DCC011 Introdução a Banco de Dados Projeto de Bancos de

DCC011
Introdução a Banco de Dados
Projeto de Bancos de Dados
Mirella M. Moro
Departamento de Ciência da Computação
Universidade Federal de Minas Gerais
[email protected]
Construindo Esquema Conceitual
Na primeira parte da matéria aprendemos a notação
de modelos ER
Agora vamos aprender a construir esquemas
conceituais, garantindo suas propriedades formais
Construindo o Esquema
Conceitual
1. Propriedades do Esquema Conceitual
2. Processo de construção
1. Propriedades de Modelos ER
(a) Modelo ER é um modelo formal
(b) Poder de expressão é limitado
(c) Equivalência entre modelos
Slide adaptado de HEUSER
Projeto de Banco de Dados Ed. Sgra & Luzzatto
(a) Modelo ER é um modelo formal
(b) Poder de expressão limitado
• Esquema ER preciso, não ambíguo
• Diferentes leitores de um mesmo esquema ER
devem sempre entender exatamente o mesmo
• DER pode ser usado como entrada a uma
ferramenta CASE
• Fundamental: todos os envolvidos devem estar
treinados na sua perfeita compreensão
• Risco: sub-utilização
• Modelo ER apresenta apenas algumas propriedades
de um banco de dados
© Carlos A. Heuser
Projeto de Banco de Dados Ed. Sgra & Luzzatto
• Foi concebido para o projeto da estrutura de um BD
relacional
• Pouco poderoso para expressar restrições de
integridade (regras de negócio)
© Carlos A. Heuser
Projeto de Banco de Dados Ed. Sgra & Luzzatto
Poder de expressão: exemplo
© Carlos A. Heuser
Projeto de Banco de Dados Ed. Sgra & Luzzatto
Poder de expressão
© Carlos A. Heuser
Projeto de Banco de Dados Ed. Sgra & Luzzatto
(c) Equivalência entre esquemas
Poder de expressão: exemplo
© Carlos A. Heuser
Projeto de Banco de Dados Ed. Sgra & Luzzatto
Poder de expressão
© Carlos A. Heuser
Projeto de Banco de Dados Ed. Sgra & Luzzatto
Equivalência entre esquemas: exemplo
• Dois esquemas ER podem ser equivalentes
• Esquemas equivalentes
• Expressam o mesmo
• Modelam a mesma realidade
• Para fins de projeto de BD, dois esquemas ER são
equivalentes
• Geram o mesmo esquema de BD
• Considerar um conjunto de regras de tradução de
esquemas ER para esquemas lógicos de BD
© Carlos A. Heuser
Projeto de Banco de Dados Ed. Sgra & Luzzatto
© Carlos A. Heuser
Projeto de Banco de Dados Ed. Sgra & Luzzatto
Equivalência entre esquemas: exemplo
© Carlos A. Heuser
Projeto de Banco de Dados Ed. Sgra & Luzzatto
Equivalência entre esquemas: exemplo
© Carlos A. Heuser
Projeto de Banco de Dados Ed. Sgra & Luzzatto
2. Processo de Construção
A. Identificando construções
A. Identificando construções
B. Verificação do esquema
C. Esquema deve refletir o aspecto temporal
Determinação da construção da abordagem ER
(entidade, relacionamento, ...) que será usada para
modelar um objeto de uma realidade
• Não pode ser feita através da observação do objeto
isoladamente
• É necessário conhecer o contexto (esquema dentro do
qual o objeto aparece)
© Carlos A. Heuser
Projeto de Banco de Dados Ed. Sgra & Luzzatto
Identificando construções
Identificando construções
Recomendação geral
Dúvidas mais comuns
• Decisão por uma construção para a modelagem de
um objeto está sujeita à alteração durante a
modelagem
• Não despender um tempo excessivo em longas
discussões sobre como modelar um objeto
• Desenvolvimento do esquema e o aprendizado
sobre a realidade irão refinar e aperfeiçoar o
esquema
• Atributo versus entidade relacionada
• Atributo versus especialização/generalização
• Atributo opcional
• Atributo multivalorado
© Carlos A. Heuser
Projeto de Banco de Dados Ed. Sgra & Luzzatto
Atributo versus entidade relacionada
Atributo versus entidade relacionada
• Objeto está vinculado a outros objetos
• Deve ser modelado como entidade
• Caso contrário
• Pode ser modelado como atributo
• Conjunto de valores de um determinado objeto é fixo
(domínio fixo)
• Pode ser modelado como atributo
• Existem transações no sistema que alteram o conjunto de
valores do objeto (domínio variável)
• Não deve ser modelado como atributo
© Carlos A. Heuser
Projeto de Banco de Dados Ed. Sgra & Luzzatto
© Carlos A. Heuser
Projeto de Banco de Dados Ed. Sgra & Luzzatto
Atributo versus generalização/especialização
Atributo versus generalização/especialização
• Questão
• Modelar um determinado objeto (por exemplo, a
categoria funcional de cada empregado de uma
empresa)
Especialização deve ser usada quando
• As classes especializadas de entidades possuem
propriedades particulares
• Como atributo?
• Categoria funcional como atributo da entidade EMPREGADO
• Como especialização?
• Atributos
• Relacionamentos
• Generalizações/especializações
• Cada categoria funcional corresponde a uma especialização da
entidade EMPREGADO
© Carlos A. Heuser
Projeto de Banco de Dados Ed. Sgra & Luzzatto
Atributo versus generalização/especialização
© Carlos A. Heuser
Projeto de Banco de Dados Ed. Sgra & Luzzatto
Atributo opcional
• Atributo opcional
• Podem indicar subconjuntos de entidades que são
modelados mais corretamente através de especializações
• Exemplo
© Carlos A. Heuser
Projeto de Banco de Dados Ed. Sgra & Luzzatto
© Carlos A. Heuser
Projeto de Banco de Dados Ed. Sgra & Luzzatto
Atributo multivalorado
• Atributo multivalorado é indesejável
• SGBD relacional que segue o padrão SQL/2
• Atributo multivalorado não possui implementação direta
• SGBD OO ou objeto/relacional
• Atributo multi-valorado normalmente é modelado como classe
separada
• Atributos multivalorados podem induzir a um erro de
modelagem
• Ocultar entidades e relacionamentos em atributos multivalorados
© Carlos A. Heuser
Projeto de Banco de Dados Ed. Sgra & DCC011
Luzzatto
- profa Mirella M. Moro
25
© Carlos A. Heuser
Projeto de Banco de Dados Ed. Sgra & Luzzatto
B. Verificação do Esquema
b.1. Esquema deve ser correto
b.2. Esquema deve ser completo
b.3. Esquema deve ser livre de redundâncias
© Carlos A. Heuser
Projeto de Banco de Dados Ed. Sgra & Luzzatto
b.1. Esquema deve ser correto
Erros
•
•
•
•
Erros semânticos: exemplos
A partir da próxima aula
Estabelecer associações incorretas
•
Sintáticos
Semânticos
Erros semânticos mais difíceis de verificar
Regras de normalização auxiliam na validação
•
•
© Carlos A. Heuser
Projeto de Banco de Dados Ed. Sgra & Luzzatto
•
Usar uma entidade como atributo de outra
entidade
Usar o número incorreto de entidades em um
relacionamento
•
•
•
© Carlos A. Heuser
Projeto de Banco de Dados Ed. Sgra & Luzzatto
Associar a uma entidade um atributo que na realidade
pertence a outra entidade
Fundir em um único relacionamento ternário dois
relacionamentos binários independentes
© Carlos A. Heuser
Projeto de Banco de Dados Ed. Sgra & Luzzatto
b.2. Esquema deve ser completo
Deve fixar todas propriedades desejáveis do
banco de dados
Somente pode ser verificado por alguém que
conhece profundamente o sistema a ser
implementado
•
•
•
Envolver o usuário
© Carlos A. Heuser
Projeto de Banco de Dados Ed. Sgra & Luzzatto
b.3. Esquema deve ser livre de redundâncias
•
•
•
•
Verificar completude
• Forma de verificar
• Dados que devem ser obtidos do banco de dados estão
presentes?
• Todas as transações de modificação do banco de dados
podem ser executadas sobre o esquema?
• Requisito é aparentemente conflitante com a falta
de poder de expressão de modelos ER
© Carlos A. Heuser
Projeto de Banco de Dados Ed. Sgra & Luzzatto
O que fazer com construções redundantes?
Esquema deve ser mínimo, isto é, não deve
conter conceitos redundantes
• Alternativas
Tipos de redundância
• Implementação pode conter redundância
controlada de dados (desempenho)
Relacionamentos redundantes
Atributos redundantes
© Carlos A. Heuser
Projeto de Banco de Dados Ed. Sgra & Luzzatto
• Não devem aparecer no esquema ou
• Devem aparecer indicadas como dedundantes
© Carlos A. Heuser
Projeto de Banco de Dados Ed. Sgra & Luzzatto
Atributos redundantes ou deriáveis
© Carlos A. Heuser
Projeto de Banco de Dados Ed. Sgra & Luzzatto
© Carlos A. Heuser
Projeto de Banco de Dados Ed. Sgra & Luzzatto
C. Esquema e Aspecto Temporal
Atributos temporais
• O esquema deve refletir o aspecto temporal
• Dados temporais
• Dados que mudam ao longo do tempo e
• Para os quais BD mantém histórico
• Tipos de dados temporais
• Atributos cujos valores modificam ao longo do tempo
• Relacionamentos que modificam ao longo do tempo
© Carlos A. Heuser
Projeto de Banco de Dados Ed. Sgra & Luzzatto
Relacionamento 1:1 temporal
© Carlos A. Heuser
Projeto de Banco de Dados Ed. Sgra & Luzzatto
Relacionamento N:N temporal
© Carlos A. Heuser
Projeto de Banco de Dados Ed. Sgra & Luzzatto
© Carlos A. Heuser
Projeto de Banco de Dados Ed. Sgra & Luzzatto
Relacionamento 1:N temporal
© Carlos A. Heuser
Projeto de Banco de Dados Ed. Sgra & Luzzatto