a12 paper - perfil business intelligence - business intelligence na política
TRANSCRIPT
PERFIL BUSINESS INTELLIGENCE [email protected] SEU PAPER PELA INTERNET Desde Março/2015 – pp12
Para não entrar em um contexto do projeto de Business Intelligence dentro das instituições, ficarei
no modelo tecnológico de uma apuração eleitoral. Quero dizer que há muita política em empresas
quando da implementação de um sistema analítico. Há os que incentivam e outros que sugerem
manter como está. Há os que indicam um tipo de tecnologia e fornecedor diferente de outros. Há
muita negociação antes do início do projeto. O modelo de análise deste paper foi criado em
atenção ao que sempre é divulgado quando da apuração de votos. Portanto, como é dito que não é
coletado quem é quem no momento do voto, partimos do princípio apenas de que o voto é único
para aqueles que estão inscritos e aptos à votar. Sabendo onde está a urna eletrônica, o tipo de
eleição e a data, tenho todas as minhas características do fato. Vou medir a quantidade de votos.
O BUSINESS INTELLIGENCE NA POLÍTICA
Motivo: Começo explicando o porquê do campo [KEY_VOTO]. Em um modelo
dimensional limpo, é bom termos apenas a caracterização do que estamos
medindo e o próprio. Porém há a necessidade de neste momento ter a chave
do fato, o registro do voto, presente na tabela. Pois esta estrutura foi pensada
em questão de minutos e assim que possível vou “desmembrar” o código que
tem na [KEY_VOTO] para dimensões.
Em alguns projetos OLAP com uma carga de pressão por resultados isso
ocorre. Não é uma má prática, mas sim uma forma de resolver naquele
momento.
Como contabilizo então os votos?! Crio uma métrica virtual ou lógica com a
função agregadora COUNT no meu projeto OLAP. Eu sei que cada registro da
tabela [FACT_VOTOS] corresponde a um voto. Desta forma, com o COUNT ou
com uma coluna que tenha o valor fixo de “1”, terei o mesmo resultado.
No final, consigo caracterizar os votos e o processo por diferentes pontos de
vista. Por exemplo: - Consigo ver quais os horários de pico (Hora do dia com
mais votos computados); - Saber os votos de um município, UF; E, se quiser,
consigo enriquecer o modelo com informações diversas. Como as sociais
daquela região. E até um Big Data analisando as discuções em redes sociais.
Particularidades: A tabela de fatos possui apenas 4 colunas. [KEY_VOTO], [ID_URNA], [ID_DATA] e [ID_CANDIDATO]. O registro que tenho em [ID_URNA] é proveniente da caracterização do voto em função da urna. Sabendo qual foi a urna, consigo percorrer os níveis acima até chegar ao nível da UF. Consigo identificar melhor qual foi o candidato que recebeu o voto. Não estou desconsiderando os brancos e nulos. Na dimensão [DIM_CANDIDATOS] utilizo dois registros, quando na minha base transacional é contabilizado o voto em branco, ao fazer o processamento ETL eu determino que quando isso for encontrado o valor padrão é o do registro correspondente na tabela da dimensão. O mesmo acontece com os votos nulos. Em outros contextos posso utilizar “N/A” e “Unk”, “Not Applicable” e “Unknow”. E, pela dimensão [DIM_TEMPO] consigo agregar os votos pelos níveis que caracterizam o momento. Meu nível mais baixo é o minuto e consigo subir até o ano deste registro. Eu determinei que meu campo chave para a dimensão [DIM_TEMPO] vai ser um numérico assim: AAAAMMDDHHMM. Vejam que não utilizo uma coluna para medir o fato. Ou seja, não tenho um registro de contagem na tabela, somente a [KEY_VOTO] e caracterizações.
Conhecendo as informações que estão disponíveis diretamente para caracterizar o fato posso criar esta estrutura dimensional.
Trata-se de uma estrutura dimensional
simples e de rápida leitura dos dados.