- •Contents
- •Data Modeling Concepts
- •Benefits of Data Modeling
- •Methods
- •Typographical Conventions
- •Introduction
- •Data Modeling
- •Data Modeling Sessions
- •Session Roles
- •Sample IDEF1X Modeling Methodology
- •Modeling Architecture
- •Logical Models
- •Entity Relationship Diagram
- •Key-Based Model
- •Fully-Attributed Model
- •Physical Models
- •Transformation Model
- •DBMS Model
- •How to Construct a Logical Model
- •Entity Relationship Diagram
- •Entities and Attributes Defined
- •Logical Relationships
- •Many-to-Many Relationships
- •Logical Model Design Validation
- •Data Model Example
- •Key-Based Data Model
- •Key Types
- •Entity and Non-Key Areas
- •Primary Key Selection
- •Alternate Key Attributes
- •Inversion Entry Attributes
- •Relationships and Foreign Key Attributes
- •Dependent and Independent Entities
- •Identifying Relationships
- •Non-Identifying Relationships
- •Rolenames
- •Overview
- •Entity and Attribute Names
- •Synonyms, Homonyms, and Aliases
- •Entity Definitions
- •Descriptions
- •Business Examples
- •Comments
- •Definition References and Circularity
- •Business Glossary Construction
- •Attribute Definitions
- •Validation Rules
- •Rolenames
- •Definitions and Business Rules
- •Relationships
- •Relationship Cardinality
- •Cardinality in Non-Identifying Relationships
- •Referential Integrity
- •Referential Integrity Options
- •RI, Cardinality, and Identifying Relationships
- •RI, Cardinality, and Non-Identifying Relationships
- •Additional Relationship Types
- •Many-to-Many Relationships
- •N-ary Relationships
- •Recursive Relationships
- •Subtype Relationships
- •Complete Compared to Incomplete Subtype Structures
- •Inclusive and Exclusive Relationships
- •IDEF1X and IE Subtype Notation
- •When to Create a Subtype Relationship
- •Normalization
- •Overview of the Normal Forms
- •Common Design Problems
- •Repeating Data Groups
- •Multiple Use of the Same Attribute
- •Multiple Occurrences of the Same Fact
- •Conflicting Facts
- •Derived Attributes
- •Missing Information
- •Unification
- •How Much Normalization Is Enough
- •Support for Normalization
- •First Normal Form Support
- •Second and Third Normal Form Support
- •Objective
- •Support for the Roles of the Physical Model
- •Summary of Logical and Physical Model Components
- •Denormalization
- •Classification of Dependent Entities
- •Glossary
- •Index
Modeling Architecture
Modeling Architecture
These five modeling levels are presented in the following figure. Notice that the DBMS Model can be at either an Area Level scope, or a Project Level scope. It is not uncommon to have single ERD and KB models for a business and multiple DBMS Models, one for each implementation environment, and then another set within that environment for projects that do not share databases. In an ideal situation, there are a set of Area Level scope DBMS Models, one for each environment, with complete data sharing across all projects in that environment.
These models fall into two categories:
■Logical
■Physical
Logical Models
There are three levels of logical models that are used to capture business information requirements: the Entity Relationship Diagram, the Key-Based Model, and the Fully-Attributed model. The Entity Relationship Diagram and the Key-Based models are also called area data models since they often cover a wide business area that is larger than the business chooses to address with a single automation project. In contrast, the Fully-Attributed model is a project data model since it typically describes a portion of an overall data structure intended for support by a single automation effort.
16 Methods Guide
