Summarizing Database Concepts

The Big Picture

A database stores organized data so applications can create, retrieve, update, and manage information. The two pages summarized here use two broad families: relational databases and non-relational databases.

Relational Databases

Organize structured data into tables made of rows and columns. Primary and foreign keys connect related tables.

Tables Keys SQL ACID

AND

Non-Relational Databases

Use flexible models such as key-value, document, column-family, and graph structures.

JSON Documents Graph Scale-out

Main idea

Relational and non-relational are not simply “old versus new.” They organize data differently and are useful for different data shapes, relationships, access patterns, integrity requirements, and scaling needs.

Relational Database Summary

The relational model separates subjects into tables and reconnects them through keys. The student example uses Students, Enrollment, and Courses.

Table

A collection of related records arranged as rows and columns.

Primary Key

Uniquely identifies a record, such as Students.StudentID.

Foreign Key

References a key in another table to create a relationship.

Referential Integrity

Protects relationships by ensuring references remain valid.

Relational Student Example

Entity

→

Table

→

Primary Key

→

Foreign Key

→

Relationship

Relational Design & Reliability

Beyond tables and keys, relational databases use normalization, indexes, SQL, and transaction properties to organize and work with data reliably.

Cardinality

Describes relationship patterns: one-to-one, one-to-many, and many-to-many.

Normalization

Reorganizes data to reduce unnecessary duplication and improve integrity. The notes illustrate 1NF, 2NF, and 3NF.

Indexes

Help the database locate matching records efficiently.

SQL

Retrieves and manipulates relational data; JOIN combines related rows using matching keys.

ACID Transaction Principles

Atomicity

All-or-nothing.

Consistency

Preserves defined rules.

Isolation

Concurrent work does not expose incomplete transactions.

Durability

Committed changes persist.

Non-Relational Database Summary

Non-relational databases use models beyond the fixed relational table structure. The summarized page focuses on four major NoSQL families.

Key-Value

A unique key retrieves an associated value. The example uses student:1002 → JSON.

Document

Stores a self-contained JSON-like document containing fields, nested objects, and arrays.

Column-Family

Organizes data around keys and related groups of columns; the teaching example groups student attributes.

Graph

Represents entities as nodes and connections as edges, such as Student — ENROLLED_IN → Course.

One Student, Four NoSQL Views

KEY-VALUE
"student:1002" → {"name":"Hafiz Iskandar","program":"Data Analytics"}

DOCUMENT
{"_id":"student-1002","name":"Hafiz Iskandar","courses":["C101","C205"]}

COLUMN-FAMILY (simplified teaching view)
studentid:[1001,1002,...]   studentname:["Alya Rahman","Hafiz Iskandar",...]

GRAPH
(Hafiz:Student) ── ENROLLED_IN ──> (C101:Course)
                └─ ENROLLED_IN ──> (C205:Course)

Relational vs Non-Relational

The comparison below brings the two concept pages together. These are broad tendencies rather than rules that every product implements identically.

Concept	Relational	Non-Relational
Core structure	Tables, rows, columns	Key-value, document, column-family, or graph
Relationships	Primary/foreign keys and joins	Embedding, application references, grouped data, or graph edges depending on model
Schema	Structured table definition	Often more flexible; depends on NoSQL model/product
Duplication	Normalization commonly reduces redundancy	Denormalization may intentionally duplicate data for access patterns
Query style	SQL and joins are central in the notes	Access style depends on the selected model
Integrity focus	Keys, constraints, referential integrity, ACID	Consistency and integrity mechanisms vary by system/design
Scaling concept	Can scale in multiple ways	The NoSQL notes emphasize horizontal scaling, partitioning and replication
Best conceptual fit	Structured relationships and integrity-sensitive data	Flexible structures, specialized access patterns, connected data, or distributed scale

Scaling, Replication & Consistency

Distributed database design introduces concepts that are especially prominent in the non-relational notes, although distributed relational systems can also use them.

Horizontal Scaling

Add more nodes or machines so workload can be distributed.

Partitioning / Sharding

Divide a dataset so different portions can live on different nodes.

Replication

Maintain copies of data on multiple nodes for availability, resilience, or read distribution.

Eventual Consistency

Replicas may temporarily differ while updates propagate, then converge later.

Important distinction

“Relational” describes a data model, while “distributed,” “replicated,” and “partitioned” describe architecture. They are not mutually exclusive categories.

Choosing a Database Model

Choose from requirements rather than from the database label alone. Use this interactive study aid to connect a workload characteristic with a likely starting point.

Interactive Model Selector

Selection questions

Consider the shape of the data, how records relate, the most important read/write patterns, required transaction and consistency behavior, expected scale, and operational constraints.

Unified Concept Map

This final map shows how the major concepts fit together before the knowledge check.

InfoTech