APPENDIX A Data Modeling - Sdu

More documents

Recommendations

Info

6 Appendix A <strong>Data</strong> <strong>Modeling</strong> Entity Example Instances FIGURE A-3 Entities and Instances Patient John Smith Susan Jones Peter Todd Dale Turner Pat Turner Concatenated Identifier Single Identifier Identifier to be Added Later PATIENT PATIENT PATIENT FIGURE A-4 Choices for Identifiers PAT_lastname PAT_firstname PAT_Idnumber PAT_lastname PAT_firstname PAT_lastname PAT_firstname appointment” and “an appointment is scheduled by a patient.” In Figure 7.1, we have included words for both directions of the relationship line; the top words are read from parent to child, and the bottom words are read from child to parent. Notice that the doctor entity is the parent entity in the doctor – appointment relationship. Cardinality Relationships have two properties. First, a relationship has cardinality, which is ratio of parent instances to child instances. To determine the cardinality for a relationship, we ask ourselves: “How many instances of one entity are associated with an instance of the other?” (Remember that an instance is one occurrence of an entity, such as patient John Smith, Dr. Dave Brousseau, or Aetna Insurance Company.) For example, how many appointments can a patient schedule? How many patients are associated with an appointment? How many insurance companies can a patient have? The cardinality for binary relationships (i.e., relationships between two entities) are 1 : 1, 1 : N, or M : N, and we will discuss each in turn. The 1 : 1 relationship (read as “one to one”), means that one instance of the parent entity is associated with one instance of the child entity. Notice that there is a 1 : 1 relationship between appointment and bill in Figure A-1. Each appointment (the parent entity) always results in a single bill that is generated, and a bill (the child entity) is associated with only one appointment. The model contains a solid dot and a number “1” on the relationship line nearest the child entity to designate the 1 : 1 relationship. More often, relationships are 1 : N relationships (read as “one to many”). In this kind of relationship, a single instance in a parent entity is associated with many instances of a child entity; however, the child-entity instance is only related to one instance in the parent. For example, a patient (parent entity) can schedule many appointments (child entity), but a particular appointment is scheduled by only one patient, suggesting a 1 : N relationship between patient and appointment. Another 1 : N relationship is between insurance company and payment (an insurance company can make many payments, but a specific payment is only associated with one insurance company). A character resembling a solid dot is placed closest to appointment to show the “many” end of the relationship.
The Entity Relationship Diagram 7 PATIENT PAT_idnumber INS_name PAT_firstname PAT_lastname PAT_address PAT_city PAT_state PAT_zipcode PAT_homephone PAT_birthdate comes down with / is shown by SYMPTOM SYM_name SYM_description DOCTOR DOC_physicianidnumber FIGURE A-5 M:N Relationships DOC_firstname DOC_lastname DOC_address DOC_city DOC_state DOC_zipcode DOC_homephone DOC_pagenumber can help patients regarding / is assigned to SPECIALTY SPE_name SPE_description The parent entity is always on the “1” side of the 1 : N relationship. Can you identify several other 1 : N relationships in Figure A-1? Identify the parent and child entities for each relationship. A third kind of relationship is the M : N relationship (read as “many to many”). In this case, many instances of a parent entity can be related to many instances of a child entity. There are no M : N relationships in Figure A-1, but take a look at Figure A-5, which provides two M : N relationship examples. The first example demonstrates that one patient (parent entity) can display many different symptoms at a time (e.g., sore throat, fever, runny nose), and a symptom (child entity) can be associated with many different patients. The second M : N in Figure A-5 communicates that a doctor can have many different specialties (e.g., infant contagious disease, cardiology, neurology), and a specialty can be associated with many different doctors. M : N relationships are depicted on an ERD by having solid dots at both ends of the relationship line. Modality Second, relationships have a modality of null or not null, which refers to whether or not an instance of a child entity can exist without a related instance in the parent entity. Basically, the modality of a relationship indicates whether the child-entity instance must participate in the relationship. It forces you to ask questions like: Can you have an appointment without a doctor? Can you have a bill without an appointment? Modality is depicted by placing a diamond on the relationship line next to the parent entity if nulls are allowed.
Page 1 and 2: APPENDIX A Data Modeling A data mod
Page 3 and 4: The Entity Relationship Diagram 3 t
Page 5: The Entity Relationship Diagram 5 I
Page 9 and 10: The Entity Relationship Diagram 9 A
Page 11 and 12: Creating an Entity Relationship Dia
Page 19 and 20: Validating an ERD 19 have unique tr
Page 21 and 22: Validating an ERD 21 COUNTRY COU_na
Page 23 and 24: Validating an ERD 23 FIGURE A-19 No
Page 25 and 26: Validating an ERD 25 places/ is pla
Page 27 and 28: Questions 27 does not lead to repea
Page 29 and 30: Minicases 29 CINEMA cin_name cin_ad

APPENDIX A Data Modeling - Sdu

Create successful ePaper yourself

Delete template?

Save as template?