Unit # 1

Data Model , Language ,

Interface , Hierarchical
Network , Strong & Weak
entity sets ,Entity
Relationship model
(Week-2)

Note: Last date to submit assignment (1) , (2) & (3)

- 10th Oct (last Class of the Sem)
 Data
Data models are fundamental frameworks for defining how data is
Models
Structured, Stored, and Manipulated in a database system. They are
crucial to understanding how to organize data in a meaningful and
efficient
Data way determines
Models for various applications.
how data will be organized into tables or other
data structures, how the relationships between data elements will be
established, and how the data will be stored for efficient access and
manipulation. This blueprint is also known as schema of the database.
The schema is essentially a map of the database's structure and its
components.of Data Models
Categories
Data models can be categorized based on how they represent and
structure data. Below are the main categories of data models:
1. Conceptual Data Models
2. Logical Data Models
a) Relational Model (d) Hierarchical Models
b) Object-Oriented Model (e) Network Model
c) Object-Relational Model
3. Physical Data Models
4. NoSQL Data Models
1. Conceptual Data Models
This model are used to represent the high-level, abstract structure of data,
focusing on the overall organization of data within a system, without
worrying about how the data will be stored or manipulated.
 Data Models (contd)
This model is used during the initial stages of database design to capture
business requirements and data entities. Entity-Relationship (ER) Model
that represents data as entities (things of interest) and relationships
between them and Enhanced Entity-Relationship (EER) Model that
adds more detailed constructs like subclasses, superclasses, and
inheritance represent Conceptual Model case.
In the University example so we have, entities like Student, Course,
Professor are defined, along with relationships such as Enrollment between
Student and Course
1. Logical Data Models
Logical data models refine the conceptual model by specifying how data will
be structured within a database management system (DBMS). These models
focus on defining the structure of the database (e.g., tables, columns,
relationships) without considering the specifics of how the data will be
physically stored. It include more details such as the data types, constraints,
and relationships but do not deal with implementation.
(a) Relational Model is a logical data model where data is represented in
tables (relations) with rows and columns. Each row represents a record, and
each column represents an attribute. Relationships are established using
keys.
(b) Object-Oriented Model: Object-oriented models represent data as
objects, similar to object-oriented programming. Each object contains
attributes (data) and methods (operations) that can act on the data. This
 Data Models (contd)
In University example , in object-oriented model, a Student object could
have attributes like StudentID, Name, and CoursesEnrolled, and methods
like CalculateGPA()

(b) Object-Relational Model: The object-relational model combines

features from both the relational model and the object-oriented model. It
supports traditional relational databases' tabular structure but also
incorporates object-oriented features such as complex data types,
inheritance, and methods. In the University example we have , In an object-
relational model, a table of Students might include a column that stores a
list of Courses objects, where each Course object contains attributes like
CourseID and Grade.

(d) Hierarchical Model: These models represent data in a tree-like

structure, with records having a parent-child relationship. Each child record
can have only one parent, but a parent can have multiple child records. This
model is ideal for representing hierarchical data, such as organizational
charts or file systems. In our University example we might have a university
organizational chart where each department reports to a dean, and each
professor belongs to one department.

(d) Network Model: The network model extends the hierarchical model by
 Data Models (contd)
represent entities, and edges represent relationships between them.
Example scenario could be situations where data needs to represent
multiple interconnections, like common Professors distributed across
various courses.

3. Physical Data Models

Physical data models describe how the data will be physically stored in a
database system. They focus on database storage structures and access
methods, taking into account factors like performance, indexing, and file
storage. Physical models include specific implementation details such as
the storage format of data, partitioning strategies, indexing techniques,
and optimization considerations. A physical model might define how the
Students table is stored on disk, the indexing strategies used, or how data
is partitioned across different physical storage devices.
Examples , Indexed File Organization , Hashed File Organization ,
Partitioned Table Storage etc

4. NoSQL Data Models

NoSQL models are designed for distributed, high-performance systems,
especially for handling unstructured or semi-structured data. They do not
rely on the tabular structure of the relational model.
A NoSQL model in a our university system might store student data as
 Schemas and
Instances
In a Database Management System (DBMS), schemas and instances
represent two key concepts related to the structure and state of a
database. These terms help differentiate between the design of the
database and its current state at any given moment.
Schema :
The description of a database is called the database schema, which is
specified during database design and is not expected to change frequently.
A schema diagram displays only some aspects of a schema, such as the
names of record types and data items, and some types of constraints. We
call each object in the schema—such as STUDENT or COURSE - a schema
construct. Other aspects are not specified in the schema diagram; for
example neither the data type of each data item, nor the relationships
or constraints among the various constructs.

Instances :
The actual data in a database may change quite frequently. For example,
the database might changes every time we add a new student or enter a
new grade. The data in the database at a particular moment in time is
called a database state or snapshot. It is also called the current set of
occurrences or Instances in the database.
 Schemas and Instances
(contd)

• 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. Many database states
can be constructed to correspond to a particular database schema. Every
time we insert or delete a record or change the value of a data item in a
record, we change one state of the database into another state.
• When we define a new database, we specify its database schema only to
the DBMS.At this point, the corresponding database state is the empty
state with no data.
 Schemas and Instances
• We get the(contd)
initial state of the database when the database is first
populated or loaded. From then on, every time an update operation is
applied to the database, we get another database state. At any point in
time, the database has a current state.
• The DBMS is partly responsible for ensuring that every state of the
database is a valid state i.e 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
and the schema must be designed with utmost care. The DBMS stores the
descriptions of the schema constructs and constraints—also called the
meta-data—in the DBMS catalog so that DBMS software can refer to
Thethe schema whenever
Three-Schema it needs to.
Architecture
The main goal of the three-schema architecture, is to separate the user
applications from the physical database. This model is designed to improve
data independence, and provide flexibility for the design and
implementation of database systems. The three levels of this architecture
are:
1. External Schema (View Level)
2. Conceptual Schema (Logical Level)
3. Internal Schema (Physical Level)
 Schemas and Instances
(contd)
1. External Schema (View Level)
The External Schema is the topmost level in the three-schema architecture
and represents how users or applications interact with the database. It is
sometimes referred to as the user view or application view of the data.
Multiple external schemas can be defined, each providing a different
perspective or customized view of the database for different users.
• Each user or group of users can have their own view of the database. For
example, a student may only see their grades, while a professor can view
grades for all students in a course.
• Users do not need access to the entire database. They may only need to
work with a subset of the data. The external schema allows this subset to
be tailored to user needs.
• The external schema is often implemented using database views, which
are virtual tables that don't store data themselves but retrieve data from
the underlying tables.
• By restricting what data different users can see, the external schema
helps protect sensitive information and enforce security policies.
2. Conceptual Schema (Logical Level)
This schema describes what data is stored in the database and how it is
organized, but without dealing with how the data is physically stored.
• The conceptual schema defines the entire structure of the database,
including entities, attributes, relationships, constraints, and data integrity
 Schemas and Instances
• (contd)
The conceptual schema is independent of both the external schema
(what users see) and the internal schema (how data is stored). This
separation allows changes to the physical storage of data without
affecting the logical view and vice versa.
• It includes the definition of tables (relations), data types, primary keys,
foreign keys, and other logical constructs that define how data elements
relate to one another.
• The conceptual schema is often modeled using high-level data models
like the Entity-Relationship (ER) model or Relational Model, which
describe the logical organization of the data.
• In the university database:
o The conceptual schema defines the tables such as Students, Courses,
Enrollments, and Grades, along with their attributes like StudentID,
Name, CourseID, Grade, etc.
o It also defines the relationships between these entities (e.g., each
student can enroll in multiple courses, and each course can have
multiple students).
o Constraints like PRIMARY KEY (e.g., StudentID uniquely identifies
3. Internal
eachSchema
student)(Physical
and FOREIGNLevel)
KEY (e.g., StudentID in Enrollments
references
The Internal SchemaStudentID in Students)
is the lowest level ofare
thepart of the conceptual
three-schema schema.
architecture
and represents how data is physically stored in the database.
 Schemas and Instances
• (contd)
The internal schema includes details such as how data is organized on
disk, what indexes are used, how data is partitioned or replicated, and
how data blocks are structured.
• The physical level is concerned with optimizing the database for
efficient access and storage. Techniques like indexing, data
compression, and partitioning are implemented at this level.
• The internal schema manages the allocation of data blocks, buffers, and
caching strategies to optimize performance.
• In the university database:
o The Students table might be stored as a set of files on disk using a
particular file format while courses as B-Tree format.
o An index might be created on the StudentID column to speed up
search operations, and the data might be partitioned across
different physical storage devices
 Schemas and Instances
(contd)

External Schemas customizations

3rd level of the conceptual
of abstraction ExternalExternal External schema to the
... needs of various
Schema 1 Schema 2 Schema n classes of users

2nd level Conceptual what data are stored,

of abstraction Schema what relationships,
constraints exist

1st level Physical

how the data are physically stored
of abstraction Schema

actual data
Figure 12
1.7
 Database Languages and
Interfaces
recap All Actors shall Interact with the
DBMS

Subject Matter The Controller :

Expert :
Administrator
System
Analyst
DBMS

The Designer , Creator : Writers / Implementors :

System Architect Application
programmers
End User
 Database Languages (contd)
Database languages are specialized languages used to interact with a
DBMS to perform various operations on data. They play a crucial role in
defining, manipulating, and controlling the data stored within the system.
For sake of ease they are listed below :
1. Storage Definition Language ( SDL)
2. Data Definition Language (DDL)
3. Data Manipulation Language (DML)
4. Data Control Language (DCL)
5. View definition language (VDL),
6. Transaction Control Language (TCL)
1. Storage Definition Language ( SDL)
Storage Definition Language (SDL) is a specialized language used in
database management systems (DBMS) to define the internal schema,
which refers to the physical storage structure of the database on storage
devices . It is primarily concerned with how data is organized at the
physical level and deals with performance optimization, data storage, and
retrieval methods.
In our University example :
o The Students database might store records in a hashed file where the
StudentID is hashed to determine the location of each student record on
disk.
o Fixed-length records might be used for storing student data where each
 Database Languages (contd)
o If a database frequently accesses the same set of student records, those
records may be stored in memory buffers to avoid repeatedly reading
from disk.
o In a large database, student data could be split across different
partitions based on their department to balance the storage load and
improve query performance.

CREATE TABLE student (article_title varchar(65000) ENGINE = MEMORY;

CREATE TABLE student (article_title varchar(65000) ENGINE = MEMORY;
CREATE TABLE f (x int, y varchar(25));

There is no specific language that performs the role of SDL. Instead,

combination of functions, parameters, and specifications related to
storage of files define internal schema.
2. Data Definition Language ( DDL)
Data Definition Language (DDL) is a subset of SQL (Structured Query
Language) used to define, modify, and manage the structure or schema of a
database. DDL is primarily used during the initial stages of database setup
and during subsequent schema modifications. The most commonly used
DDL commands include:
o CREATE: Used to create new database objects like tables, views,
indexes, and schemas.
o ALTER: Used to modify the structure of an existing database object.
 Database Languages (contd)
o DROP: Used to delete existing database objects.
o TRUNCATE: Used to quickly delete all records from a table,
resetting its storage space.
o RENAME: Used to rename database objects like tables or indexes.

CREATE TABLE Students

(
StudentID INTEGER PRIMARY KEY, -- Unique identifier for each
student
Name TEXT NOT NULL, -- Student's name (Text,
cannot be null)
Age INTEGER, -- Student's age (Integer)
Major TEXT -- Student's major (Text)
);
INSERT INTO Students (Name, Age, Major)
VALUES (‘Meera', 21, 'Computer Science');
…………..
INSERT INTO Students (Name, Age, Major)
VALUES (‘Geeta', 21, 'Computer Science');

Name VARCHAR(50) NOT NULL;

Email VARCHAR(100) UNIQUE;
 Database Languages (contd)
• DDL allows database designers to define the logical structure of the
database, including tables, indexes, and relationships between different
entities.
• By using constraints like PRIMARY KEY, FOREIGN KEY, and CHECK, DDL
ensures data integrity by enforcing rules at the database level.
• DDL allows developers and administrators to modify the database
structure without losing data. For example, columns can be added or
modified using the ALTER command.
3. Data Manipulation Language ( DML)
Data Manipulation Language (DML) is a subset of SQL (Structured Query
Language) used to manipulate and interact with the data stored in a
relational database. As we saw Data Definition Language (DDL) deals with
creating and modifying the structure of the database (e.g., tables, indexes),
DML focuses on manipulating the actual data within those tables. The
operations performed by DML typically include retrieving, inserting,
updating, and deleting data.DML operations are vital for managing the day-
to-day interactions with a database.
DML commands are typically used by applications, users, or scripts to
perform data-driven tasks. There are four primary types of DML commands:

(1) SELECT (2) INSERT

(3) UPDATE (4) DELETE
 Database Languages (contd)
1.SELECT Command :
The SELECT statement is used to retrieve data from one or more tables
in a relational database. It is the most commonly used DML command
and provides the means to query data based on specific conditions.
University example:
SELECT Name, Age FROM Students WHERE Age > 20;

2. INSERT Command
The INSERT statement is used to add new records (rows) to a table. This
is a crucial operation in any database system that grows and evolves by
adding new data.
University example:
INSERT INTO Students (Name, Age, Major) VALUES (‘Sunil', 22,
'Computer Science');

3. UPDATE Command
The UPDATE statement is used to modify existing data in a table. This
allows for making changes to records that already exist without deleting
and re-inserting them.
University example:
UPDATE Students SET Major = 'Physics‘ WHERE StudentID = 101;
UPDATE Students SET GPA = 3.9 WHERE Major = 'Computer Science';
 Database Languages (contd)
4. DELETE Command
The DELETE statement is used to remove existing records from a table.
It is used when data is no longer needed or has become irrelevant.
University example:
DELETE FROM Students WHERE StudentID = 101;

DML Command Properties

• DML commands do not immediately make permanent changes to the
database. Instead, they are part of a transaction. Changes are only
committed (made permanent) if a COMMIT operation is executed.
 Database Languages (contd)
Differences Between DML and DML
Data Definition Language: DDL
• Focuses on defining or altering the structure of database objects like
tables, indexes, and schemas.
• Commands include CREATE, ALTER, DROP, and TRUNCATE.
• Deals with schema or object structure in the database.
• Changes are generally immediate and permanent (cannot be rolled
back).

Data Manipulation Language: DML

• Focuses on data manipulation within the existing structure (insert,
update, delete, select).
• Commands include SELECT, INSERT, UPDATE, and DELETE.
• Deals with data inside the database.
• Changes can be rolled back (within a transaction).

4. Data Control Language ( DCL)

Data Control Language (DCL) is a subset of SQL (Structured Query
Language) that is used to control access and permissions to the data stored
in a database. DCL commands are primarily used by database
administrators to grant or revoke privileges to users or roles, ensuring the
security and integrity of the database.
 Database Languages (contd)
The two main DCL commands are:
1. GRANT
2. REVOKE

1. GRANT
The GRANT command is used to provide privileges (permissions) to users or
roles so that they can perform specific operations on the database. These
privileges may include actions such as querying data (SELECT), modifying
data (INSERT, UPDATE, DELETE), or managing the structure of the database
(CREATE, ALTER, DROP).

GRANT SELECT ON Students TO Seema;

GRANT SELECT, INSERT ON Courses TO Shailja ;
GRANT ALL PRIVILEGES ON DATABASE UniversityDB TO admin_role;

2. REVOKE Command
The REVOKE command is used to remove previously granted privileges from
users or roles. This command ensures that users no longer have access to
CREATE ROLE ,
perform specific actions on the database or its objects.
SET ROLE, GRANT ROLE,
REVOKE SELECT ON Students FROM Seema ; REVOKE ROLE … etc
 Database Languages (contd)
• DCL ensures that only authorized users can access or manipulate specific
data or database objects (e.g., tables, views, functions). The most
commonly controlled objects include: Tables , Views , Indexes , Functions
and Procedures , Schemas etc
• In short , security is one of the main reasons for using DCL commands. It
also help fixing the accountability by carefully controlling who can access
or modify data, organizations can hold users accountable for their actions
5.inTransaction
the database.Control Language ( TCL)
Transaction Control Language (TCL) commands ensure that transactions are
executed in a way that maintains the integrity, consistency, and durability
of the data in the database. It ensure that transactions adhere to the ACID
properties. TCL provide mechanisms for commitment and rollback of
transactions, ensuring that the database remains in a consistent state, even
in the event of an error or system failure. There are four primary TCL
commands:

(1) COMMIT (2) ROLLBACK

(3) SAVEBACK (4) SET TRANSACTION
1. COMMIT Command
The COMMIT command is used to permanently save all changes made in the
current transaction to the database. Once a transaction is committed, the
changes are made permanent and become visible to other users and
 Database Languages (contd)
INSERT INTO Students (Name, Age, Major)
VALUES (‘Meera', 22, 'Physics'); - Update an existing record
UPDATE Students
SET Major = 'Mathematics' WHERE Name = ‘Meera';

COMMIT; -- Commit the changes done.

2. ROLLBACK Command
The ROLLBACK command is used to undo all changes made by the current
transaction. If a problem or error occurs during the transaction, the
ROLLBACK command restores the database to its state before the
transaction began, discarding all the changes made within the transaction.

BEGIN TRANSACTION;
INSERT INTO Students (Name, Age, Major)
VALUES (‘Meera', 23, 'Engineering');
UPDATE Students
SET Major = 'Biology'
WHERE Name = ‘Meera';
Something went wrong or a condition failed, so rollback the transaction !!!!
ROLLBACK; -- Undo all changes made during the transaction
 Database Languages (contd)
3. SAVEPOINT Command
The SAVEPOINT command is used to set a checkpoint within a transaction.
You can later roll back the transaction to this specific savepoint , instead of
rolling back the entire transaction. It provides more control over transaction
management by allowing partial rollbacks.

BEGIN TRANSACTION; -- Start a new transaction

INSERT INTO Students (Name, Age, Major)
VALUES (‘ Savita', 24, 'Chemistry');

SAVEPOINT before_update; - Create a savepoint

before updating

-- Update an existing record

UPDATE Students
SET Major = 'Philosophy'
WHERE Name = ‘Savita';

-- Something went wrong; rollback till the savepoint

ROLLBACK TO before_update; - Undo the update but
keep the insert
 Database Interface
A database interface is the mechanism through which users and applications
interact with the DBMS. Interfaces can range from graphical user interfaces
(GUIs) for end-users to more complex command-line interfaces (CLIs) for
administrators and developers. These interfaces provide the necessary tools
for users to query, modify, and manage databases effectively. The DBMS
interface allows users to:

1. Submit queries to retrieve data.

2. Insert, update, or delete data from tables.
3. Define database structures (e.g., tables, schemas, views).
4. Manage database security and permissions.
5. Monitor and optimize database performance.

The Interfaces are different for different roles.. For Eg. System Analyst ,
Database Administrators may use graphical tools (GUIs) , Technical users like
Application Programmers may use command-line tools and APIs.

1. Graphical User Interface (GUI)

A Graphical User Interface (GUI) enables users to interact with the DBMS
using point-and-click methods rather than writing SQL queries. GUIs are
more user-friendly and are typically used by non-technical users or database
administrators who need an easier way to manage databases without deep
 Database Interface
• In MySQL Workbench, a user can create a new table by navigating to the
(contd)
database schema, clicking "Create Table," and entering table columns
and types using a form-based interface.

2. Command-Line Interface (CLI)

A Command-Line Interface (CLI) is a text-based interface that allows users
to interact with the DBMS by typing SQL commands. This interface is
typically used by advanced users, such as database administrators (DBAs)
and developers, who need full control over database operations.
• It offers direct access to execute SQL commands. This interface is fast
and lightweight but requires familiarity with SQL and database internals.
• Developers and DBAs use CLI to write queries, manage users, optimize
databases, and perform backup and restore operations.

3. Application Programming Interface (API)

Application Programming Interface (API) allows external applications to
programmatically interact with the DBMS. APIs enable developers to
integrate database functionalities into their applications, such as querying
a database, updating records, or managing transactions from within their
software.
• This requires libraries and drivers to execute SQL queries and
manipulate data within the application. Examples is ODBC (Open
Database Connectivity) & JDBC.
 Database Interface
(contd)
4. Form based Interface (API)
Form-Based Interface is a more specialized DBMS interface that allows
users to interact with a database by entering data through forms. These
interfaces are commonly used in data-entry applications where non-
technical users input, update, or retrieve data without interacting directly
with the database tables or SQL queries. Examples is Microsoft Access
forms.
• Provides a form layout for users to input data, with fields mapped to the
underlying database columns.
• Useful in environments where non-technical users perform repetitive
data entry.
5. Natural Language Interface
A Natural Language Interface allows users to interact with the DBMS by
typing queries in natural language (e.g., English) rather than using SQL.
This type of interface uses natural language processing (NLP) techniques to
interpret user queries and convert them into SQL commands. Example like
say
A user might type: "Show me all students who are older than 18," and the
system translates it into SQL: SELECT * FROM students WHERE age > 18.
• Typically used in self-service Business Intelligence environments where
non-technical users need quick access to data insights.
6. Web-Based Interfaces
A Web-Based Interface provides the ability to interact with the DBMS
 Data Modeling using Entity Relationship
Model
( Model)
The Entity-Relationship Model (ER ER Model ) conceptual data
is a high-level
model used for designing databases. It provides a way to visualize and
structure data and its relationships within a system, making it useful for the
early stages of database design. ER model has three main concepts:
1. Entities (and their entity types and entity sets)
2. Attributes (simple, composite, multivalued)
3. Relationships (and its degree , Cardinality and participation
constraints)
1. Entity
A thing or object in the real world Number: 1123
with an independent existence.
Entities can be physical objects (e.g., Name: Computer
a person, car) or concepts (e.g., a job, Programming 2
department).
Topic: Computer
Name Programming
Number Topic Entity Types
Defines a group of objects (called
Course entities) that share the same
 ER Model – Attributes
2. Attributes
In the Entity-Relationship (ER) model, attributes are properties or
characteristics of an entity or relationship that store relevant data.
Attributes can be classified into several types based on their structure and
how they relate to other attributes. Below are the main types of
attributes:

• Simple or Composite
• Single or Multi-valued
• Stored or Derived
• NULL
(a) Simple
A simple attribute cannot be divided
further into smaller parts.
(b) Composite
A composite attribute can be
divided into smaller sub-parts,
each representing more basic
attributes. It can be divided into
smaller subparts, which represent
more basic attributes with
 ER Model – Attributes
(contd)
(c) Single-Valued Attribute
A single-valued attribute
holds only one value for
each entity instance.

(d) Multi -Valued Attribute

A multi-valued attribute
can hold multiple values
for a single entity instance.

(e) Derived Attribute

A derived attribute is not
stored in the database but
is derived from other
stored attributes.
 ER Model – Attributes
(contd)
(f) Stored Attribute
Stored attributes are those
whose values are
Professor DoB
physically stored in the
database..

(g) Key Attribute

A key attribute uniquely
identifies an entity in the
entity set. It ensures that
each entity is
distinguishable from
(h) Primary Key
others.
A primary key is a special
type of Non null attribute
that uniquely identifies
each record in a database
table and which does not
change over time.
 ER Model – Attributes
(contd)
Course_I
d
8. Foreign Key
A foreign key is an
attribute in one table that
is used to establish a link
between the data in
another table. It references Course Course Id
the primary key in another
table creating a
relationship between the
two tables.
8. NULL Attribute
Some attributes can have
null values if the data is
not available or applicable.
 ER Model -
Relationship
3. Relationships
Relationship is a logical association between two or more entities.
Relationships are used to model how entities are connected or interact with
one another in the real world. They form an integral part of the ER model,
helping to capture the business rules and semantics of the system
being modeled. Following three are the most important characteristics of
the relationship in a ER Model.

1. Relationship Degree
2. Cardinality
3. Participation Constraints

1. Relationship Degree
In the Entity-Relationship (ER) Model, the degree of a relationship refers to
the number of entity types that participate in a relationship. It indicates
how many entities are involved in a particular relationship instance.
Accordingly we have :
- Unary relationship
- Binary Relationship
- Ternary Relationship
- Higher degree Relationship
 ER Model -
Relationship
entity type. In this case, the relationship involves only one entity type, but
an entity may be related to itself or to other entities of the same type.
Unary relationships are typically used to model hierarchical or recursive
structures, such as an student supervising another student or a part being a
subpart of another part.

(b) Binary relationship

A binary relationship involves exactly two different entity types. This is the
most common type of relationship in an ER model and represents
associations between pairs of entities. A relationship relates two or more
distinct entities with a specific meaning.
o For example, PROFESSOR Dr. Raman WORKS_FOR the DEPARTMENT
, or Seema WORKS_FOR the RESEARCH .

(c) Ternary relationship

A ternary relationship is a relationship that involves three different entity
types. A ternary relationship is not equivalent to three binary relationships;
it explicitly models the interaction between three entities simultaneously.
Ternary relationships are used to represent scenarios where three entities
are related in a single interaction.
o For example, PROFESSOR Dr. Raman WORKS_FOR the DEPARTMENT
and also for Examination
 ER Model – Relationship
(contd)
(d) Higher degree relationship
A relationship involving more than three entity types is referred to as a
higher-degree relationship (e.g., quaternary for four entities, etc.). These
are less common in practice but are sometimes necessary when multiple
entities are involved in a single interaction.
o For example, PROFESSOR Dr. Raman WORKS_FOR the DEPARTMENT,
Examination , and RESEARCH .

2. Cardinality
Cardinality in the context of the Entity-Relationship (ER) Model refers to the
number
of instances of one entity that can or must be associated with each
instance of another entity through a relationship. The following types of
Cardinality are found in a Database Model:
1. One-to-One (1:1)
2. One-to-Many (1:N)
3. Many-to-One (N:1)
4. Many-to-Many (N: N)

(a) One-to-One (1:1)

One-to-One Cardinality is found when one occurrence of an Entity is
associated with exactly one occurrence of another Entity. For example
 ER Model – Relationship
A student and (contd)
ID_Card are two identities, then one student can have exactly
one Id_Card and only one Id_Card can be assigned to one Student. This is
represented by following notation.

Student Have Id_Card

(b) One-to-Many (1:N)

This cardinality in DBMS relates one occurrence of an Entity to multiple
occurrences of another entity. One-to-Many Cardinality can be observed in
the database when one row of a table is related to many rows of another
table i.e In this case, the entity on the "one" side of the relationship can be
linked to many instances of the entity on the "many" side, but the reverse is
not true. For example in our University example case one PROFESSOR can
Have many STUDENTS at a time. But, many PROFESSOR cannot teach a
single STUDENTS at a time. Hence, this is One-to-Many Cardinality.

Professor Have Student

 ER Model – Relationship
(contd)
(c) Many-to-One (N:1)
A many-to-one relationship is simply the reverse of a one-to-many
relationship. When Many occurrences of an Entity are associated with a
single occurrence of another Entity, it is termed a Many-to-One Cardinality.
This means that many rows of a table are related to a single row of another
table. Many students enroll in one course, but each student is enrolled in
only one course in this specific relationship. Another example is Many
COURSE can be taken by a single PROFESSOR . But one COURSE cannot be
taken by many PROFESSOR .
Course Can Professor

(d) Many-to-Many (N:N)

This cardinality in DBMS is found when multiple occurrences of one Entity
are related to Multiple Occurrences of another Entity. In other words,
multiple rows of a table are related to multiple rows of another table. For
example in the University example , many STUDENTS can work with many
PROFESSOR , and many PROFESSOR can work with multiple STUDENTS in
the institute.
Professor handle Student
 ER Model – Relationship
(contd)
3. Participation Constraint
The participation constraint specifies whether the existence of an entity
depends on its being related to another entity via the relationship type.
This constraint specifies the minimum number of relationship instances
that each entity can participate in, and is sometimes called the minimum
cardinality constraint. There are two types of participation
 Total Participation
 Partial Participation

(a) Total Participation

In total participation, every instance of an entity must be associated with
at least one instance in the related entity set. This means that
participation in the relationship is mandatory for all entities of a particular
type. In ER diagrams, total participation is represented by a double line
connecting the entity to the relationship. For example, every STUDENT
must be registered to at least one COURSE . It follows that no student can
be excluded from a course. It serves as a means of guaranteeing that
every member of one group is connected to something within another,
ensuring that nothing is overlooked or left disconnected.

(a) Partial Participation

Partial participation allows certain aspects of a relationship to be optional.
 ER Model – Relationship
(contd)
every other thing. In our database at a university, for instance Partial
participation can mean that some STUDENT are enrolled in COURSE but not
all STUDENT are registered in them. This recognizes that not everything in
real life is always connected to everything else, this flexibility is crucial.

Course Enrol
Student
l

Partial Course
Total Students

The primary goals of ER modeling is to create a database design that

reflects real-world scenarios and business rules. Participation
constraints ensure that relationships between entities in the model closely
resemble their real-world counterparts. It helps in distinguish between
mandatory and optional relationships between entities. When an ER model
is translated into a relational database schema, participation constraints
determine the necessity of certain foreign key relationships and constraints
in the database.
 Strong & Weak Entity Sets
In the Entity-Relationship (ER) Model, entities can be classified into two
categories based on their independence and reliance on other entities:
1. Strong (Regular) Entity Sets
2. Weak Entity Sets.
These classifications are important because they help define the
relationships and dependencies between different types of entities in a
database.

1. Strong (Regular) Entity Sets

A strong entity set, also known as a regular entity set, is an entity that can
exist independently and does not rely on any other entity for its
identification. It has a primary key that uniquely identifies each instance of
the entity. Each entity in the strong entity set is fully independent and has
a complete set of attributes that are sufficient to uniquely distinguish it
from other entities.Student Cours
Strong entities are represented
ID by a rectangle in ER diagrams.
e Strong Entity :
Student is an entity
Studen that has its own
t Yea
existence and is
r
independent. Has a
Strea Primary key
m
 Strong & Weak Entity
Sets(contd)
2. Weak Entity Sets
A weak entity set is an entity that cannot exist independently and relies on
a strong (owning) entity for its identification. Weak entities do not have a
complete primary key on their own and are identified by being related to
another entity (called the owner entity). They are often identified by a
partial key (sometimes called a discriminator) combined with the
primary key of the strong entity they are related to. Common real-world
examples include things like Dependents of an employee.
Weak entities are represented by a double rectangle in ER diagrams,
and the identifying relationship is shown by a double diamond.
A weak entity type always has a total participation constraint
(existence dependency ) with respect to its identifying relationship.
Countr Stat
y e

Addres
Studen s Dist
t .
Roa
d
 Strong & Weak Entity
Sets(contd)

Countr Stat
Student Cours y
ID e
e
Addres
Ha Dist
Student s
s
.
Roa
Strea Yea d
m r

Strong Entity Weak Entity

Type Type
In the ER diagram , using a double diamond, the Entity-Relationship Diagram
represents a relationship between the strong and the weak entity type.
ER Diagram
Notations
Entity E1 R E2

Total Participation of E2 in R
Weak Entity
1 N
E1 R E2

Relationship
Cardinality Ratio 1 to Many for E1:E2
in R
N 1
E1 R E2
attribute

Cardinality Ratio Many to 1 for E1:E2

in R
Key attribute M N
E1 R E2

Multi value
attribute Cardinality Ratio Many to manyfor E1:E2
in R
 ER Diagram : University Course
Registration
https://app.creately.com/d/kMpo3308pPo/edit
ER Diagram : Company
 ER Diagram : University Library
( Assignment -1)
Problem statement :
Identify the entities, attributes, and relationships from the given
requirements. Specify the primary keys and foreign keys for each
entity and draw the ER diagram showing the relationships between
the entities. You may enlarge the scenario if you want.
You may consider following scenario :

• Library contains many Books. Book may have some attributes say like
(Book_Id, Title, Category, Author etc ). You can add more that you feel
deemed fit.
• Library members can borrow books. Libraray members may have
attributes like ( Member_Id , Name , email , Membership_Start_Date ,
Membership_Status etc). You can add more that you feel deemed fit.
• Borrowing process can have attributes say (Borrow_Date , Return_Date
etc ). Add more if you feel there can be more attributes.
• Library Staff manages borrowing the book and may have attributes like (
Staf_Id , Position , Hire_Date, email_Id)
• Book can have variety of categories. Please assume as per your will.
 ER Diagram : ATM Vending
Machine
Problem statement :
( Assignment -2)
Identify the entities, attributes, and relationships from the given
requirements. Specify the primary keys and foreign keys for each
entity and draw the ER diagram showing the relationships between
the entities. You may enlarge the scenario if you want.
You may consider following scenario :

• The ATM user is the Bank customer. Each customer may have some
attributes say like (Customer_Id, Name, Address, Age etc ).
• The customer shall have a Bank accounts. Each Bank account may have
attributes like ( Account_Id , Account_type, Balance, Account_Status,
etc).
• The ATM machine may have attributes say (ATM_ID , Location ,
Install_Date , Status etc ). Add more if you feel there can be more
attributes.
• The ATM transaction may have attributes like ( Transaction_Id ,
Transaction_Type , Transaction_Amount, Transaction_Date ,
Transaction_Status etc)
• The customer ATM card may have attributes say like ( Card_Number ,
Card_Type , Card_Status etc , PIN , Expiry_Date etc).
 ER Diagram : Company database
( Assignment -3 )
Problem statement :
Identify the entities, attributes, and relationships from the given
requirements. Specify the primary keys and foreign keys for each
entity and draw the ER diagram showing the relationships between
the entities. You may enlarge the scenario if you want.
You may consider following scenario :

• The company is organized into DEPARTMENTs, department has a name,

number, and an employee who manages the department. A
department may have several locations.
• Each department controls a number of PROJECTs. Each project has a
name, number, and is located at a single location.
• We store each EMPLOYEE's social security number, address, salary, sex,
number of hours per week , direct supervisor and birth date. Each
employee works for one department but may work on several projects.
• Each employee may have a number of DEPENDENTs. For each
dependent, we keep their name, sex, birth date, and relationship to the
employee.
• We might store each EMPLOYEE performance data like last Promotion
date , Basic_Pay , Hike_given , Rating etc.
Thanks