Embed Size (px)
Citation preview
UNIVERSIDADE REGIONAL DE BLUMENAU
CENTRO DE CIÊNCIAS EXATAS E NATURAIS
CURSO DE CIÊNCIAS DA COMPUTAÇÃO
(Bacharelado)
IMPLEMENTAÇÃO DE SISTEMA DE INFORMAÇÃO GERENCIAL, BASEADO EM DATA WAREHOUSE,
UTILIZANDO SEAGATE INFO.
TRABALHO DE ESTÁGIO SUPERVISIONADO SUBMETIDO À UNIVERSIDADE REGIONAL DE BLUMENAU PARA A OBTENÇÃO DOS CRÉDITOS NA
DISCIPLINA COM NOME EQUIVALENTE NO CURSO DE CIÊNCIAS DA COMPUTAÇÃO — BACHARELADO
HEINTJE INGO KORTE
BLUMENAU, JULHO/2000
2000/1-29
ii
PROTÓTIPO DE SISTEMA DE INFORMAÇÃO GERENCIAL PARA A PRODUÇÃO, UTILIZANDO TÉCNICA DE DATA
WAREHOUSE
HEINTJE INGO KORTE
ESTE TRABALHO DE ESTÁGIO SUPERVISIONADO FOI JULGADO ADEQUADO PARA OBTENÇÃO DOS CRÉDITOS NA DISCIPLINA DE ESTÁGIO
SUPERVISIONADO OBRIGATÓRIA PARA OBTENÇÃO DO TÍTULO DE:
BACHAREL EM CIÊNCIAS DA COMPUTAÇÃO
Prof. Marcel Hugo — Supervisor na FURB
Marcílio Pereira da Silva — Orientador na Empresa
Prof. José Roque Voltolini da Silva — Coordenador na FURB do Estágio Supervisionado
BANCA EXAMINADORA
iii
DEDICATÓRIA
A Deus, nosso Senhor,
por sua grandeza,
a meus pais, e a todos,
que um dia tive a alegria de conhecer,
e compartilhar momentos.
Dedico a todos que se propõe a mudar a história, visando o bem comum,
em especial ao que se baseiam nos ensinamentos de nosso Senhor Jesus Cristo.
iv
AGRADECIMENTOS
A Deus, pelas idas e vindas,
nestes anos.
A meus pais,
pela atenção, paciência e apoio que demonstraram.
Ao Sr. Marcílio Pereira da Silva,
pelos ensinamentos prestados e pelo interesse na minha formação.
Aos professores da FURB,
que a cada dia repassaram seus conhecimentos.
Ao professor Marcel Hugo,
pelo seu empenho na condução deste estágio.
Aos meus colegas de faculdade,
pelos momentos compartilhados, e pela amizade criada.
E a todos que confiaram em mim.
A todos estes, meus agradecimentos.
v
SUMÁRIO
DEDICATÓRIA........................................................................................................................iii
AGRADECIMENTOS ..............................................................................................................iv
SUMÁRIO..................................................................................................................................v
LISTA DE FIGURAS .............................................................................................................viii
RESUMO ..................................................................................................................................ix
ABSTRACT ...............................................................................................................................x
1 INTRODUÇÃO.....................................................................................................................1
1.1 OBJETIVOS........................................................................................................................3
1.2 ESTRUTURA DO TRABALHO........................................................................................3
2 INDÚSTRIA DE RELÓGIOS HERWEG S.A......................................................................4
2.1 SISTEMAS DE INFORMAÇÃO .......................................................................................4
2.2 SAPIENS – SENIOR SISTEMAS......................................................................................5
3 SISTEMAS DE INFORMAÇÃO..........................................................................................7
3.1 INTRODUÇÃO...................................................................................................................7
3.2 DEFININDO SISTEMAS DE INFORMAÇÃO.................................................................7
3.3 SISTEMAS, DADOS E USUÁRIOS .................................................................................7
3.4 VISÃO HISTÓRICA DOS SISTEMAS DE INFORMAÇÕES EXECUTIVAS. ..............9
3.4.1 FALTA DE CREDIBILIDADE DOS DADOS..............................................................11
3.4.2 PRODUTIVIDADE ........................................................................................................12
3.4.3 DOS DADOS ÀS INFORMAÇÕES ..............................................................................12
3.4.4 FASES METOLÓGICAS PARA A ELABORAÇÃO DO EIS. ....................................12
3.5 CICLO DE VIDA DE DESENVOLVIMENTO...............................................................15
4 DATA WAREHOUSE ........................................................................................................17
vi
4.1 APRESENTAÇÃO DA METODOLOGIA DE DATA WAREHOUSE..........................17
4.2 PROCESSAMENTO ANALÍTICO ON-LINE(OLAP) ...................................................18
4.2.1 OLAP VERSUS OLTP...................................................................................................18
4.3 COMPARAÇÃO ENTRE BANCOS DE DADOS OPERACIONAIS E DATA
WAREHOUSE..................................................................................................................19
4.4 DEFINIÇÃO DE DATA WAREHOUSE.........................................................................20
4.5 CARACTERÍSTICAS DOS DADOS DE UM DATA WAREHOUSE..........................21
4.6 ANÁLISE DO USO DE DATA WAREHOUSE..............................................................22
4.6.1 VANTAGENS ................................................................................................................22
4.6.2 DESVANTAGENS.........................................................................................................24
4.7 PROPOSTA DE DESENVOLVIMENTO DE DATA WAREHOUSE SEGUNDO W.H.
INMON. ............................................................................................................................25
4.8 ROTEIRO PARA PROJETO DE DATA WAREHOUSE SEGUNDO W.H. INMON. ..27
4.8.1 JUSTIFICATIVA DE CUSTOS.....................................................................................28
4.8.2 BUSCA PELOS DADOS OPERACIONAIS. ................................................................29
4.8.3 DADOS EXTERNOS / NÃO ESTRUTURADOS.........................................................35
4.8.4 INSERINDO DADOS NÃO-ESTRUTURADOS..........................................................36
4.8.5 GRANULARIDADE ......................................................................................................37
5 SEAGATE INFO 7..............................................................................................................39
5.1 INTRODUÇÃO.................................................................................................................39
5.1.1 INFO DESKTOP ............................................................................................................40
5.1.2 INFO ADMINISTRATOR .............................................................................................40
5.1.3 INFO APS.......................................................................................................................41
5.1.4 INFO SERVER ...............................................................................................................41
5.1.5 INFO OLAP AGENT .....................................................................................................41
5.1.6 INFO SENTINEL ...........................................................................................................41
vii
5.1.7 INFO WORKSHEET......................................................................................................42
6 DESENVOLVIMENTO DA PROPOSTA..........................................................................43
6.1 NECESSIDADES DA EMPRESA ...................................................................................43
6.2 APLICAÇÃO DA METODOLOGIA DE W.H.INMON .................................................43
6.3 ROTEIRO PARA PROJETO SEGUNDO W.H.INMON.................................................44
6.3.1 JUSTIFICATIVA DE CUSTOS.....................................................................................44
6.3.2 BUSCA PELOS DADOS OPERACIONAIS .................................................................44
6.3.3 GRANULARIDADE .......................................................Erro! Indicador não definido.
6.3.4 DATA WAREHOUSE E OS MODELOS DE DADOS ................................................44
6.3.5 VANTAGENS ................................................................................................................53
6.3.6 FUNCIONAMENTO DO PROTÓTIPO........................................................................53
7 CONCLUSÃO.....................................................................................................................57
7.1 SUGESTÕES E MELHORAMENTOS FUTUROS ........................................................58
8 ANEXO 1. ...........................................................................................................................59
REFERÊNCIAS BIBLIOGRÁFICAS .....................................................................................61
viii
LISTA DE FIGURAS FIGURA 1 - FLUXO DO SISTEMA DE INFORMAÇÃO DA HERWEG 5
FIGURA 2 - O NOVO CONTEXTO DE DATA WAREHOUSING 8
FIGURA 3 - O CICLO DE VIDA DE DESENVOLVIMENTO – SLDC 16
FIGURA 4 - FENÔMENO DIA 1-DIA N 27
FIGURA 5 - REPRESENTAÇÃO SIMPLIFICADA DA PASSAGEM DOS DADOS DO AMBIENTE
OPERACIONAL PARA O DATA WAREHOUSE. 29
FIGURA 6 - FALTA DE INTEGRAÇÃO DOS SISTEMAS EXISTENTES 30
FIGURA 7 - INTEGRAÇÃO DOS DADOS DOS SISTEMAS EXISTENTES PARA O DATA WAREHOUSE
31
FIGURA 8 - MÉTODOS DE VARREDURA DOS ARQUIVOS DA BASE OPERACIONAL 33
FIGURA 9 - ALTERAÇÃO DE PARÂMETROS DE TEMPO 34
FIGURA 10 - A CONDENSAÇÃO DOS DADOS É UM FATOR VITAL PARA O GERENCIAMENTO DOS
DADOS DO DATA WAREHOUSE 35
FIGURA 11 - TABELA E900CMO 44
FIGURA 12 - TABELA E205DEP 45
FIGURA 13 - TABELA E093ETG 45
FIGURA 14 - TABELA E900COP 46
FIGURA 15 - TABELA E083ORI 47
FIGURA 16 - TABELA E075PRO 48
FIGURA 17 - TABELA E070EMP 49
FIGURA 18 - TABELA E900EOQ 50
FIGURA 19 - TABELA E001TNS 51
FIGURA 20 - INFO DESKTOP 53
FIGURA 21 - INFO WORKSHEET 54
FIGURA 22 - TELA DE SELEÇÃO DE DIMENSÕES DO CUBO 55
FIGURA 23 - MODELO DE DADOS DO NÍVEL OPERACIONAL. 56
ix
RESUMO
Este estágio visa desenvolver um protótipo de sistemas de informação sobre a base de
dados contida na empresa Indústria de Relógios Herweg S.A. Os sistemas de informação
serão desenvolvidos sobre as informações geradas pela área de Produção, do Sistema
Corporativo Sapiens, desenvolvido pela Senior Sistemas Corporativos, onde utiliza-se como
Sistema Gerenciador de Banco de Dados, o Oracle Server; e como ferramenta onde serão
aplicados os conceitos do Data Warehouse, o Seagate Info 7.
x
ABSTRACT
The prototype made on my period of training was created to develop an Information
System using the database of Indústria de Relógios Herweg S.A.. This information system
will be developed based on information produced by Production department, Sapiens
Corporative System, created by Senior Sistemas Corporativos, that has as Database
Management System the Oracle Server and as tool the Seagate Info 7, where will be applied
the concepts of Data Warehouse.
1
1 INTRODUÇÃO
Durante muitos anos os Sistemas Gerenciadores de Banco de Dados foram o foco das
corporações, onde estas estavam preocupadas em guardar os dados que eram gerados por ela,
para depois poder gerar informações visando uma análise sobre seus negócios.
Surgiram então para auxiliar, o Sistema de Informações Gerenciais (SIG), que são
sistemas que juntam os dados a tal ponto que esta possa transmitir informação para tomada de
decisão (estratégica), possibilitando ao executivo ter uma visão integrada de todas as áreas da
empresa. Segundo [CRU1998], “Sistemas de Informações Gerenciais são o conjunto de
tecnologias que disponibilizam os meios necessários à operação do processo decisório em
qualquer organização por meio do processamento dos dados disponíveis”.
O processamento instantâneo (on-line) utilizado para o sistema de informação
produziam as informações, gastavam muito tempo de processamento. Também com o passar
dos anos, sentiu-se a necessidade de ter os dados já prontos para serem usados, sem a
necessidade de aplicar o conhecimento de pessoas. Para isto, muitas empresas iniciaram
projetos que se baseavam em uma nova metodologia: Data Warehouse.
Os dados presentes em sistemas contidos em empresas podem ser diferenciados
conforme o seu propósito. [IMN1997] separa os dados gerados pelos sistemas, em dados
operacionais e informacionais. Os dados operacionais são os dados armazenados por sistemas
setoriais, que recebem dados de setores como o Financeiro, Comercial ou Produção. Já os
dados informacionais, são os que são gerados a partir dos dados operacionais, e que são
agrupados em relação a determinado assunto. Os dados operacionais devem atender a
necessidade de diversos usuários, concorrentemente, com uma resposta rápida às solicitações.
Os dados informacionais atendem a um número menor de usuários, onde a preocupação maior
é quanto à complexidade na busca da informação, sendo que a informação gerada será
conseqüência de muitos dados operacionais.
Uma proposta ideal para o Data Warehouse é a implementação que permita a análise
de informações, monitorar e comparar os dados presentes, e também prever a inclusão de
dados futuros.
2
Para atuar no mercado atual, necessita-se cada vez atender rapidamente e com
qualidade, oferecendo produtos e serviços aos clientes. Para que isto seja possível, é
imprescindível dispor de controles sobre as fases de desenvolvimento, produção e vendas de
um negócio.
Com este protótipo, estar-se-á focando a fase da produção. Pelo fato da Indústria de
Relógios Herweg S.A. possuir produção diversificada, tanto em unidades de medida, horas de
produção e outros aspectos, é necessário fornecer algum modo de controlar esta fase. A partir
disto será desenvolvido um protótipo de Data Warehouse para integrar as informações. Com
este protótipo, a gerência irá usufruir destas informações para possivelmente detectar
tendências e desvios, o que auxilia nas tomadas de decisão, facilitando quanto à precisão e
velocidade de resolução. Descobrindo o porquê, tanto nas situações em que a informação
trouxer uma resposta positiva quanto negativa, a probabilidade de estar apoiado em valores
resultantes deste processo, aumenta a expectativa de acertos.
Sobre o Sistema Corporativo Sapiens, vale destacar que é um sistema desenvolvido
pela empresa Senior Sistemas de Blumenau. Este sistema propõe-se a integrar os
departamentos numa só ferramenta. Como gerenciador de banco de dados este sistema utiliza
o Oracle Server.
Para a implementação do Data Warehouse será usada a ferramenta Seagate Info 7, da
Seagate Softwares. O Seagate Info 7 é uma ferramenta de Business Intelligence que
proporciona e cada pessoa obtenha as informações necessárias para a tomada de decisões,
oferecendo uma infra-estrutura de nível empresarial, escalabilidade e gerenciamento na
entrega de consultas (queries), relatórios e cubos On Line Analitical Processing – OLAP para
toda a organização via rede, Intranet e Internet. A metodologia de especificação e a
implementação serão baseadas na metodologia proposta por Inmon ([INM1997]). A
metodologia de desenvolvimento de sistemas de informação é baseada em EIS. A
metodologia de desenvolvimento de sistemas baseou-se na análise estruturada.
3
1.1 OBJETIVOS
O objetivo principal do trabalho proposto é o desenvolvimento de um protótipo capaz
de gerar informações para análise do desempenho setorial para o sistema de produção da
empresa.
1.2 ESTRUTURA DO TRABALHO
No primeiro capítulo é apresentado o objetivo, como também a organização do
trabalho.
No segundo capítulo, é feita uma apresentação da empresa onde foi realizado o estágio.
Também é apresentado um resumo sobre os sistemas de informação utilizados atualmente
pela empresa. Outro tópico, é uma breve introdução sobre a empresa que desenvolveu o
sistema corporativo, da qual utilizaram-se os dados de nível operacional.
O terceiro capítulo apresentado conceito de sistemas de informações e um histórico
deste assunto, e o seu desenvolvimento.
No quarto capítulo é apresentado o Data Warehouse, com seus conceitos,
características, a proposta de desenvolvimento formulada por Inmon, e análises sobre suas
tecnologias.
No quinto capítulo, é explicada a ferramenta usada na implementação do protótipo.
No sexto capítulo, é descrita a implementação do protótipo proposto, com suas
principais telas, e uma análise final.
No sétimo capítulo, é apresentada a conclusão do trabalho, bem como as sugestões
para trabalhos futuros, e as referências utilizadas.
4
2 INDÚSTRIA DE RELÓGIOS HERWEG S.A.
Indústria do ramo metal-mecânico, sediada em Timbó, Santa Catarina. Fundada em
1952, por Otto Wilhelm Herweg e Alfred Rudolph, vende seus produtos para o Brasil e
exterior (Europa e Américas). Possui moderno parque industrial de 10.000m2 de área
construída, numa superfície de aproximadamente 120.000m2.
É uma empresa que produz grande parte dos componentes que fazem parte de seus
produtos finais. A produção é baseada em kanbans. A programação de produção é gerada
semanalmente, analisando-se relatórios de estoques, de onde são analisadas as quantidades
provenientes dos pedidos cadastrados pelo setor de vendas.
Produz atualmente:
a) despertadores mecânicos e à quartz;
b) relógios de parede à quartz;
c) timers de 10, 15, e 60 minutos;
d) relógios sob encomenda para uso promocional.
Importa para revenda:
a) relógios despertadores à quartz;
b) relógios de parede à quartz.
2.1 SISTEMAS DE INFORMAÇÃO
Atualmente o setor de PCP (Planejamento e Controle de Produção) da Herweg tem seu
controle totalmente baseado em planilhas, sendo que retira as necessidades de produção a
partir de relatórios do sistema Sapiens, provenientes do setor de vendas. A figura 1 descreve o
fluxo de informações no gerado no sistema Sapiens, a partir do pedido enviado gerado pelo
cliente.
Com a implantação do módulo de produção, do Sapiens, todo o controle deverá ser
passado ao sistema, e com isto, tendo um sistema de informação apoiando a implantação do
sistema, poder-se-á avaliar o desempenho da produção.
5
Figura 1 - Fluxo do Sistema de Informação da Herweg
Cliente
Vendas
PPCP
Montagem
Injetoras
Estamparia
Galvânica
Usinagem
Almoxarifado
Expedição
2.2 SAPIENS – SENIOR SISTEMAS
Em Junho de 1998, iniciou-se a implantação do sistema corporativo Sapiens,
produzido pela Senior Sistemas, sediada em Blumenau, Santa Catarina. A empresa Gestão
Sistema de Informações, também de Blumenau, Santa Catarina, é a responsável pela
implantação e treinamento na Indústria de Relógios Herweg.
O Sapiens é constituído por um conjunto de sistemas integrados de Gestão
Empresarial, totalmente voltados para a otimização de tomadas de decisões e para a
6
produtividade. Desenvolvido para ambiente Windows 9x/NT, com arquitetura
Cliente/Servidor.
Atualmente, juntamente com a elaboração deste estágio, está sendo implantado o
módulo de Produção, ao qual se está antecipando, fazendo com que já se tenha um Sistema de
Informação para este setor, a partir do momento em que este esteja em funcionamento para
uso.
7
3 SISTEMAS DE INFORMAÇÃO
3.1 INTRODUÇÃO
Pode-se citar como principais atribuições do executivo moderno o acompanhamento da
evolução da empresa como um todo, o diagnóstico das dificuldades, áreas de oportunidade e
soluções [SAL1994].
Os sistemas de informação são o meio pelo qual os executivos visualizam a empresa,
permitindo assim atingir seus objetivos. As informações geradas por estes sistemas apóiam a
organização em seu continuo processo de desenvolvimento e mudança.
3.2 DEFININDO SISTEMAS DE INFORMAÇÃO
Define-se Sistemas de Informação como o conjunto de pessoas, fatos e procedimentos,
visando proporcionar à organização o alcance de seus objetivos [SAL1994].
Para obter-se uma informação através dos dados têm-se os seguintes tópicos [apud
MEN1998]:
a) dados são os componentes básicos, a partir dos quais informação é criada;
b) informação é um conjunto de dados inseridos em um contexto;
c) contexto é a situação que está sendo analisada;
d) a partir da informação obtém-se conhecimento, que permite tomar decisões, trazendo
poder e vantagem competitiva.
Para transformar-se dados em informações é necessário um indivíduo (neste caso o
usuário do sistema), que é aquele que colocará o dado no contexto adequado. Neste momento,
o dado adquire significado, semântica, transformando-se em informação. Somente neste
instante ele tem valor para o negócio [TRO1997].
3.3 SISTEMAS, DADOS E USUÁRIOS
Há aproximadamente oito ou nove anos, tanto em virtude da flexibilização da reserva
de mercado de informática quanto em função dos efeitos de abertura da economia maior
pressão competitiva no ambiente de negócios, gerou-se maior demanda e foram
8
disponibilizados melhores recursos para utilização de sistemas de informação no nível de
tomada de decisões, apresentados no topo da pirâmide conforme figura 2 [AMA1997].
Figura 2 - O novo contexto de data warehousing
Fonte:[apud MEN1998]
Esse contexto denominou-se EIS – Executive Information Systems – e é delimitado
pelas seguintes variáveis:
a) topo da estrutura organizacional – alta gerência/executivos;
b) topo das estruturas de informações (dados consolidados);
c) ferramentas de interface gráfica amigável e intuitiva.
Todavia, o cenário de competitividade de negócios, globalização da economia e de
atualização constante das soluções de tecnologia transformou o quadro apresentado nos
parágrafos anteriores.
9
A cada dia que passa, as corporações têm que dedicar uma porção relativamente menor
de seu tempo às atividades operacionais e maior às estratégias de tomada de decisão para
viverem nesse cenário de maior competitividade. Com a diversidade e quantidade cada vez
maiores de informações para tomada de decisões, os executivos ficariam sobrecarregados se
tivessem de utilizar todas estas informações, como no contexto do EIS; dessa forma, surge,
nas organizações, a figura dos consumidores de informação (information consumers), que
apoiarão os executivos nos processos de tomada de decisão.
Mas estes resultados vêm sendo pesquisados e desenvolvidos há muito tempo como
mostra o próximo tópico.
3.4 VISÃO HISTÓRICA DOS SISTEMAS DE INFORMAÇÕES EXECUTIVAS.
No início da década de 1960, o mundo da computação consistia na criação de
aplicações individuais que eram executadas sobre arquivos mestres. As aplicações eram
caracterizadas por relatórios e programas, geralmente na linguagem de programação Cobol. O
uso dos cartões perfurados e fitas magnéticas era comum [INM1997].
Em meados da década de 1960, o crescimento dos arquivos mestres e das fitas
magnéticas explodiu e com este crescimento, surgiram enormes quantidades de dados
redundantes e seus problemas.
Por volta de 1970, presenciou-se o advento do armazenamento em disco
fundamentalmente diferente do armazenamento em fita magnética. Os dados podiam ser
acessados diretamente, sem necessidade da leitura seqüencial do arquivo. Com este
dispositivo de armazenamento de acesso direto (DASD), surgiram os softwares conhecidos
como SGBD ou sistema de gerenciamento de banco de dados. O objetivo do SGBD era o de
tornar o armazenamento e o acesso aos dados no DASD mais fáceis ao programador provendo
independência física e lógica. O SGBD se encarregava, ainda, de tarefas como
armazenamento de dados no DASD, indexação de dados, e assim por diante, surgindo a idéia
de um “banco de dados”.
Em meados da década de 1970, o processamento de transações on-line começou a ser
feito sobre banco de dados (OLTP – On Line Transaction Processing). Com um terminal e o
10
software apropriado, os técnicos descobriram que um acesso mais rápido aos dados era
possível – abrindo perspectivas totalmente novas. Com o processamento de transações on-line
de alta performance, o computador poderia ser usado para tarefas que anteriormente não eram
viáveis [INM1997].
Até o início da década de 1980, novas tecnologias – como os microcomputadores e as
L4G (Linguagens de Quarta Geração) – começaram a vir à tona. O usuário final passou a
assumir um papel do clássico processamento de dados. Com os PC e a tecnologia das L4G
surgiu a noção de que era possível utilizar os dados para outros objetivos além de atender ao
processamento de transações on-line de alta performance. Os SIG (sistemas de informações
gerenciais) também eram viáveis.
“Sistema de Informações Gerenciais é um sistema integrado homem-máquina que
provê informações para dar suporte às funções de operação, administração e tomada de
decisão na empresa” [OLI1992]. Anteriormente, os dados e a tecnologia eram utilizados
exclusivamente para direcionar decisões operacionais detalhadas [INM1997].
Conforme Binder [BIN1994], apesar de todo o desenvolvimento ocorrido na área de
informática, a atuação da mesma sobre a gerência da empresa ainda estava subutilizada. Um
dos novos recursos que surgiram para auxiliar as atividades gerenciais chama-se Sistema de
Apoio a Decisão (SAD ou DSS – Decision Support System).
Os Sistemas de Apoio a Decisão surgiram da necessidade de auxiliar os executivos em
processos semi-estruturados ou não estruturados, com a constante mudança desses processos.
Os Sistemas de Apoio a Decisão começaram a ser desenvolvidos por volta do final da
década de 1960 e no início da década de 1970, como resultado de vários fatores: progressos
tecnológicos tanto de hardware como de software, consciência cada vez mais de como dar
suporte ao processo decisório, desejo de obter melhores informações, pesquisas universitárias,
entre outros [SAL1994].
No final da década de 1970, no MIT (Massachussets Institute of Technology), surgiu o
termo Sistema de Informações Executivas (SIE).
11
Os SIE ou EIS (Executive Information System) surgiram da necessidade informacional
que os executivos possuíam, informações estas muito peculiares a cada um deles. As
necessidades informacionais de executivos podem ser supridas por um sistema de
informações, sistemas estes que são desenvolvidos em torno das necessidades ou exigências
de seus usuários.
Surgiu então, um paradigma – um único banco de dados que poderia atender
simultaneamente ao processamento de transações on-line de alta performance e o
processamento analítico, ou de Sistemas de Informação Gerencial (SIG), Sistemas de Suporte
a Decisão (SAD) ou SIE.
Pouco depois do advento das transações on-line de alta performance em massa, um
programa inócuo chamado de processamento de extração, começou a surgir. O programa de
extração é mais simples de todos os programas. Ele varre um arquivo ou banco de dados, usa
alguns critérios de seleção, e, ao encontrar dados que atendam aos critérios, transporta os
dados para um outro arquivo ou banco de dados.
Quando fora de controle, o processamento de extração produziu o que pode ser
chamado de arquitetura de desenvolvimento espontâneo – que ocorre quando uma
organização lida com todo o processo de arquitetura de hardware e software com uma postura
de simplesmente deixar acontecer [MEN1998].
Há muitos problemas associados com a arquitetura de desenvolvimento espontâneo
[MEN1998]:
a) falta de credibilidade;
b) produtividade;
c) impossibilidade de transformar dados em informações.
3.4.1 FALTA DE CREDIBILIDADE DOS DADOS
A falta de credibilidade é ocasionada principalmente por:
a) ausência de parâmetros de tempo dos dados;
b) o diferencial algorítmico dos dados;
c) os níveis de extração;
d) o problema dos dados externos;
12
e) nenhuma fonte de dados comum com a qual começar.
3.4.2 PRODUTIVIDADE
Para desenvolver qualquer tarefa (relatório, por exemplo) há necessidade de destacar
alguns requisitos que interferem na produtividade:
a) localizar e analisar os dados para o relatório;
b) compilar os dados para o relatório;
c) obter recursos humanos de programação/análise para realizar a tarefa.
3.4.3 DOS DADOS ÀS INFORMAÇÕES
Os sistemas encontrados na arquitetura de desenvolvimento espontâneo são
simplesmente inadequados à tarefa de apoio às necessidades de informações em virtude de
sua falta de integração e da diferença entre o horizonte de tempo necessário ao processamento
analítico e o horizonte de tempo disponível nas aplicações do ambiente de extração
[INM1997].
3.4.4 FASES METODOLÓGICAS PARA A ELABORAÇÃO DO EIS.
Segundo [FUR1994], a metodologia proposta para a definição do EIS é composta por
três fases:
a) fase I – planejamento;
b) fase II – projeto;
c) fase III – implementação.
A fase de planejamento tem por objetivo definir conceitualmente o sistema EIS por
meio da identificação das necessidades de informação e do estilo decisório do executivo, bem
como da estrutura básica do sistema e do protótipo preliminar de telas.
Esta fase é composta por cinco estágios:
a) estágio I – organização do projeto: neste estágio, a equipe de trabalho é treinada nas
técnicas de levantamento de dados e análise dos fatores críticos de sucesso. Uma
sessão de orientação de executivos também é realizada com o objetivo de prepara-los
13
para o processo de entrevistas. Identificar quais informações os executivos já recebem,
por meio de questionário específico, e utilizar as informações já coletadas da empresa
em projetos anteriores também são procedimentos importantes na análise da situação
atual;
b) estágio II – definição de indicadores: neste estágio, cada executivo é entrevistado
individualmente para que se possam identificar seus objetivos, fatores críticos de
sucesso e necessidades de informação e, em seguida, efetuar a documentação para
submeter os resultados à revisão. Uma sessão de planejamento deve ser conduzida
antes das entrevistas, a fim de rever os precedentes e, assim, traçar uma linha mestra de
ação. Após as entrevistas, seguem,-se sessões de documentação e apresentação aos
executivos para sua revisão e seu acompanhamento. O questionário específico
(Executive Information Survey) é utilizado nas entrevistas de acompanhamento com o
objetivo de identificar as necessidades de informação que são atendidas por meio das
fontes de informação existentes. Por fim, são feitas revisões na documentação das
entrevistas, que serão submetidas aos executivos para aprovação;
c) estágio III – análise de indicadores: o objetivo deste estágio é normalizar as
informações levantadas durante as entrevistas individuais dos executivos a fim de obter
uma lista consolidada de objetivos, fatores críticos de sucesso, problemas e
necessidades de informação. Esta lista é, então, transformada numa matriz de inter-
relacionamento entre os indicadores de desempenho e os respectivos objetos de
interesse dos executivos. Em seguida, são atribuídos pesos de importância e é
elaborado um ranking de necessidades;
d) estágio IV – consolidação de indicadores: neste estágio, é realizada uma revisão
dirigida com o grupo de executivos entrevistados para rever os objetivos, fatores
críticos de sucesso, problemas e necessidades de informação, assim como confirmada a
classificação (ranking) desses objetos. O resultado dessa revisão dirigida é a
combinação dos objetivos, fatores críticos de sucesso, problemas e necessidades de
informação num documento que serve com um workbook da sessão da revisão. Ainda
na sessão de revisão dirigida, são confirmadas as fórmulas de controle para regras de
exceções (níveis de desvio que o executivo deseja ver destados);
e) estágio V – desenvolvimento de protótipos: neste estágio, são realizadas atividades de
desenho de telas e estruturas de navegação do sistema. Um protótipo é construído para
14
que o executivo possa ter uma visão mais próxima possível do que será o sistema após
sua implementação. Ainda neste estágio são padronização os modelos de telas
(layouts), cores, botões e ícones.
Se a fase de planejamento tem como escopo a determinação das especificações do
sistema sob o enfoque das necessidades do usuário, a fase de projeto definirá a solução
técnica para implementar o projeto conceitual concebido. De um modo prático, é definida
nesta fase a arquitetura tecnológica a ser adotada, é escolhida a ferramenta de software, são
planejados os critérios de integração e transferência de dados, é modelada a base de dados do
EIS, sendo detalhados os atributos das tabelas a serem criadas e layouts de arquivos a serem
acessados ou criados.
Esta fase é composta por três estágios:
a) estágio I – decomposição de indicadores: este estágio envolve atividades de
detalhamento técnico dos indicadores e modelagem da base de dados do EIS que
suportará o atendimento das necessidades de informação classificadas (ranking) na
fase anterior, incluindo informações sobre fontes de dados, proprietários das
informações, freqüência e método proposto de atualização. Por meio dessa
especificação, identificam-se os sistemas e bases de dados que devem ser acessados
para suprir as necessidades de informação identificadas. Para cada indicador de
desempenho, são ainda estudados os níveis de detalhamento desejados (drill-down);
b) estágio II – definição da arquitetura tecnológica: fazem parte deste estágio a
determinação da localização física das bases de dados (no ambiente corporativo; numa
rede local; duplicada em microcomputadores stand-alone, etc) e a definição de
parâmetros, como investimentos necessários e instalações. Se, eventualmente, a
instalação ainda não tem a definição da ferramenta de EIS a ser adotada, é neste
estágio que tal decisão deve ser tomada, com base num estudo cuidadoso das
necessidades e da arquitetura atual das informações da empresa;
c) estágio III – planejamento da implementação: este estágio busca determinar os
recursos necessários para o desenvolvimento da aplicação do EIS. São planejados,
além do cronograma de construção do sistema, os seus demais requisitos, tais como
instalações, criação das bases de dados e realização de testes.
A fase de implementação é composta por três estágios:
15
a) estágio I – construção dos indicadores: as atividades deste estágio tem um caráter
notadamente técnico como em qualquer projeto de desenvolvimento de sistemas. São
construídas telas de consultas de acordo com o padrão estabelecido e o protótipo é
aprovado pelo executivo na fase de planejamento. Também neste estágio dá-se a
construção e a conversão de bases de dados a serem acessadas para a geração das telas,
bem como a realização de testes ajustes no sistema;
b) estágio II – instalação de hardware e software: este estágio tem por finalidade
implementar a parte física do sistema, providenciando a instalação da arquitetura
tecnológica projetada na fase anterior;
c) estágio III – treinamento e implementação: neste estágio final da metodologia, o
sistema torna-se disponível para o executivo e é incorporado ao seu cotidiano.
Realizam-se o treinamento e a orientação para uma efetiva utilização do sistema, bem
como se define o encarregado da administração do EIS. Esse encarregado será
responsável pelo acompanhamento e orientação dos executivos e, principalmente, pelo
controle diário da atualização, integridade e consistência das bases de dados do
sistema. A documentação construída ao longo do processo de desenvolvimento é
consolidada, sendo também elaborado o manual do sistema.
3.5 CICLO DE VIDA DE DESENVOLVIMENTO
Além do fato dos dados operacionais não serem integrados e o Data Warehouse
precisa, necessariamente, ser integrado, há outras diferenças entre os níveis de dados e de
processamento operacionais e o do Data Warehouse. Uma profunda diferença entre o nível
operacional e o Data Warehouse diz respeito aos ciclos de vida de desenvolvimento
subjacentes, como ilustra a figura 3 [INM1997].
16
Figura 3 - O ciclo de vida de desenvolvimento – SLDC
FONTE: [INM1997]
A figura 3 mostra que o ciclo de vida do desenvolvimento de sistemas clássico atende
ao ambiente operacional. O Data Warehouse funciona segundo um ciclo de vida muito
diferente, eventualmente chamado de ciclo de vida do desenvolvimento de sistemas analíticos
(o inverso de System Development Life Cycle – SLDC – ciclo de vida de desenvolvimento de
sistemas). O SLDC clássico é baseado em requisitos. Para desenvolver sistemas, primeiro é
necessário entender as necessidades. Posteriormente, vêm as fases de projeto e
desenvolvimento. O ciclo de vida de sistemas analíticos (como os SAD) é praticamente o
inverso, iniciam nos dados. Uma vez que os dados estejam sob controle, eles são integrados e,
em seguida, testados para que se verifique qual distorção há neles, se houver alguma. Então,
e, finalmente, os requisitos do sistema são compreendidos.
O ciclo de vida de sistemas analíticos é tipicamente baseado em dados, ao passo que o
de sistemas em nível operacional é um ciclo de vida baseado tipicamente em requisitos.
O Data Warehouse é criado com dados iniciais e bem refinados. Os dados são
pesquisados e os resultados são avaliados e as decisões são tomadas. O processo de pesquisa e
avaliação leva a uma melhor qualidade nos dados. Este processo é contínuo enquanto ocorre
sem mudanças organizacionais, tecnológicas e mercadológicas [MUE1999].
17
4 DATA WAREHOUSE
Segundo Jorge L. M. Gonçalvez [GON1997], Data Warehouse é uma nova buzzword
(conceito) reiterando uma velha promessa. Esse conceito, embora surgido recentemente,
baseia-se na aplicação de antigas idéias que somente agora puderam ser viabilizadas pela
conjunção de diferentes tecnologias, tais como: banco de dados relacionais e
multidimensionais, interface gráfica, PC, sistemas operacionais em rede, discos rígidos de
grande capacidade de armazenamento e velocidade de acesso, On Line Analitical Processing -
OLAP, entre outros.
4.1 APRESENTAÇÃO DA METODOLOGIA DE DATA WAREHOUSE
Com o novo conceito de Data Warehouse, é possível gerar informações antes
indisponíveis, afetando, direta e indiretamente, as decisões corporativas. Como resultado tem-
se um aumento de rentabilidade por executivo. No lado operacional, os dados aparecem em
formas de tabelas ou relatórios que precisam ser analisados, caso se queira transformá-los em
informação. No Data Warehouse, eles são armazenados de forma lógica e facilmente podem
ser analisados em vida quando trabalhados por ferramentas EIS – Executive Information
Systems – ou OLAP.
O Data Warehouse auxilia na criação e utilização de informações coletadas na base de
dados operacional, possibilitando retorno rápido de investimento. Do ponto de vista
comercial, a tecnologia aumenta a velocidade das respostas e maximiza os ganhos. As
corporações passam a perceber os benefícios de se trabalhar focado em processos de
negócios, mesmo que as informações estejam em fase de transferência da base operacional
para o Data Warehouse [EXP1996].
No Data Warehouse os dados são armazenados e analisados dentro de uma perspectiva
histórica. A prática de data warehousing permite que se raciocine de forma orientada ao
tempo:
a) passado – de onde se aprende e se evita repetir os erros;
b) presente – a análise dos fatos permite a correta adaptação a eles;
18
c) futuro – a previsão de tendências permite que se ganhe a batalha antes mesmo dela
ocorrer.
Segundo Valsoir Tronchim [TRO1997], no Data Warehouse os dados estão integrados
e orientados a assuntos, ou temas. Isto permite um raciocínio eficiente sobre o eixo da
cardinalidade. Pode-se pensar sobre vários problemas e questões simultaneamente, estudando-
se a relação entre elas.
Data Warehouse é a infra-estrutura que permite que se empregue o pensamento
estratégico. Sendo utilizada dentro da organização, eleva o nível de conhecimento de todos –
permitindo, através do conhecimento, a competição por manobra. A centralização e o controle
de acesso a informação são características da competição por atrito. Na competição por
adaptação e manobra, todos devem estar plenamente cientes da missão da empresa e do papel
que desempenham [TRO1997].
A prática Data Warehousing permite que se aja cedo e não tarde; que se aja de forma
pró-ativa e não reativa; que se saiba e não se suponha; que se mude e não se atrofie; que se
exceda e não se satisfaça; que se ganhe e não se perca.
4.2 PROCESSAMENTO ANALÍTICO ON-LINE(OLAP)
O termo On-line Analytical Processing - OLAP refere-se ao tipo de processamento e
ferramenta voltados para análise de dados típica do suporte à decisão, onde os dados são
apresentados através de uma visão multidimensional. Esta visão é independente de como os
dados estão armazenados.
4.2.1 OLAP VERSUS OLTP
De um ponto de vista prático, OLAP sempre envolve consultas interativas aos dados,
seguindo um caminho de análise através de múltiplos passos, como, por exemplo, aprofundar-
se sucessivamente por níveis mais baixos de detalhe de um quesito de informação específico.
OLAP envolve capacidades analíticas, incluindo a derivação de taxas, variâncias, etc., e
envolvendo medidas ou dados numéricos através de muitas dimensões, devendo suportar
modelos para previsões, análises estatísticas e de tendências[JOR1997].
19
De uma forma geral, OLAP apresenta características distintas do processamento de
transações on-line tipo OLTP.
Consultas típicas deste tipo de processamento são:
a) Quais os produtos que vendem bem?;
b) Quais os escritórios de vendas mais fracos?;
c) Qual o “ranking” dos vendedores da Região Nordeste?;
d) Qual o número e o salário médio dos funcionários de manutenção por departamento?
Neste estágio utilizou-se a tecnologia OLAP.
4.3 COMPARAÇÃO ENTRE BANCOS DE DADOS OPERACIONAIS E DATA WAREHOUSE
Na tabela 1, é realizada uma comparação entre as características presentes em bancos
de dados do nível operacional e do Data Warehouse.
20
Características
• Objetivo
• Uso
• Tipo de processamento
• Unidade de trabalho
• Número de usuários
• Tipo de usuário
• Interação do usuário
• Condições dos dados
• Volume
• Histórico
• Granularidade
• Redundância
• Características
• Estrutura
• Manutenção desejada
• Acesso a registros
• Atualização
• Integridade
• Número de índices
• Intenção dos índices
Bancos de dados Operacionais
• Operações diárias do negócio
• Operacional
• OLTP
• Inclusão, alteração, exclusão
• Milhares
• Operadores
• Somente pré-definida
• Dados operacionais
• Megabytes – gigabytes
• 60 a 90 dias
• Detalhados
• Não ocorre
• BD operacionais
• Estática
• Constante
• Dezenas
• Contínua (tempo real)
• Transação
• Poucos/simples
• Localizar um registro
Data Warehouse
• Analisar o negócio
• Informativo
• OLAP
• Carga e consulta
• Centenas
• Comunidade gerencial
• Pré-definida e ad-hoc
• Dados Analíticos
• Gigabytes – terabytes
• 5 a 10 anos.
• Detalhados e resumidos
• Ocorre
• Data Warehouse
• Variável
• Mínima
• Milhares
• Periódica (em batch)
• A cada atualização
• Muitos/complexos
• Aperfeiçoar consultas
Tabela 1 – Comparação entre Banco de Dados Operacionais e Data Warehouse.
Fonte:[ DAL1998]
4.4 DEFINIÇÃO DE DATA WAREHOUSE
A definição clássica do termo Data Warehouse foi feita por William H. Inmon em
1990 em seu livro “Building the Data Warehouse”: “Data Warehouse é um conjunto de dados
orientados a um assunto, integrados, não-voláteis, variáveis no tempo, utilizados para apoiar
decisões gerenciais”.
21
Data Warehousing, entretanto, tem outra definição. Segundo outros autores, “é o
processo pelo qual as empresas extraem sentido e significado dos seus dados através da
utilização de banco de dados especiais chamados Data Warehouses” [TRO1997].
Embora muitos utilizem ambos os termos de forma distinta, a diferença é clara. O
processo de Data Warehousing é contínuo e ininterrupto, devendo acompanhar toda a vida da
empresa. Segundo [TRO1997], muita gente diz que não compra um Data Warehouse,
constrói-se um. Na realidade, não se compra nem se constrói, pratica-se data warehousing.
De acordo com Richard Hackatborn (pioneiro no tema), o objetivo de um Data
Warehouse, é fornecer uma “imagem única da realidade do negócio” [JOR1997]. De uma
forma geral, sistemas de Data Warehouse compreendem um conjunto de programas que
extraem dados do ambiente de dados operacional da empresa, um banco de dados que os
mantém, e sistemas que fornecem estes dados aos usuários.
Sistemas de Data Warehouse revitalizam os sistemas da empresa [MEN1998], pois:
a) permitem que sistemas mais antigos continuem em operação;
b) consolidam dados inconsistentes dos sistemas mais antigos em conjuntos coerentes;
c) extraem benefícios de novas informações oriundas das operações correntes;
d) provêm ambiente para o planejamento e arquitetura de novos sistemas de cunho
operacional.
4.5 CARACTERÍSTICAS DOS DADOS DE UM DATA WAREHOUSE
O Data Warehouse, denominado de “grande depósito de informações”, ou como
define [IMN1997], é um conjunto de dados baseado em :
a) assuntos: voltado ao negócio onde este será aplicado;
b) integrado: reúne as informações nos sistemas, tanto integrados como os isolados;
c) volátil: somente tem incrementos em períodos previamente conhecidos, sendo que a
informação analisada em determinado instante, no instante seguinte será o mesmo;
d) variável: estará sempre sendo aumentado com a inclusão ao passar o tempo. Não
teremos dados totalmente atualizados, pois no instante seguinte algum dado já foi
inserido.
22
4.6 ANÁLISE DO USO DE DATA WAREHOUSE
Para avaliar as vantagens e desvantagens da utilização de um Data Warehouse foram
feitos estudos sobre vários casos de empresas que já estão utilizando ou estão no processo
inicial de construção de um Data Warehouse. Uma das fontes de pesquisa para este trabalho
foi um artigo publicado pela professora Toru Sakaguchi da Universidade de Memphis, EUA
[apud DAL1999]. Este artigo foi realizado tendo como base 456 artigos escritos entre abril de
1992 e julho de 1996, que foram analisados e comparados para extrair as principais vantagens
e desvantagens da utilização de um Data Warehouse.
4.6.1 VANTAGENS
As principais vantagens encontradas são:
a) simplicidade: A vantagem mencionada com mais freqüência sobre Data Warehouse
pode ser resumida como "simplicidade". O Data Warehouse facilita a administração da
empresa por que fornece uma imagem simples da realidade com integração de vários
dados de sistemas diferentes. O Data Warehouse permite que os sistemas operacionais
continuem em uso, transformando os dados inconsistentes dos sistemas do nível
operacional em um conjunto de dados coerentes que são informações vitais para as
empresas. As operações atuais podem ser monitoradas e comparadas com as operações
passadas, previsões de futuras operações podem ser feitas racionalmente, novos
processos podem ser inventados, e os sistemas de nível operacional podem ser
alterados para suportar estes processos. O Data Warehouse também pode armazenar
um grande número de dados históricos que auxiliam as empresas na tomada de
decisões. Oferece o benefício de ser único, com dados centralizados mas mantendo
uma estrutura de cliente/servidor. Além disso, Data Warehouse são sistemas para
empresas grandes, o que melhora a distribuição das informações internamente;
b) qualidade dos dados: a segunda vantagem mais mencionada foi a melhor qualidade dos
dados. O Data Warehouse proporciona consultas em dados de maior qualidade o que
traz maior consistência, acuracidade e documentação, além de aumentar a
produtividade dos usuários através de utilização de ferramentas OLAP e de Data
Mining;
c) acesso rápido: o Data Warehouse permite aos usuários recuperar rapidamente os dados
necessários para suas consultas, eliminando o trabalho de busca em vários sistemas de
23
nível operacional pois todos os dados estão em um único local, sendo assim o tempo
de resposta deve ser reduzido;
d) facilidade de uso: a maioria das ferramentas de consultas facilitam o acesso aos dados
pois trabalham com interfaces gráficas e comandos pré-definidos o que torna a análise
das informações armazenadas no Data Warehouse uma tarefa intuitiva para os usuários
finais;
e) separa as operações de decisão das operações de produção: como os dados do Data
Warehouse ficam separados dos dados dos sistemas de nível operacional mas são
continuamente atualizados com informações sobre as operações realizadas, os gerentes
e analistas de negócios podem fazer análises nestes dados sem sobrecarregar os
sistemas de nível operacional;
f) vantagem competitiva: o Data Warehouse auxilia o administrador a gerenciar melhor a
empresa utilizando o conhecimento incorporado, o qual possibilita a empresa ser mais
competitiva, entendendo melhor as necessidades dos clientes, e conhecendo mais
rapidamente as demandas de mercado. Esta vantagem pode compensar o grande custo
de se implantar um Data Warehouse;
g) custo de operação: o Data Warehouse oferece uma boa base para o desenvolvimento de
novos sistemas de nível operacional, além de eliminar o uso de arquivos baseados em
papéis e uma vez coberto o investimento inicial o grupo de tecnologia da informação
da empresa normalmente consome menos recursos do que antes da implantação do
Data Warehouse pois as informações ficam centralizadas e podem ser acessadas
facilmente pelos usuários finais;
h) administração do fluxo da informação: o Data Warehouse recebe uma grande
quantidade de dados de várias fontes operacionais e envia dados para várias aplicações
front-end. Para se adaptarem as mudanças nas regras de negócio das empresas, os
sistemas de nível operacional e as estruturas dos dados são constantemente
modificados. No Data Warehouse isto dificilmente ocorre pois os metadados auxiliam
na configuração dos dados para que eles atendam os novos requisitos da empresa;
i) habilita o processamento paralelo: o processamento paralelo ajuda os usuários a
realizar consultas no Data Warehouse mais rapidamente, pois suporta grandes
demandas em ambientes cliente/servidor, onde os usuários podem fazer perguntas ou
24
consultas simultâneas que exijam um processamento intensivo. Com o processamento
paralelo o Data Warehouse oferece uma melhor relação de preço/performance;
j) infra-estrutura computacional: o Data Warehouse ajuda as organizações a montar uma
infra-estrutura que pode suportar mudanças nos sistemas e na estrutura dos seus
negócios;
k) valores quantitativos: outra vantagem é que o Data Warehouse pode mostrar um
retrospecto realista da evolução da empresa pois possui medidas quantitativas que
podem ser comparadas e analisadas com períodos de vários anos;
l) segurança: o fato dos usuários do Data Warehouse não acessar diretamente as bases de
dados dos sistemas, aumenta a segurança destes dados além de diminuir o número de
acessos aos mesmos.
4.6.2 DESVANTAGENS
As principais desvantagens encontradas são:
a) complexidade de desenvolvimento: uma empresa não pode simplesmente comprar um
Data Warehouse. É necessário construir um ambiente composto de hardware e
software como banco de dados, ferramentas de extração de dados, ferramentas de
recuperação dos dados, etc. Um Data Warehouse deve atender as necessidades
específicas de uma empresa. Na construção deste ambiente específico é necessário ter
muito conhecimento das necessidades pré-definidas para a construção da estrutura,
definições e fluxo dos dados, assim como na escolha do hardware e software
necessários. O desenvolvimento de um Data Warehouse requer um senso de
antecipação sobre as necessidades futuras dos usuários assim como a previsão de
futuras alterações nas regras de negócio da empresa. Definir como aumentar o Data
Warehouse por causa da demanda de dados, tanto em volume como em complexidade
torna o seu desenvolvimento muito complexo e requer uma equipe de especialistas;
b) Tempo de desenvolvimento: como é uma tarefa complexa é natural que também seja
demorada. Estudos indicam que em média um ambiente completo de Data Warehouse
demora de dois a três anos para ficar pronto, o que pode ser muito tempo para uma
empresa que necessita de um ambiente de suporte a decisão em um curto espaço de
tempo;
25
c) alto custo de desenvolvimento e administração: um Data Warehouse pode consumir
milhares de dólares até que esteja pronto para ser utilizado e continuará a consumir
recursos durante toda sua "vida" útil, pois necessitará de constantes manutenções;
d) treinamento: uma das desvantagens é que os usuários do Data Warehouse devem ser
constantemente treinados e comunicados das mudanças no Data Warehouse. Isto se
deve ao fato de que é importante que todos estejam aptos a retirar o máximo de
informações possíveis que o Data Warehouse oferece.
4.7 PROPOSTA DE DESENVOLVIMENTO DE DATA WAREHOUSE SEGUNDO W.H. INMON.
Segundo W. H. Inmon, os Data Warehouse não são construídos de uma só vez. Em vez
disso, eles são projetados e povoados passo a passo, sendo, portanto, evolucionários e não
revolucionários. Os custos de construir um Data Warehouse de uma vez, os recursos
necessários e o transtorno causado ao ambiente, tornam imperativo que o Data Warehouse
seja construído de maneira ordenadamente iterativa, passo a passo[INM1997].
A figura 4 apresenta o processo típico de construção de um Data Warehouse. No dia
um, há um grupo de sistemas efetuando, basicamente, processamento operacional. No dia
dois, as primeiras tabelas da primeira área de interesse do Data Warehouse são povoadas.
Nesse ponto, uma certa dose de curiosidade aflora, e os usuários começam a descobrir os Data
Warehouses e o processamento analítico.
No dia três, mais áreas do Data Warehouse são povoadas e, com o maior povoamento,
surgem mais usuários. Uma vez que os usuários descobrem que há uma fonte integrada de
dados fácil de alcançar e que apresenta uma base histórica construída para a pesquisa de dados
ao longo do espectro de tempo, há mais do que curiosidade. Aproximadamente nesse
momento, o sério analista SAD é atraído para o Data Warehouse.
No dia quatro, à medida que mais áreas do Data Warehouse são povoadas, alguns dos
dados que residiam no ambiente operacional são colocados de forma apropriada no Data
Warehouse. E agora, o Data Warehouse é “descoberto” como uma fonte para o processamento
analítico. Surgem, repentinamente, todos os tipos de aplicações SAD. Na realidade, começam
a aparecer tantos usuários e tantas solicitações de processamento aliados ao grande volume de
26
dados agora residentes no Data Warehouse, que alguns usuários começam a ser afastados pelo
trabalho e pelo esforço necessários para alcançar o Data Warehouse. A competição para
chegar ao Data Warehouse torna-se um obstáculo a sua utilização.
No dia cinco, bancos de dados departamentais (datamart ou OLAP) começam a
florescer. Na opinião dos departamentos, é mais barato e mais fácil efetuar o respectivo
processamento trazendo os dados do Data Warehouse para seus próprios ambientes
departamentais de processamento. À medida que os dados são transferidos para o nível
departamental, uns poucos analistas de SAD são atraídos.
No dia seis, acontece a corrida aos sistemas departamentais. É mais barato, mais rápido
e mais fácil obter os dados departamentais do que os dados do Data Warehouse. Logo, os
usuários abandonam, gradativamente, os detalhes do Data Warehouse pelo processamento
departamental.
No dia n, a arquitetura encontra-se plenamente desenvolvida. Tudo o que resta do
conjunto original de sistemas de produção é o processamento operacional. O Data Warehouse
está pleno de dados. Há uns poucos usuários diretos do Data Warehouse. Há vários bancos
departamentais. A maior parte do processamento analítico de SAD ocorre no nível
departamental, porque é mais fácil e mais barato obter ali os dados necessários para o
processamento.
É claro que a evolução do dia um ao dia n leva um longo tempo. Normalmente, vários
anos. E, durante todo o processo de passar do dia um para o dia n, o ambiente SAD está em
funcionamento.
27
Figura 4 - Fenômeno dia 1-dia n
Fonte: [INM1997]
4.8 ROTEIRO PARA PROJETO DE DATA WAREHOUSE SEGUNDO W.H. INMON.
Existem dois importantes aspectos vinculados à construção do Data Warehouse – o
projeto de interface com os sistemas de nível operacional e o projeto do Data Warehouse
propriamente dito. De certa forma, projeto não é a descrição exata do que acontece durante a
construção do Data Warehouse, uma vez que ele é construído de modo heurístico. Primeiro, o
Data Warehouse é povoado com alguns dados. Tais dados são, então, usados e
minuciosamente examinados pelo analista de SAD. Em seguida, com base no retorno
28
proporcionado pelo usuário final, os dados são modificados e/ou outros dados são adicionados
ao Data Warehouse[INM1997].
O ciclo de retorno tem continuidade por toda a vida do Data Warehouse. É um engano
pensar que os enfoques de projeto que funcionaram no passado serão úteis na construção do
Data Warehouse. Os requisitos para a criação do Data Warehouse não podem ser conhecidos
até que ele esteja parcialmente povoado e sendo usado pelo analista de SAD. Portanto, ele não
pode ser projetado do mesmo modo pelo qual são construídos os sistemas clássicos baseados
em requisitos. Por outro lado, também constitui um engano pensar que não prever requisitos
seja uma boa idéia. A realidade se encontra em algum ponto intermediário.
4.8.1 JUSTIFICATIVA DE CUSTOS
Primeiramente, têm-se que aprovar o projeto de investimento junto aos diretores da
empresa. Um dos aspectos interessantes do Data Warehouse é que a justificativa de custos do
warehouse, normalmente, não é feita mediante um critério previamente estabelecido de
retorno sobre o investimento. Para efetuar tal análise seria necessário que os benefícios do
Data Warehouse fossem conhecidos antes da construção destes.
Na maioria dos casos, os verdadeiros benefícios do Data Warehouse não são
conhecidos ou mesmo previstos no momento da construção porque o warehouse é usado de
forma inteiramente diferente de outros dados e sistemas. A atualização do Data Warehouse
ocorre de um modo diferente do resto do processamento de informações. De fato, o analista
de SAD não pode dizer quais as possibilidades e potencialidades do Data Warehouse até que a
primeira iteração deste seja criada e esteja disponível. Então, uma vez que o analista de SAD
ponha as mãos no Data Warehouse, ele poderá começar a liberar o potencial de
processamento SAD.
Portanto, técnicas clássicas de análise de retorno sobre o investimento simplesmente
não se aplicam ao ambiente de Data Warehouse. No entanto, há a possibilidade do Data
Warehouse ser construído de forma incremental. A primeira iteração pode ser feita
rapidamente e mediante uma relativamente pequena quantia de dinheiro. Uma vez que a
primeira porção do Data Warehouse tenha sido construída e povoada, o analista pode começar
29
a explorar as possibilidades. É nesse ponto que o analista começa a justificar os custos de
desenvolvimento do warehouse.
4.8.2 BUSCA PELOS DADOS OPERACIONAIS.
No início, há dados operacionais totalmente trancados nos sistemas existentes. É
tentador pensar que a criação do Data Warehouse consiste em apenas extrair dados
operacionais e inseri-los no warehouse. Nada poderia estar mais longe da verdade.
A figura 5 mostra uma representação simples de dados do ambiente de sistemas já
existentes para o Data Warehouse. Podemos verificar que várias aplicações irão contribuir
para o Data Warehouse.
Figura 5 - Representação simplificada da passagem dos dados do ambiente operacional
para o Data Warehouse.
Fonte: [INM1997]
Por inúmeras razões , a figura 5 pode ser considerada exageradamente simplista. A
idéia de que a construção de Data Warehouse consiste meramente em um processo de
extração tem como erro básico o fato de que os dados existentes no ambiente operacional não
são integrados. A figura 6 demonstra a falta de integração comum ao ambiente dos sistemas
existentes.
30
Figura 6 - Falta de integração dos sistemas existentes
Fonte: [INM1997]
Na época da criação das aplicações existentes, a possibilidade de futura integração
destas não era considerada. Cada aplicação possuía seu conjunto único e particular de
requisitos e, durante o processo de desenvolvimento, as demais aplicações não eram levadas
em conta. Portanto, não é de admirar que alguns dos mesmos dados existiam em vários
lugares com nomes diferentes; que alguns dados sejam rotulados da mesma maneira em locais
diferentes mas que continuem sendo os mesmos dados; e que alguns dados apresentem o
mesmo nome em todos os lugares mas tenham diferentes unidades de medida, e assim por
diante. Tentar extrair dados dos diversos lugares em que eles existem é um problema muito
complexo.
Essa questão de falta de integração, é o pesadelo dos programadores responsáveis
pelos programas de extração. Há mil e um detalhes a observar na programação apenas para
extrair dados do ambiente operacional de forma concreta, conforme ilustrado na figura 7.
31
Figura 7 - Integração dos dados dos sistemas existentes para o Data Warehouse
Fonte: [INM1997]
Um exemplo simples de falta de integração é o fato de os dados não poderem ser
codificados de forma coerente, como exemplificando na codificação como “0/1”. Na
realidade, não importa como será feita de forma coerente. À medida que os dados passam para
o Data Warehouse, os diferentes valores precisam ser corretamente decodificados e
recodificados com o valor apropriado.
A transformação de campos é outra questão de integração. O mesmo campo existe em
quatro aplicações com quatro nomes diferentes. Para que os dados sejam passados
corretamente para o Data Warehouse é necessário que ocorra um rastreamento comparativo
entre os diferentes campos existentes e os campos do Data Warehouse.
Esses poucos exemplos apenas dão uma leve idéia da questão de integração e não são,
em si, complexos. Mas quando eles são multiplicados pelos milhares de arquivos e sistemas
existentes, a questão de integração se torna extremamente complexa e onerosa.
Contudo, a integração (ou falta de) dos sistemas existentes não é a única dificuldade na
passagem de dados do ambiente dos sistemas operacionais existentes para o ambiente de Data
Warehouse. Outro importante problema diz respeito ao acesso eficiente aos dados dos
sistemas existentes. Como pode o programa que varre os sistemas existentes saber se um
arquivo foi varrido anteriormente? Há uma enorme quantidade de dados no ambiente de
32
sistemas existentes e a tentativa de efetuar varreduras completar toda vez que é feita uma
varredura para o Data Warehouse é antieconômica e pouco realista.
Há três tipos de carga que podem ser feitos do ambiente operacional para o Data
Warehouse:
a) o carregamento de dados históricos;
b) o carregamento de dados de valor corrente no ambiente operacional;
c) o carregamento de alterações do Data Warehouse a partir de alterações (atualizações)
que tenham ocorrido no ambiente operacional desde a última atualização do Data
Warehouse.
Como regra, o carregamento de dados históricos representa um desafio menor, uma
vez que ele é feito com freqüência.
Da mesma forma, carregamento de dados do ambiente operacional existente também
constitui grande desafio porque precisa ser feito apenas uma vez. Em geral, o ambiente de
sistemas operacionais existentes pode ser descarregado em um arquivo seqüencial e este pode
ser descarregado no Data Warehouse sem acarretar danos ao ambiente online.
O carregamento de dados durante o processo normal – enquanto são efetuadas
alterações sobre o ambiente operacional – consiste no maior desafio ao arquiteto de dados.
Não é fácil realizar o rastreamento eficiente e o tratamento dessas alterações. A varredura de
arquivos existentes, é portanto, uma importante questão a ser enfrentada pelo arquiteto do
Data Warehouse.
Há cinco técnicas comumente usadas para limitar a quantidade de dados pesquisados,
conforme demonstrado na figura 8. A primeira técnica consiste em pesquisar dados que
apresentem marcas de tempo. Quando uma aplicação registra o momento da última alteração
ou atualização em um registro, a varredura para o Data Warehouse pode ser executada de
forma bem eficiente, porque os dados que apresentarem datas diferentes das procuradas não
precisarão ser tocados. No entanto, os dados existentes, em geral, só incidentalmente recebem
marcas de tempo.
33
Figura 8 - Métodos de varredura dos arquivos da base operacional
Fonte: [INM1997]
A segunda técnica de limitação dos dados a serem pesquisados para uma extração para
o Data Warehouse consiste em varrer um arquivo “delta”. Um arquivo delta é um arquivo
criado por uma aplicação e que contém apenas as alterações efetuadas por esta. Quando é
possível contar com um arquivo delta, o processo de varredura se torna muito eficiente uma
vez que os dados que não forem candidatos à varredura jamais serão tocados. Contudo,
poucas aplicações geram arquivos delta.
A terceira técnica consiste em varrer um arquivo de auditoria ou log. O arquivo de log
ou de auditoria contém basicamente dados do mesmo tipo dos de um arquivo delta. Todavia,
há algumas diferenças significativas. Muitas vezes, o departamento de operação protege os
arquivos de log porque eles são necessários aos processos de recuperação. O departamento de
operação não tem grande interesse em que seu arquivo de log seja utilizado com outros
propósitos. Outro obstáculo relacionado com as fitas de log consiste no fato de o formato
34
interno ser gerado para atender os objetivos de um sistema e não aos de uma determinada
aplicação. Talvez seja necessário contar com algum guru tecnológico que possa criar uma
interface para os dados contidos na fita de log. Outra falha dos arquivos de log é que,
geralmente, eles contém muitas informações além daquelas procuradas pelo desenvolvedor do
Data Warehouse. Os arquivos de auditoria apresentam muitos dos problemas relacionados
com os arquivos de log.
A quarta técnica empregada no gerenciamento da quantidade de dados pesquisada
durante a extração para o Data Warehouse consiste em modificar o código da aplicação. Essa
opção jamais é aplaudida, sobretudo quando o código da aplicação é antigo e complicado.
A última opção consiste em moldar um arquivo de imagem anterior e posterior.
Segundo esta opção, um instantâneo de um banco de dados é tirado no momento da extração.
Quando for necessário realizar outra extração, outro instantâneo é tirado. Os dois instantâneos
serão comparados serialmente entre si para que seja detectada a atividade transcorrida. Esse
método é pesado, complexo e demanda uma quantidade excessiva de recursos.
Porém, integração e performance não são as únicas discrepâncias fundamentais que
impedem que o processo de extração simples seja utilizado para construir o Data Warehouse.
Uma terceira importante dificuldade está relacionada à alteração dos parâmetros de tempo,
conforme ilustrado pela figura 9.
Figura 9 - Alteração de parâmetros de tempo
Fonte: [INM1997]
35
Os dados operacionais existentes são, quase sempre, dados de valor corrente. Dados de
valor corrente são dados cuja exatidão é válida para o momento do acesso e que podem ser
atualizados. Esses dados devem apresentar um elemento de tempo vinculado a eles. Portanto,
à medida que os dados passam do ambiente de sistemas operacionais existentes para o
ambiente de Data Warehouse, é necessário que seja feita uma significativa alteração sobre
eles.
Outra importante observação a ser feita durante a passagem dos dados do ambiente de
sistemas operacionais existentes para o ambiente de Data Warehouse é referente à
necessidade de gerenciar o volume de dados. É preciso efetuar condensação de dados; de
outro modo, o volume de dados contidos no Data Warehouse logo ficará grande demais para
ser controlado. A condensação dos dados deve ser iniciada no momento da extração. A figura
10 mostra uma forma simples de condensação dos dados do Data Warehouse.
Figura 10 - A condensação dos dados é um fator vital para o gerenciamento dos dados
do Data Warehouse
Fonte: [INM1997]
4.8.3 DADOS EXTERNOS / NÃO ESTRUTURADOS
A maioria das empresas ergue seus primeiros empreendimentos de Data Warehouse
sobre os dados cuja fonte são sistemas existentes (ou seja, sobre dados internos à corporação).
Em quase todos os casos, os dados provenientes dos sistemas existentes podem ser
36
classificados como dados internos e estruturados. Os dados têm origem no interior da empresa
e foram moldados segundo um formato regularmente encontrado.
Mas há toda uma enorme quantidade de dados que podem ser usados de forma legítima
por uma empresa e que não são gerados pelos próprios sistemas da empresa. Essa classe de
dados é chamada de dados externos e geralmente adentra a empresa em um formato não-
estruturado e imprevisível.
O Data Warehouse é o local ideal para armazenar dados externos e não-estruturados.
Quando os dados externos e não-estruturados adentram a empresa de forma indisciplinada, a
identidade da fonte de dados é perdida, e não há qualquer coordenação quanto ao uso
ordenado dos dados.
Tradicionalmente, quando os dados externos não são inseridos no Data Warehouse,
eles entram na empresa por meio do microcomputador. Não há nada de errado nisso, por estar
entrando por este nível. Mas quase sempre, quando os dados entram pelo nível do
microcomputador, isso é feito manualmente por meio de uma planilha e absolutamente não há
cuidado em, além de captar os dados, captar também as informações sobre sua fonte
[INM1997].
Um outro problema relacionado com o enfoque de simplesmente deixar acontecer,
com relação ao tratamento de dados externos, é que mais tarde é difícil reutilizar os dados.
Eles são introduzidos nos sistemas da empresa, usados uma vez e, então, desaparecem.
Mesmo umas poucas semanas depois, é difícil tornar a acessar os dados para nova utilização,
e isso é inoportuno, porque a maioria dos dados provenientes de fontes externas é bastante útil
por um longo período.
4.8.4 INSERINDO DADOS NÃO-ESTRUTURADOS
Há várias questões relacionadas ao uso e armazenamento de dados externos e não-
estruturados no Data Warehouse. Um dos problemas dos dados não-estruturados é a
freqüência de disponibilidade. Ao contrário dos dados de publicação interna, não há um
padrão real de publicação de dados externos. A freqüência de publicação é um problema sobre
o qual deve ser estabelecido monitoramento constante para garantir que os dados certos sejam
obtidos.
37
O segundo problema com os dados externos é a forma dos dados. A forma dos dados
externos é totalmente indisciplinada. Para que eles possam ser usados, e para que eles sejam
colocados no Data Warehouse, é preciso efetuar uma certa quantidade de reformatação dos
dados externos para passá-los para uma forma internamente aceitável e utilizável.
O terceiro fator que dificulta a obtenção de dados externos é a sua imprevisibilidade.
Dados externos podem vir de praticamente qualquer fonte a quase qualquer momento. A
natureza imprevisível da disponibilidade dos dados externos torna muito difícil a sua captação
consistente e completa.
Além dos dados externos que podem ser publicados em um artigo de uma revista ou
em um relatório de um consultor, há toda uma classe de dados não-estruturados que só agora
com o Data Warehouse, podem ser armazenados.
Os dois tipos mais comuns de dados não-estruturados ocorrem na forma de imagens e
voz. Os dados de imagem são armazenados como gráficos. Os dados de voz são dados
armazenados digitalmente e com a possibilidade de reconversão para um formato de voz. As
questões referentes aos dados de imagem e aos dados de voz originam-se sobretudo na
tecnologia. A tecnologia para captura e tratamento de dados de imagem e voz não é tão
madura quanto a tecnologia mais convencional. Além disso, mesmo quando imagem e voz
podem ser capturadas, seu armazenamento demanda enormes quantidades de DASD, e sua
reutilização e exibição ou audição pode ser difícil e lenta.
Contudo, há muitas possibilidades de captação de informações não-estruturadas e de
seu armazenamento em um Data Warehouse.
4.8.5 GRANULARIDADE
“A mais importante questão de projeto que o desenvolvedor do Data Warehouse
precisa enfrentar diz respeito à definição da granularidade do Data Warehouse. Quando a
granularidade de um Data Warehouse é propriamente estabelecida, os demais aspectos de
projeto e implementação fluem tranqüilamente; quando ela não é estabelecida, todos os outros
aspectos se complicam” [BAR1997].
38
Granularidade refere-se ao nível de detalhe em que as unidades de dados são mantidas
no Data Warehouse. Quanto maior o nível de detalhes, menor o nível de granularidade. Esta é
uma questão fundamental no projeto de um Data Warehouse porque afeta diretamente o
volume de dados armazenados no Data Warehouse e ao mesmo tempo, o tipo de consulta que
pode ser respondida. O volume de dados contidos no Data Warehouse é balanceado de acordo
com o nível de detalhe de uma consulta [CAM1997].
39
5 SEAGATE INFO 7
5.1 INTRODUÇÃO
Para implementar os conceitos mencionados na fundamentação exposta, foi utilizada a
ferramenta Seagate Info 7, da empresa Seagate Softwares. Os componentes da ferramenta,
descritos a seguir foram utilizados, e ao se completar a implantação do Data Warehouse,
todos serão utilizados.
O Seagate Info 7 é um software baseado na estrutura cliente-servidor: que provê
acesso seguro às informações para as pessoas de uma organização, bem como projetado a
satisfazer as demandas dos usuários e desenvolvedores, oferecendo uma interface fácil de
usar, juntamente com componentes finais muito poderosos. Seagate Info permite que usuários
criem relatórios e consultas e após isto, que possam compartilhar o resultado com outros
usuários. Cada usuário em um grupo de trabalho tem a possibilidade de acessar e usar as
informações através do Info Desktop ou do Info WebAcess. O Info Desktop tem uma
interface semelhante a interface de email, que é dividida em um número de pastas. Membros
de determinados grupos tem acesso a vários relatórios e consultas disponíveis nestas pastas. O
Seagate Info não só permite compartilhar, bem como distribuir a carga do processamento que
podem ser executadas por outras máquinas. Estas máquinas são conhecidas como Info
Servers. Com isto, os usuários podem programar a execução das tarefas, permitindo que
possam executar outras tarefas durante este processo de carga das informações[SEA1999].
Enquanto que o Info Desktop permite aos usuários uma intuitiva e poderosa interface
para a obtenção de informações de suporte à decisão que estes necessitam, o poder real do
Seagate Info encontra-se nos módulos auxiliares. O Info Administrator, Info APS, Info
Sentinel, e Info Servers conjuntamente provêm vários controles sobre o tráfego da rede,
atividade do banco de dados, usuários, máquinas etc[SEA1999].
A seguir será explicada resumidamente a função de cada componente do Seagate Info
7.
40
5.1.1 INFO DESKTOP
Segundo [SEA1999], o Info Desktop é a interface primária do usuário. Ela permite ao
usuário o acesso a um limite de ferramentas, relatórios, consultas, e programas. Ele usa uma
interface semelhante ao sistema de email, para organizar, programar, visualizar e analisar
relatórios, consultas, cubos e programas. Todos os usuários, que tiverem seus micros
conectados a uma LAN (Local Área Network) ou WAN (Wired Área Network), podem
acessar informações de grupos de trabalho para as decisões do dia-a-dia com o Info Desktop.
O administrador do sistema pode configurar cada desktop para configurar as
necessidades de cada usuário individual e o acesso aos dados, e a segurança necessária a
organização.
Uma configuração completa do Info Desktop contém:
a) View: visualização dos resultados dos relatórios;
b) Schedule: programar(escalonar) requisição de processamento das informações;
c) Query: gera consultas ad-hoc e cria relatórios a partir de consultas;
d) Report: criação de relatórios.
5.1.2 INFO ADMINISTRATOR
Conforme [SEA1999], o Info Administrator é a ferramenta de controle usada para
parametrizar o Seagate Info na empresa. O Info Administrator é utilizado para:
a) Montar o calendário de atividade da empresa e programação de execução de modelos
de acesso(relatórios, consultas, etc);
b) configurar as respostas do sistema a eventos, segurança, e funções de auditoria;
c) adicionar, modificar, e remover usuários, e associações de usuários, bem como direitos
de grupos de usuários;
d) preparar eventos para que possam ser usados como tarefas;
e) adicionar, modificar, ativar, desativar, e remover Info Servers, Info Server Groups, e
Info Servers Classes.
Para usar o Info Administrator, necessariamente deve-se estar conectado a um Info
APS. Quando conectado, o Info Administrator mostra uma caixa de diálogo contendo todos os
parâmetros de cada Info APS.
41
5.1.3 INFO APS
Segundo [SEA1999], o Aplication Process Server - Info APS, é a estrutura de
escalonamento para relatórios, consultas, cubos e programas. Tem a função de:
a) delegar tarefas aos Info Servers presentes para processamento;
b) controlar as tarefas em cada Info Server;
c) registrar os retornos dos códigos de execução.
Neste estágio somente foi utilizado um Info Server, pois notou-se que suportava o
volume de dados a ser processado.
5.1.4 INFO SERVER
Segundo [SEA1999], o Info Server é um software instalado em máquina designada a
executar as tarefas.
5.1.5 INFO OLAP AGENT
O Info Olap Agent funciona similarmente ao Info Agent (programa residente em
memória que aciona os programas necessários a execução das tarefas). Porém, diferentemente
do Info Agent, somente é utilizado quando um usuário escalona um cubo para ser executado.
Sendo um cubo escalonado, o Info APS chama o Info OLAP Agent em um Info OLAP Server
disponível. Neste ponto, o Info OLAP Agent pega o objeto do cubo e cria uma instância, que
consiste em um padrão de arquivos que definem a estrutura de dados no cubo. A partir deste
momento o cubo pode ser visualizado por outros usuários ou grupos de usuários através do
Info Desktop, ou pelo browser, sendo necessário instalar para isto o Info
WebAccess.[SEA1999]
5.1.6 INFO SENTINEL
Considerado como o “coração” da comunicação de dados pela rede. Está presente em
qualquer tipo de instalação, mesmo sendo a mínima, pois é vital para o funcionamento do
sistema.
42
O Info APS usa o Info Sentinel para permanecer em constante comunicação com o(s)
Info(s) Server(s), as máquinas que efetivamente rodam as tarefas escalonadas. O Info Sentinel
no Info Server retorna informações para o Info APS sobre:
a) o restante do trabalho que foi completado;
b) códigos de erro decorrentes dos trabalhos;
c) outras variáveis que indicam estado de atividade.
O Info APS usa estas informações para melhorar estes enfileiramentos, delegações e
funções de notificação.[SEA1999]
5.1.7 INFO WORKSHEET
Esta ferramenta é utilizada para a manipulação dos cubos gerados a partir do Info
Server. Com esta ferramenta é possível manipular as dimensões até que se chegue a visão
necessária dos dados.
43
6 DESENVOLVIMENTO DA PROPOSTA
6.1 NECESSIDADES DA EMPRESA
As necessidades da Indústria de Relógios Herweg S.A:
a) procurar por um meio que possibilite a obtenção de dados estatísticos que auxiliem na
tomada de decisão, acompanhando o processo de implantação do sistema corporativo,
verificando a eficiência destes e também a produção alcançada pela empresa, bem
como a produção dos usuários relacionados ao sistema corporativo;
b) fornecer dados concretos e de fácil compreensão para os superiores(diretoria), fazendo
com que estes verifiquem o sucesso do projeto de implantação do Data Warehouse;
c) possibilitar aos usuários uma ferramenta de fácil compreensão, e que não se limite a
ser usada somente dentro da empresa, cabendo a este sistema possibilitar que sejam
levados a campo.
6.2 APLICAÇÃO DA METODOLOGIA DE W.H.INMON
Como trata-se de uma área nova que estava sendo informatizada na empresa, através
do sistema corporativo Sapiens, os dados necessários foram gerados, não havendo dados de
outros sistemas que houvesse a necessidade de agrupar.
Com isto, foram povoadas as tabelas da área de produção, chegando a ser povoadas as
tabelas necessárias, em que se pudesse extrair informação para análise. Até esta fase,
concluiu-se os dois primeiros passos da geração do Data Warehouse, mencionado por
Inmon[INM1997], como sendo o primeiro e o segundo dia de construção do Data Warehouse.
O terceiro dia, ou dia 3, como Inmon [INM1997] coloca, já foi alcançado, com a
demonstração da utilidade do Data Warehouse para usuários do setor de Vendas da empresa.
O interesse se criou e a continuação do Data Warehouse nesta área também é certa.
Os outros dias serão conseqüência, que não será considerada no estágio, pois este está
voltado a implantar a tecnologia para que depois possa ser aprimorada em todas as áreas da
empresa.
44
6.3 ROTEIRO PARA PROJETO SEGUNDO W.H.INMON.
6.3.1 JUSTIFICATIVA DE CUSTOS
Com a conclusão do protótipo, notou-se que se torna viável o investimento,
considerando-se o valor da informação gerada. Com a informação pronta para ser utilizada,
pode-se fazer com que os tomadores de decisão gastem mais tempo aplicando os
conhecimentos contidos nos cubos, sobre os casos do dia-a-dia.
6.3.2 BUSCA PELOS DADOS OPERACIONAIS
Por se tratar de uma construção de Data Warehouse baseado em um sistema criado
recentemente, não houve a necessidade de integrar os dados não consistentes
6.3.3 DATA WAREHOUSE E OS MODELOS DE DADOS
O modelo de dados operacional encontra-se na figura 23. As descrições dos campos
das tabelas contidas na figura 23, estão assim descritas:
a) E900CMO: contém os componentes de produção envolvidos em determinada ordem
de produção. A descrição dos campos está descrita na figura 11;
Figura 11 - Tabela E900CMO
45
b) E205DEP: contém o cadastro dos depósitos. A descrição dos campos está descrita na
figura 12;
Figura 12 - Tabela E205DEP
c) E093ETG: contém o cadastro dos depósitos. A descrição dos campos está descrita na
figura 13;
Figura 13 - Tabela E093ETG
d) E900COP: contém os dados que identificam a ordem de produção.A descrição dos
campos está descrita na figura 14;
46
Figura 14 - Tabela E900COP
e) E083ORI: contém o cadastro de origens de produção. A descrição dos campos está
descrita na figura 15.
47
Figura 15 - Tabela E083ORI
f) E075PRO: contém o cadastro de produtos. A descrição dos campos está descrita na
figura 16;
48
Figura 16 - Tabela E075PRO
49
g) E070EMP: contém o cadastro de empresas. A descrição dos campos está descrita na
figura 17;
Figura 17 - Tabela E070EMP
h) E900EOQ: contém as movimentações das ordens de produção. A descrição dos
campos está descrita na figura 18;
50
Figura 18 - Tabela E900EOQ
i) E001TNS: contém o cadastro das transações. Neste estágio foram utilizadas as
transações de movimento de estoques. A descrição dos campos está descrita na figura
19.
51
Figura 19 - Tabela E001TNS
52
continuação da figura 19.
53
Os modelos de construção dos cubos encontram-se no anexo 1.
6.3.4 VANTAGENS
Segue abaixo relação de vantagens do protótipo desenvolvido:
a) possibilidade de transportar os dados gerados pelo cubo para uma estação que tenha o
Info Desktop instalado. Com isto, poder-se-á futuramente, por exemplo, se for
implementado na área de Vendas, fazer com que estes dados sejam levados para serem
analisados juntamente com os representantes e vendedores;
b) armazenamento do conhecimento referente ao modo de se analisar o andamento da
produção.
6.3.5 FUNCIONAMENTO DO PROTÓTIPO
Neste tópico serão apresentadas as telas que foram acessadas para a elaboração dos
protótipos de cubos.
Figura 20 - Info Desktop
54
Na figura 20, é apresentada a tela do Info Desktop. Como sendo a tela principal para o
acesso aos outros módulos da ferramenta. A partir desta tela foram utilizadas as seguintes
funções e telas, conforme segue abaixo:
a) Info Cube Designer: a partir desta tela foi possível a elaboração dos cubos
propriamente ditos;
b) View: para a visualização do cubo gerado. Esta função ativa o Info Worksheet, que é a
tela de manipulação do cubo;
c) Schedule: função que programa o cubo para ser executado em determinado horário..
d) Na figura 21 é apresentada a tela inicial do Info Worksheet.
Figura 21 - Info Worksheet
e) Ao pressionar sobre o botão , é possível alterar as dimensões do cubo, em relação
ao que está sendo apresentado. Existem as opções de seleção múltipla e simples dos
dados inseridos na dimensão, conforme mostra a figura 22.
55
Figura 22 - Tela de seleção de dimensões do cubo
56
Figura 23 - Modelo de dados do nível operacional.
E205DEPCODEMPCODDEP
DESDEPABRDEPDEPCPRESTNEGCODFILCTAREDSITDEPCODCCUDISXPL
E900CMOCODEMP (FK)CODORI (FK)NUMORP (FK)CODETG (FK)SEQCMP
CODCMP (FK)CODDERQTDPRVQTDRESQTDUTIQTDSERQTDRTSUNIMEDCODTNS (FK)CODDEPCODLOTCODCCUSOLCMPNUMSEP
E070EMPCODEMP
NOMEMPSIGEMPCODGRECODMPCCODPAIEANEMPVENEMPESTEMPRECEMPCPREMPPAGEMPCXBEMPCTBEMPEFIEMPPATEMPPRDEMPCUSEMPESPDEPESPPROPRDMASPRDMULTIPPEREISEMP
E001TNSCODEMP (FK)CODTNS
DESTNSDETTNSLISMODACEMANCODFCTCRICTBVENUPDVENTCFVENDEVVENFATVENACPVENICMVENIBIVENFREVENSEGVENEMBVENENCVENOUTVENLIRVENIRFVENISSVENDEPVENEBPVENMS1VENMS2VENTPTVENMOEESTEOSESTMOVESTCONESTCOCESTCOFESTPRMESTPRUESTPRRESTVMVESTTRFESTDUMESTDEPRECDECRECADCRECTPBRECASHRECHISCPRUOCCPRHENCPRTCFCPRDEVCPRAOCCPRLIRCPRIRFCPRISSCPRDEPCPRTPTCPRMOEPAGDECPAGADFPAGTPBPAGASHPAGHISCXBDECCXBTRFCXBCHEFICEOSPCPEOSCHAEOSPAGVBCCODREGFORRATCTAREDCTARCRCTAFDVCTAFCRSITTNSCODNTGVENIFUVENTNFCPRIFUCPRIBICPRTNFPAGTIRUSUGERDATGERHORGER
E900COPCODEMPCODEMP (FK)CODORI (FK)NUMORP
CODPRO (FK)CODPVPCODFILNUMPEDDTPINIDTPFIMDTRINIDTRFIMCODFAMCODROTTMPPRVSITORPROTALTSITANTULTGOPTIPORPDATGERQTDPRVQTDRE1QTDRE2QTDRE3OBSORPOBSOR2NUMPRILOTTEC
E093ETGCODEMP (FK)CODEMPCODETG
DESETGABRETGCTAREDCODCCUCODORI (FK)TIPETGUTICELPTOIQLMOVAUTCODLOCMOVGOPCTARCR
E083ORICODEMPCODORI
DESORINUMORITIPPRODEPPADBXAAGRBXAMOVRESCMPMOVPARGEROPRCTRSEPCTRLOTCTRQLDCTRRFGCTRGOPGERPEDAGRIPDAGRNBCDISNECGEREANSITCALCODPVPCNFNECINIPVPORPDERGERSOLGERAGRMOVOPDQTDBASUSAFRQUSAFIXUSAAUXMOVPRLCODREGOPDORP
E900EOQCODEMP (FK)CODEMPCODORI (FK)NUMORP (FK)CODETG (FK)SEQEOQ
NUMGOPCODPROCODDERSEQROTCODOPRCODCELTURTRBCODLOTQTDRE1QTDRE2QTDRE3QTDRFGQTDIQLDATREAHORREANUMCADQTDHRRCODUSUDATINIHORINIFIMORPNUMSEP
E075PROCODEMP (FK)CODEMPCODPRO
DESPROCPLPRODESNFVCODFAMUNIMEDUNIME2UNIME3TIPPROCODORI (FK)NUMORICODMDPCODMODCODROTCODAGECODAGPCODAGUCODAGCCODAGFCODCLFCODSTRPERIPIRECIPITEMICMCODTICCODTRDCODTSTRECICMCODROYQTDMLTQTDMINQTDMAXQTDGOPCODPR2DERPR2CODPR3DERPR3CTAREDSITPROROTPROPROSTQUSOCUSCTARCRCTAFDVCTAFCRCODSTPCODSTCTNSGENINDMISMATDIRUSUGERDATGERHORGERCODPR4DERPR4
Na figura 23, estão relacionadas as tabelas utilizadas para gerar os cubos de decisão.
57
7 CONCLUSÃO
Aplicando as técnicas do Data Warehouse, notou-se que se torna necessário:
conhecimento da base de dados de nível operacional, sendo necessário ter uma visão crítica de
como aproveitar os dados contidos nos campos, para que estes possam se tornar informações
para os tomadores de decisão; tempo de desenvolvimento disponível, e empenhado
diretamente no assunto: devido à sua complexidade, e aos vários passos que devem ser
executados até a elaboração do primeiro protótipo, que serve de base para o aperfeiçoamento
do Data Warehouse.
Com o término deste protótipo, verificou-se ser um assunto que deve ser continuado
nos vários departamentos da Indústria de Relógios Herweg S.A.
Apesar de concluído o protótipo, ficaram algumas etapas a serem realizadas para a real
utilização do que se implementou. Segue abaixo os itens que valem ser considerados:
divulgação da implementação; treinamento na ferramenta Info Worksheet, para os
funcionários, que farão uso das informações geradas; aprimoramento e alteração, a partir das
sugestões vindas dos usuários.
7.1 DIFICULDADES
A seguir estão relacionadas as dificuldades encontradas, referente ao que se propunha
o protótipo:
a) ferramenta nova no mercado: com isto, somente se obteve suporte na página da
empresa produtora do software. Também utilizou-se o suporte da empresa Soft
Consultoria;
b) atrasos no cronograma de implantação do módulo de produção: no dia 9 de Junho de
2000, foi realizado o treinamento do módulo de produção, ao qual, a partir deste
momento tornou-se possível inserir dados na base do nível operacional, para a partir
deste instante, gerar o Data Warehouse.
Encontrou-se como limitação neste protótipo, os seguintes itens como segue abaixo:
a) ficou pendente, implementar nos cubos, a opção de geração de dimensões a partir de
SQL (Structured Query Language), o que tornaria mais maleável a construção do
cubo;
58
b) como não havia dado de outro sistema a ser integrado, não ocorreu o processo de
integração.
Com a apresentação do protótipo ao coordenador do estágio, demonstrando a
funcionalidade dos cubos criados, obteve-se retorno positivo, quanto a aceitação e apoio à
implantação e continuidade, mesmo com o término do estágio.
7.2 SUGESTÕES E MELHORAMENTOS FUTUROS
A partir do que se alcançou neste estágio, sugere-se para futuros trabalhos:
a) comparação entre as diferentes soluções existentes no mercado, verificando a quais
contextos cada produto atende;
b) gerar a integração de dados de sistemas heterogêneos, analisando as dificuldades
encontradas.
59
8 ANEXO 1.
60
61
REFERÊNCIAS BIBLIOGRÁFICAS
[AMA1997] AMARAL, Antônio Jr. Desmistificando definitivamente o Data Warehouse.
Developers Magazine, Axcel. São Paulo, Fevereiro/1997, n.6, pág:14-17.
[BAR1997] BARBIERI, Carlos. Data Warehouse: revisando a tecnologia. Computerworld,
Rio de Janeiro: n.246, p.18, Março 1998.
[BIN1994] BINDER, Fábio Vinícius. Sistemas de Apoio à Decisão. São Paulo : Érica, 1994.
[CRU1998] CRUZ, Tadeu. Sistemas de informações gerenciais: tecnologia da informação e
a empresa do século XXI. São Paulo : Atlas, 1998.
[DAL1998] DAL’ALBA, Adriano. Um estudo sobre Data Warehouse. Dezembro 1998.
Endereço eletrônico: http://www.geocities.com/SiliconValley/Port/5072. Data
da consulta : Abril de 2000.
[DAL1999] DALFOVO, Oscar; GRIPA, Robson. Data Warehouse: usando a técnica de
Cubo de Decisão. Developers Magazine, Axcel. São Paulo, Abril/ 1999,
n.32, pag:12-26.
[EXP1997] EXPOCORP, Guia da. Guia da Feira Expocorp. São Paulo : Abril/1997, pág:6.
[FUR1994] FURLAN, José Davi et al. Sistemas de informação executiva – EIS –
Executive Information Systems. São Paulo : MAKRON Books, 1994.
[GON1997] GONÇALVES, Jorge Luiz Mendes. Data Warehouse é necessariamente um
megaprojeto?. Developers Magazine, Axel. Rio de Janeiro, Fevereiro/1997,
n.6, pag:12-13.
[INM1997] INMON, W.H. Como construir o Data Warehouse. Rio de Janeiro : Campus,
1997.
[JOR1997] JORNADA DE ATUALIZAÇÃO EM INFORMÁTICA. XVII Congresso da
Sociedade Brasileira de Computação; Anais. Editado por Cláudia Maria
Bauzer Medeiros. Brasília : UnB, 1997.
62
[KIM1998] KIMBALL, Ralph. Data Warehouse toolkit. São Paulo : Makron Books, 1998.
[MEN1998] MENGARDA, Mariane Terezinha. Definição de um roteiro de preparação para
implantação de um Data Warehouse. Blumenau, 1998. Trabalho de
Conclusão de Curso (Bacharelado em Ciências da Computação), FURB.
[MUE1999] MUELLER, Marcos. Protótipo de um aplicativo em Data Warehouse na área
ambiental. Blumenau, 1999. Trabalho de Conclusão de Curso (Bacharelado
em Ciências da Computação), FURB.
[OLI1992] OLIVEIRA, Djalma de Pinho Rebouças de. Sistemas de Informações Gerenciais:
estratégias, táticas, operacionais. São Paulo : Atlas, 1992.
[SAL1994] SALVADOR, Jean Hélvio. Um protótipo de sistema de informações executivas
para a área de administração de vendas. Blumenau, 1994. Trabalho de
Conclusão de Curso (Bacharelado em Ciências da Computação), FURB.
[SEA1999] Seagate Softwares. Support Documentation Library 1999. Endereço eletrônico:
http://community.seagatesoftware.com/library/default.asp. Data da consulta:
Abril de 2000.
[TRO1997] TRONCHIN, Jr. Data Warehousing uma attitude estratégica. DBMS, Rio de
Janeiro: n. 6,p.55, Outubro 1997.
