UNIT 1 DATA MODELS

DATA MODELS :

1. Introduction to Data Models

 A data model is a collection of concepts that can be used to describe:
 Structure of data → how data is organized.
 Operations on data → how data can be retrieved, inserted, and modified.
 Constraints on data → rules to maintain accuracy and consistency.
 Data models are fundamental for database design and serve as a bridge
between real-world requirements and how data is stored in computers.

Why Data Models Are Needed?

Real-world entities and relationships are complex and cannot be directly stored.
Different users (end-users, programmers, DBAs) require different views of data.
A data model:
 Simplifies complex reality.
 Provides abstraction.
 Ensures consistency and accuracy in data storage.

2.Purpose of Data Models

i. Conceptual Representation
Captures the real-world meaning of data (entities, attributes, relationships).
Example: A student database should reflect students, courses, grades.

ii. Communication Tool

Provides a common language for database designers, programmers, and end-
users.

iii. Blueprint for DBMS

Guides the implementation of databases.
Decides file structures, indexes, access paths.

iv. Facilitates Data Independence

Helps separate:
 Logical structure (what data is stored).
 Physical storage (how data is stored).

A data model is used to represent data and make it understandable for

 Database designers
 Application developers
 End users

It provides a structured way to describe:

i. Data (what entities/objects exist).
ii. Relationships (how they interact).
iii. Constraints (rules governing the data)
Over time, many data models have been proposed, but they fall into three broad
categories:

2.1. Object-Based Data Models

 Use entities, attributes, and relationships to describe data.
 Provide a high-level abstraction of real-world objects.
 Best suited for conceptual modeling and communication with users.

Key Concepts
 Entity: A distinct object to be represented (e.g., Student, Course, Employee).
 Attribute: A property of the entity (e.g., Name, Age, Salary).
 Relationship: Association between entities (e.g., Student enrolls in Course).

Types of Object-Based Models

Entity-Relationship (E-R) Model

 Introduced by Peter Chen (1976).
 Represents entities, relationships, and attributes using diagrams.
 Widely used for database design methodology.

Object-Oriented Model
 Extends entities to include both:
 State (attributes).
 Behavior (methods/operations).
 Example: A BankAccount object with:
 Attributes: Balance, Account_No.
 Methods: Deposit(), Withdraw().
 Encapsulation = state + behavior together.

Semantic Data Model

 Focuses on the meaning (semantics) of data.
 Similar to E-R and OO, but does not include behavior.
 Example: Customer entity and Bank Account entity with richer semantic
constraints (like ownership).

Functional Data Model

 Oldest approach (nearly 20 years old).
 Views the database as a collection of functions.
 Uses functional languages for queries.
 Example: A function Balance(Account_No) returns the balance of a given
account.

2.2. Physical Data Models

Define how data is actually stored in the computer.
Used at the internal level of the database architecture.

Key Features
 Record structures.
 Record ordering on storage media.
 Access paths (indexes, hashing, B-trees).

Example
 The Unifying Model is a common physical data model.
 It describes storage layouts and access methods for different DBMSs.

2.3. Record-Based Logical Data Models

 Used at logical and external levels.
 Provide a higher-level description of implementation compared to object-based
models.
 Database is organized into fixed-format records (rows/tuples).
 Each record type = fixed number of fields (attributes).
 Each field = usually of a fixed length.

Main Types

Hierarchical Model
 Organizes data into a tree structure.
 Parent–Child relationships
 Example: Company → Departments → Employees.
 Advantages:
 Efficient for hierarchical queries.
 Simple and intuitive for tree-like data.
 Disadvantages:
 Rigid structure.
 Poor support for many-to-many relationships.

Network Model
 Data organized as records and sets.
 Supports many-to-many relationships (unlike hierarchical).
 Uses pointers/links to connect records
 Example: Students register for many Courses; Courses have many Students.
 Advantages: Flexible, efficient for complex relationships.
 Disadvantages: Complex to design, maintain.

Relational Model
 Proposed by E.F. Codd (1970).
 Organizes data into relations (tables).
 Each table has rows (tuples) and columns (attributes).
 Relationships are represented by keys (primary, foreign).
 Manipulated using SQL (Structured Query Language).
 Advantages:
  Simplicity, widely accepted.
 Strong theoretical foundation (set theory).
 High flexibility.
 Disadvantages:
 May be less efficient for very large/complex queries.
 Most popular model today → used in Oracle, MySQL, PostgreSQL, SQL
Server.

2.3.1 Hierarchical Database Model

1. Introduction
 The Hierarchical Database Model is one of the oldest database models,
developed in the late 1950s.
 The Information Management System (IMS) developed by IBM and North
American Rockwell was the first practical hierarchical DBMS.
 In this model, data is represented as a tree structure.
 Records = Nodes of the tree.
 Fields (Attributes) = Branches of the tree.
 A Parent–Child relationship exists:
 Each parent may have multiple children.
 A child can have only one parent
 Supports 1:N (one-to-many) relationships but does not naturally support M:N
(many-to-many) relationships.

2. Structure of the Hierarchical Model

Root Node
 The top-most record in the hierarchy.
 Represents the highest-level entity.
 Example: General Manager (GM) in a company.

Parent and Child Records

 A parent record controls or contains child records.
 Example: A Department (Parent) → Employees (Children).

Levels
 Records are arranged in levels, similar to family trees.
 Example: Great-grandparent → Grandparent → Parent → Child.

Relationships
 Parent–Child relationships ensure that child existence depends on the
parent.
 Example: An employee must belong to a department.

Examples
A. Company Organizational Hierarchy
 Root: General Manager (GM).
 Level 1: Deputy General Managers (DGMs).
 Level 2: Departments under each DGM.
 Level 3: Managers under each department.
 Level 4: Employees under each manager.

This structure forms a strict tree, where each employee can belong to only one
department.

B. Family Tree Example

 Root: Great-Grandparent.
 Children: Grandparents.
 Grandchildren: Parents.
 Great-grandchildren: Children.
 Demonstrates one-to-many relationships clearly.

C. Customer–Loan Example
 Customer C1 and C2 jointly take Loan L1 → shows difficulty in modeling M:N.
 Customer C3 takes Loan L2 and L3.
 Problem: Hierarchical model cannot naturally handle joint ownership or M:N
relationships.
D. Supplier–Parts–Shipments Example
 Parts are treated as parents.
 Suppliers are children of parts.
 Each supplier occurrence includes shipment quantity.
 Example:

 Part P1 supplied by S1 (250 qty) and S2 (250 qty).

 Part P2 supplied by S1, S2, S3.
 Part P3 supplied only by S1.
 Part P4 has no suppliers (parent without child is allowed).
4. Operations in Hierarchical Model
There are four main operations: Insert, Update, Delete, and Retrieve.
A. Insert Operation
 A parent can exist without children.
 But a child cannot exist without a parent.
 Example:
 New Part P5 (with no suppliers) → allowed.
 New Supplier S4 (without supplying any part) → not allowed.
 Insert Anomaly: Occurs when children cannot be inserted without their parent.

B. Update Operation
 If a record occurs multiple times under different parents, updating it requires
multiple changes.
 Example:
 Supplier S1 supplies Part P1, P2, P3.
 If Supplier S1’s city changes, update must be made in all occurrences.
 If one update is missed → inconsistency.
 Update Anomaly: Occurs because the same child record may exist in multiple
places.

C. Delete Operation
 Deleting a parent record automatically deletes all child records.
 Example:
 Deleting Part P2 removes all its supplier records.
 Supplier S3’s information is lost since it only supplied P2.
 Delete Anomaly: Leads to unintended loss of information when a parent is
deleted.

D. Record Retrieval
 Record retrieval is complex and asymmetric.
 Requires explicit traversal of tree paths.
 Example Queries:

Query 1: Find suppliers who supply Part P2

Steps:
 Locate parent node P2.
 Traverse all child suppliers under P2.

 Algorithm:
get [next] part where PNO = P2;do until no more shipments under this part;
get next supplier under this part;
print SNO;
end;

Query 2: Find parts supplied by Supplier S2

Steps:
 Traverse all parts.
 Check if S2 exists under that part.
 Print part number if found.

 Algorithm:
do until no more parts;
get next part;
get [next] supplier under this part where SNO = S2;
if found then print PNO;end;

 Retrieval operations are time-consuming because the system must search

through all paths.

Advantages of the Hierarchical Model

I. Simplicity
 The model is easy to understand because it follows a natural parent–child
hierarchy, similar to a family tree or organizational chart.
 Example: Company hierarchy → GM → Departments → Employees.
 Users can visualize the data in a tree structure without needing advanced
knowledge.

II. Data Integrity

 Parent–child relationships are enforced by the database.
 A child cannot exist without a parent, which prevents orphan records.
 Example: An employee record cannot exist without belonging to a department.

III. Data Security

 Since access paths are predefined, only authorized applications can retrieve data.
 Each record has a clear owner (the parent), reducing the chance of unauthorized
changes.
 Example: Only department heads can access employee records under their
department.

IV. Performance Efficiency

 Very efficient in handling large volumes of data with 1:N relationships.
 Data retrieval is faster then the path is known because traversal is direct.
 Example: Finding all employees in a department is fast as they are stored
directly under the department node.

V. Data Sharing
 Supports sharing of data across different applications because of centralized
tree-based storage.
 Example: An HR application and Payroll system can both use the same Employee
records without duplication.

VI. Reduced Data Redundancy

 Data is organized in a way that minimizes duplication, at least within one
parent’s subtree.
 Example: A department’s details (like Department_ID, Dept_Name) are stored
only once for all employees in that department.

VII. Historical Importance

 One of the earliest successful DBMS models (e.g., IBM IMS).
 Paved the way for network and relational models.
 Still used in certain legacy applications like banking, telecommunications, and
defense.

Disadvantages of the Hierarchical Mode

I. Implementation Complexity
 Physically implementing and maintaining the tree structure is difficult and rigid.
 Any small structural change (e.g., adding a new parent/child relationship)
requires major redesign.

II. Lack of Structural Independence

 Structural changes in the database schema affect all application programs using
it.
 Example: If a department now has “Divisions” between it and employees, all
queries/programs must be rewritten to include that new level.

III. Program Dependence

 Application programs must explicitly navigate through predefined paths to
access data.
 This makes programming complex and error-prone.
 Example: To access Employee data, the program must always start from
Company → Department → Employee path.

IV. Limited Flexibility

 Only supports 1:N relationships directly.
 M:N relationships are either impossible or require complex workarounds (like
duplicating child records).
 Example: If two customers jointly take a loan, the model cannot naturally
represent this relationship.

V. Anomalies
 Suffers from Insert, Update, and Delete Anomalies, similar to unnormalized
relational models.
 Insert Anomaly: Cannot insert a child without a parent.
 Example: Cannot add a new supplier unless they supply a part.
 Update Anomaly: If a child record appears under multiple parents, updating
requires multiple changes.
 Example: If Supplier S1’s address changes, it must be updated everywhere it
appears.
 Delete Anomaly: Deleting a parent deletes all children, leading to unintended
loss of information.
 Example: If Part P2 is deleted, Supplier S3’s information may also be lost.
VI. Data Redundancy
 If a child record has to appear under multiple parents, duplication occurs.
 Example: Supplier S1 appears under Part P1, P2, and P3 → Supplier details are
repeated multiple times.

VII. Difficult Retrieval

 Queries are complex because the database does not support ad-hoc queries
easily.
 User must always know and follow the hierarchy path.
 Example: Finding all parts supplied by Supplier S2 requires traversing all parts
and checking each subtree.

VIII. Maintenance Cost

 Adding new relationships or modifying existing ones is expensive and time-
consuming.
 Example: If an organization changes structure (e.g., introducing project-based
teams across departments), the tree model cannot adapt easily.

IX. Obsolescence
 Modern database models (Relational, Object-Oriented, NoSQL) provide more
flexibility.
 Hierarchical DBMSs are considered outdated, though still used in legacy systems.

Conclusion
The Hierarchical Model was crucial in the early development of databases.
Strengths: Security, efficiency, data integrity.
Weaknesses: Lack of flexibility, anomalies, difficulty in handling many-to-many
relationships.
Modern DBMSs have replaced it with the Relational Model, but hierarchical systems
still exist in legacy applications like banking and telecommunication systems.

3.4.2 Network Model

The Network Data Model was developed as an improvement over the Hierarchical
Model. Instead of a strict tree structure, it uses a graph structure with nodes
(records) and edges (relationships). This allows records to have multiple parent
records, enabling representation of M:N (many-to-many) relationships.
Key Features of Network Model
a. Graph Structure
 Records are nodes in the graph.
 Relationships are edges (called sets) connecting nodes.

b. Owner–Member Relationship
 Each relationship (set) has:
 Owner record → Parent (like in hierarchical model).
 Member record → Child.
 Example: Supplier (owner) → Supplies (set) → Part (member).

c. Support for Multiple Parents

 A record can be linked to multiple owners.
 Example: An employee can work in two departments, or a loan can belong to
multiple customers.

d. Record Access
 Data access is navigational → requires following pointers.
 Retrieval is more flexible than hierarchical but still complex.

Operations in Network Model

 Insert Operation
 New records (e.g., Supplier S4) can be inserted independently, without
being forced to immediately connect to another record.
 Unlike hierarchical model, we can add an isolated record.
 Example: Supplier S4 exists even if it does not supply any part.

 Update Operation
 Easier and more consistent than hierarchical.
 Since data is stored only once, updates do not create redundancy problems.
 Example: Changing city of Supplier S1 is done in one place.

 Delete Operation
 A record (e.g., Part P1) can be deleted without necessarily deleting
connected suppliers.
 Only pointers/connectors are adjusted.
  Example: If S1 stops supplying P1, only the connector is removed.

 Retrieval Operation
 Retrieval is symmetric but complex.
 Uses pointer navigation through sets.
 Example Queries:
 Find suppliers of Part P2.
 Find parts supplied by Supplier S2.

Advantages of the Network Model

i. Conceptual Simplicity
 Easy to design and understand compared to more complex models.
 Still uses owner–member relationships like hierarchical model.

ii. Handles Complex Relationships

 Supports 1:1, 1:N, and M:N relationships directly.
 Example: Joint loan (Loan L1 shared by Customer C1 and C2) can be modeled
without duplication.

iii. Reduced Data Redundancy

 Since records can have multiple owners, there is no need to duplicate child
records.
 Example: Loan L1 is stored once, linked to both customers.

iv. Ease of Data Access

 More flexible than hierarchical.
 Can access data from different entry points (not always from root).

v. Data Integrity
 A member record cannot exist without an owner.
 Prevents orphan records and maintains referential integrity.

vi. Data Independence

 Physical storage details are hidden from users.
 Applications work with logical structures, not actual physical storage.
vii. Database Standards
 Standardized by DBTG (Database Task Group) and ANSI/SPARC in the 1970s.
 Provided DDL (Data Definition Language) and DML (Data Manipulation
Language).
 Increased portability and administration efficiency.

Disadvantages of the Network Model

i. System Complexity
 Relies heavily on pointers to maintain relationships.
 Database structure becomes difficult to design and maintain.

ii. Operational Anomalies

 Insert, Delete, and Update operations require pointer adjustments.
 Though anomalies are reduced compared to hierarchical, operations remain
complicated.

iii. Absence of Structural Independence

 Data access is navigational.
 Any structural changes (e.g., adding a new record type) require modifications in
all application programs.
 Example: Adding a new connector between Supplier and Warehouse would
force updates to all related queries.

iv. Complex Retrieval

 Though flexible, retrieval is pointer-heavy and harder to implement.
 Example: To find suppliers for Part P2, must navigate through part → connectors
→ supplier.

v. High Maintenance Cost

 Requires skilled programmers to maintain and optimize.
 Not user-friendly for casual or business users.

vi. Obsolescence
 Replaced by the Relational Model in the 1980s due to complexity.
 Still used in some legacy applications (telecom, banking, defense).

3.4.3 Relational Model

The Relational Model, proposed by Dr. E.F. Codd (IBM Researcher, 1960s), is the
most widely used and accepted data model in database management systems. It
organizes data into relations (tables) consisting of rows (tuples) and columns
(attributes). This model emphasizes simplicity, flexibility, and mathematical rigor.
A Relational Database allows grouping of related data into multiple independent
tables, which can then be linked (related) using common fields (keys).

Components of Relational Model

The relational model is built on three major components:
Data Structure (Relations and Domains)
Relations are represented as tables.
Domains define the permissible values for attributes.

Data Integrity (Constraints)

Integrity rules ensure data correctness and consistency.
Examples: Primary Key constraint, Foreign Key constraint, Domain constraints, etc.

Data Manipulation (Operations)

Includes operations to insert, update, delete, and retrieve data.
Carried out mainly using SQL (Structured Query Language).

Characteristics of Relational Databases

 Data is represented as tables (relations) with rows and columns.
 Each row represents a tuple (record).
 Each column represents an attribute.
 Values are scalar (only one value per cell).
 Operations follow the principle of closure (results of operations are themselves
relations).
 Physical storage details are hidden from users (data independence).

3.4.3.1 Basic Terminology in Relational Model

The relational model introduces certain fundamental concepts that are crucial for
understanding how data is stored, managed, and manipulated.

1. Relation
 A relation is essentially a table with rows and columns.
 Each relation describes a set of entities of the same type.
 Example:
STUDENT (RollNo, Name, Course, City)
 Here, STUDENT is the relation with attributes RollNo, Name, Course, and City.

2. Tuple (Row / Record)

 A tuple represents a single record in the relation.
 Each tuple corresponds to one instance of the entity.
 Tuples are unordered (sequence of rows does not matter).
 Example (Tuples of STUDENT relation):
 (101, Amit, BCA, Delhi)
 (102, Neha, MCA, Amritsar)

3. Attribute (Column / Field)

 An attribute represents a property/characteristic of the entity.
 Each column in a relation corresponds to an attribute.
 Example:
In STUDENT relation:
 RollNo → Unique identifier
 Name → Student’s name
 Course → Program enrolled
 City → City of residence

4. Domain
 A domain is the set of all possible values an attribute can take.
 Domains ensure data integrity by restricting invalid values.
 Examples:
 Domain of RollNo = {positive integers}
 Domain of Course = {BCA, MCA, B.Tech, MBA}
 Domain of City = {Any valid city name string}

5. Degree of Relation
 Number of attributes (columns) in a relation.
 If a relation has 4 attributes, its degree = 4.
 Example:
STUDENT relation has 4 attributes → Degree = 4.

6. Cardinality of Relation
 Number of tuples (rows) in a relation.
 If a table has 100 records, its cardinality = 100.
 Example:
STUDENT relation with 50 records → Cardinality = 50.

7. Keys
Keys are special attributes (or combinations) used to identify, connect, or constrain
tuples.
 Primary Key (PK):
 Uniquely identifies each tuple.
 Must :not be NULL or duplicate.
 Example: RollNo in STUDENT relation.

 Candidate Key:
 Any attribute (or combination) that can uniquely identify a tuple.
 Out of candidate keys, one is chosen as the Primary Key.

 Alternate Key:
 Candidate keys not chosen as Primary Key.

 Foreign Key (FK):

 Attribute that refers to the Primary Key of another relation.
 Used to establish relationships between tables.
  Example: In LOAN relation, CustID is a Foreign Key referencing
CUSTOMER(CustID).

 Composite Key:
 A combination of two or more attributes that together uniquely identify a
tuple.
 Example: (CourseID, StudentID) in ENROLLMENT relation.

 Super Key:
 Any attribute (or set) that uniquely identifies tuples.
 Primary Key is a minimal super key.

8. NULL Value
 Represents missing, unknown, or inapplicable data.
 Important to distinguish NULL from zero (0) or empty string ('').
 Example: Student with no phone number yet → Phone field = NULL.

9. Schema and Instance

 Schema: Logical design of a relation (blueprint).
 Example: STUDENT (RollNo, Name, Course, City).
 Instance: Current content (tuples) of the relation at a given time.

10. Body of Relation

 The actual set of tuples present in a relation.
 Example: STUDENT relation with 50 rows → body contains those 50 rows.

3.4.3.2 Operations in Relational Model

Operations in relational model are based on relational algebra and SQL
implementation. They are broadly classified as:
1. Insert Operation
 Adds a new tuple into a relation.
 Must satisfy integrity constraints (PK uniqueness, FK validity).
 Example:
INSERT INTO STUDENT VALUES (103, 'Ravi', 'MCA', 'Jalandhar');
 Constraints checked:
 RollNo must be unique (PK rule).
 Course must be valid (Domain rule).

2. Update Operation
 Modifies attribute values of existing tuples.
 Ensures data consistency (no violation of integrity constraints).
 Example:
UPDATE STUDENT SET City='Amritsar' WHERE RollNo=103;
 If RollNo does not exist → No update performed.

3. Delete Operation
 Removes tuples from a relation.
 If tuple is referenced by other relations (via FK), deletion may be restricted or
cascaded.
 Example:
 DELETE FROM STUDENT WHERE RollNo=103;
 If RollNo=103 is referenced in ENROLLMENT → deletion fails (unless
CASCADE is enabled).
4. Retrieve Operation (Selection & Projection)
 Selection (σ): Chooses specific tuples (rows) based on condition.
SQL: SELECT * FROM STUDENT WHERE Course='MCA';
 Projection (π): Chooses specific attributes (columns).
SQL: SELECT Name, City FROM STUDENT;
 Combined: SELECT Name FROM STUDENT WHERE Course='MCA';

5. Join Operation
 Combines tuples from two or more relations based on a related attribute
(usually PK–FK).
 Example:
Retrieve names of students who have taken loans:
 SELECT STUDENT.Name, LOAN.LoanAmount FROM STUDENT JOIN LOAN
ON STUDENT.RollNo = LOAN.RollNo;

6. Union, Intersection, Difference, Cartesian Product

Relational algebra provides set operations on relations:
 Union (∪): Combines tuples from two relations (removes duplicates).
 Intersection (∩): Common tuples in both relations.
 Difference (-): Tuples in one relation but not the other.
 Cartesian Product (×): Pairs every tuple of one relation with every tuple of
another (basis for joins).

7. Aggregate Functions and Grouping

 Used for summarization.
 Examples:
 COUNT(*) → Number of students
 AVG(Marks) → Average marks
 GROUP BY Course → Group students by course and count each group.

8. Integrity Operations
 DBMS automatically enforces:
 Entity Integrity: PK cannot be NULL.
 Referential Integrity: FK must match PK in referenced relation.
 Domain Constraints: Values must belong to valid domain.

3.4.3.3 Advantages of Relational Model

The relational model has many strengths that contributed to its dominance in
modern database systems.
1. Structural Independence
 Changes in the database structure (adding/removing tables, attributes) do not
affect how data is accessed.
 Users and applications are insulated from changes in physical storage.
 Example: Adding a column PhoneNumber to the Customer table does not break
existing queries.

2. Conceptual Simplicity
 The model is simple to understand: data is stored in tables (a familiar concept).
 No need to understand physical pointers or tree/network structures as in
hierarchical or network models.
 This simplicity makes it widely used in business, education, and research.

3. Ease of Design, Implementation, and Maintenanc

 Independence from physical storage details makes database design more
flexible.
 Maintenance is easier since changes can be made logically without affecting
stored data.
 Database administrators (DBAs) can enforce constraints (primary keys, foreign
keys, etc.) centrally.

4. Powerful Query Capability (Ad-hoc Queries)

 Relational databases support SQL, a high-level, declarative query language.
 Users specify what they want, not how to retrieve it.
 Example:
 SELECT Name FROM Supplier WHERE City='Amritsar';
instantly retrieves suppliers without user worrying about search algorithms.

5. Data Integrity and Accuracy

 Built-in constraints (Primary Key, Foreign Key, Unique, Not Null, Check) ensure
correctness.
 Prevents duplicate records, invalid references, or inconsistent entries.
 Example: You cannot insert a loan record for a non-existent customer (Foreign
Key rule).

6. Data Independence
 Logical independence: Change in schema (attributes, tables) does not affect
existing applications.
 Physical independence: Change in storage mechanism (file structures, indexing)
does not affect logical design.

7. Reduced Anomalies
 Eliminates Insertion, Update, and Deletion anomalies that plagued earlier
models.
 Example: Adding a new customer without a loan is possible without redundancy.

8. Standardization and Popularity

 SQL became an industry standard, making relational databases portable across
vendors (Oracle, MySQL, PostgreSQL, SQL Server).
 Widespread adoption ensures skilled workforce availability and robust support.

3.4.3.4 Disadvantages of Relational Model

While the relational model is powerful, it has some drawbacks, especially in certain
contexts:

1. Hardware Overheads
 Relational DBMS hides complexities (indexing, joins, constraints), which require
powerful hardware.
 Early RDBMS systems needed large memory and storage, making them
expensive.
 Today, this is less of an issue due to advancements in processing power.

2. Ease of Design May Lead to Bad Designs

 Because relational databases are easy to set up, inexperienced users may create
poorly normalized tables.
 Poor design leads to:
Data redundancy,
Performance degradation,
Risk of data corruption.
 Example: Storing Customer + Order data in the same table → repeated customer
details in every order.

3. Performance Limitations with Very Large Databases

 For huge datasets (big data, multimedia, real-time systems), relational DBMS
may become slow.
 Joins across multiple large tables are computationally expensive.
 Modern NoSQL/Big Data systems sometimes perform better in such cases.

4. Information Island Phenomenon

 Ease of creating independent databases may lead to multiple unconnected
systems within an organization.
 This results in:
 Data duplication,
 Inconsistencies,
 Lack of integration across departments.
 Example: HR department and Finance department each creating their own
Employee database.

5. Impedance Mismatch with Object-Oriented Applications

 Relational model deals with tables; object-oriented programming deals with
objects.
 Mapping objects to relational tables (ORM – Object Relational Mapping)
introduces complexity.
 Example: An object with nested properties may not map neatly into a flat
relational table.

6. Scalability Issues
 Traditional RDBMS are not horizontally scalable (difficult to distribute across
multiple servers).
 NoSQL databases (MongoDB, Cassandra) scale better for web-scale applications.

Which Data Model to Use?

The choice of a data model depends on the requirements, workload, and
organizational goals. No single model is “best” for all cases, but the Relational Model
has emerged as the most widely used in practice.

Factors Affecting the Choice of Data Model :

1. Primary Goals of the Organization
 If the organization’s goal is simple and efficient storage with minimal flexibility
→ hierarchical model may suffice.
 If complex relationships and frequent modifications are required → relational
model is more suitable.
 If object-oriented applications are to be supported (e.g., multimedia, CAD
systems) → object-based models are useful.

2. Volume of Daily Transactions

 Organizations with very high volumes of transactions need a model that:
 Ensures fast retrieval and updates
 Maintains data integrity under concurrent access
 The relational model with indexes and optimized queries is usually preferred for
such cases.

3.Estimated Number of Enquiries (Queries)

 If a system must support many queries, reports, and analytics, the relational
model provides:
 Declarative query languages (SQL)
 High flexibility in retrieving data
 Easier adaptation to changing query requirements
 In contrast, network and hierarchical models require navigating pointers, which
makes queries complex.
COMPARISON OF DATA MODELS :