Business Intelligence

O termo BI surgiu na década de 80, cunhado pelo Gartner Group, e tem como principais características:

  • Extrair e integrar dados de múltiplas fontes;

  • Fazer uso da experiência;

  • Analisar dados contextualizados;

  • Trabalhar com hipóteses;

  • Procurar relações de causa e efeito;

  • Transformar os registros obtidos em informação útil para o conhecimento empresarial.

Business Intelligence é o processo de analisar informações brutas acumuladas da empresa e a partir delas obter insights valiosos.

Business Intelligence permite que os responsáveis pelas decisões tenham as informações certas, na hora certa e no lugar certo, capacitando-os a tomar melhores decisões corporativas.

As aplicações de BI incluem:

  • Sistemas de suporte à decisão;

  • Consultas e relatórios (padronizadas e ad-hoc);

  • Análises OLAP (On-Line Analytical Processing);

  • Análises estatísticas;

  • Previsões;

  • Data Mining.

lu212826w83_tmp_dc1f8484281abeef

O conceito de BI pode ser compreendido como a utilização de variadas fontes de informações para se definir estratégias de competitividade nos negócios da empresa. Atualmente as organizações geram grandes quantidades de dados, mas enfrentam dificuldades na extração de informações. Esse crescimento das informações dificulta o processo de tomada de decisão, na medida em que a alta e a média gerência sentem-se inúteis no processo de sua procura e recuperação.

Aplicações do negócio constituem as aplicações que dão suporte ao dia a dia do negócio da empresa, que garantem a operação da empresa, também chamadas de sistemas de produção;

Aplicações sobre o negócio: são as aplicações que analisam o negócio, ajudando a interpretar o que ocorreu e a decidir sobre estratégias futuras para a empresa – compreendem os Sistemas de Apoio à Decisão (SAD).

Consultas típicas de um SAD são:

  • Listar a evolução das vendas nos últimos 10 anos;

  • Listar o fornecedor que não teve mais do que 20% de atrasos nas últimas 100 entregas.

Os sistemas legados e os ERP não disponibilizam as informações gerenciais na sua forma mais agradável. Ao contrário, as informações cruciais para a tomada de decisões estratégicas estão ocultas em milhares de tabelas e arquivos inacessíveis aos leigos na área de computação, conectadas por relacionamento e correlações transacionais em uma forma inadequada para os tomadores de decisão. Desta forma, o conhecimento corporativo e as informações externas não estão prontamente disponíveis para sua utilização.

Neste contexto, o BI tem com seu principal objetivo a definição de técnicas para a formatação adequada destes volumes de dados, visando transformá-los em depósitos estruturados de informações, independente de sua fonte. Os dados poderão ser extraídos usando técnicas emergentes de garimpo de informações via CI (Competitive Intelligence), ou de fontes conceituais como KMS (Knowledge Work Systems – Base de Conhecimento). Ambas as formas, a definição de estruturas modeladas dimensionalmente armazenados em Data Warehouses ou DM (Data Marts) e interpretadas pela visão analítica das ferramentas OLAP (On-Line Analytical Processing) ou pelas ferramentas de Data Mining, atingem o objetivo proposto pelas premissas de BI.

ETL (Extract, Transform and Load)

Um dos processos de um DW consiste na extração dos dados dos sistemas operacionais, na organização e integração desses dados de forma consistente. A extração, organização e integração dos dados devem ser realizadas com a intenção de garantir a consistência e integridade das informações, construindo desta forma uma base de dados de alta qualidade e confiabilidade, que retrate a realidade do negócio da empresa. Esses sistemas ou aplicações são responsáveis pela filtragem, limpeza, sumarização e concentração dos dados espalhados pelas fontes externas e nos sistemas operacionais. A maior parte dessas ferramentas possuem interfaces gráficas e interativas que auxiliam na realização do mapeamento de dados e a automação do processo de extração, limpeza e carga, sendo fortemente baseadas na linguagem SQL (Structured Query Language).

Podem haver alguns problemas, chamados de Conflitos Semânticos e Estruturais:

  • Diferenças de unidades;

  • Diferenças de precisão;

  • Diferenças em código ou expressões;

  • Diferenças de granularidade;

  • Diferenças de abstração.

Os conceitos de extração dos dados e de seu tratamento podem ser divididos em:

  • Filtro de dados: relaciona os procedimentos e condições para se eliminar os elementos indesejáveis no modelo dimensional;

  • Integração de dados: caracteriza a forma de se correlacionar informações existentes em fontes distintas, e que deverão ser integrados ao sistema gerencial;

  • Condensação de dados: define a maneira de reduzir o volume dos dados com o objetivo de obter informações resumidas e sumarizadas. Geralmente essas sumarizações acontecem nas dimensões dos dados, como tempo e localização geográfica;

  • Conversão de dados: especifica os procedimentos para se transformar dados em unidades, formatos e dimensões diferentes;

  • Derivação de dados: são os meios e fórmulas para gerar dados virtuais, a partir de dados existentes.

O desenvolvimento de programas de extração requer, dos analistas envolvidos, um bom conhecimento das bases de dados das quais as informações serão extraídas e da base em que serão armazenadas. O conhecimento necessário consiste no acesso aos catálogos dos bancos de dados mapeados como fontes de informação, assim como o pleno domínio dos metadados do modelo multidimensional do DW ou do DM.

Data Warehouse

Data Warehouse pode ser definido como um banco de dados especializado, o qual integra e gerencia o fluxo de informações a partir dos bancos de dados corporativos e fontes de dados externas à Organização. Um DW oferece os fundamentos e os recursos necessários para um Sistema de Apoio a Decisão (SAD) eficiente, fornecendo dados integrados e históricos que servem desde à alta direção, que necessita de informações mais resumidas, até as gerências de baixo nível, onde os dados detalhados ajudam a observar aspectos mais táticos da Organização.

Um Data Warehouse (português brasileiro) ou armazém de dados (português europeu), ou ainda depósito de dados, é um sistema de computação utilizado para armazenar informações relativas às atividades de uma organização em bancos de dados, de forma consolidada. O desenho da base de dados favorece os relatórios, a análise de grandes volumes de dados e a obtenção de informações estratégicas que podem facilitar a tomada de decisão.

O data warehouse possibilita a análise de grandes volumes de dados, coletados dos sistemas transacionais (OLTP). São as chamadas Séries Históricas que possibilitam uma melhor análise de eventos passados, oferecendo suporte às tomadas de decisões presentes e a previsão de eventos futuros. Por definição, os dados em um Data Warehouse não são voláteis, ou seja, eles não mudam, salvo quando é necessário fazer correções de dados previamente carregados. Os dados estão disponíveis somente para leitura e não podem ser alterados.

A ferramenta mais popular para exploração de um data warehouse é a Online Analytical Processing (OLAP) ou Processo Analítico em Tempo Real, mas muitas outras podem ser usadas. Os data warehouse surgiram como conceito acadêmico na década de 80. Com o amadurecimento dos sistemas de informação empresariais, as necessidades de análise dos dados cresceram paralelamente. Os sistemas OLTP não conseguiam cumprir a tarefa de análise com a simples geração de relatórios. Nesse contexto, a implementação do data warehouse passou a se tornar realidade nas grandes corporações. O mercado de ferramentas de data warehouse, que faz parte do mercado de Business Intelligence, cresceu então, e ferramentas melhores e mais sofisticadas foram desenvolvidas para apoiar a estrutura do data warehouse e sua utilização. Atualmente, por sua capacidade de sumarizar e analisar grandes volumes de dados, o data warehouse é o núcleo dos sistemas de informações gerenciais e apoio à decisão das principais soluções de Business Intelligence do mercado.

O conceito de Data Warehousing não é recente, foi inicialmente apresentado pela IBM como uma infraestrutura.

Segundo Bill Inmon, Data Warehouse é uma base de dados que utiliza a integração e síntese de dados para fornecer apoio e suporte ao processo de tomada de decisão; essa base de dados é orientada a assunto, integrada, variável com o tempo e não volátil. O armazenamento dos dados em estruturas lógicas dimensionais permite o seu processamento analítico por ferramentas OLAP e Data Mining.

Um DW é um conjunto de diversas tecnologias, como ferramentas de extração e conversão, banco de dados voltados para consultas complexas, ferramentas inteligentes de prospecção e análise de dados, ferramentas de administração e gerenciamento.

As organizações geram e captam dados sobre todos os aspectos dos seus negócios. Em grande parte estes dados estão sendo armazenados e manipulados para suportar suas atividades críticas com o uso dos sistemas de processamento de transações On-Line (OLTP), que têm como característica principal o baixo tempo de resposta para processar as suas requisições.

A principal justificativa para utilização da tecnologia de DW em uma organização é a existência na empresa de:

  • Diversas plataformas de hardware e software;

  • Modificações constantes nos sistemas transacionais corporativos;

  • Existência de diversos sistemas fechados de fornecedores diferentes;

  • Inexistência de padronização e integração dos dados nos diversos sistemas;

  • Deficiência de documentação e segurança no armazenamento dos dados;

  • Dificuldade de implantação de sistemas de informação executiva (EIS) ou de apoio à decisão (DDS) devido a dependências múltiplas de sistemas corporativos.

Características

Abaixo são descritas, segundo Inmon, as principais características de um DW.

  • Orientação por assunto: Significa que um DW armazena as informações agrupadas por assuntos de maior interesse da empresa, em contraste com os sistemas operacionais que são orientados a processos desenvolvidos para manter as transações realizadas diariamente.

  • Integração: Essa é uma das mais importantes características do DW. Através dela é possível padronizar uma representação única para os dados de todos os sistemas que formarão a base de dados do DW.

  • Variação de tempo: Os dados de um DW são valiosos em relação ao tempo e significam resultados operacionais em determinado momento de tempo. Os dados de um DW são uma imagem, um conjunto estático de registros de uma ou mais tabelas, capturados em um determinado momento de tempo predeterminado. Logo, os dados do DW não podem ser atualizados. Por exemplo, os dados sobre as vendas de um determinado mês jamais terão seus valores modificados.

  • Não volátil: No ambiente operacional, os dados são atualizados frequentemente. Todavia, os dados existentes no DW apresentam características diferentes. Os dados do DW são somente carregados (inseridos) e acessados (visualizados). Raramente ocorre uma atualização de dados em um ambiente de DW (correção de inconsistências por exemplo).

OLTP x OLAP

lu212826w83_tmp_2dcaaafce560f7f9

A característica simples mais distintiva dos aplicativos OLTP (On-line Transaction Processing) é que o banco de dados está sendo constantemente atualizado. Como os dados estão mudando constantemente, o sistema não pode ajudar no apoio a decisões.

De um ponto de vista prático, OLAP (On-line Analytic Processing) sempre envolve consultas interativas aos dados, seguindo um caminho de análise através de múltiplos passos, como, por exemplo, aprofundar-se sucessivamente por níveis mais baixos de detalhe de um quesito de informação específico. OLAP envolve capacidades analíticas, incluindo a derivação de taxas, variâncias, etc., e envolvendo medidas ou dados numéricos através de muitas dimensões, devendo suportar modelos para previsões, análises estatísticas e de tendências.

lu212826w83_tmp_46590d17674fd6f5

Data Mart

Um Data Mart (DM) pode ser representado como um subconjunto de dados do DW, possibilitando um acesso descentralizado que serve de fonte para os dados que integrarão os bancos de dados individuais. Sua utilização tem como principal vantagem o retorno rápido, assegurando um maior envolvimento com o usuário final, o que possibilita uma melhor avaliação dos benefícios extraídos de seu investimento.

“Os Data Marts diferem dos Data Warehouse no sentido de que, enquanto o Data Warehouse se concentra nas necessidades da empresa inteira, os Data Marts são dedicados a áreas de assuntos específicas ou às necessidades de um departamento ou função empresarial em particular. […]”

Arquitetura de um Data Warehouse

A arquitetura deve ser determinada de acordo com o local em que o DW ou DM estarão localizados. As três arquiteturas básicas são a global, independente e integrada.

Global

Nesta arquitetura o DW é projetado de acordo com as necessidades da empresa como um todo. Pode ser definido como um repositório comum de dados de suporte à decisão, disponível para toda a empresa. O termo global reflete o escopo de acesso e utilização das informações da empresa, não sendo necessariamente centralizado. Esta arquitetura pode ser fisicamente centralizada ou distribuída na estrutura de uma empresa. Geralmente a centralização física é escolhida quando a empresa existe em um único local e o DW é administrado por um setor de tecnologia da informação. A distribuição física de um Data Warehouse é empregada quando a empresa possui sua estrutura física em diversos locais e os dados em múltiplas instalações, possuindo também um setor de administração de tecnologia da informação. A arquitetura global possibilita aos usuários finais utilizar visões corporativas de dados. Porém, esse tipo de ambiente possui um custo de implementação muito alto devido ao grande tempo necessário para desenvolvimento e administração.

lu212826w83_tmp_61c0e5538a96213a

Independente

Essa é a arquitetura favorita dos fornecedores de software para consulta de informações de DW. Esse tipo de arquitetura requer DM separados controlados por grupos específicos de usuários, e que atendem somente às suas necessidades específicas e departamentais, sem qualquer foco corporativo. Consequentemente, não existe nenhuma conectividade desses Data Marts com os de outros departamentos ou áreas de negócio. A arquitetura independente demanda os mesmo perfis técnicos para a implantação, mas os recursos e pessoal operacional podem ser administrados pelo grupo de trabalho ou departamento. Sua restrição é que possui um mínimo de integração corporativa e não permite nenhuma visão global da empresa.

lu212826w83_tmp_9a8a5c241cf22739

Integrada

A arquitetura de Data Marts integrados é basicamente uma distribuição de implementação. Embora os DM sejam implementados separadamente por grupos de trabalho ou departamentos, eles são integrados, disponibilizando maior visão corporativa dos dados e informações. Pode-se comparar com a arquitetura global devido ao alto nível de integração. Esse tipo de arquitetura possibilita muitas outras funções e capacidades de informação em relação à arquitetura independente. Consequentemente, a integração aumenta sensivelmente o nível de complexidade de requisitos. Em compensação ocorre um aumento da capacidade e de qualidade de visão corporativa de informações quando optamos por compartilhar dados entre os Data Marts. Nesta situação a atuação da área de tecnologia da informação deve ser superior a da arquitetura independente.

lu212826w83_tmp_401dae1a84ed9f3e

Implementação

A escolha por um tipo de abordagem é influenciada por diversos fatores entre eles: recursos de infraestrutura de tecnologia, a arquitetura escolhida, o escopo da implementação, os recursos disponíveis, velocidade de implementação e, principalmente, para uma possível necessidade de acessos aos dados, bem como o retorno do investimento pretendido. Basicamente, existem três maneiras de implementação: Top Down, Bottom Up, Combinada.

Kimball aponta um conjunto de pontos fundamentais no projeto da estrutura de DW (tipo estrela). São os seguintes os chamados pontos de decisão, que constituem definições a serem feitas e correspondem, de fato, a etapas do projeto:

Os processos, e por consequência, a identidade das tabelas de fatos;

  • A granularidade de cada tabela de fatos;

  • As dimensões de cada tabela de fatos;

  • Aos fatos, incluindo fatos pré-calculados;

  • Os atributos das dimensões;

  • Como acompanhar mudanças graduais em dimensões;

  • As agregações, minidimensões e outras decisões de projeto físico;

  • Duração histórica do banco de dados;

  • Urgência com que se dá a extração e carga para o DW.

Esta metodologia segue a linha top-down, pois começa identificando os grandes processos da empresa.

Bottom Up ou Estratégia Evolucionária

  • Histórico de sucesso das aplicações;

  • Usuário final não terá condições de expressar suas necessidades com clareza antes da primeira interação;

  • A gerência não se comprometerá antes da primeira interação;

  • Há necessidade de, rapidamente, obter resultados visíveis.

lu212826w83_tmp_76d5b5089f2eb3db

Top Down (Abordagem de Inmon)

Essa abordagem foi sugerida por Inmon e baseia-se em um DW corporativo central, fundamentado no modelo relacional e totalmente normalizado. O processo de extração, transformação, carga e, consequentemente, a área de estágio de dados, são implementados de forma única e integrada. Este DW corporativo contempla todos os dados organizacionais e tem o objetivo servir de base de dados para os diversos Data Marts departamentais implementados de acordo com o modelo dimensional.

Vantagens:

  • Regras de negócio e definição dos dados de forma mais consistente;

  • Permite uma fácil manutenção por utilizar a arquitetura de DW para originar outros DM;

  • Devido ao desenvolvimento da extração de dados ser feito uma única vez, evita-se o retrabalho;

Desvantagens:

  • Precisa da participação de toda organização;

  • Tempo de implementação muito longo. Em média, são necessários mais de 15 meses para o desenvolvimento e produção da primeira área de assunto;

  • Os gastos iniciais com aquisição do hardware, infraestrutura e formação da numerosa equipe técnica são excessivamente altos;

  • Elevada taxa de risco por não existirem garantias neste tipo de investimento;

Bottom Up

A implementação Botton Up se baseia na construção de DM dimensionais independentes, cada um com sua respectiva área de estágio e processos de extração, transformação e limpeza e metadados. Neste tipo de implementação o DW é composto pelo conjunto de todos os Data Marts construídos, criando um DW incremental lógico.

Vantagens:

  • Rápida implementação com a construção direcionada dos DM;

  • A apresentação dos primeiros resultados é feita de modo rápido e barato;

  • Menor taxa de risco possibilitando investimentos adicionais.

Desvantagens:

  • Falta de planejamento de integração entre os DM;

  • Maior chance de incoerência nos dados, devido a diferentes representações e fontes de dados;

  • A integração dos DM em um DW global pode ser difícil até uma determinada fase do projeto.

Inmon: “É um engano pensar que os enfoques de projeto que funcionaram no passado serão úteis na construção do DW. Os requisitos para a criação de um DW não podem ser conhecidos até que ele seja parcialmente povoado e sendo usado pelo analista de SAD. Portanto, ele não pode ser projetado do mesmo modo pelo qual são construídos os sistemas clássicos baseados em requisitos. Por outro lado, também constitui um engano pensar que não prever requisitos seja uma boa ideia. A realidade se encontra em algum ponto intermediário.” (estratégia evolucionária)

Combinada

O objetivo das técnicas Top Down e Bottom Up combinadas é aproveitar ao máximo as características positivas de cada uma das implementações. Embora seja difícil de implementar, alguns autores afirmam que um bom gerente de projeto pode executar esta tarefa. A monitoração cuidadosa do processo de implementação, o acompanhamento e gerenciamento dos novos requerimentos auxiliam a alcançar melhores benefícios de ambas as técnicas.

Vantagens:

  • Garantia da consistência dos dados com a utilização da modelagem de dados única para os DM;

  • As ferramentas de extração são desenvolvidas uma única vez.

Desvantagens:

  • Complicações políticas em decorrência da determinação da sequência de implementação dos DM e das prioridades de manutenção;

  • Metadados complexos para gerenciar.

Metadados

Os metadados podem ser definidos como dados sobre dados. Mais exatamente como dados de mais alto nível que descrevem dados de um nível inferior. Os metadados podem ser comparados com uma enciclopédia para o DW que referencia todas as informações no seu ambiente, inclusive os que não são propriamente dados. Metadados que envolvem os sistemas de gerenciamento de banco de dados (SGBD) do DW são responsáveis por itens como tabelas de sistemas, configurações de partições, índices, definições de exibição e concessões de privilégios de segurança do SGBD.

De uma maneira geral, existem três camadas de metadados em um DW:

  • Metadados operacionais: definem a estrutura dos dados mantidos pelos bancos de dados operacional, usado pelas aplicações de produção da organização;

  • Metadados centrais do DW: São armazenados no catálogo do DW. Caracterizam-se por serem orientados por assunto, definindo como os dados transformados devem ser interpretados. Contêm definições de agregados e campos calculados, assim como visões sobre cruzamento de assuntos;

  • Metadados do nível do usuário: mapeiam os metadados do DW para características que sejam familiares e apropriados aos usuários finais.

As fontes de metadados definem de onde os dados serão extraídos para compor os metadados. Classificam-se como de fontes formais, os que documentam a origem dos dados e fazem parte da documentação da empresa, e os de fontes informais que existem dentro da empresa mas não fazem parte do documentação formal.

Tipos de Data Warehouse

A construção e implementação de um ambiente de DW deve ser única e centralizada pelos seguintes motivos:

  • O volume de dados pode ser facilmente gerenciado;

  • Os dados de toda a empresa são integrados e apenas essa visualização é usada;

  • Existe dificuldade em integrar e acessar os dados em um único local, quando eles estão separados em vários locais na organização.

Outros motivos devem ser levados em consideração antes da definição do tipo de DW a ser implementado.

  • Objetivos do negócio: Imprecisão na definição das prioridades ou opções que influenciam o modelo de DW, como tamanho, localização, frequência de uso e manutenção;

  • Localização dos dados atuais: Compreender onde os dados estão, quais são as suas características e atributos, e a forma para acessá-los, são desafios para o fornecimento desses dados aos usuários finais;

  • Necessidade de transferência de dados: No inicio de um projeto de DW, normalmente supõe-se que haverá transferência de dados. No primeiro momento será mais fácil deixar os dados em sua localização inicial, a menos que seja realmente necessário realizar sua transferência;

  • Transferência de dados: Mesmo com a disponibilidade de ferramentas para transferir dados para qualquer lugar o desconhecimento dos atributos dos dados dificulta esta tarefa;

  • Local para onde transferir dados: Deverá ser realizada uma análise do ambiente operacional (servidor, redes locais, etc.) onde os dados serão armazenados;

  • Requisitos de suporte à decisão: Deverá ser capaz de atender às atividades de suporte à decisão e sistemas de informações gerenciais;

  • Preparação dos dados: Somente substituir os dados existentes em um campo por novas informações não refletirá o histórico da mudança de dados ao longo do tempo. Deve-se optar pela substituição dos dados ou procurar formas de atualizá-los, com base em alterações incrementais;

  • Requisitos de consulta e relatório: É uma das etapas mais importantes na implementação do DW. Devem-se analisar quais ferramentas serão necessárias e quais já estão disponíveis no mercado.

  • Integração do modelo de dados: Utilizando os modelos de dados existentes na organização, devem-se integrar os resultados ao desenvolvimento do DW e as ferramentas utilizadas pelos usuários finais;

  • Gerenciamento e administração: São as atividades que possibilitam a continuidade do DW após a sua construção.

Operational Data Storage (ODS)

Um Operational Data Storage (ODS), Staging Area (SA) ou ainda Dynamic Data Storage (DDS) representa um armazenamento intermediário dos dados, promovendo a integração dos dados do ambiente operativo antes de sua atualização no DW. Inicialmente, um ODS era considerado um repositório temporário que armazenava apenas informações correntes antes de serem carregadas para o DW, similar a uma cópia dos ambientes de sistemas transacionais em uma empresa.

Essa concepção se diferencia do conceito original pela sua periodicidade de armazenamento e pelo fato de não somente armazenar dados temporários para a carga do DW. Por não ser volátil, seus dados são armazenados ao longo do tempo e passam por alterações incrementais que ao longo do tempo, podendo se tornar um DW.

Para Kimball, um ODS é frequentemente implementado para produzir relatórios operacionais, principalmente quando nem os sistemas legados nem os sistemas de processamento de transações On-Line mais recentes fornecem relatórios operacionais adequados. Em outras situações, os ODSs são criados para suportar integrações em tempo real, principalmente aplicações de gerenciamento de relacionamentos com clientes.

Um ODS é o único lugar para se definir quais valores devem ser efetivamente importados dos sistemas legados. O ODS deve ser sempre utilizado para limpar dados desnecessários que entram no processo de extração e transformação, pois o quanto antes forem removidos, menor será possibilidade de erros.

Como não é um componente indispensável em um ambiente de DW, sua criação é uma decisão de projeto.

lu212826w83_tmp_c3b79045a4543349 .

Granularidade

Para Inmon (2000), a granularidade é a questão mais importante que um desenvolvedor precisa enfrentar em um projeto de DW. Quando a granularidade de um DW é definida corretamente, os demais aspectos de projeto e implementação seguem tranquilamente.

Granularidade de dados de um DW refere-se ao nível de sumarização dos elementos de dados e ao nível de detalhe disponível nos dados. Quanto mais detalhes disponíveis nos dados, menor é a granularidade e, consequentemente, quanto menor o nível de detalhes dos dados, maior é a granularidade.

A primeira etapa para a definição do nível apropriado de granularidade consiste em fazer uma estimativa bruta do número de linhas de dados e do Direct Access Storage Device (DASD) que o DW conterá. Na sequência, devem-se identificar as tabelas que serão criadas e estimar o tamanho da linha de cada tabela. Caso não seja possível identificar o tamanho exato, estimativas do limite inferior e superior são suficientes. Depois de realizadas as projeções de linhas de dados, as projeções do espaço de índices de dados são calculadas.

Neste ponto, os números máximos e mínimos de ocorrências de linhas das tabelas são multiplicados respectivamente pelos comprimentos máximos e mínimos dos dados. Por fim, multiplicam-se os números mínimos e máximos de ocorrências de linhas nas tabelas pelos comprimentos máximos e mínimos dos dados, respectivamente.

De acordo com Inmon, o próximo passo consiste em comparar o número total de linhas do ambiente do DW aos mapas apresentados na figura abaixo.

lu212826w83_tmp_755a89dbb137e68b

Conforme o número de linhas que existirão em um ambiente de DW, diferentes enfoques de projeto e desenvolvimento deverão ser utilizados. Em um horizonte de um ano, se a perspectiva for de um total de dez mil linhas ou menos, então qualquer técnica de projeto e implementação poderá ser utilizada. Ainda para o horizonte de um ano, se o total for de cem mil linhas ou menos, deve-se conduzir o projeto com cautela. Caso o esperado para um ano ultrapasse o total de um milhão de linhas, níveis duais de granularidade deverão ser utilizados. E, caso o número total de linhas do ambiente DW ultrapasse dez milhões de linhas, será necessário conduzir de forma extremamente cautelosa o projeto e sua implementação, e níveis duais de granularidade devem ser adotados.

Para o sucesso de um projeto de DW, é vital a escolha correta do nível ou níveis de granularidades. Para o mesmo autor, o método mais indicado para esse fim é o uso do bom senso e da análise meticulosa das necessidades de informação levantadas para o projeto. Deve-se ouvir o usuário, discutir e sugerir alternativas afim de atingir uma correta granularidade de projeto.

Modelagem Multidimensional

A modelagem multidimensional é uma técnica de concepção e visualização de um modelo de dados de um grupo de medidas que apresentam aspectos semelhantes de negócios. É usada especialmente para sumarizar e reestruturar dados e apresentá-los em visões que suportem a análise dos valores desses dados. O modelo multidimensional possui como conceitos gerais três elementos básicos: fatos, dimensões e medidas.

Fatos

Machado (2000) define as tabelas fato como uma coleção de itens de dados, composta de dados de medidas e contexto. Cada fato representa um item de negócio, uma transação ou um evento de negócio, e é utilizado para analisar o processo de negócio de uma empresa. De acordo com o mesmo autor, a característica básica de uma tabela fato é que ela é representada por valores numéricos.

Para Barbieri (2001), as tabelas fatos são utilizadas para armazenar medidas numéricas associadas a eventos de negócio. Possuem como chave primária um campo de chave múltipla, formado pelas chaves primárias das dimensões que com ela se relacionam. De acordo com o mesmo autor, deve-se ter cuidado com o crescimento de dados das tabelas fatos, pois normalmente armazenam muito mais dados que as tabelas dimensão.

lu212826w83_tmp_8ebc7fe6e32470dc

Tabela central do projeto dimensional. Armazena medições numéricas do negócio. Possui chaves de múltiplas partes. Cada chave é uma chave externa para uma tabela de dimensão. Cada uma das medições é obtida na interseção de todas as dimensões. Em consultas a tabela de fatos são usados centenas, milhares ou até milhões de registros para a construção da resposta.

Importante observar que a tabela fato é normalizada. Por esse motivo ela armazena as chaves primárias das dimensões e os dados numéricos (medidas) apenas. Os dados das dimensões também são numéricos mas são apenas referências e estes não são considerados medidas.

As tabelas FATOS são normalmente normalizadas. As tabelas DIMENSÕES são normalmente desnormalizadas (Esquema Estrela).O esquema floco de neve é uma variação do esquema estrela no qual todas as tabelas dimensão são normalizadas na terceira forma normal (3FN)(

A tabela de fato é normalizada até a 3FN (Kimball, Data Warehouse Toolkit).

Dimensões

As tabelas dimensão representam entidades de negócios e constituem as estruturas de entrada que servem para armazenar informações como tempo, geografia, produto, cliente, etc. Essas tabelas possuem uma relação 1:N (um para muitos) com a tabela fato, e a quantidade de dados é bem menor que nas fatos. Apresentam sempre uma chave primária para garantir a unicidade dos dados e participa da tabela fato como parte de sua chave múltipla.

Dimensões são conceitualmente os elementos que participam de um fato. Determinam o contexto de um assunto de negócios, por exemplo, um banco de dados que analisa as vendas de produtos possuem geralmente as dimensões tempo, localização, clientes, vendedores e cenários. O mesmo autor afirma que as dimensões normalmente não possuem atributos numéricos por serem somente descritivas e classificatórias dos elementos que participam de uma tabela fato.

Uma dimensão pode conter membros ou ser organizada em hierarquias.

Exemplos (Membros):

  • dimensão Tempo:

    • dia, semana, horário.

  • dimensão Locais:

    • bairro, cidade, estado.

Exemplos (Hierarquia):

lu212826w83_tmp_a964b55027e96bee

Medidas

As medidas são os atributos numéricos que representam o desempenho de um indicador de negócios relativo às dimensões que participam desse fato. Por exemplo, medidas são valor em reais de vendas, o número de unidades de produtos vendidos, a quantidade em estoque, o custo de venda, etc. Uma medida é determinada pela combinação das dimensões que participam de um fato e que estão localizados como atributos.

As medidas podem ser:

Medida distributiva: agregada por operação distributiva sobre dados atômicos ou medidas distributivas (count, sum, max, min)

Medida algébrica: agregada por operações algébricas sobre dados atômicos ou medidas distributivas ou algébricas (avg, standev)

Medida holística: agregada por operações sem limite constante sobre o espaço necessário para armazenar os sub-agregados (median, mode, rank). Em grandes data warehouses, cálculo apenas aproximativo

Modelo Estrela (Star Schema)

O termo Star Schema (modelo estrela) é geralmente utilizado para a designação de modelos de dados multidimensionais. Esse modelo é composto por uma grande entidade central denominada tabela fato e um conjunto de entidades menores denominadas dimensões, posicionadas ao redor desta entidade central, formando uma estrela, como mostra a figura abaixo:

lu212826w83_tmp_bc21d60e539ee671

Para Corey e outros, o modelo Star é a forma mais popular de construir estruturas de dados de DM de alto desempenho em um ambiente relacional. Para conseguir esses ganhos deve-se limitar o número de uniões que terão de ser realizadas e a complexidade de cada união.

Devido à maneira simples de organizar os dados, o modelo Star além de facilitar o processamento das consultas, permite uma melhor visualização dos dados.

Modelo Floco de Neve (Snowflake)

O modelo de dados multidimensional geralmente tem seu formato semelhante a uma estrela, onde a tabela fato está no centro e as tabelas dimensões ao seu redor formando as pontas. O modelo Snowflake (floco de neve) é o resultado da decomposição de uma ou mais dimensões que possuem hierarquias entre seus membros. Esse modelo é de fácil compreensão pela equipe de desenvolvedores de sistemas OLTP, devido à aplicação das formas normais como em projeto relacional. Por ser um modelo normalizado, ele impede a redundância de valores textuais em uma tabela.

Incorpora tabelas dimensionais principais, que têm uma conexão lógica direta em fact tables através de suas chaves primárias, e tabelas menores como ‘extensões’, que são usadas para armazenar descrições e decodificação para chaves e códigos nas tabelas maiores.

As tabelas dimensionais principais parecem tabelas dimensionais em estrela, exceto pelo fato das colunas atributo conterem chaves para as tabelas extensões em lugar de descrições de texto. As tabelas ‘extensões’ são conectadas com a tabela dimensional principal (ou com outras tabelas ‘extensões’) através de suas chaves primárias, e contêm texto decodificado e descrições de valores chave ou codificados, armazenados na tabela dimensional principal.

Embora aceitável, a normalização de dimensões não é recomendável por razões de desempenho e facilidade de uso:

  • A quantidade de tabelas torna a apresentação do modelo mais complexa.

  • Otimizadores do SGBD têm mais dificuldade com esquema complexo.

  • A economia de espaço em disco é insignificante em relação ao DW completo.

  • Diminui a habilidade de usuários de navegar na dimensão.

lu212826w83_tmp_b40561b700fa6630

Agregados

Segundo Barbieri, um passo importante no projeto lógico de um DW ou DM é a etapa que envolve a definição de agregados. Os valores agregados representam, paradoxalmente, uma solução e alguns problemas. Solução, pois estabelecem a definição e a criação de tabelas prontas, trabalhadas e sumarizadas em várias dimensões, o que facilita os acessos aos dados e agilizam os processos decisórios. Problemas, porque de certa maneira ferem as regras de não redundância, estabelecidas nos princípios de banco de dados desde sua criação. Além disso, os valores agregados utilizam mais espaço por possuir uma coleção de tabelas fato ou dimensão que agora estão dedicadas ao armazenamento de dados num estado já pré-processado.

Normalmente, a modelagem dimensional utilizando o esquema estrela apenas representa os fatos no nível de granularidade mais baixa (a partir do qual é possível gerar as combinações ou diferentes perspectivas de análise).

No entanto, torna-se evidente a vantagem (por razões de desempenho) de pré-calcular e armazenar fatos sumário, contendo agregações segundo diferentes combinações de dimensões.

Os agregados são um pré-calculo da combinação de utilização da fato com diversas combinações de dimensões. No Microsoft Analysis Service, é possível definir um percentual de quanta agregação será feito. Apesar de melhorar o desempenho, pois a consulta já foi pré-calculada, o processo de agregação ocupa muito espaço em disco.

Fatores:

  • Custo de Criação;

  • Custo de Manutenção;

  • Frequência de Manutenção;

  • Frequência de Utilização;

  • Tempo de Geração.

  • Nem sempre é viável armazenar todos os agregados.

OLAP (On-Line Analytical Processing)

Para Thomsen (2002), o termo OLAP possui diversos significados. Isso ocorre porque os elementos essenciais do OLAP são manifestáveis em diversas camadas de tecnologia, desde armazenamento e acesso até as camadas de linguagem. De acordo com o mesmo autor, os conceitos de OLAP incluem a noção ou ideia de múltiplas dimensões hierárquicas e que podem ser utilizados por qualquer pessoa como auxílio à compreensão de um mundo multidimensional e com múltiplos níveis.

Um OLAP se refere ao tipo de processamento e ferramentas voltadas para análise de dados típica do suporte à decisão, onde os dados são exibidos através de uma visão multidimensional independente de como os dados estão armazenados.

A tecnologia OLAP é normalmente implementada em ambiente multiusuário e cliente/servidor, proporcionando respostas rápidas às consultas, não importando o tamanho do banco de dados nem sua complexidade.

Exemplos de uso:

  • Governo Federal: Após conclusão do DW, considerado estratégico pelo governo federal, o governo planeja implantar um sistema de Data Mining, para auxiliar na identificação de fraudes.

  • Lobrás: Desenvolveu um DW que está ajudando a empresa a saber com exatidão o movimento das vendas de seus mais de 21.500 produtos.

  • Itaú: O banco Itaú foi um dos pioneiros no uso de DW no Brasil. Seu objetivo na época da implantação do DW era filtrar suas correspondências que eram enviadas pra mais de 1 milhão de correntistas mas somente 2% se interessavam pelas promoções e novidades. Com a utilização do DW o índice de retorno foi para 30%.

Uma visão multidimensional é usualmente representada por três dimensões (tri-dimensional) chamado Cubo. Porém, é possível utilizar mais dimensões, aí chamamos de Hipercubo ou Cubóide.

Tipos

Para SOUZA (2003), a classificação das ferramentas OLAP é uma tarefa imprecisa, uma vez que não existe nenhuma característica peculiar que especifique como a ferramenta deva ser construída, qual tecnologia deva ser usada em sua construção, nem mesmo que funcionalidades devem ser implementadas.

De acordo com Barbieri (2001), a estratégia de armazenamento do DW/DM, ou de seus cubos extraídos, possibilitam as seguintes opções:

  • ROLAP (Relational On Line Analytical Processing): técnica onde são usados os próprios sistemas de gerenciamento de banco de dados, com as tabelas sendo implementadas como estruturas relacionais clássicas;

  • MOLAP (Multidimensional On Line Analytical Processing): estratégia onde são usados os gerenciadores de banco de dados proprietários com características de armazenamento especiais, e ferramentas para tratamento dimensional de dados. Podem ser entendidos como uma planilha multidimensional.

  • HOLAP (Hybrid On Line Analytical Processing): representa uma abordagem de uso misto das duas estratégias anteriores, onde as estruturas relacionais são normalmente utilizadas para os dados de maior granularidade e as estruturas dimensionais nativas são dedicadas ao armazenamento de agregados;

  • DOLAP (Desktop On Line Analytical Processing): é uma abordagem onde as estruturas dimensionais ou relacionais são transferidas do DW/DM, e armazenadas nas estações dos clientes com o objetivo de melhorar a performance de certas análises, reduzindo o tráfego de informações entre os ambientes cliente e servidor.

Operadores OLAP

No modelo entidade relacionamento (ER) tradicional o conhecimento das operações básicas de álgebra relacional é obrigatório. No modelo de dados multidimensional existem as operações OLAP que suportam tais operações. A seguir descrevem-se as operações em um OLAP.

lu212826w83_tmp_a7eefdea2605f609

Drill Down, Drill Through e Drill Up (Roll Up)

Segundo Barbieri (2001), o conceito de Drill Down (Desmembramento) está diretamente relacionado com o fato de sairmos de um nível mais alto de hierarquia para buscar informações mais detalhadas, ou seja, com uma granularidade menor, níveis crescentes de detalhes são revelados (ano, mês, dia). O inverso é o conceito de Roll Up ou Drill Up (Agregação), que possibilita sair do nível mais baixo de hierarquia até o mais alto nível de sumarização.

A operação abaixo exibida é a de Drill Down. fazendo na direção oposta, estamos fazendo um Roll Up:

lu212826w83_tmp_4c7b363c44d9a4c7

Drill Through é realizar um Drill Down até um nível abaixo do mínimo permitido, tendo acesso as linhas da consulta relacional. Ou seja, é o que alguns chamam de explodir o cubo, visualizando linha a linha o conteúdo relacional do cubo. Por isso alguns dizem que é navegar entre relatórios, de um multidimensional, para um relacional objetivando um nível maior de detalhe.

Enquanto o Drill Down/Up só pode ser realizado em MOLAP. O Drill Though deve ser realizado em ROLAP e MOLAP; A operação utiliza as características de consultas SQL relacionais para acessar os dados de tabelas relacionais que originam o cubo.

Considere o clássico exemplo de Fatos Vendas cujas medidas são Preço e Quantidade Vendida e as dimensões são Produto, Loja e Tempo. Ou seja, seu BI servirá para analisar as vendas de produtos, por loja, ao longo do tempo. Considere também que, por algum motivo especial, o projetista do esquema em estrela modelou o nível mais baixo da dimensão tempo como sendo SEMANA. Ou seja, no maior nível de detalhe (menor granularidade) só seria possível analisar as Vendas por Semana.

Pois bem… Imagine que o gestor esteja analisando o cubo de dados na maior granularidade, digamos, por ANO. Ele vai navegando na hierarquia da dimensão tempo fazendo o Drill-Down. Ou seja, vai analisando as vendas por semestre, trimestre, mensal e chega no nível semanal. Então, teoricamente, ele não conseguiria analisar as vendas com mais detalhes (por dia), pois a granularidade dos fatos, para a dimensão Tempo, está em semana. SE a ferramenta implementar o drill-through, quando ele tentar descer mais uma vez na hierarquia o sistema mostrará os dados do sistema OLTP que deram origem àquela agregação, ou seja, as vendas daquela semana específica.

Para a FCC Drill Throught é pular de uma dimensão para outra.

Slice e Dice

São operações para realizar navegação através dos dados na visualização de um cubo. Slice é a operação que corta o cubo mantendo a mesma perspectiva de visualização de dados, já a troca de perspectiva de visão é denominada Dice.

Slice and Dice (fatiar e cortar em cubos): realizar a operação de projeção nas dimensões.

Já a FCC erroneamente utiliza o conceito: é uma das principais características de uma ferramenta OLAP. Como a ferramenta OLAP recupera o microcubo (No OLAP, as informações são armazenadas em cubos multidimensionais, que gravam valores quantitativos e medidas, permitindo visualização através de diversos ângulos. Estas medidas são organizadas em categorias descritivas, chamadas de dimensões e formam, assim, a estrutura do cubo), surgiu a necessidade de criar um módulo, que se convencionou de *Slice and Dice*, para ficar responsável por trabalhar esta informação. Ele serve para modificar a posição de uma informação, trocar linhas por colunas de maneira a facilitar a compreensão dos usuários e girar o cubo sempre que tiver necessidade.

Drill Across

Drill-Across é explorar dois fatos distintos em uma única interface, por exemplo, se o gestor quiser analisar os Fatos Vendas simultaneamente com um Agregado Fatos-Vendas-Anual.do ano passado:

“Drill Across executes queries involving (i.e., across) more than one fact table”

O conceito de Drill Across está relacionado com a possibilidade da troca de um esquema para outro, desde que ambos tenham dimensões em conformidade. Pode ser considerado como uma espécie de join (junção) dimensional entre estruturas relacionadas.

A FCC utiliza um conceito errado de Drill Across que fala: Drill Across pela FCC seria um Drill down ou drill Up pulando hierarquias, ou seja. Se uma dimensão Produto possui os atributos: País, Estado, Região, Loja, Produto; de País para Estado é uma hierarquia. De País para Região eu navego duas hierarquias, fazendo um drill across.

Segundo o livro do Ralph Kimball: “”The customer, product, and deal dimensions also would conform so that we can drill across from fact table to fact table and communicate using common attributes”.

Pivot

Pivot ou Pivoteamento é executar a rotação do cubo (hipercubo). Mudar os eixos da visualização (cross-tab ou 3D graphics) do resultado de uma consultas (ex, time na vertical no lugar da horizontal)

Rank

Ordena os membros de uma dimensão de acordo com a ordem da medida corrente (ex, time retrospectivo, começando pelo mais recentes primeiro); serve também para filtragem.

Data Mining

As ferramentas de Mineração de Dados são especializadas em procurar padrões nos dados. Essa busca pode ser efetuada automaticamente pelo sistema ou interativamente com um analista, responsável pela geração de hipóteses.

Diversas ferramentas distintas, como redes neurais, indução de árvores de decisão, sistemas baseados em regras e programas estatísticos, tanto isoladamente quanto em combinação, podem ser então aplicadas ao problema.

Em geral, o processo de busca é interativo, de forma que os analistas reveem o resultado, formulam um novo conjunto de questões para refinar a busca em um dado aspecto das descobertas, e realimentam o sistema com novos parâmetros. Ao final do processo, o sistema de Mineração de Dados gera um relatório das descobertas, que passa então a ser interpretado pelos analistas de mineração. Somente após a interpretação das informações obtidas encontramos conclusões ou regras, este processo é conhecido por Knowledge Discovery in Database (KDD) ou Descoberta de Conhecimento em banco de dados.

Objetivos:

Explanatório: explicar algum evento ou medida observada, tal como porque a venda de sorvetes caiu no Rio de Janeiro;

Confirmatório: confirmar uma hipótese. Uma companhia de seguros, por exemplo, pode querer examinar os registros de seus clientes para determinar se famílias de duas rendas tem mais probabilidade de adquirir um plano de saúde do que famílias de uma renda;

Exploratório: analisar os dados buscando relacionamentos novos e não previstos. Uma companhia de cartão de crédito pode analisar seus registros históricos para determinar que fatores estão associados a pessoas que representam risco para créditos.

Resolução de Questões de Concursos Anteriores

TRT 22ª Região – Analista Judiciário – 2010 – FCC

No âmbito dos DWs, uma outra concepção do ODS (Staging Area) está sendo estabelecida por alguns autores. Trata-se de:

a) OLAP.

b) Drill throught.

c) ETL.

d) Data Mining.

e) Dynamic Data Storage.

RESPOSTA: E.

Um Operational Data Storage (ODS) ou Staging Area (SA) representa um armazenamento intermediário dos dados, promovendo a integração dos dados do ambiente operativo antes de sua atualização no DW. Inicialmente, um ODS era considerado um repositório temporário que armazenava apenas informações correntes antes de serem carregadas para o DW, similar a uma cópia dos ambientes de sistemas transacionais em uma empresa. Atualmente, alguns autores passaram a denominá-lo Dynamic Data Storage (DDS).

TRT 08ª Região – Analista Judiciário – 2010 – FCC

Como melhor relação custo/benefício, em um DW é mais aconselhável

A) separar o dado geográfico do dado histórico, uma vez que não têm correlação.

B) separar a identificação da informação da data a que ela se refere.

C) armazenar somente a data das transações.

D) armazenar dados transacionais.

E) armazenar informações de caráter histórico e estatístico.

RESPOSTA: E

Data warehouse possibilita a análise de grandes volumes de dados, coletados dos sistemas transacionais (OLTP). São as chamadas séries históricas que possibilitam uma melhor análise de eventos passados, oferecendo suporte às tomadas de decisões presentes e a previsão de eventos futuros

TRT 08ª Região – Analista Judiciário – 2010 – FCC

São modelos fortemente associados à estrutura de um banco de dados multidimensional:

(A) lineup e snowflake.

(B) anel e estrela.

(C) estrela e snowflake.

(D) anel e workflow.

(E) lineup e coroa.

RESPOSTA: C

Estrela (Star) e Floco de Neve (Snowflake)

TRT 08ª Região – Analista Judiciário – 2010 – FCC

Utilizando uma base multidimensional, o usuário passou da análise de informações sob a ótica da dimensão tempo para a visão sob a dimensão regional. A operação OLAP aí realizada foi

A) star across.

B) roll up.

C) drill across.

D) drill throught.

E) slice and dice.

RESPOSTA: D

Drill Through significa navegar de um relatório para outro com o objetivo de obter mais detalhe, ao contrário do Drill Down que é realizada a mesma coisa, porém, em um mesmo relatório. Enquanto o Drill Though pode ser realizado em ROLAP e MOLAP; o Drill Down/Up só pode ser realizado em MOLAP.

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Rolar para cima