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.

mds_hierarchies_manytomany

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. Kursteilnehmer nach Kurs anzeigt, oder die Beziehung umkehren und Klassen nach Kursteilnehmer gruppiert anzeigen.

Hinweis

SQL Server 2016 (13.x) führte abgeleitete Hierarchie für M2M-Beziehungen ein. Diese Funktion war vor dieser Version nicht verfügbar.

Wechseln Sie zunächst zur abgeleiteten Hierarchieverwaltungsseite, und erstellen Sie eine neue abgeleitete Hierarchie:

mds_hierarchies_add_derived_hierarchy

Fügen Sie als Nächstes Ebenen zur neuen abgeleiteten Hierarchie hinzu, beginnend von unten nach oben. 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:

mds_hierarchies_edit_derived_hierarchy_one

Beachten Sie im obigen Screenshot, dass die Entität Employee unter Aktuelle Ebenen in der Mitte als einzige Ebene angezeigt wird. Die abgeleitete Hierarchievorschau auf der rechten Seite zeigt einfach eine Liste aller Mitglieder der Mitarbeiterentität 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 .

Beginnend mit SQL Server gibt es einen neuen Leveltyp, der M2M-Beziehungen modelliert, z. B.: Klasse (über ClassRegistration.Student zugeordnet). 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:

mds_hierarchies_edit_derived_hierarchy_two

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:

mds_hierarchies_available_entities_and_hierarchies

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 Member der Zuordnungsentität ClassRegistration werden nicht an einer beliebigen Stelle in 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 M2M-Ebene kann an einer beliebigen Stelle innerhalb einer abgeleiteten Hierarchie angezeigt werden, die eine domänenbasierte Attributebene (DBA) 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 M2M-Beziehungen können in derselben abgeleiteten Hierarchie miteinander verkettet werden.

M2M-Ebenen sind möglicherweise ausgeblendet, genau wie andere abgeleitete Hierarchieebenen.

Eine m:n-Beziehung in einem Beispielmodell

Eine Demonstration einer M2M-Beziehung finden Sie in der vom Region Klima abgeleiteten Hierarchie im Beispielmodell "Kunden", das in Master Data Services enthalten ist.

Wie in der folgenden Abbildung dargestellt, ist mds_Number1der Ebenenname, der diese Beziehung modelliert, "Klima" (zugeordnet über Region Climate.Region). Die mds_Number2Vorschau zeigt Regionen an, die nach den Klimaarten gruppiert sind, 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 mds_Number3ist APCR {Asia Pacific} mitmds_Number4 A {Tropical} undmds_Number5 B {Dry} verknüpft.

mds_M2MRelationship_Example_CustomerModel

Anweisungen zum Bereitstellen des Kundenbeispielmodells und anderer Beispielmodelle, die in Master Data Services enthalten sind, 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:

mds_hierarchies_onetomany

Dies ist eine 1:n-Beziehung, da jeder „Employee“ nur zu einem „Department“ gehört, aber jedes „Department“ kann mehrere „Employee“-Entitäten enthalten. Eine abgeleitete Hierarchie kann erstellt werden, die Mitarbeiter nach Abteilung gruppiert anzeigt:

mds_hierarchies_dh_screenshot

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. Beispiel:

  • Eine rekursive abgeleitete Hierarchie (RDH), die keine Null-Rekursionen verankert (jedes Element auf rekursiver Ebene wird sowohl unter ROOT als auch unter dem rekursiven übergeordneten Element angezeigt).

  • Eine rekursive abgeleitete Hierarchie mit einer Ebene über der rekursiven Ebene (jedes Element der rekursiven Ebene wird sowohl unter dem nicht rekursiven übergeordneten Element als auch unter dem rekursiven übergeordneten Element angezeigt).

  • Eine abgeleitete Hierarchie mit einer M2M-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.

Weitere Informationen

Abgeleitete Hierarchien (Master Data Services)