Free Press

El modelado dimensional (DM) forma parte de la metodología Business Dimensional Lifecycle desarrollada por Ralph Kimball, que incluye un conjunto de métodos, técnicas y conceptos para su uso en el diseño de almacenes de datos. El enfoque se centra en la identificación de los procesos de negocio clave dentro de un negocio y el modelado e implementación de estos primero antes de añadir los procesos de negocio adicionales, un enfoque de abajo hacia arriba.

¿Cuáles son los objetivos del modelado del almacén de datos?

Los objetivos, expuestos por Ross y Kimball, son sencillos:

• hacer que la información sea fácilmente accesible
• presentar la información de forma consistente
• adaptable y receptiva al cambio
• presentar la información de forma oportuna
• proteger los activos de información
• servir como base autorizada y fiable para mejorar la toma de decisiones (única fuente de verdad en el lenguaje de la Ingeniería de Datos)
• los VIPs deben aceptar su sistema

Si has trabajado o utilizado un sistema ETL, te habrás dado cuenta de que la consistencia de la información se consigue con medidas de conformidad, la puntualidad que proporcionan los ciclos ETL y la adaptabilidad también depende en gran medida del diseño del ETL.

¿Por qué modelar?

Como ingeniero de datos, conoce muy bien SQL y probablemente pueda escribir consultas SQL durante todo el día. Pero no puede asumir que el usuario final típico será un experto en escribir consultas SQL. Por lo tanto, nuestro objetivo es construir un DW tan fácil para los analistas para escribir consultas de análisis de forma rápida y eficaz.

Cosas que no querrá que sus analistas hagan:

• Consultas basadas en ID
• Cascading outer joins(incluso usted no querrá hacer eso)
• Subconsultas agrupadas o unidas múltiples
• Subconsultas recursivas(sólo visite Hackerrank SQL y entenderá el dolor)
• Correlación de subconsultas: La obtención de datos a través de múltiples columnas en diferentes subconsultas
• Joins sin PK/FK: incluso para mí(1.5 años de experiencia en DE), es difícil de visualizar.

Cosas que podría y debería esperar de sus analistas:

• uniones simples
• columnas con nombres y texto completo
• agregación simple
• funciones analíticas en ventana
• DISTINTO

Nótese, que los puntos anteriores no son los fáciles y que su sistema debe ser lo suficientemente escalable para todo este tipo de consultas.

Las bases de datos OLTP se transforman en hechos y dimensiones debido a los objetivos mencionados.

Transición de las bases de datos transaccionales a los hechos

La mayoría de las empresas miden su éxito y eficiencia midiendo ciertos tipos de datos. Estos datos capturan las actividades y el progreso real del negocio. Estos datos se denominan hechos.

Las bases de datos orientadas a OLTP registran las transacciones a la vez, algo así como un flujo de eventos pero centralizado en torno a las transacciones. El DW es diferente. El DW no necesita registrar detalles a nivel transaccional. DW necesita tener hechos a través de diferentes criterios de su negocio. El DW necesita agregar (o dejar que los analistas agreguen) la información necesaria para mejorar el negocio. Por lo tanto, la redundancia es un pecado imperdonable en DW.

¿Qué son las medidas y por qué debe llenar sus tablas de hechos con ellas?

En un almacén de datos, una medida es una propiedad sobre la que se pueden hacer cálculos.

Los hechos que derivamos de los almacenes de datos operativos vienen con algunos datos adicionales que normalmente se suman en nuestro análisis. Estos son los aspectos de un hecho que permiten al analista, o al ejecutivo que ve el análisis, ver el valor del hecho.

¿Por qué necesita mantener un grano consistente?

Para que pueda asegurar que su sistema pueda correlacionar y agregar legítimamente a través de los hechos.

Pero no siempre es posible tener datos a niveles atómicos. Así que, para salvar este vacío, existen dos métodos:

• Tablas de hechos de instantáneas periódicas
• Tablas de hechos de instantáneas acumulativas

Tablas de hechos de instantáneas periódicas

Como su nombre indica, se recogen a intervalos de tiempo regulares. El consumo de gas, la auditoría y las inspecciones son algunos casos de recopilación de datos que tienen instantáneas periódicas habilitadas para ellos.

Tablas de hechos de instantáneas acumulativas

Cuando un indicador de rendimiento empresarial es una tasa de finalización de un proceso empresarial de varios pasos, es posible que desee capturar en el grano de la totalidad del proceso y registrar el inicio, la finalización y los pasos intermedios. Esto puede ser de grano de transacción, pero tiene un montón de medidas en el medio. Por lo tanto, se utilizan tablas de hechos de acumulación de instantáneas para responder a preguntas complejas en la inteligencia de negocios donde existe el paso del tiempo entre los hechos. Un buen ejemplo sería una fila de la tabla de hechos de su pedido de un sándwich de pollo y la fila de la tabla de hechos de la bolsa que se entrega a través de la ventana del coche en el drive-thru de McDonald’s.

Localización de hechos a través de dimensiones

Usted y sus analistas necesitan saber cómo consultar y filtrar los hechos para derivar la inteligencia empresarial de ellos. Este propósito es servido por las dimensiones.

Dibujar dimensiones a partir de datos de referencia y raw-meta

Las dimensiones casi siempre se crean con una clave sustituta; la clave sustituta, naturalmente, es referenciada por la clave (o claves) extranjera en la tabla de hechos. Buscamos en la tabla las dimensiones que nos interesan. Todos los demás datos que describen nuestros hechos, como las marcas de tiempo, los agentes de los clientes, la ubicación de la tienda, el producto y el cliente, son los que convertimos en dimensiones.

La belleza del modelado dimensional es que los hechos no se definen por las claves primarias ni por ningún tipo de identificador único, sino que se definen por la combinación de dimensiones. Esto da lugar a Star Schema.

Es muy importante que tengamos una unicidad en nuestras dimensiones. Cuando lleguemos a las consultas a través de los hechos, los duplicados entre las combinaciones de dimensiones se convertirán en un desastre. Si no puedes, añade o agrega dimensiones para hacerlas únicas.

Jerarquía en las dimensiones

Considera las siguientes dos imágenes.

Un analista tendrá una vida fácil si le configuras la tabla de segunda dimensión.

Entonces, con la segunda tabla, tienes la siguiente jerarquía:

Hay todo tipo de jerarquías – jerarquías múltiples, jerarquía única, etc. No voy a tratarlos en esta entrada del blog.

Una cosa que me gustaría señalar es que la dimensión temporal es un verdadero dolor de cabeza. Hay que ocuparse de los días mágicos, del calendario fiscal, de los husos horarios, de los ciclos(tipos de beneficio sobre trimestre). Y no seas pésimo ni te confíes en esto, ni siquiera las bases de datos de series temporales te ayudarán en las jerarquías si tu ETL es un desastre. Quizás quieras echar un vistazo a las dimensiones Outrigger. También hay ocasiones en las que una dimensión depende naturalmente de otra. En tal caso, los diseñadores pueden poner una clave foránea de la una a la otra. Esto es lo que constituye una «dimensión de soporte». En las dimensiones de calendario, esto es muy común.

No puede utilizar una fecha en un grano diferente en un outrigger de las fechas que utiliza en la tabla de hechos. No se puede permitir la agregación sobre las dimensiones del balancín. Si es necesario, enmascare los valores numéricos en el balancín con prefijos o sufijos textuales para impedirlo.

Cambios lentos de dimensiones

Por mucho que quiera escribir sobre ello, sigo pensando que es mejor que mis lectores entiendan bien este concepto desde aquí.

No voy a hablar de las dimensiones Snowflake, pero sólo para señalar, que todavía están en uso con las bases de datos OLAP.

Integre su Big Data en su sistema ETL

Tratará su Big Data tabular como si hubiera sido adquirido a través de una de sus fases estándar de Extracción. Por lo tanto, le aplicará los mismos pasos que aplicó en la transformación:

1. Limpieza de datos
2. Conformación de unidades y formatos
3. Desduplicación
4. Reestructuración
5. Estadística

Resumen

Quería entender los aspectos teóricos del diseño de bases de datos lo que me llevó a leer el libro, Ross y Kimball. Luego sentí curiosidad por trazar diferencias y analogías en sus métodos y en los de las principales empresas de datos de hoy en día, como Netflix, Airbnb, Uber, etc.

En esta búsqueda, puedo decir con justicia que se prefiere el formato estructurado del modelado dimensional sobre un simple ETL duro. Porque de esta manera, eliminas la dependencia de ti, tu equipo de BI no te llama por Slack para crear un nuevo DAG para cada dos insights, en cambio, con un correcto modelado, les permites actuar y explorar libremente sin tu necesidad.

Por favor, deja tus comentarios sobre cómo podría mejorar, estoy seguro de que esta no ha sido tu mejor lectura. Gracias por su tiempo.

Notas al pie

https://en.wikipedia.org/wiki/Dimensional_modeling

https://en.wikipedia.org/wiki/Measure_(data_warehouse)

Ross y Kimball, cap. 2 y cap. 18

Kimball/Ross pp103-109