Módulo 04: El proceso de diseño

Objetivos del módulo

Conocer las fases del ciclo de vida de un sistema de base de datos, desde la planificación hasta la explotación y el mantenimiento
Comprender el proceso de diseño en tres fases: conceptual, lógica y física, y qué se obtiene en cada una
Saber qué es un modelo de datos, cuáles son sus componentes (estructuras, restricciones y operaciones) y cómo se clasifican
Dominar las técnicas de análisis de requisitos: entrevistas, cuestionarios y análisis de documentos
Distinguir entre requisitos de datos, requisitos funcionales y requisitos no funcionales
Redactar un enunciado o supuesto claro, completo y sin ambigüedades
Aplicar la técnica del análisis gramatical para identificar entidades, atributos y relaciones candidatas
Conocer el origen del modelo Entidad/Relación (Peter Chen, 1976), su extensión (EER) y la notación que usaremos en todo el curso

1. ¿Por qué hay que diseñar una base de datos?

Imagina que quieres construir una casa. Nadie sensato empieza poniendo ladrillos: primero hablas con un arquitecto, le cuentas qué necesitas (cuántas personas vivirán, si quieres despacho, si habrá garaje), el arquitecto dibuja unos planos y, solo cuando todos están de acuerdo con los planos, empieza la obra. Cambiar una pared en el plano cuesta una goma de borrar; cambiarla cuando la casa está construida cuesta una fortuna.

Con las bases de datos pasa exactamente lo mismo. Una base de datos mal diseñada funciona “más o menos” al principio, pero con el tiempo aparecen los problemas:

Redundancia: el mismo dato se guarda en muchos sitios (el teléfono del cliente repetido en cada uno de sus pedidos).
Inconsistencias: como el dato está repetido, tarde o temprano se actualiza en un sitio y no en otro, y ya no sabes cuál es el bueno.
Anomalías de inserción y borrado: no puedes dar de alta un producto hasta que alguien lo compre, o al borrar el último pedido de un cliente pierdes sus datos de contacto.
Consultas imposibles o lentísimas: la información que necesitas está “escondida” en campos de texto libre o repartida de forma caótica.
Cambios muy caros: cuando hay cientos de programas que usan la base de datos, modificar su estructura es una operación de alto riesgo.

💻 Ejemplo: Una academia guarda sus matrículas en una hoja de cálculo con estas columnas: alumno, telefono_alumno, curso, profesor, telefono_profesor, aula, precio. Si la profesora Marta cambia de teléfono, hay que corregirlo en las 140 filas de sus alumnos. Si se olvida una, la base de datos ya es inconsistente. Si el único alumno de un curso se da de baja y borramos su fila, perdemos también el precio del curso y el aula asignada. Ninguno de estos problemas es un fallo de la hoja de cálculo: es un fallo de diseño.

📘 Concepto: El diseño de una base de datos es el proceso de decidir qué datos hay que almacenar, cómo se estructuran y qué restricciones deben cumplir, de forma que la base de datos represente fielmente la parte del mundo real que interesa (el universo del discurso o minimundo) y satisfaga las necesidades de información de sus usuarios.

El diseño es la parte de la informática de gestión donde más se nota la diferencia entre un profesional y un aficionado. Escribir un SELECT se aprende en unas semanas; diseñar bien una base de datos requiere método, práctica y mucho sentido crítico. Este bloque del curso (módulos 04 a 15) está dedicado entero a ello.

2. El ciclo de vida de un sistema de base de datos

Una base de datos no aparece de la nada ni dura para siempre igual: nace, se construye, se pone en marcha, se usa durante años, se modifica y, algún día, se sustituye. El conjunto de etapas por las que pasa se llama ciclo de vida del sistema de base de datos (database system development lifecycle).

📘 Concepto: El ciclo de vida de un sistema de base de datos es la secuencia de fases que van desde que se detecta la necesidad de una base de datos hasta que esta se retira, pasando por su análisis, diseño, construcción, puesta en marcha y mantenimiento. No es estrictamente lineal: en cualquier fase se puede detectar un problema que obliga a volver a una fase anterior.

2.1 Visión general

Los autores no coinciden exactamente en el número de fases ni en sus nombres (Connolly y Begg, por ejemplo, distinguen once), pero todos recogen las mismas ideas. En este curso trabajaremos con siete fases:

flowchart TB
    F1["1. Planificación"] --> F2["2. Análisis de requisitos"]
    F2 --> F3["3. Diseño<br/>(conceptual, lógico y físico)"]
    F3 --> F4["4. Implementación"]
    F4 --> F5["5. Carga de datos"]
    F5 --> F6["6. Pruebas"]
    F6 --> F7["7. Explotación y mantenimiento"]
    F6 -.->|"errores detectados"| F3
    F3 -.->|"requisitos incompletos"| F2
    F7 -.->|"nuevas necesidades"| F2

Las flechas discontinuas representan la realimentación: las pruebas pueden revelar un error de diseño, el diseño puede descubrir que faltan requisitos, y durante la explotación surgen necesidades nuevas que reinician el ciclo.

2.2 Fase 1: Planificación

Antes de escribir una sola línea hay que decidir si merece la pena el proyecto y cómo se va a abordar.

Objetivos y alcance: qué parte de la organización cubrirá la base de datos (¿solo ventas?, ¿ventas y almacén?, ¿toda la empresa?) y qué queda fuera.
Estudio de viabilidad: técnica (¿tenemos la tecnología?), económica (¿compensa el coste?) y operativa (¿la usarán los usuarios?).
Recursos: personas, presupuesto, plazos, hardware y licencias.
Plan del proyecto: calendario, hitos, responsables y riesgos.

En esta fase también se suelen identificar los grupos de usuarios y las vistas que cada uno tendrá del sistema (el personal de almacén ve stock y ubicaciones; el de contabilidad, facturas y cobros). Algunos autores lo llaman fase de definición del sistema.

2.3 Fase 2: Análisis de requisitos

Es la fase en la que se averigua qué información necesita la organización y qué quiere hacer con ella. Se estudia con detalle en la sección 5, porque es la base de todo el diseño: un diseño técnicamente perfecto sobre unos requisitos equivocados es un diseño inútil.

El producto de esta fase es la especificación de requisitos, que en el ámbito docente suele resumirse en un enunciado o supuesto en lenguaje natural.

2.4 Fase 3: Diseño

A partir de los requisitos se construyen los “planos” de la base de datos. Es una fase tan importante que se divide en tres subfases (conceptual, lógica y física), que se estudian en la sección 3. En paralelo se diseñan también las aplicaciones que usarán la base de datos (pantallas, informes, procesos), y se selecciona el SGBD concreto si no estaba decidido.

En proyectos grandes es habitual construir un prototipo: una versión reducida que permite a los usuarios ver y tocar algo real y confirmar (o corregir) que el diseño responde a lo que pidieron.

2.5 Fase 4: Implementación

Se crea la base de datos real en el SGBD elegido: se escriben y ejecutan las sentencias DDL (CREATE TABLE, CREATE INDEX, CREATE VIEW…), se configuran el almacenamiento y la seguridad (usuarios, privilegios y roles con DCL) y se desarrollan las aplicaciones. El bloque 4 del curso (módulos 22 a 26) trata la implementación con DDL en Oracle.

2.6 Fase 5: Carga (conversión) de datos

Una base de datos vacía no sirve de nada. Casi siempre existen datos previos (en otra base de datos, en hojas de cálculo, en ficheros o incluso en papel) que hay que migrar:

Extracción de los datos del sistema antiguo.
Transformación: limpiar duplicados, unificar formatos (fechas, mayúsculas, códigos), completar datos que faltan y adaptar la estructura antigua a la nueva.
Carga en las tablas nuevas, respetando las restricciones de integridad (por ejemplo, cargando antes los departamentos que los empleados que trabajan en ellos).

Este proceso se conoce como ETL (Extract, Transform, Load) y en proyectos reales puede llevar más tiempo que el propio diseño.

2.7 Fase 6: Pruebas

Se comprueba que la base de datos y las aplicaciones funcionan como se esperaba:

Que las restricciones rechazan los datos incorrectos (un salario negativo, un pedido de un cliente inexistente).
Que las consultas devuelven los resultados correctos.
Que el rendimiento es aceptable con volúmenes de datos reales.
Que la seguridad funciona: cada usuario ve y modifica solo lo que debe.
Que las copias de seguridad se pueden restaurar (una copia que nunca se ha probado a restaurar no es una copia fiable).

2.8 Fase 7: Explotación y mantenimiento

La base de datos entra en producción y se usa a diario. Es, con diferencia, la fase más larga: puede durar décadas. Durante ella:

Se supervisa el rendimiento y se afina (tuning): nuevos índices, estadísticas, reorganización del almacenamiento.
Se realizan copias de seguridad y se planifica la recuperación ante desastres.
Se gestionan usuarios y permisos.
Se aplican parches y actualizaciones del SGBD.
Se modifica el esquema cuando cambian las necesidades (una columna nueva, una tabla nueva, una restricción distinta). Cada cambio relevante debería volver a pasar por análisis y diseño.

2.9 Resumen de las fases

Fase	Pregunta que responde	Producto principal	Quién participa
Planificación	¿Merece la pena? ¿Con qué recursos?	Plan del proyecto, estudio de viabilidad	Dirección, jefe de proyecto
Análisis de requisitos	¿Qué información se necesita y para qué?	Especificación de requisitos (enunciado)	Analista y usuarios
Diseño	¿Cómo se estructuran los datos?	Esquemas conceptual, lógico y físico	Diseñador de BD, analista
Implementación	¿Cómo se construye en el SGBD?	Scripts DDL/DCL, base de datos vacía, aplicaciones	Administrador (DBA), programadores
Carga de datos	¿Cómo se pasan los datos existentes?	Base de datos con datos reales	DBA, programadores, usuarios
Pruebas	¿Funciona como se esperaba?	Informe de pruebas, correcciones	Equipo de pruebas, usuarios
Explotación y mantenimiento	¿Sigue funcionando bien? ¿Qué hay que cambiar?	Sistema en producción, versiones nuevas del esquema	DBA, usuarios, desarrolladores

⚠️ Importante: El ciclo de vida de la base de datos va de la mano del ciclo de vida del software que la usa. En metodologías clásicas (en cascada) cada fase se termina antes de empezar la siguiente; en metodologías iterativas y ágiles el ciclo se recorre muchas veces en pequeñas iteraciones, y los cambios de esquema se gestionan con scripts de migración versionados. Pero incluso en un proyecto ágil, el modelo conceptual de las entidades centrales debe pensarse bien desde el principio: es lo más caro de cambiar después.

3. El proceso de diseño en tres fases

3.1 La idea: separar el “qué” del “cómo”

Diseñar una base de datos de golpe, pensando a la vez en lo que significan los datos, en las tablas y en los índices de Oracle, es demasiado complicado. Por eso el diseño se divide en tres fases, cada una con un nivel de abstracción distinto:

flowchart TB
    REQ[/"Requisitos de datos<br/>(enunciado o supuesto)"/] --> DC["DISEÑO CONCEPTUAL"]
    DC --> EC[/"Esquema conceptual<br/>(diagrama E/R)"/]
    EC --> DL["DISEÑO LÓGICO"]
    ML[/"Modelo lógico elegido<br/>(modelo relacional)"/] --> DL
    DL --> ESL[/"Esquema lógico<br/>(tablas normalizadas)"/]
    ESL --> DF["DISEÑO FÍSICO"]
    SGBD[/"SGBD concreto<br/>(Oracle 26ai)"/] --> DF
    DF --> EF[/"Esquema físico<br/>(scripts DDL, índices, almacenamiento)"/]

Fíjate en las entradas laterales: el diseño conceptual no depende de nada técnico; el diseño lógico depende del tipo de SGBD (relacional, documental…), y el diseño físico depende del SGBD concreto (Oracle, PostgreSQL, SQL Server…) e incluso de la versión.

3.2 Diseño conceptual

📘 Concepto: El diseño conceptual obtiene una representación de la realidad (el esquema conceptual) a partir de los requisitos, usando un modelo de alto nivel, comprensible por los usuarios y completamente independiente del SGBD y de cualquier consideración de implementación.

Entrada: la especificación de requisitos.
Herramienta: un modelo conceptual, normalmente el modelo Entidad/Relación extendido (también se usan los diagramas de clases de UML).
Salida: el diagrama E/R acompañado de un diccionario de datos (descripción de cada entidad, atributo y dominio) y de las restricciones que el diagrama no puede expresar.
Pregunta clave: ¿qué datos hay y cómo se relacionan?

En esta fase no se habla de tablas, ni de tipos VARCHAR2, ni de claves ajenas. Se habla de clientes, pedidos y productos. El esquema conceptual debe poder enseñarse a un usuario sin conocimientos informáticos para que confirme que refleja su negocio.

3.3 Diseño lógico

📘 Concepto: El diseño lógico transforma el esquema conceptual en un esquema lógico expresado en el modelo de datos del tipo de SGBD que se va a usar (en nuestro caso, el modelo relacional), y lo refina para eliminar redundancias mediante la normalización.

Entrada: el esquema conceptual y el modelo lógico elegido.
Herramientas: las reglas de transformación E/R → relacional (módulo 17) y la normalización (módulos 19 y 20).
Salida: el conjunto de relaciones (tablas) con sus atributos, claves primarias, claves ajenas y restricciones.
Pregunta clave: ¿cómo se organizan los datos en el modelo relacional?

El esquema lógico ya depende del modelo (relacional), pero todavía no de un producto concreto: el mismo esquema sirve para Oracle, PostgreSQL o MySQL.

3.4 Diseño físico

📘 Concepto: El diseño físico decide cómo se implementa el esquema lógico en un SGBD concreto para que la base de datos sea eficiente, segura y fácil de administrar: tipos de datos exactos, índices, particiones, organización del almacenamiento, vistas, usuarios y privilegios.

Entrada: el esquema lógico, las características del SGBD y la información sobre la carga de trabajo (qué consultas son frecuentes, cuántas filas habrá, qué tablas crecen más).
Salida: los scripts DDL y la configuración de almacenamiento.
Pregunta clave: ¿cómo se almacenan los datos para que el acceso sea rápido y seguro?

Algunas decisiones típicas del diseño físico: elegir NUMBER(8,2) o VARCHAR2(60), crear un índice sobre la columna por la que más se busca, particionar una tabla de ventas por año, o almacenar un dato derivado (el importe total de un pedido) para no calcularlo en cada consulta.

3.5 Las tres fases sobre un mismo ejemplo

Veamos cómo evoluciona un fragmento del esquema EMPRESA del curso: “cada empleado trabaja, como mucho, en un departamento, y en un departamento pueden trabajar muchos empleados”.

Fase conceptual (diagrama E/R; no te preocupes todavía por los detalles de la notación, los estudiarás en los módulos 05 y 06):

flowchart LR
    DEPARTAMENTO[DEPARTAMENTO] ---|"(0,1)"| trabaja{trabaja}
    trabaja ---|"(0,n)"| EMPLEADO[EMPLEADO]
    DEPARTAMENTO --- d_id([<u>codigo</u>])
    DEPARTAMENTO --- d_nom([nombre])
    DEPARTAMENTO --- d_loc([localidad])
    EMPLEADO --- e_id([<u>codigo</u>])
    EMPLEADO --- e_nom([nombre])
    EMPLEADO --- e_sal([salario])

Solo hay “cosas” (entidades), sus propiedades (atributos) y cómo se asocian (relaciones). Nada de tablas.

Fase lógica (esquema relacional; módulos 16 y 17):

DEPARTAMENTOS (dept_id, nombre, localidad, presupuesto)

EMPLEADOS (emp_id, nombre, apellidos, email, salario, comision, jefe_id, dept_id)

dept_id → DEPARTAMENTOS(dept_id), admite nulos (un empleado puede no tener departamento).

Aquí aparece por primera vez la clave ajena dept_id: es la forma que tiene el modelo relacional de representar la relación “trabaja”.

Fase física (DDL de Oracle; es un extracto real del script empresa_crear.sql más un índice):

CREATE TABLE departamentos (
    dept_id      NUMBER(4)     CONSTRAINT pk_departamentos PRIMARY KEY,
    nombre       VARCHAR2(40)  CONSTRAINT nn_dep_nombre NOT NULL,
    localidad    VARCHAR2(40),
    presupuesto  NUMBER(12,2),
    CONSTRAINT uq_dep_nombre      UNIQUE (nombre),
    CONSTRAINT ck_dep_presupuesto CHECK (presupuesto >= 0)
);

-- Decisión de diseño físico: las consultas "empleados de un departamento"
-- son muy frecuentes, así que se indexa la clave ajena
CREATE INDEX ix_emp_dept ON empleados (dept_id);

Ahora sí hay tipos de datos concretos de Oracle (NUMBER, VARCHAR2), nombres de restricciones y un índice: decisiones que solo tienen sentido para un SGBD determinado.

3.6 Comparación de las tres fases

Aspecto	Diseño conceptual	Diseño lógico	Diseño físico
Nivel de abstracción	Alto (realidad)	Medio (modelo de datos)	Bajo (almacenamiento)
Depende de…	Nada técnico	El tipo de SGBD (relacional)	El SGBD concreto y su versión
Modelo / herramienta	E/R extendido, UML	Modelo relacional, normalización	DDL de Oracle, parámetros, índices
Elementos	Entidades, atributos, relaciones	Tablas, columnas, PK, FK	Tipos de datos, índices, particiones, tablespaces
Producto	Diagrama E/R + diccionario	Esquema relacional	Scripts DDL
Lo entiende el usuario	Sí	Parcialmente	No
Objetivo principal	Fidelidad a la realidad	Ausencia de redundancia, integridad	Rendimiento, seguridad
Módulos del curso	04 a 11	12 a 17	17 a 22

💡 Consejo: Respeta el orden de las fases aunque te parezca más rápido saltártelo. Cuando un alumno empieza a diseñar “directamente en tablas”, suele mezclar decisiones de fases distintas: elige claves artificiales antes de entender qué identifica a cada cosa, mete claves ajenas como si fueran atributos y olvida las restricciones que no caben en una tabla. El diagrama E/R te obliga a pensar primero en el significado.

3.7 Estrategias de diseño conceptual

Cuando el sistema es grande, construir el esquema conceptual de una sola vez es inabordable. Existen varias estrategias:

Estrategia	Idea	Cuándo usarla
Descendente (top-down)	Se parte de un esquema muy general (pocas entidades muy amplias) y se refina descomponiendo	Cuando se conoce bien el dominio a grandes rasgos
Ascendente (bottom-up)	Se parte de los atributos elementales y se agrupan en entidades y relaciones	Cuando se dispone de muchos documentos y formularios concretos
Dentro-fuera (inside-out)	Se parte de los conceptos centrales y se va añadiendo lo que está a su alrededor	Muy natural en la práctica: se empieza por CLIENTE, PEDIDO, PRODUCTO…
Mixta	Combina las anteriores	La más habitual en proyectos reales

Otra decisión es si se diseña de forma centralizada (se juntan todos los requisitos y se hace un único esquema) o mediante integración de vistas: se diseña un esquema conceptual por cada grupo de usuarios (la vista de ventas, la de almacén, la de contabilidad) y después se integran, resolviendo los conflictos entre ellas: sinónimos (CLIENTE en ventas y DEUDOR en contabilidad son lo mismo), homónimos (PEDIDO en ventas es lo que pide un cliente; en almacén, lo que se pide a un proveedor) y diferencias de estructura (en una vista dirección es un atributo y en otra una entidad).

4. Modelos de datos

4.1 Modelo, esquema y ejemplar

Hasta ahora hemos usado varias veces la palabra modelo. Conviene precisarla, porque en bases de datos se confunden con frecuencia tres conceptos distintos:

📘 Concepto: Un modelo de datos es un conjunto de conceptos, reglas y convenciones que permite describir la estructura de una base de datos, las restricciones que deben cumplir sus datos y las operaciones para manipularlos. Es la “herramienta” o el “lenguaje” con el que se diseña.

📘 Concepto: Un esquema es la descripción de una base de datos concreta hecha con un modelo de datos (el diagrama E/R de una biblioteca, el conjunto de tablas de EMPRESA). Cambia poco a lo largo del tiempo. También se le llama intensión de la base de datos.

📘 Concepto: Un ejemplar (instancia, ocurrencia o estado) de la base de datos es el conjunto de datos almacenados en un momento determinado. Cambia constantemente con cada inserción, modificación o borrado. También se le llama extensión.

Una analogía: el modelo es el idioma (el castellano, con su gramática); el esquema es un formulario concreto escrito en ese idioma (el impreso de matrícula de tu instituto, con sus casillas); y el ejemplar es el conjunto de impresos ya rellenados que hay en secretaría hoy.

Concepto	Ejemplo con E/R	Ejemplo con el modelo relacional
Modelo de datos	El modelo Entidad/Relación extendido	El modelo relacional de Codd
Esquema (intensión)	El diagrama con CLIENTE, PEDIDO y PRODUCTO	Las tablas `clientes`, `pedidos`, `productos` y sus restricciones
Ejemplar (extensión)	El cliente “Informática Levante SL” con sus 3 pedidos	Las 51 filas que hay hoy en `lineas_pedido`

4.2 Componentes de un modelo de datos

Todo modelo de datos tiene tres componentes:

Estructuras (parte estática): los elementos con los que se describen los datos. En el modelo E/R, las entidades, atributos y relaciones; en el relacional, las relaciones (tablas), atributos (columnas) y dominios.
Restricciones (parte estática): reglas que limitan los datos válidos.
- Inherentes: las impone el propio modelo y no hace falta declararlas. Por ejemplo, en el modelo relacional no puede haber dos filas idénticas en una tabla, y en el modelo E/R una relación solo puede asociar entidades (no atributos).
- Semánticas o de usuario: las define el diseñador para reflejar reglas del negocio. Por ejemplo, “el salario debe ser positivo” o “un pedido siempre pertenece a un cliente”.
Operaciones (parte dinámica): permiten consultar y modificar los datos (recuperar, insertar, modificar, borrar). En el modelo relacional, las operaciones se definen con el álgebra relacional (módulo 18) y en la práctica con SQL.

Componente	Modelo E/R	Modelo relacional
Estructuras	Entidades, atributos, relaciones, jerarquías	Relaciones (tablas), atributos, dominios, tuplas
Restricciones inherentes	Las relaciones asocian entidades; cada atributo pertenece a una entidad o relación	No hay tuplas repetidas; los valores son atómicos; el orden de filas y columnas no importa
Restricciones semánticas	Cardinalidades, identificadores, cobertura de jerarquías	PRIMARY KEY, FOREIGN KEY, UNIQUE, NOT NULL, CHECK
Operaciones	No tiene (es un modelo de diseño)	Álgebra relacional, SQL (SELECT, INSERT, UPDATE, DELETE)

⚠️ Importante: El modelo E/R es un modelo conceptual de diseño: describe estructuras y restricciones, pero no tiene operaciones propias (no se “consulta” un diagrama E/R). Por eso ningún SGBD trabaja directamente con él: siempre hay que transformarlo en un modelo lógico.

4.3 Clasificación de los modelos de datos

Los modelos de datos se clasifican según su nivel de abstracción, es decir, según lo cerca que estén de la forma de pensar de las personas o de la forma de almacenar del ordenador.

flowchart TB
    subgraph CONC["Modelos conceptuales (alto nivel)"]
        c1["Entidad/Relación (E/R)"]
        c2["E/R extendido (EER)"]
        c3["Diagramas de clases UML"]
    end
    subgraph LOG["Modelos lógicos (de implementación)"]
        l1["Relacional"]
        l2["Jerárquico y en red"]
        l3["Orientado a objetos y objeto-relacional"]
        l4["Documental, clave-valor, grafos (NoSQL)"]
    end
    subgraph FIS["Modelos físicos (bajo nivel)"]
        f1["Ficheros, bloques, páginas"]
        f2["Índices B-tree, hash, bitmap"]
        f3["Particiones, tablespaces"]
    end
    CONC -->|"diseño lógico"| LOG
    LOG -->|"diseño físico"| FIS

Tipo	Describe	Usuarios	Ejemplos
Conceptual	La realidad, con conceptos cercanos al usuario	Analistas, diseñadores, usuarios finales	E/R (Chen, 1976), EER, UML
Lógico (de implementación o representacional)	La organización de los datos tal como la ve un tipo de SGBD	Diseñadores, programadores	Relacional (Codd, 1970), jerárquico (IMS), en red (CODASYL), documental (MongoDB)
Físico	Cómo se guardan los datos en los dispositivos	Administradores, el propio SGBD	Estructuras de ficheros, índices, bloques de datos de Oracle

Esta clasificación encaja con la arquitectura ANSI/SPARC que viste en el módulo 03: el esquema conceptual de ANSI/SPARC se describe con un modelo lógico (en nuestro caso, el relacional), el esquema interno con un modelo físico, y los esquemas externos (vistas) con el mismo modelo lógico.

💡 Consejo: No confundas “esquema conceptual” de ANSI/SPARC con “esquema conceptual” del proceso de diseño. El primero es la descripción lógica global de la base de datos dentro del SGBD (las tablas de EMPRESA); el segundo es el diagrama E/R que dibujamos antes de pensar en tablas. Comparten nombre por razones históricas, pero están en niveles distintos.

5. Análisis de requisitos

5.1 Objetivo de la fase

El análisis de requisitos busca responder a dos preguntas: ¿qué datos necesita guardar la organización? y ¿qué va a hacer con ellos? Para ello, el analista se reúne con los usuarios, estudia cómo trabajan, recoge sus documentos y, a partir de todo ello, redacta una especificación.

Es una fase difícil por motivos que no son técnicos:

Los usuarios conocen su trabajo, pero no saben expresarlo en términos útiles para el diseño (“pues lo normal, apuntar los pedidos”).
Dan por supuestas muchas cosas que para ellos son obvias (“claro que un pedido puede tener varios productos”).
Usan vocabulario propio (siglas, jerga del sector) y a veces palabras distintas para lo mismo.
Cada departamento tiene una visión parcial y, a veces, contradictoria.
Los requisitos cambian durante el propio proyecto.

📘 Concepto: Un requisito es una condición o capacidad que debe tener el sistema para satisfacer una necesidad de sus usuarios. El conjunto de requisitos documentados forma la especificación de requisitos, que sirve de “contrato” entre usuarios y desarrolladores.

5.2 Técnicas de obtención de requisitos

Entrevistas

Es la técnica más usada. El analista conversa con los usuarios clave para entender su trabajo y sus necesidades.

Estructuradas (cerradas): con un guion fijo de preguntas. Fáciles de comparar entre entrevistados, pero poco flexibles.
No estructuradas (abiertas): conversación libre sobre el trabajo del usuario. Descubren cosas inesperadas, pero cuesta más sacar conclusiones.
Semiestructuradas: un guion básico con libertad para profundizar. Es la opción más habitual.

Consejos prácticos:

Prepárala: estudia antes la organización y lleva preguntas escritas.
Entrevista a usuarios de distintos niveles: quien usa el sistema a diario, quien supervisa y quien decide.
Pregunta por casos concretos y excepciones: “¿y si un cliente devuelve parte de un pedido?”, “¿puede haber un pedido sin comercial asignado?”.
Pide ejemplos reales de documentos y de datos.
Resume y valida al final: “entonces, si lo he entendido bien, cada pedido es de un solo cliente, ¿correcto?”.

💻 Ejemplo: Fragmento de guion para la entrevista con la responsable de una biblioteca municipal:

¿Qué datos piden ustedes a una persona cuando se hace socia?

¿Un socio puede tener varios libros prestados a la vez? ¿Hay un máximo?

¿Cuánto dura un préstamo? ¿Se puede renovar? ¿Cuántas veces?

Si tienen varios ejemplares del mismo libro, ¿cómo los distinguen?

¿Qué pasa si un socio devuelve tarde un libro? ¿Hay sanciones? ¿Hay que guardar un historial de ellas?

¿Qué listados o informes necesitan sacar habitualmente?

¿Necesitan saber qué libros ha leído un socio en el pasado, o solo los que tiene ahora?

La última pregunta es muy importante en diseño: la diferencia entre guardar solo la situación actual o guardar el histórico cambia por completo el esquema (lo estudiarás en el módulo 13).

Cuestionarios

Formularios con preguntas (abiertas o cerradas) que se reparten a muchos usuarios a la vez. Son útiles cuando hay muchos usuarios dispersos o se quiere cuantificar algo (“¿con qué frecuencia necesita usted el informe de ventas por provincia?”). Su inconveniente es que no permiten repreguntar: si la pregunta está mal planteada, la respuesta no sirve.

Análisis de documentos y formularios

Es una de las técnicas más productivas para el diseño de bases de datos. Las facturas, albaranes, fichas, impresos y listados que la organización ya usa contienen, casi literalmente, los datos que hay que guardar.

💻 Ejemplo: Analicemos una factura del taller mecánico “Motor Rápido”:
FACTURA Nº: 2026/0457                    Fecha: 14/03/2026
Cliente: Laura Gómez Ruiz        DNI: 12345678Z
Dirección: C/ Mayor 12, 46001 Valencia     Tel.: 600111222
Vehículo: 1234-KLM   Seat León (2019)      Km: 85.300
-----------------------------------------------------------
Concepto                         Cant.   Precio    Importe
Filtro de aceite (REF F-221)       1      12,50      12,50
Aceite 5W30 (REF A-530)            5       9,80      49,00
Mano de obra (mecánico: J. Pérez)  2,5    40,00     100,00
-----------------------------------------------------------
                                    Base imponible: 161,50
                                    IVA 21 %:        33,92
                                    TOTAL:          195,42
De este documento se deducen muchos requisitos de datos: hay facturas (número, fecha), clientes (nombre, DNI, dirección, teléfono), vehículos (matrícula, marca, modelo, año, kilómetros en el momento de la reparación), recambios (referencia, descripción, precio) y mecánicos. Las líneas de la factura muestran que una factura tiene varias líneas y cada línea tiene cantidad y precio. Y hay datos derivados (importe de la línea, base imponible, IVA, total) que se calculan a partir de otros.

Al analizar documentos, hazte siempre estas preguntas:

¿Qué dato es calculado a partir de otros? (importe = cantidad × precio)
¿Qué dato se repite varias veces en el documento? (las líneas)
¿Qué dato pertenece a otra cosa distinta del documento? (la dirección es del cliente, no de la factura)
¿El valor que aparece es el actual o el de ese momento? (el precio de la línea es el precio en el día de la factura, aunque luego cambie el precio del recambio)

Otras técnicas

Técnica	En qué consiste	Ventajas	Inconvenientes
Entrevistas	Conversación con usuarios clave	Información rica, se puede repreguntar	Lentas, dependen de la habilidad del analista
Cuestionarios	Formularios a muchos usuarios	Llegan a mucha gente, baratos	No se puede repreguntar; baja tasa de respuesta
Análisis de documentos	Estudio de impresos, facturas, listados	Datos reales y precisos	No muestran los procesos ni las excepciones
Observación	El analista ve trabajar a los usuarios	Descubre lo que el usuario no cuenta	Lenta; el usuario puede actuar distinto al ser observado
Estudio del sistema actual	Análisis de la aplicación o los ficheros existentes	Muestra los datos que ya se manejan	Reproduce también los errores del sistema antiguo
Reuniones de grupo (JAD, tormenta de ideas)	Sesiones con usuarios y técnicos juntos	Resuelven conflictos entre departamentos rápidamente	Difíciles de organizar; pueden dominar unos pocos
Prototipos	Se construye una maqueta para que el usuario opine	El usuario ve algo tangible y descubre lo que falta	Riesgo de que el usuario crea que el sistema ya está terminado

💡 Consejo: Ninguna técnica es suficiente por sí sola. Lo habitual es combinar: entrevistas para entender el negocio, análisis de documentos para obtener los datos concretos y un prototipo o una revisión del diagrama con el usuario para validar.

5.3 Tipos de requisitos

📘 Concepto: Los requisitos de datos describen qué información debe almacenar el sistema: los objetos de interés, sus propiedades y las asociaciones entre ellos (“de cada socio se guarda DNI, nombre y teléfono”; “cada préstamo es de un único ejemplar”).

📘 Concepto: Los requisitos funcionales describen qué debe hacer el sistema con esa información: las operaciones, consultas, informes y procesos (“el sistema debe listar los préstamos vencidos cada mañana”; “al devolver un libro con retraso, se genera una sanción”).

📘 Concepto: Los requisitos no funcionales describen cómo de bien debe hacerlo: rendimiento, seguridad, disponibilidad, volumen, legislación (“la consulta de disponibilidad debe responder en menos de un segundo”; “los datos personales deben cumplir el RGPD”).

El diseño conceptual se apoya sobre todo en los requisitos de datos, pero los funcionales son imprescindibles para comprobar que el esquema permite responder a todo lo que se pide: si hay que listar “los libros que ha leído cada socio en el último año”, el esquema debe guardar el histórico de préstamos, no solo los préstamos activos. Los no funcionales influyen sobre todo en el diseño físico.

Requisito (biblioteca)	Tipo	Influye en
De cada libro se guarda ISBN, título, año de edición y editorial	Datos	Diseño conceptual: entidad LIBRO y sus atributos
Un libro puede tener varios autores	Datos	Diseño conceptual: relación LIBRO–AUTOR
Un socio no puede tener más de 5 préstamos activos	Datos (restricción)	Restricción que el diagrama no siempre expresa: se documenta
Listar los socios con préstamos vencidos	Funcional	Comprobar que se guardan fechas de préstamo y devolución
Calcular cuántas veces se ha prestado cada libro en el año	Funcional	Exige guardar el histórico de préstamos
La aplicación debe estar disponible 24 h	No funcional	Diseño físico, infraestructura
Solo el personal de la biblioteca puede ver el DNI de los socios	No funcional (seguridad)	Vistas y privilegios (DCL)

⚠️ Importante: Las reglas de negocio (“un socio sancionado no puede pedir libros”, “el descuento máximo es del 30 %”) son requisitos de datos aunque se expresen como restricciones. Algunas se recogen en el diagrama E/R (las cardinalidades), otras se convierten en restricciones CHECK y otras solo pueden implementarse con programación en la base de datos (triggers, que se estudian en el Curso de Oracle PL/SQL). Todas deben quedar documentadas junto al diagrama.

5.4 El enunciado o supuesto

En la vida profesional, la especificación de requisitos es un documento extenso con apartados, glosario, casos de uso y anexos. En el ámbito docente (y en los exámenes) se resume en un enunciado o supuesto: uno o varios párrafos en lenguaje natural que describen el sistema. Aprender a leer enunciados es una habilidad clave del curso; aprender a escribirlos te hará mejor analista.

Un buen enunciado:

Describe una sola cosa por frase: “de cada cliente se guarda…”, “cada pedido lo realiza un único cliente”.
Usa siempre el mismo término para el mismo concepto (no “cliente” en un párrafo y “comprador” en otro).
Indica las cantidades en ambos sentidos de cada asociación: cuántos B tiene un A y cuántos A tiene un B.
Distingue entre lo obligatorio (“debe”, “siempre”, “al menos uno”) y lo opcional (“puede”, “algunos”).
Indica qué identifica a cada cosa (“cada vehículo se identifica por su matrícula”).
Aclara si se guarda la situación actual o el histórico.
Indica qué datos son calculables y si hay que guardarlos o no.
No incluye decisiones técnicas (“crear una tabla”, “un campo de tipo texto”).

💻 Ejemplo: Enunciado mal redactado y su corrección.

Versión ambigua: “La clínica tiene médicos y pacientes. Los médicos atienden a los pacientes en consultas. Se guarda el historial de los enfermos y la especialidad del doctor.”

Problemas: “pacientes” y “enfermos” son sinónimos; “médicos” y “doctor” también. No se dice qué datos se guardan de cada uno, ni cómo se identifican, ni cuántos médicos puede tener un paciente, ni si un médico tiene una o varias especialidades, ni qué es exactamente el “historial”.

Versión corregida: “De cada médico se guarda su número de colegiado, que lo identifica, su nombre y su especialidad; cada médico tiene una única especialidad. De cada paciente se guarda su número de historia clínica, que lo identifica, su DNI (que algunos pacientes, como los menores, no tienen), su nombre, su fecha de nacimiento y uno o varios teléfonos. Cada vez que un paciente es atendido se registra una consulta, con la fecha y hora, el diagnóstico y el tratamiento. Cada consulta la realiza un único médico a un único paciente. Un paciente puede tener muchas consultas a lo largo del tiempo, con el mismo o con distintos médicos, y un médico atiende muchas consultas; puede haber médicos recién incorporados que aún no han atendido ninguna.”

5.5 Ambigüedades típicas que hay que aclarar

Ambigüedad	Ejemplo	Pregunta para el usuario
Cardinalidad mínima no indicada	“Los clientes hacen pedidos”	¿Puede existir un cliente que aún no haya hecho ningún pedido?
Cardinalidad en un solo sentido	“Un pedido es de un cliente”	¿Cuántos pedidos puede tener un cliente?
Sinónimos	Cliente / comprador / usuario	¿Son la misma cosa?
Homónimos	“Pedido” en ventas y en compras	¿Hablamos del mismo concepto?
Situación actual o histórico	“El empleado trabaja en un departamento”	¿Hay que saber en qué departamentos trabajó antes?
Dato derivado	“La edad del socio”	¿Se guarda la edad o la fecha de nacimiento?
Identificación	“Los libros se guardan con su título”	¿Puede haber dos libros con el mismo título? ¿Qué los distingue?
Nivel de detalle	“La dirección del cliente”	¿Se necesita buscar por código postal o localidad?

💡 Consejo: Cuando en un examen o en un ejercicio el enunciado no aclara algo, no te bloquees ni inventes en silencio: adopta el supuesto más razonable y escríbelo junto a la solución (“supongo que un cliente puede darse de alta sin haber hecho pedidos”). En la vida real, apúntalo como pregunta para el usuario.

6. Identificación de candidatos: el análisis gramatical

6.1 La técnica

Una vez que tenemos el enunciado, hay que pasar del texto al diagrama. La técnica más sencilla, y sorprendentemente eficaz, es el análisis gramatical (propuesta, entre otros, por Peter Chen en 1983 al estudiar la correspondencia entre la gramática inglesa y los diagramas E/R): se recorre el texto identificando categorías gramaticales y se traduce cada una en un elemento candidato del modelo.

En el enunciado…	…suele corresponder a…	Ejemplo
Sustantivo común relevante	Entidad o atributo	“cliente”, “vehículo”, “matrícula”
Sustantivo que tiene a su vez propiedades	Entidad	“de cada cliente se guarda nombre y DNI”
Sustantivo que describe a otro (“de cada X se guarda Y”)	Atributo	“la matrícula del vehículo”
Sustantivo propio o valor concreto	Ocurrencia o valor (no es entidad)	“Seat”, “Valencia”, “rojo”
Verbo transitivo que une dos sustantivos-entidad	Relación	“el cliente realiza pedidos”
Verbo “tener”, “pertenecer”, “constar de”	Relación (a menudo 1:N) o atributo	“cada pedido consta de varias líneas”
Complemento de un verbo-relación	Atributo de la relación	“se anotan las horas que trabaja cada mecánico en cada reparación”
“identifica”, “único”, “código”	Identificador	“cada vehículo se identifica por su matrícula”
“cada”, “siempre”, “debe”, “al menos uno”	Cardinalidad mínima 1	“cada reparación la hace al menos un mecánico”
“puede”, “algunos”, “opcionalmente”	Cardinalidad mínima 0	“un cliente puede no tener vehículos”
“uno”, “un único”, “solo uno”	Cardinalidad máxima 1	“pertenece a un único cliente”
“varios”, “muchos”, plural	Cardinalidad máxima n	“puede tener varios vehículos”
“calculado”, “total”, “número de”	Atributo derivado	“el importe total de la factura”
“es un”, “puede ser de tipo”	Generalización/especialización	“un empleado puede ser mecánico o administrativo”

⚠️ Importante: El análisis gramatical es una ayuda, no un algoritmo infalible. El lenguaje natural es ambiguo: un mismo sustantivo puede ser entidad en un sistema y atributo en otro, y los verbos a veces esconden atributos (“el cliente vive en Valencia” puede ser simplemente el atributo ciudad). La técnica produce candidatos, que después hay que filtrar con criterio.

6.2 El método paso a paso

Leer el enunciado completo al menos dos veces, sin dibujar nada.
Subrayar sustantivos y anotar todos en una lista.
Filtrar la lista: eliminar el propio sistema (“el taller”, “la base de datos”), los sinónimos (quedarse con un único término), los valores concretos (“Seat”) y lo que no interesa guardar.
Clasificar cada sustantivo superviviente en entidad o atributo (y asignar cada atributo a su entidad). Marcar identificadores.
Subrayar verbos que asocian entidades: serán las relaciones candidatas.
Buscar cuantificadores para deducir las cardinalidades de cada relación en ambos sentidos.
Dibujar un diagrama E/R preliminar.
Revisar: comprobar que todo el enunciado está representado, que los requisitos funcionales se pueden satisfacer y anotar las dudas para el usuario.

6.3 Ejemplo completo guiado: el taller mecánico

Partimos de este enunciado (lo hemos numerado por frases para poder referirnos a ellas):

💻 Ejemplo: Supuesto: taller mecánico. (1) Un taller mecánico quiere una base de datos para gestionar su actividad. (2) De cada cliente se guarda su DNI, que lo identifica, su nombre, su teléfono y su dirección. (3) Cada cliente puede tener uno o varios vehículos, de los que se conoce la matrícula, que los identifica, la marca, el modelo y el año de fabricación; cada vehículo pertenece a un único cliente. (4) Cuando un vehículo entra en el taller se abre una reparación, identificada por un número, en la que se anotan la fecha de entrada, la fecha de salida, los kilómetros del vehículo y una descripción de la avería. (5) En cada reparación trabajan uno o varios mecánicos, y se registran las horas que dedica cada uno a cada reparación. (6) De los mecánicos se guarda el código de empleado, que los identifica, el nombre, la especialidad y la fecha de contratación. (7) En una reparación se pueden utilizar recambios; de cada recambio se conoce su referencia, que lo identifica, la descripción y el precio, y en cada reparación se anota la cantidad utilizada de cada recambio. (8) El taller emite una factura por cada reparación terminada, con un número, que la identifica, la fecha y el importe total.

Paso 2. Lista de sustantivos. Subrayamos todos los sustantivos del texto:

taller mecánico, base de datos, actividad, cliente, DNI, nombre, teléfono, dirección, vehículo, matrícula, marca, modelo, año de fabricación, taller, reparación, número, fecha de entrada, fecha de salida, kilómetros, descripción de la avería, mecánico, horas, código de empleado, nombre, especialidad, fecha de contratación, recambio, referencia, descripción, precio, cantidad, factura, número, fecha, importe total.

Paso 3. Filtrado.

Sustantivo	Decisión	Motivo
taller mecánico, taller	Se descarta	Es el propio sistema: solo hay un taller, no tiene sentido una entidad con una única ocurrencia
base de datos, actividad	Se descarta	Palabras del propio enunciado, no datos del negocio
El resto	Se mantiene	Son datos que hay que guardar

Paso 4. Clasificación en entidades y atributos. Aplicamos el criterio principal: si un sustantivo tiene propiedades propias que interesan (“de cada X se guarda…”), es una entidad; si describe a otro, es un atributo.

Candidato	Clasificación	Atributos / comentario
CLIENTE	Entidad	dni, nombre, telefono, direccion
VEHICULO	Entidad	matricula, marca, modelo, anio_fabricacion
REPARACION	Entidad	numero, fecha_entrada, fecha_salida, kilometros, descripcion_averia
MECANICO	Entidad	codigo, nombre, especialidad, fecha_contratacion
RECAMBIO	Entidad	referencia, descripcion, precio
FACTURA	Entidad	numero, fecha, importe_total
horas	Atributo… ¿de quién?	No es del mecánico (depende de la reparación) ni de la reparación (depende del mecánico): es de la relación entre ambos
cantidad	Atributo… ¿de quién?	Igual: depende del par reparación–recambio, es atributo de la relación
importe total	Atributo derivado	Se puede calcular con las horas y los recambios, pero el precio de los recambios puede cambiar después: conviene guardarlo (o guardar el precio aplicado)

💡 Consejo: Hemos usado nombres de atributos sin espacios ni tildes (anio_fabricacion, descripcion_averia). No es obligatorio en el diagrama conceptual, pero facilita el paso posterior a tablas y evita problemas con algunas herramientas.

Paso 5. Verbos que asocian entidades.

Frase	Verbo	Entidades	Relación candidata
(3)	“tener” / “pertenecer”	CLIENTE, VEHICULO	posee
(4)	“entrar en el taller”, “abrir”	VEHICULO, REPARACION	se_repara
(5)	“trabajar en”	MECANICO, REPARACION	trabaja (con el atributo horas)
(7)	“utilizar”	REPARACION, RECAMBIO	utiliza (con el atributo cantidad)
(8)	“emitir”	REPARACION, FACTURA	genera

Paso 6. Cuantificadores y cardinalidades. Para cada relación nos hacemos las preguntas “¿cuántos B tiene un A, como mínimo y como máximo?” y “¿cuántos A tiene un B?” (el módulo 06 explica este razonamiento con todo detalle).

Relación	Un A…	Un B…	Tipo
CLIENTE posee VEHICULO	Un cliente tiene “uno o varios” vehículos → (1,n)	Un vehículo es de “un único” cliente → (1,1)	1:N
VEHICULO se_repara REPARACION	Un vehículo puede tener 0 o muchas reparaciones (el enunciado no lo dice: supuesto) → (0,n)	Una reparación es de un único vehículo → (1,1)	1:N
MECANICO trabaja REPARACION	Un mecánico trabaja en 0 o muchas reparaciones (puede ser nuevo) → (0,n)	En una reparación trabajan “uno o varios” mecánicos → (1,n)	N:M
REPARACION utiliza RECAMBIO	En una reparación “se pueden” utilizar varios recambios → (0,n)	Un recambio se usa en 0 o muchas reparaciones → (0,n)	N:M
REPARACION genera FACTURA	Una reparación tiene una factura solo si está terminada → (0,1)	Una factura es de una única reparación → (1,1)	1:1

Paso 7. Diagrama E/R preliminar. Por legibilidad, separamos las relaciones y los atributos en dos diagramas. Recuerda la convención del curso: la pareja escrita junto a una entidad indica con cuántas ocurrencias de esa entidad se relaciona una ocurrencia de la entidad del otro lado.

flowchart LR
    CLIENTE[CLIENTE] ---|"(1,1)"| posee{posee}
    posee ---|"(1,n)"| VEHICULO[VEHICULO]
    VEHICULO ---|"(1,1)"| se_repara{se_repara}
    se_repara ---|"(0,n)"| REPARACION[REPARACION]
    MECANICO[MECANICO] ---|"(1,n)"| trabaja{trabaja}
    trabaja ---|"(0,n)"| REPARACION
    trabaja --- t_horas([horas])
    REPARACION ---|"(0,n)"| utiliza{utiliza}
    utiliza ---|"(0,n)"| RECAMBIO[RECAMBIO]
    utiliza --- u_cant([cantidad])
    REPARACION ---|"(1,1)"| genera{genera}
    genera ---|"(0,1)"| FACTURA[FACTURA]

Léelo así: “un cliente posee de 1 a n vehículos” (la pareja (1,n) está junto a VEHICULO); “un vehículo pertenece a exactamente 1 cliente” (la pareja (1,1) está junto a CLIENTE); “en una reparación trabajan de 1 a n mecánicos” ((1,n) junto a MECANICO); “una reparación genera 0 o 1 facturas” ((0,1) junto a FACTURA).

Los atributos de las entidades:

flowchart TB
    CLIENTE[CLIENTE] --- c_dni([<u>dni</u>])
    CLIENTE --- c_nom([nombre])
    CLIENTE --- c_tel([telefono])
    CLIENTE --- c_dir([direccion])
    VEHICULO[VEHICULO] --- v_mat([<u>matricula</u>])
    VEHICULO --- v_mar([marca])
    VEHICULO --- v_mod([modelo])
    VEHICULO --- v_anio([anio_fabricacion])
    REPARACION[REPARACION] --- r_num([<u>numero</u>])
    REPARACION --- r_fe([fecha_entrada])
    REPARACION --- r_fs(["fecha_salida (0,1)"])
    REPARACION --- r_km([kilometros])
    REPARACION --- r_desc([descripcion_averia])

flowchart TB
    MECANICO[MECANICO] --- m_cod([<u>codigo</u>])
    MECANICO --- m_nom([nombre])
    MECANICO --- m_esp([especialidad])
    MECANICO --- m_fc([fecha_contratacion])
    RECAMBIO[RECAMBIO] --- re_ref([<u>referencia</u>])
    RECAMBIO --- re_desc([descripcion])
    RECAMBIO --- re_pre([precio])
    FACTURA[FACTURA] --- f_num([<u>numero</u>])
    FACTURA --- f_fecha([fecha])
    FACTURA --- f_imp([importe_total])

Fíjate en fecha_salida (0,1): es un atributo opcional, porque mientras el vehículo está en el taller todavía no tiene fecha de salida.

Paso 8. Revisión y preguntas para el usuario. Al revisar el diagrama surgen dudas que el enunciado no resuelve:

¿Puede un vehículo cambiar de propietario? Si se vende a otro cliente, ¿hay que guardar quién era el dueño cuando se hizo cada reparación? (Con el diseño actual, solo se sabe el propietario actual.)
¿Una reparación puede facturarse en varias facturas (por ejemplo, una parte al seguro y otra al cliente)? Hemos supuesto que no.
El precio del recambio puede cambiar. Si queremos reproducir una factura antigua, ¿no habría que guardar el precio aplicado en cada uso (como atributo de utiliza)? Muy probablemente sí: es el mismo razonamiento que verás en el caso LINEAS_PEDIDO del esquema EMPRESA en el módulo 10.
¿El precio de la mano de obra es igual para todos los mecánicos? Si depende de la especialidad, habría que guardarlo.
¿Un mecánico tiene una sola especialidad?
¿Interesa la dirección completa del cliente desglosada (calle, código postal, localidad) para poder buscar por localidad? Se discute en el módulo 05 (atributos compuestos).

💡 Consejo: Un diagrama preliminar siempre genera preguntas. Eso no es un fracaso, sino el objetivo: el diagrama es una herramienta de comunicación con el usuario para descubrir lo que el enunciado no dice.

6.4 Limitaciones del análisis gramatical

Sinónimos y paráfrasis: “el cliente es dueño de…” y “el vehículo pertenece a…” describen la misma relación.
Sustantivos que esconden relaciones: “la asignación de un empleado a un proyecto” suena a entidad, pero puede ser una relación con atributos.
Verbos que esconden atributos: “el paciente nació en 1990” no es una relación, es el atributo fecha_nacimiento.
Información implícita: los usuarios omiten lo obvio; el analista debe preguntarlo.
Nominalizaciones: “se registra el préstamo de un ejemplar a un socio”. Préstamo es un sustantivo, pero puede modelarse como relación (SOCIO–EJEMPLAR) o como entidad, según si tiene identidad propia y relaciones con otras cosas.

7. Introducción al modelo Entidad/Relación

7.1 Un poco de historia

📘 Concepto: El modelo Entidad/Relación (E/R o ER, Entity-Relationship model) es un modelo de datos conceptual que representa la realidad mediante entidades (cosas u objetos de interés), atributos (sus propiedades) y relaciones (asociaciones entre entidades), utilizando una notación gráfica: el diagrama E/R.

1976: Peter Pin-Shan Chen, entonces en el MIT, publica “The Entity-Relationship Model — Toward a Unified View of Data” en el primer número de la revista ACM Transactions on Database Systems. Su propuesta pretendía unificar las visiones de los modelos de la época (relacional, en red y de conjuntos de entidades) con un modelo de alto nivel, independiente de la implementación. Es uno de los artículos más citados de la historia de la informática.
Finales de los 70 y años 80: varios autores proponen extensiones para representar abstracciones que el modelo original no recogía: la generalización/especialización y la agregación (Smith y Smith, 1977), las jerarquías de subclases y categorías (trabajos de Elmasri, Navathe y otros) y una metodología completa de diseño lógico con el modelo E/R extendido (Teorey, Yang y Fry, 1986).
El resultado es el modelo E/R extendido (EER, Enhanced o Extended Entity-Relationship), que es el que se enseña y se usa hoy.
En España, la notación más extendida en la enseñanza es la de Adoración de Miguel, Mario Piattini y colaboradores, que combina la notación de Chen con la representación de cardinalidades mínimas y máximas mediante parejas (mín, máx). Es la que usaremos en este curso.

⚠️ Importante: Existen muchas notaciones gráficas para el mismo modelo (Chen, pata de gallo, Barker, IDEF1X, UML…). Los conceptos son los mismos; lo que cambia es el dibujo. En el módulo 05 se comparan las notaciones para las entidades y atributos, y en el módulo 06 para las cardinalidades.

7.2 Los elementos del modelo E/R extendido

Elemento	Qué representa	Ejemplo	Símbolo en el curso	Se estudia en
Entidad (fuerte)	Objeto del mundo real con existencia propia	CLIENTE, LIBRO	Rectángulo	Módulo 05
Atributo	Propiedad de una entidad o relación	nombre, precio	Óvalo (estadio) unido a su entidad	Módulo 05
Identificador	Atributo(s) que distinguen cada ocurrencia	dni, isbn	Óvalo con el nombre subrayado	Módulo 05
Atributo multivaluado	Puede tener varios valores	telefonos	Doble círculo	Módulo 05
Atributo derivado	Se calcula a partir de otros	edad	Óvalo con borde discontinuo	Módulo 05
Atributo compuesto	Formado por otros atributos	direccion (calle, cp, localidad)	Óvalo unido a sus subatributos	Módulo 05
Relación	Asociación entre entidades	realiza, imparte	Rombo	Módulo 06
Cardinalidad	Nº mínimo y máximo de ocurrencias asociadas	(0,n), (1,1)	Pareja (mín, máx) en la línea	Módulo 06
Entidad débil	Depende de otra para existir o identificarse	LINEA_PEDIDO	Rectángulo de borde grueso (doble)	Módulo 10
Relación de identificación	Une la entidad débil con su propietaria	contiene	Rombo de borde grueso	Módulo 10
Generalización/especialización	Jerarquía “es un” entre supertipo y subtipos	EMPLEADO → COMERCIAL, TECNICO	Hexágono “es un” con la cobertura	Módulo 11
Agregación	Una relación tratada como entidad	(EMPLEADO trabaja PROYECTO) usa MAQUINA	Recuadro que encierra la relación	Módulo 11

7.3 La notación del curso de un vistazo

Este diagrama reúne casi todos los símbolos que usaremos. No intentes entenderlo todo ahora: vuelve a él como leyenda cada vez que lo necesites.

flowchart LR
    classDef debil stroke-width:4px
    classDef derivado stroke-dasharray: 5 5
    PROFESOR[PROFESOR] ---|"(1,1)"| imparte{imparte}
    imparte ---|"(0,n)"| ASIGNATURA[ASIGNATURA]
    PROFESOR --- p_dni([<u>dni</u>])
    PROFESOR --- p_nombre([nombre])
    PROFESOR --- p_tel(((telefono)))
    PROFESOR --- p_edad([edad]):::derivado
    PROFESOR --- p_email(["email (0,1)"])
    PROFESOR --- p_dir([direccion])
    p_dir --- p_calle([calle])
    p_dir --- p_cp([cp])
    p_dir --- p_loc([localidad])
    ASIGNATURA --- a_cod([<u>codigo</u>])
    ASIGNATURA --- a_nom([nombre])
    ASIGNATURA ---|"(1,1)"| tiene{tiene}:::debil
    tiene ---|"(1,n)"| TEMA[TEMA]:::debil
    TEMA --- t_num(["<u>numero</u> parcial"])
    TEMA --- t_tit([titulo])

Lo que dice el diagrama:

PROFESOR y ASIGNATURA son entidades; imparte es una relación entre ellas.
Un profesor imparte de 0 a n asignaturas → (0,n) junto a ASIGNATURA. Cada asignatura la imparte exactamente un profesor → (1,1) junto a PROFESOR. Es una relación 1:N.
El dni subrayado es el identificador de PROFESOR; telefono (doble círculo) es multivaluado; edad (borde discontinuo) es derivada; email (0,1) es opcional; direccion es compuesta (calle, cp, localidad).
TEMA es una entidad débil (borde grueso) que depende de ASIGNATURA a través de la relación de identificación tiene (rombo de borde grueso). Su numero es un identificador parcial: el tema 3 de Bases de Datos y el tema 3 de Programación son temas distintos, y solo se distinguen si se añade el código de la asignatura.

Y estos son los dos símbolos del modelo extendido que veremos en el módulo 11:

La generalización: un empleado “es un” comercial o “es un” técnico; todo empleado es de uno de los dos tipos (total) y no puede ser de los dos a la vez (exclusiva).

flowchart TB
    EMPLEADO[EMPLEADO] --- j{{"es un<br/>(total, exclusiva)"}}
    j --- COMERCIAL[COMERCIAL]
    j --- TECNICO[TECNICO]

La agregación: la relación “un empleado trabaja en un proyecto” se trata como un todo, y ese todo se relaciona con las máquinas que se usan en ese trabajo.

flowchart LR
    subgraph AGR["trabajo (agregación)"]
        EMPLEADO[EMPLEADO] ---|"(1,n)"| trabaja{trabaja}
        trabaja ---|"(0,n)"| PROYECTO[PROYECTO]
    end
    AGR ---|"(0,n)"| usa{usa}
    usa ---|"(0,n)"| MAQUINA[MAQUINA]

💡 Consejo: Guarda esta sección en favoritos. En los exámenes de diseño, la mitad de los fallos no son de razonamiento, sino de notación: cardinalidades escritas en el lado contrario, identificadores sin subrayar o entidades débiles sin marcar.

8. Ejercicios

Ejercicio 1: Las fases del ciclo de vida

Indica en qué fase del ciclo de vida de un sistema de base de datos se realiza cada una de estas tareas:

a) Se entrevista a la jefa de almacén para saber qué datos registra cuando llega un envío. b) Se crea un índice sobre la columna fecha_pedido porque los informes mensuales tardan demasiado. c) Se estima que el proyecto costará 40 000 € y durará seis meses. d) Se ejecuta el script CREATE TABLE de todas las tablas. e) Se convierten 12 000 fichas de clientes de una hoja de cálculo eliminando duplicados. f) Se dibuja el diagrama E/R. g) Se comprueba que no se puede insertar un pedido con fecha de envío anterior a la fecha de pedido. h) Se transforma el diagrama E/R en tablas y se normalizan. i) Un año después de la puesta en marcha, se añade una columna para el número de móvil de los clientes.

Ver solución

Tarea	Fase	Comentario
a) Entrevista a la jefa de almacén	Análisis de requisitos	Técnica de obtención de requisitos
b) Índice por `fecha_pedido` por lentitud	Explotación y mantenimiento	Es afinamiento (tuning) del sistema en producción; si se decidiera antes de implantar sería diseño físico
c) Estimación de coste y plazo	Planificación	Estudio de viabilidad y plan del proyecto
d) Ejecutar `CREATE TABLE`	Implementación	Construcción de la base de datos en el SGBD
e) Convertir fichas de una hoja de cálculo	Carga de datos	Proceso ETL: extracción, limpieza y carga
f) Dibujar el diagrama E/R	Diseño (conceptual)	Producto: esquema conceptual
g) Comprobar la restricción de fechas	Pruebas	Se verifica que las restricciones funcionan
h) Transformar a tablas y normalizar	Diseño (lógico)	Producto: esquema lógico
i) Añadir una columna un año después	Explotación y mantenimiento	Cambio de esquema; idealmente debería repasar análisis y diseño

Fíjate en la tarea b): la misma acción (crear un índice) pertenece a fases distintas según cuándo y por qué se hace. El ciclo de vida no clasifica acciones técnicas, sino momentos del proyecto.

Ejercicio 2: Conceptual, lógico o físico

Clasifica cada decisión según la fase de diseño a la que pertenece (conceptual, lógica o física):

a) “Un alumno puede matricularse en varias asignaturas y una asignatura tiene muchos alumnos.” b) “La columna nota será de tipo NUMBER(4,2).” c) “La tabla matriculas tendrá una clave primaria compuesta por nia y cod_asignatura.” d) “El teléfono del alumno puede tener varios valores.” e) “La tabla de calificaciones se particionará por curso académico.” f) “La tabla alumnos está en tercera forma normal.” g) “Cada asignatura se identifica por un código.” h) “Se creará una vista para que los profesores solo vean a sus alumnos.”

Ver solución

Decisión	Fase	Por qué
a) Alumno–asignatura, muchos a muchos	Conceptual	Describe la realidad (relación N:M) sin hablar de tablas
b) `NUMBER(4,2)`	Física	Tipo de dato concreto de Oracle
c) PK compuesta en `matriculas`	Lógica	Resultado de transformar la relación N:M en una tabla del modelo relacional
d) Teléfono multivaluado	Conceptual	Propiedad de un atributo del modelo E/R
e) Particionar por curso	Física	Organización del almacenamiento para mejorar el rendimiento
f) Tercera forma normal	Lógica	La normalización es parte del diseño lógico
g) Identificador de la asignatura	Conceptual	Identificador de la entidad (se convertirá en clave primaria en el diseño lógico)
h) Vista para profesores	Física	Las vistas y la seguridad se deciden en el diseño físico (aunque las vistas de usuario se identifiquen en el análisis)

La pregunta que te ayuda a decidir: ¿esta decisión seguiría siendo válida si cambiáramos Oracle por PostgreSQL? Si sí, no es física. ¿Y si en lugar de tablas usáramos otro modelo lógico? Si sí, es conceptual.

Ejercicio 3: Requisitos de datos, funcionales y no funcionales

Una clínica veterinaria ha enviado esta lista de necesidades. Clasifica cada requisito y explica, para los de datos, qué elemento del modelo E/R sugieren.

De cada mascota se quiere saber su nombre, especie, raza, fecha de nacimiento y chip (si lo tiene).
Cada mascota tiene un único dueño, pero un dueño puede tener varias mascotas.
Al final de cada día, el sistema debe imprimir la lista de citas del día siguiente.
Se debe guardar cada vacuna que se pone a una mascota, con la fecha y el lote.
El programa debe poder usarse desde la tableta de la consulta.
Hay que poder consultar qué mascotas no han recibido la vacuna de la rabia en el último año.
Los datos de los dueños solo deben verlos los veterinarios y la recepcionista.
Una mascota puede tener alergias a varios medicamentos.

Ver solución

Nº	Tipo	Elemento E/R sugerido / comentario
1	Datos	Entidad MASCOTA con atributos nombre, especie, raza, fecha_nacimiento y chip opcional (0,1). Ojo: el chip podría ser identificador, pero no sirve porque no todas las mascotas lo tienen
2	Datos	Relación DUEÑO–MASCOTA 1:N: (1,1) junto a DUEÑO y (1,n) o (0,n) junto a MASCOTA (hay que preguntar si se registra un dueño sin mascotas)
3	Funcional	Exige que existan citas con fecha y hora: confirma la entidad CITA
4	Datos	Relación MASCOTA–VACUNA N:M con atributos fecha y lote (o una entidad VACUNACION). Como una mascota puede recibir la misma vacuna varias veces, el diseño necesita cuidado (se verá en los módulos 06 y 10)
5	No funcional	Afecta a la tecnología y a la interfaz, no al esquema conceptual
6	Funcional	Exige guardar el histórico de vacunaciones con su fecha (no solo “vacunado sí/no”)
7	No funcional (seguridad)	Diseño físico: vistas, usuarios y privilegios
8	Datos	Relación MASCOTA–MEDICAMENTO N:M (“es alérgica a”), o atributo multivaluado alergias si de los medicamentos no interesa nada más

Observa cómo los requisitos funcionales 3 y 6 validan el diseño de datos: si el esquema no guardase la fecha de cada vacunación, el requisito 6 sería imposible de satisfacer.

Ejercicio 4: Reescribir un enunciado ambiguo

Este enunciado de una academia de idiomas tiene varios problemas. Identifícalos y reescríbelo.

“La academia tiene alumnos y cursos. Los estudiantes se apuntan a los cursos que imparten los profesores. Se guarda la nota y el nivel. Cada clase tiene un aula. Se necesita saber la edad de los alumnos.”

Ver solución

Problemas detectados:

Sinónimos: “alumnos” y “estudiantes”; “cursos” y “clases” (¿son lo mismo?).
Atributos sin dueño: “la nota” ¿de qué? (¿del alumno en un curso?); “el nivel” ¿del curso o del alumno?
Cardinalidades sin indicar: ¿cuántos profesores tiene un curso? ¿En cuántos cursos puede estar un alumno? ¿Un aula se usa para varios cursos?
Identificadores no indicados: ¿cómo se distinguen alumnos, cursos, profesores y aulas?
Dato derivado: la edad cambia cada año; debe guardarse la fecha de nacimiento.
Datos no especificados: no se dice qué se guarda de cada profesor ni de cada aula.
Histórico: ¿interesa saber en qué cursos estuvo un alumno en años anteriores?

Versión reescrita (con supuestos razonables, que en un caso real se validarían con la academia):

“De cada alumno se guarda un número de alumno, que lo identifica, su nombre, sus apellidos, su fecha de nacimiento (para calcular la edad) y un teléfono. De cada curso se guarda un código, que lo identifica, el idioma, el nivel (A1, A2, B1, B2, C1 o C2), el horario y el precio. Cada curso lo imparte un único profesor, y un profesor puede impartir varios cursos o ninguno. De cada profesor se guarda su DNI, que lo identifica, su nombre y los idiomas que puede enseñar. Cada curso se da siempre en la misma aula; de cada aula se guarda su número, que la identifica, y su capacidad. En un aula se pueden dar varios cursos en horarios distintos. Un alumno puede matricularse en varios cursos y en un curso hay varios alumnos; de cada matrícula se guarda la fecha y, al terminar el curso, la nota final. Se conservan las matrículas de cursos de años anteriores.”

Fíjate en que la versión reescrita usa un único término para cada concepto, indica los identificadores, da las cantidades en los dos sentidos de cada asociación y aclara el histórico.

Ejercicio 5: Análisis gramatical de una liga deportiva

Aplica el análisis gramatical completo (pasos 2 a 7) a este enunciado:

“Una federación quiere gestionar su liga de baloncesto. De cada equipo se guarda un código, que lo identifica, el nombre, la ciudad y el año de fundación. Cada equipo tiene varios jugadores, y cada jugador pertenece a un único equipo. De los jugadores se guarda su número de licencia, que los identifica, el nombre, la fecha de nacimiento, la altura y la posición. Cada equipo tiene un único entrenador, y un entrenador entrena a un único equipo; del entrenador se guarda su número de licencia, que lo identifica, y el nombre. En la liga se juegan partidos, identificados por un número; en cada partido se enfrentan un equipo local y un equipo visitante, y se guarda la fecha, el resultado del local y el resultado del visitante. Además se registran los puntos que anota cada jugador en cada partido.”

Ver solución

Sustantivos y filtrado.

Sustantivo	Decisión
federación, liga	Se descartan: son el propio sistema
equipo	Entidad EQUIPO (codigo, nombre, ciudad, anio_fundacion)
jugador	Entidad JUGADOR (licencia, nombre, fecha_nacimiento, altura, posicion)
entrenador	Entidad ENTRENADOR (licencia, nombre)
partido	Entidad PARTIDO (numero, fecha, resultado_local, resultado_visitante)
equipo local, equipo visitante	No son entidades nuevas: son papeles que juega EQUIPO en su relación con PARTIDO
puntos	Atributo de la relación entre JUGADOR y PARTIDO

Verbos y cardinalidades.

Relación	Un A…	Un B…	Tipo
EQUIPO tiene JUGADOR	Un equipo tiene “varios” jugadores → (1,n)	Un jugador pertenece a “un único” equipo → (1,1)	1:N
ENTRENADOR entrena EQUIPO	Un entrenador entrena “un único” equipo → (1,1)	Un equipo tiene “un único” entrenador → (1,1)	1:1
EQUIPO juega como local PARTIDO	Un equipo juega como local 0 o muchos partidos → (0,n)	Un partido tiene exactamente un local → (1,1)	1:N
EQUIPO juega como visitante PARTIDO	Igual: (0,n) junto a PARTIDO	(1,1) junto a EQUIPO	1:N
JUGADOR anota en PARTIDO	Un jugador participa en 0 o muchos partidos → (0,n)	En un partido anotan 0 o muchos jugadores → (0,n)	N:M

Diagrama preliminar.

flowchart LR
    ENTRENADOR[ENTRENADOR] ---|"(1,1)"| entrena{entrena}
    entrena ---|"(1,1)"| EQUIPO[EQUIPO]
    EQUIPO ---|"(1,1)"| tiene{tiene}
    tiene ---|"(1,n)"| JUGADOR[JUGADOR]
    EQUIPO ---|"(1,1)"| local{local}
    local ---|"(0,n)"| PARTIDO[PARTIDO]
    EQUIPO ---|"(1,1)"| visitante{visitante}
    visitante ---|"(0,n)"| PARTIDO
    JUGADOR ---|"(0,n)"| anota{anota}
    anota ---|"(0,n)"| PARTIDO
    anota --- an_pts([puntos])

Decisiones comentadas:

Local y visitante son dos relaciones distintas entre las mismas entidades (EQUIPO y PARTIDO). No crees entidades EQUIPO_LOCAL y EQUIPO_VISITANTE: son el mismo tipo de objeto en papeles distintos. El módulo 06 estudia las relaciones múltiples y los papeles.
puntos depende de la pareja jugador–partido: es atributo de la relación anota.
Restricción no expresable en el diagrama: el equipo local y el visitante de un partido deben ser distintos. Se documenta aparte.
Duda para el usuario: ¿un jugador puede cambiar de equipo durante la temporada? Si es así, “pertenece a un único equipo” solo sería cierto en cada momento, y habría que guardar el histórico.
El resultado del partido podría ser derivado (suma de los puntos de los jugadores de cada equipo), pero solo si se registran los puntos de todos los jugadores. Se guarda explícitamente para no depender de ello.

Ejercicio 6: Análisis de un formulario

Este es el impreso de inscripción de un club de senderismo. Indica qué entidades, atributos y relaciones puedes deducir y qué preguntas harías al club.

CLUB DE MONTAÑA "LOS PICOS"           INSCRIPCIÓN EN SALIDA
Nº socio: 0342     Nombre: Andrés Martín Soler
Teléfonos: 611223344 / 963112233     Federado: Sí  Nº licencia: V-88231
------------------------------------------------------------
Salida: Ruta del Cares     Fecha: 12/05/2026    Dificultad: Media
Guía responsable: Elena Ros (guía nº 12)
Plazas: 30     Precio: 25 €   (socios federados: 20 €)
Necesita transporte del club: Sí
Firma: ________

Ver solución

Elemento	Tipo	Comentario
SOCIO	Entidad	num_socio, nombre, telefonos (multivaluado), federado, num_licencia (0,1: solo si es federado)
SALIDA	Entidad	Necesita un identificador: ¿un código? ¿(ruta, fecha)? Atributos: ruta, fecha, dificultad, plazas, precio
GUIA	Entidad	num_guia, nombre. Pregunta: ¿los guías son también socios?
se_inscribe	Relación SOCIO–SALIDA N:M	Atributo de relación: necesita_transporte (depende del socio y de la salida)
dirige	Relación GUIA–SALIDA 1:N	Una salida tiene un guía responsable; un guía dirige varias salidas
precio pagado	Atributo derivado	Depende de si el socio es federado: se puede calcular a partir del precio y de la condición de federado (si las reglas no cambian con el tiempo)

Preguntas para el club:

¿El atributo federado es redundante con num_licencia? (Si tiene licencia, está federado.) Podría eliminarse uno de los dos.
¿Qué identifica a una salida? Si una ruta se repite cada año, ¿la ruta es una entidad (RUTA con nombre y dificultad) y la salida una realización de esa ruta en una fecha?
¿Hay que controlar que no se inscriban más socios que plazas? Esto es una restricción que el diagrama no expresa.
¿Los guías son socios del club? Si lo son, quizá GUIA sea un subtipo de SOCIO (módulo 11).
¿Pueden inscribirse personas que no son socias?

Lo interesante del ejercicio es cómo un documento de una sola página genera cinco preguntas de diseño importantes: los formularios muestran datos, pero no reglas.

Ejercicios propuestos

✏️ Ejercicio: Propuesto 1 — Ciclo de vida de una tienda online. Describe, para una pequeña tienda online de libros de segunda mano, qué se haría concretamente en cada una de las siete fases del ciclo de vida. Para cada fase indica al menos un producto o entregable.

✏️ Ejercicio: Propuesto 2 — Guion de entrevista. Prepara un guion de diez preguntas para entrevistar al gerente de una agencia de viajes que quiere gestionar viajes organizados, clientes, reservas, hoteles y guías. Incluye al menos tres preguntas sobre cardinalidades y dos sobre histórico.

✏️ Ejercicio: Propuesto 3 — Requisitos de un hospital. Escribe cinco requisitos de datos, tres funcionales y dos no funcionales para la gestión de ingresos de un hospital (pacientes, médicos, plantas, habitaciones y camas). Comprueba que cada requisito funcional se puede satisfacer con los requisitos de datos que has escrito.

✏️ Ejercicio: Propuesto 4 — Análisis gramatical de una plataforma de streaming. Aplica el método completo de la sección 6 a este enunciado: “De cada usuario se guarda su email, que lo identifica, su nombre, su fecha de alta y el plan contratado (básico, estándar o premium). Cada usuario puede crear hasta cinco perfiles; de cada perfil se guarda el nombre y si es infantil. De cada serie se guarda un código, el título, el año de estreno y los géneros. Una serie tiene varias temporadas, numeradas desde 1, y cada temporada tiene varios episodios numerados, con su título y su duración. Se registra qué episodios ha visto cada perfil, con la fecha y el minuto en que se quedó.” Señala qué dudas te surgen (pista: piensa en qué identifica a un episodio).

✏️ Ejercicio: Propuesto 5 — Análisis de un documento. Busca un ticket de compra real de un supermercado (o una factura de luz) y analízalo como en el ejemplo de la sección 5.2: entidades, atributos, datos derivados, datos que son “valores del momento” y preguntas para el usuario.

Resumen

Concepto	Idea clave
Ciclo de vida	Planificación → análisis de requisitos → diseño → implementación → carga → pruebas → explotación y mantenimiento, con realimentación
Diseño conceptual	Esquema E/R independiente del SGBD; responde a “¿qué datos hay y cómo se relacionan?”
Diseño lógico	Esquema relacional normalizado; depende del tipo de SGBD
Diseño físico	Tipos, índices, almacenamiento, seguridad; depende del SGBD concreto
Modelo de datos	Estructuras + restricciones (inherentes y semánticas) + operaciones
Esquema / ejemplar	Intensión (estructura, estable) / extensión (datos, cambiante)
Clasificación de modelos	Conceptuales (E/R, UML), lógicos (relacional, documental…), físicos
Técnicas de requisitos	Entrevistas, cuestionarios, análisis de documentos, observación, prototipos
Tipos de requisitos	De datos (qué guardar), funcionales (qué hacer), no funcionales (cómo de bien)
Enunciado o supuesto	Un concepto por frase, término único, cardinalidades en ambos sentidos, identificadores, histórico
Análisis gramatical	Sustantivos → entidades/atributos; verbos → relaciones; cuantificadores → cardinalidades
Modelo E/R	Peter Chen (1976); extendido (EER) con generalización y agregación; notación de Chen extendida (de Miguel/Piattini) en el curso

Navegación
← Módulo anterior: Sistemas gestores de bases de datos	Siguiente módulo: Entidades y atributos →