300 3

DATABASE MANAGEMENT SYSTEMS

SYLLABUS

UNIT I INTRODUCTION (9
Hrs)
Database System Application – Purpose of Database Systems – View of Data – Database Languages –
Relational Database – Database Design – System Structure – Database Architecture. Database Design and
E-R Model: Overview of the Design Process – The E-R Model – Constraints – E-R Diagrams – E-R
Design Issues –Extended E-R features – Reduction to Relational Schemas – Other aspects of Database
Design.

UNIT II RELATIONAL MODEL (9

Hrs)
Structure of Relational Database – Fundamental Relational Algebra Operations – Extended Relational
Algebra Operations –. Structured Query Language: Introduction – Basic Structure of SQL Queries – Set
Operations – Additional Basic Operations – Aggregate Functions – Null Values – Nested Sub queries –
Views – Join Expression.

UNIT III RELATIONAL DATABASE DESIGN (9

Hrs)
Features of Good Relational Designs – 1NF – 2NF – 3NF – 4NF with Examples. Atomic Domains and First
Normal Form – Decomposition using Functional Dependencies – Functional Dependency Theory –
Algorithm for Decomposition – Decomposition using Multivalued Dependencies.

UNIT IV INDEXING, HASHING AND TRANSACTION MANAGEMENT (9

Hrs)
Basic Concepts – Ordered Indices – B+ Tree Index Files – B-Tree Files – Multiples – Key Access – Static
Hashing – Dynamic Hashing – Comparison of Ordered Indexing and Hashing – Bitmap Indices.
Transaction Management: Transaction Concept – Storage Structure – Transaction Atomicity and Durability
– Transaction Isolation and Atomicity – Serializability – Recoverability – Transaction Isolation Levels –
Implementation of Isolation Levels. Concurrency Control: Lock Based Protocols – Timestamp Based
Protocols – Validation Based Protocols. Recovery System: Failure Classification – Remote Backup
Systems

UNIT V NON RELATIONAL DATABASES (9

Hrs)
Parallel Databases-Architecture, Data partitioning strategy, Inter-query and Intra-query Parallelism,
Distributed Databases-Features – Distributed Database Architecture –Fragmentation –Replication-
Distributed Query Processing – Distributed Transactions Processing Spatial and Mobile Databases-Spatial
Databases-Type of spatial data–Indexing in spatial databases, Mobile Databases-Semi-Structured
Databases-Semi Structured databases – XML –Schema-DTD- XPath- XQuery

Text Books
1. Abraham Silberschatz, Henry F Korth, S Sudharshan, “Database System Concepts”, McGraw-Hill 7th
Edition, 2019.
2. RamezElmasri and ShamkantNavathe, Durvasula V L N Somayajulu, Shyam K Gupta, “Fundamentals of
Database Systems”, Pearson Education, United States of America, 2018.
3. AtulKahate, “Introduction to Database Management Systems”, Pearson Education, New Delhi, 2006.

Reference Books
Page 1
1. Date CJ, Kannan A, Swamynathan S, “An Introduction to Database System”, Pearson Education,
8th Edition, 2006.
2. Raghu Ramakrishna, Johannes Gehrke, “Database Management Systems”, McGraw Hill, 3rd
Edition, 2014.
3. G.K.Gupta, "Database Management Systems”, Tata McGraw Hill, 2011.
4. Jeffrey D. Ullman, “Principles of database systems”, Computer Science Press, 1982.
5. Paul Beynon-Davies, “Database Systems”, Palgrave Macmillan, 3rd Edition, 2003.

References:
1. Ramez Elmasri, Shamkant B. Navathe, “Fundamentals of Database
Systems”, FourthEdition , Pearson / Addision wesley, 2007.
2. Raghu Ramakrishnan, “Database Management Systems”, Third Edition,
McGraw Hill, 2003.
3. S.K.Singh, “Database Systems Concepts, Design and Applications”, First
Edition,

Web References
1. https://nptel.ac.in/courses/106/106/106106095/
2. https://docs.oracle.com/cd/E11882_01/server.112/e41084/toc.htm MySQL
Online Documentation
3. http://dev.mysql.com/doc/
4. http://www.rjspm.com/PDF/BCA-428%20Oracle.pdf
5. https://www.tutorialspoint.com/dbms/index.html
Pearson Education, 2006.

Page 2
UNIT I INTRODUCTION (9 Hrs)
Database System Application – Purpose of Database Systems – View of Data – Database Languages –
Relational Database – Database Design – System Structure – Database Architecture. Database Design
and E-R Model: Overview of the Design Process – The E-R Model – Constraints – E-R Diagrams –
E-R Design Issues –Extended E-R features – Reduction to Relational Schemas – Other aspects of
Database Design.

1.1 Database Management System (DBMS)

 Collection of interrelated data

 Set of programs to access the data
 DBMS contains information about a particular enterprise
 DBMS provides an environment that is both convenient and efficient to use.
 Database Applications:
Banking: all transactions
Airlines: reservations,
schedules Universities:
registration, grades
Sales: customers, products, purchases
Manufacturing: production, inventory, orders,
supply chain Human resources: employee records,
salaries, tax deductions

 Databases touch all aspects of our lives

1.2 PURPOSE OF DATABASE SYSTEM

 In the early days, database applications were built on top of file systems
 Drawbacks of using file systems to store data:
 Data redundancy and inconsistency
 Multiple file formats, duplication of information in different files

 Difficulty in accessing data

 Need to write a new program to carry out each new task

 Data isolation — multiple files and formats

 Integrity problems
 Integrity constraints (e.g. account balance > 0) become part of program code

 Hard to add new constraints or change existing ones

Page 3
  Atomicity of updates

 Failures may leave database in an inconsistent state with partial updates carried out
 E.g. transfer of funds from one account to another should either complete or not

happen at all
 Concurrent access by multiple users
 Concurrent accessed needed for performance

 Uncontrolled concurrent accesses can lead to inconsistencies

– E.g. two people reading a balance and updating it at the same time
 Security problems
 Database systems offer solutions to all the above problems

1.3 VIEWS OF DATA

1.3.1 Levels of Abstraction

 Physical level describes how a record (e.g., customer) is stored.

 Logical level: describes data stored in database, and the relationships among the data.
type customer = record
name : string; street : string; city : integer;
end;
 View level: application programs hide details of data types. Views can also hide
information (e.g., salary) for security purposes.
View of Data

1.3.2 Instances and Schemas

 Similar to types and variables in programming languages

 Schema – the logical structure of the database
e.g., the database consists of information about a set of customers and accounts and
the relationship between them)
Analogous to type information of a variable in a program Physical schema: database
design at the physical level Logical schema: database design at the logical level
 Instance – the actual content of the database at a particular point in time

Page 4
  Analogous to the value of a variable
 Physical Data Independence – the ability to modify the physical schema without

changing the logical schema

 Applications depend on the logical schema
 In general, the interfaces between the various levels and components should be well
defined so that changes in some parts do not seriously influence others.
1.4 DATABASE LANGUAGES

Database languages are specialized languages used to interact with a database. They
allow users to perform different tasks such as defining, controlling,
and manipulating the data. There are several types of database languages in DBMS,
categorized into the following four main types:
1. DDL (Data Definition Language)
2. DCL (Data Control Language)
3. DML (Data Manipulation Language)
4. TCL (Transaction Control Language)
Each category serves a different purpose within the database management process. Let's
break down each one.

1.4.1 DDL (Data Definition Language)

The DDL stands for Data Definition Language, Which is used to define the database's internal
structure and Pattern of the Database. It is used to define and modify the structure of the database
itself, including the tables, views, indexes, and other schema-related objects. It deals with the
creation and modification of database schema, but it doesn't deal with the data itself.
Following are the five DDL commands in SQL:
 CREATE: Used to create database objects like tables, indexes, or views.
 ALTER: Used to modify the structure of an existing database object, such as adding a new
column to a table.
 DROP: Used to delete database objects.

Page 5
  TRUNCATE: Used to remove all rows from a table, without affecting the structure.
 RENAME: Used to change the name of a database object.
Now we will explain each command with examples for better understanding of the concepts.
CREATE Command
The CREATE is a DDL command used to create databases, tables, triggers and other database
objects.
Syntax
CREATE TABLE Students (
column1 INT,
column2 VARCHAR(50),
column3 INT
);
Alter Command
ALTER is a DDL command which changes or modifies the existing structure of the database, and
it also changes the schema of database objects. We can also add and drop constraints of the table
using the ALTER command.
Syntax
ALTER TABLE Students ADD column_name;

Drop Command
DROP is a DDL command used to delete/remove the database objects from the SQL database. We
can easily remove the entire table, view, or index from the database using this DDL command.
Syntax
DROP Table Table_name;

Truncate Command
The TRUNCATE command is used to delete all the records from a table without removing the
structure. Unlike the DELETE command, which can remove specific rows and can be rolled
back, TRUNCATE is a more efficient way to delete all rows in a table without logging individual
row deletions.
Syntax
TRUNCATE TABLE table_name;

Rename Command
The RENAME command in a Database Management System (DBMS) is used to change the name of
a database object, such as a table, column, or index. This command is helpful when we want to give a
more meaningful or appropriate name to an object without needing to recreate it.
Syntax:
ALTER TABLE Old_Table_Name RENAME TO New_Table_Name;

Page 6
 1.4.2 DCL (Data Control Language)
DCL stands for Data Control Language. It is used to control the access permissions of users to the
database. DCL commands help grant or revoke privileges to users, determining who can perform
actions like reading or modifying data. DCL commands are transactional, meaning they can be
rolled back if necessary.
The two main DCL commands are:
 Grant: Gives user access to the database
 Revoke: Removes access or permissions from the user
Now we will explain these commands with proper examples for better understanding

Grant Command
The GRANT command in a Database Management System (DBMS) is used to provide
specific permissions or privileges to users or roles. This command allows administrators to control
access to database objects, ensuring that only authorized users can perform certain actions, such as
selecting, inserting, updating, or deleting data.
Syntax
GRANT privileges
ON object
TO user_or_role [WITH GRANT OPTION];

Revoke Command
The REVOKE command in a Database Management System (DBMS) is used to remove previously
granted permissions or privileges from users or roles. This command is essential for managing
access control, ensuring that users do not have more privileges than necessary to perform their tasks.
Syntax
REVOKE privileges ON object FROM user_or_role;

1.4.3 DML (Data Manipulation Language)

The DML (Data Manipulation Language) is used toto manage and manipulate data within a database.
With DML, you can perform various operations such as inserting, updating, selecting, and deleting
data. These operations allow you to work with the actual content in your database tables.
Here are the key DML commands:
 SELECT: Retrieves data from the table based on specific criteria.
 INSERT: Adds new rows of data into an existing table.
 UPDATE: Modifies existing data in a table.
 DELETE: Removes data from a table.
 MERGE: Performs an "upsert" operation, which means updating existing records or inserting new
ones if they don’t exist.
 CALL: Executes stored procedures or functions.
 LOCK TABLE: Prevents other users from accessing the table while changes are being made.
Now, we will explain these commands with examples for better understanding:

Page 7
SELECT Command
The SELECT command in SQL (Structured Query Language) is used to retrieve data from one or
more tables in a database. It is the most commonly used commands in SQL, allowing users to specify
which columns and rows of data they want to retrieve and how they want that data organized.
The SELECT statement can be used in various ways, such as selecting all data from a table, filtering
records based on conditions, or sorting the results.
Syntax
SELECT * FROM Table_Name

Insert Command
The INSERT command in SQL (Structured Query Language) is used to add new records or rows to
a table in a database. It is a key operation in database management, essential for populating tables
with new data. This command can insert data into all columns or specific columns of a table.
Syntax
INSERT INTO Table_Name (Column 1, Column 2, Column 3, Column 4) VALUES (Value 1, Value
2,Value 3, Value 4);

Update Command
The UPDATE command in SQL (Structured Query Language) is used to modify existing records in
a table. This command enables users to change the values of one or more columns for specific rows
based on a condition (criteria). It is crucial for maintaining and adjusting data in a database when
necessary.
Syntax
UPDATE Table_Name SET Name = 'New_Value' WHERE Name = 'Ola_Value';
Delete Command
The DELETE command in SQL (Structured Query Language) is used to remove one or more
existing records from a table in a database. It is an essential operation for managing data, enabling
users to delete specific rows that meet certain conditions or criteria.
Syntax:
DELETE FROM Table_Name WHERE Column = Value;

Merge Command
The Merge command in SQL is used to perform an upsert operation, which combines
both UPDATE and INSERT actions. It allows you to insert new rows if they do not exist, or update
existing rows if they match a certain condition. This command is particularly useful for
synchronizing two tables by inserting new records and updating existing ones in a single operation.
Syntax:
MERGE INTO target_table AS target
USING source_table AS source
ON (target.id = source.id)

Page 8
 WHEN MATCHED THEN
UPDATE SET target.name = source.name
WHEN NOT MATCHED THEN
INSERT (id, name) VALUES (source.id, source.name);

CALL Command
The Call command is used to invoke a stored procedure or user-defined function, which is a set of
precompiled SQL statements. It allows you to execute complex operations within a database as a
single unit.
Syntax:
CALL user_defined_function(parameter 1, parameter 2);

LOCK TABLE
The lock table command is used to lock the table for preventing access from others, ensuring no
other operations (like insertions, updates, or deletions) can be performed on the table while it's
locked. Useful for transactional operations where consistency is important.
Syntax:
LOCK TABLE your_table IN EXCLUSIVE MODE;

1.4.4 TCL ( Transaction Control Language )

The TCL full form is Transaction Control Language commands are used to manage and control
transactions in a database, grouping them into logical units. These commands help ensure the
integrity of data and consistency during complex operations. Here are the two main commands in
this category:
 Commit: Saves all the changes made during the current transaction to the database. These are very
useful in the banking sector.
 Rollback: used to restore the database to its original state from the last commit. This command
also plays an important role in Banking Sectors.
Now we will explain these two commands for better understanding with examples

Commit Command
The COMMIT command is used to save all changes made during a transaction in the database.
This command ensures that modifications made by DML statements (such as INSERT, UPDATE,
or DELETE) become permanent in the database.
Syntax
Database Operation
Commit

ROLLBACK Command
The rollback command is used to restore the database to its state at the last COMMIT, effectively
undoing any changes made since that point. It helps ensure data consistency by allowing the reversal
of partial or erroneous operations.
Page 9
Syntax
ROLLBACK;

1.5 RELATIONAL DATABASE

A relational database is a type of database that organizes data into rows and columns, which collectively
form a table where the data points are related to each other.

Data is typically structured across multiple tables, which can be joined together via a primary key or a
foreign key. These unique identifiers demonstrate the different relationships which exist between tables,
and these relationships are usually illustrated through different types of data models. Analysts use SQL
queries to combine different data points and summarize business performance, allowing organizations to
gain insights, optimize workflows, and identify new opportunities.

For example, imagine your company maintains a database table with customer information, which
contains company data at the account level. There may also be a different table, which describes all the
individual transactions that align to that account. Together, these tables can provide information about
the different industries that purchase a specific software product.

The columns (or fields) for the customer table might be Customer ID, Company Name, Company
Address, Industry etc.; the columns for a transaction table might be Transaction Date, Customer
ID, Transaction Amount, Payment Method, etc. The tables can be joined together with the
common Customer ID field. You can, therefore, query the table to produce valuable reports, such as a
sales reports by industry or company, which can inform messaging to prospective client

Page 10
 1.6 DATABASE SYSTEM STRUCTURE

1. Query Processor:
It interprets the requests (queries) received from end user via an application program into
instructions. It also executes the user request which is received from the DML compiler.
Query Processor contains the following components –
 DML Compiler: It processes the DML statements into low level instruction (machine
language), so that they can be executed.
 DDL Interpreter: It processes the DDL statements into a set of table containing meta
data (data about data).
 Embedded DML Pre-compiler: It processes DML statements embedded in an
application program into procedural calls.
 Query Optimizer: It executes the instruction generated by DML Compiler.

Page 11
2. Storage Manager:
Storage Manager is a program that provides an interface between the data stored in the
database and the queries received. It is also known as Database Control System. It
maintains the consistency and integrity of the database by applying the constraints and
executing the DCL statements. It is responsible for updating, storing, deleting, and
retrieving data in the database.
It contains the following components –
 Authorization Manager: It ensures role-based access control, i.e,. checks whether
the particular person is privileged to perform the requested operation or not.
 Integrity Manager: It checks the integrity constraints when the database is modified.

 Transaction Manager: It controls concurrent access by performing the operations in

a scheduled way that it receives the transaction. Thus, it ensures that the database
remains in the consistent state before and after the execution of a transaction.
 File Manager: It manages the file space and the data structure used to represent
information in the database.
 Buffer Manager: It is responsible for cache memory and the transfer of data between
the secondary storage and main memory.
3. Disk Storage:
It contains the following components:
 Data Files: It stores the data.
 Data Dictionary: It contains the information about the structure of any database
object. It is the repository of information that governs the metadata.
 Indices: It provides faster retrieval of data item

1.7 DATABASE ARCHITECTURE

1.7.1 APPLICATION ARCHITECTURES
Two-tier architecture: E.g. client programs using ODBC/JDBC to communicate
with a database
Three-tier architecture: E.g. web-based applications and applications built using
―middleware‖ .

Page 12
1.7.2 DATABASE USERS
Users are differentiated by the way they expect to interact with the system
• Application programmers – interact with system through DML calls

• Sophisticated users – form requests in a database query language

• Specialized users – write specialized database applications that do not fit

into the traditional data processing framework
• Naïve users – invoke one of the permanent application programs that have been
written previously
– Examples, people accessing database over the web, bank tellers, clerical staff.

1.7.3 DATABASE ADMINISTRATOR

 Coordinates all the activities of the database system; the database administrator
has a good understanding of the enterprise‘s information resources and needs.
 Database administrator's duties include:
– Schema definition
– Storage structure and access method definition
– Schema and physical organization modification
– Granting user authority to access the database
– Specifying integrity constraints

– Acting as liaison with users

– Monitoring performance and responding to changes in requirements

1.8 DATA MODELS

 A collection of tools for describing
Page 13
 data
 data relationships
 data semantics
 data constraints
 Entity-Relationship model
 Relational model
 Other models:
 object-oriented model
 semi-structured data models
 Older models: network model and hierarchical model
1.9 ENTITY-RELATIONSHIP MODEL

Schema in the entity-relationship model

 A database can be modeled as:

 a collection of entities,
 relationship among entities.
 An entity is an object that exists and is distinguishable from other objects.
 Example: specific person, company, event, plant
 Entities have attributes
 Example: people have names and addresses
 An entity set is a set of entities of the same type that share the same properties.
 Example: set of all persons, companies, trees, holidays

1.10 E-R Diagrams

Symbols Used in E-R Notation

Page 14
 Example:

Rectangles represent entity sets.

Diamonds represent relationship sets.
Lines link attributes to entity sets and entity sets to relationship sets.
Ellipses represent attributes
Double ellipses represent multivalued attributes.
Dashed ellipses denote derived attributes.
Underline indicates primary key attributes

1.10.1 ENTITY SETS CUSTOMER AND LOAN ATTRIBUTES

Page 15
1.10.2 ATTRIBUTES
 An entity is represented by a set of attributes, which are descriptive properties possessed by all
members of an entity set.
 Domain – the set of permitted values for each attribute

 Attribute types:
 Simple and composite attributes.
 Single-valued and multi-valued attributes
 E.g. multivalued attribute: phone-numbers

 Derived attributes
 Can be computed from other attributes

 E.g. age, given date of birth

Composite Attributes

Page 16
E-R Diagram with Composite, Multivalued, and Derived Attributes

1.10.3 Relationship Sets

 A relationship is an association among several entities

Example:
Hayes depositor A-102
customer entity relationship set account entity
 A relationship set is a mathematical relation among n 2 entities, each taken from entity
sets

{(e1, e2, … en) | e1 E1, e2 E2, …, en En}

where (e1, e2, …, en) is a relationship

 Example:

(Hayes, A-102) depositor

 An attribute can also be property of a relationship set.
 For instance, the depositor relationship set between entity sets customer and account may
have the attribute access-date

Page 17
1.10.3.1 Degree of a Relationship Set
1.10.3.1.1 Refers to number of entity sets that participate in a relationship set.
1.10.3.1.2 Relationship sets that involve two entity sets are binary (or
degree two). Generally, most relationship sets in a database
system are binary.
1.10.3.1.3 Relationship sets may involve more than two entity sets.
1.10.3.1.4 Relationships between more than two entity sets are rare. Most relationships are binary.

Page 18
 1.10.4 Relationship Sets with Attributes

1.10.5 Mapping Cardinalities

 Express the number of entities to which another entity can be associated via a
relationship set.
 Most useful in describing binary relationship sets.
 For a binary relationship set the mapping cardinality must be one of the following types:
 One to one
 One to many
 Many to one
 Many to many

one to one many to many

Many to one Many to Many

Page 19
 Many to One Many to Many

1.10.5.1 Mapping Cardinalities affect ER Design

 Can make access-date an attribute of account, instead of a relationship attribute, if each

account can have only one customer
i.e., the relationship from account to customer is many to one, or equivalently,
customer to account is one to many

1.10.6 Roles
 Entity sets of a relationship need not be distinct
 The labels ―manager‖ and ―worker‖ are called roles; they specify how employee entities
interact via the works-for relationship set.
 Roles are indicated in E-R diagrams by labeling the lines that connect diamonds to
rectangles.
 Role labels are optional, and are used to clarify semantics of the relationship

Page 20
 1.10.7 Cardinality Constraints
 We express cardinality constraints by drawing either a directed line ( ), signifying
―one,‖ or an undirected line (—), signifying ―many,‖ between the relationship set and the
entity set.

1.10.7.1 One-to-one relationship:

 A customer is associated with at most one loan via the relationship borrower
 A loan is associated with at most one customer via borrower

1.10.7.2 One-To-Many Relationship

In the one-to-many relationship a loan is associated with at most one customer via
borrower, a customer is associated with several (including 0) loans via borrower

1.10.7.3 Many-To-One Relationships

Page 21
 In a many-to-one relationship a loan is associated with several (including 0) customers via
borrower, a customer is associated with at most one loan via borrower

1.10.7.4 Many-To-Many Relationship

A customer is associated with several (possibly 0) loans via borrower
A loan is associated with several (possibly 0) customers via borrower

1.10.8 Participation of an Entity Set in a Relationship Set

 Total participation (indicated by double line): every entity in the entity set participates in
at least one relationship in the relationship set
 E.g. participation of loan in borrower is total
 Every loan must have a customer associated to it via borrower
 Partial participation: some entities may not participate in any relationship in the
relationship set
 E.g. participation of customer in borrower is partial
 Cardinality limits can also express participation constraints

Page 22
 1.10.8.1 Alternative Notation for Cardinality Limits
 Cardinality limits can also express participation constraints

1.11 Keys

o Keys play an important role in the relational database.

o It is used to uniquely identify any record or row of data from the table. It is also used to
establish and identify relationships between tables.
For example, ID is used as a key in the Student table because it is unique for each student.
In the PERSON table, passport_number, license_number, SSN are keys since they are
unique for each person.

Types of keys:

1. Primary key

o It is the first key used to identify one and only one instance of an entity uniquely. An entity can
contain multiple keys, as we saw in the PERSON table. The key which is most suitable from
those lists becomes a primary key.

Page 23
o In the EMPLOYEE table, ID can be the primary key since it is unique for each employee. In the
EMPLOYEE table, we can even select License_Number and Passport_Number as primary keys
since they are also unique.
o For each entity, the primary key selection is based on requirements and developers.

2. Candidate key

o A candidate key is an attribute or set of attributes that can uniquely identify a tuple.
o Except for the primary key, the remaining attributes are considered a candidate key. The candidate keys are as
strong as the primary key.
For example: In the EMPLOYEE table, id is best suited for the primary key. The rest of the attributes, like
SSN, Passport_Number, License_Number, etc., are considered a candidate key.

3. Super Key
Super key is an attribute set that can uniquely identify a tuple. A super key is a superset of a candidate key.

Page 24
For example: In the above EMPLOYEE table, for(EMPLOEE_ID, EMPLOYEE_NAME), the name
of two employees can be the same, but their EMPLYEE_ID can't be the same. Hence, this
combination can also be a key. The super key would be EMPLOYEE-ID (EMPLOYEE_ID,
EMPLOYEE-NAME), etc.

4. Foreign key

o Foreign keys are the column of the table used to point to the primary key of another table.
o Every employee works in a specific department in a company, and employee and department are
two different entities. So we can't store the department's information in the employee table. That's
why we link these two tables through the primary key of one table.
o We add the primary key of the DEPARTMENT table, Department_Id, as a new attribute in the
EMPLOYEE table.
o In the EMPLOYEE table, Department_Id is the foreign key, and both the tables are related.

5. Composite key
Whenever a primary key consists of more than one attribute, it is known as a composite key. This
key is also known as Concatenated Key.

Page 25
For example, in employee relations, we assume that an employee may be assigned multiple roles, and
an employee may work on multiple projects simultaneously. So the primary key will be composed of
all three attributes, namely Emp_ID, Emp_role, and Proj_ID in combination. So these attributes act as
a composite key since the primary key comprises more than one attribute.

1.9 Design Issues

 Use of entity sets vs. attributes
Choice mainly depends on the structure of the enterprise being modeled, and on the
semantics associated with the attribute in question.
 Use of entity sets vs. relationship sets
Possible guideline is to designate a relationship set to describe an action that occurs
between entities
 Binary versus n-ary relationship sets
Although it is possible to replace any nonbinary (n-ary, for n > 2) relationship set by a number
of distinct binary relationship sets, a n-ary relationship set shows more clearly that several
entities participate in a single relationship.
 Placement of relationship attributes

1.10 Other aspects of Database Design

 Top-down design process; we designate subgroupings within an entity set that are
distinctive from other entities in the set.
 These subgroupings become lower-level entity sets that have attributes or participate in
relationships that do not apply to the higher-level entity set.
 Depicted by a triangle component labeled ISA (E.g. customer ―is a‖ person).
 Attribute inheritance – a lower-level entity set inherits all the attributes and relationship
participation of the higher-level entity set to which it is linked.

Page 26
1.10.1 Specialization Example

1.11.2 Generalization

 A bottom-up design process – combine a number of entity sets that share the same
features into a higher-level entity set.
 Specialization and generalization are simple inversions of each other; they are
represented in an E-R diagram in the same way.
 The terms specialization and generalization are used interchangeably.
 Can have multiple specializations of an entity set based on different features.
 E.g. permanent-employee vs. temporary-employee, in addition to officer vs. secretary vs.
teller
 Each particular employee would be
 a member of one of permanent-employee or temporary-employee,
 and also a member of one of officer, secretary, or teller
 The ISA relationship also referred to as superclass - subclass relationship

1.11.3 Design Constraints on a Specialization/Generalization

 Constraint on which entities can be members of a given lower-level entity set.

 condition-defined
 E.g. all customers over 65 years are members of senior-citizen entity set; senior- citizen

ISA person.

Page 27
  user-defined
 Constraint on whether or not entities may belong to more than one lower-level entity set
within a single generalization.
 Disjoint
 an entity can belong to only one lower-level entity set

 Noted in E-R diagram by writing disjoint next to the ISA triangle

 Overlapping
 an entity can belong to more than one lower-level entity set

 Completeness constraint -- specifies whether or not an entity in the higher-level entity set must
belong to at least one of the lower-level entity sets within a generalization.
 total : an entity must belong to one of the lower-level entity sets
 partial: an entity need not belong to one of the lower-level entity sets

1.12 Aggregation

 Relationship sets works-on and manages represent overlapping information

 Every manages relationship corresponds to a works-on relationship
 However, some works-on relationships may not correspond to any manages relationships
 So we can‘t discard the works-on relationship

 Eliminate this redundancy via aggregation

 Treat relationship as an abstract entity
 Allows relationships between relationships
 Abstraction of relationship into new entity
 Without introducing redundancy, the following diagram represents:
 An employee works on a particular job at a particular branch
 An employee, branch, job combination may have an associated manager

1.12.1 E-R Diagram With Aggregation

Page 28
1.13 E-R Design Decisions
 The use of an attribute or entity set to represent an object.
 Whether a real-world concept is best expressed by an entity set or a relationship set.
 The use of a ternary relationship versus a pair of binary relationships.
 The use of a strong or weak entity set.
 The use of specialization/generalization – contributes to modularity in the design.
 The use of aggregation – can treat the aggregate entity set as a single unit without
concern for the details of its internal structure.

1.14 Relational Schema

Relation schema defines the design and structure of the relation or table in the database. It is the
way of representation of relation states in such a way that every relation database state fulfills the
integrity constraints set (Like Primary key, Foreign Key, Not null, Unique constraints) on a
relational schema.
It consists of the relation name, set of attributes/field names/column names. every attribute would
have an associated domain

1.14 E-R Diagram for a Banking Enterprise

Page 29