03 Entity Relationship Modelling
03 Entity Relationship Modelling
Modeling
DS187 – DATABASE MANAGEMENT FOR DATA SCIENCE
Outline
• Analyzing Data
• Entity Relationship Model
• Entity Relationship Diagram
Why Analyze Data?
• Maintain data Integrity
• Minimize data Redundancy
• Improve Efficiency (performance)
Data Analysis
1. It is concerned with the NATURE and USE of data.
2. It is time consuming; it throws up a lot of questions.
3. Analyses the business thoroughly to determine the requirements
and to determine where the problem is;
4. It involves data gathering sometimes requiring individual/teams
from client to get detailed & accurate requirements;
5. It involves "breaking down" the system in different pieces to
analyze the situation;
Data Analysis
6. Involves:
• IDENTIFICATION of the data
elements which are needed
to support the data
processing system of the
organization,
Data Analysis
6. Involves:
• the placing of these elements
INTO LOGICAL GROUPS and
• the definition of the RELATIONSHIPS
between the resulting groups.
Entity Relationship Modelling
• A high-level conceptual data model developed by Chen (1976) to
facilitate database design
• It is a systematic way of describing and defining a business process.
• A detailed, logical representation of data for an organization or for a
business area
• It supports the user’s perception of the data
• It is DBMS and hardware independent
Entity Relationship Modelling
• An ER model is typically implemented as a database such as
relational database wherein entities are represented as columns &
rows of a table and each record is an instance of the entity.
• It is composed of the following:
– Entities
– Relationships (associations) among entities
– Attributes (properties) of entities and relationships
Entity Relationship Diagram (ERD)
• The graphical representation of this model is called the entity-
relationship diagram (ERD)
Entity Relationship Diagram (ERD)
• Optional Attribute
• May have a value or not.
• For example: Employee's spouse is optional attribute because an
employee may or may not have a spouse.
Single vs Composite
• Single
• Attributes which can’t be divided into subparts.
• Example: Employee Number, Age
• Composite
• Attributes which can be divided into smaller subparts.
• These subparts represent basic attributes with independent meanings of
their own.
• Example: Name = {firstName, midName, lastName}
Single Valued vs Multi Valued
• Single Valued Attributes
• holds a single value for a single entity
• Example: Student number
• Multi-valued Attributes
• An instance of this attribute can contain multiple values of uniform
syntax.
• Each value of a multi value attribute must be unique.
• Hobby is a multi-valued attribute. It may contain painting, programming,
biking, etc.
Stored vs Derived
• Stored attribute
• Attributes that are included in the database table.
• Derived Attributes
• Are derived or calculated from one or more stored attribute/s.
• Example: Age and interest of a given deposit.
• Coded attribute
• Uses one or more letters or numbers to represent a fact.
• Example, the value Gender might use the letters "M" and "F" as values
rather than "Male" and "Female".
Select Primary Key
• Select the Primary Key for each entity
• Which attributes uniquely identify instances of that entity type?
• This may not be possible for some weak entities.
• Candidate key
• an attribute or set of attributes that uniquely identifies individual
occurrences of an entity type.
• For Example:
• Entity: Staff
• Attributes: name, address, empNo, TIN, SSS
• Candidate keys: Employee Num, TIN, SSS num
Select Primary Key
• Primary key
• the candidate key selected to be the primary key;
• the choice of primary key for an entity is based on considerations of
attribute length, current and future certainty of uniqueness.
• Example:
• employees may be assigned to no more than three projects at a time;
• Subject - students
Cardinality of a Relationship
• A many-to-many (1:N) relationship
Cardinality of a Relationship
Cardinality of a Relationship
Optional and Mandatory
Relationship
• Mandatory many to many
• Optional many to many
• Optional/mandatory many to many
• Optional/mandatory one to many
• Mandatory one to one
Optional Relationship
• A relationship can have a cardinality of zero
• Optional relationships are typically indicated by the conditional
tense such as “may be”. (e.g An employee may be assigned to a
project)
• The optionality can be different at each end of the relationship
• For example, a student must be on a course. This is mandatory to
the relationship ‘student studies course’ is mandatory.
• But a course can exist before any students have enrolled. Thus the
relationship ‘course is_studied_by student’ is optional.
• To show optionality, put a circle or ‘0’ at the ‘optional end’ of the
relationship.
Optional Relationship
• As the optional relationship is ‘course is_studied_by student’, and
the optional part of this is the student, then the ‘O’ goes at the
student end of the relationship connection.
• It is important to know the optionality because you must ensure
that whenever you create a new entity it has the required
mandatory links.
Mandatory Relationship
• If a relationship must have a cardinality of at least one
• These are indicated by words such as “must” have, at least one.
• Example: a student must register in at least one subject each
semester.
Mandatory Relationship (M:M)
Optional Many to Many (M:M)
Optional/Mandatory Many to
Many(M:M)
Optional/Mandatory One to
Many(M:M)
Optional/Mandatory One to
Many(M:M)
Mandatory One to Many(M:M)
Representing M:M Relationships
• We can resolve a many-to-many relationship by dividing it into two
one-to-many relationships.
• Consider the case of a car hire company:
• Customers hire cars, one customer hires many
• cars and a car is hired by many customers.