Empezar con data warehouses en Microsoft Fabric

¿Qué te enseña este módulo?

Este módulo cubre el Fabric Data Warehouse — el motor relacional T-SQL enterprise-grade. Los objetivos oficiales:

1. Describir conceptos de data warehouse y los fundamentos del modelado dimensional.
2. Crear tablas, cargar datos y entender los métodos de ingesta.
3. Consultar y transformar datos con T-SQL y el visual query editor.
4. Modelar los datos del warehouse para reporting y consumo downstream.
5. Asegurar y monitorizar un data warehouse.

Peso en el examen DP-700

El Warehouse aparece principalmente en los dominios 1 y 2:

Definición

Un data warehouse es un store centralizado y estructurado diseñado para queries analíticas y reporting.

Diferencia crítica con las bases de datos operacionales:

• OLTP (databases operacionales): manejan transacciones day-to-day del negocio.
• OLAP (data warehouses): consolidan data de múltiples sources en un formato optimizado para analytics.

Los 4 pasos de un DW moderno

1. Data ingestion — mover data de sources al warehouse.
2. Data storage — almacenar en formato optimizado para analytics.
3. Data processing — transformar para consumo por analytical tools.
4. Data analysis y delivery — analizar y entregar insights al negocio.

¿Cómo se diseñan?

Los warehouses contienen tablas organizadas en un schema optimizado para multidimensional modeling.

La idea: agrupar numerical data related to events por diferentes attributes. Ejemplos: total amount de sales orders que ocurrieron en una fecha específica, ventas en una tienda concreta, o métricas por región o customer.

La técnica del modelado dimensional

Organizamos las tablas en dos tipos fundamentales: fact tables (mediciones) y dimension tables (contexto).

Fact tables

Contienen la numerical data que quieres analizar.

Características:

• 📊 Típicamente muchas rows.
• 🎯 Primary source para analysis.
• 📏 Contienen granular measurements de events.
• 🔑 Contienen foreign keys a dimension tables.

Ejemplos:

• FactSales: cada row = una línea de venta con sales_amount, quantity.
• FactStockPrices: cada row = una lectura de precio con open_price, close_price.
• FactWebEvents: cada row = un pageview con duration, bytes_transferred.

Dimension tables

Contienen descriptive information sobre los datos en las fact tables.

Características:

• 📚 Típicamente pocas rows (comparadas con fact).
• 📝 Muchas columnas descriptivas.
• 🎨 Proveen contexto.
• 🔑 Contienen keys que se referencian desde facts.

Ejemplos:

• DimCustomer: name, region, segment.
• DimProduct: category, brand, supplier.
• DimDate: year, quarter, month, day, day_of_week.
• DimStore: store_name, location, size.

Dos tipos de keys

Una dimension table típicamente incluye dos key columns:

A) Surrogate key

• Unique identifier específico del warehouse.
• Suele ser un integer generado automáticamente por el DBMS.
• No tiene business meaning.

B) Alternate key (también llamada natural key o business key)

• Identifica el entity en el source system.
• Ejemplos: product code, customer ID, employee number.
• Tiene business meaning.

¿Por qué necesitas ambas?

Sirven propósitos distintos.

Surrogate key:

• ✅ Consistency y accuracy dentro del warehouse.
• ✅ Independiente del source system (si el source cambia, la surrogate no).
• ✅ Performance: los integer joins son más rápidos.
• ✅ Habilita SCD Type 2 (necesitas surrogate para tracking versions).

Alternate key:

• ✅ Traceability entre warehouse y source.
• ✅ Debugging: puedes hacer lookup del source si algo va raro.
• ✅ Business queries: los users saben product codes, no surrogate keys.

Ejemplo

CREATE TABLE dbo.DimCustomer (
    CustomerKey INT NOT NULL,           -- Surrogate key (warehouse-generated)
    CustomerAltKey NVARCHAR(10) NOT NULL, -- Alternate key (from source)
    CustomerName NVARCHAR(100) NOT NULL,
    Region NVARCHAR(50) NULL
);

• CustomerKey = surrogate (ej: 1, 2, 3...).
• CustomerAltKey = alternate (ej: "CUST-00123" desde el CRM).

La fact table usa la surrogate

CREATE TABLE dbo.FactSales (
    SalesKey INT NOT NULL,
    CustomerKey INT NOT NULL,   -- FK a DimCustomer.CustomerKey (surrogate)
    ProductKey INT NOT NULL,     -- FK a DimProduct.ProductKey (surrogate)
    DateKey INT NOT NULL,        -- FK a DimDate.DateKey
    SalesAmount DECIMAL(10,2) NOT NULL,
    Quantity INT NOT NULL
);

Joins más rápidos (integer keys) e independientes del source.

Time dimensions

Las time dimensions proveen información sobre el time period en que ocurrió un event. Permiten a los analistas agregar data over temporal intervals.

Ejemplo: DimDate con columnas DateKey (ej: 20260315 formato yyyymmdd), Date, Year, Quarter, Month, MonthName, Day, DayOfWeek, IsWeekend, FiscalYear y FiscalQuarter.

Por qué son especiales

• Reutilizables: una DimDate sirve para múltiples facts.
• Hierarchies naturales: Year → Quarter → Month → Day.
• Pre-populated: se rellena con todas las fechas del rango.
• Business calendars: fiscal years, holidays, working days.

Slowly Changing Dimensions (SCD)

Ya las vimos en el Módulo 4. Recordatorio: SCD = tracking de changes to dimension attributes over time. Ejemplos: un customer cambia de dirección, un product cambia de precio, una store cierra y reabre.

Por qué importan en el warehouse

Permiten analizar y entender los cambios de los datos a lo largo del tiempo: comparar sales de un customer cuando estaba en su region antigua vs la nueva, y hacer analytics históricos que respetan el estado del dato en el momento.

Los 3 tipos principales (repaso)

• SCD Type 1: sobrescribir (sin historia).
• SCD Type 2: versionado con Valid_From, Valid_To, Is_Current.
• SCD Type 3: mantener previous_value en columna separada.

La denormalización en warehouse

En la mayoría de transactional databases operacionales, la data está normalizada para reducir duplication.

En un data warehouse, la dimension data está DENORMALIZADA para reducir el número de joins requeridos por las queries. Esto es una decisión intencional para performance analytics.

Star schema

Star schema = fact table conectada directamente a dimension tables:

       DimCustomer
            |
DimDate --- FactSales --- DimProduct
            |
       DimStore

Características:

• ✅ Menos joins para queries.
• ✅ Más rápido para analytics.
• ✅ Más fácil de entender para analistas.
• ✅ Estándar para Power BI.

Snowflake schema

Snowflake schema = dimensions normalizadas en múltiples tablas:

       DimCustomer --- DimGeography
            |
DimDate --- FactSales --- DimProduct --- DimCategory
            |                          |
       DimStore --- DimGeography    DimSupplier

En vez de todo el detalle en DimProduct, se separa en DimCategory y DimSupplier.

Características:

• ✅ Menos data duplication en storage.
• ⚠️ Más joins para queries → más lento.
• ⚠️ Más complejo para analistas.

Cuándo cada uno

Star schema ✅ (mayoría de casos): cuando la performance analítica es prioridad, los analistas consumen directamente, hay reports de Power BI, o es un data warehouse tradicional.

Snowflake schema (casos específicos): cuando el storage cost es prioridad muy alta, las dimensions tienen muchos niveles/attributes, o la data se actualiza frecuentemente en dimensions.

Definición

Un Fabric data warehouse es un fully managed, enterprise-scale relational database construido sobre OneLake.

Provee full transactional T-SQL capabilities:

• DDL statements: CREATE, ALTER, DROP.
• DML statements: INSERT, UPDATE, DELETE, MERGE.
• Full ACID compliance para data consistency.

Storage en OneLake

La data se almacena en open Delta format en OneLake:

• ✅ Otros Fabric workloads pueden acceder a la misma data sin duplication.
• ✅ Cross-workload interoperability.
• ✅ No lock-in del formato.

Interfaces

Usas T-SQL para crear tablas, cargar data, construir views y stored procedures y hacer transformaciones. Todo con la experiencia familiar de SQL Server.

Key capabilities

A) Full T-SQL support: DDL y DML statements, MERGE para upsert scenarios, sintaxis familiar de SQL Server.

B) Fully managed: NO hay infraestructura que configurar. El compute escala automáticamente e independientemente del storage.

C) OneLake integration: data en Delta format, accesible por otros Fabric workloads sin duplication.

D) Cross-database querying: query across warehouses y lakehouses sin copiar data, con three-part naming (database.schema.table) para joins cross-source.

E) Familiar tooling: conecta con SQL Server Management Studio (SSMS), Azure Data Studio, VS Code con la extensión MSSQL o cualquier SQL client vía TDS connections.

F) Copilot assistance: Copilot for Data Warehouse genera SQL desde natural language, completa código mientras escribes y explica o arregla queries existentes en el SQL editor.

Este es probablemente el tema MÁS examinable del módulo. Lo tienes que dominar completamente.

Los dos items SQL en Fabric

A) Warehouse

• Item standalone.
• Native warehouse tables (creadas por ti con CREATE TABLE).
• Full read/write.

B) SQL analytics endpoint

• Endpoint auto-generado de un Lakehouse.
• Consulta Lakehouse Delta tables.
• Read-only.

Tabla comparativa oficial

🎯 Cuándo usar cada uno

Warehouse ✅ cuando necesitas full read/write T-SQL, quieres INSERT/UPDATE/DELETE/MERGE, necesitas crear tablas vía CREATE TABLE, el equipo es T-SQL first, o haces BI empresarial tradicional.

SQL analytics endpoint ✅ cuando necesitas read-only SQL access a data de Lakehouse, ya tienes data en Lakehouse (poblada por Spark, dataflows, etc.), solo quieres queries y views sobre esa data, y no necesitas modificar datos.

Los dos usan T-SQL syntax. La sintaxis es igual; lo que cambia es qué operaciones permite.

Dos formas

• A) Desde el create hub: New → Warehouse. Provee nombre.
• B) Desde un workspace: New item → Warehouse.

Después de crear

El warehouse empieza vacío. Puedes añadir tablas, views, stored procedures y otros objects. Todo desde el SQL query editor en el Fabric portal.

Auto-created objects

Cuando creas un warehouse, se crea automáticamente un default schema dbo, y hay sample data disponible opcionalmente (Sample warehouse).

Elementos del interface

• SQL query editor: para T-SQL.
• Visual query editor: no-code drag and drop.
• Model view: para relationships y modeling.
• Explorer: navegar tables y objects.

Hay varias formas de cargar data: COPY INTO ⭐, OPENROWSET, Pipelines y Dataflows y cross-database queries (para no duplicar). Vamos uno por uno.

COPY INTO (el más común)

Bulk load de external files (CSV, Parquet) en Azure storage a warehouse tables.

COPY INTO dbo.Region
FROM 'https://mystorageaccount.blob.core.windows.net/data/Region.csv'
WITH (
    FILE_TYPE = 'CSV',
    CREDENTIAL = (
        IDENTITY = 'Shared Access Signature',
        SECRET = 'xxx'
    ),
    FIRSTROW = 2
)
GO

Options importantes:

• FILE_TYPE: CSV, PARQUET.
• CREDENTIAL: SAS, managed identity, service principal.
• FIRSTROW: skip header row.
• FIELDTERMINATOR, ROWTERMINATOR: para CSVs custom.
• PARSER_VERSION: '1.0' o '2.0' (recomendado 2.0).

OPENROWSET

Consulta ficheros directamente desde external storage o OneLake locations para ad hoc analysis o ingestion, sin crear tablas primero.

Uso típico: exploración rápida antes de decidir schema.

Pipelines y Dataflows

Ya los vimos en los Módulos 5 y 6. Recordatorio: Data Factory pipelines para orchestrated data movement y Dataflows Gen2 para transformation low-code. Ambos pueden tener Warehouse como destination.

Cross-database queries

Si ya tienes tablas en Lakehouse y quieres consultarlas desde el Warehouse sin copiar, usa cross-database queries con three-part naming:

SELECT *
FROM [MyLakehouse].[dbo].[sales_table]

Sin copiar data. Vemos esto a fondo en la sección específica.

🎯 Cuándo cada método

CREATE TABLE

Usa T-SQL CREATE TABLE con columnas apropiadas para analytics workloads:

CREATE TABLE dbo.DimCustomer (
    CustomerKey INT NOT NULL,
    CustomerAltKey NVARCHAR(10) NOT NULL,
    CustomerName NVARCHAR(100) NOT NULL,
    Region NVARCHAR(50) NULL
);
GO

CREATE TABLE dbo.FactSales (
    SalesKey INT NOT NULL,
    CustomerKey INT NOT NULL,
    ProductKey INT NOT NULL,
    DateKey INT NOT NULL,
    SalesAmount DECIMAL(10,2) NOT NULL,
    Quantity INT NOT NULL
);
GO

Data types recomendados

Elige types que balanceen precisión con storage efficiency:

Constraints

Fabric Warehouse soporta:

• ✅ NOT NULL / NULL.
• ✅ PRIMARY KEY NONCLUSTERED NOT ENFORCED (informational only).
• ✅ UNIQUE NOT ENFORCED.
• ✅ FOREIGN KEY NOT ENFORCED.

⚠️ NOT ENFORCED: Fabric NO enforcea constraints. Los mantiene como metadata para el optimizer, pero tú eres responsable de mantener la data integrity.

El pattern

Un pattern común en data warehousing: aterrizar raw data en staging tables antes de transformar y cargar en las dimension y fact tables finales.

Las staging tables replican la estructura del source data y actúan como un temporary holding area.

Beneficios

• ✅ Aislar el source data del modelo final.
• ✅ Aplicar business rules durante el load (no en query).
• ✅ Key lookups entre source keys y surrogate keys.
• ✅ Data validation antes de commit a la tabla final.
• ✅ Retry logic: si algo falla, el source data queda intacto en staging.
• ✅ Auditability: histórico de qué data se cargó cuándo.

Ejemplo típico

-- 1. Load raw data en staging con COPY INTO o pipeline
COPY INTO dbo.StgSales FROM '...';

-- 2. Transform + insert en fact table con key lookups
INSERT INTO dbo.FactSales (SalesKey, CustomerKey, ProductKey, DateKey, SalesAmount, Quantity)
SELECT
    s.OrderID,
    c.CustomerKey,    -- Lookup surrogate desde alternate
    p.ProductKey,     -- Lookup surrogate desde alternate
    d.DateKey,
    s.Amount,
    s.Qty
FROM dbo.StgSales AS s
INNER JOIN dbo.DimCustomer AS c ON s.CustomerID = c.CustomerAltKey
INNER JOIN dbo.DimProduct AS p ON s.ProductID = p.ProductAltKey
INNER JOIN dbo.DimDate AS d ON s.OrderDate = d.DateValue;
GO

Conventional naming

Prefixes comunes:

• Stg o Staging: staging tables (StgSales, StagingCustomer).
• Dim: dimensions.
• Fact: facts.
• Bridge o Br: bridge/mapping tables.
• Aggr o Agg: aggregated summary tables.

Este es un tema estrella del módulo. Muy examinable.

¿Qué es?

Fabric ofrece near-instantaneous zero-copy clones con minimal storage costs.

Un zero-copy clone crea una réplica de la tabla copiando solo la metadata, mientras sigue referenciando los mismos data files en OneLake.

• ✅ Metadata copiada.
• ❌ Underlying data NO copiada (referenciada).
• ⚡ Creación near-instant.
• 💾 Minimal storage cost.

Sintaxis

-- Clone en el mismo schema
CREATE TABLE dbo.Employee AS CLONE OF dbo.EmployeeUSA;

-- Clone cross-schema
CREATE TABLE dev.Employee AS CLONE OF prod.EmployeeUSA;

-- Clone as-of past point-in-time
CREATE TABLE dbo.Employee_Yesterday
AS CLONE OF dbo.Employee
AT (TIMESTAMP AS OF '2026-04-14T10:00:00');

Casos de uso

1. Development y testing: crear clones para playground sin duplicar data.
2. Data recovery: recuperar tras un failed release o data corruption.
3. Historical reporting: preservar data en puntos concretos del tiempo.
4. Business milestones: snapshot en momentos clave.
5. A/B testing: comparar 2 versiones sin coste de duplicación.

Independencia post-clone

Después de crear, el clone es independiente y separado:

• Los cambios en el source NO afectan al clone.
• Los cambios en el clone NO afectan al source.
• Puedes dropear cualquiera sin afectar al otro.

Time travel + clones

Puedes crear clones as-of un past point-in-time dentro del retention period. Es una capability muy poderosa.

Multiple tables at once

Puedes clonar múltiples tablas a la vez con un solo comando, útil para clonar sets de tablas relacionadas al mismo past point-in-time.

Sin límite en clones

No hay límite en el número de clones que puedes crear (dentro y entre schemas).

Storage cost

Como no copian data, el storage cost es mínimo: solo cuenta el metadata overhead (pequeño) y los data files están compartidos con el source. Cuando modificas el clone, se generan nuevos files solo para las modificaciones (Delta lo maneja transparentemente).

¿Qué es time travel?

Time travel en el data warehouse = capability low-cost y eficiente para consultar rápidamente versiones anteriores de la data.

Fabric permite recuperar past states de dos formas:

1. A nivel de statement con FOR TIMESTAMP AS OF.
2. A nivel de tabla con CLONE TABLE.

Sintaxis básica

SELECT *
FROM [dbo].[dimension_customer] AS DC
OPTION (FOR TIMESTAMP AS OF '2026-03-13T19:39:35.28');
-- March 13, 2026 at 7:39:35.28 PM UTC

Devuelve la data exactamente como existía en ese timestamp.

Format del timestamp

Format: YYYY-MM-DDTHH:MM:SS[.fff]. Solo UTC — no otras timezones.

Puedes usar CONVERT con style 126 para obtener el datetime format necesario:

SELECT CONVERT(DATETIME2, '2026-03-13T19:39:35', 126);

Reglas y limitaciones

Los resultados son inherentemente read-only: ❌ NO puedes hacer INSERT, UPDATE ni DELETE con el time travel query hint.

FOR TIMESTAMP AS OF afecta al statement ENTERO: incluye todas las warehouse tables del join. Todas ven data del mismo point-in-time.

Puedes usarla en:

• ✅ SELECT statements.
• ✅ Views (consultando views existentes, no creando views con time travel).
• ✅ Stored procedures.

NO puedes:

• ❌ Usar time travel para crear views as-of past point-in-time.
• ❌ Usarla más de una vez dentro de un SELECT statement.
• ❌ Afecta a session-scoped temp tables (#temp_table).

7 casos de uso oficiales

1. Stable reporting: reports basados en query results as-of la tarde anterior, mientras el ETL corre en background.
2. Historical trend analysis: comparar data en past time frames.
3. Analysis y comparison: identificar root cause con perspectiva histórica.
4. Performance analysis: identificar trends de degradación.
5. Audit y compliance: navegar el histórico para regulaciones de compliance.
6. Reproducir ML models: replicar exactamente los datasets usados para entrenar.
7. Cross-warehouse time travel: consultar tablas as-of un punto concreto across múltiples warehouses del mismo workspace.

Data retention

Todos los inserts, updates y deletes al warehouse se retienen dentro del retention period configurado. Esto habilita las time travel queries y los clones as-of past. Ver la siguiente sección.

Default y configurable

Default: data history retenida durante 30 días calendario. Configurable: desde 1 hasta 120 días.

Impacto en features

El retention period impacta a:

• Time travel: solo puedes ir atrás dentro del retention.
• Clones as-of past: mismo límite.
• Recovery: solo posible dentro del retention.

Cómo configurar

Se configura a nivel warehouse. Ver docs oficiales para la sintaxis exacta (varía).

Consideraciones: mayor retention = más storage cost; menor retention = menos capabilities de time travel; y el compliance puede requerir un retention mínimo.

La interfaz

El SQL query editor provee una experiencia que incluye IntelliSense, code completion, syntax highlighting, client-side parsing y validation. Muy familiar para quienes vienen de SSMS o Azure Data Studio.

Cómo crear una query

Menu → New SQL query. O el botón en el ribbon.

Copilot for Data Warehouse

Disponible en el editor. Ayuda a generar queries desde natural language, completar código mientras escribes, explicar queries existentes y arreglar queries que fallan.

Ejemplo natural language

Usuario: "Show me total sales by customer region for last month"

Copilot genera:

SELECT
    c.Region,
    SUM(f.SalesAmount) AS TotalSales
FROM dbo.FactSales AS f
INNER JOIN dbo.DimCustomer AS c ON f.CustomerKey = c.CustomerKey
INNER JOIN dbo.DimDate AS d ON f.DateKey = d.DateKey
WHERE d.Date >= DATEADD(MONTH, -1, GETDATE())
GROUP BY c.Region;

La interfaz

Visual query editor = experiencia similar al Power Query online diagram view. Para usuarios que prefieren no-code drag and drop sobre escribir T-SQL.

Cómo usarlo

1. New visual query.
2. Arrastrar una tabla al canvas.
3. Usar el menú Transform o el botón (+) en el visual para añadir columnas, filtrar, agregar, hacer join, group by, etc.

Cuándo cada uno

Más allá de las queries ad hoc, puedes guardar la lógica de transformación como objetos reutilizables.

Views

Definen una saved query que puedes referenciar como si fuera una tabla.

Use cases: estandarizar cómo los analistas acceden a la data, combinar fact y dimension tables en formato reporting-friendly, filtrar rows a un contexto de negocio específico y ocultar la complejidad de las tablas subyacentes.

CREATE VIEW dbo.vw_SalesByRegion
AS
SELECT
    c.Region,
    SUM(f.SalesAmount) AS TotalSales,
    COUNT(f.OrderID) AS OrderCount
FROM dbo.FactSales AS f
INNER JOIN dbo.DimCustomer AS c ON f.CustomerKey = c.CustomerKey
GROUP BY c.Region;

Se consumen así:

SELECT * FROM dbo.vw_SalesByRegion WHERE Region = 'North';

Stored procedures

Contienen lógica T-SQL que ejecutas on demand.

Use cases: tareas de transformación repetibles, cargar staging data en tablas finales, aplicar business rules y lógica ETL compleja parametrizable.

CREATE PROCEDURE dbo.usp_LoadFactSales
    @LoadDate DATE
AS
BEGIN
    INSERT INTO dbo.FactSales (SalesKey, CustomerKey, ProductKey, DateKey, SalesAmount, Quantity)
    SELECT
        s.OrderID,
        c.CustomerKey,
        p.ProductKey,
        d.DateKey,
        s.Amount,
        s.Qty
    FROM dbo.StgSales AS s
    INNER JOIN dbo.DimCustomer AS c ON s.CustomerID = c.CustomerAltKey
    INNER JOIN dbo.DimProduct AS p ON s.ProductID = p.ProductAltKey
    INNER JOIN dbo.DimDate AS d ON s.OrderDate = d.DateValue
    WHERE s.OrderDate = @LoadDate;
END;

Ejecutar:

EXEC dbo.usp_LoadFactSales @LoadDate = '2026-04-14';

Por qué modelar

Sin data modeling, cada consumer tiene que averiguar qué tablas se relacionan, escribir su propia aggregation logic y adivinar el significado de las columnas.

El data modeling embebe estructura, business logic y documentación directamente en el warehouse.

Los 4 pasos del modeling

1. Preparar la data para clarity (hide, rename, describe).
2. Definir relationships entre tablas.
3. Estandarizar el acceso con views y measures.
4. Publicar semantic models para reporting.

Preparar data para consumption

Las raw warehouse tables suelen contener staging tables, surrogate key columns e internal flags. Estos son para ETL processing, no para análisis: crean ruido para los consumers.

En el model view:

A) Hide internal objects: ocultar staging tables, surrogate key columns (CustomerKey) y ETL artifacts.

B) Rename columns: CustRgn → Customer Region. Nombres business-friendly.

C) Add descriptions: tablas y columnas con descripciones, para que los users las entiendan sin documentación externa.

¿Qué es una relationship?

Relationship = conexión lógica entre dos tablas que permite filtering, grouping y aggregation across esas tablas.

En star schema: conexiones entre fact tables y dimension tables a través de shared key columns. Ejemplo: CustomerKey en FactSales y DimCustomer establece el link → permite analizar sales por customer attributes (region, segment, etc.).

Cada relationship tiene 2 properties

A) Cardinality
Describe cómo se corresponden las rows de las dos tablas. En star schema es típicamente many-to-one: muchas fact rows mapean a una única dimension row.

Tipos de cardinality:

• 1:1 (one-to-one)
• 1:* (one-to-many)
• *:1 (many-to-one) ⭐ típica en star
• *:* (many-to-many)

B) Cross-filter direction
Determina en qué dirección se propagan los filters entre las tablas.

• Single direction: la dimension filtra el fact (⭐ estándar en star schema).
• Both directions: bidireccional (más flexible pero más lenta).

Por qué single direction es el estándar

• ✅ Filter behavior predecible.
• ✅ Performante.
• ✅ Evita ambigüedad en modelos complejos.

Both directions puede causar problemas de ambigüedad, dependencias circulares y penalizaciones de performance. Usar bidireccional solo cuando sea específicamente necesario.

Beneficio de definir relationships

Sin relationships, cada consumer que quiera combinar data across tables necesita escribir lógica JOIN explícita. Las relationships eliminan esa repetición codificando la conexión una sola vez.

Cuando creas un semantic model desde el warehouse, Power BI, Copilot y los Fabric IQ data agents usan estas relationships, y los data agents generan joins correctos al traducir natural language a SQL.

La necesidad de standardization

Sin estandarización, cada equipo escribe su join logic, aplica sus propios filtros, define sus propias fórmulas → resultados contradictorios.

Views para T-SQL consumers

Ya las vimos. Encapsulan join logic, filters y column selections en una query reutilizable.

Ejemplo: una view que hace join de fact/dimension, filtra a completed orders y expone solo las columnas relevantes → punto de partida fiable para todos los T-SQL consumers.

También: las views sirven como stable data sources para reports. En vez de apuntar los reports a las base tables (que pueden cambiar), apúntalos a views con forma consistente.

Measures para DAX

Measures = expresiones DAX reutilizables que definen cálculos como total, average, ratio o count.

Se crean directamente en el model view del warehouse:

1. Seleccionar una tabla.
2. Add new measure.
3. Definir la expresión DAX.

Ejemplo: una measure Total Sales que suma la columna SalesAmount asegura que todos los consumers usan el mismo cálculo.

Single source of truth

Porque la definición de la measure vive con la data, se convierte en single source of truth para esa métrica. Cuando el negocio cambia cómo calcula revenue, actualizas la measure en un solo sitio: no tienes que rastrear cada report que contiene su propia fórmula.

Views vs Measures

Juntas, views y measures cubren ambos lados del consumo:

• Views estandarizan cómo los T-SQL consumers acceden y consultan la data.
• Measures estandarizan cómo los cálculos de negocio aparecen en reports y dashboards.

Cuándo crearlo

Con las tablas preparadas, las relationships definidas y las views y measures estandarizadas, el warehouse está listo para reporting downstream.

Los equipos que consultan directamente con T-SQL pueden trabajar con el warehouse model tal cual. Pero cuando quieres construir reports y dashboards interactivos de Power BI → crear un semantic model es el siguiente paso.

Direct Lake por defecto

Los semantic models creados desde un Fabric warehouse usan Direct Lake mode.

• Import mode: copia la data en memoria de Power BI → requiere scheduled refreshes.
• Direct Lake: lee la data directamente de los ficheros Parquet de OneLake → no requiere refreshes.

Ventajas de Direct Lake

• ✅ Los reports reflejan la última data del warehouse sin scheduled refreshes.
• ✅ Evitas el storage overhead de mantener una copia separada.
• ✅ Evitas el processing overhead de los refreshes.
• ✅ Performance similar a Import mode (lee data en memoria on-demand).

Cómo crear

Desde el warehouse: Model view → New semantic model, seleccionar tablas a incluir, confirmar relationships y measures, y listo. Los reports de Power BI conectan a este semantic model, no directamente a las tablas.

Beneficios adicionales

• Governance centralizado: measures definidas una vez.
• RLS y sensitivity labels en el semantic model.
• Reusability: múltiples reports usan el mismo model.
• Endorsement: certified/promoted.

La seguridad del Fabric data warehouse opera en múltiples niveles, desde el workspace access hasta rows y columns individuales.

Workspace roles (primera capa)

La data en Fabric se organiza en workspaces. Los workspace roles son la primera capa de access control.

• Admin: full control.
• Member: casi todo excepto borrar el workspace.
• Contributor: crear/editar items.
• Viewer: solo ver.

Item permissions (granular)

Además de los workspace roles, puedes conceder item permissions para compartir warehouses individuales sin dar acceso al workspace entero.

3 permisos específicos:

• A) Read: permite conectar usando el SQL analytics endpoint. Sin Read → la conexión falla.
• B) ReadData: permite leer data desde cualquier tabla o view del warehouse.
• C) ReadAll: permite leer los raw parquet files en OneLake.

Item permissions: cuándo compartir

Los item permissions son útiles cuando necesitas compartir el warehouse para consumo downstream con usuarios específicos, sin dar acceso completo al workspace, con sharing granular.

Para un access control más preciso, el Fabric data warehouse soporta seguridad granular usando T-SQL. Estas features restringen la visibilidad de la data sin cambiar las tablas subyacentes.

Los 4 mecanismos

A) Object-Level Security (OLS)

• Controla el acceso a tablas, views o procedures específicos.
• GRANT/DENY a nivel de object.
• Un user puede ver TableA pero no TableB.

B) Row-Level Security (RLS)

• Restringe qué rows puede ver un user.
• Usa WHERE clause predicates en security policies.
• Un manager solo ve las ventas de su región.

C) Column-Level Security (CLS)

• Restringe qué columns son visibles para usuarios específicos.
• Un user puede ver email pero no salary.

D) Dynamic Data Masking (DDM)

• Enmascara data sensible (emails, account numbers, credit cards) para usuarios no privilegiados.
• La data sigue ahí, solo se enmascara en la visualización.
• Ejemplo: 4111-XXXX-XXXX-1234 en vez del número completo.

Enforcement

Muy importante: las security policies definidas en T-SQL se aplican independientemente de cómo se acceda a la data: SQL client (SSMS, ADS), reports de Power BI, queries de Copilot, notebooks y cualquier otra interfaz.

Por qué importa para compliance y AI

Asegurar la warehouse data importa para el cumplimiento regulatorio (GDPR, HIPAA, LGPD) y para garantizar que las AI-powered tools como Copilot y los data agents operan dentro de límites gobernados. Sin security enforcement, Copilot podría generar queries que exponen data sensible que no debería mostrarse.

Ejemplo básico de RLS

-- 1. Create security predicate function
CREATE FUNCTION security.fn_regionaccess(@region NVARCHAR(50))
RETURNS TABLE
WITH SCHEMABINDING
AS
RETURN SELECT 1 AS access_result
WHERE @region = USER_NAME()
   OR IS_ROLEMEMBER('AdminRole') = 1;

-- 2. Create security policy
CREATE SECURITY POLICY SalesRegionFilter
ADD FILTER PREDICATE security.fn_regionaccess(Region) ON dbo.FactSales
WITH (STATE = ON);

Después de esto, SELECT * FROM dbo.FactSales solo devuelve rows de la región del user.

Ejemplo básico de DDM

-- Alter column to add masking
ALTER TABLE dbo.Customer
ALTER COLUMN Email ADD MASKED WITH (FUNCTION = 'email()');

-- Ahora los emails aparecen como aXXX@XXXX.com para usuarios no privilegiados

CLS ejemplo

-- Denegar acceso a la columna Salary a un role
DENY SELECT ON dbo.Employee (Salary) TO AnalystRole;

Combinación de todos

Puedes combinar múltiples capas: OLS niega el acceso a la tabla SalaryHistory, RLS filtra rows en Employee por departamento, CLS niega la columna SSN en Employee y DDM enmascara PhoneNumber. Todo trabaja junto en T-SQL.

Feature

Consultar across warehouses y lakehouses del mismo workspace sin copiar data.

Three-part naming

Sintaxis: database.schema.table

SELECT
    w.CustomerID,
    l.total_spent
FROM MyWarehouse.dbo.DimCustomer AS w
INNER JOIN MyLakehouse.dbo.customer_spending AS l
    ON w.CustomerAltKey = l.customer_id;

Un solo query, dos fuentes distintas, sin copiar data.

Ventajas

• ⚡ No data movement.
• 💰 No storage duplication.
• 🔗 Combinar warehouse y lakehouse con naturalidad.
• 🎯 Data en tiempo real across sources.

Cuándo usar

Cuando el warehouse tiene dimensions curadas y el lakehouse tiene raw sales data, y quieres combinar ambos sin copiar. Muy típico en medallion architecture: bronze/silver en Lakehouse, gold en Warehouse.

Monitorizar la actividad del warehouse ayuda a identificar problemas de performance, optimizar queries y entender patrones de uso.

Query insights

Query insights provee una localización central para el histórico de queries y la información accionable de performance.

• Retiene data durante 30 días.
• Identificar long-running queries.
• Trackear cambios de performance a lo largo del tiempo.
• Entender qué queries consumen más recursos.

System views para query insights

SELECT TOP 10 *
FROM queryinsights.long_running_queries
ORDER BY total_elapsed_time_ms DESC;

Te devuelve las 10 queries más lentas.

Dynamic Management Views (DMVs)

También puedes usar DMVs para monitorizar conexiones, sesiones y requests activos en tiempo real.

SELECT
    request_id,
    session_id,
    start_time,
    total_elapsed_time
FROM sys.dm_exec_requests
WHERE status = 'running'
ORDER BY total_elapsed_time DESC;

Cuándo usar cada uno

Full ACID

Fabric Warehouse tiene full ACID compliance:

• Atomicity: las transacciones son atómicas (all-or-nothing).
• Consistency: la data siempre en estado válido.
• Isolation: las transacciones no interfieren.
• Durability: los cambios committed persisten.

Snapshot isolation exclusively

Fabric Data Warehouse usa snapshot isolation exclusivamente. Los intentos de cambiar el isolation level vía T-SQL son ignorados.

Capabilities de transacciones

A) DDL dentro de transacciones

BEGIN TRANSACTION;
CREATE TABLE dbo.MyTable (id INT);
INSERT INTO dbo.MyTable VALUES (1);
COMMIT;

B) Cross-database transactions: soportadas dentro del mismo workspace. Incluye lecturas desde SQL analytics endpoints.

C) Parquet-based rollback: el storage está en ficheros Parquet inmutables, así que los rollbacks son rápidos — revierten a versiones anteriores de los ficheros.

D) Automatic data compaction y checkpointing: la compaction fusiona ficheros Parquet pequeños y elimina rows borradas lógicamente. El checkpointing: cada write operation añade un JSON log file al Delta transaction log, y el checkpointing resume esos logs en un único checkpoint file → lecturas de metadata más rápidas.

• Trampa 1: "Warehouse y SQL analytics endpoint son intercambiables" ❌ Distintos. Warehouse permite CREATE TABLE + write. SQL endpoint es read-only sobre Lakehouse.
• Trampa 2: "Puedo hacer INSERT en un SQL analytics endpoint" ❌ El SQL analytics endpoint es READ-ONLY. Solo el Warehouse permite writes.
• Trampa 3: "Puedo crear tablas en un SQL analytics endpoint" ❌ No. Solo el Warehouse permite DDL. En el SQL endpoint solo views y stored procedures.
• Trampa 4: "Fabric Warehouse enforcea foreign keys" ❌ Los constraints son NOT ENFORCED. Se guardan como metadata para el optimizer; tú eres responsable de mantener la integridad.
• Trampa 5: "Zero-copy clone duplica el storage" ❌ NO duplica data. Solo metadata. Los data files se comparten con el source.
• Trampa 6: "Los clones NO copian las security policies" ❌ SÍ COPIAN RLS, CLS y DDM. No hay que re-aplicarlas.
• Trampa 7: "Time travel funciona con DELETE/INSERT/UPDATE" ❌ Read-only. FOR TIMESTAMP AS OF solo funciona con SELECT.
• Trampa 8: "Con time travel puedo ir 1 año atrás" ❌ Solo dentro del retention period (default 30 días, máximo 120).
• Trampa 9: "El retention default es 7 días" ❌ El default es 30 días. Configurable de 1 a 120.
• Trampa 10: "El permiso Read da acceso a la data" ❌ Read solo permite conectar al SQL endpoint. Para ver data necesitas ReadData o ReadAll.
• Trampa 11: "ReadAll da acceso solo a algunos parquet files" ❌ ReadAll da acceso a TODOS los raw Parquet files en OneLake. Es el permiso más amplio.
• Trampa 12: "RLS, CLS y DDM son mutuamente excluyentes" ❌ Se pueden combinar libremente. Son capas complementarias.
• Trampa 13: "Todos los data types de SQL Server están soportados" ❌ Faltan varios: NTEXT, TEXT, IMAGE, XML, GEOGRAPHY, GEOMETRY, HIERARCHYID, MONEY, SMALLMONEY, SQL_VARIANT.
• Trampa 14: "Copiar tablas es igual que clonar" ❌ Copiar duplica data (más storage, más tiempo). Clonar solo copia metadata (near-instant, storage mínimo).
• Trampa 15: "El semantic model desde Warehouse usa Import mode por defecto" ❌ Direct Lake por defecto. Lee data directamente de OneLake sin copiar.
• Trampa 16: "Snowflake schema es mejor para performance" ❌ Star schema es más rápido (menos joins). Snowflake reduce storage pero añade joins.
• Trampa 17: "Copilot funciona igual sin descriptions" ❌ Las descriptions mejoran significativamente la accuracy de Copilot y Fabric IQ. Muy importante para AI.
• Trampa 18: "Puedo cambiar el isolation level en Fabric Warehouse" ❌ Snapshot isolation exclusivamente. Los intentos de cambiarlo se ignoran.
• Trampa 19: "Las cross-database queries funcionan cross-workspace" ❌ Solo dentro del mismo workspace. Cross-workspace requiere shortcuts.
• Trampa 20: "Cualquiera puede hacer KILL de queries" ❌ Solo el workspace Admin. Otros roles pueden ver sus propias queries pero no las de otros.

Warehouse vs SQL analytics endpoint

Star schema vs Snowflake

Data ingestion methods

Item permissions

Sin Read → la connection falla completamente.

Granular security options

Time travel vs Clones

Query monitoring

Views vs Stored procedures

Direct Lake vs Import mode

• Módulo Learn: get-started-data-warehouse
• Data warehousing en Fabric: data-warehousing
• Fabric Data Warehouse overview: data-warehouse-overview
• COPY INTO: ingest-data-copy
• Clone table: clone-table
• Time travel: time-travel
• Data retention: data-retention
• Security: security
• Workspace roles: workspace-roles
• Row-level security (Fabric): row-level-security
• Column-level security: column-level-security
• Dynamic data masking: dynamic-data-masking
• Query insights: query-insights
• Performance guidelines: guidelines-warehouse-performance
• Star schema (Power BI guidance): star-schema
• Dimensional modeling overview: dimensional-modeling-overview
• Direct Lake overview: direct-lake-overview