The Importance of Data Analysis in Producing a Robust Physical Data Model
By Declan Chellar
Hierarchy of Data Analysis
When “data modelling” is mentioned on
projects…
Hierarchy of Data Analysis
Physical Data Model
When “data modelling” is mentioned on
projects…
…too many people only think of the
physical data model, DB tables, etc.
Hierarchy of Data Analysis
Physical Data Model
When “data modelling” is mentioned on
projects…
…too many people only think of the
physical data model, DB tables, etc.
But what about the data analysis that leads to a robust
physical data model?
Hierarchy of Data Analysis
Conceptual Data Model• A fundamental part of the
information architecture
Hierarchy of Data Analysis
Conceptual Data Model• A fundamental part of the
information architecture
• Identifies the business entities and shows the relationships between them
Hierarchy of Data Analysis
Conceptual Data Model• A fundamental part of the
information architecture
• Identifies the business entities and shows the relationships between them
• An essential complement to the business architecture
Hierarchy of Data Analysis
Conceptual Data Model• A fundamental part of the
information architecture
• Identifies the business entities and shows the relationships between them
• An essential complement to the business architecture
• Ought to be in place before any related software project even starts!
Hierarchy of Data Analysis
Conceptual Data Model• A fundamental part of the
information architecture
• Identifies the business entities and shows the relationships between them
• An essential complement to the business architecture
• Ought to be in place before any related software project even starts
• In reality, often missing altogether
Hierarchy of Data Analysis
Logical Data Model(normalised)
Conceptual Data Model• A fundamental part of the
information architecture
Hierarchy of Data Analysis
Logical Data Model(normalised)
Conceptual Data Model• A fundamental part of the
information architecture
• Expands upon the CDM by identifying the attributes of each entity and the keys to each relationship
Hierarchy of Data Analysis
Logical Data Model(normalised)
Conceptual Data Model• A fundamental part of the
information architecture
• Expands upon the CDM by identifying the attributes of each entity and the keys to each relationship
• Normalised to reduce redundancy
Hierarchy of Data Analysis
Logical Data Model(normalised)
Conceptual Data Model• A fundamental part of the
information architecture
• Expands upon the CDM by identifying the attributes of each entity and the keys to each relationship
• Normalised to reduce redundancy
• Ideally in place before any related software project even starts
Hierarchy of Data Analysis
Logical Data Model(normalised)
Conceptual Data Model• A fundamental part of the
information architecture
• Expands upon the CDM by identifying the attributes of each entity and the keys to each relationship
• Normalised to reduce redundancy
• Ideally in place before any related software project even starts
• In reality, often missing altogether
Hierarchy of Data Analysis
Logical Data Model(normalised)
Data Dictionary
Conceptual Data Model• A fundamental part of the
information architecture
Hierarchy of Data Analysis
Logical Data Model(normalised)
Data Dictionary
Conceptual Data Model• A fundamental part of the
information architecture
• Provides the essential business definitions for each attribute identified on the LDM
Hierarchy of Data Analysis
Logical Data Model(normalised)
Data Dictionary
Conceptual Data Model• A fundamental part of the
information architecture
• Provides the essential business definitions for each attribute identified on the LDM
• Traceable back to the LDM
Hierarchy of Data Analysis
Logical Data Model(normalised)
Data Dictionary
Conceptual Data Model• A fundamental part of the
information architecture
• Provides the essential business definitions for each attribute identified on the LDM
• Traceable back to the LDM
• Ideally in place before any related software project even starts
Hierarchy of Data Analysis
Logical Data Model(normalised)
Data Dictionary
Conceptual Data Model• A fundamental part of the
information architecture
• Provides the essential business definitions for each attribute identified on the LDM
• Traceable back to the LDM
• Ideally in place before any related software project even starts
• Can be enhanced iteratively throughout requirements gathering
Hierarchy of Data Analysis
Logical Data Model(normalised)
Data Dictionary
Conceptual Data Model• A fundamental part of the
information architecture
• Provides the essential business definitions for each attribute identified on the LDM
• Traceable back to the LDM
• Ideally in place before any related software project even starts
• Can be enhanced iteratively throughout requirements gathering
• In reality, often missing altogether
Hierarchy of Data Analysis
Logical Data Model(normalised)
Data Dictionary
Process Steps(data in/out at the functional level)
Conceptual Data Model• A fundamental part of the
requirements definition
Hierarchy of Data Analysis
Logical Data Model(normalised)
Data Dictionary
Process Steps(data in/out at the functional level)
Conceptual Data Model• A fundamental part of the
requirements definition
• For any process step, identifies the relevant attributes
Hierarchy of Data Analysis
Logical Data Model(normalised)
Data Dictionary
Process Steps(data in/out at the functional level)
Conceptual Data Model• A fundamental part of the
requirements definition
• For any process step, identifies the relevant attributes
• Traceable to/from the Data Dictionary
Hierarchy of Data Analysis
Logical Data Model(normalised)
Data Dictionary
Process Steps(data in/out at the functional level)
Conceptual Data Model• A fundamental part of the
requirements definition
• For any process step, identifies the relevant attributes
• Traceable to/from the Data Dictionary
• Its elaboration can feed details back into the Data Dictionary
Hierarchy of Data Analysis
Logical Data Model(normalised)
Data Dictionary
Process Steps(data in/out at the functional level)
Conceptual Data Model• A fundamental part of the
requirements definition
• For any process step, identifies the relevant attributes
• Traceable to/from the Data Dictionary
• Its elaboration can feed details back into the Data Dictionary
• In reality, often contains details that should reside in the Data Dictionary, leading to redundancy
Hierarchy of Data Analysis
Logical Data Model(normalised)
Data Dictionary
Process Steps(data in/out at the functional level)
Screen Specification(fields, etc., required for screens)
Conceptual Data Model• A fundamental part of the
requirements definition
Hierarchy of Data Analysis
Logical Data Model(normalised)
Data Dictionary
Process Steps(data in/out at the functional level)
Screen Specification(fields, etc., required for screens)
Conceptual Data Model• A fundamental part of the
requirements definition
• Documents the required behaviour of each screen and the relevant data to be displayed or captured (not to be confused with screen design/layout)
Hierarchy of Data Analysis
Logical Data Model(normalised)
Data Dictionary
Process Steps(data in/out at the functional level)
Screen Specification(fields, etc., required for screens)
Conceptual Data Model• A fundamental part of the
requirements definition
• Documents the required behaviour of each screen and the relevant data to be displayed or captured (not to be confused with screen design/layout)
• Its elaboration can feed details back into the Data Dictionary
Hierarchy of Data Analysis
Logical Data Model(normalised)
Data Dictionary
Process Steps(data in/out at the functional level)
Screen Specification(fields, etc., required for screens)
Conceptual Data Model• A fundamental part of the
requirements definition
• Documents the required behaviour of each screen and the relevant data to be displayed or captured (not to be confused with screen design/layout)
• Its elaboration can feed details back into the Data Dictionary
• Should be documented after the relevant logical process steps
Hierarchy of Data Analysis
Logical Data Model(normalised)
Data Dictionary
Process Steps(data in/out at the functional level)
Screen Specification(fields, etc., required for screens)
Conceptual Data Model• A fundamental part of the
requirements definition
• Documents the required behaviour of each screen and the relevant data to be displayed or captured (not to be confused with screen design/layout)
• Its elaboration can feed details back into the Data Dictionary
• Should be documented after the relevant logical process steps
• In reality, often contains details that should reside in the Data Dictionary, leading to redundancy
Hierarchy of Data Analysis
Logical Data Model(normalised)
Data Dictionary
Process Steps(data in/out at the functional level)
Screen Specification(fields, etc., required for screens)
Conceptual Data ModelRobust data analysis
provides the basis for good physical data modelling
Hierarchy of Data Analysis
Logical Data Model(normalised)
Data Dictionary
Process Steps(data in/out at the functional level)
Screen Specification(fields, etc., required for screens)
Conceptual Data ModelRobust data analysis
provides the basis for good physical data modelling
Otherwise, the data architects might have to
reverse-engineer the data needs of the business
based on screen designs
Hierarchy of Data Analysis
Logical Data Model(normalised)
Data Dictionary
Process Steps(data in/out at the functional level)
Screen Specification(fields, etc., required for screens)
Conceptual Data Model
Physical Data Model
Hierarchy of Data Analysis
Logical Data Model(normalised)
Data Dictionary
Process Steps(data in/out at the functional level)
Screen Specification(fields, etc., required for screens)
Conceptual Data Model
Physical Data Model
This takes a little longer, but results in a robust, adaptable and durable
physical data model
Hierarchy of Data Analysis
Process Steps(data in/out at the functional level)
Screen Specification(fields, etc., required for screens)
Physical Data Model
Hierarchy of Data Analysis
Process Steps(data in/out at the functional level)
Screen Specification(fields, etc., required for screens)
Physical Data Model
This is sub-optimal and is likely to result in an
inefficient database that will under-perform as it
grows larger
Hierarchy of Data Analysis
Process Steps(data in/out at the functional level)
Screen Specification(fields, etc., required for screens)
Physical Data Model
This is sub-optimal and is likely to result in an
inefficient database that will under-perform as it
grows larger
Unfortunately, this approach is quite common
Hierarchy of Data Analysis
Screen Specification(fields, etc., required for screens)
Physical Data Model
Hierarchy of Data Analysis
Screen Specification(fields, etc., required for screens)
Physical Data Model
This worst-case-scenario will definitely lead to an
under-performing database within as little as six months
Hierarchy of Data Analysis
Screen Specification(fields, etc., required for screens)
Physical Data Model
This worst-case-scenario will definitely lead to an
under-performing database within as little as six months
Unfortunately, this approach is not uncommon
Hierarchy of Data Analysis
Of course, physical data models often come “out of
the box” in the case of BPM or ERP systems
Hierarchy of Data Analysis
However, “out-of-the-box” does not mean “magic“ and the PDM does not
automatically fit the data needs of the business
Hierarchy of Data Analysis
“Out of the box”Physical Data Model
The PDM must be tailored to suit the
specific needs of the business
Hierarchy of Data Analysis
“Out of the box”Physical Data Model
Logical Data Model(normalised)
Conceptual Data Model
Data Dictionary
Hierarchy of Data Analysis
“Out of the box”Physical Data Model
Logical Data Model(normalised)
Conceptual Data Model
Data Dictionary
Otherwise, there will be a significant gap between
the PDM and the business needs it should support
Hierarchy of Data Analysis
“Out of the box”Physical Data Model
Logical Data Model(normalised)
Conceptual Data Model
Data Dictionary
Otherwise, there will be a significant gap between
the PDM and the business needs it should support
Hierarchy of Data Analysis
“Out of the box”Physical
Data Model
Logical Data Model(normalised)
Conceptual Data Model
Data Dictionary
Once in production, this gap eventually becomes a chasm
Hierarchy of Data Analysis
And, financially, that chasm can feel like a
bottomless pit
REMEMBER!
Screen Specification(fields, etc., required for screens)
Physical Data Model€
€
€$$ $
£ £
£
REMEMBER!
Functional Specification(data required for process steps)
Screen Specification(fields, etc., required for screens)
Physical Data Model€ €
$
$£
£
REMEMBER!
Logical Data Model(normalised)
Data Dictionary
Functional Specification(data required for process steps)
Screen Specification(fields, etc., required for screens)
Conceptual Data Model
Physical Data Model
€
$
£
REMEMBER
“Out of the box”Physical
Data Model
Logical Data Model(normalised)
Conceptual Data Model
Data Dictionary€€
€$$ $
£ £
£
REMEMBER!
“Out of the box”Physical Data Model
Logical Data Model(normalised)
Conceptual Data Model
Data Dictionary
€
$
£
With thanks to the following for reviewing the draft slideshow:
• Simon Duckett, Enterprise Data Architect• Jonathan Hunsley, Senior Business Architect
www.chellar.com/blog