Observatório de dados/BI/FAQ

Perguntas frequentes sobre BI, no contexto do Observatório de dados/BI.

Como o público pode confiar num relatório de BI?

Existem diversos elementos que levam a uma maior ou menor confiabilidade do dado,

• fontes dos dados: todo relatório de BI deve citar as fontes e de preferência dar acesso a elas (permitir baixar os dados).
• Reprodutibilidade: elemento fundamental na Ciência e no jornalismo (única arma contra as fake news), quando um resultado não pode ser reproduzido, ele automaticamente deixa de ser confiável.
• reputação: a confiabilidade da pessoa ou autoridade responsável pela guarda ou geração de um dado, é transmitida ao próprio dado.
  • do responsável da fonte: fontes fiáveis são fundamentais. Se por exemplo preciso dos dados de população do Brasil, a fonte original e fiável é o site do IBGE onde posso baixar e referenciar os dados utilizados pelo relatório.
  • do responsável do relatório (autor do relatório, que efetuou a análise de BI)

Proveniência: de onde vieram os dados publicados?

Ilustrando o fluxo de processamento no preparo dos dados

EXEMPLO A tabela de dados utilizada para definir no Brasil as profissões enquadradas como MEI (microempreendedor individual), que corresponde ao Anexo-XIII da Resolução CGSN de 1994. Temos diferentes fontes e elementos a considerar: Identificador do documento, urn:lex:br:ministerio.fazenda;comite.gestor.simples.nacional:resolucao:2011-11-29;94 no padrão URN LEX. Trata-se de uma identificação hierárquica: jurisdição BR (federal); autoridade Ministério da Fazenda/Comitê Gestor do Simples Nacional; documento do tipo Resolução; data de publicação 2011-11-29; documento ID 94. Na ficha catalográfica do portal que resolve o identificador oficial, são indicados: Publicação Original: Publicação retificada: Texto retificado multivigente: mais este. arquivo de dados CSV: faz parte do repositório git da Open Knowledge http://datasets.ok.org.br/MEI-anexo13-atividades Conteúdo transcrito para site oficial, portaldoempreendedor.gov.br.

A descrição padronizada da proveniência dos dados é parte essencial da entrega de um "produto de BI", por descrever as fontes de dados e o percurso computacional realizado para se chegar nos gráficos, tabelas, sumarizações e demais visualizações de dados.

Apenas citar as fontes em geral não basta. O conceito de proveniência é similar ao conceito de cadeia de custódia, para a determinação da autenticidade e integridade dos dados utilizados como fonte. Pode referir-se à documentação cronológica ou histórico que registra a sequencia de custódia, controle, transferência, análise e disposição dos dados digitais ou ainda de uma fonte analógica. O processo de descrição da proveniência em geral consiste de:

1. obtenção dos identificadores oficiais e endereços de guarda fiáveis dos dados...
2. registro do processo de captura
3. registro dos filtros e operações de preparo
4. identificação do dado ou dados finais

Metadados da proveniência: além dos metadados descritivos, existem conceitos e padrões para se descrever a própria proveniência. Os mais populares são a confiabilidade e a disponibilidade dos dados originais.

Nota: teoricamente a separação se deve ao teorema da indefinibilidade, que determina o uso de uma metalinguagem (um nível mais amplo) para se determinar o "grau de veracidade" ou confiabilidade. Na prática são metadados de classificação da proveniência.

A noção de confiabilidade dos dados originais (ou "acuidade" ou "fiabilidade") vem da fusão de duas percepções distintas:

• a percepção e avaliação de seu potencial para servir à finalidade em um determinado contexto. Em BI (e dentro de uma empresa em geral) é importante manter o foco no negócio, a preocupação com a confiabilidade também precisa ser justificada pois representa um custo a mais na gestão dos dados.

• a percepção de "verdade", que pode ainda ter origem na fiabilidade estatística ("verdade relativa" ou linguística) ou na semântica de verdade adotada ("verdade absoluta"). Em um contexto de BI sempre queremos evitar dados duvidosos ou "mentirosos": convém adotar algum critério critério de verdade, ainda que vago.
  Em bancos de dados o mais simples é estabelecer quem é a "autoridade do dado". Por exemplo, mesmo havendo questionamentos metodológicos ou restrições estatísticas, podemos atribuir 100% de confiabilidade aos dados oficiais do IBGE. Analogamente os valores medidos e armazenados pela caixa-preta de um avião acidentado são supostos 100% verdadeiros.

A noção de disponibilidade de um dado original refere-se ao histórico de acesso ao dado: esteve 100% disponível se quando solicitado o acesso foi consumado, menos que 100% quando houveram eventos de falha na acessibilidade dentro de um certo período.

O que é dashboard?

Painel com mostradores de diversos parâmetros de instrumentos de medida e das condições de um automóvel.

Ferramentas de BI publicam a sua "matéria de primeira página" em telas ou páginas apelidadas de dashboard ("painel de bordo" ou "painel de controle").

O termo dashbord refere-se a uma metáfora de interface: algo com o visual parecido de um painel de bordo ou de um automóvel ou avião, cheio de indicadores, focados no que o piloto precisa saber de imediato. A generalização da metáfora consiste em estabelecer as entidades, que são também metáforas:

• Objeto monitorado: a fonte dos dados, e entidades medidas, monitoradas ou avaliadas pelos indicadores do dashboard.
• Piloto: o usuário final do dashboard, define o perfil do público-alvo e objetivos de visualização.
• Indicadores: elementos informativos do dashboard, análogos da velocidade (mostrado no velocímetro), distância (odômetro), etc. PS: neste contexto da metáfora de dashboard são às vezes chamados key performance indicators (KPI).

No termo sinônimo "painel de controle", a palavra "controle" não deve ser tomada isoladamente, pois um relatório mesmo que interativo não dá opção de controle. Pensando no painel do carro ou do avião, a metáfora do dashboard se interessa apenas pelos indicadores, não pelos botões ou dispositivos de controle do objeto monitorado, eventualmente presentes.

O termo "dashbord interativo" destaca que há algum tipo de controle, mas não controle do objeto monitorado e sim das configurações do próprio dashboard. Com a interatividade posso por exemplo selecionar parâmetros que vão disparar visualizações diferentes dos dados. Neste caso os elementos interativos podem estar fundidos aos elementos de visualização de dados (por exemplo clicar numa barra do gráfico de barras) ou serem elementos de controle independentes (por exemplo seletor de ano). Programadores e desenvolvedores costumam chamar esses elementos de controle da interatividade de widgets.

E bloco (ou elemento) de um dashboard?

Pensando no dashboard como o resultado final de uma composição quase artística (e ao mesmo tempo quase tão simples quanto um brinquedo de montar), podemos imaginar como um Lego (o dashboard inteiro) e suas peças (os blocos ou elementos do dashboard).

Aqui conceituaremos mais formalmente o dashboard de BI como um conjunto de "elementos de dashboard de BI".

Cada elemento é um pequeno sistema de template, especializado num modo visual de apresentação e nos seus dados. Historicamente o que se costumava usar como dado de entrada para esse sistema de template eram SQL-Views, por isso ainda hoje alguma ferramentas chamam os elementos de dashboard de "visualizações".

Cada fabricante inventa um nome diferente: a Microsoft por exemplo apelidou esses elementos de visualizações. No Wordpress é mais genericamente utilizado o termo "plugin" ou "plugin de dados" (ex. indicador do Climatempo ou indicador do valor do dolar).

O que é uma Notebook interface?

Uma Notebook interface é uma metáfora de interface mais ampla que a metáfora dashboard, que se popularizou com as ferramentas de análise matemática em ambiente gráfico Mathcad, Maple e Mathematica, no final da década de 1980. O Notebook oferece uma forma de visualização mais limpa e acessível para não-experts, permitindo mesclar texto (relatório) aos comandos (declarações de equações com visualização amigável) e gráficos resultantes.

Nos anos 2000 surgiu o IPython com código aberto e formatos abertos, oferecendo uma alternativa de Notebook para Web, bem como controle sobre o processamento paralelo nas análises mais pesadas. No contexto de análise de dados e dados abertos o IPython ganhou força junto com uma poderosa biblioteca de captura e análise de dados, o Pandas, a partir de 2008.

O projeto IPython foi generalizado para outras linguagens como R, Julia e Javascript, através do projeto Projeto Jupyter, que hoje é a principal referência para os conceitos e padrões da metáfora Notebook. Os documentos Notebook do Jupyter são mais simples do que HTML (usam markdown) e são registrados em formato JSON (extensão .ipynb). Portais de repositórios de dados e de projetos abertos de análise de dados, tais como Github e GitLab, interpretam automaticamente (desde ~2015) o formato .ipynb.

O que é um relatório de banco de dados?

A maioria dos sistemas de bancos de dados recebe uma grande demanda (da sua comunidade de usuários) pela geração de relatórios, ou seja, documentos para o usuário final. Tipicamente listagens de tabelas, com título, data de publicação, totais, subtotais, etc. de modo que se assemelham de fato a relatórios (ver SchemaOrg/Report abaixo).

Conforme foi indicado, os geradores de relatórios correspondem a sistemas de template e, historicamente, podem ser considerados as primeiras ferramentas de BI. Ainda hoje, sistemas de template alimentados por dados e sumarizações SQL são uma das mais potentes e bem padronizadas ferramentas de BI.

Qual a diferença entre relatório e dashboard?

A definição rigorosa de qualquer um desses conceitos requer o uso de um modelo de referência de documento digital. O melhor modelo que se tem ainda nos dias de hoje é o documento XML (XML Information Set), por ser genérico o suficiente e seu padrão amplamente adotado.

NOTA Quando impomos uma DTD específica a um conteúdo, estamos realizando uma definição prescritiva. Como as DTDs podem também ser utilizadas para definir formatos, tais como XHTML, pode ficar meio complicado fixar a DTD da DTD... Uma solução bastante usada para contornar o problema é simplesmente declarar no documento HTML que se trata de um documento mais especializado, portanto uma solução meramente descritiva (não garante conformidade de estrutura). O padrão mais utilizado para isso nos dias de hoje é o SchemaOrg. Exemplos: Report (relatório), ScholarlyArticle (artigo científico), Legislation (texto legislativo).

Um "documento XML" é qualquer forma de conteúdo que possa ser descrito por um XML schema (linguagem de descrição da estrutura de um documento). Entre as possíveis "linguagens de XML schemas" a mais simples é a DTD. Podemos imaginar por exemplo o documento legislativo como conteúdo XML que respeita uma "DTD legislativa" (ex. LexML), e o documento científico como conteúdo XML que respeita uma "DTD científica" (ex. JATS).

Pode-se imaginar uma "DTD de relatório" que imponha que o relatória seja um documento minimamente estruturado em seções e subseções, que tenha um título, autores, um código de relatório, etc. Esse padrão de fato existe, é o SchemaOrg/Report; mas não é prescritivo, ele apenas descreve os atributos básicos de um relatório típico.

Comparando então com o que foi definido acima como dashbord podemos destacar as seguintes diferenças:

• dashbord é um tipo de metáfora de interface, enquanto relatório é um tipo de documento.
  Portanto dashbord pode ser uma interface (algo dinâmico) ou um documento, enquanto o relatório é sempre um documento (em geral estático).
• o relatório tem atributos mínimos enquanto o dashbord pode ser bem simples.
• o relatório pode ser bem longo, enquanto o dashbord precisa ser simples com um só foco, ocupando no máximo uma "página".

Qual a origem histórica dos dashboards?

Historicamente a metáfora do dashboard foi surgindo e sendo adaptada para vários contextos em paralelo. Destacam-se pelo menos três, entre os mais populares:

• comando top em uso desde 1984 nos terminais UNIX e Linux, o comando é utilizado principalmente por administradores de sistema. O "piloto" de servidores remotos (máquinas com serviços críticos da empresa) abre uma pequena janela de terminal no seu computador, loga na máquina remota e roda o top nela, para ficar monitorando eventos estranhos ou ter como responder rápido a quem telefonar perguntando o que se passa.

• Prontuário médico resumido nas UTIs de hospitais: prática iniciada pela enfermeira F. Nightingale no final do século 19, o destaque de gráficos e dados do paciente nos leitos de UTI vem evoluindo desde então. Hoje os dashbords são terminais de vídeo com sinais vitais e demais sinais médicos monitorados. exemplo. (ver também "O impacto dos dashboards de visualização clínica").

• monitor finanças: serviços financeiros requerem decisões em tempo real baseadas em dados. Trata-se de um setor onde os profissionais (tais como operadores de bolsa, analisttas financeiros, especuladores, etc.) demandam informação e as empresas podem investir nessa demanda, justificando-se o investimento em ferramentas e tecnologia de ponta. Foi provavelmente o setor que mais contribuiu para a evolução da metáfora do dashboard.

• Indicadores diários na home de websites com substituição de propaganda por dados. A generalização e popularização dos dashboards certamente recebeu contribuição dos "itens de dashboard" inclusos em homes de portais na Web. Elementos com dados financeiros e do clima por exemplo, nas homes de grandes agências de notícia.

• placares e totalizadores automatizados: presentes em estádios esportivos, aeroportos, etc. A maioria dos esportes não requer placares (scoreboards) complexos no campo, exceto em baseball (alguns adotam line score) e, principalmente, corridas de cavalo: o primeiro totalizador mecânico (tote board) foi instalado em 1913. Nos aeroportos ficaram famosos na década de 1970 com a tecnologia eletromecânica conhecida como split-flap display board.

Hoje há uma convergência, ferramentas de interface e visualização gráfica de dados podem ser utilizadas em qualquer setor ou aplicação.

• Paineis de bordo nos diferentes contextos de origem da metáfora de software
• 
  Tela do comando top do Unix/Linux, praticamente a mesma de 1984 ainda em uso.
• 
  Dashbord de "conteúdo top" na home de um website.
• 
  Painel de monitoramento médico no leito da UTI.
• 
  Painel de indicadores financeiros.
• 
  Painel genérico (elementos típicos de paineis BI).
• 
  Painel de indicadores numéricos visto num smartphone
• 
  ... mais três exemplos de painel de BI.
• 
  Mesa de monitoramento financeiro (típico de bolsas com transações em tempo real).
• 
  Típico termianl de monitoramento financeiro.
• 
  Painel da bolsa das Filipinas em 2008
• 
  Tote Board, painel do jokey.
• 
  painel títico dos aeroportos (split-flap display board).
• 
  Placar completo de jogo de baseball, com line score.
• 
  Placar simples de jogo de tênis.

Afinal o BI é ou não apenas um dashboard de BI?

Exemplo de "dashboard" ou "home do relatório" do Orange, onde o foco são os metadados sobre a proveniência dos dados.

Adotamos aqui a convenção de que "as ferramentas para inteligência de negócios" formam uma classe difusa de aplicativos de software. O conceito de relatório e as metáforas de notebook e dashboard são as principais orientações, e conceitos como o de template e SQL-View servem de apoio. Resumidamente podemos dizer que a ferramenta BI cumpre com os seguintes requisitos:

• captura dados de diferentes fontes, registrando seus dados e metadados;
• permite a geração de fontes secundárias, similares a SQL-Views, que ficam igualmente registradas e sob controle da ferramenta;
• os dados filtrados e análises são gerados relatórios, interfaces do tipo dashboard ou do tipo notebook.
• O dashboardo ou "primeira página" do relatório podem ser um produto final ou um resumo destacando (lincando) os produtos finais, respeitando os dois principais focos do usuário nesta primeira página:
  • a informação resumida (apresentada num dashboard típico)
  • o resumo dos metadados da informação (apresentado num sumário de relatório ou num dashboard de .