O correto entendimento de uma informação depende muito da condição de interpreta- ção dos fatos e da determinação da inerência do dado pelo analista de sistemas.
O saber interpretar o que um dado caracteriza, ou a quem esse dado se refere é de suma importância para o resultado correto do modelo de dados.
Vamos então analisar uma situação em que poderíamos ter interpretações errôneas da verdadeira caracterização que um dado efetua.
Em uma determinada empresa são realizados diversos projetos de engenharia que alocam os funcionários disponíveis de seu quadro funcional conforme a necessidade, ficando esses funcionários alocados a somente um projeto até o seu encerramento.
Uma vez alocado o funcionário a um determinado projeto, deve ser registrada a data de início de suas atividades no projeto, assim como o tempo em meses que ele vai ficar alocado. O modelo ER que representa este fato é o apresentado na figura seguinte.
Interpretando, ou melhor, lendo o diagrama que exprime o modelo de dados temos: Um funcionário é alocado a um projeto e um projeto aloca muitos funcionários. Surge agora no tocante aos dois dados antes referidos, data de início e tempo de alocação, a dúvida de sua caracterização. Esses dados são inerentes ao fato alocação, logo são campos, dados do relacionamento alocado.
Não, esta afirmativa está errada.
Seriam de fato, se um funcionário fosse alocado a mais de um projeto, mas como um funcionário é alocado a um projeto somente, esses dados são informações inerentes ao funcio- nário, pois possuem uma única existência para cada ocorrência de funcionário, que esteja relacionado com o projeto.
Da mesma forma que na entidade funcionário, para que se estabeleça o relacionamento com a entidade projeto, necessitamos do atributo Código_do_Projeto em sua estrutura.
Temos assim a seguinte estrutura de dados:
Entidade Atributos Relacionamento
Funcionário
Matrícula do Funcionário Nome do Funcionário
Endereço Código do Projeto (FK) Data de Início no Projeto Tempo Previsto de Alocação
Aloca N:1
Projeto Código do Projeto
Nome do Projeto Aloca 1:N
Utilizamos o padrão FK (foreign key) para indicar uma chave estrangeira.
Se a realidade colocada em análise fosse a de que um funcionário estivesse alocado a muitos projetos, ela seria uma informação do relacionamento entre funcionário e projeto, já que para cada associação do funcionário com um projeto teríamos esses dados para caracterizá-la. Veremos mais adiante um estudo desse tipo de relacionamento.
A figura seguinte exibe o diagrama de instâncias para o relacionamento um-para-muitos entre funcionário e projeto.
Propositalmente, colocamos no diagrama de instâncias ocorrências em ambas as entidades, que não participam de nenhum relacionamento, ou seja, não estão relacionadas.
O funcionário F7 não está alocado a nenhum projeto, assim como os projetos P4 e P2 não possuem nenhum funcionário alocado.
Queremos dizer com isso que a condicionalidade, ou melhor, a opcionalidade de um relacionamento tem também o seu grau de importância no contexto, pois permite que uma ocorrência de projeto seja inserida na entidade projeto sem que exista a necessidade, a obrigatoriedade de já possuir funcionários alocados antecipadamente, assim como a inserção de uma ocorrência em funcionário sem que ela esteja previamente relacionada com uma ocorrência em projeto.
Na vida real, esta situação ocorre exatamente desta forma, pois em 99% dos casos em análise e projeto, os relacionamentos são obrigatoriamente condicionais no mínimo para um dos lados do relacionamento.
Que existem ocorrências de funcionários que não estão alocados a nenhum projeto é fato concreto, mas como podemos visualizar este fato?
Uma característica para efetivação lógica de um relacionamento um-para-muitos é o fato de ele necessitar da existência de chave estrangeira em uma das entidades.
Tomamos como regra geral que sempre que existir um relacionamento com cardinalidade de um-para-muitos, a referência lógica (chave estrangeira) estará colocada na entidade que possui o lado muitos da cardinalidade.
No exemplo, a ligação da entidade funcionário com a entidade projeto será possível de efetuar pela inserção do atributo Codigo_do_Projeto (chave primária de projeto) na entidade funcionário.
E como devemos entender a opcionalidade do relacionamento com relação aos valores dos atributos?
Para as ocorrências da entidade funcionário que não estiverem relacionadas com nenhuma ocorrência de projeto, o atributo também existirá, porém o valor desse atributo será NULO, isto é, uma informação desconhecida, inexistente.
Funcionário
Matrícula Nome Código do Projeto Data de Início no Projeto Tempo de Alocação
1466 Pedro Antônio P-25 12/12/91 16 meses
2322 Luiz Paulo Diniz P-18 05/01/92 4 meses
7712 Carlos Estevão NULO NULO NULO
4415 Sílvia Cristina P-18 18/04/92 5 meses
Projeto
Código do Projeto Nome do Projeto
P-18 Projeto Phoenix
P-25 Projeto Minerva
P-32 Projeto Corrup (Cruzes!!) P-55 Projeto Nova Ponte
P-203 Orçamento 95
É importante destacar que existem ocorrências que justificam a cardinalidade muitos- -para-um, independentemente de existirem ocorrências com cardinalidade um-para-um no conjunto de informações em análise.
Na tabela de instâncias de funcionários apresentada, existe um projeto que só é referenciado por uma ocorrência de funcionário. Somente o funcionário Pedro Antônio está com código de projeto P-25, mas como podemos perceber, existe menos um caso de um projeto ter seu valor de Codigo_do_projeto referenciado em mais de uma ocorrência de funcionário, o que é suficiente para estabelecer esta cardinalidade de muitos-para-um entre funcionário e projeto.
A tabela que representa a entidade projeto, se agora analisada em conjunto com a tabela de instâncias de funcionário, possibilita a visualização da parcialidade do relaciona- mento entre as entidades.
Na entidade projeto existe uma ocorrência (projeto p-32) que não é referenciada por nenhuma ocorrência da tabela da entidade funcionário, assim como a entidade funcionário possui uma ocorrência que tem valor nulo para os atributos relativos ao relacionamento com a entidade projeto: Código_do_Projeto, Data_de_início e Tempo_de_Alocação são a ocorrências do funcionário Carlos Estevão.
Pelo apresentado nos exemplos, é preciso que tenhamos uma massa crítica de dados para simularmos as suas ocorrências no mundo real, para que a definição de cardinalidades seja realizada com segurança.
Agora vamos estudar outra situação neste mesmo caso.
Se, por exemplo, neste caso, a empresa informa que um funcionário pode atuar em mais de um projeto, ou melhor, está alocado a mais de um projeto simultaneamente.
Vamos ver como ficaria o modelo de dados, qual alteração sofreria. Teríamos um relacionamento muitos-para-muitos, conforme o diagrama.
Como estudamos na definição de relacionamento com cardinalidade muitos-para-muitos, esse tipo de relacionamento tem a característica de possuir campos para representá-lo, infor- mações que podem ser inerentes ao fato, ao evento, que é o relacionamento.
Para a efetivação lógica desse tipo de relacionamento, necessitamos de no mínimo dois atributos, que são as chaves primárias das entidades participantes do relacionamento.
Neste caso em estudo, Data_de_Início_no_Projeto e Tempo_de_Alocação_no_Projeto são informações relativas ao evento que une funcionário a projeto, e como pode existir mais de um evento destes para cada ocorrência de funcionário, assim como de projeto, esses dados passam a ser únicos por cada ocorrência do relacionamento, passando a ser múltiplos no contexto do modelo.
Como o número de ocorrências do relacionamento é indeterminado, não podemos mais mantê-los como atributos de funcionário, pois não saberíamos quantas ocorrências colocar desses atributos em funcionário, sendo necessário o desdobramento em múltiplos e indefinidos atributos.
Logo, o relacionamento alocado passa a ter existência lógica, ou seja, possui dados ou pode ser transformado em uma entidade associativa, como já vimos outros casos.
As estruturas de dados correspondentes ao modelo apresentado ficam delineadas da seguinte forma:
Entidades Atributos Entidade Associativa Relacionamento ou Atributos Funcionário Matrícula_Funcionário Nome_Funcionário Alocado Matrícula_Funcionário Código_Projeto Data_Início_no_Projeto Tempo_de_Alocação Projeto Código_Projeto Nome_Projeto
Como se efetiva logicamente este relacionamento?
O relacionamento efetiva-se por meio de uma expressão relacional que indica como deve ser feita a comparação entre os campos comuns às entidades, só que agora com uma característica diferente: a comparação é realizada entre campos das entidades e campos do relacionamento, formando uma expressão composta.
Expressão de relacionamento:
Funcionário.Matrícula-funcionário = Alocado.Matrícula-Funcionário e Alocado.código-projeto = Projeto.código-projeto
Esta expressão quer nos dizer que o valor do campo matrícula na entidade funcionário deve ser igual ao valor do campo matrícula no relacionamento alocado, e que o valor do campo Código_do_Projeto no relacionamento alocado deve ser igual ao valor de Código_do_Projeto na entidade projeto, conjuntamente.
Quando isso acontecer com uma ocorrência de funcionário, uma ocorrência de alocado e uma ocorrência de projeto, estaremos relacionando as duas entidades que são funcionário e projeto.
Vamos visualizar estes fatos na simulação das tabelas relacionais que representam esta realidade.
Funcionário
Matrícula Nome Data_Admissão
1466 Pedro Antônio 12/05/90
2322 Luiz Paulo Diniz 18/06/91 7712 Carlos Estevão 24/05/90 4415 Silvia Cristina 05/05/91 1216 Sandra Chi Min 01/02/92 1401 Maurício Abreu 15/05/92
Projeto
Código_do_Projeto Nome_do_Projeto
P-18 Projeto Phoenix
P-25 Projeto Minerva
P-32 Projeto Corrup (Cruzes!!) P-55 Projeto Nova Ponte
P-203 Orçamento 95
Vamos então simular relacionamentos muitos-para-muitos com estas duas tabelas de ocorrências das entidades, criando o relacionamento alocado, e suas possíveis ocorrências.
Alocado
Matrícula
Funcionário Código_do_Projeto Data_Início_no_Projeto Tempo_de_Alocação no_Projeto
1466 P-18 24/05/90 24 meses 1466 P-25 12/11/91 06 meses 1466 P-32 02/01/92 12 meses 7712 P-18 10/06/91 04 meses 7712 P-79 12/12/91 12 meses 4415 P-18 15/01/92 03 meses 1216 P-25 01/03/92 05 meses
Vamos interpretar o mundo real pela tabela de ocorrências do relacionamento alocado: A ocorrência de funcionário com matrícula 1466 está alocada a três (03) projetos,
respectivamente, P-18, P-25 e P-32, isto é, um funcionário alocado a muitos projetos.
A ocorrência de funcionário com matrícula 7712 está também alocada a muitos projetos (dois).
Já as ocorrências de funcionário de matrícula 4415 e a de matrícula 1216 estão cada uma alocada a somente um projeto, pois só constam uma vez dentro do relacionamento com campos alocados.
Novamente lembramos que ocorrências relacionando-se com cardinalidade um-para-um não invalidam a cardinalidade básica do relacionamento, uma vez que possuímos ocorrências que realizam a cardinalidade muitos-para-muitos.
É sempre muito importante que se efetue a leitura do modelo de dados em dois senti- dos para compreensão perfeita da realidade. Então vamos agora analisar a situação por outro sentido de leitura do relacionamento:
O projeto de código P-18 possui muitas ocorrências de funcionário a ele alocadas, ou seja, respectivamente, 1466, 7712 e 4415, assim como o projeto de código P-25 possui também muitas ocorrências de funcionário a ele relacionadas (1466 e 1216). Já os projetos P-32 e P-79 possuem somente uma ocorrência de funcionário a eles
relacionada.
Observe que interpretamos, ou melhor, realizamos a leitura pura e simples da tabela que representa esse relacionamento, não considerando ainda neste instante as ocorrências das duas entidades que não figuram no relacionamento.
O modelo Entidade-Relacionamento, proposto por Peter Chen na década de 1970, sofreu posteriormente algumas adaptações e extensões, que visaram torná-lo mais completo e abrangente. Uma dessas extensões foi o conceito de agregação, introduzido para viabilizar a modelagem de algumas situações típicas envolvendo relacionamentos de cardinalidade N:N.
Existem momentos em que temos uma visão dos dados que nos deixa em dúvida sobre a forma como representar um fato que está relacionado a outro. Isso equivale a dizer que um relacionamento está relacionado a outro. Mas, conceitualmente, não existem relacionamentos entre relacionamentos, é uma inverdade conceitual.
O que existe no mundo real são relacionamentos depen- dentes de outros, que somente existem após a ocorrência do outro, considerado fundamental.
O termo agregação tem sido utilizado pelas técnicas de modelagem de sistemas nos mais variados conceitos, porém o conceito lançado em modelagem de dados refere-se à visão de um relacionamento como um bloco, como alguma coisa que se relaciona com outra.
Chamamos também a atenção para o fato da existência de dependência entre os fatos, ou seja, um fato somente acontece após a existência do primeiro fato.
Em muitos trabalhos de consultoria observamos que o analista tem medo ou insegu- rança quanto à utilização de agregações em seus modelos de dados, seja porque existe a tendência de realizar diretamente o modelo físico ou o lógico, com a visualização da entidade associativa, ou porque cometem erros ao utilizar o conceito.
Quando um paciente toma remédios, isso configura um tratamento.
Tratamento existe sem que paciente tome remédio? Sim, pode ter existência própria.