Normalizao de Dados

[ Projeto ]

Ary Jnior
(ary@ajsolucoes.com.br)

Mestre em Cincias com nfase em Inteligncia Artificial e Bancos de Dados, Professor Universitrio e Gerente de TI. Atua como professor desde 2000, especialmente com disciplinas na rea de Bancos de Dados. Na rea de TI desde 1998 com desenvolvimento, anlise e projeto de Sistemas. Hoje em dia, trabalha com Gerenciamento de Projetos e Sistemas de Bancos de Dados prestando servios para diversas empresas nacionais e multinacionais.

tualmente, comum verificarmos organizaes com bases de dados da ordem dos terabytes. Alm disso, sabido que a necessidade de informaes por parte dos gestores enorme e vem crescendo diariamente. Isto porque a tomada de decises, com base em informaes, torna-se muito mais precisa. E, para que estas informaes sejam geradas com qualidade, necessrio um bom projeto de banco de dados. Sabemos que o objetivo de um projeto de banco de dados obter um conjunto de esquemas de tabelas que nos permita armazenar dados sem redundncia e que as informaes possam ser geradas facilmente. Para verificar se um projeto de banco de dados atende a estes pressupostos, podemos aplicar algumas regras aos projetos em questo. A estas regras, damos o nome de Formas Normais. Originalmente, Edgar F. Codd definiu trs destas formas normais (Primeira Forma Normal, Segunda Forma Nor-

mal e Terceira Forma Normal), mas hoje existem algumas outras (Forma Normal de Boyce-Codd, Quarta Forma Normal e Quinta Forma Normal) como veremos nos tpicos a seguir. Muitos autores dizem que aplicando as trs formas normais definidas por Codd, o projeto do banco de dados j estar livre de redundncias e inconsistncias. Entretanto, outros autores definem como de extrema importncia a aplicao das outras formas normais. Neste artigo, no entraremos nesta discusso e apresentaremos todas as formas normais existentes atualmente. Dessa forma, o leitor ter condies de verificar a importncia ou no da aplicao de todas elas. Para efetuar a normalizao, aplicam-se na ordem as seguintes formas normais: primeira forma normal, segunda forma normal, terceira forma normal. Neste ponto, podemos dar continuidade normalizao seguindo pelas formas normais de Boyce-Codd, quarta forma normal e por ltimo a Quinta Forma

22

SQL Magazine - Normalizao de Dados

NORMA L I Z A O
Normal ou, iniciar diretamente da forma normal Boyce-Codd. Estas formas normais devem ser aplicadas ao modelo de dados definido pelo profissional. Ao final da aplicao das formas normais, podemos dizer que o projeto de banco de dados est livre de redundncias e conseqentemente de inconsistncia. Neste momento, podemos definir normalizao como sendo uma srie de passos que se segue no projeto de um banco de dados que permite um armazenamento consistente e um eficiente acesso aos dados em um banco de dados relacional. Esses passos evitam a redundncia de dados e as chances dos dados se tornarem inconsistentes. Devemos fazer uso destes passos sempre que estivermos projetando nossas solues de banco de dados, salvo casos especficos onde trabalhamos com o conceito de desnormalizao. Como vimos, o uso da normalizao traz grandes benefcios (consistncia, evita redundncia, integridade) e sua no utilizao poder trazer exatamente os problemas resolvidos com normalizao, ou seja: problemas de inconsistncia, redundncia e integridade. Este artigo ser dividido da seguinte forma: inicialmente, sero abordados conceitos importantes envolvidos no contexto. Posteriormente, sero apresentadas as formas normais e um exemplo de aplicao. Logo aps, abordaremos o tpico sobre desnormalizao e por ltimo, faremos as consideraes finais relacionadas ao artigo. de forma que o valor de um atributo identifique o valor para cada um dos outros atributos, ou seja, um atributo est relacionado a outro. Por exemplo: AB Nesse exemplo, o atributo B dependente (funcionalmente) do atributo A. Em outras palavras, para descobrirmos o valor de B, precisamos saber o valor de A (observe que a recproca NO verdadeira). Veja mais um exemplo: Cdigo do cliente Nome do cliente Nesse exemplo, para descobrirmos o nome do cliente (dentro de um conjunto de clientes), primeiramente precisamos saber qual o cdigo dele. Assim, o campo/atributo nome dependente do campo/atributo cdigo. Observe que a recproca NO verdadeira! Voc poderia pensar: Ora, eu posso conhecer o nome do cliente, e no o seu cdigo. Nem sempre eu vou precisar saber o cdigo do cliente para obter o nome dele. Esse pensamento incorreto, pois voc pode ter clientes com o mesmo nome. Outro detalhe importante que em uma tabela podemos ter mais de uma dependncia funcional. Por exemplo: Cdigo do cliente Nome do cliente Cdigo do cliente UF do cliente Essa mesma afirmao pode ser descrita da seguinte forma: Cdigo do Cliente [Nome do Cliente, UF do cliente] Vamos ver agora um exemplo mais completo. Vamos supor uma tabela contendo cdigo do cliente, nome do cliente, tipo de logradouro, logradouro, nmero, complemento, bairro, cidade e UF. Nesta tabela, para cada cdigo de cliente teremos um s valor para nome do cliente, tipo de logradouro, logradouro, nmero, complemento, bairro, cidade e UF. Por isto, dizemos que os atributos nome do cliente, tipo de logradouro, logradouro, nmero, complemento, bairro, cidade e UF esto funcionalmente dependentes do cdigo do cliente. Perceba que neste caro estamos considerando que ser armazenado apenas o endereo residencial da pessoa (caso contrrio, a dependncia funcional deixaria de existir). Esta dependncia funcional pode ser escrita da seguinte forma: Cdigo nome, tipo_logradouro, logradouro, nro, compl, bairro, cidade, UF Com isso, podemos perceber que o valor de um atributo determina o valor de outro atributo. Provavelmente voc j tenha se deparado com a forma mais comum de dependncia funcional, que gerada pela chave primria. Obviamente o valor da chave primria determina o valor dos outros atributos do mesmo registro. Conceito 2: Dependncia Funcional Parcial Uma dependncia funcional parcial ocorre quando os atributos no chave no dependam funcionalmente de toda a chave primria quando esta for composta. Assim, nas tabelas onde a chave primria for composta, todos os atributos devem depender de toda a chave primria. Caso a dependncia seja de parte da chave, verificamos a existncia de dependncia funcional parcial. Por exemplo: AB C, D Considere que o atributo C dependa funcionalmente de A, mas no dependa de B. J temos um exemplo de dependncia funcional parcial. Vamos ver agora um exemplo mais completo. Suponha uma tabela notas (matricula_aluno, CodDisciplina, Periodo, NomeDisciplina, Nota) (ver Tabela 1). Suponha que a chave primria desta tabela seja matricula_aluno, Periodo e CodDisciplina. Nesta tabela, verificamos que o atributo NomeDisciplina depende apenas do CodDisciplina e no depende da matrcula do aluno junto com seu perodo. Assim, existe uma dependncia funcional parcial. Isso pode trazer problemas para o modelo como redundncia de informaes. Imagine que o aluno de matricula 123 tenha perdido a disciplina Engenharia de Requisitos no primeiro perodo e tenha que repeti-la no

Conceitos importantes
Neste tpico iremos abordar alguns conceitos necessrios para melhor compreenso de todo o artigo. Fiquem vontade em retornar a este tpico sempre que alguma dvida surgir, ou caso prefiram, podem saltar a leitura deste tpico e recorrer a ele no decorrer dos prximos tpicos. Sempre que surgir um conceito que tiver sido definido neste tpico, faremos referncia a ele para que retomem a leitura a fim de revisar ou simplesmente para efetuar a leitura do conceito necessrio. Conceito 1: Dependncia Funcional Uma dependncia funcional um relacionamento entre dois ou mais atributos

Edio 47 - SQL Magazine

23

segundo. Perceba na Tabela 1 que neste caso teramos o valor do campo NomeDisciplina replicado. Esta certamente no uma boa prtica de projeto. A soluo neste caso seria criarmos outra tabela contendo apenas os dados da disciplina (veremos esta soluo detalhadamente mais adiante quando falaremos sobre as formas normais). Conceito 3: Dependncia Funcional Transitiva Na definio dos campos de uma entidade podem ocorrer casos em que um campo no seja dependente diretamente da chave primria ou de parte dela, mas sim dependente de outro campo da tabela, campo este que no a Chave Primria. Quando isto ocorre, dizemos que a tabela possui dependncia funcional transitiva.
Matricula_Aluno 123 123 123 123 Periodo 1 1 1 2 CodDisciplina 8 9 5 8

importante deixar claro a diferena entre dependncia funcional parcial e a transitiva. Na parcial, pelo menos um atributo da tabela depende de parte da chave primria (e no dela toda); na transitiva, pelo menos um atributo da tabela depende de outro atributo que no seja chave primria. Para definir melhor o conceito de dependncia funcional transitiva, trabalharemos por meio de um exemplo. Vamos supor a existncia de uma tabela funcionrio contendo a matrcula do funcionrio (chave primria), nome do funcionrio, cdigo do cargo, nome do cargo e salrio do cargo, conforme Tabela 2. Perceba que a matrcula do funcionrio determina apenas os atributos nome do funcionrio e cdigo do cargo. EntretanNomeDisciplina Engenharia de Requisitos Qualidade de Software Engenharia de Software Engenharia de Requisitos Nota 4,0 10,0 7,0 9,0

to, o cdigo do cargo (que no chave primria) determina o nome do cargo e o salrio do cargo e estes dois ltimos atributos no dependem diretamente do atributo matrcula. Matricula NomeFuncionario, CodCargo CodCargo NomeCargo, SalarioCargo Assim, temos uma dependncia funcional transitiva. Perceba no exemplo da Tabela 2 que quando este tipo de dependncia est presente, temos informaes redundantes na tabela (o funcionrio Rodrigo tambm professor e possui os campos NomeCargo e SalarioCargo repetidos em relao ao funcionrio Ary) e sabemos que este tipo de situao uma das causas para a perda de integridade em projetos de banco de dados. Analisando esta situao, fica bastante claro que sabendo o valor do atributo CodCargo, saberamos automaticamente o valor dos atributos NomeCargo, SalarioCargo e isso poderia estar armazenado em outra tabela para evitar problemas de redundncia. Conceito 4: Atributos Multivalorados Atributos multivalorados so atributos que podem conter mais de um valor para um mesmo registro. Na Tabela 3 apresentamos uma tabela pessoa (Codigo, Nome, Telefone). Perceba o atributo telefone para os dois primeiros registros apresentados. Existe mais de um telefone para cada pessoa. Desta forma, o atributo Telefone multivalorado. Conceito 5: Atributos Compostos Atributos compostos so atributos que podem ser subdivididos em vrios atributos. Na Tabela 4 apresentamos a tabela Pessoa (Codigo, Nome, Endereco). Nesta tabela, o atributo endereo multivalorado, uma vez que ele pode ser dividido em vrios atributos. Na Tabela 5 apresentamos a tabela pessoa (Codigo, Nome, TipoLogradouro, Logradouro, Nro, Comp, Bairro, Cidade, UF). Esta tabela a mesma tabela da Tabela 4, porm com o atributo endereo sendo dividido em: Tipo de Logradouro, Logradouro, Nmero, Complemento, Bairro, Cidade e Estado(UF).

Tabela 1. Tabela contendo dependncia funcional parcial. Matricula 1 2 3 4 5 NomeFuncionario Ary Tatiana Ana Luis Rodrigo CodCargo 1 2 3 4 1 NomeCargo Professor Advogado Secretria Analista de Sistemas Professor SalarioCargo R$ 7.500,00 R$ 6.900,00 R$ 1.550,00 R$ 8.000,00 R$ 7.500,00

Tabela 2. Tabela Funcionrio Codigo 1 Nome Ary Telefone (34) 3821-0000 (34) 9979-0000 (34) 9964-0000 (34) 3822-0000 (34) 9976-0000 (11) 3184-0000 (31) 3257-0000

2 3 4

Tatiana Ana Joo

Tabela 3. Tabela Pessoa Com Atributos Multivalorados. Codigo 1 2 3 4 Nome Ary Tatiana Ana Joo Endereco Av. Getlio Vargas, 1000, apto 201 Centro Patos de Minas-MG Av. Brasil, 966 Centro Belo Horizonte-MG Rua Minas Gerais, 100 Bairro Brasil Recife-PE Praa da Liberdade, 27 Bairro Esperana So Paulo-SP

Tabela 4. Tabela Pessoa com Atributo Composto

24

SQL Magazine - Normalizao de Dados

NOR MA L I Z A O
Desta forma, verificamos que realmente o atributo endereo, da maneira que ele estava sendo apresentado na Tabela 4, um atributo multivalorado na referida tabela. Conceito 6: Atributos Atmicos Atributos atmicos so atributos que no podem ser subdivididos e tambm no so multivalorados. Assim, um atributo atmico indivisvel. Por exemplo, podemos citar, CPF, CNPJ, Preco_Unitario como sendo atributos atmicos em quaisquer tabelas, uma vez que nenhum deles pode ser subdividido. Conceito 7: Dependncia Funcional Multivalorada Uma dependncia funcional multivalorada ocorre quando, para cada valor de um atributo A, h um conjunto de valores para outros atributos B e C que esto associados a ele. importante ressaltar que B e C esto vinculados a A, porm so independentes entre si. Por exemplo, vamos supor uma tabela filmes, de acordo com a Tabela 6. Para cada filme, h um conjunto finito de atores associados ao filme e tambm h um conjunto finito de produtores associados a este filme. Entretanto, atores e produtores so independentes um do outro. Neste caso, as dependncias multivaloradas podem ser escritas como: Filme Ator Filme Produtor O problema deste tipo de depndencia que ela pode trazer um nvel muito alto de redundncia. Perceba que a Tabela 6 possui atributos multivalorados, o que muitas vezes no se configura um estado desejvel para armazenamento e busca de informaes no banco. Caso tratssemos cada atributo de forma que possuissem apenas um valor, teramos uma tabela semelhante da Tabela 7. Perceba que a quantidade de repetio de dados enorme, podendo trazer srios problemas para manuteno da consistncia e integridade das informaes. Repare tambm que para que a dependncia funcional multivalorada ocorra, necessrio no apenas um atributo multivalorado, mas no mnimo dois. No exemplo da Tabela 7, verificamos que para cada registro do atributo Filme (A), possuimos um conjunto finito de valores para o atributo Ator (B) e tambm um conjunto finito de valores para o atributo Produtor (C). Perceba que Ator e Produtor no tm relao. Desta forma, a no existncia de um dos dois atributos (Ator ou Produtor) implicaramos em no termos uma dependncia funcional multivalorada. Teramos apenas um atributo multivalorado. Conceito 8: Dependncia Funcional Cclica Uma dependncia funcional cclica acontece quando temos dependncias como: A B, B C, C A. Por exemplo: em uma instituio de ensino, um professor ministra disciplinas,
Codigo 1 2 3 4 Nome Ary Tatiana Ana Joo Tipo Logradouro Avenida Avenida Rua Praa Logradouro Getlio Vargas Brasil Minas Gerais Liberdade

conforme Tabela 8. Logo, professor disciplinas. Entretanto, um professor tambm escreve apostila, conforme Tabela 9. Assim, teremos: Professor Apostila. Alm disso, cada disciplina pode ter vrias apostilas, conforme pode ser visualizado na Tabela 10. Logo: disciplina apostilas. Desta forma, temos a relao cclica: professor disciplinas, disciplinas apostilas e professores apostilas. Conceito 9: Super Chave Uma Superchave qualquer conjunto de atributos contendo uma chave, seja ela primria ou candidata.
Nro 1000 966 100 27 Comp Apto 201 Bairro Centro Centro Brasil Esperana Cidade Patos de Minas Belo Horizonte Recife So Paulo

UF
MG MG PE SP

Tabela 5. Tabela Pessoa sem Atributo Composto Filme Uma Linda Mulher Ator Julia Richard Mel Linda Tony Gloria Produtor Jos Jack Mario Joo Joaquim Luciano Maria Professor Ary Jos Disciplina Banco de Dados 1 Banco de Dados 2 Engenharia de Software Anlise e Projeto de Sistemas

Corao Valente

Tabela 8. Tabela Professor Professor Ary Jos Joaquim Mario Jos Apostila Tutorial Banco de Dados

Se eu fosse Voc

Tabela 6. Tabela Filmes Filme Uma Linda Mulher Uma Linda Mulher Uma Linda Mulher Uma Linda Mulher Uma Linda Mulher Uma Linda Mulher Corao Valente Corao Valente Se Eu Fosse Voc Se Eu Fosse Voc Se Eu Fosse Voc Se Eu Fosse Voc Se Eu Fosse Voc Se Eu Fosse Voc Ator Julia Julia Julia Richard Richard Richard Mel Linda Tony Tony Tony Glria Glria Glria Produtor Jos Jack Mario Jos Jack Mario Joo Joo Joaquim Luciano Maria Joaquim Luciano Maria

Tutorial Engenharia de Software

Tabela 9. Tabela ProfessorApostila Disciplina Banco de Dados 1 Banco de Dados 2 Engenharia de Software Apostila Tutorial Banco de Dados Tutorial Engenharia de Software Tutorial Anlise e Projeto de Sistemas

Tabela 10. Tabela DisciplinaApostila.

Tabela 7. Tabela Contendo Dependncia Funcional Multivalorada

Edio 47 - SQL Magazine

25

Conceito 10: Chave Candidata Atributo ou grupo de atributos que tm a propriedade de identificar unicamente um registro. Pode vir a ser uma chave Primria. A chave candidata que no chave primria tambm se chama chave alternativa. Por exemplo, digamos que em uma tabela temos os campos: cdigo, nome e CPF. Tanto cdigo quanto CPF so chaves candidatas, pois permitem identificar o registro. Se o projetista escolher o cdigo como chave primria, o CPF ser a chave alternativa (e vice-versa). Conceito 11: Chave Primria Chave primria uma chave candidata, escolhida pelo projetista do banco de dados como significado principal para
Codigo 1 Nome Ary Telefone (34) 3821-0000 (34) 9979-0000 (34) 9964-0000 (34) 3822-0000 (34) 9976-0000 (11) 3184-0000 (31) 3257-0000

a identificao de registros dentro de uma tabela.

Primeira Forma Normal (1FN)

Uma tabela se encontra na 1FN se todos os atributos possurem apenas valores atmicos (simples e indivisveis) e os valores de cada atributo no registro tambm deve ser um valor simples (ou seja, o atributo no composto). Desta forma, caso existam atributos compostos, estes devem ser divididos em atributos atmicos. Caso existam atributos multivalorados, estes devem fazer parte de outra tabela, que estar relacionada com a tabela original. Para exemplificar, seja a tabela Pessoa (Codigo, Nome, Telefone, Endereco), con-

forme apresentado na Tabela 11. Perceba que a referida tabela no est na 1FN, pois possui um atributo multivalorado (Telefone) e um atributo composto (Endereco). Este atributo pode ser dividido em vrios atributos atmicos, como: Tipo de Logradouro, Logradouro, Nmero, Complemento, Bairro, Cidade, Estado. Assim, poderamos ter duas novas tabelas: Pessoa (Codigo, Nome, Tipo_logradouro, Logradouro, Numero, Complemento, Bairro, Cidade, Estado) apresentada na Tabela 12 e Telefone (Codigo_tel, Nrotel, Codigo) apresentada na Tabela 13, onde cdigo chave estrangeira referenciando cliente. Desta forma, estas duas tabelas esto atendendo 1FN.

Endereco
Av. Getlio Vargas, 1000, apto 201 Centro Patos de Minas-MG

Segunda Forma Normal (2FN)

Uma tabela se encontra na 2FN se estiver na 1FN e no possuir dependncia funcional parcial (Conceito 2). Caso existam atributos que no dependam integralmente da chave primria, devemos retirar da tabela todos eles e dar origem a uma nova tabela. Pa ra exempl i f ic a r, s e ja a t ab ela vendas(Nro, Codp, Nomep, Vunit, Qdade, Vtot), de acordo com a Tabela 14, onde os atributos correspondem a: Nro: nmero da venda; Codp: cdigo do produto; Nomep: nome do produto; Vunit: valor unitrio do produto; Qdade: quantidade vendida do produto; Vtot: valor total da venda. Suponha tambm que a chave primria desta tabela seja os atributos Nro e Codp. Logo, trata-se de uma chave primria composta. Assim, iremos verificar se esta tabela encontra-se na 2FN. O primeiro passo verificar se a tabela vendas encontra-se na 1FN. Podemos verificar que no existem atributos compostos ou multivalorados nesta tabela. Logo, a 1FN verificada nesta tabela. Posteriormente, precisamos verificar se existe dependncia parcial de chave. Note que na tabela vendas, existe a dependncia funcional parcial (Conceito 2): Codp NomeP, Vunit, ou seja, Nome do Produto e Valor Unitrio so determinados pelo Cdigo do Produto. Desta forma,

2 3
4

Tatiana Ana Luis

Av. Brasil, 966 Centro Belo Horizonte-MG Rua Minas Gerais, 100 Bairro Brasil Recife-PE Praa da Liberdade, 27 Bairro Esperana So Paulo-SP

Tabela 11. Tabela Pessoa sem atender a 1FN Codigo 1 2 3 4 Nome Ary Tatiana Ana Luis Tipo Logradouro Avenida Avenida Rua Praa Logradouro Getlio Vargas Brasil Minas Gerais Liberdade Nro 1000 966 100 27 Comp Apto 201 Bairro Centro Centro Brasil Esperana Cidade Patos de Minas Belo Horizonte Recife So Paulo

UF
MG MG PE SP

Tabela 12. Tabela Pessoa sem Atributo Composto Codigo_tel 1 2 3 4 5 6 7 Nrotel (34) 3821-0000 (34) 9979-0000 (34) 9964-0000 (34) 3822-0000 (34) 9976-0000 (11) 3184-0000 (31) 3257-0000 Codigo 1 1 1 2 2 3 4

Tabela 13. Tabela Pessoa Com Atributos Multivalorados. Nro 1 2 3 3 Codp 1 2 1 2 Nomep Sabo em p Sabonete Sabo em p Sabonete Vunit R$ 5,50 R$ 1,10 R$ 5,50 R$ 1,10 Qdade 2 5 3 2

Vtot
R$ 11,00 R$ 5,50 R$ 16,50 R$ 2,20

Tabela 14. Tabela Vendas.

26

SQL Magazine - Normalizao de Dados

NOR MA L I Z A O
existem atributos que no dependem integralmente da chave primria, ento, a tabela vendas no est na 2FN. Para que possamos adequar a tabela 2FN, devemos separar a tabela vendas em duas tabelas: vendas e produtos. Os atributos da dependncia parcial devem fazer parte da tabela Produtos. Efetuando esta separao, teremos as tabelas produtos (Codp, NomeP, Vunit), conforme Tabela 15, e vendas (Nro, Codp, Qdade, Vtot), conforme Tabela 16. Desta forma, com estas duas novas tabelas, verificamos a adequao 2FN. Percebemos que para verificar a adequao 2FN, podemos seguir alguns passos: 1) Se existirem apenas atributos atmicos, as tabelas encontram-se na 1FN; 2) Caso no existam chaves primrias compostas, no h como existir dependncia funcional parcial (Conceito 2), e as tabelas encontram-se na 2FN; 3) Caso existam chaves primrias compostas, deve-se verificar a dependncia funcional parcial (Conceito 2).

Nota 1 importante fazer uma observao sobre o exemplo da 2FN: estamos considerando que o valor unitrio da venda no pode ser alterado pelo vendedor no momento da venda. Caso isso pudesse ocorrer, teramos que obrigatoriamente armazenar o valor unitrio na tabela de vendas (pois cada venda poderia ter seu prprio valor unitrio para os produtos). Nesse caso, o atributo valor unitrio dependeria funcionalmente da chave Nro (nmero da venda) e a dependncia funcional parcial para o atributo Vunit deixaria de existir. Observe tambm que nesse caso teramos dois atributos valor unitrio: um na tabela Codp 1 2
Tabela Produtos [Nota 1]

de Produtos e outro na tabela de Vendas cada um com um significado diferente. Ou seja, a dependncia funcional de um atributo depende do seu papel dentro do sistema, e no do seu nome. Veja as tabelas Produtos e Vendas. Observe que o preo padro do produto Sabo em p R$ 5,50, mas ele foi vendido por R$ 5,00 na venda de nro 1. Neste exemplo, o campo VUnit da tabela Produtos tem o objetivo de armazenar o preo padro. O campo VUnit da tabela Vendas tem o objetivo de armazenar o preo final. Na hora de normalizar, fique atento ao real significado do campo, e no somente ao seu nome. Nro 1 2 Codp 1 2 Qdade 2 5 Vunit R$ 5,00 R$ 1,10 Vtot R$ 10,0 R$ 5,50

NomeP Sabo em p Sabonete

Vunit R$ 5,50 R$ 1,10

Tabela Vendas [Nota 1]

Terceira Forma Normal (3FN)

Uma tabela est na 3FN se estiver na 2FN e no possuir nenhuma dependncia funcional transitiva (Conceito 3). Para exemplificar, vamos verificar a tabela funcionario (Matricula, Nome, CodCargo, CNome, SalarioCargo), de acordo com a Tabela 2, onde os atributos correspondem a: Matricula: nmero de matrcula do funcionrio; Nome: nome do funcionrio; CodCargo: Cdigo do Cargo do Funcionrio; CNome: Nome do cargo; SalarioCargo: salrio do cargo. Nesta tabela, a chave primria o nmero de matrcula do funcionrio (atributo matricula). O primeiro passo para verificar se esta tabela encontra-se na 3FN verificar se ela est na 2FN. Podemos perceber que a tabela funcionrio encontra-se na 2FN porque existem apenas atributos atmicos e no existe dependncia funcional parcial, uma vez que a chave primria da tabela no composta. Aps verificar que a tabela encontra-se na 2FN, vamos verificar a existncia de

dependncia funcional transitiva (Conceito 3) em tabela chave primria. Neste momento, verificamos que nesta tabela existe a seguinte dependncia: CodCargo Cnome, SalarioCargo. Perceba que CodCargo no chave primria e os atributos Cnome e SalarioCargo esto dependendo dele (ler Nota 2). Logo, a tabela funcionrios no se encontra na 3FN. Nota 2. Observao sobre o campo SalarioCargo Veja que aqui temos a mesma situao da Nota 1. Estamos considerando para este exemplo que o valor do salrio por cargo fixo (todos os funcionrios com o mesmo cargo tero exatamente o mesmo salrio). Caso no fosse, o campo SalarioCargo no faria parte da dependncia e estaria dependente da matrcula do funcionrio. Voltando ao nosso cenrio, para resolver a dependncia funcional transitiva (Conceito 3), precisamos separar a tabela em duas ou mais tabelas de forma a eliminar tal dependncia. Neste caso, podemos dividir a tabela funcionrio em duas tabelas: funcionrio e cargo, da seguinte forma: Funcionrio (Matricula, Nome, CodCargo), conforme Tabela 17. Cargo (CodCargo, CNome, SalarioCargo), conforme Tabela 18. Verificamos que na nova tabela funcio-

Codp 1 2

NomeP Sabo em p Sabonete

Vunit R$ 5,50 R$ 1,10

Tabela 15. Tabela Produtos Nro 1 2 Codp 1 2 Qdade 2 5 Vtot R$ 11,0 R$ 5,50

Tabela 16. Tabela Vendas Matricula 1 2 3 4 NomeFuncionario Ary Tatiana Ana Joo CodCargo 1 2 3 4

Tabela 17. Tabela Funcionrio CodCargo 1 2 3 4 NomeCargo Professor Advogado Secretria Analista de Sistemas SalarioCargo R$ 7.500,00 R$ 6.900,00 R$ 1.550,00 R$ 8.000,00

Tabela 18. Tabela Cargo Aluno Mrcio Joo Disciplina Banco de Dados Matemtica 1 Professor Ary Bruno

Tabela 19. Tabela Cursa

Edio 47 - SQL Magazine

27

nrio (ver Tabela 17) o atributo CodCargo uma chave estrangeira referenciando a tabela Cargo. Por fim, verificamos que as tabelas funcionrio e cargo esto na 3FN porque esto na 2FN e no existe dependncia funcional transitiva (Conceito 3).

Forma Normal de Boyce-Codd (BCNF)

No processo de normalizao, esta forma normal pode (ler Nota 3) ser aplicada s tabelas em 3FN sendo que uma relao est na FNBC se para toda dependncia funcional X Z, X uma super-chave (Conceito 9). Nota 3. BCNF pode substituir outras formas normais. Ao contrrio das formas normais que vimos at aqui, a BCNF no exige que a tabela j esteja na forma normal anterior (3FN) para que seja aplicada. Ou seja, podemos ir direto de uma tabela no normalizada para a BCNF. Ela serve de atalho para atingirmos as formas normais 1FN, 2FN e 3FN.

Para exemplificar, vamos verificar a tabela cursa (Aluno, Disciplina, Professor), de acordo com a Tabela 19. Esta tabela est na 3FN porque est na 2FN e no apresenta dependncia funcional transitiva (Conceito 3). Vamos agora se existe dependncia funcional. Podemos verificar a seguinte dependncia: Disciplina Professor. E neste caso, disciplina uma super chave (Conceito 9). Esta dependncia acontece porque para cada disciplina existe professor. Logo, os professores dependem da disciplina. Para resolver esta dependncia, precisamos separar a tabela cursa em duas tabelas, Tutoria e Cursa, da seguinte forma: Tutoria(Professor, Disciplina), de acordo com a Tabela 20. Cursa(Aluno,Disciplina), de acordo com a Tabela 21. Verificamos que na nova tabela Tutoria (Tabela 20) o atributo Disciplina uma chave estrangeira referenciando a tabela

Cursa (Tabela 21). Por fim, verificamos que as tabelas Tutoria e Cursa esto na BCNF.

Quarta Forma Normal (4FN)

Uma tabela est na 4FN, se e somente se, estiver na BCNF e no existirem dependncias funcionais multivaloradas (Conceito 7) (ler novamente Nota 3).

CodLivro 1 2 3

Ttulo Introduo a Bancos de Dados Introduo a Sistemas de Bancos de Dados Introduo ao Teste de Software

Ano 2007 2003 2007

Tabela 23. Tabela Livro CodAssunto 1 2 3 4 5 Assunto Bancos de Dados Teste Funcional Teste de carga Teste de aceitao Teste de regresso

Disciplina Banco de Dados Matemtica 1 Tabela 20. Tabela Tutoria Aluno Mrcio Joo Tabela 21. Tabela Cursa CodLivro 1 2 2 3 3 3 3 3 3 3 3 3 3 3 3 Autor Ary Korth Silberschatz Mario Jino Mario Jino Mario Jino Mario Jino Mrcio Eduardo Delamaro Mrcio Eduardo Delamaro Mrcio Eduardo Delamaro Mrcio Eduardo Delamaro Jos Carlos Maldonado Jos Carlos Maldonado Jos Carlos Maldonado Jos Carlos Maldonado

Tutor Ary Bruno

Tabela 24. Tabela Assunto CodAutor 1 2 Nome Ary Korth Silberschatz Mario Jino Jos Carlos Maldonado Mrcio Eduardo Delamaro

Disciplina Banco de Dados Matemtica 1

3 4 5 6

Tabela 25. Tabela Autor Ttulo Introduo a Bancos de Dados Introduo a Sistemas de Bancos de Dados Introduo a Sistemas de Bancos de Dados Introduo ao Teste de Software Introduo ao Teste de Software Introduo ao Teste de Software Introduo ao Teste de Software Introduo ao Teste de Software Introduo ao Teste de Software Introduo ao Teste de Software Introduo ao Teste de Software Introduo ao Teste de Software Introduo ao Teste de Software Introduo ao Teste de Software Introduo ao Teste de Software Assunto Bancos de Dados Bancos de Dados Bancos de Dados Teste Funcional Teste de carga Teste de aceitao Teste de regresso Teste Funcional Teste de carga Teste de aceitao Teste de regresso Teste Funcional Teste de carga Teste de aceitao Teste de regresso Ano 2007 2003 2003 2007 2007 2007 2007 2007 2007 2007 2007 2007 2007 2007 2007 CodAutor 1 2 3 4 5 6 Tabela 26. Tabela AutorLivro CodAssunto 1 1 2 3 4 5 Tabela 27. Tabela LivroAssunto CodLivro 1 2 3 3 3 3 CodLivro 1 2 2 3 3 3

Tabela 22. Tabela Livros

28

SQL Magazine - Normalizao de Dados

NOR MA L I Z A O

Professor Ary Jos Rodrigo

Disciplina Banco de Dados 1 Engenharia de Software Engenharia de Requisitos

Apostila Tutorial Banco de Dados Tutorial Engenharia de Software Introduo a Engenharia de Requisitos

Professor Ary Jos Rodrigo

Disciplina Banco de Dados 1 Engenharia de Software Engenharia de Requisitos

Tabela 28. Tabela a ser normalizada na 5FN Disciplina Banco de Dados 1 Engenharia de Software Engenharia de Requisitos Tabela 30. Tabela Disciplina_Apostila Apostila Tutorial Banco de Dados Tutorial Engenharia de Software Introduo Engenharia de Requisitos

Tabela 29. Tabela Professor_Disciplina Apostila Tutorial Banco de Dados Tutorial Engenharia de Software Introduo Engenharia de Requisitos Tabela 31. Tabela Apostila_Professor Professor Ary Jos Rodrigo

Por exemplo, vamos supor uma tabela livros, contendo CodLivro, Autor, Titulo, Assunto, Ano (ver Tabela 22). Podemos verificar que nesta tabela existe dependncia funcional multivalorada (Conceito 7) em relao ao Autor e ao Assunto (um livro pode ter vrios autores e apresentar diferentes assuntos e, junto a isso, autores e assuntos no possuem vnculo entre si). Assim, para que esta tabela esteja na 4FN devemos separ-la nas seguintes tabelas: Livro(CodLivro, Titulo, Ano_publicacao), conforme Tabela 23. Esta nova tabela livros foi obtida retirando os atributos multivalorados. Assunto(CodAssunto, Assunto), conforme Tabela 24. Esta tabela assunto foi obtida a partir do atributo multivalorado Assunto da tabela livro (Tabela 22). Autor(CodAutor,Nome), conforme Tabela 25. Esta tabela autor foi obtida a partir do atributo multivalorado Autor da tabela livro anterior (Tabela 22). AutorLivro(CodAutor,CodLivro), conforme Tabela 26. Esta tabela foi obtida pois, aps retirar o atributo multivalorado autor da tabela livro (Tabela 22), criamos uma tabela autor (Tabela 25) que ser responsvel por cadastrar todos os autores. Porm, verificamos que os livros podem possuir mais de um autor. Logo, trata-se de um relacionamento n:n. Assim, para resolvermos este relacionamento precisamos de uma nova tabela que seria a AutorLivro (Tabela 26). LivroAssunto(CodLivro,CodAssun to), conforme Tabela 27. Esta tabela foi obtida pois, aps retirar o atributo multivalorado assunto da tabela livro (Tabela 22), criamos uma tabela Assunto (Tabela 24) que ser responsvel por cadastrar

todos os assuntos de livros existentes. Porm, verificamos que os livros podem possuir mais de um assunto. Logo, tratase de um relacionamento n:n. Assim, para resolvermos este relacionamento precisamos de uma nova tabela que seria a LivroAssunto (Tabela 27). Note que as tabelas AutorLivro (Tabela 26) e LivroAssunto (Tabela 27) possuem chaves estrangeiras, que so: Tabela AutorLivro o CodAutor: Referenciando tabela Autor (Tabela 25) o CodLivro: Referenciando tabela Livro (Tabela 23) Tabela LivroAssunto o CodLivro: Referenciando tabela Livro (Tabela 22) o CodAssunto: Referenciando tabela Assunto (Tabela 24) Desta forma, as dependncias funcionais multivaloradas (Conceito 7) deixam de existir nestas tabelas. Portanto, as tabelas encontram-se na 4FN.

Para resolver esta dependncia funcional cclica, podemos separar as Tabelas 29, 30 e 31. Desta forma, verificamos que a dependncia funcional cclica foi extinta. Logo, as tabelas encontram-se na 5FN.

Exemplo prtico
Suponha que inicialmente tenhamos uma nica tabela para armazenar as notas fiscais (Figura 1) com os seguintes atributos: NroNF: Nmero da Nota Fiscal Chave primria; Serie: Srie da Nota Fiscal; DataEmissao: Data de Emisso da Nota Fiscal; CodCli: Cdigo do Cliente; NomeCli: Nome do cliente; CNPJCli: CNPJ do cliente; MercadoriasVendidas: Mercadorias Vendidas na Nota Fiscal; TotalNota: Valor Total Vendido na Nota Fiscal. Assim, o esquema desta tabela seria: NotaFiscal(NroNF, Serie, DataEmissao, CodCli, NomeCli. CNPJCli, MercadoriasVendidas, TotalNota) (ver Figura 1 e Tabela 32).

Quinta Forma Normal (5FN) ou Forma Normal de Projeo de Juno (FNPJ)

Uma tabela est na quinta forma normal se no existir dependncia funcional cclica (Conceito 8). Para resolver este problema da dependncia cclica, conforme exemplo do Conceito 8, devemos separar o ciclo, envolvendo relacionamentos com cardinalidade n: n. Por exemplo, vamos supor inicialmente a tabela apresentada na Tabela 28. Nesta tabela identificamos a seguinte dependncia funcional cclica: Professor disciplinas, disciplinas apostilas e apostilas professores.

Figura 1. Tabela NotaFiscal Desnormalizada

Edio 47 - SQL Magazine

29

Veja que o atributo Mercadorias Vendidas composto (Conceito 5) e multivalorado (Conceito 4), portanto, deve ser dividido em atributos atmicos, conforme a 1FN. Veja que o atributo MercadoriasVendidas possui um nmero, uma descrio, uma quantidade e um valor. Desta forma, para cada mercadoria vendida, poderamos ter: CodM: Cdigo da Mercadoria; Descricao: Descrio da Mercadoria; Qdade: Quantidade Vendida; Preco: Preo de Venda; TotalVenda: Total Vendido da Mercadoria.

Dessa forma, poderamos ter as seguintes tabelas resultantes (Figura 2, Tabela 33, Tabela 34): NotaFiscal (NroNF, Serie, DataEmisso, CodCli, NomeCli, CNPJCli, TotalNota); Vendas(NotaFiscal_NroNF, CodM, Descricao, Qdade, Preco, TotalVenda). Repare que os novos atributos que esto na tabela Vendas so resultantes do atributo composto MercadoriasVendidas da Figura 1 e Tabela 32. Observe que na tabela NotaFiscal, a chave primria NroNF e na tabela vendas NotaFiscal_NroNF e CodM (Figura 2).

NroNF 1 2 3

Serie D D D

DataEmissao 18/09/2007 19/09/2007 20/09/2007

CodCli 1 2 1

NomeCli Ary Tatiana Ary

CNPJCli 123456 654321 123456

MercadoriasVendidas 1, Sabo em P,1, 5.40; 2, Sabonete, 1, 2.00; 3, Saboneteira, 1, 2.00; 4, Creme,1,32.50 2, Sabonete,1,2.00

TotalNota R$ 9,40 R$ 32,50 R$ 2,00

Tabela 32. Tabela NotaFiscal NroNF 1 2 3 Serie D D D DataEmissao 18/09/2007 19/09/2007 20/09/2007 CodCli 1 2 1 NomeCli Ary Tatiana Ary CNPJCli 123456 654321 123456 TotalNota R$ 9,40 R$ 32,50 R$ 2,00

Tabela 33. Tabela NotaFiscal NotaFiscal_NroNF 1 1 1 2 3 CodM 1 2 3 4 2 Descricao Sabo em P Sabonete Saboneteira Creme Sabonete Qdade 1 1 1 1 1 Preco 5,40 2,00 2,00 32,50 2,00 TotalVenda 5,40 2,00 2,00 32,50 2,00

Tabela 34. Tabela Vendas NroNF 1 2 3 Serie D D D DataEmissao 18/09/2007 19/09/2007 20/09/2007 CodCli 1 2 1 NomeCli Ary Tatiana Ary CNPJCli 123456 654321 123456 TotalNota R$ 9,40 R$ 32,50 R$ 2,00

O resultado da primeira tabela obtido atravs da diviso do atributo composto em atributo atmico em outra tabela. Esta nova tabela tem como chave primria a chave primria da tabela original. Assim, como no existem mais atributos multivalorados, estas duas tabelas encontramse na 1FN. O prximo passo verificar se as tabelas esto na 2FN. Analisando as duas tabelas, verificamos que necessrio retirar da tabela vendas todos os atributos que no dependam funcionalmente de toda a chave primria, pois apenas nesta tabela existe a chave primria composta, conforme definio da 2FN. Para resolver a 2FN na tabela Vendas (Tabela 34), verificamos que os atributos Descricao e Preco no dependem de toda a chave primria. Estes dois atributos no dependem do nmero da nota fiscal. Eles so dependentes apenas do cdigo da mercadoria, ou seja, apenas o cdigo da mercadoria identifica o valor destes dois atributos. Sabemos que estes atributos so relativos s Mercadorias. Assim, poderemos criar uma tabela Mercadorias para absorver estes dois atributos. Entretanto, devemos salientar novamente informaes sobre atributos relativos a preo. No caso da nova tabela Mercadorias, o preo apresentado o preo unitrio do produto. Repare que no possvel a identificao de histrico de preos, por exemplo. Desta forma, temos as seguintes tabelas resultantes (Figura 3, Tabela 35, Tabela 36, Tabela 37): NotaFiscal (NroNF, Serie, DataEmisso, CodCli, NomeCli, CNPJCli, TotalNota); Vendas(NotaFiscal_NroNF, Mercadorias_CodM, Qdade, TotalVenda);

CodM 1 2 3

Descricao Sabo em P Sabonete Saboneteira Creme

Preco 5,40 2,00 2,00 32,50

Tabela 35. Tabela NotaFiscal NotaFiscal_NroNF 1 1 1 2 3 Tabela 36. Tabela Vendas Mercadorias_CodM 1 2 3 4 2 Qdade 1 1 1 1 1 TotalVenda 5,40 2,00 2,00 32,50 2,00

Tabela 37. Tabela Mercadorias CodCli 1 2 NomeCli Ary Tatiana CNPJCli 123456 654321

Tabela 38. Tabela Clientes

30

SQL Magazine - Normalizao de Dados

NOR MA L I Z A O
Mercadorias (CodM, Descricao, Preco). Note que foram retirados os atributos descrio e preo, pois estes dependem apenas do cdigo da mercadoria (Figura 3, Tabela 36 e Tabela 37). O prximo passo verificar se estas trs tabelas esto na 3FN. Perceba que na tabela NotaFiscal, os atributos NomeCli, CNPJCli dependem de CodCli que no chave primria. As outras tabelas esto na 3FN uma vez que no possuem atributos que no dependem de outros atributos que no sejam chave. Desta forma, precisamos de outra tabela, que nomeamos Clientes, contendo estes atributos: Clientes (CodCli, NomeCli, CNPJCli) (Tabela 38); NotaFiscal (NroNF, Serie, DataEmisso, Clientes_CodCli, TotalNota). Esta tabela precisou ser alterada, possuindo uma chave estrangeira referenciando a tabela Clientes, conforme Tabela 39. As outras tabelas continuam da mesma forma. Vendas(NroNF, CodM, Qdade, TotalVenda) (Tabela 40); Mercadorias (CodM, Descricao, Preco) (Tabela 41); Perceba que as outras tabelas ficaram inalteradas. Portanto, estas tabelas encontram-se na 3FN. Estas relaes esto na BCNF, de acordo com a definio, pois todas as dependncias funcionais existentes possuem a super chave. Precisamos verificar se existem dependncias funcionais multivaloradas para verificar se estas tabelas encontram-se na 4FN. Como no foram identificadas, as tabelas encontram-se na 4FN. Da mesma forma, como no existe dependncia funcional cclica, as tabelas esto na 5FN. Outro ponto importante a ser verificado que a grande maioria dos modelos de dados resolvida pelas 1FN, 2FN e 3FN. Entretanto, importante ressaltar que existem outras formas normais abordadas neste artigo e verificar a aplicao de todas elas. Assim, neste exemplo simples de aplicao das formas normais, partimos de uma nica tabela NotaFiscal (NroNF, Serie, DataEmissao, CodCli, NomeCli. CNPJCli, MercadoriasVendidas, TotalNroNF 1 2 3 Serie D D D DataEmissao 18/09/2007 19/09/2007 20/09/2007 Clientes_CodCli 1 2 1 TotalNota R$ 9,40 R$ 32,50 R$ 2,00

Tabela 39. Tabela NotaFiscal NotaFiscal_NroNF 1 1 1 2 3 Tabela 40. Tabela Vendas CodM 1 2 3 4 Descricao Sabo em P Sabonete Saboneteira Creme Preco 5,40 2,00 2,00 32,50 Mercadorias_CodM 1 2 3 4 2 Qdade 1 1 1 1 1 TotalVenda 5,40 2,00 2,00 32,50 2,00

Tabela 41. Tabela Mercadorias

Figura 2. Tabela NotaFiscal e Vendas

Figura 3. Tabela NotaFiscal, Mercadoria e Vendas

Figura 4. Tabela NotaFiscal, Mercadoria, Clientes e Vendas

Edio 47 - SQL Magazine

31

Nota) (Figura 1) e chegamos ao resultado (Figura 4): Clientes (CodCli, NomeCli, CNPJCli); NotaFiscal (NroNF, Serie, DataEmisso, CodCli, NomeCli, CNPJCli, TotalNota); Vendas(NroNF, CodM, Qdade, TotalVenda); Mercadorias (CodM, Descricao, Preco). Se quisermos aprimorar um pouco mais nosso exemplo para torn-lo mais prximo do dia a dia, teramos o seguinte resultado: Clientes (CodCli, NomeCli, CNPJCli); NotaFiscal (NroNF, Serie, DataEmisso, CodCli, NomeCli, CNPJCli, TotalNota); Vendas(NroNF, CodM, Qdade, PrecoUnit, TotalVenda); Mercador ias (CodM, Desc r icao, PrecoPadrao). A principal diferena que a tabela Vendas, em grande parte dos sistemas, ela tambm ter um campo para armazenar o preo unitrio. As razes para isso so:
Codigo 1 2 3 4 Tabela 42. Tabela Pessoa Codigo 1 Nome Ary Tatiana Ana Joo Tipo Logradouro Avenida Avenida Rua Praa Nome Ary Tatiana Ana Joo

1) Quase sempre possvel dar descontos; Com esse campo, podemos armazenar qual foi o desconto dado (ou seja, o valor real da venda), para cada produto do pedido. 2) O fisco obriga as empresas a armazenar o seu histrico de vendas (pelo menos cinco anos). preciso armazenar qual foi o valor real de cada venda, para cada produto. Em alguns casos, necessrio inclusive armazenar qual foi o nome do produto no momento da venda (pois o nome do produto pode mudar no futuro). Existem duas solues nesse caso: 1) Armazenar o nome do produto na tabela vendas: Vendas(NroNF, CodM, Qdade, NomeProduto, PrecoUnit, TotalVenda); 2) Criar uma tabela de histrico de nomes de produtos. Veja o exemplo: HistricoMercadorias (CodM, Descricao, DataMudanca).
Endereco Av. Getlio Vargas, 1000, apto 201 Patos de Minas-MG Av. Brasil, 966 Belo Horizonte-MG Rua Minas Gerais, 100 Recife-PE Praa da Liberdade, 27 So Paulo-SP

Desnormalizao
Pudemos perceber o quanto importante a normalizao de dados para que se tenha um projeto de banco de dados livre de redundncias e inconsistncias. Entretanto, em alguns casos, a normalizao de dados pode gerar uma dificuldade em se recuperar informaes. Esta dificuldade deve-se principalmente no tempo gasto para se executar as consultas ao banco de dados. Isto por que ao normalizar o projeto de banco de dados, temos uma tendncia natural em acrescentar tabelas ao modelo, o que pode significar o uso mais intensivo de junes em consultas. sabido que junes tendem a ser computacionalmente custosas. Dessa forma, o uso de normalizao pode levar a perda de desempenho. Para melhoria, principalmente deste desempenho, podemos utilizar o que iremos chamar de desnormalizao dos dados. Entretanto, importante ressaltar que isto no pode ser argumento geral para que no se normalize os dados. Isto parece natural, uma vez que ao normalizar, normalmente uma tabela pode ser dividida em vrias outras. Assim, podemos perceber que uma consulta SQL pode se tornar relativamente complexa medida que normalizamos os dados. Por exemplo, podemos ter uma tabela PESSOA (Codigo, Nome, Endereco) apresentada na Tabela 42 e na Tabela 43 com o atributo endereo sendo dividido em atributos atmicos. Repare que na Tabela 43 temos possibilidades de redundncias e inconsistncias nos atributos Cidade e UF. Obviamente que para evitarmos este problema, seria necessrio termos tabelas para Cidades e UF, conforme Tabela 44 e Tabela 45 respectivamente. Na Tabela 46, fizemos uma alterao da Tabela 43 retirando os atributos cidade e uf, substituindo-os pela chave estrangeira CodCidade que referencia a tabela CidadesUF (Tabela 45). Repare que a tabela CidadesUF tambm possui uma chave estrangeira CodUF, que referencia a tabela UF (Tabela 44). Assim, teramos uma tabela Pessoa referenciando a tabela CidadesUF, que referencia a tabela UF. Desta forma, no teramos mais a possibilidade de inconsistncias nos atributos Cidade e Estado.

Logradouro Getlio Vargas Brasil Minas Gerais Liberdade

Nro 1000 966 100

Comp Apto 201

Cidade Patos de Minas Belo Horizonte Recife So Paulo

UF
MG MG PE SP

2 3
4

27

Tabela 43. Tabela Pessoa sem Atributo Composto CodUF 1 2 3 Tabela 44. Tabela UF Codigo 1 2 3 4 Nome Ary Tatiana Ana Joo Tipo Logradouro Avenida Avenida Rua Praa Descricao MG PE SP CodCidade 1 2 3 4 Descricao Patos de Minas Belo Horizonte Recife So Paulo CodUF 1 1 2 3

Tabela 45. Tabela CidadesUF Logradouro Getlio Vargas Brasil Minas Gerais Liberdade Nro 1000 966 100 27 Comp Apto 201 CodCidade 1 2 3 4

Tabela 46. Tabela Pessoa referenciando tabela CidadesUF

32

SQL Magazine - Normalizao de Dados

NOR MA L I Z A O
Porm, repare que a consulta para listar o endereo do Ary sendo aplicado na Tabela 42 (Listagem 1) mais simples que a mesma consulta sendo aplicada na Tabela 43 (Listagem 2), que por sua vez mais simples do que a consulta para listar o endereo do Ary nas tabelas normalizadas (Tabela 44, Tabela 45, Tabela 46), apresentada na Listagem 3. Desta forma, podemos perceber que em alguns casos, ao normalizarmos, as consultas podem ficar mais complexas. Este exemplo do endereo pode gerar abstraes para verificarmos que em vrios casos isto pode ocorrer. Assim, conforme falamos anteriormente, vale ressaltar que para tomarmos estas decises, devemos conhecer previamente o comportamento do sistema e assim, determinar o comportamento de cada atributo. Para este caso, o atributo endereo meramente informativo para, por exemplo, impresso de etiquetas para envios de mala direta. Mas poderamos tambm ter um caso onde existiro relatrios para verificar percentual de clientes por cidade e/ou por estado. Analisando estes duas possibilidades poderemos verificar o que fazer, ou seja, normalizar ou no o endereo. Um outro exemplo do uso da desnormalizao pode ocorrer quando trabalhamos com histrico de dados. Vamos supor um relacionamento envolvendo professores e disciplinas. Sabemos que em diversas instituies, um professor pode ministrar vrias disciplinas e cada disciplina pode ser ministrada por um professor. Assim, teramos na Tabela 47 a tabela Professor, com o cadastro dos professores, na Tabela 48 a tabela disciplina com o cadastro das disciplinas e na Tabela 49 a tabela Ministra, que relaciona professor e disciplina. Perceba que o atributo Ementa na tabela disciplina (Tabela 48) responsvel por armazenar a ementa da disciplina. Entretanto, sabemos que o valor deste atributo pode variar ao longo do tempo. Assim, o questionamento passa a ser, precisamos armazenar os dados histricos para
Listagem 1. Consulta Endereo, com a Tabela Pessoa com atributo composto
SELECT endereco FROM Pessoa WHERE Nome = Ary

Listagem 2. Consulta Endereo, com a Tabela Pessoa sem atributo composto

SELECT TipoLogradouro, Logradouro, Nro, Comp, Cidade, UF FROM Pessoa WHERE Nome = Ary

Listagem 3. Consulta Endereo, com a Tabela Pessoa sem atributo composto

SELECT TipoLogradouro, Logradouro, Nro, Comp, CidadesUF.Descricao, UF.Descricao FROM Pessoa, CidadesUF, UF WHERE (Pessoa.codCidade = CidadesUF.CodCidade) and (CidadesUF.CodUF = UF.CodUF) and (Nome = Ary)

CodProf 1 2 Tabela 47. Tabela Professor CodDisc 1 2 Nome

Nome Ary Ana

Sistemas de Bancos de Dados Programao Orientada a Objetos

Ementa 1. Introduo a Sistemas de Bancos de Dados, 2. Modelos de Dados, 3. Modelagem de Dados, 4. SQL 1. Introduo, 2. Conceitos Bsicos, 3. Herana

Tabela 48. Tabela Disciplina CodProf 1 2 CodDisc 1 2 Ano 2006 2006

Tabela 49. Tabela Ministra CodProf 1 2 1 2 CodDisc 1 2 1 2 Ano 2006 2006 2007 2007 Ementa 1. Introduo, 2. Modelagem de Dados, 3. SQL 1. Introduo, 2. Conceitos Bsicos, 3. Herana 2. Introduo a Sistemas de Bancos de Dados, 2. Modelos de Dados, 3. Modelagem de Dados, 4. SQL 2. Introduo, 2. Conceitos Bsicos, 3. Herana

Tabela 50. Tabela Ministra

este atributo? Caso necessitemos, como resolver, passar a armazenar o atributo na tabela Ministra (Tabela 49) ou criar um relacionamento entre disciplinas e uma nova tabela Ementa? A forma mais simples para resolver este problema seria acrescentar um atributo na tabela Ministra (Tabela 49) e manter o atributo tambm na tabela disciplina (Tabela 48). Ao acrescentar o atributo, podemos veri-

ficar o resultado na Tabela 50. Perceba que neste caso, o atributo ementa da tabela disciplina (Tabela 48) armazena a ltima ementa da disciplina e o atributo ementa da tabela ministra (Tabela 50) armazena a ementa utilizada em determinado ano para a referida disciplina. Assim, conseguimos perceber que estas tabelas no esto normalizadas e que existem redundncias. Porm, depen-

Edio 47 - SQL Magazine

33

dendo da nossa necessidade nos sistemas, podemos abrir mo da normalizao para obtermos resultados mais rpidos no que diz respeito a dados histricos. Entretanto, no podemos esquecer que isto pode gerar grandes transtornos para o sistema, principalmente se a equipe de desenvolvedores no conhecer claramente as regras impostas para o referido sistema. Isto nos mostra que o bom conhecimento do comportamento do sistema e dos atributos sempre deve existir, pois a existncia destas redundncias e obviamente a no normalizao dos dados podem gerar srios problemas de inconsistncia. Outra dvida que acontece com bastante freqncia com relao a atributos repetidos. Vamos supor que voc precise armazenar trs telefones de contatos para um determinado cliente. O que mais interessante, criar atributos para telefone (telefone1, telefone2, telefone3) (Tabela

53) ou criar uma tabela telefone (Tabela 52) que se relacione com a tabela clientes (Tabela 51) em um relacionamento 1:n? A partir deste questionamento, podemos verificar que em muitos casos pode ser interessante desnormalizar. Mas, desnormalizar at quando? Qual a perda do projeto ao utilizarmos a prtica da desnormalizao? A resposta a esta ultima questo bastante complexa e pode variar de acordo com cada projeto. Para isto, verificar todos os detalhes sobre o comportamento do sistema, os objetivos do projeto, dentre vrios outros fatores de suma importncia. Obviamente que os objetivos devem ser definidos em longo prazo, para o ciclo de vida do sistema como um todo. Caso contrrio, pode-se perder muito com retrabalho relativo ao que normalizar e ao que desnormalizar. Verificamos que na prtica, muitos sistemas trabalham com parte dos bancos

de dados desnormalizados. Sabemos que isto pode trazer bons resultados, principalmente pelo que foi exposto anteriormente. Entretanto, vale ressaltar que esta prtica pode ser muito perigosa para o sistema ao longo do ciclo de vida. Existem alguns outros casos que freqentemente nos deparamos com desnormalizaes, como a gerao de relatrios. Podem existir vrios relatrios que fazem muitos clculos. Assim, o questionamento : fazer os clculos todas as vezes em que o relatrio for gerado ou criar um atributo para armazenar valores j calculados. Imagine por exemplo um frum na web com milhes de registros. Imagine tambm que na pgina principal do frum exibido o total de mensagem de cada tpico do frum. Neste caso, sempre deveria se fazer um clculo com a quantidade de mensagem ou a cada nova mensagem simplesmente incrementa-se

Figura 5. Frum web

34

SQL Magazine - Normalizao de Dados

NOR MA L I Z A O

CodCli 1 2 Tabela 51. Tabela Cliente CodTel 1 2 3 4 Telefone (34) 3821-0000 (11) 3048-0000 (34) 9976-0001 (34) 3820-1000

Nome Ary Ana

Referncias DATE, C.J. Introduo a Sistemas de Bancos de Dados, Editora Campus, 2004. FAGIN, Ronald, A Normal Form for Relational Databases that is Based on Domains and Keys, Communications of the ACM, vol 6, pp.387-415 HARRINGTON, J. L. Projetos de Bancos de Dados Relacionais, Editora Campus, 2002. MONTEIRO, Emiliano S. Projeto de Sistemas e Bancos de Dados, Brasport, 2004. MULLER, Robert J. Projeto de Banco de Dados, Editora Berkeley, 2002. SILBERSCHATZ, A. KORTH, H. F., SUDARSHAN, S. Sistemas de Bancos de Dados, Makron Books 1999.

CodCli 1 2 1 1

Tabela 52. Tabela Telefone CodCli 1 2 Nome Ary Ana Telefone1 (34) 3821-0000 (11) 3048-0000 Telefone2 (34) 9976-0001 Telefone3 (34) 3820-1000

Tabela 53. Tabela Cliente com Telefone

o valor de um atributo? Veja na Figura 5 a existncia deste atributo. Se em todas as exibies se tivesse que calcular a quantidade de mensagens, com certeza o processamento das consultas aumentaria muito e conseqentemente o desempenho do frum seria reduzido. Desta forma, verificamos que a normalizao de suma importncia, porm, em muitos casos, podemos abrir mo da normalizao e criar atributos e s vezes tabelas desnormalizadas com algumas finalidades especficas.

Consideraes finais
Podemos perceber que a adoo da normalizao de dados importante para que o projeto de um banco de dados no possua redundncia e conseqentemente inconsistncia. Assim, devemos verificar sempre todos os conceitos abordados neste artigo, com a finalidade de gerar melhores modelos de dados. Conseqentemente, os sistemas iro absorver todos estes benefcios, principalmente, gerando melhores informaes para tomadas de decises, por exemplo. Vale ressaltar que a normalizao no pode gerar perdas no poder de extrao de informaes a partir dos bancos de dados. Caso isto ocorra, em muitos casos pode ser interessante o processo de desnormalizao para melhorar o desempenho das consultas, por exemplo. Entretanto, este custo pode ser muito alto, comprometendo a garantia de consistncia dos dados.

Edio 47 - SQL Magazine

35