ECC4217 & ECC4207

WEB AND DATABASE

ENTITY-RELATIONSHIP (ER) MODEL
&
RELATIONAL DATA MODEL

Siti Mariam Shafie

[email protected]
 ▪ Understand concepts of data modeling and
its purpose
▪ Learn how relationships between entities
are defined and refined, and how such
Learning relationships are incorporated into the
database design process
Outcomes ▪ Understand the ER data model and translate
to relational data model
▪ Design database using ERD approach
Some Terminology
▪ Database:
❑ A collection of related data (known facts that can be recorded and have an implicit meaning)
▪ Database application:
❑ Some part of the real world about which data is stored in a database.
❑ For example, student grades and transcripts at a university.
▪ Database Management System (DBMS):
❑ A software package/ system to facilitate the creation and maintenance of a computerized database.
❑ Example: MySQL, Oracle, MongoDB
▪ Database Schema
❑ The skeleton structure that represents the logical view of the entire database
▪ Database System:
❑ The DBMS software together with the data and (usually) the applications
 Why Database Design Is Important ?
▪ A database that meets the user
requirements must be carefully
designed
▪ A good database design is
important in ensuring consistent
data, elimination of data
redundancy, efficient execution
of queries and high
performance application

Problem:
Data redundant and data
inconsistence
Database Development Life Cycle
▪ Database design techniques:
❑ ER Diagram
❑ Normalization
Entity-Relationship Data Model
▪ Entity-Relationship model is used in the conceptual
design of a database (conceptual/logical schema)
to view/organize the real-world data (top-down
approach)
▪ ER Model is based on:
❑ Real world entities and their attributes
❑ Relationships among entities A database schema is considered
▪ One-to-many (1:M) the “blueprint” of a database
▪ Many-to-many (M:M)
▪ One-to-one (1:1) which describes how the data may
❑ Their constraints relate to other tables or other data
▪ Keys models. However, the schema
▪
▪
Referential integrity
Domain
does not actually contain data.
▪ It maps well to the relational model (relations or
tables form)
▪ Database schema in the ER model can be
represented in ERD
▪ No industry standard for notation
Components of ER Diagram
 Advantages Disadvantages

▪ The ER model is easy to build. ▪ There is no industry standard

for developing an ER model.
▪ This model is widely used by
database designers for ▪ Information might be lost or
communicating their ideas. hidden in the ER model.

▪ This model can easily convert to ▪ There is no Data Manipulation

any other model like network Language (DML).
model, hierarchical model etc.

▪ It is integrated with the dominant

▪ There is limited relationship
relational model. representation.
Various Notation Styles
▪ Information Engineering style
▪ Chen style
▪ Bachman style
▪ Martin style
▪ Crow’s Foot style
▪ Unified Modeling Language
(UML)
Chen vs Crow’s Foot vs UML Class Diagram
Notation
Example of an E-R Diagram
▪ Rectangles represent entity types
▪ Ellipses represent attributes
▪ Diamonds represent relationship
types
▪ Lines link attributes to entity types
and entity types to relationship
types
▪ Primary key attributes are
underlined
▪ Empty Circle at the end of a line
linking an attribute to an entity
type represents an optional (null)
attribute
▪ Double Ellipses represent multi-
valued attribute
Exercise - Identify entities, attribute and
identifiers
▪ ANG Laboratory has several chemists who work on one or more projects. Chemists also
may use certain kinds of equipment on each project. The organization would like to store
the chemist’s employee identification number, his/her name, up to three phone numbers,
his/her project identification number and the date on which the project started. Every
piece of equipment, the chemist uses, has a serial number and a cost.

Phone# Start-Date
Emp# Proj#

Chemist Project

Serial#
Equipment cost
Exercise – Identify relationships
▪ ANG Laboratory has several chemists who work on one or more projects. Chemists also may use
certain kinds of equipment on each project. The organization would like to store the chemist’s
employee identification number, his/her name, up to three phone numbers, his/her project
identification number and the date on which the project started. Every piece of equipment, the
chemist uses, has a serial number and a cost.
Start-Date
Proj#

Works-On Project
Phone#
Emp#

Chemist
Serial#

Uses Equipment cost

Exercise – Identify Cardinality
▪ The organization would like to store the date the chemist was assigned to the project and the
date an equipment item was assigned to a particular chemist working on a particular project. A
chemist must be assigned at least to one project and one (or more) equipment. Projects and each
equipment must be managed by only one chemist. A project need not be assigned an equipment
and vice versa.
Start-Date
Proj#

1 Works-On N Project
Phone#
Emp#

Chemist

Serial#
1 Uses N Equipment cost
Symbols used in Chen Notation
Strong vs Weak Entity
▪ Weak entity meets two
conditions
❑ Existence-dependent
❑ Primary key partially or
totally derived from
parent entity in
relationship
▪ Database designer
determines whether an
entity is weak based on
business rules
Degree of Relationship
▪ “Degree of Relationship” describes the number of entity participation
❑ Unary (Recursive) Relationship: One instance related to another of the same entity
type
❑ Binary Relationship: Instances of two different entities related to each other
❑ Ternary Relationship: Instances of three different types related to each othe
Exercise: Create ERD based on business rules
Exercises
▪ https://www.csub.edu/~ychoi2/MIS/Assignment/ERD_Practice.p
df
▪ https://www.inf.ed.ac.uk/teaching/courses/inf1/da/2013-
2014/tutorials/inf1-da-13-t1.pdf
▪ https://www.jiscollege.ac.in/pdf/projectcasestudy.pdf
Relational Model
▪ View data logically rather than physically
▪ A relation is a table with columns and rows.
❑ Structural and data independence
❑ Resembles a file conceptually
❑ Contains group of related entities = an entity set
▪ Column name of a relation is called Attribute
▪ Tuple/instance is a single row of a table
▪ Domain is a set of allowable values for every attribute
Relational Database Keys
▪ Super Key
❑ An attribute or group of attributes that uniquely identifies each
row in a table
▪ Candidate key
❑ Minimal Super Key
▪ Primary key
❑ One of the Candidate keys that uniquely identify all other attribute
values in any given row
❑ A primary key cannot be NULL
▪ Composite Key
❑ A primary key comprising of more than one attributes
▪ Alternate/Secondary Key
❑ Rest of all candidate keys
▪ Foreign key
❑ An attribute in a table that is a primary key of another table
❑ A foreign key can have a different name from its primary key
❑ Foreign keys can be null even though primary keys can not
Converting Strong Entity Types
▪ Each entity type becomes a table
▪ Each single-valued attribute
becomes a column
▪ Derived attributes are ignored
▪ Address is a composite attribute
▪ Composite attributes are
▪ Years of service is a derive attribute
represented by components
▪ Skill set is a multi-valued attribute
▪ Multi-valued attributes are ▪ The relational schema:
represented by a separate table
▪ The key attribute of the entity Employee(E#, Name, Door_no, Street, City, Pincode,
Date_of_Joining )
type becomes the primary key of
the table
Emp_Skillset(E#, Skillset)
Employee

EmpCode PK
EmpName
DateofJoining
Skillset
Spouse FK
Employee

EmpCode PK
EmpName
DateofJoining
Skillset
Manager FK
Exercise
Case Study
1. Hospital Management System
2. Railway Reservation
Refer:
DBMS_case_studies_CSE_IVSem.pdf
MahaHospitalManagementCaseStudy.pdf
https://www.guru99.com/er-modeling.html
https://d1wqtxts1xzle7.cloudfront.net/82198039/IJCSE10-02-08-050-libre.pdf?1647358880=&response-
content-
disposition=inline%3B+filename%3DDesign_of_a_Hospital_Based_Database_Syst.pdf&Expires=1731994217&Sig
nature=gycp5amAO4SVCVOEjInjhUKpqvNevJrkXRsL9bTNWvWyatO~AOLgAPkkYiQGuAs8TezN~0NgzH4HSukKHizk
gjfqmol--
bQWeFwOzV0XMQ2RA8eep3anmlNrDjkxvszBwk6woTMcrnrxy0xB6nZaGCpUtpW8CUVAQ4XErkw5Z6jKP1-
44LLPs1jJ4qyp-Peud09zKhI9xRAJqOPhVYbz4Djva9Tqer6XLdtwP8NGVS3M6GsitX4Fa3an7hrG-
nsCZvO0oETP92sUDoaekWMJSDYCv0MD3s-tCeDwWHLzp0PaGfKsfamXqFeHgqaIvAyQIlCikoYhTAjQDp1-
VBpKAQ__&Key-Pair-Id=APKAJLOHF5GGSLRBV4ZA
Exercise
▪ https://my.eng.utah.edu/~cs5530/Lectures/2011-er-relational-
exercise-pharma.pdf

▪ https://courses.washington.edu/infosysb/midTerm2-00-11-08-
Solutions.pdf
References
▪ Coronel, C. & Morris, S., Database Systems: Design, Implementation,
& Management
▪ Connolly, T. & Begg, C., Database Systems: A Practical Approach to
Design, Implementation, and Management
▪ https://www.slideshare.net/ARADHYAYANA/er-diagram-to-relational-
schema-mapping
▪ https://www.slideshare.net/SANKETSENAPATI143/e-r-model-
14464407
The database model in Figure 7.1 reflects
the following business rules:
• A customer may generate many invoices.
Each invoice is generated by one
customer.
• An invoice contains one or more invoice
lines. Each invoice line is associated with
one invoice.
• Each invoice line references one product.
A product may be found in many invoice
lines. (You can sell more than one hammer
to more than one customer.)
• A vendor may supply many products.
Some vendors do not yet supply products.
For example, a vendor list may include
potential vendors.
• If a product is vendor-supplied, it is
supplied by only a single vendor.
• Some products are not supplied by a
vendor. For example, some products may
be
• produced in-house or bought on the open
market.
1. As you can see in Figure 7.1, the database model contains
many tables. However, to illustrate the initial set of data
definition commands, the focus of attention will be the
PRODUCT and VENDOR tables. You will have the opportunity
to use the remaining tables later in this chapter and in the
Problems section.
2. To give you a point of reference for understanding the effect
of the SQL queries, the con- tents of the PRODUCT and
VENDOR tables are listed in Figure 7.2. In the tables, note the
following features, which correspond to the business rules
reflected in the ERD shown in Figure 7.1:
• The VENDOR table contains vendors who are not
referenced in the PRODUCT table. Database
designers note that possibility by saying that
PRODUCT is optional to VENDOR; a vendor may exist
without a reference to a product. You examined such
optional relationships in detail in Chapter 4, Entity
Relationship (ER) Modeling.
• Existing V_CODE values in the PRODUCT table must
(and do) have a match in the VENDOR table to ensure
referential integrity.
• A few products are supplied factory-direct, a few are
made in-house, and a few may have been bought in a
warehouse sale. In other words, a product is not
necessarily supplied by a vendor. Therefore, VENDOR
is optional to PRODUCT.