Delen via


Dimensionale modellering in Microsoft Fabric Warehouse: Tabellen laden

Van toepassing op:✅ SQL Analytics-eindpunt en -magazijn in Microsoft Fabric

Notitie

Dit artikel maakt deel uit van de dimensionale modelleringsreeks van artikelen. Deze reeks is gericht op richtlijnen en aanbevolen procedures voor ontwerpen met betrekking tot dimensionale modellering in Microsoft Fabric Warehouse.

Dit artikel bevat richtlijnen en aanbevolen procedures voor het laden van dimensie- en feitentabellen in een dimensional model. Het biedt praktische richtlijnen voor Warehouse in Microsoft Fabric. Dit is een ervaring die veel T-SQL-mogelijkheden ondersteunt, zoals het maken van tabellen en het beheren van gegevens in tabellen. U hebt dus volledige controle over het maken van uw dimensionale modeltabellen en het laden ervan met gegevens.

Notitie

In dit artikel verwijst de term datawarehouse naar een datawarehouse voor ondernemingen, dat een uitgebreide integratie van kritieke gegevens in de hele organisatie biedt. Het zelfstandige termenwarehouse verwijst daarentegen naar een Fabric Warehouse, een saaS-aanbieding (software as a service) voor relationele databases die u kunt gebruiken om een datawarehouse te implementeren. Voor de duidelijkheid wordt in dit artikel het laatste genoemd als Fabric Warehouse.

Tip

Als u onervaren bent met dimensionale modellering, kunt u deze reeks artikelen overwegen als eerste stap. Het is niet bedoeld om een volledige discussie te bieden over dimensionale modelleringsontwerpen. Raadpleeg voor meer informatie rechtstreeks gepubliceerde inhoud, zoals The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling (3e editie, 2013) door Ralph Kimball en anderen.

Een dimensional model laden

Bij het laden van een dimensional model wordt periodiek een ETL-proces (Extract, Transform en Load) uitgevoerd. Een ETL-proces organiseert het uitvoeren van andere processen, die over het algemeen betrekking hebben op faseringsbrongegevens, het synchroniseren van dimensiegegevens, het invoegen van rijen in feitentabellen en het vastleggen van controlegegevens en fouten.

Voor een Fabric Warehouse-oplossing kunt u Data Factory gebruiken om uw ETL-proces te ontwikkelen en uit te voeren. Het proces kan brongegevens fasen, transformeren en laden in uw dimensionale modeltabellen.

U kunt met name het volgende doen:

  • Gebruik gegevenspijplijnen om werkstromen te bouwen om het ETL-proces te organiseren. Gegevenspijplijnen kunnen SQL-scripts, opgeslagen procedures en meer uitvoeren.
  • Gebruik gegevensstromen om logica met weinig code te ontwikkelen voor het opnemen van gegevens uit honderden gegevensbronnen. Gegevensstromen ondersteunen het combineren van gegevens uit meerdere bronnen, het transformeren van gegevens en het laden ervan naar een bestemming, zoals een dimensionale modeltabel. Gegevensstromen worden gebouwd met behulp van de vertrouwde Power Query-ervaring die momenteel beschikbaar is in veel Microsoft-producten, waaronder Microsoft Excel en Power BI Desktop.

Notitie

ETL-ontwikkeling kan complex zijn en ontwikkeling kan lastig zijn. Naar schatting is 60-80 procent van een datawarehouse-ontwikkelingsinspanning toegewezen aan het ETL-proces.

Orchestration

De algemene werkstroom van een ETL-proces is het volgende:

  1. Laad eventueel faseringstabellen.
  2. Dimensietabellen verwerken.
  3. Feitentabellen verwerken.
  4. Voer desgewenst naverwerkingstaken uit, zoals het activeren van het vernieuwen van afhankelijke fabric-inhoud (zoals een semantisch model).

Diagram toont de vier stappen van het ETL-proces, zoals beschreven in de vorige alinea.

Dimensietabellen moeten eerst worden verwerkt om ervoor te zorgen dat alle dimensieleden worden opgeslagen, inclusief de tabellen die zijn toegevoegd aan bronsystemen sinds het laatste ETL-proces. Wanneer er afhankelijkheden zijn tussen dimensies, zoals het geval is bij outriggerdimensies, moeten dimensietabellen worden verwerkt in volgorde van afhankelijkheid. Een geografiedimensie die wordt gebruikt door een klantdimensie en een leverancierdimensie, moet bijvoorbeeld worden verwerkt vóór de andere twee dimensies.

Feitentabellen kunnen worden verwerkt zodra alle dimensietabellen zijn verwerkt.

Wanneer alle dimensionale modeltabellen worden verwerkt, kunt u het vernieuwen van afhankelijke semantische modellen activeren. Het is ook een goed idee om een melding te sturen naar relevante medewerkers om hen te informeren over het resultaat van het ETL-proces.

Fasegegevens

Faseringsbrongegevens kunnen helpen bij het laden en transformeren van gegevens. Het omvat het extraheren van bronsysteemgegevens en het laden ervan in faseringstabellen, die u maakt ter ondersteuning van het ETL-proces. U wordt aangeraden brongegevens te faseeren, omdat dit het volgende kan:

  • Minimaliseer de impact op operationele systemen.
  • Worden gebruikt om etl-verwerking te ondersteunen en te optimaliseren.
  • Bied de mogelijkheid om het ETL-proces opnieuw op te starten, zonder dat u gegevens opnieuw hoeft te laden uit bronsystemen.

Gegevens in faseringstabellen mogen nooit beschikbaar worden gesteld aan zakelijke gebruikers. Dit is alleen relevant voor het ETL-proces.

Notitie

Wanneer uw gegevens zijn opgeslagen in een Fabric Lakehouse, is het mogelijk niet nodig om de gegevens in het datawarehouse te faseereren. Als er een medalsight-architectuur wordt geïmplementeerd, kunt u de gegevens uit de brons-, zilver- of gouden laag halen.

U wordt aangeraden een schema in het magazijn te maken, mogelijk met de naam staging. Faseringstabellen moeten zo dicht mogelijk op de brontabellen lijken op kolomnamen en gegevenstypen. De inhoud van elke tabel moet worden verwijderd aan het begin van het ETL-proces. Houd er echter rekening mee dat fabricwarehouse-tabellen niet kunnen worden afgekapt. In plaats daarvan kunt u elke faseringstabel verwijderen en opnieuw maken voordat u deze laadt met gegevens.

U kunt ook alternatieven voor gegevensvirtualisatie overwegen als onderdeel van uw faseringsstrategie. U kunt gebruikmaken van:

Gegevens transformeren

De structuur van de brongegevens lijkt mogelijk niet op de doelstructuren van uw dimensionale modeltabellen. Uw ETL-proces moet dus de brongegevens opnieuw vormgeven om te worden uitgelijnd met de structuur van de dimensionale modeltabellen.

Bovendien moet het datawarehouse opgeschoonde en conforme gegevens leveren, zodat brongegevens mogelijk moeten worden getransformeerd om kwaliteit en consistentie te garanderen.

Notitie

Het concept van garbage in, garbage out is zeker van toepassing op datawarehousing, dus vermijd het laden van garbagegegevens (lage kwaliteit) in uw dimensionale modeltabellen.

Hier volgen enkele transformaties die uw ETL-proces kan uitvoeren.

  • Gegevens combineren: gegevens uit verschillende bronnen kunnen worden geïntegreerd (samengevoegd) op basis van overeenkomende sleutels. Productgegevens worden bijvoorbeeld opgeslagen in verschillende systemen (zoals productie en marketing), maar ze gebruiken allemaal een algemene SKU (Stock-Keeping Unit). Gegevens kunnen ook worden toegevoegd wanneer ze een gemeenschappelijke structuur delen. Verkoopgegevens worden bijvoorbeeld opgeslagen in meerdere systemen. Een samenvoeging van de verkoop van elk systeem kan een superset van alle verkoopgegevens produceren.
  • Gegevenstypen converteren: gegevenstypen kunnen worden geconverteerd naar gegevenstypen die zijn gedefinieerd in de dimensionale modeltabellen.
  • Berekeningen: Berekeningen kunnen worden uitgevoerd om waarden te produceren voor de dimensionale modeltabellen. Voor een dimensietabel voor werknemers kunt u bijvoorbeeld voor- en achternamen samenvoegen om de volledige naam te produceren. In een ander voorbeeld kunt u voor de feitentabel verkoopcijfers berekenen. Dit is het product van de eenheidsprijs en het aantal.
  • Historische wijziging detecteren en beheren: Wijziging kan worden gedetecteerd en op de juiste wijze worden opgeslagen in dimensietabellen. Zie Historische wijziging verderop in dit artikel beheren voor meer informatie.
  • Statistische gegevens: Aggregatie kan worden gebruikt om de dimensionaliteit van feitentabellen te verminderen en/of om de granulariteit van de feiten te verhogen. De feitentabel verkoop hoeft bijvoorbeeld geen verkoopordernummers op te slaan. Daarom kan een geaggregeerd resultaat dat door alle dimensiesleutels wordt gegroepeerd, worden gebruikt om de feitentabelgegevens op te slaan.

Gegevens laden

U kunt tabellen in een Fabric Warehouse laden met behulp van de volgende opties voor gegevensopname.

  • COPY INTO (T-SQL):deze optie is handig wanneer de brongegevens Parquet- of CSV-bestanden bevatten die zijn opgeslagen in een extern Azure-opslagaccount, zoals ADLS Gen2 of Azure Blob Storage.
  • Gegevenspijplijnen: naast het organiseren van het ETL-proces kunnen gegevenspijplijnen activiteiten bevatten die T-SQL-instructies uitvoeren, zoekacties uitvoeren of gegevens kopiëren van een gegevensbron naar een bestemming.
  • Gegevensstromen: als alternatief voor gegevenspijplijnen bieden gegevensstromen een codevrije ervaring om gegevens te transformeren en op te schonen.
  • Opname tussen magazijnen: wanneer gegevens in dezelfde werkruimte worden opgeslagen, kunt u met crosswarehouse-opname verschillende magazijn- of lakehouse-tabellen samenvoegen. Het ondersteunt T-SQL-opdrachten zoals INSERT…SELECT, SELECT INTOen CREATE TABLE AS SELECT (CTAS). Deze opdrachten zijn vooral handig wanneer u gegevens wilt transformeren en laden uit faseringstabellen in dezelfde werkruimte. Ze zijn ook op set gebaseerde bewerkingen, wat waarschijnlijk de meest efficiënte en snelste manier is om dimensionale modeltabellen te laden.

Logboekregistratie

ETL-processen vereisen meestal speciale bewaking en onderhoud. Daarom raden we u aan de resultaten van het ETL-proces te registreren bij niet-dimensionale modeltabellen in uw magazijn. U moet een unieke id genereren voor elk ETL-proces en deze gebruiken om details over elke bewerking te registreren.

Overweeg logboekregistratie:

  • Het ETL-proces:
    • Een unieke id voor elke ETL-uitvoering
    • Begin- en eindtijd
    • Status (geslaagd of mislukt)
    • Eventuele fouten die zijn opgetreden
  • Elke faserings- en dimensionale modeltabel:
    • Begin- en eindtijd
    • Status (geslaagd of mislukt)
    • Rijen ingevoegd, bijgewerkt en verwijderd
    • Uiteindelijke aantal tabelrijen
    • Eventuele fouten die zijn opgetreden
  • Andere bewerkingen:
    • Begin- en eindtijd van vernieuwingsbewerkingen voor semantisch model

Tip

U kunt een semantisch model maken dat is toegewezen aan het bewaken en analyseren van uw ETL-processen. Procesduur kan u helpen knelpunten te identificeren die kunnen profiteren van beoordeling en optimalisatie. Met het aantal rijen kunt u de grootte van de incrementele belasting begrijpen telkens wanneer de ETL wordt uitgevoerd, en kunt u ook de toekomstige grootte van het datawarehouse voorspellen (en wanneer u de infrastructuurcapaciteit omhoog moet schalen, indien van toepassing).

Dimensietabellen verwerken

Het verwerken van een dimensietabel omvat het synchroniseren van de datawarehouse-gegevens met de bronsystemen. Brongegevens worden eerst getransformeerd en voorbereid voor het laden in de dimensietabel. Deze gegevens worden vervolgens gekoppeld aan de bestaande dimensietabelgegevens door deel te nemen aan de bedrijfssleutels. Het is vervolgens mogelijk om te bepalen of de brongegevens nieuwe of gewijzigde gegevens vertegenwoordigen. Wanneer de dimensietabel langzaam veranderende dimensie (SCD) type 1 toepast, worden wijzigingen aangebracht door de bestaande dimensietabelrijen bij te werken. Wanneer de tabel SCD-type 2 toepast, is de bestaande versie verlopen en wordt er een nieuwe versie ingevoegd.

In het volgende diagram ziet u de logica die wordt gebruikt voor het verwerken van een dimensietabel.

Diagram toont een stroom waarin wordt beschreven hoe nieuwe en gewijzigde bronrijen in een dimensietabel worden geladen, zoals beschreven in de volgende alinea.

Houd rekening met het proces van de Product dimensietabel.

  • Wanneer er nieuwe producten worden toegevoegd aan het bronsysteem, worden rijen ingevoegd in de Product dimensietabel.
  • Wanneer producten worden gewijzigd, worden bestaande rijen in de dimensietabel bijgewerkt of ingevoegd.
    • Wanneer SCD type 1 van toepassing is, worden er updates uitgevoerd op de bestaande rijen.
    • Wanneer SCD-type 2 van toepassing is, worden updates uitgevoerd om de huidige rijversies te laten verlopen en worden nieuwe rijen ingevoegd die de huidige versie vertegenwoordigen.
    • Wanneer SCD-type 3 van toepassing is, wordt er een proces uitgevoerd dat vergelijkbaar is met SCD-type 1, waarbij de bestaande rijen worden bijgewerkt zonder nieuwe rijen in te voegen.

Surrogaatsleutels

We raden u aan dat elke dimensietabel een surrogaatsleutel heeft, die het kleinste mogelijke gegevenstype voor gehele getallen moet gebruiken. In op SQL Server gebaseerde omgevingen die doorgaans worden uitgevoerd door het maken van een identiteitskolom, wordt deze functie echter niet ondersteund in Fabric Warehouse. In plaats daarvan moet u een tijdelijke oplossingstechniek gebruiken waarmee unieke id's worden gegenereerd.

Belangrijk

Wanneer een dimensietabel automatisch gegenereerde surrogaatsleutels bevat, moet u deze nooit afkappen en volledig opnieuw laden. Dat komt doordat de gegevens die zijn geladen in feitentabellen die gebruikmaken van de dimensie ongeldig maken. Als de dimensietabel SCD-type 2-wijzigingen ondersteunt, is het mogelijk om de historische versies mogelijk niet opnieuw te genereren.

Historische wijziging beheren

Wanneer een dimensietabel historische wijzigingen moet opslaan, moet u een langzaam veranderende dimensie (SCD) implementeren.

Notitie

Als de rij van de dimensietabel een afgeleid lid is (ingevoegd door een proces voor het laden van feiten), moet u wijzigingen behandelen als latere binnenkomende dimensiedetails in plaats van een SCD-wijziging. In dit geval moeten alle gewijzigde kenmerken worden bijgewerkt en moet de kolom met de uitgestelde lidvlag worden ingesteld op FALSE.

Het is mogelijk dat een dimensie scd-type 1- en/of SCD-type 2-wijzigingen kan ondersteunen.

SCD type 1

Wanneer SCD-type 1-wijzigingen worden gedetecteerd, gebruikt u de volgende logica.

  1. Werk eventuele gewijzigde kenmerken bij.
  2. Als de tabel de datum van laatste wijziging en het laatst door kolommen bevat, stelt u de huidige datum en het huidige proces in waarmee de wijzigingen zijn aangebracht.

SCD-type 2

Wanneer SCD-type 2-wijzigingen worden gedetecteerd, gebruikt u de volgende logica.

  1. De huidige versie laten verlopen door de geldigheidskolom van de einddatum in te stellen op de ETL-verwerkingsdatum (of een geschikte tijdstempel in het bronsysteem) en de huidige vlag op FALSE.
  2. Als de tabel de datum van laatste wijziging en het laatst door kolommen bevat, stelt u de huidige datum en het huidige proces in waarmee de wijzigingen zijn aangebracht.
  3. Voeg nieuwe leden in waarop de kolom geldigheid van de begindatum is ingesteld op de waarde van de geldigheidskolom voor de einddatum (gebruikt om de vorige versie bij te werken) en waarop de huidige versievlag is ingesteld TRUEop .
  4. Als de tabel een gemaakte datum bevat en door kolommen is gemaakt, stelt u de huidige datum en het huidige proces in waarmee de invoegingen zijn gemaakt.

SCD type 3

Wanneer SCD-type 3-wijzigingen worden gedetecteerd, werkt u de kenmerken bij met behulp van vergelijkbare logica voor het verwerken van SCD-type 1.

Verwijderingen van dimensieleden

Zorg ervoor dat brongegevens aangeeft dat dimensieleden zijn verwijderd (omdat ze niet worden opgehaald uit het bronsysteem of als ze zijn gemarkeerd als verwijderd). U moet verwijderingen niet synchroniseren met de dimensietabel, tenzij er dimensieleden in fout zijn gemaakt en er geen feitenrecords aan zijn gerelateerd.

De juiste manier om bronverwijderingen af te handelen, is door ze vast te leggen als een voorlopig verwijderen. Een voorlopig verwijderen markeert een dimensielid als niet meer actief of geldig. Ter ondersteuning van dit geval moet uw dimensietabel een Booleaanse kenmerk bevatten met het bitgegevenstype , zoals IsDeleted. Werk deze kolom voor verwijderde dimensieleden bij naar TRUE (1). De huidige, meest recente versie van een dimensielid kan op dezelfde manier worden gemarkeerd met een Booleaanse waarde (bit) in de IsCurrent of IsActive kolommen. Alle rapportagequery's en semantische Power BI-modellen moeten records filteren die voorlopig worden verwijderd.

Datumdimensie

Kalender- en tijddimensies zijn speciale gevallen omdat ze meestal geen brongegevens hebben. In plaats daarvan worden ze gegenereerd met behulp van vaste logica.

U moet de datumdimensietabel aan het begin van elk nieuw jaar laden om de rijen uit te breiden naar een bepaald aantal jaren vooruit. Er kunnen andere bedrijfsgegevens zijn, bijvoorbeeld gegevens over fiscaal jaar, feestdagen, weeknummers die regelmatig moeten worden bijgewerkt.

Wanneer de datumdimensietabel relatieve offsetkenmerken bevat, moet het ETL-proces dagelijks worden uitgevoerd om offsetkenmerkwaarden bij te werken op basis van de huidige datum (vandaag).

U wordt aangeraden de logica voor het uitbreiden of bijwerken van de datumdimensietabel in T-SQL en ingekapseld in een opgeslagen procedure.

Feitentabellen verwerken

Het verwerken van een feitentabel omvat het synchroniseren van de datawarehouse-gegevens met de gegevens van het bronsysteem. Brongegevens worden eerst getransformeerd en voorbereid voor het laden in de feitentabel. Vervolgens bepaalt een opzoekactie voor elke dimensiesleutel de surrogaatsleutelwaarde die moet worden opgeslagen in de feitenrij. Wanneer een dimensie SCD-type 2 ondersteunt, moet de surrogaatsleutel voor de huidige versie van het dimensielid worden opgehaald.

Notitie

Meestal kan de surrogaatsleutel worden berekend voor de datum- en tijddimensies, omdat deze moeten worden gebruikt YYYYMMDD of HHMM opgemaakt. Zie Agenda en tijd voor meer informatie.

Als het opzoeken van een dimensiesleutel mislukt, kan dit duiden op een integriteitsprobleem met het bronsysteem. In dit geval moet de feitenrij nog steeds worden ingevoegd in de feitentabel. Er moet nog steeds een geldige dimensiesleutel worden opgeslagen. Eén benadering is het opslaan van een speciaal dimensielid (zoals Onbekend). Voor deze aanpak is een latere update vereist om de werkelijke dimensiesleutelwaarde correct toe te wijzen, indien bekend.

Belangrijk

Omdat Fabric Warehouse geen refererende sleutels afdwingt, is het essentieel dat het ETL-proces controleert op integriteit wanneer gegevens in feitentabellen worden geladen.

Een andere benadering, die relevant is wanneer er vertrouwen is dat de natuurlijke sleutel geldig is, is door een nieuw dimensielid in te voegen en vervolgens de waarde van de surrogaatsleutel op te slaan. Zie De leden van de ingestelde dimensie verderop in deze sectie voor meer informatie.

In het volgende diagram ziet u de logica die wordt gebruikt voor het verwerken van een feitentabel.

Diagram toont een stroom waarin wordt beschreven hoe nieuwe bronrijen in een feitentabel worden geladen, zoals beschreven in de vorige alinea's.

Indien mogelijk moet een feitentabel incrementeel worden geladen, wat betekent dat er nieuwe feiten worden gedetecteerd en ingevoegd. Een strategie voor incrementele belasting is schaalbaarder en vermindert de workload voor zowel de bronsystemen als de doelsystemen.

Belangrijk

Met name voor een grote feitentabel moet het een laatste redmiddel zijn om een feitentabel af tekappen en opnieuw te laden. Deze benadering is duur in termen van procestijd, rekenresources en mogelijke onderbreking van de bronsystemen. Het omvat ook complexiteit wanneer de dimensies van de feitentabel SCD-type 2 toepassen. Dat komt doordat opzoekacties voor dimensiesleutels moeten worden uitgevoerd binnen de geldigheidsperiode van de versies van het dimensielid.

Hopelijk kunt u efficiënt nieuwe feiten detecteren door te vertrouwen op bronsysteem-id's of tijdstempels. Wanneer een bronsysteem bijvoorbeeld op betrouwbare wijze verkooporders registreert die op volgorde staan, kunt u het meest recente opgehaalde verkoopordernummer opslaan (ook wel het hoge watermerk genoemd). In het volgende proces kan dat verkoopordernummer worden gebruikt om zojuist gemaakte verkooporders op te halen en nogmaals het meest recente verkoopordernummer op te slaan dat is opgehaald voor gebruik door het volgende proces. Het kan ook mogelijk zijn dat een datumkolom maken kan worden gebruikt om nieuwe orders betrouwbaar te detecteren.

Als u niet kunt vertrouwen op de bronsysteemgegevens om efficiënt nieuwe feiten te detecteren, kunt u mogelijk vertrouwen op een mogelijkheid van het bronsysteem om een incrementele belasting uit te voeren. SQL Server en Azure SQL Managed Instance hebben bijvoorbeeld een functie met de naam Change Data Capture (CDC), waarmee wijzigingen in elke rij in een tabel kunnen worden bijgehouden. Sql Server, Azure SQL Managed Instance en Azure SQL Database hebben ook een functie met de naam Wijzigingen bijhouden, waarmee rijen kunnen worden geïdentificeerd die zijn gewijzigd. Wanneer deze functie is ingeschakeld, kunt u efficiënt nieuwe of gewijzigde gegevens in een databasetabel detecteren. Mogelijk kunt u ook triggers toevoegen aan relationele tabellen waarmee sleutels van ingevoegde, bijgewerkte of verwijderde tabelrecords worden opgeslagen.

Ten slotte kunt u mogelijk brongegevens correleren met feitentabel met behulp van kenmerken. Bijvoorbeeld het verkoopordernummer en het regelnummer van de verkooporder. Voor grote feitentabellen kan het echter een zeer dure bewerking zijn om nieuwe, gewijzigde of verwijderde feiten te detecteren. Het kan ook problematisch zijn wanneer de operationele gegevens van het bronsysteem worden gearchiveerd.

Uitgestelde dimensieleden

Wanneer een proces voor het laden van feiten een nieuw dimensielid invoegt, wordt dit een afgeleid lid genoemd. Wanneer een hotelgast bijvoorbeeld incheckt, wordt hij gevraagd lid te worden van de hotelketen als loyaliteitslid. Er wordt onmiddellijk een lidmaatschapsnummer uitgegeven, maar de details van de gast volgen mogelijk pas nadat het papierwerk door de gast is ingediend (indien ooit).

Alles wat bekend is over het dimensielid is de natuurlijke sleutel. Het proces voor het laden van feiten moet een nieuw dimensielid maken met behulp van onbekende kenmerkwaarden. Belangrijk: het moet het IsInferredMember auditkenmerk instellen op TRUE. Op die manier kan het laadproces van de dimensie de benodigde updates voor de dimensierij doorvoeren wanneer de latere binnenkomende details worden opgehaald. Zie Historische wijziging beheren in dit artikel voor meer informatie.

Feitenupdates of verwijderingen

Mogelijk moet u feitengegevens bijwerken of verwijderen. Bijvoorbeeld wanneer een verkooporder wordt geannuleerd of een orderhoeveelheid wordt gewijzigd. Zoals eerder beschreven voor het laden van feitentabellen, moet u efficiënt wijzigingen detecteren en de juiste wijzigingen in de feitengegevens uitvoeren. In dit voorbeeld voor de geannuleerde order wordt de status van de verkooporder waarschijnlijk gewijzigd van Openen in Geannuleerd. Deze wijziging vereist een update van de feitengegevens en niet het verwijderen van een rij. Voor de wijziging van de hoeveelheid is een update van de meting voor de aantal feitenrijen nodig. Deze strategie voor het gebruik van voorlopig verwijderen behoudt de geschiedenis. Een voorlopig verwijderen markeert een rij als niet meer actief of geldig, en alle rapportquery's en semantische Power BI-modellen moeten records filteren die voorlopig worden verwijderd.

Wanneer u verwacht dat feitenupdates of verwijderingen worden bijgewerkt, moet u kenmerken (zoals een verkoopordernummer en het bijbehorende verkooporderregelnummer) opnemen in de feitentabel om de feitenrijen te identificeren die moeten worden gewijzigd. Zorg ervoor dat u deze kolommen indexeer om efficiënte wijzigingsbewerkingen te ondersteunen.

Ten slotte moet u, als feitengegevens zijn ingevoegd met behulp van een speciaal dimensielid (zoals Onbekend), een periodiek proces uitvoeren waarmee de huidige brongegevens voor dergelijke feitenrijen worden opgehaald en dimensiesleutels worden bijgewerkt naar geldige waarden.

Zie voor meer informatie over het laden van gegevens in een Fabric Warehouse: