Atributos de Relacionamentos - MER

Relacionamentos podem ter atributos. Por exemplo, o relacionamento N:N para indicar a associação de Materiais com seus Fornecedores pode indicar para cada par do relacionamento, o preço, o prazo e lote (quantidade) que o fornecedor estabelece para fornecer o material. A Figura abaixo mostra a representação gráfica desse relacionamento.

Poderíamos questionar nesse exemplo se um dado atributo, digamos, preço, pertence de fato ao relacionamento em vez de a um dos conjuntos de entidades envolvidos. Um teste simples é capaz de esclarecer a dúvida. Fixe o material e varie o fornecedor: se o preço varia, então o atributo não é do material; em seguida, fixe o fornecedor e varie o material: se o preço varia, então o atributo não é do fornecedor. Fica claro, nesse caso, que o atributo preço é do relacionamento, isto é, cada par (material, fornecedor) possui um preço. Idem aos atributos prazo e lote.

Relacionamento M:N (ou N:N) - Relacionamento entre Entidades | MER

Ocorre sempre que uma entidade se relacionar com várias tuplas de outra entidade e esta, por sua vez, relacionar-se com várias tuplas daquela entidade.

Esse relacionamento somente é possível na modelagem lógica de dados, uma vez que não se consegue implanta-lo em banco de dados relacionais. Ele será transformado em dois relacionamentos: um para muitos (1:n) e uma Entidade Associativa Atributiva será identificada, caso haja outras informações que devam ser agregadas a esta nova entidade – por exemplo de item de pedido em que se identificam quantidade e preço, ou criada, caso seja a simples união das chaves primárias de ambas as entidades – caso de vários produtos serem fornecidos por vários fornecedores e vice-versa.Esses relacionamentos são facilmente encontrados e normalmente são opcionais em ambas entidades. Existem casos em que há opcionalidade de apenas em uma das duas direções.

Nos exemplos a seguir, cada Música é composta por um ou vários Autores, e cada Autor pode compor uma ou várias Músicas. Cada Produto é fornecido por vários Fornecedores e cada Fornecedor pode fornecer vários Produtos. E, finalmente, cada Aluno é inscrito em uma ou várias Matérias e cada Matéria possui vários Alunos.

Neste exemplo, se uma entidade de um CE está associada a várias outras entidades de outro CE e vice-versa. só pode estar associada a uma única entidade de outro CE e vice-versa, dizemos então que o relacionamento é de cardinalidade N para N ou N:N.

Relacionamento 1:N (ou N:1) - Relacionamento entre Entidades | MER

Ocorre sempre que uma entidade se relacionar com uma ou mais tuplas da outra entidade e esta outra se relacionar apenas com uma tupla daquela entidade.

Esse relacionamento é mais comum e fácil de ser analisado. Nesse caso, a parte onde o relacionamento é 1 contém os dados básicos da entidade (pois é a chave primária dessa entidade) e o lado muitos fará parte da lista de atributos não chave.

Relacionamentos desse tipo raramente são obrigatórios em ambas as entidades. A exceção é quando se trata de itens de uma entidade, como itens de nota fiscal ou pedidos. Mas esse parece ser um caso especial de muitos para muitos.

A seguir, exemplos em que isso ocorre: Cada Gravadora grava vários CDs e cada CD é gravado apenas por uma Gravadora. Cada Cliente possui vários Pedidos e cada Pedido é de um único Cliente.

Neste exemplo, vários funcionários podem estar lotados num único departamento. Dizemos então que o relacionamento Lotações de Funcionários com Departamento é de cardinalidade N para 1 ou N : 1.

A cardinalidade do relacionamento está indicada pelos símbolos N e 1. Para determinar sua posição correta pode-se usar o seguinte argumento: “um funcionário existe em um único departamento e em um único departamento podem existir vários funcionários”.

Relacionamento 1:1 - Relacionamento entre Entidades | MER

Ocorre sempre que uma entidade tiver uma única ocorrência para cada ocorrência na outra entidade.

Sempre que houver esse relacionamento, deve-se perguntar se realmente são duas entidades distintas ou se elas podem ser unidas. Normalmente, ao checarmos a chave de ambas as entidades, chegamos facilmente à conclusão se as entidades devem ou não ser unidas. Da mesma forma, deve-se perguntar se esse relacionamento sempre será um para um ou se existe a possibilidade de, amanhã, vir a ser um para muitos.

Note que esse relacionamento é efetivamente raro. Relacionamentos em que seja obrigatória em ambas as entidades são mais raros ainda.

No exemplo a seguir, cada departamento é gerenciado por um gerente, e cada gerente gerencia um departamento. As chaves são distintas (são objetos absolutamente diferentes), mas é interessante nos questionarmos, mesmo que eventualmente, se um gerente não pode gerenciar mais de um departamento. Isso pode ou não ocorrer, dependendo da empresa, mesmo que seja por um curto período de tempo. Nesse caso, o relacionamento deveria ser trocado para um para muitos (1:n);

Isso também ocorre com o relacionamento entre Computador e Para Mãe. Essa pergunta deve ser feita à possibilidade de um computador possuir mais de uma Placa Mãe no futuro.

Neste exemplo, se uma entidade de um CE só pode estar associada a uma única entidade de outro CE e vice-versa, dizemos então que o relacionamento é de cardinalidade 1 para 1 ou 1:1.