Livro Apostila BI

Apostila de Treinamento – Business Intelligence

Capitulo 1 - O que é Business Intelligence? 1.1. Introdução 1.2. Business Intelligence – Conceitos e analises 1.3. Business Intelligence - Histórico 1.4. Business Intelligence – Benefícios 1.5.Gestão do Conhecimento e Sistemas de Informação 1.5.1. Conceitos Básicos de Gestão do Conhecimento 1.5.1.1. O que e dado? 1.5.1.2. O que é a informação? 1.5.1.3. O que é conhecimento? 1.5.2.Visão geral – Dados, Informação e Conhecimento: 1.5.3. Gestão do Conhecimento 1.5.4. Administração de Dados 1.5.5. Sistemas de Informação em Organizações. 1.5.6. Componentes de Sistemas de Informação. Capitulo 2 - Data Warehouse 2.1. Introdução 2.2. O que é um Data Warehouse? 2.2.1. Orientado por assunto 2.2.2. Integrado 2.2.3. Histórico 2.2.4. Não volátil 2.3. Um pouco mais sobre Data Warehouse 2.4. Construindo um Data Warehouse 2.4.1. Arquitetura de um Data Warehouse 2.4.1.1. Visão Conceitual 2.4.1.2. Visão Física (em Camadas) 2.4.2. Estrutura Física dos Dados do DW 2.4.2.1. Arquitetura de Duas Camadas 2.4.2.2. Arquitetura de Três Camadas 2.4.3. OLTP versus OLAP 2.4.4. Projeto e Desenvolvimento de Sistemas de Data Warehouse 2.4.4.1. Funções dos Componentes da Equipe 2.4.4.2. Análise entre Model. Dimensional e Model. Relacional 2.4.4.3. Problemas Encontrados no Desenvolvimento de Data Warehouses 2.4.5. Melhorando a performance do Data Warehouse 2.4.5.1. Intercalação de Tabelas 2.4.5.2. Introdução de Informações Redundantes 2.4.5.3. Separação de Dados 2.4.6. Componentes dos Sistemas de DW 2.4.6.1. O Sistema Gerenciador de Banco de Dados 2.5. O Ciclo de vida do desenvolvimento de d e um Data Warehouse 2.6. Considerações Iniciais para a criação de um Data Dat a Warehouse 2.7.Dados Operacionais (11) 3531 6550 - www.strattus.com.br www.strattus.com.br

1


Capitulo 3 - Modelagem Dimensional 3.01. Introdução 3.02. Modelagem de dados 3.03. Modelagem Dimensional 3.04. Processo da Modelagem Dimensional 3.05. Processo de Modelagem de um Data Dat a Warehouse 3.06. Tipos de Arquitetura 3.06.1. Arquitetura "Top-Down" 3.06.2. Arquitetura "Bottom-Up" 3.06.2.1 Enterprise Data Mart Architecture (EDMA) (EDM A) 3.06.2.2 Data Storage/Data Mart (DS/DM) 3.06.3. Arquitetura intermediária 3.07. Data Marts 3.08. Gerando o modelo dimensional através do StarSchema 3.08.1. Variações do StarSchema 3.08.2. Vantagens do modelo StarSchema 3.08.3. Tabela de fatos 3.08.3.1. Fatos com produtos heterogêneos 3.08.3.2. Classificação de atributos em uma tabela de d e Fatos 3.08.4. Tabela de Dimensão 3.08.4.1. Dimensões com Itens Heterogêneos 3.08.4.2. Dimensões Descaracterizadas 3.08.4.3.Tratamento de dimensões e fatos com cardinalidade 3.08.4.4.Técnicas de rastreamento de alterações 3.08.4.5. Criando novas chaves 3.08.4.6. Criando de Mini - dimensões 3.08.5. Granularidade 3.08.6. Medidas de derivação 3.09. Data Mining 3.10. Metadados 3.11. OLAP 3.11.1. Geração de Consultas (Queries) Capitulo 4 – Criando um Data Mart de Vendas Não disponível Capitulo 5 – Especiais Não disponível

(11) 3531 6550 - www.strattus.com.br www.strattus.com.br

2


“Business Intelligence não é algo que se compra de um fornecedor, mas um objetivo alcançado por uma organização .” .” Luiz Câmara, Presidente da InfoBuild Brasil

Capítulo 1 – O que é Business Intelligence? 1.1. Introdução Com o passar dos anos a necessidade de conhecimento, vem crescendo cada vez mais neste mundo globalizado. Acredito que podemos chamar este século de “A ERA DA INFORMAÇÃO”. Com isso, o volume de dados e seus devidos repositórios vem se multiplicando, se tornando armazéns de dados isolados que dificultam a análise e a compreensão verdadeira verdade ira de todo o negócio. Ou seja, nós os profissionais de tecnologia, envolvidos nas camadas de gerenciamento e análise de dados, temos como principal objetivo ajudar as empresas a transformar os grandes volumes de registros em informações relevantes para a empresa, suportando os processos de decisão estratégica e gerando vantagens competitivas no mercado. Toda esta habilidade é chamada de Business Intelligence (BI), que apoiada por ferramentas de tecnologias adequadas, permite organizar dados dispersos em uma empresa, de forma a torná-los inteligíveis e depois estudá-los com o objetivo de gerar o “Conhecimento” e “Inteligência”, a serem utilizados no desenvolvimento estratégico de ações, que beneficiam todo o negócio. Como exemplo deste emaranhado e complexo sistema de informação, podemos citar os tradicionalmente sistemas legados das empresas ERP (Enterprise Resource Planning), bem como as fontes externas de dados e outras fontes de informação (Planilhas, Arquivos de lotes, etc). Tudo isso faz com que as organizações empenhem seus esforços na construção de ferramentas, que através de uma análise refinada do negócio, mais os conceitos de Business Intelligence, integrados a crescente tecnologia de softwares voltados a esta área, possam monitorar e acompanhar a evolução das tomadas de decisões, com precisão e rapidez. O objetivo desta obra é conscientizar todos os escalões das empresas privadas, bem como os órgãos públicos em geral, qual a importância no tratamento da informação e das reais necessidades de investimento nos projetos de Business Intelligence . Digo com propriedade que depois de meus vinte e sete anos como desenvolvedor de ERPs legados, como documentador e principalmente como especialista em (11) 3531 6550 - www.strattus.com.br www.strattus.com.br

3


reporting que; a busca de novas oportunidades no mercado, bem como a gestão

ideal para nossos negócios, não vira sem que tenhamos um bom e estruturado projeto de BI, ou seja, centralizar as informações, de forma racional e orientada às necessidades do nosso negócio. Essa é sem dúvida alguma, a melhor forma de se tomar decisões estratégicas. No decorrer desta obra, o amigo leitor vai conhecer um pouco mais sobre Business Intelligence , vai acompanhar conceitualmente e na prática a criação de um Data Warehouse e ver como eles são fundamentais em qualquer projeto de BI.

Vai visualizar como a partir destas informações armazenadas em formato simples e organizadas, podem ser realizadas as análises para a tomada de decisões estratégicas relacionadas ao seu negócio. Também vai conhecer o conceito dos poderosos Data Marts e a fantástica modelagem dimensional, bem como as tecnologias de OLAP , que serão amplamente comparadas com a OLTP . Aqui o amigo leitor ainda avaliará os conceitos do Balanced Scorecard e de gestão do conhecimento, bem como poderá testar na prática a criação de um Data Warehouse, através de um pequeno projeto de BI, analisado e demonstrado em todas as suas etapas. 1.2. Business Intelligence – Conceitos e análises O mercado mundial como um todo, não para de comentar e divulgar sobre a coqueluche do momento, “Business Intelligence ”; suas aplicações e soluções tecnológicas disponíveis no mercado. Porém, eu lhe pergunto amigo leitor, será que realmente sabemos sobre o que estamos falando? Acredito que precisamos, antes de qualquer coisa, ter a consciência real sobre o conceito de BI, para o qual existem os mais diversos tipos de análises e conceitos na atualidade. Nosso primeiro passo será o entendimento dos dois termos que compõem o referido conceito: Business (negócio) e Intelligence (inteligência) O primeiro, quer dizer a intermediação de uma atividade comercial com fins lucrativos, quando se trata do mundo empresarial. O segundo se refere à faculdade de aprender ou compreender; capacidade de resolver situações complexas e problemáticas, mediante a reestruturação da informação perceptiva (Física). Com a junção dos dois termos acima, é correto supor que a inteligência do negócio está ligada intrinsecamente à capacidade das pessoas em posições estratégicas dentro de uma corporação e que estão diretamente ligadas ao negócio. Pessoas estas, com poder de decisão para adaptar, implementar ou (11) 3531 6550 - www.strattus.com.br

4


alterar o rumo da empresa (estrutura, recursos humanos, financeiros, materiais, etc.) ou externamente (mercado, concorrência, econômico, etc.). O conceito de BI tem como principal objetivo, auxiliar estes homens e mulheres a aprimorar o processo de tomada de decisão, através do tratamento das bases de dados existentes. O BI engloba o uso de ferramentas sofisticadas, que fazem parte da área de pesquisa como, por exemplo, a Inteligência Artificial (IA). Estas ferramentas proporcionam além de informações mais detalhadas, uma base de conhecimento extensa, modelada e racionalizada, que conseqüentemente dissemina o conhecimento obtido no tratamento da base de dados, que nada mais são do que as práticas oriundas das decisões tomadas por toda a empresa. As empresas fazem parte do mundo dos negócios e esse visa eternamente ao lucro, ao retorno dos capitais investidos no menor tempo possível. Numa realidade competitiva como esta, as informações estratégicas assumem um papel fundamental para o sucesso dessa empreitada. É óbvio que não podemos deixar de citar a enorme quantidade de informações que são despejadas sobre nós diariamente. Desta forma precisamos de mecanismos eficientes que nos ajudem a criar e monitorar critérios para selecionarmos e organizarmos as informações que realmente nos interessam. Como não poderia deixar de ser, os sistemas de informações prestam uma grande ajuda nesse sentido. Esse sistema proporciona lucros quando permite que uma maior quantidade de bens sejam produzidos, uma maior quantidade de clientes sejam atendidos, a satisfação dos mesmos sejam conquistadas, e finalmente, permite uma melhor alocação dos recursos disponíveis. Quando a empresa consegue obter essas informações rapidamente e de forma estruturada, ela sem dúvida sairá na frente de seus concorrentes, descobrindo os problemas com seus produtos e serviços, possibilitando corrigi-los com maior velocidade e eficiência. A informação estratégica proporciona saber se os seus clientes estão satisfeitos e poderá definir novas estratégias para expansão de sua empresa no mercado. Mas, o ponto mais importante nessa mistura de tecnologias é a empresa poder direcionar todo seu capital intelectual para a sua devida função, que é pensar. Os gerentes e diretores poderão ter as informações rapidamente e também terão mais tempo para melhorarem todos seus processos e analisarem mais os seus dados, que passarão a ser valiosas informações. Aí a Tecnologia da Informação (TI) estará exercendo seu grande papel, que é o de fornecer informações de qualidade e deixar de ser uma armazenadora de dados.

(11) 3531 6550 - www.strattus.com.br

5


O Business Intelligence pode ser entendido como um leque conceitual que envolve a Inteligência Competitiva (CI), a Gerência de Conhecimento (KMS) e a Internet Business Intelligence (IBI), pesquisa e análise de mercado, relacionados à nova era da Informação, dedicada a captura de informações e conhecimentos que permitem as organizações competirem com maior eficiência e exatidão. Isso é bom para cada um de nós clientes e consumidores. E melhor ainda para os profissionais que fazem parte dessas grandes empresas, pois além de nos capacitarmos ainda mais, conseguiremos ajudar a nossas instituições coorporativas a crescerem e chegarem a excelência de seus negócios. Segundo Gartner Group: “A maior ameaça das empresas da atualidade é o desconhecimento... O Business Intelligence se empenha em eliminar as dúvidas e a ignorância das empresas sobre suas informações, aproveitando os enormes volumes de dados coletados pelas empresas”. Por fim, o BI ou Inteligência Empresarial tem como principal objetivo à integração dos aplicativos e tecnologias para extrair e analisar os dados corporativos de maneira simples, no formato correto e no tempo certo, para que a empresa possa tomar decisões melhores e mais rápidas, sempre buscando auxiliar o executivo em seus negócios. 1.3. Business Intelligence - Histórico Ao contrário do que se possa imaginar, o conceito de Business Intelligence não é recente. Civilizações antigas já 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. O mundo mudou desde então, mas o conceito permanece o mesmo. A necessidade de cruzar informações para realizar uma gestão empresarial eficiente é hoje uma realidade tão verdadeira quanto no passado foi descobrir se a alta da maré iria propiciar uma pescaria mais abundante. Pela visão da tecnologia, a era que podemos chamar de "pré-BI" está num passado não muito distante, algo entre trinta ou quarenta anos atrás. Nesta época, quando os computadores deixaram de ocupar salas gigantescas, na medida em que diminuíram de tamanho e ao mesmo tempo, as empresas passaram a perceber os dados como uma possível e importante fonte geradora de informações decisórias. (11) 3531 6550 - www.strattus.com.br

6


No entanto, naquela época ainda não existiam recursos eficientes que possibilitassem uma análise consistente desses dados para a tomada de decisão. Era possível reunir informações de maneira integrada, fruto de sistemas transacionais estabelecidos com predominância em dados relacionais, mas que, reunidos como blocos fechados de informação, permitiam uma visão da empresa, mas não traziam ganhos decisórios ou negociais. Estamos falando do final dos anos 60, período em que cartões perfurados, transistores e linguagem COBOL eram a realidade da Informática. Era a época em que se via o computador como um desconhecido, um vislumbre de modernidade, mas que ainda parecia estar em uma realidade muito distante. O panorama começou a mudar na década de 70, com o surgimento das tecnologias de armazenamento e acesso a dados, Direct Access Storage Device (DASD), dispositivo de armazenamento de acesso direto, e o Sistema Gerenciador de Banco de Dados (SGBD), duas siglas cujo principal significado era o de estabelecer uma única fonte de dados para todo o processamento. A partir daí o computador passou a ser visto como um coordenador central para atividades corporativas e o banco de dados foi considerado um recurso básico para assegurar a vantagem competitiva no mercado. No início dos anos 90, a maioria das grandes empresas contava somente com Centros de Informação (CI) que embora mantivessem estoque de dados, ofereciam pouquíssima disponibilidade de informação. Mesmo assim, os CI supriam, de certa forma, as necessidades de executivos e detentores das tomadas de decisão, fornecendo relatórios e informações gerenciais. O mercado passou a se comportar de modo mais complexo e a tecnologia da informação progrediu rumo ao aprimoramento de ferramentas de software, as quais ofereciam informações precisas e no momento oportuno para definir ações que tinham como foco a melhoria do desempenho no mundo dos negócios. No inicio da década de 90, surgiu o Data Warehouse (DW) que é uma grande base de dados de informação, ou seja, um único repositório de dados. Considerado pelos especialistas no assunto, como o elemento principal para a execução prática de um projeto de BI. No entanto, quando se trata de BI, as opiniões nem sempre são unânimes. Na avaliação de alguns consultores é importante que a empresa que deseja incorporar ferramentas de análise disponha de um repositório específico para reunir os dados já transformados em informações Esse repositório não precisa ser necessariamente, um DW, mas algo menos complexo como, por exemplo, um Data Mart (Um banco de dados ou parte dele, desenhado de forma personalizada para departamentos), ou um banco de dados relacional comum, mas separado do ambiente transacional (operacional) e (11) 3531 6550 - www.strattus.com.br

7


dedicado a armazenar as informações usadas como base para a realização de diferentes analises e projeções. Como já foi mencionado acima, o conceito de Business Intelligence é muito mais antigo do que se imagina. Mas o desenvolvimento tecnológico ocorrido a partir da década de 70 e nos anos posteriores, é que possibilitou a criação de ferramentas que vieram a facilitar todo o processo de captação, extração, armazenamento, filtragem e disponibilidade personalizada dos dados. Isso fez com que o setor corporativo passasse a se interessar cada vez mais pelas soluções de BI, principalmente por volta do final de 1996, quando o conceito começou a ser difundido como um processo de evolução do Executive Information Systems (EIS - Sistema de informações executivas), um sistema criado no final da década 70, a partir dos trabalhos desenvolvidos pelos pesquisadores do Massachusets Institute of Tecnology/EUA (MIT). O EIS é na verdade, um software que objetiva fornecer informações empresariais a partir de uma base de dados. É uma ferramenta de consulta às bases de dados das funções empresariais para a apresentação de informações de forma simples e amigável, atendendo às necessidades dos executivos da alta administração principalmente. Permite o acompanhamento diário de resultados, tabulando dados de todas as áreas funcionais da empresa para depois exibi-los de forma gráfica e simplificada, sendo de fácil compreensão para os executivos que não possuem profundos conhecimentos sobre tecnologia. Em termos simples o EIS permite a esses profissionais o acesso amigável a uma série de informações pela via eletrônica, apresentadas de forma clara e visualmente atraente. Com o passar dos anos o termo Business Intelligence ganhou maior abrangência, dentro de um processo natural de evolução, como o próprio EIS, e mais as soluções Decision Support System ( DSS - Sistema de Suporte à Decisão), Planilhas Eletrônicas, Geradores de Consultas e de Relatórios, Data Marts , Data Mining , Ferramentas OLAP , entre tantas outras que têm como objetivo promover agilidade comercial, dinamizar a capacidade de tomada de decisões. A história do Business Intelligence também está profundamente atrelada ao ERP sigla que representa os sistemas integrados de gestão empresarial cuja função é facilitar os processos operacionais das empresas. Esses sistemas registram, processam e documentam cada fato novo na empresa e distribuem as informações de maneira clara e segura, em tempo real. Mas as empresas que implantaram estas soluções logo se deram conta de que apenas armazenar grande volume de dados, não lhes serviriam de nada, já que essas informações se encontravam repetidas, incompletas e espalhadas em vários repositórios dentro da corporação. Percebeu-se que era preciso dispor de ferramentas que permitissem reunir esses dados em uma única base de informação e trabalhá-los de forma, que possibilitassem realizar diferentes análises sob variados ângulos. (11) 3531 6550 - www.strattus.com.br

8


Tradicionalmente, o Business Intelligence pertenceu ao domínio do pessoal de TI e dos especialistas em pesquisa de mercado, responsáveis pela extração de dados, pela implantação de processos e pela divulgação dos resultados aos executivos responsáveis pela tomada de decisões. Mas com o crescimento da Internet tudo mudou. Hoje, a rede permite disponibilizar soluções de BI para um número cada vez maior de pessoas dentro e fora das grandes corporações. 1.4. Business Intelligence – Benefícios O BI consegue trazer inúmeros benefícios para as organizações que o utilizem “de forma correta”. Veja abaixo uma lista destes benefícios. Antecipar mudanças no mercado; Antecipar ações dos competidores; Descobrir novos ou potenciais competidores; Aprender com os sucessos e as falhas dos outros; Conhecer melhor suas possíveis aquisições ou parceiros; Conhecer novas tecnologias, produtos ou processos que tenham impacto no seu negócio; Conhecer sobre política, legislação ou mudanças regulamentais que possam afetar o seu negócio; Entrar em novos negócios; Rever suas próprias práticas de negócio; Alinhar projetos de tecnologia com as metas estabelecidas pelas empresas na busca do máximo retorno do investimento; Propiciar alternativas de investimento em tecnologia dentro do contexto estratégico, tecnológico e financeiro da empresa; Ampliar a compreensão das tendências dos negócios, propiciando melhor consistência no momento de decisão de estratégias e ações; Permitir uma análise de impacto sobre rumos financeiros e organizacionais para criar mudanças nas iniciativas gerenciais; Facilitar a identificação de riscos e gerar segurança para migração de estratégias, criando maior efetividade nas implementações dos projetos; Abrir um caminho orientado para implantações futuras de novas tecnologias, estabelecendo prazos e focando o orçamento dentro das perspectivas e objetivos da empresa; Gerar, facilitar o acesso e distribuir informação de modo mais abrangente para obter envolvimento de todos os níveis da empresa.

• • • • • •

•

• •

•

•

•

•

•

•

•

Podemos citar exemplos mais específicos como o setor comercial, marketing, economia e finanças, como as primeiras e mais promissoras áreas para a aplicação dos projetos de BI.


9


Na área comercial o BI oferece os seguintes benefícios: Melhora no prognóstico de vendas; Visibilidade contábil abrangente; Integração entre orçamento de análise; melhor compreensão da segmentação do mercado; Flexibilidade e interação dos relatórios financeiros; Melhoria nas decisões de distribuição de produtos.

• • •

•

Benefícios para a área de marketing: • • •

•

Campanha de marketing dirigido; Informações personalizadas de cliente; Comportamento e freqüência de compra ou preferências são obtidos de uma forma rápida e fácil com a utilização das ferramentas de BI; Fidelização dos clientes; Mala direta e público alvo.

Benefícios para a área de economia e finanças: • • •

Ações personalizadas, avaliação de riscos e de oportunidades futuras; Análise de crédito e de riscos em empresas do setor financeiro; Controle de fraude de empresas de seguro.

1.5. Gestão do Conhecimento e Sistemas de Informação Antes de iniciarmos com o desenvolvimento e as aplicações referentes ao projeto de BI, vamos falar um pouco sobre a gestão do conhecimento e os sistemas de informação, já que na minha humilde visão, nenhuma empresa conseguirá criar um bom DW, sem que seus processos e ações não estejam baseados nestes dois conceitos. O conceito de Gestão do Conhecimento surgiu no inicio da década de 90 em que a Gestão do Conhecimento não era mais um tipo de moda de eficiência operacional. Agora a GC fazia parte da estratégia empresarial. 1.5.1. Conceitos básicos de Gestão do Conhecimento Sem compreender o conceito de dado, informação e conhecimento, não conseguiremos apresentar o processo de Gestão do Conhecimento.


10


1.5.1.1. O que é dado? Dado pode ter significados distintos, dependendo do contexto no qual a palavra é utilizada. Para uma organização, dado é o registro estruturado de transações. É informação bruta, descrição exata de algo, ou de algum evento. Os dados em si não são dotados de relevância ou propósitos, mas são importantes porque são a matéria essencial para a criação da informação. 1.5.1.2. O que é a informação? Informação é uma mensagem com dados que fazem diferença, podendo ser audível ou visível. É onde existe um emitente e um receptor. É o resultado mais importante da produção humana. Definir informação não é uma tarefa fácil. Se partirmos da clássica distinção entre dados, informação e conhecimento encontraremos certa imprecisão. Informação é um termo que envolve todas as três palavras, e ainda serve como conexão entre os dados brutos e o conhecimento que no decorrer das análises pode ser obtido. Esses termos às vezes são utilizados de forma inadequada, o que podemos constatar quando verificamos que durante muito tempo as pessoas se referiam aos dados como informação. O significado da informação e seus propósitos exigem de imediato, a redefinição não apenas das tarefas que são realizadas com a ajuda desta informação, mas também dos processos que as utilizam como insumos. Veja que as pessoas transformam dados em informação. Ao contrário dos dados a informação exige análise. Este é sem dúvida o maior desafio imposto aos especialistas da T.I. 1.5.1.3. O que é conhecimento? Conhecimento é o estágio mais avançado da informação, mais valioso, mais difícil de gerenciar e de se obter. É valioso precisamente porque se trata de uma informação que recebeu um significado, uma interpretação. Algum indivíduo ou um grupo refletiu sobre conhecimento, acrescentou a ele sua própria sabedoria, considerou suas implicações mais amplas. O conhecimento, muitas vezes é tácito – existe simbolicamente na mente humana e é difícil de explicitar. O homem tenta insistentemente incorporar conhecimento às máquinas, mas os resultados ainda são tímidos e sua aplicação restrita.


11


O Conhecimento deriva da informação assim como esta, dos dados. O conhecimento não é puro nem simples; mas é uma mistura de elementos, é fluido e formalmente estruturado; é intuitivo e, portanto, difícil de ser colocado em palavras ou de ser plenamente entendido em termos lógicos. Ele existe dentro das pessoas e por isso é complexo e imprevisível. O Conhecimento humano pode ser classificado em dois tipos: Conhecimento explícito e Conhecimento tácito. NONAKA e TAKEUSHI [01]. Conhecimento explícito: É o que pode ser articulado na linguagem formal,

inclusive em afirmações gramaticais, expressões matemáticas, especificações, manuais etc., facilmente transmitido, sistematizado e comunicado. Ele pode ser transmitido formal e facilmente entre os indivíduos. Esse foi o modo dominante de conhecimento na tradição filosófica ocidental. Conhecimento tácito : É difícil de ser articulado na linguagem formal, é um tipo de

conhecimento mais importante. É o conhecimento pessoal incorporado à experiência individual e envolve fatores intangíveis como, por exemplo, crenças pessoais, perspectivas, sistema de valor, intuições, emoções e habilidades. É considerado como uma fonte importante de competitividade entre as Organizações. Só pode ser avaliado por meio da ação. Portanto, os conhecimentos explícito e tácito são unidades estruturais básicas que se complementam e a interação entre eles é a principal dinâmica da criação do conhecimento na organização de negócio. 1.5.2. Visão geral – Dados, informação e conhecimento: Dados

Simples observações sobre o estado do mundo - Facilmente estruturado - Facilmente obtido por máquinas - Freqüentemente quantificado - Facilmente transferível

Informação

Dados dotados de relevância e propósito - Requer unidade de análise - Exige consenso em relação ao significado - Exige necessariamente a mediação humana





Conhecimento

Informação valiosa da mente humana. Inclui reflexão, síntese e contexto. - De difícil estruturação - De difícil captura em máquinas - Freqüentemente tácito - De difícil transferência









A evolução no processo dados – informação - conhecimento exige cada vez mais o envolvimento humano. Os computadores são ótimos para nos ajudar a lidar com dados, mas quando evoluímos para informação a adequação diminui, tornando-se crítica com o conhecimento.


12


1.5.3. Gestão do conhecimento A Gestão do Conhecimento é o processo de identificação, criação e aplicação dos conhecimentos que são estratégicos na vida de uma empresa. Permite a organização como um todo saber o que ela “SABE”. A gestão do conhecimento leva as organizações a mensurar com mais segurança a sua eficiência, tomar decisões acertadas com relação a melhor estratégia a ser adotada em relação a seus clientes, concorrentes, canais de distribuição e ciclo de vida de produtos e serviços. 1.5.4. Administração de dados Saber administrar dados é trabalhar o dado como base estratégica da organização, representando a empresa, independentemente dos processos das diferentes unidades que utilizem o dado. “A administração de dados (Gestão de dados) pode ser definida como uma função da organização responsável por desenvolver e administrar centralizadamente estratégias, procedimentos, prática e planos capazes de fornecer dados corporativos necessários, quando necessários, revestidos de integridade, privacidade, documentação e compartilhamento”. SERRA [02] A administração de dados em uma organização pode ter uma atuação ampla, participando efetivamente do Planejamento Estratégico Empresarial junto à direção das empresas onde permitiria detectar, entre outros, as necessidades de informação futuras, pois estaria planejando melhor suas bases de dados em atendimento aos negócios da corporação e atuando fortemente na administração dos dados informatizados e os não informatizados espalhados pelos diversos setores da organização. Portanto, ao administrador de dados, cabe: procurar identificar, descrever (documentar) e modelar (estruturar) os dados - chave a serem armazenados e gerenciados (manipulados), além de cuidar das adaptações impostas pelo Sistema Gerenciador de Banco de Dados Relacional (SGBDR) e dos aspectos de desempenho e segurança. 1.5.5. Sistemas de informação em organizações A tecnologia da informação esta redefinindo os fundamentos das regras de negócios. Atendimento ao cliente, operações, estratégias de produto e de marketing e distribuição dependem muito, ou às vezes até totalmente, dos Sistemas de Informação (SI). A tecnologia da informação e seus custos passaram a fazer parte integralmente do dia-a-dia das empresas.


13


É indiscutível que toda organização têm pelo menos dois problemas genéricos: como gerenciar as forças e grupos internos que geram seus produtos e serviços, e como lidar com clientes, legislações, concorrentes e tendências gerais sócios econômicas em seu ambiente. A principal razão pela qual são construídos os sistemas de informação é para resolver problemas organizacionais e para reagir a uma mudança no ambiente LAUDON [03]. Alguns sistemas de informação tratam unicamente de problemas internos, alguns de assuntos puramente externos e outros cumprem os dois papéis. São classificados costumeiramente pela especialidade funcional a que se destinam e pelo tipo de problema. Nenhum sistema sozinho rege todas as atividades de uma empresa. Os sistemas em nível estratégico ajudam os gerentes seniores a planejar as ações de longo prazo. Os sistemas táticos auxiliam os gerentes de nível médio a supervisionar e coordenar as atividades diárias da empresa. Os especialistas e funcionários de escritório utilizam sistemas de conhecimento para projetar, racionalizar serviços e lidar com documentos, enquanto os sistemas operacionais tratam das atividades diárias de produção e serviço.

Imagem 01 Um sistema pode ser definido como um conjunto de partes coordenadas que concorrem para a realização de um conjunto de objetivos, seguindo um plano. Qualquer sistema pode ser encarado como um subsistema de um maior, sendo isso denominado hierarquia de sistemas. POLLONI [04].


14


Segundo LAUDON [*]: “Um sistema de informação (S.I.) pode ser definido como um conjunto de componentes inter-relacionados trabalhando juntos para coletar, recuperar, processar, armazenar e distribuir informação com a finalidade de facilitar o planejamento, o controle, a coordenação, a análise e o processo decisório em empresas e outras organizações”.

Um sistema é um grupo de componentes inter-relacionados que trabalham juntos de encontro a uma meta comum recebendo os resultados e produzindo resultados em um processo organizado de transformação. Um sistema dessa ordem, às vezes chamado de sistema dinâmico, possui três componentes ou funções básicas em interação: O conteúdo dos sistemas de informações varia de empresa para empresa, face às necessidades específicas de cada entidade. Em geral contêm informação sobre pessoas, lugares e coisas de interesse no ambiente ao redor da organização e dentro da própria organização. Sua principal tarefa é transformar a informação em uma forma utilizável para a coordenação do fluxo de trabalho de uma empresa, auxiliando a tomada de decisões em todos os níveis e a previsão e solução de assuntos complexos. Três atividades básicas compõem um sistema de informações: entrada (ou input), processamento e saída (ou output). A entrada envolve a captação ou coleta de fontes de dados brutos de dentro da organização ou de seu ambiente externo. São exemplos de dados: total de unidades vendidas ou compradas, datas, descrição de clientes e produtos. A entrada envolve a captação e reunião de elementos que entram no sistema para serem processados. O processamento envolve processos de transformação que convertem Resultado (entrada) em produto. Entre os exemplos se encontram um processo industrial, o processo da respiração humana ou cálculos matemáticos. A saída envolve a transferência de elementos produzidos por um processo de transformação até seu destino final. Produtos acabados, serviços humanos e informações genéricas devem ser transmitidos a seus usuários. Deve-se ressaltar que um sistema de informação pode ser formal ou informal, organizacional ou individual, baseado em computadores (SIBC) ou não. LAUDON [03]. Os SIBC são sistemas formais que se baseiam em definições de dados de procedimentos, mutuamente aceitos e relativamente fixos, para a coleta, armazenamento, processamento e distribuição de informação. Por exemplo, um (11) 3531 6550 - www.strattus.com.br

15


arquivo manual de nomes e endereços de clientes ou um catálogo alfabético por cartões em uma biblioteca é um sistema de informação formal, pois é estabelecido por uma organização e está de acordo com regras e procedimentos organizacionais; isto quer dizer que cada entrada no sistema tem o mesmo formato de informação e o mesmo tipo de conteúdo. Os sistemas informais, ao contrário, não têm essas características. Não há acordo sobre que informação existe como será armazenada e o que será armazenado ou processado. Muitos não deixam de ser importantes, na realidade, são muito poderosos e flexíveis. Exemplos desses sistemas informais são as redes de boato no escritório, grupos de amigos, estudantes e ainda pessoas com interesses comuns que trocam informações livremente sobre um grande número de assuntos, tópicos e personalidades mudando-os constantemente. Os SIBC são montados com a finalidade de resolver problemas importantes na organização. De acordo com POLLONI [*], um SIBC eficaz, deve: 1. “Produzir informações realmente necessárias, confiáveis, em tempo hábil e com custo condizente, atendendo aos requisitos operacionais e gerenciais de tomada de decisão”; 2. “Tem por bases diretrizes capazes de assegurar a realização dos objetivos, de maneira direta, simples e eficiente”; 3. “Integrar-se à estrutura da organização e auxiliar na coordenação das diferentes unidades organizacionais (departamentos, divisões, diretorias etc.) por ele interligadas”; 4. “Ter um fluxo de procedimentos (internos e externos ao processamento) racional, integrado, rápido e de menor custo possível”; 5. “Contar com dispositivos de controle interno que garantam a confiabilidade das informações de saída e adequada proteção aos dados controlados pelo Sistema”; 6. “Finalmente, ser simples, seguro e rápido em sua operação”. 1.5.6. Componentes de Sistemas de Informação. Os mais poderosos sistemas de informação da atualidade usam tecnologia da Informação para executar parte das funções de processamento, isto não quer dizer que apenas investindo em computadores teremos excelentes sistemas. Um sistema bem sucedido tem dimensões organizacional e humana atreladas aos componentes técnicos. (11) 3531 6550 - www.strattus.com.br

16


Ele existe para atender as necessidades organizacionais, incluindo problemas apresentados pelo ambiente externo criado por tendências políticas, demográficas, econômicas e sociais LAUDON [9]. As organizações devem moldar seus sistemas de informações de acordo com suas necessidades, hierarquias, estrutura funcional e sua cultura específica. Diferentes níveis e diferentes especialidades em uma organização criam interesses e pontos de vista diferentes, que freqüentemente conflitam entre si. Os sistemas de informação devem responder e resolver estes conflitos internos além de problemas criados pelo ambiente externo. As pessoas são os usuários dos sistemas de informação sob o enfoque de fornecimento de insumos e utilização de seus produtos, tudo integrado ao seu ambiente de trabalho. Suas atitudes a respeito de seus empregos, empregadores ou da tecnologia de computação podem ter um efeito poderoso sobre sua capacidade de usar sistema de informação de modo produtivo. Os sistemas de processamento de transações são exemplos importantes de sistemas de apoio às operações que registram e processam dados resultantes de transações das empresas. Eles processam transações de dois modos básicos. No processamento em lotes, os dados das transações são acumulados durante certo tempo e periodicamente processados. No processamento em tempo real (ou on-line), os dados são processados imediatamente depois da ocorrência de uma transação. Os sistemas de ponto -de - venda, por exemplo, em muitas lojas de varejo utilizam terminais eletrônicos no caixa para capturar e transmitir eletronicamente dados de vendas por conexões de telecomunicações para centros regionais de computação para processamento imediato (tempo real) ou a cada noite (lote). Os sistemas de controle de processo monitoram e controlam processos físicos. Uma refinaria de petróleo, por exemplo, utiliza sensores eletrônicos conectados a computadores para monitorar continuamente os processos químicos e fazer ajustes imediatos (em tempo real) que controlam o processo de refino. Os sistemas colaborativos aumentam as comunicações e a produtividade de equipe de projeto, por exemplo, podem usar correio eletrônico para enviar e receber mensagens eletrônicas e videoconferência para realizar reuniões eletrônicas e coordenar suas atividades. A tecnologia é o meio empregado para transformação e organização dos dados para utilização das pessoas. Não necessariamente um sistema de informação é computadorizado, podendo ser um sistema manual, tal como um arquivo de (11) 3531 6550 - www.strattus.com.br

17


fichários, porém os computadores substituíram a tecnologia manual de processamento de grandes volumes de dados e de trabalhos complexos de processamento. Os sistemas baseados em computadores têm como componentes técnicos: •

O hardware de computador : É o equipamento físico usado para as tarefas

de entrada, processamento e saída em um sistema de informação. É composto pela unidade de processamento do computador e nos vários dispositivos de entrada (teclado, “scanner”, “mouse”, “Etc”.). •

•

(Dispositivos de reconhecimento de caracteres ópticos – OCR, dispositivos de controle de voz, sensores), saída (impressora, plotters, terminais de vídeo e outros tipos de dispositivos) e armazenamento (Disco magnético e disco ótico), além dos meios físicos que interligam estes dispositivos. O software do computador: Consiste em instruções pré-programadas que

coordenam o trabalho dos componentes do hardware para que executem os processos exigidos pelos vários sistemas de informação. •

A tecnologia de armazenamento: serve para organizar e armazenar os

dados utilizados por uma empresa. A tecnologia de armazenamento inclui os meios físicos para armazenar os dados, assim como o software que rege a organização de dados nesses meios físicos. •

A tecnologia de comunicação: usada para conectar pontos diferentes do

hardware e para transferir dados de um ponto a outro via redes.

Quando os sistemas de informação se concentram em fornecer informação e apoio para a tomada de decisão eficaz pelos gerentes, eles são chamados sistemas de apoio gerencial. Fornecer informação e apoio para a tomada de decisão por parte de todos os tipos de gerentes (dos altos executivos, aos gerentes de nível médio e até os supervisores) é uma tarefa complexa. Em termos conceituais, vários tipos principais de sistemas de informação apóiam uma serie de responsabilidade administrativa do usuário final: 1. Sistemas de informação gerencial; 2. Sistemas de apoio à decisão; 3. Sistemas de informação executiva. Os sistemas de informação gerencial fornecem informação na forma de relatórios e exibições em vídeo para os gerentes. Os gerentes de vendas, por exemplo, podem utilizar seus terminais de computador para obter visualizações instantâneas sobre os resultados de vendas de seus produtos e acessar relatórios semanais de analise de vendas que avaliam as vendas realizadas por cada vendedor.


18


Os sistemas de apoio à decisão fornecem suporte computacional direto aos gerentes durante o processo de decisão. Os gerentes de propaganda podem utilizar um pacote de planilhas eletrônicas para realizar analise de simulação quando testam o impacto de orçamentos alternativos de propaganda sobre as vendas previstas para novos produtos. Os sistemas de informação executiva (EIS) fornecem informações critica em quadros de fácil visualização para uma multiplicidade de gerentes. Biografia [01] NONAKA e TAKEUCHI, 1997, IKUJIRO NONAKA, E HIROKATA T AKEUCHI, 1997, Criação de conhecimento na Empresa, Editora Campus, Rio de Janeiro, Brasil. [02] SERRA, 2002, LAÉRCIO SERRA, 2002, A Essência do Business Intelligence, Editora Berkeley, São Paulo, Brasil. [03] LAUDON, 2002, LAUDON, LAUDON, 2002, Gerenciamento de Sistemas de Informação, [04] POLLONI, 2001, ENRICO PLLONI e T IBOR SIMCSIK, 2002, Tecnologia da Informação Automatizada”, Editora Futura, São Paulo, Brasil.


19


Capítulo 2 – Data Warehouse? 2.1. Introdução Desde sua aparição no início da década de 90, e até os dias de hoje, o conceito e a operação de um DW (Data Warehouse), saíram do âmbito teórico, acadêmico, para a área empresarial, notando-se uma clara tendência no sentido de sua aceitação por praticamente todas as empresas que operam em ambientes competitivos. Antes da popularização dos DW e das ferramentas de ERP (Enterprise Resource Planning), uma verdadeira integração de dados era apenas um sonho, ou seja, era uma utopia a ser quebrada. Sistemas trocavam dados de forma que atendesse às necessidades de cada um deles, sendo por isso chamado "sistemas integrados", sem que essa integração sequer se aproximasse do que se vêem hoje nos ERP, cujos fornecedores têm dado a seus produtos características que os tornam facilmente fornecedores de dados aos warehouses. Cada aplicativo tinha uma visão da situação, um produto ou uma operação; uma visão corporativa das informações disponíveis era praticamente irreal. Dados históricos não existiam de forma organizada e os dados sintéticos disponíveis mostravam quase sempre apenas uma pequena parte da realidade da empresa. A integração dos dados permite a um executivo ter uma visão "corporativa" dos dados; essa integração, ou mais especificamente a migração dos dados mantidos pelos sistemas anteriores, no entanto, não é um processo fácil, nem barato. Tudo isso exige muito planejamento. Há algumas versões de Data Warehouse que merecem ser individualizadas por suas características especiais: uma delas é o Operational Data Store (ODS), que opera diretamente conectado aos dados operacionais, objetivando dar suporte a decisões de natureza operacional, com características que permitem a obtenção de tempos de resposta bastante rápidos. 2.2. O que é um Data Warehouse? Por Willian H. Inmon "Data Warehouse é um banco de dados orientado por assunto, integrado, não volátil e histórico, criado para suportar o processo de tomada de decisão."

Outra boa definição para DW vem de Gupta (1997): "um ambiente estruturado, extensível, projetado para a análise de dados não voláteis, lógica e fisicamente


20


transformados, provenientes de diversas aplicações, alinhados com a estrutura da empresa, atualizados e mantidos por um longo período de tempo, referidos em termos utilizados no negócio e sumarizados para análise rápida". De forma bastante simples, a imagem 1 mostra a arquitetura de um DW, com os sistemas que o alimentam, seus usuários, o DW propriamente dito e os metadados, cada um desses conceitos será amplamente discutido mais à frente:

Imagem 01

A definição de um Data Warehouse (por W. H. Inmon) necessita de um completo detalhamento, porque existem detalhes muito importantes e sutilezas básicas nas características de um Warehouse . Orientado por Assunto Integrado Histórico Não Volátil

• • • •

2.2.1. Orientado por assunto A primeira característica de um DW é que ele está orientado ao redor do principal assunto da empresa. O caminho do registro, orientado ao assunto está em contraste com a mais clássica das aplicações orientadas por processos ao redor dos quais os sistemas operacionais mais antigos estão organizados.


21


A imagem 02 mostra o contraste entre os dois tipos de orientações.

Operacional

Empréstimos

Cartão Bancário

Crédito

Data Warehouse

Clientes

Vendas

Produtos

Orientados ao assunto

Orientados a aplicação Imagem 02

No geral, o mundo da informação operacional está todo baseado ao redor de aplicações e funções transacionais. O mundo do Data Warehouse está organizado ao redor do principal assunto assim como por exemplo, cliente, vendas, produtos e atividades. O alinhamento ao redor das áreas de assunto afeta o desenho e implementação do dado criado no Data Warehouse, ou seja, a área do assunto mais influente é a parte mais importante da estrutura chave. O mundo das aplicações está preocupado com o desenho dos processos e de banco de dados. O mundo do Data Warehouse está focado exclusivamente na modelagem de dados e desenho do banco de dados. Nota: O desenho de processos (como é na forma clássica) não é parte de um am biente de Data Warehouse.

As diferenças entre aplicações orientadas por processos/funções e as orientadas por assunto, mostra as diferenças no conteúdo dos dados e no nível de detalhes dos mesmos. No Data Warehouse são excluídos os dados que não devem ser usados no processo de DSS (Sistemas de Suporte a Decisão), enquanto no (11) 3531 6550 - www.strattus.com.br

22


ambiente operacional as aplicações contêm dados para satisfazer imediatamente as requisições funcionais/processamento que podem ou não ser usadas para análise de DSS. Outra importante maneira na qual os dados operacionais das aplicações difere dos dados para Data Warehouse está no relacionamento dos dados. Dados operacionais mantêm relacionamentos entre duas ou mais tabelas baseadas nas regras de negócio que estão em efeito. Registros do DW usam uma base de tempo e os relacionamentos criados no DW são muitos. Muitas regras de negócio são representadas no DW entre duas ou mais tabelas. 2.2.2. Integrado O mais importante aspecto do ambiente de DW é que dados criados dentro de um DW são integrados. SEMPRE. COM NENHUMA EXCEÇÃO. Essa é sem duvida a melhor essência do ambiente de warehouse ... A integração mostra-se de diferentes maneiras: na convenção consistente de nomes, na forma consistente das variáveis, na estrutura consistente de códigos, nos atributos físicos consistente dos dados, e assim por diante. Veja os exemplos refletidos pela imagem 03

Imagem 03


23


A habilidade coletiva de muitos analistas de aplicações em criar produtos sem consistência é lendária. A imagem 3 apresenta algumas das muitas diferenças importantes na maneira como as aplicações são desenhadas. •

•

Codificação - desenvolvedores de aplicações têm preferido, por exemplo, codificar o campo SEXO das mais variadas formas. Um desenvolvedor representa SEXO com um "M" e um "F". Outro desenvolvedor representa SEXO com um "1" e um "0". Outro desenvolvedor representa SEXO com um "x" e um "y". E ainda outro desenvolvedor SEXO com "masculino" e "feminino". "M" e "F" são provavelmente bons para algumas representações. Entretanto quando SEXO é carregado para o DW de um projeto de BI, o mesmo deve ser convertido para um único formato; o formato do Data Warehouse. Forma dos atributos - desenvolvedores de aplicações têm preferido ao longo dos anos utilizarem uma variedade de medidas. Um desenvolvedor armazena dados em centímetros. Outro desenvolvedor armazena em polegadas. Outro desenvolvedor de aplicação armazena dados em milhões de pés cúbicos por segundo. E outro desenvolvedor armazena informações em termos de jardas. Quando a informação chega no Data Warehouse é necessário ser mensurada e transformada de algum modo.

2.2.3. Histórico Todo registro no Data Warehouse é exato em algum momento do tempo. A característica básica do dado em warehouse é ter muitas fontes de dados diferentes no ambiente operacional. No ambiente operacional o dado é exato no momento do acesso, ou seja, no ambiente operacional quando você acessa uma unidade do dado, você espera que isto deva refletir os valores corretos no momento do acesso. Por causa do dado em DW ser exato em algum momento do tempo, o dado criado no warehouse é um "histórico". A imagem 4 mostra os valores históricos do dado no warehouse. Os valores históricos dos dados no DW são mostrados em várias maneiras. O modo mais simples é que o dado representa os dados sobre um horizonte de tempo distante. O horizonte de tempo representado pelo ambiente operacional é muito curto. O segundo modo que o "histórico" é mostrado no DW é na estrutura chave. Sempre na estrutura chave do DW existe, explicitamente, ou implicitamente, um elemento de tempo, assim como dia, semana, meses, etc. O elemento de tempo está quase sempre no final da chave concatenada criada no DW.


24


A terceira maneira que o "histórico" aparece no DW, é que uma vez o registro estando correto, não pode ser atualizado. Dado no DW e, para todos os propósitos práticos, é uma série longa de snapshots . Naturalmente se os snapshots do dado têm sido feitos incorretamente, eles não são alterados uma vez feitos. Em alguns casos isto pode ser sempre ilegal, podendo os snapshots no DW, serem alterados. Dados operacionais iniciam pontualmente no momento do acesso, podendo ser atualizados quando surgir à necessidade.

Imagem 04

2.2.4. Não volátil A quarta característica definida para um DW é que ele é não volátil. Imagem 5 ilustra este aspecto no Data Warehouse . A imagem 5, apresenta que atualizações como, inclusão, exclusão, e alteração, são feitas regularmente no ambiente operacional de um registro básico. Mas a manipulação de dados básicos que ocorre no Data Warehouse é mais simples. Existem somente duas espécies de operações que ocorrem no DW, à carga inicial do dado, e o acesso ao dado. Esta não é uma atualização do dado (no sentido geral de atualização) no DW como parte normal do processamento. Para o nível de desenho, existe a necessidade de ter cautela nas atualizações anormais, o que não é um fato importante no DW, atualizações neste dado não são feitas. Existem meios para que no nível físico do desenho, permissões possam ser criadas para otimizar o acesso ao dado, particularmente em procedimentos com o uso de normalização e desnormalização física. Outras conseqüências da simplicidade das operações do DW estão na tecnologia básica usada para rodar no ambiente de DW. Como suporte para atualização de (11) 3531 6550 - www.strattus.com.br

25


registro por registro em modo on-line requer uma tecnologia com fundamentos muito complexos, em baixo da simplicidade de uso. A tecnologia que suporte backup , recovery , transação com integridade do dado, a detecção e correção de deadlock é muito complexa. Isto não é necessário para processamento de DW. As características de um Data Warehouse, desenho orientado ao assunto, integração dos dados com o Data Warehouse, histórico, e simplicidade de gerenciamento dos dados - todos conduzem para um ambiente que é MUITO, MUITO diferente do ambiente operacional básico. A fonte para aproximar todos os dados do Data Warehouse é o ambiente operacional. Muitas vezes as pessoas podem pensar que isto é mais uma redundância do dado entre os dois ambientes. De fato, na primeira impressão isso até ocorre, porém, este entendimento superficial é a necessidade de demonstrar o que está ocorrendo no Data Warehouse. De fato, este é o MÍNIMO de redundância do dado entre o ambiente operacional e o ambiente de Data Warehouse. Considere o seguinte: •

•

•

•

Dado é filtrado quando passa do ambiente operacional para o ambiente de Data Warehouse. Muitos dados nunca saem do ambiente operacional. Somente o dado que é necessário para o processamento do DSS é encontrado no ambiente warehouse; O histórico do dado é muito diferente de um ambiente para outro. Dado no ambiente operacional é muito recente. Dado no warehouse é muito antigo. Só na perspectiva de histórico recente, é muito pequeno o overlap entre o ambiente operacional e o ambiente de Data Warehouse; O DW contém dados sumarizados que nunca são encontrados no ambiente operacional; Dados sofrem uma fundamental transformação ao passar para o DW. Muitos dados são alterados significativamente após serem selecionados e movidos para o Data Warehouse . Dito de outra forma, muitos dados são fisicamente e radicalmente alterados quando movidos para o warehouse. Estes dados não são os mesmos que residem no ambiente operacional do ponto de vista de integração.

Nota: Redundância de dados entre os dois ambientes é uma ocorrência rara, resultando em menos que 1% de redundância entre os dois ambientes.


26


Imagem 5

2.3. Um pouco mais sobre Data Warehouse Não existe uma receita pronta para desenvolver um DW, porem, é possível encontrar várias ferramentas no mercado mundial que atendem e, ou abrangem desde as etapas de extração e análise de dados, até a construção propriamente dita, e o gerenciamento do DW. Um ponto importante a ser ressaltado é a observação do valor do investimento no projeto como um todo, geralmente situado na casa dos milhões de dólares. Por estar diretamente vinculado aos negócios da empresa, o projeto exige não apenas o trabalho da equipe técnica, mas também a interação constante da área executiva, pois qualquer desvio ou mau entendimento na execução dos vários processos que envolvem um projeto de BI pode causar graves prejuízos ao levar a empresa a consultar informações não confiáveis e, conseqüentemente, a tomar decisões erradas. 2.4. Construindo um Data Warehouse Antes de qualquer coisa, vamos analisar a arquitetura de um DW, suas características e minúcias. Desta forma poderemos entender melhor as etapas operacionais que serão apresentas posteriormente nesta obra.


27


2.4.1. Arquitetura de um Data Warehouse Podemos definir basicamente duas formas de apresentação da arquitetura de um DW, uma conceitual e outra física do modelo relacional que representa todo o sistema. 2.4.1.1. Visão Conceitual

Metadados produzidos em todas as etapas Monitoração e Administração

Repositório de Metadados

Data Warehouse

Servidores OLAP

Fontes Externas

ETL

Análises Data Mining

BD Operacionais

Data Marts

Ferramentas

Imagem 6

O DW pode ser dividido em diversos Data Marts (DM), que departamentalizam os dados separando-os por setores dentro da organização. Nota: Os data marts serão apresentados posteriormente.

Os dados contidos nos DW e nos DMs são gerenciados por um ou mais servidores de warehouse, os quais apresentam visões multidimensionais dos dados para uma variedade de ferramentas front end. A visão multidimensional geralmente é apresentada na forma de um ou mais cubos de dados, que indicam que as informações são visualizadas em linhas e


28


colunas como o formato tradicional das planilhas, porém existem mais dimensões, sendo que o cubo teria apenas mais uma dimensão. 2.4.1.2. Visão Física (em Camadas) •

Camada de Bancos de Dados Operacionais e Fontes Externas: contém as bases de dados operacionais e podem ser compostas também de informações de fontes externas, estes dados recebem um tratamento especial para poderem ser incorporados ao DW;

Imagem 07

Camada de Acesso aos Dados: Compõe o elo de ligação entre as ferramentas de acesso à informação e os bancos de dados operacionais, comunicando-se com diversos Sistemas de Gerenciamento de Banco de Dados (SGBDs) e sistemas de arquivos, sendo que a este conjunto de características dá-se o nome de acesso universal de dados; •

Camada de Transporte ou Middleware: tem a função de gerenciar a transmissão das informações pelo ambiente de rede que serve de suporte para o sistema como um todo, separando as aplicações operacionais do formato real dos dados, realiza ainda a coleta de mensagens e transações e se encarrega de entregá-las nos locais e nos tempos determinados;


29


•

•

•

•

•

Camada do Data Warehouse: constitui-se do armazenamento físico dos dados oriundos dos sistemas operacionais da empresa e externos, permitindo um acesso mais rápido e seguro aos dados do DW, além de prover maior flexibilidade de tratamento e facilidade manipulação; Camada de Acesso à Informação: proporciona a interação com os usuários finais através de ferramentas visuais tradicionais, tais como sistemas de planilhas de cálculo, browsers, entre outras; Camada de Metadados (Dicionário de Dados): os metadados descrevem os dados e a organização do sistema, podem ser ainda fórmulas utilizadas para cálculo, descrições das tabelas disponíveis aos usuários, descrições dos campos das tabelas, permissões de acesso, informações sobre os administradores do sistema, entre outras; Camada de Gerenciamento de Processos: faz o controle destas tarefas que mantêm o sistema atualizado e consistente, gerenciando as diversas tarefas que são realizadas durante a construção e a manutenção dos componentes de um sistema de DW; Camada de Gerenciamento de Replicação: serve para selecionar, editar, resumir, combinar e carregar no DW as informações a partir das bases operacionais e das fontes externas, envolvendo programação bastante complexa, sendo que existem ferramentas poderosas que permitem que estes processos sejam gerenciados de forma mais amigável, além do controle da qualidade dos dados que serão carregados.

2.4.2. Estrutura Física dos Dados do DW A respeito da disposição física dos dados, o DW pode ter uma estrutura centralizada em um único local ou então ser implementado de forma distribuída. Se optarmos pelo primeiro modelo, o centralizado; teremos um warehouse consolidado e o Banco de Dados (BD) formará um DW integrado. Definindo o projeto desta forma pode-se maximizar o poder de processamento e acelerar os processos de busca por informações analíticas. Definindo-se uma arquitetura federativa, pode-se distribuir a informação por função, separando os dados do setor financeiro em um servidor, os dados de marketing em outro local, e dados de manufatura em um terceiro lugar. Existe ainda uma terceira metodologia, na qual se considera uma arquitetura de DW separada por camadas, armazenando os dados mais resumidos em um servidor, dispondo os dados um pouco mais detalhados, em nível de detalhe


30


intermediário, em um segundo servidor, e por fim colocamos os dados mais detalhados (atômicos) em um terceiro servidor. A imagem 8, exemplifica esta metodologia.

Volume de Consultas / Número de Usuários

Granularidade / Tamanho da Base

Camada 1

Camada 2

Camada 3

Imagem 8

O primeiro servidor geralmente atende à maior parte das consultas, sendo que teremos um menor número de pedidos de acesso solicitados para a camada 2 e camada 3. O dimensionamento dos servidores é o seguinte: na primeira camada podemos ter uma configuração para suportar um grande número de usuários que farão diversas consultas, as quais trabalharão com um volume relativamente pequeno de dados. Já os servidores das outras duas camadas devem ser configurados para permitir processar grandes volumes de dados, porém não é necessária uma preocupação em configurar o sistema para suportar o acesso de um número maior de usuários. Isto explica-se pelo fato de que a maioria dos usuários terá suas perguntas respondidas pelas consultas iniciais da camada 1. Se algum usuário não se satisfizer com o nível de detalhe das respostas da camada 1, pode buscar maiores informações na camada 2 e até mesmo na camada 3. Concluímos então que poucos usuários farão acessos regulares à última camada, sendo que alguns nunca o farão além do nível inicial. 2.4.2.1. Arquitetura de Duas Camadas Existe uma arquitetura de implantação de sistemas de DW que consiste em utilizar um computador de alta capacidade como servidor. Este método disponibiliza aplicações aos usuários finais na forma de ferramentas front end, que servem para realizar as consultas, em conjunto com os componentes do servidor com ferramentas back end, que servem para municiar o DW com informações. (11) 3531 6550 - www.strattus.com.br

31


Organizações que podem crescer com a incorporação de outras empresas do mesmo ramo ou ainda de outro ramo de negócio, gradualmente acumulam diversos sistemas de computação legados, cada um com suas incompatibilidades de definições dos dados. Esta redundância e falta de consistência dos dados dificulta a administração das bases de dados, resultando numa dificuldade também para desenvolver-se novas aplicações front end. Esta arquitetura pode ser chamada de "sistema guarda-chuva", a qual possui um formato em que o cabo do guarda-chuva representa o servidor principal e as hastes representam os sistemas de consulta a este servidor.

Imagem 9

A arquitetura ilustrada na imagem 9 pode ser usada para construir um sistema de DW em duas camadas, o qual possui os componentes dos clientes (front end) e os componentes do servidor (back end). Esta arquitetura é bastante conveniente, uma vez que utiliza os sistemas já existentes na empresa bem como os servidores de bancos de dados e requer um pequeno investimento em hardware e software. Um dos grandes problemas que existe neste tipo de arquitetura é o fato de não ser permitido o seu escalonamento, o que resulta, com o aumento do número de usuários, num desempenho ruim pelo gargalo existente entre os clientes e o servidor. Estas anomalias podem ocorrer pelo uso de estações clientes muito lentas e com muitos processos rodando simultaneamente.


32


2.4.2.2. Arquitetura de Três Camadas Para tentar solucionar os problemas de desempenho resultantes do gargalo da arquitetura de duas camadas, existe uma arquitetura de informação em múltiplas camadas, como mostrado na imagem 10. Esta arquitetura é bastante flexível e suporta um grande número de serviços integrados, onde a interface do usuário (ferramentas front end), as funções de processamento do negócio e as funções de gerenciamento do BD são separadas em processos, os quais podem ser distribuídos através da arquitetura de informação. Este tipo de arquitetura em três camadas é bastante utilizado. Na primeira camada ficam as aplicações de interface com os usuários, que devem ser gráficas e baseadas em rede. Dados e regras de negócio podem ser compartilhados pela organização, assim como o BD para o DW, ficam armazenados em servidores de alta velocidade na segunda camada, a camada central. Na terceira e última camada estão localizadas as fontes de dados. Analisando o ambiente do DW, os servidores de BD e os servidores de aplicações da camada central provêem um acesso eficiente e rápido aos dados compartilhados. Com a separação dos servidores em transacional e analítico pode-se obter uma boa performance nas consultas e no processamento, sendo que deve haver disponibilidade de equipamentos e recursos satisfatórios de conexão entre os diversos componentes do sistema.

Imagem 10


33


2.4.3. OLTP versus OLAP Os termos OLTP (on-line transaction processing – processamento on-line de transações) e OLAP (on-line analytical processing – processamento analítico online) descrevem o modo de processamento de cada uma das componentes da divisão proposta para os sistemas de Bancos de Dados. Bancos de dados operacionais atingem proporções de centenas de megabytes e até mesmo gigabytes. Consistência e capacidade de recuperação de dados são críticas, e a maximização do poder de processar transações é requerida para minimizar os problemas que podem ser causados pela concorrência de processos. Analisando sistemas OLAP, sistemas que dão apoio à decisão, pode-se notar o contraste com OLTP. No caso do processamento analítico deve-se dar maior importância aos dados históricos, totalizados e consolidados em detrimento dos dados detalhados ou individualizados. Uma vez que os DW contêm dados referentes a longos períodos de tempo, estes podem atingir dimensões muito maiores do que os bancos de dados operacionais, chegando a conter centenas de gigabytes e até mesmo terabytes de informações. A tabela 1 ilustra as diversidades apresentadas pelos dois tipos de sistemas, DW e Bancos de Dados Operacionais: Tabela 1: Diferenças entre os tipos de sistemas. s istemas. Características

DBs Operacionais

DW

Objetivo

Operações diárias do negócio

Analisar o negócio

Uso

Operacional

Informativo

Tipo de processamento

OLTP

OLAP

Unidade de trabalho

Inclusão, alteração, exclusão

Carga e consulta

Número de usuários

Milhares

Centenas

Tipo de usuário

Operadores

Comunidade gerencial

Interação do usuário

Somente pré-definida

Pré-definida e ad-hoc

Condições dos dados

Dados operacionais

Dados Analíticos

Volume

Megabytes – gigabytes

Gigabytes – terabytes

Histórico

60 a 90 dias

5 a 10 anos


34


Granularidade

Detalhados

Detalhados e resumidos

Redundância

Não ocorre

Ocorre

Características

BDs operacionais

DW

Estrutura

Estática

Variável

Manutenção desejada

Mínima

Constante

Acesso a registros

Dezenas

Milhares

Atualização

Contínua (tempo real)

Periódica (em batch)

Integridade

Transação

A cada atualização

Número de índices

Poucos/simples

Muitos/complexos

Intenção dos índices

Localizar um registro

Aperfeiçoar consultas

2.4.4. Projeto e Desenvolvimento de Sistemas de Data Warehouse A maioria dos autores sobre o assunto costuma dizer que o projeto de sistemas de DW é muito cansativo e penoso. Analisando pelo ângulo das gerências administrativas, muitas vezes pode-se imaginar que, uma vez que a base de dados transacional já está em funcionamento, torna-se automática a implantação de sistemas de análise e suporte à decisão. Muitas vezes é necessária uma completa reavaliação dos sistemas transacionais para que só então seja possível modelar um projeto de DW. De certa forma os projetos de sistemas de apoio à tomada de decisão não fogem ao modo tradicional de se implementar e implantar sistemas de informação. Deve ser feita uma análise do sistema como um todo utilizando-se inclusive da realização de diversas reuniões com os gerentes, funcionários e outros colaboradores envolvidos no tema. Os projetos de DMs devem ser inicialmente simples e úteis para que possam atingir seus objetivos de forma rápida e clara. Não é desejável para uma empresa investir uma quantia em dinheiro e tempo de seus funcionários em um projeto que pode levar meses para ser concluído e que durante o processo de implantação possa terminar por gerar controvérsias e até mesmo problemas probl emas para os setores. Após a conclusão de um projeto inicial bem implantado, com certeza surgirão outros projetos a partir de novas idéias dos próprios usuários, e também dos projetistas, em função da experiência adquirida durante o projeto do sistema inicial.


35


2.4.4.1. Funções dos Componentes da Equipe O projeto e a posterior manutenção e utilização de sistemas de DW requerem o empenho de profissionais capacitados e com conhecimentos avançados em diversas áreas. Além disto, poderão ser definidas várias v árias funções para os usuários. De acordo com o tamanho do projeto e o tipo de tecnologia utilizada, podem ser necessárias várias pessoas para realizar as diferentes funções. Nota-se também que algumas das funções da tabela 2 são necessárias apenas durante a fase de projeto do DW. Algumas funções podem variar conforme o estágio em que se encontra o projeto, assim como podem ser agrupadas para que uma só pessoa realize várias delas ao mesmo tempo. Tabela 2: Funções dos componentes da equipe de um DW. Funções

Responsabilidades

Gerente do Data Warehouse

Define as estratégias pertinentes ao Data Warehouse; Planeja e gerencia o DW; Comunica os objetivos do DW para a equipe de desenvolvimento.

Arquiteto de Dados (Modelador)

Desenvolve o modelo de dados Analisa as exigências de dados Desenha as estruturas dos dados Define as visões gerenciais para os dados

Administrador

(Modelador)

de

Metadados Define os padrões de metadados

Gerencia o repositório dos metadados

Administrador do BD (DBA)

Cria as estruturas físicas no BD Monitora o carregamento dos dados e a performance das consultas

Usuário de nível gerencial

Descreve os dados necessários Especifica as regras de negócio Testa os resultados das transformações dos dados

Analista de processos e aplicações

Desenvolve as aplicações de suporte à decisão

Especialista em Aplicações Operacionais (DBA/Analista Sistemas)

Indica onde estão os dados nos sistemas transacionais

(Funcional)

Analista e programador conversões (ETL/DBA)

de Indica as fontes de dados para o DW

Desenvolve os programas para selecionar e carregar os dados

Especialista em suporte técnico Desenvolve as atividades técnicas como instalar e

(infra-estrutura)

configurar máquinas

Instrutor

Treina os usuários para acessar o DW


36


2.4.4.2. Analise entre Model. Dimensional e Model. Relacional Um modelo entidade-relacionamento nem sempre é indicado para a construção de bancos de dados de apoio à decisão, os chamados DSS (Decision Suport Systems). Este tipo de modelagem é bastante apropriado para ser aplicado no desenvolvimento de sistemas transacionais em ambientes relacionais. Na atualidade, a forma mais utilizada pelos projetistas para armazenar grandes quantidades de dados é feita em bancos de dados relacionais, uma vez que sua estrutura de dados é bastante propícia para solucionar problemas de espaço em disco e também de desempenho. A questão fundamental é que as novas tecnologias de consulta e análise de dados requer recursos que a modelagem relacional não pode oferecer. É sugerido por vários autores do tema BI, a utilização de técnicas diferenciadas denominadas Modelagem Dimensional (MD), as quais estruturam os dados de forma diferente daquela definida pelos sistemas relacionais, possibilitando que todas as consultas sejam melhoradas. Não existem segredos para que se converta um modelo ER em um modelo dimensional. O gerenciador de banco de dados utilizado no MD é bastante diferente do tradicional que gerencia modelos ER, sendo que no primeiro são facilitadas a navegação e as consultas. O número de tabelas é reduzido pelo fato de existirem dimensões ligadas a uma tabela de fatos central, logo o gerenciador pode trabalhar com um número menor de chaves. A teoria de bancos de dados relacionais sugere aos desenvolvedores que procurem eliminar as redundâncias dos dados através da modelagem ER e normalizações. As tabelas definidas são relacionadas através de chaves e utilizase estas tabelas normalizadas para reduzir o número de atualizações necessárias nesta base. O grande problema dos modelos ER é que o número de tabelas inconsistentes é grande. Qualquer pessoa que tenha projetado um sistema de informação que controle um processo dentro de uma empresa de porte médio deve possuir pelo menos um grande mapa desenhado com as entidades relacionadas entre si. Podem existem nele centenas de tabelas interligadas por centenas de relacionamentos. Este modelo pode ser visto pelos olhos do projetista e das pessoas ligadas à tecnologia de banco de dados como um modelo consistente e bem arranjado, o qual supre as necessidades de consistência e desempenho das transações que são realizadas em grandes quantidades a todo o momento. Porém, sob a ótica do usuário final, este modelo arquitetado é dificílimo, para não dizer impossível, de ser entendido. (11) 3531 6550 - www.strattus.com.br www.strattus.com.br

37


Já um modelo dimensional nos parece diferente. Um modelo estrela organiza de forma mais simplificada o processo como um todo, reduzindo a amplitude dos fatos desejados e trazendo as questões importantes para o foco. Por exemplo, na Imagem 11 é apresentado um modelo dimensional de um processo empresarial típico: um caixa registrador de vendas em uma cadeia de varejo. Normalmente se chama este tipo de diagrama de Diagrama Estrela. Observe que na tabela central, a tabela de fatos, estão colocadas chaves para as dimensões e alguns atributos que representam medidas numéricas do negócio. Esta tabela é tradicionalmente a maior em número de registros.

Imagem 11

Sistemas de DW podem ter várias tabelas de fatos, cada uma representando um processo diferente dentro da empresa, constituindo os DMs, que podem ser ligados uns aos outros dependendo da necessidade e também da possibilidade de que isto aconteça. As tabelas de fatos são ligadas através de relacionamento a diversas tabelas de dimensões utilizando chaves. Estas tabelas são muito menores em tamanho e número de registros do que a tabela de fatos a que são ligadas. Cada tabela de dimensão tem uma única chave e os campos destas tabelas são tipicamente textuais e utilizados como fontes para compor os cabeçalhos de relatórios. Um esquema estrela como o da imagem 11 se baseia em dois tipos de consultas (queries): browse e join multitabelas. A query browse é definida para ser aplicada em uma tabela apenas, sem que seja necessário utilizar comandos join. Um exemplo deste tipo de consulta ocorre quando um usuário abre um menu pull-down de toda a lista de itens de uma tabela que representa uma dimensão do modelo estrela a fim de consultar seus atributos.


38


Normalmente os dados resultantes desta consulta serão apresentados de forma automática, uma vez que, teoricamente, tudo o que se quer já está na tela. As consultas com joins multitabelas são precedidas por uma série de browses que fazem uso da estrutura do modelo estrela através de diversas uniões entre a tabela de fatos e as dimensões. Dificilmente este tipo de consulta será atendido rapidamente, uma vez que são localizadas centenas ou até milhares de registros de tabelas subjacentes para darem uma resposta resumida para o usuário. A modelagem dimensional é um processo top-down. Primeiro são identificados os processos empresariais que serão a base para a criação das tabelas de fatos, tabelas estas que serão povoadas como os dados numéricos destes fatos. A modelagem ER habitual possui grande parte de seu conjunto formado pelas tabelas de dimensão e por técnicas de normalização. Se as tabelas de dimensão forem normalizadas em estruturas de "floco de neve", onde estas dimensões são compostas de mais de uma tabela, podem surgir dois problemas. Primeiro, o modelo de dados fica bastante complexo para ser apresentado aos usuários. Segundo, a união entre as diversas partes do floco de neve irá comprometer o desempenho do sistema como um todo. O desempenho durante a fase de atualização das tabelas raramente é importante em sistemas de apoio à decisão, uma vez que esta operação é feita, como já foi dito neste trabalho, durante a noite ou em momentos em que não se esteja utilizando os sistemas da empresa a pleno vapor. Mesmo assim, alguns projetistas utilizam o argumento de melhorar este desempenho para justificarem a necessidade de normalizar as dimensões. Um projeto de banco de dados dimensional tem uma estrutura fixa onde não há nenhum caminho alternativo. Isto simplifica grandemente a otimização e a avaliação de questões nestes esquemas. Deve ser construída uma longa lista ordenada de chaves compostas para a tabela de fatos. A seguir, repassar a tabela de fatos compondo um índice por vez. Analise de perto como seu gerenciador de banco de dados tenta processar uma consulta em um esquema estrela. Se o plano de avaliação de consulta tem a tabela de fatos em parte semelhante ao modo abaixo a lista com as tabelas de dimensão mencionadas depois disto, seu DBMS não sabe como fazer joins do tipo estrela. Quando a tabela de fatos é só parte da lista abaixo, o DBMS está gravando um subconjunto da tabela de fatos no disco. O DBMS está testando então individualmente os registros resultantes contra as tabelas de dimensão restantes e o resultado é uma query que roda muito lentamente. Uma diferença final um pouco controversa entre o modelo ER e a MD é o grau de julgamento deixado nas mãos do projetista. A essência de um bom modelo dimensional é a escolha do conjunto da maioria das dimensões naturais da perspectiva de um usuário final. Sempre há duas ou mais alternativas que


39


representam os dados da mesma maneira, mas empacotam as dimensões diferentemente. Em última instância, o julgamento do projetista deve prevalecer. É útil ter uma análise de ER antes de embarcar em um projeto dimensional porque a equipe de DW entenderá melhor os dados desta forma. Porém, a equipe tem que fixar aparte o diagrama ER durante o processo de projeto do DW porque a modelagem dimensional tem que proceder de uma perspectiva de usuário, em lugar de uma perspectiva de dados. Se não existir uma análise de ER, não é recomendável despender um bom tempo para fazer isto com a finalidade de construir um banco de dados de DW. Os últimos três quartos do tempo de uma análise de ER são para a redução da redundância - especialmente fora das tabelas de dimensão que não beneficiam o projeto dimensional. 2.4.4.3. Problemas encontrados no Desenvolvimento de Data Warehouses Existem diversos problemas que podem ocorrer durante o desenvolvimento de um sistema de DW. Dentre estes problemas, os mais comuns são: a) Não envolver a alta direção da empresa no projeto: Conforme já foi dito em seções anteriores, o projeto de um DW só terá sucesso se os futuros usuários se envolverem diretamente desde o início nas atividades, pois isto facilitará a destinação das verbas necessárias nos momentos oportunos além de direcionar os trabalhos para que os reais objetivos do DW para o negócio da empresa sejam alcançados no momento da implantação; a) Gerar falsas expectativas com promessas que não poderão ser cumpridas: citar frases do tipo "O DW mostrará aos gerentes as melhores decisões" pode causar tanto desconfiança no projeto quanto desprezo; b) O DW não mostrará as melhores decisões, mas sim respostas às consultas efetuadas. Cabe aos usuários elaborar consultas inteligentes e analisar as respostas obtidas; c) Carregar no DW informações somente porque elas estão disponíveis nos sistemas transacionais: Nem todos os dados disponíveis nos sistemas operacionais da empresa são necessariamente úteis para o DW. Cabe ao arquiteto dos dados analisar junto com os usuários quais os dados que realmente contêm informações necessárias e desprezar aqueles que não fazem parte dos objetivos do DW; d) Imaginar que o projeto do banco de dados do DW é o mesmo que o projeto de um sistema transacional: num processo transacional devem ser dimensionados os recursos para que se atinja uma alta velocidade de acesso e grandes facilidades na atualização de registros. Nos sistemas de apoio à decisão a realidade é totalmente outra. O objetivo destes sistemas é fornecer acessos (11) 3531 6550 - www.strattus.com.br

40


agregados, ou seja, somas, médias, tendências, etc. Outra diferença entre os dois tipos de sistemas pode ser detectado no tipo de usuários. Nos sistemas transacionais um programador desenvolve uma consulta que poderá ser utilizada milhares de vezes. No DW o usuário final desenvolve suas próprias consultas que podem ser utilizadas somente uma vez; e) Na seleção do pessoal, escolher um gerente para o DW com orientação essencialmente técnica: os sistemas de apoio à decisão são na verdade uma prestação de serviços e não um serviço de armazenamento de dados. Por isso, é fundamental que o gerente do DW seja uma pessoa voltada aos interesses dos usuários e principalmente que, saiba dos termos utilizados diariamente pelos altos gerentes e outros tomadores de decisões. f) Dedicar-se ao tratamento de dados do tipo registros numéricos e string: Muitos poderiam imaginar que as informações que serão utilizadas em um DW seriam oriundas especificamente dos registros das bases de dados transacionais, e que estas informações seriam apenas números ou palavras. Quem pensa desta forma pode estar enganado, pois textos, imagens, sons e vídeos podem ser bastante úteis no momento da análise de determinadas situações da empresa e do negócio; g) Projetar um sistema com base em um hardware que não poderá comportar o crescimento da demanda do DW: A capacidade dos servidores está em constante crescimento, porém pode ser dimensionando um ou mais equipamentos para trabalharem por um ou dois anos, mas as características destes sistemas indicam que a quantidade de informações armazenadas pode atingir até mesmo alguns Terabytes. É importante que o servidor do banco de dados do DW seja fornecido por uma empresa confiável e que garanta a possibilidade de serem realizadas expansões a valores e prazos compatíveis com os de mercado; h) Imaginar que após a implantação do DW os problemas estarão terminados: Muito esforço deve ser despendido para que um sistema de DW saia da prancheta. Porém, após a sua implantação os usuários começarão a criar mais e mais consultas, e estas consultas necessitarão de novos dados que resultarão em novas consultas. Desta forma, o projeto de um sistema de apoio à decisão precisa ser revisado e atualizado constantemente, não apenas com novos dados, mas também com novas tecnologias. 2.4.5. Melhorando a performance do Data Warehouse O desempenho dos sistemas de DW deve ser sempre considerado como um dos fatores críticos para o sucesso do projeto, uma vez que serão manipuladas grandes quantidades de informação por um número razoável de usuários. Podem ser aplicadas algumas técnicas durante o projeto e o desenvolvimento de um DW na tentativa de melhorar seu desempenho para o usuário final. (11) 3531 6550 - www.strattus.com.br

41


Algumas destas técnicas já são utilizadas nos projetos de sistemas transacionais e outras são mais específicas para utilizar nos sistemas de apoio à decisão. 2.4.5.1. Intercalação de Tabelas Nesta técnica o projetista do DW intercala as tabelas relacionadas entre si em um mesmo local físico. Este procedimento diminui a carga de operações de entrada e saída (E/S), tanto em função do acesso aos dados, como em função do acesso aos índices para a localização destes dados. Tentando prever, mesmo que superficialmente, quais consultas serão feitas pelos usuários, pode-se agrupar ou desagrupar as diversas tabelas do sistema. 2.4.5.2. Introdução de Informações Redundantes Aplicada essencialmente em ambientes de apoio à decisão, esta técnica consiste na introdução deliberada de dados redundantes, os quais proporcionam um excelente incremento de desempenho. Na parte superior da imagem 12 está o campo denominado descrição, o qual está normalizado e sem redundância. Sendo assim, os processos que necessitarem da descrição, deverão acessar a tabela básica para obter tal informação. Na parte inferior da imagem o campo denominado descrição foi colocado propositadamente nas outras tabelas, mesmo que seja uma informação totalmente redundante, pois isto irá permitir ao sistema que encontre estas informações sem que seja necessário acessar a tabela original de produtos. Como se pode notar, o problema da replicação dos dados reside no fato de que as informações irão ocupar mais espaço para o armazenamento, uma vez que são gravadas diversas vezes as descrições dos produtos, além de tornar a manutenção do sistema mais trabalhosa, uma vez que não basta atualizar apenas a tabela de produtos no item descrição para propagar esta informação pelo sistema, como se costuma fazer nos bancos de dados relacionais. De qualquer maneira, como os sistemas de DW têm a característica de sofrerem poucas atualizações e em contrapartida fazerem uso de muitos acessos às bases devido às consultas ad hoc dos usuários finais, esta estratégia é interessante pelo fato de que o acréscimo de desempenho é bastante considerável.


42


Produtos Código Descrição Unidade

Atualização

Produtos Código Descrição Unidade ...

Atualização

Produção Código ...

Estoque Código ...

Acesso

Produção Código Descrição ...

Acesso

Estoque Código Descrição ...

Acesso

Acesso

Gerencia Código ...

Acesso

Gerencia Código Descrição ...

Acesso

Imagem 12

2.4.5.3. Separação de Dados Quando existirem informações em uma tabela da base transacional na qual o número provável de acessos pode ser diferente dependendo do item desejado, há a opção de separar aquela tabela em duas ou mais partes. Esta técnica serve para aumentar a velocidade de acesso aos dados e é denominada "separação de dados". Por exemplo, a data da inclusão de um produto no sistema pode ser importante para determinados usuários que desejem analisar os dados sob uma perspectiva específica, porém na maioria das vezes para as consultas dos usuários esta informação não será solicitada. A tabela, portanto, pode ser dividida em duas: uma contendo as informações com um número mais alto de possibilidades de acesso, e outra com as informações que possuem uma probabilidade mais baixa.


43


Imagem 13

Construindo uma arquitetura deste tipo dá-se preferência àqueles usuários que consultam informações mais corriqueiras, os quais obterão respostas mais rapidamente do que aqueles que realizam perguntas sofisticadas e que são realizadas esporadicamente. A decisão de privilegiar este ou aquele tipo de consulta é bastante importante para que futuras solicitações ao sistema não gerem consultas tão complexas que o sistema de apoio à decisão tenha que realizar um grande processamento de dados para poder dar uma resposta ao usuário. 2.4.6. Componentes dos Sistemas de DW No final do ano de 1991 a IBM definiu um sistema chamado Information Warehouse Framework (IW), como sendo um "conjunto de sistemas de gerência de banco de dados, interfaces, ferramentas e facilidades que gerenciam e distribuem informações confiáveis, oportunas, corretas e compreensíveis sobre o negócio para pessoas autorizadas a tomar decisões". Este sistema consiste de três componentes mais importantes, que são: o enterprise data, o data dellivery e o decision support. O primeiro, enterprise data, compõe a parte central do warehouse, com SGBDs que cuidam para que a integridade dos dados seja mantida, dando suporte à segurança destes dados, permitindo a sua recuperação, se necessário, além de manter a total disponibilidade destes dados a todos que necessitem realizar consultas. O desempenho do sistema também é conseqüência da atuação deste módulo. (11) 3531 6550 - www.strattus.com.br

44


O segundo, data delivery, é utilizado para recuperar os dados que se encontram nas fontes internas da empresa, independentemente do local ou servidor onde se encontrem. Estão disponíveis ainda neste componente serviços de transferência, transformação e enriquecimento de dados, sendo ainda controladas as cópias dos dados também pelo data delivery. No terceiro e último componente, o decision support, é permitido que os tomadores de decisão manipulem adequadamente as informações e transformem os dados brutos em conhecimento útil para a empresa. Para tal, devem ser aplicadas técnicas contidas em ferramentas que permitam selecionar, manipular e apresentar os dados nos mais diversos formatos (planilhas, gráficos, etc). Este sistema definido pela IBM serviu como referencial para que a arquitetura de sistemas de DW fosse mais bem entendida pelos estudiosos do assunto. É claro que estas ferramentas, na atualidade, podem ser consideradas rudimentares e por isso foram aperfeiçoadas e adaptadas cada vez mais às novas tecnologias oferecidas pelas empresas fabricantes de Bancos de Dados. A implementação de um sistema de DW faz uso constante de ferramentas que realizam tarefas definidas. Temos a seguir uma lista dos componentes destes sistemas: • • •

•

•

•

Fontes de dados do DW; Um conjunto de estruturas de dados analíticos (o DW); Um sistema de gerência de banco de dados (SGBD) configurado especialmente para atender aos requisitos analíticos dos sistemas de DWs; Um componente back end: faz a extração, limpeza, transformação, integração e carga dos dados das diferentes origens (fontes); Um componente front end: Disponibiliza aos usuários finais o acesso aos dados do DW; Um repositório para armazenar e gerenciar os metadados.

A imagem 14 demonstra o relacionamento entre estes componentes.


45


Imagem 14

2.4.6.1. O Sistema Gerenciador de Banco de Dados O sistema de gerência de BD tem como uma das principais funções prover acesso e manipulação eficientes aos dados armazenados através de uma linguagem de alto nível. Deve ainda o SGBD possuir um sistema de proteção contra acessos não autorizados além de manter a consistência e a integridade destes dados. No caso dos sistemas de DW os SGBDs devem possuir ferramentas que dêem suporte a OLAP, que, conforme já mencionamos, difere de OLTP em uma série de requisitos. Os SGBDs direcionados ao processamento de transações são normalmente dimensionados para atender a um grande número usuários que realizam operações atômicas (transações). No caso de um DW, o gerenciador deve ser configurado para que os poucos usuários que fazem uso destes dados possam realizar um grande número de consultas ad hoc (definidas no momento da execução) ou pré-definidas, todas bastante complexas e poderosas. Para que isto seja possível, existem ferramentas que envolvem tecnologias complexas a fim de permitir que o usuário obtenha dados resumidos utilizando técnicas de aperfeiçoamento e combinação de métodos de indexação, os dados são armazenados em sistemas multidimensionais e consultados por extensões do SQL padrão.


46


Pode-se implementar sistemas de DW em SGBDs relacionais embora já existam gerenciadores especializados em atender às necessidades dos sistemas de apoio à decisão, os chamados SGBDMs, ou sistemas de gerência de BD multidimensionais, chamados também de servidores MOLAP, que armazenam os dados em matrizes ou arrays ao invés de tratar os dados em registros de tabelas relacionadas entre si. Pelo fato de utilizarem esta tecnologia, suas dimensões ainda não atingem o tamanho necessário para grandes DWs por limitações técnicas tanto de software quanto de hardware o que acaba reduzindo o uso destes sistemas apenas em sistemas de DM. 2.5. O Ciclo de vida do desenvolvimento de um Data Warehouse Não disponível 2.6. Considerações Iniciais para a criação de um Data Warehouse Nosso ponta pé inicial consiste basicamente na extração dos dados das fontes de dados internas, incluindo a transformação e a limpeza (racionalização) dos dados. Deve-se observar a exigência de padronização dos dados, geralmente distribuídos de formas distintas pelos departamentos das empresas. Um dos itens mais importantes é o repositório dos metadados, responsável pela documentação de cada registro realizado na base de dados. Os metadados vão proporcionar a segurança sobre a qualidade das informações obtidas (Como veremos mais adiante nesta obra) Para que o projeto do DW obtenha sucesso é necessário escolher corretamente a estratégia a ser adotada, esta estratégia deve ser adequada às características e necessidades específicas do ambiente onde o DW será implementado. Existem várias abordagens que podem ser utilizadas para o desenvolvimento de um DW, mas é importante fazer uma escolha fundamentada em pelo menos quatro dimensões: escopo do DW, grau de redundância de dados e tipo de usuário final, etc. O escopo de um DW pode ser tão amplo quanto aquele que inclui todo o conjunto de informações de uma organização ou tão restrito quanto um DW pessoal definido para um único gerente. Quanto maior o escopo, maior o valor do DW e por conseqüência mais cara e trabalhosa será sua criação e manutenção. Por isso, muitas empresas tendem a iniciar com a construção de Data Marts e só após obter um retorno de seus usuários, iniciam a expansão do escopo, integrando os Data Marts em um único DW. (11) 3531 6550 - www.strattus.com.br

47


Nota: Veremos os Data Marts mais adiante no capitulo de modelagem dimensional.

Quanto à redundância de dados, há essencialmente três níveis de redundância: •

•

DW virtual: Consiste em simplesmente prover os usuários finais com facilidades adequadas para extração das informações diretamente dos bancos de produção, não havendo assim redundância, mas podendo sobrecarregar o ambiente operacional; DW centralizado: Constitui-se em um único banco de dados físico contendo

todos os dados para uma área funcional específica, um departamento ou uma empresa, sendo usado onde existe uma necessidade comum de informações. O DW central normalmente contém dados oriundos de diversos bancos relacional-operacionais, devendo ser carregado e mantido em intervalos regulares; •

DW distribuído: P seus componentes distribuídos em diferentes bancos de

dados físicos, normalmente possuindo um grau de redundância alto e por conseqüência, procedimentos mais complexos de carga e manutenção.

Outro fator importante na escolha da abordagem de desenvolvimento é o padrão de uso do DW . Relatórios e consultas pré-estruturadas podem satisfazer o usuário final, e geram pouca demanda sobre o SGBD e sobre o servidor. Análises complexas, por sua vez, típicas de ambientes de suporte à decisão, exigem mais de todo o ambiente. Ambientes dinâmicos, com necessidades em constante mudança, são mais bem atendidos por uma arquitetura simples e de fácil alteração, como as estruturas altamente normalizadas, ao invés de uma estrutura mais complexa que necessite de reconstrução a cada mudança, por exemplo, estrutura multidimensional. O DW deve ser construído de forma interativa, isto é, não é possível definir antecipadamente todos os requisitos necessários à sua construção até que ele esteja parcialmente povoado e sendo utilizado pelos analistas de SAD . Portanto ele não pode ser projetado da mesma forma como são construídos os sistemas baseados em requisitos. Por outro lado é um erro grave pensar que não é necessário prever alguns requisitos iniciais. É necessário encontrar um meio termo entre estes dois conceitos. Por ser projetado e carregado passo a passo, é dito que ele segue uma abordagem evolucionária.


48


W. Inmon indica algumas das muitas razões que mostram a importância do desenvolvimento seguir a abordagem evolucionária: •

•

•

•

Histórico de sucesso das aplicações sugere estatisticamente tal método; Usuário final não terá condições de expressar suas necessidades com clareza até que a primeira interação seja feita; A gerência não se comprometerá por completo até que verdadeiros resultados tangíveis e claros sejam apresentados; Há necessidade de, rapidamente, obter resultados visíveis.

Muitas empresas iniciam o processo a partir de uma área específica, que normalmente é uma área carente de informação e cujo trabalho seja relevante para os negócios da empresa, criando Data Marts, para depois ir crescendo aos poucos, seguindo uma estratégia botton-up ou assunto-por-assunto. Outra alternativa é selecionar um grupo de usuários, prover ferramentas adequadas, construir um protótipo do DW e deixar que os usuários analisem minuciosamente as amostras dos dados. Somente após a concordância do grupo quanto aos requisitos e funcionamento, é que o DW será de fato carregado com dados dos sistemas operacionais na empresa e dados externos. O modelo de processos deve ser bem analisado antes do início do projeto pois ele é formado tipicamente por diagramas de contexto de nível zero, diagramas de fluxo de dados, diagramas de estrutura e outras estruturas baseadas em requisitos. Em muitos ambientes o modelo de processos pode ser fundamental para o desenvolvimento de sistemas, no entanto, na construção de um DW o modelo de processos pode ser um empecilho, pois ele pressupõe a existência de um conjunto de necessidades conhecidas antes que os detalhes do projeto sejam definidos. 2.7. Dados Operacionais Seria a glorias das glorias se a criação do DW consistisse em apenas extrair dados operacionais e inseri-los no Data Warehouse. Nada poderia estar mais longe da verdade. Um DW é construído a partir de informações provenientes de várias aplicações operacionais com dados não integrados entre si. Quando estas aplicações já existentes foram criadas não foi considerada a possibilidade de uma integração futura. Cada aplicação possui seu conjunto único e particular de requisitos e, durante o processo de desenvolvimento, as outras aplicações não eram levadas em conta.


49


Não é difícil encontrar em sistemas de uma mesma empresa dados rotulados da mesma maneira em locais diferentes, mas que contenham as mesmas informações ou alguns dados que apresentem as mesmas nomenclaturas e as mesmas informações, contudo, com unidades de medidas diferentes. A questão da configuração dos extratores (ETLs) ou mesmo da programação de extratores "personalizados" para os sistemas da empresas que não são integrados pode se tornar uma tarefa muito complexa. A imagem 15 demonstra a falta de integração comum ao ambiente dos sistemas existentes.

Imagem 15 Veja mais um exemplo de integração: Um campo que tenha o objetivo de armazenar a informação distância. Ele pode ser definido de várias maneiras. Além de poder ter qualquer titulo como rótulo ele também pode utilizar unidades de medidas distintas como metros, quilômetros ou centímetros. Não existe uma preocupação específica com o modo como o caminho será medido do DW , contanto que ele seja medido de forma coerente. A imagem16 apresenta o processo de integração dos dados que tem o mesmo significado, mas que possuem representações diferentes.

Imagem 16


50


Este exemplo apenas dá uma idéia da questão da integração e por si só não é complexo. Mas quando ele se multiplica pelos milhares de arquivos e sistemas existentes, a questão da integração se torna extremamente complexa e dispendiosa. Outro importante problema da passagem de dados do ambiente operacional para o ambiente do DW diz respeito ao acesso eficiente aos dados dos sistemas existentes, não é simples definir um método que indique para os programas que estão varrendo as bases de dados operacionais se um arquivo já foi ou não varrido anteriormente. Há uma enorme quantidade de dados no ambiente de sistemas existentes e a tentativa de efetuar varreduras completas toda vez que é feita uma varredura para o DW é extremamente onerosa e sem duvida alguma muito mais demorada. Para carregar e transformar os dados provindos de sistemas operacionais, é necessário um esforço de processamento muito grande (regras de ETL), por isso estes processos são realizados normalmente a noite, deixando os dados disponíveis para o dia seguinte. Quando os dados são transferidos para o DW a sua característica de não volatilidade faz com que os dados que são manipulados no ambiente operacional assumam a situação de definitivos não podendo mais sofrer alterações. Outra informação importante é que muitos dados do ambiente operacional não passam para o DW, pois o processo de carga efetua uma filtragem nos mesmos, impedindo que dados redundantes ou sem valor para analise façam parte do sistema. No geral há três tipos de cargas que podem ser feitas do ambiente operacional para o dimensional (DW): •

Dados históricos: O carregamento dos dados históricos do sistema operacional para posterior descarregamento no DW não é uma boa

maneira de acessar os dados dos sistemas existentes, pois além de sobrecarregar os sistemas on-line (transações) também pode acessar informações que já foram carregadas para o ambiente de DW ; •

Dados de valor corrente : O carregamento de dados de valor corrente no

ambiente operacional é feito através da criação de um ou mais arquivos seqüenciais com os valores atuais do sistema operacional. Este arquivo posteriormente será processado e descarregado no DW o que não ocasionará danos ao ambiente on-line;


51


•

Alterações: O carregamento de alterações do DW a partir de atualizações

que tenham ocorrido no ambiente operacional desde a última atualização do DW consiste no maior desafio ao arquiteto de dados. Não é fácil realizar o rastreamento eficiente e o tratamento das alterações que estão sendo efetuadas sobre o ambiente operacional sem sobrecarregá-lo.


52


Capítulo 3 – Modelagem Dimensional 3.01. Introdução A visão multidimensional de dados não é algo tão novo assim, pois a necessidade de se obter de maneira rápida e simples, todo um histórico de informação de nossos ambientes operacionais, faz com que as empresas busquem cada vez mais, alternativas para organizar e acessar seus dados. 3.02. Modelagem de dados A modelagem de dados é um modo eficiente de entender os dados. O seu propósito é prover um registro apurado de aspectos do mundo real para um contexto especifico. Através da modelagem, o desenvolvedor do banco de dados pode eliminar redundâncias, que representam algumas das fontes de informações inconsistentes e que podem levar a construção de sistemas de tomadas de decisão ineficientes. Um modelo de dados é uma coleção de conceitos que podem ser utilizados para descrever um conjunto de dados e as operações para a sua manipulação. (BATINE, CERI, NAVATHE, 1992).

A não utilização de um modelo implica em um crescimento desorganizado das aplicações e seus repositórios de dados. Desta forma as aplicações demandam altos custos, para a sua manutenção e crescimento. O modelo permite ao usuário um melhor entendimento do negócio, com a vantagem de facilitar a visualização das ocorrências e qualquer ação dentro do ambiente dimensional. Podemos ressaltar também as excepcionais vantagens de se prever os impactos de qualquer mudança sobre o ambiente operacional. O modelo representa a definição, caracterização e relacionamento dos dados em um determinado ambiente. Um dos diagramas mais empregados na modelagem de dados é o Diagrama de Entidade e Relacionamento (DER). Tradicionalmente, a modelagem de dados é empregada em três níveis no ambiente operacional. Esta modelagem se inicia por um diagrama de alto nível relacionado à área do assunto, denominado modelo conceitual, seguido por uma camada intermediária, denominada modelo lógico, até a camada do modelo físico, que representa o modo como os dados serão armazenados. Atualmente, existe uma tendência nas metodologias de desenvolvimento de DW em aplicar este tipo de modelagem.


53


Nessas metodologias, o modelo conceitual do DW seria representado pelo modelo corporativo e os modelos lógico e físico pelo esquema estrela (modelo dimensional). A seguir são apresentadas características dos modelos conceitual, lógico e físico empregados nos ambientes operacionais: 1. Modelo Conceitual: O modelo conceitual é aquele que apresenta os objetos, suas características e relacionamento como uma representação fiel ao ambiente observado. Este modelo não se preocupa com os aspectos relacionados à implementação, como por exemplo, estruturas físicas e formas de acesso de um SGBD específico (COUGO, 1997) Através deste modelo é possível criar uma descrição da realidade fácil de entender e de interpretar (BATINE, CERI, NAVATHE, 1992) . O modelo conceitual, em particular, tem sido representado através do Diagrama de Entidade/Relacionamento (DER). 2. Modelo Lógico: O modelo lógico é aquele onde os objetos, suas características e relacionamentos apresentam uma representação de acordo com as regras de implementação e limitações impostas por alguma tecnologia (COUGO, 1997). Ele descreve as estruturas que comporão o banco de dados, sem considerar nenhuma característica específica de um SGBD (MACHADO, ABREU, 1996). O modelo lógico é, normalmente representado por uma estrutura relacional, hierárquica ou em rede, sendo a modelagem relacional, a mais empregada atualmente. A diferença entre o modelo conceitual e o lógico, entretanto, não é tão fácil de ser observada. Com o emprego das ferramentas CASE, o que se observa atualmente é o desenvolvimento de uma modelagem conceitual, muito próxima à modelagem relacional. O que não é incorreto, desde que o modelo conceitual se concentre em representar os conceitos e características de um dado ambiente (COUGO, 1997). Em um modelo lógico, normalmente se observa informações sobre chaves de acesso, controle de chaves duplicadas, itens de repetição, normalização e integridade. 3. Modelo Físico: O modelo físico é aquele em que a representação dos objetos é feita sob o foco do nível físico de implementação das ocorrências, ou instâncias, das entidades e seus relacionamentos. O conhecimento do modo físico de implementação das estruturas de dados é ponto básico para o domínio deste modelo (COUGO, 1997). Este modelo descreve, a partir do modelo lógico, as características físicas associadas ao armazenamento/acesso a dados, como, por exemplo, índices, métodos de acesso e distribuição física.


54


3.03. Modelagem Dimensional A modelagem dimensional representa o modo como às informações existentes em uma empresa serão modeladas e tratadas. O objetivo principal desta modelagem é a elaboração de um projeto de banco de dados consistente (DW), que permita atingir, de modo preciso, visões multidimensionais para o usuário final. O modelo final deve ser, portanto, facilmente entendido e interpretado pelos desenvolvedores e usuários finais. Qual seria então uma boa definição para modelagem dimensional? “...É uma técnica de projeto lógico que procura apresentar dados de uma forma comum, que é intuitiva para as pessoas que a acessam e que permita o acesso a informação com alto desempenho”. A modelagem dimensional e muito diferente da modelagem transacional (Entidade-Relacionamento – E/R), que procura eliminar redundâncias de forma a economizar espaço. Essa eliminação de redundâncias tem como efeito a criação de diversas entidades dentro da modelagem, o que torna mais difícil a compreensão do modelo por usuários que não tenham nível avançado. A modelagem E-R faz com que as recuperações SQL possuam “joins” mais complexos, com a união de diversas tabelas, o que torna o resultado mais demorado. Em um DW, a modelagem deve ser analisada e implementada para atender todas as necessidades do negócio. Não existe um modelo certo ou errado. O que existe é o entendimento do negócio no seu nível máximo de detalhamento, que deve ser traduzido em uma base de dados dimensional, que por sua vez, formatada e agrupada, na forma de objetos do banco de dados, possam ser armazenadas e disponibilizadas ao usuário final de forma rápida e simples. Veja abaixo os componentes do modelo dimensional: Fatos: são observações decorrentes do andar do negócio. Não são conhecidas de antemão, ou seja, não se sabe o seu valor até que se tenha acontecido. Compõe-se basicamente de campos numéricos. Ex: “quantidade de produtos vendidos”. •

Atributos do negócio: são as descrições das características do negócio. São conhecidos previamente e são caracterizados por campos textuais. Ex: nome do produto. •

Tabelas do modelo dimensional: 1. Tabelas Fato: são as tabelas que guardam os dados do negócio. Todas as informações decorrentes do andamento do negócio que não são conhecidas previamente. Os fatos podem ser aditivos, ou seja, podem ser acumulados, além de terem valores contínuos. (11) 3531 6550 - www.strattus.com.br

55


2. Tabelas Dimensão: são as tabelas que guardam os atributos do negócio. Elas podem ser usadas para restringir as pesquisas feitas nos tabelas Fato e servem como títulos em colunas. Existem várias formas de representação para os dados em ambientes de banco de dados convencionais. Podemos generalizar sem perder informações da seguinte maneira:

Datas e Horas: uma das principais características de um DW através das suas operações é poder analisar historicamente os dados. Como as possibilidades de análise são atribuídas a restrições das dimensões e possibilidade de agrupar os dados, então as datas e horas são sempre bom indício de atributos de dimensão, não de fatos. •

Textuais: os dados textuais são descrições de fácil compreensão humana, logo é natural que sejam utilizados para descrição de elementos do negócio. Como as possibilidades de análise são atribuídas a restrições das dimensões e possibilidade de agrupar os dados, então as descrições textuais são sempre bom indício de atributos de dimensão, não de fatos. •

Fatos Aditivos: são numéricos e podem ser somados em relação às dimensões existentes, pois sua semântica permite tais operações. Sempre que em uma modelagem um dado numérico for apresentado então este será um bom indício de um atributo em fatos. Em geral, fatos aditivos representam medidas de atividade do negócio. Ex. Valor Venda, Quantidade de produtos vendidos. •

Fatos Semi-Aditivos: também são numéricos, mas não podem ser somados em relação a todas as dimensões existentes, pois sua semântica não permite. Em geral, fatos semi-aditivos representam leituras medidas de intensidade do negócio. São snapshots destas leituras que entram no DW. O valor atual já leva em consideração valores passados. Ex. Nível de Estoque, Fechamento diário/mensal de conta. •

Fatos Não-Aditivos: algumas observações não são numéricas que também não são datas/horas podem eventualmente ser fatos dos eventos. Campos textuais de livre formato são ruins quer seja para dimensões ou fatos. Em geral, campos como “obs” são exemplos desta situação, pois o domínio é irrestrito. Ex. Em um DW para registrar acidentes de transito temos: carro 1, carro 2, moto 1, moto 2., hora/data, descrição do acidente, descrição do tempo (chuva,...) e descrição da pista. •


56


Aditivos

Semi-Aditivos

Não-Aditivos

Numéricos

Numéricos

Textual e Lógico

Somas

Média

Contagem

Bons Fatos

Fatos Razoáveis

Fatos Ruins

Fácil Navegação

Navegação Média

Navegação Média

3.04. Processo da Modelagem Dimensional O processo de modelagem de dados dimensional se inicia com a análise dos modelos de dados existentes no ambiente operacional (Transacional), sendo ideal a utilização do modelo de dados corporativo da empresa. Algumas empresas, porém, não possuem esses modelos para os sistemas antigos, ou mesmo apresentam o próprio modelo corporativo dividido em modelos menores, em virtude de seu porte. Para estes casos é necessário analisar os DER dos sistemas relacionados à área a ser incorporada ao DW. A análise destes modelos permitirá uma melhor base para o conhecimento do negócio e para um ágil desenvolvimento do DW. Através da análise do(s) DER é elaborado um "pré-modelo de dados" responsável pela integração entre o ambiente operativo (visão processo) e o DW (visão negócio). O(s) modelo(s) multidimensionais, que constituirão o DM, é derivado a partir deste "pré-modelo". Com a conclusão do DM, efetua-se a integração do(s) novo(s) modelo(s) ao modelo do DW. Para melhor tratar a questão de integração entre o ambiente operativo e o DW, as diretrizes do processo de modelagem foram divididas em quatro (4) fases. As seguintes fases compõem a modelagem: FASE A - Estudo dos Modelos Existentes: Esta fase é responsável por delimitar o

escopo do modelo corporativo ou dos DER relacionados aos sistemas existentes. Este escopo representa a área de interesse para a análise. Para se iniciar esta fase, as seguintes condições devem ser atendidas: • •

•

Área de interesse definida pelo usuário final; Necessidades de análise. Quando não houver uma definição formal, é necessário o levantamento dos tipos mais comuns de análises solicitadas pelo usuário final; Modelo corporativo ou DER de sistemas existentes.

FASE B - Elaboração do pré-modelo: Esta fase é a responsável por analisar e

integrar os DER dos sistemas operativos que compõem a área de interesse. Essa (11) 3531 6550 - www.strattus.com.br

57


integração é responsável pela criação de um pré-modelo. O pré-modelo se caracteriza por ser um DER não normalizado, com características peculiares. Para a realização desta fase é necessário que o projetista apresente um conhecimento razoável do negócio, que lhe permita tomar decisões com o auxílio dos usuários finais. FASE C - Modelagem do DM: Esta fase é a responsável por estabelecer um

conjunto de visões dimensionais. Após a validação das visões dimensionais, pelos usuários finais, os modelos dimensionais serão derivados, a partir do "prémodelo", empregando o esquema estrela. O modelo dimensional do DM é representado pela composição dos modelos dimensionais desenvolvidos para atender às visões dimensionais. Para a realização desta fase, o projetista deve avaliar criteriosamente as necessidades levantadas pelo usuário final e possuir o pré-modelo. FASE D - Integração do DM ao DW: Esta fase corresponde à atualização do DW,

de acordo com a construção de um novo DM. Representa o desenvolvimento incremental do DW. Como dois modelos estarão disponíveis, o pré-modelo e o modelo dimensional do DM, a atualização do DW pode ser realizada adotando a visão de Inmon ou a visão de Kimball. Esta fase apresenta também considerações sobre as mudanças estruturais usuais durante o desenvolvimento de um ADW. A modelagem dimensional independe do SGBD onde será implementada. O modelo final pode ser inserido em um SGBD relacional ou em um SGBD multidimensional. O esquema estrela é, normalmente, empregado para representar esta modelagem. Nota: Mais adiante veremos os tipos de esquemas existentes para amodelagem dimensional

A modelagem dimensional torna as operações realizadas pelas ferramentas do DW, muito mais simples, como por exemplo: •

Rollup: Permite que o usuário reduza o nível do escopo da análise. Ele

sobe o nível de detalhamento, ou seja, incrementa o nível de agregação; •

•

Drill-Down/Drill-Up: Caminho inverso do Rollup , permitindo que o usuário navegue entre os níveis de detalhamento ao analisar. Com o Drill Down você pode “subir ou descer” dentro do detalhamento do dado, como por exemplo, analisar uma informação tanto por dia como semestralmente ou ainda por ano, partindo da mesma base de dados. Slice-Dice: Seleção e projeção. Os dados no DW devem ser projetados de

modo a permitir consultas que combinem e separem as informações, através de qualquer medição possível do negócio. •

Pivot (pivoteamento): Permite que o usuário reorganize a disposição das dimensões para uma nova visão dos dados.


58


•

Visão AD HOC: Segundo Inmon “São consultas com acesso casual único e

tratamento dos dados segundo parâmetros nunca antes utilizados, geralmente executados de forma interativa e heurística”.

Observe diversas dimensões separadamente no exemplo da imagem abaixo.

Imagem 01

3.05 Processo de modelagem de um Dara Warehouse O projeto de um DW envolve a seleção de componentes que constituirão o ambiente, a seleção de uma abordagem para a construção dos componentes selecionados e a definição do tipo de modelagem de dados a ser empregada nos repositórios. Uma breve descrição do que trata cada uma destas etapas é descrita a seguir: •

•

•

Seleção dos componentes: é realizada através de um estudo das áreas de interesse que irão compor o DW. De acordo com o número de áreas, o volume de informações e os sistemas operativos existentes é possível realizar uma estimativa de necessidade de repositórios; Seleção da abordagem para a construção dos componentes: a abordagem "bottom-up" é a mais recomendada, pois permite balancear a relação custo x benefício, apresentando resultados rápidos e conquistando investimentos a nível pessoal e financeiro; e Definição da modelagem a ser empregada: conforme já mencionado, existe um consenso quanto ao emprego da modelagem multidimensional para os DM.

Entretanto, para o DW, a modelagem varia de acordo com sua aplicabilidade, podendo ser aplicada a visão Inmoniana ou a visão Kimballiana. A observação de experiências de desenvolvimento de DW demonstra que o conhecimento do negócio é alcançado, através da análise dos modelos de dados existentes no


59


ambiente operativo. Esses modelos permitem agilizar o desenvolvimento e garantir a simplicidade para novas interações. O DW acessa dados operativos, que são transformados e integrados para gerarem dados informativos e analíticos. A integração entre os modelos do ambiente operativo e o ADW garante que esse processo funcione da melhor forma possível. O processo de modelagem deve, portanto, transformar modelos de dados orientados a processo, os modelos funcionais, para modelos de dados orientados a negócio, os modelos dimensionais. Através da modelagem de dados realiza-se a transformação de uma visão de processo em uma visão de negócio. Essa transformação está representada na Imagem 3.8. Conforme apresentado na imagem 02, o DW é o centralizador de dados, apresentando diferentes propostas de modelagem: a modelagem dimensional (visão Kimball) e a modelagem não totalmente normalizada, porém sem ser dimensional (visão Inmon-Graziano). A decisão sobre qual melhor modelo aplicar ao DW é uma decisão de projeto, variando caso a caso, de acordo com as necessidades da empresa. Os dados no DW representam uma composição de seus repositórios, sendo a fase da modelagem responsável por garantir a integração e consolidação dos mesmos. Essa garantia é obtida através do emprego de metadados que permitem o gerenciamento e controle dos dados, desde o ambiente operativo até a sua visão pelo usuário final.


60


Imagem 02

O processo de modelagem deste ambiente é realizado com base nos requisitos e nas necessidades estabelecidos pelos usuários finais. O ponto de partida é a análise dos modelos de dados do ambiente operativo. A partir desta análise são obtidos os dados que serão trabalhados, consolidados e sumarizados. Esses dados comporão o modelo do DW, na abordagem "top-down" ou o modelo do DM, na abordagem "bottom-up". A abordagem "top-down" cria os DM a partir do modelo de dados do DW. A abordagem "bottom-up", desenvolve os DM independentemente, realizando a integração do seu modelo de dados ao modelo do DW. Para auxiliar o processo de modelagem, os desenvolvedores devem se manter atentos com relação aos seguintes itens: •

Estabelecer o escopo do DW. Este escopo se refere à definição dos componentes que integrarão o ambiente, à seleção da abordagem de


61


desenvolvimento a ser empregada e ao tipo de modelo a ser utilizado em cada um dos repositórios do ambiente. •

•

•

•

Garantir que a modelagem de dados do DW represente a visão negócio. Deve ser possível extrair do DW ou dos DM, as visões multidimensionais solicitadas pelo usuário final; Integrar as fontes de dados dos sistemas operativos e fontes externas. É importante observar que a otimização da integração, implica diretamente em acelerar a disponibilidade dos dados para as consultas dos usuários finais (resultados); Garantir a disponibilidade das informações finais para aplicativos, ferramentas OLAP e “Data mining”. Para isso a modelagem dos dados devem se preocupar com questões quanto a facilidades de uso e a transformação dos dados; Garantir que a modelagem do ambiente seja capaz, de rapidamente, ajustar-se a mudanças nos negócios.

A seguir serão apresentadas as abordagens da modelagem de dados para DW e DM existentes na literatura atual. A modelagem do DW é apresentada segundo a abordagem de Kimball, ou seja, empregando um modelo dimensional. 3.06. Tipos de arquitetura De uma forma geral, a arquitetura do DW ainda está em evolução. Esta evolução pode ser considerada como uma resposta à crescente complexidade deste ambiente e às dificuldades de integração entre todos os componentes. Os desenvolvedores deste ambiente devem se preocupar em como integrar o DW às diversas fontes heterogêneas e externas, aos DM, ODS, aplicações servidoras, "WEB" e "data mining", entre outros tipos de ferramentas disponíveis (FIRESTONE, 1998-b). As arquiteturas "top-down", "bottom-up" e intermediária são propostas para o desenvolvimento deste ambiente. Variações destas arquiteturas estão sendo avaliadas,sendo que uma arquitetura não inviabiliza a outra. Entretanto, a variedade de opções requer uma análise mais apurada do problema, para se avaliar qual é a arquitetura mais adequada à empresa. A escolha da arquitetura é fator importante na seleção da tecnologia apropriada para o desenvolvimento e a implantação deste ambiente. Atualmente, considera-se que os problemas do DW estão mais relacionados com a arquitetura do que com a tecnologia disponível (MELLO, 1997).


62


3.06.1. Arquitetura "Top-Down" A arquitetura "Top-Down" é a arquitetura conhecida como arquitetura padrão. Nesta arquitetura o processo se inicia com a extração, a transformação e com a integração das informações dos sistemas operativos e dados externos para um ODS. A seguir, os dados e metadados são transferidos para o DW.

Imagem 03

Nesta concepção, o DW armazena uma camada de dados atômicos e detalhes históricos. A partir do DW são extraídos os dados e metadados para os DM. Nos DM, as Imagem 03 – Arquitetura Padrão, empregando ODS informações estão em um maior nível de sumarização e, normalmente, não apresentam o nível histórico encontrado no DW (INMON, 1998). A imagem 03 apresenta a arquitetura padrão empregando o ODS. A seguir são apresentadas as vantagens e desvantagens desta arquitetura segundo Hackney (HACKNEY, 1998) : Vantagens : •

•

•

Herança de arquitetura - Todos os DM originados a partir de um DW, utilizam a arquitetura e os dados deste DW, permitindo uma fácil manutenção; Visão de empreendimento - O DW concentra todos os negócios da empresa, sendo possível a partir dele extrair níveis menores de informações; Repositório de metadados centralizado e simples - O DW provê um repositório de metadados central para o sistema. Esta centralização permite (11) 3531 6550 - www.strattus.com.br

63


•

manutenções mais simples do que aquelas realizadas em múltiplos repositórios; Controle e centralização de regras - A arquitetura "top-down" garante a existência de um único conjunto de aplicações para extração, limpeza e integração dos dados, além de processos centralizados de manutenção e monitoração.

Desvantagens: •

•

•

•

Implementação muito longa - Os DW são, normalmente, desenvolvidos de modo iterativo, por áreas de assuntos, como por exemplo, vendas, finanças e recursos humanos. Mesmo assim, são necessários, em média, 15 ou mais meses para que a primeira área de assunto entre em produção, dificultando a garantia de apoio político e orçamentário; Alta taxa de risco - Não existem garantias para o investimento neste tipo de ambiente; Heranças de cruzamentos funcionais. É necessária uma equipe de desenvolvedores e usuários finais, altamente capacitados para avaliar as informações e consultas que garantam à empresa habilidade para sobreviver e prosperar na arena de mudanças de competições políticas, geográficas e organizacionais; Expectativas Relacionadas ao Ambiente - A demora para conclusão do projeto e a falta de retorno pode induzir expectativas nos usuários.

3.06.2. Arquitetura "Bottom-Up" Em virtude da arquitetura "top-down" ser politicamente difícil de ser definida e muito cara, requerendo um tempo grande para implementação, investimento e sem apresentar retorno rápido, a arquitetura "bottom-up" vem se tornando muito popular. A imagem 04 apresenta a arquitetura "bottom-up". O propósito desta arquitetura é a construção de um DW incremental a partir do desenvolvimento de DM independentes. O processo começa com a extração, a transformação e a integração dos dados para um ou mais DM, sendo estes DM modelados, normalmente, através de um modelo dimensional. Um dos grandes problemas desta arquitetura é a falta de um gerenciador que garanta padrões únicos de metadados, mesmo com a independência dos DM.


64


A dificuldade em se garantir essa padronização é responsável pela falha na elaboração incremental do DW. A seguir são apresentadas as vantagens e desvantagens desta arquitetura segundo Hackney (HACKNEY, 1998): Arquitetura "Bottom-Up"

Imagem 04 Vantagens: •

•

•

•

Implementação rápida - A construção dos DM é altamente direcionada, permitindo um rápido desenvolvimento. Normalmente, um DM pode ser colocado em produção em um período de seis a nove meses; Retorno Rápido - A arquitetura baseada em DM com incremento demonstra rapidamente seu valor, permitindo uma base para investimentos adicionais, com um nível mais elevado de confiança; Manutenção do Enfoque da Equipe - Um dos maiores desafios do desenvolvimento de um ADW é a manutenção do mesmo enfoque por toda a equipe. A elaboração de DM incrementais, permite que os principais negócios sejam enfocados inicialmente, sem que haja gastos no desenvolvimento de áreas que não são essenciais ao problema; Herança Incremental - A estratégia de DM incrementais obriga a entrega de recursos de informação, passo a passo. Isto permite a equipe crescer e aprender, reduzindo os risco. A avaliação de ferramentas, tecnologias, consultores e vendedores só devem ser realizados uma vez, a não ser que existam restrições que impeçam o reaproveitamento.


65


Desvantagens: •

•

•

•

Perigo de LegaMarts - Um dos maiores perigos no DW é a criação de DM independentes. O advento de ferramentas de "drag-and-drop" facilitou o desenvolvimento de soluções individuais, de acordo com as necessidades da empresa. Estas soluções podem não considerar a arquitetura de forma global. Desta forma, os DM independentes transformam-se em DM legados, ou LegaMarts. Os LegaMarts dificultam, quando não inviabilizam futuras integrações. Eles são partes do problema e não da solução;

Desafio de Possuir a Visão de Empreendimento - Durante a construção dos DM incrementais é necessário que se mantenha um rígido controle do negócio como um todo. Este controle requer um maior trabalho ao extrair e combinar as fontes individuais do que utilizar um DW; Administrar e Coordenar Múltiplas Equipes e Iniciativas - Normalmente, esse tipo de arquitetura emprega o desenvolvimento de DM em paralelo. Isto pode conduzir a uma rígida administração tentando coordenar os esforços e recursos das múltiplas equipes, especialmente nas áreas de regras e semântica empresariais; A Maldição de Sucesso - A arquitetura com DM incrementais carrega a " maldição de sucesso". Nestes casos, os usuários finais do DM encontramse felizes querendo mais informação para seus DM. Ao mesmo tempo, outros usuários de outros DM aguardam o incremento de seus DM. Isto conduz a equipe de DM a vencer desafios políticos, de recurso e de administração.

Muitas das novas abordagens propostas baseiam-se na arquitetura "bottom-up". Elas procuram melhorar o processo de desenvolvimento e garantir a consistência dos metadados e facilidade de integração do ambiente. A arquitetura de DM para empresa ("Enterprise Data Mart Architecture" - EDMA) e a arquitetura de armazenamento de dados/ DM ("Data Storage/Data Mart" DS/DM ) são bons exemplos dessas novas abordagens (FIRESTONE, 1998-b) . A seguir essas arquiteturas são apresentadas em maiores detalhes. 3.06.2.1. Enterprise Data Mart Architecture (EDMA) a) EDMA: A EDMA é uma evolução da arquitetura "bottom-up", que emprega a abordagem incremental para o DW pelo desenvolvimento de DM, utilizando um "framework" compartilhado.


66


Imagem 05

Este "framework" inclui áreas de assunto da empresa, dimensões comuns, métricas, regras de negócio e fontes de dados. Seu principal objetivo é garantir uma padronização dos metadados utilizados na construção do ambiente, permitindo o desenvolvimento incremental do DW, com margens mínimas de duplicidade e inconsistência de informações. A EDMA é uma arquitetura que introduz o DDS substituindo o conceito do ODS original. A imagem 05 apresenta esta arquitetura. 3.06.2.2. Data Storage/Data Mart (DS/DM) A arquitetura DS/DM é muito similar à arquitetura EDMA, entretanto ela substitui o DW por uma visão que representa uma conjunção lógica de DM. A arquitetura DS/DM é representada pela imagem 06. Para autores como Inmon (INMON, 1998), a idéia de um DW como um conjunto integrado de DM é muito difícil de ser implantada, dadas as características específicas de cada DM. - Arquitetura "Data Storage/Data Mart" – DS/DM


67


Imagem 06

3.06.3. Arquitetura intermediária Esta arquitetura tem o propósito de integrar a arquitetura "top-down" com a "bottom-up". Nesta abordagem efetua-se a modelagem de dados do DW, sendo o passo seguinte à implementação de partes desse modelo. Estas partes são escolhidas por área de interesse e constituem os DM. Cada DM gerado a partir do modelo de dados do DW é integrado no modelo físico do DW. A principal vantagem desta abordagem é a garantia da consistência dos dados. Esta garantia é obtida em virtude do modelo de dados para os DM ser único, possibilitando realizar o mapeamento e o controle dos dados. 3.07. Data Marts Os Data Marts (DM) podem ser considerados Data Warehouses departamentalizados. Como por exemplo, menor volume de dados e padrão de uso bastante previsível. Eles necessitam de tecnologia mais simples e barata, face a esse menor volume de dados. Seu desenvolvimento e mais rápido e os resultados mais palpáveis a curto prazo. Observem a imagem 07. Veja como os data marts se apresentam na visão estrutural, onde aplicações hipotéticas os alimentam Os data marts tem muito apelo, porque eles podem ser construídos de forma simples, rápida e barata. Atualmente já se fala em "canned data marts", ou "data marts enlatados", que seriam ferramentas extremamente simples e baratas, destinadas a atender a necessidades bastante estruturadas (Radding, 1999). Durante algum tempo, esses data marts independentes foram muito populares. Mas, logo sua arquitetura se mostrou falha: quando uma corporação construía (11) 3531 6550 - www.strattus.com.br

68


vários desses data marts, o volume de redundância de dados (quase sempre dados analíticos) crescia muito, como crescia o número de programas que faziam o interface entre essas estruturas e os sistemas legados; também cresciam os recursos de hardware envolvidos. Já do ponto de vista da organização, o problema maior talvez seja o de se ter áreas tomando decisões a partir de números diferentes, gerados em função da redundância - quer por erros, quer por diferentes graus de atualização ou critérios de tratamento de dados (o exemplo clássico, embora possa não ser o melhor para esse tema, é o arredondamento versus truncamento de valores).

Imagem 07

Constatada essa realidade, percebeu-se que os data marts independentes não eram a solução, evoluindo-se então para o conceito de data marts dependentes. Em uma arquitetura desse tipo, há um warehouse central que alimenta os marts dependentes; é chamada também arquitetura "hub-and-spoke" (cubo-e-raio), onde os marts são os raios e o warehouse, o cubo. Como vantagem dessa estrutura, apresenta-se a integração de dados no cubo e autonomia de processos e nenhuma redundância de dados nos raios. Os padrões gerais de design de banco de dados ditaram os caminhos de evolução e sofisticação do ambiente de warehousing; em seus primeiros tempos, a normalização de dados clássica era a base para a estruturação; quando a arquitetura cubo/raio evoluiu, o padrão passou a ser a normalização e "star join" para o cubo e 'snowflake" para os raios. Uma vez que o warehouse já esteja construído, a próxima etapa será sua exploração, no sentido de buscar, utilizar, as informações nele contidas. Esse trabalho, que é chamado "data mining", permite descobrir padrões importantes, relações de causa e efeito que vinham passando despercebidas, tendências em longo prazo, etc., de forma a permitir a melhoria dos processos.


69


É preciso ter em mente que as diferenças entre data mart e data warehouse são apenas com relação ao tamanho e ao escopo do problema a ser resolvido. Portanto, as definições dos problemas e os requisitos de dados são essencialmente os mesmos para ambos. Enquanto um data mart trata de problema departamental ou local, um data warehouse envolve o esforço de toda a companhia para que o suporte à decisões atue em todos os níveis da organização. Sabendo-se as diferenças entre escopo e tamanho, o desenvolvimento de um data warehouse requer tempo, dados e investimentos gerenciais muito maiores que um data mart. A crescente popularidade desses mal definidos (entendidos), data marts sobre a popularidade dos grandes sistemas de data warehouses corporativos é baseada em muitos bons motivos: •

•

•

Os data marts têm diminuído drasticamente o custo de implementação e manutenção de sistemas de apoio à decisão e têm os posto ao alcance de um número muito maior de corporações. Eles podem ser prototipados muito mais rápido, com alguns pilotos sendo construídos entre 30 e 120 dias e sistemas completos sendo construídos entre 3 e seis meses. Os data marts têm o escopo mais limitado e são mais identificados com grupos de necessidades dos usuários, o que se traduz em esforço/time concentrado.

Os departamentos autônomos e as pequenas unidades de negócio freqüentemente preferem construir o seu próprio sistema de apoio à decisão via (11) 3531 6550 - www.strattus.com.br

70


data marts (células de BI). Muitos departamentos de informática estão vendo a efetividade desta aproximação entre os dois mundos e estão construindo o data warehouse por assunto ou um data mart por vez, gradualmente ganhando experiência e garantindo o suporte dos fatores chave de gerenciamento e vendo, então, benefícios concretos muitas vezes ao ano. Começando com planos modestos e os desenvolvendo na medida em que se adquire mais conhecimento sobre as fontes de dados e as necessidades dos usuários faz com que as organizações justifiquem os data marts na medida em que progridem. Veja abaixo o esquema de um DW pela visão de Kimball

DW = Operational Data Store + Data Marts Integrados

Data Marts Integrados Marketing

Sistemas Operativos

Integração & Transformação

Vendas

ODS

Finanças Produção

Histórico (não temporário) Alto nível de detalhe

R.H. ...

3.08. Gerando o modelo dimensional através do StarSchema O modelo dimensional é representado pelos esquemas Star (Estrela), Snowflake (Floco de neve) ou por suas variações. A composição típica do modelo Estrela possui uma tabela central denominada Fatos (fact table) e um conjunto de entidades denominadas Dimensão (dimension tables), na formato de uma estrela. Partindo do modelo de negócios existente na organização, projetado através do modelo ER (Entidade-Relacionamento), analisam-se as dimensões que podem vir a fazer parte do processo, e como podem ser agregados os valores detectados. Inicialmente, as dimensões são consideradas de maneira geral, para posterior detalhamento de atributos e suas hierarquias. Para a geração do modelo dimensional, a proposta baseia-se no padrão de ambiente de DW, que é gerado a partir do ambiente operacional, com o modelo do negócio. (11) 3531 6550 - www.strattus.com.br

71


Deve existir a correlação entre os esquemas conceituais do banco de dados operacional, observando os atributos das entidades e relacionamentos que identificam fatos em um esquema ER. Essa análise pode indicar dimensões implícitas no negócio a ser modelado. Para gerar o modelo dimensional, portanto, faz-se necessário desmontar hierarquias, que são os relacionamentos normalizados do modelo ER, anexando as informações relevantes às tabelas Fatos ou Dimensão correspondentes. Essa fase da metodologia caracteriza-se pela definição dos aspectos inicias do modelo de negócio, que correspondem à definição da granularidade, dimensões e fatos.Também são estabelecidas as medidas de derivação.

O esquema estrela é uma estrutura simples, com poucas tabelas e ligações ("joins") bem definidas, que permite: Facilidade de leitura e entendimento, não só pelos analistas, como por usuários finais não familiarizados com estruturas de banco de dados ; Um projeto de um banco de dados com uma visão mais próxima à do usuário final; Criação de um banco de dados que propicie consultas rápidas, realizadas de modo eficiente e intuitivo pelo usuário final; Entendimento e "navegação" dos metadados pelos desenvolvedores e usuários finais; Utilização de uma série de ferramentas "front-end", desenvolvidas especialmente para atender a este tipo de modelo.

•

•

•

•

•

Este esquema, entretanto, apresenta dificuldades com as dimensões, quando as mesmas são muito grandes ou aparecem em grande número. Os sistemas que apresentam estas características não devem forçar a utilização deste esquema (POE, KLAUER, BROBST, 1998).

Além disso, este esquema não apresenta uma forma clara de tratar hierarquias implícitas. O nome "Estrela" está associado à disposição física do modelo, que consiste de uma tabela central, a tabela de fatos, que se relaciona com "n" tabelas de dimensões. A imagem 08 apresenta este esquema. O esquema estrela pode representar tanto o modelo lógico, como o modelo físico do banco de dados (KIMBALL, 1997). A representação mais simples de um modelo dimensional contém um esquema estrela com uma tabela de fatos relacionada com tabelas de dimensões. Na verdade, um modelo dimensional pode ser representado por uma ou mais tabelas de fatos, relacionadas com tabelas de dimensões. Entretanto, a visão de um esquema por vez torna o modelo mais claro.


72


Imagem 08

3.08.1. Variações do StarSchema Abaixo segue uma pequena explicação sobre as variações do Esquema Estrela: A. Esquema Estrela com múltiplas tabelas fato: acontece quando existem fatos não relacionados tornando possível existir mais de uma tabela fato ou quando a freqüência de carga dos dados operacionais é distinta. Ex. tabela fato de vendas e tabela fato de vendas previstas. B. Tabelas Associativas: algumas chaves podem ser desdobradas na tabela fato quando existem relacionamentos muitos - para - muitos.


73


C. Esquema Estrela com tabelas Externas: nesse esquema uma ou mais tabelas dimensão podem conter uma chave estrangeira que referencia a chave primária de outra tabela dimensão, podendo também ser chamada de tabela dimensão secundária. D. Esquema floco de neve: o esquema floco de neve é uma variação do esquema estrela no quais todas as tabelas dimensão são normalizadas na terceira forma normal (3FN). Reduzem a redundância, mas aumentam a complexidade do esquema e conseqüentemente a compreensão por parte dos usuários. Elas dificultam as implementações de ferramentas de visualização dos dados. Impossibilitam o uso de esquemas de indexação mais eficientes como o bitmap indexing. E. Tabela Multi - Estrela: são assim chamadas quando a chave da tabela fato é complementada por mais campos que não são dimensões. F. Constelações: quando existem múltiplas tabelas fato que compartilham as mesmas dimensões, dizemos que o esquema de constelações de fatos. Isto acontece quando as medidas nas tabelas fatos possuem diferenças em relação aos eventos geradores: Ex: vendas realizadas x vendas previstas ou venda unitária x desconto por venda conjunta. 3.08.2. Vantagens do modelo StarSchema Veja algumas das principais vantagens de se utilizar o modelo Straschema para a modelagem dimensional de seus DWs: •

•

•

O modelo Estrela tem uma arquitetura padrão e previsível. As ferramentas de consulta e interfaces do usuário podem se valer disso para fazer suas interfaces mais amigáveis e fazer um processamento mais eficiente; Todas as dimensões do modelo são equivalentes, ou seja, podem ser vistas como pontos de entrada simétricos para a tabela de fatos. As interfaces do usuário são simétricas, as estratégias de consulta são simétricas, e o SQL gerado, baseado no modelo, é simétrico; O modelo dimensional é totalmente flexível para suportar a inclusão de novos elementos de dados, bem como mudanças que ocorram no projeto. Essa flexibilidade se expressa de várias formas, dentre as quais temos: Todas as tabelas de fato e dimensões podem ser alteradas simplesmente acrescentando novas colunas a tabelas;  Nenhuma ferramenta de consulta ou relatório precisa ser alterada de forma a acomodar as mudanças; 


74


Todas as aplicações que existiam antes das mudanças continuam rodando sem problemas;



•

Existe um conjunto de abordagens padrões para tratamento de situações comuns no mundo dos negócios. Cada uma destas tem um conjunto bem definido de alternativas que podem então ser especificamente programadas em geradores de relatórios, ferramentas de consulta e outras interfaces do usuário. Dentre estas situações temos:  

•

Mudanças lentas das dimensões: ocorre quando uma determinada dimensão evolui de forma lenta e assíncrona; Produtos heterogêneos: quando um negócio, tal como um banco, precisa controlar diferentes linhas de negócio juntas, dentro de um conjunto comum de atributos e fatos, mas ao mesmo tempo esta precisa descrever e medir as linhas individuais de negócio usando medidas incompatíveis;

Outra vantagem é o fato de um número cada vez maior de utilitários administrativos e processo de software serem capazes de gerenciar e usar agregados, que são de suma importância para a boa performance de respostas em um data warehouse.

3.08.3. Tabela de fatos A tabela de fatos representa as informações que serão avaliadas, sendo, normalmente, constituída de valores numéricos que representam os objetos da análise, como por exemplo, total de vendas, total de movimentação, média, máximos ou mínimo de valores. Algumas vezes é possível encontrar tabelas de fatos sem valores numéricos, nesses casos, normalmente, a tabela de fatos é empregada para mapear eventos. (KIMBALL, 1997) A tabela de fatos normalmente é grande, apresentando muitos registros. Esta tabela contém as informações básicas do nível de transação do negócio, de interesse particular a uma aplicação. Uma característica importante da tabela de fatos é a esparsidade, dessa forma, quando não existem valores para um cruzamento de dimensões, não são armazenados zeros. A tabela de fatos armazena as medições numéricas totalmente focadas para o negócio. Os desenvolvedores no geral devem dar preferência aos atributos que representem valores de adição, ou seja, atributos que permitam o incremento de dados. Segundo Kimball (KIMBALL et al , 1998), os fatos podem ser classificados em transações individuais, "snaphots", linhas de itens.


75


As transações individuais, normalmente, apresentam uma estrutura muito simples, com um campo acumulado que contém o valor da transação. Os fatos "snapshots" representam medidas de atividades extraídas em tempo determinado, como, por exemplo, fim do dia ou fim do mês. Os fatos do tipo "linhas de itens" são aqueles que representam exatamente uma linha de item, como, por exemplo, itens de pedido, itens de entrega e itens de vendas, etc. 3.08.3.1. Fatos com produtos heterogêneos A área financeira representa um dos melhores exemplos para produtos heterogêneos, porque, normalmente, trabalha com uma variedade de produtos e serviços. Para estes modelos dimensionais, recomenda-se a criação de uma dimensão geral e de dimensões específicas para os produtos/serviços. Da mesma forma, será necessária uma tabela de fatos gerais e tabelas de fatos específicas para cada produto. Estas tabelas de fatos específicas podem apresentar sua chave compondo a chave da tabela de fatos geral. Desse modo, é possível agilizar o processo de consultas. Os fatos específicos ou "sub - fatos" representam medições numéricas de uma dimensão específica, podendo ser inseridas na tabela de fatos principal (ou global). (KIMBALL et al , 1998). A imagem 09 apresenta uma tabela fato, com análises bancárias, e com uma tabela de sub-fato.

Imagem 09


76


3.08.3.2. Classificação de atributos em uma tabela de fatos Os atributos mais comuns em uma tabela de fatos são valores numéricos. Estes valores podem ser de três tipos: •

•

•

Valores Aditivos: são valores da tabela de fatos sobre os quais podem ser aplicadas as operações de soma, subtração e média. Os valores, como por exemplo, "total de vendas" e "total de itens vendidos", por Produto X Região X Loja representam valores aditivos. Valores Não Aditivos: são valores da tabela de fatos que não podem ser manipulados livremente, como valores percentuais ou relativos. Para esses tipos de valores, os cálculos devem ser realizados sobre os dados absolutos nos quais se baseiam. Todos os valores que medem um nível de intensidade são valores estáticos não aditivos. Esses valores são válidos para o momento em que a informação foi obtida, e sua soma através do tempo não tem significado, entretanto, podem ser úteis para futuras manipulações. Segundo Kimball (KIMBALL, 1997), estes valores, normalmente mostram totais segundo fatores multiplicativos diferentes. Para estes casos, é recomendável que se mantenham os valores unitários, geradores dos valores não aditivos, na tabela de fatos. As consultas a serem realizadas sobre a tabela de fatos podem realizar os cálculos ou se for o caso, visões podem ser criadas com os valores calculados. Um exemplo de valores não aditivos pode ser representado por informações de totais a preço de custo e a preço de venda, de itens perdidos e danificados, armazenados na tabela de fatos "ESTOCAGEM". Valores Semi Aditivos: são valores que envolvem contagem dupla. Portanto, são restritos a uma dimensão. Quando a análise é efetuada sobre a dimensão aditiva, as operações normais podem ser aplicadas sobre o valor. Segundo Kimball (KIMBALL, 1996), todas as medições que registram um nível estático, como níveis de estoque e saldos de contas financeiras, e medições de intensidade, como de temperatura ambiente, são informações não aditivas ao longo do tempo. Entretanto, podem ser agregadas, de forma útil, ao longo do tempo Segundo Kimball (KIMBALL, 1996), todas as medições que registram um nível estático, como níveis de estoque e saldos de contas financeiras, e medições de intensidade, como de temperatura ambiente, são informações não aditivas ao longo do tempo. Entretanto, podem ser agregadas, de forma útil, ao longo do tempo através do cálculo da média do número de períodos de tempo. Portanto, podem ser considerados valores semi-aditivos.

Três soluções são recomendadas para o tratamento deste tipo de valor: 

Qualquer tentativa de processamento sobre valores semi-aditivos deve ser avisada ao usuário;


77


Recorrer ao dado básico, isto é, ao dado ainda não agregado, de onde foi extraída a tabela de fatos correspondente;  Gerar na tabela de fatos, registros que armazenem o total real, embutindo uma agregação em relação ao atributo semi-aditivo. 

Um exemplo de valor semi-aditivo é o valor em estoque por mês de um produto. As manipulações e consultas sobre estes fatos devem restringir ou agregar o período, pois a soma dos totais em estoque em mais de um período, contabilizaria mais de uma vez itens em estoque. 3.08.4. Tabela de Dimensão A tabela de dimensão armazena as informações necessárias para análises ao longo de dimensões, sendo normalmente, menores que a tabela de fato. Esta tabela apresenta chave simples e seus campos, normalmente descritivos, são empregados como fonte das restrições e linhas de cabeçalhos para relatórios. A qualidade do banco de dados é proporcional a dos atributos de dimensões, portanto deve ser dedicado tempo e atenção a sua descrição, ao seu preenchimento e a sua garantia de qualidade. (KIMBALL, 1996). 3.08.4.1. Dimensões com Itens Heterogêneos A dimensão que descreve itens heterogêneos, segundo Kimball (KIMBALL, 1996) (KIMBALL et a l, 1998), é aquela cujos atributos representam mais de um produto ou serviço. Este tipo de dimensão é comum na área financeira. Para estas dimensões recomenda-se, após a definição do modelo principal, contendo a tabela de fatos central e a tabela dimensional central, a criação de tabelas de fatos e tabelas dimensionais específicas para cada tipo de item. A definição da dimensão global, abrangendo os vários tipos de itens, possibilita a elaboração de consultas gerais. Enquanto a definição das dimensões específicas permite consultas específicas com um maior nível de detalhe. Segundo Thomsen (1997, p.66), "Uma hierarquia é um atributo de uma dimensão". As hierarquias são a base para a agregação de dados e para a navegação entre os diferentes níveis de detalhe em um estrutura multidimensional (THOMSEN,1997) (MEYER, CANNON, 1998) . As hierarquias descrevem a estrutura organizacional e lógica dos relacionamentos entre os dados (MEYER, CANNON, 1998). A Imagem 10 apresenta os níveis de agregações que podem ser aplicados a dimensão Produto .


78


Muitas dimensões apresentam uma estrutura hierárquica ou de múltiplos níveis. A imagem 10 apresenta as hierarquias de múltiplos níveis para a dimensão Tempo . Algumas estruturas hierárquicas são facilmente identificadas, como por exemplo, uma estrutura de tempo representada por horas, dias, semanas, meses, trimestres e anos; e uma estrutura geográfica representada por cidades, municípios, estados, regiões e países. Dois tipos de hierarquia podem ser considerados para uma dimensão: explicita e implícita. •

Hierarquias explícitas: segundo Kimball (KIMBALL, 1997), a identificação

deste tipo de hierarquia é realizada através de uma análise do DER. As hierarquias são caracterizadas por uma seqüência de entidades interligadas, cujos relacionamentos, entre cada par de entidades na seqüência, sejam N:1. A imagem 10 representa a hierarquia explícita para a dimensão Produto . Essa hierarquia é constituída pelas dimensões Tipo e Categoria . •

Hierarquias Implícitas: também conhecidas como múltiplas hierarquias,

representam as hierarquias embutidas nos atributos das dimensões. Um exemplo para múltiplas dimensões, pode ser observado na imagem 10, apresenta a classificação de produtos de um supermercado. Essa classificação é feita nas categorias alimentos e material de limpeza. Os alimentos podem ser sub-categorizados, quanto à duração, em perecíveis ou não perecíveis, ou, quanto à fórmula, em dietético ou não dietético. Do mesmo modo, os materiais de limpeza podem ser classificados, quanto à sua fórmula, em tóxica ou não tóxica, ou, quanto à sua consistência, em líquida, pastosa ou em pó.

Imagem 10 (11) 3531 6550 - www.strattus.com.br

79


Uma questão importante a ser abordada diz respeito à influência da hierarquia das dimensões sobre a tabela de fato. A tabela de fatos deve refletir a menor granularidade das dimensões.

Imagem 11

Ao se estabelecer as hierarquias nas dimensões, a menor granularidade deve ser mantida na tabela de fatos, de modo a garantir que não sejam armazenados registros que representem totais referentes a um nível mais alto na hierarquia de uma dimensão. Dessa forma, se a dimensão Produto , na imagem 10, apresenta a hierarquia: CATEGORIA/ TIPO/ PRODUTO , os registros na tabela de fatos devem indicar totais no nível de produto. Os registros que totalizem por CATEGORIA ou TIPO não devem ser armazenados. 3.08.4.2. Dimensões Descaracterizadas As dimensões descaracterizadas, também conhecidas como dimensões degeneradas, são representadas na tabela de fatos como chaves de dimensão, sem que exista a tabela de dimensão. Um exemplo de dimensão descaracterizada é representada pelo número de controle de documentos, número de pedidos e número de faturas. Este tipo de atributo, normalmente, é empregado em tabelas de fatos onde o grão da tabela representa o documento propriamente dito ou uma linha de item do documento. 3.08.4.3.Tratamento de dimensões e fatos com cardinalidade Segundo Kimball (KIMBALL et al , 1998), apesar de, normalmente, a cardinalidade entre as dimensões e a tabela de fatos ser 1:N, podem acontecer casos em que esta cardinalidade seja M:N. Para este tipo de cardinalidade, Kimball (KIMBALL et al , 1998) recomenda a adição de uma nova dimensão que representará uma ponte entre a dimensão original e a tabela de fatos.


80


A identificação deste tipo de cardinalidade empregando um desenvolvimento baseado apenas em técnicas dimensionais não é uma tarefa trivial. Neste tipo de desenvolvimento, as dimensões e a própria tabela de fatos são definidas de acordo com a especificação do usuário final. Para identificar a existência da cardinalidade M:N é necessário uma análise mais minuciosa, cruzando o modelo gerado com as regras do negócio. Quando esta cardinalidade é identificada, deve ser realizada a inserção de uma dimensão ponte. Esta dimensão ponte representa efetivamente a cardinalidade M:N, com a tabela de fatos. Esta dimensão, além de sua chave normal, terá uma chave que permite identificar o conjunto de informações. Esta chave, única para um conjunto, será inserida na tabela de fatos. Dessa forma, será possível realizar as consultas pela dimensão origem, garantindo que não haverá repetições na tabela de fatos. Abaixo o amigo leitor vai poder observar uma lista de definições que devem ser seguidas para analisar o tipo de cardinalidade que deverá ser utilizada entre suas tabelas fatos e as dimensões: •

•

•

•

•

•

•

•

Estabelecer a granularidade do modelo, identificando a necessidade do nível sumarizado; Gerar a tabela de fatos, a partir do escopo do problema de transações referente ao departamento selecionado; Identificar às dimensões não associativas, que estão ligadas aos fatos, com respectivos atributos; Identificar a dimensão associativa, e respectivos atributos dimensionais; Gerar a dimensão tempo, a partir do período da transação da operação, com sua respectiva granularidade, observando a necessidade de análise do negócio; Determinar os atributos das entidades que serão utilizados nas várias dimensões geradas, considerando o negócio em análise; Definir as medidas e regras de derivação, relacionadas aos valores e números de transações; Verificar as hierarquias de classificação, definindo se essas serão agregadas às dimensões associativas;


81


•

•

•

Verificada a existência de valores nulos, que não atendam aos requisitos de exatidão e clareza estabelecidos para o modelo; Comparar e revisar os relacionamentos gerados no modelo dimensional com o modelo operacional original; Verificada a necessidade da utilização dos atributos para se preservar a análise do negócio.

3.08.4.4. Técnicas de rastreamento de alterações Os modelos de dados do ambiente operativo fazem pouca, ou mesmo, nenhuma distinção entre os dados estáveis e aqueles freqüentemente alterados. Como o DW é sensível às mudanças, uma organização ótima é aquela que separa os dados de acordo com sua freqüência de atualização. As modificações dinâmicas exigem um grande controle de sincronismo, o que é difícil, em virtude do grande volume de informações armazenadas neste ambiente. Os atributos descritivos, normalmente, apresentam informações que evoluem lentamente ao longo do tempo. Por exemplo, o atributo ESTADO_CIVIL na dimensão CLIENTE. Ao longo dos anos, as pessoas se casam, Morrem e se divorciam. O emprego de mini-dimensões representa uma forma de tratar as alterações em dimensões. Entretanto, outras soluções são apresentadas para esse problema. Para garantir a manutenção do histórico dos dados através do tempo, acompanhando a sua evolução são apresentadas três soluções (KIMBALL, 1996) (McGUFF,1998) : 1. Não manter o histórico, e simplesmente sobrescrever: a única vantagem desta solução é a facilidade de implementação. A mudança ocorrerá na dimensão responsável pela informação, onde um registro será alterado recebendo um novo valor. Quando as mudanças ocorrem para acertos no cadastro esta solução é válida. Porém, para os demais casos, esta não é a solução ideal, porque não atinge o propósito de manter o acompanhamento histórico dos dados. 2. Adicionar um novo registro, com uma nova chave, e a nova descrição: esta solução exige uma chave genérica. Kimball sugere a adoção de um formato de chave que adicione os dígitos de versão ao final. As chaves genéricas devem estar descritas nos metadados e serem tratadas pelas aplicações do usuário final. Esta solução não impõe maiores complexidades às aplicações. Nos aplicativos de navegação pelo DW, as consultas pressupõem uma visão dos dados através do tempo. As consultas são


82


feitas de forma a obter totais por período, particionando naturalmente a tabela de fatos de forma cronológica. 3. Criar um campo a mais para o atributo em questão na tabela dimensão, para manter o valor corrente: Esta solução permite visualizar ou restringir a dimensão de acordo com o valor original ou com o valor corrente do atributo que sofreu a alteração. É mais complexa que a solução anterior com relação às aplicações, sendo pouco aplicada na prática. Apesar de nenhum registro novo ser criado, torna-se necessária a manutenção de dois campos para um atributo, um com o valor corrente e o outro com o valor original. É necessária a criação de um campo com a data em que o valor corrente entrou em vigor. Como não existe mudança de chave, a única forma de identificar a mudança é através da referência à data da alteração. Utilizando, como exemplo, o atributo estado_civil na dimensão ALUNO, a descrição dos registros passaria a ter dois novos campos est_civil_original, est_civil_data_efetiva - e o campo est_civil passaria a chamar-se est_civil_corrente. Esta solução é própria para uma fase de adaptação, quando se precisa visualizar os dados com base no valor antigo ou novo do atributo, como se não existissem mudanças. A complexidade de se implementar este tipo de solução reside no tratamento destas considerações, que devem se referir ao campo de data efetiva. Além disso, manter apenas o valor original e o valor corrente de um atributo não atinge, por completo, o objetivo de acompanhar o histórico dos dados, pois os valores intermediários são perdidos. 3.08.4.5. Criando novas chaves É comum, a criação de novas chaves identificadoras para as dimensões em um DW. Esta nova identificação, normalmente, é decorrente das seguintes necessidades (INMON, 1997): •

•

Re-mapeamento de chave para evitar a dependência da chave original. Essa necessidade ocorre quando existe a possibilidade de alteração de chave e é necessário evitar a sua reutilização. A reutilização de chaves é comum no ambiente operativo devido a sua pequena periodicidade de armazenamento. O DW, ao contrário armazena os registros por um longo período, exigindo uma nova chave para evitar duplicidades e inconsistências para as consultas; Re-mapeamento de chaves, reduzindo chaves longas para obter um melhor desempenho nas consultas;


83


•

Estabelecimento de chaves genéricas, permitindo mudanças na descrição dos itens sem provocar alterações nas chaves. A solução normalmente adotada no nível físico é acrescentar dois ou mais dígitos ao final da chave original.

Estes novos dígitos indicam a versão do item. As chaves genéricas permitem o rastreamento de modificações pela generalização da chave primária. Apesar da modelagem física não pertencer ao escopo deste trabalho é interessante observar que a nível físico, é comum a criação de chaves onde a estrutura representa uma montagem baseada em processos de "hashing", para facilitar o acesso. 3.08.4.6. Criando de Mini - dimensões Segundo Kimball (1996, p.99), " A melhor abordagem para analisar modificações em tabelas dimensionais extremamente grandes é subdividi-las em mini-dimensões compostas por pequenos conjuntos de atributos estruturados para conter um número limitado de valores.". As mini-dimensões representam uma das melhores formas de tratar periodicidades de atualização diferentes em dimensões muito grandes (KIMBALL,1996). Além disso, permitem a manutenção de um bom desempenho porque, normalmente, se relacionam com a tabela de fatos, permitindo consultas diretas. O relacionamento da mini-dimensão com a dimensão origem permite outros meios de navegação. A imagem 12 apresenta um exemplo de mini-dimensão DEMOGRÁFICA para a dimensão CLIENTE.

Imagem 12


84


3.08.5. Granularidade Granularidade é o nível de representação mais específico utilizado para armazenar os dados. Cada Grânulo representa, em suma, uma entidade dentro da modelagem E-R. Em muitas situações, existem hierarquias de conceitos, onde a modelagem é o nível mais inferior. Um banco de maior granularidade é um banco de dados extremamente normalizado. O nível de granularidade de um DW deve ser estudado de forma a deixá-lo de entendimento e uso mais simples, para qualquer usuário. Quanto mais baixo o nível escolhido para a granularidade no DW, maior será a quantidade de dados armazenados (próximo ao transacional). A escolha da granularidade do DW não precisa ser a mesma da utilizada no operacional, por isso sempre será igual ou superior (agregado). Observando a questão da granularidade, pode-se considerar, também a aditividade, em que medidas podem ser resumidas. A aditividade torna-se importante quando ocorre a possibilidade de sumarização em tabelas de fatos. Geralmente é desejável que as medidas possam ser completamente aditivas, pois quando não são, deve-se considerar dividi-las em seus elementos mais baixos (atômicos). Como regra geral, os dados podem ser mantidos com o maior nível de detalhamento e posteriormente, sumarizados, gerando um nível mais baixo de granularidade, oferecendo flexibilidade às consultas do usuário. 3.08.6. Medidas de derivação Nesse momento, as informações já definidas são consideradas e inicia-se o processo de refinamento e detalhamento do modelo. Podem ser detectados atributos novos e atributos desnecessários podem ser eliminados. Consultas em tempo de execução geralmente não são satisfatórias e é necessária a materialização de dados agregados. Portanto, propõe-se criar mecanismos para sumarizar informações, evitando a necessidade de execução do processo de sumarização em toda consulta, através de regras estabelecidas na metodologia proposta: •

•

Para a sumarização dos dados devem ser utilizadas as funções (em SQL) SUM , AVG , COUNT ou equivalentes; Quando não existir a necessidade de análise atômica no dado, esse deve ser sumarizado, caso contrário, deve-se manter o mais baixo nível de granularidade ou manter na tabela Fatos os dados sumarizados e uma hierarquia (ou similar) com os dados atômicos.


85


A imagem 13 mostra algumas das medidas derivadas: SaldoMedioMensal, NumeroTransacoes, JurosPagos e TotalCredito, e suas regras de derivação, geradas a partir das tabelas de dimensão e implementadas na tabela Fatos. As medidas derivadas referenciadas no exemplo são sumarizadas através da utilização dos operadores SUM , AVG e COUNT na agregação dos valores de medidas de dimensões.

Imagem 13

3.09. Data Mining Qualquer sistema de Data Warehouse (DW) só vai funcionar e poder ser utilizado plenamente, com a utilização de boas ferramentas de exploração. Com o surgimento do DW, a tecnologia de Data Mining (mineração de dados) também ganhou a atenção do mercado. Como o DW, possui bases de dados bem organizadas e consolidadas, as ferramentas de Data Mining ganharam grande importância e utilidade. Essa técnica, orientada a mineração de dados, oferece uma poderosa alternativa para as empresas descobrirem novas oportunidades de negócio e acima de tudo, alcançar novas estratégias para o futuro. O propósito da análise de dados é descobrir previamente características dos dados, sejam relacionamentos, dependências ou tendências desconhecidas. Tais descobertas tornam-se parte da estrutura informacional em que decisões são formadas. Uma típica ferramenta de análise de dados ajuda os usuários finais na definição do problema, na seleção de dados e a iniciar uma apropriada análise para geração da informação, que ajudará a resolver problemas descobertos por eles. Em outras palavras, o usuário final reage a um estímulo externo, a descoberta do problema por ele mesmo. Se o usuário falhar na detecção do problema, nenhuma ação é tomada. A premissa do Data Mining é uma argumentação ativa, isto é, em vez do usuário definir o problema, selecionar os dados e as ferramentas para analisar tais dados, (11) 3531 6550 - www.strattus.com.br

86


as ferramentas do Data Mining pesquisam automaticamente os mesmos a procura de anomalias e possíveis relacionamentos, identificando assim problemas que não tinham sido identificados pelo usuário. Em outras palavras, as ferramentas de Data Mining analisam os dados, descobrem problemas ou oportunidades escondidas nos relacionamentos dos dados, e então diagnosticam o comportamento dos negócios, requerendo a mínima intervenção do usuário, assim ele se dedicará somente a irem à busca do conhecimento e produzir mais vantagens competitivas. Como podemos ver as ferramentas de Data Mining, baseadas em algoritmos que forma a com lógica de predicados, somente facilitam e auxiliam o trabalho dos analistas de negócio das empresas, ajudando as mesmas a conseguirem serem mais competitivas e maximizarem seus lucros. Nota: O capitulo Especiais vai apresentar um tópico inteiro sobre Data Mining, trazendo ainda mais informações para você amigo leitor.

3.10. Metadados Desde que surgiram os bancos de dados sempre se falou sobre a importância da documentação dos sistemas e dos próprios bancos. Com o surgimento do conceito de Data Warehouse, isso não diminuiu a importância, pelo contrário, aumentou e muito. As Corporações estão exigindo cada vez mais funcionalidades dos sistemas de TI (Tecnologia da Informação), e repositórios de metadados não são nenhuma exceção a esta regra. Mas o que são metadados? Acima vimos que sempre houve preocupação com a documentação dos sistemas e bancos de dados das corporações, sabemos que no Data Warehouse documentar tudo é vital para a sobrevivência do projeto, pois o DW pode ser um projeto gigantesco e se não houver uma documentação eficiente ninguém conseguirá entender nada. Os metadados são definidos como dados dos dados. Só que a complexidade desses dados no Data Warehouse aumenta muito. Num sistema OLTP gera-se documentos somente sobre o levantamento dos dados, banco de dados e o sistema que alimenta o mesmo. No Data Warehouse além do banco, gera-se uma documentação muito maior. Além de falar sobre o levantamento de dados e o banco, temos ainda o levantamento dos relatórios a serem gerados, de onde vem os dados para alimentar o DW, processos de extração, tratamento e rotinas de carga dos dados. Ainda podem gerar metadados as regras de negócio da empresa e todas as mudanças que elas podem ter sofrido, e também a freqüência de acesso aos dados. (11) 3531 6550 - www.strattus.com.br

87


Segundo Inmon os metadados englobam o DW e mantém as informações sobre o que está onde. Ele ainda define quais informações os metadados mantêm: • • • •

• • •

A estrutura dos dados segundo a visão do programador; A estrutura dos dados segundo a visão dos analistas de SAD; A fonte de dados que alimenta o DW; A transformação sofrida pelos dados no momento de sua migração para o DW; O modelo de dados; O relacionamento entre o modelo de dados e o DW; O histórico das extrações de dados;

Acrescentamos ainda os dados referentes aos relatórios que são gerados pelas ferramentas OLAP assim como os que são gerados nas camadas semânticas. Os metadados podem surgir de vários locais durante o decorrer do projeto. Eles provêm de repositórios de ferramentas case, os quais geralmente já estão estruturados, facilitando a integração da origem dos metadados e o repositório dos mesmos. Essa fonte de metadados é riquíssima. Outros dados que devem ser guardados no repositório de metadados, é o material que surgirá das entrevistas com os usuários. Destas entrevistas podem obter-se informações preciosas que não estão documentadas em nenhum outro lugar além de regras para validação dos dados depois de carregados no Data Warehouse. Como pudemos ver, o volume de metadados gerados é muito grande. Existem hoje algumas ferramentas que fazem única e exclusivamente o gerenciamento dos metadados. Elas têm algumas características peculiares. Falando de uma maneira simplista, essas ferramentas conseguem mapear o dado em todas as etapas de desenvolvimento do projeto, desde a conceitual até a de visualização dos dados em ferramentas OLAP/EIS. Agora vamos discutir os desafios arquitetônicos mais complexos que surgem ao implementarmos um repositório de metadados que requer funcionalidade mais avançada. Enquanto a maioria dos repositórios não tenta implementar estas características, eles representam o tipo de funcionalidade que é exigida através das corporações. As fontes metadados, (ferramentas de modelagem de dados, ferramentas de extração, transformação e carga, etc.) devem ser integradas no repositório por várias necessidades. Uma arquitetura de metadados bidirecional permite que os


88


dados modificados na fonte possam ser alterados também no repositório automaticamente. Esta arquitetura é altamente desejável por duas razões chaves. Primeiro: permite a essas ferramentas compartilhar metadados. Isto é desejável no mercado de ferramentas de apoio de decisão. A maioria das corporações que construíram um sistema de apoio a decisão não pensou na integração das ferramentas. Estas não são integradas, por isso, não se comunicam facilmente. Até mesmo essas ferramentas que podem ser integradas tradicionalmente requerem bastante programação manual para compartilhar dados. Segundo: metadados bidirecional é atraente para corporações que querem implementar um repositório de metadados em toda empresa. Como vimos os metadados são importantíssimos para o sucesso de um DW. Ao começarmos qualquer projeto devemos sempre nos preocupar com os mesmos, pois são eles que servirão de bússola para nos guiar pelo emaranhado de tabelas, relatórios e dados quando estivermos perdidos. 3.11. OLAP As ferramentas OLAP (On-Line Analytical Processing) são as aplicações que nossos usuários finais têm acesso para extraírem os dados de suas bases com os quais gera relatórios capazes de responder as suas questões gerenciais. Elas surgiram juntamente com os sistemas de apoio a decisão para fazerem a extração e análise dos dados contidos nos Data Warehouses e Data Marts. Nota: O capitulo especiais vai apresentar um tópico inteiro sobre a arquitetura OLAP.

3.11.1. Geração de Consultas (Queries) A geração de consultas no OLAP se dá de uma maneira simples, amigável e transparente para o usuário final, o qual precisa ter um conhecimento mínimo de informática para obter as informações que deseja. Cada uma destas tecnologias e técnicas tem seu lugar no mercado de DSS (Decision Support System) e apóia diferentes tipos de análises. É importante lembrar que as exigências do usuário devem ditar que tipo de Data Mart você está construindo. Como sempre, a tecnologia e técnicas devem estar bem fundamentadas para atenderem da melhor maneira possível essas exigências. Os Data Warehouses/Data Marts, servem como fonte de dados para estas aplicações, assegurando a consistência, integração e precisão dos dados. Os sistemas transacionais não conseguem responder essas questões por isso, é


89

Livro Apostila BI

Recommend Documents