0% found this document useful (0 votes)
6 views

03 Entity Relationship Modelling

The document outlines the process of Entity Relationship Modeling, which is essential for database design in data science. It covers data analysis, the creation of Entity Relationship Diagrams (ERDs), and the identification of entities, attributes, and relationships, including cardinality and optionality. Additionally, it discusses the importance of maintaining data integrity and minimizing redundancy in database systems.

Uploaded by

skiclyde
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
6 views

03 Entity Relationship Modelling

The document outlines the process of Entity Relationship Modeling, which is essential for database design in data science. It covers data analysis, the creation of Entity Relationship Diagrams (ERDs), and the identification of entities, attributes, and relationships, including cardinality and optionality. Additionally, it discusses the importance of maintaining data integrity and minimizing redundancy in database systems.

Uploaded by

skiclyde
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 70

Entity Relationship

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)

• Entities are presented as RECTANGLE,


• Attributes are represented as CIRCLES/ OVALS,
• Relationships are portrayed as a DIAMOND
Entity Relationship Diagram (ERD)

• Any ER diagram has an equivalent relational table, and any relational


table has an equivalent ER diagram.
• ER diagramming is an invaluable aid to engineers in the design,
optimization, and debugging of database programs.
Sample ERD
Sample Digital ERD
Sample Digital ERD
ERD Development Process
1. Identify the entities
2. Determine the attributes for each entity
3. Select the primary key for each entity
4. Establish the relationships between the entities
5. Draw an entity model
6. Test the relationships and the keys
ERD Development Process: Identify
the Entities
• These are the object of interest in the system.
• It is better to put too many entities in at this stage and them
discard them later if necessary.
• Read the requirements specification carefully.
• Document any assumptions you need to make
• Remove duplicate entities - Ensure that they really separate entity
types or just two names for the same thing.
ERD Development Process: Identify
the Entities
• It is any object (e.g. person, place, object, event, or concept) in the
system that we want to model and store information about
• Entities can be thought of as nouns such as computer, an
employee, a song, a book.
• Entities are represented by a box with the name of the entity type
in capital letters
ERD Development Process: Identify
the Entities
• Students enrolled in courses

• A pharmaceutical company manufactures one or more drugs, and


each drug is manufactured and marketed by exactly one
pharmaceutical company.
ERD Development Process: Identify
the Entities
• The ACME Machine Shop is a small job shop that does machining of
components for that assembled finished products.
• The customers give ACME engineering drawings of parts and
request production of parts from ACME as needed.
• The manager of the machine shop has used a database to try to
organize some basic information on the customers’ parts and their
machining requirements as well as scheduling information based on
orders.
ERD Development Process:
Attributes
• Determine the attributes for each entity
• List the attributes of each entity (all properties to describe the
entity which are relevant to the application).
• Ensure that the entity types are really needed.
• are any of them just attributes of another entity type?
• if so keep them as attributes and cross them off the entity list.

• Do not assign attributes of one entity as attributes of another


entity!
ERD Development Process:
Attributes
• An attribute is
• A property/ characteristic of an entity that is of interest to the
organization (e.g. For entity student, its attributes may include stud No,
name, Address)
• Represented by the ellipse with the name of the attribute written in
capital letter
• A line is drawn to connect the attribute to its associated entity
Types of Attributes
• Required vs. Optional
• Single vs. Composite
• Single-valued vs. Multi-valued
• Stored vs. Derived
Required vs Optional
• Required Attribute
• It must have a value, a value must be known for each entity occurrence.
• For example: identifier attribute such as Employee Number.

• 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.

• A primary key is an attribute that:


• uniquely identifies individual instances of an entity type,
• can be simple or composite identifiers
• Is permanent or does not change in value and must not be NULL
Relationships Between Entities
• Establish the relationships between the entities
• Examine each entity type to see its relationship to others.
• Describe the cardinality and optionality of the relationships
• Examine the constraints between participating entities.
• Remove redundant relationships

• A relationship type is a meaningful association between entity


types
• A relationship is an association of entities where the association
includes one entity from each participating entity type.
Entity Relationship
• A relationship is indicated by a verb connecting two or more
entities.
• Each relationship has a name, degree and cardinality
Entity Relationship
• A relationship can have attributes
Entity Relationship
Examples:
• an OWNS relationship between a company and equipment,
• a SUPERVISES relationship between an employee and a
department,
• a PERFORMS relationship between an artist and a song
• a TAKES relationship between a student and a course
• a PURCHASES relationship between a customer and an item
Entity Relationship
• Degree of a Relationship
• It refers to the number of entities associated with the relationship
or number of participating entities in a relationship:
• unary,
• binary,
• ternary, etc.
Entity Relationship
• Unary Relationship
• It is a relationship where the same entity participates more than once in
different roles.
Entity Relationship
• Binary Relationship
Entity Relationship
• Binary Relationship
• It is also possible to have entities associated through two or more
distinct relationships.
Entity Relationship
• Ternary Relationship
Entity Relationship
• Ternary Relationship
Simplifying a Ternary Relationship
• When ternary relationships occurs in an ER model, they should
always be removed before finishing the model.
• Sometimes the relationships can be replaced by a series of binary
relationships that link pairs of the original ternary relationship.
Simplifying a Ternary Relationship
• This can result in the loss of some information - It is no longer clear
which sales assistant sold a customer a particular product
• Try replacing the ternary relationship with an entity type and a set
of binary relationships.
Simplifying a Ternary Relationship
• Relationships are usually verbs, so name the new entity type by the
relationship verb rewritten as a noun.
Simplifying a Ternary Relationship
• This can result in the loss of some information - It is no longer clear
which sales assistant sold a customer a particular product
• Try replacing the ternary relationship with an entity type and a set
of binary relationships.
Cardinality of a Relationship
• It refers to the number of instances of a participating entity that can
(or must) be associated with each instance of the other
participating entity
Cardinality of a Relationship
• A one-to-one (1:1) relationship occurs when at most one instance of
an entity A is associated with one instance of the same entity or
another entity B.
Cardinality of a Relationship
• A one-to-one (1:1) relationship
Cardinality of a Relationship
• A one-to-many (1:N) relationship occurs when one instance of entity
A, there are zero, one, or many instances of entity B but for one
instance of entity B, there is only one instance of entity A.
• Example:
• 1 department - many employees
• each employee -- is assigned to one department.
Cardinality of a Relationship
• A one-to-many (1:N) relationship
Cardinality of a Relationship
• A one-to-many (1:N) relationship
Cardinality of a Relationship
• Many-to-many (M:N) relationship
• when one instance of entity A, there are zero, one, or many instances of
entity B and for one instance of entity B there are zero, one, or many
instances of entity A.

• 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.

• Many-to-many relationships should be avoided.


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.

• Many-to-many relationships should be avoided.


Representing M:M Relationships

• The many to many relationship can be broken down to reveal a


‘hire’ entity, which contains an attribute ‘date of hire’.
Representing M:M Relationships
Example
• In a library Management system, the following entities and
attributes can be identified.
• Book -the set all the books in the library.
Book(Book-id, Title, Author, Price, Available (y or n))
• Member - the set all library members. The member is described by
the attributes Member_id, Name, Street,City, Zip_code, Mem_type,
Mem_date (date of membership), Expiry_date.
Example

• Publisher - the set of all the publishers of the books. Attributes of


this entity are Pub_id, Name, Street, City, and Zip_code.
• Supplier - the set of all the Suppliers of the books. Attributes of
this entity are Sup_id, Name, Street, City, and Zip_code.
• Assumptions: a publisher publishes a book. Supplier supplies book
to library. Members borrow the book (only issue).

You might also like