BCA and Semester III
Database Management System (BCA27103)
Class: BCA27103
Academic Session: 2025-2026
Study Material
(DBMS- Module 2)
Contents
Contents................................................................................................................................................1
1. Introduction to Data Models.........................................................................................................3
1.1. What is a Data Model?...........................................................................................................3
1.2. Purpose of a Data Model.......................................................................................................3
1.3. Key Components of a Data Model.........................................................................................3
1.4. Types of Data Models............................................................................................................3
1.5. Why Use a Data Model?........................................................................................................4
1.6. Example Scenario...................................................................................................................4
2. Limitations of Flat-File Based Systems...........................................................................................4
2.1. What is a Flat-File System?....................................................................................................4
2.2. Example: Flat-File Representation.........................................................................................5
2.3. Why Flat-File Systems Become Problematic..........................................................................5
2.4. Comparison Table: Flat-File vs Database System...................................................................6
3. Hierarchical Data Model................................................................................................................6
3.1. What is a Hierarchical Data Model?.......................................................................................6
3.2. Structure Overview................................................................................................................7
3.3. Real-World Example..............................................................................................................7
3.4. Features of the Hierarchical Model.......................................................................................7
3.5. Advantages of Hierarchical Model.........................................................................................7
3.6. Limitations and Drawbacks....................................................................................................8
3.7. Hierarchical vs Relational Model...........................................................................................8
3.8. When to Use the Hierarchical Model.....................................................................................8
4. Network Data Model.....................................................................................................................8
4.1. What is a Network Data Model?............................................................................................8
4.2. Basic Structure and Terminology...........................................................................................9
4.3. Advantages of the Network Data Model...............................................................................9
4.4. Disadvantages and Limitations............................................................................................10
4.5. Network vs Hierarchical Model............................................................................................10
4.6. Where the Network Model is Used.....................................................................................10
BCA and Semester III
Database Management System (BCA27103)
Class: BCA27103
Academic Session: 2025-2026
5. Entity-Relationship (ER) Model....................................................................................................11
5.1. What is the ER Model?.........................................................................................................11
5.2. Basic Components of the ER Model.....................................................................................11
5.2.1. Entities.........................................................................................................................11
5.2.2. Attributes.....................................................................................................................11
5.2.3. Relationships................................................................................................................11
5.2.4. ER Diagram Notations..................................................................................................12
5.3. Weak Entities and Identifying Relationships........................................................................12
5.4. Generalization, Specialization, and Aggregation..................................................................13
5.5. Advantages of ER Model......................................................................................................13
5.6. Limitations of ER Model.......................................................................................................13
6. Object-Oriented Data Model (OODM).........................................................................................13
6.1. Core Concepts of the Object-Oriented Model.....................................................................14
6.2. Structure of an Object-Oriented Database..........................................................................14
6.3. Example – University Database (Object-Oriented)..............................................................15
6.4. Comparison with Relational Model......................................................................................15
6.5. Advantages of OODM..........................................................................................................15
6.6. Limitations of OODM...........................................................................................................16
BCA and Semester III
Database Management System (BCA27103)
Class: BCA27103
Academic Session: 2025-2026
1. Introduction to Data Models
1.1. What is a Data Model?
A data model is a method of defining how data is logically connected, how it can be stored,
and how it can be accessed. It provides a blueprint for designing a database—describing
how data is structured, what relationships exist among data elements, and what constraints
apply to them.
Think of a data model like an architect’s plan. Just as a building plan shows where rooms,
doors, and windows should go, a data model shows what entities, attributes, and
relationships exist in a system.
1.2. Purpose of a Data Model
● To represent real-world objects like students, courses, products, and customers in a
structured format.
● To define relationships between these objects (e.g., a student enrolls in a course).
● To specify rules for storing, retrieving, and validating the data.
1.3. Key Components of a Data Model
Compone
Description Example
nt
A real-world object or concept with an
Entity Student, Book, Employee
independent existence.
Attribute A property or characteristic of an entity. Name, Age, Email
Relationsh An association between two or more
A student enrolls in a course
ip entities.
Constraint Rules that define valid data and Age must be > 0, Student ID
s relationships. must be unique
1.4. Types of Data Models
Data models are broadly categorized into three levels, as per ANSI/SPARC architecture:
1. Conceptual Data Model
o High-level, abstract view of data.
o Focuses on what data is required and how different data elements relate.
o Example: Entity-Relationship (ER) model.
2. Logical Data Model
BCA and Semester III
Database Management System (BCA27103)
Class: BCA27103
Academic Session: 2025-2026
o More detailed than conceptual.
o Describes how data is logically stored in a database system (tables, keys,
relationships).
o Example: Relational model.
3. Physical Data Model
o Describes how data is actually stored in memory or on disk.
o Involves indexes, partitions, file structures, and hardware specifics.
Figure 1: Data Model Types
1.5. Why Use a Data Model?
Using a data model offers numerous benefits, especially in large, structured databases:
● Improves communication among stakeholders (developers, designers, users).
● Ensures consistency and integrity in how data is defined and used.
● Aids in database design, helping in translating user requirements into actual database
structures.
● Simplifies querying and maintenance, as relationships and constraints are
predefined.
1.6. Example Scenario
Imagine you're designing a library management system. Without a data model, each
developer might design their own structure: one may use a table for “Books” with authors
embedded in a text field, another may use a separate table for authors.
With a data model, you’d define:
● An Entity: Book (Attributes: ISBN, Title, Publisher)
BCA and Semester III
Database Management System (BCA27103)
Class: BCA27103
Academic Session: 2025-2026
● An Entity: Author (Attributes: Author_ID, Name)
● A Relationship: "Author writes Book" (Many-to-Many)
● Constraints: ISBN must be unique; Author name must not be null
This model gives clarity before the actual implementation begins.
2. Limitations of Flat-File Based Systems
2.1. What is a Flat-File System?
A flat-file system is the simplest form of data storage. It stores data in plain text or binary
files, where each line represents a single record and fields are separated by commas, tabs, or
fixed widths. A spreadsheet (like Excel) or a .csv file is a good example of a flat-file system.
There is no structural relationship between different files in this approach. Each file stands
alone, and it’s up to the application or developer to manually link and manage the data.
2.2. Example: Flat-File Representation
Suppose we maintain a student-course enrollment record using a .csv file:
StudentID, Name, Course, Instructor
1001, Alice, DBMS, Prof. Sen
1001, Alice, Java, Prof. Das
1002, Bob, DBMS, Prof. Sen
Notice how Alice’s name is repeated for every course. This redundancy is the start of the problem.
2.3. Why Flat-File Systems Become Problematic
Flat-file systems seem simple, but they do not scale well. As data grows, the problems
multiply. Here’s a breakdown of the major issues:
1. Data Redundancy
Flat files often require the same data to be repeated multiple times. For example, if a student
enrolls in three courses, their name and ID are repeated thrice.
● Result: Wasted storage and increased chances of inconsistency.
● Example: If Alice's email changes, it must be updated in all rows where she appears.
2. Data Inconsistency
Redundancy naturally leads to inconsistency. When the same data exists in multiple places,
keeping them synchronized is difficult.
BCA and Semester III
Database Management System (BCA27103)
Class: BCA27103
Academic Session: 2025-2026
● Example: Alice has alice@[Link] in one row and alice@[Link] in another
— which one is correct?
3. Poor Data Integrity and Accuracy
There are no rules (constraints) to enforce valid data entry. Flat files can accept any data
without validation.
● Example: A negative age or an invalid date of birth might go unnoticed.
4. Lack of Relationships
Flat files do not support data relationships such as one-to-many or many-to-many.
● Example: There’s no concept of foreign keys or joins.
● It’s hard to associate students with multiple courses or a department.
5. Inefficient Data Access
Searching for data in a flat file often involves linear scanning of the entire file. Queries like
“Find all students in DBMS” are inefficient and slow with large datasets.
6. No Concurrent Access or Transaction Support
Multiple users cannot safely access or update the data at the same time. There’s no built-in
locking, versioning, or rollback mechanism in flat files.
7. Difficult Maintenance
As the number of records grows, managing files becomes complicated. Adding new fields or
changing the structure requires manual updates to every file and application logic.
2.4. Comparison Table: Flat-File vs Database System
Database Management System
Feature Flat-File System
(DBMS)
Data Redundancy High Minimal (due to normalization)
Enforced via constraints and
Data Integrity Weak
validation
Data Relationships Not supported Fully supported (foreign keys, joins)
Scalability Poor High
None (manual or custom
Query Language SQL
scripts)
Concurrency
Not supported Supported (ACID properties)
Handling
Maintenance Tedious Easy with centralized schema control
3. Hierarchical Data Model
3.1. What is a Hierarchical Data Model?
BCA and Semester III
Database Management System (BCA27103)
Class: BCA27103
Academic Session: 2025-2026
The Hierarchical Data Model organizes data into a tree-like structure where each record
(also called a node) has one parent and possibly multiple children. It is one of the earliest
data models used in database systems and was heavily employed in early IBM databases like
IMS (Information Management System).
This model reflects a one-to-many relationship, similar to a family tree or a file directory.
For example, a university can have multiple Departments, and each department can have
several Professors. But each department belongs to only one university, and each professor
belongs to only one department.
3.2. Structure Overview
The hierarchical model is visually similar to an inverted tree:
University
├── Department
│ ├── Faculty
│ └── Course
└── Administration
● The topmost node is called the root.
● Each child node can only have one parent.
● Relationships are predefined and rigid.
3.3. Real-World Example
Let’s take a real-world scenario of a university database:
● Root: University
● Child of University: Department (like CS, IT, EE)
● Child of Department: Faculty Members
● Child of Faculty: Courses taught
This layout is easy to understand and aligns well with fixed structures.
3.4. Features of the Hierarchical Model
● Data is stored as records, which are grouped into segments.
● Each record is connected to its parent and children using pointers.
● Access to data is performed through navigational commands—starting from the root
and traversing downward.
BCA and Semester III
Database Management System (BCA27103)
Class: BCA27103
Academic Session: 2025-2026
3.5. Advantages of Hierarchical Model
Data Retrieval is Fast and Predictable
Because the structure is known and fixed, accessing a record through its parent is quick. For
example, finding all courses under a department involves a simple path from root to leaf.
Simplicity for Fixed Relationships
When the data hierarchy is rigid and doesn’t change often (such as government records or
bank branches), this model fits well.
Security and Integrity
Parent-child relationships are enforced strictly, which helps maintain referential integrity.
3.6. Limitations and Drawbacks
Despite its early adoption, the hierarchical model has several critical flaws:
1. Rigid Structure
Every child must have exactly one parent. If you need to model a many-to-many
relationship (e.g., a professor teaching in multiple departments), this structure
becomes impractical.
2. Data Redundancy
When multiple parents are needed, the same data has to be duplicated under each
parent, increasing storage and maintenance overhead.
3. Complexity in Data Access
Since you have to start from the root and navigate downwards, retrieving data from
the middle of the tree or combining data from different branches is not
straightforward.
4. Difficult to Modify Schema
Adding new relationships or reorganizing data may require major structural changes
throughout the database.
3.7. Hierarchical vs Relational Model
Criteria Hierarchical Model Relational Model
Structure Tree (one parent per child) Table-based (any relationship)
High (in many-to-many
Data Redundancy Low (due to normalization)
cases)
High (can model complex
Flexibility Low (fixed relationships)
relationships)
Data Access Procedural, navigational Declarative (using SQL)
Schema
Difficult Easier
Modification
3.8. When to Use the Hierarchical Model
BCA and Semester III
Database Management System (BCA27103)
Class: BCA27103
Academic Session: 2025-2026
While largely outdated in general-purpose databases, the hierarchical model is still useful in
specialized systems like:
● File Systems (e.g., Windows folder structure)
● XML Data Structures (which are tree-based)
● Legacy Mainframe Databases (e.g., banking systems still using IMS)
4. Network Data Model
4.1. What is a Network Data Model?
The Network Data Model was developed in the late 1960s as a more flexible alternative to
the hierarchical model. Like its predecessor, it uses a navigational approach, but instead of
a strict tree-like structure, it represents data as a graph, where each record (node) can have
multiple parent and child records.
This allows the model to capture many-to-many relationships, making it more suitable for
real-world applications like student-course enrollments, employee-project allocations, or
supplier-product relationships.
It was standardized by the Conference on Data Systems Languages (CODASYL) and was
used in early database systems such as IDMS and Raima Database Manager.
4.2. Basic Structure and Terminology
In a network model:
● Records are equivalent to entities (like "Student", "Course").
● Sets define relationships between record types.
o Each set has an owner (parent) and one or more members (children).
● Pointers are used to navigate from one record to another.
Here, a record can be part of multiple sets, thus allowing more than one parent—something
not possible in the hierarchical model.
4.3. Advantages of the Network Data Model
1. Supports Complex Relationships
The biggest strength of the network model is its ability to represent complex many-to-
many relationships easily. Unlike the hierarchical model, a child can have multiple
parents, and records can be linked in any logical structure.
2. Better Performance in Specific Scenarios
BCA and Semester III
Database Management System (BCA27103)
Class: BCA27103
Academic Session: 2025-2026
When queries follow predefined paths (especially in large, linked datasets),
performance is often superior to relational databases. This is because relationships are
navigated via pointers, which act like shortcuts.
3. Data Integrity and Consistency
The use of explicit set definitions and linkages makes it easier to enforce integrity
rules. Also, since redundancy is minimized, data consistency is easier to maintain.
4. Flexibility in Data Traversal
Users can move forward and backward through relationships, allowing greater
flexibility in navigation.
4.4. Disadvantages and Limitations
Despite its strengths, the network model also has several drawbacks:
1. Complexity in Design and Implementation
Defining sets, maintaining pointers, and designing network schemas require more
effort and expertise compared to relational models. It’s not intuitive for beginners.
2. Navigational Access Only
Data retrieval requires knowledge of the access path. You cannot simply ask "Give
me all courses taken by a student" unless you know how to reach the "Registration"
set from the "Student" record.
3. Lack of Ad-hoc Querying
Since queries are procedural, there's no high-level, declarative language like SQL in
relational systems. This makes it harder for non-technical users to retrieve data.
4. Difficult Maintenance
Any structural change (like adding a new entity or modifying a set relationship) can
require large-scale updates to applications that rely on specific navigation paths.
4.5. Network vs Hierarchical Model
Feature Hierarchical Model Network Model
Relationship Type One-to-Many (1:N) Many-to-Many (M:N) supported
Parent per Record Only One Multiple parents allowed
Data Access Top-down only Flexible: navigable in any direction
Query Flexibility Limited Moderate
Implementation Simple Complex (due to pointers and sets)
Real-World Suitability Rigid applications More realistic and adaptable
4.6. Where the Network Model is Used
While largely replaced by relational models in modern systems, network databases are still
found in:
BCA and Semester III
Database Management System (BCA27103)
Class: BCA27103
Academic Session: 2025-2026
● Legacy banking systems
● Telecom applications
● Real-time embedded systems
● Mainframe environments
Systems that need tight control over memory and access paths, and where data
relationships are highly interconnected, may still benefit from the performance and structure
of a network model.
5. Entity-Relationship (ER) Model
5.1. What is the ER Model?
The Entity-Relationship (ER) model, introduced by Peter Chen in 1976, is a high-level,
conceptual data model used to define the data elements and relationships in a database
system. It provides a visual blueprint of the system by mapping real-world entities and their
interconnections using simple diagrammatic notations.
The ER model is widely used in the initial stages of database design, allowing developers
and stakeholders to understand how data is organized and how various entities interact with
each other—before any physical schema is created.
5.2. Basic Components of the ER Model
The ER model is built around three primary components: Entities, Attributes, and
Relationships.
5.2.1. Entities
An entity is an object or thing in the real world that is distinguishable from other objects.
● Entity Set: A collection of similar entities.
o Example: "Student" is an entity set; "Alice" is an entity.
Entities can be:
● Strong (Regular): Can be uniquely identified on their own.
● Weak: Cannot be uniquely identified unless linked to another entity.
5.2.2. Attributes
Attributes describe properties or characteristics of an entity.
● Simple (Atomic): Cannot be divided further (e.g., Age, ID).
● Composite : Can be divided into sub-parts (e.g., Name First Name, Last Name).
BCA and Semester III
Database Management System (BCA27103)
Class: BCA27103
Academic Session: 2025-2026
● Derived: Can be calculated from other attributes (e.g., Age from DOB).
● Multivalued: Can have more than one value (e.g., Phone Numbers).
Primary Key: An attribute (or group) that uniquely identifies an entity in the set. It is usually
underlined in diagrams.
5.2.3. Relationships
A relationship is an association between two or more entities.
● Example: A Student "enrolls in" a Course.
● Relationships can also have attributes (e.g., Date of Enrollment).
Types of Relationships:
Type Description Example
Each entity of A relates to one Each passport is assigned to one
One-to-One (1:1)
of B person
One-to-Many (1: One entity of A relates to many One department has many
N) of B employees
Many-to-Many
Many of A relate to many of B Students enroll in many courses
(M: N)
5.2.4. ER Diagram Notations
Symbol Meaning
Rectangle Entity
Ellipse Attribute
Underlined Primary Key
Text Attribute
Multivalued
Double Ellipse
Attribute
Diamond Relationship
Double
Weak Entity
Rectangle
Dashed Line Derived Attribute
BCA and Semester III
Database Management System (BCA27103)
Class: BCA27103
Academic Session: 2025-2026
Figure 2 Example of an ER Diagram
5.3. Weak Entities and Identifying Relationships
A weak entity does not have a sufficient attribute to form a primary key and must be
identified via another (strong) entity. It has:
● Partial key: Uniquely identifies weak entities within their identifying relationship.
● Double rectangle: Used to denote weak entities.
● Double diamond: Used for identifying relationships.
Example: Consider "Dependent" as a weak entity depending on the "Employee" entity.
5.4. Generalization, Specialization, and Aggregation
These are advanced ER modelling concepts used to capture more complex relationships.
● Generalization: Combining multiple entity sets into a higher-level entity.
o Example: "Car" and "Truck" can generalize into "Vehicle".
● Specialization: Breaking down an entity into sub-entities with more specific
attributes.
o Example: "Employee" "Teacher", "Administrator".
● Aggregation: Treating a relationship as a higher-level entity.
o Useful when a relationship itself participates in another relationship.
5.5. Advantages of ER Model
● Clear Conceptual View: It closely reflects how users view data.
● Communication-Friendly: Easily understood by both technical and non-technical
users.
BCA and Semester III
Database Management System (BCA27103)
Class: BCA27103
Academic Session: 2025-2026
● Excellent for Planning: Helps identify all entities, attributes, and relationships before
designing tables.
● Flexible and Extendable: Easily modified if requirements change.
5.6. Limitations of ER Model
● It is a conceptual model only, not directly implemented in DBMS.
● It may become cluttered for large systems with too many entities and relationships.
● Some advanced constraints or triggers cannot be represented in basic ER diagrams.
6. Object-Oriented Data Model (OODM)
The Object-Oriented Data Model (OODM) integrates the principles of object-oriented
programming (OOP) with database design. It was developed to address the limitations of
traditional data models—especially in handling complex data types, real-world modeling,
and behavioral logic.
While earlier models focused solely on data (what is stored), the object-oriented approach
also models behavior (how it acts), resulting in a more complete and realistic representation.
This model is commonly used in systems where data includes images, multimedia, spatial
objects, or engineering structures—like CAD/CAM, AI applications, and multimedia
databases.
6.1. Core Concepts of the Object-Oriented Model
In OODM, everything is an object—just like in object-oriented programming.
1. Objects
An object is a real-world entity that encapsulates:
● State: Defined by attributes (e.g., a student’s name, age)
● Behavior: Defined by methods/functions (e.g., calculateGrade())
Each object is a distinct instance of a class.
2. Classes
A class is a template for creating objects. It defines the structure and behavior of its objects.
Example:
Class: Student
Attributes: studentID, name, age
Methods: enrollInCourse(), calculateGPA()
BCA and Semester III
Database Management System (BCA27103)
Class: BCA27103
Academic Session: 2025-2026
3. Inheritance
Inheritance allows a class to inherit attributes and methods from another class.
● A base class (superclass) provides common features.
● A derived class (subclass) adds specialized features.
Example:
Person inherited by Student and Professor.
4. Encapsulation
Encapsulation means that an object’s data and behavior are bundled together, and access is
restricted via methods. This improves security, modularity, and control.
5. Polymorphism
Objects can behave differently depending on their context. A single method name (e.g.,
printDetails()) can perform differently for a Student vs. a Teacher.
6.2. Structure of an Object-Oriented Database
Object-oriented databases store data in the form of objects rather than rows and columns.
These databases often use Object Query Language (OQL) or object-extended SQL to
access data.
The structure includes:
● Objects (with unique Object IDs)
● Classes (definitions)
● Attributes (data)
● Methods (behavior)
● Relationships (like association, aggregation, inheritance)
6.3. Example – University Database (Object-
Oriented)
Let’s consider a system with:
● Class: Person
Attributes: name, address
Method: printDetails()
● Class: Student (inherits from Person)
Attributes: studentID, courses
Method: calculateGPA()
BCA and Semester III
Database Management System (BCA27103)
Class: BCA27103
Academic Session: 2025-2026
● Class: Professor (inherits from Person)
Attributes: employeeID, department
Method: assignGrade()
Relationships can be represented using object references, such as a Course object holding a
list of Student objects enrolled.
6.4. Comparison with Relational Model
Feature Relational Model Object-Oriented Model
Data Tables (rows and
Objects and Classes
Representation columns)
Support for
No Yes (methods inside classes)
Methods
Inheritance Not supported Supported
Complex Data Strong support (images, videos,
Poor support
Types etc.)
Query Language SQL OQL or object-extended SQL
Good for complex & multimedia
Flexibility Good for structured data
data
6.5. Advantages of OODM
● Closer Real-World Mapping: Objects mirror real-world entities better than flat
tables.
● Supports Complex Data: Multimedia, spatial, and composite types are easily stored.
● Reusability: Classes and methods can be reused through inheritance.
● Encapsulation & Security: Data is accessed and modified only via controlled
interfaces.
6.6. Limitations of OODM
● Complexity: Designing an object-oriented database requires deeper understanding.
● Less Popular: Most DBMS systems (like MySQL, Oracle) are relational; OODBs
have limited market share.
● Performance Overhead: For simple data or high-volume transactional systems,
relational models often outperform OODMs.