migrating obiee logical models

7/27/2019 Migrating OBIEE Logical Models

1/15

Delivered Intelligence

Migrating OBIEE Logical Models to use a Data Warehouse :

Part 1A couple of weeks ago I posted an article about a next-generation Oracle BI architecture, where I

advocated building a first cut OBIEE system against your operational applications, producingsome quick win reports, and then over time copying your operational data into a data

warehouse and re-pointing the OBIEE semantic model to point to this instead. The idea behind

this is to allow you to realize some immediate benefits from OBIEE and the semantic model,whilst providing a method by which you can eventually move your data into an Oracle data

warehouse without disturbing the reports you created earlier. Im presenting on this at the

upcoming UKOUG BI & Performance Management Special Event next week in London, you

can download the slides from here.

All well and good, but how well does this work in practice? Well, theres no better way to find

out than to give it a go, so what Im going to do over the next three days is work through three

stages of the type of project Im suggesting:

1. Firstly, well start off with three operational systems (Orders, CRM and HR), and create asingle logical model that maps on top of them.

2. Well then create some reports against this data and save them for checking later.

3. Then, well use OWB to extract this data from the source systems and create a data

warehouse

4. Well then re-map the logical model I created earlier to point to this new data source

5. Then, well check the same reports and see whether they still work ok.

Starting up SQL Developer and taking a look at the three application data sources, the Orders

schema contains a number of tables in a normalized design. Its got an orders table, an orderdetails table, various product tables and so on.
http://www.rittmanmead.com/http://www.rittmanmead.com/2008/03/16/re-wiring-obiee-logical-models-to-use-a-data-warehouse-part-1/http://www.rittmanmead.com/2008/03/16/re-wiring-obiee-logical-models-to-use-a-data-warehouse-part-1/http://www.rittmanmead.com/2008/02/15/a-future-oracle-obiee-architecture/http://www.rittmanmead.com/files/Next-Generation%20Oracle%20BI%20Architecture.pdfhttp://www.rittmanmead.com/2008/03/16/re-wiring-obiee-logical-models-to-use-a-data-warehouse-part-1/http://www.rittmanmead.com/2008/03/16/re-wiring-obiee-logical-models-to-use-a-data-warehouse-part-1/http://www.rittmanmead.com/2008/02/15/a-future-oracle-obiee-architecture/http://www.rittmanmead.com/files/Next-Generation%20Oracle%20BI%20Architecture.pdfhttp://www.rittmanmead.com/


2/15

The CRM schema is a bit simpler, and contains details on customer interactions, their

reason and their outcome. The customers it refers to are in the Orders schema.

The HR Schema contains details of employees, appointments, jobs and departments, with details

of employees being in the Orders schema to record salesperson activity.

So what we have here is a set of normalized tables that contains details on order

activity, refunds, staff appointments and customer interactions. Out of these tables I

therefore want to create a dimensional model, with the fact tables corresponding to the

activities I just mentioned (orders, appointments, customer calls and so on) and the

dimensions corresponding to the customer, product, employee and other lookup tables

in the source schemas.


3/15

Starting off with a new repository then, the first thing I do is start creating this logical

model. Ill start off by modeling the facts first, then Ill build out the dimensions, and only

once thats complete will I start thinking about mapping them to the source data.

I start off them by creating my first fact table, which will model the orders that I receive.

At this initial stage, I just create the logical columns within the fact table; the datatypes

for each column will be defined later once I map source columns to them. Then, I repeat

the process for the dimension tables, again just creating the column names and leaving

the definition of the datatypes until later on. The point here is that you are modeling

what the logical model should be, later on well worry about mapping these objects tothe source data.


4/15

Now, I create logical(complex) joins between the dimensions and fact table that Ive just

created.


5/15

Then, its a case of defining the dimensions for my logical model and setting the

aggregation method for the measures, and the logical model is complete.

So Im now at the point where I have a complete first cut of my logical model. At the

moment, Ive only got a single fact table, later on Ill add some more, but for now my

next step is to map in the source tables. To do this, I use the Import From Database

feature in Administrator and read in the source table metadata.


6/15

One of the most important things you have to do when importing source data into

OBIEE is to make sure all the primary and foreign keys are registered in the physical

model. I therefore go and create a physical database diagram for each schema, making

sure all the tables are properly joined together this for example is the Orders schema.


7/15

Then, I go and create joins between the different schemas, joining for example the

tables in the HR schema to the Order schema via the Orders table, as employee data is

references in orders via the Salesperson ID.


8/15

By repeating this across all of the source schemas, I make it possible for OBIEE to join

together all the source data into a single, virtual source database.

Now its time to map the source data onto the logical model I created earlier. I start off

by dragging the Order ID field from the Order Details physical table and dropping it on

top of the Orders Fact logical table, which adds this physical table as a logical table

source for the fact table and maps the Order ID logical column to the Order ID physical

column.


9/15

I then repeat the process for the Order Line ID column, and the rest of the columns in

this source table that have corresponding entries in the logical fact table.

The Order Details physical table only contains a part of the order information I want to

put into my logical fact table the most granular part that details the individual line items

in the order. I also want to map across some data from the actual Orders table as this

contains the order header information, such as the date of the order and the customer

who made the order. To do this, I first map the existing fact table logical table source to

this additional table, which I can do because the Orders and Order Details tables are

joined together in the physical model.


10/15

Now I can just map in the additional columns from the Orders table to finish off this

logical tables mapping.


11/15

Once this step is complete, Ive mapped in all the source columns for the logical facttable, with the fact tables logical table source pointing to two source tables, the Orders

and Order Details tables.

I then repeat the process for the logical dimension tables, editing the logical table

sources as needed to provide access to additional lookup tables.


12/15

Once this is complete, I then edit the logical tables to add the primary keys, and then

check the state of the logical model at this stage.

Everything is now complete except that I havent yet provided source table mappings for

the time dimension. Theres a reason for this though, in that the source systems dont

have a Times table, all dates are held as Date datatypes in the various transaction

tables and itll therefore be up to me to make a separate table out of them, together with

derived fields such as Month, Day of Week and so on.

In my Orders fact table, time actually crops up a couple of times; theres an Order Date

and a Ship Date, and to be able to analyze these dates independently, Ill need to

create two time dimension tables, one for order data and one for ship date. I rename the

Time dimension table I created earlier on to Order Date instead, and then map in the

Order Date from the Orders table on to the Day ID logical column within it.


13/15

I then edit the logical table source for the Order Date logical table and use the

Expression Editor to derive the various date components from the Order Date physical

column.


14/15

Were now ready to go. I create a simple Presentation model out of my Logical Model,

start up Oracle BI Answers and run a couple of test reports.


15/15

The tabular report comes back OK. What about one that involves dates and a bit more

analysis, say a pivot table report?

Not bad, it looks OK. So, tomorrow well look at the next step taking this operational

data spread over three applications and copying it into a data warehouse, which well do

using Oracle Warehouse Builder 10gR2.

migrating obiee logical models

Documents