Ir para o conteúdo principal

Organograma 2.0

Data de elaboração 19/04/2021
Responsável pelo estudo
  1. Diego Gonçalves de Almeida (Assessor)
  2. 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
1. Introdução

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.

  1. Consultas de escopo mais simples.
  1. Melhor desempenho em consultas do Organograma e com definições de escopo.
  2. Manter funcionamento dos escopos consistente com o modelo atual.
  3. Atualizar dimensão do Organograma para acomodar Esferas e Poderes do Governo.
2. Desenvolvimento

2.1 Estrutura Antiga


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.

2.2 Escopo

O escopo do Organograma pode ter níveis diferentes em cada contextos, são eles:

  • Instituição - especificando todas as unidades e departamentos dentro da instituição especificada;
  • Unidade - especificando todas as unidades e departamentos dentro da unidade especificada; e
  • Departamento - especificando todas as unidades e departamentos dentro do departamento especificado;

2.3 Árvore

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.

2.4 Nova Estrutura



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.

2.5 Detalhes

A seguir a estrutura recomendada para cada tabela da nova estrutura

2.5.1 esfera

Esta seria uma tabela estática com os registros: Estadual, Federal e Municipal.

  • id - primary key numérico com auto-incremento
  • nome - string de até 9 caracteres

2.5.2 poder

Esta seria uma tabela estática com os registros: Executivo, Judiciário e Legislativo.

  • id - primary key numérico com auto-incremento
  • nome - string de até 11 caracteres

2.5.3 tipo

Esta seria uma tabela estática para tipos e entidade com os registros: Departamento, Instituição e Unidade.

  • id - primary key numérico com auto-incremento
  • nome - string de até 12 caracteres

2.5.4 entidade

  • id - primary key numérico com auto-incremento
  • uuid - uuid como índice único
  • entidade_id - foreign key numérico
  • esfera_id - foreign key numérico
  • poder_id - foreign key numérico
  • tipo_id - foreign key numérico
  • nome - string de até 150 caracteres
  • sigla - string de até 25 caracteres

2.5.5 arvore

  • id - primary key numérico com auto-incremento
  • uuid - uuid como indice único
  • entidade_id - foreign key como indice único

2.5.6 arvore_entidade

Esta é a tabela que armazena toda a herança de uma entidade

  • arvore_id - foreign key numérico como primary key
  • entidade_id - foreign key numérico como primary key
3. Conclusão

Com a descrita é possível alcançar todos os resultados planejados com uma melhoria de simplicidade e performance.

Nenhum comentário
Voltar ao topo