Relational Database

Management Systems
Lecture 2: File-Based Systems, Data
Models, Schemas & Instances
Course: IIS 2201 | Jan-May 2026
 Lecture Agenda

• Part 1: The Pre-Database Era

– Traditional file-based systems and their drawbacks.
– The Need for Database Management Systems (DBMS).
• Part 2: Foundations of DBMS
– Introduction to Data Models.
– Understanding Schemas vs. Instances.
– Categories of Data Models (Conceptual, Logical, Physical).
 What is a File-Based System?

• Definition
– A system where data is stored in flat files (text, CSV, binary).
• Decentralized Management
– Each application program manages its own private data files.
– There is no centralized control or shared engine managing the data.
– Historically used before modern DBMS software became standard.
 Architecture of File-Based Systems

• Direct Access
– Application programs access physical files directly.
• Hard-Coded Structure
– The file structure (e.g., character definitions) is embedded inside the
program code.
• Rigidity
– Any change to the file structure requires modifying and recompiling every
program that uses it.
 Example: Student File System

• Scenario
– A university uses separate systems for Admission, Fees, and Exams.
• Redundant Storage
– Admission Dept stores: Name, Address, ID.
– Fees Dept stores: Name, Address, Fees Paid.
– Exam Dept stores: Name, ID, Marks.
• Result
– The same student data (Name, Address) is duplicated across three
different files.
 Drawbacks of File-Based Systems

• Core Issues
– 1. High Data Redundancy (Duplication).
– 2. Data Inconsistency (Out of sync updates).
– 3. Poor Security and Integrity enforcement.
– 4. Difficulty in accessing and maintaining data.
– 5. Issues with concurrency (multiple users).
 1. Data Redundancy

• The Problem
– The same piece of information is held in two or more separate files.
• Consequences
– Wastes valuable storage space.
– Increases the cost of data entry (typing the same thing twice).
– Leads directly to update anomalies.
 2. Data Inconsistency

• The Definition
– Various copies of the same data do not agree with each other.
• Example
– A student changes their address.
– The 'Admission' file is updated.
– The 'Library' file is forgotten.
– Result: The system reports two different addresses for the same student.
 3. Difficulty in Data Access

• No Query Language
– Standard queries (SQL) do not exist.
– Every new request requires a new program to be written.
• Example
– To find 'All students with GPA > 8.0', a programmer must write a new
script.
– Ad-hoc querying is impossible for non-programmers.
 4. Integrity Constraint Problems

• Lack of Central Enforcement

– Constraints (e.g., 'Balance cannot be negative') must be written into the
application code.
• Risk
– If a new programmer forgets to add the check, invalid data enters the
system.
– Rules are not applied uniformly across all files.
 5. Security Limitations

• Basic OS Protection
– Security is typically limited to simple file passwords or OS-level
permissions.
• Lack of Granularity
– Hard to grant access to 'only specific columns' (e.g., allow viewing Name
but hide Salary).
– Generally, a user either has access to the whole file or nothing.
 6. Concurrency & Recovery Issues

• Simultaneous Access
– Uncontrolled concurrent access leads to errors (e.g., two people booking
the same seat).
• Recovery Failure
– If the system crashes during an update, data may be left in a corrupt
state.
– No built-in mechanism to 'roll back' a partial transaction.
 7. Maintenance Challenges

• Program-Data Dependence
– The structure of the data is defined in the application code.
• Impact of Change
– Changing a field from 2 digits to 4 digits (e.g., Year 99 to 2000) requires
rewriting every single program that uses that file.
– This makes the system rigid and hard to scale.
 Why File Systems Fail at Scale

• Not Enterprise Ready

– Cannot handle large volumes of data efficiently.
– Cannot support complex multi-user environments.
– Unreliable for critical applications (Banking, Healthcare).
• Conclusion
– A more robust solution is required: The DBMS.
 The Need for a DBMS

• Solving File System Issues

– Centralized control over data.
– Reduction of redundancy and inconsistency.
– Built-in support for Security, Integrity, and Recovery.
– Standardized query methods.
 What is a DBMS?

• Definition
– A Database Management System (DBMS) is software designed to
define, manipulate, retrieve, and manage data.
• Role
– Acts as an intermediary/interface between the user (or application) and
the physical data.
– Controls all access to the database.
 Transition to Data Modeling

• The Challenge
– Real-world data is complex and interrelated.
– A DBMS needs a structured way to represent this complexity.
• The Solution
– Data Models provide the necessary abstraction to describe data without
worrying about physical storage bits.
 What is a Data Model?

• Definition
– A collection of conceptual tools for describing data, data relationships,
data semantics, and consistency constraints.
• Function
– It acts as a 'blueprint' or 'architectural plan' for the database.
– It defines HOW data is connected and stored logically.
 Purpose of Data Models

• Representation
– To accurately represent real-world entities (Students, Courses) and their
relationships.
• Constraints
– To define rules the data must follow.
• Communication
– To help developers and stakeholders communicate about the system
design.
 Concept: Schema vs. Instance

• Database Schema (The Plan)

– The logical structure or design of the database.
– It rarely changes.
• Database Instance (The Content)
– The actual data stored in the database at a specific moment in time.
– It changes frequently.
 Example: Schema vs. Instance

• Schema (Structure)
– Student (ID: Integer, Name: String, Dept: String)
– This definition is static.
• Instance (Snapshot)
– Row 1: {101, 'Alice', 'CS'}
– Row 2: {102, 'Bob', 'IT'}
– This changes whenever we INSERT, DELETE, or UPDATE records.
 Categories of Data Models

• Three Main Levels

– 1. Conceptual Data Models (High Level)
– 2. Logical Data Models (Representation Level)
– 3. Physical Data Models (Low Level)
• Purpose
– This separation allows for Data Independence.
 1. Conceptual Data Models

• High-Level View
– Designed for business users and stakeholders.
– Focuses on WHAT data is stored, not HOW.
• Characteristics
– Independent of any specific software or hardware.
– Example: Entity-Relationship (ER) Model.
 2. Logical Data Models

• Representational View
– Defines the structure of data elements and relationships.
– Bridge between conceptual and physical.
• Characteristics
– Independent of physical storage but specific to a type of database (e.g.,
Relational).
– Example: Relational Data Model (Tables, Columns).
 3. Physical Data Models

• Low-Level View
– Describes how data is actually stored on the drive.
• Characteristics
– Concerned with file organization, indexing, and access paths.
– Highly dependent on the specific DBMS hardware and software.
– Used for performance optimization.
 Lecture Summary

• File Systems
– Limited by redundancy, inconsistency, and rigidity.
• DBMS
– Solves these issues through centralized management.
• Data Models
– Provide the abstraction layers (Conceptual, Logical, Physical) needed to
design complex systems.