Organograma 2.0
| Data de elaboração | 19/04/2021 |
|---|---|
| Responsável pelo estudo |
|
| Equipe do estudo | Esquadrão Suicida |
| Alvo | Organograma |
| Origem |
Implementação: casos de novas implementações |
| Objetivo |
Definir nova estrutura para o Organograma. |
| Documentação correlata (opcional) |
|
| Observações | Não possui. |
2.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.
- Consultas de escopo mais simples.
- Melhor desempenho em consultas do Organograma e com definições de escopo.
- Manter funcionamento dos escopos consistente com o modelo atual.
- Atualizar dimensão do Organograma para acomodar Esferas e Poderes do Governo.
3.2. Desenvolvimento
3.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.
3.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;
3.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.
3.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.
3.2.5 Detalhes
A seguir a estrutura recomendada para cada tabela da nova estrutura
3.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
3.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
3.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
3.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
3.2.5.5 arvore
- id - primary key numérico com auto-incremento
- uuid - uuid como indice único
- entidade_id - foreign key como indice único
3.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
4.3. Conclusão
Com a descrita é possível alcançar todos os resultados planejados com uma melhoria de simplicidade e performance.