Database Management System

Database Management System (DBMS) is a software used to manage data from a database.

• A database is a structured collection of data that is stored in an electronic device. The data
can be text, video, image or any other format.

• A relational database stores data in the form of tables and a NoSQL database in the form
of key-value pairs.

• SQL (Structured Query Language) is a standard language for accessing and manipulating
data in a relational database.

• A DBMS is a software that allows to create, update and retrieval of data in an organized
way. It also provides security to the database.

• Examples of relational DBMS are MySQL, Oracle, Microsoft SQL Server, Postgre SQL and
Snowflake.

• Examples of NoSQL DBMS are MongoDB, Cassandra, DynamoDB and Redis.

DBMS is a software system that manages, stores, and retrieves data efficiently in a structured
format.

• It allows users to create, update, and query databases efficiently.

• Ensures data integrity, consistency, and security across multiple users and applications.

• Reduces data redundancy and inconsistency through centralized control.

• Supports concurrent data access, transaction management, and automatic backups

DBMS acts as a bridge between a central database and multiple clients-including apps and users.
It uses APIs to handle data requests, enabling apps and users to interact with the database
securely and efficiently without directly accessing the data.
Problems with Traditional File-Based Systems

Before the introduction of modern DBMS, data was managed using basic file systems on hard
drives. While this approach allowed users to store, retrieve and update files as needed, it came
with numerous challenges

• Data Redundancy: Duplicate entries across files

• Inconsistency: Conflicting or outdated information

• Difficult Access: Manual file search required

• Poor Security: No control over data access

• Single-User Access: No support for collaboration

• No Backup/Recovery: Data loss was often permanent

A university file-based system storing data in separate files (e.g., Academics, Results, Hostels)
often faced these problems.

Components of DBMS Applications

Any DBMS based applications is made up of six key components that work together to handle data
effectively.

1. Hardware

• Physical devices like servers, disks, input-output devices (keyboard, monitor, printer).

• Stores and processes data; interfaces between real-world inputs and digital systems.

• Examples: Personal computer hard disk, RAM, network devices used for DBMS operations.

2. Software

• Actual DBMS software like MySQL, Oracle, PostgreSQL.

• Includes the database engine, OS, network software, and application tools.

• Translates database access languages into operations.

3. Data

• Raw facts stored in structured or unstructured formats.

• Operational Data: Actual user data (e.g., name, age).

• Metadata: Data about data (e.g., storage time, size, data type).

• Core reason DBMS exists—to manage and store data efficiently.

4. Procedures

• Instructions and rules for using DBMS effectively.

• Covers setup, login/logout, data validation, backup, access control, and report generation.

• Helps ensure consistent and secure use of the system.

5. Database Access Language

• Used to interact with the database (create, read, update, delete data).

• Examples: SQL, MyAccess, Oracle PL/SQL.

• DDL (Data Definition Language) – CREATE, ALTER, DROP

• DML (Data Manipulation Language) – INSERT, UPDATE, DELETE

6. People

• Users interacting with DBMS at different levels:

• Database Administrators (DBA) – Manage security, performance, user access.

• Developers – Build applications using the database.

• End Users – Use applications to access the database (e.g., students, employees).
Types of DBMS

There are several types of Database Management Systems (DBMS), each tailored to different data
structures, scalability requirements and application needs. The most common types are as
follows:

1. Relational Database Management System (RDBMS)

• It organizes data into tables (relations) composed of rows and columns.

• Uses primary keys to uniquely identify rows and foreign keys to establish relationships
between tables.

• Queries are written in SQL (Structured Query Language), which allows for efficient data
manipulation and retrieval.

Examples: MySQL oracle, Microsoft SQL Server and Postgre SQL.

2. NoSQL DBMS

• They are designed to handle large-scale data and provide high performance for scenarios
where relational models might be restrictive.

• They store data in various non-relational formats, such as key-value pairs, documents,
graphs or columns.

• These flexible data models enable rapid scaling and are well-suited for unstructured or
semi-structured data.

Examples: MongoDB, Cassandra, DynamoDB and Redis.

3. Object-Oriented DBMS (OODBMS)

• It integrates object-oriented programming concepts into the database environment,

allowing data to be stored as objects.

• Supports complex data types and relationships, making it ideal for applications requiring
advanced data modeling and real-world simulations.
Examples: ObjectDB, db4o.

4. Hierarchical Database

• Organizes data in a tree-like structure, where each record (node) has a single parent and
have multiple children.

• This model is similar to a file system with folders and subfolders.

• It is efficient for storing data with a clear hierarchy, such as organizational charts or file
directories.

• Navigation is fast and predictable due to the fixed structure.

• It lacks flexibility and difficult to restructure or handle complex many-to-many

relationships.

Example: IBM Information Management System (IMS).

5. Network Database

• It uses a graph-like model to allow more complex relationships between entities.

• Unlike the hierarchical model, it permits each child to have multiple parents, enabling
many-to-many relationships.

• Data is represented using records and sets, where sets define the relationships.

• It is more flexible than the hierarchical model and better suited for applications with
complex data linkages.

Example: Integrated Data Store (IDS), TurboIMAGE.

6. Cloud-Based Database

• They are hosted on cloud computing platforms like AWS, Azure or Google Cloud.

• They offer on-demand scalability, high availability, automatic backups and remote
accessibility.
 • These databases can be relational (SQL) or non-relational (NoSQL) and are maintained by
cloud service providers, reducing administrative overhead.

• They support modern application requirements, including distributed access and real-time
analytics.

Example: Amazon RDS (for SQL), MongoDB Atlas (for NoSQL), Google BigQuery.

Database Languages

Database languages are specialized sets of commands and instructions used to define, manipulate
and control data within a database. Each language type plays a distinct role in database
management, ensuring efficient storage, retrieval and security of data. The primary database
languages include:

1. Data Definition Language (DDL)

DDL is the short name for Data Definition Language, which deals with database schemas and
descriptions, of how the data should reside in the database.

• CREATE: to create a database and its objects like (table, index, views, store procedure,
function and triggers)

• ALTER: alters the structure of the existing database

• DROP: delete objects from the database

• TRUNCATE: remove all records from a table, including all spaces allocated for the records
are removed

• COMMENT: add comments to the data dictionary

• RENAME: rename an object

2. Data Manipulation Language (DML)

DML focuses on manipulating the data stored in the database, enabling users to retrieve, add,
update and delete data.
 • SELECT: retrieve data from a database

• INSERT: insert data into a table

• UPDATE: updates existing data within a table

• DELETE: Delete all records from a database table

• MERGE: UPSERT operation (insert or update)

• CALL: call a PL/SQL or Java subprogram

• EXPLAIN PLAN: interpretation of the data access path

• LOCK TABLE: concurrency Control

3. Data Control Language (DCL)

DCL commands manage access permissions, ensuring data security by controlling who can
perform certain actions on the database.

• GRANT: Provides specific privileges to a user (e.g., SELECT, INSERT).

• REVOKE: Removes previously granted permissions from a user.

4. Transaction Control Language (TCL)

TCL commands oversee transactional data to maintain consistency, reliability and atomicity.

• ROLLBACK: Undoes changes made during a transaction.

• COMMIT: Saves all changes made during a transaction.

• SAVEPOINT: Sets a point within a transaction to which one can later roll back.

5. Data Query Language (DQL)

DQL is a subset of DML, specifically focused on data retrieval.

• SELECT: The primary DQL command, used to query data from the database without
altering its structure or contents.
A DBMS architecture defines how users interact with the database to read, write, or update
information. A well-designed architecture and schema (a blueprint detailing tables, fields and
relationships) ensure data consistency, improve performance and keep data secure.

Types of DBMS Architecture

There are several types of DBMS Architecture that we use according to the usage requirements.

• 1-Tier Architecture

• 2-Tier Architecture

• 3-Tier Architecture

1-Tier Architecture

In 1-Tier Architecture, the user works directly with the database on the same system. This means
the client, server and database are all in one application. The user can open the application,
interact with the data and perform tasks without needing a separate server or network
connection.

• A common example is Microsoft Excel. Everything from the user interface to the logic and
data storage happens on the same device. The user enters data, performs calculations and
saves files directly on their computer.

• This setup is simple and easy to use, making it ideal for personal or standalone
applications. It does not require a network or complex setup, which is why it's often used
in small-scale or individual use cases.

• This architecture is simple and works well for personal, standalone applications where no
external server or network connection is needed.

Advantages of 1-Tier Architecture

Below mentioned are the 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.

Disadvantages of 1-Tier Architecture

• Limited to Single User: Only one person can use the application at a time. It’s not designed
for multiple users or teamwork.

• Poor Security: Since everything is on the same machine, if someone gets access to the
system, they can access both the data and the application easily.

• No Centralized Control: Data is stored locally, so there's no central database. This makes
it hard to manage or back up data across multiple devices.

• Hard to Share Data: Sharing data between users is difficult because everything is stored
on one computer.

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.

• 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.
 • 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.

Disadvantages of 2-Tier Architecture

• Limited Scalability: As the number of users increases, the system performance can slow
down because the server gets overloaded with too many requests.

• Security Issues: Clients connect directly to the database, which can make the system more
vulnerable to attacks or data leaks.

• Tight Coupling: The client and the server are closely linked. If the database changes, the
client application often needs to be updated too.

• Difficult Maintenance: Managing updates, fixing bugs, or adding features becomes

harder when the number of users or systems increases.
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.

• 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.

Disadvantages of 3-Tier Architecture

• More Complex: 3-Tier Architecture is more complex in comparison to 2-Tier Architecture.

Communication Points are also doubled in 3-Tier Architecture.

• Difficult to Interact: It becomes difficult for this sort of interaction to take place due to the
presence of middle layers.
 • Slower Response Time: Since the request passes through an extra layer (application
server), it may take more time to get a response compared to 2-Tier systems.

• Higher Cost: Setting up and maintaining three separate layers (client, server and
database) requires more hardware, software and skilled people. This makes it more
expensive.

Introduction of ER Model

The Entity-Relationship Model (ER Model) is a conceptual model for designing a databases. This
model represents the logical structure of a database, including entities, their attributes and
relationships between them.

• Entity: An objects that is stored as data such as Student, Course or Company.

• Attribute: Properties that describes an entity such as StudentID, CourseName,

or EmployeeEmail.

• Relationship: A connection between entities such as "a Student enrolls in a Course".

The graphical representation of this model is called an Entity-Relation Diagram (ERD).

ER Model in Database Design Process

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.

• Create 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.

• After this, focus on Physical Database Design (like indexing) and external design (like views)

Why Use ER Diagrams In DBMS?

• ER diagrams represent the E-R model in a database, making them easy to convert into
relations (tables).
 • These diagrams serve the purpose of real-world modeling of objects which makes them
intently useful.

• Unlike technical schemas, ER diagrams require no technical knowledge of the underlying

DBMS used.

• They visually model data and its relationships, making complex systems easier to
understand.

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, such as a student's

multiple phone numbers

• Double Rectangle: Represents weak entities, which depend on other entities for
identification.

What is an Entity?

An Entity represents a real-world object, concept or thing about which data is stored in a
database. It act as a building block of a database. Tables in relational database represent these
entities.

Example of entities:

• Real-World Objects: Person, Car, Employee etc.

• Concepts: Course, Event, Reservation etc.

 • Things: Product, Document, Device etc.

The entity type defines the structure of an entity, while individual instances of that type represent
specific entities.

What is an Entity Set?

An entity refers to an individual object of an entity type, and the collection of all entities of a
particular type is called an entity set. For example, E1 is an entity that belongs to the entity type
"Student," and the group of all students forms the entity set.

We can represent the entity sets in an ER Diagram but we can't represent individual entities
because an entity is like a row in a table, and an ER diagram shows the structure and relationships
of data, not specific data entries (like rows and columns). An ER diagram is a visual representation
of the data model, not the actual data itself.
Types of Entity

There are two main types of entities:

1. Strong Entity

A Strong Entity is a type of entity that has a key Attribute that can uniquely identify each instance
of the entity. A Strong Entity does not depend on any other Entity in the Schema for its
identification. It has a primary key that ensures its uniqueness and is represented by a rectangle
in an ER diagram.

2. Weak Entity

A Weak Entity cannot be uniquely identified by its own attributes alone. It depends on a strong
entity to be identified. A weak entity is associated with an identifying entity (strong entity), which
helps in its identification. A weak entity are represented by a double rectangle. The participation
of weak entity types is always total. The relationship between the weak entity type and its
identifying strong entity type is called identifying relationship and it is represented by a double
diamond.

Example:

A company may store the information of dependents (Parents, Children, Spouse) of an Employee.
But the dependents can't exist without the employee. So dependent will be a Weak Entity Type
and Employee will be identifying entity type for dependent, which means it is Strong Entity Type.
Attributes in ER Model

Attributes are the properties that define the entity type. For example, for a Student entity Roll_No,
Name, DOB, Age, Address, and Mobile_No are the attributes that define entity type Student. In
ER diagram, the attribute is represented by an oval.

Types of Attributes

1. Key Attribute

The attribute which uniquely identifies each entity in the entity set is called the key attribute. For
example, Roll_No will be unique for each student. In ER diagram, the key attribute is represented
by an oval with an underline.

2. Composite Attribute

An attribute composed of many other attributes is called a composite attribute. For example, the
Address attribute of the student Entity type consists of Street, City, State, and Country. In ER
diagram, the composite attribute is represented by an oval comprising of ovals.
3. Multivalued Attribute

An attribute consisting of more than one value for a given entity. For example, Phone_No (can be
more than one for a given student). In ER diagram, a multivalued attribute is represented by a
double oval.

4. Derived Attribute

An attribute that can be derived from other attributes of the entity type is known as a derived
attribute. e.g.; Age (can be derived from DOB). In ER diagram, the derived attribute is represented
by a dashed oval.

The Complete Entity Type Student with its Attributes can be represented as:
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.

Degree of a Relationship Set

The number of different entity sets participating in a relationship set is called the degree of a
relationship set.

1. Unary/Recursive Relationship: When there is only ONE entity set participating in

a relation, the relationship is called a unary relationship. For example, one person
is married to only one person.
 2. Binary Relationship: When there are TWO entities set participating in a
relationship, the relationship is called a binary relationship. For example, a Student
is enrolled in a Course.
3. Ternary Relationship: When there are three entity sets participating in a
relationship, the relationship is called a ternary relationship.
4. N-ary Relationship: When there are n entities set participating in a relationship,
the relationship is called an n-ary relationship.

Cardinality in ER Model
The maximum number of times an entity of an entity set participates in a relationship set is
known as cardinality.
Cardinality can be of different types:
1. One-to-One
When each entity in each entity set can take part only once in the relationship, the cardinality
is one-to-one. Let us assume that a male can marry one female and a female can marry one
male. So the relationship will be one-to-one.
2. One-to-Many

In one-to-many mapping as well where each entity can be related to more than one entity. Let us
assume that one surgeon department can accommodate many doctors. So the Cardinality will be
1 to M. It means one department has many Doctors.

3. Many-to-One

When entities in one entity set can take part only once in the relationship set and entities in other
entity sets can take part more than once in the relationship set, cardinality is many to one. Let us
assume that a student can take only one course but one course can be taken by many students.
So the cardinality will be n to 1. It means that for one course there can be n students but for one
student, there will be only one course.
[Link]-to-Many
When entities in all entity sets can take part more than once in the relationship cardinality is
many to many. Let us assume that a student can take more than one course and one course can
be taken by many students. So the relationship will be many to many.

Participation Constraint

Participation Constraint is applied to the entity participating in the relationship set.

1. Total Participation: Each entity in the entity set must participate in the relationship. If each
student must enroll in a course, the participation of students will be total. Total participation is
shown by a double line in the ER diagram.

2. Partial Participation: The entity in the entity set may or may NOT participate in the relationship.
If some courses are not enrolled by any of the students, the participation in the course will be
partial.

The diagram depicts the ‘Enrolled in’ relationship set with Student Entity set having total
participation and Course Entity set having partial participation.
Every student in the Student Entity set participates in a relationship but there exists a course C4
that is not taking part in the relationship.

How to Draw an ER Diagram

1. Identify Entities: The very first step is to identify all the Entities. Represent these entities in a
Rectangle and label them accordingly.

2. Identify Relationships: The next step is to identify the relationship between them and represent
them accordingly using the Diamond shape. Ensure that relationships are not directly connected
to each other.

3. Add Attributes: Attach attributes to the entities by using ovals. Each entity can have multiple
attributes (such as name, age, etc.), which are connected to the respective entity.

4. Define Primary Keys: Assign primary keys to each entity. These are unique identifiers that help
distinguish each instance of the entity. Represent them with underlined attributes.

5. Remove Redundancies: Review the diagram and eliminate unnecessary or repetitive entities
and relationships.

6. Review for Clarity: Review the diagram make sure it is clear and effectively conveys the
relationships between the entities.

Generalization, Specialization and Aggregation in ER Model

Using the ER model for bigger data creates a lot of complexity while designing a database model,
So in order to minimize the complexity Generalization, Specialization and Aggregation were
introduced in the ER model. These were used for data abstraction. In which an abstraction
mechanism is used to hide details of a set of objects.

Generalization

Generalization is the process of extracting common properties from a set of entities and creating
a generalized entity from it. It is a bottom-up approach in which two or more entities can be
generalized to a higher-level entity if they have some attributes in common.
Specialization

In specialization, an entity is divided into sub-entities based on its characteristics. It is a top-down

approach where the higher-level entity is specialized into two or more lower-level entities.

Inheritance

It is an important feature of generalization and specialization. In specialization, a higher-level

entity is divided into lower-level sub-entities that inherit its attributes. In generalization, similar
lower-level entities are combined into a higher-level entity that holds common attributes. In both
cases, inheritance allows sub-entities to reuse the properties of the parent entity.

1. Attribute inheritance: It allows lower level entities to inherit the attributes of higher level
entities and vice versa. In diagram Car entity is an inheritance of Vehicle entity ,So Car can
acquire attributes of Vehicle. Example: Car can acquire Model attribute of Vehicle.

2. Relationship Inheritance: Sub-entities also inherit relationships of the parent entity.

3. Overriding Inheritance: Sub-entities can override or add their own attributes or behaviors
different from the parent.

4. Participation inheritance: Participation inheritance in ER modeling refers to the

inheritance of participation constraints from a higher-level entity (superclass) to a lower-
level entity (subclass). It ensures that subclasses adhere to the same participation rules in
relationships, although attributes and relationships themselves are inherited differently.

Aggregation

An ER diagram is not capable of representing the relationship between an entity and a

relationship which may be required in some scenarios. In those cases, a relationship with its
corresponding entities is aggregated into a higher-level entity. Aggregation is an abstraction
through which we can represent relationships as higher-level entity sets.
Relational Model in DBMS

The Relational Model organizes data using tables (relations) consisting of rows and columns.

• The relational model represents how data is stored and managed in Relational Databases
where data is organized into tables, each known as a relation.

• Each row of a table represents an entity or record and each column represents a particular
attribute of that entity.

• The relational model transforms conceptual designs from ER diagrams into implementable
structures. These structures are used in relational database systems like Oracle SQL and
MySQL.

Key Terms in the Relational Model

1. Attribute: Attributes are the properties that define an entity. For example, ROLL_NO,
NAME, ADDRESS etc.

2. Relation Schema: A relation schema defines the structure of the relation and represents
the name of the relation with its attributes. For example, STUDENT (ROLL_NO, NAME,
ADDRESS, PHONE and AGE) is the relation schema for STUDENT. If a schema has more than
1 relation it is called Relational Schema.

3. Tuple: A Tuple represents a row in a relation. Each tuple contains a set of attribute values
that describe a particular entity. For example, (1, RAM, DELHI, 9455123451, 18) is a tuple
in the STUDENT table.

4. Relation Instance: The set of tuples of a relation at a particular instance of time is called a
relation instance. It can change whenever there is an insertion, deletion or update in the
database.

5. Degree: The number of attributes in the relation is known as the degree of the relation.
For example, The STUDENT relation has a degree of 5, as it has 5 attributes.
 6. Cardinality: The number of tuples in a relation is known as cardinality. For example, The
STUDENT relation defined above has cardinality 4.

7. NULL Values: The value which is not known or unavailable is called a NULL value. It is
represented by NULL. For example, PHONE of STUDENT having ROLL_NO 4 is NULL.

Types of Keys in the Relational Model

1. Primary Key: A Primary Key uniquely identifies each tuple in a relation. It must contain
unique values and cannot have NULL values.

2. Candidate Key: A Candidate Key is a set of attributes that can uniquely identify a tuple in
a relation.

3. Super Key: A Super Key is a set of attributes that can uniquely identify a tuple.

4. Foreign Key: A Foreign Key is an attribute in one relation that refers to the primary key of
another relation.

5. Composite Key: A Composite Key is formed by combining two or more attributes to

uniquely identify a tuple.

Relational Model Notation

• Relation schema R of degree n is denoted by by R(A1, A2, ...,An).

• Uppercase letters Q, R, S denote relation names.

• Lowercase letters q, r, s denote relation states.

• Letters t, u, v denote tuples.

• In general, the name of a relation schema such as STUDENT also indicates the current set
of tuples in that relation.

• An attribute A can be qualified with the relation name R to which it belongs by using the
dot notation R.A for example, [Link] or [Link].
 • An n-tuple t in a relation r(R) is represented as t = <v1, v2,..., vn> where vi is the value
corresponding to the attribute Ai. The value vi for attribute Ai in tuple t can be accessed
using t[Ai] or [Link].

Characteristics of the Relational Model

• Data Representation: Data is organized in tables (relations), with rows (tuples)

representing records and columns (attributes) representing data fields.

• Atomic Values: Each attribute in a table contains atomic values, meaning no multi-valued
or nested data is allowed in a single cell.

• Unique Keys: Every table has a primary key to uniquely identify each record, ensuring no
duplicate rows.

• Attribute Domain: Each attribute has a defined domain, specifying the valid data types
and constraints for the values it can hold.

• Data Independence: The model ensures logical and physical data independence, allowing
changes in the database schema without affecting the application layer.

• Relational Operations: Supports operations like selection, projection, join, union and
intersection, enabling powerful data retrieval manipulation.

• Data Consistency: Ensures data consistency through constraints, reducing redundancy

and anomalies.

• Set-Based Representation: Tables in the relational model are treated as sets and
operations follow mathematical set theory principles.

Keys in Relational Model

In the context of a relational database, keys are one of the basic requirements of a relational
database model.
 • Keys are fundamental components that ensure data integrity, uniqueness and efficient
access. It is widely used to identify the tuples(rows) uniquely in the table.

• We also use keys to set up relations amongst various columns and tables of a relational
database.

Why do we require Keys in a DBMS?

Keys are important in a Database Management System (DBMS) for several reasons:

• Uniqueness: Keys ensure that each record in a table is unique and can be identified
distinctly.

• Data Integrity: Keys prevent data duplication and maintain the consistency of the data.

• Efficient Data Retrieval: By defining relationships between tables, keys enable faster
querying and better data organization. Without keys, it would be extremely difficult to
manage large datasets and queries would become inefficient and prone to errors.

Types of Database Keys

1. Super Key: A super key is a group of single or multiple keys that uniquely identifies rows in
a table. It supports NULL values in rows.
2. A candidate key is a minimal super key, meaning it can uniquely identify a record but
contains no extra attributes.

3. 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.
4. Alternate key is also referred to as a secondary key because it can uniquely identify records
in a table, just like the primary key.
5. A foreign key in one table points to the primary key in another table, establishing a
relationship between them.
6. Composite Key: Sometimes, a table might not have a single column/attribute that uniquely
identifies all the records of a table. To uniquely identify rows of a table, a combination of
two or more columns/attributes can be used. It still can give duplicate values in rare cases.
So, we need to find the optimal set of attributes that can uniquely identify rows in a table.