You are on page 1of 113

Universidade

Católica de
Brasília
PRÓ-REITORIA DE GRADUAÇÃO
TRABALHO DE CONCLUSÃO DE
CURSO

Bacharelado em Ciência
da Computação
SIGED – Sistema de Gestão Educacional – Data Warehouse
Alunos:
André Leonardo Pires Gonçalves
Sylvia Sayuri Shibata

Orientador: MSc. Milton Pombo da Paz

BRASÍLIA 2008
ANDRÉ L.P. GONÇALVES
SYLVIA SAYURI SHIBATA

SISTEMA DE GESTÃO EDUCACIONAL – SIGED


DATA WAREHOUSE

Monografia apresentada para


obtenção do título de bacharel no
Curso de Ciência da Computação
pela Universidade Católica de
Brasília, sob a orientação do
professor Milton Pombo.

Brasília – DF
2008

i
Projeto Final de Graduação, sob a
Orientação do Msc. Milton Pombo da Paz,
avaliado por uma Banca Examinadora do
Curso de BCC da UCB e constituiu
requisito para obtenção do Título de
Bacharel em Ciências da Computação.

ii
AGRADECIMENTOS

Agradeço aos meus pais e minhas irmãs por sempre me apoiaram e


incentivarem os meus estudos e trabalho.

Agradeço ao André Leonardo, parceiro de projeto final pela paciência,


bom humor e força de vontade para conclusão do projeto.

Agradeço também ao professor Milton P. Paz pela atenção dada ao


nosso grupo e pelo incentivo e aos nossos demais colegas de projeto final.

Sou grata também as pessoas que me ajudaram na minha conquista


profissional, em especial o coordenador da equipe ao qual faço parte, Nobuo
que me transmitiu sua constante preocupação com qualidade e praticidade,
ensinando-me diversos caminhos para alcançá-la e Jean-Frédéric pela
confiança e oportunidade de aprendizado logo no início da minha vida
profissional.

Por fim, agradeço a Deus por tudo de bom e maravilhoso que Ele me
deu e, sem dúvida nenhuma, o maior presente que é a vida.

Sylvia Sayuri Shibata

iii
Primeiramente agradeço a Deus pela vida, por tudo que possuo e o que
sou.

Agradeço aos meus Pais e minha Irmã Vanessa pelo apoio intensivo e
amor que sempre me deram em todos os momentos da minha vida, e que de
certa forma fizeram o possível para que este momento se realizasse.

Agradeço a minha namorada Helaine Castro por ser forte e também por
sua paciência, compreensão e suporte oferecido principalmente nos momentos
mais difíceis que passo.

Agradeço ao Professor Milton Paz pela orientação e incentivo que nos


deu ao longo do semestre.

Agradeço a Sylvia Shibata, pela paciência e apoio durante o


desenvolvimento deste projeto final.

Agradeço a todos os que me apoiaram sempre, e neste momento


gostaria de citar de modo especial o senhor Alberto Mizuki pela oportunidade
ímpar que me proporcionou no início da minha carreira profissional, ao
professor Mário Braga pela chance e confiança depositada em mim.

Finalmente agradeço a todos os colegas de trabalho, de faculdade,


amigos, familiares e professores que de alguma maneira contribuíram com este
momento.

André Leonardo Pires Gonçalves

iv
Resumo

A tecnologia Data Warehouse (DW) tem sido cada vez mais difundida
nas corporações principalmente pelo diferencial que estes sistemas
representam como ferramenta para análise de informações gerenciais e
estratégicas. Neste cenário, o DW auxilia a alta cúpula da empresa na medida
em que capta informações a partir das bases de dados transacionais e as
armazena em repositórios construídos com o propósito exclusivo de análise. A
visão do dia-a-dia, as micro-operações, os registros de transação, enfim, os
dados dos sistemas transacionais tradicionais, são transformados em
informações no contexto do Data Warehouse por meio de visões que oferecem
a seus usuários informações globais que possibilitam que os tomadores de
decisão tenham uma visão ampla sobre o seu negócio. Com base nisto,
percebe-se uma crescente demanda por profissionais críticos que sejam
capazes de atender a este mercado. Por isso, entender e conhecer os
conceitos sobre esta tecnologia tem feito diferença para alguns profissionais do
ramo da Tecnologia da Informação. O objetivo do presente trabalho é elucidar
os principais conceitos sobre a Tecnologia Data Warehouse e ao fim
apresentar um protótipo para aplicação dos conceitos apresentados.

Palavras chave: Data Warehouse, Sistema de Apoio a decisão, Data Mart.

v
Abstract

The Data Warehouse technology has been used and widespread inside
corporations mainly because its differential as an information analysis tool. On
that way, this technology aids the decision makers of one company to view
information from specific databases constructed with the data from multiples
transactional sources. These repositories have the specific goal of analysis. The
daily view, the micro operations, the transaction rows and finally the traditional
data from transactional systems are transformed in information in Data
Warehouse context using views that offer global information and insights to its
users in the way that offer to that professionals a broad view of their business.
Based on that facts, the demand for critic professionals is rising, and the ability
to understand and know the concepts about this technology make the difference
for some Information Technology professionals and companies. The main goal
of this work is elucidate the main concepts about the Data Warehouse
Technology and at the end present one prototype for application of the main
concepts presented in this work.

Keywords – Data Warehouse, Decision Support System, Data Mart.

vi
Lista de figuras
Figura 1 – Organograma do Centro Educacional Tangran. ................................ 6

Figura 2 – Evolução dos Sistemas de Apoio à Decisão [INMON, 2005] .......... 20

Figura 1 – Cronograma no MS Project. ............................................................ 34

Figura 4 – Exemplo de Modelo Relacional [DSPACE,2008] ............................ 36

Figura 5 – Exemplo de Esquema de Modelo Multidimensional [DEVMEDIA,


2008] ................................................................................................................ 36

Figura 6 – Exemplo de Modelo Multidimensional.[MICROSOFT, 2008] ........... 37

Figura 7 – Exemplo de Estrutura Multidimensional [DEVMEDIA, 2008] ........... 39

Figura 8 – Abordagem de implementação Top-Down [MACHADO, 2007] ....... 47

Figura 9 – Abordagem de implementação Botton-Up [MACHADO, 2007] ....... 49

Figura 10 – Tabela de ferramentas segundo [OLIVEIRA, 2002] ...................... 56

Figura 11 – O Ciclo de Vida do desenvolvimento de sistemas [INMON, 2005] 64

Figura 12– Modelo mostrando o modelo dimensional macro baseado em


informações coletadas. .................................................................................... 75

Figura 13 – Modelo de dados dimensional utilizado para no Data Mart Escolar.


......................................................................................................................... 76

Figura 14 – Modelo Físico do Sistema OLTP com as principais tabelas a serem


utilizadas no DW.. ............................................................................................ 80

vii
Lista de tabelas
Tabela 1 – Cronograma geral do projeto...................................................... 29

Tabela 2 – Documentos do projeto .............................................................. 30

Tabela 3 – Quadro de funcionários necessários para desenvolvimento de um


DW. .......................................................................................................... 30

Tabela 4 - Recursos Financeiros ................................................................. 33

Tabela 1 – Quadro de funcionários sugeridos para desenvolvimento inicial de


um DW [INMON, 1999] ............................................................................... 69

Tabela 2 – Quadro de Funcionários de SI sugerido para Gerenciamento


Contínuo de DW[INMON 1999] ................................................................... 71

viii
SUMÁRIO
AGRADECIMENTOS ........................................................................................ iii

Resumo .............................................................................................................. v

Abstract ............................................................................................................. vi

Lista de figuras ................................................................................................. vii

Lista de tabelas ................................................................................................viii

SUMÁRIO.......................................................................................................... ix

1. Introdução ................................................................................................... 1

1.1 Motivação ............................................................................................. 4

1.2 Histórico ............................................................................................... 4

1.3 Problemas Diagnosticados .................................................................. 5

1.4 Surgimento das Necessidades da Pesquisa ........................................ 5

1.5 Usuários Beneficiados ......................................................................... 5

1.6 Organograma ....................................................................................... 5

1.7 Empresa Interessada ........................................................................... 7

2. Objetivos da Pesquisa................................................................................. 8

2.1 Objetivo Geral ...................................................................................... 8

2.2 Objetivo Específico .............................................................................. 9

3. Proposta de Pesquisa ............................................................................... 10

3.1 Descrição da Proposta de Pesquisa .................................................. 10

3.2 Resultados Esperados ....................................................................... 10

3.3 Restrições da Pesquisa ..................................................................... 11

3.4 Recursos necessários para a execução do novo Software................ 11

3.4.1 Descrição de Recursos de Hardware Ideal .................................... 12

3.4.2 Descrição de Recursos de Hardware Mínimo ................................ 12

3.4.3 Descrição de Recursos de Software .............................................. 13

3.4.4 Descrição de Recursos Humanos .................................................. 13

ix
3.5 Relação Custo x Benefício ................................................................. 14

3.6 Áreas afetadas pela pesquisa ............................................................ 14

4. Metodologia da pesquisa .......................................................................... 14

5. Detalhamento da pesquisa – Estudo Teórico............................................ 15

5.1. Introdução .......................................................................................... 15

5.1.1. Conceito ......................................................................................... 16

5.1.2. Objetivo .......................................................................................... 17

5.1.3. Evolução dos Sistemas de Suporte à Decisão ............................... 18

5.1.4. Público Alvo .................................................................................... 21

5.1.5. Características................................................................................ 21

5.1.6. Papéis ............................................................................................ 24

5.2. PLANEJAMENTO DO PROJETO ...................................................... 25

5.2.1. Planejamento ................................................................................. 25

5.2.2. Plano do Processo de Desenvolvimento ........................................ 26

5.2.3. Ciclo de vida do projeto .................................................................. 26

5.2.4. Métodos de Desenvolvimento e ferramentas CASE....................... 27

5.2.5. Ambiente de hardware para o desenvolvimento............................. 27

5.3. Plano de Organização........................................................................ 27

5.3.1. Equipe de Gerência ........................................................................ 27

5.3.2. Equipe de Desenvolvimento ........................................................... 28

5.4. Plano de Acompanhamento ............................................................... 28

5.4.1. Marcos e Pontos de Controle ......................................................... 28

5.4.2. Métodos de acompanhamento e controle ...................................... 29

5.4.3. Análise e Gerência de Riscos ........................................................ 30

5.5. Plano de Documentação .................................................................... 30

5.5.1. Documentos do projeto .................................................................. 30

5.6. Plano de Recursos e Produtos .......................................................... 30

x
5.6.1. Recursos Humanos ........................................................................ 30

5.6.2. Recursos de Hardware ................................................................... 32

5.6.3. Recursos de Software .................................................................... 32

5.6.4. Recursos Financeiros ..................................................................... 33

5.7. Cronograma ....................................................................................... 34

5.8. Modelagem de Dados ........................................................................ 34

5.8.1. Modelagem Multidimensional ......................................................... 37

5.8.2. Modelo Star Schema (Modelo Estrela) ........................................... 40

5.8.3. Modelo Snowflake (Floco de Neve) ................................................ 42

5.9. Arquitetura ......................................................................................... 42

5.9.1. Conceito ......................................................................................... 43

5.9.2. Arquitetura Global........................................................................... 44

5.9.3. Arquitetura Data Mart Independente .............................................. 45

5.9.4. Arquitetura Data Mart Integrado ..................................................... 46

5.10. Abordagem de Implementação ...................................................... 47

5.10.1. Top-Down ................................................................................... 47

5.10.2. Botton-Up .................................................................................... 48

5.11. Extração, Transformação e Carga.................................................. 50

5.11.1. Melhores Práticas ....................................................................... 51

5.11.2. Extração ...................................................................................... 52

5.11.3. Transformação ............................................................................ 53

5.11.4. Carga .......................................................................................... 54

5.11.5. Ferramentas................................................................................ 55

5.12. OLAP .............................................................................................. 56

5.12.1. Características das ferramentas OLAP ....................................... 57

5.12.2. Operações Básicas OLAP .......................................................... 58

5.13. Metadados ...................................................................................... 60

xi
5.13.1. O Data Warehouse e o modelo de dados ................................... 61

5.13.2. Padrões para Metadados ............................................................ 61

5.13.3. Dublin Core ................................................................................. 62

5.13.4. TEI .............................................................................................. 63

5.13.5. METS .......................................................................................... 63

5.13.6. EAD ............................................................................................ 63

5.13.7. RDF ............................................................................................ 63

5.14. Ciclo de Vida de Desenvolvimento ................................................. 64

5.14.1. Fases para um projeto Data Warehouse .................................... 65

5.14.1.1. Levantamento das Necessidades ............................................... 65

5.14.1.2. Modelagem ................................................................................. 66

5.14.1.3. Projeto Físico .............................................................................. 66

5.14.1.4. Projeto ETL ................................................................................. 66

5.14.1.5. Desenvolvimento das Aplicações ............................................... 67

5.14.1.6. Validação e Teste ....................................................................... 67

5.14.1.7. Treinamento ................................................................................ 67

5.14.1.8. Implantação ................................................................................ 67

5.14.2. Problemas Comuns de Desenvolvimento ................................... 67

5.14.3. Recursos Humanos .................................................................... 69

6. Protótipo – Validação da Pesquisa ........................................................... 73

6.1. Planejamento ..................................................................................... 73

6.2. Levantamento de Necessidades ........................................................ 74

6.3. Modelagem Dimensional.................................................................... 75

6.4. Projeto físico do banco de dados ....................................................... 76

6.5. Projeto de extração, transformação e carga ...................................... 79

6.6. Desenvolvimento de aplicações ......................................................... 84

7. Conclusão ................................................................................................. 85

xii
Referência Bibliográfica ................................................................................... 86

Apêndice A ....................................................................................................... 88

Apêndice B ....................................................................................................... 92

SCRIPT DE GERAÇÃO DO BANCO DE DADOS ........................................ 92

Apêndice C ....................................................................................................... 96

TELAS DO PROTÓTIPO .............................................................................. 96

xiii
1. Introdução

Segundo Inmon (1997) no começo dos anos sessenta o mundo da


computação consistia basicamente na construção de aplicações individuais que
resolviam problemas bastante específicos. Daquela época para cá o cenário
mudou bastante. Desde a difusão dos computadores pessoais, dos primeiros
sistemas operacionais até o advento da Internet, o mundo tem passado por
diversas transformações. O conhecimento é um fator chave para estas
mudanças e constitui a base para a evolução das sociedades.

É notável que o conhecimento sempre influenciou o avanço da


humanidade utilizando para isso a tecnologia. Quem detém o conhecimento e
tecnologia possui o domínio. Isto é fato que pode ser facilmente observado, por
exemplo, quando se visualiza o atual ranking de países desenvolvidos. Quem
alia o conhecimento à tecnologia tende a estar na frente. Entretanto para que
seja possível adquirir o conhecimento, é necessário ter informação. As
informações ajudam a moldar o conhecimento e muitas vezes são
determinantes para que se saiba construir um equipamento complexo ou até
mesmo para que se consiga tomar uma decisão da forma mais assertiva
possível.

O conhecimento têm se acumulado ao longo da história e a quantidade


de informação recebida por um cidadão atual é espantosamente grande
quando comparada ao passado. Machado (2006) cita que “Em uma única
edição do jornal The New York Times existe mais informação do que uma
pessoa poderia receber durante toda sua existência na Inglaterra do século
XVII”. Isso se deve principalmente pela difusão dos meios de comunicação
que surgiram no século XX. A difusão da energia elétrica, do rádio, do telefone,
da televisão e por último da Internet possibilitaram que uma grande quantidade
de pessoas tivessem acesso à informação.

Neste sentido, é fato que a evolução está intimamente ligada a questão


da competição. Trazendo o contexto exposto para dentro do mundo
corporativo, a necessidade de obter informações qualificadas referentes às
operações de uma empresa faz com que a utilização de sistemas
computacionais seja cada vez mais difundida no mundo corporativo. O uso
intensivo destes sistemas vem facilitando a execução de processos dentro das

1
corporações e auxiliando profissionais a executarem suas tarefas cotidianas. A
informação é a base para um negócio bem sucedido.

O foco do produto de software também tem evoluído. Além do seu papel


básico de resolver problemas do dia-a-dia por meio de sistemas transacionais,
ele tem sido utilizado para transformação de dados em informações dentro das
corporações por meio de tecnologias de apoio a decisão. A necessidade por
informações empresariais sempre existiu, no entanto a evolução da Tecnologia
da Informação (TI) tem possibilitado a criação de meios eficientes para a
transformação de dados em informações.

Neste cenário o surgimento de sistemas de apoio à decisão (SAD) tem


auxiliado empresas e pessoas a colherem informações a partir deste tipo de
sistemas, de forma a auxiliá-los na tomada de decisões estratégicas. Visto que
a necessidade de informações para a tomada de decisões foi aumentando e o
que haviam eram apenas dados estruturados sendo armazenados
historicamente.

Além disso, existe o problema de consultas em base de dados


estruturados consumir muito tempo devido aos relacionamentos existentes
entre as tabelas, inviabilizando o uso deste tipo de estrutura, o que exigiu a
criação de uma nova tecnologia para tratar os dados de forma que gerassem
consultas a informações, surgindo o Data Warehouse para prover as
informações de maneira rápida e simples.

Os ambientes transacionais tradicionais ou ambientes OLTP (Online


Transaction Processing) têm cumprido seu papel dentro das empresas. No
entanto percebeu-se que este tipo de sistema apresenta algumas deficiências
quando utilizados como ferramenta para auxilio na tomada de decisões
estratégicas de alto nível.

O grande problema nessa situação, é que os ambientes transacionais


não foram projetados para suportar análise de informação de forma maciça.
Quando um gestor questiona dados de sua empresa, ele geralmente deseja
saber informações de maneira macro e abrangente, como por exemplo,
questionar qual a margem de lucro de um produto nos últimos cinco anos.

Pode até existir sistema OLTP que consigam responder a este tipo de
pergunta, mas pelo alto volume de transações dentro do ambiente operacional

2
(e por outros fatores) estas informações podem estar guardadas em diversos
meios que impossibilitem uma pesquisa imediata ou em um tempo aceitável.
Além de outras desvantagens relacionadas, esta consulta poderia requerer
uma grande quantidade de processamento nos sistemas transacionais, que
talvez fosse proibitivo de ser executada em uma determinada ocasião
justamente por causa da brusca queda de desempenho neste sistema.

As tecnologias de análise de informações, ou tecnologias OLAP (Online


Analytical Processing) trazem solução para esta questão e oferecem um
ambiente projetado para análise de informações. Sintetizando suas diferenças
essenciais, a mais marcante, é que os sistemas OLAP permitem e são
projetados para a extração (consulta) de informações de forma maciça e
satisfatória em relação aos ambientes OLTP. Na maioria das vezes o OLTP
manipula uma grande massa de pequenas operações, enquanto o ambiente
OLAP, uma pequena quantidade de grandes operações.

Estes ambientes de análise surgem para auxiliar gestores e alta


gerência das companhias a tomarem decisões baseadas nos fatos
armazenados em seus sistemas transacionais. Muitas vezes estas decisões
são tomadas com base em informações temporais. A visualização de
informações de meses, anos e décadas são bem freqüentes e o volume de
dados armazenados neste tipo de ambiente é altíssimo, pois devem armazenar
informação durante os períodos citados.

Dentro do mundo de apoio a decisão existe a categoria de sistemas


Data Warehouse (DW). De forma muito geral, estes sistemas funcionam de
forma que, a partir das necessidades da alta gerência, extrai-se e tratam-se os
dados dos ambientes transacionais tradicionais por meio de processos
especiais, e após esta etapa, os dados são carregados em ambientes
especializados de análise. Em seguida ficam disponíveis em um repositório
dedicado para servir de base para consultas a informações gerencias de uma
determinada corporação. Geralmente estas informações servem de base
histórica e ficam armazenados nestes repositórios por anos.

Em mais detalhes, esta pesquisa tem o objetivo de descrever


detalhadamente a estrutura de um Data Warehouse, e mostrar suas principais
características e também como este tipo de solução auxilia a alta gerência no
processo de tomada de decisão.

3
1.1 Motivação

A necessidade de obter informações qualificadas referentes às


operações de uma empresa faz com que o uso de sistemas Data Warehouse
seja cada vez mais difundido no mercado corporativo.

Além de outras vantagens, o uso intensivo destes sistemas vem


melhorando cada vez mais a capacidade do ajuste interno dos processos das
empresas, na medida em que proporcionam uma visão macro das operações
executadas e auxilia os gestores a tomarem decisões baseadas nas
informações adquiridas dentro de seus próprios sistemas produtivos.

O produto final de um trabalho de implementação de Data Warehouse


pode oferecer também, uma visão posicional do referido negócio em relação ao
mercado externo, servindo como uma ferramenta para o estudo da melhor
estratégia a ser aplicada em um segmento visando à melhora da capacidade
de competição da empresa.

Segundo Silberschatz e Sudarshan (1999), um Data Warehouse é um


repositório de informações coletadas em diversas fontes – tais como Sistema
de Recursos Humanos, Contabilidade, Logística - que são armazenadas sob
um repositório único, que tem uma interface única e consolidada de dados e
que são armazenadas durante longo período de tempo. Isso significa que, ao
centralizar as informações, estes sistemas oferecem facilidade de acesso às
informações (que antes eram mineradas por meio de relatórios esparsos de
cada área de negócio) além de oferecer uma análise histórica destas
informações.

Nesse sentido, este trabalho de pesquisa tem como propósito propor


uma solução baseada em tecnologia Data Warehouse.

1.2 Histórico

Desde a fundação do Centro Educacional Tangran não se tinha a


preocupação de automatização e informatização dos dados da escola. Todos
os processos eram manuais até a pouco tempo, e com o aumento do quadro
de funcionários e alunos, iniciou a preocupação de armazenamento de dados
sobre a situação acadêmica dos alunos, visto que as informações eram
guardadas em armários de arquivos físicos.

4
Desta forma, com a quantidade de informações sendo armazenados, por
vezes, tornava-se difícil o acesso a estas informações. Neste sentido foram
adquiridos sistemas para controle acadêmico, totalizando-se três sistemas de
“prateleira”. Cada um com modelos de dados próprio, banco de dados próprio e
código-fonte inacessível.

1.3 Problemas Diagnosticados

Devido ao armazenamento de documentos físicos referentes aos alunos


e funcionários, estava gerando demora na pesquisa de determinados arquivos
e também ao grande risco da perda destes em caso de um acidente. Neste
sentido, também não existia nenhum sistema de apoio a decisões, que seria
muito importante para a análise estratégica dos dados.

Desta forma, não existem meios de extração de dados para a geração


de informações históricas da entidade para futura expansão e análise da
questão financeira dos alunos de forma a prover algum tipo de atrativo para
novos alunos ou criação de política de descontos a fim de manter os alunos já
matriculados.

1.4 Surgimento das Necessidades da Pesquisa

Assim como nos demais setores tais como telecomunicações, indústria e


logística, a área educacional tem a sua própria necessidade de buscar
informações gerenciais dentro de suas bases de dados transacionais para que
se consiga responder a perguntas essenciais para a estratégia do negócio.

Com base no cenário apresentado, o presente trabalho de pesquisa tem


como intuito responder a questões estratégicas referentes a um ambiente
escolar específico por meio da construção de um sistema computacional de
Data Warehouse.

1.5 Usuários Beneficiados

Após a construção do sistema de Data Warehouse, os usuários


beneficiados serão: Presidente, Diretores e Supervisores das instituições e
Coordenadores Educacionais.

1.6 Organograma

A seguir, será apresentado o organograma do Centro Educacional


Tangran, no qual está sendo baseada a pesquisa presente.

5
A escola é composta por uma alta Diretoria Executiva, onde, estão
ligados a ele, as diretorias Administrativa, Financeira e Educacional. A
coordenação Pedagógica está diretamente ligado à diretoria educacional, de
onde vêm as informações para a análise da Diretoria Educacional e
consequentemente, dados de tomada de decisão para a diretoria executiva.

Figura 1 – Organograma do Centro Educacional Tangran.

6
1.7 Empresa Interessada

O projeto se destina ao cenário atual do Centro Educacional Tangran,


instituição de ensino infantil, localizada em Brasília. Hoje a instituição possui
aproximadamente 100 alunos e deseja ampliar a sua estrutura para a
educação fundamental.

O principal objetivo do Centro.Educacional Tangran é promover uma


educação de qualidade, buscando sempre a transparência com os pais e
responsáveis, porém a instituição enfrenta barreiras por não contar com um
sistema para extrair relatórios estratégicos. Atualmente, toda a documentação
é preenchida manualmente o que gera uma baixa produtividade e falta de
informações confiáveis para as tomadas de decisões.

7
2. Objetivos da Pesquisa

O objetivo é desenvolver uma pesquisa sobre Data Warehouse e validá-


lo em um estudo de caso para uma escola com o desenvolvimento de um DW
para provimento de relatórios gerenciais para tomada de decisão pela alta
gerência. O qual possibilita a consulta de várias informações do processo de
negócio da área acadêmica.

2.1 Objetivo Geral

O presente trabalho tem como objetivo desenvolver uma pesquisa


bibliográfica sobre sistemas computacionais de Suporte à Decisão Data
Warehouse (SSD/DW) a fim de fornecer à escola citada, uma ferramenta de
análise gerencial de informações.

8
2.2 Objetivo Específico

Desenvolver um protótipo em computador para atender os principais


processos da Instituição de Ensino utilizando SOA para a modelagem destes
processos e construção de um sistema transacional. Com base nos dados
gerados neste sistema, e só após sua conclusão, será utilizado um sistema de
Data Warehouse para responder questões específicas do negócio.

Os objetivos específicos identificados para se atingir o objetivo geral são


os seguintes:

 Levantar, junto aos interessados pelo sistema, o conjunto de consultas


gerenciais que se deseja obter a partir do Data Warehouse;

 Mapear os Dados que serão transformados em Informações do


ambiente OLTP (Online Transaction Processing) para o ambiente
OLAP (On-Line Analytical Processing), em conformidade com o que foi
levantado com os interessados pelo sistema;

 Extrair dados específicos do ambiente transacional OLTP para a


criação de um ambiente de análise OLAP utilizando técnicas de ETL
(Extract Transform and Load); e

 Com base nas informações armazenadas neste último repositório, criar


consultas gerenciais a partir das questões analíticas levantadas pelos
analistas de sistema aos interessados pela construção do sistema para
apoio a tomada de decisão na empresa e, após isso, disponibilizar
estas consultas aos usuários.

9
3. Proposta de Pesquisa
Desenvolver uma pesquisa bibliográfica sobre Data Warehouse em
busca de informações importantes de maneira que auxilie na tomada de
decisões oferecendo diversidade de cenários de acordo com o histórico da
escola.

3.1 Descrição da Proposta de Pesquisa

Elucidar de forma descritiva os principais conceitos relacionados à


tecnologia Data Warehouse, o importante papel histórico e evolução das
tecnologias de Suporte a Decisão, as principais características ligadas à
arquitetura, à forma de implementação, questões de modelagem, entre outros
conceitos relacionados à tecnologia citada. Feito isso, desenvolver um protótipo
para comprovar a viabilidade da aplicação dos conceitos aqui referidos.

3.2 Resultados Esperados

Com a conclusão da pesquisa planeja-se implementar um protótipo para


aplicação dos conceitos e demonstração de viabilidade da construção de um
sistema Data Warehouse engajado nas necessidades da instituição de ensino
citada conforme os conceitos elucidados nesta pesquisa.

10
3.3 Restrições da Pesquisa

Para realização desta pesquisa é imprescindível:

 Ciência de que o foco deste trabalho de pesquisa é a construção de


um protótipo focado nas questões gerenciais dos usuários do
sistema, e não um sistema DSS robusto;

 Obter junto aos usuários do futuro sistema, o escopo do protótipo a


ser desenvolvido;

 A existência de uma base de dados transacional (OLTP) para


mapeamento das necessidades dos usuários;

3.4 Recursos necessários para a execução do novo Software

O servidor de banco de dados para armazenamento dos dados relativos


à escola será o Oracle Database 9.2.0.1.

O software que servirá como ferramenta de ETL (Extração,


Transformação e Carga) será o OWB (Oracle Warehouse Builder) na versão
10.1.0.4.

Já a aplicação onde os usuários finais poderão criar consultas e acessar


as já existentes é o Oracle Discoverer 10.1.2.1.

No lado servidor para instalação do banco de dados e do OWB, o


hardware ideal para suporte ao software e ao problema da escola específico
seria uma máquina com processador de velocidade 2 GHz e 2 GB de memória
RAM.

O hardware mínino para instalação do banco de dados e OWB seria


uma máquina com processador de velocidade de 1.7 GHz e 1 GB de memória
RAM.

Na máquina cliente para instalação do Oracle Discoverer, para a


consulta e criação de relatórios, o hardware ideal sugerido é um processador
de velocidade 1 GHz, com 1 GB de memória RAM.

O hardware mínimo sugerido para a máquina cliente, para execução das


consultas aos relatórios é um desktop com um processador de velocidade 700
MHz, com 512 MB de memória RAM.

11
Em relação aos recursos humanos, serão necessários 2 analistas de
sistemas, 1 DBA (Database Administrator), 2 consultores ETL, 2 consultores
OLAP para este desenvolvimento.

Abaixo segue a descrição detalhada de recursos a ser utilizada.

3.4.1 Descrição de Recursos de Hardware Ideal

Servidor

 Computador IBM PC ou Compatível;

 Processador 2 GHz;

 2 GB de Memória RAM;

 HD de 160 GB;

 Teclado;

 Mouse; e

 Placa Ethernet 10/100.

Máquina Cliente

 Computador IBM PC ou Compatível;

 Processador 1 GHz;

 1 GB de Memória RAM;

 HD de 80 GB;

 Teclado;

 Mouse; e

 Placa Ethernet 10/100.

3.4.2 Descrição de Recursos de Hardware Mínimo

Servidor

 Computador IBM PC ou Compatível;

 Processador 1.7 GHz;

 1 GB de Memória RAM;

 HD de 100 GB;

12
 Teclado;

 Mouse; e

 Placa Ethernet 10/100.

Máquina Cliente

 Computador IBM PC ou Compatível;

 Processador 700 MHz;

 HD de 40 GB;

 512 MB de Memória RAM;

 Teclado expandido;

 Mouse; e

 Placa Ethernet 10/100.

3.4.3 Descrição de Recursos de Software

Servidor

 Sistema Operacional – Windows XP Professional;

 Banco de Dados – Oracle Database Server 9i (versão 9.2.0.1);

 Software de ETL – Oracle Warehouse Builder (versão 10.1.0.4);

 Software Front-End – Oracle Discoverer Administrator (versão


10.1.2.1); e

Cliente

 Sistema Operacional - Windows XP Professional ou Home Edition; e

 Software Front-End – Oracle Discoverer Desktop.

Desenvolvimento

 Ferramenta Case - Enterprise Architect 7.1.

3.4.4 Descrição de Recursos Humanos

 2 analistas de sistemas;

 1 DBA (Database Administrator);

 2 consultores ETL; e

13
 2 consultores OLAP.

3.5 Relação Custo x Benefício

A implementação de um Data Warehouse é um investimento de longo


prazo, entretanto existe a possibilidade de durante o desenvolvimento deste, já
obter alguns resultados por meio da construção de Data Marts departamentais
separados que podem ser integrados ao fim do projeto.

Desta forma, é possível que os gerentes tomem conhecimento de


informações precisas que afetam diretamente na tomada de decisões
estratégicas da evolução da escola.

Com o armazenamento dos dados históricos possibilita a análise sobre


as mensalidades pagas pelos alunos, o qual possibilita a criação de políticas
para manter os alunos já matriculados ou convidar novos alunos a serem
matriculados na instituição.

3.6 Áreas afetadas pela pesquisa

Com a implementação do Data Warehouse, toda a escola será afetada a


longo prazo, incluindo:

 Marketing;

 Diretoria; e

 Recursos Humanos.

Porém para o desenvolvimento do protótipo será considerada a análise


somente da área fim da escola, que abrange o assunto de ocorrências e
notas dos alunos.

4. Metodologia da pesquisa

A metodologia adotada para esta pesquisa é a pesquisa classificada


como bibliográfica, pois se destina a investigar possibilidades do emprego dos
melhores métodos e práticas a serem recomendadas a fim de aplicação prática
de um estudo de Data Warehouse em uma instituição de ensino.

Foram realizadas pesquisas bibliográficas com a finalidade de apoiar as


idéias propostas, por meio de um estudo desenvolvido com base em materiais

14
originados de livros, materiais eletrônicos, com o objetivo de se levantar uma
base para o embasamento teórico.

5. Detalhamento da pesquisa – Estudo Teórico

Nesta seção serão apresentadas as principais características de um


Data Warehouse. Embasado em trabalhos realizados e publicados por diversos
autores renomados da área, o objetivo desta pesquisa é elucidar os principais
aspectos relacionados à tecnologia citada.

A princípio serão apresentados aspectos macros relativos ao assunto,


tais como principais conceitos, objetivos, histórico, entre outras questões.

Feito isso, outros aspectos mais profundos tais como modelagem,


arquitetura, processos ETL (Extração, Transformação e Carga), criação de
consultas e ciclo de desenvolvimento serão apresentados.

5.1. Introdução

A importância de definir uma estratégia para conquistar clientes e


conseqüentemente, aumentar o lucro e o capital das companhias faz com que
o uso de tecnologia da informação voltada para a tomada de decisão seja cada
vez mais utilizado dentro das companhias de forma a auxiliar no alcance dos
objetivos contemplados por sua estratégia.

Essas tecnologias são vitais porque a partir da visão dos dados contidos
nos repositórios transacionais, será possível a extração de informações
importantes e históricas para análise estratégica do negócio em um ambiente
analítico próprio.

Segundo Oliveira (2002) o Data Warehouse surgiu principalmente devido


às dificuldades emergentes que as organizações começaram a enfrentar no
momento de reunir os dados para uma análise mais eficiente.

A solução para este problema foi armazenar os dados utilizando uma


arquitetura própria e criada exclusivamente para suportar o armazenamento
destes dados em um ambiente de análise de informações.

Com isso, é possível identificar vários assuntos sobre os quais se deseja


tomar uma decisão, a partir dos questionamentos gerenciais dos usuários
interessados na implementação deste sistema.

15
Atualmente esta tecnologia é aplicada amplamente em empresas de
grande porte no Brasil e no mundo, provendo ao alto escalão empresarial uma
tecnologia robusta e completa que consegue atingir seus objetivos quando
aplicada de forma correta.

Trazendo este cenário para o mundo acadêmico, percebe-se a


necessidade de uma análise estratégica dentro do ambiente escolar para o
alcance de objetivos de igual importância quando comparados ao ramo da
Indústria, Telecomunicações, Logística, entre outras. Com base nesta
necessidade, esta pesquisa, tem como intuito de elucidar os principais
conceitos relacionados à tecnologia DW e ao final responder a questões
estratégicas referentes a um ambiente escolar específico por meio de um
protótipo.

5.1.1. Conceito

Um Data Warehouse oferece os fundamentos e os recursos necessários


para um Sistema de Apoio a Decisão (SAD) eficiente, fornecendo dados
integrados e históricos que servem desde a alta direção, que necessita de
informações mais resumidas, até as gerencias de baixo nível, onde os dados
detalhados ajudam a observar aspectos mais táticos da empresa. [Oliveira,
2002]

Ralph Kimball e William Inmon estão entre os autores mais respeitados


no universo Data Warehouse. Eles foram os pioneiros na tecnologia, e
conceituam-na de formas um pouco diferente, entretanto complementares.

Segundo Inmon (1997), um Data Warehouse é caracterizado como “uma


coleção de dados orientada por assuntos, integrada, variante no tempo, e não
volátil, que tem por objetivo dar suporte aos processos de tomada de decisão”.

Já na opinião de Ralph Kimball (1998), um Data Warehouse é “uma


cópia dos dados de transações, estruturadas especificamente para consultas e
análises”.

Sumarizando a essência dos conceitos, um Data Warehouse é um


sistema que é utilizado pela alta cúpula empresarial com o intuito de auxiliar
nas decisões estratégicas de uma corporação, de forma que utiliza os dados
dos sistemas transacionais (OLTP) e os armazena em um ambiente de

16
arquitetura própria para análise, e que é orientado por assunto, integrado,
variante no tempo e não volátil.

A própria tradução do termo Data Warehouse diz bastante sobre o seu


conceito. Um Armazém de Dados – tradução do termo DW - é um repositório
de dados onde se podem guardar os dados históricos de uma organização.

A alta gerência usuária do DW acessa o sistema usando ferramentas


SAD para consulta instantânea de relatórios na tela com montagem de
gráficos, textos, tabulação de números, entre outros recursos, acessando
diretamente a base de dados corporativa da empresa.

É importante salientar que estes artefatos são os resultados das


necessidades que foram levantadas em algum momento pelos analistas de
sistema DW juntamente com estes usuários. No entanto há situações onde os
usuários podem criar suas próprias consultas a partir de uma estrutura já
montada do Data Warehouse. Estas consultas são chamadas de ad hoc, ou
simplesmente consultas aleatórias, que são criadas a partir de usuários com
mais experiência e que conheçam a estrutura DW que lhe foi montada.

5.1.2. Objetivo

O Data Warehouse tem o objetivo de integrar e mostrar informações


gerenciais das organizações, para que estas sejam utilizadas como base pela
alta cúpula da companhia durante a tomada de decisões. Essa ferramenta
ajuda os gestores a terem uma visão abrangente dos seus processos de
negócio por meio da seleção dos assuntos mais relevantes que cercam a
corporação.

A seleção destes assuntos por vezes envolve várias áreas de uma


empresa. Um exemplo é quando um gestor deseja cruzar dados da área de
Contabilidade e de Recursos Humanos e saber o valor do orçamento
despendido com um determinado departamento por cargo. Estes assuntos,
bem como seus relacionamentos, são definidos conforme as necessidades do
gestor no início de um projeto DW e repassada à parte desenvolvedora para
que esta possa avaliar a viabilidade de entrega deste assunto dentro do DW.

Neste contexto o DW tem o objetivo de fornecer informações


consistentes a seus usuários. O gestor no caso do exemplo acima deve ter
certeza de que aqueles dados foram cruzados de forma correta e que aquela

17
informação pode ser tomada como base para a formação do conhecimento do
gestor.

Outro objetivo do DW é tornar as informações corporativas acessíveis


para visualização. Isso significa que, uma vez fechado o escopo do projeto, os
dados são carregados de forma que fiquem à disposição para seus usuários.
Esta utilização geralmente é feita por meio de ferramentas de consultas OLAP,
que oferecem visões por meio de relatórios, planilhas, entre outros. O termo
acessível também quer significa que os o DW deve entregar suas informações
de forma ágil.

Outro objetivo também importante exercido pelo DW é a comparação


das operações de forma histórica. Isso é possível devido a este tipo de sistema
ter a capacidade de armazenar informações ao longo de vários anos. Ao
armazenar os dados de forma histórica é possível verificar tendências relativas
às operações de uma empresa, de modo que um processo possa ser
remodelado por meio de um processo de reengenharia.

O último objetivo é aumentar o lucro da empresa quando a alta gerência


opta por implementar um Data Warehouse na empresa. Isso porque os
usuários destes sistemas têm condições de conhecer exatamente os números
de sua corporação. Por meio disso, estes usuários adquirem a capacidade de
saber pontualmente que foco deve ser dado ao seu negócio de forma que o
lucro desta corporação seja expandido.

5.1.3. Evolução dos Sistemas de Suporte à Decisão

Segundo Inmon (2005), a figura abaixo mostra a evolução


processamento de informação no começo dos anos sessenta com o início da
criação de aplicativos individuais que funcionavam usando master files
(arquivos-mestre). Os aplicativos com características de relatórios e programas
normalmente eram escritos em Fortran ou Cobol, perfurando cartões ou fitas de
papéis. Os master files eram hospedados em fitas magnéticas, que eram
ótimas para armazenamento de grande volume dados barato, mas o
inconveniente era o acesso seqüencial dos dados. Era possível o acesso aos
100% dos dados, porém normalmente 5% ou menos dos dados registrados
eram realmente necessários. Além do acesso à fita inteira levava em torno de
vinte a trinta minutos, dependendo de onde o dado se encontrava.

18
De acordo com Inmon (2005), por volta do meio da década de sessenta,
o crescimento de master files e fitas magnéticas explodiram. Vindo também o
crescimento da enorme quantidade de dados redundantes. A proliferação dos
master files e dados redundantes apresentou um problema muito insidioso:

 A necessidade de sincronização sobre a atualização dos dados;

 A complexidade de manutenção dos programas;

 A complexidade da criação dos novos programas; e

 A necessidade de ampla quantia de hardware para suporte de todos


os master files.

Por volta dos anos setenta, deu-se início a uma nova tecnologia de
armazenamento com o DASD (Direct Access Storage Device), dispositivo de
armazenamento de acesso direto, que era diferente das fitas magnéticas, onde
os dados poderiam ser acessados diretamente via DASD, não sendo mais
necessário passar pelos dados 1, 2, 3, ...,,n até chegar ao dado gravado na
posição n+1, pois o endereço do dado é conhecido, simplificando o acesso a
este, além de que o tempo requerido para ir ao dado gravado na posição n+1
era um tempo significantemente menor que o tempo requerido para o acesso a
este mesmo dado em uma fita magnética, agora sendo mensurado em
milisegundos.

Com o DASD, veio um novo tipo de sistema de software conhecido


como Sistema Gerenciador de Banco de Dados (SGBD ou DBMS – Database
Management System) com o propósito de facilitar o armazenamento e acesso
de informações pelos programadores ao DASD. O DBMS tomava cuidado com
alguns serviços de armazenamento de dados no DASD, como indexar a
informação. Estas novas tecnologias vieram solucionar o problema dos master
files e com o DBMS teve uma noção do que é um banco de dados.

Em meados dos anos 1975, foi criado um meio de acesso rápido aos
dados chamado OLTP, abrindo toda uma nova perspectiva para
processamento e negócio, possibilitando o uso do computador em novas
tarefas antes impossíveis, como sistema de controle de manufaturas, sistemas
de reservas, entre outros.

Em meados de 1980 vieram novas tecnologias, como os PCs (Personal


Computers) e 4GL (Fourth-generation Languages), possibilitando o usuário
19
final controlar diretamente os dados e os sistemas. Com estas duas tecnologias
teve-se a noção da simplicidade das transações Online. O MIS (Management
Information System), eram processamentos usados para operar decisões de
gerenciamento.

Figura 2 – Evolução dos Sistemas de Apoio à Decisão [INMON, 2005]

20
5.1.4. Público Alvo

A solução de Data Warehouse está voltada para o nível estratégico e


gerencial de uma companhia de forma a suportar a tomada de decisões.

Dentre os principais usuários deste tipo de sistema, pode-se citar os


Sócios, Diretores, Analistas de Suporte a Decisão, Presidentes, Gerentes e
Usuários Chave.

Estes são profissionais de alto nível que devem estar informados a


respeito da sua corporação de forma que possam contribuir com seu
crescimento.

Além de serem os usuários finais de uma solução de DW, estas são as


pessoas que visualizam as necessidades que deverão ser supridas pelo
sistema. Estes usuários geralmente são envolvidos diretamente no processo de
levantamento dos assuntos que serão tratados por um DW.

5.1.5. Características

Um DW proporciona uma sólida e concisa integração dos dados da


empresa e análises gerenciais sólidas dos dados estratégicos de seus
principais processos de negócio, preocupando-se em integrar as informações
de fontes internas e externas, sumarizando, filtrando e limpando os dados.

Entre as principais características de um Data Warehouse segundo


Machado (2006) podem ser citadas as seguintes:

 Extração de dados de fontes heterogêneas internas e/ou


externas – O DW possui um conjunto de processos responsáveis
por carregar os dados a partir dos sistemas transacionais (OLTP).
Este conjunto é denominado processos de extração, transformação e
carga (ETL- Extraction, Transform and Load). Esta característica
inicial se refere ao primeiro passo de coleta dos dados a partir dos
sistemas OLTP para o DW. É basicamente uma cópia dos dados de
um lado para o outro. Esta extração é realizada segundo normas de
mapeamento de dados. Estas normas definem a localização bem
como a origem e o destino dos dados que deverão ser carregados;

 Transformação e integração dos dados – Após os processos de


extração dos sistemas OLTP para o DW são aplicadas algumas

21
regras de negócio aos dados. Esta transformação é realizada para
que as necessidades dos usuários sejam refletidas nos dados e para
transformá-los em informações úteis. Esta transformação então se
refere à aplicação de filtros, conversão de dados, manipulação de
dados de diferentes fontes. Um exemplo básico, o DW pode ser
responsável por unificar as informações de Sexo (Masculino ou
Feminino) que estão representadas em seus diversos sistemas ora
como “M” para masculino e “F” para feminino, ora como “1” para
homens e “2” para mulheres;

 Requer máquina e suporte próprios – Salvo casos especiais de


implementação de Data Marts (assunto abordado mais a frente)
departamentais ou demonstrações, um projeto de Data Warehouse
comprometido com a empresa deve possuir recursos e máquinas
próprios para que seja possível seu desenvolvimento;

 A visualização de dados pode ser feita em diferentes níveis – As


informações podem ou não serem extraídas para um nível mais
específico, como os Data Marts e deste para um BD individual;

 Uso de ferramentas para acesso ao DW com níveis diferentes de


apresentação – Uma ferramenta de Data Warehouse deve ser
capaz de mostrar várias perspectivas de visão da mesma
informação. Isso significa que estas ferramentas devem oferecer a
seus usuários, a capacidade de, a partir de uma determinada visão
das informações, se aprofundar mais nos detalhes daquela visão
(também chamado de Drill Down). Isso possibilita ao analista daquela
informação ter um conhecimento maior sobre o assunto pesquisado;

 Os dados não são atualizados, são somente inseridos – Para se


manter o histórico de mudanças dentro do sistema, geralmente os
dados não sofrem processos de atualização (update). Por exemplo,
se a descrição do peso de um produto de uma companhia for
alterado, o DW por praxe, insere uma nova linha idêntica a anterior
salvo pelo atributo peso. Para evitar duplicações geralmente é
aplicado um atributo no registro dizendo se ele é ou não atual e qual
foi a data de alteração do mesmo. Com isso, o analista das

22
informações tem a capacidade de acompanhar mudanças neste
determinado produto;

 Orientação por assunto – Dentro de um Data Warehouse são


comumente encontradas informações sobre diversos assuntos de
uma empresa, e estes assuntos estão relacionados às suas áreas.
Um exemplo é que dentro do universo DW de uma empresa, está
inserido uma consulta retratando a quantidade de funcionários de
uma empresa que estão lotados em determinadas diretorias e que
participam de diversos centros de custo. Este exemplo mostra
como três assuntos diferentes podem estar relacionados entre si,
“funcionário” representando o assunto Recursos Humanos,
“diretorias” representando Estrutura Organizacional e “centro de
custo” representando o assunto Financeiro;

 Variação no tempo – Ao contrário dos sistemas OLTP, o DW


precisa manter informações históricas relacionadas aos seus
diversos assuntos. Ele faz isso armazenando seus dados por vários
anos em algumas ocasiões. Estas informações servem de
fundamento para análise histórica de alguma questão relacionada à
corporação. Esta variação muitas vezes é importante para análise
das tendências relacionadas a determinados assuntos.

 Não volátil – Em um sistema OLTP tradicional geralmente existem


várias operações ocorrendo ao mesmo tempo, tais como operações
de leitura, escrita, atualização e inserção. No DW estas operações
basicamente se resumem a carga inicial dos dados (primeira
inserção dos dados), carga incremental e a consultas destes dados.
Como já visto, o DW mantém um histórico das suas informações o
que significa que operações de “deleção” das informações são muito
raras, tornando-o não volátil; e

 Integrado – Esta característica diz respeito a unicidade das


informações, ou seja, mesmo que mesmas informações venham com
formatos diferentes de lugares diferentes, estas informações devem
ser unificadas para que seja apresentado apenas um valor dentro do
Data Warehouse.

23
5.1.6. Papéis

Por sua abrangência, o DW envolve vários profissionais, dentre eles


analistas de processamento de dados até analistas de negócio, ou clientes
deste ambiente.

No ambiente de DW inclui os administradores do projeto, os projetistas


do banco, os administradores de bancos de dados (Database Administrators)
dos sistemas operacionais, os administradores de dados, programadores e
analistas de sistemas, analistas de aplicativos e usuários finais, onde estes são
agrupados por papéis como descrito a seguir:

 Analistas responsáveis pela carga dos dados composto por


programadores que precisam conhecer o mapeamento entre o DW e
os sistemas operacionais além dos requisitos para filtragem e
integração dos dados;

 Usuários finais que são os especialistas, gerentes executivos e


analistas de negocio que utilizam as informações para apoio à
tomada de decisão, os quais estão sempre em busca de solução de
um problema ou em busca de novas oportunidades de negócio. São
divididos em dois grupos, os usuários diretos que acessam
livremente o DW enquanto os usuários indiretos buscam os dados
nos Data Marts (DMs) especializados;

 Analistas de desenvolvimento e manutenção do DW e DMs que


abrangem os analistas de banco de dados e administradores de
dados dos sistemas gerenciadores de banco de dados, sendo
responsáveis pelos metadados, arquitetura de armazenamento e
estrutura de dados afim de melhorar o desempenho das consultas; e

 Administradores de Dados que desempenham papel fundamental por


ser um integrador dos ambientes transacional e dimensional, para
garantia da qualidade e existência da integridade do DW, via
acompanhamento e administração dos metadados entre os sistemas
transacionais e seu processo de manutenção de extração,
transformação e carga do DW.

24
5.2. PLANEJAMENTO DO PROJETO

O plano de projeto proposto pode ser visualizado em quatro grandes


partes, a saber:

 Ferramentas;

 Hardware;

 Recursos humanos; e

 Desenvolvimento da aplicação.

Essa segmentação das atividades tem o objetivo de:

 Mitigar os riscos envolvidos com ciclo de desenvolvimento e


implantação;

 Formalizar, por meio de uma boa documentação - ponto fundamental


em EDW (Enterprise Data Warehouse), o elo entre design e
construção; e

 Garantir a estabilidade da infra-estrutura.

5.2.1. Planejamento

Na primeira etapa do projeto de Data Warehouse, é definido o escopo do


projeto com ênfase no negócio. A definição da abordagem corporativa vai
desde a escolha de um DW monolítico, grande, fortemente integrado em nível
de projeto, do qual sairão os Data Marts posteriormente (abordagem top-down),
até uma alternativa gradativa, onde os Data Marts evolutivos integrarão o DW
na medida de suas implementações (abordagem bottom-up).

Após a definição das áreas/assuntos do primeiro projeto, é feito o


planejamento para a integração dos DM de forma gradativa, identificando os
elos que possibilitarão as conexões futuras e integrações:

25
5.2.2. Plano do Processo de Desenvolvimento

As atividades para o desenvolvimento de aplicações (cada produto a ser


entregue) cobrem todas as tarefas - desde os levantamentos até o aceite final
do produto pelo usuário-final, que, resumidamente, são as seguintes:

 Identificação da área de negócio;

 Estudo da cadeia de valores para identificação dos


medidores/critérios de desempenho e a definição do escopo do
produto;

 Modelagem dimensional preliminar do Data Mart (DM);

 Mapeamento de origem e destino dos dados;

 Definição dos processos de ETL;

 Construção dos processos de ETL;

 Construção das aplicações;

 Carga dos dados; e

 Teste, homologação e termo de aceite do produto.

5.2.3. Ciclo de vida do projeto

O ciclo de vida para o projeto será dividido em seis fases na metodologia


em espiral a saber:

 Levantamento – Fase em que são levantados os requisitos para o


novo sistema ou para o sistema já existente. Neste ponto as
necessidades são colhidas junto ao cliente;

 Design e Modelagem – Levantamento, documentação e Modelagem


do DW a ser aprimorado a cada iteração;

 Codificação – Geração dos scripts ou dos programas de acordo com


a evolução do projeto de DW;

 Testes e homologação – Testes unitários e homologação pelo


cliente, feitos desde a documentação até o produto final; e

 Implantação – Implantação em ambiente produtivo para uso efetivo


do DW.

26
5.2.4. Métodos de Desenvolvimento e ferramentas CASE

O método para o levantamento de dados será baseado em pesquisa


científica e método de desenvolvimento será o desenvolvimento em espiral,
visto que as iterações da metodologia é atualmente muito utilizada como uma
metodologia de desenvolvimento e que não contém somente informações
sobre como construir Data Warehouse, mas também descreve como se usa um
Data Warehouse.
A metodologia de desenvolvimento em espiral descreve dinamicamente
as atividades específicas, entregáveis das atividades e a ordem das atividades.
O dinamismo da criação iterativa de um Data Warehouse, não são descritas,
porém, é descrito um plano em três dimensões das migrações fragmentadas,
enquanto que a metodologia de desenvolvimento espiral descreve os detalhes
do plano em uma dimensão. Juntos, eles formam uma imagem completa do
que é necessário para a construção do Data Warehouse.
A ferramenta utilizada no desenvolvimento do projeto será o Enterprise
Architec.

5.2.5. Ambiente de hardware para o desenvolvimento

Para o desenvolvimento do Data Warehouse será necessário os


seguintes hardwares:

 Servidor de banco de dados Oracle com alguma massa de dados


considerável descaracterizado para geração dos cubos OLAP e fase
de ETL;

 2 Computadores IBM/PC ou compatível com 1 GB de RAM,


velocidade de 1 Ghz e HD de 80 GB.

 Placa Ethernet 10/100

5.3. Plano de Organização

O plano de organização proposto para o desenvolvimento do Data


Warehouse será dividida em duas equipes: Uma equipe de gerência do projeto
e a equipe de Desenvolvimento do projeto, as quais são detalhadas a seguir.

5.3.1. Equipe de Gerência

Será composto por um gerente de desenvolvimento de Data Warehouse,


responsável por:

27
 Coordenar os trabalhos;

 Auxiliar no desenvolvimento do plano; e

 Revisão final do plano.

5.3.2. Equipe de Desenvolvimento

A equipe de desenvolvimento será composta por vários profissionais descritos


abaixo

 Analistas responsáveis pela carga dos dados composto por


programadores que precisam conhecer o mapeamento entre o DW e
os sistemas operacionais além dos requisitos para filtragem e
integração dos dados;

 Analistas de desenvolvimento e manutenção do DW e DMs que


abrangem os analistas de banco de dados e administradores de
dados dos sistemas gerenciadores de banco de dados, sendo
responsáveis pelos metadados, arquitetura de armazenamento e
estrutura de dados afim de melhorar o desempenho das consultas; e

 Administradores de Dados que desempenham papel fundamental por


ser um integrador dos ambientes transacional e dimensional, para
garantia da qualidade e existência da integridade do DW, via
acompanhamento e administração dos metadados entre os sistemas
transacionais e seu processo de manutenção de extração,
transformação e carga do DW.

 Três analistas de Banco de dados;

 Um administrador de dados;

5.4. Plano de Acompanhamento

Será descrito a seguir um plano de acompanhamento do


desenvolvimento do Data Warehouse.

5.4.1. Marcos e Pontos de Controle

Para a execução do projeto, serão pré-estabelecidos pontos de


controles semanais para acompanhamento a fim de identificar falhas,
cumprimento do cronograma de acordo com o estabelecido.

28
Cronograma Geral
Fev Mar Abr Mai Jun
Planejamento
Levantamento das
necessidades
Modelagem
dimensional
Projeto físico dos
banco de dados
Projeto de ETL
Desenvolvimento de
aplicações
Validação e Teste
Treinamento
Implantação.
Tabela 1 – Cronograma geral do projeto

5.4.2. Métodos de acompanhamento e controle

Por ser adotado o modelo de desenvolvimento em espiral, cada circuito


completo da espiral resultará no desenvolvimento da especificação do produto
até a conclusão do projeto.

Em cada passagem pela região de planejamento resultará em ajustes do


plano do projeto, onde o custo e o cronograma são ajustados com base no
feedback derivado do cliente após a comunicação do andamento do projeto, o
qual o gerente do projeto poderá ajustar o número planejado de iterações
necessárias para completar o software.

29
5.4.3. Análise e Gerência de Riscos

A seguir serão abordados os riscos identificados para o processo de


desenvolvimento do Data Warehouse dos quais alguns problemas podem
ocorrer durante o desenvolvimento do sistema DW.

 Carga de dados desnecessários dentro do DW;

 Confundir o projeto do banco de dados DW com o projeto de um


sistema transacional

5.5. Plano de Documentação

5.5.1. Documentos do projeto

Abaixo são descritos alguns documentos para para implementação de um DW.


Tabela 2 – Documentos do projeto

Nome Descrição
Proposta de Especificação e Documento que descreve de forma
Desenvolvimento do DW (plano de detalhada o escopo do projeto e o plano de
projeto) trabalho do projeto de DW.
Descrição da Modelagem do DW Documento que descreve, de forma
detalhada, a modelagem do DW.
Scripts do DW Documento que contém os scripts utilizados
na geração do DW.
Manual do Usuário do DW Documento que serve de referência para
uso do software pelo cliente.

5.6. Plano de Recursos e Produtos

A seguir serão descritos os planejamentos de recursos humanos,


hardware e software necessários para o desenvolvimento do DW.

5.6.1. Recursos Humanos


Tabela 3 – Quadro de funcionários necessários para desenvolvimento de um DW.

Função Nome Formação Experiência

30
Formação superior em
Sistemas de Informação; Mínimo de 5 anos
Analista de
André L. P Gonçalves Mestrado na área de em Analise de
Sistemas
analise de sistemas de Sistemas.
informação.
Formação superior em
Sistemas de Informação. Modelagem de
Administrador de
Sylvia S Shibata Mestrado ou especialização dados; banco de
Dados
na área de gerencia de dados
projeto.
5 anos em
Superior completo na área
desenvolvmento e
Analista de Testes Sylvia S Shibata de tecnologia da
certificações na área
informação.
de qualidade.
Superior completo na área
Analista de dados André L. P Gonçalves de tecnologia da Banco de dados
informação.

Superior completo na área


Analista de banco
Sylvia S Shibata de tecnologia da Banco de dados
de dadosDBA
informação.

31
5.6.2. Recursos de Hardware

Os recursos de hardware necessários para o desenvolvimento do DW


serão descritos a seguir:
Recursos de Hardware
Discriminação Unidade Quantidade Valor Índice de Valor Total
de Medida Unitário Aplicação (R$)
(R$) (%)
Microcomputadores un. 04 1.800,00 100 7.200,00
Servidor un. 01 1.200,00 100 1.200,00
SUBTOTAL 8.400,00

5.6.3. Recursos de Software

Os recursos de software necessários para o desenvolvimento do projeto


são:

 Sistema Operacional – Windows XP Professional;

 Banco de Dados – Oracle Database Server 9i (versão 9.2.0.1);

 Software de ETL – Oracle Warehouse Builder (versão 10.1.0.4);

 Software Front-End – Oracle Discoverer Administrator (versão


10.1.2.1); e

 Sistema Operacional - Windows XP Professional ou Home Edition; e

 Software Front-End – Oracle Discoverer Desktop.

 Ferramenta Case - Enterprise Architect 7.1.

32
5.6.4. Recursos Financeiros
Tabela 4 - Recursos Financeiros

Recursos Financeiros
Ano 2008
Recursos Atividades Fev mar abr mai jun Total
Analista de
Sistemas R$ 7.000 R$ 7.000 R$ 7.000 R$ 21.000
Gerente de
Projeto R$ 10.850 R$ 10.850 R$ 10.850 R$ 10.850 R$ 10.850 R$ 54.250
Administrador de
dados R$ 7.500 R$ 7.500 R$ 7.500 R$ 7.500 R$ 30.000
Administrador de
dados R$ 7.500 R$ 7.500 R$ 7.500 R$ 7.500 R$ 30.000
DBA R$ 7.808 R$ 7.808 R$ 7.808 R$ 7.808 R$ 31.232
Analista de
Testes R$ 3.799 R$ 3.799 R$ 7.598
Pessoal Total R$ 32.850 R$ 40.658 R$ 40.658 R$ 37.457 R$ 22.457 R$ 174.080
Serviços de Limpeza R$ 420 R$ 420 R$ 420 R$ 420 R$ 420 R$ 2.100
Terceiros Total R$ 420 R$ 420 R$ 420 R$ 420 R$ 420 R$ 2.100
Gastos não
esperados R$ 1.000 R$ 1.000 R$ 1.000 R$ 1.000 R$ 1.000 R$ 5.000
Outros Total R$ 1.050 R$ 1.050 R$ 1.050 R$ 1.050 R$ 1.050 R$ 5.250
Total R$ 68.590 R$ 84.206 R$ 84.206 R$ 77.804 R$ 47.804 R$ 362.610

33
5.7. Cronograma

A seguir será apresentado um cronograma resumido do projeto de Data Warehouse


elaborado no MS Project.

Figura 3 – Cronograma no MS Project.

5.8. Modelagem de Dados

Segundo o Dicionário Aurélio, modelo significa Molde; Aquilo que serve como
exemplo ou norma. Neste sentido, modelo de dados representa a essência de algo
que deve ser criado.

O modelo de dados utilizado em sistemas de Data Warehouse é


essencialmente diferente da modelagem utilizada nos sistemas OLTP. Grande parte
dos bancos de dados de sistemas transacionais das empresas atuais utiliza o
Modelo Relacional. Data Warehouse utiliza o Modelo Multidimensional para
organizar as informações.

O porquê da utilização de dois modelos para estes dois ambientes está ligado
intimamente à natureza de cada um dos mundos. Mundo Transacional versus
Analítico. O ambiente OLTP está basicamente centrado em operações do dia-a-dia
da empresa, tais como a inserção de um novo produto, a atualização do salário de
um funcionário, a remoção de uma conta contábil, e outras manipulações no banco
de dados. As operações de banco de dados para sistemas transacionais são

34
essencialmente select, insert, update, delete. Estas operações são bem pontuais e
geralmente requerem pouca quantidade de processamento.

Já no universo da análise o tipo de manipulação exercida sobre os dados é


diferente. Quando um usuário DW deseja saber alguma informação, ele abre sua
ferramenta preferida de análise e executa uma nova consulta. Esta pergunta na
maioria das vezes requer a recuperação de milhares ou por vezes milhões de
registros em um banco de dados. Neste caso a quantidade de processamento
exigido é bem maior do que nos sistemas transacionais. As operações mais comuns
em ambiente de análise são select e insert. Comumente um DW recebe uma carga
inicial de dados e após esta etapa são feitas apenas cargas incrementais. A partir
desta massa de dados seus usuários então podem realizar consultas (selects).

A normalização é um processo que tem como objetivo a remoção da


redundância de informações em bancos de dados além de garantir que a informação
se relacione de forma precisa dentro deste ambiente. A normalização oferece um
conjunto de normas (formas normais) que aconselham como o projetista deve
montar a estrutura do banco. As formas normais servem como instrumento para que
os mesmos dados não se repitam ao longo das tabelas do banco, causando a
duplicação de dados de forma desnecessária e consequentemente afetando o
desempenho do Sistema Gerenciador de Banco de Dados (SGBD).

Neste contexto os sistemas OLTP por padrão apresentam estrutura bem mais
normalizada quando comparados com os sistemas DW. Segundo Machado (2006)
“a maioria das técnicas de modelagem concorda que a aplicação completa da teoria
relacional não é apropriada para Data Warehouse.” e esta afirmação leva em
consideração aspectos distintos dos dois ambientes tais como alto volume de dados
dos sistemas DW. Apesar do DW utilizar técnicas de normalização em casos muito
específicos, esta técnica é mais recomendada para sistemas OLTP. Técnicas de
normalização aplicadas aos sistemas DW como um todo, apresentam um alto grau
de ineficácia.

Conclusivamente segundo Machado(2006) “Se mover o modelo de dados


transacional para um banco de dados separado e inserir os dados históricos,
chamando-o de Data Warehouse, não será possível trabalhar com estes dados, pois
os usuários não conseguirão realizar consultas ad hoc por possuir uma
complexidade muito alta e pelo fato do modelo transacional respeitar a terceira
35
forma normal, não respondendo com rapidez a questões de apoio à decisão por
requererem de cinco a mais joins de tabelas.”

Figura 4 – Exemplo de Modelo Relacional [DSPACE,2008]

Figura 5 – Exemplo de Esquema de Modelo Multidimensional [DEVMEDIA, 2008]

36
Figura 6 – Exemplo de Modelo Multidimensional.[MICROSOFT, 2008]

5.8.1. Modelagem Multidimensional

“A modelagem multidimensional é uma técnica de concepção e visualização


de um modelo de dados de um conjunto de medidas que descrevem aspectos
comuns de negócios. É utilizada especialmente para sumarizar e reestruturar dados
e apresentá-los em visões que suportem a análise dos valores desses dados.”
[Machado,2006]

Devido ao grande volume de dados e a complexidade envolvida nas consultas


de Data Warehouse, o modelo multidimensional busca organizar as informações de
forma a facilitar o entendimento do usuário final e de forma a agilizar o retorno das
consultas.

Entre os elementos básicos da modelagem multidimensional os Fatos,


Dimensões e as Medidas são de suma importância par ao entendimento do modelo.

37
Conceitualmente os fatos, dimensões e medidas são determinados segundo
Machado(2005) como:

 Fatos – são “elementos que representam um item, uma transação ou um


evento de negócio e é utilizado para analisar o processo de negócio de
uma empresa” e acrescenta que “a característica básica de um fato é que
ele é representado por valores numéricos...”;

 Dimensões – são denominadas como “elementos que participam de um


fato e são as possíveis formas de visualizar os dados, ou seja, são os ‘por’
dos dados: ‘por mês’, ‘por país’, ‘por produto’, ‘por região’, entre outros.”; e

 Medidas – “são os atributos numéricos que representa um fato, a


performance de um indicador de negócios relativo às dimensões que
participam deste fato”.

Com isso pode-se dizer que a relação essencial entre Fatos, Medidas e
Dimensões é bem simples: Os Fatos são os elementos quantificadores (valores)
enquanto as Dimensões são os elementos qualificadores (descrições) enquanto as
medidas são atributos numéricos que representam um fato.

Fisicamente, dentro do modelo multidimensional os fatos ficam armazenados


em tabelas chamadas “Tabelas de Fato” e as dimensões do negócio são
armazenadas respectivamente nas “Tabelas de Dimensão”. Os fatos estão
diretamente relacionados às dimensões, pois necessitam destas “descrições” para
que se tenha uma análise com sentido completo.

Outra característica física relacionada a estrutura de tabelas, é que as tabelas


de fato carregam os identificadores das dimensões (chaves estrangeiras) como
forma de interligar estas duas entidades. Abaixo um exemplo típico do modelo
multidimensional.

38
Figura 7 – Exemplo de Estrutura Multidimensional [DEVMEDIA, 2008]

Observa-se que para a tabela de fatos acima existe um conjunto de


dimensões ligadas a ela. Isso justamente porque os fatos necessitam ser descritos
de forma que se empregue semântica nas análises. Inseridas no fato existem
medidas que são determinadas pela combinação das dimensões que participam de
um fato e estão localizadas como atributos de um fato. As dimensões vão qualificar
ou descrever os fatos.

Um exemplo de uma das análises que pode ser feita a partir da estrutura
multidimensional mostrada na figura é quando um gestor gostaria de obter a
seguinte informação ilustrativa: Visualizar o valor em dólares (medida) das vendas
(fato vendas) realizadas no mês de Dezembro de 2006/2007 e 2008 (dimensão
tempo) dos aparelhos de telefone celular (dimensão produto) que foram vendidas
em lojas de São Paulo, Brasília e Rio de Janeiro (dimensão loja).

Este exemplo ilustra a forma como estes vários elementos podem se


relacionar dentro da estrutura. O valor em dólares representa a medida, que é um
atributo da tabela de fatos. Este atributo como o próprio conceito cita, armazena o
valor numérico em questão. Já as dimensões representam as perspectivas sob qual
aquela informação pode ser vista, e que no caso da figura acima são as dimensões
de tempo, produto e loja. Em outras palavras, a mesma medida pode ser analisada
somente sob o ponto de vista (Somente Por mês, ou Somente Por Loja, ou Somente
Por Produto) ou pode ser combinada com várias outras perspectivas dimensionais.

Na modelagem multidimensional, os usuários conseguem entender melhor o


modelo de dados, pois muitas vezes estes navegam com facilidade pela estrutura de

39
dados resultante apesar de exigir um nível de abstração maior, comumente utilizado
em modelo de dados transacionais. Ao invés de uma estrutura altamente complexa
derivada da modelagem Entidade Relacionamento, a multidimensional mostra-se
muito mais acessível em termos de visualização e praticidade, além de ser
altamente adequada a ambientes de análise. O exemplo acima poderia muito bem
representar um modelo lógico de alto nível em alguma situação prática de
implementação. Durante a criação e visualização do modelo físico (ou de
implementação), os relacionamentos deste modelo são bem mais intuitivos que os
do modelo E/R.

Neste contexto, existem várias formas de modelagem multidimensional.


Conforme Thomas H. Harrison[HAR98] existem cinco opções de modelos
multidimensionais. Cada opção tem um conjunto de vantagens e considerações:

 Estrela (Star Schema);

 Snowflake (Flocos de neve);

 Estrela Parcial;

 Tabela Fato Particionada; e

 Tabela dimensional.

Apesar das várias opções o intuito desta pesquisa é mostrar as


características dos dois principais modelos: Modelo Estrela e do Snowflake. Estes
dois são os modelos mais comumente utilizados em implementações práticas.

5.8.2. Modelo Star Schema (Modelo Estrela)

É o modelo mais utilizado dentro do universo multidimensional e ao contrário


do modelo relacional este possui sua estrutura desnormalizada. “Sua composição
típica possuiu uma grande entidade central denominado fato (fact table) e um
conjunto de entidades menores denominadas dimensões (dimension table),
arranjadas ao redor dessa entidade central, formando uma estrela.” [Machado, 2006]

Entre as principais características do modelo a mais marcante e a que dá o


nome ao modelo é a questão da existência de uma única tabela fato histórica
simples ligada às dimensões por meio de chaves estrangeiras. Com uma única

40
tabela de fatos cercada de um conjunto de dimensões, este modelo lembra
fisicamente o formato de uma estrela.

Este histórico do fato é guardado devido as cargas incrementais realizadas


nestas tabelas. Aliando conceito e prática, o DW tem o objetivo de apresentar dados
históricos para análise e esta característica de cargas incrementais é a que
representa claramente esta marca. As tabelas de dimensão também podem guardar
histórico e para isso devem atualizar o registro antigo e fazer utilização de flags
(bandeiras) que indicam que o registro antigo consta na tabela somente para fins
históricos.

Nos sistemas de Data Warehouse as tabelas de fatos são em geral bem


maiores que as tabelas de dimensão. Ainda que possam existir tabelas de dimensão
realmente grandes as tabelas de fato com freqüência atingem uma quantidade de
registros muito grande, chegando a casa dos milhões.

Para o caso de tabelas DW muito grandes existem soluções que podem ser
empregadas para melhorar o desempenho de consultas de usuários finais. Entre
essas técnicas estão inclusos o particionamento de tabelas e a sumarização de
dados. O particionamento consiste em dividir logicamente as tabelas em porções
menores de modo que as consultas sejam direcionadas diretamente àquela porção
em que está contido o dado desejado. É como se uma grande tabela se tornasse
várias outras pequenas. Já a sumarização ou agregação, consiste em agrupar
registros de forma que o resultado final reflita um sumário contendo um número
menor de linhas, mas que reflita a mesma realidade.

A parte das soluções, este tipo de modelo é o mais apropriado para a


construção de um Data Warehouse, pois melhora bastante a performance,
diminuindo o número de ligações entre as tabelas. Além disso, o uso de uma tabela
única por dimensão e de uma tabela fato simples por categoria assegura que
definições dos metadados podem ser usadas novamente, independentemente do
nível de sumário ou fatos. A performance também é aumentada usando uma única
declaração SQL (Structured Query Language) para cada consulta – independente do
conteúdo do relatório.

A desvantagem consiste na grande replicação de dados nas dimensões


desnormalizadas. Dependendo do banco de dados utilizado e do espaço reservado

41
para o armazenamento será necessário fazer uma análise do volume estimado para
a criação do DW.

5.8.3. Modelo Snowflake (Floco de Neve)

Os modelos Snowflake empregam uma combinação da normalização da base


de dados para manter a integridade e reduzir os dados redundantes e a
desnormalização para obter maior desempenho. O modelo é mais fácil de ser
compreendido pelo usuário final, por esse motivo é muito utilizado como modelo
lógico, sendo utilizados outros modelos como modelo físico.

As dimensões são quebradas conforme os níveis de hierarquia apresentados


fazendo ligações entre si. Por exemplo, uma dimensão tempo contendo ano, mês e
dia será composta por três tabelas normalizadas, uma para cada atributo, passando
a chave estrangeira da tabela ano para mês e da tabela mês para dia.

Neste tipo de modelo, tem-se como principal vantagem, a integridade dos


dados. Também diminui a replicação dos dados, ocupando menos espaço em disco.

Contudo, como em um Data Warehouse o objetivo é agilizar as consultas, é


importante considerar a baixa performance apresentada por este tipo de modelo.

5.9. Arquitetura

Segundo o SEI (Software Engineering Institute), "A arquitetura de software de


um programa ou de um sistema computacional é a estrutura ou estruturas do
sistema, que abrangem elementos de software, as propriedades visíveis destes
elementos, e as relações entre eles". Sintetizando a idéia, o termo arquitetura se
refere a um conjunto de estruturas conhecidas (como programas ou módulos
isolados) que, estruturadas de forma lógica e consistente, podem prover serviços ou
funcionalidades umas para as outras de modo a atingir o objetivo de resolver um
problema que o sistema como um todo se propõe a solucionar.

O projeto da arquitetura de um sistema é de vital importância e muitas vezes


está diretamente relacionado com o sucesso de um produto de software. É na
arquitetura que se define a organização do sistema e como as estruturas trocarão
mensagens ou proverão serviços a outros elementos. Com base nisto, Filho (2004)
comenta que este provimento de serviços é desenhado diretamente no projeto
arquitetural, que se for mal definido, pode afetar diretamente os atributos de

42
qualidade ou os requisitos não funcionais de um sistema tais como desempenho,
portabilidade, confiabilidade, disponibilidade, entre outros.

A partir deste cenário, entende-se que a escolha e a definição da arquitetura


para um sistema de Data Warehouse é fundamental para que se consiga responder
às perguntas que este sistema de apoio a decisão se propõe a esclarecer. Além
disso, por ser um sistema que apoio gerencial, os fatores de qualidade citados
podem ser cruciais para o sucesso neste tipo de sistema.

Segundo Machado (2006), a escolha da arquitetura do projeto de DW, está


baseado em fatores relacionados à infra-estrutura, ambiente do negócio, escopo,
tempo que se tem para se realizar o projeto e a capacitação dos recursos humanos
disponibilizados e projetados para investimento. Neste sentido, é necessário que a
gerência do projeto tenha em mãos estas informações ao planejar a arquitetura
destes sistemas.

5.9.1. Conceito

Para que um Data Warehouse seja útil, ele deve ser capaz de responder a
consultas avançadas de maneira rápida, sem deixar de mostrar detalhes relevantes
às respostas. O estudo de uma arquitetura permite compreender como o DW faz
para armazenar, integrar, comunicar, processar e apresentar os dados que os
usuários utilizarão em suas decisões.

Em [Oliveira,2002], o termo arquitetura Data Warehouse é definido como um


conjunto de estruturas que servem de base para o desenvolvimento do projeto de
um sistema ou produto. Uma arquitetura de dados tem como função primordial a
identificação e o entendimento de como os dados se movimentam e são
organizados dentro de um sistema e de como ele será empregado para o fim a que
se destina.

Neste tipo de sistema há vários aspectos que devem ser considerados


durante o projeto de arquitetura. Alguns exemplos que podem ser citados é a
maneira como a empresa enxerga o Data Warehouse, a forma como os dados são
armazenados fisicamente no banco de dados, o volume de informação que este
sistema deverá tratar. O último aspecto, por exemplo, é de suma importância para a
previsão de recursos que serão necessários no projeto. Neste sentido, os aspectos

43
citados devem ser conhecidos amplamente antes da iniciação de um projeto de
arquitetura.

Estas decisões devem ser tomadas com base nos recursos globais que o
projeto disporá, tais como recursos de infra-estrutura, humanos, orçamentários,
tempo, entre outros. Além destes recursos, há uma série de variáveis que devem ser
levadas em consideração e que são importantes para escolha da melhor arquitetura
para o projeto mencionado.

Para entender melhor as principais arquiteturas relacionadas à tecnologia


DW, serão apresentadas a seguir, três abordagens consideradas as mais
comumente utilizadas sobre o tema segundo Machado (2006). Entretanto, apesar de
existirem outras arquiteturas disponíveis para a implementação destes sistemas,
serão objetos de estudo deste trabalho, a Arquitetura Global, Arquitetura de Data
Mart Independente e a Arquitetura de Data Mart Integrado.

5.9.2. Arquitetura Global

A arquitetura global tem um foco corporativo. Segundo Machado (2006), esta


arquitetura é aquela onde o Data Warehouse suporta as necessidades da empresa
como um todo ou da maior parte destas necessidades. Isso significa que vários
representantes dos sistemas transacionais daquela corporação terão seus dados
transformados e repassados ao DW por meio de processos especiais.

Como exemplo de representantes de sistemas transacionais, pode-se ilustrar


o seguinte cenário em que uma empresa possui seis departamentos dentre os quais
estão o Departamento de Recursos Humanos, Financeiro, Operacional, Jurídico,
Comercial e de Tecnologia. Para o caso exposto, é dito que esta empresa possui um
DW implementado de forma global, quando grande parte dos departamentos
disponibiliza informações de seus sistemas no DW. Neste sentido o DW é
implantado em toda empresa e não somente em um único departamento.

O fato de grande parte de departamentos estarem contemplados no DW,


significa uma maior abrangência de informações sobre questões operacionais da
empresa. A vantagem deste tipo de arquitetura é a possibilidade de cruzamento de
dados de vários departamentos de forma integrada, ou seja, quando se deseja obter
informações sobre diferentes departamentos, não existe a necessidade de
“garimpar” estas informações em diferentes fontes. A partir de uma arquitetura global

44
é possível coletar respostas em um repositório global, em um único momento. Basta
que para isso estas perguntas sejam montadas antecipadamente no ambiente de
consultas DW. Esta integração, em outras palavras significa maior visão da
corporação.

Em Inmon (1997) esta integração dados fontes diversas é comentada por ele
como “Em todo ambiente, informações operacionais não integrados são complexos
e difíceis” e para isso, os sistemas de DW têm suas próprias técnicas para lidarem
com isso. Quando bem projetado, um sistema de DW consegue resolver a questão
de integração de informações utilizando este tipo de arquitetura.

Por contemplar maior parte da companhia, esta arquitetura possui obviamente


um custo de implementação mais elevado. A quantidade de recursos necessários
nas fases de implementação será maior simplesmente pelo fato desta arquitetura
cobrir um escopo mais abrangente da empresa.

Para este tipo de implementação geralmente existe um departamento de


tecnologia que é responsável pela manutenção deste Data Warehouse. Este é um
fato relevante, pois a manutenção destes sistemas será centralizada, evitando
problemas de inconsistências ou de múltiplas interpretações.

Entretanto este conceito não diz respeito a distribuição física do DW, ou seja,
não existe relação do conceito elucidado acima com o fato do sistema ser
fisicamente centralizado ou distribuído em locais diferentes. Por fim é importante
observar que este tipo de arquitetura possui uma complexidade alta.

5.9.3. Arquitetura Data Mart Independente

Arquitetura de Data Mart independente é voltada para grupos ou


departamentos específicos, que desejam obter informações sobre suas próprias
necessidades de forma isolada. Este tipo de arquitetura é totalmente distinto da
arquitetura global e seu escopo são as próprias necessidades do departamento. As
informações contidas neste DW independente não se integrarão com as outras
áreas da empresa. Devido ao escopo mais limitado e são mais identificados com
grupos de necessidades dos usuários, os Data Marts são construídos em
esforço/time concentrado.

O principal objetivo de implantação deste tipo de arquitetura surge da


necessidade de responder a perguntas específicas de um determinado grupo de

45
usuários. Em alguns casos, ela é utilizada para fins demonstrativos por fornecedores
de software como prova de conceito ou para apresentar as principais características
do Data Warehouse.

Neste caso, os dados são extraídos dos sistemas operacionais internos do


departamento, com o auxílio da área de tecnologia da informação e carregados em
um repositório de dados.

Em muitos casos não existe uma manutenção do departamento de tecnologia


para estes Data Marts, ficando esta completamente por sua área responsável.

O custo de implementação de um Data Mart isolado é mais baixo do que a


implementação de uma arquitetura global ou de um Data Mart integrado pelo fato de
possuir um escopo menor que o escopo dos outros dois. Geralmente é reunido um
pequeno conjunto de profissionais que serão responsáveis pela implantação daquele
escopo com base nas necessidades do departamento.

5.9.4. Arquitetura Data Mart Integrado

Esta arquitetura é caracterizada pela implementação separada por


departamento do seu próprio Data Mart e posterior interconexão provendo uma
visão corporativa maior das informações. Os Data Marts integrados mesclam
características da arquitetura Global, pelo fato de sua alta integração de
informações, e também semelhanças da arquitetura Data Mart Independente onde
cada departamento implementa seu DM separadamente.

A vantagem de utilização desta arquitetura é a maior distribuição do trabalho


e de recursos entre departamentos para a consecução do desenvolvimento. Neste
sentido, o custo de administração este tipo de ambiente é mais elevado.
Eventualmente alguns departamentos podem compartilhar das mesmas informações
e esta arquitetura provê suporte a este tipo de compartilhamento. O lado positivo
dessa opção é que se aumenta a capacidade e qualidade de visão corporativa de
informações.

A responsabilidade pela manutenção deste ambiente é delegada ao


departamento de Tecnologia, e a atuação deste nos processos de controle é
essencial para integrar o controle e a administração dos Data Marts.

46
5.10. Abordagem de Implementação

Em projetos de Data Warehouse podem ser utilizados vários tipos de


abordagem de implementação. Entretanto existem dois tipos que são considerados
segundo Machado (2006), substancialmente importantes: Implementação Top-Down
e Botton-Up.

Esta definição está diretamente relacionada a como sistema será


desenvolvido. Se o desenvolvimento for gradativo, situação na qual os Data Marts
evolutivos integrarão o DW na medida em que forem implementados, tem-se uma
abordagem Botton-Up. Quando se opta por uma implementação que engloba o
desenvolvimento do sistema todo e de uma só vez para posterior formação de Data
Marts, ou implementação monolítica tem-se uma implementação Top-Down.

5.10.1. Top-Down

Esta abordagem é muito utilizada como padrão inicial do conceito de DW.


Esta abordagem requer um planejamento e definições conceituais de tecnologia
completos antes de se iniciar o projeto. Isto se dá porque o sistema será construído
de forma monolítica, ou seja, o DW será um construído de forma contínua em um só
bloco, e depois disso servirá de base para a carga de Data Marts.

Elucidando o conceito acima, nessa arquitetura o processo se inicia com a


extração, a transformação e a integração das informações dos sistemas operativos e
dados externos para uma área de armazenagem intermediária ou até diretamente
das fontes operacionais. A seguir, os dados são transferidos para o DW.

Figura 8 – Abordagem de implementação Top-Down [MACHADO, 2007]

47
A escolha da abordagem deve levar em consideração as vantagens e
desvantagens como se observa a seguir:

Vantagens

 Herança de arquitetura - Os Data Marts utilizarão a arquitetura e dados


do DW monolítico;

 Visão de empreendimento - Proporciona uma concentração de todos os


negócios da empresa;

 Repositório de metadados centralizado e simples - Permite


manutenções mais simples do que aquelas realizadas em múltiplos
repositórios; e

 Controle e centralização das regras - Garante a existência de um único


conjunto de aplicações para extração, limpeza e integração dos dados,
além de processos centralizados de manutenção e monitoração.

Desvantagens

 Implementação é muito longa - Nessa abordagem e o desenvolvimento


é feito por áreas de assuntos tais como vendas, finanças, recursos
humanos, entre outros. Neste sentido, são necessários em média quinze
ou mais meses para que a primeira área de assunto esteja em produção;

 Alta taxa de risco - Não existem garantias para o investimento neste tipo
de ambiente;

 Heranças de cruzamentos funcionais – Se trata de um fator negativo,


pois é necessária uma equipe de desenvolvedores e usuários finais
altamente capacitados, para avaliar as informações e consultas que
garantam a empresa habilidade para sobreviver e prosperar; e

 Expectativas relacionadas ao ambiente – Esta questão pode gerar


insatisfação justamente pelo fator demora de implementação, pois isso
pode induzir expectativas nos usuários.

5.10.2. Botton-Up

O fato da implementação Top-Down ser politicamente difícil, ser definida


como cara e demorada, e com ROI (Return of Investment) demorado pode levar a

48
utilização da abordagem de implementação Botton-Up e é bem aceita pelos
executivos pelo fato de possuir um ROI rápido.

Para isso há de se fazer uma análise detalhada das vantagens e


desvantagens de cada implementação para que seja possível calcular qual será a
mais aplicável e vantajosa em um determinado cenário.

Neste caso a implementação permite que o planejamento e o desenho dos


Data Marts possam ser realizados sem esperar que seja definida uma infra-estrutura
corporativa para o DW. A infra-estrutura existirá e será implementada conforme as
Datas Marts forem sendo desenvolvidos.

Elucidando o conceito da abordagem Botton-Up e o seu fluxo, o processo se


inicia com a extração, a transformação e a integração das informações dos sistemas
operativos e dados externos diretamente para um DM específico e lá ficam
armazenados. No contexto empresarial pode existir diversos Data Marts
relacionados com os assuntos da empresa (tais como RH, Financeiro, Operacional).
Após a construção destes DMs eles serão integrados para a composição do Data
Warehouse de forma única.

Figura 9 – Abordagem de implementação Botton-Up [MACHADO, 2007]

Vantagens

 Implementação rápida - Esta é altamente direcionada, permitindo um


desenvolvimento rápido;

49
 Retorno rápido - Permite que o produto mostre rapidamente seu valor e
servindo como base para investimento adicional com nível mais elevado
de confiança;

 Manutenção do enfoque da equipe - Em equipes fixas e subdivididas por


assuntos é mais fácil de manter um foco definido do que quando se tem
uma implementação; e

 Herança Incremental - Na medida em que obriga a entrega de recursos


de informação passo a passo. Isso permite à equipe crescer e aprender,
reduzindo os riscos.

Desvantagens

 Desafio de possuir a visão de empreendimento - De modo a manter um


rígido controle do negócio como um todo pois requer maior trabalho ao
extrair e combinar as fontes individuais do que utilizar um DW; e

 Administrar e coordenar múltiplas equipes e iniciativas - Normalmente


este tipo de arquitetura emprega o desenvolvimento de DM em paralelo.
Isso pode conduzir a uma rígida administração, tentando coordenar os
esforços e recursos das múltiplas equipes, especialmente nas áreas de
regras e semântica empresariais.

5.11. Extração, Transformação e Carga

Segundo Oliveira (2002) a fase de ETL (Extração, Transformação e Carga) é


composta por um conjunto de processos que têm como objetivo coletar as
informações que serão utilizadas no sistema Data Warehouse a partir do ambiente
tradicional (OLTP). De maneira geral, seleciona-se as informações essenciais do
sistema OLTP, realiza transformações e limpeza nos mesmos e logo após as
carrega no ambiente DW.

Conforme o autor citado, esta fase é considerada uma das etapas mais
críticas da construção de um DW. Ela envolve a fase de extração dos dados dos
sistemas transacionais ou de outras fontes tais como flat files (arquivos texto),
planilhas; a fase de filtragem que consiste em garantir a integridade dos dados e a
fase de carga dos dados no DW.

50
Esta fase constitui-se essencialmente em observar os requisitos dos usuários
finais e reproduzir esta especificação na forma de mapeamentos. Este mapeamento
deve dizer onde as informações solicitadas estarão presentes dentro dos sistemas
fonte, quais são as regras de negócio que deverão ser aplicadas e qual deve ser o
destino destes dados no DW.

Durante a movimentação dos dados entre os sistemas transacionais e o DW


tem-se a impressão que nada além de simples extrações de dados de um local para
outro está ocorrendo. Em função disto, muitas vezes as empresas acabam perdendo
tempo e dinheiro por ter de refazer toda a parte de extração.

O desafio por trás disso não é técnico e sim gerencial, pois não é fácil
automatizar estas tarefas. Especialistas afirmam que identificar fontes, definir regras
de transformação e detectar e resolver questões de qualidade e integração
consomem cerca de 80% do tempo de projeto. Além disso, existem outros fatores
influentes na estimativa de tempo para estas tarefas, tais como o grande número de
fontes e a qualidade dos metadados mantidos sobre estas fontes.

5.11.1. Melhores Práticas

Segundo Kimball (1998) são necessários onze etapas para extração dos
dados de produção para o DW que são consideradas melhores práticas no
desenvolvimento deste tipo de sistema.

As etapas são as seguintes:

1. Extração primária (Ler o formato legado);

2. Identificação dos registros modificados;

3. Generalização de chaves para dimensões e modificação;

4. Transformação em imagens de registro de carga;

5. Migração do sistema legado para o sistema de Data Warehouse;

6. Classificação e construção de agregados;

7. Generalização de chaves para agregados;

8. Carregamento;

9. Processamento de exceções;

51
10. Garantia de qualidade; e

11. Publicação.

O processo de carga dos dados passa por algumas etapas: extração (envolve
os passos 1, 2 e 3), transformação (passos 4, 5, 6 e 7), carga (passos 8 e 9)
propriamente dita e homologação (passos 10 e 11).

5.11.2. Extração

O processo de Extração de Dados de um ambiente de produção transacional


para o Data Warehouse muitas vezes requer adaptação às tecnologias já existentes
nestes sistemas transacionais. O fato é que os sistemas transacionais podem
apresentar-se implementados utilizando diversas tecnologias de gerenciamento de
banco de dados.

Um exemplo desta heterogeneidade é o fato que muitas vezes, os dados são


transferidos de um banco de dados hierárquico, como o Adabas, para uma nova
tecnologia de SGBD para Data Warehouse, tal como o Oracle. Não menos comum é
a utilização de arquivos texto (flat files) que utilizam algum símbolo textual específico
como delimitador de colunas e que são utilizados como fonte para o DW. Estes flat
files comumente são gerados a partir dos dados de um repositório especifico e
disponibilizados para que sejam usados como fonte para os processos de Extração
DW.

Segundo Inmon (1997) algumas funcionalidades são necessárias durante a


fase de extração dos dados:

 A seleção de dados do ambiente operacional pode ser muito complexa,


pois muitas vezes é necessário selecionar vários campos de um sistema
operacional para compor um único campo no Data Warehouse;

 Os dados são re-formatados. Por exemplo: um campo data do sistema


operacional do tipo DD/MM/AAAA pode ser passado para o outro sistema
do tipo ano e mês como AAAAMM;

 Podem existir várias fontes de dados diferentes para compor uma


informação. Ela pode ser oriunda de uma planilha Excel enquanto uma
outra que serviria para compor um mesmo fato viria de um arquivo texto;

52
 Quando há vários arquivos de entrada, a escolha das chaves devem ser
feitas antes que os arquivos sejam intercalados. Isso significa que se
diferentes estruturas de chaves são usadas nos diferentes arquivos de
entrada, então se deve optar por apenas uma dessas estruturas;

 Os arquivos devem ser gerados obedecendo a mesma ordem das colunas


estipuladas no ambiente de Data Warehouse;

 Pode haver vários resultados. Dados podem ser produzidos em diferentes


níveis de resumo pelo mesmo programa de criação do Data Warehouse;

 Valores padrões devem ser fornecidos. Às vezes pode existir um campo


no Data Warehouse que não possui fonte de dados, então a solução é
definir um valor padrão para estes campos;

 Data Warehouse espelha as informações históricas necessárias, enquanto


o ambiente operacional focaliza as informações correntes; e

 Volumes massivos de entrada devem ser levados em consideração.


Quando há somente uma pequena quantidade de dados de entrada,
diversas opções de projetos podem ser conciliadas. Mas quando há
muitos registros de entrada, opções especiais de projeto (como cargas em
paralelo ou leituras em paralelo) talvez tenham que ser empregadas.

5.11.3. Transformação

Seguindo o fluxo ETL existem os processos de transformação. Após a etapa


de Extração dos dados é necessária uma definição de qual deverá ser o formato de
armazenamento dos dados no Data Warehouse. Existe a necessidade de filtrar os
dados para colocá-los no padrão definido.

Esta etapa tem como um dos objetivos padronizar a informação vinda de


diversas fontes de dados de forma a apresentar os dados de maneira homogênea. O
objetivo disso é evitar várias interpretações que podem ser causadas pela existência
da mesma informação com um formato diferente. Este passo garante que
informações cruzadas de vários sistemas tenham um sentido único.

Um exemplo simplório desta padronização se dá quando se considera um


sistema operacional onde existe o campo de sexo sendo preenchido como “F” ou
“M” e em outro sistema tem-se este mesmo dado está sendo preenchido como “0”

53
ou “1”. É, justamente, nesta hora que entra a parte de transformação, que remodela
todos estes dados para o padrão definido.

Outro objetivo da etapa é o de fazer com que as regras de negócio sejam


carregadas no DW. O objetivo disso é fazer com o que o DW possa refletir com
fidelidade a realidade dos processos da empresa.

Exemplo deste cenário é quando em um sistema transacional se tem uma


informação para um cálculo contábil de desconto de determinado imposto sobre o
salário de um empregado. Para o caso desta regra de negócio específica, é
necessário fazer uma transformação matemática envolvendo cinco campos do
banco de dados, utilizando somas, percentuais, divisões. Para que esta informação
seja reproduzida de maneira correta dentro do DW é preciso que esta regra de
negócio seja implementada corretamente durante o processo de transformação de
dados.

Por fim o processo de transformação de dados é responsável por implementar


rotinas que tornem os dados homogêneos à medida que estes dados são filtrados e
limpos e também é responsável pela implementação da lógica do negócio para que
os processos dos sistemas transacionais sejam refletidos dentro do Data
Warehouse.

5.11.4. Carga

Esta se trata da ultima etapa do processo, onde os registros são efetivamente


gravados no banco de dados DW.

Há algumas maneiras em que a informação pode ser inserida no DW, por


meio de um registro por vez, por meio de uma interface de linguagem, ou em massa
com a ajuda de um utilitário. Em geral, a carga de dados por meio de um utilitário é
mais rápida. Em alguns casos, convém declarar a parte de índices após toda a
carga inicial do Data Warehouse.

A carga também pode ser incremental ou total. A carga incremental


normalmente é feita para tabelas fatos e a carga por cima dos dados é feita em
tabelas dimensões onde o analista terá que apagar os dados existentes e incluí-los
novamente. Este processo de carga incremental para as dimensões normalmente
acontece devido os usuários já estarem com o arquivo pronto, que foi gerado a partir

54
da extração dos operacionais. No entanto, se a modificação for apenas de inclusão
de um registro, deve ser feito diretamente no Data Warehouse.

Caso a carga não seja possível, por problemas de obtenção dos dados
necessários, o Data Warehouse se tornará inutilizável.

5.11.5. Ferramentas

Segundo Oliveira (2002), existem algumas categorias de ferramentas ETL


conforme descrito na figura a seguir:

55
Figura 10 – Tabela de ferramentas segundo [OLIVEIRA, 2002]

5.12. OLAP

Online Analiytical Processing (OLAP) é um conjunto de ferramentas que


possibilitam a análise e exploração das informações contidas em um Data

56
Warehouse de maneira multidimensional ao invés de tabelas representando um
conjunto de tecnologias projetadas para suportar análise e consultas ad hoc que
segundo Inmon (1994) “são consultas com acesso casual único e tratamento dos
dados segundo parâmetros nunca antes utilizados, geralmente executado de forma
iterativa e heurística”.

Segundo Machado (2006) este tipo de ferramenta permite ao usuário analisar


o porquê dos resultados obtidos. Atualmente existe disponível no mercado uma
variedade dessas ferramentas com diferentes abordagens.

Estas ferramentas basicamente têm o papel de fazer interface entre o usuário


e o sistema gerenciador de banco de dados. Entende-se por usuário tanto o
desenvolvedor que é o profissional responsável pela criação das consultas, quanto
os usuários finais os quais a solução é direcionada. Elas têm a habilidade de
simplificar o processo de desenvolvimento, o gerenciamento de metadados, o
processo de consulta dos usuários, entre outros.

5.12.1. Características das ferramentas OLAP

Por meio do modelo multidimensional é possível fazer uma grande


diversidade de combinações que possibilitam a extração das informações conforme
necessidade. Estas informações ajudam analistas e executivos a sintetizarem
informações sobre a empresa, utilizando comparações, visões personalizadas,
análise histórica e projeção de dados em vários cenários de "e se..." entre outras
funções estatísticas e financeiras por ser mais natural, fácil e intuitiva, permitindo a
visão em diferentes perspectivas dos negócios da empresa, fazendo com que o
analista seja um explorador da informação.

Sistemas OLAP são implementados para ambientes multi usuário, arquitetura


cliente-servidor oferecendo respostas rápidas e consistentes às consultas iterativas
executadas pelos analistas, independente do tamanho e complexidade do banco de
dados.

Segundo Machado (2007) a arquitetura OLAP possui três componentes


principais:

 Um modelo de negócios para análises interativas, implementado numa


linguagem gráfica que permite diversas visões e níveis de detalhes dos
dados;
57
 Um motor OLAP para processar consultas multidimensionais contra o
dado-alvo; e

 Um mecanismo para armazenar os dados a serem analisados. A base de


dados usada define se o pacote é um ROLAP, que interfaceia(?) com um
banco de dados relacional de mercado, ou um MOLAP, que se liga a um
servidor OLAP, usando um banco de dados multidimensional e dedicado.

Machado (2006) diferencia as variações de ferramentas OLAP como segue


observado a seguir:

 ROLAP (Relational OLAP) – é um produto relacional OLAP que


possibilita a análise multidimensional de dados, agrega e armazena dados
em um SGBDR – Sistema Gerenciador de Banco de Dados Relacional. O
processamento multidimensional pode ser feito dentro do SGBDR, ou na
camada de servidor ou no cliente;

 MOLAP (Multidimensional OLAP) – é um banco de dados


multidimensional. Um produto que pode armazenar e processar dados
multidimensionais;

 HOLAP (Hibrid OLAP) – é um produto de OLAP híbrido que pode prover


análise multidimensional e simultaneamente de dados armazenados em
um banco de dados multidimensional e em um banco de dados relacional;
e

 DOLAP (Desktop OLAP) – ferramentas OLAP voltadas para


computadores pessoais. Este tipo de ferramenta vem sendo mais
empregado nos bancos de dados individuais para análises mais
específicas do que as realizadas no DM. Os dados, normalmente, são
carregados a partir de DM.

5.12.2. Operações Básicas OLAP

As operações OLAP são executadas basicamente por aplicativos para


usuários finais que possuem acesso de leitura das bases de dados a fim de
extraírem e manipularem o layout das informações para seus relatórios de forma que
estes respondam às suas questões gerenciais.

58
Essas ferramentas surgiram juntamente com os sistemas de apoio à decisão
(DSS – Decision Suport System) para fazerem consulta e análise dos Data
Warehouses e Data Marts, apoiando o usuário final nas suas atividades, tais como
slice and dice e drill, onde as operações drill utilizam a navegação nos dados,
modificando o nível da granularidade da consulta e para navegar nas dimensões são
utilizados as operações de slice and dice.

Segundo Machado(2007) as principais operações OLAP são:

 Drill Down e Roll Up - método de exploração de dados detalhados que


foram usados na criação de um nível sumarizado de dados ao longo dos
níveis hierárquicos de uma dimensão. O Drill Down ocorre quando o
usuário aumenta o nível de detalhe da informação, diminuindo o nível de
granularidade; e

 Drill Up ou Roll Up – é o inverso, ocorrendo quando o usuário aumenta o


nível de granularidade, diminuindo o nível de detalhamento da informação.
Com a capacidade do drill o usuário pode navegar do mais alto nível até o
nível mais detalhado.

Já com a capacidade de roll up o usuário pode navegar no nível de


detalhe até o mais alto nível de sumarização dos dados. Os quais os
níveis de aprofundamento dependem da granularidade dos dados
existentes no Data Warehouse;

 Drill Across - ocorre quando o usuário pula de um nível intermediário


dentro de uma mesma dimensão, desde que ambos tenham algumas
dimensões em conformidade, ou seja, as mesmas dimensões estão
compartilhadas;

 Drill Through - está relacionado com o fato de se desejar uma informação


num nível de detalhe menor do que aquele colocado na tabela fato e
permitido pela sua granularidade. Em um Data Mart onde trabalha com
informações sumarizadas no nível de Linha de Produtos e deseja baixar o
nível, onde este nível menor é encontrado no Data Warehouse (havendo
compatibilidade entre os dois ambientes). Neste caso, a ferramenta OLAP
irá efetuar um Drill Through e buscar esta informação no ambiente de DW;
e

59
 Slice And Dice - é uma das principais características de uma ferramenta
OLAP. Como a ferramenta OLAP recupera o micro cubo, surgiu a
necessidade de criar um módulo que se convencionou de Slice and Dice
para ficar responsável por trabalhar esta informação, servindo para
modificar a posição de uma informação, alterar linhas por colunas de
maneira a facilitar a compreensão dos usuários e girar o cubo sempre que
tiver necessidade.

Com o Slice and Dice é possível analisar as informações de diferentes


prismas limitados somente pela imaginação e agindo como um filtro.
Utilizando esta tecnologia é possível visualizar a informação sobre ângulos
que anteriormente inexistiam sem a confecção de um Data Warehouse e a
utilização de uma ferramenta OLAP.

De maneira simplista, significa a redução de escopo das informações em


análise, mudando a ordem das dimensões e a orientação de acordo com a maneira
que os dados são visualizados.

5.13. Metadados

Uma parte importante do Data Warehouse são os Metadados, também


chamados de dados sobre os dados e índice do conteúdo de um DW. Possui um
mapeamento de que modo os dados foram extraídos das fontes operacionais e
como estão sendo inseridos no DW. Os metadados definem os tipos de dados e
descrevem os dados de negócio, não apenas o conteúdo do DW, mas também
informações úteis para o julgamento da qualidade do conteúdo.

Em um projeto de Data Warehouse, o processo de metadados deve gerar e


gerenciar uma documentação sobre o levantamento de dados, do banco de dados,
a origem dos dados que alimentam o DW, processos de extração , tratamento e
rotinas de cargas dos dados, as regras de negócios da empresa e todas as suas
mudanças.

Os metadados podem surgir de vários locais no decorrer do projeto e


permitem ao usuário transformar os dados crus em informações que gerem
conhecimento e tragam vantagem competitiva.

O coração da arquitetura do ambiente de BI (Business Intelligence) é o Data


Warehouse, e no seu centro nervoso estão os metadados, sendo considerado o

60
DNA do DW. Sem Metadados, o Data Warehouse e seus componentes nesta
arquitetura, são meramente componentes deslocados, trabalhando
independentemente e com metas diferentes.

Para alcançar harmonia e unidade entre os diferentes componentes no


ambiente de Data Warehouse, é necessário ter uma bem definida e disciplinada
integração com metadados.

Segundo Machado (2007), os metadados são classificados conforme descrito


a seguir:

 Metadados Técnicos – Os metadados técnicos fornecem aos


desenvolvedores e aos usuários técnicos de sistemas de suporte à
decisão a confiança de que os dados estão corretos. Eles são críticos para
a manutenção e o crescimento contínuo do DW; e

 Metadados de Negócio – Estes metadados são o elo de ligação entre os


usuários de negócios (executivos e analistas de negócios) e o DW. Os
metadados de negócios mostram que relatórios, consultas e dados estão
no DW, a localização dos dados, confiabilidade dos dados, contexto dos
dados, regras de transformação que foram aplicadas e as origens desses
dados.

5.13.1. O Data Warehouse e o modelo de dados

No ambiente do Data Warehouse, Inmon (1997) destaca três modelos de


dados: corporativo (genérico), operacional (aplicações operacionais) e analítico
(Data Warehouse). O modelo corporativo de dados contém primitivas básicas sobre
o tipo de dados necessários para a corporação. Os outros dois modelos (operacional
e analítico), são derivações do modelo corporativo.

5.13.2. Padrões para Metadados

Atualmente existem vários padrões para descrever metadados, como The


Text Encoding Initiative (TEI), Metadata Encoding and Transmission Standard
(METS), Metadata Object Description Schema (MODS), The Encoded Archival
Description (EAD) e MPEG-7. Entretanto o padrão de metadados Dublic Core é o
principal dentre eles. Essas duas instituições (OCSC e NCSA) realizaram um

61
workshop em Dublin, Ohio no ano de 1995. Os trabalhos continuaram a serem
desenvolvidos e gerenciados pelo DCMI.

Ele tem como objetivo definir um grupo de elementos que possam ser usados
por autores para descrever seus próprios recursos na Web. Isso ocorreu devido a
grande incapacidade das bibliotecas eletrônicas de catalogar todos esses recursos,
que atualmente são muitos na Web. O objetivo era definir poucos elementos e
algumas regras para serem usadas nos recursos não catalogados. O DCMI tem uma
definição própria que diz: “Dedicado a promover a adoção difundida de padrões
interoperacionais de metadados e a desenvolver vocabulários especializados de
metadados para sistemas de busca”.

5.13.3. Dublin Core

Inicialmente, o padrão Dublin Core possuía treze elementos, agora são


quinze: Title, Creator, Subject, Description, Publisher, Contributor, Date, Type,
Format, Identifier, Source, Language, Relation, Coverage, Rights.

Entretanto o Dublin Core passa por um problema: o de qualificar ao máximo


suas descrições ou continuar simples e conciso. Se tornar qualificado pode trazer
várias vantagens para esse padrão. Um bom exemplo disso é o elemento data, ele
pode com outro significado, como identificar as data de alteração de um documento
seguindo um padrão ISO (o qual definiu representação para data e hora).

Todos os elementos do Dublin Core são opcionais e todos são repetíveis. Os


elementos podem ser apresentados em toda a ordem. Os valores dos elementos
não possuem um padrão. Entretanto, Dublin Core recomenda que use alguns
valores controlados para campos apropriados, como Subject. O Dublin Core apenas
recomenda isso, não é obrigatório. Por esse motivo alguns grupos vêm trabalhando
para definir algum padrão para definir os campos (resource Type).

Embora tão padrão tenha sido criado para descrever documentos Web,
passou a ser usada em aplicações mais complexas, devido a sua eficiência e
simplicidade. Pesquisadores, museus e músicas utilizam o padrão Dublin Core.

62
5.13.4. TEI

O TEI, que significa iniciativa de codificação de textos, é um projeto


internacional que busca desenvolver padrões para caracterizar textos eletrônicos
como peças, poesias, novelas, entre outros.

Primeiramente tem como finalidade possibilitar a pesquisa para a população,


pretendendo chegar a estabelecer um padrão para a codificação de textos, o padrão
do TEI também especifica um cabeçalho, que traz metadados sobre o próprio texto.

5.13.5. METS

Foi desenvolvido com o intuito de suprir a necessidade de padrões para


estruturação de dados em objetos complexos de bibliotecas digitais. O METS é um
XML Schema para criação de documentos XML que expressam a estrutura de
objetos de bibliotecas digitais, a descrição associada e metadados administrativos,
além do nome e da localização do objeto digital.

5.13.6. EAD

Foi criada para servir como uma forma de caracterizar estruturas de arquivos,
para que estes arquivos pudessem ser procurados e mostrados na internet. Assim
como o TEI a EAD trás um cabeçalho que descreve a estrutura de arquivo, e segue
descrevendo a coleção, podendo trazer apontadores para objetos digitais.

A EAD e bastante popular em bibliotecas acadêmicas, sociedades de história,


e museus com grandes coleções. A EAD acaba tornando possível a disposição de
peças únicas na internet.

5.13.7. RDF

O padrão RDF foi desenvolvido pela W3C. É um modelo de dados para


descrição de recursos na Web. Serve como um mecanismo para integração de
múltiplos esquemas de metadados. Possui um namespace o qual é definido por uma
url, apontando para a descrição do esquema de metadados usado. Pode haver
vários namespaces apontando para vários esquemas usados ao mesmo tempo,
geralmente expressos em XML.

63
5.14. Ciclo de Vida de Desenvolvimento

Segundo Inmon (2005), é preciso ver como o dado operacional é usualmente


orientado a aplicação e as suas conseqüências, como a falta de integridade,
enquanto dados de Data Warehouse são integrados. Outra diferença existente entre
o nível operacional de dado e processamento e o nível de DW de dado e
processamento. O ciclo de vida de desenvolvimento subjacente destes sistemas
pode causar profunda preocupação.

Figura 11 – O Ciclo de Vida do desenvolvimento de sistemas [INMON, 2005]

A figura 10 mostra que o Ciclo de vida de desenvolvimento de sistemas


clássico (quadro à esquerda) é praticamente o oposto do ciclo de vida de
desenvolvimento de DW (quadro à direita)

64
5.14.1. Fases para um projeto Data Warehouse

Com o intuito de oferecer software de qualidade aos compradores, muitas


vezes é preciso estabelecer quais serão as fases para a construção de um
determinado produto. O planejamento destas fases é de vital importância, pois a
partir dele é possível determinar uma série lógica de atividades que deverão ser
executadas para a construção deste software. As atividades deverão ser totalmente
claras e compreensíveis para toda equipe de projeto com o objetivo de construir o
produto certo e da maneira certa.

Neste sentido Barbiere (2001) sugere um conjunto de fases para o


desenvolvimento de sistemas Data Warehouse e Data Mart. Estas fases são
mostradas de forma macro a seguir e explicadas ao longo deste tópico da pesquisa.
Estas fases ajudam a equipe de desenvolvimento na medida em que a norteiam em
relação às principais atividades a serem executadas durante a construção do
DW/DM. As fases por Barbiere (2001) são:

 Planejamento;

 Levantamento das necessidades;

 Modelagem dimensional;

 Projeto físico dos banco de dados;

 Projeto de ETL;

 Desenvolvimento de aplicações;

 Validação e Teste;

 Treinamento; e

 Implantação.

A seguir estas fases são explicadas detalhadamente.

5.14.1.1. Levantamento das Necessidades

Nesta etapa deverão ser identificados dois modelos. O primeiro modelo é o


modelo Dimensional, ou aquele que representa os blocos conceituais de dados
necessários ao alcance dos objetivos do sistema de suporte a decisão. O outro
modelo é relacionado com as fontes das informações. É o modelo Fonte dos Dados.

65
Nele deverão ser registrados os blocos conceituais de dados existentes, com suas
respectivas descrições e formas atuais de armazenamento e de uso nos sistemas.

5.14.1.2. Modelagem

A modelagem de dados é seguramente um dos fatores críticos de sucesso


em um projeto de DW e pode representar a fronteira entre o seu sucesso e o seu
fracasso. Os volumes brutos dos dados deverão ser cuidadosamente considerados
no projeto, visando ao processamento para obtenção das informações sumarizadas
e consolidadas.

5.14.1.3. Projeto Físico

Nessa etapa serão desenhadas as estruturas lógicas do modelo dimensional,


com as definições das tabelas fatos e dimensões, relacionamentos, indexação,
atributos de tabelas e implantação de regras.

5.14.1.4. Projeto ETL

Nessa etapa deverão ser definidos os processos requeridos de transformação


do modelo fonte para o modelo dimensional. Segundo Barbiere (2001), os conceitos
de extração dos dados e de seu tratamento podem ser divididos em:

 Filtro de Dados – Relaciona os procedimentos e condições para se


eliminar os elementos de dados indesejáveis no modelo dimensional;

 Integração dos Dados – Define a forma de se correlacionar informações


existentes de formas distintas e que deverão ser integradas no sistema
gerencial;

 Condensação dos Dados – Define forma de se reduzir volumes de dados


visando a obter informações resumidas e sumarizadas;

 Conversão de Dados – Define os procedimentos para se transformar


dados em unidades, formatos e dimensões diferentes; e

 Derivação de Dados – Define os meios e fórmulas para se produzir dados


virtuais, a partir de dados existentes.

66
5.14.1.5. Desenvolvimento das Aplicações

Nessa etapa será projetado o sistema aplicativo, objeto do trabalho. As


ferramentas devem ser de fácil utilização e devem priorizar a interface Web,
facilitando o acesso aos dados via browser.

5.14.1.6. Validação e Teste

Fase em que o sistema é testado e validado, considerando-se o máximo


possível, as simulações de volume e de processamentos.

5.14.1.7. Treinamento

O grupo objeto do treinamento deverá ser formado prioritariamente de


usuários voltados para atividades de negócios, além de gerentes das áreas
envolvidas.

5.14.1.8. Implantação

A implantação deverá ser seguida de um rigoroso acompanhamento de uso


das aplicações disponibilizadas. Os usuários devem ser estimulados a apresentar
criticas e sugestões de melhorias para as próximas versões do sistema.

Em paralelo com as etapas descritas anteriormente, acontecerá a construção


do diretório de metadados do projeto.

5.14.2. Problemas Comuns de Desenvolvimento

Alguns problemas podem ocorrer durante o desenvolvimento de um sistema


DW. Para ajudar o gerente do DW a detectá-los, Barquini (1996) antecipa os
problemas mais comumente encontrados:

 Iniciação do projeto sem o comprometimento da diretoria da


companhia – Para que o projeto de DW tenha sucesso e continuidade é
necessário que a alta diretoria esteja comprometida com o projeto,
garantindo as verbas necessárias e ajudando a direcionar o foco do DW
para o negócio da organização;

 Levantar expectativas prometendo o que não é possível de ser


cumprido – Frases do tipo "O DW guiará os gerentes para as melhores
decisões" podem causar tanto desconfiança no projeto quanto desprezo.
O DW não mostrará as melhores decisões, mas sim respostas às

67
consultas efetuadas. Cabe aos usuários elaborar consultas inteligentes e
analisar as respostas obtidas;

 Carga de dados desnecessários dentro do DW – Nem todos os dados


disponíveis nos sistemas transacionais da organização são
necessariamente úteis para o DW. O arquiteto dos dados deve analisar,
junto aos usuários, quais os dados que realmente contêm informações
necessárias e desprezar aqueles que não fazem parte dos objetivos do
DW;

 Confundir o projeto do banco de dados DW com o projeto de um


sistema transacional – Em um processo transacional, o projeto deve
fornecer velocidade de acesso e facilidades na atualização de registros. O
DW é fundamentalmente diferente. A meta no DW são acessos
agregados, ou seja, somas, médias, tendências, entre outros. Outra
diferença entre os dois tipos de sistemas é o tipo de usuário. Nos sistemas
transacionais um programador desenvolve uma consulta que poderá ser
utilizada milhares de vezes. No DW o usuário final desenvolve suas
consultas que podem ser utilizadas somente uma vez;

 Optar por gerente técnico de Data Warehouse – Escolher um gerente


para o DW com orientação técnica: O DW é essencialmente uma
prestação de serviços e não um serviço de armazenamento de dados, por
isso é fundamental que o gerente do DW seja uma pessoa voltada aos
interesses dos usuários e, principalmente, que fale a mesma “língua”
deles;

 Grande foco em dados do tipo registros – Muitas vezes os projetos de


DW partem do princípio de que as informações necessárias ao bom
desempenho do DW estão somente em forma de registros nos arquivos
dos sistemas transacionais da organização. Isto pode ser um equívoco, já
que muitas informações podem estar armazenadas fora dos sistemas
transacionais, em forma de textos, imagens, sons e vídeos;

 Crer nas promessas de performance, capacidade e escalabilidade


dos fornecedores – A informática cresce de uma maneira muito rápida,
isto também acontece com o tamanho do DW, portanto é interessante

68
fazer um estudo de crescimento do DW antes de definir a configuração
que deve atender, com folga, o banco de dados do DW, pelo menos até a
conclusão do projeto inicial. É interessante que o servidor do banco de
dados do DW seja fornecido por uma organização idônea e que garanta
futuras expansões; e

 Crer que ao término do projeto e a subida para a produção resolverá


todos os problemas – Assim que o DW começar a rodar, os usuários
começarão a criar mais consultas e estas consultas necessitarão de novos
dados que resultarão em novas consultas. Assim, o projeto do DW precisa
ser atualizado continuamente, não só com novos dados, mas também com
novas tecnologias.

5.14.3. Recursos Humanos

Segundo Inmon (1999) para criar e manter um Data Warehouse é necessário


desenvolver uma série de funções. Dependendo do tamanho do projeto e do tipo de
tecnologia utilizada podem ser necessárias várias pessoas para realizar as
diferentes funções previstas e, ao mesmo tempo, deve-se manter a equipe de Data
Warehouse relativamente pequena, para que possa responder de maneira rápida às
necessidades de informação em constante mudança em toda organização.

A maneira mais eficaz de arquitetar um DW que transforme dados em


informação é ter, na equipe, funcionários que já fazem parte da organização, com
habilidades de negócios necessárias para executar certas funções. Estas funções
podem variar conforme o estágio em que se encontra o DW, bem como podem ser
agrupadas para que uma só pessoa realize várias delas ao mesmo tempo.

Inmon (1999) sugere o quadro a seguir para o desenvolvimento inicial de um


Data Warehouse:

Tabela 5 – Quadro de funcionários sugeridos para desenvolvimento inicial de um DW [INMON, 1999]

Ftes1
Função Descrição Mínimos
Iniciais

1
Full Time Equivalents – Funcionários equivalentes em tempo integral.

69
Gerencia o projeto total, desde
Administrador de
incursão na implementação inicial ate 1
Data Warehouse
manutenção e iterações adicionais.

Gerencia as expectativas e
Gerente de Mudança percepções da organização quanto ao
Organizacional de Data Warehouse, suas capacidades, Menos de 1
DW limitações e o impacto em todos os
aspectos da organização

Cria e gerencia o(s) banco(s) de


Administrador de
dados físicos que compõe(m) todos os 1
Banco de Dados
níveis e aspectos do Data Warehouse

Gerencia metadados de negócios e


Gerente de técnicos, assegurando que estejam
Menos de 1
Metadados atuais, precisos e adequadamente
integrados

Identifica e analisa as
Analista de
necessidades de informação de negócios
necessidades de 2
da organização e auxilia no projeto do DW
negócios
para satisfazer essas necessidades

Cria e mantém os modelos de


dados para todos os níveis do DW.
Arquiteto de Data
Analisa sistemas de origem para 1
Warehouse
determinar sistema(s) de registro. Projeta
aquisição de dados e ambiente técnico

Cria e mantém programas e


Desenvolvedor de processos que executam a extração,
1a3
Aquisição de Dados transformação e carga de dados das
origens até os alvos

70
Cria e mantém programas e
Desenvolvedor de processos e “caminhos” predefinidos que
1a3
Acesso a Dados permitem que usuários finais acessem
dados do DW

Cria e mantém programas e


processos e procedimentos para executar
Desenvolvedores de
tarefas de manutenção como 1
Manutenção de DW
arquivamento, recuperação, segurança,
monitoração, entre outros.

Responsável pelo suporte ao 1 (Não é


Responsável
projeto de DW em termos de fornecimento uma tarefa
executivo de Sistema
de fundos, recursos e de representação de tempo
de Informação
frente aos seus colegas de alto escalão. integral)

Monitora e assegura qualidade de


Analista de Qualidade Mais do que
dados no DW que satisfaça as
de Dados 1
necessidades da organização

Tabela 6 – Quadro de Funcionários de SI sugerido para Gerenciamento Contínuo de DW[INMON


1999]

Função FTEs Adicionais por Iteração

Lideres de equipe podem ser


requeridos se a funcionalidade do DW
Administrador de Data Warehouse
crescer a um tamanho que os torne
necessários.

Gerente de Mudança Organizacional de Possivelmente 1 após diversas


DW iterações.

Até 1 para cada 2 ou 3 iterações


Administrador de Banco de Dados
adicionais.

71
Mínimo de 1 após a primeira interação
Gerente de Metadados
e as seguintes.

2 adicionais após a implementação


Analista de necessidades de negócios inicial; até 1 para cada duas ou três
iterações seguintes.

Mínimo de 1 após a primeira iteração e


Arquiteto de Data Warehouse
as seguintes.

Até 1 para cada uma ou duas novas


iterações e para a sua manutenção,
Desenvolvedor de Aquisição de Dados
dependendo do crescimento da
demanda de usuários.

Até 1 para cada uma ou duas novas


iterações e para a sua manutenção,
Desenvolvedor de Acesso a Dados
dependendo do crescimento da
demanda de usuários.

0 a 1 após diversas iterações,


Desenvolvedores de Manutenção de
dependendo da complexidade das
DW
funções de manutenção.

Responsável executivo de Sistema de 0 (nenhum recurso adicional


Informação necessário)

Possivelmente 1 ou mais após a


iteração inicial, dependendo da
qualidade de dados dos novos
Analista de Qualidade de Dados
sistemas de registro e da qualidade
apresentada por sistemas de registro
existentes.

A equipe de projeto do Data Warehouse será tipicamente composta de doze a


quinze pessoas que serão responsáveis por criar um Data Warehouse na
organização. Inmon (1999) sugere que a equipe ideal deve ser composta de

72
projetistas de banco de dados, de pessoas que conheçam bem os sistemas legados
por dentro e por fora para a extração dos dados necessários para o Data Warehouse
(arqueologistas de dados), programadores de sistemas para assegurar que os
dados dos sistemas legados movam-se de forma limpa e repetitiva pelo Data
Warehouse, usuários, instrutores e administradores de Data Warehouse, que em
geral, são responsáveis pela coordenação de todos os aspectos do projeto de DW e
por equilibrar as necessidades e objetivos de todos os interessados.

6. Protótipo – Validação da Pesquisa


Baseado na pesquisa realizada foi elaborado um protótipo para aplicação dos
conceitos aqui apresentados em uma necessidade real.

Este protótipo tem o objetivo de solucionar o problema da falta de um sistema


gerencial para análise das informações obtidos a partir da base de dados
transacional da Escola Tangran.

O desenvolvimento de um Data Mart supre a necessidade da alta gerência da


Escola em responder questões gerenciais relacionadas ao desempenho de alunos,
professores e da Escola em si, de acordo com os dados obtidos nos sistemas
transacionais.

A metodologia utilizada para o desenvolvimento deste protótipo segue as


fases sugeridas por Barbiere (2001) que foi apresentado anteriormente.

Segue adiante o desenvolvimento do protótipo conforme as fases definidas


para o projeto de um DW/DM.

6.1. Planejamento

O escopo do projeto limita-se análise de questões de ocorrências de


professores e alunos, desempenho e como a freqüência dos responsáveis tem
influenciado no desempenho destes alunos. Estas questões são detalhadas no
tópico seguinte.

O Data Mart será desenvolvido utilizando a abordagem evolutiva ou Bottom-


up e poderá ser integrado, futuramente, a outros Data Marts a fim de formar um Data
Warehouse.

73
Os recurso utilizados para a criação deste protótipo foi descrito no item 3.4 do
presente trabalho, mas em geral vai contar com:

 O Sistema Gerenciador de Banco de Dados adotado será o Oracle


Database Server 9i, e a ferramenta de ETL será o Oracle Warehouse
Builder, montado em uma máquina HP DV4000 com 1 processador
Centrino 2 GHz, 1GB de memória RAM, 80 GB de espaço interno; e

 A ferramenta que será utilizada para apresentação do Front End será o


Oracle Discoverer, montada em um segundo equipamento HP DV1000
com 1 processador de 2 GHz, 1GB de memória RAM, 120 GB de espaço
em disco.

6.2. Levantamento de Necessidades

Existe a necessidade de informações gerenciais automatizadas e mais


precisas para fornecimento de um subsidio confiável à tomada de decisão. Foi
adotada uma granularidade de dados bimestral devido ao fato de que avaliações
marco, tanto sobre a escola quanto sobre alunos, são feitas obedecendo a períodos
de dois meses. Nesta etapa serão identificados dois modelos: O modelo
dimensional e o modelo fonte dos dados.

Durante a fase inicial, foram identificadas algumas necessidades junto a alta


diretoria da escola sobre questões que deveriam ser respondidas por meio da
implementação do sistema Data Warehouse, listadas a seguir:

 Nível de ocorrências por professor – No sistema OLTP existem


ocorrências sobre diversos fatos relacionados aos alunos. Estas
ocorrências são registradas por professores e armazenadas nos sistemas
de banco de dados;

 Desempenho escolar por ano (notas por ano) – As notas a respeito das
diversas disciplinas lecionadas na escola são armazenadas nos sistemas
transacionais. Deseja-se acompanhar o desempenho da escola em geral
por meio das notas dos alunos nestas diversas disciplinas; e

 Desempenho do aluno na disciplina por professor – As notas a


respeito das diversas disciplinas lecionadas na escola são armazenadas

74
nos sistemas transacionais. Deseja-se acompanhar o desempenho dos
alunos na disciplina de determinado professor.

Com base nestes requisitos e com o que há disponível no sistema


transacional e que foi levantado juntamente com os analistas de sistemas OLTP, foi
apresentado um modelo dimensional de alto nível, ou seja, com a definição macro
geral que o Data Mart Escolar deverá ter. Com base no exposto, o modelo
dimensional que atenda os requisitos levantados acima deverá seguir, de forma
geral o formato apresentado na figura 12:

Figura 12– Modelo mostrando o modelo dimensional macro baseado em informações


coletadas.

6.3. Modelagem Dimensional

A partir da definição dos requisitos, tem-se base para o começo da


construção do modelo dimensional.

Esse modelo utiliza duas tabelas de fatos e sete tabelas dimensionais, devido
a três necessidades distintas detalhadas a seguir:

 Registrar a quantidade de ocorrências por professor, o qual este cálculo


armazenará a quantidade de ocorrências em determinada disciplina de um

75
determinado aluno por professor. O objetivo deste cálculo é atender o
primeiro requisito solicitado ao sistema;

 Armazenar a média de notas dos alunos para a análise do desempenho


por professor e o desempenho da escola em geral. Com base neste
cálculo será possível responder questões de desempenho; e

 Analisar se o comparecimento de pais ou responsáveis influencia no


desempenho geral dos alunos.

Figura 13 – Modelo de dados dimensional utilizado para no Data Mart Escolar.

6.4. Projeto físico do banco de dados

Foi criado um repositório chamado DM_ESCOLAR para armazenar as tabelas


dimensionais e fato relacionadas a solução.

Abaixo segue descrição física das tabelas dimensionais com a indicação da


função de cada campo dentro da solução:

TB_DIM_FUNCIONARIO

ID_FUNCIONARIO Armazena o ID DW para a dimensão funcionário;

76
MATRICULA_FUNCIONARIO Armazena a matrícula do funcionário;

NOME_FUNCIONARIO Armazena o nome do funcionário;

DTH_NASCIMENTO Armazena a data de nascimento do funcionário;

CARG_FUNCIONARIO Armazena o cargo do funcionário;

DTH_ADMISSAO Armazena a data de admissão do funcionário;

ESTADO_CIVIL Armazena o estado civil do funcionário;

SEXO_FUNCIONARIO Armazena o sexo do funcionário;

DTH_INICIO Data de entrada da dimensão no DW;

DTH_FIM Data de mudança da dimensão no DW; e

FL_CORRENTE Flag que indica se a dimensão é atual.

TB_DIM_ALUNO

ID_ALUNO Armazena o ID DW para a dimensão aluno;

MATR_ALUNO Armazena a matrícula do aluno;

NOME_ALUNO Armazena o nome do aluno;

DTH_NASCIMENTO Armazena a data de nascimento do aluno;

SEXO_ALUNO Armazena o sexo do aluno;

DTH_INICIO Data de entrada da dimensão no DW;

DTH_FIM Data de mudança da dimensão no DW; e

FL_CORRENTE Flag que indica se a dimensão é atual.

TB_DIM_OCORRENCIA

77
ID_OCORRENCIA Armazena o ID DW para a dimensão ocorrência;

COD_CATEGORIA Armazena o código de categoria de ocorrência;

DTH_INICIO Data de entrada da dimensão no DW;

DTH_FIM Data de mudança da dimensão no DW; e

FL_CORRENTE Flag que indica se a dimensão é atual.

TB_DIM_DISCIPLINA

ID_DISCIPLINA Armazena o ID DW para a dimensão disciplina;

COD_ID_DISCIPLINA Armazena o ID OLTP para disciplina;

COD_DISCIPLINA Armazena o código da disciplina;

NOME_DISCIPLINA Armazena o nome da disciplina;

DTH_INICIO Data de entrada da dimensão no DW;

DTH_FIM Data de mudança da dimensão no DW; e

FL_CORRENTE Flag que indica se a dimensão é atual.

TB_DIM_TEMPO

ID_TEMPO Armazena o ID DW para a dimensão tempo;

ANO_REF Armazena o ano referente;

SEMESTRE Armazena o semestre referente;

BIMESTRE Armazena o bimestre referente;

MES_REF Armazena o mês referente;

MES_NOME Armazena o nome do mês referente;

78
DIA_ANO Armazena o dia do ano;

DIA_MES Armazena o dia do mês;

DIA_SEMANA Armazena o dia da semana; e

DTH_REF Armazena a data.

TB_FATO_ESCOLAR

ID_FUNCIONARIO Armazena o ID DW do funcionário;

ID_ALUNO Armazena o ID DW do aluno;

ID_OCORRENCIA Armazena o ID DW de ocorrência;

ID_DISCIPLINA Armazena o ID DW da disciplina;

ID_TEMPO Armazena o ID DW do tempo;

QTD_OCORRENCIA Armazena a quantidade das ocorrências;

MDA_NOTA Armazena a média da nota do aluno; e

QTD_FALTAS Armazena a quantidade de faltas do aluno.

6.5. Projeto de extração, transformação e carga

De acordo com o modelo dimensional, pode-se fazer um projeto dos planos


de carga para que os dados dos sistemas transacionais se adéqüem perfeitamente
na estrutura do modelo dimensional.

Na figura seguinte são mostradas as principais tabelas do sistema OLTP que


serão utilizadas como fonte para o sistema DW.

79
Figura 14 – Modelo Físico do Sistema OLTP com as principais tabelas a serem utilizadas no
DW..

A princípio não houve grande esforço para a carga das dimensões, pois elas
já estavam bem encaixadas nas tabelas do modelo relacional. O plano de carga
para as dimensões foi feito da seguinte forma:

TB_DIM_FUNCIONARIO ID_FUNCIONARIO  Chave primária gerado


pelo script PL/SQL;

MATRICULA_FUNCIONARIO  Retirado do
campo co_funcionario da tabela
S_FUNCIONARIO. Este campo será utilizado
como chave para avaliação de novos registros
nesta dimensão;

NOME_FUNCIONARIO  Retirado do campo


ds_funcionario da tabela S_FUNCIONARIO;

DTH_NASCIMENTO  Retirado do campo


dt_nascimento da tabela S_FUNCIONARIO;

ESTADO_CIVIL  Retirado do campo


tp_estado_civil da tabela S_FUNCIONARIO;

SEXO_FUNCIONARIO  Retirado do campo

80
tp_sexo da tabela S_FUNCIONARIO;

DATA_INICIO  Campo calculado gerado por


PL/SQL indicando a data de entrada do registro
de dimensão;

DATA_FIM  Campo calculado gerado por


PL/SQL indicando a data de fim de vigência do
registro de dimensão; e

FL_CORRENTE  Campo calculado gerado por


PL/SQL indicando se o registro de dimensão é
atual ou não.

TB_DIM_ALUNO ID_ALUNO  Chave primária gerada pelo script


PL/SQL;

MATRICULA_ALUNO  Retirado do campo


co_aluno da tabela S_ALUNO. Este campo será
utilizado como chave para avaliação de novos
registros nesta dimensão;

NOME_ALUNO  Retirado do campo ds_aluno


da tabela S_ALUNO;

DTH_NASCIMENTO  Retirado do campo


dt_nascimento da tabela S_ALUNO;

SEXO_ALUNO  Retirado do campo tp_sexo da


tabela S_ALUNO;

DATA_INICIO  Campo calculado gerado por


PL/SQL indicando a data de entrada do registro
de dimensão;

DATA_FIM  Campo calculado gerado por


PL/SQL indicando a data de fim de vigência do
registro de dimensão; e

81
FL_CORRENTE  Campo calculado gerado por
PL/SQL indicando se o registro de dimensão é
atual ou não.

TB_DIM_OCORRENCIA ID_OCORRENCIA  Chave primária gerado


pelo script PL/SQL;

CODIGO_OCORRENCIA  Retirado do campo


id_categoria da tabela S_CATEGORIA. Este
campo será utilizado como chave para avaliação
de novos registros nesta dimensão;

DESCRICAO_OCORRENCIA Retirado do
nome_categoria da tabela S_CATEGORIA;

DATA_INICIO  Campo calculado gerado por


PL/SQL indicando a data de entrada do registro
de dimensão;

DATA_FIM  Campo calculado gerado por


PL/SQL indicando a data de fim de vigência do
registro de dimensão;

FL_CORRENTE  Campo calculado gerado por


PL/SQL indicando se o registro de dimensão é
atual ou não.

TB_DIM_DISCIPLINA ID_DISCIPLINA  Chave primária gerado pelo


script PL/SQL;

CODIGO_DISCIPLINA  Retirado do campo


co_disciplina da tabela S_DISCIPLINA. Este
campo será utilizado como chave para avaliação
de novos registros nesta dimensão;

NOME_DISCIPLINA  Retirado do campo

82
ds_disciplina da tabela S_DISCIPLINA;

DATA_INICIO  Campo calculado gerado por


PL/SQL indicando a data de entrada do registro
de dimensão;

DATA_FIM  Campo calculado gerado por


PL/SQL indicando a data de fim de vigência do
registro de dimensão; e

FL_CORRENTE  Campo calculado gerado por


PL/SQL indicando se o registro de dimensão é
atual ou não.

TB_DIM_TEMPO ID_TEMPO  Chave primária gerado pelo script


PL/SQL;

ANO  Campo gerado por script PL/SQL;

SEMESTRE  Campo gerado por script


PL/SQL;

BIMESTRE  Campo gerado por script PL/SQL;

MES  Campo gerado por script PL/SQL;

MES_NOME  Campo gerado por script


PL/SQL;

DIA_ANO  Campo gerado por script PL/SQL;

DIA_MES  Campo gerado por script PL/SQL;

DIA_SEMANA  Campo gerado por script


PL/SQL; e

DATA  Campo gerado por script PL/SQL.

TB_FATO_ESCOLAR ID_FUNCIONARIO  Chave estrangeira que

83
referencia a tabela TB_DIM_FUNCIONARIO;

ID_ALUNO  Chave estrangeira que referencia


a tabela TB_DIM_ALUNO;

ID_OCORRENCIA  Chave estrangeira que


referencia a tabela TB_DIM_OCORRENCIA;

ID_DISCIPLINA  Chave estrangeira que


referencia a tabela TB_DIM_DISCIPLINA;

ID_TEMPO  Chave estrangeira que referencia


a tabela TB_DIM_TEMPO;

QTD_OCORRENCIA  Campo calculado com


base na quantidade de ocorrências cometidas
por alunos em determinada disciplina. Campo da
tabela S_OCORRENCIA; e

MDA_NOTA  Retirado do campo nota da


tabela NOTA. Para tupla da tabela, deve existir o
campo nota com a média do aluno naquela
disciplina. Campo da tabela
S_ALUNO_DISCIPLINA.

6.6. Desenvolvimento de aplicações

Uma vez realizada a carga do Data Mart, será utilizada a ferramenta Oracle
Discoverer como ferramenta Front-End para consulta de dados que podem ser
acessados via intranet, por meio de um browser

Com base nas necessidades levantadas anteriormente pode efetuar várias


pesquisas tais como:

 Nível de ocorrências por professor;

 Desempenho escolar por ano (notas por ano);

 Desempenho do aluno na disciplina por professor; e

 Desempenho escolar do aluno x Assiduidade dos Responsáveis.

84
7. Conclusão

Um Data Warehouse é um grande centro de informações, que são


constantemente incluídas, mantendo um histórico sobre todas as movimentações
consideradas importantes para as companhias que constroem um Data Warehouse.

É um processo demorado e de alto custo em alguns casos, desta forma, os


objetivos da construção e uso de um Data Warehouse deverão ser muito bem
fundamentadas, pois exigem também requisição de vários recursos de hardware,
software e pessoal qualificado. No entanto é uma ferramenta cara e de difícil
implantação, devido a isso, deve-se analisar bem antes da implantação.

Os benefícios da construção de um Data Warehouse variam desde a


campanhas para manter o estado atual dos negócios quanto para previsão de
possíveis oportunidades para crescimento no mercado.

Para se atingir os resultados por ele almejados é preciso saber utilizá-lo e


também saber se é realmente necessário. Muitas vezes estas questões básicas são
esquecidas e os pensamentos são enfocados apenas no que esta ferramenta pode
nos oferecer, esquecendo muitas vezes a nossa própria realidade.

Desta forma, deve-se dar a máxima importância para a etapa de coleta de


requisitos em um projeto de DW, realizando todas as etapas do ciclo de
desenvolvimento definido no projeto a fim de minimizar os erros de especificação e
desta maneira, evitar-se o gasto desnecessário com novos levantamentos e
atualização de documentação

85
Referência Bibliográfica

[BAR01] BARBIERI, Carlos. BI – Business Inteligence – Modelagem & Tecnologia,


Rio de Janeiro, Axcel Books, 2001.

[DWBRASIL, 2003] DWBrasil – Disponível em <http://www.dwbrasil.com.br>


Acessado em 13 de fevereiro de 2008 20h47.

[CONGRESSO, 2008], MUSSI, Camilo. DataWarehouse – Da modelagem à


implantação, 2006 – Disponível em <http://www.congreso-
info.cu/UserFiles/File/Info/Intempres2006/Intempres2004/Sitio/Ponencias/8.pdf>
Acesso em 05 de maio de 2008.

[BIBLIOTECADIGITAL, 2008] Biblioteca Digital – Disponível em


<www.sbc.org.br/bibliotecadigital/download.php?paper=262> Acesso em 05 de maio
de 2008.

[DATAMINIG, 2008] DataMining EIS – Disponível em


<http://www.fieo.br/v2/central_aluno/revista/rev1999/DataMining_EIS.htm#Quem>
Acesso em 06 de maio de 2008.

[DATABASES, 2008] Databases – Disponível em


<http://databases.about.com/od/specificproducts/a/normalization.htm> Acesso em 06
de maio de 2008.

[DEVMEDIA, 2008] DevMedia group – asp.net, java, Delphi, SQL e Webdesign.


Disponível em
<http://www.devmedia.com.br/Imagens/gold/SQL/39/artigo1/image2.jpg> Acesso em
10 de maio de 08. 20h00.

[DSPACE,2008] Instituto Superior Técnico – Universidade Técnica de Lisboa.


Disponível em:
<https://dspace.ist.utl.pt/bitstream/2295/54644/1/bdSchema.20060321.jpg> Acesso
em 11 de maio de 2008.

[GRA00] GRAEML, Alexandre R.. Sistemas de Informação: o alinhamento da


estratégia de TI com a estratégia corporativa. São Paulo, Editora Atlas S.A., 2000.

[GRA98] GRAY, Paul & Watson, Hugh J. Decision Support in the Data Warehouse.
New Jersey, Prentice Hall PTR, 1998.

86
[INM99] INMON, W.H. – Gerenciando Data Warehouse. Rio de Janeiro, Makron
Books, 1999.

[INM05] INMON, William H. Building the Data Warehouse. Indianapolis, Indiana,


Wiley Publishing, Inc., 2005.

[KIM98a] KIMBALL, Ralph, ROSS, Margy. The Data Warehouse Toolkit 2th edition.
Indianapolis, Indiana, Wiley Publishing, Inc. 1998.

[KIM98b] KIMBALL, Ralph – The Data Warehouse Toolkit. São Paulo: Makron
Books, 1998. 388p.

[MAC07] MACHADO, Felipe N R. Tecnologia e Projeto de Data Warehouse: uma


visão multidimensional. São Paulo, Érica, 2007.

[MICROSOFT, 2008] Microsoft – Modelo multidimensional. Disponível em


http://www.microsoft.com/brasil/msdn/images/tecnologias/arquitetura/Dados_Multidi
mensionais/4_Whitepaper%20-
%20Modelagem%20de%20Bancos%20de%20Dados%20Multidimensionais_19.jpg>

Acesso em 11 de maio de 2008 as 20h15

[OLI02] OLIVEIRA, José W. Data Warehouse. Visual Books, 2002.

[ORACLE, 2008]ORACLE – ETL. Disponível em < -


http://download.oracle.com/docs/cd/B19306_01/server.102/b14223/ettover.htm>
Acesso em 08 de maio de 2008 as 19h30.

[SIL99] SILBERSCHATZ, A.; KORTH, H. F.; SUDARSHAN, S. Sistemas de Bancos


de Dados. 3. ed. Makron Books, 1999.

[SPR91] SPRAGUE, H. e WATSON, J. – Sistema de apoio a decisão: colocando a


teoria em prática. Ed. Campus, Rio de Janeiro, 1991.

87
Apêndice A

Glossário

Ad-Hoc Query ( consulta eventual )


Qualquer consulta que não possa ser determinada antes do momento da consulta
ser emitida. Uma consulta que consiste em SQL construído dinamicamente, em
geral por ferramentas de consulta residentes na estação de trabalho do usuário final.

Agregados
Resumos pré - calculados ou pré - armazenados que são mantidos no Data
Warehouse para melhorar o desempenho de consulta.

Atributo
Um campo em uma tabela dimensional.

Banco de dados Relacional


Um sistema de banco de dados que suporta todos os comandos SQL padrão.

Chave estrangeira (Foreign Key)


Um campo de um banco de dados relacional cujos valores são obtidos de uma
chave primária em outra tabela. Em um esquema star join, os componentes da
chave composta de uma tabela de fatos são chaves estrangeiras respectivas a cada
uma das tabelas de dimensão.

Chave primária (Primary key)


Um campo em um banco de dados exclusivos a cada registro da tabela.

Cliente/Servidor
Abordagem de tecnologia distribuída na qual o processamento é dividido por função.
O componente servidor realiza funções compartilhadas - gestão de comunicações,
fornecimento de serviços de base de dados etc. O componente cliente realiza
funções individuais de usuário – disponibilização de interfaces adaptadas,
navegação entre telas, funções de auxilio etc.

88
Consulta (Query)
Uma instrução SQL SELECT passada de um aplicativo de front-end (que reside
normalmente no cliente do usuário) para DBMS relacional.

Data Mining
Técnica que utiliza ferramentas de software geralmente orientadas para o usuário
que não sabe exatamente o que está pesquisando, mas procura identificar
determinados padrões ou tendências. O termo Data Mining (garimpo de Dados)
identificação processo de separar grandes quantidades de dados de forma a
identificar relacionamentos entre eles.

Data Warehouse
Uma cópia dos dados de transações, estruturada especificamente para consultas e
análises.

Drill
Modo de exploração de dados detalhados que foram usados na criação de um nível
sumarizado de dados. Os níveis de aprofundamento dependem de granularidade
dos dados existentes no Data Warehouse.

DSS (Decision Support System ou Sistema de Apoio a Decisão)


Software que fornece ao usuário informações para a tomada de decisões.

Executive Information System - (EIS)


Sistema de Informações Executivas Ferramentas programadas para disponibilizar
relatórios previamente preparados ou resumos impressos para executivos de alto
nível. Elas oferecem poderosas capacidades de construção de relatórios e de
detalhamento de informações. Atualmente estas ferramentas possibilitam a
submissão de consultas especificas a base de dados multi-dimensionais e a maioria
delas oferece aplicações analíticas especificas, como analise de vendas ou
financeira.

Ferramentas de front-end

89
É uma ferramenta-cliente que recupera ou manipula dados armazenados em um
banco de dados relacional.

Filtros
Conjunto de critérios previamente escolhidos que especificam um subconjunto de
informações em um Data Warehouse.

Grão
Significa um único registro em uma tabela de fatos. A definição da granularidade em
uma tabela de fatos é a Segunda das quatro etapas principais envolvidas no projeto
de um esquema star join.

Metadados
Qualquer dado mantido para suportar as operações ou uso de um Data Warehouse.
Praticamente todas as ferramentas de Front-End exigem algum metadado próprio na
forma de especificações ou status. O metadado é freqüentemente externo ao banco
de dados relacional. Não existem padrões coerentes para o metadado.

Modelo Dimensional
Metodologia de projeto que lista dimensões e fatos relevantes a cada processo de
negócio.

Modelo Entidade/Relacionamento
Modelo para os dados de uma organização que tem como objetivo remover todos os
valores repetidos por meio de criação de tabelas adicionais.

Normalizar
Processo usado para eliminar a redundância de dados separando-os em várias
tabelas.

OLAP
Processamento analítico On-Line. Um termo que contrasta com OLTP. Um conjunto
de princípios com definição imprecisa que fornece uma estrutura para suporte a
decisão. O termo OLAP também é utilizado para referir-se ao grupo de fornecedores

90
que oferecem produtos proprietários, não relacionais, destinados ao suporte à
decisão.

OLTP
Processamento de transações On-Line. A descrição original de todas as atividades e
sistemas associados à inserção de dados de forma confiável em um banco de
dados. Embora utilizado freqüentemente com referência a banco de dados, OLTP
pode ser usado genericamente para descrever um ambiente de processamento de
transações.

Repositório
Banco de dados de um Data Warehouse.

Slice and Dice (Fatiar)


A descrição padrão da habilidade de acessar um Data Warehouse por meio de
qualquer de suas dimensões de forma igual.

Suporte à Decisão
Utilização de dados na tomada de decisão em uma organização.

Tabela de dimensão
Uma tabela em um esquema star join com uma única chave primária.

Tabela de Fatos
A tabela central de um esquema star join, caracterizada por uma chave composta,
em que cada elemento é uma chave externa de uma tabela de dimensão.

Transação
Um unidade indivisível de trabalho. Um sistema de processamento de transações
pode executar somente a transação completa, e não apenas parte dela.

91
Apêndice B
SCRIPT DE GERAÇÃO DO BANCO DE DADOS

CREATE TABLE tb_dim_aluno


(id_aluno NUMBER(8,0) NOT NULL,
matricula_aluno VARCHAR2(10),
nome_aluno VARCHAR2(200),
data_nascimento_aluno DATE,
sexo_aluno CHAR(1),
data_inicio DATE,
data_fim DATE,
fl_corrente CHAR(1))
PARALLEL (DEGREE DEFAULT)
/

GRANT SELECT ON tb_dim_aluno To eul_escolar


/
GRANT REFERENCES ON tb_dim_aluno To eul_escolar
/
GRANT SELECT ON tb_dim_aluno TO eul_escolar
/
GRANT REFERENCES ON tb_dim_aluno TO eul_escolar
/

ALTER TABLE tb_dim_aluno


ADD CONSTRAINT pk_dim_aluno PRIMARY KEY (id_aluno)
USING INDEX
/

CREATE TABLE tb_dim_disciplina


(id_disciplina NUMBER(8,0) NOT NULL,
codigo_disciplina VARCHAR2(10),
nome_disciplina VARCHAR2(50),
data_inicio DATE,
data_fim DATE,
fl_corrente CHAR(1))
PARALLEL (DEGREE DEFAULT)
/

GRANT SELECT ON tb_dim_disciplina To eul_escolar


/
GRANT REFERENCES ON tb_dim_disciplina To eul_escolar
/
GRANT SELECT ON tb_dim_disciplina TO eul_escolar
/
GRANT REFERENCES ON tb_dim_disciplina TO eul_escolar
/

ALTER TABLE tb_dim_disciplina


ADD CONSTRAINT pk_dim_disciplina PRIMARY KEY (id_disciplina)

92
USING INDEX
/

CREATE TABLE tb_dim_funcionario


(id_funcionario NUMBER(8,0) NOT NULL,
matricula_funcionario NUMBER(10,0),
nome_funcionario VARCHAR2(200),
dth_nascimento DATE,
cargo_funcionario VARCHAR2(50),
dth_admissao_funcionario DATE,
estado_civil_funcionario VARCHAR2(15),
sexo_funcionario CHAR(1),
data_inicio DATE,
data_fim DATE,
fl_corrente CHAR(1))
PARALLEL (DEGREE DEFAULT)
/

GRANT SELECT ON tb_dim_funcionario To eul_escolar


/
GRANT REFERENCES ON tb_dim_funcionario To eul_escolar
/
GRANT SELECT ON tb_dim_funcionario TO eul_escolar
/
GRANT REFERENCES ON tb_dim_funcionario TO eul_escolar
/

ALTER TABLE tb_dim_funcionario


ADD CONSTRAINT pk_dim_funcionario PRIMARY KEY (id_funcionario)
USING INDEX
/

CREATE TABLE tb_dim_ocorrencia


(id_ocorrencia NUMBER(8,0) NOT NULL,
codigo_ocorrencia NUMBER(4,0),
descricao_ocorrencia VARCHAR2(20),
data_inicio DATE,
data_fim DATE,
fl_corrente CHAR(1))
PARALLEL (DEGREE DEFAULT)
/

ALTER TABLE tb_dim_ocorrencia


ADD CONSTRAINT pk_dim_ocorrencia PRIMARY KEY (id_ocorrencia)
USING INDEX
/

CREATE TABLE tb_dim_tempo


(data DATE NOT NULL,
data_chave DATE,
mes VARCHAR2(15),
ano NUMBER(4,0),

93
trimestre VARCHAR2(25),
semestre VARCHAR2(25),
diasemana VARCHAR2(15),
semanadomes VARCHAR2(10),
atual CHAR(1),
mes_chave NUMBER(2,0),
diasemana_chave NUMBER(2,0),
descricao_mes VARCHAR2(15),
bimestre VARCHAR2(25))
PARALLEL (DEGREE DEFAULT)
/

GRANT SELECT ON tb_dim_tempo To eul_escolar


/
GRANT REFERENCES ON tb_dim_tempo To eul_escolar
/
GRANT SELECT ON tb_dim_tempo TO eul_escolar
/
GRANT REFERENCES ON tb_dim_tempo TO eul_escolar
/

ALTER TABLE tb_dim_tempo


ADD CONSTRAINT pk_tempovenda PRIMARY KEY (data)
USING INDEX
/

CREATE TABLE tb_fato_aluno


(id_aluno NUMBER(8,0),
id_funcionario NUMBER(8,0),
id_disciplina NUMBER(8,0),
id_ocorrencia NUMBER(8,0),
id_tempo DATE,
nota NUMBER(4,2),
falta NUMBER(3,0)
qtd_ocorrencia NUMBER(3,0))
PARALLEL (DEGREE DEFAULT)
/

GRANT SELECT ON tb_fato_aluno To eul_escolar


/
GRANT REFERENCES ON tb_fato_aluno To eul_escolar
/
GRANT SELECT ON tb_fato_aluno TO eul_escolar
/
GRANT REFERENCES ON tb_fato_aluno TO eul_escolar
/

ALTER TABLE tb_fato_aluno


ADD CONSTRAINT fk_dim_aluno FOREIGN KEY (id_aluno)
REFERENCES tb_dim_aluno (id_aluno) ON DELETE CASCADE
/
ALTER TABLE tb_fato_aluno
ADD CONSTRAINT fk_dim_disciplina FOREIGN KEY (id_disciplina)
REFERENCES tb_dim_disciplina (id_disciplina) ON DELETE CASCADE

94
/
ALTER TABLE tb_fato_aluno
ADD CONSTRAINT fk_dim_funcionario FOREIGN KEY (id_funcionario)
REFERENCES tb_dim_funcionario (id_funcionario) ON DELETE CASCADE
/
ALTER TABLE tb_fato_aluno
ADD CONSTRAINT fk_dim_ocorrencia FOREIGN KEY (id_ocorrencia)
REFERENCES tb_dim_ocorrencia (id_ocorrencia) ON DELETE CASCADE
/
ALTER TABLE tb_fato_aluno
ADD CONSTRAINT fk_dim_tempo FOREIGN KEY (id_tempo)
REFERENCES tb_dim_tempo (data) ON DELETE CASCADE
/

95
Apêndice C

TELAS DO PROTÓTIPO

Figura 15 – Tela do aplicativo SQLPLUS mostrando todas as tabelas DW do esquema “dw_escolar”.


Tabelas com prefixo diferente de “TB_” pertencem aos aplicativos core do Oracle Warehouse Builder.

96
Figura 16 – Tela da ferramenta de ETL Oracle Warehouse Builder, mostrando a perspectiva DW e a
perspectiva OLTP.

Figura 17 – Tela da ferramenta de ETL Oracle Warehouse Builder, mostrando os processos de ETL
com prefixo “MAP_”.

97
Figura 18 – Tela da ferramenta de front-end Oracle Discoverer Administrator, mostrando a Business
Area Criada para o projeto escolar.

Figura 19 – Business Area para a Escola. Tela do Discoverer Administrator mostrando as tabelas do
DW.

98
Figura 20 – Business Area para a Escola. Tela do Discoverer Administrator mostrando o
detalhamento das tabelas. Perspectiva pronta para a criação de consultas ad hoc.

99