Modelo de Datos Relacional

Ya he mencionado que un modelo de datos se caracteriza por la estructura de datos que admite, las operaciones sobre esa estructura y la forma de especificar las restricciones. En este post voy a presentar una descripción más detallada de una serie de modelos de datos comunes. Voy a empezar con los datos relacionales, que es uno de los modelos de datos más simple y de uso más frecuente actualmente y constituye la base de muchos otros sistemas de gestión de bases de datos tradicionales como MySQL, Oracle, Teradata, etc. Por lo tanto, después de este post espero que seas capaz de describir los componentes estructurales de un modelo de datos relacional, de demostrar que componentes se convierten en el esquema de un modelo de datos, de explicar el propósito de las claves primarias/externas y de describir el Join y otras operaciones.

El Modelo Relacional

La estructura de datos principal de un modelo relacional es una tabla, como en la aplicación de ejemplo que se muestra aquí. Pero tenemos que tener cuidado con las tablas relacionales, que se llaman también relaciones. Esta tabla representa en realidad un conjunto de tuplas. Esta es una tupla relacional, que se representa como una fila de la tabla. Antes le estábamos llamando informalmente "registro", pero una tupla relacional implica que, a menos que se indique lo contrario, los elementos de la misma, como 203, 204, Mary, etc., son atómicos, es decir, que representan una unidad de información y no se pueden descomponer más. Por lo tanto, esta es una relación de seis tuplas.

Una colección de tablas

Recuerda la definición de conjunto: "una colección de elementos distintos del mismo tipo". Eso significa que no se puede añadir esa tupla a la solución, porque si se hace, se introduciría un duplicado. En la práctica muchos sistemas permiten tuplas duplicadas en una relación, pero se proporcionan mecanismos para evitar entradas duplicadas si el usuario así lo elige.

Evitar duplicados

Aquí hay otra tupla que no se puede añadir. Tiene todas las piezas correctas de información, pero todas en el orden equivocado, por lo que es una tupla desigual a las otras seis tuplas de la relación. Entonces, ¿Cómo sabe el sistema que esta tupla es desigual? 

Prohibidas las tuplas desiguales

Esto dirige nuestra atención a la primera fila de todas que corresponde a la cabecera de esta tabla pintada en negro. Esta fila es parte del esquema de la tabla, en este caso, la de empleados, los nombres de las seis columnas denominadas atributos de la relación y, para cada columna, nos indica el tipo de datos permitido, es decir, la restricción de tipo de cada columna. Teniendo en cuenta este esquema, ahora debería estar claro por qué la última fila de color rojo no pertenece a esta tabla.

Esquema relacional de la tabla Empleados

El esquema de una tabla relacional también puede especificar restricciones, que se muestran en amarillo en la tercera línea de la fila del esquema. Indica que el salario mínimo de una persona tiene que ser mayor de 25k. Además, establece que todo empleado debe tener un nombre y un apellido. No se pueden dejar a nulo, es decir, sin valor. ¿Por qué no tiene esta restricción la columna de departamento o de título? Una respuesta puede ser que a un nuevo empleado no se le puede asignar todavía un departamento o un título, pero pueden seguir siendo entradas de la tabla. Sin embargo, la columna de departamento tiene otra restricción. Restringe los valores posibles que forman parte del dominio del atributo a solo cuatro posibilidades: Recursos Humanos, Informática, Investigación y Negocio. Por último, la primera dice que el ID es una clave primaria, lo que significa que es única para cada empleado, de manera que si se conoce la clave primaria el empleado, también se sabrá de forma unívoca los otros cinco atributos de ese empleado. Observa que una tabla con una clave primaria implica de forma lógica que la tabla no puede tener un registro duplicado, ya que si existiera violaría la restricción de unicidad asociada a la clave primaria.

Permíteme presentarte una nueva tabla que contiene la historia salarial de los empleados. Los empleados se identifican mediante la columna EmpID, pero estos no son nuevos valores que tendría esta tabla. Son los mismos IDs que figuran en la columna ID de la tabla de empleados mostrada anteriormente. Esto se refleja en la declaración que aparece a la derecha. El término "References" indica que los valores de esta columna solo pueden existir si aparecen los mismos valores en la tabla de empleados a la que hace referencia, también conocida como tabla principal (parent table). Por este motivo, en la terminología del modelado relacional, se dice que la columna EmpID de la tabla EmpSalaries es una clave externa (foreign key) que hace referencia a la clave primaria de la tabla de empleados. Te en cuenta que EmpID no es una clave primaria de esta tabla EmpSalaries porque tiene múltiples tuplas con el mismo EmpID reflejando el salario de los empleados en diferentes momentos del tiempo.

Claves externas

Imagino que recordarás que el Join es una operación común de la que he hablado anteriormente. Aquí proporciono un ejemplo de un join relacional realizado por las tres primeras columnas de la tabla de Empleados y de la tabla EmpSalaries, donde se compara la igualdad de las columnas Empleados.ID y EmpSalaries.EmpID. La tabla de salida muestra todas las columnas implicadas. La columna común se representa una vez. Esta forma de Join se denomina Join Natural. Es importante entender que el Join es una de las operaciones más costosas, lo que significa que consume mucho tiempo y espacio. A medida que los datos crecen y las tablas contienen cientos de millones de tuplas, la operación de Join puede convertirse fácilmente en un cuello de botella en una aplicación analítica más grande. Por lo tanto, para aplicaciones analíticas de grandes volúmenes de datos que necesiten Joins es muy importante elegir una plataforma adecuada de gestión de datos que optimice esta operación. Volveré a este tema en artículos posteriores.

Relaciones con Join

Voy a terminar este post con una nota práctica. En muchas aplicaciones científicas y de negocio la gente comienza con ficheros CSV que se manipulan con hojas de cálculo y luego migran su sistema relacional sólo como una idea de última hora cuando los datos se vuelven demasiado grandes como para manejar la hoja de cálculo. Aunque la hoja de cálculo ofrece muchas funcionalidades útiles, no cumple ni aplica muchos principios de los modelos de datos relacionales. En consecuencia, se dedica una gran cantidad de tiempo a la depuración y corrección de errores en los datos una vez finalizada realmente la migración.

Permitirme mostrarte algunos ejemplos de una hoja de cálculo que tiene 125.000 filas y más de 100 columnas. Esta hoja de cálculo enumera los ataques terroristas recopilados a partir de los medios de comunicación, de modo que cada fila representa un ataque. Esta es una información importante para las personas que estudian el terrorismo, pero vamos a verlo desde un punto de vista de modelado de datos relacional.

Excel y el Modelo Relacional

En primer lugar, observa la columna marcada en verde, la cual enumera dos armas utilizadas en el ataque separadas por un punto y coma. ¿Por qué esto es tan común? Esto provoca que la columna no sea atómica, lo que significa que esta columna en realidad tiene dos valores diferentes. En un diseño relacional moveremos esta información a otra tabla al igual que los múltiples salarios de los empleados se pusieron en una tabla separada.

A continuación, observa la columna que se indica en rojo. En ella se describe la cantidad de bienes dañados en un posible ataque terrorista. En esta columna los valores válidos posibles son "desconocido", "menor", "mayor" y "catastrófico". Sin embargo, el valor de la parte resaltada de la hoja de cálculo es "menor", y luego entre corchetes, "probablemente menos de 1$ millón", lo que significa que una consulta como "encontrar todos los ataques para los que el daño a la propiedad sea <<menor>>" no se puede responder directamente. En su lugar tenemos que realizar una búsqueda de la subcadena "menor" al comienzo de la descripción, lo que es factible, aunque más costoso.

Aquí se muestran las columnas de la hoja de cálculo, de modo que forma parte del esquema de datos. Si se observa con atención, se ve un patrón recurrente. El diseñador de la tabla decidió que puede haber como máximo tres tipos de ataques para un único enfrentamiento y que se representara con tres columnas separadas. En un modelado relacional apropiado diríamos que existe una relación uno a muchos (1:N) entre el ataque y el número de tipos de ataques. En tal caso sería más prudente colocar estas columnas del tipo de ataque en una tabla separada que conecte con la padre mediante una relación clave primaria - clave externa.