Proveen de contexto a los datos provistos por las tablas fact, transformando los datos en información. Las tablas dimension contienen la información textual descriptiva asociada con los eventos medidos en los procesos de negocio. Las dimensiones suelen tener una relación directa con los conceptos de negocio más importantes.
Estas tablas proveen del contexto que describe "quién", "qué", "dónde", "cuándo", "cómo" y "por qué" asociado con el evento. Son tablas con gran cantidad de columnas (50 a 100), aunque naturalmente suelen ser unos pocos los realmente útiles. Suelen tener muy pocos registros.
Los atributos de estas tablas proveen la principal fuente de restricciones en consultas, agrupaciones y etiquetas de reportes. Los valores en estos atributos deben consistir en palabras reales y no en acrónimos confusos. Además es importante limitar en mayor medida el uso de códigos reemplazándolos por descripciones textuales. En caso los códigos tengan verdadero valor para el negocio, será necesario disponer de ellos junto con las descripciones textuales.
Es importante no intentar desnormalizar el modelo de datos con las jerarquías, que suelen repetir la misma información varias veces, pues la principal compensación será mejorar la simplicidad y accesibilidad.
Cada dimension tiene una llave primaría de una sola columna. Esta llave primaría es agregada a la tabla fact como llave foránea para lograr asociar el contexto descriptivo a las medidas presentes en la tabla fact. Es importante que la llave primaría de la dimension no sea la llave natural del sistema fuente, pues en ocasiones existirán múltiples registros en una dimension por cada llave natural, conforme ésta última cambie en el tiempo.
Una consideración especial está en la llave primaría de la dimension tiempo, en la que será mejor utilizar directamente un formato del estilo "yyyymmdd", pues expresa información muy importante, además de ser predecible y estable. En caso de requerir mayor precisión, una dimension adicional deberá ser creada para el manejor de horas, minutos, segundos, etc.
Las dimensiones contiene entre sus atributos distintas jerarquías, y todas estas jerarquías pueden convivir en la misma tabla dimension, siempre y cuando la profundidad de la jerarquía sea fija. Además cuando la profundidad varía ligeramente, también es posible esta misma aproximación. Por otro lado, cuando la variación de profundidad es demasiado variable se aconseja el uso de un atributo de texto almacenando un valor con una codificación definida que describa la jerarquía deseada.
Es una buen práctica evitar el uso de banderas con verdadero o falso, y reemplazar esto por textos descriptivos que tengan un sentido completo cuando se visualizan. Además si existen códigos con información compuesta es importante separar cada parte del código en su propio atributo descriptivo.
No se deben permitir atributos null, y estos deben ser reemplazos con texto descriptivos que expliquen la no aplicabilidad o la no disponibilidad.
Degenerated dimension
Cuando una dimension no contiene más información que propiamente su llave primaría. Por ejemplo, para una fact de ordenes, el número de orden.
Role playing dimension
Cuando la misma dimension debe ser referenciada múltiples veces en una tabla fact, con cada referencia como un rol diferente, es una buena práctica hacer referencia una vista sobre esa dimension de forma que las referencias sean independientes.
Junk dimension
Los procesos de negocio con eventos transaccionales suelen generar un conjunto de baja cardinalidad de banderas e indicadores que no tienen una pertenencia lógica a una dimension definida. Para estos casos es posible la creación de una dimension que combine estos atributos. Esta dimension debe contener solamente las combinaciones posibles.
Conformed dimension
Cuando distintas dimensiones contienen atributos con los mismos nombres y los mismos dominos, es posible generar una tabla derivada. Estas conformed dimensions proveen un punto de integración para distintas tablas fact.
Shrunken dimension
Son conformed dimension con un subconjunto de registros y atributos de la dimension base. Estas son necesarios cuando una aggregated fact table es creada.
Slow Changing Dimension
Cuando los atributos son alterados en la fuente, debemos decidir como esos cambios serán expresados en las tablas dimension.
Saludos,
Brian Estrada
Los atributos de estas tablas proveen la principal fuente de restricciones en consultas, agrupaciones y etiquetas de reportes. Los valores en estos atributos deben consistir en palabras reales y no en acrónimos confusos. Además es importante limitar en mayor medida el uso de códigos reemplazándolos por descripciones textuales. En caso los códigos tengan verdadero valor para el negocio, será necesario disponer de ellos junto con las descripciones textuales.
Es importante no intentar desnormalizar el modelo de datos con las jerarquías, que suelen repetir la misma información varias veces, pues la principal compensación será mejorar la simplicidad y accesibilidad.
Cada dimension tiene una llave primaría de una sola columna. Esta llave primaría es agregada a la tabla fact como llave foránea para lograr asociar el contexto descriptivo a las medidas presentes en la tabla fact. Es importante que la llave primaría de la dimension no sea la llave natural del sistema fuente, pues en ocasiones existirán múltiples registros en una dimension por cada llave natural, conforme ésta última cambie en el tiempo.
Una consideración especial está en la llave primaría de la dimension tiempo, en la que será mejor utilizar directamente un formato del estilo "yyyymmdd", pues expresa información muy importante, además de ser predecible y estable. En caso de requerir mayor precisión, una dimension adicional deberá ser creada para el manejor de horas, minutos, segundos, etc.
Las dimensiones contiene entre sus atributos distintas jerarquías, y todas estas jerarquías pueden convivir en la misma tabla dimension, siempre y cuando la profundidad de la jerarquía sea fija. Además cuando la profundidad varía ligeramente, también es posible esta misma aproximación. Por otro lado, cuando la variación de profundidad es demasiado variable se aconseja el uso de un atributo de texto almacenando un valor con una codificación definida que describa la jerarquía deseada.
Es una buen práctica evitar el uso de banderas con verdadero o falso, y reemplazar esto por textos descriptivos que tengan un sentido completo cuando se visualizan. Además si existen códigos con información compuesta es importante separar cada parte del código en su propio atributo descriptivo.
No se deben permitir atributos null, y estos deben ser reemplazos con texto descriptivos que expliquen la no aplicabilidad o la no disponibilidad.
Degenerated dimension
Cuando una dimension no contiene más información que propiamente su llave primaría. Por ejemplo, para una fact de ordenes, el número de orden.
Role playing dimension
Cuando la misma dimension debe ser referenciada múltiples veces en una tabla fact, con cada referencia como un rol diferente, es una buena práctica hacer referencia una vista sobre esa dimension de forma que las referencias sean independientes.
Junk dimension
Los procesos de negocio con eventos transaccionales suelen generar un conjunto de baja cardinalidad de banderas e indicadores que no tienen una pertenencia lógica a una dimension definida. Para estos casos es posible la creación de una dimension que combine estos atributos. Esta dimension debe contener solamente las combinaciones posibles.
Conformed dimension
Cuando distintas dimensiones contienen atributos con los mismos nombres y los mismos dominos, es posible generar una tabla derivada. Estas conformed dimensions proveen un punto de integración para distintas tablas fact.
Shrunken dimension
Son conformed dimension con un subconjunto de registros y atributos de la dimension base. Estas son necesarios cuando una aggregated fact table es creada.
Slow Changing Dimension
Cuando los atributos son alterados en la fuente, debemos decidir como esos cambios serán expresados en las tablas dimension.
- Type 0 - Retener original: El atributo nunca cambia.
- Type 1 - Sobreescribir: El atributo obtiene el última valor asignado sobreescribiendo el valor anterior. Sin embargo, es necesario entender que los resultados de datos agregados pueden variar en un re-cálculo.
- Type 2 - Agregar registro: Semejante a la estructura expuesta en los satellites. Ante un cambio en el valor de atributo, un nuevo registro es agregado a la dimension con el valor actualizado. Esto requiere la creación de una llave primaría alterna que no corresponda a la llave natural del sistema fuente. Cuando un nuevo registro es agregado, una nueva llave primaría es asignada y utilizada como llave foránea en las tablas fact, al menos hasta que un nuevo cambio se introduzca asignando una nueva llave primaría. Además un par de atributos se agregan: effective datetime, expiry datetime y current row indicator.
Saludos,
Brian Estrada