1. Heading 1. Conceptual Design LEARNING OBJECTIVES. Study Guide. On completion of this session you will be able to:

Transcription

1 1. Heading 1 Conceptual Design Study Guide 4 LEARNING OBJECTIVES On completion of this session you will be able to: Understand the purpose of Entity Relationship (ER) modelling in database design: o as a design tool o as a communication tool Understand how various basic relational database concepts are represented in ER model: o entity o attributes o bridge/composite entity o relationship participation (mandatory and optionality) o relationships strength (strong and weak) o entity supertypes and subtypes o weak entity o connectivity and cardinality Understand how business rules are reflected in ER models Understand the purpose of converting a many-to-many relationship between two entities into a one-to-many relationship by introducing a bridge entity Interpret ER diagrams Create an ER model from a requirements specification using: o Chen notation o Crow s Foot notation Appreciate the iterative nature of ER modelling process

2 FIT1004 Database Reading Prescribed readings Rob P. & Coronel C. Database Systems: Design, Implementation & Management, Sixth Edition 2004, Thomson Course Technology. Chapter 4 Rob P. & Coronel C. Database Systems: Design, Implementation & Management, Seventh Edition 2007, Thomson Course Technology. Chapters 4 & 6 Further references Website: Rob & Coronel textbook Where we are Introduction to Database Systems The Relational Model Database Lifecycle Conceptual Design Logical Design Physical Design Normalisation Implementation SQL (DML) SQL (DDL & DCL) Transaction Management Database Administration Data Warehousing, Data Mining, ECommerce 32

3 Study Guide 4: Conceptual Design 1. Heading 1 1. Introduction In Study Guide 3 you learnt the characteristics and the components of a relational database model. In this study guide, we will go one step further to look at how a relational database can be designed using a technique called Entity Relationship (ER) modelling. In ER Modelling, we attempt to represent data by first creating an overall picture of the main entities (e.g. people, objects, departments) and their relationships in the organization or business area. Next, details about the entities and relationships are added. All these information are represented using an ER diagram. Due to the strategy used by ER modelling to design a database, it is also referred to as the top-down approach to database design. In many cases, ER modelling is main technique a systems analyst or database designer would use to organise the essential data required for a system he/she is trying to develop. Therefore, it is important for you to be clear on the proper steps to perform this modelling technique in order to ensure the relational database you have designed has the proper structure to organise, store and access its data efficiently. 2. Purposes of ER Modelling ER modelling is an established technique for designing a relational database. In Database Life Cycle (DBLC), ER model is very often one of first models which a database designer will create. In this section, we will discuss the importance of ER Modelling in database design and also from the perspective of systems development: 2.1. Design Tools Abstraction Abstraction is a fundamental concept in modelling. Abstraction is focusing on key aspects of a situation, and ignoring the details that do not directly relate to the situation. For example, when you plan a holiday, you might 33

4 FIT1004 Database use a tourist guide photograph of a waterfall to select the location. You might use a road map to find your way. You might use a weather map to plan your day of arrival. The photograph, the road map and the weather map are all abstractions of the same holiday location, each emphasising different aspects and omitting information about other aspects. To relate this concept to systems development, ER modelling allows us, the database designers, to concentrate on the data organisation aspects of the system. Thus, we can focus on ensuring that all essential data for the system we are developing are stored, properly organised, and efficiently accessed. As a result, data redundancy can be limited. ER model is a conceptual model. Conceptual model is basically a model designed without constrains of software and hardware. From the perspective of DBLC, this is very important as the ER model is one of the first models we will create in the design phase. Here, besides focusing on designing a good structure for the system database, we would also want this abstraction of our database design to be implemented with ease regarding of what software and hardware chosen at the later stages of DBLC. Decomposition Modelling assists decomposition, a core activity in most problem solving activities. Problem decomposition is intrinsic to systems development, in particular requirements definition. Stated simply, a complex problem is partitioned into smaller problems that are more manageable i. From the perspective of database design, ER modelling allows multiple database designers to systematically work on the design of a complex database. This can be done by first partitioning the complex database into multiple sub-databases. Each sub-database can then be allocated to a designer. At this stage, it is important for the designers to discuss how various sub-databases are linked. Finally each designer can proceed to design their sub-database in details. ER modelling thus makes the task of designing a complex database more manageable and efficient Communication Tool Research has found that human can understand information better if the information is expressed using graphics. Since the deliverable of ER modelling is an ER diagram, it is often used as a communication tool between members in a system development team, and also between designers and their clients/users. The use of ER diagram as a 34

5 Study Guide 4: Conceptual Design communication tools allows the designer to effectively verify if the model he/she has developed properly represent the information the system is trying to handle. Another important role of ER diagram is for documentation purposes. With the documentation of ER diagrams developed at different stages for the database, there will be proper records of the database design process. This allows the designer to fall back to pervious designs if alterations are needed during various stages of DBLC. If there is a change in personnel in a project team during the development of a system, such documentation will also make the transitions smoother as the new members can efficiently understand various components of the current design. If future enhancements or alterations are needed for the database, such documentation will also be handy. 3. ER Diagram Convention As stated in the introduction, the main deliverable of ER modelling is an ER diagram. As usual, to learn to create any standard diagram and to use it as a potential communication tool, it is important to first know the proper notations (i.e. set of symbols) used to represent various components in the ER model. It is also important to understand the object that each of these symbols represent in a real physical database. Such understanding will enhance your ability to convert and implement the information you have captured in the ER diagram to a real database later in the unit. There is a wide range of diagramming and naming conventions used for ER diagrams. Different companies will have their preferred choice of ER modelling notation stated as part of their company standard. Different DBMS textbooks are likely to illustrate their ER models with different sets of notations. From a database designer perspective, as long as we are wellversed in one ER notation, it is normally easy for us to understand the other notations. In the prescribed text, the Chen model and the Crow s Foot model are used Entities and Attributes 35

6 FIT1004 Database Read R & C 6 th Edn, p Sections & R & C 7 th Edn, p Sections & Relationships Read R & C 6 th Edn, p Section R & C 7 th Edn, p.109 Section Connectivity, Cardinality and Relationship Participations Read R & C 6 th Edn, p Section R & C 6 th Edn, p Section R & C 7 th Edn, p Section R & C 7 th Edn, p Section Do R & C 6 th Edn, p Review Questions 20, 21, 8 R & C 7 th Edn, p Review Question 17, Problem Composite Entities Read R & C 6 th Edn, p Section R & C 7 th Edn, p Section

7 Study Guide 4: Conceptual Design 3.5. Relationship Degree Read R & C 6 th Edn, p Section R & C 7 th Edn, p Section Relationship Strength and Entity Strength Read R & C 6 th Edn, p Section R & C 6 th Edn, p Section R & C 7 th Edn, p Section R & C 7 th Edn, p Section Entity Supertypes and Subtypes Read R & C 6 th Edn, p , Section R & C 7 th Edn, p Section As most DBMSs do not directly support the supertypes and subtypes relationships between entities, it is important for a database designer to be able to convert such relationships between these entities to 1:1 relationships. This is normally done in the logical design phase when we transform the ER diagram into a logical model. We will cover logical design in the next study guide. Read R & C 6 th Edn, p , Section 4.3 R & C 7 th Edn, p Section

8 FIT1004 Database 4. ER Modelling Software To facilitate the modelling of systems and relational databases, many modelling software have been developed. The commonly known commercial modelling software are: MS-Visio: Rational Rose: Some other publicly available freeware which have similar ER modelling functionalities are: VisioModeler: FE6786-A B8B6-7A9B84CFA709&displaylang=en UMLet: Violet: DIA: ArgoUML: Instructions to use MS-Word to draw ER diagram: ml 5. Steps in producing an ER diagram The steps in developing an ER model are: 1. List the major entities in the system. 2. Represent the entities graphically by a rectangle. 3. Search for relationships between the entities and represent them graphically with the proper symbol (e.g. a diamond if Chen s notation is used). Determine if there are supertypes and suptypes relationships between entities. 4. Add attributes; remember to establish the primary key for every entity. 5. Model relationship connectivity between each pair of entities. 38

9 Study Guide 4: Conceptual Design 6. Model relationship cardinalities between each pair of entities (i.e. the minimum and maximum participation). 7. Determine if composite entities are to be created. If required, refine the connectivity and cardinality of entities affected. 8. Verify the ERD you have created by going through each component you have created from Steps (1) to (7). Ensure that they properly represent the business rules of the system you are developing the database for. Repeat this process until your ER diagram is complete. 6. Step-by-Step Walkthrough on Developing an ER Diagram Next, we will demonstrate strategies for constructing an ER diagram, which is a suitable conceptual model for Fly By Night Tours, based on the information in the case study below. Fly-By-Night Travel Fly-By-Night Travel Agencies organise tours. The company has an agency in the capital cities of various countries around the world. Each travel agency organises a range of tours within their own country. The company does not organise any inter-country tours. Customers book on these tours (a given customer may book on many tours) and may pay for the tour in a series of instalments. For each payment, a receipt is issued containing a receipt number (5 digit max ), date of payment (Date), customer number, amount of payment and the tour number. For each tour the company maintains a worldwide unique tour number (99999), the tour name (20 characters - C20), tour description (C50), maximum number of participants (maximum of 99), the date of departure (date), and return (date), the adult tour cost ( ), the child tour cost ( ) and details for each overnight stop on the tour which include the date of stop (date), hotel name (C20), hotel fax number (C15), and city (C20) for each overnight stop in the tour. Each customer is assigned a worldwide unique customer number (99999). The company also maintains data on family name (C20), given name (C20), street address (C20), town/city (C20), postcode/zip (C4), and telephone number (C10 - not all customers have a telephone number), of each customer. When a customer books a tour, the company also records the date of the booking, the number of adults and number of children booked on the tour, the total amount owed by the customer on this tour and their current outstanding balance on this tour. If the customer pays for a tour by instalments, this outstanding balance is modified each time a payment is 39

10 FIT1004 Database made. For each agency, the agency code (C2), agency name (C20), agency address (C40), telephone number (C10), and manager's name (C20) are recorded. Note: C30 - represents a data item which has been identified as 30 characters represents a numeric data item containing a maximum value of 999 When constructing an ER diagram, it is always important to remember that an ER diagram is a conceptual design of the type and the organisation of data that should be stored for the system to be developed. Thus it is always important to be clear on what functions this system performs and what kind of data output (e.g. reports) it must be able to produce. In this system, its database must be able to provide reports for the following queries: a. A listing of all tours showing tour number, name and departure date b. A listing showing for every payment made the receipt number, payment date, payment amount, customer number and customer full name c. A listing for all customers showing, the names of all the tours they have booked on, the departure dates, the number of adults and children they have booked on each tour and their current outstanding balance for each tour. This report should be in departure date order. Now, with all the information above, we will walk through the ER modelling procedure based on the steps illustrated in Section 5: 1. List the major entities in the system. A good technique to identify the entities relevant to the system is by looking for nouns in the case study descriptions. In the following, we will illustrate the nouns in the description by underlining them and the nouns which are identified as entities will be illustrated by underlining and bolding them. Let start with the first paragraph: Fly-By-Night Travel Agencies organise tours. The company has an agency in the capital cities of various countries around the world. Each travel agency organises a range of tours within their own country. The company does not organise any inter-country tours. Customers book on these tours 40

11 Study Guide 4: Conceptual Design (a given customer may book on many tours) and may pay for the tour in a series of instalments. For each payment, a receipt is issued containing a receipt number (5 digit max ), date of payment (Date), customer number, amount of payment and the tour number. Explanation: The first sentence provides us with some background information about Fly-By-Night Travel, so the nouns here are ignored. In the second sentence, agency is identified as an entity because it is important to keep a record of all agencies associated with Fly-By-Night Travel. This allows us to keep track of important information on which tours is organised by which agencies. Now we will explain why other nouns here are not identified as entities for this system. Company is not a relevant entity in this system because it is basically referring to Fly-By- Night Travel. There is no point having an entity Company that will only have one record in it. As for cities and countries, they are actually attributes (i.e. part of address) for entity agency. As for world, there is again no point having such an entity because no proper records will appear in it for this system. Tour is another entity identified because as stated above, the database must be able to provide a reports listing information of all the tours. No new nouns appear in the third sentence. Finally, we will look at the last two sentences of the first paragraph. Customer is identified as an entity because this system requires information on which customers have booked which tours to be kept. As for the next three nouns (i.e. instalments, payments & receipt), only payment is identified as an entity because in this context, they are basically synonyms of each other. This means that the attributes describing each of these three nouns are exactly the same. Thus, to avoid data redundancy in the database, only one of them is identified as entity. Now we will proceed on to the second paragraph: For each tour the company maintains a worldwide unique tour number (99999), the tour name (20 characters - C20), tour description (C50), maximum number of participants (maximum of 99), the date of departure (date), and return (date), the adult tour cost ( ), the child tour cost ( ) and details for each overnight stop on the tour which include the date of stop (date), hotel name (C20), hotel fax number (C15), and city (C20) for each overnight stop in the tour. 41

12 FIT1004 Database Explanation: The first ten nouns (i.e. tour number, tour name, tour description, number of participants, date of departure, return (date), adult tour cost, child tour cost) in the second paragraphs are all attributes describing the entity tour. Stop is identified as an entity because it is likely that a customer will be interested in knowing a tour s stop locations when they are booking that tour. The last four nouns are attributes (i.e. date of stop, hotel name, hotel fax number, and city are attributes describing the location in entity stop. Finally, we will assess to the third paragraph: Each customer is assigned a worldwide unique customer number (99999). The company also maintains data on family name (C20), given name (C20), street address (C20), town/city (C20), postcode/zip (C4), and telephone number (C10 - not all customers have a telephone number), of each customer. When a customer books a tour, the company also records the date of the booking, the number of adults and number of children booked on the tour, the total amount owed by the customer on this tour and their current outstanding balance on this tour. If the customer pays for a tour by instalments, this outstanding balance is modified each time a payment is made. 42

13 Study Guide 4: Conceptual Design Explanation: In the third paragraph, no nouns are identified as entities. The first eight nouns (i.e. customer number, family name, given name, street address, town/city, postcode/zip, and telephone number) described here are attributes for entity customer. The final five nouns (i.e. date of the booking, number of adults, number of children, total amount, current outstanding balance)are attributes associated with the tours the customer has booked. So, after going through the procedure demonstrate above, we have identified the initial list of entities which are relevant this system. 2. Represent the entities graphically by a rectangle. With the list of entities identified in Step 1, we can carry out this step easily. When naming the entities, the convention is to use singular rather than plural. For example, Customer is used rather than Customers. It is also important to use a name which is meaningful and can properly represent the attributes it carries. For example, instead of using the entity name Stop, we will use Location instead. 3. Search for relationships between the entities and represent them graphically with the proper symbol (e.g. a diamond if Chen s notation is used). Determine if there are supertypes and suptypes relationships between entities. The verbs in the case study description will normally provide us with clues on the relationships between entities. For examples, agency organises a range of tours and Customers book on these tours. Verbs - organises and book, indicate the relationships between entities agency and tour, Customer and tour respectively. By using the technique illustrated in this step, we can come up with an initial ER diagram in crow s foot model as follows: 43

14 FIT1004 Database As we usually read the ER diagram from top-to-bottom, and left-to-right, we can decide on the tense of the verse based on the way we read. 4. Add attributes; remember to establish the primary key for every entity. With the analysis we have carried out in Step 1, the attributes for each entity are already identified. With the attributes, the ER diagram can be illustrated as follows: 5. Model relationship connectivity between each pair of entities. 6. Model relationship cardinalities between each pair of entities (i.e. the minimum and maximum participation). Steps 5 and 6 can normally be carried out together since the connectivity is equivalent to the maximum participation of the cardinality at each end of that relationship. To accurately identify the cardinality, we will also start with one instance of the entity at one end and decide the minimum and maximum participations of the entity at the other end. Having done that, we will then consider one instance of the entity at the other end can be associated with the minimum and the maximum participations of the initial entity. Let look at the entities Customer and Payment for an example. Using the technique I have just described, we will know that one customer record can be associated with a minimum of Zero payment record (because that customer has yet to make any payment/instalment for 44

15 Study Guide 4: Conceptual Design the tour) and a maximum of Many payment record. Graphically, it can be shown as: Now, ignore the cardinality you have decided on the payment end, consider the cardinality over at the customer end for one payment record. Here, one payment record can be associated with a minimum of One customer record and maximum of One customer record. This is because if a payment is recorded, it must be paid by one and only one customer. Graphically, this can be shown as: When the relationship cardinalities between each pair of the entities is identified, the ER diagram can be illustrated as follows: 7. Determine if composite entities are to be created. If required, refine the connectivity and cardinality of entities affected. Composite entity is usually created to contain attributes which should rightfully be represented at the relationship, instead of any of the entities 45

16 FIT1004 Database the relationship is connecting. This is because if these attributes are contained in any of the entities the relationship is connecting, it will result in inadequate data redundancy and high tendency of anomalies. In the ER diagram, we will usually find attributes required to be represented on the relationship at places where there are many-to-many relationship connectivities between entities. In this case, we can find that between entities Customer and Tour, and also between entities Tour and Location. To assess if there is a need to create a composite between entities Customer and Tour, we will need to go through the attributes in these entities and see if any of them are better contained on the relationship. In this case, all the attributes in entity Tour related to booking are better contained on the relationship books. It is not suitable to have these attributes in Tour and attributes there should only record information of various tours organised. With information about booking in entity Tour, it also means that everytime a booking for a particular tour is recorded, we will need to repeat the information of that tour again. This causes data redundancy, which may in turn lead to anomalies. With this assessment, a composite entity called Book is created to contain the attributes related to booking. As for entities Tour and Location, if similar assessment is carried out, we will find attribute stop_date is better contained on the relationship. Thus, a composite entity named Stop_At is created to contain the attribute stop_date. After adding the composite entities and refining the connectivities and cardinalities, the ER diagram will be as follows: 46

17 Study Guide 4: Conceptual Design 8. Verify the ERD you have created by going through each component you have created from Steps (1) to (7). Ensure that they properly represent the business rules of the system you are developing the database for. Repeat this process until your ER diagram is complete It is important to note that you may not correctly construct the final ERD at your first attempt. You may need to go through a few iterations before deriving a satisfactory ERD. When you have verified that your ER diagram does represent the business rules of the system, you can finally refine your ER diagram by adding information like the relationship strength and entity strength. The final ER diagram for Fly-By-Night Travel is as follows: Do Draw the ER diagram for Fly-By-Night Travel database using Chen s model. 47

18 FIT1004 Database Read R & C 6 th Edn, p , Section 4.3 R & C 7 th Edn, p Section 4.2 In this section, you can find another example on developing an ER diagram. 7. Summary In this study guide, you have learnt how to design a conceptual database model using ER modelling. Two standard ER models are taught here. They are the Chen s and the Crow s Foot models. With a case study, a step-by-step walkthrough on the ER modelling procedure is also covered in this study guide. Since conceptual design is commonly viewed as the first step towards a good database design, it is important for you to understand the materials in this study guide. i Pressman, R. S. (2001). Software engineering: a practioner's approach. New York, USA, McGraw-Hill.p67 48