How To Model An Entity Relationship Model

Transcription

1 Chapter 4. Entity-Relationship Diagrams Table of Contents Objectives... 2 Introduction... 2 The DATA perspective of information systems... 2 ERDs, relational databases and object-oriented analysis and developement... 3 Overview of notation... 3 Entities and attributes... 4 Entities... 4 Attributes... 6 Relationships... 9 Introduction to relationships between entities... 9 The degree of relationships...10 Optionality of relationships...15 Application of Entity-Relationship model concepts...17 How to Make Entity Relationship Models...19 Introduction to inferring ER models from text descriptions...19 Stage 1: Identify entities...19 Stage 2: List entity attributes and identify primary keys...21 Stage 3: Identify relationships...23 Stage 4: Remove many-to-many relationships...24 Repeat stages Stage 5: Validation...26 Creating ERDs using the SELECT-Enterprise CASE tool...28 The SELECT-Enterprise CASE tool...28 Overview of using the SELECT system...28 An ERD created using SELECT...30 Creating a project...30 Creating a new Storage Class Diagram file...32 Opening an existing Storage Class Diagram...34 Adding a table to a Storage Class Diagram...35 Adding a relationship between tables to a Storage Class Diagram...36 Editing the properties of relationship diagram object...38 Deleting diagram objects...41 Adding columns and prime keys to tables...41 SELECT Reference: Viewing...49 Activities...50 Answers and Discussions...52 Solution to Exercise Solution to Exercise Solution to Exercise Solution to Exercise Solution to Exercise Solution to Exercise Solution to Exercise Solution to Exercise Solution to Exercise Solution to Exercise Solution to Exercise Solution to Exercise Solution to Exercise Solution to Exercise Solution to Exercise

2 Solution to Review Question Solution to Review Question Solution to Review Question Solution to Review Question Solution to Review Question Solution to Review Question Solution to Review Question Solution to Review Question Solution to Review Question Solution to Review Question Solution to Review Question Solution to Review Question Solution to Review Question Solution to Review Question Solution to Activity Solution to Activity Solution to Activity Objectives At the end of this chapter you should be able to: Explain the purpose of entity relationship diagrams Describe the meaning of the symbols used in entity relationship diagrams Construct a simple entity relationship diagram from a textual description of some data Document an entity relationship diagram using the SELECT-Enterprise software Introduction The DATA perspective of information systems Data is the foundation of any information system and, as businesses increase the levels of automation, data is now crucial to the success of any business. Companies often have a Database Administrator (DBA) who is in charge of the day-to-day management of the business database and ensures that all parts of the business can receive the data they require in an efficient and trouble-free manner. More recently, companies have also employed a Data Administrator (DA). This person does not handle the technical issues like the DBA but rather is in charge of the strategic aspects of the data such as what data should be stored, the quality of the data and its security. The DA is a senior manager and may even be an executive in the company. It is clearly necessary to have a good picture of the data held in an information system. Entity relationship diagrams are used to produce a model of the full data structure for a system showing all the data stored and how that data is inter-related. In developing entity relationship models of the system, the systems analyst focuses only on what data is stored in the system. How the data is stored and how it is processed are not represented at all in this model. The key here is to produce a clean logical model of the data which will allow the system to operate successfully and flexibly in a variety of implementations. In the course of developing a system, the functions which it must perform are often changed considerably from the original intentions but substantial changes in the data are much less likely. Thus, the entity relationship model provides a sound foundation for the development of the rest of the system. The required properties in an entity relationship model are therefore: 2

3 Structured - the model must define an efficient structure for the data. A good entity relationship model can be translated easily into a database design. Logical - there is no reference to how the data is stored Process independent - there is no reference to how the data is processed Minimal - there are no repetitions or redundancies or dependencies in the data stored It is because of these first two points that the term Logical Data Structure (LDS) is used interchangeably for Entity-Relationship Diagram (ERD or ER diagram ). Exercise 1 Is ER modelling a process- or data- oriented approach to systems analysis? A discussion of this exercise can be found at the end of this chapter. Exercise 2 What does each letter stand for in ERD? A discussion of this exercise can be found at the end of this chapter. Exercise 3 What does each letter stand for in LDS? A discussion of this exercise can be found at the end of this chapter. ERDs, relational databases and object-oriented analysis and developement As has been described earlier, ERDs are a logical model of system data. There are different ways that a information systems analysis and developer may wish to use an ERD, for example: the ERD can be implemented as a relational database, or a flat file database the ERD can be a model for object-oriented class data the ERD might be a model of an existing information system or it might be a model of a proposed new information system It doesn t matter what use the ERD is to be put to, since an ERD is a logical model, independent of implementation issues. So when working with ERD don t worry about object-orientation or different kinds of databases, focus on modelling the logical relationships between the things you believe a system needs to store data about. Overview of notation Entity-relationship diagrams use a small number of notational symbols to record and communicate the logical structure of data for an information system. During this section you will learn the concepts of ER modelling and how to associate some of those concepts with each of the following 4 symbols: 3

4 There are more concepts in ER modelling than are usually displayed in ER diagrams, so ER diagrams are accompanied by more detailed textual and tabular descriptions of entities and their relationships. Entities and attributes Entities The main components of the entity relationship diagram are entities. An entity can be thought of as a key category of thing about which the system needs to store information. For instance, in a university timetabling system, examples of the things the system needs to store information about are students, teachers, courses and modules. So the entities used would be STUDENT, TEACHER, COURSE and MODULE correspondingly. Or in for an estate agency some of the entities are CLI- ENT, PROPERTY and BUYER. Note Although it is not necessary to always write the names of entities in UPPER CASE letters, it is a useful convention we shall follow in this unit s study materials. An entity is represented on a diagram as a rectangle with the name of the entity written in it. The following shows the notation for a STUDENT entity: Note An important feature of entity naming to note is that an entity has a singular name. An entity is the name for a category of objects about which the system needs to store data. A system may need to store data about this STUDENT or that STUDENT or about some CLIENT or other. Entities are never named with plural names like STUDENTS, TEACHERS or CLIENTS. Though it may sound peculiar to name each entity in the singular, it does make sense. In modelling the data stored, the analyst is interested in the type of thing stored rather than the actual things which will be stored. For example, in a university timetabling system, the analyst does not care that the system will have to store information on a particular lecturer called, say, Paul Cairns or some other called Mohammed Youssef, only that the system will need to store data about each TEACHER in general. The analyst wants to know what type of thing the system needs to store data about, and the answer is singular, Paul Cairns is a TEACHER, Mohammed Youssef is a TEACHER, John Smith is 4

5 a CUSTOMER and so on. There are many people a sales system, for example, needs to store data about that the data analyst does not know, nor need to know each ones name, just that each one is a CUSTOMER or SUPPLIER or DELIVERY PERSON or whatever; hence the singular is used for the name of each entity. You may find this confusing at first but as you see more examples you should find that using the singular becomes more natural and logical. The whole system itself does not appear as an entity on the diagram. This should be reasonable if you think that the entities are the categories things about which the system stores data. An information systems does not store data about itself! However, one can consider a complete ERD to be a model of all the data of the system. ERD entities for real world and logical things It should be noted that not every entity in an ERD has to have a real world equivalent. So while many of the entities of a system do relate to real world physical entities, such as people (CUSTOMER, TEACHER, STUDENT, EMPLOYEE etc.) or physical objects (PRODUCT, LIB- RARY ITEM, COURSEWORK etc.), other entities may only exist as logical entities. A logical entity might be something like a PROJECT MILESTONE it is some logical concept that we wish the system to store information about but does not correspond to a physical thing in the real world. Another kind of logical entity is an intersection entity there are ways in which the complexity of a logical data structure can be simplified, which we shall investigate in a later section. Exercise 4 Name the entities in the following ERD (for now don t worry about the other parts of the diagram): A discussion of this exercise can be found at the end of this chapter. Occurrence of entities An occurrence of an entity is one particular thing about which the system stores data. So if a system is modelled as having a CUSTOMER entity, each actual customer would be an occurrence, such as Fred Bloggs, John Smith, Ali Shah and Donald Macmillan. Another example could be for a PRODUCT entity of a supermarket, occurrences might include milk, bread, cheese, rice and so on. What if two CUSTOMERS have the same name? Are there 2 occurrences or just one? The way that we distinguish between each different occurrence is covered soon, in the section on primary keys. For now it is sufficient to learn that the term occurrence refers to each thing real world or conceptual thing whose overall category is modelled by an entity on an ERD. Exercise 5 Consider a bank system that has entity LOAN TYPE. What might be some of the occurrences for this entity? 5

6 Attributes A discussion of this exercise can be found at the end of this chapter. Each entity has an associated list of attributes. The attributes of an entity define the relevant pieces of data that can be stored for each occurrence of the entity. The word relevant is important, since we must remember that an ERD is a logical model of a system, and as the systems analyse we define what is included in the system, i.e. what are the relevant aspects of the real world we believe should be modelled. For example, a STUDENT entity for a university system might have attributes including: Student Number Name Date of Birth Programme of Study and so on A TEACHER entity might have attributes such as: Name Department Hours per Week Base Campus Telephone number address and so on There are many other attributes a real world student might have, such as weight, height, favourite book and pop band etc. However, when we model a system for an ERD we must define what is relevant for the particular system being modelled. For a university timetabling or results system, attributes such as weight, height, favourite book are simply not relevant and do not need to be modelled. Note It is usually possible to think of examples of systems for which it would be relevant to model any particular real work attribute of a real world entity. For example, a music or product marketing system might very well include physical and consumer taste attributes to be relevant, perhaps for forming profiles of customers for individualised electronic or direct marketing. Therefore it is important to continually bear in mind the particular system that is being modelled when working on ERDs. Attributes do not (usually) appear on the main ER diagram but the list of attributes for each entity form part of the text accompanying the diagram. Note An attribute must be a simple, single item of data, such as Name or Age. An attribute should not be a complicated structure, such as a lists of things. If an attribute is complicated (i.e. more than a single value) then perhaps it should be an entity in its own right, and the ER model re-evaluated in terms of this new entity. We shall consider such de- 6

7 cisions in the logical data structure analysis process later this unit. Occurrences are sets of attribute values Each occurrence of an entity is a set of values for the attributes of the entity. So three occurrences of a TEACHER entity with attributes Name, Hours per week and Base campus we might have values of: Staff number Name Hours per week Base campus #02034 Paul Cairns 40 Upper Campus #02041 John Makuma 40 Middle Campus #07201 Patricia Nkosi 20 Art Campus Primary Keys Certain attributes can be used to uniquely identify different occurrences of an entity. Such attributes are called a key and can be either a single attribute like Student Number or Staff Number, or a combination of attributes like Name and Date of Birth. A key made up of more than one attribute is called a composite key. There may be a number of candidate keys for a single entity each candidate key is an attribute or combination of attributes that uniquely identify an occurrence of the entity. Examples of likely candidate keys for a STUDENT entity might be: Student number First Name + Surname + Date of birth First Name + Surname + Postal/ZIP code When entities are defined one of the candidate keys is chosen (often a single numeric attribute like Student Number or Part Number) and this is referred to as the primary key for the entity. A common convention is to underline the attribute(s) that form the primary key for each entity. Some examples of entities with their primary key attribute(s) underlined are the following: CUSTOMER Customer Number First name Surname Address STUDENT Student Number First name Surname Address 7

8 STAFF MEMBER First name Surname Postal Code Office Location PRODUCT Part Number Description Price LIBRARY ITEM Catalogue Number Copy Number Title Publisher MODULE REGISTRATION Student Number Module Code Semester Year Grade Exercise 6 Of the examples of primary keys listed above, which entities have single attribute primary keys, and which have composite primary keys? For each entity state the attribute(s) that form its primary key. A discussion of this exercise can be found at the end of this chapter. Exercise 7 For each of the entities above that have composite primary keys, suggest a reason why multiple attributes are needed for the primary key. A discussion of this exercise can be found at the end of this chapter. A good way to envisage an entity is as a table. The entity name describes the type of thing represented in the table, the column headings are the attributes, each row is an occurrence and the entries in 8

9 the table are the values of the attribute for the given occurrence. Foreign keys A foreign key is where the primary key of one entity occurs in another entity. An entity only has a foreign key if all primary key attributes of the other entity appear as attributes in the second entity. It does not matter if all or some of the foreign key attributes form part of the primary key for this second entity. An example would be the primary key of STUDENT (Student number), appearing as part of the primary key of MODULE REGISTRATION (Student number, Module, Semester, Year). In this case the primary key attribute Student number of entity STUDENT is appearing as a foreign key in the entity MODULE REGISTRATION. A relationship can only occur between two entities if the primary key of one entity occurs as a foreign key of the other since a relationship is between occurrences of entities, and occurrences are refereed to by the values of the primary key attributes. Attribute data types Each attribute of an entity is of a particular data type. There are many basic types of data, such as integers, real numbers (perhaps to a certain number of decimal places), characters, times and dates, Boolean yes/no or true/false values, and strings of characters for attributes like names and addresses. There are also likely to be special kinds of data types for each particular information system. For example, for an Estate Agent information system there might be a property type, which is the set of values { detached house, semi-detatched house, terraced house, flat }. Although it is possible to use a sequence of characters to record values for these attributes, many CASE tools, include SE- LECT-Enterprise, allow an analyst to add new data types, such as house type, to the dictionary of attribute data types available. Relationships Introduction to relationships between entities In addition to entities, the other key parts of any entity relationship model are of course the relationships. A relationship between two entities means that occurrences of one entity directly affects occurrences of the other entity. So for instance, students study modules so the STUDENT entity is related to the MODULE entity. Also modules are taught by teachers and so there is a relationship between the MODULE entity and the TEACHER entity. 9

10 Relationships work in two directions. If entity A is related to entity B then entity B is related to entity A. This is represented on the diagrams. To show a relationship between entities, a line is drawn between the two entities and the description of the relationship is given in both directions. So the relationship of a STUDENT attending a MODULE is represented as: This is understood to mean the two sentences: One (occurrence of) STUDENT studies (an occurrence of) MODULE and One (occurrence of) MODULE is studied by (an occurrence of) STUDENT The degree of relationships A note on terminology Note The term degree originally was used to refer to the number of entities involved in a single relationship. In this unit we shall only consider binary relationships i.e. those relationships that involve 2 entities. However, it is possible, though uncommon, to create data models with ternary (3 entities) relationships, or relationships with even higher degrees. The term cardinality was used to refer to the one-to-many ness etc. of relationships, which we now think of as the degree explained in this section. However, since most ER modelling is performed with only binary relationships, many ER modellers are use with the term degree to indicate the cardinality of relationships. We shall follow this convention since most books these days on ER modelling do the same. However, you may wish to bear in mind when reading other resources (books, web pages, user manuals) that if there is an presence of the term degree and the term cardinality then the term degree is probably being used in its original sense, meaning the number of entities involved in a relationship. It is usually clear whether the original meaning of the term degree is being used from the context of the writing e.g. look out for statements such as a relationship with degree of two is a binary relationship and a relationship with a one-to-many cardinality and so on. All the book references made in this unit are to modern books that do not use the term cardinality. The relationship symbols on ER diagrams can indicate how many occurrences can be involved between the entities. For example, one occurrence of a TEACHER can teach many modules, i.e. by many occurrences of a MODULE entity. Example occurrences might be: MODULE Module Code Number of units Teacher Number COM422S 20 #001 INT412W 20 #001 BIS313F 10 #002 TEACHER 10

11 Teacher Number Name Base Campus #001 Dr Matt Matambo Upper Campus #002 Dr Evelyn Jones Upper Campus #003 Prof Sarah Tambi Middle Campus From these example occurrences we can see that TEACHER #001 teaches 2 MODULES (occurrences COM422S andint412w). But a module is taught by only one teacher, so one occurrence of MODULE is related to only one occurrence of entity TEACHER. So MODULE occurrence COM422S is taught by TEACHER #001, MODULE INT412W is taught by #001 and MODULE BIS414F is taught by TEACHER #002. Occurrence diagrams The (maximum) number of occurrences (one, many) involved is called the degree of the relationship. Some data modellers prefer to create occurrence diagrams which list just the primary key and foreign key attributes of each entity, and show how occurrences in one entity relate to occurrences in the second. An occurrence diagram for MODULE and TEACHER is illustrated below: One can create occurrence diagrams either from samples of real world data collected during analysis, or through creating possible system data, and having users confirm the occurrences created are plausible in the real world. Occurrence diagrams can clearly show where many occurrences in one entity relate to one occurrence in the other entity. The relationship can be described in two sentences, one for each direction: One TEACHER teaches one or more (many) MODULEs One MODULE is taught by only one TEACHER Note Some people prefer to use the word each rather than one when writing the sentences for each relationship. In which case the sentences for the TEACHER-MODULE relationship would be: Each TEACHER teaches one or more (many) MODULEs Each MODULE is taught by only one TEACHER Either convention is fine, but with all conventions ensure you are consistent in which convention you apply. The degree of a relationship is usually represented by a single line for one occurrence, and the 11

12 crow s foot symbol for many occurrences. For example in the ER diagram below one occurrence of the ORDER entity can contain many occurrences of the SHOPPING TROLLY ITEM entity, so at the SHOPPING TROLLEY end of the relationship line we see the crow s foot. However, in the diagram above, one occurrence of SHOPPING TROLLEY ITEM (i.e. item to purchase by a customer for this order) can only occur in one occurrence of ORDER, so there is a single line where the relationship touches the ORDER entity: This can be read as: one ORDER contains one or more (many) SHOPPING TROLLY ITEMs and one SHOPPING TROLLY ITEM occurs in only one ORDER. So the 3 different cardinalities of (binary) relationship are: One-to-one : one A is related to one B and one B is related to one A One-to-many (or many to one depending on which way round you look at it) one A is related to one or more (many) B and one B is related to one A Many-to-many: one A is related to one or more (many) B and one B is related to one or more (many) A Note 12

13 Some authors do not use the crow foot notation for the many part of relationships, instead the symbols 1, N and M are used: One-to-one is labelled on a diagram as 1 : 1 One-to-many is labelled on a diagram as 1 : N Many-to-many: is labelled on a diagram as M : N Exercise 8 Consider this part of an ERD for a theatre with a one-off evening of readings of dead poets. What is the degree of the relationship shown in the ERD for SPEAKER and POEM? Write down the two sentences describing the relationship in each direction. A discussion of this exercise can be found at the end of this chapter. One-to-one relationships are rare One-to-one relationships are quite rare as it generally means that the two entities are so closely related that they may actually be different parts of a single entity. It is difficult to give a simple example which would occur in practice but a less realistic one would be each husband is married to one wife and each wife is married to one husband but clearly the two entities are distinct. Another might be between a managing director of a company and his/her personal assistant (we assume the MD has only one PA, and that the PA works for only the MD). A third example might be UNIVERSITY FACULTY and DEAN OF FACULTY, where each faculty has a single dean, and a person can only be a dean for one faculty: One-to-many relationships The entity at the one end of a one-to-many relationship is often called the master entity, and the entity at the many end is called the detail entity. A rule that always holds for one-to-many relationships is that the primary key of the master entity will appear as a foreign key in the attribute list for the detail entity. This makes sense when thought through: we are stating that: one occurrence of the master entity can relate to many occurrences of the detail entity, and each occurrence of the detail entity relates to only one occurrence of the master entity, then each detail entity occurrence should have attributes to state which occurrence of the master entity it relates to 13

14 Intersection entities to simplify many-to-many relationships Many-to-many relationships are common, but are then broken down into a simpler form (i.e. two one-to-many relationships) partly because they are difficult to represent in databases but mostly because they hide information and that defeats the point of doing these models. For example, each STUDENT studies many MODULEs and each MODULE is studied by many STUDENTs. This is a good example of a many-to-many relationship. This is represented as: But where do we put the information of the grade obtained and when a student studied a module? We cannot put it with the MODULE as that would mean all students achieved the same grade and studied the module at the same time. We cannot put it with the STUDENT as that would mean the student achieved the same grade and studied all modules the same time. Both of these are wrong. So instead, an intersection entity is invented and given a sensible name, in this case MODULE RE- GISTRATION and the diagram re-drawn as follows: The first relationship can be read as: One STUDENT registers for one or more MODULE REGISTRATIONS and One MODULE REGISTRATION is by only one STUDENT The second relationship can be read as: One MODULEs study is registered by one or more MODULE REGISTRATIONs and One MODULE REGISTRATION is for only one MODULE We can now make the grade and time / semester of the study attributes of the MODULE REGIS- TRATION entity. This breakdown of a many to many into an intersection entity is entirely routine and should be done whenever you come across such a relationship. The only difficult aspect of creating intersection entities is the choice of name for the new entity and the relationships. If no good names come to mind you should do the following automatic insertion of an intersection entity, and leave the choice of names until a later stage of modelling. 14

15 Automating the insertion of an intersection entity Consider a many-to-many relationship between two entities A and B: An intersection entity called AB or BA (or a better name if one comes to mind) should be inserted as follows to simplify the many-to-many into 2 one-to-many relationships: Note Each of these new one-to-many relationships is always mandatory for the intersection entity. Refer back to this statement when you have read the section on optionality of relationship occurrences. Exercise 9 Simplify the following many-to-many relationship by inserting an intersection entity. A discussion of this exercise can be found at the end of this chapter. Optionality of relationships Not all relationships hold for all occurrences. For instance, a TEACHER may or may not be teaching on any MODULEs in a certain semester (say when the teacher is on sabbatical). In other cases, the relationship always holds. A MODULE must always be taught by some TEACHER. If a relationship does not always hold then it is said to be optional, other wise it is mandatory. Note Some books use the term participation rather than optionality. The terms are interchangeable, and both refer to optional and mandatory participation in relationships. Different notations for optionality of relationships There are two different ways that the optional relationships can be represented on ERDs. Mandatory relationships are always indicated by solid lines. Optional relationships are either represented by 15

16 dotted lines or by a solid line that begins with a small circle (at the optional end of the relationship line). The second of these notations is the one provided by the SELECT-Enterprise CASE tool. So the above relationship between TEACHER and MODULE can be represented in either of the following ways: This reads as One TEACHER may teach on one or more (many) MODULEs and One MODULE must be taught by only one TEACHER. Just as for degree it is possible to have either, both or neither ends of a relationship as optional. Reminder Each new one-to-many relationships resulting from an intersection entity is always mandatory for the intersection entity. Refer back to the section on intersection entities if necessary to understand this. Exercise 10 Decide on the optionality of each direction of a relationship is travelled to by from entity DESIN- ATION to FLIGHT and relationship travels to FLIGHT to DESITINATION for an internet flight web page system. The relationship is one-to-many from DESTINATION to FLIGHT one DES- TINATION is travelled to by many FLIGHS. Draw an ERD for these entities indicating the optionality your have decided. A discussion of this exercise can be found at the end of this chapter. Exercise 11 Summary exercise. Fill in the blanks for each summary statement below. are the categories of things which are stored in the system are the types of data actually stored for each entity of an entity are a particular set of attribute values which represent a thing of the type given by the entity describe how occurrences of the entities relate to each other A relationship corresponds to sentences one for each direction Relationships can be one-to-, one-to- or many-to-. This is called the of the relationship Relationships can be or mandatory in either direction. This is called the of the relationship 16

17 A discussion of this exercise can be found at the end of this chapter. Application of Entity-Relationship model concepts Do the following review questions Review Questions 1 What is an entity? A discussion on this review question can be found at the end of this chapter. Review Questions 2 What is an occurrence of an entity? A discussion on this review question can be found at the end of this chapter. Review Questions 3 What is an attribute? A discussion on this review question can be found at the end of this chapter. Review Questions 4 What is a primary key? A discussion on this review question can be found at the end of this chapter. Review Questions 5 What is a relationship? A discussion on this review question can be found at the end of this chapter. Review Questions 6 How do we refer to a particular occurrence of an entity? A discussion on this review question can be found at the end of this chapter. Review Questions 7 What is meant by the degree of a relationship between two entities? A discussion on this review question can be found at the end of this chapter. Review Questions 8 What is meant by the optionality of a relationship between two entities? A discussion on this review question can be found at the end of this chapter. Review Questions 9 What is meant by cardinality? A discussion on this review question can be found at the end of this chapter. Review Questions 10 What is the degree of the TEACHER-MODULE relationship? Write 2 sentences, one to describe each direction of the relationship. 17

18 A discussion on this review question can be found at the end of this chapter. Review Questions 11 What is the degree of the TEACHER-MODULE relationship illustrated in the previous question? A discussion on this review question can be found at the end of this chapter. Review Questions 12 What does the dotted line indicate for the CUSTOMER half of the CUSTOMER-ORDER relationship below? A discussion on this review question can be found at the end of this chapter. Review Questions 13 What would be an acceptable alternative notation for the optional relationship between CUSTOM- ER and ORDER in the ERD of the previous question? A discussion on this review question can be found at the end of this chapter. Review Questions 14 Simplify this many-to-many relationship with an intersection entity. A discussion on this review question can be found at the end of this chapter. 18

19 How to Make Entity Relationship Models Introduction to inferring ER models from text descriptions To produce a logical data structure for a system, the description of the requirements (we use case studies) must be analysed and represented using the components we have just described. The key to the production of models, all models not just logical data structures, is to realise that it must be repeated, occasionally a lot of times, before a full, satisfactory model can be reached. Thus, the important thing is to make a start and then use the first attempt as a basis for repeated improvements. The process can be divided into steps. Each step is illustrated using the following Estate Agent example case study: The Estate Agent case study Clients wishing to put their property on the market visit the estate agent, who will take details of their house, flat or bungalow and enter them on a card which is filed according to the area, price range and type of property. Potential buyers complete a similar type of card which is filed by buyer name in an A4 binder. Weekly, the estate agent matches the potential buyer requirements with the available properties and sends them the details of selected properties. When a sale is completed, the buyer confirms that the contracts have been exchanged, client details are removed from the property file, and an invoice is sent to the client. The client receives the top copy of a three part set, with the other two copies being filed. On receipt of the payment the invoice copies are stamped and archived. Invoices are checked on a monthly basis and for those accounts not settled within two months a reminder (the third copy of the invoice) is sent to the client. Note It is possible to create entity relationship models via data normalization techniques used in database design. This is appropriate to smaller scale systems but for large scale systems this can easily escalate into an unmanageable task. The approach introduced in this unit imposes structure from the beginning and so allows a steady construction of the model from the ground up. Those who have done database design may wish to use normalization but you are recommended to practice the staged process following and treat normalisation as an additional skill. The stages of the process for inferring data models from textual descriptions can be summarised as follows: Stage 1: Identify Entities Stage 2: List entity attributes and identify primary keys Stage 3: Identify relationships Stage 4: Remove many-to-many relationships Repeat stages 1 4 Stage 5: Validation Stage 1: Identify entities The first stage in producing a logical data structure is to identify the main entities that will make up 19

20 the system. Usually there are one or two obvious entities which form the basis of the system. For instance in a timetabling system, STUDENT, MODULE and TEACHER would be obvious entities. Other entities can be harder to spot. One trick is to look for each noun in the case study and consider whether or not the noun is a likely entity. Good choices of entities would be ones which are obviously part of the system, not external to the system. Also an entity must be a type of thing, an answer to the question, What type of thing is this?. Care must be taken though as some nouns may be better as attributes. In the Estate Agent case study, the obvious entities are CLIENT (i.e. seller of a property), PROP- ERTY and BUYER. Another entity distinct from BUYER might be POTENTIAL BUYER so we shall add this entity to the list for now. Other nouns are market and estate agent in the first sentence. Market is the housing market and is external to the estate agent system because we are not required to store everything on the housing market just the properties we are interested in. Estate agent is the system itself so this cannot be part of the system. Also in the first sentence are house, flat etc but these are obviously types of property so that is covered by the PROPERTY entity. Card is another word but this is simply a means of storage. The model is independent of how things are stored. As a result there are never entities on the model like Card, File, Filing Cabinet, Tape or Archive. We are interested in the types of thing stored not how they are stored. The few entities identified so far are enough to make a start. Likely entities identified for the model are: CLIENT PROPERTY BUYER POTENTIAL BUYER The Job-Finder case study for exercises The following is a second case study, which will be used for the exercises in this section of the unit. The Job-Finder case study Job-Finder Ltd. is an agency which specialises in placing temporary secretaries into various companies in the City of London. Secretaries apply to register with the Job-Finder for temporary work either by sending their CV or filling in a Job-Finder application form. Secretaries whose applications have been successful are interviewed by one of the agency s senior officers to decide which category they should be allocated to. There are four main categories of secretarial work which require different skills. Secretaries registrations are suspended by Job-Finder if they request so, or if they have not been placed with a company for six months. Companies looking for temporary secretaries make their bookings with Job-Finder giving the secretarial skills they require. Job-Finder allocates each booking to one or more of the available secretaries who have the required skills. Job-Finder calculates the charges for companies bookings at different rates according to their volume of bookings and how long in advance they make the booking. Secretaries get paid by the Job-Finder every Friday, also at different rates according to their category and experience. In order to identify the main entities from the Job-Finder case study, we can look at the nouns in the above descriptions. They have been bold-faced in the following paragraphs. The Job-Finder Case Study Job-Finder Ltd. is an agency which specialises in placing temporary secretaries into various 20

21 companies in the City of London. Secretaries apply to register with the Job-Finder for temporary work either by sending their CV or filling in a Job-Finder application form. Secretaries whose applications have been successful are interviewed by one of the agency s senior officers to decide which category they should be allocated to. There are four main categories of secretarial work which require different skills. Secretaries registrations are suspended by Job-Finder if they request so, or if they have not been placed with a company for six months. Companies looking for temporary secretaries make their bookings with Job-Finder giving the secretarial skills they require. Job-Finder allocates each booking to one or more of the available secretaries who have the required skills. Job-Finder calculates the charges for companies bookings at different rates according to their volume of bookings and how long in advance they make the booking. Secretaries get paid by Job-Finder every Friday, also at different rates according to their category and experience. Job-Finder and agency refer to the whole system, and are therefore rejected as entities to be modelled. temporary secretaries refers to a category of people, so an entity SECRETARY seems a good idea company and companies refers to a category of companies, so an entity COMPANY seems a good idea CV and application form refer to the storage of data, and are therefore not modelled category refers to a category of temps, so an entity CATEGORY seems a good idea skills refers to a category of skill, so an entity SKILL seems a good idea registrations refers to a category of registrations, so an entity REGISTRATION seems a good idea booking refers to a category of booking, so an entity BOOKING seems a good idea charges is a calculated attribute and therefore not modelled experience looks like it should be an attribute rates seems to be a calculated figure so will neither be an entity nor an attribute Therefore the following entities have been identified at this stage: SECRETARY COMPANY CATEGORY KILL REGISTRATION BOOKING Stage 2: List entity attributes and identify primary keys Each entity has a list of attributes, the details that are needed by the system for recording each entity occurrence. There are often obvious ones. The entity PROPERTY must have the attributes Area, Price Range and Type as these are listed in the first sentence! 21

22 Other attributes may require some thought. Again nouns in the case study may be either attributes or entities. If the noun obviously belongs as part of something, like the price of something is a part of that thing then it is a good candidate for an attribute. Many attributes are not explicitly listed and must be identified by thinking about what the system does. If the system must send letters or goods to a CLIENT then you need the CLIENT s address, name and possibly telephone number. This is certainly the case in the CLIENT entity in the estate agent system and also the BUYER. Also, consider the primary key for each entity. A common technique is to give everything a unique number if not obvious, single attribute primary key already exists (such as STUDENT or STAFF NUMBER). Examples for the Estate Agent case study might be Seller Num, Buyer Num and Property Num. As the attributes do not appear on the diagram, a full and complete list is not necessary but an idea of the main attributes of each entity helps as it provides a focus for what that entity is. The following table summarises the main attributes of our entities so far (with primary keys underlined as usual). CLIENT Customer Num Name Address BUYERS Buyer Num Name Address PROPERTY Property Num Address Area Price Type Details Date of Offer Date of Sale POTENTIAL BUYER Potential Buyer Num Name 22

23 Address Type of Property Price Range Desired Area Exercise 12 For the Job-Finder case study identify the attributes and primary key for the SECRETARY entity. A discussion of this exercise can be found at the end of this chapter. Stage 3: Identify relationships The easiest way to determine the relationships is to work through all the entities and consider each pair of entities in turn. By referring back to the case study, it should be clear whether or not entities are directly related (in which case draw a line) or only related through another entity (in which case do not draw a line). It is at this point the drawing starts. Put down on the paper boxes for two of the main entities identified. With estate agent system, this would be the CLIENT and the PROPERTY. The relationship is obviously, a CLIENT offers a PROPERTY and a PROPERTY is owned by a CLIENT. Notice that there are two sentences in this relationship, for each direction of the relationship. Consider relationship degree Next consider the degree. Each CLIENT offers one or more PROPERTies and each PROPERTY is owned by only one CLIENT (it cannot be owned by many CLIENTs). Consider relationship optionality (participation) Finally consider the optionality. As a CLIENT only becomes a CLIENT when a PROPERTY is offered then each CLIENT must offer one or more PROPERTies. Similarly, a PROPERTY must belong to someone so each PROPERTY must be owned by (only) one CLIENT. Draw the entities and relationships The first attempt at the model looks like: Similarly work through each pair. Suppose the next is POTENTIAL BUYER and SELLER. There is no direct relationship here. A POTENTIAL BUYER may consider a PROPERTY owned by a CLI- ENT but there is no other relationship except through the PROPERTY. Each POTENTIAL BUYER may consider one or more PROPERTies (there is no guarantee that there will be any suitable PROPERTies for a POTENTIAL BUYER but there could be a number). Each PROPERTY may be matched with one or more POTENTIAL BUYERs (there is no guarantee that a PROPERTY has any POTENTIAL BUYERs or there may be many). 23

24 BUYER must buy one or more PROPERTies. Each PROPERTY may be bought by only one BUY- ER. POTENTIAL BUYERs become BUYERs if they buy a PROPERTY that they have considered. But this relationship is over time and this is hard to represent on entity relationship diagrams. So this relationship is left out and without any loss as there is still a link from POTENTIAL BUYER to BUY- ER via the PROPERTY bought. Thus, the diagram so far is: Exercise 13 For the Job-Finder case study identify, consider the degree and optionality, and name (in both directions) the relationship between the SECRETARY and CATEGORY entities. Then draw the ERD for these 2 entities and their relationship. A discussion of this exercise can be found at the end of this chapter. Stage 4: Remove many-to-many relationships This is the routine replacement of any many-to-many relationships which may be on the diagram so far. We need to define an intersection entity (and two new one-to-many) to replace each manyto-many relationship. We must try to choose a sensible name and if possible use it to add functionality. 24

25 In the Estate Agent system, the only many to many is between POTENTIAL BUYER and PROP- ERTY. Thinking about estate agents and what they do, a sensible intersection entity might be a VIEWING. This is the process of a single POTENTIAL BUYER going to see a PROPERTY. The VIEWING entity can then have the attributes of the time and date of the VIEWING so also has added some useful functionality. The diagram now looks like: Repeat stages 1 4 Having considered all the relationships between all the entities, the whole procedure is repeated. Using the model so far, try to see if all the data is present to achieve all the tasks described. In re-reading the case study, it is clear that invoicing is necessary but there is no obvious place in the model where invoices could be stored. Now INVOICE could be an attribute (it is a noun) of CLI- ENT but there are copies and also multiple INVOICEs may be sent. Thus, an INVOICE should be a separate entity. Now consider the attributes of the new entity INVOICE. Amount of invoice, date of issue are the main ones though others would be sensible. What relationships are there between INVOICE and other entities? By considering all pairs it is clear that an INVOICE is sent to a CLIENT but only if a PROPERTY is sold. Also, a CLIENT may receive many INVOICEs even on only one Property. So the relationship is: one CLIENT may receive one or more INVOICEs one INVOICE must be sent to only one CLIENT It is unclear from the case study whether an INVOICE is for a particular PROPERTY or is a general INVOICE on the Client CLIENT. We assume the latter but for a real system, the analyst would go 25

26 to the estate agent and find out more about invoices. We now do the same thing again. Are there any more entities? In the case study, sale is mentioned. This could be an entity but reading about it, a sale simply seems to be some external event and nothing is stored on the system about a sale. One last read of the case study suggests that all the given functionality can be managed by the current model. It is now time to stop repeating stages 1 4. The final version is therefore: Stage 5: Validation In the development process, the analyst may be engrossed in producing the models and not notice minor mistakes. Thus, when a final version of the model has been reached, it is worth standing back from the model and checking it over in a routine way just to see that there are no glaring errors. The model can be checked by answering some questions. Is there any repetition of data? There should be no repetition of the same data either within an entity or as attributes of different entities. Are all the attributes and entities relevant to the system? Do any of the attributes depend on other data in the system? There should be no dependencies. For example, it may be tempting for the CLIENT entity to have an attribute which is the number of PROPERTies that the CLIENT is offering for sale. This is unnecessary as each PROPERTY is associated with the offering CLIENT and so this number can be calculated. Have all many-to-many relationships been broken down? Are the one to one relationships correct? It may be possible to merge two entities or even make one entity an attribute of the other. For each one-to-many relationship does the entity at the many end have as a foreign key the primary key of the entity at the one end (occurrences of two entities can only be related if there is a foreign key involved) 26

27 The final question leads us to the following, complete set of attributes for the Estate Agent model. In the table we are following the SELECT-Enterprise convention of indicating foreign keys with an asterisk * symbol. CLIENT Customer Num Name Address BUYERS Buyer Num Name Address PROPERTY Property Num Address Area Price Type Details Date of Offer Date of Sale *Buyer Num * Customer Num POTENTIAL BUYER Potential Buyer Num Name Address Type of Property Price Range Desired Area INVOICE 27

28 Invoice Num *Customer Num Date sent VIEWING *Property Num *Potential Buyer Num Date Time Creating ERDs using the SELECT-Enterprise CASE tool The SELECT-Enterprise CASE tool In previous units you will have learnt how to create projects, data flow diagrams and how to add items to data flow diagrams. To create ERDs in SELECT you will need to learn about SELECT s Storage Class category of diagram. You will also learn about SELECT s data dictionary, and how this can be explicitly used to help maintain the logical data integrity of your diagrams. Having worked through the remainder of this unit, and the associated activities you will be in a position to create your own ERDs using the SELECT-Enterprise software tool. Overview of using the SELECT system A note on terminology n the rest of this unit the term SELECT will be used to refer to the SELECT-Enterprise software package. The SELECT CASE tool uses terminology for the implementation of relational databases rather than the conceptual terminology for logical models of data entities and relationships. There is no need for concern, since the diagram notation provided by SELECT is just the same as for the ERDs introduced in this unit. However, you may find it useful to refer to the following table when wishing to identify the terminology used in SELECT for ERD concepts. ERD Term Entity Relationship Attribute Entity-relationship Diagram SELECT 'Storage Class' Term Table Relationship Column Storage Class Diagram A note of caution on copying and moving SELECT files As with all work with SELECT, you must use the Project Backup and Project Restore menu choices when running SELECT if you wish to copy your SELECT files from one computer to an- 28

29 other. Note You are likely to encounter projects, and possibly corrupt and lose projects if you attempt to copy/ move files directly using the Windows explorer. Although this may seem to be a limitation to the usability of SELECT, in fact the problem is a result of the sophisticated project file management features of SELECT, which allows this CASE tool to be used by many different people working on a single project on different computers. While these features of SELECT are not explored in this unit you need to be aware of the consequences of these features and the importance of using the backup and restore project menu choices. Directory for project files Projects You will need to store all your project files into a specified directory. Although a directory can be created after having started SELECT, in the computer-based activities for this unit you will be asked to create a directory for your project files before starting SELECT. The reason this approach is adopted is so that a new directory is not created by SELECT due to a spelling or file path error when creating a new project having an existing directory means that this problem can be avoided using a directory browse dialog and the correct directory being chosen from a list rather than typed in. You will see later in this unit the same advantage, of creating an object first (i.e. a entity-table in SELECTs data dictionary) and then choosing this existing object when constructing ERDs once again problems of new (erroneous) entity-tables being created due to spelling mistakes are avoided. As with all work in SELECT you will need to create a new project before being able to create a diagram file. You may wish to refer back to units 3 and 4 to recap the creation and naming of projects. Storage Class Diagrams As mentioned above, SELECT being an object-oriented CASE tool rather than a data-oriented CASE tool uses a different (but equivalent) terminology for the construction of ERDs. SELECT provides facilities for many different kinds of information system diagrams, of which the database implementation Storage Class Diagram category is the one based on the principles of Entity- Relationship modelling. Note CASE tools and methodologies have different perspectives on the role of data in information systems, and some tools will focus on modelling while others focus on design for implementation. It is usual to find some terminological differences between the theoretical ER modelling concepts presented in this unit, and a particular information systems tool or method. The Data Dictionary A data dictionary is a definition of all important data items and data types for an information system. In many modern, large-scale systems the data dictionary is a central and very important information resource for the project development team. In SELECT the data dictionary can store the details of each table (entity), relationship, column (attribute), and attribute data type in the logical data structure(s). The level of detail entered into the data dictionary is up to the SELECT users for example it is possible to create a diagram with tables and relationships but not to define the table key columns or column data types. Also it is possible to create the logical data structure diagrams without explicitly working with the data dictionary, however each table and relationship added to a diagram is also added to the data dictionary automatically. 29

30 An ERD created using SELECT Consider the following ERD for a library system: This diagram, created in SELECT, illustrates the following diagram features: Two kinds of diagram element: tables and relationships The tables have been named The relationships have been named (SELECT only gives one name to each relationship, from the parent table the table from which the relationship was started) The degree of relationships is either one-to-one or one-to-many (SELECT does not permit many-to-many relationships) The optionality of relationships (both mandatory and optional) In the following sections of this unit, are number of actions with SELECT will first be described, then you will be asked to complete a set of activities to try out what has been described. Creating a project We shall assume the following directory has been created on the computer: C:\UNIT_05\LIB_01\ We need to create a project in which to create our diagram files. This is achieved by following these steps: Action: We start SELECT Result: The following, empty SELECT screen is displayed 30

31 Action: Project New... (i.e. choose New from the Project menu) Result: We are presented with an empty Project Details dialog window: Action: We enter the project name ER Diagram 1 Action: We click the Browse button and then select the project directory (C:\UNIT_05\LIB_01\) we created before starting SELECT Result: Action: We click the Create button Result: SELECT creates some default project files in our project directory 31

32 Result: After a second or two (depending on the speed of your computer) SELECT will display the Project Created ok dialog window: Action: We click the OK button to acknowledge we know the project has been successfully created Result: We now have a new, empty project, in which we can create an ERD diagram. The SELECT window looks something like the following: Exercise 14 If you type in a path to a directory that does not exist in the Project Details dialog window, what do you think would happen? A discussion of this exercise can be found at the end of this chapter. Exercise 15 What files does SELECT create when a new project is created? A discussion of this exercise can be found at the end of this chapter. Creating a new Storage Class Diagram file SELECT uses the term Storage Class Diagram to refer to diagrams representing the implementation of ERDs i.e. database tables, relationships and table column details. Action: (we will assume a new project has been created) Result: We have a new, empty project, in which we can create an ERD. The SELECT window looks as follows: 32

33 Action: We create a new diagram file either by choosing the File New... menu item, or by clicking the shortcut button Result: We are presented with the Create New Diagram dialog window: Action: We change the type of diagram to Storage Class Diagram and enter a filename for our library ERD file lib_erd Result: Action: We click the Create button Result: We now have a new, empty Storage Class Diagram file, in which we can create an ERD diagram. The SELECT blank diagram window looks something like the following: 33

34 Opening an existing Storage Class Diagram We will now examine how to open an existing diagram file, and add tables and relationships to the diagram. Action: We will open our empty diagram file lib_erd in the project library by either choosing the menu item File Open... or by clicking the shortcut button Result: SELECT presents the Diagram Selector dialog window: Note Note: If SELECT did not have the library project open already, we could switch to this project by clicking the Project button and selecting the library project from the directory C:\UNIT_05\LIB_01 Action: From this dialog we select and open the diagram file lib_erd.dat and click the Open button. (since this is the only diagram we have created for our library project it is the only diagram we can open anyway!) 34

35 Result: SELECT presents the opened, empty Storage Class Diagram we created earlier: Adding a table to a Storage Class Diagram We will now examine how to add a table to a diagram. Action: (we will assume we have started SELECT and opened the lib_erd.dat Storage Class Diagram file) Result: SELECT presents the opened, empty Storage Class Diagram we created earlier: Action: With the mouse pointer somewhere in the white diagram background area we RIGHT-click the mouse to display the diagram popup menu. Result: SELECT displays a popup menu with the following items: Table Free Format Text Free Format Box All Tables All Tables/Relationships All Relationships Action: We choose Table from this menu 35

36 Result: SELECT displays the table Enter Name dialog: Action: We enter the Table name LIBRARY ITEM Result: The table Enter Name dialog looks as follows: Action: We enter the Table name LIBRARY ITEM and click the Ok button Result: We have now added a named table to our diagram. SELECT displays a LIBRARY ITEM table object to the diagram: Note Each table is in a round-corned rectangle. The upper part of this rectangle contains the table name, the lower part of the rectangle (empty in this example) is where an the column (attribute) list is displayed. Adding a relationship between tables to a Storage Class Diagram We will now examine how to add a relationship between two tables on a diagram. Our aim is to create a relationship between parent entity (table) LIBRARY ITEM and entity (table) LOAN ITEM. 36

37 Action: (we assume there is an open Storage Class Diagram containing two unrelated tables) Result: The SELECT window looks something like the following: Action: We select the parent table of our relationship first. We do this by LEFT clicking the mouse once over the LIBRARY ITEM table. Result: SELECT shows that table LIBRARY ITEM is selected by displaying control boxes around the item: Action: We display the table popup menu for the selected object (table) by RIGHT clicking the mouse once. Result: We display the table popup menu for the selected object (table) by RIGHT clicking the mouse once. Edit... Add > (Links >) Usage... Delete Note You can combine both the above select and popup menu actions by simply moving the mouse pointer over an object and then RIGHT clicking the mouse. 37

38 Action: We choose Add > Table from the popup menu Result: SELECT creates a rubber band relationship from parent table LIBRARY ITEM to the end of the mouse pointer at this point in time the relationship has not yet been assigned a destination table to relate LIBRARY ITEM to. The screen will look something like the following: Action: We select table LOAN ITEM as the destination for our relationship by single clicking the LEFT mouse button over this table object. Result: SELECT creates (perhaps after a second or two delay) a one-to-many relationship from LIBRARY ITEM to LOAN ITEM. We have now succeeded in creating an unnamed relationship between two tables. The screen will look something like the following: Note The defaults of SELECT are to initially create an unnamed, one-to-many relationship with mandatory optionality. In the next section we shall examine how to name a relationship, and to change the degree and optionality. Note SELECT will beep at you if you attempt to place a relationship into the column (lower part) of a table rectangle. To successfully create a relationship you must click the mouse into the upper (table name) part of the table s round-cornered rectangle on the diagram. Editing the properties of relationship diagram object We shall investigate how to name a relationship, and how to set the degree and optionality properties of relationship diagram objects. 38

39 Our aim is to name the relationship between LIBRARY ITEM and LOAN ITEM as may be borrowed as, and to set this relationship to be optional. Action: (we assume there is an open Storage Class Diagram containing the two related tables LIBRARY ITEM and LOAN ITEM ) Result: The SELECT window looks something like the following: Action: We request the quick edit of the relationship by double clicking the relationship line (or crow s foot) with the LEFT mouse button Result: The SELECT Relationship editor dialog box is displayed: Note We could have achieved the same effect by selecting the relationship object (LEFT click) and then choosing Edit... from the object popup menu (RIGHT click). Action: We can now change the name of the relationship from the meaningless numeric default (in our example it is Rel268 the number is just one chosen by the system to distinguish unnamed relationships from each other ) to the name may be borrowed as Result: The SELECT Relationship editor dialog box looks as follows: 39

40 Action: We can now set the optionality of the relationship to true by checking the Parent Optional check box Result: The SELECT Relationship editor dialog box looks as follows: Note We could have set the degree of the relationship to one-to-one, had we so wished, by checking the one-to-one checkbox. Action: Having completed our changes we click the Ok button Result: We have now successfully changed the properties of the relationship, and can see the named, optional relationship on the diagram: 40

41 Deleting diagram objects To delete an item from a diagram, select the item (single click LEFT mouse button) and press the DEL key (or choose Delete from the popup menu from a RIGHT button click). You will then be shown the following delete question dialog: (where the name and type of item will depend on which object you selected in this example the table LIBRARY ITEM was selected for deletion). To delete they item click the Yes button, to cancel your delete request click the No button. Note When an object is deleted from a diagram, it is no longer displayed but may still be in SELECT s data dictionary. To delete a relationship you may need to delete from the diagram the table that is the parent of the relationship, and then redisplay this table. Simply deleting the relationship from the diagram may still leave the relationship recorded in the data dictionary... Adding columns and prime keys to tables We shall now investigate how to add columns (attributes) to tables in a Storage Class Diagram, and how to specify which columns (attributes) comprise the primary key for a table. SELECT will attempt to maintain the logical data integrity of your diagrams when you create relationships between tables that have primary key columns defined i.e. SELECT will automatically copy the primary key columns of the parent of a relationship as foreign key columns in the recipient of a relationship (if such columns to not exist, they are created and made foreign key columns). For this reason, you may find it easiest to create tables and their primary key attributes first, and then create relationships between the tables. In this example we shall first enter all the attributes for the BORROWER table, then create a relationship to LOAN ITEM (which will copy over the primary key columns of BORROWER to become foreign key columns of LOAN ITEM), then complete the attribute list for LOAN ITEM. For the purposes of this example the attributes for the tables are: 41

42 BORROWER Borrower ID Borrower Name Borrower Address Telephone number Age LOAN ITEM Catalogue number Copy number Borrower ID Date borrowed Date to be returned Note Sometimes the diagram displayed is a bit out of touch with the actual columns for a table. One trick to get SELECT to update the displayed columns is to make one of the incorrectly displayed columns a primary key, and then back to a non-primary key. When you finish editing the table you will find that the columns displayed on the diagram are up to date again... Action: (we assume there is an open Storage Class Diagram containing the two unrelated tables BORROWER and LOAN ITEM ) Result: The SELECT window looks something like the following: Action: We double click the BORROWER table to quick edit its properties Result: SELECT displays the BORROWER Table Editor dialog: 42

43 Action: To add the column Borrower ID we enter this column name in the Add text box and press the <RETURN> key. Result: The BORROWER Table Editor dialog looks as follows 43

44 Note The default for a newly created column is not to be part of the prime key, not to be unique, and to allow null values.the n by the column indicates it allows null values. Action: We shall now set this column to be BORROWER table s primary key by checking the prime key check box Result: The BORROWER Table Editor dialog looks as follows, notice the p by the column, indicating a prime key column, and the automatic removal of the n (i.e. obviously, null values are not permitted for primary key columns): 44

45 Action: We add a new column Borrower Name by typing this column name in the Add text box (in this case replacing the Borrower ID text in this text box) and pressing the <RETURN> key Result: The BORROWER Table Editor dialog shows a new column, Borrower Name, in the list of columns. Once again with the default of null values, not unique and not a prime key column: 45

46 Action: We click the Ok button, to see the columns displayed in the diagram Result: SELECT shows the attributes (underlining the prime key column) in the diagram as follows: Action: We double click the BORROWER table again, add the remaining columns and press <RETURN> Result: SELECT shows all the BORROWER attributes in the diagram as follows: 46

47 Action: We create a relationship from BORROWER (the parent of the relationship) to LOAN ITEM Result: SELECT shows the relationship as follows: Action: We inspect the LOAN ITEM table object by double clicking Result: SELECT shows the LOAN ITEM Table Editor as follows, notice that SELECT has automatically copied over the primary key column from BORROWER since LOAN ITEM must have this column as a foreign key if the tables are to maintain logical integrity with the created relationship and columns: 47

48 Action: We make column Borrower ID a primary key column, and add the other primary key columns and non-key columns Result: The LOAN ITEM Table Editor should look as follows: 48

49 Note We used the Ordering... button to move Catalogue number and Copy number above Borrower ID in the list of columns. Logically the ordering of columns on the diagram does not matter, but this facility is available to improve presentation and readability if desired. Action: We click the Ok button to return to the diagram Result: The diagram should look as follows, showing the prime key columns and non-key columns for each table: SELECT Reference: Viewing 49

50 Activities You cannot change the size of a symbol; SELECT scales all symbols to match their contents. You can, however, zoom in or out using the commands on the View menu. This changes the scaling of the whole diagram. Note Or you can use the shortcut buttons (see a later Reference section) For speed, Enterprise does not redraw the whole diagram every time you change something. Eventually it will start to look scruffy. The Refresh command on the View menu forces a complete redraw. If your ERD becomes very complex, you can hide all columns for ease of viewing the overall tables and relationships. From the View menu you can choose View Options... to set whether prime key columns are underlined, and whether foreign key columns are marked with an asterisk *. Activity 1 - Adding entities to an ERD in SELECT You are to produce an ERD and attribute lists for the Estate Agent case study examined in this unit. Create a directory for the project files, for example something like: C:\MIT\UNIT_05\estate Create a new project called Estate Agent, and a new Storage Class Diagram file called est.dat. Now add tables for each of the entities in the Estate Agent final ERD below: A discussion on this activity can be found at the end of this chapter. Activity 2 - Entering the attributes (include keys) for the entities Edit each table and add the primary keys and other columns (attributes) from the final Estate Agents list below: CLIENT Customer Num Name 50

51 Address BUYERS Buyer Num Name Address PROPERTY Property Num Address Area Price Type Details Date of Offer Date of Sale *Buyer Num * Customer Num POTENTIAL BUYER Potential Buyer Num Name Address Type of Property Price Range Desired Area INVOICE Invoice Num *Customer Num Date sent VIEWING 51

52 *Property Num *Potential Buyer Num Date Time A discussion on this activity can be found at the end of this chapter. Activity 3 - Adding the relationships to the diagram You should now add the relationships to the diagram (this is easier when columns are not displayed), so that your diagram matches the one from Activity 1 (given the SELECT notational differences). (Hint: Use Free Format Text to add the name of the second direction for each relationship). You diagram should end up looking similar to the following: A discussion on this activity can be found at the end of this chapter. Answers and Discussions Solution to Exercise 1 ER modelling is a data oriented approach to systems analysis. Solution to Exercise 2 The E stands for Entity, the R stands for Relationship and the D stands for Diagram. 52

53 Solution to Exercise 3 The L stands for Logical, the D stands for Data and the S stands for Structure. Solution to Exercise 4 There are 3 entities (i.e. three named rectangles): CUSTOMER, ORDER and SHOPPING TROLLY ITEM. Solution to Exercise 5 There are many different kinds of bank loan. Examples you have come up with might include the following: overdraft mortgage flexible payment loan fixed payment loan car loan home improvement loan Solution to Exercise 6 The single attribute primary key entities are: CUSTOMER, STUDENT and PRODUCT. The composite primary key entities are:staff MEMBER, LIBRARY ITEM, MODULE REGIS- TRATION. The primary key attribute(s) for each entity are those that are underline, i.e.: CUSTOMER: Customer number STUDENT: Student number PRODUCT: Part number STAFF MEMBER: First name, Surname, Postal code LIBRARY ITEM: Catalogue number, Copy number MODULE REGISTRATION: Student number, Module code, Semester, Year Solution to Exercise 7 The reason is the same in each case, that no single attribute is sufficient to uniquely identify one particular occurrence of the entity. STAFF MEMBER: There might be two staff members with the same first, and even the same first and surnames. However, the analyse decided that is it not reasonable for two staff members to have the same name and live at the same address LIBRARY ITEM: There are often 2 or more copies of the same book or recording in a library, 53

54 so the Catalogue Number alone is not sufficient to uniquely identify a particular library item occurrence, however with the copy number as well this is sufficient MODULE REGISTRATION: A student might take a module more than once, and a module can run in the same semester in different years, so all 4 attributes are required to uniquely identify which module and when the module was taken Solution to Exercise 8 This is a one-to-many relationship from SPEAKER to POEM. We can tell this, since there is a single line at the SPEAKER end of the relationship, and a crow s foot at the POEM end of the relationship. The two directions of the relationship can be written in sentences as follows: one SPEAKER reads one or more (many) POEMs one POEM is read by only one SPEAKER Solution to Exercise 9 We create an intersection entity, ORDER ITEM seem reasonable. We then create a one-to-many relationship from ORDER to our new entity, and another one-to-many relationship from PRODUCT to our new entity: Solution to Exercise 10 It is possible to have an occurrence of a holiday DESTINATION for a system has no current FLIGHT occurrences, so the relationship is optional in at the DESTINATION end. It should not be possible to have an occurrence of FLIGHT which does not have a related DESTINATION occurrence, so the relationship is mandatory at the FLIGHT end. The ERD should look as follows: You may have used a dashed line instead of the circle at the DESTINATION end. Solution to Exercise 11 Suggested solutions to the summary exercise statements are: 54

55 Entities are the categories of things which are stored in the system Attributes are the types of data actually stored for each entity occurrence Occurrences of an entity are a particular set of attribute values which represent a thing of the type given by the entity Relationships describe how occurrences of the entities relate to each other A relationship corresponds to two sentences one for each direction Relationships can be one-to-one, one-to-many or many-to-many. This is called the degree of the relationship Relationships can be optional or mandatory in either direction. This is called the optionality of the relationship Solution to Exercise 12 We shall examine the nouns again as potential attributes for the SECRETARY entity. There is not obvious primary key, so we shall create a primary key attribute called Secretary Num We are told that each secretary is allocated to a Category (the skills is plural, so is probably a separate entity) A secretary can be active or suspended, so we shall create a Boolean (true/false) Active attribute A secretary is suspended if they have not been placed for 6 months, therefore there needs to be an attribute recording when the secretary was last placed, e.g. Date last placed Secretaries pay is calculated according to category (already an attribute) and experience, so we shall create a Years of experience attribute (the rate of pay is a calculation, so not something to be stored as an attribute) Although not stated explicitly, secretaries are people with first and surnames. Also Job-Finder must be able to contact them, so we should record an address and telephone number (for now we shall assume the address is a single attribute, it could be broken down further into House name/number, Road, Town, City, Region, Country, Post/ZIP code if we wished). Therefore the following entities have been identified at this stage: SECRETARY Secretary Num First name Surname Address Telephone number Years of experience 55

56 Category Active Date last placed Solution to Exercise 13 A SECRETARY is allocated to a CATEGORY, so a CATEGORY has allocated to it SECRETARies. One SECRETARY is allocated to only one CATEGORY (if we doubted this we would consult our clients for clarification). However, one CATEGORY may have allocated to it one or more SEC- RETARies. A SECRETARY must be allocated to a CATEGORY. However, it may be that there exists a CAT- EGORY for which no SECRETARies are currently allocated. We can write the name of the relationship in each direction as: One SECRETARY must be allocated to only one CATEGORY One CATEGORY may have allocated to it one (or more) SECRETARies We can draw the relationship as follows: Solution to Exercise 14 Try it! SELECT will create a new directory with the path you specify (if a valid path). However, if you make a typing mistake, SELECT will not know this, and create your project in a new directory with the spelling mistake in the path, after asking you: For this reason you may wish to always create the directory first, and use the Browse button to specify which directory a new project should be created in. 56

57 Solution to Exercise 15 Use the Windows Explorer to examine the contents of the directory: C:\UNIT_05\LIB_01\ The directory looks as follows on a computer after the above actions had been completed: Solution to Review Question 1 An entity is a category of things about which a system stores data. An example is a CUSTOMER entity for a sales system. Solution to Review Question 2 An occurrence of an entity is a particular thing the system stores information about, so one occurrence of a STUDENT entity might be Fred Smith, Student number , age 32 etc. An occurrence of an entity is recorded by a set of values for the entity attributes (although not every attribute has to have a value). Each occurrence is uniquely identified by the values of the primary key attributes. Solution to Review Question 3 An attribute is the definition of a type of piece of data we wish to store for each occurrence of an entity. For example, an important attribute for each occurrence of a CUSTOMER entity might be the Customer Number or Surname or address. Solution to Review Question 4 The primary key of an entity is the attribute (or set of attributes) that together uniquely identify an occurrence of the entity. A primary key comprised of 2 or more attributes is sometimes referred to as a composite primary key. Sometimes special attributes are created to act as primary keys, such as the Middlesex University Student number, unique for each occurrence of the STUDENT entity 57

58 of the university information system. Other times primary keys are made up of one or more attributes of an entity that together will always uniquely identify an occurrence of the entity for a some systems the combination of First Name, Surname and Postal/ZIP code made be sufficient to uniquely identify each occurrence of a CUSTOMER entity. Solution to Review Question 5 A relationship in an ERD is the modelling of a 'functional dependence' of occurrences from two different entities. You may wish to read more about this term (and a process called 'data normalisation') in database books. For example, in a sales system there might be a CUSTOMER entity and a CREDIT CATEGORY entity each customer occurrence is assigned a particular credit category (which might have attributes like credit limit, interest rate, payment periods etc.). In ER modelling we use a relationship to define the kind of dependency occurrences of each entity have on each other. So for our example, there may be many occurrences of the CUSOMTER entity that refer to one particular credit category (i.e. one particular occurrence of the CREDIT CATEGORY entity). The degree and optionality of relationships can be defined as well. Solution to Review Question 6 The values for the primary key attributes uniquely identify each occurrence of an entity. By stating the primary key attribute value(s) we are refer to a particular occurrence of an entity. For example, by stating a STUDENT number of we are referring to a particular occurrence of the Middlesex University STUDENT entity. Solution to Review Question 7 The term degree (these days) indicates the number of occurrences (one or many) related (functionally dependant) between two tables. A one-to-one relationship indicates that one occurrence of the one entity is related to one occurrence of the related entity. A one-to-many relationship indicates that one occurrence of the one entity can be related to 2 or more occurrences of the related entity. A many-to-many relationship indicates that one occurrence from either entity can be related to 1 or more occurrences of the other. In the past the term degree had a different meaning defining the number of entities involved in a relationship. Most relationships are binary, i.e. they involved a relationship between 2 entities. Relationships involving 3 or more entities can exist, although are usually simplified into 3 or more binary relationships at some stage in the data modelling process it takes 3 binary relationships to approximate a ternary (degree of 3) relationship. In this unit we only consider binary relationships. In such situations where the older meaning of the term degree is used, the term cardinality is used to refer to the number of occurrences (one or many) between the entities of the relationship. Solution to Review Question 8 An entity has an optional relationship with another if the entity can have an occurrence for which there are no related occurrences in the other entity. For example a STUDENT occurrence may not yet be registered for any modules, so there are no related occurrences in the MODULE REGISTRA- TION entity. Solution to Review Question 9 The term cardinality refers to the number of entities related by a single relationship i.e. this previously used term has the same meaning as the term degree today. Solution to Review Question 10 The relationship is a one-to-many relationship from TEACHER to MODULE. The two sentences for each direction of the relationship are: one TEACHER teaches many MODULEs and one 58

59 MODULE is taught by one TEACHER. Solution to Review Question 11 The relationship is between 2 entities, and so is a binary relationship. Solution to Review Question 12 The dotted line indicates that the CUSTOMER entity has optional participation in the relationship i.e. a CUSTOMER occurrence may exist that has no related ORDER occurrences. The other entity (ORDER) has mandatory participation in the relationship, so it is not permissible for an ORDER occurrence to exist without a related CUSTOMER occurrence this makes sense, since one should not have orders in the system which are not related to a customer! Solution to Review Question 13 Optionality of relationships can be indicated by either a dashed line, or by a circle at the optional end of the relationship, such as in the following diagram (and in the SELECT-Enterprise diagrams): Solution to Review Question 14 We create an intersection entity, the name LOAN ITEM seems reasonable. We then create a oneto-many relationship from BORROWER to our new entity, and another one-to-many relationship from LIBRARY ITEM to our new entity: Solution to Activity 1 Remember the different terminology in SELECT: 59

60 Storage Class Diagram Table Column Circle for relationship optionality Entity Relationship Diagram Entity Attribute dashed relationship line Once you have created the directory, project and new Storage Class Diagram file you can add the tables to the diagram in two ways: By RIGHT clicking, choosing Table and entering the name of each table Or by populating the dictionary with table items for each table, then adding via the Browse button on the RIGHT button popup menu Either method is fine. After adding all 6 tables SELECT should look something like the following: Solution to Activity 2 You can edit a table by double (LEFT) clicking the mouse. Attributes are added by entering column names and checking the prime key checkbox as appropriate. For example the screen below shows the attributes of the VIEWING entity being entered: 60

61 After all columns have been entered SELECT may look as follows: If no columns are displayed you can switch this option on and off view the View View Options menu choice. Likewise, from the same options you can choose whether to see primary key columns underlines or 61