Lecture 09 dblc centralized vs decentralized design

4,635 views

Published on

Published in: Education
  • Be the first to comment

  • Be the first to like this

Lecture 09 dblc centralized vs decentralized design

  1. 1. Lecture 9 Database Design DBLC and Centralized vs Decentralize Design
  2. 2. <ul><li>Data </li></ul><ul><ul><li>Raw facts stored in databases </li></ul></ul><ul><ul><li>Need additional processing to become useful </li></ul></ul><ul><li>Information </li></ul><ul><ul><li>Required by decision maker </li></ul></ul><ul><ul><li>Data processed and presented in a meaningful form </li></ul></ul><ul><ul><li>Transformation </li></ul></ul>Changing Data into Information
  3. 3. <ul><li>Database </li></ul><ul><ul><li>Carefully designed and constructed repository of facts </li></ul></ul><ul><ul><li>Part of an information system </li></ul></ul><ul><li>Information System </li></ul><ul><ul><li>Provides data collection, storage, and retrieval </li></ul></ul><ul><ul><li>Facilitates data transformation </li></ul></ul><ul><ul><li>Components include: </li></ul></ul><ul><ul><ul><ul><li>People </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Hardware </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Software </li></ul></ul></ul></ul>The Information System <ul><li>Database(s) </li></ul><ul><li>Application programs </li></ul><ul><li>Procedures </li></ul>
  4. 4. <ul><li>System Analysis </li></ul><ul><ul><li>Establishes need and extent of an information system </li></ul></ul><ul><li>Systems development </li></ul><ul><ul><li>Process of creating information system </li></ul></ul><ul><li>Database development </li></ul><ul><ul><li>Process of database design and implementation </li></ul></ul><ul><ul><li>Creation of database models </li></ul></ul><ul><ul><li>Implementation </li></ul></ul><ul><ul><ul><li>Creating storage structure </li></ul></ul></ul><ul><ul><ul><li>Loading data into database </li></ul></ul></ul><ul><ul><ul><li>Providing for data management </li></ul></ul></ul>The Information System (Con’t.)
  5. 5. Systems Development Life Cycle Figure 6.2
  6. 6. Database Lifecycle (DBLC) Figure 6.3
  7. 7. Phase 1: Database Initial Study <ul><li>Purposes </li></ul><ul><ul><li>Analyze company situation </li></ul></ul><ul><ul><ul><li>Operating environment </li></ul></ul></ul><ul><ul><ul><li>Organizational structure </li></ul></ul></ul><ul><ul><li>Define problems and constraints </li></ul></ul><ul><ul><li>Define objectives </li></ul></ul><ul><ul><li>Define scope and boundaries </li></ul></ul>
  8. 8. Initial Study Activities Figure 6.4
  9. 9. Phase 2: Database Design <ul><li>Most Critical DBLC phase </li></ul><ul><li>Makes sure final product meets requirements </li></ul><ul><li>Focus on data requirements </li></ul><ul><li>Subphases </li></ul><ul><ul><li>Create conceptual design </li></ul></ul><ul><ul><li>DBMS software selection </li></ul></ul><ul><ul><li>Create logical design </li></ul></ul><ul><ul><li>Create physical design </li></ul></ul>
  10. 10. Two Views of Data Figure 6.5
  11. 11. I. Conceptual Design <ul><li>Data modeling creates abstract data structure to represent real-world items </li></ul><ul><li>High level of abstraction </li></ul><ul><li>Four steps </li></ul><ul><ul><li>Data analysis and requirements </li></ul></ul><ul><ul><li>Entity relationship modeling and normalization </li></ul></ul><ul><ul><li>Data model verification </li></ul></ul><ul><ul><li>Distributed database design </li></ul></ul>
  12. 12. Data analysis and Requirements <ul><li>Focus on: </li></ul><ul><ul><li>Information needs </li></ul></ul><ul><ul><li>Information users </li></ul></ul><ul><ul><li>Information sources </li></ul></ul><ul><ul><li>Information constitution </li></ul></ul><ul><li>Data sources </li></ul><ul><ul><li>Developing and gathering end-user data views </li></ul></ul><ul><ul><li>Direct observation of current system </li></ul></ul><ul><ul><li>Interfacing with systems design group </li></ul></ul><ul><li>Business rules </li></ul>
  13. 13. Entity Relationship Modeling and Normalization Table 6.2
  14. 14. E-R Modeling is Iterative Figure 6.8
  15. 15. Concept Design: Tools and Sources Figure 6.9
  16. 16. Data Model Verification <ul><li>E-R model is verified against proposed system processes </li></ul><ul><ul><li>End user views and required transactions </li></ul></ul><ul><ul><li>Access paths, security, concurrency control </li></ul></ul><ul><ul><li>Business-imposed data requirements and constraints </li></ul></ul><ul><li>Reveals additional entity and attribute details </li></ul><ul><li>Define major components as modules </li></ul><ul><ul><li>Cohesivity </li></ul></ul><ul><ul><li>Coupling </li></ul></ul>
  17. 17. E-R Model Verification Process Table 6.4
  18. 18. Iterative Process of Verification Figure 6.10
  19. 19. Distributed Database Design <ul><li>Design portions in different physical locations </li></ul><ul><li>Development of data distribution and allocation strategies </li></ul>
  20. 20. II. DBMS Software Selection <ul><li>DBMS software selection is critical </li></ul><ul><li>Advantages and disadvantages need study </li></ul><ul><li>Factors affecting purchasing decision </li></ul><ul><ul><li>Cost </li></ul></ul><ul><ul><li>DBMS features and tools </li></ul></ul><ul><ul><li>Underlying model </li></ul></ul><ul><ul><li>Portability </li></ul></ul><ul><ul><li>DBMS hardware requirements </li></ul></ul>
  21. 21. III. Logical Design <ul><li>Translates conceptual design into internal model </li></ul><ul><li>Maps objects in model to specific DBMS constructs </li></ul><ul><li>Design components </li></ul><ul><ul><li>Tables </li></ul></ul><ul><ul><li>Indexes </li></ul></ul><ul><ul><li>Views </li></ul></ul><ul><ul><li>Transactions </li></ul></ul><ul><ul><li>Access authorities </li></ul></ul><ul><ul><li>Others </li></ul></ul>
  22. 22. IV. Physical Design <ul><li>Selection of data storage and access characteristics </li></ul><ul><ul><li>Very technical </li></ul></ul><ul><ul><li>More important in older hierarchical and network models </li></ul></ul><ul><li>Becomes more complex for distributed systems </li></ul><ul><li>Designers favor software that hides physical details </li></ul>
  23. 23. Physical Organization Figure 6.12
  24. 24. Phase 3: Implementation and Loading <ul><li>Creation of special storage-related constructs </li></ul><ul><li>to house end-user tables </li></ul><ul><li>Data loaded into tables </li></ul><ul><li>Other issues </li></ul><ul><ul><li>Performance </li></ul></ul><ul><ul><li>Security </li></ul></ul><ul><ul><li>Backup and recovery </li></ul></ul><ul><ul><li>Integrity </li></ul></ul><ul><ul><li>Company standards </li></ul></ul><ul><ul><li>Concurrency controls </li></ul></ul>
  25. 25. Phase 4: Testing and Evaluation <ul><li>Database is tested and fine-tuned for performance, integrity, concurrent access, and security constraints </li></ul><ul><li>Done in parallel with application programming </li></ul><ul><li>Actions taken if tests fail </li></ul><ul><ul><li>Fine-tuning based on reference manuals </li></ul></ul><ul><ul><li>Modification of physical design </li></ul></ul><ul><ul><li>Modification of logical design </li></ul></ul><ul><ul><li>Upgrade or change DBMS software or hardware </li></ul></ul>
  26. 26. Phase 5: Operation <ul><li>Database considered operational </li></ul><ul><li>Starts process of system evaluation </li></ul><ul><li>Unforeseen problems may surface </li></ul><ul><li>Demand for change is constant </li></ul>
  27. 27. Phase 6: Maintenance and Evaluation <ul><li>Preventative maintenance </li></ul><ul><li>Corrective maintenance </li></ul><ul><li>Adaptive maintenance </li></ul><ul><li>Assignment of access permissions </li></ul><ul><li>Generation of database access statistics to monitor performance </li></ul><ul><li>Periodic security audits based on system-generated statistics </li></ul><ul><li>Periodic system usage-summaries </li></ul>
  28. 28. DB Design Strategy Notes <ul><li>Top-down </li></ul><ul><ul><li>1) Identify data sets </li></ul></ul><ul><ul><li>2) Define data elements </li></ul></ul><ul><li>Bottom-up </li></ul><ul><ul><li>1) Identify data elements </li></ul></ul><ul><ul><li>2) Group them into data sets </li></ul></ul>
  29. 29. Top-Down vs. Bottom-Up Figure 6.14
  30. 30. Centralized vs. Decentralized Design <ul><li>Centralized design </li></ul><ul><ul><li>Typical of simple databases </li></ul></ul><ul><ul><li>Conducted by single person or small team </li></ul></ul><ul><li>Decentralized design </li></ul><ul><ul><li>Larger numbers of entities and complex relations </li></ul></ul><ul><ul><li>Spread across multiple sites </li></ul></ul><ul><ul><li>Developed by teams </li></ul></ul>
  31. 31. Centralized Design
  32. 32. Decentralized Design Figure 6.16
  33. 33. Centralized vs. Decentralized Design (continued) <ul><li>Aggregation process </li></ul><ul><ul><li>Requires designer to create single model in which various aggregation problems must be addressed: </li></ul></ul><ul><ul><ul><li>Synonyms and homonyms </li></ul></ul></ul><ul><ul><ul><li>Entity and entity subtypes </li></ul></ul></ul><ul><ul><ul><li>Conflicting object definitions </li></ul></ul></ul>
  34. 34. Centralized vs. Decentralized Design (continued)

×