Módulo 05: Entidades y atributos
Objetivos del módulo
- Definir con precisión qué es una entidad y distinguir entre tipo de entidad y ocurrencia (ejemplar)
- Diferenciar las entidades fuertes (regulares) de las débiles
- Aplicar criterios para decidir si un concepto es entidad o atributo, incluso en los casos ambiguos
- Conocer los atributos, sus dominios y todos sus tipos: simples y compuestos, monovaluados y multivaluados, almacenados y derivados, obligatorios y opcionales
- Entender el significado de los valores nulos y cómo influye el diseño en ellos
- Dominar los identificadores: superclave, clave candidata, identificador principal, claves alternativas, identificadores compuestos, claves naturales y subrogadas
- Elegir el identificador principal de una entidad con criterios profesionales
- Comparar las principales notaciones del modelo E/R (Chen, Chen extendida, pata de gallo, UML, IDEF1X y Barker)
- Reconocer y evitar los errores frecuentes al modelar entidades y atributos
1. Entidades
1.1 Qué es una entidad
En el módulo anterior vimos que el modelo E/R describe la realidad mediante “cosas” y las asociaciones entre ellas. Esas “cosas” son las entidades.
📘 Concepto: Una entidad (entity) es un objeto del mundo real, concreto o abstracto, que existe por sí mismo, que se puede distinguir de los demás objetos y del que interesa guardar información en la base de datos.
La definición tiene tres partes, y las tres son importantes:
- Objeto concreto o abstracto: puede ser algo físico (un coche, un libro, una persona) o algo conceptual (una asignatura, un pedido, una cuenta bancaria, una reserva).
- Distinguible: cada objeto se puede diferenciar de los demás de su clase. Si no podemos distinguir dos objetos, no podemos guardarlos como entidades separadas.
- Interesa guardar información: un concepto solo es entidad si es relevante para el sistema. En la base de datos de un taller, los clientes son entidades; los proveedores de café de la máquina de la sala de espera, no.
1.2 Tipo de entidad y ocurrencia
Cuando decimos “la entidad CLIENTE”, en realidad nos referimos a dos cosas distintas que conviene separar:
📘 Concepto: Un tipo de entidad (entity type) es la descripción común de un conjunto de objetos que tienen las mismas propiedades: CLIENTE, LIBRO, ASIGNATURA. Es lo que se dibuja en el diagrama.
📘 Concepto: Una ocurrencia o ejemplar de entidad (entity instance) es cada uno de los objetos concretos que pertenecen a ese tipo: el cliente “Laura Gómez”, el libro “El Quijote” de la edición de 2015, la asignatura “Bases de Datos”. El conjunto de ocurrencias existentes en un momento dado se llama conjunto de entidades (entity set).
Es la misma diferencia que existe entre una clase y sus objetos en programación orientada a objetos, o entre el molde y las galletas: el molde (tipo) define la forma; cada galleta (ocurrencia) es un objeto concreto.
flowchart LR
subgraph TIPO["Tipo de entidad (esquema)"]
LIBRO[LIBRO]
end
subgraph OCURR["Ocurrencias (ejemplar de la BD)"]
l1["isbn 978-84-376-0494-7<br/>Cien años de soledad"]
l2["isbn 978-84-206-5101-3<br/>La Regenta"]
l3["isbn 978-84-670-2908-7<br/>Fortunata y Jacinta"]
end
LIBRO -.->|"tiene como ocurrencias"| l1
LIBRO -.-> l2
LIBRO -.-> l3
| Tipo de entidad | Algunas ocurrencias |
|---|---|
| PROFESOR | Marta Ruiz, Pedro Sanz, Ana López |
| ASIGNATURA | Bases de Datos, Programación, Sistemas Informáticos |
| VEHICULO | 1234-KLM, 5678-BCD, 9012-FGH |
| PEDIDO | Pedido 5001, pedido 5002, pedido 5003 |
| DEPARTAMENTO (EMPRESA) | 10 Dirección, 20 Ventas, 30 Informática… |
⚠️ Importante: En el diagrama se dibujan tipos, nunca ocurrencias. Un error típico de principiante es dibujar una entidad VALENCIA y otra MADRID: son ocurrencias (valores) de un tipo CIUDAD, o simplemente valores de un atributo ciudad.
1.3 Representación y nombres
En la notación del curso, una entidad se representa con un rectángulo que contiene su nombre:
flowchart LR
CLIENTE[CLIENTE]
PRODUCTO[PRODUCTO]
LINEA_PEDIDO[LINEA_PEDIDO]
Convenciones de nombre:
- Sustantivo en singular: CLIENTE, no CLIENTES. El rectángulo representa el tipo, y cada ocurrencia es un cliente. (En el modelo relacional, en cambio, el curso usa plural para las tablas:
clientes,empleados.) - MAYÚSCULAS, sin espacios ni tildes, con guion bajo si hacen falta varias palabras: LINEA_PEDIDO, CUENTA_BANCARIA.
- Significativo y propio del negocio: el nombre que usan los usuarios. Si en la clínica dicen “paciente”, no lo llames CLIENTE.
- Único en todo el esquema: no puede haber dos entidades con el mismo nombre.
1.4 ¿Cuándo es algo realmente una entidad?
Antes de dibujar un rectángulo, comprueba que el candidato cumple estas condiciones:
| Condición | Pregunta | Contraejemplo |
|---|---|---|
| Relevancia | ¿Necesita el sistema guardar información sobre esto? | En una biblioteca, la entidad ESTANTERIA probablemente no interesa |
| Varias ocurrencias | ¿Habrá más de un ejemplar? | EMPRESA en la base de datos de una única empresa |
| Identificable | ¿Puedo distinguir unas ocurrencias de otras? | “Arena” en una obra (se mide, no se cuentan “arenas”) |
| Propiedades propias | ¿Tiene atributos que interesan, además de su nombre? | COLOR, si solo interesa el nombre del color |
| Existencia propia | ¿Tiene sentido por sí mismo, no solo como característica de otra cosa? | FECHA_NACIMIENTO es una propiedad, no un objeto |
1.5 Clasificación de las entidades
- Entidad fuerte o regular (strong entity): existe por sí misma y se puede identificar con sus propios atributos. CLIENTE, PRODUCTO, LIBRO. Es la mayoría.
- Entidad débil (weak entity): su existencia depende de otra entidad (la propietaria) y, en el caso más habitual, ni siquiera puede identificarse sin ella. Por ejemplo, la habitación 101 no identifica una habitación concreta si no sabemos de qué hotel es: HABITACION es débil respecto de HOTEL. Se representa con un rectángulo de borde grueso (doble) y se estudia a fondo en el módulo 10.
flowchart LR
classDef debil stroke-width:4px
HOTEL[HOTEL] ---|"(1,1)"| tiene{tiene}:::debil
tiene ---|"(1,n)"| HABITACION[HABITACION]:::debil
HOTEL --- h_cod([<u>codigo</u>])
HOTEL --- h_nom([nombre])
HABITACION --- hab_num(["<u>numero</u> parcial"])
HABITACION --- hab_tipo([tipo])
Algunos autores distinguen también entre entidades concretas (objetos tangibles: VEHICULO, LIBRO) y abstractas o de acontecimiento (cosas que suceden o se acuerdan: PEDIDO, RESERVA, MATRICULA, CONSULTA). Las entidades de acontecimiento casi siempre tienen una fecha entre sus atributos, y son las que más crecen en número de ocurrencias.
2. ¿Entidad o atributo?
2.1 El dilema
Es la decisión más frecuente del diseño conceptual y, a la vez, la que más dudas genera. ¿La ciudad de un cliente es un atributo de CLIENTE o una entidad CIUDAD relacionada con CLIENTE? La respuesta correcta es siempre la misma: depende de los requisitos. No hay una solución universal, pero sí criterios claros.
2.2 Criterios para decidir
Un concepto debería ser una entidad si cumple alguna de estas condiciones:
| Criterio | Explicación | Ejemplo |
|---|---|---|
| Tiene atributos propios que interesan | Si de X queremos guardar varias propiedades, X es entidad | De la editorial queremos nombre, país y web → EDITORIAL es entidad |
| Participa en relaciones con otras entidades | Los atributos no se relacionan con nada | El autor “escribe” libros y “pertenece” a un movimiento literario → AUTOR es entidad |
| Sus valores forman un catálogo cerrado que hay que mantener | Para evitar valores mal escritos y poder gestionar la lista | Las provincias españolas: 50 valores fijos, con su código |
| Tiene existencia independiente | Debe poder registrarse aunque nadie lo use todavía | Una categoría de producto que aún no tiene productos |
| Es multivaluado con estructura | Varios valores, cada uno con propiedades | Varios teléfonos, cada uno con su tipo (fijo, móvil) y horario |
Y debería ser un atributo si:
- Solo describe a una entidad (o a una relación) y no tiene propiedades propias que interesen.
- No se relaciona con ninguna otra entidad.
- Su valor no necesita controlarse contra una lista, o el control se puede hacer con un dominio sencillo.
💡 Consejo: Una prueba rápida: intenta completar la frase “de cada __ se guarda __”. Si para el concepto X puedes completarla con varias cosas (“de cada editorial se guarda su nombre, su país y su web”), X es candidato a entidad. Si X solo aparece en la segunda parte (“de cada libro se guarda su título”), X es un atributo.
2.3 Casos ambiguos resueltos
La dirección
Como atributo (compuesto) cuando cada cliente tiene una única dirección y no interesa nada más de ella:
flowchart LR
CLIENTE[CLIENTE] --- c_dni([<u>dni</u>])
CLIENTE --- c_nom([nombre])
CLIENTE --- c_dir([direccion])
c_dir --- c_calle([calle])
c_dir --- c_num([numero])
c_dir --- c_cp([cp])
c_dir --- c_loc([localidad])
Como entidad cuando un cliente puede tener varias direcciones con propiedades propias (dirección de envío, de facturación, horario de entrega) o cuando varias personas comparten la misma dirección y eso interesa (por ejemplo, el padrón de un ayuntamiento, donde la vivienda es el centro del sistema):
flowchart LR
CLIENTE[CLIENTE] ---|"(1,1)"| tiene{tiene}
tiene ---|"(1,n)"| DIRECCION[DIRECCION]
DIRECCION --- d_id([<u>id_direccion</u>])
DIRECCION --- d_calle([calle])
DIRECCION --- d_cp([cp])
DIRECCION --- d_tipo([tipo])
DIRECCION --- d_hor(["horario_entrega (0,1)"])
(Recuerda la convención: un cliente tiene de 1 a n direcciones → (1,n) junto a DIRECCION; cada dirección es de exactamente un cliente → (1,1) junto a CLIENTE.)
La ciudad
- Atributo ciudad de CLIENTE si solo interesa como texto para el envío postal. Es lo que hace la tabla
clientesdel esquema EMPRESA (columnasciudadyprovincia). - Entidad CIUDAD (o LOCALIDAD) si de cada ciudad interesa algo más (código INE, población, provincia a la que pertenece), si se quiere un catálogo para que nadie escriba “Valencia”, “valencia” y “València” como si fueran tres ciudades distintas, o si la ciudad se relaciona con otras entidades (las oficinas de la empresa, las rutas de reparto).
El color
- Atributo color de PRODUCTO en una tienda de ropa sencilla: “rojo”, “azul”.
- Entidad COLOR en una fábrica de pinturas: cada color tiene un código, un nombre comercial, sus componentes RGB y una fórmula de mezcla, y se relaciona con los pigmentos que lo componen.
El departamento de un empleado
- Atributo si es solo una etiqueta y no interesa nada del departamento.
- Entidad en el esquema EMPRESA, porque de cada departamento se guarda nombre, localidad y presupuesto, y además existen departamentos sin empleados (el departamento 70): si fuera un atributo de EMPLEADO, un departamento sin empleados no podría existir en la base de datos.
⚠️ Importante: Este último argumento es muy potente: si un concepto debe poder existir sin estar asociado a ninguna ocurrencia de otra entidad, tiene que ser una entidad. Un atributo solo existe “dentro” de su entidad: si no hay empleados, no hay valores del atributo departamento.
El autor de un libro
- Atributo autor (texto) en el catálogo de una pequeña librería, si solo se muestra el nombre.
- Entidad AUTOR en una biblioteca: un libro puede tener varios autores, un autor escribe varios libros, y de cada autor interesa nacionalidad, fechas y biografía.
Resumen de casos ambiguos
| Concepto | Es atributo cuando… | Es entidad cuando… |
|---|---|---|
| Dirección | Hay una por cliente y solo se usa para enviar correo | Hay varias por cliente con datos propios, o se comparten |
| Ciudad | Basta con el texto | Tiene datos propios, se necesita catálogo o se relaciona con otras cosas |
| Color | Es solo un nombre | Tiene código, componentes, fórmula… |
| Teléfono | Uno o varios números sin más información | Cada número tiene tipo, extensión, horario, o se asigna a otras entidades |
| Departamento | Es solo una etiqueta | Tiene datos propios o puede existir sin empleados |
| Autor | Solo se muestra el nombre | Hay varios por libro y datos propios del autor |
| Categoría de producto | Etiqueta libre | Hay jerarquía de categorías (EMPRESA: categoria_padre_id) |
3. Atributos
3.1 Definición y representación
📘 Concepto: Un atributo (attribute) es cada una de las propiedades o características que describen a una entidad (o a una relación) y que interesa almacenar. Todas las ocurrencias de un tipo de entidad tienen los mismos atributos, aunque cada una tiene sus propios valores.
En la notación del curso, un atributo se representa con un óvalo (forma de estadio) unido por una línea a su entidad. Los nombres de atributo van en minúsculas, sin espacios ni tildes y, si es posible, sin repetir el nombre de la entidad (nombre mejor que nombre_cliente dentro de CLIENTE).
flowchart LR
LIBRO[LIBRO] --- l_isbn([<u>isbn</u>])
LIBRO --- l_tit([titulo])
LIBRO --- l_anio([anio_edicion])
LIBRO --- l_pag([num_paginas])
3.2 Dominio
📘 Concepto: El dominio de un atributo es el conjunto de valores permitidos para ese atributo. Formalmente, un atributo A de una entidad E es una función que asocia a cada ocurrencia de E un valor (o un conjunto de valores, si es multivaluado) del dominio D(A).
El dominio es más que un tipo de dato. El tipo de dato dice “es un número entero”; el dominio dice “es un número entero entre 0 y 10” o “es una de estas cinco palabras”. Pensar en dominios desde el diseño conceptual evita muchos errores:
| Atributo | Dominio (semántico) | Tipo de dato (decisión física, más adelante) |
|---|---|---|
| dni | 8 dígitos seguidos de una letra de control válida | VARCHAR2(9) + CHECK |
| nota | Números entre 0 y 10 con dos decimales como máximo | NUMBER(4,2) + CHECK (nota BETWEEN 0 AND 10) |
| estado (de un pedido) | {PENDIENTE, ENVIADO, ENTREGADO, CANCELADO} | VARCHAR2(12) + CHECK (estado IN (...)) (como en EMPRESA) |
| fecha_nacimiento | Fechas pasadas, posteriores a 1900 | DATE + CHECK |
| Cadenas con el formato usuario@dominio | VARCHAR2(60) + validación | |
| salario | Importes en euros mayores que 0 | NUMBER(8,2) + CHECK (salario > 0) (como en EMPRESA) |
| sexo, federado… | Conjuntos pequeños de valores ({S, N}) | CHAR(1) + CHECK, o BOOLEAN en Oracle 23ai y posteriores |
Varios atributos pueden compartir el mismo dominio: fecha_alta, fecha_pedido y fecha_envio comparten el dominio “fechas”; telefono del cliente y telefono del empleado comparten el dominio “números de teléfono”. Esto es útil porque permite definir las reglas una sola vez.
💡 Consejo: El diagrama E/R no muestra los dominios: se documentan en el diccionario de datos que acompaña al diagrama. Una entrada típica del diccionario es: “nota — atributo de la relación evalúa — dominio: decimal 0..10 con 2 decimales — obligatorio — nota final del alumno en la asignatura”. Oracle 23ai incorporó los dominios SQL (
CREATE DOMAIN) para llevar esta idea a la implementación; se mencionan en el bloque de DDL.
3.3 Atributos simples y compuestos
📘 Concepto: Un atributo simple o atómico no se puede descomponer en partes con significado propio (precio, edad). Un atributo compuesto está formado por varios atributos más simples (direccion = calle + numero + cp + localidad).
En el diagrama, el atributo compuesto se une a la entidad y sus componentes se unen al atributo compuesto:
flowchart LR
EMPLEADO[EMPLEADO] --- e_cod([<u>codigo</u>])
EMPLEADO --- e_nc([nombre_completo])
e_nc --- e_nom([nombre])
e_nc --- e_ap1([apellido1])
e_nc --- e_ap2(["apellido2 (0,1)"])
EMPLEADO --- e_dir([direccion])
e_dir --- e_via([via])
e_dir --- e_cp([cp])
e_dir --- e_loc([localidad])
¿Cuándo hay que descomponer? Cuando el usuario necesita acceder a las partes por separado: buscar empleados por localidad, ordenar por primer apellido, agrupar por código postal. Si la dirección solo se imprime en una etiqueta, un atributo simple puede bastar. En la duda, descompón: unir partes es trivial, separar un texto libre (“C/ Mayor 12, 3ºB, 46001 Valencia”) es muy difícil.
⚠️ Importante: En el modelo relacional los atributos compuestos desaparecen: solo se guardan sus componentes simples (módulo 17). El atributo compuesto es una ayuda conceptual para agrupar propiedades relacionadas.
3.4 Atributos monovaluados y multivaluados
📘 Concepto: Un atributo monovaluado tiene un único valor para cada ocurrencia (fecha_nacimiento de una persona). Un atributo multivaluado puede tener varios valores para la misma ocurrencia (telefonos de una persona, idiomas que habla un guía turístico).
En la notación del curso se dibuja con un doble círculo. Opcionalmente se puede indicar su cardinalidad (mínimo y máximo de valores) en la etiqueta:
flowchart LR
GUIA[GUIA] --- g_dni([<u>dni</u>])
GUIA --- g_nom([nombre])
GUIA --- g_tel((("telefono (1,3)")))
GUIA --- g_idi((("idioma (1,n)")))
Se lee: “cada guía tiene entre 1 y 3 teléfonos y habla entre 1 y n idiomas”.
Un atributo multivaluado puede ser también compuesto: por ejemplo, las titulaciones de un profesor, cada una con nombre, universidad y año. Cuando un multivaluado tiene estructura, o cuando sus valores tienen que relacionarse con otras entidades, casi siempre es mejor modelarlo como una entidad (débil o fuerte); lo veremos en el módulo 10.
⚠️ Importante: El modelo relacional no admite atributos multivaluados (los valores deben ser atómicos: primera forma normal). Al transformar, cada multivaluado se convierte en una tabla aparte (módulo 17). Por eso nunca debes “esconder” un multivaluado en un texto con comas:
telefonos = '600111222, 963112233'hace imposible buscar por un número concreto o validar cada número.
3.5 Atributos almacenados y derivados
📘 Concepto: Un atributo almacenado (o base) se guarda tal cual. Un atributo derivado (o calculado) se obtiene a partir de otros atributos o de las relaciones, por lo que, en principio, no es necesario guardarlo.
Tipos de derivación:
- De otros atributos de la misma ocurrencia: edad a partir de fecha_nacimiento; importe_linea = cantidad × precio_unitario × (1 − descuento/100).
- De ocurrencias relacionadas: num_empleados de un departamento (contando los empleados que trabajan en él); importe_total de un pedido (sumando sus líneas).
- De valores externos: antiguedad a partir de fecha_alta y la fecha actual.
En la notación del curso se dibujan con borde discontinuo:
flowchart LR
classDef derivado stroke-dasharray: 5 5
SOCIO[SOCIO] --- s_num([<u>num_socio</u>])
SOCIO --- s_fn([fecha_nacimiento])
SOCIO --- s_edad([edad]):::derivado
SOCIO --- s_fa([fecha_alta])
SOCIO --- s_ant([antiguedad]):::derivado
SOCIO --- s_np([num_prestamos_activos]):::derivado
¿Se guardan o no? En el diseño conceptual se dibujan para documentar que el usuario necesita ese dato, pero se marcan como derivados. La decisión de almacenarlos se toma en el diseño físico y depende del coste:
| Guardar el derivado | No guardarlo (calcularlo al consultar) |
|---|---|
| Consultas más rápidas | Ocupa menos espacio |
| Riesgo de inconsistencia si cambian los datos de origen | Siempre es correcto |
| Hay que mantenerlo actualizado (con programación o procesos) | Puede ser lento con muchos datos |
| Justificado si el cálculo es costoso y muy frecuente | La opción por defecto |
⚠️ Importante: Cuidado con los falsos derivados. El precio_unitario de una línea de pedido parece derivado del precio del producto, pero no lo es: es el precio en el momento de la venta. Si mañana sube el precio del producto, las facturas antiguas no deben cambiar. Por eso en EMPRESA
lineas_pedido.precio_unitarioes un atributo almacenado y obligatorio. Del mismo modo, la edad de un paciente en el momento de una operación quirúrgica no es la edad actual.
3.6 Atributos obligatorios y opcionales
📘 Concepto: Un atributo es obligatorio si toda ocurrencia debe tener un valor para él, y opcional si puede haber ocurrencias sin valor (con un valor nulo).
En la notación del curso, un atributo opcional se marca con el sufijo (0,1) en la etiqueta. Si no se indica nada, el atributo es obligatorio y monovaluado, es decir, (1,1).
Esto nos permite ver todos los casos como una cardinalidad de atributo (mínimo y máximo de valores por ocurrencia):
| Cardinalidad | Significado | Ejemplo | Representación |
|---|---|---|---|
| (1,1) | Obligatorio y monovaluado (por defecto) | dni, nombre | ([nombre]) |
| (0,1) | Opcional y monovaluado | email, fecha_baja, comision | (["email (0,1)"]) |
| (1,n) | Obligatorio y multivaluado | idiomas de un guía | ((("idioma (1,n)"))) |
| (0,n) | Opcional y multivaluado | alergias de un paciente | ((("alergia (0,n)"))) |
| (1,3) | Multivaluado con límite | entre 1 y 3 teléfonos | ((("telefono (1,3)"))) |
flowchart LR
PACIENTE[PACIENTE] --- p_nhc([<u>num_historia</u>])
PACIENTE --- p_nom([nombre])
PACIENTE --- p_dni(["dni (0,1)"])
PACIENTE --- p_email(["email (0,1)"])
PACIENTE --- p_ale((("alergia (0,n)")))
El DNI del paciente es opcional porque los menores de 14 años no están obligados a tenerlo. Esta observación, que parece un detalle, tiene una consecuencia de diseño importante: el DNI no puede ser el identificador de PACIENTE (lo veremos en la sección 4).
3.7 Resumen de los tipos de atributos
| Clasificación | Tipos | Pregunta para decidir | Ejemplo |
|---|---|---|---|
| Por su estructura | Simple / compuesto | ¿Necesito acceder a sus partes? | precio / direccion |
| Por el número de valores | Monovaluado / multivaluado | ¿Puede tener varios valores a la vez? | fecha_nacimiento / telefonos |
| Por su origen | Almacenado / derivado | ¿Se puede calcular a partir de otros datos? | fecha_nacimiento / edad |
| Por su obligatoriedad | Obligatorio / opcional | ¿Toda ocurrencia tiene valor? | nombre / email |
| Por su función | Identificador / descriptor | ¿Distingue cada ocurrencia? | dni / nombre |
Las clasificaciones son independientes entre sí: un atributo puede ser a la vez compuesto, multivaluado y opcional (las direcciones_envio de un cliente de una tienda online, cada una con calle, cp y localidad, y que puede no tener ninguna).
3.8 Valores nulos
📘 Concepto: Un valor nulo (null) es una marca que indica la ausencia de valor de un atributo en una ocurrencia. No es un cero, ni una cadena vacía, ni un espacio en blanco: es “aquí no hay valor”.
Un nulo puede significar cosas muy distintas:
| Significado | Ejemplo |
|---|---|
| Desconocido: el valor existe, pero no lo sabemos | La fecha de nacimiento de un cliente que no la quiso dar |
| No aplicable: el atributo no tiene sentido para esa ocurrencia | La comisión de un empleado que no es comercial |
| Inexistente (todavía): no hay valor por ahora | La fecha de envío de un pedido pendiente (pedidos.fecha_envio en EMPRESA) |
El problema es que el SGBD no distingue entre estos significados: todos se guardan como NULL. Por eso los nulos complican las consultas (en SQL, cualquier comparación con NULL da “desconocido”, como verás en el módulo 27) y conviene minimizarlos desde el diseño:
- Los nulos “no aplicables” suelen indicar que hay subtipos escondidos: si muchos atributos solo tienen sentido para algunas ocurrencias (comisión y zona solo para comerciales; titulación y especialidad solo para técnicos), probablemente se necesita una especialización (módulo 11).
- Los atributos opcionales deben marcarse siempre con (0,1), para que la decisión quede documentada.
- Un identificador nunca puede ser nulo.
💡 Consejo: Oracle tiene una peculiaridad que conviene conocer desde ya: trata la cadena vacía
''comoNULL. En otros SGBD (PostgreSQL, SQL Server) son cosas distintas. Lo verás en detalle en el bloque de SQL.
4. Identificadores (claves)
4.1 Por qué hace falta un identificador
Si en la base de datos de una academia hay dos alumnos que se llaman “Juan García López”, ¿cómo sabemos a cuál se refiere una matrícula? Toda entidad necesita algún atributo, o combinación de atributos, cuyos valores no se repitan entre ocurrencias distintas. Ese es el identificador o clave.
Para estudiar los distintos tipos de claves usaremos esta muestra de ocurrencias de ALUMNO:
| nia | dni | nombre | apellidos | fecha_nac | |
|---|---|---|---|---|---|
| 1001 | 11111111H | ana.ruiz@edu.es | Ana | Ruiz Gil | 12/03/2007 |
| 1002 | 22222222J | juan.garcia@edu.es | Juan | García López | 05/11/2006 |
| 1003 | 33333333P | juan.garcia2@edu.es | Juan | García López | 21/07/2007 |
| 1004 | 44444444A | marta.sanz@edu.es | Marta | Sanz Pérez | 12/03/2007 |
| 1005 | 55555555K | luis.ruiz@edu.es | Luis | Ruiz Gil | 30/01/2006 |
Supondremos, como requisitos, que el nia (número de identificación del alumno) lo asigna el centro y no se repite nunca, que todos los alumnos tienen dni y que cada alumno tiene un email institucional único.
4.2 Superclave
📘 Concepto: Una superclave (superkey) de una entidad E es un conjunto de atributos K tal que, en cualquier estado válido de la base de datos, no pueden existir dos ocurrencias distintas de E con los mismos valores en todos los atributos de K.
Ejemplos de superclaves de ALUMNO: {nia}, {dni}, {email}, {nia, nombre}, {dni, email, fecha_nac}, {nia, dni, email, nombre, apellidos, fecha_nac}…
Observa dos cosas:
- Si K es superclave, cualquier conjunto que contenga a K también lo es. El conjunto de todos los atributos siempre es una superclave (en el modelo, dos ocurrencias distintas no pueden ser idénticas en todo).
- La definición dice “en cualquier estado válido”, no “en los datos de hoy”. En la muestra, {nombre, apellidos, fecha_nac} no se repite… pero nada impide que mañana se matricule otra “Ana Ruiz Gil” nacida el mismo día. Por tanto no es superclave. Las claves se deducen de la semántica (de los requisitos), nunca de los datos de una muestra.
✏️ Ejercicio: ¿Cuántas superclaves tiene ALUMNO con los seis atributos de la muestra? Pista: un subconjunto es superclave si y solo si contiene al menos uno de los atributos nia, dni o email. Hay 2⁶ = 64 subconjuntos de atributos, y 2³ = 8 de ellos no contienen ninguno de los tres (los formados solo con nombre, apellidos y fecha_nac). Luego hay 64 − 8 = 56 superclaves. Por eso las superclaves no se enumeran: interesan las mínimas.
4.3 Clave candidata
📘 Concepto: Una clave candidata (candidate key) es una superclave mínima: ninguno de sus subconjuntos propios es superclave. Dicho de otro modo, si le quitas cualquier atributo, deja de identificar.
Las claves candidatas de ALUMNO son {nia}, {dni} y {email}. {nia, nombre} es superclave pero no candidata: le sobra nombre.
Una clave candidata cumple, por tanto, dos propiedades:
- Unicidad: no hay dos ocurrencias con el mismo valor.
- Minimalidad (irreducibilidad): no le sobra ningún atributo.
4.4 Identificador principal y claves alternativas
📘 Concepto: El identificador principal (primary identifier), que en el modelo relacional se llamará clave primaria (primary key), es la clave candidata que el diseñador elige para identificar las ocurrencias de la entidad. Las demás claves candidatas se llaman claves alternativas (alternate keys) o identificadores alternativos.
En ALUMNO podemos elegir nia como identificador principal; dni y email quedan como claves alternativas. En el diagrama:
- El identificador principal se subraya.
- Las claves alternativas no se subrayan; se documentan en el texto o en el diccionario de datos. Si quieres marcarlas en el diagrama, puedes añadir (AK) a la etiqueta.
flowchart LR
ALUMNO[ALUMNO] --- a_nia([<u>nia</u>])
ALUMNO --- a_dni(["dni (AK)"])
ALUMNO --- a_email(["email (AK)"])
ALUMNO --- a_nom([nombre])
ALUMNO --- a_ape([apellidos])
ALUMNO --- a_fn([fecha_nac])
Las claves alternativas no se pierden: en el diseño físico se convertirán en restricciones UNIQUE. Es exactamente lo que hace EMPRESA: en empleados la clave primaria es emp_id y email es una clave alternativa (CONSTRAINT uq_emp_email UNIQUE (email)); en clientes, la primaria es cliente_id y la alternativa nif (uq_cli_nif).
⚠️ Importante: No confundas clave alternativa con clave ajena. Una clave alternativa es otra forma de identificar las ocurrencias de la propia entidad. Una clave ajena (foreign key) es un concepto del modelo relacional que sirve para representar relaciones; en el modelo E/R no existen claves ajenas.
4.5 Identificadores compuestos
📘 Concepto: Un identificador compuesto está formado por varios atributos que, por separado, no identifican, pero juntos sí.
Ejemplo: en un sistema de una aerolínea, un vuelo programado se identifica por el código del vuelo y la fecha. El vuelo IB3456 sale todos los días de Valencia a Madrid; el IB3456 del 12/05/2026 y el del 13/05/2026 son vuelos distintos, con distintos pasajeros, tripulación y avión.
flowchart LR
VUELO[VUELO] --- v_cod([<u>codigo</u>])
VUELO --- v_fec([<u>fecha</u>])
VUELO --- v_hs([hora_salida])
VUELO --- v_pta(["puerta (0,1)"])
VUELO --- v_est([estado])
Ambos atributos se subrayan: el identificador es el conjunto {codigo, fecha}. Ten cuidado de no leerlo como “dos identificadores”: si quisieras decir que codigo y fecha son dos claves candidatas distintas, subrayarías solo una y marcarías la otra como (AK).
💡 Consejo: Cuando un identificador compuesto contiene un atributo que en realidad es el identificador de otra entidad (por ejemplo, {codigo_hotel, numero_habitacion}), probablemente estás ante una entidad débil: la habitación depende del hotel. Si HOTEL es una entidad del sistema, no pongas codigo_hotel como atributo de HABITACION: modela HABITACION como débil (módulo 10).
4.6 Claves naturales y claves artificiales (subrogadas)
📘 Concepto: Una clave natural es un atributo (o combinación) que ya existe en el mundo real y tiene significado para el usuario: DNI, ISBN, matrícula, número de colegiado, código IATA de un aeropuerto. Una clave artificial o subrogada (surrogate key) es un identificador que inventa el sistema y que no tiene significado fuera de él: un número secuencial (
emp_id,cliente_id), un código interno o un UUID.
Las claves naturales parecen ideales (“¿para qué inventar un número si ya tengo el DNI?”), pero en la práctica dan problemas con frecuencia:
| Clave natural | Problema real |
|---|---|
| DNI | Los menores pueden no tenerlo; los extranjeros tienen NIE o pasaporte; una persona con NIE puede obtener después DNI y “cambiar” de identificador |
| ISBN | Los libros antiguos (anteriores a 1970) no lo tienen; hay ISBN-10 e ISBN-13 para el mismo libro; algunas editoriales han reutilizado ISBN por error |
| Matrícula de un vehículo | Puede cambiar (rematriculación, vehículos importados, matrículas históricas) |
| Las personas cambian de email; puede compartirse en una familia | |
| Número de teléfono | Cambia y se reasigna a otras personas |
| Nombre de un departamento | Los departamentos se renombran |
Comparación:
| Aspecto | Clave natural | Clave subrogada |
|---|---|---|
| Significado para el usuario | Sí: se puede buscar y comunicar | No: es un número interno |
| Estabilidad | Puede cambiar (DNI → NIE, email) | No cambia nunca |
| Existencia garantizada | No siempre (menores sin DNI) | Siempre: la genera el sistema |
| Tamaño | Variable, a veces grande (textos) | Pequeña (un número) |
| Evita duplicados reales | Sí: impide dar de alta dos veces a la misma persona | No: hace falta además una restricción UNIQUE sobre la natural |
| Facilidad de uso en relaciones | Las claves compuestas o largas se propagan a muchas tablas | Una sola columna numérica |
💡 Consejo: La práctica profesional más extendida es combinar ambas: una clave subrogada como identificador principal (estable, corta, siempre disponible) y la clave natural como clave alternativa (
UNIQUE) para que el sistema siga impidiendo duplicados reales. Es lo que hace el esquema EMPRESA concliente_id(subrogada, PK) ynif(natural, UK). En Oracle, la clave subrogada se genera con una columna identidad o una secuencia (módulos 23 y 26).
⚠️ Importante: ¿Hay que dibujar claves subrogadas en el diagrama conceptual? Hay dos posturas. Los puristas dicen que no, porque son una decisión de implementación; el diseño conceptual debe usar los identificadores del mundo real. Otros autores las admiten si el propio negocio usa ese código (“número de socio”, “número de pedido”, “número de historia clínica”), porque en ese caso el código sí existe en el mundo real: lo conoce el usuario y aparece en los documentos. En este curso seguiremos ese criterio: usa un código como identificador cuando el negocio lo emplea o cuando no exista ninguna clave natural fiable, y explica tu decisión.
4.7 Criterios para elegir el identificador principal
Cuando una entidad tiene varias claves candidatas, elige la que cumpla mejor estos criterios:
| Criterio | Pregunta | Ejemplo de fallo |
|---|---|---|
| Unicidad garantizada | ¿Es imposible, por las reglas del negocio, que se repita? | El nombre de un alumno |
| Obligatoriedad | ¿Todas las ocurrencias tienen valor desde el primer momento? | El DNI de un paciente menor |
| Estabilidad | ¿Su valor no cambia nunca a lo largo de la vida de la ocurrencia? | El email de un cliente |
| Minimalidad | ¿Tiene el menor número posible de atributos? | {nia, nombre} |
| Simplicidad y tamaño | ¿Es corto y fácil de comparar? | Un título de 200 caracteres |
| Sin significado oculto | ¿Evita codificar información que puede cambiar? | Un código “VAL-2026-ADM-001” que incluye ciudad, año y departamento |
| Familiaridad | ¿Lo conocen y usan los usuarios? | (Ventaja de las claves naturales y de los códigos de negocio) |
💻 Ejemplo: Elección del identificador de PACIENTE en un hospital. Candidatos: dni (los menores pueden no tenerlo: falla la obligatoriedad), num_tarjeta_sanitaria (los pacientes extranjeros o de otras comunidades pueden no tenerla, y cambia si cambian de comunidad: falla la obligatoriedad y la estabilidad), {nombre, apellidos, fecha_nac} (no garantiza unicidad), num_historia_clinica (lo asigna el hospital en la primera visita, todos los pacientes lo tienen, nunca cambia y lo usan médicos y administrativos). Se elige num_historia_clinica como identificador principal; dni y num_tarjeta_sanitaria se documentan como atributos opcionales y únicos cuando tienen valor.
5. Comparación de notaciones
5.1 Una misma idea, muchos dibujos
Desde 1976 han aparecido muchas notaciones gráficas para el modelo E/R. Los conceptos son los mismos, pero el dibujo cambia, y en tu vida profesional encontrarás casi todas: los libros universitarios españoles usan Chen extendida; las herramientas de modelado (Oracle SQL Developer Data Modeler, MySQL Workbench, ERwin, draw.io) usan pata de gallo, Barker o IDEF1X; los equipos de desarrollo orientado a objetos usan UML.
| Notación | Origen | Entidad | Atributos | Identificador | Cardinalidades | Dónde se usa |
|---|---|---|---|---|---|---|
| Chen | Peter Chen, 1976 | Rectángulo | Óvalos unidos a la entidad | Subrayado | 1, N, M en las líneas | Libros de texto, enseñanza |
| Chen extendida (de Miguel/Piattini) | Enseñanza en España, años 90 | Rectángulo | Óvalos (o pequeños círculos con el nombre) | Subrayado (o círculo relleno) | Pareja (mín, máx) en cada línea | Ciclos formativos y universidades en España; este curso |
| Pata de gallo (crow’s foot, Ingeniería de la Información) | Gordon Everest, 1976; popularizada por James Martin y Clive Finkelstein en los 80 | Rectángulo con los atributos dentro | Lista dentro del rectángulo | PK marcada | Símbolos en los extremos (raya, círculo, pata) | Herramientas CASE, MySQL Workbench, draw.io, Mermaid erDiagram |
| Barker | Richard Barker, CASE*Method, Oracle, 1990 | Rectángulo de esquinas redondeadas | Lista dentro: # identificador, * obligatorio, o opcional | # | Línea continua (obligatoria) / discontinua (opcional) y pata de gallo | Oracle Designer, Oracle SQL Developer Data Modeler |
| IDEF1X | Fuerza Aérea de EE. UU.; norma FIPS 184 (1993) | Caja: esquinas rectas (independiente) o redondeadas (dependiente) | Dentro, separados por una línea: claves arriba, resto abajo | Atributos sobre la línea | Punto relleno en el extremo “muchos”; letras P, Z o números | Administración y defensa de EE. UU., ERwin |
| UML (diagrama de clases) | OMG, 1997 | Rectángulo (clase) con compartimentos | Compartimento de atributos | No es nativo: {id}, estereotipo «PK» | Multiplicidades 0..1, 1, 0..*, 1..* | Ingeniería del software, diseño orientado a objetos |
5.2 La misma entidad en varias notaciones
Modelemos una entidad ALUMNO con: identificador nia; clave alternativa dni; nombre y apellidos; email opcional; varios telefonos; fecha_nac y la edad derivada.
Chen extendida (notación del curso):
flowchart LR
classDef derivado stroke-dasharray: 5 5
ALUMNO[ALUMNO] --- a_nia([<u>nia</u>])
ALUMNO --- a_dni(["dni (AK)"])
ALUMNO --- a_nom([nombre])
ALUMNO --- a_ape([apellidos])
ALUMNO --- a_email(["email (0,1)"])
ALUMNO --- a_tel(((telefono)))
ALUMNO --- a_fn([fecha_nac])
ALUMNO --- a_edad([edad]):::derivado
Pata de gallo (con erDiagram de Mermaid). Los atributos van dentro de la caja con un tipo orientativo; las claves se marcan con PK y UK, y los comentarios entre comillas sirven para lo que la notación no expresa:
erDiagram
ALUMNO {
int nia PK
string dni UK
string nombre
string apellidos
string email "opcional"
date fecha_nac
}
TELEFONO_ALUMNO {
int nia PK, FK
string telefono PK
}
ALUMNO ||--o{ TELEFONO_ALUMNO : "tiene"
Fíjate en lo que ha pasado: la pata de gallo no tiene símbolo para atributos multivaluados ni derivados. El multivaluado telefono se ha tenido que representar como otra entidad (que, de hecho, es lo que acabará siendo en el modelo relacional), y la edad derivada simplemente se omite. Por eso esta notación está más cerca del modelo lógico que del conceptual.
UML (diagrama de clases de Mermaid). UML sí admite multiplicidad en los atributos ([0..1], [*]) y marca los derivados con una barra /:
classDiagram
class Alumno {
+nia : Integer
+dni : String
+nombre : String
+apellidos : String
+email : String [0..1]
+telefono : String [*]
+fechaNac : Date
+/edad : Integer
}
En UML los identificadores no forman parte del estándar del diagrama de clases: se suelen indicar con una nota o restricción ({id}) o con un estereotipo («PK»).
Barker (dibujo esquemático):
╭──────────────────────────╮
│ ALUMNO │
│ # nia │ # identificador (UID)
│ * dni │ * obligatorio
│ * nombre │ o opcional
│ * apellidos │
│ o email │
│ * fecha_nac │
╰──────────────────────────╯
IDEF1X (dibujo esquemático):
ALUMNO
┌──────────────────────────┐
│ nia │ ← atributos de la clave primaria
├──────────────────────────┤
│ dni (AK1) │ ← resto de atributos
│ nombre │
│ apellidos │
│ email │
│ fecha_nac │
└──────────────────────────┘
5.3 Cómo representa cada notación los tipos de atributos
| Elemento | Chen extendida (curso) | Pata de gallo | Barker | IDEF1X | UML |
|---|---|---|---|---|---|
| Identificador | Subrayado | PK | # | Encima de la línea | {id} o «PK» |
| Clave alternativa | En texto o (AK) | UK / AK | # en otro UID secundario | (AKn) | {unique} |
| Opcional | (0,1) | Comentario o NULL | o | (O) en algunas herramientas | [0..1] |
| Multivaluado | Doble círculo | No existe: otra entidad | No existe: otra entidad | No existe: otra entidad | [*] |
| Derivado | Borde discontinuo | No existe | No existe (se documenta) | No existe | /nombre |
| Compuesto | Óvalo con subatributos | No existe: se listan los componentes | No existe | No existe | Tipo de dato estructurado |
💡 Consejo: Esta tabla explica por qué en el diseño conceptual se prefiere la notación de Chen extendida: es la única que representa directamente todos los tipos de atributos. Las notaciones de pata de gallo, Barker e IDEF1X son excelentes para el diseño lógico (y por eso las usan las herramientas que generan DDL), y UML es la natural si el sistema se desarrolla con orientación a objetos. El módulo 06 completa la comparación con las cardinalidades, y el módulo 14 trata las herramientas de modelado.
6. Errores frecuentes
| Error | Ejemplo | Por qué está mal | Solución |
|---|---|---|---|
| Entidad en plural | CLIENTES | El rectángulo es un tipo; cada ocurrencia es un cliente | CLIENTE |
| Entidad con una única ocurrencia | EMPRESA en el sistema de una empresa | No hay nada que distinguir ni relacionar | Eliminarla; sus datos van a parámetros de configuración |
| Ocurrencias dibujadas como entidades | VALENCIA, MADRID | Son valores | Atributo ciudad o entidad CIUDAD |
| Clave ajena como atributo | dept_id como atributo de EMPLEADO | En el E/R las asociaciones se representan con relaciones, no con atributos | Relación EMPLEADO–DEPARTAMENTO |
| Identificador que no es único | nombre como identificador de ALUMNO | Puede haber dos alumnos con el mismo nombre | Usar nia, dni… |
| Identificador opcional | dni como identificador de PACIENTE | Los menores pueden no tenerlo | num_historia_clinica |
| Identificador inestable | email como identificador de CLIENTE | Los clientes cambian de email | Código de cliente + email como (AK) |
| Multivaluado escondido | telefonos como texto “600…, 963…” | Imposible buscar o validar cada valor | Atributo multivaluado o entidad |
| Derivado sin marcar | edad como atributo normal | Se queda desactualizado | Guardar fecha_nac; edad como derivado |
| Atributo en la entidad equivocada | nota como atributo de ALUMNO | La nota depende del alumno y de la asignatura | Atributo de la relación (módulo 06) |
| Atributos de varias entidades mezclados | nombre_profesor dentro de ASIGNATURA | Es un dato del profesor | Entidad PROFESOR y relación |
| Nombres ambiguos | fecha, tipo, codigo sin más | ¿Fecha de qué? | fecha_alta, tipo_iva… |
| Confundir dato actual con dato histórico | precio en la línea como derivado del producto | El precio de venta es el de ese momento | Atributo almacenado en la línea |
| Atributo que es una entidad | editorial (texto) cuando interesan país y web de la editorial | Pierde información y genera inconsistencias | Entidad EDITORIAL |
7. Ejercicios
Ejercicio 1: Tipos y ocurrencias
En la siguiente lista hay tipos de entidad, ocurrencias, atributos y valores de atributos de la base de datos de una biblioteca. Clasifica cada elemento.
SOCIO, “El nombre de la rosa”, isbn, LIBRO, 978-84-9759-258-5, Umberto Eco, fecha_prestamo, AUTOR, 12/05/2026, Editorial Lumen, EDITORIAL, nombre, el socio número 342.
Ver solución
| Elemento | Clasificación | Comentario |
|---|---|---|
| SOCIO | Tipo de entidad | |
| “El nombre de la rosa” | Valor del atributo titulo (de una ocurrencia de LIBRO) | Identifica de forma coloquial una ocurrencia, pero es un valor |
| isbn | Atributo (identificador de LIBRO) | |
| LIBRO | Tipo de entidad | |
| 978-84-9759-258-5 | Valor del atributo isbn | |
| Umberto Eco | Ocurrencia de AUTOR (o valor de su atributo nombre) | |
| fecha_prestamo | Atributo (de la relación SOCIO–LIBRO o de una entidad PRESTAMO) | |
| AUTOR | Tipo de entidad | |
| 12/05/2026 | Valor de un atributo de tipo fecha | |
| Editorial Lumen | Ocurrencia de EDITORIAL | |
| EDITORIAL | Tipo de entidad | Si de la editorial solo interesara el nombre, sería un atributo de LIBRO |
| nombre | Atributo | Lo tienen varias entidades (SOCIO, AUTOR, EDITORIAL) |
| el socio número 342 | Ocurrencia de SOCIO |
La regla para no equivocarse: los tipos se nombran en singular genérico (“un socio cualquiera”), las ocurrencias son objetos concretos (“este socio”), y los valores son los datos que describen a una ocurrencia.
Ejercicio 2: Clasificar atributos
Una clínica dental guarda de cada paciente: número de historia, DNI (si lo tiene), nombre, primer apellido, segundo apellido (algunos extranjeros no tienen), fecha de nacimiento, edad, teléfonos de contacto (al menos uno), dirección (calle, número, código postal, localidad), alergias (puede no tener ninguna), fecha de la última visita y número total de visitas.
Clasifica cada atributo según las cuatro clasificaciones de la sección 3.7 y dibuja la entidad.
Ver solución
| Atributo | Estructura | Nº valores | Origen | Obligatoriedad | Comentario |
|---|---|---|---|---|---|
| num_historia | Simple | Mono | Almacenado | Obligatorio | Identificador principal |
| dni | Simple | Mono | Almacenado | Opcional (0,1) | Clave alternativa cuando tiene valor |
| nombre_completo | Compuesto (nombre, apellido1, apellido2) | Mono | Almacenado | Obligatorio | apellido2 es opcional |
| fecha_nacimiento | Simple | Mono | Almacenado | Obligatorio | |
| edad | Simple | Mono | Derivado | — | De fecha_nacimiento |
| telefono | Simple | Multi (1,n) | Almacenado | Obligatorio (al menos uno) | |
| direccion | Compuesto | Mono | Almacenado | Obligatorio | |
| alergia | Simple | Multi (0,n) | Almacenado | Opcional | |
| fecha_ultima_visita | Simple | Mono | Derivado | — | Del histórico de visitas, si se guardan |
| num_visitas | Simple | Mono | Derivado | — | Contando las visitas |
flowchart LR
classDef derivado stroke-dasharray: 5 5
PACIENTE[PACIENTE] --- p_nh([<u>num_historia</u>])
PACIENTE --- p_dni(["dni (0,1)"])
PACIENTE --- p_nc([nombre_completo])
p_nc --- p_nom([nombre])
p_nc --- p_ap1([apellido1])
p_nc --- p_ap2(["apellido2 (0,1)"])
PACIENTE --- p_fn([fecha_nacimiento])
PACIENTE --- p_edad([edad]):::derivado
PACIENTE --- p_tel((("telefono (1,n)")))
PACIENTE --- p_dir([direccion])
p_dir --- p_calle([calle])
p_dir --- p_num([numero])
p_dir --- p_cp([cp])
p_dir --- p_loc([localidad])
PACIENTE --- p_ale((("alergia (0,n)")))
PACIENTE --- p_fuv([fecha_ultima_visita]):::derivado
PACIENTE --- p_nv([num_visitas]):::derivado
Decisiones comentadas:
- fecha_ultima_visita y num_visitas solo son derivados si el sistema guarda cada visita (que es lo razonable en una clínica: una entidad VISITA relacionada con PACIENTE). Si no se guardaran las visitas, serían atributos almacenados.
- Las alergias podrían ser una relación con una entidad MEDICAMENTO o SUSTANCIA si se quiere que el sistema avise al recetar. Como atributo multivaluado, solo son texto.
Ejercicio 3: Superclaves y claves candidatas
Una federación de ajedrez guarda estos datos de sus torneos. Los requisitos dicen que: el código del torneo es único; no puede haber dos torneos con el mismo nombre en la misma edición (año); en una misma ciudad y fecha de inicio solo se celebra un torneo.
| codigo | nombre | edicion | ciudad | fecha_inicio | premio |
|---|---|---|---|---|---|
| T01 | Open Mediterráneo | 2025 | Valencia | 10/07/2025 | 3000 |
| T02 | Open Mediterráneo | 2026 | Valencia | 09/07/2026 | 3500 |
| T03 | Memorial Pomar | 2026 | Palma | 09/07/2026 | 2000 |
| T04 | Abierto de Otoño | 2026 | Valencia | 15/10/2026 | 1500 |
a) ¿Es {nombre} superclave? ¿Y {ciudad, fecha_inicio}? ¿Y {premio}? b) Indica todas las claves candidatas. c) Elige identificador principal y justifícalo.
Ver solución
a)
- {nombre} no es superclave: “Open Mediterráneo” se repite (y los requisitos permiten que se repita en ediciones distintas).
- {ciudad, fecha_inicio} sí es superclave: lo garantizan los requisitos (“en una misma ciudad y fecha de inicio solo se celebra un torneo”). En la muestra, Valencia 09/07/2026 y Palma 09/07/2026 comparten fecha pero no ciudad.
- {premio} no es superclave aunque en la muestra no se repite ningún valor: ningún requisito impide que dos torneos tengan el mismo premio. Las claves se deducen de la semántica, no de los datos.
b) Claves candidatas (superclaves mínimas):
- {codigo}
- {nombre, edicion}: ni nombre ni edicion por separado identifican.
- {ciudad, fecha_inicio}: ni ciudad ni fecha_inicio por separado identifican.
c) Se elige codigo: es simple (un solo atributo), corto, estable (el nombre de un torneo puede cambiar por patrocinio, y la fecha de inicio puede aplazarse) y lo usa la federación. {nombre, edicion} y {ciudad, fecha_inicio} se documentan como claves alternativas (restricciones UNIQUE en el diseño físico).
flowchart LR
TORNEO[TORNEO] --- t_cod([<u>codigo</u>])
TORNEO --- t_nom(["nombre (AK1)"])
TORNEO --- t_ed(["edicion (AK1)"])
TORNEO --- t_ciu(["ciudad (AK2)"])
TORNEO --- t_fi(["fecha_inicio (AK2)"])
TORNEO --- t_pre([premio])
Se ha usado la marca AK1 y AK2 para indicar qué atributos forman juntos cada clave alternativa compuesta (el mismo convenio que usa IDEF1X).
Ejercicio 4: ¿Entidad o atributo? Plataforma de streaming
En una plataforma de vídeo bajo demanda, decide si cada concepto debe ser entidad o atributo de PELICULA, y justifícalo. Requisitos: “De cada película se guarda título, año, duración y clasificación por edades (TP, 7, 12, 16, 18). Una película pertenece a uno o varios géneros; los géneros se muestran en el menú principal y cada uno tiene una imagen de portada. De cada director se guarda nombre, nacionalidad y fecha de nacimiento; una película puede tener varios directores. Cada película se ofrece en uno o varios idiomas de audio, y se quiere poder filtrar por idioma. El país de producción solo se muestra como información.”
Ver solución
| Concepto | Decisión | Justificación |
|---|---|---|
| titulo, anio, duracion | Atributos de PELICULA | Solo describen la película |
| clasificacion | Atributo con dominio {TP, 7, 12, 16, 18} | Catálogo pequeño y fijo, sin propiedades propias: basta con un dominio |
| GENERO | Entidad | Tiene propiedades propias (imagen de portada), se muestra en el menú (existe aunque no tenga películas) y se relaciona N:M con PELICULA |
| DIRECTOR | Entidad | Tiene atributos propios (nacionalidad, fecha de nacimiento) y se relaciona N:M con PELICULA |
| idioma | Atributo multivaluado idioma_audio (1,n), o entidad IDIOMA | Si solo se filtra por el código del idioma, basta un multivaluado. Si se quiere un catálogo controlado (para que no aparezca “español”, “Español” y “castellano”), mejor una entidad IDIOMA. Ambas opciones son defendibles: se elige la entidad para garantizar el catálogo |
| pais_produccion | Atributo | Solo se muestra como información |
flowchart LR
GENERO[GENERO] ---|"(1,n)"| pertenece{pertenece}
pertenece ---|"(0,n)"| PELICULA[PELICULA]
DIRECTOR[DIRECTOR] ---|"(1,n)"| dirige{dirige}
dirige ---|"(1,n)"| PELICULA
PELICULA ---|"(0,n)"| tiene_audio{tiene_audio}
tiene_audio ---|"(1,n)"| IDIOMA[IDIOMA]
PELICULA --- p_cod([<u>codigo</u>])
PELICULA --- p_tit([titulo])
PELICULA --- p_anio([anio])
PELICULA --- p_dur([duracion])
PELICULA --- p_cla([clasificacion])
PELICULA --- p_pais([pais_produccion])
Léelo con la convención del curso: “un género tiene de 0 a n películas” → (0,n) junto a PELICULA; “una película pertenece a 1 a n géneros” → (1,n) junto a GENERO. Para el director: “un director dirige de 1 a n películas” → (1,n) junto a PELICULA (se supone que solo se registran directores con alguna película en la plataforma); “una película tiene de 1 a n directores” → (1,n) junto a DIRECTOR. Las relaciones se estudian en el módulo 06; aquí lo importante es la decisión entidad/atributo.
Se ha añadido un identificador codigo porque el título y el año no garantizan unicidad (hay remakes con el mismo título y años distintos, pero también películas homónimas del mismo año).
Ejercicio 5: Elegir identificadores
Para cada entidad, enumera sus claves candidatas y elige el identificador principal razonando con los criterios de la sección 4.7. Si ninguna clave natural es adecuada, propón un código.
a) AEROPUERTO: nombre, ciudad, código IATA (3 letras, p. ej. VLC), código OACI (4 letras, p. ej. LEVC). b) EMPLEADO de una multinacional: DNI o pasaporte, email corporativo, número de la Seguridad Social, nombre. c) PARTIDO de una liga: jornada, temporada, equipo local, equipo visitante, fecha. d) LIBRO de una biblioteca histórica con fondos del siglo XVIII: ISBN, título, autor, año.
Ver solución
a) AEROPUERTO. Claves candidatas: {codigo_iata}, {codigo_oaci}. El nombre puede cambiar (“Aeropuerto de Madrid-Barajas” pasó a llamarse “Adolfo Suárez Madrid-Barajas”). Ambos códigos son cortos, estables, únicos y conocidos. Se elige codigo_iata (el más usado por viajeros y aerolíneas); codigo_oaci es clave alternativa. Pega: algunos aeródromos pequeños solo tienen código OACI; si el sistema los incluye, sería mejor elegir codigo_oaci.
b) EMPLEADO. Candidatas: {documento_identidad}, {email_corporativo}, {num_seguridad_social}. Ninguna es buena como principal: el documento varía según el país (DNI, NIE, pasaporte) y puede cambiar; el email cambia si cambia el nombre o la empresa se fusiona; el número de la Seguridad Social es español (no sirve para empleados de otros países). Se propone un codigo_empleado generado por la empresa (como emp_id en EMPRESA), con las demás como claves alternativas cuando procedan.
c) PARTIDO. Candidatas: {temporada, jornada, equipo_local} (un equipo juega como local como mucho un partido por jornada), {temporada, jornada, equipo_visitante}, {equipo_local, fecha}… Todas son compuestas y, además, equipo_local es el identificador de otra entidad (EQUIPO). Se propone un num_partido (la propia federación numera los partidos en el calendario). Las combinaciones anteriores quedan como restricciones de unicidad.
d) LIBRO con fondos antiguos. El ISBN no sirve: los libros anteriores a 1970 no lo tienen (falla la obligatoriedad). {titulo, autor, anio} no garantiza unicidad (varias ediciones el mismo año). Se usa la signatura de la biblioteca (el código que la propia biblioteca asigna a cada obra) como identificador; el ISBN queda como atributo opcional y único.
Observa el patrón: cuando las claves naturales fallan en obligatoriedad o estabilidad, la solución profesional es un código del negocio o subrogado, manteniendo las naturales como alternativas.
Ejercicio 6: De Chen a pata de gallo
Traduce esta entidad de la notación del curso a erDiagram (pata de gallo) y explica qué información se pierde.
flowchart LR
classDef derivado stroke-dasharray: 5 5
VEHICULO[VEHICULO] --- v_mat([<u>matricula</u>])
VEHICULO --- v_bas(["num_bastidor (AK)"])
VEHICULO --- v_mod([modelo])
VEHICULO --- v_fm([fecha_matriculacion])
VEHICULO --- v_ant([antiguedad]):::derivado
VEHICULO --- v_col(["color (0,1)"])
VEHICULO --- v_ext(((extra)))
Ver solución
erDiagram
VEHICULO {
string matricula PK
string num_bastidor UK
string modelo
date fecha_matriculacion
string color "opcional"
}
EXTRA_VEHICULO {
string matricula PK, FK
string extra PK
}
VEHICULO ||--o{ EXTRA_VEHICULO : "tiene"
Información que se pierde o cambia de forma:
- antiguedad (derivado): desaparece; habría que documentarla aparte o calcularla en una consulta o una vista.
- extra (multivaluado): no tiene símbolo, así que se convierte en otra entidad con la matrícula y el extra. Esto ya es, en la práctica, una decisión de diseño lógico.
- color (0,1): la opcionalidad solo queda en un comentario; el
erDiagramno tiene marca estándar de nulos. - La clave alternativa se conserva con
UK.
Conclusión: la notación de pata de gallo es más compacta y cercana a las tablas, pero expresa menos semántica conceptual. Por eso en el curso se usa para comparar y para representar el modelo de tablas, no para el diseño conceptual.
Ejercicio 7: Detectar errores
El siguiente diagrama corresponde a “una academia guarda de cada alumno su DNI, nombre, teléfonos y la nota de cada asignatura que cursa; de cada asignatura se guarda código, nombre y el profesor que la imparte”. Encuentra todos los errores.
flowchart LR
ALUMNOS[ALUMNOS] --- a_nom([<u>nombre</u>])
ALUMNOS --- a_dni([dni])
ALUMNOS --- a_tel([telefonos])
ALUMNOS --- a_nota([nota])
ALUMNOS --- a_asig([cod_asignatura])
ASIGNATURA[ASIGNATURA] --- s_cod([<u>codigo</u>])
ASIGNATURA --- s_nom([nombre])
ASIGNATURA --- s_prof([nombre_profesor])
Ver solución
- ALUMNOS en plural: debe ser ALUMNO.
- Identificador incorrecto: nombre no es único; el identificador debe ser dni (u otro código).
- telefonos es multivaluado, pero se ha dibujado como simple: debe ser un doble círculo (telefono).
- cod_asignatura es una “clave ajena” metida como atributo: en el E/R la asociación alumno–asignatura se representa con una relación. Además, como atributo monovaluado, solo permitiría una asignatura por alumno.
- nota no es atributo del alumno: depende del alumno y de la asignatura. Debe ser atributo de la relación entre ambas (módulo 06).
- nombre_profesor dentro de ASIGNATURA: si del profesor interesa algo más que el nombre o un profesor imparte varias asignaturas, debe ser una entidad PROFESOR relacionada con ASIGNATURA. Incluso si solo interesa el nombre, repetirlo en cada asignatura genera redundancia.
- No hay ninguna relación dibujada, así que las dos entidades están aisladas.
Diagrama corregido:
flowchart LR
ALUMNO[ALUMNO] ---|"(0,n)"| cursa{cursa}
cursa ---|"(0,n)"| ASIGNATURA[ASIGNATURA]
cursa --- c_nota(["nota (0,1)"])
PROFESOR[PROFESOR] ---|"(1,1)"| imparte{imparte}
imparte ---|"(0,n)"| ASIGNATURA
ALUMNO --- a_dni([<u>dni</u>])
ALUMNO --- a_nom([nombre])
ALUMNO --- a_tel(((telefono)))
ASIGNATURA --- s_cod([<u>codigo</u>])
ASIGNATURA --- s_nom([nombre])
PROFESOR --- p_cod([<u>codigo</u>])
PROFESOR --- p_nom([nombre])
La nota es opcional porque mientras el alumno cursa la asignatura todavía no tiene nota.
Ejercicios propuestos
✏️ Ejercicio: Propuesto 1 — Agencia de viajes. De cada cliente se guarda DNI o pasaporte, nombre, fecha de nacimiento, teléfonos y nacionalidad. De cada hotel, código, nombre, categoría (de 1 a 5 estrellas), dirección completa y servicios (piscina, gimnasio, wifi…). Dibuja ambas entidades con todos los tipos de atributos y escribe la entrada del diccionario de datos (con su dominio) de cinco atributos.
✏️ Ejercicio: Propuesto 2 — Claves de un hospital. Para las entidades MEDICO (número de colegiado, DNI, nombre, email), CAMA (planta, habitación, letra de la cama) y QUIROFANO (número, planta), indica superclaves, claves candidatas e identificador principal. ¿Alguna de ellas debería ser una entidad débil? Razónalo con lo visto en la sección 4.5.
✏️ Ejercicio: Propuesto 3 — Entidad o atributo en una red social. Decide si son entidades o atributos de USUARIO: foto de perfil, ciudad, intereses (que se usan para recomendar grupos), idioma de la interfaz, centro de estudios (con el que se pueden “conectar” antiguos compañeros) y estado civil. Justifica cada decisión con los criterios de la sección 2.2.
✏️ Ejercicio: Propuesto 4 — Derivados y falsos derivados. En un videoclub en línea se guardan: precio de alquiler de cada película, precio pagado en cada alquiler, número de veces que se ha alquilado cada película, fecha de alquiler, fecha de devolución prevista (siempre 48 horas después) y puntuación media de la película. Indica cuáles son derivados, cuáles son “falsos derivados” y cuáles almacenarías en el diseño físico.
✏️ Ejercicio: Propuesto 5 — Cuatro notaciones. Dibuja la entidad EMPLEADO del esquema EMPRESA (consulta las columnas en empresa_crear.sql) en notación de Chen extendida, en
erDiagram, en UML (classDiagram) y como esquema de Barker en texto. Ten en cuenta qué columnas son obligatorias, cuáles opcionales y cuál es la clave alternativa, y no incluyas las columnas que en el E/R serían relaciones (jefe_id,dept_id).
Resumen
| Concepto | Idea clave |
|---|---|
| Entidad | Objeto distinguible del que interesa guardar información; rectángulo, MAYÚSCULAS, singular |
| Tipo / ocurrencia | El tipo se dibuja (CLIENTE); las ocurrencias son los objetos concretos (el cliente 1001) |
| Fuerte / débil | La fuerte existe e identifica por sí misma; la débil depende de su propietaria (módulo 10) |
| ¿Entidad o atributo? | Entidad si tiene atributos propios, se relaciona, debe existir por sí misma o forma un catálogo |
| Atributo | Propiedad de una entidad o relación; óvalo |
| Dominio | Conjunto de valores permitidos; se documenta en el diccionario de datos |
| Simple / compuesto | Compuesto si interesa acceder a sus partes (direccion → calle, cp…) |
| Mono / multivaluado | Multivaluado: doble círculo; desaparece en el relacional (tabla aparte) |
| Almacenado / derivado | Derivado: borde discontinuo; se decide en el diseño físico si se guarda |
| Obligatorio / opcional | Opcional: (0,1); por defecto (1,1) |
| Valor nulo | Ausencia de valor: desconocido, no aplicable o inexistente |
| Superclave | Conjunto de atributos que identifica (siempre, no solo en los datos de hoy) |
| Clave candidata | Superclave mínima |
| Identificador principal | Clave candidata elegida; subrayada. Las demás: alternativas (AK) |
| Identificador compuesto | Varios atributos que solo juntos identifican; todos subrayados |
| Clave natural / subrogada | Del mundo real / inventada por el sistema; lo habitual es subrogada como PK + natural como UK |
| Notaciones | Chen, Chen extendida (curso), pata de gallo, Barker, IDEF1X, UML |