1 Introducing Oracle Communications Data Model

About Business Areas and Subject Areas in Oracle Communications Data Model

A Business Area is a broad slice through Oracle Communications Data Model grouping where all tables that cover the associated business processes (reports, metadata, Mining, OLAP, 3NF) are all accessible through the same GUI (if OBIEE is used). A business area is a conceptual grouping, used at the default report level. The reports are organized by related subject areas gathered in "business areas". Table 1-4 lists the Oracle Communications Data Model business areas.

Figure 1-3 represents a Business Area: a broad slice through Oracle Communications Data Model covering all the entities and mapped business processes associated with the business area.

A Subject Area is a thin slice through Oracle Communications Data Model grouping all tables, mainly at the foundation layer, that cover a specific (logical) concept, business process or question. For example, the subject area PARTY defines the notion of a "PARTY". The "Individual" and "Organization" are both a subset of PARTY. The CUSTOMER, OPERATOR, and VENDOR are example of Party types. At the opposite of this abstract subject area, the subject area CALL CENTER, with pre-built aggregates provided in Oracle Communications Data Model on top of the foundation layer covers all the customer interactions that are done through a call center, whether inquiry, complaints, or change requests.

From an implementation perspective, Oracle Communications Data Model can be filled by subject or business area, without taking care of having to feed all tables in order to have tangible and usable results.

After filling all reports of a given business area with data, this does not mean that the whole business area is covered. Feeding all the tables needed to have all reports of a given business area probably also feeds some reports of other business areas. For example, some PRODUCT, COST and COLLECTION AGENCY entities are required in the Business Area Revenue (for the Revenue OLAP cube). This also partly covers the Product Management, Cost and Contribution, as well as the Partner Management business areas.

Figure 1-3 Business Area: A broad Slice through Oracle Communications Data Model

Description of "Figure 1-3 Business Area: A broad Slice through Oracle Communications Data Model"

About the Logical Data Model and Physical Data Model

A logical data model describes how to store information that defines business processes. The logical data model is an interface between business and technical staff, and allows these groups to provide a common understanding of business data elements and requirements.

The logical data model also provides the foundation for designing an Enterprise Data Warehouse. In Oracle Communications Data Model, the logical data model is designed to avoid data redundancy, as much as possible, without impacting performance, and thus prevent data and business transaction inconsistency. The idea is to facilitate data re-use and sharing, hence reducing development and maintenance cycle and cost.

The logical data model is a single source for the model definition, with its own naming conventions that are valid for both business and IT.

In describing the business processes independently of the data sources and the technology, the logical data model clarifies the functional specifications, while avoiding (unnecessary) assumptions.

This implies that, in principle, the logical data model of Oracle Communications Data Model could work on any platform. However, on top of the fact that it would not be supported by Oracle, such an implementation would not benefit from all the pre-built pre-integrated technologies leveraged with Oracle Communications Data Model, in particular in the analytical layer, such as Partitioning, OLAP, Mining models, and so on.

The Oracle Communications Data Model physical data model is the concrete implementation of the logical data model. It is fully technology dependent. The physical data model transforms business relationships into keys or indexes. It takes into account the infrastructure and technology to optimize the performance for end-users. The physical data model has its own naming convention in parallel to the one of the logical data model. Looking at the physical data model, one should be able to "build-back" the logical data model from the entity relationship, even if one could not have all the key understanding of a business process behind, unless one knows the business.

About Entity Relationships in Oracle Communications Data Model

A relationship between two entities should exist in the model only if there is a direct (business) relationship between those entities. You can categorize the relationships as:

• Description or added information: (typically for Lookup tables) An entity contains codes that describes or validates the various values that an attribute of the original entity possesses. Physically, the two entities are related through a Foreign Key.

• Direct relationship: Typically, when two entities are related from a business point of view, the model needs to make sure this relationship is explicitly present and described. A direct relationship contains a direct business link between the entities (typically serves, uses, owns, and so on). There must be a distinction between clear 1 to many (1:n) or 0 to many (0:n), and many to many (n:m) relationship.

  • 0:n or 1:n relationships: typically business types like "owns", "has got", "serves", "uses"… It is usually directly linked to an attribute (like description), and may be a foreign key link.

  • m:n relationships: If the relationship can be "many to many", use an "Assignment" Entity between the entities to transform this m:n relationship in m:1 (or 0) and (0 or) 1:n.

Self-Relationship:

Very often, two rows of a given entity (say "ENTITY") have to be related with one another. Most of the time, Oracle Communications Data Model uses a table named "ENTITY ASSIGNMENT".

For example: PARTY and PARTY ASSIGNMENT, as shown in Figure 1-4.

Figure 1-4 PARTY and PARTY ASSIGNMENT Entities

Description of "Figure 1-4 PARTY and PARTY ASSIGNMENT Entities"

PARTY ASSIGNMENT represents the relationship between two parties uniquely identified in Oracle Communications Data Model, whatever the role they play within the model: As Customer, Employee, dealer or even all three for the same individual!

In Party, the PARTY TYPE is a "person", an "organization", or an "organization business unit". It is not "Customer". This is a Party role. A given Party can have several roles which are "chosen" depending on the type of business interaction that takes place. However, the type never changes.

The only exception to this rule is with ADDRESS LOCATION. One uses the "ADDRESS RELATED" table, for example to feed the fact that an alternative billing address has been given by customer when the first one fails or because he is in holiday.

Understanding Named and Flexible Hierarchies

A named hierarchy is a pre-built hierarchy of general interest, usually used/seen in the market, with fixed levels (with a specific name for each).

A flexible hierarchy is a hierarchical structure that is freely definable: for levels, attributes per level, relationships and numbers of hierarchies (for the same base entity) with various possible versions.

These hierarchies do the following:

• Follow Slowly Changing dimension Type II rules.

• Have the same leaf level (Organization Business Unit for "Organization" and Address Location for "Geography")

• Have pre-built tools to feed/change them easily (for implementation team).

• Can be associated in parallel (for example, In an Organization, several hierarchies can be defined: Administrative Hierarchy and Sales Hierarchy)

ORGANIZATION BUSINESS UNIT refers to lowest-level internal business unit of the organization that delivers a limited range of specific communications services or merchandise through any sales channel (website, store, and so on), as shown in Figure 1-5.

Figure 1-5 Organization Business Unit Entity

Description of "Figure 1-5 Organization Business Unit Entity"

ORGANIZATION BUSINESS ENTITY refers to any internal logical entity that is recognized as a part of the enterprise for business analysis and transactions. Classification for a business entity can include company, operation unit, store, or warehouse. This is part of "Flexible Hierarchy" of organization.

Address Related is the only exception in Oracle Communications Data Model to relationship between the same entity.

Calendar and Time in Oracle Communications Data Model

Oracle Communications Data Model includes five pre-defined calendars:

• Business: allows to define operator's own Calendar according to its business operation.)

• Gregorian: Standard 365-days calendar

• Fiscal: Follows Accounting or Legal Requirements

• Ad: Follows Ad Cycle

• Planning: Planning cycle calendar

In Oracle Communications Data Model, the business calendar is by default the same as the natural calendar (=Gregorian), since most of operators run billing process monthly according to natural calendar. Business calendar can be modified according to different business operations.

A flexible calendar script can populate the calendar based on input parameters.

Time Transformation

A Time Transformation does the following:

• Relates the elements of time-based attributes to other elements of the same attribute and specify the relationship between elements for some time-based frame of reference.

• Supports both "one-to-one" and "many to many" Transformation …

  • For every element in the table, there is one corresponding element for the time frame in question (for example, current week to the same week last year).

  • Supports "many-to-many" transformations for calculating year-to-date, season-to-date and similar totals. These tables specify all of the elements that are to be included in calculating a total from a given reference point.

• Time of Day allows granularity to the Quarter-hour level.

• Year-to-date transformation specifies all of the days or weeks that are included in the transformation from a given day or week since the beginning of the year.

Product and Product Instance: In Product Management and Provisioning Business Area

PRODUCT: is what customer can get. It composes the offering:

• Sub-Types of PRODUCT are PRODUCT PACKAGE, SERVICE, ITEM, EQUIPMENT

• PRODUCT may have valid equipment functionality and versions.

• PRODUCT may be particularly offered only locally or in a limited region.

PRODUCT INSTANCE: represents the real instance of a given PRODUCT that a customer can purchase or rent. For example:

• Specified Song Corresponding to Product MUSIC DOWNLOAD

• TV channel Corresponding to Product PAY TV

• Product Instance could also be a physical instance of Equipment which customer can leverage to access the service from operator. It could be used for inventory management. For example:

  • Handset (with IMEI)

  • Land line phone (with serial number)

  • Set-top box

  • Cable modem

Concept: Business Interaction / Events in All business areas

Business Interaction: "an arrangement, contract, or communication between an enterprise and one or more other entities such as individuals and organizations (or parts of organizations). Interactions take on the form of requests, responses, and notifications". (TMF-SID definition)

Event: an interaction of any kind between at least two parties. There are two types of events:

• "Network" Event: A Call Data Record or a Traffic event on the network made by a customer, a partner, or someone else calling the customer (but not originated from the CSP itself)

• "Non-Network" Event: all other (business) interactions:

  • Customer interaction with the call center, the web interface…,

  • SLA with partners

  • Interaction between Mediation and Order Management System

Scenario 2: Product and Subscription

For a Standard Offer with a two hundred dollar monthly fee that includes three products for customer, as in Figure 1-6.

Figure 1-6 Product and Subscription Offer for Customer A

Description of "Figure 1-6 Product and Subscription Offer for Customer A"

Figure 1-7 shows this relationship in Oracle Communications Data Model.

Figure 1-7 Product and Subscription Scenario

Description of "Figure 1-7 Product and Subscription Scenario"