a12 paper - perfil business intelligence - business intelligence na política

1
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.

Upload: bibrasil

Post on 21-Aug-2015

9 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: A12   paper - perfil business intelligence - business intelligence na política

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.