0% found this document useful (0 votes)
66 views43 pages

DBMS

Uploaded by

SRIHARI HARAN D
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
66 views43 pages

DBMS

Uploaded by

SRIHARI HARAN D
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 43

DBMS

What is DBMS?

A Database Management System (DBMS) is a software system that is designed to manage


and organize data in a structured manner. It allows users to create, modify, and query a
database, as well as manage the security and access controls for that database. DBMS
provides an environment to store and retrieve data in convenient and efficient manner

File System (FS) vs Database Management System (DBMS)

A File System (FS) is used for storing and organizing files in a hierarchical structure, providing
basic file operations with limited features for complex data management. In contrast, a
Database Management System (DBMS) manages structured data, offering powerful querying,
data integrity, and concurrency control for large-scale, complex applications.

Tuple vs Record

Aspect Tuple Record

Definition A tuple is a single row in a A record is a single,


table in a relational logically related collection
database. of data.

Usage Context Used in the context of Commonly used in


relational databases. programming (e.g., objects
or structs).

Structure Represents a set of Represents a complete unit


attribute values (fields) in a of meaningful information.
row.

Data Type May include varied data Similar to a tuple but


types as attributes (e.g., emphasizes logical
string, int). grouping.

Examples A row in a table: (101, A record in an object: {ID:


'Alice', 25) 101, Name: 'Alice', Age: 25}

DBMS Architecture
DBMS architecture defines the framework for how the database is designed, used, and
managed. It is categorized into 1-Tier, 2-Tier, and 3-Tier architectures.

Aspect 1-Tier Architecture 2-Tier Architecture 3-Tier Architecture

Definition Direct interaction Client interacts Introduces a


with the database. with the database middleware layer
via a server. between client and
database.

Components User interacts Client (application) Client, application


directly with DBMS. and database server
server. (middleware), and
database.

Usage Used for local, Suitable for small Ideal for large-
personal applications. scale, enterprise
databases. applications.

Data Processing Performed directly Limited processing Middleware


on the user’s on client; rest on handles processing;
machine. server. reduces client-
server dependency.

Examples MS Access, SQLite. MySQL with a Web-based


client-side systems using
application. MySQL, Oracle.

Diagram for 3-Tier Architecture:

1. Client Layer: User interfaces or applications like web browsers.


2. Application Layer: Middleware to process business logic (e.g., APIs, frameworks).
3. Database Layer: Backend database for storage and retrieval.

This layered approach enhances security, scalability, and modularity in enterprise


applications.

Why is the Need for 3-Tier Architecture?


The 3-tier architecture addresses the limitations of simpler architectures by enhancing
scalability, security, and maintenance. It separates responsibilities into layers, ensuring
flexibility and robustness in application design.

Key Reasons:

1. Scalability: Allows each layer (client, application, database) to scale independently.


2. Maintainability: Changes in one layer (e.g., UI redesign or database migration) don't
impact others.
3. Security: The application server acts as a gatekeeper, preventing direct client access to
the database.
4. Reusability: Middleware logic can be reused across multiple applications.
5. Fault Tolerance: Failure in one layer does not compromise the entire system.

How 3-Tier Architecture Works

The 3-tier architecture divides the application into three distinct layers:

1. Presentation Layer (Client Layer):

Role: Handles user interaction (UI/UX).


Components: Web browsers, mobile apps, desktop applications.
Examples: Login pages, dashboards.
Function: Sends user requests to the application server and displays results.

2. Application Layer (Middleware):

Role: Contains business logic and processes requests.


Components: APIs, web servers, frameworks.
Examples: Node.js, Django, Spring.
Function:
Receives client requests.
Processes data using logic.
Sends structured queries to the database layer.
Returns processed results to the client layer.

3. Database Layer:

Role: Manages and stores data.


Components: DBMS like MySQL, Oracle, MongoDB.
Examples: User details, product catalogs.
Function: Executes queries, updates records, and retrieves requested data for the
application layer.

Flow Example (E-commerce Application):

1. Client Layer: User searches for a product via a web browser.


2. Application Layer: Middleware processes the query, validates it, and constructs a SQL
query for the database.
3. Database Layer: Executes the SQL query, retrieves product details, and sends them back
to the middleware.
4. Middleware: Formats the response into JSON and sends it to the browser.
5. Client Layer: Displays the product list to the user.

This separation ensures seamless performance, even for complex systems with many
simultaneous users.

Uses of DBMS

A Database Management System (DBMS) addresses the limitations of traditional file


management systems and provides efficient, secure, and organized data storage. Here are the
key uses and reasons for adopting DBMS:

1. Data Retrieval

Problem: Traditional file systems require custom programs in high-level languages for
data storage and retrieval, which is time-consuming.
DBMS Solution: Facilitates fast and secure data retrieval using query languages like SQL.
Example: Execute an SQL query (SELECT * FROM Employees WHERE Department='IT';) to
retrieve specific employee details.

2. Data Redundancy

Problem: Traditional systems often store duplicate data, leading to data inconsistency
when updates fail to propagate to all copies.
DBMS Solution: Reduces redundancy through normalization and maintains consistency
using ACID properties (Atomicity, Consistency, Isolation, Durability).
Example: A database transaction ensures that updating an employee's address is
consistently reflected in all associated records.

3. Data Integrity

Problem: Ensuring correctness and validity of data in flat files is challenging.


DBMS Solution: Enforces integrity constraints like Primary Key, Foreign Key, and Unique
constraints to validate data before entry.
Example: Prevents duplicate entries for a customer by using a unique customer ID.

4. Data Security

Problem: Traditional file systems lack robust authentication mechanisms.


DBMS Solution: Offers multi-level security (e.g., user-level, admin-level) and access
control to protect sensitive data.
Example: Only administrators can modify salary data, while general users have read-only
access.
5. Data Indexing

Problem: Flat files lack indexing, leading to slow data retrieval.


DBMS Solution: Uses indexing mechanisms to uniquely identify and store data for fast
retrieval.
Example: A B-Tree index improves query performance when searching for a specific
product in a database.

Summary of Benefits

1. Efficient storage and retrieval of large datasets.


2. Eliminates redundancy and inconsistency through rules like normalization.
3. Enhances security and integrity with constraints and user-level authentication.
4. Improves scalability and indexing, making the system suitable for large-scale
applications.

DBMS transforms how organizations store, manage, and use data, providing a robust
foundation for modern applications.

Data Abstraction and Data Independence in DBMS

Data Abstraction

Data abstraction refers to the process of hiding complex details from users to enhance
security and simplify interaction with the database. It allows different levels of access
depending on the user's role.

Levels of Data Abstraction:


Level Description Example

Conceptual Level - Describes the logical Example: CREATE TABLE


structure of the database. - emp (id NUM(5) PRIMARY
Specifies data types, KEY, name VARCHAR(10));
constraints, and Logical structure includes
relationships. fields, data types, keys, and
relationships.

External Level - Defines the user’s view of A user accessing only their
the database.- Ensures bank account details, but
security by restricting not internal operational
access to certain parts of data.
the database.

Internal Level - Specifies how data is Managing physical storage


physically stored in the with indexes like B-trees for
database.- Handles efficient retrieval.
indexing, clustering, and
storage mechanisms.

Data Independence

Data independence ensures that changes made at one level of the database architecture do
not affect the other levels, enhancing system flexibility and maintainability.

Type Description Example

Logical Data Independence Changes at the conceptual Adding a new field (e.g.,
level do not affect the email) in the emp table
external level and vice- should not affect existing
versa. views used by end-users.

Physical Data Changes at the internal Changing the storage


Independence level do not affect the format or adding indexes
conceptual level and vice- for performance
versa. optimization does not
impact the logical table
structure.
Importance of Data Abstraction and Independence

1. Simplified Interaction: Users interact with the database without worrying about complex
physical storage details.
2. Security: Restricts access to sensitive data at specific levels.
3. Flexibility: Allows system upgrades and modifications without disrupting user
interaction.
4. Maintainability: Reduces interdependencies, making the database easier to manage.

This abstraction ensures efficient handling of large, complex datasets while providing a user-
friendly interface.

Definitions of DBMS Database Models

1. Flat File DBMS

A flat file DBMS stores data sequentially in a single, large, plain text or binary file without any
structured relationships between the data items. Retrieval of data involves searching linearly,
making it slow and inefficient.

2. Relational DBMS (RDBMS)

A relational DBMS organizes data in a table-based structure where rows (tuples) represent
records, and columns (attributes) represent data fields. Relationships between tables are
maintained using keys (e.g., primary and foreign keys).

3. Hierarchical DBMS

A hierarchical DBMS stores data in a tree-like structure with parent-child relationships. Each
child record has only one parent, and the data is organized in a top-down manner, suitable for
hierarchical data storage.

4. Network DBMS

A network DBMS is a data model that organizes data in a graph structure, allowing many-to-
many relationships between parent and child records. It uses pointers to connect records,
providing flexibility in linking data.

5. Object-Relational DBMS (ORDBMS)

An object-relational DBMS combines the features of relational databases with object-


oriented principles such as classes, objects, and inheritance. It supports advanced data types
and operations for enhanced functionality.

Types of Data Models in DBMS


Data models define how data is logically structured, stored, and managed in a database. Here
are the primary types of data models, along with a detailed explanation:

1. Hierarchical Database Model

Structure: Resembles a tree-based structure. Data is organized in a hierarchy with a


single root node and connected child nodes.
Features:
Each child node has only one parent.
Parent nodes can have multiple children, forming a one-to-many relationship.
Advantages:
Fast data retrieval for hierarchical relationships.
Simplicity in implementation.
Drawbacks:
Inflexible structure; changes are difficult to handle.
Redundant data storage if multiple parent-child relationships exist.

2. Network Model

Structure: A graph-based model where data is stored in nodes and relationships are
represented as links.
Features:
Supports many-to-many relationships.
A child node can have multiple parent nodes.
Advantages:
Reduces data redundancy.
Efficient for complex relationships.
Drawbacks:
Complex to implement and maintain.
Requires high technical expertise.

3. Entity-Relationship (ER) Model

Structure: Based on entities, attributes, and relationships between entities.


Components:
Entity: Represents real-world objects (e.g., Student).
Attributes: Characteristics of entities (e.g., StudentID, Name).
Relationship: Logical connections between entities (One-to-One, One-to-Many, Many-
to-Many).
Use Case: ER models are used for designing databases logically before implementation.

4. Relational Model

Structure: Data is stored in two-dimensional tables (relations) consisting of rows and


columns.
Features:
Each table row represents a tuple (record).
Each column represents an attribute (field).
Tables are linked through keys (primary and foreign keys).
Advantages:
Easy to use and widely adopted (e.g., MySQL, PostgreSQL).
Supports normalization, reducing redundancy.
Secure and scalable.

5. Object-Oriented Database Model

Structure: Combines object-oriented programming concepts with database


management.
Features:
Data is represented as objects with attributes (properties) and methods (functions).
Supports inheritance, polymorphism, and encapsulation like OOP.
Advantages:
Ideal for complex applications like AI, machine learning, and image processing.
Models real-world scenarios effectively.
Drawbacks:
More complex to design and implement.
Limited adoption due to complexity.

6. Document Model

Structure: Stores data in document formats such as JSON, XML, or BSON.


Features:
Designed for semi-structured or unstructured data.
Commonly used in NoSQL databases (e.g., MongoDB).
Advantages:
Flexible schema.
Ideal for dynamic or evolving datasets.

7. Entity-Attribute-Value (EAV) Model

Structure: Represents data in a sparse matrix form, often used for medical or other
complex datasets.
Features:
Entity: Represents the object being described.
Attribute: Describes the property of the entity.
Value: The corresponding data value.
Advantages:
Handles sparse data efficiently.
Useful for systems requiring dynamic attributes.

8. Star Schema

Structure: Used in data warehousing. Consists of a central fact table connected to


multiple dimension tables.
Features:
Optimized for query performance in analytical systems.
Simplifies data aggregation.
Use Case: Business intelligence and data analytics.

Comparison Table

Data Model Key Features Use Cases Example

Hierarchical Model Tree-based, one-to- Organization IBM IMS


many relationships charts, XML storage

Network Model Graph-based, Complex Integrated Data


many-to-many applications with Store
relationships networked data

Entity-Relationship Based on entities, Database design ER Diagrams


Model attributes, and and schema
relationships development

Relational Model Tabular structure General-purpose MySQL,


with keys DBMS, web apps PostgreSQL

Object-Oriented OOP concepts like AI, machine ObjectDB, Oracle


Model inheritance and learning, real-time OODB
encapsulation systems

Document Model JSON/XML/BSON NoSQL databases, MongoDB


format dynamic datasets

EAV Model Sparse data, entity- Medical databases, Custom


attribute-value complex datasets implementations
format

Star Schema Fact table with Data warehousing, OLAP tools


dimensions analytics

Network Model in DBMS

Definition:

The Network Model is a type of database model where data is represented in a graph
structure. It uses nodes (records) and edges (relationships) to define connections between
data. Unlike the hierarchical model, the network model allows many-to-many relationships
between nodes, making it more flexible.

Features of the Network Model:

1. Graph-Based Structure:
Data is organized as records (nodes), and relationships between records are
represented as links (edges).
Example: A single student record can be linked to multiple course records, and each
course record can link to multiple student records.
2. Many-to-Many Relationships:
Supports relationships where a child can have multiple parents.
Example: A project can have multiple team members, and each member can work on
multiple projects.
3. Schema Representation:
Data is defined in terms of record types and set types.
A record type specifies the structure of records (like a table schema).
A set type defines the relationships between different record types.
4. Pointer-Based Access:
Uses pointers or links to navigate between records, enabling fast data traversal.
5. Data Integrity:
Ensures referential integrity by enforcing proper linkages between parent and child
nodes.

Advantages of the Network Model:

1. Flexibility:
Handles complex relationships with many-to-many connections better than the
hierarchical model.
2. Efficiency:
Pointer-based access makes retrieval operations faster.
3. Reduced Redundancy:
Minimizes data duplication by allowing shared relationships between nodes.

Disadvantages of the Network Model:

1. Complexity:
Designing and maintaining the network structure is difficult due to its complexity.
2. Navigation Dependency:
Requires knowledge of the database structure to traverse relationships effectively.
3. Less User-Friendly:
Querying is more technical and less intuitive compared to relational databases.

Example:

Imagine a university database with students, courses, and instructors.

Each student can enroll in multiple courses (many-to-many).


Each course is taught by one or more instructors (many-to-many).

Using a network model:

Nodes: Student, Course, Instructor.


Links: Student-Course (Enrollment), Course-Instructor (Teaching).

Schema Representation:

Record Types:
Student (StudentID, Name, Age)
Course (CourseID, Title, Credits)
Instructor (InstructorID, Name, Department)
Set Types:
Enrollment (Student ↔ Course)
Teaching (Course ↔ Instructor)

Comparison to Other Models:

Aspect Network Model Hierarchical Model Relational Model

Relationships Many-to-Many One-to-Many Many-to-Many

Structure Graph Tree Tables (Relations)

Navigation Pointer-based Top-down SQL-based queries

Complexity Moderate to High Moderate Low

The network model is largely replaced by relational models in modern systems but is still
used in legacy systems requiring complex relationships, such as CAD software or real-time
simulations.

Entity-Relationship Model (ER Model)

Definition:

The Entity-Relationship (ER) model is a high-level conceptual data model used to define the
structure of data by visually representing entities, their attributes, and the relationships
between them. It is primarily used during database design to organize and plan the database
structure.

Components of ER Model:
1. Entities:
Represents real-world objects or concepts.
An entity type defines a collection of similar entities.
Each entity has attributes that describe its properties.
Example: In a school database, Student and Course are entities.
2. Entity Types:
Strong Entity: Can exist independently. Example: Student.
Weak Entity: Depends on a strong entity for its existence. Example: Payment (depends
on Student).
3. Attributes:
Properties or characteristics of an entity or relationship.
Types of attributes:
Simple Attribute: Cannot be divided further (e.g., Age).
Composite Attribute: Can be divided further (e.g., Full Name → First Name + Last
Name).
Derived Attribute: Calculated from other attributes (e.g., Age from DOB).
Multivalued Attribute: Can have multiple values (e.g., Phone Numbers).
4. Relationships:
Logical associations between entities.
Defined by the degree(number of entities involved):
Unary (One Entity): An employee manages another employee.
Binary (Two Entities): A student enrolls in a course.
Ternary (Three Entities): A doctor prescribes medicine to a patient.
5. Cardinality:
Describes the number of relationships an entity can have.
One-to-One (1:1): One entity instance is related to one instance of another.
One-to-Many (1:N): One entity instance is related to many instances of another.
Many-to-Many (M:N): Many instances of one entity relate to many instances of
another.
6. Keys:
Used to uniquely identify an entity in a set.
Primary Key: A unique identifier (e.g., StudentID).
Foreign Key: An attribute in one entity that links to the primary key of another entity.

Diagram Representation:

Entity: Represented as a rectangle.


Attributes: Represented as ovals connected to their respective entities.
Relationships: Represented as diamonds connecting related entities.

Advantages of ER Model:

1. High-Level Design:
Provides a clear, conceptual view of data relationships, aiding developers and
stakeholders.
2. Easy to Understand:
Simplifies the database design process through visual diagrams.
3. Flexible:
Can model both simple and complex relationships.

Example:

For a Library Database:

Entities: Book, Member, Librarian.


Attributes:
Book: BookID, Title, Author.
Member: MemberID, Name, Address.
Librarian: LibrarianID, Name.
Relationships:
Member borrows Book.
Librarian manages Book.

Limitations of ER Model:

1. Static Representation:
Focuses on structure, not operations like data updates or queries.
2. Scalability:
Diagrams become complex for large systems with many entities and relationships.

Comparison to Relational Model:

Aspect ER Model Relational Model

Focus Conceptual Design Logical Implementation

Representation Entities and Relationships Tables and Tuples

Use Case Database Design Database Usage

The ER model is a critical step in database creation, enabling efficient transition from abstract
design to practical implementation.

Relational Model in DBMS

Definition:

The Relational Model is a database model that represents data in the form of tables
(relations). Each table consists of rows (tuples) and columns (attributes). This model is based
on mathematical set theory and predicate logic, providing a simple, systematic, and powerful
way to manage data.
Key Components:

1. Relation (Table):
A table with rows and columns where each row represents a record (tuple), and each
column represents an attribute.
Each table has a unique name in the database.
2. Tuple (Row):
A single record in a relation containing data for each attribute.
Example: A single row in a "Students" table with details like RollNo, Name, and Age.
3. Attribute (Column):
A characteristic or property of a relation.
Example: Columns like RollNo, Name, and Age in the "Students" table.
4. Domain:
The set of permissible values for an attribute.
Example: For an "Age" attribute, the domain might be positive integers.
5. Relation Schema:
Defines the structure of a relation, including its attributes and their data types.
Example: Students(RollNo: Integer, Name: String, Age: Integer).
6. Relation Instance:
A specific set of tuples in a relation at a given time.
Example: The actual rows present in the "Students" table.

Keys in the Relational Model:

1. Primary Key:
Uniquely identifies a tuple in a relation.
Example: RollNo in a "Students" table.
2. Candidate Key:
A set of attributes that can uniquely identify a tuple.
Example: Both RollNo and Email in a "Students" table might be candidate keys.
3. Foreign Key:
An attribute in one relation that references the primary key of another relation.
Example: A "CourseEnrollments" table has a StudentID that references the "Students"
table.

Features of the Relational Model:

1. Data Independence:
Changes in data structure do not affect data access.
2. Ease of Use:
Data is stored in simple, easy-to-understand tabular form.
3. Flexibility:
New data can be added without altering existing applications.
4. Data Integrity:
Integrity constraints (e.g., primary and foreign keys) ensure accurate and consistent
data.
Operations in the Relational Model:

1. Relational Algebra:
A procedural query language with operations like:
Selection (σ): Filters rows based on conditions.
Projection (π): Selects specific columns.
Join: Combines data from two or more relations.
2. Relational Calculus:
A declarative query language using logical predicates.
3. SQL (Structured Query Language):
Practical implementation of relational algebra and calculus for interacting with
relational databases.

Advantages of the Relational Model:

1. Simplicity:
Easy to understand and implement using tables.
2. Data Integrity:
Maintains consistency with constraints like primary and foreign keys.
3. Flexibility:
Adapts to changing requirements.
4. Scalability:
Efficiently handles large datasets.
5. Standardization:
Widely adopted query language (SQL) supports interoperability.

Disadvantages of the Relational Model:

1. Performance:
May not be as fast as hierarchical or network models for certain complex
relationships.
2. Storage:
Requires significant memory for large datasets.
3. Complexity for Advanced Use Cases:
Struggles with scenarios requiring object-oriented or unstructured data.

Example:

Students Table:
RollNo Name Age Department

101 Alice 20 Computer Science

102 Bob 22 Electronics

103 Charlie 21 Mechanical

Courses Table:

CourseID CourseName Instructor

CSE101 Data Structures Dr. Smith

ELE202 Digital Electronics Dr. Brown

MEC303 Thermodynamics Dr. Green

Relation Example: A "StudentEnrollments" table links the Students and Courses tables using
primary and foreign keys.

The Relational Model is the foundation of modern databases, offering a structured and
efficient way to manage and query data.

Object-Oriented Database Model

Definition:

The Object-Oriented Database Model (OODB) integrates the principles of object-oriented


programming (OOP) with database management systems. It stores data as objects, similar to
how OOP languages like Java, Python, or C++ define and manipulate objects. This model is
particularly suited for complex data types, such as multimedia, CAD/CAM, and real-world
modeling scenarios.

Entity-Relationship Diagram (ER Diagram) in DBMS

Definition:
An Entity-Relationship Diagram (ER Diagram) is a graphical representation of the logical
structure of a database. It illustrates the relationships between different entities, attributes,
and relationships within a database, helping to visualize its schema and structure.

Key Components of an ER Diagram:

1. Entities:
Definition: Real-world objects or concepts that have a distinct existence in the
database.
Representation: Represented as rectangles.
Examples:
Student, Teacher, Course, Department.
Entity Set: A collection of similar types of entities.
Example: All students in a university form the Student entity set.
2. Attributes:
Definition: Properties or characteristics of an entity.
Representation: Represented as ovals connected to the entity.
Types of Attributes:
Key Attribute: Uniquely identifies an entity (e.g., StudentID).
Representation: Underlined in the oval.
Composite Attribute: Composed of multiple sub-attributes (e.g., Address → Street,
City, Zip).
Representation: Connected ovals branching from the main attribute.
Multivalued Attribute: Can have multiple values (e.g., Phone Numbers).
Representation: Double ovals.
Derived Attribute: Can be calculated from other attributes (e.g., Age from Date of
Birth).
Representation: Dashed oval.
3. Relationships:
Definition: Describes how two or more entities are associated with each other.
Representation: Represented as diamonds connected to the entities.
Types:
Unary: Relationship within the same entity (e.g., Employee supervises Employee).
Binary: Relationship between two entities (e.g., Student enrolled in Course).
n-ary: Relationship involving multiple entities (e.g., Project assigned to Employees
working for Departments).
4. Cardinality:
Describes the number of instances of an entity related to another entity.
Types:
One-to-One (1:1): A single instance of one entity is related to a single instance of
another.
Example: One husband has one wife.
One-to-Many (1:N): A single instance of one entity is related to multiple instances
of another.
Example: One teacher teaches multiple courses.
Many-to-Many (M:N): Multiple instances of one entity are related to multiple
instances of another.
Example: Students enroll in multiple courses, and each course has multiple
students.
5. Participation Constraint:
Total Participation: All instances of an entity participate in the relationship.
Representation: Double line connecting entity and relationship.
Partial Participation: Some instances of an entity may not participate in the
relationship.
Representation: Single line connecting entity and relationship.
6. Weak Entities:
Definition: Entities that do not have a primary key and depend on a strong entity for
identification.
Representation: Represented as double rectangles.
Weak Relationships: Connect weak entities to strong entities, represented as double
diamonds.
Example: Monthly installment depends on the Loan entity.

Examples of ER Diagram Relationships:

1. One-to-One:
A person has one passport.
2. One-to-Many:
A department has many employees.
3. Many-to-Many:
Students enroll in multiple courses, and each course is taken by multiple students.

Use of ER Diagrams in DBMS:

Designing database schemas.


Understanding relationships and dependencies.
Simplifying complex database structures.
Communicating the database design effectively.

The ER diagram serves as a foundation for converting logical schemas into relational schemas
in database development.

Attributes in DBMS

Attributes define the characteristics or properties of an entity in a database. They determine


what type of data will be stored in the database table and describe the details related to an
entity.

Example:

In a Student table, the attributes could include:

Student Name
Roll Number
Marks
Attendance

Each of these represents a property of the Student entity.

Types of Attributes in DBMS

1. Simple Attributes:
Definition: Attributes that cannot be broken down further into smaller parts.
Example:
Roll Number and Marks are simple attributes as they cannot be subdivided.
Representation: Oval in an ER diagram.
2. Composite Attributes:
Definition: Attributes that are composed of multiple sub-attributes.
Example:
Name can be divided into First Name and Last Name.
Address can be divided into Street, City, State, and Zip Code.
Representation: A main oval branching into smaller sub-ovals.
3. Single-Valued Attributes:
Definition: Attributes that can have only one value for a given entity.
Example:
Date of Birth for a student has a single value for each student.
Key Point: These attributes are deterministic, meaning they hold exactly one value for
each instance.
4. Multi-Valued Attributes:
Definition: Attributes that can have more than one value for a given entity.
Example:
Phone Numbers: A student may have multiple contact numbers.
Email IDs: A student can have multiple email addresses.
Representation: Double oval in an ER diagram.
5. Derived Attributes:
Definition: Attributes that can be calculated or derived from other existing attributes.
Example:
Age can be derived from the Date of Birth.
Total Marks can be calculated by summing up marks in individual subjects.
Representation: Dashed oval in an ER diagram.
6. Key Attributes:
Definition: Attributes that uniquely identify an entity in an entity set.
Example:
Roll Number is a key attribute in the Student entity because it uniquely identifies
each student.
Representation: Underlined in an ER diagram.

Summary Table of Attribute Types


Attribute Type Definition Example Representation in
ERD

Simple Cannot be divided Roll Number, Marks Oval


further.

Composite Composed of Name (First Name, Oval branching


multiple sub- Last Name), sub-ovals
attributes. Address

Single-Valued Takes only one Date of Birth, Oval


value for an entity. Nationality

Multi-Valued Takes multiple Phone Numbers, Double oval


values for an entity. Email IDs

Derived Calculated from Age (from DOB), Dashed oval


other attributes. Total Marks

Key Uniquely identifies Roll Number Underlined oval


an entity in the set.

Attributes in DBMS play a crucial role in defining the structure and functionality of a
database. Understanding their types ensures efficient design and implementation of
relational schemas.

Key Attribute in DBMS

Definition:

A key attribute is an attribute or a set of attributes that uniquely identifies a specific entity
within an entity set. It ensures that no two entities in the same set have the same value for
this attribute, making it essential for distinguishing records.

Key Points about Key Attributes:

1. Uniqueness: A key attribute must have a unique value for each entity in the entity set.
2. Mandatory: A key attribute cannot have a null value, as it is used to identify entities.
3. Primary Key: In relational databases, key attributes form the basis for Primary Keys.
4. Combination: If a single attribute cannot uniquely identify an entity, a combination of
attributes can be used, referred to as a composite key.
Examples:

Student Table:
Roll Number: A student’s roll number is a key attribute because no two students can
have the same roll number.
Student ID: A unique ID assigned to each student can also act as a key attribute.
Employee Table:
Employee ID: Identifies employees uniquely.
Email ID: If unique, it can serve as a key attribute.

Representation in ER Diagrams:

In Entity-Relationship (ER) diagrams, a key attribute is denoted by an oval with an underline.

Key Attribute in Action:

Student Table Example:

Roll Number Name Age Marks

101 Alice 20 85

102 Bob 21 90

103 Charlie 19 78

Here, Roll Number is the key attribute as it uniquely identifies each student.

Characteristics of Key Attributes:

1. Uniqueness: No two entities can have the same key attribute value.
2. Immutability: Ideally, the value of a key attribute should not change over time.
3. Minimality: It should be the smallest possible set of attributes that uniquely identify an
entity.

Types of Keys (Built on Key Attributes):

1. Primary Key: A key attribute or combination of attributes that uniquely identifies records
in a table.
2. Candidate Key: All possible key attributes that can uniquely identify records.
3. Alternate Key: Candidate keys that are not chosen as the primary key.
4. Composite Key: A combination of attributes acting as a key when a single attribute is
insufficient.
Key attributes form the foundation for defining relationships and maintaining the integrity of
data in a database.

Multivalued Attributes in DBMS

Definition:

A multivalued attribute is an attribute that can hold more than one value for a single entity in
an entity set. Unlike single-valued attributes, which store only one value per entity,
multivalued attributes allow entities to have multiple values for the same attribute.

Key Points about Multivalued Attributes:

1. Multiple Values: These attributes can store a set of values for a single entity.
2. Representation: In ER Diagrams, multivalued attributes are represented by double ovals.
3. Use Case: Useful when an entity has multiple pieces of data for a single attribute.

Examples:

Student Entity:
Phone Numbers: A student may have multiple contact numbers.
Email IDs: A student may use more than one email address.
Employee Entity:
Skills: An employee may possess multiple skills (e.g., Java, Python, SQL).
Projects: An employee may work on multiple projects simultaneously.

Representation in ER Diagrams:

Multivalued attributes are shown using a double ovalconnected to the entity.


Example: An entity Student may have a multivalued attribute Phone Numbers.

Examples of Multivalued Attributes in Tables:

1. Student Table Example:

Student ID Name Phone Numbers

101 Alice +1234567890, +9876543210

102 Bob +1112223334, +5556667778

Here, the attribute Phone Numbers is multivalued, storing multiple phone numbers for
each student.
2. Employee Table Example:

Employee ID Name Skills

E001 John Java, Python, SQL

E002 Emily React, Node.js

Here, the attribute Skills is multivalued as employees can have multiple skills.

Handling Multivalued Attributes in Relational Databases:

Relational databases do not directly support multivalued attributes. To implement them, a


separate table is often created to handle the multiple values. This avoids data redundancy
and ensures normalization.

Example:

For the Student entity with Phone Numbers, we can design two tables:

1. Student Table:

Student ID Name

101 Alice

102 Bob

1.
2. Phone Numbers Table:

Student ID Phone Number

101 +1234567890

101 +9876543210

102 +1112223334

102 +5556667778
1.

Key Considerations:

Normalization: Multivalued attributes often require separate tables for normalized


database design.
Constraints: May complicate data integrity and constraints, such as uniqueness.
Usage: Common in scenarios where multiple values are necessary, like contact details,
skills, or hobbies.

By properly handling multivalued attributes, database systems can effectively manage


complex relationships while maintaining consistency.

Derived Attribute in DBMS

Definition:

A derived attribute is an attribute in a database that is not directly stored in the database but
can be computed or derived from other stored attributes. These attributes save storage
space and are calculated whenever needed using existing data.

Key Characteristics of Derived Attributes:

1. Dependent on Other Attributes: Their values are computed using one or more other
attributes in the database.
2. Not Physically Stored: Derived attributes are typically not stored in the database to
avoid redundancy and inconsistency.
3. Dynamic Updates: Since they are computed at runtime, they always reflect the most up-
to-date values based on the source attributes.

Examples:

1. Age: Can be derived from the attribute Date of Birth (DOB) as:
2. Age=Current Date−DOB\text{Age} = \text{Current Date} - \text{DOB}
3. Total Salary: For an employee, the total salary can be derived as:
4. Total Salary=Basic Salary+Allowances−Deductions\text{Total Salary} = \text{Basic Salary}
+ \text{Allowances} - \text{Deductions}
5. Distance: For a vehicle database, distance traveled can be derived as:
6. Distance=Final Odometer Reading−Initial Odometer Reading\text{Distance} = \text{Final
Odometer Reading} - \text{Initial Odometer Reading}

Representation in ER Diagrams:

Derived attributes are represented by a dashed oval connected to the entity or relationship
to which they belong.

Example:
In a Student entity, Age can be derived from Date of Birth (DOB).

Examples of Derived Attributes in Tables:

Student Table Example:

Student ID Name DOB Age (Derived)

101 Alice 2005-05-20 19

102 Bob 2000-03-15 24

Here, Age is a derived attribute, calculated based on the DOB.

Employee Table Example:

Emp ID Basic Salary Allowances Deductions Total Salary


(Derived)

E001 30,000 5,000 2,000 33,000

E002 40,000 6,000 3,000 43,000

Here, Total Salary is derived based on the formula:

Total Salary=Basic Salary+Allowances−Deductions\text{Total Salary} = \text{Basic Salary} +


\text{Allowances} - \text{Deductions}

Benefits of Derived Attributes:

1. Space Efficiency: Reduces the need for storage as they are not physically stored.
2. Consistency: Eliminates the risk of data inconsistency as they are computed on demand.
3. Real-Time Values: Ensures that derived values are always up-to-date.

Challenges with Derived Attributes:

1. Computation Overhead: Frequent calculations can increase query execution time.


2. Dependency: Derived attributes depend on other attributes, which must be accurate for
correct calculations.

Use Cases:
E-Commerce: Calculating total order cost from individual item prices and quantities.
Finance: Calculating interest or EMI based on principal, rate, and tenure.
Logistics: Deriving delivery time based on dispatch and arrival times.

Derived attributes add flexibility and efficiency to database design, allowing systems to
compute data dynamically while minimizing storage redundancy.

Cardinality in DBMS

Definition:

Cardinality in DBMS refers to the number of elements in one entity set that are associated
with elements in another entity set through a relationship. It defines the degree of the
relationship between two entities in an Entity-Relationship (ER) model.

Types of Cardinality:

1. One-to-One (1:1):
Each entity in one set is related to only one entity in another set and vice versa.
Example:
A person can have only one passport and each passport belongs to one person.
Diagram Representation:
Person (1) ↔ (1) Passport
2. One-to-Many (1:N):
An entity in one set is related to multiple entities in another set, but entities in the
second set relate to only one entity in the first set.
Example:
A teacher teaches many students, but each student has only one teacher.
Diagram Representation:
Teacher (1) ↔ (N) Students
3. Many-to-One (M:1):
Many entities in one set are associated with one entity in another set, but entities in
the second set are related to only one entity in the first set.
Example:
Many employees work in one department, but each department has multiple
employees.
Diagram Representation:
Employees (M) ↔ (1) Department
4. Many-to-Many (M:N):
Many entities in one set are associated with many entities in another set.
Example:
Many students enroll in many courses, and each course can have many students.
Diagram Representation:
Students (M) ↔ (N) Courses

Examples of Cardinality:
Example 1: One-to-One

Person ID Passport Number

1 A12345

2 B67890

Example 2: One-to-Many

Teacher ID Student ID

T1 S1

T1 S2

T2 S3

Example 3: Many-to-Many

Student ID Course ID

S1 C1

S1 C2

S2 C1

S3 C3

Cardinality in ER Diagrams:

Cardinality is represented in ER diagrams using notations:

One-to-One (1:1): A straight line with "1" near both entities.


One-to-Many (1:N): A line with "1" near one entity and "N" near the other.
Many-to-Many (M:N): A line with "M" near one entity and "N" near the other.

Importance of Cardinality:

1. Defines Relationships: Helps understand how entities interact in a database.


2. Aids in Normalization: Ensures data is stored without redundancy.
3. Influences Database Design: Helps in deciding the structure and constraints of the
database.
4. Query Optimization: Assists in writing efficient queries by understanding relationships.

Real-World Use Cases:

E-commerce:
One customer can place many orders (1:N).
Each order can contain many products (M:N).
University Management:
One professor teaches many students (1:N).
Many students can enroll in many courses (M:N).

Cardinality is a cornerstone of database design, ensuring logical relationships and efficient


data handling.

Relationships in DBMS

In DBMS (Database Management System), relationships define how two or more entities are
related to each other. These relationships help organize data and define how tables interact
with each other.

Types of Relationships:

1. Unary Relationship (Recursive Relationship):


A unary relationship occurs when an entity is related to itself.
Example:
A person can be related to another person as a married to relationship.
Diagram Representation:
A single entity (Person) related to itself.
Person (married_to) Person
2. Binary Relationship:
A binary relationship occurs between two different entities.
Example:
A student enrolls in a course.
Diagram Representation:
Student (enrolls_in) Course
3. N-ary Relationship:
A relationship involving more than two entities is called an N-ary relationship.
Example:
A student enrolls in a course which is taught by a teacher.
Here, the relationship involves 3 entities: Student, Course, Teacher.
Diagram Representation:
Student (enrolls_in) Course (taught_by) Teacher

Types of Relationship Cardinalities:

1. One-to-One (1:1) Relationship:


Each entity in one set is related to one entity in another set.
Example:
A person can have only one passport, and a passport is assigned to only one
person.
Diagram Representation:
Person (1) ↔ (1) Passport
2. One-to-Many (1:N) Relationship:
An entity in one set is related to multiple entities in another set, but each entity in the
second set relates to only one entity in the first set.
Example:
A teacher teaches many students, but each student can have only one teacher.
Diagram Representation:
Teacher (1) ↔ (N) Students
3. Many-to-One (M:1) Relationship:
Multiple entities in one set are related to a single entity in another set.
Example:
Many employees work in one department, but each department can have many
employees.
Diagram Representation:
Employees (M) ↔ (1) Department
4. Many-to-Many (M:N) Relationship:
Multiple entities in one set are related to multiple entities in another set.
Example:
Many students enroll in many courses, and each course can have many students.
Diagram Representation:
Students (M) ↔ (N) Courses

Relationship Representation in ER Diagrams:

1. Unary (Recursive) Relationship:


Represented by a single entity and a self-referencing relationship.
Example:
Employee (supervises) Employee (Employee supervises another Employee)
2. Binary Relationship:
Represented by a diamond shape connecting two entities.
Example:
Student (enrolled_in) Course
3. N-ary Relationship:
Represented by a diamond shape connected to multiple entities.
Example:
Student (enrolled_in) Course (taught_by) Teacher
Cardinality Constraints in Relationships:

1. One-to-One (1:1):
Each instance in one entity is related to exactly one instance in another entity.
2. One-to-Many (1:N):
One instance in one entity is related to many instances in another entity.
3. Many-to-Many (M:N):
Many instances in one entity are related to many instances in another entity.

Real-World Examples of Relationships:

1. Library System:
Books and Authors:
One author can write many books, but each book can have one or more authors.
(Many-to-Many)
2. School System:
Students and Courses:
A student can enroll in many courses, and each course can have many students.
(Many-to-Many)
3. Employee System:
Employees and Departments:
One department has many employees, but each employee works in one
department. (One-to-Many)

Participation Constraints:

Total Participation: Every entity in an entity set must participate in the relationship.
Represented by a double linebetween the entity and the relationship.
Example: Every student must enroll in at least one course.
Partial Participation: Some entities may not participate in the relationship. Represented
by a single linebetween the entity and the relationship.
Example: Not all employees have to supervise another employee.

Importance of Relationships:

1. Data Integrity: Establishing relationships ensures the accuracy and consistency of data.
2. Query Optimization: Understanding the relationships helps optimize database queries.
3. Database Normalization: Relationships help in organizing the database efficiently,
reducing redundancy.
4. Real-world Modeling: Relationships mirror real-world interactions between entities.

Conclusion:

Understanding relationships in DBMS is essential for designing databases that are both
effective and efficient. They help in defining how tables interact, maintain data integrity, and
ensure that queries and operations are executed optimally.
Recursive Relationship in DBMS

A recursive relationship (also called a Unary Relationship) occurs when an entity is related to
itself within the same entity set. In simpler terms, an entity is related to other instances of
the same type of entity.

Characteristics of Recursive Relationship:

It involves only one entity set.


The relationship links an entity to itself, either directly or indirectly.
Recursive relationships are typically used when there is a hierarchical or self-referencing
structure.

Example of Recursive Relationship:

Example 1: Employee Hierarchy

Consider an Employee entity where an employee may supervise another employee. This
is a recursive relationship because an employee (entity) is related to another employee
(same entity set).
Relationship: Employee (supervises) Employee
Here, one employee supervises another employee.
The relationship type is "supervises", which links an employee to another employee.
Diagram Representation:
A single entity "Employee" is related to itself through the recursive relationship
"supervises."

In DBMS, generalization is the process of abstracting common attributes and relationships


from multiple entity types into a higher-level, generalized entity. It helps to simplify the
design by grouping entities that share common characteristics and behaviors into a more
general form, reducing redundancy.

Example of Generalization in DBMS:

Consider a scenario where we have two entities:

Employee
Manager

Both entities share some common attributes, such as name, address, and salary, but the
Manager entity has additional attributes like department. Instead of repeating the common
attributes in both entities, we can generalize them into a single entity called Person.

Steps:

1. Identify common attributes: Both Employee and Manager share attributes like name,
address, and salary.
2. Create a generalized entity: Create a higher-level entity, Person, to store the common
attributes.
3. Specialize further: Keep the specific attributes of Employee and Manager in their
respective sub-entities.

ER Diagram Example:

+--------------------+

| Person |

+--------------------+

| Name |

| Address |

| Salary |

+--------------------+

/ \

+-------------------+ +-------------------+

| Employee | | Manager |

+-------------------+ +-------------------+

| EmpID | | Dept |

| Position | | Reports |

+-------------------+ +-------------------+

Explanation:

Person is the generalized entity containing common attributes.


Employee and Manager are specialized entities, inheriting from Person.
Employee may have attributes like EmpID and Position, while Manager may have
attributes like Dept and Reports.

Advantages:

Reduces Redundancy: Common attributes are stored only once in the generalized entity.
Increases Maintainability: Changes to common attributes need to be made only in the
generalized entity, making it easier to maintain the database.
Improves Data Consistency: Shared attributes are handled in a single place, reducing
inconsistencies.

Specialization is the reverse of generalization in DBMS. It is the process of defining sub-


entities from a higher-level, generalized entity based on specific characteristics or attributes.
In other words, specialization allows the creation of more specific entity types (sub-entities)
from a general entity, where each sub-entity can have its own attributes that aren't shared
with the others.

Example of Specialization in DBMS:

Consider an entity called Employee. An employee could be a Full-Time Employee or a Part-


Time Employee. These two types of employees have different attributes (e.g., Full-Time
Employee may have a salary, while Part-Time Employee may have hourlyRate).

Steps:

1. Identify common attributes: All employees share attributes like name, address, and
employeeID.
2. Create specialized entities: Define sub-entities for the specific types of employees, such
as FullTimeEmployee and PartTimeEmployee, which will have additional, unique
attributes.
3. Use a relationship: The specialized entities are connected to the generalized Employee
entity, inheriting the common attributes.

ER Diagram Example:

+------------+

| Employee |

+------------+

| EmpID |

| Name |

| Address |

+------------+

/ \

+-----------------+ +------------------+

| FullTimeEmployee| | PartTimeEmployee |

+-----------------+ +------------------+
| Salary | | HourlyRate |

| Benefits | | WorkingHours |

+-----------------+ +------------------+

Explanation:

Employee is the generalized entity with shared attributes.


FullTimeEmployee and PartTimeEmployee are specialized entities with their own unique
attributes.
The specialization allows specific attributes to be added to each type without affecting
the general employee data.

Advantages:

Improved Organization: Specialization helps in organizing data by focusing on specific


attributes that apply only to certain entities.
Avoids Redundancy: The common attributes are stored in the parent entity, while the
specialized attributes are placed in the sub-entities, avoiding redundancy.
Flexibility: You can easily add new specialized entities if needed without altering the
overall structure of the database.

Disjoint vs. Overlapping Specialization:

Disjoint Specialization: A single entity can belong to only one of the sub-entities.
(Example: An employee can either be full-time or part-time, but not both).
Overlapping Specialization: A single entity can belong to more than one sub-entity.
(Example: A student can be both an undergraduate and a graduate).

Specialization in DBMS helps create more flexible and organized database structures tailored
to specific data requirements.

Aggregation in DBMS is an advanced modeling technique used in Entity-Relationship (ER)


diagrams to represent a relationship between a relationship and another entity. It is useful
when we need to express relationships involving more than two entities, particularly when
the relationship itself has attributes or needs to interact with another entity.

Definition:

Aggregation treats a relationship set as a higher-level entity that can participate in another
relationship. It is a "relationship within a relationship," allowing more complex interactions
between entities.

Example of Aggregation:

Scenario:
Consider a project management system where:

Project is assigned to an Employee.


The Manager oversees the assignment of employees to projects.

Here, the relationship between Project and Employee (called "Assigned") can itself be
associated with the Manager. This requires representing the Assigned relationship as a
higher-level entity to show the connection with the Manager.

ER Diagram:

+----------+ +----------+

| Project | | Employee |

+----------+ +----------+

\ /

\ /

\ "Assigned" /

\ +----------+/

\-->| Manager |

+----------+

Explanation:

1. Project and Employee are connected via the "Assigned" relationship.


2. "Assigned" itself is aggregated into a higher-level entity.
3. The Manager entity interacts with the "Assigned" relationship as a whole, overseeing the
project assignments.

Key Features:

Aggregation is used when the relationship itself has attributes or needs to participate in
another relationship.
It simplifies the ER diagram by representing complex relationships hierarchically.
Aggregation is different from composition (used in OOP), as it deals specifically with
relationships in a database context.

Advantages:

1. Handles Complexity: Allows modeling of complex real-world scenarios involving multiple


entities and relationships.
2. Modularity: Improves modularity and clarity in ER diagrams by breaking down complex
relationships.

Use Case:

Representing scenarios like projects assigned to employees and supervised by a


manager, courses taught by instructors with departments monitoring assignments, etc.

Aggregation is a powerful concept in database design that enhances the ability to model real-
world scenarios effectively.

A Relational Database Management System (RDBMS) is a type of database management


system that stores and manages data in a structured format using tables. These tables are
related to one another through keys (primary and foreign keys). RDBMS is based on the
principles of relational algebra and provides features such as data integrity, normalization,
and powerful querying capabilities using Structured Query Language (SQL).

Schema in DBMS

In DBMS, a schema defines the structure or organization of data in a database, specifically


how data is logically organized and related to one another. It outlines the design of the
database, including tables, relationships, attributes, and constraints.

The schema does not contain any data itself but rather provides the blueprint for how the
data is structured and how different tables are connected.

Types of Schema

1. Physical Schema:
Describes how data is stored in the database. It deals with the physical storage of data
(e.g., file systems, indexing).
2. Logical Schema:
Describes the logical view of the entire database, focusing on the tables, their
attributes, and the relationships between them.
3. View Schema:
Defines a virtual schema, which allows the user to interact with a subset or specific
view of the database data, often for security or efficiency purposes.

Example of a Schema:

A STUDENT relation can be represented as:

STUDENT (STUD_ID, NAME, PHONE, STATE, STUD_AGE)

Here:
STUDENT is the name of the relation (table).
STUD_ID, NAME, PHONE, STATE, and STUD_AGE are the attributes (columns) in the table.

Explanation of Schema Components:

STUD_ID: A unique identifier for each student. This could be a primary key in the table.
NAME: The student's name.
PHONE: The student's phone number.
STATE: The state where the student resides.
STUD_AGE: The student's age.

Schema Representation in the Table:

STUD_ID NAME PHONE STATE STUD_AGE

1 Alice 123-456-7890 California 20

2 Bob 987-654-3210 Texas 22

Conclusion

A schema serves as the structure that defines how the data is organized in a database,
providing a way to ensure that the data is logically aligned and accessible according to the
design specified. The schema is essential in setting up tables and relationships in a database
to meet the needs of the application.

Instance in DBMS

An instance in a DBMS (Database Management System) refers to the actual data stored in
the database at any given point in time. It is a snapshot of the content in the database,
corresponding to the state of the database at that particular moment. While the schema
defines the structure of the database (the blueprint), the instance represents the real-time
data that populates the database according to that structure.

Schema vs. Instance:

Schema: The schema defines the structure of the database (tables, columns,
relationships) without any actual data.
Instance: The instance refers to the actual data in the database at any particular point in
time. It is the "real-world" data that adheres to the structure defined by the schema.

In a Relational Database Management System (RDBMS), keys are used to uniquely identify
rows (records) in a table and to establish relationships between different tables. There are
several types of keys, each serving a different purpose in ensuring data integrity and
efficiency in relational databases. Here's an overview of all the important keys in RDBMS:

1. Primary Key (PK)

Definition: A primary key is a field (or a combination of fields) that uniquely identifies
each record in a table. No two rows can have the same primary key value.
Characteristics:
Uniqueness: Each value of the primary key must be unique.
Non-null: A primary key column cannot have a NULL value.
Example:
STUDENT (STUD_ID, NAME, PHONE)
Here,STUD_ID could be the primary key, as each student must have a unique ID.

2. Foreign Key (FK)

Definition: A foreign key is a field (or a set of fields) in a table that refers to the primary
key in another table. It establishes and enforces a link between the data in the two tables.
Characteristics:
It can accept NULL values (unless specified otherwise).
The values in the foreign key column should either match the primary key or be NULL.
Example:
COURSE (COURSE_ID, STUD_ID)
In this case,STUD_ID is a foreign key that refers to the primary key STUD_ID in the
STUDENT table.

3. Candidate Key

Definition: A candidate key is a field (or combination of fields) that can uniquely identify
a record in a table. Every table can have multiple candidate keys, and one of them is
selected as the primary key.
Characteristics:
A candidate key must be unique and non-null.
Any candidate key can become the primary key.
Example: In the STUDENT table, both STUD_ID and EMAIL could be candidate keys if both
fields can uniquely identify a student.

4. Alternate Key

Definition: An alternate key is any candidate key that is not chosen as the primary key.
Essentially, it is a candidate key that did not become the primary key.
Example: In the STUDENT table, if STUD_ID is the primary key, then EMAIL could be an
alternate key.

5. Composite Key

Definition: A composite key is a combination of two or more columns used together to


uniquely identify a record in a table. This is typically used when no single column can
uniquely identify records.
Example:
ENROLLMENT (STUD_ID, COURSE_ID)
In this case, neitherSTUD_ID nor COURSE_ID alone can uniquely identify an enrollment
record, but together, they form a composite key.

6. Superkey

Definition: A superkey is a set of one or more attributes that, when taken collectively, can
uniquely identify a record in a table. A superkey may include additional attributes that
are not necessary to uniquely identify the record.
Characteristics:
Every candidate key is a superkey, but not all superkeys are candidate keys.
Example: In the STUDENT table, {STUD_ID, EMAIL} is a superkey because both together
can uniquely identify a student, even though STUD_ID alone is enough.

7. Unique Key

Definition: A unique key is a column (or a set of columns) that ensures the uniqueness of
the values within that column(s). Unlike the primary key, a unique key can accept NULL
values (if allowed by the DBMS).
Characteristics:
Uniqueness: The values in the unique key column must be unique.
It can allow NULL values (depending on the DBMS).
Example: In the STUDENT table, EMAIL could be a unique key, ensuring that no two
students can have the same email address.

8. Natural Key

Definition: A natural key is a type of key that is derived from real-world data and is used
to uniquely identify records in a table.
Example: A student’s EMAIL address might be used as a natural key since it uniquely
identifies each student.

9. Surrogate Key

Definition: A surrogate key is an artificially created key, often an auto-incremented


integer, used to uniquely identify records in a table when no natural key exists or is
suitable.
Characteristics:
It has no business meaning.
It is usually system-generated.
Example: In the STUDENT table, a STUD_ID that auto-increments could serve as a
surrogate key.

10. Foreign Key Constraint


Definition: A foreign key constraint ensures that the values in the foreign key column
correspond to valid values in the referenced primary key column of another table. It
ensures referential integrity between tables.
Example: In the COURSE table, if STUD_ID is a foreign key referring to STUDENT(STUD_ID),
then the database will ensure that every STUD_ID in COURSE matches an existing
STUD_ID in STUDENT.

11. Primary Key vs. Unique Key

Primary Key:
Cannot have NULL values.
Each table can have only one primary key.
Unique Key:
Can have NULL values (except when explicitly restricted).
A table can have multiple unique keys.

Summary Table of Keys


Key Type Uniqueness Null Values Explanation

Primary Key Must be unique Cannot be NULL Uniquely identifies


a record in a table

Foreign Key References another Can be NULL Creates


table's key relationships
between tables

Candidate Key Can uniquely Cannot be NULL Any attribute that


identify a record can be a primary
key

Alternate Key Can uniquely Cannot be NULL A candidate key not


identify a record chosen as the
primary key

Composite Key Can uniquely Cannot be NULL Combination of


identify a record multiple attributes
to form a unique
key

Superkey Can uniquely Can be NULL A set of attributes


identify a record that can uniquely
identify a record

Unique Key Must be unique Can be NULL Ensures uniqueness


but allows NULL
values

Natural Key Can uniquely Cannot be NULL Based on real-


identify a record world data

Surrogate Key Must be unique Cannot be NULL Artificially


generated key,
often an auto-
increment integer
These keys help ensure data integrity, establish relationships, and enforce rules within a
relational database.

You might also like