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
These are the bedrock ideas every relational system rests on — Codd's relational model, the entity–relationship thinking that precedes a schema, and the transaction guarantees (ACID) that let many users write at once without corrupting each other's data. Functional dependencies and Armstrong's axioms are the theory behind good normalization, and three-valued logic explains why NULL so often surprises people. Get comfortable here and the rest of the sheet stops feeling like a pile of disconnected syntax.
| 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). |