Characteristics of the Default Physical Model

The default physical model of Oracle Communications Data Model defines tables, KPIs, data mining models, and OLAP cubes.

• 1800+ tables and 40,000+ columns
• 5000+ industry-specific measures and KPIs
• 7 pre-built data mining models
• 22 pre-built OLAP cubes

The default physical model of the Oracle Communications Data Model shares characteristics of a multischema "traditional" data warehouse but defines all data structures in a single schema.

Layers in a "Traditional" Data Warehouse

Historically, three layers are defined for a data warehouse environment:

• Staging layer. This layer is used when moving data from the operational system and other data sources into the data warehouse itself. It consists of temporary loading structures and rejected data. Having a staging layer enables the speedy extraction, transformation and loading (ETL) of data from your operational systems into data warehouse without disturbing any of the business users. It is in this layer the much of the complex data transformation and data quality processing occurs. The most basic approach for the design of the staging layer is as a schema identical to the one that exists in the source operational system.

  Note:

  In some implementations this layer is not necessary, because all data transformation processing is done as needed as data is extracted from the source system before it is inserted directly into the foundation layer.

• Foundation or integration layer. This layer is traditionally implemented as a Third Normal Form (3NF) schema. A 3NF schema is a neutral schema design independent of any application, and typically has many tables. It preserves a detailed record of each transaction without any data redundancy and allows for rich encoding of attributes and all relationships between data elements. Users typically require a solid understanding of the data to navigate the more elaborate structure reliably. In this layer data begins to take shape and it is not uncommon to have some end-user application access data from this layer especially if they are time sensitive, as data becomes available here before it is transformed into the Access and Performance layer.

• Access layer. This layer is traditionally defined as a snowflake or star schema that describes a "flattened" or dimensional view of the data.

Layers in the Default Oracle Communications Data Model Warehouse

Oracle Communications Data Model warehouse environment also consists of three layers However, as indicated by the dotted line in Figure 2-1, in the Oracle Communications Data Model the definitions of the foundation and access layers are combined in a single schema.

Figure 2-1 Layers of an Oracle Communications Data Model Warehouse

Description of "Figure 2-1 Layers of an Oracle Communications Data Model Warehouse"

The layers in the Oracle Communications Data Model warehouse are:

• Staging layer. As in a "traditional" data warehouse environment, an Oracle Communications Data Model warehouse environment can have a staging layer. Because the definition of this layer varies by customer, a definition of this area is not provided as part of Oracle Communications Data Model.

  Note:

  If you are using an application adapter for Oracle Communications Data Model to populate the foundation layer of Oracle Communications Data Model, then that adapter defines and populates an Oracle Communications Data Model staging layer.

• Foundation and Access layers. The physical objects for these layers are defined in a single schema, the ocdm_sys schema:

  • Foundation layer. The foundation layer of the Oracle Communications Data Model is defined by base tables that present the data in 3NF (that is, tables that have the DWB_ prefix). This layer also includes reference, lookup, and control tables defined in the ocdm_sys schema (that is, the tables that have the DWR_ , DWL_, DWC_ prefixes).

  • Access layer. The access layer of Oracle Communications Data Model is defined by derived and aggregate tables (defined with DWD_ and DWA_ prefixes), cubes (defined with a CB$ prefix), and views (that is, views defined with the DWV_ prefix), and cube views (defined with _VIEW suffix). These structures provide a summarized or "flattened" perspectives of the data in the foundation layer.

    This layer also contains the results of the data mining models which are stored in derived (DWD_) tables.