Tuve la oportunidad de conocer y aprender del Ingeniero John Jairo Londoño Pérez mientras estaba en el primer semestre de mi especialización de Ingeniería de software. El una persona que realmente apasionada por las bases de datos. Escribió un libro que lleva por titulo el mismo nombre que este post, y quiero hablarles justamente de la metodología que el propone para el diseño y modelamiento de bases de datos relacionales.

Fundamentos

Esta metodología esta fuertemente influenciada por el trabajo de William Ward Armstrong, específicamente por su trabajo en axiomas de dependencia de Armstrong para bases de datos relacional, así que para entender en profundidad este modelo vamos a revisar antes las premisas marcadas por Armstrong y los trabajos de Normalización de bases de datos, no es necesario para entender el modelo, pero si para fundamentar los postulados que propone el mismo y darle sentido al nombre de seudomatemático. Pasare a mencionar las principales características y definiciones de los conceptos que mas adelante vea necesarios para explicar la metodología.

Axiomas de Armstrong

Podemos entender los axiomas de Armstrong como reglas de inferencia, es decir que con ellas intentamos establecer dependencias funcionales entre una base de datos relacional. Matemáticamente lo podemos interpretar como la relación existente entre conjuntos y en base de datos como la relación entre tablas.

En su trabajo(artículo) de 1974, donde definió los axiomas, los separo en reglas primarias y reglas secundarias, en donde las reglas secundarias son extensiones o casos que se pueden dar a partir de las reglas primarias.

Los principales axiomas son:

  1. Reflexividad: ∀ Y ⊆ X  ⇒  X → Y
    • Si X es un conjunto de atributos y Y es un subconjunto de X, entonces X contiene Y, lo que significa que X determina funcionalmente a Y.
  2. Aumentatividad: X → Y, X ⊆ Z  ⇒  Y → Z
    • Si X contiene Y y Z es un conjunto de atributos, entonces XZ contiene YZ. Significa que el atributo en las relaciones no modifica las relaciones básicas.
  3. Transitividad: X → Y, Y → Z  ⇒  X  → Z
    • Si X contiene Y y Y contiene Z, entonces X contiene Z.

Normalización de bases de datos

La normalización consiste en aplicar unas reglas a las relaciones, con el objetivo de evitar la redundancia, mantener la integridad de los datos y facilitar el mantenimiento y actualización de los datos, aunque veremos que lo podemos ampliar para la base de datos en general.

Para asegurarnos de que la normalización es la correcta se proponen tres reglas:

  1. Las tablas deben tener un nombre único.
  2. No pueden haber dos columnas iguales dentro de una misma tabla.
  3. Una columna debe contener el mismo tipo de datos.

Para cumplir con esto los desarrolladores de motores de bases de datos, científicos, matemáticos e ingenieros contribuyeron con nuevos conceptos.

Dependencias

Aqui interviene nuestro amigo Armstrong con sus axiomas, con los cuales se pueden determinar las dependencias funcionales, es decir las relaciones entre conjuntos(tablas) y subconjuntos; lo que permite señalar si alguna característica o elemento de un conjunto pertenece o se contiene en otro.

Claves

Las claves son necesarias para identificar un elemento dentro de un conjunto, es decir un campo dentro de una tabla. Con el objetivo de señalar una posible relación, ya este definida o no.

las claves con las que podemos trabajar son:

  • Primaria: Solemos asociarla a un identificador, y esta es la que caracteriza o representa un registro.
  • Ajena (Foránea): Indica dependencia a otra tabla, específicamente a su clave primaria.
  • Alternativa: Es una alternativa para una clave primaria, o compañera para una clave compuesta(Ver siguiente concepto), también es propensa a convertirse en un indice(depende del motor).
  • Compuesta: Es una clave que esta conformada por dos o mas columnas.

Formas normales

Las formas normales son una categorización o clasificación del estado en que se encuentran las tablas en una base de datos. Normalmente podemos decir que una base de datos esta normalizada cuando llega a la tercera forma normal, las cuales fueron propuestas por Edgar F. Codd, pero podemos encontrar dos formas normales adicionales.

  • 1FN: Las tablas deben contener una clave primaria única y requerida, sus columnas deben ser simples, es decir no contener mas de un dato; la tabla tiene un numero definido de columnas y estas no dependen de un orden especifico y si hay relaciones con otras tablas se debe poder identificar las columnas que contienen esta clave. Esto asegura que no hay redundancia de datos.
  • 2FN: Consiste en asegurarse de que todos las columnas de la tabla pueden ser identificados por la clave primaria de la misma y dependen de ella.
  • 3FN: Se debe identificar que no existe ninguna dependencia funcional transitiva entre columnas que no tengan clave.
  • 4FN: Llegamos a esta forma normal al incluir claves candidatas y compuestas (Solo si es necesario).
  • 5FN: Validamos y garantizamos la eficiencia y utilidad de las llaves compuestas.

Reglas de Codd

Son un conjunto de reglas que permiten a los motores de bases de datos normalizar, y de este modo crear correctamente bases de datos relacionales.

  1. Toda la información debe estar almacenada en tablas.
  2. La información debe ser accesible, para esto se tiene en cuenta los nombres de tabla, claves y columnas.
  3. Un valor desconocido, faltante o que no se puede usar se representa como nulo, o con un valor por defecto.
  4. La información que describe la base de datos(tablas, usuarios, permisos, etc) debe respetar las anteriores reglas.
  5. Definición de un lenguaje de consulta (Ahora el mas popular es SQL).
  6. Las vistas se deben poder actualizar automaticamente.
  7. Se debe poder leer, escribir, eliminar y agregar.
  8. Se debe poder separar las aplicaciones que consumen la información de la base de datos tanto física como lógicamente.
  9. Se debe garantizar la integridad de los datos.
  10. La información almacenada se debe poder distribuir.
  11. Debe se seguro.

La metodología

Por fin hemos llegado, puede que algunos conceptos que se mencionaron anteriormente no estén claros, pero en lo que queda de este post, mientras vamos desarrollando y explicando la metodología, veremos ejemplos y aplicaciones de estos conceptos, por lo que sera mucho mas fácil de entender, y es esto justamente lo que le da a esta metodología un gran atractivo, ya que permite entender y aplicar la normalización de una manera relativamente sencilla.

La creación de una base de datos comienza por el levantamiento de información, donde justamente comienza a proponer la metodología. No nos sugiere las técnicas de recolección de información, pero si deja en claro dos preguntas que se deben hacer.

  • ¿Para quién se quiere controlar?: Esta pregunta permite conocer lo que el autor denomina sujeto.
  • ¿Qué se va a controlar?: Permite identificar lo que denomina el grupo transaccional.

Al identificar esas dos entidades (sujeto y grupo transaccional) se conforma una nueva entidad a la que llama Cadena Lógica de Negocio del Sistema (CLNS), sobre esta entidad es que se desarrolla la normalización. Hay cuatro caminos que se pueden tomar para el desarrollo de la base de datos, esto en base a la relación entre el sujeto y el grupo transaccional. Para identificar la ruta que marca la metodología se propone identificar de nuevo con cuatro preguntas respectivamente para cada posible vía. Las veremos mas adelante al definir las dependencias funcionales.

Cadena lógica del negocio del sistema (CLNS)

CLNS permite dimensionar el producto, es decir pasar del contexto a un modelo abstracto que no varia, ya que se centra en una función especifica.

Sujeto

Es la identidad que se identifica como principal dentro de la CLNS.

Grupo transaccional

Conforman la segunda parte de la CLNS, siendo dependientes del sujeto. Es decir podemos tener un sujeto controlando varios grupos transaccionales.

Dependencia funcional

Como indica su nombre, el pilar de las bases de datos relacionales es precisamente establecer relaciones entre sus entidades(Tablas). Ya que previamente identificamos el Sujeto y el/los grupos transaccionales aplicamos las siguientes preguntas.

  • ¿Existe dependencia funcional exclusiva del grupo transaccional respecto al sujeto?
  • ¿Existe dependencia funcional no exclusiva del grupo transaccional respecto al sujeto?
  • ¿Qué variables dependen funcional y estrictamente de los dos componentes de la llave?
  • ¿Qué variables dependen funcional y estrictamente del segundo componente de la llave?

Dependencia funcional no exclusiva

Esta dependencia funcional se da cuando tenemos una relación directa, en donde el grupo transaccional depende del sujeto. Esto se transforma en una relación de uno a muchos.

Dependencia funcional exclusiva

Esta dependencia se da cuando el grupo transaccional depende del sujeto, pero el sujeto a su vez depende también del grupo transaccional. En este caso generamos una relación de varios a varios.

Usando la metodología

Para ejemplificar el uso tomare las entidades con las que suele trabajar el Ingeniero Londoño, tanto en su libro como en sus clases.

Clientes, Facturas, Productos. y pasaremos por cada una de las formas normales para ver como se desarrolla el diseño y se realiza la normalización.

Contextualizando

Contextualizar es el primer paso, y uno de los mas importantes, ya que asegura que el sujeto y grupo transaccional se determina bien.

Al realizar la pregunta de que se va a controlar, en este caso, Facturas, y para quien, en este caso los clientes, obtenemos el grupo transaccional y el sujeto.

Ahora es necesario revisar el contexto, por ejemplo, en este caso se nos pidió que también mostráramos los productos de la factura. Es decir necesitamos saber que productos compro un cliente. En un caso real esto lo determina el analista de negocio, quien debe poder entender y abstraer las funcionalidades que requiera el negocio. No se deben crear entidades innecesarias por suposición. Por lo que es muy importante limitar el alcance y ver las restricciones del negocio.

Para la explicación de este punto no sera necesario expandir mas el modelo, pero se debe saber que el modelo se puede y debe ampliar tanto como sea necesario. La metodología peca de no explicar como ampliar el modelo, pero se puede inferir en que hay dos maneras.

Podemos ampliar el modelo de manera natural, es decir identificar el sujeto y sus grupos transaccionales, luego esos grupos transaccionales pasaran a ser el sujeto e identificamos nuevos grupos transaccionales, por lo que nos queda una jerarquía descendente, imaginemos un mapa conceptual. Podemos realizar la misma labor iterando una y otra vez pero de manera ascendente, es decir identificar primero los grupos transaccionales y luego el sujeto; aunque esta manera puede provocar que pasemos por alto algún grupo transaccional, así que tendremos que llegar al sujeto y luego verificar sus grupos transaccionales.

Otra forma y que para mi es la mas sencilla de trabajar, pero también requiere mas esfuerzo es un crecimiento modular. Es decir, la idea es dividir  la CNLS en varios CNLS mas pequeños, que vendrían a ser funcionalidades o tareas determinadas. Una vez se ha segmentado todo el sistema en varios CNLS se unen teniendo en cuenta los limites y restricciones, y finalmente se se valida.

Por ahora nos hemos extendido mucho, así que dejamos por aquí. Si te interesa el tema y quieres seguir aprendiendo no dudes en continuar la lectura y practicas en la parte 2