Microsoft Dataverse-tabellrelationer

Tabellrelationer i Microsoft Dataverse definierar hur tabellrader kan associeras med rader från andra tabeller eller samma tabell. Det finns två typer av tabellrelationer:

• En-till-många-relationer
• Många-till-många-relationer

En till många-relationer

I en en-till-många-tabellrelation kan många refererande (relaterade) tabellrader associeras med en enda refererad tabellrad (primär). Den refererande tabellraden kallas ibland för ”överordnad” och rader i den refererande tabellen kallas ”underordnad”. En N:1-relation är bara den underordnades perspektiv av 1:N-relationer.

I ett skolscenario kan till exempel flera kurser levereras i ett enda klassrum, så klasstabellen skulle ha en en-till-många-relation med kurstabellen.

Relationer många-till-många

I en många-till-många-tabellrelation kan många tabellrader associeras med många andra tabellrader. Rader som är kopplade via en många-till-många-relation kan betraktas som motparter och relationen är ömsesidig.

I samma skolscenario som nämndes tidigare kan till exempel en enskild elev registrera sig i flera kurser och varje kurs kan ha flera elever. Den här typen av relation möjliggör mer komplexa dataassociationer och hanteras med Power Apps i Dataverse.

Så här fungerar relationer i Dataverse

Tabellrelationer definierar hur tabellrader kan relateras till varandra i Dataverse. När du lägger till en uppslagskolumn i en tabell på den enklaste nivån skapas en ny 1:N-relation (en-till-många) mellan de två tabellerna och du kan placera uppslagskolumnen i ett formulär. Med uppslagskolumnen kan användarna associera flera underordnade rader i tabellen till en enda överordnad tabellrad.

Förutom att bara definiera hur rader kan relateras till andra rader, ger 1:N-tabellrelationer också data för att hantera följande frågor:

• Ska alla rader som är relaterade till den raden också tas bort när jag tar bort en rad?
• När jag tilldelar en rad, behöver jag också tilldela alla rader som är relaterade till den raden till den nya ägaren?
• Hur kan jag effektivisera datainmatningsprocessen när jag skapar en ny relaterad rad i kontexten för en befintlig rad?
• Hur ska personer som visar en rad kunna visa de associerade raderna?

Tabeller kan också delta i en N:N-relation (många-till-många) där valfritt antal rader för två tabeller kan associeras med varandra.

Bestäm om du vill använda tabellrelationer eller anslutningar

Tabellrelationer är metadata som gör ändringar i Dataverse. Dessa relationer gör det möjligt för frågor att hämta relaterade data effektivt. Använd tabellrelationer för att definiera formella relationer som definierar tabellen eller som de flesta rader kan använda. Till exempel skulle en affärsmöjlighet utan en potentiell kund inte vara användbar. Affärsmöjlighetstabellen i Dynamics 365 for Sales har också en N:N-relation med konkurrenttabellen, som också är tillgänglig med Dynamics 365 for Sales. Detta ger möjlighet att lägga till flera konkurrenter i affärsmöjligheten. Du kanske vill samla in dessa data och skapa en rapport som visar konkurrenterna.

Det finns andra mindre formella typer av relationer mellan rader som kallas anslutningar. Det kan till exempel vara användbart att veta om två kontakter är gifta, eller om de är vänner utanför arbetet, eller kanske en kontakt som används för att arbeta för ett annat konto. De flesta företag genererar inte rapporter som använder den här typen av information eller kräver att de anges, så det är förmodligen inte värt att skapa tabellrelationer. Mer information: Konfigurera anslutningsroller

Typer av tabellrelationer

När du visar relationer i Power Apps kanske du tror att det finns tre typer av tabellrelationer. Faktiskt finns det endast två, som du ser i följande tabell.

Relationstypen N:1 (många-till-en) finns i användargränssnittet eftersom designern visar en vy grupperad efter tabeller. 1:N-relationer finns faktiskt mellan tabeller och refererar till varje tabell som antingen en primär/aktuell tabell eller relaterad tabell. Den relaterade tabellen, som ibland kallas den underordnade tabellen, har en uppslagskolumn som gör det möjligt att lagra en referens till en rad från den primära tabellen, ibland kallad den överordnade tabellen. En N:1-relation är bara en 1:N-relation som visas från den relaterade tabellen.

Tabellrelationsbeteende

Beteenden för relaterade tabeller är viktiga eftersom de bidrar till att säkerställa dataintegritet och kan automatisera affärsprocesser åt dig.

Bevara dataintegritet

Vissa tabeller finns för att stödja andra tabeller. De är inte vettiga på egen hand. De har vanligtvis en nödvändig uppslagskolumn för att länka till den primära tabell som de stöder. Vad ska hända när en primär rad tas bort?

Du kan använda relationsbeteendet för att definiera vad som händer med relaterade rader enligt reglerna för ditt företag. Mer information: Lägga till avancerat relationsbeteende

Automatisera affärsprocesser

Anta att du har en ny säljare och vill tilldela dem ett antal befintliga konton som för närvarande är tilldelade till en annan säljare. Varje kontorad kan ha ett antal associerade uppgiftsaktiviteter. Du kan enkelt hitta de aktiva konton som du vill tilldela om och tilldela dem till den nya säljaren. Men vad händer för någon av de uppgiftsaktiviteter som är associerade med kontona? Vill du öppna varje uppgift och besluta om den också ska tilldelas den nya säljaren? Förmodligen inte. I stället kan du låta relationen tillämpa vissa standardregler automatiskt för dig. Dessa regler gäller endast för aktivitetsrader som är associerade med de konton som du omtilldelar. Dina alternativ är:

• Omtilldela alla aktiva uppgifter.
• Omtilldela alla uppgifter.
• Omtilldela inte någon uppgift.
• Omtilldela alla aktiviteter som är tilldelade den förra ägaren till kontona.

Relationen kan styra hur åtgärder som utförs på en rad i den primära tabellen kaskaderas ner till relaterade tabellrader.

Beteenden

Det finns flera typer av beteenden som kan tillämpas när vissa åtgärder inträffar.

Åtgärder

Det här är de åtgärder som kan utlösa vissa beteenden:

Överordnade tabellrelationer

Varje par med tabeller som är berättigade att ha en 1:N-relation kan ha flera 1:N-relationer mellan dem. Men vanligtvis kan bara en av dessa relationer betraktas som en föräldratabellrelation.

En föräldratabellrelation är en 1:N-relation där ett av de kaskaderande alternativen i kolumnen Förälder i följande tabell är uppfyllt.

Om du till exempel skapar en ny anpassad tabell och lägger till en 1:N-tabellrelation med kontotabellen där din anpassade tabell är den relaterade tabellen, kan du konfigurera åtgärderna för den tabellrelationen så att alternativen i kolumnen Föräldra används. Om du senare lägger till ytterligare en 1:N-tabellrelation med din anpassade tabell som refererande tabell kan du bara konfigurera åtgärderna så att de använder alternativen i kolumnen Inte förälder.

Vanligtvis innebär det att det för varje tabellpar bara finns en föräldrarelation. Det finns vissa fall där uppslag i den relaterade tabellen kan tillåta en relation till mer än en typ av tabell.

Om en tabell till exempel har en kundsökning som kan referera till antingen en kontakt- eller kontotabell. Det finns två separata överordnade 1:N-tabellrelationer.

Alla aktivitetstabeller har en liknande uppsättning överordnade tabellrelationer som kan associeras med hjälp av tillhörande uppslagskolumner.

Begränsningar som kan anges för beteenden

På grund av föräldrarelationer finns det vissa begränsningar som du bör tänka på när du definierar tabellrelationer.

• En anpassad tabell kan inte vara den primära tabellen i en relation med en relaterad systemtabell som är angiven som kaskad. Det innebär att du inte kan ha en relation med någon åtgärd inställd på Cascade All, Cascade Active eller Cascade User-Owned mellan en primär anpassad tabell och en relaterad systemtabell.
• Ingen ny relation kan ha någon åtgärd inställd på Cascade All, Cascade Active eller Cascade User-Owned om den relaterade tabellen i den relationen redan finns som en relaterad tabell i en annan relation som har någon åtgärd inställd på Cascade All, Cascade Active eller Cascade User-Owned. Därmed undviks relationer med flera överordningar.

Rensa ärvda åtkomsträttigheter

Att använda Reparent och Dela sammanhängande beteenden är användbart när du vill ge åtkomst till rader i relaterade tabeller. Men det kan finnas en ändring i processen eller designen som kräver en ändring av de sammanhängande beteendeinställningarna.

När en tabellrelation använder Reparent eller Share, och det sammanhängande beteendet ändras till Cascade None, förhindrar tabellrelationen att några nya behörighetsändringar sprids till relaterade underordnade tabeller. Dessutom måste ärvda behörigheter som beviljades medan det sammanhängande beteendet var aktivt återkallas.

Rensning av ärvda åtkomsträttigheter är ett systemjobb som rensar upp äldre ärvda åtkomsträttigheter som finns kvar när den kaskaderande beteendet har ändrats till Cascade None. Den här rensningen påverkar inte någon användare som har beviljats direkt åtkomst till en tabell, men tar bort åtkomst från alla som har fått åtkomst endast via arv.

Så här fungerar rensning av ärvda åtkomsträttigheter:

1. Identifierar och samlar in alla tabeller som fanns i en överlappande relation med den uppdaterade överordnad.
2. Identifierar och samlar in de användare som har beviljats åtkomst till de relaterade tabellerna via ärvd åtkomst.
3. Söker efter användare som har fått direkt åtkomst till en relaterad tabell och tar bort dem från samlingen.
4. Tar bort ärvd åtkomst för de insamlade användarna i de insamlade registren.

När rensningen har körts kan användare som bara har åtkomst till relaterade tabeller på grund av den sammanhängande funktionen inte längre komma åt raderna, vilket ger större säkerhet. Det finns fall där rensningen kanske inte lyckas. Läs mer om hur du rensar ärvd åtkomst

Se även

Övervaka systemjobb
Skapa och redigera 1:N-relationer (en-till-många) eller N:1 (många-till-en)
Skapa många-till-många-tabellrelationer (N:N)