Banco de Dados Gerenciais

ANA KARINA DE OLIVEIRA ROCHA
ELMANO RAMALHO CAVALCANTI
SÉRGIO CAVALCANTI DE PAIVA
Banco de Dados Gerenciais
Monografia submetida ao Professor Dr.
Ulrich Schiel da disciplina de Modelos de
Dados do Curso de Pós-Graduação em
Informática da Universidade Federal de
Campina Grande.
Área de concentração: Ciência da Computação
Linha de Pesquisa: Banco de Dados
Campina Grande – PB
Maio de 2007
1
SUMÁRIO
1. INTRODUÇÃO ............................................................................................... 8
2. MOTIVAÇÃO.................................................................................................. 9
3. FUNDAMENTAÇÃO TEÓRICA.................................................................... 11
3.1 Conceitos................................................................................................ 11
3.1.1 Dado x Informação ........................................................................... 11
3.1.2 Sistemas de Informações................................................................. 11
3.1.3 Data Warehouse .............................................................................. 12
3.1.4 Data Mart ......................................................................................... 13
3.1.5 Arquitetura do Data Warehouse ....................................................... 14
3.1.6 Sistemas de Suporte à Decisão ....................................................... 18
3.1.7 Business Intelligence........................................................................ 19
3.1.8. Modelagem de Dados ..................................................................... 20
3.1.9 Banco de Dados Relacional ............................................................. 22
3.1.10 Banco de Dados Multidimensional ................................................. 22
3.1.11 Análise Multidimensional................................................................ 23
3.1.12 OLTP.............................................................................................. 24
3.1.13 OLAP.............................................................................................. 24
3.1.14 Operações OLAP ........................................................................... 28
3.1.15 Modelagem Dimensional dos Dados.............................................. 29
3.1.16 Metadados ..................................................................................... 35
3.1.17 Ferramentas CASE (Computer Aided Software Engineering) ....... 36
3.1.18 SQL ................................................................................................ 37
3.1.19 Indexação....................................................................................... 39
3.1.20 XML................................................................................................ 39
3.1.21 XMLA ............................................................................................. 40
3.2 Aspectos na construção de um Data Warehouse................................... 41
2
3.2.1. Planejamento .................................................................................. 41
3.2.2 Necessidades das Empresas ........................................................... 42
3.2.3 Tipos de Sistemas de Informações na Empresa .............................. 45
3.2.4 Motivação da Empresa no Mercado................................................. 46
3.2.5 Necessidades e Benefícios para o Usuário...................................... 47
3.2.6 Perfil do Usuário na Empresa que Utiliza o Data Warehouse .......... 47
3.2.7 Análise do Ambiente Legado ........................................................... 50
3.2.8 Equipe de Desenvolvedores ............................................................ 52
3.2.9 Aspectos da Implementação Física (ROLAP/MOLAP)..................... 54
3.2.10 Performance................................................................................... 55
4. APLICAÇÃO................................................................................................. 57
4.1.1 Informação ....................................................................................... 60
4.1.2 Modelo ............................................................................................. 61
4.1.3 Meta-Modelo .................................................................................... 63
4.1.4 Meta-meta Modelo ........................................................................... 66
4.2 Modelagem Interna ................................................................................. 67
4.2.1 Diagrama Entidade Relacionamento................................................ 67
4.2.2 Relacionamento entre Entidades ..................................................... 68
4.2.3 Tabela do Banco de Dados Relacional ............................................ 69
4.2.4 Tabelas (ou relações, ou entidades) ................................................ 69
4.3 Modelagem Externa................................................................................ 70
4.3.1 Esquema estrela .............................................................................. 70
4.3.2 Cubo................................................................................................. 73
4.3.3 Recuperação da informação ............................................................ 75
5. CONCLUSÃO............................................................................................... 81
REFERÊNCIAS................................................................................................ 82
Apêndice A ....................................................................................................... 88
A.1 Estrutura................................................................................................. 88
A.2 Consultas MDX ...................................................................................... 89
3
LISTA DE FIGURAS
Figura 1: Arquitetura do sistema de DW .......................................................... 14
Figura 2: Arquitetura em camadas ................................................................... 16
Figura 3: Granularidade em camadas .............................................................. 18
Figura 4: Exemplo de Drill-down e Roll-up ....................................................... 29
Figura 5: Exemplo de Slice............................................................................... 29
Figura 6: Exemplo de um Cubo Dimensional ................................................... 32
Figura 7: Exemplo de uma Estrutura Star Schema .......................................... 33
Figura 8: Exemplo de uma Estrutura Snow-Flake ............................................ 34
Figura 9: Tipos de Sistemas de Informação (Laudon e Laudon 1998)............. 45
Figura 10: Arquitetura do servidor OLAP utilizada. .......................................... 59
Figura 11: Diagrama de Objeto ........................................................................ 61
Figura 12: Diagrama de Classe........................................................................ 62
Figura 13: Modelo Entidade Relacionamento................................................... 68
Figura 14: Relacionamento entre Entidades .................................................... 69
Figura 15: Tabela no Banco de Dados Relacional ........................................... 70
Figura 16: Esboço do esquema estrela............................................................ 71
Figura 17: Esquema estrela da BD dimensional .............................................. 72
Figura 18: Povoamento do banco de dados..................................................... 75
Figura 19: Recuperação da informação ........................................................... 77
Figura 20: Avaliação dos Projetos por Departamento ...................................... 78
4
LISTA DE TABELAS
Tabela 1: Comparação do Modelo OLTP com OLAP....................................... 25
Tabela 2: Relatório dos projetos por área temática e tempo ............................ 78
Tabela 3: Arquitetura ANSI/SPARQ ................................................................. 79
5
LISTA DE SIGLAS E ABREVIATURAS
DSS
Decision Support Systems
EIS
Executive Information System
IDC
International Data Corporation
DW
Data warehouse
OLAP
Online Analytical Processing
SGBD
Sistema Gerenciador de Banco de Dados
MER
Modelo Entidade-Relacionamento
DER
Diagrama Entidade-Relacionamento
SGBDR
Sistema Gerenciador de Banco de Dados Relacional
SQL
Structured Query Language
OLTP
Online Transaction Processing
ROLAP
Relacional OLAP
HOLAP
Híbrido OLAP
MOLAP
Multidimensional OLAP
WOLAP
Web OLAP
DM
Dimensional Modeling
RDBMS
Relational Data Base Management System
CASE
Computer Aided Software Engineering
DDL
Data Definition Language
DML
Data Manipulation Language
DCL
DIGITAL Command Language
ISO
International Organization for Standardization
ANSI
American National Standards Institute
NIST
National Institute of Standards and Technology
6
FIPS
Federal Information Processing Standards
RPC
Remote Procedure Call
IMS
Information Management System
VSAM
Virtual Storage Access Method
W3C
World Wide Web Consortium
SGML
Standard Generalized Markup Language
HTML
HyperText Markup Language
DTDs
Document Type Definitions
XML
eXtensible Markup Language
XMLA
XML for Analysis
MDX
Multidimensional Expressions
7
1. INTRODUÇÃO
A disseminação e o aperfeiçoamento dos produtos e metodologias para
suporte dos bancos de dados gerenciais têm ocupado uma posição de
destaque no cenário internacional, devido às pressões dos tempos modernos,
as sucessivas reestruturações das organizações, e a necessidade cada vez
maior de informações. Estes fatores tornam crítica a capacidade de gestão dos
negócios, pois os métodos tradicionais de acesso e de análise dos dados,
baseados na tecnologia de bancos de dados relacionais, embora consigam
pesquisar e manipular grandes volumes de dados, ainda não permite analisar e
entender, em tempo hábil, um imenso volume de dados [30].
Diante disto, surge o problema de supersaturação do mundo dos
negócios, quando a obtenção de informações úteis sobre um grande volume de
dados ultrapassa a capacidade de analisá-los. Assim, uma nova geração de
técnicas, produtos e serviços que permitam a extração e manipulação
automatizada de dados e descoberta de conhecimento, faz-se necessária.
Neste contexto, vamos estudar um ambiente com informações
consistentes e precisas, obtidas das mais variadas fontes de dados,
representando uma nova maneira de visualizar a organização em âmbito
estratégico e estrutural para suporte a decisão e compartilhamento de
informações que é conhecido como Data warehouse.
Na seção 4 realizaremos a modelagem de um sistema gerencial de
acompanhamento de projetos acadêmicos, usando os conceitos de data
warehouse. Em seguida, criaremos uma base de dados de teste e utilizaremos
ferramentas OLAP para a verificação do sistema.
8
2. MOTIVAÇÃO
O Data warehouse nasceu a partir do reconhecimento da importância do
valor da informação nas organizações. Ele é um ambiente expansível e
planejado para a análise de dados não voláteis. Estes dados são logicamente e
fisicamente transformados, provenientes de múltiplas aplicações, atualizados e
mantidos por um longo período de tempo, expressos em termos do negócio e
resumidos para uma análise eficiente. Assim, um data warehouse é uma
plataforma com dados integrados e qualidade melhorada para apoiar vários
DSS (Sistema de Apoio de Decisão), aplicações de EIS (Sistema de
Informação Executiva) e processos empresariais [15].
Em termos tecnológicos, um data warehouse é uma combinação de
várias tecnologias, tendo como primeiro objetivo à integração efetiva de bases
de dados operacionais em um ambiente que habilita o uso estratégico dos
dados. Estas tecnologias incluem sistemas gerenciadores de banco de dados
relacional e multidimensional, arquitetura cliente/servidor, modelagem de
metadados e repositórios, interfaces gráficas para usuário, etc.
Pode-se explicar a motivação para a construção de um data warehouse
através de alguns pontos importantes citados pela IDC (International Data
Corporation), que são [15]:
•
A habilidade em focalizar processos empresariais e efetuar uma
análise financeira completa destes processos, assim como permitir as
organizações tomarem decisões baseadas na compreensão do sistema como
um todo ao invés de fazer estimativas duvidosas fundadas sobre dados
incompletos.
•
A habilidade em racionalizar e automatizar o processo de
construção de um repositório de informações integradas para uma empresa ao
invés de desenvolver inúmeros sistemas de apoio à decisão e sua infraestrutura correspondente.
•
O preço do hardware e do software, bem como os custos de
armazenamentos relacionados ao desenvolvimento, organização (deployment),
9
e manutenção de grandes repositórios de dados estão continuamente
diminuindo.
•
Os benefícios de um data warehouse podem ser facilmente
estendidos à tomada de decisões estratégicas, que podem trazer grandes e
tangíveis benefícios.
•
A habilidade em entender e administrar simultaneamente macro e
micro perspectivas de uma organização, que pode economizar incontáveis
horas de trabalho manual das organizações e pode ajudar a evitar cometer
enganos dispendiosos, que podem ser o resultado de suposições feitas sobre
dados incompletos ou incorretos.
10
3. FUNDAMENTAÇÃO TEÓRICA
3.1 Conceitos
3.1.1 Dado x Informação
Dado é um registro de fatos, conceitos ou instruções para a comunicação,
recuperação e processamento por meios automáticos e apresentação na forma
de informação compreensível para os seres humanos. Informações são dados
que os seres humanos assimilam e validam para resolver problemas ou tomar
decisões [13].
Dados são os componentes básicos, a partir dos quais a informação é
criada. Informações são dados inseridos em um contexto. Contexto é a
situação que está sendo analisada. A partir da informação vem o
conhecimento, que permite tomar decisões adequadas, trazendo vantagem
competitiva [18].
3.1.2 Sistemas de Informações
Segundo Mallack (2000), sistema de informações é um sistema que tem
como propósito armazenar, processar e compartilhar informações.
Lesca
(1996)
define
sistema
de
informações como o conjunto
interdependente das pessoas, da estrutura organizacional, das tecnologias de
informação, dos procedimentos e métodos, que disponibilizam em tempo hábil,
as organizações as informações necessárias para o seu funcionamento atual e
para sua evolução.
Já Laudon e Laudon (1998), definem sistema de informações como um
conjunto de componentes inter-relacionados que coleta (ou recupera),
processa, armazena e distribui informações para suporte ao controle e tomada
de decisões nas organizações.
Analisando-se as definições acima, conclui-se que o sistema de
informações, na sua forma final, aborda todos os componentes da organização.
11
Neste sentido, busca-se um ambiente que forneça informações internas,
informações externas, informações sobre as percepções do consumidor/cliente,
que permite análises e simulações, enfim, um ambiente integrador das
informações disponíveis e relevantes para o sucesso da empresa. [29].
Assim, o SI é um sistema a serviço da organização e de seus objetivos,
devendo ser coerente e coordenado com todos os aspectos da organização.
3.1.3 Data Warehouse
Data warehouse (armazém de dados) é um ambiente com informações
consistentes e precisas, obtidas das mais variadas fontes de dados,
representando uma nova maneira de visualizar a organização em âmbito
estratégico e estrutural para suporte a decisão e compartilhamento de
informações [2]. Ele apresenta as seguintes características básicas:
•
Orientado por temas: Refere-se ao fato do DW armazenar informações
sobre temas específicos importantes para o negocio da empresa. Exemplos
típicos de temas são produtos, atividades contas, clientes, etc. Em
contrapartida, o ambiente operacional é organizado por aplicações
funcionais. Por exemplo, em uma organização bancária, estas aplicações
incluem empréstimos, investimentos e seguros. [13].
•
Integrado: A integração mostra-se em muitas diferentes maneiras: na
consistência e padronização de nomes, das unidades das variáveis, etc., no
sentido de que os dados foram transformados até um estado uniforme. Por
exemplo, considere-se sexo como um elemento de dado. Uma aplicação
pode codificar sexo como M/F, outra como 1/0 e uma terceira como H/M.
Conforme os dados são trazidos para o DW, eles são convertidos para um
estado uniforme, ou seja, sexo é codificado apenas de uma forma. [13]
•
Não Volátil: Atualizações (inclusão exclusão e alteração) são feitas
regularmente no ambiente operacional de um registro básico. Mas a
manipulação de dados básicos que ocorre no data warehouse é mais
simples. Tem somente três espécies de operações que ocorrem no data
warehouse: a carga inicial do dado, o acesso ao dado e atualização
temporal (semanal, mensal) conforme necessidades do negócio [13].
12
•
Histórico: Todo dado no data warehouse é exato em algum momento do
tempo e em conseqüência desta informação, o dado criado no warehouse é
dito ser "histórico". Os valores históricos dos dados no data warehouse são
mostrados em várias maneiras. O modo mais simples é que o dado no data
warehouse representa os dados sobre um horizonte de tempo distante - de
5 até 10 anos [13].
Uma coleção de bancos de dados integrados e orientados a assuntos
projetados para apoiar as funções de um Sistema de Apoio de Decisão
(Decision Support Systems); onde cada unidade de dados é importante em um
momento no tempo. O data warehouse contém dados atômicos e muitas vezes
sumarizados [13].
Data warehouse é uma arquitetura de banco de dados com informações
de caráter gerencial voltado para: suporte à decisão, planejamento estratégico,
análise do comportamento de clientes e análise da performance de vendas.
Funciona como um provedor de informações de uma empresa ou instituição,
pois concentra todas as informações estratégicas e históricas, extraídas dos
sistemas transacionais relativos aos clientes e produtos. A proposta principal
do data warehouse é a democratização das informações para a área de
negócios, através do fácil acesso aos dados para análise [1].
3.1.4 Data Mart
Um data mart (mercado de dados) não é uma evolução de um data
warehouse, mas sim parte das estratégias deste. Um data mart é um
subconjunto de dados de um data warehouse, desenhado para suportar uma
necessidade de negócio ou uma unidade organizacional específica. A
estratégia correta é fazer o data mart incorporar-se à arquitetura de data
warehouse, sem perder a visão de conjunto. Essa visão de conjunto é
decorrência de um bom projeto de data warehouse [25]. O data mart é similar
ao data warehouse com algumas exceções:
•
O data mart opera um conjunto menor de dados.
•
O data mart visualiza o dados com um enfoque departamental enquanto o
data warehouse visualiza os dados com um enfoque corporativo.
13
•
O data mart visualiza os dados em uma base muito mais previsível
enquanto o data warehouse freqüentemente faz exploração na base de
dados.
Características comuns ao data warehouse e data mart são: informação
estrutural, fonte de informação e outras informações encontradas ao longo do
ambiente [13].
Obedece aos mesmos conceitos do data warehouse, diferenciando-se
somente no conteúdo, ou seja, os dados são organizados por assunto,
permitindo maior independência, agilidade e ganhos de performance [26].
3.1.5 Arquitetura do Data Warehouse
Podemos definir duas formas de apresentação da arquitetura de DWs,
uma conceitual e outra física do modelo relacional que representa o sistema.
3.1.5.1. Visão Conceitual
Figura 1: Arquitetura do sistema de DW
Além do DW podem existir vários Data Marts (DMs), que separam os
dados por setor dentro da organização.
14
Os dados contidos no DW e nos DMs são gerenciados por um ou mais
servidores de warehouse, os quais apresenta visões multidimensionais dos
dados para uma variedade de ferramentas front end.
A visão multidimensional em forma de cubo de dados indica que as
informações são visualizadas em linhas e colunas como o formato tradicional
das planilhas, porém existem mais dimensões, sendo que o cubo teria apenas
mais uma dimensão. Esta característica organiza e facilita a consulta aos
dados de maneira que se pode ter, por exemplo, numa dimensão do cubo os
meses do ano, na segunda dimensão estariam as cidades de origem dos
clientes e na terceira dimensão o médico que encaminhou o cliente para o
hospital [42].
3.1.5.2 Visão em Camadas
Camada de Bancos de Dados Operacionais e Fontes Externas: contém
as bases de dados operacionais e também pode ser composta de informações
de fontes externas, estes dados recebem um tratamento especial para
poderem ser incorporados ao DW [42].
15
Figura 2: Arquitetura em camadas
Camada de Acesso aos Dados: compõe o elo de ligação entre as
ferramentas de acesso à informação e os bancos de dados operacionais,
comunicando-se com diversos Sistemas de Gerenciamento de Banco de
Dados (SGBDs) e sistemas de arquivos, sendo que a este conjunto de
características dá-se o nome de acesso universal de dados [42].
Camada de Transporte ou Middleware: tem a função de gerenciar a
transmissão das informações pelo ambiente de rede que serve de suporte para
o sistema como um todo, separando as aplicações operacionais do formato
real dos dados, realiza ainda a coleta de mensagens e transações e se
encarrega de entregá-las nos locais e nos tempos determinados [42].
Camada do Data Warehouse: constitui-se do armazenamento físico dos
dados oriundos dos sistemas operacionais da empresa e externos, permitindo
um acesso mais rápido e seguro aos dados do DW, além de prover maior
flexibilidade de tratamento e facilidade manipulação [42].
Camada de Acesso à Informação: proporciona a interação com os
usuários finais através de ferramentas visuais tradicionais, tais como sistemas
de planilhas de cálculo, browsers, entre outras [42].
16
Camada de Metadados (Dicionário de Dados): os metadados descrevem
os dados e a organização do sistema, podem ser ainda fórmulas utilizadas para
cálculo, descrições das tabelas disponíveis aos usuários, descrições dos
campos
das
tabelas,
permissões
de
acesso,
informações
sobre
os
administradores do sistema, entre outras [42].
Camada de Gerenciamento de Processos: faz o controle destas tarefas
que mantêm o sistema atualizado e consistente, gerenciando as diversas
tarefas que são realizadas durante a construção e a manutenção dos
componentes de um sistema de DW [42].
Camada de Gerenciamento de Replicação: serve para selecionar, editar,
resumir, combinar e carregar no DW as informações a partir das bases
operacionais e das fontes externas, envolvendo programação bastante
complexa, sendo que existem ferramentas poderosas que permitem processos
sejam gerenciados de forma mais amigável, além do controle da qualidade dos
dados que serão carregados [42].
3.1.5.3 Estrutura Física dos Dados do DW
A respeito da disposição física dos dados, o DW pode ter uma estrutura
centralizada em um único local ou então ser implementado de forma
distribuída. Se optarmos pelo primeiro modelo, o centralizado, teremos um
warehouse consolidado e o Banco de Dados (BD) formará um DW integrado.
Definindo o projeto desta forma pode-se maximizar o poder de processamento
e acelerar os processos de busca por informações analíticas.
Definindo-se uma arquitetura federativa, pode-se distribuir a informação
por função, separando os dados do setor financeiro em um servidor, os dados
de marketing em outro local, e dados de manufatura em um terceiro lugar.
Existe ainda uma terceira metodologia, na qual considera-se uma arquitetura
de DW separada por camadas, armazenando os dados mais resumidos em um
servidor, dispondo os dados um pouco mais detalhados, em nível de detalhe
intermediário, em um segundo servidor, e por fim colocamos os dados mais
detalhados (atômicos) em um terceiro servidor. A figura 3 exemplifica esta
metodologia [42].
17
Figura 3: Granularidade em camadas
O primeiro servidor geralmente atende à maior parte das consultas,
sendo que teremos um menor número de pedidos de acesso solicitados para a
camada 2 e camada 3.
O dimensionamento dos servidores é o seguinte: na primeira camada
podemos ter uma configuração para suportar um grande número de usuários
que farão diversas consultas, as quais trabalharão com um volume
relativamente pequeno de dados. Já os servidores das outras duas camadas
devem ser configurados para permitir processar grandes volumes de dados,
porém não é necessária uma preocupação em configurar o sistema para
suportar o acesso de um número maior de usuários. Isto se explica pelo fato de
que a maioria dos usuários terá suas perguntas respondidas pelas consultas
iniciais da camada 1. Se algum usuário não se satisfizer com o nível de detalhe
das respostas da camada 1, pode buscar maiores informações na camada 2 e
até mesmo na camada 3. Concluímos então que poucos usuários farão
acessos regulares à última camada, sendo que alguns nunca o farão além do
nível inicial [42].
3.1.6 Sistemas de Suporte à Decisão
Um sistema utilizado para gerenciar decisões. Usualmente envolve a
análise de muitos dados. Como regra, não envolve a atualização dos dados,
18
somente efetua consultas. Sistemas projetados para os executivos que se
caracterizam pela análise de tendências.
Enquanto o resultado de um data warehouse é a possibilidade de auxiliar
no suporte a decisões, um DSS pode existir independentemente da arquitetura
de data warehouse. Além disso, um DSS é uma solução isolada e que não
inclui necessariamente uma arquitetura, uma infra-estrutura e nem mesmo
ferramentas de administração ou auditoria, ao contrário de um data warehouse,
que deve incluir todos esses componentes [25].
Contudo Mallack (2000) afirma que quando necessária uma arquitetura
para sistemas de suporte a decisão, ou qualquer outro tipo de sistema de
informação, esta deve contemplar:
• interoperabilidade dos sistemas, de forma que as informações possam
ser acessadas, fácil e rapidamente;
• compatibilidade dos sistemas, permitindo que os recursos possam ser
facilmente compartilhados e distribuídos através da organização;
• expansibilidade dos sistemas, garantido que limitações em componentes
de funções simples não criem obstáculos para o crescimento da organização.
Dependendo da arquitetura que se pretende utilizar, existem diversas
metodologias para a sua construção.
3.1.7 Business Intelligence
É um processo de coleta, transformação, análise e distribuição de dados
para melhorar a decisão de negócios; sua infra-estrutura tecnológica é
composta de data warehouses ou data marts, ferramentas OLAP, EIS, data
mining, consultas e relatórios e software de visualização dos dados; os bancos
de dados são a infra-estruturas básica de qualquer sistema de business
intelligence. São neles que vão estar armazenados os dados que serão
transformados em informações competitivas [17].
19
3.1.8. Modelagem de Dados
Modelagem de dados é uma atividade na qual procuramos construir uma
estrutura de dados que reflita a realidade e ao mesmo tempo seja facilmente
manuseada por computadores para que os sistemas construídos a partir dela
sejam estáveis e sofram o mínimo de manutenção possível. A modelagem é
dividida em três etapas ou níveis: Conceitual, Lógico e Físico.
Modelo Conceitual: É desenvolvido sem levar em consideração nenhum
aspecto de representação lógica ou física dos dados, seja software, hardware
ou visão particular de um usuário. É baseado em como funciona o negócio do
cliente e ignora detalhes de implementação e performance [28].
Modelo Lógico: É desenvolvido levando-se em consideração a arquitetura
de dados suportada pelo sistema gerenciador de banco de dados. Exemplo:
Em Rede, Hierárquico, Relacional. Há a definição das tabelas, colunas e
chaves. A meta é a redução de redundâncias para simplificação do
gerenciamento e aumento da integridade [28].
Modelo Físico: O mapeamento físico leva em consideração características
de hardware e software (SGBD) e estimativas de espaço e tempo
(performance) [28].
O inicio para o plano de migração é um modelo de dados. O modelo de
dados representa as necessidades de informação da corporação. Representa o
que a corporação necessita não necessariamente o que a corporação
atualmente possui. É construído sem consideração de tecnologia [12].
O Modelo Entidade-Relacionamento (MER) será a técnica de modelagem
de dados utilizada para criação do Modelo Conceitual de Dados [9].
Esta técnica é usada para descrever o mundo real com alto grau de
abstração, em termos de entidades (objetos de interesse), relacionamentos
(forma como as entidades estão interligadas) e atributos (características das
entidades e relacionamentos) [9].
O MER é composto por uma representação gráfica, o chamado Diagrama
Entidade-Relacionamento (DER) e um conjunto de informações escritas sobre
cada conceito representado (entidades, relacionamentos e atributos) [9].
20
Apesar de ter surgido junto com a Análise Estruturada, o MER, por sua
flexibilidade, foi evoluindo com o aparecimento de novas abordagens de
desenvolvimento de sistemas (Engenharia da Informação, Análise Essencial,
Análise Orientada a Objetos), e é considerada uma linguagem universal para a
representação da realidade dos negócios de uma empresa [9].
Modelo de Dados: Estruturas de dados lógicas, providas por um sistema
gerenciador de banco de dados utilizado para a representação dos dados [13].
Entidade: Armazena os dados de uma pessoa, lugar ou objeto de
interesse em um alto nível de abstração [13]. Todo o objeto, coisa que tem
alguma existência no negócio, na vida real. Não são tabelas, são implantadas
como tabelas [23].
Relacionamentos: As ações ou fatos que integram as entidades no mundo
real [23].
Modelo Entidade-Relacionamento (MER): Um modelo de dados que
define entidades, o relacionamento entre entidades e os atributos que tem
valores para descreverem as propriedades das entidades e/ou relacionamentos
[13].
Diagrama de Entidade-Relacionamento (DER): Um modelo de dados de
alto nível que demonstra, esquematicamente, todas as entidades dentro do
âmbito de integração e a relação direta entre essas entidades [13].
Chave: Um item de dado ou combinação de itens de dados utilizados para
identificar ou localizar uma instância de um registro ou algum agrupamento de
dados similares [13]. Elas podem ser:
• Chave Primária: Um atributo único utilizado para identificar um registro
em um banco de dados. Uma ou mais colunas que unicamente
identificam uma linha da tabela. Chaves primárias devem ser únicas e
não nulas.
• Chave Estrangeira: Uma ou mais colunas que referenciam à chave
primária de outra tabela.
• Chave Comum: Uma ou mais colunas que são freqüentemente
utilizadas para relacionar tabelas.
21
Chaves não são o mesmo que índices. Uma chave pode ou não ser um índice.
As chaves são definidas no projeto lógico enquanto índices são definidos no
projeto físico para garantir performance e outras razões [6].
3.1.9 Banco de Dados Relacional
Um Sistema Gerenciador de Banco de Dados Relacional (SGBDR)
mantém tabelas que são compostas por colunas que descrevem linhas de
dados.
Uma base ou banco de dados é uma coleção de dados relacionados e
armazenados (freqüentemente com redundância controlada e limitada) de
acordo com um esquema. Um banco de dados pode servir única ou múltiplas
aplicações.
Os atuais Sistemas Gerenciadores de Bancos de Dados Relacionais
oferecem uma solução poderosa e eficiente para o processamento de grandes
volumes de transações de uma grande variedade de aplicações comerciais e
científicas [8].
3.1.9.1 Tabelas
Tabela é uma relação que consiste em um conjunto de colunas com um
título e um conjunto de linhas. Coluna é uma tabela vertical onde são
selecionados valores do mesmo domínio. Uma linha é composta de uma ou
mais colunas.
Em um banco de dados relacional, todos os dados estão em tabelas. Uma
tabela mantém dados relacionados com uma classe particular de objetos (uma
entidade). Tabelas são compostas por linhas e colunas. Existe exatamente um
conteúdo de dado em cada coluna de cada linha [31].
3.1.10 Banco de Dados Multidimensional
Um sistema gerenciador de banco de dados especificamente projetado
para suportar várias dimensões de dados em uma arquitetura três camadas.
22
Tipicamente não suportam SQL (Structured Query Language) diretamente e,
atualmente, suportam um volume de dados significantemente menor que um
Sistema Gerenciador de Banco de Dados Relacional. Entretanto, esse tipo de
gerenciador de banco de dados pode ser uma excelente opção para uma
implementação departamental se a funcionalidade que ele provê atende à
demanda do usuário referente às informações do negócio [13].
“As pessoas falam da necessidade de separar a captura dos dados do
acesso aos dados, em termos de bases separadas, movendo informações
entre si, ao menos desde o início dos anos 80”, testemunha o especialista da
IDC em data warehouse Henry Morris. O que mudou foi a maturação de várias
tecnologias-chave: agora não é mais só o banco de dado relacional; mas
SGBDR multidimensional, com características especiais para aumento de
performance, como indexação bitmap, e novos esquemas para organizar e
representar os dados, visando não somente a inserção rápida de novas
transações, mas análise e consultas complexas [3].
3.1.11 Análise Multidimensional
Análise multidimensional é a habilidade em manipular dados que foram
agregados em várias categorias ou dimensões. A proposta da análise
multidimensional é auxiliar o usuário a sintetizar a informação da empresa
através de uma visão comparativa, personalizada e projetada para a análise de
dados históricos [13].
Algumas ferramentas de análise multidimensional possuem a habilidade
em acessar dados em um sistema gerenciador de banco de dados relacional;
outras requerem um esquema estrela (“star schema”) para facilitar o
processamento multidimensional [13].
A visão multidimensional é muito mais útil para os analistas do que a
tradicional visão tabular utilizada nos sistemas de processamento de transação.
Ela é mais natural, fácil e intuitiva, permitindo a visão dos negócios da empresa
em diferentes perspectivas e, assim, transformando o analista num explorador
da informação [7].
23
3.1.12 OLTP
O Processamento Transacional Online registra todas as transações
contidas em uma determinada operação organizacional. Por exemplo: sistema
de transações bancárias registra todas as operações efetuadas em um banco.
Transação OLTP consome poucos recursos; pesquisa quantidade
reduzida de dados. Como resultado desta disciplina, o tempo de resposta de
uma transação é bom (dois a três segundos são o normal) [13].
De maneira geral, um sistema aplicativo está focado na precisão dos
processos operacionais [33].
3.1.13 OLAP
Processamento Analítico Online é um importante método na arquitetura
do data warehouse na qual os dados podem ser transformados em informação.
OLAP é uma categoria de tecnologia de software que permite a analistas,
gerentes e executivos a obterem perspicácia em dados de uma forma rápida,
consistente e com acesso interativo para uma grande variedade de possíveis
visões da informação na empresa. Mais sucintamente, OLAP é um conjunto de
funcionalidades
que
tem,
como
principal
objetivo,
facilitar
a
análise
multidimensional [13].
OLAP representa um conjunto de tecnologias projetadas para suportar
análise e consultas ad hoc (consultas efetuadas pelo usuário de acordo com
sua necessidade momentânea).
A característica principal dos sistemas OLAP é permitir uma visão
conceitual multidimensional dos dados de uma empresa [7].
A criação do OLAP foi em decorrência da forte necessidade de análises
dos dados de forma fácil e flexibilidade, mas ao mesmo tempo, analisando
múltiplas visões do negócio em diferentes níveis de detalhes.
Os bancos de dados multidimensionais foram a resposta para atender a
essas necessidades analíticas. No início dos anos 90 começaram a surgir os
primeiros protótipos de bancos de dados multidimensionais. Após alguns anos
de aprimoramento da tecnologia, os bancos de dados multidimensionais foram
24
submetidos à análise de E. F. Codd e sua equipe em 1993. Codd então definiu
12 regras, padrões, homologou a tecnologia, e batizou os bancos de dados
multidimensionais com o nome de OLAP (derivado do termo OLTP - que foi
atribuído aos Bancos de Dados Relacionais no início da década de 1970,
quando Codd definiu os padrões para modelo Relacional).
A partir da homologação de Codd, a tecnologia começou a ser utilizada e
conhecida em 1994, e os fornecedores da tecnologia criaram produtos com
cada vez mais capacidade de armazenamento, bem como vários outros
recursos para facilitar as análises.
Começou então a utilização de Banco de Dados Multidimensionais como
Data Marts entre 1995/96 e a tecnologia evoluiu a passos largos [5].
As bases OLAP podem ser acessadas/manipuladas através de aplicações
personalizadas ou ainda via Internet/Intranet e aplicações pré-definidas para se
fazer análises diversas.
Abaixo há uma tabela comparativa:
Operação típica
OLTP
Transação
OLAP
Análise
Granularidade
Atômico
Agregado
Temporalidade dos dados Presente
Histórico, atual e projetado.
Recuperação
Poucos registros Muitos registros
Usuários
Muitos
Poucos
Orientação
Registros
Arrays
Consulta
Predefinida
Ad-hoc
Tabela 1: Comparação do Modelo OLTP com OLAP
Essa tabela é apenas para dar uma idéia geral e será detalhada abaixo:
Operação típica: No modelo OLTP são efetuadas transações, que podem
ser, por exemplo, uma atualização de um registro, uma remoção, uma
recuperação ou uma criação. Já no modelo OLAP os dados servem para ser
analisados, por exemplo, saber qual foi o produto mais vendido há dois meses.
[34]
25
Granularidade: No modelo OLTP os dados são tratados com o máximo de
detalhamento, já no OLAP os dados estão agregados, ou seja, há um resumo
dos dados. Esse resumo é o necessário para que sejam feitas análises. [34]
Temporalidade dos dados: No OLTP o que importa são os dados atuais,
por exemplo, se o preço de um produto passa de x para y então x é apagado e
substituído por y. No OLAP o passado importa, pois os dados são utilizados
para análise e previsões futuras, ambas atividades que necessitam de
informações sobre o passado. Logo o modelo OLAP considera as informações
atuais e também as informações anteriores, as quais no OLTP poderiam não
mais existir. [34]
Recuperação: No modelo OLTP geralmente poucos registros são
recuperados em uma consulta. Por exemplo, o preço de um produto, os dados
de um cliente. No OLAP vários registros são recuperados, por exemplo, a
quantidade vendida de um dado produto em cada um dos últimos sete meses
agrupados por cidade. [34]
Usuários: No modelo OLTP existem muitos usuários utilizando o sistema
ao mesmo tempo, porém com consultas mais simples. No OLAP existem
poucos usuários com consultas mais complexas. [34]
Orientação: O modelo OLTP é orientado a registros, termo que é muito
comum em informática e geralmente significa uma linha em uma tabela de um
banco de dados relacional. O modelo OLAP utiliza arrays, os quais são bons
para representar dimensões, como, por exemplo, a dimensão tempo ou a
dimensão lugar. [34]
Consulta: No modelo OLTP os tipos de consultas que podem ser
realizadas já são predefinidos, por exemplo, consultar o preço de um produto
ou consultar o débito de um cliente. No OLAP as consultas são ad-hoc, ou seja,
são definidas de acordo com os interesses de quem realiza a consulta, por
exemplo, qual o total de vendas de um dado produto em cada um dos últimos
três meses por cidade. [34]
A tecnologia OLAP hoje é largamente utilizada na elaboração de Data
Marts com desdobramentos para ROLAP/modelagem NxN no Relacional e
HOLAP (Híbrido OLAP que combina OLAP com ROLAP) [5].
26
A utilização de OLAP híbrido, o H-OLAP só é necessária quando se trata
de bases muito grandes, de grande ocorrência em Varejo, Banco e
Seguradoras [5].
3.1.13.1 ROLAP
Nos sistemas ROLAP (Relacional OLAP) temos uma base de dados
relacional que será analisada de maneira multidimensional. A base de um
desenho
físico
ROLAP
é,
tipicamente,
uma
combinação
de
dados
apropriadamente normalizados em uma ou mais técnicas star schema
[13].Esse trabalho poderá ser feito de duas maneiras:
•
Todo o processamento sendo feito no servidor do banco de dados. Esses
servidores OLAP geram os comandos SQL em diversos passos e as
tabelas necessárias para o processamento das consultas.
•
Todo o processamento dos dados sendo feito no servidor OLAP, mas o
servidor dos dados executando os comandos SQL, inclusive os joins e
agregações.
Algumas outras características dos servidores ROLAP:
•
Uso de metadados que descrevem o modelo e servem também para o
auxílio na construção de consultas. Com o uso dos metadados, um analista
é capaz de executar consultas de maneira mais personalizada, buscando os
dados e usando os critérios que achar mais conveniente. [43]
•
Capacidade de criar comandos SQL mais otimizados para o banco de
dados com o qual trabalha. [43]
A maior vantagem da adoção da tecnologia ROLAP está no fato de ser
uma tecnologia já estabelecida e cuja arquitetura é aberta e padronizada, já
que é relacional. Isso faz com que possa utilizar diversas plataformas,
escalabilidade e paralelismo de hardware. [43]
27
3.1.13.2 MOLAP
É qualquer análise multidimensional efetuada em um sistema gerenciador
de banco de dados multidimensional [13].
MOLAP (Multidimensional OLAP) é uma classe de sistemas que permite a
execução de análises bastante sofisticadas usando como gerenciador de
dados um banco de dados multidimensional [7].
3.1.13.3 HOLAP
É um produto de OLAP híbrido que pode prover análise multidimensional
simultaneamente
de
dados
armazenados
em
um
banco
de
dados
multidimensional e em um banco de dados relacional [17].
3.1.13.4 WOLAP
Representa a migração da tecnologia OLAP para o ambiente da Internet
(Web OLAP). Tem havido uma grande divulgação sobre o uso de Web
browsers para acesso à OLAP, mas ainda são poucos os sites em
funcionamento com o uso de OLAP. Segundo alguns institutos de pesquisa o
OLAP baseado na Web será a chave para aplicações na Intranet e deverá
oferecer um caminho simples e barato no acesso ao data warehouse [17].
3.1.14 Operações OLAP
Operações OLAP são as operações de pesquisa e exploração da
informação no cubo de dados. São elas:
• Slice and Dice: São operações de fatiamento do cubo de dados,
permitindo sua visualização em segmentos, assim como a rotação do cubo
buscando novas perspectivas de visão de dados.
• Drill Down e Roll UP: É a capacidade de navegação aprofundando o
nível de detalhamento dos dados, ou subindo este nível de detalhe conforme a
hierarquia.
28
Figura 4: Exemplo de Drill-down e Roll-up
Figura 5: Exemplo de Slice
3.1.15 Modelagem Dimensional dos Dados
A modelagem dimensional é a técnica utilizada para se ter uma visão
multidimensional dos dados. Nessa técnica, os dados são modelados em uma
estrutura dimensional conhecida por cubo. As dimensões do cubo representam
os componentes dos negócios da empresa, tais como “cliente”, “produto”,
“fornecedor” e “tempo”. A célula resultante da intersecção das dimensões é
chamada de medida e geralmente representa dados numéricos como
“unidades vendidas”, “lucro” e “total de venda” [7].
Além dos componentes dimensão e medida, outro importante aspecto do
modelo multidimensional é a consolidação dos dados, uma vez que para a
tarefa de análise são mais úteis e significativos à agregação (ou sumarização)
dos valores indicativos dos negócios [7].
O próprio desenho do data warehouse leva a novas perspectivas de
projeto. Não há necessidade de modelagem na terceira forma normal. Na
29
prática, redundância de dados é bem-vinda nesse ambiente. Para muitos
projetistas, é uma maneira diferente de modelar dados [33].
Modelagem Dimensional é um nome novo para uma técnica antiga usada
para criar bancos de dados simples e compreensíveis. Quando um banco de
dados pode ser visualizado como um “cubo” contendo até três, quatro, cinco ou
mais dimensões, as pessoas conseguem visualizar este cubo em qualquer de
suas dimensões.
Outro nome para modelo dimensional é star join schema. Os projetistas
de bancos de dados têm utilizado esse nome já há algum tempo para
descrever modelos dimensionais porque o diagrama é semelhante a uma
estrela com uma tabela no centro rodeada por tabelas auxiliares exibidas em
um padrão radial [19].
Dimensional Modeling (DM) é uma técnica lógica de projeto muito
utilizada nos data warehouses, diferente e oposta ao entity-relation modeling
(ER). O DM é a única técnica viável para os bancos de dados projetados para
suportar as consultas de usuário final de um data warehouse. O ER é muito útil
na captura de transações e nas fases de administração de dados da
construção de um data warehouse, mas deve ser evitado para o usuário final
[4].
O DM é uma técnica lógica de projeto que busca apresentar os dados
dentro de uma estrutura padrão e intuitiva, permitindo ainda o acesso de alto
desempenho. Ele é inerentemente dimensional e adota a disciplina com
algumas restrições importantes. Todo modelo dimensional é composto por uma
tabela com uma chave de várias partes, denominado tabela de fatos e um
conjunto de tabelas menores chamadas tabelas de dimensão. Cada tabela de
dimensão possui uma chave de uma única parte, que corresponde exatamente
a um dos componentes da chave de várias partes da tabela de fatos. Essa
característica de estrutura de “estrela” também é chamada de star join. Este
termo remonta os primeiros dias dos bancos de dados relacionais [4].
30
3.1.15.1 Fatos
São as medidas básicas de informações do negócio. Representa as
quantidades e valores dos dados que podem ser agregados sem perderem seu
significado. A tabela fato ou fact table armazena as medidas básicas objetos de
análise do negócio. O dado na tabela fato é composto de elementos de dados
organizados em um nível estruturado. Os valores destes elementos de dados
podem ser sumarizados em uma variedade de formas sem por em risco a
integridade dos dados [13].
A chave de uma tabela fato é a composição das chaves das tabelas
dimensão. O resultado é que existirá uma linha na tabela fato para cada
combinação única dos domínios de todas as chaves de todas as tabelas
dimensão. Características:
• Quantifica o dado que foi descrito nas tabelas dimensão.
• Chave composta de combinação única de valores das chaves das
dimensões.
• Os valores da tabela fato são somente aditivos.
• Sempre contém uma data.
3.1.15.2 Dimensões de um Cubo
Descrevem ou caracterizam os dados relacionados e organizados na
tabela fatos. As tabelas dimensão circundam a tabela fato. Representam as
possíveis formas de visualizar e consultar os dados. Características:
• Chave deve ser única.
• Permitir gerenciar número de níveis de agregações.
• Dimensão não precisa ser uma hierarquia, pode ser uma combinação
de atributos.
31
Figura 6: Exemplo de um Cubo Dimensional
3.1.15.3 Agregações
Agregações são sumarizações de dados com o objetivo principal de
melhorar a performance de acesso. Geralmente armazenadas em tabelas fatos
separadas [13].
Abstração de dados que, aplicada à modelagem conceitual de dados,
permite que objetos venham a formar um novo objeto de mais alto nível. [28].
Agregações fornecem níveis múltiplos de detalhes do fato.
Os resultados das queries (ou seus valores intermediários) são précalculados, o que melhora muito a performance [18].
As agregações podem ser acumuladas através de agrupamentos
diferentes, freqüentemente através de várias dimensões ou combinação de
dimensões [18].
O único aspecto mais importante de design de um data warehouse é o
assunto da granularidade. Granularidade se refere ao nível de detalhe contido
as unidades de dados no data warehouse.
Quanto mais detalhamento há, mais baixo será o nível de granularidade.
Quanto menos detalhamento há, mais alto o nível de granularidade.
A razão por que granularidade é o assunto de design principal no
ambiente de data warehouse é que afeta profundamente o volume de dados
residente no data warehouse e ao mesmo tempo afeta o tipo de questão que
pode ser respondida [12].
32
3.1.15.4 Técnica Star Schema (Esquema Estrela)
A técnica star schema pré-processa os dados em uma tabela fatos central
com tabelas de dimensão relacionadas. As únicas chaves de cada tabela
dimensão compõem uma chave combinação na tabela fatos. Os benefícios
desta técnica são que os dados estão pré-processados em dimensões
conhecidas e caracterizadas em um conjunto específico de necessidades de
informação do negócio, tornando o acesso pelo usuário mais eficiente.
Figura 7: Exemplo de uma Estrutura Star Schema
Este modelo é composto por uma tabela com chave de múltiplas partes
(dimensões) chamadas de tabela fato e de um conjunto de tabelas pequenas
chamadas de dimensões, que formam as pontas das estrelas. Cada tabela de
dimensão tem uma chave primária simples que corresponde a um dos
componentes da chave múltipla da tabela fato.
A princípio parece um modelo muito simples de ser construído, porém a
determinação das dimensões e do fato tem necessidade de excelente
entendimento conceitual para que se obtenha sucesso em uma implantação de
data warehouse [23].
33
3.1.15.5 Técnica Snow Flake (Floco de Neve)
A técnica snow flake é uma variante do star schema com as tabelas
dimensões normalizadas [23].
Figura 8: Exemplo de uma Estrutura Snow-Flake
As hierarquias têm significado e importância dentro da análise
multidimensional.
No
modelo
star,
elas
estão
todas
em
vista
da
desnormalização das entidades, um dos conceitos básicos de modelagem
multidimensional.
Um esquema alternativo é o esquema snow flake, onde normalizando as
hierarquias encadeamos relacionamentos e entidades a partir das dimensões.
A utilização de esquema snow flake depende da necessidade de otimizações
no projeto físico ou nas queries realizadas. Lembramos que sempre um data
warehouse tem como objetivo sistemas de apoio à decisão, que necessitam
das mais variadas consultas [23].
Um esquema snow flake em nosso entendimento é somente uma
alternativa de construção do modelo de dados multidimensional. Todo modelo
snow flake pode rapidamente ser transformado em um star, bastando para isto
relacionarmos as hierarquias diretamente às tabelas fato, desnormalizando-as
completamente [23].
34
3.1.16 Metadados
São dados sobre dados. Descrição dos dados: estrutura, conteúdo,
chaves, índices, detalhes, etc. Sem os metadados, o data warehouse e seus
componentes associados seriam meramente componentes não integrados
trabalhando independentemente e com objetivos distintos [13].
Para alcançar harmonia e unidade entre os diferentes componentes do
ambiente projetado, deve haver uma técnica bem definida e rigorosa para
desenvolver os metadados. Existem metadados para:
• O ambiente operacional.
• A camada de integração e transformação.
• Porções detalhadas do data warehouse.
• Depósitos de dados operacionais.
• Data mart’s.
• Ambiente de desenvolvimento.
• Modelo do negócio da Empresa.
Para atingir um grau de segurança na confiabilidade dos dados, o
primeiro passo é catalogar os metadados com RDBMS (Relational Data Base
Management System), plataforma, fontes de dados, tabelas, campos, índices,
chaves primárias, chaves estrangeiras, stored procedures, parâmetros,
programas – ou seja, o metadados contém todas as informações que explicam
o funcionamento da base de dados [24].
Com os metadados catalogados, as estruturas de dados de todo o
ambiente estarão sempre sendo verificadas. Portanto, a cada mudança que
ocorra nas bases de dados transacionais, o administrador estará sempre sendo
alertado, o que aumenta sua confiança na informação que estará sendo
disponibilizada aos tomadores de decisão [24].
Importante utilizar metadados para descrever o modelo dos dados e para
auxiliar na construção das consultas. Dessa maneira, um analista pode
executar suas análises utilizando seus próprios termos [7].
35
O Metadado é um dado sobre um determinado dado. Por exemplo: os
metadados poderiam indicar se uma base de dados existe na corporação,
quais atributos formam uma determinada tabela, características físicas de um
determinado atributo, tais como: tamanho e formato, onde ele é utilizado, etc.
As informações do metadado podem ser sobre os dados do legado, dados
armazenados em data warehouse ou informações pertinentes a um catálogo.
Estas informações são armazenadas em um repositório que tem o objetivo de
documentar e administrar estes metadados e fornecer informações para reuso
destes dados, melhorando a qualidade e produtividade da empresa [16].
Metadados é a mais importante regra no data warehouse e, é usado em
vários aspectos:
• É direcionado para ajudar na localização analítica do conteúdo no data
warehouse para o DSS [13].
• É um guia para mapear os dados, como o dado é transformado do
ambiente operacional para o ambiente do data warehouse [13].
• É um guia para o algoritmo usado para a sumarização entre dado
corrente detalhado e o dado “lightly” sumarizado e o dado “highly” sumarizado,
etc [13].
3.1.17 Ferramentas CASE (Computer Aided Software Engineering)
São ferramentas individuais que auxiliam o desenvolvedor de software ou
gerente de projeto durante uma ou mais fases do desenvolvimento de software
(ou manutenção).
Uma combinação de ferramentas de software e metodologias de
desenvolvimento estruturado.
CASE pode auxiliar diretamente no projeto e suporte do desenvolvimento
de sistemas e também provê gerenciamento da informação, documentação e
controle de como desenvolver um projeto [11]. Alguns benefícios do CASE:
• Reduz custos, especialmente manutenção.
• Melhora a qualidade de software.
36
• Acelera o processo de desenvolvimento.
• Incrementa a produtividade.
• Tornam práticas as técnicas estruturadas.
3.1.18 SQL
A Structured Query Language é uma linguagem padrão de acesso aos
dados em bancos de dados relacionais independente de fornecedor. É dividida
em três partes: linguagem de definição de dados (DDL), linguagem de
manipulação de dados (DML) e linguagem de controle de dados (DCL). O
padrão internacional é estabelecido pela ISO (International Organization for
Standardization). A primeira normatização do SQL foi feita pela ANSI
(American National Standards Institute) em 1986. O SQL/86 foi um subconjunto
das implementações de SQL da IBM. A primeira norma da ISO saiu em 1989. A
norma internacional vigente é a versão de 1992 (ISO/IEC 9075:1992(E),
também conhecida como SQL92 ou SQL2). Ela se subdivide em 3 partes: Entry
Level, Intermediate Level e Full Level. A maioria dos sistemas gerenciadores
de banco de dados só implementa o Entry Level completamente. [28]
Já existem trabalhos para o SQL/3 e SQL/MM (Multimídia) que devem
implementar alguns conceitos da tecnologia de orientação à objeto. Um dos
órgãos de certificação de conformidade dos produtos com a norma é o NIST
(National Institute of Standards and Technology) que publica o FIPS (Federal
Information Processing Standards) que contém uma lista de sistemas
gerenciadores de banco de dados que tem conformidade com o padrão e em
qual plataforma [28].
Uma linguagem que habilita o usuário a interagir diretamente com o
sistema gerenciador de banco de dados para recuperar e/ou modificar dados
gerenciados pelo mesmo.
Características:
• É uma forma padrão de especificar conjuntos de dados.
• É uma forma de recuperar e manipular dados em um banco de dados
relacional.
37
• É utilizada para todas as funções de bancos de dados, incluindo
administração, criação de esquemas e recuperação.
• Pode ser utilizada na forma de “SQL embutida” em um programa de
aplicativo.
3.1.18.1 Stored Procedure
Stored Procedure (SP) é uma técnica de projeto que permite que um
conjunto de instruções SQL sejam compiladas e armazenadas no gerenciador
de banco de dados. São rotinas chamadas por aplicações cliente de modo
semelhante a RPC (Remote Procedure Call) e são armazenadas e executadas
no servidor. A stored procedure fornece uma significante melhora de
performance sobre o SQL utilizado diretamente na aplicação [28].
Uma stored procedure é uma coleção de comandos SQL armazenados no
banco de dados e que pode ser executada pelo nome. Características:
• Podem aceitar e retornar parâmetros e podem chamar outras
procedures.
• Processam mais rapidamente que os mesmos comandos SQL
executados interativamente.
• Reduzem o tráfego de dados na rede.
• A primeira vez que uma stored procedure é executada, um plano de
acesso é produzido no banco de dados.
• Garantem a consistência do banco de dados.
• Provêem um nível extra de segurança.
• Sugerem o desenvolvimento de uma aplicação modular.
• Reduz erro de operação.
38
3.1.19 Indexação
É o conceito de índices de acesso. São estruturas de indexação
destinadas a otimizar o acesso aos dados. É importante lembrar que em
bancos de dados relacionais, uma chave nem sempre tem um índice associado
a ela. Chaves são definições de nível lógico e os índices são estruturas físicas
para melhorar a performance no acesso aos dados. Há dois tipos de índices:
clustered index e nonclustered index. No clustered index os dados de uma
tabela são ordenados fisicamente pelo índice. Ele tem um nível a menos de
acesso em relação ao nonclustered. O índice nonclustered armazena os
valores das chaves e ponteiros para as páginas de dados onde as linhas estão
armazenadas [28].
Índice: Porção da estrutura de armazenamento de dados mantida para
prover acesso eficiente a um registro quando seu conteúdo chave é conhecido.
Índice Invertido: Uma estrutura de índice organizada por meio de uma
chave não única que aumenta a velocidade de pesquisa aos dados [13].
Características dos Índices:
• São utilizados para melhorar a performance. (se nenhum índice é
definido a uma tabela, a tabela inteira deverá ser pesquisada para satisfazer
uma condição de consulta) [6].
• Provêem um mecanismo para garantir a unicidade.
• Clustered: O dado é classificado na ordem do índice. Somente pode
existir um único índice clusterizado por tabela (geralmente é a chave primária).
Determina a ordem física do dado na tabela [6].
• NonClustered: O dado não é classificado na ordem da chave. Podem
existir vários índices associados à tabela (geralmente são as chaves
estrangeiras) [6].
3.1.20 XML
A eXtensible Markup Language tem como propósito principal a facilidade
de compartilhamento de informações através da Internet.
39
Estimulado pela insatisfação com os formatos existentes (padronizados
ou não), um grupo de empresas e organizações que se autodenominou World
Wide Web Consortium (W3C) começou a trabalhar em meados da década de
1990 em uma linguagem de marcação que combinasse a flexibilidade da
SGML com a simplicidade da HTML. O principio do projeto era criar uma
linguagem que pudesse ser lida por software, e integrar-se com as demais
linguagens [36]. Sua filosofia seria incorporada por vários princípios
importantes:
•
Separação do conteúdo da formatação.
•
Simplicidade
e
Legibilidade,
tanto
para
humanos
quanto
para
computadores.
•
Possibilidade de criação de tags sem limitação.
•
Criação de arquivos para validação de estrutura (Chamados DTDs).
•
Interligação de bancos de dados distintos.
•
Concentração na estrutura da informação, e não na sua aparência.
O XML é considerado um bom formato para a criação de documentos
com dados organizados de forma hierárquica, como se vê frequentemente em
documentos de texto formatados, imagens vetoriais ou bancos de dados[36].
Pela sua portabilidade, um banco de dados pode através de uma
aplicação escrever em um arquivo XML, e um outro banco distinto podem ler
então estes mesmos dados [36].
3.1.21 XMLA
XML for Analysis é o padrão da indústria para acesso aos dados em
sistemas analíticos, tais com OLAP e Data Mining. XMLA é baseado em outros
padrões da indústria tais como XML, SOAP e HTTP.[37]
Produtos que suportam XMLA são de duas categorias:
• XMLA Providers: esses produtos XMLA provêem serviços. Tipicamente
esses são servidores ou produtos meios. [37]
40
• XMLA Consumers: esses produtos podem conectar ao XMLA Providers
e consumir XMLA. Tipicamente esses são clientes. [37]
3.2 Aspectos na construção de um Data Warehouse
3.2.1. Planejamento
Um problema sério em projetos de data warehouse é um planejamento
defeituoso. O fato de todos concordarem que o projeto de um data warehouse
não se baseia em requisitos bem delimitados não significa que os projetistas
não devam planejar minuciosamente cada atividade do processo. E mais, tal
planejamento deve levar em consideração o fato de se tratar de um data
warehousing mais que um data warehouse: um processo sem fim para todos
os efeitos práticos. Deve ser considerado o longo prazo geralmente envolvido.
Não se estará projetando uma aplicação operacional, mas sim um repositório
de informações gerenciais [10].
A operação do negócio tende a uma estabilidade grande. Um aplicativo
voltado para gerir essas atividades tende, portanto, a ser bastante estável, pelo
menos quando comparado às necessidades de informação para a tomada de
decisão. É aqui que a competitividade do mercado se faz sentir. As perguntas
que os executivos precisam ver respondidas hoje para tomarem suas decisões
podem ser substancialmente as de amanhã. Desse modo, um planejamento
consistente deve prever liberações parciais de dados, em curtos intervalos, de
maneira que o usuário cedo possa interagir com o ambiente, facilitando essa
mudança inevitável de requisitos. Os planejadores devem identificar muito cedo
os alvos do projeto e seus benefícios [10].
Recomenda-se
que
o
data
warehouse
não
comece
muito
ambiciosamente. O primeiro projeto não deve levar mais que nove meses para
estar operacional e deve atingir basicamente as áreas de negócio mais
importantes e que tragam retorno direto e tangível. Com o tempo, ele será
refinado e aumentado em sua abrangência [32].
Um projeto de data warehouse deve ser conduzido com enfoque diferente
de um projeto de aplicações tradicional. A primeira etapa é identificar os
41
objetivos da organização, sob a óptica de seus executivos. A empresa pretende
crescer dentro de seu segmento de negócio? Ou pretende expandir seu
market-share? Depois, são identificados os processos de negócio diretamente
relacionados com esses objetivos. A seguir, definem-se as informações que
são necessárias para suportar esses processos de decisão. Onde essas
informações serão obtidas? As especificações técnicas aparecem no final,
quando então se desenham as alternativas tecnológicas para a sua total
implementação [33].
3.2.2 Necessidades das Empresas
No princípio havia sistemas simples de automação. Então vieram
sistemas de banco de dados e sistemas on-line. Em um tempo muito pequeno
o computador tinha achado seu modo de incorporar-se ao cotidiano das
empresas. De quase nenhum computador nos anos cinqüenta para milhões de
computadores de todo tipo e tamanho nos anos oitenta, o mundo da tecnologia
explodiu além de qualquer previsão a uma taxa de crescimento que parecia ser
impossível acreditar.
Os sistemas de computação iniciais foram projetados para processar as
transações diárias da corporação. Decisões imediatas eram o enfoque destes
sistemas pioneiros. Com o advento dos primeiros sistemas, veio um
subproduto de dados. Estes dados refletiam as atividades que estavam
acontecendo e cresceram à medida que o tempo passava e de como o negócio
era administrado [13].
Logo, a quantidade de trabalho exigiu manter as aplicações ao ponto em
que 95% do trabalho era dedicado à manutenção de programas. Ao mesmo
tempo em que o fardo de manutenção estava crescendo, os usuários finais
estavam ficando frustrados com a inabilidade dos sistemas de informação da
organização em responder às necessidades de informação. Caso após caso,
os usuários finais sabiam que os dados de que eles precisavam estavam
disponíveis, mas difíceis de serem obtidos. Ainda, em cada caso, o
departamento de sistemas de informação dava uma ou outra justificativa do
42
porquê dos dados não poderem ser acessados. Usuários finais sentiam-se
abandonados e frustrados [13].
Então, o data warehouse foi criado para transferir os dados do ambiente
transacional, armazenando-os e organizando-os de forma que o usuário final
poderia obter a informação pela qual tanto ansiava. Afinal, os dados estavam
disponíveis em uma base para que o usuário processasse suas próprias
consultas [13].
O data warehouse representou uma troca fundamental na concepção de
sistemas de informação e introduziu alguns conceitos novos importantes:
• Dados devem ser integrados através da empresa.
• Dados sumarizados tem um grande valor para a organização.
• Dados históricos são a chave para compreender os dados ao longo do
tempo.
• Metadados representam um papel muito importante na infra-estrutura
do data warehouse.
• Muito importante manter a precisão dos dados históricos com o passar
do tempo.
Além de resolver alguns problemas muito importantes para a corporação,
a criação do data warehouse aliviou o fardo do programador de aplicação em
tentar transformar o ambiente de sistemas legado em um sistema para a
tomada de decisão. As solicitações dos usuários e a manutenção das
aplicações, pela primeira vez, tornaram-se gerenciáveis [13].
O objetivo básico do data warehouse deve ser adicionar valor ao negócio.
À medida que as regras do negócio são incorporadas às aplicações, exige-se
rapidez cada vez maior nas respostas. O ambiente de negócios é
crescentemente dinâmico. Responder com rapidez ao como, quando e quanto
passa a ser decisivo para a empresa sobreviver e crescer nesse cenário [33].
As organizações hoje em dia estão enfrentando enormes pressões para
prever informações de melhor qualidade para tomada de decisões, em
formatos de fácil acesso e manipulação. Em poucas palavras, as empresas
43
precisam se tornar mais ágeis em sua capacidade de utilizar as enormes
quantidades de dados no esforço de proporcionar melhor suporte ao cliente.
Um data warehouse reconhece o valor estratégico do gerenciamento
intencional do bem corporativo de dados. A ênfase no data warehouse reflete o
reconhecimento de que a exploração de dados é o caminho para vantagem
competitiva, novas oportunidades de negócios, e melhoria no serviço ao
cliente. Ela também reconhece que os sistemas tradicionais de gerenciamento
de base de dados estão geralmente assoberbados pelo enorme volume de
dados que lhes são confiados. Como resultado, os sistemas de extração de
informações que trabalham com a totalidade das bases de dados geralmente
funcionam mal [35].
O data warehouse e a arquitetura associada a ele providencia o objetivo
para lutar contra os mais variados desafios confrontados nos sistemas de
informações gerenciais de hoje [13].
Em outras palavras, o data warehouse permite o gerenciamento para
considerar resultados no contexto. Sem a armação do data warehouse e sua
arquitetura associada é uma tarefa quase impossível formar sentido para os
diversos resultados obtidos [13].
Os sistemas de informações (IS) gerenciáveis encontram a noção da
arquitetura indispensável no movimento da corporação dentro de um mundo de
processamento de informação efetiva. Em particular, o IS gerenciável usa a
arquitetura como um guia para o gerenciamento, como o seguinte:
• uso da armazenagem e aquisição.
• tecnologia adequada com processamento necessário.
• gerenciamento de orçamento.
• mudança de tecnologia e plataforma.
• informações derivadas do ambiente de produção.
• determinação das responsabilidades organizacionais.
• desenvolvimento de relatórios da arquitetura.
• definição da interface entre as diferentes unidades organizacionais.
44
• gerenciamento de gráficos organizacionais como a responsabilidade no
processamento da informação concernida.
• gerenciamento do impacto na arquitetura no desenvolvimento do
processo.
Afinal, é antigo o enfoque por trás da idéias do depósito, galpão ou
armazém de dados extraídos dos muitos sistemas de produção – geralmente
“legacy systems” – das companhias: transformar o dado cru em informação,
para obtenção de vantagem competitiva. [3]
Data warehouse é entendido como uma “enabling technology”; uma
tecnologia-meio, que favorece a tomada de decisões ao separar sistemas de
informações para decisão dos dados de produção. Essa divisão dos dados
permite, dizem os entusiastas, melhor alocação e administração de recursos;
enquanto que a proliferação de ferramentas sofisticadas de acesso possibilita
combinar várias fontes de dados de estruturas distintas e concretiza, assim,
antigas promessas de gerência participativa e menor concentração de poder
decisório [3].
3.2.3 Tipos de Sistemas de Informações na Empresa
Segundo Laudon e Laudon (1998), os sistemas de informações são
classificados em quatro tipos, dependendo do tipo de problema organizacional
que solucionam, conforme a figura abaixo.
Figura 9: Tipos de Sistemas de Informação (Laudon e Laudon 1998)
45
Pirâmide com três níveis: [38]
• 1º Nível é o Nível Estratégico: ESS – Sistema de Suporte aos
Executivos: ajuda a gerencia sênior no planejamento das atividades de longo
prazo.
• 2º Nível é o Nível Tático: DSS – Sistema de Suporte a Decisão e MIS –
Sistemas de Administração das Informações: suporta o monitoramento,
controle, tomadas de decisão e avaliação das atividades da gerência
intermediária.
• 3º Nível é o Nível de Conhecimento: KWS – Sistema de Controle de
Conhecimento e OAS – Sistema de Automação de Escritório: permite aos
funcionários de escritórios a criação de produtos, racionalização de serviços e
acompanhamento de fluxo de documentos na organização.
• 4º Nível é o Nível Operacional: TPS – Sistemas de processamentos
Transacionais: responde questões rotineiras e acompanha o fluxo das
transações através da organização.
3.2.4 Motivação da Empresa no Mercado
O verdadeiro impulso para a utilização da tecnologia de data warehouse
começou quando as pessoas perceberam que as informações disponíveis no
data warehouse poderiam ser utilizadas para a obtenção de vantagem
competitiva. Esta informação apoiou a habilidade da corporação em atrair e
manter parte do mercado, reduzir despesas e aumentar as vendas. Estes
atributos elevaram o data warehouse para a vanguarda de sistemas de
informação, tornando-o promissor tanto para o profissional técnico da
informação quanto para o profissional da área de negócios [13].
Estamos vivendo o início da era da informação. Nela os grandes desafios
são as integrações dos processos operacionais entre as empresas e o
gerenciamento do negócio através da análise dos fatos para identificação de
oportunidades [26].
46
3.2.5 Necessidades e Benefícios para o Usuário
A necessidade principal do usuário é a transformação dos dados em
informações.
Embora o seu uso ainda seja incipiente, alguns resultados positivos
parecem demonstrar que realmente o data warehouse produz um alto retorno
sobre o investimento. A grande vantagem de um data warehouse é permitir a
tomada de decisões baseadas em fatos. Na verdade, ele busca disponibilizar à
organização o grande volume de dados que foram e estão sendo armazenados
em bases de dados operacionais, espalhadas por toda a empresa [32].
O principal resultado de um data warehouse é, indiscutivelmente, a
facilidade dos gestores da empresa poderem tomar decisões rápidas,
baseados em informações mais consistentes [32].
Levantamentos realizados junto a usuários em âmbito mundial e local
atestam o sucesso dos projetos já implantados, nos quais os primeiros
resultados apontaram para: aumento do tempo dos tomadores de decisão
(decision makers) para a análise e tomada de decisão; eliminação de tarefas
operacionais como pesquisa e identificação dos dados necessários ao
processo
decisório;
melhor
confiabilidade
das
informações
devido
à
implantação de um elo integrador dos dados transacionais; racionalização do
fluxo de informações da empresa; padronização dos conceitos de negócio e
democratização das informações sobre o desempenho do negócio [24].
3.2.6 Perfil do Usuário na Empresa que Utiliza o Data Warehouse
O usuário, o formulador de perguntas, é o ponto mais crítico nos projetos
de data warehouse. Idealmente, os usuários devem ser membros da equipe de
projeto, desde o seu nascimento [10].
Os usuários finais do data warehouse tem alguns papéis específicos a
cumprir. Estes geralmente dividem-se em duas categorias: Suporte aos Papéis
e Tipos de Usuário [13].
Suporte aos Papéis:
47
Cada interação do data warehouse deve ter um “Patrocinador Executivo”
da área de negócios da comunidade usuária que serão os primeiros
beneficiários da funcionalidade destas interações. O Patrocinador Executivo é
especialmente importante para o data warehouse. Ele define o escopo e
requisitos do negócio e analisa as necessidades de informação da organização
para a tomada de decisão. Existem, também, dois importantes papéis
adicionais na comunidade de usuários finais: Especialista do Assunto e Técnico
de Apoio ao Usuário [13].
O Especialista do Assunto é quem facilita a comunicação entre os
usuários finais e a equipe técnica do data warehouse. Provê as informações
para definir o escopo de uma interação do data warehouse. Participa no projeto
e revisão da aquisição e capacidade de acesso aos dados. Assiste o
treinamento de outros usuários em seus grupos funcionais. Atua como suporte
a outros usuários em suas áreas [13].
O Técnico de Apoio ao Usuário provê apoio técnico global para os
usuários do seu departamento, grupo, linha de negócio, etc. Ele entende o
ambiente técnico de uma área específica do data warehouse, presta apoio
como administrador de banco de dados local e apoio técnico aos usuários
locais [13].
Tipos de Usuário:
São categorizados como: Usuários de Aplicações Pré-definidas, Usuários
com Acesso Limitado e Usuários com Acesso Ilimitado [13].
Os Usuários de Aplicações Pré-definidas não possuem um nível alto de
experiência técnica, mas estão, tipicamente, em um nível relativamente alto
dentro da estrutura de administração de uma organização. Eles também são,
freqüentemente, assistentes administrativos. Acessam o data warehouse
através de consultas pré-definidas que atendem aos seus requisitos de negócio
[13].
Os Usuários com Acesso Limitado são a maioria dos usuários analíticos.
Requerem caminhos pré-definidos de acesso ao data warehouse como, por
exemplo, uma ferramenta OLAP para facilitar o acesso e tem conhecimento em
48
drill-up/down. Tipicamente oferecem apoio aos pedidos de informação da
administração superior [13].
Os Usuários com Acesso Ilimitado são os “exploradores”, altamente
habilitados tecnicamente no acesso aos dados, precisam de ferramentas
poderosas,
procedurais
e
não
ferramentas
simples
e
limitadas.
Freqüentemente desenvolvem aplicações para uso por outros tipos de usuários
e, tipicamente, possui um número pequeno de usuários. Oferecem apoio às
exigências organizacionais para relatórios complexos [13].
Pode parecer desnecessário identificar os papéis chaves que os usuários
executam no desenvolvimento e gerenciamento de um data warehouse.
Entretanto, muitas organizações não têm reconhecido a importância que os
usuários exercem durante esse desenvolvimento e, conseqüentemente,
perderam a visão da importância em conduzir a evolução do data warehouse
através das necessidades de negócio do usuário. O resultado é normalmente
um enfoque tecnológico ao data warehouse e não um enfoque do usuário,
resultando em um ambiente de informação que não atinge as necessidades da
organização para a análise e suporte à decisão [13].
De patrocinador da funcionalidade de negócio para um executivo que
precisa monitorar as tendências em uma métrica importante do negócio; de
perito de assunto para um usuário técnico altamente qualificado para a
obtenção ocasional da informação, usuários têm papéis distintos e importantes
a executar na evolução do data warehouse de forma que podem continuar
satisfazendo suas exigências de informação sobre o negócio. Os usuários
também tem uma responsabilidade significativa como “bons cidadãos
corporativos” para trabalhar com a equipe do data warehouse para assegurarse de que o data warehouse continuará agregando valor à organização através
de uma importante ferramenta tática e estratégica de análise e acesso à
informação [13].
Um ingrediente essencial para o sucesso do ambiente do data warehouse
é o fator humano. O melhor projeto e a melhor arquitetura no mundo não são
bem usadas se não existirem pessoas capazes e preparadas para colocarem
os planos em ação.
49
O ambiente do data warehouse é administrado por uma unidade
organizacional chamada grupo de arquitetura de dados. O grupo de arquitetura
de dados algumas vezes faz parte da administração de dados. [13].
Em outros casos, o grupo de arquitetura de dados permanece sozinho.
Ele está próximo do grupo de sistemas ou do grupo de aplicações [13].
3.2.7 Análise do Ambiente Legado
Situada entre o ambiente operacional, o data warehouse e o depósito de
dados operacionais está a interface de integração e transformação dos dados.
Esta interface é o local onde o dados não integrados do ambiente operacional
são integrados e enviados ao data warehouse [13].
As tecnologias de sistemas gerenciadores de bancos de dados que
normalmente alojam as aplicações do legado mais antigas, usualmente
requerem que os dados sejam acessados na forma de um registro por vez.
Esta abordagem requer lógica de programa que é familiarizada com a maneira
com que os dados são armazenados. Em muitos casos, o dados provenientes
de muitas áreas de assunto diferentes são amarrados e controlados pelas
aplicações. A execução da integração e transformação dos dados torna-se um
problema complexo decorrente do grande volume de dados armazenados no
ambiente de aplicações do legado. A integração e transformação dos dados a
serem carregados no data warehouse são um dos aspectos mais importantes e
devem ser cuidadosamente gerenciados [13].
Como todo o data warehouse depende dos dados disponíveis nas bases
de dados operacionais da empresa, o primeiro passo para sua construção é o
mapeamento dessas bases, sua limpeza e sincronização com as demais
camadas. Para isso, é extremamente necessário conciliar em um único
ambiente a administração de todas as bases de dados operacionais que são
fonte de alimentação para o data warehouse com a administração do data
warehouse em si [24].
Criar um data warehouse não é uma simples questão de escolha de
banco de dados ou ferramentas, mas envolve planejamento e modelagem
(aspectos que garantem a qualidade dos dados, fator crítico para o sucesso do
50
projeto), escolha de ferramentas e atualização e refinamento contínuos. É, de
fato, uma arquitetura completa e que se compõe dos seguintes elementos
principais: bases de dados operacionais, que são as fontes primárias das
informações; processos de extração e conversão de dados; bancos de dados
específicos para data warehouse; recursos de administração e ferramentas de
inteligência de negócios, que facilitam o acesso, manipulação e análise dos
dados contidos no data warehouse [25].
Um armazém de dados é composto de três áreas funcionais distintas,
cada uma das quais deve ser customizada para satisfazer as necessidades do
negócio. O primeiro componente é a aquisição de dados, podendo ser de
sistemas legados ou de outras fontes quaisquer. Lá o dado é identificado,
copiado, formatado e preparado para ser carregado no armazém. O segundo
componente do armazém é o espaço de armazenamento e o terceiro é a área
de acesso aos dados [27].
A busca pelas informações espalhadas pelas diversas aplicações e
plataformas tecnológicas, pode ser um problema muito sério. Mesmo que as
informações que vão preencher o data warehouse venham apenas de sistemas
legados baseados em mainframes, o que nem sempre ocorre, a diversidade de
tecnologias envolvidas é grande. Uma recente pesquisa mostrou que apenas
25% das informações desses sistemas estão em bancos de dados relacionais,
como o DB2. A grande maioria está espalhada por bancos de dados não
relacionais, arquivos VSAM, etc [32].
Um armazém de dados se propõe a compatibilizar um número grande de
sistemas desintegrados oriundos do legado a uma coleção igualmente diversa
de tipos de estações de trabalho de usuário final. Os ambientes existentes
normalmente se compõem de um conjunto de hardware sortido, software e
sistemas operacionais incompatíveis e com características únicas a cada
organização [27].
A maioria dos “armazéns de armazenamento” está sendo administrada
por bancos de dados relacionais sob plataformas Unix. De acordo com o Meta
Group Inc., Oracle, Sybase Inc., IBM Corp. e Informix controlam 65% do
mercado de “armazéns de armazenamento”; os vendedores de outros bancos
51
de dados relacionais e bancos de dados especializados são secundários nesse
contexto [27].
Uma questão relevante será como integrar as diversas fontes de dados
legadas ou não, arquivos VSAM, DB2, CA-IDMS, CA-DATACOM, OpenIngres,
Oracle, Informix, Sybase e mais uma infinidade de outras fontes. A resposta:
utilizando gateways que tenham as características de transparência e
confiabilidade para sustentar o ambiente de data warehouse [20].
O assunto mais óbvio relativo à interface de integração e transformação
refere-se às tecnologias utilizadas pelos sistemas transacionais encontradas no
ambiente legado (às vezes chamado de ambiente fonte) como, por exemplo, as
tecnologias que são, na maioria dos casos antigas, orientadas à transações e
complexas: IMS (Information Management System) – um sistema gerenciador
de banco de dados hierárquico desenvolvido pela IBM para ambientes
mainframe, VSAM (Virtual Storage Access Method) – arquivo indexado
desenvolvido pela IBM para ambientes mainframe, IDMS, Adabas, Oracle,
Sybase, Informix, Arquivos Seqüenciais, etc [13].
3.2.8 Equipe de Desenvolvedores
O crescimento do data warehouse criou a necessidade de disciplinar o
gerenciamento do mesmo que é o papel do administrador do data warehouse
(DWA). O DWA é parte administrador de dados, parte administrador de banco
de dados, deve posicionar-se um pouco como usuário final, um pouco
programador de sistemas e muito de programador e projetista de aplicação
[13].
O administrador do data warehouse é um disciplinador organizacional que
apareceu com o advento do data warehouse e dos sistemas de apoio à
decisão. Ele é o principal responsável pelo sucesso contínuo do armazém de
dados [13].
O administrador do data warehouse deve conhecer as várias habilidades
abaixo descritas:
• Projetista da Base de Dados: projeta e constrói o data warehouse.
52
• Modelador de Dados: integra um novo data warehouse em um já
existente.
• Desenvolvedor: que mantém, nos programas, novas integrações e
transformações de dados.
• Político: solicita e negocia os recursos necessários para a construção
do data warehouse.
• Programador de Sistemas: capacidade de planejamento e refinamento
do data warehouse.
• Usuário final: deve entender as necessidades das áreas de negócio da
empresa como, por exemplo, financeira, gerência de vendas, atuarial,
engenharia, etc.
Em alguns casos, o administrador do data warehouse não somente deve
possuir as habilidades acima, mas estar apto a executá-las. Em suma, o
administrador do data warehouse é responsável por um ambiente inteiro de
suporte à decisão que é o fator crucial para o sucesso da corporação [13].
O Administrador de Data warehouse (DWA) é o responsável pelo data
warehouse, envolvendo obter, agendar e coordenar o trabalho entre os
recursos humanos, preparando relatórios de situação, orientando revisões de
design, garantindo que membros de equipes de trabalho e usuários finais estão
sendo efetivamente treinados, e gerenciando outras atividades relacionadas ao
Data warehouse como especificado pela gerência da organização [13].
O Administrador de Banco de Dados é essencial na organização da
equipe de data warehouse, em número suficiente e dedicados em tempo
integral. As diferenças entre os sistemas de informação e operacional da
empresa devem ser acompanhadas pelo Administrador de Banco de Dados
[13].
O Gerenciador de Metadados deve assegurar que os metadados no
Subdiretório de Informações está sincronizado com a produção de recursos,
regras de negócio na obtenção de dados, e regras de negócio norteando o
acesso dos dados, bem como fontes de conceito de metadados como
ferramentas CASE e novas aplicações em desenvolvimento [13].
53
3.2.9 Aspectos da Implementação Física (ROLAP/MOLAP)
Quanto à localização dos dados a serem utilizados na análise, atualmente
existem duas abordagens:
• Um banco de dados multidimensional especializado.
• Um data warehouse implementado com a tecnologia de banco de dados
relacional, mas otimizado para a tarefa de análise: Nesse caso, os dados são
modelados utilizando um esquema projetado para balancear desempenho e
volume de dados. Normalmente é utilizada uma representação desnormalizada
da conhecida por esquema estrela.
Sistemas OLAP que implementam a primeira abordagem são chamados
de MOLAP (Multidimensional OLAP) e aqueles que implementam a segunda
são chamados de ROLAP (Relacional OLAP).
Em um banco de dados MOLAP, os dados são mantidos em arranjos e
indexados de maneira a prover um ótimo desempenho no acesso a qualquer
elemento. O indexamento, a antecipação da maneira como os dados serão
acessados e o alto grau de agregação dos dados fazem com que sistemas
MOLAP tenham um excelente desempenho. Além de serem rápidos, outra
grande vantagem desses sistemas é o rico e complexo conjunto de funções de
análise que oferecem [7].
Existem algumas limitações nos sistemas MOLAP. Bancos de dados
multidimensionais são sistemas proprietários que não seguem padrões
(linguagem, Application Program Interface, etc.) estabelecidos pela indústria de
banco de dados. Isso se torna uma desvantagem para tais sistemas, uma vez
que a arquitetura não é aberta. A utilização das estruturas dimensionais
adotadas também traz algumas desvantagens. Mudanças do modelo
dimensional requerem uma reorganização do banco de dados, e a estrutura de
cubos não suporta a criação ad hoc de visões multidimensionais. Além dessa
falta de flexibilidade, sistemas MOLAP enfrentam problemas quanto à
escalabilidade porque um dos recursos para garantir o excelente desempenho
é manter os índices dos arranjos na memória e isso acaba limitando banco de
dados multidimensionais a 20 ou 30 gigabytes de dados, tornando-se, dessa
54
maneira, mais apropriados para data marts ou organizações com pequenos
data warehouses [7].
Sistemas
ROLAP
fornecem
análise
multidimensional
de
dados
armazenados em uma base de dados relacional.
A principal vantagem de se adotar uma solução ROLAP reside na
utilização de uma tecnologia estabelecida, de arquitetura aberta e padronizada
como é a relacional, beneficiando-se da diversidade de plataformas,
escalabilidade e paralelismo de hardware [7].
Quanto às limitações, podemos citar o pobre conjunto de funções para
análise, a inadequação do esquema estrela para atualização dos dados e as
soluções proprietárias para metadados que acaba por anular muitas das
vantagens da tecnologia relacional [7].
MOLAP ou ROLAP? Qual escolher? Atualmente existe um grande debate
sobre essa questão e, se possível, esse debate deve ser deixado para os
fornecedores. Para quem utilizará a tecnologia, o mais importante é entender
os negócios da empresa para então decidir pela solução que melhor atende o
volume de dados e as necessidades de análise da empresa.
Provavelmente esse debate não terá um vencedor. Já se percebe que
existe uma convergência dessas duas tecnologias. Fornecedores MOLAP têm
adicionado
funcionalidade
ROLAP
nos
seus
produtos
e,
igualmente,
fornecedores ROLAP têm enriquecido a funcionalidade e desempenho de seus
servidores.
3.2.10 Performance
A duração de tempo desde o momento em que um pedido é emitido até o
primeiro resultado recebido.
A maioria das consultas dos usuários precisa ser processada rápida e
eficientemente. O administrador do data warehouse é responsável pela
performance de carga de dados, criação de índices e manutenção de
metadados, itens importantes ao analisar a performance.
55
A maioria dos projetos de data warehouse reside em um sistema
gerenciador de banco de dados separado do ambiente OLTP, com um
processador dedicado, disco e memória. Esta separação é o melhor ambiente
porque, certamente, alivia o processamento e proporciona, ao administrador do
data warehouse, liberdade para projetar as bases de dados e suporta uma
estrutura de acesso específica para um ambiente de data warehouse onde as
consultas são variadas [13].
56
4. APLICAÇÃO
Esta seção descreve a modelagem e implementação de um Sistema de
Informações Gerenciais sobre Projetos de Pesquisa acadêmicos no âmbito da
Universidade Federal de Campina Grande.
Utilizamos o Mondrian, um servidor OLAP/WOLAP open source feito em
Java [48]. Além disso, para testarmos o modelo dimensional que criamos,
utilizamos uma pequena aplicação cliente que vem junto com o Mondrian. A
seguir detalhamos a arquitetura do Mondrian e as funcionalidades da aplicação
cliente.
O Mondrian consiste de quatro camadas. Numa visão top-down temos: a
camada de apresentação, a camada dimensional, a camada estrela, e a
camada de armazenamento.
A camada de apresentação determina o que o usuário final vê na tela do
seu computador, e como ele pode interagir para fazer perguntas à aplicação.
Há muitos modos para apresentar datasets multidimensional, inclusive tabelas
pivot, gráficos de barra, linha ou pizza, e ferramentas avançadas de
visualização como mapas interativos e gráficos dinâmicos. Estes poderiam ser
escritos em Swing ou JSP, gráficos transformados em JPEG ou GIF, ou
transmitiu a uma aplicação remota por XML. [48]
A segunda camada é a camada dimensional. A camada dimensional
realiza o parser, a validação e a execução das consultas em MDX. Uma
consulta é avaliada em múltiplas fases. Os eixos são computados primeiro, em
seguida os valores das células de cada eixo. Por questões de eficiência, a
camada dimensional envia cell-requests em lotes para a camada estrela. Um
transformador de consultas permite à aplicação manipular consultas existentes,
em vez de construir uma declaração MDX para cada request. E o metadata
descreve o modelo dimensional, e como ele é mapeado para o modelo
relational. [48]
A terceira camada é a camada estrela, que é responsável por manter um
cache agregado. Aqui uma agregação é um conjunto de valores das medidas
57
('células’) em memória, separadas por colunas das dimensões do cubo. A
camada dimensional envia requests para conjuntos de células. Se as células
pedidas não estão em cache, ou se são deriváveis através de operações rollup, a camada estrela envia um pedido à camada de armazenamento.
A camada de armazenamento é um RDBMS (Relational Database
Management System). É responsável por prover dados agregados das células,
e membros das tabelas dimensionais. [48]
Todas estas quatro camadas podem existir na mesma máquina, ou então
podem ser distribuídas entre máquinas. As camadas 2 e 3, que incluem o
servidor Mondrian, devem estar na mesma máquina. A camada de
armazenamento pode estar em outra máquina, acessada por conexão de
JDBC remota. Em um sistema multi-usuário, a camada de apresentação
existiria na máquina de cada usuário final (menos no caso de páginas de JSP
geradas no servidor). [48]
Na nossa aplicação, por questões de simplicidade, colocamos todas as
quatro camadas do Mondrian em uma máquina. O gerenciador de banco de
dados escolhido foi o MySQL 5, que possui integração com XML.
Uma exemplo de aplicação cliente para o servidor Mondrian é a
ferramenta JPivot, que baseado em JSP (Java Server Pages). No JPivot o
usuário pode realizar operações OLAP típicas, como drill-down, roll-up, slice, e
dice. A comunicação com o servidor dar-se-á por XMLA. [47]
Resumindo, utilizamos as seguintes tecnologias/ferramentas/modelos no
nosso projeto:
• Ambiente de Banco de Dados Gerenciais: Data Warehouse;
• Servidor OLAP: Mondrian. [48]
• Modelo Multidimensional: esquema estrela (star scheme);
• Método OLAP: ROLAP, utilizando o MySQL 5;
• Interface OLAP: WOLAP, através da ferramenta web-client que vem
junto com o Mondrian;
• Padrão de acesso OLAP: XMLA;
• Linguagem de Recuperação de Informação: MDX;
58
A seguir temos uma figura que mostra toda a arquitetura do servidor
Mondrian, destacando suas camadas e componentes.
Figura 10: Arquitetura do servidor OLAP utilizada.
59
O controle de acesso ao banco de dados dimensional no servidor
Mondrian é definido em um arquivo XML. Os elementos que definem as regras
de acesso são os seguintes
•
<SchemaGrant> - define o acesso padrão a objetos em um esquema. O
atributo de acesso pode ser "all" ou "none"; este acesso pode ser
sobrescrito para usuários específicos.
•
Um <CubeGrant> define o acesso a um cubo particular. Como para
<SchemaGrant>, o atributo de acesso pode ser "all" ou "none", e pode
ser sobrescrito para sub-objetos específicos no cubo.
•
Um <HierarchyGrant> define acesso a uma hierarquia. O atributo de
acesso pode ser "all", significando que todos os membros são visíveis;
"none", significando que a existência da hierarquia é escondida do
usuário; e "custom". Com acesso customizado, pode usar você definir
regras de acesso topLevel e bottomLevel, limitando o usuário de realizar
as operações roll-up e drill-down no cubo.
4.1 Modelagem Conceitual
4.1.1 Informação
O diagrama de objetos modela as instâncias das classes contidas no
diagrama de classes, isto é, o diagrama de objetos mostra um conjunto de
objetos e seus relacionamentos no tempo. Estes diagramas são importantes
para construir os aspectos estáticos do sistema. Normalmente, são compostos
por: objetos e vínculos.
Na figura 10, temos o diagrama de objetos para a classe projeto na
modelagem tradicional.
60
Figura 11: Diagrama de Objeto
4.1.2 Modelo
Os diagramas de Classe mostram as diferentes classes que fazem um
sistema e como elas se relacionam. Os Diagramas de Classe são chamados
diagramas “estáticos” porque mostram as classes, com seus métodos e
atributos bem como os relacionamentos estáticos entre elas: quais classes
“conhecem” quais classes ou quais classes “são partes” de outras classes, mas
não mostram a troca de mensagens entre elas.
Na figura 11, temos o diagrama de classe para o nosso projeto.
61
Figura 12: Diagrama de Classe
62
4.1.3 Meta-Modelo
Os meta-modelos da modelagem conceitual do nosso projeto equivalem
as linguagens UML e OCL, que são explicados a seguir.
4.1.3.1 UML
A Linguagem de Modelagem Unificada (Unified Modelling Language UML) é uma linguagem de diagramação ou notação para especificar, visualizar
e documentar modelos de sistemas de software Orientados à Objeto. A UML
não é um método de desenvolvimento, o que significa que ela não diz para
você o que fazer primeiro e em seguida ou como desenhar seu sistema, mas
ele lhe auxilia a visualizar seu desenho e a comunicação entre objetos. A UML
é controlada pelo Grupo de Gerenciamento de Objeto (Object Management
Group - OMG) [40].
A UML é voltada para o desenho de software Orientado à Objeto e tem
um uso limitado para outros paradigmas de programação. Ela é composta por
muitos elementos de modelo que representam as diferentes partes de um
sistema de software. Os elementos UML são usados para criar diagramas, que
representam uma determinada parte, ou um ponto de vista do sistema. A seguir
temos a descrição dos principais diagramas UML [40]:
Diagrama de Caso de Uso - mostra atores (pessoas ou outros usuários do
sistema), casos de uso (os cenários onde eles usam o sistema), e seus
relacionamentos.
Diagrama de Classe - mostra classes e os relacionamentos entre elas.
Diagrama de Seqüência - mostra objetos e uma seqüência das chamadas
do método feitas para outros objetos
Diagrama de Objeto - modela as instâncias das classes contidas no
diagrama de classes.
Diagrama de Colaboração - mostra objetos e seus relacionamentos,
colocando ênfase nos objetos que participam na troca de mensagens.
63
Diagrama de Estado - mostra estados, mudanças de estado e eventos
num objeto ou uma parte do sistema.
Diagrama de Atividade - mostra atividades e as mudanças de uma
atividade para outra com os eventos ocorridos em alguma parte do sistema.
Diagrama de Componente - mostra os componentes de programação de
alto nível.
Diagrama de Distribuição - mostra as instâncias dos componentes e seus
relacionamentos.
4.1.3.2 OCL
A primeira versão da UML foi submetida ao Object Management Group
(OMG), organizador do processo de padronização dos modelos e linguagens. A
revisão desse modelo mostrou uma grande deficiência na clareza e
consistência das definições da UML. Em particular, uma dificuldade encontrada
foi que a semânitica da UML poderia ser interpretada em formas ambígüas. O
problema foi minimizado com a elaboração de uma nova versão da Unified
Modeling Language (UML) a qual foi publicada em 1997. O mais importante
incremento nesta versão foi a criação da Object Constraint Language (OCL).
[41]
A OCL é uma linguagem de expressões para especificar restrições sobre
modelos orientados a objetos ou outros artefatos da linguagem UML. É uma
linguagem precisa, textual e formal. Essa formalidade garante a não existência
de interpretações ambígüas para as mesmas restrições, fato que ocorria antes
da sua criação. Uma das suas principais características é que seu uso não
exige um forte conhecimento matemático para ser utilizada corretamente, como
ocorre nos modelos Z e VDM. [41]
Na linguagem OCL toda expressão é declarativa no sentido de que
expressa “o quê” a restrição representa no sistema e não “como” essa restrição
é implementada. A avaliação de uma expressão sempre resulta em um valor
booleano e nunca muda o estado do sistema no modelo [41].
64
As expressões OCL são utilizadas para definir condições invariantes nas
classes representadas em um modelo e também são utilizadas para especificar
as pré e pós-condições em operações aplicadas a classes deste modelo. Elas
também podem ser utilizadas para fazer consultas a um modelo de classes da
UML. Essas consultas podem ser úteis para validar modelos de classes na fase
de projeto. A avaliação dessa expressão não devolve um valor booleano, e sim
valores de um tipo específico da OCL [41].
4.1.3.2.1 Regras OCL
Regra 1: a área de uma sala deve ser maior que 2m2;
Context Sala inv:
self.areaSala > 2;
Regra 2: Um laboratório deve estar sendo usado por pelo menos um projeto.
Context Laboratorio inv:
self.numProjetos > 0;
Regra 3: Cada projeto sempre deve ter um único coordenador. Caso o
coordenador saia, outra pessoa deve entrar no lugar.
Context Projeto inv:
if self.temCoordenador then
self.coordenador->count = 1;
else then
self.coordenador->includes(pessoa);
65
Regra 4: Todo professor que for coordenador de um projeto deve participar
deste projeto.
Context Professor inv:
self.coordenaProjeto->iterator(i; i: Projeto;
if not i.participaProjeto->including(self) then
i.participaProjeto->includes(self);
else;
Regra 5: Um laboratório deve possuir uma única sala.
Context Laboratorio inv:
self.sala -> count = 1
4.1.4 Meta-meta Modelo
O Meta-meta-Modelo utilizado para modelar o modelo conceitual deste
projeto foi o MOF (Meta-Object Facility), um padrão sugerido pela OMG (Object
Management Group) que define a estratégia de meta-meta-modelagem do
OMG, baseada na orientação a objetos. O MOF é uma meta-meta-modelo
para nível de meta-modelos UML (UnifiedModeling Language) que está
estruturado em torno de uma hierarquia de múltiplas camadas. O modelo MOF
tem uma sintaxe abstrata definida por ele e emprega diagramas de classes
UML em sua sintaxe concreta. Para isso, o MOF e UML possuem um núcleo
comum alinhado de forma que qualquer meta-modelo oriundo do MOF é
passível de representação através de ferramentas CASE que sigam o padrão
UML. No MOF a linguagem de meta-modelagem é independente da tecnologia
de dados, ou seja, podem ser usada com XML ou modelo relacional, por
exemplo. Ele também é independente da linguagem de programação e outras
plataformas de tecnologia.
4.1.4.1 Data warehouse e MOF
No data warehouse a extração e os processos de integração dependem
do administrador de banco de dados que cria um mapeamento de esquemas
de um banco de dados tradicional para o esquema de um data warehouse [39].
66
A meta-informação para vários bancos de dados é representada usando
tecnologia MOF, logo é possível criar ferramentas sofisticadas para ajudar o
administrador de banco de dados neste processo [39].
O Meta dados é descrito freqüentemente como o “coração e alma” do
data warehouse. O MOF é usado para automatizar a administração dos meta
dados no data warehouse. Atualmente, repositórios de meta dados que
administram data warehouse usam meta dados estáticos que usam grupos de
arquivos baseados em meta dados que se comunicam [39].
A interface do MOF e o modelo do MOF podem ser usados para definir
meta-modelos específicos para banco de dados tradicionais e para o data
warehouse. A integração entre estes modelos é feita em tempo real entre o
ambiente de desenvolvimento do data warehouse (que possuem o modelo de
dados) e os modelos UML (que descrevem os modelos incorporados dos
dados e as bases de dados operacionais) este é um uso típico do MOF [39].
4.2 Modelagem Interna
Esta seção mostra os aspectos da modelagem interna, segundo a
arquitetura ANSI/SPARC, aplicada ao nosso projeto.
4.2.1 Diagrama Entidade Relacionamento
O diagrama entidade relacionamento é um modelo diagramático que
descreve o modelo de dados de um sistema com alto nível de abstração. A sua
principal aplicação é para visualizar o relacionamento entre tabelas de uma
banco de dados, no qual as relações são construídas através da associação de
um ou mais atributos destas tabelas.
A Figura 12 mostra o diagrama entidade relacionamento do banco de
dados tradicional do nosso projeto.
67
Figura 13: Modelo Entidade Relacionamento
4.2.2 Relacionamento entre Entidades
Existem quatro tipos de multiplicidade no relacionamento entre duas
entidades:1-1, 1-N, N-1 e N-N. A figura 13 mostra o relacionamento entre a
entidade bloco e a entidade sala do nosso projeto.
68
Figura 14: Relacionamento entre Entidades
4.2.3 Tabela do Banco de Dados Relacional
Um Banco de Dados Relacional é um conceito abstrato que define
maneiras de armazenar, manipular e recuperar dados estruturados unicamente
na forma de tabelas, construindo assim um banco de dados.
4.2.4 Tabelas (ou relações, ou entidades)
Todos os dados de um banco de dados relacional (BDR) são
armazenados em tabelas. Uma tabela é uma simples estrutura de linhas e
colunas. Em uma tabela, cada linha contém um mesmo conjunto de colunas, e
estas linhas devem seguir a ordem que foi especificada pelo projetista do BDR.
Em um banco de dados podem existir uma ou centenas de tabelas, sendo que
o limite pode ser imposto tanto pela ferramenta de software utilizada, quanto
pelos recursos de hardware disponíveis no equipamento.
As tabelas associam-se entre si através de regras de relacionamentos,
estas regras consistem em associar um atributo de uma tabela com um
conjunto de registros de outra tabela. A Figura 14 mostra uma tabela do banco
de dados relacional do nosso projeto que foi criada utilizando o programa
MySQL.
69
Figura 15: Tabela no Banco de Dados Relacional
4.3 Modelagem Externa
Após feita a modelagem conceitual através de UML e seguindo a
arquitetura do data warehouse, o próximo passo é realizar a modelagem
dimensional. Escolhemos utilizar o esquema estrela como modelo conceitual
do banco de dados dimensional. A seguir será descrita as etapas para
construção desse esquema a partir do esquema relacional definido na seção
4.2, e a posterior construção do cubo.
4.3.1 Esquema estrela
Como visto anteriormente, no esquema estrela temos uma tabela de fato,
que representa o dado mais importante da aplicação, e as tabelas
dimensionais. No caso do banco de dados gerenciais de projetos de pesquisa
fica fácil perceber que a tabela de fato conterá dados de projetos.
A questão agora é definir quantas e quais serão as tabelas dimensionais.
Pensando nas principais perguntas que descrevem os atores envolvidos em
70
um projeto acadêmico, conseguimos definir as tabelas de dimensões. Abaixo
está o esboço do esquema estrela.
Figura 16: Esboço do esquema estrela
A tabela de fato sabe o “o quê” é o centro da aplicação, que é justamente
os projetos. Cada tabela dimensional reponde uma pergunta crucial. São elas:
quem ganha com o projeto?; Quem paga os custos?; Quem realiza o projeto?;
Onde será feito o projeto?; Quando será feito?; Qual a categoria do projeto? Ou
seja, quais são os discriminadores dos projetos.
Com base nessas perguntas, e aproveitando a já definição das tabelas no
modelo relacional, chegamos ao modelo dimensional abaixo, mantendo a
estrutura estrela:
71
Figura 17: Esquema estrela da BD dimensional
É interessante relembrar aqui que um das características do modelo
dimensional é a não normalização das tabelas. Por exemplo, a tabela
Laboratório possui informações sobre a sala, o bloco e o departamento. No
modelo relacional precisaríamos de três tabelas para modelar isso, para deixar
tudo normalizado. Porém essa normalização aqui não tem necessidade, pois
72
essas tabelas do esquema estrela, que faz parte do data warehouse,
possuirão os valores contidos nas tabelas do banco de dados operacional, e
não serão alterados depois. Essa simplificação facilitará justamente o que se
quer com o data warehouse: analisar os dados de forma rápida e simples.
4.3.2 Cubo
Com o modelo estrela construído, podemos construir o modelo lógico do
data warehouse, que é chamado de cubo. O modelo estrela é considerado
como um modelo físico, enquanto que o cubo um modelo lógico. Isso porque
não é necessariamente um cubo propriamente dito, mas uma estrutura de
dados que, no contexto da nossa aplicação, permiti a navegação pelos projetos
nas dimensões de lugar, tempo, pessoas, etc.
Um cubo possui métricas, dimensões, hierarquias e níveis. As métricas
das tabelas de fatos são usadas para medir o desempenho do negócio.
Hierarquias são estruturas em forma de árvore contendo informações do
domínio de uma característica.
Para a construção do cubo foi utilizada a ferramenta open-source Pentaho
Cube Designer (44). A construção foi feita por uma interface gráfica amigável.
Após esta etapa o cubo está pronto, estando descrito em XML. Abaixo um
trecho do código do cubo da nossa aplicação, destacando os seus elementos:
<?xml version="1.0" encoding="UTF-8"?>
<Schema name="Projetos">
<Cube name="Projetos">
<Table name="projeto"/>
<Dimension name="Local" foreignKey="id_local">
<Hierarchy name="Local" hasAll="true" allMemberName="All local"
primaryKey="id_local">
<Table name="local"/>
<Level name="departamento" table="local" column="departamento"
uniqueMembers="false"/>
<Level name="bloco" table="local" column="bloco"
uniqueMembers="false"/>
<Level name="sala" table="local" column="sala"
uniqueMembers="false"/>
<Property name="area" column="area_sala" type="Numeric"/>
</Hierarchy>
</Dimension>
...
<Measure name="QuantidadeProjetos" column="idProjeto" aggregator="count"
datatype="Integer" formatString="#"/>
73
<Measure name="MediaAvaliacoesCliente" column="avaliacaoCliente"
aggregator="avg" datatype="Numeric" formatString="#,##"/>
<Schema> é a raiz do xml. Dentro de um schema pode haver muitos
cubos. Na nossa aplicação criamos apenas um: Projetos. Dentro da tag
<Cubo> definimos as seguintes dimensões:
• Local – contendo os níveis nessa ordem: departamento, bloco e sala.
Dessa forma, o usuário do sistema poderá navegar no sentido
departamento -> bloco -> sala. Também definimos uma propriedade
dessa dimensão no nível de sala, que é a área da sala.
• AreaTematica – contém os níveis do tema de um projeto: grande área,
área e subárea.
• Equipe – contém um único nível, que é o coodenador, e as
propriedades referentes a quantidade de estudantes da graduação,
mestrado e doutorado e a quantidade de professores envolvidos no
projeto.
• Favorecido – dimensão que permitir visualizar os dados do favorecido
do projeto. No nosso projeto consideramos apenas o atributo nome.
• Financiador – dimensão que possui o nível setor (público/privado) e o
nome do financiador do projeto. Assim, será possível separar os
projetos oriundos de verba pública e de verba privada.
• Cronograma – permitirá ao usuário do sistema navegar no sentido
ano -> mês nas datas
• Situação – essa dimensão foi acrescenta para que possamos separar
os projetos já finalizados dos que estão em andamento.
Após a construção do cubo, instalamos um servidor ROLAP chamado
Mondrian, também da organização Pentaho, em uma máquina e configuramos
o banco de dados que o servidor usaria para extrair os dados. Inserimos dados
fictícios no banco de dados diretamente no esquema estrela ao invés do
normal que seria inserir no banco de dados operacional criado na seção 4.2. O
objetivo deste projeto não era criar toda a infraestrutura de data warehouse,
74
mas sim o mínimo necessário para executar consultar MDX em uma base de
dados dimensional, construído sobre o esquema estrela.
Na etapa de povoamento do bando de dados em estrela, inserimos um
total de quinze projetos, dos quais nove representam projetos já finalizados e
seis projetos em andamento. Abaixo está o total de linhas (rows) inseridas na
base de dados:
Figura 18: Povoamento do banco de dados
4.3.3 Recuperação da informação
A recuperação da informação em um banco de dados dimensional dá-se
através de consultas com a linguagem MDX. No nosso projeto, a aplicação
cliente é executada no browser, o que caracteriza que nossa solução é ROLAP
na camada de persistência, e WOLAP na camada cliente [47], pois realiza as
operações OLAP via web. A seguir mostraremos um exemplo de consulta na
base de dados criados acima.
4.3.3.1 Consultas MDX
O MDX é uma linguagem de consulta para banco de dados OLAP, assim
como SQL para bancos relacionais. Sua sintaxe possui semelhanças com
fórmulas de planilhas eletrônicas. Foi desenvolvida pela Microsoft, e após a
invenção do XML para análise (XMLA) a MDX foi padronizada com a
linguagem de consulta multidimensional. [45]
Uma importante vantagem dessa linguagem é que ela funciona
independente da localização do cliente e do servidor dentro dos cubos do
75
OLAP. Se eles são localizados na mesma máquina, a comunicação ocorrerá
localmente, senão, ela se realizará através da rede. [46]
Abaixo está um exemplo de consulta MDX no nosso projeto. Ela cria uma
medida virtual (MediaGeral) e a formata. A medida [MediaGeral] não existe
fisicamente, sendo assim uma métrica virtual, que é o resultado de uma
operação matemática de duas ou mais medidas reais. Nesta consulta, a
formatação da string dessa medida virtual terá um estilo (cor de background)
vermelho se a média geral for menor que sete, e verde caso contrário. O select
selecionará as métricas da tabela Projetos, colocando-os nas colunas da tabela
resultado, e os departamentos da dimensão Local estarão nas linhas do lado
esquerdo da tabela. A cláusula where executa a operação slice, “fatiando” o
cubo projetos selecionando apenas os projetos finalizados. O resultado da
consulta é enviado à ferramenta olap cliente.
WITH MEMBER [Measures].[MediaGeral] AS
'( ([Measures].[MediaAvaliacoesCliente] + [MediaAvaliacoesComissao]) / 2)',
FORMAT_STRING = Iif([Measures].[MediaGeral] < 7.0, '|#.##|style=red',
'|#.##|style=green')
SELECT
{ [Measures].[QuantidadeProjetos], [Measures].[MediaAvaliacoesCliente],
[Measures].[MediaAvaliacoesComissao], [Measures].[MediaGeral],
[Measures].[OrcamentoProjetos] } on columns,
{ ([Local].[Departamento].Members) } ON rows
FROM Projetos
WHERE [Projeto.Situacao].[All situacao].[Finalizado]
Após executarmos a consulta acima aparecerá no browser a seguinte
tabela. No eixo vertical temos a dimensão Local, com os filhos de primeiro
nível, que são os departamentos (DEAG, DEE, DEMA e DSC). No eixo
horizontal temos as métricas provenientes da tabela fato Projetos.
76
Figura 19: Recuperação da informação
4.3.3.2 Relatórios e gráficos
A ferramenta possui integração com o Microsoft Excel, possibilitando a
exportação do resultado das consultas e navegações para uma planilha do
Excel que poderá servir de relatório para o gerente. Abaixo temos um relatório
Excel que separa os projetos em área temática e por período de tempo (ano e
mês do início), mostrando as métricas consideramos importantes para o
usuário do software (o gerente de projetos de P&D da universidade):
quantidade de projetos, avaliação média do cliente e da comissão acadêmica,
e o orçamento final do projeto.
Área Temática
Cronograma
All
cronograma
Ciências Exatas e
All
da Terra
cronograma
Ciências da
All
Computação
cronograma
All
cronograma
1995
1998
2001
Banco de Dados
1
4
2004
2006
2007
Redes de
All
Computadores
cronograma
All
Engenharia Agrícola
cronograma
QtdeProj MAvalCliente MAvalComissao
Orcamento
(R$)
14
5
5
273.238,4
7
4
5
150.255,15
4
6
6
62500,
1
7
8
15000,
2
1
1
9
9
9
9
9
9
12500,
7500,
5000,
Ciências Biológicas
1
35000,
3
2
2
87.755,15
2
3
3
28.550,5
77
Engenharia de
Materiais
Física
Matemática
Ciências Humanas
História
Teologia
Ciências Sociais
Aplicadas
All
cronograma
All
cronograma
All
cronograma
All
cronograma
All
cronograma
All
cronograma
All
cronograma
2
2
4
15850,
1
7
7
3.582,75
2
10
10
75000,
1
21.320,32
1
21.320,32
Tabela 2: Relatório dos projetos por área temática e tempo
A métrica MediaGeral foi criada nessa consulta, não existindo fisicamente
na tabela. Isso permitiu criarmos visões específicas para os usuários. Além
disso, na consulta nós formatamos essa medida, para destacar projetos que
tiveram boas avaliações e os que tiveram más avaliações.
A aplicação possui muitas funcionalidades. Uma delas é a montagem de
gráficos a partir dos dados resultantes mostrado na consulta da Figura 18. A
seguir temos o gráfico que relaciona os departamentos com e as médias gerais
dos projetos realizados neles, contidos na figura acima.
Figura 20: Avaliação dos Projetos por Departamento
78
Por fim, temos abaixo a visão da arquitetura ANSI/SPARC do nosso
Sistema de Informação Gerencial de Projetos de Pesquisa.
Dimensão
Interno
Conceitual
Externo
Esquema do
Modelo de Dados
F-Logic
MOF
Modelo de Dados
Relacional
UML, OCL,
Modelo Estrela
*
Dicionário de
Dados
Bloco compostopor Sala
Diagrama de
Classe e Regras
OCL
**
1 composto-por
201
Diagrama de
Objeto
Dados aplicativos
SGML1
***
Tabela 3: Arquitetura ANSI/SPARQ
1: SGML é a metalinguagem das linguagens de marcação.
*: Modelo dimensional: A estrutura é representada pelo Cubo. O controle é
definido através de tags xml <Role> indicando a permissão de acesso às
dimensões/métricas do cubo, e o acesso é feito por XMLA. A definição dos
esquemas XML de estrutura e controle dar-se-á por arquivos DTD.
**: Como extensão do modelo dimensional do cubo temos a instância do cubo
de projetos de pesquisa, descrito parcialmente abaixo (o código completo
encontra-se no apêndice):
<?xml version="1.0" encoding="UTF-8" ?>
<Schema name="Projetos">
<Cube name="Projetos">
<Table name="projeto" />
<Dimension name="Tempo" foreignKey="id_cronograma">
<Dimension name="AreaTematica" foreignKey="id_areatematica">
<Dimension name="Favorecido" foreignKey="id_favorecido">
<Dimension name="Bloco" foreignKey="id_local">
<Dimension name="Coordenador" foreignKey="id_equipe">
<Dimension name="Financiador" foreignKey="id_financiador">
<Measure name="Avaliação média do cliente" column="avaliacaoCliente"
aggregator="avg" datatype="Numeric" formatString="#.##0,###" />
<Measure name="AvaliaçãoMédia da comissão" column="avaliacaoComissao"
aggregator="avg" datatype="Numeric" formatString="#.##0,###" />
<Measure name="OrçamentoTotal" column="orcamento" aggregator="sum"
datatype="Numeric" formatString="#.##0,###" />
</Cube>
</Schema>
79
O controle foi realizado usando as tags XML descritas no início deste
capítulo: <SchemaGrant>, <CubeGrant>, <HierarchyGrant> e <MemberGrant>.
***: Os dados aplicativos são os resultados das consultas usando a linguagem
MDX mostrados em tabelas dinâmicas, que revelam uma visão do Cubo: suas
métricas, hierarquias e dimensões. O comportamento é alcançado através das
operações OLAP roll-up, drill-down, slice, etc.
80
5. CONCLUSÃO
As novas maneiras de desenvolver sistemas gerenciais, através do
WOLAP por exemplo, têm facilitado o acesso a informações que são vitais para
os negócios de uma empresa.
Nesta monografia realizou-se uma pesquisa bibliográfica sobre os
conceitos que envolvem os Sistemas de Informação Gerenciais, focando na
estrutura do Data Warehouse, que baseia-se na modelagem dimensional dos
dados (Star Scheme), processamento analítico online (OLAP) e consultas
usando MDX.
Em seguida, projetamos um sistema gerencial de projetos de P&D da
Universidade Federal de Campina Grande usando um servidor ROLAP
(Mondrian), um cliente WOLAP e um banco de dados relacional (MySQL).
Foram definidas as modelagens interna e conceitual dos bancos de dados
relacional e dimensional e a modelagem externa do banco de dados
dimensional.
Trabalhos futuros poderão propor um modelo mais próximo da realidade
dos projetos acadêmicos e utilizar outras abordagens OLAP, como o MOLAP
ou HOLAP. Além disso, pode-se criar um sistema mais abrangente, contendo
informações dos projetos por campus universitário, espalhados em várias
cidades.
81
REFERÊNCIAS
[1]
ASSUNÇÃ0,
Luis.
Data
Warehousing.
Disponível
http://www.luis.assuncao.eti.br/luisdwh.htm#item1.
na
Internet.
acessado
em
19/05/2007.
[2]
CLEMES, Márcio. Data Warehouse como suporte ao sistema de
informações gerenciais em uma instituição de ensino superior:
Estudo de caso na UFSC. Florianópolis:2001, 118f. Dissertação
(Mestrado em Engenharia de Produção) Universidade Federal de Santa
Catarina, 2001.
[3]
COMPUTERWORLD. Data warehouse: depósito de boas oportunidades.
Rio de Janeiro. n.173, p. 17, julho,1996.
[4]
DBMS – TOOLS & STRATEGIES FOR I.S. PROFESSIONAIS. Um
Manifesto do Dimensional Modeling. Rio de Janeiro. Ed. Mantelmedia,
n. 7, p. 44-50, 7 novembro,1997.
[5]
EXECPLAN.
Apresentação.
Disponível
http://www.execplan.com.br/apresent/apresent.htm.
na
Internet.
acessado
em
01/05/2007.
[6]
Fast Track to Sybase – Student Guide. 1992, Sybase Inc.
[7]
FIGUEIREDO, Adriana Maria C.M.. MOLAP x ROLAP: Embate de
Tecnologias para Data warehouse. Developer’s Magazine. Rio de
Janeiro: Axcel Books do Brasil Editora Ltda. Fevereiro de 1998, nº 18
p.24.
[8]
FILHO, Trayahú R.Moreira. On-Line
Analytical
Processing
Server
(Servidor OLAP). Developer’s Magazine. Rio de Janeiro: Axcel Books
do Brasil Editora Ltda. Fevereiro de 1998, nº 18 p.28-29.
82
[9]
FORMA INFORMÁTICA LTDA. Técnicas de Modelagem de Dados.
São Paulo, 26 maio, 1994.
[10]
GUTIERREZ, Marco Antônio. Developer’s Magazine. Rio de Janeiro:
Axcel Books do Brasil Editora Ltda. Fevereiro de 1998, nº 18 p.7.
[11]
http://osiris.sunderland.ac.uk/sst/case2/welcome.html,
acessado em
03/05/2007
[12]
INMON, W. H.
Building the Data warehouse.
New York : Wiley
Computer Publishing, 1996.
[13]
INMON, W. H., WELCH, J. D. e GLASSEY,Katherine L. Managing the
Data warehouse. New York : Wiley Computer Publishing, 1997.
[14]
INMON, Willian H. e HACKATHORN, R. D. Using the Data warehouse.
New York : J. Wiley, 1994.
[15]
JAMHOUR, Edgard. Data warehouse. Disponível em Lemon Internet
Services,
disponível
em
http://www.lemon.com.br/canais/tutoriais/bd.cfm?Id=338&Sub=13.
acessado em 15/05/2007.
[16]
JORNAL BATE BYTE – CELEPAR ( Companhia de Informática do
Paraná). Administração de Metadados. Curitiba, edição nº 76 em
junho de 1998.
[17]
JORNAL BATE BYTE – CELEPAR ( Companhia de Informática do
Paraná). Tecnologia OLAP. Curitiba, edição nº 87 em junho de 1999.
[18]
JÚNIOR TRONCHIN, Valsoir.
Warehousing
:Aspectos
Apresentação Sybase :
Estratégicos
e
de
Data
Implementação.
Curitiba,1997.
83
[19]
KIMBALL, Ralph. Data warehouse Toolkit. 1.ed. São Paulo: Makron
Books, 1998. 388p.
[20]
KONDRATIUK, Edgardo Ruben. Data warehouse: Detalhes que Fazem
a Diferença. Developer’s Magazine. Rio de Janeiro: Axcel Books do
Brasil Editora Ltda. Fevereiro de 1998, nº 18 p.22.
[21]
LAUDON, K. C.; LAUDON, J. P. Management information systems:
new approaches to organization and technology. 5. ed. New Jersey:
Prentice Hall, 1998.
[22]
LESCA,
H.
Structure
et
systeme
d’information
facteurs
et
competitive de l’entreprese. [S.l.]: Masson, 1996.
[23]
MACHADO, Felipe.
Modelagem de Dados Multidimensional. DBA
Engenharia de Sistemas. Rio de Janeiro, 1999.
MALLACH, E. G. Decision support and data warehouse systems. Boston:
McGraw-Hill, 2000. 664p.
[24]
MANNI, Luiz Carlos & DORSA, Luiz Fernando A. Data warehouse:
Gerenciando a Qualidade dos Dados. Developer’s Magazine. Rio de
Janeiro: Axcel Books do Brasil Editora Ltda. Fevereiro de 1998, nº 18
p.20.
[25]
NIMER, Fernando.Analisando o Retorno Sobre o Investimento de Data
warehouse. Developer’s Magazine. Rio de Janeiro : Axcel Books do
Brasil Editora Ltda. Fevereiro de 1998, nº 18 p.16-17.
[26]
OLIVEIRA LEITE., Argemiro A. Informação à Prova de Equívocos.
ComputerWorld Business Inteligence, Rio de Janeiro, n. 285, p.7, 8
março, 1999.
84
[27]
PALMA, Sérgio. Os Componentes Funcionais de um Data warehouse.
Developer’s Magazine. Rio de Janeiro:Axcel Books do Brasil Editora
Ltda. Fevereiro de 1998, nº 18 p.18-19.
[28]
PORTFÓLIO DE TECNOLOGIAS CELEPAR ( Companhia
de
Informática do Paraná). SQL, Índices, Modelo de Dados, Banco de
Dados. Curitiba,30 de junho de 1998.
[29]
POZZEBON, M.; FREITAS, H. M. R. Características desejáveis dos
enterprise information systems no final dos anos 90. Read, Porto Alegre,
v. 5, n. 1, abr. 1999. Disponível em:
<http://read.adm.ufrgs.br/read09/artigo/artigo_3.htm>. Acessado em:
03/05/2007.
[30]
SINGH, H. S. Data warehouse. São Paulo: Makron Books, 2001. 382p.
[31]
Sybase System 10: Introduction to SQL- Student Guide.1993, Sybase
Inc.
[32]
TAURION, Cezar. Data warehouse : Vale
a
Investindo em Um?. Developer’s Magazine.
Pena Gastar Milhões
Rio de Janeiro: Axcel
Books do Brasil Editora Ltda. Fevereiro de 1998, nº 18 p.10-11.
[33]
TAURION, Cezar. Data warehouse Será Útil Para a Sua Organização?
Developer’s Magazine. Rio de Janeiro : Axcel Books do Brasil Editora
Ltda. Fevereiro de 1998, nº 18 p.26-27.
[34]
TIMÓTEO, Max J. L., Ferramentas OLAP, disponível em
www.cin.ufpe.br/~mjlt/idw/relatorio2/OLAP.doc . Acessado em:
20/05/2007.
[35]
WANG, Charles B., Techno Vision II, ed. Makron Books, 1998.
85
[36]
Wikipedia,
XML,
disponível
em
http://pt.wikipedia.org/wiki/XML.
Acessado em 21/05/2007.
[37]
Wikipedia,
XML
for
Analysis,
disponível
em
http://en.wikipedia.org/wiki/XMLA . Acessado em 21/05/2007.
[38]
ZAMBON, Luís Pedro. Desenvolvimento de Sistemas de Informação.
Curitiba,Setembro de 1999.Disciplina do Curso de Especialização em
Gestão da Tecnologia da Informação e Comunicação da Faculdade
Católica de Administração e Economia.
[39]
The Object Management Group (OMG). MetaObjectFacility (MOF)
Specification – disponível em www.omg.org/docs/formal/02-04-03.pdf
acessado em 19/05/2007
[40]
HENSGEN, Paul, Manual do Umbrello UML Modeller, ano 2003,
disponível
em
http://docs.kde.org/stable/pt_BR/kdesdk/umbrello/uml-
basics.html acessado em 20/05/2007
[41]
LIMA, Daniel H. A, MUSIAL Rafael, Entendendo OCL - Apresentação e
utilização da Object Constraint Language, ano 2001
[42]
CUSTÓDIO
Eduardo,
Data
Warehouse,
disponível
em
http://www.maxarte.com.br/eduardocustodiohp/DataWareHouse.htm
acessado em 20/05/2007
[43]
SHAMMAS Gabriel, Extraindo dados de um DW, disponível em:
http://www.shammas.eng.br/acad/sitesalunos0106/012006dtw/extraindo.
htm. Acessado: 20/05/2007
[44]
Pentaho. http://www.pentaho.com/. Acessado em 18/05/2007.
86
[45]
Wikipedia,
Multidimensional
Expressions,
disponível
em
http://en.wikipedia.org/wiki/XMLA . Acessado em 18/05/2007.
[46]
SISNEMA Informática, MDX e Crystal Analysis: Duas ferramentas de
auxílio ao OLAP, disponível em:
http://sisnema.com.br/Materias/idmat014821.htm
[47]
JPivot - a JSP based OLAP client. http://jpivot.sourceforge.net/,
acessado em: 24/05/2007.
[48]
Mondrian: um servidor OLAP em Java.
http://mondrian.pentaho.org/documentation/architecture.php
87
Apêndice A
A.1 Estrutura
<?xml version="1.0" encoding="UTF-8" ?>
<Schema name="Projetos">
<Cube name="Projetos">
<Table name="projeto" />
<Dimension name="Local" foreignKey="id_local">
<Hierarchy name="Local" hasAll="true" allMemberName="All local"
primaryKey="id_local">
<Table name="local" />
<Level name="departamento" table="local" column="departamento"
uniqueMembers="false" />
<Level name="bloco" table="local" column="bloco" uniqueMembers="false" />
<Level name="sala" table="local" column="sala" uniqueMembers="false" />
<Property name="area" column="area_sala" type="Numeric" />
</Hierarchy>
</Dimension>
<Dimension name="AreaTematica" foreignKey="id_areatematica">
<Hierarchy name="AreaTematica" hasAll="true" allMemberName="All
areatematica" primaryKey="id_areatematica">
<Table name="areatematica" />
<Level name="grandeArea" table="areatematica" column="grandeArea"
uniqueMembers="false" />
<Level name="area" table="areatematica" column="area" uniqueMembers="false"
/>
<Level name="subarea" table="areatematica" column="subarea"
uniqueMembers="false" />
</Hierarchy>
</Dimension>
<Dimension name="Equipe" foreignKey="id_equipe">
<Hierarchy name="Equipe" hasAll="true" allMemberName="All equipe"
primaryKey="id_equipe">
<Table name="equipe" />
<Level name="coordenador" table="equipe" column="coordenador"
uniqueMembers="false">
<Property name="qtdeAlunosGraduacao" column="qtdeAlunosGraduacao"
type="Numeric" />
<Property name="qtdeAlunosMestrado" column="qtdeAlunosMestrado"
type="Numeric" />
<Property name="qtdeAlunosDoutorado" column="qtdeAlunosDoutorado"
type="Numeric" />
<Property name="qtdeProfessores" column="qtdeProfessores" type="Numeric"
/>
</Level>
</Hierarchy>
</Dimension>
<Dimension name="Favorecido" foreignKey="id_favorecido">
<Hierarchy name="Favorecido" hasAll="true" allMemberName="All favorecido"
primaryKey="id_favorecido">
<Table name="favorecido" />
88
<Level name="nome" table="favorecido" column="nome" uniqueMembers="false"
/>
</Hierarchy>
</Dimension>
<Dimension name="Financiador" foreignKey="id_financiador">
<Hierarchy name="Financiador" hasAll="true" allMemberName="All financiador"
primaryKey="id_financiador">
<Table name="financiador" />
<Level name="setor" table="financiador" column="setor" uniqueMembers="false"
/>
<Level name="nome" table="financiador" column="nome" uniqueMembers="false"
/>
</Hierarchy>
</Dimension>
<Dimension name="Cronograma" foreignKey="id_cronograma">
<Hierarchy name="Cronograma" hasAll="true" allMemberName="All cronograma"
primaryKey="id_cronograma">
<Table name="cronograma" />
<Level name="ano_inicio" table="cronograma" column="ano_inicio"
uniqueMembers="false">
<Property name="ano_fim" column="ano_fim" type="Numeric" />
<Property name="mes_fim" column="mes_fim" type="Numeric" />
</Level>
<Level name="mes_inicio" table="cronograma" column="mes_inicio"
uniqueMembers="false" />
</Hierarchy>
</Dimension>
<Dimension name="Projeto">
<Hierarchy name="Situacao" hasAll="true" allMemberName="All situacao">
<Table name="projeto" />
<Level name="situacao" table="projeto" column="situacao"
uniqueMembers="false" />
</Hierarchy>
</Dimension>
<Measure name="QuantidadeProjetos" column="idProjeto" aggregator="count"
datatype="Integer" formatString="#" />
<Measure name="MediaAvaliacoesCliente" column="avaliacaoCliente"
aggregator="avg" datatype="Numeric" formatString="#.##" />
<Measure name="MediaAvaliacoesComissao" column="avaliacaoComissao"
aggregator="avg" datatype="Numeric" formatString="#.##" />
<Measure name="OrcamentoProjetos" column="orcamento" aggregator="sum"
datatype="Numeric" formatString="#,###.##" />
</Cube>
</Schema>
A.2 Consultas MDX
Entre todos os projetos finalizados retorne a quantidade de projetos, a
média de avaliação do cliente, da comissão e o orçamento total do projeto:
89
<jp:mondrianQuery id="query01" jdbcDriver="com.mysql.jdbc.Driver"
jdbcUrl="jdbc:mysql://localhost/projetos_estrela?user=elmano&password=123"
catalogUri="/WEB-INF/queries/projetos_estrela.xml">
select
{[Measures].[QuantidadeProjetos], [Measures].[MediaAvaliacoesCliente],
[Measures].[MediaAvaliacoesComissao],
[Measures].[OrcamentoProjetos]} on columns,
{([Local].[Departamento].Members)} ON rows
from Projetos
where [Projeto.Situacao].[All situacao].[Finalizado]
</jp:mondrianQuery>
Agora, o coordenador de projetos deseja visualizar quais projetos
tiveram boas/más avaliações. Para isso, ele deseja que todos os projetos cuja
avaliação média, avaliaçãoCliente+avaliaçãoComissão / 2, for menor que sete
(7,0), seja destacado na cor vermelha, caso contrário na cor verde.
WITH MEMBER [Measures].[MediaGeral] AS
'( ([Measures].[MediaAvaliacoesCliente] + [MediaAvaliacoesComissao]) / 2)',
FORMAT_STRING = Iif([Measures].[MediaGeral] < 7.0, '|#.##|style=red',
'|#.##|style=green')
select
{[Measures].[QuantidadeProjetos], [Measures].[MediaAvaliacoesCliente],
[Measures].[MediaAvaliacoesComissao],
[Measures].[MediaGeral], [Measures].[OrcamentoProjetos]} on columns,
{([Local].[Departamento].Members)} ON rows
from Projetos
where [Projeto.Situacao].[All situacao].[Finalizado]
90