Auto-relacionamentos - MER

Muitas vezes queremos fazer o relacionamento de um CE consigo mesmo. Por exemplo, dado o CE “Peças” queremos saber quais peças são componentes de uma dada peça ou, dada peça quais peças tem a têm como componente. Esses dois relacionamentos podem ser representados pelo diagrama da figura abaixo. Observe que cada uma das ligações do losango com o CE Peças recebeu um rótulo. O primeiro rótulo significa: “uma peça é um componente” de outra peça, e o segundo rótulo significa “uma peça tem como componente” outra peça. Os rótulos de ligações explicitam o papel que a peça desempenha no relacionamento, Este papel é normalmente evidente nos relacionamentos. Observe também que o relacionamento é de cardinalidade N;N, isto é, uma peça pode ter vários componentes e uma dada peça pode ser componente de várias peças.

Conjunto de Entidades Fracos - MER

Há casos em que a existência de um CE está vinculada à existência de outro CE. Um exemplo típico é o registro, para fins de seguro-saúde ou imposto de renda, dos dependentes de um funcionário. Nesse caso o registro só faz sentido para a empresa porque o dependente está ligado ao funcionário. Diz-se, então, que o CE “Dependentes” é um conjunto de entidades fraco. O CE funcionários é as vezes chamado conjunto pai conjunto mestre e dependentes é as vezes chamado de conjunto detalhe.

CE´s fracos não possuem um atributo determinante , mas em geral utilizam o atributo determinante do conjunto pai para construir o seu atributo determinante. Por exemplo, o atributo determinante de Dependentes poderia ser o par (numf, o-dependente).

CE´s fracos são representador no MER por um retângulo de borda dupla e seu relacionamento com o conjunto pai por um losango também de borda dupla.

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.

Relacionamento entre Entidades | MER

Para relembrar:
MER - Modelo Entidade x Relacionamento

Sempre que duas entidades apresentarem interdependência (por exemplo, autor da música ou música do CD), indica-se um relacionamento entre elas. Deve-se perguntar a cada par de entidades se elas se relacionam. Para facilitar esse trabalho, siga o esquema abaixo:

Cada entidade 1 {deve ter ou pode ter} relacionamento {uma ou mais ou uma única} entidade2

Assim, podemos dizer que:
1 – Cada CD deve ser gravado por uma única gravadora;
2 – Cada gravadora pode ter gravado um ou mais CDs;

1 – Cada autor pode ter escrito uma ou mais músicas;
2 – Cada música pode ser escrita por um ou mais autores;

1 – Cada música pode estar gravada em um ou mais CDs.
2 – Cada CD deve conter uma ou mais músicas.

Conforme você pode notar, cada relacionamento contém um nome (normalmente um verbo como ser gravado, conter, ter escrito), a determinação de opcionalidade (deve ou pode) e um grau ou cardinalidade (uma única ou uma ou mais).

Análise dos tipos de Relacionamentos (Cardinalidade)

Há três tipos de relacionamentos:
- Um para um (1:1);
- Um para Muitos (1:n);
- Muitos para muitos (m:n);

Tipos de Atributos e Diagramas

Um atributo pode conter vários subatributos. Nesse caso ele se diz itens de grupo ou composto. Por exemplo:

Atributo: endereço
Subatributos: Local (Rua, Número, Complemento), Cidade, CEP.

A representação gráfica desse atributo composto é:

Funcionário (numf, RG, CPF, nome, end(rua, número, complemento, cidade, cep), salário)

Se um atributo de uma entidade pode tomar diversos valores então se diz multivalorado. Por exemplo:

Atributo: Telefone
Valores:
(99) 9999-9999
(44) 4444-4444

Essa propriedade pode ser indicada colocando-se um * após o nome do atributo multivalorado.

Funcionário (numf, nome, telefone*)

Convenção para utilização em Diagramas

Deve-se utilizar uma caixa de qualquer dimensão com um nome único (exclusivo) em cada uma das caixas. Esses nomes devem representar as Entidades do sistema. Alguns autores preferem utilizar a caixa com bordas arredondadas. Isso é apenas uma convenção diferente, que em nada modificará o objetivo e a compreensão da Entidade.

A seguir será utilizado o nome da Entidade de fora da caixa e separada a Chave primária dos demais atributos com uma linha horizontal:

Atributos | Chaves - Primária, Secundária e Estrangeira

É um atributos utilizado para indexar dados. Há três tipos de chaves:

• Primária
• Estrangeira;
• Secundária;

Chave primária
É o atributo que permite identificar uma única ocorrência de uma tupla em uma Entidade. Dessa forma, seu conteúdo deve ser único, exclusivo e imutável para cada linha dessa Entidade. Todos os demais atributos da entidade devem depender unicamente desse atributo.

Caso não exista um atributo que possa assumir a posição de chave primária, é preciso criá-lo. Veja que nem todos campos é uma boa chave. Normalmente utilizamos campos numéricos por serem localizados mais rapidamente pelos bancos de dados. Valores alfanuméricos grandes têm acesso mais lento.

Dessa forma, fica claro que toda tabela deve conter uma chave primária. Muitas vezes encontramos o termo super-chave para identificar a chave primária. Trata-se apenas de um nome diferente para designar a mesma coisa, e, portanto não é preciso se preocupar com isso.

Eventualmente uma chave primária pode conter mais de um atributo. Nesse caso, a chave conterá mais de um atributo, mas será considerada a chave da tabela. A união dos dois atributos é que deve garantir o acesso a uma única linha da entidade. Esse caso de chave primária é chamado de Chave Concatenada.

Chave estrangeira
É o atributo que estabelece a relação de uma Entidade com a Chave Primária de outra Entidade e permite uma relação entre entidades. Isto ocorre quando uma Entidade dependente herda a chave da Entidade Fundamental exatamente para estabelecer o relacionamento entre elas.

Chave Secundária

Esta chave é utilizada como meio de classificação e pesquisas em entidades. Sempre que houver a necessidade de buscar informações semelhantes, em ordem crescente ou decrescente, em função de datas, valores ou status predefinidos, criam-se chaves secundárias.

Podem também ser concatenadas a outras chaves secundárias para extrair a informação desejada.

O que são Atributos? | Modelagem de Dados

Os atributos são informações básicas que qualificam uma entidade e descrevem seus elementos ou características. Quando transpostos ao modelo físico (ao banco de dados), chamamos os atributos de campos ou colunas.

Note que todas as entidades devem possuir os atributos necessários ao andamento das operações da empresa, do contrário a entidade não será necessária para o sistema. Esses atributos devem representar o objeto na sua totalidade.

Há uma tendência a confundir Entidade e Atributo. Tenha sempre em mente que um Atributo é uma característica, logo não contém um grupo de informações. Por sua vez, uma Entidade sempre é um grupo. No mínimo são necessários dois atributos para criar uma entidade. Uma entidade com um único atributo normalmente será agregada a outra entidade existente ao modelo.

Exemplos de atributos as entidades:
- Entidade Pessoa: nome, endereço, documento, data de nascimento, telefone, e-mail;
- Entidade Nota Fiscal: série, número, data e emissão e cliente;

Nota-se, portanto, que ao utilizarmos o conceito de atributos em entidades estamos querendo qualificar ao máximo aquele objeto do mundo real. Essas informações muitas vezes não correspondem a todas as informações possíveis daquele objeto, mas sim às informações relevantes para o funcionamento do sistema.

No exemplo do catálogo de CDs, não teremos cada um dos CDs armazenados no banco de dados, mas sim as características que nos permitirão identificar qual CD o cliente quer comprar, quais músicas há naquele CD, autores, gravadoras etc. Não importa se há várias unidades do mesmo CD disponíveis para venda na loja (a menos que se esteja desenvolvendo um sistema que controle o estoque cd CDs). Esta deve ser uma preocupação quando estivermos desenvolvendo um novo sistema – até onde exatamente queremos
chegar com o sistema.

Um atributo chave é um dos atributos de um CE especialmente projetado para identificar de forma única qualquer entidade do CE.`É importante enfatizar a expressão acima especialmente projetado, porque a unicidade do valor do atributo determinante deve ser garantida para qualquer conteúdo futuro do CE e não apenas para a instancia atual do CE. Resumindo: um CE fica especificado no modelo entidade-relacionamento, dado o nome do CE, os nomes dos atributos do CE, os nomes do CE e dentre esses o nome do atributo chave. Uma forma textual de definir um CE poderia ser, por exemplo:

Funcionário (numf, RG, CPF, nome, end, salário)

Tupla
É uma estrutura de atributos intimamente relacionados e interdependentes que residem em
uma entidade. Quando transposta ao modelo físico, uma tupla equivale a um registro ou linha da tabela.