Universidade Federal de Santa Catarina

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 metadados 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:

<?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. 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]

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.

<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> 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

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 enviandoos 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