Aula 18: MER: Restrições de Participação Total e Parcial
Além da cardinalidade, a integridade de um banco de dados depende das restrições de participação, que definem a obrigatoriedade da existência de uma entidade dentro de um relacionamento. Essa restrição responde à pergunta: "Toda instância desta entidade deve, obrigatoriamente, estar associada a uma instância da outra entidade através deste relacionamento?". Existem dois tipos fundamentais: a participação total (dependência de existência) e a participação parcial.
A participação total (ou dependência de existência) ocorre quando cada entidade no conjunto deve estar vinculada a pelo menos uma instância no relacionamento. No diagrama, essa restrição é representada por uma linha dupla ligando a entidade ao losango. Um exemplo clássico é o relacionamento entre 'Departamento' e 'Empregado': se a regra da empresa diz que todo empregado deve obrigatoriamente pertencer a um departamento, a participação de 'Empregado' é total. Se um empregado for cadastrado sem departamento, o sistema deve impedir a operação para manter a integridade.
Já a participação parcial ocorre quando apenas algumas instâncias do conjunto de entidades participam do relacionamento. No diagrama, utiliza-se uma linha simples. Um exemplo é o relacionamento 'Gerencia' entre 'Empregado' e 'Departamento'. Nem todo empregado é um gerente; logo, a participação do conjunto 'Empregado' no relacionamento 'Gerencia' é parcial. Por outro lado, se todo departamento deve ter obrigatoriamente um gerente, a participação de 'Departamento' nesse mesmo relacionamento seria total.
Essas restrições são fundamentais para evitar registros órfãos. Ao definir uma participação total, o projetista está criando uma trava de segurança que garante que informações essenciais não fiquem faltando. Modernamente, as restrições de participação são implementadas via chaves estrangeiras com a restrição NOT NULL no banco de dados físico, forçando o preenchimento dos dados obrigatórios.
Saber diferenciar participação total de parcial é o que garante que o banco de dados seja um reflexo fiel das regras do negócio. Modelar incorretamente uma participação como parcial quando ela deveria ser total pode permitir que funcionários fiquem sem departamento no sistema, gerando erros em folhas de pagamento e relatórios gerenciais. O rigor nesta fase é o selo de qualidade de um bom projeto de dados.
Comentários
Postar um comentário