Step by Step ERD Example
Step by Step ERD Example
The scenario
A University contains many Faculties. The Faculties in turn are divided into several Schools. Each School
offers numerous programs and each program contains many courses. Lecturers can teach many different
courses and even the same course numerous times. Courses can also be taught by many lecturers. A
student is enrolled in only one program but a program can contain many students. Students can be
enrolled in many courses at the same time and the courses have many students enrolled.
Step 1 - Identify Entities
The entities in this scenario are
University
Faculty
School
Program
Course
Lecturer
Student
Step 2 - Find relationships
University Faculty School Program Course Lecturer Student
University contains
divided
Faculty
into
School offers employs
Program contains
taken
Course
by
Lecturer taught
Student enrolled enrolled
1
Step 4 - Fill in cardinality
The university contains many faculties
Each faculty is divided into several schools
Each school offers numerous programs
Each program contains many courses
Each school employs many lecturers
Lecturers can teach many courses
Lecturers can teach the same course many times
Courses can be taught by more than one lecturer
A student is enrolled in only one program
Students can be enrolled in many courses at the same time
Courses have many students enrolled
2
Step 5 - Define primary keys
The primary keys could be
University – University name
Faculty – Faculty name
School – School name
Program – Program code
Course – Course number
Lecturer – Employee number
Student – Student number
3
In this step any many-to-many relationships have to be eliminated. In the ERD so far
there are two relationships that fall into this category. They are Lecturer – Course and
Course – Student. As you can see Associative Entities have been included to rectify the
situation.
4
Step 7 - Identify attributes
In the scenario there are no attributes indicated, so it is up to the analyst to ascertain
what data needs to be kept about each particular entity.
For example other attributes for Lecturer could be
Employee Name
Employee Address
Speciality
Step 8 - Map attributes
An example of mapping the attributes would be
Attribute Entity Attribute Entity
Employee_name Lecturer Faculty_name Faculty
Employee_number Lecturer Student_number Student
Course_number Course Student_name Student
Step 9 - Draw fully attributes ERD
This is an example of what all the entities should look like when they have been fully
attributed.
5
o Entities
o Attributes
o Candidate keys and identifiers
o Multivalued attributes
o Relationships
Conceptual data modelling and the ER model
o Degree of a relationship
o Cardinalities in relationships
o Associative entities
Step-by-step construction of ERDs
Summary
Focus
The focus of this module continues with structuring system requirements. We now
move on to conceptual data modelling. In order to complete this Entity Relationship
Diagrams (ERDs) will be discussed.
Objectives
Define the key data modelling terms
o Conceptual data model
o Entity Relationship Diagram
o Entity type.
o Entity instance
o Attribute
o Candidate key
o Multivalued attribute
o Relationship
o Degree
o Cardinality
o Associative entity
Ask appropriate questions to determine data requirements for an information
system.
Draw an ERD.
Explain the role of the conceptual data model.
Distinguish between and give examples of unary, binary and ternary
relationships.
Distinguish between relationships and associative entities and use an associative
entity in an ERD.
Relate data modelling to process and logic modelling.
Conceptual data modelling
A conceptual data model is a detailed model that shows the overall structure of
organisational data while being independent of any database management system or
other implementation considerations. Its purpose is to show as many rules about the
meaning and interrelationships among data as possible.
6
Process
The first step is to develop a data model for the current system.
Next, build a new data model that includes all the data requirements for the new
system.
In the design stage, the conceptual model is translated into a physical design.
Using the project repository, all data modelling and design steps can be traced.
Deliverables and outcomes
The primary deliverable for the conceptual data-modelling step is the Entity Relationship
Diagram (ERD).
There can be as many as four ERD’s produced and analysed during conceptual data
modelling. These are
1. An ERD that covers just the data needed in the project’s application
2. An ERD for the application system being replaced
3. An ERD for the whole database from which the new application’s data are
extracted
4. An ERD for the whole database from which data for the application system being
replaced is drawn
The other deliverable is a set of entries about data objects to be stored in the project
dictionary or repository. The repository is a mechanism to link data, process and logic
models of an information system.
Gathering information
In requirements determination investigations have to be undertaken and questions
asked that focus on the data rather than focus on the process and logic. There are two
perspectives that can be used
Top-down approach – the data model is derived from an intimate understanding
of the nature of the business.
Bottom-up approach – the information is gathered for data modelling by
reviewing specific business documents.
Introduction to Entity-relationship diagrams (ERDs)
Entity-Relationship Diagram (ERD) – is a detailed, logical and graphical representation of
the entities, associations and data elements for an organisation or business area.
The basic modelling notation contains three main constructs
Data entities
Relationships
Attributes
7
Entities
An entity is a person, place, object, event or concept in the user environment about which the
organisation wishes to maintain data.
An entity type is a collection of entities that share common properties or characteristics. For example for
the entity Person could have types – Employee or Student
An entity instance is a single occurrence of an entity type. For example in the entity type Employee it
would be the names of the employees.
Attributes
An attribute ia a named property or characteristic of an entity that is of interest to the organisation
An example of attribute for the entity STUDENT would be Student_ID, Student_Name
Candidate keys and identifiers
The candidate key is an attribute (or combination of attributes) that uniquely identifies each
instance of an entity type. The candidate key for STUDENT could be Student_ID
The identifier is a candidate key that has been selected as the unique, identifying characteristic
for an entity type.
The following rules need to be applied when selecting an identifier
Choose a candidate key that will not change its value over time.
Choose a candidate key that will always have a value and never be null
Avoid using intelligent keys. These area ones that could contain an abbreviation
of a location
Consider substituting single value surrogate keys for large composite keys
For each entity the name of the identifier is underlined on the ERD
Multivalued attributes
A multivalued attribute is an attribute that may take on more that one value for each
entity instance. An example would be if Dept_Name was an attribute of the entity
EMPLOYEE and the EMPLOYEE worked for more that one department.
It can be represented on the ERD in two ways
A double-lined ellipse
A weak entity
A repeating group is a set of two or more multivalued attributes that are logically
related
Relationships
8
A relationship in an ERD is an association between the instances of one or more entity
types that is of interest to the organisation.
This usually means that an event has occurred or that some natural linkage exists
between the entity instances.
Relationships are always labelled with verb phrases.
Degree of a relationship
Degree – the number of entity types that participate in a relationship
A unary or recursive relationship is a relationship between the instances of one entity
type
A binary relationship is a relationship between instances of two entity types
A ternary relationship is a simultaneous relationship among instances of three entity
types
Cardinalities in relationships
Cardinality is the number of instances of one entity that can (or must) be associated
with each instance of another entity
9
Minimum cardinality is the minimum number of instances of one entity that may be
associated with each instance of another entity
Maximum cardinality is the maximum number of instances of one entity that may be
associated with each instance of another entity
10
8. Map attributes For each attribute, match it with exactly one entity that it describes
9. Draw fully attributed Adjust the ERD from step 6 to account for entities or relationships discovered in
ERD step 8
10. Check results Does the final ERD accurately depict the system data?
Summary
Before you go on to the review questions, spend a few moments thinking about each of
the following key terms. If you are not really sure about the meanings revisit the various
areas in the textbook to refresh your memory
Associative entity Degree Multivalued attribute
Attribute Entity Relationship
Binary relationship Entity instance (instance) Repeating group
Entity Relationship
Candidaty key Ternary relationship
Diagram (ERD)
Unary relationship
Cardinality Entity type
(recursive relationship)
Conceptual data model Identifier
11