Richtlijnen voor een-op-een-relatiesOne-to-one relationship guidance

Dit artikel is geschreven voor iedereen die gegevensmodellen maakt met Power BI Desktop.This article targets you as a data modeler working with Power BI Desktop. Het biedt richtlijnen voor het werken met een-op-een-modelrelaties.It provides you with guidance on working with one-to-one model relationships. Een een-op-een-relatie kan worden gemaakt wanneer beide tabellen elk een kolom met algemene en unieke waarden bevatten.A one-to-one relationship can be created when both tables each contain a column of common and unique values.

Notitie

Dit artikel bevat geen inleiding tot modelrelaties.An introduction to model relationships is not covered in this article. Als u niet volledig vertrouwd bent met relaties, de eigenschappen ervan of het configureren ervan, is het aan te raden eerst het artikel Modelrelaties in Power BI Desktop te lezen.If you're not completely familiar with relationships, their properties or how to configure them, we recommend that you first read the Model relationships in Power BI Desktop article.

Het is ook belangrijk dat u enig begrip hebt van het ontwerpen van stervormige schema's.It's also important that you have an understanding of star schema design. Zie Meer informatie over stervormige schema's en het belang daarvan voor Power BI voor meer informatie.For more information, see Understand star schema and the importance for Power BI.

Er zijn twee scenario's waarbij een-op-een-relaties zijn vereist:There are two scenarios that involve one-to-one relationships:

  • Losstaande dimensies: U kunt een losstaande dimensie afleiden uit een feitentabel.Degenerate dimensions: You can derive a degenerate dimension from a fact-type table.

  • Rijgegevens die verschillende tabellen omvatten: Eén bedrijfsentiteit of bedrijfsonderwerp wordt geladen als twee (of meer) modeltabellen, mogelijk omdat de bijbehorende gegevens afkomstig zijn uit verschillende gegevensarchieven.Row data spans across tables: A single business entity or subject is loaded as two (or more) model tables, possibly because their data is sourced from different data stores. Dit scenario kan gebruikelijk zijn voor dimensietabellen.This scenario can be common for dimension-type tables. De hoofdproductdetails worden bijvoorbeeld opgeslagen in een operationeel verkoopsysteem, en aanvullende productdetails worden opgeslagen in een andere bron.For example, master product details are stored in an operational sales system, and supplementary product details are stored in a different source.

    Het is echter ongebruikelijk om twee feitentabellen via een een-op-een-relatie aan elkaar te koppelen.It's unusual, however, that you'd relate two fact-type tables with a one-to-one relationship. De reden hiervoor is dat beide feitentabellen dan dezelfde dimensionaliteit en granulatie moeten hebben.It's because both fact-type tables would need to have the same dimensionality and granularity. Elke feitentabel heeft dan bovendien unieke kolommen nodig voordat de modelrelatie kan worden gemaakt.Also, each fact-type table would need unique columns to allow the model relationship to be created.

Losstaande dimensiesDegenerate dimensions

Als kolommen uit een feitentabel worden gebruikt voor filteren of groeperen, kunt u overwegen om ze beschikbaar te maken in een afzonderlijke tabel.When columns from a fact-type table are used for filtering or grouping, you can consider making them available in a separate table. Op deze manier scheidt u kolommen die worden gebruikt voor filteren en groeperen, van de kolommen die worden gebruikt voor feitenrijen.This way, you separate columns used for filter or grouping, from those columns used to summarize fact rows. Deze scheiding biedt de volgende voordelen:This separation can:

  • Verkleinen van de benodigde opslagruimteReduce storage space
  • Vereenvoudigen van modelberekeningenSimplify model calculations
  • Bijdragen aan verbeterde queryprestatiesContribute to improved query performance
  • Auteurs van rapporten een intuïtiever deelvenster Velden biedenDeliver a more intuitive Fields pane experience to your report authors

Stel dat u een bronverkooptabel hebt waarin de details van verkooporders worden opgeslagen in twee kolommen.Consider a source sales table that stores sales order details in two columns.

Tabelrijen voor een verkooptabel.

De kolom OrderNumber bevat het ordernummer, en de kolom OrderLineNumber bevat een reeks regels binnen de order.The OrderNumber column stores the order number, and the OrderLineNumber column stores a sequence of lines within the order.

In het volgende modeldiagram ziet u dat de kolommen ordernummers en orderregels niet zijn geladen in de tabel Sales.In the following model diagram, notice that the order number and order line number columns haven't been loaded to the Sales table. In plaats hiervan zijn de bijbehorende waarden gebruikt om een kolom met surrogaatsleutels te maken met de naam SalesOrderLineID.Instead, their values were used to create a surrogate key column named SalesOrderLineID. (De sleutelwaarde wordt berekend door het ordernummer te vermenigvuldigen met 1000, en vervolgens het orderregelnummer toe te voegen.)(The key value is calculated by multiplying the order number by 1000, and then adding the order line number.)

Een modeldiagram bevat twee tabellen: Sales en Sales Order.

De tabel Sales Order biedt een rijke ervaring voor auteurs van rapporten, met drie kolommen: Sales Order, Sales Order Line en Line Number.The Sales Order table provides a rich experience for report authors with three columns: Sales Order, Sales Order Line, and Line Number. Het bevat ook een hiërarchie.It also includes a hierarchy. Deze tabelbronnen bieden ondersteuning voor rapportontwerpen die het mogelijk moeten maken te filteren, te groeperen of in te zoomen op orders en orderregels.These table resources support report designs that need to filter, group by, or drill down through orders and order lines.

Aangezien de tabel Sales Order is afgeleid uit de verkoopgegevens, moet elke tabel precies hetzelfde aantal rijen bevatten.As the Sales Order table is derived from the sales data, there should be exactly the same number of rows in each table. Verder moeten er overeenkomende waarden zijn tussen elke kolom SalesOrderLineID.Further, there should be matching values between each SalesOrderLineID column.

Rijgegevens die verschillende tabellen omvattenRow data spans across tables

Bekijk een voorbeeld van twee gerelateerde een-op-een-dimensietabellen: Product en Product Category.Consider an example involving two one-to-one related dimension-type tables: Product, and Product Category. Elke tabel vertegenwoordigt geïmporteerde gegevens en heeft een kolom SKU (Stock-Keeping Unit) met unieke waarden.Each table represents imported data and has a SKU (Stock-Keeping Unit) column containing unique values.

Hier volgt een gedeeltelijk modeldiagram van de twee tabellen.Here's a partial model diagram of the two tables.

Een modeldiagram bevat twee tabellen:

De eerste tabel heet Product en bevat drie kolommen: Color, Product en SKU.The first table is named Product, and it contains three columns: Color, Product, and SKU. De tweede tabel heet Product Category en bevat twee kolommen: Category en SKU.The second table is named Product Category, and it contains two columns: Category, and SKU. De kolommen SKU zijn gekoppeld via een een-op-een-relatie.A one-to-one relationship relates the two SKU columns. De relatie wordt gefilterd in beide richtingen, wat altijd het geval is voor een-op-een-relaties.The relationship filters in both directions, which is always the case for one-to-one relationships.

Het modeldiagram is zodanig gewijzigd dat de tabelrijen worden weergegeven om aan te geven hoe de doorgifte van relatiefilters werkt.To help describe how the relationship filter propagation works, the model diagram has been modified to reveal the table rows. Alle voorbeelden in dit artikel zijn gebaseerd op deze gegevens.All examples in this article are based on this data.

Notitie

Het is niet mogelijk om tabelrijen weer te geven in het Power BI Desktop-modeldiagram.It's not possible to display table rows in the Power BI Desktop model diagram. Het wordt wel gedaan in dit artikel om duidelijke voorbeelden te kunnen geven.It's done in this article to support the discussion with clear examples.

In het modeldiagram zijn de tabelrijen nu te zien.

De rijgegevens voor de twee tabellen worden beschreven in de volgende lijst:The row details for the two tables are described in the following bulleted list:

  • De tabel Product heeft drie rijen:The Product table has three rows:
    • SKU CL-01, Product T-shirt, Color GroenSKU CL-01, Product T-shirt, Color Green
    • SKU CL-02, Product Jeans, Color BlauwSKU CL-02, Product Jeans, Color Blue
    • SKU AC-01, Product Hoed, Color BlauwSKU AC-01, Product Hat, Color Blue
  • De tabel Product Category heeft twee rijen:The Product Category table has two rows:
    • SKU CL-01, Category KledingSKU CL-01, Category Clothing
    • SKU AC-01, Category AccessoiresSKU AC-01, Category Accessories

U ziet dat de tabel Product Category geen rij bevat voor de product-SKU CL-02.Notice that the Product Category table doesn't include a row for the product SKU CL-02. De gevolgen van deze ontbrekende rij worden verderop in dit artikel besproken.We'll discuss the consequences of this missing row later in this article.

In het deelvenster Velden kunnen auteurs van rapporten productgerelateerde velden in twee tabellen vinden: Product en Product Category.In the Fields pane, report authors will find product-related fields in two tables: Product and Product Category.

In het deelvenster Velden ziet u beide tabellen uitgevouwen, en de kolommen worden weergegeven als velden met Product en Product Category gemarkeerd.

Laten we eens kijken wat er gebeurt als velden uit beide tabellen worden toegevoegd aan een tabelvisual.Let's see what happens when fields from both tables are added to a table visual. In dit voorbeeld is de kolom SKU afkomstig uit de tabel Product.In this example, the SKU column is sourced from the Product table.

Een tabelvisual bevat vier kolommen: SKU, Product, Color en Category.

U ziet dat de waarde Category voor product-SKU CL-02 is leeg.Notice that the Category value for product SKU CL-02 is BLANK. Dit komt omdat de tabel Product Category geen rij bevat voor dit product.It's because there's no row in the Product Category table for this product.

AanbevelingenRecommendations

We raden u aan om het maken van een-op-een-modelrelaties zoveel mogelijk te vermijden wanneer rijgegevens verschillende tabellen omvatten.When possible, we recommend you avoid creating one-to-one model relationships when row data spans across model tables. Nadelen van dit ontwerp:It's because this design can:

  • Het deelvenster Velden kan te vol raken, omdat er meer tabellen worden weergegeven dan nodig isContribute to Fields pane clutter, listing more tables than necessary
  • Auteurs van rapporten kunnen gerelateerde velden mogelijk moeilijk vinden, omdat deze zijn verdeeld over meerdere tabellenMake it difficult for report authors to find related fields, because they're distributed across multiple tables
  • De mogelijkheid om hiërarchieën te maken kan beperkt zijn, omdat niveaus moeten zijn gebaseerd op kolommen uit dezelfde tabelLimit the ability to create hierarchies, as their levels must be based on columns from the same table
  • Er kunnen onverwachte resultaten worden gegenereerd wanneer rijen in de tabellen niet volledig overeenkomenProduce unexpected results when there isn't a complete match of rows between the tables

Specifieke aanbevelingen kunnen variëren, afhankelijk van of het gaat om een ‘intra-island’ of ‘inter-island’ een-op-een-relatie.Specific recommendations differ depending on whether the one-to-one relationship is intra-island or inter-island. Raadpleeg Modelrelaties in Power BI Desktop (evaluatie van relaties) voor meer informatie over de evaluatie van relaties.For more information about relationship evaluation, see Model relationships in Power BI Desktop (Relationship evaluation).

Een ‘intra-island’ een-op-een-relatieIntra-island one-to-one relationship

Wanneer er een ‘intra-island’ een-op-een-relatie tussen tabellen bestaat, raden we u aan om de gegevens samen te voegen in één modeltabel.When a one-to-one intra-island relationship exists between tables, we recommend consolidating the data into a single model table. Dit wordt gedaan door Power Query-query's samen te voegen.It's done by merging the Power Query queries.

De volgende stappen vertegenwoordigen een methode voor het samenvoegen en modelleren van gegevens die zijn gerelateerd aan een een-op-een-relatie:The following steps present a methodology to consolidate and model the one-to-one related data:

  1. Query's samenvoegen: Kijk bij het combineren van de twee query’s naar de volledigheid van de gegevens in elke query.Merge queries: When combining the two queries, give consideration to the completeness of data in each query. Als één query een volledige set rijen bevat (zoals een hoofdlijst), moet u de andere query met deze query samenvoegen.If one query contains a complete set of rows (like a master list), merge the other query with it. Configureer de samenvoegtransformatie voor het gebruik van een left outer join. Dit is het standaard-join-type.Configure the merge transformation to use a left outer join, which is the default join type. Dit join-type zorgt ervoor dat alle rijen uit de eerste query behouden blijven, en worden aangevuld met eventuele overeenkomende rijen uit de tweede query.This join type ensures you'll keep all rows of the first query, and supplement them with any matching rows of the second query. Vouw alle vereiste kolommen uit de tweede query uit in de eerste query.Expand all required columns of the second query into the first query.

  2. Laden van query uitschakelen: Zorg ervoor dat u laden uitschakelt voor de tweede query.Disable query load: Be sure to disable the load of the second query. Op deze manier wordt het bijbehorende resultaat niet geladen als een modeltabel.This way, it won't load its result as a model table. Deze configuratie vermindert de opslaggrootte van het gegevensmodel, en zorgt ervoor dat het deelvenster Velden minder vol is.This configuration reduces the data model storage size, and helps to unclutter the Fields pane.

    In ons voorbeeld zien de auteurs van rapporten nu één tabel met de naam Product in het deelvenster Velden.In our example, report authors now find a single table named Product in the Fields pane. Deze tabel bevat alle productgerelateerde velden.It contains all product-related fields.

    In het deelvenster Velden ziet u beide tabellen uitgevouwen, en de kolommen worden weergegeven als velden met Product gemarkeerd.

  3. Ontbrekende waarden vervangen: Als de tweede query niet-overeenkomende rijen bevat, worden null-waarden weergegeven in de afgeleide kolommen.Replace missing values: If the second query has unmatched rows, NULLs will appear in the columns introduced from it. U kunt deze null-waarden vervangen door een tokenwaarde, indien dit van toepassing is.When appropriate, consider replacing NULLs with a token value. Het vervangen van ontbrekende waarden is met name belangrijk wanneer auteurs van rapporten filteren of groeperen op de kolomwaarden, omdat er lege waarden kunnen worden weergegeven in rapportvisuals.Replacing missing values is especially important when report authors filter or group by the column values, as BLANKs could appear in report visuals.

    In de volgende tabelvisual ziet u dat de categorie voor product-SKU LC-02 nu [Undefined] is.In the following table visual, notice that the category for product SKU CL-02 now reads [Undefined]. Null-categorieën in de query zijn vervangen door deze tokentekstwaarde.In the query, null categories were replaced with this token text value.

    Een tabelvisual bevat vier kolommen: SKU, Product, Color en Category.

  4. Hiërarchieën maken: Als er relaties tussen de kolommen van de nu-geconsolideerde tabel bestaan , kunt u overwegen om hiërarchieën te maken.Create hierarchies: If relationships exist between the columns of the now-consolidated table, consider creating hierarchies. Op deze manier kunnen auteurs van rapporten snel mogelijkheden identificeren om in te zoomen op rapportvisuals.This way, report authors will quickly identify opportunities for report visual drilling.

    In ons voorbeeld kunnen auteurs van rapporten nu een hiërarchie gebruiken die twee niveaus heeft: Category en Product.In our example, report authors now can use a hierarchy that has two levels: Category and Product.

    In het deelvenster Velden ziet u beide tabellen uitgevouwen, en de kolommen worden weergegeven als velden met Products gemarkeerd.

Als u wilt weten hoe afzonderlijke tabellen kunnen helpen om uw velden te organiseren, raden we nog steeds aan om alles samen te voegen in één tabel.If you like how separate tables help organize your fields, we still recommend consolidating into a single table. U kunt uw velden nog steeds ordenen, maar in plaats hiervan met behulp van mappen weergeven.You can still organize your fields, but by using display folders instead.

In ons voorbeeld kunnen auteurs van rapporten het veld Category vinden in de weergavemap Marketing.In our example, report authors can find the Category field within the Marketing display folder.

In het deelvenster velden wordt het veld Category weergegeven binnen een weergavemap met de naam Marketing.

Als u nog steeds een ‘intra-island’ een-op-een-relatie in uw model wilt, moet u er, waar mogelijk, voor zorgen dat de gerelateerde tabellen overeenkomende rijen bevatten.Should you still decide to define one-to-one intra-island relationships in your model, when possible, ensure there are matching rows in the related tables. Aangezien een intra-eiland-een-op-een-relatie is geëvalueerd als een reguliere relatie, kunnen problemen met de gegevensintegriteit in uw rapportvisuals optreden als lege waarden.As a one-to-one intra-island relationship is evaluated as a regular relationship, data integrity issues could surface in your report visuals as BLANKs. (U ziet een voorbeeld van een lege groepering in de eerste tabelvisual in dit artikel.)(You can see an example of a BLANK grouping in the first table visual presented in this article.)

‘Inter-island’ een-op-een-relatieInter-island one-to-one relationship

Als er een ‘inter-island’ een-op-een-relatie tussen tabellen bestaat, is geen alternatief modelontwerp beschikbaar, tenzij u de gegevens in uw gegevensbronnen vooraf samenvoegt.When a one-to-one inter-island relationship exists between tables, there's no alternative model design—unless you pre-consolidate the data in your data sources. In Power BI wordt de een-op-een-modelrelatie geëvalueerd als een beperkte relatie.Power BI will evaluate the one-to-one model relationship as a limited relationship. Zorg er daarom voor dat de gerelateerde tabellen overeenkomende rijen bevatten, aangezien niet-overeenkomende rijden worden geëlimineerd in de queryresultaten.Therefore, take care to ensure there are matching rows in the related tables, as unmatched rows will be eliminated from query results.

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.Let's see what happens when fields from both tables are added to a table visual, and a limited relationship exists between the tables.

Een tabelvisual bevat vier kolommen: SKU, Product, Color en Category.

In de tabel worden slechts twee rijen weergegeven.The table displays two rows only. De product-SKU LC-02 ontbreekt, omdat er geen overeenkomende rij is in de tabel Product Category.Product SKU CL-02 is missing because there's no matching row in the Product Category table.

Volgende stappenNext steps

Bekijk de volgende resources voor meer informatie over dit artikel:For more information related to this article, check out the following resources: