Partilhar via


Mostrar relações muitos-para-muitos em hierarquias derivadas (Master Data Services)

Aplica-se a:SQL Server no Windows Azure SQL Managed Instance

Importante

Os Serviços de Dados Mestres (MDS) foram removidos no SQL Server 2025 (17.x). Continuamos a oferecer suporte ao MDS no SQL Server 2022 (16.x) e em versões anteriores.

As hierarquias derivadas (DH) exibem relações um-para-muitos, e agora também podem mostrar relações muitos-para-muitos.

Relações muitos-para-muitos (M2M)

Uma relação muitos-para-muitos (M2M) entre duas entidades pode ser modelada através do uso de uma terceira entidade que fornece um mapeamento entre elas:

mds_hierarchies_manytomany

No exemplo acima, há uma relação M2M entre as entidades Employee e TrainingClass , fornecida pela entidade de mapeamento ClassRegistration. Um funcionário pode ser registrado como aluno em várias turmas, e cada classe pode conter vários alunos.

Você pode criar uma hierarquia derivada que exiba, por exemplo, alunos por classe, ou inverter a relação e mostrar classes agrupadas por aluno.

Observação

O SQL Server 2016 (13.x) introduziu hierarquia derivada para relações M2M. Esse recurso não estava disponível antes dessa versão.

Primeiro, vá para a página de gerenciamento de hierarquia derivada e crie uma nova hierarquia derivada:

mds_hierarchies_add_derived_hierarchy

Em seguida, adicione níveis à nova hierarquia derivada, começando de baixo para cima. Neste exemplo, queremos mostrar os alunos (funcionários) agrupados por classe. A entidade Employee é, portanto, o nível foliar da hierarquia e é adicionada primeiro.

mds_hierarchies_edit_derived_hierarchy_one

Na captura de tela acima, observe que a entidade Employee aparece em Current Levels no meio como o único nível. A hierarquia derivada Preview à direita simplesmente mostra uma lista de todos os membros da entidade Employee . A seção Níveis Disponíveis à esquerda mostra quais níveis podem ser adicionados sobre o nível superior atual (Funcionário). A maioria deles são atributos baseados em domínio (DBAs) na entidade Employee , incluindo o DBA do Departamento .

Começando com o SQL Server, há um novo tipo de nível que modela relações M2M, por exemplo: Class (mapeado via ClassRegistration.Student). O nome do nível é mais detalhado do que os outros para refletir as informações extras necessárias para descrever inequivocamente a relação de mapeamento. Arraste e solte este nível para o nível Funcionário na seção Níveis atuais :

mds_hierarchies_edit_derived_hierarchy_two

Agora, a visualização mostra os funcionários agrupados pelas classes de treinamento para as quais estão registrados. Uma vez que esta é uma relação M2M, cada membro filho pode ter vários pais. No exemplo acima, o funcionário 6 {Hillman, Reinout N} está registrado como aluno em duas classes, 1 {Master Data Services 101} e 4 {Career-Limiting Moves}.

Esta relação de mapeamento também pode ser exibida invertida, agrupando turmas por aluno:

mds_hierarchies_available_entities_and_hierarchies

Novamente, vemos como uma criança pode aparecer sob mais de um pai: a classe de treinamento 1 {Master Data Services 101} aparece em 6 {Hillman, Reinout N} e 40 {Ford, Jeffrey L}.

Os membros da entidade de mapeamento ClassRegistration não aparecem em nenhum lugar dentro da hierarquia derivada. Eles são usados meramente para definir as relações entre os membros pai e filho na hierarquia.

Você pode editar a relação M2M modificando os membros da entidade de mapeamento, seguindo um destes procedimentos. A relação M2M é de apenas leitura na página Derived Hierarchy Explorer.

  • Modifique os membros da entidade de mapeamento na página Explorador de Entidades, usando o complemento Master Data Services para Excel ou usando a preparação de dados.

  • Arraste e solte nós filhos entre os pais na página Explorador de Hierarquia Derivada.

    Este método modifica os membros existentes quando possível e adiciona novos membros quando necessário. Os membros existentes não são excluídos.

    Por exemplo, com a entidade de mapeamento ClassRegistration, ao mover um aluno para o nó não utilizado, o valor do atributo class do membro da entidade de mapeamento correspondente é alterado para nulo e o membro não é excluído. Por outro lado, ao mover um aluno do nó não utilizado para uma classe, se existir um membro de mapeamento correspondente ao aluno em que a classe é nula, esse membro é modificado alterando a classe de nula para a nova classe principal. Se nenhum membro for encontrado, então um é adicionado.

    Esse processo evita a exclusão de membros para evitar a exclusão indesejada de outros dados do usuário, por exemplo, se a entidade de mapeamento contiver outros atributos além dos dois que definem a relação pai-filho. Os usuários devem explicitamente fazer exclusões diretamente na entidade de mapeamento.

O novo nível M2M pode aparecer em qualquer parte de uma hierarquia derivada onde é permitido um nível de atributo baseado em domínio (DBA). Um nível M2M pode estar no topo, como nos exemplos acima. Pode estar acima e/ou abaixo de um nível de administrador de bases de dados (DBA), incluindo níveis recursivos. Pode estar sob um nível de limite de hierarquia explícita (preterido). Várias relações M2M podem ser encadeadas na mesma hierarquia derivada.

Os níveis M2M podem estar ocultos, assim como outros níveis de hierarquia derivados.

Relação M2M no modelo de amostra

Para obter uma demonstração de um relacionamento M2M, exiba a hierarquia derivada da Região Climática no modelo de Cliente de exemplo incluído no Master Data Services.

Como mostrado na imagem a seguir, o nome do nível que modela essa relação é mds_Number1Clima (mapeado via RegionClimate.Region). A mds_Number2mds_Number2Pré-visualização mostra regiões agrupadas pelos tipos de climas a que estão associadas. Esta é uma relação M2M porque existem regiões (membros crianças) que estão associadas a vários climas (pais). Por exemplo, mds_Number3APCR {Ásia-Pacífico} está associado a mds_Number4A {Tropical} e mds_Number5B {Dry}.

mds_M2MRelationship_Example_CustomerModel

Para obter instruções sobre como implantar o modelo de exemplo Customer e outros modelos de exemplo incluídos no Master Data Services, consulte Implantando modelos e dados de exemplo.

One-Many Relacionamento

Um membro de um DH pode ser o progenitor de muitos membros descendentes, mas geralmente não pode ter mais de um progenitor (para exceções, consulte Segurança do Membro). Por exemplo, suponha que existem duas entidades: Funcionário e Departamento, onde cada funcionário pertence a um único departamento. Essa relação é modelada adicionando à entidade Employee um atributo baseado em domínio (DBA) que faz referência à entidade Department:

mds_hierarchies_onetomany

Esta é uma relação um-para-muitos, porque cada funcionário pertence a apenas um departamento, mas cada departamento pode ter vários funcionários. Pode ser criada uma hierarquia derivada que exiba os funcionários agrupados por departamento:

mds_hierarchies_dh_screenshot

Segurança dos Membros

Uma hierarquia que permite a duplicação de membros (permite que um membro tenha mais de um pai) não pode ser usada para atribuir permissões de segurança de membro. Por exemplo:

  • Uma hierarquia derivada recursiva (RDH) que não ancora recursões nulas (cada membro no nível recursivo aparece em ROOT e seu pai recursivo).

  • Uma hierarquia derivada recursiva com um nível acima do nível recursivo (cada membro do nível recursivo aparece sob seu pai não recursivo e seu pai recursivo).

  • Uma hierarquia derivada com um nível M2M (uma criança pode ser mapeada para muitos pais).

Coleções

Coleções e hierarquias explícitas foram preteridas. O procedimento armazenado de conversão (udpConvertCollectionAndConsolidatedMembersToLeaf) converte membros da coleção em membros folha e cria hierarquias derivadas de muitos para muitos para capturar as informações de associação dos membros da coleção.

Ver também

Hierarquias derivadas (Master Data Services)