Dicas Para Uma Boa Modelação de Dados: Normalização

Imaine que lhe foi dado o projecto que se segue. Crie um sistema de base de dados para ser utilizado numa loja de aluguer de vídeos (clube de vídeo), de modo a permitir que a loja possa acompanhar o histórico dos seus clientes - histórico dos vídeos alugados por cada cliente e o estado dos vídeos. O clube de vídeo deverá ser capaz de adicionar novos títulos e novos clientes.

Num sistema de base de dados flat-file, seria difícil a criação de uma boa base de dados nesta situação. Numa base de dados flat-file pura não seríamos capazes de explicitar relações entre as tabelas da base de dados. Consequentemente, seríamos forçados a agrupar todos os campos relacionados numa grande tabela. Uma base de dados flat-file poderia ter uma tabela com as seguintes colunas:

• ClienteID (SSN)
• Nome Cliente
• SaidaVideoID1
• SaidaVideoID2
• ...
• SaidaVideoIDM
• SaidaVideoAnterior1
• SaidaVideoAnterior2
• SaidaVideoAnterior3
• ...
• SaidaVideoAnteriorN

Como se pode ver, existem colunas (1...M) para os IDs dos vídeos saídos (alugados no momento) e colunas (1...N) para o histórico dos vídeos alugados. No entanto, a utilização de uma base de dados flat-file ignora as relações entre entidades.

Pelo contrário, as bases de dados relacionais são definidas pelas relações entre as entidades. Entre as bases de dados relacionais podemos referir nomes como SQL, Access, Informix, Oracle, etc. Poderíamos ter uma tabela Cliente, uma tabela Filme e uma tabela Saida, as quais relacionariam o clienteID com o filmeID.

Não pense, no entanto, que numa base de dados relacional basta estabelecer relações. Muitos especialistas em desenvolvimento, quando estão a desenvolver bases de dados relacionais, não racionalizam completamente os seus modelos de dados. Esta falha pode conduzir a problemas relacionados com a integridade dos dados e faz com que a actualização e a modificação do modelo de dados sejam muito mais difíceis.

A acção de criar uma base de dados completamente relacional é conhecida como normalização. Com base no "Inside SQL Server 6.5", uma base de dados normalizada elimina dependências funcionais nos dados, de modo a que a actualização da base de dados seja fácil e eficiente. Contudo, apesar da normalização das bases de dados ser sempre algo de bom, a verdade é que podemos exagerar na normalização do desenho de dados dessas bases de dados, fazendo com que o desempenho passe a ser um problema. Uma base de dados completamente normalizada terá várias pequenas tabelas e qualquer query exigirá várias uniões. Estas várias relações e uniões farão realmente com que a actualização do desenho de dados seja muito mais fácil, mas diminuirão o desempenho em muitas queries.

Existem vários graus de normalização, designados por primeira forma normal, segunda forma normal, etc. Os estudos relativos ao desempenho têm mostrado que as bases de dados apresentam normalmente melhores desempenhos quando normalizadas de acordo com a terceira forma normal. No entanto, para alcançar a terceira forma normal será necessário alcançar antes a primeira e a segunda forma normal.

Convém ter em conta que podemos submeter o desenho da nossa base de dados a testes. Se o nosso desenho de dados responder a todos os requisitos da primeira e segunda forma normal, mas não aos da terceira forma normal, o desenho de dados será normalizado de acordo com a segunda forma normal. Mas como a terceira forma normal é a desejável, deveremos trabalhar na nossa modelação de dados para garantir que a base de dados está de acordo com a terceira forma normal.

Primeira forma normal
Para alcançar a primeira forma normal, cada campo de uma tabela tem que comunicar informação única. Por exemplo, se tivermos uma tabela Cliente com duas colunas para o número de telefone, o nosso desenho violará a primeira forma normal. Esta primeira forma normal é, no entanto, bastante fácil de alcançar, dado que serão poucos aqueles que terão necessidade em duplicar informação numa tabela.

Segunda forma normal
Nenhum campo de uma tabela pode ser derivado de outro campo da mesma tabela. Por exemplo, suponhamos que tem uma coluna para a data de nascimento na tabela Cliente. Não existiria qualquer necessidade de acrescentar uma coluna com a idade, dado que seria fácil de calcular a idade com base na data de nascimento. A segunda forma normal costuma colocar dificuldades mesmo a especialistas experientes em desenho de dados. Como tal, é importante olhar atentamente para as colunas, a fim de assegurar que nenhuma delas deriva de outra.

Terceira forma normal
Não é permitida informação duplicada em toda a base de dados. No nosso exemplo, quereríamos uma tabela chamada Saida, que incluiria uma lista dos vídeos alugados por cada cliente. Um erro comum seria fazer com que esta tabela guardasse informação sobre o cliente (como o nome, endereço, clienteID, etc.) e sobre o filme (género, título, classificação, análises, etc.). Evidentemente, esta informação estaria duplicada, dado que o nome e o endereço do cliente já constam da tabela Cliente, enquanto que a classificação, o título e o género do filme já estariam na tabela Filme. Para garantir a terceira forma normal, seria necessário que a tabela Saida tivesse apenas o ClienteID e o FilmeID (e talvez um campo data/hora).

Existem mais de três formas normais, mas são poucos os programadores que se preocupam em garantir mais formas de normalização. Isso deve-se em grande parte ao facto de se criarem problemas de desempenho quando se vai além da terceira forma normal. Além disso, pode ser muito desmoralizante garantir que o nosso desenho responde à quarta ou quinta forma normal. Na realidade, por vezes a terceira forma normal pode ser demasiado normal.

A melhor abordagem consiste em normalizar a nossa base de dados até à terceira forma normal e depois experimentá-la/manipulá-la para determinar como atingir o melhor desempenho. A utilização desta abordagem será melhor do que começar com uma base de dados não normalizada e avançar depois para a sua normalização até atingir um determinado nível de desempenho.

Resumindo, a normalização é boa e é algo importante. A normalização de uma base de dados permite a fácil actualização e manutenção do desenho de dados. A normalização em excesso poderá prejudicar o desempenho. A melhor abordagem consiste em normalizar até à terceira forma normal. Depois disso, se o desempenho ainda constituir um problema, deve-se experimentar/manipular o desenho de dados até ficarmos satisfeitos com o desempenho.

Baseado num artigo intitulado "Data Modeling 301", publicado no site http://4guysfromrolla.com/webtech/datamodeling.shtml.