| Data de elaboração | 19/04/2021 |
| Responsável pelo estudo | Diego Gonçalves de Almeida (Assessor), Rubens Fidelis Miranda Junior (Assessor) |
| Equipe do estudo | Esquadrão Suicida |
| Alvo | Organograma |
| Origem | Objetivo estratégico: Definir melhor estrutura para o Organograma |
| Objetivo | Definir nova estrutura para o Organograma. |
| Documentação correlata (opcional) | Observações Não possui. |
Glossário
PK ou Primary Key - chave primária
FK ou Foreign Key - chave estrangeira
UUID ou Universally Unique Identifier - identificador universalmente único
Com problemas causados por complexidade e desempenho de consultas que utilizam o organograma para definir escopo dos dados em determinados contextos do E-Estado como Patrimônio e Recursos Humanos, e mais recentemente a integração com o SEI para replicação do Organograma, ficou claro que precisávamos melhorar a estrutura para que sua interpretação fosse consistente em todos os contextos.
Na questão da complexidade, o problema está no fato do organograma estar estruturado em 3 tabelas diferentes sendo que duas delas tem relacionamento recursivo com nível indeterminado.
Já na questão de desempenho, voltamos no cenário descrito na complexidade e no fato de não conseguirmos representar as consultas que utilizam escopo do organograma através de relacionamento dos registros - o melhor resultados que conseguimos na ocasião foi consultar o escopo separadamente e usar em uma cláusula WHERE IN da consulta com a lista de id’s do organograma.
Em cenários como no site do Organograma, dependemos da aplicação executar N consultas organizando a estrutura para ser exibida em tela que também está longe do cenário ideal.
Nesta primeira versão do Organograma não havia ainda a complexidade toda do cenário atual, ele foi criado inicialmente para atender as necessidades do módulo de Patrimônio do E-Estado sem a necessidade de escopos complexos como temos hoje.
O escopo do Organograma pode ter níveis diferentes em cada contextos, são eles:
Para solucionar os problemas atuais do escopo introduzimos o conceito de árvores, onde cada entidade do Organograma é o tronco de uma árvore e suas entidades subordinadas herdam os relacionamentos anteriores. Exemplo: uma entidade subordinada a outras duas terá relacionamento com 3 árvores.
Na nova estrutura centralizamos Instituição, Unidade e Departamento em uma mesma tabela, sendo tratados simplesmente como Entidades. Mantivemos a recursividade da tabela entidade para determinar hierarquia detalhada, além do controle geral por árvores.
Na criação de uma entidade, também é criada uma árvore pertencente a esta entidade, além de herdar relacionamento com todas as árvores de sua hierarquia.
Sendo assim, os mecanismos de controle das árvores e das heranças das entidades são automáticos.
A seguir a estrutura recomendada para cada tabela da nova estrutura
Esta seria uma tabela estática com os registros: Estadual, Federal e Municipal.
Esta seria uma tabela estática com os registros: Executivo, Judiciário e Legislativo.
Esta seria uma tabela estática para tipos e entidade com os registros: Departamento, Instituição e Unidade.
Esta é a tabela que armazena toda a herança de uma entidade
Com a descrita é possível alcançar todos os resultados planejados com uma melhoria de simplicidade e performance.