Bases de datos

Tu primer diagrama en Data Modeler

Instalar Data Modeler, configurarlo en notación Barker, y armar el modelo del instituto paso a paso hasta generar el script SQL.

bases-de-datosdata-modeleroraclebarkertutorial

Antes de empezar

Oracle SQL Developer Data Modeler es gratuito y se descarga de la página de Oracle (requiere una cuenta gratuita). Viene también incluido dentro de SQL Developer, en el menú View → Data Modeler → Browser; si ya lo tienes instalado, no hace falta bajar nada más.

Necesita un JDK instalado — el mismo Java del que habla la sección de Java. Algunas descargas lo traen incluido; si no, hay que instalarlo aparte antes de la primera ejecución.

Nota

Los nombres de menú de esta página corresponden a las versiones recientes (23.x y 24.x). Entre versiones se mueven de lugar algunas opciones, pero los nombres en inglés se mantienen bastante estables: si algo no está donde dice acá, búscalo por su nombre en los menús File, Tools y View.

Configurar la notación Barker

Este es el primer paso, y saltárselo es la causa del “mi diagrama no se ve como el de los ejemplos”. Por defecto Data Modeler puede mostrar el modelo lógico en notación Bachman, donde los atributos no llevan #, * ni o.

Tools → Preferences → Data Modeler → Diagram → Logical Model, y ahí elegir Barker Notation.

Notación	Cómo se ven los atributos	Cómo se ve el “muchos”
Barker	`# id`, `* nombre`, `o telefono`	Pata de gallo
Bachman	Sin símbolos, con iconos aparte	Punta de flecha

Toda esta sección usa Barker, que es la notación de la bibliografía de Oracle y la que se enseña en la mayoría de los cursos.

Crear el diseño y el modelo lógico

File → New → Data Modeler Design (o directamente empezar en el diseño vacío que se abre al arrancar).
En el panel Browser de la izquierda están los modelos del diseño. El que interesa ahora es Logical Model.
Doble clic en Logical Model para abrir su lienzo.

Si el panel Browser no aparece: View → Browser.

Tip

Guarda el diseño (File → Save) apenas lo creas, antes de dibujar nada. Data Modeler guarda cada diseño como una carpeta con muchos archivos XML adentro, no como un archivo suelto — conviene que tenga su lugar definitivo desde el principio, porque moverla después es más incómodo de lo que parece.

Crear una entidad

En la barra de herramientas del lienzo, el botón New Entity (la caja).
Clic en el lienzo donde quieras ponerla.
Se abre la ventana de propiedades de la entidad. En General, escribe el nombre: PROFESOR.

Agregarle atributos

En la misma ventana, la pestaña Attributes, y el botón + por cada atributo:

Campo	Qué poner
Name	El nombre del atributo (`nombre`, `email`)
Datatype	Logical y el tipo genérico (VARCHAR, NUMERIC, DATE)
Mandatory	Marcado = `*` · Sin marcar = `o`
Primary UID	Marcado = `#`

Ese Mandatory es literalmente el asterisco de la página de símbolos: la casilla y el símbolo son la misma decisión vista de dos maneras.

Para PROFESOR:

Atributo	Mandatory	Primary UID	Queda como
`id_profesor`	✔	✔	`# id_profesor`
`nombre`	✔		`* nombre`
`email`	✔		`* email`
`telefono`			`o telefono`

Al aceptar, la caja en el lienzo muestra los símbolos. Si no los muestra, es que la notación quedó en Bachman — vuelve a la configuración del principio.

Repite para ALUMNO y CURSO, con los atributos del modelo del instituto.

Crear una relación 1:N

Para la relación “un profesor dicta muchos cursos”:

En la barra de herramientas, New 1:N Relation.
Clic primero en la entidad del lado “uno” (PROFESOR), después en la del lado “muchos” (CURSO).
Se abre la ventana de la relación.

Importante

El orden de los dos clics importa. Primero el “uno”, después el “muchos”. Si los inviertes, la pata de gallo queda del lado equivocado y el modelo afirma lo contrario de lo que querías. Si te pasa, borra la relación y vuelve a hacerla: es más rápido que corregirla.

En la ventana de la relación, las dos mitades se configuran por separado — que es exactamente lo que decía leer una relación en dos direcciones:

Sección	Casilla	Efecto
Source (PROFESOR)	Optional marcado	La mitad de ese lado queda punteada
Target (CURSO)	Optional sin marcar	La mitad de ese lado queda continua
Name	El verbo	`dicta` / `es dictado por`

Para el instituto: el lado de PROFESOR es opcional (un profesor puede no dictar nada todavía) y el de CURSO obligatorio (todo curso tiene profesor).

Tip

Data Modeler muestra la lectura en lenguaje natural dentro de la ventana de la relación. Léela: es la misma verificación en voz alta de la página de relaciones, hecha por la herramienta. Si la frase que muestra no es verdad en el negocio, alguna casilla está al revés.

Crear una relación N:M

Para “los alumnos se inscriben en cursos” hay dos caminos, y conviene entender la diferencia.

Camino A — dejar que la herramienta la resuelva. Se usa New M:N Relation y se hacen los dos clics. Data Modeler dibuja la relación con pata de gallo en los dos extremos, y al hacer la ingeniería al modelo relacional crea sola la tabla intermedia.

Es cómodo, pero tiene un costo: la entidad intermedia no existe en el modelo lógico, así que no hay dónde poner fecha ni nota. Para una N:M sin atributos propios está perfecto; para esta, no alcanza.

Camino B — crear la entidad intermedia a mano. Es lo correcto aquí, y es la resolución que ya conoces:

Crear la entidad INSCRIPCION con sus atributos propios: fecha (mandatory) y nota (opcional).
Una relación 1:N de ALUMNO hacia INSCRIPCION.
Otra relación 1:N de CURSO hacia INSCRIPCION.

Los dos extremos que tocan a INSCRIPCION son obligatorios (una inscripción sin alumno o sin curso no significa nada) y los de afuera opcionales.

Marcar el UID barrado

Falta decir que una inscripción se identifica por su alumno y su curso. En la ventana de cada una de esas dos relaciones, del lado de INSCRIPCION, se marca la casilla que dice que la relación forma parte del identificador — según la versión aparece como Identifying o como parte del UID.

Al marcarla, la línea se dibuja con la barra atravesada que viste en el diagrama de la página anterior. Eso es lo que se convierte en la clave primaria compuesta.

Verificar el modelo

Antes de generar nada: Tools → Design Rules (o el botón de validación). Data Modeler revisa el diseño y lista los problemas.

Los avisos más frecuentes al empezar, y qué significan de verdad:

Aviso	Qué está pasando	Cómo se arregla
Entity without UID	Una entidad sin identificador	Marca Primary UID en el atributo que corresponda
Entity without attributes	Una caja vacía	Agrégale atributos, o bórrala si sobraba
Entity is not connected	Una entidad suelta, sin relaciones	Puede ser correcto; verifica si le faltaba un vínculo
Duplicate name	Dos entidades o atributos con el mismo nombre	Renombra

Nota

Un aviso no siempre es un error: una entidad de catálogo sin relaciones puede ser perfectamente válida. El valor de la validación no es que apruebe todo, sino que te obligue a mirar cada punto y decidir a conciencia.

Generar las tablas y el SQL

Con el modelo lógico validado:

Engineer to Relational Model (la flecha hacia la derecha en la barra, o File → Engineer to Relational Model).
En el diálogo, aceptar las opciones por defecto y Engineer.
Aparece el modelo relacional: las mismas cajas, ahora con PK y FK. Es la traducción mecánica hecha por la herramienta.
Para el script: File → Export → DDL File, elegir el motor (por ejemplo Oracle Database 21c) y Generate.

El resultado es un .sql con los CREATE TABLE, las claves primarias y las foráneas, listo para ejecutar.

Advertencia

La ingeniería no es una exportación de una sola vez: mantiene los dos modelos vinculados. Si después cambias el modelo lógico y vuelves a hacer Engineer, Data Modeler abre un diálogo comparando qué cambió y qué va a hacer con lo que ya existía. Léelo antes de aceptar, sobre todo si tocaste el modelo relacional a mano — ahí es donde se pierden cambios sin darse cuenta.

Atajos y detalles que ahorran tiempo

Acción	Cómo
Ver/editar cualquier objeto	Doble clic sobre él en el lienzo
Acomodar el diagrama solo	Clic derecho en el lienzo → Auto Layout
Exportar el diagrama como imagen	File → Print Diagram → To Image File
Cambiar colores y tipografía	Tools → Preferences → Diagram
Ver todo el árbol del diseño	Panel Browser (View → Browser)
Deshacer	`Ctrl+Z`, como en todos lados

Pon a prueba

🎯 La pata de gallo quedó del lado equivocado

Dibujaste “un departamento tiene muchos empleados” con New 1:N Relation, pero la pata de gallo quedó tocando a DEPARTAMENTO en vez de a EMPLEADO. ¿Qué pasó?

Correcto. New 1:N Relation espera primero la entidad del lado "uno" y después la del "muchos". Invertir los clics produce exactamente ese síntoma, y lo más rápido es borrar la relación y rehacerla en el orden correcto.
Ese error da otro síntoma: no aparecerían los símbolos #, * y o en los atributos, y el "muchos" se dibujaría con una punta de flecha en vez de una pata de gallo. Si ves pata de gallo, la notación es Barker.
Mandatory controla el * de cada atributo, o sea si puede quedar vacío. No tiene nada que ver con la cardinalidad de la relación, que se decide en la ventana de la relación.
El modelo lógico se dibuja correcto por sí solo, antes de cualquier ingeniería. Si está mal en el lógico, la ingeniería solo va a propagar el error a las tablas.

🧩 Ordena el código

Ordena los pasos para armar el modelo del instituto en Data Modeler desde cero.

Tools → Design Rules para validar el modelo
New 1:N Relation de PROFESOR a CURSO
Tools → Preferences → Diagram → Logical Model → Barker Notation
Engineer to Relational Model
New 1:N Relation de ALUMNO a INSCRIPCION y de CURSO a INSCRIPCION
Cargar los atributos de cada una marcando Mandatory y Primary UID
Marcar las dos relaciones de INSCRIPCION como parte de su UID
File → New → Data Modeler Design y guardar el diseño
File → Export → DDL File para generar el script SQL
Abrir el Logical Model desde el panel Browser
Crear las entidades PROFESOR, ALUMNO, CURSO e INSCRIPCION

💡 Arma el modelo tú mismo

Modela esto en Data Modeler, de principio a fin, hasta generar el script:

Un gimnasio tiene socios (nombre, email, teléfono opcional) y ofrece clases (nombre, día, hora, cupo). Cada clase la dicta un instructor (nombre, especialidad). Los socios se anotan a las clases, y de cada anotación se registra la fecha en que se anotó y si asistió o no.

Antes de abrir la herramienta, resuelve el modelo en papel. Después compáralo.

El modelo:

texttext

┌──────────────────┐    ┌──────────────────┐    ┌──────────────────┐
│ SOCIO            │    │ ANOTACION        │    │ CLASE            │
├──────────────────┤    ├──────────────────┤    ├──────────────────┤
│ # id_socio       │──┼<│ * fecha_anotacion│>┼──│ # id_clase       │
│ * nombre         │    │ * asistio        │    │ * nombre         │
│ * email          │    └──────────────────┘    │ * dia            │
│ o telefono       │                            │ * hora           │
└──────────────────┘                            │ * cupo           │
                                                └──────────────────┘
                                                         │
                                        ┌──────────────────┐
                                        │ INSTRUCTOR       │
                                        ├──────────────────┤
                                        │ # id_instructor  │
                                        │ * nombre         │
                                        │ * especialidad   │
                                        └──────────────────┘

Las decisiones:

SOCIO ↔ CLASE es N:M con atributos propios (fecha_anotacion, asistio), así que hace falta la entidad intermedia. “Anotación” es la palabra que usa el propio enunciado.
INSTRUCTOR → CLASE es 1:N. Cada clase la dicta un instructor; un instructor puede dictar varias. El extremo hacia CLASE es punteado (un instructor recién contratado todavía no tiene clases) y el extremo hacia INSTRUCTOR continuo (toda clase tiene alguien que la dicte).
asistio es *, no o. Antes de la clase el dato se conoce igual: es false hasta que alguien marque lo contrario. Si prefirieras distinguir “todavía no pasó” de “no vino”, entonces sí correspondería o. Las dos son defendibles; lo que importa es haberlo pensado.
El UID de ANOTACION es barrado con las dos relaciones: un socio no se anota dos veces a la misma clase.

En la herramienta: los mismos pasos del ejercicio anterior. Al validar con Design Rules no debería quedar ningún aviso; si aparece Entity without UID, es que faltó marcar Primary UID en algún id_.

Siguiente paso

La herramienta ya no es un obstáculo. Lo que queda es lo único que realmente enseña a modelar: hacerlo muchas veces, con enunciados distintos — ver el Banco de ejercicios.