Artigo no estilo Mentoring
Ao desenvolvermos um sistema, seja de grande ou pequeno porte, é necessário planejar todas as suas etapas e dedicar uma atenção especial ao projeto do banco de dados. Sem esse planejamento prévio, a manutenção corretiva do sistema, além de constante, será mais complicada. O projeto de banco de dados utiliza uma técnica chamada modelagem de dados. Ela procura transformar uma ideia conceitual em algo que possa ser traduzido em termos computacionais.
Neste artigo, aplicamos o modelo entidade-relacionamento em um estudo de caso projetando e modelando um banco de dados para um módulo de controle bancário com as funcionalidades básicas de cadastramento de clientes, abertura, movimentação e encerramento de contas. Para a modelagem propriamente dita, utilizamos o SQL Developer Data Modeler, uma ferramenta CASE da Oracle disponibilizada de forma gratuita e que cobre todas as fases do projeto de um banco relacional (ler Nota 1).
Uma ferramenta computacional que auxilia no projeto de sistemas. Ela ajuda o projetista no desenvolvimento de um banco bem elaborado envolvendo os processos de projeto conceitual, projeto lógico e criação física.
O software atualmente é desenvolvido em cenários bastante complexos e com uma gama muito grande de variáveis envolvidas. Nesse contexto, é fundamental que se utilize um modelo de desenvolvimento no planejamento de um sistema. Os paradigmas de engenharia de software propiciam métodos e técnicas que mostram como proceder na construção de software.
A utilização de um método no desenvolvimento de um software traz vantagens que são facilmente verificáveis durante e após a sua construção: trabalho sistematizado, documentos padronizados, melhor controle no desenvolvimento, uniformidade de linguagem e maximização dos resultados.
Uma das primeiras tentativas de criar processos formais para o desenvolvimento de software foi através de uma conferência internacional, em 1968, promovida pelo grupo de estudo em ciência da computação da OTAN (Organização do Tratado do Atlântico Norte). Essa conferência foi uma tentativa de encontrar caminhos para melhorar o desenvolvimento de software que, durante a década de 60, ocorria sem nenhum método, de maneira informal, gerando atrasos e falhas nos projetos, que culminavam em metas não atingidas, custos imprevisíveis e sistemas de difícil manutenção. Tal situação caótica ficou conhecida como a “crise do software”, e a conferência de 1968 da OTAN procurou difundir a necessidade de um software que fosse concebido dentro de práticas disciplinadas. A conferência terminou sem uma proposta concreta, mas fomentou diversas discussões sobre esse assunto. Com o passar do tempo, entre as propostas que surgiram, a primeira a ter maior difusão e prática foi a técnica de análise estruturada.
Essa técnica começou a ser efetivamente utilizada a partir de 1975. Ela envolve a construção de um sistema de forma top-down (do todo para as partes) considerando-se os refinamentos sucessivos, produzindo em um primeiro momento uma fotografia global do sistema. Com base nesse esquema global, realiza-se uma decomposição funcional, gerando-se fluxos de processos especializados que são um detalhamento do fluxo macro. Esses detalhamentos começam a dar pistas dos dados requeridos que, posteriormente, serão representados como entidades no modelo entidade-relacionamento.
Dada a simplicidade da diagramação e dos conceitos envolvidos, o modelo teve ampla aceitação e passou a ser referência na modelagem de dados, sendo utilizado até os dias atuais no projeto de bancos relacionais. Ele é baseado em dois grupos de objetos: entidades e relacionamentos (que serão detalhados mais adiante).
Modelo Conceitual
Nessa etapa, as necessidades de informação são representadas através de uma visão genérica dos dados e seus relacionamentos. Um exemplo desse tipo de representação é apresentado a seguir:
1. Clientes pessoa física
Dados necessários: nome, endereço, bairro, cidade, estado, CEP, telefone, e-mail, contato.
2. Clientes pessoa jurídica
Dados necessários: CNPJ, razão social, endereço, bairro, cidade, estado, CEP, e-mail, contato.
3. Produtos
Dados necessários: identificador, nome, modelo, unidade de medida, preço de compra, preço de venda, data da última compra.
4. Operações
a. Cadastro de cliente (pessoa física ou pessoa jurídica)
Quando o cliente que está realizando uma compra não é cadastrado, o funcionário deve realizar o seu registro no sistema.
b. Cadastro de produto
Ao ser adquirido, o produto deve ser cadastrado pelo funcionário. Para isso, ele insere informações como nome, preço de compra e de venda e a data da compra.
Modelo Lógico
Nessa etapa, iremos representar as estruturas utilizadas para o armazenamento no banco de dados utilizando o modelo lógico. Para essa representação gráfica, utiliza-se o diagrama entidade-relacionamento (DER), que permite representar as estruturas de dados referentes a uma parcela do mundo real (“minimundo”). Esse diagrama mapeia os dados que as operações do sistema utilizam e caracteriza-se pela independência de dispositivos ou meios de armazenamento físico.
A modelagem com o DER permite a utilização de diversos elementos de modelagem, alguns mais simplificados e outros mais avançados. Apresentamos, neste artigo, apenas os construtores necessários para a modelagem de nosso estudo de caso. Esses construtores são apresentados na notação Chen (originalmente publicada no trabalho de Peter Chen, em 1976) e, quando necessário, na notação Barker (utilizada pelo SQL Developer Data Modeler):
· Entidade: objeto de dado básico do modelo entidade-relacionamento, cujas informações devem ser coletadas. Representa uma pessoa, lugar, coisa ou evento do mundo real, de interesse informativo. Uma ocorrência específica de uma entidade é chamada de instância da entidade. Na Figura 1, temos uma representação gráfica do construtor para entidades: um retângulo com as bordas retas (Notação Chen) ou arredondadas (Notação Barker), sendo que o nome da entidade é escrito dentro do retângulo.
· Atributo: são características das entidades, que oferecem detalhes descritivos sobre elas. Uma ocorrência em particular de um atributo dentro de uma entidade é chamada de valor de atributo. Na Figura 1, eles são representados de duas formas: na notação Barker, eles aparecem descritos dentro do construtor da entidade, logo abaixo do nome dela; na notação Chen, seus construtores são retângulos com bordas arredondadas, com o nome do atributo em seu interior e uma linha que o conecta à sua entidade correspondente. Um atributo pode ser caracterizado como descritor ou identificador (chave).
· Chave: um identificador (ou chave) é usado para determinar exclusivamente uma instância de uma entidade. Essa chave pode ser composta de um único atributo (chave simples) ou por um conjunto de atributos (chave composta). Uma entidade pode ter mais de uma chave e, nesse caso, esse conjunto é denominado de chaves candidatas. Dentro da relação de chaves candidatas, elege-se uma que será utilizada como indexador exclusivo de cada instância da entidade. Essa chave recebe o nome de chave primária. Na Figura 1, as chaves são representadas como um atributo sublinhado (notação Chen) ou como um atributo com o símbolo “#” à sua esquerda (notação Barker).
Figura 1. Construtor para entidade nas notações Barker e Chen
· Entidade fraca: um tipo de entidade que não possui um identificador próprio, mas deriva sua identidade a partir dos atributos identificadores de uma ou mais “entidades-pai”, de quem é dependente para sua própria existência. Na Figura 2, temos a representação gráfica de uma entidade fraca na notação Chen. Ela é representada como um retângulo de borda dupla. Percebam, no exemplo apresentado, que a chave da entidade “sala” (“num_sala” + “id_edificio”) é derivada da chave da entidade “edifício” (“id_edificio”), tendo em vista que uma sala não tem uma identidade separada de seu edifício, pois está contida fisicamente nele.
Figura 2. Construtor para entidade fraca na notação Chen
· Relacionamentos: representam associações do mundo real entre uma ou mais entidades e, dessa forma, não possuem existência física. Eles apenas conceituam as dependências que existem entre as entidades associadas. Na Figura 3, observamos que na notação Barker ele é uma linha que conecta as entidades associadas, com o nome do relacionamento aparecendo logo acima dessa linha. Na notação Chen, seu construtor é um losango conectando as entidades associadas, com o nome do relacionamento em seu interior.
Figura 3. Construtor para relacionamentos nas notações Barker e Chen
Os relacionamentos podem ser descritos em função de sua conectividade e participação:
· Conectividade: descreve uma restrição sobre a conexão das ocorrências de entidade associadas no relacionamento. Os valores para conectividade são “um” ou “muitos”. A contagem real de elementos associados à conectividade do relacionamento é chamada de cardinalidade, mas esse conceito é usado com menos frequência do que a conectividade, pois os valores reais variam entre as instâncias do relacionamento.
A Figura 4 mostra os construtores básicos de conectividade em relacionamentos. Eles podem ser “um-para-muitos”, “um-para-um” e “muitos-para-muitos”. Na notação Barker, o lado “um” é representado por uma extremidade de linha simples conectando-se a uma entidade, enquanto o lado “muitos” aparece como uma extremidade com ramificações conectada à entidade, sendo que essa representação ramificada é conhecida como “pé-de-galinha”. Na notação Chen, o lado “um” possui o número um aparecendo na conexão entre a entidade e o relacionamento, enquanto o lado “muitos” possui a letra “N” na conexão entre o relacionamento e a entidade.
Figura 4. Construtores para conectividade de relacionamentos nas notações Barker e Chen
Analisando os exemplos da Figura 4, e com as definições apresentadas até agora para a representação de conectividade, podemos dizer que no exemplo da primeira linha da figura, um “Departamento” possui um ou muitos “Funcionários”, enquanto que um “Funcionário” deve pertencer a pelo menos um e somente um “Departamento”. Na segunda linha da figura, um “Departamento” é gerenciado por pelo menos um e somente um “Funcionário”, enquanto que um “Funcionário” pode gerenciar apenas um “Departamento”. No exemplo da terceira linha da figura, um “Funcionário” pode trabalhar em um ou vários “Projetos”, enquanto que um “Projeto” pode ter um ou muitos “Funcionários” trabalhando nele.
· Participação: a participação de uma instância de entidade em um relacionamento é definida como obrigatória ou opcional. Se uma instância de entidade sempre tiver de participar do relacionamento para que ela exista, então sua participação é obrigatória. Se, por outro lado, uma instância dessa entidade nem sempre precisar participar do relacionamento, ela é considerada opcional.
A Figura 5 exibe exemplos de representação para a participação de uma entidade em relacionamentos. Em [1], temos a representação de uma participação opcional, enquanto que em [2], temos uma participação obrigatória. Na notação Barker, o lado opcional é representado por uma extremidade de linha pontilhada conectando-se a uma entidade, enquanto o lado obrigatório possui uma extremidade com linha contínua. Na notação Chen, o lado opcional possui um círculo vazado na linha de conexão entre a entidade e o relacionamento, enquanto o lado obrigatório possui uma linha contínua na conexão entre o relacionamento e a entidade.
