APPENDIX A Data Modeling - Sdu

More documents

Recommendations

Info

10 Appendix A Data Modeling model also appear on the process models as data stores and data flows, and on the user interface as fields on an input screen. When you make a change in the data dictionary, the change ripples to the relevant parts of the project that are affected. When metadata is complete, clear, and shareable, the information can be used to integrate the different pieces of the analysis phase and ultimately lead to a much better design. It becomes much more detailed as the project evolves though the SDLC. YOUR TURN A-2 Evaluate Your CASE Tool Examine the CASE tool that you will be using for your project, or find a CASE tool on the Web that you are interested in learning about. What kind of metadata does its data dictionary capture? Does the CASE tool integrate data model information with other parts of a project? How? ERD Element Kinds of Metadata Example Entity Name Doctor Definition A doctor is any medical professional who has been hired to see patients during scheduled appointments in the doctor’s office. Special notes A nurse practitioner is considered a doctor within this system. User contact Virginia Baker is the office manager (x4335), and she can provide information about the doctor entity. Analyst contact Barbara Wixom is the analyst assigned to this entity. Attribute Name DOC_physicianidnumber Definition A physicianidnumber is a number assigned to a doctor by the medical industry. The number was put in place to track physicians and the prescription they make. Alias Physician identification number, PID Sample values 334997300 Acceptable values Any 9-digit number Format 9-digits, no spaces or dashes Type Numeric Special Notes If a nurse practitioner does not have a PID, then his or her social security number will be used. Relationship Verb Phrase Schedules Parent Entity Doctor Child Entity Appointment Definition One doctor is scheduled to participate in an appointment, and he or she can be scheduled for many appointments over time. A single appointment can only have one doctor affiliated with it. Cardinality 1 : N Modality Not null Special Notes Investigate how walk-in patients are handled! Are they placed on the schedule like regularly scheduled appointments? FIGURE A-9 Types of Metadata Captured by the Data Dictionary
Creating an Entity Relationship Diagram 11 CREATING AN ENTITY RELATIONSHIP DIAGRAM Drawing an ERD is an iterative process of trial and revision. It usually takes considerable practice. ERDs can become quite complex—in fact, there are systems that have ERDs containing hundreds or thousands of entities. The basic steps in building an ERD are these: (1) identify the entities, (2) add the appropriate attributes to each entity, and then (3) draw relationships among entities to show how they are associated with one another. First, we will describe the three steps in creating ERDs using the data model example from Figure A-1. Then, we will present an ERD for CD Selections. Building Entity Relationship Diagrams Step 1: Identify the Entities As we explained, the most popular way to start an ERD is to first identify the entities for the model and their attributes. The entities should represent the major categories of information that you need to store in your system. If the process models (e.g., DFDs) have been prepared, the easiest way to start is with them: the data stores on the DFDs, the external entities, and the data flows indicate the kinds of information that are captured and flow through the system. If you begin your data model using a use case, look at the major inputs to the use case, the major outputs, and the information used for the use-case steps. Examine the process model (Figure 6.12) and the use cases (Figure 5.1) for the doctor’s office system. As you look at the doctor’s office system’s level 0 DFD, you see that there are three data stores: patient, appointment, and billing. Each of these unique types of data probably will be represented using entities on our data model. As a next step, you should examine the external entities and ask, “Will the system need to capture information about any of these entities?” We are already capturing patient information, but will we also need doctor and insurance company data? The answer is yes—we need information about doctors and insurance companies. The make appointments process will certainly need to include what doctor is affiliated with the appointment, and the perform billing process likely cannot be performed without information about the patient’s insurer. We should note that if the doctor’s office only contained one doctor, then there would be no need for a doctor entity. A rule of thumb is to include only entities that contain more than one instance. We will assume that this doctor’s office has multiple doctors who can see patients, so we include doctor on the ERD. Finally, it is good to look at the data flows and see if there is information that flows through the system that has not yet been captured by the ERD. Notice that there is information called a bill that flows from the perform billing process. This seems logically different from the other entities. Remember that creating ERDs is an iterative process, so we can go ahead and add an entity called bill for now to store bill information—we always can make changes down the road if this turns out to be a bad assumption. Step 2: Add Attributes and Assign Identifiers The information that describes each entity becomes its attributes. It is likely that you identified a few attributes if you read the doctor’s office system use cases and paid attention to the information flows on its DFDs. For example, a patient has a name and information, and an appointment has a date. Unfortunately, much of the information from the process models and use cases is at too high a level to identify the exact attributes that should exist in each of our six entities. On a real project, there are a number of places where you can go to figure out what attributes belong in your entity. For one, you can check in the CASE tool—often an analyst will describe a process model data flow in detail when he or she enters the data flow into the CASE repository. For example, an analyst may create an entry for the patient information data flow like the one shown in Figure A-10 that lists nine data elements that comprise patient
Page 1 and 2: APPENDIX A Data Modeling A data mod
Page 3 and 4: The Entity Relationship Diagram 3 t
Page 5 and 6: The Entity Relationship Diagram 5 I
Page 7 and 8: The Entity Relationship Diagram 7 P
Page 9: The Entity Relationship Diagram 9 A
Page 13 and 14: 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?