Find everything you need to get certified on Fabric—skills challenges, live sessions, exam prep, role guidance, and more. Get started
Hola a todos,
Estoy trabajando en un modelo de datos que incluye varias tablas de búsqueda que deben comunicarse entre sí en ambas direcciones.
1 - Aplicaciones (ID de la aplicación, estado, división, propósito)
2 - Servidores (ID del servidor, nombre del servidor, estado, condición)
3 - Servicios (ID de servicio, nombre del servicio, división, rango)
4 - Subservicios (ID de subservicio, ID de servicio, nombre del subservicio, impacto)
Un servicio tiene muchos subservicios. Un subservicio tiene muchas aplicaciones. Una aplicación puede tener muchos servidores.
Las tablas matriciales que están en el tablero deben leerse correctamente si hago clic en cualquier aplicación o cualquier servidor o cualquier servicio o cualquier subservicio y mostrar los detalles basados en el nombre seleccionado de cualquiera de las 4 opciones sobre las que el usuario necesita ver una actualización.
Por ejemplo, si el usuario seleccionó la aplicación Z, todos los servidores, servicios y subservicios de la aplicación Z deben mostrarse. Si el usuario seleccionó el Servidor A, debería suceder lo mismo. Si el usuario desea ver en función de los subservicios y hace clic en el subservicio X, debería ver todos los nombres de servicio, todas las aplicaciones y todos los servidores que se aplican.
Para cumplir con este escenario, descubrí que la mejor manera es crear una tabla de puente que conecte las coincidencias de los identificadores de cada una de las tablas de búsqueda. Luego, he conectado cada una de las tablas con una relación de uno a muchos. También he hecho que la relación sea bidireccional para aplicaciones, servidores y subservicios.
Mi pregunta aquí es que probé el escenario que expliqué anteriormente para ver si las tablas se comunican entre sí correctamente y se veía bien, sin embargo, todavía tengo dudas sobre si este modelo de datos es adecuado y las relaciones que establezco no se estropearán cuando el volumen de datos aumente. Además, no estoy seguro de cuánto puede ser escalable este modelo de datos para el futuro en caso de que necesite agregar más tablas de hechos.
Cualquier idea y opinión sería apreciada, ya que no quiero construir el modelo y luego descubrir que no es el mejor enfoque.
@kalkhudary , Idealmente el servidor debería ser usted Hecho. No estoy seguro de cómo se conectó con la aplicación.
El servicio y el subservicio deben combinarse y dar una dimensión y unirse con el servidor.
El calendario debe unirse con el servidor
@amitchandak Las aplicaciones son la tabla de hechos principal en este escenario, ya que actúa como una dependencia de los servidores y subservicios.
Puedo combinar el servicio y el subservicio y conectarlos a las aplicaciones, sin embargo, me preocupaba que no funcionara correctamente con el requisito bidireccional. Es por eso que pensé que una mesa puente disminuirá el riesgo y hará que la relación bidireccional sea más óptima.
Este modelo de datos es el más complicado y desafiante, ya que el requisito principal recae en la lectura de datos de un lado a otro.
¿Qué te parece?
Hola, @kalkhudary
El diseño de su modelo de datos suena muy bien organizado, especialmente al unir los ID de las tablas de búsqueda individuales a través de una tabla puente, lo que garantiza la comunicación bidireccional y la coherencia de los datos.
A continuación, se ofrece una breve descripción general de las limitaciones de tamaño del modelo semántico:
Además, el tamaño máximo del modelo semántico puede ser de hasta 100 GB cuando se usa una licencia de Power BI Premium por usuario (PPU).
Estos límites son para cada modelo semántico individual, no para la suma de todos los modelos. Por lo tanto, si tiene varios modelos, el límite de tamaño para cada modelo es independiente.
Espero que mis sugerencias le den buenas ideas, si tiene más preguntas, aclare en una respuesta de seguimiento.
Saludos
Fen Ling,
Si esta publicación ayuda, considere Acéptalo como la solución para ayudar a los demás miembros a encontrarlo más rápidamente.