One question that often comes up is “How is OWB different from ODI, after all they both do E-LT?” I have written a small series of blogs to be published over the next few months that look at this subject from the point of view of an OWB developer moving to ODI.

To start things off here is the first of the series where I am looking at OWB and ODI in high level terms and point out some of the key differences and similarities. I will be considering the two current releases (OWB 11.2 and ODI 11.1.1.5). Later blogs will look in more detail about the actual development of ETL process and how to orchestrate them.

Both ODI and OWB have a similar (I am being very simplistic here) three-component design of: a metadata repository, a development environment where the developer defines the processes and data flows and a runtime component that executes the code and flows. It is the “how” of these things that is different for the two tools.

Both are repository driven, that is the metadata that describes the ELT processes, data structures being accessed and host of other things is held in a database schema. For OWB the repository is pre-installed (the user needs to create a workspace though) in an Oracle 11gR2 database, optionally, the OWB repository can be installed into an other Oracle database if required. ODI’s repository is installed using Oracle Fusion Middleware’s Repository Creation Utility into a supported (and not necessarily Oracle) database. With ODI, the repository can be shared with other components that use the Fusion Middleware stack such as OBIEE 11g, whether this is desirable would depend on your circumstances and factors such as your organization’s software release process and network topology – just because it is possible to have all on one database does not make it desirable.

Cosmetically, there is a lot of similarity between the two development environments, they are both part of the same unified family of Java IDE applications as JDeveloper and SQLDeveloper; the look and feel is similar, for example double-clicking on a tab has the same effect (it toggles the tab’s panel between full-sized and windowed). What is different however is the content of the windows and navigators and that is a big topic for later postings.In practice, with OWB the key parts of the IDE are those for the development of MAPPINGS and (optionally) the design of process flows to orchestrate mappings. In the ODI world think INTERFACES for mappings and PACKAGES for process flows. This is simplistic though as ODI also has PROCEDURES (code developed in one of the ODI supported languages) and LOAD PLANS (multiple packages orchestrated to execute in serial or parallel). OWB mappings require the developer to include all of the components needed to facilitate the mapping – we connect source columns to target columns through a logic flow of joiners, filters, expressions, aggregates and a whole palette of other activities. Typically, this would generate a single, but large, SQL statement with much use of in-line views. ODI interfaces are simply about connecting source columns to target columns in a logical relationship (we also create expressions, joins and filters here) and allowing the physical implementation to be supplied by a knowledge module.

In its most common usage mode, OWB deploys its executable code into PL/SQL packages in the target database. Even pure SQL set-based insert code is wrapped into a package that contains the control and audit methods that allow it to execute under the control of the Control Center and the OWB runtime. The code generated by ODI depends on the knowledge modules used and might be native SQL which is executed directly against the target database by the Java agent executing the code. Again this is a big topic and more will follow in later blogs.

I laid out the general vocabulary and considerations for Real-time BI in my first post in this series, and then followed up with how to implement Real-time BI using a federated approach that relies on the metadata capabilities OBIEE to blend two different environments into one. Now I’d like to discuss how we might implement a Real-time solution by relying on ETL instead of BI Tool metadata. I call this EDW with a Real-Time Component.

Whereas the Federated OLTP/EDW Reporting option provides us an option to layer real-time data into an otherwise classic batch-loaded EDW, delivering the EDW with a Real-Time Component requires designing an EDW from the ground up that supports real-time reporting. Specifically, we have to design our fact tables to support what Ralph Kimball calls the “real-time partition” in his book The Kimball Group Reader: “To achieve real-time reporting, we build a special partition that is physically and administratively separated from the conventional static data warehouse tables. Actually, the name partition is a little misleading. The real-time partition may be a separate table, subject to special rules for update and query.” We construct a separate section for each of our fact tables to facilitate the following 4 requirements, as defined by Kimball:

1. Contain all activity since the last time the load was run
2. Link seamlessly to the grain of the static data warehouse tables
3. Be indexed so lightly that incoming data can “dribble in”
4. Support highly responsive queries

So we modify our model to support the interaction of real-time and static data, but we also modify our ETL to support this. In fact, to construct an EDW with a Real-Time Component, we have to build some very intricate interaction between the database, the data model and ETL processes. The static fact table is partitioned on a date data-type using standard Oracle partitioning strategies. The real-time partition is structured in such a way as to be loadable throughout the day. In other words, there are no indexes or constraints enabled on the table. ETL against the real-time partition uses a process comparable to traditional load scenarios, but using micro-batch instead, running as often as 100 times a day or more. Alternative methods include transactional style, record-by-record loading, possible using web services or message-based system such as JMS queues.

We effectively want to build a single logical fact table out of the combination of the static EDW fact table and the real-time fact partition. There are several ways to do this. We could use OBIEE fragmentation for this, as we saw in the last post. This would work, but it’s not what I recommend. The reason we used fragmentation in the last post is because we were joining two completely different data sets across conformed dimensions into a unified model. However, with the real-time partition, we have two tables that have exactly the same structure—both using the same surrogate keys to the same dimension tables—just separated across different segments for performance reasons. In this case, I choose to UNION the two datasets with either a database view, or an opaque view in OBIEE.

This works because we no longer have to control which source the rows will come from in particular situations: we simply pull all the rows, and use standard WHERE filters to limit the rows where applicable, and like the pruning the BI Server did for us in the last post, the Oracle Database will do for us in this case. We can, however, still present the static fact tables in situations that merit it: I’m thinking of financial reports here. Accountants don’t usually like their reports giving different results every time they run them.

We have one issue with the load of the real-time partition: we are assuming that we receive all of our dimension data right along with our fact data in clean CDC subscription groups. That would likely be the case if we were pulling all the data for our data warehouse from a single source-system, but with enterprise data warehouses, that is rarely the case. Receiving dimension data early causes no problems with our load scenario; it doesn’t matter if we do the surrogate key lookup for the fact table load hours or days later than the dimensions. Receiving the fact table data early does present us with ETL logic issues: the correct dimension record may or may not be there when it’s time to load the facts.

There is a simple strategy to handle early-arriving facts. In our ETL, we implement a process to insure that our facts are at least reportable intra-day:

1. If a dimension record exists for the current business or natural key we are interested in, then grab the latest record. This is the best we can do at this point, and will usually be the correct value.
2. If no dimension record exists yet for the current natural key, then use a default record type equating to “Not Known Yet.” Though it’s not sexy for intra-day reporting, it at least makes the data available across the dimensions we do know about.
3. As we approach the end of the day and prepare to “close the books” for the current day, we should have run all dimension loads—even late arriving dimensions—so that our dimension tables are all up to date. At this point we run a corrective mapping to update all the fact records in the real-time partition with the right surrogate keys. This would likely be a MERGE statement, or a TRUNCATE/INSERT style mapping. From a performance perspective, my bet is on the latter.

The above mapping loads the real-time partition in a micro-batch style doing an outer join to the CUSTOMER_DIM table and writing the “Not Known Yet” row in case a customer is not found. Also, I am employing a Splitter Operator in OWB, but I tricked it out to force it to load all rows to BOTH tables: SALES_FACT_RT and SALES_STG_RT. The reason for this is that we don’t write dimension natural keys into our fact tables, though I’ve seen that technique employed in some real-time implementations. So when it’s time to run our corrective mapping to correct our fact table data, we just join the SALES_STG_RT table to the now-correct dimension tables and produce the right surrogate keys for each fact record, and load the results into SALES_FACT_RT.

When “closing the books” on the day, we build indexes and constraints on the real-time partition that match those on the partitioned fact table. Once this step is complete, we can then use a partition-exchange operation to combine the real-time partition as part of the static fact table. In Oracle, this is a fast, dictionary update, and occurs almost instantaneously.
Obviously, our partitioning choice for the fact table will determine exactly how this partition-exchange will occur. If we’ll agree to partition the fact table by DAY, then we can use Oracle Interval partitioning, available in Oracle 11gR1 and beyond. We have to make this concession because Interval partitioning tables cannot have partitions in the same table that contain different range-based boundaries. For instance, we can’t have some MONTH-based partitions, while also having some DAY-based partitions, as we can with regular range-based partitioning. Using Interval partitioning is the easiest method, however, because it requires the least amount of partition maintenance as part of the load. For instance, consider the SALES_FACT table listed below, using Interval partitioning on the SALES_DATE_KEY, which we partition on at the DAY grain:

CREATE TABLE sales_fact
       (
         customer_key           NUMBER           NOT NULL,
         product_key            NUMBER           NOT NULL,
         staff_key              NUMBER           NOT NULL,
         store_key              NUMBER           NOT NULL,
         sales_date_key         DATE             NOT NULL,
         trans_id               NUMBER,
         trans_line_id          NUMBER,
         sales_date             DATE,
         unit_price             NUMBER,
         quantity               NUMBER,
         amount                 NUMBER
       )
       partition BY range (sales_date_key)
       interval (numtodsinterval(1,'DAY'))
       (
         partition sales_fact_2006 VALUES less than (to_date('2007-01-01','YYYY-MM-DD'))
       )
       COMPRESS
/

Each time we load a record into SALES_FACT for which no partition currently exists, Oracle will spawn one for the table. But based on our real-time requirements, we will use a partition-exchange operation every day to close the books on the current day processing, so each day, we will need to spawn a clean, new partition to facilitate that partition-exchange. All we need to do to make this happen is issue an insert statement with a DATE value for the partitioning key that equates to TRUNC(SYSDATE). For instance, the following statement would generate a new partition that we can use for the exchange:

SQL> INSERT INTO gcbc_edw.sales_fact
  2         (
  3           customer_key,
  4           product_key,
  5           staff_key,
  6           store_key,
  7           sales_date_key,
  8           trans_id,
  9           trans_line_id,
 10           sales_date,
 11           unit_price,
 12           quantity,
 13           amount)
 14         VALUES
 15         (
 16           -1,
 17           -1,
 18           -1,
 19           -1,
 20           trunc(SYSDATE),
 21           -1,
 22           -1,
 23           SYSDATE,
 24           0,
 25           0,
 26           0
 27         )
 28  /

1 row created.

Elapsed: 00:00:00.01
SQL>

Once the insert has created our new SYSDATE-based partition, we can exchange the real-time partition in for this new partition. We can use the new PARTITION FOR clause — which allows us to reference partition names using partition key values — with a slight caveat. Though we can’t use SYSDATE explicitly in the DDL statement, we can reference it implicitly:

SQL> DECLARE
  2     l_date DATE := SYSDATE;
  3     l_sql  LONG;
  4  BEGIN
  5     l_sql :=   q'|alter table gcbc_edw.sales_fact exchange partition|'
  6             || chr(10)
  7             || q'|for ('|'
  8             || l_date
  9             || q'|') with table gcbc_edw.sales_fact_rt|';
 10
 11     dbms_output.put_line( l_sql );
 12     EXECUTE IMMEDIATE( l_sql );
 13  END;
 14  /

alter table gcbc_edw.sales_fact exchange partition
for ('03/01/2011 09:38:33 PM') with table gcbc_edw.sales_fact_rt

PL/SQL procedure successfully completed.

Elapsed: 00:00:00.07
SQL>

Using the preferred Interval partitioning option, the final “close the books” process flow is shown below. The first step that is taken is to run any late-arriving dimension mappings, in this example, the MAP_CUSTOMER_DIM mapping. Once all the dimensions are up-to-date, we can run the process that corrects all the dimension keys in the real-time partition. Remember, the real-time partition contains small data sets, so updating these records should not be resource intensive. In this scenario, the mapping MAP_CORRECT_SALES_FACT_RT issues an Oracle MERGE statement, but it is quite likely that a TRUNCATE/INSERT statement would work just as well. Once all the data in the real-time partition is correct and ready to go, we issue the MAP_CREATE_PARTITION mapping which uses an insert statement to spawn a new partition, and then the EXCHANGE_PARTITION PL/SQL procedure builds indexes and constraints, and completes the process by issuing the partition-exchange statement.

One of the sources for federation is a classic, batch-loaded EDW, with ETL processes that load conformed dimension tables, followed by fact tables that store the measures and calculations for the enterprise. Oracle Warehouse Builder (OWB), the ETL tool built inside the Oracle Database, is a standard choice for data warehouses built on the Oracle Database, and below, I show a sample process flow of what that batch load might look like:

Logical table sources (LTS’s) are a key feature within the OBIEE semantic model but are often misunderstood. Each LTS represents a single location for data to exist for either a logical fact table, or logical dimension table. A logical table in the BMM can have multiple LTS’s for any of the following reasons:

1. Including different table sources into a single logical table at different levels of granularity. Tables containing data pre-aggregated at a different level in a hierarchy is a common example of this scenario, and is known as “vertical fragmentation”.

2. Including different table sources into a single logical table at the same level of granularity. Having data exist in two different locations, but wanting them to be combined in particular situations, is a common example of this scenario, and is known as “horizontal fragmentation”.

Using horizontal fragmentation in OBIEE, we can map a single logical fact table to multiple LTS’s. For example, suppose we had a physical fact table in our EDW called SALES_FACT. To represent that fact table in the semantic model, we would create a logical fact table in the BMM — called “Sales Fact Realtime” in this example — and create an LTS that maps to the SALES_FACT table. We would also map another LTS which presents this data in the source system as well. As the source system is transactional and likely exists in third-normal form (3NF), the LTS that maps to the transactional schema would likely not be a simple one-to-one relationship. In 3NF, we would likely have to join multiple tables in our source system to represent the logical fact table Sales Fact Realtime:

We would have to do something comparable with the Customer Dimension:

With the two LTS’s, we still need to configure the horizontal fragmentation. For this implementation, I have configured a repository variable called RV_REALTIME_THRESHOLD_DT, with an initialization block that keeps the value consistently at TRUNC(SYSTDATE). I use this variable as the threshold between reporting against the EDW schema and the source system schema.

Once I have the variable available, I can configure the fragmentation on the fact table to use the threshold to determine the appropriate source for a particular record. This is less complicated with the EDW LTS… simple fragmentation configured for all rows with a transaction date less than the threshold date:

Whereas only the source system contains the newer rows needed for layering in real-time data… both the EDW and the source system contain historic data, albeit the EDW data is likely transformed to a certain degree. So we have to configure fragmentation using the RV_REALTIME_THRESHOLD_DT variable, but we also have to use that variable as a filter on the source system LTS to make sure we don’t over allocate the data.

What’s the result of all this complex mapping among different LTS’s in the BMM? OBIEE understands that each source schema is completely segmented, and the tables in each LTS never join to tables in the other LTS… but they do union. OBIEE will construct a complete query against the transactional schema, in this example, joining between the CUSTOMER_DEMOG_TYPES, CUSTOMERS, POS_TRANS and POS_TRANS_HEADER tables. Additionally, OBIEE will construct another complete query against the EDW schema, in this case, only the tables SALES_FACT and CUSTOMER_DIM. The BI Server then logically unions the results between the two source schemas into a single result set that is returned whenever a user builds a report against the logical tables Customer Dim and Sales Fact Realtime. So I run the following report against my fragmented Sales Fact Realtime:

The interesting part is how OBIEE does the logical union. When the EDW and the transactional schema exist in separate databases, the BI Server issues two different database queries and combines them into a single result set in its own memory space. However, if the schemas exist within the same database, as the Oracle Next-Generation Reference Architecture recommends, then the BI Server is able to issue a single query, transforming the logical union into an actual physical union in the SQL statement, as demonstrated in the statement below. Notice that the SQL threshold has been applied, and the UNION was constructed with a single SQL statement pushed down from the BI Server to the Oracle Database holding the Foundation and Presentation and Access layers in our Oracle architecture:

WITH
SAWITH0 AS (select T44105.AMOUNT as c1,
     T44042.CUSTOMER_LAST_NAME as c2,
     T48199.CALENDAR_MONTH_NUMBER as c3,
     T48199.CALENDAR_YEAR as c4,
     T48199.SQL_DATE as c5
from
     GCBC_EDW.DATE_DIM T48199 /* CONFORMED_DATE_DIM */ ,
     GCBC_EDW.CUSTOMER_DIM T44042,
     GCBC_EDW.SALES_FACT T44105
where  ( T44042.CUSTOMER_KEY = T44105.CUSTOMER_KEY and T44105.SALES_DATE_KEY = T48199.DATE_KEY ) ),
SAWITH1 AS (select T43971.SAL_AMT as c1,
     T43901.CUST_LAST_NAME as c2,
     T48199.CALENDAR_MONTH_NUMBER as c3,
     T48199.CALENDAR_YEAR as c4,
     T48199.SQL_DATE as c5
from
     GCBC_EDW.DATE_DIM T48199 /* CONFORMED_DATE_DIM */ ,
     GCBC_CRM.CUSTOMERS T43901,
     GCBC_POS.POS_TRANS T43971,
     GCBC_POS.POS_TRANS_HEADER T43978
where  ( T43901.CUST_ID = T43978.CUST_ID
         and T43971.TRANS_ID = T43978.TRANS_ID
         and T48199.DATE_KEY =  TRUNC(T43978.TRANS_DATE)
         and T43978.TRANS_DATE >= TO_DATE('2011-05-16 00:00:00' , 'YYYY-MM-DD HH24:MI:SS') 
       )),
SAWITH2 AS ((select concat(D0.c4, D0.c3) as c2,
     D0.c5 as c3,
     D0.c2 as c4,
     D0.c1 as c5
from
     SAWITH0 D0
union all
select concat(D0.c4, D0.c3) as c2,
     D0.c5 as c3,
     D0.c2 as c4,
     D0.c1 as c5
from
     SAWITH1 D0)),
SAWITH3 AS (select sum(D3.c5) as c1,
     D3.c2 as c2,
     D3.c3 as c3,
     D3.c4 as c4
from
     SAWITH2 D3
group by D3.c2, D3.c3, D3.c4)
select distinct 0 as c1,
     D2.c2 as c2,
     D2.c3 as c3,
     D2.c4 as c4,
     D2.c1 as c5
from
     SAWITH3 D2
order by c2, c4, c3

But OBIEE is also capable of doing the fragmentation equivalent of “partition pruning.” When the BI Server has enough information to know that the entire result set will come from a single source, then the SQL will be issued against only one of the LTS’s. For instance, if I click on one of the “SQL Date” attributes in the above report which will apply a filter on the fragmentation column, the BI Server will know that the result set only comes from the EDW:

WITH
SAWITH0 AS (select sum(T44105.AMOUNT) as c1,
     concat(T48199.CALENDAR_YEAR, T48199.CALENDAR_MONTH_NUMBER) as c2,
     T48199.DATE_KEY as c3,
     T48199.SQL_DATE as c4,
     T44042.CUSTOMER_LAST_NAME as c5
from
     GCBC_EDW.DATE_DIM T48199 /* CONFORMED_DATE_DIM */ ,
     GCBC_EDW.CUSTOMER_DIM T44042,
                   GCBC_EDW.SALES_FACT T44105
where  ( T44042.CUSTOMER_KEY = T44105.CUSTOMER_KEY
         and T44042.CUSTOMER_LAST_NAME = 'Carr'
         and T44105.SALES_DATE_KEY = T48199.DATE_KEY
         and T48199.SQL_DATE = TO_DATE('2009-07-03' , 'YYYY-MM-DD')
         and concat(T48199.CALENDAR_YEAR, T48199.CALENDAR_MONTH_NUMBER) = '200907' )
group by T44042.CUSTOMER_LAST_NAME,
         T48199.DATE_KEY,
         T48199.SQL_DATE,
         concat(T48199.CALENDAR_YEAR, T48199.CALENDAR_MONTH_NUMBER))
select distinct 0 as c1,
     D1.c2 as c2,
     D1.c3 as c3,
     D1.c4 as c4,
     D1.c5 as c5,
     D1.c1 as c6
from
     SAWITH0 D1
order by c2, c5, c4, c3

Before closing this section of the real-time discussion, I want to take a minute to identify the strengths and weaknesses of this approach. As far as strengths go, we have several items that register with this solution. First off… this is a low-latency solution. When using the Oracle Next-Generation Reference Architecture, we have the latency of streaming, or “GoldenGating,” the content from the source system to the DW database. With clients we’ve had in the past, this can run anywhere from a few seconds to several minutes, depending on the solution implemented. Additionally, there is no complex logical or physical data modeling and supporting ETL to deliver this solution, as there is with the EDW with a Real-Time Component, which we will explore in the next posting.

As far as weaknesses go, there will be a fair amount of complex RPD semantic-layer modeling. Obviously, the degree of difficulty depends on a number of factors: number of source systems integrated, number of subject areas, complexity of reports delivered, etc. Also, increased complexity of RPD modeling may introduce performance degradation as OLTP schemas have to be transformed “on the fly” to star schemas by the BI Server. But keep in mind… we are typically only doing this for at most a day’s worth of data, so with proper database tuning, this content can usually perform quite well.

Next up: EDW with a Real-Time Component

For the purposes of this series of blog posts, I’m defining real-time as anything that pushes the envelope on the standard daily batch load window. We will explore some of the architectural options available in the standard Oracle BI stack (Oracle Database plus Oracle Business Intelligence) for the removal of the latency inherent in this well-established paradigm.

I’ve categorized 4 basic types of DW/BI systems as they relate to real-time BI.

Our solution with the least amount of latency, but also with the worst performance, is simple reporting against the OLTP database. Our next approach, with more latency but better performance, is a federated approach, using a BI tool such as OBIEE to “combine” results from the data warehouse with fresh data from the OLTP source system schema. In this scenario, we have a typical data warehouse, loading in daily batch cycle, but we layer in fresh data from the source for intra-day records. We improve upon query performance by using an optimized data warehouse for the majority of our data, with gains for real-time reporting by including the non-tranformed data directly from the source system schema. Our next approach is using a traditional data warehouse that has been optimized to store the results of micro-batch loads. In this scenario, instead of running the batch load process once every 24 hours, we instead run it several times a day, usually between one and ten times an hour. We extend the standard data warehouse architecture to have a real-time component, which means, we modify our fact tables, our dimension tables, and the ETL processes that run them to better handle the micro-batch processing. Finally, last on the list in terms of latency, but our best choice for pure performance, is the traditional, batch-loaded data warehouse.

As the image above suggests, I’m most interested in the two squares in the middle, as I think they are the only ones that qualify as both “real-time” and “BI”. In the series of blog posts to follow, I’ll be talking about these two solutions, how they compare to each other, and what are some of the keys in determining “readiness” for delivering them. Before moving on, however, I need to make a pitch for the Oracle Next-Generation Reference DW Architecture, which Mark first spoke about here.

Regardless of which of the two solutions that we opt for, we should implement the staging, foundation and performance layers as the best overall approach to building and sustaining business intelligence. For example… even if we should to use our source system schema to address some portion of our reporting requirements, we should still stream, or “GoldenGate,” our data from the actual live transactional system to the database where we do our reporting. But I’m not arguing in favor of simply having another “reporting” copy of our source system: I’m advocating that we use change data capture strategies to populate a foundation layer where we maintain a complete history of all the source system changes. Only then are we fully insulated against any change in user behavior and the possible change in reporting requirements that follows.

Be on the lookup for the first follow-up to this, where I will explain the EDW with Federated OLTP Data choice, and demonstrate how to achieve this using OBIEE 11g.

Taking a step back and looking at the ETL process we felt there was a lot of complexity unnecessarily created by decomposing the process into a number of program units or mappings. In our view this process creates the following problems:

• A large amount of processing time was wasted on the inter-communication of these mappings.
• Unnessary temporary storage objects and created and populated in the database.
• A separate technology is required to orchestrate all the mappings.
• It encouraged multiple developers to work on the ETL process thereby increasing the risk of mis-communication and mis-aligned interfaces.

In response to this Rittman Mead have developed the One Mapping Paradigm. We believe that you should put all your ETL code into one mapping, and as such have called this approach the One Mapping Paradigm (OMP). The goal of this approach is to encapsulate your entire ETL routine into one mapping or program unit.

We feel this approach adheres to some of the fundamental tennets of software development: encapsulation (everything is in the one mapping) and decoupling (there are no external dependencies). Further it completely negates the need for old bugbear re-usability, you now don’t even need to re-use code, just use it once, all in the same mapping. Most importantly OMP will also provides a reduction in development costs: you now only need one developer.

Our extensive research has also developed a series of steps you can follow to deliver your One Mapping. You should note that the One Mapping that OMP generates will be extremely complex, only by following these can you address the complexity of the mapping that will be generated.

OMP follows a black hole development approach where it is crucial for the developer to do as much development as possible without any outside interfere from either peers or the business. This allows the developer to focus solely on the development task in hand, which is a must when developing extremely complex code. It is also essential that the developer is allowed to proceed as far through the process as possible without stopping for other distracting activities like testing. In order to follow the OMP I have built the following example using Oracle Warehouse Builder.

• Step 1: source objects – create new mapping a drag all your source objects onto the canvas – it is important to arrange these in a straight line on the left hand side of the canvas.
• Step 2: add all your join operators to combine the data. A couple of tips here, (1) add predicates into the join conditions to avoid using filter operators (2) keep the data transition lines as straight as possible for performance reasons.
• Step 3: add any expression or transformational operators required – these should really be added to the middle of the canvas.
• Step 4: add all your target tables – these are added to the right hand side of your canvas. You are in the home straight now, but you may find this the trickiest part and we recommend using at least a 29″ monitor to complete this process.
• Step 5: unit test – note there is no orchestration or integration required, as you only have One Mapping.
• Step 6: release to production – you can just release you mapping straight into production, overwriting whatever was there before. There is no system or integration testing required as there is only one piece of code. UAT is further bypassed as your unit testing verifies whether the entire ETL process works or not.

We are looking for beta testers for this concept, so if you want to try the OMP for your ETL code, please contact me at omp@rittmanmead.com.

On Thursday, I’ll be giving three technical presentations, each with a strong database and data warehousing focus:

Thursday, 9:00 AM, 402/403: Resuming, Restarting, Restoring: Three R’s of Data Warehouse Fault Tolerance
Thursday, 1:30 PM, 404: Real-Time Data Warehousing with Oracle Business Intelligence 11g and the Oracle Database
Thursday, 2:45 PM, 406: Deploying a Dimensional Model on the Oracle Database

If you are planning on attending RMOUG, let me know in the comments of this post, or drop by one of my sessions and introduce yourself afterwards. We should have some very nice weather in Denver, so I’m planning on getting out and seeing a bit of the city.

First, I need a dimension table that I can work with, and one that most of us are familiar with. I’m going to use the SH.PRODUCTS table… but with a few modifications. The dimension tables in the SH schema don’t use surrogate keys, so I’m going to add one. Additionally… I’m going to pare down the columns a little bit, while also updating the data slightly to be a little more standard:

SQL> create table stewart.product_dim
  2  as select
  3  prod_id product_key,
  4  prod_id,
  5  prod_name,
  6  prod_desc,
  7  prod_status,
  8  prod_eff_from,
  9  prod_eff_to,
 10  prod_valid
 11  from sh.products;

Table created.

SQL> update stewart.product_dim
  2     set prod_eff_to='12/31/9999',
  3         prod_valid='Y'
  4   where prod_valid='A';

72 rows updated.

SQL> update stewart.product_dim
  2     set prod_valid='N'
  3   where prod_valid='I';

0 rows updated.

SQL>

Notice that, with the SH.PRODUCTS table, there are only ‘Active’ rows in the table. You’ll see how this degrades the quality of the test case later, but I’ll trudge on. I’ll also add a few indexes to demonstrate Transcend’s capability for handling those, just like we saw with the Mapping. I’ll do some dog-fooding and use the product to generate these indexes:

SQL> BEGIN
  2     trans_etl.build_indexes
  3     ( p_owner        => 'stewart',
  4       p_table        => 'product_dim',
  5       p_source_owner => 'sh',
  6       p_source_table => 'products',
  7       p_index_type   => 'bitmap'
  8     );
  9  END;
 10  /
1 index creation process executed for STEWART.PRODUCT_DIM

PL/SQL procedure successfully completed.

SQL>

I’ll also need a source table, which would be the target table for our ETL mapping. Hold tight… let me explain. Transcend does not try to replace your ETL tool… it just tries to make some of the heavy-lifting easier. As the SCD implementation in most of these tools is either non-standard or non-perfromant, we tried to deliver a best practices approach that could be easily called from any tool. Obviously, this would work well with custom-developed ETL mappings as well. So all you have to do in your ETL mapping is construct the business logic for how the data set from your source systems needs to be joined and transformed to be ready to roll into your dimension. You drop that in a staging table, tell Transcend that this data needs to make it’s way into the dimension table, and then the product will do the rest. My holding table will be called PRODUCT_SRC, and needs a subset of the columns that exist in the dimension table. The only columns that aren’t required are the ones that are calculated and stored to facilitate SCD processing. For my table, this is: PRODUCT_KEY, PROD_EFF_TO, and PROD_VALID. I’ll add a few rows to this table from SH.PRODUCTS and modify them to look like source-system updates:

SQL> create table staging.product_src
  2  as select
  3  prod_id,
  4  prod_name,
  5  prod_desc,
  6  prod_status,
  7  prod_eff_from
  8  from sh.products
  9  where rownum < 11;

Table created.

SQL> update staging.product_src
  2  set prod_name = 'New '||prod_name;

10 rows updated.

SQL>

Now I need to configure the Dimension and how I want it loaded, much like I configured the Mapping in the last post. Actually, many of the parameters are the same, but there are some new ones in there as well:

SQL> BEGIN
  2     trans_adm.create_dimension
  3     ( p_mapping          => 'map_product_dim',
  4       -- dimension table
  5       p_owner            => 'stewart',
  6       p_table            => 'product_dim',
  7       -- SCHEMA for intermediate tables
  8       p_staging_owner    => 'staging',
  9       -- intermediate source table
 10       p_source_owner     => 'staging',
 11       p_source_table     => 'product_src',
 12       -- SEQUENCE for the dimension
 13       p_sequence_owner   => 'stewart',
 14       p_sequence_name    => 'product_key_seq',
 15       p_default_scd_type => 2,
 16       p_description      => 'load for PRODUCT_DIM',
 17       -- MANAGE indexes and constraints
 18       p_indexes          => 'both',
 19       p_index_type       => 'bitmap',
 20       p_constraints      => 'both'
 21     );
 22  END;
 23  /

PL/SQL procedure successfully completed.

SQL>

So I’ve told Transcend about my dimension table, including the sequence to use for the surrogate key, the default SCD type (more on this later), and the staging (or work) schema to hold any intermediate tables that Transcend needs to create. I’m also registering the PRODUCT_SRC table which I described above, and I’m telling it how to handle constraints and indexes, which I described in the last post.

With the basics around the dimension table configured, I now need to work on the columns. I’ve configured the default SCD type as a Type 2. That means that I don’t have to do anything with the columns that are regular dimensional attributes for which I want to capture change. So the only things I need to register with Transcend are the following: any Type 1 dimensional attributes, the surrogate key, the natural key, the current indicator column, the effective date and the expiration date:

SQL> BEGIN
  2     trans_adm.create_dim_attribs
  3     ( p_mapping       => 'map_product_dim',
  4       p_surrogate     => 'product_key',
  5       p_effective_dt  => 'prod_eff_from',
  6       p_expiration_dt => 'prod_eff_to',
  7       p_current_ind   => 'prod_valid',
  8       p_nat_key       => 'prod_id',
  9       p_scd1          => 'prod_status'
 10     );
 11  END;
 12  /

PL/SQL procedure successfully completed.

SQL> commit;

Commit complete.

SQL>

It’s worth noting that the P_NAT_KEY and P_SCD1 columns take comma-separated lists of values in case you need to pass multiple column names in. I can also use the P_SCD2 parameter if my default SCD type was a 1.

Since I haven’t told Transcend the specific approach I want to take to getting the rows into the dimension table, the default ‘merge’ methodology is employed. This represents a change in the default behavior beginning in version 2.5 away from the old default of ‘exchange’, which I will demonstrate in a bit. A single “INSERT into… SELECT…” statement will be issued to pull all the rows with a PROD_VALID of ‘Y’ from PRODUCT_DIM along with all the incoming rows from PRODUCT_SRC into an intermediate table, doing complex SQL analytics along the way to evaluate and process any Type 1 and Type 2 changes, as well as setting PROD_EFF_TO, PROD_EFF_FROM and PROD_VALID. The changes are then MERGED back into the dimension table. Because we use a single, set-based process, the performance over comparable row-by-row processing can be substantial. Executing the Dimension functionality is done as if it were a regular mapping:

SQL> exec trans_etl.start_mapping( 'map_product_dim' );
Pre-mapping processes beginning
Pre-mapping processes completed

PL/SQL procedure successfully completed.

SQL> -- here you would execute the mapping
SQL> exec trans_etl.end_mapping( 'map_product_dim' );
Post-mapping processes beginning
Table STAGING.STG$PRODUCT_DIM created
Number of records processed with analytics into STAGING.STG$PRODUCT_DIM: 82
5 constraint disablement processes for STEWART.PRODUCT_DIM executed
1 index and 0 local index partitions affected on table STEWART.PRODUCT_DIM
Number of SCD1 attributes updated with a MERGE in STEWART.PRODUCT_DIM: 0
Number of records merged into STEWART.PRODUCT_DIM: 82
1 index rebuild process for table STEWART.PRODUCT_DIM executed
5 constraint enablement processes for STEWART.PRODUCT_DIM executed
Post-mapping processes completed

PL/SQL procedure successfully completed.

SQL>

It’s not an overly impressive test case because, as I mentioned above, there are no historical rows in this table at all: PROD_VALID is ‘Y’ for every record. Transcend brings all the current dimension rows into the working set for the following reasons: the effective dates and the current indicator might have to be modified, and all the current Type 2 attributes have to be in the working set to be able to determine whether there have been Type 2 changes. But before this, a separate MERGE statement executes to update all the Type 1 changes for the historical rows. A Type 1 change is seen as a correction, and requires updating ALL the rows in the dimension table for that entity, even ones that may be years old.

Now, I’ll reset the test case in preparation for using a PARTITION EXCHANGE instead of a MERGE. This will issue two insert statements: one that does the same insert statement as above, and another that brings all the old dimension rows into the intermediate table as well. This is because we are replacing PRODUCT_DIM table with a brand new version of the table. Exchanges are handy in cases where 100% uptime is required, and users can’t afford to be down for even the amount of time it takes to load dimension tables. Partition exchanges don’t disrupt queries to the dimension tables, as the load is done to the intermediate table while the dimension is still available. When that load is complete, the dimension table is just swapped out for the new version of the table in an instantaneous dictionary update. Transcend makes this possible by creating the intermediate table with a single partition using MAXVALUE so that the one partition contains all data, and swapping that single partition with the dimension table. Note, however, that we still have to process all the Type 1 updates to the historical rows the same as we did before. However, we do that in the intermediate table so it is done prior to being exchanged in to the dimension table:

SQL> BEGIN
  2     trans_adm.modify_dimension
  3     ( p_mapping        => 'map_product_dim',
  4       p_replace_method => 'exchange'
  5     );
  6  END;
  7  /

PL/SQL procedure successfully completed.

SQL> exec trans_etl.start_mapping( 'map_product_dim' );
Pre-mapping processes beginning
Pre-mapping processes completed

PL/SQL procedure successfully completed.

SQL> -- here you would execute the mapping
SQL> exec trans_etl.end_mapping( 'map_product_dim' );
Post-mapping processes beginning
Table STAGING.STG$PRODUCT_DIM created
Number of history records inserted into STAGING.STG$PRODUCT_DIM: 0
Number of records processed with analytics into STAGING.STG$PRODUCT_DIM: 82
Number of SCD1 attributes updated with a MERGE in STAGING.STG$PRODUCT_DIM: 10
Statistics from STEWART.PRODUCT_DIM transferred to partition PMAX of STAGING.STG$PRODUCT_DIM
1 index creation process executed for STAGING.STG$PRODUCT_DIM
5 constraints built for STAGING.STG$PRODUCT_DIM
STEWART.PRODUCT_DIM exchanged for partition PMAX of table STAGING.STG$PRODUCT_DIM
Post-mapping processes completed

PL/SQL procedure successfully completed.

SQL>

Again… since there are no historical records in the PRODUCT_DIM table, the first insert brought over no records.

And in case you aren’t confused enough as is… Transcend supports late-arriving dimensions as well. In the default mode, if you get an incoming dimension row that has en effective date before the effective date of the current row for that dimensional entity, then the PROD_EFF_TO and PROD_EFF_FROM date ranges, as well as the tracking of SCD 2 attributes, won’t work correctly. But if we turn on the late-arriving feature, Transcend will handle this seamlessly. It sets the effective dates and current indicator correctly over the entire range of data, but more importantly… it will represent the history of SCD 2 attributes correctly regardless of which order the rows came in. The complex analytics statement used to evaluate Type 1 and Type 2 attributes, as well as setting effective dates and current indicators, will process the entire dimension table along with the incoming rows. Though this sounds like it would be excruciatingly slow, the fact is that it isn’t. Compared to the typical row-by-row approach that ETL tools take, requiring lots and lots of updates, a pure set-based process, even if it reads the entire dimension table, is generally the winner. But remember, this is only required if late-arriving dimensions are a possibility. However, for many clients, the processing of the entire table combined with a partition exchange outperforms the MERGE approach of just loading the current records. Updates are expensive folks.

You can see that the process is down to a single insert again:

SQL> BEGIN
  2     trans_adm.modify_dimension
  3     ( p_mapping       => 'map_product_dim',
  4       p_late_arriving => 'yes'
  5     );
  6  END;
  7  /

PL/SQL procedure successfully completed.

SQL> exec trans_etl.start_mapping( 'map_product_dim' );
Pre-mapping processes beginning
Pre-mapping processes completed

PL/SQL procedure successfully completed.

SQL> -- here you would execute the mapping
SQL> exec trans_etl.end_mapping( 'map_product_dim' );
Post-mapping processes beginning
Table STAGING.STG$PRODUCT_DIM created
Number of records processed with analytics into STAGING.STG$PRODUCT_DIM: 82
Statistics from STEWART.PRODUCT_DIM transferred to partition PMAX of STAGING.STG$PRODUCT_DIM
1 index creation process executed for STAGING.STG$PRODUCT_DIM
5 constraints built for STAGING.STG$PRODUCT_DIM
STEWART.PRODUCT_DIM exchanged for partition PMAX of table STAGING.STG$PRODUCT_DIM
Post-mapping processes completed

PL/SQL procedure successfully completed.

SQL>

The moral of this story: if you have any Type 1 attributes, don’t immediately go for the default MERGE approach with it’s multiple updates required. Give the late-arriving approach a try, even if you don’t have any. You might see the single insert statement outperform all the rest.

When you think of a Mapping in Transcend, try not to think about the common source-to-target functionality that you would create in an ETL tool or a custom mapping. Instead, try to consider EVERYTHING ELSE that you might need to couple with the mapping that ETL tools don’t provide: index maitenance, constraint maintenance, segment-switching, etc. If you look at the above posts, you will see a lot of features that can be implemented with a series of calls. That’s not difficult, but it’s still code, right? But what if you could “bundle” all of the necessary calls that need to be made BEFORE and AFTER a mapping into one easy name, so that you could pass that name to just two calls–one before the mapping and one after–to get all the necessary features needed to roll that mapping? Well… then you’d have a Transcend Mapping!

In addition to all the heavy-lifting, we wanted to make sure Transcend did the simple things right, so we first created an instrumentation framework that could be used consistently throughout the product. This framework is affectionately called Evolve and includes auditing, logging (with different levels), process registration with the Oracle Database, and a DEBUG mode. So the very basic skeleton of a Mapping in Transcend is the ability to log messages in a logging table, set the MODULE and ACTION contexts with the database, and capture exception errors all the way back to their source. To put together a standard mapping, I would make the following call:

SQL> BEGIN
  2     trans_adm.create_mapping( p_mapping => 'map_sales_fact' );
  3  END;
  4  /

PL/SQL procedure successfully completed.

SQL>

Now, whenever I execute the MAP_SALES_FACT mapping in either my ETL tool or my custom ETL processing, I need to make a single call before the mapping runs, and a single call after:

SQL> exec trans_etl.start_mapping( p_mapping => 'map_sales_fact' );
Pre-mapping processes beginning
Pre-mapping processes completed

PL/SQL procedure successfully completed.

Elapsed: 00:00:00.03
SQL> -- here you would execute the mapping
SQL> -- notice that the session has been instrumented;
SQL> select SYS_CONTEXT( 'USERENV', 'MODULE' ) module,
  2         SYS_CONTEXT( 'USERENV', 'ACTION' ) action
  3    from dual;

MODULE                         | ACTION
------------------------------ | --------------------------------
mapping map_sales_fact         | execute mapping

1 row selected.

Elapsed: 00:00:00.00
SQL> exec trans_etl.end_mapping( p_mapping => 'map_sales_fact' );
Post-mapping processes beginning
Post-mapping processes completed

PL/SQL procedure successfully completed.

Elapsed: 00:00:00.01
SQL> 

So at the very least, Transcend provides the ability to instrument the mapping so the session can be identified easily in V$SESSION, as well as setting a consistent environment for tracing sessions with DBMS_MONITOR, which allows for tracing sessions based on combinations of MODULE and ACTION. But there is a lot more we can do with Transcend. We can easily incorporate index maintenance by changing our configuration slightly. All the features previously described around index maintenance can be turned on and off with a simple configuration change (NOTE: the ‘both’ parameter specifies that we want to mark indexes both UNUSABLE before the mapping and USABLE again after the mapping. We could have also passed “unusable”,”usable” or “ignore” ):

SQL> BEGIN
  2     trans_adm.modify_mapping( p_mapping         => 'map_sales_fact',
  3                               p_table           => 'sales_fact',
  4                               p_owner           => 'stewart',
  5                               p_indexes         => 'both',
  6                               p_index_type      => 'bitmap',
  7                               p_idx_concurrency => 'yes'
  8                             );
  9  END;
 10  /

PL/SQL procedure successfully completed.

SQL> 

Now I simply execute the exact same calls I made before, but now the new functionality is implemented:

SQL> exec trans_etl.start_mapping( p_mapping => 'map_sales_fact' );
Pre-mapping processes beginning
5 indexes and 0 local index partitions affected on table STEWART.SALES_FACT
Pre-mapping processes completed

PL/SQL procedure successfully completed.

SQL> -- here you would execute the mapping
SQL> exec trans_etl.end_mapping( p_mapping => 'map_sales_fact' );
Post-mapping processes beginning
Rebuild processes for unusable indexes on 28 partitions of table STEWART.SALES_FACT submitted to the Oracle scheduler
No matching unusable global indexes found
Post-mapping processes completed

PL/SQL procedure successfully completed.

SQL>  

Additionally, all the constraint maintenance features described here can be implemented with another call to MODIFY_MAPPING:

SQL> BEGIN
  2     trans_adm.modify_mapping( p_mapping         => 'map_sales_fact',
  3                               p_constraints     => 'both',
  4                               p_constraint_type => 'P',
  5                               p_con_concurrency => 'no'
  6                             );
  7  END;
  8  /

PL/SQL procedure successfully completed.

SQL> exec trans_etl.start_mapping( p_mapping => 'map_sales_fact' );
Pre-mapping processes beginning
5 indexes and 0 local index partitions affected on table STEWART.SALES_FACT
1 constraint disablement process for STEWART.SALES_FACT executed
Pre-mapping processes completed

PL/SQL procedure successfully completed.

SQL> -- here you would execute the mapping
SQL> exec trans_etl.end_mapping( p_mapping => 'map_sales_fact' );
Post-mapping processes beginning
Rebuild processes for unusable indexes on 28 partitions of table STEWART.SALES_FACT submitted to the Oracle scheduler
No matching unusable global indexes found
1 constraint enablement process for STEWART.SALES_FACT executed
Post-mapping processes completed

PL/SQL procedure successfully completed.

SQL> 

And finally, we can implement segment-switching using partition exchanges, table renames… and now a new option in 2.5: MERGE statements. As described in the above post, Transcend Mappings can provide the functionality to facilitate getting the rows from one segment into another. So you could create a mapping that loads all the new rows for a fact table, and propagate those changes into another table using a trio of possibilities. Formerly, only the options to do this with partition exchanges and table renames made sense, because those were the most difficult to reproduce in and ETL tool, and thus required custom-coding. As I’ve worked with numerous clients since writing the initial version of Transcend, I’ve discovered that some of the non-Oracle ETL tools have a tough time replicated the functionality of a MERGE statement. So now we can MERGE all the rows from one segment into another at the end of an ETL mapping by simply configuring this feature with Transcend:

SQL> BEGIN
  2     trans_adm.modify_mapping( p_mapping         => 'map_sales_fact',
  3                               p_replace_method  => 'merge',
  4                               p_staging_owner   => 'stewart',
  5                               p_staging_table   => 'sales_stg'
  6                             );
  7  END;
  8  /

PL/SQL procedure successfully completed.

SQL> exec trans_etl.start_mapping( p_mapping => 'map_sales_fact' );
Pre-mapping processes beginning
0 indexes and 80 local index partitions affected on table STEWART.SALES_FACT
1 constraint disablement process for STEWART.SALES_FACT executed
Pre-mapping processes completed

PL/SQL procedure successfully completed.

SQL> -- here you would execute the mapping
SQL> exec trans_etl.end_mapping( p_mapping => 'map_sales_fact' );
Post-mapping processes beginning
Number of records merged into STEWART.SALES_FACT: 918843
Rebuild processes for unusable indexes on 16 partitions of table STEWART.SALES_FACT submitted to the Oracle scheduler
No matching unusable global indexes found
1 constraint enablement process for STEWART.SALES_FACT executed
Post-mapping processes completed

PL/SQL procedure successfully completed.

SQL> 

And we can still use the segment-switching options from the previous version, including the popular “exchange” option:

SQL> BEGIN
  2     trans_adm.modify_mapping( p_mapping         => 'map_sales_fact',
  3                               p_replace_method  => 'exchange'
  4                             );
  5  END;
  6  /

PL/SQL procedure successfully completed.

SQL> exec trans_etl.start_mapping( p_mapping => 'map_sales_fact' );
Pre-mapping processes beginning
Pre-mapping processes completed

PL/SQL procedure successfully completed.

SQL> -- here you would execute the mapping
SQL> exec trans_etl.end_mapping( p_mapping => 'map_sales_fact' );
Post-mapping processes beginning
6 index creation processes submitted to the Oracle scheduler for STEWART.SALES_STG
Creation of constraint SALES_STG_PK executed
1 constraint built for STEWART.SALES_STG
STEWART.SALES_STG exchanged for partition SALES_Q4_2003 of table STEWART.SALES_FACT
1 constraint dropped on STEWART.SALES_STG
6 indexes dropped on STEWART.SALES_STG
Post-mapping processes completed

PL/SQL procedure successfully completed.

SQL> 

Mike Durran’s talk on Monday about the new OBIEE 11g features was enlightening. We’ve seen some of the features in the beta release, but having Mike demonstrate the OEM integration, security improvements, and general industrialization of OBIEE was eye-opening. As Rittman Mead has been instrumental in implementing the 10g release of OBIEE for clients over the years, and working with those clients (and the world at large via the blog) to try and circumvent some of the limitations in the current product, it’s good to see that Oracle is listening to the needs of their clients. Mark’s presentation on the internals of the BI Server was great as usual. I’ve seen this content before, but it was enjoyable to revisit. The academic approach Mark took in trying to define the sometimes undocumented behavior of the BI Server shows the right way to approach product-discovery.

Also good to see was David Allan’s presentation on “right-time” loading with Oracle OWB 11gR2. David knows this product as well as anyone, and he has a handle on what the product can do now as well as what clients want to see in the future. David demonstrated that OWB can make use of GoldenGate in a (reasonably) uncomplicated way. He also knows his way around a pint of Guinness (Scot’s drink Irish stout?), and though I got less sleep than I should have, I had more fun than I deserved. I also learned quite a bit from Holger Friedrich’s presentation on Pushing the Envelope with OWB. I always get questions from clients about how to properly do SCM with OWB, and I think now I just might start handing them a copy of Holger’s presentation. Really, really good stuff Holger.

My session on New Data Warehousing Features in 11gR2 was well-attended, and I think it delivered some good content around parallelism-enhancements, summary management improvements, and cool new tricks with SQL Analytics. I think the LISTAGG function was of particular interest… so that old workhouse STRAGG now has a shorter shelf-life. That’s OK… I’m sure Tom is tired of answering questions around it anyway. I’d like to thank Tim Tow of AppliedOLAP for giving me a great introduction.

I enjoyed the BI Panel moderated by Mark, and all the panelists and attendees had a good chance to discuss the future of BI within Oracle. Again we had Mike Durran, together with Bob Ertl, Joe Leva and Holger Friedrich. The contrasting perspectives of implementors and product managers rounded-out a great discussion, and I saw Bob take numerous notes about what customers are hoping for in the future direction of OBIEE.

Finally was the OWB Deep-Dive this morning with myself, Mark and Holger. It was a last-minute replacement for a cancelled session, but I think the content was very good and well-received. We rarely get a chance to go in-depth in our sessions, nor answer questions for half an hour either. The attendees were all familiar faces from our other sessions for the whole week, and we appreciate their dedication for seeking out the session even though it wasn’t in the session catalog, for getting started with us at 8:30 in the morning, and for sticking with us for three hours.

Thanks to Maria Colgan, Jean-Pierre Dijcks, Holger Fiedrich, Mike Durran, Mark Rittman and David Allan for the extra-curricular activities. I think I’ll sleep in late tomorrow.

“Deriving and Sharing Business Intelligence Metadata” looks at how OBIEE repositories can be automatically derived from an OWB11gR2 dimension model, taking the dimensions, facts, hierarchies and measures within your OWB project and translating them into the equivalent metadata in an OBIEE RPD. The article also comes with a OWB metadata export file that you can use to try out the techniques in the article, and if you’re interested in reading more about this or other OWB11gR2 features, check out this posting that catalogs all the articles on this new release that are available on our blog.