265 - Text - Chapter 4

265 - Text - Chapter 4 - Chapter 4: Physical Design for...

Info iconThis preview shows pages 1–3. Sign up to view the full content.

View Full Document Right Arrow Icon
Chapter 4: Physical Design for Database Systems 1 of 60 ADVANCED SYSTEMS ANALYSIS AND DESIGN by: Uday S. Murthy, Ph.D., ACA Physical Design for Database Systems Learning Objectives After studying this chapter you should be able to: o convert an extended entity relationship diagram to relational tables o articulate the conversion rules for mandatory relationships o articulate the conversion rules for optional relationships o explain the concept of database normalization o describe the rules for determining whether a table conforms to first, second, or third normal form o explain the process of implementing tables in a relational database system such as Microsoft Access o explain how forms in a relational database management system are used to implement information processes In the previous chapter, we discussed the logical design process for database systems, comprising logical data modeling (using EER diagrams) and logical process modeling (using DFDs). The nine-step event-oriented modeling approach was discussed. This chapter focuses on physical design--the last two steps in the nine-step process. Regarding step 8, we will first see how the logical data and process models (ER and DFD) are converted to physical models. Regarding step 9 of the event-oriented approach, we will discuss the specific steps needed to actually implement a design using a relational DBMS such as Microsoft Access. Whereas the logical design is independent of any particular implementation of the model, a physical design is tied to a particular implementation path. As we have alluded to earlier, the implementation mechanism we will focus on is relational database systems. We will show how DFDs map to forms in a relational DBMS, with form inputs and outputs mapping to tables in the database. The process of ensuring that tables in a relational database do not have any undesirable flaws, a process referred to as "database normalization," will also be discussed in this chapter.
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Chapter 4: Physical Design for Database Systems 2 of 60 Converting an EER diagram to relational tables--designing the data repository Step 8 in the event-oriented modeling approach involves the application of relatively straightforward rules for converting an EER diagram to tables. We first indicate the rules and then illustrate the application of the rules with examples. Note that the rules take into account (1) the optionality of relationships, and (2) the cardinality of relationships. We will first consider the case of mandatory relationships only. Conversion rules for mandatory relationships: 1. For one-to-one relationships: collapse the entities participating in the relationship into a single table, 2. For relationships other than one-to-one relationships, create a separate table for each entity, 3. Create fields for each table based on the attributes identified in the EER diagram, 4. Designate the primary key in each table based on the attributes identified in the EER diagram, 5. For one to many relationships: post the primary key of the table on the "one" side
Background image of page 2
Image of page 3
This is the end of the preview. Sign up to access the rest of the document.

This note was uploaded on 08/12/2008 for the course MBA 265 taught by Professor James during the Spring '08 term at CSU Sacramento.

Page1 / 60

265 - Text - Chapter 4 - Chapter 4: Physical Design for...

This preview shows document pages 1 - 3. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online