Aula 2 modelos entidaderelacionamento MER Modelo Conceitual de

Aula 2 – modelos entidaderelacionamento (MER)

Modelo Conceitual de Dados • Modelo de Entidade e Relacionamentos (E/R) • Modelo de mais alto nível que descreve as estruturas de um banco de dados independente de tecnologia Ex: Modelo E/R - Coleção de entidades e relacionamentos CPF End. Pessoa Num. possui saldo Conta corrente

Projeto de Banco de Dados Conjunto de atividades a serem realizadas para efetuar a representação de informações do mundo real em um Sistema de Banco de Dados, através de modelos de dados

Modelo Entidade e Relacionamento “O modelo de dados entidade-relacionamento baseia-se na percepção de um universo constituído por um grupo básico de objetos chamados entidades e por relacionamentos entre estes objetos. Ele foi desenvolvido a fim de facilitar o projeto de banco de dados permitindo a especificação de um esquema de empreendimento. Tal esquema representa a estrutura lógica global do banco de dados. ”

Entidade e Relacionamento

Chaves - Chave Primária: Toda tabela deve ter um campo ou conjunto de campos que identificam o registro. No caso de tabelas cadastrais ou fortes, esta chave será simples, ou seja, formada por um só campo. No caso de tabelas de movimento ou fracas, esta chave será formada por mais de um campo.

Regras para se definir as chaves - Elas não podem ser nulas; - Devem ser campos pequenos, preferencialmente numéricos

Entidades fortes ou cadastrais São as entidades onde os registros existem, sem dependerem da existência de outro. Normalmente a chave é simples (formada por 1 só campo). Ex. : alunos, produtos, clientes, etc.

Entidades fracas Seus registros só existem se existir um registro relacionado na entidade forte. A chave primária é composta por mais de um campo. Ex. : músicas, notas, mensalidades, etc

Chave estrangeira É o campo que faz parte da chave primária composta na entidade fraca. Este campo, obrigatoriamente, deverá estar relacionado com o campo chave primária simples na entidade forte. Notas Ex. : Alunos Cod_alunos (CE) Cod_alunos bimestre Nome Cod_materia endereço Valor

Atributos multi-valorado Nas tabelas, existem alguns campos que podem ou necessitam assumir mais de um valor. Ex. : telefone ( pode ser residencial, comercial, celular)

Relacionamentos Para que se possa implementar um BD não repetindo nem deixando dados importantes de fora, devemos compartilhar as informações. A este compartilhamento, damos o nome de relacionamento.

Para que haja o relacionamento, três condições devem ser satisfeitas: 1) Campos do mesmo tipo 2) Campos do mesmo tamanho 3) Campos afins Ex: cod_aluno deve-se relacionar com cod_aluno Obs. : Os campos podem ou não ter o mesmo nome

Tipos de relacionamentos 1) 1: 1 (um para um) Funcionário Departamento codfunc Coddepto Nome nome Endereco codfunc salario

2) 1: N (um para muitos) Alunos Notas Codaluno Nome Coddisciplina endereco valor

3) N: M (muitos para muitos) Médico Paciente Este tipo de implementação é incorreta, pois um médico pode ter vários pacientes e vários pacientes podem ter um ou mais médicos. Para resolver a situação, utilizaremos uma entidade associativa: médico consulta pacientes

Exercícios de fixação 1) Construa o modelo físico de BD para seguinte situação: Juvenal tem uma empresa de manutenção de computadores e necessita de um BD para controlar os equipamentos, clientes e manutenção. Neste BD, deve-se preocupar com a entrada e saída de equipamentos, sua configuração e manutenção sofrida. Não há necessidade de se preocupar com a parte financeira da empresa.

2) Construa um modelo físico de BD para uma locadora, onde deve haver um controle para os filmes, clientes e locação. 3) Construa um modelo físico de BD para uma clínica médica, para controlar médicos, pacientes e consultas.