Step 3: Build and Validate Global Logical Data Model

1
Step 3 Build and Validate Global Logical Data
Model

• Objective Combine individual local logical data
  models into a single enterprise data model.

2
Step 3

• Validate global model against normalization rules
  and transactions in views
• Only requires normalization and validation of
  those models that changed during the merge
  process
• Significant reduction in work needed for a large
  system

3
Step 3

• Each local logical data model should be correct,
  comprehensive, and unambiguous
• HOWEVER Each model is only a representation of a
  users or groups perception of the enterprise
• View may be incomplete
• Inconsistencies and overlaps
• Must resolve conflicts between views

4
Step 3

• Step 3.1 Merge local logical data models
  into global model
• Step 3.2 Validate global logical data model
• Step 3.3 Check for future growth
• Step 3.4 Review global logical data model
  with users

5
Step 3.1 Merge data models

• Identify similarities and differences between
  local logical data models
• Use
• ER diagrams
• Relational schema
• Data dictionaries
• Constraint documenation
• From each of the individual models

6
Step 3.1 Merge data models

• Systematic approach for large systems
• Review names and contents of entities/relationship
  s and their candidate keys
• Review names and contents of relationships/foreign
  keys
• Merge entities/relations from local data models
• Include entities/relations unique to each local
  data model
• Merge relationships/foreign keys from local data
  models
• Include relationships/foreign keys unique to each
  local data model
• Check for missing entities/relations and
  relationships/foreign keys
• Check foreign keys
• Check integrity constraints
• Draw global ER/relation diagram
• Update documentation

7
3.1.1 Review names and contents of
entities/relations

• Inspect names and descriptions of
  entities/relations in the data dictionary
• Problems when entities/relations
• Have same name, but are different (homonyms)
• Are the same, but have different names (synonyms)
• Use candidate keys to help identify equivalent
  but differently named entities

8
DreamHome Branch Staff Views
9
3.1.2 Review names and contents of
relationships/foreign keys

• Same method as described above
• Comparison of relationship names/foreign keys
  gives some indication of view overlap
• BUT, must be careful of entities or relationships
  with the same name that represent different
  concepts (i.e. homonyms)

10
DreamHome Branch Staff Views
11
3.1.3 Merge entities/relations from local data
models

• Examine name and content of each entity to be
  merged
• Determine whether entities represent the same
  thing
• Typically 3 situations
• Same name and same primary key
• Same name but different primary key
• Different names and same or different primary keys

12
Same name, same primary key
13
Same name, different primary key