BANCO DE DADOS Universidade do Estado de Santa Catarina Centro de Ciências Tecnológicas Departamento de Ciência da Computação Prof. Alexandre Veloso de Matos alexandre.matos@udesc.br
OBJETIVOS Orientações para Projetos de BD; Dependências Funcionais (DFs): Definição de DF; Regras de inferência para DFs. Formas Normais: Primeira Forma Normal; Segunda Forma Normal; Terceira Forma Normal. Outras Formas Normais.
ORIENTAÇÕES PARA PROJETOS DE BD Estratégia imediata para construção de um modelo relacional => o bom senso de um projetista desde o projeto conceitual Mas, seria suficiente? É necessário um modo formal de análise que permita distinguir que agrupamento é mais adequado que outro!
ORIENTAÇÕES PARA PROJETOS DE BD Principais Problemas Ainda não foi prevista nenhuma medida de adequação ou uma apresentação de boas práticas que ajudem a medir a qualidade de um projeto de BD. Projetos de BD são, em geral, guiados pela intuição do projetista! Que abordagem, então, utilizar para que se possa identificar: Medidas de adequação Boas práticas
ORIENTAÇÕES PARA PROJETOS DE BD Há 2 níveis em que se pode discutir boas práticas/medidas de adequação: Nível lógico (ou conceitual) Como os usuários interpretam os esquemas e o significado de seus atributos? Nível de implementação (ou físico) Como as tuplas são armazenadas e atualizadas?
ORIENTAÇÕES PARA PROJETOS DE BD Em ambos níveis é importante que se identifique qual a abordagem para o projeto do BD: Projeto Bottom-Up Ponto de partida como atributos se relacionam? Permite a derivação de entidades/relacionamentos e consequentemente tabelas Projeto Top-Down Inicia com agrupamentos aleatórios de atributos em relações que existem semanticamente (faturas, formulários, relatórios,...) As relações passam a ser analisadas individualmente levando à decomposição
PROJETO BOTTOM-UP Ênfase nas descrições de dados já existentes na organização: arquivos eletrônicos, fichários, documentos bem formatados (pedidos, NFs), relatórios,... Geralmente aplicado em casos onde existem fontes de dados ou sistemas informatizados (legados) sem BD Cinco etapas: a) coleta de fontes de dados b) representação em uma tabela não-normalizada c) normalização d) integração de esquemas relacionais das fontes e) engenharia reversa (para o modelo conceitual)
PROJETO TOP-DOWN Ênfase nos requisitos da aplicação obtidos com os usuários Compreensão dos dados operacionais relevantes para a aplicação Processo mais usual de projeto aplicado geralmente em casos onde não existe sistema informatizado ou BD anterior Quatro etapas a) levantamento de requisitos b) projeto conceitual c) projeto lógico d) normalização e) projeto físico ou implementação
PROJETO BOTTOM-UP X TOP-DOWN Projeto Top-Down Gera esquemas de BD baseados nos requisitos da organização obtidos através de contatos com os usuários Projeto Bottom-Up Gera esquemas de BD baseados nas fontes de dados da organização Um pode complementar o outro!
ORIENTAÇÕES PARA PROJETOS DE BD Independente da abordagem adotada, quatro medidas informais podem ser usadas para estimular um projeto com menos falhas: Observar a semântica dos atributos; Redução de valores redundantes nas tuplas; Redução de valores null nas tuplas; Impedimento da geração de valores ilegítimos nas tuplas.
SEMÂNTICA DOS ATRIBUTOS Cada tupla de uma relação deve representar uma entidade ou instância de relacionamento; Atributos de entidades distintas não devem estar na mesma relação; Apenas chaves-estrangeiras devem ser usadas para referenciar outras entidades! Atributos de entidades e relacionamentos devem ser mantidos separadamente tanto quanto possível.
SEMÂNTICA DOS ATRIBUTOS Exemplo: Correto: Empregado(#matricula, nome, datanasc, endereco, &depto) Incorreto: Empregado(#matricula, nome, datanasc, endereco, &depto, nomedepto)
REDUÇÃO DE VALORES REDUNDANTES Informações redundantes desperdiçam espaço de armazenamento; A mistura de atributos de várias entidades pode gerar problemas conhecidos como: Anomalias de inserção; Anomalias de remoção; Anomalias de atualização.
ANOMALIAS Empregado #Matrícula Nome &Depto nomedepto 0000001 José 101 Recursos Humanos 0000002 João 102 Tecnologia da Informação 0000003 Maria 102 Tecnologia da Informação E se o funcionário José fosse excluído dessa tabela?
REDUÇÃO DE VALORES NULL Pode causar desperdício de espaço no armazenamento; Pode gerar problemas de entendimento do significado dos atributos; Podem induzir a interpretações distintas: Ex: Grau de escolaridade É um valor não aplicável ou inválido? Ex: Data nascimento É um valor desconhecido? Ex: Telefone É um valor indisponível?
IMPEDIMENTO DA GERAÇÃO DE TUPLAS ILEGÍTIMAS As tabelas devem ser projetadas para satisfazer a condição de junção sem perdas; Nenhuma tupla ilegítima deve ser gerada ao se efetuar uma junção natural de quaisquer relações.
Empregado #Matrícula Nome 0000001 José 0000002 João 0000003 Maria E_Localização Nome Localização José Joinville José Curitiba Maria Curitiba E_Projeto #&Matrícula #&Projeto Horas Localização 0000001 1 32 Joinville 0000001 2 7 Curitiba 0000003 2 30 Curitiba E_Projeto JOIN E_Localização ON E_Projeto.Localização = E_Localização.Localização #&Matrícula #&Projeto Horas Localização Nome 0000001 1 32 Joinville José 0000001 2 7 Curitiba José 0000001 2 7 Curitiba Maria 0000003 2 30 Curitiba José 0000003 2 30 Curitiba Maria
Empregado #Matrícula Nome 0000001 José 0000002 João 0000003 Maria E_Localização Nome Localização José Joinville José Curitiba Maria Curitiba E_Projeto #&Matrícula #&Projeto Horas Localização 0000001 1 32 Joinville 0000001 2 7 Curitiba 0000003 2 30 Curitiba E_Projeto JOIN E_Localização ON E_Projeto.Localização = E_Localização.Localização #&Matrícula #&Projeto Horas Localização Nome 0000001 1 32 Joinville José 0000001 2 7 Curitiba José 0000001 2 7 Curitiba Maria 0000003 2 30 Curitiba José 0000003 2 30 Curitiba Maria
DEPENDÊNCIAS FUNCIONAIS
DEPENDÊNCIA FUNCIONAL (DF) Uma DF é uma restrição entre dois atributos ou dois conjuntos de atributos; É uma propriedade da semântica dos atributos; Para qualquer relação R, um atributo B é funcionalmente dependente de um atributo A se, para toda instância de R, um valor de A determina univocamente o valor de B; AB Determinante Funcionalmente Dependente
EXEMPLO - DF Vendedor (1,N) Fornece (0,N) Material Vendedor_Id Endereço Material_Id UM Nome Custo Preço Vendedor_Id {Nome, Endereço} {Vendedor_Id, Nome} Endereço Material_Id {Custo, UM} {Vendedor_Id, Material_Id} Preço
REGRAS DE INFERÊNCIA PARA DFS RI1 (Reflexiva): Se Y é um subconjunto de X, então X Y (também válido quando X=Y); RI2 (Aumentativa): Se X Y, então XZ YZ; RI3 (Transitiva): Se X Y e Y Z, então X Z;
REGRAS DE INFERÊNCIA PARA DFS RI4 (Decomposição): Se X YZ, então X Y e X Z; RI5 (Aditiva): Se X Y e X Z, então X YZ; RI6 (Pseudotransitiva): Se X Y e WY Z, então WX Z
NORMALIZAÇÃO
FORMAS NORMAIS Normalização: Processo de decompor relações ruins dividindo seus atributos em relações menores. Forma normal: Indica o nível de qualidade de uma relação.
NORMALIZAÇÃO Pode ser vista como a análise das DFs de um esquema de relação e chaves primárias para alcançar: Minimização de redundância e; Minimização de anomalias de inserção, exclusão e atualização.
NORMALIZAÇÃO Deve confirmar a existência de duas propriedades: Propriedade da junção sem perda ou junção não aditiva; Propriedade da preservação da dependência.
PRIMEIRA FORMA NORMAL (1FN) Uma relação não pode conter atributo multivalorado nem composto: O domínio dos atributos deve incluir valores atômicos; O valor de qualquer atributo deve ser um único valor do domínio daquele atributo.
PRIMEIRA FORMA NORMAL (1FN) Aluno Idiomas Matrícula Curso Nome #Matrícula Nome Curso Idiomas 0000001 João Letras {Alemão} 0000002 Pedro Matemática {Inglês, Espanhol} 0000003 Maria Computação {Inglês,Francês}
PRIMEIRA FORMA NORMAL (1FN) Uma solução, embora com redundância: #Matrícula Nome Curso Idiomas 0000001 João Letras Alemão 0000002 Pedro Matemática Inglês 0000002 Pedro Matemática Espanhol 0000003 Maria Computação Inglês 0000003 Maria Computação Francês
PRIMEIRA FORMA NORMAL (1FN) Aluno: #Matrícula Nome Curso 0000001 João Letras 0000002 Pedro Matemática 0000003 Maria Computação Idiomas_Aluno: #&Matrícula #Idioma 0000001 Alemão 0000002 Inglês 0000002 Espanhol 0000003 Inglês 0000003 Francês
SEGUNDA FORMA NORMAL (2FN) Um esquema de relação R está na 2FN se: Está na 1FN; Todo atributo não participante da chave primária, depende de forma completa da mesma (dependência total).
SEGUNDA FORMA NORMAL (2FN) Dependência Parcial: #Matr #Curso Nome Depto Salário Data_término Solução: decompor em duas relações Empregado(#Matr,Nome,Depto,Salário) EmpCurso(#&Matr,#Curso,Data_término)
TERCEIRA FORMA NORMAL (3FN) Um esquema de relação R está na 3FN se: Está na 2FN; Todos os seus atributos, não participantes da chave primária, não dependem transitivamente da mesma; Lembrando que: Se X Y e Y Z, então X Z
TERCEIRA FORMA NORMAL (3FN) Canal_Vendas #Cod_cliente Nome_cliente &Vendedor Região Cod_cliente Nome_cliente Vendedor Região 8023 Anderson Paulo Sul 9167 Bruno Geraldo Oeste 7929 Carlos Paulo Sul 6837 Marcos João Leste 8596 Samuel Geraldo Oeste 7018 Felipe Pedro Norte
TERCEIRA FORMA NORMAL (3FN) Anomalias: Inserção: Um novo vendedor não pode ser inserido a menos que um cliente tenha sido alocado para um vendedor; Deleção: Quando um cliente é excluído da tabela (Ex. 6837), perde-se a informação de que João está alocado para a região Leste; Atualização: Se um vendedor muda a região, várias linhas deverão ser modificadas para refletir esse fato.
TERCEIRA FORMA NORMAL (3FN) Solução: decompor a relação em duas Canal_Vendas #Cod_cliente Nome_cliente &Vendedor Vendedor #Vendedor Região
ETAPAS DADOS NÃO NORMALIZADOS Grupos de repetição PRIMEIRA FORMA NORMAL Sem grupos de repetição SEGUNDA FORMA NORMAL Dependência Total TERCEIRA FORMA NORMAL Sem dependência transitiva
FORMAS NORMAIS Universo das Relações Relações na 1FN Relações na 2FN Relações na 3FN
BIBLIOGRAFIA ELMASRI, R. E.; NAVATHE S. Sistemas de Banco de Dados. 4ª Ed., São Paulo: Pearson Prentice Hall, 2005. Capítulo 10.