Modelagem de Banco de Dados: 5 regras para construção de um banco de dados

Em artigos anteriores (SQL Magazine, edições 121, 122 e 132), abordamos conceitos e técnicas de modelagem de dados e apresentamos as vantagens de utilizar modelos para representar os requisitos de informação relevantes a uma determinada área de assunto: o negócio de uma empresa, uma área de negócio ou um sistema de informação. Representando o negócio sob a perspectiva dos dados, modelos de dados são úteis em todas as fases de um projeto de TI, complementando a perspectiva “funcional” dos modelos de processos.

Neste artigo, abordaremos especificamente a utilização de modelos para projetar, construir e manter bancos de dados que suportam sistemas de informação. De maneira resumida, demonstraremos que os benefícios de criar e manter modelos extrapolam a aplicação das técnicas de modelagem para o correto desenvolvimento dos sistemas.

Por que utilizar modelos para manter bancos de dados?

Imaginemos que há muitos anos, em seu primeiro emprego na área de informática, um analista trabalhou como desenhista copista em uma empresa de tecnologia que desenvolvia hardware e software para automação de máquinas injetoras de plástico (precursoras, possivelmente, das atuais impressoras 3D). Trabalhando em uma mesa inclinada, com réguas de gabarito, papel vegetal e caneta nanquim, ele era responsável por “passar a limpo” intrincados diagramas elétricos, elaborados pelos engenheiros da empresa. Os diagramas eram utilizados como modelos para projetar e, posteriormente, orientar a construção das placas de circuito elétrico do então chamado Sistema Automático de Controle de Processos. A Figura 1 mostra um desenhista técnico e um exemplo de seu trabalho.

Figura 1. Exemplos de desenhista e desenho técnico.

Isso aconteceu um pouco antes do advento dos programas de Desenho Assistido por Computador (DAC ou CAD – Computer Aided Design). Para se ter ideia do esforço envolvido na confecção manual de tais diagramas, basta dizer que alterações nas especificações obrigavam, com frequência, ao descarte do diagrama existente e à confecção de um diagrama inteiramente novo, a partir do zero. Se a alteração fosse pequena e pudesse ser acomodada no próprio diagrama, utilizava-se um estilete para, cuidadosamente, raspar o nanquim do desenho que seria alterado e, assim, liberar espaço para o desenho da nova especificação (o estilete também era útil para corrigir erros cometidos durante o desenho original). Horas incontáveis eram gastas na elaboração de diagramas impecáveis, que traduzissem sem erro as especificações.

O ponto que queremos ilustrar é que, mesmo quando diagramas técnicos eram feitos manualmente, partia-se do princípio de que nenhum componente do sistema devia ser construído sem que, antes, fosse completamente diagramado. Além disso, sempre que era necessário alterar uma especificação do sistema, o diagrama do componente afetado era utilizado como um ponto de partida para todas as atividades, sendo alterado e publicado antes da alteração ocorrer fisicamente.

Naquela época, como hoje, os diagramas possuíam símbolos padronizados para representar os diferentes objetos diagramados, além de uma quantidade considerável de textos e legendas, necessários para identificar os objetos e seu propósito. Além de detalhados, os diagramas deviam ser confiáveis, ou seja, corresponder a descrições fiéis dos objetos que representavam. Motivo de orgulho para muitos desenhistas esforçados, os engenheiros confiavam nos diagramas tanto quanto nas próprias máquinas que construíam.

Analogamente, se compararmos um sistema de informações a um edifício, o banco de dados que suporta o sistema corresponderia à fundação ou aos alicerces do edifício. É óbvio que, se os alicerces não forem projetados adequadamente, a construção inteira ficará comprometida: o edifício não será erguido ou, se isto acontecer, correrá o risco de desmoronar. Aqui também está implícita a ideia de que o edifício deve ser construído a partir dos alicerces e que, posteriormente, qualquer alteração deve começar com uma revisão da arquitetura inicial, considerando o impacto na fundação e em todos os componentes estruturais."