Aula 19: MER: Entidades Fracas e Dependência de Existência




No universo da modelagem, nem todas as entidades têm "vida própria". As entidades fracas são aquelas que não possuem atributos próprios suficientes para formar uma chave primária exclusiva. Elas dependem totalmente de outra entidade, chamada de entidade proprietária (ou forte), para existirem e serem identificadas no sistema. A relação entre elas é de dependência de existência: se a entidade proprietária for removida do banco de dados, todas as entidades fracas ligadas a ela perdem o sentido e devem ser excluídas também.

Um exemplo clássico de entidade fraca é o conjunto 'Dependente' em relação a 'Empregado'. Os dependentes são armazenados apenas para fins de benefícios de seguro do funcionário. Se o empregado for demitido e seus dados removidos, não há razão para manter seus filhos ou cônjuge no sistema. A entidade 'Dependente' não possui uma chave única global (como um ID nacional), sendo identificada apenas pelo seu nome em conjunto com a chave do 'Empregado'.

No Diagrama Entidade-Relacionamento (DER), a entidade fraca é representada por um retângulo de linha dupla. O relacionamento que a liga à sua proprietária é chamado de relacionamento de identificação e é desenhado como um losango de linha dupla. Além disso, a entidade fraca possui uma chave parcial (ou discriminador), que é um atributo que distingue instâncias fracas ligadas a uma mesma proprietária, mas que não serve como chave única para o sistema inteiro. A chave parcial é identificada por uma linha tracejada abaixo do seu nome.

A identificação de entidades fracas é crucial para a integridade referencial. Na implementação física, a chave primária da entidade proprietária é "emprestada" para a entidade fraca, formando uma chave primária composta. Esse mecanismo garante que o banco de dados saiba exatamente a quem aquele dependente pertence, evitando confusões entre registros de pessoas com nomes iguais em famílias diferentes.

Trabalhar com entidades fracas exige rigor técnico. Elas são muito comuns em sistemas de logística (ex: 'Itens' de um 'Pedido') e financeiros (ex: 'Parcelas' de um 'Empréstimo'). Modelar essas situações como entidades fortes seria um erro de design, pois geraria dados desconectados e dificultaria a manutenção da integridade do mini-mundo.




Comentários

Postagens mais visitadas deste blog

Aula 3: Objetivos e Vantagens de um SGBD

Aula 5: Níveis de Abstração de Dados: Visão, Lógico e Físico

Aula 1: Introdução aos Conceitos Fundamentais de Banco de Dados