Visualización de relaciones varios a varios en jerarquías derivadas (Master Data Services)
Se aplica a: 
SQL Server: solo Windows Azure SQL Managed Instance
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 varios a varios (M2M)
Se puede modelar una relación de varios a varios (M2M) entre dos entidades mediante el uso de una tercera entidad que proporcione una asignación 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.
Nota:
SQL Server 2016 (13.x) introdujo la jerarquía derivada para las relaciones M2M. Esta funcionalidad no estaba disponible antes de esa versión.
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. En la vista previa de la jerarquía derivada del lado derecho podrá ver 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 asignación ClassRegistration no aparecen en ningún lugar de la jerarquía derivada. Se utilizan simplemente para definir las relaciones entre los miembros primarios y secundarios 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.
Arrastre y coloque nodos secundarios entre los elementos primarios en la página Derived Hierarchy Explorer(Explorador de jerarquías derivadas).
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 alguna clase, si existe un miembro de asignación correspondiente al alumno con la clase NULL, ese miembro se modifica cambiando la clase de NULL al nuevo elemento primario. 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 encontrarse encima o 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 obtener una demostración de una relación de M2M, vea la jerarquía derivada Region Climate del modelo de ejemplo Customer que se incluye 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 varios
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:
Un jerarquía derivada recursiva que no delimite recursiones nulas (cada miembro del nivel recursivo aparece bajo la raíz y su elemento primario recursivo).
Una jerarquía derivada recursiva con un nivel por encima del recursivo (cada miembro este último aparece bajo su elemento primario no recursivo y su primario 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.