INTRODUCTION TO DATABASE SYSTEMS

Basic concepts and Definitions:

Data vs. Information:

Data (used as both singular and plural) is the known fact that can be recorded and have
implicit meaning.

Information is the refined data. When data is processed and presented in a form
suitable for human interpretation, it is called information. Data is the raw material and
information is the finished goods.

Data Processing Information

(I/P) (O/P)

For Example: A list of students showing Regd. No, Name, Address, Course, Marks
obtained in each paper is called student’s data.

List of students who secured more than 50% marks is information.

Data base: A collection of logically interrelated data stored together with controlled
redundancy to meet the needs of an organization is called database.

Example: University database, Banking database, Hospital database etc.

Components of Database:

 Data item: distinct piece of information

 Relationships: association between data items
 Constraints: Predicates that define correct database states
 Schema: description of the database

Database-management system (DBMS): It is a collection of interrelated data and a set

a programs to access those data. It is basically a computerized record keeping system
which stores information and allows users to add, delete, change, retrieve, and update
that information on demand.

𝐷𝑎𝑡𝑎𝑏𝑎𝑠𝑒 + 𝐴𝑝𝑝𝑙𝑖𝑐𝑎𝑡𝑖𝑜𝑛 𝑃𝑟𝑜𝑔𝑟𝑎𝑚𝑠 = 𝐷𝑎𝑡𝑎𝑏𝑎𝑠𝑒 𝑠𝑦𝑠𝑡𝑒𝑚

Example:

Banking system is an example of DBMS which keeps information about the customers
and has a number of application programs:

 To open a new A/C.

 To debit or credit an A/C.
 To check balance

Dr. A. K. Panda
  To generate mini or, monthly statement etc

Advantages of DBMS:

 Minimal data redundancy: In non database system or file processing system

each department or, application has its own files. Hence the same piece of
information is replicated in several files which is called data redundancy. There
are several disadvantages of data redundancy; First, valuable storage space is
wasted. Second, same data is entered into different files unnecessarily. Third,
inconsistency. In a database system, this consistency can be controlled.
 Improved data consistency: Data redundancy leads to data inconsistency.
When the same data is duplicated and changes are made at one site, which is not
propagated to the other site, it gives rise to inconsistency. Then the two entries
regarding the same data will not agree. At such times the data is said to be
inconsistent. Since data redundancy is controlled in DBMS, the database system
enforces consistency by updating each occurrence of a data item when change
occurs.
 Data integrity: Integrity means that data entered into the database is both
accurate and consistent. Therefore, data values being entered for storage can be
checked to ensure that they fall within a specified range and are of the correct
format. Centralized control of the data helps in permitting the administrator to
define integrity constraints to the data in the database.
 Data sharing: A database system permits multiple users to share a database
easily due to a centralized system.
 Data concurrency: Concurrent access to data means more than one user is
accessing the same data at the same time. Anomalies occur when changes made
by one user get lost because of changes made by another user. The file system
does not provide any procedure to stop anomalies. Whereas DBMS provides a
concurrency control mechanism to stop anomalies to occur.
 Data Security: Security is the protection of database from unauthorized users.
Data is very important to an organization and may be confidential. Such
confidential data must be accessed by authorized users. Different authorization
checks can be established by DBA for each type of access (Retrieve, modify,
delete, etc.) to every piece of information in the database.
 Easy recovery: Since a database system keeps the backup of data, it is easier to
do a full recovery of data in case of a failure.
 Flexible: It reduces the cost and time for developing new applications. Since the
database is already designed and implemented, the programmer develops only
application programs to query the database.

Dr. A. K. Panda
Difference between File Management & Database Management

Sl. No File Management Database Management

1. It is a small system like a C++ or It is a large system like Oracle.
COBOL Program
2. It is relatively cheap It is relatively expensive
3. It has simple structure It has complex structure
4. It needs very little preliminary It needs vast preliminary design
design
5. It is not secure It is more secure
6. It is often single user oriented It is multiple user oriented
7. It has isolated data It has shared data
8. It has simple primitive It has complex and sophisticated
backup/recovery mechanism backup/recovery

Characteristics of DBMS:

1. Self describing nature of DBMS: A database system contains not only the
database itself but also a complete definition or description of the database
structure and constraints. This definition is called metadata i.e. data about data
which is stored in a catalog called data dictionary. Hence data dictionary is a
data structure that stores metadata.
2. Data independence and data abstraction: In DBMS there is insulation between
data and programs called program-data independence. Hence data can be
changed without changing application programs. A DBMS provides users with a
conceptual representation of data that does not include many of the details of
how the data is stored or how the operations are implemented. This is called
program-operation independence. The characteristic that allows program-data
independence and program-operation independence is called data abstraction.
3. Support of multiple views of the data: A database typically has many users,
each of whom may require a different perspective or view of the database. A
view is a virtual data that is derived from the database files. Users may not need
to aware of whether the data they refer to is stored derived. A multiuser DBMS
provides different views for multiple users of the same database.
4. Data sharing and multiuser transaction processing: A multiuser DBMS allow
multiple users to access the database at the same time. A concurrency control
s/w is loaded to control multiple transactions.

Different types of Database Users:

There are different types of users who interact with the database with different level of
privileges and permissions.

Dr. A. K. Panda
1. Data Base Administrator (DBA):

An individual person or group of persons having central control over DBMS is called
DBA. They are the persons who are most familiar with the database and responsible for
creating, modifying and maintaining three levels of database. The DBA is also
responsible for authorizing access to the database, coordinating and monitoring its use
and acquiring software and hardware resources as needed.

Functions of DBA:

 Defining conceptual schema and database creation

 Storage structure and access method definition
 Granting authorization to the users
 Physical organization modification
 Routine maintenance: making periodical back-ups of the database
 Job monitoring: making appropriate adjustment or tuning of the database.

2. Database Designers:

There are two types of data base designers:

a) Logical Database Designer: The logical database designer is concerned with

identifying the data (i.e. the entities and attributes), the relationships between
the data, and the constraints on the data that is to be stored in the database. The
logical database designer must have a thorough and complete understanding of
the organization’s data and its business rules.
b) Physical database designer: The physical database designer decides how the
logical database design is to be physically realized. This involves:
 Mapping the logical database design into a set of tables and integrity
constraints;
 Selecting specific storage structures and access methods for the data to
achieve good performance.
 Designing any security measures required on the data.

3. Application Programmers:

Application programmers write database application programs that provide the

required functionality for the end-users. They work from a specification produced by
the system analysts. Each program contains statements that request the DBMS to
perform some operation on the database.

4. End-Users:

The end-users are the clients for the database, which has been designed and
implemented. There are two types of end-users:

Dr. A. K. Panda
a) Naïve/ Parametric users: These users are the unsophisticated who don’t have
any DBMS knowledge but they frequently use the database applications in their
daily life to get the desired results. For example, Railway’s ticket booking users
are naive users. Clerks in any bank is a naive user because they don’t have any
DBMS knowledge but they still use the database and perform their given task.
b) Casual/ Temporary Users: These users interact with the database occasionally
and for specific purposes. They usually require the database for tasks that do not
occur on a daily basis but are crucial when needed. A marketing manager might
be a casual user who accesses the database quarterly to generate reports on
sales performance and customer demographics
c) Sophisticated users: These users are familiar with the structure of the database
and the facilities offered by the DBMS. Sophisticated users may use a high level
query language such as SQL to perform the required operation.

Dr. A. K. Panda
 DATA BASE SYSTEM ARCHITECTURE

There are two types of architectures:

 Two-tier architecture: In this type of architecture, the application is partitioned

into a component that resides at the client machines, which invokes database
system functionality at the server machine through query language statements.
Application program interface standards are used for interaction between the
client and the server.
In 1971, Database Task Group (DBTG) proposed a two-tier architecture

 Three-tier architecture: In this type of architecture, the client machine acts as

a front-end and does not contain any database calls. The client end
communicates with an application server, usually through a forms interface. The
application server in turn communicates with a database system to access data.
This type of architecture is appropriate for large applications and for
applications that run on the World Wide Web (WWW). In 1975, ANSI-SPARC
(American National Standards Institute- Standards Planning and Requirements
committee) produced three-tier architecture.

Schema, Subschema and Instances:

Schema: The overall description of the database is called as database schema. It is also a
plan or outline that describes the records at a particular level.

Employee

EMP_ID ENAME ADDRESS SEX BASIC DEPT_ID

Department

DEPT_ID DNAME LOCATION

Fig: Schema diagram

Subschema: A subschema (or, scheme) is a subset of the schema and inherits the same
property that a schema has. It is an application programmer’s or, user’s view of the data
item types and record types. It gives the users a window through which he or, she can
view only part of the databases.

ENAME ADDRESS SEX BASIC

EMP_ID ENAME ADDRESS DEPT_ID DNAME

Dr. A. K. Panda
Fig: Subschema viewed by two application programs derived from above schema.

Instance: The collection of information stored in the database at any point of time is
called as an instance of the database.

DEPT_ID DNAME LOCATION

001 MCA East
002 MBA North
003 Humanities Central

Fig: Instances of Department table.

Three Level Architecture/ 3-tier Architecture/ ANSI-SPARC Database

Architecture:

In 1975, ANSI-SPARC (American National Standards Institute- Standards Planning and

Requirements committee) produced three-tier architecture. The crucial feature of this
architecture is concept of schema.

The architecture is divided into three levels:

 External level or external schema

 Conceptual level or conceptual schema
 Internal level or internal schema

External External External

External Level
Schema Schema
… Schema

External-Conceptual Mapping Logical data Independence

Conceptual Level Conceptual Schema

Conceptual-Internal Mapping Physical data Independence

Internal Level Physical Schema

Physical Data
Organization Database

Dr. A. K. Panda
 1. External Level: This level describes the part of the database that is relevant to
each user.
2. Conceptual level: This level describes what data is stored in the database and
the relationships among the data.
3. Internal Level: This level describes how data is stored in the database.

Data Independence:

It means that upper levels are unaffected by changes in lower levels. It is achieved
through use of three levels of data abstraction.

There are two types of data independence:

1. Physical data independence: It indicates that physical storage structure or

devices used for storing data can be changed without affecting the conceptual
schema or, any of the external views. This change is absorbed by
conceptual/internal mapping.
2. Logical data independence: It means that conceptual schema can be changed
without affecting the existing external schemas. Users are shielded from change
in the logical structure of the data. Changes to conceptual schema , such as the
addition and deletion of entries, addition and deletion of attributes, or addition
and deletion of relationships are possible without changing existing external
schemas or having to rewrite application programs.

Note: It is difficult to achieve logical data independence than physical data

independence because logical data independence requires flexibility in the design of
database and the programmer has to foresee the future requirements or
modifications in the design.

Difference between Physical data independence & Logical data Independence:

Physical data Independence Logical data Independence

It is the ability to modify the physical
It is ability to modify the conceptual
schema without causing application schema without causing application
programs to be rewritten. programs to be rewritten.
Modifications at this level are necessary
Modifications at this level are necessary
to improve performance whenever the logical structure of the
database is altered.
It is not difficult to be achieved. It is more difficult to be achieved
because application programs are
dependent on the logical structure of the
data that they access.
It provides immunity of conceptual or It provides immunity of external
external schemas. schemas or application programs.

Dr. A. K. Panda
Database languages:

 Data Definition Language (DDL): It is a special language used to specify a

database conceptual schema using set of definitions.
The DDL commands are:
1. Create: It is used to create objects in the database
2. Alter: It is used to change or alter the structure of the database objects
3. Drop: It is used to delete objects from the database
4. Truncate: It is used to remove all records from a table
5. Rename: It is used to rename the object in the database
6. Comment: It is used for comments on the data dictionary.

 Data Manipulation Language (DML): It is used to query the database. It is a

mechanism that provides a set of operations to support the basic data
manipulation operations on the data held in the database.
The DML commands are:
1. Select: It is used to retrieve data from the database
2. Insert: It is used for Inserting data into an existing table
3. Update: It is used to update data within the table
4. Delete: It is used to delete data from the table
5. Merge: It is used to combine records from different tables based on a
specified condition.
6. Call: It is used to execute a stored procedure or function in a database.
7. Lock Table: It is used to restrict access to a table to prevent concurrent
data modifications.

 Data Control Language (DCL): It is used to access the stored data. It is mainly
used for revoke and grant the user access to a database.

The DCL commands are:

1. Grant: It is used to give user access privileges to a database.
2. Revoke: It is used to take back permissions from the user.

 Transaction Control Language (TCL): TCL is a language which manages the

transactions within the database. It is used to execute the changes made by the
data manipulation language statements.

The TCL commands are:

1. Commit: It is used to save the transaction on the database.
2. Rollback: It is used to restore the database to original since the last Commit.

Dr. A. K. Panda
 DATA MODEL

It is a collection of conceptual tools for describing data, data relationships, data

semantics (Integrity) and consistency constraints.

Basically there are 3 types of data models:

1. Conceptual data model/object based data model: It focuses on logical nature

of the data representation. It is concerned with what is represented in the in the
database rather than how it is represented. It uses the concept of entities,
attributes, and relationships. EX: ER model, object-oriented data model.

2. Physical data model: It provides concepts that describe the details of how data
is stored in the computer. Concepts provided by physical data models are
generally meant for computer specialists, not for the typical end-users. Physical
data models describes how data is stored as files in computer by representing
information such as record format, record orderings, and access paths. EX:
unifying model, frame memory model.

3. Implementation/representational/ record based data models: It provides

concepts that may be understood by the end users and also contain how data is
organized within computer. This model hides some details of data storage but
can be implemented in a direct way. EX: Hierarchical model, Network Model,
Relational model.

Data Model

Conceptual Physical Model Implementation

Model Model

Hierarchical Network Relational

Model Model Model

Hierarchical Model:

Hierarchical data model was developed by IBM in 1968. A hierarchical data model is a
data model which the data is organized into a tree like structure with one-to-many
relationships between different types of data. The structure allows repeating
information using parent/child relationships: each parent can have many children but
each child only has one parent. To retrieve data from a hierarchical database, we need
to traverse whole tree.

Dr. A. K. Panda
Network Model:

Network model is the advance version of the hierarchical data model. It uses directed
graphs instead of the tree-structure to organize data. The data in the network model are
represented by collection of records and relationships among data are represented by
links, which can be viewed as pointers. The main difference between this model and the
hierarchical model is that any record can have several parents in the network model.
This data model is used to map many-to-many relationship.

Relational Model:

In 1970 E.F. Codd developed the relational data model .Unlike hierarchical data model
there are no physical links. Relational Model represents how data is stored in Relational
Databases. In this model, data is represented in the form of table only. It doesn’t deal
with the physical structure but only deals with data. It provides information regarding
metadata.

Dr. A. K. Panda
 ENTITY-RLATIONSHIP MODEL

An entity-relationship model is a popular high level conceptual data model. It is a

detailed logical representation of data for an organization. The E-R model is expressed
in terms of entities, the relationships (or, associations) among those entities and the
attributes (or properties) of both the entities and their relationships. An E-R model is
normally expressed as an entity-relationship diagram (or E-R diagram or ERD) which is
a graphical representation of an E-R model.

Components of E-R model:

 Entities
 Attributes
 Relationships

Entity: An entity is a person, place, object, event or concept that is uniquely identifiable.
An entity is called entity instance or entity occurrence.

Entity type (or set): It is a collection of entities that share common properties or
characteristics.

Representation of an entity type in ERD:

Example: Person: EMPLOYEE, STUDENT, PATIENT

Place: STORE, WAREHOUSE, STATE

Object: MACHINE, BUILDING, AUTOMOBILE

Event: SALE, REGISTRATION, RENEWAL

Concept: ACCOUNT, COURSE, WORK CENTRE

Attribute: An attribute is a property or characteristic of an entity type that is of interest

to the organization.

Representation of an attribute in ERD:

Example:

Entity Type Associated attributes

EMPLOYEE Emp-id, Ename, Address, Basic, Date- of- birth, Skill
STUDENT Regd-no, Name, Address, Date-of-birth, Father’s-name,
AUTOMOBILE Vehicle-No, Engine-No, Chesses-No, Color, Weight,
Horsepower

Dr. A. K. Panda
Classification of attributes:

Simple vs. Composite Attribute:

An attribute that cannot be broken down into smaller components that are meaningful
for the organization is called simple attribute or atomic attribute.

Example: Emp-id, age, Basic, color, horsepower etc.

An attribute composed of multiple components, each with an independent existence is

called composite attribute.

Name: First-Name, Middle-Name, Last-Name

Address: Plot-No, Area, Locality, PO, City, Pin

Date of birth: Day, Month, Year

Representation of Composite attribute:

Single-valued vs. Multivalued attribute:

An attribute that holds a single value for a single entity is called single-valued attribute
and an attribute that holds multiple values for a single entity is called Multivalued
attribute.

Example: Single-valued: Empid, Ename, Basic etc.

Multivalued: Degree, Skill, hobby, Telephone-no etc.

Representations of Multivalued attribute:

Stored vs. Derived Attribute:

An attribute whose value is derived from value of another attribute is called derived
attribute and from which it is derived is called stored attribute.

Example: Stored: Date-Of-Birth, Basic, Date-Of-Joining

Derived: Age, Gross-salary, Experience

Representation of derived attribute:

Dr. A. K. Panda
Required vs. Optional Attribute:

An attribute that must be present for each entity instance is called a required attribute,
whereas an attribute that may not have a value is called an optional attribute.

Example: Required: Roll-No, Name, Fathers’-Name

Optional: Hons, Spouse-Name

*
Representation of optional attribute:

Attribute Domain: Every attribute has a domain. A domain determines the type of data
values that are permitted for that attribute.

KEYS:

 Super Key: An attribute or, a set of attributes that uniquely identifies an entity
in the entity type is called Super Key.
 Candidate Key: A super key is said to be a candidate key if no proper subset of it
is a super key. That means minimal super key is called candidate key.
 Primary Key: An entity type may have one or more possible candidate keys, one
of which is selected to be primary key. Database designer selects one of the
candidate key as primary key.
 Composite key or concatenated key: A primary key that consists of two or
more attributes is called a composite key.
 Alternate key: A candidate key that is not selected as primary key is called an
alternate key.
 Secondary key: An attribute or, a set of attributes that is used to identify the
entities which have a certain property is called secondary key.

Relationship:

It is an association between instances of one or more entity types that is interest to the
organization.

Relationship type:

It is a meaningful association between entity types.

Representation of relationship type in ERD:

Degree of a Relationship:

It is the number of entity types that participate in that relationship. The three most
common relationship degrees in E-R models are unary (degree 1), binary (degree 2),
and ternary (degree 3).

Dr. A. K. Panda
 Unary Relationship (or recursive relationship): It is a relationship between
the instances of a single entity type.

PERSON
EMPLOYEE

Is married
to
Manages

 Binary Relationship: It is relationship between the instances of two entity types

and is the most common type of relationship encountered in data modeling.

EMPLOYEE Works for DEPARTMENT

Registers
STUDENT COURSE
for

 Ternary relationship: It is a simultaneous relationship among the instances of

three entity types.

Quantity

VENDOR Supplies WAREHOUSE

PART

Hours

SUBJECT Teaches STUDENT

TEACHER

Dr. A. K. Panda
Structural Constraints:

There are certain constraints which may be placed on participating entities in a

relationship.

1. Cardinality Constraint:

It specifies the number of instances of one entity that can be associated with each
instance of another entity. There are three basic types of cardinality constraints:

 One-to-one (1:1): A relationship is said to be one-to-one if one instance of an

entity type A is associated with one other instance of another entity type B.
1 1
A R B

 One-to many (1: N): A relationship is said to be one-to-many if one instance of an

entity type A is associated with zero, one or many instances of another entity
type B, but for one instance of entity type B there is only one instance of entity
type A.
1 N
A R B

 Many-to-many (M:N): A relationship is said to be many-to-many if one instance

of an entity type A is associated with one, zero or many instances of another
entity type B, and one instance of entity type B is associated with one, zero or
many instances of entity type A.

M N
A R B

2. Participation Constraint:
It specifies whether the existence of an entity depends on its being related to
another entity via the relationship type. There are two types of participation
constraints:

The participation is said to be total (mandatory) if an entity’s existence requires

the existence of an associated entity in a particular relationship.

The participation is said to be partial (Optional) if the occurrence of one entity

does not require the occurrence of another corresponding entity in a
relationship.

Representation total participation:

Dr. A. K. Panda
 Example:

EMPLOYEE Claims DEPENDENT

3. MIN/MAX Constraints:
The participation of an entity type in relationship type can be associated by a
pair of integers (MIN, MAX) as follows:

(MIN, MAX)
A R

It means that each entity instance of the entity type A participates in at least MIN
and at most MAX relationship instances at any point of time.

Note: If MIN = 0, then the participation is partial and if MIN > 0, then the
participation is total.

Example:

(1, 1) (4, N)
EMPLOYEE Works for DEPARTMENT

Each employee works for at least one department and at most one department and
each department have at least 4 employees and at most unlimited employees.

Weak entity types:

The entity type that does not have sufficient attributes to form a primary key is called a
weak entity type. On the other hand, an entity type that has a primary key is called
strong entity type.

Note: The participation of weak entity type is always total but the converse is not true.

Representation of weak entity type in ERD:

Example:
EMPLOYEE Claims DEPENDENT

Dr. A. K. Panda
Identifying Relationship:

A relationship in which the primary key of the parent entity is used as a part of the
primary key of the dependent entity is called identifying relationship.

Representation in ERD:

Partial Key:

It is a set of attributes that uniquely identify weak entities that are related to the same
owner entity.

Representation in ERD:

Example:

City
Street
Ename
Sex
Empid State Dname Birth date
Addres
s (1, 1)
(0, N)
EMPLOYEE Claims DEPENDENT

Notations used in ER diagrams:

Sl. Symbol Meaning

No.
1. Entity type

2. Weak Entity type

3. Attribute

4. Multi-valued Attribute

5. Derived Attribute

6. Primary key Attribute

Dr. A. K. Panda
7. Partial key Attribute

…
8. Composite Attribute

9. Relationship

10. Identifying Relationship

11. Link between attribute and

entity type

12. E R Partial participation of E in R

13. E R Total participation of E in R

1 1
14. E1 R E2 One-to-One relationship

1 N
15. E1 R E2 One-to-Many relationship

M N
16. E1 R E2 Many-to-Many relationship

(MIN, MAX)
17. E R MIN/ MAX Constraint

Dr. A. K. Panda
Example:

Draw an ER diagram of book club. The book club has members. The book club sells
books to its members. The members place orders for books, which the book club fulfils.
Each order contains one or more than one book. An author can write more than one
book and a book can have more than one author. A book is published by a publisher but
a publisher publishes many books. The book club sells many books.

(1, 1) (1, N)
MEMBER Enrolls in BOOK_CLUB

(0, N) (1, N) (1, N)

AUTHOR
Fulfils
Places
Sells (1, N)

(1, 1)
(1, 1) (1, N)
(1, 1)
ORDER
BOOK Writes
(1, 1)
(1, N)
(1, 1)

Publishes

(1, N)

Contains PUBLISHER

Dr. A. K. Panda
 Example: ER diagram of Project handling company.

Locality City Locality City

State StreetNo State

PlotNo
Start-date
Address Location

Ename Sex Cname

Experience Comp-id No-of-Emp

Emp-id
(0, 1) (1, 1)
Manages
EMPLOYEE COMPANY
(1, 1) (M, N)

1 N Works for (0, N)

(1, N)

Controls

(1, 1)
Supervises (1, N)
Works on PROJECT

Proj-id Location

Hours Pname

Dr. A. K. Panda
 Example: ER diagram of banking organization.

Locality City

Plot-No State
Locality City

Address Plot-No State

Cname Sex Type Address Ename

Cust-id Emp-id experience

M N
CUSTOMER Cust-Banker EMPLOYEE Manages
1

1
N
Balance
Deposits ACCOUNT
A/C-No
N

Borrows
Transaction-Date

Opens

N 1
Loan-No N 1
LOAN Loan-branch BRANCH
Amount 1

Branch-Name Assets

City

Loan
Payment

PAYMENT

Payment-No Payment-Date

Payment-Amount

Dr. A. K. Panda
 ENHANCED ENITY RELATIONSHIP (EER) MODEL

The EER model consists of all the concepts of E-R model together with the following
additional concepts:

 Specialization
 Generalization
 Categorization
 Aggregation

Subtype or, Subclass: It is a sub-grouping of the entities in an entity type that is

meaningful to the organization and that shares common attributes or relationships
distinct from other sub-groupings.

Supertype or, Superclass: It is a generic entity type that has a relationship with one or
more subtypes.

Example:

Employee: (Full Time Employee, Part time Employee, Consultant)

Account: (SB A/C, Current A/C, Loan A/C, RD A/C, FD A/C)

Notation of Supertype/Subtype relationships:

Shared Attributes

SUPERTYPE

SUBCLASS-1 SUBCLASS-2 …… SUBCLASS-n

Unique attributes Unique attributes

Unique attributes

Dr. A. K. Panda
Attribute Inheritance:

It is a property by which subtype entities inherit values of all attributes and instance of
all relationships of the Supertype.

Specialization:

It is a top-down process. It is a process of defining one or more subtypes of the

Supertype and forming Supertype / subtype relationships.

Pname S
Patient-id Admin-Date P
G E
E C
N PATIENT
I
E A
R L
A I
L Z
I A
Z T
INPATIENT OUT-PATIENT
A I
T O
I N
O
N Check-back-Date Date-discharged

Generalization:

It is a bottom-up process. The reverse process of specialization is called generalization.

It is a process of defining a more general entity type from a set of more specialized
entity types.

Specifying Constraints on Specialization and Generalization:

The two most important types of constraints are:

 Participation constraint
 Disjointness constraint

Dr. A. K. Panda
Participation Constraint:

It is a type of constraint that addresses the question whether an instance of a Supertype

must also be a member of at least one subtype. There are two types of participation
constraints:

 Total Participation
 Partial participation

Total participation constraint: It specifies that each entity of the supertype must be a
member of some subtype in the Specialization/ Generalization.

Representation in ERD:
SUPERTYPE

Example:
Ename

Empid Address

EMPLOYEE

FULL TIME EMP HOURLY EMP CONSULTANT

Annual-Salary Billing-rate
Hourly-rate Contract-no

Partial Participation Constraint:

It specifies that a member of the Supertype need not belong to any of its subtypes of a
specialization/generalization.

Representation in ERD: SUPERTYPE

Dr. A. K. Panda
Example:

Make Model

V-Name Engine-No
Vehicle-No Chassis-No

VEHICLE

BUS TRUCK BIKE

No-of-Passengers Capacity Type

Disjointness Constraint:

It is a type of constraint that addresses the question whether an entity of a Supertype

may simultaneously be a member of two or more subtypes. There are two types of
Disjointness constraints:

 Disjoint Constraint
 Overlapping constraint

Disjoint Constraint:

It specifies that an entity of a Supertype is a member of at most one of the subtypes.

Representation in ERD:
SUPERTYPE

Dr. A. K. Panda
Example:

Name

A/C-No Address

ACCOUNT

SAVING A/C CURRENT A/C LOAN A/C

Min-Balance Overdraft-Amt EMI

Overlapping Constraint:

It specifies that an entity of a Supertype may simultaneously be a member of two or

more subtypes.

Representation in ERD:
SUPERTYPE

Example:

Ename Description
Empid Salary Part-No Type

EMPLOYEE PART

O
O

MANUFACURED PART PURCHASED PART

UNION MEMBER CLUB MEMBER

Routine-No Unit-Price

Dr. A. K. Panda
Hence, we have following four possible constraints on specialization/generalization:

 Disjoint, total
 Disjoint, partial
 Overlapping, total
 Overlapping, partial

Supertype/ subtype hierarchy:

It is a hierarchical arrangement of supertypes and subtypes, where each subtype has

only one supertype.

Example:
Name
Person-id Address

PERSON

O
Major
Date-hired

EMPLOYEE ALUMNUS STUDENT

Salary Degree Regd-No

d d

Year
Section
Regd-no
FACULTY STAFF GRADUATE UNDER GRADUATE

Rank Position
CGPA Percentage

Categorization or, Union:

It is the process of modeling of a single subtype (or subclass) with a relationship that
involves more than one distinct supertype (or superclass).
…
Representation in ERD: Supertype-1 Supertype-2 Supertype-n

SUBTYPE
Dr. A. K. Panda
Example:
EMPLOYEE DEPARTMENT COMPANY

OWNER

Aggregation:

It treats a relationship between entities as an entity itself. In aggregation, relationship

with its corresponding entities is aggregated into a higher level entity. It is used when
relationships have their attributes or, when a relationship is linked with another
relationship.

In ER models, aggregation simplifies complex scenarios. For example, consider a

"Student" working on a "Project" that requires specific "Guide". To connect this, the
"WORKS_ON" relationship between "Student" and "Project" aggregates into an
"Assignment" entity. Then, a "REQUIRE" relationship links "Assignment" and "Guide"
entities, representing the needed project guide.

STUDENT Works on PROJECT

Requires

GUIDE

Dr. A. K. Panda
 Example: EER diagram of Hospital database

Total-Cost
I-code Unit-Price
Name
T-Code Price
N
Is billed ITEM
for TEST

Name Specialty
Name
Phy-id
Patient-id Admit-date Tel-No
M
PATIENT Advices PHYSICIAN

Age Ph.No
Name
d
Prescribes
DRUG
OUT-PATIENT IN-PATIENT 1
Date Quantity N

Company
Checkbackdate Discharge-date

Is assigned Price Sells

Time

Ph.No Name
Type Price
1

ROOM PHARMACY
Treat-Code Room-No Bed-No
Roomid

TREATMENT Treats

Result
Date

Description Time

Dr. A. K. Panda
 RELATIONAL DATA MODEL

The relational model was first introduced in 1970 by Dr. E. F. Codd of IBM. The
relational model represents data in the form of tables.

Terminologies related to relational model:

 Relation: It is a named two dimensional table of data with rows and columns.
 Attribute: It is a named column of a relation.
 Domain: It is a set allowable value of an attribute.
 Tuple: It is a row of a relation.
 Degree: The degree of a relation is the no. of attributes it contains.
 Cardinality: The cardinality of a relation is the number of tuples it contains.
 Relational Database: It is a collection of normalized or structured relations with
distinct relation names.

Types of Keys:

 Super key: An attribute or, a set of attributes that uniquely identifies a tuple
with in a relation is called Super Key.
 Candidate Key: A super key is said to be a candidate key if no proper subset of it
is a super key. That means minimal super key is called candidate key.
 Primary Key: A relation may have one or more possible candidate keys, one of
which is selected to be the primary key. Database designer selects one of the
candidate key as primary key.
 Composite key or concatenated key: A primary key that consists of two or
more attributes is called a composite key.
 Alternate key: A candidate key that is not selected as primary key is called an
alternate key.
o 𝐴𝐾 = 𝐶𝐾 − 𝑃𝐾
 Secondary key: An attribute or, a set of attributes that is used to identify the
entities which have a certain property is called secondary key.
 Foreign key: An attribute in a relation that serves as the primary key of another
relation is called in the same database is called foreign key.

Dr. A. K. Panda
Properties of relations:

1. Each relation (or table) in a database has a unique name.

2. An entry at the intersection of each row and column is atomic (or single valued).
There can be no multivalued attribute in a relation.
3. Each row is unique; no two rows in a relation are identical.
4. Each attribute (or column) within a table has a unique name.
5. The order of the attributes (left to right) has no significance. The columns of a
relation can be interchanged without changing the meaning or use of the
relation.
6. The order of the tuples has no significance. The rows of a relation may be
interchanged or stored in any sequence.

Integrity Constraints:

Relational data model includes several constraints whose purpose is to maintain the
accuracy and integrity of the data in the database. The major types of integrity
constraints are:

1. Domain constraint (Check): It specifies that the value of each attribute A must
be atomic value from the domain of A.
2. Key constraint (unique): It specifies that all tuples in a relation must be distinct.
3. Entity Integrity constraint (not null): It specifies that primary key cannot
accept null values.
4. Referential Integrity Constraint (Foreign key): It specifies the value of the
referencing attribute (Foreign key) is either null or it is equal to value of the
referenced attribute.

Example:

Referencing Relation: EMPLOYEE (Emp-id, E-name, Address, Dept-id)

Referenced relation: DEPT (Dept-id, D-name, Location)

In the referencing relation EMPLOYEE, value of the referencing attribute Dept-id is

either null or it takes any value of the Dept-id column in DEPT relation.

Dr. A. K. Panda
CODD’S 12 Rules:

E. F. Codd proposed a set of rules which qualify a database product as relational.

Though, it is referred to as “Codd’s twelve rules”, in reality there are 13 rules including
rule zero.

Rule Rule Name Description

Rule Foundation Rule A relational database management system must manage the
0 database entirely through its relational capabilities.
Rule Information Rule The information can be represented in one and only one
1 way i.e. tables also known as relations.
Rule Guaranteed Every data value is logically accessible by a combination of
2 Access Rule table name, column name, and primary key value.
Rule Missing Null values are systematically supported independent of
3 information Rule data type.
Rule System catalogue The description of a database and its contents are database
4 rule tables and therefore, can be queried on-line via the data
manipulation language. The database administrator’s
productivity is improved since the changes and additions to
the catalog can be done with the same commands that are
used to access any other table.
Rule Comprehensive The RDBMS may support several languages. But at least one
5 Language Rule of them should allow the user to do all the following: define
tables and views, query and update data, set integrity
constraints, set authorizations, and define transactions.
Rule View Update Rule The system should be able to perform all theoretically
6 possible updates on views.
Rule Set level update The RDBMS supports insertion, updating, and deletion at a
7 Rule table level. The performance is improved since the
commands act on a set of records rather than one record at
a time.
Rule Physical data User operations and application programs should be
8 independence independent of any changes in physical storage or access
rule methods.
Rule Logical data User operations and application programs should be
9 independence independent of any changes in logical structure of base
rule tables provided they involve no loss of information.
Rule Integrity Entity and referential integrity constraints should be
10 independence defined in the high level relational language.
rule
Rule Distribution User operations and application programs should be
11 independence independent of the location of data when it is distributed
rule over multiple computers.
Rule Non-subversion If RDBMS takes help of any low level procedural language, It
12 Rule must not bypass any integrity rules or constraints of the
relational language.

Dr. A. K. Panda
 TRANSFORMATION OF ER MODEL INTO RELATIONS

During logical design, the ER diagrams (developed during conceptual design) are
translated into relational database schemas. The inputs to this process are the ER
diagrams and the outputs are collection of tables (or, relations) with associated
constraints. Transforming (or mapping) ER diagrams to relations is a straightforward
process with a well-defined set of rules.

Step 1: Mapping of strong entity types

Transform each (strong) entity type in an E-R diagram into a relation. The primary key
of the entity type becomes the primary key of the corresponding relation. Each simple
attribute of the entity type becomes an attribute of the relation. If one attribute is
composite, include the simple components of the composite attribute.

Mname
Fname Lname

Cname Sex
Custid
Address

CUSTOMER

CUSTOMER (Custid, Fname, Mname, Lname, Sex, Address)

Step 2: Mapping of Weak Entity Types

For each weak entity type, create a new relation and include all of the simple attributes
as attributes of this relation. Then include the primary key of the parent entity type as
foreign key attribute in this new relation. The primary key of the new relation is the
combination of the primary key of the parent entity type and the partial key of the weak
entity type.

City
Street
Ename
Sex
Empid State Dname Birth date
Addres
s (1, 1)
(0, N)
EMPLOYEE Claims DEPENDENT

Dr. A. K. Panda
 EMPLOYEE (Empid, Ename, Street, City, State)

DEPENDENT (Empid, Dname, Sex, Birth-Date)

Step 3: Mapping of Multivalued Attributes

When the entity type contains a multivalued attribute, two new relations are created.
The first relation contains all the attributes of the entity type except the multivalued
attribute. The second relation contains two attributes that form the primary key of the
second relation. The first of these attributes is the primary key of the first relation,
which becomes a foreign key in the second relation and the second is the Multivalued
attribute.

Pname
Phy-id Salary

PHYSICIAN (Phy-id, Pname, Salary)

Phone-no
PHYSICIAN
TELEPHONE (Phy-id, Phone-no)

Step 4: Mapping of Binary One-to-One Relationships

For each binary one-to-one relationship R between two entity types A and B, first create
a relation for each of the two entity types, say R 1 and R2 respectively. Then choose one
of the relations (say R1) and include as foreign key in R 1 the primary key of B. (It is
better to choose an entity type whose participation is total.) Include all the simple
attributes of the relation type R as attributes of R1.

Ename Dname
Start-Date
Deptid
Salary Location
Empid

1 1
EMPLOYEE Manages DEPARTMENT

EMPLOYEE (Empid, Ename, Salary)

DEPARTMENT (Deptid, Dname, Location, Managerid, Start-Date)

Dr. A. K. Panda
Step 5: Mapping of Binary One-to-Many Relationships

For each binary one-to-many relationship, first create a relation for each of the two
entity types participating in the relationship. Next, include the primary key attribute of
the entity on the one-side of the relationship as a foreign key in the relation that is on
the many-side of the relationship (PK migrates to the many side). Then include the
simple attributes of the relationship as attributes of the relation that is on the many-
side.

Cname
Orderid O-Date
Custid Address

1 N
CUSTOMER Places ORDER

CUSTOMER (Custid, Cname, Address)

ORDER (Orderid, O-Date, Custid)

Step 6: Mapping of Binary Many-to-Many Relationships

For each binary many-to-many relationship R, between two entity types A and B, create
a relation for each participating entity types (say, R1 and R2) and create a separate
relation for the relationship (say R3). The primary key of this relation is a composite
key consisting of the primary keys of the participating entity types. Include the simple
attributes of relationship type R as attributes of R3.

Description
Quantity

Orderid O-Date Prodid UnitPrice

M N
ORDER REQUESTS PRODUCT

ORDER (Orderid, O-Date)

PRODUCT (Prodid, Description, UnitPrice)

ORDERLINE (Orderid, Prodid, Quantity)

Dr. A. K. Panda
Step-7: Mapping of Unary Relationships (or, recursive relationships)

For each unary one-to-one or, one-to-many relationship, create a single relation to
represent both entity type and relationship type. The primary key of this relation is the
primary key of the entity type. Then include the primary key of the same entity type as
foreign key of the relation.

Sex

Pname Addre
ss

PERSON PERSON (Pname, Sex, Address, Spouse-name)

1 1

Is
married
to

Ename

Empid Address

EMPLOYEE EMPLOYEE (Empid, Ename, Address, Managerid)

1 N

Manages

For each unary many-to-many relationship, create two relations: one to represent the
entity type in the relationship and the other an associative relation to represent the M:
N relationship itself. The primary key of the associative relation consists of two
attributes (which need not have the same name) both take their values form the
primary key of the other relation. Then include simple attributes of the relationship as
attributes of the associative relation.

Dr. A. K. Panda
 Description

Item-No Unit-Price

ITEM ITEM (Item-No, Description, Unit-Price)

M N
COMPONENT (Item-No, Component-No, Quantity)

Contains

Quantity

Step-8: Mapping of n-ary relationships (n  2)

For each n-ary (n  2) relationship type R, create a new relation S to represent R. The
primary key of this relation consists of the primary key attributes for the participating
entity types. Then include the simple attributes of R as attributes of the relation S.

Pname Color

Pno Weight

Sname Status
PART Jname
Jno
Sno City
City

SUPPLIER Supplies PROJECT

Quantity

SUPPLIER (Sno, Sname, Status, City)

PART (Pno, Pname, Color, Weight)

PROJECT (Jno, Jname, City)

SHIPMENT (Sno, Pno, Jno, Quantity)

Dr. A. K. Panda
Step-9: For each specialization / generalization, create a relation for the Superclass,
which contains the primary and all non key attributes in common with all subclasses,
plus create a separate relation for each subclass with the same primary key but with
only non key attributes related to that subclass.

Ename

Empid Address

EMPLOYEE (Empid, Ename, Address)

EMPLOYEE
FULL-TIME-EMP (Empid, Basic)

d PART_TIME_EMP (Empid, Hourly-wages, Hours-worked)

FULL TIME EMP PART TIME EMP

Basic
Hourly-wages Hours-worked

Dr. A. K. Panda