Visualización de relaciones varios a varios en jerarquías derivadas (Master Data Services)

Se aplica a:SQL Server en Windows Instancia administrada de Azure SQL

En las jerarquías derivadas se muestran relaciones uno a varios y, ahora, también se pueden ver en ellas relaciones varios a varios.

Relaciones de muchos a muchos (M2M)

Se puede modelar una relación de muchos a muchos (M2M) entre dos entidades mediante una tercera entidad que establezca una correspondencia entre ellas.

En el ejemplo anterior, hay una relación de M2M entre las entidades Employee y TrainingClass , que proporciona la entidad de asignación ClassRegistration. Es posible que un empleado esté registrado como alumno en varias clases, y cada clase puede contener diversos alumnos.

Puede crear una jerarquía derivada que muestre, por ejemplo, los alumnos por clase, o invertir la relación y mostrar las clases agrupadas por alumno.

En primer lugar, vaya a la página de administración de la jerarquía derivada y cree una nueva jerarquía derivada:

Después, agregue niveles a la nueva jerarquía derivada, desde el final hasta el principio. En este ejemplo, deseamos mostrar alumnos (empleados) agrupados por clase. Por lo tanto, la entidad Employee constituye el nivel hoja de la jerarquía y se agrega en primer lugar:

En la captura de pantalla anterior, observe que la entidad Employee figura en Niveles actuales , en la parte intermedia, como el único nivel. La jerarquía derivada Preview a la derecha simplemente muestra una lista de todos los miembros de la entidad Employee. En la sección Niveles disponibles del lado izquierdo se muestran los niveles que se pueden agregar encima del nivel superior actual (Employee). La mayoría de ellos son atributos basados en dominio (DBA) de la entidad Employee , incluido el DBA Department .

A partir de SQL Server, existe un nuevo tipo de nivel que modela las relaciones de M2M, por ejemplo: Class (asignado mediante ClassRegistration.Student). El nombre del nivel es más detallado que los demás a fin de reflejar la información adicional necesaria para describir la relación de asignación de forma inequívoca. Arrastre este nivel y colóquelo en el nivel Employee , que se encuentra en la sección Niveles actuales :

Ahora, en la vista previa, se muestran los empleados agrupados por las clases de aprendizaje en las que están inscritos. Como se trata de una relación de M2M, cada miembro secundario puede tener varios elementos primarios. En el ejemplo anterior, el empleado 6 {Hillman, Reinout N} está inscrito como alumno en dos clases: 1 {Master Data Services 101} y 4 {Career-Limiting Moves}.

Esta relación de asignación también puede mostrarse invertida; es decir, con las clases agrupadas por alumno:

Una vez más, vemos como un elemento secundario puede aparecer bajo más de un primario: la clase de aprendizaje 1 {Master Data Services 101} se muestra bajo 6 {Hillman, Reinout N} y 40 {Ford, Jeffrey L}.

Los miembros de la entidad de mapeo ClassRegistration no aparecen en ninguna parte de la jerarquía derivada. Se utilizan únicamente para definir las relaciones entre los miembros padre e hijo de la jerarquía.

Puede editar la relación de M2M modificando los miembros de entidades de asignación; para ello, realice una de las siguientes acciones. La relación de M2M es de solo lectura en la página Derived Hierarchy Explorer (Explorador de jerarquías derivadas).

• Modifique los miembros de entidades de asignación en la página Entity Explorer (Explorador de entidades) mediante el complemento Master Data Services para Excel, o bien usando el almacenamiento provisional de datos.

• Arrastra y suelta nodos hijos entre los nodos padres en la página Explorador de jerarquía derivada.

  Con este método, se modifican los miembros existentes cuando sea posible y se agregan nuevos cuando resulte necesario. Los miembros existentes no se eliminan.

  Por ejemplo, con la entidad de asignación ClassRegistration, al mover un alumno al nodo no utilizado, se cambia a NULL el valor de atributo de clase del miembro de la entidad de asignación correspondiente, pero no se elimina dicho miembro. Por el contrario, al mover un estudiante del nodo no utilizado a una clase, si existe un miembro de correspondencia correspondiente al estudiante cuya clase es null, ese miembro se modifica cambiando la clase de null al nuevo elemento padre. Si no se encuentra ningún miembro de este tipo, se agrega uno.

  Gracias a este proceso, se evita la eliminación de miembros a fin de evitar la eliminación no deseada de otros datos de usuario (por ejemplo, si la entidad de asignación contiene otros atributos, aparte de los dos que definen la relación de elementos primarios y secundarios). Los usuarios deben eliminar los elementos explícitamente en la entidad de asignación.

El nuevo nivel de M2M puede aparecer en cualquier parte de una jerarquía derivada donde se permita un nivel de atributo basado en dominios (DBA). Un nivel de M2M puede estar en la parte superior, como en los ejemplos anteriores. Puede estar por encima y/o por debajo de un nivel de DBA, incluidos los niveles recursivos. Puede estar en un nivel de límite de jerarquía explícita (en desuso). Es posible encadenar varias relaciones de M2M en la misma jerarquía derivada.

Asimismo, se pueden ocultar los niveles de M2M, al igual que los demás niveles de una jerarquía derivada.

Relación de M2M en el modelo de ejemplo

Para ver un ejemplo de una relación M2M, consulte la jerarquía derivada Region Climate en el modelo de ejemplo Customer incluido con Master Data Services.

Como se muestra en la siguiente imagen, el nombre del nivel que modela esta relación es Climate (asignado mediante RegionClimate.Region). La vista previa muestra las regiones agrupadas por los tipos de climas con los que se asocian. Se trata de una relación de M2M porque hay regiones (miembros secundarios) que están asociadas a varias climas (elementos primarios). Por ejemplo, APCR {Asia Pacific} está asociado a A {Tropical} y B {Dry}.

Para obtener instrucciones sobre cómo implementar el modelo de ejemplo Customer y otros modelos de ejemplo incluidos con Master Data Services, consulte Implementar modelos y datos de ejemplo.

Relación uno a muchos

Un miembro de una jerarquía derivada puede ser el elemento primario de muchos miembros secundarios, pero normalmente no puede tener más de un elemento primario (para ver las excepciones, consulte Seguridad de miembros). Por ejemplo, supongamos que hay dos entidades: Employee y Department, donde cada empleado pertenece a un solo departamento. Esta relación se modela agregando a la entidad Employee un atributo basado en dominio (DBA) que haga referencia a la entidad Department:

Se trata de una relación uno a varios porque cada empleado pertenece a un único departamento, pero cada departamento puede tener varios empleados. Se puede crear una jerarquía derivada en la que se muestre a los empleados agrupados por departamento:

Seguridad de miembros

No se puede usar una jerarquía que permita la duplicación de los miembros (permite a un miembro a tener más de un elemento primario) para asignar permisos de seguridad de miembros. Por ejemplo:

• Una jerarquía derivada recursiva (RDH) que no ancla recursiones nulas (cada miembro del nivel recursivo aparece tanto bajo ROOT como bajo su elemento primario recursivo).

• Una jerarquía derivada recursiva con un nivel por encima del nivel recursivo (cada miembro del nivel recursivo figura tanto bajo su elemento principal no recursivo como bajo su elemento principal recursivo).

• Una jerarquía derivada con un nivel de M2M (es posible asignar un elemento secundario a muchos primarios).

Colecciones

Las colecciones y las jerarquías explícitas se encuentran en desuso. El procedimiento almacenado de conversión (udpConvertCollectionAndConsolidatedMembersToLeaf) convierte los miembros de la colección en miembros hoja y crea jerarquías derivadas de varios a varios para capturar información de pertenencia a la colección.

Contenido relacionado

• Jerarquías derivadas (Master Data Services)