Modelo de datos / esquema de estrella

[ethan_lim]

Hola a todos

Quería comprobar dos veces y obtener alguna opinión si tal modelo es apropiado / recomendado / correcto

Tengo el origen de tabla de SQL Server que actúa como mis orígenes de datos para mis tablas de dimensiones y hechos.

De hecho, la tabla 1, cada registro es único. Cada uno de estos registros únicos tiene un registro secundario.

Los registros secundarios son en la tabla 2, cada registro secundario en Fact 2 es único con su correspondiente clave externa de vinculación de vuelta a la tabla de hechos 1.

La tabla de hechos 1 contendrá el Documento A, B

La tabla de hechos 2 contendrá la sublí línea A1,A2,B1

por ejemplo, Documento A -> subrela A1

Documento A -> subrelí A2

Documento B -> subrelí B1, etc.

El documento A puede tener 5 partidas individuales, el documento B puede tener 3 partidas individuales, el documento C puede tener 0 sublísmas

Siguiente nivel para la Tabla de hechos 3, cada elemento de sublínea puede tener varios elementos de sección. Cada sublínea puede tener 0 o más de las mismas secciones, pero cada línea de subenline identifica de forma única a sus secciones correspondientes a través de otro vínculo de clave externa.

E.g

Documento A -> subreline A1 -> sección X

Documento A -> subrelí A1 -> sección Y

Documento A -> subreline A1 -> sección Z

Documento A -> subrelí A2 -> sección A

Documento A -> subreline A2 -> sección B

Documento B -> subreline B1 -> sección X

Documento B -> subrelí B1 -> sección Z

Documento C -> subrelí C1 -> null o N/A

Estoy construyendo 2 informes, el informe 1 sólo necesitaría datos de FACT 1 y FACT 2, mientras que el informe 2 necesitaría datos de FACT 1,2,3.

Pregunta -

1. En el esquema de estrella, sé que no se recomienda unir las relaciones FACT a FACT, pero está bien si la relación está definida correctamente.

2. ¿Cómo debería haber diseñado mis tablas FACT, pensé en unir FACT 1,2,3 en 1 repetido padre-hijo tipo FACT, pero cuando pensé en el escenario a continuación:

donde el sublínea de FACT 2 puede tener 1 a muchos relaciones con otro atributo de subline en FACT 4 con su propio enlace de clave externa. La sección de FACT 3 no tiene ninguna relación con el atributo en FACT4.

4 escenarios posibles:

subline A -> muchas secciones, 0 atributos

subline A -> 0 secciones, muchos atributos

subline A -> muchas secciones, muchos atributos

subline A -> 0 secciones, 0 atributos

Estoy pensando que tener 1 estructura FACT padre-hijo no funcionaría en este caso porque no hay ninguna relación entre 3 y 4.

¿Aprecia los consejos sobre si las relaciones FACT a FACT (múltiples FACT > 2) son apropiadas para este escenario de datos?

Actualmente, estoy teniendo este hecho de relación y soy capaz de crear mis informes, pero no estoy seguro de si esto es apropiado para ser un esquema de estrella entonces.

[dedelman_clng · Accepted solution]

Hola @ethan_lim -

¿Escribió mal las relaciones entre el Hecho 1 y el Dim 1-4? Por lo general Dim-to-Fact es de 1 a muchos (los tienes todos como varios a 1)

Suponiendo que se trata de un error tipográfico, en Power BI, no hay realmente una distinción física entre las tablas Dimension y Fact, solo cómo se usan una vez en el modelo de datos. El esquema parece que debería para los datos de hechos que son primarios/secundarios/secundarios (por ejemplo, Factura --> Pedido de compra --> Línea de pedido de compra).

Espero que esto ayude

David

[PaulDBrown]

@ethan_lim

basado en su descripción, me atrevería a que las tablas DIM en la representación son redundantes

[ethan_lim]

Hola Pablo,

Gracias por responder,

¿Por qué las dimensiones serían redundantes en este caso, no se seguirían utilizando las dimensiones para filtrar en el modelo?

[PaulDBrown · Accepted solution]

@ethan_lim

Puedes conservarlos si lo deseas, pero como tus tablas ya están vinculadas por relaciones de uno a varios, realmente no las necesitas. Puede utilizar las columnas reales en filtros/cortadores/medidas tal cual. Los filtros y las segmentaciones de datos contienen valores distintos por definición.

Ino sería diferente si necesitara "puentear" tablas usando un campo común, o si las tablas no permitieran relaciones de uno a varios, pero ese no parece ser su caso.

Dicho esto, si sus datos contienen fechas, la creación de una "Tabla de fechas" (como una tabla de dimensiones) se considera una "mejor práctica" y (consenso general) un "debe tener" (especialmente importante si va a utilizar las funciones de Time Intelligence).

La "Tabla de fechas" debe incluir fechas consecutivas (y cualquier otra columna: mes, nombre del mes, año, etc.) y cubrir todo el rango de fechas incluidas en el conjunto de datos.

[dedelman_clng · Accepted solution]

Hola @ethan_lim -

¿Escribió mal las relaciones entre el Hecho 1 y el Dim 1-4? Por lo general Dim-to-Fact es de 1 a muchos (los tienes todos como varios a 1)

Suponiendo que se trata de un error tipográfico, en Power BI, no hay realmente una distinción física entre las tablas Dimension y Fact, solo cómo se usan una vez en el modelo de datos. El esquema parece que debería para los datos de hechos que son primarios/secundarios/secundarios (por ejemplo, Factura --> Pedido de compra --> Línea de pedido de compra).

Espero que esto ayude

David

[ethan_lim]

Hola @dedelman_clng

Gracias por responder,

Sí, es un error tipográfico de mi parte.

Gracias por su opinión, como estaba pensando en el esquema de estrella estándar, copo de nieve, donde por lo general no vamos a conectar demasiados hechos entre sí, especialmente en las relaciones padre / hijo y quería comprobar que no estaba haciendo algo "mal" o fuera de los estándares.

Pero de acuerdo, que PBI proporciona la flexibilidad si se pueden definir las relaciones adecuadas.

Una vez más, gracias por su entrada.