DBMS - Normalización

Dependencia funcional

La dependencia funcional (FD) es un conjunto de restricciones entre dos atributos en una relación. La dependencia funcional dice que si dos tuplas tienen los mismos valores para los atributos A1, A2, ..., An, entonces esas dos tuplas deben tener los mismos valores para los atributos B1, B2, ..., Bn.

La dependencia funcional está representada por un signo de flecha (→) es decir, X → Y, donde X determina funcionalmente Y. Los atributos del lado izquierdo determinan los valores de los atributos del lado derecho.

Axiomas de Armstrong

Si F es un conjunto de dependencias funcionales, entonces el cierre de F, denotado como F + , es el conjunto de todas las dependencias funcionales implícitas lógicamente en F. Los axiomas de Armstrong son un conjunto de reglas que, cuando se aplican repetidamente, generan un cierre de dependencias funcionales .

  • Reflexive rule - Si alfa es un conjunto de atributos y beta es_subconjunto_de alfa, entonces alfa tiene beta.

  • Augmentation rule- Si a → b se cumple e y es un conjunto de atributos, entonces ay → by también se cumple. Eso es agregar atributos en dependencias, no cambia las dependencias básicas.

  • Transitivity rule- Igual que la regla transitiva en álgebra, si a → b se cumple y b → c se cumple, entonces a → c también se cumple. a → b se llama funcionalmente a que determina b.

Dependencia funcional trivial

  • Trivial- Si se cumple una dependencia funcional (FD) X → Y, donde Y es un subconjunto de X, entonces se denomina FD trivial. Los FD triviales siempre se mantienen.

  • Non-trivial - Si se cumple un FD X → Y, donde Y no es un subconjunto de X, entonces se denomina FD no trivial.

  • Completely non-trivial - Si un FD X → Y se cumple, donde x se cruza con Y = Φ, se dice que es un FD completamente no trivial.

Normalización

Si el diseño de una base de datos no es perfecto, puede contener anomalías, que son como un mal sueño para cualquier administrador de bases de datos. Administrar una base de datos con anomalías es casi imposible.

  • Update anomalies- Si los elementos de datos están dispersos y no están vinculados entre sí de manera adecuada, podría dar lugar a situaciones extrañas. Por ejemplo, cuando intentamos actualizar un elemento de datos que tiene sus copias esparcidas en varios lugares, algunas instancias se actualizan correctamente mientras que otras se quedan con valores antiguos. Tales instancias dejan la base de datos en un estado inconsistente.

  • Deletion anomalies - Intentamos eliminar un registro, pero partes del mismo se dejaron sin eliminar por desconocimiento, los datos también se guardan en otro lugar.

  • Insert anomalies - Intentamos insertar datos en un registro que no existe en absoluto.

La normalización es un método para eliminar todas estas anomalías y llevar la base de datos a un estado coherente.

Primera forma normal

La primera forma normal se define en la propia definición de relaciones (tablas). Esta regla define que todos los atributos en una relación deben tener dominios atómicos. Los valores en un dominio atómico son unidades indivisibles.

Reorganizamos la relación (tabla) como se muestra a continuación, para convertirla a Primera forma normal.

Cada atributo debe contener solo un valor de su dominio predefinido.

Segunda forma normal

Antes de aprender sobre la segunda forma normal, debemos comprender lo siguiente:

  • Prime attribute - Un atributo, que es parte de la clave candidata, se conoce como atributo principal.

  • Non-prime attribute - Un atributo, que no es parte de la clave principal, se dice que es un atributo no principal.

Si seguimos la segunda forma normal, entonces cada atributo no principal debería ser funcionalmente dependiente del atributo de clave principal. Es decir, si X → A se cumple, entonces no debería haber ningún subconjunto apropiado Y de X, para el cual Y → A también es válido.

Vemos aquí en la relación Student_Project que los atributos de la clave principal son Stu_ID y Proj_ID. De acuerdo con la regla, los atributos no clave, es decir Stu_Name y Proj_Name, deben depender de ambos y no de ninguno de los atributos de clave principal individualmente. Pero encontramos que Stu_Name puede ser identificado por Stu_ID y Proj_Name puede ser identificado por Proj_ID de forma independiente. Se llamapartial dependency, que no está permitido en la Segunda Forma Normal.

Rompimos la relación en dos como se muestra en la imagen de arriba. Entonces no existe una dependencia parcial.

Tercera forma normal

Para que una relación esté en la tercera forma normal, debe estar en la segunda forma normal y lo siguiente debe satisfacer:

  • Ningún atributo no principal depende transitivamente del atributo de clave principal.
  • Para cualquier dependencia funcional no trivial, X → A, entonces -
      X es una superclave o,
    • A es el atributo principal.

Encontramos que en la relación Student_detail anterior, Stu_ID es la clave y el único atributo de clave principal. Encontramos que la ciudad se puede identificar por Stu_ID así como por Zip. Ni Zip es una superclave ni City es un atributo principal. Además, Stu_ID → Zip → Ciudad, por lo que existetransitive dependency.

Para llevar esta relación a la tercera forma normal, dividimos la relación en dos relaciones de la siguiente manera:

Forma normal de Boyce-Codd

La forma normal de Boyce-Codd (BCNF) es una extensión de la tercera forma normal en términos estrictos. BCNF afirma que:

  • Para cualquier dependencia funcional no trivial, X → A, X debe ser una superclave.

En la imagen de arriba, Stu_ID es la superclave en la relación Student_Detail y Zip es la superclave en la relación ZipCodes. Entonces,

Stu_ID → Stu_Name, Zip

y

Código postal → Ciudad

Lo que confirma que ambas relaciones están en BCNF.