This document provides an overview of entity-relationship modeling as a first step for designing a relational database. It describes how to model entities, attributes, relationships, and participation constraints. Key aspects covered include using boxes to represent entity types, diamonds for relationship types, and labeling relationships with degrees. The document also discusses handling multi-valued attributes and deciding whether to model concepts as attributes or entity types.

1. Relational Database Lecture 2: Entity-Relationship Modelling

2. Objectives By the end of this lecture you should be able to: Describe how entities, attributes and relationships are used to model data; Decide whether to model a given concept as an entity, attribute or relationship; Determine the degree of a relationship; Produce an entity relationship diagram based on a simple description of a domain.

3. Recap Last lecture we looked at the relational model of data: Information Principle, “ All information in the database must be cast explicitly in terms of values in relations and in no other way ” EF Codd Atomic Attributes Primary keys Foreign keys Referential integrity In this lecture we show how to analyse/model data as a first step to designing a relational database

4. Entity-Relationship Modelling Deciding what data to hold in a database and how to structure it into tables is a design issue. Entity-relationship modelling analyses data requirements in a systematic way to help produce a well-designed database. E-R modelling should always be completed before you implement your database. Everything is modelled in terms of three basic concepts: Entities, Attributes Relationships.

5. Entities and Entity-types An entity is , “ anything about which we want to store data”. We classify entities according to their type: Some entities (eg you and I) are more concrete than others (eg a lecture). Entities may be physical objects, events or abstract (for example ‘degree programme’) Lecture This lecture Lecturer Me Student You Entity-type Entity

6. E-R Diagram In E-R modelling we use a box to represent entity-types: Student Lecture Lecturer

7. Relationships and Relationship-types Entities take part in relationships. We can often identify relationships from verbs or verb phrases. For example you are attending this lecture, I am giving the lecture. As with entities, we classify relationships according to relationship-types: A student attends a lecture; A lecturer gives a lecture.

8. E-R Diagram We name relationship-types and depict them on our diagram as diamonds with lines connecting to the appropriate entity-types: Student Lecture Lecturer E-R depiction of entity-types and their relationship-types gives attends

9. Relationship-type Degree The degree of the relationship-type has to do with the maximum number of relationships of a given type an entity is allowed to take part in. We label relationships-types as 1:1, 1:M or M:N. The relationship-type ‘ currently married to’ between one person and another in a law-abiding, monogomous society is 1:1. Each person is allowed to be ‘ currently married’ to at most one person. The relationship-type ‘ gives’ between lecturer and lecture could be 1:M or M:N, depending on circumstances for which our database is to be used. The relationship-type ‘ attends ’ is M:N.

10. E-R Diagram We extend the relationship diagram to include degrees: Student Lecture Lecturer E-R diagram extended to show relationship degrees. gives attends M 1 M N

11. Participation The participation constraint specifies the minimum number of relationships of a given type that an entity may participate in. Principally we are interested in the question, “Does every entity of a some type have to take part in a relationship of a given type?” For example, it might be considered true that: Every lecture has to be given by a lecturer Every lecturer has to give at least one lecture Every lecture has to be attended by at least one student Not every student has to attend a lecture

12. E-R Diagram We extend the relationship diagram to include participation: Student Lecture Lecturer E-R diagram extended to show relationship degrees. gives attends M 1 M N

13. Attributes An attribute is a single-valued property of either an entity-type or a relationship-type. For example, a lecture might have attributes: time, date, length, place. Lecture time date length place

14. Dealing with multi-valued attributes Note that attributes should be single-valued. If some lectures might be relayed to lecture theatres other than the one where the lecturer is physically present, then we would model this: Lecture time date length Lecture theatre Takes place in M N

15. E-R Diagram Student Lecture Lecturer E-R Diagram for student-lecture-lecturer attends gives M N 1 M surname forenames title surname forenames title time date length place Reg_no

16. Attribute or Entity-type? To decide whether a concept be modelled as an attribute or an entity-type: Do we wish to store any information about this concept (other than an identifying name)? Is it single-valued?

17. Promotion from attribute to entity-type I Lecture time date module length

18. Promotion from attribute to entity-type I Lecture time date length Belongs to Module code title credits M 1

19. Promotion from attribute to entity-type I Lecture time date objectives length

20. Promotion from attribute to entity-type I Lecture time date length Addresses Objectives description M N

21. Determining components of an E-R Diagram From a description of the Universe of Discourse (UoD): Underline nouns and noun-phrases These are candidates for entity-types Underline verbs and verb-phrases These are candidates for relationship-types Check each entity- and relationship-type for relevance. Remove any for which there is only one instance.

22. Example UoD “ Each module is identified by a module_code and consists of a number of lectures , tutorials and exercise classes . Students are required to attend lectures and tutorials, but exercise classes are optional. Lectures are given either by a member of staff or (occasionally) a postgraduate student . Modules are specified in terms of a list of learning objectives . Each lecture should address one or more of these objectives .”

23. Summary E-R modelling is a first step towards database design. It is a non-trivial design activity that is intellectually demanding, but should not be overlooked. This lecture has covered only the basics. See Chen’s paper or Elmasri &Nevathe for more details The rules for designing a relational database given an E-R model are straightforward. We shall cover these rules in the next lecture.