Module II: Relational

Database & ER Model

 Contents
Relational System, Codd’s Rule, Relational
Model, Optimization, Tables and Views,
Entity, Types of Entity, Weak Entity Attributes
, Entity sets , Entity – Relationship Diagrams.
 Relational Model Concepts
• The relational Model of Data is based on the
concept of a Relation.

• A Relation is a mathematical concept based

on the ideas of sets.

• The strength of the relational approach to

data management comes from the formal
foundation provided by the theory of relations.
 INFORMAL DEFINITIONS
• RELATION: A table of values

– A relation may be thought of as a set of rows.

– A relation may alternately be though of as a set of columns.
– Each row represents a fact that corresponds to a real-world
entity or relationship.
– Each row has a value of an item or set of items that uniquely
identifies that row in the table.
– Sometimes row-ids or sequential numbers are assigned to
identify the rows in the table.
– Each column typically is called by its column name or column
header or attribute name.
 FORMAL DEFINITIONS
• A Relation may be defined in multiple ways.
• The Schema of a Relation: R (A1, A2, .....An)
Relation schema R is defined over attributes A1,
A2, .....An
For Example -
CUSTOMER (Cust-id, Cust-name, Address, Phone#)

Here, CUSTOMER is a relation defined over the four

attributes Cust-id, Cust-name, Address, Phone#, each of
which has a domain or a set of valid values. For
example, the domain of Cust-id is 6 digit numbers.
Example -
 Typical DBMS Functionality
• Define a database : in terms of data types,
structures and constraints
• Construct or Load the Database on a
secondary storage medium
• Manipulating the database : querying,
generating reports, insertions, deletions
and modifications to its content
• Concurrent Processing and Sharing by a
set of users and programs – yet, keeping all
data valid and consistent
 CODD’S RULES
• EF Codd is a computer scientist who first outlined the relational model which now
became the most popular and one and only database model
• Codd Proposed 13 rules (listed from 0 to 12) popularly known as codd’s 12 rules
which are used as a yardstick to test the quality of relational database management
system(RDBMS)
• Rule 0: Foundation rule 
• If a system is said to be an RDBMS then the database should be managed using
only relational capabilities 
• Rule 1: Information rule 
• All the data including metadata must be stored in some cell of the table in  the
form of rows and columns 
• Rule 2: Guaranteed access 
• Each data element in a table must be accessed through a combination of table
name + primary key (row)+ attribute(column) 
• Example : emp+empid+ename,sal
• Strictly the data must not be accessed via a pointer 
 CODD’S RULES

• Rule 3: Systematic treatment of null values

• Null values represent different situations it may be missing data or not
applicable or no value situation.
• Null values must be handled consistently and also primary key must
not be null and any expression on null must give null 
• Rule 4: Active online catalog 
• Database dictionary is a catalog which shows structural description of
the complete database and it must be stored online
• This rule states that a database dictionary must be governed by the
same rules and same query language as used for general database 
• Rule 5: Powerful and well-structured language 
• The database should be accessible through a  language which supports
definition, manipulation and all transaction management activities,
such a language is called structured language 
• For example, SQL, if database uses a different  language for data
access and manipulation then it is a violation of the rule 
• Rule 6: View updation rule 
• Difference views created for different purposes should be automatically updated by the
system itself 
• Rule 7: Relational level operation 
• Operations like  insert, delete and update operations must be supported at each level
of relation even though it might be a nested relation or a complex relation 
• Set operations like union, intersection, minus must be supported 
• Rule 8: Physical data independence 
• Any change in the physical location of the table should not reflect the change at the
application level 
• Example: If you rename or move a file from one disk to another then it should not affect the
application 
• Rule 9: Logical data independence 
• If there are any changes done to the logical structure of the database table, then users
view of data should not be changed
• If  the table is split into two tables, then a new view should give result as the join of
these two tables but this rule is very difficult to satisfy 
• Rule 10: Integrity  independence 
• Database table should design itself on integrity rather than using external
programs.
• It should use primary keys, check constants triggers, etc which makes our DBMS
independent of the front end application 
• Rule 11: Distribution Independence 
• Data distribution over various geographical locations over a network should not reflect
the end-user i.e  you should feel that all the data is stored in a single place 
• This rule laid the foundation for the distributed database
• Rule 12 Non-Subversion Rule 
• Any access given to the data that is present in the lowest level must not give a
chance to authenticate constraints and change data ,this can be achieved through
some kind of encryption techniques
ER Model is used to model the logical view of the system from data
perspective which consists of these components:
Entity, Entity Type, Entity Set –
An Entity may be an object with a physical existence – a particular person,
car, house, or employee – or it may be an object with a conceptual existence
– a company, a job, or a university course.
An Entity is an object of Entity Type and set of all entities is called as entity
set. e.g.; E1 is an entity having Entity Type Student and set of all students is
called Entity Set. In ER diagram, Entity Type is represented as:
Attribute(s):
Attributes are the properties which define the entity type. For example, Roll_No,
Name, DOB, Age, Address, Mobile_No are the attributes which defines entity
type Student. In ER diagram, attribute is represented by an oval.

Key Attribute –
The attribute which uniquely identifies each entity in the entity set is called key
attribute.For example, Roll_No will be unique for each student. In ER diagram,
key attribute is represented by an oval with underlying lines.
Composite Attribute –
An attribute composed of many other attribute is called as composite attribute.
For example, Address attribute of student Entity type consists of Street, City,
State, and Country. In ER diagram, composite attribute is represented by an oval
comprising of ovals.

Multivalued Attribute –
An attribute consisting more than one value for a given entity. For example,
Phone_No (can be more than one for a given student). In ER diagram,
multivalued attribute is represented by double oval.
Derived Attribute –
An attribute which can be derived from other attributes of the entity type is
known as derived attribute. e.g.; Age (can be derived from DOB). In ER diagram,
derived attribute is represented by dashed oval.

The complete entity type Student with its attributes can be

represented as:
Relationship Type and Relationship Set:
A relationship type represents the association between entity types. For
example,‘Enrolled in’ is a relationship type that exists between entity type Student
and Course. In ER diagram, relationship type is represented by a diamond and
connecting the entities with lines.

Degree of a relationship set:

The number of different entity sets participating in a relationship set is called as
degree of a relationship set.
Unary Relationship –
When there is only ONE entity set participating in a relation, the relationship is
called as unary relationship. For example, one person is married to only one
person.
Binary Relationship –
When there are TWO entities set participating in a relation, the relationship is
called as binary relationship.For example, Student is enrolled in Course.

n-ary Relationship –
When there are n entities set participating in a relation, the relationship is
called as n-ary relationship.
Cardinality:
The number of times an entity of an entity set participates in a
relationship set is known as cardinality. Cardinality can be of different types:
One to one – When each entity in each entity set can take part only once in the
relationship, the cardinality is one to one. Let us assume that a male can marry to
one female and a female can marry to one male. So the relationship will be one to
one.

Many to one – When entities in one entity set can take part only once in the
relationship set and entities in other entity set can take part more than once in the
relationship set, cardinality is many to one. Let us assume that a student can take
only one course but one course can be taken by many students. So the cardinality
will be n to 1. It means that for one course there can be n students but for one
student, there will be only one course.
Many to many – When entities in all entity sets can take part more than once in
the relationship cardinality is many to many. Let us assume that a student can
take more than one course and one course can be taken by many students. So
the relationship will be many to many.
Participation Constraint:
Participation Constraint is applied on the entity participating in the relationship set.
1.Total Participation – Each entity in the entity set must participate in the
relationship. If each student must enroll in a course, the participation of student
will be total. Total participation is shown by double line in ER diagram.
2.Partial Participation – The entity in the entity set may or may NOT participate in
the relationship. If some courses are not enrolled by any of the student, the
participation of course will be partial.The diagram depicts the ‘Enrolled in’
relationship set with Student Entity set having total participation and Course
Entity set having partial participation.
Weak Entity Type and Identifying Relationship:
As discussed before, an entity type has a key attribute which uniquely identifies
each entity in the entity set. But there exists some entity type for which key
attribute can’t be defined. These are called Weak Entity type.
For 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.
 Definitions (con’t)
• A key attribute of an entity type is one
whose value uniquely identifies an entity of
that type.
• A combination of attributes may form a
composite key.
• If there is no applicable value for an
attribute that attribute is set to a null value.
 Entity Type / Entity Set

Entity Type (Intension): EMPLOYEE

Attributes: Name, Age, Salary

Entity Set (Extension): e1 = (John Smith, 55, 80000)

e2 = (Joe Doe, 40, 20000)
e3 = (Jane Doe, 27, 30000)
.
.
.
 Attributes
• Attributes can be
– composite / simple (atomic)
– single-valued / multivalued
– stored / derived
– key / nonkey.
 EMPLOYEE
Name, SSN, Sex, Address, Salary, Birthdate, Department,
Supervisor, {Works on ( Project, Hours)}

WORKS_FOR
N 1
Name SSN . . .

EMPLOYEE DEPARTMENT

Relationship instances of WORKS_FOR:

{(KV, CS), (Pan, EE), . . .}
ER Diagram for COMPANY Database
 Relationship Type
• A relationship type R among n entity types
E1,…,En is a set of relationship instances
ri, where each ri associates n entities (e1,
…,en), s.t. each ej  Ej. Informally, a
relationship instance is an association of
entities, with exactly one entity from each
participating entity type.
 Relationship Type (con’t)
• The degree n of a relationship type is the
number of participating entity types.
• In the ER model relationships are
explicitly represented.
 Entity Roles
• Each entity type in a relationship type
plays a particular role that is described by
a role name. Role names are especially
important in recursive relationship types
where the same entity participates in
more than one role:
Employee
Supervisor 1 N Supervisee

Supervision
 Weak Entity Type
• A weak entity type is one without any key
attributes of its own. Entities belonging to a
weak entity type are identified by being
related to another entity type ( called
identifying owner) through a relationship
type ( called identifying relationship), in
combination with values of a set of its own
attributes (called partial key). A weak entity
type has total participation constraint w.r.t.
its identifying relationship.
 Relationship Attributes
• Relationship types can have attributes as
well. in case of 1:1 or 1:N relationships,
attributes can be migrated to one of the
participating entity types.
 Structural Constraints
• Structural constraints of a relationship
type:
– Cardinality ratio: Limits the number of
relationship instances an entity can participate
in, eg. 1:1, 1:N, M:N
– Participation constraint: If each entity of
an entity type is required to participate in
some instance of a relationship type, then that
participation is total; otherwise, it is partial.
 Structural Constraint Min, Max
• A more complete specification of the
structural constraint on a relationship type
can be given by the integer pair (min,
max), which means an entity must
participate in at least min and at most max
relationship instances.
 A ternary relationship generally represents
more information than 3 binary relationships
The ER Model has the power of expressing database entities in a conceptual
hierarchical manner. As the hierarchy goes up, it generalizes the view of
entities, and as we go deep in the hierarchy, it gives us the detail of every entity
included.
Going up in this structure is called generalization, where entities are clubbed
together to represent a more generalized view. 
Specialization is the opposite of generalization. In specialization, a group of
entities is divided into sub-groups based on their characteristics. Take a
group ‘Person’ for example. A person has name, date of birth, gender, etc.
These properties are common in all persons, human beings. But in a
company, persons can be identified as employee, employer, customer, or
vendor, based on what role they play in the company.
The details of entities are generally hidden from the user; this process known
as abstraction.
Inheritance is an important feature of Generalization and Specialization. It allows
lower-level entities to inherit the attributes of higher-level entities.

For example, the attributes of a Person class such as name, age, and gender
can be inherited by lower-level entities such as Student or Teacher.
Aggregation
In aggregation, the relation between two entities is treated as a single entity. In aggregation,
relationship with its corresponding entities is aggregated into a higher level entity.
For example: Center entity offers the Course entity act as a single entity in the relationship
which is in a relationship with another entity visitor. In the real world, if a visitor visits a
coaching center then he will never enquiry about the Course only or just about the Center
instead he will ask the enquiry about both.
 Steps to build ER Model
• Identify the entities and its types (gen. and spec., if
required)
• Identify the attributes associated with each entity and
the types of attributes
• Identify the relationship and its type between the
entities
• Identify the cardinality ratio/structural constraint
• Identify the type of participation
• Finally, represent the above steps through
appropriate symbols to make an ER model/diagram