Entendendo os Data Warehouses Espaciais – Parte 2

Continuação do artigo enfoca o processo de implementação do SDW para a criação de conhecimento em negócios

Na InfoGEO 35 procuramos apresentar os conceitos de um Data Warehouse Espacial (Spatial Data Warehouse ou SDW) e demonstrar seus benefícios para as organizações no ambiente de negócios. Desta vez discutiremos como implementar um SDW, para a criação de conhecimento para o negócio.

As diferenças entre um SDW e uma simples integração entre GIS e DW (conforme analisamos na InfoGEO 24) residem no conhecimento geográfico. Um SDW que utiliza a dimensão geográfica nas análises OLAP (ou Spatial OLAP) é de alta complexidade e remete a uma outra abordagem (mais ligada ao Spatial Data Mining, que já discutimos outras vezes). Nosso foco neste artigo está na utilização de informações geográficas para auxílio a geração de conhecimento (geralmente não geográfico) para apoio a tomada de decisão no mundo empresarial.

Conceitualmente, os Data Warehouses não seguem os modelos relacionais tradicionais. Eventos do mundo real são "fatos", descritos e caracterizados em suas diversas "dimensões". As estruturas de análise são multi-dimensionais – os famosos "cubos". A quantidade de dimensões e como elas se combinam fazem parte do projeto e do modelo dos DWs. Quando estamos implementando um SDW, vários aspectos devem ser considerados: Dimensões, Fatos, Hierarquias e Agregações, Usabilidade e Aquisição de Dados, entre outros.

As Dimensões podem ser não espaciais (sem atributos espaciais), ou espaciais (com atributos espaciais e não espaciais). Vale notar que o modelo permite múltiplas representações espaciais para um mesmo objeto (p.e., endereço residencial e comercial, ou ponto [endereço] e polígono [planta baixa da edificação]). Bancos de Dados relacionais de mercado já possuem extensões para armazenar objetos geográficos.

Fatos espaciais são de implementação complexa. Para simplificar o processo, sugere-se a criação de uma dimensão espacial e apenas fatos numéricos (referenciando tal dimensão). Dessa forma, os SDW na nossa abordagem representarão informações geográficas apenas nas tabelas de dimensão.

Porém, o maior desafio está no esforço de processamento e armazenamento de dados para a Agregação espacial. A solução para os Fatos espaciais utiliza mecanismos profundamente estudados nos DWs convencionais, o que facilita o processo. Em um DW espacial toda a Hierarquia pode ser representada por objetos geográficos ou parte dessa hierarquia pode ser representada apenas por atributos descritivos.

Ao observar a natureza das informações geográficas pertinentes à análise para tomada de decisão em um DW espacial, é possível perceber que algumas são inerentes aos objetos do negócio, tais como localização de ponto de vendas, endereço de cliente e local do acidente, por exemplo. Por outro lado, outras informações geográficas formam o contexto de análise, tais como infra-estrutura viária, pontos relevantes (portos, aeroportos, shopping centers e muitos outros conforme o negócio e os propósitos do DW espacial), infra-estrutura de serviços, entre outros.

Quando o DW espacial avança para informações do ambiente externo, a localização dos concorrentes, perfil do público alvo por região e muitas outras podem ser georeferenciadas. Conforme a abrangência das informações e objetivos do DW espacial, a localização dos concorrentes, por exemplo, pode ser tratada como uma Informação de Negócio ou um Dado de Contexto para as análises.

Informações geopolíticas como limites dos municípios e estados podem ser tratadas como informações de negócio quando as hierarquias das dimensões espaciais são também georeferenciadas (dimensões espacial para espacial) ou como informações de contexto quando essas hierarquias são apenas descritivas (dimensão espacial para não espacial).

A percepção de quais informações geográficas formam o contexto e quais são objetos do negócio é fundamental para viabilizar a modelagem do DW espacial, uma vez que as informações de contexto não precisam ser representadas no modelo dimensional. Assim, podemos tratar as informações de contexto como uma camada temática (layer) em um mapa, para contextualizar, de fato, as análises e também servir de predicado para consultas com base em operadores espaciais.

Disponibilizar as funcionalidades OLAP e GIS de forma integrada e amigável é preponderante para o sucesso da implementação de um DW espacial – a Usabilidade é fundamental. Três caminhos distintos podem ser trilhados na implementação. É possível agregar nas ferramentas OLAP funcionalidades GIS, agregar funcionalidades OLAP nas ferramentas GIS ou desenvolver camadas de mediação para integrar as duas ferramentas distintas.

Considerando que a proposta é utilizar a informação geográfica na criação de conhecimento na organização, as funcionalidades analíticas e estatísticas das ferramentas OLAP parecem preponderantes. Sendo assim, agregar funcionalidades GIS a estas ferramentas se apresenta como a solução mais adequada para oferecer um ambiente amigável para o usuário em sistemas cuja motivação é apoiar a tomada de decisão gerencial e estratégica.

É de se supor que ferramentas OLAP implementem apenas parte dos recursos de análise espacial disponíveis nas ferramentas GIS. Nos casos em que a demanda por análise espacial exigir recursos não disponíveis nas ferramentas OLAP estendidas, as soluções específicas podem ser implementadas através de ferramentas GIS ou utilizando camada de mediação para integrar as ferramentas.

Se a alternativa de desenvolver uma camada de mediação para integrar as duas ferramentas (OLAP e GIS) demanda maior esforço de desenvolvimento, por outro lado, a organização não depende da implementação de funcionalidades de análise espacial nas ferramentas OLAP adotadas. Quanto maior a demanda por análises sofisticadas envolvendo as informações geográficas, mais interessante se torna criar uma camada de mediação. Em organizações que já possuem ambientes DW e GIS operando em separado essa alternativa torna-se mais atraente, pois visa aproveitar e integrar o esforço já despendido no desenvolvimento das duas soluções inicialmente isoladas.

A Aquisição de Dados é uma atividade delicada e de alto custo tanto no ambiente DW convencional quanto no ambiente GIS. A atividade de projeto e desenvolvimento dos programas ETL para extração dos dados convencionais dos sistemas transacionais da organização, bem como transformação e carga destes no DW, não sofre qualquer alteração em um DW espacial em relação ao processo de data warehousing convencional.

Por outro lado, a aquisição dos dados georeferenciados pode ser conduzida por três caminhos distintos, que podem também ser usados em conjunto: (i) Aquisição de dados geográficos especificamente para o DW espacial; (ii) Projeto e desenvolvimento de programas ETL específicos para carga dos dados espaciais (provenientes das bases GIS existentes) no DW espacial e (iii) Integração dos cubos do DW com os dados espaciais existentes no GIS, usando a própria base de dados espaciais dos sistemas transacionais.

Para organizações que não utilizam nenhum sistema de informação georeferenciado, somente a primeira alternativa é viável. Ao considerar os custos usuais de aquisição de dados geográficos, esse caminho pode ser considerado economicamente inviável. Porém, é preciso analisar qual nível de precisão e detalhamento faz-se necessário, tanto para os dados geográficos do negócio quanto de contexto.

Nem todas as aplicações requerem a mesma qualidade de dados para o seu processamento. Parece claro que, para a grande maioria das organizações, uma análise gerencial georeferenciada não demanda informações precisas e mapas detalhados. Por exemplo, endereços de clientes e pontos de venda podem ser obtidos a partir do CEP – os mapas das cidades podem não representar arruamento. Dessa forma o custo de aquisição dos dados geográficos é reduzido, pois tais dados estão disponíveis muitas vezes de forma gratuita sem qualquer perda sob o ponto de vista da qualidade das análises gerenciais.

Para organizações como as indústrias de telecomunicações e Utilities, que demandam análises gerenciais com dados geográficos mais precisos, esta abordagem não é válida para alguns tipos de dados geográficos necessários, como, por exemplo, cabos (ou tubos) e localização de clientes. Porém, essas empresas possuem, em geral, tradição no uso de GIS em suas aplicações operacionais, o que permite o uso das outras alternativas consideradas.

Para organizações que já dispõe de base de dados geográficos é possível projetar e desenvolver programas que extraiam os dados espaciais destas bases, transformem esses dados de acordo com as necessidades dos sistemas de apoio a decisão gerencial e carreguem-os no DW espacial. Esta abordagem permite resolver a questão da integração de dados geográficos de fontes heterogêneas. O processo ETL pode solucionar problemas encontrados nos dados espaciais como: restrições topológicas, múltiplas representações, escalas diferentes, precisão espacial, adequação do objeto geométrico para os diferentes níveis de granularidade, entre outros.

A terceira alternativa se apresenta interessante para os casos em que a opção envolve uma camada mediadora para acesso as aplicações DW e GIS antes isoladas. Este caminho pode ser usado para acesso aos dados geográficos de contexto, porém, dada a provável grande quantidade e variedade de mapas e representações, pode ser um fator de complexidade desnecessária, prejudicando a usabilidade do DW espacial. As duas últimas alternativas apresentadas serão, em geral, complementadas pela primeira alternativa, uma vez que diversos objetos espaciais relevantes para análises gerenciais, provavelmente, não estarão disponíveis nas aplicações georeferenciadas operacionais.

Com toda a discussão acima é possível perceber a viabilidade da implementação de sistemas de apoio à decisão gerencial e estratégica baseados em DWs espaciais. Considerando o potencial de benefícios apresentados no artigo anterior, fica claro que o desenvolvimento de um DW espacial na arquitetura de informações da organização pode ser um diferencial competitivo e fonte de vantagens sobre a concorrência.


Fonte: Rogério Penna, Adaptado de Kimball et al. (1998)
Figura: Processo de Data Warehousing Espacial

O ciclo se inicia com o planejamento do projeto. Em seguida são definidos os requerimentos do negócio. Os requerimentos de informação devem ser baseados nas necessidades de informação analítica dos tomadores de decisão e na disponibilidade e qualidade da informação existente nos sistemas transacionais. Estas etapas são semelhantes às do processo de data warehousing convencional, sendo que os requerimentos de negócio devem considerar também as necessidades de informação geográfica e análises espaciais. O projeto do DW espacial prossegue, então, pelos mesmos três caminhos paralelos de um DW convencional.

Perspectiva dos Dados

Na Perspectiva dos Dados, o modelo dimensional é desenhado, os mapas de contexto são projetados, a estrutura física do banco de dados é definida, são desenvolvidos os programas para alimentação do DW espacial a partir dos sistemas transacionais ou fontes externas, bem como a aquisição de dados geográficos externos é definida, realizada e carregada no DW espacial. A modelagem dimensional é semelhante a um DW convencional, sendo os objetos espaciais modelados como atributos nas dimensões, conforme nossa abordagem.

A modelagem dimensional é semelhante à de um DW convencional, na qual os objetos espaciais são modelados como atributos nas dimensões. É importante frisar que não está sendo considerada a possibilidade de utilização de medidas espaciais, visando tornar o projeto mais simples e viável (considerando a discussão feita anteriormente, que demonstra que no ambiente de negócio estes podem ser substituídos por dimensões espaciais).

O projeto dos mapas de contexto deve ser feito tendo como base a modelagem das dimensões espaciais e as necessidades de análises espaciais. Nesta etapa são definidas quais camadas de informação geográfica devem ser disponibilizadas, quais escalas e representações e a precisão requerida. É fundamental ter em mente a relação custo-benefício ao definir o projeto dos mapas de contexto, sobretudo, quando tais informações não estão disponíveis em sistemas de informação geográfica transacionais na organização.

A figura abaixo apresenta um exemplo. É interessante notar que foram criadas hierarquias por tipo de cliente e localização (bairro e estado), sendo esta usada em duas dimensões. Estas hierarquias permitem a criação de Data Marts agregados, com informações sumariadas para análises de alto nível gerencial e estratégico. Hierarquias de tempo e produto também são pertinentes a este modelo, mas não foram representadas, para torná-lo mais simples.


Figura: Exemplo de Modelagem de DW Espacial

Apesar de sua característica de localização, a opção foi usar apenas informações textuais nas dimensões bairro e estado, usando as informações geográficas da localização espacial de bairros e municípios dos estados nos quais esta organização atua como dados de contexto geográfico. Esta abordagem torna mais simples a implementação da solução.

O projeto físico do DW espacial é uma atividade similar ao projeto físico de um DW convencional. A única diferença está no fato de acrescentarmos a consideração sobre os objetos espaciais que correspondem a atributos de tipos complexos existentes em extensões de SGBDs comerciais para representar pontos, linhas e polígonos.

O projeto e desenvolvimento dos programas ETL dos dados convencionais não sofre qualquer alteração em relação aos projetos de DWs convencionais. Para a extração de informações geográficas dos sistemas transacionais da organização, devem ser desenvolvidos programas específicos que carregarão esses dados em um ambiente intermediário (staging area). No caso dos objetos espaciais de negócio (atributos das dimensões espaciais), estes devem ser integrados aos demais atributos da dimensão neste ambiente intermediário para, posteriormente, serem carregados em conjunto no DW espacial. Os programas de carga devem ser desenvolvidos de forma a carregar tanto dados convencionais quanto objetos espaciais nas dimensões. No entanto, é preciso notar que a maioria das ferramentas ETL disponíveis no mercado não foram concebidas para tratar objetos espaciais. Para organizações que utilizam ferramentas ETL que não suportem atributos complexos representando objetos espaciais, estes precisarão ser carregados no DW espacial em separado.

Os programas ETL das camadas de objetos geográficos que formam os mapas de contexto são desenvolvidos e executados em separado da programação ETL de dados das dimensões e fatos do DW. Os programas de extração devem filtrar os objetos efetivamente relevantes para os mapas de contexto do DW espacial. No ambiente intermediário, objetos de camadas de informação distintas no ambiente transacional podem ser compostos, formando uma nova camada de informação conforme a necessidade de informação analítica. É neste ambiente que escalas e representações devem ser transformadas para adequar-se aos requisitos do DW espacial – em geral, muito menos detalhado que os mapas demandados em um GIS transacional. Uma outra alternativa é acessar os mapas de contexto já usados nas aplicações operacionais existentes, como discutido anteriormente.

A aquisição de dados geográficos externos é uma etapa inerente ao processo de data warehousing espacial, sendo semelhante à etapa de aquisição de dados dos sistemas de informação geográfica gerais. É importante observar a relação custo-benefício das aquisições, conforme discutido anteriormente. Dados geográficos podem ser adquiridos externamente tanto para as dimensões espaciais do DW quanto para os mapas de contexto. Em organizações que não utilizam GIS transacional, esta é a única alternativa para obtenção desses dados.

A aquisição de dados externos pode ser estendida como uma etapa para aquisição de quaisquer dados externos que sejam utilizados no DW, não apenas dados espaciais. Tais dados são de grande importância para o uso do DW como ferramenta estratégica. Como tais atividades não estão contempladas no processo de data warehousing definido por Kimball, a opção foi considerar esta nova etapa não apenas como aquisição de dados geográficos, fundamental em um DW espacial, mas de forma mais ampla, como aquisição de dados externos, necessária para o uso do DW como uma ferramenta efetiva para suporte a decisões estratégicas.

Perspectiva Tecnológica

Na Perspectiva Tecnológica, as atividades são as mesmas do processo de data warehousing convencional, porém é preciso dimensionar a capacidade do hardware para suportar análises espaciais, selecionar o software considerando o suporte as funcionalidades de integração GIS – BI e de armazenamento de dados espaciais.

Perspectiva da Aplicação

Na perspectiva da Aplicação, a primeira atividade deve ser a conscientização dos usuários. Se o uso de sistemas de apoio à decisão baseados em DWs ainda é novidade para boa parte dos usuários, o uso de GIS fora dos círculos especializados é bastante raro. Sabendo-se que qualquer sistema de informação, e em especial sistema de suporte à decisão, quando sub-utilizado ou mal utilizado pelos usuários não alcança seus objetivos, parece altamente relevante incluir uma atividade de conscientização no processo de data warehousing espacial. O fato de o GIS ainda ser uma caixa preta para a grande maioria dos usuários decisores no ambiente corporativo torna mais relevante essa atividade. Em seguida devem ser desenvolvidas as aplicações especificadas utilizando a ferramenta OLAP-GIS.

Na execução desta atividade devem ser feitas apresentações para os usuários do potencial da solução com discussão de casos e exemplos de aplicações. É preciso obter participação efetiva dos usuários, idealmente disponibilizando um protótipo inicial para que possam estar mais familiarizados com o ambiente e possam contribuir de forma efetiva no processo de desenvolvimento das aplicações. A maior dificuldade desta etapa é medir os resultados obtidos, posto que o nível de conscientização dos usuários não é mensurável.

A conscientização dos usuários faz parte da etapa de especificação das aplicações, mas merece destaque especial por ser base para o sucesso do projeto. Contando com usuários conscientes do potencial e possibilidades da solução, torna-se mais fácil e produtivo proceder à especificação dos relatórios, consultas e cálculos pré-definidos requeridos pelos usuários, posto que muitos usuários não utilizam consultas ad hoc. Esta etapa é a mesma do processo de data warehousing convencional, sendo necessário apenas considerar adicionalmente o uso das informações geográficas como predicado nas consultas e a visualização destas em mapas, quando indicado. Em um DW espacial nem todas as visualizações são feitas em mapas e nem todos os predicados utilizam informações geográficas.
Em seguida serão desenvolvidas as aplicações especificadas na etapa anterior utilizando a ferramenta OLAP-GIS e / ou o gerador de relatórios escolhido. Na perspectiva tecnológica, a seleção das ferramentas já terá selecionado a(s) ferramenta(s) indicada(s) para as necessidades de informação da organização.

Disponibilização e Crescimento

Assim como no processo de data warehousing convencional, as três perspectivas convergem em seguida, quando da disponibilização do DW espacial para o corpo gerencial, que passa então a utilizá-lo no apoio as tomadas de decisão. Demonstrando o caráter de processo do data warehousing espacial, o ciclo de vida se encerra com a manutenção e crescimento do SDW, que exige um novo ciclo de desenvolvimento e aperfeiçoamento, que se inicia no planejamento do novo projeto.

Finalmente, cabe lembrar que o SDW, assim como o DW convencional, precisa ser considerado como um organismo vivo, pois o ambiente de negócio certamente se modificará com uma dinâmica cada vez maior, demandando novas análises e informações adicionais para a tomada de decisão. O acirramento da competição enseja análises mais profundas, que também requerem informações adicionais no DW espacial. Compreendendo isto, fica fácil perceber que o DW espacial não pode ser encarado como um projeto finito e estanque com início, meio e fim. Ao contrário, o processo de data warehousing espacial passa a ser visto como contínuo, em constante evolução, de forma a acompanhar a evolução do negócio.

Rogério Penna , Analista de Sistemas pela PUC-RJ, Mestre em Engenharia de Produção pela COPPE-UFRJ, atua há 20 anos com Sistemas de Informação. É Professor Universitário, Consultor e Pesquisador em projetos de Business Intelligence, Data Warehousing, Integração GIS – DW, Planejamento Estratégico e Gestão da Informação.
rogeriopenna@yahoo.com

Eduardo de Rezende Francisco , Bacharel em Ciência da Computação pelo IME-USP, Mestrando em Administração (Métodos Quantitativos) pela EAESP-FGV, atua em GIS, Business Intelligence e Estratégias de Marketing na AES Eletropaulo, é Consultor em integração Geomarketing & Data Mining e sócio-fundador da GITA Brasil
erfrancisco@hotmail.com
eduardo.francisco@aes.com