RLS para filtrar SOLO la tabla de dimensiones

[Syndicate_Admin]

Tengo una pregunta que me parece un caso de uso común, pero después de unas horas de buscar en Google y un sinfín de videos de youtube, de alguna manera no he encontrado la respuesta.

Tengo un modelo semántico (Microsoft Fabric, Direct Lake, identidad fija) con unas pocas docenas de tablas alrededor de una tabla de hechos central con datos de rendimiento (ingresos, ventas, horas, etc.). Dimensiones bastante estándar como clientes, oportunidades, proyectos, etc. El punto clave es que todos estos datos de rendimiento son en principio públicos para todos los que tengan acceso al modelo.

La excepción es que una de las tablas de dimensiones es a su vez una tabla de mapeo (denominada "informes de recursos humanos" a continuación) con identificadores que a su vez se vinculan a otras tablas de dimensiones con datos de personas. Algunos de ellos son públicos (visibles para todos, por ejemplo, el departamento o el cargo de la función) y otros se limitan a la línea jerárquica (por ejemplo, información del contrato, objetivos individuales o salarios) o incluso solo a RRHH (por ejemplo, datos sensibles a la privacidad). Se ilustra a continuación.

¿Cómo se configura RLS de tal manera que filtre solo las tablas de dimensiones privadas, pero no filtre la tabla de asignación "- Informes de RRHH"? Todavía quiero que las personas y sus datos públicos aparezcan, pero no su información privada.

El único caso que encontré que funciona es cuando la cardinalidad de una relación es N: N, en cuyo caso puedo cambiar la dirección del filtro a la inversa. Pero tampoco estoy seguro de que esto sea lo que quiero, ya que esto no permitiría a un gerente de línea seleccionar una dimensión en esa tabla para ver el rendimiento de solo las personas que cumplen con los criterios seleccionados.

Idealmente, evitaría hacer modelos semánticos duplicados, porque hay otras dos docenas de tablas y medidas correspondientes de las cuales una gran parte tendría que duplicarse y mantenerse. Al final, se trata de segmentar los datos de rendimiento, en los que los gerentes tienen más visibilidad para su propia línea de informes.

Así que... ¿No hay una opción de RLS "no en cascada a las relaciones" o algo por el estilo? ¿O necesito una configuración diferente para lograr lo que necesito?

Espero que puedas ayudar, gracias 🙂

[Syndicate_Admin]

Hola @raschaoot

Cuando RLS se aplica a una dimensión que tiene relaciones que fluyen a otras tablas, también se extenderá a esas otras tablas, por lo que no puede restringirlo solo a esa tabla de dimensiones.

[Syndicate_Admin]

Hola @raschaoot

El desafío principal es que en Microsoft Fabric (como en Power BI), los filtros de seguridad de nivel de fila se aplican en las relaciones activas del modelo. Esto significa que cuando se define un filtro en una tabla de dimensiones confidencial o "privada", ese filtro normalmente se propaga a las tablas relacionadas, incluida la tabla de asignación ("informes de RR.HH."), sin una opción integrada para detener la cascada.

En lugar de aplicar RLS en toda la tabla, puede considerar la posibilidad de crear medidas de DAX que prueben los permisos de usuario y devuelvan valores de forma selectiva. Este enfoque puede omitir la propagación de filtros no deseados

Si esto es útil, felicite y acepte la respuesta

[Syndicate_Admin]

Gracias por la respuesta. Al menos eso confirma mis sospechas, de lo contrario, habría habido una opción de "no filtro de seguridad en cascada" en la configuración de la relación.

Supongamos que un usuario extrae el tipo de contrato (un campo restringido): el usuario empresarial normal debería ver las dimensiones en blanco, pero aún así el total, mientras que un gerente debería ver la división para su propia línea de informes y un espacio en blanco para el resto. No puedo usar DAX para afectar a los valores de dimensión, ¿correcto (ya que las columnas calculadas no se ven afectadas, pero en cualquier caso serían demasiadas)? O, si me equivoco, ¿puede señalarme un ejemplo?

¡Gracias de nuevo!

[Syndicate_Admin]

• tiene razón en que no puede usar columnas calculadas por DAX en el modo Direct Lake. Esto se debe a que las columnas calculadas no se admiten en los modelos semánticos de Direct Lake debido a las restricciones de rendimiento y arquitectura
  
  

Solo un pensamiento

si es posible, mueva la lógica de los campos restringidos (por ejemplo, la visibilidad del tipo de contrato) a su almacén de datos o canalización ETL. Cree una columna que predefina si un usuario ve valores "en blanco" o reales en función de su rol.
•Por ejemplo:
• Agregue una columna como 'VisibleContractType' en la tabla de origen que genere el tipo de contrato (para administradores) o 'NULL'/en blanco (para usuarios normales).
• Esto evita la dependencia de columnas calculadas en Direct Lake y, al mismo tiempo, garantiza que la lógica se maneje de manera eficiente.

Si esto ayuda, acepte la respuesta y felicite

[Syndicate_Admin]

Hola, gracias por contribuir de nuevo. No estoy seguro de seguirlo.

Tengo muchos usuarios, cada uno con acceso a filas que dependen de otra tabla de asignación (la línea de informes, aún no visualizada), y la canalización en sí obviamente no es compatible con el usuario. ¿Su sugerencia implicaría que duplique los datos para cada posibilidad básicamente?

[Syndicate_Admin]

Hola @raschaoot ,

La sugerencia de nilendraFabric fue trasladar la lógica de los campos restringidos a un almacén de datos o a una canalización ETL y crear una columna para predefinir si un usuario ve valores reales o en blanco en función del rol del usuario. Esta es una excelente manera de evitar la dependencia de columnas calculadas en Direct Lake y, al mismo tiempo, garantizar que la lógica se controle de manera eficiente. Esta sugerencia no significa necesariamente que deba replicar los datos para cada posibilidad.

Puede crear una tabla de asignación en el almacenamiento de datos o en la canalización de ETL que contenga los roles de usuario y los tipos de contratos a los que pueden acceder. De esta manera, puede filtrar dinámicamente los datos en función de los roles de usuario en el momento de la consulta, sin tener que replicar los datos para cada posibilidad.

O bien, cree vistas en el almacén de datos para filtrar los datos en función de los roles de usuario. Las vistas pueden generar dinámicamente conjuntos de datos sin copiar realmente los datos.

Intente también preprocesar los datos en función de los roles de usuario durante el proceso ETL y almacenar los resultados en una nueva tabla. Esto garantiza que los datos se hayan filtrado en función de los roles de usuario cuando se cargan en el almacén de datos.

Saludos

Lucy Chen