Criando sub classes de entidades

Quando criamos um modelo de dados, muitas vezes temos que tratar de diferentes tipos da mesma entidade básica. Como trabalhar com uma tabela principal e diversas tabelas subsidiárias?

Autor: Rebecca Riordan

Quando criamos um modelo de dados, muitas vezes temos que tratar de diferentes tipos da mesma entidade básica. Por exemplo, Clientes pode ser Pessoas Físicas ou Jurídicas e precisamos armazenar diferentes informações para cada um dos tipos. Produtos muitas vezes têm diferentes tipos e não precisamos manter as mesmas informações sobre um livro e um aplicativo. livros podem ter os atributos Título, um ou mais Autores, um Editor, uma Data de Publicação, um Preço de Lista e um Preço de Venda. O aplicativo, por outro lado, tem um Número de Versão, mas não Autores e, provavelmente, não há preocupação com a Data de Publicação.

Uma solução para este problema é incluir todos os atributos de todos os tipos em uma única tabela. Numa primeira olhada esta parece ser uma solução simples e direta. Mas isso é desmontado facilmente à medida que o sistema inclui tipos adicionais, com campos adicionais. Além disso, a interface com o usuário tende a ficar bem complicada rapidamente.

Uma solução melhor é emprestar uma técnica do design orientado a objetos e criar subclasses das entidades. Em termos relacionais, criamos múltiplas tabelas: uma tabela mestre, que contém os campos comuns a todos os tipos, e tabelas subsidiárias que contém as informações específicas para cada tipo.

   Download OneToOne.zip

O banco de dados de exemplo fornece um modelo de como implementar a solução. A entidade primária é Pessoa, que pode ser Física ou Jurídica. A entidade Pessoa contém os campos comuns a todos os tipos, enquanto que as duas tabelas subsidiárias contém apenas as informações específicas dos tipos por elas modelados. (A tabela TipoDePessoa é usada apenas para popular uma caixa de combinação no formulário de exemplo).

Note-se que a chave primária (usei um campo Autonumeração no exemplo) é criada na tabela Pessoas, não nas tabelas subsidiárias. Este é um erro comum e torna a programação mais complexa do que necessário. Não há necessidade dos tipos terem identificadores adicionais e, na verdade, a vida fica mais simples se não tiverem.

O formulário de exemplo, também chamado Pessoas, apresenta uma forma de tratar da interface com o usuário. Temos dois subformulários sobrepostos, um para cada tipo. Quando o usuário seleciona um tipo na caixa de combinação IdTipoPessoa, o formulário apropriado se torna visível. No exemplo isto acontece no evento Ao Sair da caixa de combinação. Este código é repetido no evento No Atual do formulário, de modo a apresentar o subformulário apropriado quando o usuário se move pelos registros.

A consulta AllInOne demonstra a junção de todas as tabelas com o uso de left outer joins. Normalmente não é necessário o uso de tabelas "sacos de gatos" como esta, mas pode ser útil em situações onde não queira usar subformulários ou subrelatórios.