SIMPLIFICANDO O BUSINESS INTELLIGENCE

Andre de Freitas Tasca

Bacharel em Analise de Sistemas pela Unisinos

Diretor da empresa SoftSystem IT

Porto Alegre, 2013

Resumo

Todos os dias são tomadas decisões para a condução dos mais diversos tipos de negócios. Os gestores das empresas são pressionados pela alta competitividade do mercado a oferecerem aos seus clientes produtos e serviços com qualidade e preços atrativos.

A análise de dados de sistemas transacionais vem se tornando cada vez mais necessária para o entendimento das necessidades dos clientes direcionando produtos e serviços adequados a cada perfil. Essa análise tende a transformar dados em informação e informação em conhecimento para que as decisões sejam tomadas da forma mais acertada possível.

O presente artigo tem como objetivo apresentar conceitos relacionados ao tema Business Intelligence e os itens importantes de sua arquitetura, trazendo a visão dos principais teóricos sobre os assuntos estudados e também uma comparação entre a abordagem tradicional de Business Intelligence versus uma nova abordagem chamada de associativa. Palavras-chave: Business Intelligence – ETL – Data Mart - Arquitetura

1. INTRODUÇÃO Ao contrário do que se possa imaginar, o conceito de Business

Intelligence não é recente. Fenícios, persas, egípcios e outros povos do Oriente utilizavam esse princípio há milhares de anos, quando cruzavam informações obtidas junto à natureza em benefício próprio. Observar e analisar o comportamento das marés, os períodos de seca e de chuvas, a posição dos astros, entre outras, eram formas de obter informações que eram utilizadas para tomar as decisões que permitissem a melhoria de vida de suas respectivas comunidades (LOPES, 2006).

Para que as empresas possam conhecer mais e assim administrar melhor seu negócio, elas estão dando maior importância às informações estratégicas que podem ser extraídas da base de dados gerada por um ERP ou Sistemas Integrados de Gestão. Significa dizer que toda a informação poderá ser tratada como objeto a ser arquivado, posteriormente consultado e analisado, permitindo que os executivos visualizem comportamentos, tendências e desvios de forma rápida, segura e confiável, possibilitando uma gestão aprimorada e eficiente.

Afirma Reinhard (1996) que os dirigentes passaram a utilizar recursos de informática como ferramentas para tomada de decisões estratégicas, devido a muitas mudanças no ambiente externo e interno das empresas. A alta

competitividade do mercado exige planejamento, coordenação e controle da empresa, além do acompanhamento do mercado em relação aos concorrentes, aos aspectos econômicos, legais, políticos e culturais em âmbito global.

Segundo Porter (1986), a leitura dos sinais do mercado exige técnicas. É preciso determinar uma metodologia para a decisão sobre quais são os dados particularmente cruciais e sobre o modo como eles podem ser analisados. A análise que pode levar a uma compreensão mais profunda de um determinado segmento e de seus concorrentes exige um grande volume de dados, alguns dos quais sutis e de difícil obtenção. A compilação dos dados para uma análise sofisticada da concorrência exige mais do que um trabalho duro: exige um mecanismo organizado, algum tipo de sistema de inteligência. Na obra Estratégia Competitiva, o autor salienta que, qualquer que seja o mecanismo escolhido para coletar dados de inteligência sobre o concorrente, existem benefícios com um mecanismo que seja formal e envolva documentação.

Desde a década de 80, o autor se preocupava em desenvolver uma metodologia para a análise da concorrência, tornando um dos temas principais da inteligência competitiva. A metodologia proposta por Porter envolve quatro momentos principais: 1) análise das necessidades, definição dos alvos; 2) coleta de informações após definição das fontes úteis; 3) análise e avaliação das informações com os especialistas da área; 4) difusão das informações aos decisores para a ação. Salientam-se algumas operações preliminares importantes, como a análise da posição da empresa no mercado e a determinação das necessidades de informações críticas da empresa para guiar a coleta, o tratamento e a difusão de informações. As informações críticas seriam aquelas áreas ou temas a vigiar de modo prioritário (PORTER, 1986).

Decisões são tomadas a todo instante nas organizações. Existem instituições que utilizam sistemas de informações somente a nível operacional, não direcionando para o topo da hierarquia os dados colhidos pela própria organização. Para esses gestores, a maioria das decisões é tomada com base em conhecimento empírico adquirido com o passar dos tempos. Para Davenport e Marchand (2004) a aplicação e o uso do conhecimento envolvem diversas dimensões: uma delas é cultural. A empresa recompensa decisões tomadas com base em conhecimentos compartilhados ou fica satisfeita com as decisões e ações tomadas com base na intuição e adivinhação das pessoas com experiência e competência.

O BI é uma metodologia que permite a extração e estruturação de informações dos sistemas operacionais para o processo decisório.

Este artigo visa simplificar os conceitos de Business Intelligence.

2. BUSINESS INTELLIGENCE

Para competir no mercado global de hoje, as empresas precisam deter mais conhecimento do que antigamente e, ainda, para obter sucesso, elas precisam saber mais sobre seus clientes, mercados, tecnologias e processos, e necessitam ter essas informações antes que seus concorrentes (HEINRICHS e LIM, 2003).

A essência do Business Intelligence supre as necessidades de quem está à procura de vantagem competitiva por meio da administração de dados e pode auxiliá-lo na construção de melhores relações comerciais e de sucesso (SERRA, 2002).

Segundo Barbieri (2001), o conceito de BI começa a ganhar grande espessura no cenário de negócios. Ele pode ser entendido como um conjunto de conceitos que envolve Inteligência Competitiva (CI), Gerência de Conhecimentos (KMS), IBI (Internet Business Intelligence), pesquisa e análise de mercados, etc., tudo relativo à nova era da Economia da Informação, dedicada à captura dos dados, informações, e conhecimentos que permitam às empresas competirem com maior eficiência. O Autor afirma ainda que de forma mais ampla, pode ser entendido como a utilização de variadas fontes de informação para se definir estratégias de competitividade nos negócios da empresa. 2.1 Diferença entre Dados Operacionais e Informacionais

Para diferenciar melhor os dados de natureza informacional e operacional, e estabelecer fontes importantes para o conceito de Business Intelligence, a Tabela 1 mostra algumas dessas diferenças:

Tabela 1 - Diferença entre Dados Operacionais e Informacionais.

Características Dados Operacionais Dados Informacionais

Conteúdo Valores Correntes Valores Sumarizados, Calculados, Integrados de Várias Fontes

Organização dos Dados Por Aplicação/sistema de informação Por Assuntos/Negócios

Natureza dos Dados Dinâmica Estática até a atualização dos dados

Formato das Estruturas Relacional, próprio para computação transacional

Dimensional, simplificado, próprio para atividades analíticas

Atualização dos Dados Atualização campo a campo Acesso, sem update

Uso Altamente estruturado, processamento repetitivo

Desestruturado, com processamento analítico/heurístico

Tempo de Resposta Otimizado para 2 a 3 seg.

Análises mais complexas, com tempos de respostas maiores

Fonte: BARBIERI, 2001, p.47.

3. DATA WAREHOUSE E DATA MARTS

Inmon (1996), afirma que o Data Warehouse é uma coleção de dados não voláteis, crescente no tempo, integrada e orientada ao negócio para dar suporte às informações gerenciais. É a fonte de dados para consulta da organização (KIMBALL, 1998). Ele possui as seguintes características (BERSON e SMITH, 1997):

É um banco de dados projetado para análise, que usa dados de várias aplicações; É projetado para um pequeno número de usuários com iterações longas; É usado basicamente para leitura; É atualizado periodicamente, principalmente para adição de dados; Contêm dados atualizados e históricos para fornecer informações do fluxo do negócio no tempo; É formado por poucas e grandes tabelas; Destina-se à realização de consultas que resultam em um conjunto grande de dados e geralmente devolvem leitura de tabelas inteiras e vários relacionamentos.

O Data Warehouse deve ter os seguintes objetivos (KIMBALL, 1998): Tornar a informação mais acessível; Tornar a informação mais consistente, ou seja, informação de qualidade em toda a organização. Os termos usados em uma parte da empresa devem ter o mesmo significado em toda empresa; Ser uma fonte de informação adaptável e maleável. Deve ser projetado para mudança constante sem que todo sistema tenha que ser alterado; Ser uma fonte segura para proteger a informação da empresa; Deve ser a base para a tomada de decisão.

O Data Mart possui definições diferentes junto aos autores, especialmente Kimbal e Inmon (1996).

Segundo Inmon (1996), o Data Mart é uma coleção de dados relacionados à área da empresa, organizados para dar suporte à decisão e baseados nas necessidades de um determinado departamento ou processo, podendo ser de uma determinada área da empresa. Ele afirma que um conjunto de Data Marts dificilmente pode ser integrado, e mesmo que for não resultará em um Data Warehouse (INMON,1998). Para Inmon (1998), o Data Mart é derivado do Data Warehouse.

Sob a ótica de Kimball (1998), o Data Mart é como um subconjunto lógico do Data Warehouse, e o Data Warehouse é a união de todos os Data Marts.

Essa diferença de opiniões se reflete em diferentes formas de implantação. Kimball (1998) propõe a implantação de um Data Mart por vez desde que seja feito uma prévia modelagem da organização. Já Inmon (1996) propõe que o sistema comece pequeno e vá evoluindo progressivamente em espaços curtos de tempo. Ambos concordam que a implantação completa é muito complexa para ser feita de uma vez, e que a sustentação do projeto

5

depende da entrega rápida de uma solução parcial que agrade os usuários e justifique o investimento.

4. ETL – EXTRAÇÃO, TRANSFORMAÇÃO E CARGA DE DADOS

4.1 Extração de Dados

A extração dos dados se faz a partir das mais diversas fontes de dados, que podem ter os mais variados formatos, em diferentes plataformas. Para isso, é necessário uma fonte de dados temporária com padronização de ambiente de desenvolvimento que permita a recepção dos dados das diferentes bases, sendo que as configurações das tecnologias de hardware, sistema operacional e banco de dados sejam o primeiro padrão a ser aplicado ao DW em construção (LELES, 2004).

KIM (1995), prevê que para possibilitar o acesso a dados de diversas fontes heterogêneas, é previsto que a integração seja feita em um novo banco de dados. Essa consolidação geralmente é feita através de Interfaces padrão do tipo ODBC (Open Data Base Conectivity) – padrão para acesso a BDs do SQL Access Group Consortium adotado pela Microsoft, ou outras.

Ainda segundo o autor, existem outros tipos de abordagens, os quais propõem a integração dos dados e das bases de dados apenas durante o processamento das consultas, somente selecionando resultados vindos destas consultas, sem materialização, isto é, sem a criação de réplicas dos repositórios locais integrados.

Conforme Silberschatz (1999), os dados de um SGDB podem ser extraídos para um arquivo por meio de ferramentas de aplicação utilizando a linguagem SQL, pois ela utiliza uma combinação de construtores em álgebra e cálculo relacional para a manipulação de dados em BD’s, possuindo recursos para: consulta, modificação, definição da estrutura de dados e especificação de restrições de segurança. Entretanto, se a formatação dos arquivos não é conhecida é necessário geração de relatório ou criação de arquivo para descarregar os dados do sistema de produção. 4.2 Transformação dos Dados

Essa etapa consiste em retirar redundâncias e inconsistências advindas dos vários formatos que podem existir nas fontes de dados. As rotinas de limpeza e transformações de dados são necessárias e as suas características devem ser armazenadas e documentadas como metadados1 (LELES, 2004).

Para melhor entender esse processo, um exemplo simples de incompatibilidade de dados é a codificação para gênero feminino e masculino. Em uma base de dados, a entrada deste dado pode estar codificada em “m/f” e em outra base de dados em “0/1”, para que fique transparente para o usuário, é 1 Qualquer dado mantido para sustentar as operações ou a utilização de um data warehouse; funciona como uma enciclopédia para o data warehouse.

6

necessária a padronização da entrada deste dado de forma coerente como, por exemplo, especificando a codificação como “M/F” (LELES, 2004). 4.3 Carga de Dados

Neste processo, os dados padronizados na etapa de transformação são transferidos para o DW, e serão utilizados para a montagem das análises que serão disponibilizadas aos gestores.

Existem três desafios para a carga dos dados do ambiente operacional para DW (INMON, 1997):

I) Frequência de carregamento dos dados históricos; II) Carga dos dados do valor corrente do ambiente operacional; III) Carga dos dados depois de ter ocorrido atualizações dos dados no

ambiente transacional. No item I, o autor afirma que o desafio é menor, pois a carga não é feita

com muita frequência. O item II, também não representa muito problema, pois essa carga é feita somente uma vez. O item III, é considerado pelo autor o mais difícil, devido a dificuldade de rastreabilidade das alterações.

5. OLAP

A análise multidimensional para OLAP surgiu após a publicação de A Programming Language (Ken Iverson,1962). Com base nessas ideias a IBM desenvolveu e implementou a primeira linguagem com análise multidimensional, no final da década de 60, chamada de APL. Definida matematicamente, baseada em símbolos gregos, utilizadas por usuários finais e grande consumidora de recursos computacionais, foi amplamente utilizada nas décadas de 80 e 90 em aplicações de negócio. Acompanhando a evolução dos sistemas, na década de 90, introduziu-se uma nova classe de ferramentas no mercado, que foi chamada de OLAP. As ferramentas de OLAP possuem a maioria dos conceitos introduzidos pela linguagem APL, porém, com maior integração na utilização dos dados fontes. Existe um grupo de empresas que desenvolveu e ainda desenvolve ferramentas OLAP e arquiteturas nela baseada como a IBM, a Computer Associates, MicroSoft, MicroStrategy, Cognos, IRI, Oracle, entre outras (ANZANELLO, 2002).

Segundo Anzanello (2002), a aplicação OLAP oferece visualizações das informações de negócio a partir de muitas perspectivas diferentes por manter uma estrutura adequada e eficiente. Os dados são armazenados na forma dimensional, e as dimensões podem ser hierárquicas. Sua finalidade é apoiar os executivos em suas decisões estratégicas.

Thomsen (1997) demonstra que utilizando somente consultas SQL e planilhas eletrônicas é difícil consultar e disponibilizar as informações analíticas do DW. Para suprir estas necessidades surgiram os softwares multidimensionais, também conhecidos como ferramentas OLAP. Ele define algumas funcionalidades para trabalhar com dados não estruturados como:

Associação de fórmulas nas dimensões;

7

Exibição das dimensões do modelo em qualquer configuração tri-dimensional composta de linhas colunas e páginas;

Habilidade de lidar com a natureza hierárquica das dimensões. O conceito de hypercubo, cubo com mais de três dimensões, é a base

da abordagem das ferramentas OLAP que podem utilizar SGBD’s relacionais dando a eles um sabor dimensional (ROLAP) ou usar tecnologias proprietárias de banco de dados multidimensionais (MOLAP) (KIMBALL, 1998).

Barbieri (2001) nota que na modelagem dimensional as informações residem na interseção de várias dimensões. Os valores dos fatos residem na interseção das diversas dimensões que formam um ponto no hypercubo. O hypercubo pode ser fatiado (slice) isolando uma ou mais dimensões. O pivotamento (rotação) permite girar o hypercubo com a mudança do eixo de dimensões analisado. O conceito de dicing permite a criação de hypercubos menores restringindo as ocorrências de interesse em cada dimensão. Evidentemente, esses conceitos são mais facilmente demonstrados quando consideramos um cubo com três dimensões, mas na maioria das consultas aos data marts mais de três dimensões são utilizadas.

5.1 Arquiteturas

Segundo Nigel Pendse (2002), conforme o método de armazenamento de dados utilizado para uma aplicação OLAP, será elaborada a arquitetura da aplicação. Os métodos de armazenamento de dados são MOLAP, ROLAP, DOLAP e HOLAP. Cada um deles tem uma função específica e deve ser utilizada quando melhor atender às necessidades de análise pela ferramenta de OLAP.

Anzanello (2002), afirma que no MOLAP (Multidimensional On-Line Analytical Processing) os dados são armazenados de forma multidimensional, sua implementação varia de acordo com a sua ferramenta de OLAP, mas é freqüentemente implementado em um banco de dados relacional, porém não na terceira forma normal. Além disto, o acesso aos dados ocorre diretamente no banco de dados do servidor multidimensional. Os gerenciadores de banco de dados têm um limite prático quanto ao tamanho físico de dados que eles podem manipular. As restrições de armazenamento e desempenho limitarão o tamanho do banco de dados, não esquecendo o limite das dimensões que também restringem sua manipulação. A complexidade que existe no processo de carga de um banco de dados multidimensional, pode acarretar a demora no processo. O processo de carga é complexo devido à série de cálculos que devem ser realizados para agregar os dados às dimensões e preencher as estruturas do banco. Depois do processo concluído, ainda é realizado uma série de mecanismos para melhorar a capacidade de pesquisa.

Já no ROLAP (Relational On-Line Analytical Processing) os dados são armazenados no modelo relacional como também suas consultas são processadas pelo gerenciador do banco relacional (ANZANELLO, 2002).

Por outro lado, o DOLAP (Desktop On-Line Analytical Processing) é uma variação que existe para fornecer portabilidade dos dados. A vantagem que oferece esta arquitetura é a redução do tráfico na rede (ANZANELLO, 2002).

8

A arquitetura mais recente é a HOLAP (Hybrid On-Line Analytical Processing), na qual ocorre uma combinação entre ROLAP e MOLAP. A vantagem é que com a mistura de tecnologias pode-se extrair o que há de melhor de cada uma, a alta performance do MOLAP e a escalabilidade do ROLAP (ANZANELLO, 2002).

5.2 Ferramentas OLAP

A grande maioria dos softwares oferecidos no mercado trabalha, no

mínimo, sob duas abordagens: A ferramenta de desenvolvimento, que é utilizada para a montagem do modelo dimensional de negócios e a interface de iteração com o usuário, e a ferramenta de visualização e análise dos dados destinada ao usuário final.

Algumas características dessas ferramentas são: Consultas ad-hoc: são consultas geradas pelos usuários finais através

do cruzamento de informações que os levem a encontrar tendências, padrões e comportamentos sob os itens analisados de uma forma não vista. Segundo Inmom (2002), “são consultas com acesso casual único e tratamento de dados segundo parâmetros nunca antes utilizados de forma iterativa e heurística”.

Slice and Dice: possibilita a alteração da perspectiva de visão. Serve para modificar a posição de uma informação, trocar linhas por colunas de maneira facilitar a compreensão dos usuários e girar o cubo sempre que houver necessidade (ANZANELLO, 2002).

Drill down/up: consiste em realizar exploração em diferentes níveis de detalhes da informação. Com drill down divide-se um item de resumo em seus componentes detalhados, como por exemplo, ano, semestre, trimestre, mensal e diário. Além das principais características apresentadas é necessário que estas aplicações forneçam vários modelos de visualização em uma variedade de formatos, e não apenas em simples tabelas, sendo muitas vezes apresentados através de gráficos (ANZANELLO, 2002).

Devido suas características e funcionalidades, as ferramentas constituem parte importante em uma estrutura de Business Intelligence, pois elas permitem que as informações do DW sejam exploradas de maneira eficiente.

6. MODELAGEM DIMENSIONAL

A Modelagem Dimensional de dados é uma técnica de projeto que traz os dados para uma forma próxima do entendimento do usuário, onde o modelo dimensional é formado por informações que poderão vir de diversas fontes de dados. Essa técnica nasceu para modificar alguns conceitos cristalizados nos projetos tradicionais de Bancos de Dados, principalmente após a fase relacional. O produto final da Modelagem Dimensional é a produção de um modelo conceitual dimensional, formado de tabelas Fato e tabelas Dimensão (BARBIERI, 2001).

9

As tabelas Fato servem para armazenar medidas numéricas associadas a eventos de negócio. Uma tabela Fato contém vários fatos, correspondentes a cada uma de suas linhas. Cada fato pode armazenar uma ou mais medidas numéricas, que constituem os valores objetos da análise dimensional. Possuem como chave primária, normalmente um campo multi-chaves, formado pelas chaves-primárias das dimensões que com ela se relacionam. Normalmente armazenam muito mais linhas do que as tabelas Dimensão, e merecem cuidado especial em função do seu alto volume. Contêm dados normalmente aditivos (manipulados por soma, média, etc.) e relativamente estáticos.

As tabelas Dimensão representam entidades de negócios e constituem estruturas de entrada que servem para armazenar informações como tempo, geografia, produto, cliente, etc. As tabelas Dimensão tem uma relação 1:N com a tabela Fato. Possuem múltiplas colunas de informação, algumas das quais representam a sua hierarquia. Apresentam sempre uma chave primária, que lhes confere unicidade, chave essa que participa da tabela Fato, como parte de sua chave múltipla. Devem ser entendidas como as tabelas que realizam os filtros de valores aplicados na manipulação dos fatos e por onde as consultas entram no ambiente de DW/DM. A seguir, a Figura 2 ilustra a composição da tabela Fato, onde cada linha representa um fato e as colunas chaves são herdadas das tabelas Dimensão associadas. Além das chaves, apresenta as colunas com valores das medidas definidas para o modelo (BARBIERI, 2001).

Figura 1 - Exemplo de um Modelo Dimensional.

Fonte: BARBIERI, 2001, p.82.

O autor afirma que a estrutura dimensional modifica a ordem de distribuição de campos por entre as tabelas, permitindo uma formatação estrutural mais voltada para muitos pontos de entradas específicos (as chamadas dimensões) e menos para os dados granulares em si (os chamados Fatos). Isso significa que numa estrutura dimensional os dados estarão numa

10

forma quase estelar, onde várias tabelas de entrada estarão se relacionando com algumas (poucas) tabelas de informações, criando uma notação mais sintética, legível e objetiva.

O modelo dimensional oferece clara e diretamente os elementos que se precisa para buscar as informações sobre fatos via dimensões de referência, diferindo da malha relacional, ou de rede.

O modelo dimensional, embora mais leve do que o modelo relacional, pode se tornar mais complexo, na medida em que novas extensões forem sendo agregadas a resolução do problema. A necessidade de relacionamentos M:N entre tabelas Fato e tabelas Dimensão, bem como a resolução de estruturas recursivas nas dimensões poderão acrescentar complexidade ao modelo (BARBIERI, 2001).

6.1 Comparação entre Relacional e Dimensional

As diferenças os modelos Relacional e Dimensional são apresentas na tabela 2.

Tabela 2 - Comparação entre Modelo Relacional – E/R e Modelo Dimensional.

Modelo Dimensional Modelo Relacional – E/RÉU: Padrão de estrutura mais fácil e intuitiva Modelo mais complexo

Anterior ao MER, anos 60 Ênfase nos Bancos de Dados Relacionais, anos 70

Tabelas Fato e tabelas Dimensão Tabelas que representam Dados e Relacionamentos

Tabelas Fato são o núcleo – normalizadas

Todas as tabelas são comumente normalizadas

Tabelas Dimensão são os pontos de entrada

As tabelas são indistintamente acessadas e de filtro inicial

Tabelas Dimensão opcionalmente normalizadas

Todas as tabelas são comumente normalizadas

Modelo mais facilmente “joined” Maior dificuldade de “join” pelo número maior de tabelas

Leitura mais fácil do modelo por usuários não especializados

Maior dificuldade de leitura pelo usuário não especializado

Fonte: BARBIERI, 2001, p.38.

Os passos da Modelagem Dimensional são:

Definição da Área de Negócio

11

Deve ser escolhida de acordo com as prioridades emergentes da empresa. Após a escolha, parte-se para definir aqueles que serão os processos alvos do projeto.

Definição de Granularidade Define de forma combinatória os níveis dimensionais que serão usados

para o armazenamento dos dados. Os fatores de definem a escolha da granularidade estão relacionados com o volume de dados a ser mantido e com o processamento necessário para produzí-los. A granularidade pode variar na dimensão temporal entre dia, mês e anos, por exemplo.

Definição das Tabelas Dimensão Devem ser definidas em função da granularidade e áreas de negócio.

Normalização2 das Tabelas Dimensão.

As tabelas Dimensão, diferentemente das tabelas Fato, estão mais sujeitas ao processo de desnormalização3. Existem duas correntes diferentes com relação aos aspectos de normalização das tabelas Dimensão:

Star Schema ou Esquema Estrela: Abordagem que recomenda a não normalização das tabelas

Snowflake Schema ou Esquema de Flocos de Neve: Abordagem que recomenda a normalização das tabelas.

A utilização do esquema estrela é extremamente recomendável, pelos aspectos de ganho de desempenho quando comparado ao esquema de flocos de neve. Isso acontece porque a redução dos comandos de junção que seriam necessários para recompor a informação desejada buscando-a em outra tabela.

Relacionamento de Atributos das Tabelas Dimensão As tabelas Dimensão carregam atributos que estabelecem

relacionamentos entre si. É necessário um esquema cuidadoso de modelagem para melhor distribuídos no esquema dimensional (BARBIERI, 2001).

6.2 MODELAGEM DIMENSIONAL ASSOCIATIVA

A modelagem dimensional associativa funciona de forma diferente dos

demais modelos de arquiteturas de BI, ela constrói e mantém um banco de dados não relacional associado através de chaves compactada em disco e descompactada na memória quando o banco é aberto. Os dados são armazenados na memória (RAM) e analisados conforme as necessidades, isso é feito sem qualquer apoio de leitores de disco.

2 Técnica de modelagem lógica que remove redundância de dados separando os dados em muitas entidades distintas, cada uma das quais se torna uma tabela e um SGBD relacional. 3 Aceitação de redundância em uma tabela para que ela permaneça simples e não normalizada. Esse procedimento tem por objetivo melhorar o desempenho e facilitar a utilização.

12

Atualmente a única tecnologia que implementa nesse formato é o QlikView.

Segundo seu Tutorial (2011), a ferramenta possui as seguintes características:

Armazenamento dos Dados

Não é necessário montar um DW, o QlikView possui seu próprio arquivo de dados gerado a partir da carga. Possui funções embutidas para a carga (ETL) e limpeza (Data Cleansing) dos dados. Por esse motivo, reduz consideravelmente o custo de todo um projeto de ETL e modelagem do DW.

Número ilimitado de dimensões

Os cubos são não tem limitação de dimensão, eles são relacionados através de chaves associativas e são orientados ao negócio, portanto qualquer variável pode servir como item de análise em um objeto da interface. Por esse motivo, cada tabela do modelo dimensional é chamada de hypercubo.

Possibilidade para que diversos Hypercubos "conversem" um com o

outro

Após serem montados os hypercubos, as informações poderão ser visualizadas através de objetos de interface (gráficos, tabelas, velocímetros, etc.) e todos esses objetos podem ser combinados em uma mesma análise, podendo todos os objetos estar se relacionando ou não.

Flexibilidade

A alteração ou criação de novas análises é totalmente transparente, não requerendo alterações em bases de dados ou redefinição de cubos. O tempo para a criação de novos atributos é extremamente reduzido por não precisar alterar a base de dados, qualquer campo da fonte de dados pode ser adicionado como uma dimensão instantaneamente, assim como novas medidas e indicadores podem ser criados.

Amigável para o usuário

A navegação é intuitiva, não requerendo praticamente nenhum treinamento mais específico na ferramenta. As possibilidades gráficas são avançadas e de fácil compreensão.

Espaço em disco

A base de dados do QlikView pode trabalhar com uma compactação de até 80%, isso faz com que não seja necessário muito espaço em disco para o armazenamento das informações. Mesmo com alta compactação, a performance das consultas é extremamente elevada por trabalhar com cálculos em memória RAM.

Acessibilidade

13

O QlikView pode ser utilizado através dos principais navegadores de internet sem que seja instalado nenhum plugin. Também possui navegação nativa para dispositivos móveis sem que seja necessário nenhuma programação adicional pelos desenvolvedores.

Os sistemas convencionais de pesquisa de informações normalmente requerem uma abordagem top-down, enquanto o QlikView permite iniciar com quaisquer dados, independentemente de sua localização na estrutura de dados. A recuperação de dados em sistemas convencionais geralmente é uma tarefa complexa que requer conhecimento abrangente da estrutura das bases de dados e da sintaxe da linguagem de consulta. Normalmente, o usuário está limitado a rotinas de pesquisa pré-definidas.

Pode-se dizer que o QlikView utiliza uma arquitetura híbrida para análise dos dados; a MOLAP devido ao relacionamento das chaves associativas entre os hypercubos para montagem do modelo de negócios, a DOLAP por permitir uma análise off-line dos dados, e a OLAP por permitir uma análise on-line se a versão utilizada for a cliente-servidor. Outra característica que faz com que o modelo de negócios fique mais simples, é que campos de sumarizações não precisam ficar nos hypercubos, eles são calculados em tempo de execução, com isso a carga dos dados fica extremamente rápida. Os usuários podem criar suas próprias visões utilizando qualquer variável do modelo de negócios diretamente via navegador de internet.

6.3 Arquitetura Tradicional de BI x Arquitetura Associativa

Conforme mostra a Figura 7, a construção de um ambiente de Business Intelligence requer dados de várias fontes de dados existentes na empresa ou fora dela. O conjunto de dados coletados é matéria-prima para uma série de transformações feitas antes da carga no Data Warehouse, cujo produto final é carregado no Data Warehouse (depósito de dados). São criadas visualizações gerenciais que possibilitam que as decisões gerenciais sejam tomadas em tempo real.

Figura 2 - Arquitetura Tradicional de Business Intelligence.

14

Nesse ambiente tradicional, é necessário o investimento em um novo banco de dados, uma ferramenta para fazer ETL e, além disso, para posterior manutenção desse banco de dados um DBA (Administrador de Banco de Dados). Isso faz com que o custo fique bastante elevado.

Na Figura 8, o ambiente de Business Intelligence fica mais simplificado, não é necessário o investimento em um novo banco de dados, e o ETL é feito dentro da própria ferramenta de desenvolvimento QlikView que gera seu próprio Data Warehose (QVW). Nessa base gerada por ele, não é necessário nenhuma manutenção para melhoria de performance. Essas características fazem que o custo para implantar e manter o sistema fique muito atrativo.

Figura 3 - Arquitetura Associativa de Business Intelligence.

15

Referências

ANZANELLO, C. A. M. OLAP: Conceitos e Utilização. Instituto de Informática – Universidade Federal do Rio Grande do Sul (UFRGS), 2002. Disponível em: <http://www.inf.ufrgs.br/~clesio/cmp151/cmp15120021/MaterialSeminarios.html>. Acesso em: 15 jul. 2006.

BARBIERI, C. BI – Business Intelligence: Modelagem e Tecnologia. Rio de Janeiro: Axcel Books, 2001. BERSON, A.; SMITH, S. J. Data warehousing, Data mining & OLAP. New York: McGraw-Hill, 1997. CORRÊA, H. L.; GIANESI, I. G. N. e CAON, M. (1999). Planejamento, Programação e Controle da Produção: MRP II / ERP. São Paulo: Editora Atlas. DAVENPORT, T. H. Mission critical: realizing the promise of enterprise systems. Boston, Massachusetts: Harvard Business School Press, 2000. DAVENPORT, T. H.; MARCHAND, D. A.; DICKSON, T. Dominando a gestão da informação. Porto Alegre: Bookman, 2004. 407p. DAVENPORT, T. H.; MARCHAND, D. A. A Gestão do conhecimento é uma boa gestão da informação? In: Dominando a gestão da informação. Tradução de Bellini C.G.P. e Soares C.A.S.N. Porto Alegre: Bookman, 2004. p.189-194. HEINRICHS, J. H.; LIM, J. S. Integrating web-based data mining tolls with business models for knowledge management. Decision Support Systems, v.35, n.1, p.103-112, 2003. INMON, W. H. Como Construir o Data Warehouse. Rio de Janeiro: Editora Campus, 1997.

INMON, W. H. Building the Data Warehouse. 2d. New York: John Wiley & Sons, 1996. 401p.

KIM, W. Modern Database Systems: the Object Model, Interoperability and Beyond. ACM press, Addison Wesley, 1995.

KIMBALL, R. The Data Warehouse Tollkit: practical techniques for buiding.

LOPES, C. Conceito e história do BI. Disponível em: <http://www.celedo.com.br/portal/modules.php?name=News&file=article&sid=1>. Acesso em: 7 maio 2006.

MACHADO, F. N. R.; ABREU, M. P. Projeto de Banco de Dados: uma visão prática. São Paulo: Érica, 1996.

16

MANUAL QlikView: Versão 10 para Microsoft Windows® Primeira Edição, Lund, Suécia, fevereiro de 2011 De autoria da QlikTech International AB /HIC/KHN/JNN/MSJ

MARKUS, M. L. e TANIS, C (2000). .The enterprise system experience. from adoption to success., em Zmud, R. Ed., Framing the domains of IT research: glimpsing the future through the past. Cincinnati, Pinnaflex.

PENDSE, N. What Is OLAP? The OLAP Report. Disponível em: <http://www.olapreport.com/fasmi.htm>. Acesso em: 29 set. 2006. PESQUISA em Administração. São Paulo, FEA/USP, v.1, n.11, 1º Trimestre/2000, p.46-57.

PORTER, M. Estratégia Competitiva: Técnicas para Análise de Indústrias e da Concorrência. Rio de Janeiro: Campus, 1986.

REINHARD, N. Evolução das ênfases gerenciais e de pesquisa na área de tecnologia de informática e de comunicações aplicada nas empresas. Revista da Administração. São Paulo: v. 4, 1996. p.5-6.

SERRA, L. A. Essência do Business Intelligence. São Paulo: Editora Berkeley, 2002.

THOMSEN, E. OLAP Solutions: Building John Wiley & Sons, Inc., 1.ed., 1997.