faculdade catÓlica de administraÇÃo e …celepar7cta.pr.gov.br/portfolio.nsf... · web...
TRANSCRIPT
FACULDADE CATÓLICA DE ADMINISTRAÇÃO E ECONOMIA
CENTRO DE DESENVOLVIMENTO EMPRESARIAL
CURSO DE TECNOLOGIA DA INFORMAÇÃO E COMUNICAÇÃO
PROJETO DE CURSO
PROPOSTA DE UM ROTEIRO PARA PROJETAR UM DATA WAREHOUSE
CURITIBA
FEVEREIRO DE 2000
CLAUCIA MARQUES COSTA
FABIANO AUGUSTO PEREZ LIMA
FERNANDO ARAÚJO FIGUEIREDO
HENRIQUE SALATINO MIORELLI
MARCOS VIEIRA DE SOUZA
PROPOSTA DE UM ROTEIRO PARA PROJETAR UM DATA WAREHOUSE
Monografia apresentada à disciplina Projeto de Curso para obtenção do título de Especialista no Curso de Pós-Graduação em Tecnologia da Informação e Comunicação no Centro de Desenvolvimento Empresarial da Faculdade Católica de Administração e Economia.
Orientador: Prof. Luís Pedro Zambon.
CURITIBA
FEVEREIRO DE 2000
AGRADECIMENTOS
Ao professor e orientador Luís Pedro Zambon, que durante os nossos
estudos, nos direcionou à qualidade fazendo críticas e sugestões, dando-nos apoio
no trabalho, bem como pelos conhecimentos que nos foram transmitidos.
Agradecimentos especiais à nossa equipe de desenvolvimento deste projeto,
tanto pelo interesse comum em atingir o sucesso quanto pela grande amizade e
companheirismo que fortaleceu-se durante este trabalho.
ii
RESUMO
O data warehouse, literalmente , é um “armazém de dados” . É uma base de
dados carregada de forma incremental em um período de tempo. O data warehouse
organiza e armazena os dados necessários para processamento informatizado e
analítico sobre perspectivas históricas ao longo do tempo, tendo como principal
objetivo transformar o dado em informação. É uma arquitetura que utiliza banco de
dados desenvolvido para análise e tomada de decisões em bases sumarizadas e
também detalhadas, com o intuito de contemplar os segmentos da empresa ou
organização.
O data warehouse pode revolucionar os negócios da empresa. Ao ser bem
elaborado e implementado, e caso seja cuidadosamente direcionado para a
chamada “inteligência de negócio”, ele pode tornar-se uma vantagem competitiva.
Essa ferramenta está fazendo surgir novos conceitos de gestão da informação ,
tipos de consultas e análises dos negócios. Os principais conceitos que norteiam
essa tecnologia serão abordados e analisados como pré-requisitos que, direta ou
indiretamente, são necessários para o desenvolvimento do projeto.
O enfoque principal do trabalho é reunir grande parte da fundamentação
teórica referente ao assunto data warehouse , organizando essas informações
através de um roteiro que especifica as etapas necessárias no desenvolvimento do
projeto. Um outro item importante é amenizar o grau de dificuldade encontrado por
profissionais da Tecnologia da Informação quando iniciam um projeto de data
warehouse, bem como prover o conhecimento mínimo necessário àqueles
profissionais que não têm referência alguma sobre esse assunto.
Apresentaremos o que é importante entender e considerar para alcançar o
sucesso do projeto, através de etapas que auxiliem o desenvolvimento do mesmo e
exemplos de cenários reais para a sua utilização, onde a tecnologia de data
warehouse pode suprir as necessidades de informação da empresa ou organização.
iii
SUMÁRIO
LISTA DE TABELAS..................................................................................................viii
LISTA DE FIGURAS..................................................................................................viii
LISTA DE SIGLAS...................................................................................................... ix
MÉTODO DE TRABALHO........................................................................................xiv
PLANO DE TRABALHO.............................................................................................xv
1. FUNDAMENTOS TEÓRICOS................................................................................1
1.1 CONCEITOS........................................................................................................1
1.1.1 Dado x Informação.............................................................................................1
1.1.2. Data Warehouse (Armazém de Dados)............................................................1
1.1.3. Data Mart (Mercado de Dados)........................................................................3
1.1.4. Engenharia da Informação................................................................................4
1.1.5. Sistemas de Suporte à Decisão (DSS-Decision Support Systems)..................5
1.1.6. Inteligência Do Negócio (Business Intelligence)...............................................5
1.1.7. Modelagem De Dados......................................................................................5
1.1.8. Banco De Dados Relacional.............................................................................8
1.1.8.1. Tabelas..........................................................................................................8
1.1.9. Banco De Dados Multidimensional...................................................................8
1.1.10. Análise Multidimensional...............................................................................9
1.1.11. OLTP (Online Transaction Processing)........................................................10
1.1.12. OLAP (Online Analytical Processing)...........................................................10
1.1.12.1. ROLAP (Relacional OLAP)........................................................................12
1.1.12.2. MOLAP (Multidimensional OLAP)..............................................................12
1.1.12.3. HOLAP (Híbrido OLAP).............................................................................13
1.1.12.4. WOLAP (Web OLAP).................................................................................13
1.1.13. Operações Olap............................................................................................13
iv
1.1.14. Modelagem Dimensional Dos Dados............................................................14
1.1.14.1. Fatos..........................................................................................................15
1.1.14.2. Dimensões De Um Cubo...........................................................................16
1.1.14.3. Agregações................................................................................................16
1.1.14.4. Técnica star schema (esquema estrela)....................................................17
1.1.14.5. Técnica snow flake (floco de neve)...........................................................17
1.1.15. Metadados....................................................................................................18
1.1.16. Ferramenta CASE (Computer Aided Software Engineering)........................20
1.1.17. SQL (Structured Query Language)...............................................................20
1.1.17.1. Stored procedure (sp)................................................................................21
1.1.18. Indexação.....................................................................................................22
1.2. ASPECTOS ESTRATÉGICOS PARA A CONSTRUÇÃO DE UM DATA WARE-
HOUSE......................................................................................................................23
1.2.1. Planejamento..................................................................................................23
1.2.2. Necessidades Das Empresas.........................................................................25
1.2.3. Hierarquia Clássica Da Informação Na Empresa...........................................28
1.2.4. Motivação Da Empresa No Mercado..............................................................29
1.2.5. Necessidades e Benefícios Para o Usuário....................................................29
1.2.6. Perfil Do Usuário Na Empresa Que Utiliza O Data Warehouse......................30
1.2.7. Análise Do Ambiente Legado.........................................................................33
1.2.8. Equipe De Desenvolvedores..........................................................................36
1.2.9. Aspectos Da Implementação Física (Rolap/Molap)........................................37
1.2.10. Performance.................................................................................................39
1.2.11. Segurança.....................................................................................................40
2. DESENVOLVIMENTO..........................................................................................41
2.1. FATORES CRÍTICOS DE SUCESSO...............................................................41
2.2. DEFINIÇÃO DA TÉCNICA DE DESENVOLVIMENTO DE SISTEMAS A SER.....
UTILIZADA................................................................................................................42
v
2.3. VISUALIZAR AS NECESSIDADES DO USUÁRIO...........................................43
2.4. NOVA VISÃO DA INFORMAÇÃO PARA A TOMADA DE DECISÕES..............44
2.5. ANÁLISE DO NEGÓCIO A SER MODELADO..................................................45
2.6. ANÁLISE DO AMBIENTE LEGADO..................................................................46
2.7. MODELAGEM DIMENSIONAL DOS DADOS...................................................49
2.7.1. Dimensões......................................................................................................50
2.7.2. Fatos...............................................................................................................50
2.7.3. Exemplo de uma análise dimensional............................................................50
2.7.4. Agregações.....................................................................................................53
2.7.5. Metadados......................................................................................................53
2.7.6. Resumo das etapas para a modelagem dimensional.....................................54
2.8. ASPECTOS DA IMPLEMENTAÇÃO FÍSICA......................................................55
2.8.1. Levantamento de volumes de dados..............................................................55
2.8.2. Periodicidade de Carga..................................................................................56
2.8.3. Tempo de Armazenagem dos Dados.............................................................57
2.8.4. Controle de Backup’s......................................................................................57
2.8.5. Análise de Performance..................................................................................58
2.8.6. Segurança......................................................................................................59
2.9. ASPECTOS DA VISUALIZAÇÃO DAS INFORMAÇÕES..................................60
2.9.1. Queries Simples..............................................................................................60
2.9.2. Stored Procedures (sp)...................................................................................60
2.9.3. Ferramentas OLAP.........................................................................................61
2.9.4. Aplicativos de Consulta...................................................................................64
2.10. ESTUDOS DE CASOS REAIS (NECESSIDADES DO NEGÓCIO E MODE-
LAGEM DIMENSIONAL)...........................................................................................65
2.10.1. TAP – Termo de Acordo de Parcelamento...................................................66
2.10.2. Arrecadação Estadual de ICMS do Paraná..................................................68
2.10.3. CONPREVI...................................................................................................70
vi
CONCLUSÃO............................................................................................................72
ANEXOS....................................................................................................................75
ALGUNS FORNECEDORES DE FERRAMENTAS OLAP ATUAIS..........................75
SUGESTÃO DE UMA TABELA DIMENSÃO TEMPO DETALHADA.........................76
FIGURAS...................................................................................................................77
REFERÊNCIAS BIBLIOGRÁFICAS..........................................................................79
vii
LISTA DE TABELAS
1. EXEMPLO DE GERENCIAMENTO DE AGREGAÇÕES ...................................56
2. EXEMPLO DE STAR SCHEMA PARA TERMO DE ACORDO DE
PARCELAMENTO ...................................................................................................
.............67
3. EXEMPLO DE STAR SCHEMA PARA ARRECADAÇÃO ESTADUAL DE
ICMS.....................................................................................................................68
4. DEFINIÇÃO DE AGREGAÇÃO NA TABELA FATOS ARRECADAÇÃO..............69
5. EXEMPLO DE STAR SCHEMA CONPREVI........................................................71
6. FORNECEDORES DE FERRAMENTAS OLAP ATUAIS.....................................75
7. SUGESTÃO DE UMA TABELA DIMENSÃO TEMPO DETALHADA....................76
LISTA DE FIGURAS
1. CUBO PARA MODELAGEM DIMENSIONAL DOS DADOS COM TRÊS DIMEN-
SÕES....................................................................................................................49
2. EXEMPLO DA TÉCNICA STAR SCHEMA...........................................................52
3. AGREGAÇÃO COM DUAS DIMENSÕES............................................................53
4. VISUALIZAÇÃO DAS DIMENSÕES E FATOS ATRAVÉS DA FERRAMENTA
OLAP BUSINESS OBJECTS................................................................................62
5. SOLICITAÇÃO DAS INFORMAÇÕES DAS DIMENSÕES E FATOS ATRAVÉS
DE COMANDOS DRAG AND DROP....................................................................63
6. HIERARQUIA IMPLEMENTADA EM UM BANCO DE DADOS
MULTIDIMENSIONAL...............................................................................................
.....................64
7. EXEMPLO DE UM CUBO DIMENSONAL............................................................77
8. EXEMPLO DE UMA ESTRUTURA STAR SCHEMA............................................77
viii
9. EXEMPLO DE UMA ESTRUTURA SNOW FLAKE..............................................78
10.EXEMPLO DE UM MODELO DE DADOS (MER)................................................78
ix
LISTA DE SIGLAS
ANSI - American National Standards Institute
API - Aplication Program Interface
CASE - Computer Aided Software Engenering
CELEPAR - Companhia de Informática do Paraná
CONPREVI - Conselho de Previdência dos Serventuários do Estado do Paraná
DATA MARTS - Mercados de Dados
DCL - Linguagem de controle de dados
DDL - Linguagem de definição de dados
DER - Diagrama Entidade Relacionamento
DM - Dimensional Modeling
DML - Linguagem de manipulação de dados
DSS - Decision Support Systems
DSS - Sistema de Apoio à Decisão
DW - Data Warehouse
DWA - Administrador de Data Warehouse
EIS - Sistema de Informações Executivas
ER - Entity Relation
ERP - Enterprise Resource Planning
FIPS - Federal Information Processing Standards
HOLAP - Híbrido On Line Analytical Processing
IB - Business Intelligence
ICMS - Imposto sobre Circulação de Mercadorias e Serviços
IMS - Information Management System
IS - Sistemas de Informações
ISO - International Organization for Standardization
MER - Modelo Entidade Relacionamento
x
MOLAP - Multidimensional On Line Analytical Processing
NIST - National Institute of Standards and Techonology
ODS - Operational Data Store
OLAP - On Line Analytical Processing
OLTP - On Line Transaction Processing
RDBMS - Relational Data Base Management System
ROLAP - Relacional On Line Analytical Processing
RPC - Remote Procedure Call
SDLC - Ciclo de Vida de Desenvolvimento de Sistemas Clássico
SEFA/PR - Secretaria da Fazenda do Estado do Paraná
SGBD - Sistema de Gerenciamento de Banco de Dados
SGBDR - Sistema Gerenciador de Banco de Dados Relacional
SQL - Structured Query Language
SQL/MM - Structured Query Language Multimídia
TAP - Termo de Acordo de Parcelamento
VSAM - Virtual Storage Access Method
WOLAP - Web On Line Analytical Processing
xi
INTRODUÇÃO
1. Problema
Hoje constata-se freqüentemente nas Empresas que as informações estão
desorganizadas, pouco integradas e de difícil acesso pelos usuários quando os
mesmos necessitam analisá-las para tomar decisões. São freqüentes as perguntas
feitas pelos executivos das empresas com relação às informações:
“Nós temos montanhas de dados nesta empresa mas não temos acesso
aos mesmos”.
“Nós queremos cruzar informações de todas as maneiras possíveis”.
“Apenas me mostre o que é importante”.
Estas perguntas poderão ser respondidas mais rapidamente se a empresa
possui um data warehouse consistente e integrado porém, não é uma tarefa simples
o desenvolvimento de um projeto desse nível. Para tanto, as premissas abaixo
devem ser observadas:
De que maneira agilizar o processo de tomada de decisão na Empresa
utilizando a Tecnologia da Informação?
De que forma o data warehouse realmente possibilita agilizar o processo
de tomada de decisão na Empresa?
Quais etapas um profissional da Tecnologia da Informação deve seguir
para desenvolver um projeto de data warehouse?
2. Importância e Justificativa
Atualmente, a informação é o principal patrimônio de uma empresa ou
organização e a mesma é utilizada no processo de tomada de decisões importantes
e estratégicas. Portanto, a informação deve ser tratada como fator primordial com
relação à competitividade do mercado. No entanto, muitas empresas necessitam
integrar seus dados de forma a visualizar todo o escopo operacional da empresa
xii
para que análises possam ser efetuadas de uma forma rápida, confiável e que o
usuário possa solicitar suas consultas às bases de dados sem necessitar de ajuda
do analista de informática. A integração destas bases de dados é um problema
complexo quando se visualizam várias fontes de informação distribuídas na
empresa em um mesmo ambiente computacional ou em ambientes distintos.
O conceito de data warehouse surge com a finalidade de organizar a
integração das informações e disponibilizá-las através de várias dimensões de
consulta, permitindo que todos os dados da Empresa possam estar disponíveis em
uma única base para consulta e auxílio à tomada de decisão.
O crescimento atual do conceito de data warehouse ocasionou muitas
fundamentações teóricas e, até certo ponto, dificultou a organização das etapas
necessárias desde o início do projeto até sua implementação física. Essa
necessidade que muitos analistas têm em visualizar um roteiro para o
desenvolvimento de data warehouse nos impulsionou em desenvolvermos este
trabalho, reunindo no mesmo os principais aspectos que , obrigatoriamente, devem
ser considerados no projeto.
A importância da aplicação de um roteiro para desenvolvimento de um
projeto de data warehouse baseia-se, fundamentalmente, em planejar as etapas
necessárias. O roteiro estrutura o que deve ser feito, apresenta uma seqüência
lógica das etapas e enfatiza a importância e necessidade de análise de cada fase do
desenvolvimento do projeto.
3. Objetivo Geral
Baseado em fundamentação teórica, desenvolver, para os profissionais de
Tecnologia da Informação, um roteiro suscinto e claro de como projetar um data
warehouse e aplicação deste roteiro em cenários reais de utilização.
4. Objetivos Específicos
xiii
4.1) Elaborar fundamentação teórica para suportar o assunto:
prover conhecimentos teóricos, técnicos e conceituais básicos referentes
ao desenvolvimento de projetos de construção de data warehouse;
aplicar os referidos conhecimentos aos profissionais da área de
Tecnologia da Informação;
demonstrar as fases necessárias que deverão ser consideradas no
desenvolvimento do referido projeto até a parte de projeto do modelo de
dados abrangendo: aspectos estratégicos, conceitos gerais,
levantamento das informações, modelagem dimensional dos dados,
planejamento do data warehouse, aspectos da implementação física,
consultas, além de outros assuntos também importantes que são
conseqüência dos itens principais e muitas vezes, pré-requisitos de
outros.
4.2) Identificar situações reais de necessidade de análise da informação
através de alguns estudos de caso que serão apresentados, utilizando as etapas
principais do roteiro para a construção de data warehouse para atender estas
necessidades, demonstrando principalmente a parte de negócio do cliente e projeto
do modelo de dados dimensional.
xiv
MÉTODO DE TRABALHO
O método utilizado é a pesquisa bibliográfica. As fontes bibliográficas
utilizadas foram Livros de Leitura Corrente, por constituírem conhecimentos técnicos
e Publicações Periódicas que proporcionam informações recentes e atualizadas.
Outra classificação de pesquisa bibliográfica utilizada é consultas à sites da Internet.
Os autores William H. Inmon e Ralph Kimball nortearam a fundamentação teórica
como referências bibliográficas principais.
Para o detalhamento do conhecimento adquirido através da pesquisa
bibliográfica, também foi utilizado o método de estudo de caso, que permite o estudo
profundo e exaustivo de um ou mais objetos de análise. A técnica utilizada para o
desenvolvimento de sistemas de informação com o enfoque em data warehouse, foi
a da Engenharia da Informação em virtude de o foco principal desta técnica ser os
dados, armazenados e mantidos por computadores e as informações deles
extraídas.
Também foi inserida no contexto do trabalho a experiência profissional dos
colaboradores que compõem a equipe.
xv
PLANO DE TRABALHO
Basicamente o trabalho está dividido em três partes distintas:
1ª Parte: Embasamento teórico através de pesquisa bibliográfica que dará
o suporte necessário à elaboração do roteiro para a construção de data warehouse,
visualizando conceitos e considerações necessárias para o desenvolvimento do
projeto.
2ª Parte: Início do desenvolvimento do trabalho onde será proposto o
conteúdo do roteiro para projetar um data warehouse, aspectos considerados, a
quem se destina, a elaboração do mesmo com todas as etapas necessárias e o
porquê definimos o roteiro na ordem especificada.
3ª Parte: Continuação do desenvolvimento do trabalho voltado à aplicação
do roteiro desenvolvido no que se refere às necessidades do cliente para a análise
do negócio e modelagem dimensional em estudos de casos reais, referentes ao
ambiente profissional dos integrantes desse projeto.
Primeiramente iremos organizar os assuntos em ordem seqüencial, podendo
os mesmos serem trabalhados separadamente e referenciados ao longo do trabalho.
Muitos dos itens que serão contemplados, ao menos em uma referência resumida,
são importantes no desenvolvimento do projeto para o pleno entendimento do
assunto.
Nosso plano contempla o desenvolvimento de um roteiro com as etapas
principais iniciando pelos conceitos básicos da tecnologia de data warehouse até
exemplos práticos de utilização. Nestes exemplos práticos serão apresentados
problemas na obtenção de informações para a tomada de decisão pelos usuários e
como a construção de modelos de dados utilizando a tecnologia de data warehouse
pode solucionar estes problemas.
xvi
1. FUNDAMENTOS TEÓRICOS
1.1 CONCEITOS1.1.1 Dado x Informação
Dado é um registro de fatos, conceitos ou instruções para a comunicação,
recuperação e processamento por meios automáticos e apresentação na forma de
informação compreensível para os seres humanos. Informação são dados que os
seres humanos assimilam e validam para resolver problemas ou tomar decisões
[13].
Dados são os componentes básicos, a partir dos quais a informação é
criada. Informação são dados inseridos em um contexto. Contexto é a situação que
está sendo analisada. A partir da informação vem o conhecimento, que permite
tomar decisões adequadas, trazendo vantagem competitiva [18].
1.1.2. Data Warehouse (Armazém de Dados)
Data warehouse é uma coleção de dados para suportar o gerenciamento
das necessidades de decisão, orientado a um assunto, integrado, variante no tempo
e não volátil [14].
Orientado por assunto: A primeira característica de um data warehouse é
que ele está orientado ao redor do principal assunto da organização como, por
exemplo, clientes, vendas, produtos e atividades. O alinhamento ao redor das áreas
de assunto afetam o desenho e implementação do dado criado no data warehouse.
A área de assunto mais influente é a parte mais importante da estrutura chave [14].
Integrado: A melhor essência do ambiente de warehouse é que dados
contidos dentro dos limites do warehouse estão integrados. A integração mostra-se
em muitas diferentes maneiras: na consistência e padronização 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 [14].
1
Não Volátil: Atualizações - 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. Tem somente três
espécies de operações que ocorrem no data warehouse: a carga inicial do dado, o
acesso ao dado e atualização temporal (semanal, mensal) conforme necessidades
do negócio [14].
Histórico: Todo dado no data warehouse é exato em algum momento do
tempo e em conseqüência desta informação, o dado criado no warehouse é dito ser
"histórico". Os valores históricos dos dados no data warehouse são mostrados em
várias maneiras. O modo mais simples é que o dado no data warehouse representa
os dados sobre um horizonte de tempo distante - de 5 até 10 anos [14].
Uma coleção de bancos de dados integrados e orientados a assuntos
projetados para apoiar as funções de um Sistema de Apoio de Decisão (Decision
Support Systems); onde cada unidade de dados é importante em um momento no
tempo. O data warehouse contém dados atômicos e muitas vezes sumarizados [13].
Um data warehouse não é um produto ou mesmo um conjunto de produtos,
mas processos suportados por diversas tecnologias: ele coleta dados das várias
aplicações operacionais; integra-os em um modelo lógico, por áreas de negócio;
armazena as informações de tal maneira que possam ser recuperadas por usuários
pouco técnicos; e entrega essas informações aos tomadores de decisão através de
ferramentas de fácil utilização, como geradores de relatórios e de consulta [29].
A idéia de data warehouse é integrar os dados de uma organização em uma
estrutura única provendo qualidade e melhor acesso aos dados [6].
Base de dados analítica que permite análises e simulações, para suporte às
decisões estratégicas de médio e longo prazo. Geralmente é armazenada em
ambiente específico, ou seja, separado do ambiente operacional. Características:
[25].
2
Dados históricos: para possibilitar análises combinatórias e simulações.
Armazenam grandes quantidades de dados, podendo chegar a dezenas de anos
[25].
Sumário estático: decorrente de atualização pontual, as sumarizações são
calculadas e fixadas no momento da carga [25].
Dados Corporativos: estrutura de dados das diversas áreas da empresa
(Suprimentos, Manufatura, Vendas, Finanças, Recursos Humanos, etc.), permitindo
as mais diversas comparações [25].
Data warehouse é uma arquitetura de banco de dados com informações de
caráter gerencial voltado para: suporte à decisão, planejamento estratégico, análise
do comportamento de clientes e análise da performance de vendas. Funciona como
um provedor de informações de uma empresa ou instituição, pois concentra todas as
informações estratégicas e históricas, extraídas dos sistemas transacionais relativos
aos clientes e produtos. A proposta principal do data warehouse é a democratização
das informações para a área de negócios, através do fácil acesso aos dados para
análise [1].
1.1.3. Data Mart (Mercado de Dados)
Um data mart não é uma evolução de um data warehouse, mas sim parte
das estratégias deste. Um data mart é um subconjunto de dados de um data
warehouse, desenhado para suportar uma necessidade de negócio ou uma unidade
organizacional específica. A estratégia correta é fazer o data mart incorporar-se à
arquitetura de data warehouse, sem perder a visão de conjunto. Essa visão de
conjunto é decorrência de um bom projeto de data warehouse [24].
O data mart é similar ao data warehouse com algumas exceções: [13]
O data mart opera um conjunto menor de dados [13].
O data mart visualiza o dados com um enfoque departamental enquanto
o data warehouse visualiza os dados com um enfoque corporativo [13].
3
O data mart visualiza os dados em uma base muito mais previsível
enquanto o data warehouse freqüentemente faz exploração na base de
dados [13].
Características comuns ao data warehouse e data mart são: informação
estrutural, fonte de informação e outras informações encontradas ao longo do
ambiente [13].
Obedece os mesmos conceitos do data warehouse, diferenciando-se
somente no conteúdo, ou seja, os dados são organizados por assunto, permitindo
maior independência, agilidade e ganhos de performance [25].
1.1.4. Engenharia da Informação
É um conjunto integrado de técnicas formais pelas quais modelos de
negócios, modelos de dados e modelos de processos são construídos a partir de
uma base de conhecimento compreensível utilizada para desenvolver e manter
sistemas de informação [33].
O foco principal da Engenharia da Informação são os dados, armazenados e
mantidos por computadores e as informações deles extraídas [33].
Premissas básicas: [33]
Os dados situam-se no centro dos sistemas de informação [33].
Os dados são estáveis, os procedimentos não [33].
Princípios: [33]
A análise rigorosa de dados deve ser feita antes do projeto lógico de
processos [33].
A análise de dados deve ser feita de forma independente dos arquivos
físicos e da distribuição dos dados [33].
Os dados devem ser planejados para toda a empresa [33].
4
O acesso a base de dados deve ser possibilitado aos usuários finais
através de ferramentas que ele não tenha a necessidade de programar
[33].
Construir modelos de dados de processos com a visão integral da
empresa possibilitando que os sistemas a serem desenvolvidos, mesmo
que independentes, integrem-se e ajustem-se à estrutura do modelo
corporativo [33].
1.1.5. Sistemas de Suporte à Decisão (DSS-Decision Support Systems)
Um sistema utilizado para gerenciar decisões. Usualmente envolve a análise
de muitos dados. Como regra, não envolve a atualização dos dados, somente efetua
consultas. Sistemas projetados para os executivos que caracterizam-se pela análise
de tendências [13].
Enquanto o resultado de um data warehouse é a possibilidade de auxiliar no
suporte a decisões, um DSS pode existir independentemente da arquitetura de data
warehouse. Além disso, um DSS é uma solução isolada e que não inclui
necessariamente uma arquitetura, uma infra-estrutura e nem mesmo ferramentas de
administração ou auditoria, ao contrário de um data warehouse, que deve incluir
todos esses componentes [24].
1.1.6. Inteligência Do Negócio (Business Intelligence)
É um processo de coleta, transformação, análise e distribuição de dados
para melhorar a decisão de negócios; sua infra-estrutura tecnológica é composta de
data warehouses ou data marts, ferramentas OLAP, EIS, data mining, consultas e
relatórios e software de visualização dos dados; os bancos de dados são a infra-
estrutura básica de qualquer sistema de business intelligence. São neles que vão
estar armazenados os dados que serão transformados em informações competitivas
[17].
5
1.1.7. Modelagem De Dados
Modelagem de dados é uma atividade na qual procuramos construir uma
estrutura de dados que reflita a realidade e ao mesmo tempo seja facilmente
manuseada por computadores para que os sistemas construídos a partir dela sejam
estáveis e sofram o mínimo de manutenção possível. A modelagem é dividida em
três etapas ou níveis: Conceitual, Lógico e Físico [27].
Modelo Conceitual: É desenvolvido sem levar em consideração nenhum
aspecto de representação lógica ou física dos dados, seja software, hardware ou
visão particular de um usuário. É baseado em como funciona o negócio do cliente e
ignora detalhes de implementação e performance [27].
Modelo Lógico: É desenvolvido levando-se em consideração a arquitetura
de dados suportada pelo sistema gerenciador de banco de dados. Exemplo: Em
Rede, Hierárquico, Relacional. Há a definição das tabelas, colunas e chaves. A meta
é a redução de redundâncias para simplificação do gerenciamento e aumento da
integridade [27].
Modelo Físico : O mapeamento físico leva em consideração
características de hardware e software (SGBD) e estimativas de espaço e tempo
(performance) [27].
O ponto de começo para o plano de migração é um modelo de dados. O
modelo de dados representa as necessidades de informação da corporação.
Representa o que a corporação necessita, não necessariamente o que a corporação
atualmente possui. É construído sem consideração de tecnologia [12].
O Modelo Entidade-Relacionamento (MER) será a técnica de modelagem de
dados utilizada para criação do Modelo Conceitual de Dados [8].
Esta técnica foi criada por Peter Pin-Shan Chen em 1975 e é usada para
descrever o mundo real com alto grau de abstração, em termos de entidades
(objetos de interesse), relacionamentos (forma como as entidades estão
interligadas) e atributos (características das entidades e relacionamentos) [8].
6
O MER é composto por uma representação gráfica, o chamado Diagrama
Entidade-Relacionamento (DER) e um conjunto de informações escritas sobre cada
conceito representado (entidades, relacionamentos e atributos) [8].
Apesar de ter surgido junto com a Análise Estruturada, o MER, por sua
flexibilidade, foi evoluindo com o aparecimento de novas abordagens de
desenvolvimento de sistemas (Engenharia da Informação, Análise Essencial, Análise
Orientada a Objetos), e é considerado, ainda hoje, uma linguagem universal para a
representação da realidade dos negócios de uma empresa [8].
Modelo de Dados : Estruturas de dados lógicas, providas por um sistema
gerenciador de banco de dados utilizado para a representação dos dados [13].
Entidade: Armazena os dados de uma pessoa, lugar ou objeto de interesse
em um alto nível de abstração [13]. Todo o objeto, coisa que tem alguma existência
no negócio, na vida real. Não são tabelas, são implantadas como tabelas [21].
Relacionamentos: As ações ou fatos que integram as entidades no mundo
real [21].
Modelo Entidade-Relacionamento (MER): Um modelo de dados que define
entidades, o relacionamento entre entidades e os atributos que tem valores para
descreverem as propriedades das entidades e/ou relacionamentos [13]. Um exemplo
de um modelo MER está demonstrado na Figura 4 do Anexo.
Diagrama de Entidade-Relacionamento (DER): Um modelo de dados de alto
nível que demonstra, esquematicamente, todas as entidades dentro do âmbito de
integração e a relação direta entre essas entidades [13].
Chave : Um item de dado ou combinação de itens de dados utilizados para
identificar ou localizar uma instância de um registro ou algum agrupamento de dados
similares [13].
Chave Primária : Um atributo único utilizado para identificar um registro em
um banco de dados [13].
7
Uma ou mais colunas que unicamente identificam uma linha da tabela.
Chaves primárias devem ser únicas e não nulas [5].
Chave Estrangeira: Uma ou mais colunas que referenciadas à chave
primária de outra tabela [5].
Chave Comum: Uma ou mais colunas que são freqüentemente utilizadas
para relacionar tabelas [5].
Chaves não são o mesmo que índices. Uma chave pode ou não ser um
índice [5].
Chaves são definidas no projeto lógico enquanto índices são definidos no
projeto físico para garantir performance e outras razões [5].
1.1.8. Banco De Dados Relacional
Um Sistema Gerenciador de Banco de Dados Relacional (SGBDR) mantém
tabelas que são compostas por colunas que descrevem linhas de dados [13].
Uma base ou banco de dados é uma coleção de dados relacionados e
armazenados ( freqüentemente com redundância controlada e limitada) de acordo
com um esquema. Um banco de dados pode servir única ou múltiplas aplicações
[13].
Os atuais Sistemas Gerenciadores de Bancos de Dados Relacionais
oferecem uma solução poderosa e eficiente para o processamento de grandes
volumes de transações de uma grande variedade de aplicações comerciais e
científicas [7].
1.1.8.1. Tabelas
Tabela é uma relação que consiste em um conjunto de colunas com um
título e um conjunto de linhas. Coluna é uma tabela vertical onde são selecionados
valores do mesmo domínio. Uma linha é composta de uma ou mais colunas [13].
Em um banco de dados relacional, todos os dados estão em tabelas. Uma
tabela mantém dados relacionados com uma classe particular de objetos (uma
8
entidade). Tabelas são compostas por linhas e colunas. Existe exatamente um
conteúdo de dado em cada coluna de cada linha [28].
1.1.9. Banco De Dados Multidimensional
Um sistema gerenciador de banco de dados especificamente projetado para
suportar várias dimensões de dados em uma arquitetura três camadas. Tipicamente
não suportam SQL (Structured Query Language) diretamente e, atualmente,
suportam um volume de dados significantemente menor que um Sistema
Gerenciador De Banco De Dados Relacional. Entretanto, esse tipo de gerenciador
de banco de dados pode ser uma excelente opção para uma implementação
departamental se a funcionalidade que ele provê atende à demanda do usuário
referente às informações do negócio [13].
“As pessoas falam da necessidade de separar a captura dos dados do
acesso aos dados, em termos de bases separadas, movendo informações entre si,
ao menos desde o início dos anos 80”, testemunha o especialista da IDC em data
warehouse Henry Morris. O que mudou foi a maturação de várias tecnologias-chave:
agora não é mais só o banco de dado relacional; mas SGBDR multidimensional,
com features especiais para aumento de performance, como indexação bitmap, e
novos esquemas para organizar e representar os dados, visando não somente a
inserção rápida de novas transações, mas análise e consultas complexas [2].
1.1.10. Análise Multidimensional
Análise multidimensional é a habilidade em manipular dados que foram
agregados em várias caregorias ou dimensões. A proposta da análise
multidimensional é auxiliar o usuário a sintetizar a informação da empresa através
de uma visão comparativa, personalizada e projetada para a análise de dados
históricos [13].
Algumas ferramentas de análise multidimensional possuem a habilidade em
acessar dados em um sistema gerenciador de banco de dados relacional; outras
9
requerem um esquema estrela (“star schema”) para facilitar o processamento
multidimensional [13].
A visão multidimensional é muito mais útil para os analistas do que a
tradicional visão tabular utilizada nos sistemas de processamento de transação. Ela
é mais natural, fácil e intuitiva, permitindo a visão dos negócios da empresa em
diferentes perspectivas e, assim, transformando o analista num explorador da
informação [6].
1.1.11. OLTP (Online Transaction Processing)
Processamento de aplicações transacionais [13].
Transações OLTP são extremamente disciplinadas [13].
O ambiente OLTP é previsível e regular em seu tamanho e forma [13].
Transação OLTP consome poucos recursos; pesquisa quantidade reduzida
de dados. Como resultado desta disciplina, o tempo de resposta de uma transação é
bom (dois a três segundos são o normal) [13].
De maneira geral, um sistema aplicativo está focado na precisão dos
processos operacionais [30].
1.1.12. OLAP (Online Analytical Processing)
Processamento Analítico Online é um importante método na arquitetura do
data warehouse na qual os dados podem ser transformados em informação. OLAP é
uma categoria de tecnologia de software que permite à analistas, gerentes e
executivos a obterem perspicácia em dados de uma forma rápida, consistente e com
acesso interativo para uma grande variedade de possíveis visões da informação na
empresa. Mais suscintamente, OLAP é um conjunto de funcionalidades que tem,
como principal objetivo, facilitar a análise multidimensional [13].
OLAP representa um conjunto de tecnologias projetadas para suportar
análise e consultas ad hoc (consultas efetuadas pelo usuário de acordo com sua
necessidade momentânea) [6].
10
A característica principal dos sistemas OLAP é permitir uma visão conceitual
multidimensional dos dados de uma empresa [6].
A tecnologia OLAP foi definida em 1993 por F. Cood [4].
A criação foi em decorrência da forte necessidade de análises dos dados de
forma fácil e flexibilidade, mas ao mesmo tempo, analisando múltiplas visões do
negócio em diferentes níveis de detalhes [4].
Os bancos de dados multidimensionais foram a resposta para atender a
essas necessidades analíticas. No início dos anos 90 começaram a surgir os
primeiros protótipos de bancos de dados multidimensionais. Após alguns anos de
aprimoramento da tecnologia, os bancos de dados multidimensionais foram
submetidos à análise de CODD e sua equipe em 1993. CODD então definiu 12
regras, padrões, homologou a tecnologia, e batizou os bancos de dados
multidimensionais com o nome de OLAP (derivado do termo OLTP - que foi atribuído
aos Bancos de Dados Relacionais no início da década de 1970, quando CODD
definiu os padrões para modelo Relacional) [4].
A partir da homologação de CODD, a tecnologia começou a ser utilizada e
conhecida em 1994, e os fornecedores da tecnologia criaram produtos com cada vez
mais capacidade de armazenamento, bem como vários outros recursos para facilitar
as análises [4].
Começou então a utilização de Banco de Dados Multidimensionais como
Data Marts entre 1995/96 e a tecnologia evoluiu a passos largos[4].
As bases OLAP podem ser acessadas/manipuladas através de aplicações
personalizadas ou ainda: [4].
via Internet/Intranet [4].
via aplicações pré-definidas para se fazer análises diversas [4].
A tecnologia OLAP hoje é largamente utilizada na elaboração de Data Marts,
com desdobramentos para ROLAP/modelagem NxN no Relacional) e HOLAP
(Híbrido OLAP que combina OLAP com ROLAP) [4].
11
A utilização de OLAP híbrido, o H-OLAP só é necessária quando se trata de
bases muito grandes, de grande ocorrência em Varejo, Banco e Seguradoras [4].
Histórico de lançamento de alguns produtos OLAP [17]:
Em 1970, Express foi a primeira ferramenta multidimensional usada para
aplicações de marketing. Foi adquirida pela Oracle em 1995 [17];
Em 1982, Comshare System W foi a primeira ferramenta OLAP usada
para aplicações financeiras [17];
Em 1984, Metaphor foi o primeiro ROLAP. Foi adquirido pela IBM em
1991 [17];
Em 1985, Pilot Command Center foi o primeiro EIS Cliente/Servidor estilo
OLAP [17];
Em 1992, Arbor Essbase primeiro OLAP Cliente/Servidor que usa a
planilha eletrônica com front-end [17];
Em 1994, MicroStrategy DSS Agent primeiro ROLAP com um engine
multidimensional [17];
Em 1995, Holos 4.0 primeiro HOLAP [17];
Em 1996, Business Objects primeira ferramenta que provém ao mesmo
tempo relatórios relacionais e multidimensionais de cubos construídos
dinamicamente no desktop de dados relacionais [17];
Em 1998 IBM lança o IBM DB2 OLAP [17];
Em 1998 Microsoft lança Microsoft OLAP [17].
1.1.12.1. ROLAP (Relacional OLAP)
Qualquer análise multidimensional efetuada em um sistema gerenciador de
banco de dados relacional. A base de um desenho físico ROLAP é, tipicamente,
uma combinação de dados apropriadamente normalizados em uma ou mais técnicas
star schema [13].
12
1.1.12.2. MOLAP (Multidimensional OLAP)
Qualquer análise multidimensional efetuada em um sistema gerenciador de
banco de dados multidimensional [13].
MOLAP é uma classe de sistemas que permite a execução de análises
bastante sofisticadas usando como gerenciador de dados um banco de dados
multidimensional [6].
1.1.12.3. HOLAP (Híbrido OLAP)
É um produto de OLAP híbrido que pode prover análise multidimensional
simultaneamente de dados armazenados em um banco de dados multidimensional e
em um banco de dados relacional [17].
1.1.12.4. WOLAP (Web OLAP)
Representa a migração da tecnologia OLAP para o ambiente da Internet.
Tem havido uma grande divulgação sobre o uso de Web browsers para acesso à
OLAP, mas ainda são poucos os sites em funcionamento com o uso de OLAP.
Segundo alguns institutos de pesquisa o OLAP baseado na Web será a chave para
aplicações na Intranet e deverá oferecer um caminho simples e barato no acesso ao
data warehouse [17].
1.1.13. Operações Olap
Operações OLAP são as operações de pesquisa e exploração da informação
no cubo de dados. São elas: [21].
Slice and Dice : São operações de fatiamento do cubo de dados, permitindo
sua visualização em segmentos, assim como a rotação do cubo buscando
novas perspectivas de visão de dados [21].
13
Drill Down e Roll UP : É a capacidade de navegação aprofundando o nível de
detalhamento dos dados, ou subindo este nível de detalhe conforme a
hierarquia [21].
1.1.14. Modelagem Dimensional Dos Dados
A modelagem dimensional é a técnica utilizada para se ter uma visão
multidimensional dos dados. Nessa técnica, os dados são modelados em uma
estrutura dimensional conhecida por cubo. As dimensões do cubo representam os
componentes dos negócios da empresa, tais como “cliente”, “produto”, “fornecedor”
e “tempo”. A célula resultante da intersecção das dimensões é chamada de medida
e geralmente representa dados numéricos como “unidades vendidas”, “lucro” e “total
de venda” [6].
Além dos componentes dimensão e medida, outro importante aspecto do
modelo multidimensional é a consolidação dos dados, uma vez que para a tarefa de
análise são mais úteis e significativos à agregação (ou sumarização) dos valores
indicativos dos negócios [6].
O próprio desenho do data warehouse leva a novas perspectivas de projeto.
Não há necessidade de modelagem na terceira forma normal. Na prática,
redundância de dados é bem-vinda nesse ambiente. Para muitos projetistas, é uma
maneira diferente de modelar dados [30].
Modelagem Dimensional é um nome novo para uma técnica antiga usada
para criar bancos de dados simples e compreensíveis. Quando um banco de dados
pode ser visualizado como um “cubo” contendo até três, quatro, cinco ou mais
dimensões, as pessoas conseguem visualizar este esse cubo em qualquer de suas
dimensões [19].
Outro nome para modelo dimensional é star join schema. Os projetistas de
bancos de dados têm utilizado esse nome já há algum tempo para descrever
14
modelos dimensionais porque o diagrama é semelhante a uma estrela com uma
tabela no centro rodeada por tabelas auxiliares exibidas em um padrão radial [19].
Dimensional Modeling (DM) é uma técnica lógica de projeto muito utilizada
nos data warehouses, diferente e oposta ao entity-relation modeling (ER). O DM é a
única técnica viável para os bancos de dados projetados para suportar as consultas
de usuário final de um data warehouse. O ER é muito útil na captura de transações e
nas fases de administração de dados da construção de um data warehouse, mas
deve ser evitado para o usuário final [3].
O DM é uma técnica lógica de projeto que busca apresentar os dados dentro
de uma estrutura padrão e intuitiva, permitindo ainda o acesso de alto desempenho.
Ele é inerentemente dimensional e adota a disciplina com algumas restrições
importantes. Todo modelo dimensional é composto por uma tabela com uma chave
de várias partes, denominada tabela de fatos e um conjunto de tabelas menores
chamadas tabelas de dimensão. Cada tabela de dimensão possui uma chave de
uma única parte, que corresponde exatamente a um dos componentes da chave de
várias partes da tabela de fatos. Essa característica de estrutura de “estrela”
também é chamada de star join. Este termo remonta os primeiros dias dos bancos
de dados relacionais [3].
1.1.14.1. Fatos
São as medidas básicas de informações do negócio. Representa as
quantidades e valores dos dados que podem ser agregados sem perderem seu
significado. A tabela fato ou fact table armazena as medidas básicas objetos de
análise do negócio. O dado na tabela fato é composto de elementos de dados
organizados em um nível estruturado. Os valores destes elementos de dados podem
ser sumarizados em uma variedade de formas sem por em risco a integridade dos
dados [13].
15
A chave de uma tabela fato é a composição das chaves das tabelas
dimensão. O resultado é que existirá uma linha na tabela fato para cada combinação
única dos domínios de todas as chaves de todas as tabelas dimensão.
Características: [13]
Quantifica o dado que foi descrito nas tabelas dimensão [13].
Chave composta de combinação única de valores das chaves das
dimensões [13].
Os valores da tabela fato são somente aditivos [13].
Sempre contém uma data [13].
1.1.14.2. Dimensões De Um Cubo
Descrevem ou caracterizam os dados relacionados e organizados na tabela
fatos. As tabelas dimensão circundam a tabela fato. Representam as possíveis
formas de visualizar e consultar os dados. Características: [13]
Chave deve ser única [13].
Permitir gerenciar número de níveis de agregações [13].
Dimensão não precisa ser uma hierarquia, pode ser uma combinação de
atributos [13].
(Exemplo demonstrado na Figura 1 do Anexo) [13].
1.1.14.3. Agregações
Agregações são sumarizações de dados com o objetivo principal de
melhorar a performance de acesso. Geralmente armazenadas em tabelas fatos
separadas [13].
Abstração de dados que, aplicada à modelagem conceitual de dados,
permite que objetos venham a formar um novo objeto de mais alto nível. Foi
proposto por J. M. Smith em 1977 [27].
Agregações fornecem níveis múltiplos de detalhes do fato [18].
16
Os resultados das queries (ou seus valores intermediários) são pré-
calculados, o que melhora muito a performance [18].
As agregações podem ser acumuladas através de agrupamentos diferentes,
freqüentemente através de várias dimensões ou combinação de dimensões [18].
O único aspecto mais importante de desígn de um data warehouse é o
assunto da granularidade. Granularidade se refere ao nível de detalhe contido as
unidades de dados no data warehouse [12].
Quanto mais detalhamento há, mais baixo será o nível de granularidade.
Quanto menos detalhamento há, mais alto o nível de granularidade [13].
A razão por que granularidade é o assunto de desígn principal no ambiente
de data warehouse é que afeta profundamente o volume de dados residente no
data warehouse e ao mesmo tempo afeta o tipo de questão que pode ser respondida
[12].
1.1.14.4. Técnica star schema (esquema estrela)
A técnica star schema pré-processa os dados em uma tabela fatos central
com tabelas de dimensão relacionadas. As chaves únicas de cada tabela dimensão
compõem uma chave combinação na tabela fatos. Os benefícios desta técnica são
que os dados estão pré-processados em dimensões conhecidas e caracterizadas
em um conjunto específico de necessidades de informação do negócio, tornando o
acesso pelo usuário mais eficiente (Exemplo demonstrado na Figura 2 do Anexo)
[13].
Este modelo é composto por uma tabela com chave de múltiplas partes
(dimensões) chamadas de tabela fato e de um conjunto de tabelas pequenas
chamadas de dimensões, que formam as pontas das estrela. Cada tabela de
dimensão tem uma chave primária simples que corresponde a um dos componentes
da chave múltipla da tabela fato. A princípio parece um modelo muito simples de ser
construído, porém a determinação das dimensões e do fato tem necessidade de
17
excelente entendimento conceitual para que se obtenha sucesso em uma
implantação de data warehouse [21].
1.1.14.5. Técnica snow flake (floco de neve)
A técnica snow flake é uma variante do star schema com as tabelas
dimensões normalizadas (Exemplo demonstrado na Figura 3 do Anexo) [21].
As hierarquias tem significado e importância dentro da análise
multidimensional. No modelo star, elas estão todas em vista da desnormalização das
entidades, um dos conceitos básicos de modelagem multidimensional. Um
esquema alternativo é o esquema snow flake, onde normalizando as hierarquias
encadeamos relacionamentos e entidades a partir das dimensões. A utilização de
esquema snow flake depende da necessidade de otimizações no projeto físico ou
nas queries realizadas. Lembramos que sempre um data warehouse tem como
objetivo sistemas de apoio a decisão, que necessitam das mais variadas consultas
[21].
Um esquema snow flake em nosso entendimento é somente uma alternativa
de construção do modelo de dados multidimensional .Todo modelo snow flake pode
rapidamente ser transformado em um star, bastando para isto relacionarmos as
hierarquias diretamente às tabelas fato, desnormalizando-as completamente [21].
1.1.15. Metadados
São dados sobre dados. Descrição dos dados: estrutura, conteúdo, chaves,
índices, detalhes, etc. Sem os metadados, o data warehouse e seus componentes
associados seriam meramente componentes não integrados trabalhando
independentemente e com objetivos distintos [13].
Para alcançar harmonia e unidade entre os diferentes componentes do
ambiente projetado, deve haver uma técnica bem definida e rigorosa para
desenvolver os metadados. Existem metadados para: [13]
18
O ambiente operacional [13].
A camada de integração e transformação [13].
Porções detalhadas do data warehouse [13].
Depósitos de dados operacionais [13].
Data mart’s [13].
Ambiente de desenvolvimento [13].
Modelo do negócio da Empresa [13].
Para atingir um grau de segurança na confiabilidade dos dados, o primeiro
passo é catalogar os metadados com RDBMS (Relational Data Base Management
System), plataforma, fontes de dados, tabelas, campos, índices, chaves primárias,
chaves estrangeiras, stored procedures, parâmetros, programas – ou seja, o
metadados contém todas as informações que explicam o funcionamento da base de
dados [22].
Com os metadados catalogados, as estruturas de dados de todo o ambiente
estarão sempre sendo verificadas. Portanto, a cada mudança que ocorra nas bases
de dados transacionais, o administrador estará sempre sendo alertado, o que
aumenta sua confiança na informação que estará sendo disponibilizada aos
tomadores de decisão [22].
Importante utilizar metadados para descrever o modelo dos dados e para
auxiliar na construção das consultas. Dessa maneira, um analista pode executar
suas análises utilizando seus próprios termos [6].
É o dado sobre um determinado dado. Por exemplo: os metadados poderiam
indicar se uma base de dados existe na corporação, quais atributos formam uma
determinada tabela, características físicas de um determinado atributo, tais como:
tamanho e formato, onde ele é utilizado, etc. As informações do metadado podem
ser sobre os dados do legado, dados armazenados em data warehouse ou
informações pertinentes a um catálogo. Estas informações são armazenadas em um
repositório que tem o objetivo de documentar e administrar estes metadados e
19
fornecer informações para reuso destes dados, melhorando a qualidade e
produtividade da empresa [16].
Metadados é a mais importante regra no data warehouse e, é usado em
vários aspectos: [14]
É direcionado para ajudar na localização analítica do conteúdo no data
warehouse para o DSS [14].
É um guia para mapear os dados, como o dado é transformado do
ambiente operacional para o ambiente do data warehouse [14].
É um guia para o algoritmo usado para a sumarização entre dado
corrente detalhado e o dado “lightly” sumarizado e o dado “highly”
sumarizado, etc [14].
1.1.16. Ferramenta CASE (Computer Aided Software Engineering)
São ferramentas individuais que auxiliam o desenvolvedor de software ou
gerente de projeto durante uma ou mais fases do desenvolvimento de software (ou
manutenção) [10].
Uma combinação de ferramentas de software e metodologias de desenvolvi-
mento estruturado [10].
CASE pode auxiliar diretamente no projeto e suporte do desenvolvimento de
sistemas e também provê gerenciamento da informação, documentação e controle
de como desenvolver um projeto [10].
Alguns benefícios do CASE: [10]
Reduz custos, especialmente manutenção [10].
Melhora a qualidade de software [10].
Acelera o processo de desenvolvimento [10].
Incrementa a produtividade [10].
Tornam práticas as técnicas estruturadas [10].
20
1.1.17. SQL (Structured Query Language)
É uma linguagem padrão de acesso aos dados em bancos de dados
relacionais independente de fornecedor. É dividida em três partes: linguagem de
definição de dados (DDL), linguagem de manipulação de dados (DML) e linguagem
de controle de dados (DCL). O padrão internacional é estabelecido pela ISO
(International Organization for Standardization). A primeira normatização do SQL foi
feita pela ANSI (American National Standards Institute) em 1986. O SQL/86 foi um
subconjunto das implementações de SQL da IBM. A primeira norma da ISO saiu em
1989. A norma internacional vigente é a versão de 1992 (ISO/IEC 9075:1992(E),
também conhecida como SQL92 ou SQL2). Ela se subdivide em 3 partes: Entry
Level, Intermediate Level e Full Level. A maioria dos sistemas gerenciadores de
banco de dados só implementa o Entry Level completamente. Já existem trabalhos
para o SQL/3 e SQL/MM (Multimídia) que devem implementar alguns conceitos da
tecnologia de orientação à objeto. Um dos órgãos de certificação de conformidade
dos produtos com a norma é o NIST (National Institute of Standards and
Technology) que publica o FIPS (Federal Information Processing Standards) que
contém uma lista de sistemas gerenciadores de banco de dados que tem
conformidade com o padrão e em qual plataforma [27].
Uma linguagem que habilita o usuário a interagir diretamente com o sistema
gerenciador de banco de dados para recuperar e/ou modificar dados gerenciados
pelo mesmo [13].
Características: [28]
É uma forma padrão de especificar conjuntos de dados [28].
É uma forma de recuperar e manipular dados em um banco de dados
relacional [28].
É utilizada para todas as funções de bancos de dados, incluindo
administração, criação de esquemas e recuperação [28].
21
Pode ser utilizada na forma de “SQL embutida” em um programa de
aplicativo [28].
1.1.17.1. Stored procedure (sp)
Stored Procedure é uma técnica de projeto que permite que um conjunto de
instruções SQL sejam compiladas e armazenadas no gerenciador de banco de
dados. São rotinas chamadas por aplicações cliente de modo semelhante a RPC
(Remote Procedure Call) e são armazenadas e executadas no servidor. A stored
procedure fornece uma significante melhora de performance sobre o SQL utilizado
diretamente na aplicação [27].
Uma stored procedure é uma coleção de comandos SQL armazenados no
banco de dados e que pode ser executada pelo nome. Características: [5]
Podem aceitar e retornar parâmetros e podem chamar outras procedures
[5].
Processam mais rapidamente que os mesmos comandos SQL
executados interativamente [5].
Reduzem o tráfego de dados na rede [5].
A primeira vez que uma stored procedure é executada, um plano de
acesso é produzido no banco de dados [5].
Garantem a consistência do banco de dados [5].
Provêem um nível extra de segurança [5].
Sugerem o desenvolvimento de uma aplicação modular [5].
Reduz erro de operação [5].
Exemplo de sintaxe padrão de criação de uma stored procedure: [5]
create proc nome da procedure
as comandos_SQL
Exemplo de sintaxe padrão de execução de uma stored procedure: [5]
exec nome da procedure
22
1.1.18. Indexação
É o conceito de índices de acesso. São estruturas de indexação destinadas
a otimizar o acesso aos dados. É importante lembrar que em bancos de dados
relacionais, uma chave nem sempre tem um índice associado a ela. Chaves são
definições de nível lógico e os índices são estruturas físicas para melhorar a
performance no acesso aos dados. Há dois tipos de índices: clustered index e
nonclustered index. No clustered index os dados de uma tabela são ordenados
fisicamente pelo índice. Ele tem um nível a menos de acesso em relação ao
nonclustered. O índice nonclustered armazena os valores das chaves e ponteiros
para as páginas de dados onde as linhas estão armazenadas [27].
Índice : Porção da estrutura de armazenamento de dados mantida para
prover acesso eficiente a um registro quando seu conteúdo chave é conhecido [13].
Índice Invertido : Uma estrutura de índice organizada por meio de uma chave
não única que aumenta a velocidade de pesquisa aos dados [13].
Índices: [5]
São utilizados para melhorar a performance. (se nenhum índice é
definido a uma tabela, a tabela inteira deverá ser pesquisada para
satisfazer uma condição de consulta) [5].
Provêem um mecanismo para garantir a unicidade [5].
Clustered: O dado é classificado na ordem do índice. Somente pode
existir um único índice clusterizado por tabela (geralmente é a chave
primária). Determina a ordem física do dado na tabela [5].
NonClustered: O dado não é classificado na ordem da chave Podem
existir vários índices associados à tabela (geralmente são as chaves
estrangeiras) [5].
23
1.2. ASPECTOS ESTRATÉGICOS PARA A CONSTRUÇÃO DE UM DATA
WAREHOUSE1.2.1. Planejamento
Um problema sério em projetos de data warehouse é um planejamento
defeituoso. O fato de todos concordarem que o projeto de um data warehouse não
se baseia em requisitos bem delimitados não significa que os projetistas não devam
planejar minuciosamente cada atividade do processo. E mais, tal planejamento deve
levar em consideração o fato de se tratar de um data warehousing mais que um data
warehouse: um processo sem fim para todos os efeitos práticos. Deve ser
considerado o longo prazo geralmente envolvido. Não se estará projetando uma
aplicação operacional, mas sim um repositório de informações gerenciais [9].
A operação do negócio tende a uma estabilidade grande. Um aplicativo
voltado para gerir essas atividades tende, portanto, a ser bastante estável, pelo
menos quando comparado às necessidades de informação para a tomada de
decisão. É aqui que a competitividade do mercado se faz sentir. As perguntas que
os executivos precisam ver respondidas hoje para tomarem suas decisões podem
ser substancialmente as de amanhã. Desse modo, um planejamento consistente
deve prever liberações parciais de dados, em curtos intervalos, de maneira que o
usuário cedo possa interagir com o ambiente, facilitando essa mudança inevitável de
requisitos. Os planejadores devem identificar muito cedo os alvos do projeto e seus
benefícios [9].
Recomenda-se que o data warehouse não comece muito ambiciosamente.
O primeiro projeto não deve levar mais que nove meses para estar operacional e
deve atingir basicamente as áreas de negócio mais importantes e que tragam
retorno direto e tangível. Com o tempo, ele será refinado e aumentado em sua
abrangência [29].
Um projeto de data warehouse deve ser conduzido com enfoque diferente de
um projeto de aplicações tradicional. A primeira etapa é identificar os objetivos da
24
organização, sob a óptica de seus executivos. A empresa pretende crescer dentro
de seu segmento de negócio? Ou pretende expandir seu market-share ? Depois, são
identificados os processos de negócio diretamente relacionados com esses
objetivos. A seguir, definem-se as informações que são necessárias para suportar
esses processos de decisão. Onde essas informações serão obtidas? As
especificações técnicas aparecem no final, quando então se desenham as
alternativas tecnológicas para a sua total implementação [30].
1.2.2. Necessidades Das Empresas
No princípio haviam sistemas simples de automação. Então vieram sistemas
de banco de dados e sistemas on-line. Em um tempo muito pequeno o computador
tinha achado seu modo de incorporar-se ao cotidiano das empresas. De quase
nenhum computador nos anos cinqüenta para milhões de computadores de todo
tipo e tamanho nos anos oitenta, o mundo da tecnologia explodiu além de qualquer
previsão a uma taxa de crescimento que parecia ser impossível acreditar [13].
Os sistemas de computação iniciais foram projetados para processar as
transações diárias da corporação. Decisões imediatas eram o enfoque destes
sistemas pioneiros. Com o advento dos primeiros sistemas, veio um subproduto de
dados. Estes dados refletiam as atividades que estavam acontecendo e cresceram
à medida que o tempo passava e de como o negócio era administrado [13].
Logo, a quantidade de trabalho exigiu manter as aplicações ao ponto em
que 95% do trabalho era dedicado à manutenção de programas. Ao mesmo tempo
em que o fardo de manutenção estava crescendo, os usuários finais estavam
ficando frustrados com a inabilidade dos sistemas de informação da organização em
responder às necessidades de informação. Caso após caso, os usuários finais
sabiam que os dados de que eles precisavam estavam disponíveis mas difíceis de
serem obtidos. Ainda, em cada caso, o departamento de sistemas de informação
25
dava uma ou outra justificativa do porquê de os dados não poderem ser acessados.
Usuários finais sentiam-se abandonados e frustrados [13].
Então, o data warehouse foi criado. O data warehouse transferiu os dados do
ambiente transacional, armazenando-os e organizado-os de forma que o usuário
final poderia obter a informação pela qual tanto ansiava. Afinal, os dados estavam
disponíveis em uma base para que o usuário processasse suas próprias consultas
[13].
O data warehouse representou uma troca fundamental na concepção de
sistemas de informação e introduziu alguns conceitos novos importantes: [13]
Dados devem ser integrados através da empresa [13].
Dados sumarizados tem um grande valor para a organização [13].
Dados históricos são a chave para compreender os dados ao longo do
tempo [13].
Metadados representam um papel muito importante na infra-estrutura do
data warehouse [13].
Muito importante manter a precisão dos dados históricos com o passar
do tempo [13].
Além de resolver alguns problemas muito importantes para a corporação, a
criação do data warehouse aliviou o fardo do programador de aplicação em tentar
transformar o ambiente de sistemas legado em um sistema para a tomada de
decisão. As solicitações dos usuários e a manutenção das aplicações, pela primeira
vez, tornaram-se gerenciáveis [13].
O objetivo básico do data warehouse deve ser adicionar valor ao negócio. À
medida que as regras do negócio são incorporadas às aplicações, exige-se rapidez
cada vez maior nas respostas. O ambiente de negócios é crescentemente dinâmico.
Responder com rapidez ao como, quando e quanto passa a ser decisivo para a
empresa sobreviver e crescer nesse cenário [30].
26
As organizações hoje em dia estão enfrentando enormes pressões para
prever informações de melhor qualidade para tomada de decisões, em formatos de
fácil acesso e manipulação. Em poucas palavras, as empresas precisam se tornar
mais ágeis em sua capacidade de utilizar as enormes quantidades de dados no
esforço de proporcionar melhor suporte ao cliente [32].
Um data warehouse reconhece o valor estratégico do gerenciamento
intencional do bem corporativo de dados. A ênfase no data warehouse reflete o
reconhecimento de que a exploração de dados é o caminho para vantagem
competitiva, novas oportunidades de negócios, e melhoria no serviço ao cliente. Ela
também reconhece que os sistemas tradicionais de gerenciamento de base de
dados estão geralmente assoberbados pelo enorme volume de dados que lhes são
confiados. Como resultado, os sistemas de extração de informações que trabalham
com a totalidade das bases de dados geralmente funcionam mal [32].
O data warehouse e a arquitetura associada a ele providencia o objetivo
para lutar contra os mais variados desafios confrontados nos sistemas de
informações gerenciais de hoje [14].
Em outras palavras, o data warehouse permite o gerenciamento para
considerar resultados no contexto. Sem a armação do data warehouse e sua
arquitetura associada é uma tarefa quase impossível formar sentido para os diversos
resultados obtidos [14].
Os sistemas de informações (IS) gerenciáveis encontram a noção da
arquitetura indispensável no movimento da corporação dentro de um mundo de
processamento de informação efetiva. Em particular, o IS gerenciável usa a
arquitetura como um guia para o gerenciamento, como o seguinte: [14]
uso da armazenagem e aquisição [14]
tecnologia adequada com processamento necessário [14]
gerenciamento de orçamento [14]
mudança de tecnologia e plataforma [14]
27
informações derivadas do ambiente de produção [14]
determinação das responsabilidades organizacionais [14]
desenvolvimento de relatórios da arquitetura [14]
definição da interface entre as diferentes unidades organizacionais [14]
gerenciamento de gráficos organizacionais como a responsabilidade no
processamento da informação concernida [14]
gerenciamento do impacto na arquitetura no desenvolvimento do
processo [14].
Afinal, é antigo o enfoque por trás da idéias do depósito, galpão ou armazém
de dados extraídos dos muitos sistemas de produção – geralmente “ legacy systems”
– das companhias: transformar o dado cru em informação, para obtenção de
vantagem competitiva. [2]
Data warehouse é entendido como uma “enabling technology”; uma
tecnologia-meio, que favorece a tomada de decisões ao separar sistemas de
informações para decisão dos dados de produção. Essa divisão dos dados permite,
dizem os entusiastas, melhor alocação e administração de recursos; enquanto que a
proliferação de ferramentas sofisticadas de acesso possibilita combinar várias fontes
de dados de estruturas distintas e concretiza, assim, antigas promessas de gerência
participativa e menor concentração de poder decisório [2].
1.2.3. Hierarquia Clássica Da Informação Na Empresa
Pirâmide com três níveis: [33]
1º Nível (Topo da Pirâmide) é o Nível Estratégico: EIS-Sistema de
Informações Executivas [33].
2º Nível (Meio da Pirâmide) é o Nível Tático: DSS-Sistema de Suporte a
Decisão [33].
3º Nível (Base da Pirâmide) é o Nível Operacional: Sistemas Operacionais
[33].
28
O patrocínio efetivo da alta administração da empresa é crítico. E esse
patrocínio não pode se revelar apenas na hora de assinar o cheque. A empresa
precisa fornecer os analistas do negócio, aqueles técnicos que conhecem
profundamente a informação e o negócio da empresa [9].
Drivers para data warehousing: [31]
Operacional [31]
Substituir relatórios feitos no mainframe [31].
Dar ao usuário o acesso direto aos dados [31].
Atualizar o sistema [31].
Tático [31]
Explorar novos recursos e funcionalidades de análise de dados [31].
Fornecer melhores informações para o processo de decisão
gerencial [31].
Melhorar o conhecimento da empresa sobre seus dados [31].
Estratégico [31].
- Competitividade [31].
Time-to-market [31].
Qualidade de produtos e serviços [31].
Mercado global (pressionando preço e qualidade) [31].
- Quebra de paradigmas [31].
Privatização [31].
Novos mercados [31].
1.2.4. Motivação Da Empresa No Mercado
O verdadeiro impulso para a utilização da tecnologia de data warehouse
começou quando as pessoas perceberam que as informações disponíveis no data
warehouse poderiam ser utilizadas para a obtenção de vantagem competitiva. Esta
informação apoiou a habilidade da corporação em atrair e manter parte do mercado,
29
reduzir despesas e aumentar as vendas. Estes atributos elevaram o data warehouse
para a vanguarda de sistemas de informação, tornando-o promissor tanto para o
profissional técnico da informação quanto para o profissional da área de negócios
[13].
Estamos vivendo o início da era da informação. Nela os grandes desafios
são a integração dos processos operacionais entre as empresas e o gerenciamento
do negócio através da análise dos fatos para identificação de oportunidades [25].
1.2.5. Necessidades e Benefícios Para o Usuário
A necessidade principal do usuário é a transformação dos dados em
informações [13].
Embora o seu uso ainda seja incipiente, alguns resultados positivos parecem
demonstrar que realmente o data warehouse produz um alto retorno sobre o
investimento. A grande vantagem de um data warehouse é permitir a tomada de
decisões baseadas em fatos. Na verdade, ele busca disponibilizar à organização o
grande volume de dados que foram e estão sendo armazenados em bases de dados
operacionais, espalhadas por toda a empresa [29].
O principal resultado de um data warehouse é, indiscutivelmente, a
facilidade de os gestores da empresa poderem tomar decisões rápidas, baseados
em informações mais consistentes [29].
Levantamentos realizados junto a usuários em âmbito mundial e local
atestam o sucesso dos projetos já implantados, nos quais os primeiros resultados
apontaram para: aumento do tempo dos tomadores de decisão (decision makers)
para a análise e tomada de decisão; eliminação de tarefas operacionais como
pesquisa e identificação dos dados necessários ao processo decisório; melhor
confiabilidade das informações devido à implantação de um elo integrador dos
dados transacionais; racionalização do fluxo de informações da empresa;
30
padronização dos conceitos de negócio; democratização das informações sobre o
desempenho do negócio [22].
1.2.6. Perfil Do Usuário Na Empresa Que Utiliza O Data Warehouse
O usuário, o formulador de perguntas, é o ponto mais crítico nos projetos de
data warehouse. Idealmente, os usuários devem ser membros da equipe de projeto,
desde o seu nascimento [9].
Os usuários finais do data warehouse tem alguns papéis específicos a
cumprir. Estes geralmente dividem-se em duas categorias: Suporte aos Papéis e
Tipos de Usuário [13].
Suporte aos Papéis: [13]
Cada interação do data warehouse deve ter um “Patrocinador Executivo” da
área de negócios da comunidade usuária que serão os primeiros beneficiários da
funcionalidade destas interações. O Patrocinador Executivo é especialmente
importante para o data warehouse. Ele define o escopo e requisitos do negócio e
analisa as necessidades de informação da organização para a tomada de decisão.
Existem, também, dois importantes papéis adicionais na comunidade de usuários
finais: Especialista do Assunto e Técnico de Apoio ao Usuário [13].
O Especialista do Assunto é quem facilita a comunicação entre os usuários
finais e a equipe técnica do data warehouse. Provê as informações para definir o
escopo de uma interação do data warehouse. Participa no projeto e revisão da
aquisição e capacidade de acesso aos dados. Assiste o treinamento de outros
usuários em seus grupos funcionais. Atua como suporte a outros usuários em suas
áreas [13].
O Técnico de Apoio ao Usuário provê apoio técnico global para os usuários
do seu departamento, grupo, linha de negócio, etc.; entende o ambiente técnico de
uma área específica do data warehouse, presta apoio como administrador de banco
de dados local e apoio técnico aos usuários locais [13].
31
Tipos de Usuário: [13]
São categorizados como: Usuários de Aplicações Pré-definidas, Usuários
com Acesso Limitado e Usuários com Acesso Ilimitado [13].
Os Usuários de Aplicações Pré-definidas não possuem um nível alto de
experiência técnica mas estão, tipicamente, em um nível relativamente alto dentro
da estrutura de administração de uma organização. Eles também são,
freqüentemente, assistentes administrativos. Acessam o data warehouse através de
consultas pré-definidas que atendem aos seus requisitos de negócio [13].
Os Usuários com Acesso Limitado são a maioria dos usuários analíticos.
Requerem caminhos pré-definidos de acesso ao data warehouse como, por
exemplo, uma ferramenta OLAP para facilitar o acesso e tem conhecimento em drill-
up/down. Tipicamente oferecem apoio aos pedidos de informação da administração
superior [13].
Os Usuários com Acesso Ilimitado são os “exploradores”, altamente
habilitados tecnicamente no acesso aos dados, precisam de ferramentas poderosas,
procedurais e não ferramentas simples e limitadas. Freqüentemente desenvolvem
aplicações para uso por outros tipos de usuários e, tipicamente, são um número
pequeno de usuários. Oferecem apoio às exigências organizacionais para relatórios
complexos [13].
Pode parecer desnecessário identificar os papéis chaves que os usuários
executam no desenvolvimento e gerenciamento de um data warehouse. Entretanto,
muitas organizações não têm reconhecido a importância que os usuários exercem
durante esse desenvolvimento e, conseqüentemente, perderam a visão da
importância em conduzir a evolução do data warehouse através das necessidades
de negócio do usuário. O resultado é normalmente um enfoque tecnológico ao data
warehouse e não um enfoque do usuário, resultando em um ambiente de informação
que não atinge as necessidades da organização para a análise e suporte à decisão
[13].
32
De patrocinador da funcionalidade de negócio para um executivo que precisa
monitorar as tendências em uma métrica importante do negócio; de perito de
assunto para um usuário técnico altamente qualificado para a obtenção ocasional da
informação, usuários têm papéis distintos e importantes a executar na evolução do
data warehouse de forma que podem continuar satisfazendo suas exigências de
informação sobre o negócio. Usuários também tem uma responsabilidade
significativa como “bons cidadãos corporativos” para trabalhar com a equipe do data
warehouse para assegurar-se de que o data warehouse continuará agregando valor
à organização através de uma importante ferramenta tática e estratégica de análise
e acesso à informação [13].
Um ingrediente essencial para o sucesso do ambiente do data warehouse é o
fator humano. O melhor projeto e a melhor arquitetura no mundo não são bem
usadas se não existirem pessoas capazes e preparadas para colocarem os planos
em ação [14].
O ambiente do data warehouse é administrado por uma unidade
organizacional chamada grupo de arquitetura de dados. O grupo de arquitetura de
dados algumas vezes faz parte da administração de dados. [14].
Em outros casos, o grupo de arquitetura de dados permanece sozinho. O
grupo de arquitetura de dados está próximo do grupo de sistemas ou do grupo de
aplicações [14].
O grupo de arquitetura de dados possui interface com o topo gerencial,
gerência do IS, da organização do IS e com o usuário final. O grupo de arquitetura
de dados ultimamente é responsável para o sucesso ou falha do data warehouse
[14].
1.2.7. Análise Do Ambiente Legado
Situada entre o ambiente operacional, o data warehouse e o depósito de
dados operacionais está a interface de integração e transformação dos dados. Esta
33
interface é o local onde o dados não integrados do ambiente operacional são
integrados e enviados ao data warehouse [13].
As tecnologias de sistemas gerenciadores de bancos de dados que
normalmente alojam as aplicações do legado mais antigas, usualmente requerem
que os dados sejam acessados na forma de um registro por vez. Esta abordagem
requer lógica de programa que é familiarizada com a maneira com que os dados são
armazenados. Em muitos casos, o dados provenientes de muitas áreas de assunto
diferentes são amarrados e controlados pelas aplicações. A execução da integração
e transformação dos dados torna-se um problema complexo decorrente do grande
volume de dados armazenados no ambiente de aplicações do legado. A integração
e transformação dos dados a serem carregados no data warehouse são um dos
aspectos mais importantes e devem ser cuidadosamente gerenciados [13].
Como todo o data warehouse depende dos dados disponíveis nas bases de
dados operacionais da empresa, o primeiro passo para sua construção é o
mapeamento dessas bases, sua limpeza e sincronização com as demais camadas.
Para isso, é extremamente necessário conciliar em um único ambiente a
administração de todas as bases de dados operacionais que são fonte de
alimentação para o data warehouse com a administração do data warehouse em si
[22].
Criar um data warehouse não é uma simples questão de escolha de banco
de dados ou ferramentas, mas envolve planejamento e modelagem (aspectos que
garantem a qualidade dos dados, fator crítico para o sucesso do projeto), escolha de
ferramentas e atualização e refinamento contínuos. É, de fato, uma arquitetura
completa e que se compõe dos seguintes elementos principais: bases de dados
operacionais, que são as fontes primárias das informações; processos de extração e
conversão de dados; bancos de dados específicos para data warehouse; recursos
de administração e ferramentas de inteligência de negócios, que facilitam o acesso,
manipulação e análise dos dados contidos no data warehouse [24].
34
Um armazém de dados é composto de três áreas funcionais distintas, cada
uma das quais deve ser customizada para satisfazer as necessidades do negócio. O
primeiro componente é a aquisição de dados, podendo ser de sistemas legados ou
de outras fontes quaisquer. Lá o dado é identificado, copiado, formatado e
preparado para ser carregado no armazém. O segundo componente do armazém é
o espaço de armazenamento e o terceiro é a área de acesso aos dados [26].
A busca pelas informações espalhadas pelas diversas aplicações e
plataformas tecnológicas, pode ser um problema muito sério. Mesmo que as
informações que vão preencher o data warehouse venham apenas de sistemas
legados baseados em mainframes, o que nem sempre ocorre, a diversidade de
tecnologias envolvidas é grande. Uma recente pesquisa mostrou que apenas 25%
das informações desses sistemas estão em bancos de dados relacionais, como o
DB2. A grande maioria está espalhada por bancos de dados não relacionais,
arquivos VSAM, etc [29].
Um armazém de dados se propõe compatibilizar um número grande de
sistemas desintegrados oriundos do legado a uma coleção igualmente diversa de
tipos de estações de trabalho de usuário final. Os ambientes existentes normalmente
se compõem de um conjunto de hardware sortido, software e sistemas operacionais
incompatíveis e com características únicas a cada organização [26].
A maioria dos “armazéns de armazenamento” está sendo administrada por
bancos de dados relacionais sob plataformas Unix. De acordo com o Meta Group
Inc., Oracle, Sybase Inc., IBM Corp. e Informix controlam 65% do mercado de
“armazéns de armazenamento”; os vendedores de outros bancos de dados
relacionais e bancos de dados especializados são secundários nesse contexto [26].
Uma questão relevante será como integrar as diversas fontes de dados
legadas ou não, arquivos VSAM, DB2, CA-IDMS, CA-DATACOM, OpenIngres,
Oracle, Informix, Sybase e mais uma infinidade de outras fontes. A resposta:
35
utilizando gateways que tenham as características de transparência e confiabilidade
para sustentar o ambiente de data warehouse [20].
O assunto mais óbvio relativo à interface de integração e transformação
refere-se às tecnologias utilizadas pelos sistemas transacionais encontradas no
ambiente legado (às vezes chamado de ambiente fonte) como, por exemplo, as
tecnologias que são, na maioria dos casos antigas, orientadas à transações e
complexas: IMS (Information Management System) – um sistema gerenciador de
banco de dados hierárquico desenvolvido pela IBM para ambientes mainframe,
VSAM (Virtual Storage Access Method) – arquivo indexado desenvolvido pela IBM
para ambientes mainframe, IDMS, Adabas, Oracle, Sybase, Informix, Arquivos
Seqüenciais, etc [13].
1.2.8. Equipe De Desenvolvedores
O crescimento do data warehouse criou a necessidade de disciplinar o
gerenciamento do mesmo que é o papel do administrador do data warehouse
(DWA). O DWA é parte administrador de dados, parte administrador de banco de
dados, deve posicionar-se um pouco como usuário final, um pouco programador de
sistemas e muito de programador e projetista de aplicação [13].
O administrador do data warehouse é um disciplinador organizacional que
apareceu com o advento do data warehouse e dos sistemas de apoio à decisão. Ele
é o principal responsável para o sucesso contínuo do armazém de dados [13].
O administrador do data warehouse deve conhecer as várias habilidades
abaixo descritas: [13]
Projetista da Base de Dados: projeta e constrói o data warehouse [13].
Modelador de Dados: integra um novo data warehouse em um já
existente [13].
Desenvolvedor : que mantém, nos programas, novas integrações e
transformações de dados [13].
36
Político: solicita e negocia os recursos necessários para a construção do
data warehouse [13].
Programador de Sistemas: capacidade de planejamento e refinamento do
data warehouse [13].
Usuário final: deve entender as necessidades das áreas de negócio da
empresa como, por exemplo, financeira, gerência de vendas, atuarial,
engenharia, etc. [13].
Em alguns casos, o administrador do data warehouse não somente deve
possuir as habilidades acima mas estar apto a executá-las. Em suma, o
administrador do data warehouse é responsável por um ambiente inteiro de suporte
à decisão que é o fator crucial para o sucesso da corporação [13].
O Administrador de Data warehouse (DWA) é o responsável pelo data
warehouse, envolvendo obter, agendar e coordenar o trabalho entre os recursos
humanos, preparando relatórios de situação, orientando revisões de design,
garantindo que membros de equipes de trabalho e usuários finais estão sendo
efetivamente treinados, e gerenciando outras atividades relacionadas ao Data
warehouse como especificado pela gerência da organização [13].
O Administrador de Banco de Dados é essencial na organização da equipe
de data warehouse, em número suficiente e dedicados em tempo integral. As
diferenças entre os sistemas de informação e operacional da empresa devem ser
acompanhadas pelo Administrador de Banco de Dados [13].
O Gerenciador de Metadados deve assegurar que os metadados no
Subdiretório de Informações está sincronizado com a produção de recursos, regras
de negócio na obtenção de dados, e regras de negócio norteando o acesso dos
dados, bem como fontes de conceito de metadados como ferramentas CASE e
novas aplicações em desenvolvimento [13].
37
1.2.9. Aspectos Da Implementação Física (Rolap/Molap)
Quanto à localização dos dados a serem utilizados na análise, atualmente
existem duas abordagens: [6]
Um banco de dados multidimensional especializado [6].
Um data warehouse implementado com a tecnologia de banco de dados
relacional, mas otimizado para a tarefa de análise: Nesse caso, os dados
são modelados utilizando um esquema projetado para balancear
desempenho e volume de dados. Normalmente é utilizada uma
representação desnormalizada da conhecida por esquema estrela [6].
Sistemas OLAP que implementam a primeira abordagem são chamados de
MOLAP (Multidimensional OLAP) e aqueles que implementam a segunda são
chamados de ROLAP (Relacional OLAP) [6].
Em um banco de dados MOLAP, os dados são mantidos em arranjos e
indexados de maneira a prover um ótimo desempenho no acesso a qualquer
elemento. O indexamento, a antecipação da maneira como os dados serão
acessados e o alto grau de agregação dos dados fazem com que sistemas MOLAP
tenham um excelente desempenho. Além de serem rápidos, outra grande vantagem
desses sistemas é o rico e complexo conjunto de funções de análise que oferecem
[6].
Existem algumas limitações nos sistemas MOLAP. Bancos de dados
multidimensionais são sistemas proprietários que não seguem padrões (linguagem,
Application Program Interface, etc.) estabelecidos pela indústria de banco de dados.
Isso se torna uma desvantagem para tais sistemas, uma vez que a arquitetura não é
aberta. A utilização das estruturas dimensionais adotadas também traz algumas
desvantagens. Mudanças do modelo dimensional requerem uma reorganização do
banco de dados, e a estrutura de cubos não suporta a criação ad hoc de visões
multidimensionais. Além dessa falta de flexibilidade, sistemas MOLAP enfrentam
problemas quanto à escalabilidade porque um dos recursos para garantir o
38
excelente desempenho é manter os índices dos arranjos na memória e isso acaba
limitando banco de dados multidimensionais a 20 ou 30 gigabytes de dados,
tornando-se, dessa maneira, mais apropriados para data marts ou organizações com
pequenos data warehouses [6].
Sistemas ROLAP fornecem análise multidimensional de dados armazenados
em uma base de dados relacional [6].
A principal vantagem de se adotar uma solução ROLAP reside na utilização
de uma tecnologia estabelecida, de arquitetura aberta e padronizada como é a
relacional, beneficiando-se da diversidade de plataformas, escalabilidade e
paralelismo de hardware [6].
Quanto às limitações, podemos citar o pobre conjunto de funções para
análise, a inadequação do esquema estrela para atualização dos dados e as
soluções proprietárias para metadados que acaba por anular muitas das vantagens
da tecnologia relacional [6].
MOLAP ou ROLAP? Qual escolher? Atualmente existe um grande debate
sobre essa questão e, se possível, esse debate deve ser deixado para os
fornecedores. Para quem utilizará a tecnologia, o mais importante é entender os
negócios da empresa para então decidir pela solução que melhor atende o volume
de dados e as necessidades de análise da empresa [6].
Provavelmente esse debate não terá um vencedor. Já se percebe que existe
uma convergência dessas duas tecnologias. Fornecedores MOLAP têm adicionado
funcionalidade ROLAP nos seus produtos e, igualmente, fornecedores ROLAP têm
enriquecido a funcionalidade e desempenho de seus servidores [6].
1.2.10. Performance
A duração de tempo desde o momento em que um pedido é emitido até o
primeiro resultado recebido [13].
39
A maioria das consultas dos usuários precisam processar rápida e
eficientemente. O administrador do data warehouse é responsável pela performance
de carga de dados, criação de índices e manutenção de metadados, itens
importantes ao analisar a performance [13].
A maioria dos projetos de data warehouse residem em um sistema
gerenciador de banco de dados separado do ambiente OLTP, com um processador
dedicado, disco e memória. Esta separação é o melhor ambiente porque,
certamente, alivia o processamento e proporciona, ao administrador do data
warehouse, liberdade para projetar as bases de dados e suporta uma estrutura de
acesso específica para um ambiente de data warehouse onde as consultas são
variadas [13].
1.2.11. Segurança
Proteção dos dados em um banco de dados que gerencia os acessos com
ou sem autorização. Há níveis diferentes de segurança conforme o perfil do usuário
[13].
O problema de proteger as informações do data warehouse é normalmente
colocado em segundo ou terceiro plano. Temos que saber quem está acessando as
informações, de onde e como se está manuseando. Os bancos de dados têm seus
esquemas de segurança, porém eles não conseguem resolver todos os problemas.
É necessário procurar uma solução que realmente consiga evitar que os intrusos e
curiosos consigam tirar proveito dessas informações. Se essa ferramenta for
integrada junto com outras soluções de gerenciamento de recursos, será ainda
melhor. Uma estrutura por exemplo, que integre em uma única interface todas as
disciplinas de gerenciamento, incluindo segurança, backup, redes, distribuição de
software e help-desk será uma solução muito próxima do ideal [20].
40
2. DESENVOLVIMENTO
De acordo com o embasamento teórico do nosso trabalho, iniciamos o
desenvolvimento das etapas do nosso roteiro. Essas etapas estão em uma ordem
seqüencial, algumas delas podem ser realizadas paralelamente a outras ou a ordem
pode ser alterada, de acordo com a necessidade; isso será definido pela equipe que
está elaborando o projeto. Sugerimos essa seqüência pois facilita o entendimento do
objetivo do projeto e descreve etapas interligadas e fundamentais para o sucesso do
mesmo. Abaixo apresentaremos o roteiro em uma forma esquemática para prover,
ao leitor, uma ampla visualização das etapas do projeto:
1. Fatores críticos de sucesso.
2. Definição da técnica para desenvolvimento de sistemas a ser utilizada.
3. Visualizar as necessidades do usuário.
4. Nova visão da informação para a tomada de decisões.
5. Análise do negócio a ser modelado.
6. Análise do ambiente legado.
7. Modelagem dimensional dos dados.
8. Aspectos da implementação física.
9. Aspectos da visualização das informações.
A seguir, iniciaremos o detalhamento de cada uma das etapas acima
seqüencializadas.
2.1. FATORES CRÍTICOS DE SUCESSO
Primeiramente, é de extrema importância elencar os principais itens que
determinarão o sucesso do projeto. Abaixo apresentamos alguns itens importantes:
1. É fundamental planejar o projeto.
2. É importante ter o orçamento aprovado para desenvolver o projeto de
acordo com o plano de investimento da empresa.
41
3. É importante que a empresa esteja disposta a modernizar-se para garantir
o crescimento e a competitividade.
4. É importante ter o apoio e o empenho dos usuários responsáveis e suas
respectivas gerências através de atitudes participativas e cooperativas.
5. É fundamental ressaltar a importância das informações para a empresa e,
em especial, o compartilhamento das mesmas, evitando duplicidade de
dados e informações proprietárias.
6. É necessário negociar um acordo com a alta administração referente à
proposta de implementação do projeto.
7. É importante primeiro analisar as áreas de atuação mais lucrativas da
empresa.
8. É importante analisar a contenção de custos.
9. É imprescindível que as informações sejam precisas, consistentes e
rápidas de obter.
10.É importante ter a capacidade de adaptação às necessidades de negócio.
11.É necessário apresentar resultados entre as etapas do desenvolvimento
do projeto.
Após definirmos os fatores críticos de sucesso do projeto, devemos iniciar a
análise de qual técnica de desenvolvimento de sistemas mais se integra à
construção de um projeto de data warehouse.
2.2. DEFINIÇÃO DA TÉCNICA DE DESENVOLVIMENTO DE SISTEMAS A SER
UTILIZADA
É de extrema importância utilizar uma técnica para desenvolvimento de
sistemas para auxiliar no projeto do data warehouse. Indicamos a técnica da
Engenharia da Informação em virtude de os dados serem o enfoque principal desta
técnica e em um data warehouse o objetivo principal é a transformação dos dados
em informações.
42
Ao utilizar a técnica da Engenharia da Informação, torna-se mais fácil a
forma de visualização dos relacionamentos entre os requisitos básicos que
estruturam o negócio objeto de análise. Como produto principal desta técnica temos
o modelo de entidades e relacionamentos (MER). Um MER é válido e confiável
quando consegue responder às perguntas dos processos que serão por ele
atendidos. Portanto é um modelo obrigatório em qualquer desenvolvimento de
sistemas até porquê é requisito básico para a implementação física das bases de
dados.
Esta técnica sugere que devemos identificar os objetivos da organização ,
sob a óptica de seus executivos, por exemplo: “ a empresa pretende crescer dentro
do seu segmento de negócio? Devemos identificar os processos de negócio
diretamente relacionados a esses objetivos, com base nas prioridades emergentes
da empresa sempre associadas com as prioridades reais dos negócios da empresa,
por exemplo: clientes, finanças, vendas, produção, etc.
Tendo definida e assimilada a técnica de desenvolvimento de sistemas a ser
utilizada no projeto, é importante entender quais são as necessidades do usuário,
diferenciando-as entre o ambiente analítico e o operacional.
2.3. VISUALIZAR AS NECESSIDADES DO USUÁRIO
O usuário é o fator chave para o sucesso do projeto. Sua participação efetiva
durante todo o projeto é o requisito mais importante pois ele é quem domina a área a
ser analisada e irá dirimir as dúvidas do analista da informação que implementará o
projeto.
O usuário necessita de um sistema que forneça informações para que deci-
sões sejam tomadas de acordo com a análise destas informações. Um exemplo de
decisão estratégica é: analisar os padrões de consumo em um determinado período
para decidir a viabilidade ou não de criação de um novo produto. Há a necessidade
43
de entender a diferença entre os sistemas de processamento operacional e o ana-
lítico.
Sistemas de processamento operacional são sistemas que suportam as ope-
rações do dia a dia da empresa. São sistemas de processamento on-line atualizados
ao longo do dia. Exemplos: Sistema de Estoque, Sistema Contábil, Folha de Paga-
mento, etc. As informações refletem o momento atual [15].
Sistemas de processamento analítico disponibilizam informações usadas
para analisar um problema ou uma situação. É feito por meio de comparações ou
através da análise de padrões ou tendências. As informações refletem um instante
específico no tempo. Exemplos: mostrar como uma marca de um produto está sendo
vendida em diferentes estados; mostrar como uma marca específica de um produto
está sendo vendido desde que foi introduzido nas lojas; comparar as vendas dessa
marca de produto em diferentes localidades, etc. [15].
Tendo definidas e assimiladas quais são as necessidades do usuário, é
importante entender a mudança de enfoque em um projeto de data warehouse no
que se refere às informações para a tomada de decisões. Durante este processo, é
fundamental a participação do usuário e o pleno entendimento dele nesse novo
processo de análise da informação.
2.4. NOVA VISÃO DA INFORMAÇÃO PARA A TOMADA DE DECISÕES
O que buscamos quando estamos modelando sistemas de informação é o
entendimento operacional do negócio que está sendo modelado, sem pensar na
aplicação em si, sem pensar na tecnologia envolvida, mas com a visão relacional de
dados. Quando vamos executar uma modelagem multidimensional, estamos dese-
nhando soluções de gestão de negócios, buscando entender como os executivos e
gestores de uma organização avaliam as informações para adoção de estratégias e
avaliação de desempenho. A mudança de enfoque de “entendimento operacional do
negócio para entendimento da gestão do negócio” concentra e provoca diferença
44
acentuada na forma de se desenvolver um modelo de dados multidimensional. A
análise multidimensional requer um modelo de dados que permita que os dados
sejam facilmente visualizados através de diversas perspectivas. Mais adiante
apresentaremos como aplicar a modelagem dimensional.
Abaixo citamos um exemplo de uma nova visão da informação com a
utilização do data warehouse:
“O data warehouse é parte fundamental da solução, que analisa o
comportamento do cliente, informando em caso de desvio padrão. Durante testes
em um banco australiano, por exemplo, foi identificado um depósito que fugia aos
padrões do correntista. O banco entrou em contato com o cliente e descobriu que o
depósito fora um presente de casamento – o valor da quitação de uma casa. A partir
dessa informação, desenvolveu promoções para aquele cliente específico, que
conseguiu um empréstimo para acabar de montar sua casa [11]”.
O passo seguinte é como analisar a área do negócio a ser modelado.
2.5. ANÁLISE DO NEGÓCIO A SER MODELADO
Primeiramente definir os objetivos do projeto que podem ser resumidamente
descritos nos dois itens abaixo:
1. Disponibilizar as bases de dados do ambiente operacional (OLTP) para
um ambiente analítico (OLAP).
2. Permitir aos usuários a extração dos dados através de análise exploratória
no ambiente OLAP.
Definir o escopo do projeto, observando:
Caracterizar o problema: o dado deve ser representado como informação
para que a empresa possa tomar decisões.
Definir quais processos são mais críticos para o negócio e que precisam
de decisões sobre ele.
45
Assimilar o conhecimento e definição da área de atuação (negócio) do
cliente específico e tomada de decisão. É importante representar este
conhecimento em um modelo de entidades e relacionamentos pois será
muito útil na modelagem dimensional.
Definir grupo gestor da informação que irá participar durante todo o
processo de desenvolvimento do projeto. O grupo gestor pode ser
considerado como os usuários que dominam a área de negócio e que
tomam decisões, juntamente com o pessoal de informática.
É extremamente importante a definição do escopo do projeto pois é a base
do mesmo. No escopo deve ser descrito se a implementação será em um data
warehouse (base corporativa que atenderá toda a organização) ou em um ou vários
data mart`s (base de informação por linha de negócio que contém um sub-conjunto
dos dados corporativos da organização). Recomenda-se iniciar com data mart`s
integrando-os a um data warehouse ao longo do tempo. Isto justifica-se pelos
seguintes aspectos:
O custo é bem inferior a implantar um data warehouse de toda a
empresa;
O tempo de implementação é reduzido;
Mais fácil assimilar a atuação de uma área de negócio específica a
entender todo o processo da empresa.
Optando-se por implementar em data mart`s, deve-se ter o cuidado de não
esquecer a integração entre os data mart`s caso contrário o projeto é inviabilizado.
Tendo definida a área de negócio da empresa a ser implementada no
projeto, deve-se analisar onde estão as informações que alimentarão o data
warehouse / data mart(s). A origem destas informações é comumente chamada de
“legado”.
46
2.6. ANÁLISE DO AMBIENTE LEGADO
Partindo das necessidades de informação por área de negócio já estarem
definidas, nesta análise deve-se observar o seguinte:
Analisar o ambiente computacional da empresa como, por exemplo:
mainframe IBM, ambiente DOS, ambiente windows, ambiente UNIX, etc.
Se as informações necessárias estão armazenadas nos aplicativos
operacionais ou, caso contrário, manter os aplicativos operacionais para
que obtenham os dados que faltam. Verificar viabilidade deste tipo de
manutenção para gerar a informação que falta no sistema analítico.
Definir como integrar as várias fontes de informação, se houverem.
Um fator importante é como analisar as fontes de informação do ambiente
legado como, por exemplo: tipos de bancos de dados (relacionais, em rede,
hierárquicos), arquivos seqüenciais, planilhas, etc. Também é importante verificar os
modelos de dados, dicionários de dados dos sistemas do ambiente operacional,
relatórios gerenciais dos aplicativos, etc. Estas informações auxiliam muito a
construção do modelo dimensional.
É importante separar em quatro itens observando os questionamentos e
atividades em cada um deles segundo Felipe Machado [21]:
“ 1. Seleção de Dados:
Qual dado interessa?
Onde estão os dados?
Onde mais existe o dado?
Qual o ambiente de sistema gerenciador de banco de dados?
Qual dado é válido?
Qual período de existência ?
Qual o formato do dado?
Quantos formatos tem o dado?
2. Extração de Dados:
47
Qual a frequência de carga?
Validação da carga.
Gerência de dimensões: dimensões que sofrem alterações e é
necessário manter o histórico.
Validação de dado calculado.
Agregação de valores, indicadores.
Unicidade de extratores ou seja, se vários data mart´s utilizam a
mesma dimensão, o processo de carga deve ser único.
Gerência do processo.
3. Limpeza de Dados:
Redundância de nomes e endereços.
Códigos desconhecidos.
Unificação de códigos.
Validação de valores pré-calculados.
Unificação de nomes.
Padronização de conceitos.
Tratamento de valores nulos.
4. Transformação de Dados:
Validação de valores agregados.
Consolidação de regras de negócio.
Análise de formatos e tipos de dados “.
O grande fator de sucesso de projetos incrementais de data marts/ data
warehouse está na transformação, extração, preparação e limpeza dos dados.
Definir criteriosamente as necessidades, forma, fontes e as regras de mecanismos
de transformação como, por exemplo, a padronização do conteúdo dos dados.
Supondo que, no ambiente operacional, a informação sexo do cliente está, em al-
guns sistemas, como “F/M” e em outros “1/2”. Ao carregar esta informação no data
48
warehouse, deve-se definir um único padrão para conteúdo do mesmo dado orig-
inário de fontes distintas.
A próxima etapa do nosso roteiro é a construção da modelagem dimen-
sional.
2.7. MODELAGEM DIMENSIONAL DOS DADOS
Utilizaremos como técnica principal para a modelagem de dados
dimensional o star schema que é a técnica mais indicada para projetos de data
warehouse.
Muito importante é documentar o modelo de dados em uma ferramenta
CASE onde definem-se as tabelas, atributos, domínios, enfim, todas as informações
necessárias para garantir a plena documentação do modelo e facilitar a geração dos
esquemas físicos no banco de dados, principalmente em bancos de dados
relacionais.
Considere a seguinte afirmativa: “Nós vendemos produtos em vários merca-
dos e nós medimos nosso desempenho ao longo do tempo”.
O modelo de dados mais adequado para representar diversas relações entre
grandezas é o modelo dimensional. [15]
Para melhor visualizar as dimensões, abaixo representamos um “cubo”
propriamente dito com 3 dimensões:
49
TEMPO
MERCADOCada ponto do cubo
representa uma combinação de
Produto, Mercado e Tempo armazenado.
A seguir definiremos, os conceitos básicos que norteiam a modelagem
dimensional:
2.7.1. Dimensões
Representam as possíveis formas de visualizar os dados. São as entradas
para as consultas (tempo, região, cliente, etc). A base para entendimento de qual-
quer negócio é responder às quatro perguntas fundamentais abaixo:
1. QUANDO? (Período de tempo a que se refere a análise)
2. O QUÊ ? (O principal objeto de análise)
3. ONDE? (Localização física ou geográfica para análise)
4. QUEM? (Um objeto específico e detalhado para análise: opcional)
Dimensão mascarada: É aquela dimensão com pouquíssimas ocorrências.
Exemplo: Dimensão Tipo Cliente – Ativo ou Inativo. Não se cria uma tabela dimen-
são com essas ocorrências e sim usar esta dimensão como restrição na cláusula
where da consulta. No modelo pode ou não ser representada como uma dimensão
ligada à tabela fatos.
2.7.2. Fatos
É a tabela central que interliga as dimensões e tem os indicadores de análise
ou métricas (quantidade, valores,etc). A tabela fato deverá possuir, no mínimo, as
três primeiras dimensões. A pergunta “QUEM?” refere-se a um nível de análise
mais detalhado.
2.7.3. Exemplo de uma análise dimensional.
“Precisamos analisar a quantidade e valor faturado dos produtos de nossa
empresa em nossas lojas para medirmos nosso desempenho ao longo do tempo”.
Partindo da premissa acima que reflete a necessidade de informação do usuário, o
50
PRODUTO
projetista do data warehouse faz o primeiro esboço da modelagem dos dados de
acordo com as 4 perguntas fundamentais:
1. QUANDO : Período de tempo. De acordo com a necessidade de análise do
usuário. Pode ser: dia, semana, quinzena, mês, bimestre, trimestre, se-
mestre, ano, etc.
2. O QUÊ : Produtos oferecidos pela empresa.
3. ONDE : Lojas da empresa.
4. QUEM : Opcional. No exemplo acima essa pergunta não se encaixaria
pois não foi solicitada como objeto de análise. Porém, caso o usuário ne-
cessitasse saber quais os maiores clientes que efetuam compras de de-
terminados produtos, aí sim a informação Cliente se enquadraria na per-
gunta “quem”.
Até agora definimos os objetos de análise, no caso as dimensões de
consulta. Obviamente nenhum resultado aparente será apresentado combinando as
referidas dimensões pois o que está faltando são os fatos ainda não analisados em
nosso modelo. Os fatos ou medidas são o elo de ligação entre os vários tipos de
combinações de consulta entre as dimensões. É o que será medido, no caso o
faturamento e a quantidade de produtos. Sempre são definidos como números que
podem ser medidos, sumarizados e calculados. Em nosso exemplo, os fatos são:
quantidade de produtos e valor faturado.
Em seguida, projetaremos o modelo de dados utilizando a técnica star
schema, que consiste em uma tabela central (fatos), relacionada com as dimensões.
A estrutura final parece uma estrela, por isso a denominação da técnica. As tabelas
dimensões são tabelas independentes, ou seja, possuem uma única chave primária
e atributos que a identificam e que são utilizados para a consulta. São tabelas des-
normalizadas. A tabela fatos é uma tabela dependente das dimensões ou seja, sua
chave primária é a combinação das chaves primárias das dimensões e os atributos
51
para análise são os fatos ou medidas, no nosso exemplo o valor faturado e a
quantidade de produtos.
Obs: No exemplo abaixo da técnica star schema, as chaves primárias de cada
tabela estão em negrito.
Observação:
As chaves primárias das tabelas podem ser, um número seqüencial ou a própria
data da venda, código do produto e código da loja, desde que esteja garantida a
unicidade da chave primária em cada tabela dimensão e que o conteúdo histórico
esteja garantido, ou seja, se houve alteração posterior em uma determinada
venda em um determinado dia, é importante, nesse caso, gerar um número se-
qüencial na chave de tempo para garantir a posição antes da alteração. Caso a
chave fosse a própria data da venda, a alteração seria sobreposta. Um outro
exemplo seria o cliente em um pedido. Caso o mesmo cliente possua mais de
uma ocorrência no cadastro e cada uma em pedidos diferentes, nesse caso justi-
fica-se gerar um número único para identificar cada ocorrência do cliente. É claro
52
FATOS VENDAS
Chave_tempoChave_produtoChave_loja
Valor_FaturadoQuantidade_Vendida
DIMENSÃO TEMPO
Chave_tempo
Data_VendaDia_da_SemanaMesAno...
DIMENSÃO PRODUTO
Chave_produto
DescricaoMarcaCategoria...
DIMENSÃO LOJA
Chave_loja
NomeEnderecoCidadeUF...
que este tipo de análise depende de como é o processo específico do cliente.
Fica como sugestão importante a ser analisada.
2.7.4. Agregações
É um fator importante a analisar já que o principal objetivo de uma agregação
é prever um aumento de performance no acesso aos dados e reduzir o volume de
dados na tabela.
As agregações (ou sumarizações) consistem em gerar informações
redundantes a partir da informação de menor granularidade [15].
As agregações:
Fornecem níveis múltiplos de detalhe do fato [18].
Os resultados das queries (ou seus valores intermediários) são pré-
calculados, o que melhora muito a performance [18].
Podem ser acumuladas através de agrupamentos diferentes.
Freqüentemente através de várias dimensões ou combinações de
dimensões [18].
Apresentaremos uma agregação com 2 dimensões segundo Valsoir Tronchin
Júnior [18]:
53
Tempo
Data da Transação
Loja
Número da LojaNome da LojaCidadeEstadoPaísTelefone
Agregação das Vendas da Loja
Número da LojaData da TransaçãoNúmero de ClientesQuantidade de ProdutosValor das Vendas
Agregam-se vários fatos por Loja por Dia:
Número de clientes - Quantos clientes fizeram compras?
Quantidade de produtos - Quantas unidades de produtos foram vendidas?
Valor da venda - Qual foi o faturamento bruto do dia?
2.7.5. Metadados
Metadados são dados sobre dados que podem ser entendidos como
verdadeiros documentadores dos dados que compõem um data warehouse.
Os metadados armazenam diversas informações sobre dados armazenados
no data warehouse. Estas informações são armazenadas em um repositório que tem
como objetivo principal documentar e administrar os metadados.
Os metadados englobam o data warehouse e mantém informações sobre a
estrutura dos dados, as fontes de dados, a transformação dos dados, as rotinas de
extração de dados, o modelo de dados, relacionamentos e demais informações
pertinentes a dar significado ao dado.
Recomenda-se a utilização de uma ferramenta CASE para documentação dos
processos, modelos de dados, dicionário de dados, domínios de atributos e geração
dos esquemas físicos no banco de dados.
2.7.6. Resumo das etapas para a modelagem dimensional.
A seguir apresentamos, resumidamente, as etapas importantes a serem
seguidas na modelagem dimensional.
1. Obter a necessidade executiva: qual o negócio objeto de gestão.
2. Entender quais são os indicadores de valor do negócio definindo as
métricas de controle.
3. Descrever em um modelo de dados conceitual o negócio.
4. Se houverem modelos de relatórios do ambiente operacional: simular.
5. Definir o que descreve o negócio: dimensões.
6. Definir a organização da dimensão tempo: qual a menor unidade de
tempo.
7. Trabalhar com o conceito de hierarquia nas dimensões de consulta: Por
exemplo uma hierarquia na dimensão tempo: Dia -> Mês -> Trimestre ->
Semestre -> Ano
54
8. Definir a tabela fatos.
9. Montar o star schema.
A modelagem dimensional é aplicada para visualizarmos os dados
referentes às necessidades do usuário para obtenção da informação em um sistema
analítico. O modelo de dados dimensional independe de qual banco de dados será
implementado (ROLAP ou MOLAP).
2.8. ASPECTOS DA IMPLEMENTAÇÃO FÍSICA
Um data warehouse exige grande capacidade de armazenamento e
processamento dos dados, pois armazena dados analíticos, destinados às
necessidades de tomada de decisão. Estes dados podem ser armazenados tanto
em um banco de dados relacional (ROLAP) quanto em um multidimensional
(MOLAP). A diferença básica é que em uma estrutura ROLAP devemos criar vários
índices atrelados às tabelas fatos e dimensões para um acesso mais rápido e
eficiente ao banco de dados enquanto que em um banco multidimensional somente
precisamos informar quais são as dimensões e os fatos e o próprio banco
encarrega-se de gerar os cubos.
A seguir levantaremos alguns aspectos importantes a serem considerados
prevendo a implementação física do data warehouse.
2.8.1. Levantamento de volumes de dados
Como visto anteriormente, é necessário analisar a necessidade de sumarizar
os dados (agregações). Um fator importante é que as agregações reduzem o
volume de dados considerando que um sistema para tomada de decisões
geralmente não analisa o dado em nível detalhado pois esta informação já se
encontra no ambiente operacional (OLTP). O volume de dados a ser carregado e a
previsão de crescimento é fator importante ao decidir qual tipo de banco de dados
55
será utilizado (MOLAP ou ROLAP). Um banco MOLAP não suporta eficientemente
um volume muito grande de dados.
Abaixo está representado um exemplo de gerenciamento de agregações
com relação ao volume de dados segundo Valsoir Tronchin Júnior [18]:
Evite a explosão exponencial. Por exemplo: explosão do número de
linhas da tabela de agregação (n!) em um caso de análise com as
seguintes informações: 100 lojas, 25 categorias de produtos, 50 tipos de
clientes e dados de 1 ano.
Ao analisar o volume de dados na tabela fatos, há de considerar o
crescimento no número de linhas na tabela, número de dimensões associadas e
qual o nível de detalhe desejado. Muitas vezes, é importante analisar a necessidade
de separar a tabela fatos em outras tabelas menores ou em agregações em nível
mais alto. Abaixo exemplificaremos o volume de dados na tabela fatos considerando
somente o valor das vendas diárias por loja e produto:
Armazenar, no mínimo, os últimos 3 anos (previsão de 1.095 dias).
Número de Lojas: 100
Número de Produtos: 400
Fatos = 1.095 x 100 x 400 => 43.800.000 linhas na tabela fatos.
2.8.2. Periodicidade de Carga
As rotinas de extração dos dados do ambiente operacional devem ser
executadas de acordo com um esquema de processamento pré-definido. A
56
periodicidade de execução pode ser diária (inviável quando a extração necessita de
muitas fontes externas), semanal, quinzenal, mensal, etc.
Um fator importante a ser analisado com relação à periodicidade de carga é
a forte dependência com a área de negócio do usuário e da real necessidade de
análise da informação pois a informação urgente de hoje pode estar obsoleta
amanhã.
O volume de processamento é fator primordial para a criação de um
esquema de carga. Como o data warehouse possui carga incremental, recomenda-
se que criem-se os movimentos de dados originários do ambiente operacional e
carga no data warehouse fora do horário comercial de trabalho.
2.8.3. Tempo de Armazenagem dos Dados
De acordo com o volume de dados carregados de forma incremental no data
warehouse, é importante estimar por quanto tempo estes dados deverão estar
disponíveis na base de dados. O principal objetivo do data warehouse é manter o
histórico dos dados por um período de tempo necessário para a análise. Tudo
depende do tipo de negócio do cliente.
Geralmente a carga inicial do data warehouse corresponde a um volume
histórico de 3 anos (no mínimo) para dar um respaldo necessário ao processo
analítico. De acordo com o crescimento do banco de dados, é necessário gerenciar
o expurgo das informações não mais utilizadas em um determinado período de
tempo.
Caso o usuário quiser manter as informações por um período de tempo longo,
deve-se deixar claro que o custo de manutenção de hardware e software aumentará.
2.8.4. Controle de Backup’s
O administrador do data warehouse deve controlar como o backup das
bases de dados será efetuado (periodicidade, volume, dispositivos de
armazenamento, etc.). É importante verificar se há necessidade de copiar todo o
57
banco de dados ( visto que, em projetos de data warehouse muito grandes, o custo
desta atividade é alto e torna-se inviável) ou apenas um determinado período de
tempo.
É claro que o backup é importante e deve ser analisado. Vale a pena
verificar se as informações originárias dos sistemas transacionais para carga do data
warehouse são facilmente recuperáveis pelas rotinas de extração, aproveitando o
backup das bases operacionais (bancos de dados, arquivos sequenciais, etc) em
caso de problemas. Neste caso pode-se utilizar como backup os próprios arquivos
oriundos do sistema transacional com os movimentos (diários, semanais, mensais,
etc) carregados no data warehouse. Tudo depende de como gerenciar este
processo e analisar por quanto tempo o data warehouse pode ficar indisponível em
caso de recuperação do banco de dados e estimar quanto tempo levará a recarga a
partir dos backup’s operacionais. Este gerenciamento envolve os administradores do
data warehouse diretamente.
2.8.5. Análise de Performance
Indica-se a técnica star schema pelos principais motivos na implementação
física em um servidor ROLAP:
As tabelas fato contém a maioria das linhas de dados.
As tabelas dimensão tendem a ter um número menor de linhas.
Os joins (junções, relacionamentos) em um star schema tipicamente
envolvem uma tabela fato grande e uma ou mais tabelas dimensão
pequenas, o que torna a operação de consulta mais rápida.
Sempre consultar as tabelas fatos pelas entradas que são as dimensões.
Esquema altamente desnormalizado para melhorar performance.
A desnormalização provoca redundância e duplicação de dados, o que privi-
legia a performance em detrimento do consumo de espaço.
58
Uma análise importante refere-se aos índices a serem criados nas tabelas
fatos e dimensões quando da implementação em uma estrutura ROLAP. Os índices
são extremamente importantes pois permitem o acesso às informações de uma
maneira rápida visto que o processo de tomada de decisão pode envolver consultas
complexas que necessitem acessar um grande número de registros.
Geralmente criam-se índices das chaves primárias nas tabelas dimensão e
fatos mais outros atributos das dimensões necessários às consultas e também a
combinação de dimensões na tabela fatos. Ao criarmos índices em bancos de dados
relacionais devemos considerar a granularidade das informações, seletividade e
outros fatores pertinentes à estrutura do banco pois os bancos relacionais analisam
seu próprio plano de acesso antes de decidir acessar a estrutura de índices ou se é
mais eficiente dar um scan table (pesquisa em toda a tabela). Geralmente definem-
se índices clustered para cada chave primária. Este tipo de suporte é fornecido pelo
administrador do banco de dados (DBA).
Ao utilizarmos um servidor MOLAP (com um banco multidimensional), não é
necessário criar índices visto que a própria estrutura deste tipo de banco de dados
cria os cubos com todas as combinações possíveis das dimensões. Devemos
informar ao banco de dados quais são as dimensões e quais são os fatos. Esta
tecnologia multidimensional têm alta performance porém ocupa um alto espaço de
armazenamento dependendo do volume de dados da tabela fatos.
A tendência dos bancos de dados é reunir funcionalidades ROLAP e
MOLAP.
2.8.6. Segurança
Além de utilizar o esquema de segurança de logins do próprio banco de
dados (chaves autorizadas e o nível de acesso de cada uma), é importante que o
administrador do data warehouse tenha um controle do perfil de usuários com
autorização de acesso. Muitas ferramentas OLAP possuem um controle de
59
segurança próprios. Outra alternativa é o desenvolvimento de um aplicativo
específico de controle de usuários autorizados antes de executarem uma consulta
ao banco de dados onde reside o data warehouse/ data mart.
Após considerarmos os aspectos de implementação física mais importantes
do projeto, apresentaremos como as informações podem ser visualizadas pelo
usuário e como são as consultas.
2.9. ASPECTOS DA VISUALIZAÇÃO DAS INFORMAÇÕES
As ferramentas OLAP de visualização dos dados transformam números
enfadonhos em excitantes apresentações visuais. Provavelmente, as ferramentas de
visualização mais populares caem sob o título de sistemas de informação
geográficos. Estes transformam dados sobre lojas, indivíduos ou qualquer outra
coisa em mapas dinâmicos e de fácil compreensão [26].
A seguir exemplificaremos várias formas de fazer uma consulta ao banco de
dados através de queries simples, stored procedures e o exemplo de como uma
ferramenta OLAP monta o SQL para acesso ao banco de dados.
2.9.1. Queries Simples
São comandos SQL simples desenvolvidos pelo usuário fazendo o acesso
diretamente ao SGBDR e retornando as linhas acessadas em uma forma tabular.
Este usuário deve possuir um perfil técnico avançado na criação de consultas SQL.
Abaixo exemplificamos um comando SQL simples para acesso às informações de
um cliente específico.
select NomeCliente, Endereco, Telefone, Email from CADASTRO_CLIENTESwhere CodigoCliente = “XYZ”
Obs: Colunas com as informações : NomeCliente, Endereco, Telefone, Email.Tabela do banco de dados : CADASTRO_CLIENTESCritério de seleção : CodigoCliente = XYZ
60
2.9.2. Stored Procedures (sp)
Apresentaremos a mesma consulta acima efetuada com comandos SQL
simples, porém organizadas em uma stored procedure que fica armazenada no
banco de dados relacional e o acesso é mais rápido. Recomenda-se desenvolver
stored procedures quando as consultas são pré-definidas pelo usuário. No exemplo
abaixo transferimos o parâmetro de entrada (código do cliente) para a rotina e ele
retorna as colunas como parâmetros de saída. Obviamente várias consistências
devem ser feitas mas o exemplo é somente para entender a estrutura de uma stored
procedure. O nome da função será SP_ObterInformacaoCliente.
use <banco_de_dados onde a sp está armazenada>goif exists (select name from sysobjects where name = "SP_ObterInformacaoCliente") drop procedure SP_ObterInformacaoClientegocreate procedure SP_ObterInformacaoCliente@codigo_cliente char(10),@nome_cliente char(35) output,@endereco varchar(50) output,@telefone char(10) output,@email char(30) output,@msg_erro varchar(100) outputas declare @qtdlinhas int, @erro intselect @nome_cliente = NomeAtivEconomica,
@endereco = Endereco,@telefone = Telefone,@email = Email
from CADASTRO_CLIENTESwhere CodCliente = @codigo_clientereturn 0go
2.9.3. Ferramentas OLAP
Abaixo exemplificamos como uma consulta é feita pelo usuário através da
ferramenta OLAP Business Objects e o comando SQL gerado automaticamente pela
ferramenta. O banco de dados a ser acessado, no exemplo, é um ROLAP. O
projetista do banco de dados utilizou a técnica star schema como demonstrado na
ferra
61
menta para que o usuário possa visualizar as dimensões e os fatos conforme
apresentaremos na figura abaixo.
A referida consulta refere-se a uma base de dados da Secretaria Estadual da
Fazenda do Estado do Paraná onde o usuário pretende visualizar as informações de
quantidade e saldo por mês e atividade econômica no ano de 1999 no município de
Curitiba (101). O usuário solicita as informações das dimensões e dos fatos através
de comandos drag and drop (arraste e solte).
62
Dimensões: Delegacia Regional, Município, Atividade Econômica, Tempo
Fatos: GIA Gerencial
Comando SQL gerado automaticamente pela ferramenta na consulta:
SELECT TB_Tempo.MesRefGIA, TB_AtividadeEconomica.CodAtivEconomica,
TB_AtividadeEconomica.NomeAtivEconomica, sum(TB_F_GIA_Gerencial.QuantidadeGIA),
sum(TB_F_GIA_Gerencial.C11_VlrContabEntrEstado)FROM TB_Tempo, TB_AtividadeEconomica, TB_F_GIA_Gerencial, TB_MunicipioWHERE (TB_F_GIA_Gerencial.CodAtivEconomica =
TB_AtividadeEconomica.CodAtivEconomica ) AND ( TB_F_GIA_Gerencial.CodMunicipio=TB_Municipio.CodMunicipio ) AND ( TB_F_GIA_Gerencial.AnoBase=TB_Tempo.AnoRefGIA ) AND ( TB_Tempo.AnoRefGIA = 1999 AND TB_Municipio.CodMunicipio = 101 )
GROUP BY TB_Tempo.MesRefGIA, TB_AtividadeEconomica.CodAtivEconomica, TB_AtividadeEconomica.NomeAtivEconomica
63
Abaixo demonstraremos uma hierarquia implementada em um banco de
dados multidimensional (Arbor Essbase – MOLAP) segundo Felipe Machado [21]:
2.9.4. Aplicativos de Consulta
Muitas vezes o usuário solicita queries pré-definidas que, podem ser
armazenadas no banco de dados na forma de stored procedures ou gravadas de
acordo com o tipo de ferramenta OLAP. Por exemplo, na ferramenta Business
Objects, as queries dos usuários podem ser salvas em arquivos. Quando da
necessidade de consulta através da mesma query, o usuário abre o arquivo e faz um
refresh no banco de dados, retornando as informações atualizadas.
64
A viabilidade de construir um aplicativo de consulta é diretamente
relacionada às necessidades de informação do alto escalão da empresa
(presidência, diretoria, gerências). Obviamente estes funcionários não irão
desenvolver queries e sim desejam somente clicar em um ícone para obter a
informação. Nestes casos, um aplicativo de consulta que integra as queries pré-
definidas deve ser implementado prevendo a integração de novas consultas que são
executadas freqüentemente. Consultas esporádicas não se justificam implementar
em um aplicativo pois o usuário pode desenvolvê-las de acordo com sua
necessidade. Depende da análise do usuário se quer ou não implementar
determinada consulta em um aplicativo.
2.10. ESTUDOS DE CASOS REAIS (NECESSIDADES DO NEGÓCIO E
MODELAGEM DIMENSIONAL).
Nos estudos de caso que serão apresentados a seguir, demonstraremos as
necessidades de análise da informação sobre o negócio do cliente e a modelagem
dimensional utilizando a técnica star schema. Estas duas etapas do roteiro podem
ser consideradas como as mais críticas e complexas para o projeto, motivo pelo qual
estamos exemplificando o roteiro nestas etapas específicas. Nosso escopo, neste
exemplo de estudos de caso, parte do princípio de que a fase de modelo
dimensional dos dados é a que garante o sucesso do projeto pois o modelo deve
responder às necessidades do negócio. As demais fases também são importantes
porém são específicas de acordo com os objetivos tecnológicos de cada empresa.
Os estudos de caso referem-se a dois tipos de organizações: A SEFA/PR e
o CONPREVI .
A SEFA/PR possui vários sistemas de informação desenvolvidos e mantidos
pela CELEPAR. Muitos usuários necessitam de informações gerenciais referentes
aos parcelamentos de ICMS (Sistema TAP) e Arrecadação de ICMS.
65
O CONPREVI é uma instituição que serve aos tabeliâes do Estado do
Paraná para assegurar alguns benefícios como aposentadoria e pensões, através de
um sistema de recolhimentos mensais sobre o movimento de cada cartório. O
programa que gerencia a CONPREVI foi criado e é mantido pela Datatítulo Sistemas
Informatizados, com sede em Curitiba e especializada em ofícios de protesto de
títulos em todo o Paraná.
As necessidades de informação gerencial sobre estes sistemas serão
modeladas nos estudos de casos abaixo:
2.10.1. TAP – Termo de Acordo de Parcelamento
Necessidades do usuário:
“Precisamos analisar e acompanhar a evolução da concessão de parcela-
mentos de ICMS dos últimos 5 anos sob vários aspectos: tipo, modalidade e situa-
ção do parcelamento, município, agência de rendas e delegacia regional a que per-
tencem, bem como a atividade econômica dos contribuintes que efetuam
parcelamento. A análise, sobre os referidos aspectos acima mencionados,
considerará os valores parcelados, quantidade de parcelas concedidas, pendentes
em dia, pendentes em atraso, pagas em dia e pagas com atraso em um período de
tempo que refere-se a data de assinatura do parcelamento e a data da situação do
parcelamento para os casos de parcelamentos já baixados.”
Observação: Neste estudo de caso, a tabela fatos será única e conterá o item
mais baixo de detalhe que é a informação referente ao próprio parcelamento e não
agregações em outras tabelas fatos visto que o usuário têm necessidade de saber
quais são os parcelamentos específicos. Esta definição levou em conta um volume
de parcelamentos registrados no ambiente operacional nos últimos 5 anos,
suficiente para ser armazenado detalhadamente no ambiente OLAP. Este fator em
migrar ou não o dado detalhado deve sempre levar em conta o volume de dados e
66
crescimento dos mesmos ou então separar em outras tabelas fatos com agregações
pertinentes às consultas mais efetuadas.
67
Data_AssinaturaData_SituaçãoCódigo_DelegaciaCódigo_MunicípioCódigo_Ag_RendasCódigo_Ativ_EconomicaCódigo_Regime_PgtoCódigo_ModalidadeCódigo_Situacao_TAPCódigo_Tipo_TAPCódigo_Contribuinte
Número_TAPQtd_Parc_ConcedidasQtd_Parc_PendentesQtd_Parc_PagasQtd_Parc_VencidasQtd_Parc_Pagas_AtrasoValor_Imposto_ParceladoValor_CM_Imposto_ParceladoValor_Multa_ParceladoValor_CM_Multa_ParceladoValor_Juro_Vencido_ParceladoValor_Juro_Vincendo_ParceladoValor_Imposto_FCA_ParceladoValor_Multa_FCA_ParceladoValor_Atraso_Parc_PendenteSaldo_Residual_ImpostoSaldo_Residual_MultaSaldo_Residual_JurosValor_Imposto_PagoValor_Multa_PagoValor_Juro_Pago
DIMENSÃO TEMPO
Data_AssinaturaData_Situação
Mês_SituaçãoAno_AssinaturaAno_Situação
DIMENSÃO DELEGACIA REGIONAL
Código_Delegacia
Nome_DelegaciaEnderecoCepFoneMunicípio
DIMENSÃO ATIVIDADE ECONÔMICACódigo_Ativ_Economica
Descrição
DIMENSÃO MUNICÍPIO
Código_Municipio
Nome_MunicipioAno_InstalacaoAssociaçãoMicroregião
DIMENSÃO REGIME PAGAMENTO
DE PAGAMENTOCódigo_Regime_Pgto
Descrição
DIMENSÃO CONTRIBUINTE
Código_Contribuinte
Nome_ContribuinteCPFCNPJCadICMSEnderecoMunicípioInício_AtividadeFim_Atividade...
DIMENSÃO SITUAÇÃO PARCELAMENTO
Código_Situacao_TAP
Descrição
DIMENSÃO TIPOPARCELAMENTO
Código_Tipo_TAP
Descrição
DIMENSÃOMODALIDADE
Código_Modalidade
Descrição
DIMENSÃO AGÊNCIA RENDAS
Código_Ag_Rendas
NomeEnderecoFoneMunicípio
FATOS_TAP
2.10.2. Arrecadação Estadual de ICMS do Paraná
Necessidades do usuário:
“Precisamos analisar e acompanhar a evolução da arrecadação de ICMS dos
últimos 3 anos por data de pagamento por várias regiões do Estado considerando os
aspectos de tipos de receita e produtos, bem como a atividade econômica e regime
de pagamento dos contribuintes que recolhem ao Estado. A análise, sobre os
referidos aspectos acima mencionados, considerará a quantidade de recolhimentos
e os valores de imposto, multa, acréscimo, juros e total recolhido.”
68
Data_PagamentoCódigo_ReceitaCódigo_Ativ_EconômicaCódigo_Regime_PgtoCódigo_ProdutoCódigo_DelegaciaCódigo_MunicípioCódigo_Contribuinte
Qtd_RecolhimentosValor_ReceitaValor_MultaValor_AcrescimoValor_JurosValor_Total_Recolhido
DIMENSÃO TEMPO
Data_Pagamento
DiaMêsTrimestreSemestreAno
DIMENSÃO DELEGACIA REGIONAL
Código_Delegacia
Nome_DelegaciaEnderecoCepFoneMunicípio
DIMENSÃO ATIVIDADE ECONÔMICA
Código_Ativ_Econômica
Descrição
DIMENSÃO MUNICÍPIO
Código_Municipio
Nome_MunicipioAno_InstalacaoAssociaçãoMicroregião
DIMENSÃO REGIME DE PAGAMENTO
Código_Regime_Pgto
Descrição
DIMENSÃO RECEITA
Código_Receita
Descrição
DIMENSÃO PRODUTO
Código_Produto
Descrição
FATOS ARRECADAÇÃO
DIMENSÃOCONTRIBUINTE
Código_Contribuinte
Nome_ContribuinteCPFCNPJCadICMSEnderecoMunicípioInício_AtividadeFim_Atividade...
Analisando o perfil de consultas do usuário de acordo com suas necessi-
dades, percebeu-se que mais de 60% das consultas referem-se ao movimento men-
sal de arrecadação, não sendo uma necessidade imediata a análise por con-
tribuintes nestas consultas, portanto decidiu-se por criar outra tabela fatos da ar-
recadação com os valores agregados mensais. Ao construir uma agregação ganha-
se em performance pois os dados já estáo sumarizados mas perde-se em espaço no
banco de dados visto que as informações sumarizadas poderiam ser obtidas na
tabela fatos em nível de detalhe. Cria-se nesse caso, um tipo de “redundância” de
dados.
69
DIMENSÃO TEMPO
AnoMês_Pagamento
MêsTrimestreSemestreAno
DIMENSÃO DELEGACIA REGIONAL
Código_Delegacia
Nome_DelegaciaEnderecoCepFoneMunicípio
DIMENSÃO ATIVIDADE ECONÔMICA
Código_Ativ_Econômica
Descrição
DIMENSÃO MUNICÍPIO
Código_Municipio
Nome_MunicipioAno_InstalacaoAssociaçãoMicroregião
DIMENSÃO REGIMEDE PAGAMENTO
Código_Regime_Pgto
Descrição
DIMENSÃO RECEITA
Código_Receita
Descrição
DIMENSÃO PRODUTO
Código_Produto
Descrição
FATOSARRECADAÇÃO
MENSAL
AnoMês_PagamentoCódigo_ReceitaCódigo_Ativ_EconômicaCódigo_Regime_PgtoCódigo_ProdutoCódigo_DelegaciaCódigo_Município
Qtd_RecolhimentosValor_ReceitaValor_MultaValor_AcrescimoValor_JurosValor_Total_Recolhido
2.10.3. CONPREVI
O CONPREVI tem como negócio o recolhimento de contribuições mensais de
cartórios no estado do Paraná. Essas contribuições visam a manutenção de um
sistema previdenciário para os cartorários garantindo aposentadoria para os
mesmos e pensões para suas respectivas famílias. O recolhimento é feito via
declaração da movimentação mensal de cada cartório e correspondente percentual.
Como as contribuições são preenchidas pelos próprios cartorários a detecção
de sonegação fica difícil. A única forma atual de se verificar uma irregularidade é
através de fiscalização no próprio cartório, uma prática além de demorada,
dispendiosa financeiramente.
Com a implantação da técnica de data warehouse será possível, pelo próprio
usuário do sistema, ou até, pelo corpo decisor da instituição CONPREVI detectar os
sonegadores e decidir sobre parcelamentos, por exemplo, com um custo muito
menor e com ganho em eficácia.
O uso do data warehouse através de comparativos entre cartórios de mesma
instãncia ou do mesmo cartório no decorrer do tempo, por exemplo, podem
disponibilizar a CONPREVI uma ferramenta poderosa para análise de seus
contribuintes e agilidade na tomada de decisões.
Os dados estão em um micro usado como servidor, a base de dados é Ac-
cess e periodicidade de carga das informações é mensal.
Necessidades do Usuário:
“Precisamos analisar e acompanhar a arrecadação de nossa carteira de prev-
idência por parte dos servidores. Os valores a serem analizados dizem respeito ao
valor destinado ao CONPREVI e Associações. O comparativo vai ser em relação a
épocas distintas, pela data de pagamento, respeitando a sazonalidade para detectar
possíveis sonegações. As consultas devem ser tanto evidenciando as serventias,
como os titulares das serventias. Deve-se, tambem, comparar-se cartórios de
mesmo tipo e de mesma entrância em todas as cidades do Paraná.”
70
71
DIMENSÃO TEMPO
Dt_Pagamento
MêsTrimestreSemestreAno
DIMENSÃO SERVENTIA
Código_Serventia
Nome_ServentiaEnderecoCepTel(Ramal)CidadeEntrancia
DIMENSÃO TIPO DE CARTÓRIO
Código_Tipo_Cartorio
Classificação
DIMENSÃO TITULARCod_Titular
NomeTel(Ramal)EndereçoCidadeCEP Estado CPF
DIMENSÃO CIDADE
Cod_Cidade
CidadeEstado
FATOSRECOLHIMENTO MENSAL
Dt_PagamentoCod_TitularCod_ServentiaCod_CidadeCod_Tipo_Cartorio
Valor_CertidaoValor_CPCValor_Total_AssocValor_MultaValor_JurosValor_Correcao
CONCLUSÃO
Este trabalho forneceu-nos fundamentação teórica e embasamento
suficientes para projetar um data warehouse. O roteiro mostrou que é possível, de
forma esquemática, elaborar um data warehouse sem maiores problemas. Com ele,
muitas das principais dúvidas que surgem, principalmente, àqueles profissionais
que estão tendo o seu primeiro contato com a ferramenta, são apontadas e sanadas
no decorrer do desenvolvimento do projeto de data warehouse. Outra grande virtude
do roteiro é unir, de forma mais harmoniosa, através de correlação, o que foi exposto
na teoria com os casos práticos apresentados. Através da exposição de uma
seqüência de etapas, tornou-se possível uma visualização mais organizada e
sistemática da construção de um data warehouse.
Acreditamos que o objetivo proposto foi amplamente atingido dando
condições a um profissional da área de informática, sem nenhum conhecimento em
data warehouse, a se familiarizar com os novos termos, planejar e desenvolver um
projeto desse nível.
De acordo com a estrutura lógica da seqüência apresentada envolvendo: 1º
Fundamentação Teórica, 2º Desenvolvimento do Roteiro e 3º Casos práticos com
validação de algumas partes do roteiro de acordo com a necessidade de cada
situação, acreditamos termos apresentado um texto de fácil leitura, com raciocínio
lógico e bem estruturado.
Considerações:
Data warehouse não é modismo, tornou-se uma necessidade para a organiza-
ção.
Data warehouse não resolve os problemas da organização se não houver o fator
humano para analisar os resultados e tomar as decisões.
72
É fundamental o envolvimento do usuário em todo o processo (usuário que atua
na análise de informações para a tomada de decisão). São poucos os usuários
com este perfil.
Evitar trabalhar em nível operacional (detalhe) e sim em nível estratégico (dados
consolidados/ agregados) a não ser que seja muito necessária a análise detal-
hada.
A técnica mais adequada para a modelagem dimensional é a star schema. Evitar
utilizar a técnica snow flake visto que é uma técnica onde as dimensões são nor-
malizadas, degradando a performance de acesso à tabela fatos.
Utilizar a modelagem dimensional. A utilização do MER somente para visualizar a
área de negócio para então analisar como obter as informações fontes para o
data warehouse.
O analista de Tecnologia da Informação deve possuir o conhecimento da tecnolo-
gia utilizada no projeto principalmente em: SGBD, Modelagem de Dados Tradi-
cional e Multidimensional.
A estação cliente deve ter alto desempenho.
As consultas demandam um alto consumo de recursos (tanto do servidor quanto
da rede de comunicação de dados).
A avaliação da necessidade de implantar tal sistema deve levar em conta:
A necessidade da empresa de responder continuamente às mudanças de
mercado.
A existência ou não de uma base consistente de informações oriundas
dos bancos de dados operacionais.
A inviabilidade de obter as informações de suporte a decisão diretamente
dos bancos de dados operacionais da empresa.
À medida que a infra-estrutura de informações das empresas amadurece,
aumenta a necessidade de qualidade dos dados e de sistemas eficientes
e eficazes de suporte a decisão. Esse tipo de sistema e o uso corporativo
73
que se faz dele alavancam o conhecimento de negócio ou sua
inteligência, resultando em vantagem competitiva.
No cenário atual onde os administradores das empresas precisam tomar
decisões rápidas e certeiras em resposta aos diversos eventos que ocorrem a todo
instante em suas empresas, faz-se necessário construir todo um mecanismo de
suporte rápido e eficiente aos processos decisórios. O data warehouse é uma
ferramenta apropriada para este tipo se situação. Se bem projetado, permite aos
gerentes obter informações rápidas e confiáveis que lhe servirão de suporte para a
solução de seus problemas e para atingir os objetivos propostos para os negócios.
74
ANEXOS
ALGUNS FORNECEDORES DE FERRAMENTAS OLAP ATUAIS
Existem, no mercado, vários fornecedores de produtos OLAP cada um
dentro de uma categoria, isto é, classificado como um tipo de produto MOLAP,
ROLAP, HOLAP e Cliente/Servidor. A seguir relacionamos alguns fornecedores de
produtos OLAP: [17]
Fornecedores Produto Tipo de ProdutoAndyne Computing Ltd. PaBLO HOLAP Client
Applix TM1 Software Applix TM/1 MDDB Server
Arbor Software Corp. Essbase MDDB Client
Brio Technology Inc. Brio Query MDDB Client
Business Objects Inc. Business Objects ROLAP Client
Cognos Corporation PowerPlay HOLAP Client
Comshare Inc. Decision MDDB Client
Dimension Insight Cross Target MDDB Server
Gentia Software GQL MDDB Client/Server
Hyperion Software Corp. Pillar MDDB Client/Server
IBM DB2 OLAP Server HOLAP Server
Information Advantage Inc. Decision Suite ROLAP Server
Informix MetaCube ROLAP Server
Microsoft Microsoft OLAP Server HOLAP Server
MicroStrategy Inc. DSS Server / DSS Agent ROLAP Client/Server
Oracle Express MDDB Server
Pilot Software Pilot Analysis Server MDDB Server
Platinum Technology InfoBeacon ROLAP Server
SAS Institute Inc. SAS MDDB Client/Server
Seagate Software IMG Holos HOLAP Client/Server
Speedware Corp. Inc. Media/MR MDDB Client/server
Sybase PowerDimensions ROLAP Server
WhiteLight Systems Inc. WhiteLight ROLAP Server
75
SUGESTÃO DE UMA TABELA DIMENSÃO TEMPO DETALHADA [21].
76
Data da Transação
Indicador de último dia do mêsAnoQuartil (Trimestre)MêsSemanaDia da SemanaDia do MêsDia do QuartilDia do AnoIndicador de FeriadoSemana do MêsSemana do QuartilSemana do AnoIndicador de última semana do mêsIndicador de última semana do quartilMês do QuartilAno FiscalQuartil FiscalMês FiscalSemana FiscalDia da semana fiscalDia do mês fiscalDia do quartil fiscalDia do ano fiscalIndicador de último dia do ano fiscalSemana do mês fiscalSemana do quartil fiscalSemana do ano fiscalIndicador de última semana do mês fiscalIndicador de última semana do quartil fiscalIndicador de última semana do ano fiscalMês do quartil fiscal
FIGURAS
[21] Figura 1 – Exemplo de um Cubo Dimensional
[21] Figura 2 – Exemplo de uma Estrutura Star Schema
77
Vendemos 1 Milhão de Reais !
Quando ?Quando ?
O Quê ?O Quê ?
Onde Onde ??
2
3
4
TomateTomate
LaranjaLaranja
ArrozArroz
ChocolateChocolate
O quê ?O quê ?
Região
RegiãoRegião
RegiãoRegião
Região
1996 1997 1998 19991996 1997 1998 1999
Tempo
[21] Figura 3 – Exemplo de uma Estrutura Snow-Flake
[21] Figura 4 – Exemplo de um Modelo de Dados (MER)
78
REFERÊNCIAS BIBLIOGRÁFICAS
[1] ASSUNÇÃ0, Luis. Data Warehousing. Disponível na Internet. http:// www.luis.assuncao.eti.br/luisdwh.htm#item1. 15/12/1999.
[2] COMPUTERWORLD. Data warehouse: depósito de boas oportunidades. Rio de Janeiro. n.173, p. 17, julho,1996.
[3] DBMS – TOOLS & STRATEGIES FOR I.S. PROFESSIONAIS. Um Manifes- to do Dimensional Modeling. Rio de Janieiro. Ed. Mantelmedia, n. 7, p. 44-50, 7 novembro,1997.
[4] EXECPLAN. Apresentação. Disponível na Internet. http: // www.execplan.com.br/apresent/apresent.htm. 28/12/1999.
[5] Fast Track to Sybase – Student Guide. 1992, Sybase Inc.
[6] FIGUEIREDO, Adriana Maria C.M.. MOLAP x ROLAP: Embate de Tecnolo- gias para Data warehouse. Developer’s Magazine. Rio de Janeiro: Ax-
cel Books do Brasil Editora Ltda. Fevereiro de 1998, nº 18 p.24.
[7] FILHO, Trayahú R.Moreira. On-Line Analytical Processing Server (Servidor OLAP). Developer’s Magazine. Rio de Janeiro: Axcel Books do Brasil Edi- tora Ltda. Fevereiro de 1998, nº 18 p.28-29.
[8] FORMA INFORMÁTICA LTDA. Técnicas de Modelagem de Dados. São Paulo, 26 maio, 1994.
[9] GUTIERREZ, Marco Antônio. Developer’s Magazine. Rio de Janeiro: Axcel Books do Brasil Editora Ltda. Fevereiro de 1998, nº 18 p.7.
[10] http://osiris.sunderland.ac.uk/sst/case2/welcome.html em 20/01/2000
[11] INFORMATION WEEK. O Poder do Data warehouse. São Paulo.Ed.Itmidia n.12, p. 12, 20 outubro,1999.
[12] INMON, W. H. Building the Data warehouse. New York : Wiley Computer Publishing, 1996.
[13] INMON, W. H., WELCH, J. D. e GLASSEY,Katherine L. Managing the Data warehouse. New York : Wiley Computer Publishing, 1997.
[14] INMON, Willian H. e HACKATHORN, R. D. Using the Data warehouse. New York : J. Wiley, 1994.
[15] JAMHOUR, Edgar. Sistemas de Banco de Dados. Curitiba,Agosto de 1999. Disciplina do Curso de Especialização em Gestão da Tecnologia da Infor- mação e Comunicação da Faculdade Católica de Administração e Econo- mia.
[16] JORNAL BATE BYTE – CELEPAR ( Companhia de Informática do Paraná). Administração de Metadados. Curitiba, edição nº 76 em junho de 1998.
79
[17] JORNAL BATE BYTE – CELEPAR ( Companhia de Informática do Paraná). Tecnologia OLAP. Curitiba, edição nº 87 em junho de 1999.
[18] JÚNIOR TRONCHIN, Valsoir. Apresentação Sybase : Data Warehousing : Aspectos Estratégicos e de Implementação. Curitiba,1997.
[19] KIMBALL, Ralph. Data warehouse Toolkit. 1.ed. São Paulo: Makron Books, 1998. 388p.
[20] KONDRATIUK, Edgardo Ruben. Data warehouse: Detalhes que Fazem a Di- ferença. Developer’s Magazine. Rio de Janeiro: Axcel Books do Brasil Editora Ltda. Fevereiro de 1998, nº 18 p.22.
[21] MACHADO, Felipe. Modelagem de Dados Multidimensional. DBA Enge- nharia de Sistemas. Rio de Janeiro, 1999.
[22] MANNI, Luiz Carlos & DORSA, Luiz Fernando A. Data warehouse: Gerenci- ando a Qualidade dos Dados. Developer’s Magazine. Rio de Janeiro: Axcel Books do Brasil Editora Ltda. Fevereiro de 1998, nº 18 p.20.
[23] MANZONI JR, Ralphe. A inteligência é a Alma do Negócio. ComputerWorld Business Inteligence, Rio de Janeiro, n. 285, p.2, 8 março, 1999.
[24] NIMER, Fernando.Analisando o Retorno Sobre o Investimento de Data ware- house. Developer’s Magazine. Rio de Janeiro : Axcel Books do Brasil E- ditora Ltda. Fevereiro de 1998, nº 18 p.16-17.
[25] OLIVEIRA LEITE., Argemiro A. Informação à Prova de Equívocos. Compu- terWorld Business Inteligence, Rio de Janeiro, n. 285, p.7, 8 março, 1999.
[26] PALMA, Sérgio. Os Componentes Funcionais de um Data warehouse. Deve- loper’s Magazine. Rio de Janeiro:Axcel Books do Brasil Editora Ltda. Fe- vereiro de 1998, nº 18 p.18-19.
[27] PORTFÓLIO DE TECNOLOGIAS CELEPAR ( Companhia de Informática do Paraná). SQL, Índices, Modelo de Dados, Banco de Dados. Curitiba,30 de junho de 1998.
[28] Sybase System 10: Introduction to SQL- Student Guide.1993, Sybase Inc. [29] TAURION, Cezar. Data warehouse : Vale a Pena Gastar Milhões Investindo em Um?. Developer’s Magazine. Rio de Janeiro: Axcel Books do Brasil Editora Ltda. Fevereiro de 1998, nº 18 p.10-11.
[30] TAURION, Cezar. Data warehouse Será Útil Para a Sua Organização ? De- veloper’s Magazine. Rio de Janeiro : Axcel Books do Brasil Editora Ltda. Fevereiro de 1998, nº 18 p.26-27.
[31] VASCONCELLOS, João Marcos. Apresentação Informix: Do Data Mart ao Data warehouse, O Caminho para o Acesso às Informações Gerenci- ais Estratégicas, Curitiba,1997.
[32] WANG, Charles B., Techno Vision II, ed. Makron Books, 1998.
80
[33] ZAMBON, Luís Pedro. Desenvolvimento de Sistemasde Informação. Curi- tiba,Setembro de 1999.Disciplina do Curso de Especialização em Gestão da Tecnologia da Informação e Comunicação da Faculdade Católica de Administração e Economia.
81