Learning Objectives
By the end of this lesson you will be able to:
- Explain the role of the Conceptual Entity Model in PDM
- Read and interpret a simple Entity Relationship Diagram (ERD)
- Describe how the four types of data model are used at different stages of a PDM project
Models in PDM
Data models in PDM are not architecture documents - they are analytical tools. Their purpose is to help the project team and business stakeholders understand the data being migrated well enough to make good decisions.
PDM does not require complete, normalised data models of every legacy system. It requires models that are good enough for the purpose at hand. This is a deliberate design choice: over-engineering the modelling work adds time and cost without improving outcomes.
The Four PDM Models
1. Conceptual Entity Model
The highest-level model. Shows the key business entities and their relationships, without detail about attributes or technical structure. This is the model used for project decomposition, KBDA identification, and communication with senior business stakeholders.
In PDM notation: boxes for entities, crow’s feet for relationships. The model needs to be readable by a non-technical Data Owner.
2. Legacy (or Migration) Data Model
Documents the actual structure of the legacy data stores being migrated. Used in gap analysis to identify structural differences between legacy and target.
The level of detail depends on the LDS: a major ERP system may have a detailed model; a local spreadsheet may need only a simple entity list.
3. Target Model
The structure of the target system. This is usually provided by the target system team or vendor - it is not the migration team’s responsibility to create it.
The target model is the destination against which all mapping decisions are made.
4. Individual Data Store Model
A detailed model of a specific legacy store, used when analysing internal inconsistencies or complex transformation requirements. Not all LDS will need this level of detail.
Reading an ERD
A basic ERD uses:
- Boxes - entities (Customer, Order, Product, Equipment)
- Lines - relationships between entities
- Crow’s feet - cardinality notation (one-to-many, many-to-many)
The video above walks through the corrected DHGS conceptual model. In plain language, it shows:
- One Customer places many Sales Orders
- Each Sales Order lists one or more Products
- A Product may be supplied by several Suppliers (and a Supplier supplies many Products)
- Suppliers also lease Equipment to DHGS
- Equipment is located at a Site and requires many Equipment Maintenance records
- The Work Force carries out that maintenance and is based at Sites
- Customers and Purchase Orders both generate Financial Activities
Vehicles are deliberately left off - DHGS manages them in a separate, dedicated database.
This picture drives the migration sequence: Customer and Product must be in place before Sales Orders can be loaded; Equipment must be in place before its maintenance records.
A word of warning - never trust the model you are handed. The first conceptual diagram for DHGS came from a CRM project that was never implemented. It was missing the entire finance area, had no Equipment Maintenance, no Supplier-to-Equipment leasing relationship, and treated Vehicles as ordinary Equipment. Always validate a handed-over model against other sources - the strategy documents, the people who run the systems, the data itself - before you build decomposition decisions on top of it.
Master Data Management in the Context of Models
When the Conceptual Entity Model reveals that the same entity appears in multiple legacy systems - Customer in the CRM, the Finance system, and the Sales system - a Master Data Management (MDM) decision is required.
PDM defines MDM in this context as: the creation and management, for data migration purposes only, of a single list of values for a migration-critical entity.
This is distinct from enterprise MDM. The migration MDM is temporary - it exists only to ensure that when Customer records from three systems are merged, the result is a single, deduplicated, correctly attributed list. After migration, the target system takes over.
Key Takeaways
- PDM uses four model types: Conceptual, Legacy/Migration, Target, and Individual Data Store
- The Conceptual Entity Model drives project decomposition and is kept simple enough for business stakeholders to read
- Models are analytical tools, not architecture documents - “good enough” is the right standard
- Never trust a handed-over model; validate it against other sources before building on it
- Migration MDM is a temporary measure for handling entities that exist in multiple legacy systems
Book Reference
Practical Data Migration by Johny Morris (BCS, The Chartered Institute for IT): Chapter 7, “Metadata and Key Business Data Areas”.