This slideshow is an introduction to the importance of data analysis in producing a robust physical data model and the hierarchy of the levels of analysis. The intended audience is software requirements analysts.
Tata AIG General Insurance Company - Insurer Innovation Award 2024
The Importance of Data Analysis in Producing a Robust Physical Data Model
1. The Importance of Data Analysis in Producing a Robust Physical Data Model By Declan Chellar
2. Hierarchy of Data Analysis When “data modelling” is mentioned on projects…
3. Hierarchy of Data Analysis When “data modelling” is mentioned on projects… Physical Data Model …too many people only think of the physical data model, DB tables, etc.
4. Hierarchy of Data Analysis When “data modelling” is mentioned on projects… Physical Data Model …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?
5.
6.
7. Identifies the business entities and shows the relationships between themConceptual Data Model
22. Expands upon the CDM by identifying the attributes of each entity and the keys to each relationshipConceptual Data Model Logical Data Model (normalised)
23.
24. Expands upon the CDM by identifying the attributes of each entity and the keys to each relationship
25. Normalised to reduce redundancyConceptual Data Model Logical Data Model (normalised)
26.
27. Expands upon the CDM by identifying the attributes of each entity and the keys to each relationship
33. Ideally in place before any related software project even starts
34. In reality, often missing altogetherConceptual Data Model Logical Data Model (normalised)
35.
36.
37. Provides the essential business definitions for each attribute identified on the LDMConceptual Data Model Logical Data Model (normalised) Data Dictionary
53. Ideally in place before any related software project even starts
54. Can be enhanced iteratively throughout requirements gathering
55. In reality, often missing altogetherConceptual Data Model Logical Data Model (normalised) Data Dictionary
56.
57.
58. For any process step, identifies the relevant attributesConceptual Data Model Logical Data Model (normalised) Data Dictionary Process Steps (data in/out at the functional level)
61. Traceable to/from the Data DictionaryConceptual Data Model Logical Data Model (normalised) Data Dictionary Process Steps (data in/out at the functional level)
65. Its elaboration can feed details back into the Data DictionaryConceptual Data Model Logical Data Model (normalised) Data Dictionary Process Steps (data in/out at the functional level)
69. Its elaboration can feed details back into the Data Dictionary
70. In reality, often contains details that should reside in the Data Dictionary, leading to redundancyConceptual Data Model Logical Data Model (normalised) Data Dictionary Process Steps (data in/out at the functional level)
71.
72.
73. Documents the required behaviour of each screen and the relevant data to be displayed or captured (not to be confused with screen design/layout)Conceptual Data Model Logical Data Model (normalised) Data Dictionary Process Steps (data in/out at the functional level) Screen Specification (fields, etc., required for screens)
74.
75. Documents the required behaviour of each screen and the relevant data to be displayed or captured (not to be confused with screen design/layout)
76. Its elaboration can feed details back into the Data DictionaryConceptual Data Model Logical Data Model (normalised) Data Dictionary Process Steps (data in/out at the functional level) Screen Specification (fields, etc., required for screens)
77.
78. Documents the required behaviour of each screen and the relevant data to be displayed or captured (not to be confused with screen design/layout)
79. Its elaboration can feed details back into the Data Dictionary
80. Should be documented after the relevant logical process stepsConceptual Data Model Logical Data Model (normalised) Data Dictionary Process Steps (data in/out at the functional level) Screen Specification (fields, etc., required for screens)
81.
82. Documents the required behaviour of each screen and the relevant data to be displayed or captured (not to be confused with screen design/layout)
83. Its elaboration can feed details back into the Data Dictionary
85. In reality, often contains details that should reside in the Data Dictionary, leading to redundancyConceptual Data Model Logical Data Model (normalised) Data Dictionary Process Steps (data in/out at the functional level) Screen Specification (fields, etc., required for screens)
86. Hierarchy of Data Analysis Conceptual Data Model Robust data analysis provides the basis for good physical data modelling Logical Data Model (normalised) Data Dictionary Process Steps (data in/out at the functional level) Screen Specification (fields, etc., required for screens)
87. Hierarchy of Data Analysis Conceptual Data Model Robust data analysis provides the basis for good physical data modelling Logical Data Model (normalised) Data Dictionary Otherwise, the data architects might have to reverse-engineer the data needs of the business based on screen designs Process Steps (data in/out at the functional level) Screen Specification (fields, etc., required for screens)
88. Hierarchy of Data Analysis Conceptual Data Model Physical Data Model Logical Data Model (normalised) Data Dictionary Process Steps (data in/out at the functional level) Screen Specification (fields, etc., required for screens)
89. Hierarchy of Data Analysis Conceptual Data Model Physical Data Model Logical Data Model (normalised) Data Dictionary This takes a little longer, but results in a robust, adaptable and durable physical data model Process Steps (data in/out at the functional level) Screen Specification (fields, etc., required for screens)
90. Hierarchy of Data Analysis Physical Data Model Process Steps (data in/out at the functional level) Screen Specification (fields, etc., required for screens)
91. Hierarchy of Data Analysis This is sub-optimal and is likely to result in an inefficient database that will under-perform as it grows larger Physical Data Model Process Steps (data in/out at the functional level) Screen Specification (fields, etc., required for screens)
92. Hierarchy of Data Analysis This is sub-optimal and is likely to result in an inefficient database that will under-perform as it grows larger Physical Data Model Unfortunately, this approach is quite common Process Steps (data in/out at the functional level) Screen Specification (fields, etc., required for screens)
93. Hierarchy of Data Analysis Physical Data Model Screen Specification (fields, etc., required for screens)
94. Hierarchy of Data Analysis This worst-case-scenario will definitely lead to an under-performing database within as little as six months Physical Data Model Screen Specification (fields, etc., required for screens)
95. Hierarchy of Data Analysis This worst-case-scenario will definitely lead to an under-performing database within as little as six months Physical Data Model Unfortunately, this approach is not uncommon Screen Specification (fields, etc., required for screens)
96. Hierarchy of Data Analysis Of course, physical data models often come “out of the box” in the case of BPM or ERP systems
97. 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
98. Hierarchy of Data Analysis “Out of the box” Physical Data Model The PDM must be tailored to suit the specific needs of the business
99. Hierarchy of Data Analysis “Out of the box” Physical Data Model Conceptual Data Model Logical Data Model (normalised) Data Dictionary
100. Hierarchy of Data Analysis “Out of the box” Physical Data Model Conceptual Data Model Logical Data Model (normalised) Data Dictionary Otherwise, there will be a significant gap between the PDM and the business needs it should support
101. Hierarchy of Data Analysis “Out of the box” Physical Data Model Conceptual Data Model Logical Data Model (normalised) Data Dictionary Otherwise, there will be a significant gap between the PDM and the business needs it should support
102. Hierarchy of Data Analysis “Out of the box” Physical Data Model Conceptual Data Model Logical Data Model (normalised) Data Dictionary Once in production, this gap eventually becomes a chasm
103. Hierarchy of Data Analysis And, financially, that chasm can feel like a bottomless pit
104. REMEMBER! € £ Physical Data Model $ $ € $ £ £ € Screen Specification (fields, etc., required for screens)
105. REMEMBER! Physical Data Model £ $ £ € $ € Functional Specification (data required for process steps) Screen Specification (fields, etc., required for screens)
106. REMEMBER! Conceptual Data Model Physical Data Model £ Logical Data Model (normalised) Data Dictionary $ Functional Specification (data required for process steps) € Screen Specification (fields, etc., required for screens)
107. REMEMBER € £ “Out of the box” Physical Data Model $ $ Conceptual Data Model € $ Logical Data Model (normalised) £ £ € Data Dictionary
108. REMEMBER! £ “Out of the box” Physical Data Model Conceptual Data Model $ Logical Data Model (normalised) Data Dictionary €