Como Utilizar as Técnicas de Modelação de Dados

A modelação de dados é o processo através do qual desenhamos as tabelas, colunas e relações de uma base de dados. Uma boa forma de determinar quais as tabelas, colunas e relações que iremos precisar consiste em escrever com exactidão aquilo que queremos que a base de dados faça.

Por exemplo, vamos supor que queremos desenhar uma aplicação para lidar com os pagamentos dos ordenados de uma empresa. É essencial que compreendamos claramente aquilo que o sistema irá precisar de fazer. Normalmente basta um único parágrafo. Haverá, portanto, que escrever esse parágrafo e submetê-lo à apreciação dos supervisores e coordenadores do projecto, de modo a garantir que toda a gente está em sintonia.

Para este nosso exemplo, o parágrafo poderá dizer o seguinte: "o sistema de pagamento de ordenados acompanhará as horas de cada empregados (horas de entrada e de saída do trabalho durante o dia). Os números de segurança social serão utilizados para identificar inequivocamente cada empregado. Para a produção de relatórios, os empregados irão especificar as suas horas de trabalho com base em várias categorias. As categorias em que cada empregado poderá incluir as suas horas de trabalho irão depender do departamento a que pertence o empregado".

Apesar do parágrafo anterior não parecer dos melhor concebidos em termos literários, ilustra bem aquilo que queremos dizer. Graças a ele, poderemos ficar a saber rapidamente quais as tabelas que iremos precisar: uma tabela Empregado, uma outra Categoria, uma terceira Departamento, e uma última TempoGasto. Olhando para o parágrafo, os nomes são normalmente tabelas. Os adjectivos são normalmente colunas (o Numero-Seguranca-Social será uma coluna da tabela Empregado). Os verbos são normalmente relações /cada empregado TEM um departamento e existirá uma coluna DepartamentoID na tabela Empregado, a qual será Chave Estrangeira na tabela Departamento.

A escrita de um parágrafo como o referido atrás, além de nos ajudar a determinar a estrutura da base de dados, também nos ajuda numa prática cada vez mais importante: documentação. É vital que documentemos tudo. Os desenhos preliminares de tabelas, os aspectos importantes do desenho de dados, as especificações técnicas e todos os outros documentos precisam de ser agrupados e preenchidos para um acesso fácil a qualquer momento.

Uma das razões principais para efectuar a modelação de dados consiste em melhorar a facilidade de manutenção da aplicação. Consequentemente, é importante a existência de uma boa documentação. Outro passo importante a ter em conta para melhorar a facilidade de manutenção de qualquer programa incluem a escrita de código que se auto-documente. Ou seja, deve-se escrever o código de forma a que não sejam necessários muitos comentários. No desenho de bases de dados, isto significa atribuir nomes às tabelas e às colunas que sejam auto-explicativos.

Por exemplo, devemos chamar Empregado à nossa tabela de empregados (ou P_Empregado, em que o prefixo P esclarece que se trata de uma tabela utilizada no sistema de pagamentos. Não devemos utilizar nomes como TABELA01, ou outros nomes "secretos"que não digam nada. Também devemos escolher nomes apropriados para as colunas.

Como as bases de dados actuais são relacionais, devemos tirar partido disso utilizando tabelas de código. Estas tabelas são pequenas, tendo normalmente duas ou três colunas - uma com a chave primária (ID único) e mais uma ou duas colunas com descrições em português. Continuando com o nosso exemplo anterior, em que existem departamentos a que pertencem os empregados, poderíamos desenhar a tabela Empregado em tempos idos como se segue:

Nota: deixámos as designações/abreviaturas em inglês entre parêntesis para facilitar a compreensão, dado que muitos programadores continuam a ter o inglês como referência. Por exemplo, PK designa chave primária e FK chave estrangeira.

Nesta tabela, o departamento seria o departamento de cada empregado (obviamente). Assim, HUMAN poderia significar que o empregado fazia parte do departamento de recursos humanos. VENDAS significaria que trabalharia no departamento de vendas; GEST no de gestão e assim por diante.

Seja como for, este seria um mau desenho. O que aconteceria se fossem adicionados novos departamentos, ou removidos outros existentes? Um melhor desenho de dados utilizaria uma tabela de código, como se segue:

Neste segundo caso, existe uma linha para cada departamento na tabela Departamento. Utilizando as restrições da chave estrangeira, passou a ser impossível que um empregado possa ser alocado a um departamento que não exista. De igual modo, deixou de existir qualquer ambiguidade entre departamentos, dado que passaram a existir 50 caracteres para descrever o departamento na tabela Departamento.

Esta é uma melhor abordagem. As bases de dados são relacionais por alguma razão e esta é uma delas. Como tal, devemos assegurar-nos de que tiramos partido dessas relações. Existem muitos programadores que se recusam a utilizar tabelas de códigos. No entanto, com isso só estão a fazer com que os seus desenhos de bases de dados sejam difíceis de entender, menos eficientes e mais difíceis de manter.

A modelação de dados não é difícil. Se aplicarmos as boas práticas desta área, garantiremos desenhos de bases de dados mais fáceis de manter.

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