ER-MODEL

Data model:
The data model describes the structure of a database. It is a collection of conceptual tools
for describing data, data relationships and consistency constraints and various types of
data model such as
1. Object based logical model
2. Record based logical model
3. Physical model

Types of data model:

1. Object based logical model
a. ER-model
b. Functional model
c. Object oriented model
d. Semantic model
2. Record based logical model
a. Hierarchical database model
b. Network model
c. Relational model
3. Physical model

Entity Relationship Model

The entity-relationship data model perceives the real world as consisting of basic objects,
called entities and relationships among these objects. It was developed to facilitate data
base design by allowing specification of an enterprise schema which represents the
overall logical structure of a data base.
Main features of ER-MODEL:
 Entity relationship model is a high level conceptual model
 It allows us to describe the data involved in a real world enterprise in terms of
objects and their relationships.
 It is widely used to develop an initial design of a database
 It provides a set of useful concepts that make it convenient for a developer to
move from a baseid set of information to a detailed and description of information
that can be easily implemented in a database system
 It describes data as a collection of entities, relationships and attributes.
Basic concepts:

The E-R data model employs three basic notions : entity sets, relationship sets and
attributes.
Entity sets:

An entity is a “thing” or “object” in the real world that is distinguishable from all other
objects. For example, each person in an enterprise is an entity. An entity has a set
properties and the values for some set of properties may uniquely identify an entity.
BOOK is entity and its properties(calles as attributes) bookcode, booktitle, price etc .
An entity set is a set of entities of the same type that share the same properties, or
attributes. The set of all persons who are customers at a given bank, for example, can be
defined as the entity set customer.
Attributes:

An entity is represented by a set of attributes. Attributes are descriptive properties

possessed by each member of an entity set.

Customer is an entity and its attributes are customerid, custmername, custaddress etc.

An attribute as used in the E-R model , can be characterized by the following attribute
types.
a) Simple and composite attribute:

simple attributes are the attributes which can’t be divided into sub
parts eg: customerid,empno
composite attributes are the attributes which can be divided into
subparts. eg: name consisting of first name, middle name, last name
address consisting of city,pincode,state
b) single-valued and multi-valued attribute:
The attribute having unique value is single –valued attribute
eg: empno,customerid,regdno etc.
The attribute having more than one value is multi-valued attribute
eg: phone-no, dependent name, vehicle

c) Derived Attribute:

The values for this type of attribute can be derived from the values of existing
attributes
eg: age which can be derived from (currentdate-birthdate)
experience_in_year can be calculated as (currentdate-
joindate)

d) NULL valued attribute:

The attribute value which is unknown to user is called NULL valued attribute.
Relationship sets:
A relationship is an association among several entities.
A relationship set is a set of relationships of the same type. Formally, it is a mathematical
relation on n>=2 entity sets. If E1,E2…En are entity sets, then a relation ship set R is a
subset of
{(e1,e2,…en)|e1Є E1,e2 Є E2..,en Є En}
where (e1,e2,…en) is a relation ship.

customer borro loan

Consider the two entity sets customer and loan. We define the relationship set borrow to
denote the association between customers and the bank loans that the customers have.

Mapping Cardinalities:
Mapping cardinalities or cardinality ratios, express the number of entities to which
another entity can be associated via a relationship set.
Mapping cardinalities are most useful in describing binary relationship sets, although
they can contribute to the description of relationship sets that involve more than two
entity sets.
For a binary relationship set R between entity sets A and B, the mapping cardinalities
must be one of the following:
one to one:

An entity in A is associated with at most one entity in B, and an entity in B is associated

with at most one entity in A.
Eg: relationship between college and principal
11 11
college has principal

One to many:

An entity in A is associated with any number of entities in B. An entity in B is associated

with at the most one entity in A.

Eg: Relationship between department and faculty

11 M1
Department Works Faculty
in
Many to one:
An entity in A is associated with at most one entity in B. An entity in B is associated with
any number in A.

1□ M□
Course Teach Faculty
es

Many –to-many:
Entities in A and B are associated with any number of entities from each other.

1□ M□
Customer Depos Account

More about entities and Relationship:

Recursive relationships:
When the same entity type participates more than once in a relationship type in different
roles, the relationship types are called recursive relationships.
Participation constraints:
The participation constraints specify whether the existence of any entity depends on its
being related to another entity via the relationship. There are two types of participation
constraints
Total :
.When all the entities from an entity set participate in a relationship type , is called total
participation. For example, the participation of the entity set student on the relationship
set must ‘opts’ is said to be total because every student enrolled must opt for a course.
Partial:
When it is not necessary for all the entities from an entity set to particapte ion a
relationship type, it is called participation. For example, the participation of the entity set
student in ‘represents’ is partial, since not every student in a class is a class
representative.
Weak Entity:
Entity types that do not contain any key attribute, and hence can not be identified
independently are called weak entity types. A weak entity can be identified by uniquely
only by considering some of its attributes in conjunction with the primary key attribute of
another entity, which is called the identifying owner entity.
Generally a partial key is attached to a weak entity type that is used for unique
identification of weak entities related to a particular owner type. The following
restrictions must hold:
 The owner entity set and the weak entity set must participate in one to may
relationship set. This relationship set is called the identifying relationship set of
the weak entity set.
 The weak entity set must have total participation in the identifying relationship.
Example:
Consider the entity type dependent related to employee entity, which is used to keep
track of the dependents of each employee. The attributes of dependents are : name
,birthrate, sex and relationship. Each employee entity set is said to its own the
dependent entities that are related to it. How ever, not that the ‘dependent’ entity does
not exist of its own., it is dependent on the employee entity. In other words we can
say that in case an employee leaves the organization all dependents related to without
the entity ‘employee’. Thus it is a weak entity.

Keys:
Super key:
A super key is a set of one or more attributes that taken collectively, allow us to
identify uniquely an entity in the entity set.
For example , customer-id,(cname,customer-id),(cname,telno)
Candidate key:
In a relation R, a candidate key for R is a subset of the set of attributes of R, which
have the following properties:
 Uniqueness: no two distinct tuples in R have the same values for
the candidate key
 Irreducible: No proper subset of the candidate key has the
uniqueness property that is the candidate key.
Eg: (cname,telno)
Primary key:
The primary key is the candidate key that is chosen by the database designer as the
principal means of identifying entities with in an entity set. The remaining candidate
keys if any, are called alternate key.
ER-DIAGRAM:

The overall logical structure of a database using ER-model graphically with the help
of an ER-diagram.
Symbols use ER- diagram:

entity

Weak entity
composite attribute
attribute
Relationship

Multi valued attribute

Derived attribute Identifying

Relationship
Key attribute

1 m
1 1

One-to -one One-to -

many m 1
m n

many-to -one many-to -many

Total participation Partial participation

Advanced ER-diagram:

Abstraction is the simplification mechanism used to hide superfluous details of a set of

objects. It allows one to concentrate on the properties that are of interest to the
application.
There are two main abstraction mechanism used to model information:
Generalization and specialization:
. Generalization is the abstracting process of viewing set of objects as a single
general class by concentrating on the general characteristics of the constituent sets while
suppressing or ignoring their differences. It is the union of a number of lower-level entity
types for the purpose of producing a higher-level entity type. For instance, student is a
generalization of graduate or undergraduate, full-time or part-time students. Similarly,
employee is generalization of the classes of objects cook, waiter, and cashier.
Generalization is an IS_A relationship; therefore, manager IS_AN employee, cook
IS_AN employee, waiter IS_AN employee, and so forth.
Specialization is the abstracting process of introducing new characteristics to an
existing class of objects to create one or more new classes of objects. This involves
taking a higher-level, and using additional characteristics, generating lower-level entities.
The lower-level entities also inherits the, characteristics of the higher-level entity. In
applying the characteristics size to car we can create a full-size, mid-size, compact or
subcompact car. Specialization may be seen as the reverse process of generalization
addition specific properties are introduced at a lower level in a hierarchy of objects.
 empno name
dob

employee
Generalization Specialization

Is Is
degree degree

Full time Part-time

employee employee

Is Is Is Is

faculty staff teaching casual

degree Intrest Intrest Classificatio hourrat

EMPLOYEE(empno,name,dob) Faculty(empno,degree,intrest)
FULL_TIME_EMPLOYEE(empno,sala Staff(empno,hour-rate)
ry) Teaching (empno,stipend)
PART_TIME_EMPLOYEE(empno,type)
Aggregation:
Aggregation is the process of compiling information on an object, there by abstracting a
higher level object. In this manner, the entity person is derived by aggregating the
characteristics of name, address, ssn. Another form of the aggregation is abstracting a
relationship objects and viewing the relationship as an object.
 Job

Branch
Employe
Works
on

Manag

Manager
ER- Diagram For College Database

rollno name addres

coursei cname duratio

Student Course
opts
N 1
1
M

has enroll Taug

ed
1 N
N 1 Work N fid

gaurdian Department dno Faculty addre

Head
name dnam 1 name sal
1
addres relationship

Date

Conversion of ER-diagram to relational database

Conversion of entity sets:
1. For each strong entity type E in the ER diagram, we create a relation R containing
all the single attributes of E. The primary key of the relation R will be one of the
key attribute of R.

STUDENT(rollno (primary key),name, address)

FACULTY(id(primary key),name ,address, salary)
COURSE(course-id,(primary key),course_name,duration)
DEPARTMENT(dno(primary key),dname)
 2. for each weak entity type W in the ER diagram, we create another relation R that
contains all simple attributes of W. If E is an owner entity of W then key attribute
of E is also include In R. This key attribute of R is set as a foreign key attribute of
R. Now the combination of primary key attribute of owner entity type and partial
key of the weak entity type will form the key of the weak entity type

GUARDIAN((rollno,name) (primary key),address,relationship)

Conversion of relationship sets:

Binary Relationships:
 One-to-one relationship:
For each 1:1 relationship type R in the ER-diagram involving two entities E1 and
E2 we choose one of entities(say E1) preferably with total participation and add
primary key attribute of another E as a foreign key attribute in the table of
entity(E1). We will also include all the simple attributes of relationship type R in
E1 if any, For example, the department relationship has been extended tp include
head-id and attribute of the relationship.

DEPARTMENT(D_NO,D_NAME,HEAD_ID,DATE_FROM)
 One-to-many relationship:
For each 1:n relationship type R involving two entities E1 and E2, we identify the
entity type (say E1) at the n-side of the relationship type R and include primary
key of the entity on the other side of the relation (say E2) as a foreign key
attribute in the table of E1. We include all simple attribute(or simple components
of a composite attribute of R(if any) in he table E1)
For example:
The works in relationship between the DEPARTMENT and FACULTY. For this
relationship choose the entity at N side, i.e, FACULTY and add primary key
attribute of another entity DEPARTMENT, ie, DNO as a foreign key attribute in
FACULTY.

FACULTY(CONSTAINS WORKS_IN
RELATIOSHIP)
(ID,NAME,ADDRESS,BASIC_SAL,DNO)

 Many-to-many relationship:

For each m:n relationship type R, we create a new table (say S) to represent R,
We also include the primary key attributes of both the participating entity types
as a foreign key attribute in s. Any simple attributes of the m:n relationship
type(or simple components as a composite attribute) is also included as attributes
of S. For example:
The M:n relationship taught-by between entities COURSE; and FACULTY shod
be represented as a new table. The structure of the table will include primary key
of COURSE and primary key of FACULTY entities.
TAUGHT-BY(ID (primary key of FACULTY table),course-id (primary key of
COURSE table)

 N-ary relationship:

For each n-anry relationship type R where n>2, we create a new table S to
represent R, We include as foreign key attributes in s the primary keys of the
relations that represent the participating entity types. We also include any simple
attributes of the n-ary relationship type(or simple components of complete
attribute) as attributes of S. The primary key of S is usually a combination of all
the foreign keys that reference the relations representing the participating entity
types.

Customer Loan

Loan -
sanctio

Employee
LOAN-SANCTION(cusomet-id ,loanno,empno ,sancdate,loan_amount)
 Multi-valued attributes:

For each multivalued attribute ‘A’, we create a new relation R that includes an
attribute corresponding to plus the primary key attributes k of the relation that
represents the entity type or relationship that has as an attribute. The primary key
of R is then combination of A and k.
For example, if a STUDENT entity has rollno,name and phone number where
phone numer is a multivalued attribute the we will create table
PHONE(rollno,phoneno) where primary key is the combination,In the STUDENT
table we need not have phone number, instead if can be simply (rollno,name)
only.
PHONE(rollno,phoneno)
 name
Account_n
Account branch

generalisation
specialisation
Is-a

intrest charges

Saving Current

 Converting Generalisation /specification hierarchy to tables:

A simple rule for conversion may be to decompose all the specialized entities into
table in case they are disjoint, for example, for the figure we can create the two
table as:
Account(account_no,name,branch,balance)
Saving account(account-no,intrest)
Current_account(account-no,charges)
Record Based Logical Model

Hierarchical Model:

 A hierarchical database consists of a collection of records which are connected to

one another through links.
 a record is a collection of fields, each of which contains only one data value.
 A link is an association between precisely two records.
 The hierarchical model differs from the network model in that the records are
organized as collections of trees rather than as arbitrary graphs.
Tree-Structure Diagrams:
 The schema for a hierarchical database consists of
o boxes, which correspond to record types
o lines, which correspond to links
 Record types are organized in the form of a rooted tree.
o No cycles in the underlying graph.
o Relationships formed in the graph must be such that only
one-to-many or one-to-one relationships exist between a parent and a
child.

Database schema is represented as a collection of tree-structure diagrams.

 single instance of a database tree
 The root of this tree is a dummy node
 The children of that node are actual instances of the
appropriate record type
When transforming E-R diagrams to corresponding tree-structure diagrams, we must
ensure that the resulting diagrams are in the form of rooted trees.

Single Relationships:

 Example E-R diagram with two entity sets, customer and account, related through
a binary, one-to-many relationship depositor.
 Corresponding tree-structure diagram has
o the record type customer with three fields: customer-name,
customer- street, and customer-city.
o the record type account with two fields: account-number and balance
o the link depositor, with an arrow pointing to customer

 If the relationship depositor is one to one, then the link depositor has two arrows.
 Only one-to-many and one-to-one relationships can be directly represented in the
hierarchical mode.

Transforming Many-To-Many Relationships:

 Must consider the type of queries expected and the degree to which the database
schema fits the given E-R diagram.
 In all versions of this transformation, the underlying database tree (or trees) will
have replicated records.

 Create two tree-structure diagrams, T1, with the root customer, and T2, with
the root account.
 In T1, create depositor, a many-to-one link from account to customer.
 In T2, create account-customer, a many-to-one link from customer to account.
Network Model:
 Data are represented by collections of records.
o similar to an entity in the E-R model
o Records and their fields are represented as record type
 type customer = record type account = record type
customer-name: string; account-number: integer;
customer-street: string; balance: integer;
customer-city: string;
 end end
 Relationships among data are represented by links
o similar to a restricted (binary) form of an E-R relationship
o restrictions on links depend on whether the relationship is many-many,
many-to-one, or one-to-one.
Data-Structure Diagrams:
 Schema representing the design of a network database.
 A data-structure diagram consists of two basic components:
o Boxes, which correspond to record types.
o Lines, which correspond to links.
 Specifies the overall logical structure of the database.

For every E-R diagram, there is a corresponding data-structure diagram.

Since a link cannot contain any data value, represent an E-R relationship with
attributes with a new record type and links.

To represent an E-R relationship of degree 3 or higher, connect the participating

record types through a new record type that is linked directly to each of the original
record types.

1. Replace entity sets account, customer, and branch with record types
account, customer, and branch, respectively.
2. Create a new record type Rlink (referred to as a dummy record type).
3. Create the following many-to-one links:
o CustRlink from Rlink record type to customer record type
o AcctRlnk from Rlink record type to account record type
o BrncRlnk from Rlink record type to branch record type
RELATIONAL MODEL
Relational model is simple model is simple model in which database is represented as a
collection of “relations” where each relation is represented by two-dimensional table.

The relational model was founded by E.F.Codd of the IBM in 1972.The basic concept in
the relational model is that of a relation.
Properties:
o It is column homogeneous. In other words, in any given column of a table, all
items are of the same kind.
o Each item is a simple number or a character string. That is a table must be in first
normal form.
o All rows of a table are distinct.
o The ordering of rows with in a table is immaterial.
o The column of a table are assigned distinct names and the ordering of these
columns in immaterial.

Domain, attributes tuples and relational:

Tuple:
Each row in a table represents a record and is called a tuple .A table containing ‘n’
attributes in a record is called is called n-tuple.
Attributes:
The name of each column in a table is used to interpret its meaning and is called an
attribute.Each table is called a relation.
In the above table, account_number, branch name, balance are the attributes.
Domain:
A domain is a set of values that can be given to an attributes. So every attribute in a
table has a specific domain. Values to these attributes can not be assigned outside
their domains.
Relation:
A relation consist of
o Relational schema
o Relation instance

Relational schema:
A relational schema specifies the relation’ name, its attributes and the domain of each
attribute. If R is the name of a relation and A1,A2,… and is a list of attributes
representing R then R(A1,A2,…,an) is called a relational schema. Each attribute in
this relational schema takes a value from some specific domain called domain(Ai).
Example:
PERSON(PERSON_IDinteger,NAME: STRING,AGE:INTEGER,ADDRESS:string)
Total number of attributes in a relation denotes the degree of a relation.since the
PERSON relation schemea contains four attributes ,so this relation is of degree 4.

Relation Instance:
A relational instance denoted as r is a collection of tuples for a given relational
schema at a specific point of time.
A relation state r to the relations schema R(A1,A2…,An) also denoted by r® is a set
of n-tuples
R{t1,t2,…tm}
Where each n-tuple is an ordered list of n
values T=<v1,v2,….vn>
Where each vi belongs to domain (Ai) or contains null values.
The relation schema is also called ‘intension’ and the relation state is also called
‘extension’.
Eg:

Relation schema for student:

STUDENT(rollno:strinhg,name:string,city:string,age:integer)
 Relation instance:
Student:
Rollno Name City Age
101 Sujit Bam 23
102 kunal bbsr 22

Keys:
Super key:
A super key is an attribute or a set of attributes used to identify the records uniquely
in a relation.

For example , customer-id,(cname,customer-id),(cname,telno)

Candidate key:
Super keys of a relation can contain extra attributes . candidate keys are minimal
super keys. i.e, such a key contains no extraneous attribute. An attribute is called
extraneous if even after removing it from the key, makes the remaining attributes still
has the properties of a key.

In a relation R, a candidate key for R is a subset of the set of attributes of R, which

have the following properties:
 Uniqueness: no two distinct tuples in R have the same values for
the candidate key
 Irreducible: No proper subset of the candidate key has the
uniqueness property that is the candidate key.
 A candidate key’s values must exist. It can’t be null.
 The values of a candidate key must be stable. Its value can not change
outside the control of the system.

Eg: (cname,telno)
Primary key:
The primary key is the candidate key that is chosen by the database designer as the
principal means of identifying entities with in an entity set. The remaining candidate
keys if any are called alternate key.

RELATIONAL CONSTRAINTS:
There are three types of constraints on relational database that include
o DOMAIN CONSTRAINTS
o KEY CONSTRAINTS
o INTEGRITY CONSTRAINTS

DOMAIN CONSTRAINTS:
It specifies that each attribute in a relation an atomic value from the corresponding
domains. The data types associated with commercial RDBMS domains include:
 o Standard numeric data types for integer
o Real numbers
o Characters
o Fixed length strings and variable length strings
Thus, domain constraints specifies the condition that we to put
on each instance of the relation. So the values that appear in
each column must be drawn from the domain associated with
that column.
Rollno Name City Age
101 Sujit Bam 23
102 kunal bbsr 22

Key constraints:
This constraints states that the key attribute value in each tuple
msut be unique .i.e, no two tuples contain the same value for the
key attribute.(null values can allowed)

Emp(empcode,name,address) . here empcode can be unique

Integrity constraints:

There are two types of integrity constraints:

o Entity integrity constraints
o Referential integrity constraints

Entity integrity constraints:

It states that no primary key value can be null and unique. This is
because the primary key is used to identify individual tuple in the
relation. So we will not be able to identify the records uniquely
containing null values for the primary key attributes. This
constraint is specified on one individual relation.

Referential integrity constraints:

It states that the tuple in one relation that refers to another
relation must refer to an existing tuple in that relation. This
constraints is specified on two relations .
If a column is declared as foreign key that must be primary key of another table.

Department(
deptcode,dna
me) Here the
deptcode is
the primary
key.
Emp(empcod
e,name,city,d
eptcode).
Here the
deptcode is
foreign key.