Back to projects

Data integration and modeling

Documented case

Enterprise Data Platform

Data Warehouse migration from SAP Datasphere to Microsoft Fabric: integration from SAP HANA, Lakehouse and Warehouse layers, materialized tables, and models ready for Power BI.

A sanitized case based on real work at a retail company: designing the Lakehouse + Warehouse architecture in Microsoft Fabric and migrating the Data Warehouse from SAP Datasphere / BW Bridge in 3 months. Table and column names are anonymized.

Outcome: −83%processing time: the refresh of critical business reports went from 30 to 5 minutes.

  • SAP HANA
  • SQL
  • Microsoft Fabric
  • Power BI

Architecture

Flow from the ERP to analytical consumption
  1. SourceERP tables: documents, master data, and salesSAP HANA
  2. ExtractionSQL queries with explicit columns and date filtersFabric Pipelines
  3. StagingRaw data per load, append-onlyLakehouse
  4. WarehouseFacts, dimensions, and materialized tablesFabric Warehouse
  5. ConsumptionSemantic model and reportsPower BI

Modeling decisions

  • Keep staging apart from the Warehouse: raw loads do not mix with business logic.
  • Materialize consumption tables so heavy joins are not recomputed on every report query.
  • Define the grain of each fact table before building measures in Power BI.
  • Select explicit columns instead of SELECT * to reduce reads and transfer.

Load strategy and incrementality

  • Classify tables by the freshness each one needs before changing its load strategy.
  • Replace daily full loads with incremental extraction using a watermark on creation and change dates.
  • Load the delta into staging (append) and run the MERGE as a separate step, over a small volume.
  • Keep a periodic full reload to reconcile changes that do not update header dates.

Technical problems and solutions

  1. Problem
    A daily full load of a large document partner table took too long for an analytics layer that needs refreshing during the day.
    Solution
    Incremental extraction joined to the document header and filtered by creation or change date, with explicit columns and append-only staging.

    Diagnosis and approach documented

  2. Problem
    An UPSERT over millions of rows is expensive even when few of them change.
    Solution
    Compute the delta first and MERGE only that set, optimizing the target Delta table by its business keys.

    Approach documented

  3. Problem
    An incremental load based on header dates can miss changes that do not touch those dates.
    Solution
    A periodic full reconciliation alongside the daily incremental load.

    Risk identified and mitigation defined

Code sample

Incremental extraction and MERGE (anonymized names)sql
-- 1. Extract only documents created or changed since the last watermark
SELECT p.document_id, p.item_id, p.partner_role, p.customer_id
FROM erp.document_partners AS p
JOIN erp.document_headers AS h
  ON h.document_id = p.document_id
WHERE p.partner_role IN ('SHIP_TO', 'BILL_TO')
  AND (h.created_on >= :watermark OR h.changed_on >= :watermark);

-- 2. Apply the small delta to the warehouse table
MERGE INTO wh.document_partners AS t
USING stg.document_partners_delta AS s
  ON  t.document_id  = s.document_id
  AND t.item_id      = s.item_id
  AND t.partner_role = s.partner_role
WHEN MATCHED THEN UPDATE SET t.customer_id = s.customer_id
WHEN NOT MATCHED THEN
  INSERT (document_id, item_id, partner_role, customer_id)
  VALUES (s.document_id, s.item_id, s.partner_role, s.customer_id);

Case limits

  • Table and column names are anonymized.
  • No volumes or business data are published; the only timing shown is the report refresh improvement.
  • The diagram summarizes the architecture; it does not show every object in the model.