Kardinaliteit en referentiële integriteit
Het opzetten van een databron, ongeacht hoe u de data combineert, vereist inzicht in de datastructuur van alle tabellen en hoe deze kunnen worden gecombineerd. Er zijn verschillende belangrijke elementen waarmee rekening moet worden gehouden:
- Detailniveau: hoe gedetailleerd de data zijn (granulariteit). Dit kan worden gezien als het beantwoorden van de vraag 'Wat definieert een rij?'. Zie Data structureren voor analyse voor meer informatie over granulariteit
- Gedeeld veld: er moet minimaal één veld zijn dat kan worden gebruikt om de koppeling tussen tabellen te vormen. Voor een join definiëren deze velden de join-component. In gerelateerde tabellen bepalen ze de relatie.
- Kardinaliteit: hoeveel of hoe weinig unieke waarden zijn er voor het gedeelde veld (uniciteit). Zie het volgende deel voor meer informatie.
- Referentiële integriteit: een waarde in de ene tabel komt gegarandeerd overeen met de andere tabel. Met andere woorden: er kan in de ene tabel geen record voorkomen die geen corresponderende record in de andere tabel heeft. Zie hieronder voor meer informatie.
Kardinaliteit
Kardinaliteit in een enkele kolom of veld verwijst naar hoe uniek de waarden ervan zijn. Een lage kardinaliteit betekent dat er slechts een paar unieke waarden zijn (zoals in een veld voor oogkleur). Een hoge kardinaliteit betekent dat er veel unieke waarden zijn (zoals in een veld voor telefoonnummers).
De kardinaliteit tussen tabellen is vergelijkbaar, maar verwijst naar de vraag of het om een rij uit één tabel gaat die zou kunnen zijn gekoppeld aan meer dan één rij in een andere tabel. (Het is belangrijk om te onthouden dat kardinaliteit niets zegt over de vraag of er data ontbreken in een van beide tabellen. De aanwezigheid of afwezigheid van ontbrekende data is referentiële integriteit. Hoewel deze concepten samenwerken, betreffen het twee verschillende kenmerken van de relatie.)
De opties zijn een-op-een, een-op-veel, veel-op-een of veel-op-veel.
Een op een
Voorbeeld: elke auto heeft een eigen kenteken en een kenteken is specifiek voor een individuele auto. Auto-op-kentekenbewijs is een-op-een. Zelfs als een auto niet geregistreerd is of als er nog geen kenteken aan een auto is toegewezen, wordt deze afwijking beschreven door de referentiële integriteit. Een auto kan maar één kenteken hebben en een kenteken kan maar aan één auto worden toegekend. De kardinaliteit blijft dus een-op-een. |
 |
Een-op-veel of Veel-op-een
Voorbeelden: veel medewerkers hebben dezelfde manager. Medewerkers-op-manager is veel-op-een. Manager-op-medewerkers is een-op-veel. |
|
Veel-op-veel
Voorbeelden: een acteur speelt in veel films en een film heeft veel acteurs. Acteur-op-film is veel-op-veel. Er kunnen meerdere boeken in dezelfde transactie worden gekocht en een boek kan meerdere keren worden gekocht. ISBN-op-order-ID is veel-op-veel. |
 |
De kardinaliteit kan worden opgegeven in de instellingen voor Prestatieopties. Zie Relatiequery's optimaliseren met prestatieopties voor meer informatie.
Referentiële integriteit
Er is een verwant concept genaamd referentiële integriteit. Dit betekent dat een rij in de ene tabel altijd een overeenkomende rij in de andere tabel zal hebben zoals bepaald door de waarde van hun gedeelde velden. Als de database geen records bevat voor auto's zonder kentekenplaten of kentekenplaten zonder auto's, is er sprake van referentiële integriteit.
In Tableau wordt referentiële integriteit aan elke kant van de relatie geconfigureerd. In de instellingen voor Prestatieopties betekent Sommige records komen overeen dat er geen referentiële integriteit is (of dat u niet weet of die er wel is). Alle records komen overeen betekent dat er sprake is van referentiële integriteit. De standaardinstelling is om geen referentiële integriteit aan te nemen (Sommige records komen overeen).
Zie Relatiequery's optimaliseren met prestatieopties voor meer informatie.
Test uzelf
Kunt u de kardinaliteit en referentiële integriteit van elk diagram definiëren? Wat betekent dit in woorden?
Voorbeeld:
Als we de linkertabel instellen als boeken en de rechtertabel als auteurs gekoppeld aan AuteurID, vertaal het diagram dan in woorden:
- Eén boek kan meerdere auteurs hebben (de paarse records tonen één rij in de boekentabel aan de linkerkant die overeenkomt met meerdere records in de auteurstabel aan de rechterkant).
- Geen enkele auteur heeft meer dan één boek (elke auteursrecord aan de rechterkant leidt slechts één boekrecord aan de linkerkant).
- Er zijn geen boeken zonder auteurs (geen enkele record aan de linkerkant komt niet overeen met een record aan de rechterkant).
- Sommige auteurs hebben mogelijk geen boeken (De grijze auteursrecord aan de rechterkant heeft geen corresponderende boekrecord aan de linkerkant.)
Klik op elke sectie hieronder om deze uit te vouwen.
Waarom maakt het uit?
Het correct configureren van de instellingen voor kardinaliteit of referentiële integriteit kan via queryoptimalisatie de prestaties verbeteren. Onjuiste configuraties kunnen echter leiden tot aggregatieproblemen als gevolg van verlies of duplicatie van data. De standaardinstellingen voor Prestatieopties zijn Veel voor kardinaliteit en Sommige records komen overeen voor referentiële integriteit. Deze dienen alleen aangepast te worden als u zeker bent van de juiste kenmerken van uw data.
Zie Wat de instellingen kardinaliteit en referentiële Integriteit betekenen voor meer informatie over hoe Tableau met elke instelling omgaat.
Een voorbeeld in Tableau
Laten we eens kijken wat er gebeurt als de kardinaliteit onjuist is geconfigureerd.
Opmerking: in het volgende voorbeeld wordt een subset van tabellen van De Bookshop-dataset gebruikt. U kunt de werkmap downloaden om te volgen of de onbewerkte data downloaden om zelf de databronnen te maken. De gebruikte tabellen zijn Boeken, Info en Editie van Bookshop.xlsx (slechts enkele velden behouden) en Bibliotheekprofiel en Catalogus van BookshopLibrary.xlsx.
De tabellen Boek en Info hebben een een-op-een-relatie: Info bestaat in wezen uit extra kolommen voor de tabel Boek. Daarom is het zinvol, ook al kunnen ze gerelateerd zijn, om er een join van te maken om een nieuwe logische tabel te maken die alle kolommen bevat. Editie heeft een veel-op-een-relatie met deze gecombineerde tabel, omdat er van één boek meerdere edities kunnen zijn, meestal met verschillende formaten. (Het onderstaande diagram toont de relatie tussen de tabel Boek+Info en Editie, dus dit is een-op-veel.)
Editie is gerelateerd aan Catalogus als een een-op-veel-relatie op ISBN. De tabellen Catalogus en Bibliotheekprofiel zijn via veel-op-veel gerelateerd aan Bibliotheek-ID. Het belangrijkste punt is dat de tabel Bibliotheekprofielen meerdere rijen per bibliotheek bevat, één voor elk personeelstype (bibliothecaris, bibliotheekassistent, bibliotheekmedewerker). Zie De Bookshop-dataset voor meer informatie over de structuur van deze tabellen.
De juiste instellingen
Wanneer de relatie Catalogus-Bibliotheekprofiel correct is opgezet, kunnen we een eenvoudig voorbeeld maken dat het aantal medewerkers voor elke bibliotheek voor meerdere boeken weergeeft. Dit is een vreemde visualisatie om te maken, maar het is nuttig om de kwestie te illustreren. Idle Hour Library heeft 130 medewerkers, ongeacht over welk boek we het hebben. Er zijn drie waarden voor het type medewerker. Dus elk totaal bestaat uit drie records: het getal tussen haakjes.
Aantal medewerkers per bibliotheek en titel. (De cijfers tussen haakjes geven het aantal records per markering aan.)
De verkeerde instellingen: een-op-een
Wanneer de relatie ten onrechte is ingesteld op een-op-een, wordt in de weergave elke titel uit Catalogus effectief gekoppeld aan slechts één record uit de tabel Bibliotheekprofiel (zoals aangegeven door het aantal records tussen haakjes).
Aantal medewerkers per bibliotheek en titel. (De cijfers tussen haakjes geven het aantal records per markering aan.)
Hierboven kunnen we zien dat elke bibliotheek alleen het minimumaantal medewerkers weergeeft. (Zie de vetgedrukte cijfers in de onderstaande visualisatie. Het laagste aantal medewerkers is het aantal dat wordt weerspiegeld in de visualisatie van het aantal medewerkers)
Indeling van medewerkers op type en bibliotheek.
Zie Introductie van nieuwe datamodellering in Tableau(Link wordt in een nieuw venster geopend) (in het Engels) in de Tableau-blog voor meer informatie over hoe relaties contextuele joins worden.
De verkeerde instelling: joins maken
Hoewel er manieren zijn om dit soort problemen te omzeilen (waarbij LOD-expressies gebruikelijk zijn), kan het maken van joins van tabellen met een verschillende granulariteit of 'veel' in de bijbehorende kardinaliteit duplicatie veroorzaken. Hier zijn de aantallen medewerkers accuraat voor titels die slechts één formaat hebben. Maar voor de boeken die twee formaten hebben in de tabel Edities, wordt die verdubbeling ook doorgegeven aan de aantallen medewerkers (de record telt tussen haakjes; dat is 6 in plaats van het juiste aantal 3).
Aantal medewerkers per bibliotheek en titel. (De cijfers tussen haakjes geven het aantal records per markering aan.)
De verkeerde instelling: ten onrechte uitgaan van referentiële integriteit
Als u Tableau vertelt dat er sprake is van referentiële integriteit (alle records komen overeen), terwijl dit niet het geval is, kunnen waarden verloren gaan. Hier zijn deze twee visualisaties vergelijkbaar. Maar die aan de rechterkant is afkomstig van een databron die is geconfigureerd om referentiële integriteit aan te nemen. Deze heeft de nulwaarden verloren. Hoewel dit in sommige omstandigheden prima kan zijn, is het belangrijk om te begrijpen wat deze nulwaarden vertegenwoordigen. Hier wordt het aantal edities in elke bibliotheek getoond. De nulwaarden geven twee edities aan die aanwezig zijn in de editietabel, maar niet in het bezit zijn van enige bibliotheek. Dit zou een belangrijke vergissing kunnen zijn. En het is een vergissing die ten onrechte over het hoofd zou worden gezien als er sprake is van referentiële integriteit.
Verken de werkmap en de bijbehorende databronnen om te zien welke andere problemen kunnen voortkomen uit onjuist gecombineerde tabellen.
Impact op prestaties
Als het verkeerd configureren van deze instellingen kan leiden tot ontbrekende of dubbele data, waarom staat Tableau dan überhaupt toe dat deze kunnen worden gewijzigd? In veel gevallen kunt en moet u de standaardinstellingen behouden: relateer tabellen in plaats van er een join van te maken, laat de kardinaliteit op veel-op-veel staan en ga niet uit van referentiële integriteit. Vooral als u niet zeker weet wat de instellingen moeten zijn.
Kardinaliteit en referentiële integriteit zijn echter prestatieopties, omdat er prestatie-implicaties kunnen zijn voor de standaardwaarden. Als u zeker bent van de structuur van uw data, kan het configureren van de juiste instellingen de uitvoering van zoekopdrachten verminderen en de snelheid verbeteren.
Onder de motorkap
Opmerking: in deze sectie worden analogieën met andere technieken voor het combineren van data gebruikt om uitsluitend een conceptueel raamwerk te bieden. Het is geen technische beschrijving van hoe Tableau de prestatie-instellingen voor relaties gebruikt.
Kardinaliteit
De kardinaliteit van de relatie is van invloed op het moment waarop aggregatie plaatsvindt. Hierbij kan gedacht worden aan combineren. Bij het combineren van data worden twee databronnen onafhankelijk van elkaar opgevraagd. Elke databron wordt indien nodig geaggregeerd tot het gewenste detailniveau voor de weergave, ongeacht de andere databron. Voor relaties heeft de instelling voor kardinaliteit invloed op de vraag of de aggregatie vóór of na het maken van de join plaatsvindt.
In het bovenstaande voorbeeld betekent de instelling Veel dat het aantal medewerkers voor elke bibliotheek wordt geaggregeerd voordat die data worden gecombineerd met de boekinformatie, zodat elk boek de juiste nummers heeft. Wanneer de kardinaliteit ten onrechte op Eén was ingesteld, is het aantal medewerkers niet geaggregeerd voordat het werd gecombineerd met de boekdata. Dit leidde tot onjuiste waarden.
Merk op dat niet alleen de onjuiste waarden worden weergegeven, maar dat alle waarden zijn toegewezen aan het type medewerker Bibliothecarissen, ondanks het feit dat deze afkomstig zijn van alle drie de typen medewerkers. Een verkeerde configuratie van deze instelling kan onvoorspelbare en onjuiste waarden veroorzaken. Dit filteren van resultaten gebeurt alleen wanneer een veld uit een andere tabel aan de andere kant van de verkeerd ingestelde relatie in de weergave wordt gebruikt.
Als de waarden uniek zijn, is Tableau echter vrij om de aggregatie vóór het maken van de join te verwijderen als dit de query optimaliseert.
Referentiële integriteit
Hoewel referentiële integriteit verwijst naar een instelling voor relaties, kan deze worden gezien in termen van typen joins. Bij een volledig buitenste join blijven alle records behouden. Ongeacht of er al dan niet een overeenkomst bestaat in de andere tabel, maar dit resulteert in lagere prestaties. Als u niet zeker weet of records verloren gaan, is een buitenste join veiliger. Dit is de manier waarop tabellen worden behandeld als er mogelijk geen sprake is van referentiële integriteit (sommige records komen overeen).
Bij een binnenste join worden alleen die records bewaard bij een overeenkomst in beide tabellen en worden records verwijderd die niet in elke tabel voorkomen. Als u weet dat een binnenste join de benodigde data niet elimineert, is dit efficiënter. Als de Prestatieopties zijn ingesteld op Alle records komen overeen, wordt uitgegaan van referentiële integriteit en worden joins uitgevoerd zonder rekening te houden met niet-overeenkomende waarden.
Een onjuiste instelling voor referentiële integriteit kan een filterachtig effect hebben op de gecombineerde data, waardoor niet-overeenkomende waarden worden verwijderd. Zie Vragen stellen over meerdere gerelateerde tabellen (in het Engels) in de Tableau-blog voor meer informatie over de kracht van het behouden van records zonder overeenkomsten. Zie Joins maken van uw data voor meer informatie over typen joins.
De standaardinstellingen behouden
Als uw analyse acceptabele prestaties levert, raden we u ten zeerste aan de standaardinstellingen voor Prestatieopties op veel-op-veel te laten en niet uit te gaan van referentiële integriteit. De kracht van relaties komt voort uit hun vermogen om nauwkeurige, contextueel passende resultaten te leveren op basis van de tabellen die in de analyse worden gebruikt. Als u deze instellingen wijzigt, wordt de semantische flexibiliteit van relaties verwijderd.