MODULE 1

RELATIONAL DATABASE
Purpose of Database System
• Applications of Database System

• Database systems have a prominent effect in many industries

which includes finance, telecommunications, logistics,
manufacturing, entertainment, and more. They enable efficient
data storage, retrieval, and analysis, for the user or the
organization helping in fast and efficient decision-making.
View of Data
Data Abstraction
 Physical or Internal Level
• It is the lowest level of data abstraction which defines how data is
stored in database .
• It defines data structures used to store data and methods to access
data in database.
• It is very complex to understand and hence kept hidden from user.
• Database administrator decides how and where to store the data in
database.
• Physical level deals with actual storage details like data
organization, disk space allocation and data access methods.
Logical or Conceptual Level

• It is intermediate level present next to physical level.

• It defines what data is present in database and their
relationships between them .
• It is less complex as compared to physical level.
• Programmers generally work at this level and depending on
data, structure of tables, relationships and their constraints is
decided at this level.
View or External Level

•It is the highest level in abstraction.

•Many users of the database system do not need all
information; instead, they need to access only a part of
the database.
•The system may provide many views for the same
database.
•There are different levels of views and each view
defines only a part of whole data required to user.
• “Schema” and “Instance” are key ideas in a database
management system (DBMS) that help organize and manage
data.
• A schema can be referred to as the blueprint of the database
while an instance is the actual contents of the database at a
given point of time.
What is Schema?
• Schema is the overall description of the database.
• It outlines the tables, fields, relationships, views, indexes, and
other elements within the database.
• The basic structure of how the data will be stored in the database
is called schema.
• In DBMS, the term schema refers to the architecture of the
database which describes how it will appear or will be constructed.
• It describes the organization of data such as tables, relationships
as well as constraints.
• A schema is a template that dictates how data items in a database
will be stored, arranged, and accessed.
Schema
•Schema is of three types: Logical Schema, Physical
Schema and view Schema.
•Logical Schema – It describes the database designed
at a logical level.
•Physical Schema – It describes the database designed
at the physical level.
•View Schema – It defines the design of the database at
the view level. (sometimes called sub schemas)
What is Instance?
• An instance of DBMS refers to real data in a database coming
at some particular point in time.
• Instance on the other hand refers to the content in the
database in as much as it refers to the structure defined under a
particular schema at a given point.
• Example

• Let’s say a table teacher in our database whose name is

School, suppose the table has 50 records so the instance of the
database has 50 records for now and tomorrow we are going to
add another fifty records so tomorrow the instance has a total of
100 records. This is called an instance.
• We typically follow the below steps for designing a database
for an application.
• Gather the requirements (functional and data) by asking
questions to the database users.

• Do a logical or conceptual design of the database. This is

where ER model plays a role. It is the most used graphical
representation of the conceptual design of a database.

• The Entity Relationship Model is a model for identifying entities

(like student, car or company) to be represented in the
database and representation of how those entities are related.
• Why Use ER Diagrams In DBMS?
• ER diagrams represent the E-R model in a database, making
them easy to convert into relations (tables).

• ER diagrams provide the purpose of real-world modeling of

objects which makes them intently useful.

• ER diagrams require no technical knowledge of the underlying

DBMS used.

• It gives a standard solution for visualizing the data logically.

Symbols Used in ER Model
• ER Model is used to model the logical view of the system from a
data perspective which consists of these symbols:
• Rectangles: Rectangles represent Entities in the ER Model.

• Ellipses: Ellipses represent Attributes in the ER Model.

• Diamond: Diamonds represent Relationships among Entities.

• Lines: Lines represent attributes to entities and entity sets with

other relationship types.

• Double Ellipse: Double Ellipses represent Multi-Valued Attributes.

• Double Rectangle: Double Rectangle represents a Weak Entity.

Components of ER Diagram
• One of the various types of data models in dbms follows the
paradigms of object-oriented programming.
• The data is in form of objects, which are instances of a certain class
with each having its own methods and attributes.
• In an object-oriented model, objects can inherit attributes and
methods from parent objects, allowing for the hierarchical
organization of the data.
• For example, in a database for a company, the Employee object
might inherit attributes and methods from the Person object, which
might inherit from the Object object.
• It is based on the pillars of object-oriented programming such as
Polymorphism, Inheritance, and Encapsulation.
Semi structured Data Model
• The semi-structured data model is a type of data model that allows
for flexible representation of data without requiring a strict schema
or predefined structure.
• In a semi-structured data model, data is organized into a hierarchy
of nodes and edges, with each node representing a specific entity
or element and each edge representing a relationship between
nodes.
• Semi-structured data often takes the form of documents, such as
HTML, XML, or JSON files, which contain data organized into a
hierarchical structure.
• However, unlike a structured data model, semi-structured data
does not require a strict schema or predefined structure, meaning
that the data can be modified or updated without requiring
extensive changes to the underlying data model.
▪ Semi-structured data is a type of data that is not purely structured, but also not completely
unstructured.
▪ It contains some level of organization or structure, but does not conform to a rigid schema
or data model, and may contain elements that are not easily categorized or classified.
▪ Characteristics of semi-structured Data:
• Data can not be stored in the form of rows and columns as in Databases

• Semi-structured data contains tags and elements (Metadata) which is used to group data
and describe how the data is stored

• Similar entities are grouped together and organized in a hierarchy

• Entities in the same group may or may not have the same attributes or properties

• Does not contain sufficient metadata which makes automation and management of data
difficult

• Size and type of the same attributes in a group may differ

• Due to lack of a well-defined structure, it can not used by computer programs easily
 Database Architecture
•A Database stores a lot of critical information to
access data quickly and securely. Hence it is
important to select the correct architecture for efficient
data management.
•Types of DBMS Architecture
•There are several types of DBMS Architecture that we
use according to the usage requirements.
Types of DBMS Architecture are
•1-Tier Architecture
•2-Tier Architecture
 1-Tier Architecture
• In 1-Tier Architecture the database is directly available to the user, the
user can directly sit on the DBMS and use it that is, the client, server, and
Database are all present on the same machine.
• This setup is simple and is often used in personal or standalone
applications where the user interacts directly with the database.
• Advantages of 1-Tier Architecture

• Simple Architecture: 1-Tier Architecture is the most simple

architecture to set up, as only a single machine is required to
maintain it.

• Cost-Effective: No additional hardware is required for

implementing 1-Tier Architecture, which makes it
cost-effective.

• Easy to Implement: 1-Tier Architecture can be easily deployed,

and hence it is mostly used in small projects.
2-Tier Architecture
• The 2-tier architecture is similar to a basic client-server model .
The application at the client end directly communicates with the
database on the server side.
• APIs like ODBC and JDBC are used for this interaction.
• The server side is responsible for providing query processing and
transaction management functionalities.
• On the client side, the user interfaces and application programs
are run.
• The application on the client side establishes a connection with
the server side to communicate with the DBMS.

For Example: A Library Management System used in schools or

small organizations is a classic example of two-tier architecture.
1. Client Layer (Tier 1): This is the user interface that library staff
or users interact with.
For example: they might use a desktop application to search for
books, issue them, or check due dates.
2. Database Layer (Tier 2): The database server stores all the
library records such as book details, user information, and
transaction logs.
• The client layer sends a request (like searching for a book) to
the database layer which processes it and sends back the
result. This separation allows the client to focus on the user
interface, while the server handles data storage and retrieval.
• Advantages of 2-Tier Architecture
• Easy to Access: 2-Tier Architecture makes easy access to the
database, which makes fast retrieval.
• Scalable: We can scale the database easily, by adding clients or
upgrading hardware.
• Low Cost: 2-Tier Architecture is cheaper than 3-Tier Architecture
and Multi-Tier Architecture .
• Easy Deployment: 2-Tier Architecture is easier to deploy than
3-Tier Architecture.
• Simple: 2-Tier Architecture is easily understandable as well as
simple because of only two components.
3-Tier Architecture
• In 3-Tier Architecture , there is another layer between the client and
the server.
• The client does not directly communicate with the server. Instead, it
interacts with an application server which further communicates
with the database system and then the query processing and
transaction management takes place.
• This intermediate layer acts as a medium for the exchange of
partially processed data between the server and the client. This type
of architecture is used in the case of large web applications.
For Example: E-commerce Store
• User: You visit an online store, search for a product and add it to
your cart.
Processing: The system checks if the product is in stock, calculates
the total price and applies any discounts.
Database: The product details, your cart and order history are stored
in the database for future reference.
Advantages of 3-Tier Architecture

• Enhanced scalability: Scalability is enhanced due to the

distributed deployment of application servers. Now, individual
connections need not be made between the client and server.

• Data Integrity: 3-Tier Architecture maintains Data Integrity.

Since there is a middle layer between the client and the server,
data corruption can be avoided/removed.

• Security: 3-Tier Architecture Improves Security. This type of

model prevents direct interaction of the client with the server
thereby reducing access to unauthorized data.
Fig: Database System Architecture
• A "database architecture" refers to the overall design and structure of
a database system, including how data is stored, organized, and
accessed within the system.

• A "tier architecture" describes how the components of a database

system are distributed across different layers, essentially separating
functionalities like user interface, application logic, and data storage
into distinct tiers for better scalability and management;

• Database architecture focuses on the internal workings of a

database, while tier architecture focuses on how the database
interacts with other application layers within a system.
• Relationship Type and Relationship Set
• A Relationship Type represents the association between entity types. For example, ‘Enrolled in’ is
a relationship type that exists between entity type Student and Course. In ER diagram, the
relationship type is represented by a diamond and connecting the entities with lines.

A set of relationships of the same type is known as a relationship set. The following
relationship set depicts S1 as enrolled in C2, S2 as enrolled in C1, and S3 as registered in
C3.
Mapping cardinality in a Database
Management System (DBMS) defines the
number of entity instances that can be
associated with another entity instance in a
relationship.
•Each entity in Set A is associated with at most one entity in Set B, and vice versa.

•Example: Person ↔ Passport

•Each person has only one passport, and each passport belongs to one person.

E-R Representation:

(Person) ---- (Has) ---- (Passport)

•One entity in Set A is associated with multiple entities in Set B, but each entity in
Set B is related to only one entity in Set A.

•Example: Teacher ↔ Students

•One teacher can teach many students, but each student has only one
teacher (in a simple scenario).

E-R Representation:

(Teacher) ---- (Teaches) ----> (Students)

•Multiple entities in Set A are associated with one entity in Set B.

•Example: Employees ↔ Department

•Many employees work in one department, but each department can have
multiple employees.

E-R Representation:

(Employees) ----> (Works In) ---- (Department)

•Multiple entities in Set A are associated with multiple entities in Set B.

•Example: Students ↔ Courses

•A student can enroll in many courses, and a course can have many
students.

E-R Representation:

(Student) ---- (Enrolls) ---- (Course)

Key Constraints
What Are Constraints In DBMS?
• Constraints in DBMS (Database Management Systems) encompass rules or
conditions applied to database data, ensuring data integrity, consistency, and
adherence to business rules.
• They define limitations and requirements that data must meet, preventing the
entry of invalid or inconsistent data.
• Constraints serve as pre-established rules governing the behavior and
relationships of data in a database, contributing to the maintenance of accuracy
and reliability.
• Different types of key constraints are:
1. NOT NULL Constraint
2. UNIQUE Constraint
3. PRIMARY KEY Constraint
4. FOREIGN KEY Constraint
5. CHECK Constraint
6. DEFAULT Constraint
3.Primary Key Constraint:
• A primary key is a column or a set of columns that uniquely identifies each row in a table.
• The primary key constraint ensures that the values in the specified columns are unique
and not NULL.
• There can be only one primary key in a table.
• Example: Let’s consider a simple example of a primary key constraint in a relational
database using a Students table:

In this example:
1.StudentID is the primary key for the Students table.
2.FirstName, LastName, Age, and other columns are attributes associated
with each student.
4. Foreign Key Constraint:
• A foreign key is a column or a set of columns in a table that
refers to the primary key of another table.
• It establishes a relationship between the two tables, enforcing
referential integrity.
• The foreign key constraint ensures that values in the foreign key
column(s) match values in the referenced primary key
column(s).
• The foreign key constraint ensures referential integrity,
meaning that relationships between tables are maintained, and
it helps prevent inconsistencies in the data. It’s a powerful tool
for enforcing relationships between tables in a relational
database.

• Example: Let’s consider a simple example to illustrate the use

 • Customers Table: Orders
Table:

In this example:
1.In the Customers table, CustomerID is the primary key that uniquely identifies each customer. It
is also referenced by the foreign key in the Orders table.
2.In the Orders table, OrderID is the primary key that uniquely identifies each order. The
CustomerID column is a foreign key that establishes a relationship with the Customers table.
3.The FOREIGN KEY (CustomerID) REFERENCES Customers(CustomerID) statement in the
Orders table specifies that the CustomerID column in the Orders table is a foreign key, and it
must refer to a valid CustomerID in the Customers table.
5. CHECK Constraint

• The CHECK constraint allows us to specify a condition that data must

satisfy before it is inserted into the table. This can be used to enforce
rules, such as ensuring that a column’s value meets certain criteria (e.g.,
age must be greater than 18)
• Example:

Explanation: In the above table, the CHECK constraint ensures that only
students aged 18 or older can be inserted into the table.
 6. DEFAULT Constraint

• The DEFAULT constraint provides a default value for a column when no

value is specified during insertion. This is useful for ensuring that certain
columns always have a meaningful value, even if the user does not
provide one
• Example:

Explanation: Here, if no value is provided for AGE during an insert, the default value of
18 will be assigned automatically.
Participation Constraints

What is a Participation Constraint?

• A participation constraint in a Database Management System
(DBMS) defines whether an entity's participation in a relationship is
mandatory or optional. It ensures that certain entities must or may
participate in a relationship.
Types of Participation Constraints
1. Total Participation
2. Partial Participation
1. Total Participation
• Every instance of the entity must participate in the relationship.
• Represented by a double line in an E-R diagram.
• Example: "Every student must have a university ID"
• Example
• Entities: Student and University
Relationship: Enrolled_In
• Every Student must be enrolled in a University.
• E-R Representation

Every student is linked to a university.

2. Partial Participation
• Some entity instances may or may not participate in a relationship.
• Represented by a single line in an E-R diagram.
• Example: "Not every employee manages a department"
• Example
• Entities: Employee and Department
Relationship: Manages
• Some employees manage a department, but not all.
• E-R Representation

Only some employees are managers.

Consider the below E-R diagram
• which consists of two entity sets, instructor and student related through a binary
relationship set advisor.The attributes associated with instructor are ID, name, and salary.
The attributes associated with student are ID, name, and tot cred.
• Attributes of an entity set that are members of the primary key are underlined.
• If a relationship set has some attributes associated with it, then it enclose the attributes in
a rectangle and link the rectangle with a dashed line to the diamond representing that
relationship set.
• In this figure ,the date descriptive attribute attached to the relationship set advisor to
specify the date on which an instructor became the advisor
Mapping Cardinality
• The relationship set advisor, between the instructor and student entity sets
may be one-to-one, one-to-many, many-to-one, or many-to-many. To
distinguish among these types,we draw either a directed line (→) or an
undirected line (—) between the relationship set and the entity set in
question, as follows:
• One-to-one: Draw a directed line from the relationship set advisor to both
entity sets instructor and student ( Figure:a). This indicates that an instructor
may advise at most one student, and a student may have at most one advisor.
• One-to-many: Draw a directed line from the relationship set advisor to the
entity set instructor and an undirected line to the entity set student ( Figure:b).
This indicates that an instructor may advise many students, but a studentmay
have at most one advisor.
• Many-to-one: Draw an undirected line from the relationship set advisor to
the entity set instructor and a directed line to the entity set student. This
indicates that an instructor may advise at most one student, but a student may
have many advisors.
 Complex Attributes
• A complex attribute in a database management system (DBMS) is a combination of composite
and multi-valued attributes. It can be broken down into smaller components and can contain
multiple values.
• It is formed by nexting of multivalued attributes with composite attributes to form a single
attributes .

A multivalued attribute phone number, denoted by

“{phone number}”, and a derived attribute age, depicted
by a “age ( )”.

E-R diagram with composite, multivalued, and derived

 Roles in E-R Diagrams in DBMS
Roles in E-R Diagrams
•· It is a function that plays(relationship) in an entity called its role.
•· Roles are normally explicit and not specified.
•· Useful when the relationship meaning needs to clarify.
•· Example, The relationship works-for define in employees as manager or worker. 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 the semantics of the relationship.
Non binary relationship sets

Binary Relationship
When there is a relationship between two different entities, it is known as a binary
relationship. Examples of a binary relationship can be shown as follows −
Ternary Relationship
When there is a relationship between three different entities, it is known as a
ternary relationship. An example of a ternary relationship can be shown as follows
−
Example:
Database:
A database storing information about a company's employees and their
dependents.
Entities:
● Employee (strong entity): This is the identifying entity, with each
employee having a unique ID.
● Dependent (weak entity): Information about each employee's
dependents, which requires the employee ID to be fully identified.
Weak entities are represented with double rectangular box in the ER Diagram and the
identifying relationships are represented with double diamond. Partial Key attributes are
represented with dotted lines.
ISA relationship
In an E-R (Entity-Relationship) diagram, an ISA relationship represents inheritance or a
generalization-specialization hierarchy between entities. It is used to model subclasses and superclasses, similar
to object-oriented programming.

Explanation:
● If Entity A is a subtype of Entity B, we say A ISA B.
● The ISA relationship allows the subtype entity to inherit attributes and relationships of the supertype entity.
● This helps in representing hierarchical data structures.

Example:
Consider an organization where we have different types of employees:

1. Employee (superclass)
○ Attributes: Emp_ID, Name, Salary
2. Manager (subclass of Employee)
○ Attributes: Bonus
3. Technician (subclass of Employee)
○ Attributes: SkillSet

The ISA relationship is drawn as a triangle connecting Employee to its subtypes (Manager and Technician).

●
Key Concepts:
1. Generalization (Bottom-up approach)
○ Merging multiple entities into a higher-level entity.
○ Example: Car and Bike can be generalized into Vehicle.
2. Specialization (Top-down approach)
○ Breaking a higher-level entity into lower-level entities.
○ Example: Employee can be specialized into Manager and Technician.

Why Use ISA Relationships?

● Avoids redundancy by storing common attributes in the superclass.
● Enhances data organization by structuring related entities.
● Supports inheritance, reducing complexity in modeling.
KEYS
Why do we require Keys in a DBMS?
★ Keys in a DBMS to ensure that data is organized, accurate,
and easily accessible.
★ Keys help to uniquely identify records in a table, which
prevents duplication and ensures data integrity.
★ Keys also establish relationships between different tables,
allowing for efficient querying and management of data.
★ Without keys, it would be difficult to retrieve or update
specific records, and the database could become
inconsistent or unreliable.
 Different Types of Database Keys
Super Key

The set of one or more attributes (columns) that can uniquely identify a tuple
(record) is known as Super Key. For Example, STUD_NO, (STUD_NO,
STUD_NAME), etc.
● A super key is a group of single or multiple keys that uniquely identifies
rows in a table. It supports NULL values in rows.
● A super key can contain extra attributes that aren’t necessary for
uniqueness. For example, if the “STUD_NO” column can uniquely identify a
student, adding “SNAME” to it will still form a valid super key, though it’s
unnecessary.
 Candidate Key

Candidate Key

★ The minimal set of attributes that can uniquely identify a tuple is known as a candidate key.
★ It is a super key where proper subset is not a super key.
For Example, STUD_NO in STUDENT relation.
● A candidate key is a minimal super key(as minimum as possible), meaning it can uniquely
identify a record but contains no extra attributes.
● It is a super key with no repeated data is called a candidate key.
● The minimal set of attributes that can uniquely identify a record.
● A candidate key must contain unique values, ensuring that no two rows have the same value
in the candidate key’s columns.
● Every table must have at least a single candidate key.
● A table can have multiple candidate keys but only one primary key.
 Primary Key
Primary Key

There can be more than one candidate key in relation out of which one can be chosen as the
primary key. For Example, STUD_NO, as well as STUD_PHONE, are candidate keys for relation
STUDENT but STUD_NO can be chosen as the primary key (only one out of many candidate keys).
● A primary key is a unique key, meaning it can uniquely identify each record (tuple) in a
table.
● It must have unique values and cannot contain any duplicate values.
● A primary key cannot be NULL, as it needs to provide a valid, unique identifier for every
record.
● A primary key does not have to consist of a single column. In some cases, a composite
primary key (made of multiple columns) can be used to uniquely identify records in a
table.
● Databases typically store rows ordered in memory according to primary key for fast
access of records using primary key.
Relationship between Primary Key, Candidate Key and Super Key
The Union Operation
Union(U) : Union Operator is basically used to combine the results of two queries into a single
result. The only condition is that both queries must return same number of columns with same data
types.
Illustration : If in case we want a list of all the employee from two different department . Then in
that case we should use union operation to merge both the list from two different department.
Union operation in relational algebra is the same as union operation in set theory.
Problems(Write the queries)

1.To find the set of all courses taught in the Fall 2009 semester.
2.To find the set of all courses taught in the Spring 2010
semester.
π(Student_Name)FRENCH π(Student_Name)GERMAN
Cross Product(X) : Cartesian product Operator combines every row of one
table with every row of another table , producing all the possible
combination. It’s mostly used as a precursor to more complex operation like
joins.
Cross-product between two relations. Let’s say A and B, so the cross
product between A X B will result in all the attributes of A followed by each
attribute of B. Each record of A will pair with every record of B.
Formal Definition of the Relational Algebra
Set Intersection(∩) : Set Intersection basically allows to fetches only those rows of data that are common
between two sets of relational tables.
Illustration : If we want to find the number of employees who work in both IT and Marketing Department ,
then in that case we use Intersection Operator.
Set Intersection in relational algebra is the same set intersection operation in set theory.
Example: From the above table of FRENCH and GERMAN, the Set Intersection is used as follows:
π(Student_Name)FRENCH ∩ π(Student_Name)GERMAN
Constraints on Relational Database Model
Relational Constraints
● These are the restrictions or sets of rules imposed on the database contents.
● It validates the quality of the database.
● It validates the various operations like data insertion, updation, and other processes that
have to be performed without affecting the integrity of the data.
● It protects us against threats/damages to the database. Mainly Constraints on the
relational database are of 4 types
● Domain constraints
● Key constraints or Uniqueness Constraints
● Entity Integrity constraints
● Referential integrity constraints
1. Domain Constraints

● Every domain must contain atomic values(smallest indivisible units) which means composite
and multi-valued attributes are not allowed.
● We perform a data type check here, which means when we assign a data type to a column
we limit the values that it can contain. Eg. If we assign the datatype of attribute age as int, we
can’t give it values other than int datatype.
2. Key Constraints or Uniqueness Constraints

● These are called uniqueness constraints since it ensures that every tuple in the relation should be
unique.
● A relation can have multiple keys or candidate keys(minimal superkey), out of which we choose one of
the keys as the primary key, we don’t have any restriction on choosing the primary key out of candidate
keys, but it is suggested to go with the candidate key with less number of attributes.
● Null values are not allowed in the primary key, hence Not Null constraint is also part of the key
constraint.
3. Entity Integrity Constraints

● Entity Integrity constraints say that no primary key can take a NULL value, since using the
primary key we identify each tuple uniquely in a relation.
4. Referential Integrity Constraints

● The Referential integrity constraint is specified between two relations or tables and
used to maintain the consistency among the tuples in two relations.
● This constraint is enforced through a foreign key, when an attribute in the foreign key of
relation R1 has the same domain(s) as the primary key of relation R2, then the foreign
key of R1 is said to reference or refer to the primary key of relation R2.
● The values of the foreign key in a tuple of relation R1 can either take the values of the
primary key for some tuple in relation R2, or can take NULL values, but can’t be empty.
Explanation: In the above tables, the DNO of Table 1 is the foreign key, and DNO in
Table 2 is the primary key. DNO = 22 in the foreign key of Table 1 is not allowed
because DNO = 22 is not defined in the primary key of table 2. Therefore, Referential
integrity constraints are violated here.
Advantages of Relational Database Model
● It is simpler than the hierarchical model and network model.
● It is easy and simple to understand.
● Its structure can be changed anytime upon requirement.
● Data Integrity: The relational database model enforces data integrity through various constraints such as primary
keys, foreign keys, and unique constraints. This ensures that the data in the database is accurate, consistent, and
valid.
● Flexibility: The relational database model is highly flexible and can handle a wide range of data types and
structures. It also allows for easy modification and updating of the data without affecting other parts of the
database.
● Scalability: The relational database model can scale to handle large amounts of data by adding more tables,
indexes, or partitions to the database. This allows for better performance and faster query response times.
● Security: The relational database model provides robust security features to protect the data in the database. These
include user authentication, authorization, and encryption of sensitive data.
● Data consistency: The relational database model ensures that the data in the database is consistent across all
tables. This means that if a change is made to one table, the corresponding changes will be made to all related
tables.
● Query Optimization: The relational database model provides a query optimizer that can analyze and optimize SQL