Dependencia funcional

Supongamos que se diseña un sistema para rastrear vehículos y la cilindrada de sus motores. Cada vehículo tiene un número de identificación vehicular (VIN) único. Se escribiría VIN → Capacidad del motor porque sería inapropiado que el motor de un vehículo tuviera más de una cilindrada. (Suponiendo, en este caso, que los vehículos solo tienen un motor). Por otro lado, Capacidad del motor → VIN es incorrecto porque podría haber muchos vehículos con la misma cilindrada.

Esta dependencia funcional podría sugerir que el atributo EngineCapacity se relacione con la clave candidata VIN. Sin embargo, esto no siempre es apropiado. Por ejemplo, si dicha dependencia funcional surge como resultado de las dependencias transitivas VIN → VehicleModel y VehicleModel → EngineCapacity, entonces no se obtendría una relación normalizada.

Este ejemplo ilustra el concepto de dependencia funcional. La situación modelada es la de estudiantes universitarios que asisten a una o más clases, en cada una de las cuales se les asigna un ayudante de cátedra. Supongamos además que cada estudiante está en un semestre determinado y se identifica mediante un número entero único.

Observamos que siempre que dos filas de esta tabla tengan el mismo StudentID, también tendrán necesariamente los mismos valores de Semestre. Este hecho básico se puede expresar mediante una dependencia funcional:

• Número de identificación del estudiante → Semestre.

Si se añadiera una fila donde el estudiante tuviera un semestre diferente, la dependencia funcional (DF) dejaría de existir. Esto significa que la DF se deduce de los datos, ya que es posible que existan valores que la invaliden.

Se pueden identificar otras dependencias funcionales no triviales, por ejemplo:

• {StudentID, Lecture} → TA
• {ID de estudiante, conferencia} → {TA, semestre}

Esto último expresa el hecho de que el conjunto {StudentID, Lecture} es una superclave de la relación.

Un ejemplo clásico de dependencia funcional es el modelo de departamento de empleados.

Este caso representa un ejemplo donde múltiples dependencias funcionales están integradas en una única representación de datos. Cabe destacar que, dado que un empleado solo puede pertenecer a un departamento, su identificador único determina dicho departamento.

• ID de empleado → Nombre del empleado
• ID de empleado → ID de departamento

Además de esta relación, la tabla también tiene una dependencia funcional a través de un atributo no clave.

• ID del departamento → Nombre del departamento

Este ejemplo demuestra que, aunque exista una dependencia funcional ID de empleado → ID de departamento, el ID de empleado no sería una clave lógica para determinar el nombre del departamento. El proceso de normalización de los datos reconocería todas las dependencias funcionales y permitiría al diseñador construir tablas y relaciones más lógicas basadas en los datos.

El cierre de un conjunto de valores es el conjunto de atributos que pueden determinarse mediante sus dependencias funcionales para una relación dada. Para ello, se utilizan los axiomas de Armstrong : reflexividad, aumento y transitividad.

Dado${\displaystyle R}$y${\displaystyle F}$un conjunto de FD que contiene${\displaystyle R}$: El cierre de${\displaystyle F}$en${\displaystyle R}$(denotado${\displaystyle F}$⁺ ) es el conjunto de todos los FD que están lógicamente implicados por${\displaystyle F}$. ^{[ 8 ]}

Cierre de un conjunto de atributos X con respecto a${\displaystyle F}$es el conjunto X ⁺ de todos los atributos que están determinados funcionalmente por X usando${\displaystyle F}$⁺ .

Definición :${\displaystyle F}$cubiertas${\displaystyle G}$si cada FD en${\displaystyle G}$se puede inferir de${\displaystyle F}$.${\displaystyle F}$cubiertas${\displaystyle G}$si${\displaystyle G}$⁺ ⊆${\displaystyle F}$⁺ Cada conjunto de dependencias funcionales tiene una cobertura canónica .

Dos conjuntos de FD${\displaystyle F}$y${\displaystyle G}$esquema${\displaystyle R}$son equivalentes, escritos${\displaystyle F}$≡${\displaystyle G}$, si${\displaystyle F}$⁺ =${\displaystyle G}$⁺ . Si${\displaystyle F}$≡${\displaystyle G}$, entonces${\displaystyle F}$es una portada para${\displaystyle G}$y viceversa. En otras palabras, los conjuntos equivalentes de dependencias funcionales se denominan cubiertas entre sí.

Un conjunto${\displaystyle F}$de FD no es redundante si no hay un subconjunto apropiado ${\displaystyle F'}$de${\displaystyle F}$con${\displaystyle F'}$≡${\displaystyle F}$. Si tal es un${\displaystyle F'}$existe,${\displaystyle F}$es redundante.${\displaystyle F}$es una cobertura no redundante para${\displaystyle G}$si${\displaystyle F}$es una portada para${\displaystyle G}$y${\displaystyle F}$es no redundante. Una caracterización alternativa de la no redundancia es que${\displaystyle F}$es no redundante si no hay FD X → Y en${\displaystyle F}$de tal manera que${\displaystyle F}$- { X → Y }${\displaystyle \models }$X → Y . Llamar a una FD X → Y en${\displaystyle F}$redundante en${\displaystyle F}$si${\displaystyle F}$- { X → Y }${\displaystyle \models }$X → Y .

Una propiedad importante (que produce una aplicación inmediata) de las dependencias funcionales es que si R es una relación con columnas nombradas a partir de algún conjunto de atributos U y R satisface alguna dependencia funcional X → Y, entonces${\displaystyle R=\Pi _{XY}(R)\bowtie \Pi _{XZ}(R)}$donde Z = U − XY . Intuitivamente, si una dependencia funcional X → Y se cumple en R , entonces la relación se puede dividir de forma segura en dos relaciones junto a la columna X (que es una clave para${\displaystyle \Pi _{XY}(R)\pajarita \Pi _{XZ}(R)}$) asegurando que cuando las dos partes se vuelven a unir no se pierde ningún dato, es decir, una dependencia funcional proporciona una forma sencilla de construir una descomposición de unión sin pérdida de R en dos relaciones más pequeñas. Este hecho a veces se denomina teorema de Heath ; es uno de los primeros resultados en la teoría de bases de datos. ^{[ 9 ]}

El teorema de Heath dice efectivamente que podemos extraer los valores de Y de la gran relación R y almacenarlos en uno solo,${\displaystyle \Pi _{XY}(R)}$, que no tiene repeticiones de valores en la fila para X y es efectivamente una tabla de búsqueda para Y indexada por X y, en consecuencia, tiene solo un lugar para actualizar la Y correspondiente a cada X, a diferencia de la relación "grande" R donde potencialmente hay muchas copias de cada X , cada una con su copia de Y que deben mantenerse sincronizadas en las actualizaciones. (Esta eliminación de redundancia es una ventaja en contextos OLTP , donde se esperan muchos cambios, pero no tanto en contextos OLAP , que implican principalmente consultas). La descomposición de Heath deja solo a X para actuar como clave externa en el resto de la tabla grande.${\displaystyle \Pi _{XZ}(R)}$.

Sin embargo, las dependencias funcionales no deben confundirse con las dependencias de inclusión , que son el formalismo para las claves foráneas; aunque se utilizan para la normalización, las dependencias funcionales expresan restricciones sobre una relación (esquema), mientras que las dependencias de inclusión expresan restricciones entre esquemas de relación en un esquema de base de datos . Además, las dos nociones ni siquiera se cruzan en la clasificación de dependencias : las dependencias funcionales son dependencias que generan igualdad, mientras que las dependencias de inclusión son dependencias que generan tuplas . Imponer restricciones referenciales después de la descomposición del esquema de relación (normalización) requiere un nuevo formalismo, es decir, dependencias de inclusión. En la descomposición resultante del teorema de Heath, no hay nada que impida la inserción de tuplas en${\displaystyle \Pi _{XZ}(R)}$tener algún valor de X que no se encuentra en${\displaystyle \Pi _{XY}(R)}$.

Las formas normales son niveles de normalización de bases de datos que determinan la "calidad" de una tabla. Generalmente, la tercera forma normal se considera un buen estándar para una base de datos relacional.

La normalización tiene como objetivo eliminar las anomalías de actualización, inserción y eliminación de la base de datos. Asimismo, garantiza que cuando se introduce un nuevo valor en la relación, su impacto en la base de datos sea mínimo y, por consiguiente, también en las aplicaciones que la utilizan.