“Aplicação OLAP com Visualização Cartográfica” · 2.3.3. MDX – Multidimensional...
73
Universidade Federal de Santa Catarina “Aplicação OLAP com Visualização Cartográfica” Miguel Soares Nuno Santos Florianópolis – SC 2007
Transcript of “Aplicação OLAP com Visualização Cartográfica” · 2.3.3. MDX – Multidimensional...
Universidade Federal de Santa Catarina
“Aplicação OLAP com Visualização Cartográfica”
Miguel Soares
Nuno Santos
Florianópolis – SC
2007
Índice
Índice..................................................................................................................2 Indice de Figuras ................................................................................................3 Resumo ..............................................................................................................4 Abstract ..............................................................................................................5 1. Introdução ...................................................................................................6 2. Conceitos Base ...........................................................................................7 2.1. Data Warehouse ..................................................................................7 2.1.1. Elementos básicos de um Data Warehouse: ................................8 2.1.2. Características de um Data Warehouse:.....................................11 2.1.3. Modelos de uma Base de Dados: ...............................................13 2.1.4. Tipos de Modelos Dimensionais: ................................................15
2.2. OLAP..................................................................................................19 2.2.1. Classificação das ferramentas OLAP .............................................22 2.2.1.1. Multidimensional OLAP (MOLAP): ..........................................22 2.2.1.2. Relational OLAP (ROLAP):......................................................22 2.2.1.3. Hybrid OLAP(HOLAP): ............................................................22
2.2.2. Servidor OLAP – SQL Server 2005 ................................................24 2.3. Linguagens de comunicação com servidores.....................................25 2.3.1. XML – eXtensible Markup Language ..........................................25 2.3.2. XMLA – XML for Analysis............................................................27 2.3.3. MDX – Multidimensional Expressions .........................................29
2.4. GIS .....................................................................................................32 Técnicas usadas no GIS ...........................................................................32
3. Análise das ferramentas GIS.....................................................................36 3.1. Microsoft MapPoint 2006 North America............................................36 3.2. MapWindow........................................................................................37 3.3. ArcGIS Explorer .................................................................................38 3.4. AvisMap GIS Engine ..........................................................................39 3.5. Quantum GIS .....................................................................................40 3.6. Comparativo .......................................................................................41
4. Arquitectura proposta ................................................................................42 5. Implementação..........................................................................................48 5.1. SQL Server 2005................................................................................48 5.2. MapWindow........................................................................................56 5.2.1. Gerar mapas ...............................................................................57 5.2.2. Servir mapas ...............................................................................59
6. Trabalhos relacionados .............................................................................60 7. Conclusões e trabalhos futuros .................................................................61 Referências bibliográficas.................................................................................63 Anexo I .............................................................................................................67 Anexo II – Glossário .........................................................................................69 Anexo III – Acrónimos.......................................................................................73
Indice de Figuras
Ilustração 1 - Representação Gráfica de um Data WareHouse..........................8 Ilustração 2 - Número de Meta-Dados num Sistema Operacional e num Data WareHouse.......................................................................................................11 Ilustração 3 - Representação Gráfica de Cubo Multi-Dimensional ...................15 Ilustração 4 - Representação Gráfica do Modelo Star Scheme........................16 Ilustração 5 - Representação gráfica do modelo Snow Flake...........................17 Ilustração 6 - visão multidimensional dos dados, através de um cubo .............23 Ilustração 7 - SQL Server 2005 Developer Edition ...........................................24 Ilustração 8 - Exemplo de uma Representação Matricial..................................33 Ilustração 9 - Exemplo de uma representação vectorial ...................................34 Ilustração 10 - Arquitectura Geral de GIS.........................................................35 Ilustração 11 - Tabela comparativa de Ferramentas GIS .................................41 Ilustração 12 - Arquitectura do OLAP ...............................................................43 Ilustração 13 - Arquitectura do GIS...................................................................44 Ilustração 14 - Arquitectura integrada...............................................................46 Ilustração 15 - Esquema de dados ...................................................................50 Ilustração 16 - Resultado de uma query por estado .........................................67
Resumo
Este documento estuda a integração de bancos de dados multidimensionais
com ferramentas geográficas em ambiente Web. Este estudo acompanha a
tendência global de criação de ferramentas que melhorem o nível e qualidade
de análise de Data Warehouses por parte do analista.
O que se pretende neste trabalho é maximizar o potencial analítico de
dados em bancos multidimensionais através da geração de mapas que
permitam a visualização geográfica da mesma informação.
A ferramenta de BI utilizada foi o Microsoft SQL Server 2005 enquanto na
área de geração de mapas recorreu-se ao GIS MapWindow.
Abstract
This document studies the integration of multidimensional databases with
geographic tools in a Web environment. This study follows the global trend of
creating tools that improve the level and quality of analysis of Data Warehouses
by the analyst.
This work is about maximizing the potential of analytical data in
multidimensional banks through the generation of maps which allow the viewing
of the same geographical information.
The BI tool used was Microsoft SQL Server 2005 while in the area of
generating maps we used the MapWindow GIS.
1. Introdução
Este trabalho aborda a temática da integração OLAP e GIS para se
conseguir mostrar informação de uma forma geográfica, mais visual e de
percepção mais fácil.
Este projecto teve duas partes distintas: o desenvolvimento de visualização
online do cubo e geração de mapas através de queries OLAP. O protótipo
desenvolvido resulta de uma pesquisa de ferramentas de BI e de GIS que
apesar de fazerem parte de aplicativos diferentes são indispensáveis para o
funcionamento do projecto como um todo.
O Data Warehouse que serviu como base do nosso trabalho foi criado no
desenvolvimento de um trabalho de conclusão de curso na UFSC[17]. Como os
dados do dataWarehouse referem-se ao território brasileiro, os mapas foram
retirados do Instituto Brasileiro de Geografia e Estatística (IBGE)[27], no
formato ESRI shapefile.
Este documento inicia-se com uma breve descrição dos fundamentos
básicos para a percepção do trabalho (Capítulo 2), discute-se posteriormente
as ferramentas GIS analisadas e qual a nossa escolha no capítulo 3. Com as
ferramentas escolhidas apresentamos a arquitectura no capítulo 4, seguido da
discussão dos detalhes da implementação (Capítulo 5). Este documento
termina com o capítulo de trabalhos relacionados e conclusões e trabalhos
futuros (Capítulos 6 e 7 respectivamente).
2. Conceitos Base
2.1. Data Warehouse
O Data Warehouse é um armazém de dados, uma infra-estrutura que
possui uma arquitectura que permite integrar os dados da empresa de forma a
ter uma visão, histórica e não volátil, da empresa.
Conjunto de bases de dados integradas, desenhadas para auxiliar o
sistema de apoio à tomada de decisão da organização. Os dados são
predominantemente históricos, atómicos e levemente resumidos.
Serve como um repositório de dados para muitos tipos de informação de
negócio oriunda de muitas fontes. A informação destas fontes é transferida
para o DW para ser de acesso mais fácil, depois é indexada e combinada para
um acesso mais rápido. [13][14][15][16]
2.1.1. Elementos básicos de um Data Warehouse:
Ilustração 1 - Representação Gráfica de um Data WareHouse
Na figura acima estão representados os elementos básicos de um DW, um
armazém de dados é constituído por 3 componentes. A componente de Back
end, a de Front End e a componente de Meta-Dados.
A componente de Back End,é constituída por:
• SourceSystems (Sistemas Fontes): São também chamados Sistemas de
Informação Operacionais. Tratam-se de sistemas de informação que
numa empresa ou organização servem para registar os acontecimentos
do dia-a-dia do negócio. Estes Sistemas fontes tem como características
terem uma alta disponibilidade ou seja estão operacionais e disponíveis
24 horas por dia, tem uma boa performance transaccional (inserts,
updates, deletes) apresentam um bom desempenho na execução da
alteração dos dados, têm os seus queries quase sempre “estreitos” ou
previstos, ou seja poucos registos de cada vez( consegue dados sobre
um cliente e uma encomenda mas nunca de todos os clientes e as suas
encomendas) e por fim têm queries pré programados (são quase
sempre iguais às necessidades do utilizador).Estes sistemas funcionam
isolados uns dos outros na empresa, podendo por vezes gerar
redundância ou volatilidade nos dados.
• Data Staging Área: Área de retenção, prepara os dados para serem
carregados no data Warehouse. Não se fazem queries a estes dados. A
informação pode ser guardada em base de dados ou ficheiros. Esta é a
camada que transporta os dados dos sistemas operacionais para o data
Warehouse, depois destes passarem por um processo de transformação
que se chama ETL. Através de uma analogia pode-se considerar esta
área uma cozinha onde os dados impróprios para consumo são
transformados para tendo em vista o bom consumo do utilizador.
ETL – As ferramentas de ETL têm como função agregar informação de
várias fontes e produzir informação integra e de qualidade, ou seja, sem erros,
sem duplicações, sem omissões e sem diversificações. Desta forma começa-se
por ser feita a extracção dos dados, seguindo-se a transformação que se divide
em duas fases, limpeza e conciliação dos dados, e por fim é feito o
carregamento na DW, colocando os dados num modelo dimensional.[17]
Presentation Server: Trata-se de uma máquina física onde os dados do
data Warehouse são organizados e guardados para o querying directo por
parte dos utilizadores finais, para relatórios e outras aplicações.
Componente de Front-End:
Aplicações End-User: Trata-se do conjunto de ferramentas que executam
queries, analisam e apresentam a informação procurada de forma a suportar as
necessidades do negócio exemplo dessas ferramentas são o Ad Hoc, Query
Tool e o Data Mining.
Componente de Meta Dados:
Os Meta Dados: São considerados como sendo "os dados dos dados" ou
dados sobre os sistemas que operam com estes dados, ou seja, não serve
para descrever o conteúdo mas sim o contexto da informação. São portanto um
directório para ajudar o analista de DSS a localizar os dados num DW, um guia
para o manuseamento de dados, como os dados são transformados do
ambiente operacional para o ambiente de DW, é também um guia para os
algoritmos usados para sumariar entre os dados detalhados actuais, os dados
ligeiramente resumidos e os dados altamente resumidos.
Ilustração 2 - Número de Meta-Dados num Sistema Operacional e num Data WareHouse
Nesta figura é possível verificar a diferença que existe no número de meta-
dados num sistema operacional ou seja num sistema fonte e num armazém de
dados, como se pode verificar existem muito mais meta-dados no DW que num
sistema operacional.
2.1.2. Características de um Data Warehouse:
Um sistema de DW possui quatro características básicas que são: é
organizado por temas, é integrado, é variante no tempo e não é volátil.
Organizado por Temas:
Um DW é organizado por temas, este armazena informações consoante o
assunto da informação e importância que este tem para o negócio da empresa.
Alguns exemplos de temas utilizados em projectos deste tipo são: produtos,
actividades, conta, clientes, etc.
Integrado:
O DW é integrado porque consegue uniformizar todos os conceitos dos
valores das tabelas e outras aplicações default, de modo a que todos os
valores da base de dados sejam homogéneos. (exemplo pode ser com o sexo
do cliente enquanto numa área o funcionário coloca o sexo feminino com a
conotação “F” noutra Área o funcionário pode colocar o sexo com a conotação
“Feminino” fazendo com que haja dois tipos de conceitos uma vez no DW isso
já não acontece, pois ele consegue evitar essas situações).
Variante:
Os dados contidos num DW são temporais, ou seja, referem-se a períodos
de tempo bem definidos, e isto auxilia na análise e na confirmação de
acontecimentos sazonais dentro de uma determinada actividade ou ramo de
negócio.
Não Volátil:
Um sistema de DW deve permitir apenas uma carga inicial dos dados e
posteriormente deve permitir aos utilizadores a consulta desses mesmos. Esta
característica é conhecida por "load-and-access". Os dados integrados e
transformados são carregados para o DW na forma de blocos de informações,
ficando assim à disposição dos utilizadores do sistema. Já no ambiente
operacional temos uma situação diferente: os dados são actualizados de forma
atómica, registo a registo.
2.1.3. Modelos de uma Base de Dados:
Quando se constrói uma base de dados pode se utilizar diferentes tipos de
modelos como são o caso do modelo relacional, do modelo hierárquico, do
modelo de rede e do modelo dimensional. No caso do nosso projecto vamos
utilizar o modelo Dimensional, assim fizemos uma breve descrição deste
modelo, dando uma menor importância aos outros que optámos apenas por
referir.
Modelo Dimensional
O modelo dimensional é uma técnica de modelagem de dados usado na
construção de uma base de dados de um data Warehouse. Esta técnica
permite que as informações se relacionem de forma que possa ser
representada como um cubo. Sendo assim podemos partir este cubo e
aprofundar cada uma das dimensões, este modelo relaciona as tabelas de
factos com as tabelas de dimensões, esta modelagem é realizada de forma a
ganhar uma melhor performance nas consultas, este modelo visa apenas
consultas analíticas.
O modelo dimensional permite visualizar dados abstractos de forma simples
e relacionar informações de diferentes sectores da empresa de forma muito
eficaz, o que o torna numa ferramenta muito poderosa. [18][19][20]
O modelo dimensional é constituído por quatro atributos:
- Facto representa o objecto que queremos analisar e
que representa o negócio. A quantidade de factos é
que determina o modelo a usar.
- Dimensões de análise dos factos (onde? Quem?
quando?)
- Métricas (Como é que eu vou medir os factos. Os
factos têm de ser mensuráveis) [valor, quantidade]
- Hierarquia: Organizar a informação (A hierarquia do
tempo é sempre usada).
O que torna o Data Warehouse uma ferramenta muito poderosa é a
capacidade que este tem de reunir informações que se situam em várias fontes
espalhadas por todos os sectores da empresa, e reuni-las num só banco de
dados de forma dimensional, conseguindo colocar toda a informação de uma
forma homogénea e consequentemente colocando as informações unificadas e
padronizadas num só local.
Ilustração 3 - Representação Gráfica de Cubo Multi-Dimensional
2.1.4. Tipos de Modelos Dimensionais:
2.1.4.1. O Modelo Estrela (Star Schema):
O principal tipo de modelo dimensional, é o chamado modelo Star (Estrela),
onde existe uma tabela dominante no centro, chamada tabela de facto, com
múltiplas junções conectando-a a outras tabelas, sendo estas chamadas de
tabelas de dimensão. Cada uma das tabelas secundárias possui apenas uma
junção com a tabela central. O modelo Estrela, ilustrado na Figura abaixo, tem
a vantagem de ser simples e intuitivo, mas também faz uso da indexação e
união de tabelas.
As tabelas de factos contêm milhares ou milhões de valores e medidas do
negócio da empresa, como transações de vendas ou compras. Cada uma
destas medidas tem uma dimensão relacionada. Os factos mais úteis são
numéricos e aditivos, já que estes facilitam a geração do conjunto de
respostas. Uma outra característica é o facto desta tabela não armazenar
zeros.
As tabelas de dimensão armazenam as descrições das dimensões do
negócio. Cada uma dessas descrições ajuda a definir um componente da
respectiva dimensão. Uma das principais funções dos atributos de tabelas de
dimensão é servir como fonte para restrições em uma consulta ou como
cabeçalhos de linha no conjunto de resposta do utilizador.
Ilustração 4 - Representação Gráfica do Modelo Star Scheme
2.1.4.2. O modelo Floco de Neve (Snow Flake):
No modelo Floco de Neve as tabelas dimensionais relacionam-se com a
tabela de fatos, mas algumas dimensões relacionam-se apenas entre elas, isto
ocorre para fins de normalização das tabelas dimensionais, visando diminuir o
espaço ocupado por estas tabelas.
No modelo Floco existem tabelas de dimensões auxiliares que normalizam
as tabelas de dimensões principais. Na figura abaixo podemos verificar essas
tabelas são (Ano, Mês e Dia) que normalizam a Dimensão Tempo, (Categoria,
Departamento e Marca) que normalizam a Dimensão Produto e a tabela Meio
que normaliza a Dimensão Promoção.
Construindo a base de dados desta forma, passamos a utilizar mais tabelas
para representar as mesmas dimensões, mas ocupando um espaço em disco
menor do que o modelo estrela. Este modelo chama-se floco de neve, pois
cada dimensão se divide em vaias outras tabelas, onde organizadas de certa
forma lembra um floco de neve.
Ilustração 5 - Representação gráfica do modelo Snow Flake
Comparação entre os dois modelos:
O Modelo Floco (Snow Flake) reduz o espaço de armazenamento dos
dados dimensionais mas acrescenta várias tabelas ao modelo, deixando-o
mais complexo, tornando mais difícil a navegação pelos softwares que
utilizarão o banco de dados. Um outro factor é que mais tabelas serão
utilizadas para executar uma consulta, então mais JOINS de instrução SQL
serão feitos, tornando o acesso aos dados mais lento do que no modelo
estrela.
O Modelo em Estrela (Star Schema) é mais simples e mais fácil de
navegação pelos softwares, porém desperdiça espaço repetindo as mesmas
descrições ao longo de toda a tabela, porém análises feitas mostram que o
ganho de espaço normalizando este esquema resulta em um ganho menor que
1% do espaço total no banco de dados, sendo assim existem outros factores
mais importantes para serem avaliados para redução do espaço em disco
como a adição de agregados e alteração na granularidade dos dados, estes
temas serão abordados em colunas posteriormente.
Assim concluímos que um modelo estrela é mais adequado pois fornece um
acesso mas rápido aos dados e mais fácil de se navegar, criando tabelas
auxiliares para dimensões somente para dimensões especificas quando for
estritamente necessário ou quando demonstrar um beneficio que justifique a
perda de desempenho nas consultas, que também não é tão grande
dependendo da forma que estas tabelas são construídas e a quantidade de
registros que elas contiverem.
2.2. OLAP
OLAP – Online Analytical Processing é uma ferramenta de BI que permite
ao utilizador analisar informação que foi resumida em varias perspectivas no
cubo multidimensional. Com o OLAP um utilizador terá a possibilidade de fazer
Drill Down (descer na hierarquia do cubo e ter uma analise mais especifica),
Drill Cross (faz com que duas ou mais tabelas de facto que compartilham
dimensões sejam combinadas num único relatório). [3]
O Grande componente do OLAP é o seu servidor no nosso projecto iremos
utilizar um servidor de OLAP chamado SQL Server 2005, que é o elemento
responsável por fazer a ligação entre o cliente e o SGBD (Sistema de gestão
de Base de Dados), isto é possível porque o servidor OLAP sabe como é que
os dados estão organizados na base de dados e tem umas aplicações que
possibilitam essa sua analise. Em modo de conclusão podemos afirmar que o
servidor OLAP faz de ponte entre o cliente e a base de dados. [4][7]
Kimbal realizou estudos sobre as funcionalidades específicas que todas
as ferramentas OLAP deveriam ter e listou essas caracteristicas, apresentadas
abaixo:
• Visibilidade: a ferramenta deverá apresentar de forma clara e, se
possível,em uma mesma tela, as dimensões, as restrições sobre essas
dimensões e as tabelas de fatos disponíveis para análise. As edições
realizadas no relatório pelo usuário também devem ser facilmente visualizadas
por ele apenas com poucos cliques de mouse.
• Browse/Navegação: a ferramenta deve permitir ao usuário “navegar” de
forma intuitiva pelos dados e deve fazê-lo compreender e explorar as
dimensões disponíveis.
• Valores nulos: refere-se à maneira como a ferramenta trata a ausência de
valor numa determinada coluna, seja colocando espaços em branco ou alguma
mensagem como, por exemplo, “não aplicável”.
• Interface de ajuda: a ferramenta deve se preocupar não só em apresentar
sua documentação e explicação detalhada das funções disponíveis e como
executá-las, mas também ter um “repositório” ou dicionário dos dados com
explicações feitas na terminologia do negócio.
• Comparações Pré-definidas: alguns tipos de comparação devem estar
sempre disponíveis, tais como, diferença numérica, diferença percentual,
proporção, fator de crescimento durante N períodos de tempo e outras.
• Drill-Down, Drill-Across: Drill down e drill across são recursos fundamentais
para uma análise efetiva por parte do usuário. Fazer um drilldown significa
obter mais informações sobre os dados que estão sendo apresentados, seja
descendo numa hierarquia ou adicionando dimensões que complementem a
análise dos dados. Drill-across é fazer com que duas ou mais tabelas de fato
que compartilham dimensões sejam combinadas num único relatório.
• Manipulação de exceções: está relacionado à capacidade da ferramenta de
proporcionar alertas ou marcadores para itens excepcionais, limitar o relatório
apenas às linhas com valores nulos, determinar faixas de valores numéricos ou
percentuais, demarcar limites superior e inferior, etc.
• Interação com agregados: a ferramenta deve saber gerenciar valores
agregados pré-armazenados de forma que, quando da navegação do usuário
pelos dados, principalmente usando drill-down, o fato de o dado ser pré-
armazenado ou não seja transparente.
• Análise/Restrições de Comportamento: capacidade da ferramenta de
rastrear um determinado comportamento de forma a utilizar essa informação
em outro relatório (Exemplo: isolar um grupo especial de clientes para utilizá-lo
num relatório mais complexo).
• Rotacionamento/Visualização: cabeçalhos de linhas e colunas devem poder
ser misturados em combinações arbitrárias fazendo com que os dados do
relatório sejam reorganizados de uma forma que tenha mais sentido para o
usuário. Além disso, a ferramenta deve ter disponíveis vários modos de
apresentação tais como planilhas, gráficos, matrizes, etc.
• Operação Batch: refere-se à possibilidade de agendar o processamento de
consultas já definidas, principalmente se o tempo de resposta destas for
demorado.
2.2.1. Classificação das ferramentas OLAP
Podemos classificar as ferramentas OLAP quanto a sua forma de acesso aos
dados, as suas principais características estão enumeradas em baixo:
2.2.1.1. Multidimensional OLAP (MOLAP):
O MOLAP permite fazer transacções dos dados nas diferentes perspectivas
multidimensionais do cubo. Os dados num cubo estão organizados numa dada
estrutura e graças a esta tecnologia vai permitir ao utilizador percorrer todo
cubo dando lhe a possibilidade de retirar a informação que deseja. [17]
2.2.1.2. Relational OLAP (ROLAP):
As ferramentas de OLAP relacionais conseguem extrair dados das tabelas
de base de dados que utilizam um modelo relacional, ROLAP é normalmente
usado em dados que tenham uma grande quantidade de atributos, onde é
complicado coloca-los num cubo. [17]
2.2.1.3. Hybrid OLAP(HOLAP):
Hybrid Olap é uma tecnologia que combina as vantagens do MOLAP e do
ROLAP, permite assim guardar parte dos dados em ROLAP e a outra parte em
MOLAP conseguindo assim combinar as potencialidades dos dois modelos.
[17]
Ilustração 6 - visão multidimensional dos dados, através de um cubo
Como visto acima, toda ferramenta OLAP provê uma visão multidimensional
dos dados, com isso podemos imaginar que os dados estão alocados em um
cubo pré-calculado que contém todas as respostas possíveis para um
eterminado âmbito, onde a ferramenta OLAP irá percorrer de acordo com a
visão que o usuário solicitar.
Para melhor entendimento de um cubo OLAP devemos primeiramente
entender seus principais componentes, descritos abaixo:
Dimensões: São o topo ou as mais altas categorias de um cubo. Contêm
subcategorias conhecidas como níveis ou medidas. Uma dimensão pode ter
múltiplas hierarquias e pode ser usada em vários cubos. Um cubo pode ter
até 64 dimensões.
Hierarquia: Uma dimensão pode ser categorizada com diferentes
hierarquias.
Níveis: São categorias para organização dentro da dimensão. Níveis são
hierárquicos, e cada nível descendente é um componente do nível acima. Por
exemplo, a dimensão tempo pode conter os seguintes níveis: Ano,
Trimestre, Mês, Semana e Dia.
Membro: É um componente de um nível e é análogo a um valor deste
nível. Por exemplo, o nível Ano tem os membros “2005”, “2006”, etc...
2.2.2. Servidor OLAP – SQL Server 2005
Ilustração 7 - SQL Server 2005 Developer Edition
“Ideal Choice for Independent Software Vendors, Consultants, System
Integrators, Solution Providers, and Corporate Developers”
Hoje em dia cada vez mais as empresas tem uma grande necessidade de
informação de qualidade, assim é necessário uma ferramenta que tenha uma
excelente performance, que seja flexível e que seja de confiança, para alem de
tudo isto que seja ao mesmo tempo fácil de utilizar e de a manter. A
Ferramenta SQL Server excede todas as expectativas nestes pontos pois
consegue entregar ao utilizador final informação de confiança e de qualidade.
Assim neste projecto optámos por utilizar o como servidor OLAP, o SQL
Server 2005 “Developer Edition”. É um servidor que permite ao utilizador
construir e testar qualquer aplicação SQL em plataformas de 32 bits, ia64 e
x64. Esta versão inclui todas as funcionalidades das edições anteriores, mas
tem uma licença que apenas funciona para o desenvolvimento de aplicações,
testes e utilização dessas mesmas aplicações como demo mas pode ser
facilmente up-grated para uma versão que permita um maior número opções,
como é o caso da “entreprise edition”. [6]
2.3. Linguagens de comunicação com servidores
2.3.1. XML – eXtensible Markup Language
XML é a abreviação de EXtensible Markup Language (Linguagem
extensível de formatação). Trata-se de uma linguagem que é considerada uma
grande evolução na Internet.
O XML é uma especificação técnica desenvolvida pela W3C (World Wide
Web Consortium – entidade responsável pela definição da área gráfica da
internet), para superar as limitações do HTML, que é o padrão das páginas da
Web.
A linguagem XML é definida como o formato universal para dados
estruturados na Web. Esses dados consistem em tabelas, desenhos,
parâmetros de configuração, etc. A linguagem então trata de definir regras que
permitem escrever esses documentos de forma que sejam adequadamente
visíveis ao computador. [8]
Objectivos do XML:
1. Separação do conteúdo da formatação
2. Simplicidade e legibilidade, tanto para humanos quanto para
computadores
3. Possibilidade de criação de tags sem limitação
4. Criação de arquivos para validação de estrutura
5. Interligação de bancos de dados distintos
6. Concentração na estrutura da informação, e não na sua informação
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 vectoriais ou bancos de dados.[9]
Exemplo de uma tag em XML, no exemplo abaixo iremos descrever um
Curriculum Vitae:
Codigo XML descrevendo um Curriculum Vitae:
2.3.2. XMLA – XML for Analysis
O XMLA é uma API (Application Programming Interface) standart que
funciona através de SOAP (Simple Object Access Protocol), para a troca de
dados multi-dimensionais entre um cliente e um servidor, independente de
plataforma e linguagem.
A principal razão para a aceitação desta linguagem como standart deve-se
ao facto de estar suportada pelos principais fabricantes de ferramentas de BI e
mais especificamente de OLAP, com a excepção da ORACLE que não suporta
a utilização desta linguagem no seu sistema. Esta linguagem funciona através
de Web Services, que permitem que o XMLA aceda a multiplas fontes de
dados multi-dimensionais e forneça-os a vários tipos de clientes sem qualquer
custo adicional.[10]
<?xml version="1.0" encoding="UTF-8"?>
<curriculo> <InformacaoPessoal>
<DataNascimento>02-04-88</DataNascimento> <Nomecompleto>Leonardo da Silva
Machado</Nomecompleto> <Contatos>
<Morada>R.Caratinga, 112,Anchieta, Brasil</Morada> <Telefone>97446182</Telefone> <CorreioEletronico>leodsm01@gmail</CorreioEletronico
> </Contatos> <Nacionalidade>brasileiro</Nacionalidade> <Sexo>M</Sexo>
</InformacaoPessoal> </currículo>
2.3.2.1. Métodos
O protocolo XMLA possui dois métodos que utilizam o protocolo SOAP:
• Discover – Obtém informação e metadados de um Web Service.
Este método permite especificar o que se está à procura, as
restrições e as propriedades. Tem como resultado um conjunto
de linhas.
• Execute – Este método é utilizado para enviar pedidos de acções
ao servidor, no qual está incluído transferência de dados (retirar e
colocar dados no servidor)
Em baixo iremos mostrar um exemplo de XMLA, neste caso especifico o
cliente envia um Discover para pedir a lista de cubos da Data Warehouse da
empresa “Adventures Work”.
2.3.3. MDX – Multidimensional Expressions
MDX é uma linguagem que é usada para manipular dados
multidimensionais (no caso do no projecto nós iremos utilizar esta linguagem
no Microsoft SQL Server2005 Analysis Server). Esta linguagem é baseada no
XMLA mas tem algumas especificações do SQL. É uma linguagem muito rica e
poderosa para a manipulação de dados utiliza expressões compostas por
identificadores, valores, funções e operadores de modo a conseguir retornar o
<Discover xmlns=”urn:schemas-microsoft-com:xml-analysis”>
<RequestType>MDSCHEMA_CUBES</RequestType>
<Restrictions>
<RestrictionsList>
<CATALOG_NAME>Adventure Works DW
</CATALOG_NAME>
</RestrictionsList>
</Restrictions>
<Properties>
<PropertiesList>
<Catalog> Adventure Works DW </catalog>
<Format> Tabular </Format>
</PropertiesList>
</Properties>
</Discover>
objecto do cubo. MDX é a linguagem mais comum para se fazerem consultas
OLAP, permite:
• Retornar dados;
• Formatar os resultados da query;
• Fazer tarefas como: calcular o número de membros de um determinado
data set, agrupar elementos por indicadores de performance (KPI);
• Efectuar tarefas administrativas.
A sintaxe do MDX é muito semelhante ao SQL que é tipicamente usado em
base de dados relacionais, contudo o MDX não é uma extensão do SQL é
muito diferente em muitos aspectos pois este permite controlar estruturas de
dados ou seja DDL (Data Definition Language). [11][12][13]
A sintaxe mais básica e mais comum do MDX são comandos como:
1. Select: Selecciona quais os campos que o utilizador deseja visualizar.
2. From: Selecciona de que tabelas é que o utilizador vai visualizar.
3. Where: Limita a query do utilizador de acordo com o solicitado.
Em abaixo iremos mostrar um exemplo de uma query em MDX, que
retorna um result set com todas as vendas que ocorreram nos Estados unidos,
mais concretamente na Califórnia nos anos de 2002 e 2003.
SELECT
{ [Measures].[Store Sales] } ON COLUMNS,
{ [Date].[2002], [Date].[2003] } ON ROWS
FROM Sales
WHERE ( [Store].[USA].[CA] )
2.4. GIS
Um Sistema de Informação Geográfica é um sistema de informação
espacial e procedimentos computacionais, que permite capturar, analisar e
gerir dados que têm uma perspectiva espacial, ou seja capaz de mostrar dados
sobre uma referência geográfica. A informação do GIS pode ser usada para os
mais diversos propósitos tais como investigação cientifica, gestão de recursos,
planeamento urbano, catástrofes naturais, para concluir é uma ferramenta com
muita utilidade nos dias de hoje. [21][22]
Técnicas usadas no GIS
Criação de Dados
As tecnologias de GIS mais modernas usam informação digital, assim
existem diferentes métodos de criação de dados. A técnica mais comum de
criação de dados e a digitalização, por exemplo copias de mapas são
digitalizados e passados para computador através de um programa chamado
CAD (Computer Aided Design).
Representação de dados:
Dados de GIS representam objectos reais (ruas, terras, elevações). Os
objectos são divididos em 2 abstracções: Objectos discretos (ex.: uma casa) ou
objectos contínuos (ex.:chuva). Existem duas maneiras de representar estes
objectos por Matriz e por Vector.
Matriz:
Os dados pela forma matricial consistem num conjunto de linhas e colunas
de células em que dentro de cada célula esta guardado um único valor, o valor
em cada uma das células vai representar o respectivo objecto, esse valor pode
ser um variável discreta que nesse caso poderia representar um pedaço de
terra, ou então poderia ser uma variável contínua que nesse caso poderia
representar a chuva. Imagens de rasteio podem ser armazenadas em
diferentes tipos como JPEG ou TIF.
Ilustração 8 - Exemplo de uma Representação Matricial
Vector:
Dados representados por vectores usam a geometria para representar o
espaço geográfico como por exemplo pontos, linhas, polígonos para
representar objectos, estes dados também podem representar objectos
contínuos ou discretos.
Ilustração 9 - Exemplo de uma representação vectorial
Vantagens e Desvantagens
Existem uma série de vantagens e desvantagens por usar o método
matricial ou de vector para representar a realidade. Nos dados por matriz é
necessário ter um valor para todos os pontos na área que nos interessa
representar o que pode significar necessitar de um maior espaço para
armazenamento, apesar de se tornar mais fácil para implementar do que por
vector. Com vector a imagem fica com uma maior noção de profundidade e
com uma maior precisão do que com rasteio. O método vectorial é mais
compatível com uma base de dados relacional.
Arquitectura de um GIS
De modo geral a arquitetura de um sistema de informações geográficas
deve ter os seguintes componentes:
a) interface com usuário;
b) entrada e integração de dados;
c) consulta e análise espacial;
d) visualização e plotagem;
e) armazenamento e recuperação de dados sob a forma de um banco de
dados geográficos.
A Ilustração 10mostra como estes componentes formam uma hierarquia.
Ilustração 10 - Arquitectura Geral de GIS
3. Análise das ferramentas GIS
3.1. Microsoft MapPoint 2006 North America
Esta versão da aplicação destina-se principalmente para utilizadores da
América do Norte, pois as suas totais capacidades estão somente disponíveis
nessa área Geográfica. Além desta hipotese existiam outras duas dentro da
família de produtos MapPoint:
• Microsoft MapPoint 2006 Europe Edition – Mesmas funções que a
aplicação estudada, mas virada fundamentalmente para o
território europeu
• Microsoft MapPoint WebService – serviço Web suportado pela
Microsoft que possui informação detalhada sobre o Brasil.
Necessita de licença para aceder ao servidor e
consequentemente ao serviço.
A opção pelo estudo da aplicação indicada deveu-se ao facto de esta ser a
única ferramenta da família MapPoint disponível sem a necessidade de haver
qualquer dispendio financeiro.
Esta foi uma opção estudada aprofundadamente pois foi a ferramenta em
que inicialmente aplicámos os nossos esforços relativamente à demonstração
geográfica. As funcionalidades da aplicação eram promissoras, pois a
existência de um add-in que realizava queries OLAP directamente ao
DataWarehouse e outro que permitia a importação de ficheiros com extensão
.shp auxiliariam na execução do que nos foi proposto.
O API disponibilizado pelos dois add-ins acima mencionados caracteriza-se
pela falta de documentação e poucas funcionalidades facultadas ao
programador, aliadas à escassez de tempo impossibilitaram a continuidade do
projecto na ferramenta MapPoint, pelo que foi necessário procurar novas
abordagens à solução do problema proposto.
Qualquer uma das soluções acima descritas possui licença comercial, pelo
que é necessário efectuar pagamento para poder utilizar este software sem ser
por tempo limitado.
Após o estudo efectuado nesta ferramenta, fica clara a ideia que esta é
bastante apropriada para problemas de criação de rotas, geração de gráficos
distribuidos geográficamente e funcionalidades de GPS dentro da área
geográfica a que diz respeito.
3.2. MapWindow
Esta é uma solução de GIS open source e gratuita que se caracteriza por
ser extensível, pois permite que qualquer pessoa consiga adicionar
funcionalidades à aplicação.
Esta solução apresenta três produtos distintos:
• MapWindow Application – aplicação desktop que permite a
visualização espacial de dados.
• ActiveX control – este componente é um objecto programável que
pode ser embutido numa janela aplicativa. Possui um API que
permite o acesso a dados de polígonos, tabelas e imagens. Pelas
características atrás descritas este componente torna-se bastante
poderoso pois permite a criação de um GIS à medida das
necessidades do utilizador.
• Plug-ins – é possivel acrescentar funcionalidades à aplicação
desktop MapWindow.
A sua principal vantagem é possuir um controlo activeX programável que
pode ser facilmente embutido em qualquer aplicação, a par das capacidades
que o seu API permite ao programador.
Outra característica bastante positiva para o desenvolvimento deste
projecto é o facto de ser gratuito e permitir um suporte bastante interessante
para iniciantes.
A nossa escolha recaiu sobre esta ferramenta pois considerámos que as
características do componente activeX desta aplicação permitiria-nos a
manipulação dos dados conforme os requisitos do nosso projecto.
3.3. ArcGIS Explorer
Esta aplicação é um visualizador de informação geográfica muito eficaz,
pois permite a visualização dos dados de diversas formas, devido às muitas
funcionalidades que possui.
Além das funcionalidades vulgares dos GIS comuns, o ArcGIS Explorer
permite juntar dados locais com dados recolhidos existentes em servidores da
ESRI e de parceiros e analisar geograficamente dados, quer estáticos quer
através de tarefas (procuras de locais, modelação, análise de visibilidade).
Permite também receber dados provenientes de WebServices.
Ao nível de aplicação desktop, este é um visualizador GIS que se pode
adaptar às necessidades do utilizador, pois permite a personalização da
aplicação.
Possui um SDK disponível, quer permite a criação de tarefas existentes e
novas para a aplicação, no entanto este é complexo e não possui foruns de
ajuda e documentos suficientes para que esta hipótese fosse estudada mais
seriamente.
3.4. AvisMap GIS Engine
O AvisMap GIS Engine é uma plataforma de desenvolvimento de GIS que
se baseia em controlos activeX. As aplicações criadas nesta plataforma
permitem que as suas distribuições possam ser instaladas nas máquinas dos
clientes sem que estes possuam o GIS Engine.
Esta plataforma possui bastantes capacidades, e deve ser analisada muito
sériamente se se pretender implementar um GIS mais complexo e que requeira
funcionalidades abaixo descritas:
• Visualização e edição de mapas complexos – com
manuseamento de elementos 3D, projecção dinamica, conversor
de dados vectoriais para matriciais e vice-versa, entre outras
funcionalidades;
• Criação de mapas temáticos – organizados por valores, por
segmentos, por simbolos, onde é possível visualizar gráficos 3D
para uma melhor percepção dos dados envolvidos;
• Análise e processamente topológico – permite que seja feita a
remoção de dados redundantes, nomeadamente vertices, linhas e
polígonos, assim como juntar nós adjacentes e construir
polígonos;
• Funções de análise espaciais – modelação 3D, operações
algébricas matriciais, de análise hidrológicas, entre outras;
Esta ferramenta possui bastantes funcionalidades, que vão auxiliar o
desenvolvimento de um GIS mais complexo do que aquele que é necessário
para a concretização deste projecto.
O principal aspecto contra é o facto de ser necessário efectuar pagamento
para possuir uma licença de utilização do software, pelo que neste contexto
torna muito dificil a realização deste projecto sobre esta ferramenta.
3.5. Quantum GIS
O Quantum GIS é um GIS de código aberto extensível e flexível, o que
significa que se podem criar plug-ins para adicionar à aplicação e também
possibilita a costumização desta através da programação de novas ou tarefas
mais especializadas.
Esta aplicação, de base não possui nenhuma capacidade diferenciadora
dos comuns GIS, no entanto consegue ser bastante abrangente pois suporta
inúmeros tipos de formato de dados para análise geográfica.
O Quantum GIS é mantido e actualizado por programadores voluntários de
todo o mundo, fazendo com que o suporte e mecanismos de ajuda à aplicação
sejam melhores que muitas aplicações livres existentes.
Apesar das funcionalidades base não se distinguirem dos GIS de software
livre comuns, a sua extensibilidade e plug-ins já disponíveis faz com que esta
se torne numa ferramenta a ter em conta no desenvolvimento de um GIS.
3.6. Comparativo
Ilustração 11 - Tabela comparativa de Ferramentas GIS
4. Arquitectura proposta
Neste capitulo iremos apresentar uma arquitectura possivél para integrar
um servidor OLAP e um Servidor GIS, iremos falar individualmente primeiro da
integraçado do servidor OLAP depois do Servidor GIS e finalmente como
integrar os dois servidores.
Estrutura do OLAP
Como visto anteriormente a interacção de um cliente com o servidor
OLAP é feita por meio de uma requisição do cliente, através de uma consulta
MDX. A resposta do servidor é feita através de um arquivo XMLA, que
comunica através do protocolo SOAP, que por sua vez utiliza o protocolo HTTP
para realizar a comunicação.
Como podemos observar na figura a arquitetura OLAP mais comumente
utilizada pode ser dividida em três estruturas:
1. SGBD, onde encontramos o banco de dados transacional e o data
warehouse, gerado a partir do processo de ETL Extract,Transform e
o Load dos dados, da BD transacional para a Camada de Dados;
2. Servidor OLAP. Camada de processamento;
3. Servidor de Interface OLAP. Camada de interface;
Ilustração 12 - Arquitectura do OLAP
Estrutura do GIS
Uma arquitectura tíıpica de GIS tem no mínimo duas estruturas: Um GIS
e o repositório de dados GIS. Lembrando que esse GIS pode assumir várias
formas, desde aplicações desktop a servidores web.Os dados desse GIS
podem estar tanto em formato vectorial quanto matricial, integrados em uma
única base ou separados em vários arquivos.
Na figura abaixo podemos perceber claramente esta arquitetura, o
servidor de mapas buscando informações no repositório de dados e enviando-
os aos usuários.
Ilustração 13 - Arquitectura do GIS
Arquitetura Gerada
Analisando os padrões e protocolos utilizados pelo servidor OLAP
podemos notar que a comunicação é feita via serviços web. Sendo assim, não
seria problema nenhum para o servidor de interface realizar mais uma
chamada, mas desta vez ao GIS, se este se mostrar na forma de um servidor.
Iremos agora demonstar como é que se vai dar o fluxo de informação
nesta arquitectura, esse fluxo encontra se demonstrado na figura abaixo:
Ilustração 14 - Arquitectura integrada
Assim, podemos definir uma sequência de eventos para gerar um mapa
relativo à pesquisa no OLAP:
1. Interação do usuário com a interface, selecionando um drill-down de alguma
dimensão;
2. O servidor de interface solicita ao servidor OLAP o drill-down a ser
executado, através de um comando MDX;
3. Ao receber o MDX, o servidor OLAP realiza as consultas necess´arias no
DW, retornando os dados dessa visão do cubo em XMLA;
4. Ao receber o XMLA, o servidor de interface vai gerar a visualização dos
dados. E também faz uma requisição ao servidor de mapas, enviando este
arquivo XMLA, juntamente com o foco desejado.
5. O servidor de mapas por sua vez, explora o arquivo XMLA, recolhendo as
informações necessárias para a geração do mapa.
6. Com os dados recolhidos, o servidor de mapas associa-os com os
respectivos dados geográficos, gerando o mapa, que é enviado ao servidor de
interface;
7. Por fim o servidor de interface devolve o mapa gerado ao utilizador com as
as informaçoes por este solcitada.
5. Implementação
5.1. SQL Server 2005
Os dados utilizados para a realização deste projecto são
provenientes das fichas de inscrição do vestibular da UFSC do ano
de 2006. Pelo o que pudemos apurar serão apenas considerados
os candidatos que realizaram todas as provas, ou seja que não
faltaram a nenhum dia de prova.
Esta ficha de inscrição do candidato contém informações
relacionadas com questões socio-económicos e demográficas, tais
como raça, estado civil, idade, sexo, etc. A tabela curso tem
informações de qual o nome do curso, a area escolhida e qual e o
centro a que esse curso está associado por fim temos uma tabela
chamada disciplinaprova, esta tabela tem informações sobre as
disciplinas de cada area.
O Data Warehouse que iremos utilizar foi desenvolvido por
Felipe Shigunov no seu trabalho de conclusão de curso, então nós
iremos aproveitar o trabalho por ele realiazado e aplicá-lo ao nosso
projecto.
Para a geração de um Data Warehouse, os dados devem passar
por um processo de ETL(extract,transform , load) isto devido aos
dados virem de diversas fontes, para não correr o risco de haver
redundancia nos dados este e um processo fundamental.
O processo de ETL realizado por felipe Shigunov foi feito por
meio de uma aplicação escrita em java com SQL embutido via
JDBC.Uma consulta SQL à base de dados da comissão
Permanentedos Vestibular (COPERVE), retorna todos os campos
desejados para DW.
Então é feita a carga total das tabelas localizadas em um banco
de dados MySQL que constitui o repositório de dados da DW, de
acordo com o esquema ilustrado na figra abaixo
Ilustração 15 - Esquema de dados
Agora com o DW pronto o próximo passo é instalar o nosso
servidor OLAP, a ferramenta escolhida para este serviço foi SQL
Server 2005 uma ferramenta de BI da Microsoft. Sendo uma
ferramenta da Microsoft ñao se obtém gratuitamente então para
conseguirmos ter acesso a esta aplicação foi necessário utilizar a
licenca que a universidade tem com a microsoft. O SQL Server
possui um conjunto de ferramentas que facilitam a implementação
de soluções para apoios a decisões, tem uma grande flexiblidade e
uma grande segurança, possui um servidor e uma interface OLAP,
e possivel efectuar Data Mining e a geração de relatórios.
A instalação foi bastante simples e quase automatica, visto
que nos neste projecto utilizamos na maioria programas da
Microsoft então não tivemos grandes problemas de adpatação ou
de conflito entre os varios programas. Fomos a pagina da nossa
universidade de Lisboa o ISCTE (http://msdnaa.dcti.iscte.pt) e
fizemos o download do SQL Server. Corremos o programa e
tinhamos o Servidor na nossa máquina.
No projectos de BI o SQL Server possui uma ferramenta
chamada Analysis Service esta ferramenta é de uma utilidade muito
grande, foi com ela que criamos o cubo.
Criamos um projecto Analysis Service, esta ferramenta tem um
conjunto de wizards que ajudam a criar o cubo.
O processo de criação do cubo pode ser explicado em 4 passos:
1. Criar a Data Source do Cubo ou seja neste passo temos de
identicar a fonte proveniente dos dados e estabelecer a
ligação com esses mesmo dados, o que fizemos foi carregar
uma base de dados relacional no SQL com os dados da base
de dados que o Shigunov nos deu, ou seja fizemos um Import
dos dados para essa base de dados relacional e
posteriormente criamos uma ligação entre o DataSouce do
cubo e essa mesma tabela.
2. Criar o Data View do cubo ou seja neste passo temos de
identifcar como e que as tabelas se vao relacionar entre si,
identificar quais as tabelas que são factos e dimensões e
como estão organizadas e finalmente identificar as hieraquias.
No nosso projecto temos uma hierarquia que o caso da
Estado Endereco -> Cidade Endereco.
3. Criar as Dimensões ou seja neste passo temos de identifcar
quais as dimensões,a chave primária dela e cria-las.
4. Criar o Cubo este é o ultimo passo finalmente pegamos nos
dados todos criados anteriormente e criamos o cubo.
Após criar o cubo fazemos o deployment deste e estamos pronto
a efectuar todas as queries que assim desejamos, esta ferramenta
é muito util pois permite queries muito flexiveis, e retirar uma grande
número de conclusões.
Uma vez que agora temos o nosso Servidor OLAP e temos o
nosso cubo temos de conseguir que o utilizador tenha acesso a ele,
entao criamos o nosso WebSite e através de objecto de
comunicação do Analysis Service chamado Adomd estabelecemos
a ligação o nosso cubo.
Para conseguirmos utilizar este objecto de ligação tivemos de fazer
um import de uma bilblioteca de dados:
using Microsoft.AnalysisServices.AdomdClient;
Um documento de extrema importancia em qualquer projecto
de webService é o WebConfig, que é um documento XML em que é
detalhada a forma de como a comunicação vai ser feita, no :NET
esse ficheiro é criado automaticamente assim o utilizador não tem
de se preocupar com isso.Em baixo mostramos o conteúdo desse
mesmo ficheiro.
<?xml version="1.0"?>
<configuration>
<appSettings/>
<connectionStrings>
<add name="Ligacao BD UFSC_v1.0"
connectionString="Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:\Documents
and Settings\Nuno\Desktop\UFSC\tcc_felipe.mdb"
providerName="System.Data.OleDb"/>
<add name="UFSC DWConnectionString" connectionString="Data
Source=localhost;Initial Catalog="UFSC DW";Integrated
Security=True" providerName="System.Data.SqlClient"/>
</connectionStrings>
</configuration>
A ligação foi efectuada da seguinte maneira:
public DataSet getRelatorio(String dimensao1_,String atributo_dimensao1_, String
dimensao2_,String atributo_dimensao2_,String dimensao3_, String
atributo_dimensao3_,String facto_)
{
String dimensao1 = dimensao1_;
String dimensao2 = dimensao2_;
String dimensao3 = dimensao3_;
String atributo_dimensao1 = atributo_dimensao1_;
String atributo_dimensao2 = atributo_dimensao2_;
String atributo_dimensao3 = atributo_dimensao3_;
String facto = facto_;
DataSet data_set = new DataSet();
AdomdDataAdapter data_adapter;
AdomdConnection conn1;
conn1 = new AdomdConnection("Provider=SQLNCLI.1;Data
Source=localhost;Integrated Security=SSPI;Initial Catalog=Analysis Services UFSC
DW");
data_adapter = new AdomdDataAdapter("SELECT NON EMPTY {
[Measures].["+facto+"] } ON COLUMNS, NON EMPTY
{((DISTINCT(["+dimensao1+"].["+atributo_dimensao1+"].["+atributo_dimensao1+
"])) *
["+dimensao2+"].["+atributo_dimensao2+"].["+atributo_dimensao2+"].ALLMEMB
ERS *
["+dimensao3+"].["+atributo_dimensao3+"].["+atributo_dimensao3+"].ALLMEMB
ERS ) } DIMENSION PROPERTIES MEMBER_CAPTION,
MEMBER_UNIQUE_NAME ON ROWS FROM [UFSC DW]", conn1);
data_adapter.Fill(data_set,"Measures");
return data_set;
}
Neste caso estamos a efectuar uma ligação cubo e
efectuamos uma querie MDX para retornar o numero de elementos
das dimensões que o utilizador escolheu. Nós utilizamos queries
MDX para fazer perguntas e a resposta é nos dada em XMLA.
Neste projecto nós tentamos colocar uma interface que fosse
mais adequada para ver as queries que eram efectuadas, tentámos
desde colocar o Analysis Service on line, mas não fomos bem
sucedidos, tentámos através do excel colocar o resultado na net
mas também não fomos bem sucedidos pois o web browser não
suporta ficheiro do office e a única maneira de conseguirmos
colocar esses ficheiros do office era através de uma plataforma
chamada SharePoint mas para ter acesso a essa plataforma era
nécessário uma licensa, algo que não tinhamos. Assim criamos a
nossa própria interface.
5.2. MapWindow
Conforme foi descrito atrás, optámos pelo MapWindow ActiveX
component para a criação do nosso GIS. Para a implementação da aplicação,
foi necessário recorrer ao API desta solução disponível através de dois
arquivos .DLL (Dynamic Link Library):
• AxInterop.MapWinGIS.dll – responsável pela manipulação do
componente de ActiveX;
• Interop.MapWinGIS.dll – que possui os componentes necessários
para a criação do GIS.
Os dados geográficos sobre os quais vamos trabalhar a informação
proveniente do DataWarehouse foram retirados do Instituto Brasileiro de
Geografia e Estatística (IBGE) e encontram-se no formato ESRI Shapefile.
O desenvolvimento deste projecto tinha como referência ser elaborado
para o ambiente Web, pelo que foi desenvolvido um WebService baseado no
MapWindow que possui duas grandes funcionalidades para responder ao
desafio colocado:
• Gerar mapas
• Servir mapas
5.2.1. Gerar mapas A aplicação por nós desenvolvida materializa-se numa janela aplicativa que
está situada na máquina em que o WebService está presente e é nesta mesma
janela que o componente ActiveX atrás referido gera os mapas que são
requisitados.
O pedido de geração do mapa escolhido pelo utilizador chega à aplicação
através de um DataSet que contém uma tabela com a referência geográfica a
ser representada e os valores respectivos de cada uma. Cada mapa pedido
terá um ficheiro shape associado cuja aplicação tem guardado numa pasta
predefinida. Para que se saiba qual o ficheiro shape que vai ser modificado
convencionou-se que a primeira coluna da primeira linha teria o nome
hierarquicamente acima do mapa que se quer mostrar, ou seja:
1) Nome do país – mostra o país dividido pelos estados;
2) Nome do estado – mostra os municipios do estado escolhido.
Para melhor percepção ver Anexo I.
Assim torna-se facil saber qual o ficheiro a ir buscar, conforme o excerto de
código o demonstra:
String nome = tabelaResultadoDaQuery.Rows[0][0].ToString(); String[] ficheiros = System.IO.Directory.GetFiles("C:\\Folder"); for (int i = 0; i < ficheiros.Length; ++i) { if (ficheiros[i].Contains(nome) && ficheiros[i].Contains("shp")) return ficheiros[i]; }
Com o nome do ficheiro devolvido sabe-se agora qual a camada sobre a
qual se vão trabalhar os dados e assim sendo adiciona-se a mesma ao mapa já
existente no componente do MapWindow.
A informação existente no shapefile vai ser armazenada localmente
numa tabela na qual vai ser adicionada uma coluna com os valores
provenientes do DataSet enviado pelo cliente, para facilitar a manipulação da
informação.
É possível agora preencher os polígonos com a cor estipulada para cada
valor, conforme o excerto de código abaixo demonstra:
UInt32 corBase; UInt32 corParaValorNulo =
Convert.ToUInt32(System.Drawing.ColorTranslator.ToOle(System.Drawing.Color.White));
UInt32 corEfectiva; for (int i = 0; i < tabelaShapeFile.Rows.Count;
++i) { corBase =
Convert.ToUInt32(System.Drawing.ColorTranslator.ToOle(System.Drawing.Color.Navy));
if
(System.Convert.ToInt32(tabelaShapeFile.Rows[i]["Valores"]) > 0)
corEfectiva = corAInserir(corBase, (uint)System.Convert.ToInt32(tabelaShapeFile.Rows[i]["Valores"]), 5);
else corEfectiva = corParaValorNulo; mapa.set_ShapeFillColor(0, i,
(uint)(corEfectiva)); }
O método corAInserir atribui a cor através da criação de vários intervalos de
valores, isto é, divide o valor máximo existente na tabela pelo número desejado
de níveis que o utilizador pretende. Consoante o valor de cada polígono é
criada uma variação da corBase e inserida no polígono.
Após esta tarefa, o mapa está concluido e é passível de ser mostrado no
lado do servidor.
5.2.2. Servir mapas Outra funcionalidade da nossa aplicação é o facto desta executar o papel
de um servidor de mapas, visto que responde a um pedido com um mapa.
Para proceder ao envio do mapa que foi gerado, este output é gravado no
lado do servidor como uma imagem bitmap (.bmp), e posteriormente enviada
para o cliente neste formato, para que possa ser mostrado no browser do lado
do cliente.
6. Trabalhos relacionados
Na Universidade Federal de Santa Catarina, o estudo da integração de
ferramentas OLAP com GIS tem sido levado com muita seriedade, e prova
disso são os trabalhos que onde este tema já foi abordado:
• “Uma Aplicação OLAP sobre a Web para Análise dos Dados do
Vestibular da UFSC e Diretrizes para a sua Integração com GIS”
realizada por Felipe Shigunov [17], onde é dado mais ênfase ao aspecto
OLAP, mas onde também são feitos estudos voltados para a integração
OLAP e GIS.
• “Desenvolvendo um Middleware para a Integração de Servidores OLAP
e Servidores de Mapa na Web” realizado por Carlos Costa e José Neis,
onde “foi definida uma arquitectura aberta que combina componentes de
mercado usando um middleware baseado em padrões de sistemas
abertos das áreas de OLAP e SIG para realizar a ligação entre as duas
tecnologias”[25].
• “Visualização cartográfica de informação acoplada a processamento
analítico on-line” realizado por Ricardo Gross[26]
7. Conclusões e trabalhos futuros
Apesar de o conceito de GIS já ser antigo, só há relativamente pouco tempo
se teve a percepção que esta vertente de sistemas de informação poderia ter
uma grande importância nas áreas de negócio, pois estas têm constantemente
dados geográficos que necessitam de ser analisados.
O trabalho descrito neste documento pretende fazer a integração entre as
áreas de negócio e geográficas, culminando com a criação de uma solução
baseada numa arquitectura em ambiente Web que permite a comunicação
entre um Data Warehouse e o GIS através de XMLA.
O protótipo criado permite a realização de queries OLAP na Web e
visualização de mapas de acordo com a escolha do utilizador nesse mesmo
ambiente. Torna-se uma ferramenta muito poderosa pois é possível visualizar a
informação de qualquer lado e em qualquer hora.
Apesar da geração de mapas através de queries OLAP já ser algo comum,
é no entanto incomum ver duas componentes construidas separadamente, i.e.
as componentes OLAP e de mapasserem independentes uma da outra. Este
protótipo tem essa grande vantagem, possuir uma ferramenta geradora de
mapas que trabalha com uma linguagem standart – o XMLA, para aceitar
informação proveniente de qualquer tipo de banco de dados multidimensional.
Apesar desta ferramenta estar ainda em fase de prototipagem,
consideramos que tem óptimo potencial comercial, pela sua flexibilidade e
capacidades.
Como trabalhos futuros, consideramos útil a criaçãode uma interface que
permita ao utilizador manipular a imagem do mapa que está presente no web
browser como fazer zoom in, zoom out, seleccionar áreas do mapapara
visualizar informação, ou seja, como se de uma aplicação desktop se tratasse,
para dar mais liberdade ao utilizador.
Referências bibliográficas
[1] Professora Maria José Trigueiros: Acetatos de Sistemas de Apoio à
Decisão, Business Inteligence, ISCTE 2006
[2] Wikipedia. Business Inteligence: Disponível em
http://pt.wikipedia.org/wiki/ Business_Inteligence
[3] Wikipedia. Business Inteligence: Disponível em
http://pt.wikipedia.org/wiki/OLAP
[4] Professora Maria José Trigueiros: Acetatos de Sistemas de Apoio à
Decisão, OLAP, ISCTE 2006
[5] Virtual Earth Home: www. msdn.microsoft.com/mapPoint, acedido em
2007
[6] Microsoft SQL Server. Microsoft SQL Server official home page,
http://www.Microsoft.com/sql/default.mpx, Acesso em Setembro de
2007
[7] Cyntia Aurora Moura Anozelo: Acetatos OLAP conceito e sua
Aplicação, 2004
[8] Wikipedia. Business Inteligence: Disponível em
http://pt.wikipedia.org/wiki/XML
[9] Professora Maria José Trigueiros: Acetatos de Sistemas de Apoio à
Decisão, XML, ISCTE 2006
[10] XMLA, XML for Analysis, ODBO, OLE DB for OLAP, XMLA
provider, bridge,server. XMLA official home page,
http://www.xmla.org/, Acesso em Setembro de 2007.
[11] Professor Henrique O’neill: Acetatos de Sistemas Decisão, MDX,
ISCTE 2006
[12] Wikipedia. Business Inteligence: Disponível em
http://pt.wikipedia.org/wiki/MDX
[13] Introduction to Multidimensional Expressions,
http://tecnet.microsoft.com/Library /MDX, Acesso em Setembro de
2007
[14] Professora Elsa Cardoso: Acetatos de Sistemas de Apoio à
Decisão, Data Warehouse, ISCTE 2006
[15] Wikipedia. Data WareHouse: Disponível em
http://pt.wikipedia.org/wiki/ Data_warehouse
[16] Acetatos de Data WareHouse: DBQ Consultant, acedido em
Setembro de 2007
[17] Felipe Shigunov: Trabalho de Conclusão de Curso numa
Aplicação OLAP sobre a web para análise dos dados dos
vestibulares da UFSC e directrizes para a sua integração com o GIS.
[18] Professora Maria José Trigueiros: Acetatos de Sistemas de Apoio
à Decisão, ETL, ISCTE 2006
[19] Wikipedia.Modelo Dimensional: Disponível em
http://pt.wikipedia.org/wiki/ Modelo_dimensional
[20] Professor José Cordeiro Gomes: Acetatos de Sistemas de
Informação de Gestão, Modelos Dimensionais, ISCTE 2005
[21] What is GIS?, www.Gis.com, acedido em Setembro de 2007
[22] Wikipedia.Geografic Information Systems: Disponível em
http://pt.wikipedia.org/wiki/ Geografic_Information_Systems
[23] MapPoint: MapPoint official home page,
www.Microsoft.com/MapPoint/default.mpsx , Acesso em Setembro de
2007.
[24] Wikipedia.MapPoint: Disponível em http:// pt.wikipedia.org/wiki/
MapPoint
[25] C. Costa; J. Neis: Desenvolvendo um Middleware para Integração
de servidores OLAP e Servidores de Mapa na Web. Universidade
Federal de Santa Catarina, Florianópolis, 2007
[26] Ricardo Gross: Visualização cartográfica de informação acoplada
a processamento analítico on-line. Universidade Federal de Santa
Catarina, Florianópolis, 2007
[27] Instituto Brasileiro de geografia e estatística,
http://www.ibge.gov.br/ acessado em Setembro de 2007
Anexo I
No caso do utilizador pretenda visualizar os dados ao nível estadual do
Brasil, conforme a Ilustração 16 representa, então a primeira coluna da primeira
linha da tabela do utilizador terá que ter o valor “Brasil”;
Ilustração 16 - Resultado de uma query por estado
Outra das opções que o utilizador tem é efectuar uma consulta por
estado, isto é, pode escolher visualizar a informação por municipios dentro do
estado seleccionado. Neste caso o valor da primeira coluna da primeira linha
da tabela enviada pelo cliente terá o nome do estado seleccionado. No caso do
utilizador pretender visualizar os municipios dados somente para o estado de
Santa Catarina, a primeira coluna da primeira linha terá o valor “Santa
Catarina”.
Anexo II – Glossário
Atributo: Representa um único tipo de informação numa dimensão.
Bases de Dados Operacionais: Trata-se de um armazém de dados
correntes orientado a objectos, integrado e volátil, contendo apenas dados
detalhados e incorporados.
Business Intelligence: Trata-se da área de conhecimento onde actual os
sistemas desenhados para ajudar as empresas a entender como os seus
negócios funcionam e a predizer o impacto das decisões tomadas.
Data Mart: Trata-se de um subconjunto de um DW e é geralemente
referente a um departamento da organização.
Data Staging Area: Área de retenção, prepara os dados para serem
carregados no data warehouse. Não se fazem queries a estes dados. A
informação pode ser guardada em base de dados ou ficheiros.
Data Warehouse: Trata-se de uma infra-estrutura que permite integrar os
dados de uma empresa de forma ter uma visão histórica e não volátil da própria
empresa. Serve assim como um repositório de dados para muitos tipos de
informação de negócio vinda de muitas fontes. A informação destas fontes é
transferida para o DW para acesso mais fácil, e depois é indexada e
combinada para um acesso mais rápido.
Data Warehousing: Processo de desenhar construir e manter um sistemas
de data warehouse.
Densidade da Inteligência: Trata-se da quantidade de informação de
suporte à decisão necessária para um decisor conseguir retirar conclusões a
partir de uma ferramenta, durante um determinado período de tempo.
Dimensão: Área de negócio pela qual se que analisar o negócio
Drill-Across: Trata-se da análise de dados através das dimensões.
Drill-Down: Trata-se da análise de dados a um atributo filho.
Drill-Through: Trata-se da análise de dados que vai desde um cubo OLAP
ate a base de dados relacional.
Drill-Up: Trata-se da análise de dados a um atributo pai.
ETL: As ferramentas de ETL têm como função agregar informação de
várias fontes e produzir informação integra e de qualidade, ou seja, sem erros,
sem duplicações, sem omissões e sem diversificações. Desta forma começa-se
por ser feita a extracção dos dados, seguindo-se a transformação que se divide
em duas fases, limpeza e conciliação dos dados, e por fim é feito o
carregamento na DW.
Facto: Variável mensurável do negócio.
Galáxia: Trata-se de uma mistura, tendo vários star schema e snowflake
schema.
Granularidade: Representa o detalhe.
Hierarquia: Uma hierarquia define o caminho para fazer drill up, drill down.
Todos os atributos de uma hierarquia pertencem à mesma dimensão.
HOLAP: São sistemas híbridos, sendo uma mistura de potencialidades dos
ROLAP e MOLAP.
Meta-Informação: Trata-se da informação sobre os dados que descrevem
a forma como os conceitos do negócio foram representados.
Metadados: São considerados como sendo "dado sobre dado" ou dado
sobre os sistemas que operam com estes dados, ou seja, não serve para
descrever o conteúdo mas sim o contexto da informação. São portanto um
directório para ajudar o analista de DSS a localizar os dados num DW, um guia
para o manuseamento de dados, como os dados são transformados do
ambiente operacional para o ambiente de DW, e também um guia para os
algoritmos usados para sumarização entre os dados detalhados actuais, os
dados ligeiramente resumidos e os dados altamente resumidos.
Métricas aditivas: São métricas que quando agregadas não perdem valor.
Métrica Composta/Agregada: São métricas compostas a partir de
métricas elementares.
Métrica Simples: Medidas elementares do facto.
Modelo Dimensional: Trata-se de uma disciplina especifica para modelizar
dados.
MOLAP: São OLAP multidimensional. Sendo que estes sistemas guardam
dados em cubos multidimensionais(n-dimensionais).
OLAP: Trata-se de um software de suporte à decisão, que permite ao
utilizador analisar rapidamente a informação que foi sumariada em hierarquias
e pontos de vista multidimensionais.
OLTP: Tratam-se de sistemas muito bons para armazenar informações em
Base de Dados de uma forma rápida, eficiente e com segurança, no entanto
não suportam de uma forma eficiente a extracção e análise qualitativa de
informação.
Query: Trata-se de uma ferramenta de software que permite ao utilizador
efectuar perguntas específicas a uma base de dados, conseguindo assim a
informação desejada sobre a uma determinada questão. Posteriormente será
feita Elaboração de relatórios com os resultados retirados da informação
existente nos Data Marts.
ROLAP: OLAP relacional. Tratam-se de sistemas que guardam dados
numa base de dados relacional.
Sistemas de Apoio à Decisão: Tratam-se de sistemas mais complexos
que permitem o acesso total a base de dados corporativas, modelação de
problemas, simulações e possuem uma interface amigável. Para além disso
ajudam o executivo em todas as fases do processo de tomada de decisão,
principalmente nas etapas de desenvolvimento, comparação e classificação
dos ricos, para além de fornecer subsídios para a escolha de uma boa
alternativa.
Snow Flake Schema: No snowflake schema as hierarquias diferentes de
uma dimensão podem ser estendidas para as suas próprias tabelas de
dimensão.
Star Schema: No Star Schema cada dimensão é representada por uma
única tabela de dimensão.
Tabela de Dimensões: Trata-se de uma tabela que guarda registos
relacionados com uma dada dimensão.
Tabela de Factos: Trata-se de uma tabela que inclui dois tipos de colunas:
colunas de factos, e chaves primárias para as dimensões.
Anexo III – Acrónimos
BI – Business Intelligence
CAD – Computer Aided Design
DDL – Data Definition Language
DLL – Dynamic Link Library
DSS – Decision Support System
DW – Data Warehouse
GIS – Geographic Information System
MDX – Multidimensional Expressions
SGBD – Sistema de gestão de Base de Dados
SQL – Structured Query Language
