👉 Ver todas las notas
Una relación se crea cuando una columna de una tabla referencia a otra columna de otra tabla, la cual se conoce como Foreign Key.
👉 Una Foreign Key siempre hace referencia a la Primary Key de otra tabla o a una columna con la restricción
UNIQUE.
Necesitamos describir formalmente las relaciones entre las tablas de nuestra base de datos. La forma en que describimos las relaciones es a través de las claves (Primary Keys, Foreign Keys).
👉 Algo a tener en cuenta es que no es necesario que todas las tablas de la DB tengan relación con alguna otra.
En las relaciones 1 a 1, una entidad sólo tiene relación con otra y viceversa. Por ejemplo, un número de pasaporte puede estar asociado a una única persona y cada persona puede tener sólo 1 número de pasaporte.
Para diseñar relaciones 1 to 1, la forma más común es poner los datos en diferentes columnas de la misma tabla. Por ejemplo, si queremos relacionar un user_id con un username
| user_id | fist_name | last_name | username |
|---|---|---|---|
| 1 | Linus | Torvalds | ltorvalds |
En este caso, el user_id 1 está asociado sólo con el username ltorvalds y viceversa.
También podemos tener relaciones 1 to 1 con los datos distribuídos en 2 tablas, por ejemplo, si queremos relacionar usuarios con tarjetas de crédito, podemos hacer
| id | fist_name | last_name | card_id |
|---|---|---|---|
| 1 | Caleb | Curry | 50 |
| id | issue_date | max_ammount | user_id |
|---|---|---|---|
| 50 | 2020/03/01 | 5000 | 1 |
(en este caso, user_id es una Foreign Key que referencia al id de la tabla de usuarios)
👉 Este es el tipo de relación menos frecuente en bases de datos relacionales.
En las relaciones 1 a muchos, una entidad puede tener relaciones con 1 o más entidades (pero no a la inversa).
Por ejemplo, las siguientes tablas se encuentran relacionadas a través del customer_id. En la tabla Customer, cumple el rol de Primary Key, mientras que en la tabla Order, cumple el rol de Foreign Key.
⚠️ Notar que esto implica quecustomer_iddebe ser único en la tablaCustomer, pero no necesariamente enOrder.
| customer_id | first_name | last_name | address | |
|---|---|---|---|---|
| 367 | Michelle | Blackwell | mblackwell@... | 22 Acacia... |
| 368 | Lynn | Allen | la1942@... | 1016B 1st... |
| 369 | Lee | Stout | lee@... | 47 Main St... |
| order_id | date | quantity | total | customer_id |
|---|---|---|---|---|
| 1198 | 3/1/2011 | 17 | $340.00 | 367 |
| 1199 | 3/2/2011 | 47 | $902.00 | 367 |
| 1200 | 3/2/2011 | 104 | $1500.00 | 368 |
Este tipo de relación se conoce como 1 to many, ya que cada customer puede tener asociadas 1 o más orders.
⚠️ Notar que la inversa no es cierta, en este caso cada orden puede tener 1 (y sólo 1) cliente asociado.
👉 Este es el tipo de relación más común en bases de datos relacionales.
En las relaciones muchos a muchos, muchas entidades pueden tener relaciones con 1 o más entidades y viceversa. Por ejemplo, muchos estudiantes pueden estar cursando más de 1 asignatura y a la vez cada asignatura puede tener más de 1 estudiante anotado.
👉 En la mayoría de las bases de datos relacionales no podemos expresar relaciones many to many directamente, sino que tendremos que hacerlo indirectamente.
Por ejemplo, podemos tener una tabla de autores (authors), otra de libros (books) y relacionar los autores con los libros de forma tal que un/a autor/a pueda estar asociado a uno o más libros, es decir, una relación del tipo 1 to many.
| author_id (PK) | first_name | last_name | |
|---|---|---|---|
| 445 | Tucker | Morrison | tmorrison@... |
| 446 | Robert | Allen | rallen@... |
| 447 | Jordan | Winters | jwinters64@... |
| book_id (PK) | title | list_price | author_id (FK) |
|---|---|---|---|
| 1145 | Designing Databases | $45 | 447 |
| 1146 | PostgreSQL Made Simple | $39.95 | 446 |
| 1147 | Y U Don't Need MongoDB | $19.95 | 447 |
El problema aparece si un mismo libro puede tener varios autores, cómo representamos esa relación? No podemos asociar un libro con múltiples Foreign Keys (authorID sería una Foreign Key de la tabla books), al menos no con una única columna author_id. Una posible solución podría ser agregar una segunda columna, author_id_2 (nulleable, en el caso de que haya un único autor), como se muestra abajo, pero esta no es una práctica recomendada y lleva a un mal diseño, ya que estamos repitiendo información (columnas), por lo que vamos a intentar evitarla.
| book_id (PK) | title | list_price | author_id_1 (FK) | author_id_2 (FK) |
|---|---|---|---|---|
| 1145 | Designing Databases | $45 | 447 | 446 |
| 1146 | PostgreSQL Made Simple | $39.95 | 446 | (null) |
| 1147 | Y U Don't Need MongoDB | $19.95 | 447 | 445 |
👉 La solución para este tipo de casos entonces, suele ser agregar una tercer tabla, intermedia, que linkee (haga de enlace) entre las otras 2. [1]
| author_id (PK) | first_name | last_name | |
|---|---|---|---|
| 445 | Tucker | Morrison | tmorrison@... |
| 446 | Robert | Allen | rallen@... |
| 447 | Jordan | Winters | jwinters64@... |
| authors_books_id (PK) | author_id | book_id |
|---|---|---|
| 1 | 447 | 1145 |
| 2 | 445 | 1145 |
| 3 | 446 | 1146 |
| 4 | 447 | 1146 |
| book_id (PK) | title | list_price |
|---|---|---|
| 1145 | Designing Databases | $45 |
| 1146 | PostgreSQL Made Simple | $39.95 |
| 1147 | Y U Don't Need MongoDB | $19.95 |
Nos deshacemos de la Primary Key author_id en books.
Podemos decir entonces que ahora tenemos 2 relaciones 1 to many: 1 de authors hacia books y otra de books hacia authors.
👉 La tabla
authors_booksexiste únicamente con el fin de unirauthorsconbooksy establecer la relación.
La cardinalidad expresa cuántas entidades se relacionan con otras, es decir, es sólo un nombre para hablar de los tipos de relaciones mencionados anteriormente (1 to 1, 1 to many ó many to many).
1 Con las tablas intermedias también podemos utilizar claves compuestas (aka Composite Keys).