Implementando Herança de Tabela no SQL Server – Parte 01

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (0)  (0)

Começaremos neste artigo a implementar herança de tabela no SQL Server.

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".

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?