Forum Discussion
Modelo de datos / esquema de estrella
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
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.
Community Championbasado en su descripción, me atrevería a que las tablas DIM en la representación son redundantes
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
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.