Business Intelligence e Data Warehouse - Conceitos, Arquitetura e Ciclo de Vida

Conceito de Business Intelligence e seu componente Data Warehouse Profª Vivian Monteiro Antonio Felipe Podgorski Bezerra Descrição Conceitos de Business Intelligence BI e sistemas de suporte à tomada de decisão entendimento de Data Warehouse DW seus componentes e sua arquitetura bem como a compreensão do ciclo de vida do projeto Propósito Compreender os conceitos basilares de Business Intelligence e Data Warehouse como requisitos essenciais para a análise e o entendimento do ambiente organizacional e para uma maior assertividade durante o levantamento de requisitos com os usuários envolvidos e na elaboração de documentos para apoiar o projeto de DW Objetivos Módulo 1 Business Intelligence Definir o conceito de Business Intelligence e seus componentes nos diferentes níveis organizacionais Módulo 2 Projeto de Data Warehouse Reconhecer a arquitetura e o ciclo de vida de um projeto de Data Warehouse Módulo 3 Requisitos e fontes para Data Warehouse Descrever o processo de levantamento de requisitos e mapeamento de fontes de dados para Data Warehouse Introdução O crescimento de uma empresa revela desafios relacionados ao conhecimento do seu próprio negócio e sobre o comportamento do mercado que pode influenciar direta ou indiretamente na saúde da empresa O conhecimento permite aos gestores de uma organização tomarem decisões mais direcionadas focando em aspectos de melhoria das atividades aumentando as oportunidades de crescimento e minimizando riscos que possam impactar em seus resultados No entanto poucos sabem que esse conhecimento já se encontra em posse da organização em sistemas destinados às operações diárias sistemas de controle de estoque nas planilhas de vendas nos emails trocados com fornecedores e clientes e até mesmo em feedbacks e menções recebidos nas redes sociais Todos são exemplos de dados brutos que se lapidados por meio de técnicas e processos bem definidos podem se transformar em conhecimento Por isso devem ser tratados como um ativo extremamente importante da organização para obtenção da inteligência organizacional também conhecida como Business Intelligence BI Neste conteúdo vamos compreender as diferentes necessidades informacionais dentro de uma organização os tipos de sistemas que as apoiam e como é possível projetarmos estruturas para organizarmos esses dados e informações denominados Data Warehouse DW reconhecendo seus componentes e sua arquitetura o funcionamento do ciclo de vida de um projeto de DW e as fases de levantamento de requisitos e mapeamento de fontes de dados para Data Warehouse 1 Business Intelligence Ao final deste módulo você será capaz de definir o conceito de Business Intelligence e seus componentes nos diferentes níveis organizacionais Business Intelligence visão geral As plataformas de Business Intelligence BI fornecem apoio à construção do conhecimento para a tomada de decisão utilizando um conjunto de técnicas e ferramentas que coletam dados aplicam tratamentos necessários integram os dados organizam e disponibilizam informações que darão suporte às decisões estratégicas da organização Esse conjunto resulta em um ambiente analítico com informações gerenciais em formato de relatórios e dashboards que facilitam a visualização de forma mais ampla do que aconteceu do que está acontecendo ou do que ainda poderá acontecer na empresa Exemplo Para que o gerente do supermercado possa realizar uma análise do que já aconteceu e identificar quais são os produtos mais vendidos no verão é necessário analisar os dados dos três últimos anos nos meses de dezembro a março Se esse mesmo gerente possui a necessidade de acompanhar a venda dos produtos para que seu estoque não seja zerado ele precisa de relatórios diários ou semanais do fluxo de venda Mas como as análises sobre os dados podem auxiliar na tomada de decisão sobre o que acontecerá O estudo de acontecimentos passados pode revelar comportamentos futuros Então é possível analisar os produtos comprados pelos clientes traçar os perfis de consumo destes e sugerir novos produtos que se encaixem nos perfis mapeados pois de acordo com os produtos comprados há uma probabilidade que eles se interessem por alguns itens relacionados às suas compras passadas Esses tipos de análises são classificados como diagnóstica descritiva preditiva e prescritiva De acordo com o Glossário do Gartner Group GARTNER 2020 tais análises são descritas da seguinte forma Análise diagnóstica Examina os dados do passado para responder a perguntas como O que aconteceu caracterizando a questão sobre os produtos mais vendidos no verão como no exemplo do supermercado Análise descritiva Examina os dados para responder perguntas como O que aconteceu ou O que está acontecendo Um exemplo disso é a análise semanal de vendas Análise preditiva Utiliza técnicas de mineração de dados e se baseia nos dados do passado para responder perguntas sobre o que acontecerá Análise prescritiva É considerada uma análise mais avançada na qual os dados são analisados para determinar ações que podem ser tomadas para que algo aconteça Exemplo O que pode ser feito para que a venda de produtos do setor de higiene pessoal seja alavancada A análise prescritiva utiliza análise gráfica simulação processamento de eventos complexos redes neurais motores de recomendação heurística e aprendizagem de máquinas A forma de analisar os dados está relacionada aos objetivos da organização cujo interesse é visualizar os dados relevantes para facilitar a tomada de decisão Data Warehouse DW Sistema de Informação Gerencial SIG Conforme Laudon e Laudon 2014 os objetivos de um Sistema de Informação Gerencial SIG em uma organização são Obter a excelência operacional Desenvolver novos produtos serviços e modelos de negócio Estreitar o relacionamento com os clientes e fornecedores Melhorar a tomada de decisão Obter vantagem competitiva Sobreviver O SIG disponibiliza relatórios para usuários no nível de gerente que possuem objetivos mais específicos Sistemas de Apoio à Decisão SAD Já os Sistemas de Apoio à Decisão SAD são baseados em conhecimentos que apoiam a tomada de decisão nas organizações com ferramentas de análises e visão por diferentes perspectivas de análises Eles processam grandes volumes de dados consolidam e disponibilizam ambientes analíticos com consultas em formato de relatórios e dashboards Sistema de Informação Executiva SIE Há ainda o Sistema de Informação Executiva SIE destinado à tomada de decisão dos executivos da empresa Suas análises são mais resumidas e a interface de análise é mais fácil e objetiva Os três tipos de sistemas de informação gerencial possuem o objetivo de apoiar a tomada de decisão cada qual destinado a um público específico O Data Warehouse DW é um sistema de informação gerencial focado no apoio à tomada de decisão que normalmente é realizada pelos gestores da organização O conceito Data Warehouse DW ou armazém de dados surgiu entre os anos 1980 e 1990 com o trabalho desenvolvido pelos pesquisadores Devlin e Murphy 1988 com o nome Business Data Warehouse BDW que buscava integrar dados para apoiar as análises sobre os dados de uma organização Comentário Apesar de Bill Inmon já usar o termo Data Warehouse nos anos 1970 KEMPE 2012 o artigo citado DEVLIN MURPHY 1988 descreveu o problema a ser resolvido e a solução a ser implementada para a integração dos dados empresariais Posteriormente Inmon difundiu o conceito do Data Warehouse e hoje é conhecido como o pai do DW O professor Ralph Kimball também é uma referência no conceito de Data Warehouse e possui uma abordagem de implementação diferente da apresentada por Inmon KIMBALL 1998 Abordagem de Inmon topdown A abordagem de Inmon topdown parte de uma estrutura que abrange amplamente os assuntos contidos em uma organização DW A partir dessa visão os Data Marts DM que serão detalhados mais adiante são desenhados INMON IMHOFF 2001 Abordagem de Kimball bottomup A abordagem de Kimball bottomup se dedica a criar visões menores com os Data Marts DM e depois integrar esses módulos resultando no Data Warehouse DW organizacional A imagem a seguir apresenta as abordagens defendidas pelos dois autores Abordagens de projeto de DW Atenção A escolha da abordagem a ser implementada por uma organização ocorre conforme a sua necessidade de análise Contudo muitas vezes a abordagem bottomup é escolhida por ser mais fácil de implementar explorando um assunto por vez e evoluindo com o desenvolvimento dos Data Marts até que se obtenha o Data Warehouse desejado Data Mart DM O Data Mart é um armazém de dados focado em um assunto da organização Ele é um subconjunto de um Data Warehouse O Data Warehouse é formado por vários Data Marts ligados por perspectivas de análises em comum Para uma implementação mais rápida do ambiente analítico ele pode ser construído por Data Mart Nesse caso é importante compreender o Data Mart como parte de um todo DW que será integrado aos demais assuntos fornecendo análises para toda a organização Agora vamos analisar o cenário hipotético de um estudo de caso uma locadora de veículos Cenário de análise locadora de veículos Com o objetivo de prestar um excelente serviço aos seus clientes uma locadora de veículos mantém um portfólio de veículos 0 Km ou com até um ano de uso para alugar aos seus clientes Ao completar um ano de uso os veículos são vendidos e novos veículos são comprados para a reposição Para aumentar os lucros e fidelizar os clientes oferecendo benefícios em seus aluguéis a locadora deseja conhecer quais são os clientes que alugaram veículos nos últimos seis meses pelo menos uma vez por mês Para isso foi construído um ambiente de análise com o Data Mart AlugueDM tornando possível responder à pergunta sobre os clientes conforme observado na imagem a seguir Data Mart dos clientes fidelizados Com o passar do tempo a locadora sentiu a necessidade de responder à outra pergunta Os clientes que compraram carros conosco participam do programa de fidelidade Para responder a essa pergunta foi construído o Data Mart VendaDM conforme observado na imagem a seguir Data Mart da venda de veículos usados O Data Mart VendaDM possui a mesma perspectiva de análise que o Data Mart AlugueDM Essa perspectiva é a visão de cliente Com a perspectiva de análise em comum nos dois Data Marts é possível relacionálos e analisar as informações de aluguel e venda de veículos para os clientes da locadora conforme observado na imagem a seguir Relacionamento dos Data Marts Com o exemplo da locadora de veículos é possível verificar que o Data Warehouse e o Data Mart fornecem análises gerenciais que facilitam e melhoram a performance das atividades das organizações com análises consistentes ao longo tempo Principais características do Data WarehouseData Mart O Data WarehouseData Mart é orientado a assunto possui dados integrados não é volátil e apresenta análises ao longo do tempo À diferença dos sistemas transacionais que são orientados a aplicações como estoque e faturamento o DWDM se preocupa com os principais assuntos da organização Vejamos algumas de suas características O processo de extração captura dados de diversas fontes aplica tratamentos padroniza e integra os dados fornecendo consultas por diferentes visões de análises Nos ambientes analíticos ao carregarmos os dados no DWDM eles não sofrerão atualizações garantindo assim que uma mesma consulta feita no mês passado e hoje apresentará o mesmo resultado Nos sistemas transacionais por sua vez os dados sofrem as operações básicas de inclusão alteração e deleção de registros O DWDM permite análises ao longo do tempo A visão Tempo é muito importante no ambiente analítico pois os dados históricos são referentes a um momento no tempo É essa característica que permite avaliar por exemplo qual foi o percentual de crescimento de vendas de produtos do setor de higiene pessoal no primeiro trimestre do ano em relação ao primeiro trimestre do ano passado eleição Remoção perda destruição Além das características principais os sistemas DWDM diferem dos sistemas transacionais por 1 Apresentarem consolidação dos dados 2 Serem voltados aos gestores da organização que atuam na tomada de decisão 3 Acessarem grandes quantidades de linhas para montar as consultas 4 Possuírem redundância dos dados Os sistemas transacionais possuem dados detalhados e são usados principalmente pelos usuários que por exemplo ao realizarem atendimento ao público ou controle de estoque acessam poucas linhas por transação e são normalizados Sistemas de Apoio Operacional X Sistemas de Apoio à Decisão Um sistema de informação necessita apoiar os diferentes níveis de tomada de decisão devendo portanto prover suporte aos diversos tipos de decisão conforme ilustrado na imagem a seguir Níveis de decisão Sistemas de Apoio Operacional Os Sistemas de Apoio Operacional utilizam um tipo de processamento conhecido como OnLine Transaction Processing OLTP ou Processamento de Transações Online São normalmente usados pelos gerentes operacionais para realizar as atividades diárias da organização como os sistemas integrados de gestão Eles buscam responder a perguntas de rotina registrando os eventos ocorridos a cada operação realizada Exemplo O sistema de apoio ao fluxo de vendas do cenário de análise de um supermercado recebe todas as ocorrências de eventos de compras realizadas pelos clientes em várias lojas físicas e pelo ecommerce Todas as operações de inclusão alteração e deleção de registros ocorrem durante o período do atendimento ao cliente Assim esse sistema deve estar disponível para que a operação do supermercado não seja prejudicada Em outras palavras não pode haver concorrência de acesso aos dados gerando lentidão a esse ambiente As análises realizadas nas bases de dados dos Sistemas de Apoio Operacional são pontuais e coletam poucos registros por vez Exemplo Quais foram os produtos que o cliente João comprou hoje na loja física Seu funcionamento é baseado em consultas ao banco de dados da empresa que são formuladas por critérios predefinidos e altamente estruturados Caso seja necessário analisar o volume de compras efetuadas pelo cliente João nos últimos dois anos nas lojas física e pelo ecommerce isso não será possível O volume de dados a ser analisado é muito grande para concorrer com as operações que estão sendo realizadas no Sistema de Apoio Operacional transacional Sistemas de Apoio à Decisão Os Sistemas de Apoio à Decisão ou OnLine Analytical Processing OLAP são mais adequados para lidar com decisões não rotineiras pois visam gerar informações e conhecimentos para a resolução de problemas para os quais não existe um procedimento previamente definido Saiba mais Além das informações internas de outros sistemas organizacionais os SADs buscam fontes de dados externas como as cotações das bolsas de valores e os preços dos concorrentes Esses sistemas são usados pelos gerentes de nível mais alto que usam técnicas analíticas e modelos estatísticos e matemáticos sofisticados para produzir conhecimento Nesse ambiente analítico os dados ficam disponíveis para responder às perguntas com eficiência sem concorrer com as operações transacionais da organização Em um Data WarehouseData Mart as análises históricas são respondidas com bastante eficiência pois sua arquitetura é projetada para explorar grandes volumes de dados como veremos no próximo módulo Principais características de sistemas de BI No vídeo a seguir abordamos os conceitos basilares de sistemas de Business Intelligence Vamos lá Para assistir a um vídeo sobre o assunto acesse a versão online deste conteúdo Falta pouco para atingir seus objetivos Vamos praticar alguns conceitos Questão 1 Sobre o conceito de Business Intelligence BI que tem como objetivo fornecer análises para a tomada de decisão em organizações privadas ou públicas é possível afirmar que A É um sistema que fornece relatórios sobre os dados produzidos pela organização B É uma ferramenta que transforma os dados para a construção das análises solicitadas pela organização C É um conjunto de técnicas e ferramentas que dão suporte à criação de um ambiente analítico no qual as análises podem ser feitas por meio de relatórios e dashboardss D É uma ferramenta de criação de dashboardss com as possíveis análises que a organização possa precisar E É um ambiente que fornece análises somente sobre os fatos que estão ocorrendo atualmente na organização como por exemplo Quantos produtos foram vendidos essa semana Parabéns A alternativa C está correta O conceito de Business Intelligence BI fornece apoio à construção do conhecimento para a tomada de decisão utilizando um conjunto de técnicas e ferramentas que coletam integram e organizam os dados com os tratamentos necessários e disponibilizam informações que darão suporte às decisões estratégicas da organização Questão 2 Sobre as características do Data Warehouse é possível afirmar que A É orientado a assunto não integra dados é não volátil e apresenta dados históricos B É orientado a assunto possui dados integrados que são alterados ao longo do tempo e apresenta dados históricos C Possui foco departamental não integra dados é não volátil e apresenta dados históricos D É orientado a assunto possui dados integrados é não volátil e apresenta dados históricos E Possui foco departamental e dados integrados é não volátil e apresenta dados históricos Parabéns A alternativa D está correta O Data Warehouse é orientado a assunto integra dados de vários sistemas não é passível de alterações dos acontecimentos passados e armazena dados históricos possibilitando análises ao longo do tempo 2 Projeto de Data Warehouse Ao final deste módulo você será capaz de reconhecer a arquitetura e o ciclo de vida de um projeto de Data Warehouse Arquitetura do Data Warehouse O Data Warehouse pode ser construído com uma visão integrada de Data Marts ligados por perspectivas comuns dentro da organização ou por Data Marts de forma independente que tratam assuntos mais específicos A construção do DWDM envolve alguns pontos que devem ser considerados pela organização como a infraestrutura disponível o escopo a disponibilidade dos dados e os profissionais capacitados que executarão as atividades relacionadas à arquitetura do ambiente Um projeto de construção de um DWDM é composto por alguns passos importantes São eles 1 Entendimento do negócio Levantar os requisitos para conhecer a necessidade da organização é um passo fundamental para o início de um projeto de DWDM O escopo a ser definido deve conter as análises desejadas pela organização para as perspectivas de análises e os indicadores que serão analisados É necessário definir o grão que será analisado no ambiente e entender como o tempo deve se comportar no ambiente a ser criado 2 Mapeamento dos dados Esse passo verifica a disponibilidade e a viabilidade dos dados necessários para a construção das análises 3 Construção da área de manobra dos dados staging area Área em que os dados são armazenados temporariamente para que sejam tratados 4 Construção do processo ETL Extract Transform and Load Processo de extração de dados das fontes de origem transformação dos dados para adequar à análise e carga dos dados no DWDM 5 Construção das análises Especificação e desenvolvimento de consultas relatórios aplicativos de análise e outros componentes das aplicações de BI rão Nível de detalhamento dos dados Saiba mais Grão Nível de detalhamento dos dados Segundo Kimball e Ross 2013 a arquitetura de um DWDM possui quatro componentes distintos no ambiente de BI Fontes de dados transacionais source transactions Sistema ETL ETL system Área de apresentação dos dados presentation area Aplicações de BI BI applications A imagem a seguir apresenta esses componentes Fontes de dados transacionais source transactions As fontes de dados são em geral provenientes de sistemas transacionais da organização que contêm elementos de dados de onde informações possam ser extraídas e analisadas Os sistemas transacionais são aqueles que interessam para a análise de dados como por exemplo sistemas de vendas contas a pagar e a receber folha de pagamento controle de estoque controle de crédito Esses dados são conhecidos como estruturados ou seja é possível recuperar o conteúdo a partir de uma estrutura previamente estabelecida e padronizada No entanto outras fontes de dados como planilhas em Excel documentos em Word log file arquivos de log menções em redes sociais arquivos de áudio arquivos de imagens podem ser utilizados na análise Essas fontes são denominadas semiestruturadas ou não estruturadas pois possuem pouco ou nenhum padrão inicialmente preestabelecido e seu tratamento é mais complexo Esses dados podem conter conhecimento extremamente valioso para o negócio Sistema ETL ETL system O sistema ETL é definido por Kimball e Ross 2013 como um ambiente composto por uma área de trabalho estruturas de dados instanciadas e um conjunto de tarefas organizadas em três etapas extração transformação e carga og file arquivos de log Arquivo em geral com extensão log que contém registro de eventos e ocorrências em um sistema de computação Extração A extração é a etapa que coleta os dados identificaos copia os que são necessários para as análises e armazena esse conjunto de dados em uma base de dados temporária Além das fontes de sistemas transacionais outras fontes de dados podem ser consideradas como dados semiestruturados arquivos XML JSON e dados não estruturados texto Essas fontes podem complementar as análises de DWsDMs ou ainda compor Data Marts baseados apenas em dados extraídos de fontes de dados não estruturados Transformação A transformação dos dados consiste em aplicar tratamentos para limpar e padronizar os dados colocandoos em conformidade converter campos numéricos formatar datas integrar dados aplicar metadados em dados não estruturados etc Essa etapa contribui com a melhoria dos sistemas transacionais apontando inconsistências que possam ser encontradas nos dados que foram extraídos Devido ao grande volume de dados manipulados é inviável que a cada problema encontrado o analista responsável pelo DWDM informe ao sistema transacional Para resolver esse problema há mecanismos de controle de cargalog que registram as inconsistências e que podem ser consultados conforme a necessidade Carga A carga dos dados ocorre após a transformação Eles são inseridos na estrutura definitiva representada pela área de apresentação do DWDM onde são acomodados de forma organizada no modelo de dados multidimensional definido para o DWDM Área de apresentação dos dados presentation area A área de apresentação é o local onde os dados estão organizados no modelo dimensional e disponibilizados para usuários e aplicações de BI Nesse momento os dados estão prontos para uso e podem ser consumidos pela organização para apoiar a tomada de decisão Aplicações de BI BI applications As aplicações de BI consultam os dados que estão organizados na área de apresentação dos dados Por meio das aplicações de BI os usuários podem desenvolver suas análises ou utilizar relatórios e dashboards prontos desenvolvidos conforme a necessidade dos usuários Metadados do Data WarehouseData Marts O banco de metadados construído com o ambiente do DWDM é um ativo importante tanto para a equipe de BI quanto para os usuários da organização pois mantém informações importantes sobre os dados contidos no ambiente permitindo a identificação dos dados como nome tipo tamanho Esse conjunto de informações dados sobre os dados é conhecido como dicionário de dados Além dessas informações são armazenados os tratamentos aplicados o relacionamento entre os dados o entendimento de conceitos e definições de negócio a verificação das regras de negócios aplicadas e todas as demais informações importantes para o desenvolvimento desse ambiente Kimball e Ross 2013 afirmam que os metadados são análogos à enciclopédia do DWBI Por isso o analista deve estar atento para povoar e manter o repositório de metadados Barbieri 2020 explica que os metadados definem os dados sob várias óticas tais como Características daquilo que está se contextualizando Nome peso tipo comprimento formato altura distância preço etc Relacionamentos Trabalha para mantido por tem como gestores os localizado em etc Formas de tratamento Fórmulas cálculos manipulações procedimentos etc Regras Obrigatoriedade de presença dos dados naquele contexto regras de qualidade exigidas para formas valores conteúdos etc Informações históricas Inventado em descoberto por desativado em etc A principal vantagem de trabalhar com os metadados é o fato de que todas as informações importantes estão armazenadas e podem ser consultadas sempre que for necessário Data WarehouseData Marts SelfService A arquitetura tradicional de um Data WarehouseData Mart fica sob os cuidados dos analistas de BI que têm como objetivo manter um ambiente de dados consistente e confiável disponibilizando análises para os usuários ou para que as aplicações de BI e usuários avançados realizem as análises conforme a necessidade Esse fluxo de atividades é apoiado por um conjunto de tarefas de entendimento levantamento de requisitos e documentação realizado pelos analistas de BI Tais artefatos geram um banco de metadados sobre o ambiente analítico com informações importantes sobre o conhecimento produzido neste Comentário Apesar de o atendimento e a atuação da equipe de BI serem eficientes quanto à entrega de um ambiente controlado assistido e apoiado por metadados em organizações onde a demanda é muito volumosa e a equipe de BI não consegue atender às necessidades dos usuários de forma rápida surge a necessidade de um modelo SelfService no qual o usuário pode acessar modelar e analisar os dados sem o auxílio da equipe de BI Com essa forma de acesso aos dados os usuários podem gerar suas análises de maneira mais rápida obtendo os resultados desejados com um tempo inferior ao atendimento do analista especializado em BI No entanto apesar de o modelo SelfService oferecer maior rapidez na confecção das análises pelos usuários alguns pontos de atenção devem ser observados São eles Nesse modelo os dados ficam descentralizados onde cada usuário cria seu próprio conjunto de dados e aplica regras de negócio sob seu ponto de vista Não há o desenvolvimento dos metadados do ambiente A falta de tratamento e observação das inconsistências de dados pode apresentar resultados errados Análises sobre o mesmo assunto podem apresentar resultados diferentes prejudicando a tomada de decisão Mineração de dados e Descoberta de Conhecimento em Bases de Dados KDD O Data Warehouse disponibiliza uma base de dados organizada com diversas perspectivas de análises ao longo do tempo Esse repositório de dados oferece consultas predefinidas e análises no formato SelfService Além dessas possibilidades ir em busca da descoberta de conhecimento e da mineração de dados é uma das etapas da Descoberta de Conhecimento em Bases de Dados ou Knowledge Discovery in Databases KDD e está relacionada com o Data Warehouse no que diz respeito a dados tratados e disponíveis para análises pois o DW pode fornecer dados para os processos de KDD gerando valor para a organização Porém lembrese uma solução não substitui a outra Elas são complementares no processo de busca pelo conhecimento Essas técnicas podem revelar padrões de comportamento auxiliando a tomada de decisão No cenário de análise do supermercado o DW fornece consultas sobre o volume de compras realizadas pelos clientes e os processos de KDD podem descobrir padrões existentes nas compras realizadas Vejamos alguns exemplos fases você precisa planejar a execução dessas fases como ilustrado na imagem a seguir Planejamento do projeto Definição dos requisitos de negócio Arquitetura tecnológica Seleção e instalação dos produtos Modelagem dimensional Projeto físico Especificação e desenvolvimento de ETL Especificação da aplicação de BI Desenvolvimento da aplicação de BI Implantação Crescimento Manutenção Gerenciamento do projeto Ciclo de Vida de um Projeto de Data Warehouse Primeira fase Planejamento O planejamento do projeto é a primeira fase do ciclo de vida de um projeto de DW Nessa fase são definidos o escopo do projeto a viabilidade de recursos as tarefas a serem desenvolvidas no projeto e o encadeamento delas Saiba mais Kimball e Ross 2013 afirmam que um bom planejamento e a definição bem elaborada dos requisitos aumentam a probabilidade de sucesso de um projeto de DW pois seu desenvolvimento é baseado nas necessidades dos usuários do negócio Isso apoia a importância dessas duas fases para o desenvolvimento do DW Segunda fase Definição dos requisitos de negócios A segunda fase do ciclo de vida é a Definição dos requisitos de negócios e está diretamente relacionada à primeira fase devido à necessidade do conhecimento dos requisitos pois o escopo do projeto é definido pelos requisitos do usuário A relação entre essas duas fases é representada na imagem pela seta de mão dupla leftrightarrow Saiba mais Kimball e Ross 2013 afirmam que um bom planejamento e a definição bem elaborada dos requisitos aumentam a probabilidade de sucesso de um projeto de DW pois seu desenvolvimento é baseado nas necessidades dos usuários do negócio Isso apoia a importância dessas duas fases para o desenvolvimento do DW Terceira fase Desenvolvimento Observe que o ciclo de vida do projeto após a definição dos requisitos do negócio é dividido em três trilhas distintas da fase de desenvolvimento Trilha tecnológica A primeira trilha se dedica às tecnologias que serão utilizadas no desenvolvimento do DW Atenção A etapa arquitetura tecnológica se preocupa com a definição estrutural e compreende os componentes necessários à implementação de um DW Esses componentes estão relacionados à arquitetura de dados à infraestrutura utilizada e às tecnologias necessárias na Exemplo 1 Você já ouviu falar sobre a relação da fralda descartável com a cerveja Apesar de não haver uma fonte confiável que valide essa descoberta é um fato muito conhecido no mundo de BI e interessante para ser analisado Um grande varejista dos EUA observando os padrões de compra de seus clientes verificou que o aumento da venda de fraldas às sextasfeiras estava relacionado à venda de cerveja e na maioria das vendas os clientes eram do sexo masculino A explicação para esse fato curioso é que os papais iam comprar fralda para seus pequenos e acabavam levando a cerveja para seu final de semana De posse desse conhecimento o varejista posicionou estrategicamente as fraldas ao lado das cervejas para aumentar os lucros Exemplo 2 Outro exemplo voltado ao bemestar de pacientes e com foco na diminuição de gastos é a descoberta antecipada de possíveis cirurgias de alto risco realizadas por pacientes que possuem problemas relacionados à coluna O estudo sobre a recorrência de consultas com ortopedistas e as ocorrências de exames correlacionados e terapias dedicadas a essa patologia pode sinalizar futuras cirurgias Com esse conhecimento os gestores responsáveis pelo acompanhamento clínico dos pacientes podem oferecer tratamentos direcionados e efetivos para que cirurgias desnecessárias não sejam realizadas reduzindo os riscos ao paciente e diminuindo os gastos com internações Ciclo de vida do Data Warehouse O Data Warehouse coleta trata e armazena os dados mais relevantes para uma organização com o objetivo de apoiar a tomada da decisão A implementação desse ambiente está relacionada à necessidade da organização de unificar os dados para analisálos historicamente a fim de observar seu comportamento ao longo do tempo ou mapear futuros comportamentos no negócio Atenção Sua implementação deve se preocupar com os recursos disponíveis para sua concepção de modo que o resultado seja alcançado Além disso é muito importante que o objetivo da construção esteja bem definido e seja orientado às necessidades dos usuários da organização à disponibilidade de recursos e dos dados A construção do DW deve considerar esses pontos e ter um plano de desenvolvimento para que os objetivos sejam alcançados O desenvolvimento de um projeto é dividido em fases e possui um início e um fim Para iniciar qualquer atividade que envolva várias construção e utilização de um DW Essa etapa é seguida da seleção e instalação dos produtos que define as ferramentas que serão utilizadas na construção realiza a instalação faz o teste de integração e as executa Trilha de dados A segunda trilha se dedica ao tratamento dos dados e encadeia as fases modelagem dimensional projeto físico e especificação e desenvolvimento de ETL Modelagem Dimensional A etapa modelagem dimensional estuda as análises que serão desenvolvidas no ambiente analítico e une o conhecimento dos requisitos definidos para criar uma estrutura capaz de acomodar os dados dimensionalmente Nessa etapa é definido o modelo de dados dimensional do DWDM Projeto Físico Na etapa seguinte projeto físico é definida a estrutura física para a construção do modelo de dados dimensional como a definição do padrão de nomenclatura utilizada e a configuração do ambiente do banco de dados Especificação e Desenvolvimento de ETL Após a definição da estrutura física da base de dados é o momento de definir e construir os processos que extrairão os dados dos sistemas origens transformar e carregar os dados nas tabelas definitivas do DW Esta é a etapa especificação e desenvolvimento de ETL O tamanho das caixas de cada etapa não representa o esforço realizado em cada uma delas A construção do ETL é uma tarefa muito custosa que demanda aproximadamente 70 do esforço empregado na trilha de dados Trilha da aplicação de BI A terceira trilha do ciclo de vida está concentrada na definição e construção da camada de visualização dos dados O desenho das consultas desejadas pelos usuários é um artefato muito interessante e contribui com o alinhamento das expectativas dos usuários que acessarão o DW por meio de análises predefinidas Essa definição é realizada na etapa de especificação da aplicação de BI Seguindo a tarefa de especificação a etapa desenvolvimento da aplicação de BI constrói as consultas na ferramenta de relatórios analíticos definida para o projeto Quarta fase Implantação A fase de implantação é a união das tarefas desenvolvidas em cada trilha do ciclo e deve ocorrer quando todas as fases estiverem concluídas Novas necessidades surgirão após a implementação do ambiente analítico o que faz parte do processo de desenvolvimento e crescimento do DW de uma organização Quinta fase Crescimento e manutenção O crescimento é representado pela fase que inicia com o planejamento de um novo projeto mas nesse caso será um projeto de complemento Por fim a manutenção é representada no ciclo de vida de um projeto de DW Neste módulo foi abordada a arquitetura tradicional de um Data Warehouse além de outras possíveis abordagens e foram apresentadas as fases do ciclo de vida de um projeto de Data WareHouse Arquitetura de Data Warehouse e ciclo de vida de projeto Assista no vídeo a seguir a uma apresentação da arquitetura DW na qual visitamos cada fase do ciclo de vida do projeto culminando com a ideia da sobreposição da arquitetura DW contida nesse ciclo de vida do projeto Para assistir a um vídeo sobre o assunto acesse a versão online deste conteúdo Falta pouco para atingir seus objetivos Vamos praticar alguns conceitos Questão 1 Metadados são muito importantes para sistemas de Business Intelligence BI e mantêm informações relevantes sobre os dados O banco de metadados de um projeto de BI A Documenta os processos de extração conceitos e histórias dos usuários da organização B Documenta os dados contidos no DWDM os tratamentos sobre os dados o relacionamento entre eles o entendimento de conceitos e definições e a verificação das regras de negócios aplicadas sobre os tratamentos realizados C Documenta os processos de extração conceitos e definições de negócio e os erros que ocorrem nos sistemas transacionais que são fontes para os sistemas de BI D Documenta o mapeamento dos processos de extração e os resultados obtidos pelas consultas mas não registra regras de negócio e conceitos E Não apresenta conhecimento sobre o ambiente e sim estatísticas das execuções de consultas realizadas pelos usuários Parabéns A alternativa B está correta Os metadados de um projeto de BI documentam as informações sobre os dados sobre o relacionamento do conjunto de dados contido no DWDM os tratamentos aplicados além das informações voltadas ao negócio Questão 2 O desenvolvimento de um projeto possui início e fim além de ser dividido em fases Em qualquer atividade composta por fases é necessário inicialmente planejar a execução dessas fases com o objetivo de viabilizar que o projeto consiga ser de fato implantado na organização Dentre as diversas fases de um projeto o planejamento é a primeira fase do ciclo de vida de um projeto de Data Warehouse Nessa fase são definidos A O escopo do projeto o processo ETL as tarefas a serem desenvolvidas no projeto e o mapeamento das fontes de dados B A viabilidade de recursos as tarefas a serem desenvolvidas no projeto e o encadeamento delas e as consultas predefinidas C O escopo do projeto a viabilidade de recursos a matriz de granularidade e o encadeamento das atividades do projeto O escopo do projeto a viabilidade de recursos as tarefas a serem desenvolvidas no projeto e o encadeamento delas Parabéns A alternativa D está correta Na fase de planejamento deve ser considerado o escopo do projeto no qual as necessidades dos envolvidos no negócio denominadas requisitos do usuário são levantadas e servem para delimitar a abrangência do projeto que tem de se manter alinhado ao objetivo organizacional Já a viabilidade de recursos as tarefas a serem desenvolvidas no projeto e seu encadeamento que também ocorrem na fase de planejamento servem como base para que na fase do gerenciamento do projeto seja possível coordenar a devida condução e execução das tarefas aumentando assim a probabilidade de sucesso do projeto de DW 3 Requisitos e Fontes para Data Warehouse Ao final deste módulo você será capaz de descrever o processo de levantamento de requisitos e mapeamento de fontes de dados para Data Warehouse Análise de cenário de um projeto de Data Warehouse Vamos analisar juntos um cenário hipotético de uma grande rede de fastfood Cenário 1 Marcos é gerente de vendas em uma grande rede de fastfood Todos os dias às 16 horas ele precisa verificar se é necessário fazer a reposição de algum item utilizado na confecção dos lanches da lanchonete Se o item estiver com a disponibilidade comprometida ele deverá enviar a solicitação de reposição ao setor de reabastecimento para que o item seja entregue na manhã seguinte Para fazer o controle dos itens Marcos imprime a lista dos pedidos conta a quantidade de lanches servidos em cada pedido e faz o cálculo de kits utilizados para saber se é necessário repor ou não algum item Esse processo é tão custoso para Marcos que há dias ele não consegue terminar a análise em tempo de solicitar os itens para o dia seguinte Qual é a solução mais adequada para ajudar Marcos Vamos analisar o problema Analisando o cenário É a dificuldade em saber se é necessário ou não solicitar a reposição de itens até às 17 horas todos os dias da semana Saber se há necessidade de solicitar a reposição de algum item diariamente e fazer a solicitação dentro do prazo de forma mais rápida Ele verifica todos os pedidos e calcula a média manualmente dos itens utilizados com o objetivo de saber se há algum item que precisa ser reposto O que podemos oferecer para resolver o problema de Marcos Soluções propostas Podemos propor como solução do problema de Marcos projetar um Data Mart e construir consultas onde o menor nível de análise estivesse em Mês Exemplo Consulta de quantidade de itens por Mês Essa solução resolveria o problema de Marcos Não resolveria Primeiramente o tempo de desenvolvimento desse cenário poderia durar em torno de dois meses A consulta por quantidade de itens por mês pode até ser útil para outro tipo de tomada de decisão inclusive para a melhoria do processo de Marcos mas não para sua necessidade atual Uma investigação mais detalhada sobre o problema de Marcos permitiu verificar a solução mais adequada para resolver seu problema De acordo com a necessidade descrita anteriormente um relatório no sistema de vendas fornecerá a informação sobre os itens que precisam ser repostos Conclusão do cenário Com a observação e análise do caso é fácil concluir que o planejamento do projeto e o levantamento de requisitos produzem o entendimento sobre a necessidade da organização e o conhecimento do objetivo para a construção do DW que deve estar bem definido e justificar essa necessidade Sem essas definições o sucesso do projeto está comprometido pois se não houver um objetivo para tal solução o ambiente não será utilizado ou sua construção poderá não ser finalizada Levantamento de requisitos para construção do Data Warehouse Você já deve ter escutado comentários sobre um projeto que não deu certo e o desenvolvimento foi cancelado ou que o desenvolvimento foi finalizado mas os usuários não utilizaram o produto entregue Atenção O entendimento sobre o problema a ser resolvido deve ser a primeira tarefa realizada para o desenvolvimento de um projeto pois a investigação permite conhecer o cenário os stakeholders partes interessadas o problema e as possíveis soluções a serem adotadas Passo 1 Entender as necessidades do negócio stakeholders O entendimento da necessidade é realizado pelo analista de negócios Ele é responsável por investigar a necessidade entender as dores dos usuários e traduzir o entendimento em requisitos para o projeto Kimball e Ross 2013 abordam o levantamento de requisitos focado na necessidade do negócio e afirmam que os requisitos determinam quais dados devem estar disponíveis no DW como são organizados e com que frequência são atualizados Dica O primeiro passo é entrevistar os usuários e entender quais são as atividades realizadas por eles Conhecer a atividade realizada pelo usuário auxilia no entendimento do fluxo dos dados que será analisado Você pode realizar reuniões mais específicas com usuários individuais pequenos grupos ou grupos que reúnem todos os interessados no desenvolvimento do DW A estratégia pode ser traçada conforme a necessidade O levantamento de requisitos é apoiado por técnicas que auxiliam a condução das entrevistas Durante essa fase as informações coletadas devem ser anotadas O resultado do levantamento conterá a descrição de cenário do negócio com as dores os objetivos as análises desejadas etc Nas análises desejadas podem ser identificadas as possíveis perspectivas de análise e os indicadores As perspectivas de análise descrevem os fatos que ocorreram em determinado assunto e os indicadores são as medidas que podem ser descritas pelas perspectivas de análise Quando a carga dos dados ocorre diariamente o processo de ETL acessa a base de dados do sistema transacional todos os dias obedecendo a uma janela temporal para a extração dos dados Normalmente a extração ocorre no período em que as transações dos sistemas de origem são diminuídas como por exemplo à noite Essa estratégia é usada para que a extração dos dados não concorra com as operações transacionais prejudicando o andamento das operações na organização Quando a carga é realizada mensalmente o processo de ETL acessa a base de dados do sistema transacional após o fechamento mensal do negócio populando a base do DW apenas uma vez ao mês Essa informação deve estar registrada no documento principal de especificação do projeto Passo 2 Elaborar documento com perspectivas de análises visões Todo entendimento deve ser documentado para que os demais analistas tenham acesso às informações do projeto Normalmente cada organização usa uma metodologia que melhor se encaixa às suas necessidades No entanto independente da metodologia adotada as perspectivas de análise precisam ser definidas e descritas Elas são representadas pelas tabelas Dimensões do modelo de dados do DW e contêm os dados que descrevem os fatos Vamos entender com um exemplo Cenário 2 Vamos relembrar o cenário de análise do supermercado Paulo e Ricardo são gerentes de uma grande rede de supermercados Eles contrataram o desenvolvimento de uma solução que apoie a tomada de decisão da organização Para entender as necessidades de Paulo e Ricardo algumas reuniões de levantamento foram feitas com eles e com alguns usuários que constroem análises gerenciais Durante as reuniões foram coletadas as seguintes informações opulando a Base Inserindo dados nas tabelas que compõem a base 1ª Característica O supermercado possui um sistema de apoio ao fluxo de vendas que recebe todas as ocorrências de eventos de compras realizadas pelos clientes em lojas físicas e pelo ecommerce 2ª Característica Todas as operações de inclusão alteração e deleção de registros ocorrem durante o período do atendimento ao cliente 3ª Característica Sempre que uma venda ocorre um serviço informa ao sistema de estoque quais produtos foram vendidos e a quantidade vendida A Visão Dimensão contém os dados referentes ao domínio que está sendo tratado Por exemplo a visão Produto contém o código do Produto que é importante na identificação do produto no sistema origem e a descrição do produto permite saber qual é o produto analisado O quadro a seguir ilustra a documentação da visão Produto Produto Código do produto Descrição do produto Fabricante do produto Categoria do produto Descreve os produtos do DW Supermercado Identifica unicamente um produto no sistema SisVendas Nome do produto que está sendo comercializado no SisVendas Fabricante do produto que está sendo comercializado no SisVendas Grupamento do produto que está sendo comercializado no SisVendas 1 2 3 Detergente Limpa Limpeza Códigos de produtos que deixaram de ser comercializados não podem ser reutilizados em novos produtos Pode conter até 100 caracteres Pode conter até 200 caracteres Pode conter até 50 caracteres A coluna Visão de análise contém o nome da visão a coluna Atributo apresenta os dados referentes ao produto e a coluna Conceito descreve cada um dos atributos O conceito é extremamente importante para um ambiente analítico pois o usuário e os analistas saberão o que é o dado tanto na construção das análises quanto na manutenção do ambiente A coluna Exemplos contém alguns exemplos dos dados para auxiliar nas próximas etapas do projeto A coluna Observação é livre para adicionar comentários importantes sobre cada um dos dados caso tenham e regras de negócio que deverão ser aplicadas aos dados Resposta Visões Cliente e Categoria do Produto Passo 3 Elaborar documento com as medidas que serão analisadas indicadores Após a documentação das visões de análise é hora de documentar as medidas também conhecidas como indicadores Os indicadores são organizados em tabelasfato que registram os fatos ocorridos No cenário do supermercado foram identificados os seguintes indicadores Quantidade de Produtos Vendidos Quantidade de Produto no Estoque Preço do Produto Vendido Preço do Produto Comprado do Fabricante Lucro do Produto Vendido O quadro a seguir ilustra a conceituação dos indicadores identificados durante o levantamento com os usuários Indicador Quantidade de Produtos Vendidos Quantidade de Produto no Estoque Preço do Produto Vendido Preço do Produto Comprado do Fabricante Lucro do Produto vendido Conceito Quantidade do produto vendido em um pedido Preço do produto no momento da venda Preço do produto quando foi comprado do fabricante ou distribuidor Lucro obtido na venda do produto Lucro obtido na venda do produto Fórmula de cálculo Soma das unidades do produto Soma das unidades do produto Não há Não há Preço do Produto Vendido Preço do Produto Comprado do Fabricante Observação Apresentar o cálculo da função soma de quantidades vendidas Apresentar o cálculo da função soma de quantidades em estoque Apresentar o valor com formatação de moeda e com duas casas decimais Apresentar o valor com formatação de moeda e com duas casas decimais Apresentar o valor com formatação de moeda e com duas casas decimais A coluna Indicador lista o nome dos indicadores a coluna Conceito lista os conceitos ou as definições dos indicadores a coluna Fórmula de cálculo descreve como os indicadores devem ser calculados e a coluna Observação contém informações adicionais Matriz de granularidade Para facilitar o entendimento e a compreensão da relação entre as visões e os indicadores do DWDM temos a matriz de granularidade Em formato de matriz são organizados as visões atributos e os indicadores que estão relacionados com essas visões O quadro a seguir ilustra a relação entre as visões identificadas no levantamento e os indicadores que serão analisados nas consultas predefinidas Visões Venda ao cliente Estoque Cliente Indicadores venda da Data venda de Mês venda da Ano estoque Data do estoque Mês do estoque Ano do cliente do Número cliente do Nome Quantidade de produtos vendidos x x x x x Quantidade de produtos no estoque x x x Preço do produto vendido x x x x x Preço do produto comprado do fabricante x x Lucro do produto vendido x x Comentário Como podemos observar no eixo X da matriz estão organizadas as Visões Tempo Cliente Fabricante e Produto No eixo Y da matriz estão organizados os Indicadores Quantidade de Produtos Vendidos Quantidade de Produto no Estoque Preço do Produto Vendido Preço do Produto Comprado do Fabricante e Lucro do Produto Vendido De acordo com a matriz sabemos que a Quantidade de Produtos Vendidos pode ser analisada pela data de venda do produto ao cliente Por exemplo sabemos a quantidade de sabonetes vendidos no dia 20082020 no mês 082020 ou ainda no ano de 2020 Em nosso exemplo há poucas visões e indicadores o que facilita saber quais são os possíveis cruzamentos entre eles No entanto no levantamento de um DWDM real há inúmeros cruzamentos e a matriz permite a visualização das análises que serão possíveis no ambiente analítico de forma mais simples e objetiva Além disso a matriz de granularidade apoia os analistas que estão atuando no projeto Você observou que essa matriz se chama matriz de granularidade A granularidade é referente ao grão de análise do DWDM ou seja o nível de detalhamento dos dados Quanto mais granularmenor a granularidade mais detalhada é a informação Quanto mais alta a granularidade menos detalhada é a informação Comentário Por exemplo é possível analisar o Preço do Produto Vendido por data da venda dia mês e ano mas o Preço do Produto Comprado do Fabricante só pode ser analisado por mês e pelo ano Isso significa que a informação sobre a venda dos produtos ao cliente é mais granular do que a informação sobre a compra do produto com o fabricante para o abastecimento do estoque Passo 4 Elaborar documento que descreva as análises desejadas consultas O documento das análises predefinidas deve conter o layout de todas as consultas desejadas pelos usuários e identificadas durante o levantamento das necessidades Pode acontecer de novas análises surgirem ao longo do projeto Se essa nova análise utilizar as visões e indicadores já mapeados no levantamento será simples desenhar esse novo layout e entregar a análise ao cliente deixandoo satisfeito com a entrega e agregando valor à organização Contudo se as visões ou os indicadores não estiverem mapeados os participantes do projeto tanto analistas quanto usuários deverão ser reunidos para que seja estudada a melhor forma de atendimento da nova necessidade Para isso alguns pontos precisam ser considerados no impacto no projeto como tempo e dinheiro A seguir veja um exemplo de especificação de consulta Mês de venda Produto Categoria Quantidade de Produtos Vendidos Abril 2020 Código 1 2 3 Descrição Sabonete Pão de Forma Suco de Uva Integral Descrição Higiene Padaria Bebida 1523 150 63 Quadro Vendas de produtos por mês Elaborado por Vivian Monteiro Dado Sistema de Origem Tabela Tela Produto Sisvendas Produto TB Produto Quadro Apontamento de origem do dado Elaborado por Vivian Monteiro O apontamento da origem dos dados é muito importante pois pode ser que o dado não exista no sistema transacional ou ainda pode não ser possível extraílo do sistema origem Uma vez que essa situação ocorra deve ser levado ao gestor para que o entendimento seja alinhado sobre o dado Mapeamento das fontes de dados Dando sequência à fase de levantamento de requisitos temos o mapeamento das fontes de dados conforme observado na imagem Levantamento de Requisitos Mapeamento das fontes de Dados 1 Verificar as origens apontadas 2 Elaborar documento com o mapeamento das fontes dos dados Mapeamento das fontes de dados Verificar as origens apontadas é uma análise mais detalhada da origem dos dados mapeados nas etapas anteriores em que ocorre a especificação da necessidade e os conceitos são definidos O analista que realiza essa tarefa poderá localizar o dado no sistema origem conhecer sua localização com o nome da tabela que será acessada o nome o tamanho e o tipo de dado do campo Comentário Se o sistema transacional for muito antigo ou não houver documentação sobre ele a investigação mais profunda da origem poderá trazer surpresas que precisam ser tratadas e contornadas Descrição O objetivo do relatório é apresentar a quantidade de produtos vendidos por mês Visões Mês da venda Produto código e descrição Categoria do produto Indicadores Quantidade de produtos vendidos Filtros O filtro Mês é de preenchimento obrigatório O relatório deve permitir filtrar por Categoria de Produtos A descrição de uma análise deve conter o desenho do relatório ou dashboard para que seja possível o alinhamento das expectativas com o cliente O desenho permite que ele visualize suas futuras análises de forma mais fácil e mais aproximada do produto que será entregue Além dos desenhos devem estar presentes a descrição de cada análise com o objetivo os atributos que estarão na análise os indicadores filtros obrigatórios e filtros dinâmicos caso sejam necessários Passo 5 Elaborar documento com apontamento das origens dos dados Com o mapeamento das visões de análise e dos indicadores é possível verificar a origem dos dados Essa verificação normalmente é feita com os analistas responsáveis pelos sistemas transacionais A existência de cada uma das visões e dos indicadores no sistema origem deve ser checada O quadro a seguir ilustra um exemplo A conceituação obtida com os gestores auxiliará na identificação do dado no sistema origem e será utilizada na integração de dados caso venham de sistemas diferentes Durante o mapeamento das origens podem ser definidas regras a serem aplicadas na etapa de construção do ETL O quadro a seguir ilustra um exemplo Dado Sistema origem Tabela Tela Produto SisVendas Produto TBProduto Cadastro do Produto Quadro Mapeamento das fontes de dados Elaborada por Vivian Gabriela dos Santos Medeiros adaptada por João Paulo Coelho Saiba mais String Tipo de dados formado por uma cadeia de caracteres de um idioma letras números caracteres especiais Elaborar documento com o mapeamento das fontes de dados pode ser uma versão estendida do documento de apontamento da origem de dados acrescentado as informações levantadas pelo analista técnico Levantamento de requisitos e matriz de granularidade No vídeo a seguir demonstramos o processo de levantamento de requisitos dentro do ciclo de vida de um projeto mostrando a importância da matriz de granularidade ao longo desse ciclo de vida Falta pouco para atingir seus objetivos Vamos praticar alguns conceitos Relaciona as visões que serão desenvolvidas com seus conceitos e explicita o grão dos dados contidos no DWDM Parabéns A alternativa A está correta A matriz de granularidade tem como objetivo apresentar de forma visual a relação entre as visões e os indicadores pois à medida que o projeto cresce a quantidade de relações aumenta tornando difícil a gestão dessas relações A matriz serve como norteadora para auxiliar quais perguntas feitas pelo usuário serão possíveis responder com o modelo atual O termo granularidade faz referência ao grão da informação ou seja em que nível de detalhamento os dados estão armazenados quanto mais granularmenor a granularidade mais detalhada a informação está armazenada Considerações finais Ao longo deste conteúdo trabalhamos os conceitos de Business Intelligence BI e seu componente Data Warehouse DW e compreendemos as diferenças entre os Sistemas de Apoio Operacional e os Sistemas de Apoio à Decisão Em seguida abordamos a arquitetura do DW como um conjunto de Data Marts DM e o ciclo de vida do projeto de DW Neste ciclo focamos na fase de levantamento de requisitos em que são analisadas as necessidades dos usuários Ressaltamos aqui a importância de documentar o conhecimento adquirido no levantamento de requisitos pois os artefatos produzidos nessa fase são utilizados pelos analistas que participam da construção do DWDM pelos usuários que farão suas análises no ambiente e pelas pessoas que futuramente possam interagir com o ambiente analítico auxiliando no crescimento e na manutenção do projeto Podcast Encerramos o nosso estudo falando sobre os principais tópicos abordados no tema Ouça tudo isso no podcast a seguir Para ouvir o áudio acesse a versão online deste conteúdo Referências BARBIERI C Governança de dados práticas conceitos e novos caminhos Rio de Janeiro Alta Books 2020 DEVLIN B A MURPHY P T An architecture for a business and information system In IBM Systems Journal v 27 n 1 p 6080 1988 GARTNER Gartner glossary Consultado em meio eletrônico em 10 jun 2021 INMON B IMHOFF C Corporate Information Factory CIF overview Colorado Inmon Consulting Services 2001 KEMPE S A short history of Data Warehousing California Dataversity 2012 KIMBALL R The Data Warehouse toolkit técnicas para construção de Data Warehouses dimensionais 1 ed Rio de Janeiro Makron Books 1998 KIMBALL R ROSS M The Data Warehouse toolkit the definitive guide to dimensional modeling 3 ed Indianapolis John Wiley Sons 2013 LAUDON K C LAUDON J P Sistemas de Informação Gerenciais 11 ed São Paulo Pearson 2014 MONTEIRO V G S Arquitetura de Data Warehouse e Data Marts Rio de Janeiro YDUQS 2020 Explore Conheça o guia Business Analysis Body of Knowledge BABOK que reúne os principais conceitos e técnicas que apoiam a análise de negócios e aprofunde seus conhecimentos sobre a análise de requisitos por meio do Portal de Análise de Negócios para o público brasileiro IIBA International Institute os Business Analysis Conheça o primeiro artigo técnico que utilizou o termo Business Intelligence de autoria de H P Luhn em 1958 A Business Intelligence System publicado no IBM Journal of Research and Development Veja como a polêmica sobre as arquiteturas de Inmon x Kimball ainda persistem mesmo após mais de duas décadas de discussões no artigo Data Warehouse Design Inmon versus Kimball publicado no The Data Administration Newsletter Veja a aplicação prática do uso de dados não estruturados para complementar ambientes de análises nos trabalhos desenvolvidos por João Luiz Moreira Kelli de Faria Cordeiro e Maria Luiza M Campos DoctorOLAP Ambiente para análise multifacetada de prontuários médicos JoinOLAP Sistema de informação para exploração conjunta de dados estruturados e textuais um estudo de caso no setor elétrico