Para dominar la organización de datos en bases de datos relacionales, es esencial entender no solo la normalización y álgebra relacional, sino también el área temática del programa. Cada software, como el de contabilidad o los sitios de streaming, se basa en conceptos específicos del dominio en cuestión. Comprender estos conceptos es tan crucial como saber programar.
En esta lección, aprenderemos qué es la ontología, cómo describe el área temática de un programa y cómo visualiza las relaciones entre sus entidades.
Qué es la ontología
Consideremos Códica, que conoces bien. Para entender su área temática, debes identificar los conceptos clave o entidades que estructuran toda la lógica, como "curso" y "lección". Sin embargo, hay más entidades, como "programa", "prueba", "revisión de código", "estudiante" y "proyecto".
Estas entidades están relacionadas entre sí. Por ejemplo, una prueba tiene preguntas con respuestas, un programa incluye cursos, los cursos están formados por lecciones, y las lecciones se componen de teoría, pruebas y ejercicios. Estas relaciones se denominan:
Uno a muchos, one-to-many, o2m. Por ejemplo, cuando una lección solo puede estar en un curso, pero un curso contiene muchas lecciones
Uno a uno, one-to-one, o2o. Por ejemplo, en Códica se establece esta relación entre el usuario y su cuenta de GitHub
Muchos a muchos, many-to-many o m2m. Por ejemplo, cuando un curso puede ser realizado por muchos usuarios y un usuario puede realizarse muchos cursos.
Así es como se ve en un esquema:
La descripción de los objetos y sus relaciones en un área específica se llama ontología. Esta ontología es familiar para los expertos en el campo, como contadores en contabilidad o profesores en enseñanza. Sin embargo, a menudo la perciben de manera intuitiva e informal, a diferencia de los programadores.
En la práctica, los programadores, analistas de negocio o gerentes se comunican con los clientes, que pueden actuar como expertos, y construyen juntos una ontología formal. Es decir, identifican términos concretos, se ponen de acuerdo sobre lo que significan y cómo están relacionados entre sí.
Luego, utilizando el modelo ER, el programador crea el modelo de datos necesario. No necesariamente en papel o en programas especializados. A menudo, este modelo sólo existe en la cabeza y en el código.
Este modelo se convierte en el principal para el diseño de la base de datos. Cada entidad en una base de datos relacional está representada por una tabla, y las relaciones entre las entidades se implementan a través de claves externas.
Para visualizar el modelo ER, se utiliza el diagrama Entity-Relationship Diagram (ERD). Vamos a explorarlo.
¿Qué es ERD?
El modelo ER no tiene una representación gráfica, por lo que se utiliza ERD. Muchos entienden el modelo ER y ERD como lo mismo. Aunque el modelo ER puede ser representado con otras notaciones.
En ERD, cada entidad está representada por un bloque en el que se enumeran los campos. Entre los bloques se dibujan líneas que tienen algunos extremos predefinidos. Definen el tipo de relación entre las entidades:
Vamos a examinar cada tipo de relación.
Uno a muchos (one-to-many)
Uno a muchos es el tipo de relación más común. Por ejemplo, un instructor puede enseñar varios cursos:
Técnicamente, se organiza dicha relación a través de una clave externa que se añade a la entidad dependiente many / muchos.
Supongamos que tenemos dos tablas de origen:
usuarios
| id | nombre | apellidos | fecha_creación |
|---|---|---|---|
| 1 | Alejandro | Mendoza | 11.10.2005 |
| 38 | Laura | Gómez | 03.08.2000 |
| 22 | Carlos | Ramírez | 23.12.2011 |
correo
| id | id_usuario | correo |
|---|---|---|
| 1 | 1 | alejandro@gmail.com |
| 2 | 1 | mendoza@gmail.com |
| 10 | 38 | laura.gomez@yahoo.com |
| 22 | 22 | carlos.ramirez@indbox.com |
Para conocer todas las direcciones de correo que tiene el usuario con el identificador 1, debes ejecutar la siguiente consulta:
SELECT * FROM correo WHERE id_usuario = 1;
| id | id_usuario | correo |
|---|---|---|
| 1 | 1 | alejandro@gmail.com |
| 2 | 1 | mendoza@gmail.com |
Ver en DB Fiddle
Uno a uno (one-to-one)
En el esquema, tal relación se ve así:
Por ejemplo, cada país tiene una sola capital:
paises
| id | nombre | fecha_creación |
|---|---|---|
| 2 | Argentina | 11.10.2005 |
| 38 | Mexico | 03.08.2000 |
| 22 | Colombia | 23.12.2011 |
ciudades
| id | nombre | id_pais | capital | fecha_creación |
|---|---|---|---|---|
| 34 | Buenos Aires | 2 | true | 11.10.2005 |
| 33 | Guadalajara | 38 | 03.08.2000 | |
| 99 | Córdoba | 2 | 23.12.2011 | |
| 4 | Rosario | 2 | 23.12.2011 | |
| 5 | Bogotá | 22 | true | 23.12.2011 |
La relación one-to-one generalmente no existe por sí misma, sino dentro de una relación one-to-many. Es decir, cada país tiene ciudades, pero solo una de ellas es la capital.
SELECT * FROM ciudades WHERE id_pais = 38 AND capital = true;
Ver en DB Fiddle
Muchos a muchos (many-to-many)
Estas relaciones pueden ser representadas así:
Muchos a muchos es muy común. Por ejemplo, cada persona tiene múltiples amigos, cada persona es un amigo para múltiples personas. O una persona está tomando múltiples cursos, y un curso es tomado por múltiples personas.
Esta relación ya no se implementa de manera tan sencilla. Técnicamente no es posible conectar dos tablas con una relación many-to-many sin introducir una tercera tabla.
Por ejemplo, tenemos dos tablas de origen:
usuarios
| id | nombre | fecha_creación |
|---|---|---|
| 2 | Sergio | 11.10.2005 |
| 38 | Iván | 03.08.2000 |
| 22 | Víctor | 23.12.2011 |
cursos
| id | nombre | fecha_creación |
|---|---|---|
| 8 | Fundamentos de PHP | 11.10.2005 |
| 55 | Fundamentos de Python | 03.08.2000 |
| 22 | Fundamentos de Ruby | 23.12.2011 |
Esta tabla será la que enlace:
miembros_curso
| id | id_usuario | id_curso | fecha_creación |
|---|---|---|---|
| 34 | 2 | 8 | 11.10.2005 |
| 33 | 38 | 55 | 03.08.2000 |
| 99 | 22 | 22 | 23.12.2011 |
| 4 | 22 | 8 | 23.12.2011 |
| 5 | 38 | 22 | 23.12.2011 |
En la tabla miembros_curso hay una clave principal y cada entrada contiene enlaces tanto a un curso específico como a un usuario específico. En Códica, esta tabla comienza a llenarse en el momento en que el usuario presiona el botón "Unirse al curso". Se crea una entrada con su identificador y el identificador del curso que va a tomar.
Si queremos saber todos los cursos que está tomando un usuario, ejecutaríamos la siguiente consulta:
SELECT id_curso FROM miembros_curso WHERE id_usuario = 22;
Si queremos saber quién está tomando un curso determinado, ejecutaríamos la siguiente consulta:
SELECT id_usuario FROM miembros_curso WHERE id_curso = 22;
Ver en DB Fiddle
Este tipo de estructura se mantiene para cualquier par de entidades que necesitan conectarse. En general el esquema se ve así:
Existen tablas de origen A y B. Para ellas se crea una nueva tabla AB. Dentro de ella hay dos llaves extranjeras - a_id y b_id, que están conectadas a las tablas de origen.
Como muestra la práctica, esta tabla intermedia a menudo se convierte en una entidad independiente. Si hablamos de cursos, es importante saber si un usuario ha terminado el curso o no, cuándo lo hizo, cuántos ejercicios ha resuelto. Toda esta información sólo puede almacenarse en un lugar - en la tabla conectada.
Conclusiones
En esta lección, hemos visto que la ontología nos ayuda a describir el tema de un programa y a mostrar cómo se relacionan sus entidades. En las bases de datos relacionales, trabajamos con tres tipos de relaciones: uno a muchos, uno a uno y muchos a muchos. Estas relaciones se representan en el diagrama de Entidad-Relación.
Materiales adicionales
Para acceder completo a curso necesitas un plan básico
El plan básico te dará acceso completo a todos los cursos, ejercicios y lecciones de Códica, proyectos y acceso de por vida a la teoría de las lecciones completadas. La suscripción se puede cancelar en cualquier momento.
