Bases de datos
Qué es el modelado de datos
Por qué se dibuja un modelo antes de crear una sola tabla, qué son los modelos conceptual, lógico y físico, y qué lugar ocupa Oracle Data Modeler en todo eso.
El problema: la planilla que se rompe sola
Casi todo sistema empieza como una planilla. Un instituto que anota sus inscripciones podría tener esta:
| Alumno | Curso | Profesor | Sala | |
|---|---|---|---|---|
| Ana Ruiz | ana@mail.com | Java Básico | Luis Paz | A-12 |
| Ana Ruiz | ana@mail.com | Bases de Datos | Marta Gil | B-03 |
| Beto Sosa | beto@mail.com | Java Básico | Luis Paz | A-12 |
Funciona hasta que deja de funcionar, y falla siempre de las mismas tres maneras:
- Datos repetidos. El email de Ana está escrito dos veces; el profesor y la sala de Java Básico, también. Cada copia es una oportunidad de que una quede desactualizada.
- Actualizaciones a medias. Si Ana cambia de email y solo se corrige una fila, la base pasa a afirmar dos cosas contradictorias a la vez.
- Datos que no se pueden guardar. ¿Cómo anotas un curso que todavía no tiene ningún inscripto? No hay fila donde ponerlo sin inventar un alumno falso.
Ninguno de los tres se arregla escribiendo mejor SQL: son consecuencia de haber puesto en una sola tabla tres cosas distintas —alumnos, cursos e inscripciones— que el negocio trata por separado. Modelar datos es hacer ese trabajo antes: identificar de qué cosas habla el sistema, qué se sabe de cada una, y cómo se relacionan entre sí.
Un error de modelado es el más caro de todos los errores de un sistema. Una consulta lenta se optimiza y un botón mal puesto se mueve, pero cambiar la estructura de las tablas cuando ya hay datos cargados y código escrito contra ellas obliga a migrar los datos, reescribir las consultas y reprobar todo. Media hora de diagrama al principio ahorra semanas después.
Entidad-relación: las tres preguntas
El modelo entidad-relación (E-R) responde a tres preguntas, y esas tres preguntas son todo el método:
| Pregunta | Nombre técnico | En el ejemplo |
|---|---|---|
| ¿De qué cosas hablo? | Entidades | ALUMNO, CURSO, PROFESOR |
| ¿Qué sé de cada una? | Atributos | nombre, email, fecha de inicio |
| ¿Cómo se vinculan entre sí? | Relaciones | Un alumno se inscribe en cursos |
El resultado se dibuja: un diagrama donde cada entidad es una caja, cada atributo una línea dentro de esa caja, y cada relación una línea entre cajas. Ese diagrama es el plano del edificio antes de poner el primer ladrillo — y, como vas a ver, después se convierte en tablas casi automáticamente.
Los tres niveles del modelo
La misma realidad se dibuja tres veces, con distinto nivel de detalle. Distinguirlos evita la confusión más común al empezar: mezclar decisiones de negocio con decisiones técnicas.
| Nivel | Qué responde | Vocabulario | Quién lo entiende |
|---|---|---|---|
| Conceptual | ¿De qué habla el negocio? | Entidad, atributo, relación | El cliente, sin saber nada técnico |
| Lógico | ¿Cómo se estructura eso? | Entidad, atributo, UID, cardinalidad | Analistas y desarrolladores |
| Físico | ¿Cómo se implementa en este motor? | Tabla, columna, PK, FK, índice, VARCHAR2 | El motor de base de datos |
El salto que más importa es el que va del lógico al físico, y tiene nombres propios en cada lado:
| En el modelo lógico | Se convierte en (modelo físico) |
|---|---|
| Entidad | Tabla |
| Instancia (un caso concreto) | Fila / registro |
| Atributo | Columna |
| Identificador único (UID) | Clave primaria (primary key) |
| Relación | Clave foránea (foreign key) |
Por eso una entidad se nombra en singular: ALUMNO describe qué es cada instancia, no el conjunto. “Ana Ruiz” es un ALUMNO. Cuando eso se convierta en tabla, la fila seguirá siendo un alumno. Nombrar la entidad “ALUMNOS” es el primer síntoma de estar pensando en tablas en vez de en el negocio.
Dónde entra Oracle Data Modeler
Oracle SQL Developer Data Modeler es la herramienta gratuita de Oracle para dibujar estos modelos. Lo que la hace útil para aprender no es que dibuje bonito, sino que entiende lo que dibujas:
- Valida el modelo y avisa de inconsistencias (una entidad sin identificador, una relación mal definida).
- Convierte el modelo lógico en modelo relacional con un botón — es la traducción de la tabla de arriba, hecha por la herramienta.
- Genera el script SQL de
CREATE TABLEa partir de ese modelo relacional.
Es decir: dibujas el negocio y sale la base de datos. Toda esta sección trabaja con esa herramienta, y usa su notación por defecto para el modelo lógico, la notación Barker, que es de donde salen los símbolos #, * y o que verás en cada diagrama.
Data Modeler viene incluido dentro de SQL Developer, y también se descarga por separado desde la página de Oracle. Existe para Windows, Linux y macOS, y es gratuito. Necesita tener instalado un JDK — el mismo Java del que habla la sección de Java.
El ejemplo que va a acompañar toda la sección
Para no cambiar de dominio en cada página, todo lo que sigue modela el mismo instituto de la planilla del principio. Su descripción en palabras, tal como la daría el cliente:
El instituto dicta cursos. Cada curso tiene un código, un nombre y una cantidad de horas, y lo dicta un profesor. De cada profesor se guarda su nombre, su email y opcionalmente su teléfono. Los alumnos se inscriben en cursos: un alumno puede estar en varios cursos y un curso tiene varios alumnos inscriptos. De cada inscripción interesa la fecha y, cuando el curso termina, la nota final.
Ese párrafo tiene adentro todo el modelo. A lo largo de las páginas siguientes se va a ir traduciendo pieza por pieza: primero las entidades y sus atributos, después los símbolos que marcan cuáles son obligatorios y cuál identifica a cada instancia, y por último las relaciones entre ellas.
Al leer un enunciado así, subraya los sustantivos (candidatos a entidad), los datos que se guardan de cada uno (candidatos a atributo) y los verbos que unen dos sustantivos (candidatos a relación). Es una heurística tosca y no siempre acierta, pero convierte una hoja en blanco en un primer borrador en cinco minutos.
Pon a prueba
Una tienda te describe su sistema así: “Vendemos productos, cada uno con su nombre, precio y stock. Los clientes hacen pedidos, y cada pedido tiene una fecha y puede incluir varios productos.”
¿Cuál de estas clasificaciones es la correcta?
Una veterinaria lleva esta planilla. Encuentra al menos tres problemas concretos y di qué entidades deberían existir en su lugar.
| Dueño | Teléfono | Mascota | Especie | Fecha visita | Motivo |
|---|---|---|---|---|---|
| Ana Ruiz | 555-1234 | Fido | Perro | 2026-03-01 | Vacuna |
| Ana Ruiz | 555-1234 | Fido | Perro | 2026-05-14 | Control |
| Ana Ruiz | 555-1234 | Michi | Gato | 2026-05-14 | Vacuna |
Problemas:
- Repetición. El teléfono de Ana está escrito tres veces, y la especie de Fido dos. Cada copia puede desincronizarse de las demás.
- Actualización parcial. Si Ana cambia de teléfono y se corrige una sola fila, la planilla afirma dos teléfonos distintos para la misma persona sin que nada lo impida.
- No se puede guardar lo que todavía no pasó. Una mascota que nunca fue atendida no tiene dónde existir: haría falta inventar una visita falsa. Lo mismo con un dueño nuevo que aún no trajo a nadie.
- Borrado destructivo. Si se elimina la única visita de Michi, se pierde también que Michi existe y que es un gato — datos que no tenían nada que ver con esa visita.
- Ambigüedad. Dos dueños distintos llamados “Ana Ruiz” son indistinguibles: no hay ningún dato que identifique a una persona sin lugar a dudas.
Entidades que deberían existir:
- DUEÑO — nombre, teléfono. Existe aunque no tenga mascotas.
- MASCOTA — nombre, especie. Pertenece a un dueño; existe aunque nunca haya venido.
- VISITA — fecha, motivo. Corresponde a una mascota.
Cada dato queda escrito una sola vez, y cada cosa puede existir independientemente de las otras. Ese es, en una frase, el objetivo del modelado.
Siguiente paso
Ya sabes qué se busca y por qué. Ahora toca dibujarlo: cómo se representa una entidad, cómo se eligen sus atributos y qué diferencia hay entre un atributo y una entidad disfrazada — ver Entidades y atributos.