Construcción de la capa semántica en PBI

[Syndicate_Admin]

Actualmente tenemos un unv de Business Objects (~ 900 tablas) y en base a eso se crean 200+ plantillas que en su mayoría son parámetros de entrada del usuario. Ahora estamos haciendo la transición a PBI, que para mí es un gran cambio, mis preguntas:

1. ¿Debería construir un modelo semántico en PBI y luego crear estas plantillas o debería abordar cada informe individualmente?

2. ¿Puedo usar el SQL (generado en Bus Obj Query) que es complejo con múltiples parámetros y usarlo en una consulta directa y generar un informe con los valores de entrada del usuario?

3. ¿Puede PBI manejar parámetros dinámicos definidos por el usuario en SQL? La mayor parte de la carga debe ser manejada por el origen de datos y no por PBI.

Gracias.

Agradezco sus comentarios.

[Syndicate_Admin]

Hola @rnola16 - Tienes razón: pasar de Business Objects (BOBJ) UNV a Power BI es un gran cambio, especialmente con 900 tablas y 200+ plantillas.

Identifique las tablas y relaciones principales:

acercarse:

Comience con un enfoque de esquema en estrella en lugar de tratar de replicar toda la estructura del programa VNU.
Aplanar uniones complejas siempre que sea posible.
Control de parámetros en Power BI

Los objetos de negocio dependen en gran medida de los parámetros: deberá diseñarlos de forma diferente en Power BI (por ejemplo, segmentaciones, variables DAX o procedimientos almacenados).
Migración por fases

Identifique los informes de alta prioridad y migre primero.
Valide los KPI, las medidas y los cálculos.

2. ¿Puede usar SQL (generado en Business Objects Query) en DirectQuery y pasar entradas de usuario?

acercarse:

Convertir BOBJ SQL en vistas de base de datos

En lugar de insertar SQL en Power BI, cree vistas optimizadas en el origen de datos.
A continuación, Power BI puede DirectQuery estas vistas con filtros de usuario.
Procedimientos almacenados para consultas complejas

Si necesita un filtrado intensivo o cálculos dinámicos, considere la posibilidad de usar un procedimiento almacenado.
Puede llamar a procedimientos almacenados en Power BI mediante parámetros (aunque requiere scripts de Power Query M).

3. ¿Puede Power BI controlar parámetros dinámicos definidos por el usuario en SQL?

acercarse:

Uso de segmentaciones de Power BI para el filtrado en lugar de parámetros SQL

DirectQuery puede filtrar sobre la marcha sin modificar SQL.
Mantenga el filtrado en el nivel visual/de informe en lugar de en SQL.
Parámetros de consulta M dinámicos (si son compatibles con la fuente de datos)

Si la base de datos admite parámetros de consulta M, puede usarlos para el filtrado dinámico en DirectQuery.
Esto no es tan flexible como BOBJ, pero funciona para muchos casos.
Aproveche las vistas en lugar de SQL dinámico

Cree una vista por caso de uso de informe principal con las combinaciones y agregaciones necesarias.

Espero que estos detalles te ayuden.