En este segundo capítulo de la primera sesión TechXperience, David Ortega Cruz , incide en aspectos a tener en cuenta para organizar, diseñar y estructurar modelos de tablas para el tratamiento de datos. Acompáñanos en este repaso de la charla titulada “Modelado de tablas”
Modelado de tablas
A la hora de diseñar las tablas de las distintas capas, hay que tener en cuenta una cuestión muy importante el SCD (Slowly Changing Dimension) o historificación. La historificación es determinar cómo reflejamos los cambios que sufren los datos en nuestras tablas de destino. Hay distintas opciones, las principales son:
- Tipo 1: Sobre escribir. Se actualiza la información que cambia de la fila. Se suele tener una fecha de entrada y una fecha de actualización.
- Tipo 2: Añadir fila. Se añade una nueva fila con una fecha inicio y fecha fin, la cual nos indicará el periodo de validez del registro.
- Tipo 3: Añadir columna. Se añade una columna con el valor previo que tenía el campo antes del cambio.
- Tipo 4: Historial de cambios. Se tiene una tabla con los cambios que se han realizado en los registros.
Un aspecto muy importante en el desarrollo es evaluar correctamente que tipo de historificación utilizar. Ya que puede ser necesario saber el estado de los registros en el pasado, para realizar preprocesamiento ha pasado o en las visualizaciones realizar comparativas con fechas pasadas. Por lo general, se suele utilizar un tipo 2, es decir, se crea una nueva fila por cada cambio y se marca su rango de fechas válido.
En el tipo 2 hay dos tipos de versiones, un tipo de versionado por periodos con una fecha de inicio y fecha fin del registro. Y un tipo de versionado, en el cual se hacer una foto diaria con una fecha de cierre que marca el día. La historificación implica que el volumen de las tablas crecerá día a día. Esto hace que hay que realizar un estudio de volumetría. Con este estudio ver cuántos registros y espacio se carga en las distintas tablas cada día para prevenir cuando hará falta más espacio. En los casos que se hace una foto diaria de los datos, se suele utilizar tablas particionadas por días para tener una mayor eficiencia. En el otro caso con fecha de inicio y fin, en algunas ocasiones se utilizan tablas históricas para guardar datos antiguos y no saturar la tabla principal.
Otro aspecto relacionado con la historificación, es como identificar que un registro ha sufrido cambios. Si la tabla es muy grande en columnas, ir comparando columna a columna con el nuevo registro es muy costoso en tiempo. Por lo que se suele utilizar un campo denominado Hash, que contiene el hash o el MD5 de todos los campos principales del registro quitando los campos de Primary Key y campos de auditoría. Con ello solo habrá que hacer un Hash a la nueva fila y comparar un solo campo para saber, si el registro nuevo hay que insertarlo o no.
Hay que realizar también, un estudio de los campos origen para la correcta elección de los tipos de datos. Ya que es muy importante para el rendimiento de las consultas y el espacio que ocuparan las tablas. Sobredimensionar las columnas en exceso, provocará que nunca se llene su espacio disponible y sea espacio desperdiciado.
Se crea una dimensión tiempo con un script y con un conjunto de fechas a futuro amplio, para cruzar por la fecha. En esta tabla dimensión, suele contener la fecha, día, mes, años, trimestre, cuatrimestre, semana y día de la semana. Esta dimensión es esencial para luego realizar visualizaciones con cálculo de fechas por diferentes opciones temporales.
Nomenclatura de las tablas y los campos
No hay que perder de vista otro aspecto muy importante, la nomenclatura de las tablas y los campos. Algunos clientes suelen tener documentos o equipos de Data Management con unas reglas de nomenclatura de tablas y columnas. En el caso de que no lo tenga, hay que tener cuidado en los nombres, ya que esto deben ser representativos. No deberían ser más de 30 caracteres de longitud generalmente. Además, debería consensuarse con el equipo que mantendrá la base de datos y los clientes. Ya que habrá campos en otras bases de datos del cliente que ya tengan un nombre, con lo que algunos nombres deben seguir ese nombre. Porque a veces pasa que un mismo campo en un DWH se le llama de varias formas distintas, lo que dificulta la compresión y confunde al cliente. Es importante que si se utilizan palabras largas utilizar abreviaturas adecuadas. Evitar nombrar tablas y campos solo con iniciales, ya que dificulta la compresión y puede llevar a error en muchos casos.
En ocasiones, se utiliza como prefijo o sufijo en los campos una palabra clave para saber si es un código, descripción, fecha, importes o flag. Un ejemplo de prefijos, ID significa identificar de registro, CD significa código, DS significa descripción, MT significa métrica, DT significa fecha o IS significa flag. También es común en las tablas ponerle un prefijo para saber si es una tabla de dimensión, de hechos, de auditoría, auxiliar, etc. Un ejemplo de prefijos para tablas, AUX significa tabla auxiliar, FACT significa tabla de hecho, DIM significa tabla de dimensiones o AUD significa tabla de auditoría.
Business Glosary (diccionario de negocio)
Acorde con la nomenclatura de las tablas y los campos, es necesario realizar un Business Glosary, es decir, un diccionario de negocio de los campos. Con ello nos aseguramos de que significa cada nombre de tabla y campos, además de que información relevante de cuáles son sus orígenes. Facilita la lectura para los clientes de que es cada campo, además de facilitar a los desarrolladores y el equipo de mantenimiento su compresión. Este Business Glosary, se puede utilizar para unificar los disantos campos en los distintos modelos de datos y que todo el mundo utilice un mismo nombre para un mismo campo. No que cada uno lo llame a su manera y luego tengas n veces un campo llamado de diferentes maneras.
Es muy importante hacer una documentación tanto técnica y funcional, donde reflejar los modelos de datos, sus orígenes y documentar los procesos. Estos documentos se deben actualizar, no solo cuando se realiza el proyecto, sino también cuando se realizan correcciones o mejoras. Estos aspectos en la arquitectura y modelado de datos pueden parecer triviales, pero algunas veces no se tienen en cuenta o pasan desapercibidos. Esto provoca rehacer la arquitectura y los modelos de las bases de datos, lo que conlleva un retraso y rehacer procesos de carga de datos.
Tratamiento de errores en el modelado de tablas
Una cuestión importante, es que hacer los con registros que tienen errores o no cumplen con la calidad de los datos. Ya esto implica, crear unas tablas de errores para guardar aquellos registros que no se cargan en las tablas normales y cuál es su razón. Por lo general, los registros que no cumplen no se suelen guardar, pero siempre es una buena práctica guarda aquellos que no cumple porque en algún momento alguien preguntará porque no aparecen.
