Key Concepts

Habari Mwanafunzi! Welcome to the World of Databases!

Ever wondered how M-Pesa remembers your balance? Or how your school keeps track of every student's marks, from Form 1 to Form 4? The magic behind all of this is something called a database. Think of it as a super-organized digital filing cabinet. Today, we're going to open that cabinet and learn about its most important parts. Let's dive in!

The Building Blocks: From a Tiny Bit to a Giant Database

Just like a house is built from bricks, a database is built from smaller pieces of data. We call this the data hierarchy. It's a simple idea: we start small and build up.

• Bit & Byte: The smallest piece is a bit (a 0 or 1). We group 8 bits to form a byte, which can represent a single character, like the letter 'K' or the number '5'.
• Field (or Attribute): This is one single piece of information. Think of it as a column in a table. For a student, a field could be `FirstName`, `AdmissionNumber`, or `County`.
• Record (or Tuple): This is a complete set of fields for one person or item. It's like a single row in a table. All your details together make up your record in the school system.
• File (or Table): This is a collection of related records. For example, a `Students` table contains the records of all students in the school.
• Database: Finally, the database is a collection of related tables. A school database might have a `Students` table, a `Teachers` table, and a `Fees` table, all working together.

Let's visualize this with a simple `Students` table:

    A Simple Table (File)
    +-----------------+------------+-----------+--------+
    | AdmissionNumber | FirstName  | County    | KCPE   |  <-- These are FIELDS
    +-----------------+------------+-----------+--------+
    | 8001            | John       | Nairobi   | 415    |  <-- This whole row is a RECORD
    +-----------------+------------+-----------+--------+
    | 8002            | Mary       | Mombasa   | 421    |
    +-----------------+------------+-----------+--------+
    | 8003            | David      | Kisumu    | 398    |
    +-----------------+------------+-----------+--------+
      ^
      |
      This 'J' is made of bytes, which are made of bits.

Image Suggestion: A vibrant, colorful pyramid diagram illustrating the data hierarchy. At the base is 'Bit', moving up to 'Byte', 'Field', 'Record', 'File', and at the very top, 'Database'. Use icons for each level, like a tiny '01' for Bit and a folder icon for File.

Database Models: The Architectural Blueprints

You can't just throw data into a box; you need a plan! A database model is the structure or blueprint for how data is stored and connected. The most important one for you to know is the Relational Model.

• Hierarchical Model: An old model structured like a family tree. Data is organized in a top-down way. Think of a school's structure: Principal at the top, then Deputy Principals, then Heads of Department, and so on.
• Relational Model: This is the most popular model today! It organizes data into tables (like the one above) that can be linked together using a common field.

Real-World Example: Think about the Huduma Namba system. You have one number (your Huduma Namba). This number can be used to link to your KRA tax records, your NHIF health records, and your NTSA driving records. Each of these (KRA, NHIF, NTSA) could be a separate table, but they are all *related* to you through that one number. That's the power of a relational database!

Keys: The Super Glue of Databases!

How do we link tables together? And how do we make sure we find the *exact* student we're looking for, especially if there are three students named 'James Omondi'? We use keys!

• Primary Key: This is a field that uniquely identifies each record in a table. It cannot be repeated and it cannot be empty. Your Admission Number is a perfect primary key. Your name is not, because other students might share it.
  • Other examples: National ID Number, M-Pesa Transaction ID, Car Plate Number.
• Foreign Key: This is a primary key from one table that is placed into another table to create a link. It's the "glue" that connects our tables. For example, if we have a `Fees` table, we would include the `AdmissionNumber` to know which student the fee payment belongs to. In the `Fees` table, `AdmissionNumber` is a foreign key.

Here is how it works:

    STUDENTS Table                      FEES Table
    +-----------------+-----------+       +-----------+-----------------+--------+
    | AdmissionNumber | FirstName |       | PaymentID | AdmissionNumber | Amount |
    | (Primary Key)   |           |       |           | (Foreign Key)   |        |
    +-----------------+-----------+       +-----------+-----------------+--------+
    | 8001            | John      |-----\ | 1         | 8001            | 10000  |
    +-----------------+-----------+     | +-----------+-----------------+--------+
    | 8002            | Mary      |     | | 2         | 8003            | 12500  |
    +-----------------+-----------+     | +-----------+-----------------+--------+
    | 8003            | David     |-----/ | 3         | 8001            | 5000   |
    +-----------------+-----------+       +-----------+-----------------+--------+
    
    See? The AdmissionNumber links a student to all their payments!

The Librarian: Database Management System (DBMS)

So we have all this organized data. How do we actually use it? We use special software called a Database Management System (DBMS).

Think of the DBMS as the school librarian. You don't just walk into the library and take any book you want. You talk to the librarian, who helps you find, borrow, or return a book. A DBMS does the same for a database. It helps you:

• Create new tables and databases.
• Read or retrieve data (e.g., "Show me all students from Kiambu county").
• Update existing data (e.g., "Change Mary's KCPE score").
• Delete data.

Popular DBMS examples include Microsoft Access, MySQL, and Oracle. We "talk" to most of these systems using a language called SQL (Structured Query Language).

-- This simple SQL code asks the DBMS to find the names
-- of all students who scored above 400 marks.

SELECT FirstName, County 
FROM Students
WHERE KCPE_Score > 400;

A Bit of Math: Calculating Table Size

Ever wonder how much space a database takes? We can estimate it! Let's say we define the size for each field in our `Students` table.

    Field Name         Data Type        Size (Bytes)
    --------------------------------------------------
    AdmissionNumber    Integer          4
    FirstName          Text(50)         50
    County             Text(30)         30
    KCPE_Score         Integer          4
    --------------------------------------------------
    
    Step 1: Calculate the size of ONE record.
    Record Size = 4 + 50 + 30 + 4 = 88 Bytes
    
    Step 2: Calculate the total table size for, say, 500 students.
    Total Size = Record Size * Number of Records
    Total Size = 88 Bytes * 500 = 44,000 Bytes
    
    Step 3: Convert to Kilobytes (KB) (since 1 KB = 1024 Bytes).
    Total Size = 44,000 / 1024 ≈ 42.97 KB

That's a tiny table! Imagine the size of the database for all of Safaricom's customers!

You've Got This!

Sawa? We've covered a lot, but these are the absolute fundamentals. From the smallest field to the giant database, linked together with keys and managed by a DBMS, you now understand the core concepts that power the digital world around you.

Challenge for you: Besides M-Pesa and school records, what other databases do you think you interact with every day here in Kenya? Think about supermarkets, banks, or even your favourite app!