************************************* ********** BD2 - Resumo P1 ********** ************************************* Data : 23/09/2004 Versão : 04/07/2007 Professor: Marcelo Dias Autor : Leandro Salvador ( leandrosalvador.com.br ) * Definições - view - expressão de álgebra relacional renomeada - fornece segurança automática para dados ocultos - fornece atalhos ou capacidade de "macros" (simplificação) - permite que os mesmos dados sejam vistos por usuários diferentes de diferentes formas - podem fornecer independência lógica funcional - VAR VIEW - independência lógica funcional - imunidade de usuário e programas contra modificações na estrutura lógica do database - aspectos - crescimento - expansão de uma relvar existente para incluir novos atributos correspondentes à inclusão de nova informação a respeito de um tipo de objeto existente - ex: adição de um campo denominado DISCOUNT na tabela S - inclusão de uma nova base relvar correspondendo à adição de um novo tipo de objeto no database - ex: inclusão da tabela P (projects) no banco de dados SP - reestruturação - ocasionalmente pode ser necessário reestruturar o database de tal forma que toda a informação continue intacta - ex: dividir a base relvar S em duas --> a relvar original S corresponde a um JOIN entre as duas novas relvar SNC e ST, podendo criar uma view: VAR S VIEW SNC JOIN ST; - princípio da troca - não deve existir nenhuma distinção arbitrária e desnecessária entre base e derived relvars - este princípio implica na obrigatoriedade de autalização de views - princípio da relatividade do banco de dados - a diferença entre qual é real e qual é virtual entre base e derived relvars é arbitrário para o banco de dados - view updates - data uma particular atualização em uma view, quais atualizações precisam ser aplicadas à(s) correspondente(s) base relvar(s) para implementar a atualização da view original? - considerando - D --> database - V --> view em D - X --> definição em função de D V = X(D) --> view é definida em função de D U(V) = U(X(D)) --> operação de update em V U(X(D)) = X(U'(D)) --> identificar uma operação em U' em D - o que realmente existe e pode ser atualizado é o database D e não a view V diretamente (virtual) - ou seja: o usuário atualiza uma view = o SGBD define uma atualização no database, diferente da atualização feita pelo usuário - snapshots - são derived relvars reais, ao contrário das views que são virtuais - são representados por cópias reais, materializadas, dos dados, não apenas por suas definições em termos de base relvars - VAR P2SC SNAPSHOT ((S JOIN SP) WHERE P# = P2) {S#, CITY^} REFRESH EVERY DAY; - triggers (gatilhos) - é um comando que é executado automaticamente pelo sistema em conseqüência de uma modificação no database - gatilho acionado pela modificação dispara uma série de comandos - exigências - especificar as condições sob as quais o gatilho deve ser executado (on insert, on update, on delete) - especificar as ações (comandos) que serão tomadas quando um gatilho for disparado - dependência funcional - relacionamento "vários-para-um" de um conjunto de atributos para outro em uma determinada relvar - X -> Y significa "X determina funcionalmente Y" - X -> Y se e somente se cada valor de X na relação R estiver associado precisamente com um valor de Y - ou seja, só existe um valor de Y para um dado X - se X é uma candidate key da relvar R, então todos os atributos Y de R devem ser funcionalmente dependentes de X P# -> {P#, PNAME, COLOR, WEIGHT, CITY} * Clausura (Closure) de um Conjunto de Dependências Funcionais - propriedades - 1) Reflexividade --> se B é subconjunto de A então A -> B - 2) Incremento --> se A -> B então AC -> BC - 3) Transitividade --> se A -> B e B -> C então A -> C - 4) Auto-determinação --> A -> A - 5) Decomposição --> se A -> BC então A -> B e A -> C - 6) União --> se A -> B e A -> C então A -> BC - 7) Composição --> se A -> B e C -> D então AC -> BD - exercício 1) Reduzir o seguinte conjunto de Dependências Funcionais (DFs): > A -> B A -> B A -> B A -> B A -> BC < > A -> C < A -> C < > A -> C B -> C B -> C B -> C B -> C B -> C A -> B (1) A -> B (2) (3) (4) AB -> C AB -> C AB -> C < AC -> D AC -> D < > A -> D A -> D A -> D --irredutível-- - (1) reescrevendo deixando apenas singleton sets do lado direito - (2) temos A -> C como A -> AC (incremento) temos AC -> D então A -> D portanto AC -> D é redundante - (3) temos A -> C como AB -> BC (incremento) temos AB -> C (decomposição) portanto AB -> C é redundante - (4) temos A -> B temos B -> C como A -> C (transitividade) portanto A -> C é redundante * Normalização - reversibilidade significa que a relvar original é igual a um join de suas projeções - hierarquia [ 1NF [ 2NF [ 3NF [ BCNF [ 4NF [ 5NF ] ] ] ] ] ] - 1NF - toda tupla (linha) possui exatamente um valor para cada atributo (coluna) - 2NF - todo atributo não chave é irredutivelmente dependente da primary key - ou seja, todo atributo não chave depende da chave inteira - 3NF - todos atributos não chave são mutuamente independentes entre si - ou seja, os atributos não chave não dependem funcionalmente de nenhum outro atributo - BCNF - a relvar tem duas ou mais candidate keys - essas candidate keys são compostas - essas candidate keys compartilham pelo menos um atributo (overlap) - ou seja, se qualquer afirmativa acima for falsa, está na BCNF - 4NF - a relvar não tem dependência multivalorada - 5NF - cada dependência de junção não-trivial são implicadas pelas candidate keys - ou seja, a relvar não tem dependência de junção ----------//----------