Back to Topics
Term 2 DA10-2

Database Design

Learning Objectives

  • Understand relational database concepts
  • Design entity-relationship diagrams (ERDs)
  • Identify appropriate data types for fields
  • Apply normalization principles to reduce redundancy

What is a Database?

A database is an organized collection of data stored electronically. A relational database stores data in tables that can be linked together.

Database Terminology

Term Definition Example
Table A collection of related data organized in rows and columns Students, Products, Orders
Record (Row) A single entry in a table One student's information
Field (Column) A single piece of data about each record StudentName, DateOfBirth
Primary Key A unique identifier for each record StudentID, ProductCode
Foreign Key A field that links to another table's primary key CustomerID in Orders table

Data Types

Each field must have a data type that defines what kind of data it can store:

Text Types

  • VARCHAR(n) - Variable text up to n characters
  • CHAR(n) - Fixed length text
  • TEXT - Long text (descriptions)

Number Types

  • INTEGER - Whole numbers
  • DECIMAL(p,s) - Numbers with decimals
  • FLOAT - Approximate decimals

Date/Time Types

  • DATE - Date only (YYYY-MM-DD)
  • TIME - Time only
  • DATETIME - Date and time together

Other Types

  • BOOLEAN - True/False
  • BLOB - Binary data (images)
  • ENUM - List of allowed values

Entity-Relationship Diagrams (ERDs)

An ERD is a visual representation of a database structure, showing:

  • Entities - Things we store data about (become tables)
  • Attributes - Properties of entities (become fields)
  • Relationships - How entities connect to each other

ERD Notation

Entity
Rectangle represents an entity (table)
Attribute
Oval represents an attribute (field)
Relates
Diamond represents a relationship

Cardinality

Cardinality describes how many records in one table relate to records in another:

  • One-to-One (1:1) - Each record in Table A relates to exactly one record in Table B
  • One-to-Many (1:M) - One record in Table A relates to many records in Table B
  • Many-to-Many (M:M) - Many records in Table A relate to many records in Table B

Common Examples:

  • 1:1 - Person → Passport (each person has one passport)
  • 1:M - Customer → Orders (one customer, many orders)
  • M:M - Students ↔ Classes (students take many classes, classes have many students)

Crow's Foot Notation

A popular way to show cardinality on ERD lines:

  • || - Exactly one (mandatory)
  • O| - Zero or one (optional)
  • |< - One or many
  • O< - Zero or many

Keys

Primary Keys

Rules for primary keys:

  • Must be unique for every record
  • Cannot be null (empty)
  • Should not change over time
  • Often an auto-incrementing number (ID)

Foreign Keys

Foreign keys create relationships between tables:

  • A foreign key in one table references the primary key in another
  • Enforces referential integrity
  • Prevents orphan records
// Example: Orders table with foreign key

Orders Table
-----------
OrderID (PK)    CustomerID (FK)    OrderDate
1               101                2024-03-15
2               102                2024-03-16
3               101                2024-03-17

// CustomerID references Customers.CustomerID

Normalization

Normalization is the process of organizing data to reduce redundancy and improve data integrity.

First Normal Form (1NF)

  • Each cell contains only one value (atomic)
  • No repeating groups of columns
  • Each row is unique (has a primary key)

Not 1NF (Bad)

StudentID | Subjects
1 | Math, Science, English

1NF (Good)

StudentID | Subject
1 | Math
1 | Science
1 | English

Second Normal Form (2NF)

  • Is in 1NF
  • All non-key fields depend on the entire primary key
  • Remove partial dependencies

Third Normal Form (3NF)

  • Is in 2NF
  • No transitive dependencies
  • Non-key fields depend only on the primary key, not other non-key fields

Database Design Process

  1. Identify entities - What things do we need to store data about?
  2. Identify attributes - What information do we need for each entity?
  3. Choose primary keys - How will we uniquely identify each record?
  4. Identify relationships - How do entities connect?
  5. Draw ERD - Visualize the structure
  6. Normalize - Remove redundancy
  7. Verify - Check the design meets requirements

Key Terminology

  • Table - A collection of related records
  • Record - A single row in a table
  • Field - A single column in a table
  • Primary Key - Unique identifier for each record
  • Foreign Key - Links one table to another
  • ERD - Entity-Relationship Diagram
  • Cardinality - The number of related records
  • Normalization - Organizing data to reduce redundancy
🏠

Project Connection

In Simpson's House...

The classroom version of Simpson's House has no database — commands are fire-and-forget. But a production smart home absolutely would. Every entity you learn to model in an ERD maps onto a real component of the system.

Entities & Attributes

Device, Room, Event — three natural entities

Device (device_id, name, type, gpio_pin), Room (room_id, name, floor), Event (event_id, device_id, command, timestamp) — a clean three-entity ERD that models the whole system.

Relationships

A Room has many Devices; a Device has many Events

The relationships are clear: one room contains many devices, and each device generates many events over time. One-to-many in both cases — straightforward to draw and implement.

Normalisation

Don't repeat the device name in every event row

A poorly designed events table might store the full device name ("Living Room LED") in every row. Normalisation says: store a device_id foreign key and look up the name when needed — less redundancy, easier to update.

Primary & Foreign Keys

device_id links Events back to Devices

Each Event row has a device_id foreign key that references the Device table's primary key. This is the exact relationship pattern you draw in an ERD — visible in a real system.

Explore the full Simpson's House project →