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.

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?

7. Identifies the business entities and shows the relationships between themConceptual Data Model

9. Identifies the business entities and shows the relationships between them

10. An essential complement to the business architectureConceptual Data Model

12. Identifies the business entities and shows the relationships between them

13. An essential complement to the business architecture

14. Ought to be in place before any related software project even starts!Conceptual Data Model

16. Identifies the business entities and shows the relationships between them

17. An essential complement to the business architecture

18. Ought to be in place before any related software project even starts

19. In reality, often missing altogetherConceptual 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)

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)

27. Expands upon the CDM by identifying the attributes of each entity and the keys to each relationship

28. Normalised to reduce redundancy

29. Ideally in place before any related software project even startsConceptual Data Model Logical Data Model (normalised)

31. Expands upon the CDM by identifying the attributes of each entity and the keys to each relationship

32. Normalised to reduce redundancy

33. Ideally in place before any related software project even starts

34. In reality, often missing altogetherConceptual Data Model Logical Data Model (normalised)

37. Provides the essential business definitions for each attribute identified on the LDMConceptual Data Model Logical Data Model (normalised) Data Dictionary

39. Provides the essential business definitions for each attribute identified on the LDM

40. Traceable back to the LDMConceptual Data Model Logical Data Model (normalised) Data Dictionary

42. Provides the essential business definitions for each attribute identified on the LDM

43. Traceable back to the LDM

44. Ideally in place before any related software project even startsConceptual Data Model Logical Data Model (normalised) Data Dictionary

46. Provides the essential business definitions for each attribute identified on the LDM

47. Traceable back to the LDM

48. Ideally in place before any related software project even starts

49. Can be enhanced iteratively throughout requirements gatheringConceptual Data Model Logical Data Model (normalised) Data Dictionary

51. Provides the essential business definitions for each attribute identified on the LDM

52. Traceable back to the LDM

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

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)

60. For any process step, identifies the relevant attributes

61. Traceable to/from the Data DictionaryConceptual Data Model Logical Data Model (normalised) Data Dictionary Process Steps (data in/out at the functional level)

63. For any process step, identifies the relevant attributes

64. Traceable to/from the Data Dictionary

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)

67. For any process step, identifies the relevant attributes

68. Traceable to/from the Data Dictionary

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)

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)

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)

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)

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

84. Should be documented after the relevant logical process steps

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 €