Introduction to Transactions, Integrity, and Normalization

Welcome! In this chapter, we are going to explore how databases stay organized, accurate, and reliable. Think of a database not just as a pile of digital filing cabinets, but as a high-security system. We need rules to make sure that when data is added or changed, nothing gets "broken" or lost. We will look at Transactions (how work gets done), Integrity (how we keep data accurate), and Normalization (how we organize data to save space and prevent errors).

Whether you are an SL or HL student, these concepts are the "Golden Rules" of the relational database world. Don't worry if it seems like a lot of technical terms at first—we'll break them down with simple analogies!

1. Database Transactions

A transaction is a single logical unit of work that involves one or more changes to a database. The classic example is a bank transfer. If you send \(\$50\) to a friend, two things must happen: \(\$50\) is taken out of your account, and \(\$50\) is added to theirs. If the system crashes halfway through, we have a big problem!

The ACID Properties

To ensure transactions are processed reliably, they must follow the ACID principle. This is a vital concept for your exams:

Atomicity: The "all or nothing" rule. Either the entire transaction happens, or none of it does. If one part fails, the whole thing is cancelled (rolled back).

Consistency: A transaction must take the database from one valid state to another. It ensures that all data follows the predefined rules (like "account balance cannot be negative").

Isolation: If multiple people are using the database at once, their transactions shouldn't interfere with each other. It’s like being in your own private bubble until your transaction is finished.

Durability: Once a transaction is "committed" (saved), it stays saved, even if the power goes out or the system crashes a second later.

Quick Review: Remember ACID as the "Safety Shield" of database operations.

2. Data Integrity

Data Integrity refers to the overall accuracy, completeness, and consistency of data. We maintain integrity by imposing sets of rules on the database. There are three main types you need to know:

Entity Integrity

This rule ensures that every row in a table is unique and identifiable.
• Every table must have a Primary Key.
• The Primary Key cannot be null (empty).

Referential Integrity

This involves the relationship between tables. It ensures that a Foreign Key in one table always points to a valid, existing Primary Key in another table.
Example: You cannot have an "Order" for "Customer ID 99" if "Customer 99" doesn't exist in your Customers table.

Domain Integrity

This defines the "domain" or the valid values allowed in a specific column.
Example: If a column is for "Age", the domain might be restricted to integers between \(0\) and \(120\). You shouldn't be able to type "Banana" into an Age field!

Did you know? Most modern database systems (RDBMS) enforce these rules automatically once you set them up, preventing users from making accidental mistakes.

3. Normalization

Normalization is a systematic way of organizing a database to reduce data redundancy (repeating the same data) and ensure data dependency (storing related data together). We do this by breaking large tables into smaller, related tables.

Why Normalize?

If we don't normalize, we run into Anomalies:
Update Anomaly: If a customer changes their address, you have to change it in fifty different order records.
Deletion Anomaly: If you delete the last order for a customer, you might accidentally delete the customer's entire contact history.
Insertion Anomaly: You might not be able to add a new product unless someone actually buys it.

The Three Stages of Normalization

First Normal Form (\(1NF\))

To be in \(1NF\), a table must:
1. Have atomic values (only one piece of data per cell—no lists!).
2. Have a unique name for each column.
3. Have a defined Primary Key.

Second Normal Form (\(2NF\))

To be in \(2NF\), a table must:
1. Already be in \(1NF\).
2. Have no partial dependencies. This means every non-key column must depend on the entire Primary Key. (This is mostly an issue when you have a composite Primary Key made of two or more columns).

Third Normal Form (\(3NF\))

To be in \(3NF\), a table must:
1. Already be in \(2NF\).
2. Have no transitive dependencies. This is a fancy way of saying that non-key columns should not depend on other non-key columns. Everything must depend only on the Primary Key.

A Great Mnemonic: "The data must depend on the key (\(1NF\)), the whole key (\(2NF\)), and nothing but the key (\(3NF\)), so help me Codd!" (E.F. Codd was the inventor of the relational model).

Summary and Key Takeaways

Don't worry if normalization feels a bit abstract at first. Just remember the goal: one fact in one place.

Transactions use ACID to keep operations safe.
Integrity uses rules (Primary Keys, Foreign Keys, Domains) to keep data accurate.
Normalization (\(1NF, 2NF, 3NF\)) organizes tables to stop data from being repeated or accidentally lost.

Note: For more information on how to link these tables together using keys, see the chapter on "Relational database design and modelling".