Database Management System

Module - I

 Introduction
 Characteristics of Database approach
 Actors on the screen
 Workers behind the scene
 Advantages of using DBMS approach
 Data models, schemas and instances
 Three-schema architecture and data independence
 ER Model: Using High-Level Conceptual Data Models for Database Design
 Entity types, Entity sets, Attributes and Keys
 Relationships, Relationship types
 Roles and Structural Constraints
 Weak Entity Types.

Introduction

Data are the known facts that can be recorded and have an implicit meaning. A database is a
collection of logically related data.
 Properties of a database:
o It represents some aspect of real world (miniworld).
o It is a logically coherent collection of data with some inherent meaning.
o It is designed, built and populated with data for a specific purpose.

A database can be of any size and complexity.

 Ex1: A university database
o Entities such as students, faculty, courses
o Relationships between entities such as students’ enrollment in courses, faculty
teaching courses

 Ex2: A Hospital database

o Entities such as doctors, patients, nurses, wards
o Relationships between entities such as doctors visiting patients, patients in
rooms.

Dr. Aparna K, Professor, Department of MCA, BMSIT&M Page 1

Database Management System

A database may be generated and maintained manually or it may be computerized. A Database

Management System (DBMS) is a software package (collection of programs) that enables users
to create, store and maintain a database. The DBMS is a general purpose software system that
facilitates the process of defining, constructing, manipulating, and sharing databases among
various users and applications.

Introduction (functionalities of DBMS)

A DBMS is a general purpose software system facilitating each of the following (with respect to
a database):
 Defining a database
o Specifying data types, structures, and constraints of the data to be stored in the
database.
 Constructing the database
o the process of storing the data on some storage medium (e.g., magnetic disk)
that is controlled by the DBMS
 Manipulating the database
o querying the database to retrieve specific data, updating the database to reflect
changes in the miniworld, and generating reports
 Sharing a database
o allowing multiple users and programs to access the database "simultaneously"
 Maintaining the database
o allowing the system to evolve as requirements change over time

Protection includes system protection and security protection.

 System protection
o preventing database from becoming corrupted when hardware or software
failures occur
 Security protection
o Preventing unauthorized or malicious access to database.

Characteristics of a Database system

File System vs a DBMS

 In the file processing approach
o Each user defines and implements the files needed and software applications to
manipulate those files.

Dr. Aparna K, Professor, Department of MCA, BMSIT&M Page 2

Database Management System

o Data definition is part of the application programs, thus, programs must be

changed to change definition of files.
o A program can access only specific files and special programs should be written
for every query.
o This redundancy in defining and storing data results in wasted storage space and
in redundant efforts to maintain up-to-date data.
o In file system, each application is free to name data elements independently.

 In the database approach

o A single repository of data is defined once, maintained and is then accessed by
various users.
o In database, names or labels of data are defined once and used repeatedly in
different applications/queries.

Characteristics of a Database system

 Self-describing nature of a database system
 Insulation between programs and data, and data abstraction
 Support of multiple views of the data
 Sharing of data and multiuser transaction processing

Self describing nature of a Database system

In DBMS
 A database system has self-describing nature.
 A complete definition and description of the database structure and constraints is
stored in the DBMS catalog (known as metadata),
 Application software need not be changed to change description of databases.
 A general purpose DBMS software package is not written for a specific database
application.
 Application must refer to the catalog to know the structure of the files in a specific
database.

In Traditional file processing System

 The structure of the data files accessed by an application is "hard-coded" in its source
code.
 To change the structure of the data, every application in which a description of that
file's structure is hard-coded must be changed.

Dr. Aparna K, Professor, Department of MCA, BMSIT&M Page 3

Database Management System

Insulation between programs and data, and data abstraction

In DBMS
 DBMS provides an abstract view of the data that hides the details.
 A DBMS provides users with a conceptual representation of data that does not include
the details of how data is stored and how the operations are implemented.
o Program-data independence
o Program-operation independence

Program-data independence
 The definition and description of the database is stored in the catalog (known as
metadata); to change description of databases, application software are not changed.

Program-operation independence
 In object-oriented relational system, users can define operations on data as part of the
database definitions
 An operation is specified in two parts:
o The interface of an operation name and data types of its arguments.
o The implementation of the operation is specified separately and can be changed
without affecting the interface.
 User application programs can operate on the data by invoking on these operations
through their names and arguments, regardless of how the operations are
implemented.

Support of multiple views of the data

 A database has many users, different users may have different requirements i.e. each
user requires a different view of the database.
 A view may be a subset of the database or it may contain virtual data that is derived
from the database files but is not explicitly stored.

Dr. Aparna K, Professor, Department of MCA, BMSIT&M Page 4

Database Management System

Sharing of data and multiuser transaction processing

 A multiuser DBMS must allow multiple users to access the database at the same time.
 DBMS includes concurrency control software to ensure that several users updating the
same data, should update in a controlled manner so that the result of the every update
is correct.
 Each transaction should possess ACID properties.

Actors on the Scene

 Database Administrator
 Database Designers
 End Users
o Casual end users
o Naive/Parametric end users
o Sophisticated end users
o Stand-alone users
 System Analysts and Application Programmers

Database Administrator (DBA)

This is the chief administrator, who oversees and manages the database system. Duties include
1. Security & Authorization
o authorizing users to access the database, coordinating/monitoring its use
2. Database recovery after failures

Dr. Aparna K, Professor, Department of MCA, BMSIT&M Page 5

Database Management System

o restoring the data, maintaining the log files

3. Database tuning
o acquiring hardware/software for upgrades, etc.

Database Designers
 They are responsible for identifying the data to be stored and for choosing an
appropriate structure to represent and store this data.
 They also define views for different categories of users. The final design must be able to
support the requirements of all the user sub-groups.

End-users
 These are persons who access the database for querying, updating, and report
generation. They are main reason for database's existence!

1. Casual end users

o They use database occasionally, needing different information each time.
o They use query language to specify their requests.
o They are middle- or high-level software literate managers.
2. Naive/Parametric end users
o Typically the biggest group of users; frequently query/update the database using
standard front end based application that have been carefully programmed and
tested in advance.
Examples:
o Bank tellers check account balances, post withdrawals/deposits
o Reservation clerks for airlines, hotels, etc., check availability of seats/rooms and
make reservations.
3. Sophisticated end users
o They are engineers, scientists, business analysts who implement their own
applications to meet their complex needs.
4. Stand-alone users
o They use "personal" databases,
o A tax program user that creates his or her own internal database by using ready-
made package.

System Analysts and Application Programmers

 They develop the packages that facilitate the data access for end users using the host
language, DBMS packages, other DBMS related software tools like report writers.

Dr. Aparna K, Professor, Department of MCA, BMSIT&M Page 6

Database Management System

Workers behind the Scene

 Database system designers & implementers
 Tool Developers
 Operators and maintenance personnel

Database system designers & implementers

 They design and implement the DBMS modules and interfaces as a software packages.
 DBMS consists of many components e.g. for implementing the catalog, processing query
language, processing the interface, accessing and buffering data, controlling
concurrency and handling data recovery and security
 It should also interface operating system and compilers of various programming
languages

Tool Developers
 They design and implement tools – the software packages that facilitate database
modeling design.
 These tools include packages for database design, performance monitoring, natural
language or graphical interfaces, prototyping, simulation, and test data generation.
 Tools can be purchased separately which are developed by different vendors.

Operators and maintenance personnel

 They are responsible for the actual running and maintenance of the hardware and
software environment for the database system.

Advantages of using the DBMS approach

1. Controlled Redundancy
2. Restricting Unauthorized Access
3. Providing Persistent Storage for Program Objects
4. Providing Storage Structures for Efficient Query Processing
5. Providing Backup & Recovery
6. Multiple user interfaces
7. Representing Complex Relationships among data
8. Enforcing Integrity Constraints
9. Permitting Inferencing and Action Using Rules

Dr. Aparna K, Professor, Department of MCA, BMSIT&M Page 7

Database Management System

1. Controlled Redundancy
 In the file processing approach, each user defines and implements the files needed and
software applications to manipulate those files.
 Various files are likely to have different formats and programs may be written in
different languages and same information may be duplicated in several files.
 Data redundancy leads to
o wasted storage space,
o duplication of effort (when multiple copies of a datum need to be updated),
o a higher likelihood of the introduction of inconsistency.
 Database design stores each logical data item at one place to ensure consistency and
saves storage.
 But sometimes, controlled redundancy is necessary to improve the performance.
 Database should have capability to control this redundancy & maintain consistency by
specifying the checks during database design.

2. Restricting Unauthorized Access

 A DBMS provides a security and authorization subsystem, which is used by DBA to
create user accounts and to specify restrictions on user accounts.
 File processing system provides password mechanism and very less security which is not
sufficient to enforce security policies like DBMS.

3. Providing Persistent Storage for Program Objects

 Object oriented database systems are compatible with programming languages such as
C++ and Java.
 A OODBMS software automatically performs the conversion of a complex object which
can be stored in OODBMS, thus an object is said to be persistent due to its survival after
the termination of the program.

4. Providing Storage Structures for Efficient Query Processing

 The DBMS utilizes a variety of sophisticated techniques (view, indexes etc.) (auxiliary
files) to store and retrieve the data efficiently that are utilized to improve the execution
time of queries and updates.
 DBMS provides indexes and buffering for fast access of query result, the choice of index
is part of physical database design and tuning.
 The query processing and optimization module is responsible for choosing an efficient
query execution plan for each query submitted to the system.

Dr. Aparna K, Professor, Department of MCA, BMSIT&M Page 8

Database Management System

5. Providing Backup & Recovery

 Data should be restored to a consistent state at the time system crash and changes
being made
 If hardware or software fails in the middle of the update program, the recovery
subsystem of DBMS ensures that update program is resumed at the point of failure.

6. Multiple user interfaces

 DBMS provides a variety of user interfaces for the users of varying level of technical
knowledge.
 These includes query language for casual users, programming language interfaces for
application programmers, forms and command codes for parametric users, menu driven
interfaces and natural language interfaces for standalone users etc

7. Representing Complex Relationships among data

 A DBMS have the capability to represent a variety of complex relationship among the
data, to define new relationships as they arise, and to retrieve and update the related
data easily and efficiently.

8. Enforcing Integrity Constraints

 The DBMS have certain integrity constraints that hold on data.
 These constraints are derived from the meaning of the data and of the miniworld.
 Some constraints can be specified to the DBMS at the time of defining data definitions
and automatically enforced.
 Database does not allow violation of constraints at the time of updating the database.

9. Permitting Inferencing and Action Using Rules

 Deductive database systems provide capabilities for defining deduction rules for
inferencing new information from the stored database facts.
 Triggers can be associated with tables.
 A trigger is a form of a rule activated by updates to the table, which results in
performing some additional operations to some other tables, sending messages and so
on.
 Stored procedure can also be used as a part of the overall database definition and are
invoked appropriately when certain conditions are met.
 Active database provides more powerful functionality by providing the active rules that
can automatically initiate actions when certain events and conditions occur.

Dr. Aparna K, Professor, Department of MCA, BMSIT&M Page 9

Database Management System

Additional Implications of using the DBMS approach

1. Potential for enforcing standards

 The database approach permits the DBA to define and enforce standards among
database users in a large organization.
 Standards can be defined for names and formats of data elements, display formats,
report structures, terminology etc.
 This facilitates communication and cooperation among various departments, projects
and users within the organization.

2. Reduced application time

 DBMS applications are more robust because many important tasks are handled by
DBMS, thus do not have to be debugged and tested.
 Programmer can concentrate more on the specific functionality required by the users.

3. Flexibility
 It may be necessary to change the structure of a database as requirements change.
 Modern DBMS allows certain type of changes to the structure of database without
affecting the stored data and the existing application programs.
4. Availability of Up-to date information
 Availability of immediate up to date information is essential for many transaction
processing applications.
 In DBMS, update applied to database by one user can immediately be seen by other
users.

5. Economies of scale
 The DBMS approach permits consolidation of data and applications, thus reducing the
amount of wasteful overlap between the activities of data processing personnel, also
reduce the storage space.

Data Models, Schemas, and Instances

Database approach provides data abstraction. Database abstraction refers to the suppression
of details of data organization and storage and the highlighting of the essential features for an
improved understanding of data. Structure of a database includes data types, relationships,
and constraints that should hold on the data. A data model is a collection of concepts that can
be used to describe the structure of a database and thus it provides the necessary means to
achieve this abstraction. Most data models also include a set of basic operations for specifying

Dr. Aparna K, Professor, Department of MCA, BMSIT&M Page 10

Database Management System

retrievals and updates on the database. Data models also include the dynamic aspect or
behavior of a database application. Concepts to specify behavior are fundamental to object
oriented data models but are also being incorporated in more traditional relational data models
(e.g. stored procedures).

Categories of Data Models

A number of models for data representation have been proposed.

 High level or conceptual data models

o provide concepts that how users perceive the data, e.g. ER model
o object data model group (ODMG): a conceptual model for object oriented
database
 Low level or physical data models
o provide concepts that describe the details of how data is stored in the computer
e.g. record formats, record orderings, access path, index etc.
 Representational data models
o provide the concepts which is in between two extremes
o they hide some details of data storage but can be implemented on a computer
system directly
 Most frequently used in commercial applications is relational data model (also called
record-based data models). Other legacy data models are network and hierarchical
models.

Schemas, Instances, and Database State

Description of structure of database & Database itself

The description of a database is called the database schema which is specified during database
design and is not expected to change frequently. Schema diagram displays structure of each
record type but not the actual instances of records. Each object in the schema is known as a
schema construct e.g. student table. A schema diagram displays only some aspects of a schema
such as names of record types and data items, and some type of constraints; other aspects are
not specified.

An Example

Dr. Aparna K, Professor, Department of MCA, BMSIT&M Page 11

Database Management System

The data in the database at a particular moment is called a database state or snapshot. This
state is also called the current set of occurrences or instances in the database. Many database
states can be constructed to correspond to a particular database. When a new database is
defined, database state is empty state with no data. When database is populated, database
enters in initial state. The DBMS is partly responsible for ensuring that every state of the
database is a valid state - that is, a state that satisfies the structure and constraints specified in
the schema. Hence, specifying a correct schema to the DBMS is extremely important. DBMS
stores the descriptions of the schema constructs and constraints in the catalog (meta-data).
Schema is called the intension and state is called as extension. Changes in application
requirements result in schema evolution.

Three-Schema Architecture and Data Independence

Three-Schema Architecture
 The schema in DBMS can be described at three levels:
o Internal level has an internal schema
o Conceptual level has a conceptual schema
o External level includes a number of external schemas or user views
 The information about all three schemas is stored in the system catalog.

Dr. Aparna K, Professor, Department of MCA, BMSIT&M Page 12

Database Management System

Internal Schema

The internal schema specifies complete details of storage and access paths for the database.
File organization on the disk should be decided e.g. hashing, indexing etc. The process of
arriving at a good physical database schema is called physical database design.

Conceptual Schema

The conceptual schema (or logical schema) describes the structure of the database. The
conceptual schema hides the details of physical storage structures and concentrates on
describing entities, data types, relationships, user operations, and constraints. A
representational data model is used to describe the conceptual schema when a database is
implemented. The process of arriving at a good conceptual database schema is called
conceptual database design.

Conceptual Schema (example)

Students (sid: string, sname: string, login: string, age: integer, gpa: real)
Faculty (fid: string, fname: string, sal: real)
Courses (cid: string, cname: string, credits: integer)
Rooms (rno: string, address: string, capacity: integer)
Enrolled (sid: string, cid: string, grade: string)
Teaches (fid: string, cid: string)
Meets_In (cid: string, rno: integer, time: string)

Dr. Aparna K, Professor, Department of MCA, BMSIT&M Page 13

Database Management System

External Schema

The external schemas allow data access to be customized at the level of individual users and
hide rest of the details from the users. Any database has exactly one conceptual schema and
one physical schema but may have many external schemas in view to support different users.
Each external schema consists of a collection of one or more number of views or tables. The
external schema design is guided by end user requirements e.g. courseinfo (cid, fname, sid).

Important points
 Three schemas are only descriptions of data; the stored data that actually exists is at the
physical level.
 DBMS must transform a request specified on an external schema into a request against
the conceptual schema, and then into a request on the internal schema for processing
over the stored database.
The process of transforming requests and results between levels are called mappings

Data Independence

One of the most important benefits of using three schema architecture is its support for data
independence. Applications are insulated from how data are structured and stored. Data
independence is the capacity to change the schema at one level of a database without changing
the schema at the next higher level.
o Logical data independence
o Physical data independence

Logical data independence

 Protection of user views from changes in logical structure of data.

 Logical data independence is the capacity to change the conceptual schema without
having to change external schemas or application programs.

Physical data independence

 Protection of logical structure from changes in physical structure of data.

 Physical data independence is the capacity to change the internal schema without
having to change conceptual schemas.

Dr. Aparna K, Professor, Department of MCA, BMSIT&M Page 14

Database Management System

Important points
 Physical data independence exists in most databases.
 But logical data independence is hard to achieve.
 Data independence occurs because when the schema is changed at some level, the
schema at higher level remains unchanged; only the mapping between the two levels is
changed.
 Two levels of mappings create an overhead during compilation or execution of a query
or program, leading to inefficiencies in the DBMS.

Entity-Relationship Model

Using High-Level Conceptual Data Models for Database Design

 1st Step: Requirements analysis

 2nd Step: Conceptual design
 3rd Step: Logical design or data model mapping
 4th Step: Physical design

Dr. Aparna K, Professor, Department of MCA, BMSIT&M Page 15

Database Management System

1st Step: Requirements analysis

Database designers interview prospective database users to understand and document their
data requirements. Two types of requirements are
o Functional requirements
o Database requirements
Functional requirements
 User defined operations that are applied to the database
 Include updates and retrieval
 DFDs, Sequence diagram, scenarios can be used to define
Database requirements
 Data and data type to be stored
 Constraints applied on data

2nd Step: Conceptual design

Create conceptual schema using high level conceptual data model. Conceptual schema is a
description of the data requirements of the users and includes entity types, relationships, and
constraints. Conceptual schemas do not include implementation details and can be used to
communicate with non technical users. It can be used to ensure that all users data
requirements are met and no conflict exists.

3rd Step: Logical design or data model mapping

Actual implementation of the database is using a commercial DBMS. Conceptual schema is
transformed from the high level data model into the implementation data model.

4th Step: Physical design

Internal storage structures, access paths, and file organizations for the database files are
specified. In parallel with all steps, application programs are designed and implemented as
database transactions corresponding to the high level transaction specifications.

ER Model
 A database can be modeled as:
o a collection of entities having attributes
o relationship among entities
 Entity, Entity type, Entity set
 Attributes, Type of attributes
 Keys
 Relationships, Relationship type
 Roles
 Constraints

Dr. Aparna K, Professor, Department of MCA, BMSIT&M Page 16

Database Management System

Entities
An entity is an object that has existence and is distinguishable from other objects.
 Physical existence
o Person, car, employee etc.
 Conceptual existence
o Company, job, university course
An entity lies within the scope of the business world being modeled. Each entity has attributes
– the particular properties that describe it.

Attributes
Attributes are properties used to describe an entity. For example an EMPLOYEE entity may have
a Name, SSN, Address, Sex, BirthDate. A specific entity will have a value for each of its
attributes. For example a specific employee entity may have Name=‘Ram', SSN='123456789',
Address ='731, RR Nagar, Bangalore, Karnataka', Sex='M', BirthDate='09-JAN-65’. Each attribute
has a data type associated with it e.g. integer, string, date etc. Each attribute must have a
unique name across the entity.

Types of Attributes

Simple
Each entity has a single atomic value for the attribute. For example, SSN or Sex.

Composite
The attribute may be composed of several components. The value of a composite attribute is
the concatenation of the values of its simple attributes. Composition may form a hierarchy
where some components are themselves composite. If components of the composite
attributes have to be referred, it is necessary to store the components separately. If composite
attribute is referred only as a whole, there is no need to subdivide it into component attributes
e.g. if address has to be referred as a whole only, there is no need to divide it.

For Example:
Address (Apt#, House#, Street, City, State, ZipCode, Country)
Name (FirstName, MiddleName, LastName).

Dr. Aparna K, Professor, Department of MCA, BMSIT&M Page 17

Database Management System

Single-valued
 Only single value for a particular entity e.g. DOB

Multi-valued
 An entity may have multiple values for that attribute.
 Multiple value may have lower and upper bounds on the number of values.
 For example, Color of a CAR: {Color}
phone_numbers: {phone number}

Stored attributes
 Stored in the database

Derived attributes
 Can be computed from other related attributes
 E.g. Birthdate ---stored
Age ----derived
Joining date ------stored
Year of Experience ---derived

Dr. Aparna K, Professor, Department of MCA, BMSIT&M Page 18

Database Management System

Null values
 A particular entity may not have the value for a particular attribute
o Value is not applicable
o Value is unknown
 A special value NULL is written
 e.g. Every employee may not have Fax no.

Complex attributes
 Composite attributes can be nested arbitrarily.
 Components of a composite attribute can be shown in () and multivalued attribute can
be shown in {}.
For example:
{Address_phone (
{phone (Area_code, phone_number)},
Address (Street_Address
(Number, Street, Apartment_No), City, State, Zip)
) }

Entity Type
 An entity type defines a collection of entities that have the same attributes
 Each entity is defined in database by its name and attributes.
 Each entity type must have a name that is unique across the entire model and has a
consistent meaning across the modelling team and the end users.
 For example,
o EMPLOYEE is an entity type
o PROJECT is an entity type.

Entity set
 The collection of all entities of a particular entity type in the database at any point of
time is called an entity set.
 The entity set is usually referred to using the same name as the entity type.
 For example,
 EMPLOYEE refers to both
o ‘type of entity’
o ‘set of entity’
Notation
 Entity type by rectangular box enclosing the entity type name
 Attributes by ovals attached to entity type by straight line

Dr. Aparna K, Professor, Department of MCA, BMSIT&M Page 19

Database Management System

 Composite attributes shown by attaching components to it

 Multivalued by double oval

Example

Extension & Intension

 An entity type describes the schema or intension for a set of entities that share
structure.
 The collection of all entities of a particular entity type are grouped into an entity set, is
also called the extension of the entity type.

Key attributes
 An attribute of an entity type for which each entity must have a unique value is called a
key attribute of the entity type.
For example, SSN of EMPLOYEE
 (Key attribute defines the each entity of an entity type uniquely)

Dr. Aparna K, Professor, Department of MCA, BMSIT&M Page 20

Database Management System

 Uniqueness of key attribute must hold for every extension of the entity type.
 It is not the property of a particular extension of the entity type, it is a constraint on all
extension of entity type.
 A key attribute may be composite.

For example,
 Registration is a composite key of the CAR entity type with components (Number,
State).

Some entity types have more than one key attributes, those attributes can behave as keys
on their own separately; they are called candidate keys. All key attributes should be
underlined in ER diagram. Selected key will work as Primary key. Other potential keys will
be Alternate keys. An entity type may have no key; it is called a weak entity type.

Value Sets (Domains) of attributes

 Domain specifies the set of permitted values for each attribute for each individual
entity.
For example,
o Birth Date: Range of all valid dates
o Employee Name: All possible range of names
o DeptCode: Set of all department codes
 Value sets are specified using the basic data types, size and other constraints.
 Value set provides all possible values
 Value Sets (Domains) of attributes

A : E  P(V)
 A is Attribute of E Entity Type having value set V, is a function to the power set P(V)
 For composite attribute
V = P(V1) * P( V2) * ……* P(Vn)
 Where V1, V2 ….Vn are the value set of each component of composite attribute.

Relationships
 A relationship is an association among two or more entities.
 Whenever an attribute of one entity type refers to the attribute of another entity type,
some relationship exists.
 Specifically a relationship relates two or more distinct entities with a specific meaning
o For example, manager of the DEPARTMENT refers to an employee who manages
the department.

Dr. Aparna K, Professor, Department of MCA, BMSIT&M Page 21

Database Management System

o Department of EMPLOYEE refers to the department for which the employee

works.

Relationships Type
 Relationships of the same type are grouped into a relationship type.
o For example, the WORKS_FOR relationship type in which EMPLOYEEs and
DEPARTMENTs entities participate,
o or The MANAGES relationship type in which EMPLOYEEs and DEPARTMENTs
entities participate.
 More than one relationship type can exist with the same participating entity types.
 For example, MANAGES and WORKS_FOR are distinct relationships between EMPLOYEE
and DEPARTMENT, but with different meanings and different relationship instances.

Relationships Set
 A relationships set is a set of relationships of the same type.
 A relationship set and a relation type are referred to by the same name.
 The relationship set R is a set of relationship instances ri, where each ri associates n
individual entities (e1, e2, ….., en) and each entity ej in ri is a member of entity type Ej,
1≤ j ≤ n
 E.g. each employee and department participates in the relationship of works_for.

Some instances in the WORKS_FOR relationship set, which represents a relationship type
WORKS_FOR between Employee and department.

Dr. Aparna K, Professor, Department of MCA, BMSIT&M Page 22

Database Management System

Degree of Relationships Type

 The degree of a relationship type is the number of participating entity types.
o Binary Relationship
o Ternary Relationship

Binary Relationship
 When two entities participate in relation.
 WORKS_FOR is binary relationship and participating entities are EMPLOYEE and
DEPARTMENT

Ternary Relationship
 When three entities participate in relation.
 SUPPLY is ternary relationship and participating entities are SUPPLIER, PROJECT and
PARTS.

Degree of Relationships Type: Example

 Some relationship instances in the ‘SUPPLY’ ternary relationship set

Dr. Aparna K, Professor, Department of MCA, BMSIT&M Page 23

Database Management System

Role names
 Each entity type that participates in a relationship type plays a particular role in the
relationship.
 Role name signifies the role that a participating entity plays in each relationship
instance.

 For example,
o In the WORKS_FOR relationship type, EMPLOYEE plays the role of employee or
worker and DEPARTMENT plays a role of department or employer.
 Each participating entity type name can be used as role name.

Recursive relationship
 In some cases, same entity participates more than once in a relationship type and plays
different roles.
 In such cases, role names become necessary for distinguishing the meaning of each
participation.
 Such relationship types are called Recursive relationship.

Recursive relationship and Roles: Example

A recursive relationship SUPERVISION between EMPLOYEE in the supervisor role (1) and
EMPLOYEE in the subordinate role (2)

Dr. Aparna K, Professor, Department of MCA, BMSIT&M Page 24

Database Management System

Constraints on Relationships
Structural Constraints on Relationship Types (Also known as ratio constraints) are
determined from the mini-world situation.
o Maximum Cardinality (or cardinality ratio)
o Minimum Cardinality (also called participation constraint or existence dependency
constraints)

Maximum Cardinality (or cardinality ratio) for Binary relationship

 It refers to the number of entities to which another entity can be associated via a
relationship set
 Cardinality must be one of the following types:
o One to one
o One to many
o Many to one
o Many to many
 Shown by placing appropriate number on the link.

One-to-One (1:1) Relationships

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

Dr. Aparna K, Professor, Department of MCA, BMSIT&M Page 25

Database Management System

One-to-Many (1:N) Relationships

An entity in A is associated with any number of entities in B, and an entity in B however can be
associated with at most one entity in A

1:1 & 1: N Relationships: Example

Many-to-1 (N:1) Relationships

An entity in A is associated with at most one entity in B, and an entity in B however can be
associated with any number of entities in A

Many-to-Many (N:1) Relationships

An entity in A is associated with any number of entities in B, and an entity in B can also be
associated with any number of entities in A

Dr. Aparna K, Professor, Department of MCA, BMSIT&M Page 26

Database Management System

N: 1 & N: M Relationships: Example

Participation constraint or existence dependency constraints

 The participation constraint specifies whether the existence of an entity depends on its
being related to another entity via the relationship type.
o Total Participation
o Partial participation

Total Participation
 Total Participation is a constraint when every entity in the entity set participates in at least
one relationship in the relationship set.
 Total Participation is also called existence dependency.
 Shown by double lining the link
For example
o Every employee must work in some department
o Every employee must work on some project

Partial Participation
 Partial participation is the constraint when some entities may not participate in any
relationship in the relationship set.

Dr. Aparna K, Professor, Department of MCA, BMSIT&M Page 27

Database Management System

 Represented by single line link.

o Example: participation of ‘EMPLOYEE’ as manager in relationship type ‘MANAGES’ is
partial

Attributes of Relationship types

 Relationship types can also have attributes similar to attributes of entity types.
 E.g. To record ‘Number of Hours per Week’ that an employee works on a particular project,
No_of_hours can be included as an attribute with relationship type ‘Works_on’.
 Attribute ‘Manager_start_date’ can be included with relationship type ‘Manages’.

Weak Entity Types

 An entity that does not have a key attribute is called weak entity type
 A weak entity cannot be identified without its owner.
 A weak entity type must participate in an identifying relationship type with an owner or
identifying entity type.
 A weak entity type always has a total participation constraint (existence dependency) with
respect to its identifying relationship.
 Weak entities are identified by the combination of:
o A partial key of the weak entity type
o The particular entity they are related to in the identifying entity type
For example:
 Weak Entity Type: DEPENDENT
 Identifying Relationship: HAS_DEPENDENTS
 Identifying Entity Type: EMPLOYEE
 Partial key of DEPENDENT: Dependent_name
 Thus, Primary key of DEPENDENT TABLE: (SSN, Dependent_name)

Dr. Aparna K, Professor, Department of MCA, BMSIT&M Page 28

Database Management System

Initial Conceptual Design of COMPANY Database

1. An entity type DEPARTMENT with attributes Name, Number, Location, Manager,
Manager_Start_Date. Location is multivalued. Name & Number are (separate) key attributes.

2. An entity type PROJECT with attributes Name, Number, Location, Controlling_Department.

Name & Number are (separate) key attributes.

3. An entity type EMPLOYEE with attributes SSN, Name, Sex, Address, Salary, Birth_date,
Department and Supervisor. Name & Address are composite, SSN is key attribute. Projects and
Number_Of_Hours for which Employee is working.

4. An entity type DEPENDENT with attributes Employee_Name, Dependent_Name, Sex,

Birth_date, Relationship (to Employee)

Dr. Aparna K, Professor, Department of MCA, BMSIT&M Page 29

Database Management System

Refining the ER Design for the Company Database

The cardinality ratio and participation constraint of each relationship type in company database
can be determined by the following requirements:

1. ‘manages’ a 1:1 relationship type between employee and department

 employee’s participation is partial but department participation is mandatory i.e. total
 the attribute StartDate is assigned to the relationship type

2. ‘works_for’, a N:1 relationship type between employee and department

 Both participations are total.

3. ‘controls’, a 1:N relationship type between department and project

 Participation of project is total but Participation of department is partial

4. ‘supervision’, a 1:N relationship type between employee and employee

 Both participation is partial

5. ‘works_on’, a M:N relationship type between employee and project

 Both participations are total.
 Attribute for this can be No-of-hours.

6. ‘has_dependents’, a 1:N relationship type between employee and dependent

 Participation of dependent is total but Participation of employee is partial
 Relationship is identifying for weak entity dependent.

Dr. Aparna K, Professor, Department of MCA, BMSIT&M Page 30

Database Management System

ER diagrams, naming conventions and design issues

 In ER diagram, emphasis is on representing the schema rather than the instances.
 Schema is much smaller than extensions
 Schema is relatively much more stable than extensions
o Schema changes rarely.
o Extensions changes frequently.

Notations for ER Diagrams

Dr. Aparna K, Professor, Department of MCA, BMSIT&M Page 31

Database Management System

Naming conventions of Schema constructs

 Singular names for entity type and relationship type
 Entity type & Relationship Type:
o Uppercase
 Attribute names:
o Capitalized
 Role names:
o Lowercase
 Nouns: Entity Type name
 Verbs: Relationship Type
 Additional Nouns that describe the nouns corresponding to Entity types: Attributes
 Binary relationship should be readable
o from left to right
o top to bottom

Dr. Aparna K, Professor, Department of MCA, BMSIT&M Page 32