Embed Size (px)
Citation preview
ANDRÉ LUÍS ANDRADE MENOLLI
DEFINIÇÃO DE UMA ARQUITETURA DE DATA WAREHOUSING PARA GESTÃO EM CIÊNCIA E
TECNOLOGIA NO BRASIL
MARINGÁ
2004
ANDRÉ LUÍS ANDRADE MENOLLI
DEFINIÇÃO DE UMA ARQUITETURA DE DATA WAREHOUSING PARA GESTÃO EM CIÊNCIA E
TECNOLOGIA NO BRASIL
Dissertação apresentada ao Programa de
Pós-Graduação em Ciência da Computação
da Universidade Estadual de Maringá, como
requisito parcial para obtenção do grau de
Mestre em Ciência da Computação.
Orientadora: Profª. Drª. Maria Madalena Dias
MARINGÁ
2004
ANDRÉ LUÍS ANDRADE MENOLLI
DEFINIÇÃO DE UMA ARQUITETURA DE DATA WAREHOUSING PARA GESTÃO EM CIÊNCIA E
TECNOLOGIA NO BRASIL
Dissertação apresentada ao Programa de
Pós-Graduação em Ciência da Computação
da Universidade Estadual de Maringá, como
requisito parcial para obtenção do grau de
Mestre em Ciência da Computação.
Aprovado em 25/06/2004.
BANCA EXAMINADORA
Profª. Drª. Maria Madalena Dias Universidade Estadual de Maringá – UEM
Profª. Drª. Itana Maria de Souza Gimenes Universidade Estadual de Maringá – UEM
Prof. Dr. Roberto Carlos dos Santos Pacheco Universidade Federal de Santa Catarina – UFSC
AGRADECIMENTOS
Agradeço primeiramente a Deus, que sempre me deu forças e iluminou o meu caminho. Por
ter me acompanhado, por ter me dado a vida, saúde, bons amigos e uma ótima família.
A minha orientadora, professora Maria Madalena Dias ao professor Wesley Romão e a
professora Itana Gimenes, pessoas formidáveis que contribuíram muito para o
desenvolvimento do trabalho e para a minha formação como pessoa e pesquisador.
Aos grandes amigos do laboratório, que acompanharam e contribuíram para o meu trabalho,
em especial ao meu grande amigo Ricardo G. Coelho.
Aos meus pais que sempre deram grande apoio, e a meus irmãos que sempre foram grandes
amigos, sendo todos eles fundamentais para o meu triunfo.
Ao Conselho Nacional de Desenvolvimento Cientifico e Tecnológico - CNPq, pelo
ininterrupto apoio financeiro.
A todos que direta ou indiretamente contribuíram para a realização deste trabalho.
RESUMO
A tecnologia de data warehouse (DW) vem sendo amplamente utilizada em empresas com o
objetivo de oferecer organização, gerenciamento e integração de bancos de dados. No
processo de descoberta de conhecimento em banco de dados, a primeira etapa é a preparação
de dados, em que os dados devem ser organizados e armazenados no data warehouse. A
construção de um data warehouse é uma tarefa complexa e trabalhosa por exigir um
profundo conhecimento das tecnologias envolvidas, tais como banco de dados e integração de
dados, sobre o negócio da empresa e, também, sobre o conteúdo das fontes de dados de
origem. A escolha de uma arquitetura de data warehousing é uma das primeiras decisões a
serem tomadas na construção de um data warehouse. Atualmente, encontra-se em fase de
desenvolvimento no Departamento de Informática da Universidade Estadual de Maringá o
projeto Intersul, financiado pelo CNPq e Fundação Araucária, cujo objetivo é desenvolver um
sistema informatizado de gestão em Ciência e Tecnologia. Um dos objetivos específicos deste
sistema é desenvolver técnicas de extração de conhecimentos aplicáveis à Ciência e
Tecnologia. A melhor maneira de se extrair conhecimento é a partir de uma base de dados já
preparada, tal como um DW. Neste trabalho é apresentada uma arquitetura de data
warehousing em camadas proposta para gestão em Ciência e Tecnologia e é descrito como
esta arquitetura é aplicada na construção de um data warehouse para o sistema Intersul que
integre as bases Institucionais do CNPq e CAPES.
Palavras Chaves: Data Warehouse, Ciência e Tecnologia, Integração de Dados.
ABSTRACT
The data warehouse (DW) technology has been widely used in companies with the aim of
offering organization, management and database integration. In the data knowledge
discovering process, the first step is the data preparation, where the data must be organized
and stored in the data warehouse. The construction of a data warehouse is a complex and
laborious task because it demands a high knowledge of the involved company business, and
also of the contents of data sources and of the involved technologies, such as database and
data integration. The choice of a data warehousing architecture is one of the first decisions to
be taken in the data warehouse construction. Currently, the Intersul project is in the
development phase in the Department of Computer Science of the State University of
Maringá, funded by CNPq and Fundação Araucária. The objective of this project is to
develop a management system of Science and Technology. One of the specific objectives of
this system is to develop knowledge extration techniques applicable to Science and
Technology. The best way to extract knowledge, is from an already prepared database, such
as a DW. This work presents a data warehousing layer architecture proposal for management
in Science and Technology. This architecture is applied in the construction of a data
warehouse for the Intersul system that integrates the Institucional bases of CNPq and CAPES.
Keywords: Data Warehouse, Science and Technology, Data Integration
LISTA DE ILUSTRAÇÕES
Gráfico 1 – PIB gasto em Pesquisa e Desenvolvimento financiada por Empresa ................18 Gráfico 2 – Parcela de Pesquisadores nas Empresas.............................................................18
Quadro 1 – Distribuição dos Professores na Rede de Ensino ...............................................19
Figura 1 – Orientação por Assunto........................................................................................29
Figura 2 – Integração de Dados.............................................................................................30
Figura 3 – Data Warehouse não-volátil ................................................................................32
Figura 4 – Modelo Estrela .....................................................................................................36
Figura 5 – Drill Down e Roll Up ...........................................................................................38
Figura 6 – O balanceamento no gerenciamento da questão da granularidade.......................39
Figura 7 – Data Marts integrados .........................................................................................40
Figura 8 – Arquitetura multicamadas para DW.....................................................................42
Figura 9 – Arquitetura Global ...............................................................................................43
Figura 10 – Fases do Desenvolvimento de Data Marts Incrementais...................................44
Figura 11 – Processo de Desenvolvimento da Pesquisa........................................................52
Figura 12 – Arquitetura de DW Modular ..............................................................................59
Figura 13 – Arquitetura Proposta por Windom ....................................................................60
Figura 14 – Arquitetura Proposta ..........................................................................................61
Figura 15 – Módulo de Migração da Camada ETL...............................................................64
Figura 16 – Matriz de Barramento ........................................................................................68
Figura 17 – A Arquitetura do Sistema Intersul .....................................................................74
Figura 18 – A Arquitetura Geral do Sistema.........................................................................76
Figura 19 – Matriz de Barramento do DW............................................................................78
Figura 20 – Esquema de Criação do Modelo em Oracle ......................................................79
Figura 21 – Tela do Sistema de Migração de Dados.......................................................... 80
Figura 22 – Modelo Parcial e Simplificado da Área de Estágio ...........................................81
Figura 23 – Modelo Parcial e Simplificado do Modelo de Dados do DW proposto.............86
Figura 24 – Esquema de Consulta no DW construído ..........................................................88
Gráfico 3 – Número de Artigos Publicados por Ano ............................................................92
Gráfico 4 – Graduados no Estado do Paraná.........................................................................93
Gráfico 5 – Média de Tempo de Defesa de Mestrado por Regime Letivo............................93
Gráfico 6 – Número de Publicações de Livros ou Capítulos de Livros ................................95
Figura 25 – Tela com store procedures da camada ETL .................................................. 107
Figura 26 – Modelo de Dados da Área de Estágio ............................................................. 108
Figura 27 – Modelo de Dados do Data Mart de Publicação de Artigos ............................ 109
Figura 28 – Modelo de Dados do Data Mart de Publicação de Livros.............................. 110
Figura 29 – Modelo de Dados do Data Mart de Publicação de Teses ............................... 111
Figura 30 – Modelo de Dados do Data Mart de Publicação em Geral .............................. 112
LISTA DE TABELAS
Tabela 1 - Vantagens e Desvantagens dos Data Marts incrementais ................................................ 45 Tabela 2 - Resumo dos Métodos ....................................................................................................... 85
LISTA DE SIGLAS
C&T Ciência e Tecnologia CAPES Coordenação de Aperfeiçoamento de Pessoal de Nível Superior CNPq Conselho Nacional de Desenvolvimento Cientifico e Tecnológico DM Data Mart DW Data Warehouse DTD Document Type Description ETL Extração, Transformação e Carga EMPRAPA Empresa Brasileira de Pesquisa Agropecuária FAP Fundação de Amparo à Pesquisa FINEP Financiadora de Estudos e Projetos IBGE Instituto Brasileiro de Geografia e Estatísticas MER Modelo de Entidade/Relacionamento ODS Operational Data Store OLAP On-Line Analytic Processing OLTP On-Line Transaction Processing P&D Pesquisa e Desenvolvimento PIB Produto interno Bruto SGBD Sistema Gerenciador de Banco de Dados SQL Struct Query Language UEM Universidade Estadual de Maringá UML Unified Modeling Language XML Extensible Markup Language
SUMÁRIO
RESUMO ABSTRACT 1 INTRODUÇÃO.................................................................................................................. 12
1.1 OBJETIVO .....................................................................................................................12 1.2 JUSTIFICATIVA ...........................................................................................................13 1.3 ORGANIZAÇÃO DO TRABALHO .............................................................................14
2 CIÊNCIA E TECNOLOGIA NO BRASIL........................................................................ 15 2.1 INTRODUÇÃO..............................................................................................................15 2.2 O PERFIL DE CIÊNCIA E TECNOLOGIA NO BRASIL ...........................................16 2.3 PLANEJAMENTO EM C&T ........................................................................................20 2.4 INDICADORES E AVALIAÇÃO EM C&T.................................................................21 2.5 BASES DE CIÊNCIA E TECNOLOGIA NO BRASIL................................................24
2.5.1 Plataforma Lattes.....................................................................................................24 2.5.2 Diretório de Grupo de Pesquisa no Brasil ...............................................................25 2.5.3 Plataforma Coleta Capes .........................................................................................25
2.6 CONSIDERAÇÕES FINAIS .........................................................................................26 3 DATA WAREHOUSING .................................................................................................. 27
3.1 INTRODUÇÃO..............................................................................................................27 3.2 AMBIENTE DE DATA WAREHOUSE.......................................................................27
3.2.1 Conceitos de DW.....................................................................................................27 3.2.2 Características de DW .............................................................................................28 3.2.3 Modelagem de Dados ..............................................................................................32 3.2.4 Granularidade ..........................................................................................................38 3.2.5 Data Mart.................................................................................................................40 3.2.6 Arquitetura de Data Warehouse ..............................................................................41 3.2.7 Tipos de Implementações ........................................................................................45 3.2.8 Metadados................................................................................................................46 3.2.9 Povoando o Data Warehouse..................................................................................48
3.3 CONSIDERAÇÕES FINAIS .........................................................................................50 4 METODOLOGIA DE DESENVOLVIMENTO DA PESQUISA.................................... 51
4.1 INTRODUÇÃO..............................................................................................................51 4.2 MODELO DA PESQUISA ............................................................................................51 4.3 PROCESSO DE DESENVOLVIMENTO DA PESQUISA ..........................................52
4.3.1 Escolha do Tema .....................................................................................................52 4.3.2 Revisão da Literatura...............................................................................................53 4.3.3 Estudo Sobre as Bases de Dados Envolvidas ..........................................................53 4.3.4 Definição da Arquitetura de Data Warehousing para Gestão em C&T.................53 4.3.5 Construção do Data Warehousing Utilizando a Arquitetura Proposta....................54
5 A ARQUITETURA PROPOSTA ...................................................................................... 55 5.1 INTRODUÇÃO..............................................................................................................55 5.2 DIFICULDADES E DESAFIOS NA DEFINIÇÃO DE UMA ARQUITETURA PARA DATA WAREHOUSE.........................................................................................................55 5.3 ARQUITETURA PROPOSTA ......................................................................................60
5.3.1 Camada Fonte de Dados ..........................................................................................63 5.3.2 Camada ETL............................................................................................................63 5.3.3 Camada Área de Estágio..........................................................................................65 5.3.4 Camada Data Warehouse ........................................................................................67 5.3.5 Camada Área de Análise .........................................................................................69
5.3.6 Metadados................................................................................................................71 5.4 CONSIDERAÇÕES FINAIS .........................................................................................72
6 CONSTRUÇÃO DO DW PARA GESTÃO EM C&T..................................................... 74 6.1 INTRODUÇÃO..............................................................................................................74 6.2 ABORDAGEM DO PROBLEMA.................................................................................75
6.3.1 Definição das Fontes de Dados ...............................................................................76 6.3.2 Construção do Sistema ............................................................................................77 6.3.3 Implementação dos Módulos da Camada ETL........................................................78 6.3.4 Modelagem da Área de Estágio...............................................................................81 6.3.5 Definição da Camada DW.......................................................................................82 6.3.6 Desenvolvimento da Camada Análise.....................................................................87 6.3.7 Definição do Metadados..........................................................................................88
6.4 Considerações Finais ......................................................................................................89 7 ESTUDOS DE CASO ........................................................................................................ 91
7.1 INTRODUÇÃO..............................................................................................................91 7.2 ESTUDOS DE CASO ....................................................................................................91
7.2.1 Estudo Sobre a Propriedade Intelectual...................................................................91 7.2.2 Titulação ..................................................................................................................92 7.2.3 Tempo de Defesa nos Programas de Mestrado .......................................................93 7.2.4 Número de Publicações de Livros ...........................................................................94
7.3 CONSIDERAÇÕES FINAIS .........................................................................................95 8 CONCLUSÃO E TRABALHOS FUTUROS .................................................................... 97 REFERÊNCIAS BIBLIOGRÁFICAS .................................................................................. 101 APÊNDICE A – PROCEDIMENTOS DA CAMADA ETL ................................................ 107 APÊNDICE B – MODELOS DE DADOS ........................................................................... 108
12
1 INTRODUÇÃO
Muitas empresas de diferentes ramos de atividade e organizações governamentais possuem
dados em diversas fontes de dados que contêm informações importantes para o suporte à
tomada de decisões. Para que essas decisões possam ser tomadas são necessárias a
compreensão e a preparação desses dados, podendo assim os mesmos serem utilizados
adequadamente. Com a construção de um DW (Data Warehouse) é possível a integração de
diversas fontes de dados, facilitando a tomada de decisões dentro de uma empresa, através da
extração de um grande número de informações.
Um data warehousing mune os usuários de ferramentas de apoio à tomada de decisões
através da integração dos dados de toda a empresa em um repositório de dados. A partir desse
repositório, os usuários finais podem extrair relatórios e realizar análises diretas. O resultado
da utilização de um DW para o processamento de informações é um ganho direto de
produtividade e tempo. Os dados podem ser facilmente acessados e analisados sem o gasto de
tempo envolvido na manipulação e no processamento. As decisões podem ser tomadas
rapidamente e com maior segurança, pois os dados estão disponíveis no momento exato que
se é necessário e com a consistência necessária.
Não só empresas, mas qualquer segmento de mercado em que se queira fazer a integração de
bases de dados diversas, pode construir um DW, tornando possível a utilização de uma base
de dados integrada na tomada de decisões.
A construção de um DW é uma tarefa complexa que exige um profundo conhecimento de
várias tecnologias e dos sistemas envolvidos, sendo em geral demorada e custosa. A
integração de dados também é um grande problema, considerando que, em geral, o DW tem
bases de dados de origem em formatos distintos, o que dificulta esta tarefa.
1.1 OBJETIVO
Os objetivos principais deste trabalho são a definição de uma arquitetura de data warehousing
e a construção de um data warehouse para o sistema Intersul1 que integre as bases
1 Sistema Inteligente de Apoio à Rede Sul de Pesquisa e Pós-Graduação: http//www.uem.din.uem.br/~intersul
13 Institucionais do CNPq e CAPES com dados regionais. A construção do DW é feita a partir
de sistemas transacionais e fontes de dados externas, tendo diferentes tipos de bases de dados,
assim como distintos formatos de dados. O DW dará suporte a análise de dados sobre C&T
(Ciência e Tecnologia) de pesquisas e pesquisadores regionais.
Os objetivos específicos desse trabalho são:
• apresentar os elementos teóricos relacionados à construção de um data warehousing;
• discutir o modelo de arquitetura proposto, apresentando de forma detalhada cada uma
das camadas da arquitetura;
• apresentar e comparar tipos de modelagens de dados utilizadas em desenvolvimento
de DW;
• definir um modelo de dados do DW baseado na modelagem dimensional estrela e
conjunto com as outras modelagens estudadas;
• construir um DW para gestão em C&T;
• apresentar o processo de construção do DW e as dificuldades encontradas neste
processo.
1.2 JUSTIFICATIVA
A arquitetura utilizada neste trabalho é uma arquitetura em camadas baseada na
implementação BUS, que foi definida por Kimball et al. (1998) em conjunto com a
metodologia de DM (Data Marts) incrementais. A utilização dessa metodologia permite
apresentar resultados mais rápidos, enquanto a construção independente das camadas
possibilita a inclusão de novas fontes de dados e a integração de fontes de diferentes formatos.
À medida que os sistemas de informação executiva tornam-se mais abrangentes, envolvendo a
empresa como um todo, o DW passa a ter um papel de extrema importância por possibilitar
análise estratégica, que facilita a tomada de decisões.
Na área de C&T, o Brasil conta com algumas bases de dados bastante confiáveis que são de
extrema importância para avaliar o sistema de C&T no Brasil. O projeto Intersul,
desenvolvido por um grupo de pesquisadores da UEM e UFSC, utilizará essas bases de C&T
14 com dados regionais e tem como um dos principais objetivos desenvolver técnicas de extração
de conhecimentos e tomada de decisão aplicáveis a C&T.
Com isso, a construção de um DW para o projeto Intersul é de suma importância,
considerando que através do DW é possível a utilização de ferramentas OLAP (On-Line
Analytic Processing) e de técnicas de mineração de dados para a extração de dados que
permitam avaliar o perfil de pesquisadores e pesquisas brasileiros, auxiliando assim na
definição de uso dos recursos destinados à C&T.
1.3 ORGANIZAÇÃO DO TRABALHO
Além deste capítulo, este trabalho está dividido em 7 capítulos.
No capítulo 2 é apresentada uma pequena introdução sobre ciência e tecnologia no Brasil,
demonstrando sua evolução e as principais bases de dados de C&T existentes.
No terceiro capítulo é apresentada a fundamentação teórica dos conceitos envolvidos no
ambiente de DW. O objetivo é descrever sucintamente os principais conceitos necessários
para a implementação de um DW.
No quarto capítulo é descrita a metodologia de pesquisa utilizada nesse trabalho.
No quinto capítulo é detalhada a arquitetura proposta, suas camadas e relação com os
conceitos abordados no segundo e terceiro capítulos.
No sexto capítulo, é demonstrado como o DW para gestão em C&T foi construído utilizando
a arquitetura descrita no capítulo cinco.
No sétimo capítulo são discutidos alguns resultados obtidos através de consultas ao DW
construído e no oitavo capítulo são apresentadas a conclusão e sugestões para trabalhos
futuros.
15 2 CIÊNCIA E TECNOLOGIA NO BRASIL
2.1 INTRODUÇÃO
No século passado, o aumento tecnológico foi de grandes proporções, tendo um crescimento
superior a qualquer século antecessor. A partir desse crescimento, novos desafios foram
criados, surgindo então novas questões em aberto que necessitam que novas teorias sejam
formuladas ou explicadas. Com isso, a ciência teve um aumento significativo na qualidade de
suas pesquisas, tornando os pesquisadores profissionais cada vez mais capacitados que
trabalham em beneficio da humanidade.
No Brasil ou em qualquer país que esteja em desenvolvimento, um ponto-chave é fazer com
que escassos recursos destinados a C&T sejam utilizados minimizando os desperdícios,
fazendo com que os gastos sejam utilizados seguindo um planejamento prévio. Uma
alternativa para se conseguir isto, de acordo com Romão (2002), é aumentar os investimentos
em P&D (Pesquisa e Desenvolvimento), fazendo com que, através desta área consiga-se
conhecer em detalhes a realidade da infra-estrutura e do potencial de pesquisa no país, assim
como o perfil de pesquisa dos pesquisadores. Conseguir mais e melhores resultados com
menos recursos é o principal desafio para nações em desenvolvimento como o Brasil.
Mesmo o Brasil sendo um país com grandes dificuldades, o sistema de C&T tem sofrido
avanços significativos. Nesta área pode-se realçar bases de dados importantes que são
consolidadas e confiáveis, através das quais é possível traçar um panorama de C&T sobre
qualquer região do país. Destacam-se entre estas bases o Diretório dos Grupos de Pesquisa no
Brasil (CNPq, 2003a) e o Sistema de Currículo Lattes (CNPq , 2003b), desenvolvidos no
âmbito do Conselho Nacional de Desenvolvimento (CNPq), e o Sistema Coleta da CAPES
sobre a pós graduação brasileira (CAPES, 2003).
Dentro deste contexto, encontra-se o projeto Intersul, que tem como objetivo desenvolver um
sistema informatizado de gestão de C&T. Este projeto terá como público alvo, profissionais
vinculados às FAPs (Fundação de Amparo à Pesquisa) e profissionais vinculados às
instituições executoras de P&D, tais como: universidades (pró-reitores de pesquisa e pós-
16 graduação, coordenadores de cursos de pós-graduação), empresas estatais e privadas que
desenvolvam pesquisa.
O sistema Intersul utilizará dados de C&T da região Sul do Brasil e deverá ser capaz de
responder perguntas como:
• Que tipo de conhecimento é viável e relevante para planejar fomento a C&T?
• Quais seriam os melhores meios de se obter esses conhecimentos?
O projeto Intersul tem como um dos principais objetivo desenvolver técnicas de extração de
conhecimentos e tomada de decisão aplicáveis à C&T para contribuir para o processo de
avaliação e acompanhamento das agências e tornar disponível, rapidamente, informações
sobre o potencial de C&T.
Neste capítulo é feita uma breve revisão bibliográfica sobre C&T no Brasil como subsídio à
criação de um DW para gestão em C&T. Inicialmente é apresentado um resumo da evolução
do sistema de C&T brasileiro. Na seqüência é feita uma breve análise sobre a importância de
se realizar planejamento neste contexto e os indicadores de C&T brasileiro. E por fim, são
apresentadas as principais bases de ciência e tecnologia no Brasil.
2.2 O PERFIL DE CIÊNCIA E TECNOLOGIA NO BRASIL
No Brasil, até a década de 50 não existia um sistema nacional de C&T, o que existia eram
trabalhos e iniciativas individuais. O CNPq foi criado em 1951, era o então Conselho
Nacional de Pesquisa que, em 1978, foi transformado em Conselho Nacional de
Desenvolvimento Cientifico e Tecnológico.
A criação da CAPES (Coordenação de Aperfeiçoamento de Pessoal de Nível Superior)
também ocorreu em 1951. Seu objetivo era a distribuição de bolsas de estudos no Brasil e no
exterior, para assegurar a existência de pessoal especializado para atender às necessidades dos
empreendimentos públicos do país, que tinham como objetivo o desenvolvimento econômico
e social do Brasil.
17 Foram sendo criadas então novas instituições, organizando a base institucional para a
capacitação de recursos humanos, através da implantação da pós-graduação, e para o
desenvolvimento de C&T.
Um estudo feito por Guimarães (1995) aponta que a Pesquisa Científica e Tecnológica no
Brasil é concentrada geograficamente, sendo que 78% dos grupos de pesquisa localizam-se
em São Paulo, Rio de Janeiro, Rio Grande do Sul e Minas Gerais. Este estudo revela também
que a pesquisa é praticamente realizada por grupos recentes, com cerca de oito anos, e por
pesquisadores com titulação bastante diversificada, predominando doutorado e mestrado. De
modo geral, é pouco produtiva e caracterizada por Pesquisa Básica.
A área de Ciências Humanas apresenta o maior número de grupos de pesquisa. A Pesquisa
Básica predomina nas áreas de Ciências Exatas e da Terra e Ciências Biológicas, sendo estas
áreas mais consolidadas e produtivas do que aquelas nas quais predomina a pesquisa aplicada.
Nos países desenvolvidos, onde o resultado da inovação se faz presente em termos de patentes
produzidas e contribuições ao crescimento econômico, a atividade de P&D é
predominantemente realizada nas empresas. No Brasil, do total de cientistas e engenheiros
atuantes em P&D, em todas as áreas atualmente em torno de 83 mil profissionais, cerca de
68% atuam nas universidades e apenas em torno de 11% exercem suas atividades em centros
de pesquisas de empresas privadas (MCT, 2000), enquanto que nos países industrializados
pode chegar a 50% (KRIEGER & GALEMBECK, 1996) e mesmo mais de 70% no caso do
Japão (ARRUDA, 1994). No Brasil as empresas privadas investem pouco em pesquisa e
desenvolvimento, como pode ser visto nos Gráficos 1 e 2.
18
0,1
0,4
0,78
1,18
1,621,73
1,9
México Brasil Canadá França Alemanha Coréia doSul
EUA
Parcela do PIB gasta em Pesquisa e Desenvolvimento financiada por empresas Em %
Gráfico 1 – PIB gasto em Pesquisa e Desenvolvimento financiada por Empresas (Fonte: LEI..., 2004, p. A9)
10,3 12,7
54,547
58,865,3
82,5
México Brasil Canadá França Alemanha Coréia doSul
EUA
Parcela de pesquisadores na empresas em relação ao total
Em%
Gráfico 2 – Parcela de Pesquisadores nas Empresas (Fonte: LEI..., 2004, p. A9)
Estudos recentes mostram que no Brasil o pessoal envolvido com C&T está mais concentrado
em instituições públicas. Entretanto, nos últimos anos a quantidade de professores envolvidos
em pesquisa nas instituições particulares vem tendo um crescimento surpreendente. Apesar da
maioria dos pesquisadores ainda estar concentrada nas instituições públicas, é apontada uma
tendência de crescimento da pesquisa nas universidades particulares. O Quadro 1 mostra esses
números.
19
Privadas................................14.029
Municipais.............................758
Estaduais..............................20.294
Federais................................38.594 Professores Universitários em Tempo Integral...............73.675
O sistema de pós-g
científica imediata,
e Mestrado, o que
prosseguir na sua e
desafios para a C&
a) promover a
b) aumentar a
c) aumentar o
d) aumentar o
e) aumentar a
f) promover p
g) obter o des
Outros estudos, co
crescimento da ciê
o Brasil desenvolv
também que, desde
instabilidade institu
e na educação.
No Brasil, assim c
carências que amea
Quadro 1 – Distribuição dos Professores na Rede de Ensino
Fonte: (Romão, 2002)
raduação, que está diretamente ligado à atividade de pesquisa e à produção
tem evoluído muito, sendo a cada ano criados novos cursos de Doutorado
aumenta a concorrência na distribuição de recursos para pesquisa. Para
volução, Krieger (1999 apud Romão et al, p. 6, 2000) destaca os seguintes
T no Brasil:
educação generalizada;
quantidade e qualidade do pessoal envolvido em C&T;
intercâmbio entre a universidade e o setor produtivo;
s investimentos em C&T com relação ao PIB (Produto interno Bruto);
contribuição da indústria nos investimentos de C&T;
rojetos estratégicos com impacto socioeconômico;
envolvimento sustentado e a preservação ambiental.
mo o realizado por Schwartzman et al. (1995), também apontam um
ncia e tecnologia no Brasil. Esse estudo concluiu que, nos últimos 25 anos,
eu significativamente sua capacidade científica e tecnológica. Revelou
a última década, este setor vem sendo afetado pela falta de recursos, pela
cional e pela falta de definição sobre seu papel na economia, na sociedade
omo em outros países em desenvolvimento, além de superar o sistema de
ça os programas de C&T, transformações deverão ocorrer a partir do uso
20 das novas tecnologias de informação, na qualificação dos pesquisadores e em sua motivação
pelo objeto de estudo.
2.3 PLANEJAMENTO EM C&T
Para que um país consiga um desenvolvimento próspero, é necessário o planejamento da
política científica e tecnológica. Em casos de países como o Brasil, que é um país em
desenvolvimento, é necessário um meio eficiente de planejamento e o estabelecimento de
políticas.
Um dos principais problemas encontrados pelas empresas e instituições é a instabilidade do
cenário econômico, exigindo a adoção de uma administração estratégica, onde uma das
principais etapas é o planejamento. Uma abordagem que leva em consideração a mudança
organizacional é o planejamento estratégico.
“O planejamento estratégico é um processo iterativo da análise das oportunidades e
ameaças e de pontos fortes e fracos visando à busca de uma equação para a definição de
objetivos apropriados ao ajustamento da organização às condições ambientais de
mudança.
Consiste na utilização de um arcabouço de técnicas direcionadas para a elaboração de
uma análise ambiental interna e externa da organização, definição da missão,
formulação de objetivos estratégicos, quebra e fixação de novos paradigmas, definição do
perfil de negócio e área de negócio, grupos de clientes e produtos ou serviços,
formulação de políticas e diretrizes e detalhamento destas em projetos e ações
estratégicas” SILVEIRA (1996 apud ROMÃO, p. 19, 2002).
O planejamento estratégico utiliza conceitos de outras áreas, e para adaptar esses conceitos no
contexto do planejamento em C&T e viabilizar a sua aplicação, é necessário conhecer as
políticas públicas e fatos relevantes a respeito de C&T, para que se consiga analisar as
oportunidades e criar um plano estratégico.
Para se ter um bom planejamento em C&T, é necessário que o decisor tenha informações
precisas e seguras para a tomada de decisão; para isto, deve-se utilizar métodos e meios
modernos para a obtenção dessas informações.
21 Em um país que investe algo em torno de 0,7% do PIB em C&T e cujos recursos provêm
predominantemente dos cofres públicos, sempre sujeitos a descontinuidades, o componente
planejamento é fundamental para a aplicação adequada dos recursos. Em agências de
promoção de C&T, como o CNPq, CAPES, FINEP (Financiadora de Estudos e Projetos) e
Fundações Estaduais, esse planejamento tem como objetivo criar ações de indução do
desenvolvimento científico e tecnológico. Para isto é necessário utilizar conhecimento
adequado que em boa parte está disponível na forma de indicadores (ROMÃO, 2002).
2.4 INDICADORES E AVALIAÇÃO EM C&T
A avaliação de C&T é um processo vinculado ao fomento, ou seja, é necessária uma análise
que produza subsídios para a tomada de decisão, determinando os níveis de distribuição de
recursos. Para realizar qualquer tipo de análise de informações, é necessário utilizar
informações íntegras e que representem de forma concisa a realidade que se pretende analisar.
O uso de indicadores pode viabilizar isto.
Na área de C&T utilizam-se alguns indicadores específicos, criados para permitir estudos
sobre a atividade científica e tecnológica e auxiliar em tarefas tais como: avaliação da
pesquisa, planejamento de política científica, etc (ROMÃO, 2002). As agências em geral,
além das metodologias tradicionais, utilizam também metodologias próprias.
Um dos benefícios que os indicadores de C&T podem trazer é a melhora nos processos de
distribuição de recursos para pesquisa entre os vários objetivos socioeconômicos e as
disciplinas científicas.
Existem diversas maneiras de se medir a atividade científica através de indicadores. Ela pode
ser medida de forma absoluta, relativa, ponderada, etc. De um modo geral, o processo de
avaliação pode ser dividido em dois grupos: qualitativo e quantitativo ou pela combinação dos
dois métodos. Os indicadores viabilizam a condução de estudos em vários níveis para avaliar,
por um lado, indivíduos, grupos, instituições e países e, por outro, periódicos, áreas do
conhecimento e setores de atividade (SPINAK, 1998).
22 Para analisar C&T de um segmento ou região, é necessário conhecer alguns conceitos
quantitativos criados no contexto da atividade científica, como a cientometria e a bibliometria,
além da informetria (ROMÃO 2002). Macias-Chapula (1998) enfatiza que “em tudo o que se
refere à ciência, os indicadores bibliométricos e cientométricos tornaram-se essenciais”.
Estes conceitos são apresentados em Taque-Sutcliffe (apud Macias-Chapula, 1998),
conforme segue:
Bibliometria: é o estudo dos aspectos quantitativos da produção, disseminação e uso da
informação registrada. Seus resultados são usados para elaborar previsões e apoiar a tomada
de decisões.
Cientometria: é o estudo dos aspectos quantitativos da ciência enquanto uma disciplina ou
atividade econômica. É aplicada no desenvolvimento de políticas científicas. Sobrepõe-se a
bibliometria.
Informetria: é o estudo dos aspectos quantitativos da informação em qualquer formato, não
apenas dos cientistas. Através destes conceitos é possível abstrair a realidade e estabelecer
parâmetros numéricos capazes de resumir informações generalizadas sobre investimentos,
produção e tendências no campo da ciência e da tecnologia. Estes parâmetros são conhecidos
como indicadores de C&T.
Os indicadores mais utilizados na medição da ciência são os bibliométricos, que são métodos
quantitativos derivados das publicações científicas. Segundo Katz (2000 apud Niederauer, p.
16, 2002) a avaliação da atividade científica inclui as seguintes medidas bibliométricas:
1. Tamanho: número de artigos publicados;
2. Reconhecimento: número de citações que um artigo recebe;
3. Impacto: relação citação/artigo;
4. Colaboração: número de co-autores nos artigos.
O número de artigos, de citações e de co-autorias forma o tripé de indicadores bibliométricos
que compõem a rede de monitoração da produtividade científica, havendo uma série de
refinamentos e métricas que se constroem a partir deles (CASTRO, 1986; KOSTOFF, 1997).
A explicação para derivar indicadores a partir das publicações científicas é simples: publicar
os resultados de uma pesquisa é um compromisso dos cientistas. Essa é a maneira pela qual
23 novas descobertas são divulgadas, garante-se a propriedade intelectual e atinge-se o
reconhecimento dos pares.
O uso de indicadores quantitativos como descritores do desempenho de pesquisadores e do
progresso científico é hoje extremamente útil à gestão de C&T. Na construção de indicadores
reside a chave do sucesso dos métodos quantitativos (NIEDERAUER, 2002). A construção de
indicadores científicos é feita a partir da medição dos insumos (recursos humanos,
financiamento público e privado, etc.) e dos resultados (produção bibliográfica, patentes, etc.)
das instituições científicas. Com isso, bancos de dados sobre C&T têm uma relevada
importância na medição dos insumos e dos resultados que são bases dos indicadores
científicos.
Construir bons indicadores não é uma tarefa simples. Existe grande dificuldade em construir
indicadores que reflitam com segurança a realidade que se pretende representar e em
estabelecer uma relação de causa-efeito entre a atividade científica e tecnológica e o impacto
socioeconômico que a própria ciência provoca (BRISOLLA, 1998). Para que seja possível
construir bons indicadores é necessária uma participação efetiva de especialistas tanto para
concebê-los como para validá-los. É necessário ter um completo conhecimento do contexto,
do sistema e do objeto ou processo a ser avaliado, para então extrair deles características e
aspectos singulares.
Na construção de indicadores, o que importa é a realidade (processo ou sistema) que eles
descrevem. Um indicador não é a realidade, mas, tal qual um modelo, uma expressão
incompleta da realidade (TRZESNIAK, 1998, p. 164).
Segundo Romão (2002), o uso de indicadores quantitativos é muito criticado devido ao seu
caráter empresarial e a sua limitação para medir idéias. No caso de publicações, elas podem
oferecer contribuições diferentes ao conhecimento científico.
De acordo com Niederauer (2002), não há um método perfeito de avaliação da ciência que
atenda satisfatoriamente às partes envolvidas: avaliado, avaliadores e gestores de C&T. O que
se percebe é uma tendência de utilização de diversos indicadores, pois, se em décadas
anteriores havia restrições tecnológicas quanto a manipular grandes quantidades de dados,
essa barreira se desfez. A capacidade dos computadores atuais, tanto em termos de hardware
24 como de software, representa um significativo impulso para a medição, avaliação e
acompanhamento das atividades de C&T.
A Bibliometira, como área tradicional de indicadores em C&T e, particularmente, os preceitos
de Katz sobre as dimensões de análise de C&T vêm sendo sensivelmente e gradativamente
ampliadas juntamente pelas novas possibilidades em Tecnologia da Informação, formando
assim novos indicadores muito mais complexos e dos que os indicadores tradicionais.
2.5 BASES DE CIÊNCIA E TECNOLOGIA NO BRASIL
A criação de bases de dados de C&T indicam um crescimento no Brasil nesta área, podendo
realçar a existência de algumas bases de dados importantes que são consolidadas e confiáveis,
e através delas é possível conseguir dados sobre C&T em qualquer região do país.
As três principais bases brasileiras de C&T são: a base da Plataforma Lattes (CNPq), que
inclui uma base que trata do indivíduo, com base de currículos; a base do Diretório dos
Grupos de Pesquisa no Brasil (CNPq), contendo dados sobre os grupos de pesquisa no Brasil
e a base Coleta (CAPES), contendo dados sobre os programas de pós-graduação.
2.5.1 Plataforma Lattes
A Plataforma Lattes possui uma base de dados com informações curriculares de
pesquisadores do Brasil, compreendendo bolsistas de iniciação científica, bolsistas de
mestrado e doutorado, orientadores e outros atores ligados ao sistema nacional de inovação.
A Plataforma Lattes tem como objetivos básicos:
• avaliação da competência de candidatos à obtenção de bolsas e auxílios;
• seleção de consultores, de membros de comitês e de grupos assessores;
• subsídio à avaliação da pesquisa e da pós-graduação brasileiras.
O Currículo Lattes é o sistema responsável pela coleta das informações que servem de apoio
na descrição da pesquisa no país em nível de indivíduo. As informações são originadas de
pesquisadores ou usuários do CNPq.
25 2.5.2 Diretório de Grupo de Pesquisa no Brasil
O Diretório dos Grupos de Pesquisa no Brasil, coordenado pelo CNPq. Ela é constituída pelos
principais grupos de pesquisa do Brasil, seus integrantes e pela produção científica desses
grupos.
Quando o Diretório foi criado, tinha como objetivo oferecer um suporte de informações
atualizadas sobre as atividades de pesquisa, querendo obter, periodicamente, a configuração
dos recursos humanos e a organização da produção científica e tecnológica brasileiras.
Hoje, o Diretório tem o objetivo de ser uma plataforma de informações básicas sobre parque
científico e tecnológico brasileiro, sendo assim, um instrumento essencial para a gestão de
C&T (MARTINS & GALVÃO, 1994 (apud ROMÃO, p. 31, 2002)).
O Diretório possui três finalidades principais (Guimarães (1994 apud Gonçalves, p. 32,
2000)):
• ser um eficiente instrumento para o intercâmbio e a troca de informações, permitindo
identificar com rapidez a posição do indivíduo dentro do grupo;
• ser uma ferramenta poderosa destinada ao planejamento e gestão das atividades de
C&T;
• possuir um papel importante na preservação histórica de ciência e tecnologia no
Brasil.
A base do Diretório pode ser analisada segundo algumas abordagens, entre elas: o próprio
grupo de pesquisa, as linhas de pesquisa, os pesquisadores, estudantes, técnicos, áreas do
conhecimento e a produção em C&T. Neste primeiro ponto pode-se verificar as principais
características dos grupos, tais como a instituição a qual estes pertencem, a área do
conhecimento a qual estão vinculados e a produção científica de seus integrantes
(GONÇALVES, 2000).
2.5.3 Plataforma Coleta Capes
26 A finalidade da Plataforma Coleta é coletar dados dos programas de pós-graduação (stricto
sensu) do país, para subsidiar o processo de avaliação da pós-graduação brasileira.
O modelo desta base de dados é bem complexo, permitindo análises importantes sobre o perfil
de C&T no país, embora, como a própria agência menciona, estes dados não possuem um
caráter censitário.
Assim sendo, esta base tem como finalidade o suporte a aplicativos computacionais, captação
dos dados junto aos programas e a avaliação dos cursos.
2.6 CONSIDERAÇÕES FINAIS
A área de C&T no Brasil teve um significativo crescimento nas últimas décadas, tendo bases
de dados importantes, que são confiáveis e que podem ser de grande valia para um
crescimento nesta área. Estes dados podem disponibilizar informações estratégicas à tomada
de decisão em gestão de C&T, através de um sistema concebido com o objetivo de extrair
conhecimento sobre C&T. O DW é uma alternativa para se conseguir isto. Muitas empresas e
instituições governamentais estão iniciando a exploração de seus dados, através da construção
de DW (DIAS et al., 1998) e ferramentas de extração de conhecimento, com o objetivo de
reduzir custos e otimizar a qualidade de seus produtos e serviços.
A construção de um DW, integrando as bases de dados descritas neste capítulo, facilitará o
processo de busca de conhecimentos interessantes sobre C&T, através do sistema Intersul e de
ferramentas OLAP.
27 3 DATA WAREHOUSING
3.1 INTRODUÇÃO
O conceito de data warehousing, embora surgido recentemente, baseia-se em idéias que
vinham sendo aplicadas em vários sistemas de informação há muitos anos (INMON, 1997).
O data warehousing teve um grande crescimento com o surgimento de tecnologias e
metodologias para facilitar o desenvolvimento de sistemas de apoio à tomada de decisão.
Neste capítulo abordam-se os conceitos, principais elementos, fases da construção e aspectos
relacionados à implementação de um data warehousing.
3.2 AMBIENTE DE DATA WAREHOUSE
Com o aumento dos sistemas de apoio à decisão, elevou-se a dificuldade do controle e
gerenciamento dos dados, necessitando assim de uma nova tecnologia para melhor
administrar os dados e tornar possível a tomada de decisão neste novo contexto. Surgiu então
o ambiente de DW, que combina os métodos e ferramentas destinados ao suporte à decisão
com uma modelagem de dados que permita gerenciar e controlar uma grande quantidade de
dados, possibilitando ao usuário final tomar decisões melhores e mais rápidas.
O ambiente de DW pode ser considerado uma evolução dos sistemas de apoio à decisão, pois
ele combina as consultas e processamentos dos sistemas de apoio à decisão com uma nova
forma de armazenamento de dados que permite o armazenamento de grande quantidade de
dados, possibilitando uma maior rapidez ao acesso a estes.
O presente capítulo tem por objetivo apresentar conceitos e características sobre a tecnologia
de DW e trabalhos relacionados.
3.2.1 Conceitos de DW
28 Um DW pode ser considerado uma coleção de dados para dar suporte à tomada de decisões,
com dados integrados de múltiplas fontes, orientados por assunto, não voláteis e que sofrem
variação no tempo (INMON, 1997).
Um DW tem o objetivo de integrar dados de diferentes fontes e formatos. O DW não é
construído para suportar o processo funcional ou operacional da empresa, ou seja, não é o fim,
mas é o meio para facilitar o uso da informação (KIMBALL et al., 1998).
3.2.2 Características de DW
Um DW tem algumas características importantes, como a orientação por assunto, a
integração, o fato de não ser volátil e a variação no tempo. Segundo Inmon (1997), essas são
as principais características do ambiente DW. A seguir, uma breve abordagem de cada uma
dessas características.
1) Orientação por Assunto
Enquanto as bases de dados operacionais têm seus dados focados nas aplicações das empresas
(transações que acontecem no dia-a-dia da empresa), o DW tem seus dados focados nos
assuntos da empresa que são relevantes ao processo de tomada de decisão. Antes de iniciar a
construção de um DW, na fase de análise é muito importante que se discuta com os usuários
quais são os seus objetivos, para conseguir fazer uma classificação por assunto no DW.
Outra diferença entre os dados orientados a aplicações e o DW é que os orientados a
aplicações possuem detalhes que satisfazem os requisitos imediatistas do processamento
funcional, enquanto que o DW não inclui dados que não serão utilizados para processamento.
Na Figura 1 é mostrada a diferença entre os dados do ambiente transacional e os dados no
DW.
29
Pedido, Nota Fiscal
Ordem de Produção, Máquina
Falha, produto
Vendas
Produção
Qualidade
Ambiente Transacional arehouse Data WDados baseados em assuntos de negócio
2) Integração
A integração de dados é uma
geral é composto por diversas
uma representação única para
diversas fontes para que se ob
medidas, a consistência da cod
dados e assim por diante.
Um exemplo desse problema é
em um sistema a representaçã
“M” representaria masculino
para masculino e 2 para femin
duas fontes, seria necessária u
provenientes das fontes de dad
Figura 1 - Orientação por Assunto
Fonte: (Machado, 2000)
das características mais importantes do DW. Como o DW em
fontes de dados, para que estas possam interagir é necessária
estes dados. É necessário fazer a integração dos dados das
tenha a consistência de nomes, a consistência de variáveis de
ificação das estruturas, a consistência dos atributos físicos dos
a representação do sexo, como mostrado na Figura 2, no qual,
o poderia ser feita através de um campo alfanumérico, onde
e “F” feminino e em outro sistema essa representação seria 1
ino. Para que o DW possa utilizar os dados provenientes dessas
ma integração, utilizando um filtro, que transformaria os dados
os de origem para o formato definido no DW.
30
Sexo ‘Sexo
M’ ‘F’
Sexo 1 Sexo 2
Extração Filtro
Sistema1
DWSexo ‘M’ Sexo ‘F’
Sistema2
Dois elementos básicos estão rel
e o armazenamento de dados op
limpeza, transformação e agrega
a integração ocorrem no OD
processos de extração, transform
• extrair os dados do amb
de tecnologia, por exemp
• selecionar e validar os da
• reestruturar as chaves d
simples, um elemento de
• reformatar os dados;
• trabalhar com várias fon
a fonte de dados apropri
condições;
• intercalar vários arquivos
• trabalhar com vários re
mesmo programa de carg
• extrair os dados com efic
• resumir os dados;
• alterar nomes de elemen
para o ambiente de DW e
Figura 2 - Integração de Dados
Fonte : (Machado, 2000)
acionados com a integração: a área de estagiamento de dados
eracionais (ODS) (KIMBALL et al., 1998). Os processos de
ção ocorrem no estagiamento, enquanto a compatibilização e
S. Inmon (1997) identifica algumas funcionalidades dos
ação e carga (ETL), como são relacionados a seguir:
iente operacional para o ambiente de DW demanda mudança
lo, SGBD (Sistema Gerenciador de Banco de Dados) de DW;
dos do ambiente operacional;
e entrada operacionais antes de serem gravadas. Em casos
tempo é acrescentado à estrutura da chave;
tes de dados, nas quais a lógica deve ser esclarecida para que
ada contribua com seus dados segundo o conjunto correto de
de entrada;
sultados de diferentes níveis de resumos produzidos pelo
a;
iência na escolha dos dados de entrada;
tos de dados durante a passagem do ambiente operacional
registrar essas alterações;
31
• padronizar os registros de entrada.
3) Variação no Tempo
Diferente de bancos de dados OLTP (On-Line Transaction Processing), no qual os dados
estão em constantes atualizações e os dados estão sempre com valores atuais, em um DW os
dados estão associados a um ponto no tempo (SINGH, 2001). A variação com o tempo
significa que todos os dados no DW são precisos em algum instante no tempo. No ambiente
operacional, os dados estão corretos no momento do acesso. Por isto os dados estão corretos
em algum instante do tempo (INMON et al., 1997a).
“O melhor sistema OLTP é um estado instantâneo dos negócios de uma organização,
atualizado constantemente à medida que as transações são concretizadas.“ (KIMBALL et al.,
1998)
Bancos de dados OLTP não possuem um suporte explícito para representar corretamente o
histórico do passado, pois eles refletem o valor corrente e sua exatidão é válida para um
determinado momento, podendo ser alterado. Já os dados em um DW são um conjunto
estático de registros de uma ou mais tabelas, capturados em um determinado momento de
tempo. O armazenamento é uma seqüência de tempo explícita, em que são transferidos
instantâneos estáticos do OLTP para o DW como uma seqüência de camada de dados, isto é,
o DW é uma seqüência de registros no tempo. Os dados no DW trazem uma imagem fiel da
época em que foram gerados.
Os dados podem, ainda, estar divididos em dois modos: dados atuais e dados antigos. Os
dados atuais são os dados mais recentes e que têm maior interesse, sendo os mais importantes
no processo de tomada de decisão. Geralmente esses dados são armazenados com um baixo
nível de granularidade e devem ser acessados de maneira rápida. Já os dados antigos, são
dados que fazem parte do DW, mas não são acessados tão freqüentemente. Geralmente ficam
armazenados em meios de custo mais baixo como, por exemplo, fitas. Normalmente o DW
possui um grande volume de dados por serem armazenados dados de um grande período de
tempo, e são acessados sempre que haja necessidade de extrair informações deles.
4) Não-Volátil
32 Um DW não ser volátil significa que ele não sofre modificações, ou seja, após os dados serem
inseridos eles não são mais modificados. No banco de dados transacional, os dados sofrem
atualizações em muitas transações, necessitando de um grande trabalho para garantir a
integridade e consistência dos dados. Já o DW não requer este grau de controle por não
permitir atualizações.
A Figura 3 mostra um exemplo de banco de dados transacional e de um DW com as
operações possíveis para cada um dos bancos. No DW, só são possíveis as operações de
consulta e inclusão, enquanto no banco de dados transacional, as operações de incluir, excluir,
alterar e consultar são permitidas.
Banco de Dados Transacional
AlterarExcluirIncluir
Consultar
ConsultarIncluir
Data Warehouse
Figura 3 - Data Warehouse não-volátil
Fonte: Adaptado de Machado (2000)
5) Armazenamento de Dados
Após todas as etapas de extração, limpeza, integração acontece o armazenamento dos dados
no DW. “Nesta etapa, vários processos adicionais ainda são realizados, tais como a
verificação de restrições de integridade, a ordenação dos dados, a geração de agregações, a
construção de índices e a condensação dos dados visando-se diminuir o volume dos dados a
ser armazenado” (CIFERRI, 2002).
3.2.3 Modelagem de Dados
Um dos assuntos mais críticos na construção de um DW é a compreensão dos dados. A
criação de um modelo de dados é o melhor caminho para entender os dados.
33 De acordo com Date (1999) um modelo de dados ajuda em:
• determinar os requisitos de negócio de alto nível e a criação de um escopo de
documentos;
• reunir requisitos adicionais;
• construir um modelo de dados físico.
A modelagem de dados para DW é totalmente diferente da modelagem utilizada em banco de
dados transacionais. Nos bancos de dados transacionais é utilizada a MER (Modelagem
Entidade/Relacionamento) a qual usa uma técnica que busca remover qualquer redundância
de dados, qualquer transação que atualize os dados será efetuada em apenas um ponto do
banco de dados (KIMBALL et al., 1998). Já o DW utiliza a modelagem dimensional como
uma técnica que suporta o ambiente para análise multidimensional dos dados (MACHADO,
2000). “A utilização de modelos dimensionais é amplamente aceita como uma técnica viável
para a entrega de dados para o usuário final em um DW” (KIMBAL et al., 1998; MEYERE &
CANNON, 1998; AXEL & SONG, 1997; DINTER et al., 1998). O objetivo no projeto do
modelo de um DW é deixar ele com um fácil entendimento, simples para se carregar com
dados operacionais e trazer resultados de consultas o mais rápido possível. (KIMBAL et al.,
1998; ADAMSON & VENERABLE, 1998.).
O modelo dimensional traz duas principais vantagens na sua utilização em ambientes de DW.
Primeiro, um modelo dimensional prove uma análise espacial multidimensional em ambientes
de bases de dados relacionais. São analisados dados factuais utilizando dimensões. Segundo,
um típico modelo dimensional desnormalizado tem um esquema de estrutura simples, o qual
simplifica o processamento de consulta de usuários finais e eleva o desempenho.” ( SONG et
al., 2001).
Segundo Meyere & Cannon (1998) existem quatro níveis de requisitos de modelo de dados
para construir um DW, como segue:
• um modelo lógico de alto nível, constituído de um diagrama de área de assuntos
coorporativos;
• um modelo lógico de nível médio de área de assuntos do negócio, aplicável para uma
fase particular da construção do DW;
34
• um modelo de dimensão do DW, o qual reflete a informação e características
analíticas do DW;
• um modelo físico do DW, o qual reflete as mudanças necessárias para alcançar os
objetivos de desempenho.
Modelagem dimensional é a técnica em que o modelo proporciona uma representação do
banco de dados consistente com o modo que o usuário visualiza e navega pelo DW,
combinando tabelas com dados históricos em séries temporais, cujo contexto é descrito
através de tabelas de dimensões (BALLARD et al., 1998; HARRISON, 1998).
Ferramentas OLAP permitem análise e gerenciamento, proporcionando aos executivos um
grande ganho de desempenho através do rápido acesso a uma grande variedade de visões de
dados organizados através da base de dados multidimensional. O modelo de dados
multidimensional permite, também, um suporte a múltiplas hierarquias (AGRAWAL et al.,
1995). Isto porque os membros de uma dimensão não estão em uma única estrutura
hierárquica, por exemplo, dados que estão na dimensão tempo podem estar divididos em
várias hierarquias, como ano, mês e semana.
A modelagem dimensional tem como conceito, três elementos principais:
• fatos;
• dimensões;
• medidas.
Um fato é uma coleção de dados. Cada fato representa um item de negócio, uma transação ou
um evento de negócio. Os fatos são utilizados para fazer a análise sobre a empresa, ou a
instituição. “Fato é tudo aquilo que reflete a evolução dos negócios do dia-a-dia de uma
organização” (MACHADO, 2000 p. 64).
Dimensões são os elementos que participam de um fato, como por exemplo: tempo,
localização e cliente. A dimensão pode ser organizada de maneira hierárquica, sendo
constituída de vários níveis. Por exemplo, a dimensão região pode ser constituída de região,
estado e cidade.
35 As medidas são os atributos numéricos que representam um fato. Cada medida é constituída
pela combinação de dimensões que estão em um fato. Um exemplo de medida é o número de
publicações de um determinado autor em um ano.
O modelo dimensional permite a visualização de dados na forma de um cubo, onde cada
dimensão do cubo representa o contexto de um determinado fato e a intersecção entre as
dimensões representa as medidas. Matematicamente, o cubo possui apenas três dimensões.
Entretanto, no modelo dimensional, a metáfora do cubo pode possuir quantas dimensões
forem necessárias para representar um determinado fato (MACHADO, 2000). Por este
motivo este modelo também é chamado de modelo multidimensional.
Dentre os modelos de dados dimensionais, o mais comum é o modelo estrela. O modelo
estrela possui uma entidade central denominada tabela de fatos e um conjunto de entidades
menores, as tabelas de dimensões, relacionadas com a tabela de fatos, como mostra a Figura
4.
Como pode ser visto na Figura 4, a tabela de fatos representa relacionamentos muitos-para-
muitos entre as tabelas de dimensão, esta tem como chave primária uma chave composta de
todas as chaves estrangeiras das tabelas de dimensão.
Nas tabelas de dimensões são armazenadas as descrições das dimensões do negócio, e estas
tabelas tendem a utilizar tipo caracter ao invés de numérico, de forma que suas linhas são
muito mais longas, mas em pouca quantidade, ocupando pequena percentagem de espaço em
disco. As tabelas de fatos podem utilizar até 95% da área destinada ao DW (BARQUINI,
1996).
36
Dimensão Tempo
Fatos Vendas
Chave_Tempo Chave_ProdutoCh
ave_Loja
o Valor_VendidQtde_Vendida
Chave_Loja Nome_Loja Endereço Cidade
Dimensão Loja
Chave_ProdutoDe
scrição
ia Marca Categor
Dimensão Produto
Chave_Tempo Dia Mês Ano Dia util
Figura 4 - Modelo Estrela
Fonte: Adaptado de Kimball (1996)
Outro modelo dimensional que existe é o modelo floco de neve, que pode ser conseguido pela
decomposição de uma ou mais dimensões de maneira hierárquica. Um exemplo seria aplicar a
decomposição da Dimensão Tempo, em ano, mês e dia no modelo estrela apresentado.
A diferença básica entre os dois modelos é que no modelo floco de neve as dimensões são
separadas em hierarquias, ou seja, uma tabela para cada nível. Já o modelo estrela possui as
mesmas dimensões, com todos os níveis em uma só tabela.
Comparando esses dois modelos, tem-se que no modelo estrela o tempo de acesso é mais
eficiente do que no floco de neve. No modelo floco de neve são necessárias mais junções
entre as tabelas e, conseqüentemente, há um gasto maior de tempo. O modelo floco de neve é
esteticamente mais semântico para visualização que o modelo estrela, mas deve-se lembrar
que o principal objetivo de um DW é fazer consultas com o máximo de eficiência possível.
37 Existem algumas operações para navegar nos dados de um modelo dimensional, e estas
operações são (MACHADO, 2000):
• Drill Down;
• Roll Up;
• Drill Across;
• Slice and dice.
Através do Drill Down o usuário navega de um nível de detalhe mais alto até um nível de
detalhe mais baixo, enquanto no Roll Up o usuário navega de um nível de detalhe mais baixo
até um nível mais alto. Estas duas operações podem ser vistas na Figura 5.
A operação Drill Across combina várias tabelas de fato que compartilham as mesmas
dimensões em um único relatório (KIMBALL, 1996).
As operações Slice (Fatiar) e Dice (Mudar a perspectiva da visão) são referentes ao cubo. Na
operação Slice, o cubo é fatiado para visualizar melhor um pedaço do cubo, mas mantêm a
mesma perspectiva de visualização dos dados. Por exemplo, se a Figura 5 estivesse
representando a produção total da UEM (Universidade Estadual de Maringá) no trimestre, em
relação a artigos e livros, com a operação Slice seria visualizada somente a produção de
artigos ou somente a de livros no trimestre. Já a operação Dice traz uma mudança de
perspectiva da visão. Por exemplo, se está sendo visualizado na UEM quantos artigos foram
publicados em um certo período de tempo, com a operação Dice se visualizará o número de
artigos publicados na UEM, ou seja, o foco deixa de ser a universidade e passa a ser a
publicação de artigos.
38
Volume de Produção (em Milhares)
Região Sul
RS
Janeiro 30
Fevereiro 26
323028SC
Março 22
Trimestre 1
Volume de Produção (em Milhares)
Trim. 1 78
Região Sul
Trim. 2 67
Trim. 3 22
Trim. 4 56
RS
1999
99886790SC
DriRoll Up – Dimensão Tempo Drill Down – Dimensão Tempo
Figura 5 - Drill Down e Roll Up
Fonte: (Machado, 2000)
3.2.4 Granularidade
A granularidade está relacionada com o nível de detalhe em que serão armazenados os dados
no DW, sendo que ela é inversamente proporcional ao nível de detalhe, ou seja, quanto maior
a granularidade menor o nível de detalhe. A granularidade afeta o desempenho das consultas e
o volume dos dados tendo, portanto, uma grande importância para o projeto. Nenhum outro
aspecto de projeto terá importância se a granularidade não for conduzida de forma apropriada
e se o particionamento não for cuidadosamente projetado e implementado (INMON, 1997).
O nível de granularidade deve ser definido no início do projeto, mas é muito difícil determinar
esta granularidade, sendo que geralmente a melhor solução consiste em estruturas com alguns
níveis de granularidade. Geralmente é utilizada a opção de múltiplos níveis de granularidade,
em que se parte de um baixo nível de granularidade, passando por níveis intermediários até
um alto nível de granularidade.
Uma outra opção é o uso dual de granularidade. Nesta opção são mantidas as informações
recentes em um baixo nível de granularidade, para permitir a extração de informações mais
39 detalhadas. À medida que os dados se tornam obsoletos, estes são resumidos em um alto nível
de granularidade, aumentando o desempenho de acesso.
Figura 6 - O balanceamento no gerenciamento da questão da granularidade.
Fonte: (Inmon, 1997)
Nível de detalhe – responde qualquer questão Grandes volumes de dados
Flexibilidade – volume suficientemente pequeno para serem tratados Pequenos volumes
Baixo Nível de DetalheAlto Nível de Detalhe
Na integração de dados de diferentes fontes, a granularidade é um fator muito importante, que
normalmente deve-se expressar o menor nível de granularidade comum entre as fontes.
Muitas vezes é preciso expressar os dados no menor nível de granularidade para que as
consultas possam aprofundar-se com precisão no DW (KIMBALL et al., 1998).
Outro fator importante no projeto do DW é o particionamento dos dados. O particionamento
consiste em dividir os dados em unidades físicas menores. Como as unidades são separadas,
elas podem ser tratadas de forma independente e, por serem menores, permitem maior
flexibilidade no gerenciamento dos dados.
O particionamento pode ser feito no nível do sistema gerenciador de banco de dados (SGBD)
e/ou no nível da aplicação. No particionamento no nível do sistema, o gerenciamento e a
infra-estrutura ficam a cargo do SGBD, enquanto que no nível de aplicação o particionamento
é feito pelo código da aplicação controlado pelo programador.
40 3.2.5 Data Mart
Data Mart (DM) é um banco de dados multidimensional que representa um subconjunto de
dados do DW e permite o acesso descentralizado das informações.
O DW está relacionado com a empresa toda, permitindo uma visão global do negócio,
enquanto que o DM é direcionado a um departamento ou a uma área específica do negócio.
Como o DM é direcionado a uma área específica do negócio, o volume de dados é bem menor
que no DW e sua implementação é bem mais rápida e a um custo bem mais baixo que a de um
DW. Um outro benefício do desenvolvimento do DM para o investimento em um DW
completo é o ganho de experiência, mostrando aos usuários o valor de informação de suporte
à decisão (PEREIRA & BECKER, 2001).
Uma outra característica dos data marts é que eles podem ser integrados ou interconectados
através do compartilhamento de dados, provendo um aumento na capacidade e qualidade de
visão corporativa dos dados e informações. A Figura 7 representa esta integração. Segundo
Kimball et al. (1998), o conjunto de todos os data marts da organização, construídos de
forma incremental e compartilhando dimensões e fatos comuns, forma o DW lógico da
organização segundo um planejamento prévio.
Data Warehouse
DM
DM
DM
Sistemas Operacionais
Figura 7 - Data Marts integrados
Fonte: (Machado, 2000)
41 3.2.6 Arquitetura de Data Warehouse
Arquitetura é um conjunto de regras que regulamentam uma estrutura para um produto ou
projeto de um sistema (SINGH, 2001). Mais importante que as ferramentas que serão
utilizadas para o desenvolvimento do DW, são os fundamentos da arquitetura. Um dos
principais fundamentos da arquitetura de DW é a flexibilidade, pois é necessário que a
empresa ou organização possa modificar e analisar os dados de acordo com suas
necessidades.
No projeto de um DW, a escolha da arquitetura e da metodologia de desenvolvimento devem
ser umas das primeiras decisões a serem tomadas antes de iniciar o desenvolvimento de um
DW, pois toda a organização dos componentes depende dela.
Singh (2001) propõe um modelo de arquitetura em múltiplas camadas para um DW, contendo
as seguintes camadas, como pode ser visto na Figura 8:
• Camada de Mensagem da Aplicação – esta camada tem como responsabilidade o
transporte das informações do DW para o resto da empresa;
• Camada de Metadados – os metadados são dados sobre os dados, ou seja, são dados
que descrevem os dados. Esta camada tem como objetivo o acesso dos dados do DW
pelos usuários de forma única, sem que eles necessitem saber onde estão ou quais são
os formatos dos dados;
• Camada de Acesso à Informação – nesta camada o usuário tem acesso às informações
do DW através de relatórios, ferramentas OLAP e mineração de dados, permitindo que
o usuário manipule as informações do DW;
• Camada de Acesso a Dados – esta camada é a responsável por fazer a conexão entre a
camada de dados operacionais e a camada de estágio de dados, realizando esta
conexão de modo transparente para o usuário;
• Camada DW – esta camada é onde estão armazenados os dados. Normalmente é uma
base utilizando a modelagem multidimensional, para permitir um acesso mais rápido e
flexível;
• Camada de Estágio dos Dados – nesta camada é feita a extração, limpeza e
transformação dos dados antes para que eles possam ser carregados no DW;
42
• Camada de Dados Operacionais – nesta camada estão contidas as bases de dados da
empresa ou organização;
• Camada de Gerenciamento do Processo - esta camada gerencia os diversos processos
que estão envolvidos em um DW.
Dados
Operacionais
Acesso a Dados
Estagiamento
de Dados
Data
Warehouse
Acesso a Dados
Acesso a
Informação
GERENCIAMENTO DO PROCESSO
METADADOS
Mensagem da Aplicação
Figura 8 - Arquitetura multicamadas para DW
Fonte: Adaptado de Singh (2001)
1) Arquitetura Global
O DW global é construído a partir das necessidades da empresa como um todo. Nele o
armazenamento de dados é composto por um repositório de dados comum de suporte à
decisão, disponível para toda a empresa.
Esta arquitetura pode ser centralizada ou fisicamente distribuída, isto é, se for centralizada o
DW fica em uma única instalação física, enquanto se for distribuída pode ter data marts
espalhados em diferentes instalações físicas.
Esta arquitetura dá a idéia de desenvolvimento Top-Down e apresenta cinco fases, como é
mostrado na Figura 9.
43
Figura 9 - Arquitetura Global
Fonte: (Inmon, 1997)
Projeto Lógico e Físico
Projeto de implementação
e extração
Implementação das aplicações clientes
Carga de Dados, Operação de Manutenção.
Levantamento de todos os dados e requisitos
Esta arquitetura tem como vantagem o acesso à visão corporativa de dados, entretanto é uma
arquitetura com um elevado custo de implementação e que exige um grande tempo de
desenvolvimento.
2) Arquitetura de Data Mart Independente
Nesta arquitetura os data marts são controlados por um grupo específico, onde cada DM é
implementado de forma isolada, sem ter nenhuma interligação com os outros data marts. Os
data marts são construídos isoladamente e então são integrados em um único DW (SAMOS et
al., 1998).
A implementação desta arquitetura é rápida, mas não traz nenhuma visão corporativa.
3) Arquitetura de Data Marts Incrementais
Esta arquitetura foi proposta por Kimball et al. (1998). Nela os requisitos devem ser bem
definidos e a integração entre os data marts deve ser planejada antes de começar o
desenvolvimento dos mesmos. Na arquitetura de data marts integrados, a área de
armazenamento é composta por vários data marts projetados de forma a manter a integração
dos dados. A interligação dos dados faz-se através do metadados e pelo software SGBD
(KIMBALL et al., 1998). A Figura 10 mostra o processo de desenvolvimento desta
abordagem.
Nesta arquitetura, o desenvolvimento é feito através da combinação das abordagens Top-
Down e Bottom-Up e é baseado em um processo contínuo. O desenvolvimento nesta
arquitetura segue os seguintes passos (KIMBALL et al., 1998):
1. Primeiro é feita uma análise dos requisitos de forma global;
44
2. A partir dos requisitos levantados, surge uma lista dos data marts a serem
implementados e como deverão ser integrados;
3. São levantados os requisitos de um dos departamentos integrantes e implementado o
DM correspondente;
4. Repete-se o passo anterior de maneira cíclica, até que todos os DM tenham sido
desenvolvidos;
5. O conjunto de todos os data marts desenvolvidos constitui o DW da empresa ou
organização.
Planejamento
Definição dos Requisitos
Projeto Arquitetura
Seleção e Instalação Arquitetura
Estágio de Dados, Projeto e desenvolvimento
Projeto Lógico
Projeto Físico
Projeto Área de Apresentação
Impl. Área de Apresentação
Implantação
Figura 10 - Fases do Desenvolvimento de Data Marts Incrementais
Fonte: Adaptado de Kimball et al. (1998)
Esta arquitetura é dividida em dois grandes componentes, o Back Room e o Front Room, que
são descritos a seguir:
• Back Room - Extração, Transformação e Carga (ETL) - nele estão todas as
ferramentas e os processos para a aquisição das fontes de dados. Após a extração e a
transformação, os dados são armazenados na área de estágio para serem inseridos
posteriormente no DW e atualizar os metadados.
• Front Room - nele estão todas as ferramentas e os processos necessários para interação
com o usuário final, como ferramentas OLAP. Também contém ferramentas de busca
e apresentação dos dados, acesso e segurança, gerenciamento de consultas, relatórios
padronizados e o monitoramento de atividades.
A Tabela 1 apresenta as principais vantagens e desvantagens desta arquitetura.
45
Tabela 1 - Vantagens e Desvantagens dos Data Marts incrementais
Fonte: (Sell, 2001) Vantagens Desvantagens
A apresentação dos primeiros resultados é feita de modo mais rápido e barato do que a abordagem global
Complicações políticas por conta da determinação da seqüência de implementação dos data marts e das prioridades de manutenção
A integração entre os data marts possibilita a unicidade de representação dos dados e informações mais confiáveis por não existirem redundâncias
Metadado mais complexo para gerenciar a distribuição e integração dos dados
Maior controle no nível de granularidade, padronização e nas manutenções das tabelas
Os mecanismos de extração são projetados uma única vez
compartilhadas 3.2.7 Tipos de Implementações
Existem alguns tipos de implementações das arquiteturas descritas. A escolha da abordagem
de implementação está relacionada com vários fatores, como infra-estrutura de tecnologia, o
escopo da implementação, a arquitetura selecionada, o custo, o tempo de implementação e a
necessidade ou não de um acesso coorporativo.
A seguir são apresentadas três abordagens de implementação: Top-Down, Button-Up e a BUS.
A abordagem Top-Down foi proposta por Inmon (1997) e é conhecida como o padrão inicial
do conceito de DW. Ela se baseia em um DW central, onde todas as decisões sobre as fontes
de dados, segurança, estrutura de dados e padrões de dados devem ser analisadas antes de
iniciar o desenvolvimento, resultando em um grande trabalho inicial.
Nesta abordagem, o processo de desenvolvimento se inicia na extração, transformação e carga
das bases de dados operacionais para uma área de estagiamento ou diretamente para o DW. O
DW por sua vez tem o propósito de servir os data marts departamentais com dados e
metadados.
A abordagem Top-Down tem um custo elevado e um tempo de implementação muito alto,
mas em compensação fornece uma base de dados integrada e corporativa.
46 Pela dificuldade e custo de implementação, a abordagem Top-Down não teve muito sucesso,
surgindo a implementação Button-Up. Ela é baseada na construção de data marts
independentes, sem que seja necessária a definição de uma infra-estrutura corporativa para o
DW da empresa. Cada DM tem sua própria área de estágio e processos de extração,
transformação e limpeza independentes. Essa abordagem tem como característica a
construção de um DW incremental a partir do desenvolvimento dos data marts independentes.
Esta abordagem tem uma implementação rápida e um retorno rápido, no entanto existe uma
dificuldade em gerenciar os padrões únicos de metadados, além de os processos de extração,
transformação e limpeza independentes acarretarem um esforço maior nesta fase do projeto.
A implementação BUS é a junção das abordagens Top-Down e Button-Up. A palavra BUS é
muito utilizada na elétrica, e é uma estrutura que conecta vários dispositivos, isto é, uma
interface padrão que permite diferentes tipos de dispositivos se conectarem. No DW, a
implementação BUS tem o mesmo significado, é uma implementação que utiliza dimensões e
fatos padronizados. Ela foi proposta por Kimball et al. (1998) e o DW lógico é constituído por
data marts integrados. Estes data marts são planejados e integrados a partir do processo de
planejamento, conseguindo assim um DW integrado e incremental.
Este planejamento especifica uma arquitetura global de dados com um escopo bem definido,
então, data marts incrementais são construídos seguindo os padrões da arquitetura planejada.
Nesta abordagem, os fatos devem ser padronizados e as dimensões entre os diversos data
marts são definidas em nível atômico, ou seja, com menor grão possível.
3.2.8 Metadados
Uma parte fundamental do ambiente de DW é o mapeamento do ambiente operacional para o
ambiente de DW. Esse mapeamento inclui:
• mapeamento de um atributo para o outro;
• conversões;
• troca de nomes convencionada;
• troca das características físicas dos dados;
47
• filtragem de dados, etc.
Os metadados são dados sobre os dados e têm a função de dizer onde está o que dentro do
DW, ou seja, é necessário saber quais os dados estão disponíveis e onde estão localizados no
DW para que possam ser acessados com eficiência. Nos metadados residem informações
variadas que são utilizadas e alimentadas por vários componentes da arquitetura. As
informações contidas nesse repositório são essenciais para o pleno funcionamento dos
componentes e para a sua manutenção, além destas informações, os metadados também
podem armazenar dados como (KIMBALL et al., 1998):
• estatística de uso de dados;
• medições de desempenho;
• diferentes elementos por atributo.
“O melhor caminho para implementar e manter metadados simples é através do warehouse
metadados. O warehouse metadados vai além dos tradicionais dicionários de dados, catálogos
de dados e repositórios de dados para prover um help desk particular que traga uma
compreensão da fonte de dados” (BRACKETT, p.193, 1996).
Um DW que é constituído de um ambiente de metadados bem feito deve ser capaz de a partir
dos dados do DW, conseguir voltar para os dados de origem dos sistemas operacionais. Isto é
um ponto importante, por exemplo, caso um relatório não seja bem aceito com dúvidas sobre
sua veracidade. Se for possível voltar aos dados de origem e mostrar que os dados são
verdadeiros, então, a credibilidade do DW estará provada.
Uma outra característica do DW, é que ao contrário dos ambientes operacionais, ele possui
dados de um grande período de tempo, com isso o metadados precisa ser atualizado. A
estrutura do metadados precisa ser atualizada de acordo com que mudanças no DW ocorram,
mudando a estrutura dos ambientes operacionais ou inserindo novas fontes de dados
(INMON, 2000).
Segundo Inmon (2000), no ambiente de DW, alguns dos componentes de metadados são:
• a estrutura e o conteúdo do DW.
• o mapeamento de dados para o DW;
48
• o histórico de extração/transformação;
• a informação de alias;
• a informação de estado;
• as informações volumétricas;
• o critério de envelhecimento e limpeza;
• a sumarização/cálculo de dados entre os níveis de DW;
• o relacionamento de dados;
• o histórico de relacionamento;
• as informações sobre proprietário e administradores;
• as informações de acesso;
• as tabelas de referências;
• o modelo de dados.
Segundo David (2001) os metadados são divididos em dois tipos, os metadados técnicos e os
metadados de negócio.
Os metadados técnicos são utilizados pelo pessoal de desenvolvimento e manutenção,
especificando a esses todas as descrições técnicas do banco de dados e suas operações. Já os
metadados de negócios são utilizados pelos analistas de negócios e provêem uma descrição de
negócio dos objetos da informação. Podem especificar o cálculo de um valor, o cálculo de
custo de um produto, etc.
Um dos problemas dos metadados é que não existe uma estrutura padrão para eles, tendo que
ser criada uma antes do início da implementação do DW. Sendo necessária a definição de
regras para o componente de extração, modelos de dados e tabelas descritivas para o
componente de armazenamento e tabelas descritivas para as aplicações do cliente.
3.2.9 Povoando o Data Warehouse
A etapa de povoamento é uma das partes mais críticas na construção de um DW. Esta etapa
contempla os processos de extração, filtragem, transformação e migração dos dados. Pela
dificuldade de se encontrar ferramentas que dão suporte a todo o processo e pelas ferramentas
serem de elevado custo, ela constitui-se uma tarefa crítica.
49 Existem várias opções de extração dos dados do ambiente operacional para o DW,
dependendo das características de cada origem dos dados (CHAUDHURI & DAYAL, 1997).
• Origens cooperativas: origens que suportam gatilhos (triggers), fazendo com que
notificações de mudanças na base de dados possam ser programadas para ocorrer
automaticamente;
• Origens com log: origens que mantêm um log o qual pode ser consultado, de forma
que mudanças possam ser extraídas deste log (ex. Sybase Replication Server e Oracle
Replication Server);
• Origens consultáveis (time stamps): origens que são modeladas para indicar dados
novos e modificados através de time stamps. Desta forma, apurações periódicas podem
ser realizadas diretamente sobre essas origens, a fim de isolar as alterações que se tem
interesse;
• Origens de instantâneos (snapshots): origens que não suportam triggers, logs ou
consultas. Neste caso, a solução é realizar periódicos snapshots off-line, onde as
mudanças são detectadas, comparando os sucessivos snapshots.
Uma vez que os dados são extraídos e colocados na área de estágio, estes devem passar por
uma série de tratamentos. O primeiro destes tratamentos refere-se à limpeza ou filtragem dos
dados. O objetivo é garantir a integridade dos dados através de programas ou rotinas especiais
que tentam identificar anomalias e resolvê-las, deixando os dados em um estado consistente
antes de serem instalados no DW.
O segundo passo é colocar os dados em uma forma homogênea, aplicando uma metodologia
de comparação de representações, que inclua os critérios a serem utilizados na identificação
de semelhanças e conflitos de modelagem (BATINI & LENZERINI, 1986). Conflitos de
modelagem podem ser divididos em (RIBEIRO, 1995): semânticos e estruturais.
Conflitos semânticos são todos aqueles envolvendo o nome ou palavra associada às estruturas
de modelagem. Por exemplo, mesmo nome para diferentes entidades ou diferentes nomes para
a mesma entidade. Conflitos estruturais englobam os conflitos relativos às estruturas de
modelagem escolhidas, tanto no nível de estrutura propriamente dito como no nível de
domínios. Os principais tipos de conflito estruturais são os conflitos de domínio de atributo
que se caracterizam pelo uso de diferentes tipos de dados para os mesmos campos.
50 Depois de identificados os conflitos de modelagem, deve-se criar as regras de mapeamento de
representações equivalentes e de conversão para os padrões estabelecidos pelo DW.
3.3 CONSIDERAÇÕES FINAIS
O estudo dos conceitos das tecnologias envolvidas no processo de construção do DW
apresentados neste capítulo permitiu uma visão geral das tecnologias envolvidas.
Foram descritas as principais arquiteturas de DW, como a arquitetura global e a arquitetura de
data marts independentes, a arquitetura de data marts incrementais, que foi proposta por
Kimball et al. (1998). Na descrição das arquiteturas foram identificados os tipos de
implementações das mesmas, mostrando vantagens e desvantagens de cada uma das
abordagens.
O modelo de arquitetura do DW definido neste trabalho baseia-se na arquitetura proposta por
Kimball et al. (1998), pelo fato dessa arquitetura apresentar um processo incremental de
construção de data marts integrados.
Baseando-se nas tecnologias e conceitos descritos nesse capítulo, é apresentada no capitulo 5
a arquitetura proposta e no capitulo 6 é descrito como foi construído o DW para gestão em
C&T.
51 4 METODOLOGIA DE DESENVOLVIMENTO DA PESQUISA
4.1 INTRODUÇÃO
Este capítulo tem como objetivo a apresentação da estrutura geral desta pesquisa, que é
composta pelos seguintes elementos: o modelo da pesquisa e o processo de desenvolvimento
da pesquisa.
4.2 MODELO DA PESQUISA
A metodologia adotada neste trabalho é fundamentada no estudo das várias tecnologias
envolvidas, as principais são: sistemas de informação, modelagem de dados, arquitetura de
software, integração de dados e data warehousing (metodologias, tipos de implementação,
arquiteturas de DW, modelos de metadados).
Essas tecnologias foram utilizadas como base para a definição de uma arquitetura e a
construção de um DW para gestão em C&T, que tem como principal objetivo avaliar o perfil
de C&T na região sul do Brasil.
Esta pesquisa pode ser classificada como pesquisa aplicada e experimental. Uma pesquisa é
considerada como aplicada porque “objetiva gerar conhecimentos para aplicação à solução de
problemas específicos” Silva e Menezes(2000 apud Dias 2001, p.44). Pesquisa experimental
porque “determina-se um objeto de estudo, selecionam-se as variáveis capazes de influenciá-
lo, definem-se as formas de controle e de observação dos efeitos que a variável produz no
objeto” (Silva e Menezes (2000 apud Dias 2001, p.44)).
Para o desenvolvimento deste trabalho foram necessários conhecimentos bastante específicos
sobre as principais técnicas e os sistemas envolvidos na construção do DW, além das
tecnologias Oracle, Delphi, Sybase, ErWin. Tudo isto visando à definição da arquitetura de
data warehousing e a implementação dessa arquitetura com dados de C&T.
52 4.3 PROCESSO DE DESENVOLVIMENTO DA PESQUISA
As principais etapas de pesquisa consideradas nesta dissertação foram: escolha do tema,
revisão da literatura, estudo sobre as bases de dados envolvidas, definição da arquitetura de
data warehousing para gestão em C&T e a construção do DW baseada na arquitetura
proposta.
A Figura 11 representa as etapas do processo de desenvolvimento da pesquisa. Nesta figura, à
esquerda são relacionadas as principais etapas da pesquisa e à direita os elementos envolvidos
em cada etapa.
Escolha
do Tema
Revisão daLiteratura
Construção do DW
Estudo das Bases
Definição da Arquitetura
Arquitetura de Software Data Warehousing Gestão da Informação
ErWin 4.0 LATTES DataCAPES
Arquitetura de Software Data Warehousing ErWin 4.0
Oracle 9.0i Delphi 7.0 ErWin 4.0
C&T no Brasil Data Warehousing Modelagem de Dados Integração de Dados Metadados
Figura 11 - Processo de Desenvolvimento da Pesquisa
4.3.1 Escolha do Tema
O tema é fruto de um problema já identificado na pesquisa brasileira através de trabalhos
como Romão (2002) e Gonçalves (2000) e proposto como parte de uma solução para esse
problema através do projeto Intersul.
53 Foram determinadas as tecnologias específicas a serem aplicadas como base na obtenção de
uma arquitetura de data warehousing para gestão em C&T.
4.3.2 Revisão da Literatura
A revisão da literatura englobou conceitos e características das seguintes tecnologias adotadas
na pesquisa: C&T no Brasil, arquiteturas de data warehousing, tipos de implementação DW,
integração de dados, metadados e modelagem de dados para modelos dimensionais.
Na revisão da literatura sobre data warehousing, além dos conceitos e características de DW,
foram descritas arquiteturas existentes e os tipos de implementações de DW mais comumente
utilizados.
A revisão da literatura e as técnicas já existentes de integração de dados, modelagem de dados
e metadados, além das arquiteturas de DW já sedimentadas deram o suporte necessário à
definição de todas as camadas da arquitetura do data warehousing.
4.3.3 Estudo Sobre as Bases de Dados Envolvidas
Foram estudados os modelos de dados dos sistemas Lattes e Datacapes e identificadas as
principais características das bases, além de ter sido feito um levantamento com possíveis
usuários sobre quais dados são necessários para a implementação do DW de maneira
eficiente, enfocando o processo decisório e o papel da tecnologia sobre estes sistemas.
4.3.4 Definição da Arquitetura de Data Warehousing para Gestão em C&T
Nesta etapa foi proposta uma arquitetura e apontadas as melhorias que podem ser obtidas com
o emprego de uma arquitetura em camadas com fases bem definidas e independentes no
desenvolvimento de um data warehousing. A arquitetura foi definida baseando-se na
implementação BUS e sobre os preceitos da metodologia de data marts incrementais, por se
tratar de uma das metodologias mais completas de acordo com Sell (2001), Bomfim (2001).
54 4.3.5 Construção do Data Warehousing Utilizando a Arquitetura Proposta
Nesta etapa procurou-se validar o emprego da arquitetura na construção de um data
warehousing para C&T no Brasil, sendo realizada a validação de cada uma das camadas e
seus componentes e a interação entre as mesmas de acordo com a arquitetura proposta. Os
resultados alcançados foram descritos nesta etapa.
55 5 A ARQUITETURA PROPOSTA
5.1 INTRODUÇÃO
A pesquisa na área de DW teve um grande crescimento na década de 90, principalmente a
partir do ano de 1996. Isto pode ser verificado no estudo feito por Vassiliadis (2000), onde é
apontado um aumento no número de publicações relacionadas com DW nos principais
congressos de banco de dados.
Apesar desse aumento em pesquisas na área de DW, ainda é muito difícil ter um suporte para
o desenvolvimento de um DW, pois as pesquisas ainda são muito voltadas para área
acadêmica. “A lacuna entre o DW prático e o de pesquisa se tornou óbvio“ (VASSILIADIS,
2000).
Um outro ponto importante é a falta de projeto e estrutura no desenvolvimento de DW.
Segundo Demarest (1997), o projeto de DW tem como alguns de seus fatores de insucesso:
• engenharia de dados problemática;
• esquema de projeto não realístico;
• falta de um método de projeto.
Por estes motivos, é de extrema importância o projeto de uma arquitetura contendo passos
bem definidos que possa auxiliar o projetista de DW na conclusão do projeto com sucesso e
dentro do prazo estipulado.
Neste capítulo são abordadas algumas dificuldades comumente encontradas no
desenvolvimento de um DW. Em seguida é apresentada a arquitetura proposta, suas camadas
e seus componentes, os benefícios da sua utilização e a aplicação da metodologia de
desenvolvimento baseada em data marts incrementais.
5.2 DIFICULDADES E DESAFIOS NA DEFINIÇÃO DE UMA
ARQUITETURA PARA DATA WAREHOUSE
56 No desenvolvimento de qualquer sistema, a arquitetura é extremamente importante, através
dela o desenvolvedor encontra uma visão do sistema de diversas perspectivas para melhor
entender o projeto. Além disso, Jacobson et al. (1999), apresenta importantes decisões em
que a arquitetura de software circunda, como:
• a organização do sistema de software;
• a estrutura dos elementos e suas interfaces que irão compreender o sistema;
• o estilo arquitetural, que direciona a organização, os elementos e suas interfaces, suas
colaborações e suas composições.
Com isso, se faz necessária a definição de um estilo arquitetural, pois através dele é possível
determinar a classe a qual pertence a organização de um sistema. Características de
componentes (subsistemas) e conectores do sistema, topologia da arquitetura, restrições
semânticas e mecanismos de interação entre os componentes (MENDES, 2002).
A criação de um DW se inicia com a definição da arquitetura de DW que será utilizada. Para
cada tipo de aplicação em que um DW é implementado, é necessária a escolha de uma
arquitetura que supra as necessidades identificadas na análise de requisitos. Para que isto
aconteça, muitas vezes o projetista de DW deve fazer um estudo das arquiteturas de DW
existentes e escolher a mais adequada ao seu projeto. Em outros casos, é necessária a criação
de uma nova arquitetura, adaptando-se uma arquitetura ou mais arquiteturas já existentes.
Na definição de uma arquitetura de DW existe a etapa de ETL (Extração Transformação e
Carga), e nesta etapa encontra-se uma das grandes dificuldades na criação de um DW, que é a
integração eficiente de várias fontes de dados distintas. A integração de independentes, mas
semânticas bases de dados relacionais, foi um dos tópicos mais pesquisados nos últimos 15
anos. “Muitos dos trabalhos desenvolvidos tiveram foco em técnicas para permitir projetistas
a identificar e resolver conflitos estruturais e semânticos entre objetos de metadados e itens de
dados localizados nas bases de dados locais e nos sistemas de múltiplas bases de dados”
(GERTZ & SCHMITT, 1998).
Ao longo dos últimos anos muitas ferramentas para ajudar na integração de dados foram
criadas, principalmente ferramentas de DW, como por exemplo, as ferramentas de DW da
IBM (DB2 UDB, 2003), Oracle (OWB, 2003) e Microsoft (SQL Server, 2003) e muitas
outras que atuam na camada de ETL e auxiliam no processo de integração de dados. Mas em
57 muitos casos são encontrados problemas específicos no desenvolvimento de um DW, como
problemas estruturais e semânticos, que são causados principalmente pelo uso de fontes de
dados distintas e em formatos diferentes, sendo necessária a criação de um método próprio
para a resolução destes problemas. Essa é uma das razões que torna a etapa de ETL, e mais
especificamente a de integração de dados, uma das etapas mais problemáticas no
desenvolvimento de um DW.
Como exemplo de trabalhos voltados para integração de fontes de dados distintas, pode-se
citar: Gertz & Sattler (2002), Fan et al. (2001). No trabalho apresentado por Gertz & Sattler
(2002), é mostrado um estudo sobre integração de dados baseado em anotações. Tipicamente
as fontes de dados a serem integradas oferecem algum tipo de esquema, o qual representa um
subconjunto do esquema global. A correspondência entre estruturas de dados existe em um
nível semântico somente onde regiões de interesse em documentos podem ser entendidas com
instâncias (dados) de esquemas. A integração de documentos e seus dados representam
recursos para permitir consultas automáticas ou manuais que determinam as características do
documento. Cada característica pode ser representada através de anotações.
O artigo de Gertz & Sattler (2002) apresenta um modelo gráfico de anotações, onde cada
modelo gráfico representa conceitos, anotações e documentos como nós em um grafo e são
conectados pelo tipo de relacionamento. Esse modelo serve como um modelo de integração
definindo conexões entre um esquema de metadados global e distribuído e coleções de
documentos heterogêneos.
O trabalho de Fan et al. (2001) utiliza uma estratégia chamada DIRECT, que, para driblar
conflitos semânticos, descobre regras de conversão de dados a partir de dados que estão
presentes em múltiplas fontes de dados com redundância. O sistema consiste em dois
subsistemas: a preparação de dados e a mineração de regras. A preparação de dados prepara o
conjunto de dados e a mineração de dados analisa os dados preparados para gerar candidatos a
funções de conversões. Os valores das regras de conversão de dados são então formados
utilizando a função de conversão selecionada.
A implementação do DIRECT visa aplicações financeiras, e utiliza técnica de medidas
lineares, associadas entre variáveis numéricas.
58 Na construção de um DW é muito importante que se consiga trabalhar com várias fontes de
dados, que podem ser providas de vários formatos e provenientes de vários lugares, até
mesmo da internet. O trabalho de Jensen, Møller & Pedersen (2003) descreve uma aplicação,
denominada de construção de esquemas OLAP multidimensional, baseada em fontes de dados
da internet. Neste trabalho é fornecido um algoritmo para construção automática de diagramas
UML (Unified Modeling Language) a partir de XML (Extensible Markup Language) DTDs
(Document Type Description). O algoritmo captura importantes propriedades semânticas dos
dados XML como cardinalidade precisa e relacionamento de agregação entre os elementos de
dados.
No processo de integração de dados, vários tipos de problemas podem ocorrer, sendo que,
para alguns desses problemas existem soluções e ferramentas que auxiliam na resolução,
enquanto que para outros problemas novas soluções devem ser criadas. A integração de dados
é um dos primeiros passos no desenvolvimento do DW, por isso, é muito importante que se
verifique os tipos de dados, as estruturas físicas e semânticas dos dados, os tipos de fontes de
dados e as co-relações entre os dados. Fazendo isso, é possível verificar a possibilidade de
utilizar alguma ferramenta de ETL ou a necessidade de criação de um novo processo de
integração a fim de definir a melhor estratégia para integrar os dados de maneira mais rápida,
coesa e precisa.
Um outro ponto muito importante no desenvolvimento do DW é a arquitetura que será
utilizada na sua implementação. É essencial o uso de uma arquitetura que seja flexível o
bastante para suportar a integração de várias técnicas em cada uma das etapas do
desenvolvimento do DW.
Vários trabalhos abordam modelos arquiteturais de DW, como por exemplo, o trabalho de
Sell (2001), o qual propõe uma arquitetura modular para ter independência dos componentes
no desenvolvimento do DW. Neste trabalho, foi definido um modelo em que a principal
preocupação é uma arquitetura que seja flexível o suficiente para integrar fontes de dados
distintas e permitir alterações nas fontes ou incorporações de novas fontes se necessário.
Neste trabalho são discutidas as principais metodologias utilizadas na criação de um DW e é
apresentada uma arquitetura a ser empregada em conjunto com uma metodologia baseada em
DW orientado a “processo”, onde o DW é construído de forma incremental e modular através
da estruturação de data marts integrados.
59 Uma das vantagens desta arquitetura é que os primeiros resultados são apresentados
rapidamente ao usuário, sem perder a visão integrada do negócio, além de permitir uma rápida
absorção de novos requisitos, dada a flexibilidade proporcionada pela arquitetura. A
arquitetura é dividida em três grandes módulos independentes: extração, armazenamento e
apresentação, como pode ser visto na Figura12.
Sistema A Sistema B Sistema CBa y Net work s
MóduloColeta 1
MóduloColeta 2
MóduloColeta 3
Área deEstágio
Ba y Net work sBay Ne twork s
MóduloIncorporação
MóduloTransformação
Área Comum
Data Mart1
Data Mart2
S D
D E F I N I T Y 03 4
Servidor deAplicação
Cliente 1
Cliente 2
Cliente 3
Área de Armazenamento
Área de Extração
Área de Apresentação
MóduloMetadados
Figura 12 -Arquitetura de DW Modular
Fonte: (Sell 2001)
Uma outra arquitetura é apresentada no trabalho de Widom (1995), mostrada na Figura 13.
Nesta arquitetura, as fontes de dados estão na parte abaixo, onde cada uma é conectada ao
componente wrapper/monitor. Wrapper é responsável pela tradução da informação da fonte
de dados nativa para o formato utilizado pelo DW, enquanto o monitor é o responsável pela
detecção automática de mudanças significativas na fonte de dados e informar ao integrator
60 sobre essas mudanças. O integrator é o responsável pela inserção da informação no DW, o
que pode incluir alguns filtros de informação, sumarizando ou agrupando informações de
várias fontes.
Inf. Source
Inf. Source
Inf. Source
Wrapper/Monitor Wrapper/Monitor
Integrator
Wrapper/Monitor
Data
Warehouse
Figura 13 - Arquitetura Proposta por Windom (1995)
O wrapper/monitor pode ter duas funções: tradução da informação da fonte de dados para o
modelo que foi definido no DW e detecção de mudanças.
Pode-se notar através desses trabalhos que a arquitetura está relacionada diretamente com o
objetivo proposto pelo projetista de DW, como: flexibilidade, facilidade de manutenção,
facilidade de integração de novas fontes de dados ou outras funcionalidades definidas por ele.
Sendo assim, a definição da arquitetura é de suma importância para o desenvolvimento do
DW.
5.3 ARQUITETURA PROPOSTA
Como foi descrito anteriormente, a área de DW teve um grande aumento no número de
trabalhos científicos, mas em sua maioria não possui aplicações práticas, por esse motivo,
neste trabalho são propostos uma arquitetura, técnicas e métodos que tentam solucionar
problemas comumente encontrados no desenvolvimento de um DW.
A arquitetura proposta neste trabalho é uma arquitetura em camadas e tem como principal
característica a substituição de fontes de dados de diversos formatos por novas bases de dados
analíticas padronizadas, facilitando assim a integração dos dados. A arquitetura é constituída
de diversas camadas, como pode ser visto na Figura 14. As flechas grossas representam o
61 carregamento de dados enquanto que as setas finas representam o acesso aos dados. A
arquitetura possui cinco camadas, sendo que a camada 2 (ETL) pode ser subdivida em outras
duas camadas, dependendo dos tipos de fontes de dados existentes na camada 1.
Font
es d
e D
ados
E
TL
Áre
a de
Est
ágio
D W
Á
rea
de A
nális
e
Rep
ositó
rio d
e M
etad
ados
Extração, Transformação e Carga
Migração para base de dados referência
Base de Trabalho1
OLAP e Ferramentas de Mineração de Dados
Nova Fonte de Dados
Fontes de Dados Referência
Data Mart 1
Base de Trabalho2
Área de dados Comuns
Data Mart N
Grupos de Pesquisas Pesquisadores Instituições de Educação
Fontes de Dados em Outros Formatos
Figura 14 - Arquitetura Proposta
Na arquitetura em camadas, a principal vantagem é a independência das camadas, pois o que
acontece na camada antecessora é transparente à camada superior, ou seja, se for necessário
alterar ou inserir novos componentes na camada antecessora não haverá problema, desde que,
mantenha-se o modo como dados são providos à camada superior.
A arquitetura proposta combina tecnologias de DW com tecnologia clássica de base de dados
relacional, principalmente na camada Área de Estágio.
62 Na arquitetura proposta, a camada Fonte de Dados armazena todas as fontes de dados que são
utilizadas como fornecedores de informações ao DW. A camada ETL é dividida em dois
módulos, um módulo de migração e outro de extração, transformação e carga. O módulo de
migração transforma dados em diversos formatos para um formato referência, que é o formato
escolhido pelo projetista de DW para ser o formato do DW, já o outro módulo, coleta dados
relevantes, que são previamente definidos na fase de planejamento e definição dos requisitos,
e os armazena na área de estágio, transformados e limpos. Posteriormente, na camada Área de
Estágio, os dados são integrados e incorporados aos data marts. As regras de extração,
transformação e integração são registradas no repositório de metadados.
A partir da análise dos modelos de dados das fontes de origem e de entrevistas com possíveis
usuários do sistema, foi definido o modelo de dados dos data marts, de acordo com a
modelagem dimensional estrela. Esta modelagem foi escolhida por estar consolidada no
ambiente de DW e pelo fato de muitas das ferramentas OLAP e de mineração de dados
necessitarem que os dados estejam neste formato. Posteriormente foi definido o modelo de
dados do DW.
O DW foi construído seguindo a metodologia de data marts incrementais, e a implementação
BUS, para que haja uma padronização e uma melhor integração. O DW incremental tem por
característica o fato de que, conforme novas necessidades surjam, novos datas marts podem
ser implementados ou os existentes podem ser alterados para satisfazer essas novas
necessidades. Para que o DW incremental funcione corretamente, é necessário que a
arquitetura e a metodologia escolhidas sejam flexíveis o suficiente para permitir essas
alterações.
Para a definição das regras de integração de dados, foi utilizada a matriz de identificação de
interseções entre os data marts, definida na abordagem de implementação BUS, assim as
tabelas de fatos e dimensões foram previamente estruturadas de modo a manter integração
entre os data marts. Caso haja sobreposição de dimensões nos data marts, é criada uma área
comum, como pode ser visto na camada de DW da Figura 14, reduzindo a replicação de dados
entre os data marts.
As camadas ETL, Área de Estágio e DW foram projetadas e implementadas utilizando
recursos, como gatilhos e stored procedures, do SGBD Oracle (Oracle9i, 2002) além de
63 ferramentas como o ERWin (Computer Associates, 2003) para modelagem de dados, Rational
Rose (Jacobson et al., 1999) para o projeto das camadas e o Delphi (Delphi 7.0, 2003) para
criação do módulo de migração da camada ETL.
Cada uma das camadas que fazem parte da arquitetura da Figura 14 é detalhada nas seções
seguintes.
5.3.1 Camada Fonte de Dados
Em qualquer ambiente de DW é necessário que os dados sejam extraídos de alguma fonte de
dados, pois o DW não é um banco de dados convencional, e sim uma base de dados não
volátil e, por isso, é um repositório de dados que tem como característica armazenar dados de
diversas fontes integrando-os.
Na arquitetura proposta só existem dois tipos de dados de origem, que poderão estar em dois
tipos de formatos:
• formato referência;
• formatos distintos.
Na arquitetura proposta, o formato referência é escolhido pelo projetista de DW de acordo
com o formato em que os dados serão armazenados no DW. Dados que estão em qualquer
outro tipo de banco ou em outros formatos (arquivos, planilhas eletrônicas, texto, etc), são
migrados na camada de ETL para o modelo normalizado no formato referência.
5.3.2 Camada ETL
Esta camada é onde ocorre a extração dos dados das fontes de origem e os armazena na área
de estágio. Nesta camada encontram-se os maiores problemas no desenvolvimento de um
DW. De acordo com Shilakes & Tylman (1998), estima-se que mais que 1/3 do custo de um
DW são gastos com tarefas de ETL e problemas com extração, transformação e limpeza,
podem tomar 80% do tempo gasto no desenvolvimento de um DW (MILLET, PARENTE,
FIZEL, 2002).
64 Esta camada é composta por dois módulos, o módulo de migração e o módulo de extração
transformação e carga. As funções da camada ETL na arquitetura proposta são realizadas
através da colaboração entre esses módulos de maneira independente. Cada módulo é uma
unidade de programa com um comportamento determinado por parâmetros.
A principal vantagem da utilização de módulos é o isolamento das atividades de extração em
processos distintos e bem definidos, o que facilita as manutenções que se façam necessárias e
a perfeita adaptação e aproveitamento das características de cada ambiente.
O primeiro módulo, o módulo de migração, faz a verificação do tipo de formato dos dados de
origem. Se os dados não estiverem em um formato referência, a fonte de dados passará por
um processo de migração de dados, integrando e transformando no formato referência, como
é mostrado na Figura 15.
Passo 1 Passo 1
Passo 3
Criação do Modelo Lógico de dados no Formato Referência
ou
Bases de Dados em formatos Distintos
Outros Tipos de Arquivos
Modelo de Dados Lógico no Formato Referência
Migração do Modelo de Dados Lógico para o Formato Referência
Criação do Modelo Físico de dados no Formato Referência
Base de Dados Física no Formato Referência
Passo 2
Migração dos dados Para o Formato Referência
Fontes de Origens
Figura 15 – Módulo de Migração da Camada ETL
O primeiro passo neste módulo é verificar se a fonte de dados de origem é uma base de dados
no formato referência. Se a base de origem estiver no formato referência, os dados já estão
preparados para o próximo módulo, senão os dados serão migrados. Após esta verificação
inicial é verificado se os dados são uma base de dados ou se são algum outro tipo de arquivo,
como por exemplo, arquivos texto. Após essa verificação é gerado um modelo lógico da fonte
65 de dados referência a partir dos dados das fontes de dados de origem. Estando o modelo
lógico pronto, o modelo físico no formato referência é gerado e a base de dados é criada.
Com a base de dados no formato referência criada, são então gerados os procedimentos de
migração de dados, que podem ser feitos manualmente ou com auxílio de ferramentas de
ETL. Esta etapa exige muito cuidado, pois deve-se tratar todos os problemas que possam vir
a ocorrer na migração devido a não equivalência de muitos aspectos entre as bases de dados,
ou mesmo entre arquivos e bases de dados, como por exemplo: problemas com chaves,
transformações de tipos de dados, problemas de acentuação.
Este processo de migração facilita a manipulação e a consistência dos dados e auxilia na
integração de fontes distintas de dados.
O módulo de extração, transformação e carga tem como funções a extração, limpeza e
integração dos dados na área de estágio. Neste módulo, os dados das bases de origens já
migrados são extraídos, seguindo um planejamento prévio, de acordo com o que foi definido
na fase de análise de requisitos e seguindo a modelagem feita previamente. Apenas dados que
serão utilizados no DW são extraídos.
Após essa extração inicial, os dados passam por procedimentos onde são tratados de acordo
com a modelagem feita na área de estágio. Os dados são primeiramente limpos, em seguida,
podem sofrer transformações e serem integrados a dados de diferentes fontes de dados e, por
fim são incorporados na área de estágio.
A camada ETL proposta tem como objetivo facilitar a integração de dados de diversas fontes,
fazendo com que os dados mantenham a consistência, além de facilitar a manutenção e
inserção de novas fontes de dados.
5.3.3 Camada Área de Estágio
A área de estágio é um passo intermediário entre os dados de origem e os dados no DW. É na
área de estágio que os dados sofrem as primeiras limpezas, transformações e integrações.
66 Em qualquer DW no qual informações existam em múltiplos sistemas não integrados, essas
informações precisam ser consolidadas em um único ponto de gravação. O desafio é
identificar a melhor fonte, padronizar códigos e formatos, tratar dados irregulares e identificar
qualidade de dados.
Segundo Dumoulin (2000), a área de estágio de dados simplifica grandes projetos de DW e
facilita a etapa de manutenção do DW. A partir do projeto lógico da área de estágio,
modeladores de dados têm uma boa idéia dos atributos e fontes necessários para povoar o
DW. A área de estágio de dados serve como uma linha divisória entre os sistemas fontes e o
DW, devendo conter apenas informações necessárias para povoar o warehouse.
A área de estágio tem uma grande interação com a camada ETL, pois todas as ferramentas e
procedimentos da camada ETL devem ter como parâmetros os atributos definidos nas bases
de dados da área de estágio, sendo que a área de estágio junto com a camada ETL engloba
todas as bases de dados e ferramentas que são necessárias para transformar, integrar, carregar,
controlar a qualidade e limpar os dados (TOMBROS & HÄBERLI, 2001).
A partir das fontes de origem até os dados nos formatados na área de estágio os seguintes
passos devem ser executados:
1. Separação dos dados por granularidade. Isto se faz necessário, pois os sistemas de
origens em muitos casos incluem dados em diferentes níveis de detalhes.
2. Limpeza dos valores de atributos. Neste passo são tratadas as seguintes situações,
entre outras: valores descritivos inconsistentes, decodificações ausentes, códigos
inválidos, dados inválidos e dados ausentes.
3. Transformação dos dados. Essas transformações incluem: cálculo aritmético,
conversões de tempo, tratamento de valores nulos, conversões de tipo de dados e
unidades monetárias.
4. Troca das chaves operacionais por chaves substitutas. Neste passo as chaves são
trocadas para facilitar a normalização dos dados.
5. Garantia da qualidade dos dados. Este último passo verifica a consistência dos dados,
e de valores contidos nas tabelas.
A utilização desses passos traz como benefícios dados de qualidade, padronizados e
consistentes, facilitando assim a integração e a carga de dados no DW.
67 A área de estágio, definida neste trabalho, utiliza um modelo de dados normalizado para
permitir uma maior consistência dos dados e facilitar o processo de integração entre bases de
dados distintas, mas permite a utilização de relacionamentos não normalizados entre tabelas
que se transformarão em dimensões e mini-dimensões dessas tabelas.
Decisões como determinar se um dado é um atributo de uma dimensão ou deve-se criar uma
mini-dimensão para aquele atributo, quais relacionamentos são normalizados e quais não são,
devem ser tomadas pelo projetista, pois essas decisões podem facilitar a integração e a
consistência dos dados, como pode prejudicar todo o projeto.
5.3.4 Camada Data Warehouse
Nesta camada é onde se encontra o DW, que é a área de armazenamento dos dados e segue o
modelo proposto por Kimball et al. (1998), utilizando-se da implementação BUS, a qual é
baseada em modelos dimensionais mantidos em diversos data marts, contendo tabelas de
dimensões e de fatos previamente estruturadas para manter a integração entre os dados dos
diversos data marts.
A modelagem dimensional é usada porque existem, segundo Song et al. (2001), duas
principais vantagens na utilização de modelos dimensionais em ambientes de DW. Primeira,
um modelo dimensional fornece uma análise espacial multidimensional em ambientes de base
de dados relacionais, onde são analisados dados factuais através das dimensões. Segunda, um
típico modelo dimensional desnormalizado tem um esquema de estrutura simples, o qual
simplifica o processamento de consulta de usuários finais elevando o desempenho.
Para manter a integração entre os data marts, a arquitetura vale-se da estruturação dos data
marts seguindo a idéia da arquitetura BUS proposta por Kimball et al. (1998), onde, após um
levantamento dos requisitos e das fontes de dados, é elaborada uma matriz para identificação
das interseções dos data marts. Deste modo, a definição do modelo de dados segue os
seguintes passos:
1. listar os data marts;
2. listar as dimensões de cada data mart;
3. marcar as interseções entre os data marts.
68 No primeiro passo é feito o levantamento dos data marts que estejam em uma única fonte de
dados inicialmente. Provavelmente, após este levantamento inicial, seja possível reunir data
marts de fontes distintas em um só.
No passo 2 são então listadas as dimensões para os data marts criados no passo 1, e são
marcadas as intersecções entre os data marts e suas dimensões e, no passo 3, montada a
matriz de barramento, como mostrado na Figura 16.
A partir da matriz de barramento pronta, deve ser definido o data mart a ser construído. Deve
ser considerado para a escolha um data mart que represente um negócio de impacto para a
corporação ou instituição. Na seqüência, deve ser declarada a granularidade da tabela de fatos
do data mart e verificadas quais dimensões estão relacionadas à tabela de fatos. E por fim,
são definidos os fatos que compõem a tabela de fatos.
Figura 16 - Matriz de Barramento
Seguindo este modelo de implementação, existe a possibilidade de haver sobreposição de
fatos entre as tabelas de fatos dos data marts, além de replicação de dimensões. Para resolver
este problema, a arquitetura BUS propõe o uso de uma área comum de dados, na qual constam
as dimensões e os fatos que são utilizados por vários data marts, além de agregados que
integram e sumarizam dados utilizados em conjunto, desde que haja viabilidade técnica. Na
camada DW da Figura 14 é ilustrada a área de armazenamento proposta pela arquitetura.
69 Com a definição da área comum, são reduzidas de forma considerável as replicações de dados
entre os data marts, fazendo que haja um ganho em desempenho e consistência no processo
de incorporação.
Na camada DW é onde os dados são armazenados para acesso das ferramentas de consulta e
mineração de dados, por isso é de suma importância uma ênfase especial no desenvolvimento
de sistemas de controle de qualidade de dados e utilização de ferramentas que auxiliem a
correção de erros. Além da qualidade dos dados, também é muito importante que se tenha um
acesso rápido a esses dados, e que estes estejam atualizados de acordo com o definido no
projeto. Essas bases de dados contêm dados no nível mais baixo de granularidade e alguns
dados levemente sumarizados.
Utilizando esse método de implementação tem-se a implementação de data marts
incrementais, conseguindo-se resultados rapidamente, além de conseguir uma visão
corporativa muito abrangente.
5.3.5 Camada Área de Análise
Na área de análise figuram os componentes responsáveis pela busca de dados no DW, como
ferramentas OLAP, mineração de dados e visões materializadas, sendo que estes
disponibilizarão informações aos usuários.
Para qualquer tipo de componente que seja utilizado, é necessária uma preparação especial
dos dados no uso das ferramentas, além de ser necessária uma grande interação com o
metadados.
Apesar de não fazer parte deste trabalho a definição de um modelo específico para área de
análise, são descritas abaixo algumas características de componentes que podem ser inseridos
dentro dessa camada, como ferramentas OLAP e de mineração de dados.
As ferramentas OLAP permitem análise e gerenciamento, proporcionando um grande ganho
de desempenho como rápido acesso a uma grande variedade de visões de dados organizados
70 através da base de dados multidimensional. Mas essas ferramentas em geral necessitam que os
dados estejam em formatos pré-definidos.
As ferramentas de mineração de dados em geral são mais complexas do que as ferramentas
OLAP. A complexidade dessas ferramentas está relacionada com a complexidade dos
algoritmos que implementam as técnicas de mineração de dados, que são baseadas em
aprendizagem de máquina, inteligência artificial e métodos estatísticos. O principal objetivo
dessas ferramentas é buscar conhecimentos ocultos e relevantes dentro do banco de dados. As
ferramentas de mineração de dados necessitam que os dados sejam preparados em um formato
específico para que possam ser utilizados, o que pode tomar um grande tempo.
Uma solução mais simples do que o uso de técnicas de mineração de dados é a
disponibilização dos dados aos usuários através de visões materializadas.
A materialização de dados multidimensionais em grandes repositórios de dados facilita rápida
análise de dados on-line.
Nesta área existem muitos estudos desenvolvendo métodos para geração de consultas e
manutenção de cubos de dados. Agrawal et. al. (1997) desenvolveu vários algoritmos para
computar coleções de agregações relatadas em cubo de dados. Ross & Srivastava (1997)
propôs um algoritmo para computação rápida de cubo de dados sobre relações em cubo de
dados esparsas.
Uma vantagem da utilização de visões materializadas é que, embora consultas OLAP ocupem
pouca saída, o volume de processamento em geral é muito alto. Por exemplo: “Ache o total
de volume de vendas dos 10 últimos anos”. O processamento desta consulta pode levar horas
“varrendo” grandes tabelas e agregações, enquanto o resultado será apenas 8-bytes, que é um
valor que pode ser facilmente armazenado para uso futuro.
Uma desvantagem da utilização de visões materializadas é o grande espaço em disco que é
necessário para armazenar as consultas. Uma alternativa para esse problema é o uso de um
disco exclusivo para o gerenciamento de dados materializados, sendo que este módulo fica
totalmente separado do DW, tendo um acesso independente e não prejudicando o desempenho
do DW (KOTIDIS & ROUSSOPOULOS, 1999).
71 5.3.6 Metadados
No metadados residem informações variadas que são utilizadas e alimentadas por vários
componentes da arquitetura. As informações contidas neste repositório são essenciais para o
pleno funcionamento dos componentes e para a sua manutenção.
A estruturação dos dados reunidos no repositório de metadados é feita através de regras
definidas na camada ETL e por modelos de dados e tabelas descritivas da camada DW.
As regras para a camada de ETL devem ser definidas e dividas em três partes:
• regras para a extração: define a origem dos dados e o local de armazenamento na área
de estágio;
• transformação: define o código responsável pela limpeza, integração e transformação,
entre outros, dos dados existentes na área de estágio;
• incorporação: define a origem dos dados da área de estágio e as tabelas dos data marts
destino.
O metadados do DW deve armazenar as seguintes características:
• dados relativos ao projeto lógico, tais como, modelo de dados dos data marts, da área
de controle e dos agregados, bem como histórico de incorporações e manutenções no
modelo, principalmente as que dizem respeito à criação de agregados, como motivo e
resultados obtidos;
• dados relativos ao projeto físico, tais como esquema de particionamento, índices e
outros;
• dados relativos à manutenção, tais como, procedimento de backup, restauração e
outros.
Na área de análise, os metadados devem guardar informações para possibilitar o acesso das
ferramentas de análise, e devendo ser armazenados os seguintes dados:
• dados relativos aos usuários, tais como, detalhes de um valor calculado, dados
disponíveis e última carga, entre outros;
72
• os dados mantidos para utilização do re-direcionamento das consultas, tais como,
hierarquia nas dimensões, conteúdo das tabelas, tempo de resposta, número de
registros, descrição dos agregados existentes, entre outros.
5.4 CONSIDERAÇÕES FINAIS
Um dos principais pontos na implementação de um DW é a escolha da metodologia de
desenvolvimento e a definição da sua arquitetura, pois estes pontos são cruciais para o sucesso
do projeto, afetando diretamente variáveis como prazo, custo, satisfação do usuário e
requisitos de recursos.
A arquitetura apresentada neste capítulo utiliza a implementação BUS em conjunto com a
metodologia de data marts incrementais. Cada camada da arquitetura foi projetada de modo a
ser independente, facilitando cada uma das etapas da construção do DW.
Os principais diferenciais da arquitetura, segundo os seus componentes são:
• o processo de extração dos dados dos sistemas operacionais é baseado na
padronização dos dados, onde todos os dados devem estar em um mesmo formato para
iniciar a limpeza, transformações e integração na área de estágio, facilitando a
integração de dados de diferentes fontes de dados, que é um dos maiores problemas no
desenvolvimento de um DW;
• a área de estágio utiliza a modelagem normalizada em conjunto com a modelagem
usada em modelos dimensionais, o que facilita a integração dos dados da área de
estágio para o DW;
• na camada DW, além dos data marts, existe uma área comum onde residem as tabelas
de dimensões comuns aos data marts, além dos agregados, o que facilita o processo de
extração e a gerência do metadados;
• na área de análise, existe a possibilidade de uso de ferramentas, ou seja, não é
determinado nenhum modelo específico para essa área, podendo ser adaptadas novas
ferramentas para ser fazer a análise dos dados.
73
O DW construído será utilizado no projeto Intersul, portanto, espera-se que a construção
de um DW com dados regionais de C&T ajudará na tomada de decisões nesta área é
melhorará a utilização de recursos destinados à C&T.
74 6 CONSTRUÇÃO DO DW PARA GESTÃO EM C&T
6.1 INTRODUÇÃO
Em estudos feitos sobre o ambiente de ciência e tecnologia no Brasil verificou-se que 78%
dos grupos de pesquisas no Brasil encontram-se no estado de São Paulo (GUIMARÃES,
1995), e que as pesquisas estão totalmente concentradas em universidades, e apenas em torno
de 11% exercem suas atividades em centros de pesquisas de empresas privadas (MCT, 2000),
enquanto que em países desenvolvidos esse número é de 50%, podendo chegar a mais de 70%
no caso do Japão (ARRUDA, 1994).
Além da má distribuição dos grupos de pesquisas e das áreas de investimentos, o Brasil ainda
enfrenta problemas de verbas insuficientes na área de C&T, causando inúmeras dificuldades
como falta de equipamentos e perda de profissionais para universidades e empresas do
exterior. O projeto Intersul vem para tentar solucionar muitos desses problemas, e este
trabalho se enquadra dentro do projeto Intersul, o qual a arquitetura é mostrada na Figura 17.
CAPES CNPq
Base Integrada
Data Warehouse
Pós-Graduação Professores
Bolsistas
Grupos de Pesquisa
Mineração de Dados
INTERSUL • Planejamento • Administração • Avaliação • Projetos • Análises
Universidades Institutos Centros do Sul
Fundações Estaduais da região Sul
Site do Intersul
Figura 17 - A Arquitetura do Sistema Intersul
75 Neste capítulo é apresentado como a arquitetura discutida no capítulo anterior foi aplicada
com sucesso na construção de um DW para gestão em C&T, de forma a poder ajudar no
processo decisório.
6.2 ABORDAGEM DO PROBLEMA
Na tentativa de buscar soluções para os problemas apresentados neste trabalho, foi proposto o
projeto Intersul, que tem como objetivo desenvolver um sistema informatizado de gestão de
C&T, atendendo profissionais ligados a esta área. Esse sistema deverá contribuir para o
aumento da produtividade e efetividade dos investimentos em C&T na região Sul. O projeto
Intersul se concentra nas funcionalidades de planejamento, por considerar o componente
planejamento fundamental para que os recursos sejam gastos da melhor forma possível.
A construção do DW para gestão em C&T faz parte desse projeto, sendo o DW necessário na
aplicação de ferramentas de mineração de dados que darão suporte à tomada de decisão.
6.3 ARQUITETURA DO SISTEMA
A arquitetura do sistema de DW para gestão em C&T foi definida segundo o modelo
apresentado no capítulo anterior. Desta forma, o sistema foi concebido a partir de camadas,
conforme ilustra a Figura 18, cada qual construída de maneira independente para permitir
mudanças internas em cada uma das camadas sem causar impacto sobre toda a estrutura.
O ambiente de DW possui uma camada onde são armazenadas as bases de dados relativas a
C&T, uma camada onde estas bases são extraídas para a área de estágio, uma camada de DW
que é onde os dados ficam armazenados e uma camada de análise onde existem ferramentas
de acesso aos dados do DW.
76
Font
es d
e D
ados
E
TL
Áre
a de
Est
ágio
D W
Á
rea
de A
nális
e
Rep
ositó
rio d
e M
etad
ados
Extração, Transformação e Carga
Migração da base Sybase para Base de Dados Oracle
Base de Trabalho1
OLAP e Ferramentas de Mineração de Dados
Data Mart 1
Base de Trabalho2
Área de dados Comuns
Data Mart 2
Grupos de Pesquisas Pesquisadores Instituições de Educação
Figura 18 - Arquitetura Geral do Sistema
A construção do DW foi realizada seguindo as etapas que são descritas na seqüência. 6.3.1 Definição das Fontes de Dados
Na etapa de definição da camada Fonte de Dados foram estudadas algumas das possíveis
fontes de dados de origem, a base de dados Lattes e a base do sistema coleta da CAPES. A
base de dados Lattes contém dados sempre atualizados, através do currículo Lattes, sobre os
pesquisadores brasileiros e a base da Coleta CAPES é uma base que contém dados sobre os
programas de pós-graduação do Brasil.
77
Os dados da Plataforma Lattes, utilizados nesta pesquisa, foram obtidos junto ao Grupo Stela2
que possui acordo com o CNPq para utilização restrita à pesquisas e com controle de
privacidade das informações. A plataforma Lattes continha dados na sua maioria dos anos de
1997 até 1999.
Os dados da plataforma de Coleta Capes estavam no formato Sysbase e para cada instituição
existia uma base de dados distinta e não existia as bases de algumas instituições, como a
própria UEM. Os dados da base de dados do Coleta Capes são até o ano de 1998.
Foram analisados os modelos de dados, os dicionários de dados, o conteúdo de cada tabela e
atributos, seus tipos de dados e as possibilidades de integração. Tendo, dessa forma uma
grande idéia de quão útil essas fontes de dados podem ser, quanto elas poderão gerar de
respostas depois de transformadas e quão difícil será esse processo.
6.3.2 Construção do Sistema
A construção de um sistema de DW se dá, inicialmente, através da análise dos requisitos,
sendo levantados os principais requisitos que o sistema deve ser capaz de responder, a partir
de então são levantadas as medidas necessárias para respondê-los.
Com base nas conclusões tiradas a partir de possíveis usuários do sistema, junto com uma
compreensão dos principais sistemas de origem, foi feito o esboço de uma matriz de
barramento de DW com os principais processos de negócio sendo expressos em linhas e as
principais dimensões em colunas.
A partir desse momento, cada uma das colunas e dimensões começaram a ser detalhadas. Os
processos de negócio dão origem aos data marts e novas dimensões começam a ser criadas
para cada um dos data marts. Neste ponto, a granularidade já deve ser decidida, para que seja
gerada a matriz de barramento final do projeto.
2 O Grupo Stela consiste no Laboratório de Desenvolvimento de Sistemas de Informações e de Inteligência Artificial do Programa de Pós-Graduação em Engenharia de Produção da Universidade Federal de Santa Catarina. Desde 1997 o Grupo Stela é o responsável pelo desenvolvimento da Plataforma Lattes do CNPq.
78 Após todos estes passos, foi criada a matriz de barramento, como mostrada na Figura 19,
fazendo a intersecção entre os data marts e suas dimensões. Durante esta fase foi
desenvolvido um conjunto mestre de fatos e dimensões padronizados que possui uma
interpretação uniforme, o que estabelece a estrutura da arquitetura de dados.
A criação da matriz de barramento do DW é de fundamental importância para o
desenvolvimento do DW, por ser essa matriz um dos produtos genéricos preliminares mais
importantes de uma implementação de DW. É um recurso híbrido que faz parte da ferramenta
de projeto técnico, da ferramenta de gerenciamento de projeto e da ferramenta de
comunicação.
Figura 19 - Matriz de Barramento do DW
6.3.3 Implementação dos Módulos da Camada ETL
Na camada ETL foram implementados todos os módulos de extração, transformação, limpeza
e integração dos dados necessários para a camada Área de Estágio.
Após o estudo das fontes de dados, a criação da matriz de barramento e a definição dos
modelos lógicos da área de estágio, foi verificada a necessidade de se fazer a migração da
base de dados do sistema coleta CAPES que está em Sybase para o SGBD Oracle 9i, que foi
definido como o formato referência para este projeto.
Inicialmente foi feita a conversão do modelo de dados, seguindo o processo mostrado na
Figura 20. Para tanto foi utilizada a ferramenta CASE ErWin que possibilitou a geração de
79 um modelo lógico da base de dados Sybase. A partir do modelo lógico gerado, foi criado um
modelo físico em Oracle e feita a geração do esquema, criando assim a base de dados
correspondente em Oracle.
TRANSFORMAÇÃO DO MODELO DE DADOS SYBASE PARA ORACLE
Base Sybase
Modelo Lógico
Modelo Físico em Oracle
Gerar Modelo Físico em Oracle
Gerar Modelo Lógico
Base Oracle
Módulo de Migração e Integração dos Dados
Figura 20 -Esquema de Criação do Modelo em Oracle
Após ser criada a base de dados da coleta CAPES correspondente em Oracle, foi necessário
migrar os dados do SGBD Sybase para Oracle, que corresponde a parte em cinza escuro da
Figura 20. Após ser realizado um estudo, foi decidido que a melhor solução para fazer essa
migração e resolver os conflitos estruturais e semânticos seria a construção de uma ferramenta
em Delphi 7.0.
A ferramenta de migração foi construída em Delphi 7.0 porque além de migrar os dados foi
necessário integrá-los, pois para cada instituição havia uma base de dados distinta. Sendo
assim, a ferramenta foi projetada para migrar e integrar os dados de diferentes instituições,
tratando dados replicados, problemas com chaves e problemas com a acentuação dos dados
que ocorreram. A tela do sistema construído é mostrada na Figura 21.
80
Figura 21 – Tela do Sistema de Migração de Dados
Além do módulo de migração de base de dados para Oracle, a camada ETL possui outro
módulo que tem a função de extrair, limpar, transformar e integrar os dados na área de
estágio. Neste módulo é feita a extração dos dados que serão utilizados na área de estágio de
acordo com o modelo de dados da área de estágio. Após os dados serem extraídos, eles são
limpos e adequados ao modelo de dados da área de estágio.
Todo esse módulo foi implementado através de stored-procedures construídas com a
linguagem PL-SQL da Oracle, solução que se mostrou bastante eficiente em termos de
desempenho e flexibilidade. O Apêndice A possui uma tela com stored-procedures criadas no
projeto.
Todos os passos nesta camada são documentados nos metadados, mantidos através de
planilhas, as quais são armazenadas informações dos dados, como:
• campos de origem;
• mapeamento dos atributos;
• conversão de atributos;
• características físicas de conversões;
• troca de nomes;
• troca de chaves;
• descrições sobre os campos.
81 6.3.4 Modelagem da Área de Estágio
A área de estágio é o local onde serão armazenados os dados coletados e posteriormente
transformados. Ela foi construída sobre o banco de dados Oracle 9i, devido à robustez deste
gerenciador de banco de dados. O metadados da área de estágio é constituído pela
documentação completa do modelo, mantida através da ferramenta CASE Er-Win, além das
informações adicionais contidas no metadados da camada ETL.
A modelagem da área de estágio foi feita utilizando o modelo de dados relacional
normalizado em conjunto com técnicas da modelagem dimensional, evitando assim
redundância dos dados e facilitando a conversão dos dados para o DW. As tabelas foram
modeladas de acordo com a matriz de barramento, sendo que os atributos das tabelas são
baseados nas dimensões definidas.
Na Figura 22 é mostrada uma parte do modelo da área de estágio proposta para essa
arquitetura, os modelos de dados completos são mostrados no Apêndice B. O objetivo
principal desse modelo é facilitar a integração de diferentes fontes, mantendo a consistência
dos dados.
Figura 22 - Modelo Parcial e Simplificado da Área de Estágio
Este modelo é dividido basicamente em três partes. As tabelas claras na Figura 22
representam tabelas que posteriormente serão transformadas em dimensões ou tabelas de fatos
82 no DW. As tabelas em cinza claro representam as mini-dimensões, que são explicadas na
seção seguinte, e as tabelas cinza em escuro representam o relacionamento entre as tabelas e
suas mini-dimensões. Os relacionamentos entre as tabelas e as suas mini-dimensões podem
ser de dois tipos: relacionamentos n para n normalizado ou relacionamentos pontes, que são
utilizados em modelos não normalizados, como o modelo estrela. A utilização de
relacionamentos pontes facilita a inserção desses dados no DW, já que eles devem estar nesse
formato no DW.
Na Figura 22 o modelo está normalizado, mas também possui em alguns relacionamentos
uma modelagem normalmente usada em modelos dimensionais. Essa modelagem é baseada
no proposto por Kimball et al. (1998), no qual para tabelas que possuem campos
multivalorados é criada uma mini-dimensão para suportar os vários valores do campo. Para
relacionar essa mini-dimensão com a tabela da qual foi derivada, é criada uma tabela ponte,
onde é definido um grupo de valores para cada indivíduo que possui vários campos na mini-
dimensão.
A área de estágio também é responsável pela incorporação em cada DM dos dados
transformados existentes na área de estágio. O módulo de incorporação implementado vale-se
das regras existentes no metadados, as quais foram implementadas também na linguagem PL-
SQL da Oracle.
6.3.5 Definição da Camada DW
O repositório de dados é parte principal do ambiente de DW. A arquitetura é toda projetada
afim de que os dados sejam inseridos e consultados nesse repositório. Nele estão
representados todos os dados extraídos dos sistemas operacionais, necessários para o processo
de tomada de decisão.
A construção do DW se deu de forma incremental, seguindo a implementação BUS e a
metodologia de data marts incrementais. Desta forma, a construção do modelo de dados do
sistema seguiu os seguintes passos:
• levantamento dos data marts;
• definição básica da granularidade das tabelas de fatos;
83
• levantamento das dimensões de todo o modelo;
• padronização das dimensões de acordo com o método da matriz;
• definição lógica e física de data mart e ajustes no processo de extração, de forma
incremental.
A granularidade escolhida foi o nível mais atômico possível, que é uma linha de fato por
pesquisador. Com essa granularidade é possível detalhar as informações de pesquisadores,
grupos de pesquisa, instituições, cidades, regiões, países, áreas de conhecimento e qualquer
outra medição que se desejar realizar.
O processo de modelagem utilizado nesta arquitetura é baseado no processo clássico de
modelagem de banco de dados que distingue os modelos conceituais, lógico e físico estendido
pelo modelo de implementação proposto por Kimball et al. (1998). De acordo com esta
abordagem, antes de começar a modelagem de dados é necessário identificar todos os
possíveis data marts e dimensões que serão utilizados no DW. Isto é feito através da matriz de
barramento, sendo que as colunas da matriz representam as dimensões comuns usadas nos
diversos data marts. Desta forma, as dimensões são modeladas com dados que possam ser
utilizados por todos data marts que foram identificados na matriz de barramento.
O DW foi projetado de acordo com a modelagem dimensional estrela. Esta modelagem foi
escolhida pelas vantagens já apresentadas e porque a utilização de modelos dimensionais é
amplamente aceito como uma técnica viável para a entrega de dados para o usuário final em
um DW (KIMBAL et al., 1998; MEYERE & CANNON, 1998; AXEL & SONG, 1997;
DINTER et al., 1998).
No entanto, o esquema estrela não aceita relacionamentos muitos-para-muitos, mas este tipo
de relacionamento foi apresentado na área de estágio e deve, assim, ser transformado em
relacionamentos muitos-para-muitos entre fatos e dimensões no DW.
Segundo Song et al. (2001), este tipo de relacionamento em um modelo dimensional causa
vários problemas como a perda da simplicidade da estrutura do modelo estrela, aumentando a
complexidade na construção de consultas e piorando o desempenho pela adição de junções.
Neste caso, é desejável a representação de relacionamentos muitos-para-muitos com uma
semântica correta enquanto ainda é sustentada a estrutura do modelo estrela. Existem diversos
84
trabalhos para resolver este problema, como: (KRIPPENDORF & SONG, 1997;
THEODORATOS & SELLIS, 1998; LEHNER; ALBRECHT; WEDEKIND, 1998;
PEDERSEN & JENSEN, 1999; MOODY & KORTINK, 2000; KIMBAL et al., 1998).
A Tabela 2 apresenta resumidamente um comparativo entre as soluções propostas para fazer
relacionamentos muitos-para-muitos em uma modelagem dimensional.
Dentre essas soluções, a escolhida foi a de Kimball et al. (1998), por ser uma solução limpa e
fácil, sendo ideal para problemas que não tenham um grande número de relacionamentos
(SONG et al.,, 2001), o que se enquadra em nosso projeto.
85
Redundância Nome Fator de Ponderação (FP) Consultas Armazenamento Recomendações
Necessário
A atribuição de FP pode ser incomoda Leve
Ideal para dimensões sem limites superior no lado muitos e o PF pode ser facilmente calculado ou não é
necessário Método A
Tabelas Pontes de Kimball Adicionando novos diagnósticos
necessita recalcular a FP
Junções adicionais aumentam o tempo da consulta
96.1 MB Uma solução limpa
Não pode segurar um Fator de Ponderação
Requer muitos comandos OR, Processamento de resposta lento
Tabela de dimensões lista todas as combinações possíveis, pode ser
extremamente grande
Método B Tabela Dimensional Desnormalizada
com atributos de Posições-Flag Pode utilizar uma flag de diagnóstico preliminar
Esquema de índice de bitmap pode aumentar a velocidade de
processamento da consulta. 10.1 TB ( para 40 diagnosticos)
Por causa do requerer muito armazenamento, somente aplicações
onde o número de atributos de posições é muito pequeno (menos que
10) e fixo
Pode manter a estrutura do esquema estrela para facilitar a compreensão e
formar consultas Pode ser muito grande Use quando o número de valores da
dimensão for pequeno e desempenho da consultas for importante
Método C
Tabela Dimensional Desnormalizada com atributos não-posicionais &
campos concatenados
Depende do relacionamento entre tabela de Fatos e Dimensões
Uso de atributos concatenados e clausulas LIKE
Veja C-1 e C-2 abaixo Cria muitos valores nulos O comando LIKE incapacita a
indexação Pode ser muito grande Método C-1 Um-para-Um
Pode criar um Fator de Ponderação concatenado, mas incomodo Pode usar flags e índices de bitmaps
para as flags 219MB
Use somente quando a dimensão padrão aparecer na tabela de fatos 1-2
vezes
O comando LIKE incapacita a indexação Menos redundância que o método C-1
Use quando a dimensão padrão aparecer na tabela de fatos muitas
vezes Método C-2 Um-para-Muitos
Não pode utilizar um Fator de Ponderação por causa da natureza do
Um-para-Muitos Pode usar flags e índices de bitmaps para as flags 72.6 MB
Requer uma lógica complexa para encontrar registros existentes antes de
inserir um novo código
Não Necessita de um PF View é uma única tabela Pode causar redundância para outras FK´s na tabela de fatos
A tabela de fatos pode se tornar muito grande.
Necessita calcular agregações
Método D Tabela de Fatos de baixa
granularidade para ajustar o nível dos items
Pode utilizar uma flag de diagnóstico preliminar Consultas rápidas
201.1 MB Use somente para um limitado número
de atributos e itens de linha por transação
View é uma única tabela Trata duas tabelas de Fato Pode utilizar um PF
Consultas rápidas
Pode causar redundância para outras FK´s na tabela de fatos
Método E
Baixa granulardiade e fatos dividido em duas tabelas Pode utilizar uma flag de diagnóstico
preliminar É necessário calcular agregações 196.1 MB
Use quando duas tabelas de fatos podem ser usadas separadamente
Tabela 2 – Resumo dos Métodos: Fonte (Song et al., 2001)
86
A Figura 23 apresenta uma parte do modelo de dados do DW, nela é possível visualizar os
relacionamentos muitos-para-muitos entre fatos e dimensões e os relacionamentos entre
dimensões e mini-dimensões apresentados anteriormente. Na Figura 23 também é possível
verificar que mais de um fato utilizam uma mesma dimensão, de acordo com o que foi
proposto com o uso da matriz de barramento.
Figura 23 - Modelo Parcial e Simplificado do Modelo de Dados do DW proposto
Um modelo dimensional simplificado e desnormalizado, que melhora o processamento de
consulta de usuários finais e eleva o desempenho, foi obitdo através da utilização da
modelagem dimensional estrela em conjunto com técnicas de modelagem entre fatos e
dimensões muitos-para-muitos e entre dimensões multivaloradas.
Os metadados do DW concentram-se principalmente em detalhes lógicos e físicos. Devido ao
uso de um único repositório de dados, onde figuram todos os data marts, foram simplificados
a manutenção do SGBD e o gerenciamento dos metadados do processo de incorporação e da
área de análise.
87
6.3.6 Desenvolvimento da Camada Análise
Através da camada de análise consegue-se disponibilizar informações analíticas que podem
auxiliar no processo de tomada de decisões, que é o principal objetivo de um DW. Para
alcançar isto, são necessárias ferramentas que auxiliem os usuários a interagirem com o
ambiente de DW projetado.
Na camada análise são encontradas todas as ferramentas que podem ajudar na análise e no
processo de tomada de decisões estratégicas, como ferramentas OLAP e de mineração de
dados. Nesta camada foram feitos alguns estudos utilizando diferentes tipos de ferramentas.
Alguns testes foram realizados com a ferramenta da Oracle9i OLAP, mas a necessidade de
seguir passos muito rígidos através um modelo pré-estabelecido dificultou um pouco a sua
utilização.
O projeto Intersul foi um fator importante na decisão de qual ferramenta utilizar nessa
camada, pois nesse projeto está sendo desenvolvida uma ferramenta de mineração de dados
que tem como entrada dados do DW construído. Foram realizados alguns pequenos testes de
integração com essa ferramenta e foi apontado um resultado bastante satisfatório, não tendo
maiores problemas na sua utilização.
A maior parte dos resultados foi obtida através de visões materializadas. A materialização de
dados tem muitas vantagens, como facilitar rápidas análises de dados on-line, além de ter uma
implementação simples (HAN et al., 2001).
Outro fator importante a ser considerado no uso de visões materializadas é o fato de ser
possível trabalhar com dados que são mais freqüentemente utilizados. Com as visões pode-se
criar uma estratégia para seleção e materialização de visões baseada na freqüência de visões
acessadas. Isto permite uma adaptação dinâmica do conjunto de elementos vistos para um
padrão de retorno (SMITH et al.,1998).
A Figura 24 mostra o esquema de consultas através de visões materializadas neste projeto.
Utilizando os metadados e o modelo de dados é feita a seleção dos dados do DW, gerando
88
consultas SQL (Struct Query Language). Os resultados dessas consultas são as visões
materializadas, que podem tanto interagir com ferramentas para analisar dados e gerar
gráficos quanto serem tratadas e interagirem com ferramentas de mineração de dados.
Figura 24 - Esquema de Consulta no DW construído
6.3.7 Definição do Metadados
Em todas as etapas da construção do DW foram armazenadas informações no repositório de
metadados. A estrutura de metadados desse projeto foi feita através da utilização de planilhas,
nas quais foram guardadas informações sobre:
• dados das fontes de origem;
• dados da área de estágio;
• dados do DW
89
• mapeamento dos dados;
• conversões físicas dos dados;
• procedimentos implementados na camada de ETL;
• procedimentos implementados para carga no DW.
Além de planilhas, foi também utilizada a ferramenta CASE Er-Win, a qual possibilitou
armazenar todos os modelos de dados utilizados no projeto com informações detalhadas,
como: volume de dados utilizado e informações lógicas e físicas sobre tabelas, atributos e
chaves.
A enorme complexidade de se definir um metamodelo foi o principal motivo da utilização de
planilhas e da ferramenta CASE Er-Win para a implementação da estrutura de metadados. Isto
pode ser verificado através de um estudo feito por Bomfim (2001), o qual aponta que a
maioria das instituições públicas que implementaram um DW, ainda não possui uma estrutura
de metadados que envolva todo o ambiente de DW. As instituições que implementaram
metadados fizeram através de soluções próprias com recursos de HTML, ferramentas OLAP,
ferramentas CASE.
6.4 CONSIDERAÇÕES FINAIS
A disponibilização de informações que permitam uma análise sobre a situação de C&T no
Brasil é de fundamental importância para as instituições de pesquisa, auxiliando as decisões
que envolvem distribuição de recursos, acompanhamento da evolução dos diversos tipos de
pesquisas, entre outros.
Neste contexto o emprego de um DW se mostrou a solução adequada. A partir de bases de
dados normalizadas disponibilizadas com informações relacionadas aos pesquisadores,
instituições e grupos de pesquisas, pôde-se agrupar os dados de maneira a possibilitar a
extração de informações analíticas indispensáveis ao processo de tomada de decisão.
A aplicação da arquitetura proposta se mostrou bastante eficiente. Apesar de ocorrer algumas
mudanças de requisitos no decorrer do projeto, elas foram assimiladas com facilidade, pois
eram absorvidas com ajustes isolados nas camadas, sem afetar o conjunto.
90
Seguindo a filosofia de padronização de fontes de dados de origem, foram migradas as bases
de dados em formatos distintos para o formato referência escolhido. Desta forma, a
integração de dados foi facilitada pelo tratamento de possíveis inconsistências e replicações
de dados. Os dois módulos que compõem a camada ETL são guiados através do metadados de
ETL, sendo assim, toda modificação que se faça em qualquer uma das etapas desta camada,
seja ela na migração dos dados, coleta, limpeza, transformação ou na integração dos dados na
área de estágio é armazenada no metadados.
A modelagem utilizada na área de estágio ajudou muito o processo de integração de dados,
por reduzir o tempo de implementação, devido ao uso de parte da modelagem utilizada no
DW, diminuindo o número de fases entre a área de estágio e o DW.
A adoção da implementação BUS em conjunto com a metodologia de data marts incrementais
e de uma área comum de dados, se mostrou bastante eficiente. Assim, o DW foi construído de
forma incremental, o que torna a visualização de resultados mais rápida.
Com a estrutura proposta para a área de análise foi possível a obtenção de vários resultados e
a integração com uma ferramenta de mineração de dados, o que facilitou a validação da
arquitetura e do DW construído.
91
7 ESTUDOS DE CASO
7.1 INTRODUÇÃO
O DW tem como objetivo ser uma base de dados de consulta que possa auxiliar no processo
de tomada de decisão. Assim, neste capítulo os resultados de estudos de casos realizados com
o DW construído. Nestes estudos, foram feitas consultas sobre propriedade intelectual,
titulação, tempo de defesa nos programas de mestrado e número de publicações de livros.
7.2 ESTUDOS DE CASO
Através de consultas ao DW foram conseguidos alguns resultados, alguns esperados e outros
surpreendentes. Na análise dos resultados, deve ser levado em consideração que as bases de
dados de origens estão um pouco defasadas (os dados sobre cursos de pós-graduação são do
ano de 1998 e do Lattes são de 1997 a 1999) e contêm apenas dados regionais, não podendo
assim refletir a realidade nacional, mas mesmo assim, dá-se uma idéia de como se comporta a
pesquisa e os pesquisadores de um modo geral no Brasil.
7.2.1 Estudo Sobre a Propriedade Intelectual
O Brasil é um país que tem sofrido alguns problemas por não ter a cultura de fazer patentes e
registros. Um exemplo disso é o fato de empresas japonesas patentearam o processo de
derivados de cupuaçu. Essas empresas têm cinco patentes de processo de elaboração de
produtos com cupuaçu. O processo de fabricação foi desenvolvido pela Emprapa (Empresa
Brasileira de Pesquisa Agropecuária), um órgão do governo federal, e anunciado há cerca de
três anos, mas não havia sido registrado (INDRIUNAS, 2003).
Através do DW, foi constatado que dentre todos os processos e produtos criados pelos
pesquisadores a partir do ano de 1990, apenas 0,08% geraram patentes. Apesar de ser
esperado que no Brasil se gere poucas patentes, este número é muito baixo. No Brasil, quando
a pesquisa é feita em instituições públicas, o pesquisador não tem o incentivo de fazer a
92
patente. Como quase a totalidade da pesquisa no Brasil é feita em instituições públicas, o
número de patentes e registros é muito baixo.
7.2.2 Titulação
Uma outra pesquisa realizada foi a busca do número de artigos publicados. Como era de se
esperar o número de artigos publicados no Brasil vem crescendo nos últimos anos, como
pode ser visto no Gráfico 3.
Número de Artigos Por Ano
0,001.000,002.000,003.000,004.000,005.000,006.000,007.000,008.000,009.000,00
1975
1977
1979
1981
1983
1985
1987
1989
1991
1993
1995
1997
1999
2001
Ano
Núm
ero
de A
rtig
os
Gráfico 3 – Número de Artigos Publicados por Ano
Através do DW pode-se verificar também que a maioria dos pesquisadores que atuam no
Paraná se graduaram nele, como é mostrado no Gráfico 4. Mas este mesmo gráfico mostra
que à medida que o pesquisador busca por uma graduação mais elevada, como mestrado ou
doutorado, ele necessita se direcionar a outros estados, principalmente São Paulo, onde está
concentrada a maior parte dos pesquisadores no Brasil.
93
Titulação
0
20
40
60
80
100
Graduação Especialização Mestrado Doutorado
Formados (%)
PR
OUTROS
Gráfico 4 – Graduados no Estado do Paraná
7.2.3 Tempo de Defesa nos Programas de Mestrado
Uma outra pesquisa realizada no DW construído mostrou a relação entre o regime letivo dos
programas de mestrado e o tempo de defesa dos alunos. O Gráfico 5 mostra essa relação.
Regime Letivo do Programa
Média de Tempo de Defesa em Programas de Mestrado
0102030405060
Geral Antes de 1996 A partir de1996
Ano de Entrada no Programa
Núm
ero
de M
eses
Media GeralAnualSemestralQuadrimestralTrimestral
Gráfico 5 – Média de Tempo de Defesa de Mestrado por Regime Letivo
O Gráfico 5 é dividido em 3 partes. A primeira parte é a média geral de tempo de defesa do
mestrado de acordo com os regimes letivos. A segunda parte é a média geral de tempo de
conclusão do mestrado de acordo com os regimes letivos para alunos que ingressaram no
94
programa antes de 1996, e a última parte é a média de tempo para alunos que ingressaram nos
programas de mestrado a partir de 1996.
A média de tempo de defesa do mestrado a partir de alguns anos atrás diminui muito, como
pode ser visto no Gráfico 5. Foi usado o ano de 1996 como delimitador, pois, através de
consultas percebeu-se que havia uma grande diferença entre o tempo de defesa antes e depois
desse ano.
Através deste gráfico pode-se verificar que a partir do momento em que a média de tempo de
defesa de mestrado diminui, a diferença entre média de tempo dos regimes letivos é muito
pequena, apenas programas com regime letivo anual apresentaram uma média de tempo de
defesa um pouco superior.
7.2.4 Número de Publicações de Livros
A última pesquisa mostrada neste capítulo, compara a diferença entre o número de
publicações de livros ou capítulo de livros entre homens e mulheres em diversas faixas de
idade. Como pode ser visto no Gráfico 6, a diferença de publicações até os 35 anos entre
homens e mulheres é muito pequena. Na faixa dos 35 aos 45 anos essa diferença aumenta e
depois diminui novamente. Através deste gráfico, consegue-se perceber que existe uma faixa
de idade na qual o número de publicações de livros ou de capítulos de livro aumenta entre
homens e mulheres, mas não é possível concluir a razão desse aumento. Uma possível causa
seria que nesta faixa de idade as mulheres tiveram filhos, mas esta hipótese não pode ser
constatada, pois no DW construído não contém dados pessoais dos pesquisadores que
comprovem isto.
95
Número de Publicações de Livros ou Capítulos de Livros
0
1
2
3
4
5
6
25 de 25 a 35 de 35 a 45 de 45 a 55 55Faixa de Idade
Núm
ero
de P
ublic
açõe
s
MulheresHomens
Gráfico 6 – Número de Publicações de Livros ou Capítulos de Livros
Com este gráfico fica óbvio que quanto mais dados um DW tiver, conclusões mais precisas
podem ser conseguidas. Sendo assim, uma base de dados que seria muito interessante de ser
incorporado ao DW criado é a base de dados do IBGE (Instituto Brasileiro de Geografia e
Estatística), pois com essa base seria possível verificar fatores externos que influenciam direta
e indiretamente a pesquisa e os pesquisadores no Brasil.
7.3 CONSIDERAÇÕES FINAIS
Neste capitulo foram apresentados alguns dos estudos realizados e resultados obtidos através
do DW criado.
Os estudos realizados foram bastante diversificados, como pode ser visto na relação abaixo:
• o número de patentes e registros realizados;
• o número de artigos publicados por ano no Brasil;
• o número de graduados no Paraná nos diversos níveis de graduação;
• a média de tempo de defesa de mestrado por regime letivo;
• o número de publicações de livros ou capítulos de livros.
Todos os estudos mostraram virtudes e defeitos da pesquisa e pesquisadores no Brasil e
através deles um gestor de C&T tem suporte para tomar decisões que melhorem a pesquisa.
96
Com isso, um DW para gestão em C&T se faz necessário por trazer dados confiáveis, dando
assim um grande suporte aos gestores no processo de tomada de decisão.
97
8 CONCLUSÃO E TRABALHOS FUTUROS
Os tomadores de decisão na maioria das empresas não possuem suporte computacional
adequado e eficiente para o desempenho de suas tarefas. Muitos deles estão sujeitos ao
fracasso em suas decisões de negócio por terem que se basear apenas em sua experiência
profissional e/ou em seu "faro para o negócio".
Nos últimos anos, muitas pesquisas estão sendo direcionadas ao desenvolvimento de técnicas
e sistemas que dêem suporte à tomada de decisões.
Ferramentas OLAP e de mineração de dados são classe de sistemas de suporte à tomada de
decisões que estão em constante evolução. No entanto, muitas dificuldades ainda são
encontradas no desenvolvimento e uso desses tipos de ferramentas. Um tipo de dificuldade
está relacionado ao acesso aos dados que geralmente estão espalhados em diferentes bases de
dados com diferentes formatos.
A solução para este tipo de problema geralmente está na construção de um DW que integra
dados originados de diversas fontes em diferentes formatos. No DW, os dados são preparados
e direcionados ao negócio da empresa, facilitando a busca de conhecimentos interessantes que
darão suporte à tomada de decisões.
O sucesso na construção de um DW está diretamente relacionado à definição de uma
arquitetura de implementação e à escolha de uma metodologia de desenvolvimento.
Este trabalho apresentou a definição de uma arquitetura de DW para gestão em C&T no Brasil
e descreveu como o DW foi construído.
A arquitetura proposta foi desenvolvida baseando-se na implementação BUS e na
metodologia de data marts incrementais. Cada camada da arquitetura foi projetada de forma a
conseguir a máxima independência possível, sendo que a camada superior utiliza parâmetros
da camada imediatamente inferior a ela. Além disso, na definição da arquitetura preocupou-se
com a integração de diferentes fontes de dados. Para facilitar esta integração, foi especificado
98
um formato padrão. Sempre que determinada fonte de dados não estiver de acordo com este
formato, a mesma é migrada para ele.
A metodologia de data marts incrementais possibilita a integração de diferentes fontes de
dados aos poucos, ou seja, os dados de cada base de dados de origem podem ser adicionados
em momentos diferentes. Esta característica deste tipo de metodologia facilitou a
implementação do DW com dados de bases de C&T, considerando a existência de diferentes
fontes de dados. Também torna possível a inclusão de novas fontes de dados no futuro.
Foi adotada a modelagem de dados relacional normalizada para a área de estágio definida
neste trabalho por permitir uma maior consistência dos dados e facilitar o processo de
integração entre bases de dados distintas, ao mesmo tempo que possibilita o uso de
relacionamentos não normalizados, o que facilita a integração com o DW. Já no DW foi
utilizada a modelagem multidimensional em conjunto com a modelagem de tabelas pontes
proposta por Kimball et al. (1998).
Após o DW ser construído com dados de C&T, foram realizados alguns alguns estudos de
caso objetivando a verificação e a validação do DW construído. Os resultados dos alguns
estudos de caso mostraram que o DW construído de acordo com a arquitetura proposta torna
bastante eficiente a busca por informações interessantes que possam dar suporte à tomada de
decisões.
Um DW é, geralmente, utilizado como uma ferramenta de extração de conhecimento, com o
objetivo de reduzir custos e otimizar a qualidade de seus produtos e serviços, conseguindo
assim mais e melhores resultados com menos recursos. No caso da área de C&T, o DW traz
como benefício um melhor conhecimento da realidade da pesquisa e dos pesquisadores
brasileiros, possibilitando melhor aproveitamento de investimentos nesta área.
No desenvolvimento do DW foram encontrados alguns problemas. Os principais problemas
foram relativos às bases de dados de origem. A base de dados do CNPq e da CAPES
utilizadas estavam um pouco defasadas. A base de dados do Coleta CAPES, não continha
dados de muitas instituições importantes como a própria UEM e havia alguns dados
inconsistentes. O dicionário de dados da base de dados do Coleta CAPES não possuía muitas
informações importantes, o que dificultou o estudo e entendimento desta base. Tudo isto
99
dificultou o processo de integração de dados. A utilização de dados defasados impossibilitou a
realização de determinadas consultas que poderiam resultar em conhecimentos relevantes, e
os resultados obtidos nas consultas realizadas não são totalmente confiáveis.
O principal motivo das bases de dados de origem estarem defasadas é a grande dificuldade de
se conseguir bases de dados do CNPq e CAPES. Existem muitas leis que restringem a
utilização dessas bases, tornando assim quase inviável a construção de um DW em C&T com
dados atualizados. Mas existem duas possibilidades para se conseguir trabalhar com bases
atualizadas, que seriam:
• A utilização de dados em XML. Muitos dados já estão sendo disponibilizados neste
formato através de webservers. Utilizando dados neste formato seria necessária a
inclusão de um módulo de conversão dos dados de XML para bases de dados.
• A utilização de dados das próprias universidades e centros. Desta maneira seria mais
fácil conseguir dados das próprias instituições onde está se construindo o DW, mas
diminuiria muito o escopo do DW.
Outro problema que foi detectado no decorrer do projeto é um problema particular no
desenvolvimento de DW para C&T. Como os dados em C&T não são atualizados através das
transações que ocorrem no dia a dia, e sim, a partir de inserções de dados pelos usuários, é
possível que muitos dados não sejam inseridos. Isto ocasiona um problema pelo fato de
resultados poderem ser mascarados. Por exemplo, em um certo ano muitos pesquisadores não
inserem suas publicações na base de dados e no ano seguinte a maioria cadastra as
publicações, quando for feita uma pesquisa, o resultado mostrará que este ano teve um grande
aumento nas publicações, o que não seria verdadeiro.
Pelo problema apresentado é necessária a definição de um método de análise de resultados
que verifique questões como esta, dando confiabilidade nos resultados conseguidos através do
DW construído.
Outras dificuldades encontradas estão relacionadas à definição do escopo do DW e à
definição dos dados a serem mantidos no DW utilizando a arquitetura BUS e a metodologia
de data marts incrementais.
Como trabalhos futuros podem ser sugeridos os seguintes tópicos:
100
• incorporação de outras fontes de dados, como o Diretório dos Grupos de Pesquisa do
Brasil e dados do IBGE, dando mais confiabilidade às consultas, ampliando o escopo
dos resultados e aumentando os recursos para suporte ao processo decisório;
• desenvolvimento de ferramentas OLAP para busca de conhecimentos no DW;
• especificação e implementação de um sistema especialista para gerenciamento do
metadados, com regras definidas para a extração e a análise dos dados;
• construção de interfaces gráficas para facilitar a análise de conhecimentos descobertos
por parte do usuário final.
101
REFERÊNCIAS BIBLIOGRÁFICAS
AGRAWAL, R.; GUPTA, A.; SARAWAGI, S. Modeling Multi-Dimensional Databases.
IBM Research Report , IBM Almaden Research Center, September 1995.
AGRAWAL, S; AGRAWAL, R.; DESHPANDE, P. M.; GUPTA, A.; NAUGHTON, J. E.; RAMAKRISHNAN, R.; SARAWAGI, S. On the computation of multidimensional aggregates. In Proc. Conf. on Very Large Databases (VLDB), p. 506-521, 1997. ADAMSON, C.; VENERABLE, M. Data Warehouse Design Solutions. John Wiley, 1998. ARRUDA, M. F. M. A indústria e o desenvolvimento tecnológico nacional. In: Ciência & Tecnologia: Alicerces do Desenvolvimento, São Paulo, ed. 1, p. 23-44, 1994. AXEL, M.; SONG, Y. Data Warehouse Design for Pharmaceutical Drug Discovery Research. Proc. of 8th International Conference and Workshop on Database and Expert Systems Applications (DEXA97), Toulouse, France, p. 644-650, September 1-5, 1997. BALLARD, C ; HERREMAN, D.; SCHAU, D.; BELL, R.; KIM, E.;VALENCIC, A. Data Modeling Techniques for Data Warehousing. IBM Corporation, 1998. BARQUINI, R. Planning and designing the Warehouse. Prentice-Hall, 1996. BATINI, C.; LENZERINI, M. Comparative Analysis Of Methodologies For Database Schema Integration, ACM Computing Surveys. New York, v.18, n. 4, p..323 - 364, Dez. 1986. BOMFIM, M. M. A Implementação e Utilização de Data Warehouse em Instituições Públicas no Brasil : Um estudo descritivo das implicações envolvidas. Programa de Pós-Graduação em Engenharia de Produção, Florianópolis – SC. Dissertação de Mestrado, UFSC, Florianópolis, 2001. BRACKETT, M. H. The Data Warehouse Challenge. Taming Data,Chaos. John Viley & Sons, 1996. BRISOLLA, S.N. Indicadores para apoio à tomada de decisão. Ciência da Informação, Brasília, v. 27, n. 2, p. 221-225, maio/ago. 1998. CAPES. Brasília. Disponível em <http://www.capes.gov.br>. Acesso em 18 julho 2003. CASTRO, C. M. A questão da qualidade. In: Simon Schwartzman e Cláudio Moura Castro(Orgs.) Pesquisa universitária em questão. São Paulo, 1986. CHAUDHURI, S. & DAYAL, U. An Overview of Data Warehousing and Olap Tecnology, SIGMOD Record, New York, v.26, n. 1, Mar. 1997.
102
CIFERRI, C. D. A. Distribuição dos Dados em Ambiente de Data Warehousing: O sistema WebD2W e Algoritmos Voltados à Fragmentação Horizontal dos Dados. Programa de Pós-Graduação em Ciência da Computação, Recife – PE. Tese de doutorado, Universidade Federal de Pernambuco, Recife, ago. 2002. CNPq. Plataforma Lattes. Disponível em <http://lattes.cnpq.br/>. Acesso em 15 julho 2003a. CNPq. Diretório dos Grupos de Pesquisa no Brasil. Disponível em <http://lattes.cnpq.br/diretorio/>. Acesso em 17 julho 2003b.
COMPUTER ASSOCIATES. ERwin Brochure. <http://www.cai.com/products/alm/erwin/erwin pd.pdf>. Acessado em: 18 março 2003. DATE, C. J. Introdução a Sistemas de Bancos de Dados. Campus, 1999. DAVID, M. Building and managing the meta data Repository: A Full Lifecycle Guide, Paperback, 2001. DB2 UDB. DB2 Universal Database Data Warehouse Enterprise Edition. <http://www-306.ibm.com/software/data/db2/udb/dwe/> Acessado em 05 junho 2003. DELPHI 7.0. Borland Delphi. <http://www.borland.com/delphi/>. Acessado em 03 fevereiro 2003. DEMAREST, M. The politics of data warehousing. Disponível em <http://www.dmreview.com/whitepaper/wid293.pdf> 1997. Acessado em: 08 novemvro 2003. DIAS, M.M.; MATTOS, M.M.; ROMÃO, W.; TODESCO, J.L.; PACHECO, R.C.S. Data Warehouse -Presente e Futuro. Revista Tecnológica, no.7, p. 59-73, 1998. DIAS, M.M. Um modelo de formalização do processo de desenvolvimento de sistemas de descoberta de conhecimento em banco de dados. Tese de Doutorado. Universidade Federal de Santa Catarina. Florianópolis, Santa Catarina, 2001. DINTER, B.; SAPIA, C.; HOFLING, G.; BLASCHKA, M. The OLAP Market: State of the Art and Research Issues. Proc. of Int’lWorkshop on Data Warehousing and OLAP, Washington, USA, p. 22-27, 1998. DUMOULIN, R. 2000. Architecting Data Warehouses for Flexibility,Maintainability, and Performance. Disponível em <http://www.olap.it/Articles.htm>. FAN, W.; LU, H.; CHEUNG, D.W. Discovering and Reconciling Data Value Conflicts for Numerical Data Integration. Information Systems, vl. 26, no. 8, p. 635-656, 2001. GERTZ, M.; SCHIMITT, I. Data Integration Techniques based on Data Quality Aspects. Proc. of 3rd Workshop “Föderierte Datenbanken” , Magdeburg, 10/11 p. 1-9, Aechen, Dez. 1998.
103
GERTZ, M.; SATTLER, K. Integrating Scientific Data through External, Concept-based Annotations. Second International Workshop on Data Integration over the Web, p. 87-101, Toronto, Canada, 2002. GONÇALVES, A. L. Utilização de Técnicas de Mineração de Dados na Análise dos Grupos de Pesquisa no Brasil. Florianópolis. Dissertação (Mestrado em Engenharia de Produção) – Programa de Pós-graduação em Engenharia de Produção, UFSC, 2000. GUIMARÃES, Reinaldo. A Pesquisa no Brasil. Parte I Organização.Ciência Hoje, v.19, no.109, maio,1995. HAN, J.; PEI, J.; DONG, G.; WANG, K. Efficient Computation of Iceberg Cubes with Complex Measures. Proceding of SIGMOD Conference, p. 1-12, Santa Barbara, CA, 2001. HARRISON, T. Intranet Data Warehouse. Berkeley, 1998. INDRIUNAS, L. Biopiratiaria – O Brasil se Defende. Revista Super Interessante, ed. 193, p. 24, out, 2003. INMON, W. H. Como Construir o Data Warehouse. Rio de Janeiro, 1997. INMON, W. H., HACKATHORN, RICHARD D. Como Usar o Data Warehouse. IBPI, 1997a. INMON, H., W. Metadata in the Data Warehouse. 2000. Disponível em <www.billinmon.com/library/whiteprs>. Acesso em 20 novembro 2003. JACOBSON, I. et al. Rational Unified Software Development Process. [S.I]: Addison-Wesley, 1999. JENSEN, M. R.; MØLLER, T. H.; PEDERSEN, T. B. Converting XML DTDs to UML Diagrams for Conceptual Data Integration. ACM Computing Surveys. New York. v. 4, n. 3, p. 323-346, 2003. KIMBALL, R. Data Warehouse Toolkit. Makron Books, 1996. KIMBALL, R.; REEVES L.; ROSS M.; THORNTHWAITE W.The Data Warehouse Lifecycle Toolkit: Expert Methods for Designing, Developing, and Deploying Data Warehouses. John Wiley & Sons Inc., 1998. KOSTOFF, R. N. Science and technology metrics. 1997. Disponível em: <http://www.onr.navy.mil/sci_tech/special/technowatch/>. Acessodo em: 22 set. 2002. KOTIDIS, Y.; ROUSSOPOULOS, N. DynaMat: A Dynamic View Management System for Data Warehouses. SIGMOD 1999, p. 371-382, Philadephia, USA, 1999. KRIEGER, E. M.; GALEMBECK, F. A capacitação brasileira para a pesquisa. In: Simon Schwartzman. Ciência e tecnologia no Brasil: a capacitação para a pesquisa científica e tecnológica, Rio de Janeiro: Editora Fundação Getulio Vargas, p. v.3, p. 1-18, 1996.
104
KRIPPENDORF, M.; SONG, Y. Translation of Star Schema into Entity-Relationship Diagrams. Proc. of 8th International Conference and Workshop on Database and Expert Systems Applications (DEXA97 ), p. 390-395, França,. Setembro, 1997. LEHNER, W.; ALBRECHT, J.; WEDEKIND, H. Normal Forms for Multidimensional Databases.Proc. SSDBM, p. 63-72, 1998,. LEI pode facilitar pesquisa em empresas. Jornal Folha de São Paulo, São Paulo, ano 84, n. 27.396, p. A9, abril 2004. MACHADO, F. N. R.. Projeto de Data Warehouse – Uma visão Multidimensional. Érica, 2000. MACIAS-CHAPULA, C. O papel da informetria e da cienciometria e sua perspectiva nacional e internacional. Ciência da Informação, Brasília, v.27, n.2, p. 134-140, maio/ago. 1998. MCT. Sociedade da Informação no Brasil – Livro Verde. Brasília, DF, Set. 2000. MENDES, A. F. Arquitetura de Software, Editora Campus, 2002. MEYERE, D.; CANNON, C. Building a Better Data Warehouse. Prentice-Hall, 1998. MILLET, I.; PARENTE, D. H; FIZEL, J, L. Data Warehouse Design for Ease of Data Transformation. DMDW, Toronto, Canada, p. 82-89, 2002. MOODY, D.; KORTINK, M.A.R.. From Enterprise Models to Dimensional Models: A Methodology for Data Warehouse and Data Mart design, Proc. of Int’l Workshop on Design and Management of Data Warehouses(DMDW2000), Suécia, 2000. NIEDERAUER, C. A. P. ETHOS: Um Modelo Para Medir A Produtividade Relativa De Pesquisadores Baseado Na Análise Por Envoltória De Dados. Programa de Pós-Graduação em Engenharia de Produção, Florianópolis – SC. Tese de doutorado, UFSC, Florianópolis, 2002. ORACLE9I. Oracle9i Database < http://otn.oracle.com/software/products/oracle9i/> Acessado em: 02 dezembro 2002. OWB. Oracle Warehouse Builder. <http://otn.oracle.com/products/warehouse/index.html> Acessado em: 03 junho 2003. PEDERSEN, T. B.; JENSEN, C.S. Multidimensional Data Modeling for Complex Data. Proc. of 15th ICDE, p. 336-345, Sidney, Australia, 1999. PEREIRA, W. A. L.; BECKER, K. Inserting Data Warehouse In Corporations: A Methodological Approach. In: 3th International Conference on Information Systems, Setúbal, Portugal, 2001. RIBEIRO, C. Bancos de Dados Heterogêneos - Mapeamento dos Esquemas Conceituais em um modelo Orientado a Objetos. 1995. Tese (Doutorado) – Universidade Federal do Rio Grande do Sul, UFRGS, Porto Alegre, 1995.
105
ROMÃO, W. Descoberta de conhecimento interessante em banco de dados sobre ciência e tecnologia. Programa de Pós-Graduação em Engenharia de Produção, Florianópolis – SC. Tese de doutorado, UFSC, Florianópolis, 2002. ROMÃO, W.; PACHECO, R. C. S.; NIEDERAUER, C. A. P. Planejamento Em C&T: Uma Abordagem Para Descoberta De Conhecimento Relevante Em Banco De Dados De Grupos De Pesquisa. Revista Tecnológica, no 9, p. 139-152, Outubro 2000. ROSS, K. A.; SRIVASTAVA, D. Fast computation of sparse datacubes. In Proc. Conf. on Very Large Data-bases (VLDB), 1997. SAMOS J.; SALTOR F.; SISTRAC J.; BARDÉS A. Database Architecture for Data Warehousing: An evolutionary Approach, DEXA, Vienna, 1998. SCHWARTZMAN, Simon; KRIEGER, Eduardo; GALEMBECK, Fernando; GUIMARÃES, Eduardo A.; BERTERO, Carlos Osmar. Ciência e tecnologia no Brasil: Uma nova política para um mundo global. In: Ciência e tecnologia no Brasil: Política Industrial, Mercado de Trabalho e Instituições de Apoio, Rio de Janeiro: Editora da Fundação Getúlio Vargas, 1995, 384p, v.2, p.1-59. SELL, D. Uma Arquitetura para Distribuição de Componentes Tecnológicos de Sistemas de Informações Baseadas em Data Warehouse. Programa de Pós-Graduação em Engenharia de Produção, Florianópolis – SC. Dissertação de Mestrado, UFSC, Florianópolis, 2001. SHILAKES, C.; TYLMAN, J. Enterprise Information Portals. Enterprise Software Team. November 1998. Disponível em <http://www.sagemaker.com/company/downloa s/eip/indepth.pdf.>. Acessado em: 05 maio 2003.
SINGH, H. S. Data Warehouse: Conceitos, Tecnologias, Implementação e Gerenciamento. Makron Books, 2001. SMITH, J. R.; LI, C.; CASTELLI, V.; JHINGRAN, A. Dynamic Assembly of Views in Data Cubes. Proc. of the Seventeenth ACM SIGACT-SIGMOD-SIGART Symposium on Principles of Database Systems publisher, p. 274-283, Seattle, Washington, June 1-3, 1998. SONG, Y.; ROWEN, W.; MEDSKER, C.; EWEN, E. An Analysis of Many-to-Many Relatioships Between Fact and Dimension Tabels in Dimensional Modeling. Proc. of Int’lWorkshop on Design and Management of Data Warehouse(DMDW 2001),Interlaken, Suiça, 2001. SPINAK, E. Indicadores cientométricos. Ciência da informação, v. 27, n. 2, p. 141-148, maio/ago. 1998. SQL Server. Microsoft Sql Server 2000. <http://www.microsoft.com/sql/default.asp.> Acessado em: 05 junho 2003. TANNENBAUM, A. Metadata Solutions: Using Metamodels, Repositories, X ML, and Enterprise Portals to Generate Information on Demand. Addison Wesley, New York, USA, 2002.
106
THEODORATOS, D.; SELLIS, T. Data Warehouse Schema and Instance Design. Proc. of 17th International Conf. On Conceptual Modeling (ER98), p.363-376, Singapore, Novembro, 1998. TOMBROS, D.; HÄBERLI, C. A Data Warehouse Architecture for MeteoSwiss: An Experience Report. Proceedings of the International Workshop on Design and Management of Data Warehouses (DMDW'2001), Switzerland, June 4, 2001. TRZESNIAK, P. Indicadores quantitativos: reflexões que antecedem seu estabelecimento. Ciência da Informação, v. 27, n. 2, p. 159-164, maio/ago. 1998. WIDOM, J. Research Problems in Data Warehousing. Proc. of the Int’l. Conf. on Information and Knowlege Management. Baltimore, 1995. VASSILIADIS, P. Guliver in the lan of data warehousing: pratical experiences and observations of a researcher. DMDW, Stocolmo, Suécia, Junho 5-6, 2000.
107
APÊNDICE A – PROCEDIMENTOS DA CAMADA ETL
108
APÊNDICE B – MODELOS DE DADOS
