The Importance of Data Analysis in Producing a Robust Physical Data Model<br />By Declan Chellar<br />
Hierarchy of Data Analysis<br />When “data modelling” is mentioned on projects…<br />
Hierarchy of Data Analysis<br />When “data modelling” is mentioned on projects…<br />Physical Data Model<br />…too many pe...
Hierarchy of Data Analysis<br />When “data modelling” is mentioned on projects…<br />Physical Data Model<br />…too many pe...
Hierarchy of Data Analysis<br /><ul><li>A fundamental part of the information architecture</li></ul>Conceptual Data Model<...
Hierarchy of Data Analysis<br /><ul><li>A fundamental part of the information architecture
Identifies the business entities and shows the relationships between them</li></ul>Conceptual Data Model<br />
Hierarchy of Data Analysis<br /><ul><li>A fundamental part of the information architecture
Identifies the business entities and shows the relationships between them
An essential complement to the business architecture</li></ul>Conceptual Data Model<br />
Hierarchy of Data Analysis<br /><ul><li>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!</li></ul>Conceptual Data Model<br />
Hierarchy of Data Analysis<br /><ul><li>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</li></ul>Conceptual Data Model<br />
Hierarchy of Data Analysis<br /><ul><li>A fundamental part of the information architecture</li></ul>Conceptual Data Model<...
Hierarchy of Data Analysis<br /><ul><li>A fundamental part of the information architecture
Expands upon the CDM by identifying the attributes of each entity and the keys to each relationship</li></ul>Conceptual Da...
Hierarchy of Data Analysis<br /><ul><li>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</li></ul>Conceptual Data Model<br />Logical Data Model<br />(normalised)<br />
Hierarchy of Data Analysis<br /><ul><li>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</li></ul>Conceptual Data Model<br />Logical Data Model<br...
Hierarchy of Data Analysis<br /><ul><li>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</li></ul>Conceptual Data Model<br />Logical Data Model<br />(normalised)<br />
Hierarchy of Data Analysis<br /><ul><li>A fundamental part of the information architecture</li></ul>Conceptual Data Model<...
Hierarchy of Data Analysis<br /><ul><li>A fundamental part of the information architecture
Provides the essential business definitions for each attribute identified on the LDM</li></ul>Conceptual Data Model<br />L...
Hierarchy of Data Analysis<br /><ul><li>A fundamental part of the information architecture
Provides the essential business definitions for each attribute identified on the LDM
Traceable back to the LDM</li></ul>Conceptual Data Model<br />Logical Data Model<br />(normalised)<br />Data Dictionary<br />
Hierarchy of Data Analysis<br /><ul><li>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</li></ul>Conceptual Data Model<br />Logical Data Model<br...
Hierarchy of Data Analysis<br /><ul><li>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</li></ul>Conceptual Data Model<br />Logical Data Model<br />...
Hierarchy of Data Analysis<br /><ul><li>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</li></ul>Conceptual Data Model<br />Logical Data Model<br />(normalised)<br />Data Di...
Upcoming SlideShare
Loading in …5
×

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

3,657 views

Published on

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.

Published in: Technology, Business
  • sorry,it's ok now
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • I'm sorry but page32 can't display.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • IAG, the second half of the original version has now been expanded and split off into its own slideshow titled 'Tracing Data Requirements'.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Thanks, IAG. That was just the draft. I have since had feedback from a couple of former colleagues, one an Enterprise Data Architect and one a Senior Business Architect. Based on their comments, I have split it into two slideshows, the first showing the hierarchy of data analysis and the second showing the process for traceability. I have also updated some of the slides.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Nice job. Well done. And like the final editorial bullets on each of the slides.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

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

  1. 1. The Importance of Data Analysis in Producing a Robust Physical Data Model<br />By Declan Chellar<br />
  2. 2. Hierarchy of Data Analysis<br />When “data modelling” is mentioned on projects…<br />
  3. 3. Hierarchy of Data Analysis<br />When “data modelling” is mentioned on projects…<br />Physical Data Model<br />…too many people only think of the physical data model, DB tables, etc.<br />
  4. 4. Hierarchy of Data Analysis<br />When “data modelling” is mentioned on projects…<br />Physical Data Model<br />…too many people only think of the physical data model, DB tables, etc.<br />But what about the data analysis that leads to a robust physical data model?<br />
  5. 5. Hierarchy of Data Analysis<br /><ul><li>A fundamental part of the information architecture</li></ul>Conceptual Data Model<br />
  6. 6. Hierarchy of Data Analysis<br /><ul><li>A fundamental part of the information architecture
  7. 7. Identifies the business entities and shows the relationships between them</li></ul>Conceptual Data Model<br />
  8. 8. Hierarchy of Data Analysis<br /><ul><li>A fundamental part of the information architecture
  9. 9. Identifies the business entities and shows the relationships between them
  10. 10. An essential complement to the business architecture</li></ul>Conceptual Data Model<br />
  11. 11. Hierarchy of Data Analysis<br /><ul><li>A fundamental part of the information architecture
  12. 12. Identifies the business entities and shows the relationships between them
  13. 13. An essential complement to the business architecture
  14. 14. Ought to be in place before any related software project even starts!</li></ul>Conceptual Data Model<br />
  15. 15. Hierarchy of Data Analysis<br /><ul><li>A fundamental part of the information architecture
  16. 16. Identifies the business entities and shows the relationships between them
  17. 17. An essential complement to the business architecture
  18. 18. Ought to be in place before any related software project even starts
  19. 19. In reality, often missing altogether</li></ul>Conceptual Data Model<br />
  20. 20. Hierarchy of Data Analysis<br /><ul><li>A fundamental part of the information architecture</li></ul>Conceptual Data Model<br />Logical Data Model<br />(normalised)<br />
  21. 21. Hierarchy of Data Analysis<br /><ul><li>A fundamental part of the information architecture
  22. 22. Expands upon the CDM by identifying the attributes of each entity and the keys to each relationship</li></ul>Conceptual Data Model<br />Logical Data Model<br />(normalised)<br />
  23. 23. Hierarchy of Data Analysis<br /><ul><li>A fundamental part of the information architecture
  24. 24. Expands upon the CDM by identifying the attributes of each entity and the keys to each relationship
  25. 25. Normalised to reduce redundancy</li></ul>Conceptual Data Model<br />Logical Data Model<br />(normalised)<br />
  26. 26. Hierarchy of Data Analysis<br /><ul><li>A fundamental part of the information architecture
  27. 27. Expands upon the CDM by identifying the attributes of each entity and the keys to each relationship
  28. 28. Normalised to reduce redundancy
  29. 29. Ideally in place before any related software project even starts</li></ul>Conceptual Data Model<br />Logical Data Model<br />(normalised)<br />
  30. 30. Hierarchy of Data Analysis<br /><ul><li>A fundamental part of the information architecture
  31. 31. Expands upon the CDM by identifying the attributes of each entity and the keys to each relationship
  32. 32. Normalised to reduce redundancy
  33. 33. Ideally in place before any related software project even starts
  34. 34. In reality, often missing altogether</li></ul>Conceptual Data Model<br />Logical Data Model<br />(normalised)<br />
  35. 35. Hierarchy of Data Analysis<br /><ul><li>A fundamental part of the information architecture</li></ul>Conceptual Data Model<br />Logical Data Model<br />(normalised)<br />Data Dictionary<br />
  36. 36. Hierarchy of Data Analysis<br /><ul><li>A fundamental part of the information architecture
  37. 37. Provides the essential business definitions for each attribute identified on the LDM</li></ul>Conceptual Data Model<br />Logical Data Model<br />(normalised)<br />Data Dictionary<br />
  38. 38. Hierarchy of Data Analysis<br /><ul><li>A fundamental part of the information architecture
  39. 39. Provides the essential business definitions for each attribute identified on the LDM
  40. 40. Traceable back to the LDM</li></ul>Conceptual Data Model<br />Logical Data Model<br />(normalised)<br />Data Dictionary<br />
  41. 41. Hierarchy of Data Analysis<br /><ul><li>A fundamental part of the information architecture
  42. 42. Provides the essential business definitions for each attribute identified on the LDM
  43. 43. Traceable back to the LDM
  44. 44. Ideally in place before any related software project even starts</li></ul>Conceptual Data Model<br />Logical Data Model<br />(normalised)<br />Data Dictionary<br />
  45. 45. Hierarchy of Data Analysis<br /><ul><li>A fundamental part of the information architecture
  46. 46. Provides the essential business definitions for each attribute identified on the LDM
  47. 47. Traceable back to the LDM
  48. 48. Ideally in place before any related software project even starts
  49. 49. Can be enhanced iteratively throughout requirements gathering</li></ul>Conceptual Data Model<br />Logical Data Model<br />(normalised)<br />Data Dictionary<br />
  50. 50. Hierarchy of Data Analysis<br /><ul><li>A fundamental part of the information architecture
  51. 51. Provides the essential business definitions for each attribute identified on the LDM
  52. 52. Traceable back to the LDM
  53. 53. Ideally in place before any related software project even starts
  54. 54. Can be enhanced iteratively throughout requirements gathering
  55. 55. In reality, often missing altogether</li></ul>Conceptual Data Model<br />Logical Data Model<br />(normalised)<br />Data Dictionary<br />
  56. 56. Hierarchy of Data Analysis<br /><ul><li>A fundamental part of the requirements definition</li></ul>Conceptual Data Model<br />Logical Data Model<br />(normalised)<br />Data Dictionary<br />Process Steps<br />(data in/out at the functional level)<br />
  57. 57. Hierarchy of Data Analysis<br /><ul><li>A fundamental part of the requirements definition
  58. 58. For any process step, identifies the relevant attributes</li></ul>Conceptual Data Model<br />Logical Data Model<br />(normalised)<br />Data Dictionary<br />Process Steps<br />(data in/out at the functional level)<br />
  59. 59. Hierarchy of Data Analysis<br /><ul><li>A fundamental part of the requirements definition
  60. 60. For any process step, identifies the relevant attributes
  61. 61. Traceable to/from the Data Dictionary</li></ul>Conceptual Data Model<br />Logical Data Model<br />(normalised)<br />Data Dictionary<br />Process Steps<br />(data in/out at the functional level)<br />
  62. 62. Hierarchy of Data Analysis<br /><ul><li>A fundamental part of the requirements definition
  63. 63. For any process step, identifies the relevant attributes
  64. 64. Traceable to/from the Data Dictionary
  65. 65. Its elaboration can feed details back into the Data Dictionary</li></ul>Conceptual Data Model<br />Logical Data Model<br />(normalised)<br />Data Dictionary<br />Process Steps<br />(data in/out at the functional level)<br />
  66. 66. Hierarchy of Data Analysis<br /><ul><li>A fundamental part of the requirements definition
  67. 67. For any process step, identifies the relevant attributes
  68. 68. Traceable to/from the Data Dictionary
  69. 69. Its elaboration can feed details back into the Data Dictionary
  70. 70. In reality, often contains details that should reside in the Data Dictionary, leading to redundancy</li></ul>Conceptual Data Model<br />Logical Data Model<br />(normalised)<br />Data Dictionary<br />Process Steps<br />(data in/out at the functional level)<br />
  71. 71. Hierarchy of Data Analysis<br /><ul><li>A fundamental part of the requirements definition</li></ul>Conceptual Data Model<br />Logical Data Model<br />(normalised)<br />Data Dictionary<br />Process Steps<br />(data in/out at the functional level)<br />Screen Specification<br />(fields, etc., required for screens)<br />
  72. 72. Hierarchy of Data Analysis<br /><ul><li>A fundamental part of the requirements definition
  73. 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)</li></ul>Conceptual Data Model<br />Logical Data Model<br />(normalised)<br />Data Dictionary<br />Process Steps<br />(data in/out at the functional level)<br />Screen Specification<br />(fields, etc., required for screens)<br />
  74. 74. Hierarchy of Data Analysis<br /><ul><li>A fundamental part of the requirements definition
  75. 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. 76. Its elaboration can feed details back into the Data Dictionary</li></ul>Conceptual Data Model<br />Logical Data Model<br />(normalised)<br />Data Dictionary<br />Process Steps<br />(data in/out at the functional level)<br />Screen Specification<br />(fields, etc., required for screens)<br />
  77. 77. Hierarchy of Data Analysis<br /><ul><li>A fundamental part of the requirements definition
  78. 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. 79. Its elaboration can feed details back into the Data Dictionary
  80. 80. Should be documented after the relevant logical process steps</li></ul>Conceptual Data Model<br />Logical Data Model<br />(normalised)<br />Data Dictionary<br />Process Steps<br />(data in/out at the functional level)<br />Screen Specification<br />(fields, etc., required for screens)<br />
  81. 81. Hierarchy of Data Analysis<br /><ul><li>A fundamental part of the requirements definition
  82. 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. 83. Its elaboration can feed details back into the Data Dictionary
  84. 84. Should be documented after the relevant logical process steps
  85. 85. In reality, often contains details that should reside in the Data Dictionary, leading to redundancy</li></ul>Conceptual Data Model<br />Logical Data Model<br />(normalised)<br />Data Dictionary<br />Process Steps<br />(data in/out at the functional level)<br />Screen Specification<br />(fields, etc., required for screens)<br />
  86. 86. Hierarchy of Data Analysis<br />Conceptual Data Model<br />Robust data analysis provides the basis for good physical data modelling<br />Logical Data Model<br />(normalised)<br />Data Dictionary<br />Process Steps<br />(data in/out at the functional level)<br />Screen Specification<br />(fields, etc., required for screens)<br />
  87. 87. Hierarchy of Data Analysis<br />Conceptual Data Model<br />Robust data analysis provides the basis for good physical data modelling<br />Logical Data Model<br />(normalised)<br />Data Dictionary<br />Otherwise, the data architects might have to reverse-engineer the data needs of the business based on screen designs<br />Process Steps<br />(data in/out at the functional level)<br />Screen Specification<br />(fields, etc., required for screens)<br />
  88. 88. Hierarchy of Data Analysis<br />Conceptual Data Model<br />Physical Data Model<br />Logical Data Model<br />(normalised)<br />Data Dictionary<br />Process Steps<br />(data in/out at the functional level)<br />Screen Specification<br />(fields, etc., required for screens)<br />
  89. 89. Hierarchy of Data Analysis<br />Conceptual Data Model<br />Physical Data Model<br />Logical Data Model<br />(normalised)<br />Data Dictionary<br />This takes a little longer, but results in a robust, adaptable and durable physical data model<br />Process Steps<br />(data in/out at the functional level)<br />Screen Specification<br />(fields, etc., required for screens)<br />
  90. 90. Hierarchy of Data Analysis<br />Physical Data Model<br />Process Steps<br />(data in/out at the functional level)<br />Screen Specification<br />(fields, etc., required for screens)<br />
  91. 91. Hierarchy of Data Analysis<br />This is sub-optimal and is likely to result in an inefficient database that will under-perform as it grows larger<br />Physical Data Model<br />Process Steps<br />(data in/out at the functional level)<br />Screen Specification<br />(fields, etc., required for screens)<br />
  92. 92. Hierarchy of Data Analysis<br />This is sub-optimal and is likely to result in an inefficient database that will under-perform as it grows larger<br />Physical Data Model<br />Unfortunately, this approach is quite common<br />Process Steps<br />(data in/out at the functional level)<br />Screen Specification<br />(fields, etc., required for screens)<br />
  93. 93. Hierarchy of Data Analysis<br />Physical Data Model<br />Screen Specification<br />(fields, etc., required for screens)<br />
  94. 94. Hierarchy of Data Analysis<br />This worst-case-scenario will definitely lead to an under-performing database within as little as six months<br />Physical Data Model<br />Screen Specification<br />(fields, etc., required for screens)<br />
  95. 95. Hierarchy of Data Analysis<br />This worst-case-scenario will definitely lead to an under-performing database within as little as six months<br />Physical Data Model<br />Unfortunately, this approach is not uncommon<br />Screen Specification<br />(fields, etc., required for screens)<br />
  96. 96. Hierarchy of Data Analysis<br />Of course, physical data models often come “out of the box” in the case of BPM or ERP systems<br />
  97. 97. Hierarchy of Data Analysis<br />However, “out-of-the-box” does not mean “magic“ and the PDM does not automatically fit the data needs of the business<br />
  98. 98. Hierarchy of Data Analysis<br />“Out of the box”<br />Physical Data Model<br />The PDM must be tailored to suit the specific needs of the business<br />
  99. 99. Hierarchy of Data Analysis<br />“Out of the box”<br />Physical Data Model<br />Conceptual Data Model<br />Logical Data Model<br />(normalised)<br />Data Dictionary<br />
  100. 100. Hierarchy of Data Analysis<br />“Out of the box”<br />Physical Data Model<br />Conceptual Data Model<br />Logical Data Model<br />(normalised)<br />Data Dictionary<br />Otherwise, there will be a significant gap between the PDM and the business needs it should support<br />
  101. 101. Hierarchy of Data Analysis<br />“Out of the box”<br />Physical Data Model<br />Conceptual Data Model<br />Logical Data Model<br />(normalised)<br />Data Dictionary<br />Otherwise, there will be a significant gap between the PDM and the business needs it should support<br />
  102. 102. Hierarchy of Data Analysis<br />“Out of the box”<br />Physical Data Model<br />Conceptual Data Model<br />Logical Data Model<br />(normalised)<br />Data Dictionary<br />Once in production, this gap eventually becomes a chasm<br />
  103. 103. Hierarchy of Data Analysis<br />And, financially, that chasm can feel like a bottomless pit<br />
  104. 104. REMEMBER!<br />€<br />£<br />Physical Data Model<br />$<br />$<br />€<br />$<br />£<br />£<br />€<br />Screen Specification<br />(fields, etc., required for screens)<br />
  105. 105. REMEMBER!<br />Physical Data Model<br />£<br />$<br />£<br />€<br />$<br />€<br />Functional Specification<br />(data required for process steps)<br />Screen Specification<br />(fields, etc., required for screens)<br />
  106. 106. REMEMBER!<br />Conceptual Data Model<br />Physical Data Model<br />£<br />Logical Data Model<br />(normalised)<br />Data Dictionary<br />$<br />Functional Specification<br />(data required for process steps)<br />€<br />Screen Specification<br />(fields, etc., required for screens)<br />
  107. 107. REMEMBER<br />€<br />£<br />“Out of the box”<br />Physical Data Model<br />$<br />$<br />Conceptual Data Model<br />€<br />$<br />Logical Data Model<br />(normalised)<br />£<br />£<br />€<br />Data Dictionary<br />
  108. 108. REMEMBER!<br />£<br />“Out of the box”<br />Physical Data Model<br />Conceptual Data Model<br />$<br />Logical Data Model<br />(normalised)<br />Data Dictionary<br />€<br />
  109. 109. Withthanks to thefollowingforreviewingthedraftslideshow:<br /><ul><li>SimonDuckett, Enterprise Data Architect
  110. 110. Jonathan Hunsley,Senior Business Architect</li></li></ul><li>www.chellar.com/blog<br />

×