Ln 1 DATABASE SYSTEMS
Database in DBMS (Database Management System):
A database is an organized collection of data that is stored and accessed electronically. In the context of a
DBMS, the database is managed and manipulated through software that provides tools for:




Storing data efficiently,
Retrieving data quickly,
Modifying and deleting data,
Ensuring data integrity, security, and consistency.
Example:
If you're using a library management system, the database might store information like:




Book titles
Author names
Borrower details
Due dates
Great question—data and information are often used interchangeably, but they actually
mean different things:
� Data:




Raw, unprocessed facts.
No context or meaning on its own.
Examples:
o 42, John, 2025-04-15, 7.3
o A spreadsheet full of numbers without labels
Think of data as the ingredients.
� Information:




Processed or organized data that has meaning or context.
Useful for making decisions.
Examples:
o "John scored 42 points on April 15, 2025."
o "The average temperature this week was 7.3°C."
Think of information as the finished dish made from the ingredients.
Database design is super important—it’s like laying the foundation for a building. If the
foundation’s weak, the whole thing can fall apart. Here’s why good database design matters:
🏗️ 1. Data Integrity


Ensures data is accurate, consistent, and reliable.
Prevents issues like duplicate records, incorrect relationships, or orphaned data.
⚡ 2. Performance


A well-designed database runs faster and handles more users without choking.
Poor design = slow queries, overloaded servers, and frustrated users.
🔍 3. Easy Access & Reporting


Organizing data smartly makes it easier to query, analyze, and report.
Example: Want to know how many orders were placed last month? A good design
makes that a breeze.
🔐 4. Security & Access Control


Lets you control who can see or edit what, down to specific tables or fields.
Crucial for protecting sensitive data like personal info or financial records.
🛠️ 5. Scalability


Good design makes it easy to add new features or grow without starting from
scratch.
Whether it’s 100 records or 10 million, the structure can handle it.
� Real-world analogy:
A database is like a library. Good design is having clear sections, labeled shelves, and a
catalog system. Without it, you’re just stuck in a room full of random books.
evolution of file systems in data processing, in simple terms:
🗃️ 1. File-Based Systems (1950s–1970s)
The Early Days



Data was stored in flat files (like .txt, .csv, or custom formats).
Each application managed its own data independently.
Access was sequential, slow, and tightly tied to the program.
Problems:




❌ Redundancy – same data stored in multiple places
❌ Inconsistency – changes in one file weren’t reflected elsewhere
❌ No security – anyone could open and modify files
❌ Difficult to scale or share data
� 2. Hierarchical & Network Databases (1960s–1970s)
More Structure, But Still Rigid



IBM's IMS (Information Management System) introduced hierarchical models
(like tree structures).
Network models allowed more flexible relationships (many-to-many).
Data access required complex navigation using pointers.
Improvements:


Better than flat files for relationships
Allowed shared data across apps
Limitations:



❌ Hard to modify structure
❌ Navigation was tricky
❌ Still very program-dependent
� 3. Relational Databases (1970s–Today)
The Game-Changer

Introduced by Edgar F. Codd at IBM.


Based on tables, rows, and columns with relationships using keys.
Used SQL (Structured Query Language) to manage data.
Benefits:




✅ Data independence
✅ Easier to query
✅ Better integrity & normalization
✅ Reduced redundancy
Popular systems: Oracle, MySQL, PostgreSQL, MS SQL Server
☁️ 4. Object-Oriented & NoSQL Databases (1990s–Now)
For Modern, Complex Needs


Object-oriented databases: Store data as objects (used in some niche apps).
NoSQL: Designed for big data, real-time web apps, and flexible schemas.
Types of NoSQL:




� Document-based (MongoDB)
📦 Key-Value stores (Redis)
� Graph databases (Neo4j)
📚 Column-family stores (Cassandra)
Benefits:



✅ High performance & scalability
✅ Schema flexibility
✅ Good for unstructured data
🔮 5. Cloud & Distributed Data Systems (Now & Future)
Data Anywhere, Anytime



Systems like BigQuery, Amazon Redshift, Snowflake, Databricks.
Handle massive data across multiple machines.
Support real-time analytics, AI/ML, and global access.
Trends:


Serverless databases
Data lakes + warehouses

Data mesh architecture
TL;DR:
Era
System Type
Key Feature
1950s–60s File-Based
Flat files, manual handling
60s–70s
Hierarchical/Network
Structured, but rigid
70s–Today Relational
Tables, SQL, relationships
90s–Now Object-Oriented / NoSQL Flexibility, scalability
Now–Future Cloud/Distributed
Real-time, massive scale
Here’s a breakdown of the main problems with file system-based data processing:
🌀 1. Data Redundancy



Same data stored in multiple files or locations.
Example: Customer info repeated in every department’s file.
🔁 Wastes space and leads to inconsistency.
❌ 2. Data Inconsistency



When the same piece of data is updated in one file but not others.
Example: A customer’s address changes in one file but not in another.
Leads to errors and unreliable reports.
🔒 3. Lack of Security



File systems had very limited access control.
Anyone with access could view or modify files, which is risky for sensitive data.
No fine-grained permissions like “read-only” or “admin access.”
� 4. Data Isolation



Data stored in different formats across separate files.
Hard to combine data from multiple sources for analysis.
Makes cross-functional reporting and insights difficult.
🛠️ 5. Difficult Data Access



You had to write custom code for every query or report.
No standard query language like SQL.
Simple tasks could take a lot of time and effort.
🔄 6. Concurrency Issues


No built-in support for multiple users accessing or updating files at the same time.
Could lead to:
o File corruption
o Data loss
o Conflicts
� 7. Rigid Structure


File formats were usually fixed—changing the structure (like adding a new field) was
a pain.
Could require rewriting applications that used those files.
🚫 8. Poor Backup & Recovery


File systems didn’t support automated backups, logging, or recovery mechanisms.
If data was lost or corrupted, it was often gone for good.
📉 Summary:
Problem
Why It’s Bad
Data redundancy Wastes space, causes conflicts
Data inconsistency Leads to errors
Lack of security
No control over access
Data isolation
Hard to get the full picture
Hard access
Custom code needed for everything
Concurrency issues Risk of data corruption
Rigid structure
Difficult to change or scale
Weak backup
High risk of data loss
Alright! Let’s break down database systems—what they are, why they’re important, and
what types exist.
📚 What is a Database System?
A database system (or DBMS—Database Management System) is software that helps you:




Store data in an organized way
Retrieve data easily (using queries like SQL)
Update or delete data efficiently
Manage who can access and change the data
It sits between the user/application and the actual data, handling all the heavy lifting.
� Key Functions of a DBMS





✅ Data storage & retrieval
✅ Data security & access control
✅ Backup & recovery
✅ Multi-user support (concurrency control)
✅ Data integrity (rules to keep data accurate)
� Components of a Database System
1.
2.
3.
4.
Database – the actual organized collection of data
DBMS – the software that manages access and updates
Query Language – like SQL to interact with the data
Users – people or apps using the database
� Types of Database Systems
1. Relational Database Management Systems (RDBMS)



Based on tables (rows and columns)
Use SQL for data operations
Examples: MySQL, PostgreSQL, Oracle, SQL Server
🔹 Best for: Structured data, transactions, business apps
2. NoSQL Databases


Non-tabular, flexible schema
Types:
o 🗂️ Document (MongoDB)
o 🔑 Key-Value (Redis)
o � Columnar (Cassandra)
o 🔗 Graph (Neo4j)
🔹 Best for: Big data, fast-growing apps, unstructured data, real-time use cases
3. NewSQL Databases


Combine scalability of NoSQL with the reliability of SQL
Examples: Google Spanner, CockroachDB
🔹 Best for: Cloud-scale applications with strong consistency
4. In-Memory Databases


Store data in RAM for super-fast access
Examples: Redis, Memcached
🔹 Best for: Real-time analytics, caching, gaming, high-frequency trading
5. Cloud-Based Databases


Hosted and managed on cloud platforms
Examples: Amazon RDS, Firebase, Snowflake, Azure SQL
🔹 Best for: Modern apps, serverless architecture, global availability
⚖️ DBMS vs File System (Quick Comparison)
Feature
File System
DBMS
Data Structure
Flat files
Tables, objects, graphs
Redundancy
High
Low
Data Access
Manual coding Query language (SQL)
Security
Limited
Strong access control
Concurrency
Poor
Excellent
Backup/Recovery Manual
Automated & reliable
👥 Who Uses DBMS?




Businesses (e.g., inventory, HR, CRM systems)
Websites (user data, transactions)
Apps (mobile, games, etc.)
Researchers & analysts (data science, big data)
Awesome! Let’s break down data modeling and data models—super important concepts if
you’re working with databases or planning systems.
� What is Data Modeling?
Data modeling is the process of visually and logically designing how data is organized,
stored, and related to each other in a database.
Think of it like creating a blueprint before constructing a building—except here, you’re
designing how your data will work.
🔹 It answers questions like:



What entities (things) are we storing?
What are their attributes (details)?
How do they relate to each other?
� What is a Data Model?
A data model is the representation (or result) of that design process. It shows the structure
of the data, the relationships, and the rules that define how data behaves.
There are different types/levels of data models, each serving a different purpose.
📊 Types of Data Models
1. Conceptual Data Model




High-level overview
Focuses on business concepts and rules
Entities, relationships, and attributes
No concern about physical implementation
🔹 Tools: ER diagrams (Entity-Relationship diagrams)
� Example:



Entity: Customer
Attribute: CustomerName, Phone
Relationship: Customer places Order
2. Logical Data Model



More detailed than conceptual
Adds data types, keys, and normalization
Still platform-independent (no SQL, no DBMS specifics)
🔹 Focus: How data will be structured logically (e.g., table structures, columns,
relationships)
3. Physical Data Model



The most detailed
Focuses on how the data is actually stored
Includes:
o Table names
o Column types
o Indexes
o Storage details
o Constraints
o Relationships (foreign keys)
🔹 DBMS-specific (e.g., designed for Oracle, MySQL, PostgreSQL)
� Common Data Model Types (by structure)
Data Model
Description
Example
Tree-like structure
IBM IMS
Hierarchical
More flexible, many-to-many CODASYL DB
Network
Based on tables & keys
MySQL, PostgreSQL
Relational
Object-Oriented Data as objects with methods db4o, ObjectDB
Schema-free JSON/XML docs MongoDB
Document
Nodes + edges for relationships Neo4j
Graph
🚀 Why Data Modeling Matters




✅ Ensures data consistency and integrity
✅ Simplifies development and maintenance
✅ Supports better performance and scalability
✅ Bridges the gap between business needs and technical implementation
🛠️ Tools for Data Modeling


ERD Tools: Lucidchart, dbdiagram.io, Draw.io, ER/Studio
Database Design Software: MySQL Workbench, Microsoft Visio, Oracle SQL
Developer Data Modeler
� Quick Example (Relational Data Model)
Entities:



Student(StudentID, Name, Email)
Course(CourseID, Title)
Enrollment(StudentID, CourseID, Grade)
Relationships:


A student can enroll in many courses.
A course can have many students.
This can be visualized in an ER diagram or turned into SQL tables.
Great choice! The evolution of data models reflects how technology has adapted to handle
increasingly complex data, larger volumes, and faster processing needs. Let’s walk through
this evolution step by step:
🕰️ Evolution of Data Models
1. 🗂️ File-Based Systems (Pre-1960s)



No data model as such—just flat files.
Data stored in plain text or binary files.
Each application had its own way to process files.
🔻 Issues: Data redundancy, inconsistency, poor scalability, and no relationship between
files.
2. 🌲 Hierarchical Data Model (1960s)



Data organized in a tree-like structure (parent-child).
One-to-many relationships only.
Introduced by IBM’s IMS (Information Management System).
🔹 Example: A company with Departments (parent) and Employees (children).
🔻 Limitation: Rigid structure. If relationships became more complex (like many-to-many),
it got messy.
3. 🌐 Network Data Model (Late 1960s–1970s)



More flexible than hierarchical.
Supports many-to-many relationships.
Uses a graph-like structure with records and sets (like pointers).
🔹 CODASYL was the standard. 🔻 Limitation: Very complex to navigate. Required
procedural navigation of data (hard-coded paths).
4. � Relational Data Model (1970s–Present)


Introduced by E.F. Codd (IBM).
Organizes data in tables (relations).


Uses keys and foreign keys to define relationships.
Uses SQL as the query language.
🔹 Simple, flexible, and powerful. 🔹 Normalization to reduce redundancy. 🔻 Limitations:
Not ideal for unstructured data or massive distributed systems.
5. � Object-Oriented Data Model (1980s–1990s)



Combines concepts of object-oriented programming with databases.
Data stored as objects (with attributes and methods).
Supports complex data types like images, audio, etc.
🔹 Great for multimedia and CAD apps. 🔻 Limited adoption. Performance lagged behind
relational systems.
6. ☁️ NoSQL Data Models (2000s–Present)



Born from web-scale data problems (Google, Amazon, Facebook).
Designed for scalability, flexibility, and high availability.
Four major types:
o Document (MongoDB): stores JSON/XML-like structures.
o Key-Value (Redis, DynamoDB): simple and fast.
o Column-Family (Cassandra, HBase): good for analytics.
o Graph (Neo4j): great for highly connected data.
🔹 Schema-less, distributed, horizontally scalable. 🔻 Limited consistency (eventual
consistency in some cases).
7. 🔄 NewSQL & Multi-Model (2010s–Now)


NewSQL: Retains relational model + supports distributed architecture (e.g., Google
Spanner, CockroachDB).
Multi-model: Supports multiple data models in one engine (e.g., ArangoDB,
OrientDB).
🔹 Tries to offer the best of both SQL and NoSQL worlds.
8. 🔮 Future & Emerging Models



Graph + AI + Semantic models: For knowledge graphs, reasoning, and natural
language interfaces.
Time-series models: For IoT, sensors, finance (e.g., InfluxDB, TimescaleDB).
Blockchain-based data models: For decentralized, immutable storage.
📊 Summary Table
Era
Pre-1960s
1960s
1970s
1970s–
Now
Model
File-Based
Hierarchical
Network
Key Features
No modeling, flat files
Tree structure
Graph-like, many-to-many
Example
Manual files
IBM IMS
CODASYL DB
Relational
Tables, SQL, normalization
MySQL, Oracle
1980s–90s Object-Oriented
2000s–
Now
2010s–
Now
Emerging
NoSQL
Objects, methods, complex
types
Flexible, scalable, schemaless
ObjectDB
MongoDB,
Cassandra
NewSQL / Multi-Model
Combines models, distributed Spanner, ArangoDB
Semantic / Graph / TimeSeries
For AI, IoT, analytics
Neo4j,
TimescaleDB
Great topic! The degrees of data abstraction refer to the layers or levels used to hide
complexity and make working with data easier and more organized.
This concept is key in database design and is part of the three-level architecture proposed
by the ANSI/SPARC model.
📚 Degrees (Levels) of Data Abstraction
There are three main levels of data abstraction:
1. External Level (View Level) – "What the user sees" 👀



Closest to end-users.
Describes individual user views of the data.
Different users can have different views depending on what they need or are allowed
to see.
📌 Example:
A student might only see their grades, while an admin sees all student records.
✅ Purpose: Customization & security
✅ Focus: What data is relevant to a specific user or application
2. Conceptual Level – "What the organization sees" �


Describes the entire structure of the database for an organization.
Includes all entities, relationships, and constraints—but hides physical details.
📌 Example:
Tables like Students, Courses, and Enrollments with relationships defined.
✅ Purpose: Unified view of the entire database
✅ Focus: Logical structure (schemas, relationships)
3. Internal Level – "How the data is stored" 💾


Closest to the physical storage.
Describes how data is actually stored in files, indexes, and data structures.
📌 Example:
Data stored as binary files, use of B-trees for indexing, partitioning by semester.
✅ Purpose: Efficiency & optimization
✅ Focus: Physical storage & access paths
🔄 How They Relate
Level
What it Describes
Who Uses It
End-users, front-end apps
External Specific user views
Conceptual Logical database structure DB designers, analysts
Physical storage & indexing DB administrators, system programmers
Internal
✅ Abstraction helps separate concerns, so changing storage (internal) doesn’t affect how
users see data (external).
🎓 Real-World Analogy:
Imagine a library:



External: What a visitor sees—just the book titles and sections they care about
Conceptual: The catalog system—all books, categories, authors, and how they relate
Internal: How the books are physically stored—on shelves, indexed by barcodes,
arranged in boxes