sql server - proper - Diseño de jerarquías de dimensión: natural o no natural.
que es un atributo en sql server (1)
Estoy usando Analysis Services y al diseñar dimensiones nunca estoy seguro de cuán lejos ir para crear jerarquías naturales.
Lo que quiero decir es que he agregado en todas las relaciones de atributo genuinas. Así que la mayoría de las jerarquías son naturales de todos modos, pero la jerarquía más comúnmente solicitada es de 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 todos estáticos, pero el atributo deudor (es decir, quién paga la factura) puede cambiar a lo largo del curso del trabajo. Así las jerarquías se ven así.
- Manager -> Debtor -> Job Name
- Director -> Debtor -> Job Name
- Office -> Debtor -> Job Name
- Office -> Manager -> Debtor -> Job Name
Entonces, dentro de la dimensión hay muchas jerarquías que comienzan con atributos estáticos del trabajo seguidos por el deudor (que cambia lentamente) con el nombre del trabajo (clave de dimensión) en la parte inferior.
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 se encuentran arriba. por ejemplo, para el primer ejemplo anterior, el atributo de nivel de Deudor tendría una clave de ID 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 Oficina, Administrador y Deudor. Luego, ocultamos todos estos atributos para que solo se usen en las jerarquías.
Por lo tanto, esto hace que nuestras dimensiones sean mucho más complicadas, pero obtenemos el beneficio de un rendimiento adicional en nuestras consultas. A menudo esto es una mejora notable. Aparte de la complejidad, constantemente tenemos problemas porque ahora tenemos varias versiones de un "Deudor" y la clave del atributo no es la identificación del deudor. Por lo tanto, esto afecta a las acciones de obtención de detalles e informes, además de dificultar ciertos tipos de cálculo si queremos cambiar el comportamiento para 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 involucran jerarquías antinaturales podrían hacer que el servidor se atara por completo a nudos, lo cual es otra razón por la que hemos hecho todo lo posible para evitar jerarquías antinaturales.
Además, la advertencia de diseño de signo de exclamación es tan dramática en Visual Studio que parece una cosa realmente mala tener jerarquías antinaturales.
¿Qué hacen otros diseñadores en estas situaciones? ¿Hasta dónde vas para evitar jerarquías antinaturales?
La forma de hacer jerarquías en una dimensión que cambia lentamente en un cubo SSAS es sintetizar una pseudojerarquía con claves reales ocultas detrás de las escenas, pero 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 que cambia lentamente y se utiliza para hacer las relaciones de atributo. 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 ''Autoexistir'' (resuelve la falta de vacío únicamente de la dimensión antes de llegar a la tabla de hechos), por lo que el cubo es lento cuando estas relaciones no están configuradas.
Es posible 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 realizar una actualización completa, esto puede no ser necesario.