O gestor de qualidade do MPU solicitou à analista de Business Intelligence Maria um Dashboard para monitorar o desempenho da tramitação dos processos ao longo do tempo. O programador Pedro havia implementado o banco de dados MongoProc, no MongoDB, para armazenar os dados do sistema de tramitação de processos judiciais. Então, Maria solicitou a ele a consulta ao MongoProc para alimentar as tabelas: fato_proc (quantidade), dim_data, dim_estado. Pedro respondeu que não poderia fornecer apenas uma consulta, pois seria necessário transformar os dados NoSQL em relacional. Para implementar a solução, Maria poderá utilizar apenas as ferramentas disponíveis no MPU: MongoDB, PostgreSQL, MySQL, Flyway, Pentaho, QlikView e MicroStrategy. Para transformar os dados NoSQL visando a alimentar as tabelas e construir o Dashboard, Maria deve:
- A)minerar os documentos armazenados no MongoProc para encontrar padrões e exibir no Tableau;
Errada: mineração de dados não é o processo pedido, e Tableau nem aparece entre as ferramentas disponíveis.
- B)modelar multidimensionalmente os dados NoSQL para compor um Data Lake visando a apresentar os dados no Flyway;
Errada: Data Lake não é o destino adequado para tabelas fato e dimensão, e Flyway é ferramenta de migração, não de apresentação.
- C)carregar um repositório de metadados com a descrição da estrutura flexível do MongoProc e transformar a estrutura rígida do PostgreSQL;
Errada: a ideia de metadados não resolve sozinha a transformação ETL nem indica a arquitetura correta para alimentar o modelo analítico.
- D)transformar a estrutura NoSQL do MongoProc em SQL do MySQL e criar um Data Mart no GraphDB para ser consultado via QlikView;
Errada: GraphDB é banco de grafos, não um Data Mart relacional, e a passagem para MySQL não atende ao desenho dimensional pedido.
- E)implementar um ETL no Pentaho extraindo dados do MongoProc para armazenar em um Data Mart no PostgreSQL e implementar um Dashboard no MicroStrategy.
Certa: o Pentaho faz o ETL, o PostgreSQL pode armazenar o Data Mart e o MicroStrategy é adequado para construir o dashboard.
Gabarito: E
Quando você quer sair do mundo bagunçado do NoSQL e chegar num dashboard bonitinho, entra em cena o ETL: Extract, Transform e Load. Primeiro você extrai os dados do MongoDB, depois trata e converte a estrutura flexível dos documentos em um formato adequado para análise, e por fim carrega isso em um banco analítico ou Data Mart. É o caminho clássico quando a origem é documental e o destino é relacional, principalmente para consultas gerenciais como indicadores ao longo do tempo. No enunciado, o objetivo era alimentar tabelas fato e dimensão - fato_proc, dim_data e dim_estado - isto é, um modelo dimensional. Isso combina com um Data Mart, que é um recorte do ambiente analítico voltado a um assunto específico. Como o MPU só tinha ferramentas como MongoDB, PostgreSQL, Pentaho e MicroStrategy, a solução natural é usar o Pentaho para fazer a integração e transformação dos dados do MongoProc e carregar tudo no PostgreSQL, que vai guardar o Data Mart. Depois, o dashboard pode ser construído no MicroStrategy, que é uma ferramenta de BI e visualização. Repare que a questão não cobra mineração de dados nem data lake, e sim preparação de dados para análise. Então o foco está na arquitetura de BI, não em achar padrão escondido em documento nem em inventar um repositório exótico no meio do caminho. Em prova, a lógica é simples: dado NoSQL na origem, transformação ETL no meio, banco relacional analítico no destino e ferramenta de BI na ponta. Isso é bem alinhado com a doutrina de data warehouse e modelagem dimensional, como a proposta de Kimball, em que dados são integrados, resumidos e organizados para consulta gerencial.