The Importance of Data Analysis in Producing a Robust Physical Data Model

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