DATABASE MANAGEMENT SYSTEM

Dept of ISE

Subject code : BCS403

Prof. Vinutha Raghu Prof. Usha Kumari V
Assistant Professor Assistant Professor
Department of ISE Department of ISE
Acharya Institute Of Acharya Institute Of Technology
Technology
 MODULE 1
Chapter 1- Introduction to Databases
Chapter 2- Overview of Database Languages
Dept of ISE
and Architectures
Chapter 3- Conceptual Data modelling using
Entities and Relationships
 Chapter 1- Introduction to Databases

1.1- Introduction
1.2- Characteristics of database approach
1.3- Advantages of using the DBMS approach
1.4- History of Database applications
Dept of ISE
 1.1- Introduction
https://www.youtube.com/watch?v=X7v0O8yiUuY

Dept of ISE
 INTRODUCTION

•A database is a collection of related data.

•For example, consider the names, telephone numbers, and addresses of the people
you know. Nowadays, this data is typically stored in mobile phones, which have
their own simple database software.
•A database can be of any size and complexity.
•An example of a large commercial database is Amazon.com. (The database is
Dept of ISE continually updated )
•A database may be generated and maintained manually or it may be computerized.
 1.2- Characteristics of
database approach
Dept of ISE
 Characteristics of database approach

• 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
Dept of ISE
 (i)Self-describing nature of a database system

• A general-purpose DBMS software package is not written for a

specific database application. Therefore, it must refer to the
catalog to know the structure of the files in a specific database,
such as the type and format of data it will access.
• This definition is stored in the DBMS catalog, which contains
information such as the structure of each file, the type and
storage format of each data item, and various constraints on the
data.
Dept of ISE • The information stored in the catalog is called meta-data.
• It is important to note that some newer types of database
systems, known as NOSQL systems, do not require meta-data.
• Rather the data is stored as self-describing data that includes the
data item names and data values together in one structure.
 Fig: Shows some entries in a database catalog

Dept of ISE
 (ii) Insulation between programs and data, and data abstraction

• Insulation between programs and data refers to the separation of data

management from application programs.
• Program-data independence Changes in the data structure (e.g., adding a new
column in a table) do not affect the programs that use the database.
Example: If a database stores student records and a new "email" field is
added, the existing applications that fetch student names will still work fine.

• Program-operation independence Changes in the logic of operations (how

Dept of ISE data is processed) do not require changes in how applications access data.
Example: If a database operation for calculating student grades is
modified, the applications using it will not need changes.

• Both are critical features that enhance the flexibility, maintainability, and
scalability of database systems.
• The characteristic that allows program-data independence and
program-operation independence is called data abstraction.
 Data Abstraction & Data Model:

• Data abstraction helps users work with data without needing to know how it
is stored or managed internally.
• A data model provides a simplified view of data and hides technical details
like file structures and indexing.

Dept of ISE
 (iii)Support of multiple views of the data
• A database typically has many types of users, each of whom may require
a different perspective or 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.

• A multiuser DBMS whose users have a variety of distinct applications

must provide facilities for defining multiple views.
Dept of ISE Ex: One user of the database of may be interested only in accessing and
printing the USN of each student.
 (iv) Sharing of data and multiuser transaction processing
• A multiuser DBMS, as its name implies, must allow multiple users to access the
database at the same time.
• The DBMS must include concurrency control software.

• For example, when several reservation agents try to assign a seat on an airline
flight, the DBMS should ensure that each seat can be accessed by only one agent at
a time for assignment to a passenger. These types of applications are generally
called online transaction processing (OLTP) applications.

• The concept of a transaction has become central to many database applications. A

transaction is an executing program or process that includes one or more database
Dept of ISE
accesses, such as reading or updating of database records.
Key Properties of Transactions:
1.Isolation:
1. Each transaction works as if it’s the only one running, even if many
transactions are happening at the same time.
2. No transaction can interfere with another.
2.Atomicity:
1. All operations in a transaction are completed, or none of them are.
2. If something goes wrong, the database is left unchanged.
 1.3- Advantages of using
the DBMS approach
Dept of ISE
 Advantages of using the DBMS approach

1. Controlling Redundancy
2. Restricting Unauthorized Access
3. Providing Persistent Storage for Program Objects
4. Providing Storage Structures and Search Techniques for Efficient Query
Processing
5. Providing Backup and Recovery
6. Providing Multiple User Interfaces
7. Representing Complex Relationships among Data
Dept of ISE
8. Enforcing Integrity Constraints
9. Permitting Inferencing and Actions Using Rules and Triggers
10. Additional Implications of Using the Database Approach
 (1)Controlling Redundancy
• Redundancy in databases means storing the same data multiple
times in different places.
• While this might seem convenient in some cases, it leads to several
problems:
a. Duplication of Effort
b. Wasted Storage
c. Inconsistency
• To solve these problems, data normalization is used. It means we
Dept of ISE store each piece of data (like a student's name or birthdate) only
once in the database. This keeps everything consistent, saves space,
and avoids errors.
• However, sometimes controlled redundancy is used intentionally for
performance reasons.
• This is called denormalization. It helps speed up the system by
reducing the need to search multiple places for related data.
 (2) Restricting Unauthorized Access
• When many people share a large database, not everyone should have access
to all the information in it.
• For example: Confidential Information: Data like salaries or bonuses is
private and can only be seen by authorized people.
Hence, the type of access operation—retrieval or update—must also be
controlled.

A DBMS should provide a security and authorization subsystem,

which the Database Administrator (DBA) uses to create accounts and to specify
Dept of ISE account restrictions.

In short, the database ensures that people only see and do what they are
allowed to, keeping the data secure and organized.
 (3)Providing Persistent Storage for Program Objects
• Object-oriented database systems enable persistent storage of program
objects and data structures, allowing them to survive after a program ends.
• This eliminates the need for manual conversions to and from file formats, as
the database system automatically handles these.
• Programming languages like C++ and Java integrate seamlessly with these
databases, allowing objects to be stored and retrieved directly, ensuring
convenience and consistency.
Dept of ISE • Object-oriented database systems address the impedance mismatch problem
by providing compatibility between database data structures and
programming language data structures.
 (4) Providing Storage Structures and Search Techniques for
Efficient Query Processing

• The database is typically stored on disk, the DBMS must provide specialized data
structures and search techniques to speed up disk search for the desired
records.
• Auxiliary files called indexes are often used for this purpose. Indexes are
typically based on tree data structures or hash data structures that are suitably
modified for disk search.
• The DBMS often has a buffering or caching module that maintains parts of the
Dept of ISE database in main memory buffers.(to avoid disk-to-memory buffering )
• The choice of which indexes to create and maintain is part of physical database
design and tuning, which is one of the responsibilities of the DBA staff.
 (5) Providing Backup and Recovery

• A DBMS must provide facilities for recovering from hardware or software

failures.
• The backup and recovery subsystem of the DBMS is responsible for
recovery.
• Disk backup is also necessary in case of a catastrophic disk failure.
• For example, if the computer system fails in the middle of a complex update
transaction, the recovery subsystem is responsible for making sure that the
database is restored to the state it was in before the transaction started
Dept of ISE executing.
 (6) Providing Multiple User Interfaces
• Many types of users with varying levels of technical knowledge use a
database, a DBMS should provide a variety of user interfaces.
• Forms-style interfaces and menu-driven interfaces are commonly
known as graphical user interfaces (GUIs).
• Web GUI interfaces to a database—or Web-enabling a
database—are also quite common.

(7) Representing Complex Relationships among Data

• A database may include numerous varieties of data that are
Dept of ISE interrelated in many ways.
• A DBMS must have the capability to represent a variety of complex
relationships among the data, to define new relationships as they
arise, and to retrieve and update related data easily and efficiently.
 (8) Enforcing Integrity Constraints

• The simplest type of integrity constraint involves specifying a data type

for each data item.
• A more complex type of constraint that frequently occurs involves
specifying that a record in one file must be related to records in other
files.
• This is known as a referential integrity constraint.
• Another type of constraint specifies uniqueness on data item values,
this is known as a key or uniqueness constraint.
Dept of ISE
 (9) Permitting Inferencing and Actions Via Rules
• Deductive Database Systems:
In a deductive database system, one may specify declarative rules
that allow the database to infer new data. For example, a rule
might determine which students are on probation based on their
grades. If the rule changes, you just update it instead of rewriting a
program.
• Active Database Systems:
These are smarter databases that can automatically respond to
events or conditions without waiting for someone to trigger them.
Dept of ISE For instance, if a student's attendance drops below 75%, the
database might automatically send a warning email.
 (10) Additional Implications of Using the Database Approach

• Potential for Enforcing Standards

• Reduced Application Development Time
• Flexibility
• Availability of Up-to-Date Information
• Economies of Scale

Dept of ISE
 1.4- History of Database
applications
Dept of ISE
 History of Database applications
1. Early Database Systems (Hierarchical and Network)
•Early systems were used in organizations like universities, banks, and
hospitals.
•Data was tightly linked to its physical storage, making it hard to reorganize
or handle new queries.
•Required complex programming for new queries.

2. Relational Databases
•Introduced in the 1980s to separate data storage from its representation.
•Provided flexibility and program-data independence.
Dept of ISE
•Supported high-level query languages, making queries easier and faster
to write.
•Became the dominant database system over time due to improved
performance.

3. Object-Oriented Databases (OODBs)

•Emerged in the 1980s to handle complex data like structured objects.
•Useful for specialized applications (e.g., engineering, multimedia).
•Later integrated with relational databases to form object-relational systems
(ORDBMSs).
 4. XML for Data Sharing on the Web
•XML became a standard for sharing dynamic data (like prices, flight info) on
websites.
•Combines document and database modelling concepts.
•Widely used for e-commerce and data interchange.

5. Specialized Applications
•New database extensions support applications like:
• Scientific data (e.g., genome mapping, physics experiments).
• Images and videos (e.g., X-rays, satellite images).
Dept of ISE • Data mining (e.g., detecting fraud).
• Geographical data (e.g., maps, weather).
• Time-series data (e.g., sales trends).
•Added features like new data types, operations, and indexing for these uses.

6. Big Data and NOSQL

•Social media, e-commerce, and cloud storage led to huge data volumes.
•NOSQL systems emerged to handle unstructured data (e.g., posts, tweets).
•Combines traditional SQL databases with NOSQL as per application needs.
Dept of ISE
 Chapter 2- Overview of Database Languages and Architectures

2.1- Data Models, Schemas and Instances

2.2- Three Schema Architecture and Data Independence
2.3- Database Languages and Interfaces
2.4- The Database System Environment

Dept of ISE
 2.1- Data Models, Schemas and
Instances
Dept of ISE
 Data Models

• Data abstraction generally refers to the suppression of details of data

organization and storage, and the highlighting of the essential features for an
improved understanding of data. Ex: ATM machine

• One of the main characteristics of the database approach is to support data

abstraction so that different users can perceive data at their preferred level of
detail.

Dept of ISE • A data model—a collection of concepts that can be used to describe the structure
of a database—provides the necessary means to achieve this abstraction

• By structure of a database means the data types, relationships, and constraints

that apply to the data. Most data models also include a set of basic operations for
specifying retrievals and updates on the database.
 Categories of Data Models
1. High-level or conceptual data models

• Provide concepts that are close to the way many users perceive
data -use concepts such as entities, attributes, and relationships.
• An entity represents a real-world object or concept, such as an
employee or a project from the miniworld that is described in the
database.
Dept of ISE • An attribute represents some property of interest that further
describes an entity, such as the employee’s name or salary.
• A relationship among two or more entities represents an
association among the entities., for example, a works- on
relationship between an employee and a project.
Dept of ISE
 2. Low-level or physical data models
• Provide concepts that describe the details of how data is stored
on the computer storage media, typically magnetic disks.
• Concepts provided by low-level data models are generally meant
for computer specialists, not for end users.

3. Representational (or implementation) data models

Dept of ISE • Provide concepts that may be easily understood by end users but
that are not too far removed from the way data is organized in
computer storage
• In between high level and low level hide many details of data
storage on disk but can be implemented on a computer system
directly
 These models bridge conceptual and physical models, providing a
structured way to store and manipulate data

Examples:
Relational Model – Uses tables, primary keys, and foreign keys
(e.g., MySQL, PostgreSQL).
Document-Oriented Model – Stores data as documents
(e.g., MongoDB, CouchDB).
Key-Value Model – Stores key-value pairs
(e.g., Redis, DynamoDB).
Columnar Model – Stores data in columns instead of rows
Dept of ISE (e.g., Apache Cassandra, HBase).
 Schemas and Instances

• The description of a database is called the database schema, which is specified during
database design and is not expected to change frequently.
• The data in the database at a particular moment in time is called a database state/
SNAPSHOT / current set of occurrences / instances in the database

Dept of ISE
 Schemas and Instances

• The description of a database is called the database schema, which is specified during
database design and is not expected to change frequently.
• The data in the database at a particular moment in time is called a database state/
SNAPSHOT / current set of occurrences / instances in the database.
• In a given database state, each schema construct has its own current set of instances;
for example, the STUDENT construct will contain the set of individual student entities
(records) as its instances.

Dept of ISE
 Three Schema Architecture and
Dept of ISE
Data Independence
 Three Schema Architecture
• The goal of the three-schema architecture, illustrated in Figure 2.2, is to separate the user
applications from the physical database.

Dept of ISE

Fig: The three-schema

architecture.
Dept of ISE
 1. External Level (External Views)
• Description:
• Represents the user's view of the database.
• It focuses on how different users or applications interact with the database.
• Each user sees only the relevant parts of the data, customized to their needs.
• Purpose:
• Simplifies the interface for users.
• Hides complex structures and implementation details from the end-users.

2. Conceptual Level (Conceptual Schema)

Dept of ISE
• Description:
• Describes the overall structure of the database.
• It includes all entities, their attributes, relationships, constraints, and semantic
me
• aning.
• Serves as an intermediary between the external and internal levels.
• Purpose:
• Provides a unified view of the data for all users.
• Ensures data consistency and integrity by defining the logical schema.
 3. Internal Level (Internal Schema)
• Description:
• Focuses on the physical storage and retrieval of data.
• Describes the file structure, indexing methods, and access
paths.
• Purpose:
• Optimizes storage space and data retrieval.
Dept of ISE
• Implements the conceptual schema at the hardware level.
 Data Independence in DBMS

• Data Independence refers to the ability to modify the database schema at one
level without altering the schema at the next higher level. It ensures that
changes to the database structure or storage do not affect how the data is
accessed or viewed by users.
• Data Independence is achieved through the three-schema architecture in
DBMS.
• We can define two types of data independence:
• Logical Data Independence
Dept of ISE • Physical Data Independence
 • Logical Data Independence
• Definition:
• The ability to change the conceptual schema (logical structure of the
database) without affecting the external schema (user views).
• What can be changed:
• Adding or removing entities, attributes, or relationships.
• Modifying constraints such as keys.
• Why it’s important:
Dept of ISE • User applications or queries don’t need to be modified when the
database's logical design changes.
• Example:
• Adding a new attribute PhoneNumber to the STUDENT table should not
affect user queries that only retrieve the Name and Age.
 • Physical Data Independence
• Definition:
• The ability to change the internal schema (physical storage of the
database) without affecting the conceptual schema or external schema.
• What can be changed:
• File organization, indexing, or access methods.
• Storage hardware or data compression techniques.
• Why it’s important:
Dept of ISE • Optimizations at the storage level do not disrupt database functionality
or logical structure.
 2.3- Database Languages and
Interfaces
Dept of ISE
 Database Languages
These are specialized programming or query languages used for
creating, accessing, and managing data in a database.
Commonly used database languages include:

1. Data Definition Language (DDL)

•Purpose: Defines the database structure or schema. Is used by
the DBA and by database designers to define both schemas.
Dept of ISE
•Operations:
• CREATE: Creates new database objects (e.g., tables,
indexes).
• ALTER: Modifies existing database structures.
• DROP: Deletes database objects.
• TRUNCATE: Removes all rows from a table without
affecting the structure.
 2. Data Manipulation Language (DML)
• Purpose: Manipulates data within existing database objects.
Provides set of operations like retrieval, insertion, deletion, and
modification of the data.
• Operations:
• INSERT: Adds new records.
• UPDATE: Modifies existing records.
• DELETE: Removes records.
• SELECT: Queries data from the database.
Dept of ISE
3. Data Control Language (DCL)
• Purpose: Manages access and permissions to the
database.
• Operations:
• GRANT: Provides access to users.
• REVOKE: Removes access permissions.
 Interfaces
1. Menu-Based Interfaces- for Web Clients or Browsing. These
interfaces present the user with lists of options (called menus) that
lead the user through the formulation of a request.
Example: Online shopping
2. Forms-Based Interfaces- displays a form to each user. Users can
fill out all of the form entries to insert new data, or they can fill out
only certain entries, in which case the DBMS will retrieve matching
data for the remaining entries.
Dept of ISE
Example: A job application form where you fill out your name,
and the system fetches existing details if they match.
3. Graphical User Interfaces- displays a schema to the user in
diagrammatic form. The user then can specify a query by
manipulating the diagram. GUIs utilize both menus and forms.
Most GUIs use a pointing device.
Example: Database design tools like MS Access or
drag-and-drop query builders.
 4. Natural Language Interfaces- accepts requests written in English or
some other language and attempt to understand them.
Example: Asking, “Show me all employees earning more than
$5000.”
5. Speech Input and Output- use of speech as an input query and
speech as an answer to a question or result. The speech input is
detected using a library of predefined words and used to set up the
parameters that are supplied to the queries.
Example: Voice assistants like Siri or Alexa querying a database.
6. Interfaces for Parametric Users- such as bank tellers, often have a
Dept of ISE
small set of operations that they must perform repeatedly.
Example: Bank tellers processing withdrawals and deposits.
7. Interfaces for the DBA- DBA use privileged commands. These
include commands for creating accounts, setting system parameters,
granting account authorization, changing a schema, and reorganizing
the storage structures of a database.
Example: Tools to grant user access/optimize database
performance.
 2.4- The Database System
Environment
Dept of ISE
 (i)DBMS component modules
(ii)Database system utilities
Dept of ISE
(iii)Tools, Application Environments,
and Communications Facilities
Dept of ISE

Fig: DBMS Component modules and their interactions

 DBMS component modules

• Many DBMSs have their own buffer management module to schedule disk read/write.
Stored data manager controls access to DBMS information that is stored on disk, whether
it is part of the database or the catalog.

Top half figure:

• It shows interfaces for the DBA staff, casual users who work with interactive interfaces to
formulate queries application programmers who create programs using some host
programming languages.
• Parametric users who do data entry work by supplying parameters to predefined
transactions.
Dept of ISE • The DBA staff works on defining the database and tuning it by making changes to its
definition using the DDL and other privileged commands DBA staff:
• The DDL compiler processes schema definitions, specified in the DDL, and stores
descriptions of the schemas (meta-data) in the DBMS catalog.
• The catalog includes information such as the names and sizes of files, names and data types
of data items, storage details of each file, mapping information among schemas, and
constraints
 1. Casual users: interact with a database using a user-friendly interface, called an interactive
query interface.
• The query compiler checks if the query is written correctly and whether the files and data
exist.
• The query is then optimized to improve efficiency by removing unnecessary steps and
choosing the best execution methods.
• The query optimizer looks at the database's structure and statistics to decide the best way
to run the query.
• Finally, an executable code is created, which fetches the requested data and processes it.
• This ensures that database queries are executed efficiently and correctly.
2. Application programmers write programs in languages like Java, C, or C++ that interact
with a database.
Dept of ISE
• A precompiler scans the program and extracts database commands (DML commands).
• These commands are sent to the DML compiler, which processes them.
• The rest of the program is sent to the host language compiler for normal compilation.
• The compiled database commands and the rest of the program are combined to create a
canned transaction (a reusable program).
• Example: In a bank withdrawal transaction, the program takes the account number and
amount as inputs and processes the transaction.
 DBMS component modules

1. In the lower part of Figure,

the runtime database processor executes
2. (1) the privileged commands
(2) the executable query plans, and
(3) the canned transactions with runtime parameters.
• It works with the system catalog and may update it with statistics.
• It also works with the stored data manager, which in turn uses basic operating
system services for carrying out
Dept of ISE
• low-level input/output (read/write) operations between the disk and main
memory
• The runtime database processor handles other aspects of data transfer, such as
management of buffers concurrency control and backup and recovery systems,
integrated into the working of the runtime database processor for purposes of
transaction management
 Database system utilities

• Loading

• Backup
Dept of ISE
• Database Storage Reorganization.

• Performance Monitoring.
 Database System Utilities

• DBMSs have database utilities that help the DBA manage the database system. Common
utilities have the following types of functions:
• Loading
• Used to load existing data files—such as text files or sequential files—into the
database
• Automatically reformats the data and stores it in the database
• For loading programs, conversion tools are available like IDMS (Computer
Associates), SUPRA (Cincom), and IMAGE (HP)
Dept of ISE
• Backup
• Creates a backup copy of the database, by dumping the entire database onto tape
• Used to restore the database in case of catastrophic disk failure
• Incremental backups are also often used, to save space
 Database System Utilities

• Database storage reorganization

• Used to reorganize a set of database files into different file organizations to
improve performance
• Performance monitoring
• Monitors database usage and provides statistics to the DBA.
• Statistics used for making decisions
• Other utilities may be available for sorting files, handling data compression,
Dept of ISE monitoring access by users, interfacing with the network, and performing
other functions.
 Centralized and Client/Server Architecture
for DBMS
1. Physical Centralized DBMS Architectures

Dept of ISE
 2. Basic Client / Server Architecture
• Specialized Servers with Specialized
functions
• Print server
• File server
• DBMS server
• Web server
Dept of ISE • Email server
• Clients can access the specialized
servers as needed
 Two Tier Client-Server Architecture for DBMS

• An Open Database
Connectivity(ODBC) provides
and API which allows
client-side to call DBMS

Dept of ISE
Advantage:
• Simplicity and Seamless
Compatibility.
 Three Tier and n-Tier Client-Server
Architecture
Server plays an intermediate role by running application
programs and storing business rules that are used to access
data from the database server

Dept of ISE
 Classification of Database
Management System.
• Based on Data Model – DBMS Classification
• Relational Data Model.
• Object Data Model.
• Big Data system – Key _value storage system
& NoSQL systems. Document-based.
Dept of ISE Graph-based.
Column-based.
Key-value data models.
• Object relational model & hierarchical network.
• Tree – Structured data model – XML based
 Classification of Database Management System
• Based on number of users
• Single user system.
• Multi user system.

• Based on number of sites.

• Centralized DBMS
• Distributed DBMS(DDBMS).
• Homogeneous DDBMS.
Dept of ISE • Heterogeneous DDBMS.

• Based on usage:
• General Purpose.
• Special Purpose.

• Based on Data Model.

• Relation data model
• Object Data Model
Dept of ISE
 Chapter - 3
Data Modelling Using The Entity – Relationship (ER)
Model
Dept of ISE
 High level Conceptual Data Models for
Database Design

Dept of ISE
Dept of ISE
 Entities and Attributes

● An entity, which is a thing or object in the real world with an independent

existence.
● An entity may be an object with a physical existence (for example, a
particular person, car, house, or employee) or it may be an object with a
conceptual existence (for instance, a company, a job, or a university
Dept of ISE course)
 Entities and Attributes

● Each entity has attributes—the particular properties that describe it. For
example, an EMPLOYEE entity may be described by the employee’s
name, age, address, salary, and job

Dept of ISE
 Types of attributes in the ER model

● Simple and composite

Dept of ISE
 Types of attributes in the ER model

● Single-Valued versus Multivalued Attributes

Dept of ISE
 Types of attributes in the ER model

● Stored versus Derived Attributes

Dept of ISE
 Types of attributes in the ER model

NULL Values - particular entity may not have an

applicable value for an attribute
The unknown category of NULL can be further classified into two cases.

● The first case arises when it is known that the attribute value exists
but is missing—for instance, if the Height attribute of a person is
listed as NULL.

Dept of ISE ● The second case arises when it is not known whether the attribute
value exists—for example, if the Home_phone attribute of a person is
NULL.
 Types of attributes in the ER model

Complex Attributes: composite and multivalued attributes can be

nested arbitrarily

Nesting by grouping components of

● a composite attribute between parentheses ( ) and separating the
components with commas
● displaying multivalued attributes between braces { }
Dept of ISE
 Entity Types, Entity Sets, Keys, and Value Sets

● An entity type defines a collection (or set) of entities that have the same
attributes. Each entity type in the database is described by its name and
attributes.
● The collection of all entities of a particular entity type in the database at
any point in time is called an entity set or entity collection.
●

Dept of ISE
 Key Attributes of an Entity Type.

● An entity type usually has one or more attributes whose values are distinct
for each individual entity in the entity set. Such an attribute is called a key
attribute, and its values can be used to identify each entity uniquely.
● Each key attribute has its name underlined inside the oval.
● Some entity types have more than one key attribute

Dept of ISE
 Value Sets (Domains) of Attributes

Each simple attribute of an entity type is associated with a value set (or domain of values),
which specifies the set of values that may be assigned to that attribute for each individual
entity

Dept of ISE
 Initial Conceptual Design of the COMPANY Database
According to the requirements listed , we can identify
four entity types

Dept of ISE
Dept of ISE
 Relationship Types, Relationship Sets,
Roles, and Structural Constraints
● There are several implicit relationships among the various
entity types

Dept of ISE

Fig: Some instances in the WORKS_FOR relationship set,

which represents a relationship type WORKS_FOR
between EMPLOYEE and DEPARTMENT.
 Relationship Types, Relationship Sets,
Roles, and Structural Constraints
● A relationship type R among n entity types E1, E2, . . . , En defines a set of
associations—or a relationship set—among entities from these entity
types.
● A relationship set is a mathematical relation on E1, E2, . . . , En;
alternatively, it can be defined as a subset of the Cartesian product of the
entity sets E1 × E2 × . . . × En

Dept of ISE
 Relationship Degree
1. Degree of a Relationship Type: The degree of a relationship type is the number
of participating entity types. Hence, the WORKS_FOR relationship is of degree
two.
A relationship type of degree two is called binary, and one of degree three is
called ternary
An example of a ternary relationship is SUPPLY, shown in Figure, where each
relationship instance ri
2. Associates three entities—a supplier s, a part p, and a project j—whenever s
supplies part p to project j.

Dept of ISE

Fig: Some relationship instances in the SUPPLY ternary relationship set.

 Constraints on Binary Relationship Types

• Relationship types usually have certain constraints that limit the possible
combinations of entities that may participate in the corresponding
relationship set.
• These constraints are determined from the miniworld situation that the
relationships represent.

Dept of ISE Two main types of binary relationship constraints:

• Cardinality ratio
= Structural constraints
• Participation constraint
 Relational (Structural Constraints)
Cardinality Ratio : Maximum no of relationship instances of
each entity type can participate

One to many (1:N) Cardinality Ratio or Many to one (N:1)

Dept of ISE
 Relational (Structural Constrains)
Cardinality Ratio - Binary
Relationship

• One to One (1:1) Cardinality Ratio

Dept of ISE
 Relational (Structural Constrains)
Cardinality Ratio :

Many to many (M:N) Cardinality Ratio

Dept of ISE
Dept of ISE
Dept of ISE
 A recursive relationship is a relationship where an entity is related to
itself. This means that instances of the same entity set participate in a
relationship with each other

Dept of ISE
 Attributes of Relationship Types

• Relationship types can also have attributes, similar to those of entity

types.
• For example, to record the number of hours per week that a particular
employee works on a particular project, we can include an attribute
Hours for the WORKS_ON relationship type
• To include the date on which a manager started managing a department
Dept of ISE via an attribute Start_date for the MANAGES relationship type.
Dept of ISE
 3.3 Weak Entity Types

Dept of ISE
 1. Strong Entity Type
• A strong entity has a primary key that uniquely identifies each
record.
• Example: An Employee entity with Employee_ID as a key.

2. Weak Entity Type

• A weak entity does not have a key of its own.
• It depends on a strong entity for identification.
• Example: A Dependent entity (e.g., a child or spouse of an
employee) doesn’t have a unique identifier of its own.
Dept of ISE

3. Identifying Relationship
• A weak entity is linked to a strong entity through an identifying
relationship.
• The strong entity is called the owner entity.
Dept of ISE
 4. Total Participation
• A weak entity must be related to a strong entity.
• Example: A Dependent cannot exist without being related to
an Employee.

5. Partial Key
• A partial key is an attribute that helps distinguish weak entities
within the same owner.
• Example: If no two dependents of the same employee have the
Dept of ISE
same Name, then Name is a partial key for the Dependent
entity.
 ER Diagrams, Naming Conventions, and Design Issues
1. Meaningful Names
• Choose names that clearly represent the purpose of entities,
attributes, and relationships.
• Example: Use Employee instead of Person if the entity
represents employees.
2. Singular Names for Entity Types
• Use singular names for entity types, rather than plural.
• Example: Use Student (✅) instead of Students (❌).
3. Naming Conventions
Dept of ISE
• Entity Types & Relationship Types → UPPERCASE
• Example: EMPLOYEE, DEPARTMENT, WORKS_FOR
• Attributes → Capitalized Initial Letter
• Example: Employee_ID, Name, Salary
• Role Names → Lowercase
• Example: manager, subordinate (in a supervision
relationship)
 4. Nouns for Entities, Verbs for Relationships
• Nouns (People, objects, concepts) → Entity Type Names
• Example: STUDENT, COURSE, TEACHER
• Verbs (Actions, interactions) → Relationship Names
• Example: ENROLLED_IN, TEACHES, MANAGES

5. Readable Relationship Naming

• Arrange binary relationships so they make the ER diagram easy
to read from left to right or top to bottom.
Dept of ISE
 Design Choices for ER Conceptual Design

Schema design process should be considered an iterative

refinement process, where an initial design is created and then
iteratively refined until the most suitable design is reached. Some of
the refinements that are often used include the following:

• Convert attributes to relationships if they refer to another entity.

Dept of ISE • Promote attributes to entity types if they exist in multiple entities.
• Demote entity types to attributes if they have a single attribute
and one relationship.
 Refinement 1: Attribute → Relationship
• If an attribute refers to another entity, it should be changed into a
relationship.
• Example:
• Initially, we model Advisor as an attribute of STUDENT.
• Later, we realize that Advisor is an INSTRUCTOR (an entity).
• Solution: Convert Advisor from an attribute to a relationship
between STUDENT and INSTRUCTOR.
Dept of ISE Before:
STUDENT (Student_ID, Name, Major, Advisor)
After (Refined Schema):
STUDENT (Student_ID, Name, Major)
INSTRUCTOR (Instructor_ID, Name, Department)

STUDENT ----(HAS_ADVISOR)----> INSTRUCTOR

 Refinement 2: Attribute → Entity Type
• If the same attribute is present in multiple entity types, promote it to an entity.
• Example:
• The attribute Department appears in STUDENT, INSTRUCTOR, and COURSE.
• Instead of repeating Department, we create a DEPARTMENT entity and
establish relationships.
Before:
STUDENT (Student_ID, Name, Department)
INSTRUCTOR (Instructor_ID, Name, Department)
COURSE (Course_ID, Title, Department)
Dept of ISE
After (Refined Schema):
• STUDENT (Student_ID, Name)
• INSTRUCTOR (Instructor_ID, Name)
• COURSE (Course_ID, Title)
• DEPARTMENT (Dept_Name)

STUDENT ----(BELONGS_TO)----> DEPARTMENT

INSTRUCTOR ----(WORKS_IN)----> DEPARTMENT
 Refinement 3: Entity Type → Attribute

• If an entity type has only one attribute and is only related to one other
entity, it might be better as an attribute instead of a separate entity.
• Example:
• If DEPARTMENT has only the attribute Dept_Name and relates only
to STUDENT, we can demote it to an attribute of STUDENT.
Before:
Dept of ISE STUDENT ----(BELONGS_TO)----> DEPARTMENT (Dept_Name)

After (Simplified Schema):

STUDENT (Student_ID, Name, Dept_Name)
 Summary of the notation for ER diagrams

Dept of ISE
Dept of ISE
Dept of ISE
Dept of ISE
Dept of ISE
Dept of ISE
Dept of ISE
Dept of ISE
Dept of ISE
Dept of ISE
Dept of ISE
Dept of ISE
Dept of ISE