usuario - ¿Propósito y efecto de las jerarquías SSAS?

roles de usuarios en base de datos

Question

En primer lugar, me siento cómodo con lo que es una jerarquía en términos del concepto y cómo afecta el diseño del esquema en estrella de un DW. Tengo algunas dimensiones con muchos atributos y podría crear muchas jerarquías dentro de SSAS. Me gustaría comprender mejor cómo el motor OLAP usa las jerarquías que creo para poder tomar una decisión más informada sobre cómo diseño mis jerarquías (es una palabra difícil de escribir las primeras veces). También hay limitaciones con SSAS con respecto a los atributos que aparecen en múltiples jerarquías, por lo que a veces tengo que hacer un trabajo adicional para solucionar esas limitaciones o decidir qué jerarquía es más importante.

También me pregunto qué impactos negativos podría tener una jerarquía, como hacer que la dimensión sea más confusa para los usuarios. Podría ocultar los atributos que se incluyen en las jerarquías para eliminar el atributo duplicado y hacer que la dimensión sea menos confusa. Pero luego, un usuario desea ver en qué meses del año normalmente obtiene más ventas. Si he ocultado el atributo del mes para que solo esté disponible a través de la jerarquía Año-> Mes, ¿se ven obligados a incluir siempre la parte Año de la jerarquía, lo que les impide realizar dicho análisis?

Algunos artículos sobre jerarquías han declarado algo como el efecto de "permitir al usuario profundizar en datos detallados". Lo que es engañoso, ya que simplemente puede arrastrar los atributos de año y mes a un informe y lo ha logrado sin el uso de una jerarquía. Así que tal explicación es un poco superficial. Siento que debe haber mucho más que eso.

Algunos artículos parecen sugerir que determina si los atributos se consideran para la agregación o no. Esto parece contrario a la intuición, porque pensé que eso ya ocurre cuando incluiste un atributo en un cubo. Me refiero a que el objetivo principal de crear un cubo que consiste en atributos es tener una intersección de todos los atributos para que pueda agregar rápidamente cualquier combinación de ellos, así que me confunde cuando algo implica lo contrario a eso diciendo solo atributos En jerarquías se consideran para la agregación:

Los atributos solo expuestos en las jerarquías de atributos [a diferencia de las jerarquías de usuario] no son considerados automáticamente para la agregación por el Asistente de diseño de agregación. Las consultas que involucran estos atributos se satisfacen al resumir los datos de la clave principal. Sin el beneficio de las agregaciones, el rendimiento de las consultas con estas jerarquías de atributos puede ser lento. -SSAS 2008 Guía de rendimiento

¿Puede alguien explicar cómo el motor usa mis jerarquías en contraste con solo incluir el atributo en el cubo? (Además de la estética de agrupar atributos).

Las jerarquías antinaturales son tan confusas como para mí en particular. En la Guía de rendimiento de SSAS 2008, se muestra un ejemplo como una jerarquía de género y educación. Creo que mis usuarios murmurarían "programadores estúpidos" cada vez que tuvieran que explorar Género solo para llegar a la Educación.

¿Qué racional sigues cuándo y cuándo no para crear una jerarquía?

Answer 1

No estoy seguro del 100% de los comentarios que diré que se aplican a SSAS, pero como ambos somos compatibles al 100% con MDX / XMLA, es similar.

Puede comenzar leyendo this y la documentación de muchos a muchos .

La primera diferencia entre usar jerarquías con niveles y atributos es el rendimiento. Tiene dos escenarios diferentes para un desglose (tome a [Asia] como miembro particular y encontremos todos los países de [Asia]):

• Usando la jerarquía con niveles: [Asia] .children ()
• Usando atributos: ([Asia], [Países])

La primera opción es trivial y muy rápida (la estructura está en la memoria). El segundo implica iterar a través de todos los países y "verificar" si existen (también conocidos como países de [Asia]). Esto puede ser un dolor para grandes atributos (> 100k). Una vez hecho esto, debemos ir a nuestras tablas de hechos donde cada miembro tiene un conjunto de filas de datos asociadas. La versión con una sola jerarquía es de nuevo directa. El uno con dos podría implicar algunas operaciones internas adicionales -> todas las filas de [Asia] menos las de un país en particular. La versión simplificada también es más útil para el caché.

En segundo lugar, define una ruta de desglose ''natural'' que se puede usar directamente en la GUI.

En la parte superior, puede agregar tipos de agregaciones especiales (primero, último, mínimo, máximo ...) que tendrán en cuenta la estructura de una jerarquía determinada.

Existen soluciones OLAP exitosas que funcionan sin estructuras jerárquicas, pero tiene menos características con las que jugar para hacer una solución.

Espero que te ayude a entender mejor estos conceptos.