¿Cuáles son algunas formas de implementar una relación de muchos a muchos en un almacén de datos?

Las topologías dominantes del modelado de Data Warehouse (Star, Snowflake) están diseñadas con relaciones de uno a muchos en mente. La legibilidad de la consulta, el rendimiento y la estructura se degradan severamente cuando se enfrentan a una relación de muchos a muchos en estos esquemas de modelado.

¿Cuáles son algunas formas de implementar una relación de muchos a muchos entre dimensiones o entre la tabla de hechos y una dimensión en un almacén de datos y qué compromisos infligen con respecto a la granularidad necesaria y el rendimiento de las consultas?

En mi experiencia, una jerarquía recursiva es la forma más práctica de abordar esto. Ofrece las siguientes ventajas:

1. Profundidad ilimitada.
2. Compacidad
3. Flexibilidad.
4. Velocidad.

Por el contrario, se necesita una tabla adicional para cada nivel de uniones "a muchos". Esto está codificado y es difícil de mantener con las actualizaciones de esquema.

Mediante el uso de índices filtrados, una gran tabla de combinaciones jerárquicas puede funcionar a una velocidad superior a las tablas dedicadas. La razón es que cada combinación es solo "padre-hijo" en comparación con "unir tabla a tabla de datos". Este último tiene más índices para procesar y almacenar.

He tratado de resolver este problema durante muchos años. Recientemente, esto es lo que se me ocurrió.

Algunos escenarios para las relaciones M: M en un modelo de almacén de datos

La mayoría de los servidores OLAP y los sistemas ROLAP tienen un medio para lidiar con las estructuras de datos M: M ahora, pero hay algunas advertencias sobre esto a las que deberá prestar atención. Si implementa relaciones M: M, deberá vigilar su capa de informes y las herramientas que desea admitir.

Escenario 1: dimensión M: M en una tabla de hechos

Un ejemplo de esto podría ser múltiples conductores en una política de motor. Si agrega o elimina un controlador, la transacción de ajuste de la política puede tener una relación con una lista de controladores que cambia con el ajuste.

Opción 1: tabla de puente M: M driver-fact Esto tendrá un gran volumen de datos, ya que tiene controladores x filas de transacciones para una política determinada. SSAS puede consumir esta estructura de datos directamente, pero es más lento consultar a través de una herramienta ROLAP.

Si su relación M: M se basa en entidades que son específicas de la fila de hechos (p. Ej., Conductores en un automóvil), esto también podría ser apropiado para una herramienta ROLAP, siempre que su herramienta ROLAP admita relaciones M: M (p. Ej., Utilizando contextos en los negocios Objetos).

Opción 2: tabla de dimensiones de 'combinaciones' ficticias Si está asignando una lista de códigos comunes a una tabla de hechos (es decir, las entidades vinculadas no son peculiares de la fila de hechos), puede adoptar otro enfoque que reducirá los volúmenes de datos. Un ejemplo de este tipo de escenario son los códigos ICD en una visita hospitalaria. Cada visita de hospitalización tendrá uno o más diagnósticos y / o procedimientos de DAI enumerados en su contra. Los códigos ICD son globales.

En este caso, puede crear una lista distinta de las combinaciones de códigos en cada caso. Haga una tabla de dimensiones con una fila para cada combinación distinta, y tenga una tabla de enlaces entre las combinaciones y las tablas de referencia para los códigos ICD.

La tabla de hechos puede tener una clave de dimensión para la dimensión 'combinaciones', y la fila de dimensión tiene una lista de referencias a códigos ICD reales. La mayoría de las herramientas ROLAP pueden consumir esta estructura de datos. Si su herramienta solo funcionará con una relación M: M real, puede crear una vista que emule la relación M: M entre el hecho y la tabla de referencia de codificación. Este sería el enfoque preferido con SSAS.

Ventajas de la opción 1: - Las consultas indexadas adecuadamente, basadas en la selección de filas de la tabla de hechos con una cierta relación a través de la tabla M: M pueden ser razonablemente eficientes.

• Modelo conceptual ligeramente más simple

Ventajas de la opción 2: - El almacenamiento de datos es más compacto

• Puede emular una relación directa 1: M presentando las combinaciones en un formato legible por humanos como un código en la dimensión 'combinaciones'. Esto podría ser más útil en herramientas de informes más tontas que carecen de soporte para las relaciones M: M.

Escenario 2: relación M: M entre dimensiones:

Es difícil pensar en un caso de uso, pero uno podría imaginar algo fuera de la atención médica con los códigos ICD nuevamente. En un sistema de análisis de costos, la visita hospitalaria puede convertirse en una dimensión y tendrá relaciones M: M entre la visita (o el episodio del consultor en el discurso del NHS) y las codificaciones.

En este caso, puede configurar las relaciones M: M y posiblemente codificar una representación legible por humanos en la dimensión base. Las relaciones se pueden hacer a través de tablas de enlaces M: M o a través de una tabla de 'combinaciones' como antes. Esta estructura de datos se puede consultar correctamente a través de Business Objects o herramientas ROLAP de mejor calidad.

Fuera de mi cabeza, no puedo ver que SSAS pueda consumir esto sin llevar la relación directamente a la tabla de hechos, por lo que necesitaría presentar una vista de la relación M: M entre la codificación y la tabla de hechos filas para usar SSAS con estos datos.

Me gustaría saber exactamente qué tipo de relación de muchos a muchos tiene en mente en su modelo, ya sea en el sistema transaccional o en cualquier modelo de datos en el que se encuentre actualmente.

Típicamente, las relaciones de muchos a muchos entre dimensiones son hechos acerca de las dimensiones. El hecho de que un cliente ordena desde varias sucursales que atienden a muchos clientes, o algo así. Cada uno de esos es un hecho. Tendría una fecha de vigencia o algo así, pero la relación podría ser "sin hechos". La relación en sí misma puede tener otras dimensiones además del cliente y la sucursal. Por lo tanto, es un esquema de estrella típico con una tabla de hechos (potencialmente sin hechos) en el centro. La forma en que esta estrella puede relacionarse con otras estrellas dimensionales en el almacén obviamente dependerá. Cada vez que combine diferentes estrellas, lo haría en las teclas de negocios y tendrá que asegurarse de no realizar uniones cruzadas involuntarias.

Por lo general, no se informa sobre tales tablas de relación de dimensiones en el mismo grado que las tablas de hechos más grandes y, cuando lo hacen, no siempre son tantos datos, por lo que no tienden a afectar el rendimiento. En el caso anterior, puede observar la utilización del cliente / sucursal a lo largo del tiempo, pero mejores datos sobre las cantidades reales de pedido estarían disponibles en su tabla de hechos de pedido, que presumiblemente también tendría dimensiones para el cliente, sucursal, etc. la mayoría de la gente consideraría muchos a muchos (aunque se podría considerar un pedido para definir una relación de muchos a muchos de cliente a sucursal), por lo que son más típicos en entornos de almacenamiento de datos. Solo estaría haciendo agregados numéricos en modelos de muchos a muchos si hubiera acumulado información resumida a ese nivel de relación, es decir, cliente, sucursal, mes,

Aquí hay algunos artículos relevantes de Kimball y otros que pueden aplicarse para modelar una relación propuesta de muchos a muchos. Tenga en cuenta que una relación de muchos a muchos es un concepto en el dominio del problema / modelo lógico solamente. En un modelo OLTP normalizado, todavía se manejaría con una tabla de enlaces que, por supuesto, es de una a muchas en cada sentido. En un modelo de almacén de datos Kimball no normalizado, hay varias formas de hacerlo, una de las cuales básicamente trata esa tabla de enlaces como el hecho en el centro de una estrella. Otro es como una matriz de columnas de bandera.

En última instancia, la elección dependerá de qué es exactamente lo que está modelando, cómo está cambiando y cómo desea informar al respecto. Aquí es donde el modelado dimensional y el almacenamiento de datos en general divergen bruscamente del modelo normalizado. El modelo normalizado se concentra en las relaciones lógicas y teóricas en los datos, cuyo almacenamiento de datos siempre vigila los casos de uso realistas y se desnormaliza para que funcionen.

Modelado de jerarquías alternativas utilizando una tabla puente:

http://www.kimballgroup.com/wp-content/uploads/2012/05/DT62Alternative.pdf

Tres opciones para una relación de muchos a muchos (vinculada a las asignaciones numéricas de acciones; consulte los comentarios para obtener información interesante de un lado a otro)

http://www.pythian.com/news/364/implementing-many-to-many-relationships-in-data-warehousing/

Desafortunadamente, muchos artículos de la Semana de Información de Kimball / DBMS mag ya no tienen buenos enlaces ...

Una forma de resolver esto es tener una tabla de hechos con solo 2 columnas, de clave externa de las 2 dimensiones que tengan una relación de muchos a muchos.