Modelo Conceitual de Dados - Aprenda a utilizar os principais mecanismos de abstração.

"Neste artigo Bergson Lopes apresenta para os leitores os principais mecanismos de abstração utilizados para construir um Modelo Conceitual de Dados".

Conforme mencionado no artigo anterior, a finalidade do modelo conceitual de dados é capturar os requisitos de informação e regras de negócio sob o ponto de vista do negócio. Para isto, torna-se necessário o entendimento e a correta aplicação dos mecanismos de abstração, utilizados na modelagem conceitual de dados.

Durante a leitura deste artigo o leitor entrará em contato com os principais conceitos e técnicas para construção de um modelo conceitual de dados.

Elementos Estruturais de um Modelo Conceitual de Dados

1 - Entidades

Formam um conjunto de “coisas” com conceitos comuns às quais desejamos armazenar os dados.

Entidades podem ser pessoas, lugares, organizações, objetos físicos e tangíveis.

As entidades são representadas através de um retângulo com o nome da entidade escrito em seu centro. Conforme figura a seguir, as entidades são classificadas em dois tipos: Entidades Fortes e Entidades Fracas.

Figura 1 - Notação de Entidade Forte x Entidade Fraca

As entidades fortes possuem um alto grau de independência de existência de identificação. Geralmente, outras entidades podem depender dela para serem identificadas. Podemos tomar como exemplo a entidade “BANCO”, onde a existência da mesma não depende de nenhuma outra entidade para ser identificada.

As entidades fracas possuem dependência de existência e/ou identificação. São sempre ligadas a outras tabelas através de relacionamentos. Podemos tomar como exemplo a entidade “AGENCIA”, onde a existência e identificação da mesma estão vinculadas a outra entidade forte, no caso o “BANCO”.

2 - Relacionamentos

Relacionamentos são associações entre entidades com um significado específico dentro do mundo real. Os objetos do mundo real não ocorrem de forma isolada, eles se associam ou se vinculam.

A figura de um relacionamento é representada através de um losango, tal como as entidades os relacionamentos são classificados em fortes ou fracos. Tal como as entidades, os relacionamentos também possuem nome e devem expressar o real significado dentro do contexto modelado. A figura a seguir mostra como os relacionamentos são representados em um modelo conceitual de dados.

Figura 2 - Notação de Relacionamento Forte e Relacionamento Fraco

Na figura acima DEPENDENTE é uma entidade fraca em relação ao EMPREGADO, sempre que esta relação existir de forma fraca, o relacionamento também será fraco, por esta razão o losango desta relação está representado com uma linha dupla. Já na relação entre EMPREGADO e CARGO não há dependência de existência ou identificação, pois um CARGO não depende de um EMPREGADO para existir e ser identificado e vice-versa.

Quando tratamos de relacionamentos, devemos ter em mente três conceitos importantes que influenciam diretamente na modelagem e entendimento de um modelo conceitual. Os conceitos são o grau, cardinalidade e tipo do relacionamento.

Grau dos Relacionamentos

O grau de um relacionamento corresponde ao número de entidades envolvidas na mesma relação. O grau de um relacionamento pode ser:

Binário: Onde duas entidades participam de um relacionamento. Este é o grau utilizado na maioria dos relacionamentos.

Ternário: Onde três entidades participam de um relacionamento. Muito se discute sobre o uso e aplicabilidade de relacionamentos com grau maior que dois (ternários e n-ários) em modelos de dados. Alguns autores sugerem inclusive que esses relacionamentos não sejam adotados.

N-ário: Onde quatro ou mais entidades participam de um relacionamento.

A figura a seguir mostra exemplos comuns de graus de relacionamentos.

Figura 3 - Grau dos Relacionamentos em Modelos Conceituais

Cardinalidade

A cardinalidade representa a quantidade de vezes que um elemento de um conjunto de entidades pode, em um determinado instante, estar associado em um dado relacionamento, a outros elementos de outras entidades.

A cardinalidade de uma relação é definida em cada um dos sentidos do relacionamento por um conjunto (x,y) onde x representa a cardinalidade mínima e y representa a cardinalidade máxima.

A cardinalidade mínima é responsável por orientar a obrigatoriedade (opcionalidade) do relacionamento. Já a cardinalidade máxima é responsável por definir a quantidade máxima de vezes que um elemento pode estar associado no relacionamento.

Até agora, por fins didáticos, a cardinalidade não estava sendo representada nos exemplos deste artigo, porém vale a pena destacar que seu uso é obrigatório, pois as cardinalidades refletem regras que obrigatoriamente devem ser representadas em um modelo conceitual de dados.

A figura a seguir mostra um exemplo de uso das cardinalidades em um relacionamento dentro de um modelo conceitual de dados.

Figura 4 – Exemplo do uso de Cardinalidade nos Relacionamentos

No exemplo acima, um EMPREGADO trabalha em uma e somente uma EMPRESA e, em uma EMPRESA trabalham nenhum ou vários EMPREGADOS. Ou seja, dentro do contexto que foi modelado, é impossível existir um EMPREGADO sem uma EMPRESA associada, porém é totalmente viável criar uma EMPRESA e não associar inicialmente algum EMPREGADO.

Tipos de Relacionamentos

O simples fato de associar duas entidades através de um relacionamento com suas cardinalidades às vezes não são suficientes para representar todas as regras de negócio existentes dentro dessas relações.

Para isto, podemos usar mecanismos de representação um pouco mais detalhados. Sob esta ótica, podemos ainda classificar os relacionamentos em três tipos:

• Relacionamentos independentes;

• Relacionamentos Contingentes;

• Relacionamentos mutuamente exclusivos.

Relacionamentos Independentes:

Tipo de relacionamento presente na maioria das relações. Não há necessidade de interpretação simultânea de outro relacionamento. Ou seja, é independente, não depende de ninguém para existir ou influenciar o seu comportamento.

Relacionamentos Contingentes:

Estabelecem associações simultâneas entre os elementos envolvidos. Ou seja, mais de um relacionamento deve ocorrer em um mesmo instante.

Sua representação é recomendada, pois envolvem regras de negócio específicas que se não mapeadas neste momento, fatalmente serão esquecidas mais adiante no decorrer do projeto.

A figura a seguir mostra um exemplo de relacionamento contingente.

Figura 5 - Exemplo de Relacionamento Contingente

No exemplo acima é impossível alocar empregados em um projeto sem um gerente definido e também não é possível definir um gerente para um projeto sem existir empregados alocados no projeto. Ou seja, os dois relacionamentos devem ocorrer no mesmo instante.

Relacionamentos Mutuamente Exclusivos:

Estabelecem associações onde, se um relacionamento ocorre, os outros não deverão ocorrer em relação a um determinado objeto.

Sua representação é recomendada, pois envolvem regras de negócio específicas que se não mapeadas neste momento, fatalmente serão esquecidas mais adiante no decorrer do projeto.

A figura a seguir mostra um exemplo de relacionamento mutuamente exclusivo.

Figura 6 – Exemplo de relacionamento mutuamente exclusivo

O exemplo acima reflete um exemplo onde uma obra é gerida por uma Empresa Privada ou por uma Unidade Federativa ou por um Município. Ou seja, três tipos de entidades podem gerir uma obra, porém somente uma é a entidade gestora.

3 - Atributos

Os atributos são informações que caracterizam as entidades e os relacionamentos. Um atributo pode: identificar, descrever, qualificar, quantificar ou registrar o estado/situação/ocorrência de uma entidade.

No modelo conceitual são representados através de “pirulitos” colocados juntos as entidades.

Os atributos podem ser classificados em quatro tipos:

Atributo identificador: Representado através de uma bola cheia na extremidade do atributo. Atributos identificadores identificam ou compõe a identificação única de uma ocorrência em uma entidade. Vale ressaltar que uma entidade e/ou relacionamento pode possuir mais de um atributo identificador, desde que os mesmos em conjunto componham a identificação única.

Atributo não identificado: Representado através de uma bola vazia na extremidade do atributo. Corresponde a maioria das ocorrências de uma entidade. Além disso, atributos não identificados podem ser opcionais, ou seja, em algumas instâncias de entidade, alguns atributos poderão conter valores nulos.

Atributos multivalorados: Representado através de uma flor ou asterisco na extremidade do atributo.

Atributos multivalorados são utilizados para representar mais de uma ocorrência de valor de um atributo dentro de uma mesma instância de uma entidade. Exemplo: Geralmente, uma pessoa possui mais de um número de telefone. Como o objetivo do modelo conceitual é capturar a essência do negócio sem levar em conta aspectos de implementação, este tipo de abordagem é utilizado para representar todas essas instâncias em um único atributo, porém deve-se ter em mente que este tipo de abordagem não deve ser utilizado a partir da modelagem lógica de dados, onde entrarão em cena os conceitos de normalização.

Atributos compostos: Representados através de uma oval com vários nós na extremidade do atributo.

Atributos compostos são utilizados para representar mais de um tipo de informação (qualificação) em um atributo. Tal como o atributo multivalorado, seu uso é recomendado somente no modelo conceitual de dados.

A figura a seguir, mostra os tipos de atributos utilizados em um modelo conceitual de dados.

Figura 7 - Notações utilizadas em atributos

O exemplo acima representa atributos comuns aos alunos de qualquer instituição: o número da matrícula é um atributo identificador, o nome do aluno é um atributo não identificador. Já o atributo telefones é um atributo multivalorado, onde representa os diversos telefones que um aluno possui. Endereço é considerado um atributo composto, pois é formado pela composição da UF, Cidade e Logradouro.

Mecanismos avançados de abstração utilizados em um Modelo Conceitual de Dados

Os mecanismos avançados de abstração são excelentes recursos para melhorar o entendimento e representação dos modelos de dados. Alguns mecanismos como o auto relacionamento já são bastante utilizados pelos técnicos que produzem os modelos de dados. As seções a seguir irão detalhar e mostrar exemplos de como esses mecanismos são utilizados.

1 - Repetição

Existem situações em que uma mesma instância de uma entidade pode selecionar com outra mesma instância de outra entidade várias vezes.

A repetição permite representar as regras de negócio que expressam a quantidade de instâncias de relacionamentos que podem ser estabelecidos entre os mesmos elementos das entidades participantes de um relacionamento.

Quando trabalhamos com o mecanismo de Repetição, é obrigatória a existência de um atributo identificador no relacionamento onde ocorre a repetição.

A repetição é indicada no modelo através de um número que indica quantas vezes uma mesma instância de uma entidade pode se relacionar com outra instância mais de uma vez em outra entidade. Se o número de vezes for indefinido utiliza-se a letra “N”.

A figura a seguir mostra um exemplo de uso do mecanismo da Repetição.

Figura 8 - Exemplo do uso da Repetição em um MCD

No exemplo acima temos a representação de um relacionamento onde são registrados os cartões (amarelo ou vermelho) recebidos pelos jogadores de futebol em uma partida. Conforme regra vigente, um jogador não pode receber 2 cartões amarelos em uma mesma partida. Se isto acontecer, o segundo cartão amarelo é convertido em vermelho e ele é automaticamente expulso da partida. O número 2 colocado em cima do relacionamento “punição” representa esta regra.

2 - Auto Relacionamento

O auto relacionamento, também conhecido como relacionamento recursivo representa a associação entre elementos pertencentes à mesma entidade.

Em um auto relacionamento temos sempre dois papéis formados pelos elementos de uma entidade. A representação desses papéis é obrigatória e fundamental para o entendimento do modelo. De forma geral, prefiro utilizar um substantivo para nomear o relacionamento e verbos ou expressões verbais para nomear os papéis.

Geralmente, utilizamos um auto relacionamento quando:

1- Desejamos representar estruturas hierárquicas dentro da mesma entidade. Este tipo de representação sempre utilizará uma cardinalidade (0,1) x (0,N). A figura a seguir mostra um exemplo de utilização de um auto relacionamento com essas características.

Figura 9 - Exemplo do uso de um auto relacionamento para representar uma hierarquia

Conforme exemplo da figura acima, conseguimos montar uma estrutura de rede hierárquica de empregados dentro de uma empresa.

2 - Desejamos representar estruturas similares a composições com a mesma entidade. Este tipo de representação sempre utilizará uma cardinalidade (0,N) x (0,N). A figura a seguir mostra um exemplo de utilização de um auto relacionamento com essas características.

Figura 10 - Exemplo de um auto relacionamento para representar uma composição

Conforme exemplo da figura acima, conseguimos montar uma estrutura que forma uma composição de materiais. O relacionamento composição será responsável por armazenar essas informações. Para ilustrar esta relação com exemplos reais, podemos imaginar que a entidade MATERIAL armazena todos os itens materiais de um carro. O relacionamento “composição” será responsável por montar a composição desses materiais. No caso de um carro, existirá várias instâncias de materiais dentro da entidade MATERIAL, inclusivo o material “motor”. O “motor” por sua vez é formado por vários materiais de menor porte e diversas quantidades. Por esta razão foi colocado o atributo quantidade dentro do relacionamento.

3 - Generalização e Especialização

Existem situações onde precisamos representar entidades comuns com um maior ou menor grau de propriedades em cada uma, sempre mantendo uma visão hierárquica entre essas entidades. Dependendo da situação, podemos utilizar a Generalização ou a Especialização.

A consiste em criar um conceito superior para as entidades existentes, mantendo uma relação de hierarquia de entidade entre a nova entidade (entidade pai) e as entidades já existentes (entidades filhas). A figura abaixo demonstra um exemplo de uso do mecanismo de generalização.

Figura 11 - Uso da Generalização em um Modelo Conceitual

Já a Especialização consiste em criar novos conceitos (entidades filhas) a uma entidade já existente, mantendo uma relação de hierarquia das novas entidades com a entidade pai (já existente). A figura a seguir demonstra um exemplo de uso do mecanismo de especialização.

Figura 12 - Uso da Especialização em um MCD

Quando trabalhamos com mecanismos de Generalização / Especialização utilizamos regras de negócio que representam condições envolvendo especialização. A essas condições damos o nome de cobertura.

A cobertura é representada do lado da seta que indica a especialização / generalização por um par de valores (X,Y) onde X representa o conteúdo e Y representa a cobertura.

O valor de conteúdo pode ser representado pelas letras T e P onde:

T = Conteúdo Total (Toda instância de um elemento “E” deve pertencer também a uma instância em uma entidade filha especializada).

P = Conteúdo Parcial (Pode existir uma instância do elemento “E” que não pertença às entidades especializadas)

O valor de cobertura pode ser representado pelas letras E e S onde:

E = Cobertura Exclusiva (Toda instância do elemento “E” pode existir no máximo em uma instância nas entidades especializadas).

S = Cobertura Sobreposição (Toda instância do elemento “E” pode existir em várias instâncias das entidades especializadas).

4 - Agregação

A agregação é um mecanismo de abstração onde criamos um novo conceito a partir dos componentes de uma relação. Usamos a agregação quando sentimos a necessidade de associar um relacionamento ao outro. A figura abaixo mostra um exemplo de uso de uma agregação.

Figura 13 - Exemplo do uso da agregação em um MCD

No exemplo acima, foi necessário criar um conceito mais abrangente para poder representar o consumo de um cliente hospedado em um quarto. Vale ressaltar que, quando utilizamos a agregação, as relações são dependentes. Ou seja, a associação da entidade agregada com a outra entidade só ocorre após a existência do fato (relação) da entidade agregada. No caso, o cliente só poderá consumir serviços, após estar hospedado em um quarto.

Quais os próximos passos?

Conforme comentado no início deste artigo, a finalidade do modelo conceitual de dados é capturar os requisitos de informação e regras de negócio sob o ponto de vista do negócio. Este trabalho pode ser concluído aqui, caso a demanda não esteja associada a um desenvolvimento de aplicação ou seguir adiante com o mapeamento do modelo conceitual de dados para o modelo lógico de dados.

Um modelo lógico de dados é considerado um modelo de dados implementável. Ao contrário do modelo conceitual que tem como principal objetivo representar o contexto do negócio, o modelo lógico de dados já procura estabelecer soluções de implementação em bancos de dados, claro que respeitando os requisitos de informação e regras de negócio representadas no modelo conceitual.

De forma geral, recomenda-se que o modelo lógico de dados seja criado a partir do mapeamento do modelo conceitual de dados e, a partir daí, começa-se um trabalho de refinamento para projetar o melhor modelo implementável. Um modelo lógico de dados também pode ser construído a partir do zero, porém toda a questão da participação do cliente/usuário no início da modelagem e a captura do ambiente de negócios poderão ser comprometidas, tornando a solução de modelagem vulnerável a erros de conceito e adequação ao negócio.

Gostou do artigo? Envie seus comentários para bergson@blrdata.com.br

Até o próximo!