Tema 15. Modelado de datos, metodologías y reglas. Entidades, atributos y relaciones. Diseño de bases de datos. Diseño lógico y físico. El modelo lógico relacional. Normalización.

1. Modelado de datos, metodologías y reglas

1. Modelado de datos, metodologías y reglas

🎯 Idea clave

• El modelado de datos construye representaciones abstractas y formales de la información de un dominio para permitir su tratamiento eficaz por sistemas informáticos.
• Constituye un ejercicio de comprensión del negocio que fija un lenguaje común entre los equipos participantes en el ciclo de vida del sistema.
• El proceso abarca tres niveles de abstracción: el conceptual describe el dominio, el lógico lo formaliza según un modelo, y el físico lo adapta a un SGBD concreto.
• Una metodología típica comprende las fases de requisitos, análisis, diseño conceptual, diseño lógico, diseño físico, implementación, pruebas y mantenimiento.
• En las Administraciones Públicas españolas, el modelado se integra con marcos como MAGERIT, el Esquema Nacional de Interoperabilidad y el Esquema Nacional de Seguridad.

📚 Desarrollo

Definición fundamental. El modelado de datos es la disciplina que construye representaciones abstractas y formales de la información que circula por un dominio determinado, con el objetivo último de que dicha información pueda ser tratada de manera eficaz por sistemas informáticos.

Ejercicio de comprensión. No se trata de una actividad meramente técnica, sino ante todo un ejercicio de comprensión del negocio, de comunicación entre los distintos equipos que participan en el ciclo de vida del sistema y de fijación de un lenguaje común que permita razonar con precisión sobre las entidades, los hechos y las reglas que conforman la realidad que se desea informatizar.

Niveles de abstracción. El proceso distingue tres niveles fundamentales: el nivel conceptual, que describe el dominio; el nivel lógico, que lo formaliza según un modelo específico; y el nivel físico, que lo adapta a un sistema gestor de bases de datos concreto.

Metodología de trabajo. Una metodología típica de modelado incluye las fases de requisitos, análisis, diseño conceptual, diseño lógico, diseño físico, implementación, pruebas y mantenimiento, permitiendo una evolución controlada desde la realidad observada hasta el sistema implementado.

Marcos normativos específicos. En el ámbito de la Administración española, el modelado se integra con marcos normativos y técnicos específicos como MAGERIT, metodología de análisis y gestión de riesgos que exige inventariar los activos de información; el Esquema Nacional de Interoperabilidad y el Esquema Nacional de Seguridad, que establecen requisitos que afectan al tratamiento y modelado de los datos.

Interoperabilidad y estándares. Para favorecer la interoperabilidad entre administraciones se utilizan modelos de datos comunes, como el perfil DCAT-AP-ES para datos abiertos, adaptación española de la norma europea DCAT-AP, y para el ámbito geoespacial la Directiva INSPIRE, que establece esquemas armonizados que las administraciones deben respetar. El Centro de Transferencia de Tecnología pone a disposición modelos compartidos y soluciones reutilizables.

🧩 Elementos esenciales

• Modelado de datos: disciplina que representa información, significado, relaciones y restricciones antes de implementar una base de datos.
• Nivel conceptual: describe el dominio de negocio sin atender a aspectos técnicos de implementación.
• Nivel lógico: formaliza el modelo según una tecnología específica manteniendo independencia física.
• Nivel físico: adapta el modelo a las características concretas de un SGBD particular.
• Reglas de modelado: incluyen identificación, cardinalidad, opcionalidad, integridad, dominios, temporalidad, calidad, seguridad y ciclo de vida.
• MAGERIT: metodología de gestión de riesgos que conecta con el inventario y catalogación de activos de información.
• Esquema Nacional de Interoperabilidad (ENI): establece el uso de modelos de datos comunes entre administraciones.
• Esquema Nacional de Seguridad (ENS): condiciona el modelado según requisitos de seguridad de la información.
• DCAT-AP-ES: perfil español para la descripción de catálogos de datos abiertos.
• INSPIRE: marco de modelos de datos para información geográfica en la Unión Europea.
• Diccionario de datos: documenta significado, tipo, origen, obligatoriedad, dominio, sensibilidad y reglas de cada dato.

🧠 Recuerda

• El modelado es previo a la implementación y representa la realidad observada de forma abstracta y formal.
• Un buen modelo reduce ambigüedad, facilita el mantenimiento y mejora la calidad de la información.
• La normalización reduce redundancias y anomalías, mientras que la desnormalización solo debe aplicarse de forma justificada y controlada.
• La interoperabilidad, seguridad y protección de datos condicionan el modelo en sistemas administrativos.
• No debe confundirse modelar datos con copiar pantallas, dibujar tablas aisladas o elegir prematuramente índices físicos.
• El Centro de Transferencia de Tecnología ofrece modelos compartidos reutilizables para las administraciones públicas.

2. Entidades, atributos y relaciones

2. Entidades, atributos y relaciones

🎯 Idea clave

• Las entidades, los atributos y las relaciones son los elementos básicos para representar la información de un dominio en el modelado de datos.
• Una entidad describe una clase de objetos o conceptos sobre los que el sistema necesita conservar datos.
• Un atributo describe una propiedad específica de una entidad o de una relación.
• Una relación describe una asociación significativa entre dos o más entidades.
• Una entidad debe poseer identidad propia, permitiendo tener ocurrencias distinguibles dentro del sistema.
• La decisión sobre qué conceptos constituyen entidades depende exclusivamente del alcance del sistema, no de su importancia abstracta.

📚 Desarrollo

Elementos fundamentales del modelado. Las entidades, los atributos y las relaciones constituyen los pilares básicos sobre los que se construye cualquier representación formal de la información. Estos tres elementos permiten transformar la realidad observada en un modelo abstracto, comprensible y posteriormente implementable en una base de datos.

Definición de entidad. Una entidad describe una clase de objetos o conceptos sobre los que el sistema necesita conservar datos. No se trata simplemente de cualquier palabra relevante extraída del lenguaje del usuario, sino de un concepto que posee identidad propia dentro del sistema y que requiere ser gestionado de forma independiente.

Características diferenciadoras. Para que un concepto sea considerado entidad válida, debe cumplir tres condiciones esenciales: poder tener ocurrencias distinguibles entre sí, poseer atributos propios que la describan, y mantener participación en relaciones con otras entidades. Estas características permiten diferenciar una entidad de simples términos o categorías descriptivas.

Definición de atributo. Un atributo describe una propiedad de una entidad o de una relación. Representa las características específicas que se desean registrar sobre cada ocurrencia, determinando qué información concreta se almacenará y cómo se estructurarán los valores dentro del sistema.

Definición de relación. Una relación describe una asociación significativa entre entidades. Establece las conexiones lógicas que existen entre los diferentes conceptos del dominio, permitiendo representar cómo interactúan y dependen unos de otros los datos gestionados por la aplicación.

Criterio de identificación. La determinación de qué conceptos deben modelarse como entidades depende siempre del alcance específico del sistema. El criterio fundamental no es que el concepto sea importante en abstracto, sino que el sistema deba poder identificarlo, almacenarlo, consultarlo o relacionarlo efectivamente durante su funcionamiento.

Ejemplos prácticos. En una aplicación administrativa podrían existir entidades como expediente, interesado, unidad, documento o trámite. Sin embargo, la validez de cada una como entidad depende exclusivamente de que el sistema deba gestionarla de forma independiente, con capacidad de distinguir sus ocurrencias y vincularla con otras entidades del dominio.

🧩 Elementos esenciales

• Entidad: Clase de objetos o conceptos sobre los que el sistema necesita conservar datos.
• Atributo: Propiedad que describe características específicas de una entidad o de una relación.
• Relación: Asociación significativa que conecta dos o más entidades dentro del modelo.
• Ocurrencia: Instancia concreta y distinguible de una entidad que existe en el sistema.
• Identidad propia: Característica que permite diferenciar una entidad de otros conceptos similares o genéricos.
• Participación en relaciones: Capacidad de la entidad para vincularse con otras entidades del dominio.
• Alcance del sistema: Marco delimitador que determina qué conceptos se modelan como entidades según las necesidades de gestión.
• Atributos propios: Conjunto de características que definen la estructura interna de una entidad.
• Asociación significativa: Tipo de vínculo que debe existir entre entidades para constituir una relación válida.

🧠 Recuerda

• Los tres elementos básicos del modelado de datos son entidades, atributos y relaciones.
• Una entidad debe tener identidad propia y capacidad de generar ocurrencias distinguibles.
• Los atributos describen propiedades tanto de entidades como de las relaciones que las conectan.
• No todo concepto relevante es una entidad; debe ser necesario para el alcance del sistema.
• El criterio para definir una entidad depende de la necesidad de identificar, almacenar, consultar o relacionar el concepto.
• Las relaciones establecen conexiones significativas entre los conceptos del dominio modelado.
• La transformación de la realidad al modelo formal requiere estos tres elementos básicos.

3. Diseño de bases de datos

3. Diseño de bases de datos

🎯 Idea clave

• El diseño de bases de datos transforma los requisitos de información en una estructura coherente, segura, eficiente y mantenible.
• La metodología clásica comprende las fases de análisis de requisitos, diseño conceptual, diseño lógico, diseño físico, implementación, pruebas y mantenimiento.
• El diseño conceptual describe el dominio del problema sin ataduras tecnológicas, utilizando habitualmente el modelo entidad-relación.
• El diseño lógico formaliza el esquema conceptual en una estructura relacional con tablas, columnas, claves y restricciones.
• El diseño físico adapta la estructura lógica a un sistema gestor de bases de datos concreto, optimizando el rendimiento.
• La seguridad, protección de datos e interoperabilidad deben incorporarse desde las primeras fases del diseño.

📚 Desarrollo

Fases metodológicas. El diseño de una base de datos relacionales sigue una metodología que parte del análisis del dominio del problema y culmina en la implementación física. Las fases clásicas incluyen el análisis de requisitos, el diseño conceptual, el diseño lógico, el diseño físico, la implementación, las pruebas y el mantenimiento posterior.

Nivel conceptual. La primera fase, el modelado conceptual, suele realizarse con el modelo entidad-relación propuesto por Peter Chen en 1976. En este modelo se identifican las entidades que representan objetos del mundo real, los atributos que describen sus propiedades, las relaciones que vinculan entidades entre sí, y la cardinalidad que indica cuántas instancias pueden asociarse.

Nivel lógico. La segunda fase es el modelado lógico, donde el esquema conceptual se traduce a un esquema relacional. Cada entidad se transforma en una tabla con sus atributos; las relaciones uno a muchos se materializan mediante claves foráneas en la tabla del lado muchos; y las relaciones muchos a muchos generan una tabla intermedia que contiene las claves de ambas entidades.

Nivel físico. La tercera fase, el modelado físico, considera aspectos de rendimiento como la elección de tipos de datos óptimos, la definición de índices, el particionamiento y la asignación a tablespaces. En esta etapa se toman decisiones sobre almacenamiento que afectan directamente al rendimiento del sistema gestor.

Independencia y optimización. El diseño lógico define la estructura de datos de forma independiente del producto concreto, mientras que el diseño físico implementa y optimiza esa estructura en un SGBD específico. Las claves y restricciones pertenecen al nivel lógico aunque posteriormente se materialicen físicamente mediante sentencias SQL.

Operatividad y ciclo de vida. El diseño operativo incorpora mecanismos de backup, recuperación ante desastres, auditoría, trazabilidad y retención de datos según normativa. Un buen diseño prevé la evolución futura, la migración entre sistemas, el rendimiento sostenido y la gestión del ciclo de vida completo de la información.

Seguridad e interoperabilidad. La seguridad, la protección de datos y la interoperabilidad deben incorporarse desde las primeras fases del diseño, afectando tanto al nivel lógico como al físico. Estos requisitos condicionan el modelo en sistemas administrativos y garantizan la protección de la información sensible.

🧩 Elementos esenciales

• Análisis de requisitos: Fase inicial que recoge las necesidades de información antes de modelar la estructura definitiva.
• Diseño conceptual: Representación abstracta del dominio sin tecnología específica, habitualmente mediante modelo entidad-relación.
• Diseño lógico: Formalización del esquema conceptual en tablas, columnas, claves primarias y foráneas, y restricciones de integridad.
• Diseño físico: Adaptación al SGBD concreto mediante tipos de datos, índices, particiones y configuración de almacenamiento.
• Claves y restricciones: Elementos del diseño lógico que preservan la integridad de los datos y reducen la ambigüedad.
• Normalización: Proceso lógico que reduce redundancias y anomalías en la estructura de datos.
• Desnormalización: Técnica física que solo debe aplicarse de forma justificada y controlada para mejorar el rendimiento.
• Índices: Decisiones físicas orientadas a optimizar consultas, aunque penalizan las operaciones de escritura.
• Seguridad y protección: Requisitos que deben incorporarse desde el diseño tanto lógico como físico.
• Documentación: Incluye modelos, diccionario de datos, reglas, restricciones, permisos y procedimientos.
• Mantenimiento y evolución: Fases finales que garantizan la continuidad, recuperación y adaptación futura del sistema.

🧠 Recuerda

• El diseño conceptual describe el dominio sin ataduras tecnológicas.
• El diseño lógico formaliza la estructura en tablas y relaciones independientemente del SGBD.
• El diseño físico adapta y optimiza la implementación para un sistema gestor concreto.
• Las claves foráneas materializan las relaciones uno a muchos en el modelo relacional.
• Las relaciones muchos a muchos requieren una tabla intermedia en el diseño lógico.
• La normalización es una técnica lógica; la desnormalización es una decisión física justificada.
• Los índices mejoran la velocidad de consulta pero consumen recursos adicionales.
• La seguridad y protección de datos deben planificarse desde el inicio del diseño.
• La documentación debe incluir modelos, diccionario y reglas de negocio.
• Validar el diseño lógico no sustituye la validación del diseño físico.

4. Diseño lógico y físico

4. Diseño lógico y físico

🎯 Idea clave

• El diseño lógico define la estructura de datos de forma independiente al sistema gestor específico.
• El diseño físico concreta la implementación técnica optimizando el rendimiento en un SGBD determinado.
• Ambos niveles responden a preguntas distintas: qué datos existen frente a cómo se almacenan y acceden.
• La separación entre ambos planos garantiza la independencia de los datos y facilita el mantenimiento.
• Las claves, restricciones y normalización pertenecen al ámbito lógico, mientras que los índices y particiones al físico.

📚 Desarrollo

Niveles complementarios. El diseño lógico y el diseño físico constituyen dos etapas diferenciadas y complementarias dentro del proceso de diseño de bases de datos. El primer nivel se centra en organizar la información según un modelo de datos, habitualmente el relacional en sistemas transaccionales clásicos, mientras que el segundo determina cómo implementar esa estructura en un sistema gestor concreto optimizando recursos.

Enfoque del diseño lógico. Este nivel se pregunta qué datos existen, cómo se identifican unívocamente, qué relaciones mantienen entre sí y qué restricciones deben cumplirse permanentemente. Su resultado principal es un esquema lógico compuesto por tablas, columnas, claves, relaciones y reglas de integridad expresadas de forma independiente, en lo posible, de cualquier producto específico.

Enfoque del diseño físico. Este nivel se pregunta cómo se almacenan y acceden eficientemente esos datos en una plataforma concreta, considerando una carga de trabajo específica y unas necesidades de servicio determinadas. Concreta tipos de datos, índices, estructuras de almacenamiento, particiones, parámetros de configuración, seguridad y decisiones de rendimiento adaptadas al entorno tecnológico.

Independencia de datos. Separar ambos niveles permite mantener la independencia de los datos esencial para el mantenimiento evolutivo. El modelo lógico representa el significado semántico de la información, mientras que el físico optimiza su explotación técnica. Añadir un índice cambia el diseño físico sin alterar el significado lógico de una entidad ni las tuplas válidas.

Transformación desde el modelo conceptual. El diseño lógico suele partir del modelo conceptual previamente definido, transformando entidades en tablas, atributos en columnas, identificadores en claves primarias o candidatas, y relaciones en claves ajenas o tablas intermedias. Las cardinalidades, opcionalidades y reglas del dominio se traducen en restricciones formales del esquema.

Normalización y restricciones. La normalización pertenece principalmente al diseño lógico, organizando las relaciones para reducir redundancias y anomalías de actualización. Las restricciones lógicas deben expresarse de forma declarativa siempre que sea posible mediante cláusulas como NOT NULL, UNIQUE, PRIMARY KEY, FOREIGN KEY y CHECK para garantizar la integridad.

Diferenciación de elementos físicos. Una tabla SQL puede incluir índices, particiones, almacenamiento, estadísticas o triggers, pero estos elementos no forman parte de la relación como concepto lógico puro. Los índices mejoran el acceso sin cambiar las tuplas válidas, las particiones organizan el almacenamiento sin modificar el esquema lógico, y esta separación permite optimizar tras diseñar correctamente.

🧩 Elementos esenciales

• Diseño lógico: Define la estructura de datos de forma independiente al producto concreto, centrándose en el significado de la información.
• Diseño físico: Implementa y optimiza la estructura en un SGBD específico, atendiendo a rendimiento y almacenamiento.
• Esquema lógico: Conjunto de tablas, columnas, claves, relaciones y restricciones que representan la realidad modelada.
• Independencia lógico-física: Separación que permite optimizar el rendimiento sin alterar el significado de los datos.
• Claves y restricciones: Pertencen al diseño lógico, aunque se materialicen físicamente en SQL.
• Índices: Decisiones puramente físicas orientadas a mejorar el rendimiento y mantenimiento de consultas.
• Normalización: Proceso lógico que organiza relaciones para eliminar redundancias y anomalías de actualización.
• Desnormalización: Decisiones físicas que introducen redundancias controladas para mejorar rendimiento, sin ocultar un mal modelo inicial.
• Restricciones declarativas: Mecanismos como NOT NULL, UNIQUE y CHECK que el SGBD aplica para garantizar integridad.
• Validación dual: Verificar el diseño lógico no sustituye validar el físico, pues ambos presentan riesgos distintos.

🧠 Recuerda

• El diseño lógico responde a qué datos existen y cómo se relacionan.
• El diseño físico responde a cómo se almacenan y acceden esos datos.
• Las claves primarias y ajenas son elementos del diseño lógico.
• Los índices son elementos del diseño físico destinados al rendimiento.
• La normalización es una tarea propia del diseño lógico.
• La desnormalización debe justificarse en el diseño físico por razones de rendimiento.
• Confundir ambos niveles genera diseños difíciles de mantener.
• Las restricciones deben expresarse declarativamente en el esquema lógico.
• La recuperación y replicación son aspectos del diseño físico-operativo.
• Validar ambos niveles por separado es imprescindible para garantizar la calidad.

5. El modelo lógico relacional

5. El modelo lógico relacional

🎯 Idea clave

• El modelo lógico relacional representa los datos mediante relaciones organizadas en tablas bidimensionales formadas por filas y columnas.
• Fue propuesto por Edgar F. Codd sobre fundamentos matemáticos de teoría de conjuntos y lógica de predicados de primer orden.
• Establece una separación clara entre la representación lógica de la información y su almacenamiento físico en el sistema gestor.
• Las relaciones se componen de tuplas que corresponden a filas, atributos que corresponden a columnas y dominios que definen los valores permitidos.
• El modelo define mecanismos de claves para identificar registros únicos y mantener la integridad referencial entre relaciones.
• Dispone de lenguajes formales de consulta como el álgebra relacional y el cálculo relacional de tuplas y dominios.

📚 Desarrollo

Fundamentos matemáticos. El modelo lógico relacional fue introducido por Edgar F. Codd y se fundamenta en la teoría de conjuntos y la lógica de predicados. Su idea esencial consiste en representar la información mediante relaciones, que en la práctica de los sistemas gestores se materializan como tablas compuestas por filas y columnas. Cada fila representa una tupla u ocurrencia concreta, mientras que cada columna representa un atributo con nombre, significado específico y dominio asociado.

Independencia de niveles. Una de las fortalezas fundamentales del modelo es la separación entre la representación lógica de los datos y su almacenamiento físico. El usuario interactúa con relaciones, atributos, claves y restricciones de manera independiente, mientras que el sistema gestor decide internamente cómo almacenar páginas, índices, buffers y planes de ejecución. Esta independencia lógico-física permite modificar la estructura física sin afectar a las aplicaciones.

Estructura de datos. Una relación constituye un conjunto de tuplas con idéntica estructura, donde cada tupla contiene un valor para cada atributo de la relación. Un dominio define el conjunto de valores admisibles para un atributo, pudiendo tratarse de fechas, enteros, cadenas de texto o códigos específicos. El esquema describe la estructura de la base de datos, mientras que la instancia contiene los datos concretos existentes en un momento determinado.

Sistema de claves. El modelo establece diferentes tipos de claves para garantizar la identificación única de registros. Una superclave identifica tuplas de forma unívoca, mientras que una clave candidata es una superclave mínima que no contiene atributos redundantes. De entre las candidatas se elige una clave primaria, y las claves ajenas permiten establecer referencias entre relaciones manteniendo la integridad referencial del sistema.

Reglas de integridad. El modelo relacional se sustenta sobre tres pilares fundamentales de integridad. La integridad de entidad establece que ninguna tupla de una relación base puede contener valores nulos en la clave primaria. La integridad referencial garantiza que los valores de una clave ajena coincidan con valores existentes en la relación referenciada o sean nulos. La integridad de dominio asegura que los atributos tomen únicamente valores pertenecientes a su dominio definido.

Lenguajes formales. El modelo dispone de dos lenguajes formales complementarios. El álgebra relacional proporciona operaciones procedimentales como selección, proyección y join, sirviendo como representación intermedia para el optimizador del sistema gestor. El cálculo relacional constituye un aparato declarativo basado en lógica de primer orden, existiendo variantes de tuplas y de dominios según el tipo de variables que emplean.

Implementación práctica. SQL constituye la implementación práctica del modelo relacional, aunque incorpora extensiones como la gestión de duplicados y valores nulos. Las vistas representan relaciones derivadas del esquema que resultan útiles para controlar el acceso, garantizar la seguridad y mantener la estabilidad lógica frente a cambios en el esquema base, sin almacenar datos físicamente independientes.

🧩 Elementos esenciales

• Relación: Conjunto de tuplas con la misma estructura que se materializa como una tabla formada por filas y columnas.
• Tupla: Cada fila de una tabla que contiene un valor concreto para cada atributo de la relación.
• Atributo: Cada columna de una tabla que posee nombre, significado semántico y dominio de valores asociado.
• Dominio: Conjunto de valores admisibles para un atributo específico, como enteros, fechas o cadenas alfabéticas.
• Esquema: Descripción de la estructura de la base de datos independiente de los datos concretos almacenados.
• Instancia: Conjunto de datos concretos existentes en la base de datos en un momento determinado.
• Clave candidata: Superclave mínima que identifica unívocamente cada tupla sin atributos redundantes.
• Clave primaria: Clave candidata elegida para identificar oficialmente las tuplas de una relación.
• Clave ajena: Atributo o conjunto de atributos que referencia la clave primaria de otra relación para mantener integridad referencial.
• Álgebra relacional: Conjunto de operaciones formales como selección, proyección y join para manipular relaciones.
• Cálculo relacional: Lenguaje declarativo basado en lógica de primer orden con cuantificadores existenciales y universales.
• Vista: Relación derivada del esquema que no almacena datos físicamente y facilita el acceso y la seguridad.

🧠 Recuerda

• Codd fundamentó el modelo en teoría de conjuntos y lógica de predicados.
• Una tabla representa una relación, las filas son tuplas y las columnas son atributos.
• El dominio restringe los valores permitidos para cada atributo.
• La independencia lógico-física separa la estructura visible del almacenamiento interno.
• La clave primaria identifica únicamente cada fila y no admite nulos.
• La clave ajena mantiene la integridad referencial entre tablas relacionadas.
• La integridad de entidad, referencial y de dominio son los tres pilares fundamentales.
• El álgebra relacional opera mediante procedimientos concretos como selección y proyección.
• El cálculo relacional opera declarativamente con variables de tuplas o dominios.
• Las vistas proporcionan estabilidad lógica y control de acceso sin duplicar datos.

6. Normalización

6. Normalización

🎯 Idea clave

• La normalización es el proceso de descomposición de tablas para eliminar redundancias y anomalías de actualización, inserción y borrado.
• Fue propuesta inicialmente por Codd y posteriormente refinada por Raymond Boyce como base del diseño relacional.
• Se fundamenta en el análisis de dependencias entre datos y la aplicación progresiva de formas normales.
• Las formas normales principales son la 1FN, 2FN, 3FN y BCNF, existiendo además la 4FN, 5FN y 6FN para casos específicos.
• En la práctica, la mayoría de los diseños operativos alcanzan la 3FN o la BCNF, ya que formas superiores implican costes de join adicionales.
• La desnormalización constituye la introducción intencional y controlada de redundancia para mejorar el rendimiento de ciertas consultas.

📚 Desarrollo

Definición y origen histórico. La normalización es el proceso de descomposición de tablas diseñado específicamente para eliminar redundancias y anomalías de actualización, inserción y borrado. Fue propuesta inicialmente por Codd y posteriormente refinada por Raymond Boyce, estableciendo las bases teóricas sobre las que se asienta el diseño lógico de bases de datos relacionales.

Primera Forma Normal (1FN). Una tabla se encuentra en 1FN cuando todos sus atributos son atómicos, es decir, indivisibles dentro del modelo. No se admiten valores compuestos ni multivaluados, garantizando que cada columna contenga valores simples y evitando la existencia de grupos repetidos o listas dentro de una columna.

Segunda Forma Normal (2FN). Una relación se halla en 2FN si está en 1FN y todos los atributos no clave dependen funcionalmente de la totalidad de la clave primaria. Esta forma elimina las dependencias parciales, relevantes especialmente cuando la clave primaria es compuesta, evitando que atributos dependan únicamente de una parte de dicha clave.

Tercera Forma Normal (3FN). Una relación está en 3FN si está en 2FN y no existen dependencias transitivas entre atributos no clave. Esto significa que ningún atributo no clave debe depender de otro atributo no clave. La 3FN evita que una tabla almacene permanentemente datos de entidades diferentes por comodidad, ayudando a que cada relación represente un único tipo de hecho.

Forma Normal de Boyce-Codd (BCNF). Constituye una versión más estricta de la 3FN donde, para toda dependencia funcional no trivial, el determinante debe ser superclave. A diferencia de la 3FN, que admite excepciones cuando el atributo dependiente forma parte de una clave candidata, la BCNF no permite ninguna excepción. Es importante advertir que la BCNF no siempre admite una descomposición que preserve todas las dependencias funcionales.

Formas normales superiores y desnormalización. La 4FN aborda las dependencias multivaluadas independientes, que aparecen cuando una entidad tiene varios conjuntos de valores independientes. La 5FN trata las dependencias de proyección-unión o de join más complejas. La 6FN resulta especialmente relevante en bases de datos temporales. Frente a este proceso, la desnormalización introduce intencionalmente redundancia para mejorar el rendimiento de consultas, siendo una decisión consciente que asume un coste de mantenimiento a cambio de un beneficio de lectura.

🧩 Elementos esenciales

• Normalización: Proceso iterativo de descomposición de relaciones orientado a reducir la redundancia y eliminar anomalías de inserción, actualización y borrado.
• Dependencia funcional: Relación X → Y donde, conocido el valor de X, el valor de Y queda unívocamente determinado.
• 1FN: Exige que todos los atributos sean atómicos, sin valores compuestos ni multivaluados ni grupos repetidos.
• 2FN: Elimina las dependencias parciales respecto a claves primarias compuestas.
• 3FN: Elimina las dependencias transitivas entre atributos no clave.
• BCNF: Refuerza la 3FN exigiendo que todo determinante de una dependencia funcional no trivial sea superclave.
• 4FN: Trata las dependencias multivaluadas independientes entre atributos.
• 5FN: Resuelve las dependencias de proyección-junta o de join más complejas.
• 6FN: Forma normal especialmente relevante para el tratamiento de bases de datos temporales.
• Descomposición sin pérdida: Propiedad que garantiza que la información original puede recuperarse mediante operaciones de reunión natural.
• Preservación de dependencias: Capacidad de mantener las dependencias funcionales originales tras el proceso de descomposición.
• Desnormalización: Introducción intencional y controlada de redundancia para mejorar el rendimiento de consultas en entornos analíticos.

🧠 Recuerda

• La normalización se fundamenta en el análisis de dependencias funcionales, claves candidatas y atributos primos.
• Una tabla en 3FN debe contener datos de un único tipo de entidad y referencias a otras, no copias permanentes de datos ajenos.
• La BCNF no siempre admite una descomposición que preserve todas las dependencias funcionales, por lo que se convierte en un objetivo deseable pero no obligatorio.
• En la práctica operativa, la mayoría de diseños se sitúan en 3FN o BCNF, ya que subir más allá raramente compensa el coste de los joins adicionales.
• La desnormalización no es un error de diseño siempre que esté justificada, documentada y controlada.
• La identificación rigurosa de dependencias permite detectar redundancias y oportunidades de descomposición de relaciones.
• Una descomposición debe procurar ser sin pérdida de información y, en lo posible, preservadora de dependencias.