Databases like T-SQL are called relational databases. And they are called that because they are based on the relational model.
Which might sound silly but also makes you wonder what is the relational model?
Although alternatives have recently emerged (like NoSQL databases), relational databases remain the cornerstone of most enterprise, banking, and critical management systems.
In this article, we are going to break down what it really means for a database to be “relational” and why it is so important for us as developers.
What is the Relational Model?
The relational model was proposed by E.F. Codd in 1970 while working for IBM and has been the software industry standard for decades.
His revolutionary idea was to organize data in tables (mathematically called “relations”), instead of using hierarchical or network structures that were common at the time.
In this model, information is stored in objects called tables, which consist of rows and columns.
The great advantage of the relational model is its logical independence. We can change the database structure without necessarily altering the applications that access it, as long as we maintain the query interface.
Information Structure
To understand a relational database, we must visualize it as a set of tables that connect to each other.
The Database is the main container that groups, structures, and manages all the information of a system or application.
For example: TiendaOnlineDB, RecursosHumanosDB.
We can imagine it as the complete Excel file (the workbook) or as a large physical filing cabinet in an office.
But, in reality, it doesn’t just store data. Tables, security rules, relationships between different entities, and the internal programming of the engine coexist.
The Table is the fundamental storage object in a relational database. It is the structure where data resides.
For example: Usuarios, Productos, Facturas.
We can imagine a table as a two-dimensional grid (very similar to an Excel sheet), but much stricter.
But, in reality, each table must represent a single entity or concept of the system or your data model.
Columns represent the attributes or characteristics of the entity modeled in the table. Each column has:
- A unique name within the table (e.g.,
Nombre,Precio,FechaRegistro). - A defined data type.
You can think of them as the vertical divisions of a table. But, unlike Excel, where you put a number in one cell and write “Hello” in the one below, in a relational database the entire column must respect the data type.
If we define a column Edad as an integer (INT), T-SQL will not allow us to insert the text “Twenty” into it. This rigidity is what ensures data quality.
Each row represents a unique instance of the entity modeled by the table. They are also known as Records or Tuples.
A table can have from zero rows (empty table) to billions.
- If the table is
Productos, a row would be “24-inch Monitor, Dell brand, 150€”
You can think of them as the horizontal divisions of the table.
A Value (or data) is the exact intersection between a row and a column. It is the smallest and most atomic unit of information in our database.
You can visualize it directly as a single cell within your Excel sheet.
If we cross the row of the record “24-inch Monitor” with the column “Precio”, the specific value we find there is 150.
This isolated value has no meaning on its own, but acquires all its meaning thanks to the context of the row and column to which it belongs, and it must always comply with the data type rules dictated by its column.
The Concept of “Relationship”
What really gives power to this model is not just storing data in tables, but the ability to establish relationships between them (hence its name).
Imagine we want to save an order. Instead of writing all the customer’s data (name, address, email) every time they make a purchase, we simply save a reference to that customer.
This is achieved through two key concepts that we will explore in depth later, but which we must already know:
- Primary Key (Clave primaria): A unique identifier for each row in a table (e.g., Customer ID).
- Foreign Key (Clave Foránea): A field that points to the Primary Key of another table.
Thanks to this, we avoid data redundancy and keep information organized and efficient.
Referential Integrity
Understanding relationships leads us to a key concept in T-SQL: Referential Integrity.
The database engine monitors these relationships so we don’t make logical errors.
- If you try to create an
Orderfor aCustomerthat doesn’t exist, SQL Server will prevent it. - If you try to delete a
Customerthat already has associatedOrders, SQL Server will prevent it.
This ensures that there are no “orphaned records” in our database, maintaining information consistency.
