Classes

Atributos

Na modelação de dados, para além de identificarmos as entidades envolvidas, temos de identificar também, para cada entidade, os seus atributos.

Por exemplo, a entidade Cliente pode ter vários atributos: nome, morada, nif, telefone, etc..

Para além disso, temos de definir o domínio de cada atributo. O domínio de um atributo é o conjunto dos valores possíveis que esse atributo pode assumir.

Há domínios que são constituídos por Strings (nome, morada, etc..), outros são valores numéricos (preço, idade, etc.. ), outros são datas, etc..

Classes

Ao adicionarmos os atributos e respetivos domínios a uma entidade, estamos a transformar as entidades em classes.

As classes na Modelação de Dados, derivam das classes da Programação Orientada a Objetos, sendo os atributos as suas propriedades e os respetivos domínios os tipos de dados dos atributos.

Uma classe na Modelação de Dados representa-se como na Programação Orientada a Objetos (como o Java, por exemplo): um retângulo com o nome da classe no topo e os atributos no corpo do retângulo.

Uma classe representa uma coleção de objetos, por exemplo, a classe Produto representa todos os produtos.

Portanto, as entidades dão origem às classes ao acrescentarmos-lhes os atributos, e os Diagramas ER dão origem ao Diagrama de Classes.

Diagramas de classes

Os Diagramas de Classes são uma evolução dos Diagramas ER, com conceitos provenientes da Programação Orientada a Objetos (POO).

Nos Diagramas de Classes, as classes darão origem às tabelas da base de dados e os seus atributos dão origem às colunas de cada tabela. Os domínios dos atributos darão origem aos tipos de dados das colunas.

Os relacionamentos existentes no Diagrama ER mantêm-se quando estes evoluem para Diagramas de Classes.

Relacionamentos quanto ao número de classes envolvidas

Nos Diagramas de classes, tal como nos Diagramas ER classificam-se as relações quanto ao número de classes envolvidas.

Assim temos:

  • Relacionamentos unários
  • Relacionamentos binários
  • Relacionamentos de ordem superior (incluem-se os ternários)

Relacionamentos unários

Este é o caso em que uma classe se relaciona com ela mesmo ou, dito de outra forma, os objetos desta classe se relacionam uns com os outros.

Por exemplo, entre os funcionários de uma empresa, a relação “A é chefe de B” ou “B é chefiado por A” é um caso de relacionamento unário.

Relacionamentos binários

Este é o caso mais comum nas relações entre classes. O relacionamento passa-se entre duas classes.

Exemplos:

  1. A relação entre os fornecedores e os produtos que uma empresa compra.
  2. A relação entre esses produtos e os clientes a quem a empresa os vende.

Relacionamentos de ordem superior

Quando uma relação envolve, ao mesmo tempo, três ou mais classes no mesmo relacionamento dizemos que se trata de um relacionamento de ordem superior.

No caso particular de serem 3 as classes envolvidas dizemos que se trata de um relacionamento ternário.

Por exemplo, numa escola, os alunos frequentam disciplinas e estão organizados em turmas.

Entre Aluno, Disciplina e Turma existe uma relação do tipo ternário.

Tipos de relacionamentos quanto à cardinalidade

A cardinalidade de uma relação diz respeito à quantidade de objetos de uma classe em relação a outra mas diz também respeito à questão da obrigatoriedade ou não da participação.

Consideremos, por exemplo, as classes Fornecedor e Produto e a relação “fornece” existente entre elas.

Nos diagramas de classes, quando se um relacionamento, deve ter-se em conta o seguinte:

A classe de onde parte o relacionamento é a classe-origem.

A classe para onde se dirige o relacionamento é a classe-alvo.

Nos diagramas de classes a questão da multiplicidade de um relacionamento coloca-se em saber quais as quantidades mínima e máxima de ocorrências possíveis da classe-alvo em relação à classe-origem.

Quanto à quantidade mínima, ela pode ser 0 ou 1.

Quanto à quantidade máxima, ela pode ser 1 ou vários.

No exemplo entre Fornecedor e Produto, a questão é a seguinte: qual o mínimo e máximo de produtos (classe-alvo) que um fornecedor (classe-origem) pode fornecer ?

Quanto à quantidade mínima – um fornecedor pode fornecer 0 (zero), ou terá de fornecer, no mínimo, um produto ?

Quanto à quantidade máxima – um fornecedor só pode fornecer, no máximo, um produto ou pode fornecer vários ?

O indicativo de multiplicidade de um relacionamento coloca-se junto à classe-alvo e tem sempre dois símbolos: 0..1 (zero ou um); 1..1 (um e só um); 0..* (zero ou vários); 1..* (1 ou vários).

No quadro abaixo podem ver-se, detalhadamente, os símbolos usados:

Nos indicativos de multiplicidade usados no diagramas de classes já está explícito se a participação de uma classe no relacionamento é ou não obrigatória:

  • Se o primeiro dígito é 0 (zero) a participação é opcional.
  • Se o primeiro dígito é 1 (um) a participação é obrigatória.

Voltando ao exemplo do Fornecedor e do Produto, podemos ter situações consoante as determinações da empresa em causa.

Suponhamos que cada fornecedor pode fornecer 0 ou vários produtos. Neste caso, a participação é opcional e o diagrama terá o indicativo 0..* junto à classe Produto.

Mas também podemos admitir que cada fornecedor tem obrigatoriamente de fornecer pelo menos um produto, podendo fornecer vários.

Neste caso, a participação é obrigatória e o diagrama terá o indicativo 1..* junto à classe Produto.

Agora, coloquemos a questão inversa: para cada produto quantos fornecedores pode haver ? De igual modo, temos de saber as quantidades mínima e máxima.

Neste caso, podem ocorrer todas as situações possíveis:

0..1 – Cada produto pode ser fornecido por 0 (zero) ou, no máximo, um fornecedor.

1..1 –  Cada produto é fornecido por um e um só fornecedor.

0..* – Cada produto pode ser fornecido por 0 (zero) ou vários (*) fornecedores.

1..* – Cada produto pode ser fornecido por um ou vários (*) fornecedores.

Consideremos o seguinte diagrama:

A leitura deste diagrama será assim:

  • Cada fornecedor pode fornecer 0 ou vários produtos.
  • Cada produto é fornecido por um e um só fornecedor.