APPENDIX A Data Modeling

Transcription

1 APPENDIX A Data Modeling A data model describes the data that flows through the business processes in an organization. During the analysis phase, the data model presents the logical organization of data without indicating how the data are stored, created, or manipulated so that analysts can focus on the business without being distracted by technical details. Later, during the design phase, the data model is changed to reflect exactly how the data will be stored in databases and files. This chapter describes entity relationship diagramming, one of the most common data modeling techniques used in industry. OBJECTIVES Understand the rules and style guidelines for creating entity relationship diagrams. Be able to create an entity relationship diagram. Become familiar with the data dictionary and metadata. Become familiar with the process of normalization. Understand how to balance between entity relationship diagrams and data flow diagrams. CHAPTER OUTLINE Introduction The Entity Relationship Diagram Reading an Entity Relationship Diagram Elements of an Entity Relationship Diagram The Data Dictionary and Metadata Creating an Entity Relationship Diagram Building Entity Relationship Diagrams Applying the Concepts at CD Selections Validating an ERD Design Guidelines Normalization Balancing Entity Relationship Diagrams with Data Flow Diagrams Summary INTRODUCTION During the analysis phase, analysts create process models to represent how the business system will operate. At the same time, analysts need to understand the information that is used and created by the business system (e.g., customer information, order information). In this chapter, we discuss how the data that flow through the processes are organized and presented. A data model is a formal way of representing the data that are used and created by a business system; it illustrates people, places, or things about which information is captured 1

2 2 Appendix A Data Modeling and how they are related to each other. The data model is drawn using an iterative process in which the model becomes more detailed and less conceptual over time. During analysis, analysts draw a logical data model, which shows the logical organization of data without indicating how data are stored, created, or manipulated. Because this model is free of any implementation or technical details, the analysts can focus more easily on matching the diagram to the real business requirements of the system. In the design phase, analysts draw a physical data model to reflect how the data will physically be stored in databases and files. At this point, the analysts investigate ways to store the data efficiently and to make the data easy to retrieve. The physical data model (Chapter 8) and performance tuning (Chapter 9) are discussed later in the textbook. Project teams usually use CASE tools to draw data models. Some of the CASE tools are data modeling packages, such as ERwin by Platinum Technology that help analysts create and maintain logical and physical data models; they have a wide array of capabilities to aid modelers, and they can automatically generate many different kinds of databases from the models that are created. Other CASE tools (e.g., Oracle Designer) come bundled with database management systems (e.g., Oracle), and they are particularly good for modeling databases that will be built in their companion database products. A final option is to use a full-service CASE tool, such as Visible Analyst Workbench in which data modeling is one of many capabilities, and the tool can be used with many different databases. These tools have decent data modeling tools although they do not have as much functionality and support for data modeling as the two other kinds of CASE software. A benefit of the full-service CASE tool is that it well integrates the data model information with other relevant parts of the project. In this chapter, we focus on creating a logical data model. Although there are several ways to model data, we will present one of the most commonly used techniques: entity relationship diagramming, a graphic drawing technique developed by Peter Chen 1 that shows all the data components of a business system. We will first describe how to create an entity relationship diagram (ERD) and discuss some style guidelines. Then, we will present a technique called normalization that helps analysts validate the data models that they draw. The chapter ends with a discussion of how data models balance, or interrelate, with the process models that you learned about in Chapter 6. THE ENTITY RELATIONSHIP DIAGRAM An entity relationship diagram (ERD) is a picture that shows the information that is created, stored, and used by a business system. An analyst can read an ERD to find out the individual pieces of information in a system and how they are organized and related to each other. On an ERD, similar kinds of information are listed together and placed inside boxes called entities. Lines are drawn between entities to represent relationships among the data, and special symbols are added to the diagram to communicate high-level business rules that need to be supported by the system. The ERD implies no order, although entities that are related to each other are usually placed close together. For example, consider the doctor s office system that was described in Chapter 6. Although we understand how the system will work from studying the data flow diagram (DFD), we have very little detailed understanding about the information itself that flows 1 P. Chen, The Entity-Relationship Model Toward a Unified View of Data, ACM Transactions on Database Systems, 1976, 1:9 36.

3 The Entity Relationship Diagram 3 through the system. What exactly is patient information? What pieces of information are captured when making an appointment? How is a patient related to the appointment that he or she makes? Reading an Entity Relationship Diagram The analyst can answer these questions and many more by examining the ERD that is presented in Figure A-1. First, the analyst knows that the data to support the appointment system can be organized into six main categories patient, appointment, doctor, bill, payment, and insurance company and that patient information includes the patient s ID number, last name, first name, address, phone number, and birthdate. The analyst understands what information is used to uniquely identify a patient, an appointment, a doctor, and so on by looking for the information in the top box of each category. For example, the patient ID number is used to identify a particular patient. The lines connecting the six categories of information communicate the relationships that the categories share. By reading the relationship lines, the analyst understands that a doctor can be scheduled for an appointment that is scheduled by a patient. The ERD also communicates high-level business rules. Business rules are constraints or guidelines that are followed during the operation of the system; they are rules like only one person can be seen by a doctor at a time or payments must be made in the form of cash or check or a bill can be paid by insurance, a patient, or a combination of both. Over the course of a workday, people are constantly applying business rules to do their jobs, and they know what the rules are because they either have been taught them (the office manager will know from experience that credit card payments are not accepted) or they can look them up somewhere. If a situation arises and people don t know how to handle it, they may have to refer to a policy guide or written procedure to determine what the business rules are. On a data model, business rules are communicated by the kinds of relationships that the entities share. From the ERD, for example, we know that a patient can schedule many appointments from the round dot placed on the line closest to appointment, and we know that a person does not have to be insured to become a patient because of the diamond on the line nearest the insurance company. A doctor can be scheduled for many appointments, and each appointment generates one bill (communicated by the number one on the line closest to bill). Both the patient and insurance company make payments, and this rule makes sense given that a bill can have many payments associated with it. Ultimately, the new system should support the business rules we just described, and it should ensure that users don t violate the rules when performing the processes of the system. Now that you ve seen an ERD, let s step back and learn the ERD basics. In the following sections, we will first describe the syntax of the ERD using the diagram in Figure A-1. Then we will teach you how to create an ERD using an example from CD Selections. Elements of an Entity Relationship Diagram There are three basic elements in the data modeling language (entities, attributes, and relationships), each of which is represented by a different graphic symbol. There are many different sets of symbols that can be used on an ERD. No one set of symbols dominates industry use, and none is necessarily better than another. We will use IDEF1X in this book. Figure A-2 summarizes the three basic elements of ERDs and the symbols we will use. Entity The entity is the basic building block for a data model. It is a person, place, event, or thing about which data is collected for example, an employee, an order, or a product. An entity is depicted by a rectangle, and it is described by a singular noun

4 4 Appendix A Data Modeling DOCTOR DOC_physicianidnumber DOC_firstname DOC_lastname DOC_address DOC_city DOC_state DOC_zipcode DOC_homephone DOC_pagenumber DOC_primaryspecialty 1 BILL BIL_number BIL_amountinsured BIL_amountnotinsured BIL_datesent BIL_status is paid by / pays is scheduled for/ includes schedules / is scheduled by generates / is generated by makes / is made by PAYMENT PAY_receiptnumber PAY_amount PAY_date PAY_method APPOINTMENT APP_date APP_time APP_duration APP_reason APP_status makes / is made by INS_name PATIENT PAT_idnumber PAT_firstname PAT_lastname PAT_address PAT_city PAT_state PAT_zipcode PAT_homephone PAT_birthdate INSURANCE COMPANY insures / is insured by INS_benefitscontact INS_phonenumber INS_claimsaddress INS_claimssummaryinformation FIGURE A-1 Example Entity Relationship Diagram spelled in capital letters. All entities have a name, a short description that explains what they are, and an identifier that is the way to locate information in the entity (which is discussed later). In Figure A-1, the entities are patient, doctor, appointment, payment, insurance company, and bill. Entities represent something for which there exists multiple instances,or occurrences. For example, John Smith and Susan Jones could be instances of the entity patient (Figure A-3). We would expect the patient entity to stand for all of the people who have scheduled an appointment, and each of them would be an instance in the patient entity. Attribute An attribute is some type of information that is captured about an entity. For example, date of birth, home address, and last name are all attributes of a patient. It is easy to come up with hundreds of attributes for an entity (e.g., a patient has an eye color, a favorite hobby, a religious affiliation), but only those that will actually be used by a business process should be included in the model. Attributes are nouns that are listed within an entity. Usually, some form of the entity name is appended to the beginning of each attribute to make it clear as to what entity it belongs (e.g., PAT_lastname, PAT_address). Without doing this, you can get confused by multiple entities that have the same attributes for example, a doctor and a patient both can have an attribute called lastname. DOC_lastname and PAT_lastname are much clearer attributes to place on the data model.

5 The Entity Relationship Diagram 5 IDEF1X Chen Crow s Foot a An ENTITY: Is a person, place, or thing Has a singular name spelled in all capital letters Has an identifier Should contain more than one instance of data ENTITY-NAME ENTITY-NAME ENTITY-NAME Identifier *Identifier An ATTRIBUTE: Is a property of an entity Should be used by at least one business process Is broken down to its most useful level of detail ENTITY-NAME Attribute-name Attribute-name Attribute-name ENTITY-NAME Attribute-name Attribute-name Attribute-name FIGURE A-2 Data Modeling Symbol Sets A RELATIONSHIP: Shows the association between two entities Has modality (0,1) Has cardinality (1,M) Is described with a verb phrase Relationship-name a This is the notation that will be used throughout the textbook Relationship-name One or more attributes can serve as the identifier, the attribute(s) that can uniquely identify one instance of an entity, and the attributes that serve as the identifier are placed in the top box of the entity rectangle. If there are no patients with the same last name, then last name can be used as the identifier of the patient entity. In this case, if we need to locate John Brown, the name Brown would be sufficient to identify the one instance of the Brown last name. Suppose we add a patient named Sarah Brown. Now we have a problem: using the name Brown would not uniquely lead to one instance it would lead to two (i.e., John Brown and Sarah Brown). You have three choices at this point, and all are acceptable solutions. First, you can use a combination of multiple fields to serve as the identifier (last name and first name). This is called a concatenated identifier because several fields are combined, or concatenated, to uniquely identify an instance. Second, you can find a field that is unique for each instance, like the patient ID number. Third, you can wait to assign an identifier (like a randomly generated number that the system will create) until the design phase of the SDLC (Figure A-4). Many data modelers don t believe that randomly generated identifiers belong on a logical data model because they do not logically exist in the business process. Relationship Relationships are associations between entities, and they are lines that connect the entities together. Every relationship has a parent entity and a child entity, the parent being the first entity in the relationship, and the child being the second. Relationships should be clearly labeled with active verbs so that the connections between entities can be understood. If one verb is given to each relationship, it is read in two directions. For example, we could write the verb schedules alongside the relationship for the patient and appointment entities, and this would be read as a patient schedules an

6 6 Appendix A Data Modeling 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.

7 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.

8 8 Appendix A Data Modeling YOUR TURN A-1 Understanding the Elements of an ERD A wealthy businessman owns a large number of paintings that he loans to museums all over the world. He is interested in setting up a system that records what he loans to whom so that he doesn t lose track of his investments. He would like to keep information about the paintings that he owns as well as the artists who painted them. He also wants to track the various museums that reserve his art along with the actual reservations. Obviously artists are associated with paintings, paintings are associated with reservations, and reservations are associated with museums. Questions: 1. Draw the four entities that belong on this data model. 2. Provide some basic attributes for each entity, and select an identifier, if possible. 3. Draw the appropriate relationships between the entities and label them. 4. What is the cardinality for each relationship? Depict this on your drawing. 5. What is the modality for each relationship? Depict this on your drawing. 6. List two business rules that are communicated by your ERD. In the first two questions we asked, the answer is no of course you need a doctor to have an appointment, and of course you can t send a bill without an associated appointment. Thus, the relationships are left alone, and the analyst understands that the modality is not null for both of these relationships. Notice, however, that a diamond has been placed on the relationship line next to insurance company. This means that we can have a patient in our system who does not have an insurance company, and the modality is null. The Data Dictionary and Metadata As we described earlier, a CASE tool is used to help build ERDs. Every CASE tool has something called a data dictionary, which quite literally is where the analyst goes to define or look up information about the entities, attributes, and relationships on the ERD. Figures A-6, A-7, and A-8 illustrate common data dictionary entries for an entity, FIGURE A-6 Data Dictionary Entry for the Patient Entity (Shown Using ERwin)

9 The Entity Relationship Diagram 9 Attribute Name: Aliases: Entity: Description: PAT _ idnumber Patient ID Number, Social Security Number, SSN PATIENT The ID number assigned by the doctor s office that uniquely identifies a patient. Data Type: Identifier: Notes: Alpha-Numeric Yes Usually, the patient s social security number is used. When a patient does not have a social security number, the number assigned by the patient s insurance provider is used. If the patient does not have an insurance provider, a driver s license number is used. FIGURE A-7 CASE Entry for Patient Notes: If the patient s insurance provider number is used and it is greater than 9 characters, the first 9 characters are used to create this attribute. Zeros are added to the number if it is less than 9 characters. Parent Entity: Child Entity: Relationship: Description: INSURANCE COMPANY PATIENT Insures/Is insured by An insurance company insures patients, usually through work-related benefits. A patient can be insured by an insurance company, although patients exist without insurance. FIGURE A-8 CASE Entry for the Insurance Company and Patient Relationship Cardinality: Modality: Notes: Notes: 1 : N Nulls allowed A patient can exist without insurance. An insurance company can be affiliated with any number of patient. an attribute, and a relationship; notice the kinds of information the data dictionary captures about each element. The information you see in the data dictionary is called metadata, which, quite simply, is data about data. Metadata is anything that describes an entity, attribute, or relationship, such as entity names, attribute descriptions, and relationship cardinality, and it is captured to help designers better understand the system that they are building and to help users better understand the system that they will use. Figure A-9 lists typical metadata that are found in the data dictionary. Notice that the metadata can describe an ERD element (like entity name) and also information that is helpful to the project team (like the user contact, the analyst contact, and special notes). Metadata is stored in the data dictionary so that it can be shared and accessed by developers and users throughout the SDLC. The data dictionary allows you to record the standard pieces of information about your elements in one place, and it makes that information accessible to many parts of a project. For example, the data elements in a data

10 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 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

11 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

12 12 Appendix A Data Modeling FIGURE A-10 Elements of the Patient Information Data Flow Data flow name: Data elements: Patient information identification number + first name + last name + address + city + state + zip code + home phone number + birth date information. The elements of the data flow should be added to the ERD as attributes in your entities. A second approach is to check the requirements definition. Often there is a section under functional requirements called data requirements. This section describes the data needs for the system that were identified while gathering requirements. A final approach to identifying attributes is to use requirements-gathering techniques. The most effective techniques would be interviews (e.g., asking people who create and use reports about their data needs) or document analysis (e.g., examining existing reports or input screens). Once the attributes are identified, one or more of them will become the entity s identifier. The identifier must be an attribute(s) that is able to uniquely identify a single instance of the entity. Look at Figure A-1 and notice the identifiers that were selected for each entity. Five of the entities had some attribute that could identify an instance by itself (e.g., physician ID number, bill number, payment receipt number, insurance company name, and patient ID). Step 3: Identify Relationships The last step in creating ERDs is to determine how the entities are related to each other. Lines are drawn between entities that have relationships, and each relationship is labeled and assigned both a cardinality and a modality. The easiest approach is to begin with one entity and determine all the entities with which it shares relationships. For example, there likely there are relationships between a patient and appointment, payment, and insurance company. We know that a patient schedules appointments, makes payments, and is insured by an insurance company. The same exercise is done with each entity until all of the relationships have been identified. Each relationship should be labeled appropriately as it is added. When you find a relationship to include on the model, you need to determine its cardinality and modality. For cardinality, ask how many instances of each entity participate in the relationship. You know that an insurance company can have many patients, but that a patient is affiliated with only one insurer. This suggests that there is a 1: N relationship in which the insurance company is the parent entity (the 1 ) and the patient is the child entity (the many ). Next we examine the relationship s modality. Can a patient exist without an insurance company? We already determined that the answer is yes, so the modality for the relationship is null. This exercise is done for every relationship. Notice the cardinality and modality for each relationship in Figure A-1. Again, remember that data modeling is an iterative process. Often the assumptions you make and the decisions you make change as you learn more about the business requirements and as changes are made to the use cases and process models. But, you have to start somewhere so do the best you can with the three steps we just described and keep iterating until you have a model that works. Later in this chapter, we will show you a few ways to validate the ERDs that you draw. Applying the Concepts at CD Selections Let s go through one more example of creating a data model using the context of CD Selections. For now, review the example use case that was presented in Figure 5-6 and the final level 0 process model presented in Figure 6-19.

13 Creating an Entity Relationship Diagram 13 Identify the Entities When you examine the CD Selections level 0 DFD, you see that there are four data stores: CD information, inventory, marketing, and in-store holds. Each of these unique types of data likely will be represented using entities on a 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? You may be tempted to include marketing manager and in-store staff, but there really is no need to track information about either of these in our system. Later, we may want to track system users, passwords, and data access privileges, but this information has to do with the use of the new system and would not be added until the physical data model (which is created in the design phase). Customer and vendor are different matters. We need to capture information about both of these external entities. First consider customer. The take-request process requires that a customer provide a name and some basic contact information that is used for holding and special ordering CDs. A customer entity is needed on the data model to store this information. Likewise, the maintain marketing materials process accepts basic vendor information when a vendor sends in marketing material. This information should be stored in a vendor entity. The last external entity, special order system, would not be added to the data model because we don t need to store or capture any information about it. Additionally, the special order system entity refers to only one system. A rule of thumb is to exclude entities on your data model that have only one instance. If, however, our Internet order system interfaced with multiple systems and we tracked information about each of them for some business reason, then it would be wise to create an entity called system to represent the multiple systems involved (the special order system would be one instance of this entity). It is good practice to also look at the data flows on your process model and make sure that all of the information that flows through the system has been covered by your ERD. Unlike the doctor s office example (which found an additional entity by looking at the data flows), it appears that the main entities for CD Selections have been identified after examining the data stores and external entities. To recap, by examining our process models, we have determined that our data model will contain six entities: CD, inventory, marketing material, in-store hold, customer, and vendor. See Figure A-11 for the beginning of our data model. Identify the Attributes The next step is to select which attributes should be used to describe each entity. It is likely that you identified a handful of attributes if you read the CD Selections use cases and examined the DFDs. For example, a CD has an artist, title, category, and sale status and some attributes of customer are name and contact information, which likely includes address, phone number, and address. As a second example, the inventory external entity suggests that a data store is needed to hold inventory information, and the take-request use case provides some indication of the kind of information that it will have. The use case says that the new system will find a MARKETING MATERIAL CD INVENTORY FIGURE A-11 Entities for CD Selections ERD VENDOR CUSTOMER HOLD

14 14 Appendix A Data Modeling store close to the customer and display the availability of the CD in that store. To do this, we need to capture the CD availability, or inventory information, such as the retail store that has the CD in stock. We should also include the store s zip code because the system will find the nearest store to the customer based on this information. See if you can think about possible attributes to include in some of the other entities like Marketing Material and CD. Remember that on a real project, you would have the data dictionary, the requirements definition, and a variety of requirements-gathering techniques to use as sources for identifying attributes. Figure A-12 shows the data model with some of the attributes that likely would be found on the CD Selections data model. The model shows that we would capture the type of marketing material (e.g., video clip, audio clip), a short description, the address of the person who provided the material, and the actual contents in the marketing material entity. The CD entity would have the following attributes: SKU, title, artist, category, and sale status (i.e., whether or not the CD is on sale). One or more of the attributes will be used to uniquely identify an instance of each entity. address may be a good choice for the customer entity in case two customers have the same name. You know that every CD has a unique SKU (stock keeping unit), so this can be used as the identifier in the CD entity. In case there are two vendors with the same name, we may want to use a concatenated identifier that combines vendor name and address for the vendor entity. Notice that there do not seem to be obvious identifiers to use for the marketing material, inventory, and in-store hold entities. We will leave the identifier off for the time being until we learn about some special types of entities later in this chapter. Identify the Relationships The last step in creating ERDs is to determine how the entities are related to each other. Lines are drawn between entities that have relationships, and each relationship is labeled and assigned both a cardinality and a modality. For example, there likely is some kind of relationship between a CD and marketing material used to promote it. When you probe into the cardinality of the relationship, you discover MARKETING MATERIAL CD INVENTORY CD_sku MAR_type MAR_description MAR_ MAR_content CD_title CD_artist CD_category CD_salestatus INV_store INV_zipcode VENDOR CUSTOMER HOLD FIGURE A-12 Attributes and Identifiers for CD Selections ERD VEN_name VEN_address VEN_city VEN_state VEN_zip VEN_contact VEN_phone CUS_ CUS_lastname CUS_firstname CUST_address CUST_city CUST_state CUST_zip CUST_daytimephone HOL_date

15 Creating an Entity Relationship Diagram 15 that a CD can have many different kinds of marketing material (e.g., audio clip, video clip, jacket cover photo), but a specific piece of marketing material is only associated with one CD. This suggests that there is a 1 : N relationship between the CD and marketing material entities. Next we examine the modality. Can marketing material exist without a CD? Well, maybe. There is a chance that a vendor will send us information before a CD is available for sale. In this case, we may want to store the marketing material until we are ready to use it. Therefore, we would make the modality of the relationship null. Look at Figure A-13. Notice the labels, cardinality, and modality that have been included on the diagram. Advanced Syntax Now that we have created a data model according to the basic syntax that was presented earlier, we can move to some more advanced concepts. There are three special types of entities that need to be explained and added to the diagram to make it clearer. Independent Entity The first type of entity is an independent entity, an entity that can exist without the help of another entity, such as patient, doctor, and insurance company. These three entities all have identifiers that were created using their own attributes (i.e., patient ID number, physician ID number, and insurer name). In other words, attributes from other entities were not needed to uniquely identify an instance. For example, using the patient ID number is sufficient for uniquely identifying a patient in the system shown in Figure A-1. Information from the insurance company, appointment, or payment are not needed to identify a patient, even though these entities share relationships with the patient entity. Independent entities are depicted using rectangles with straight corners. MARKETING MATERIAL MAR_type MAR_description MAR_ MAR_content is described by / describes CD CD_sku CD_title CD_artist CD_category CD_salestatus is stored by / stores INVENTORY INV_store INV_zipcode provides / is provided by reserves / is reserved by IN-STORE HOLD VENDOR VEN_name VEN_address VEN_city VEN_state VEN_zip VEN_contact VEN_phone CUSTOMER CUS_ CUS_lastname CUS_firstname CUST_address CUST_city CUST_state CUST_zip CUST_daytimephone places / is placed by HOL_date FIGURE A-13 Relationships for CD Selections ERD

16 16 Appendix A Data Modeling CONCEPTS IN ACTION A-A The User s Role in Data Modeling I have two very different stories regarding data models. First, when I worked with First American Corporation, the head of Marketing kept a data model for the marketing systems hanging on a wall in her office. I thought this was a little unusual for a high-level executive, but she explained to me that data was critical for most of the initiatives that she puts in place. Before she can approve a marketing campaign or new strategy, she likes to confirm that the data exists in the systems and that it s accessible to her analysts. She has become very good at understanding ERDs over the years because they had been such an important communications tool for her to use with her own people and with IT. On a very different note, here is a story I received from a friend of mine who heads up an IT department: We were working on a business critical, time dependent development effort, and VERY senior management decided that the way to ensure success was to have the various teams do technical design walkthroughs to senior management on a weekly basis. My team was responsible for the data architecture and database design. How could senior management, none of whom probably had ever designed an Oracle architecture, evaluate the soundness of our work? So, I had my staff prepare the following for the one (and only) design walkthrough our group was asked to do. First, we merged several existing data models and then duplicated each one that is, every entity and relationship printed twice (imitating, if asked, the redundant architecture). Then we intricately color coded the model and printed the model out on a plotter and printed one copy of every inch of model documentation we had. On the day of the review, I simply wheeled in the documentation and stretched the plotted model across the executive boardroom table. Any questions, I asked? Very impressive, they replied. That was it! My designs were never questioned again. Barbara Wixom Questions: 1. Based on these two stories, what do you think is the user s role in data modeling? 2. When is it appropriate to involve users in the ERD creation process? 3. How can users help analysts create better ERDs? YOUR TURN A-3 Campus Housing System Consider the following system that was described in Chapter 5. Use the use cases and process models that you created in Chapters 5 and 6 to help you answer the questions below. The Campus Housing Service helps students find apartments. Owners of apartments fill in information forms about the rental units they have available (e.g., location, number of bedrooms, monthly rent). Students who register with the service can search the rental information to find apartments that meet their needs (e.g., a two-bedroom apartment for $400 or less per month within 1/2 mile of campus). They then contact the apartment owners directly to see the apartment and possibly rent it. Apartment owners call the service to delete their listing when they have rented their apartment(s). Questions: 1. What entities would you include on a data model? 2. What attributes would you list for each entity? Select an identifier for each entity, if possible. 3. What relationships exist between the entities that you identified? Label the relationships appropriately, and denote the cardinality and modality of reach relationship. When relationships have an independent child entity, they are called nonidentifying relationships, and they are denoted using a dotted relationship line. This name originated because the attributes from parent entity were not used as part of the child s identifier. The nonidentifying relationships in Figure A-1 include the relationships between appointment and bill, appointment and patient, patient and payment, bill and payment, insurance company and payment, and insurance company and patient.

17 Creating an Entity Relationship Diagram 17 YOUR TURN 7-4 Independent Entities Locate the independent entities on Figure How do you know which of the entities are independent? Locate the nonidentifying relationships. How did you find them? Can you create a rule that describes the association between independent entities and nonidentifying relationships? Dependent Entity You may have guessed that there are situations when a child entity does rely on attributes from the parent entity to uniquely identify an instance. In these cases, the child entity is called a dependent entity (or associative entity), and it needs external attributes to use for identification purposes. Look at Figure A-14, which shows the appointment entity that originally appeared in Figure A-1. Alone, an appointment cannot be identified using the appointment s date and time because likely there are many appointments that are scheduled concurrently. (Several doctors may be seeing patients at 10 AM on March 26.) In this case, you actually would need to add the identifier from the parent entity (doctor) to help identify a unique appointment. Appointment is considered a dependent entity, and the fact that it is a dependent entity is depicted using a rectangle with rounded corners. When relationships have a dependent child entity, they are called identifying relationships, and they are denoted using a solid relationship line. This name originated because attributes from parent entity were needed as part of the child s identifier. The only identifying relationship in Figure A-1 includes the doctor and appointment relationship. DOCTOR DOC_physicianidnumber FIGURE A-14 Dependent Entity Examples DOC_firstname DOC_lastname DOC_address DOC_city DOC_state DOC_zipcode DOC_homephone DOC_pagenumber DOC_primaryspecialty is scheduled for / includes APPOINTMENT APP_date APP_time DOC_physicianidnumber APP_duration APP_reason APP_status YOUR A-5 Dependent Entities TURN The CD Selections ERD has been updated in Figure A- 15. Which entities are dependent entities on this version? Locate the identifying relationships. How did you find them? Can you create a rule that describes the association between dependent entities and identifying relationships?

18 18 Appendix A Data Modeling MARKETING MATERIAL MAR_type MAR_description MAR_ MAR_content is described by / describes CD CD_sku CD_title CD_artist CD_category CD_salestatus is stored by / stores INVENTORY INV_itemnumber INV_store INV_zipcode provides / is provided by reserves / is reserved by VENDOR VEN_name VEN_address VEN_city VEN_state VEN_zip VEN_contact VEN_phone CUSTOMER CUS_ CUS_lastname CUS_firstname CUST_address CUST_city CUST_state CUST_zip CUST_daytimephone places / is placed by IN-STORE HOLD HOL_date FIGURE A-15 Dependent Entities for CD Selections Intersection Entity A third kind of entity is called an intersection entity, and it exists on the basis of a relationship between two other entities. Typically, intersection entities are created to store information about two entities that share a M : N relationship. Think back to the M : N relationship between patient and symptom that was described in Figure A-5. Currently, one instance of a symptom (e.g., sore throat, fever, runny nose) could occur with many patients, and a patient could have many symptoms at one time. A difficulty arises if we want to capture the date upon which a particular patient demonstrates one or more symptoms. For example, we can t place a date in the patient entity because a patient gets sick many times. Alternatively, the date doesn t belong in the symptom entity because it contains symptoms that are shared by all kinds of patients. In this case, an intersection entity is needed to capture attributes about the relationship itself attributes that describe when a particular patient actually has a particular symptom. There are three steps to adding an intersection entity, and this process usually is called resolving a M : N relationship because it eliminates the M : N relationship and problems associated with it from the data model. Step 1: remove the M : N relationship line between the two entities and add a third entity in between the two existing ones. Step 2: add two 1 : N relationships to the model. The two original entities should serve as the parent entities for each 1 : N, and the new intersection entity becomes the child entity in both relationships. Step 3: Name the intersection entity. Many times intersection entities are named using a concatenation of the two entities that created it (e.g., patient symptom), making its purpose clear, or the entity can be given another appropriate name (e.g., illness). Figure A-16 shows the M : N relationship and how it was resolved using an intersection entity. Are intersection entities dependent or independent? Actually, it depends. Sometimes an intersection entity has a logical identifier that can uniquely identify instances within it. For example, an intersection entity between student and course (a student can take many courses and a course can be taken by many students) may be called transcript. If transcripts