Mapeando MER para o Modelo Relacional | Atributos Multivalorados, Agregação e Relacionamento 1 para 1

• Atributos Multivalorados: novas tabelas devem ser criadas para armazená-los juntamente com a chave primária da entidade que os possui. Exemplo:

Livros (No_tombo, título, ano, editora)

Autores (No_tombo, autor)

• Agregação: como a agregação é a representação de um conjunto de relacionamentos como se fosse um conjunto de entidades, o mapeamento para tabelas é semelhante ao mapeamento aplicado em entidades e relacionamentos normais.
• Relacionamentos de 1 para 1: para decidir como será feita a transposição de chaves, deve-se observar a participação total com relação ao relacionamento.

Exemplo:

Todo país tem uma capital, mas nem toda cidade é capital de um país, portanto a tabela de países é que deve receber a código da cidade que é capital.

Países (código, nome, continente, código_capital)

Cidades ( código, nome, população)

OBS: Relacionamentos Binários de 1 para n podem gerar tabela quando não há totalidade na associação.

Fonte: Apostila professores Cláudio e Carrilho, download em Março/2006

Mapeando MER para o Modelo Relacional | Generalização e Especialização

• Generalização e Especialização: há duas maneiras de definir as tabelas para uma generalização ou especialização:
• Define-se uma tabela para o conjunto de entidades do nível mais alto (com os atributos comuns) e uma tabela para cada entidade do nível mais baixo (com seus atributos próprios + a chave primária da entidade do nível mais alto). Exemplo:

Contas (número, saldo)

Contas_corrente (número, limite)

Contas_poupança (número, data_base)

• Define-se tabelas apenas para os conjuntos de entidades do nível mais baixo (com seus atributos próprios, mais todos os atributos herdados do conjunto de entidades do nível mais alto).
  Essa opção só é permitida se a generalização / especialização for mutuamente exclusiva (uma entidade não pertence a mais do que um dos subconjuntos) e total (todas as entidades do nível mais alto pertencem a um dos subconjuntos do nível de baixo). Exemplo:

Contas_corrente (número, saldo, limite)

Contas_poupança (número, saldo, data_base)

Fonte: Apostila professores Cláudio e Carrilho, download em Março/2006

Mapeando MER para o Modelo Relacional | Relacionamentos

• Conjunto de Relacionamentos: podem ou não gerar tabelas:
• Relacionamentos Múltiplos ou Relacionamentos Binários de N para N: geram tabelas com as chaves primárias das entidades envolvidas mais os atributos próprios do relacionamento. Exemplo:

                 
                Usuários (COD, nome, fone)

                Livros (No_tombo, título, ano, editora)

                Empréstimos (COD, No_tombo, data_ret, data_dev)

• Relacionamentos Binários de 1 para N ou de 1 para 1: não geram tabelas. Para associar as tuplas das tabelas no Modelo Relacional deve-se transpor a chave de um conjunto de entidades para o outro ( a chave da entidade do lado com 1 é transposta para a entidade do lado n). A chave transposta nesse caso não compõe a chave primária da entidade que a recebeu (é uma chave estrangeira).
  Obs: no caso da transposição de chave entre a entidade forte e a entidade fraca que dela depende, a chave transposta compõe a chave primária da entidade fraca). Exemplo:

                 Países (código, nome, continente)

                 Cidades ( código, nome, população, código_país)

Fonte: Apostila professores Cláudio e Carrilho, download em Março/2006

Mapeando MER para o Modelo Relacional | Entidades

Um Diagrama de Entidade relacionamento pode ser representado por um conjunto de tabelas ( esquema do Modelo Relacional)

• Conjunto de Entidades: cada conjunto de entidades do DER gera uma tabela no Modelo Relacional.
• Entidades Fortes: tabela com seus atributos próprios

Contas (Número, saldo)

• Entidades fracas: tabela com chave primária da entidade forte da qual ela depende mais seus atributos próprios

Carros (chassi, marca, modelo, ano, cor, placa)

Reparos (chassi, data, tipo, valor, oficina)

Fonte: Apostila professores Cláudio e Carrilho, download em Março/2006

Integridade Referencial - Banco de Dados

É um mecanismo utilizado para manter a consistência das informações gravadas. Dessa forma, não são permitidas a entrada de valores duplicados nem a existência de uma referência a uma chave inválida em uma entidade.

É importante enfatizar o conceito de integridade referencial. É também necessário que cada valor de chave estrangeira possua uma ocorrência na outra entidade à qual faz referência. Se isso não ocorrer, fica claro que estaremos perdendo uma informação importante para o sistema. Exemplo: se tivermos um valor na entidade CD correspondente à gravadora (chave estrangeira) e não tivermos o mesmo valor (chave primária) na entidade Gravadora, estaremos diante de um problema, pois teríamos um CD sem uma Gravadora válida.

A maior parte dos bancos de dados relacionais estabelece esse tipo de relacionamento e impede que durante uma inclusão, exclusão ou alteração uma chave estrangeira de uma entidade não tenha correspondente na chave primária da outra entidade. Assim, em uma inclusão na entidade com a chave estrangeira, caso seja informado um código que não exista, correspondente na outra entidade, deve ser gerada uma mensagem de erro. Assim, caso queiramos incluir um CD com um código de Gravadora que não exista, correspondente na tabela Gravadora, deve ser enviada uma mensagem de erro e impedida a gravação da informação.

No caso de uma alteração ou exclusão na chave primária da entidade, deve-se verificar se há registros dependentes (chave estrangeira) nas demais tabelas. Se houver, deve-se excluir todos os registros dependentes ou alterá-los, dependendo do caso. Isso poderia ocorrer caso quiséssemos excluir ou alterar uma Gravadora e tivéssemos CDs armazenados com o código da Gravadora. Se fosse permitido, teríamos uma informação inválida, pois ao tentarmos localizar a Gravadora deste CD, isso não seria possível.

Caso o seu banco de dados não disponha desse recurso, você deverá levar isso em consideração e criar mecanismos que evitem o problema. Quanto o banco de dados dispuser desse recurso, este adotará o nome CONSTRAINT.

Em alguns bancos de dados é possível controlar até a propagação de exclusões ou alterações na chave primária: ou se apagam todos os registros dependentes ou se altera o seu código. Assim, caso excluíssemos ou alterássemos uma determinada Gravadora, todos os CDs dessa gravadora seriam automaticamente excluídos ou alterados. Note que isso é bastante perigoso, pois normalmente nenhuma mensagem será dada ao usuário. A regra será a automática modificação das informações no banco de dados.

Especificação - MER

As técnicas de orientação a objetos tiveram várias influencias sobre o projeto de bases de dados. Uma delas é o conceito de subclasse e herança. Muitas vezes queremos registrar características especiais de certos subconjuntos de um CE. Por exemplo, no CE Funcionários temos secretária, técnicos, engenheiros, gerentes etc, e para cada uma dessas categorias queremos guardar alguns atributos específicos, como habilidades das secretárias em digitação, informática, línguas etc. Outros atributos seriam requeridos para engenheiros e assim por diante. Seria ineficiente estender o CE Funcionários com todos esses atributos que só teriam valores para cada grupo específico de funcionários ficando vazios os não correspondentes ao grupo. Para este fim criamos os CE´s denominados Secretárias, Técnicos, Engenheiros etc, e um tipo especial de relacionamentos desses CE´s chamado “é um” e representado por um triângulo.

Esses novos CE´s são também chamados de especializações do CE Funcionários. Como o nome “é-um” indica, o relacionamento significa que uma secretária “é uma” funcionária, isto é, possui todos os atributos do CE funcionário.

O símbolo “+” indica que a especialização é do tipo “ou exclusivo”, ou seja, um funcionário pode ser especializado em apenas um dentre “Secretárias”, “Técnicos” e “Gerentes”.

Agregações - MER

Há casos em que relacionamentos de grau superior a 2 não capturam as regras de negócio desejadas. Por exemplo, no relacionamento triplo MRP visto anteriormente em materiais, requisições e pedidos (ordens de compra), uma requisição está relacionada com um ou mais materiais e com um ou mais pedidos (ou com nenhum deles), o que é artificial.

Requisições precedem a pedidos no tempo e originalmente estão relacionadas apenas com Materiais, já que toda requisição é criada para comprar um ou mais materiais. Elas se originam em diversos setores da empresa e são encaminhadas ao setor de compras. O setor de compras associa um pedido de compra ao par (requisição, material), portanto, ao relacionamento, especificando a quantidade a ser comprada ( que pode ser diferente da requisitada, por exemplo, para obter um desconto maior ou devido a alguma restrição de tamanho de lote de venda). Esta separação de funções implica na existência de dois relacionamentos distintos; o segundo é chamado de agregação porque o relacionamento de Materiais com Requisição é agregado em um pseudo CE, que por sua vez se relaciona com Pedidos através do relacionamento “Itens de pedidos”.

Relacionamento de Grau 3 - MER

Os exemplos vistos até agora são de relacionamento envolvendo dois CE´s. Eles são ditos binários ou de grau 2 e são os mais comuns na prática. O grau de um relacionamento é um número de CE´s envolvidos no relacionamento. A figura abaixo mostra um relacionamento de grau 3, ou triplo, entre professores, alunos e disciplinas.

A cardinalidade desse relacionamento, 1 : N : N, pode ser interpretada da seguinte forma:
- dado um professor e uma determinada disciplina temos diversos alunos;
- dado um professor e um determinado aluno, temos diversas disciplinas;
- dado um aluno e uma certa disciplina, temos um único professor;

A figura abaixo mostra um relacionamento triplo chamado MRP entre Materiais, Pedidos e Requisições, típico de um sistema de compras de materiais, onde requisições vindas de diversos setores são agrupadas em pedidos ou ordens de compra e se deseja relacionar cada pedido com as requisições originais. O relacionamento possui dois atributos: quantidade requisitada e quantidade pedida. O relacionamento tem cardinalidade N : N : N e é total do lado de Pedidos e de Requisições (toda requisição está associada a um ou mais pedidos e pode conter vários materiais, idem para pedidos), mas é parcial do lado de Materiais (um dado material pode não estar sendo comprado no momento).

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);

Terceira Forma Normal (3NF)

Uma entidade está em Terceira Forma Normal se e somente estiver em Primeira e em Segunda Forma Normal e todos os atributos não chave dependerem funcionalmente da chave primária.

Exemplo:
Pedido (nro_pedido, data, cod_cliente, nome_cliente, email_cliente, valor_total_pedido)

Vamos verificar a dependência funcional dos atributos:
nro_pedido -> data
nro_pedido -> cod_cliente
nro_pedido -> valor_total_pedido
cod_cliente -> nome_cliente
cod_cliente -> email_cliente

Verificamos que os atributos nome_cliente e email_cliente não são dependentes da chave primária e sim do atributo cod_cliente. Será necessário então desmembrar a entidade pedido.

Pedido (nro_pedido, data, cod_cliente, valor_total_pedido)
Que terá como chave primária o atributo nro_pedido.

Cliente (cod_cliente, nome_cliente, email_cliente)
Que terá como chave primária o atributo cod_cliente.

Segunda Forma Normal (2NF)

Uma entidade encontra-se em Segunda Forma Normal se e somente estiver em Primeira Forma Normal e não tiver atributos com dependências parciais. No caso de uma chave primária composta, isto é, que possui mais de um atributo em sua composição, é denominada dependência parcial a dependência de um atributo não chave a apenas uma parte da chave primária.

Tomemos como exemplo a tabela compra, descrita abaixo:

Compra (nro_nf, cod_fornecedor, cod_produto, data,nome produto, quantidade, valor_unitario, valor_total_nota)

Tendo como chave primária os atributos: nro_nf, cod_fornecedor, cod_produto

Se analisarmos a dependência funcional teremos:
nro_nf, cod_fornecedor --> data
nro_nf, cod_produto --> quantidade
nro_nf, cod_produto --> valor_unitario
nro_nf, cod_fornecedor --> valor_total_nota
cod_produto --> nome_produto

Vemos agora que nem todos os atributos dependem da chave primária. O que não é permitido pela Segunda Forma Normal. Para que essa entidade fique em 2NF, teremos de desmembrá-la.

Ela ficará assim:

Compra (nro_nf, cod_fornecedor, data, valor_total_nota)
Tendo como chave primária os atributos nro_nf e cod_fornecedor e como chave estrangeira o atributo cod_fornecedor.

Item_compra (nro_nf, cod_produto, quantidade, vl_unitario)
Tendo como chave primária os atributos nro_nf e cod_produto e como chaves estrangeiras os atributos nro_nf e cod_produto.

Produto (codigo, nome)
Tendo como chave primária o atributo codigo.

Primeira Forma Normal (1NF)

Uma entidade está em Primeira Forma Normal, se e somente todos os seus atributos são atômicos, isto é, se contém um valor único (atômico) e não contém atributos multivalorados.

Exemplo:
Dada a entidade funcionario, definida com os atributos abaixo:
Funcionario (codigo, nome, data_admissao, data_demissao, habilidades)

Vemos que a entidade funcionario possui o campo multivalorado habilidades, o que não é permitido pela Primeira Forma Normal. Devemos então dividir a tabela funcionario de forma que o campo habilidades se torne uma nova entidade.

Então teremos:
Funcionario (codigo, nome, data_admissao, data_demissao)
Possui (cod_funcionario, cod_habilidade)
Habilidade (codigo, descricao)

Exemplo:
Fornecedor (codigo, nome, endereco, telefones)

Vemos que a entidade fornecedor tem como atributo composto endereco e como atributo multivalorado telefones.

Em relação ao atributo composto endereco, sabemos que o mesmo é composto, pois nele pressupõe-se incluir as informações de rua, complemento, bairro, cidade, estado e cep . Ou substituímos o atributo endereco por seus atributos componentes (rua, complemento, bairro, cidade, estado e cep ) ou criamos uma
outra entidade com o nome do atributo composto (endereco), tendo como atributos dessa nova entidade rua, complemento, bairro cidade, estado e cep.

Já o campo telefones, por estar no plural, indica que nele poderá ser armazenado mais de um número. Pela regra, esse atributo precisa ser separado em outra entidade, que pode ser chamada de telefone e que conterá os diversos números de telefone do fornecedor.

Assim, temos:
Fornecedor (codigo, nome, rua, complemento, bairro, cidade, estado, cep)

Tendo como chave primária o atributo codigo.
Telefone (cod_fornecedor, nro telefone)

Tendo como chave primária os atributos cod_fornecedor e nro_telefone, já que isso garante que não será cadastrado o mesmo telefone para o forncedor e como chave estrangeira o atributo cod_fornecedor.

Fornecedor (codigo, nome)

Tendo como chave primária o atributo código.
Endereco (cod_fornecedor, rua, complemento, bairro, cidade, estado, cep).

Tendo como chave primária o atributo cod_fornecedor e como chave estrangeira o atributo cod_fornecedor.

Saiba o que é Normalização

Normalização é um processo utilizado para acertar possíveis problemas estruturais das entidades e relacionamentos com campos criados – também chamados de anomalias – em um modelo de entidade e relacionamento. Consiste na análise dos atributos das entidades e relacionamentos com campos, sob o ponto de vista das regras chamadas formas normais, que descrevem, com base na teoria de conjuntos, na álgebra e no cálculo relacional, o que devemos ou não fazer nas estruturas das entidades e relacionamentos de nosso modelo, baseados em conceitos matemáticos.

Essa análise pode demonstrar a necessidade de alterarmos a estrutura de nossas entidades e relacionamentos com campos, dividindo ou agrupando seus atributos para aprimorar o processo de recuperação das informações (performance) e seu armazenamento, de modo a evitar perda, redundância e distorção da informação.

Sempre que formos obrigados pela aplicação das formas normais em nosso modelo a dividir entidades, temos que garantir que a divisão poderá ser revertida, isto é, que, mesmo particionada em duas ou mais entidades, uma entidade poderá voltar à sua formação original, por meio de operações de conjuntos.

Dependência funcional
Seja R uma relação e X e Y atributos de R. X e Y podem ser atributos simples ou compostos.
X --> Y (o atributo X determina funcionalmente o atributo Y) sempre que duas tuplas quaisquer de R tiverem o mesmo valor para X, elas possuem também o mesmo valor para Y.

Exemplo:
Tendo a entidade funcionario os atributos codigo, nome, cidade e DDD, e sabendo  que o codigo é a chave primária da entidade funcionario, se analisarmos esses atributos sob a óptica da dependência funcional, teremos:
codigo -->  nome
codigo -->  cidade
cidade -->  DDD

Logo, podemos dizer que os atributos nome e cidade dependem do atributo codigo. Já o atributo DDD depende do atributo cidade. Definida a dependência funcional, nas próximas postagens abordaremos sobre as definições das formas normais.