Creating a Repository Using the Oracle Business Intelligence Administration Tool
Purpose
This tutorial covers using the Oracle Business Intelligence (BI) Administration Tool to build, modify, enhance, and manage an Oracle BI repository. This tutorial is built using OBI EE 11.1.1.3. There will be some differences if you are testing with 11.1.1.5, such as in Create Keys and Joins, Check Consistency, and Set Up Query Logging. There is a new tutorial based on OBI EE 11.1.1.5, please check here.
Time to Complete
Approximately 6 hours.
Overview
This tutorial shows you how to build an Oracle BI metadata repository using the Oracle BI Administration Tool. You learn how to import metadata from databases and other data sources, simplify and reorganize the imported metadata into a business model, and then structure the business model for presentation to users who request business intelligence information via Oracle BI user interfaces.
Prerequisites
Before starting this tutorial, you should:
1.
|
Have access to or have Installed Oracle Business Intelligence Enterprise Edition 11g.
|
2.
|
Have access to or have installed the Sample Application schema (BISAMPLE) that ships with Oracle Business Intelligence 11g. You can access the BISAMPLE schema and installation instructions here.
If you are interested in downloading and installing the latest version of the entire Sample Application, you can access it here on the Oracle Technical Network (OTN). Please note, however, that only the BISAMPLE schema is required to complete this tutorial.
|
Building the Physical Layer of a Repository
In this topic you use the Oracle BI Administration Tool to build the Physical layer of a repository.
The 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 recommended 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 objects in 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 sources, 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, flat files, XML documents, and so forth. In this example, you import and configure tables from the BISAMPLE schema included with the Oracle BI 11g Sample Application.
To build the Physical layer of a repository, you perform the following steps:
- Create a New Repository
- Import Metadata
- Verify Connection
- Create Aliases
- Create Physical Keys and Joins
Create a New Repository
1.
|
Select Start > Programs > Oracle Business Intelligence > BI Administration to open the Administration Tool.
|
2.
|
Select File > New Repository.
|
3.
|
Enter a name for the repository. In this tutorial the repository name is BISAMPLE.
|
4.
|
Leave the default location as is. It points to the default repository directory.
|
5.
|
Leave Import Metadata set to Yes.
|
6.
|
Enter and retype a password for the repository. In this tutorial BISAMPLE is the repository password.
|
7 .
|
Click Next.
|
Import Metadata
1 .
|
Change the Connection Type to OCI 10g/11g. The screen displays connection fields based on the connection type you selected.
|
2 .
|
Enter a data source name. In this example the data source name is orcl. This name is the same as the tnsnames.ora entry for this Oracle database instance.
|
3 .
|
Enter a user name and password for the data source. In this example the username and password are both BISAMPLE. Recall that BISAMPLE is the name of the user/schema you created in the prerequisite section.
|
4 .
|
Click Next.
|
5 .
|
Accept the default metadata types and click Next.
|
6 .
|
In the Data source view, expand the BISAMPLE schema.
|
7 .
|
Use Ctrl+Click to select the following tables:
SAMP_ADDRESSES_D
SAMP_CUSTOMERS_D SAMP_PRODUCTS_D SAMP_REVENUE_F SAMP_TIME_DAY_D |
8 .
|
Click the Import Selected button to add the tables to the Repository View.
|
9 .
|
The Connection Pool dialog box appears. Accept the defaults and click OK.
|
10 .
|
The Importing message appears.
|
11 .
|
When import is complete, expand BISAMPLE in the Repository View and verify that the five tables are visible.
|
12 .
|
Click Finish to open the repository.
|
13 .
|
Expand orcl > BISAMPLE and confirm that the five tables are imported into the Physical layer of the repository.
|
Verify Connection
1 .
|
Select Tools > Update All Row Counts.
|
2 .
|
When update row counts completes, move the cursor over the tables and observe that row count information is now visible, including when the row count was last updated.
|
3 .
|
Expand tables and observe that row count information is also visible for individual columns.
|
4 .
|
Right-click a table and select View Data to view the data for the table.
|
5 .
|
Close the View Data dialog box when you are done. It is a good idea to update row counts or view data after an import to verify connectivity. Viewing data or updating row count, if successful, tells you that your connection is configured correctly.
|
Create Aliases
1 .
|
It is recommended that you use table aliases frequently in the Physical layer to eliminate extraneous joins and to include best practice naming conventions for physical table names. Right-click SAMP_TIME_DAY_D and select New Object > Alias to open the Physical Table dialog box.
|
2 .
|
Enter D1 Time in the Name field.
|
3 .
|
In the Description field, enter Time Dimension Alias at day grain. Stores one record for each day.
|
4 .
|
Click the Columns tab. Note that alias tables inherit all column definitions from the source table.
|
5 .
|
Click OK to close the Physical Table dialog box.
|
6 .
|
Repeat the steps and create the following aliases for the remaining physical tables.
SAMP_ADDRESSES_D = D4 Address SAMP_CUSTOMERS_D = D3 Customer SAMP_PRODUCTS_D = D2 Product SAMP_REVENUE_F = F1 Revenue |
Create Keys and Joins
1 .
|
Select the five alias tables in the Physical layer.
|
2 .
|
Right-click one of the highlighted alias tables and select Physical Diagram > Selected Object(s) Only to open the Physical Diagram. Alternatively, you can click the Physical Diagram button on the toolbar.
|
3 .
|
Rearrange the alias table objects so they are all visible. If desired, right-click in the white space of the diagram and select Zoom to change the size of the objects in the Physical Diagram.
|
4 .
|
Click the New Foreign Key button on the toolbar.
|
5 .
|
Click the D1 Time table, and then click the F1 Revenue table. The Physical Foreign Key dialog box opens. It matters which table you click first. The join creates a one-to-many (1:N) relationship that joins the key column in the first table to a foreign key column in the second table.
|
6 .
|
Select the D1 Time. CALENDAR_DATE column, and then select F1 Revenue.BILL_DAY_DT to join the tables. Ensure that the Expression edit box (at the bottom) contains the following expression:
"orcl".""."BISAMPLE"."D1 Time"."CALENDAR_DATE" = "orcl".""."BISAMPLE"."F1 Revenue"."BILL_DAY_DT" |
7 .
|
Click OK to close the Physical Foreign Key dialog box. The join is visible in the Physical Diagram.
|
8 .
|
Repeat the steps to create joins for the remaining tables. Use the following expressions as a guide:
"orcl".""."BISAMPLE"."D2 Product"."PROD_KEY" = "orcl".""."BISAMPLE"."F1 Revenue"."PROD_KEY"
"orcl".""."BISAMPLE"."D3 Customer"."CUST_KEY" = "orcl".""."BISAMPLE"."F1 Revenue"."CUST_KEY"
"orcl".""."BISAMPLE"."D4 Address"."ADDRESS_KEY" = "orcl".""."BISAMPLE"."D3 Customer"."ADDRESS_KEY"
|
9 .
|
Click the X in the upper right corner to close the Physical Diagram.
|
10 .
|
Select File > Save or click the Save button on the toolbar to save the repository.
|
11 .
|
Click No when prompted to check global consistency. Checking Global Consistency checks for errors in the entire repository. Some of the more common checks are done in the Business Model and Mapping layer and Presentation layer. Since these layers are not defined yet, bypass this check until the other layers in the repository are built. You learn more about consistency check later in this tutorial.
|
12 .
|
Leave the Administration Tool and the repository open for the next topic.
Congratulations! You have successfully created a new repository, imported a table schema from an external data source into the Physical layer, created aliases, and defined keys and joins.
In the next topic you learn how to build the Business Model and Mapping layer of a repository.
|
No comments:
Post a Comment