Es bastante común tener varios atributos en una dimensión que describen lo mismo: los productos pueden tener descripciones largas y cortas, por ejemplo, o puede mostrar fechas en diferentes formatos, o mostrar nombres completos de estados o solo sus abreviaturas. . AS no le brinda ninguna funcionalidad para manejar esto específicamente; algo que escuché de personas que han usado otras herramientas OLAP es que sería genial configurar «alias» para atributos, en lugar de configurar traducciones, así que solo necesita diseñarlo en su dimensión. Sin embargo, una cosa que he notado es que cuando se diseñan relaciones de atributos para cumplir con este escenario, existe la tentación de hacerlo de una manera particular que conduce a problemas más adelante; al menos he hecho esto en el pasado y he visto a otras personas haciendo lo mismo, así que pensé que valía la pena escribir un blog.

Este es un ejemplo de una dimensión de tiempo basada en datos relacionales de Adventure Works:

Tenemos una estructura simple Año-Trimestre-Mes-Fecha, pero queremos ver la misma estructura una vez con una breve descripción (por ejemplo, «2004» para el año) y otra vez con una descripción larga (por ejemplo, «Calendario año 2004»). Hay dos jerarquías de usuarios naturales que reflejan estas dos opciones, pero tenga en cuenta la forma en que se diseñan las relaciones de atributos: no tienen en cuenta que existe una relación de uno a uno entre los dos conjuntos de atributos. Si utiliza La excelente función ‘Visualizar retícula de atributos’ de BIDS Helper se puede ver las relaciones forman una bifurcación:

forklattice

¿Qué está mal con eso? Bueno, en lugar de responder esa pregunta, veamos mi alternativa preferida:

tiempo de deformación

Aquí está la red de apoyo:

enrejado de cadena

Puede ver que en lugar de una forma de tenedor, ahora tenemos una cadena larga y las relaciones uno a uno que mencioné anteriormente ahora están en su lugar; recuerde que esto no afecta la apariencia de la dimensión para el usuario final. Por cierto, es posible que se pregunte, como lo hice yo, si la propiedad Cardinalidad de una relación debería cambiarse de ‘Muchos’ a ‘Uno’ para las relaciones uno a uno: probablemente valga la pena, pero según BOL no es así. en este momento:
http://msdn2.microsoft.com/en-us/library/ms176124.aspx

Las ventajas de este diseño son:

  • Autoexiste más eficiente. En el enfoque de bifurcación, si interseca Año con Mes largo Desc, AS tendrá que resolver esta relación a través del atributo Fecha; en el enfoque de cadena, debido a que existe una relación directa entre los dos, determinar qué miembros de Month Long Desc existen con Year será más rápido. Probablemente solo lo notará en dimensiones bastante grandes. ACTUALIZACIÓN: vea el comentario de Mosha a continuación, esto no es correcto.
  • En general, creo que el asistente de diseño de agregación producirá mejores diseños con el enfoque de cadena. Nuevamente, no sé qué diferencia habrá realmente, pero cuando ejecuté el asistente en un cubo de prueba que solo contenía mi dimensión de bifurcación, apareció con tres agregaciones en Month/Quarter Long Desc; Descripción larga del mes/trimestre; y Año. Cuando hice lo mismo en un cubo de prueba que contenía solo mi dimensión de cadena, obtuve cuatro agregaciones en Mes; Trimestre; Año; y todo. En el último caso, por supuesto, la jerarquía Calendar Long Desc puede beneficiarse de las agregaciones creadas en los atributos que no son Long Desc y, en general, la cobertura de agregación se ve mejor. Sin embargo, los resultados pueden variar en el mundo real…
  • Los cálculos de rango se vuelven mucho, mucho más fáciles con el enfoque de cadena en lugar del enfoque de bifurcación. Imagine que desea implementar algo como un cálculo Total hasta la fecha, que suma una medida desde el inicio de Time hasta el miembro actual de Time. Naturalmente, desea que esto funcione en sus dos jerarquías de usuarios, pero descubrirá que con el enfoque de bifurcación se vuelve diabólicamente difícil obtener el alcance correcto: es mucho más difícil de lo que piensa, y de hecho no encontré una solución satisfactoria. solución. Sin embargo, con el enfoque de la cadena, existe una solución muy elegante: debido a las fuertes jerarquías, cada miembro que seleccione en la jerarquía del calendario obliga automáticamente al miembro actual de la jerarquía Calendar Long Desc al equivalente: por lo tanto, seleccionando ‘2004’ en Calendar cambia el miembro actual en Calendar Long Desc a ‘Calendar Year 2004’. Esto significa que puede extender todos sus cálculos en la jerarquía de usuarios Calendar Long Desc y funcionarán automáticamente en la jerarquía Calendar; por ejemplo, aquí está cómo hacer el cálculo de TTD:

Cree el miembro CurrentCube.Measures.TTD como nulo;

Alcance (Medidas.TTD);
Alcance([ForkTime].[Calendar].Miembros, [ForkTime].[Calendar Long Desc].miembros);
Esto=suma({nulo:[ForkTime].[Calendar].miembro actual}, [Measures].[Sales Amount]);
Alcance final;
Alcance final;

(Gracias a Richard Tkachuk por responder a algunos correos electrónicos sobre estos temas)