2.3. Modelagem de banco de dados
A modelagem de banco de dados até o início do ano 2000 era umas das formas mais comuns de se iniciar a modelagem de um sistema. Sob a orientação da arquitetura cliente-servidor, os analistas pensavam o sistema em termos de “o que deve ser armazenado no banco de dados”, as funcionalidades eram tratadas depois, e documentadas em texto puro, fluxogramas, modelagem de processos e outras técnicas.
Porém, com o advento das tecnologias de programação de última geração, o banco de dados tem-se tornado cada vez mais uma consequência da modelagem de classes, em que a parte de persistência é transformada em tabelas, campos e relacionamentos.
Por vezes, ainda, após a implantação da aplicação, administradores de dados analisam a performance do banco de dados e sugerem melhorias. Essas melhorias normalmente são recomendações de criação de índices, mudanças na estrutura de tabelas, inclusão ou exclusão de regras e até mesmo alterações na implementação física do próprio banco de dados como: replicação de dados, distribuição em pilhas de discos rígidos etc.
A parte lógica da análise dos modelos de dados normalmente é feita por diagramas de entidade relacionamento, em que são modeladas as seguintes informações:
Conjunto de dados que representa o contexto de uma informação. Muitas vezes há uma relação muito clara entre as classes do sistema (que são persistidas) e as tabelas. Exemplo: tabela pessoa, tabela de vendas, tabela de endereços.
XTipo de informação de uma tabela. Representa cada uma das informações acerca do assunto modelado. Normalmente representa os atributos de uma classe. Exemplos: nome do cliente, CPF, data de nascimento.
XTipo lógico do campo. Assim como os atributos, qualifica o tipo de informação armazenada. Exemplos: inteiro, fracionário, booleano, string.
XApresenta a relação entre duas tabelas, semelhante à associação entre duas classes. Exemplo: A tabela cliente relaciona-se com a tabela orçamento da seguinte forma: “um cliente possui zero ou muitos orçamentos associados”.
XSão pequenos trechos de código que acontecem antes e após as operações sobre as tabelas. Esses códigos muitas vezes são denominados de “triggers” (gatilhos). Permitem, por exemplo, validar operações de inserção ou exclusão de dados.
X