Pregunta

Tenemos datos con dos orígenes diferentes: algunos provienen de un cliente, otros provienen de diferentes proveedores. Actualmente, físicamente " fusionamos " esta información en una tabla masiva con casi cien columnas, decenas de miles de filas y sin separación formal de las dos dimensiones. En consecuencia, no podemos usar esta tabla por mucho.

Voy a rediseñar este lío para convertirlo en un esquema en estrella adecuado, pero pequeño.

Las dos dimensiones son obvias. Uno de ellos, por ejemplo, es el tiempo.

Los datos proporcionados por el cliente proporcionan una serie de valores de hechos. Cada proveedor puede (o no) proporcionar valores de hechos adicionales que se ajusten a las mismas dimensiones.

Todos estos datos de hechos tienen la misma granularidad. Puede llamarse " disperso " porque a menudo no obtenemos información de todos los proveedores.

Aquí está mi dilema.

¿Es esta una tabla de hechos, con algunos nulos, rellenada desde diferentes fuentes?

¿O es esto n +1 tablas de hechos: una rellenada por el cliente, las otras por cada proveedor?

Hay pros y contras para cada diseño. Necesito algunas segundas opiniones sobre la elección entre " fusionar " o " cargar por separado " ;.


El cliente proporciona ingresos, costos, conteos, pesos y otras cosas que saben sobre el final de una transacción.

El proveedor uno proporciona algunos detalles adicionales sobre algunas de las transacciones: pesos, costos, duraciones. Las otras transacciones no tendrán ningún valor por parte del proveedor.

El proveedor dos proporciona algunos detalles adicionales sobre algunas de las transacciones: volúmenes, duraciones, longitudes, tasas de cambio de moneda extranjera. Las otras transacciones no tendrán valor para el proveedor dos.

Algunas transacciones tendrán ambos proveedores. Algunas transacciones no tendrán ningún proveedor.

¿Una mesa con nulos? ¿Tres tablas?

¿Fue útil?

Solución

Iría por la tabla de hechos individuales. Lo mejor de este enfoque es que deja todo el trabajo duro en el tiempo de carga en lugar de en el tiempo de consulta.

Otros consejos

Por lo que describe, suena como una única tabla de hechos es el camino a seguir.

Parece que la tabla de hechos tendría una gran cantidad de tiempo x transacción x cliente (?).

Mi pregunta anterior estaba realmente tratando de averiguar si algunos de los datos del proveedor eran candidatos para su propia dimensión. Te lo dejo a ti para determinar eso. pero en realidad no lo parece.

Los hechos nulos pueden generar advertencias durante las agregaciones (dependiendo de la plataforma), pero la alternativa de llenarlos con ceros posiblemente engañosos es peor.

Creo que dado que ambas fuentes comparten el mismo grano, la respuesta es que debe tener una tabla de hechos. Piense en cómo desea que sus usuarios finales interactúen con la información. Si tiene sentido y los informes comerciales se beneficiarán de la coubicación de esos datos, esa es su respuesta. Intenta evitar los nulos en tus tablas de hechos. Si puede ingresar un cero (y el cero tiene sentido para los datos, es decir, piense en la temperatura), hágalo. Le ahorrará a los usuarios cierta confusión y, como lo señaló TrickyNixon, causará problemas de agregación.

En realidad, estás en un gran punto aquí en la aplicación 'brownfield'. Puede ver lo que existe hoy y aprovechar la experiencia para crear un mejor diseño. Este es el momento más importante para seleccionar el mejor grano que, con suerte, no cambiará durante la vida útil del DW.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top