Richtlijnen voor een-op-een-relatie
Dit artikel is bedoeld voor u als gegevensmodeller die werkt met Power BI Desktop. Het biedt u richtlijnen voor het werken met een-op-een-modelrelaties. Er kan een een-op-een-relatie worden gemaakt wanneer beide tabellen elk een kolom met gemeenschappelijke en unieke waarden bevatten.
Notitie
In dit artikel wordt geen inleiding tot modelrelaties behandeld. Als u niet volledig bekend bent met relaties, hun eigenschappen of hoe u ze configureert, raden we u aan eerst de modelrelaties in Power BI Desktop te lezen.
Het is ook belangrijk dat u inzicht hebt in het ontwerp van stervormige schema's. Zie Meer informatie over stervormige schema's en het belang van Power BI.
Er zijn twee scenario's met een-op-een-relaties:
Degenereerde dimensies: U kunt een ontaarde dimensie afleiden uit een feitentabel.
Rijgegevens omvatten meerdere tabellen: één bedrijfsentiteit of onderwerp wordt geladen als twee (of meer) modeltabellen, mogelijk omdat hun gegevens afkomstig zijn uit verschillende gegevensarchieven. Dit scenario kan gebruikelijk zijn voor dimensietabellen. Hoofdproductdetails worden bijvoorbeeld opgeslagen in een operationeel verkoopsysteem en aanvullende productdetails worden opgeslagen in een andere bron.
Het is echter ongebruikelijk dat u twee feitentabellen koppelt aan een een-op-een-relatie. Dit komt doordat beide feitentabellen dezelfde dimensionaliteit en granulariteit moeten hebben. Elke feitentabel heeft ook unieke kolommen nodig om de modelrelatie te kunnen maken.
Gedegenereerde dimensies
Wanneer kolommen uit een feitentabel worden gebruikt voor filteren of groeperen, kunt u overwegen deze beschikbaar te maken in een afzonderlijke tabel. Op deze manier scheidt u kolommen die worden gebruikt voor filteren of groeperen, van die kolommen die worden gebruikt om feitenrijen samen te vatten. Deze scheiding kan:
- Opslagruimte verminderen
- Modelberekeningen vereenvoudigen
- Bijdragen aan verbeterde queryprestaties
- Een intuïtiever deelvenster Velden bieden aan uw rapportauteurs
Overweeg een bronverkooptabel waarin verkooporderdetails in twee kolommen worden opgeslagen.
In de kolom OrderNummer wordt het ordernummer opgeslagen en in de kolom OrderLineNumber wordt een reeks regels binnen de order opgeslagen.
In het volgende modeldiagram ziet u dat de kolommen ordernummer en orderregelnummer niet zijn geladen in de tabel Sales . In plaats daarvan werden hun waarden gebruikt om een surrogaatsleutelkolom met de naam SalesOrderLineID te maken. (De sleutelwaarde wordt berekend door het ordernummer te vermenigvuldigen met 1000 en vervolgens het orderregelnummer toe te voegen.)
De tabel Verkooporder biedt een uitgebreide ervaring voor rapportauteurs met drie kolommen: Verkooporder, Verkooporderregel en Regelnummer. Het bevat ook een hiërarchie. Deze tabelbronnen ondersteunen rapportontwerpen die moeten worden gefilterd, gegroepeerd of ingezoomd op orders en orderregels.
Omdat de tabel Verkooporder is afgeleid van de verkoopgegevens, moet er precies hetzelfde aantal rijen in elke tabel zijn. Verder moeten er overeenkomende waarden zijn tussen elke kolom SalesOrderLineID .
Rijgegevens omvatten meerdere tabellen
Bekijk een voorbeeld met twee een-op-een gerelateerde dimensietabellen: Product en Productcategorie. Elke tabel vertegenwoordigt geïmporteerde gegevens en heeft een SKU-kolom (Stock-Keeping Unit) met unieke waarden.
Hier volgt een gedeeltelijk modeldiagram van de twee tabellen.
De eerste tabel heet Product en bevat drie kolommen: Kleur, Product en SKU. De tweede tabel heet Productcategorie en bevat twee kolommen: Categorie en SKU. Een een-op-een-relatie heeft betrekking op de twee SKU-kolommen . De relatie filtert in beide richtingen, wat altijd het geval is voor een-op-een-relaties.
Om te beschrijven hoe de doorgifte van relatiefilters werkt, is het modeldiagram gewijzigd om de tabelrijen weer te geven. Alle voorbeelden in dit artikel zijn gebaseerd op deze gegevens.
Notitie
Het is niet mogelijk om tabelrijen weer te geven in het Power BI Desktop-modeldiagram. Het wordt in dit artikel gedaan om de discussie met duidelijke voorbeelden te ondersteunen.
De rijdetails voor de twee tabellen worden beschreven in de volgende lijst met opsommingstekens:
- De tabel Product heeft drie rijen:
- SKU CL-01, Product T-shirt, Kleur Groen
- SKU CL-02, Product Jeans, Kleur Blauw
- SKU AC-01, Product Hat, Kleur Blauw
- De tabel Productcategorie heeft twee rijen:
- SKU CL-01, Categoriekleding
- SKU AC-01, Categorieaccessoires
U ziet dat de tabel Productcategorie geen rij bevat voor de product-SKU CL-02. Verderop in dit artikel bespreken we de gevolgen van deze ontbrekende rij.
In het deelvenster Velden vinden rapportauteurs productgerelateerde velden in twee tabellen: Product en Productcategorie.
Laten we eens kijken wat er gebeurt wanneer velden uit beide tabellen worden toegevoegd aan een tabelvisual. In dit voorbeeld is de SKU-kolom afkomstig uit de tabel Product .
U ziet dat de categoriewaarde voor product-SKU CL-02 LEEG is. Dit komt doordat er geen rij in de tabel Productcategorie voor dit product staat.
Aanbevelingen
Indien mogelijk wordt u aangeraden geen een-op-een-modelrelaties te maken wanneer rijgegevens over modeltabellen bestaan. Dit komt doordat dit ontwerp het volgende kan doen:
- Bijdragen aan het deelvenster Velden onbelangrijke e-mail, met meer tabellen dan nodig is
- Het lastig maken voor rapportauteurs om gerelateerde velden te vinden, omdat ze over meerdere tabellen worden verdeeld
- Beperk de mogelijkheid om hiërarchieën te maken, omdat hun niveaus moeten zijn gebaseerd op kolommen uit dezelfde tabel
- Onverwachte resultaten produceren wanneer er geen volledige overeenkomst is tussen rijen tussen de tabellen
Specifieke aanbevelingen verschillen, afhankelijk van of de een-op-een-relatie intra-brongroep of cross-sourcegroep is. Zie Modelrelaties in Power BI Desktop (evaluatie van relaties) voor meer informatie over de evaluatie van relaties.
Een-op-een-relatie tussen brongroepen
Wanneer er een een-op-een-relatie tussen de brongroepen tussen tabellen bestaat, raden we u aan de gegevens samen te brengen in één modeltabel. Dit wordt gedaan door de Power Query-query's samen te voegen.
De volgende stappen bevatten een methodologie voor het samenvoegen en modelleren van de een-op-een gerelateerde gegevens:
Query's samenvoegen: Bij het combineren van de twee query's moet u rekening houden met de volledigheid van gegevens in elke query. Als één query een volledige set rijen (zoals een hoofdlijst) bevat, voegt u de andere query eraan samen. Configureer de samenvoegtransformatie om een left outer join te gebruiken. Dit is het standaard jointype. Dit jointype zorgt ervoor dat u alle rijen van de eerste query bewaart en deze aanvult met overeenkomende rijen van de tweede query. Vouw alle vereiste kolommen van de tweede query uit in de eerste query.
Querybelasting uitschakelen: zorg ervoor dat u de belasting van de tweede query uitschakelt. Op deze manier wordt het resultaat niet geladen als een modeltabel. Deze configuratie vermindert de opslaggrootte van het gegevensmodel en helpt bij het opheffen van het deelvenster Velden .
In ons voorbeeld zoeken rapportauteurs nu één tabel met de naam Product in het deelvenster Velden. Het bevat alle productgerelateerde velden.
Ontbrekende waarden vervangen: als de tweede query niet-overeenkomende rijen bevat, worden NULL's weergegeven in de kolommen die ermee worden geïntroduceerd. Overweeg eventueel NULL's te vervangen door een tokenwaarde. Het vervangen van ontbrekende waarden is vooral belangrijk wanneer auteurs van rapporten filteren of groeperen op de kolomwaarden, omdat LEGE WAARDEN kunnen worden weergegeven in rapportvisuals.
In de volgende tabelvisual ziet u dat de categorie voor product-SKU CL-02 nu [Niet gedefinieerd] leest. In de query zijn null-categorieën vervangen door deze tokentekstwaarde.
Hiërarchieën maken: Als er relaties bestaan tussen de kolommen van de nu geconsolideerde tabel, kunt u overwegen om hiërarchieën te maken. Op deze manier identificeren rapportauteurs snel mogelijkheden voor het analyseren van rapportvisuals.
In ons voorbeeld kunnen auteurs van rapporten nu een hiërarchie met twee niveaus gebruiken: Categorie en Product.
Als u wilt hoe afzonderlijke tabellen helpen bij het organiseren van uw velden, raden we u nog steeds aan om samen te voegen in één tabel. U kunt uw velden nog steeds ordenen, maar in plaats daarvan kunt u weergavemappen gebruiken.
In ons voorbeeld kunnen rapportauteurs het veld Categorie vinden in de weergavemap Marketing .
Als u nog steeds besluit om een-op-een-relaties binnen de brongroep in uw model te definiëren, moet u, indien mogelijk, ervoor zorgen dat er overeenkomende rijen in de gerelateerde tabellen zijn. Omdat een een-op-een-relatie binnen een brongroep wordt geëvalueerd als een reguliere relatie, kunnen problemen met gegevensintegriteit in uw rapportvisuals worden weergegeven als BLANK's. (U ziet een voorbeeld van een LEGE groepering in de eerste tabelvisual die in dit artikel wordt weergegeven.)
Een-op-een-relatie tussen brongroepen
Wanneer er een een-op-een-relatie tussen meerdere bronnen bestaat tussen tabellen, is er geen alternatief modelontwerp, tenzij u de gegevens in uw gegevensbronnen vooraf samenvoegt. Power BI evalueert de een-op-een-modelrelatie als een beperkte relatie. Zorg er daarom voor dat er overeenkomende rijen in de gerelateerde tabellen zijn, omdat niet-overeenkomende rijen worden verwijderd uit queryresultaten.
Laten we eens kijken wat er gebeurt wanneer velden uit beide tabellen worden toegevoegd aan een tabelvisual en er een beperkte relatie tussen de tabellen bestaat.
In de tabel worden alleen twee rijen weergegeven. Product-SKU CL-02 ontbreekt omdat er geen overeenkomende rij in de tabel Productcategorie staat.
Gerelateerde inhoud
Raadpleeg de volgende bronnen voor meer informatie over dit artikel:
Feedback
Binnenkort beschikbaar: In de loop van 2024 zullen we GitHub-problemen geleidelijk uitfaseren als het feedbackmechanisme voor inhoud en deze vervangen door een nieuw feedbacksysteem. Zie voor meer informatie: https://aka.ms/ContentUserFeedback.
Feedback verzenden en weergeven voor