Explicación del modelo de datos de ejemplo (Contoso)

Hace pocos días publiqué una base de datos la cual ofrecí utilizar para enseñar DAX en este blog. El artículo en cuestión lo encuentran aquí. Antes de comenzar con la enseñanza de DAX, conviene sobremanera entender la organización y estructura de dicha data publicada. En otras palabras -usando la jerga de Power BI- conviene entender el Modelo de Datos.

Un Modelo de Datos es un conjunto de tablas organizadas y relacionadas de manera tal que respondan a una necesidad de análisis de negocio.

Vamos por partes. Recordemos que una tabla es información organizada en filas y columnas, referida toda a un solo concepto. Veamos el gráfico siguiente:

Esta tabla tiene tres columnas, campos o atributos (i.e. alumno, curso y nota), y siete filas o registros (o en jerga: «tuplas»). Permítanme señalar varias cosas que para los técnicos es evidente, pero para los analistas de negocio puede que no.

Primero y más importante, en este ejemplo cada fila representa una nota obtenida por un alumno en un curso particular. En otras palabras, no es una tabla de alumnos, ni tampoco de cursos. Es una tabla de notas. Cada fila representa algo muy concreto que es la nota del alumno en el curso. En una tabla, cada fila representa algo concreto.

Del mismo modo, cada columna tiene un tipo de datos. Por ejemplo la columna «Alumno» y la columna «Curso» son de tipo texto (i.e. almacenarán información tipo texto) y la columna nota es tipo número. El hecho de que una columna sea tipo número, implicará que puedan hacerse cálculos con ella (en este caso, por ejemplo, calcular nota promedio)

Segundo, en cada «intersección» de fila y columna, en otras palabras, cada atributo de un registro tiene un solo valor. Veamos el gráfico siguiente donde presento una tabla muy mal diseñada para el análisis.

Esta tabla a la que llamo «pésima tabla» no sirve para analizar. Es un excelente ejemplo de un muy mal diseño. Si bien la información que contiene es la misma que la de la tabla anterior, el modelado está mal hecho. El primer registro tiene «DOS datos» en la columna Curso (i.e. consigna dos nombres de curso donde solo debería aparecer uno: «Matemáticas» e «Historia»). Lo mismo sucede en la columna «Nota». Hay dos notas en algunos registros. Esto causará, por ejemplo, que la columna «Nota» no pueda ser tipo número (sino tipo texto) y, por ello, no podría calcularse la nota promedio, por ejemplo. Qué sucedería, además, si en lugar de 2 cursos, se ponen 3, o 5, o 10 en una sola fila. Se vuelve inmanejable.

No estoy negando que data como la «pésima tabla» mostrada pueda existir en una organización. De hecho muchos usuarios tienen tablas así, ya sea porque fueron heredadas de alguien más, porque les conviene para la digitación, o por alguna otra razón. Si eso les sirve para escribir datos y para llevar control operativo de algo, pues continúen así. Lo que digo es que para poder analizar esta información, una tabla modelada así no sirve para nada. Al momento de cargar datos (a Power BI o Power Pivot), habrá que extraer esa data, «descifrarla» y cargarla a una tabla bien hecha.

Dicho esto, veamos el modelo Contoso v2 materia principal de este artículo:

En este modelo hay cinco tablas. Cada una tiene una serie de columnas que en el gráfico se ven enumeradas hacia abajo. Paso a explicar:

• Ventas: cada fila representa una venta (una transacción). Hay información del Monto, del Costo y de la Cantidad de cada Venta. Esta es la tabla «principal» del modelo. Dicho de otra manera, todo gira alrededor de la información que hay en ella. Si sumara, por ejemplo, la columna «MontoVendido» obtendría, precisamente, el Monto Vendido para las transacciones cuyas filas sumé. Cada fila, además, tiene información de la Fecha , el Producto, la Tienda y el Canal a través del cual se dio la venta. En el gráfico siguiente se ve, por ejemplo, que la primera fila representa una venta realizada el 22 de octubre de 2008, a través del Canal 1, en la Tienda 299. El producto vendido es el que lleva por código 375. Las siguientes columnas muestran las Cantidades y Montos relacionados con esa transacción. Esta tabla es tan importante en el modelo que recibe el nombre de «Tabla de Hechos» porque cada línea representa -efectivamente- un hecho o acontecimiento (i.e. el hecho de que se vendió el producto 375 el 22 de octubre de 2008, en el canal 1… por un monto de 6990)

• Canal: Es una tabla donde cada fila representa un Canal de venta: el canal Tienda, el canal Online, etc. Es una tabla muy sencilla y se ve que realmente sirve para «traducir» un código de canal (e.g. el canal 1 de la primera fila de la tabla ventas) en un nombre de canal («Tienda»). Viene a ser una especie de maestro de códigos de canal. Si tienes un código de canal y quieres averiguar su nombre, solo vas al maestro de códigos y sabrás el resultado. Valga decir que a este tipo de tablas maestras o maestros de código, se les denomina también tablas de dimensión. Yo prefiero llamarlas Maestros de Código.

• Producto: Siguiendo con el razonamiento de la tabla Canal, esta sería un Maestro de Productos: una fila por cada código de producto existente. Por ejemplo la primera fila de esta tabla nos dice que el producto con código 799 es una funda de cuero para cámara «Leather case…». Pero no solo nos dice eso: especifica también que el producto 799 es, por ejemplo, de Marca Contoso, Clase Premium, Color Blanco y pertenece a la Subcategoría «Computers Accesories». Finalmente, también asocia un costo unitario y un precio unitario a ese producto. Deducimos entonces, que los Maestros de Código no solamente sirven para convertir un código en el nombre completo, sino también para especificar más cosas (columnas o atributos) de cada fila. En este caso, clasifica a cada producto con un fabricante, marca, clase, color, subcategoría y categoría lo cual permitirá un análisis más poderoso de los productos (e.g. un análisis por marca o por categoría, por ejemplo). Los maestros de códigos como este, suelen ser así: no solo tienen la columna del código y la columna del nombre, sino varios atributos más que enriquecen el análisis.

• Tienda: Es un Maestro de Tiendas. Cada fila representa una Tienda y nos dice, por ejemplo, que el código 4 representa la Tienda «Bellevue Store». Además, nos brinda información enriquecida como la Ciudad y País donde se ubica la tienda en cuestión.

• Fecha: Es un Maestro de Fechas. Si bien puede sonar raro, solo sigamos los que hemos aprendido de lo que es una tabla maestra de códigos: cada línea representa una fecha. En la primera fila está la fecha con «código» 1/01/2008, y gracias a las demás columnas, sabemos que esa fecha pertenece al año 2008, al semestre H1, al trimestre Q1, al mes Enero, fue martes («Tuesday»), etc. Vemos pues que, al tener este extraño «Maestro de Fechas», logramos un análisis poderoso respecto de las mismas, ahora podríamos analizar por Mes, o por día de la semana, etc. Un analista de datos que usa Excel, normalmente no usa un maestro de fechas pero acabamos de descubrir que es muy útil para un análisis de tiempo poderoso. ¿Qué pasaría si -por ejemplo- en mi empresa no analizan las ventas por mes ni por trimestre sino por número de semana o por número de campaña pues el año se divide en 18 campañas? Bueno, lo único que habría que hacer para habilitar un análisis como el que la pregunta plantea, es agregar una columna «número de semana» o «número de campaña» al maestro de fechas y listo. Ya se podría analizar las ventas vía esos rubros.
  Además de habilitar un análisis poderoso de fechas, el Maestro de Fechas cumple una segunda y potente función en Power BI (y en Power Pivot): permite hacer muy fácilmente análisis temporal (también conocido como Inteligencia de Tiempo o «Time Intelligence»). Esto es, analizar por ejemplo crecimientos año contra año, o ver acumulado a la fecha o acumulado trimestral. Esto será materia de posteriores artículos pero quedemos desde ya, que el Maestro de Fechas debería estar presente en todo análisis hecho en Power Pivot o Power BI.

Muy importante: la cantidad de archivos de datos, o la estructura de los mismos, no tiene nada que ver con el diseño y cantidad de tablas en nuestro Modelo de Datos. Por ejemplo, la tabla Ventas arriba mostrada puede provenir de 5 archivos Excel distintos. O el maestro de Productos podría ser resultado de mezclar varias bases de datos para obtener la estructura que ahí se muestra.

No existe relación alguna entre el número y estructura de archivos con data necesarios para el análisis y el número y estructura de tablas del Modelo de Datos.

Para terminar, además de tablas, hay relaciones (representadas por líneas en el Modelo de Datos) que no hacen más que «vincular» dos columnas que contienen el mismo código. En el gráfico que sigue se relaciona la columna CCanal de la tabla Ventas con la columna CCanal de la tabla Canal. Ambos contienen el código de Canal. Una manera de leer esto sería: para saber qué significa un código de canal (columna CCanal) en la tabla Ventas, hay que buscarlo en la tabla Canal (columna CCanal). Los nombres de las dos columnas no tienen que ser iguales. Aquí es así por motivos pedagógicos. Pero, eso sí, deben contener los mismos datos: códigos en ambos casos.

Finalmente, se ve que en cada relación (la línea amarilla del gráfico anterior) hay unos símbolos (un 1, un * y un triángulo o cabeza de flecha al medio de la línea). De dichos símbolos hablaré en un posterior artículo.

(*) La foto que acompaña este artículo es un dibujo creado por el famoso artista Maurits Cornelis Escher quien se inspiraba en las matemáticas para dibujar cosas imposibles. Este edificio que a primera vista se ve bien, es un objeto imposible cuando lo ves a detalle. Me recuerda a algunos «modelos de datos» que si bien son maquillados para aparecer «lindos», al utilizarlos (i.e. «verlos a detalle») no representan adecuadamente el requerimiento de análisis y terminan complicando el proyecto hasta volverlo casi imposible de realizar. La foto fue tomada de esta página.