Tema 1: Modelado y diseño de bases de datos. Normalización

El modelo Entidad/Relación

El modelo Entidad/Relación (E/R), propuesto por Peter Chen (1976) y recogido por Métrica v3 como técnica de modelado de datos, es un mecanismo de abstracción que representa gráficamente el mundo real para su tratamiento informático. Un modelo de datos tiene como propósito principal servir de nexo de unión entre el mundo del usuario y el mundo del ordenador, permitiendo describir la información de forma comprensible antes de descender a la implementación.

El modelo E/R se materializa en el esquema conceptual, que es un esquema de la información usada en la empresa, independiente de consideraciones físicas. Los modelos conceptuales de datos representan la visión lógica de la información que maneja el Sistema de Información, e incluyen las entidades importantes y las relaciones de más alto nivel entre ellas. Es FALSO afirmar que representan la estructura física de la información: precisamente no especifican las características físicas de las entidades, y una de las ventajas del modelo de datos es la obtención de estructuras independientes (no dependientes) del entorno físico.

Entidades, atributos y dominios

Una entidad es, según Métrica v3, aquel objeto, real o abstracto, acerca del cual se desea almacenar información en la base de datos; dicho de otro modo, son partes del mundo distinguibles del resto. Por abstracción, un objeto como un bote de bebida se representa mediante un rectángulo, y datos como su marca o caducidad se modelan como atributos.

Un atributo es una propiedad o característica de una entidad. Se representa por medio de una elipse (o círculo) etiquetada con su nombre, conectada mediante una línea al tipo de entidad o relación. Tipos relevantes:

• Identificador (clave): distingue unívocamente cada ocurrencia.

• Descriptor: atributo que caracteriza una ocurrencia pero no la distingue del resto.

• Simple: tiene un único componente, no puede dividirse en subatributos; se representa con una elipse.

• Compuesto: puede dividirse en partes más pequeñas; también se representa con una elipse.

• Derivado: se representa con una elipse discontinua.

El dominio de un atributo es el conjunto de todos los valores posibles que puede tomar dicho atributo.

Para identificar atributos adecuados durante el diseño conceptual, la técnica recomendada consiste en hacerse preguntas sobre qué atributo se necesita para visualizar una información específica.

Relaciones

Una relación es la asociación entre dos o más entidades. Gráficamente, dos entidades que deben relacionarse se unen mediante un rombo. Las relaciones también pueden tener atributos (atributos en relaciones), que se representan igual que los atributos de las entidades. Las relaciones de tipo histórico son aquellas en las que debe constar una fecha o una hora.

Conceptos cuantitativos de una relación:

• Grado: el número de tipos de entidad que participan en un tipo de relación (número del conjunto de entidades que intervienen en la asociación).

• Cardinalidad: el número de instancias (ocurrencias) de una entidad que pueden asociarse con una instancia de otra a través de una relación binaria. En Métrica v3 la cardinalidad expresa la participación en la relación de cada una de las entidades afectadas (número máximo y mínimo de ocurrencias). Se representa con un símbolo cerca de la línea que conecta la entidad con la relación.

• Tipo de correspondencia: el número máximo de ocurrencias de cada tipo de entidad que pueden intervenir en una ocurrencia de la relación que se trata. Las relaciones en Métrica v3 se definen por cardinalidad, nombre y tipo de correspondencia.

Correspondencias típicas: 1:1, 1:N (una instancia se relaciona con varias, pero cada una de esas solo con una de la primera; p. ej. una factura se emite a una sola persona, pero una persona tiene varias facturas → uno a muchos) y N:M (p. ej. la relación entre pedido y artículo).

Entidades débiles y dependencias

Una entidad débil es aquella que carece de identificador o clave propia y que no puede existir sin participar en la relación con una entidad regular (fuerte); su identificación se logra por medio de una relación. En los diagramas EER se representa con un rectángulo de doble línea. Se distinguen dos tipos de dependencia:

• Dependencia en existencia: las ocurrencias de la entidad débil no pueden existir sin la ocurrencia de la entidad regular, pero sí pueden identificarse mediante un atributo identificador propio.

• Dependencia en identificación: además de la dependencia en existencia, las ocurrencias no se pueden identificar solo mediante sus propios atributos, por lo que hay que añadir el identificador (clave) de la ocurrencia de la entidad regular o fuerte de la que dependen.

Modelo Entidad/Relación Extendido (EER)

Los diagramas E/R extendidos (EER) son diagramas que incorporan algunos elementos más al lenguaje. Sus mecanismos específicos, según Métrica v3, son:

• Generalización: abstrae un supertipo a partir de las propiedades comunes de varios subtipos.

• Especialización: operación inversa; un supertipo se descompone en uno o varios subtipos que heredan todos los atributos y relaciones del supertipo, además de tener los propios. Se basa en las diferencias (frente a la generalización, basada en lo común).

• Agregación: trata una relación existente como una entidad de nivel superior para establecer nuevas relaciones; se representa englobando la relación abstraída y sus entidades en un rectángulo. Sirve para expresar relaciones entre relaciones o entre entidades y relaciones.

• Asociación: mecanismo que relaciona dos tipos de entidades de dominios normalmente independientes que coyunturalmente se asocian. La asociación no es un tipo de generalización.

Elementos como una jerarquía (EMPRESA → DEPARTAMENTOS → SUBDEPARTAMENTOS) o las restricciones de participación forman parte del EER. Cuando la participación es obligatoria, la restricción es total. Las relaciones exclusivas se representan incluyendo un arco sobre las líneas que conectan la entidad con los dos o más tipos de relación; la restricción de exclusividad implica que dos o más interrelaciones son excluyentes respecto de la entidad que participa en ambas. Nótese que las transacciones NO son un elemento del EER.

Metodología de diseño conceptual

El orden de trabajo es: 1) identificar entidades, 2) identificar relaciones, 3) identificar atributos y 4) determinar los dominios de los atributos. Las vistas reflejan las diferentes perspectivas de la información de varios usuarios o departamentos. Aspecto esencial: la prueba y validación del esquema con los requisitos de los usuarios; el paso final es revisar el esquema conceptual local con el usuario.

Diagramas de Flujo de Datos (DFD)

Complementariamente, los DFD de Métrica v3 se basan en la descomposición o explosión por niveles; los almacenes SÍ pueden repetirse en los diagramas. El flujo de datos se representa con una flecha que indica la dirección de los datos, etiquetada con un nombre; el flujo de control usa una flecha de trazo discontinuo. Un proceso de control representa procesos que coordinan y sincronizan las actividades de otros procesos. Regla clave: no se pueden unir de forma directa dos almacenes de datos (siempre media un proceso).

Fuentes

• Ministerio de Hacienda y Función Pública (España). Metodología Métrica v3, Técnica Modelo Entidad/Relación Extendido: https://administracionelectronica.gob.es/pae_Home/pae_Documentacion/pae_Metodolog/pae_Metrica_v3.html

• Métrica v3 — Técnica Modelo Entidad/Relación Extendido (reproducción documental): https://manuel.cillero.es/doc/metodologia/metrica-3/tecnicas/modelo-entidad-relacion-extendido/

• Métrica v3 — Técnica Diagrama de Flujo de Datos (DFD) y consistencia: https://manuel.cillero.es/doc/metodologia/metrica-3/tecnicas/diagrama-de-flujo-de-datos/

• Notación de DFD, MÉTRICA 3 (Universidad de Castilla-La Mancha, ALARCOS): https://alarcos.esi.uclm.es/ipsw/metrica3/metrica_3/guidances/whitepapers/notacion_dfd_4D9FAE5F.html

Diseño lógico relacional

El modelo relacional fue formulado por Edgar Frank Codd (IBM, 1970) en su artículo "A Relational Model of Data for Large Shared Data Banks". Es el fundamento teórico de las bases de datos relacionales y de su lenguaje asociado (el álgebra relacional y, después, SQL).

Niveles de abstracción

El estándar ANSI/SPARC define tres niveles de abstracción de una base de datos:

• Externo (de vistas): cómo ven los datos los distintos usuarios/aplicaciones.

• Conceptual (lógico): qué datos se almacenan y qué relaciones existen entre ellos, con independencia del soporte físico.

• Interno (físico): cómo se almacenan realmente los datos (ficheros, índices, bloques).

El nivel "sintáctico" NO existe como nivel de abstracción de bases de datos: es un distractor típico.

Fases del diseño: conceptual, lógico y físico

El diseño de una base de datos se aborda en tres etapas encadenadas:

1. Diseño conceptual: produce un esquema conceptual independiente del SGBD (habitualmente un modelo Entidad/Relación con entidades, atributos y relaciones).

2. Diseño lógico: su objetivo principal es transformar el esquema conceptual en un esquema lógico compatible con el modelo de datos del SGBD elegido (aquí, el relacional). El esquema lógico actúa como puente entre el esquema conceptual y el diseño físico, adaptando las estructuras de datos al modelo escogido.

3. Diseño físico: materializa el esquema lógico en estructuras concretas de almacenamiento y acceso.

El diseño conceptual y lógico tiene carácter iterativo: ambos procesos requieren refinamiento continuo, lo que contribuye a una comprensión más profunda del funcionamiento de la organización y de sus datos.

La relación: tuplas, grado y cardinalidad

En el modelo de Codd, una relación (tabla) es un conjunto de n-tuplas, donde cada n-tupla es una lista ordenada de valores atómicos. Una relación es, por tanto, un conjunto de tuplas. Dos medidas la describen:

• Grado: número de atributos (columnas).

• Cardinalidad: número de tuplas (filas).

Así, una entidad con 4 columnas y 7 filas tiene grado 4 y cardinalidad 7.

Claves: superclave, candidata, primaria y ajena

• Superclave: subconjunto de atributos del esquema R(A1,…,An) tal que no puede haber dos tuplas con la misma combinación de valores para dicho subconjunto (identifica unívocamente).

• Clave candidata: superclave mínima (sin atributos redundantes). Toda relación tiene al menos una clave candidata (en el peor caso, el conjunto de todos sus atributos); por tanto es FALSO afirmar que "una relación puede no tener clave candidata".

• Clave primaria: clave candidata elegida como identificador principal; conjunto de atributos que hacen único el acceso a cada ocurrencia de la entidad. Tanto la clave primaria como una clave candidata encajan con la definición de "atributos que identifican de forma única las filas".

• Clave ajena o foránea (foreign key): atributo(s) que referencian la clave primaria de otra relación. Las claves ajenas SÍ pueden ser nulas (salvo restricción explícita); afirmar que "nunca pueden ser nulas" es incorrecto.

Reglas de integridad

El modelo relacional impone dos reglas de integridad básicas:

• Integridad de entidad(es): ningún atributo que compone la clave primaria puede ser nulo, de modo que cada entidad sea única e identificable.

• Integridad referencial: el valor de una clave ajena, si no es nulo, debe coincidir con un valor existente de la clave primaria a la que referencia (o bien ser nulo). Garantiza que las relaciones entre tablas permanezcan sincronizadas durante inserciones, actualizaciones y borrados, evitando "filas hijas huérfanas". Si una clave externa apunta a una fila inexistente, se viola la integridad referencial; borrar una fila padre con hijos es un riesgo típico de violación.

Otras restricciones habituales: datos requeridos (campos NOT NULL que no pueden quedar vacíos) y restricciones de dominio.

Propiedades ACID de las transacciones

Las transacciones de un SGBD deben cumplir las propiedades ACID: Atomicidad, Consistencia, Aislamiento (Isolation) y Durabilidad/Persistencia.

Las 12 reglas de Codd

Codd definió 12 reglas (más la regla 0) para calificar un sistema como relacional. Entre las más preguntadas:

• Regla 2 — Acceso garantizado: todo dato es accesible mediante la combinación de nombre de tabla, valor de clave primaria y nombre de columna (implica clave primaria única en cada relación).

• Regla 5 — Sublenguaje de datos completo: el sistema debe soportar al menos un lenguaje de manipulación de datos con sintaxis bien definida (definición de datos, vistas, manipulación, integridad, autorizaciones y transacciones).

• Regla 7 — Inserción, actualización y borrado de alto nivel: el sistema debe permitir operar sobre conjuntos de tuplas (no fila a fila) tanto en consulta como en inserción/actualización/borrado.

• Regla 11 — Independencia de la distribución: que la base de datos se almacene de forma distribuida NO debe afectar a las aplicaciones. Por eso una "dependencia de la distribución" NO es una de las 12 reglas (es la inversión del enunciado real).

Reglas de transformación (paso al modelo lógico/físico)

Al pasar del modelo conceptual al lógico relacional se aplican reglas de transformación:

• Transformación de entidades en tablas y de atributos en columnas.

• Transformación de relaciones N:M: se crea una tabla intermedia (de intersección o de enlace) cuyas claves foráneas son las claves primarias de las entidades participantes.

• Transformación de relaciones de grado n (n-arias): dividir las relaciones de grado n en relaciones binarias.

• Transformación de entidades débiles.

• Transformación de atributos compuestos (un atributo que contiene otros).

• Transformación de atributos multivalorados: se llevan a una tabla separada.

La "transformación de funciones" NO es una regla de transformación (distractor).

Álgebra relacional

Las operaciones fundamentales (primitivas) del álgebra relacional son: selección (σ), proyección (π), unión (∪), diferencia de conjuntos (−) y producto cartesiano (×) —a veces se añade el renombrado—. Son fundamentales porque ninguna puede eliminarse sin perder poder expresivo. La intersección NO es fundamental: es una operación derivada (se obtiene a partir de la diferencia).

Modelo dimensional (Kimball)

En el modelo dimensional de Kimball (data warehousing), una dimensión outrigger es una tabla de dimensión enlazada desde otra tabla de dimensión (una dimensión que cuelga de otra), utilizada de forma limitada para normalizar atributos correlacionados.

Fuentes

• Codd, E. F. — A Relational Model of Data for Large Shared Data Banks, ACM: https://dl.acm.org/doi/10.1145/362384.362685

• Codd's 12 rules — Wikipedia: https://en.wikipedia.org/wiki/Codd%27s_12_rules

• Codd's 12 Rules (Rule 2, 5, 7) — OLAP.com: https://olap.com/learn-bi-olap/codds-paper/

• Relational algebra (operadores primitivos) — Wikipedia: https://en.wikipedia.org/wiki/Relational_algebra

• Kimball Group — Outrigger Dimension (Data Warehouse glossary): https://www.kimballgroup.com/data-warehouse-business-intelligence-resources/kimball-techniques/dimensional-modeling-techniques/

• ANSI/SPARC three-schema architecture — ISO/IEC: https://en.wikipedia.org/wiki/Three-schema_approach

Normalización de bases de datos

La normalización es el proceso, dentro del diseño lógico del modelo relacional, que consiste en organizar los datos en tablas (relaciones) para eliminar la redundancia y las dependencias no deseadas, evitando la duplicidad de datos y garantizando la integridad. Su objetivo principal es eliminar redundancias y garantizar la integridad de los datos; dicho de otro modo, el principal problema que busca resolver es la redundancia de datos. Como técnica del diseño lógico relacional, asegura que las relaciones (tablas) del modelo no contengan datos redundantes y organiza los datos en grupos lógicos, cada uno describiendo una pequeña parte del todo.

La normalización debe abordarse en el momento adecuado: antes de crear las tablas, tras haber realizado un análisis de requisitos. Es una técnica propia del diseño lógico previa a la implementación física.

Por qué normalizar: anomalías y consecuencias

Una base de datos mal normalizada sufre anomalías. Las tres anomalías clásicas son de inserción, actualización y borrado (la denominada anomalía de actualización es una de las más citadas). No existe la anomalía de consulta: consultar no modifica datos, por lo que la «anomalía de consulta» NO es un tipo de anomalía de una base de datos sin normalizar.

Las consecuencias principales de que una base de datos NO esté normalizada adecuadamente son errores de inconsistencias, incoherencias, actualización y redundancia de datos, además de inexactitud de los sistemas de bases de datos (todas las anteriores). En cambio, garantizar la disponibilidad de la base de datos NO es una consecuencia de la falta de normalización. Normalizar correctamente evita errores de inconsistencias, incoherencias, actualización y redundancia, y por ello mejora la eficiencia y la integridad, algo especialmente relevante en el procesamiento transaccional en línea (OLTP).

Importante: entre los objetivos de la normalización NO figura mejorar el rendimiento; de hecho descomponer en más tablas puede exigir más reuniones. Tampoco es cierto que la normalización minimice las relaciones entre tablas (esa afirmación es INCORRECTA): la normalización descompone en más relaciones bien formadas.

Dependencia funcional

La dependencia funcional es la relación en la que el valor de una columna (o conjunto de columnas) determina de manera única el valor de otra columna dentro de la misma tabla. Según Métrica v3: «un atributo Y se dice que depende funcionalmente de otro X si, y sólo si, a cada valor de X le corresponde un único valor de Y» (se escribe X → Y; X es el determinante o implicante). Un atributo Y tiene dependencia funcional completa respecto de X si depende de él en su totalidad y no de una parte de X.

Las formas normales

Las formas normales más comunes son la primera, segunda y tercera (1FN, 2FN y 3FN). En la práctica, la 3FN es la que ofrece el mejor equilibrio entre eliminación de redundancia y eficiencia, y es la generalmente recomendada en el diseño relacional.

Primera Forma Normal (1FN)

Una relación está en 1FN si no tiene grupos repetitivos: cada atributo toma un único valor de un dominio simple. Aplicar la 1FN supone la eliminación de atributos multivaluados (y de grupos repetitivos).

Segunda Forma Normal (2FN)

La 2FN elimina las dependencias parciales. Según Métrica v3: «una entidad está en 2FN si está en 1FN y todos los atributos que no forman parte de las claves candidatas tienen dependencia funcional completa respecto de éstas». Es decir, se alcanza la 2FN cuando todos los atributos dependen funcionalmente de la totalidad de las claves candidatas (no de una parte).

Tercera Forma Normal (3FN)

La 3FN elimina las dependencias transitivas. Una relación está en 3FN si está en 2FN y ningún atributo no primario depende transitivamente de otros atributos no clave; equivalentemente, todos los atributos no principales dependen directamente de la clave y no existen dependencias funcionales transitivas. Ante FDs como F = {AB→C, BC→AD, CD→E} sobre R(A,B,C,D,E), la descomposición en 3FN preserva las dependencias generando una relación por cada dependencia: R1(A,B,C), R2(B,C,A,D) y R3(C,D,E).

Forma Normal de Boyce-Codd (FNBC)

Una tabla está en FNBC si está en 3FN y cada dependencia funcional no trivial tiene una clave candidata como determinante. Es una versión más estricta de la 3FN.

Cuarta Forma Normal (4FN) y dependencia multivaluada

La 4FN se apoya en la dependencia multivaluada: existe cuando hay una restricción entre dos conjuntos de atributos de una relación que exige que ciertas tuplas estén presentes en ella (un valor de X determina un conjunto de valores de Y con independencia del resto de atributos). Una relación en 4FN está en FNBC y no contiene dependencias multivaluadas no triviales.

Quinta Forma Normal (5FN) y dependencia de reunión

Cuando una relación puede reconstruirse sin pérdida de información a partir de la combinación de algunas de sus proyecciones, se dice que tiene una dependencia de reunión (join). Una tabla está en 5FN si, y sólo si, está en 4FN y no existen dependencias de reunión (join) no triviales que no se generen desde las claves (candidatas).

Desnormalización

La desnormalización es el proceso inverso: introduce redundancia de forma controlada. Mientras la normalización elimina redundancias, la desnormalización las introduce para mejorar el rendimiento en ciertas situaciones (por ejemplo, reducir reuniones en entornos de consulta intensiva).

Fuentes

• Ministerio de Hacienda / MAP — Métrica Versión 3, técnica de Normalización (definiciones oficiales de dependencia funcional, dependencia funcional completa, 1FN, 2FN y 3FN). Alojamiento académico del texto oficial: https://alarcos.esi.uclm.es/ipsw/metrica3/metrica_3/guidances/guidelines/normalizacion_AF788CBF.html

• Métrica v3 — Técnica de Normalización (referencia consolidada): https://manuel.cillero.es/doc/metodologia/metrica-3/tecnicas/normalizacion/

• Portal de Administración Electrónica (PAe), Gobierno de España — Metodología Métrica v3: https://administracionelectronica.gob.es/pae_Home/pae_Documentacion/pae_Metodolog/pae_Metrica_v3.html

Diseño físico de bases de datos

El diseño físico es la última de las tres grandes fases del diseño de una base de datos (conceptual → lógico → físico). Su propósito principal es implementar el esquema lógico en la memoria secundaria, definiendo las estructuras de almacenamiento y los métodos de acceso que permitirán al Sistema Gestor de Bases de Datos (SGBD) almacenar y recuperar los datos de forma eficiente. Mientras el modelo lógico describe qué datos se guardan y sus relaciones, el modelo físico describe cómo se guardan realmente sobre el hardware y el software concretos.

Modelo lógico frente a modelo físico

La diferencia esencial es la dependencia tecnológica: el modelo lógico es independiente de la tecnología, mientras que el modelo físico depende de la tecnología (del SGBD elegido, del sistema operativo, del almacenamiento). Por eso, antes de comenzar la etapa de diseño físico debe estar decidido el SGBD que se utilizará (Oracle, PostgreSQL, SQL Server, etc.), ya que sus tipos de datos, mecanismos de indexación, particionamiento y opciones de almacenamiento condicionan todas las decisiones posteriores.

El objetivo de obtener el modelo físico a partir del modelo lógico es definir la estructura de la base de datos a nivel de tablas y relaciones, traduciendo cada relación normalizada a las estructuras concretas del gestor.

Arquitectura ANSI/SPARC y niveles de abstracción

La arquitectura de referencia ANSI/SPARC define tres niveles de abstracción de una base de datos:

• Nivel externo (o de vistas): las distintas visiones parciales de los usuarios.

• Nivel conceptual: la descripción global de entidades, atributos, relaciones y restricciones.

• Nivel interno (o físico): cómo se almacenan realmente los datos (estructuras de ficheros, índices, páginas). El nivel interno es, por tanto, uno de los niveles de abstracción válidos.

De esta separación surge la independencia de datos:

• Independencia física: capacidad de modificar el esquema físico sin realizar cambios en el esquema conceptual (ni en los programas de aplicación). Los cambios en las estructuras de almacenamiento —reorganizar ficheros, añadir o quitar índices, reubicar tablas— no tienen efecto sobre el esquema lógico/conceptual, porque ambos niveles son independientes.

• Independencia lógica: capacidad de cambiar el esquema conceptual sin afectar a las vistas externas.

Componentes clave del diseño físico

En el diseño físico de una base de datos relacional se deben diseñar los componentes fundamentales:

1. El conjunto de relaciones (tablas) derivadas del modelo lógico.

2. Las estructuras de almacenamiento y los métodos de acceso (organización de ficheros, índices, clústeres).

3. El modelo de seguridad del sistema (usuarios, roles, privilegios).

Tareas en la obtención del modelo físico

Siguiendo metodologías como Métrica v3 (actividad DSI 6, Diseño Físico de Datos), las tareas típicas incluyen: transformar las relaciones lógicas en tablas físicas, seleccionar tipos de datos, definir claves e índices, analizar los caminos de acceso de cada módulo, aplicar desnormalización controlada cuando el rendimiento lo exige, y decidir el particionamiento. Crear diagramas de flujo de datos (DFD) NO es una tarea del modelo físico: el DFD pertenece a las fases de análisis/diseño de procesos, no al diseño físico de datos.

Entre las técnicas de optimización destacan:

• Índices: el uso de índices es la característica del modelo físico que permite optimizar el rendimiento de las consultas al acelerar la localización de las filas.

• Partición horizontal: consiste en dividir una tabla en varias tablas (o fragmentos) más pequeñas según ciertos criterios (por ejemplo, por rango de fechas o por región), repartiendo las filas. La partición vertical, en cambio, divide por columnas.

• Atributos derivados: un atributo derivado (calculable a partir de otros) puede almacenarse materializado o calcularse en tiempo real. Al pasar del modelo lógico al físico, el enfoque de calcular el valor en tiempo real evita redundancia y problemas de consistencia, a costa de recomputarlo en cada acceso.

Restricciones en el modelo físico

En la definición del modelo físico se implementan restricciones como las de clave primaria, clave ajena (integridad referencial), unicidad, not null y las restricciones de verificación (CHECK). Las restricciones de cardinalidad NO son un tipo de restricción propio del modelo físico: la cardinalidad es un concepto del modelado conceptual/lógico (entidad-relación) que expresa cuántas ocurrencias participan en una interrelación.

Transacciones y propiedades ACID

Una transacción es una unidad lógica de trabajo que el SGBD ejecuta como un todo indivisible. Toda transacción debe cumplir las propiedades ACID:

Así, las propiedades de las transacciones son atomicidad, consistencia, aislamiento y persistencia (durabilidad). La encapsulación NO es una propiedad de las transacciones: es un concepto de la programación orientada a objetos, ajeno al modelo ACID.

Resumen operativo

En síntesis, el diseño físico materializa el esquema lógico sobre un SGBD concreto —decidido de antemano—, produciendo tablas, estructuras de almacenamiento, índices, métodos de acceso y seguridad. Gracias a la independencia física, sus ajustes no alteran el nivel conceptual; y sobre este soporte las transacciones garantizan la integridad mediante las propiedades ACID.

Fuentes

• Ministerio de Hacienda y Función Pública (España). Metodología Métrica versión 3 — Diseño del Sistema de Información (DSI), Actividad DSI 6: Diseño Físico de Datos. https://administracionelectronica.gob.es/pae_Home/pae_Documentacion/pae_Metodolog/pae_Metrica_v3.html

• Métrica v3, Tarea DSI 6.1 «Diseño del Modelo Físico de Datos» (mirror docente). https://alarcos.esi.uclm.es/ipsw/metrica3/metrica_3/tasks/DSI_06_1_41DFD8E6.html

• ANSI/X3/SPARC Study Group on Data Base Management Systems — arquitectura de tres niveles (externo, conceptual, interno) e independencia de datos. https://en.wikipedia.org/wiki/ANSI-SPARC_Architecture

• ISO/IEC 9075 (SQL), propiedades ACID de las transacciones — ISO. https://www.iso.org/standard/76583.html