Modelação de Dados: Porque Razão é Vital?

A grande vantagem das Active Server Pages tem a ver com o facto de poderem utilizar conectividade de base de dados. Este facto fornece grandes capacidades às aplicações Web. No entanto, quando decidimos conceber aplicações Web interligadas com bases de dados, estas muitas vezes apresentam ao utilizador algumas tabelas e páginas ASP pouco cuidadas. Consequentemente, é bastante comum os programadores terem que voltar ao protótipo funcional já concluído para melhorarem as páginas ASP, de modo a tornarem a aplicação mais amigável para os utilizadores e mais utilizável.

Existe algo de fundamentalmente errado nesta abordagem. Em primeiro lugar, antes de escrever uma linha de uma ASP, deverá ter dedicado horas ao desenho dos dados. A tradução da lógica de negócio em tabelas, colunas e relações chama-se modelação de dados. No entanto, infelizmente, a modelação de dados parece ser uma arte em decadência. Parece que não são muitos os especialistas em desenvolvimento a compreenderem verdadeiramente a razão porque a modelação de dados é algo vital. E são ainda menos aqueles que despendem tempo e energia com esse trabalho.

Neste texto vamos tentar responder a uma questão vital: para quê investir tempo e esforço no desenho de uma base de dados? Pode não se preocupar muito com o futuro a longo prazo, mas a verdade é que a maior parte das aplicações continuarão a ser utilizadas muito depois dos programadores que as conceberem terem abandonado a empresa. Além disso, no curto e médio prazo, as aplicações precisam normalmente de ser actualizadas, de modo a incluírem novas funcionalidades ou características.

No entanto, muitas vezes, os programadores só pensam nas aplicações como se tivessem um período de vida bastante curto - um ano mais ou menos. Depois desse prazo, haveria que desenvolver uma nova versão ou simplesmente deixar de utilizar o software em causa. Se isto fosse verdade, não teriam existido os problemas da mudança de século com a entrada no ano 2000.

Uma vez que temos de continuar a actualizar os produtos ao longo do tempo, o mais racional será fazer com que sejam fáceis de manter. Com bases de dados desenhadas com grande cuidado, todos os especialistas em desenvolvimento de uma equipa (os mais e os menos experientes) serão capazes de determinar o propósito das várias tabelas e colunas, dado que estas foram desenhadas a pensar na sua manutenção futura.

Por exemplo, vamos supor que temos uma tabela destinada a permitir o acompanhamento das despesas e que o registo dessas despesas deverá ter em conta o departamento ao qual serão imputadas. O departamento de contabilidade poderá assim acompanhar as despesas de cada departamento através de um campo designado por CódigoDepartamento, constituído por um número alfanumérico de sete dígitos.

Depois disso, alguém poderá sentir-se tentado a criar uma coluna na tabela de acompanhamento de despesas designada por NumeroDepartamento, de tipo numérico (7,0). Deverá resistir-se a este tipo de tentação, uma vez que outros programadores que venham a olhar futuramente para os dados da tabela irão ver números como 9381170. Consequentemente, não farão ideia do que isso significa. Teremos igualmente problemas se os departamentos forem reestruturamos ou se forem criados novos departamentos. Um bom especialista em modelação de base de dados criará um código com um nome claro do departamento em português, tendo o NumeroDepartamento como chave única.

A facilidade de manutenção deverá ser um dos aspectos importantes a ter em conta no desenho de dados. De igual modo, deverá ter-se um cuidado extra com os nomes atribuídos às tabelas e colunas. É necessário desenhar diagramas Entidade-Relação detalhados e descritivos. Actualmente, as bases de dados modernas são todas relacionais, pelo que devemos estabelecer relações lógicas nas nossas bases de dados.

Aquando do desenho de uma base de dados devemos pensar, não só no curto e médio prazo, mas também no longo prazo, partindo do princípio de que seremos um novo programador a trabalhar nesse mesmo projecto daí a cinco anos. Será que compreendemos bem a organização das tabelas? E será que os nomes das colunas fazem sentido?

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