Las estructuras de datos dimensionales son el objetivo de los procesos ETL, y estas tablas se sitúan en el límite entre los procesos de transformación de datos y su volcado al sistema de datos de explotación. En muchos casos, las tablas dimensionales serán el último paso físico de preparación antes de transferir las tablas a los entornos de los usuarios finales.
Los modelos de datos dimensionales son, con diferencia, las estructuras de datos más populares para las consultas y análisis de los usuarios finales. Son sencillos de crear, son extremadamente estables en presencia de entornos de datos cambiantes, son intuitivamente comprensibles por los usuarios finales y son la estructura de datos más rápida para consultas generales en bases de datos relacionales. Los modelos dimensionales también son la base para construir todas las formas de cubos OLAP, ya que un cubo OLAP no es más que un modelo dimensional de alto rendimiento implementado en software de propósito especial
Tablas de Hechos
Los modelos dimensionales se construyen alrededor de procesos de medición. Una medición es una observación en el mundo real de un valor previamente desconocido. Las mediciones son predominantemente numéricas y la mayoría de ellas pueden repetirse a lo largo del tiempo, creando una serie temporal.
Una sola medición crea un único registro en la tabla de hechos. Inversamente, un único registro en la tabla de hechos corresponde a un evento de medición específico. Obviamente, la medición observada se almacena en el registro de la tabla de hechos. Pero también almacenamos el contexto de la medición en el mismo registro. Aunque podríamos sentirnos tentados a almacenar este contexto en muchos campos detallados directamente en el registro de la tabla de hechos, normalizamos sistemáticamente los atributos contextuales fuera de la tabla de hechos creando una serie de tablas de dimensiones que pueden verse informalmente como agrupaciones de contexto.
Por ejemplo, si la medición es la cantidad de una prima de seguro registrada por una compañía de seguros en una póliza particular, un cliente particular, un agente particular, una cobertura específica (como daños por colisión), un artículo asegurado (quizás un automóvil), un tipo de transacción específico (como establecer prima), en una fecha efectiva determinada, las dimensiones típicas adjuntas al registro de hechos serían Póliza, Cliente, Agente, Cobertura, Artículo, Tipo de Transacción y Fecha Efectiva.
El grano de una tabla de hechos es la definición de lo que constituye un registro único en la tabla de hechos. En el mundo del modelado dimensional, el grano siempre se declara al principio del diseño en términos de negocio, no en términos de base de datos. El grano de nuestro ejemplo de seguro podría ser la transacción de póliza de seguro. Luego, más adelante en el proceso de diseño, cuando se comprenden las dimensiones disponibles, el grano puede declararse formalmente en términos de la clave de la tabla de hechos. Esta declaración de clave incluirá algunas, pero generalmente no todas, las referencias de clave foránea a las dimensiones adjuntas a la tabla de hechos. Asumimos que la clave para nuestra tabla de hechos de seguros es Póliza X Tipo de Transacción X Tiempo.
La estructura y el contenido de un modelo dimensional dependen únicamente de la física del proceso de medición en sí.
Tablas Dimensionales
El modelo dimensional no anticipa ni depende de los usos de consulta previstos. Es un marco simétrico extremadamente flexible, adecuado para todas las clases de consultas. Sin embargo, aún hay cierto margen para la discreción del diseñador. Muchas de las dimensiones para una tabla de hechos particular se referenciarán directamente en la fuente de datos original. Pero el equipo del almacén de datos puede agregar dimensiones que provienen de otras fuentes, siempre que sean de valor único en el momento del evento de medición. Por ejemplo, en nuestro caso de seguros, se podría agregar una dimensión de promoción orientada al marketing si esos datos estuvieran disponibles. Una de las grandes fortalezas de los modelos dimensionales es su capacidad para agregar grácilmente contexto dimensional que es válido en el contexto del evento de medición.
De manera similar, las mejores dimensiones son descripciones detalladas de las entidades dimensionales. Así que la dimensión Cliente en nuestro ejemplo debería tener muchos campos descriptivos. A estos campos descriptivos los llamamos atributos dimensionales. Afortunadamente, todos los diseños dimensionales permiten que se añadan atributos a las dimensiones de forma incremental a lo largo de la vida del almacén. La responsabilidad del arquitecto del almacén de datos es identificar estas oportunidades para atributos adicionales y solicitar que el equipo de ETL los añada al esquema físico. Los atributos dimensionales son principalmente textuales o son números que adoptan valores discretos. Las tablas dimensionales siempre deben construirse con un único campo de clave primaria que es un entero simple sin significado asignado por el proceso de ETL. Estas claves se llaman claves sustitutas.
Las claves sustitutas primarias en cada dimensión se emparejan con claves foráneas correspondientes en la tabla de hechos. Cuando se respeta esta relación clave primaria-a-foránea, decimos que las tablas obedecen la integridad referencial. La integridad referencial es un requisito constante en todos los modelos dimensionales. No mantener la integridad referencial significa que algunos registros de la tabla de hechos son huérfanos que no pueden recuperarse mediante restricciones en las dimensiones afectadas.
Tablas de Hechos Atómicas y Agregadas
Sabes que un modelo de datos dimensional es el mejor formato para los datos que respaldan las consultas de los usuarios. En ocasiones, podrías necesitar utilizar ciertos elementos a nivel atómico para que los datos se puedan presentar a un nivel superior. Sin embargo, necesitas almacenar los hechos a nivel atómico para producir las solicitudes precisamente restringidas requeridas por los usuarios. A menudo, los usuarios de negocios no quieren analizar hechos a nivel de transacción porque la cardinalidad de cada dimensión es tan extensa que cualquier informe a nivel atómico sería de páginas y páginas, lo que lo hace humanamente imposible de examinar. Sin embargo, necesitas almacenar los hechos a nivel atómico para producir los hechos de instantáneas periódicas requeridos por los usuarios. Cuando llega el momento en que los usuarios solicitan datos a nivel atómico, simplemente puedes migrarlos del área de preparación a la capa de presentación.
Es una buena práctica particionar las tablas de hechos almacenadas en el área de preparación porque los agregados resultantes probablemente se basarán en un período específico, tal vez mensual o trimestral. Crear particiones alivia a la base de datos de tener que escanear toda la tabla y le permite ir directamente a la subsección que contiene los datos que necesita para ese período para crear el agregado. La partición también reduce la carga de podar o archivar datos antiguos. Las tablas particionadas simplemente pueden eliminar la parte de una tabla que contiene los datos antiguos.
Las tablas diseñadas dimensionalmente en el área de preparación son en muchos casos necesarias para poblar cubos de procesamiento analítico en línea (OLAP). O puedes implementar una estructura híbrida donde tienes la gran capa de datos atómicos en un esquema RDBMS dimensional, con estructuras cada vez más agregadas por encima de la capa atómica en forma de cubos OLAP. Algunos de los sistemas OLAP pueden explorar a través de los cubos OLAP y acceder a los datos atómicos de nivel más bajo en una sola aplicación.
Tablas de Mapeo de Claves Sustitutas
Las tablas de mapeo de claves sustitutas están diseñadas para mapear claves naturales de los sistemas fuente dispares a su clave sustituta maestra del almacén de datos. Las tablas de mapeo son una forma eficiente de mantener claves sustitutas en tu almacén de datos. Estas tablas compactas están diseñadas para un procesamiento de alta velocidad. Las tablas de mapeo contienen solo el valor más actual de una clave sustituta, utilizado para poblar una dimensión, y la clave natural del sistema fuente. Dado que la misma dimensión puede tener muchas fuentes, una tabla de mapeo contiene una columna de clave natural para cada una de sus fuentes.
Las tablas de mapeo pueden ser igualmente efectivas si se almacenan en una base de datos o en el sistema de archivos. La ventaja de usar una base de datos para las tablas de mapeo es que puedes utilizar el generador de secuencias de la base de datos para crear nuevas claves sustitutas. Y también, cuando se indexan correctamente, las tablas de mapeo en una base de datos son muy eficientes durante las búsquedas de valores de clave.
Dado que las tablas de mapeo de claves no tienen valor analítico, nunca deben residir en la capa de presentación del almacén de datos ni ser expuestas a los usuarios finales.