Aula 36: Transformação do MER para Tabelas: Relacionamentos N:M
No mapeamento de um modelo conceitual para o modelo relacional lógico, os relacionamentos do tipo Muitos-para-Muitos (N:M) exigem uma abordagem especial. Diferente dos relacionamentos 1:1 e 1:N, nos quais a associação pode ser resolvida pelo transporte simples de uma chave estrangeira para uma das tabelas existentes, no relacionamento N:M isso é tecnicamente impossível. Se tentássemos colocar a chave estrangeira em qualquer uma das duas tabelas originais, seríamos forçados a armazenar múltiplos valores dentro de uma única célula (o que viola a Primeira Forma Normal) ou a duplicar linhas inteiras gerando uma redundância inaceitável.
Para solucionar esse problema e manter a atomicidade e a consistência dos dados, a regra de mapeamento estabelece que todo relacionamento N:M transforma-se obrigatoriamente em uma nova tabela, frequentemente chamada de tabela associativa ou tabela de junção. O nome dessa nova tabela geralmente deriva do verbo que descreve o relacionamento ou da combinação dos nomes das duas entidades envolvidas (por exemplo, a associação entre 'Pedido' e 'Produto' dá origem à tabela 'Item_Pedido' ou 'Pedido_Produto').
A estrutura da tabela associativa é composta por:
Chaves Estrangeiras (FKs): A tabela associativa herda as chaves primárias de ambas as entidades participantes. Cada uma dessas colunas atua individualmente como uma chave estrangeira, garantindo a integridade referencial com a sua respectiva tabela de origem.
Chave Primária Composta (PK): A combinação dessas duas chaves estrangeiras forma, por padrão, a chave primária composta da tabela associativa, garantindo que a mesma associação entre duas instâncias específicas não seja registrada em duplicidade.
Atributos do Relacionamento: Quaisquer atributos que pertenciam ao relacionamento no MER (como 'Quantidade', 'Preço_Praticado' ou 'Data_Associação') tornam-se colunas adicionais dentro dessa tabela associativa.
Na prática do desenvolvimento de sistemas, a tabela associativa é a peça-chave para implementar transações complexas, como carrinhos de compras, matrizes curriculares e alocações de recursos humanos em projetos. Compreender essa transformação é o divisor de águas entre quem apenas desenha diagramas e quem sabe construir bancos de dados relacionais funcionais e seguros.
Comentários
Postar um comentário