Oracle BI Server Administrator 10g: Build RepositoriesStudent GuideContents1 Repository Basics2 Building the Physical Layer of a Repository3 Building the Business Model and Mapping Layer of a Repository4 Building the Presentation Layer of a Repository5 Testing and Validating a Repository6 Adding Multiple Logical Table Sources7 Adding Calculations to a Fact8 Creating Dimension Hierarchies and Level-Based Measures9 Using Aggregates10 Using RepositoryVariab les11 Security12 Cache ManagementOracle BI Architecture ComponentsThis lesson describes the following architecture components and their relationships: Clients Oracle BI Presentation Services Oracle BI Server Oracle BI Repository Data sources

SHAPE \* MERGEFORMAT

Oracle BI Architecture ComponentsThis lesson provides a high-level overview of the Oracle BI architecture components that are critical to understanding the subject matter in this course.ClientsProvide access to business intelligence information Oracle BI Answers Is a set of graphical tools used to build, view, and modify Oracle BI requests Oracle BI Interactive Dashboards Display the results of Answers requests and other items Oracle BI Administration Tool Is used to build an Oracle BI repository

SHAPE \* MERGEFORMAT

ClientsOracle BI Answers and Oracle BI Interactive Dashboards are examples of clients that provide access to business intelligence information via a Web browser. The Oracle BI Administration Tool is a Windows application.Oracle BI AnswersOracle BI Answers is a set of graphical tools used to build, view, and modify Oracle BI requests. The requests are queries against an organizations data.Oracle BI Interactive DashboardAn Oracle BI Dashboard is used to display the results of Answers requests that are embedded in the dashboard, and other items, such as links to saved requests in Answers, links to Web sites, Active-X objects, HTML Text, and links to documents. Dashboards are typically created by users with administrator permissions. However, dashboards are simple to create via the user-friendly Oracle BI interface. After dashboards are created, they can be shared by common groups of users or can be personal (not shared).Oracle BI Administration ToolThe Oracle BI Administration Tool is used to build the Oracle BI repository and is the focus of this course.Oracle BI Presentation Services Provides the processing to visualize the information for client consumption Is implemented as an extension to a Web server Uses a catalog to store saved content Receives data from Oracle BI Server and provides it to the client that requested it

SHAPE \* MERGEFORMAT

Oracle BI Presentation ServicesOracle BI Presentation Services is an extension to an existing Web server. It receives processing instructions from an Oracle BI client, retrieves the requested information from Oracle BI server, and then renders the information inside the requesting client. Oracle BI Presentation Services uses a catalog to store saved content, such as Oracle BI requests and Oracle BI Interactive dashboards.Oracle BI Presentation Services runs as a service in the Windows environment on your classroom machine.Oracle BI Server Is the core server behind Oracle Business Intelligence Provides efficient processing to intelligently access physical data sources and structure information Uses metadata to direct processing Generates dynamic SQL to query data in the physical data sources Connects natively or through ODBC to the RDBMS Structures results to satisfy requests Provides BI data to Oracle BI Presentation Services

SHAPE \* MERGEFORMAT

Oracle BI ServerOracle BI Server is the core server behind Oracle Business Intelligence. It is an optimized query engine that receives analytical requests, intelligently accesses multiple physical data sources, generates SQL to query data in the data sources, and then structures the results to satisfy the requests.It also handles requests from a variety of front ends, including Oracle BI applications as well asthird-party tools. Oracle BI Server allows a single information request to query multiple data sources, providing information access to members of the enterprise and, in Web-based applications, to suppliers, customers, prospects, or any authorized user with Web access.Oracle BI Server serves as a portal to structured data that resides in one or more data sources: multiple data marts, the Oracle BI Data Warehouse, an enterprise data warehouse, an operational data store, transaction system databases, personal databases, and more. Transparent to both end users and query tools, Oracle BI Server functions as the integrating component of a complex decision support system by acting as a layer of abstraction and unification over the underlying databases. This offers users a simplified query environment in which they can ask business questions that span information sources across the enterprise and beyond.Oracle BI Server runs as a service in the Windows environment on your classroom machine.Oracle BI Repository Stores the metadata used by Oracle BI Server Is accessed and configured using the Oracle BI Administration Tool, which you use to: Import metadata from databases and other data sources Simplify and reorganize the metadata into business models Structure the business model for presentation to users who request information SHAPE \* MERGEFORMAT

SHAPE \* MERGEFORMAT

Oracle BI RepositoryOracle BI Server stores metadata in repositories. The Administration Tool has a graphical user interface that allows server administrators to set up these repositories. An Oracle BI Server repository consists of three layers. Each layer appears in a separate pane in the Administration Tool user interface and has a tree structure. You can expand each object to see a list of its components. These layers are not visible to the end user.Building an Oracle BI repository is the focus of this course. You learn how to import metadata from databases and other data sources; how to simplify and reorganize the imported metadata into business models; and then how to structure the business model for presentation to users who request business intelligence information via Oracle BI clients, such as Oracle BI Answers and Interactive Dashboards.Data Sources Contain the business data that users want to analyze Are accessed by Oracle BI Server Can be in any format, such as: Relational databases Online Analytical Processing (OLAP) databases Flat files Spreadsheets XMLA

SHAPE \* MERGEFORMAT

Data SourcesData sources are the physical sources where the business data is stored. They can be in any format, including transactional databases, online analytical processing databases, text files, XMLA, spreadsheets, and so forth. A connection to the data source is created and then used by Oracle BI Server. The data source connection can be defined to use native drivers or ODBC. You learn more about this when you create the Physical layer for a repository in the lesson titled Building the Physical Layer of a Repository.SQL is generated by Oracle BI Server against the data sources using the data source connection, information from the repository, and database-specific parameters stored in a DBFeatures.INI file. Thus, Oracle BI Server is not just a SQL generator. It figures out the best source and the optimal way to access data. In some cases, Oracle BI Server takes on operations that are more efficient for it to do rather than the host data source.Sample Request Processing1. User views a dashboard or submits a request.2. Oracle BI Presentation Services makes a request to Oracle BI Server to retrieve the requested data.3. Oracle BI Server, using the repository file, optimizes functions to request the data from the data sources.4. Oracle BI Server receives the data from the data sources and processes as necessary.5. Oracle BI Server passes the data to Oracle BI Presentation Services.6. Oracle BI Presentation Services formats the data and sends it to the client.Clients1Oracle BI Pres Services2Oracle BI Server3Data sources

654

Sample Request ProcessingThis is a simplified example of how an Oracle BI request is processed. A user accesses a dashboard or submits a request in Answers. The request is received by Oracle BI Presentation Services, which routes the request to Oracle BI Server. Oracle BI Server uses the repository to determine the best way to access the requested data. Next it sends the SQL or other requests to the sources and then combines the results or provides further processing. It then sends the data back to Oracle BI Presentation Services, which formats the data as appropriate and sends it to the client for display.Oracle BI Administration ToolExposes the Oracle BI repository as three separate panes, called layers: Physical layer Business Model and Mapping layer Presentation layer

Oracle BI Administration ToolYou develop a repository using the Oracle BI Administration Tool. The main window of the Administration Tool provides a graphical representation of the three layers of a repository. In this course, you learn how to use the Administration Tool to build, edit, manage, and administer Oracle BI repositories.Physical Layer Contains objects representing the physical data sources to which Oracle BI Server submits queries May contain multiple data sources Is typically the first layer built in the repository SHAPE \* MERGEFORMAT

Physical LayerThe Physical layer contains information about the physical data sources to which Oracle BI Server submits queries. The most common way to populate the Physical layer is by importing metadata from databases and other data sources. The data sources can be of the same or different varieties. When you import metadata, many of the properties of the data sources are configured automatically based on the information gathered during the import process. After import, you can also define other attributes of the physical data source, such as join relationships, that might not exist in the data source metadata. There can be one or more data sources in the Physical layer, including databases, spreadsheets, and XML documents. In this example, there are two data sources in the Physical layer: ORCL and xls_quota.Physical Layer ObjectsAre objects in the Physical layer, such as connection pools, folders, tables, columns, and keys Expand a database object to display the objects it contains.DatabaseConnection poolSchema folderTablesColumnsKeyPhysical Layer ObjectsThe database object is the highest object in the Physical layer. Each database object in the Physical layer contains a connection pool, SUPPLIER CP in this example. A connection pool contains information about the connection between Oracle BI Server and the data source. For example, the connection pool contains data source name information used to connect to a data source, the number of connections allowed, timeout information, and other connectivity-related administrative details. There is at least one connection pool for each data source.You can organize the Physical layer into folders, if desired. The folders shown here are created by default when the schema is first imported. Additional folders are optional. A schema folder, SUPPLIER2 in this example, contains tables, columns, and keys for a physical schema. The table, column, and key objects provide the metadata necessary for Oracle BI Server to access the actual physical sources with SQL requests. Each object in the Physical layer has a set of properties associated with it. To view the properties, double-click the objects icon to open the Properties dialog box.Business Model and Mapping LayerIs where physical schemas are simplified and reorganized to form the basis of the users view of the data SHAPE \* MERGEFORMAT

Business Model and Mapping LayerThe Business Model and Mapping layer of the Administration Tool defines the business, or logical, models of the data and specifies the mapping between the business models and the Physical layer schemas. This is where the physical schemas are simplified to form the basis for the users view of the data. The Business Model and Mapping layer of the Administration Tool can contain one or more business model objects. A business model object contains the business model definitions and the mappings from logical to physical tables for the business model.Business Model and Mapping Layer ObjectsThe Business Model and Mapping layer contains business model objects. SHAPE \* MERGEFORMAT

Business Model and Mapping Layer ObjectsThe Business Model and Mapping Layer contains business model objects. There can be multiple business models in this layer, although there is only one in this example. The business model object (SupplierSales in this example) is the highest-level object, and it contains logical tables: Customers, Periods, Products, and SalesFacts, in this example. Logical tables contain logical columns. Logical tables also have a Sources folder that contains one or more logical table sources. These logical table sources define the mappings between the logical table and the physical tables where the data is actually stored. In this example, the data for the SalesFacts logical table is stored in the D1_ORDERS2 physical table, and the logical table source is Orders.In the Business Model and Mapping layer, data is separated and simplified into facts and dimensions. Recall that facts contain the business measures, and dimensions contain descriptive attributes that qualify the facts. Each business model contains one or more dimension tables and fact tables. A dimension table appears with a white table icon. A fact table appears with a yellow icon. The business model also contains dimension hierarchies, in this example: CustomerDim, PeriodDim, and ProductDim. Dimension hierarchies introduce formal hierarchies into a business model, establish levels for data groupings and calculations, and provide paths for drilldown in end-user tools such as Oracle BI Answers.Business Model Mappings Business Model and Mapping layer objects map to source data objects in the Physical layer. Mappings are typically not one to one: Business models may map to multiple data sources. Logical tables may map to multiple physical tables. Logical columns may map to multiple physical columns. SHAPE \* MERGEFORMAT

Business Model MappingsThe Business Model and Mapping layer of the Administration Tool can contain one or more business model objects. A business model object contains other business model object definitions and the mappings from logical to physical tables for the business model. SupplierSales is the business model object in this example. Business model objects map to the source data objects in the Physical layer.Business models map to physical schemas. Logical tables map to physical tables. Logical columns map to physical columns, and so forth. The arrows convey the mappings. There is typically not a 1:1 mapping between business model objects and a physical objects. In fact, a business model can have multiple data sources, a logical table can have multiple physical tables as sources, and a logical column can have multiple physical columns as sources. In the Administration Tool, the mappings are specified at the logical Business Model and Mapping layer, not the Physical layer. The mappings can include transformations and formulas. Thus, you use the Business Model and Mapping layer to define the meaning and content of each physical source in business model terms. Oracle BI Server then uses these business model definitions to pick the appropriate sources for each data request. For more information about business model mappings, see the lesson titled Building the Business Model and Mapping Layer of a Repository. Also note that, in this example, the business model objects have been renamed. For example, the name of the logical table that maps to the D1_CUSTOMER2 physical table has been changed to Customers. You can change the names of business model objects independently from corresponding physical model object names and properties, and vice versa. The tool keeps track of the changes. Techniques for making these changes are covered in detail throughout this course.Measures Are the facts a business uses to evaluate its performance Can be calculations defining measurable quantities Are created on logical columns in the fact table Have a defined aggregation rule SHAPE \* MERGEFORMAT

MeasuresIn a business model, some logical columns serve as measures. Measures need to be computed correctly from the base physical data when Oracle BI Server receives a query from a client. In this case, you want Dollars, Units Shipped, Units Ordered, and Net Weight Shipped to be aggregated by summing. The third bullet refers to setting aggregation on a column. By default, a column has no aggregation rule defined (rule = None). When you define an aggregation rule on a column, the icon changes to reflect this. After you define an aggregation rule on a column, the aggregation is the default. In the screenshot, the sum aggregation rule has been defined for the Dollars, Units Shipped, Units Ordered, and New Weight Shipped columns. The calculations are sent to the database or processed by Oracle BI Server. Measures may not require any calculations. For example, they might be a regular logical column and simply grab the data from the source.Presentation Layer Contains presentation objects that provide a customized view of a business model to users Simplifies and organizes the business model to make it easy for users to understand and query Exposes only the data meaningful to the users SHAPE \* MERGEFORMAT

Presentation LayerThe Presentation layer provides a means to further simplify or customize the business model for end users. Simplifying the view of the data for users makes it easier for users to craft queries based on their business needs. For example, you can organize columns differently than the table structure in the Business Model and Mapping layer, show fewer columns, and rename columns so that they are more understandable to users.Presentation Layer MappingsPresentation layer objects map to objects in the Business Model and Mapping layer. SHAPE \* MERGEFORMAT

Presentation Layer MappingsPresentation layer objects map to objects in the Business Model and Mapping layer. Presentation catalogs map to business models, presentation tables may map to logical tables, and presentation columns map to logical columns. A presentation catalog can map to only a single business model and cannot span multiple business models. However, multiple presentation catalogs can reference the same business model and a presentation table can contain columns from one or more logical tables.Thus, you can use presentation catalogs and tables to organize columns into categories that make sense to the user community.Presentation tables do not necessarily have a one-to-one mapping to a logical table. Presentation tables are folders used for organizing columns and can be organized and structured differently from logical tables in the Business Model and Mapping layer.You can create Presentation layer objects by dragging and dropping objects from the Business Model and Mapping layer. Corresponding objects are automatically created in the Presentation layer. The presentation table and column names are, by default, identical to the logical names in the Business Model and Mapping layer, but can be renamed. Thus, the names and object properties of the presentation tables are independent of the logical table properties. It is also possible to nest presentation tables so they appear as nested folders in the Answers UI. Note that these are just examples and that presentation tables do not have to mirror business model logical table and columns as the diagram implies.Presentation Layer Defines User InterfacePresentation layer objects define the interface that users see to query the data from the data sources. SHAPE \* MERGEFORMAT

Presentation Layer Defines User InterfacePresentation layer objects define the interface that users see to query the data from the data sources. Presentation layer objects appear as subject areas, folders, and columns in Oracle BI Answers. Presentation catalogs in the Presentation layer are seen as subject areas in Oracle BI Answers. Presentation folders in the Presentation layer are seen as folders in Oracle BI Answers. Presentation columns are seen as columns within the Oracle BI Answers folders.Presentation layer objects can be renamed and reorganized and typically use terminology that is meaningful to the user.Repository DirectoryRepository files reside in the \Oracle BI\server\Repository directory where the Oracle BI software is installed. SHAPE \* MERGEFORMAT

Repository DirectoryRepository files are stored by default in the \OracleBI\server\Repository directory where the Oracle BI software is installed. From this directory, repository files are loaded by Oracle BI Server, or they can be opened for editing. To open repository files for editing, you can double-click the file in this directory, or open the file using the Administration Tool. Repository files can be opened in two modes, which are discussed on the next page.Repository ModesRepository files can be opened in either offline or online mode. Offline Oracle BI Server is not started. Repository is not loaded into Oracle BI Server memory. Used for development Online Oracle BI Server is started. Repository loaded into memory. Users can submit query requests.Repository ModesA repository can be opened in the Administration Tool in two modes: offline or online.Offline ModeOpening a repository in offline mode means Oracle BI Server is not started and the repository is not loaded into its memory. Offline mode is typically used for development. The repository is modified, saved, and then loaded at the next Oracle BI Server startup. It is possible to use multiuser checkout for projects with many developers.Online ModeOpening a repository in online mode means Oracle BI Server is started and the repository is loaded into its memory. Because Oracle BI Server may be processing queries while you are editing the repository in online mode, you must check out objects before editing them. After the objects have been edited, you can check them in again. When you are finished editing and checking in the changes, you can save the changes by saving the repository file and the changes become active.Users can still access the repository while changes are being made in online mode.Adding an Entry in NQSConfig.iniNQSConfig.ini is a configuration file read by Oracle BI Server to determine which repository to load into memory. SHAPE \* MERGEFORMAT

Adding an Entry in the NQSConfig.ini fileAfter you have built a repository, you need to add an entry in the NQSConfig.ini file for the repository. The entry allows Oracle BI Server to load the repository into memory when it is started. There can be multiple repositories listed in the repository section of this file. For example, multiple repositories might be listed for testing purposes. If there are multiple repositories, Oracle BI Server will read them all when it starts up. Only one repository can be loaded for access by a particular Oracle BI Presentation Server instance. One repository must be specified as the default. If multiple repositories are specified as the default repository, the last one listed will become the default repository. Any line beginning with a pound sign (#) will be treated as a comment. If the repository file name contains a space, enclose the file name in single quotation marks.SummaryIn this lesson, you should have learned how to: Identify and describe the major components of the Oracle BI architecture Identify and describe the three layers of an Oracle BI Repository and how they relate to one another Use the Oracle BI Administration Tool to explore repository objectsPractice 1-1 Overview: Exploring an Oracle BI RepositoryThis practice covers the following topics: Exploring the Physical layer of a repository Exploring the Business Model and Mapping layer of a repository Exploring the Presentation layer of a repository Loading a repository into memory Submitting a request using Oracle BI AnswersPractice 1-1 Overview: Exploring an Oracle BI RepositoryThis practice makes you familiar with the Administration Tool and helps you understand the three layers of an Oracle BI Repository and how they relate to one another.Physical Layer Contains objects representing the physical data sources to which Oracle BI Server submits queries May contain multiple data sources Is typically the first layer built in the repository SHAPE \* MERGEFORMAT

Physical LayerThe Physical layer defines the data sources to which Oracle BI Server submits queries and the relationships between physical databases and other data sources that are used to process multiple data source queries. The most common way to populate the Physical layer is by importing metadata from databases and other data sources. The data sources can be of the same or different varieties. You can import schemas or portions of schemas from existing data sources. Additionally, you can create the physical layer manually.When you import metadata, many of the properties of the data sources are configured automatically based on the information gathered during the import process. After import, you can also define other attributes of the physical data source, such as join relationships, that might not exist in the data source metadata. There can be one or more data sources in the Physical layer, including databases, spreadsheets, and XML documents. In this example, there are two data sources in the Physical layer: ORCL and xls_quota.Physical Layer ObjectsAre objects in the Physical layer, such as connection pools, folders, tables, columns, and keys Expand a database object to display the objects it contains.DatabaseConnection poolSchema folderTablesColumnsKeyPhysical Layer ObjectsThe database object is the highest object in the Physical layer. Each database object in the Physical layer contains a connection pool, SUPPLIER CP in this example. A connection pool contains information about the connection between Oracle BI Server and the data source. You can organize the Physical layer into folders, if desired. The folders shown here are created by default when the schema is first imported. Additional folders are optional. A schema folder, SUPPLIER2 in this example, contains tables, columns, and keys for a physical schema. The table, column, and key objects provide the metadata necessary for Oracle BI Server to access the actual physical sources with SQL requests. Each object in the Physical layer has a set of properties associated with it. To view an objects properties, double-click the objects icon to open the properties dialog box. Each of the objects shown here is discussed in more detail on the slides that follow.Database Object Is the highest-level object in the Physical layer Defines the data source to which Oracle BI Server submits queries SHAPE \* MERGEFORMAT

Database ObjectThe database object is the highest-level object in the Physical layer. It defines the data source to which Oracle BI Server submits queries. Importing a schema automatically creates a database object for the schema in the Physical layer.Database Object: General PropertiesUse the General tab to view and set general properties for a database object.NameTypeDatabase Object: General PropertiesImporting a schema automatically creates a database object for the schema, but in some cases you need to manually set up the database object properties. Double-click the database object or right- click and select Properties to open the database object properties dialog box. If you import the physical schema into the Physical layer, the database name and type are usually assigned automatically. However, if the server cannot determine the database type, an approximate ODBC type is assigned to the database object. If necessary, replace the database type with the closest matching entry from the database drop-down menu. Persist connection pool is a database property that is typically used to support Marketing queries. Refer to the Oracle BI Server Administration Guide for more details. When Allow populate queries by default is selected, this allows everyone to execute POPULATE SQL. If you want most but not all users to be able to execute POPULATE SQL, select this option and then limit queries for specific users or groups using Security Manager. You learn more about Security Manager in the lesson titled Security. When Allow direct database requests by default is selected, this allows everyone to execute physical queries directly against the database from the Answers UI. If you want most but not all users to be able to execute physical queries, select this option and then limit queries for specific users or groups.Database Object: FeaturesUse the Features tab to view and set the SQL features that Oracle BI Server uses with this data source. SHAPE \* MERGEFORMAT

Database Object: FeaturesWhen you import the schema or specify a database type in the General tab of the Database dialog box, the Features table is automatically populated with default values appropriate for the database type. These are the SQL features that Oracle BI Server uses with this data source. You can customize the default query features for a database. For example, if a data source supports left outer join queries, but you want to prohibit the server from sending such queries to a particular database, you can change this default setting in the Feature table. But be very careful when modifying the Feature table. If you enable SQL features that the database does not support, your query may return errors and unexpected results. If you disable supported SQL features, the server could issue less efficient SQL to the database. The Default check box identifies the default SQL features for this data source. The Value check box allows you to enable or disable a query type. It is strongly recommended that you do not disable the default SQL features. The Ask DBMS button is used only if you are installing and querying a database that has no features table. It allows you to query a database for the SQL features it supports. Be very careful when using Ask DBMS. The results of the features query are not always an accurate reflection of the SQL features actually supported by the data source. You should use this functionality only with the assistance of Oracle Technical Support. The Revert to defaults button restores the default features values. The Find button allows you to enter a string to help you locate a feature in the list.Connection Pool Defines how Oracle BI Server connects to a data source Specifies the ODBC or native data source name Allows multiple users to share a pool of data source connectionsConnection pool nameData source name

Maximum number of connectionsShared logon user name and password

Connection pooling enabledConnection PoolFor each data source, there is at least one corresponding connection pool. The connection pool contains information about the connection between Oracle BI Server and a data source. Typically, the database object and connection pool are created automatically when you import the physical schema. It is strongly recommended that you use OCI for connecting to Oracle. ODBC should only be used to import from Oracle.The connection pool contains data source name (DSN) information used to connect to a data source, the number of connections allowed, timeout information, and other connectivity-related administrative details. Connection pools allow multiple concurrent data source requests (queries) to share a single database connection, reducing the overhead of connecting to a database. You can create multiple connection pools to improve the performance for groups of users.Selecting Enable connection pooling allows multiple concurrent query requests to share a single database connection. This reduces the overhead of connecting to a database because it does not open and close a new connection for every query. If you do not select this option, each query sent to the database opens a new connection.Schema FolderIs an optional display folder that contains tables and columns for a physical schema To create a schema folder, right-click a database object and select New Object > Physical Schema. SHAPE \* MERGEFORMAT

Schema FolderThe schema folder contains tables and columns for a physical schema. Schema folder objects are optional in the Physical layer of the Administration Tool. You must create a database object before you create a schema object. A schema folder is created by default when you first import from a data source. To create a new schema object, right-click the database object and select New Object > Physical Schema.Physical Table Is an object that corresponds to a table in a physical data source Is typically imported from a database or other data source Provides the metadata necessary for Oracle BI Server to access the tables with SQL requests SHAPE \* MERGEFORMAT

Physical TableA physical table is an object in the Physical layer of the Administration Tool that corresponds to a table in a physical database. Physical tables are usually imported from a database or another data source, and they provide the metadata necessary for Oracle BI Server to access the tables with SQL requests. When data source definitions are imported, no actual data is moved. Data remains stored in the physical data source.Physical Table PropertiesDouble-click a physical table object to view its properties: SHAPE \* MERGEFORMAT

Physical Table PropertiesUse the General tab to view and set general properties for a physical table object. By default, the name corresponds to the table name defined during import, but you can rename it. The Table Type drop-down list allows you to specify the physical table object type. Physical Table is the default. You can also define the physical table as a stored procedure or a select statement. When you select either of theses options, a text pane below the Table Typedrop-down list becomes active, allowing you to enter the stored procedure or the select statement. Requests against this table then execute the stored procedure or the select statement. You can use a dynamic name to specify the name of a table object. You must define a session variable before you can set a dynamic name. You learn more about variables in the lesson titled Using Repository Variables. Select Cacheable to include the table in the Oracle BI Server query cache. This is selected by default. Select Cache never expires or set Cache persistence time to define how long table entries should persist in the cache. You learn more about caching in the lesson titled Cache Management. Database hints are instructions placed within a SQL statement that tell the database query optimizer the most efficient way to execute the statement. Hints override the optimizers execution plan, so you can use hints to improve performance by forcing the optimizer to use a more efficient plan. The Columns, Keys, and Foreign Keys tabs allow you to view, create new, and edit existing columns, keys, and foreign keys that are associated with the table.Physical Table: Alias Table TypeIs a virtual physical table object that points to a physical table object Right-click a physical table and select New Object > Alias. Provide a name for the alias table. The alias table appears with an alias icon in the Physical layer. SHAPE \* MERGEFORMAT

Alias Table TypeAn alias table type specifies that the physical table object is an alias to another table. An alias table in the physical layer of the repository is just like any alias used in standard SQL notation. That is, you want to reference the same table twice in a given SQL statement, but to avoid circularity in the references, you use a different name. A common use for aliases is role-playing dimensions, where a single dimension simultaneously appears several times in the same fact table. For example, an order date and a shipping date in a fact table may both point to the same column in a physical dimension table, but each role is presented as a separately labeled alias.Alias SynchronizationSynchronization is the act of ensuring that the source table and related alias tables have the same column definitions. An alias table always inherits all of the column definitions from the source table and synchronization happens automatically. Consequently, columns in an alias table cannot be modified. All columns opened from an alias table become read-only. Creation of a source column creates the same column on all its alias tables. Deletion of a source column automatically deletes corresponding alias columns. Modification of a source column forces the same changes to be reflected in the alias columns.To create an alias:1. Right-click a physical table and select New Object > Alias.2. Provide a name for the alias table. The table properties dialog box displays the source table.3. The alias table appears with a green arrow alias icon in the Physical layer.Physical Table: Select Table TypeSpecifies that a physical table object is a SELECTstatement SHAPE \* MERGEFORMAT

Select Table TypeA Select table type specifies that the physical table object is a SELECT statement. When you select this option, the Default Initialization String text pane below the Table Type drop-down list becomes active, allowing you to enter the SELECT statement. Requests for this table will execute the SELECT statement. In this example, the SELECT statement returns all rows from D1_CUSTOMER2 where Region = 'East'. Select tables can be created manually, or by duplicating an existing physical table and changing the table type. Select tables have an eyeglasses icon.For SELECT statements that are database specific, you can select the database type from the drop- down list above the text pane. At run time, if a SELECT statement has been defined for the corresponding databases database type, then the SELECT statement will be executed; otherwise, the default configuration will be executed.Physical Table: View DeploymentCreates a corresponding database view for metadata views SHAPE \* MERGEFORMAT

View DeploymentA Select table serves as an opaque view in the repository metadata, but no corresponding view is actually created in the database. The Administration Tool provides a Deploy View feature that creates a corresponding view in the database.The advantages of creating views in the database are: The server generates simpler queries whenever opaque view is encountered. Query statement errors can be more easily identified. Optimization or any other features provided by database vendors for views can be leveraged.Not all databases can run view deployment. For example, XLS databases and nonrelational databases cannot have views deployed. To make view deployment explicit, the CREATE_VIEW_SUPPORTED feature has been added to the feature list of a database object. Only opaque views that belong to a database with this feature enabled can run view deployment.To deploy a view, right-click the object and select Deploy View. It is possible to select multiple views and deploy them simultaneously, or to deploy all views for a database, catalog, or schema. View names are restricted to 18 characters and must be alphanumeric. Views can also be undeployed, which drops the view from the database.Physical ColumnIs an object that corresponds to a column in a physical database SHAPE \* MERGEFORMAT

Physical ColumnA physical column is an object in the Physical layer of the Administration Tool that corresponds to a column in a physical database. Each physical table object in the Physical layer has one or more physical column objects. The column properties are set automatically when the column is imported. Double-click a column to view or modify its properties.Key ColumnDefines relationships between tables Primary key: Uniquely identifies a single row of data Consists of a column or set of columns Is identified by a key icon Foreign key: Refers to the primary key columns in another table Is composed of a column or set of columns SHAPE \* MERGEFORMAT

Key ColumnA primary key and foreign key relationship defines a one-to-many relationship between two tables. A foreign key is a column or a set of columns in one table that references the primary key columns in another table. The primary key is defined as a column or set of columns where each value is unique and identifies a single row of the table. Keys and joins help Oracle BI Server determine the fact dimension relationships between tables. The Physical layer typically uses foreign key joins to define relationships, whereas the Business Model and Mapping layer uses logical joins to define relationships. You learn more about logical joins in the lesson titled Building the Business Model and Mapping Layer of a Repository. Typically, keys are defined only for dimension tables, not for fact tables.JoinsRepresent the primary keyforeign key relationships between tables in the Physical layerPhysical Diagram

Join propertiesDouble-click to view join properties.Join expressionJoinsJoins represent the relationships between tables in the Physical layer. Joins that already exist in the physical data sources are imported automatically into the Physical layer, but can be modified. When you import keys in a physical schema, the primary keyforeign key joins are automatically defined. Any other joins within each database have to be explicitly defined. You need to define any joins that express relationships between tables in the Physical layer of the repository. You can use the Physical Diagram feature to create joins between physical table objects. Note that complex joins can be used in this layer to express the relationships that do not involve a primary keyforeign key relationship. When you create a complex join in the Physical layer, you can specify expressions and the specific columns on which to create the join. When you create a complex join in the Business Model and Mapping layer, you do not specify expressions.ABC ScenarioData for ABC resides in the SUPPLIER2 schema in an Oracle relational database, containing tables with: Invoice data SHAPE \* MERGEFORMAT

ABC ScenarioThroughout this course, you build a repository based on the business requirements of ABC, a fictitious company that sells restaurant supplies. In the first practice for this lesson, you read a document that explains in detail the ABC business scenario. Because you have not yet read this document, this slide briefly introduces the ABC business requirements. ABCs data reside in the SUPPLIER2 schema in an Oracle relational database on your student machine. The schema contains invoice fact data, and customer, product, and period dimension data. The first task is to use the Administration Tool to import metadata about the schema into the Physical layer of the repository. The remaining pages in this lesson describe the steps for this task.Implementation Steps1. Define an ODBC System Data Source Name (DSN).2. Import the physical schema.3. Select tables and columns for import.4. Import keys and joins.5. Verify the import.6. Edit connection pool properties.7. Define physical keys and joins.Implementation StepsThis is an overview of the necessary steps for building the Physical layer. Subsequent slides cover each step in detail.1. Define an ODBC System DSNUse the ODBC Data Source Administrator to define a system DSN for each data source. SHAPE \* MERGEFORMAT

1. Define an ODBC System DSNMost physical schema imports are performed using an ODBC connection type. Native database gateways for schema import are only supported for DB2 and XML connection types. Assuming you are using an ODBC connection type, the first step is to define the system data source name for the data source you want to import. This slide shows the initial steps for using the ODBC Data Source Administrator to define a system data source name for the data source you want to import. Additional steps include testing the data source connection. These are the standard steps for setting up an ODBC data source using the ODBC Data Source Administrator.2. Import the Physical SchemaUse the Oracle BI Administration Tool to import the physical schema. SHAPE \* MERGEFORMAT

2. Import the Physical SchemaThe next step is to import physical schemas using the ODBC DSN. The most common way to populate the Physical layer is by importing from databases and other data sources. In fact, it is strongly recommended that you import the physical schema as opposed to building the metadata from scratch in the Physical layer. This slide illustrates the process for importing from your data source into the Oracle BI Server repositorys Physical layer. In the Oracle BI Administration Tool, select File > Import > from Database to open the Select ODBC Data Source window. This window shows the available ODBC data source names. Select the desired ODBC DSN and click OK.3. Select Tables and Columns for ImportSelect the tables and columns needed to support the business model.Filter tables for import.Select tables or columns for import.Tables and keys selected by default3. Select Tables and Columns for ImportAfter you have selected the ODBC data source name, a window opens and displays the available schemas, tables, and columns. At this point you can import schemas or portions of schemas from existing data sources. When you import the physical tables, it is good practice to limit the import to only those tables that contain data that you are likely to use in the business models you create. You can use a filter (table mask) to limit the number of tables that appear in the import list. This makes it easier to locate and select the tables that you want to import. To use a table mask, enter a table mask such as D1%, and then click the highest-level database folder. Tables that meet the filter criteria appear. You also need to check the type of physical metadata you want to import. The default is to import tables and keys. Note that you can also import database views, aliases, synonyms, foreign keys, and system tables.4. Import Keys and JoinsKeys, foreign keys, and corresponding joins are imported automatically only if they are already defined in the data source.4. Import Keys and JoinsBased on the selections you make when you import, many properties of the physical model are configured automatically in the Physical layer based on the information gathered during the import process. For example, if you import a physical schema and import keys and foreign keys, the primary keyforeign key joins are automatically defined in the Physical layer. Of course, this occurs only if the relationships are already defined in the source data. After import, you can also explicitly define other attributes of the physical data source that might not be defined in the source, such as join relationships. It is recommended that you not import foreign keys from an Oracle database because the process is lengthy when importing a large number of tables.5. Verify the Import Verify that the correct schema, tables, columns, and keys were imported. Use Update Row Count and View Data features to verify connection. SHAPE \* MERGEFORMAT

5. Verify the ImportAfter import completes, close the import dialog box and verify that the expected schemas, tables, columns, and keys exist in the Physical layer. It is also good practice to update row counts and view data to verify that the connection is configured correctly.6. Edit Connection Pool PropertiesAfter import, verify or modify connection pool properties using the connection pool properties dialog box. SHAPE \* MERGEFORMAT

6. Edit Connection Pool PropertiesAfter importing into the Physical layer, the next step is to set up, or verify, the connection pool for the data source. The connection pool contains information about the connection between Oracle BI Server and that data source, for example, the connection pool name, the data source name that connects to the data source, user name and password for the data source, and the maximum number of connections. The Physical layer in the Administration Tool contains at least one connection pool for each data source. When you create the Physical layer by importing a schema for a data source, the connection pool is created automatically. But you can configure multiple connection pools for a database. Click the General tab of the Connection Pool dialog box to create or edit a connection pool in the Physical layer. The recommendation is to give the connection pool a distinct name. Selecting Enable connection pooling allows multiple concurrent query requests to share a single database connection. This reduces the overhead of connecting to a database because it does not open and close a new connection for every query. If you do not select this option, each query sent to the database opens a new connection. The Timeout value indicates how long a connection remains open for any future requests. For each connection pool, you must specify the maximum number of concurrent connections allowed. When this limit is reached, Oracle BI Server routes all other connection requests to another connection pool, or if no other connection pools exist, the connection request waits until a connection becomes available.7. Define Physical Keys and JoinsThe Administration Tool allows you to define physical keys and joins that were not imported automatically. Define keys using the Physical Table properties dialog box. Define joins and keys using the Physical Diagram.7. Define Physical Keys and JoinsThe Administration Tool allows you to define keys and joins using several different methods. You must define joins that exist on the physical database in the Physical layer of the repository. If the imported database joins over primary keyforeign key relationships and the primary keys and foreign keys are imported into the repository, the join conditions are set up automatically in the Physical layer of the repository. In the ABC example, primary keys, foreign keys, and joins have not been automatically defined in the repository, so they need to be defined manually.Defining Keys Using the Table Properties DialogOpen the table properties dialog box to view or define keys.Select the appropriate tab.Check the appropriate check box to define the key.Click New.Defining Keys Using the Table Properties DialogRight-click a table object and select Properties, or double-click the table object to open the table properties dialog box. The primary key is defined as a column or set of columns where each value is unique and identifies a single row of the table. You can view or specify both primary key and foreign keys in the Physical Diagram or by using the Keys tab and Foreign Keys tab of the Physical Table properties dialog box, which is illustrated in this slide. The Physical Diagram is discussed on the next page.Using the Physical DiagramUse the Physical Diagram to view or define keys and joins. SHAPE \* MERGEFORMAT

Using the Physical DiagramThe Physical Diagram graphically shows the physical tables and any defined joins between them. You can use the Physical Diagram to define primary keys, foreign keys, and joins between tables. As stated earlier, all valid physical joins need to be configured in the Physical layer of the Administration Tool. To open the Physical Diagram window, select one or more tables in the Physical layer and then click the Physical Diagram icon on the toolbar or select one of the Physical Diagram options from the shortcut menu. The options are shown in the slide: selected objects only, objects and direct joins, and objects and all joins. You can view any joins that have already been created by double-clicking a join to open the Joins properties box. You also can create new joins using the Join icons on the toolbar, pictured on the next slide.Defining Foreign Key Joins SHAPE \* MERGEFORMAT

Defining Foreign Key JoinsThis slide describes the process for building a foreign key join in the Physical Diagram. To define a foreign key join:1. Click the New Foreign Key icon on the Administration Tool toolbar.2. With this icon selected, in the Physical Diagram, click the first table in the join (the table representing one in the one-to-many join) to select it.3. Move the cursor to the table to which you want to join (the table representing many in the one- to-many join), and then click the second table to select it. The order is important. The first table you click contains the primary key. The second table contains the foreign key that points to the primary key in the first table.4. After you click the second table, the Physical Foreign Key dialog box appears.5. Join the key column in the first table to a column that is the foreign key in the second table by selecting the appropriate columns. By default, the left side is the one side and the right side is the many.6. The SQL join condition appears in the expression pane of the window.

Clients

Oracle BI Presentation Services

Oracle BI

Server

Data sources

Clients

Oracle BI Presentation Services

Oracle BI

Server

Data sources

Clients

Oracle BI Presentation Services

Oracle BI

Server

Data sources

Clients

Oracle BI Presentation Services

Oracle BI

Server

Data sources

Repository

Clients

Oracle BI Presentation Services

Oracle BI

Server

Data sources

Clients

Oracle BI Presentation Services

Oracle BI

Server

Data sources

Data sources

Business model Dimension hierarchies Logical dimension tables

Logical fact table Logical table source Logical columns

Measures

Mappings

Summation icon denotes an aggregation rule.

Presentation catalogs

map to business model.

Presentation tables may

map to logical tables.

Presentation columns

map to logical columns.

Presentation

catalog

Presentation

folder

Presentation

column

Subject area

Folder

Column

Default location of

repository files

Oracle BI

Repository file

Repository to load

Commented out

Data sources

Database object

Enable or disable feature

Default SQL

features for this data source

Schema folder

Physical table

Use tabs to create, view,

or modify other properties.

Name

Table type

Cacheable

Alias synchronization is automatic.

Alias

name

Source table

Table Type

Database specific SQL

SELECT

statement

Select Deploy View.

View created in database

Columns

Key

Customer data

Product data Period data

Physical layer

Source data

SUPPLIER2

Import metadata

using Administration Tool

Data source name

TNS service name

User ID

Test

Select ODBC source.

Select File > Import

> from Database.

Schema

Tables

Columns

Key

Connection

pool name

Call interface

Maximum number of connections

Shared logon

user name and password

Data source name

Connection pooling enabled

Click the Physical

Diagram icon ...

... or right-click the

object to open the Physical Diagram.

Double-click the link to open the Joins properties box.

1. Select New

Foreign Key.

5. Select key

columns.

2. Select one table

in relationship.

3. Select "many

table in relationship.

4. Physical

Foreign Key dialog opens.

6. Join expression: first table selected maintains primary key; second table selected maintains foreign key to first table.