Relational databases store data as relations (tables) with rigorously defined schemas, and they use keys, constraints, and transactions to keep data correct under concurrency. They matter because most business systems depend on predictable integrity guarantees (e.g., referential integrity, uniqueness) while still supporting high query flexibility via SQL. A useful mental model is "declare invariants + write set-based queries": let constraints enforce correctness, and let the optimizer choose efficient execution plans. When performance surprises happen, the fastest path to clarity is usually to inspect the plan (EXPLAIN) and verify the physical design (indexes, statistics, partitioning).
What This Cheat Sheet Covers
This topic spans 13 focused tables and 203 indexed concepts. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.
Table 1: Relational Foundations
| Concept | Example | Description |
|---|---|---|
A relation is a set of tuples over attributes | Formal foundation for relational databases based on relations and predicate logic. | |
Employees(emp_id, name, dept_id) | Defines relation structure: attribute names and intended meaning/constraints. | |
Atomic commit/rollback for a transaction | Transaction properties: Atomicity, Consistency, Isolation, Durability. | |
Customer β places β Order | Conceptual modeling approach for entities, attributes, and relationships. | |
Boxes=entities; lines=relationships | Diagram notation used to communicate a relational design at a high level. | |
Customer 1..* Order | Specifies relationship multiplicity (e.g., one-to-many). |