SQL Database en Fabric: buenas prácticas de arquitectura | Acadevor
·8 min de lectura
Buenas prácticas para la base de datos SQL en Microsoft Fabric
Cuándo y cómo usar SQL Database en Microsoft Fabric como capa operativa escribible junto al modelo semántico, con permisos, auditoría y retorno analítico.
Respuesta corta: 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?
Power BI y el modelo semántico son excelentes para leer, explicar y gobernar métricas. 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.
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. 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:
Demo gratuita
Mira cómo construir tu sistema de datos e IA
Un recorrido práctico de principio a fin para unificar fuentes dispersas en un modelo semántico que alimenta Excel, Power BI, Copilot y tus agentes.
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 contrato común de las métricas. 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 la versión preliminar, 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
Varias de estas capacidades continúan en versión preliminar. La buena práctica no es evitarlas, sino documentar 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 es un sistema vivo, no un montaje que se arma una vez. 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.
Siguiente paso
Diseñar la capa escribible correcta (dónde persistir, qué función valida, qué queda en versión preliminar) 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 romper la única verdad, una evaluación de preparación audita fuentes, sistemas y gobierno y entrega un plan priorizado. Puedes revisar cómo trabajamos ese diagnóstico en /s/empresas.
Preguntas frecuentes
¿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.
