Hello, I'm Maneshwar. I'm working on FreeDevTools online currently building **one place for all dev tools, cheat codes, and TLDRs* — a free, open-source hub where developers can quickly find and use tools without any hassle of searching all over the internet.*
Yesterday, we looked at how applications interact with a DBMS through interaction models and declarative languages like SQL.
At that level, databases appear as collections of tables, completely abstracted from storage details.
Today, we make that abstraction explicit.
A Relational Database Management System (RDBMS) is a DBMS that implements the relational data model.
To users and applications, an RDBMS presents the database as a collection of relations (tables), each defined by a schema.
Internally, however, those relations must live inside ordinary files.
This gap between tables and files is where much of an RDBMS’s work happens.
Relations vs Files
A relation is a two-dimensional structure: rows and columns.
A file, in contrast, is one-dimensional flat sequence of bytes.
Operating systems do not understand tables, schemas, or tuples.
They only know how to read and write bytes.
As a result, an RDBMS must map logical relations onto file storage.
Users operate at the logical (conceptual) schema level:
- Tables
- Attributes
- Constraints
The RDBMS translates these operations into lower level file operations using a separate physical schema that defines how data is laid out inside files.
Crucially:
- Users never see the physical schema
- Applications are insulated from storage layout
- Internal reorganization does not break application logic
This separation is what allows databases to evolve without rewriting applications.
Schemas and Catalogs
Every relation has a schema that defines:
- Attribute names
- Data types
- Constraints
Schema information itself is stored inside the database in special relations called catalogs (also known as system tables or data dictionaries).
Catalogs store metadata such as:
- Relation names
- Column names and types
- Default values
- Constraint definitions
Together, all catalog entries define the database schema.
While applications are usually allowed to read catalogs, they cannot modify them directly. Catalogs are updated automatically by the RDBMS as a side effect of schema-changing operations like creating or altering tables.
More Than Just Tables
In addition to user relations and system catalogs, an RDBMS also maintains:
- Indexes to speed up data access
- Internal structures to support correctness and performance
All of this complexity exists so that applications can treat the database as nothing more than a clean collection of relations.
Where This Leads
At this point, we’ve established:
- What relations are
- How they are mapped onto files
- How schemas and catalogs define database structure
The next natural step is understanding how relations are manipulated.
That takes us into:
- Relational operations
- Relational algebra
- Projection, selection, joins, and set operations
Those operations form the theoretical foundation of SQL and that’s where the journey continues next.
👉 Check out: FreeDevTools
Any feedback or contributors are welcome!
It’s online, open-source, and ready for anyone to use.
⭐ Star it on GitHub: freedevtools
Top comments (0)