1 / 18

Database Design Process (Chapter 3)

Database Design Process (Chapter 3). Peter Rob and Elie Semaan Databases: Design, Development, and Deployment Using Microsoft Access Second Edition. System Development. Any production database system -- a reality, you must follow a carefully defined plan. This plan

Download Presentation

Database Design Process (Chapter 3)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Database Design Process(Chapter 3) Peter Rob and Elie SemaanDatabases: Design, Development,and DeploymentUsing Microsoft Access Second Edition

  2. System Development Any production database system -- a reality, you must follow a carefully defined plan. This plan reflects the notion that a database’s successful design, its implementation, and its applications development require the successful completion of the following steps:

  3. System Development (Cont) • Write a detailed and accurate description of business operations • Develop an extensive and precisely written set of business rules based on the description of business operations. • Define the major transaction modules. In the POS system these modules define sales, inventory management, shipping, back ordering, and product returns.

  4. System Development (Cont) • Define the entities, attributes, relationships, connectivities, cardinalities, and constraints for each module defined in step 3. Use the business rules developed in step 2 as the source for your component definitions. • Create the initial ERD segments to model the modules you defined in step 4. Remember that each of the ERD’s entities will be implemented through a database table. The coverage of ERDs in Chapter 1 will be your guide to completing this step successfully.

  5. System Development (Cont) 6. Create a basic data dictionary for all the components found in each ERD segment. At the initial design stage, the data dictionary is a document that precisely describes each attribute’s characteristics. Table 3.1 shows a few sample data dictionary entries. Keep in mind that the amount of detail in the data dictionary is important. More detail is always better than less detail. (Note that items of special interest are highlighted.)

  6. Data Dictionary Entries for the Two Entities

  7. Data Dictionary Entries for the Two Entities (Cont)

  8. Data Dictionary Entries for the Two Entities (Cont)

  9. System Development (Cont) • Perform the appropriate normalization checks based on the data dictionary contents. The successful completion of this step requires the knowledge you gained in Chapter 2. • If necessary, modify the ERD segments you developed in step 5 to reflect the normalization findings in step 7.

  10. System Development (Cont) • Link all the ERD segments created in step 5 and (possibly) modified in step 8 to produce the initial ERD for the entire database. You will use the techniques learned in Chapter 1 to complete this step. • Check the normal forms again to make sure that they are appropriate. • Complete the final ERD.

  11. System Development (Cont) 12. Perform a final review of the data dictionary contents. Examine all table structures, all attribute characteristics, and the relationships as expressed by FKs. 13. Implement the database based on steps 11 and 12. Make sure that entity integrity and referential integrity are maintained. You will learn how to implement a database in Chapter 4.

  12. System Development (Cont) 14. Create the end-user interface to “connect” the end user to the database. This step requires the creation of the basic end-user components: forms, queries, and reports. You will learn how to accomplish these tasks in Chapters 5, 6, and 7. 15. Create the database system by connecting all the system components. In Chapter 8 you will learn how to use macros, stored in macro groups, to do this job.

  13. System Development (Cont) 16. Verify the implementation and applications development for each module against the business rules and the end-user requirements derived from the description of operations. In Chapter 9 you will see how to approach this task. 17. Create a security system to protect the database from improper and/or unauthorized use. You will learn how to create a full-blown database administrator’s security environment in Chapter 10.

  14. System Development (Cont) 18. Test the system thoroughly. This step requires that you put your own database through its paces. We suggest that you let other testers use your database system for a while to see how well it works. It’s always best to discover and fix problems before you deliver the final product!

  15. The Description of Operations • If this description of operation is not prepared • properly, the database design is likely to fail. • A good description of operations contains at least • a detailed and accurate picture of the business • type, business objectives, organizational • hierarchy, data environment, available resources, • current operations, current problems and • proposed solutions, and limitations.

  16. The Description of Operations (Cont) Business Type • The business type must be classified and • described precisely to determine the • Number and types of entities. • Data type (s) and characteristics. • In short, the business type helps establish the data requirements

  17. The Description of Operations (Cont) Business Objectives • The business objectives must be synchronized with its business type. • The business objectives must be described precisely and in detail. Because the business objectives are so closely tied to the business type, they help audit the initial database components. • The business objectives should not yield database components that are in conflict with those required by the business type.

  18. The END

More Related