Esse artigo faz parte da revista SQL Magazine edição 61. Clique aqui para ler todos os artigos desta edição
isso, utilizaremos um estudo de caso hipotético, que consiste na criação de um sistema de controle de orçamentos. Este sistema permite a inclusão de um orçamento mensal que é composto por contas de receita e despesa. Estas contas são definidas pelo usuário e classificadas em grupos e subgrupos que geram o plano de contas do sistema. Além do orçamento mensal, todos os recebimentos e pagamentos são lançados diariamente e vinculados à conta cadastrada no plano de contas. Desta forma, têm-se a possibilidade de análise do previsto através do orçamento mensal e da análise do que efetivamente foi realizado através dos lançamentos diários nas contas.
Para a construção do modelo de dados, seguiremos uma metodologia de desenvolvimento composta pelas etapas de: levantamento de dados, definição de entidades e associações, definição de atributos e identificadores, criação do modelo conceitual, definição das cardinalidades e, por fim, a criação do modelo lógico de dados.
Modelo Conceitual
Um modelo conceitual descreve a estrutura do banco de dados sem preocupar-se com o Sistema Gerenciador de Banco de Dados (SGBD) que será utilizado. Este modelo expressa quais dados aparecerão em um Banco de Dados (BD), e não como estes estão armazenados. Normalmente ele é usado para se representar todo o conjunto de informações disponíveis em um BD a ser projetado.
Considerado como um padrão para a modelagem conceitual, o modelo Entidade-Relacionamento (comumente chamado de modelo ER) foi criado por Peter Chen em 1976 é ainda hoje serve como base para vários modelos, inclusive modelos orientado a objetos. Ele percebe o mundo como sendo um conjunto de entidades e relações entre estas. Uma entidade nada mais é do que a representação de algum fato ou componente de um sistema. Usualmente, suas propriedades são representadas graficamente através de um Diagrama Entidade-Relacionamento (DER), onde os retângulos representam as entidades e os losangos interligados por linhas representam as associações. O relacionamento entre as entidades a partir destas associações caracteriza uma instância ou ocorrência de relacionamento. A identificação de uma instância de relacionamento entre as entidades é gerada a partir da utilização do atributo identificador. A Figura 1 apresenta todos os elementos e símbolos que compõem um diagrama de ER.
Figura 1. Símbolos Utilizados no DER
O número de ocorrências de determinada entidade que podem estar associadas a ocorrências de outra entidade chama-se cardinalidade. Devemos considerar dois tipos de cardinalidade: a mínima e a máxima. Conforme representado na Figura 1, a cardinalidade mínima é “0” (zero) e a cardinalidade máxima é “n”.
Após a definição das cardinalidades, temos como identificar se a entidade é forte ou fraca. Quando esta for fraca, a linha de ligação aparece em destaque (mais forte) conforme representado na Figura 1. Para melhor compreender o uso de cardinalidades e da definição de entidade forte ou fraca, vejamos o exemplo a seguir:
O domínio deste exemplo é a relação entre entidades Cliente e Compra, onde a cardinalidade mínima entre elas é “0” (zero) e a máxima “n”. Pela cardinalidade mínima, podemos afirmar que uma ocorrência de Cliente não obrigatoriamente precisa estar associada a uma ocorrência da entidade Compra. Pela cardinalidade máxima, podemos afirmar que várias ocorrências (um número máximo, porém não conhecido de ocorrências) da entidade Cliente podem estar relacionadas à entidade Compra.
Simplificando, podemos dizer que podem ser cadastrados clientes sem a obrigatoriedade destes terem registro de compra – também conhecida como associação opcional da entidade Cliente. Por outro lado, podemos dizer que cada compra possuirá no máximo um cliente. Como a entidade Compra depende de obrigatoriamente de uma ocorrência na entidade Cliente, dizemos que a entidade Compra é a entidade fraca, como observado na Figura 2.
Figura 2. Exemplo de Diagrama ER
Ao desenvolvermos o DER, temos uma melhor visão das relações existentes entre as entidades e desta forma facilita-se a construção do modelo lógico. Entretanto, para melhor compreendermos esta afirmação, vejamos a seguir algumas definições e características de qualquer modelo lógico de BD.
Modelo Lógico
O modelo lógico se preocupa em representar a estrutura dos dados e suas relações em um BD. Ele consiste em criar uma abstração da realidade do BD, enfatizando os objetos que dele pertencem, as relações entre estes objetos e os dados que serão armazenados.
Diferente do modelo conceitual que cria uma abstração da realidade voltada ao projeto do BD, o modelo lógico possui uma representação mais próxima da utilizada pelos SGBDs e, portanto, mais conhecida. Desta forma, muitos desenvolvedores criam os modelos lógicos de dados diretamente nestes. Entretanto, focar apenas no SGBD poderá limitar consideravelmente a percepção das relações e dados que deverão fazer parte do BD, e por isso o desenvolvimento do modelo conceitual é tão importante, pois foca apenas no propósito do BD sem considerar o SGBD que será utilizado.
A maioria dos SGBDs utiliza-se de arquiteturas de Banco de Dados Relacionais (BDR), mas uma outra possibilidade seria o uso de Banco de Dados Orientados a Objetos (ver Nota DevMan 1). A arquitetura de um banco de dados relacional é constituída por objetos chamados de tabela e suas relações com as demais em um mesmo BD, constituindo o modelo lógico chamado de Modelo Relacional (MR). Aqui, percebemos claramente a relação do modelo lógico com o modelo conceitual, pois as entidades nada mais são do que as possíveis tabelas de um MR, e suas associações, as associações do MC.
Nota DevMan 1. Banco de Dados Orientado a Objetos
Definição
Um banco de dados orientado a objetos é um banco de dados em que cada informação é armazenada na forma de objetos. O gerenciador de banco de dados que considera a orientado a objeto é referenciado por vários como ODBMS ou OODBMS.
Existem dois fatores principais que levam à adoção da tecnologia de banco de dados orientados a objetos. A primeira, é que em um banco de dados relacional a manipulação de dados complexos é difícil. Segundo, os dados são geralmente manipulados pela aplicação escrita usando linguagens de programação orientada a objetos, como C++, C#, Java, e o código precisa ser traduzido entre a representação do dado e as linhas da tabela relacional, o que além de ser uma operação tediosa de ser escrita, consome tempo.
Recursos Técnicos
Num banco de dados orientado a objetos puro, os dados são armazenados como objetos onde só podem ser manipulados pelos métodos definidos pela classe que estes objetos pertencem. Os objetos são organizados numa hierarquia de tipos e subtipos que recebem as características de seus supertipos. Os objetos podem conter referências para outros objetos, e as aplicações podem conseqüentemente acessar os dados requeridos usando um estilo de navegação de programação.
A maioria dos bancos de dados também oferece algum tipo de linguagem de consulta, permitindo que os objetos sejam localizados por uma programação declarativa mais próxima. Uma tentativa de padronização foi feita pela ODMG (Object Data Management Group) com a OQL (Object Query Language).
O acesso aos dados pode ser rápido porque as junções não são geralmente necessárias (como numa implementação tabular de uma base de dados relacional). Isto porque um objeto pode ser obtido diretamente sem busca, seguindo os ponteiros.
As tabelas são compostas por campos que armazenam os dados destas tabelas. Ao conjunto dos dados, oriundos de todos os campos de uma tabela, dá-se o nome de registro. A chave primária é constituída de um ou mais campos que identificam uma única ocorrência de registro. Uma chave estrangeira é um campo originado da necessidade da relação entre as tabelas. A chave estrangeira é a chave primária da tabela origem de uma determinada relação.
Após a construção do modelo conceitual, é feita a conversão para o MR. As entidades são convertidas em tabelas, os atributos em campos e os identificadores em chaves-primárias.
As chaves-estrangeiras são geradas a partir do identificador da entidade forte ao qual uma entidade fraca se relaciona. No caso do exemplo da Figura 2, o identificador de Cliente (CPF) que seria chave-primária da tabela Cliente, quando da conversão para modelo lógico seria repassada à tabela Compra como chave-estrangeira.
Conforme representado na Figura 3, temos um modelo conceitual com duas entidades (Acadêmico e Avaliação) e uma associação com cardinalidade do tipo n:n entre elas. Neste tipo de relação (n:n), temos o que chamamos de entidade associativa gerada a partir da associação (como indica seu nome) entre as entidades. Quando não existir uma entidade forte, nesta relação ambas entidades irão ceder seus identificadores para a entidade associativa. ...
