Database Systems 4th edition Connolly and Begg Chapter 11 CM2020: Introduction to Database Systems Conceptual Modelling with The Entity Relationship Model Database Systems 4th edition Connolly and Begg Chapter 11 Nirmalie Wiratunga

Aim of Lecture Outline the steps involved in designing a database Explain the first phase: Conceptual Modelling Study a particular conceptual model: Entity Relationship (ER) Model By the end you should be able to Explain what conceptual design is, and how it is used Represent a real-world situation as an ER Model Understand an ER model constructed by someone else This lecture is on Conceptual Modelling, which is the first step in designing a database, before you even think about creating any tables.

Role of Conceptual Modelling within the design process Real-World Organisation / Problem Identify key concepts and data needs Create a conceptual model Conceptual Data Model Logical Data Model Convert model to structures required by database (relational, object-oriented, etc.) This is how conceptual modelling fits into the overall design process. When designing a DB, you start with a real world situation or organisation such as a library or an estate agent, and end up with a database on the disc. This slide shows the steps in between. 1) Identify important concepts: library, books borrowers. How do they relate? 2) Analyse the user’s requirements, so that you’re sure you know what you want the system to do. What queries the system will have to answer, what reports you want it to generate. If you’re doing this job for a paying customer, it’s a good idea to produce an agreed user requirements document, listing the user’s requirements and all the assumptions you’re making about the model - then he can’t turn round at the end and say that the DB doesn’t behave as he intended. Getting to the real world to a conceptual model is in general a difficult problem, and undergraduate students get an entire course on it. In general there isn’t a single right answer; there will usually be many different ways of modelling a given real-world situation, some better than others. It’s also an iterative process; that means that typically you come up with an idea for a model, then discover that it doesn’t quite work, so you have to go back and refine it. For the purposes of this course, we’ll stick to relatively simple examples. Physical Model (via DBMS) Implement using a DBMS (MSA, ORACLE): create tables, add data, constraints, etc.

The Conceptual Data Model Abstract view of situation Identify important entities and relationships between them Library: Books, Members, Carpets Member borrows Book Use human understandable terms, not computer terms Tables, Combo Boxes, Foreign Keys… Implementation independent One form is the Entity Relationship (ER) model Basis for the next step: the logical model Forming the conceptual model is the first stage in designing a database. So, what IS the conceptual model? What does it contain? Easier to illustrate with examples, but basically the conceptual model a high level description of a situation or problem, Estates and physical resources might well might want to keep track of how old the carpets are. What is important depends on the need of the client. Identifying the most important things, and leaving out the less important details.. It mainly includes objects and the relationships between them, and constraints on the objects. For example, in a library, objects might be members and books. Members BORROW books, so that forms a relationship between members and books; and say members can only borrow 6 books at a time, that’s a constraint. It’s important that it’s expressed in the user’s terms, so talk about books and borrowers, not tables and records and combo-boxes.

Simplicity of ER modelling Suppose we wish to record details of staff working on project. Works_on ER diagram Staff Project Tables Staff StaffId Name Title WorksOn Project 1 ∞ 1 StaffId ProjectId ProjectId Name StartDate ∞ The first step according to the approach we teach here is to create an entity relationship model. After all, the final object is to create a relational database, so why not just talk to the customer about what he wants, define your tables, type in the data, take your money and go? For complex problems that’s unlikely to be very successful. In the next couple of slides I’ll try to give a couple of reasons why. ER diagram is simpler. In a more realistic situation, when there are MANY entities in the diagram, ER diagram is a lot easier to follow ER diagrams are simpler than the table representation

Purpose of ER modelling? ER model is simpler and easier to understand Helps discussions with customers and fellow-workers Separates Modelling the real-world problem situation Designing the DB tables for a DBMS (e.g. MSA) Most large organisations will require ER Modelling (Last bit) If you try to create the tables without doing the ER modelling first, then you’re trying to do two things at once. You’re both trying to understand and model the real-world situation, and you’re also trying to fit it into the format required by a relational database. That’s quite hard, and for all but the simplest tasks, you aren’t likely to get very good results. If you do it in TWO steps, you can first of all concentrate on the situation you’re trying to model; then, once you’ve built the model, the second step is to convert the model to tables, and you can concentrate on the particular requirements of a relational database. So, those are two reasons why it’s a good idea to start the design process with ER modelling. If you’re writing a DB for the fish and chip shop down the road, all they’ll care about is that you deliver something that works. However, if you become a professional software engineer, you will almost certainly be required to carry out some form of modelling as part of the database design process, so it’s probably a good idea to learn it while you’re here

Contents Components of an ER model Entity Relationship Entity sets and descriptions Relationship Functional and membership class descriptions Constraints and Assumptions Putting it all together with example ER Models Advance concepts Inheritance Recursion Ternary relationships I’ve given you some simple examples of an ER model. I now want to look at the components of the model in more detail.

Components of an ER Model The ER Model consists of four items: 1. An ER Diagram (using Bachman Notation) - graphical representation of the entities and the relationships between them 2. A formal description of each entity in terms of its attributes and identifiers 3. Descriptions of the meaning of relationships 4. Descriptions of any constraints on the system and of any assumptions made Note: the completion of an ER Model is iterative and unlikely to be successful first time round

Example of a realistic ER diagram Makes Driver Trip Vehicle Incurs Includes Uses Food Processor Expense Maintenance Engineer Qualification Holds Customer Stop Delivers Receives Food Processor Type Has Undergoes Visits Date-obtained Performs Staff Most of the examples in this lecture have been very simple. This slide makes the point that a realistic ER diagram will include LOTS of entities and relationships.

How do you obtain an ER Model ? Given a specification, you need to identify the following concepts: Entities: ‘things’ with physical or conceptual existence - usually nouns Relationships: between entities - usually verbs Attributes: of each entities and sometimes relationships any constraints or assumptions

Identify ER Concepts in a Specification Entity Attribute Relationship Departments control many projects and each department has many employees. Each employee works on only one project at a time. A project’s start date must be before the project’s target completion date. Entities: departments, projects, employees Relationships: control - between departments and projects has - between departments and employees works_on - between employees and projects You may be given a description of a situation and have to come up with a conceptual model. That means you have to identify the entities, relationships, attributes and constraints. Date is a noun, but it doesn’t have any relationships, and it doesn’t have any attributes of it own, so it’s simplest to make start date and end datae attributes of project. The slides is an example of the first steps in going from a textual description to an ER model. Attributes: Start date, completion date for project. NI number, name, address for employee. Constraints: A project’s start date must be before its target completion date.

Contents Components of an ER model Entity Relationship Entity sets and descriptions Relationship Functional and membership class descriptions Constraints and Assumptions Putting it all together with example ER Models Advance concepts Inheritance Recursion Ternary relationships I’ve given you some simple examples of an ER model. I now want to look at the components of the model in more detail.

Entity Definition Entity Set: a collection of similar entities real-world object distinguishable from other objects and described using a common set of attributes. Diagrammatically shown as Entity Set: a collection of similar entities E.g. all employers, all students the set tends to have the same number of attributes must have a primary key entity-name

Entity Examples Delivery database College registration database Drivers Customers Deliveries Invoice College registration database Student Instructor Classroom Course Restaurant database Menu Recipe Ingredient Order Personal Music database ?

Descriptions of entities Properties of entities are called attributes Simple or composite e.g. name (firstname, surname) Identifiers: One or more unique attributes are chosen as an identifier for the entity (a.k.a. primary key) Single or multi-valued e.g. hobbies {cycling,reading,music} Derived e.g. TotalCost (UnitCost * Quantity) Entity description = Entity name + identifier + other attributes Entity Set: the set of entity descriptions Primary Key Two John Browns, or two Harpreet Singhs in the MSc class. Entities in the ER model have quite a lot in common with tables in a database. They have attributes and primary keys, for example. When you come to create your database, each entity will turn into a table. However, an entity is not the same thing as a table!!!

Entity Sets Entity Sets Supervisor Student do NOT include foreign keys at the conceptual modelling stage Supervisor(staffID, name, jobTitle, address) Student(studentID, name, address, staffId*) Other Examples of Entity Sets: Driver(driver#, first-name, surname, address, #points) Exam(module#, student#, grade) In ER model, relationship is indicated by line. Don’t need to use a FK as well – that would be superfluous. Also ER model is meant to be independent of the kind of database you’re going to create. You might be building a network database which doesn’t have foreign keys! Then you’d find you couldn’t do it. In an ER model, the attributes of an entity are properties of that entity alone, NOT properties of any entity which it may be linked to

Contents Components of an ER model Entity Relationship Entity sets and descriptions Relationship Functional and membership class descriptions Constraints and Assumptions Putting it all together with example ER Models Advance concepts Inheritance Recursion Ternary relationships I’ve given you some simple examples of an ER model. I now want to look at the components of the model in more detail.

Relationships An association among entities. Supervisor supervises student Relationships are described in terms of their Functionality Membership Class Attributes supervises Supervisor Student

Relationship: Functionality Each supervisor can supervise many students, but each student has only one supervisor supervises Supervisor Student Functionality answers two questions: Can the supervisor have more than one student? Yes Can the student have more than one supervisor? No So we’re interested in the MAX number of each entity involved: is it 1 or many? DO BACHMAN diagram of lecturer/course Professor heads department. Each department is headed by exactly one professor. DO BACHMAN Now another example...

Functionality Types 1- to -1 1- to many many to -1 many to many Functionality types are based on different mappings between entities

Relationship: Membership Class A supervisor does not have to supervise any students. A student has to have a supervisor. supervises Supervisor Student Supervisor’s participation in supervision is optional Student’s participation in supervision is mandatory The membership class answers two questions: Must the supervisor have at least one student? No Must the student have at least one supervisor? Yes So we’re interested in the MIN number of each entity involved: is it 0 or 1? Where, 0 means optional and 1 means mandatory DO BACHMAN diagram of lecturer/course Professor heads department. Each department is headed by exactly one professor. DO BACHMAN Now another example...

Combining Functionality and Membership A student must have at least one supervisor, and not more than one supervisor supervises Supervisor Student A supervisor may supervise no students, or may supervise many students

Relationship: Example 1 Hamilton Castle School Paul Stevens High School Brian Hill School Walters employ School Teacher Every school must employ atleast one or more Teachers Every teacher must work in at most one school

Relationship: Example 2 Hamilton Castle School Paul Stevens High School Brian Hill School Walters employ School Teacher Every school must employ one or more Teachers Every teacher may work in zero or one school - Paul does not work in any school

Relationship: Example 3 Hamilton Castle School Paul Stevens High School Brian Hill School Walters employ School Teacher Schools can employ many teachers, but some schools have yet to recruit. Some teachers do not work whilst others work in a school.

Relationship: Example 4 Hamilton Castle School Paul Stevens High School Brian Hill School Walters employ School Teacher Schools can employ many teachers, but some schools have yet to recruit All teachers must work in a school.

Description of Relationships supervises Supervisor Student Functionality: one to many, written [1:M] many to many, written [M:N] one to one, written [1:1] Membership class: optional to mandatory, written [o:m] Description of relationship is therefore: Supervises: Supervisor supervises student [1:M] [o:m] Note this is the third component of the model, but it makes sense to include it here along with the discussion of relationships

Description of Relationships with Attributes Assistant works in Lab for many hours per week. hours Assistant Lab works_in Does every assistant have to work in a lab? Does every lab have an assistant. Can one assistant work in several different labs? Description of relationship works_in(hours): assistant works in lab [M:N] [o:m]

Contents Components of an ER model Entity Relationship Entity sets and descriptions Relationship Functional and membership class descriptions Constraints and Assumptions Putting it all together with example ER Models Advance concepts Inheritance Recursion Ternary relationships I’ve given you some simple examples of an ER model. I now want to look at the components of the model in more detail.

Descriptions of Constraints / Assumptions Examples of constraints: #points on driver’s license must be less than 11 pickup_date must be before delivery_date Driver title must be Mr, Mrs or Ms Examples of Assumptions Typically involve assumptions made about a relationship’s membership and/or functionality CONSTRAINTS: These are useful, because when you come to create the DB, they can be represented as validation rules which prevent users from entering invalid data. I’ve now told you everything you need to know about basic ER modelling. There are a few additional features which you can include in your ER diagram

Contents Components of an ER model Entity Relationship Entity sets and descriptions Relationship Functional and membership class descriptions Constraints and Assumptions Putting it all together with example ER Models Advance concepts Inheritance Recursion Ternary relationships I’ve given you some simple examples of an ER model. I now want to look at the components of the model in more detail.

Example ER model: a staff project management system ER diagram supervises Supervisor Student Entity Sets Supervisor(StaffID, Name, JobTitle, Address) Student(StudentID, Name, Address, date_enrolled, completion_date, DOB) Relationships Supervises: Supervisor supervises student [1:M] [o:m] Constraints/Assumptions Student’s date_enrolled must be before completion_date

Example ER model: A library System ER diagram return-date borrows Member Book Entities Book(ISBN, title, author,…) Member(MemberID, name, address, phone#, …) Relationships Borrows(return-date) – members borrow books [1:M][o:o] Constraints and assumptions: A member can borrow up to 6 books at once Each book can be borrowed by at most one member Before explaining the entity relationship model in detail, I’m going to show you a very simple example of one, so that you can see where we’re heading An entity relationship model consists of entities, attributes and relationships. Entities are objects, usually corresponding to nouns in the description A library has books and members. So the objects in our model will be books and members. Attributes are properties of things. Atts for book will be title, author, etc.. Atts for member will be name, address, etc. There is also a relationship between members and books, where members borrow books. We shall also be concerned with what is called the FUNCTIONALITY of relationships. What functionality means in the library example is how many books a member can borrow, here it’s 6, and how many members can borrow one book.

Contents Components of an ER model Entity Relationship Entity sets and descriptions Relationship Functional and membership class descriptions Constraints and Assumptions Putting it all together with example ER Models Advance concepts Inheritance Recursion Ternary relationships I’ve given you some simple examples of an ER model. I now want to look at the components of the model in more detail.

Advanced Concepts of ER diagrams ER Diagram, which is part of the ER Model, can become more complex i.e., we may have the following: Entity Subsets and Supersets Complex Relationships Involuted or Recursive Relationships Ternary Relationships

Entity subsets and supersets Staff makes Driver Trip has Branch performs Engineer Maintenance Branch has many Staff. Engineers perform many maintenance tasks. Drivers make many trips.

Unusual Relationships Recursive manages Employee Ternary works on Project Programmer The manages relationship can be converted into an attribute that is part of the employee entity. Sometimes the relationship needs to be converted into a table itself. Convert works on into an entity Site

Summary ER Modelling A conceptual design technique Is independent of the type of logical model / database you’re going to transform it into Contains entities, attributes, relationships and constraints/assumptions ER Diagram is a graphical representation using the Bachman notation Connolly and Begg Relational Databases uses the Chen notation

More examples of Bachman Notation governs Principal University A principal must govern exactly one university A university can’t have more than one principal, and may have no principal Description: Principal governs university [1:1] [m:o] commands Dark Lord Minion This is recap Right-hand column indicates functionality - maximum number of instances involved in relationship. Extra symbols at the bottom indicate participation constraints - minimum numbers involved in relation. Note how the numbers and the symbols relate - there is some duplication of information. When drawing diagram, you can either attach attributes them to entities, or list them separately below the diagram. Probably better to list them below, so as not to clutter the diagram. The main function of the diagram is to show the relationships between entities; the attributes are just additional details. A dark lord may have no minions, or he may have many minions. A minion must have exactly one Dark Lord Description: Dark Lord commands minion: [1:M] [o:m]

Identify Entities and Attributes Entity Attribute Relationship “We need a database to track the movement of stock items. Each item has a code number and comes from a particular supplier. Each item can be used on one of many platforms. Each platform has a name and location”. Each supplier has an id code, name, address and phone number”. Each location has a latitude, longitude, and sea area name. Lessons from this example: It isn’t always obvious what the entities should be. Occam’s razor is a good rule; don’t create any more entities than you have to.