| Oracle® Communications Data Model Implementation and Operations Guide 11g Release 2 (11.2) Part Number E15883-04 |
|
|
PDF · Mobi · ePub |
| Oracle® Communications Data Model Implementation and Operations Guide 11g Release 2 (11.2) Part Number E15883-04 |
|
|
PDF · Mobi · ePub |
This chapter provides information about customizing the logical model portion of the Oracle Communications Data Model. It contains the following topics:
Tip:
If you do not have a requirement to change the logical design delivered with Oracle Communications Data Model you can ignore this topicA logical data model is the model that is built during the strategy and analysis phase of the Database Development life cycle. The purpose of this model is to clarify and satisfy the needs of the business users and validate the information requirements. Typically, a logical model is in Third Normal Form (3NF) which is a classical relational-database modeling technique that minimizes data redundancy through normalization.
The logical model delivered with Oracle Communications Data Model is a Third Normal Form (3NF) model developed using Oracle SQL Developer Data Modeler.
When customizing the logical data model of Oracle Communications Data Model, keep the data model application-neutral, and ideally in Third Normal Form. That way a physical design based on it mirrors the logical data model structure, and realizes all the benefits of a good relational database design: flexibility, controlled and limited redundancy, and ease of future expansion and support.
Approach any attempt to change the Oracle Communications Data Model with caution. The logical model of the Oracle Communications Data Model has (at its core) a set of generic structures that allow it to be flexible and extensible. Before making extensive additions, deletions, or changes, ensure that you understand the full range of capabilities of Oracle Communications Data Model and that you cannot handle your requirements using the default logical objects.
When designing the default Oracle Communications Data Model the following notation and tools were used. Determine if you want to customize Oracle Communications Data Model in the same manner:
Data model uses the Information Engineering (IE) syntax.
All of the data models are developed and maintained using Oracle SQL Developer Data Modeler.
When developing the logical model for Oracle Communications Data Model, the following conventions were followed. Continue to follow these conventions as you customize the logical model.
Naming Conventions for the Logical Data Model
In the logical data model, ensure that entity and attribute names are meaningful in your business. Also, to ensure that when you create the physical data model you can use physical table names that are similar to the logical entity names. Also, familiarize yourself with the naming restrictions within an Oracle Database schema.
For example:
Table and column names:
Must start with a letter
Can use only 30 alphanumeric characters or less
Cannot contain spaces or some special characters such as "!".
Cannot use reserved words
Table names must be unique within a schema that is shared with views and synonyms.
Column names must be unique within a table
A domain is a set of values allowed for a column. The domain can be enforced by a foreign key, check constraints, or the application on top of the database. Define the standards for each domain across the model such as:
Date and time type, such as 'YYYY-MM-DD'.
Numeric value in different situations.
Character string length in different situations.
Coded value definition such as key or description.
Comment your logical data model using the following guidelines:
All entities must have description (or notes).
All attributes must have comment (in short). The description (or notes) is required to further define the attributes.
Comments for relationships are not mandatory. But for tricky or abstruse relationships, add comments whenever you find them confusing.
There are several common change scenarios when customizing the logical model:
Additions to Existing Structures
If you identify business areas or processes that are not supported in the default logical model of the Oracle Communications Data Model, add new entities and attributes.
Carefully study the logical data model to avoid building redundant structures when making additions. If these additions add high value to your business value, communicate the additions back to the Oracle Communications Data Model Development Team for possible inclusion in future releases of Oracle Communications Data Model.
Changes to Existing Structures
In some situations some structures in the logical model of the Oracle Communications Data Model may not exactly match the corresponding structures that you use.Before implementing changes, identify the impact that the changes would have on the database design of Oracle Communications Data Model. Also identify the impact on any applications based on the new design.
Deletions of Existing Structures
If there are areas of the model that cannot be matched to any of the business requirements of your legacy systems, it is safer to keep these structures and not populate that part of the warehouse.
Deleting an entity in a logical data model can destroy relationships needed in other parts of the model or by applications based on the it. Some entities may not be needed during the initial implementation, but the you may want to use these structures at a later time. If this is a possibility, keeping the structures now saves re-work later. If entities are deleted, perform a thorough analysis to identify all relationships originating from that entity.
Application stores are the latest battleground for mobile phone companies seeking to differentiate their products in an increasingly crowded and competitive marketplace. Users can find the applications by searching using keywords or by browsing through categories and top downloads - so they can see what everyone else is downloading - in addition to the front page, which showcases a selection of featured applications. The 'App World' can be accessed directly through the handset, enabling users to download applications and software on the go. Some applications are free, others cost a small fee.
Now, as an example, let's take a look how Oracle Communications Data Model supports the application store business, what a sample customer might discover during fit-gap analysis, and how that customer might extend Oracle Communications Data Model to fit the discovered gaps. (For other examples, see business use cases in Oracle Communications Data Model Reference.)
The entities provided with the logical model of Oracle Communications Data Model that support the Application stores are:
CONTENT PROVIDER: This entity provides the actual content that ultimately is consumed by the end user. The contents could be video or audio clips or text content. In the case of Quick Time 7, the content provider is Apple.
CONTENT TYPE: This entity stores the type of content. For example, for Quick Time 7, Content Type is an application.
CONTENT: This entity keeps all contents provided by the content provider. For example, Quick Time 7 is Content. In this entity you can store the information about the content; for example, whether the content is still active or not, popularity of the content which is calculated by the number of downloads, and so on.
CONTENT PRICE: This entity contains the price for downloading and ordering the content. This price is for individual content clip. There might be other contents priced as a flat rate rather than different price for each content. In this case, the pricing information is in product rating plan. For example, Quick Time 7 Pro is $30
CONTENT PRICING TYPE: This entity is type of content pricing. For example, The charge per downloading, monthly fixed rate, and so on.
CONTENT DELIVERY EVENT: This entity is an event to track downloads of contents. This entity captures the details of the download like the size of the download, duration, date and so on.
Assume that during the fit-gap analysis, you discover the following needs that are not supported by the logical model delivered with Oracle Communications Data Model:
Your company saves more than two levels of data for content. In other words, you discover that you track not only Content and Content Type as represented in the standard logical model of Oracle Communications Data Model, but also a level under Content Type (that is, a content subtype). For example for the value of Games in Content, you have Content Types of Fun Games, Action, and Racing. For the value of Fun Games in Content Types, you have subtype values of Packman, Mummy, and NFS.
In the Application Store, the operator must maintain a history of Customers who purchased applications so that when a customer tries to reinstall an application, they are not charged again.
To support the differences, you must extend the logical model in the following ways:
To store details about type of the game you must modify the logical model. The classic way to store details is to add another entity to hold another level of information. For example, you can add an entity named CONTENT SUBTYPE that has a one-to-many relationship with the CONTENT entity. The specific steps to perform these actions in Oracle SQL Developer Data Modeler are given in Example 2-1, "Extending the Logical Model to Support Multiple Levels for CONTENT".
To maintain the history of Customers who have purchased an application, you can change the logical model to support this need by creating an entity named APPLICATION SUBSCRIPTION that has a one-to-many relationship with CONTENT. The specific steps to perform these actions in Oracle SQL Developer Data Modeler are given in Example 2-2, "Extending the Logical Model to Maintain a History of Purchasers of an Application".
Example 2-1 Extending the Logical Model to Support Multiple Levels for CONTENT
Take the following steps in Oracle SQL Developer Data Modeler to extend the logical model to support multiple levels for CONTENT:
Open the Oracle Communications Data Model in SQL Developer Data Modeler.
Create the CONTENT SUBTYPE entity by taking the following steps:
In the right-hand pane (the main area) of the SQL Developer Data Modeler window, select the Logical tab.
Click the New Entity icon.
Click in the logical model pane and draw an entity box.
The Entity Properties window is displayed.
In the left-hand pane of Entity Properties, select General. For Name, specify, CONTENT SUBTYPE. (Note the value of Entity_xxx where xxx is the number for Long Name and Single Table for FWD Engineer Strategy.)
In the left-hand pane, select Attributes. Using the Add (+) icon, add the following attributes, one at a time:
CONTENT SUBTYPE CODE with a data type of CODE.
CONTENT SUBTYPE NAME with a data type of NAME.
CONTENT SUBTYPE DESC with a data type of DESCRIPTION.
In the left-hand pane, select Unique Identifiers. Using the Add (+) icon, add a unique, primary key to CONTENT SUBTYPE.
Select key_1 (which represents the unique, primary key), and use Properties icon to add the properties to the key.
In the left-hand pane of Key Properties, select General. For key properties, specify CST_PK for Name and Primary Key for State. (Note that the Long Name is CONTENT_SUBTYPE.CST_PK.
Select Attributes and Relations, and then select the column for the primary key (that is, CONTENT SUBTYPE CODE).
Click Apply. The entity CONTENT SUBTYPE is created.
Add a CONTENT SUBTYPE CODE column to the CONTENT entity by taking the following steps:
Select the CONTENT entity.
Right click and select Properties.
In the left-hand pane, click Attributes.
Use the Add (+) icon to add an attribute with the Name of CONTENT SUBTYPE CODE and a Data type of CODE.
Add a relationship between CONTENT and CONTENT SUBTYPE by taking the following steps:
Select the New 1: N Relation icon.
Select the CONTENT SUBTYPE entity.
Drag the CONTENT SUBTYPE entity over to the CONTENT entity and drop the cursor.
Example 2-2 Extending the Logical Model to Maintain a History of Purchasers of an Application
Take the following steps in Oracle SQL Developer Data Modeler to extend the logical model to support maintaining a history of Customers who purchased which application:
Open Oracle Communications Data Model in SQL Developer Data Modeler.
Create an APPLICATION SUBSCRIPTION entity by taking the following steps:
In the right-hand pane (main area) of the SQL Developer Data Modeler window, select the Logical tab.
Click the New Entity icon.
Click in the logical model pane in the main area; and in the Logical pane press, diagonally drag, and release the mouse button to draw an entity box.
The Entity Properties window is displayed.
In the left-hand pane of Entity Properties, select General. Specify APPLICATION SUBSCRIPTION for Name, and SUBSCRIPTION for Super Type. (Note that the value of FWD Engineer Strategy is Single Table.)
In the left-hand pane, select Attributes. Using the Add (+) icon, add the attribute named APPLICATION SUBSCRIPTION CODE with a data type of CODE. (As the APPLICATION SUBSCRIPTION entity is of SUBSCRIPTION, attributes are inherited from SUBSCRIPTION entity.)
In the left-hand pane, select Unique Identifiers. Use the Add (+) icon to add the Primary Key
Select Attributes and Relations, and then select the column for the unique, primary key.
Click Apply. The APPLICATION SUBSCRIPTION entity is created.
Add APPLICATION SUBSCRIPTION CODE to CONTENT by taking the following steps:
Select the CONTENT entity. Right click the CONTENT entity and select Properties.
In the left-hand pane, select Attributes. Use the Add (+) icon to add attributes, one at a time.
Add a relationship to CONTENT with APPLICATION SUBSCRIPTION by taking the following steps:
Select the New 1: N Relation icon.
Select the APPLICATION SUBSCRIPTION entity.
Drag the APPLICATION SUBSCRIPTION entity over to the CONTENT entity and drop the cursor.
|
 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
