“O Objetivo básico do projeto de banco de dados é possibilitar ao usuário obter a informação exata em um limite aceitável de tempo, de maneira a executar sua tarefa dentro da organização” (Teorey e Fry)
“O Objetivo do projeto de um banco de dados relacional é gerar um conjunto de esquemas relacionais que nos permita armazenar informações sem redundância desnecessária, apesar de nos permitir recuperar a informação facilmente” (Korth e Silberschatz)
- Ciclo de vida para o Desenvolvimento de Sistemas de Bancos de Dados
- Análise das Necessidades
- Projeto Conceitual (DER)
- Projeto Físico
- Implementação
- Monitoração
- Sintonização
- (Manutenção -> retorna ao 1)
Sistemas de Gerenciamento de Base de Dados (SGBD) encapsulam do 3 ao 5 em um único processo, necessitando apenas ser Sintonizado (ou configurado)
- Perigos potenciais no projeto de Banco de Dados Relacionais
- Repetição da informação
- Informações repetidas consomem espaço de armazenamento e dificultam a atualização
- Incapacidade de representar parte da informação
- Por vezes há a necessidade de se incluir valores nulos
- Perda de Informação
- Projetos mal elaborados sugerem a decomposição de esquemas relacionais com muitos atributos
- Repetição da informação
- Dependências Funcionais
- Dada uma relação R, o atributo Y de R é funcionalmente dependente do atributo X de R, ou:
- R.X -> R.Y
- Se e somente se cada valor X em R for associado precisamente a um mesmo valor Y em R, a qualquer momento
- (Y e X podem ser compostos)
- Dada uma relação R, o atributo Y de R é funcionalmente dependente do atributo X de R, ou:
Regras para encontrar Dependências Funcionais
Separação
A -> BC então A -> B e A -> C Exemplo:
CPF -> nome, endereço então CPF -> nome e CPF -> endereço
Leia o exemplo acima da seguinte maneira:
Se com um número de CPF eu encontro o nome e o endereço de uma pessoa, então com este mesmo número eu posso encontrar apenas o nome e com este mesmo número eu posso encontrar apenas o endereço.
Acumulação
A -> B então AC -> B
Exemplo:
CPF -> endereço então CPF, idade -> endereço
Leia o exemplo acima da seguinte maneira:
Se com um número de CPF eu encontro o endereço de uma pessoa, então com este mesmo número mais a idade da pessoa eu posso encontrar o endereço também.
Transitividade
A -> B e B -> C então A -> C
Exemplo:
CPF -> código-cidade e código-cidade -> nome-cidade então CPF -> nome-cidade
Leia o exemplo acima da seguinte maneira:
Se com um número de CPF eu encontro o código da cidade de uma pessoa, e com o código da cidade eu encontro o nome da cidade, então com o número do CPF eu posso encontrar o nome da cidade.
Pseudo-Transitividade
A -> B e BC -> D então AC -> D
Exemplo:
CPF -> código-funcionário e código-funcionário, mês -> salário-funcionário então CPF, mês -> salário-funcionário
Leia o exemplo acima da seguinte maneira:
Se com um número de CPF eu encontro o código do funcionário, e com o código do funcionário mais um certo mês eu encontro o salário que ele recebeu naquele mês, então com o número do CPF mais um certo mês eu posso encontrar o salário que ele recebeu naquele mês.
- Normalização
- Processo de transformações das relações (tabelas representando entidades e relacionamentos) em novas relações pela aplicação de projeções (quebra e granularização das tabelas)
- Consequências:
- Diminuem problemas de anomalias e inconsistências
- Relações simplificadas e estrutura regular
- Aumento da integridade dos dados
- Necessidade de realização de agregamentos
- Eventual queda na performance
- 5 Formas normais
- 1a. Forma Normal:
- Todos os atributos admitem apenas valores atômicos
- Todos os atributos admitem apenas valores atômicos
- 2a. Forma Normal
- Cada atributo não chave é dependente de toda a chave primária
- Problemas Solucionados
- Inserção
- Fornecedor somente poderá ser cadastrado quando fornecer pelo menos 1 peça
- Remoção:
- Ao se remover algum pedido remove-se também a informação de localidadeassociadaao fornecedor a que se refere o pedido
- Atualização
- Redundância de informações em diversas tuplas. Ex: Mudança do endereço de um fornecedor
- Inserção
- Cada atributo não chave é dependente de toda a chave primária
- 3a. Forma Normal
- Cada atributo chave é dependente não transitivo da chave primária
- Problemas Solucionados 3a. FN
- Inserção:
- Não se pode registrar o fato de uma cidade ter um determinado porte até que haja um fornecedor daquela cidade
- Remoção:
- Removendo-se o último fornecedor de uma cidade perde-se a informação porte
- Atualização:
- Quando uma cidade muda de porte pode ser necessário atualizar diversas tuplas de fornecedor
- Inserção:
- Cada atributo chave é dependente não transitivo da chave primária
-
- Restrições de Integridade
- Integridade de Chave
- Integridade de Entidade
- Integridade Referencial
- Tipos:
- Restrições implícitas
- Restrições Explícitas
- Especificação procedimental
- Especificação declarativa
- Especificação de Triggers
- Restrições de Integridade
- Forma normal de Boyce-Codd – FNBC
Uma relação R está na forma normal de Boyce-Codd
se para toda dependência funcional X → Y associada
com R uma das seguintes afirmações é verdadeira:- Y ⊆ X (i.e, X → Y é DF trivial);ou
- X é superchave de R;
Exemplo:
Está na FNBC: emp(ecod, ename, title), pay(title, sal),
É raro uma relação estar na 3FN e não estar na
FNBC, mas vejamos dois exemplos.
Exemplo de normalização até a FNBC
Seja o esquema de lotes a venda em um Estado:
lotes(propriedadeNum, cidade, loteNum, area, preco, imposto)
chaves primária: propriedadeNum;
DF1: propriedadeNum é chave primária
DF2: (cidade, loteNum) é chave candidata
DF3: cidade → imposto; % imposto fixo por cidade
DF4: area → preco; % preço por área independente
. % dos demais atributos
DF5: area → cidade; % domínio de tamanhos
. % disjuntos por cidade
Está na 1FN? E na 2FN? E na 3FN? E na FNBC?
Exemplo lotes: 1FN
lotes(propriedadeNum, cidade, loteNum, area, preco, imposto)
Está na 1FN, mas não na 2FN, pois:
DF2: (cidade, loteNum) → propriedadeNum, area, preco, imposto
DF3: cidade → imposto
Imposto é parcialmente dependente da chave
(cidade, loteNum)
Exemplo lotes1 e lotes2: 2FN
lotes1(propriedadeNum, cidade, loteNum, area, preco)
lotes2(cidade, imposto)
lotes2 está na 3FN;
lotes1 está na 2FN, mas não na 3FN, pois:
DF4: area → preco;
– area não é superchave e preço não é atributo principal
Exemplo lotes1 e lotes2: 3FN
lotes1a(propriedadeNum, cidade, loteNum, area)
lotes1b(area, preco)
lotes2(cidade, imposto)
Lotes1a, lotes1b e lotes2 estão na 3FN, mas
lotes1a não está na FNBC, pois:
DF5: area → cidade;
Observe que lotes1a está na 3FN porque, embora area
não seja superchave, cidade é atributo principal.
Entretanto isso não é relevante para a FNBC
Exemplo lotes na FNBC
lotes1ax(propriedadeNum, loteNum, area)
lotes1ay(area, cidade)
lotes1b(area, preco)
lotes2(cidade, imposto)
Observe que a DF2 foi perdida nesta decomposição
Outro Exemplo de 3FN x FNBC
ensina(aluno, disciplina, professor)
DF1: {aluno, disciplina} → professor;
DF2: professor → disciplina; % cada professor
% leciona uma disciplina
1FN: atributos são atômicos? Sim
2FN: há dependência parcial? Não, logo está na 2FN
3FN: dependências de superchaves ou apontando para
atributos principais? sim, logo está na 3FN
FNBC: dependências de superchaves? Não, veja DF2
Como decompor ensina?
Alternativas de decomposição na FNBC
1. (aluno, professor), (aluno, disciplina)
2. (disciplina, professor), (aluno, disciplina)
3. (disciplina, professor), (aluno, professor)
Todas perdem DF1, mas em 3. evitamos tuplas falsas após
uma junção. Ex. de instância:
Estudo para a Prova:
Construa um Diagrama Modelo Entidade Relacionamento tabular (Relacional) agrupando os atributos nas tabelas que vão representar as entidades e os relacionamentos do seu banco de dados
Construa os diagramas de dependências funcionais para as tabelas propostas (Diagrama relacional)
Garanta que cada atributo será atômico (isto, é, não pode ser dividido) para se obter um modelo na 1a. FN
Elimine as dependências parciais da chave primária em suas tabelas para obter um projeto na 2a. FN
Elimine as dependências transitivas nas tabelas (se houver), obtendo um esquena na 3a. FN