Unit 8 Session 2: File Systems vs Databases and Models | IT 231 BBA Slides

--:-- --
↓ Scroll for more

Unit 8 · Session 2

File Systems vs Databases and Models

IT 231: IT and Applications (BBA)

Today's focus

  1. Topic 3
  2. An Introduction to Database Models

Topic 3

Learning Objectives 🎯

By the end of this session, you will be able to:

  • ✅ Describe the traditional file system approach to managing data.
  • ✅ Identify the major problems associated with the file system approach.
  • ✅ Explain how a database approach solves these problems.

The "Old Way": The File System Approach

Definition: Storing data in a collection of separate, application-specific files.

Think of it like separate digital filing cabinets for each department. 🗄️

  • The accounting department has its own set of files.
  • The sales department has a completely separate set of files.
  • Each application has its own private data.

Visualizing the File System Approach

The same customer data is duplicated across departments.

Accounting Dept.

customer_billing.csv

Contains: Name, Address, Bill

Sales Dept.

customer_contacts.txt

Contains: Name, Address, Phone

Marketing Dept.

mailing_list.xls

Contains: Name, Address, Email

🔍 This separation created several major problems for organizations.

Problem 1: Data Redundancy

The same piece of information is stored in multiple places unnecessarily.

Example: A customer's address is stored in:

  • The Sales file
  • The Marketing file
  • The Accounting file

Wasted Space & Effort

This wastes storage and requires multiple updates for a single change, leading to the next problem...

Problem 2: Data Inconsistency

A direct result of redundancy. When data is not updated everywhere, it becomes inconsistent and unreliable.

Scenario: Customer Moves

A customer, Sita Rai, moves from Pokhara to Kathmandu.

  • Sales updates their file: Address = Kathmandu ✅
  • Accounting forgets to update: Address = Pokhara ❌

Result: Which address is correct? The data cannot be trusted!

Problem 3: Data Isolation

Data is scattered in different files with different formats, making it difficult to access and integrate.

Sales Data

Format: .xls

Accounting Data

Format: .dat

Marketing Data

Format: .csv

Challenge: How do you write one program to get a complete, 360-degree view of a customer?

The Solution: A New Approach ⚡

Organizations needed a way to manage data that was centralized, consistent, and accessible.

Enter the Database Approach.

The Database Approach

The solution is to store all organizational data in a single, centralized location, managed by a specific software.

Database: A shared collection of logically related data.

Database Management System (DBMS): Software that controls the creation, maintenance, and use of a database (e.g., MySQL, Oracle, SQL Server).

File System vs. Database Approach

Before: File System

Sales File

Acct. File

Mktg. File

...leads to...

Redundancy & Inconsistency

After: Database

Sales App

Acct. App

Mktg. App

...all access...

📊 Central Database (via DBMS)

The database provides a "single source of truth" for the entire organization.

Practical Application: Nepal Context

Scenario: Vehicle Registration ("Yatayat")

Imagine the old file-based system for vehicle ownership (the "blue book").

  • Traffic Police Office: Has a file for fines and violations.
  • Transport Management Office (Yatayat): Has a file for ownership and tax records.
  • Insurance Company: Has a file for the insurance policy.

Problem: If you sell your scooter, the new owner's name might be updated at the Yatayat office but not in the Traffic Police's file. A traffic fine could be sent to you, the old owner! This is data inconsistency.

Solution: A modern, centralized database ensures all three departments see the same, up-to-date owner information from a single source.

Summary & Key Takeaways

  • The File System Approach stores data in separate, isolated files, leading to major problems.
  • The three core problems are Data Redundancy, Data Inconsistency, and Data Isolation.
  • The Database Approach solves this by using a central database and a DBMS to manage all data.
  • This creates a "single source of truth", ensuring data is consistent, secure, and easily shared across the organization.

An Introduction to Database Models

Next focus

In this part of today's lecture, you will be able to:

  • ✅ Define a database model.
  • ✅ Describe the hierarchical and network models.
  • ✅ Explain the structure of the relational model.
  • ✅ Understand the importance of the relational model in modern databases.

What is a Database Model?

A database model is a set of rules and standards that defines the logical structure of a database.

It determines how data is stored, organized, and manipulated.

Think of it as the blueprint for a database. 📐

A Look Back: Early Database Models

Before the modern relational model became standard, data was organized differently. Let's explore two influential early models.

1. Hierarchical Model

2. Network Model

1. The Hierarchical Model 🌳

This model organizes data in a rigid, tree-like structure.

Key Features

  • Data is structured like an organization chart.
  • There is a single "root" at the top.
  • Each "child" record has only one parent.

Major Disadvantage

  • Very inflexible.
  • To access data, you must start at the root and navigate down the tree.

2. The Network Model 🕸️

An evolution of the hierarchical model, offering more flexibility.

Key Features

  • Data is in a graph-like structure.
  • A "child" record can have multiple parent records.
  • This allows for more complex relationships.

Major Disadvantage

  • While more flexible, it was still very complex to navigate and manage.

The Game Changer: Relational Model ⚡

Developed by E.F. Codd in 1970, this model revolutionized how we think about data.

The relational model is the basis for almost all modern database systems we use today, including MySQL, PostgreSQL, and SQL Server.

How the Relational Model Works 📊

It organizes data into simple, two-dimensional tables (also called relations).

Tables

Store data about a specific entity (e.g., `Students`, `Courses`).

Rows (Records)

Represent a single instance of that entity (e.g., one specific student).

Columns (Fields)

Represent an attribute of that entity (e.g., `FirstName`, `CourseID`).

Visualizing Relational Tables

Imagine a simple database for our university.

Table: `Students`


| StudentID | FirstName | LastName |
|-----------|-----------|----------|
| 101       | Anjali    | Thapa    |
| 102       | Bikash    | Shrestha |

Table: `Enrollments`


| EnrollmentID | StudentID | CourseID |
|--------------|-----------|----------|
| 1            | 101       | IT231    |
| 2            | 102       | IT231    |

Tables are linked together using common fields called keys (like `StudentID`).

Accessing the Data: SQL 🔍

The power of the relational model is unlocked with a special language.

SQL (Structured Query Language) is the standard language for managing and querying data in relational databases.

It allows for powerful, flexible, and easy-to-understand data manipulation.


SELECT FirstName FROM Students WHERE StudentID = 101;
-- Result: Anjali

Practical Application in Nepal

Relational databases power many systems we use daily.

Digital Wallets (eSewa, Khalti)

They use tables for `Users`, `Transactions`, and `Merchants`. Your transaction history is linked to your User ID, which is a key in the `Transactions` table.

Government Services (Nagarik App)

Integrates data from different government bodies. It likely has tables for `Citizens`, `Documents` (like citizenship, PAN), and `Services`, all linked by a unique Citizen ID.

Summary & Key Takeaways

  • A database model is the logical blueprint of a database.
  • Early models like Hierarchical (tree) and Network (graph) were influential but rigid and complex.
  • The Relational Model is the modern standard, using simple, flexible tables made of rows and columns.
  • SQL is the standard language used to query and manage data in relational databases.

Thank You

Questions before we wrap this hour?

Next: Unit 8 · Session 3 — Database Management Systems

Course Home · Next session