Dicas de normalização de bancos de dados

Este artigo oferece aos desenvolvedores algumas dicas para ajudá-los a evitar algumas armadilhas na criação de tabelas Access. As dicas são aplicáveis a bancos de dados (.mdb) e projetos (.adp) Microsoft Access.

Autor: Luke Chung

Conteúdo
Dicas de Normalização de Bancos de Dados
Conteúdo
Introdução
Os Dados
Entendendo Seus Dados
Quais São os Dados Necessários?
O Que Vai Ser Feito com os Dados?
Como os Dados Se relacionam?
O Que Vai Acontecer com os Dados com o Tempo?
Aprenda a Usar Consultas
Conceitos de Normalização de Tabelas
Armazenar Informações Únicas em um Único Lugar
Registros são Grátis, Novos Campos Custam Caro
Saiba Quando os Dados Devem Ser Duplicados
Use Campos Sem Significado Como Campo Chave
Use Integridade Referencial
Conclusão.

Introdução
Um dos passos mais importantes na criação de um banco de dados é o conhecimento de que os dados estão distribuídos corretamente nas suas diversas tabelas. Com estruturas de dados corretas, o restante do aplicativo (as consultas, os formulários, os relatórios, os códigos) fica significativamente simplificado. O nome formal da criação correta de tabelas é normalização de banco de dados.

Este artigo é uma amostra dos conceitos básicos da normalização de bancos de dados e algumas das armadilhas a serem consideradas e evitadas.

Os Dados
Entendendo Seus Dados
Antes de iniciar a criação das tabelas, é importante entender o que se planeja fazer com os dados e como estes mudarão com o passar do tempo. As idéias levantadas neste ponto vão afetar todo o desenvolvimento do aplicativo.

Quais São os Dados Necessários?
Ao criar um aplicativo, é crítico entender os resultados finais para estar seguro de ter todos os dados necessários e saber de onde eles virão. Por exemplo, qual a aparência dos relatórios, de onde vem cada parte dos dados e, principalmente, os dados existem? Nada é mais danoso para um projeto que descobrir, bem adiante no processo, que faltam dados para a emissão de um relatório importante.

Uma vez sabendo os dados necessários, deve-se determinar de onde eles virão. Os dados serão importados de outra fonte? Estes dados precisam ser “limpos” ou verificados? O usuário entra com os dados?

Ter um bom conhecimento de quais dados são necessários e de onde eles virão é o primeiro passo para a criação de um bom banco de dados.

O Que Vai Ser Feito com os Dados?
Os usuários precisarão editar os dados e, se sim, como os dados deverão ser mostrados para que possam entendê-los e editá-los? Existem regras de validação e tabelas de pesquisa relacionadas? Existem situações de auditoria associadas com a entrada de dados que exigem a manutenção de cópias de segurança das exclusões e alterações? Que tipo de informações resumidas devem ser apresentadas ao cliente? Será necessária a exportação de arquivos? Com estas informações pode-se ter uma idéia de como os dados contidos no banco se relacionam.

Como os Dados Se relacionam?
Agrupe seus dados em campos relacionados (como informações relativas aos clientes, informações relativas aos pedidos, e assim por diante). Cada grupo de campos representa uma futura tabela no banco de dados. Deve-se, então, considerar como elas se relacionam. Por exemplo, quais tabelas são relacionadas em relacionamentos um-para-muitos (por exemplo, um cliente pode ter vários pedidos)? Quais tabelas têm relacionamentos um-para-um (que podem, talvez, ser combinadas em uma única tabela)?

O Que Vai Acontecer com os Dados com o Tempo?
Depois que as tabelas são criadas, o impacto do tempo raramente é considerado, podendo causar sérios problemas mais adiante. Muitas tabelas funcionam muito bem no uso imediato. Entretanto, muitas delas desmoronam à medida que o usuário modifica ou acrescenta dados com o correr do tempo. Muitas vezes os desenvolvedores necessitam reestruturar suas tabelas para atender a estas mudanças. Quando a estrutura de uma tabela é alterada, todas as suas dependências (consultas, formulários, relatórios, códigos) também necessitam ser alterados. Entender e antecipar estas alterações permite uma implementação que minimize os problemas.

Aprenda a Usar Consultas
Entender como os dados serão analisados e manipulados também é muito importante. Deve-se ter um bom conhecimento de como funcionam as consultas, como usá-las para vincular dados de diversas tabelas, como usá-las para agrupar e consolidar dados, e como usar consultas de referência cruzada para apresentar dados em formato não normalizado.

Finalmente, a meta de um bom modelo de dados é equilibrar as necessidades de armazenar os dados com eficiência durante a utilização normal e sua recuperação e análise de forma simples. Conhecer o poder das consultas ajuda significativamente na criação das tabelas.

Conceitos de Normalização de Tabelas
Em vez de apresentar uma discussão teórica sobre a normalização de bancos de dados, esta seção explica os conceitos básicos envolvidos na normalização de bancos de dados. Como aplicá-los vai variar dependendo das necessidades dos aplicativos. A meta é entender estes conceitos básicos, aplicá-los quando possível e entender os problemas que podem ocorrer se não forem seguidos.

Armazenar Informações Únicas em um Único Lugar
A maioria dos desenvolvedores de bancos de dados entende os conceitos básicos da normalização de dados. Idealmente, gostaríamos de armazenar os mesmos dados nos mesmos lugares e referenciá-los através de uma identificação quando necessário. Assim, se alguma informação for alterada, podemos alterá-la em um único lugar e a informação é alterada em todo o aplicativo.

Por exemplo, uma tabela de clientes armazenaria um registro para cada cliente, incluindo nome, endereço, números de telefones, endereço de e-mail, além de outras características próprias. A tabela de clientes teria um campo único IdCliente (normalmente um campo Autonumeração), que é seu campo chave, usado por outras tabelas para se referir ao cliente. Assim, uma tabela de pedidos, em vez de armazenar todas as informações do cliente com cada pedido (pois cada cliente pode ter diversos pedidos), se refere simplesmente ao valor da ID do cliente, que pode ser usada para procurar pelos detalhes do cliente na tabela de clientes. O Access faz com que isto seja fácil através de formulários poderosos, que usam caixas de combinação e subformulários. Se necessário alterar alguma informação do cliente (como um novo número de telefone), isso pode ser feito na tabela de clientes e, em todos os lugares onde a informação é utilizada, ela será atualizada automaticamente.

Com uma base de dados corretamente normalizada, as alterações que ocorrem com o passar do tempo são tratadas facilmente, com uma simples edição. Bases de dados não normalizadas corretamente exigem, muitas vezes, consultas ou programação complexas para alterar diversos registros ou tabelas. Isto exige não apenas mais trabalho para implementar mas, também, aumenta a possibilidade de inconsistência de dados se a consulta ou o código não executarem corretamente.

Registros são Grátis, Novos Campos Custam Caro
Os bancos de dados devem ser criados de modo a que, com o passar do tempo, simplesmente acrescentamos novos registros. As tabelas dos bancos de dados podem conter uma grande quantidade de registros. Entretanto, se necessário acrescentar novos campos, será um problema com origem na criação da tabela.

Isto ocorre muitas vezes com usuários experientes de planilhas, que tentam criar suas tabelas da mesma forma que criam suas planilhas. A criação de campos que armazenam unidades sensíveis ao tempo (como Ano, Trimestre, Produto e Vendedor), por exemplo, exigem que novos campos sejam adicionados no futuro. Mas a idéia correta é transpor a informação e ter os dados sensíveis ao tempo em um campo, permitindo que mais registros sejam incluídos. Por exemplo, em vez de criar um campo separado para cada ano, cria-se um campo Ano e entra-se com o valor do ano para o registro naquele campo.

A razão dos problemas da criação de novos campos é o impacto das alterações estruturais de tabelas em outras partes do aplicativo. Quando mais campos são adicionados a uma tabela, os objetos e códigos que dependem da tabela também necessitam de atualização. Por exemplo, as consultas precisam pegar os campos extras, os formulários devem mostrá-los, os relatórios precisam incluí-los, e assim por diante. Entretanto, se os dados estiverem normalizados, os objetos existentes atualmente recuperariam automaticamente os novos dados e executariam cálculos ou os apresentariam corretamente. As consultas são particularmente poderosas porque permitem que os dados sejam agrupados, por exemplo, pelo campo Ano, para apresentar informações resumidas por ano – não importando quais anos estão registrados nas tabelas.

A normalização de dados não significa, entretanto, que não se pode apresentar ou usar dados com campos sensíveis ou dependentes de tempo. Desenvolvedores que necessitam mostrar e apresentar tais informações o fazem utilizando consultas de referência cruzada. As consultas de referência cruzada são muito importantes e devemos saber usá-las bem. Elas não são a mesma coisa que tabelas (não podemos, por exemplo, editar os resultados de uma consulta de referência cruzada), mas podemos usá-las para apresentar informações em uma planilha (com até 255 colunas). Se quisermos usar consultas de referência cruzada em relatórios é mais complicado, pois o relatório precisa aceitar nomes de campo adicionais ou que se modificam. É por isso que a maioria dos relatórios apresenta os resultados agrupados em vez de em colunas separadas. Para os casos onde não houver escolha, deve-se investir tempo para resolver, mas provavelmente todos entenderão as implicações que tais decisões terão como recursos adicionais com o passar do tempo.

Assim, é por isso que registros adicionais são grátis (a grande vantagem dos bancos de dados) e o porquê de novos campos custarem tão caro. Bancos de dados podem guardar grandes quantidades de alterações, se criadas corretamente.

Saiba Quando os Dados Devem Ser Duplicados
Algumas vezes os dados necessitam ser desnormalizados para preservar informações que podem ser alteradas com o passar do tempo.

No exemplo do pedido vinculado à tabela de cliente por meio de um número de identificação do cliente, pode ser necessário preservar o endereço do cliente quando o pedido foi efetuado (não o endereço atual do cliente, já que este pode ser alterado entre pedidos). Se não for preservado o endereço do momento da emissão do pedido e o endereço do cliente for alterado no futuro, não haverá a capacidade de confirmar o endereço para onde determinado pedido foi enviado. Isto pode ser um grande problema comercial. Claro que algumas informações de endereçamento não necessitam ser preservadas, como um número de telefone, por exemplo. Assim sendo, deve-se determinar, seletivamente, quais dados deverão ser duplicados.

Outro exemplo de dados que necessitam ser duplicados está no preenchimento dos itens de um pedido. Normalmente uma lista de preços é utilizada para selecionar os itens pedidos pelo cliente. Poderia ser armazenada, simplesmente, a identificação do item na lista, que contém a descrição do item, seu preço de venda e outras informações. Entretanto, a descrição do item e o valor de venda podem ser alterados com o correr do tempo. Se estes dados não forem copiados da lista de preços para o pedido este não poderá ser reimpresso, o que pode ser um grande problema se ele ainda não foi pago. Outro problema: perdem-se os dados históricos e nunca se sabe quando serão necessárias informações estatísticas.

Assim sendo, mesmo que a normalização funcione muito bem para manter os mesmos dados no mesmo lugar e facilitar edições, existem situações onde tais benefícios não são desejáveis. Se necessário um retrato dos dados por razões históricas, é crítico que estas situações sejam criadas já no início da definição do banco de dados. Se não, uma vez que os dados sejam alterados, as informações não poderão ser recuperadas.

Use Campos Sem Significado Como Campo Chave
Por eficiência, cada tabela deve ter um campo chave. O campo chave define a unicidade na tabela e é usado por índices em outros campos para melhorar o desempenho de consultas. Por exemplo, a tabela Clientes pode ter um campo IdCliente que define um número único para cada cliente. Para esta discussão, estamos considerando tabelas que contém múltiplos campos e não uma tabela de pesquisa simples, como uma lista de siglas de estados.

De modo geral, um campo chave deve ter as seguintes características:

Deve ser um campo único
É possível definir múltiplos campos como chave de uma tabela, mas é preferível usar um único campo. Primeiramente, se é necessário a utilização de múltiplos campos para determinar a unicidade, será necessário mais espaço para armazenar a chave. Em segundo lugar, índices adicionais da tabela também usarão a combinação de campos da chave para identificação dos registros, o que, também, utiliza mais espaço que um campo único. Finalmente, a identificação de registros na tabela exige que seja usada uma combinação dos campos. É muito melhor ter um campo IdCliente do que uma combinação de outros campos para definir o cliente.

Deve ser numérico
O Access oferece o tipo de campo Autonumeração, que é um Inteiro Longo, que é ideal para utilização como campo chave. Estes valores são automaticamente únicos para cada registro e, além de tudo, suportam a entrada de dados multiusuários.

Não podem ser alterados com o passar do tempo
Um campo chave não pode ser alterado. Uma vez identificado, como um CPF, não deve mudar nunca. Um campo que seja alterado torna muito difícil a utilização como dado histórico, já que os vínculos entre as informações serão quebrados.

Não devem ter significado
Para certeza de que um campo chave não seja alterado, ele não deve ter significado. Um valor de chave sem significado também é de grande ajuda em situações em que os outros dados estejam incompletos. Por exemplo, pode-se dar um número a um cliente sem ter seu endereço completo. O restante do aplicativo vai funcionar corretamente e pode-se acrescentar a informação quando recebidas. Se a tabela usasse, como parte da chave, a sigla do estado ou outro campo identificador que não estivesse à mão no momento do cadastramento, haveria o risco de não ser possível a utilização do aplicativo.

Assim, por todas as razões expostas acima, é recomendado o uso de um campo Autonumeração como chave da maioria das tabelas (se não todas). Usando caixas de combinação e colunas ocultas, pode-se ligar campos ao campo Autonumeração e escondê-lo do usuário.

Use Integridade Referencial
Uma vez definidas as tabelas e entendido como elas se relacionam umas com as outras, deve-se acrescentar a integridade referencial para reforçar os relacionamentos. Isto evita que campos vinculados sejam incorretamente modificados, deixando registros “órfãos”. O motor de Bancos de Dados Microsoft Jet suporta integridade referencial bastante sofisticada, que permite atualizações e exclusões em cascata. De modo geral, o campo chave nunca será alterado e as atualizações em cascata deixam de ser importantes, mas as exclusões em cascata podem ser de grande ajuda.

Por exemplo, se existe uma tabela de notas fiscais relacionada a uma tabela de pedidos onde uma nota pode ter um número ilimitado de pedidos (itens) e cada registro de pedido contém o número da nota à qual está vinculado, a exclusão em cascata permite que, ao excluirmos a nota, sejam excluídos todos os itens do pedido. Isto assegura que nunca haverá pedidos sem um número correspondente de nota fiscal.

Conclusão
Esperamos que você seja capaz de aplicar estes conceitos de criação de bancos de dados no início do desenvolvimento do seu aplicativo de forma a minimizar muitos problemas e soluções emergenciais necessárias quando tais idéias não são implementadas. Boa sorte.

Luke Chung é Presidente e Fundador da FMS Inc., um grande fornecedor de produtos de terceiros para desenvolvedores e usuários do Microsoft Access.

Fonte: http://msdn.microsoft.com/library/en-us/dnacc2k2/html/odc_FMSNormalization.asp