Anzeigen von m:n-Beziehungen in abgeleiteten Hierarchien (Master Data Services)
Gilt für: 
SQL Server – nur Windows Azure SQL Managed Instance
Abgeleitete Hierarchien zeigen (DH) 1:n-Beziehungen an und können jetzt auch m:n-Beziehungen anzeigen.
m:n-Beziehungen
Eine m:n-Beziehung zwischen zwei Entitäten kann mithilfe einer dritten Entität modelliert werden, die eine Zuordnung zwischen ihnen bietet.
Im obigen Beispiel besteht eine m:n-Beziehung zwischen den Entitäten Employee (Mitarbeiter) und TrainingClass (Trainingskurs), die von der Zuordnungsentität ClassRegistration(Kursregistrierung) bereitgestellt wird. Ein Mitarbeiter kann als Teilnehmer in mehreren Kursen registriert sein, und jeder Kurs kann mehrere Teilnehmer enthalten.
Sie können eine abgeleitete Hierarchie erstellen, die z. B. die Schüler nach Klassen anzeigt oder die Beziehung umkehren und die Klassen nach Schülern gruppiert anzeigen.
Hinweis
In SQL Server 2016 (13.x) wurde eine abgeleitete Hierarchie für M2M-Beziehungen eingeführt. Diese Funktionalität war vor dieser Version nicht verfügbar.
Wechseln Sie zunächst zur Verwaltungsseite „Abgeleitete Hierarchie“, und erstellen Sie eine neue abgeleitete Hierarchie:
Fügen Sie dann zur neuen abgeleiteten Hierarchie Ebenen hinzu, wobei Sie von unten beginnen. In diesem Beispiel möchten wir nach Kursen gruppierte Teilnehmer (Mitarbeiter) anzeigen. Die Entität Employee ist daher die Blattebene der Hierarchie und wird zuerst hinzugefügt:
Beachten Sie im obigen Screenshot, dass die Entität Employee unter Aktuelle Ebenen in der Mitte als einzige Ebene angezeigt wird. Die abgeleitete Hierarchie Preview auf der rechten Seite zeigt einfach eine Liste aller Elemente der Entität Employee an. Der Abschnitt Verfügbare Ebenen auf der linken Seite zeigt an, welche Ebenen oberhalb der aktuell obersten Ebene hinzugefügt werden können (Employee). Bei den meisten handelt es sich um domänenbasierte Attribute (DBAs) für die Entität Employee . Hierzu zählt auch das domänenbasierte Attribut Department .
Ab SQL Server gibt es eine neue Art von Ebene, die m:n-Beziehungen modelliert, z. B. Class (zugeordnet über „ClassRegistration.Student“). Der Ebenenname ist ausführlicher als die anderen, um die zusätzliche Information widerzuspiegeln, die zum eindeutigen Beschreiben der Zuordnungsbeziehung erforderlich ist. Fügen Sie diese Ebene per Drag & Drop zur Ebene Employee im Abschnitt Aktuelle Ebenen hinzu:
In der Vorschau werden jetzt die nach Schulungskurs gruppierten Mitarbeiter angezeigt, für die diese registriert sind. Da dies eine m:n-Beziehung ist, kann jedes untergeordnete Element über mehrere übergeordnete Elemente verfügen. Im obigen Beispiel ist der Mitarbeiter 6 {Hillman, Reinout N} als Teilnehmer für zwei Kurse registriert, 1 {Master Data Services 101} und 4 {Career-Limiting Moves}(nicht karriereförderliches Handeln).
Diese Zuordnungsbeziehung kann auch umgekehrt angezeigt werden, wobei die Kurse nach Teilnehmern gruppiert werden:
Dies ist ein weiteres Beispiel dafür, dass ein untergeordnetes Element unter mehreren übergeordneten Elementen angezeigt werden kann: Schulungskurs 1 {Master Data Services 101} wird sowohl unter 6 {Hillman, Reinout N} als auch unter 40 {Ford, Jeffrey L}angezeigt.
Die Elemente der Zuordnungsentität ClassRegistration werden nicht innerhalb der abgeleiteten Hierarchie angezeigt. Sie werden lediglich zum Definieren der Beziehungen zwischen übergeordneten und untergeordneten Elementen in der Hierarchie verwendet.
Sie können die m:n-Beziehung bearbeiten, indem Sie die Elemente der Zuordnungsentität mithilfe einer der folgenden Methoden ändern. Die m:n-Beziehung ist auf der Seite des Explorers für abgeleitete Hierarchien schreibgeschützt.
Ändern Sie die Elemente der Zuordnungsentität auf der Seite Entitäts-Explorer mithilfe des Master Data Services-Add-Ins für Excel oder über das Staging von Daten.
Verschieben Sie untergeordnete Knoten per Drag & Drop auf der Seite des Explorers für abgeleitete Hierarchienzwischen übergeordneten Elementen.
Diese Methode ändert nach Möglichkeit vorhandene Elemente und fügt neue Elemente bei Bedarf hinzu. Vorhandene Elemente werden nicht gelöscht.
Mit der Zuordnungsentität „ClassRegistration“ wird z. B. beim Verschieben eines Teilnehmers auf den nicht verwendeten Knoten der Kursattributwert des entsprechenden Zuordnungsentitätselements in null geändert, und das Element wird nicht gelöscht. Umgekehrt wird beim Verschieben eines Teilnehmers aus dem nicht verwendeten Knoten in einen Kurs das Element geändert, wenn ein vorhandenes Zuordnungselement vorhanden ist, das dem Teilnehmer entspricht, bei dem der Kurs null ist, indem für den Kurs der Wert von null in das neue übergeordnete Element geändert wird. Wenn dieses Element nicht vorhanden ist, wird eines hinzugefügt.
Dieser Prozess verhindert das Löschen von Elementen, um das ungewollte Löschen von anderen Benutzerdaten zu vermeiden, wenn z. B. die Zuordnungsentität andere Attribute als die beiden enthält, die die Beziehung zwischen über- und untergeordnetem Element definieren. Benutzer müssen die Löschvorgänge explizit und direkt für die Zuordnungsentität vornehmen.
Die neue m:n-Ebene kann überall innerhalb einer abgeleiteten Hierarchie angezeigt werden, in der eine domänenbasierte Attributebene zulässig ist. Eine m:n-Ebene kann sich wie in den obigen Beispielen auf der obersten Ebene befinden. Sie kann über und/oder unter einer domänenbasierten Attributebene angeordnet sein, einschließlich rekursiver Ebenen. Sie kann unter der Abschlussebene einer expliziten Hierarchie (veraltet) angeordnet sein. Mehrere m:n-Beziehungen können in derselben abgeleiteten Hierarchie miteinander verkettet werden.
m:n-Ebenen können genau wie andere abgeleitete Hierarchieebenen ausgeblendet werden.
Eine m:n-Beziehung in einem Beispielmodell
Eine Vorführung einer m:n-Beziehung finden Sie in der abgeleiteten Hierarchie „Region Climate“ (regionales Klima) im Beispielmodell „Customer“, das in Master Data Services enthalten ist.
Wie in der folgenden Abbildung gezeigt, lautet der Ebenenname, der diese Beziehung modelliert, 
Climate (mapped via RegionClimate.Region)(Klima (über RegionClimate.Region zugeordnet)). Die 
Vorschau zeigt die Regionen gruppiert nach den Klimatypen, denen sie zugeordnet sind. Hierbei handelt es sich um eine m:n-Beziehung, weil einige Regionen (untergeordnete Elemente) mehreren Klimata (übergeordneten Elementen) zugeordnet sind. Beispielsweise ist 
APCR {Asien-Pazifik} mit 
A {Tropical} und 
B {Dry} verknüpft.
Eine Anleitung zum Bereitstellen des Customer-Beispielmodells und weitere in Master Data Services enthaltene Beispielmodelle finden Sie unter Bereitstellen von Beispielmodellen und Daten.
1:n-Beziehung
Ein Element einer abgeleiteten Hierarchie kann das übergeordnete Element vieler untergeordneter Elemente sein, aber es kann in der Regel nicht mehr als ein übergeordnetes Element aufweisen (Ausnahmen finden Sie unter Elementsicherheit). Angenommen, es gibt zwei Entitäten: „Employee“ und „Department“, wobei jeder „Employee“ zu einem einzelnen „Department“ gehört. Diese Beziehung wird durch Hinzufügen eines domänenbasierten Attributs zur Entität „Employee“ modelliert, das auf die Entität „Department“ verweist:
Dies ist eine 1:n-Beziehung, da jeder „Employee“ nur zu einem „Department“ gehört, aber jedes „Department“ kann mehrere „Employee“-Entitäten enthalten. Es kann eine abgeleitete Hierarchie erstellt werden, in der „Employee“ nach „Department“ gruppiert angezeigt wird:
Elementsicherheit
Eine Hierarchie, die das Kopieren von Elementen ermöglicht (dadurch kann ein Element mehrere übergeordnete Elemente aufweisen), kann nicht dazu verwendet werden, um Elementsicherheitsberechtigungen zuzuweisen. Zum Beispiel:
Eine rekursive abgeleitete Hierarchie, die keine Null-Rekursionen verankert (jedes Element der rekursiven Ebene wird sowohl unter ROOT als auch unter seinem rekursiven übergeordneten Element angezeigt).
Eine rekursive abgeleitete Hierarchie mit einer Ebene über der rekursiven Ebene (jedes Element der rekursiven Ebene wird sowohl unter seinem nicht rekursiven als auch unter seinem rekursiven übergeordneten Element angezeigt).
Eine abgeleitete Hierarchie mit einer m:n-Ebene (ein untergeordnetes Element kann vielen übergeordneten Elementen zugeordnet werden).
Sammlungen
Sammlungen und explizite Hierarchien sind veraltet. Die gespeicherte Konvertierungsprozedur (udpConvertCollectionAndConsolidatedMembersToLeaf) konvertiert Sammlungselemente in Blattelemente und erstellt abgeleitete m:n-Hierarchien, um die Informationen zur Sammlungsmitgliedschaft zu erfassen.