SQL Database en Microsoft Fabric es la capa escribible que guarda estados operativos como objetivos, clasificaciones manuales, notas y aprobaciones con permisos y auditoría. El modelo semántico sigue siendo la fuente de lectura de las métricas oficiales; SQL Database solo persiste lo que el usuario debe modificar. La escritura se hace mediante una User Data Function o un backend seguro, nunca con tokens de escritura expuestos en la interfaz.
¿Por qué necesitas una capa escribible junto al modelo semántico?
Leer indicadores, explicarlos y mantenerlos bajo control es justamente donde Power BI y el modelo semántico rinden mejor. El problema aparece cuando el flujo de trabajo no termina en la lectura: el negocio necesita fijar objetivos, clasificar registros a mano, dejar notas ejecutivas o aprobar un cambio. Esas acciones son escritura, y la escritura no vive bien dentro de un informe de lectura. Si todavía no tienes claro qué es la base de datos SQL en Fabric y para qué sirve, conviene repasarlo antes de diseñar la capa escribible.
La arquitectura de datos gobernados separa dos responsabilidades. La lectura analítica consulta medidas y dimensiones del modelo semántico, sin duplicar los cálculos oficiales en la interfaz. El almacenamiento operativo guarda estados, objetivos y aprobaciones en una base transaccional como SQL Database, con permisos y auditoría. Esta separación se apoya bien en una arquitectura medallion que ordena los datos en capas Bronze, Silver y Gold sin duplicar la lógica, donde cada capa cumple un rol definido. Confundir ambas capas es el error más común: termina con cifras duplicadas y con una única verdad que deja de serlo.
¿Qué debería guardar SQL Database en Fabric y qué no?
SQL Database es el lugar correcto para los datos que nacen de una decisión humana y no de la fuente operativa. Un patrón claro de qué persistir:
- Objetivos por métrica, equipo, escenario, período y moneda.
- Clasificaciones manuales que no existen en el sistema de origen.
- Notas ejecutivas, responsables, estados y comentarios de seguimiento.
- Reglas compartidas que se actualizan una vez y se invocan desde varios canales.
Lo que no debería vivir aquí: los cálculos oficiales de negocio. Esos siguen en el modelo semántico como la definición oficial que todos los canales consultan. SQL Database persiste el dato escrito; el modelo semántico lo interpreta cuando regresa al análisis.
¿Cómo se escribe sobre datos gobernados sin romper la gobernanza?
La regla central: sin tokens de escritura expuestos en la interfaz. La aplicación no escribe directo contra la base. En su lugar, una capa de lógica valida y ejecuta la acción.
**User Data Functions** aloja código Python sin servidor reutilizable y lo expone a Fabric o a aplicaciones externas mediante endpoints autenticados. Es el lugar ideal para una regla que debe invocarse desde Pipelines, Notebooks, Activator, Power BI o una aplicación por REST: se escribe una vez y se llama desde varios canales. Cuando el caso exige autenticación propia, transacciones complejas o garantías adicionales fuera de Fabric, encaja mejor un backend externo con su contrato de API, secretos y observabilidad.
En ambos casos se documenta lo mismo: identidad, conexiones, idempotencia, manejo de errores y registros. La idempotencia importa porque una acción reintentada no debe duplicar un objetivo ni una aprobación.
¿Qué rutas existen para implementar acciones y escritura?
No hay una sola forma de escribir sobre datos gobernados. La ruta se elige según dónde vive la experiencia y qué garantías se necesitan.
| Ruta | Cuándo encaja | Límite que se documenta |
|---|---|---|
| Fabric App y Data API | La empresa necesita una experiencia propia que consulta y modifica datos dentro de una aplicación Fabric | Estado de disponibilidad según la documentación oficial, región, autenticación y modelo de permisos |
| User Data Functions | La misma regla debe invocarse desde Pipelines, Notebooks, Activator, Power BI o una app por REST | Identidad, conexiones, idempotencia, errores y librerías del entorno de ejecución |
| Flujo transaccional y analítico | Un informe de Power BI ejecuta una acción acotada y escribe mediante una función sobre SQL Database o Cosmos DB | Región, tenant, latencia, auditoría y una alternativa para producción |
| Backend externo | El caso exige autenticación propia, transacciones complejas o integración fuera de Fabric | Contrato API, secretos, observabilidad y sincronización con la capa analítica |
El estado de disponibilidad de estas capacidades evoluciona; revisa la documentación oficial de Microsoft y documenta la región, el tenant, la latencia y una alternativa para producción antes de comprometer un flujo crítico.
¿Cómo se ve un patrón real: objetivos y Scorecards?
Una tabla de objetivos es el ejemplo canónico de una capa escribible bien diseñada. Debe guardar la métrica, el equipo, el escenario, el tipo de período, el período, el valor, la moneda, el estado, el responsable y la auditoría. La clave lógica combina período y escenario para evitar duplicados: un mismo objetivo no puede existir dos veces para el mismo trimestre y escenario.
La escritura pasa por una User Data Function o un backend seguro que valida antes de persistir. Si además se sincroniza un Scorecard, las llamadas a Power BI REST se ejecutan fuera del navegador y se prueban como una integración independiente, no incrustadas en la interfaz.
¿Cómo regresan los datos escritos al análisis?
El ciclo se cierra cuando lo que se escribió vuelve a ser analizable. El retorno analítico lleva los datos escritos de vuelta a Power BI, Excel o agentes mediante Direct Lake, el SQL analytics endpoint, una actualización o una API.
Una advertencia sobre Direct Lake: úsalo solo si el modelo y las fuentes fueron diseñados para ese modo. Forzarlo sobre una arquitectura que no lo contempló introduce fricción en lugar de resolverla.
¿Cómo se sostiene esto en el tiempo?
Una capa escribible se opera y evoluciona; no es un montaje que se arma una vez y se olvida. La operación y evolución se apoyan en tres prácticas:
- Git integration versiona los elementos compatibles y permite colaborar con historial.
- Deployment pipelines mueven los cambios entre desarrollo, pruebas y producción de forma repetible.
- Variable libraries ajustan parámetros entre entornos sin duplicar la lógica.
El principio que las une: todo cambio importante debe poder probarse, aprobarse y revertirse. Una base operativa sin esa disciplina se convierte en deuda silenciosa.
Cómo empezar
Diseñar la capa escribible correcta (dónde persistir, qué función valida, qué estado de disponibilidad tiene cada pieza) es una decisión de arquitectura, no de herramienta. Si tu empresa está evaluando cómo llevar sus datos de la lectura a la acción sin comprometer la gobernanza, el mejor punto de partida es ver el enfoque aplicado sobre un caso concreto: mira la demo gratuita y evalúa cómo encajaría en tu arquitectura.
Preguntas relacionadas
¿Para qué sirve SQL Database en Microsoft Fabric?
Sirve como capa de almacenamiento operativo escribible: guarda estados, objetivos, clasificaciones manuales, notas y aprobaciones con permisos y auditoría. Complementa al modelo semántico, que sigue siendo la fuente de lectura de las métricas oficiales.
¿Por qué no escribir directo desde la interfaz contra la base de datos?
Porque expondría tokens de escritura en la interfaz y rompería la gobernanza. La buena práctica es escribir mediante una User Data Function o un backend seguro que valida la acción, maneja la idempotencia y registra la auditoría.
¿Cuándo conviene un backend externo en lugar de User Data Functions?
Cuando el caso exige autenticación propia, transacciones complejas, garantías adicionales o integración fuera de Fabric. En ese escenario se documentan el contrato de API, los secretos, la observabilidad y la sincronización con la capa analítica.
¿Cómo vuelven los datos escritos al análisis en Power BI?
Mediante el retorno analítico: Direct Lake, el SQL analytics endpoint, una actualización o una API llevan los datos escritos de vuelta a Power BI, Excel o agentes. Direct Lake solo debe usarse si el modelo y las fuentes fueron diseñados para ese modo.
¿Qué debe guardar una tabla de objetivos bien diseñada?
La métrica, el equipo, el escenario, el tipo de período, el período, el valor, la moneda, el estado, el responsable y la auditoría. Una clave lógica que combine período y escenario evita objetivos duplicados.