Revision 1 - Relational Database Concepts

• ER Model – Basic Concepts

• ER Model to Relational Model

https://forms.gle/wtmtdYHdWnftcd5r6
 ER Model (Conceptual View of a Database)
• ER Model: It works around real world entities and the associations among them.
• Entity (a real world object)
• For example, in a school database, students, teachers, classes, and courses
offered can be considered as entities.
• All the entities have some attributes or properties that give them their identity.
• An entity set is a collection of similar types of entities.
• Attributes
• All attributes have values. For example, a student entity may have name, class,
and age as attributes.
• There exists a domain or range of values or value set that can be assigned to
attributes. For example, a student's name cannot be a numeric value. It has to
be alphabetic. A student's age cannot be negative, etc.
 Types of attributes

• Simple and Composite attributes:

• Simple attributes are atomic values, which cannot be divided further. For example, a
student's phone number is an atomic value of 10 digits. Balance, Account Number are
also simple attributes.
• Composite attributes are made of more than one simple attribute. For example, a
student's complete name may have first_name and last_name. Address may comprise of
house no, street, city, area code.
• Single- valued and Multi-valued attributes:
• The attribute for which we have a single value for each entity is called single valued
attribute. For example, age, loan_no are single valued.
• The attributes for which we have a set of attributes for a particular entity is called multi
valued attributes. For example, phone_no, dependent_name.
• Derived attributes:
• Derived attributes are the attributes that do not exist in the physical database, but their
values are derived from other attributes present in the database
• For example, age can be derived from data_of_birth.
E-R Diagram With Composite, Multivalued, and R Diagram
With Composite, Multivalued, and Derived Attributes
Relationship and Relationship Set
• A relationship is an association among several entities.
• For example, an employee works_at a department, a student enrolls in a
course. Here, Works_at and Enrolls and depositor are called relationships,
• Depositor and Borrower are also relationship between Customer and Account
entities and Customer and Loan entities respectively.
• Relationship Set
• A set of relationships of similar type is called a relationship set. Like entities, a
relationship too can have attributes. These attributes are called descriptive
attributes.
• For instance, the depositor relationship set between entity sets customer and
account may have the attribute access-date.
Relationship and Relationship Set contd…
Relationship set with attributes
Roles
• Entity sets of a relationship
need not be distinct
• The labels “manager”and
“worker”are called roles;
they specify how employee
entities interact via the
works_for relationship set
• Roles are indicated in E-R
diagrams by labeling the
lines that connect diamonds
to rectangles
Degree of Relationship
• The number of participating entities in a relationship defines the degree of
the relationship.
• Binary (Degree-2):
• Relationship sets that involve two entity sets are binary(or degree two). Generally,
most relationship sets in a database system are binary.
• Ternary( Degree -3):
• Relationship sets may involve more than two entity sets.
• Example: Suppose employees of a bank may have jobs (responsibilities) at multiple
branches, with different jobs at different branches. Then there is a ternary
relationship set between entity sets employee, job, and branch.
• Relationships between more than two entity sets are rare. Most relationships are
binary.
Mapping Cardinalities / Cardinality Ratio
• Cardinality express the number of entities (in one entity set) to which
another entity (in another entity set) can be associated via a
relationship set.
• Most useful in describing binary relationship sets.
• For a binary relationship set the mapping cardinality must be one of
the following types:
• One to one [1:1]
• One to many [1:n]
• Many to one [m:1]
• Many to many [m:n]
 Mapping Cardinalities contd..
• One-to-One:
• One entity from entity set A can be associated with at most one entity of
entity set B and vice versa.
• For example: An employee is allotted an organization vehicle, which might
solely be driven by that employee. Therefore, there’s a one-to-one
relationship between employee and company vehicle.
Mapping Cardinalities contd..
• One-to-Many:
• One entity from entity set A can be associated with more than one entities of
entity set B, however an entity from entity set B can be associated with at
most one entity.
• For example, each customer can have many sales orders but an order can be
associated with only one customer.
• Example, An employee works in one department however a department has
several employees. Therefore, there’s a one-to-many relationship between
department and employee.
 Example- One-to-Many

In this example the primary key field in the Customers table, Customer ID, is designed to contain unique
values. The foreign key field in the Orders table, Customer ID, is designed to allow multiple instances of
the same value.
Mapping Cardinalities contd..
• Many-to-One: (vice versa to One-to-Many)
• More than one entities from entity set A can be associated with at most one
entity of entity set B, however an entity from entity set B can be associated
with more than one entity from entity set A.
• It depends on which side of the relationship the entity is present on.

For example, if one department can employ for several employees then,
department to employee is a one to many relationship (1 department
employs many employees), while employee to department relationship is
many to one (many employees work in one department).
Mapping Cardinalities contd..
• Many-to-Many
• One entity from A can be associated with more than one entity from B and
vice versa.
• Many-to-Many relationship can be seen between project and employee. An
employee works on many projects and at the same time, a project has several
employees.
Participation Constraints
• Total Participation: the participation of an entity set E in a relationship
set R is said to be total if every entity in E participates in atleat one
relationship in R.
• For example, participation of Loan in the relationship Borrower is total. That
means, each entry in loan is associated with any one or more entries in
customer table.
• Partial Participation: Total Participation: the participation of an entity
set E in a relationship set R is said to be partial if only some entities in
E participates in relationship R.
• For example, participation of Customer in the relationship Borrower is partial.
That means, every customer has not taken loan.
Weak Entity Set
• An entity set that does not have a primary key is referred to asa weak entity set.
• The existence of a weak entity set depends on the existence of a identifying entity set
• It must relate to the identifying entity set via a total, one-to-many relationship set from the
identifying to the weak entity set.
• The discriminator(or partial key)of a weak entity set is the set of attributes that
distinguishes among all the entities of a weak entity set.
• The primary key of a weak entity set is formed by the primary key of the strong entity set on
which the weak entity set is existence dependent, plus the weak entity set’s discriminator.
• Example: A company may store the information of dependants (Parents, Children, Spouse)
of an Employee. But the dependents don’t have existence without the employee. So
Dependent will be weak entity type and Employee will be Identifying Entity type for
Dependant.
Example - Weak Entity Set

• payment_number –discriminator of the payment entity set

• Primary key for payment –(loan_number, payment_number)
• Note – Weak entity always has total participation but Strong entity may not have total participation.
Symbols Used in E-R Notation
ER diagram for Banking Enterprise
Relational DataModel
• Tables: In relational data model, relations are saved in the format of
Tables. This format stores the relation among entities. A table has rows
and columns, where rows represent records and columns represent the
attributes.
• Tuple: A single row of a table, which contains a single record for that
relation is called a tuple.
• Constraints: Every relation has some conditions that must hold for it to be a valid
relation.
• Key constraints
• Domain constraints
• Referential integrity constraints
Constraints:
• Key Constraints/Entity Constraints:
• There must be at least one minimal subset of attributes in the relation, which
can identify a tuple uniquely.
• This minimal subset of attributes is called key for that relation.
• If there are more than one such minimal subsets, these are called candidate
keys
• Key constraints force that:
• in a relation with a key attribute, no two tuples can have identical values for key
attributes.
• a key attribute cannot have NULL values.
Constraints:
• Domain Constraints:
• It is a set of permitted values in one column or attribute
• Every attribute is bound to have a specific range of values.
• For example, age can only be a positive integer and can not be less than zero, and telephone
numbers must contain numbers.
• Referential Integrity Constraints:
• Referential integrity requires that a foreign key must have a matching primary key or it must
be null.
• Examples of referential integrity constraint in the Customer/Order database of the Company:
• Customer(CustID, CustName)
• Order(OrderID, CustID, OrderDate)
• To ensure that there are no orphan records, we need to enforce referential
integrity. An orphan record is one whose foreign key FK value is not found in the
corresponding entity – the entity where the PK is located.
Mapping E-R to Relational Model
• Mapping Regular Entities to Tables:
• Composite attributes: Composite attributes are flattened out by creating a
separate attribute for each component attribute
• Example: given entity set customer with composite attribute name with component
attributes first_name and last_namethe schema corresponding to the entity set has two
attributes name.first_name and name.last_name
• Multivalued attributes: A multivalued attribute of an entity E is represented by
a separate schema with a foreign key taken from E.
• Example: Multivalued attribute dependent_names of employee is represented by a
schema: employee_dependent_names= (employee_id, dname)
• Each value of the multivalued attribute maps to a separate tuple in new schema.
• For example, an employee entity with primary key 123-45-6789 and dependents
Jack and Jane maps to two tuples: (123-45-6789 , Jack) and (123-45-6789 , Jane) in
the new schema.
Example – Mapping of Composite attribute
Example – Mapping of Multivalued Attributes

• Multivalued attribute becomes a separate relation with foreign key

• 1 – to – many relationship between original entity and new relation
Mapping of Weak Entities
• Weak entities become a separate table with a foreign key taken from
the strong entity.
• Primary key is composed of
• the discriminator of the weak entity plus
• the primary key from the strong entity
• For example, payment = ( loan_number, payment_number,
payment_date, payment_amount)
Example- Mapping of Weak Entities
• Weak Entity Dependant
Example- Mapping of Weak Entities
• Relations resulting from weak entity:
Mapping Binary Relationships
• One-to-Many - Primary key on the one side becomes a foreign key on
the many side
• Many-to-Many - Create a new relation with the primary keys of the
two entities as its primary key
• One-to-One - Primary key on the mandatory side becomes a foreign
key on the optional side
Example: Mapping a 1:M relationship
Example : Mapping an M:N relationship

The Supplies relationship will need to

become a separate relation
Three resulting Relations
Example : Mapping a binary 1:1 relationship
Mapping Unary/Recursive Relationships
• A unary relationship is a relationship between the instances
of one entity type.
• One-to-Many - Recursive foreign key in the same relation
• Many-to-Many - Two relations:
• One for the entity type
• One for an associative relation in which the primary key
has two attributes, both taken from the primary key of the
entity
Mapping a unary 1:N relationship
Mapping a unary M:N relationship

The attribute Quantity indicates the no. of each

components that is contained in a given
assembly.

Bill of Materials: A bill of materials (BOM) is a comprehensive inventory of the

raw materials, assemblies, subassemblies, parts and components, as well as the
quantities of each, needed to manufacture a product.
Example: Mapping a unary M:N relationship

Primary Key
Item_No Name Unit Cost
MX300 Mountain Bike 75,000
Item Table
TR425 Tandem Bike 80,000

HX100 Handlebars 1000

TX100 Transmission System 2000

WX240 Wheels 2500

BR450 Brakes 1500
BR250 Brakes 2 1200
DX500 Derailer 900

FK FK
Item_No Component_No Quantity
Component
MX300 HX100 1 Table
MX300 TX100 1
MX300 WX240 2
TX100 BR450 2
TX100 DX500 1
Unary M:N relationship
ITEM and COMPONENT Relations with sample data
Exercise