Aula 5 - Construcao de modelos

Prévia do material em texto

Construção de modelos 
entidade-relacionamento
Banco de dados 1
Fabrício Nogueira
fabricio.silva@uva.br
Relembrando
• Entidades
• Atributos
• Relacionamentos
• Cardinalidades
• Generalização/Especialização
• Entidade associativa
Propriedades do MER
• Diferentes modelos podem ser equivalentes
• Dois modelos são equivalentes quando geram o mesmo esquema de 
banco de dados
Médico PacienteConsulta
n n
Médico Paciente
(1,1)
Consulta
(0,n) (0,n) (1,1)
Propriedades do MER
• Diferentes modelos podem ser equivalentes
• Relacionamentos n:m podem ser transformados em entidades
• É possível construir modelos sem relacionamento n:m, porém equivalentes 
aos que usam relacionamento n:m
• Relacionamentos 1:1 podem ser eliminados, unificando-se as 
entidades
Empregado Mesa
(1,1) (1,1)
Empregado
Atributos da mesa
Determinando construções
• Entidade, Relacionamento, atributo, ...?
• A escolha não pode ser observando-se o objeto isoladamente
• Depende do contexto
• A decisão pode sofrer alterações durante a modelagem
Determinando construções – Critérios
• Atributos vs entidade relacionada
Automóvel
Número do chassi
Cor
Automóvel
Número do chassi
Cor
(1,1)
(0,n)
OU
Útil quando se 
pretende manter 
informações extras 
sobre a cor 
(fabricante, data de 
validade, etc)
Determinando construções – Critérios
• Atributos vs entidade relacionada
• Caso o objeto em discussão tenha atributos, relacionamentos, entidades 
genéricas ou especializadas  Entidade
• Atributo não pode ter atributos
• Atributos não pode estar relacionado a outras entidades
• Atributo não pode ser generalizado/especializado
• Ex.: Cor
• Seria entidade se precisássemos armazenar: fabricante, data de início e fim de uso da 
cor,
• Seria atributo se precisássemos armazenar apenas o valor da cor
Determinando construções – Critérios
• Atributo vs especialização
• Especializações devem ser usadas quando sabe-se que as entidades 
especializadas possuem propriedades particulares (atributos, 
relacionamentos, generalizações, especializações)
Empregado
Motorista Engenheiro
xt
Nome Código
cnh validade CREA
EmpregadoNome Código
Categoria 
funcional
Determinando construções – Critérios
• Atributo vs especialização
• Especializações devem ser usadas quando sabe-se que as entidades 
especializadas possuem propriedades particulares (atributos, 
relacionamentos, generalizações, especializações)
Empregado
Homem Mulher
xt
Nome Código
EmpregadoNome Código
sexo
Determinando construções – Critérios
• Atributos opcionais
• A existência de atributos opcionais indicam uma possível modelagem de 
entidades especializadas
EmpregadoNome
Código
CREA CRM
CNH Validade CNH
Tipo de empregado
Empregado
Motorista Engenheiro
xt
Nome Código
cnh validade CREA
Médico
CRM
Determinando construções – Critérios
• Atributo multivalorado
• Atributo cujos valores podem ter mais de uma ocorrência
Empregado
Nome
Dependente(0,n)
Lançamento pagamento (0,n)
Determinando construções – Critérios
• Atributo multivalorado
• Indesejados
• SGBDs relacionais não possuem uma representação direta de um atributo multivalorado
• Ex.: Dependente = [Ana, Carla, Pedro, Raul]
• SGBDs relacionais representam múltiplos valores através de um atributo texto
• Ex.: Telefone = “Ana, Carla, Pedro, Raul”
• Não existe qualquer regra para se obter um nome específico
• Não existe qualquer regra que defina um delimitador entre os dependentes, o exemplo utiliza 
“,”, mas poderia ser “-”, “_”, “ “, etc
• Podem induzir a um erro de modelagem, pois podem ocultar entidades e 
relacionamentos em atributos multivalorados
• Analisando-se a entidade Empregado, percebe-se que dependente pode ter outros atributos 
(nome e data de nascimento). Lançamento pode ter um código e um tipo
Determinando construções – Critérios
• Atributo multivalorado
Empregado
Tipo 
lançamento
Dependente
Nome
matrícula
nome
(1,1)
1
descrição
Pagamentovalor
código
(0,n)
(1,1)
(0,n)
(1,1)
(0,n)
Data de nascimento
Verificação de modelo
• O modelo deve ser completo
• Deve retratar todos os dados presentes no negócio
• Só pode ser verificado por um especialista do domínio  Envolver usuário
• O modelo deve ser livre de redundância
• Deve ser mínimo
• Não deve aparecer no modelo
• Devem ser explicitamente documentadas como redundantes
• Relacionamentos redundantes são os resultantes da combinação de outros 
relacionamentos entre as mesmas entidades
• Não há perda de informação ao eliminá-los
Verificação de modelo
Fábrica
Empregado
Departamento
(1,1)
(1,1)
(0,n)
(1,1)
(0,1)
Máquina
Sindicato
(0,n)
(0,n)
(0,n)
(0,n)
(0,n)
(1,1)
(0,n)
(0,n)
Verificação de modelo
Departamento Empregados
(1,1) n
código
Quantidade de 
empregados
Código do 
departamento
Verificação de modelo
• O modelo deve refletir o aspecto temporal
• Certas aplicações exigem que o banco de dados mantenha o histórico de 
alteração de informações
• Dados temporais
• Mudam ao longo do tempo e para os quais o BD deve manter um histórico
• Atributos cujos valores mudam ao longo do tempo
• Ex.: Salário
• Relacionamentos que mudam ao longo do tempo
• Ex.: Alocação de um empregado 
• Não há regra, porém alguns padrões
Verificação de modelo
• O modelo deve refletir o aspecto temporal
• Atributo temporal. Ex.: Salário
Empregado
Salário
Empregado
Salário
Data valor
Empregado
Salário
Início valor
fim
Apenas a 
informação do 
salário atual
Apenas a 
informação do 
salário atual
Histórico da 
evolução do 
salário
Verificação de modelo
• O modelo deve refletir o aspecto temporal
• Relacionamento temporal. 1:1 e 1:n  n:n
Empregado Empregado
Mesa
Data
Alocação
Mesa
Alocação
1
1 n
n
Alocação atual 
do empregado Histórico de 
alocações
Verificação de modelo
• O modelo deve refletir o aspecto temporal
• Relacionamento temporal. 1:1 e 1:n  n:n
Empregado Empregado
Departamento
Data
Lotação
Departamento
Lotação
n
1 n
n
nome nome
Lotação atual 
do empregado Histórico de 
lotações
Verificação de modelo
• O modelo deve refletir o aspecto temporal
• Relacionamento temporal. n:n n:n com atributo identificador
Participante Participante
Curso
Data
Inscrição
Curso
Inscrição
n
n n
n
Data
Inscrição de um 
participante em 
um curso em 
dado instante
Inscrição de um 
participante em vários 
cursos ao longo do tempo
Verificação de modelo
• Evitar entidades isoladas
• Entidades que não se relacionam com nenhuma outra
• Podem ocorrer raramente
• Devem ser evitadas
• Exemplo
UF
Estratégias de modelagem
• O modelo não é construído num único passo
• Processo incremental
• Diferentes propostas de modelagem proposta
• Nenhuma proposta é universalmente aceita
• A melhor estratégia depende da fonte de informação a ser 
considerada
• Descrição de dados existentes
• Conhecimento de especialistas do negócio
Estratégias de modelagem
• A partir de descrições de dados existentes
• Modelo para um sistema já existente  Engenharia reversa
• Documentos (pastas, fichas, documentos fiscais, ...)
• Ascendente
• Maior detalhe para mais abstrato
• 1. Atributos
• 2. Entidades
• 3.1 Relacionamentos
• 3.2 Generalizações/Especializações
Estratégias de modelagem
• A partir do conhecimento das pessoas
• Novos sistemas sem descrição de dados sendo concebidos
• Descendente
• Do mais abstrato para os mais detalhados• 1. Entidade genéricas
• 2. Atributos
• 3.1 Relacionamentos
• 3.2 Atributos dos relacionamentos
• 4. Especializações
Estratégias de modelagem
• A partir do conhecimento das pessoas – Descendente
• Modelagem superficial  DER pouco detalhado
• 1. Enumeração das entidades
• 2. Relacionamentos e hierarquias de generalização/especialização e cardinalidades
• 3. Determinação dos atributos de entidades e relacionamentos
• 4. Determinação dos identificadores (entidades e relacionamentos)
• 5. Verificação do aspecto temporal
• Modelagem detalhada  Domínios dos atributos e cardinalidades mínimas
• 6. Adiciona-se os domínios dos atributos (Ex.: texto, número, data)
• 7. Determinação das cardinalidades mínimas
• 8. Demais restrições que não são cobertas pelo MER
• Validação do modelo
• 9. Verifica a existência de redundâncias
• 10. Validação com especialista do domínio
• Em qualquer etapa é possível retornar passos anteriores
Estratégias de modelagem
• A partir do conhecimento das pessoas - Inside-out (de dentro para 
fora)
Empregado
nome cpf
tipo
Lotação Departamento
(0,n) (1,1)
Gerente
Lotação
(1,n)
(0,1)
Secretária
Engenheiro
CREA
Alicação
Domínio
Projeto
(0,n)(0,n)
(0,n)
Editor de texto
(1,n)
Notações alternativas
• Notação vista até agora  Peter Chen
• Notação engenharia de informações
• Notação UML
Notações alternativas
• Notação engenharia de informações
Notações alternativas
• Notação UML