You are on page 1of 56

CMSC 127

File Processing & Database System

Entity-Relationship Model

Wk 4 – Lec 1
Topics:

• Entity-Relationship (ER) Model


• Entity and Entity Set
• What is an attribute?
• Classes of attribute
• Key attributes: superkeys, candidate keys, primary key
• What is a Relationship?
• Degree of a relationship,
• Cardinality in the relationship,
• When to make a Relationship into an entity or Associative Entity
• Uses and Limitations of ERD
• Generalization, Specification and Aggregation
Learning Outcomes:

At the end of this session, you should be able to:

1. Distinguish between entity and attributes


2. Relationship of Entities
3. Identify the candidate keys of an entity and determine the appropriate
primary key
4. Understand the difference between unary, binary and ternary
relationship
5. Be able to determine the cardinality of the relations
6. Define and differentiate generalization, specialization and aggregation
7. Create an ER diagram
Entity-Relationship (ER) Model/ ER Diagram

Entity-Relationship (ER) Model is based on the notion of real-world entities and


relationships among them. It creates entity set, relationship set, general attributes
and constraints.

ER Model was introduced by Peter Chen, an assistant professor at MIT’s Sloan


School of Management, in 1970.

This model is good to design a database, which can then be turned into tables in
relational model.

ER models and data models are typically drawn at up to three levels of detail:

1. Conceptual Model - E-R Model or Object-Oriented Model.


2. Logical Model - Relational Model.
3. Physical data model - Physical Data Structures.
Database Model

Heirarchical Network Relational ER Model

Conceptual Logical ER Physical ER


ER Model Model Model

https://www.visual-paradigm.com/support/documents/vpuserguide/3563/3564/85378_conceptual,l.html
Entity-Relationship (ER) Model/ ER Diagram

1. Conceptual Model - E-R Model or Object-Oriented Model.


• The highest-level view containing the least detail.
• It shows the overall scope of the model and portraying the system
architecture.

2. Logical or Implementation Model - Relational Model.


• Contains more detail than a conceptual model.
• The logical model is independent of the technology in which it will be
implemented.

3. Physical data model - Physical Data Structures.

• One or more physical model may be developed from each logical model.
• The physical models must show enough technology detail to produce and
implement the actual database.
Conceptual ERD models

Models the business objects that should exist in a system and the


relationships between them.

A conceptual model is developed to present an overall picture of the system by


recognizing the business objects involved.

It defines what entities exist.


Logical ERD model

Logical ERD is a detailed version of a Conceptual ERD.

A logical ER model is developed to enrich a conceptual model by defining


explicitly the columns in each entity and introducing operational and
transactional entities.
Physical ERD model

Physical ERD represents the actual design blueprint of a relational database.

A physical data model elaborates on the logical data model by assigning each
column with type, length, nullable, etc.
Components of Entity-Relationship (ER) Model/ ER Diagram

1. Entity
• Entity Set
• Weak entity

2. Attribute of the Entity


• super key, candidate key, primary key
• Categories: Single, composite, derived, etc

3. Relationship of Entities
• Degree of Relationship: Unary, Binary, Ternary
• Cardinality of the relationship:
• 1:1, 1: M, M: M
Components of Entity-Relationship (ER) Model/ ER Diagram
1. Entity

Entity – is a definable thing —such as a person, object, concept or event—that


can have data stored about it. Think of entities as nouns. Examples: a customer,
student, car or product. Typically shown as a rectangle.

A weak entity -- is represented using double rectangular boxes. It is an entity


that depends on another entity or Has a primary key that is partially or totally
derived from the parent entity in the relationship.

Entity Set – is the complete dataset of the entity. For entity Student, its entity
set is the complete dataset of all the students.
Components of Entity-Relationship (ER) Model/ ER Diagram
2. Attribute

– is a property or characteristic of an entity. Often shown as an


oval, ellipse or circle. Student’s attribute may include name,
age, id, and address.

Identify the attributes of the following entities:


• Movie, Book,
• Computer,
• Cellphone

Categories of Attributes:
• Simple
• Composite
• Derived attribute -- is calculated derived from another attribute,
such as age from a birthdate.
• Single-valued
• Multi-valued
Categories of Attributes:
Attribute Type Description Example
values that are atomic and cannot be
Simple broken down further birthdate
attribute that is made up of more address -> housenum, streetName,
Composite than one simple attribute barangay, townOrCity, province, et
not present in the whole database
management system, but can be
Derived derived from other attributes age from birthdate
Single-valued It has single Value Birthdate, gender/sex
Multi-valued It can have multiple values Hobbies
Attribute/s as Entity Keys
When an attribute or attributes can uniquely define an an entity in an entity set, then these attributes
can be called as entity key/s.

Entity keys can be:

• Super key -- is a set of attributes (one or more) that together define an entity in an entity set. 

• Candidate key --   is an attribute or set of attributes that uniquely identify an instance of an entity
or each record in a table. Some entities have more than one candidate key.

• Primary key -- is a candidate key that is most appropriate to become the main key for any table. It
is a key that can uniquely identify each record in a table. It should:
• NOT be NULL, and does NOT change its value over the life of each entity instance. 
• Avoid intelligent-keys (stored data as part of a key such as a code).  For example, a key where
the first two digits indicates a warehouse location would be a poor choice because the coding
scheme could change over time. 
• Substitute single-attribute surrogate keys for large composite keys.  A surrogate key can be a
system generated sequence of unique numbers.
Attribute/s as Entity Keys

Super key -- is a set of attributes (one or more) that


together define an entity in an entity set. 

Example:

super key = {student_id, (student_id, name), phone}

student_id is unique for every row of data, hence it can be


used to identity each row uniquely.

(student_id, name) -- name of two students can be same,


but their student_id can't be same hence this combination
can also be a key.

phone number for every student will be unique, hence


again, phone can also be a key.
Attribute/s as Entity Keys

Candidate key --   is an attribute or set of attributes that


uniquely identify an instance of an entity or each record in a
table. Some entities have more than one candidate key.

candidate key = (student_id, phone)

• A candidate key can never be NULL or empty & its value


should be unique.
• There can be more than one candidate keys for a table.
• A candidate key can be a combination of more than one
columns (attributes).

Primary key -- is a candidate key that is most appropriate to


become the main key for any table. It is a key that can uniquely
identify each record in a table.

Primary key = student_id


Other Keys
A composite key - is a combination of two or more columns
in a table that can be used to uniquely identify each row in
the table.

Uniqueness is only guaranteed when the columns are


combined; when taken individually the columns do not
guarantee uniqueness.

Normally, the records in relationship table or relationship


entity table can be uniquely identified by a combination of 2
or more columns or attributes.

A foreign key -- is a key used to link two tables together. It is a field


(or collection of fields) in one table that refers to the PRIMARY KEY
in another table.

The table containing the foreign key is called the child table, and the
table containing the candidate key is called the referenced or parent
table.
Components of Entity-Relationship (ER) Model/ ER Diagram
3. Relationship between Entities

It occurs when there are more than one entity. It is the logical association between
entities. Relationships are mapped with entities in various ways. Mapping cardinalities
define the number of association between two entities.

For example: A Teacher Entity is related to Student entity, because Teacher teaches the
students.

E-R Models are defined to represent the relationships into pictorial form to make it easier
for different stakeholders to understand.
Entity-Relationship (ER) Model/ ER Diagram

We can also present an


ER model or the ER
diagram using this
convention particularly if
the entities have many
attributes to make it easy
to understand and view.
ER Diagram is to visually represent the model
Uses of Entity Relationship Diagrams (ERD)

1. An ER diagram is often an initial step in determining requirements for an


information systems project.

2. To analyze existing databases to find and resolve problems in logic or


deployment. The diagram should reveal where it’s going wrong.

3. To design or analyze relational databases used in business processes. It can


streamline processes, uncover information more easily and improve results.

4. Help in analyzing databases used in business process re-engineering (BPR)


and in modeling a new database setup.

5. Used as method of storing relational information for business purposes and


later retrieval.
Limitations of ER diagrams and models

• Only for relational data: 


• Understand that the purpose is to show relationships.
• ER diagrams show only that relational structure.

• Not for unstructured data and semi-structured data: Unless the data is


cleanly delineated into different fields, rows or columns, ER diagrams
are probably of limited use.

• Difficulty integrating with an existing database:


• Using ER Models to integrate with an existing database can be a
challenge because of the different architectures.
Degree of the Relationship between Entities

A relationship's degree indicates the number of entities in a relationship.


It can be unary, binary, or ternary.

A unary/ recursive
relationship exists when an
association is maintained
within a single entity.

http://www.shsu.edu/~csc_tjm/summer2000/cs334/Chapter04/part1/Chap04-97.html
Degree of the Relationship between Entities

A binary relationship exists when two entities are associated.

http://www.shsu.edu/~csc_tjm/summer2000/cs334/Chapter04/part1/Chap04-97.html
Degree of the Relationship between Entities
A ternary relationship exists when three entities are
associated.
To understand the relationship better or
to define rules around the model, we
should relate two entities and then derive
the third one.

A Student enrolls in a Course.

A Course is handled by a Teacher.

http://www.shsu.edu/~csc_tjm/summer2000/cs334/Chapter04/part1/Chap04-97.html
Cardinality of Association/ Relationship
Cardinality expresses the specific number of instances or occurrences of an entity that can be
linked with the instances of another entity. It is the specific number of instances or occurrences of
an entity that participate in a relationship.

One-to-one (1:1)

• This is where one occurrence of an entity relates to only one occurrence in another entity.
• A one-to-one relationship rarely exists in practice, but it can.
• For example,
• an employee is allocated a company car
• A country has one capital city
• An employee/person is marries to an employee/person
Cardinality of Association
One-to-many (1: M)

• where one occurrence in an entity relates to many occurrences in another entity.


• For example,
• an employee works in one department but a department has many employees.

A cardinality of 1:M involving 2 entities. This is A cardinality of 1:M involving a single entity. This
read as a department has many employee is interpreted as an employee manages many
employees
Cardinality of Association

Many-to-many (M: N)

• This is where many occurrences in an entity relate to many occurrences in another entity.
• For example:
• an employee may work on several projects at the same time and
• a project has a team of many employees.
Cardinality of Association

Many-to-many (M: N)

Room Guest A room can be booked by


many guests. A guest can
Room
m n
Guest book any room.
Gerund or Associative Entity

When is a relationship an entity?


• If the relationship is many-to-many

• If a relationship has attributes, then you may


have an associative entity or gerund (gerund -
is a word that is derived from a verb but that
functions as a noun).

• An EMPLOYEE completes a COURSE of study


and is awarded a certificate. The
CERTIFICATE is the associative entity.

• Note that the relationship is converted to an


entity, it has an identifier attribute, CertNumber.
Enhanced ER Model

As the complexity of data increased in the late 1980s, it


became more and more difficult to use the traditional ER
Model for database modelling.

Hence some improvements or enhancements were made to


the existing ER Model to make it able to handle the complex
applications better. These are generalization, specialization
and aggregation

What is Generalization?

Generalization is a bottom-up approach (parent-child relationship)


wherein low level entities are combined to form a higher level or
generalized entity. The supertype and its subtype(s) maintain
a 1:1 relationship.
The supertype or higher entity contains the shared attributes, while
the subtype or lower entity contains the unique attributes and
inherits its attributes and its relationships from the supertype entity.
Enhanced ER Model

For example, Saving and Current account types entities can be generalized and an entity with


name Account can be created, which covers both.
Enhanced ER Model

What is Specialization?

Specialization is opposite to Generalization.

It is a top-down approach in which one higher


level entity can be broken down into two lower
level entity.

In specialization, a higher level entity may not


have any lower-level entity sets.
Enhanced ER Model
What is Aggregration?

Aggregration is a process when relation between two entities is treated as a single entity.

In the diagram, the relationship between Center and


Course together, is acting as an Entity, which is in
relationship with another entity Visitor.

Now in real world, if a Visitor or a Student visits a


Coaching Center, he/she will never enquire about the
center only or just about the course, rather he/she will
ask enquire about both.
ERD: Chen notation style
ERD: Chen notation style
ERD: Crow’s Foot/Martin/Information Engineering style
ERD: Bachman style
ERD: Notation Style

 A person is born in one and only, denoted by ||, location.


<-- A location is a birthplace of zero or many person
References:

1. https://www.w3schools.in/dbms/
2. https://www.studytonight.com/dbms/overview-of-dbms.php
3. https://www.quackit.com/database/tutorial/
4. https://beginnersbook.com/2015/04/dbms-introduction/
5. https://www.tutorialspoint.com/dbms/index.htm
6. https://www.lucidchart.com/pages/er-diagrams
7. https://www.visual-paradigm.com/support/documents/vpuserguide/3563/
3564/85378_conceptual,l.html
8. https://www.visual-paradigm.com/tutorials/
Thank you!
https://www.visual-paradigm.com/guide/data-modeling/
what-is-entity-relationship-diagram/
Topics:

In this session, we will discuss the following:


• What is a Relational Model?
• Difference between relational and ER Model

References:

1. https://www.youtube.com/watch?v=NlGRINAJXrI
2. https://www.youtube.com/watch?v=PH17p5vORyk&t=51s
3. https://www.youtube.com/watch?v=NvrpuBAMddw
4. https://techdifferences.com/difference-between-e-r-and-relational-model-in-dbms.html
Learning outcomes:

At the end of this session, you should be able to:

1. Define what is a relational model


2. Differentiate between ER model and Relational Model
Introduction

E-R Model and Relational Model


both are the types of Data Model.
Data Model describes a way to
design database at physical, logical
and view level.

The main difference between E-R


Model and Relational Model is that:
1. ER Model is entity specific, it is
the conceptual view of the
database
2. Relational model is table
specific

Basically, the ER model can be


converted to Relational model.
Relational Model

Background:

• Relational Model was developed by Codd in 1970 along with the non-procedural method to query
the data from Relational Model.
• Relational Model represents data and relation among those data in the form of tables. 
• Relational model is also called Record-based Model.

Terms and concepts

• Table is called as relation in Relational Model.


• It can have any number of rows (called tuple) but with definite number of columns (called
attributes).
• Each row/tuple contains the full information about a particular entity in a table.
• The columns in a table are called attributes that describe the properties of a table (relation).
• Each attribute must have a domain that defines the type of value (e.g. integer, character, etc) that
it can store.
• Like E-R Model, keys also plays an important role in a Relational Model as a key uniquely identify
a tuple in a relation or table.
Relational Model

Terms and concepts:

• Relation instance − A finite set of tuples in the relational database system


represents relation instance. Relation instances do not have duplicate tuples.
• Relation schema − A relation schema describes the relation name (table name),
attributes, and their names.
• Relation key − Each row has one or more attributes, known as relation key,
which can identify the row in the relation (table) uniquely.
• Attribute domain − Every attribute has some pre-defined value scope, known as
attribute domain.
Attributes
Entity: Students

StudNum LastName FirstName MidName Gender domain


2015-60077 Bolilan, Mark Anjelo Manbulao M
2015-06703 Cabanalan, Norjan Charls Magno M
2015-12593 Del Campo, Kyle Baroro M
2015-60096 Escoreal, Jerrico Garcia M
2015-60025 Gelacio, Jica Marica Gelacio F
2015-03870 Igbalic, Allein Lyle Layagon M
2015-60081 Latoza, Mary Allen Talip F
Tuples 2015-14456 Lubonting, Seth Roen Bautista M
2015-12328 Luzon, Maria Joselle Victorio F
2015-13192 Orioque, Rhymno Abalos M
2015-11594 Rivas, Carlos Rey Otagan M
2015-11829 Samonte, Jia Maris Pag-Ong F
2015-10442 Semblante, Johannese Kyla Duplito F
2015-10893 Tierra, Almira Faye Dela Torre F
2015-03749 Torrecampo, Marielle Libago F
Physical Data Model

Physical data model represents how the model will be built in the database. A physical
database model shows all table structures, including column name, column data type, column
constraints, primary key, foreign key, and relationships between tables.

The physical data model include:


• Specification all tables and columns.
• Foreign keys are used to identify relationships between tables.
• Denormalization may occur based on user requirements.
• Physical considerations may cause the physical data model to be quite different from the
logical data model.
• Physical data model will be different for different RDBMS (e.g. the data type for a
column may be different between MySQL and SQL Server).
Physical Data Model

The steps for physical data model design are as follows:


1. Convert entities into tables.
2. Convert relationships into foreign keys.
3. Convert attributes into columns.
4. Modify the physical data model based on physical constraints / requirements.

Difference Between the Logical and Physical Data Model

• Entity names are now table names.


• Attributes are now column names.
• Data type for each column is specified. Data types can be different depending on the actual
database being used.
Logical vs Physical Data Model
Data IntegrityData integrity refers to the validity of data, meaning data is consistent and correct. In the data
warehousing field, we frequently hear the term, "Garbage In, Garbage Out." If there is no data integrity in the data
warehouse, any resulting report and analysis will not be useful.
In a data warehouse or a data mart, there are three areas of where data integrity needs to be enforced:
Database level
We can enforce data integrity at the database level. Common ways of enforcing data integrity include:
Referential integrity
The relationship between the primary key of one table and the foreign key of another table must always be
maintained. For example, a primary key cannot be deleted if there is still a foreign key that refers to this primary
key.
Primary key / Unique constraint
Primary keys and the UNIQUE constraint are used to make sure every row in a table can be uniquely identified.
Not NULL vs. NULL-able
For columns identified as NOT NULL, they may not have a NULL value.
Valid Values
Only allowed values are permitted in the database. For example, if a column can only have positive integers, a value
of '-1' cannot be allowed.
ETL process
For each step of the ETL process, data integrity checks should be put in place to ensure that source data is the same
as the data in the destination. Most common checks include record counts or record sums.
Access level
We need to ensure that data is not altered by any unauthorized means either during the ETL process or in the data
warehouse. To do this, there needs to be safeguards against unauthorized access to data (including physical access
Definition of schema: Design of a database is called the schema. Schema is of three types: Physical schema, logical
schema and view schema.
The design of a database at physical level is called physical schema, how the data stored in blocks of storage is
described at this level.
Design of database at logical level is called logical schema, programmers and database administrators work at this
level, at this level data can be described as certain types of data records gets stored in data structures, however the
internal details such as implementation of data structure is hidden at this level (available at physical level).
Design of database at view level is called view schema. This generally describes end user interaction with database
systems.

You might also like