Diseñar jerarquías de dimensión: natural o no natural

Question

Estoy usando Analysis Services y, al diseñar las dimensiones, nunca estoy seguro de qué tan lejos llegar para construir jerarquías naturales.

Lo que quiero decir es que he agregado todas las relaciones de atributos originales. Entonces, la mayoría de las jerarquías son naturales, pero la jerarquía más comúnmente solicitada es 3 o más niveles con un nivel medio como un atributo que cambia lentamente.

El escenario es el seguimiento de trabajos. El trabajo tiene muchos atributos que son estáticos, pero el atributo Deudor (es decir, quién paga la factura) puede cambiar a lo largo del trabajo. Por lo que las jerarquías se ven así

- Manager -> Debtor -> Job Name 
- Director -> Debtor -> Job Name 
- Office -> Debtor -> Job Name 
- Office -> Manager -> Debtor -> Job Name 

así que dentro de la dimensión hay muchas jerarquías que se inician con el atributo estático (s) del trabajo, seguido del deudor (wich cambia lentamente) con el nombre del trabajo (tecla de dimensión) a El fondo.

Entonces, lo que hacemos en este momento para "naturalizar" estas jerarquías es crear atributos "falsos" para cada deudor que aparece en una jerarquía que es una combinación de los atributos que están sobre él. p.ej. para el primer ejemplo anterior, el atributo de nivel deudor tendría una clave de administrador y deudor. Y para el último ejemplo, el nivel de Administrador tendría una clave de Administrador y Oficina y el atributo de nivel de Deudor tendría una clave de Office, Administrador & Deudor. Luego, ocultamos todos estos atributos para que solo se utilicen en las jerarquías.

Esto hace que nuestras dimensiones sean mucho más complicadas, pero obtenemos el beneficio de un rendimiento extra en nuestras consultas. A menudo esta es una mejora notable. Además de la complejidad, constantemente nos topamos con problemas porque ahora tenemos múltiples versiones de un "Deudor" y la clave del atributo no es la identificación del deudor. Por lo tanto, esto afecta las acciones de obtención de detalles e informes, además de dificultar ciertos tipos de cálculos si queremos cambiar el comportamiento de ciertos niveles.

Los clientes que utilizamos son Reporting Services, Excel y Office Web Components.

Me han dicho que en las primeras versiones de SQL 2005 las consultas complejas que implican jerarquías no naturales pueden provocar que el servidor quede completamente atado en nudos, razón por la cual nos hemos esforzado mucho para evitar jerarquías no naturales.

Además, la advertencia de diseño de signo de exclamación es tan dramática en Visual Studio que parece algo realmente malo tener jerarquías antinaturales.

¿Qué hacen otros diseñadores en estas situaciones? ¿Qué tan lejos vas para evitar jerarquías antinaturales?

Answer 1

La forma de hacer jerarquías en una dimensión que cambia lentamente en un cubo SSAS consiste en sintetizar una pseudo-jerarquía con claves reales ocultas detrás de las escenas pero solo mostrando los atributos como si fueran claves.

Office  Manager DebtorKey Debtor  JobKey Job Name From  To 
Scunthorpe Bloggs  101  Scarper&Co 2001  Fixit  2010-01-01 2010-01-31 
Scunthorpe Bloggs  102  Bodgett  2002  Fixit  2010-02-01 9000-01-01 

Esta jerarquía se construye sobre la dimensión original de cambio lento y se utiliza para hacer las relaciones de los atributos. Desea que los niveles en una jerarquía tengan las relaciones de atributo adecuadas. IIRC estos son necesarios para que el cubo realice la optimización 'Autoexists' (resuelva el no vacío simplemente desde la dimensión antes de tocar la tabla de hechos), que es la razón por la cual el cubo es lento cuando estas relaciones no están configuradas.

Puede que tenga que aplicar la jerarquía a la dimensión en SQL antes de construir el cubo. Ciertamente, si desea cargar actualizaciones, las claves deberán permanecer estáticas, aunque si tiene tiempo para hacer una actualización completa, puede que no sea necesario.