Database Design Using Entity-Relationship Diagrams phần 6 pot

Replaced with Two 1:M Relationships Now that we have a STUDENT+COURSE entity (an intersecting entity), our grammatical description of this intersecting entity would be: The Entity This database records data about STUDENT–COURSE combinations — STUDENT+COURSE. For each STUDENT+COURSE in the database, we record a grade. The Attributes For each STUDENT+COURSE, there always will be one and only one grade for each STUDENT+COURSE combination. The value for grade will not be subdivided. The Keys (d) No candidate keys (intersecting entity): The STUDENT+COURSE entity does not have a candidate key of its own, but rather, each STUDENT+COURSE entity will be identified by keys belonging to the STUDENT and COURSE entities. The latter statement is very close (and for a user, hopefully indistinguishable) from the key statements found in the "attribute on a relationship" grammar above: For the relationship between STUDENT and COURSE, we will record a grade. The grade depends on both entities, STUDENT and COURSE, for identification. More Entities and Relationships In the handling of a database, we have to model the information presented. We will likely have situations that call for more than two entities and more than one binary relationship. Again, a binary relationship is a relationship between two entities. (Chapter 7 looks at ternary and higher relationship combinations.) This section deals with situations where the information about the database indicates that we have to expand our diagrams with more entities, but all the connections will be binary. More than Two Entities Let us again reconsider the STUDENT–COURSE ER diagram, Figure 6.1. If this database were oriented toward a college, the courses would have instructors and the instructors would be related to the courses. We would consider adding INSTRUCTOR to our database per our methodology steps 4 and 5, which say: Step 4: If another entity is appropriate, draw the second entity with its attributes. Repeat step 2 to see if this entity should be further split into more entities. Step 5: Connect entities with relationships (one or more) if relationships exist. If we added instructors to the ER diagram, Figure 6.1 , we might see something like Figure 6.3 (attributes other than the primary keys are intentionally left off to unclutter the diagram). The relationship between INSTRUCTOR and COURSE is teach — instructors teach many courses, a course is taught by an instructor (loosely speaking). The participation would be determined by the situation, but we will choose one for our example. Stated more precisely, we would say: Figure 6.3: An ER Diagram (with Only Primary Keys) Showing a STUDENT/COURSE/INSTRUCTOR Database Pattern 4 — x:y::1:M, from the 1 Side, Partial Participation Short: An instructor may teach many courses which actually means: Long: An instructor, but not necessarily all instructors, (which are recorded in the database) may teach many (one or more) courses. Some instructors may not teach courses. Pattern 1 — x:y::M:1, from the M Side, Full Participation Short: Courses must be taught by instructors which actually means: Long: Courses, which are recorded in the database, must be taught by one and only one instructor. No course is taught by more than one instructor. In this diagram (Figure 6.3 ), the INSTRUCTOR entity is related to the COURSE entity. There could be a relationship between the INSTRUCTOR entity and the STUDENT entity, but the relationships in Figure 6.3 are assumed to be the only ones that exist. One could argue that the other possible relationships are advisor, mentor, counselor, coach, … , but remember that we are modeling only what exists and not what might be. We assume that the diagram represents the information given and only the information given. Adding More Attributes that Evolve into Entities As we have seen, ER diagrams evolve during the design/redesign process. One way ER diagrams evolve is to add attributes to various entities. Some attributes are going to be simple, functionally dependent additions. Functional dependency means that something is identifiable by that which it is dependent upon. For example, a social security number functionally identifies a name, and name is functionally dependent on social security number. This functional dependency means that anywhere a certain value for social security number exists in the database, you can be sure that the same name will appear with it. Consider adding the attribute instructor name. The addition enhances the diagram and instructor name is functionally dependent on the attribute, instructor ID. Now consider adding "building" to each of the entities. Students live in buildings (dorms), courses are taught in buildings (classrooms and labs), instructors have offices in buildings. "Building" can be added as an attribute of each of the three entities and not be considered an entity unto itself. Why? Because at this stage, we have not expressed the desire to record information about buildings. If buildings (dorm rooms, class rooms, office rooms) were considered as attribute items for appropriate entities, then we would have the ER diagram as in Figure 6.4 . Figure 6.4: An ER Diagram (with Only Primary Keys) Showing a STUDENT/COURSE/INSTRUCTOR Database with "Building" as an Attribute Now that we have added "building" to our database (Figure 6.4 ), suppose we evolve yet again to where we now decide that we do want to record more information about buildings; or put another way, we want to make BUILDING an entity. We would then have to connect other entities to BUILDING with appropriate relationships. Such a design is depicted in Figure 6.5. Whether we begin with the idea of BUILDING as an entity or evolve to it by starting with STUDENTS, COURSES, and INSTRUCTORS, we need to be constantly asking the question, "Is this item in the ER diagram one that we want to record information about, or not? Should this be an entity?" In Figure 6.5, we have depicted BUILDING as an entity and hence we will want to add attributes to it. For an embellished ER diagram with more attributes and cardinalities, see Figure 6.6 . Figure 6.5: An ER Diagram (with Only Primary Keys) Showing a STUDENT/ COURSE/INSTRUCTOR/BUILDING Database Figure 6.6: An ER Diagram Showing a STUDENT/COURSE/INSTRUCTOR/BUILDING Database Checkpoint 6.1 1. In Figure 6.6 , why is BUILDING an entity and not an attribute of another entity? 2. In Figure 6.6 , why is the room number attribute attached to the lives in relationship rather than the STUDENT entity? 3. What will make you decide whether an attribute should be connected to ENTITYA or ENTITYB or, on the relationship connecting ENTITYA and ENTITYB? 4. Why are all the lines leaving BUILDING (on Figure 6.6 ) single lines (partial participation)? 5. According Figure 6.6 , does a student have to enroll in a course? 6. According to Figure 6.6 , how many courses can an instructor teach? More Evolution of the Database Let us reconsider the ER diagram in Figure 6.6. As the diagram is analyzed, the user might ask, "Why is a room number attribute not included for the relationship, class?" Why is there no office number for the relationship, office? There may be several reasons for the omission: (1) the data was not mentioned in the analysis stage; (2) the data is not necessary (i.e., there may be only one classroom per building or office numbers may not be recorded for advisors); or (3) it was an oversight and the data should be added. Suppose now we decide that room number is important for all of the relationships or entities. Suppose that we want to identify the room number associated with instructors and buildings, courses and buildings, and students and buildings. We might "evolve" the diagram to that of Figure 6.7 . Figure 6.7: An ER Diagram Showing a STUDENT/COURSE/INSTRUCTOR/ BUILDING Database with the "room number" for the Three Relations In this case, we have information attached to BUILDING: building occupancy, the maintenance supervisor, and the square footage of the building. We have room number as an attribute identifiable by two entities in each case. Attributes that Evolve into Entities This section illustrates, one more time, the idea that we have to model "what is" and not necessarily "what might be." Also, we again see how an attribute might become an entity. Consider, for example, the following data that will go into an ER diagram/database: a course name, course number, credits, instructor name, and book. Example: 'Database','COP 4710',3,'Earp','Elmasri/Navathe' The beginning ER diagram might look like Figure 6.8 , "An ER Diagram of the COURSE entity in a database." Why "might look like … "? The answer lies in eliciting correct requirements from our user. Figure 6.8: An ER Diagram with COURSE Entity in a Database If all of the information that was ever to be recorded about this data was mentioned above, then this single entity ER diagram would describe the database. However, one could realistically argue that things that we have described as attributes could themselves be entities. Both the instructor and the book would be candidates for being diagrammed as entities if the envisioned database called for it. Consider a scenario in which one might choose to expand or redesign the database to include information about instructors. If this were the case, we might want to go beyond recording the instructor name and also include such attributes as the instructor's department, date_hired, and the school where the instructor received the terminal degree. With the additional information about INSTRUCTORS, the ER diagram would have two entities and would look like Figure 6.9 . Figure 6.9: An ER Diagram of the COURSE–INSTRUCTOR Database In Figure 6.9 , we have depicted the INSTRUCTOR entity as weak because of the presumed non-uniqueness of instructor names and the dependence on COURSE. If the instructor were identified uniquely with an attribute like instructor social security number, and if instructors could exist independent of course, then the entity could become strong and would look like Figure 6.10. The idea of this section, then, is to bring out the point that an entity is not an entity just because one might want to record information "someday." There would have to be some planned intent to include the data that would be identified by the entity. Further, the definition of weak or strong entity would depend on the identifying information that was to be provided. Figure 6.10: An ER Diagram of the COURSE–INSTRUCTOR Database Finally, if no information about instructors were ever planned, then the first ER diagram (Figure 6.10 ) would well describe the database. We will leave as an exercise the extension of Figure 6.10 to include BOOK as an entity. [...]... employees So, using mapping rule M5a, we will reinclude the primary key of the EMPLOYEE entity in itself, giving us the following EMPLOYEE relation: EMPLOYEE ename essn dnum snum dm_ssn Kaitlyn 987–754–9 865 501 1 2 76 263 –9182 Fred 2 76 263 –9182 502 1 null Katie 982–928–27 26 503 1 987–754–9 865 Seema 837–937–9373 501 1 2 76 263 –9182 This recursive relationship is also shown in Figure 6. 17 Figure 6. 17: An... relationship, then Figure 6. 11 would map to the above table (PERSONNEL) and: PERSONNEL_SUPERVISOR employee_id super_id 8945 9090 9090 null 3841 9090 8 767 9090 5050 8945 Checkpoint 6. 4 1 Map the recursive relationship shown in Figure 6C to a relational database and show some sample data 2 If Figure 6C was an M:N relationship, how would you map this recursive relationship to a relational database? Show the... on Both Sides) Figure 6A show us an example of an entity, PERSONNEL, that is related to itself through a married to relationship This means that a person in this database can be married to one other person in this same database Figure 6A: One-to-One Recursive Relationship (Partial Participation on Both Sides) Some instances of this relationship are shown in Figure 6B From Figure 6B we can see that Seema... discussed with examples and diagrams The ER design methodology steps were refined to include all of the above into the new and evolving methodology Toward the end of the chapter, an alternative ER notation for specifying structural constraints on relationships was presented Upon completing this chapter, the reader or database creator should be able to efficiently design a database with binary relationships... relationships Chapter 6 Exercises In each of the exercises that follow, the admonition to "construct an ER diagram" implies not only the diagram, but also the structured grammatical description of the diagram Exercise 6. 1 Define and state in precise terms the cardinality and participation in Figure 6. 5, the STUDENT/COURSE/INSTRUCTOR/BUILDING database Discuss the structural constraints of Figure 6. 5 Under what... Publishing, Danvers, MA, 1995 Teorey, T.J., Database Modeling and Design, Morgan Kaufman, San Francisco, 1999 Case Study: West Florida Mall (continued) Thus far in our case study, we have developed the major entities and relationships and mapped these to a relational database (with some sample data) Then, upon reviewing step 7, which says: Step 7: Present the "as-designed" database to the user, complete with... To review, our methodology for designing ER diagrams has now evolved to the following: ER Design Methodology Step 1: Select one, primary entity from the database requirementsdescription and show attributes to be recorded for that entity Label keys if appropriate and show some sample data Step 2: Use structured English for entities, attributes, and keys to describe the database that has been elicited... relationship and is always partial–partial Figure 6. C: One-to-Many Recursive Relationship (Partial Participation on Both Sides) Instances of this relationship are shown in Figure 6D From Figure 6D we can see that Tom Smith supervises Sudip Bagui and Tim Vaney, Rishi Kapoor supervises Mala Sinha and Korak Gupta, Korak Gupta supervises Roop Mukerjee, etc Figure 6. D: Instances of One-to-Many Recursive Relationship... incorrect? Exercise 6. 2 Consider the following data and construct an ER diagram — use structured grammar to rationalize your constraints The data: horse name, race, owner, odds at post, post position, date of race, order of finish, year to date earnings, owner name and address Exercise 6. 3 In this chapter we described a database that had two entities: COURSE and INSTRUCTOR (refer to Figure 6. 10) Book was... that had two entities: COURSE and INSTRUCTOR (refer to Figure 6. 10) Book was left as an attribute of COURSE Extend the database to include BOOK as an entity Attributes of BOOK might include: book title, author, price, edition, publisher Exercise 6. 4 Refer to Figure 6. 7 Change Figure 6. 7 to include the following information: One building can have a maximum of 99 students living in it A student has to . leaving BUILDING (on Figure 6. 6 ) single lines (partial participation)? 5. According Figure 6. 6 , does a student have to enroll in a course? 6. According to Figure 6. 6 , how many courses can. STUDENT/COURSE/INSTRUCTOR/BUILDING Database Checkpoint 6. 1 1. In Figure 6. 6 , why is BUILDING an entity and not an attribute of another entity? 2. In Figure 6. 6 , why is the room number attribute attached. Figure 6. 5: An ER Diagram (with Only Primary Keys) Showing a STUDENT/ COURSE/INSTRUCTOR/BUILDING Database Figure 6. 6: An ER Diagram Showing a STUDENT/COURSE/INSTRUCTOR/BUILDING Database