Gathering Information to Build an Initial Business Model :

Goal Scenario provided in the ABC document that you read in the previous practice to determine the structure of the initial business model. : : To analyze the business requirements to begin building the metadata Before you begin building the metadata, you need to gather and analyze the business requirements of the ABC company. In this practice, you use the information

Creating a Repository and Importing a Data Source :

Goals Scenario Physical layer Outcome : of the repository using the Server Administration Tool. You have a new repository file, ABC.rpd, which contains the D1_CALENDAR2, D1_ CUSTOMER2, D1_ORDERS2, and D1_PRODUCTS tables in the Physical layer. : : To create a new repository and import the table schema from an external data source. First, you check an existing ODBC data source for an Oracle database. Then you create a new repository and import tables from the SUPPLIER2 schema into the

Defining Keys and Joins :

Goals Scenario define the keys and joins that exist on the physical database in the Physical Layer of the repository. If the imported database had primary key-foreign key relationships defined and the primary keys and foreign keys were imported into the repository, then the join conditions would be set up automatically. But that is not always what you want because foreign key relationships are set in a database for only one purpose (referential integrity), which may not correspond to the purpose of the Administration Tool (knowing which joins to include in the SQL). In this database, primary keys, foreign keys, and joins have not been defined. Therefore, you need to define the keys and join conditions manually using an objects Properties dialog box and the Physical Diagram feature of the Administration Outcome : Tool. Keys and joins defined on the physical tables. : : To define the primary keys, foreign keys, and joins in the Physical layer. You have just created a new repository and imported the initial tables from the SUPPLIER2 schema to the Physical layer of the repository. Now, you must

Creating Alias and Select Tables :

Goals Scenario : : To create alias and select table types, and deploy a view. You create an Order Date alias that points to the D1_CALENDAR2 table, and a RegionEast select table. You also practice deploying and undeploying a view and

Outcome

checking the results. A new alias table called ORDER_DATE and a select table called RegionEast.

Creating the Business Model :

Goal repository. Scenario layer of the repository. The main purpose of the business model is to capture how users think about their businesses using their own vocabulary. The business model simplifies the physical schema and maps the users business vocabulary to physical sources. Most of the vocabulary translates into logical columns in the business model. Collections of logical columns form logical tables. Each logical column (and, therefore, each logical table) can have one or more physical objects as sources. There are two main categories of logical tables: fact and dimension. Logical fact tables contain the measures by which ABC gauges its business operations and performance. Logical dimension tables contain the data used to qualify the facts. This practice assumes that a business model has already been designed on paper. You know what measures are important to ABC, what ABC employees compare measures to, and how the company likes to analyze its data. The goal of this practice is to capture this information in a business model in the Business Model and Mapping layer of the repository. Outcome : In the Business Model and Mapping layer, the SupplierSales business model with Periods, Customers, Products, and SalesFacts logical tables. : : To create a business model in the Business Model and Mapping layer of the In the previous practice, you created the Physical layer of the repository. You are now ready to begin building the business model in the Business Model and Mapping

Creating Simple Measures :

Goals Scenario mappings to better understand the relationships that exist between logical tables and their logical table sources.You then create measures by setting aggregation rules for logical columns. Outcome : Then you check the physical tables referenced by the business model. Measures defined in the SalesFacts logical table. : : To examine the logical-to-physical column mappings and create simple measures. The SupplierSales business model is now defined in the Business Model and Mapping layer. In this practice, you review the logical-to-physical table and column

Creating the Presentation Layer :

Goal Scenario business model to users in Oracle BI Answers so that they can build requests to analyze their data. Outcome : In the Presentation layer of the repository, there is a SupplierSales presentation catalog and a SupplierSalesDM presentation catalog. : : To create the Presentation layer of a repository. You have created the initial SupplierSales business model in the repository. You now create the Presentation layer of the repository. This allows you to expose the

Testing the Repository :

Goal examining Scenario consistency checking option.You then test the repository by running queries using Oracle BI Answers. Finally, you examine the query log file to verify the SQL generated by Oracle BI Server. Outcome : A tested and verified repository file. A consistent repository has met the following requirements: All logical columns are mapped directly or indirectly to one or more physical columns. All logical dimension tables have a logical key. All logical tables have a logical join relationship to another logical table. There are at least two logical tables in the business model: one is a logical fact table, the other is logical dimension table; and both tables may map to the same physical table. There are no circular logical join relationships. A presentation catalog exists for the business model. : : To test the repository by generating some queries, retrieving the results, and

the query log. You finished building the initial business model and now need to test the repository before continuing. You begin by checking the repository for errors using the

Checking Consistency :
Goal Scenario inconsistent business troubleshooting an inconsistent business model. model. This is to further understand the requirements for : : To understand the requirements for a consistent business model. You have successfully tested the business model and made it available to end users for querying. In this practice, you modify your business model to generate an

Enhancing the Product Dimension :

Goal Physical : To import normalized tables that contain additional product information into the layer of the repository.

Scenario layer.

There are product tables that store detailed information about ABCs products. You want to add these tables to the Product dimension in the Business Model and Mapping You import these tables into the repository and create keys and foreign key joins

for the Outcome layer with associated keys and joins. : tables. D1_PRICELIST, D1_PROD_DIET_TYPES, D1_PRODUCT_SUBTYPE, D1_PRODUCT_TYPE, and D1_SUPPLIERS tables imported into the Physical

Creating Multiple Sources for a Logical Table Source (Manual) :

Goal Scenario for the tables. So far, the Product dimension in the Business Model and Mapping layer has only information from the root product table: D1_PRODUCTS. You are ready to add the information from the price list table to the Product dimension, and while doing that, Outcome logical column is added to the Product dimension and mapped to the appropriate physical table. : simplify the data structure (in effect, creating a denormalized logical table). In the Business Model and Mapping layer, the D1_PRICELIST physical table is added to the existing logical table source for the Product dimension and the Price : : To add the information from the price list table to the Product dimension. You have imported the product tables that store detailed information about ABCs products into the Physical layer of the repository and configured keys and joins

Creating Multiple Sources for a Logical Table Source (Automated) :

Goal dimension. Scenario dimension using an alternate method. You create multiple sources for the Product logical table Outcome tables are added to the existing logical table source for the Products logical table. In the Business Model and Mapping layer, the DIET_TYPE, ITEMSUBTYPE, ITEMTYPE, and ITEMSUPPLIER logical columns are added to the Products logical table and: mapped to the appropriate physical tables. : source and simultaneously add the columns to the Product dimension. In the Business Model and Mapping layer, the D1_PROD_DIET_TYPES, D1_PRODUCT_SUBTYPE, D1_PRODUCT_TYPE, and D1_SUPPLIERS physical : : To add the information from the additional product tables to the Product

You have manually added information from the price list table to the Product dimension. You are ready to add information from the other product tables to the Product

Adding a New Logical Table Source :

Goal Scenario while the

: To add a second logical table source to the Product dimension. Examining the physical sources and the Products dimension table, you discover that the Type Code and Type columns are mapped to different physical tables, information for both is stored in a common physical table. In order to model the most economical method for Oracle BI Server to find

information for these two columns, you decide to add a second logical table source to the Product dimension so that Oracle BI Server queries only one table for the Type Code and Type Outcome : information. In the Business Model and Mapping layer, Type is added as second logical table source for the Products logical table.

Creating Calculation Measures by Using Logical Columns :

Goal Scenario can Outcome : potentially help track lost revenue. You use the Expression Builder to configure a formula for Cuts using existing logical columns as objects in the formula. In the Business Model and Mapping layer, the Cuts logical column is added to the SalesFacts logical table. In the Presentation layer, the Cuts presentation column is added to the presentation table. : : To derive a new calculation based on existing business measures. You want to enable users to track the difference between the units ordered and units shipped by selecting a single fact column called Cuts. This business measure

SalesFacts

Creating Calculation Measures by Using Physical Columns :

Goals Scenario you used logical columns to create the calculation. In this practice, you use the Expression Builder again to configure a formula for CutsP using physical columns as objects in the Outcome table. : Formula. In the Business Model and Mapping layer, CutsP is added to the SalesFacts logical Table. In the Presentation layer, CutsP is added to the SalesFacts presentation : : To modify a repository in online mode and create a calculation measure using physical Columns. You want users to be able to track the difference between the units ordered and units shipped by selecting a single fact column called CutsP. In the previous practice,

Creating Calculation Measures by Using the Calculation Wizard :

Goals Scenario : : To modify a repository in offline mode and create calculation measures using the Calculation Wizard. You want to model two calculation measures using the Calculation Wizard, called

Change Units Shipped and Percent Change Units Shipped. The Change Units Shipped measure calculates the difference between the units ordered and units shipped. The Percent Change Units Shipped measure calculates what percentage of the units ordered has not been shipped. The calculation measures that are created by the wizard are based on existing logical columns. You rename these columns CutsW and Percent Outcome : Not Shipped in the Presentation layer. In the Business Model and Mapping layer, Change Units Shipped and Percent Change Units Shipped are added to the SalesFacts logical table. In the Presentation layer, CutsW and Percent Not Shipped are added to the SalesFacts presentation table.

Creating Dimension Hierarchies :

Goal Scenario Oracle BI Server to provide useful calculations. You need to implement three dimensions for ABC: Product, Customer, and Period. Creating dimensions and hierarchies allows you to build level-based measures, to define aggregation rules that vary by dimension, to provide drill down on charts and tables in Answers and dashboards, and to describe the Outcome : content of aggregate sources. In the Business Model and Mapping layer, there are ProductsDim, CustomersDim, and PeriodsDim dimension objects. : : To create dimensions to introduce hierarchies into the business model. Dimensions are metadata objects that allow you to introduce hierarchies into a business model. The dimensions and hierarchies remain hidden to users, but they enable