Implementando
Herança de Tabela no SQL Server – Parte 01
Por: Jeff Smith
Quando
estamos projetando um banco de dados, algumas vezes nos cruzamos com situações
onde existem múltiplos tipos de entidades que nós estamos modelando, mas que
nós gostaríamos que elas tivessem certos atributos ou relações em comum. Usar tabelas "sub-tipos"
é uma forma simples de implementar herança de tabelas no SQL Server.
Por exemplo, uma questão surgiu recentemente sobre a modelagem das seguintes entidades
em um banco de dados chamado “Escola”:
· Estudantes
· Professores
· Pais
Casa uma dessas
entidades possui muitos dos mesmos atributos, tais como primeiro nome,
sobrenome e data de nascimento. Porém, precisamos separá-los em múltiplas
tabelas porque precisamos armazenar e rastrear dados diferentes para
estudantes, professores e pais: estudantes possuem notas, classes e pais, professores
possuem classes onde dão aulas, habilidades, informações sobre o emprego e outros.
Além de
compartilhar atributos em comum, essas entidades possuem também relacionamentos
em comum. Por
exemplo, para cada uma dessas entidades nós podemos também armazenar endereços,
número de telefones, histórico de correspondência, etc. Para fazer isso em um “agradável”
banco de dados normalizado, nós modelaríamos estes dados através de tabelas
adicionais:
· EnderecosEstudantes
· EnderecosProfessores
· EnderecosPais
· NumeroTelefoneEstudantes
· NumeroTelefoneProfessores
· NumeroTelefonePais
· CorrespondenciaEstudante
· CorrespondenciaProfessor
· CorrespondenciaPai
· ...etc...
No topo da redundância, tabelas similares, nós necessitaríamos de uma bagunça completa de elementos redundantes, como stored procedures similares para adicionar/atualizar/deletar/selecionar itens a partir dessas tabelas. Porém mais uma vez, nós iremos precisar de tabelas diferentes para essas diferentes entidades porque cada uma delas possui seu próprio conjunto de relações e atributos.
Existe uma forma
mais fácil de modelar isto em um banco de dados relacional? Absolutamente!
Vamos ver como?
Criando uma "Tabela Base"
Nós podemos iniciar pelo reconhecimento de que Estudantes, Professores e
Pais são todos "Pessoas", e nós podemos notar que
faz sentido dizer que todas as Pessoas podem ter endereços, número de telefones
e histórico de correspondência:
· Pessoa
· EndereçoPessoa
· NumeroTelefonePessoa
· CorrespondeciaPessoa
Na tabela Pessoas, nós gostaríamos de armazenar todos os atributos comuns de Estudantes, Professores e Pais que discutimos anteriormente: nome, data de nascimento e outros. Nós removemos todos esses atributos comuns das tabelas Estudantes, Professores e Pais e colocamos todos eles em um único lugar. Agora, a manutenção número de telefones, endereços, nomes, data de nascimento e correspondência pode ser completamente feita com um conjunto de stored procedures genéricas. A redundância dessas atividades foi agora reduzida, e qualquer mudança nos formatos do número de telefone ou endereço pode ser feita em um lugar. Nós podemos nos referir à tabela Pessoa como uma "tabela base".
