Universidade de Brasília Instituto de Ciências

Transcrição

Universidade de Brasília
Instituto de Ciências Exatas
Departamento de Ciência da Computação
Data Warehouse como Instrumento de Suporte à
Avaliação Acadêmica
Daniel Kenji Fujiwara
Monografia apresentada como requisito parcial
para conclusão do Curso de Computação – Licenciatura
Orientadora
Prof .̄ Dr .̄ Célia Ghedini Ralha
a
a
Brasília
2006
Universidade de Brasília – UnB
Curso de Computação – Licenciatura
Coordenadora: Prof a.̄ Dr a.̄ Maria Emília Machado Telles Walter
Banca examinadora composta por:
Prof a.̄ Dr a.̄ Célia Ghedini Ralha (Orientadora) – CIC/IE
Prof a.̄ Dr a.̄ Gardênia da Silva Abbad – PST/IP
Prof. Cristian Rodrigo Dedavid – CIC/IE
CIP – Catalogação Internacional na Publicação
Daniel Kenji Fujiwara.
Data Warehouse como Instrumento de Suporte à Avaliação Acadêmica/
Daniel Kenji Fujiwara. Brasília : UnB, 2006.
98 p. : il. ; 29,5 cm.
Monografia (Graduação) – Universidade de Brasília, Brasília, 2006.
1. Data Warehouse, 2. OLAP, 3. DOLAP, 4. Data Mart,
5. Banco de Dados
CDU 004
Endereço: Universidade de Brasília
Campus Universitário Darcy Ribeiro – Asa Norte
CEP 70910–900
Brasília – DF – Brasil
Universidade de Brasília
Data Warehouse como Instrumento de Suporte à
Avaliação Acadêmica
Daniel Kenji Fujiwara
Monografia apresentada como requisito parcial
para conclusão do Curso de Computação – Licenciatura
Prof a.̄ Dr a.̄ Célia Ghedini Ralha (Orientadora)
CIC/IE
Prof a.̄ Dr a.̄ Gardênia da Silva Abbad
PST/IP
Prof. Cristian Rodrigo Dedavid
CIC/IE
Prof a.̄ Dr a.̄ Maria Emília Machado Telles Walter
Coordenadora do Curso de Computação – Licenciatura
Brasília, 04 de agosto de 2006
Dedicatória
Dedico este projeto a todos meus amigos, que compartilharam nossas alegrias e
incertezas ao longo dessa caminhada. Dedico de modo especial à minha esposa
Elisângela e minha filha Sara, que, com incentivo e muita paciência, vibram comigo por este final de curso. Dedico este projeto também aos meus pais, que me
deram todas as bases da minha formação intelectual e pessoal. Dedico aos meus
irmãos que gozam comigo dessa conquista. E dedico por fim ao corpo docente do
Departamento de Ciências da Computação da Universidade de Brasília, em especial a minha orientadora tão importante como guia na caminhada nesta minha
vida acadêmica.
Agradecimentos
Agradeço a Deus, sempre fazendo por mim e por minha família, mesmo quando
não fazemos por Ele.
Agradeço muito à Prof a.̄ Dr a.̄ Célia, minha orientadora que, com paciência e
muito trabalho tornou possível esta monografia. Agradeço também pelo trabalho
na obtenção junto a outras entidades da UnB.
Agradeço à Prof a.̄ Dr a.̄ Gardênia por participar da banca examinadora e por auxiliar na definição do escopo do projeto maior, mesmo não sendo possível executálo no prazo deste projeto.
Ao professor Neto e ao servidor Mizuno, que disponibilizaram as informações
para serem carregadas no estudo de caso para o projeto final.
Agradeço também ao Prof. Cristian, meu amigo de longa data, que além de
ter me fornecido material de estudo, veio participar desta banca examinadora.
Agradeço especialmente à minha esposa Elisângela e à minha filha Sara, que
precisaram de paciência durante todo o tempo em que estive cursando minha
graduação.
Resumo
Nos dias atuais, vivemos em um momento tecnológico no qual estamos tendo uma
oportunidade de grandes mudanças de conceitos. Bens, direitos e expansão são
exemplos de conceitos cujo significado está cada vez mais diferente do que era nas
gerações passadas.
Junto com a globalização, a informação passou a ter suma importância para
todas as pessoas e instituições. A desinformação é nevrálgica para qualquer indivíduo. As relações comerciais, de modo geral, pregam a competitividade de tal
modo, que empresas e clientes tornaram-se extremamente ágeis e exigentes.
Entretanto o excesso de informação é desinformação. Diante da quantidade
de dados, números, estatísticas, nomes, endereços, datas, valores, quantidades e
contas disponibilizadas por todos os meios de comunicação de massa, somadas as
informações disponíveis nas organizações, instituições e pessoas tendem a ficarem
sem informação. Assim, prover informações de maneira organizada, selecionada,
suficiente e precisa é certamente uma contribuição essencial às instituições.
Este trabalho apresenta a tecnologia de Data Warehouse como Instrumento de
Avaliação Acadêmica, tendo desenvolvido um estudo de caso junto ao CESPE, à
Secretaria de Planejamento (SPL) e ao Departamento de Ciências da Computação
(CIC) da Universidade de Brasília.
Palavras-chave: Data Warehouse, OLAP, DOLAP, Data Mart, Banco de Dados
Abstract
Now a days, we live at a technological moment at which we are having a chance of
great changes of concepts. Goods, rights and expansion are examples of concepts
whose meant it is each more different time of what it was in the last generations.
With the globalization, the information is utmost important for all the people
and institutions. Disinformation is nephralgic for any person. The commercial
relationship, preach the competitiveness, that companies and customers had become extremely agile and demanding.
However the information excess is disinformation. In face of the amount of
data, numbers, statisticians, names, addresses, dates, values, amounts and accounts, shown by all mass communication media, added the available information in the organizations, institutions and people tend to be without information.
Thus, to provide information with way organized, selected, enough and needs is
certainly a essential contribution to the institutions.
This work presents the technology of Data Warehouse as Instrument of Academic Evaluation, having developed a case study with CESPE, Secretariat of
Planning (SPL) and to the Department of Computer Sciences (CIC) of the University of Brasilia.
Keywords: Data Warehouse, OLAP DOLAP, Data Mart, Data Base
Sumário
Lista de Figuras
10
Lista de Tabelas
12
Capítulo 1 Introdução
13
Capítulo 2 Fundamentos Teóricos
2.1 Histórico de DW . . . . . . . .
2.2 Conceitos Básicos . . . . . . . .
2.3 Principais Características . . . .
2.4 Tecnologia de DW . . . . . . .
2.4.1 Modelo de Dados . . . .
2.4.2 Arquitetura . . . . . . .
2.4.3 ETC . . . . . . . . . . .
2.4.4 Visualização de Dados .
2.4.5 Administração . . . . . .
2.5 Trabalhos Correlatos . . . . . .
15
15
18
19
31
31
37
41
42
50
54
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Capítulo 3 O Problema
57
Capítulo 4 Metodologia Adotada
62
Capítulo 5 Estudo de caso
5.1 Questões Gerenciais . . . . . . . . . .
5.2 Granularidade Adotada . . . . . . . .
5.3 Objetos Gerenciais . . . . . . . . . .
5.4 Estrelas Modeladas . . . . . . . . . .
5.5 Camada de Visualização dos Dados .
5.6 Fontes de Dados . . . . . . . . . . . .
5.6.1 Qualiade dos dados . . . . . .
5.7 Ferramentas Utilizadas . . . . . . . .
5.7.1 Banco de Dados . . . . . . . .
5.7.2 ETC . . . . . . . . . . . . . .
5.7.3 Ferramenta Case . . . . . . .
5.7.4 Ferramenta de Visualização de
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
Dados
Capítulo 6 Conclusão e Trabalhos Futuros
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
67
68
68
69
71
72
72
78
79
79
79
79
79
80
Apêndice A Padões Utlizados nos Modelos de Dados
84
Apêndice B Dicionário de dados
B.1 Tabelas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.2 Colunas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
87
87
88
Apêndice C Formulário de Avaliação das Disciplinas pelos Discentes
94
Referências
95
9
Lista de Figuras
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
2.10
2.11
2.12
2.13
2.14
Representação de um modelo dimensional sobre eixos cartesianos.
Tabelas de fatos e de dimensões. . . . . . . . . . . . . . . . . . . .
Processo de contstrução de um DM. . . . . . . . . . . . . . . . . .
Modelo Floco de Neve. . . . . . . . . . . . . . . . . . . . . . . . .
Compartilhamento de dimensões no modelo Floco de Neve. . . . .
Modelo Estrela de uma tabela de fatos. . . . . . . . . . . . . . . .
Modelo Estrela de outra tabela de fatos. . . . . . . . . . . . . . .
Componentes básicos de um DW. . . . . . . . . . . . . . . . . . .
Exemplo de Cubo com 3 Dimensões. . . . . . . . . . . . . . . . .
Tabelas no Modelo MDB. . . . . . . . . . . . . . . . . . . . . . .
Hierarquia Comum nos Modelos OLAP. . . . . . . . . . . . . . . .
Criação de um Cubo Virtual no MDDB. . . . . . . . . . . . . . .
Os Cubos Físicos pela Visão do Usuário. . . . . . . . . . . . . . .
Desembolso em um projeto de BI . . . . . . . . . . . . . . . . . .
21
22
25
33
34
35
35
39
45
45
46
48
48
50
5.1
5.2
5.3
Estrela com a relação entre vagas e matrículas . . . . . . . . . . .
Estrela contendo os conceitos de cada curso nas avaliações externas
Estrela contendo informações das avaliações feitas pelos discentes
sobre a disciplina . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ferramenta de visualização dos dados, antes de pesquisar o banco
de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ferramenta de visualização dos dados, após pesquisa ao banco de
dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Universo de Vagas e Matrículas . . . . . . . . . . . . . . . . . . .
Universo de Conceitos das Avaliações Externas . . . . . . . . . . .
Universo de Avaliação das Disciplinas pelos Discentes . . . . . . .
71
71
5.4
5.5
5.6
5.7
5.8
6.1
6.2
6.3
A.1
A.2
A.3
A.4
72
73
74
75
76
77
Consulta sobre o perfil dos discentes que preencheram o questionário 80
Consulta da evolução das amostras das avaliações das disciplinas,
segregadas pelos grupos. . . . . . . . . . . . . . . . . . . . . . . . 81
Consulta as Avaliações Externas, Vagas e Matrículas. . . . . . . . 82
Padrões utilizados na Tabela. . . . . . . . . . . . .
Tabelas de Fatos, Dimensões e Relacionamentos. . .
Exemplo de um modelo estrela. . . . . . . . . . . .
Exemplo de um modelo estrela com relacionamentos
setas. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
definidos por
. . . . . . . .
84
84
85
85
C.1 Formulário de Avaliação das Disciplinas pelos Discentes.
11
. . . . .
94
Lista de Tabelas
2.1
2.2
2.3
2.4
2.5
2.6
2.7
3.1
Comparação entre Banco de Dados Operacionais e DW. . . . . . .
Tabela de qualidade dos dados. . . . . . . . . . . . . . . . . . . .
Exemplo de Agregação com Dados de Vendas. Receita de vendas
do 3o trimestre de 1999. . . . . . . . . . . . . . . . . . . . . . . .
Tabela com Exemplo de Informação Incompleta. . . . . . . . . . .
Administração das origens. . . . . . . . . . . . . . . . . . . . . . .
Administração das origens. . . . . . . . . . . . . . . . . . . . . . .
Controle Staging Area. . . . . . . . . . . . . . . . . . . . . . . . .
3.7
3.8
Quadro 1 - Resultados das avaliações dos cursos de graduação
realizadas elo MEC nos últimos três anos. . . . . . . . . . . . . .
Quadro 2 - Relação dos cursos de graduação oferecidos no ano da
avaliação in loco. . . . . . . . . . . . . . . . . . . . . . . . . . . .
Quadro 3 - Situação legal dos cursos de graduação. . . . . . . . .
Quadro 6 - Relação dos cursos superiores de tecnologia oferecidos
no ano da avaliação in loco (quando for o caso). . . . . . . . . . .
Quadro 7 - Situação legal dos cursos superiores de tecnologia
(quando for o caso). . . . . . . . . . . . . . . . . . . . . . . . . . .
Quadro 10 - Estágios curriculares, extra-curriculares e Trabalho
de Conclusão de Curso (TCC) nos três últimos anos. . . . . . . .
Quadro 16 - Envolvimento dos docentes com a instituição. . . .
Quadro 17 - Permanência do Corpo Docente na Instituição. . . .
4.1
4.2
4.3
Tabela com Exemplo de Componentes dos Objetos Gerenciais. . .
Tabela com Exemplo da Origem dos Atributos Gerenciais. . . . .
Tabela com Exemplo de Ciclicidade dos Dados. . . . . . . . . . .
3.2
3.3
3.4
3.5
3.6
20
29
46
47
52
52
53
57
58
58
59
59
60
60
61
65
66
66
Capítulo 1
Introdução
Nos dias atuais, vivemos em um momento tecnológico no qual estamos tendo uma
oportunidade de grandes mudanças de conceitos. Bens, direitos e expansão são
exemplos de conceitos cujo significado está cada vez mais diferente do que era nas
gerações passadas.
Junto com a globalização, a informação passou a ter suma importância para
todas as pessoas e instituições. A desinformação é nevrálgica para qualquer indivíduo. As relações comerciais, de modo geral, pregam a competitividade de tal
modo, que empresas e clientes tornaram-se extremamente ágeis e exigentes. Dessa
forma descreveremos a suma importância no trabalho com dados para transformálos em informações para suporte a decisão, tornando ou mantendo as empresas
cada dia mais competitivas.
Todas as instituições, via de regra, visam resultados obtidos com a aplicação
de capital no menor prazo, e da melhor forma possível. Sobre esta afirmação, o
conhecimento passa a ser uma pedra fundamental, sobre a qual será iniciada a
empreitada.
Entretanto o excesso de informação é desinformação. Diante da quantidade
de dados, números, estatísticas, nomes, endereços, datas, valores, quantidades e
contas disponibilizadas por todos os meios de comunicação de massa, somadas as
informações disponíveis nas organizações, instituições e pessoas tendem a ficarem
sem informação. Assim, prover informações de maneira organizada, selecionada,
suficiente e precisa é certamente uma contribuição essencial às instituições.
Como não poderia deixar de ser, sistemas que provêem suporte a gestão da
informação são grandes contribuintes para essa construção. Esses sistemas colaboram com melhores resultados, no momento que permitem que se produzam
ativos na quantidade mais próxima da consumida ou desejada, ou mais clientes ou
usuários sejam atendidos, ou permitam melhor atendimento e melhores serviços
a esses, ou ainda gerando economia e racionalidade na utilização dos recursos de
que dispõe os gestores das instituições. Quaisquer desses produtos dos sistemas
de informação cooperam para resultados mais satisfatórios para as instituições.
Uma questão que chama muito a atenção, é que durante a evolução da Tecnologia da Informação (TI), empresas de médio e grande portes necessitavam da
informática para aumentar os controles sobre seus processos. Assim, cada departamento iniciou o desenvolvimento de sistemas informatizados para seus processos
internos e externos, aumentando o controle e sistematizando seus procedimentos.
13
Entretanto muitos conceitos básicos, como modelagem dos dados, correta documentação e sistematização foram deixados de lado.
É muito comum encontrar sistemas de informação que não contém integridade
nos modelos de dados, e esses ficam indisponíveis. Consultas na mesma base
de dados podem prover informações desencontradas. Quando essas distorções
ocorrem, muitos gestores abrem mão dos sistemas de informação, e passam a
tomar decisões embasadas em informações empíricas ou em sua (em geral, mas
nem sempre) vasta experiência. Observando essa dificuldade, o conceito Data
Warehouse (DW) surgiu, e passaremos a descrevê-lo agora.
No espaço deste trabalho, DW é visto como uma base de dados histórica e
integrada a fim de prover a quem o usa a possibilidade de análise dos dados,
transformando-os em informações, que são ou podem se tornar um diferencial
competitivo para quaisquer pessoas ou entidades. Com um sistema como esse,
diversos executivos podem tomar decisões com muito mais precisão, eficiência
e eficácia. Tais decisões levarão em conta fatos, não apenas a intuição ou o
sentimento e informações isoladas, a fim de promover novos produtos, abrir novos
mercados, ter novas oportunidades de negócios, ou ter relação mais próxima do
cliente, o que certamente será traduzido em melhores resultados ou melhor gestão
sobre todo o negócio.
O ponto mais importante nessa mistura de tecnologias, é que toda a empresa que possui tais informações, pode canalizar seu capital intelectual, para sua
verdadeira função, que é pensar. As alta e média administração poderão obter
informações com muita agilidade, e poderão direcionar seus recursos para atividades certamente mais nobres, como otimização de processos internos ou qualquer
outra atividade que melhore os indicativos de produtividade ou os resultados diretos da empresa. Analisando os dados provenientes do DW, essas pessoas, assim,
transformarão tais dados em valiosas informações. Nesse ponto a TI exercerá
um grande papel, que é o de fornecer informações de qualidade e deixará de ser
apenas um grande depósito de dados soltos.
Este trabalho está subdividido da seguinte forma: No capítulo 2 serão apresentados alguns fundamentos básicos relacionados à tecnologia de DW, com referências a alguns trabalhos correlatos. O capítulo 3 descreve o problema ao qual
este trabalho está propondo uma hipótese de solução. A metodologia de trabalho
adotada será apresentada no capítulo 4. No capítulo 5 um estudo de caso será
apresentado, enquanto o capítulo 6 apresenta as conclusões e trabalhos futuros.
14
Capítulo 2
Fundamentos Teóricos
Como um estudo de DW, faz-se necessário definir diversos conceitos acerca do
assunto.
Com este objetivo, este capítulo procura abordar os conceitos básicos de um
DW, iniciando em um breve histórico, e evoluindo para as definições e principais
características. Ainda neste capítulo, serão identificados os modelos de dados
utilizados para um DW, tipos de tabelas, arquitetura, Extração, Transformação
e Carga (ETC) e Ferramenta Front-End do DW. Para finalizar o capítulo, serão
citados alguns trabalhos correlatos envolvendo as tecnologias utilizadas por este
projeto.
2.1
Histórico de DW
A fim de compreender a evolução tecnológica que levou aos conceitos de DW, será
necessário rever a evolução dos procedimentos tecnológicos.
Em administração, estuda-se muito acerca da missão das empresas e áreas.
Compreender quais os fatos que realmente importam para o gerenciamento de
quaisquer processos e para cumprir tal missão é um passo fundamental para a
melhor administração dos recursos. Esses fatos devem refletir a realidade da
área com informação suficiente e correta para que o gerente tenha condições de
identificar problemas, riscos e oportunidades, a tempo de agir. A partir dessa
carência, foram traçados os primeiros conceitos de Business Intelligence (BI).
Desde o princípio da computação, os sistemas de informação primavam pela
execução correta e procedimental de processos da empresa ou alguma das suas
áreas. Mas foi na década de 70 que uma grande revolução ocorreu, quando as empresas passaram a utilizar o armazenamento das informações em disco, chamado
Dispositivo de Armazenamento de Acesso Direto (DASD em inglês).
Através do acesso direto, uma nova classe de software foi desenvolvida para
suprir diversas necessidades. Esses software foram chamados Sistema Gerenciador
de Banco de Dados (SGBD), que foi identificada como a melhor fonte única de
dados persistidos para a construção dos sistemas.
Com o advento dos bancos de dados, os processos passaram a ter uma visão
baseada em dados, e assim, um computador servidor central atuaria de modo
único e centralizado para toda a corporação. Dessa forma, aos poucos, os bancos
15
de dados tornaram-se ferramentas corporativas indispensáveis.
A partir desse momento, os instrumentos computacionais da época passaram
a ser vistos como vantagens competitivas. Desse modo, uma vez que todas as
informações procedimentais estavam persistidas, os processos estavam estruturados de modo a persistirem os dados necessários, e diversos sistemas passaram a
coexistir, a fim de permitir a gestão das grandes empresas, sistemas de informação começaram a se tornar necessário. Neste momento, as empresas passaram a
investir na gestão da informação para que os administradores tivessem em mãos
ferramentas que informassem o que fosse preciso, sem que todas as informações
procedimentais fossem apresentadas.
A integração dos diversos sistemas para uma visão holística da corporação
também se tornou importante para a economia de recursos e para maior eficiência
e eficácia dos negócios.
Com o advento dos bancos de dados hierárquicos (e posteriormente relacionais), diversos sistemas de informação puderam implementar avanços muito significativos, tornando-os mais eficientes e mais produtivos.
Nos anos 80, praticamente todas as grandes e médias, boa parte das pequenas
empresas, e pessoas com maior poder aquisitivo, já possuíam acesso a microcomputadores, de modo que a informatização passou a fazer cada vez mais parte do
dia a dia das empresas e pessoas. Dessa forma, as informações advindas dessa
informatização incrementaram ainda mais o diferencial competitivo.
Junto com o processamento on-line, com eficiência suficiente para grande
quantidade de usuários simultâneos, principalmente no Brasil, as instituições
bancárias passaram a investir muito em redes privativas (que em breve foram
substituídas pela Internet), que permitissem aos correntistas acesso a suas contas e a transações que antes somente eram feitas na no caixa humano ou com
o gerente. Além dos bancos, o desenvolvimento de processos on-line deu-se de
modo bastante vigoroso com empresas administradoras de cartões de crédito e de
telecomunicações.
Outra evolução que permitiu, aos usuários mais avançados da tecnologia, que
assumissem um papel mais ativo na transformação de dados em informação de
grande valia, foi o desenvolvimento de linguagens de quarta geração, que proveu
ao usuário o desenvolvimento de sistemas, além das fronteiras das áreas de TI.
Desse modo, os gestores viram uma grande oportunidade de análise das suas
informações, e verificaram a possibilidade de aumento nos recursos de inteligência
organizacional (BI). Com essas novas formas de desenvolvimento de sistemas, em
[24] apresenta uma nova forma de classificação:
• Sistemas Transacionais: que provê suporte às transações e processos da
empresa, e os processos alimentem essas informações no dia a dia, e;
• Sistemas de Suporte à Decisão: que analisam os dados e permitem a visualização dos dados, transformando-os em informação, sob critérios passados
pelo usuário, sob demanda.
Quando as ferramentas disponíveis passaram a prover ao usuário quase leigo a
possibilidade de análise das informações com maior agilidade, os administradores
16
iniciaram um movimento forte na direção de BI, uma vez que seus sistemas transacionais foram desenvolvidos de modo a garantir a operação da empresa, muitas
vezes, com milhões de transações a cada hora.
Para atender, ao menos por alguns anos, surgiram no mercado soluções que
permitiam a obtenção de informações diretamente dos sistemas transacionais.
Desse modo, os chamados Programas Extratores, extraíam os dados transacionais normalmente através de arquivos intermediários, e os carregava em outros
ambientes. Até a extração nos arquivos intermediários, os dados passavam por
transformações e padronizações, que em alguns casos, acarretava em falta de integridade relacional, causando impacto nos resultados da análise, que nesses casos
levavam as soluções ao descrédito.
Um outro impacto significativo, ocorreu quando sistemas que já estavam com
seu poder de processamento e de acesso a disco comprometidos com as transações,
passaram a dar uma nova carga de trabalho, com pesquisas que faziam buscas na
tabela inteira (table scan) para obter os resultados.
Quando os primeiros testes de ferramentas extratoras começaram a apresentar termino anormal (abbend ) as transações, a idéia passou a ficar restrita aos
sistemas de menor importância. Outra questão levantada, era a demora no desenvolvimento e na obtenção dos dados, uma vez que a integração de diversos
sistemas sempre foi (e ainda é) um ponto nevrálgico no desenvolvimento de sistemas de BI.
É possível dizer que BI em sistemas transacionais, com dados oriundos de
planilhas, bancos de dados pessoais, dados em papel, é possível, porém existem
ônus e riscos bastante grandes a arcar, por conta da possibilidade de equívocos, e
de queda importante no desempenho dos sistemas. Também é de suma relevância
que a carência de informações históricas, do momento no qual o fato ocorreu,
prejudicava a análise de diversas informações, pois em geral as informações são
voláteis.
Tais problemas começaram a serem resolvidos com a armazenagem dos dados
tratados em bases de dados centrais, compartilhadas, integradas e que permitissem análises históricas. Assim, as bases naturalmente foram assumindo modelos
de dados semelhantes aos modelos dimensionais. Esse Sistema de Suporte a Decisão - DSS em inglês - recebeu o nome de DW (Armazém de Dados, em português).
Esses modelos, começaram a serem criados na década de 90, quando os modelos entidade relacionamento, com todas suas formas normais já não provinham a
mesma eficiência necessária para consultas que em grande parte, faziam leituras
em toda a tabela (table scan), mesmo quando eram necessários apenas uma fração
dos dados.
Junto com esses modelos, novos métodos de armazenamento e recuperação dos
dados nas páginas de dados, foram criados. Podemos citar que as metodologias
de desenvolvimento de um DW é em diversos pontos muito divergente do desenvolvimento de sistemas transacionais. Além disso, foram desenvolvidos diversos
hardware e software que permitem uma estruturação, administração e consulta a
um DW muito mais eficiente que os até então desenvolvidos.
A compreensão de um DW provavelmente será de grande valia para que administradores conquistem novos caminhos na busca incessante de crescimento em
um ambiente cada vez mais global e competitivo.
17
2.2
Conceitos Básicos
Apesar de tratar-se de uma tecnologia relativamente recente, os conceitos de
DW são bastante convergentes em diversos aspectos. Entretanto, [13] chama de
guerras religiosas que eclodem entre os devotos dos dois principais especialistas
no assunto.
Com o amadurecimento da indústria de sistemas de informação, os conceitos
que circunscrevem o DW foram tomando corpo, e convergindo muito. Segundo o
entendimento de diversos especialistas, [18] e [25] possuem abordagens sobre DW
bastante compatíveis. A maior diferença reside na nomenclatura utilizada.
Em [19] DW é uma coleção de dados orientados por assuntos, integrados,
variáveis com o tempo e não voláteis, para dar suporte ao processo de tomada de
decisão.
Em [23] um conjunto de ferramentas e técnicas de projeto, que quando aplicadas às necessidades específicas dos usuários e aos bancos de dados específicos
permitirá que planejem e construam um DW.
Em [14] define: DW é um processo em andamento que aglutina dados de
fontes heterogêneas, incluindo dados históricos e dados externos para atender à
necessidade de consultas estruturadas e ad-hoc, relatórios analíticos e de suporte
de decisão.
Os três experts concordam que o sucesso de um DW ou de um Data Mart
(DM) depende determinantemente da correta e precisa identificação primeiramente das necessidades essenciais do negócio. Essa correta identificação norteará
a construção do DM da área e orientará os dados que estarão contidos em um
DW.
É possível chamar um DM de supermercado, onde o cliente busca as informações necessárias, enquanto um DW pode ser comparado ao atacadista ou à
CEASA. Com essa concordância dos dois autores, teorias botton-up de desenvolvimento de um DW, embasadas nos dados dos sistemas operacionais, tem apresentado um excessivo consumo de recurso e de tempo, com um retorno limitado
para o foco do DW. Ambos comungam na identificação da necessidade do negócio,
com a visão do usuário, para o Design do mercado, garantindo o atendimento às
expectativas. Após esse momento, o analista de dados identifica qual ou quais
os sistemas mais próprios, e assim solicita o modelo de dados (ou constrói ou faz
engenharia reversa, caso esse não exista).
A partir desse modelo de dados será iniciada a construção da área de trabalho
(Staging Area). Em [24] chama a isso de backroom (quarto dos fundos), enquanto
em [20] chama de DW. Neste local, regras de integridade referencial são aplicadas
através do Sistema Gerenciador de Banco de Dados Relacional (SGBDR); ou
validadas por meio do uso de programas. Ocorrem, também, transformações e
criações de dados, tornando-os mais consistentes, além, é claro, da integração com
demais sistemas de origem.
Bancos de dados transacionais tratam das operações diárias da entidade, ou
seja, são acessados por muitos usuários, e devem suportar incontáveis transações
que tenham sido pré-definidas. Assim, seus dados sofrem alterações constantemente. Suas estruturas de dados devem suportar grande quantidade de acessos
pontuais, em pouca quantidade de registros. Além disso, as formas normais são
18
utilizadas para redução das redundâncias.
Em um DW ou DM há redundância no armazenamento dos dados, em parte
por conta dos focos de análise, que em geral são apresentados em fatos diferentes.
Por exemplo, o foco a partir do departamento de Marketing, sobre as vendas, e
sobre o mesmo objeto, o foco a partir da contabilidade.
As consultas solicitadas a um DW costumam vasculhar grande parte das tabelas em questão, situação que muitas vezes torna um table scan menos oneroso que
a busca através do índice, dessa forma, o modelo de dados deve ser desenhado,
possibilitando a análise com o menor esforço.
Outras estruturas de dados de mais baixo nível foram desenvolvidas por engenheiros de grandes empresas de bancos de dados, reduzem drasticamente a
quantidade de acesso a disco, permitindo acessos a grandes volumes com um desempenho muito superior. Um detalhamento acerca dessas estruturas será feito
na sessão Arquitetura.
Em uma adaptação de [30], a tabela 2.1 identifica algumas diferenças entre
bancos de dados transacionais e DW; bem como mostra as diferenças dos dados
que eles manipulam segundo os autores citados.
A tabela 2.1, entretanto poderá ser alterada em breve, pois conforme Kimball
em palestra ocorrida em SP, já é possível pensar em Petabytes. Em [21], já se
prevê que o DW deverá responder às demandas em tempo inferior ao exposto na
tabela.
Conforme o exposto é possível resumir que um DW pode ser definido como
técnicas e bancos de dados integrados, desenvolvidos de modo a dar suporte a
funcionalidades de Sistemas de Apoio à Decisão, no qual as informações estão
agrupadas em tabelas fatos, que podem ser vistas sob a ótica das dimensões. As
informações deverão prover suporte aos níveis táticos e estratégicos da empresa
(dificilmente operacional). Com as séries históricas, devem possibilitar análises
de tendências, para a tomada de decisões mais convergentes com as metas da
empresa.
2.3
Principais Características
Em [17] DW é definido como: orientado por assuntos, integrado, variável no
tempo e não volátil. Doravante seguiremos essa definição, e será descrito a seguir
mais sobre cada característica.
Tabelas de Fatos, Dimensões e Agregadas
A principal característica de sistemas de DW é a existência de tabelas de
fatos e de dimensões. As fatos e dimensões são definidas como a figura 2.1, de
modo a permitir que as informações (métricas, como por exemplo, quantidade)
sejam visualizadas conforme as classificações (dimensões, que são as arestas da
figura 2.1).
As dimensões são, conforme [25], os pontos de vista através dos quais os
fatos poderiam ser analisados. Pode-se dizer também que as dimensões são as
perspectivas sob as quais as fatos serão analisadas, ou os prismas gerenciais, ou
19
Características
Tipo de dados
Bancos de dados
Transacionais
Detalhados
Organização dos dados
Estabilidade dos dados
Qualidade dos dados
Estrutura dos dados
Por aplicação
Dinâmico
Na entrada
Otimizado para transações
Dados por transação
Freqüência de acesso
Volume
Tipo de informação
Operação
Processamento
Poucos (dezenas)
Alta
Megabytes, gigabytes
Atual e volátil
Atualização
Dirigido à transação
(OLTP)
Não ocorre, ou ocorre
minimamente (normalizado)
Operacional, repetitivo
e estruturado
Funcional com necessidades cotidianas. Decisões
do dia a dia.
Redundância
Uso
Comunidade atendida
Objetivo
Interação
Histórico
Tempo de resposta
Atualização
Disponibilidade
Manutenção do negócio
Pré-definida
Baixo (até 3 meses)
Até 2-3 segundos
Em tempo real
Alta
DW
Detalhados e
sumarizados
Por assunto (fatos)
Estático
No processo (ETC)
Otimizado para pesquisas complexas
Muitos (milhares)
Média para baixa
Gigabytes, terabytes
Histórica e não volátil
Leitura e análise
Dirigido à análise
(OLAP)
Ocorre (desnormalizado)
Informativo, analítico
e não estruturado.
Gerencial, com necessidades gerenciais. Decisões estratégicas. Longo prazo.
Análise do negócio
Pré-definida e ad-hoc
Alto (até 10 anos)
De segundos a minutos
Periodicamente
Atenuada
Tabela 2.1: Comparação entre Banco de Dados Operacionais e DW.
ainda simples por.... Dessa forma é possível analisar a quantidade vendida por
produto, por mês, por loja.
As tabelas de fatos, por sua vez são as métricas sobre o negócio. Podem
ser chamadas de objetos de curiosidade do usuário, ou aquilo que é o foco da
curiosidade do usuário. Como exemplo podemos citar a quantidade vendida, o
valor do faturamento, o valor dos impostos, os saldos de contas contábeis. Essas
tabelas recebem as chaves estrangeiras das dimensões que a compõem. Todas
as consultas às tabelas de fatos somente fazem sentido quando qualificadas por
dimensões (conforme ilustrado na figura 2.2).
As tabelas agregadas são as tabelas fatos que têm alguns tratamentos específicos conforme a necessidade. Estas tabelas podem ser classificadas em três
tipos:
20
Figura 2.1: Representação de um modelo dimensional sobre eixos cartesianos.
• Agregada;
• Agregada de contexto e;
• Agregada restritiva.
Uma tabela agregada tem no máximo as mesmas informações que uma tabela
de fatos ou de dimensão, ou informações derivadas de informações dessa mesma
tabela, porém com um grão maior, ou seja, uma granularidade menor.
Uma agregada de contexto possui informações distintas de qualquer fato ou
dimensão isolada, porém possui informações que podem ser provenientes de operações quaisquer sobre os dados já existentes no banco de dados.
A agregada restritiva possui os mesmos dados de uma tabela, porém com alguns filtros, de modo a conter as informações mais consultadas. Por exemplo,
uma tabela de perfil do empregado que possui diversas fotografias mensais do
empregado ao longo de 37 meses, mas comumente consulta-se o perfil do empregado no último mês. Esse último mês estará em dois lugares ao mesmo tempo:
na tabela agregada restritiva do perfil do empregado somente no último mês e
na tabela do perfil do empregado, nesta última para que seja possível traçar evoluções dos perfis existentes, ou outras consultas que necessitem de mais de um
mês.
Na seqüência serão explicitados alguns dos tratamentos. Para tanto será explicitado o conceito de granularidade.
Granularidade
21
Figura 2.2: Tabelas de fatos e de dimensões.
Antes de definir Granularidade, vamos definir grão de uma tabela fato como
um conjunto de chaves primárias das dimensões que utilizadas simultaneamente
em uma consulta nos permite recuperar uma única tupla (registro do result set).
Deduz-se que seria possível implementar uma chave única na tabela Fato,
bastando concatenar algumas (ou todas) das suas chaves estrangeiras. Quais
chaves seriam estas? As chaves de dimensão que compõem o grão.
Granularidade, portanto, é trata do nível de detalhe ou de resumo dos dados
existentes num DW. A definição da granularidade desejada pelo usuário incide
diretamente sobre o volume de dados: quanto maior a granularidade, menor o
grão; quanto menor o grão, mais dados (nem sempre úteis) serão inseridas na
tabela fato e em algumas dimensões; quanto maior o volume de dados, mais disco
e pior o desempenho alcançado.
Um dos grandes desafios dos analistas que desenvolvem sistemas de DW é
definir a granularidade ótima, que contemple as necessidades do usuário, sem que
lhes falte informações, de modo que as consultas sejam no tempo esperado.
Outra implicação quando são tomadas decisões de armazenar grãos menores,
diz respeito aos índices. Grãos muito pequenos implicam em mais índices e a
indexação mais complexa. Por outro lado, a decisão de armazenar apenas informações com um nível menor de granularidade implica na impossibilidade do
usuário de descer no detalhe da informação.
Em um projeto de Risco de Mercado, a marcação a mercado de todos as
classificações de títulos públicos do governo federal, da data do projeto até a
data dos vencimentos, em cada data, por um período de cinco anos, implicaria
na necessidade de alocação de espaço equivalente a um petabytes (1024 bytes
elevado à quinta potência). Desse modo, o gestor do negócio optou por recalcular
22
a marcação a mercado até o vencimento a cada consulta, armazenando apenas os
parâmetros para tanto. Essa decisão teve um impacto no tempo de resposta, que
passou a ser de um minuto e meio para cada consulta, possivelmente equivalente
ao tempo gasto para consultas semelhantes no DW.
[20] prega que os grãos em um DW devem ser os menores possíveis. Desse
modo, a integração é facilitada, e constrói-se os DM com o grão no tamanho
desejado. Entretanto [23] inicialmente indicava a utilização de grãos no tamanho
ideal, porém as manutenções que aumentavam a granularidade implicavam em
grandes ônus. Posteriormente, em [25], a utilização de grãos menores passou a
ser também bandeira defendida, enquanto em [21], Inmon vai no sentido contrário,
aproximando-se de Kimball.
Ainda assim, com grãos muito pequenos, existem outros custos envolvidos já
citados. Em casos específicos, entretanto, existem DW que utilizam granularidade
que equivalente aos dados encontrados nos sistemas transacionais. Nessas fatos,
é comum que os dados sejam armazenados por pouco tempo, por exemplo, três
meses, e em outras tabelas de fatos, mais agregadas, as informações são mantidas
por cinco ou mais anos.
Para atendimento à alta direção das entidades, entretanto, é comum que sejam
utilizados dados altamente resumidos. Para esses usuários, são construídas interfaces mais amigáveis e mais lúdicas. Essas interfaces, que utilizam fatos mais
agregadas são chamadas Sistema de Informações Executivas (EIS, em inglês).
Nessas interfaces, há casos em que as informações detalhadas compõem informações gerenciais que cabem aos executivos. Esses relatórios costumam demandar
mais tempo para atualizar os dados. Para resolver esse problema a interface deve
prover o recurso ao executivo para que esses relatórios já estejam atualizados
quando esse é aberto.
Na maior parte das empresas, é comum que existam diversos níveis de agregação para a mesma informação. Para tratar casos como esses, existem ferramentas
no mercado que tratam níveis distintos de agregação, e escolhem qual a tabela
mais agregada devem consultar. Nesse caso a escolha independe explicitamente
de uma decisão do usuário.
Em algumas empresas que possuem muitos sistemas legados, problemas para
extrair os dados levam os analistas a criarem tabelas de fatos que contem o mesmo
nível de agregação que o sistema de origem. Nesse caso, é comum que essas
informações sejam todas tratadas, mas nem sempre consultadas nesse nível. A
partir desses dados limpos, as tabelas com níveis de agregação mais adequados
são carregadas.
Os dados de origem tratados, entretanto não são descartados. Mesmo que
nem sempre sejam tão úteis, diversos tratamentos e validações demandam recursos (humanos, tecnológicos e financeiros), portanto o armazenamento de dados
fidedignos passa a ser o menor dos gastos. Os dados, entretanto das tabelas
agregadas podem ser descartados após o período estipulado.
No DW 2.0, conforme [22], os dados não são descartados, mas armazenados em
mídias mais baratas (mídias óticas, fitas ou discos mais antigos ou mais lentos).
Há ferramentas no mercado que consideram essas mídias materiais de consulta,
como se fossem as próprias tabelas do banco de dados. Há casos em que parte
dos dados está em discos, e outra parte em fitas, que não necessariamente estão
23
montadas na máquina. Quando o banco de dados recebe uma solicitação, ele
verifica se os dados encontram-se todos no disco. Caso haja outras informações,
o banco de dados envia uma solicitação para que o robô monte a fita (ou as outras
mídias citadas) e busca a informação nela.
Um exemplo pode ser visto com informações contábeis: legalmente as instituições devem manter as informações contábeis por cinco anos. Guardar as
informações além desse prazo é caro, principalmente se essas informações estiverem disponíveis a qualquer tempo. Supondo que a empresa costuma consultar
as informações de até dois anos atrás. Nesse caso, as informações dos últimos
dois anos estão disponíveis constantemente, as informações a partir daí estão em
discos mais lentos, até cinco anos. As informações mais antigas estão em fitas.
Há ferramentas que conseguem enxergar essas mídias todas como se fossem
uma única tabela, e a ferramenta sabe a regra de segregação. Quando uma
consulta é submetida, a ferramenta identifica a que período refere-se e busca a
informação no local correto. Essas ferramentas também podem identificar consultas que possuem níveis de agregação maiores e menores. Os menores níveis
de agregação (informações mais detalhadas) são enviados para fitas, enquanto os
sumarizados ficam disponíveis.
Tal situação ocorre, pois informações mais sumarizadas costumam ser mais
gerenciais, enquanto informações com grãos menores normalmente são mais operacionais. A alta cúpula da empresa não pode esperar o mesmo tanto que os
gerentes inferiores para obter as informações que lhe cabem.
Integração
A integração é o principal benefício de um DW. Esta afirmação é feita baseada
na experiência pessoal do autor desta monografia, mas a seguir será possível
identificar os motivos.
Uma grande dificuldade para as grandes empresas é a integração de sistemas.
Um DW permite que diversos sistemas que possuem possam ser integrados, convergindo em torno de um assunto (vide Orientação por Assunto). Para que o
processo de integração possa ser executado, consultores e analistas identificam
nos sistemas fontes os objetos de negócio identificados. Muitos dos objetos serão
encontrados em sistemas distintos (exemplo: as informações de recursos humanos
podem ser cruzadas com as informações contábeis).
Nesse processo, haverá, também, uma padronização do que será visualizado
pelo usuário. Os padrões de codificação serão analisados e existirão processos (que
podem ser programas, conversores ou ferramentas) que converterão os diversos
padrões para um único. Uma dificuldade constante para esse processo, ocorre
quando as fontes de dados foram desenvolvidas há muitos anos, e não possuem
integridade, ou estão armazenadas em estruturas antigas. Processos e sistemas
não documentados também dificultam essa junção dos dados.
Um exemplo clássico, citado por quase todos os autores, é a convenção de que
a informação do sexo (que pode ser do cliente, do funcionário, entre outros). Em
um sistema pode ser representado com zero para masculino e um para feminino.
Noutro sistema pode ocorrer exatamente o oposto. Em um terceiro, pode haver
as opções M, F e nulo (NULL). Para que esses sistemas sejam integrados, faz-se
24
necessária a aplicação de um padrão único para sexo, por exemplo, M, F, ou
NULL, para a ausência de informação, e I para outro valor, que é inválido, ou um
outro valor curinga.
Como foi citado, no DW os dados podem ser extraídos de mais de uma fontes
de dados. Essas fontes podem ser das mais diversas e estarem em máquinas e
ambientes computacionais distintos. A origem dos dados pode ser arquivos texto
ASCII, bancos de dados em plataforma alta (Main Frame), plataforma baixa
(PC’s e máquinas UNIX), planilhas Excel, e ainda fontes externas à empresa,
como da Internet. A construção dos Armazéns deve contemplar a possibilidade
de tal integração.
Em geral, as bases de dados devem ser acessíveis ao usuário final através de
ferramentas simples (middleware, que em geral têm dificuldades para conexão aos
Main Frame).
Durante o processo de integração, principalmente de sistemas antigos, o corpo
técnico fatalmente terá diversas pedras para quebrar. Conforme Gartner’s Group,
uma das principais pedras é a qualidade dos dados. A fim de minimizar os impactos decorrentes desses problemas, é comum que os analistas utilizem artifícios
dos mais diversos, entre eles estão a criação de chaves substitutas e a criação de
valores curinga, confomre [15]. Em [16], as características principais das chaves
substitutas (surrogate keys) são:
• Substituem o chaveamento natural;
• Permitem a criação de valores curinga;
• São inteiros seqüenciais crescentes;
• São controladas no processo de carga.
Figura 2.3: Processo de contstrução de um DM.
25
Orientação por Assunto
A orientação por assunto é uma característica que incide sobre todo o DW.
[20] e [25] citam que sistemas transacionais são focados em processos. DW são
focados nos assuntos principais da empresa.
Assuntos são um conjunto de informações pertinentes a área em questão.
Como DW são utilizados pelas áreas mais estratégicas da empresa, os assuntos
tratados nos DW são, portanto, os assuntos mais importantes da empresa. Esses
assuntos devem focar ao máximo o negócio da empresa. Por exemplo, para uma
loja qualquer, é possível acreditar que os principais assuntos podem ser Vendas,
Database Marketing, Customer Relationship Management (CRM) ou qualquer
outro assunto que trate do negócio da empresa. Esses assuntos serão criados fisicamente no projeto de DW em tabelas de fatos.
Variação no Tempo
Outra característica citada na definição de Inmon é a Variação no tempo. Essa
característica significa predominantemente que o DW deve manter históricos dos
dados. Esses históricos serão maiores que os existentes nos sistemas transacionais.
Conforme [23], é comum que nos sistemas transacionais os históricos não passem
de três meses, enquanto no DW pode ser de dez anos.
Ao analisar a missão de cada sistema, é mais fácil de compreender que os
sistemas transacionais devem atender aos processos da empresa, e para analisar
as tendências são necessários mais anos de dados. Para atender aos processos, o
sistema deve responder às solicitações em no máximo três segundos (conforme tabela 2.1), e com tabelas com históricos muito superiores, e acessos que demandam
indexações específicas, essa tarefa torna-se muito mais complicada e cara.
Além disso, sistemas transacionais estão constantemente sendo atualizados,
portanto qualquer consulta a esse sistema refletirá a verdade para o exato momento da consulta. Informações extraídas de um DW, por sua vez, são o reflexo
do momento da carga dos dados. Como as cargas costumam ser mensais, semanais, ou em casos específicos, diárias, tais informações serão fidedignas durante
todo o tempo até a próxima carga.
Um procedimento comum é a extração dos dados na forma de fotografias, que
recebe mais um atributo na composição da chave no DW: a data da extração.
Desse modo é possível comparar as diversas fotografias ao longo do tempo. Essas
são chamadas snapshots.
Como o grão é a menor informação da fato, e o grão da fato é definido por
parte ou por todas as dimensões que exportam suas chaves, é necessário que
a Data também seja uma informação qualificadora. Assim a dimensão Tempo
(chamada de período em muitas instituições) estará presente em qualquer fato de
qualquer DW.
Quando a estratégia das fotografias é adotada para uma fato, é possível afirmar que as informações contidas na fato ou nas dimensões não precisarão de
atualizações, pois essas refletirão o momento da extração. Para as dimensões
existem algumas estratégias que podem ser adotadas para a atualização dos dados (estratégias de Slowly Changing Dimension):
26
• Apaga-se tudo e carrega-se novamente;
• Atualiza-se os registros da dimensão, fazendo-se um append das informações
que ainda não estavam contidas na versão anterior da tabela;
• Versiona-se os registros que sofreram atualização.
O versionamento de registros pode ocorrer em tabelas de fatos (ou fatos agregadas) e de dimensões. O Versionamento é a criação de versões para o mesmo
registro. Tal versão tem uma data de início e uma data de término de validade.
A data de término de validade pode ser definida como uma data futura distante
ou como um valor nulo. Essa decisão depende principalmente dos arquitetos do
projeto, em conjunto com Administrador de Bases de Dados (DBA) de produção,
pois cada fabricante de banco de dados indica uma solução como a que melhor
adapta-se à engenharia que não é apresentada ao desenvolvedor.
Dessa forma, caso um funcionário tenha seu estado civil alterado, e essa dimensão é versionada, o registro anterior recebe uma data de término de validade
do registro, e um novo registro é inserido, com uma chave substituta (surrogate
key) diferente. Registros anteriores existentes na tabela de fatos, continuarão
apontando para as versões anteriores do registro do funcionário, pois essa era a
realidade na época.
Além dos dados, as informações sobre as informações também sofrem alterações ao longo do tempo. Essas informações sobre as informações são chamadas
de Metadados. Assim, a correta documentação sobre decisões de alteração nas
regras de negócio precisa ser inserida nos metadados. Tais alterações podem ser
deixadas de lado nas manutenções, porém após alguns anos, essa documentação
poderá ser a diferença entre uma informação com ou sem credibilidade.
Não Volatilidade
No DW, a carga dos dados e as consultas são as principais operações. Alterações nos dados são pontuais e seguem regras muito rigorosas, de modo a
não permitir que a credibilidade dos dados entre em xeque. Primeiramente, será
explicado o fluxo dos dados no DW.
Após o desenvolvimento do DW, esse se encontra vazio. A primeira carga é
feita extraindo-se os dados completos do sistema fonte. Esses dados passam por
processos de validação e integração, onde sofrem alterações.
Esses dados limpos e (às vezes) validados são carregados nas tabelas de fatos, de fatos agregadas, dimensões e de dimensões agregadas. Quando chegar o
momento de uma nova extração, o mais comum é que sejam extraídos todos os
dados novamente.
Em alguns casos, existem processos de invalidação de registros de tabelas de
dimensão (Slowly Changing Dimension). Esse processo de alteração nos dados
não altera a fidelidade da informação. Outra questão que deve ser levada em
consideração, é que os dados extraídos passam por um processo de ETC, onde
nas fases E e T, os dados sofrem alterações. [19] indica que:
27
Em outras palavras, a maior parte dos dados é física e radicalmente
alterada quando passam a fazer parte do DW. Do ponto de vista de
integração, não são mais os mesmos dados do ambiente operacional. À
luz destes fatores, a redundância de dados entre os dois ambientes raramente ocorre, resultando em menos de um por cento de duplicações.
Credibilidade dos Dados
Dados confiáveis são de suma importância para qualquer projeto de DW.
Muito mais que projetos de sistemas transacionais, os projetos de DW costumam
nascer com rótulos indesejáveis por parte das pessoas que defendem os sistemas
de origem dos dados. Em alguns casos, existem verdadeiras guerras santas para
provar que os dados do DW são ou não são confiáveis.
Por causa do exposto, é essencial que os projetos sejam muito bem trabalhados
para que não reste dúvida acerca da informação. Haja vista que informações
erradas são piores que a desinformação, durante um razoável tempo, os usuários
baterão os relatórios extraídos do DW com um conjunto de planilhas ou telas de
diversos sistemas para se certificarem de que os dados são confiáveis. Se você tem
dados de má qualidade e os disponibiliza em um DW, o seu resultado final será
um suporte à decisão de baixo nível com altos riscos para o seu negócio, afirma
em [4], na data desta monografia diretor do Hurwitz Group, mas na data do livro,
analista do mesmo conglomerado.
Informações como um CPF errado podem não ter impacto quando uma instituição bancária oferece crédito a um cliente, mas poderá ser a diferença entre a
recuperação ou a não-recuperação desse empréstimo não pago.
A qualidade dos dados é tão importante para um DW que as ferramentas de
ETC (ETL, em inglês) já agregam funcionalidades dessa natureza. Essas funcionalidades foram incluídas junto de ferramentas de ETC, pois antes mesmo do
cliente ver os resultados que estão errados por causa da qualidade das informações
dos sistemas de origem, muitos processos de limpeza dos dados já poderiam ter
terminado com erro, pois no campo UF de residência do cliente, foi cadastrado a
sigla BH.
Em projetos que estão sendo implantados, é comum que exista uma camada
intermediária, entre os sistemas transacionais e as fatos e dimensões. Nessa camada, os dados são verificados, para que se tenha certeza de que os dados que
chegaram foram carregados corretamente. Essa camada continuará existindo enquanto o DW existir, porém as consultas a ela somente serão submetidas quando
houver dúvidas sobre a real qualidade da informação.
A Tabela 2.2 de [19], explicita diversas características que servem para assegurar a qualidade dos dados, além de sugerir medidas para a qualidade.
Os Metadados
As informações sobre os dados, ou metadados, são essenciais para projeto de
DW. Normalmente são informações descritas em alto nível acerca das informações
inseridas no DW. Qualquer administrador de dados classifica os metadados como
28
Característica
da qualidade
dos dados
Precisão
Abrangência
Consistência
Coerência
Tempo de resposta
Singularidade
Descrição
Exemplo de medida
Grau de informações
que estão corretas.
Grau de dados requisitados e atendidos.
Consistência dos dados / liberdade de
contradição.
Coerência lógica que
permite criar relações
entreos dados.
Tempo entre o pedido de consulta e a
resposta.
Singularidade dos
dados de mesma
natureza.
Percentual de correção.
Percentual atendimentos.
Percentual de condições
satisfeitas.
Percentual de regras de
integridade referencial
suportadas.
Relação entre a complexidade e o tempo gasto
para resposta.
Percentual dos dados que
têm valores dentro dos
domínios de valores permitidos.
Tabela 2.2: Tabela de qualidade dos dados.
importantes para qualquer projeto que lide com dados. Talvez por isso, em um
DW eles tenham tamanha importância.
Metadados podem ser informações simples como o que significa valor da parcela vincenda, em um projeto de crédito ou de recuperação de ativos; ou informações sobre o mapeamento de origem dos dados, passando pelas transformações
até o destino nas tabelas de fatos e de dimensões.
Metadados de usuários normalmente são informações que descrevem particularidades sobre os dados. No exemplo acima, poderia ser o valor da prestação
A+J (Amortização+Juros), emitida e a vencer nos próximos 30 dias.
Com base nas informações em alto nível que descreverão cada informação
de um DW, o usuário passará a buscar cruzamentos dos dados de forma não
convencional para identificar informações que não eram possíveis serem vistas
nos sistemas transacionais, seja porque os dados do DW provêm de mais de uma
fonte, seja porque não existe uma interface lúdica que indique o que todos os
usuários desejam quando abrem a mesma tela.
Em uma mescla entre as classificações apresentadas por [17] em [25], identificamos os seguintes tipos de metadados:
Metadados operacionais: são os metadados existentes nos modelos de dados
dos sistemas transacionais. Esses metadados são utilizados pelas aplicações
corporativas da empresa. Em geral, para sistemas muito antigos, são muito
desatualizados.
Metadados centrais do DW: são metadados orientados por assuntos. Infor29
mam as transformações e filtros que são executados sobre os dados. Estão
contidos nesses metadados, definições sobre as tabelas de fatos, as dimensões
e agregações, com suas regras de agregação. Contém visões e cruzamentos
de informações. Nele, tempos o mapeamento dos dados que vêm dos sistemas fontes, passam por transformações (como são as transformações) e
filtros, passam pela área de Staging e chegam às tabelas de fatos (e fatos
agregadas) e de dimensões.
Metadados do nível do usuário: são as informações que estarão disponíveis
aos usuários. Essas podem conter qualquer texto que seja coerente, desde
que o usuário compreenda o que realmente significa. O exemplo do valor da
parcela vincenda que foi definida como o valor da prestação A+J (Amortização+Juros), emitida e a vencer nos próximos 30 dias pode não ser inteligível
para qualquer pessoa. Não é necessário descrever regras para cálculos da
amortização e cálculos os juros incidentes, mas caso essa informação agregue
à área, é bom que seja sempre descrito.
Certo momento, em um projeto na área de crédito de um banco, o objeto
NCPD tornou-se necessário para a análise das informações. Tal objeto tem a
regra de formação, que é a concatenação do ano no qual vence a parcela, com dois
dígitos, e o mês também com dois dígitos (AAMM). Durante o preenchimento dos
metadados, identificou-se que NCPD é o número de controle da prestação devida.
O simples significado de NCPD foi, após esse episódio, amplamente divulgado
na área, pois a maior parte dos empregados não sabia que era uma sigla e o seu
significado. Somente conheciam a regra de formação.
Metadados podem conter informações diversas. Em metadados centrais, é
possível incluir controle de acesso, log de acesso, tempo de uso da máquina, desempenho de cada processador, estatísticas de erro, dados sobre os arquivos de
origem, dados sobre o tratamento das informações, ou qualquer outra informação
que seja avaliada como relevante. Enfim, todas as informações sobre o projeto
são importantes para o sucesso de um DW.
Fontes de Metadados
Documentos do o projeto, cadastro nas ferramentas Case, arquiteturas definidas para o projeto, são algumas fontes de metadados para o projeto de DW. A
seguir, serão descritas as principais fontes e tipos de metadados, segundo [20]:
Documentação dos sistemas operacionais: as informações, normalmente não
estruturadas contidas na documentação dos sistemas transacionais, são potencialmente fontes de consultas. Os maiores problemas na utilização dessa
fonte são a compreensão de informações não estruturadas e documentação
inexistente ou desatualizada.
Código fonte dos sistemas operacionais: Não é aconselhável utilizar os códigos fontes dos sistemas transacionais como fonte de metadados, porém
neles existem informações ricas, que podem não ser corretamente interpretadas pelo analista de sistemas, que é uma pessoa técnica e cartesiana.
30
Ferramentas Case: As informações cadastradas nas ferramentas Case, são certamente uma das mais acessíveis fontes de metadados. São dados desestruturados, que estão em um ambiente estruturado. Assim, o repositório
(quando disponível na ferramenta Case) é por si só uma fonte rica de metadados. Esses metadados podem ainda ser carregados nas ferramentas OnLine Analytical Processing(OLAP), ou serem integradas em um ambiente
único.
Fontes primárias: É altamente recomendável que se façam entrevistas com
usuários para obtenção de informações sobre as informações. Mesmo que
as informações estejam em outros documentos disponíveis para os desenvolvedores, nada substitui o entendimento passado pelos analistas de negócio
que realmente entendem do sistema. O cadastro dessas informações como
fontes primárias é essencialmente útil em todos os projetos.
Ambiente e logs do DW: Outra fonte de informações que pode ser utilizada
como metadados, são logs de acesso e do ambiente, quantidade e desempenho de acessos a cada tabela, entrada e saída (E/S) em disco e desempenho
do sistema. Tais informações podem servir inclusive para a proposição de
melhorias dos sistemas, já que os analistas podem sugerir a criação de agregações diversas.
2.4
Tecnologia de DW
Nesta seção diversos aspectos tecnológicos serão apresentados. Partindo da base
do DW (o banco de dados modelado conforme outras técnicas), passando por
arquitetura, ETC, visualização dos dados e a administração de um DW.
Além das classes de ferramentas, serão apresentadas diversas características
importantes para um DW e para sua melhor implementação e seu melhor desempenho. Estas características vão ao encontro das melhores práticas elaboradas
pelos maiores especialistas da área, conforme será demonstrado a seguir.
2.4.1
Modelo de Dados
Kimball, o mentor do modelo de dados multidimensional, indica em [23] uma modelagem de dados diferente dos modelos acadêmicos modelo entidade-relacionamento
(MER).
A construção de um modelo de dados ajuda a compreender as regras
de negócio que o DW irá apoiar. Muitas vezes a equipe que está desenvolvendo o ambiente do DW ignora a fase de construção do modelo
por não ter tempo ou achar que não é uma parte fundamental para o
desenvolvimento. Para Kimball um dos maiores problemas no desenvolvimento do DW é a compreensão dos dados. Segundo ele, são três
tipos de modelos de dados: modelo das regras de negócio ou modelo
empresarial, um modelo dimensional estrela e um modelo dimensional
floco de neve.
31
Em um sistema transacional, logo nas primeiras etapas ocorre a modelagem
dos dados de um MER. Em um DW, o modelo de dados nascerá após a elaboração
de questões, que serão submetidas ao modelo. Tais questões estão voltadas ao
assunto principal do desenvolvimento em questão. Como foi indicado anteriormente, esses assuntos normalmente são referentes às principais e mais importantes
áreas da empresa.
Para o departamento comercial, é possível identificar algumas questões gerenciais relevantes:
• Qual o valor das vendas no último ano?
• E nos meses do último ano?
• Quais as vendas por vendedor?
• Quais vendedores tiveram as melhores vendas?
• Quanto foi a rentabilidade das vendas de cada vendedor?
• Quanto foi o faturamento produto a produto?
Somente depois de elaboradas as principais questões gerenciais, os modelos de
dados serão construídos. Essas questões ajudarão a compor os modelos de dados.
Os objetos da curiosidade serão vistos por diversos prismas, e essa forma de
ver os dados resulta por si só em estruturas dimensionais. Para iniciar um projeto
(seja a partir do zero ou uma manutenção evolutiva), inicia-se normalmente inquirindo ao usuário sobre o que ele deseja ver. Após saber o que ver, questiona-se
acerca dos prismas ou qualificadores que ajudarão a compor a informação. Saber
que um departamento faturou um milhão não significa muito, pois esse faturamento pode ter sido em um mês ou em dez anos, portanto os qualificadores sempre
comporão as informações dos usuários.
Deve-se sempre inquirir sobre todas as necessidades, pois manutenções que
impliquem na alteração dos grãos (para menor) de uma fato podem implicar em
um grande custo, sendo que em muitos casos, a implicação pode ser a completa
perda dos históricos, ou a necessidade de extrações muito onerosas.
É imprescindível para os negócios do mundo globalizado que a tomada de
decisão seja feita no menor tempo possível. Desse modo, ferramentas que são
baseadas em relatórios gerados a partir de SQL feitos sobre as bases relacionais,
das aplicações transacionais da empresa, não tem a mesma tempestividade no
atendimento às demandas que um DW.
As respostas para as principais questões gerenciais das empresas são normalmente uma ou mais medidas de desempenho, vistas por prismas diversos. Esses
prismas serão chamados de dimensões, como visto na seção 2.1. Devido à forma
de visualização das medidas contidas nas tabelas de fatos, que pode ser através
de uma ou mais dimensões, os modelos de dados são chamados modelos dimensionais.
Para Kimball, a modelagem dimensional é uma técnica normalmente utilizada
em projetos de DW, de modo a prover ao usuário uma arquitetura de alto desempenho, e a mais intuitiva possível. Para cada dimensão, a partir da qual é
32
possível a visualização da fato, existe uma coluna na tabela de fatos, que é uma
chave estrangeira da outra tabela.
Em tese, quaisquer tabelas podem ser vistas de na forma de modelos multidimensionais. Em uma tabela de clientes, o atributo renda pode ser considerado
uma métrica. Caso esse atributo não exista, a simples contagem de linhas da
tabela pode ser considerada com uma métrica. Cada um dos demais atributos
pode ser considerado uma dimensão, sendo que, conforme visto na seção 2.3, nem
todos necessariamente qualificam a fato de forma a definir o grão.
Os dados multidimensionais podem ser inseridos em modelos de dados relacionais. Para tanto, é preciso lançar mão de uma das duas formas de modelagem
mais usuais, ou uma terceira forma, que é uma variação das anteriores:
• Modelo Estrela (ou Star Schema);
• Modelo Floco de neve (ou Snow Flake Schema);
• Modelo Estrela Floco de Neve (ou Star Flake Schema).
Modelo Floco de Neve
Uma das formas mais simples de utilização de modelagem de dados para
sistemas de DW é o modelo Floco de Neve. É mais próximo do modelo entidaderelacionamento, academicamente difundido há muitos anos. Nesse modelo de
dados, existem tabelas de fatos (e fatos agregadas) e tabelas de dimensão. As
tabelas de dimensão são estruturas normalizadas de modo hierárquico, conforme
figura 2.4. Como nas estruturas hierárquicas, existe um relacionamento um para
muitos entre as dimensões e as fatos, e entre os níveis superiores das dimensões e
os inferiores das fatos.
Figura 2.4: Modelo Floco de Neve.
Uma característica importante no modelo Floco de Neve, é que nas dimensões há possibilidade de existir métricas, como por exemplo, na dimensão loja,
deixando essa com possibilidade de ter características de fatos. Há que se ter cuidado com esse modelo, uma vez que sumarizações com as métricas das dimensões
podem causar cálculos incoerentes.
33
Por sua vez, esse modelo é mais flexível, pois em uma mesma interface é
possível fazer cálculos com essa dimensão e com a fato, em momentos distintos.
Por exemplo, fazer uma relação entre a área da loja e o valor das vendas. A área
das lojas será objeto de uma consulta e as vendas de outra.
Figura 2.5: Compartilhamento de dimensões no modelo Floco de Neve.
Outra característica desse modelo de dados, é que as dimensões que não estão
no seu nível mais granular podem ser utilizadas por outras fatos ou agregações.
No caso de haver uma fato que reflita a folha de pagamento dos empregados
(característica mensal), as dimensões Ano e Mês serão reaproveitadas do modelo
representado na figura 2.4 e para o modelo representado na figura 2.5.
Modelo Estrela
Um MER possui diversas tabelas e diversos relacionamentos entre as tabelas. Além disso, uma tabela pode ter relacionamentos consigo mesma (autorelacionamento) e uma mesma tabela pode ser referenciada por diversas outras.
Em um MER, são praticamente incontáveis as combinações de entidades e de relacionamentos que podem ser utilizados para obter-se relações entre duas tabelas
quaisquer.
Portanto, quais, dentre tantas relações serão necessárias para alcançar as respostas corretas?
Outra questão que deve ser levada em consideração, é que o usuário desconhece
completamente os modelos de dados. Portanto, para que o usuário não tenha que
tomar decisões, o modelo de dados deve ser o mais simples possível, e não deve
deixar dúvidas ao software quanto aos relacionamentos e tabelas que precisarão
ser utilizadas e referenciadas para a obtenção do resultado almejado.
É nesse momento que nasce o modelo estrela, ou Star Schema. Essa modelagem possui uma tabela de fatos no centro, e ao redor diversas dimensões,
qualificando a tabela de fatos. Cada dimensão possui apenas uma chave que é
exportada para a tabela de fatos. A chave exportada da dimensão é a primária,
que não necessariamente é a chave primária existente nos sistemas de origem dos
dados, uma vez que no sistema em questão, podem existir chaves substitutas,
34
chamadas Surrogate Keys. Além disso, boas as boas práticas de modelagem baseadas mais na experiência que na abordagem acadêmica, indica que as chaves
naturais (chaves primárias dos sistemas de origem dos dados) continuem existindo
na tabela de fatos.
As principais vantagens do modelo estrela são a facilidade de compreensão,
como é possível ver nas figuras 2.6 e 2.7, e o grande desempenho que é possível
obter, sem que sejam feitos relacionamentos entre os diversos níveis hierárquicos
da dimensão.
Figura 2.6: Modelo Estrela de uma tabela de fatos.
Figura 2.7: Modelo Estrela de outra tabela de fatos.
As tabelas de fatos podem conter diversos milhões ou bilhões de registros,
cada um contendo ao menos uma medida. Essas medidas são necessárias para a
tomada de decisões. Esses registros são identificados pela combinação de diversas
(ou todas as) dimensões. A combinação de todos os registros de cada uma das
dimensões com todos os registros das demais dimensões (algo como um produto
cartesiano), tornaria a fato densa.
Supondo uma empresa que possui cem mil empregados, a cada mês, são identificadas as alterações de cargo dos empregados, em uma tabela de fatos. Esta
35
tabela seria densa caso cada um dos empregados passasse em cada mês por cada
um dos cargos. Haja vista a inviabilidade de tais acontecimentos, a tabela de
fatos do exemplo não é densa, mas é esparsa.
A esparsividade é uma das características existentes em todos os sistemas
de DW, com raríssimas exceções controladas. Por causa desta característica, os
sistemas de DW que já têm a fama de consumirem muito espaço em disco, não
ocupam incontáveis vezes a mais. Em um DW, a ausência de informação no
sistema fonte não é gravada como zero, implicando na inexistência do chamado
não-fato, ou não-evento, conforme [31]. Não-fatos são informações que não são
gravadas na tabela de fatos, pela inexistência dessas. Quando são necessárias
algumas informações que indiquem a não ocorrência de determinados fatos, e
essas não estão presentes pois não ocorreram, fala-se que houve problemas por
causa do não-fato.
Suponha que em um terminal que esteve funcionando das 8h às 18h, foram
registradas vendas de diversos produtos. Em uma pesquisa do produto A, foram
identificadas as vendas de 10 produtos, sendo três às 9h, quatro às 11h, dois às
13h e um às 14h. Uma média de vendas por hora traria que foram vendidos em
média 3,5 produtos por hora. No caso, a média seria a média das ocorrências,
excluindo a não-ocorrência de vendas do produto A nas horas não referidas.
Para uma análise correta, seria necessária a carga de informações de zeros para
complementar os espaços vazios, tornando a tabela de fatos densa. Para tanto,
não existe uma solução simples tal qual bala de prata (solução única e genérica
para todos os problemas), mas a cada caso, uma solução deve ser adotada. Uma
sugestão de solução pode ser identificada em [31].
Outra característica relevante provém do tipo de dados existentes em cada tipo
de tabelas. Tabelas de dimensão tendem a ter incontáveis vezes menos registros
que nas tabelas de fatos. Entretanto as tabelas de fatos possuem apenas números,
situação que custa muito menos ao SGBD para armazenamento. Apesar do tipo
de dados das tabelas de fato tender a torna-la menor, é comum em projetos de
DW que estas tabelas ocupem cerca de vinte ou mais vezes mais espaço em disco
que as tabelas de dimensões.
Em casos em que as dimensões possuem hierarquias que seriam definidas em
tabelas distintas no modelo floco de neve (herdado da mesma solução em um
MER), em um modelo estrela essas tabelas serão desnormalizadas e colocadas
em uma única tabela. Desse modo, não são necessários relacionamentos durante
a execução de consultas no banco de dados. Essa situação reduz o tempo de
resposta, conforme benchmark executado em um ambiente controlado, com fatos relativamente pequenas, em algo em torno de 30% a 40%. Citando alguns
exemplos clássicos de hierarquias que são desnormalizadas com freqüência, fazem
parte desta lista a hierarquia de tempo (ano, mês, dia); a hierarquia de município
(município, UF, região geopolítica), produto (produto, linha de produto).
Ao analisar o modelo de dados representado pelas figuras 2.6 e 2.7, pode-se
identificar facilmente que as tabelas de fatos podem ser vistas como uma tabela
associativa entre diversas outras dimensões. Identificando a tabela de fatos desse
modo, pode-se inferir, portanto, que a chave primária dessa tabela é, portanto,
a combinação de todas as dimensões que a compõe. Essa situação nem sempre
é verdade, porém o modelo de dados é implementado dessa forma para aumento
36
no desempenho das consultas, quando submetidas a bancos de dados relacionais
tradicionais, com modelos estrela implementados nele.
Em bancos de dados voltados para DW (a exemplo dos bancos de dados Sybase Adaptive Server Intelligence Query e Teradata), os relacionamentos ocorrem
índice com índice, não necessitando de acesso aos registros propriamente ditos,
conforme [33] e [34].
Em projetos de DW, os projetistas tendem a antecipar algumas consultas a
serem feitas pelos usuários, na forma de agregações. Essas podem ser implementadas sobre o mesmo modelo de dados, de forma que existe, em geral, uma melhora
significativa nos indicadores de desempenho do sistema (menos acesso a disco,
menos uso de memória, menos uso do processador, menor tempo de resposta).
Modelo Estrela Floco de Neve
Uma variação dos modelos apresentados é o modelo de dados Star Flake (algo
como Estrela Floco de Neve). Neste modelo de dados, o principal problema
existente no modelo de dados Snow Flake é resolvido. Neste, as operações com
métricas nas dimensões não são feitas. Desta forma, não aplicadas regras de
agregação que mexem com grãos diferentes e têm como conseqüência a exibição
de resultados multiplicados pela quantidade de vezes que a dimensão tem sua
chave replicada na fato.
É comum que projetistas tenham a tentação de criar modelos estrela floco
de neve, a partir de modelos estrela, haja vista que a escola de todos passou
certamente pelo estudo das formas normais (normalização), dos modelos entidaderelacionamento. Essa tentação deve ser avaliada com muita cautela, pois modelos
estrela têm diversas vantagens sobre os demais, vantagens essas que já foram
citadas até aqui.
2.4.2
Arquitetura
Um DW tem como premissa básica o atendimento a solicitações de informações
diversas, que podem requerer consultas complexas. Esse atendimento deve ser
tempestivo, e apresentar os níveis corretos de detalhes ou sumarizações. Para
tanto, o DW deve ser desenvolvido sobre uma arquitetura tecnológica que não
cerceie as possibilidades criadas no desenvolvimento dos modelos de dados, e
permita as consultas e as inclusões de dados, de modo eficiente.
Como visto anteriormente, os dados de diversos sistemas podem conter informações não encontradas, que precisam passar por transformações e filtros para
possibilitar a integração, e evitar redundâncias.
Haja vista as necessidades específicas de cada projeto, a arquitetura pode variar muito. Uma arquitetura única não é fácil definir. Portanto, serão definidos
apenas alguns componentes básicos existentes em praticamente todos os projetos. Antes disso, será descrito sobre a persistência dos dados em bancos de dados,
quanto a sua localização.
Localização
37
[17] indica que os dados de um DW podem ser armazenados de três modos:
Em local único: Em um banco de dados único, centralizado e integrado. Dessa
forma, um DW maximiza o processamento, e agiliza a captura dos dados. Essa abordagem tem maiores riscos ao investimento, que é grande, e
o retorno incerto até que a empresa adquira maturidade suficiente no desenvolvimento de soluções de DW. Haja vista a integração, o DW passa a
ter possibilidades maiores de prover informações mais diferenciadas e com
maior valor agregado.
Em DM: Em locais diversos, podendo ser em plataformas diferentes. Esse tipo
de abordagem tem um investimento muito menor, haja vista a capacidade
de processamento ficar restrita a cada DM. Nesta abordagem, cada DM
pode estar fisicamente armazenado em locais distintos. Em geral, apenas
algumas dimensões corporativas são integradas por processos externos aos
de cada DM. Em entrevista com o gerente da área de desenvolvimento de
DW da época de uma empresa, em São Paulo, Inmon citou a seguinte
analogia: O desenvolvimento de DM para toda a empresa é muito oneroso.
Isso é o mesmo que dar a uma pessoa faminta um doce. Ela continuará
com fome, e você, para satisfazê-la dará para ela outro doce (outro DM ou
outras estrelas).
Armazenamento de um DW corporativo, com DM para as pontas: · Armazenamento de um DW corporativo, com DM para as pontas: As informações gerais, com o maior nível de detalhes ficaria em uma base de dados
corporativa e integrada, conforme a primeira forma. Nessa base, as informações são mantidas por tempo inferior ao necessário para as pontas. Nas
pontas, são obtidas extrações do DW para cadastro em DM. Nesses DM,
as informações são mantidas por tempo maior. É possível ainda fazer extrações das tabelas de fatos, para incluir informações em tabelas de fatos
agregadas. Nessas, haja vista que a quantidade de registros é ainda menor,
é possível manter os dados por tempo maior ainda.
Componentes Básicos de um DW
Os componentes básicos apresentados na figura 2.8 explicitam componentes
como os extratores, o integrador e as bases de dados. Apesar de poucos componentes, esses são os únicos essenciais para a construção do DW. Quaisquer outras
ferramentas podem ser substituídas ou não serem necessariamente utilizadas.
Extrator
Extrator é a ferramenta que identifica quando os dados devem ser extraídos e
os extrai. Esses programas identificam cada situação que encadeia a necessidade
de extração. São identificadas também quando o programa deve fazer uma extração completa ou incremental. O programa extrator diferencia quando ocorrem
alterações nos dados, e se essas alterações devem ser enviadas ao DW.
38
Figura 2.8: Componentes básicos de um DW.
Essa implementação normalmente é feita pela equipe de desenvolvimento dos
sistemas transacionais, pois conhecem as implicações de cada implementação e a
melhor forma para extrair as informações especificadas pela equipe de desenvolvimento do DW. A cada nova extração, os dados devem ser enviados para processos
de limpeza e integração.
Limpeza e Integração
Os processos de limpeza dos dados visam a integridade da informação. Tais
processos identificam quais registros devem ou não entrar em um DW, e reportam
aos processos extratores quais não entraram e porque.
Caso a quantidade de registros incorretos seja superior ao limite máximo admitido, o programa não carrega nenhum dado no DW, a fim de garantir que se
tenha uma qualidade mínima nos dados carregados.
Em alguns sistemas, o limite pode ser 1% dos registros, mas há sistemas em
que se admite apenas dez registros.
Os processos de integração são implementações de regras que recebem notificações dos integradores ou dos sistemas operacionais, e desencadeiam mecanismos
de união de informações diversas. Durante o processo de integração, são identificadas as regras de criação de chaves substitutas (Surrogate Keys), e regras de
alteração nas dimensões (Slowly Changing Dimension).
Bases de Dados
Por fim, todos os processos de um DW são circunscritos por bases de dados.
Essas bases são as bases dos sistemas de origem dos dados, base da Staging Area
ou a base do DW e dos DM propriamente dita. Essas bases de dados da área
de trabalho e do DW podem ter arquiteturas próprias, de forma a melhorar o
desempenho das consultas, quando em comparação com os mesmos modelos de
dados implementados sobre bancos de dados relacionais comuns.
Em uma pesquisa no banco de dados, o processo mais caro e demorado para o
banco é o acesso a disco. Caso um banco que faça menos acesso a disco para fazer
39
o mesmo trabalho, esse provavelmente terá performance melhor que os comuns.
Pensando nisso, duas empresas desenvolveram bancos de dados que permitem que
o mesmo trabalho seja feito, com menos acesso a disco.
A questão é relativamente simples e será descrita a seguir. É normal que na
implementação de modelos estrela, existam muitas desnormalizações nos dados.
Dessa forma, em uma coluna, por exemplo, de UF, existem vinte e oito registros
distintos, porém em dimensões que podem ter milhares ou até alguns milhões de
registros.
A página de dados de um banco de dados relacional comum grava registros
inteiros, porém, conforme Kimball, em implementações de modelos estrela, podem ter mais de uma centena de atributos. Assim, uma página pode conter
poucos registros, ou em alguns casos, apenas um. Pensando nisso, que algumas
das mais importantes empresas desenvolvedoras de soluções em bancos de dados
desenvolveram produtos específicos para DW.
Nesses bancos, conforme [33] e [34], são gravadas colunas das tabelas em cada
página de dados, otimizando o acesso. Nesses produtos, as páginas de dados
passam a conter dezenas de vezes mais registros daquelas colunas pesquisadas.
Ainda assim, as empresas desenvolveram soluções para as desnormalizações
e dimensões que contém menos que 65536 ocorrências de valores distintos nas
colunas das tabelas de um DW. Essa solução implica na criação de uma lookup
table, sem que o desenvolvedor opte. Para tanto, basta que seja definido que a
quantidade de valores distintos para cada coluna seja inferior a 256 (combinações
de um byte, menos um) ou inferior a 65536 (combinações de dois bytes, menos
um).
Além de a solução incluir cada coluna em páginas de dados, conforme citado
acima, em cada ocorrência na coluna, o banco de dados grava nas páginas somente
um byte ou dois bytes. Em um único acesso a disco, o banco de dados busca a
lookup table completa, que tem uma relação de/para entre o que é gravado nas
páginas de dados e o que essa combinação de bits significa. Nos demais acessos a
disco, o banco busca as páginas de dados, buscando, assim, uma quantidade de
registros bastante elevada.
Caso a quantidade de ocorrências distintas para a coluna, que eventualmente
tenha sido definida como 255, exceda esse número, o banco de dados automaticamente reconstrói as páginas de dados, causando uma pequena demora. O mesmo
ocorre, caso o número que fora definido para 65535, seja excedido, o banco de
dados reconstrói as páginas de dados, para páginas que contém as ocorrências da
coluna. Uma vez que essa reconstrução reescreve o conteúdo completo das colunas nas páginas, existe uma demora significativa, caso a tabela contenha mais
que alguns poucos milhões de registros.
Outra característica desse tipo de bancos de dados é a existência de índices
bitmap (mapas de bits). Nesses índices, cada ocorrência distinta decorre em uma
coluna nova no mapa de bits. Nessas colunas, são gravados os valores zero ou um,
sendo zero a ocorrência de qualquer valor diferente do referente àquela coluna,
e um para o valor igual. Pesquisas nos mapas de bits são muito mais rápidas
que pesquisas comuns. Entretanto, caso o número de colunas (cardinalidade, ou
seja, quantidade de valores distintos) seja muito grande (dependendo do banco de
dados, esse número pode ser entre 100 e 1.500), as pesquisas nos mapas passam
40
a ser mais demoradas que em índices de árvores B1 .
Além desses índices, os bancos para DW ainda possuem índices tradicionais,
como índices que utilizam árvores B, por exemplo. Para a carga, alguns produtos
ainda permitem que o banco de dados comunique com os processadores, e envie
uma coluna para cada thread, maximizando muito a performance na carga.
Portanto, a utilização de bancos de dados específicos para DW, pode melhorar
muito o desempenho em sistemas dessa natureza.
2.4.3
ETC
A fase do projeto de DW que mais demanda cuidados do gerente de projetos, logo
após o levantamento de requisitos, é o ETC. Nessa fase, é exigido um tato muito
apurado do gerente, inclusive pelo tratamento com outras áreas da tecnologia,
responsáveis pelo desenvolvimento dos sistemas que serão fontes de dados para o
DW.
Nesta etapa, os arquivos recebidos, normalmente em formato texto (ASCII),
são filtrados para a identificação de erros diversos, antes da carga ou da integração,
no DW.
Por causa de uma aparente ausência de complicação no processo de extração,
os gerentes de projeto costumam subestimar a complexidade de uma extração
prezando pela qualidade da informação e obediência às regras negociais. Doravante cada etapa será explicada com mais detalhes.
Extração
Um dentre vários cuidados que os gerentes de projetos precisam ter durante
o desenvolvimento de um DW, diz respeito às transformações nos dados durante
a extração nos sistemas fonte.
É comum que os dados extraídos não façam referência com a realidade, uma
vez que extrações para DW não costumam ter a devida atenção dos desenvolvedores dos sistemas transacionais. Essas extrações podem demandar operações
complexas, e alteração no formato dos dados, ou até mesmo a criação de informações novas a partir de operações ou cálculos específicos.
Algumas ferramentas de ETC fazem conexão ao banco de dados, extraem a
informação já no formato, demandando uma carga de trabalho extra ao sistema
transacional. Em casos de sistemas transacionais que já trabalham próximo ao
limite de processamento e de acessos a disco, essas ferramentas podem acessar
de modo simples os dados na origem, transferindo as informações para outra
máquina, onde o processamento mais complexo pode ser feito.
Após todas as transformações exigidas na extração, os dados podem possuir
máscaras próprias, diferentes das existentes na origem. Apesar de não ser comum,
é possível que existam fontes de informação alternativas, como planilhas Excel,
ou arquivos DBF.
1
Árvore B é uma estrutura presente em praticamente todos os banco de dados relacionais
atuais.
41
O tratamento dessas informações e de diversas fontes passa pela etapa seguinte
do processo de ETC.
Transformação
Após as extrações os dados sofrerão transformações internas ao DW. Dentre
as transformações, a primeira e mais básica é a verificação registro a registro de
tipologia e obrigatoriedade da informação.
Existe também a unificação de padrões (como por exemplo, M para Masculino e F para Feminino), integração dos dados conforme regras definidas pelos
analistas de negócios em conjunto com os desenvolvedores.
Carga dos dados
Por fim, após transformações, os dados são carregados. Nesta fase são feitas
exportações de chaves estrangeiras, verificação de integridade referencial e aplicação das regras de Slowly Changing Dimension (e consequentemente a criação
das chaves substitutas).
2.4.4
Visualização de Dados
Nesta subseção, serão apresentados alguns conceitos presentes nas ferramentas de
acesso e visualização de informações existentes em um DW.
OLAP
A partir de agora, as informações já se encontram disponíveis no DW. No início
dos sistemas computacionais a cada novo relatório, um grupo de desenvolvedores
programava cada relatório para os usuários. O trabalho desse tipo passava a não
ser produtivo, além de, qualquer alteração de um nome de uma coluna, implicar
na revisão de boa parte dos relatórios. O OLAP propiciou, então, a possibilidade
de análise e cruzamento de informações on-line, sem a necessidade de envolver os
técnicos e analistas da área de TI da empresa.
Além do conceito de OLAP, outras letras passaram a serem incluídas no nome,
e denotam desde a forma de acesso à informação, onde o cubo é processado,
ou a arquitetura tecnológica de banco de dados que está por trás do OLAP. O
simples nome OLAP denota que as informações podem ser processadas on-line
pelo usuário para acesso ao armazém ou ao mercado.
A partir de agora, as funcionalidades e características serão expostas.
Características e Funcionalidades
Qualquer ferramenta OLAP deve possuir alguns requisitos mínimos para serem classificadas assim. São eles:
Drill Down: pode ser considerada como deixe-me ver o detalhe (um nível de
detalhe a mais);
Drill Up: pode ser vista como deixe-me ter uma visão mais ampla (um nível de
detalhe a menos);
42
Drill Across: é o mesmo que os anteriores, porém pulando dois ou mais níveis
para baixo ou para cima;
Drill Throught: é a possibilidade de passear entre as dimensões. Ao descer,
por exemplo, de ano para mês, e de mês para loja. Pode ser considerado
deixe-me ver por outro ângulo;
Slice and Dice: em uma tradução livre é o corte e o picadinho. É a possibilidade de o usuário cruzar as dimensões na ordem que bem entender,
transformando tabelas simples em referências cruzadas, por exemplo.
Outras funcionalidades comuns a diversas ferramentas não são obrigatórias,
mas serão descritas abaixo:
Alerta: é semelhante à formatação condicional;
Ranking: é a possibilidade de selecionar os melhores, maiores ou menores, piores;
Filtro: é a possibilidade de apresentar informações a menos que as buscadas pela
consulta;
Classificação: é a possibilidade de ordenação na ordem crescente, decrescente
ou ordem definida pelo usuário;
Quebra: é a possibilidade de separar resultados parciais a cada vez que uma
determinada coluna muda seu valor.
É possível ver em literatura específica, classificações do OLAP quanto ao local no qual o cubo, que é resultado da consulta ao banco de dados, é trabalhado.
São encontradas, sob essa classificação Desktop OLAP e Reference OLAP e Multidimentional OLAP (DOLAP, ROLAP e MOLAP, respectivamente). Este último está em duas classificações ao mesmo tempo, e será descrita na classificação
quanto à arquitetura de bancos de dados envolvida.
Os títulos que classificam quanto à arquitetura de bancos de dados são Relational OLAP (ROLAP), MOLAP e Hybrid OLAP (HOLAP).
OLAP quanto ao processamento do cubo
DOLAP Ferramentas DOLAP submetem consultas ao banco de dados, e esse
retorna o result set completo, que será visto pela ferramenta DOLAP como
um micro cubo, e está fisicamente na máquina cliente.
ROLAP Ferramentas ROLAP possuem um servidor OLAP. O cliente envia u
uma consulta ao banco de dados através do servidor OLAP. O result set é
enviado ao servidor, e lá é armazenado.
OLAP quanto à arquitetura de banco de dados
43
ROLAP É o OLAP que acessa as fatos e as dimensões em bases de dados relacionais.
MOLAP É o OLAP, em arquitetura proprietária de cada fabricante, que utiliza
bancos de dados multidimensionais (MDDB).
HOLAP É uma arquitetura proprietária de cada fabricante, que utiliza bases
de dados relacionais e cubos ou bancos de dados multidimensionais.
Haja vista que esta monografia não tem a intenção de referendar arquiteturas
já consagradas como bancos de dados relacionais, somente será descrito em detalhes como um MDDB trabalha.
MDDB
Antes de definir MDDB propriamente dito, alguns conceitos sobre o Banco
de Dados Relacional serão repassados. Para isso será considerado um banco de
dados com diversas tabelas, relacionamentos e cardinalidades.
Para consultar os bancos de dados e fazer relatórios com esses dados, é necessário conhecimento do Banco de Dados, das tabelas e dos atributos de cada
tabela. Para utilizar alguns cálculos nas consultas como, por exemplo, multiplicar
quantidade vendida, pelo preço unitário, para se encontrar a receita de vendas,
existem duas opções:
• Escrevê-los na instrução SQL a ser enviado ao banco de dados relacional,
com o propósito de recebermos do banco de dados os dados já computados;
• Ou somá-los localmente com ferramentas DOLAP.
Na primeira situação, o servidor de bancos de dados precisa processar os
cálculos, resultando em certa demora no recebimento do result set. Enquanto
na segunda, o computador local processa tais informações, resultando, portanto,
numa demora na análise.
O que aconteceria se um banco de dados contivesse tais cálculos, e não possuísse relacionamentos? Um banco de dados que vetorialmente encontra as informações dispostas no corpo de uma figura n-dimensional, onde cada uma das
n dimensões já está sendo uma forma de análise da informação. Este Banco de
Dados será descrito a partir de agora, conforme [11].
Baseado na modelagem de dados multidimensional, o MDDB é um banco que
dá suporte e aperfeiçoa manipulações matemáticas, financeiras, estatísticas e de
tempo. Um MDDB oferece um ambiente muito recomendado para usuários que
necessitem habilidade de analisar fatias dos dados em um único local.
Com base nas agregações, este banco de dados oferece aos usuários finais
os valores que estes necessitem, mesmo que tais valores requeiram uma análise
matemática, estatística ou financeira mais sofisticada.
Para enxergar de forma um pouco mais didática, um exemplo de DM com 3
dimensões (Geografia, Tempo e Produto) em um MDDB mostrado na figura 2.9.
Neste caso está demonstrada uma implementação MOLAP, para que seja possível
44
o acesso das aplicações. Cada aresta representada deste cubo, antes de fazer
parte do MDDB, foi uma dimensão da implementação ROLAP, utilizando o Star
Schema da figura 2.10.
Figura 2.9: Exemplo de Cubo com 3 Dimensões.
Figura 2.10: Tabelas no Modelo MDB.
Nesta implementação são informadas ao MDDB a tabela FATO, e as tabelas
que serão as DIMENSÕES do nosso cubo. Conforme mostra a figura 2.10, para
acessar a informação, o cliente OLAP informa ao servidor as coordenadas:
• Ano=1999,
• Linha de produto = Luxo e
• Região = Centro-Oeste.
Desta forma o MDDB encontra a receita de vendas referentes a essa informação
e, logo após a envia ao cliente que a requisitou.
A escalabilidade é outra característica dos bancos multidimensionais. Estes
bancos são projetados para suportar um número muito grande de usuários simultaneamente, sem que haja degradação no seu desempenho.
45
Agregações em um MDDB
Em um MDDB, é possível encontrar todos os cálculos que envolvem os valores
do MDDB. Como conseqüência, as queries não requerem processamento algum
do servidor. O processamento no servidor demora na maioria das queries menos
de 5 (cinco) segundos, e em quase todas as queries, até 10 (dez) segundos.
Possuir esses valores previamente calculados, na importação dos dados (précomputação), é a mais importante característica dos bancos multidimensionais.
A tabela 2.3 mostra exemplos de agregações com dados fictícios. Quanto maior
a quantidade de agregações, mais rápida tende a ser a query, uma vez que não
haverá cálculos no servidor, tampouco na máquina local, no caso de um software
cliente DOLAP.
Nacionalidade
Carros Nacionais
Carros Importados
TOTAL
SP
352.950
126.290
452.240
RJ
220.530
90.850
311.380
MG
251.830
93.870
345.700
TOTAL
825.310
311.010
1.136.320
Tabela 2.3: Exemplo de Agregação com Dados de Vendas. Receita de vendas do
3o trimestre de 1999.
Muitos valores agregados são predefinidos pelo MDDB, como no exemplo da
tabela 2.3. Cálculos simples como totais de vendas e médias aritméticas, já são
previstos pelo MDDB ao processar as informações, desde que as hierarquias, medidas e dimensões, sejam corretamente modeladas.
Mas não existem somente vantagens em um número muito grande de valores
agregados. A explosão de dados que ocorre quando o número de agregações
é muito grande é de vital importância quando dimensionamos o hardware. O
número de agregações em um MDDB é uma função, principalmente do número
de dimensões e dos níveis de hierarquias.
A figura 2.11 mostra uma hierarquia freqüentemente encontrada em praticamente todos os modelos OLAP (MDDB ou Star Schema em SGBDR) é relacionada à dimensão tempo.
Figura 2.11: Hierarquia Comum nos Modelos OLAP.
Observando-se o exemplo, o ano de 1999 exibe os 4 trimestres, cada um deles
46
tem seus 3 meses de vendas, cada mês seus dias, até que alcançar o grão seja ele
dia, hora, minutos ou ainda segundos.
Ao ascender na hierarquia dentro do MDDB qualquer, serão visualizados valores persistidos cada vez mais agregados. No exemplo a receita de vendas do 1o
trimestre de 1999 é um valor que agrega todos os grãos referentes a este trimestre, enquanto a receita de vendas de 1999 agrega as receitas de vendas de todos
trimestres desse ano.
Apesar de cada ano ter 4 trimestres, não é obrigatório que em certo ano, para
determinado produto, haja todos os trimestres de vendas. Mesmo não havendo
esta informação, a economia de espaço em disco, que se tem, é mínima, como
mostrado na tabela 2.4.
Linha de produto
Utilitários
Luxo
TOTAL
SP
45.360
153.200
198.560
RJ
Valor nulo ou faltando
79.080
79.080
MG
52.250
45.600
97.850
TOTAL
97.610
277.880
375.490
Tabela 2.4: Tabela com Exemplo de Informação Incompleta.
Considerando o banco de dados relacional, a falta desta informação teria como
conseqüência uma economia considerável de espaço. Em um MDDB, a economia
de espaço torna-se irrelevante, pelo fato da falta de uma informação não interferir
na existência dos valores agregados. Um valor agregado depende de diversos
outros valores para existir, como no exemplo da tabela 2.4, que o agregado Receita
Total de utilitários do mês de Dezembro de 1998, e o agregado Receita Total do
RJ, referente a Dezembro de 1998. A falta de um único valor não afetaria o espaço
em disco para armazenar estes agregados.
Utilizando um número médio de agregações, e considerando a complexidade
e hierarquias destas, há, então, em média uma explosão de dados com um fator
de 240, ou seja, 15Mb de dados brutos (arquivos em texto) se transformarão em
um cubo que necessite de, em média, 3,6GB para administrá-lo.
Cubo Físico X Cubo Lógico (Virtual)
Quando um MDDB é modelado, um cubo físico é criando, o qual deverá
ocupar espaço em disco para armazenar os dados e muito mais espaço em disco
para administrá-los. Cubos físicos têm apenas uma tabela fato. Como se pode
criar um modelo multi-estrela em um MDDB? Para tal, outra questão deve ser
respondida: Como criar cubos de um diagrama multi-star ?
A resposta da questão acima responderia também outra situação muito relacionada à escalabilidade de DM: Se em uma entidade existem algumas filiais,
e há muitas informações em cada, de que forma não armazená-las em um único
cubo? Como seriam distribuídos esses cubos em diversos servidores, sendo que
os tomadores de decisão deverão enxergar apenas uma estrutura? Em ambos
os casos, quando estamos modelando um MDDB, a solução parte de um mesmo
ponto: Ter dois ou mais cubos físicos em seu DM.
Quando existem dois ou mais cubos físicos no MDDB, e o cruzamento das in47
formações é necessário para as análises, há que se criar um cubo lógico contendo
as informações de ambos os cubos, mesmo que, cada um esteja em um servidor diferente, o que aumenta ainda mais a velocidade, requerendo menos processamento
de cada servidor.
Figura 2.12: Criação de um Cubo Virtual no MDDB.
A criação de um cubo virtual (figura 2.12)parte do princípio de que existem
dados em comum, entre as dimensões dos cubos físicos. Desta forma, temos
um relacionamento entre os cubos. Para o usuário final, os cubos físicos serão
apresentados apenas como um cubo lógico, como mostra a figura 2.13.
Figura 2.13: Os Cubos Físicos pela Visão do Usuário.
No caso da figura 2.13, há um cubo virtual, composto de dois cubos físicos,
sendo o MDDB da direita a matriz, e o MDDB da esquerda a filial. As dimensões Produto (que possui a hierarquia: Produto, Linha de Produto) e Tempo
(composta de: Dia, Mês e Ano) são comuns aos cubos Matriz e Filial. Dessa
forma, apenas uma dimensão apresenta sua estrutura alterada que é a dimensão
Geografia. Nas demais dimensões haverá apenas um acréscimo de dados.
O cubo virtual não ocupa tanto espaço em disco como o cubo propriamente
dito. É como se fossem diversos índices de bancos de dados relacionais. Todo o
48
processamento das queries não é feito no servidor, onde está o cubo lógico, mas
onde estão os físicos.
Arquitetura do Cubo OLAP
O principal objeto do processamento OLAP é o cubo. Uma representação
multidimensional, dos detalhes e resumos de dados. Um cubo consiste em uma
fonte de dados com dimensões, medidas e fatias de informações. Os cubos são
projetados e baseados nas exigências de análises dos usuários. Um DW pode
suportar muitos cubos diferentes, tais como, um cubo de vendas, um cubo de
estoque, e assim por diante. Um cubo tem fontes e servidores, a partir dos quais
se carregam os dados predefinidos, bastando apenas carregá-los periodicamente.
Um Cubo mapeia as informações referentes a cada uma das tabelas de onde
provém cada dimensão do DW, bem como níveis de hierarquias, assim como a
dimensão geografia, que pode ter como níveis: continente, país, estado, cidade
e bairro. As dimensões podem ser criadas separadamente, e compartilhadas entre cubos para facilitar a construção de outros cubos e assegurar a consistência
dos dados a serem analisados. Por exemplo, se a dimensão Produto é compartilhada com os cubos, Vendas e Estoque, teremos então uma fidelidade nestas
informações: jamais será vendido um produto que não esteve no estoque.
As medidas são os valores numéricos da tabela, fatos que são agregados para
a análise, tais como o preço, o custo, ou a quantidade vendida.
As partições são os recipientes de armazenamento multidimensional que guardam os dados dos cubos. Cada cubo contém pelo menos uma partição, e os dados
de um cubo podem ser combinados de múltiplas partições. Cada partição pode
fazer a análise de seus dados de uma origem diferente, e pode ser armazenada em
um local separado. Os dados de uma partição podem ser atualizados independentemente de outras em um cubo. Por exemplo, um cubo está dividido em diversas
partições, separadas pela dimensão tempo. Em uma partição e são encontrados
dados referentes ao ano atual, em outra, dados referentes ao ano anterior, e uma
terceira, todos os dados históricos referentes aos anos anteriores.
As diferentes partições de um cubo podem ser armazenadas independentemente, utilizando-se modelos diferentes e com granularidades distintas. As partições são transparentes ao usuário final, para o qual o cubo parece ser um único
objeto, contudo fornecem ao administrador um excelente leque de opções para
controlar os metadados do cubo OLAP.
Um cubo virtual é uma visão lógica de pedaços de um ou mais cubos. Um cubo
virtual pode ser usado para unir cubos relativamente distintos, que compartilham
uma ou mais dimensões comuns, assim como os cubos de vendas e de estoque.
Para certas análises especiais, quando pretendemos cruzar os dados de vendas com
os dados do estoque, guardamos os cubos separados para facilitar a administração.
As dimensões e as medidas podem ser selecionadas através dos cubos juntos, para
serem apresentadas no cubo virtual.
49
2.4.5
Administração
Como qualquer sistema, um DW deve ser administrado após seu completo desenvolvimento. Manutenções diversas são necessárias em qualquer sistema, porém
em sistemas de BI essas manutenções são muito mais freqüentes devido à dinâmica dos mercados. Assim nasce o conceito de Data Warehousing, pois o gerúndio
é aplicado em um sistema que está constantemente em manutenção e evoluindo.
Devido à complexidade dos sistemas de DW, cerca de um terço dos projetos
sequer passam do papel ou esbarram em incontáveis problemas. Esta quantidade
de sistemas, tão superior à quantidade de sistemas transacionais que vão à falência
antes mesmo de nascerem, se deve às grandes cifras envolvidas no projeto.
Outro problema deve-se ao prazo de projeto, que, dependendo da abordagem,
pode ser por volta de dois anos. Considerando que, no mundo corporativo, o
retorno do investimento dos projetos devem ser bastante vantajosos, a alta administração das empresas nem sempre vê o DW como uma alternativa para seu (às
vezes curto) mandato.
A figura 2.14 demonstra os recursos necessários durante um projeto de DW.
A última fase crescente, sem uma legenda, são manutenções evolutivas.
Figura 2.14: Desembolso em um projeto de BI
No início do projeto, o custo já é relativamente alto. O corpo técnico envolvido é pequeno e composto de consultores. Apesar de ter relativamente poucas
pessoas envolvidas, o corpo é caro, e envolve gerentes diversos, elevando o custo
do projeto. Aos poucos, novos recursos são envolvidos, como projetistas de ETC,
DBA, e uma equipe grande de programadores e analistas. Ao término do desenvolvimento, entra em ação o usuário para testes em produção e para informar
aos desenvolvedores que muito deve ser revisado, e outras questões tiveram seu
escopo alterado durante o ciclo de vida do projeto, tornando o DW um pouco
defasado e exigindo manutenções.
Segurança no DW
Junto com a popularização das grandes redes de computadores, grandes facilidades foram criadas, inclusive facilidade de quebra de sigilo de informações
importantes da empresa e facilidade de que pessoas invadam a empresa através
dessas redes, e modifiquem informações que não deveriam ser modificadas.
Dessa forma, o DW além de uma ferramenta que é um excelente diferencial
competitivo, também cria a possibilidade de pessoas mal intencionadas buscarem
50
informações restritas, integradas e de alto valor agregado. Será visto neste documento questões de segurança divididas nos níveis de banco de dados, rede e
front-end (ferramentas OLAP).
Banco de Dados
Os SGBD, são certamente o principal alvo de qualquer pessoa mal intencionada, devido à importância das informações para qualquer empresa. É necessário
que o SGBD seja administrado de forma competente, pois esse é o nível no qual
mais se tentam invasões em uma empresa.
É importante que cada usuário tenha o seu perfil de acesso controlado, e
veja (somente select) exatamente o que é necessário para seu uso no trabalho.
Nem mais, nem menos. É bom que todos os acessos sejam controlados (gravar
log do SGBD), e monitorados. Ao verificar uma invasão ocorrida em sistemas
do governo federal, identificou-se que no dia anterior, mais de um milhão de
tentativas frustradas foram computadas.
Ter dados criptografados não é cuidado excessivo.
Rede
Dada a possibilidade de acessos não autorizados conseguirem êxito, o uso de
Firewall é extremamente recomendado para a Internet e para a Extranet das
empresas. Outras ferramentas como roteadores de filtragem e software que simulam êxito na tentativa, levando o usuário não autorizado a acreditar que está
chegando ao seu objetivo também auxiliam na prevenção aos ataques.
Neste nível também é recomendado o uso de criptografia, além de certificação
digital. A tecnologia SSL está a disposição para auxiliar na antecipação de tentativas.
Nível de Ferramenta de Visualização
Ferramentas OLAP também podem ser atacadas, portanto devem se precaver
e utilizar sistemas de segurança (em geral proprietários). Em geral possuem
características em comum com os SGBD, porém são mais frágeis.
Para reduzir suas fragilidades, elas podem utilizar a segurança dos sistemas
operacionais e dos sistemas de bancos de dados, de forma integrada.
É possível, também, permitir ou proibir funcionalidades próprias, como atualização dos dados ou visualização dos comandos de bancos de dados utilizados.
É imprescindível que o usuário (login) da ferramenta OLAP que acessa o banco
de dados do DW, somente acesse para leitura.
Administração das fontes de dados
Uma questão importante na administração de um DW é a administração das
fontes de dados. À medida que os sistemas de DW amadurecem, crescem, também, a quantidade de informações que são carregadas. É comum que as origens
51
dos dados sejam as mais diversas possíveis, como equipamentos de grande porte,
arquivos TXT, outras bases de dados que estejam na mesma plataforma do DW.
Para cada sistema, sugere-se que se utilize uma plataforma única, pois o controle de diversas plataformas é muito complexo. Se for possível utilizar um tipo
único de arquivos, por exemplo, texto ASCII, a administração será facilitada, pois
é possível criar um framework que trate as informações. Para que se tenha um
controle, é importante que as informações estejam à mão, como no exemplo da
tabela 2.5.
Arquivo
Sistema
Origem
SISCLI
BD
Cliente
Plataforma
Origem
IBM
Crédito
IBM
SISCRE
DB2
Unidades
SUN
Finança
SUN
Inf.
Compartilhadas
Fina
Tabela
Destino
Cliente
Cobrança
Cliente
Inadimplência
Periodicidade
Diária
Horário
Diária
04:00
IQ
Unidade
Diária
00:45
Oracle
Movimento
Tesouraria
Diária
05:00
DB2
05:00
Tabela 2.5: Administração das origens.
ETC
A devida documentação dos processos de ETC, são essenciais para as manutenções evolutivas. Processos bem documentados e repletos de comentários
auxiliam aos desenvolvedores, mesmo que a manutenção seja feita pela mesma
equipe que desenvolveu a solução. As regras de integração precisam estar claras,
mesmo que não sejam simples. A tabela 2.6 mostra um exemplo simples de controle que pode ser adotado pelas empresas.
Tabela Origem 1
Cliente STG
Inad STG
Inad STG
Tabela Origem 2
Cob STG
Cliente STG
Cob STG
Destino
Cliente
Cliente
Cobrança
Regra
CPF iguais
CPF Iguais
Append
Tabela 2.6: Administração das origens.
Administração dos Bancos de dados
Os dados chegaram na plataforma onde o DW se encontra. Doravante esses
dados são carregados nas tabelas se staging. É bom que a cada carga, informações
sobre o processamento sejam gravados, por exemplo na tabela 2.7.
52
Arquivo
Cliente
Cliente
Cliente
Crédito
Crédito
Crédito
Etapa
Carga STG
Transf.
Carga Dim
Carga STG
Carga STG
Transf.
Tabela
Cliente STG
Cliente STG
Cliente
Cob STG
Cliente STG
Cob STG
Início
20/6/6
20/6/6
20/6/6
21/6/6
21/6/6
21/6/6
05:02
05:23
05:45
04:06
04:06
06:06
Fim
05:23
05:44
06:03
06:03
05:24
06:41
OK
OK
OK
NOK
OK
OK
OK
Motivo
null
null
PK Dup.
null
null
null
Tabela 2.7: Controle Staging Area.
Após o controle dos processos, é importante que sejam administrados os objetos do banco de dados. Essa administração está presente em nas rotinas normais
dos administradores de bases de dados, administradores de dados e administradores de modelos de dados, portanto, não é necessário descrever formas de administração e controle específicos.
Ferramenta OLAP
A administração das ferramentas OLAP em um DW está fortemente ligada
às questões de segurança, já descritas nesta subseção, e à administração dos
metadados. Nesta ferramenta, estão disponível para os usuários, os metadados
negociais, e aos desenvolvedores, metadados superficiais de modelagem de dados
e regras aplicadas nos bancos de dados.
Uma vez que as ferramentas OLAP já fornecem uma interface amigável para
cadastramento de cada um dos metadados, não será necessária a descrição dessa
interface. Além do mais, esta interface é proprietária de cada ferramenta.
Gerenciando vários Ambientes
Para garantir a integridade da informação, e facilitar a administração dos
sistemas de DW, principalmente enquanto esses sistemas estão em manutenção
(o que ocorre freqüentemente), a maior parte das empresas divide os ambientes
para que uma alteração em uma série de programas que já dão carga no DW ou
já tratam os dados, divide os ambientes em dois ou três.
O ambiente de desenvolvimento é um ambiente menos controlado, onde boa
parte dos controles está nas mãos dos desenvolvedores. Nele todo o desenvolvimento é feito, e somente quando concluído passado ao próximo ambiente (homologação ou produção).
O ambiente de homologação (não está presente em boa parte das empresas)
simula a falta de controle dos analistas que desenvolveram o sistema, bem como
serve para que o usuário passe a ver o DW. Somente após a efetiva homologação
os sistemas são enviados à produção. A homologação de um DW é mais complicada que dos sistemas transacionais, pois um DW precisará de um volume de
dados muito expressivo para que seja efetivamente homologado. Dessa forma, é
incomum que exista ambiente de homologação para DW.
O ambiente produtivo (ou Produção) é onde os dados reais são carregados, e
53
onde são efetivamente identificados problemas no desenvolvimento do DW. Haja
vista que, em geral, os dados reais não são vistos nem mesmo no ambiente de homologação, somente neste ambiente o analista identificará os erros, pois passará
a conhecer a qualidade dos dados.
Qualidade dos dados
Um dos principais fatores de insucesso de um DW é a qualidade dos dados.
Em uma empresa, há anos não era exigido o cadastramento do CPF para
concessão de empréstimos. Muitos clientes não possuíam tal documento, que
tem uma regra de validação. Os empréstimos podiam (e podem) ser feitos para
pessoas físicas e jurídicas.
Quando o cliente torna-se inadimplente, a empresa não tinha como cobrar boa
parte dos empréstimos, pela ausência do número do documento de CPF. A partir
daí, a empresa exigiu que o campo CPF fosse preenchido, e colocou a regra de
validação dos dígitos verificadores.
Os números 111.111.111-11, 222.222.222-22,..., 999.999.999-99 são números
que têm seus dígitos válidos. A partir do momento que os números supracitados
passaram a não serem mais válidos, uma quantidade muito grande de empréstimos
passou a ser feita com o CNPJ da empresa Sousa Cruz. A pessoa que cadastrava,
caso o cliente não tinha o CPF, utilizava o CNPJ da carteira de cigarros que
estava mais a mão. Exemplos como o apresentado é comum a quase todas as
grandes empresas.
Cerca de trinta por cento dos fracassos nos projetos de DW são ocasionados
por má qualidade dos dados.
2.5
Trabalhos Correlatos
Atualmente, todas as grandes empresas possuem sistemas de Business Intellicence.
Dessas, não é difícil acreditar que todas empresas que estão entre as maiores do
Brasil possuem sistemas de DW. Dentre estas, é possível citar todos os grandes
bancos brasileiros, diversos órgãos da administração direta do governo central,
boa parte dos órgãos e secretarias de boa parte dos governos estaduais, grandes
redes varejistas e boa parte das grandes fábricas.
Em boa parte das empresas citadas, existem equipes dedicadas para a construção de sistemas dessa natureza. A importância desses sistemas é indiscutível,
pois há empresas que investem a partir de trezentos mil reais de mão de obra para
a construção de DM de pequena complexidade, e muitas empresas compram equipamentos que custam dezenas de milhões para dar suporte tecnológico a alguns
DW.
Existem, também, diversos trabalhos acadêmicos desenvolvidos no Brasil com
foco direto ou indireto em DW, entre os quais é possível citar as monografias:
• De Licenciatura em Computação do Instituto de Exatas da Universidade
de Brasília apresentada em janeiro de 2005 por Cristian Rodrigo Dedavid
com o título Uma Proposta de Data Warehouse como Ferramenta de Apoio
Gerencial, conforme [11];
54
• De Especialização em Banco de Dados, pelo Instituto de Informática da
Universidade Federal de Goiás apresentada em 2002 por Hedenir Monteiro
Pinheiro, com o título Tópicos de Pesquisa em Data Warehouse, conforme
[29];
• De Especialização em Web e Sistemas de Informação do Instituto de Informática da Universidade Federal do Rio Grande do Sul apresentada em
novembro de 2003 por Luiz Henrique Lorentz com o título Coleta de Requisitos - Uma abordagem visando Data Warehouse, conforme [27];
• De Bacharelado em Ciência da Computação pelo Instituto de Informática
da Universidade Federal do Rio Grande do Sul apresentada em março de
2003 por Luiz Cláudio Chaves Ziulkoski com o título Coleta de Requisitos e
Modelagem de Dados para Data Warehouse: um Estudo de Caso utilizando
Técnicas de Aquisição de Conhecimento, conforme [35];
• De Especialização em Informática Pública da Prodabel e da Pontifícia Universidade Católica de Minas Gerais apresentada em 2000 por Ana Cláudia
Campolina de Azeredo com o título Data Warehousing - Contribuindo para
o Processo de Recuperação de Informações Estratégicas na Administração
Pública, conforme [10];
• De Mestrado pela Universidade Federal de São Carlos apresentada em abril
de 2004 por Marcela Xavier Ribeiro com o título Mineração de Dados em
Múltiplas Tabelas Fato de um Data Warehouse, conforme [32].
No sítio do Dataware da Universidade Federal do Rio de Janeiro (http://
dataware.nce.ufrj.br/) há 24 trabalhos acadêmicos que retornam da pesquisa
com as palavras Data Warehouse, sendo 6 teses de mestrado, conforme abaixo:
• AQUAWARE: Um Ambiente de Suporte à Qualidade de Dados no Data
Warehouse por Glenda Carla Moura Amaral concluída em dezembro de
2003, conforme [2]
• Datamart de Navegação Baseado em Ambientes XML por Sérgio Manuel
Serra da Cruz, conforme [5]
• Regras de Negócio para Análise em Ambientes OLAP por Pablo Lopes
Alenquer concluída em julho de 2002, conforme [1]
• Um Modelo para Suporte à Integração de Análises Multidimensionais e
Espaciais por Ana Cristina Florentino Ferreira concluída em abril de 2002,
conforme [12]
• A Tecnologia Relacional-Objeto em um Ambiente de Data Warehouse por
Lawrence Zordam Klein concluída em março de 1999, conforme [26]
• Modelagem Incremental no Ambiente de Data Warehouse por Vânia Jesus
de Araujo Soares concluída em dezembro de 1998, conforme [6]
55
Há também alguns papers disponíveis na biblioteca digital da SBC, sobre ou
que se utilizaram de DW:
• Medição de Tamanho para Sistemas de Data Mart por Angélica Toffano S.
Calazans, conforme [3];
• Proposta de Aplicação da Ferramenta OLAP / Data Mart para Apoiar a
Captação de Doadores de Sangue em um Hemonúcleo por Katia Milena
Gonçalves Meira, conforme [28];
56
Capítulo 3
O Problema
Conforme descrito em [7], [8] e [9]:
A criação do Sistema Nacional de Avaliação da Educação Superior (Sinaes) pelo Ministério da Educação instituiu de forma integrada a avaliação das instituições, dos cursos e do desempenho dos
estudantes. O Sinaes estabeleceu igualmente que a avaliação das instituições considerará dez dimensões1 definidas em lei e que terá dois momentos: a auto-avaliação a ser coordenada por Comissões Próprias de
Avaliação (CPAs) e a avaliação externa a ser realizada por comissões
de docentes atuantes na educação superior devidamente cadastrados
e capacitados.
Para atendimento a uma2 das dimensões da forma mais urgente possível, diversas demandas por informações tornaram-se indispensáveis.
Este é um cenário muito propício para o desenvolvimento de um pequeno DW
ou um DM. A partir de então, foram realizadas algumas reuniões para definição
do escopo do projeto, para atendimento às demandas do Sinaes. Entre as informações necessárias, estão as tabelas (chamadas no Sinaes de Quadros), além da
do cruzamento destas tabelas com as informações descritas na página 61:
CURSO
AVALIAÇÃO
DATA PP CD IE
Tabela 3.1: Quadro 1 - Resultados das avaliações dos cursos de graduação realizadas elo MEC nos últimos três anos.
Legenda Quadro 1:
• Data é a data da avaliação no formato mm/aa;
1
2
Não confunda com as dimensões de estruturas multidimensionais citadas na página 19.
As demais dimensões não foram analisadas.
57
• PP é o conceito para o projeto pedagógico;
• CD é o conceito obtido pelo corpo docente;
• IE é o conceito obtido para a infra-estrutura.
VAGAS
CURSO/HABILITAÇÃO
RA
CHT
TP
M
T
N
ALUNOS
MATRICULADOS
M T N
Tabela 3.2: Quadro 2 - Relação dos cursos de graduação oferecidos no ano da
avaliação in loco.
Legenda Quadro 2:
• RA é o regime acadêmico do curso: seriado anual (SA); seriado semestral(SS); sistema créditos (SC) ou sistema modular (SM);
• CHT é a carga horária total do curso;
• TP é o tempo previsto de integralização curricular do curso, em anos;
• M é o número de vagas ferecidas e de alunos matriculados no turno da
manhã;
• T é o número de vagas ferecidas e de alunos matriculados no turno da tarde;
• N é o número de vagas ferecidas e de alunos matriculados no turno da noite.
CURSO/HABILITAÇÃO
AUTORIZAÇÃO
A No D C
RECONHECIMENTO
A No D C
Tabela 3.3: Quadro 3 - Situação legal dos cursos de graduação.
Legenda Quadro 3:
• A é o ato de autorização ou reconhecimento: Decreto (D); Portaria (P);
Instrumento Normativo Interno (I);
• No é o número do ato de autorização ou reconhecimento;
• D é a data de publicação do ato no DOU no formato mm/aa, quando for o
caso;
58
VAGAS
NOME DO CURSO
RA
CHT
TP
M
T
N
ALUNOS
MATRICULADOS
M T N
Tabela 3.4: Quadro 6 - Relação dos cursos superiores de tecnologia oferecidos
no ano da avaliação in loco (quando for o caso).
• C é o conceito geral obtido, quando for o caso (no caso de três conceitos,
subdividir a coluna para inserção dos dados).
Legenda Quadro 6:
• RA é o regime acadêmico do curso: seriado anual (SA); seriado semestral(SS); sistema créditos (SC) ou sistema modular (SM);
• CHT é a carga horária total do curso;
• TP é o tempo previsto de integralização curricular do curso, em anos;
• M é o número de vagas ferecidas e de alunos matriculados no turno da
manhã;
• T é o número de vagas ferecidas e de alunos matriculados no turno da tarde;
• N é o número de vagas ferecidas e de alunos matriculados no turno da noite.
NOME DO CURSO
NAT
AUTORIZAÇÃO
A No D C
RECONHECIMENTO
A No D C
Tabela 3.5: Quadro 7 - Situação legal dos cursos superiores de tecnologia
(quando for o caso).
Legenda Quadro 7:
• NAT é a natureza da atividade: curso/projeto/programa/outra;
• A é o ato de autorização ou reconhecimento: Decreto (D); Portaria (P);
Instrumento Normativo Interno (I);
• No é o número do ato de autorização ou reconhecimento;
• D é a data de publicação do ato no DOU no formato mm/aa, quando for o
caso;
59
CURSO
TC
EC
ESTÁGIOS
C
EX
Ano:
Ano:
Ano:
Total:
Tabela 3.6: Quadro 10 - Estágios curriculares, extra-curriculares e Trabalho de
Conclusão de Curso (TCC) nos três últimos anos.
• C é o conceito geral obtido, quando for o caso (no caso de três conceitos,
subdividir a coluna para inserção dos dados).
Legenda Quadro 10:
• TC indica a obrigatoriedade (S) ou não (N) de trabalho de conclusão de
curso;
• EC indica a obrigatoriedade (S) ou não (N) de estágio curricular;
• C é o número de alunos que realizaram estágio curricular;
• EX é o número de alunos que realizaram estágio extra-curricular;
TITULAÇÃO
AG
%
APG
ATIVIDADE DESENVOLVIDA
% AA % AE % AP % CA
AG
%
APG
%
Doutor
Mestre
Especialista
Graduado
TOTAL
DEDICAÇÃO
%
AD
%
TOTAL
No %
ATIVIDADE DESENVOLVIDA
AA % AE % AP % CA
%
AD
%
TOTAL
No %
Integral
Parcial
Horista
TOTAL
Tabela 3.7: Quadro 16 - Envolvimento dos docentes com a instituição.
Legenda Quadro 16:
60
• AG é o total de horas semanais em aulas de graduação;
• APG é o total de horas semanais em aulas de pós-graduação;
• AA é o total de horas semanais em atendimento aos alunos, inclusive as
horas de orientação à monitoria;
• AE é o total de horas semanais no desenvolvimento de projetos de extensão, assessorias a escritórios modelo e empresas juniores, organizações de
oficinas, seminários, congressos e outras que venham a contribuir para a
melhoria da qualidade institucional;
• AP é o total de horas semanais em atividades de pesquisa e orientação de
programas de iniciação científica;
• CA é o total de horas semanais destinadas à participação em programas
de capacitação e educação continuada e para a elaboração de monografias,
dissertações ou teses;
• AD é o total de horas semanais dedicadas às atividades administrativas,
participação em conselhos e outras não enquadradas nos itens anteriores.
Observações referentes ao Quadro 16: os percentuais, em valores inteiros,
devem ser calculados no sentido horizontal do quadro. Os da coluna TOTAL
devem ser calculados no sentido vertical.
TITULAÇÃO
No
DURAÇÃO DOS VÍNCULOS
% No % No % No %
TOTAL
No %
Doutor
Mestre
Especialista
Graduado
TOTAL
Tabela 3.8: Quadro 17 - Permanência do Corpo Docente na Instituição.
Observações referentes ao Quadro 17:
1) o número de anos deve ser arredondado para o inteiro mais próximo, ou
seja, menos de 6 meses para o inteiro anterior e a partir de 6 meses para o inteiro
superior;
2) os percentuais, em valores inteiros, devem ser calculados no sentido horizontal do quadro. Os da coluna TOTAL devem ser calculados no sentido vertical.
Avaliações das disciplinas pelos discentes:
Outra informação considerada importante pela força tarefa da Universidade de
Brasília, não identificada pelo MEC, foi a necessidade de cruzamento de boa parte
das informações supracitadas com as avaliações das disciplinas pelos discentes.
Estas avaliações jamais tiveram tantos cruzamentos como os possíveis a partir do
DW que pudesse conter estas informações dos quadros.
61
Capítulo 4
Metodologia Adotada
Foi planejada a aplicação de uma metodologia que atenda aos requisitos para o
desenvolvimento de um DW. Este estudo baseou-se em outro já realizado, conforme [11], no qual foram estudadas três metodologias distintas de levantamento
de informações gerenciais com o intuito de que uma fosse selecionada e aplicada.
As metodologias estudadas na pesquisa anterior são de três empresas:
• IBM;
• UNISYS;
• Decision Warehouse.
Destas três estudadas, foi selecionada a metodologia da empresa Decision
Warehouse, onde descrevemos a seguir os motivos para a sua escolha:
• Metodologia enxuta e de fácil aplicação e entendimentos;
• Metodologia com dinâmica que facilita o entendimento das necessidades gerenciais do cliente e ajuda na montagem dos modelos gerenciais pertinentes.
Entretanto, dado o prazo para conclusão do estudo de caso, o planejamento
reduziu a metodologia a quatro reuniões para elaboração de uma estrela (descrita na subseção 2.4.1). Serão expostas características da metodologia adaptada,
quanto ao levantamento de informações gerenciais necessárias para a elaboração
da estrela.
Foi feita uma adaptação da metodologia Dynamic Warehouse Design (DWD)
para a construção do estudo de caso. Esta é uma metodologia utilizada para conduzir reuniões de trabalho, a onde os participantes, orientados por um profissional
com prática nesta metodologia, extraem conhecimentos sobre o negócio, evitando
que sistemas sejam desenvolvidos sem a utilização de um método de levantamento
eficaz. Desta forma, as organizações se encontram em condições de desenvolver
sistemas padronizados, facilitando o seu entendimento, sua implementação e a
sua manutenção.
O DWD é uma metodologia baseada principalmente na condução de reuniões
de trabalho, utilizando dinâmica de grupo, em que cada reunião tem seu objetivo
62
pré-estabelecido. Com a finalidade de elaborar e/ou implementar o DM das áreas
específicas de uma organização, envolvendo os usuários e profissionais de sistemas
e métodos. Em alguns casos, as finalidades de duas reuniões foram fundidas em
uma só.
Nesta metodologia são levantadas as questões gerenciais e as informações
que respondem de onde se originam os objetos de negócio. Além dessas questões/respostas, também são levantadas a ciclicidade e o tempo de permanência
dos dados nas bases de dados gerenciais.
O DWD Gerencial é realizado em até sete sessões, enquanto a adaptação será
em apenas quatro. Estas sessões de trabalho podem ser constituídas de mais de
uma reunião, de no máximo quatro horas de duração cada, e com um intervalo
de 15 minutos após a primeira metade da mesma. Estima-se que cada reunião
não dure mais que três horas.
Em cada dia é realizada uma sessão de trabalho (meio expediente). O intervalo entre as sessões possibilita a reflexão dos participantes com relação aos
aspectos tratados durante a realização das sessões anteriores. Nos intervalos, os
participantes continuam gerando os produtos definidos pelo facilitador. Além
disso, efetuam correções, ordenam e classificam os produtos já obtidos, com vista
ao bom entendimento do contexto da área objeto do DWD e da sua adaptação.
Os produtos gerados durante a realização de uma sessão, ou nos intervalos, são
editados, copiados e entregues a todos os participantes, antes mesmo do início da
sessão subseqüente. Nos Sete dias após o final do DWD GER, ou nos quatro dias
da sua adaptação, é produzido o RELATÓRIO FINAL DO DWD GER, contendo
todos os produtos gerados nas sessões, organizados e editados.
Passaremos a explicar sucintamente as seções constantes na adaptação da
metodologia DWD:
1a Sessão - Missão Funcional da Área Objeto de Estudo e Produtos
e Serviços da Área Objeto de Estudo
O questionamento sobre a missão da área objeto de estudo da adaptação do
DWD força o grupo a analisar o seu trabalho de uma forma global, fornecendo
assim, aos implementadores, uma perspectiva das atividades estratégicas da área.
Investiga o conjunto de saídas, do ponto de vista informacional, que são geradas
na área específica para se alcançar à missão.
Finalidade: 1. Relacionar o(s) objetivo(s) que norteiam as atividades desenvolvidas pela(s) área(s) objeto do estudo dentro da Organização. 2. De
acordo com a Missão Funcional levantada, identificar os produtos e serviços
gerados pela organização.
Método: Conduzir os participantes a refletirem sobre a importância de sua área
para a organização, detectando as inter-relações entre as demais áreas e
a própria. A partir das inter-relações detectadas, levantam-se todos os
insumos gerados, a fim de que, clientes internos e externos da área sejam
atendidos.
Exemplo:
• Missão: Dar embasamento técnico jurídico dos atos administrativos e/ou
processuais da organização (Departamento Jurídico);
63
• Missão: Registrar dados de pessoal tendo como finalidade a execução de
pagamento e outros.
• Serviço: Análise de desempenho de campanhas publicitárias;
• Produto: Relatório de desperdício de material.
2a Sessão - Questões Gerenciais da Área Objeto de Estudo
Para que os analistas de negócio tomem suas decisões, naturalmente surgem
questões de natureza gerencial que, quando satisfeitas, os auxiliam nesta etapa.
Finalidade: As questões gerenciais são aquelas que necessitam ser respondidas
para que se produzam os produtos e serviços.
Método: Induzir os participantes a explicitarem a necessidade de informação, a
fim de que possam produzir os insumos levantados na sessão anterior.
Exemplo:
• Quantos itens são utilizados, por filial, por setor, por mês/ano?
• Qual é o maior lucro com um determinado produto?
• Qual é a receita mensal de vendas por produto, por região atendida?
• Quanto foi investido em propaganda e marketing neste ano?
Ainda nesta etapa, é de extrema importância à detecção para cada questão, do
ponto de vista da informação central (medidas ou valores) da forma ser analisada.
Após esta etapa parte para o levantamento a nível de granularidade de cada
ponto de vista. A seguir exemplos de questões que podem ser colocadas para o
levantamento deste aspecto:
Granularidade
• Você consulta os dados diariamente? (dimensão tempo)
• Você precisa distinguir, terças-feiras de sábados?
• Você precisa consultar baixa no estoque de itens em promoção especial
diariamente? (dimensão tempo)
• Você deseja rastrear produtos na nível de loja individual? E a nível de
cliente? (dimensão loja ou cliente)
• Você analisa o negócio com base numa perspectiva mensal?
Outro ponto importante a ser considerado, são as descrições especiais de algumas dimensões que poderão ser incluídas no DW. Estas descrições nada mais são
do que critérios de análise e que de alguma forma influenciam no negócio da organização. A seguir exemplos de questionamentos para identificação de descrições
especiais:
Critérios Especiais
64
• Você mantém uma descrição especial de perfil de loja, como planta da loja
ou data da última reforma ou tipos de departamentos da loja? Como se
podem obter essas descrições e adicioná-las à tabela loja? (dimensão loja)
• Faz sentido adicionar dados demográficos a cada uma das lojas ou regiões
de vendas? Alguém no departamento de marketing já possui esses dados?(dimensão cliente ou dimensão equipe de vendas)
3a Sessão - Objetos Gerenciais da Área Objeto de Estudo e Detalhamento dos Componentes dos Objetos Gerenciais
O objeto de negócio é o conjunto de informações que organizadas são capazes
de responder a uma ou mais questões gerenciais. Inclui-se nesta etapa as leis de
formação dos objetos.
Finalidade: Responder às questões gerenciais levantadas na etapa anterior. Para
isso são levantados diversos dados que são agrupados àquele que é denominado objeto gerencial ou objeto de negócio. Nesta análise podemos encontrar um objeto gerencial que responde a mais de uma questão, e também,
uma questão sendo respondida por mais de um objeto gerencial.
Método: Determinação junto aos usuários da essência da questão, assim como
os elementos que compõem cada um de seus pontos de vista.
Exemplo:
• Questões: Qual é a receita mensal de vendas por produto e por região?
• Objeto Gerencial: VENDAS;
• Componentes: Mês/Ano, Receita, Produto, Região.
• Exemplo de regras de formação com Objeto VENDAS na tabela 4.1.
Componente
MÊS/ANO
PRODUTO
REGIÃO
RECEITA
Atributo
MÊS/ANO
PRODUTO
REGIÃO
PREÇO
QUANTIDADE
Regra de Formação
–
–
–
PREÇO *
QUANTIDADE
Tabela 4.1: Tabela com Exemplo de Componentes dos Objetos Gerenciais.
4o Sessão - Quadro de Origem dos Atributos Gerenciais da Área
Objeto de Estudo e Definição do Mapa de Ciclicidade dos Objetos
Gerenciais
A determinação da localização dos atributos nas bases legadas é de fundamental importância para a etapa de extração, filtragem e carga dos dados, já na
implementação física do sistema.
Uma característica fundamental do DW é o armazenamento do histórico de
informações, contudo é necessário que se defina para cada objeto qual a amplitude
da série histórica a ser armazenada no banco.
65
Finalidades: Definir a localização exata de cada atributo. Nesta etapa, é de
fundamental importância à participação efetiva dos analistas de sistemas
responsáveis pelos sistemas legados, pois a maioria dos usuários desconhece
este tipo de informação. Definir a periodicidade de carga e o tempo de
permanência dos dados na base gerencial.
Método: Verificar atributo por atributo no sistema do qual faz parte e, assim
como, na medida do possível, a tabela e os campos correspondentes. Levantar para cada objeto:
• Quanto à periodicidade de carga: se a mesma deve corresponder ao
grão relativo à dimensão tempo.
• Quanto à amplitude da série histórica: aspectos relativos a necessidades legais, a necessidades estatísticas, assim como, às necessidades
particulares daquele objeto específico.
Exemplo Origem: Objeto Estoque na tabela 4.2
Atributo
MÊS/ANO
PRODUTO
REGIÃO
Quantidade
Origem
Sistema de Controle de Vendas
Tabela de Vendas - Atributo MÊS/ANO - SQL SERVER
Tabela de Vendas - Atributo PRODUTO - SQL SERVER
Tabela de Vendas - Atributo REGIÃO - SQL SERVER
Tabela de Vendas - Atributo QUANTIDADE - SQL SERVER
Tabela 4.2: Tabela com Exemplo da Origem dos Atributos Gerenciais.
Exemplo Ciclicidade: Objeto Estoque na tabela 4.3
Atributo
Periodicidade
Tempo de Permanência
Período
Mensal
61 meses
Tabela 4.3: Tabela com Exemplo de Ciclicidade dos Dados.
66
Capítulo 5
Estudo de caso
O Ministério da Educação (MEC), no exercício das suas funções regulatórias através do Sistema Nacional de Avaliação da Educação Superior (Sinaes), solicitou
às instituições de ensino superior diversas informações sobre os cursos superiores,
os cursos de pós-graduação, extensão universitária, entre outras. Desta forma, a
Secretaria de Planejamento solicitou a uma equipe multidisciplinar que identificasse as informações existentes, e as distribuísse entre os membros do time para
atendimento ao MEC.
O Sinaes avalia todos os aspectos que giram em torno de três eixos1 : o
ensino, a pesquisa, a extensão, a responsabilidade social, o desempenho dos alunos, a gestão da instituição, o corpo docente, as instalações
e vários outros aspectos.
Ele possui uma série de instrumentos complementares: auto-avaliação,
avaliação externa, Enade, Avaliação dos cursos de graduação e instrumentos de informação (censo e cadastro). Os resultados das avaliações
possibilitam traçar um panorama da qualidade dos cursos e instituições de educação superior no País. Os processos avaliativos são coordenados e supervisionados pela Comissão Nacional de Avaliação da
Educação Superior (Conaes). A operacionalização é de responsabilidade do Inep.
As informações obtidas com o Sinaes são utilizadas pelas IES (Instituições de Ensino Superior), para orientação da sua eficácia institucional
e efetividade acadêmica e social; pelos órgãos governamentais para orientar políticas públicas e pelos estudantes, pais de alunos, instituições
acadêmicas e público em geral, para orientar suas decisões quanto à
realidade dos cursos e das instituições.
O escopo do estudo de caso foi delimitado junto da Secretaria de Planejamento
(SPL), no qual foram identificadas as informações que fariam parte deste projeto.
Esta demanda foi previamente estudada pelo MEC, de modo a dispensar algumas
das reuniões planejadas, já descritas no capítulo corrente.
1
a avaliação das instituições, dos cursos e do desempenho dos estudantes
67
Este projeto tem como cerne da sua proposta a elaboração de um DW piloto
para o atendimento às demandas indicadas no capítulo 3.
É importante citar que o Sinaes requereu às instituições de educação superior
outras informações que foram encomendadas para a CPA, portanto não foram
avaliadas para este projeto, nem descritas nos capítulos anteriores, logo este projeto piloto pode ser estendido para aplicações futuras, mais amplas e abrangentes,
que permitam melhor gerenciamento das informações e dos recursos necessários
para as instituições de ensino superior, em especial a Universidade de Brasília.
Este projeto traz diversas informações disponíveis em diversas visões (universos da ferramenta OLAP utilizada no estudo de caso), que refletem as estrelas,
conforme seção 2.4.
5.1
Questões Gerenciais
Foram identificadas as questões gerenciais relevantes para o atendimento às demandas do MEC, descritas no capítulo 3, e destas, foram selecionadas as questões
a seguir para elaboração do estudo de caso:
• Qual a relação entre alunos matriculados e as vagas disponíveis em cada
habilitação de cada curso da Universidade de Brasília? (Quadro 2 definido
na tab 3.2)
• Quais os conceitos obtidos pelos cursos da Universidade de Brasília, nas avaliações externas? Qual a situação de cada curso quanto ao reconhecimento
pelo MEC? (Quadro 3 definido na tab 3.3)
• Qual a avaliação que os discentes fazem das disciplinas?
A principal fonte é o sistema SIGRA, que contém as informações de gestão
acadêmica da Universidade de Brasília. Outra fonte extremamente útil para o
projeto fora informações passadas em planilhas Excel, acerca das avaliações dos
discentes.
Para este projeto, não foram utilizadas fontes primárias (cadastro) de informações, tampouco secundárias (extrações diretas ou com transformações nos
sistemas fonte). Para este projeto, foram utilizadas como fontes, arquivos que
continham dados secundários.
Na seqüência do capítulo corrente, será exposto mais acerca das questões e
como resolve-las.
5.2
Granularidade Adotada
Para atendimento a essas questões, para cada fato, foram identificados os grãos
a seguir:
Para o assunto relacionado no Quadro 2: Foi identificado para o assunto
relacionado às matrículas e às vagas um grão composto de 1. Curso/Habilitação,
2. Turno e 3. Tempo (semestre).
68
Para o assunto relacionado no Quadro 3: Para o assunto relacionado aos
conceitos obtidos, foi identificado um grão contendo uma agregalçao do
curso/habilitação, chamada no modelo de 1. Curso apenas, bem como o 2.
Tempo (o último semestre do ano).
Para o assunto relacionado à avaliação dos discentes: Para esta última estrela, a granularidade é definida pelas dimensões 1. Disciplina, Tempo (semestre), 2. Questão, 3. Característica da turma, 4. Questão e 5. Grau
avaliado.
É possível identificar na seção 5.4, na estrela representada na figura 5.1 que
o dimensionamento está circunscrito em quatro dimensões, porém apenas três
dimensões definem o grão. Isto ocorre porque a dimensão regime acadêmico
(RA) não faz parte do grão. A rigor esta dimensão poderia ser desnormalizada
e, conseqüentemente ser inserida na dimensão Curso/Habilitação, porém estas
informações não tiveram a mesma fonte de dados. Para fins de administração foi
considerada mais conveniente a não-inclusão do RA na dimensão contendo dados
do SIGRA. Neste dimensionamento estão contidos todos os objetos gerenciais que
serão apresentados na seção a seguir.
Para a estrela com informações das avaliações dos discentes, o dimensionamento dos arquivos de entrada poderia definir um grão menor (mais detalhado),
com informações de cada avaliação, de cada turma, de cada professor. Uma decisão gerencial tomada entre a orientadora desta monografia e o CESPE impediu
que as informações contivessem tais detalhes.
5.3
Objetos Gerenciais
Estrela Matrículas e Vagas
Para atendimento às questões gerenciais foram identificados alguns objetos
gerenciais que farão parte das estrelas deste estudo de caso. Para a estrela que
contém a relação de matrículas em relação às vagas, foram identificados os objetos:
• Quantidade de Vagas;
• Quantidade de Matrículas;
• Semestre (Dimensão Tempo);
• Curso/Habilitação;
• Turno;
• Carga Horária Total;
• Tempo previsto de integralização curricular;
• Regime Acadêmico.
69
Devido ao regime acadêmico dos cursos da Universidade de Brasília, a quantidade de vagas associada ao Curso/Habilitação foi considerada como sendo a
quantidade disponível para ingresso no início do semestre; foi considerada a quantidade de matrículas como sendo a quantidade de alunos matriculados no curso
(estoque).
Uma limitação para esta estrela quanto à análise temporal e evolução dos dois
objetos gerenciais mensuráveis, foram os dados extraídos apenas do ano de 2004.
Estrela Conceitos
Para a estrela que deve conter as informações dos conceitos obtidos nas avaliações externas à Universidade de Brasília, foram necessários alguns objetos, que
por definição das fontes de dados, foram incluídos, na sua maior parte, na dimensão curso.
Devido a diferenças encontradas no grão da dimensão utilizada na estrela anterior, que é curso/habilitação/turno, enquanto esta é apenas o curso, foi necessária
a criação de uma dimensão agregada, que contém as informações sumarizadas.
Deste modo, houve compartilhamento da dimensão tempo, apenas. Para trabalhos futuros, existe a possibilidade de integração das dimensões conforme indicado
na subseção 2.3.
Os objetos da estrela Conceitos são:
• Conceito;
• Ano da avaliação externa (Dimensão Tempo);
• Ato de autorização do curso (tipo, número e data);
• Ato do reconhecimento do curso (tipo, número e data).
Estrela Conceitos
Para o cruzamento das informações de avaliações dos discentes, foram identificados os objetos a seguir:
1. Semestre (Dimensão Tempo);
2. Questão;
3. Característica da turma (quantidade de alunos, quantidade de professores
e regime);
4. Disciplina (com informações do departamento para o cruzamento com os
cursos);
5. Grau (Nota atribuída pelo aluno para a questão);
6. Quantidade de Avaliações.
70
O objeto Quantidade de Avaliações não existia nos arquivos originais, entretanto foram criados a partir de uma série de cálculos de sumarização submetidos
ao SGBD, de modo a trazer esta informação definida conforme o dimensionamento
limitado pelos demais objetos gerenciais. Tal sumarização requereu um poder razoável de processamento em batch, e reduziu aproximadamente 4,1 milhões de
registros em apenas mais de 700 mil.
5.4
Estrelas Modeladas
Para atendimento aos objetos gerenciais definidos a partir das questões gerenciais
foi necessária a criação de três estrelas, que serão mostradas nas figura 5.1, 5.2
e 5.3.
Figura 5.1: Estrela com a relação entre vagas e matrículas
Figura 5.2: Estrela contendo os conceitos de cada curso nas avaliações externas
71
Figura 5.3: Estrela contendo informações das avaliações feitas pelos discentes
sobre a disciplina
5.5
Camada de Visualização dos Dados
Para que o usuário, que comumente é um gerente ou gestor de uma grande ou
média empresa, possa ter acesso ao DW, é necessário o desenvolvimento de uma
interface simplificada, que não exija mais que alguns cliques para a confecção de
relatórios. Pensando nesta demanda, em décadas passadas, houve o desenvolvimento de uma linguagem amigável para a extração de informações.
A linguagem estruturada de consultas (tradução livre de SQL) tinha essa
missão. Com o avanço da tecnologia, esta linguagem passou a ser complexa demais
para que a alta direção da empresa pudesse acessar. O avanço da tecnologia
descrito na seção 2.1, que culminou na tecnologia de DW, trouxe consigo algumas
ferramentas OLAP que permitem ao usuário o aceso às informações de modo ainda
mais simples que o SQL.
A camada semântica desenvolvida para este estudo de caso será apresentada
nas figuras 5.4 e 5.5. Na figura 5.6 está representado o módulo Designer, onde o
universo2 é modelado, e é onde é possível ver as tabelas e relacionamentos entre as
tabelas. Neste módulo são criados os objetos que serão vistos pelos usuários. Nas
figuras 5.7 e 5.8, estão sendo apresentados os universos de Conceitos das avaliações
externas e das Avaliações das disciplinas pelos discentes, respectivamente.
5.6
Fontes de Dados
Nesta seção, serão apresentados os arquivos utilizados para dar carga nas tabelas
de fatos e tabelas de dimensão. Um dos principais problemas deste estudo de caso
foi a obtenção dos dados. Os dados somente puderam ser trabalhados faltando
duas semanas para a defesa desta monografia.
2
Universo é o nome dado à camada que simplifica a visualização do usuário.
72
Figura 5.4: Ferramenta de visualização dos dados, antes de pesquisar o banco de
dados
O primeiro arquivo utilizado para dar carga, foi o arquivo de cursos e habilitações (arquivo em formato texto ASCII). Neste arquivo, cada registro continha
as informações do curso e da habilitação, conforme colunas descritas a seguir:
• SIGLA_DEPARTAMENTO;
• COD_DEPARTAMENTO;
• TIPO_CURSO;
• NOME_DO_CURSO_TURNO;
• DEPARTAMENTO_HABILITACAO;
• COD_OPCAO;
• HISTORICO_HABILITACAO;
• PERIODO_INICIO;
• PERIODO_FIM;
• RECONHECIDO;
• DURACAO;
• AREA_ACESSO;
• LIMITE_MINIMO_CREDITO_POR_SEMESTRE;
73
Figura 5.5: Ferramenta de visualização dos dados, após pesquisa ao banco de
dados
• LIMITE_MAXIMO_CREDITO_POR_SEMESTRE;
• TOTAL_CREDITO;
• CREDITO_MINIMO_DC;
• CREDITO_MINIMO_AC;
• CREDITO_MINIMO_ML;
• PERMANENCIA_MINIMA;
• PERMANENCIA_MAXIMA.
Devido aos problemas citados na subseção 5.6.1 e do supracitado, somente
foram carregadas na tabela de dimensão as informações dos cursos e das habilitações atuais.
Outro arquivo utilizado para o projeto, foi o arquivo em formato Excel, que
continha informações da quantidade de vagas e matrículas por curso/habilitação
e turno, no ano de 2004. Este arquivo já continha informações com algum nível
de tratamento visual, o que prejudica uma carga direta. Para dar carga no banco
de dados, foi necessária a retirada de textos e sumarizações que, posteriormente,
serão incluídos através da ferramenta de visualização dos dados.
Outra ocorrência registrada quanto ao arquivo, diz respeito ao formato da sua
tabela, que é uma tabela de referências cruzadas. Este tipo de tabela pode ser
criado deste modo, da mesma forma que os textos e fórmulas. Foi necessário,
portanto, que as informações dos turnos (que estavam na horizontal), fossem
colocadas na vertical, com uma coluna a mais qualificando a qual turno os dados
74
Figura 5.6: Universo de Vagas e Matrículas
das vagas e matrículas pertencem. Esta coluna foi posteriormente transformada
em uma nova dimensão, bem como a coluna Regime Acadêmico, conforme pode
ser visto no modelo de dados (seção 5.4).
Devido ao banco de dados utilizado, foi possível importar os dados diretamente
do arquivo Excel.
As colunas do arquivo serão descritas a seguir:
• Curso/Habilitação;
• Regime Acadêmico;
• Carga Horária Total;
• Tempo Previsto para a Integralização (tempo mínimo);
• Tempo Previsto para a Integralização (tempo máximo);
• Quantidade de alunos matriculados no período diurno;
• Quantidade de alunos matriculados no período noturno;
• Número de Vagas no período diurno;
• Número de Vagas no período noturno.
75
Figura 5.7: Universo de Conceitos das Avaliações Externas
As informações de Carga Horária Total (quantidade de créditos multiplicada
por 15) foram extraídas do primeiro arquivo, bem como o tempo previsto para a
integralização. Assim, essas foram utilizadas apenas nas tabelas temporárias e de
tratamento das informações, e não foram incluídas (por esta fonte) nas estrelas.
O último arquivo que utilizou como fonte secundária o SIGRA, também em
formato Excel, foi o arquivo que contém a situação legal do curso. A maior
parte das informações deste arquivo, como será demonstrado na descrição das
colunas a seguir, pode ser incluída como novas informações na tabela de dimensão
Curso/Habilitação e na dimensão agregada Curso.
As informações de conceito foram, do mesmo modo que o turno no arquivo
anterior, incluídas como colunas (horizontalmente). Para este, também foi necessária a transformação nos dados para torná-los verticais, com a inclusão da
dimensão Tempo, conforme pode ser conferido nos modelos de dados. Seguem as
colunas do arquivo de Conceitos:
• Nome do curso.
• Tipo de ato de autorização do curso;
• Número do ato de autorização do curso;
• Data do ato de autorização do curso;
• Tipo de ato de reconhecimento do curso;
• Número do ato de reconhecimento do curso;
• Data do ato de reconhecimento do curso.
Por fim, dois outros arquivos foram os arquivos de avaliação das disciplinas,
professor, auto-avaliação, e suporte à execução, respondida pelos discentes. Estes
76
Figura 5.8: Universo de Avaliação das Disciplinas pelos Discentes
arquivos (um do semestre 2004/1 e outro de 2004/2), igualmente em formato
Excel, possuem formatos muito semelhantes.
Para o tratamento destas informações, foram identificados dois complicadores:
• 43 colunas (uma para cada resposta);
• Grande volume de dados para as ferramentas utilizadas.
Nenhum destes complicadores inviabilizaram o projeto, entretanto o tratamento das informações que, em parte foi manual, gerou um risco operacional: a
falha humana.
Inicialmente foi necessária a transformação das informações horizontais em
verticais, algo que foi extremamente demorado. Após este passo, a tabela, ainda
contendo informações sigilosas, continha aproximadamente 4,1 milhões de registros. Após a exclusão das informações que identificariam os professores e suas
turmas, a tabela foi sumarizada, tornando-a viável, porém com 748.409 registros.
As colunas das duas planilhas estão descritas a seguir:
• Matrícula do professor;
• Nome do professor;
• Turma;
• Quantidade de alunos;
• Cód da disciplina
• Nome da disciplina
• Nível da disciplina (foram incluídas apenas disciplinas de Graduação - GR);
77
• Quantidade de créditos da disciplina;
• Quantidade de professores;
• Departamento da disciplina;
• Código do departamento;
• Sigla do departamento;
• Lotação da disciplina;
• Regime;
• 43 colunas contendo as respostas de cada um dos 43 itens de respostas
fechadas.
Algumas das colunas podem ser coincididas, de modo que será possível integrar
os dados do CESPE como SIGRA. O atributo Sigla do departamento dos arquivos
de informações do CESPE coincide com o atributo SIGLA_DEPARTAMENTO
do arquivo de informações dos cursos e habilitações. Desta forma, na ferramenta
OLAP será possível cruzar estas informações.
5.6.1
Qualiade dos dados
Um dos problemas identificados no projeto, foi a qualidade dos dados. É muito
comum que os projetos de DW sejam prejudicados pela baixa qualidade dos dados.
Neste projeto, no arquivo texto extraído do SIGRA, foram identificadas habilitações idênticas com período de início e término simultâneas. Possivelmente
essas informações são condizentes com algumas regras negociais que não foram
passadas para o tratamento no ETC, porém para resolver os problemas, foram
consideradas apenas as habilitações com o maior período de início e menor que
ou igual a 2004/2 e com o período de término nulo ou maior que 2004/2.
Outro problema ocorreu quando da integração deste arquivo de habilitações
com os arquivos de vagas e matrículas e de conceitos. Isso ocorreu devido a
consolidações feitas nos arquivos Excel, que já possuíam fontes secundárias de
informação.
Deste modo, a integração foi feita com o batimento registro a registro, para
obter o cruzamento entre as informações de vagas e matrículas com as informações
de conceitos.
Para a estrela de informações de avaliações dos discentes, foram identificados
problemas de qualidade dos dados, nas notas atribuídas pelos alunos para cada
questão.
Para a questão que indica a quantidade de créditos já cursados (questão 5.3),
as respostas poderiam conter qualquer número entre 0 e 999 (era permitido qualquer resposta nesta faixa, mesmo não sendo coerente que um aluno faça mais que
300 ou 400 créditos). Para a questão que pergunta acerca do currículo novo ou
antigo (5.2), as respostas poderiam ser Sim, Não ou NA. Para todas as demais
questões, as respostas poderiam ser de 0 a 10, ou NA.
78
Foram identificados valores que continham espaços entre números (9 0), asteriscos ou outros caracteres, valores fora da faixa e respostas em branco (valor
nulo). Para que as informações não fossem perdidas, foram atribuídos valores curinga para estas ocorrências (Fora da Faixa, Dados Incorretos e Não Informado).
5.7
Ferramentas Utilizadas
Para a construção do estudo de caso, foram selecionadas algumas ferramentas
dentre as disponíveis.
A seleção não levou em conta quais as melhores ferramentas ou as que possuíam melhor desempenho. A seleção levou em consideração o conhecimento das
pessoas envolvidas no estudo de caso. Deste modo, não foi necessária a aprendizagem de outras ferramentas.
5.7.1
Banco de Dados
Como visto no capítulo 2, a principal ferramenta utilizada em um DW é o banco
de dados. Para este estudo foi selecionado o banco de dados Microsoft Access,
dada a maior disponibilidade e facilidade no uso.
Mesmo sabendo das limitações e mesmo sabendo que o MS Access não possui
a maior parte das características necessárias para um SGBDR, as facilidades
supracitadas tiveram maior peso na escolha.
5.7.2
ETC
Não foram utilizadas ferramentas de ETC Para a transformação, foram utilizadas
as ferramentas do Microsoft Office disponíveis, em conjunto com editores de texto
padrão do Windows (notepad e wordpad).
5.7.3
Ferramenta Case
A ferramenta Case utilizada foi o Sybase Power Designer, por tê-la disponível no
local de trabalho. Os padrões gráficos utilizados pela ferramenta Case e presentes
em boa parte das figuras estão apresentados no apêndice A.
5.7.4
Ferramenta de Visualização de Dados
A ferramenta para visualização utilizada foi o Business Objects versão 5.1, por
tê-la disponível, bem como conhecê-la bem. A empresa 5 Acts disponibilizou-a
para uso acadêmico, sem qualquer ônus para a Universidade de Brasília.
79
Capítulo 6
Conclusão e Trabalhos Futuros
Com algumas consultas submetidas ao DW, foram identificadas algumas situações, conforme podem ser vistas na figura 6.1, referente ao segundo semestre de
2004.
Figura 6.1: Consulta sobre o perfil dos discentes que preencheram o questionário
• 63% dos alunos possivelmente desconhece se o currículo do curso é novo ou
antigo;
• Foram respondidos no semestre em questão mais de 69 mil questionários,
o que estatisticamente pode explicar a Universidade de Brasília. Para ter
certeza da afirnativa seria necessário o número total de matrículas nas disciplinas.
• Em média os alunos que responderam o questionário estão finalizando 113
créditos.
80
Figura 6.2: Consulta da evolução das amostras das avaliações das disciplinas,
segregadas pelos grupos.
Na figura 6.2, é possível identificar que as lotações TEF, CEPPA e DSC obtiveram na média as melhores avaliações (4o bloco) quanto ao suporte à disciplina,
e HIS, MUS e LET ocuparam as últimas. Já os discentes que na auto-avaliação
(3o bloco) obtiveram os melhores resultados foram das lotações CEPPA, TEL e
CEN. Na outra ponta de uma classificação decrescente estão as lotações MAT,
IFD e EST, esta última lotação a única com auto-avaliação com média abaixo de
7 (6,92).
Entre todos os grupos de questões, o grupo 1 (Programa da Disciplina) é o
mais bem avaliado, seguido dos professores. O departamento CIC encontra-se
em todos os quadros próximo da média, porém é mais bem avaliado que ela no
grupo Suporte à Execução da Disciplina, e pior nos demais grupos. É possível
explicar devido a colocação acima da média do quadro suporte à disciplina devido
à infraestrutura tecnológica presente todas as salas de aula.
A lotaçõe CEPPA foi a mais bem avaliada nos quadros 1, 2 e 3, ocupando a
segunda colocação no quadro 4. Entretanto a lotação em questão aplicou apenas
no segundo semestre de 2004, entre os dois semestres avaliados neste estudo de
caso.
Quando é analisada a figura 6.3 referente ao ano de 2004, é possível identificar
cinco cursos que foram avaliados em todos os três anos incluídos no DW, sendo
que estes cursos não possuem vagas ou matrículas no período noturno.
81
Figura 6.3: Consulta as Avaliações Externas, Vagas e Matrículas.
Ainda é possível identificar o curso de Pedagogia, com 2.306 é o curso com
maior número de alunos matriculados, seguido de Letras, com 1.337. Estes cursos
possuem, também a maior quantidade de vagas que são disputadas anualmente
através de avaliações de desempenho (PAS e Vestibular), com 236 e 212 vagas,
respectivamente. Ambos cursos possuem vagas e matrículas para o dia e para a
noite.
Além da análise dos dados, o projeto apontou para uma carência de informação
existente na Universidade de Brasília. Desta forma, este trabalho deixa margem
para que diversos outros sistemas de informação gerencial sejam implementados.
Outra possibilidade é a implementação em um ambiente mais robusto do DW
ora desenvolvido, implementando neste outras funcionalidades, e melhorando as
já implementadas, entre elas, existe a possibilidade de análise das médias com os
seus desvios padrão e análise de variância.
Identifica-se, também, que o DW é uma fonte de informação centralizada e
organizada, que permite ao usuário acesso a sistemas de diversas áreas.
Devido aos processos de ETC, os dados apresentados são confiáveis e permitem
ao usuário quase leigo em informática acesso a informações que, sem o DW,
seriam inviáveis de serem obtidas em prazo semelhante. A falta de normalização
das tabelas de um DW facilita o acesso, pois o usuário não precisará relacionar
diversas tabelas para obter as informações.
Outro benefício da falta de normalização diz respeito às escolhas de caminhos
alternativos para acesso a informações compartilhadas por diversas tabelas. O
82
usuário não precisará dizer ao sistema que, ao selecionar informações de município,
os dados são referentes à naturalidade do professor ou onde a sala de aula está
localizada, pois são criados objetos distintos para funções distintas. Como não
serão necessários relacionamentos entre tabelas, o tempo de resposta da pesquisa
também será reduzido. A utilização de um DW permite portanto que as decisões
dos gestores sejam mais precisas e ágeis, por não serem embasadas apenas em
critérios subjetivos, mas também em informações.
Um passo seguinte à implantação do DW será a construção de sistemas de
apoio ao executivo ou ao gestor, que proverá informações já trabalhadas pelas
áreas a esta pessoa vinculadas.
O projeto implementado para a confecção da presente monografia é apenas
um embrião do projeto que poderá ser implantado na Universidade de Brasília,
e desde já aponta para o grande potencial existente no conhecimento, tanto para
o planejamento, quanto para o acompanhamento das execuções de projetos e
programas implantados pela UnB.
Devido à centralização das informações, qualquer usuário que tenha acesso
extrairá exatamente a mesma informação que outro. Os conceitos serão integrados
para que sempre que uma extração utilize um objeto, todos saibam qual é o objeto
e qual seu real significado e suas limitações. Após a fase de construção, qualquer
consulta ao DW será muito mais ágil que a confecção de programas de extração
dos dados. Como o tempo é essencial para que se tenham melhores resultados,
fazer no tempo correto, não depois, pode trazer um retorno mais satisfatório ao
investimento.
Diversos custos de qualquer instituição estão relacionados com o tempo (a
exemplo de salário, que é pago com ou sem resultado obtido do funcionário). Deste
modo, a redução nos custos também pode ser observada na execução dos novos
projetos e programas. Ao fazer uma pesquisa em uma base histórica consistente,
será, mais viável que análises estatísticas possam implementar modelos preditivos
ou mesmo qualquer gestor compreender de modo mais claro o porquê de muitas
situações atuais.
A flexibilidade na construção das pesquisas é por si só um dos maiores benefícios o DW, mas pode ser a alforria do gestor, sempre dependente da TI para
quaisquer informações. A redução no tempo gasto para obter os dados permite
que as equipes responsáveis tenham mais tempo para analisar os dados, e tomar
decisões mais corretas e assertivas.
Concluo, também, que, caso os materiais fossem disponibilizados pela UnB/CESPE
em um prazo maior, não apenas há duas semanas da defesa desta monografia,
uma análise das informações mais completa e construção de um sistema mais robusto seriam possíveis. Mesmo com todos os problemas, o autor desta monografia
obteve um grande aprendizado e ratificou muitas das informações dos grandes especialistas da área. O conhecimento adquirido na confecção desta monografia
será levado junto do autor para sua vida profissional e para os próximos passos
da vida acadêmica.
83
Apêndice A
Padões Utlizados nos Modelos de
Dados
Para descrever as estrelas, a ferramenta CASE Sybase Power Designer foi utilizada. Para delimitar o trabalho, serão apresentados apenas os padrões utilizados
na modelagem, bem como referentes apenas aos modelos físicos (chamados no
Power Designer de Phisical Data Model ).
Figura A.1: Padrões utilizados na Tabela.
Figura A.2: Tabelas de Fatos, Dimensões e Relacionamentos.
As cores das tabelas ou das linhas não interferem no resultado. Didaticamente
as tabelas podem ser preenchidas com cores diferentes, dependendo do seu tipo
de tabela (fato, dimensão ou fato agregada).
84
Figura A.3: Exemplo de um modelo estrela.
O relacionamento pode ser terminado em pés de galinha na tabela filho (que
no caso de um DW será sempre uma fato ou fato agregada), ou iniciado em uma
seta, indicando a dimensão, ou referenciando a tabela pai, conforme figura A.4.
Figura A.4: Exemplo de um modelo estrela com relacionamentos definidos por
setas.
Os traços perpendiculares à direção do relacionamento ou pequenas circunferências nas terminações apresentadas na figura A.3 indicam se a tabela é referenciada de modo obrigatório pelo lado oposto ou é referenciada de modo opcional,
respectivamente. Para um DW, somente existirão relacionamentos onde a dimensão será obrigatória e a fato será opcional, conforme demonstrado na figura A.2.
Na seção 5.4 os modelos são apresentados conforme implementados.
85
O nome das tabelas foi precedido de TD, TDA e TF, para identificar, respectivamente Tabela de Dimensão, Tabela de Dimensão Agregada e Tabela de Fatos.
Não foram criadas tabelas de fatos agregados. Para os atributos das tabelas, as
chaves primárias foram precedidas de PK (primary key), e as chaves estrangeiras
foram precedidas de FK (foreign key).
Não foram criados outros padrões para nomes de tabelas e de atributos.
86
Apêndice B
Dicionário de dados
A seguir segue o dicionário de dados, contendo os metadados das tabelas e colunas
das estrelas:
B.1
Tabelas
TD_CARACTERISTICA_TURMA: Esta tabela de dimensão é uma Speed
Table (tabela de acesso rápido que contém informações diversas, cujo conteúdo quase sempre é cadastrado somente quando o fato ocorre para este
conteúdo), que contém informações de quantidade de alunos e professores
de cada turma, e do regime.
TD_CURSO_HABILITACAO: Tabela de dimensão que contém informações de cada curso e suas habilitações. Esta tabela é versionada pelos
atributos PERIODO_INICIO e PERIODO_FIM, que indicam quando um
curso iniciou ou terninou. Nesta tabela, existe uma Surrogate Key que é a
chave primária da tabela.
TD_DISCIPLINA: Tabela de dimensão que contém informações das disciplinas da Universidade de Brasília.
TD_GRAU_AVALIACAO_DISCENTE: Tabela de dimensão que limita
as gradações que podem ser atribuídas nas avaliações dos discentes. Na
tabela de fatos, existe um atributo que permite qualquer entrada, mas a dimensão indica quais os valores curinga que devem ser atribuídos a cada valor
incorreto, fora da faixa ou para a falta de informação. A tabela também
atribui valores aos itens válidos.
TD_QUESTAO: Tabela de dimensão que contém informações sobre cada questão respondida na avaliação dos discentes.
TD_REGIME_ACADEMICO: Tabela de dimensão que contém a discriminação de todos os regimes acadêmicos adotados pelas instituições de ensino
superior no Brasil.
TD_SEMESTRE: Tabela de dimensão que determina o tempo, medido em
semestres, conforme padrão da Universidade de Brasília
87
TD_TURNO: Tabela de dimensão que contém a discriminação dos turnos possíveis para os cursos - manhã, tarde, noite e diúrno (manhã e tarde).
TDA_CURSO: Tabela de dimensão, agregada da tabela de cursos e habilitações. Nesta tabela existem apenas os cursos, sem distinção de turno e de
habilitação.
TF_AVALIACAO_DISCENTE: Tabela de fatos que contém o resultado da
avaliação que os discentes fazem das disciplinas cursadas. Esta tabela possui
grau de sigilo superior às demais, e possui um grão definido pelas respostas para cada pergunta para a disciplina, no semestre, conforme algumas
características da turma, sem discriminar a turma e o professor.
TF_CONCEITO: Tabela de fatos que contém os conceitos obtidos nas avaliações externas à UnB, para cada curso avaliado, em cada ano.
TF_VAGA_MATRICULA: Tabela de fatos que contém informações das vagas e das matrículas em cada curso/habilitação, em cada ano (inicialmente
somente existe o ano de 2004).
B.2
Colunas
Todas as tabelas de um banco de dados relacional devem possuir uma ou mais
colunas. Nesta seção estão cadastrados os metadados descritivos de cada uma
das colunas das tabelas.
Tabela TD_CARACTERISTICA_TURMA
PK_CARACTERISRICA_TURMA: Chave primária da tabela de características da turma. Esta é uma Surrogate Key, que é incrementada a cada
registro novo incluído.
QTD_ALUNOS: Quantidade de alunos matriculados na disciplina na turma
avaliada.
QTD_PROFS: Quantidade de professores docentes da disciplina,na turma,
avaliada.
REGIME: Regime da turma
Tabela TD_CURSO_HABILITACAO
PK_HABILITACAO_TURNO Chave primária da tabela de cursos/habilitação.
Esta é uma Surrogate Key, que é incrementada a cada registro novo incluído.
SIGLA_DEPARTAMENTO Sigla do departamento do Curso/Habilitação
COD_CURSO Código do curso
88
TIPO_CURSO Classificação do curso (para este projeto são considerados apenas os cursos de graduação - GR)
Curso Nome do curso da habilitação
NOME_CURSO Nome do curso por extenso (contendo qual habilitação e qual
o turno, conforme cadastro no arquivo de origem)
DEPARTAMENTO_HABILITACAO Departamento ao qual a habilitação
está vinculada.
PERIODO_INICIO Período de início da validade do registro da habilitação/curso
PERIODO_FIM Período de término da validade do registro da habilitação/curso
RECONHECIDO Indicador S/N que indica se o curso foi reconhecido pelo
MEC.
DURACAO Duração da habilitação (no caso da UnB, existem atualmente somente duração plena).
AREA_ACESSO Área de acesso de cada habilitação.
LIMITE_MINIMO_CREDITO_POR_SEMESTRE Número mínimo de
créditos que podem ser cursados pelo discente em cada semestre
LIMITE_MAXIMO_CREDITO_POR_SEMESTRE Número máximo de
créditos que podem ser cursados pelo discente em cada semestre
TOTAL_CREDITO Quantidade total de créditos necessários para a integralização do currículo do curso
TOTAL_HORAS Quantidade total de horas necessárias para a integralização
do currículo do curso (quantidade de créditos multiplicada por 15)
CREDITO_MINIMO_DC Quantidade mínima de créditos que um aluno
deve cursar de domínio conexo ao seu curso.
CREDITO_MINIMO_AC Quantidade mínima de créditos que um aluno
deve cursar da área de concentração do seu curso.
CREDITO_MINIMO_ML Quantidade mínima de créditos que um aluno
deve cursar como móduo livre.
PERMANENCIA_MINIMA Quantidade mínima de semestres que o aluno
pode cursar para cada curso/habilitação
PERMANENCIA_MAXIMA Quantidade máxima de semestres que o aluno
pode cursar para cada curso/habilitação
AUTORIZACAO_A Tipo de ato de autorização do curso.
89
AUTORIZACAO_N Número do ato de autorização do curso.
AUTORIZACAO_D Data do ato de autorização do curso.
RECONHECIMENTO_A Tipo de ato de reconhecimento do curso.
RECONHECIMENTO_N Número do ato de reconhecimento do curso.
RECONHECIMENTO_D Data do ato de reconhecimento do curso.
Tabela TD_DISCIPLINA
PK_DISCIPLINA Chave primária da tabela de disciplinas. Para esta chave,
foi considerado o mesmo atributo utilizado no sistema fonte, ou seja, o
código da disciplina.
DISCIPLINA Nome da disciplina
NIVEL_DISC Classificação da disciplina (para este projeto são consideradas
apenas as disciplinas de graduação - GR)
CREDITOS Quantidade de créditos da disciplina
DEPTO Departamento ao qual o curso está vinculado.
CODIGO Código da disciplina
SIGLA Sigla da lotação da disciplina
LOTACAO Lotação da disciplina (instituto ao qual pertence, por extenso)
Tabela TD_GRAU_AVALIACAO_DISCENTE
PK_GRAU_AVALIACAO_DISCENTE Chave primária da tabela de graus
avaliados pelos discentes. Esta é uma tabela densa, com todos os registros
(válidos) possíveis. Quanto aos não-válidos foram consideradas .quatro situações, descritas nos registros da tabela.
VALOR Valor atribuído pelo aluno para a questão. Este valor é numérico para
que eventuais cálculos sejam possíveis.
DESCRICAO Descrição do grau atribuído pelo discente à disciplina
Tabela TD_QUESTAO
90
PK_QUESTAO Chave primária da tabela de questões solicitadas para que
os discentes respondessem. Esta é uma tabela contendo todas as questões
das avaliações dos discentes. Possui uma regra de formação que é o item
multiplicado por 100, somado com o subitem.
ITEM Item (grande grupo) da avaliação
SUBITEM Subitem da avaliação
DESCRICAO_QUESTAO Questão respondida pelo discente por extenso (não
será cadastrada neste projeto, porém o modelo de dados já terá condições
de contemplar esta questão)
Tabela TD_REGIME_ACADEMICO
PK_REGIME_ACADEMICO: Chave primária da tabela de Regime acadêmico.
SIGLA_REGIME_ACADEMICO: Sigla do regime acadêmico adotado para
o curso/habilitação
NOME_REGIME_ACADEMICO: Nome por extenso do regime acadêmico
Tabela TD_SEMESTRE
PK_SEMESTRE: Chave primária da tabela de semestre. Possui uma regra
de formação definida pela concatenação de Ano (no formato AAAA), com
o semestre (1 ou 2)
SEMESTRE: Número do semestre no ano (com um dígito)
ANO: Ano do semestre.
Tabela TD_TURNO
Name: Comment
PK_TURNO: Chave primária da tabela de Turnos.
TURNO: Turno (por extenso) da habilitação
Tabela TDA_CURSO
91
PK_CURSO: Chave primária da tabela de cursos. Esta é uma Surrogate Key,
que é incrementada a cada registro novo incluído.
TIPO_CURSO: Classificação do curso (para este projeto são considerados
apenas os cursos de graduação - GR)
Curso: Nome do curso
AUTORIZACAO_A: Tipo de ato de autorização do curso.
AUTORIZACAO_N: Número do ato de autorização do curso.
AUTORIZACAO_D: Data do ato de autorização do curso.
RECONHECIMENTO_A: Tipo de ato de reconhecimento do curso.
RECONHECIMENTO_N: Número do ato de reconhecimento do curso.
RECONHECIMENTO_D: Data do ato de reconhecimento do curso.
Tabela TF_AVALIACAO_DISCENTE
FK_DISCIPLINA: Chave estrangeira da tabela de disciplinas
FK_CARACTERISRICA_TURMA: Chave estrangeira da tabela de característica da turma
FK_SEMESTRE: Chave estrangeira da tabela de semestre (dimensão tempo)
FK_QUESTAO: Chave estrangeira da tabela de questões respondidas avaliações dos discentes
FK_GRAU_AVALIACAO_N: Chave estrangeira da tabela dos graus (medidas) das avaliações dos discentes
GRAU_AVALIACAO_CADASTRADO: Grau da avaliação do discente,
conforme cadastrado nos arquivos fonte
QUANTIDADE_AVALIACOES: Quantidade de avaliações com as mesmas
características.
Tabela TF_CONCEITO
FK_CURSO: Chave estrangeira da tabela dos cursos
CONCEITO: Conceito obtido na avaliação externa
92
Tabela TF_VAGA_MATRICULA
FK_CURSO_HABILITACAO: Chave estrangeira da tabela dos cursos e
habilitações
FK_REGIME_ACADEMICO: Chave estrangeira da tabela de regime acadêmico
FK_TURNO: Chave estrangeira da tabela de turnos das disciplinas
VAGA: Quantidade de vagas disponíveis a cada ano para o curso
MATRICULA: Quantidade de alunos matrículados pertencente ao curso (estoque)
93
Apêndice C
Formulário de Avaliação das
Disciplinas pelos Discentes
Figura C.1: Formulário de Avaliação das Disciplinas pelos Discentes.
94
Referências
[1] Pablo Lopes Alenquer.
Regras de negócio para análise em ambientes OLAP.
Master’s thesis, Universidade Federal do Rio
de Janeiro, Rio de Janeiro, Brasil, julho 2002.
Divulgado em
http://dataware.nce.ufrj.br:8080/dataware/publicacoes/fisico/
teses/datawarehousing/ALENQUER-2002.pdf.
[2] Glenda Carla Moura Amaral. Aquaware: Um ambiente de suporte à qualidade de dados no Data Warehouse. Master’s thesis, Universidade Federal do Rio de Janeiro, Rio de Janeiro, Brasil, dezembro 2003. Divulgado em http://dataware.nce.ufrj.br:8080/dataware/publicacoes/
fisico/teses/datawarehousing/AMARAL-2003.pdf.
[3] Angélica Toffano S. Calazans.
Medição de tamanho para sistemas
de Data Mart. http://bibliotecadigital.sbc.org.br/download.php?
paper=262, 2003. Paper pesquisado na biblioteca eletrônica da SBC.
[4] Robert S. Craig. Microsoft Data Warehousing: Building Distributed Decision
Support System. WILEY, 1999.
[5] Sérgio Manuel Serra da Cruz. Datamart de navegação baseado em ambientes XML. Master’s thesis, Universidade Federal do Rio de Janeiro,
Rio de Janeiro, Brasil. Divulgado em http://dataware.nce.ufrj.br:
8080/dataware/publicacoes/Members/serra/.
[6] Vânia Jesus de Araujo Soares.
Modelagem incremental no ambiente de Data Warehouse.
Master’s thesis, Universidade Federal do
Rio de Janeiro, Rio de Janeiro, Brasil, dezembro 1998.
Divulgado em http://dataware.nce.ufrj.br:8080/dataware/publicacoes/
fisico/teses/datawarehousing/SOARES-1998.pdf.
[7] Comissão Tecnica de Avaliação. Roteiro de auto-avaliação institucional 2004.
Technical report, Instituto Nacional de Estudos e Pesquisas Educacionais
Anísio Teixeira - INEP/MEC, Esplanada dos Ministérios, Bloco L, Anexo I,
2004.
[8] Comissão Tecnica de Avaliação. Avaliação externa das instituições de educação superior 2005. Technical report, Instituto Nacional de Estudos e Pesquisas Educacionais Anísio Teixeira - INEP/MEC, Esplanada dos Ministérios,
Bloco L, Anexo I, Novembro 2005.
95
[9] Comissão Tecnica de Avaliação. Sistema nacional de avaliação da educação
superior. Divulgado pelo INEP em http://www.inep.gov.br/superior/sinaes,
acessado em 25/07/2006, Janeiro 2005.
[10] Ana Cláudia Campolina de Azeredo. Data Warehousing - contribuindo
para o processo de recuperação de informações estratégicas na administração pública. Curso de Especialização em Informática Pública da
Prodabel e da Pontifícia Universidade Católica de Minas Gerais, divulgado pelo endereço http://www.pbh.gov.br/prodabel/cde/publicacoes/
2000/azeredo2000.pdf, Janeiro 2000.
[11] Cristian Rodrigo Dedavid. Data Warehouse como ferramenta de apoio gerencial. Monografia apresentada em janeiro de 2005 na Universidade de Brasília,
Janeiro 2005.
[12] Ana Cristina Florentino Ferreira. Um modelo para suporte à integração
de análises multidimensionais e espaciais. Master’s thesis, Universidade
Federal do Rio de Janeiro, Rio de Janeiro, Brasil, abril 2002. Divulgado em http://dataware.nce.ufrj.br:8080/dataware/publicacoes/
fisico/teses/datawarehousing/FERREIRA-2002.pdf.
[13] Susan Gallas. Kimball Vs. Inmon. DM Direct Newsletter, September
1999. Divulgado pela revista DMReview em http://www.dmreview.com/
article_sub.cfm?articleId=1400.
[14] Harjinder S. Grill. The Official Client/Server Computing Guide to Data
Warehousing. Que, 1996.
[15] Joe Oates; Clay Rehm; Adrienne Tannenbaum; Tom Haughey. Should we
load null values into the Data Warehouse? DM Direct Newsletter, May
article_sub.cfm?articleID=1055285.
[16] Joe Oates; Clay Rehm; Adrienne Tannenbaum; Tom Haughey. Updating
slowly changing dimensions. DM Direct Newsletter, May 2006. Divulgado
pela revista DMReview em http://www.dmreview.com/article_sub.cfm?
articleID=5046.
[17] William Inmon. Como Construir o Data Warehouse. Campus, 1997.
[18] William Inmon. Como Usar o Data Warehouse. Ibpi Press, 1997.
[19] William Inmon. Gerenciando Data Warehouse. Campus, 1999.
[20] William Inmon. Corporate Information Factory. Campus, 2001.
[21] William Inmon. Up-to-the-second data. DM Direct Newsletter, June
article_sub.cfm?articleID=1028743.
96
[22] William Inmon. 2.0 - architecture for the next generation of data warehousing. DM Direct Newsletter, April 2006. Divulgado pela revista DMReview
em http://www.dmreview.com/article_sub.cfm?articleID=1051111.
[23] Ralph Kimball. The Data Warehouse Toolkit. Makron, 1996.
[24] Ralph Kimball. The Data Warehouse Lifecycle Toolkit: Expert Methods for
Designing, Developing and Deploying Data Warehouses. Makron, 1998.
[25] Ralph Kimball. Data Warehouse. Campus, 2000.
[26] Lawrence Zordam Klein. A tecnologia relacional-objeto em um ambiente de Data Warehouse.
Master’s thesis, Universidade Federal
do Rio de Janeiro, Rio de Janeiro, Brasil, março 1999.
Divulgado em http://dataware.nce.ufrj.br:8080/dataware/publicacoes/
fisico/teses/datawarehousing/KLEIN-1999.pdf.
[27] Luiz Henrique Lorentz. Coleta de requisitos - uma abordagem visando Data
Warehouse. Especialização em Web e Sistemas de Informação do Instituto
de Informática da Universidade Federal do Rio Grande do Sul, divulgado
pelo endereço http://www.inf.ufrgs.br/gpesquisa/bdi/publicacoes/
files/WebsisLuizLorentz.PDF, Novembro 2003.
[28] Katia Milena Gonçalves Meira. Proposta de aplicação da ferramenta OLAP
/ Data Mart para apoiar a captação de doadores de sangue em um hemonúcleo. http://bibliotecadigital.sbc.org.br/download.php?paper=290,
2003. Paper pesquisado na biblioteca eletrônica da SBC.
[29] Hedenir Monteiro Pinheiro. Tópicos de pesquisa em Data Warehouse. Especialização em Banco de Dados, pelo Instituto de Informática da Universidade
Federal de Goiás, 2002.
[30] Richard Merz Ralph Kimball. The Data Warehouse Toolkit: Building The
Web-Enabled Data Warehouse. Makron, 1998.
[31] Tom Haughey; Chuck Kelley; Joe Oates; Clay Rehm. How would you
generate a report that shows non-events in a fact table?
DM Direct
Newsletter, February 2006. Divulgado pela revista DMReview em http:
//www.dmreview.com/article_sub.cfm?articleID=1048081.
[32] Marcela Xavier Ribeiro. Mineração de dados em múltiplas tabelas fato de
um Data Warehouse. Master’s thesis, Universidade Federal de São Carlos,
São Carlos, Brasil, 2004. Divulgado resumo em http://www.dc.ufscar.br/
~ppg/dissertacoes/diss235.htm.
R IQ. Divulgado pela empresa Sy[33] Sybase.com. Introduction to Sybase°
base em http://infocenter.sybase.com/help/index.jsp?topic=/com.
sybase.help.iq_12.6.iqintro/html/iqintro/title.htm, acessado em
19/06/2006, December 2004.
97
R IQ 12.6 Reference Manual.
[34] Sybase.com.
Sybase°
Divulgado pela
empresa Sybase em http://infocenter.sybase.com/help/index.jsp?
topic=/com.sybase.help.iq_12.6.iqref/html/iqref/title.htm, acessado em 19/06/2006, December 2004.
[35] Luiz Cláudio Chaves Ziulkoski. Coleta de requisitos e modelagem de dados
para Data Warehouse: um estudo de caso utilizando técnicas de aquisição
de conhecimento. Bacharelado em Ciência da Computação pelo Instituto de
Informática da Universidade Federal do Rio Grande do Sul, Março 2003.
98

Universidade de Brasília Instituto de Ciências

Transcrição

Documentos relacionados

1) Atualmente, segundo Tofler estamos vivenciando a Sociedade do

normas para tabelas e gráficos

Baixar este arquivo PDF - Rede Batista de Educação

Apostila Método VHLS

Pictogramas e Gráficos Circulares

Aprendendo o Valor Posicional dos Números Através dos Dados

normas para publicação dos trabalhos nos anais da

Dorli Maria Schneider

Com amor, a garota chamada Estrela

Guia de Modelagem de Dados - DATASUS

estudo analítico de ferramentas open source para ambientes olap