JPG src="/imagens/SQL/SQL16/capaSQL16.JPG" width=196 border=0>
Clique aqui para ler todos os artigos desta edição
10 passos para a criação de um modelo conceitual de banco de dado
por José Ferreira Prata
Existem notações e denominações diferentes para designar os componentes do modelo conceitual principalmente no que se refere ao tipo de orientação do banco de dados seja esse relacional, objeto-relacional ou orientado a objetos. Trataremos neste artigo basicamente do modelo conceitual para bancos de dados relacionais, embora muitos conceitos e denominações também sejam comuns para bancos de dados orientados a objetos. A seguir apresentamos alguns termos que utilizaremos para facilitar a compreensão do leitor:
• Tipos de entidade que definem um conjunto de entidades do mesmo tipo, (por exemplo: empregado, fornecedor, cliente, etc.) serão chamados apenas de entidade.
• Trataremos como ocorrência de uma entidade o equivalente a uma linha de tabela ou a um registro de arquivo.
• Atributo equivale a uma coluna em tabela e a um campo em um arquivo.
• O padrão de notação para desenho do modelo conceitual será o modelo entidade–relacionamento (ER).
Durante todos esses anos nos quais trabalhei com projetos envolvendo banco de dados ou lecionando essa disciplina, notei que tanto os analistas quanto os alunos tinham como principal dificuldade abstrair de forma adequada o modelo conceitual do banco de dados. Por conseqüência, os modelos lógico e físico também ficavam comprometidos. A correta identificação, principalmente das entidades e seus respectivos relacionamentos ficava totalmente dependente da capacidade de cada pessoa. Como a experiência só é obtida através do tempo e dos trabalhos realizados, durante esse período de aprendizado os projetos podem ter seus custos aumentados pelas correções de erros ou mesmo ter sua qualidade comprometida de forma irreversível. Como contornar então essas dificuldades? Acredito que a resposta esteja em uma das melhores práticas da qualidade de software, que é o estabelecimento de um processo padrão que oriente e aprimore continuamente o desenvolvimento.
É importante frisar que todo projeto de banco de dados deve começar sempre com requisitos bem descritos, que traduzam de forma adequada as necessidades e medidas de qualidade esperadas pelo cliente. Estes requisitos aliados a boas práticas de desenvolvimento aumentarão de forma considerável a probabilidade do produto desenvolvido ter a qualidade desejada.
Não iremos tratar, porém, da engenharia de requisitos (o artigo Desenvolvimento de aplicações orientadas a objeto apoiadas por tecnologias Java Parte II – Análise publicado na SQL Magazine 13 apresenta alguns pontos interessantes sobre a importância dos requisitos para o sucesso do desenvolvimento de um software) que por si só merece um trabalho à parte. Também não trataremos todas as regras e conceitos necessários para a construção do modelo conceitual de banco de dados, por se tratar de assunto muito extenso e complexo. Caso o leitor tenha interesse no aprofundamento desses conceitos, sugerimos consultar a bibliografia citada no fim do artigo. Abordaremos apenas os conceitos e regras essenciais, as facilidades que nossa própria língua oferece, além de algumas diretrizes e dicas simples para descobrir as entidades, tipos e graus de relacionamento e respectivas razões de cardinalidade.
Antes de iniciar as considerações sobre nosso processo de elaboração do modelo conceitual é necessário termos conhecimento do seguinte:
• Substantivos que designam alguém (fornecedor, cliente, funcionário, aluno); documentos (nota fiscal, pedido, conta corrente, estoque) ou ainda coisas (peça, produto) representam objetos do mundo real que podem vir a fazer parte do modelo conceitual. Vale ressaltar aqui que nem todos os objetos citados nos requisitos farão parte do modelo e para separá-los podemos utilizar algumas regras simples das quais falaremos mais adiante.
• Verbos e preposições por sua vez servem para que identifiquemos o relacionamento entre as entidades, pois demonstram as ligações existentes entre elas. Por exemplo, quando lemos em um texto a frase “Listar empregados por departamento” concluímos que a entidade “empregado” tem um tipo de relacionamento que podemos chamar de “trabalha no” com a entidade departamento. ...
