Saltar al contenido
Caso prácticoSAP Datasphere

Caso práctico: la DAC de la dimensión aplicada al hecho en Datasphere

Paso a paso para que la seguridad por filas de una dimensión filtre también los hechos en SAP Datasphere, con datos de ejemplo y prueba con View as User.

Por 13 min de lectura
Diagrama de SAP Datasphere: una tabla de permisos alimenta una DAC aplicada a la dimensión de regiones, cuya asociación propaga la seguridad a la vista de ventas y al Analytic Model
Índice del artículo

La seguridad por filas en SAP Datasphere se monta con Data Access Controls (DAC). Lo natural es proteger la dimensión: “Ana solo ve las regiones Norte y Centro”. El problema es que proteger la dimensión no bastaba para proteger bien los hechos que cuelgan de ella por una asociación. En la wave 2026.6 (marzo de 2026) SAP añadió a la asociación hecho → dimensión la opción Apply Dimension Data Access Controls to Fact, que aplica la DAC de la dimensión directamente a los datos del hecho. En este caso práctico la montamos de cero y la comprobamos usuario a usuario sin necesitar más usuarios reales.

Qué vamos a construir

Un modelo de ventas por región, típico de una distribuidora con delegaciones. Al acabar tendrás:

  1. Una tabla de permisos T_PERM_REGION (usuario → región) y una DAC DAC_REGION de tipo Single Values sobre ella.
  2. Una dimensión V_REGION protegida con DAC_REGION.
  3. Una vista fact V_SALES con una asociación a V_REGION que propaga la DAC al hecho.
  4. Un Analytic Model AM_SALES, una prueba con View as User en la vista fact para tres usuarios ficticios y otra en el modelo con tu propio usuario.

Todos los nombres técnicos son de ejemplo: usa los de tu convención.

Por qué importa

SAP lo explica en una frase: sin esta opción, los usuarios pueden ver valores agregados nulos de registros que no tienen permiso para ver. En mi prueba se ve claro: la DAC filtra la dimensión, pero el hecho no la hereda. En la vista fact el usuario sigue viendo todas las ventas, y en el Analytic Model ve los importes de las regiones prohibidas con el nombre de la región a (Null). La alternativa sin esta opción es aplicar también la DAC en la vista fact o en el Analytic Model, y mantener el mapeo en dos sitios. Con la nueva opción, la regla vive en la dimensión y el hecho la hereda.

Paso a paso

  1. Paso:Sube los datos de ejemplo

    Descarga los tres CSV, con datos ficticios: regiones.csv, ventas.csv y permisos_region.csv.

    regiones.csv tiene cuatro regiones (NOR, CEN, SUR, EST). ventas.csv tiene 16 ventas, cuatro por región, que suman 22.450:

    Región Ventas Importe
    NOR 4 4.450
    CEN 4 6.050
    SUR 4 6.000
    EST 4 5.950

    La tabla de permisos asigna regiones a usuarios:

    permisos_region.csv
    USER_ID,REGION_ID
    TU_USUARIO,NOR
    TU_USUARIO,CEN
    TU_USUARIO,SUR
    TU_USUARIO,EST
    ANA.DEMO,NOR
    ANA.DEMO,CEN
    LUIS.DEMO,SUR

    Antes de subirlo, sustituye TU_USUARIO por tu ID de usuario de Datasphere, en el formato que use el proveedor de identidad del tenant. Es importante: un usuario que no aparece en la tabla de permisos no ve ningún registro en las vistas protegidas, y eso te incluye a ti. ANA.DEMO y LUIS.DEMO son ficticios; no hace falta que existan en el tenant.

    ¿Qué formato? No lo adivines: el editor de la DAC (paso 2) muestra un ejemplo con tu propio usuario debajo de Permissions Entity. En mi tenant de trial era el email en minúsculas, no el código USR… que ves en el nombre del espacio. Mi primera carga llevaba el código y tuve que rehacerla.

    En el Data Builder, abre el menú de importación de la barra de herramientas y elige Import CSV File para crear T_REGION, T_SALES y T_PERM_REGION. En el editor de importación, selecciona cada columna y abre Details para revisar el tipo. En mi prueba Datasphere detectó bien AMOUNT como Number y SALE_DATE como Date. Despliega cada tabla con su nombre técnico.

    Si ya subiste T_PERM_REGION con el ID equivocado, no hace falta borrarla: en el editor de la tabla, el botón Upload Data from CSV File abre el diálogo Import CSV File; marca Delete Existing Data Before Upload y sube el fichero corregido.

  2. Paso:Crea la DAC sobre la tabla de permisos

    En el Data Builder, elige New Data Access Control y rellena:

    Propiedad Valor
    Business / Technical Name DAC_REGION
    Structure Single Values
    Permissions Entity T_PERM_REGION
    Identifier Column USER_ID
    Criteria REGION_ID

    En la sección Criteria, Create añade una fila; en mi caso propuso directamente REGION_ID, la única columna que quedaba. Guarda y despliega. Con Single Values, cada usuario ve los registros que coinciden con cualquiera de los valores que tiene asignados: Ana, Norte o Centro.

    Si tu tabla de permisos llega compartida desde otro espacio, no la puedes usar directamente como permissions entity: encapsúlala antes en una vista de tu espacio.

    Editor de la DAC DAC_REGION desplegada: Structure Single Values, Permissions Entity T_PERM_REGION, Identifier Column USER_ID, el aviso con el formato de ID del proveedor de identidad (tapado) y REGION_ID en Criteria
    DAC_REGION desplegada. Debajo de Permissions Entity, el editor indica el formato de ID que espera (he tapado mi email).

  3. Paso:Crea la dimensión y protégela

    Crea una SQL View V_REGION:

    V_REGION.sql
    SELECT "REGION_ID", "REGION_NAME"
    FROM "T_REGION"

    Ponle Semantic Usage = Dimension, valida el SQL para que aparezcan los atributos y marca REGION_ID como clave (lápiz de Attributes, columna de la llave). Si quieres, REGION_NAME como texto de REGION_ID.

    En el panel lateral de la vista, baja a la lista Data Access Controls. Pulsa +, elige DAC_REGION y, en la sección Join, arrastra REGION_ID de la vista sobre el criterio REGION_ID de la DAC: en mi prueba no se mapeó solo, aunque las columnas se llaman igual. Cada criterio de la DAC tiene que quedar mapeado; si no, el filtro no funciona bien. Despliega.

    Panel lateral de V_REGION con DAC_REGION seleccionada: sección Join con REGION_ID de la vista unido al criterio REGION_ID de la DAC
    Join de DAC_REGION en V_REGION: REGION_ID de la vista unido al criterio de la DAC.

    Compruébalo ya en el Data Viewer de V_REGION con View as User (el icono de la persona en la barra del panel de datos): con ANA.DEMO solo salen CEN y NOR. La dimensión ya está protegida.

  4. Paso:Crea el hecho con la asociación (todavía sin la opción)

    Crea una SQL View V_SALES:

    V_SALES.sql
    SELECT "SALE_ID", "SALE_DATE", "REGION_ID", "AMOUNT"
    FROM "T_SALES"

    Ponle Semantic Usage = Fact, SALE_ID como clave y AMOUNT como medida (arrástrala a Measures). En la sección Associations, pulsa + > Association y elige V_REGION. Datasphere mapeó solo REGION_ID del hecho contra la clave REGION_ID de la dimensión.

    En el panel de la asociación, bajo To, ya ves la casilla Apply Dimension Data Access Controls to Fact. De momento no la marques: quiero que veas primero el comportamiento de antes. Despliega.

    Después crea el Analytic Model AM_SALES arrastrando V_SALES al lienzo. El diálogo de alta ya propone la dimensión asociada REGION_ID (V_REGION) y la medida AMOUNT. Despliégalo.

  5. Paso:Mira el «antes» con View as User

    En el editor de V_SALES, abre el Data Viewer, pulsa View as User, escribe ANA.DEMO y pulsa View.

    Resultado en mi prueba: Ana ve las 16 ventas, también las de SUR y EST, y el total sigue en 22.450. La dimensión la filtra, pero la vista fact no.

    Un detalle: View as User solo simula DAC desplegadas y aplicadas en el espacio actual. Si la vista viene compartida de otro espacio, no está disponible.

    En AM_SALES, que es donde SAP habla de valores agregados nulos, View as User no sirve. La ayuda dice que existe en el editor del Analytic Model; en mi tenant (octubre de 2026) solo aparece si seleccionas en el lienzo el fact source o la dimensión, y entonces el Data Viewer muestra los datos de esa vista (V_SALES o V_REGION), igual que si la abrieras en su editor. Con el modelo seleccionado, ni el Data Viewer ni Preview lo tienen.

    El truco es probar con tu propio usuario. Quítate temporalmente SUR y EST en T_PERM_REGION (vuelve a subir el CSV sin esas dos filas, con Delete Existing Data Before Upload). Abre AM_SALES en Preview y pon en filas REGION_ID y su atributo REGION_NAME (despliega REGION_ID en Available Objects).

    Preview de AM_SALES sin la opción, con un usuario que solo tiene NOR y CEN: CEN Centro 6.050, EST (Null) 5.950, NOR Norte 4.450 y SUR (Null) 6.000
    AM_SALES sin la opción y con mi usuario limitado a NOR y CEN: EST y SUR salen con REGION_NAME (Null), pero con sus importes.

    Esto es exactamente lo que describe SAP: la DAC oculta los registros de la dimensión, así que REGION_NAME sale como (Null) en EST y SUR, pero los importes del hecho siguen ahí y el total es 22.450. El usuario no sabe de qué región son, pero ve cuánto venden las regiones que no le tocan.

  6. Paso:Activa la propagación al hecho

    Vuelve a V_SALES, abre la asociación a V_REGION y marca Apply Dimension Data Access Controls to Fact. Despliega la vista.

    Panel de la asociación V_SALES to V_REGION con la casilla Apply Dimension Data Access Controls to Fact marcada y el mapeo REGION_ID a REGION_ID
    La asociación de V_SALES a V_REGION con la casilla marcada y el mapeo REGION_ID → REGION_ID.

    En el panel lateral de V_SALES, la lista Data Access Controls sigue con 0 DAC propias, pero ahora muestra DAC_REGION en la sublista Applied via Dimensions, con la nota Applied to V_REGION. Esa sublista es útil para revisar modelos heredados: te dice qué seguridad llega por asociaciones sin tener que abrir cada dimensión.

    Panel lateral de V_SALES: Data Access Controls (0) y, en la sublista Applied via Dimensions, DAC_REGION con la nota Applied to V_REGION
    V_SALES no tiene DAC propias, pero hereda DAC_REGION por la asociación.

    En AM_SALES no esperes ver el cambio. Su panel no tiene sublista Applied via Dimensions, y DAC_REGION aparece en Applied via Sources con V_REGION como origen, con la casilla marcada o sin ella: lo comprobé desmarcándola y volviendo a desplegar. Sale ahí porque V_REGION es una de las fuentes del modelo, no por la nueva opción. El Analytic Model siguió en estado Deployed después de cambiar la vista fact; no me pidió redesplegarlo.

    Donde sí se ve el cambio es en los datos. Repite el Preview de AM_SALES con tu usuario todavía limitado a NOR y CEN:

    Preview de AM_SALES con la opción activada y un usuario que solo tiene NOR y CEN: solo CEN Centro 6.050 y NOR Norte 4.450
    Con la casilla marcada, el mismo usuario solo ve CEN y NOR (10.500). Las filas (Null) desaparecen.

    Ahora el hecho hereda la DAC: solo salen CEN y NOR, y el total baja a 10.500. Cuando acabes, vuelve a subir el CSV con tus cuatro regiones. No hace falta redesplegar nada: el AM recoge los cambios de la tabla de permisos al recargar la página del navegador. Lo repetí dos veces más y lo cogió con un simple F5. Eso sí, una vez el Preview siguió mostrando el resultado anterior durante unos minutos, aunque V_SALES ya mostraba el nuevo; si te pasa, espera un poco y recarga.

Validación

Repite View as User en V_SALES con cada usuario. Si el Data Viewer muestra el error You can’t see data in a view protected by a data access control until all changes are deployed justo después de desplegar, cierra la vista y vuelve a abrirla desde el Data Builder: a mí se me quitó así. Este es el resultado que obtuve con los datos del CSV:

Usuario Regiones permitidas Ventas visibles Total AMOUNT
ANA.DEMO NOR, CEN 8 10.500
LUIS.DEMO SUR 4 6.000
MARTA.DEMO (no está en la tabla) — 0 —
Tu usuario Las cuatro 16 22.450

En AM_SALES, con mi usuario limitado a NOR y CEN, el Preview pasó de 22.450 con dos filas (Null) a 10.500 al marcar la casilla, igual que ANA.DEMO en la vista fact.

MARTA.DEMO es la prueba que más me gusta: confirma que quien no está en la tabla de permisos no ve nada. Es el comportamiento correcto y seguro, pero en proyecto genera incidencias de “no veo datos” el primer día. Si tu equipo carga los permisos desde un fichero de RR. HH. o desde un sistema de identidades, revisa antes que todos los usuarios activos tienen al menos una fila.

Data Viewer de V_SALES con View as User activo para ANA.DEMO: 8 ventas, solo de las regiones NOR y CEN
V_SALES vista como ANA.DEMO: 8 ventas, solo de NOR y CEN (10.500 en total). Antes de marcar la casilla veía las 16.

Errores habituales

Síntoma Causa Solución
Un usuario no ve ningún dato No tiene ninguna fila en la tabla de permisos Añádelo, aunque sea con una región. Ojo con tu propio usuario.
Tú no ves datos aunque estás en la tabla de permisos El ID no tiene el formato del proveedor de identidad Usa el formato que muestra el editor de la DAC (en el trial, el email en minúsculas) y recarga la tabla.
El Data Viewer pide desplegar aunque la vista ya está desplegada El editor no ha refrescado el estado tras el despliegue Cierra la vista y ábrela de nuevo desde el Data Builder.
Cambias la tabla de permisos y el Preview del AM no cambia El Preview sigue mostrando el resultado anterior Recarga la página del navegador; si no cambia, espera unos minutos y recarga otra vez. No hace falta redesplegar.
View as User no filtra nada La DAC no está desplegada, o se aplicó en otro espacio Despliega la DAC y la vista. View as User solo simula DAC desplegadas del espacio actual.
No puedes usar la tabla de permisos en la DAC La tabla viene compartida de otro espacio Crea una vista sobre ella en tu espacio y úsala como permissions entity.
La validación de datos de la vista muestra reglas no disponibles La vista, o alguna de sus fuentes, está protegida con una DAC Es una limitación documentada: valida las claves antes de aplicar la DAC o en una vista sin proteger.
No puedes persistir una vista que consume V_SALES No se puede persistir una vista que consume otra vista con DAC Persiste por debajo de la vista protegida o aplica la DAC en la vista superior.
En el Analytic Model no puedes mapear una DAC a un atributo de dimensión El modelo tiene variables estándar, de fecha de referencia o X Es una limitación documentada. Aplicar la seguridad en las vistas, como en este caso, es la alternativa que yo usaría.

Un apunte sobre persistencia: la documentación dice que una vista con DAC se puede persistir, pero no he encontrado qué pasa exactamente con una DAC heredada por asociación. Si persistes la vista fact, pruébalo antes de darlo por hecho.

Mi recomendación

Para modelos nuevos, yo pondría la DAC en la dimensión y marcaría la opción en cada asociación hecho → dimensión que tenga que heredarla. Una regla en un sitio es más fácil de auditar que tres copias mapeadas a mano. En modelos existentes, empieza por la sublista Applied via Dimensions de cada vista fact: te dice qué hechos heredan ya la seguridad de sus dimensiones. En el Analytic Model, Applied via Sources te dice qué DAC hay en sus fuentes, pero no si el hecho las hereda. Y antes de pasar a producción, haz siempre la prueba de los tres usuarios: uno con todo, uno con parte y uno sin nada.

Fuentes

Sigue leyendo