You are on page 1of 13

maintained in the shared folder SHARED\MODELS in server ev010dataaegm

Logical The data models are

Revision: 1.0 04/18/2009 Owner:

IS THIS THE LATEST REVISION OF THIS DOCUMENT? Before proceeding, please verify that you are using the latest approved revision of this document. If you are not sure how to do this, please ask your Enterprise Data Architect.

Revision Information
Modification Log: Date Revi sion # Person Updating Section: Brief Description of Issue

Table of Contents
1 INTRODUCTION 2 LOGICAL DATA MODELING 3 3

2.1 Project Deliverables Required for Logical Data Modeling 2.1.1 Technical Architecture Document (TAD) 2.1.2 Functional Specifications (FS) 2.1.3 Business Requirements Document (BRD) 2.1.4 Data Requirements Document (DRD) 2.2 Conceptual Data Model 2.3 Logical Data Model General Guidelines 2.4 Additional Guidelines for Data Marts 2.4.1 Dimensional Data Modeling Guide 2.5 Model Naming Standard 2.6 Entities 2.6.1 Creating New Entities 2.6.2 Entity Naming 2.6.3 Entity Definition 2.6.4 Primary Key & Alternate Keys 2.6.5 Foreign Key Relationship 2.7 Attributes 2.7.1 Attribute Naming 2.7.2 Attribute Data Types 2.7.3 Attribute Constraints 2.7.4 Attribute Definition 2.8 Logical Data Model Review Checklist
3 ABBREVIATIONS 4 ORACLE 10G RESERVED WORDS 5 APPENDIX A - GLOSSARY

3 3 3 3 4 4 5 5 5 6 6 6 6 8 8 9 9 9 11 11 12 12
12 13 13

1 Introduction
In the Logical Data Modeling section, the document captures the list of inputs from project team (business analyst) required by a data modeler to begin logical modeling, naming standards for entities, attributes, standards about identifying and creating keys for an entity and standards for creating foreign key relationships. The document also provides a checklist for data modeler to verify the data model before the logical model can be taken to a model review.

2 Logical Data Modeling


2.1 Project Deliverables Modeling

Required

for

Logical

Data

In order to ensure the success of the logical data modeling, please make sure that the following deliverables are provided: Technical Architecture Document (TAD) Functional Specifications (FS) Business Requirements Document (BRD) Data Requirements Document (DRD) Completed Source Inventory file

2.1.1

Technical Architecture Document (TAD)

See link to the standard TAD template http://supportcentral.XX.com/*TAD

2.1.2

Functional Specifications (FS)

See link to the standard FS template. http://libraries.XX.com/download? fileid=22710683101&entity_id=3209860101&sid=101

2.1.3

Business Requirements Document (BRD)

The BRD must provide data requirements that will include but are not limited to all source data, reporting, and application and extract requirements. One output of the BRD will be the documentation of the source data structures using SourceInventoryTemplate.xls. This template is a working document that starts with the BRD and is refined in the DRD.

2.1.4

Data Requirements Document (DRD)

All data requirements that are needed in order to satisfy the Functional Specifications and Business Requirements, including the reporting requirements need to be identified in the DRD document. The DRD is a further detailed refinement of the Data Requirements that may have been already addressed in the FS and the BRD. In some instances, much of these requirements will already be identified to some level of granularity, in the BRD. This document can stand-alone

or be referenced in a section of the BRD. Often not all the Data Requirements are sorted out at the time the BRD is finalized. The DRD is the primary responsibility of the Data Analyst (DA); however This may be a shared responsibility of the DA, BA, DM and/or the Data Architect with the guidance of the Business. A template for data requirements is provided at DRD Template.doc The DRD will define: All sources and inputs to the project Technical and business definitions for all data elements All the outputs or extracts (if any) that will feed other systems or that will be downloaded to local applications included those that may be used to populate excel spreadsheets on the users desktop. Dimensions and measures will be identified as they relate to reporting requirements Key subject areas will be identified in a conceptual data model, e.g. Customer, Location, Shipments, and Orders etc. Once can use these to create a conceptual data model of the data. Data Requirements Definition. The data requirement has to be defined in appropriate format. For data integration projects, please document the source data structures using SourceInventoryTemplate.xls

2.2 Conceptual Data Model


If the complexity of the requirements is high, a conceptual data model needs to be created, before attempting to derive a logical data model. Features of conceptual data model must include: Includes the important entities and the relationships among them. No attribute is specified. No primary key is specified.

At this level, the data modeler attempts to identify the highest-level relationships among the different entities. Conceptual model can be done with Erwin. Bpwin may be a superior tool for conceptual model. But the tool evaluation is out of scope for this effort. We will evaluate the tool and give you the guidance later. Until then, please feel free to use ERwin for Conceptual model design. For an overview of how to use BPwin, please refer to the presentation. http://data.supportcentral.XX.com/upload/17786/doc_1177818.ppt

2.3 Logical Data Model General Guidelines


The intent of the Logical Data Model is to document explicitly, a comprehensive understanding of the data to be stored and delivered in an application. In the logical data model, the data modeler will attempt to describe the data in as much detail as possible, without regard to how they will be physically implemented in the database. The logical data model has to emphasize the following: The logical data model has to be at least in 3rd normal form. Separate subject area has to be created to group entities that belong to a unique business function. While creating the subject area please bring all the 1st level parent entities to the subject area. Includes all entities and relationships among them. All attributes for each entity are specified. Audit columns are not required to be in the logical data model, Create them as Physical ONLY columns. Primary key for each entity specified. Foreign keys (keys identifying the relationship between different entities) are specified.

Please refer to the data model image at section 2.7.2 for a example of how table should be named and columns should be named. For a detailed discussion of design standards for entities, attributes and relationships please refer the section for Entities or Attributes in this document.

2.4 Additional Guidelines for Data Marts


2.4.1 Dimensional Data Modeling Guide
Dimensional Data models are useful for representing star schemas, a.k.a. Fact tables to be used for reporting purposes. While this is not a function of logical modeling; some known facts and dimensions may be started at this stage. It is the job of the physical modeler however, to take the suggestions, in any, and add to or finalize the fact tables in the physical model. Dimensional models are often used to depict structures used in Data marts. The PMM should follow the Dimensional Data Modeling methodology. Dimensional Data Modeling Guide provides the information and the TSG standards for dimensional data modeling that PMM should follow. http://data.supportcentral.XX.com/upload/17786/doc_690968.doc

2.5 Model Naming Standard


The data model must be named per the following to naming convention. SSS + XXX + v.<n>.erwin where: SSS = Schema

XXX = DEV, QA, PROD (development, QA, production) n = Model version number as in Model Mart (stating with 1) All section has to be separated by an underscore ("_"). E.g., BDW_QA_v.2.erwin For work-in-progress models, you may add a date after the Version number to track the changes in the model. But you should remove the date part upon finalizing the model.

2.6 Entities
2.6.1 Creating New Entities
To speed up creation of new entities, copy from the template data models template entity. This entity has all of the necessary settings pre-defined. You can always override the settings if required. OLTP Data Model ERwin Template: OLTP Template V3.erwin Dimensional Data Model ERwin Template: Dimensional Template v4.erwin

2.6.2

Entity Naming
Entity names must be meaningful and must not conflict with other entity names. The entity name should be self-explanatory and should reflect the correct business meaning. Entity names should not be prefixed with schema name and should have spaces not underscores). For e.g. SALES ORDERLINE Entity name should not be too generic with the exception of a super type entity (E.g.: An entity for a sales transaction cannot be called Transaction, it must be called Sales Order). Avoid any abbreviations on the entity name unless it is commonly used in the business community. When abbreviations are used, the full words must be obvious or in other words, only standard abbreviations should be used. For XX standard abbreviations see Abbreviations There is no restriction to the length of the entity name but unusually long names should not be used. The entity name should be long enough to describe the business meaning of the entity. Entities should be represented by singular names. Entity names should be mixed case (i.e., lowercase with leading caps) with spaces between the words (e.g., Customer Name). Special characters except spaces should not be used in entity names.

Please find the following model snippet as example for good entity naming.

SALE INVOICE ORDER LINE Sales Sales Sales Sales Invoice Num (FK) Invoice Line Id (FK) Order Line Num (FK) Order Id (FK)

SALES ORDER LINE Sales Order Id (FK) Sales Order Line Num is charged on Parent Sales Order Id (FK) Parent Sales Order Line Num (FK) Sales Order Line Create Dttm Sales Order Line Item Id (FK) Sales Order Line Item Qty Sales Order Line Qty UOM Cd (FK) Sales Order Line Unit Standard Price Amt Sales Order Line Unit Average Cost Amt Sales Order Line Unit Price Amt Sales Order Line Currency Cd (FK) Sales Order Line Forecasted Revenue Dttm Sales Order Line Ship To Party Id (FK) Sales Order Line Ship To Address Id (FK) Sales Order Line Contract Id (FK) Sales Order Line Sales Associate Id (FK) Sales Order Line Web Visit Id (FK) Sales Order Line Page View Sequence Num (FK) Sales Order Line Requested Ship To Location Id (FK) Sales Order Line Status Object Id (FK) Billing Rates Entered Flag Estimated Final Cost Margin Order Entered By Name Txt Partial Billing Flag Quote Created By Name Verbal PO Flag PO Received Flag PO Hard Copy Received Flag Pricing Basis Type Cd (FK) Requestor Telephone Number Id (FK) Sales Order Line Extended Global Amt Sales Order Line Extended Local Amt Ship To Attention Ship To Contact Name Sales Order Line Ship To Telephone Id (FK) Sales Order Line Ship To Fax Id (FK) Sales Order Line Ship To Email Address Id (FK) Warranty Reason Id (FK) Forced Outage Flag describes is the child of

is charged on

Sales Invoice Line Order Line Qty Sales Invoice Line Order Line UOM Cd (FK) INVOICE TYPE Invoice Type Cd INVOICE Invoice Num Invoice Created Dttm Invoice Description Txt Host Invoice Num Invoice Type Cd (FK) Invoice Transmittal Mode Cd (FK) Consolidated Invoice Id (FK) Invoice Source Type Cd (FK) Invoice Status Object Id (FK) Invoice Desc2 Txt Invoice Desc3 Txt Collection District Cd classifies Invoice Type Desc

INVOICE AMOUNT Invoice Amount Type Cd (FK) Sales Invoice Line Id (FK) Invoice Amount Dttm Sales Invoice Num (FK) Invoice Amount Invoice Amount Invoice Amount is associated with Invoice Amount Global Amt Transaction Amt Local Amt Currency Cd (FK)

SALES INVOICE LINE Sales Invoice Num (FK) Sales Invoice Line Id Sales Invoice Line Item Id (FK) Sales Invoice Line Desc Host Invoice Line Num Sales Invoice Line Type Cd (FK) Sales Invoice Line Status Object Id (FK) Bill To Intraco Billing Cd

SALE INVOICE Sales Invoice Num (FK) Sale Invoice Type Cd (FK) Sale Invoice Reason Type Cd (FK) Sale Invoice Ledger Batch Id (FK) Sales Invoice Chart Of Account Id (FK) Invoice Comment Line2 Txt (FK) Invoice Comment Line3 Txt (FK) Account Distribution Number Segment Id (FK) GL Account Overwrite Transaction Type Cd (FK) Alternate Invoice Account (FK) INVOICE AMOUNT TYPE Invoice Amount Type Cd Invoice Amount Type Desc

contains

2.6.3

Entity Definition
Entity definition must be at least one complete sentence with a meaningful textual description of the meaning/use of the entity with up to a max of 4000 characters of data. Simply repeating the full entity name is not an acceptable definition.

Definition should benefit the developers and users, to better understand the application and its functionality. Refrain from giving a dictionary definition for the entity. They can serve as a good starting point, but they do not put the concept in prospective of the application or the functional use of the data. Do not use abbreviations in the definition. The individuals reading these manuals may not know the meanings of abbreviations or acronym that are common in the development environment.

Follow the details mentioned in the attached document for more details:

"STANDARD COMMENTS Format.doc"

The definition entered in the logical Entity Editor will automatically appear on the physical table as comments. The following is a good example. It defines an entity called Organization which is a subtype of the entity called Party in a typical Manufacturing domain. ____________________________________________________________________ In the context of XX Energy the organization is used to track details of internal department and customer. SOURCE: GIB, PLP, AND COPICS Description: This is a subtype entity to PARTY. An organization is any group of individuals (or one individual) or other organizations formed for a specific purpose. An organization can be either an internal organization or an external organization. This definition does not include groups of individuals that form a segment, nor does it include households (a grouping of individuals created by the enterprise for marketing purposes.) ____________________________________________________________________

2.6.4

Primary Key & Alternate Keys


Each entity should have a unique primary key. Each entity should have at least one candidate key identified. A candidate key is an attribute or a set of attributes that can uniquely identify a record in the entity. Among the identified candidate keys, select the most appropriate candidate key (The candidate key which is most static over its life) as the primary key. All the other candidate keys must be created as Alternate Keys. Do not define the Primary key also as an Alternate Key in the data model. All the Alternate keys will result into UNIQUE indexes in the physical data model.

If no candidate primary key is available, discuss it with the EDA. One alternative is to create a new attribute using an Oracle-generated sequence number in the format: LogicalEntityName Seq Id (follow the attribute naming standards discussed below). Primary key attributes will be set to NOT NULL. For oracle generated sequence number attributes please use Sequence Identifier as the domain. Sequence IDs are preferred to multi-column keys in most cases, especially if the entity has many child tables through relationships.

2.6.5

Foreign Key Relationship


If a logical relationship exists between two entities, it is recommended to create the relationship and the resulting constraint in the Erwin data model, unless there is a valid. Reason for not creating it (e.g., legacy data which doesnt satisfy the constraint and cant be cleaned up). Relationships in the logical data model should have names that are verb phrases and are lowercase (e.g., is evaluated by). The relationship Verb phase is required ONLY for the parent-to-child relationship. The Child-toParent relationship is quite apparent from the parent-to-child relationship and should be left empty. If a foreign key relationship does not accurately define the role in the associated entity use a role name in the relationship definition.

2.7 Attributes
2.7.1

Attribute Naming
Attribute name must be meaningful, self-explanatory and self-documenting and should reflect the correct business meaning of the data that is represented by the attribute. For e.g. in Sales Transaction entity, Sales Transaction Priority Cd clearly depicts the attribute definition. The attribute names should be "qualified" so that the domain of values is properly represented. In order to avoid ambiguity, or in order to add clarity, the name should be qualified. For instance; an attribute should not just be named "date"; rather, it should be named "Hire Date" or "Birth Date" etc (as applicable). The logical attribute names are usually used as column title in reports. Attribute names should not be prefixed with the entity name unless the attribute name is too generic. For example; in entity Vendor, its better to call an attribute Vendor Name Than calling the attribute Name. Attribute names must be short, but still logical and self-descriptive.

Always end the attribute name with a domain Name. The idea here is to make the attribute data unambiguous to the user (reader) of a logical model. The words must be separated by a space and NOT by an underscores. Avoid any abbreviations on the logical unless it is commonly used in the business community. When abbreviations are used, the full words must be obvious or in other words, only standard abbreviations should be used. For XX standard abbreviations see Abbreviations. There is no restriction to the length of the attribute name; but unusually long names should not be used. The attribute name should be long enough to describe the business meaning of the attribute. Attribute should be represented by singular names. Attribute names should be mixed case (i.e., lowercase with leading caps) with spaces between the words (e.g., Customer Name). Special characters except spaces should not be used in attribute names. When the attribute is a foreign key, please make sure to give an appropriate and meaningful Role Name to the attribute.

Following is an example of proper attribute naming:

Q O E LIN ST U O U T E AT S BJEC T Q uote Line Status O bject Id (FK)

SALES T AN R SAC IO T T N YPE Sales T ransaction T ype C d Sales T ransaction T ype D esc describes

is status of

SALES T AN R SAC IO T N Sales T ransaction Id

Q O E LIN U T E Q uote Id (FK) Q uote Line N um Q uote Line D ttm Q uote Line Sales Associate Id (FK) Q uote Item Id (FK) Q uote Line Item Q ty Q uote Line U M C (FK) O d Q uote Line U Std Price Am nit t Q uote Line U Std Price C nit urrency C (FK) d Q uote Line R equested Shipm D ent ttm Q uote Line Valid From D ttm Q uote Line Valid T D o ttm Q uote Line Ship T Party Id (FK) o Q uote Line Expected Purchase D ttm Q uote Line W Visit Id (FK) eb Q uote Line Page View Sequence N (FK) um Q uote Line Status O bject Id (FK) Q uote Line C M ost argin Q uote Line Extended Am t becom es

Sales T ransaction Visit Id (FK) Sales T ransaction T ype C (FK) d Sales T ransaction C reate D ttm Sales T ransaction Priority C (FK) d Sales T ransaction C reated By Party Id (FK) Sales T ransaction T ransm ittal M ode C (FK) d Sales T ransaction Status O bject Id (FK)

Q OE U T has Q uote Id (FK) Q uote Party Id (FK) Q uote Address Id (FK) Q uote N um Q uote R eceiv Location T ed xt Q uote C reated By

Q O E LIN O D LIN U T E R ER E Q uote Id (FK) Q uote Line N (FK) um Sales O rder Id (FK) Sales O rder Line N (FK) um Q uote Line O rder Line Item Q ty Q uote Line O rder Line U M C (FK) O d

2.7.2

Attribute Data Types


All attributes must belong to a data domain, which is already created and available in the logical data model template. If you couldnt find an appropriate data domain, please work with you EDA to create a domain in the appropriate template and also in the logical data model you are working on.

2.7.3

Attribute Constraints
You are required to capture all the applicable constraints such as Validation constraints, Null constraints and Default constraints in the logical data model. Commonly used constraints are available in the ERwin template you use.

If you need additional constraints to be created, please work with your EDA to create them in the ERwin template and also in the data model you are working on. Please pay attention not to create duplicate constraint rules with different names.

All the primary key attributes must be set to NOT NULL. All the non-key attributes can be set to NULL or NOT NULL as desired.

2.7.4

Attribute Definition
Attribute comments must be at least one complete sentence with a meaningful textual description of the meaning/use of the attribute with up to a max of 4000 characters of data. Simply repeating the full attribute name is not an acceptable definition. Definition should benefit the developers and users, to better understand the application and its functionality. Refrain from giving a dictionary definition for the attribute. They can serve as a good starting point, but they do not put the concept in prospective of the application or the functional use of the data. Do not use abbreviations in the definition. The individuals reading these manuals may not know the meanings of abbreviations or acronym that are common in the development environment. As far as possible, provide examples in the comments. This will assist in understanding the usage of the entity/attribute. The definitions entered in the logical Attribute Editor are setup in the template data model to automatically appear on the physical column comments. Follow the details mentioned in the attached document for more details

"STANDARD COMMENTS Format.doc"

2.8 Logical Data Model Review Checklist


Once the logical data model is created and is ready to be reviewed, the data modeler is required to run the checklist provided in Logical Data Model Checklist.doc. The checklist is provided to ensure that the data model review is done at the least amount of time with minimum repetitions.

3 Abbreviations
For commonly used abbreviations, check: http://data.supportcentral.XX.com/upload/17786/doc_2381791.xls

4 Oracle 10g Reserved Words


List of Oracle 10g Reserved Words

5 Appendix A - Glossary
Terms APL C.A E/R Diagram EDA Kintana Data Model Mart / Data Model manager MODELS shared drive PM PMM SAFE TSG Descriptions Application Project Leader Computer Associates Entity Relationship Diagram Enterprise Data Architect IT Project Management Tool A place where all data models are stored. Place to store data models, documents and scripts. Used before introducing Data Model manager. Project Manager Project Master Data Modeler Simple Algorithm for Fragmentation Elimination XX Technology Services Group

You might also like