DAX :: Entendiendo el modelo de datos

Capítulo 1, tema 1 :: Entendiendo el modelo de datos

Feb 22
Marco Russo & Alberto Ferrari

DAX es un lenguaje específicamente diseñado para calcular fórmulas de negocio sobre un modelo de datos. Es posible que ya sepa lo que es un modelo de datos, pero si no está familiarizado con él, vale la pena dedicar algunas páginas a una descripción de los modelos de datos y relaciones, para crear una base sobre la que construir su conocimiento de DAX.

Un modelo de datos es un conjunto de tablas, enlazadas por relaciones.

Todos sabemos lo que es una tabla: un conjunto de filas que contienen datos, con cada fila dividida en columnas. Cada columna tiene un tipo de datos y contiene una sola información. Usualmente nos referimos a una fila en una tabla como un registro. Las tablas son una forma conveniente de organizar sus datos. Por sí sola, una tabla ya es un modelo de datos, aunque en su forma más simple. Por lo tanto, cuando escribe nombres y números en un libro de Excel, está creando un modelo de datos.

Si su modelo de datos contiene muchas tablas, es muy probable que estén enlazadas a través de relaciones. Una relación se establece entre dos tablas. Cuando dos tablas están unidas con una relación, decimos que están relacionadas. Gráficamente, una relación se representa mediante una línea que conecta las dos tablas. La Figura 1-1 muestra un ejemplo de un modelo de datos.

FIGURA 1-1
FIGURA 1-1 Este es un ejemplo sencillo de un modelo de datos compuesto por cinco tablas.

Algunos aspectos importantes de las relaciones que se deben aprender bien:

  • Dos tablas en una relación no tienen el mismo rol. Se les conoce como el lado único y el lado múltiple de la relación. En la Figura 1-1 se centra en la relación entre Product y Product Subcategory. Una sola subcategoría contiene muchos productos, mientras que un solo producto tiene sólo una subcategoría. Por lo tanto, Product Subcategory es el lado único de la relación (teniendo solo una subcategoría), mientras que Product es el lado múltiple (teniendo muchos productos).
  • Las columnas utilizadas para crear una relación (que normalmente tienen el mismo nombre en ambas tablas) se llaman las llaves de la relación. En el lado único de la relación, la columna necesita tener un valor único dentro del conjunto de datos. En el lado múltiple el mismo valor puede ser (y a menudo es) repetido en muchas filas diferentes. Cuando una columna tiene un valor único dentro del conjunto de datos, se llama la llave de la tabla. Generalmente, las tablas tienen una columna que es la llave.
  • Las relaciones pueden formar una cadena. Cada producto tiene una subcategoría y cada subcategoría tiene una categoría. Así, cada producto tiene una categoría. Para poder recuperar la categoría de un producto, necesitarás atravesar una cadena de dos relaciones. La Figura 1-1 incluye un ejemplo de una cadena compuesta por tres relaciones, comenzando con Sales y continuando hasta Product Category.
  • En cada relación, puede haber una o dos flechas pequeñas. En la Figura 1-1 se pueden ver dos flechas en la relación entre Sales y Product, mientras que todas las demás relaciones tienen una sola flecha. La flecha indica la dirección del filtrado automático de la relación.
  • En el modelo de datos tabulares, las relaciones sólo pueden crearse en columnas individuales. El motor no soporta relaciones entre múltiples columnas.

Comprender la dirección de una relación

Como se dijo anteriormente, cada relación puede tener una o dos direcciones de filtrado. El filtrado siempre ocurre de un lado de la relación a otro. Si la relación es bidireccional (es decir, tiene dos flechas), entonces el filtrado también ocurre desde el lado múltiple hacia el lado único.

Un ejemplo puede ayudar a entender mejor este comportamiento. Si crea una tabla pivote basada en el modelo de datos mostrado en la Figura 1-1, con los años en las filas y Sum of SalesAmount y Count of ProductName en el área de valores, verá el resultado que se muestra en la Figura 1-2.

FIGURA 1-2
FIGURA 1-2 Esta tabla pivote muestra el efecto de filtrar a través de múltiples tablas en acción.

La columna Row Labels contiene los años, es decir, una columna de la tabla Date. La tabla Date se encuentra en el lado único de la relación con la tabla Sales. Así que cuando ponemos Sum of SalesAmount en la tabla pivote, el motor filtra las ventas basadas en el año. La relación entre las tablas Sales y Product es bidireccional; cuando se pone Count of ProductName en la tabla pivote, se obtiene, como resultado, el número de productos vendidos por año. Dicho de otra manera, el filtro del año se propaga a la tabla Product mediante una cadena de relaciones.

Si ahora se modifica la tabla pivote poniendo el campo Color en las filas y añadiendo Count of FullDateLabel en el área de valores, el resultado es algo más difícil de entender, como se puede ver en la Figura 1-3.

FIGURA 1-3
FIGURA 1-3 Esta tabla pivote muestra que si no se activa el filtrado bidireccional, las tablas no están filtradas.

El filtro en las filas es la columna Color de la tabla Product. Debido a que Product se encuentra en el lado único de la relación con Sales, Sum of SalesAmount se filtra correctamente. Count of ProductName, obviamente, es filtrado, porque está calculando valores de la misma tabla que está en las filas (Product). El valor que está equivocado es Count of FullDateLabel. De hecho, siempre muestra el mismo valor para todas las filas, y por cierto, este número es el número total de filas en la tabla Date.

La razón por la cual el filtro que viene de la columna Color no se propaga hasta Date es que la relación entre Date y Sales tiene una sola flecha, que va de Date a Sales. Por lo tanto, incluso si Sales tiene un filtro activo, el filtro no puede propagarse a Date, porque el tipo de relación lo impide.

Si cambia la relación entre Date y Sales habilitando el filtrado bidireccional, entonces el resultado será el que se muestra en la Figura 1-4.

FIGURA 1-4
FIGURA 1-4 Si habilita el filtrado bidireccional, la tabla Date se filtra utilizando la columna Color.

Como se puede ver, los números ahora son diferentes, reflejando el número de días en los que se vendió al menos un producto del color en particular. A primera vista, podría parecer que todas las relaciones deben definirse como bidireccionales, de manera que el filtro se propague en cualquier dirección y siempre devuelva resultados significativos. Como se verá más adelante, esta no es siempre la forma correcta de diseñar un modelo de datos. De hecho, dependiendo del escenario con el que se esté trabajando, se deberá elegir la propagación correcta de las relaciones.