1. F28DM: Database Management Systems The Entity Relationship ModelEr

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 Er

3. Storage structure and File Organisation
Database Design
Database design goes through several stages.
Problem
Requirements Analysis
Data Requirements
Data Analysis, Conceptual Design
Conceptual Data Model
Logical Database Design
Logical Schema
Physical Database Design
Storage structure and File Organisation 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 Er

5. Conceptual Design with the ER Model
The questions we need to ask are:
What are the entities (e.g. objects, individuals) in the organisation?
Which relationships exist among these entities?
What information do we want to store about these entities and relationships?
What are the business rules of the organisation?
Which integrity constraints do arise from them?
The answers are mostly represented in an Entity Relationship diagram 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 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 Er

8. UML notation Spy SpyMaster In this diagram
codeName {PK}
firstName
dateOfBirth
gender
mark
amountDue
SpyMaster
mCodeName {PK}
contact
manages
1..* 1
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. Er

9. Other notations
mCode
Name
contact
firstName
code Name
etc 1 n
Spy
SpyMaster
manages
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 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. Er

11. Company ER Diagram Employee Department Deadlines Project start date
dept number {PK}
dept name {AK}
location [1..5]
Employee
ssn {PK}
name
first names
last names
date of birth
gender
salary
/age
1..* 1
works for
0..1
manages
Project
proj number {PK}
project name {AK}
0..*
controls
hours
works on
has
supervises
Deadlines
date
type
start date
Assumes we only want to know about which depts in which locations, not which employee in which location etc 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 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
Tim
Grey
Amy
White 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) 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
Employee
ssn {PK}
name
first names
last name
date of birth
gender Er

16. Single and multi-valued attributes
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
Room
roomID {PK}
tel [1..3] 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
Employee
ssn {PK}
name
first names
last name
date of birth
/age 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}
Employee
ssn {PK}
nhsNo {AK}
name
first names
last name
date of birth
gender 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. 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.
CompanyContact
company name {PK}
town {PK}
contact name
contact phone 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 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
has
Order
order number {PK}
customer number
date of order
OrderItem
Item number
quantity 1
1..* 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:
Order
order number {PK}
customer number
date of order
order item [1..*]
item number
quantity 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 Er

25. Relationships example
Employee
ssn {PK}
name
first names
last names
date of birth
hours
Project
proj number {PK}
project name
works on
1..*
1..* 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
Tim
Grey
Amy
White X A RR Er

27. Relationships
There may be more than one relationship between 2 entity types
Employee
ssn {PK}
name
first names
last names
date of birth 1
manages 1
Department
dept number {PK}
Dept name
works for 1
1..* 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
Course
studies
0..* 1
1..8 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 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
0..1
Staff
0..* 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
Department
dept number {PK}
dept name
Employee
ssn {PK}
name
first names
last names
date of birth
1..* 1
works for
manages 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
Employee
ssn {PK}
name
first names
last names
date of birth 1
manages 1
Department
dept number {PK}
dept name
works for 1
1..* Er

33. Cardinality Constraints (2)
Many : Many
An employee works on many projects
A project has many employees working on it
hours
Employee
ssn {PK}
name
first names
last names
date of birth
Project
proj number {PK}
project name
works on
1..*
1..* Er

34. Cardinality Constraints (3)
Cardinality constraints can be shown by a semantic net
Many-to-One
One-to-One
One-to-Many
Many-to-Many 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 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 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 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
1..* 1 1
1..*
Course
Department
Student 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
1..* 1
1..* 1
Student
Course
Department
1..* 1
Student
Department 1
1..*
Course 1
1..* 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.
1..*
1..*
0..1 1
Student
Supervisor
Department 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
1..*
0..1 1
1..*
Student
Supervisor
Department 1
1..* 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. 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) Er

44. Extended ER Diagrams Employee Manager Salaried HourlyPaid
ssn {PK}
name
first names
last names
date of birth
Manager
mgrStartDate
Salaried
salary scale
HourlyPaid
rate
SalesPersonnel
salesArea
(Optional, And)
(Mandatory, Or) Er

45. Company ER Diagram Employee Department Manager SalesPersonnel Sales
supervises
0..1
Employee
ssn {PK}
name
first names
last names
date of birth
/age
Department
dept number {PK}
dept name {AK}
location [1..5]
0..*
works for 1
1..*
0..1
manages
(Optional, And) 1
SalesPersonnel
salesArea
Manager
mgrStartDate
Fragment of ER diagram showing that relationships can be shown from both the generalised and the specialised entities – as appropriate 1
1..*
Sales
saleDate
salePrice 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 Er

47. Conceptual Design: Summary
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 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 Er