Llegó el momento de comenzar a diseñar nuestra propia base de datos relacional.
Hasta ahora, en esta serie aprendimos qué es una base de datos, conocimos diferentes modelos, estudiamos el modelo relacional y vimos por qué la normalización nos ayuda a evitar redundancias y problemas al organizar la información.
Pero antes de abrir MariaDB, MySQL o phpMyAdmin y comenzar a crear tablas necesitamos responder algo mucho más importante:
¿Qué información necesita realmente nuestra aplicación y cómo se relacionan esos datos entre sí?
Para responder esta pregunta vamos a aprender a crear un Diagrama Entidad Relación, normalmente abreviado como DER o ERD por Entity-Relationship Diagram.
Un DER nos permite pensar primero en el problema y representar visualmente sus elementos antes de preocuparnos por tablas, tipos de datos o sentencias SQL.
Y esta vez no nos quedaremos solamente con la teoría. A partir de este capítulo comenzaremos un pequeño proyecto que irá evolucionando durante los próximos tutoriales: una aplicación de usuarios y películas.
- Qué es un Diagrama Entidad Relación (DER).
- Qué diferencia existe entre diseño conceptual, lógico y físico.
- Qué son las entidades.
- Qué son los atributos y qué tipos podemos encontrar.
- Para qué sirven las claves.
- Cómo identificar relaciones entre entidades.
- Qué significa la cardinalidad.
- Cómo interpretar relaciones 1:1, 1:N y N:M.
- Qué son las entidades asociativas.
- Cómo leer un DER.
- Cómo crear el primer modelo conceptual de nuestra aplicación de películas.
Las 3 etapas del diseño de una base de datos
Diseñar una base de datos no consiste simplemente en abrir un gestor y comenzar a crear tablas hasta que algo funcione.
Antes de implementar nuestra base de datos necesitamos comprender qué problema queremos resolver, qué información necesitamos almacenar y qué relaciones existen entre esos datos.
Para controlar mejor esa complejidad podemos dividir el diseño en tres grandes etapas.
| Etapa | Pregunta principal | Resultado |
|---|---|---|
| Diseño conceptual | ¿Qué información existe y cómo se relaciona? | Modelo o Diagrama Entidad-Relación |
| Diseño lógico | ¿Cómo organizamos esos conceptos en el modelo relacional? | Tablas, columnas, PK, FK y restricciones |
| Diseño físico | ¿Cómo implementamos realmente esa estructura? | Base de datos funcionando en un SGBD |
En este tutorial nos encontramos principalmente en la primera etapa: el diseño conceptual.
Todavía no nos interesa demasiado si una columna será VARCHAR, INT o qué sentencia SQL tendremos que escribir.
Primero necesitamos comprender el problema.
Podemos pensar el DER como uno de los planos de nuestra base de datos. Primero representamos qué necesitamos y cómo se relaciona. Después transformaremos ese diseño en una estructura relacional y finalmente la implementaremos.
¿Qué es un Diagrama Entidad Relación o DER?
Un Diagrama Entidad-Relación es una representación visual de los elementos importantes de un sistema y de las relaciones que existen entre ellos.
Estos elementos pueden representar personas, objetos, acontecimientos o conceptos sobre los que necesitamos almacenar información.
Por ejemplo, imaginemos que queremos desarrollar una aplicación donde diferentes usuarios puedan consultar películas y guardar sus favoritas.
Sin crear todavía ninguna tabla podemos reconocer dos conceptos importantes:
USUARIO PELÍCULA
También podemos reconocer una relación:
Un USUARIO puede guardar una PELÍCULA como favorita.
Ya comenzamos a modelar nuestro problema.
Lo interesante es que podemos hacerlo sin haber decidido todavía cómo será implementada la base de datos.
Partes de un Diagrama Entidad Relación
Para comprender un DER necesitamos conocer algunos conceptos fundamentales: entidades, atributos, claves, relaciones y cardinalidad.
Vamos a estudiarlos por separado antes de reunirlos en nuestro primer diagrama.
Entidades
Una entidad representa algo relevante para nuestro sistema sobre lo que necesitamos almacenar información. Puede tratarse de una persona, un objeto, un lugar, un evento o incluso un concepto que tenga importancia dentro del problema que estamos modelando.
Podemos pensar una entidad como una categoría de elementos que comparten determinadas características. Por ejemplo, en una aplicación de películas podemos identificar entidades como Usuario, Película o Género. Cada una representa un concepto diferente sobre el que necesitaremos registrar y relacionar información.
Una buena forma de detectar posibles entidades es preguntarnos: “¿Sobre qué cosas necesita guardar información nuestra aplicación?”. Las respuestas suelen convertirse en los primeros candidatos a entidades de nuestro modelo.
Puede tratarse de una persona:
Usuario Cliente Profesor
Puede ser un objeto:
Película Producto Vehículo
O incluso un concepto importante dentro del sistema:
Pedido Reserva Inscripción
En nuestra aplicación comenzaremos identificando tres entidades:
Usuario Película Género
Por ahora no estamos diciendo que sean tablas. Estamos identificando los conceptos que forman parte del problema.
Entidad e instancia no son exactamente lo mismo
Cuando hablamos de Usuario estamos describiendo un tipo de entidad.
Pero dentro de nuestra aplicación existirán usuarios concretos.
Por ejemplo:
Usuario id: 1 nombre: Ana email: ana@ejemplo.com Usuario id: 2 nombre: Lucas email: lucas@ejemplo.com
Ambos representan elementos concretos pertenecientes al mismo tipo de entidad.
Esta diferencia nos ayuda a comprender por qué definimos una estructura común y después almacenamos múltiples elementos que respetan esa estructura.
Entidades fuertes, débiles y asociativas
Al estudiar modelos Entidad Relación también podemos encontrarnos con diferentes categorías de entidades.
Una entidad fuerte puede identificarse mediante sus propios atributos y no necesita depender de otra entidad para existir dentro del modelo.
Por ejemplo, Usuario o Película pueden tener su propio identificador.
Una entidad débil, en cambio, depende de otra entidad para poder identificarse o tener sentido dentro del sistema.
También existen las llamadas entidades asociativas, especialmente útiles cuando necesitamos representar una relación que adquiere información propia.
Esto último será muy interesante para nuestro proyecto.
Tenemos:
USUARIO <-> PELÍCULA
Y necesitamos registrar qué películas guarda cada usuario como favoritas.
Más adelante podremos representar esa asociación mediante algo como:
FAVORITO usuario película fecha
Por ahora alcanza con comprender la idea. En el siguiente tutorial veremos cómo estas decisiones terminan afectando realmente al diseño de nuestra base de datos.
¿Qué son los atributos?
Los atributos son las características, propiedades o datos que utilizamos para describir una entidad. Mientras que una entidad representa aquello sobre lo que queremos guardar información, sus atributos indican qué información concreta necesitamos conocer sobre ella.
Por ejemplo, si tenemos una entidad llamada Usuario, podemos describirla mediante atributos como su id, nombre y email. Del mismo modo, una entidad Película podría tener atributos como titulo y descripcion.
Podemos pensarlo de una manera sencilla: la entidad responde a la pregunta “¿sobre qué queremos guardar información?” y los atributos responden “¿qué queremos saber sobre esa entidad?”.
Cada atributo representa entonces una parte determinada de la información que describe a la entidad. Cuando posteriormente llevemos nuestro diseño conceptual al modelo relacional, muchos de estos atributos terminarán convirtiéndose en las columnas de nuestras tablas. Por ahora, sin embargo, lo importante es identificarlos correctamente sin preocuparnos todavía por cómo serán implementados en SQL.
USUARIO id nombre email
Para una película:
PELÍCULA id titulo anio descripcion
Y para un género:
GÉNERO id nombre
Los atributos responden preguntas sobre la entidad.
¿Cómo identificamos al usuario? ¿Cómo se llama? ¿Cuál es su email? ¿Cuál es el título de la película? ¿En qué año se estrenó?
Tipos de atributos
Durante el diseño conceptual podemos encontrarnos con distintos tipos de atributos.
Un atributo simple contiene un valor que tratamos como una unidad.
titulo email anio
Un atributo compuesto puede dividirse conceptualmente en otras partes.
Por ejemplo, una dirección podría estar formada por:
DIRECCIÓN calle numero ciudad codigo_postal
También existen atributos derivados, cuyo valor puede calcularse a partir de otra información.
Un ejemplo clásico sería la edad de una persona. Si almacenamos su fecha de nacimiento, la edad puede calcularse a partir de esa fecha en lugar de almacenarse como un valor independiente que tendremos que actualizar constantemente.
Durante el diseño conviene preguntarnos si un dato necesita almacenarse realmente o si puede obtenerse a partir de otros datos. Este tipo de decisiones ayuda a mantener modelos más coherentes.
Claves: cómo identificar cada elemento
Una clave es uno o varios atributos que utilizamos para identificar un elemento dentro de un conjunto de datos y poder distinguirlo de los demás.
Su función es evitar ambigüedades cuando diferentes elementos pueden compartir características similares, como un nombre, una fecha o una descripción.
En una base de datos podemos encontrar diferentes tipos de claves. Algunas permiten identificar un registro de forma única, mientras que otras sirven para establecer relaciones entre distintas entidades.
Más adelante conoceremos las claves primarias y foráneas y veremos cómo participan en el modelo relacional.
Supongamos que nuestra aplicación tiene dos usuarios llamados exactamente igual.
Mariano Mariano
El nombre no alcanza para saber a cuál de los dos nos estamos refiriendo.
Necesitamos algún valor que permita identificar inequívocamente cada elemento.
Por eso podemos utilizar un identificador:
id: 1 nombre: Mariano id: 2 nombre: Mariano
Ahora sí podemos distinguirlos sin ninguna ambigüedad.
Clave primaria
Una clave primaria, también llamada Primary Key o PK, identifica de forma única cada registro.
En nuestros ejemplos utilizaremos normalmente un atributo id:
USUARIO PK id nombre email
Ya estudiamos las claves con mayor profundidad en nuestro tutorial sobre el Modelo Relacional de Bases de Datos.
Utilizar un identificador propio hace que nuestro ejemplo sea más sencillo y evita depender de nombres, emails u otros datos que podrían cambiar o no resultar adecuados como identificador principal.
Relaciones entre entidades
Las entidades de una aplicación rara vez viven completamente aisladas. En la mayoría de los sistemas, los datos tienen sentido precisamente porque podemos establecer conexiones entre ellos. En un Diagrama Entidad-Relación estas conexiones reciben el nombre de relaciones.
Una relación representa una asociación que existe entre dos o más entidades dentro del problema que estamos modelando. Nos permite expresar cómo participa una entidad con otra y, sobre todo, representar una regla del mundo real o del funcionamiento de nuestra aplicación.
Por ejemplo, tener las entidades Usuario y Película nos dice qué información queremos almacenar, pero todavía no explica qué tienen que ver entre sí.
Cuando establecemos la siguiente regla:
Un usuario puede guardar una película como favorita.
acabamos de descubrir una relación entre ambas entidades:
USUARIO -- guarda como favorita --> PELÍCULA
Lo mismo sucede con nuestras entidades Género y Película. Si nuestro requisito establece que las películas deben clasificarse por género, podemos expresar otra relación:
GÉNERO -- clasifica --> PELÍCULA
Fijate que las palabras utilizadas para describir una relación suelen ser verbos o expresiones que indican una acción o asociación: un usuario realiza un pedido, un alumno cursa una materia, un autor escribe un libro o un cliente realiza una reserva.
Por eso, una buena forma de descubrir relaciones mientras diseñamos una base de datos es intentar construir frases entre nuestras entidades. Si la frase representa una regla válida del sistema, probablemente hayamos encontrado una relación que debemos analizar.
Las entidades nos indican sobre qué elementos necesitamos almacenar información. Las relaciones explican cómo esos elementos se conectan o interactúan dentro del sistema.
Pero todavía nos falta una pregunta fundamental: ¿cuántos elementos pueden participar en cada relación? Para responderla necesitamos estudiar la cardinalidad.
¿Qué es la cardinalidad?
Una vez que identificamos una relación entre dos entidades aparece una nueva pregunta: ¿cuántos elementos de una entidad pueden relacionarse con los elementos de la otra?
A esta propiedad la llamamos cardinalidad. Y expresa la cantidad de elementos o instancias que pueden participar en una relación y nos permite representar con mayor precisión las reglas que debe cumplir nuestro sistema.
Por ejemplo, saber que existe una relación entre Género y Película no es suficiente. También necesitamos conocer si un género puede estar relacionado con una sola película o con muchas. Del mismo modo, debemos preguntarnos si una película puede pertenecer a un único género o a varios.
La cardinalidad nos ayuda precisamente a responder este tipo de preguntas. No describe simplemente que dos entidades están conectadas, sino que establece los límites de esa conexión.
Para determinar correctamente una cardinalidad conviene analizar la relación en ambos sentidos. Podemos preguntarnos:
- ¿Con cuántos elementos de B puede relacionarse un elemento de A?
- ¿Con cuántos elementos de A puede relacionarse un elemento de B?
Supongamos que tenemos las entidades Usuario y Película. Si solamente pensamos que un usuario puede guardar muchas películas, todavía nos falta analizar la otra dirección. Una misma película también puede ser guardada como favorita por muchos usuarios. Al analizar ambos sentidos descubrimos que estamos ante una relación muchos a muchos.
Estas reglas no son universales: dependen de los requisitos de nuestra aplicación. Un mismo conjunto de entidades podría tener cardinalidades diferentes en otro sistema si sus reglas de negocio fueran distintas.
Cuando analices una relación, hacete siempre dos preguntas:
1. Para un elemento de la primera entidad, ¿cuántos elementos de la segunda pueden existir?
2. Para un elemento de la segunda entidad, ¿cuántos elementos de la primera pueden existir?
Responder ambas preguntas nos permitirá reconocer las tres cardinalidades básicas que veremos a continuación: 1:1, 1:N y N:M.
Relación uno a uno: 1:1
En una relación uno a uno, un elemento de una entidad se relaciona como máximo con un elemento de la otra entidad según las reglas establecidas por nuestro sistema.
A 1 ----- 1 B
Relación uno a muchos: 1:N
En una relación uno a muchos, un elemento de una entidad puede relacionarse con varios elementos de otra.
En nuestro ejemplo decidiremos inicialmente que cada película tendrá un género principal:
GÉNERO 1 ----- N PELÍCULA
Un género puede contener muchas películas, mientras que cada película pertenecerá inicialmente a un género principal.
Relación muchos a muchos: N:M
En una relación muchos a muchos, múltiples elementos de una entidad pueden relacionarse con múltiples elementos de la otra.
Nuestra relación entre usuarios y películas favoritas es un ejemplo perfecto.
Un usuario puede guardar muchas películas:
Ana - Matrix - Alien - Terminator
Pero Matrix también puede ser favorita de Ana, Lucas, Pedro y miles de usuarios.
Por lo tanto:
USUARIO N ----- M PELÍCULA
Tenemos una relación N:M.
Cuando transformemos este modelo conceptual en un modelo relacional veremos que las relaciones muchos a muchos requieren un tratamiento especial.
En nuestro proyecto aparecerá una estructura intermedia que relacionará usuarios con películas. Pero no nos adelantemos: eso pertenece al siguiente paso del diseño.
Cardinalidad y participación: ¿es obligatorio relacionarse?
Existe otra pregunta que podemos hacer mientras analizamos una relación:
¿La relación es obligatoria o puede no existir?
Imaginemos que un usuario acaba de registrarse.
¿Está obligado a tener una película favorita?
No necesariamente.
Puede registrarse y todavía no haber guardado ninguna.
Esto nos lleva a expresiones que podemos encontrar en diferentes herramientas de modelado:
- 0..1: cero o uno.
- 1..1: exactamente uno.
- 0..N: cero, uno o muchos.
- 1..N: uno o muchos.
Por ejemplo, podríamos decir que un usuario puede tener:
0..N películas favoritas
Porque un usuario nuevo puede no tener ninguna, pero posteriormente puede guardar muchas.
No necesitamos memorizar todas las notaciones ahora. Lo importante es comenzar a hacernos esta pregunta cuando diseñamos:
¿Cuántos pueden existir y es obligatorio que exista alguno?
¿Cómo leer un Diagrama Entidad Relación?
Un DER puede parecer complicado cuando lo vemos por primera vez, pero resulta mucho más sencillo si intentamos leerlo como una frase.
Por ejemplo:
GÉNERO 1 ----- N PELÍCULA
Podemos leerlo así:
Un género puede clasificar muchas películas y cada película pertenece, en nuestro modelo inicial, a un género principal.
Siempre entonces entendemos que una película tendrá 1 solo genero, pero que cada genero tendrá muchas películas. ¿Si lo entiendes verdad?. Estas formas nos ayudan a definir también los «limites» de las relaciones entre los datos que se convertirán en información.
Ahora observemos:
USUARIO N ----- M PELÍCULA
Podemos leerlo:
Un usuario puede guardar muchas películas como favoritas y una película puede ser favorita de muchos usuarios.
-Es una relación de muchos a muchos, básicamente cualquier usuario puede tener cualquier película y cualquier película es añadida por diferentes usuarios.
Esta técnica es muy útil.
Si somos capaces de transformar una relación gráfica en una frase comprensible, estamos comenzando a entender el modelo.
La notación puede cambiar dependiendo metodología o herramienta
Lo siento pero vaya título me he puesto. No todos los diagramas Entidad Relación tienen exactamente el mismo aspecto.
Dependiendo de la metodología o herramienta podemos encontrar rectángulos, líneas, rombos, símbolos especiales o la conocida notación de pata de cuervo (Crow’s Foot). Que en este caso expresa las «relaciones» utilizando una notación de Lineas terminadas en el tipo de relación en este caso cuando se trata de esta especie de «patita» de gallo o de cuervo o de cualquier bendito pájaro significa a «muchos» así pudiendo tener relación de 1 a muchos ejemplificado con líneas el tipo de relación y su «cardinalidad», ve por ejemplo un diagrama de este estilo:
Por eso no conviene obsesionarse al principio con memorizar cada símbolo posible. La idea de estos diagramas y las aplicaciones que nos ayudan a crearlos es facilitarnos la lectura y organización de nuestro modelo de bases de datos aún incluso cuando trabajemos con modelos enormes.x]Lo verdaderamente importante es poder reconocer:
- qué entidades existen;
- qué atributos poseen;
- cómo se identifican;
- qué entidades están relacionadas;
- y qué cardinalidad tiene cada relación.
Cuando utilicemos una herramienta para dibujar nuestro modelo veremos una notación concreta y aprenderemos a interpretarla sobre el propio ejercicio. Pero si quieres mirar algunas te dejo las principales herramientas de software utilizadas para diagramar bases de datos y relaciones:
Caso práctico diagrama entidad relación: aplicación de películas
Ya conocemos los elementos básicos de un DER. Ahora vamos a reunirlos en nuestro primer ejemplo.
Supongamos que recibimos el siguiente requisito:
Queremos desarrollar una aplicación donde los usuarios puedan consultar películas, conocer su género y guardar películas en una lista de favoritos.
Todavía no sabemos cómo será la interfaz, qué framework utilizaremos ni qué tablas tendremos.
Eso no importa todavía.
Estamos en la etapa de diseño conceptual.
1. Identificamos las entidades
Del requisito podemos extraer inicialmente:
Usuario Película Género
También aparece el concepto Favorito, que representa la asociación entre un usuario y una película.
2. Identificamos los atributos
Para comenzar no necesitamos veinte atributos por entidad. Podemos crear un modelo mínimo:
USUARIO PK id nombre email PELÍCULA PK id titulo anio descripcion GÉNERO PK id nombre
Más adelante nuestra aplicación podría almacenar director, duración, país, idioma, portada, puntuación, fecha de registro y muchos otros datos.
Pero agregar información porque sí no mejora un modelo.
Primero diseñamos aquello que realmente necesitamos.
3. Identificamos las relaciones
Ahora expresamos las reglas utilizando frases sencillas:
- Un Usuario puede guardar muchas Películas como favoritas.
- Una Película puede ser favorita de muchos Usuarios.
- Un Género puede clasificar muchas Películas.
- Para este primer modelo, cada Película tendrá un género principal.
4. Establecemos la cardinalidad
De nuestras reglas podemos deducir:
USUARIO <-> PELÍCULA N:M GÉNERO -> PELÍCULA 1:N
Ya tenemos prácticamente toda la información necesaria para crear nuestro primer diagrama.
No existe un único DER universal para una aplicación de películas.
Nosotros decidimos que inicialmente una película tendrá un género principal para mantener sencillo el ejercicio. Si mañana el requisito cambia y una película puede pertenecer a varios géneros, tendremos que revisar esa relación.
Cuando cambian los requisitos, puede cambiar el modelo.
Nuestro primer Diagrama Entidad Relación
Ahora sí podemos representar visualmente nuestro análisis.
Este diagrama nos permite comprender de un vistazo los elementos fundamentales de nuestro sistema.
Tenemos Usuario, Película y Género como entidades principales.
Sabemos qué atributos básicos necesitamos y qué atributo utilizaremos para identificar cada entidad.
También sabemos que existe una relación muchos a muchos entre usuarios y películas favoritas y una relación uno a muchos entre géneros y películas.
erDiagram
USUARIO {
int id
string nombre
string email
date fecha_registro
}
PELICULA {
int id
string titulo
int anio
string descripcion
}
GENERO {
int id
string nombre
}
RESENA {
int id
int puntuacion
string comentario
date fecha
}
USUARIO ||..o{ RESENA : escribe
PELICULA ||..o{ RESENA : recibe
GENERO ||..o{ PELICULA : clasifica
USUARIO }o..o{ PELICULA : favoritaAhora podemos intentar leer el diagrama como si estuviera formado por frases. No hace falta memorizar todos sus símbolos de inmediato: lo importante es aprender a interpretar qué regla está representando cada conexión.
Comencemos por Género y Película. Podemos leer esta relación de la siguiente manera: “Un género puede clasificar varias películas, mientras que cada película pertenece a un género principal”. Estamos representando una relación uno a muchos (1:N).
Ahora observemos Usuario y Película. Un usuario puede tener muchas películas favoritas y, al mismo tiempo, una misma película puede ser favorita de muchos usuarios. Por lo tanto podemos leer: “Muchos usuarios pueden guardar muchas películas como favoritas”. Esta es una relación muchos a muchos (N:M).
También encontramos la entidad Reseña. Un usuario puede escribir varias reseñas y una película puede recibir varias reseñas. Sin embargo, cada reseña concreta corresponde a un usuario y a una película determinada. De esta manera podemos representar información adicional como su puntuación, comentario y fecha.
Cuando encuentres un Diagrama Entidad-Relación, no intentes interpretarlo todo al mismo tiempo. Elegí dos entidades conectadas y tratá de convertir su relación en una frase:
“Un género clasifica muchas películas.”
“Una película puede recibir muchas reseñas.”
“Un usuario puede guardar muchas películas y una película puede ser favorita de muchos usuarios.”
Si podemos expresar correctamente esas reglas utilizando palabras, estamos empezando a leer el modelo en lugar de simplemente observarlo.
Ahora estamos comprendiendo qué queremos construir antes de construirlo. Un diagrama como este que ves arriba se genera con el siguiente código:
erDiagram
USUARIO {
int id
string nombre
string email
date fecha_registro
}
PELICULA {
int id
string titulo
int anio
string descripcion
}
GENERO {
int id
string nombre
}
RESENA {
int id
int puntuacion
string comentario
date fecha
}
USUARIO ||..o{ RESENA : escribe
PELICULA ||..o{ RESENA : recibe
GENERO ||..o{ PELICULA : clasifica
USUARIO }o..o{ PELICULA : favorita
Para mostrarlo con una herramienta que te invito a investigar, e igualmente lo haremos más adelante llamada: Mermaid y nos ayudará a crear todo tipo de diagramas cuando lo necesitemos.
Evita estos errores al diseñar tu Diagrama Entidad-Relación
Crear un Diagrama Entidad-Relación no consiste solamente en dibujar entidades y conectarlas mediante líneas. El objetivo es conseguir que el modelo represente correctamente las reglas y necesidades reales del sistema que queremos construir.
Antes de considerar terminado un DER conviene detenerse unos minutos y revisar nuestra lógica. La siguiente checklist puede ayudarte a detectar algunos de los errores más habituales durante el diseño conceptual de una base de datos.
☐ ¿Cada entidad representa realmente algo importante para el sistema?
No crees entidades simplemente porque un concepto aparece mencionado en los requisitos. Una entidad debería representar algo sobre lo que necesitamos almacenar información o establecer relaciones.
☐ ¿Estoy confundiendo una entidad con un atributo?
Preguntate si el concepto necesita información propia o si simplemente describe a otra entidad. Por ejemplo, titulo puede ser un atributo de Película; no necesitamos crear una entidad Título solamente para almacenarlo.
☐ ¿Cada entidad tiene atributos que la describen?
Una entidad debería contener las características necesarias para representar aquello que nos interesa del sistema. No hace falta agregar todos los datos imaginables: solamente aquellos que tengan sentido según nuestros requisitos.
☐ ¿Puedo identificar cada elemento de forma única?
Dos usuarios podrían llamarse Mariano o dos películas podrían compartir un título similar. Pensá qué atributo permitirá distinguir cada instancia sin depender de datos que pueden repetirse.
☐ ¿Las relaciones representan reglas reales del sistema?
No conectes entidades solamente porque parecen relacionadas. Intentá expresar cada conexión mediante una frase: “un usuario escribe una reseña”, “un género clasifica películas” o “un usuario guarda películas como favoritas”.
☐ ¿Analicé cada relación en ambos sentidos?
No alcanza con preguntar cuántas películas puede guardar un usuario. También debemos preguntarnos cuántos usuarios pueden guardar una misma película. Analizar ambos sentidos nos ayuda a descubrir correctamente la cardinalidad.
☐ ¿Definí la cardinalidad de las relaciones?
Una línea entre Usuario y Película solamente nos indica que existe alguna relación. Todavía necesitamos saber si se trata de 1:1, 1:N o N:M.
☐ ¿Consideré si la participación es obligatoria u opcional?
Preguntate si una instancia puede existir sin participar en determinada relación. Por ejemplo, un usuario recién registrado podría existir aunque todavía no haya guardado ninguna película como favorita.
☐ ¿Estoy diseñando el problema o copiando una pantalla?
Los formularios, botones y páginas de una aplicación pueden cambiar. El DER debe representar los conceptos y reglas del dominio, no simplemente reproducir los campos que aparecen actualmente en una interfaz.
☐ ¿Estoy intentando convertir todo en tablas demasiado pronto?
En el diseño conceptual todavía queremos comprender qué información existe y cómo se relaciona. Las claves foráneas, tablas intermedias y demás decisiones del modelo relacional tendrán su momento.
☐ ¿El modelo es tan complejo como necesita ser, pero no más?
Agregar entidades y relaciones innecesarias no convierte nuestro diseño en uno más profesional. Un buen modelo intenta representar el problema de la forma más clara posible.
Una técnica sencilla consiste en recorrer el diagrama de izquierda a derecha e intentar explicar cada entidad y cada relación utilizando lenguaje cotidiano. Si encontramos una conexión que no sabemos justificar, una cardinalidad que no podemos explicar o una entidad cuya función no está clara, probablemente haya algo que debamos revisar.
Y tampoco debemos preocuparnos si nuestro primer DER no es perfecto. El diseño de una base de datos es un proceso iterativo: a medida que entendemos mejor los requisitos podemos descubrir nuevas entidades, eliminar otras o modificar las relaciones que habíamos planteado inicialmente.
¿Por qué diseñar antes de programar?
En un proyecto pequeño puede resultar tentador comenzar directamente creando tablas y escribiendo código.
Pero una aplicación puede crecer rápidamente.
Hoy tenemos solo usuarios y películas en una aplicación pensada de forma sencilla, básica.
Mañana podemos tener: valoraciones; listas personalizadas; comentarios; imágenes; directores; actores; recursos externos; permisos; historial de actividad y vaya a saber cuanto más.
Si comprendemos correctamente las entidades y relaciones fundamentales resulta mucho más sencillo hacer evolucionar el sistema. Y no te compliques demasiado, mis primeros diagramas eran solo papel, boli, tablas y flechas con texto.
Siempre recuerda es preferible comenzar simple, pero con la mira en que pueda desarrollarse más complejo, no hace falta un superdiagrama en Paint 3D que te lleve 20 minutos:
Además, un DER nos permite comunicar el diseño sin necesidad de explicar cientos de líneas de Python o SQL.
Muchísimo.
Más adelante Python tendrá que consultar, crear y modificar estos datos. Incluso podremos representar conceptos del dominio mediante objetos y conectar nuestras aplicaciones con MariaDB.
Cuando avancemos en el Módulo 3 y trabajemos con Flask, estos conocimientos también nos permitirán entender mucho mejor de dónde salen los modelos y relaciones de una aplicación web.
Del problema al DER: resumen de lo aprendido
En este capítulo dimos uno de los primeros pasos importantes en el diseño de una base de datos: dejamos de pensar solamente en datos aislados y comenzamos a representar qué elementos existen en nuestro sistema, qué información necesitamos conocer sobre ellos y cómo se relacionan entre sí.
Partimos de un problema del mundo real y fuimos transformándolo progresivamente hasta obtener un Diagrama Entidad-Relación (DER). Ese proceso puede resumirse mediante la siguiente checklist:
🔎 1. Comprender el problema
Antes de dibujar cualquier cosa debemos entender qué necesita hacer nuestro sistema y qué información necesita conservar.
🧩 2. Identificar las entidades
Buscamos los elementos importantes sobre los que necesitamos almacenar información: usuarios, películas, géneros, reseñas, productos, clientes, pedidos, etc.
📝 3. Identificar los atributos
Definimos qué necesitamos conocer sobre cada entidad. Un usuario puede tener nombre y email; una película puede tener título, año y descripción.
🔑 4. Pensar cómo identificar cada elemento
Necesitamos poder distinguir una instancia de otra, incluso cuando algunos de sus datos puedan repetirse.
🔗 5. Descubrir las relaciones
Analizamos cómo interactúan nuestras entidades y tratamos de expresar esas conexiones mediante frases: “un usuario escribe una reseña” o “un género clasifica películas”.
↔️ 6. Analizar las relaciones en ambos sentidos
No preguntamos solamente cuántas películas puede guardar un usuario. También analizamos cuántos usuarios pueden guardar una misma película.
📐 7. Definir la cardinalidad
Determinamos si cada relación es 1:1, 1:N o N:M y analizamos cuándo la participación puede ser obligatoria u opcional.
🧠 8. Comprobar las reglas del sistema
Intentamos leer nuestro modelo utilizando lenguaje cotidiano. Si podemos explicar cada relación mediante una regla comprensible, estamos mucho más cerca de representar correctamente el problema.
🗺️ 9. Representar el modelo mediante un DER
Finalmente reunimos entidades, atributos, relaciones y cardinalidades dentro de una representación visual que nos permite comprender el sistema antes de comenzar a implementarlo.
Este procedimiento es mucho más importante que aprender de memoria dónde colocar un rectángulo, un rombo o qué símbolo utiliza una determinada aplicación de diagramación. Las notaciones pueden cambiar y las herramientas también.
El verdadero objetivo es desarrollar la capacidad de convertir un problema del mundo real en un modelo que podamos explicar, revisar y posteriormente implementar.
Si observás nuestro ejemplo de películas y podés decir frases como “un género puede clasificar muchas películas”, “un usuario puede escribir varias reseñas” o “muchos usuarios pueden guardar muchas películas como favoritas”, entonces ya no estás simplemente mirando un diagrama: estás comenzando a leer un modelo de datos.
Herramientas para crear Diagramas Entidad-Relación
No existe una única aplicación obligatoria para crear un DER. Podemos comenzar incluso utilizando papel y lápiz mientras intentamos comprender el problema y posteriormente trasladar nuestro diseño a una herramienta digital.
Estas son tres opciones interesantes para practicar y compartir este tipo de diagramas:
| Herramienta | Ideal para | Características |
|---|---|---|
| Mermaid | Diagramas mediante código | Permite describir diagramas utilizando texto, modificarlos fácilmente y renderizarlos como gráficos. También dispone de un editor online para practicar. |
| Lucidchart | Diseño visual | Incluye formas y plantillas específicas para diagramas ER, cardinalidades y herramientas visuales para construir y compartir diagramas. |
| dbdiagram.io | Diseño de bases de datos mediante código | Permite describir esquemas utilizando DBML o SQL, generar automáticamente el diagrama y compartirlo mediante enlaces. |
A partir de ahora será normal encontrar diagramas dentro de los tutoriales de Pythones. Los utilizaremos para representar bases de datos, arquitectura de aplicaciones, relaciones entre componentes, flujos y otros conceptos que resultan más fáciles de comprender visualmente.
Algunos estarán creados mediante Mermaid. Esto nos permite mantener el diagrama como código y modificarlo a medida que nuestros proyectos evolucionan, en lugar de depender únicamente de una imagen estática.
¿Qué viene después del DER?
Ya tenemos nuestro primer modelo conceptual y conocemos las piezas fundamentales de un Diagrama Entidad-Relación. Sin embargo, todavía no hemos construido realmente nuestra base de datos.
Nuestro modelo todavía debe responder preguntas importantes:
- ¿Cómo pasamos de los requisitos de una aplicación a un diseño completo?
- ¿Cómo comprobamos que no olvidamos entidades o relaciones importantes?
- ¿Qué sucede cuando aparecen nuevos requisitos?
- ¿Cómo convertiremos posteriormente las entidades en tablas?
- ¿Dónde aparecerán las claves primarias y foráneas?
- ¿Cómo resolveremos una relación N:M como Usuario y Película?
- ¿Cómo llegaremos finalmente desde este dibujo hasta SQL?
Eso es precisamente lo que comenzaremos a resolver en los próximos capítulos.
En BD-6 · Cómo diseñar una Base de Datos desde cero dejaremos de estudiar las piezas por separado y utilizaremos lo aprendido para recorrer el proceso completo: requisitos → reglas del sistema → entidades → atributos → relaciones → cardinalidades → diseño.
Nuestra aplicación de películas continuará evolucionando con nosotros. Después, en el siguiente paso de la serie, transformaremos ese diseño conceptual en un modelo lógico preparado para convertirse en tablas y, finalmente, en una base de datos real mediante SQL.
✅ BD-1 · Introducción a Bases de Datos
✅ BD-2 · Modelos de Bases de Datos: Relacional vs NoSQL
✅ BD-3 · Modelo Relacional de Bases de Datos
✅ BD-4 · Normalización de Bases de Datos Relacionales
📍 BD-5 · Diagrama Entidad-Relación (DER): diseño conceptual
➡️ BD-6 · Cómo diseñar una Base de Datos desde cero · Próximamente
Fuentes, documentación y recursos
- Mermaid · Documentación y sintaxis de diagramas
- Mermaid · Editor y documentación oficial
- Lucidchart · Tutorial de Diagramas Entidad-Relación
- dbdiagram.io · Herramienta para diseñar diagramas de bases de datos
- MySQL · Documentación oficial
- MariaDB · Documentación oficial
- PostgreSQL · Data Definition
Este artículo fue publicado originalmente en 2021 y ha sido recuperado, ampliado, actualizado y revisado en 2026 como parte de la serie Bases de Datos Relacionales + SQL de Pythones.net.
En el próximo capítulo dejaremos de estudiar las piezas por separado y comenzaremos a diseñar nuestra base de datos de películas desde cero, partiendo de los requisitos del proyecto.
📅 Última actualización: octubre 16, 2026