Banco de Dados I Módulo II: Modelagem Entidade- Relacionamento versus Relacional. (Aula 4) Clodis Boscarioli

Transcrição

1 Banco de Dados I 2007 Módulo II: Modelagem Entidade- Relacionamento versus Relacional (Aula 4) Clodis Boscarioli

2 Agenda: Dependências Funcionais; Dependências Funcionais e Projeto de Banco de Dados Relacional; Decomposição de esquemas.

3 Dependências Funcionais e Projeto de Banco de Dados Relacional Clodis Boscarioli

4 Dependências Funcionais Dependências funcionais são restrições ao conjunto de relações válidas. Permitem expressar determinados fatos relativos ao domínio que está sendo modelado. Definição: Seja α R e β R. A dependência funcional: α β realiza-se em R se, em qualquer relação válida r(r), para todos os pares de tuplas t1 e t2 em r, tal que t1[α] = t2[α], t1[β] = t2[β] também será verdade.

5 Dependências Funcionais Usando a notação de dependência funcional, dizemos que K é uma super chave de R se K R. A dependência funcional nos permite expressar um tipo de restrição. Exemplo: Esquema_info_empréstimo = (nome_agência, número_empréstimo, nome_cliente, total) O conjunto de dependências funcionais que queremos garantir para este esquema é: número_empréstimo total número_empréstimo nome_agência E não esperamos que a seguinte dependência funcional se realize: número_empréstimo nome-cliente

6 Dependências Funcionais As dependências funcionais podem ser usadas de dois modos: Para o estabelecimento de restrições sobre um conjunto de relações válidas. Para verificar se uma relação é válida sob um conjunto de dependências funcionais. Considere a seguinte relação r, para verificar quais dependências funcionais são satisfeitas: A a1 a1 a2 a2 B b1 b2 b2 b3 C c1 c1 c2 c2 D d1 d2 d2 d3 Vale: A C AB D A A (trivial) a3 b3 c2 d4

7 Relação que satisfaz uma Dependência versus Dependência realizando-se em um esquema nome Jones Smith Hayes Curry Lindsay Turner Williams Adams Johnson rua Main North Main North Park Putnam Nassau Spring Alma cidade Harrison Rye Harrison Rye Pittsfield Stanford Princeton Pittsfield Palo Alto Nota-se que rua cidade é satisfeita. Entretanto, no mundo real, em algum momento, pode haver uma instância da relação cliente na qual esta dependência não seja satisfeita. Assim, não se deve incluir esta dependência funcional no conjunto das dependências que devem ser realizadas no Esquema_cliente. Glenn Sand Hill Woodside Brooks Senator Brooklyn Green Walnut Stanford

8 Relação que satisfaz uma Dependência versus Dependência realizando-se em um esquema empréstimo nome_ag Downtown Redwood Perryridge Downtown Mianus Round Hill número total A dependência funcional número total, nome_ag é satisfeita pela relação e deve fazer parte do conjunto de dependências que se realizam no Esquema_empréstimo. Pownal North Town Downtown Observe que número é chave para a relação. Perryridge Brighton

9 Regras de Inferência Em geral, o projetista do esquema de um banco de dados especifica as dependências funcionais que são semanticamente evidentes, porém, normalmente, diversas outras dependências funcionais existem em todas as instâncias válidas da relação que satisfazem as dependências. Essas outras dependências podem ser deduzidas ou inferidas do conjunto original de dependências funcionais. Definição: o conjunto de todas as dependências de F (conjunto original de dependências), bem como todas as dependências que podem ser inferidas para F, é chamado clausura de F e é denotado por F +. Regra Reflexiva: Se X Y, então X Y Regra Aumentativa: X Y então XZ YZ Regra Transitiva: X Y, Y Z então X Z Regras de Decomposição ou Projetiva: X YZ então X Y e X Z Regra de União ou Aditiva: X Y, X Z então X YZ Regra Pseudotransitiva: X Y, WY Z então WX Z

10 Cobertura Canônica/Mínima A cobertura mínima de um conjunto de dependências funcionais E é um conjunto de dependências funcionais F que satisfaça a propriedade que diz que: toda dependência em E pertence à clausura F + de F. Essa propriedade será perdida se qualquer dependência do conjunto F for removida. F não deve ter nenhuma redundância; F deve então ser um conjunto mínimo e, F será mínimo se: Toda dependência F tem um único atributo em seu lado direito. Não podemos substituir nenhuma dependência X A por uma dependência Y A, em que Y é um subconjunto de X, e ainda ter um conjunto de dependências que seja equivalente a F. Não podemos remover nenhuma dependência de F e ainda ter um conjunto de dependências que seja equivalente a F. Dois conjuntos de dependências funcionais E e F são equivalentes se E + = F +.

11 Qualidade Existem dois níveis em que podemos discutir a excelência dos esquemas de relação. Nível lógico: ter bons esquemas de relação nesse nível possibilita que os usuários entendam claramente o significados dos dados nas relações e, assim, possam formular corretamente a manipulação de dados. Nível de implementação: diz respeito a como as tuplas de uma relação básica são armazenadas e atualizadas e como se proporciona a manipulação eficiente dos dados.

12 Qualidade Metodologias de desenvolvimento de projeto de banco de dados: Bottom up ou por síntese: considera os relacionamentos básicos entre os atributos individuais como ponto de partida, e os utiliza para construir os esquemas de relações. Top down ou por análise: começa com um número de agrupamentos de atributos em relações. Essas são então analisadas individual e coletivamente, indicando as decomposições futuras até que todas as propriedades sejam alcançadas.

13 Projetos Informais Medidas informais para mensurar a qualidade de um projeto de esquema de relação: Semântica dos atributos; Redução de valores redundantes nas tuplas; Redução de valores null nas tuplas; Impedimento para a geração de valores ilegítimos nas tuplas;

14 Semântica dos Atributos Quando se agrupa atributos em uma relação espera-se que haja um significado no mundo real e que haja uma interpretação própria associada a eles. Esse significado, ou semântica, especifica como interpretar os valores dos atributos armazenados em uma tupla da relação. Em geral, quanto mais fácil for explicar a semântica da relação, melhor será o modelo de esquema da relação. O atributo DNumero em empregado é uma chave estrangeira que representa uma relação implícita entre empregado e departamento.

15 Diretriz 1: Modelar um esquema de relação de modo que seja fácil explicar seu significado. Se uma relação corresponde a uma mistura de entidades e relacionamentos, resultarão em ambigüidades semânticas e a relação não poderá se explicada facilmente. Esquemas pobres porque violam a Diretriz 1: Emp_dept: enome, ssn, datanasc, endereco, dnumero, dnome, dgerssn. Emp_proj: ssn, pnumero, horas, enome, pnome, plocalização.

16 Redução de Valores Redundantes nas Tuplas Deve-se minimizar o espaço de armazenamento utilizado pelas relações básicas: Agrupe atributos em esquemas de relações; Deve-se evitar situações que caiam em problemas de Anomalias na Atualização.

17 Diretriz 2: Modelar esquemas de relações básicas de forma que nenhuma anomalia de atualização possa ocorrer nas relações. Se houver a possibilidade de ocorrer alguma anomalia, registre-a claramente e tenha certeza de que os programas que atualizam o banco de dados operarão corretamente. Pode-se violar uma diretriz em prol do desempenho de uma consulta, entretanto, as medidas cabíveis devem ser tomadas para que os dados estejam sempre consistentes e íntegros.

18 Redução de Valores null nas Tuplas A existência de muitas possibilidades de uso do valor null causa desperdício de espaço no armazenamento e gera problema de entendimento do significado do atributos e da especificações de joins, e funções agregadas. Motivos para uso do null: O atributo não se aplica à tupla; O valor do atributo para a tupla é desconhecido; O valor do atributo para a tupla é conhecido, mas ausente, ou seja, ainda não foi registrado.

19 Diretriz 3: Até onde for possível, evite colocar os atributos em uma relação básica cujos valores freqüentemente possam ser nulos. Se os nulls forem inevitáveis, tenha certeza de que eles se aplicam somente em casos excepcionais e não na maioria das tuplas da relação. Ex: se só 10% dos empregados tiverem escritórios particulares, há pouca justificativa para incluir um atributo ESCRITORIO-NRO na relação EMPREGADO; pode ser criada uma relação EMP_ESCRITÖRIOS (ESSN, ESCRITORIO_NRO) que contenha apenas as tuplas dos empregados que possuírem escritórios particulares.

20 Impedimento para a Geração de Valores Ilegítimos nas Tuplas Considere os esquemas: Esquema 1: Emp_locs (enome, plocalização) Emp_proj1 (ssn, pnumero, horas, pnome, plocalização) Esquema 2: Emp_proj: (ssn, pnumero, horas, enome, pnome, plocalização) A partir do esquema 1 é possível conseguir as mesmas informações que temos no esquema 2? Não, usando um JOIN conseguiremos tuplas ilegítimas.

21 Diretriz 4: Projete os esquemas de relações de forma que possam ser unidos (join) com igualdade de condições sobre os atributos que sejam chaves primárias ou chaves estrangeiras, de modo a garantir que nenhuma tupla ilegítima seja gerada.

22 Qualidade Propriedades indesejáveis: Informações repetidas Inabilidade para representação de certas informações. Considere o seguinte esquema: Esquema_linha_de_crédito = (nome_agência, cidade_agência, fundos, nome_cliente, número_empréstimo, total) linha_de_crédito(esquema_linha_de_crédito)

23 Instância Brooks Brooklyn Brighton Glenn Horseneck Perryridge Johnson Brooklyn Downtown Hayes Rye North Town Williams Bennington Pownal Turner Horseneck Round Hill Jones Horseneck Mianus Jackson Brooklyn Downtown Hayes Horseneck Perryridge Smith Palo Alto Redwood Jones Brooklyn Downtown total número_ empréstimo nome_cliente fundos cidade_agência nome_agência

24 Problema Para acrescentar um novo empréstimo, com número 31, para o cliente Adams, com valor de 1500, na agência Perryridge. Será necessário repetir os dados sobre fundos e cidade referentes à agência Perryridge. Dados sobre fundos e localização da agência deverão aparecer toda vez que um empréstimo foi criado naquela agência. Repetição de informação: Desperdício de espaço; Dificuldade (custo) para atualizar o banco de dados. Suponha uma mudança de localização de uma agência. Num bom projeto, apenas uma tupla deveria ser mudada. Aqui, várias tuplas serão alteradas.

25 Problema Neste esquema não se pode representar diretamente a informação relativa a uma agência (nome_agência, cidade_agência, fundos), salvo se houver ao menos um empréstimo concedido pela agência. O problema é que as tuplas da relação linha_de_crédito exigem valores para (número_empréstimo, nome_cliente, total). Uma solução (que queremos sempre evitar) é introduzir valores nulos. É o problema de inabilidade para representar certas informações.

26 Estudando as Dependências Funcionais Sabe-se que uma agência bancária está localizada em apenas uma cidade. A dependência funcional nome_agência cidade_agência, fundos realiza-se no Esquema_linha_de_crédito. Sabe-se que uma agência bancária pode conceder vários empréstimos. A dependência funcional nome_agência número_empréstimo não se realiza no Esquema_linha_de_crédito.

27 Estudando as Dependências Funcionais O fato da agência estar localizada em uma cidade e o fato da agência conceder empréstimos são independentes, e serão melhor representados em relações diferentes. Note que as dependências funcionais podem ser usadas para indicar um caminho para obtenção de bons projetos de banco de dados. As dependências funcionais podem ser usadas para especificação formal de quando o projeto de banco de dados é bom.

28 Decomposição Para resolver os problemas levantados, é interessante que façamos a decomposição do esquema em vários outros com um número menor de atributos. Entretanto, decomposições mal feitas podem gerar outro tipo de projeto de má qualidade. Exemplo: Esquema_agência_cliente = (nome_agência, cidade_agência, fundos, nome_cliente). Esquema_cliente_empréstimo = (nome_cliente, número_empréstimo, total)

29 Instâncias nome_agência cidade_agência fundos nome_cliente nome_cliente número_empréstimo total Downtown Brooklyn Jones Jones Redwood Palo Alto Smith Smith Perryridge Horseneck Hayes Hayes Downtown Brooklyn Jackson Jackson Mianus Horseneck Jones Jones Round Hill Horseneck Turner Turner Pownal Bennington Williams Williams North Town Rye Hayes Hayes Downtown Brooklyn Johnson Johnson Perryridge Horseneck Glenn Glenn Brighton Brooklyn Brooks Brooks Encontre todas as agências que tenham empréstimos cujos totais sejam inferiores a 1000 reais.

30 Resolvendo a consulta... Nenhuma relação neste projeto alternativo contém esses dados. Será necessário reconstruir a relação linha_de_crédito. Para isso será necessário fazer a junção natural das duas relações: agência_cliente X cliente_empréstimo Quando compararmos o resultado desta junção com a relação linha_de_crédito encontraremos algumas tuplas a mais no resultado da junção. Estas tuplas indicam informações que, na realidade, não existem. (Downtown, Brooklyn, , Jones, 93, 500) (Perryridge, Horseneck, , Hayes, 16, 1300 ) (Mianus, Horseneck, , Jones, 17, 1000) (North Town, Rye, , Hayes, 15, 1500) Isso se dá devido ao uso incorreto do atributo nome_cliente com atributo de referências entre as duas relações (agência_cliente, cliente_empréstimo). O atributo nome_cliente não é chave primária em nenhuma das relações.

31 Decomposição Analise o problema de encontrar todas as agências que tenham feito um empréstimo com totais menores que 1000 reais. Embora existam mais tuplas em agência_cliente X cliente_empréstimo, temos, na realidade, menos informações. Devido a essa perda de informação, a decomposição realizada no Esquema_linha_de_crédito é uma decomposição com perda ou decomposição com perda na junção. Ou seja, uma má opção de projeto de banco de dados. Considere a seguinte decomposição: Esquema_agência = (nome_agência, cidade_agência, fundos) Esquema_info_empréstimo = (nome_agência, nome_cliente, número_empréstimo, total)

32 Considerações... nome_agência cidade_agência, fundos é uma dependência funcional que se realiza no projeto. nome_agência determina todos os atributos do esquema_agência. Logo, podemos concluir que nome_agência é uma superchave para o esquema_agência. O atributo comum entre os esquemas da decomposição é nome_agência. Assim, o único modo de representar um relacionamento entre atributos dos dois esquemas na decomposição é por meio deste atributo. Diferença entre esta decomposição e a anterior: o valor dos fundos e da cidade de uma agência é o mesmo, qualquer que seja o cliente em questão, enquanto que a linha de crédito oferecida pela agência depende do cliente em questão. Este projeto ainda pode ser melhorado. Acrescente as informações de rua e cidade do cliente. Observe as dependências funcionais que devem valer no projeto, as que já valem nas instâncias da decomposição e pense em como o projeto ainda pode ser melhorado.

33 Normalização usando Dependências Funcionais O conjunto de dependências funcionais pode ser usado para projetar um banco de dados relacional evitando as propriedades indesejadas. Entretanto, o estabelecimento do conjunto de dependências funcionais é tarefa do projetista do banco de dados e, deve ser feito com cuidado para não gerar restrições que não se quer obedecer e nem deixar de fora do conjunto as restrições que se deseja obedecer. Usando as dependências funcionais podemos definir algumas formas normais que representam bons projetos de bancos de dados (por exemplo, a 3NF e a BCNF). Contudo, espera-se utilizar as dependências funcionais para atestar a qualidade do projeto construído, ou seja, com a prática em construção de projetos, estes serão naturalmente construídos dentro das formas normais desejadas.

34 Propriedades desejáveis da decomposição Decomposição sem perda na junção Preservação das dependências Ausência de redundância de informações Considerando o esquema: Esquema_linha_de_crédito = (nome_agência, cidade_agência, fundos, nome_cliente, número_empréstimo, total) Considerando o conjunto de dependências funcionais que deseja-se que se realize no esquema: nome_agência fundos, cidade_agência número_empréstimo total, nome_agência Analise a seguinte proposta de decomposição: Esquema_agência = (nome_agência, fundos, cidade_agência) Esquema_empréstimo = (nome_agência, número_empréstimo, total) Esquema_devedor = (nome_cliente, número_empréstimo)

35 Decomposição sem perda na junção A decomposição sugerida é sem perdas na junção? Seja R um esquema de relação e F um conjunto de dependências funcionais sobre R. Sejam R1 e R2 formas de decomposição de R. Essa decomposição é uma decomposição sem perda na junção de R se ao menos uma das seguintes dependências funcionais está em F + : R1 R2 R1 R1 R2 R2

36 Preservação das Dependências Sempre que ocorre uma atualização no banco de dados, o sistema deve checar se ela criará uma relação ilegal isto é, uma relação que não satisfaça todas as dependências funcionais. Devemos projetar esquemas de banco de dados relacionais capazes de proporcionar esta checagem eficientemente, ou seja, sem a necessidade de realizar junções. Seja F um conjunto de dependências funcionais de um esquema R e seja R1, R2,..., Rn uma decomposição de R. A restrição F para Ri é o conjunto Fi de todas as dependências funcionais em F + que contenham somente atributos de Ri.

37 Preservação das Dependências Já que todas as dependências funcionais em uma restrição contêm somente atributos de apenas uma esquema de relação, é possível testar se tais dependências são satisfeitas checando somente uma relação. O conjunto de restrições F1, F2,..., Fn é o conjunto das dependências funcionais que podem ser checadas eficientemente. Agora é preciso se certificar de que é suficiente testar somente essas restrições. Seja F = F1 F2 Fn. F o conjunto de dependências funcionais do esquema R, mas, em geral F F. Entretanto, mesmo que F F, pode ser que F + = F +. Dizemos que uma decomposição preserva as dependências se ela possui a propriedade F + = F +.

38 Ausência de Redundância de Informação A decomposição sugerida não apresenta redundância de informações, como é o caso do Esquema_linha_de_crédito. O grau alcançado por essa ausência de redundância é representado pelas formas normais.

39 Referências Sistemas de Banco de Dados. (Cap. 6-7) Abraham Silberchatz, Henry F. Korth e S. Sudarshan. 3ª Edição. Makron Books, Introdução a Banco de Dados (Apostila). (Cap. 9) Osvaldo Kotaro Takai, Isabel Cristina Italiano, João Eduardo Ferreira. DCC-IME-USP, Sistemas de Banco de Dados. (Cap. 10 e 11) Ramez Elsmari e Shamkant B. Navathe. 4ª Edição. Editora Pearson Addison Wesley, 2005.