Documentación del modelo de datos

1. DOCUMENTACIÓN DEL MODELO DE DATOS #

Los modelos Entidad/Relación (E/R) y Entidad/Relación Extendido (E/R Extendido) son herramientas gráficas útiles para representar estructuras de datos en un sistema, pero tienen limitaciones. No pueden capturar todas las restricciones necesarias para definir completamente el dominio de un problema.

Restricciones en el Modelo de Datos #

Una restricción es una condición que debe cumplir una instancia para pertenecer correctamente al dominio del problema que se está modelando. Las restricciones pueden aplicarse en varios niveles:

a) Valores de Atributos: Restricciones que limitan los valores que un atributo específico puede tomar.

b) Participación de Entidades en Relaciones: Restricciones que definen los valores mínimos y máximos de participación de una entidad en una relación.

c) Existencia de Entidades Débiles o Jerárquicas: Restricciones relacionadas con la necesidad de que ciertas entidades existan sólo en relación con otras, como entidades débiles o entidades en relaciones jerárquicas.

Si bien las restricciones sobre la participación en relaciones y la existencia de entidades débiles pueden representarse gráficamente en el modelo E/R, las restricciones sobre los valores de los atributos no se pueden mostrar directamente en el diagrama. Por esta razón, el modelo debe complementarse con documentación adicional en forma de texto.

Estructura de la Documentación #

La documentación del modelo de datos sigue una estructura organizada que proporciona detalles sobre las entidades y relaciones en el sistema. Esta estructura incluye:

1. Descripción de las Entidades:
   • Nombre de la Entidad: Identificación única de la entidad en el modelo.
   • Breve Descripción: Resumen de lo que representa la entidad en el sistema.
   • Atributos:
     • Nombre del Atributo: Identificación del atributo dentro de la entidad.
     • Función: Especifica si el atributo forma parte del identificador o si describe la entidad.
     • Descripción de Valores: Explicación de los valores que puede tomar el atributo.
     • Dominio de Valores: Conjunto de valores permitidos que el atributo puede asumir.
2. Descripción de las Relaciones:
   • Nombre de la Relación: Identificación única de la relación en el modelo.
   • Breve Descripción: Resumen de lo que representa la relación en el sistema.
   • Grado de la Relación: Número de entidades que participan en la relación.
   • Cardinalidad de la Relación: Define la relación numérica entre las instancias de las entidades que participan en la relación.
   • Entidades Asociadas:
     • Nombre: Identificación de cada entidad que participa en la relación.
     • Participación Mínima y Máxima: Define el número mínimo y máximo de veces que una instancia de la entidad puede participar en la relación.
   • Atributos Propios de la Relación:
     • Nombre del Atributo: Identificación del atributo dentro de la relación.
     • Función: Especifica si el atributo se utiliza para identificar la relación o para describirla.
     • Descripción de Valores: Explicación de los valores que puede tomar el atributo.
     • Dominio de Valores: Conjunto de valores permitidos que el atributo puede asumir en la relación.

Esta documentación es esencial para proporcionar una visión completa y precisa del modelo de datos, asegurando que todas las restricciones y características necesarias del sistema estén claramente definidas y comprendidas.

2. Herramientas de modelado conceptual #

3. Uso de herramientas gráficas #

Una herramienta de diagramación ayuda a construir y revisar el modelo conceptual. Su objetivo en esta fase no es generar tablas ni código SQL, sino representar con claridad el significado de los datos y las reglas del dominio, sin depender de un SGBD concreto.

Funciones útiles en el modelado conceptual #

1. Representar el dominio: crear entidades, atributos, identificadores, relaciones, roles y restricciones de participación.
2. Mantener una notación coherente: aplicar los mismos símbolos y convenciones en todo el diagrama.
3. Facilitar la revisión: reorganizar el modelo y detectar elementos duplicados, relaciones ambiguas o cardinalidades incompletas.
4. Documentar decisiones: añadir descripciones y reglas de negocio que no se puedan expresar gráficamente.
5. Compartir el modelo: exportarlo como imagen o documento para validarlo con las personas conocedoras del dominio.

Ejemplos de herramientas #

• ERDPlus: permite crear diagramas E/R con una notación orientada al aprendizaje.
• diagrams.net: herramienta general de diagramación que puede utilizarse con una plantilla y una leyenda E/R acordadas.
• Oracle SQL Developer Data Modeler y ER/Studio: admiten varios niveles de modelado; en este curso se usarían únicamente sus funciones de modelo conceptual.

Proceso de trabajo con una herramienta gráfica #

1. Recoger requisitos y reglas de negocio antes de dibujar.
2. Identificar entidades y atributos, incluyendo los identificadores candidatos.
3. Definir relaciones, roles y participación mínima y máxima.
4. Revisar el modelo con ejemplos concretos para comprobar que admite situaciones válidas y rechaza las inválidas.
5. Validarlo con las personas expertas del dominio y registrar las decisiones que no sean evidentes en el diagrama.

La transformación del modelo conceptual a un modelo lógico pertenece a una fase posterior y queda fuera del alcance de este curso.

4. Documentación y Análisis de Restricciones Semánticas #

5. Introducción a las Restricciones Semánticas en Bases de Datos #

Las restricciones semánticas son reglas del dominio que determinan qué estados y asociaciones son válidos. Algunas pueden representarse mediante cardinalidades o identificadores; otras deben documentarse en lenguaje natural porque el diagrama E/R no puede expresarlas por completo.

6. Tipos Comunes de Restricciones Semánticas #

1. Restricciones de Dominio
   • Descripción: Estas restricciones especifican los valores permitidos para un atributo particular. Por ejemplo, el atributo Edad de Empleado podría admitir únicamente valores entre 18 y 65.
   • Ejemplo:
     • Atributo: Edad.
     • Restricción de Dominio: Edad >= 18 AND Edad <= 65.
2. Restricciones de Unicidad
   • Descripción: Aseguran que el valor de un atributo, o una combinación de atributos, no se repita entre las ocurrencias de una entidad. Puede existir más de un identificador candidato, como un número de afiliación o un correo electrónico.
   • Ejemplo:
     • Atributo: Correo Electrónico.
     • Restricción de Unicidad: Cada correo electrónico debe ser único entre las ocurrencias de Usuario.
3. Restricciones de Existencia
   • Descripción: Expresan que una ocurrencia depende de otra para poder existir. Por ejemplo, una asignación a un proyecto solo puede existir para un empleado reconocido por el sistema.
   • Ejemplo:
     • Condición: No puede existir una Asignación sin el Empleado correspondiente.
4. Restricciones de Cardinalidad
   • Descripción: Definen el número mínimo y máximo de veces que una ocurrencia puede participar en una relación.
   • Ejemplo:
     • Condición: Un Cliente puede tener como máximo un Asesor asignado, pero un Asesor puede manejar múltiples Clientes.
5. Restricciones Derivadas
   • Descripción: Son restricciones que dependen de otros valores en la base de datos. Por ejemplo, el salario de un empleado puede depender de su puesto de trabajo, y no se permite que los salarios sean inconsistentes con la categoría laboral.
   • Ejemplo:
     • Condición: El Salario debe ser mayor o igual que el Salario Mínimo del Puesto correspondiente.

7. Documentación de Restricciones Semánticas #

Documentar las restricciones semánticas es un paso crítico en el diseño de bases de datos, ya que permite que todos los miembros del equipo de desarrollo comprendan las reglas que rigen los datos. Las herramientas de modelado gráfico suelen incluir funciones para documentar estas restricciones directamente en el modelo, lo que facilita la comprensión y el mantenimiento de la base de datos.

1. Incorporación de Restricciones en el Modelo
   • Descripción: Las restricciones semánticas se pueden definir directamente en las herramientas de modelado, donde se documentan como parte de las propiedades de los atributos o relaciones. Esto incluye la definición de reglas de negocio, validaciones, y restricciones personalizadas.
   • Beneficio: Permite que las restricciones sean visibles y comprensibles directamente desde el modelo, asegurando que sean implementadas correctamente durante la construcción de la base de datos.
2. Generación Automática de Documentación
   • Descripción: Muchas herramientas de modelado pueden generar documentación que incluye una descripción completa de todas las restricciones semánticas aplicadas en el modelo. Esta documentación es útil para la revisión por parte de analistas de negocio, desarrolladores y auditores.
   • Beneficio: Facilita la comunicación entre los equipos y asegura que las restricciones estén claramente definidas y comprendidas.
3. Análisis de Restricciones Semánticas
   • Descripción: El análisis de restricciones semánticas implica revisar y validar que las reglas definidas no solo sean lógicas y coherentes, sino también implementables dentro del modelo de base de datos. Esto puede incluir la verificación de que las restricciones no entren en conflicto entre sí y que se alineen con las políticas del negocio.
   • Ejemplo: Un análisis puede mostrar si una regla de unicidad es coherente con el dominio o si admite excepciones que deben documentarse.
4. Validación con personas expertas del dominio
   • Descripción: Las restricciones se contrastan con casos normales, casos límite y situaciones inválidas antes de aprobar el modelo.
   • Beneficio: Evita que una decisión técnica aparente sustituya por error a una regla real del negocio.

8. Lista de comprobación del modelo conceptual #

Esta lista ayuda a revisar el modelo antes de considerarlo terminado. Una respuesta negativa no significa siempre que exista un error, pero sí que la decisión debe revisarse o documentarse.

Alcance y vocabulario #

• El objetivo y los límites del modelo están escritos y han sido acordados.
• Cada término tiene una definición única en el glosario del dominio.
• No existen dos nombres para el mismo concepto ni un nombre con significados diferentes.
• Cada elemento del modelo puede relacionarse con un requisito o una regla de negocio.

Entidades #

• Cada entidad representa un concepto relevante con ocurrencias distinguibles.
• Los nombres de las entidades son sustantivos en singular y tienen significado para el negocio.
• No se han convertido en entidades valores que deberían ser atributos.
• Los acontecimientos con identidad, historial o relaciones propias se han considerado explícitamente.
• Las entidades fuertes y débiles están diferenciadas por su forma de identificación, no solo por su dependencia existencial.

Identificadores y atributos #

• Cada entidad fuerte tiene al menos un identificador candidato.
• El identificador elegido es único, mínimo y suficientemente estable en el dominio.
• Las claves parciales de las entidades débiles están indicadas y documentadas.
• Cada atributo describe a la entidad o relación a la que está conectado.
• Los atributos compuestos, multivalorados, derivados y opcionales están representados de forma coherente.
• Los valores calculables no se han modelado como independientes sin una justificación.

Relaciones y roles #

• Cada relación expresa una regla del dominio y tiene un nombre comprensible.
• La relación puede leerse con sentido en todas las direcciones necesarias.
• Los roles están indicados cuando una entidad participa más de una vez en la misma relación.
• Los atributos que dependen de una asociación están unidos a la relación correspondiente.
• Las relaciones ternarias o n-arias no se han sustituido por binarias sin demostrar que se conserva el significado.

Cardinalidad y opcionalidad #

• Cada participación tiene definidos un mínimo y un máximo.
• Los mínimos distinguen claramente entre participación opcional y obligatoria.
• Los máximos se han confirmado con ejemplos y no se basan en suposiciones.
• La cardinalidad se ha leído y validado desde cada entidad participante.
• Los límites temporales, como «un préstamo activo», están documentados aunque no puedan expresarse completamente en el diagrama.

Redundancia y coherencia #

• No hay entidades, atributos o relaciones duplicados con nombres diferentes.
• Un mismo hecho no se almacena en varios lugares sin una razón explícita.
• No existen atributos que contradigan una relación ya representada.
• Las reglas semánticas no se contradicen entre sí.
• La notación utilizada es uniforme y dispone de una leyenda cuando puede resultar ambigua.

Validación mediante ejemplos #

• El modelo permite representar varios casos normales del dominio.
• Se han probado valores mínimos, máximos y situaciones opcionales.
• Se han planteado casos inválidos y se conoce qué regla los rechaza.
• Se han revisado cambios temporales y la necesidad de conservar historial.
• Las personas expertas del dominio han entendido y aprobado el significado del modelo.

Ejemplo de Documentación y Análisis #

Imagina que estás modelando una base de datos para un sistema de gestión de hospital. Uno de los requisitos del negocio es que cada médico solo puede estar asignado a un máximo de tres pacientes a la vez (una restricción de cardinalidad), y que el salario de cada médico debe estar dentro de un rango predefinido dependiendo de su especialidad (una restricción derivada).

• Documentación:
  • Restricción de Cardinalidad: Se documenta que la relación entre Médico y Paciente es uno a muchos, pero con un límite superior de tres.
  • Restricción Derivada: El salario del Médico se documenta como dependiente de su Especialidad.
• Análisis:
  • Validación de Cardinalidad: Verificación de que la relación entre Médico y Paciente respeta la regla de tres pacientes por médico.
  • Validación de Rango Salarial: Confirmación de que todos los registros cumplen con los límites salariales según la especialidad.

Este proceso asegura que el diseño de la base de datos no solo esté técnicamente correcto, sino que también cumpla con las expectativas y reglas del negocio, manteniendo la integridad y la coherencia de los datos.