Definição sobre chave primária nas matrizes

[fjuniorr]

Segue o contexto da discussão até o momento que está em mais de um chat no Teams:

[Fabiana]: No caso do exemplo que enviou poderia ter duas linhas com a associação de uo/ação/grupo/fonte/ipu? Caso a vigência for alterada.

Ou eles manteriam em uma linha só mudando somente a informação do mês/ano

[Rodolfo]: Eu acredito que possa haver duas linhas com a mesma chave sim, nos casos em que há alteração de critério. Em cada linha, a referência ANO_MES indicaria o início da vigência. Sendo assim, caso você tenha uma linha x com vigência 2023_01 e outra linha y com a mesma chave e vigência 2024_01, isso significa que:

De janeiro de 2023 a dezembro de 2023, são válidos os critérios da linha x.
A partir de janeiro de 2024, são válidos os critérios da linha y.

[Francisco]: Podem haver duas linhas se forem consideradas como "chave" somente as colunas:

• Receita: UO_COD, FONTE_COD, RECEITA_COD
• Despesa: UO_COD, ACAO_COD, GRUPO_COD, FONTE_COD, IPU_COD

Mas adicionando a coluna FONTE_STN_COD na chave ela passa a identificar unicamente cada linha. Um exemplo real que já existe na matriz da receita é esse aqui:

FONTE_STN_COD	ANO	MES_COD	UO_COD	FONTE_COD	RECEITA_COD
704	2023	1	9999	33	1712521101000
720	2024	1	9999	33	1712521101000

Não vai existir na matriz outra linha 704|9999|33|1712521101000 com um ano/mês de vigência diferente de 2023/01 (mas a vigência em si pode ser alterada ou a linha inteira excluída).

[Rodolfo]: Eu entendo que pode haver caso o critério antigo retorne após uma alteração intermediária. Por exemplo:

FONTE_STN_COD	ANO	MES_COD	UO_COD	FONTE_COD	RECEITA_COD
704	2023	1	9999	33	1712521101000
720	2024	1	9999	33	1712521101000
704	2025	1	9999	33	1712521101000

Não sei se vai acontecer isso na prática.

[Francisco]: Bem lembrado viu. Eu olhei somente pro script atual que eu estou usando e nele por causa da forma como eu construi não existe duplicação na chave c("FONTE_STN_COD", "UO_COD", "ACAO_COD", "GRUPO_COD", "FONTE_COD", "IPU_COD").

[fjuniorr]

Sem considerar as dificuldades do lado da PRODEMGE, eu não sei de pronto como gerar a matriz corretamente de acordo com a especificação porque os dados primários:

FONTE_STN_COD	ANO	MES_COD	UO_COD	FONTE_COD	RECEITA_COD
704	2023	1	9999	33	1712521101000
704	2023	2	9999	33	1712521101000
720	2024	1	9999	33	1712521101000

devem gerar a matriz:

FONTE_STN_COD	ANO	MES_COD	UO_COD	FONTE_COD	RECEITA_COD
704	2023	1	9999	33	1712521101000
720	2024	1	9999	33	1712521101000

enquanto para:

FONTE_STN_COD	ANO	MES_COD	UO_COD	FONTE_COD	RECEITA_COD
704	2023	1	9999	33	1712521101000
720	2024	1	9999	33	1712521101000
704	2025	1	9999	33	1712521101000

os dados primários e matriz são idênticos. Em outras palavras pelo menos por enquanto não sei expressar a regra de negócio "remova os registros duplicados 704|9999|33|1712521101000 somente se não houver uma mudança de fonte no passado para a classificação 9999|33|1712521101000".

O caminho mais simples que consigo ver é gerar a matriz sem remover registros duplicados no ANO/MES de tal forma que a inclusão da FONTE_STN_COD em uma nova base seja simplesmente um left join/procv. No entanto seria necessário remover o MES_COD para evitar que certos meses não sejam devidamente classificados e bases de granularidade anual possam ser classificadas sem maiores dificuldades.