A Impedância, o Mapeamento Objeto Relacional e Implementações – Parte II

Boa Noite Pessoal,

No artigo anterior demonstrei algumas alternativas de implementação para mapear situações de herança criadas em uma representação orientada a objeto para um banco de dados relacional. As três alternativas clássicas foram abordadas (uma tabela por herança, uma tabela por classe e uma tabela por classe concreta), os prós e contras iniciais foram detalhados em relação a espaço, simplicidade, desempenho, etc, mas propositalmente não abordei um critério de avaliação: a resiliência a alterações de negócio. Quando se projeta um modelo de dados é imprescindível visualizar futuras alterações no mundo real que certamente irão influenciar a implementação do modelo. Não é possível prever com exatidão que alterações virão, mas é importante preparar-se para que quando elas vierem, a solução como um tudo tenha o menor impacto possível em relação ao modelo de dados. Hoje demonstrarei como uma evolução de regras de negócio podem afetar as implementações anteriores. Todo o artigo utilizará os mesmos exemplos anteriores, ou seja, refletirá a representação da força de trabalho da fictícia empresa FKW Soluções.

Representações Lógicas / Conceituais

A FKW Soluções conta com diversos perfis em sua força de trabalho. Há profissionais efetivos, estagiários, terceirizados e consultores externos para suportar às demandas por recursos humanos dessa organização. O diagrama de classes projetado é apresentado na figura abaixo:

O modelo conceitual simplificado na representação de Peter Chen é apresentado abaixo:

Mudanças na Organização FKW Soluções

A FKW defende que investir nos estagiários é uma boa política de gestão de recursos humanos. Os estagiários normalmente passam por um rígido processo seletivo antes de ingressarem na empresa e embora tenham um salário acima do mercado, os custos de contratação e manutenção desses profissionais é inferior aos dos demais uma vez que a FKW fica desobrigada de diversos passivos trabalhistas. A longo prazo, o programa de estágio é visto como um processo seletivo maior no qual os estagiários que realmente se destacam acabam preenchendo as vagas no quadro sejam como efetivos ou terceirizados. A preparação desses estagiários normalmente ocorre nos seus semestres finais quando os mesmos fazem um projeto (TCC) aplicável à empresa. Normalmente esses estagiários que são supervisionados representam 5% a 10% do total de estagiários.

A FKW entende que a departamentalização é necessária para gerir as principais atividades de seus colaboradores, mas percebe também que mais importante que os limites de uma gerência ou de outra é a atuação por papéis, ou seja, um colaborador da área de contabilidade pode estar envolvido em outras atividades que não necessariamente às impostas pela sua gerência como a avaliação da expansão ou não das atividades da FKW em outros estados. Isso é muito comum principalmente nas atividades de projetos que ultrapassem os limites de um único departamento. Nessas situações, um conhecimento multidisciplinar é necessário e possivelmente haverá formação de equipes de colaboradores para realização de um projeto. As equipes não são restritas à realização de projetos internos à FKW. É possível que equipes sejam formadas para a execução de projetos sociais.

As mudanças na realidade a ser modelada demandam alterações no diagrama de classes, no modelo conceitual bem como impactam as três implementações até então trabalhadas. O novo diagrama de classes é exposto na figura abaixo:

A notação de Peter Chen simplificada é apresentada abaixo:

A especialização de estagiário em estagiário de projeto final acompanha a letra P para informar que essa especialização é parcial, ou seja, não necessariamente todo estagiário será um estagiário de projeto final. Como essa é a única especialização possível não é necessário especificar se ela é sobreposta ou disjunta como foi o caso da especialização de colaborador em efetivo, estagiário, tercerizado ou consultor externo.

A nova realidade pode provocar impactos significativos nas implementações anteriormente abordadas. A seguir são apresentadas as três alternativas de mapeamento detalhadas no artigo anterior, porém adaptadas para as novas regras.

O mapeamento em uma única tabela

Seguindo a mesma realidade antes das mudanças, o uso de uma única tabela irá mapear todos os atributos das classes e suas especializações no caso das classes envolvidas na herança. A classe "Equipe" corresponde uma classe a parte e será mapeada para uma outra tabela. Como uma equipe é feita de vários colaboradores e um colaborador pode ser incluso em várias equipes haverá uma associação entre essas entidades.

Essa alternativa ressalta a principal vantagem e as desvantagens dessa implementação. A simplicidade continua presente e a representação através de uma única tabela faz com que a codificação das consultas continue simples. Mesmo a presença de uma nova entidade chamada "equipe", os impactos nesse relacionamento foram mínimos. As desvantagens tornam-se mais aparentes, cada novo tipo de colaborador que surgir, força a presença de novas colunas na tabela. Considerando que apenas 5% a 10% do total desses estagiários terão as novas colunas preenchidas e que os estagiários não representam a totalidade dos colaboradores, muito provavelmente menos de 5% dos registros terão essas colunas preenchidas, acentuando os problemas das colunas nulas (espaço e controle) bem como as etapas de validação das operações de INSERT e UPDATE (novos atributos demandaram novas regras). Validar que um colaborador efetivo, um terceirizado e um consultor externo não tenham as duas novas colunas preenchidas representa mais codificação e manutenção nesse tipo de implementação.

O mapeamento de uma tabela por classe concreta

A associação entre colaboradores e equipes é uma das maiores desvantagens nessa alternativa. A figura do colaborador é abstrata e essa implementação não representa classes abstratas. Nesse caso, ao invés de simplesmente optar por um relacionamento mais "trivial" entre colaboradores e equipes será necessário representar esse relacionamentos entre todas as classes concretas, ou seja, todas as tabelas.

Para representar os efetivos que fazem parte de equipes é necessário implementar uma tabela que faça essa associação. O mesmo foi necessário para cada classe concreta envolvida, ou seja, estagiários, estagiários de projeto final, terceirizados e consultores externos. Se fosse utilizada uma única tabela (Participantes), a integridade ficaria difícil de manter, pois, uma tabela genérica de participantes se relacionaria com qual das classes concretas ?

A gestão do espaço e a codificação de inserts, updates e deletes ainda são diferenciais, mas outras dificuldades se potencializam. A obtenção de todos os colaboradores e suas equipes envolverá um acesso em praticamente três tabelas por classe concreta (a classe em si, a associativa e a tabela de equipes). A existência de 5 classes concretas (efetivos, estagiários, estagiários de projeto final, terceirizados e consultores externos) envolverá 15 acessos para a obtenção da lista de colaboradores que participam de equipes.

A migração de estagiários comuns para estagiários de projeto final também compõe um desafio. Será necessário importar os dados entre tabelas e refazer todas as ocorrências de associações envolvidas. Um estagiário comum que esteja em um equipe do projeto X, ao se tornar um estagiário de projeto final terá que ter seus dados cadastrados na tabela de estagiários de projeto final juntamente com os dados na tabela de estagiários de projeto final participantes de alguma equipe. Além desse cadastro, seus dados terão de ser excluídos das tabelas de estagiários e estagiários participantes. A migração de estagiários para outro tipo de colaboradores pode não ser tão comum, mas é de se esperar que um estagiário venha a se tornar um estagiário de projeto final.

O mapeamento de uma tabela por classe envolvida

Essa alternativa mapeia cada classe para uma tabela independente da classe ser concreta e abstrata. A presença de uma classe "equipe" e uma associação entre colaborador e equipe derivará duas novas tabelas. Como o colaborador do tipo estagiário de projeto final também é um estagiário, essa especialização também deve ser contemplada.

Essa alternativa mostra-se uma pouco mais resistente às novas definições. A implementação da classe abastrata colaborador permite um relacionamento direto com a classe equipe através da tabela participantes. A presença da classe "Estagiários Projeto Final" também representa uma implementação direta através de uma especialização da tabela de estagiários em um relacionamento 1 x 1.

Obter a relação de todos os colaboradores participantes de equipes é uma tarefa performática nessa alternativa. A gestão de espaço é efetiva e a complexidade de codificação de instruções de inserts, updates e deletes é moderada. O ponto crítico dessa alternativa refere-se à profundidade da herança envolvida. O cadastro de um estagiário de projeto final envolverá o acesso à três tabelas (colaboradores, estagiários e estagiários projeto final) representando passos adicionais. A recuperação tende a ser mais lenta, pois, dois joins serão necessários enquanto às abordagens anteriores dispensam essa junções.

Conclusão

Assim como a primeira parte desse artigo já ressalta que não há nenhuma abordagem "melhor" que as demais, a adição de novas definições no negócio mostra que todas as alternativas continuam cercadas de vantagens e desvantagens. Não é possível escolher uma alternativa mais "correta" já que cada uma delas buscará alguns poucos objetivos em particular. A tabela abaixo mostra um comparativo e recomendações entre as estratégias:

Objetivo Uma única tabela Uma tabela por classe concreta Uma tabela por classe
Operações DML (Insert, Update & Delete) Ruim Bom Moderado
Espaço Ruim Bom Bom
Relacionamentos das classes com uma outra classe comum Bom Ruim Bom
Desempenho nas consultas às classes Bom Moderado Ruim
Desempenho nas consultas às classes e uma classe comum Bom Ruim Bom

Como é possível observar, não há uma implementação que seja perfeita para todas as situações e isso permite afirmar que nunca uma alternativa pode ser considerada sempre certa ou sempre errada. Há situações que ainda não foram avaliadas e que podem mudar o julgamento sobre uma alternativa em relação às demais. Como seria por exemplo que essas alternativas se comportariam se o estagiário de projeto final tivesse de ser avaliado por um profissional efetivo ? E se ao invés de ser avaliado por apenas um efetivo, ele pudesse ser avaliado por vários efetivos e vários terceirizados sendo que a quantidade de avaliadores é variável ? Essa representa somente mais cenário que pode prover diversas vantagens e desvantagens a cada uma dessas alternativas.

O segredo em escolher a alternativa certa não é simplesmente fechar os olhos e escolher sempre a alternativa A ou a B. O caminho para a escolha certa está justamente em analisar os pontos fortes e fracos de cada uma bem como a possibilidade de ocorrência desses pontos. Já vi alguns modelos de dados que separam a relação de clientes em duas tabelas, uma para pessoas físicas e outra para pessoas jurídicas. Não há simplesmente nada de errado em fazer essa separação se ambas as tabelas não se relacionaram a nada em comum (digamos que os processos de venda, cobrança, etc para pessoas físicas e jurídicas obedeçam à características completamente diferentes). Juntar várias tabelas em um só, como é o caso de motos, carros e caminhonetes também não é um erro se elas compartilharem várias características em comum e aparecer uma ou outra coluna com o valor nulo. Manter uma tabela com algumas poucas colunas e especializá-la em várias outras tabelas também não é uma implementação ruim se houver muitas características diferentes. Seria o caso da universidade que possui seus alunos e seus funcionários sendo que ambos possuem pouquíssimas características em comum (um login, um e-mail) e N outras características diferentes (direito a assistir aula, obrigatoriedade do pagamento de mensalidades, resultado de um processo seletivo, contra-cheque, ficha admissional, etc.

O importante é adequar a escolha que tenha mais pontos positivos e menos negativos à realidade a ser modelada. Vale lembrar que ela pode não ser estática e é bom sempre estar de olho nas evoluções futuras para não ser surpreendido.

Nessa parte do artigo detalhei apenas as mesmas implementações lógicas que as do artigo anterior acompanhadas de uma evolução negocial. Os modelos lógicos apresentados podem ser diretamente transpostos para modelos físicos já que qualquer SGBD relacional suporta as alternativas abordadas. No próximo artigo detalharei um pouco mais os modelos físicos do ponto de vista das implementações proprietárias para lidar com situações de herança.

[ ]s,

Gustavo

5 Respostas para “A Impedância, o Mapeamento Objeto Relacional e Implementações – Parte II

  1. Opa Gustavo beleza?Em geral na empresa em que trabalho, usamos uma tabela por classe, o que facilita para nossos geradores de código.Mas gostei de ver a sua opinião sobre os demais.Parabéns! Ah te linkei no meu blog, espero que não tenha problema (:

  2. Fala Thiago,Tudo blz ? Há vários geradores que implementam de uma forma ou de outra. Não há forma correta. O importante é a solução mais "preparada ao ambiente" e a mais fácil de manter. Nesse artigo opinei sobre as implementações básicas para o relacional. Ainda vou falar sobre algumas extensões interessantes.Não há nenhum problema em linkar não. Fico lisonjeado de estar referenciado no seu blog. É um prazer, pois, sei que ele é boa referência.Abs,

  3. Luzimar Oliveira

    Vc é o cara…. conseguiu me passar uma dúvida que tinha há tempos e achei que só por classe era certo mas agora me clareou a mente e cheguei a dizer que as outras duas formas estavam erradas…. obrigado vc contriubuiu muito mano

  4. Pingback: APS1 – Mapeamento objeto-relacional | QuatiNetwork

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s