DBMS
DBMS
What is 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
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.
Usage Used for local, Suitable for small Ideal for large-
personal applications. scale, enterprise
databases. applications.
Key Reasons:
The 3-tier architecture divides the application into three distinct layers:
3. Database Layer:
This separation ensures seamless performance, even for complex systems with many
simultaneous users.
Uses of 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
4. Data Security
Summary of Benefits
DBMS transforms how organizations store, manage, and use data, providing a robust
foundation for modern applications.
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.
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.
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.
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.
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.
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.
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.
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.
4. Relational Model
6. Document 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
Comparison Table
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.
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.
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.
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:
Schema Representation:
Record Types:
Student (StudentID, Name, Age)
Course (CourseID, Title, Credits)
Instructor (InstructorID, Name, Department)
Set Types:
Enrollment (Student ↔ Course)
Teaching (Course ↔ Instructor)
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.
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:
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:
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.
The ER model is a critical step in database creation, enabling efficient transition from abstract
design to practical implementation.
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.
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.
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.
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.
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
Courses Table:
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.
Definition:
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.
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.
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.
The ER diagram serves as a foundation for converting logical schemas into relational schemas
in database development.
Attributes in DBMS
Example:
Student Name
Roll Number
Marks
Attendance
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.
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.
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.
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:
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.
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.
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.
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.
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:
Here, the attribute Phone Numbers is multivalued, storing multiple phone numbers for
each student.
2. Employee Table Example:
Here, the attribute Skills is multivalued as employees can have multiple skills.
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:
101 +1234567890
101 +9876543210
102 +1112223334
102 +5556667778
1.
Key Considerations:
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.
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).
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.
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
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:
Importance of Cardinality:
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).
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. 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.
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.
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."
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:
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.
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:
Advantages:
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.
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:
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:
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:
Use Case:
Aggregation is a powerful concept in database design that enhances the ability to model real-
world scenarios effectively.
Schema in DBMS
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:
Here:
STUDENT is the name of the relation (table).
STUD_ID, NAME, PHONE, STATE, and STUD_AGE are the attributes (columns) in the table.
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.
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: 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:
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.
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
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
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.