What Is a Relational Database? RDBMS Concepts Explained for Developers

Before writing a single SELECT statement, you need the mental model. Get this right and everything else in SQL Server clicks into place much faster — most beginner confusion later in this course traces back to a shaky version of what’s covered here.

Tables, Rows, and Columns

A relational database stores data in tables — grids of rows and columns, like a spreadsheet, except every row follows the same strict structure and tables can reference each other. SQL Server is a Relational Database Management System (RDBMS): the software that stores, protects, and lets you query that data.

• Table — a named collection of rows with the same columns (e.g. Customer)
• Row (record, or formally a tuple) — one entity: one customer, one order
• Column (field/attribute) — one property every row has: name, email
• Schema — the overall structure: which tables exist, their columns, types, and the rules connecting them

Why “Relational,” Specifically — The Math Behind the Name

The term comes from set theory: a table is mathematically a relation — a set of tuples (rows). This isn’t just trivia; it explains real SQL Server behavior. A true mathematical set has no inherent order and no duplicate members — which is exactly why a SQL table has no guaranteed row order unless you explicitly add ORDER BY, and why operations like UNION (versus UNION ALL) exist specifically to remove duplicates, echoing set semantics. Beginners who assume “the rows come back in the order I inserted them” get bitten by this constantly — SQL Server makes no such promise, ever.

How Tables Relate to Each Other

The “relational” part means tables relate to each other through shared values, not through nested/embedded structure like you’d see in a document database (MongoDB) or a spreadsheet with merged tabs. A customer_id in the Order table points back to a row in Customer — that’s a foreign key reference, formalized fully in Chapter 5. This is fundamentally different from how a NoSQL document store would model the same data (embedding the customer’s info directly inside every order document, duplicated across orders) — the relational approach trades some query complexity (you must JOIN to see combined data) for zero duplication and guaranteed consistency.

The Three Classic Relationship Shapes

You’ll build a real one-to-many relationship yourself starting in Chapter 5, and the full JOIN toolkit for querying across them right after.

OLTP vs OLAP, in More Than One Paragraph

SQL Server is usually used two ways:

• OLTP (Online Transaction Processing) — lots of small, fast reads/writes, like an e-commerce checkout or a support-ticket system. Schema is normalized (Chapter 6) to avoid duplicate/inconsistent data, since data changes constantly.
• OLAP (Online Analytical Processing) — fewer, much heavier queries that aggregate huge amounts of history for reporting and dashboards. Schemas here are often deliberately denormalized for read speed, since the data is mostly historical and rarely changes.

Beginners almost always start with OLTP-style querying and design, which is the foundation either way — you can’t design a good reporting schema until you understand why the transactional schema it’s summarizing looks the way it does.