Módulo 18: Metodología y herramientas

Objetivos del módulo

  • Aplicar una metodología sistemática para obtener un esquema conceptual a partir de un enunciado o de unas entrevistas
  • Conocer las estrategias de diseño: descendente, ascendente, centrífuga (inside-out) y mixta
  • Saber integrar varias vistas de usuario en un único esquema y resolver sus conflictos
  • Elaborar el diccionario de datos del modelo conceptual con una plantilla profesional
  • Evaluar la calidad de un esquema con una lista de comprobación: completitud, corrección, minimalidad y legibilidad
  • Reconocer y corregir los errores más frecuentes de los estudiantes
  • Comparar las principales notaciones y herramientas de modelado
  • Presentar un diagrama E/R de forma clara y completa en un examen

1. Del enunciado al esquema: visión general

Diseñar un esquema conceptual no es un acto de inspiración: es un proceso que puede seguirse paso a paso. Igual que un arquitecto no empieza dibujando la fachada, sino entendiendo qué necesita la familia que va a vivir en la casa, un diseñador de bases de datos empieza entendiendo los requisitos y termina validando con el usuario que el esquema los recoge.

flowchart LR
    REQ["Requisitos<br/>(enunciado, entrevistas,<br/>documentos)"] --> ANA["Análisis<br/>(identificar elementos)"]
    ANA --> DIS["Diseño<br/>(diagrama E/R)"]
    DIS --> DOC["Documentación<br/>(diccionario y restricciones)"]
    DOC --> REV["Revisión<br/>(calidad, trampas, ciclos)"]
    REV --> VAL["Validación<br/>con el usuario"]
    VAL -->|"cambios"| ANA
    VAL -->|"aprobado"| FIN["Esquema conceptual<br/>definitivo"]

📘 Concepto: El esquema conceptual es el resultado del diseño conceptual. Está formado por el diagrama E/R (extendido), el diccionario de datos (descripción de cada elemento) y el catálogo de restricciones que el diagrama no expresa. Es independiente del SGBD y del modelo de datos lógico (relacional, documental…) que se use después.

⚠️ Importante: El proceso es iterativo. Es normal que al definir las cardinalidades descubras una entidad nueva, o que al validar con el usuario aparezca un requisito que nadie había mencionado. Un buen diseñador no se frustra por volver atrás: lo espera.

2. Metodología paso a paso

A continuación se describe un método de diez pasos, inspirado en los de Batini, Ceri y Navathe, de Miguel y Piattini, y Connolly y Begg, adaptado a la forma en que se trabaja en clase y en los exámenes. Lo aplicaremos a un enunciado completo.

2.0. El enunciado de trabajo

💻 Ejemplo: Clínica veterinaria.

Una clínica veterinaria quiere informatizar su gestión. De cada cliente (dueño de mascotas) se guarda su DNI, nombre, dirección (calle, código postal y ciudad) y uno o varios teléfonos. Cada cliente puede tener varias mascotas; cada mascota tiene un único dueño. De cada mascota se registra un código interno, su nombre, la especie (perro, gato, ave…), la raza, la fecha de nacimiento y, si lo tiene, el número de microchip, que es único.

La clínica cuenta con veterinarios, de los que se guarda el número de colegiado, nombre y fecha de incorporación. Algunos veterinarios son cirujanos y tienen una certificación con fecha de obtención.

Cada vez que una mascota acude a la clínica se registra una consulta: fecha y hora, motivo, diagnóstico y el veterinario que la atendió. En una consulta se pueden recetar medicamentos (código, nombre, laboratorio), indicando la dosis y la duración del tratamiento para cada medicamento recetado.

También se lleva el control de vacunas (código, nombre, enfermedad que previene): se registra cada vacuna que se pone a cada mascota, con la fecha y el lote. Una mascota puede recibir la misma vacuna muchas veces (refuerzos anuales).

Por último, los cirujanos realizan operaciones a las mascotas en alguno de los quirófanos de la clínica (número, planta). De cada operación interesa la fecha, el tipo de intervención y las observaciones. Una operación la realiza un solo cirujano.

2.1. Paso 1: lectura y análisis lingüístico

Lee el enunciado completo al menos dos veces antes de dibujar nada. En la segunda lectura, subraya:

  • Sustantivos y grupos nominales → candidatos a entidades o atributos.
  • Verbos y expresiones verbales (“tiene”, “realiza”, “se registra”, “pertenece a”) → candidatos a relaciones.
  • Cuantificadores (“cada”, “varios”, “uno o varios”, “un único”, “si lo tiene”, “algunos”) → pistas de cardinalidades y opcionalidad.
  • Adjetivos y condiciones (“único”, “algunos son”, “solo si”) → identificadores, jerarquías y restricciones.

Esta técnica se llama análisis lingüístico y la propuso el propio Chen en 1983 con reglas del tipo “un sustantivo común suele ser una entidad; un verbo transitivo suele ser una relación; un adjetivo suele ser un atributo”.

Elemento del texto Candidato a Pista
cliente, mascota, veterinario, consulta, medicamento, vacuna, operación, quirófano Entidad Sustantivos con datos propios y varias ocurrencias
cirujano Subtipo “Algunos veterinarios son cirujanos” + atributos propios
DNI, nombre, dirección, teléfonos, código, especie, raza… Atributo Describen a otro sustantivo
“puede tener varias mascotas” Relación 1:N “cada mascota tiene un único dueño”
“recetar medicamentos… indicando la dosis” Relación N:M con atributos El dato dosis depende de la consulta y del medicamento
“puede recibir la misma vacuna muchas veces” Relación con repetición Hay que reificar (módulo 13)
“si lo tiene, el número de microchip, que es único” Atributo opcional y clave alternativa No puede ser identificador principal

⚠️ Importante: El análisis lingüístico es una ayuda, no un algoritmo. “Especie” es un sustantivo, pero aquí es un atributo; “receta” es un verbo, pero se convierte en relación con atributos. Cada candidato hay que confirmarlo con los criterios del paso 2.

2.2. Paso 2: identificar las entidades

Para cada candidato, comprueba estos criterios. Una entidad debe:

  1. Representar un tipo de objeto del que hay varias ocurrencias (no una sola: “la clínica” no es una entidad).
  2. Tener interés para el sistema: alguien necesita consultar o registrar sus datos.
  3. Tener atributos propios además del que la identifica (o participar en relaciones).
  4. Poder identificarse: cada ocurrencia se distingue de las demás.
Candidato ¿Entidad? Justificación
CLIENTE Sí Muchos clientes, con DNI y datos propios
MASCOTA Sí Muchas mascotas, con código interno
VETERINARIO Sí Con número de colegiado
CIRUJANO Subtipo de VETERINARIO Atributos propios (certificación) y relación propia (realiza operaciones)
CONSULTA Sí Acontecimiento con fecha, motivo y diagnóstico; se repite
MEDICAMENTO Sí Catálogo con código, nombre y laboratorio
VACUNA Sí Catálogo con código y enfermedad
VACUNACION Sí (reificación) “La misma vacuna muchas veces”: el hecho de vacunar es un acontecimiento repetible
OPERACION Sí Acontecimiento con fecha, tipo y observaciones
QUIROFANO Sí Varios quirófanos con número y planta
especie No, atributo Solo un nombre; si tuviera datos propios sería entidad
clínica No Una sola ocurrencia: es el propio sistema

2.3. Paso 3: elegir los identificadores

Para cada entidad, elige un identificador (clave) que sea:

  • Único para todas las ocurrencias, presentes y futuras.
  • Obligatorio (todas las ocurrencias lo tienen).
  • Estable (no cambia con el tiempo).
  • Mínimo (no sobra ningún atributo).
  • Preferiblemente simple y corto.
Entidad Identificador Claves alternativas Comentario
CLIENTE dni — Natural y estable
MASCOTA cod_mascota num_microchip El microchip es único pero opcional: no puede ser identificador principal
VETERINARIO num_colegiado — —
CONSULTA num_consulta (cod_mascota, fecha_hora) Se elige un código por sencillez; también podría ser débil de MASCOTA
MEDICAMENTO cod_medicamento — —
VACUNA cod_vacuna — —
VACUNACION — — Débil de MASCOTA, identificador parcial fecha (se decidirá en el paso 7)
OPERACION num_operacion — —
QUIROFANO numero — —

💡 Consejo: Si dudas entre un identificador natural (DNI, matrícula, ISBN) y uno artificial (código interno), pregúntate si el natural cumple siempre las cinco condiciones. El DNI falla para extranjeros sin NIE o menores; el ISBN falla para libros antiguos; el teléfono cambia. En esos casos, usa un código artificial y deja el natural como clave alternativa (si es único) o como atributo normal.

2.4. Paso 4: identificar las relaciones

Busca los hechos que vinculan entidades. Para cada uno, determina qué entidades participan, ponle un verbo como nombre y comprueba que no se deduce de otras relaciones.

Relación Entidades Texto de origen
posee CLIENTE – MASCOTA “cada cliente puede tener varias mascotas”
acude MASCOTA – CONSULTA “cada vez que una mascota acude se registra una consulta”
atiende VETERINARIO – CONSULTA “el veterinario que la atendió”
receta CONSULTA – MEDICAMENTO “en una consulta se pueden recetar medicamentos”
recibe MASCOTA – VACUNACION “cada vacuna que se pone a cada mascota”
de VACUNACION – VACUNA —
realiza CIRUJANO – OPERACION “una operación la realiza un solo cirujano”
se_opera MASCOTA – OPERACION “operaciones a las mascotas”
en OPERACION – QUIROFANO “en alguno de los quirófanos”

2.5. Paso 5: determinar las cardinalidades

Para cada relación binaria entre A y B haz dos preguntas, una en cada sentido, y responde siempre con mínimo y máximo:

  1. “Una ocurrencia de A, ¿con cuántas de B se relaciona como mínimo? ¿Y como máximo?” → la pareja se escribe junto a B.
  2. “Una ocurrencia de B, ¿con cuántas de A se relaciona como mínimo? ¿Y como máximo?” → la pareja se escribe junto a A.
Relación Pregunta Respuesta Junto a
posee ¿Cuántas mascotas tiene un cliente? 1 a n (es cliente porque tiene alguna) MASCOTA: (1,n)
posee ¿Cuántos dueños tiene una mascota? Exactamente 1 CLIENTE: (1,1)
acude ¿Cuántas consultas tiene una mascota? 0 a n CONSULTA: (0,n)
acude ¿De cuántas mascotas es una consulta? Exactamente 1 MASCOTA: (1,1)
atiende ¿Cuántas consultas atiende un veterinario? 0 a n CONSULTA: (0,n)
atiende ¿Cuántos veterinarios atienden una consulta? Exactamente 1 VETERINARIO: (1,1)
receta ¿Cuántos medicamentos se recetan en una consulta? 0 a n MEDICAMENTO: (0,n)
receta ¿En cuántas consultas se receta un medicamento? 0 a n CONSULTA: (0,n)

💡 Consejo: Las cardinalidades mínimas son las que más se equivocan. Para cada mínima, piensa en el primer día: cuando se da de alta un veterinario nuevo, ¿ha atendido ya alguna consulta? No → mínima 0. Cuando se registra una mascota, ¿tiene ya dueño? Sí, siempre → mínima 1.

2.6. Paso 6: asignar los atributos

Coloca cada atributo en la entidad o relación a la que describe, y clasifícalo: simple o compuesto, monovaluado o multivaluado, obligatorio u opcional, derivado o almacenado.

  • direccion es compuesto (calle, código postal, ciudad).
  • telefono es multivaluado (“uno o varios teléfonos”).
  • num_microchip es opcional y único.
  • dosis y duracion son atributos de la relación receta: no describen ni a la consulta ni al medicamento por separado, sino al hecho de recetar ese medicamento en esa consulta.
  • edad de la mascota sería derivado de fecha_nacimiento (no se pide, así que no se dibuja).

⚠️ Importante: Regla para los atributos de relación: si el atributo depende de las dos entidades a la vez (en una N:M), va en la relación. En una 1:N, un atributo de la relación puede “bajarse” a la entidad del lado N; en el modelo conceptual, colócalo donde sea más natural semánticamente.

2.7. Paso 7: entidades débiles y relaciones con repetición

Revisa las entidades que no tienen sentido sin otra o que se identifican a través de otra (módulo 10), y las relaciones N:M que deben admitir repeticiones (módulo 13):

  • VACUNACION: una mascota recibe la misma vacuna varias veces. Una relación N:M MASCOTA–VACUNA no permitiría repetir el par. Se modela como entidad débil de MASCOTA, identificada por la mascota + fecha (una mascota no recibe dos vacunas el mismo día) o, si eso puede ocurrir, por mascota + fecha + vacuna.
  • CONSULTA podría ser débil de MASCOTA, pero se ha optado por un identificador propio porque se referencia desde otras entidades (las recetas) y conviene un identificador corto.

2.8. Paso 8: jerarquías

Busca expresiones del tipo “algunos X son Y”, “los X pueden ser A o B”, “hay dos tipos de X”, y aplica la regla de oro del módulo 11 (el subtipo necesita atributos, relaciones o restricciones propios):

  • CIRUJANO es subtipo de VETERINARIO: tiene atributos propios (certificacion, fecha_certificacion) y una relación propia (realiza). Cobertura parcial (no todos los veterinarios son cirujanos), con un único subtipo.
  • La especie de la mascota no justifica una jerarquía (perro, gato…): no hay atributos ni relaciones propios.

2.9. Paso 9: restricciones

Anota todo lo que el diagrama no recoge (módulo 13):

  • R1: la fecha de una consulta no es anterior a la fecha de nacimiento de la mascota.
  • R2: una operación se realiza en una fecha posterior o igual a la de certificación del cirujano.
  • R3: un quirófano no puede tener dos operaciones a la vez (requeriría hora y duración; se anota para validarlo con el usuario).
  • R4: la duración de un tratamiento es mayor que 0 días.

2.10. Paso 10: diagrama, revisión y validación

Dibuja el diagrama completo:

flowchart TB
    classDef debil stroke-width:4px
    CLIENTE[CLIENTE] --- c_dni([<u>dni</u>])
    CLIENTE --- c_nom([nombre])
    CLIENTE --- c_dir([direccion])
    c_dir --- c_calle([calle])
    c_dir --- c_cp([cp])
    c_dir --- c_ciu([ciudad])
    CLIENTE --- c_tel(((telefono)))
    CLIENTE ---|"(1,1)"| posee{"posee<br/>1:N"}
    posee ---|"(1,n)"| MASCOTA[MASCOTA]
    MASCOTA --- m_cod([<u>cod_mascota</u>])
    MASCOTA --- m_nom([nombre])
    MASCOTA --- m_esp([especie])
    MASCOTA --- m_raz([raza])
    MASCOTA --- m_fn([fecha_nacimiento])
    MASCOTA --- m_chip(["num_microchip (0,1) (AK)"])
    MASCOTA ---|"(1,1)"| acude{"acude<br/>1:N"}
    acude ---|"(0,n)"| CONSULTA[CONSULTA]
    CONSULTA --- co_num([<u>num_consulta</u>])
    CONSULTA --- co_fh([fecha_hora])
    CONSULTA --- co_mot([motivo])
    CONSULTA --- co_dia([diagnostico])
    VETERINARIO[VETERINARIO] ---|"(1,1)"| atiende{"atiende<br/>1:N"}
    atiende ---|"(0,n)"| CONSULTA
    CONSULTA ---|"(0,n)"| receta{"receta<br/>N:M"}
    receta ---|"(0,n)"| MEDICAMENTO[MEDICAMENTO]
    receta --- r_dos([dosis])
    receta --- r_dur([duracion_dias])
    MEDICAMENTO --- me_cod([<u>cod_medicamento</u>])
    MEDICAMENTO --- me_nom([nombre])
    MEDICAMENTO --- me_lab([laboratorio])
    MASCOTA ---|"(1,1)"| recibe{"recibe<br/>ID"}:::debil
    recibe ---|"(0,n)"| VACUNACION[VACUNACION]:::debil
    VACUNACION --- va_fec(["<u>fecha</u> parcial"])
    VACUNACION --- va_lote([lote])
    VACUNACION ---|"(0,n)"| de{"de<br/>1:N"}
    de ---|"(1,1)"| VACUNA[VACUNA]
    VACUNA --- vc_cod([<u>cod_vacuna</u>])
    VACUNA --- vc_nom([nombre])
    VACUNA --- vc_enf([enfermedad])

flowchart TB
    VETERINARIO[VETERINARIO] --- v_col([<u>num_colegiado</u>])
    VETERINARIO --- v_nom([nombre])
    VETERINARIO --- v_fec([fecha_incorporacion])
    VETERINARIO --- jv{{"es un<br/>(parcial)"}}
    jv --- CIRUJANO[CIRUJANO]
    CIRUJANO --- ci_cert([certificacion])
    CIRUJANO --- ci_fec([fecha_certificacion])
    CIRUJANO ---|"(1,1)"| realiza{"realiza<br/>1:N"}
    realiza ---|"(0,n)"| OPERACION[OPERACION]
    OPERACION --- o_num([<u>num_operacion</u>])
    OPERACION --- o_fec([fecha])
    OPERACION --- o_tip([tipo_intervencion])
    OPERACION --- o_obs(["observaciones (0,1)"])
    MASCOTA[MASCOTA] ---|"(1,1)"| se_opera{"se_opera<br/>1:N"}
    se_opera ---|"(0,n)"| OPERACION
    OPERACION ---|"(0,n)"| en{"en<br/>1:N"}
    en ---|"(1,1)"| QUIROFANO[QUIROFANO]
    QUIROFANO --- q_num([<u>numero</u>])
    QUIROFANO --- q_pla([planta])

💡 Consejo: Cuando el diagrama es grande, divídelo en partes que compartan entidades (aquí, MASCOTA y VETERINARIO aparecen en los dos). En cada parte, dibuja los atributos de una entidad compartida solo una vez y en las demás deja la entidad “desnuda”.

Revisión: aplica la lista de comprobación de la sección 6: ¿hay ciclos? (MASCOTA–CONSULTA–VETERINARIO no forma ciclo con OPERACION porque VETERINARIO–CIRUJANO es una jerarquía); ¿hay trampas? (¿podemos saber qué veterinario atendió cada vacunación? No: el enunciado no lo pide, pero es una buena pregunta para el usuario); ¿sobra algo?

Validación con el usuario: lee el diagrama en voz alta en lenguaje natural, frase a frase, y pide al usuario que confirme cada una:

  • “Cada mascota tiene exactamente un dueño. ¿Correcto?” (¿Y si una familia comparte la mascota?)
  • “Una consulta la atiende exactamente un veterinario. ¿Correcto?” (¿Y si se deriva a otro durante la consulta?)
  • “Una mascota no recibe dos vacunas el mismo día. ¿Correcto?” (Muy probablemente falso: se suelen poner varias en la misma visita. Habría que cambiar el identificador parcial a fecha + vacuna.)

⚠️ Importante: Esta lectura en voz alta es la herramienta de validación más eficaz que existe. Los usuarios no entienden los rombos ni las cardinalidades, pero sí entienden frases como “un cliente puede no tener ninguna mascota”. Muchos errores salen a la luz solo en este paso.

2.11. Tabla de heurísticas de decisión

Durante los pasos anteriores surgen siempre las mismas dudas. Esta tabla resume los criterios:

Duda Elige… Si…
¿Entidad o atributo? Entidad Tiene atributos propios, participa en relaciones o se comparte entre muchas ocurrencias que conviene normalizar (ciudad, especialidad)
  Atributo Solo es un valor que describe a otra cosa
¿Atributo de entidad o de relación? De relación Depende de las dos entidades a la vez (dosis de un medicamento en una consulta)
¿Relación o entidad? Entidad Es un acontecimiento repetible, tiene muchos atributos o se relaciona a su vez con otras entidades
  Relación Es un vínculo estable sin apenas atributos
¿Jerarquía o atributo tipo? Jerarquía Los subtipos tienen atributos, relaciones o restricciones propios
¿Entidad débil o fuerte? Débil No tiene identificador propio natural y no existe sin su entidad fuerte
¿Ternaria o binarias? Ternaria El hecho involucra a las tres entidades a la vez y no se reconstruye a partir de binarias (módulo de relaciones ternarias)
¿Multivaluado o entidad? Entidad Cada valor tiene atributos propios (teléfono con tipo y extensión) o interesa buscarlo y compartirlo

3. Estrategias de diseño

Para esquemas grandes, el orden en el que se abordan los conceptos influye mucho en el resultado. Batini, Ceri y Navathe describen cuatro estrategias.

3.1. Estrategia descendente (top-down)

Se parte de un esquema muy abstracto, con pocos conceptos, y se refina sucesivamente aplicando transformaciones (llamadas primitivas de refinamiento) hasta llegar al detalle.

Primitivas descendentes típicas:

Primitiva Transformación Ejemplo
T1 Una entidad se convierte en una jerarquía PERSONA → ALUMNO, PROFESOR
T2 Una entidad se convierte en dos entidades relacionadas PEDIDO → PEDIDO + LINEA_PEDIDO
T3 Una relación se convierte en dos relaciones con una entidad intermedia ALUMNO–ASIGNATURA → ALUMNO–MATRICULA–ASIGNATURA
T4 Una entidad o relación desarrolla sus atributos CLIENTE → CLIENTE con dni, nombre, dirección
T5 Un atributo se convierte en compuesto o en entidad dirección → calle, cp, ciudad

💻 Ejemplo: Refinamiento descendente de un sistema de ventas.

Nivel 1, muy abstracto:

flowchart LR
    CLIENTE[CLIENTE] ---|"(1,1)"| compra{"compra<br/>1:N"}
    compra ---|"(0,n)"| VENTA[VENTA]

Nivel 2 (primitiva T2: la venta se divide en pedido y líneas; aparece el producto):

flowchart LR
    classDef debil stroke-width:4px
    CLIENTE[CLIENTE] ---|"(1,1)"| realiza{"realiza<br/>1:N"}
    realiza ---|"(0,n)"| PEDIDO[PEDIDO]
    PEDIDO ---|"(1,1)"| contiene{"contiene<br/>ID"}:::debil
    contiene ---|"(1,n)"| LINEA[LINEA_PEDIDO]:::debil
    LINEA ---|"(0,n)"| de{"de<br/>1:N"}
    de ---|"(1,1)"| PRODUCTO[PRODUCTO]

Nivel 3 (primitiva T1 sobre CLIENTE y T4 en todas las entidades): se añaden subtipos PARTICULAR/EMPRESA, atributos, categorías de producto…

Ventajas: visión global desde el principio, ideal cuando el diseñador conoce bien el dominio. Inconvenientes: difícil de aplicar en sistemas grandes en los que nadie tiene la visión completa.

3.2. Estrategia ascendente (bottom-up)

Se parte de los conceptos elementales (los atributos) y se van agrupando en entidades, que después se relacionan y generalizan.

  1. Lista de todos los datos que aparecen en formularios, informes y documentos: dni_cliente, nombre_cliente, num_pedido, fecha_pedido, cod_producto, precio…
  2. Agrupación por el objeto que describen: {dni_cliente, nombre_cliente} → CLIENTE; {num_pedido, fecha_pedido} → PEDIDO…
  3. Relaciones entre los grupos.
  4. Generalizaciones: si CLIENTE_PARTICULAR y CLIENTE_EMPRESA comparten atributos, se crea CLIENTE.

Ventajas: muy sistemática, adecuada cuando se parte de documentos existentes (formularios en papel, hojas de cálculo, un sistema antiguo). Inconvenientes: el esquema puede necesitar mucha reestructuración al final, porque los grupos no siempre encajan.

3.3. Estrategia centrífuga (inside-out)

Se parte del concepto más importante del sistema y se va extendiendo “en mancha de aceite”, añadiendo los conceptos más cercanos a los ya incluidos.

flowchart LR
    MATRICULA[MATRICULA] --- ALUMNO[ALUMNO]
    MATRICULA --- ASIGNATURA[ASIGNATURA]
    ASIGNATURA --- PROFESOR[PROFESOR]
    ASIGNATURA --- TITULACION[TITULACION]
    PROFESOR --- DEPARTAMENTO[DEPARTAMENTO]
    ALUMNO --- BECA[BECA]

(Esquema de conceptos, sin notación E/R: muestra el orden de expansión. Primero la matrícula; después alumno y asignatura; después profesor, titulación y beca; por último departamento.)

Ventajas: natural, se avanza siempre desde algo conocido. Inconvenientes: la visión global llega tarde; es fácil olvidar conceptos alejados del centro.

3.4. Estrategia mixta

Combina la descendente y la ascendente: primero se define un esquema esqueleto (skeleton schema) con los conceptos principales y sus relaciones (descendente) y después se diseña cada zona por separado, a menudo de forma ascendente o centrífuga, encajándola en el esqueleto. Es la estrategia más usada en proyectos reales y en los exámenes largos.

3.5. Comparación

Estrategia Punto de partida Avance Ideal cuando… Riesgo
Descendente Esquema abstracto Refinamiento Se conoce bien el dominio completo Perderse en sistemas grandes
Ascendente Atributos sueltos Agrupación Hay documentos o un sistema antiguo Reestructuración costosa al final
Centrífuga Concepto central Expansión por capas Hay un concepto claramente principal Olvidar conceptos lejanos
Mixta Esqueleto + zonas Esqueleto y detalle por zonas Sistemas grandes, varios equipos Integración de las zonas

💡 Consejo: En un examen, una estrategia mixta funciona muy bien: dibuja primero en una esquina un esqueleto solo con rectángulos y rombos (sin atributos ni cardinalidades); cuando tengas claro el esqueleto, pasa a limpio y completa cada zona.

4. Integración de vistas

4.1. Diseño por vistas

En sistemas grandes, cada grupo de usuarios conoce su parte: secretaría conoce las matrículas, el profesorado conoce las calificaciones, la gerencia conoce los costes. Lo habitual es diseñar un esquema por cada grupo, llamado vista (view), y después integrarlas en un esquema global.

📘 Concepto: La integración de vistas (view integration) es el proceso de fusionar varios esquemas conceptuales parciales en un único esquema global coherente, detectando y resolviendo los conflictos entre ellos.

4.2. Tipos de conflictos

Conflicto Descripción Ejemplo
Sinónimos Nombres distintos para el mismo concepto ALUMNO (secretaría) y ESTUDIANTE (profesorado)
Homónimos Mismo nombre para conceptos distintos CURSO como “año académico” (2026-27) y como “nivel” (1º, 2º)
Estructurales El mismo concepto modelado con construcciones distintas TITULACION como atributo en una vista y como entidad en otra
De cardinalidad Cardinalidades distintas para la misma relación Una vista dice que un grupo tiene un tutor; otra, que puede tener dos
De identificador Identificadores distintos para la misma entidad ALUMNO por dni en una vista y por num_expediente en otra
De dominio Mismo atributo con tipos o unidades distintos Nota de 0 a 10 frente a calificación con letras (A, B, C)

4.3. Fases de la integración

  1. Preintegración: se decide el orden de integración (de dos en dos, empezando por las vistas más importantes, o todas a la vez) y se recopila información sobre cada vista.
  2. Comparación: se buscan las correspondencias entre conceptos de las distintas vistas y se detectan los conflictos.
  3. Conformación: se resuelven los conflictos modificando las vistas (renombrando, transformando un atributo en entidad…). Exige hablar con los usuarios.
  4. Fusión: se superponen las vistas conformadas en un esquema único.
  5. Reestructuración: se revisa el esquema resultante para eliminar redundancias (relaciones que ahora se deducen de otras) y mejorar su calidad.

4.4. Ejemplo

Vista de secretaría:

flowchart LR
    ALUMNO[ALUMNO] --- a_exp([<u>num_expediente</u>])
    ALUMNO --- a_nom([nombre])
    ALUMNO --- a_tit([titulacion])
    ALUMNO ---|"(0,n)"| matricula{"matricula<br/>N:M"}
    matricula ---|"(1,n)"| ASIGNATURA[ASIGNATURA]
    ASIGNATURA --- as_cod([<u>cod_asignatura</u>])
    ASIGNATURA --- as_cre([creditos])

Vista del profesorado:

flowchart LR
    ESTUDIANTE[ESTUDIANTE] --- e_dni([<u>dni</u>])
    ESTUDIANTE --- e_nom([nombre])
    PROFESOR[PROFESOR] ---|"(1,1)"| imparte{"imparte<br/>1:N"}
    imparte ---|"(0,n)"| MATERIA[MATERIA]
    ESTUDIANTE ---|"(0,n)"| califica{"calificado_en<br/>N:M"}
    califica ---|"(0,n)"| MATERIA
    califica --- c_not([nota])
    MATERIA --- m_cod([<u>cod_asignatura</u>])
    MATERIA --- m_tit([titulacion])
    TITULACION[TITULACION] --- t_cod([<u>cod_titulacion</u>])

Conflictos detectados:

  • Sinónimos: ALUMNO = ESTUDIANTE; ASIGNATURA = MATERIA. Se adoptan ALUMNO y ASIGNATURA.
  • Identificador: num_expediente frente a dni. Tras hablar con secretaría, se decide num_expediente como identificador y dni como clave alternativa.
  • Estructural: titulacion es atributo en las dos vistas (de ALUMNO y de ASIGNATURA) y entidad en la del profesorado. Se resuelve como entidad TITULACION.
  • Relaciones equivalentes: matricula y calificado_en no son la misma relación (un alumno matriculado puede no estar calificado aún), pero hay inclusión: calificado_en ⊆ matricula. Una solución mejor: nota como atributo de matricula.

Esquema integrado:

flowchart LR
    ALUMNO[ALUMNO] --- a_exp([<u>num_expediente</u>])
    ALUMNO --- a_dni(["dni (AK)"])
    ALUMNO --- a_nom([nombre])
    ALUMNO ---|"(0,n)"| matricula{"matricula<br/>N:M"}
    matricula ---|"(1,n)"| ASIGNATURA[ASIGNATURA]
    matricula --- m_not(["nota (0,1)"])
    ASIGNATURA --- as_cod([<u>cod_asignatura</u>])
    ASIGNATURA --- as_cre([creditos])
    PROFESOR[PROFESOR] ---|"(1,1)"| imparte{"imparte<br/>1:N"}
    imparte ---|"(0,n)"| ASIGNATURA
    ALUMNO ---|"(0,n)"| cursa{"cursa<br/>1:N"}
    cursa ---|"(1,1)"| TITULACION[TITULACION]
    ASIGNATURA ---|"(1,n)"| pertenece{"pertenece<br/>1:N"}
    pertenece ---|"(1,1)"| TITULACION
    TITULACION --- t_cod([<u>cod_titulacion</u>])

En la reestructuración aparece un ciclo ALUMNO–ASIGNATURA–TITULACION: ¿solo puede matricularse un alumno de asignaturas de su titulación? Si es así, se anota la restricción; si puede cursar optativas de otras titulaciones, el ciclo es independiente.

5. El diccionario de datos del modelo conceptual

El diagrama muestra la estructura; el diccionario de datos explica el significado. Un esquema conceptual sin diccionario es como un plano sin leyenda: se ve la forma, pero no se sabe qué es cada cosa.

5.1. Plantilla de entidades

Entidad Descripción Identificador Claves alternativas Tipo Ocurrencias estimadas
CLIENTE Persona propietaria de una o más mascotas atendidas en la clínica dni — Fuerte 3 000
MASCOTA Animal atendido en la clínica cod_mascota num_microchip Fuerte 5 000
VACUNACION Administración de una dosis de vacuna a una mascota (cod_mascota) + fecha + cod_vacuna — Débil de MASCOTA 20 000 / año
CIRUJANO Veterinario certificado para realizar operaciones num_colegiado (heredado) — Subtipo de VETERINARIO 4

5.2. Plantilla de atributos

Entidad / relación Atributo Descripción Dominio Oblig. Tipo Ejemplo
CLIENTE dni Documento nacional de identidad o NIE 8 dígitos + letra, o NIE Sí Simple, identificador 12345678Z
CLIENTE direccion Domicilio postal Compuesto: calle, cp (5 dígitos), ciudad Sí Compuesto C/ Mayor 1, 28001, Madrid
CLIENTE telefono Teléfonos de contacto 9 dígitos Sí (al menos 1) Multivaluado (1,n) 600111222
MASCOTA num_microchip Código del microchip ISO 15 dígitos No Simple, clave alternativa 941000012345678
MASCOTA especie Especie animal {‘PERRO’, ‘GATO’, ‘AVE’, ‘ROEDOR’, ‘REPTIL’, ‘OTRO’} Sí Simple GATO
receta dosis Cantidad y frecuencia de administración Texto libre (máx. 100) Sí Simple, de relación 1 comprimido cada 12 h
receta duracion_dias Días de tratamiento Entero > 0 Sí Simple, de relación 7

5.3. Plantilla de relaciones

Relación Entidades (papel) Cardinalidades Tipo Atributos Descripción
posee CLIENTE (dueño), MASCOTA CLIENTE (1,1); MASCOTA (1,n) 1:N — Un cliente es dueño de una o varias mascotas; cada mascota tiene un único dueño
receta CONSULTA, MEDICAMENTO CONSULTA (0,n); MEDICAMENTO (0,n) N:M dosis, duracion_dias En una consulta se recetan medicamentos con una dosis y duración
realiza CIRUJANO, OPERACION CIRUJANO (1,1); OPERACION (0,n) 1:N — Cada operación la realiza un único cirujano

(Recuerda la convención: “CLIENTE (1,1)” significa que la pareja (1,1) se escribe junto a CLIENTE, es decir, que cada mascota tiene exactamente un cliente.)

5.4. Plantilla de jerarquías

Supertipo Subtipos Cobertura Discriminante Descripción
VETERINARIO CIRUJANO Parcial Definida por el usuario Solo algunos veterinarios están certificados como cirujanos

5.5. Plantilla de restricciones

Id Enunciado Elementos Tipo Origen Implementación prevista
R1 La fecha de una consulta no es anterior a la fecha de nacimiento de la mascota CONSULTA.fecha_hora, MASCOTA.fecha_nacimiento Entre entidades Enunciado Trigger o aplicación
R2 Una operación se realiza en una fecha igual o posterior a la de certificación del cirujano OPERACION.fecha, CIRUJANO.fecha_certificacion Entre entidades Enunciado (implícita) Trigger o aplicación
R4 duracion_dias > 0 receta.duracion_dias Dominio Entrevista CHECK

💡 Consejo: No hace falta que en un examen escribas el diccionario completo (a menos que se pida), pero sí las restricciones y las decisiones de diseño discutibles. En un proyecto real, el diccionario es obligatorio y es lo primero que mirará quien tenga que mantener la base de datos dentro de cinco años.

6. Lista de comprobación de calidad

Un esquema conceptual puede ser sintácticamente correcto (todos los símbolos bien usados) y, aun así, ser un mal esquema. Batini, Ceri y Navathe proponen varias propiedades de calidad:

Propiedad Significado Pregunta de control
Completitud Recoge todos los requisitos ¿Puedo responder a todas las preguntas que necesita el usuario?
Corrección sintáctica Usa bien la notación ¿Cada entidad tiene identificador? ¿Cada arista, cardinalidad?
Corrección semántica Representa fielmente la realidad ¿Lo que dice el diagrama es verdad en el negocio?
Minimalidad Cada requisito aparece una sola vez; no hay redundancias ¿Sobra alguna relación, atributo o entidad?
Legibilidad Se entiende con facilidad ¿Lo entendería un compañero sin explicaciones?
Expresividad Usa las construcciones que mejor reflejan la semántica ¿Hay restricciones en notas que podrían dibujarse?
Autoexplicación Se entiende sin documentación adicional ¿Los nombres son claros y sin abreviaturas crípticas?
Extensibilidad Admite cambios previsibles sin rehacerlo ¿Qué pasa si mañana hay más de un dueño por mascota?

6.1. Checklist práctica

Antes de dar un diagrama por terminado, comprueba punto por punto:

Entidades

  • ☐ Todas en MAYÚSCULAS y en singular.
  • ☐ Todas tienen identificador subrayado (salvo subtipos, que lo heredan, y débiles, que tienen identificador parcial).
  • ☐ Ninguna tiene una sola ocurrencia (no hay “EMPRESA” si es la propia empresa).
  • ☐ Ninguna representa un proceso, un informe o un usuario del sistema.
  • ☐ Las débiles están marcadas, con su relación de identificación y su identificador parcial.

Atributos

  • ☐ No hay claves ajenas dibujadas como atributos.
  • ☐ Los multivaluados, compuestos, opcionales y derivados están marcados.
  • ☐ Cada atributo está en la entidad o relación a la que describe.
  • ☐ No hay atributos “numerados” (telefono1, telefono2).

Relaciones

  • ☐ Todas tienen un nombre (verbo) y cardinalidades (mín, máx) en todas sus aristas.
  • ☐ Las cardinalidades se han escrito en el lado correcto según la convención del curso.
  • ☐ Las relaciones reflexivas tienen sus papeles indicados.
  • ☐ Las N:M que deben admitir repetición están reificadas.
  • ☐ Los ciclos están analizados (redundantes eliminados, restricciones anotadas).
  • ☐ No hay trampas de abanico ni de sima en las consultas importantes.

Jerarquías y restricciones

  • ☐ Cada jerarquía tiene cobertura indicada y cumple la regla de oro.
  • ☐ Las restricciones que no caben en el diagrama están numeradas y escritas.
  • ☐ Las decisiones discutibles están justificadas.

7. Los errores más frecuentes

Esta sección recoge los errores que más se repiten en los exámenes y prácticas, con un ejemplo incorrecto y su corrección.

7.1. Dibujar claves ajenas como atributos

Incorrecto: EMPLEADO con un atributo cod_departamento, además de la relación trabaja.

flowchart LR
    EMPLEADO[EMPLEADO] --- e_id([<u>num_empleado</u>])
    EMPLEADO --- e_dep([cod_departamento])
    EMPLEADO ---|"(0,n)"| trabaja{"trabaja<br/>1:N"}
    trabaja ---|"(1,1)"| DEPARTAMENTO[DEPARTAMENTO]

Correcto: la relación trabaja ya expresa a qué departamento pertenece el empleado. La clave ajena aparece solo al pasar a tablas.

flowchart LR
    EMPLEADO[EMPLEADO] --- e_id([<u>num_empleado</u>])
    EMPLEADO ---|"(0,n)"| trabaja{"trabaja<br/>1:N"}
    trabaja ---|"(1,1)"| DEPARTAMENTO[DEPARTAMENTO]

⚠️ Importante: Este es el error número uno de quienes ya saben algo de SQL. El modelo E/R es conceptual: no hay claves ajenas, hay relaciones.

7.2. Cardinalidades en el lado contrario

Incorrecto (para “cada empleado trabaja en un departamento y un departamento tiene muchos empleados”):

flowchart LR
    EMPLEADO[EMPLEADO] ---|"(1,1)"| trabaja{"trabaja<br/>1:N"}
    trabaja ---|"(0,n)"| DEPARTAMENTO[DEPARTAMENTO]

Este diagrama dice que cada departamento tiene exactamente un empleado y que un empleado trabaja en muchos departamentos. Correcto: la pareja junto a DEPARTAMENTO responde a “¿en cuántos departamentos trabaja un empleado?” → (1,1). Es el diagrama de la sección 7.1.

7.3. Olvidar las cardinalidades mínimas o poner solo “1:N”

Escribir solo 1 y N en las aristas pierde la información de obligatoriedad. En este curso, siempre (mín, máx).

7.4. Entidades sin identificador o con identificador no válido

Incorrecto: CLIENTE identificado por nombre, PRODUCTO sin identificador, MASCOTA identificada por num_microchip (opcional). Correcto: un identificador único, obligatorio y estable para cada entidad fuerte.

7.5. Modelar el propio sistema o la empresa como entidad

Incorrecto: una entidad CLINICA relacionada con todo (“la clínica tiene veterinarios”, “la clínica tiene quirófanos”), cuando solo hay una clínica. Correcto: eliminarla. Solo es entidad si hay varias (una cadena de clínicas con sedes).

7.6. Modelar procesos, informes o usuarios de la aplicación

Incorrecto: entidades LISTADO_MENSUAL, FORMULARIO_ALTA, ADMINISTRADOR_SISTEMA (salvo que el sistema gestione sus usuarios como datos). Correcto: el modelo describe los datos del negocio; los informes son consultas sobre esos datos.

7.7. Atributos numerados en lugar de multivaluados

Incorrecto: telefono1, telefono2, telefono3. Correcto: un atributo multivaluado telefono (o una entidad TELEFONO si cada teléfono tiene tipo y extensión).

flowchart LR
    CLIENTE[CLIENTE] --- c_dni([<u>dni</u>])
    CLIENTE --- c_tel(((telefono)))

7.8. Atributo en el sitio equivocado

Incorrecto: nota como atributo de ALUMNO (¿la nota de qué asignatura?) o de ASIGNATURA (¿la nota de qué alumno?). Correcto: atributo de la relación N:M matricula.

flowchart LR
    ALUMNO[ALUMNO] ---|"(0,n)"| matricula{"matricula<br/>N:M"}
    matricula ---|"(1,n)"| ASIGNATURA[ASIGNATURA]
    matricula --- m_not(["nota (0,1)"])

7.9. Atributo que debería ser entidad

Incorrecto: especialidad como atributo de MEDICO cuando el enunciado dice que “de cada especialidad se guarda el jefe de servicio y la planta”. Correcto: entidad ESPECIALIDAD relacionada con MEDICO. La pista: el “atributo” tiene sus propios atributos.

7.10. Entidad que debería ser atributo

Incorrecto: una entidad COLOR con un único atributo nombre, relacionada con COCHE, sin que el enunciado pida nada más de los colores. Correcto: atributo color en COCHE. (Aunque en el diseño lógico pueda decidirse una tabla de colores para controlar los valores válidos.)

7.11. Relaciones N:M con repetición sin reificar

Incorrecto: PACIENTE –visita (N:M) con atributo fecha– MEDICO, cuando un paciente visita muchas veces al mismo médico. Correcto: entidad CITA o CONSULTA (módulo 13, sección 8).

7.12. Relaciones redundantes en ciclos

Incorrecto: ALUMNO–GRUPO–CURSO más ALUMNO–CURSO cuando el curso se deduce del grupo. Correcto: eliminar la relación deducible (módulo 13, sección 6).

7.13. Usar “tiene” para todo

Incorrecto: diez rombos llamados tiene. Correcto: verbos que expresen el significado: posee, trabaja, imparte, contiene, realiza. Si dos relaciones se llaman igual, el diccionario no puede distinguirlas.

7.14. Nombres en plural, en minúsculas o con abreviaturas

Incorrecto: CLIENTES, pedido, PRD, F_ALT. Correcto: CLIENTE, PEDIDO, PRODUCTO, fecha_alta. Las entidades representan tipos (en singular); el plural lo reservamos para las tablas del modelo relacional, como en el esquema EMPRESA.

7.15. Marcar como débil cualquier entidad del lado N

Incorrecto: marcar EMPLEADO como débil de DEPARTAMENTO porque “todo empleado tiene un departamento”. Correcto: EMPLEADO tiene identificador propio y existe aunque cambie de departamento: es fuerte con participación obligatoria. Débil es la que depende de otra para existir o identificarse (líneas de pedido, habitaciones de un hotel, ejemplares de un libro).

7.16. Jerarquías innecesarias

Incorrecto: CLIENTE → NACIONAL, EXTRANJERO sin atributos ni relaciones propios. Correcto: atributo tipo (módulo 11, sección 11).

7.17. Jerarquías sin cobertura o con identificador en los subtipos

Incorrecto: hexágono vacío; dni repetido en cada subtipo. Correcto: cobertura siempre indicada; identificador solo en el supertipo.

7.18. Romper una ternaria en binarias (o al revés)

Incorrecto: sustituir “un proveedor suministra una pieza a un proyecto” por tres binarias, perdiendo qué proveedor suministra qué pieza a qué proyecto; o usar una ternaria cuando los tres hechos son independientes. Correcto: analizarlo con ocurrencias (lo verás en el módulo de relaciones ternarias).

7.19. Ignorar el tiempo

Incorrecto: EMPLEADO –trabaja (1:N)– DEPARTAMENTO cuando el enunciado dice “se quiere conocer en qué departamentos ha trabajado cada empleado”. Correcto: entidad de historial con fechas (módulo 13, sección 7).

7.20. Eliminar datos “congelados” por creerlos redundantes

Incorrecto: quitar precio_unitario de la línea de pedido “porque ya está en el producto”. Correcto: mantenerlo: es el precio en el momento de la venta, no el precio actual (módulo 13, sección 7.4).

7.21. Tabla resumen

Nº Error Pregunta que lo evita
1 Claves ajenas como atributos ¿Este atributo es en realidad una relación?
2 Cardinalidades al revés ¿He leído la pareja desde la otra entidad?
3 Sin mínimas ¿Qué pasa el primer día?
4 Sin identificador válido ¿Es único, obligatorio y estable?
5 El sistema como entidad ¿Hay más de una ocurrencia?
6 Procesos o informes como entidades ¿Es un dato del negocio o una función de la aplicación?
7 Atributos numerados ¿Puede tener varios valores?
8 Atributo mal colocado ¿De quién depende este dato?
9 Atributo que debería ser entidad ¿Tiene sus propios datos?
10 Entidad que debería ser atributo ¿Aporta algo además del nombre?
11 N:M con repetición ¿Puede repetirse el mismo par?
12 Ciclos redundantes ¿Se deduce esta relación de otras?
13 “tiene” para todo ¿El nombre explica el hecho?
14 Plurales y abreviaturas ¿Lo entendería otra persona?
15 Débiles por error ¿Existe y se identifica por sí misma?
16 Jerarquías innecesarias ¿Los subtipos tienen algo propio?
17 Jerarquías incompletas ¿He indicado la cobertura?
18 Ternarias mal resueltas ¿Reconstruyo los hechos a partir de las binarias?
19 Ignorar el tiempo ¿Interesa el valor anterior?
20 Eliminar datos congelados ¿Debe cambiar si cambia el original?

8. Comparación de notaciones

El curso usa la notación de Chen extendida, pero en el mundo profesional encontrarás otras. El significado es el mismo; cambia el dibujo.

8.1. Tabla comparativa

Notación Origen Entidad Relación Atributos Cardinalidad Jerarquías Uso típico
Chen original Chen (1976) Rectángulo Rombo Óvalos 1, N, M en las aristas No Docencia
Chen extendida (este curso) de Miguel, Piattini, Elmasri Rectángulo Rombo Óvalos (mín, máx) Triángulo o hexágono “es un” Docencia en España, diseño conceptual
Pata de gallo (IE) Martin, Finkelstein Rectángulo con atributos dentro Línea con nombre Lista dentro de la caja Símbolos en los extremos (o, |, pata de gallo) Limitadas o según herramienta Herramientas CASE, diseño lógico
Barker (Oracle) Barker (CASE*Method) Caja con esquinas redondeadas Línea con frases en cada extremo Lista con # (identificador), * (obligatorio), o (opcional) Línea continua/discontinua + pata de gallo Subtipos dentro del supertipo Oracle SQL Developer Data Modeler
IDEF1X Gobierno de EE. UU. Caja (esquinas redondeadas si es dependiente) Línea con punto Lista dentro, clave separada Punto relleno, letras P, Z, n Círculo con líneas Administración, defensa
UML (diagrama de clases) OMG Clase Asociación Lista de atributos Multiplicidad 0..1, 1, 0..*, 1..* Flecha de generalización Ingeniería del software

💡 Consejo: La convención de cardinalidades de este curso (la pareja junto a la entidad A indica con cuántas A se relaciona una ocurrencia de la otra) coincide con la forma de leer la multiplicidad UML y la pata de gallo: el símbolo se escribe en el extremo de la entidad “contada”. Por eso es muy fácil pasar de una a otra. La convención contraria (participación, a veces llamada look-here, típica de Merise) se explica en el módulo 06.

8.2. El mismo modelo en tres notaciones

Requisito: cada asignatura la imparte exactamente un profesor; un profesor imparte de 0 a n asignaturas. Del profesor interesa el DNI y el nombre; de la asignatura, el código y los créditos.

Chen extendida (este curso):

flowchart LR
    PROFESOR[PROFESOR] ---|"(1,1)"| imparte{"imparte<br/>1:N"}
    imparte ---|"(0,n)"| ASIGNATURA[ASIGNATURA]
    PROFESOR --- p_dni([<u>dni</u>])
    PROFESOR --- p_nom([nombre])
    ASIGNATURA --- a_cod([<u>codigo</u>])
    ASIGNATURA --- a_cre([creditos])

Pata de gallo (Mermaid erDiagram): || = exactamente uno; o{ = cero o muchos.

erDiagram
    PROFESOR ||--o{ ASIGNATURA : imparte
    PROFESOR {
        string dni PK
        string nombre
    }
    ASIGNATURA {
        string codigo PK
        int creditos
    }

UML (Mermaid classDiagram):

classDiagram
    class Profesor {
        dni
        nombre
    }
    class Asignatura {
        codigo
        creditos
    }
    Profesor "1" -- "0..*" Asignatura : imparte
Concepto Chen extendida Pata de gallo UML
Exactamente uno (1,1) \|\| 1
Cero o uno (0,1) o\| 0..1
Uno o muchos (1,n) \|{ 1..*
Cero o muchos (0,n) o{ 0..* o *
Identificador Subrayado PK No estándar (estereotipo o {id})
Relación N:M con atributos Rombo con atributos Entidad asociativa Clase asociación
Jerarquía Hexágono “es un” Según herramienta Flecha de generalización con {complete, disjoint}

⚠️ Importante: El erDiagram de Mermaid y la mayoría de herramientas de pata de gallo modelan tablas, no conceptos: no tienen rombos, ni atributos multivaluados, ni jerarquías, ni relaciones N:M con atributos (se dibuja la entidad asociativa). Por eso son ideales para el modelo lógico y menos expresivas para el conceptual.

9. Herramientas de modelado

9.1. Tabla comparativa

Herramienta Tipo y licencia Plataforma Notaciones Genera SQL / ingeniería inversa Recomendada para
draw.io / diagrams.net Gratuita, código abierto Web y escritorio Chen (biblioteca Entity Relation), pata de gallo, UML; cualquier notación dibujando a mano No está orientada a generar SQL Dibujar diagramas conceptuales en cualquier notación, incluida la del curso
ERDPlus Gratuita (web, con cuenta) Web Diagramas E/R estilo Chen, esquemas relacionales, esquemas en estrella Convierte E/R a relacional y genera DDL SQL Docencia: dibujar el E/R y ver su paso a tablas
Dia Gratuita, código abierto (GPL) Escritorio (Windows, Linux, macOS) Formas E/R de Chen, UML, diagramas de bases de datos No Diagramas sencillos sin conexión; desarrollo poco activo
Oracle SQL Developer Data Modeler Gratuita (Oracle) Escritorio (Java) Modelo lógico en Barker (por defecto), Bachman o Information Engineering; subtipos Genera DDL (Oracle y otros SGBD), ingeniería inversa, comparación de modelos Diseño lógico y físico profesional sobre Oracle
MySQL Workbench Gratuita (Community, GPL) Escritorio Modelos de tablas (los llama “EER”) en varias notaciones: propia, pata de gallo, IDEF1X, UML, entre otras Ingeniería directa e inversa con MySQL Modelo físico de bases de datos MySQL
dbdiagram.io Freemium Web Tablas y relaciones (estilo pata de gallo) descritas con el lenguaje DBML Exporta SQL para varios SGBD e importa esquemas Esbozar rápidamente un modelo lógico escribiendo texto
Mermaid Gratuita, código abierto Texto (integrado en GitHub, GitLab, Jekyll, editores Markdown) erDiagram (pata de gallo), classDiagram (UML), flowchart (Chen extendida, como en este curso) No Documentación versionada junto al código; apuntes
PlantUML Gratuita, código abierto Texto (Java; extensiones para muchos editores) Diagramas IE (pata de gallo), UML de clases y, en versiones recientes, E/R de Chen con subclases y uniones (@startchen) No Documentación técnica en texto

Otras herramientas que encontrarás: Lucidchart y Visual Paradigm (comerciales, con versiones educativas), StarUML (UML), pgModeler (PostgreSQL), DBeaver (genera diagramas de tablas a partir de una base de datos existente).

9.2. Cómo elegir

Necesidad Herramienta recomendada
Dibujar un E/R conceptual en la notación del curso para entregar draw.io o Mermaid
Ver cómo un E/R se transforma en tablas ERDPlus
Diseñar y generar el DDL de una base de datos Oracle Oracle SQL Developer Data Modeler
Documentar en un repositorio Git, con control de versiones Mermaid o PlantUML
Esbozar un modelo lógico en cinco minutos dbdiagram.io
Obtener el diagrama de una base de datos que ya existe SQL Developer Data Modeler (ingeniería inversa), DBeaver, MySQL Workbench

9.3. Ejemplo: el diagrama del curso en Mermaid

Todos los diagramas de este curso están escritos en Mermaid. Para escribir el tuyo:

flowchart LR
    classDef debil stroke-width:4px
    classDef derivado stroke-dasharray: 5 5
    CLIENTE[CLIENTE] ---|"(1,1)"| realiza{"realiza<br/>1:N"}
    realiza ---|"(0,n)"| PEDIDO[PEDIDO]
    CLIENTE --- c_dni([<u>dni</u>])
    CLIENTE --- c_ema(["email (AK)"])
    CLIENTE --- c_tel(((telefono)))
    PEDIDO --- p_num([<u>num_pedido</u>])
    PEDIDO --- p_tot([importe_total]):::derivado
    PEDIDO ---|"(1,1)"| contiene{"contiene<br/>ID"}:::debil
    contiene ---|"(1,n)"| LINEA[LINEA_PEDIDO]:::debil

Reglas para que funcione:

  • Cada nodo necesita un id sin espacios ni tildes (c_dni, p_tot); la etiqueta, entre corchetes, puede llevar tildes.
  • Las etiquetas con paréntesis o caracteres especiales van entre comillas: (["telefono (0,1)"]), ---|"(1,n)"|.
  • [ ] rectángulo (entidad), { } rombo (relación), ([ ]) óvalo (atributo), ((( ))) doble círculo (multivaluado), {{ }} hexágono (jerarquía).
  • El tipo de correspondencia va dentro del rombo: {"realiza<br/>1:N"}. En las relaciones de una entidad débil se escribe ID (dependencia en identificación) o E (solo en existencia) y se añade :::debil.
  • Las claves alternativas llevan (AK) en la etiqueta del atributo: (["email (AK)"]).
  • Puedes probarlo en el editor en línea oficial de Mermaid (Mermaid Live Editor) o en cualquier editor Markdown con vista previa.

10. Cómo presentar un diagrama en un examen

Un diagrama correcto pero ilegible puntúa menos que uno con un pequeño error pero claro. Estos consejos te ayudarán a sacar el máximo partido de tu trabajo.

10.1. Antes de dibujar

  1. Lee el enunciado completo dos veces y subraya con colores (entidades, relaciones, cardinalidades).
  2. Haz un borrador en una hoja aparte: solo rectángulos y rombos, sin atributos. Mueve cosas hasta que no se crucen líneas.
  3. Reparte el tiempo: en un ejercicio de 45 minutos, unos 10 de lectura y borrador, 25 de diagrama limpio, 10 de restricciones y revisión.

10.2. Al dibujar

Consejo Por qué
Coloca la entidad más conectada en el centro Reduce los cruces de líneas
Usa lápiz y regla, o al menos traza recto Se corrige y se lee mejor
Escribe entidades en MAYÚSCULAS y relaciones en minúsculas Se distinguen de un vistazo
Pon las cardinalidades cerca de la entidad a la que se refieren Evita ambigüedades
No cruces líneas; si no hay más remedio, usa un “puente” Legibilidad
Agrupa los atributos alrededor de su entidad, sin mezclarlos Evita que un óvalo parezca de otra entidad
Si el diagrama es grande, divídelo en partes con entidades compartidas Cabe en la hoja y se lee mejor
Incluye una leyenda si usas símbolos no estándar El corrector sabe qué significa cada cosa

10.3. Después de dibujar

  1. Lista de supuestos: escribe debajo del diagrama las suposiciones que has hecho donde el enunciado era ambiguo (“Supongo que un cliente puede no tener pedidos todavía”). Un supuesto razonable y explícito casi nunca se penaliza; uno implícito y contrario al del corrector, sí.
  2. Restricciones numeradas (R1, R2…).
  3. Decisiones discutibles: si dudaste entre dos opciones, explica brevemente por qué elegiste una.
  4. Repasa con la checklist de la sección 6.1 al menos: identificadores, cardinalidades en todas las aristas, coberturas, nombres.

💡 Consejo: Un corrector valora sobre todo tres cosas: que cada requisito del enunciado aparezca en el diagrama, que las cardinalidades sean correctas y que el diagrama se pueda leer. Si vas mal de tiempo, prioriza terminar las entidades, relaciones y cardinalidades antes que dibujar todos los atributos secundarios.

11. Ejercicios

Ejercicio 1: Aplicar la metodología completa

Aplica los diez pasos de la sección 2 al siguiente enunciado, mostrando la tabla de candidatos, los identificadores elegidos, las cardinalidades razonadas y el diagrama final:

Una escuela de idiomas ofrece cursos de varios idiomas (código, nombre). Cada curso (código, idioma, nivel A1-C2, fecha de inicio, fecha de fin, precio) lo imparte un profesor (DNI, nombre, idiomas que puede enseñar). Los alumnos (número de alumno, nombre, email, teléfono) se matriculan en cursos; de cada matrícula se guarda la fecha y si está pagada. Cada curso se imparte en un aula (número, capacidad). Al terminar el curso, cada alumno obtiene una calificación final.

Ver solución

Paso 1-2. Candidatos:

Candidato Decisión Motivo
IDIOMA Entidad Tiene código y nombre; lo usan cursos y profesores
CURSO Entidad Código propio, varios atributos
PROFESOR Entidad DNI y datos propios
ALUMNO Entidad Número de alumno
AULA Entidad Número y capacidad
matrícula Relación N:M con atributos Un alumno en varios cursos; un curso con varios alumnos; cada par una sola vez
nivel Atributo de CURSO Valores A1-C2
calificación Atributo de la matrícula Depende del alumno y del curso

Paso 3. Identificadores: IDIOMA: cod_idioma; CURSO: cod_curso; PROFESOR: dni; ALUMNO: num_alumno (email como clave alternativa si es único); AULA: numero.

Pasos 4-5. Relaciones y cardinalidades:

  • de CURSO–IDIOMA: un curso es de 1 idioma (1,1) junto a IDIOMA; un idioma tiene 0..n cursos.
  • imparte PROFESOR–CURSO: un curso lo imparte 1 profesor (1,1) junto a PROFESOR; un profesor imparte 0..n cursos.
  • sabe PROFESOR–IDIOMA: un profesor puede enseñar 1..n idiomas; un idioma lo pueden enseñar 0..n profesores.
  • matricula ALUMNO–CURSO: un alumno se matricula en 1..n cursos (es alumno porque se ha matriculado al menos una vez); un curso tiene 0..n alumnos.
  • se_imparte_en CURSO–AULA: un curso en 1 aula; un aula, 0..n cursos.

Paso 6. Atributos: fecha_matricula, pagada y calificacion en matricula (calificacion opcional hasta que acaba el curso).

Pasos 7-8. No hay débiles ni jerarquías. Las matrículas no se repiten (un alumno no se matricula dos veces del mismo curso concreto; si repite nivel, es otro curso con otro código).

flowchart TB
    IDIOMA[IDIOMA] --- i_cod([<u>cod_idioma</u>])
    IDIOMA --- i_nom([nombre])
    CURSO[CURSO] --- c_cod([<u>cod_curso</u>])
    CURSO --- c_niv([nivel])
    CURSO --- c_ini([fecha_inicio])
    CURSO --- c_fin([fecha_fin])
    CURSO --- c_pre([precio])
    CURSO ---|"(0,n)"| de{"de<br/>1:N"}
    de ---|"(1,1)"| IDIOMA
    PROFESOR[PROFESOR] --- p_dni([<u>dni</u>])
    PROFESOR --- p_nom([nombre])
    PROFESOR ---|"(1,1)"| imparte{"imparte<br/>1:N"}
    imparte ---|"(0,n)"| CURSO
    PROFESOR ---|"(0,n)"| sabe{"sabe<br/>N:M"}
    sabe ---|"(1,n)"| IDIOMA
    ALUMNO[ALUMNO] --- a_num([<u>num_alumno</u>])
    ALUMNO --- a_nom([nombre])
    ALUMNO --- a_ema([email])
    ALUMNO --- a_tel([telefono])
    ALUMNO ---|"(0,n)"| matricula{"matricula<br/>N:M"}
    matricula ---|"(1,n)"| CURSO
    matricula --- m_fec([fecha_matricula])
    matricula --- m_pag([pagada])
    matricula --- m_cal(["calificacion (0,1)"])
    CURSO ---|"(0,n)"| en{"se_imparte_en<br/>1:N"}
    en ---|"(1,1)"| AULA[AULA]
    AULA --- au_num([<u>numero</u>])
    AULA --- au_cap([capacidad])

Paso 9. Restricciones:

  • R1: nivel ∈ {A1, A2, B1, B2, C1, C2}.
  • R2: fecha_fin > fecha_inicio.
  • R3: el número de alumnos matriculados en un curso no supera la capacidad de su aula.
  • R4: el profesor que imparte un curso sabe el idioma del curso (ciclo PROFESOR–CURSO–IDIOMA con caminos coincidentes).
  • R5: un aula no tiene dos cursos con fechas y horarios solapados (si se añade el horario).
  • R6: la calificación solo puede registrarse después de fecha_fin.

Paso 10. Validación: “¿Un curso puede tener dos profesores?”, “¿Un curso se imparte siempre en la misma aula?”, “¿Interesa el horario?”. Son preguntas para el usuario que conviene escribir como supuestos.

Ejercicio 2: Integración de dos vistas

Integra estas dos vistas de una cadena de librerías y enumera los conflictos:

  • Vista de compras: LIBRO (isbn, titulo, editorial), PROVEEDOR (cif, nombre), relación N:M suministra con atributo precio_compra.
  • Vista de ventas: OBRA (isbn, titulo, autor, precio_venta), TIENDA (codigo, ciudad), relación N:M tiene_stock con atributo unidades, y EDITORIAL (codigo, nombre, pais) relacionada 1:N con OBRA.
Ver solución

Conflictos:

  1. Sinónimos: LIBRO = OBRA (mismo identificador isbn). Se adopta LIBRO.
  2. Estructural: editorial es atributo en compras y entidad en ventas. Se adopta la entidad EDITORIAL, que tiene atributos propios (país).
  3. Posible conflicto estructural: autor es atributo en ventas. Si un libro puede tener varios autores, debería ser multivaluado o entidad AUTOR; se plantea al usuario. Supuesto: entidad AUTOR, N:M.
  4. Sin conflicto: los atributos precio_compra (de suministra) y precio_venta (de LIBRO) son distintos.
flowchart TB
    LIBRO[LIBRO] --- l_isbn([<u>isbn</u>])
    LIBRO --- l_tit([titulo])
    LIBRO --- l_pre([precio_venta])
    LIBRO ---|"(0,n)"| publica{"publica<br/>1:N"}
    publica ---|"(1,1)"| EDITORIAL[EDITORIAL]
    EDITORIAL --- e_cod([<u>codigo</u>])
    EDITORIAL --- e_nom([nombre])
    EDITORIAL --- e_pai([pais])
    LIBRO ---|"(1,n)"| escribe{"escribe<br/>N:M"}
    escribe ---|"(1,n)"| AUTOR[AUTOR]
    AUTOR --- au_id([<u>cod_autor</u>])
    AUTOR --- au_nom([nombre])
    PROVEEDOR[PROVEEDOR] ---|"(0,n)"| suministra{"suministra<br/>N:M"}
    suministra ---|"(1,n)"| LIBRO
    suministra --- s_pre([precio_compra])
    PROVEEDOR --- p_cif([<u>cif</u>])
    PROVEEDOR --- p_nom([nombre])
    TIENDA[TIENDA] ---|"(0,n)"| stock{"tiene_stock<br/>N:M"}
    stock ---|"(0,n)"| LIBRO
    stock --- st_uni([unidades])
    TIENDA --- t_cod([<u>codigo</u>])
    TIENDA --- t_ciu([ciudad])

Lectura de escribe: un libro tiene 1..n autores (junto a AUTOR) y un autor escribe 1..n libros (junto a LIBRO; solo se registran autores con algún libro). En suministra: un proveedor suministra 1..n libros; un libro lo suministran 0..n proveedores.

Ejercicio 3: Corrige el diagrama

Encuentra todos los errores del siguiente diagrama, que pretende modelar: “Los socios de un club (número de socio, nombre, teléfonos) reservan pistas (número, tipo de superficie) para una fecha y hora; un socio puede reservar la misma pista muchas veces”.

flowchart LR
    SOCIOS[SOCIOS] --- s_nom([<u>nombre</u>])
    SOCIOS --- s_t1([telefono1])
    SOCIOS --- s_t2([telefono2])
    SOCIOS --- s_pista([num_pista])
    SOCIOS ---|"N"| tiene{tiene}
    tiene ---|"M"| PISTA[PISTA]
    tiene --- t_fec([fecha_hora])
    PISTA --- p_sup([superficie])
    CLUB[CLUB] --- tiene2{tiene}
    tiene2 --- PISTA
Ver solución

Errores:

  1. SOCIOS en plural → SOCIO.
  2. Identificador nombre: no es único → num_socio.
  3. telefono1, telefono2: atributos numerados → multivaluado telefono.
  4. num_pista en SOCIO: es una clave ajena dibujada como atributo → eliminar.
  5. Cardinalidades solo con N y M, sin mínimas → (mín, máx).
  6. La relación se llama tiene (y hay otra igual) → nombre significativo (reserva).
  7. N:M con repetición (“muchas veces la misma pista”): la relación no admite repetir el par → reificar en RESERVA.
  8. PISTA sin identificador → numero.
  9. CLUB es una entidad de una sola ocurrencia (el propio sistema) y además sin atributos ni cardinalidades → eliminar.
flowchart LR
    SOCIO[SOCIO] --- s_num([<u>num_socio</u>])
    SOCIO --- s_nom([nombre])
    SOCIO --- s_tel(((telefono)))
    SOCIO ---|"(1,1)"| hace{"hace<br/>1:N"}
    hace ---|"(0,n)"| RESERVA[RESERVA]
    RESERVA --- r_id([<u>num_reserva</u>])
    RESERVA --- r_fh([fecha_hora])
    RESERVA ---|"(0,n)"| de{"de<br/>1:N"}
    de ---|"(1,1)"| PISTA[PISTA]
    PISTA --- p_num([<u>numero</u>])
    PISTA --- p_sup([superficie])

Restricción: R1: una pista no puede tener dos reservas en la misma fecha_hora (equivale a una clave alternativa (pista, fecha_hora) si las reservas son de duración fija).

Ejercicio 4: Completar el diccionario

Escribe las fichas de diccionario (entidad, atributos, relaciones y restricciones) para el diagrama corregido del ejercicio 3.

Ver solución

Entidades

Entidad Descripción Identificador Claves alternativas Tipo
SOCIO Persona asociada al club con derecho a reservar pistas num_socio — Fuerte
PISTA Pista deportiva reservable numero — Fuerte
RESERVA Uso de una pista por un socio en una fecha y hora num_reserva (numero de pista, fecha_hora) Fuerte (reificación)

Atributos

Elemento Atributo Descripción Dominio Oblig. Tipo
SOCIO num_socio Número asignado al darse de alta Entero > 0 Sí Identificador
SOCIO telefono Teléfonos de contacto 9 dígitos Sí (1..n) Multivaluado
PISTA superficie Tipo de superficie {‘TIERRA’, ‘CESPED’, ‘RESINA’, ‘CRISTAL’} Sí Simple
RESERVA fecha_hora Inicio de la reserva (duración fija 1 h) Fecha y hora en punto, entre 08:00 y 22:00 Sí Simple

Relaciones

Relación Entidades Cardinalidades Tipo
hace SOCIO, RESERVA SOCIO (1,1); RESERVA (0,n) 1:N
de RESERVA, PISTA RESERVA (0,n); PISTA (1,1) N:1

Restricciones

Id Enunciado Tipo Implementación
R1 No hay dos reservas de la misma pista con la misma fecha_hora Unicidad UNIQUE sobre (pista, fecha_hora)
R2 fecha_hora es una hora en punto entre las 08:00 y las 22:00 Dominio CHECK
R3 Un socio no puede tener más de 2 reservas futuras Cardinalidad condicionada Trigger o aplicación

Ejercicio 5: Pasar de notación

Dibuja en pata de gallo (Mermaid erDiagram) el diagrama corregido del ejercicio 3, y explica qué información de la notación de Chen se pierde.

Ver solución
erDiagram
    SOCIO ||--o{ RESERVA : hace
    PISTA ||--o{ RESERVA : "es reservada en"
    SOCIO {
        int num_socio PK
        string nombre
    }
    RESERVA {
        int num_reserva PK
        datetime fecha_hora
    }
    PISTA {
        int numero PK
        string superficie
    }

Información que se pierde o cambia:

  • El atributo multivaluado telefono no se puede representar: en pata de gallo habría que crear una entidad TELEFONO_SOCIO.
  • No hay rombos: las relaciones son solo líneas con un nombre.
  • La distinción entre entidad y “relación reificada” desaparece: RESERVA es una caja más.
  • SOCIO ||--o{ RESERVA equivale a (1,1) junto a SOCIO y (0,n) junto a RESERVA: la posición de los símbolos coincide con la convención del curso.

Ejercicio 6: Evaluar la calidad

Evalúa con las propiedades de la sección 6 el esquema integrado de la sección 4.4. Indica al menos un punto fuerte y un punto débil por propiedad (completitud, corrección, minimalidad, legibilidad, extensibilidad).

Ver solución
Propiedad Punto fuerte Punto débil o pregunta abierta
Completitud Recoge todos los conceptos de las dos vistas No sabemos de qué curso académico es cada matrícula: si un alumno repite una asignatura, falta información (relación con repetición)
Corrección Identificadores elegidos tras resolver el conflicto imparte con (1,1) junto a PROFESOR impide que una asignatura tenga varios profesores (¿es real?)
Minimalidad Se ha eliminado calificado_en integrándola como atributo nota El ciclo ALUMNO–ASIGNATURA–TITULACION debe analizarse
Legibilidad Nombres claros y en singular Las relaciones cursa y pertenece se cruzan visualmente
Extensibilidad TITULACION como entidad permite añadir datos (créditos, rama) Si mañana una asignatura pertenece a varias titulaciones (asignaturas compartidas), pertenece debe pasar a N:M

La pregunta más importante para el usuario: ¿un alumno puede matricularse varias veces de la misma asignatura? Si la respuesta es sí (lo es en casi todas las universidades), matricula debe convertirse en una entidad MATRICULA con el curso académico como parte de la identificación.

Ejercicio 7 (propuesto): Estrategia ascendente

A partir de los siguientes datos extraídos de las facturas en papel de un taller, aplica la estrategia ascendente para obtener el diagrama E/R: número de factura, fecha, matrícula, marca, modelo, km, nombre del cliente, NIF del cliente, teléfono del cliente, concepto de cada línea, horas de mano de obra, código de pieza, descripción de pieza, unidades, precio unitario, nombre del mecánico, total, IVA.

Ejercicio 8 (propuesto): Elegir herramienta

Instala o abre dos de las herramientas de la sección 9 (por ejemplo, draw.io y ERDPlus) y dibuja con ambas el diagrama de la clínica veterinaria de la sección 2. Compara: tiempo empleado, facilidad para representar la jerarquía y la entidad débil, posibilidad de exportar y, en ERDPlus, el esquema relacional que genera. Escribe una conclusión de media página.

Resumen

Concepto Idea clave
Esquema conceptual Diagrama E/R + diccionario de datos + catálogo de restricciones
Análisis lingüístico Sustantivos → entidades/atributos; verbos → relaciones; cuantificadores → cardinalidades
Criterios de entidad Varias ocurrencias, interés, atributos propios, identificable
Identificador Único, obligatorio, estable, mínimo, preferiblemente corto
Cardinalidades Dos preguntas, una en cada sentido; pensar en “el primer día” para las mínimas
Validación Leer el diagrama en voz alta al usuario, frase a frase
Estrategia descendente De lo abstracto a lo concreto mediante primitivas de refinamiento
Estrategia ascendente De los atributos a las entidades, relaciones y generalizaciones
Estrategia centrífuga Desde el concepto central hacia fuera
Estrategia mixta Esqueleto global + diseño por zonas
Integración de vistas Preintegración, comparación, conformación, fusión, reestructuración
Conflictos Sinónimos, homónimos, estructurales, cardinalidad, identificador, dominio
Calidad Completitud, corrección, minimalidad, legibilidad, expresividad, extensibilidad
Errores clave Claves ajenas como atributos, cardinalidades al revés, sin mínimas, N:M con repetición, jerarquías innecesarias
Notaciones Chen extendida (conceptual), pata de gallo e IDEF1X (lógico), Barker (Oracle), UML
Herramientas draw.io, ERDPlus, Dia, SQL Developer Data Modeler, MySQL Workbench, dbdiagram.io, Mermaid, PlantUML
Examen Borrador, entidad central en medio, cardinalidades en todas las aristas, supuestos y restricciones por escrito
Navegación  
← Módulo anterior: Restricciones avanzadas Siguiente módulo: Casos prácticos E/R →