![Page 1: Monica Farrow EM G30 monica@macs.hw.ac.uk Material on Vision Er 1 F28DM: Database Management Systems The Entity Relationship Model](https://reader037.vdocument.in/reader037/viewer/2022103112/551b2e56550346d41a8b4d01/html5/thumbnails/1.jpg)
Monica Farrow EM [email protected]
Material on Vision
Er 1
F28DM: Database Management Systems
The Entity Relationship Model
![Page 2: Monica Farrow EM G30 monica@macs.hw.ac.uk Material on Vision Er 1 F28DM: Database Management Systems The Entity Relationship Model](https://reader037.vdocument.in/reader037/viewer/2022103112/551b2e56550346d41a8b4d01/html5/thumbnails/2.jpg)
Er 2
Topics today
• Conceptual database design• ER diagrams
• Notation• Definitions• Entities• Relationships• Cardinality constraints• Participation constraints• Limitations (other constraints)• Fan and chasm traps• Extended ER diagram
• Examples – Departmental, Hospital
![Page 3: Monica Farrow EM G30 monica@macs.hw.ac.uk Material on Vision Er 1 F28DM: Database Management Systems The Entity Relationship Model](https://reader037.vdocument.in/reader037/viewer/2022103112/551b2e56550346d41a8b4d01/html5/thumbnails/3.jpg)
Er 3
Database DesignDatabase design goes through several stages.
Physical Database Design
Logical Database Design
Data Analysis, Conceptual Design
Problem
Data Requirements
Conceptual Data Model
Storage structure and File Organisation
Logical Schema
Requirements Analysis
![Page 4: Monica Farrow EM G30 monica@macs.hw.ac.uk Material on Vision Er 1 F28DM: Database Management Systems The Entity Relationship Model](https://reader037.vdocument.in/reader037/viewer/2022103112/551b2e56550346d41a8b4d01/html5/thumbnails/4.jpg)
Er 4
Conceptual Database Design• Process of constructing a model of the data used
in an enterprise, independent of all physical considerations.
• E.g. ER diagram
• Conceptual database design is top-down design as you start by specifying entities (real-world objects) then build up the model by defining new entities, attributes, and relationships.
• The data model is built using the information in the users’ requirements specification.
• The conceptual data model is the source of information for logical design phase.
© Pearson Education Limited 1995, 2005
![Page 5: Monica Farrow EM G30 monica@macs.hw.ac.uk Material on Vision Er 1 F28DM: Database Management Systems The Entity Relationship Model](https://reader037.vdocument.in/reader037/viewer/2022103112/551b2e56550346d41a8b4d01/html5/thumbnails/5.jpg)
Er 5
Conceptual Design with the ER Model
The questions we need to ask are:
1. What are the entities (e.g. objects, individuals) in
the organisation?
2. Which relationships exist among these entities?
3. What information do we want to store about
these entities and relationships?
4. What are the business rules of the organisation?
5. Which integrity constraints do arise from them?
The answers are mostly represented in an Entity
Relationship diagram
![Page 6: Monica Farrow EM G30 monica@macs.hw.ac.uk Material on Vision Er 1 F28DM: Database Management Systems The Entity Relationship Model](https://reader037.vdocument.in/reader037/viewer/2022103112/551b2e56550346d41a8b4d01/html5/thumbnails/6.jpg)
Er 6
ER Diagrams
• There are quite a few different notations for ER diagrams• In year one, we used UML notation• Chen and Crow’s Foot notations are also
commonly used• There are others as well.....
• We’ll look at these 2 notations and some variations as we look at the components of an ER diagram
![Page 7: Monica Farrow EM G30 monica@macs.hw.ac.uk Material on Vision Er 1 F28DM: Database Management Systems The Entity Relationship Model](https://reader037.vdocument.in/reader037/viewer/2022103112/551b2e56550346d41a8b4d01/html5/thumbnails/7.jpg)
Er 7
No RDBMS design decisions!
• At this stage, we are ONLY concerned with modelling entities in the real world, and the connections between them, as we need it for our database requirements
• We are NOT thinking about how to store the data in the tables• So you will see some representations of data
that will have to be changed when converting into tables
• Don’t include foreign keys at this stage
• We COULD use the ER diagram as a basis for an Object Oriented database
![Page 8: Monica Farrow EM G30 monica@macs.hw.ac.uk Material on Vision Er 1 F28DM: Database Management Systems The Entity Relationship Model](https://reader037.vdocument.in/reader037/viewer/2022103112/551b2e56550346d41a8b4d01/html5/thumbnails/8.jpg)
Er 8
UML notation
• In this diagram• 2 Entities (SpyMaster, Spy) are connected by a relationship• One SpyMaster manages at least one and maybe multiple
Spies• One Spy is managed by exactly one master.• A Spy has attributes (name, date of birth etc)• The codeName uniquely identifies the Spy, and is used as a
primary key.
SpycodeName {PK}firstNamedateOfBirthgendermarkamountDue
SpyMaster
mCodeName {PK}contact
1..*
1
manages
![Page 9: Monica Farrow EM G30 monica@macs.hw.ac.uk Material on Vision Er 1 F28DM: Database Management Systems The Entity Relationship Model](https://reader037.vdocument.in/reader037/viewer/2022103112/551b2e56550346d41a8b4d01/html5/thumbnails/9.jpg)
Er 9
Other notations
• This shows the same information as the previous slide, using Chen notation
• Crow’s feet notation is similar to UML notation, with different symbols on the relationships
1SpySpyMaster
mCodeName
contactcodeName
firstName
etc
managesn
![Page 10: Monica Farrow EM G30 monica@macs.hw.ac.uk Material on Vision Er 1 F28DM: Database Management Systems The Entity Relationship Model](https://reader037.vdocument.in/reader037/viewer/2022103112/551b2e56550346d41a8b4d01/html5/thumbnails/10.jpg)
Er 10
Example ER Diagram for a Company database
• A company has several departments. Each department has a unique number and a unique name, and may be based in several locations (e.g. Hillhead, Overton, MillEnd). A department has a manager.
• A department controls various projects. Projects also have a unique ID and name, and several deadlines (e.g. startup, intermediate, final).
• Information required about the employee is a unique ssn (social security number), his name, date of birth, age, gender, salary. We don’t need to know about which employee works at which location.
• An employee works for one department and may work on several projects. The number of hours that they are allocated for each project must be recorded. Most employees are supervised by another employee.
![Page 11: Monica Farrow EM G30 monica@macs.hw.ac.uk Material on Vision Er 1 F28DM: Database Management Systems The Entity Relationship Model](https://reader037.vdocument.in/reader037/viewer/2022103112/551b2e56550346d41a8b4d01/html5/thumbnails/11.jpg)
Er 11
Company ER Diagram
Assumes we only want to know about which depts in which locations, not which employee in which location etc
Departmentdept number {PK}dept name {AK}location [1..5]
Employee
ssn {PK}name first names last namesdate of birthgendersalary/age
1..* 1
works for
1 0..1manages
Projectproj number {PK}project name {AK}
1..*
0..*
controlshours
works on
1
1..*
has
10..*
supervises
0..*
0..1
Deadlinesdate type
start date
![Page 12: Monica Farrow EM G30 monica@macs.hw.ac.uk Material on Vision Er 1 F28DM: Database Management Systems The Entity Relationship Model](https://reader037.vdocument.in/reader037/viewer/2022103112/551b2e56550346d41a8b4d01/html5/thumbnails/12.jpg)
Er 12
Entity
• Entity: a thing or object of importance, about which data must be captured• A entity is described by a set of attributes and
may have relationships with other entities
• Entities can be objects with a physical existence• E.g. Employee, Department
• Or with a conceptual or abstract existence• E.g. deadline
![Page 13: Monica Farrow EM G30 monica@macs.hw.ac.uk Material on Vision Er 1 F28DM: Database Management Systems The Entity Relationship Model](https://reader037.vdocument.in/reader037/viewer/2022103112/551b2e56550346d41a8b4d01/html5/thumbnails/13.jpg)
Er 13
Entity Type, Entity occurrence
• Entity Type (or Set): A group of objects with the same properties • E.g. all employees in the system
• Entity Occurrence: A uniquely identifiable object of an entity type• E.g a particular employee “John Smith”
• An entity set consists of entity occurrences and can be shown in a semantic net like this:
John Smith
TimGrey
AmyWhite
![Page 14: Monica Farrow EM G30 monica@macs.hw.ac.uk Material on Vision Er 1 F28DM: Database Management Systems The Entity Relationship Model](https://reader037.vdocument.in/reader037/viewer/2022103112/551b2e56550346d41a8b4d01/html5/thumbnails/14.jpg)
Er 14
Attributes 1
• An attribute is a property of an entity or a relationship type• E.g Employee name, staff number, date of birth
• The attribute domain is the set of allowable values E.g.:• 6 digits for the staff number• Up to 20 characters for a name• A set of building names (Earl Mountbatten,
David Brewster etc)
![Page 15: Monica Farrow EM G30 monica@macs.hw.ac.uk Material on Vision Er 1 F28DM: Database Management Systems The Entity Relationship Model](https://reader037.vdocument.in/reader037/viewer/2022103112/551b2e56550346d41a8b4d01/html5/thumbnails/15.jpg)
Er 15
Simple or composite
• Attributes can be simple or composite• Staff number is just 6 digits – simple• Name could be divided into first names and last name.• Date of birth consists of day, month, year
• Decide whether to model name as a simple attribute or to subdivide it, depending on how it will be used in the application
• As individual components, or not
• Show composite attributes indented Employeessn {PK}name first names last namedate of birthgender
![Page 16: Monica Farrow EM G30 monica@macs.hw.ac.uk Material on Vision Er 1 F28DM: Database Management Systems The Entity Relationship Model](https://reader037.vdocument.in/reader037/viewer/2022103112/551b2e56550346d41a8b4d01/html5/thumbnails/16.jpg)
Er 16
Single and multi-valued attributes
• Single and multi-valued• Most attributes are single-valued (date of birth,
name)• A company may have 3 telephone numbers –
multi-valued• A department may have different locations
• Show permitted number of attributes in square brackets
RoomroomID {PK}tel [1..3]
![Page 17: Monica Farrow EM G30 monica@macs.hw.ac.uk Material on Vision Er 1 F28DM: Database Management Systems The Entity Relationship Model](https://reader037.vdocument.in/reader037/viewer/2022103112/551b2e56550346d41a8b4d01/html5/thumbnails/17.jpg)
Er 17
Derived attribute
• A derived attribute is an important attribute, but one that should be calculated from other data
• E.g. we often need to know a person’s age, but this changes over time. It is best just to work it out when we need it .
• Precede with a slash
• Likely usage - fairly rare• Eg. result of calculation
such as duration, age, actual miles per gallon of car
Employeessn {PK}name first names last namedate of birth/age
![Page 18: Monica Farrow EM G30 monica@macs.hw.ac.uk Material on Vision Er 1 F28DM: Database Management Systems The Entity Relationship Model](https://reader037.vdocument.in/reader037/viewer/2022103112/551b2e56550346d41a8b4d01/html5/thumbnails/18.jpg)
Er 18
Keys
• A minimal set of attributes which uniquely identifies each occurrence of an entity type is called a candidate key
• E.g. Employee could be identified by staff number or NHS number
• Names are a poor choice of key, they might not be unique
• Select one candidate key to uniquely identify the entity in your system – the primary key
• E.g. staff number.• Often there is only one candidate key
• Show primary keys with {PK}• Alternative or candidate keys {AK}
Employeessn {PK}nhsNo {AK}name first names last namedate of birthgender
![Page 19: Monica Farrow EM G30 monica@macs.hw.ac.uk Material on Vision Er 1 F28DM: Database Management Systems The Entity Relationship Model](https://reader037.vdocument.in/reader037/viewer/2022103112/551b2e56550346d41a8b4d01/html5/thumbnails/19.jpg)
Er 19
Problems with keys
• Sometimes it might be hard to choose a key• An Address entity
• Street number and postcode?• Do all addresses fit this pattern?
• A Volunteer for a charity• May not be assigned any sort of id number• Name might not be unique• Invent one? E.g. initials and sequence number• Use an ‘autonumber’ – meaningless but unique
• This problem should be noted but decisions can be delayed until later in the design.
![Page 20: Monica Farrow EM G30 monica@macs.hw.ac.uk Material on Vision Er 1 F28DM: Database Management Systems The Entity Relationship Model](https://reader037.vdocument.in/reader037/viewer/2022103112/551b2e56550346d41a8b4d01/html5/thumbnails/20.jpg)
Er 20
Composite key
• A candidate key that consists of more than one attribute is called a composite key• i.e. more than one attribute is needed to make
the entity unique• E.g. Keep a list of company contacts. Some
companies have branches in various towns. So the company name and the town is needed to identify the company.
CompanyContactcompany name {PK}town {PK}contact namecontact phone
![Page 21: Monica Farrow EM G30 monica@macs.hw.ac.uk Material on Vision Er 1 F28DM: Database Management Systems The Entity Relationship Model](https://reader037.vdocument.in/reader037/viewer/2022103112/551b2e56550346d41a8b4d01/html5/thumbnails/21.jpg)
Er 21
Strong and weak entity types
• A strong entity is not existence-dependent upon other entities • Employee and Department entities both exist in
a company
• A weak entity is existence-dependent upon some other entity. Details about this weak entity would not be kept in the database without the other entity, and it cannot be uniquely identified without knowing about the associated entity.• E.g. the details of one item in an order
![Page 22: Monica Farrow EM G30 monica@macs.hw.ac.uk Material on Vision Er 1 F28DM: Database Management Systems The Entity Relationship Model](https://reader037.vdocument.in/reader037/viewer/2022103112/551b2e56550346d41a8b4d01/html5/thumbnails/22.jpg)
Er 22
Strong and weak entity types
• Weak entities are quite confusing, and there can quite often be a debate as to whether an entity is weak or not
• It’s not possible to identify candidate keys for a weak entity
• Think about possible OrderItem entities• Order 5 could contain an order for 10 of item number 51• Order 6 could also contain an entry for 10 of item number
51• We need to include the order number to make the entry
unique – but don’t do this in the ER diagram, leave as a weak entity
Orderorder number {PK}customer numberdate of order
OrderItemItem numberquantity
1
has
1..*
![Page 23: Monica Farrow EM G30 monica@macs.hw.ac.uk Material on Vision Er 1 F28DM: Database Management Systems The Entity Relationship Model](https://reader037.vdocument.in/reader037/viewer/2022103112/551b2e56550346d41a8b4d01/html5/thumbnails/23.jpg)
Er 23
Strong and weak entity types
• At this stage, another way of thinking about the weak entity is to consider it as a composite multivalued attribute:
Orderorder number {PK}customer numberdate of orderorder item [1..*] item number quantity
![Page 24: Monica Farrow EM G30 monica@macs.hw.ac.uk Material on Vision Er 1 F28DM: Database Management Systems The Entity Relationship Model](https://reader037.vdocument.in/reader037/viewer/2022103112/551b2e56550346d41a8b4d01/html5/thumbnails/24.jpg)
Er 24
Relationships• Relationship: An association among 2 or
more entities. (example on next slide)• In UML notation, the relationship should be
labelled, and a black triangle indicates the direction that the label should be read
• E.g. Employee works on Project
• Relationships may have attributes• E.g. Employee John Smith works on Project X for
10 hours
• We can also show how many entities participate in the relationships, shown here using 1..*
• More about this in a later slide
![Page 25: Monica Farrow EM G30 monica@macs.hw.ac.uk Material on Vision Er 1 F28DM: Database Management Systems The Entity Relationship Model](https://reader037.vdocument.in/reader037/viewer/2022103112/551b2e56550346d41a8b4d01/html5/thumbnails/25.jpg)
Er 25
Relationships example
Projectproj number {PK}project name
Employee
ssn {PK}name first names last namesdate of birth
1..* 1..*works on
hours
![Page 26: Monica Farrow EM G30 monica@macs.hw.ac.uk Material on Vision Er 1 F28DM: Database Management Systems The Entity Relationship Model](https://reader037.vdocument.in/reader037/viewer/2022103112/551b2e56550346d41a8b4d01/html5/thumbnails/26.jpg)
Er 26
Relationships• Relationship Type or Set: A collection of similar
relationships• The Set is the set of all lines in the semantic net below
• Relationship occurrence: a uniquely identifiable association, which includes one occurrence from each particpating entity type
• E.g. John Smith works on project X• Each line below is an occurrence
John Smith
TimGrey
AmyWhite
X
A
RR
X
![Page 27: Monica Farrow EM G30 monica@macs.hw.ac.uk Material on Vision Er 1 F28DM: Database Management Systems The Entity Relationship Model](https://reader037.vdocument.in/reader037/viewer/2022103112/551b2e56550346d41a8b4d01/html5/thumbnails/27.jpg)
Er 27
Relationships• There may be more than one
relationship between 2 entity types
Departmentdept number {PK}Dept name
Employee
ssn {PK}name first names last namesdate of birth
1..* 1works for
11manages
![Page 28: Monica Farrow EM G30 monica@macs.hw.ac.uk Material on Vision Er 1 F28DM: Database Management Systems The Entity Relationship Model](https://reader037.vdocument.in/reader037/viewer/2022103112/551b2e56550346d41a8b4d01/html5/thumbnails/28.jpg)
Er
28
Complex relationships• Introduce a diamond (as in Chen notation) to
represent relationships between more than two entity types
• For a particular course and programme, there can be many students. It’s possible that no students choose this course for a programme.
• For a particular student and course, they are only taking one programme
• For a particular student and programme, there should be 8 courses – but allow less in case of exemptions
Programme
Student
Coursestudies
0..*
1 1..8
![Page 29: Monica Farrow EM G30 monica@macs.hw.ac.uk Material on Vision Er 1 F28DM: Database Management Systems The Entity Relationship Model](https://reader037.vdocument.in/reader037/viewer/2022103112/551b2e56550346d41a8b4d01/html5/thumbnails/29.jpg)
Er 29
Exceptions to the rule
• Never impose ‘normal’ constraints on a database system if there could be exceptions to the rule!
• E.g. The normal number of courses for a student to take is 8, but occasionally students may take more or less.• More if repeating a course from previous year• Less if some sort of part-time arrangement
![Page 30: Monica Farrow EM G30 monica@macs.hw.ac.uk Material on Vision Er 1 F28DM: Database Management Systems The Entity Relationship Model](https://reader037.vdocument.in/reader037/viewer/2022103112/551b2e56550346d41a8b4d01/html5/thumbnails/30.jpg)
Er 30
Recursive relationships• A recursive relationship is when an
entity has a relationship with itself• E.g. • A member of staff may supervise one or more
other members of staff• A member of staff may be supervised by
another member of staff
supervises
Staff0..*
0..1
![Page 31: Monica Farrow EM G30 monica@macs.hw.ac.uk Material on Vision Er 1 F28DM: Database Management Systems The Entity Relationship Model](https://reader037.vdocument.in/reader037/viewer/2022103112/551b2e56550346d41a8b4d01/html5/thumbnails/31.jpg)
Er 31
Cardinality Constraints (1)• Cardinality = how many
• When reading, ignore the number nearest to the first entity mentioned
• Start sentence with ‘A’ or ‘An’• End sentence with the details in the numbers
nearest the second entity• A department is worked for by many employees • An employee works for one department
Departmentdept number {PK}dept name
Employee
ssn {PK}name first names last namesdate of birth
1..* 1works for
11manages
![Page 32: Monica Farrow EM G30 monica@macs.hw.ac.uk Material on Vision Er 1 F28DM: Database Management Systems The Entity Relationship Model](https://reader037.vdocument.in/reader037/viewer/2022103112/551b2e56550346d41a8b4d01/html5/thumbnails/32.jpg)
Er 32
Cardinality Constraints (2)• Cardinality = how many• 1:1
• An employee manages one department• A department is managed by one employee
• 1:Many• An employee works for one department• A department has many employees
Departmentdept number {PK}dept name
Employee
ssn {PK}name first names last namesdate of birth
1..* 1works for
11manages
![Page 33: Monica Farrow EM G30 monica@macs.hw.ac.uk Material on Vision Er 1 F28DM: Database Management Systems The Entity Relationship Model](https://reader037.vdocument.in/reader037/viewer/2022103112/551b2e56550346d41a8b4d01/html5/thumbnails/33.jpg)
Er 33
Cardinality Constraints (2)• Many : Many
• An employee works on many projects• A project has many employees working on it
Projectproj number {PK}project name
Employee
ssn {PK}name first names last namesdate of birth
1..* 1..*works on
hours
![Page 34: Monica Farrow EM G30 monica@macs.hw.ac.uk Material on Vision Er 1 F28DM: Database Management Systems The Entity Relationship Model](https://reader037.vdocument.in/reader037/viewer/2022103112/551b2e56550346d41a8b4d01/html5/thumbnails/34.jpg)
Er 34
Cardinality Constraints (3)
One-to-One One-to-Many Many-to-One Many-to-Many
• Cardinality constraints can be shown by a semantic net
![Page 35: Monica Farrow EM G30 monica@macs.hw.ac.uk Material on Vision Er 1 F28DM: Database Management Systems The Entity Relationship Model](https://reader037.vdocument.in/reader037/viewer/2022103112/551b2e56550346d41a8b4d01/html5/thumbnails/35.jpg)
Er 35
Participation Constraints• The participation constraint determines
whether all or only some entity occurrences participate in a relationship• Every department must have a manager• Not all employees are managers
• In UML notation, the multiplicity determines optional or mandatory participation• 0..* means optional• 1..* means mandatory
• In other notations, participation may be shown by vertical bar on the relationship near the entity, or by open and closed circles, or thicker relationship lines
![Page 36: Monica Farrow EM G30 monica@macs.hw.ac.uk Material on Vision Er 1 F28DM: Database Management Systems The Entity Relationship Model](https://reader037.vdocument.in/reader037/viewer/2022103112/551b2e56550346d41a8b4d01/html5/thumbnails/36.jpg)
Er 36
Other constraints
• There are various constraints that can’t be shown on an ER diagram, for example:• Domain constraints
• E.g. gender can only be M or F• Multi-table constraints other than the
relationships• E.g. Employees aged under 21 cannot work on
Project X• E.g. The time ranges allocated to a module
cannot overlap
![Page 37: Monica Farrow EM G30 monica@macs.hw.ac.uk Material on Vision Er 1 F28DM: Database Management Systems The Entity Relationship Model](https://reader037.vdocument.in/reader037/viewer/2022103112/551b2e56550346d41a8b4d01/html5/thumbnails/37.jpg)
Er 37
Conceptual Design using the ER Model
• Design Choices:• Should a concept be modelled as an entity or an
attribute?• Should a concept be modelled as an entity or a
relationship?• Identifying relationships: binary or ternary
• Constraints in the ER Model:• A lot of data semantics can (and should) be captured.• Keep the initial ER model like the real world
• E.g. don’t show foreign keys• When converting to tables, various relational database
rules may change some attributes to entities
![Page 38: Monica Farrow EM G30 monica@macs.hw.ac.uk Material on Vision Er 1 F28DM: Database Management Systems The Entity Relationship Model](https://reader037.vdocument.in/reader037/viewer/2022103112/551b2e56550346d41a8b4d01/html5/thumbnails/38.jpg)
Er 38
Fan traps
• These obscure the relationship between two entities
• In the following, each student is attached to exactly one department as is each course, but you cannot tell which courses each student attends.
• Fan traps occur when two supposedly related entity types are connected only through many-to-one relationships with some third entity type
Course StudentDepartment1 11..* 1..*
![Page 39: Monica Farrow EM G30 monica@macs.hw.ac.uk Material on Vision Er 1 F28DM: Database Management Systems The Entity Relationship Model](https://reader037.vdocument.in/reader037/viewer/2022103112/551b2e56550346d41a8b4d01/html5/thumbnails/39.jpg)
Er 39
Fan traps
• The solution is to change which entity type is at the centre or maybe to add a new relationship • Depending on whether there is a significant link
between student and department, or whether the link is just through the course
Student DepartmentCourse1 11..* 1..*
Student Department
Course111..*
1..*
11..*
![Page 40: Monica Farrow EM G30 monica@macs.hw.ac.uk Material on Vision Er 1 F28DM: Database Management Systems The Entity Relationship Model](https://reader037.vdocument.in/reader037/viewer/2022103112/551b2e56550346d41a8b4d01/html5/thumbnails/40.jpg)
Er 40
Chasm traps
• These imply relationships between entity types which do not hold
• In the following, it has been decided to model the student information using the intuition that a student’s department can be inferred through a supervisor.
Student DepartmentSupervisor0..1 11..* 1..*
![Page 41: Monica Farrow EM G30 monica@macs.hw.ac.uk Material on Vision Er 1 F28DM: Database Management Systems The Entity Relationship Model](https://reader037.vdocument.in/reader037/viewer/2022103112/551b2e56550346d41a8b4d01/html5/thumbnails/41.jpg)
Er 41
Chasm traps
• However, not all students have supervisors (partial participation), so what is the department of such students?
• The solution is to put in a direct relationship between student and department
Student DepartmentSupervisor0..1 11..* 1..*
11..*
![Page 42: Monica Farrow EM G30 monica@macs.hw.ac.uk Material on Vision Er 1 F28DM: Database Management Systems The Entity Relationship Model](https://reader037.vdocument.in/reader037/viewer/2022103112/551b2e56550346d41a8b4d01/html5/thumbnails/42.jpg)
Er 42
Limitations to ER diagrams
• We’ve covered the basic ER diagrams• An extended version (brief details on next
slide) uses generalisation and specialisation to cover more complex situations
• In your coursework, if you find some of your constraints cannot be captured in your ER diagram, make notes of these and hand in as text.
![Page 43: Monica Farrow EM G30 monica@macs.hw.ac.uk Material on Vision Er 1 F28DM: Database Management Systems The Entity Relationship Model](https://reader037.vdocument.in/reader037/viewer/2022103112/551b2e56550346d41a8b4d01/html5/thumbnails/43.jpg)
Er 43
Extended ER Diagrams
• See diagram on the next slide• Uses generalisation and specialisation• ALL Employees have the attributes in the
generalised superclass Employee • Extra attributes must be kept according to
the role of the employee (e.g. manager or sales personnel) and according to their employment category (salaried or hourly paid)
![Page 44: Monica Farrow EM G30 monica@macs.hw.ac.uk Material on Vision Er 1 F28DM: Database Management Systems The Entity Relationship Model](https://reader037.vdocument.in/reader037/viewer/2022103112/551b2e56550346d41a8b4d01/html5/thumbnails/44.jpg)
Er 44
Extended ER Diagrams
Employee
ssn {PK}name first names last namesdate of birth
Manager
mgrStartDate
Salaried
salary scale
HourlyPaid
rate
SalesPersonnel
salesArea
(Optional, And) (Mandatory, Or)
![Page 45: Monica Farrow EM G30 monica@macs.hw.ac.uk Material on Vision Er 1 F28DM: Database Management Systems The Entity Relationship Model](https://reader037.vdocument.in/reader037/viewer/2022103112/551b2e56550346d41a8b4d01/html5/thumbnails/45.jpg)
Er 45
Company ER Diagram
Departmentdept number {PK}dept name {AK}location [1..5]
Employee
ssn {PK}name first names last namesdate of birth/age
1..* 1works for
1
0..1manages
supervises
0..*
0..1
ManagermgrStartDate
SalesPersonnelsalesArea
(Optional, And)
SalessaleDatesalePrice
1..*1
Fragment of ER diagram showing that relationships can be shown from both the generalised and the specialised entities – as appropriate
![Page 46: Monica Farrow EM G30 monica@macs.hw.ac.uk Material on Vision Er 1 F28DM: Database Management Systems The Entity Relationship Model](https://reader037.vdocument.in/reader037/viewer/2022103112/551b2e56550346d41a8b4d01/html5/thumbnails/46.jpg)
Er 46
Extended ER Diagrams
• Participation constraints are shown with the labels (Mandatory or Optional)• Employees do not have to be managers or sales
personnel• Employees must be salaried or hourly paid
• Disjoint constraints are shown with the labels (And or Or)• Employees could be both a Manager AND
SalesPersonnel• Employees must be either Salaried OR
HourlyPaid, not both
![Page 47: Monica Farrow EM G30 monica@macs.hw.ac.uk Material on Vision Er 1 F28DM: Database Management Systems The Entity Relationship Model](https://reader037.vdocument.in/reader037/viewer/2022103112/551b2e56550346d41a8b4d01/html5/thumbnails/47.jpg)
Er 47
Conceptual Design: Summary• Conceptual design
• Follows requirements analysis • Is performed at a high level of abstraction*
involving entities, relationships and attributes• Yields a high-level description of data to be stored
• The Entity Relationship Model is popular for conceptual design• But can be very subjective
• * Abstraction = hiding implementation details
![Page 48: Monica Farrow EM G30 monica@macs.hw.ac.uk Material on Vision Er 1 F28DM: Database Management Systems The Entity Relationship Model](https://reader037.vdocument.in/reader037/viewer/2022103112/551b2e56550346d41a8b4d01/html5/thumbnails/48.jpg)
Er 48
Conceptual Design: Summary• Include integrity constraints in the ER
model, • key constraints, participation constraints,
overlap/disjoint, etc
• *** Foreign key constraints are implicit ***• i.e. shown by the relationship lines ONLY, not
described as attributes• In an ER diagram, each attribute occurs only
once, in the most logical place
• Constraints are important to determine the best DB design for an organisation