Relational model — tables, keys and constraints

The relational model, introduced by Edgar F. Codd in 1970, remains the dominant framework for organising and querying structured data. At its heart, it represents data as a collection of tables — called relations — where every row is a unique record and every column represents a typed attribute. Before the relational model, databases used hierarchical or network structures that forced developers to navigate complex pointer chains just to retrieve data.

The model's power comes from its mathematical foundation in set theory and predicate logic. Relationships between tables are expressed through keys rather than physical pointers, which means the storage layout is entirely independent of how queries are written. This separation of logical structure from physical storage is what makes relational databases so flexible — you can reorganise storage internals without rewriting application queries.

For data engineers, the relational model is foundational because every downstream tool — data warehouses, ETL pipelines, BI dashboards — ultimately reads from or writes to relational structures. Understanding tables, keys, and constraints at a deep level allows engineers to design schemas that are both efficient to query and resilient to data quality problems before they propagate into analytics.

Analogy🏏Cricket

🏏 Think of it like cricket: A SELECT query is precisely how a selection committee picks a playing XI. FROM is the full list of centrally contracted players — the raw pool. WHERE is the fitness and eligibility screen: injured or unavailable players are removed before anyone debates merit, and the fewer names that survive this screen, the faster the meeting goes — exactly why a good WHERE clause matters more than anything downstream. ORDER BY is ranking the survivors by recent form, then by experience as the tiebreaker. LIMIT 11 takes the top of that ranked list and stops. The committee never ranks the entire national player pool and then discards thousands of names — and neither should your query force the database to sort millions of rows it will immediately throw away. The order of operations is the whole game: filter first, sort what remains, take only what you need.