N style="mso-spacerun: yes">
Clique aqui para ler todos os artigos desta edição
Homologação de modelos de dados
Avaliando a qualidade na raiz do projeto
Carlos Caldo
O administrador de dados sofrendo com diversos mal estares e preocupado com a saúde, decide procurar o médico. Ao adentrar a sala do consultório, o doutor dirige o olhar ao semblante do administrador de dados e o observa durante alguns minutos, sem nada dizer. O silêncio perturbador faz com que nosso colega de área, praticamente grite:
- Algo errado doutor?
Sem titubear, rapidamente o médico devolve a frase devastadora:
- O senhor está muito doente.
Agora, completamente desesperado, o paciente retruca:
- O que eu tenho? É muito grave?
O médico, sem esboçar reação mais expressiva, simplesmente diz calma e serenamente:
- Não sei ao certo, mas que o senhor esta mal, isto está! Decreta sem piedade.
Na sala de espera os outros pacientes apenas escutam um barulho estranho... Era o nosso administrador de dados que acabava de desmaiar.
A cena narrada acima é fictícia, mas serve para que façamos uma reflexão: você gostaria que um médico, sem que lhe examinasse detalhada e formalmente lhe fornecesse um diagnostico?
Claro que não, pois se o diagnóstico fosse ruim, como o do nosso colega administrador de dados, você também poderia desmaiar, além de tomar medidas errôneas para o tratamento. Por outro lado, se o diagnóstico fosse bom, poderia até ser pior, pois no caso de existir um problema você não tomaria as providencias necessárias.
Esta reflexão pode ser aplicada agora ao cenário de desenvolvimento de sistemas, mormente na elaboração de modelos de dados. Muitas vezes, escutei criticas a um modelo por parte de equipes de administradores de dados sem que ao menos um relatório formal de inconsistências fosse fornecido ao analista. Em nossa opinião, não mais existe espaço para este tipo de procedimento. Para que ocorra melhoria de qualidade é necessário apontamento claro e formal sobre o que necessita ser aprimorado. Não vale somente falar, é preciso documentar!
Tenho notado que a consciência sobre o que realmente um modelo de dados representa está, com raras exceções, deturpando-se, pois o modelo é considerado por muitos profissionais apenas como um instrumento de documentação, conceito este que acaba contaminando inclusive as mentes de administradores de dados e gerentes de vários níveis. Consideram que o modelo de dados é bom se o mesmo possui descrições ricas sobre seus componentes e obedece a padrões de nomenclatura estabelecidos.
Ora, isso é muito pouco! Um modelo de dados deve ser considerado como um valioso instrumento de especificação, ou seja, através dele, em conjunto com o modelo funcional, é que toda arquitetura de um banco de dados será projetada. Se o modelo foi bem especificado, com chaves primárias coerentes com a cardinalidade de relacionamentos, com hierarquias semânticas (generalizações, agregações) corretamente identificadas, reutilizações de dados consideradas, regras de normalização aplicadas, entre outros aspectos, então teremos sucesso no projeto físico de banco de dados.
Todavia, se um modelo de dados for mal especificado, não raro escutaremos posteriormente:
