Los tres niveles de diseño

Modelar datos es traducir un enunciado escrito en lenguaje corriente a una descripción precisa de qué información hay que guardar y cómo se relaciona entre sí. Es análisis estructural: se ocupa de la forma de los datos, no de lo que el programa hace con ellos.

Esa distinción importa porque en el análisis de un sistema conviven dos miradas. El análisis estructural responde a la pregunta de qué datos existen y cómo se conectan. El análisis funcional responde a qué procesos los transforman. Un diagrama entidad-relación pertenece a la primera; un diagrama de flujo de datos, a la segunda. En este tema solo se trabaja la primera.

El modelado se hace antes de escribir una sola sentencia de creación de tablas, y por una razón muy práctica: los errores de modelado son los más caros de corregir. Cambiar una consulta cuesta una tarde; cambiar la clave primaria de una tabla con dos millones de filas y quince programas encima cuesta un proyecto.

Modelar datos es análisis estructural: qué información hay y cómo se relaciona. Lo que el sistema hace con esa información es análisis funcional y va por otro camino.

El diseño de una base de datos se hace en tres pasadas, cada una menos abstracta que la anterior. El modelo conceptual se convierte en modelo lógico aplicando reglas de transformación conocidas, y el modelo lógico se convierte en modelo físico al escribirlo en el lenguaje del gestor concreto que se vaya a usar.

La normalización, que se ve al final de este tema, es una técnica que se aplica sobre el modelo lógico: sobre relaciones ya definidas, no sobre entidades del diagrama conceptual y no sobre tablas ya creadas en el gestor.

Conceptual, independiente de todo. Lógico, dependiente del tipo de base de datos. Físico, dependiente del gestor concreto. Esa gradación de dependencia es lo que se pregunta.

ANSI/SPARC es la arquitectura de referencia de un sistema gestor de bases de datos. Propone describir la misma base de datos en tres niveles de abstracción, de forma que cada uno pueda cambiar sin arrastrar a los demás.

El valor de la arquitectura está en las dos independencias que hace posibles. La independencia física significa que se puede cambiar el nivel interno (añadir un índice, mover un fichero, reorganizar el almacenamiento) sin tocar el nivel conceptual ni las aplicaciones. La independencia lógica significa que se puede cambiar el nivel conceptual (añadir un atributo, dividir una tabla) sin tocar las vistas que ya usan las aplicaciones existentes.

La independencia lógica es notablemente más difícil de conseguir que la física, porque una vista no siempre puede seguir ofreciendo lo mismo cuando el esquema que hay debajo cambia de forma. Ese detalle es una pregunta de examen frecuente.

Tres niveles: externo (vistas), conceptual (tablas) e interno (almacenamiento). El sistema aguanta mejor los cambios porque los niveles están desacoplados.

El modelo lógico depende del tipo de base de datos, y a lo largo de la historia han existido cuatro grandes familias. Conocerlas sirve para entender por qué ganó el modelo relacional.

• Jerárquico: los datos se organizan como un árbol, cada registro tiene un único padre. Rápido de recorrer hacia abajo y muy rígido: representar que un dato depende de dos padres obliga a duplicarlo.
• En red: generaliza el anterior permitiendo que un registro tenga varios padres. Gana flexibilidad y pierde sencillez, porque el programador tiene que navegar explícitamente por los punteros.
• Relacional: propuesto por Edgar F. Codd. Todo son relaciones (tablas) y los enlaces no son punteros, sino valores que coinciden. Es el modelo dominante y el que se supone en el resto del tema.
• Orientado a objetos: guarda directamente objetos con su estado y su comportamiento, sin traducir a filas y columnas. Encaja bien con los lenguajes orientados a objetos y nunca llegó a desplazar al relacional.

La ventaja decisiva del modelo relacional para este tema es que el paso desde un diagrama entidad-relación está resuelto: existe un juego de reglas de transformación cerrado y mecánico, que se ve más adelante. Con los otros modelos esa traducción es artesanal.

El entidad-relación no es el único modelo conceptual, aunque sí el que se pregunta. Conviene reconocer los otros nombres cuando aparecen en una opción de respuesta.

• Modelo RM/T, de Codd y Date. Es una extensión del modelo relacional que le añade capacidad semántica, es decir, la posibilidad de expresar en el propio modelo cosas como la herencia o la agregación, que el relacional puro no sabe representar.
• Modelos semánticos. Familia de modelos que persiguen recoger el significado de los datos y no solo su estructura. El entidad-relación extendido pertenece a esta familia.
• Diagrama de clases de UML. Es el equivalente del entidad-relación dentro del lenguaje unificado de modelado. Donde el E/R dice entidad y relación, UML dice clase y asociación.
• Métrica versión 3. No es un modelo, es una metodología pública de planificación, desarrollo y mantenimiento de sistemas de información. Aparece aquí porque prescribe qué modelos usar en el análisis y el diseño.

Al diagrama entidad-relación le corresponde, dentro de UML, el diagrama de clases. Confundirlo con el diagrama de objetos o con el de componentes es el fallo típico.