Projeto de Banco de Dados e Teoria Relacional

C. J. Date

Novatec

Authorized Portuguese translation of the English edition of titled Database Design and Relational Theory, First Edition ISBN 9781449328016 © 2012 Chris Date. This translation is published and sold by permission of O'Reilly Media, Inc., the owner of all rights to publish and sell the same.

Tradução em português autorizada da edição em inglês da obra Database Design and Relational Theory, First Edition ISBN 9781449328016 © 2012 Chris Date. Esta tradução é publicada e vendida com a permissão da O'Reilly Media, Inc., detentora de todos os direitos para publicação e venda desta obra. © Novatec Editora Ltda. [2015].

Todos os direitos reservados e protegidos pela Lei 9.610 de 19/02/1998. É proibida a reprodução desta obra, mesmo parcial, por qualquer processo, sem prévia autorização, por escrito, do autor e da Editora.

Editor: Rubens Prates Tradução: Acauan Fernandes Revisão técnica: Edgard Damiani Assistente editorial: Priscila A. Yoshimatsu Revisão gramatical: Marta Almeida de Sá Editoração eletrônica: Carolina Kuwabata ISBN: 978-85-7522-455-7 Histórico de impressões: Outubro/2015

Primeira edição

Novatec Editora Ltda.

Rua Luís Antônio dos Santos 110 02460-000 – São Paulo, SP – Brasil Tel.: +55 11 2959-6529 Email: novatec@novatec.com.br Site: www.novatec.com.br Twitter: twitter.com/novateceditora Facebook: facebook.com/novatec LinkedIn: linkedin.com/in/novatec

capítulo 1

Introdução

(Sendo perguntado sobre o que jazz1 significa) Cara, se você precisa perguntar, é porque nunca saberá.

– Louis Armstrong (atribuído)

Este livro tem um subtítulo, Formas Normais e Tudo o Mais. É claro que alguma explicação se faz necessária! Em primeiro lugar, é claro, estou falando sobre teoria de projetos, e todos sabem que as formas normais são um componente importante dessa teoria; daí a primeira parte do meu subtítulo. Porém há mais coisas nessa teoria do que apenas formas normais, e esse fato explica a segunda parte do subtítulo. Em terceiro lugar, infelizmente, acontece que – do ponto de vista do praticante, de qualquer maneira – a teoria de projetos é cheia de termos e conceitos que parecem difíceis de entender e que não parecem ter muito a ver com projetos tal como são realmente executados na prática. É por isso que moldei a segunda parte do meu subtítulo em termos coloquiais (para não dizer gírias); queria expressar a ideia, ou impressão, de que, embora estivéssemos necessariamente lidando com material “difícil” de vez em quando, o tratamento desse material seria tão menos assustador ou intimidante quanto eu poderia tê-lo deixado. Mas, se eu fui bem-sucedido nesse objetivo, cabe a você julgar, é claro.

Também gostaria de falar um pouco mais sobre a questão de a teoria de projetos ter algo a ver com projetos conforme são executados na prática. Deixe-me ser claro: ninguém poderia, ou deveria, alegar que projetar bancos de dados é fácil. Todavia, um conhecimento sólido da teoria só pode ajudar. Na verdade, se você executar um projeto apropriadamente – se quiser criar bancos de dados que sejam tão robustos, flexíveis e precisos quanto deveriam –, então simplesmente terá de lidar com a teoria de projetos. Não há alternativa: pelo menos se você quiser se intitular um profissional. A teoria de projetos é a base científica para projetos de banco de dados, assim como o modelo relacional é a base científica para tecnologias de banco de dados em geral. E, assim como qualquer profissional envolvido com tecnologia de banco de dados geral precisa estar familiarizado com 1 N. do T.: Do subtítulo original, All That Jazz, que em uma tradução livre significa “E Tudo o Mais”.

19

20

Projeto de Banco de Dados e Teoria Relacional

o modelo relacional, qualquer um envolvido com projeto de banco de dados em especial precisa estar familiarizado com a teoria de projetos. Um projeto adequado é muito importante! Afinal, o banco de dados fica no centro de muitas coisas que fazemos no mundo da computação; assim, se for mal projetado, os impactos negativos podem se espalhar de modo extraordinário.

Algumas citações da literatura Já que falaremos bastante sobre formas normais, achei que poderia ser – bem, talvez não instrutivo, mas divertido (?) – começar com algumas citações da literatura.

O ponto inicial de todo o conceito de formas normais é, claro, a primeira forma normal (1FN), e então uma questão óbvia é: Você sabe o que é a 1FN? Conforme as seguintes citações demonstram (com as fontes omitidas para proteger os culpados), muitas pessoas não sabem: • Para se atingir a primeira forma normal, cada campo de uma tabela deve expressar uma informação única.

• É dito que uma entidade está na primeira forma normal (1FN) quando todos os atributos possuem apenas um valor.

• Uma relação está na 1FN se, e somente se, todos os domínios subjacentes contiverem apenas valores atômicos.

• Se não houver grupos repetidos de atributos, então [a tabela] está na 1FN. Pode-se argumentar que algumas, se não todas, dessas citações estão pelo menos vagamente corretas – mas elas são irremediavelmente desleixadas, mesmo quando estão, de modo geral, no caminho correto. (No caso de você estar imaginando, darei uma definição precisa e correta da 1FN no capítulo 4).

Vamos examinar mais de perto o que está acontecendo aqui. Aqui está novamente a primeira citação, agora apresentada integralmente: • Para obter a primeira forma normal, cada campo de uma tabela deve expressar uma informação única. Por exemplo, se você tivesse uma tabela Clientes com duas colunas para o número de telefone, seu projeto violaria a primeira forma normal. A primeira forma normal é razoavelmente fácil de ser alcançada, já que poucas pessoas veriam uma necessidade de informações duplicadas em uma tabela.

Capítulo 1 ■ Introdução

21

OK, então aparentemente estamos falando de um projeto que se parece um pouco com isto:

Bom, não posso dizer se isso é um bom projeto ou não, mas certamente não viola a 1FN. (Não posso dizer se é um bom projeto porque não sei exatamente o que “duas colunas para o número de telefone” significa. A expressão “informações duplicadas em uma tabela” sugere que estamos gravando o mesmo número de telefone duas vezes, mas tal interpretação é absurda por si só. Porém, mesmo se essa interpretação estiver correta, ainda assim não constituiria uma violação da 1FN como tal.)

Aqui está a outra: • A Primeira Forma Normal ... significa que a tabela não deve ter “grupos repetidos” de campos ... Um grupo repetido é quando você repete o mesmo atributo básico (campo) várias vezes. Um bom exemplo disso é quando você deseja armazenar os itens que compra em uma mercearia ... [e o autor segue em frente apresentando o exemplo, presumivelmente para ilustrar o conceito de um grupo repetido, de uma tabela chamada Item Table com colunas Customer, Item1, Item2, Item3 e Item4]:

Bem, esse projeto é quase certamente ruim – o que acontece se o cliente não comprar exatamente quatro itens? –, mas o motivo de ele ser ruim não é o fato de que ele viola a 1FN; assim como o exemplo anterior, na verdade, ele é um projeto em 1FN. E, embora, seja verdade que a 1FN signifique, vagamente, “nenhum grupo repetido”, um grupo repetido não é “quando você repete o mesmo atributo básico diversas vezes”. (Eu explicarei o que isso realmente significa no capítulo 4, quando esclarecer o que é realmente a 1FN.) E que tal esta (um pedido de ajuda encontrado na Internet)? Estou citando-a de forma completamente textual, exceto pelo fato de ter colocado uma parte do texto em negrito: • Tenho tentado encontrar a forma correta de normalizar tabelas em Access.

Pelo que entendo, vai-se da primeira forma normal para a segunda, e depois para a terceira. Geralmente vai-se até aí, mas às vezes até a quinta e a sexta.

Então também há a terceira de Cobb. Tudo isso faz sentido para mim. Eu

22

Projeto de Banco de Dados e Teoria Relacional devo lecionar para uma turma que começa semana que vem e acabei de obter o livro-texto. Ele diz algo inteiramente diferente. Diz que a segunda forma normal é apenas para tabelas com uma chave primária de múltiplos campos, que a terceira forma normal é apenas para tabelas com uma chave de apenas um campo. A quarta forma normal pode ir da primeira para a quarta, onde não existam relacionamentos “um para muitos” independentes entre a chave primária e os campos que não sejam chaves. Alguém pode esclarecer isso para mim, por favor?

E mais uma (desta vez, com uma resposta “útil”): • Não está muito claro para mim o que “normalizado” significa. Você poderia ser específico sobre a que regras de normalização está se referindo? De que forma o meu esquema não está normalizado?

Normalização: O processo de substituir coisas duplicadas por uma referência à coisa original.

Por exemplo, dado que “john é uma pessoa" e "john obedece ao exército", observa-se que o "john" na segunda sentença é uma repetição de "john" na primeira. Usando os meios fornecidos pelo seu sistema, a segunda sentença deve ser armazenada como "→john obedece ao exército".

Uma observação sobre tecnologia Como tenho certeza de que você percebeu, as citações na seção anterior foram expressas, na sua maior parte, na terminologia familiar, “amigável ao usuário”, de tabelas, linhas e colunas (ou campos). Neste livro, de uma forma diferente, tenderei a favorecer os termos mais formais relação, tupla e atributo. Peço desculpas se essa decisão de minha parte acabar tornando o texto um pouco mais difícil de entender, mas tenho meus motivos. Como eu disse em SQL e Teoria Relacional2: Geralmente, sou simpático à ideia de usar termos mais amigáveis ao usuário, se eles puderem ajudar a tornar as ideias mais palatáveis. Nesse caso, entretanto, me parece que, lamentavelmente, eles não tornam as ideias mais palatáveis; em vez disso, eles as distorcem, e na verdade fazem um desserviço à causa da compreensão genuína. A verdade é que uma relação não é uma tabela, uma tupla não é uma linha e um atributo não é uma coluna. E, embora possa ser aceitável fingir o contrário em contextos informais – de fato, eu mesmo frequentemente faço isso –, 2 Lembre-se do que eu disse no prefácio, que por todo este livro uso SQL e Teoria Relacional como uma forma abreviada de referência ao meu livro SQL e Teoria Relacional (Novatec, 2014).

Capítulo 1 ■ Introdução

23

eu argumentaria que isso só é aceitável se todos compreendermos que os termos mais amigáveis para o usuário são apenas uma aproximação da verdade e que, de modo geral, não capturam a essência do que está realmente acontecendo. Para colocar de outra forma, se você entender o estado real das coisas, então o uso criterioso de termos amigáveis para o usuário pode ser uma boa ideia; mas para aprender e perceber o estado real das coisas em primeiro lugar, você realmente precisa lidar com os termos formais.

Ao que foi dito, deixe-me acrescentar (conforme eu disse no prefácio) que suponho que você saiba exatamente o que são relações, atributos e tuplas! – embora, na verdade, definições formais dessas construções possam ser encontradas no capítulo 5.

Existe outra questão relacionada à terminologia que também preciso resolver.

O modelo relacional é, obviamente, um modelo de dados. Infelizmente, entretanto, este último termo possui dois significados bastante distintos no mundo dos bancos de dados3. O primeiro e mais fundamental é este: • Definição: um modelo de dados (primeiro sentido) é uma definição abstrata, autocontida e lógica das estruturas de dados, dos operadores de dados e assim por diante, que juntos constituem a máquina abstrata com a qual os usuários interagem.

Esse é o significado que temos em mente quando falamos especificamente do modelo relacional: as estruturas de dados no modelo relacional são relações, é claro, e os operadores de dados são os operadores relacionais de projeção, junção etc. (Com relação ao “assim por diante” da definição, o modelo abrange coisas como chaves, chaves estrangeiras e diversos conceitos relacionados.)

O segundo significado do termo modelo de dados é o seguinte: • Definição: um modelo de dados (segundo sentido) é um modelo dos dados – especialmente dos dados persistentes – de alguma determinada empresa.

Em outras palavras, um modelo de dados no segundo sentido é apenas um projeto de banco de dados (lógico e, possivelmente, um tanto abstrato). Por exemplo, poderíamos falar do modelo de dados de algum banco, ou algum hospital, ou algum departamento governamental.

Tendo explicado esses dois significados diferentes, gostaria de chamar sua atenção para uma analogia que acho que esclarece bem o relacionamento entre eles: 3 Essa observação está inegavelmente correta. Todavia um revisor quis que eu acrescentasse que os dois significados podem ser imaginados como sendo basicamente o mesmo conceito em níveis diferentes de abstração.

24

Projeto de Banco de Dados e Teoria Relacional

• Um modelo de dados no primeiro sentido é como uma linguagem de programação cujos constituintes podem ser usados para resolver muitos problemas específicos, mas que por si só não têm conexão direta com qualquer problema específico.

• Um modelo de dados no segundo sentido é como um programa específico escrito nessa linguagem – ele usa os recursos fornecidos pelo modelo, no primeiro sentido do termo, para resolver algum problema.

Do que foi visto anteriormente, conclui-se que se estivermos falando sobre modelos de dados no segundo sentido, então podemos, de certa forma, falar de “modelos relacionais” no plural, ou “um” modelo relacional (com um artigo indefinido). Mas se estivermos falando em modelos de dados no primeiro sentido, então só há um modelo relacional, e é o modelo relacional (com o artigo definido).

Conforme você já deve saber, a maioria dos textos sobre projetos de banco de dados, especialmente se o seu enfoque for pragmático, em vez de focar na teoria subjacente, usa o termo “modelo” ou “modelo de dados” exclusivamente no segundo sentido. Porém – por favor, observe com atenção! – não sigo essa prática neste livro; na verdade, não uso o termo “modelo”, exceto ocasionalmente para me referir ao modelo relacional.

O exemplo corrente Deixe-me apresentar o exemplo que usarei como base para a maioria das discussões no restante do livro: o familiar – para não dizer banalizado – banco de dados fornecedores-e-peças. (Peço desculpas por mais uma vez trazer à vista esse velho cavalo de guerra, mas acredito que o uso de um mesmo exemplo em uma diversidade de livros e publicações possa ajudar, e não prejudicar, o aprendizado.)

Valores de exemplo são mostrados na figura 1.14. Para detalhar: • Fornecedores: A variável de relação (ou relvar) S denota fornecedores5. Cada fornecedor possui um código (SNO) que é exclusivo para ele; um nome (SNAME), não necessariamente único (embora os valores de SNAME da figura 1.1 sejam); um valor de status (STATUS) representando algum tipo de classificação ou nível de preferência entre os fornecedores; e uma localização (CITY).

4 Por motivos que se tornarão claros posteriormente, os valores mostrados na figura 1.1 diferem em dois pequenos aspectos de outros livros meus: o status do fornecedor S2 é mostrado como 30 em vez de 10, e a cidade da peça P3 é mostrada como Paris em vez de Oslo.

5 Se você não souber o que é uma variável de relação, por enquanto você pode supor que ela seja uma tabela no sentido comum de banco de dados. Veja mais explicações no capítulo 2.

Capítulo 1 ■ Introdução

25

• Peças: A variável de relação P denota peças (mais precisamente, tipos de peças). Cada tipo de peça possui um código (PNO), que é exclusivo; um nome (PNAME), não necessariamente único; uma cor (COLOR); um peso (WEIGHT); e um local onde as peças desse tipo são armazenadas (CITY).

• Remessas: A variável de relação SP denota remessas (mostra quais peças são fornecidas, ou remetidas, por quais fornecedores). Cada remessa possui um código de fornecedor (SNO), um código de peça (PN) e uma quantidade (QTY). Além disso, suponho, para o propósito deste exemplo, que exista no máximo uma remessa em um determinado momento para um determinado fornecedor e uma determinada peça e, assim, cada remessa terá uma combinação código-de-fornecedor/código-de-peça exclusiva.

Figura 1.1 – Valores do banco de dados de exemplo fornecedores-e-peças.

Chaves Antes de seguirmos adiante, preciso revisar o conceito familiar de chaves, no sentido relacional desse termo. Em primeiro lugar, como tenho certeza de que você sabe, cada variável de relação tem pelo menos uma chave candidata. Uma chave candidata é, basicamente, apenas um identificador exclusivo; em outras palavras, é uma combinação de atributos – frequentemente, mas nem sempre, uma “combinação” consistindo de apenas um único atributo – de modo que cada tupla na variável de relação tenha um valor único para a combinação em questão. Por exemplo, com relação ao banco de dados da figura 1.1:

26

Projeto de Banco de Dados e Teoria Relacional

• Cada fornecedor possui um código exclusivo e cada peça possui um código exclusivo, assim {SNO} é uma chave candidata para S e {PNO} é uma chave candidata para P. • Quanto às remessas, supondo que exista no máximo uma remessa em um determinado momento para um determinado fornecedor e uma determinada peça, {SNO, PNO} é uma chave candidata para SP. Observe as chaves, a propósito; repetindo, chaves candidatas são sempre combinações, ou conjuntos, de atributos (mesmo quando o conjunto em questão contém apenas um atributo), e a representação convencional em papel de um conjunto é uma lista de elementos separados por vírgulas e entre chaves. Observação: a expressão útil lista separada por vírgulas pode ser definida da seguinte maneira: seja xyz uma construção sintática (por exemplo, “nome de atributo”). Então, uma lista xyz separada por vírgulas denota uma sequência de zero ou mais xyzs na qual cada par de xyzs adjacentes é separado por uma vírgula (assim como, opcionalmente, por um ou mais espaços antes ou depois da vírgula, ou ambos).

A seguir, como tenho certeza de que você também sabe, uma chave primária é uma chave candidata que foi destacada de alguma forma por algum tipo de tratamento especial. Se a variável de relação em questão tiver apenas uma chave candidata, então não faz diferença se a chamarmos de chave primária. Porém, se a variável de relação tiver duas ou mais chaves candidatas, então é costumeiro escolher uma delas para ser a primária, o que significa que ela é, de alguma forma, “mais igual do que as outras”. Suponha, por exemplo, que os fornecedores sempre tenham um código exclusivo e um nome exclusivo, de modo que {SNO} e {SNAME} sejam ambas chaves candidatas. Poderíamos então escolher {SNO}, digamos, como a chave primária.

Observe que eu disse que é costumeiro escolher uma chave primária. De fato é habitual – mas não é 100% necessário. Se houver apenas uma chave candidata, então não há escolha e, portanto, não há problema; contudo, se houver duas ou mais, então ter de escolher uma delas e torná-la chave primária parece um pouco arbitrário, pelo menos para mim. (Certamente há situações em que parece não haver bons motivos para fazer tal escolha. Poderia existir até bons motivos para não fazê-lo. O apêndice A detalha tais questões.) Por motivo de familiaridade, geralmente seguirei a disciplina da chave primária neste livro – e em figuras como a 1.1, indicarei atributos de chaves primárias com um sublinhado duplo –, mas quero enfatizar o fato de que realmente são as chaves candidatas, e não as chaves primárias, que são significativas a partir de um ponto de vista relacional e, de fato, também do ponto de vista da teoria de projetos. Em parte por esses

Capítulo 1 ■ Introdução

27

motivos, deste ponto em diante usarei o termo chave, não qualificado, significando qualquer chave candidata, independentemente de a chave candidata em questão ter sido designada como primária. (No caso de você estar imaginando, o tratamento especial recebido por chaves primárias com relação às outras chaves é de natureza principalmente sintática, de qualquer forma; isso não é fundamental, nem muito importante.)

Mais terminologia: Em primeiro lugar, uma chave envolvendo dois ou mais atributos é, às vezes, chamada de composta (e uma chave não composta é às vezes chamada de simples). Em segundo lugar, se uma determinada variável de relação

tiver duas ou mais chaves e uma for escolhida como a primária, então as outras, às vezes, são chamadas de chaves alternativas (veja o apêndice A). Em terceiro lugar, uma chave estrangeira é uma combinação, ou conjunto, de atributos FK de alguma variável de relação R2 de modo que cada valor FK deva ser igual a algum valor de alguma chave K em alguma variável de relação R1 (R1 e R2 não sendo necessariamente distintas)6. Com referência à figura 1.1, por exemplo, {SNO} e {PNO} são ambas chaves estrangeiras na variável de relação SP, correspondendo às chaves {SNO} e {PNO} nas variáveis de relação S e P, respectivamente.

O lugar da teoria de projetos Para repetir algo que disse no prefácio, pelo termo projeto quero dizer projeto lógico, não físico. O projeto lógico se preocupa com o que o banco de dados se parece para o usuário (o que significa, grosso modo, quais variáveis de relação existem e quais restrições se aplicam a elas); o projeto físico, em comparação, se preocupa com o modo como um determinado projeto lógico é mapeado no armazenamento físico7. E o termo teoria de projetos se refere especificamente ao projeto lógico, não ao físico – a questão é que o projeto físico é necessariamente dependente de aspectos (em especial relacionados a desempenho) do SGBD em mente, enquanto o projeto lógico é, ou deveria ser, independente de SGBD. Por todo este livro, então, o termo projeto não qualificado deve ser entendido como projeto lógico, excetuando-se declarações explícitas em contrário.

A teoria de projetos em si não faz parte do modelo relacional; ela é uma teoria separada construída sobre esse modelo. (É apropriado pensar nela como parte da teoria relacional em geral, mas ela não é, repetindo, parte do modelo relacional 6 Essa definição é deliberadamente um pouco simplificada (embora seja suficientemente boa para os propósitos atuais). Uma definição melhor pode ser encontrada em SQL e Teoria Relacional.

7 Esteja avisado, entretanto, de que outros autores (a) usam projeto lógico e projeto físico significando algo diferente e (b) usam outros termos significando o que eu quero dizer com estes termos. Caveat Lector (Leitor avisado).

28

Projeto de Banco de Dados e Teoria Relacional

em si). Assim, conceitos de projetos, como normalizações adicionais, são baseados em noções mais fundamentais – por exemplo, os operadores de projeção e junção da álgebra relacional – que fazem parte do modelo relacional. (Tendo dito tudo isso, seria possível certamente argumentar que a teoria de projetos é uma consequência lógica do modelo relacional, pelo menos em parte. Em outras palavras, seria inconsistente concordar com o modelo relacional de modo geral, mas não concordar com a teoria de projetos que se baseia nele.)

O objetivo geral do projeto lógico é obter um projeto que seja (a) independente de hardware, por motivos óbvios; (b) independente de sistema operacional e SGBD, novamente por motivos óbvios; e, finalmente, e talvez um pouco controversamente, (c) independente de aplicação (em outras palavras, estamos preocupados principalmente com o que os dados são, em vez de como eles serão usados). A independência de aplicação nesse sentido é desejável pelo excelente motivo de normalmente – talvez sempre – acontecer de nem todos os usos dos dados serem conhecidos em tempo de projeto; assim, queremos um projeto que seja robusto, no sentido de que não seja invalidado pelo advento de requisitos de aplicação que não tenham sido previstos no momento do projeto original. Observe que uma consequência importante dessa situação é que não estamos (ou pelo menos não deveríamos estar) interessados em fazer concessões de projeto por motivos de desempenho físico. A teoria de projetos nunca deve ser guiada por considerações de desempenho.

Voltemos à teoria de projetos. Conforme veremos, essa teoria inclui uma diversidade de teoremas formais, teoremas esses que fornecem diretrizes práticas para os projetistas seguirem. Assim, se você for um projetista, precisa estar familiarizado com esses teoremas. Deixe-me acrescentar rapidamente que não quero dizer que você tenha de saber como provar esses teoremas (embora, na verdade, as provas sejam frequentemente bastante simples); o que eu quero dizer é que você tem de saber o que os teoremas dizem – ou seja, tem de conhecer os resultados – e deve estar preparado para aplicar esses resultados. Isto é o bom dos teoremas: assim que alguém os prova, seus resultados ficam disponíveis para todos usarem sempre que precisarem. Às vezes se alega, não totalmente sem razão, que tudo o que a teoria de projetos realmente faz é reforçar a sua intuição. O que eu quero dizer com essa observação?

Bem, analise o banco de dados fornecedores-e-peças. O projeto óbvio para esse banco de dados é o ilustrado na figura 1.1; o que eu quero dizer é que é “óbvio” que três variáveis de relação são necessárias, que o atributo STATUS deve ficar na variável de relação S, que o atributo COLOR deve ficar na variável de relação P,

Capítulo 1 ■ Introdução

29

que o atributo QTY deve ficar na variável de relação SP e assim por diante. Mas por que exatamente essas coisas são óbvias? Bom, suponha que façamos um projeto diferente; suponha que movemos o atributo STATUS da variável de relação S, por exemplo, para a variável de relação SP (intuitivamente o lugar errado para ele, já que o status é uma propriedade dos fornecedores, e não das remessas). A figura 1.2 mostra um valor de exemplo para essa variável de relação de remessas revisada, que eu chamarei de STP para evitar confusão8:

Figura 1.2 – Valor de exemplo para a variável de relação STP.

Uma olhada rápida na figura é suficiente para mostrar o que está errado com esse projeto: ele é redundante, no sentido de que cada tupla do fornecedor S1 nos informa que S1 possui status 20, cada tupla do fornecedor S2 nos informa que S2 tem status 30 e assim por diante9. E a teoria de projetos nos diz que não projetar o banco de dados da forma óbvia levará a tal redundância, e também nos informa (embora implicitamente) quais serão as consequências de tal redundância. Em outras palavras, a teoria de projetos tem muito a ver com a redução da redundância, conforme veremos. (Como uma nota lateral, lembro que – em parte por esses motivos – a teoria foi descrita, talvez um pouco indelicadamente, como uma boa fonte de exemplos ruins.)

Se a teoria de projeto realmente reforça a sua intuição, então poderia ser (e de fato tem sido) criticada por ser, na verdade, apenas senso comum. Como exemplo, analise novamente a variável de relação STP. Conforme eu disse, essa variável de relação está mal projetada; as redundâncias são óbvias, as consequências também são óbvias e qualquer projetista humano competente evitaria “naturalmente” tal projeto, mesmo se aquele projetista não tivesse conhecimento explícito de 8 Por motivos óbvios, eu uso T, não S, como abreviação de STATUS, aqui e por todo este livro.

9 Você talvez tenha percebido outro problema também: o projeto não pode representar apropriadamente fornecedores como o S5, que atualmente não fornece peças. Tais “anomalias de atualização” são discutidas no capítulo 3.

30

Projeto de Banco de Dados e Teoria Relacional

teoria de projetos. Mas o que “naturalmente” significa aqui? Quais princípios estão sendo aplicados por esse projetista humano ao optar por um projeto mais “natural” (e melhor)?

A resposta é: eles são exatamente os princípios sobre os quais a teoria de projetos fala (os princípios de normalização, por exemplo). Em outras palavras, projetistas competentes já têm esses princípios em mente, mesmo que nunca os tenha estudado formalmente e não possa dar um nome a eles ou articulá-los com precisão. Então, sim, os princípios são senso comum – mas eles são senso comum formalizado.

(Senso comum pode ser comum, mas nem sempre é fácil dizer exatamente o que é isso!) O que a teoria de projetos faz é declarar de forma precisa em que consistem determinados aspectos do senso comum. Em minha opinião, essa é a verdadeira conquista – ou uma das verdadeiras conquistas, de qualquer maneira – da teoria: ela formaliza determinados princípios do senso comum, abrindo assim a porta para a possibilidade de mecanizar tais princípios (ou seja, incorporá-los em ferramentas de projeto computadorizadas). Críticos da teoria muitas vezes não percebem a questão: eles alegam, justamente, que as ideias são na sua maioria apenas senso comum, mas não parecem perceber que é uma conquista significativa declarar o que significa o senso comum de uma forma precisa e formal.

Como um tipo de adendo ao que foi dito, observo que o senso comum pode nem sempre ser tão comum. O seguinte extrato ligeiramente editado de um artigo de Robert R. Brown da Hughes Aircraft10 ilustra a questão. O autor começa dando um “exemplo real simplificado” – palavras dele – envolvendo um arquivo de funcionários (com campos para o código do funcionário, nome do funcionário, telefone, código do departamento e nome do gerente) e um arquivo de departamentos (com campos para o código do departamento, nome do departamento, nome do gerente e telefone do gerente), todos com significados intuitivamente óbvios. A seguir, ele continua: O banco de dados real no qual este exemplo é baseado tinha muito mais arquivos e muito mais redundância. Quando o projetista foi perguntado quanto às suas razões para tal projeto, citou o desempenho e a dificuldade de fazer junções. Embora a redundância deva estar clara para você no meu exemplo, ela não estava tão evidente assim na documentação do projeto. Em bancos de dados grandes com muito mais arquivos e campos, é impossível encontrar as duplicações sem executar análises extensas de informações e sem ter longas discussões com os especialistas na estrutura organizacional do usuário.

10 Robert R. Brown: “Database Systems in Engineering: Key Problems, and Potential Solutions”, no simpósio sobre bancos de dados que ocorreu em Sydney, na Austrália (de 15 a 17 de novembro de 1984).

Capítulo 1 ■ Introdução

31

Incidentalmente, há outra citação que eu gosto muito – na verdade, eu a usei como um epígrafe em SQL e Teoria Relacional – que apoia a minha afirmação de que os praticantes realmente precisam conhecer as bases teóricas de sua área. É de Leonardo da Vinci (e tem, dessa forma, 500 anos de idade!) e é assim (acrescentei o negrito): Aqueles que se enamoram com a prática sem a teoria são como um navegador que entra em um navio sem leme nem bússola, que jamais tem certeza para onde vai. Sempre a prática deve ser edificada sobre um conhecimento sólido da teoria.

Objetivos deste livro Se você for como eu, terá encontrado muitos termos de teoria de projetos na literatura, nas apresentações e assim por diante – termos como forma normal projeção-junção, perseguição, dependência de junção, preservação de DF (dependência funcional) e muitos outros –, e tenho certeza de que ficou imaginando de vez em

quando exatamente o que todos eles significavam. Assim, é um dos meus objetivos neste livro explicar tais termos: defini-los cuidadosa e precisamente, explicar sua relevância e aplicabilidade, e geralmente remover qualquer ar de mistério que possa haver em torno deles. E, se for bem-sucedido nesse objetivo, terei feito muito para explicar o que é a teoria de projetos e por que ela é importante (de fato, um título alternativo possível para o livro seria Teoria de Projetos de Banco de Dados: O que é e por que você deve se importar). De modo geral, é meu objetivo fornecer uma introdução gradual à teoria de projetos para profissionais de banco de dados.

Mais especificamente, o que eu quero fazer é: • Revisar, embora a partir de uma perspectiva possivelmente não familiar, aspectos de projeto com os quais você já deveria estar familiarizado.

• Explorar em profundidade aspectos com os quais você provavelmente não esteja familiarizado.

• Fornecer explicações claras e precisas, e definições (com muitos exemplos) de todos os conceitos pertinentes.

• Não gastar muito tempo em material que já esteja amplamente entendido, como a 2FN e a 3FN.11 11 Contudo darei pelo menos definições precisas desses conceitos familiares para não deixar a discussão incompleta. Já que tenho certeza de que eles realmente são familiares, entretanto, tomarei a liberdade de apelar para eles de vez em quando, mesmo antes de chegarmos às definições.

32

Projeto de Banco de Dados e Teoria Relacional

Tendo dito tudo isso, também devo dizer que projeto de banco de dados não é o meu assunto favorito. O motivo de não sê-lo é que muito desse assunto ainda é um pouco... bem, subjetivo. Conforme eu disse anteriormente, a teoria de projetos é a base científica para projetos de banco de dados. Infelizmente, entretanto, há inúmeras questões de projeto que a teoria simplesmente não aborda (ainda).

Assim, embora os princípios formais que descreverei neste livro representem a parte científica de projetos, há outras partes que, conforme eu disse em outro lugar, ainda estão mais na natureza do esforço artístico. De fato, uma mensagem do livro é precisamente que precisamos de mais ciência nesta área.

Para colocar uma interpretação mais distinta sobre a questão, gostaria de chamar sua atenção para o seguinte. A teoria de projetos tem a ver (pelo menos em parte) com capturar o significado dos dados e, como o próprio Codd disse uma vez em conexão com tal noção12: [A] tarefa de capturar (de maneira razoavelmente formal) mais do ... significado dos dados é infindável. Apesar disso, o objetivo é muito importante, porque mesmo sucessos pequenos podem trazer compreensão e ordem na área de projeto de banco de dados.

Na verdade, vou ainda mais longe: se o seu projeto violar algo conhecido, então, como eu escrevi em algum outro lugar (em um contexto ligeiramente diferente), uma coisa da qual você pode estar certo é que as coisas darão errado. E, embora possa ser difícil dizer exatamente o que será, e também possa ser difícil dizer se as coisas darão muito errado, ou um pouco errado, você sabe – é garantido – que elas darão errado. Teoria é importante.

Observações finais Este livro aumentou enquanto estava sendo escrito; acontece que, apesar do tom ligeiramente negativo das observações da seção anterior, na verdade, há muito material bom a ser examinado. Mais ainda, o material se desenvolve. Assim, embora possa parecer que os primeiros capítulos estão indo devagar, creio que você perceberá que a velocidade aumenta mais tarde. Parte da questão é o número de termos e conceitos que precisam ser apresentados; as ideias realmente não são muito difíceis, mas podem parecer um pouco complexas, pelo menos até que você fique confortável com a terminologia. Por esse motivo, pelo menos em 12 A citação é do artigo de Codd intitulado “Extending the Database Relational Model to Capture More Meaning”, ACM TODS 4, no 4, 1979 (o itálico é meu). Ted Codd foi, é claro, o inventor do modelo relacional: ele também foi a pessoa que primeiro definiu o conceito de normalização de modo geral, assim como as três primeiras formas normais (1FN, 2 FN, 3FN) em especial.

Capítulo 1 ■ Introdução

33

algumas partes do livro, apresentarei o material duas vezes – primeiro, a partir de uma terminologia informal, e depois novamente a partir de uma mais formal.

(Conforme Bertrand Russell uma vez, memoravelmente, disse: A escrita pode ler legível ou precisa, mas não ao mesmo tempo. Estou tentando fazer as duas coisas.)

Parece apropriado terminar este capítulo com outra citação de Bertrand Russell13: Tenho sido acusado de ter o hábito de mudar de opinião ... Não estou nem um pouco envergonhado [desse hábito]. Que médico que já estivesse atuando em 1900 sonharia em se gabar de que as suas opiniões nunca mudaram durante a última metade do século? ... O tipo de filosofia que eu valorizo e tenho me empenhado em adotar é científica, no sentido de que há algum conhecimento definido a ser obtido e que novas descobertas podem tornar inevitável a admissão de erros anteriores por qualquer mente sincera. Pelo que tenho dito, antes ou depois, não reivindico o tipo de verdade que os teólogos alegam para suas crenças. Apenas digo que, no máximo, a opinião expressa era sensata de se ter na época ... Ficaria muito surpreso se pesquisas subsequentes não mostrassem que ela precisava ser modificada. [Tais opiniões não] pretendiam ser pronunciamentos pontificais, mas apenas as melhores que eu poderia formular na época para promover o pensamento claro e preciso. Clareza, acima de tudo, tem sido meu objetivo.

Já citei esse excerto em outro lugar: no prefácio do meu livro An Introduction to Database System (8ª edição, Addison-Wesley, 2004) em especial. O motivo pelo qual menciono esse livro é que ele inclui, entre outras coisas, um tratamento de tutorial sobre parte do material examinado com mais profundidade no presente livro. Porém o mundo seguiu em frente; meu próprio entendimento da teoria é, espero, melhor do que na época em que escrevi aquele livro, e há aspectos do tratamento dado nele que eu francamente gostaria de revisar agora. Um problema com esse tratamento anterior foi que eu tentei tornar o material mais palatável, adotando a ficção de que qualquer variável de relação tinha apenas uma chave, que poderia, então, ser inofensivamente considerada como a chave primária. Mas uma consequência dessa suposição simplificada foi que várias das definições que dei (por exemplo, da 2FN e da 3FN) não eram totalmente precisas. Esse fato levou a certa confusão – em parte, por culpa minha, admito sinceramente, mas também, em parte, por culpa das pessoas que usaram as definições fora de contexto.

13 A citação é do prefácio de The Bertrand Russel Dictionary of Mind, Matter and Morals (ed. Lester E. Denonn; Citadel Press, 1993).

34

Projeto de Banco de Dados e Teoria Relacional

Exercícios O propósito destes exercícios é dar uma ideia do escopo dos próximos capítulos e também, talvez, testar a extensão do seu conhecimento atual. Eles não podem ser respondidos apenas a partir do material do presente capítulo.

1.1 É verdade que o modelo relacional não requer variáveis de relação para estar em alguma forma normal?

1.2 A redundância de dados sempre deve ser eliminada? Isso é possível?

1.3 Qual a diferença ente a 3FN e a FNBC14?

1.4 É verdade que toda variável de relação “totalmente chave” está na FNBC? 1.5 É verdade que toda variável de relação binária está na 4FN? 1.6 É verdade que toda variável de relação “totalmente chave” está na 5FN? 1.7 É verdade que toda variável de relação binária está na 5FN? 1.8 É verdade que, se uma variável de relação tiver apenas uma chave e apenas um outro atributo, então está na 5FN? 1.9 É verdade que, se uma variável de relação estiver na FNBC, mas não na 5FN, então deve ser “totalmente chave”?

1.10 Você pode dar uma definição precisa para a 5FN? 1.11 É verdade que, se uma variável de relação estiver na 5FN, então está livre de redundância?

1.12 O que é precisamente desnormalização?

1.13 O que é o Teorema de Heath e por que ele é importante?

1.14 O que é o Princípio de Projeto Ortogonal?

1.15 O que torna alguns DJs irredutíveis e outros não?

1.16 O que é preservação de dependência e por que ela é importante?

1.17 O que é a perseguição (the chase)?

1.18 Quantas formas normais você pode citar?

14 N. do T.: Forma Normal de Boyce-Codd.