• Nenhum resultado encontrado

UNIVERSIDADE ESTADUAL DE FEIRA DE SANTANA

N/A
N/A
Protected

Academic year: 2021

Share "UNIVERSIDADE ESTADUAL DE FEIRA DE SANTANA"

Copied!
47
0
0

Texto

(1)

UNIVERSIDADE ESTADUAL DE FEIRA DE SANTANA BACHARELADO EM ENGENHARIA DE COMPUTAÇÃO

IAN ANDERSON DE SOUSA FERREIRA

MODELAGEM E CONSTRUÇÃO DE UM DATA WAREHOUSE NO CONTEXTO DE UM SETOR IMOBILIÁRIO DE FEIRA DE SANTANA

FEIRA DE SANTANA 2013

(2)

MODELAGEM E CONSTRUÇÃO DE UM DATA WAREHOUSE NO CONTEXTO DE UM SETOR IMOBILIÁRIO DE FEIRA DE SANTANA

Trabalho de Conclusão de Curso apresentado ao Colegiado de Engenharia de Computação como requisito parcial para obtenção do grau de Bacharel em Engenharia de Computação da Universidade Estadual de Feira de Santana.

Orientador: David Moisés Barreto dos Santos

FEIRA DE SANTANA 2013

(3)

Dedico este trabalho ao meus pais, Vanderly Correia de Sousa e Getúlio Ferreira dos Santos, pelo apoio durante toda a jornada até chegar ao presente momento.

(4)

Agradeço a Deus pela luz que fornece no instante em que temos fé em nossos desejos.

Agradeço à minha mãe, Vanderly Correia de Sousa, pela preocupação, pelo apoio, pela bondade, desejo e esforço em fazer o filho prosperar na vida, a tua força e amor de mãe superam tudo.

Agradeço ao meu pai, Getúlio Ferreira dos Santos, pela ajuda com as dúvidas, principalmente em eletrônica, que surgiram ao longo desta jornada.

Agradeço à minha irmã, Ana Patrícia de Sousa Mascarenhas, pelo afeto e pelo apoio e ao meu sobrinho, Pedro Henrique Marques de Sousa Mascarenhas, por estar comigo nas horas de descontração, nos games e nos sorrisos.

Agradeço à minha namorada, Carla Tailane Silva de Carvalho, pelo exemplo de perseverança, virtude e fé, pelo apoio e principalmente, pelo amor.

Agradeço ao meu orientador David Moisés Barreto dos Santos pelo exemplo de profissionalismo, paciência e companheirismo, com certeza agora já, grande amigo.

Agradeço a todos que me ajudaram a ter a oportunidade de redigir estas palavras.

(5)

RESUMO

Este trabalho apresenta uma proposta de modelagem dimensional de um data warehouse com foco no setor imobiliário de Feira de Santana. Através do software Pentaho utilizou-se de técnicas de extração, transformação e carga de dados para preparar as informações oriundas de fontes diversas da organização. Em seguida, uma vez armazenadas no data warehouse, foi possível analisar as informações através do cubo OLAP, permitindo aos gestores gerar conhecimento para auxiliar no processo de tomada de decisão da organização.

Palavras-chave: Data Warehouse. OLAP. Conhecimento Organizacional. Setor Imobiliário.

(6)

This paper presents a proposal for a dimensional modeling of a data warehouse with a focus on real state in Feira de Santana. Through the Pentaho Software made use of techniques for extracting, transforming and loading data to prepare the information from differents sources in the organization. Then, once stored in the data warehouse, it was possible to analyze the information through the OLAP cube, allowing managers to generate knowledge to assist in the decision-making process of the organization. Keywords: Data Warehouse. OLAP. Organizational Knowledge. Real Estate Industry.

(7)

LISTA DE FIGURAS

Figura 1 Tabela auxiliar utilizada para armazenar os interesses em imóveis.

Fonte: Próprio autor. 12

Figura 2 Transformação de dados em informação e, posteriormente, conhecimento. Fonte: Adaptado de (PONNIAH, 2002, pág. 19). 15

Figura 3 Transferência de dados orientados a assunto para o data warehouse.

Fonte: Próprio autor. 17

Figura 4 Integração do campo sexo. Fonte: Próprio autor. 18

Figura 5 Modelagem dimensional para um setor de varejo. Fonte: (NEOGRID,

2013). 22

Figura 6 Exemplo de cubo OLAP. Fonte: Adaptado de (URBANEK, 2013). 25

Figura 7 Exemplo de operaçãoDrill Down. Fonte: Adaptado de (INMON, 2002). 26

Figura 8 Arquitetura do DW proposta. Fonte: Próprio autor. 27

Figura 9 Modelagem dimensional realizada para o projeto. Fonte: Próprio autor. 29

Figura 10 Tela de edição SQL para o step de conexão. Fonte: Próprio autor. 30

Figura 11 Job principal. Fonte: Próprio autor. 30

Figura 12 Etapa extração, transformação e carga dos dados. Fonte: Próprio

autor. 31

Figura 13 Etapa de extração e seleção dos dados. Fonte: Próprio autor. 32

(8)

autor. 33

Figura 16 Mapeamentos dos nomes de bairros. Fonte: Próprio autor. 33

Figura 17 Etapa de transformação dos dados. Fonte: Próprio autor. 34

Figura 18 O DLU contém campos que armazenam as datas em que a informação foi válida e a versão daquela informação. Fonte: Adaptado de

(PENTAHO-WIKI, 2013). 35

Figura 19 Diagramas de carga das dimensões. Fonte: próprio autor. 36

Figura 20 Etapa de carga dos dados na tabela de fato a partir das dimensões.

Fonte: Próprio autor. 36

Figura 21 Tela do OLAP. Fonte: Próprio autor. 38

Figura 22 Drill-down na dimensão de tipo de imóvel. Fonte: Próprio autor. 39

Figura 23 Exemplo de visualização de informação através do OLAP. Fonte:

Próprio autor. 39

Figura 24 Demanda de imóveis por venda/aluguel por tipo de imóvel. Fonte:

Próprio autor. 40

Figura 25 Demanda de imóveis por venda/aluguel por bairro. Fonte: Próprio

autor. 41

Figura 26 Demanda de compra/aluguel nos três últimos trimestres de 2013.

Fonte: Próprio autor. 42

Figura 27 Gráfico da demanda de compra/aluguel nos três últimos trimestres de

(9)

Figura 28 Gráfico da demanda de compra/aluguel para os meses dos três últimos

(10)

Tabela 1 Ambientes operacionais versus ambientes gerenciais 16

Tabela 2 Linha de dimensão inicial 22

Tabela 3 Valor substituído 23

Tabela 4 Inserção de nova linha para a técnica Tipo 2 23

Tabela 5 Inserção de nova coluna para a técnica Tipo 3 23

(11)

SUMÁRIO

1 INTRODUÇÃO. . . 10

1.1 METODOLOGIA . . . 11

1.2 ESTRUTURA DA MONOGRAFIA . . . 13

2 DATA WAREHOUSE . . . 14

2.1 ESTRUTURA DO DATA WAREHOUSE . . . 16

2.1.1 ORIENTAÇÃO POR ASSUNTO . . . 16

2.1.2 INTEGRAÇÃO . . . 17

2.1.3 NÃO VOLATILIDADE . . . 17

2.1.4 GRANULARIDADE . . . 18

2.2 EXTRAÇÃO, TRANSFORMAÇÃO E CARGA . . . 18

2.3 ARQUITETURA DO DATA WAREHOUSE . . . 19

2.3.1 ESQUEMA ESTRELA . . . 19

2.3.2 MODELAGEM MULTIDIMENSIONAL . . . 20

2.3.3 DIMENSÕES QUE VARIAM LENTAMENTE . . . 22

2.4 MODELAGEM DO DW . . . 24

2.5 ONLINE ANALYTICAL PROCESSING (OLAP) . . . 24

3 PROJETO DO DATA WAREHOUSE PARA SETOR IMOBILIÁRIO . . . 27

3.1 ARQUITETURA . . . 27

3.2 MODELO MULTIDIMENSIONAL . . . 27

3.3 PROCESSO DE ETL . . . 28

3.3.1 POLÍTICA DE ATUALIZAÇÃO . . . 34

3.4 CARGA DAS DIMENSÕES . . . 35

3.5 CARGA DA TABELA DE FATO . . . 35

3.6 CRIAÇÃO DO CUBO OLAP . . . 37

4 RESULTADOS E DISCUSSÕES . . . 38

5 CONSIDERAÇÕES FINAIS . . . 44

(12)

1 INTRODUÇÃO

As organizações costumam gerar em seus departamentos milhares de dados através dos sistemas legados internos da empresa, que são os sistemas de cadastros de clientes, sistemas de controle de estoque, sistemas financeiros, e todos que forem necessários para a logística da organização, e que juntos, formam o ambiente operacional da mesma. Muitas vezes os dados gerados nesses sistemas são de difícil acesso para os gestores da organização, pois podem ser oriundos de diversas fontes, possuírem difícil legibilidade e não fornecerem as informações que são realmente importantes para a gestão da organização (BRUZAROSCO, Donizete; CASTOLDI, André; PACHECO, Roberto, 2000).

Essas informações devem ser de fácil acesso e de rápida compreensão por parte da gerência, de modo que facilite o processo de tomada de decisão, com o intuito de evitar prejuízos ou até mesmo a falência de uma organização. As informações da organização devem fornecer um panorama histórico dos processos administrativos, comerciais, financeiros, ou qualquer outro procedimento que seja essencial para a gestão da organização, permitindo ao gestor tomar decisões rápidas com base na inteligência do negócio. O setor que trata desta vertente da organização é denominado ambiente gerencial (BRUZAROSCO, Donizete; CASTOLDI, André; PACHECO, Roberto, 2000).

Neste sentido, a gestão do negócio deve munir-se de ferramentas de Tecnologia da Informação (TI) que permitam avaliar de maneira eficaz: tendências de mercado, estratégias de vendas, comportamento do negócio ao longo do tempo, perfil de clientes, receita, e tudo que for considerado como métrica do negócio (BRUZAROSCO, Donizete; CASTOLDI, André; PACHECO, Roberto, 2000).

Visando justamente suprir a necessidade de gerir dados da organização, de modo que os mesmos sejam adequados para o ambiente gerencial e venham a se tornar informação útil no processo decisório de gerentes e administradores, foi desenvolvida a tecnologia de data warehouse (DW ), que fornece os conceitos necessários para o ambiente de suporte à tomada de decisão da organização (KIMBALL RALPH; ROSS, 2002). Segundo Kimball (2002, pag. 3), "um data warehouse deve fazer com que informações de uma empresa possam ser facilmente acessadas".

De forma especial, este trabalho atuou no contexto do setor imobiliário de Feira de Santana, em um negócio específico, no qual surgiu a necessidade de integração e análise de dados do setor imobiliário oriundos de diversas fontes, as quais são

(13)

11

gerenciadas por uma empresa de desenvolvimento de sistemas web para imobiliárias. O DW proposto através deste trabalho foi desenvolvido a partir de bases de dados de imobiliárias de Feira de Santana, cujo acesso foi disponibilizado por um empresário do setor, de forma que este trabalho pudesse ser útil para a empresa, fornecendo informações analíticas.

De modo geral, o objetivo principal deste trabalho foi projetar e implementar um Data Warehouse para dados do setor imobiliário gerenciados pela empresa de desenvolvimento Web para imobiliárias supracitada. Para atingir este objetivo foi utilizada uma ferramenta de software para fazer a carga dos dados no DW e após o mesmo ser povoado, foi possível gerar os relatórios e fazer as análises sobre as informações obtidas para o setor imobiliário em questão. Os dados utilizados para alimentar o DW foram restritos às intenções dos clientes em comprar ou alugar os imóveis. Isso porque o empresário só pôde disponibilizar acesso aos websites das imobiliárias, o que permitiu ter acesso às intenções de compra/aluguel dos usuários dos websites, portanto, os dados não representam uma negociação finalizada, mas sim, a intenção do cliente em compra/alugar um imóvel. Apesar disso, os dados obtidos a partir das intenções foram suficientes para avaliarmos tendências do mercado imobiliário. Sobretudo, permitiram que um gestor pudesse avaliar tendências do mercado, como por exemplo, saber o tipo de imóvel mais procurado, em um determinado período de tempo e, as características do imóvel preferidas pelos compradores, assim como os bairros com maior procura por imóveis. Essas questões podem variar muito com o tempo e o DW proposto neste trabalho foi projetado de modo a ser flexível a essas mudanças.

1.1 METODOLOGIA

Para atingir o objetivo desse trabalho foi necessário delimitar um setor de negócios. O escolhido foi o ramo imobiliário, devido à proximidade com um empresário que está envolvido no processo de criação de sites e sistemas para imobiliárias de Feira de Santana e que se predispôs a prestar suporte quanto às dúvidas sobre os processos envolvidos no ramo, assim como fornecer acesso às bases de dados dos websites de algumas imobiliárias de Feira de Santana. Os nomes das empresas são mantidas em anonimato de acordo com solicitação do empresário que forneceu acesso às bases de dados.

É importante ressaltar que os dados acessados não foram de informações financeiras diretas das imobiliárias, mas sim obtidos através de formulários de contato

(14)

com os corretores a partir dos websites destas imobiliárias, cujo preenchimento e envio demonstram uma intenção de compra ou aluguel do imóvel por parte do cliente. Em outras palavras, não são negociações fechadas, mas sim intenções de negociação, o que pode significar, em dado momento, que o cliente queira saber apenas dados do imóvel a partir do formulário de contato com o corretor. Desse modo, todos os resultados obtidos foram baseados nas intenções de compra e/ou aluguel.

A partir disso, foi criada uma tabela diretamente em cada uma das bases de dados das imobiliárias disponíveis para armazenar os dados do imóvel de interesse do cliente. Isso foi feito logo no início do projeto, para que fosse possível obter a maior quantidade de dados possível. A estrutura da tabela supracitada é apresentada na Figura 1. Nela são armazenados o código do imóvel, a data e os valores de aluguel e venda do imóvel.

Figura 1: Tabela auxiliar utilizada para armazenar os interesses em imóveis. Fonte: Próprio autor.

Em seguida foi feita a revisão bibliográfica, cuja fonte principal foi Kimball, que é um dos pré-cursores dos conceitos de data warehouse e desde 1982 vem desenvolvendo este estudo para os diversos setores (KIMBALLGROUP, 2013).

Após iniciada a revisão bibliográfica foi definido que o DW seria elaborado através do auxílio de uma suíte de software, o Pentaho, cuja proposta final é ajudar líderes de negócios a tomarem decisões gerenciais de maneira mais rápida e fácil. O Pentaho foi escolhido por ser uma ferramenta de código aberto desenvolvido em Java para inteligência empresarial e, sobretudo, pelo fato do Pentaho oferecer as funcionalidades necessárias para o trabalho, tais como Extract, Transform And Load (ETL) (Seção 3.3) e Online Analytical Processing (OLAP) (Seção 3.6).

Definida a ferramenta, foi iniciado o processo de modelagem do DW. O empresário então informou que o interesse das imobiliárias é relativo à demanda de imóveis, ou seja, os mais procurados, as regiões da cidade com maiores

(15)

13

vendas/aluguéis e os tipos de imóveis mais desejados, para que a captação de imóveis por parte das imobiliárias fosse feita de acordo com a demanda do mercado. Assim o processo de modelagem variou bastante até que fosse adequado a esses requisitos.

Em seguida ao processo de modelagem, foi preciso utilizar as ferramentas de software do Pentaho para fazer o processo de extração, transformação e carga dos dados para o DW. O módulo PDI (Pentaho Data Integration) foi utilizado para realizar o processo de ETL, e em seguida o módulo Schema Workbench foi utilizado para criar o cubo OLAP. Finalmente, o PUC (Pentaho User Console) foi utilizado para fazer as análises no cubo OLAP através das operações Drill up e Drill down e a geração de relatórios para a análise das informações.

1.2 ESTRUTURA DA MONOGRAFIA

No Capítulo 2 será feita uma revisão bibliográfica sobre os conceitos envolvidos em torno da tecnologia de Data Warehouse, desde a estrutura do mesmo, até o ETL e a arquitetura de um DW.

No Capítulo 3 será discutido o processo de desenvolvimento, os métodos e as tecnologias de software utlizadas para desenvolver o DW.

No Capítulo 4 serão apresentados os resultados e as análises feitas através das informações obtidas através do DW.

No Capítulo 5 será discutido qual era a proposta e o que foi conseguido, os principais resultados, as limitações do projeto e os trabalhos futuros.

(16)

2 DATA WAREHOUSE

O data warehouse é um repositório de dados que estrutura os mesmos para que estejam sempre preparados a fim de que sejam acessados por um gestor, sem necessitar de conhecimentos técnicos avançados de informática. Através desta estrutura, ferramentas analíticas são utilizadas para acessarem informações úteis para a organização, de modo que venham a fornecer respostas aos mais peculiares questionamentos do departamento estratégico (KIMBALL RALPH; ROSS, 2002).

Segundo Ponniah (2002, p. 15), ”o data warehouse é um ambiente informacional que fornece as seguintes características:

• Visão geral e integrada da organização;

• Disponibiliza de maneira fácil o acesso às informações históricas e atuais para suporte estratégico de tomada de decisão;

• Torna o processo de tomada de decisão possível sem atrapalhar os processamentos dos sistemas legados, ou seja, sem interferir no ambiente operacional da empresa;

• Torna a informação da organização consistente e age como uma fonte segura desses dados;

• É uma fonte flexível e interativa de informação estratégica.”

Inmon afirma que "o data warehouse é o coração do ambiente projetado, e é a base de todo sistema de suporte a tomada de decisão". Ainda segundo Inmon, "O trabalho do analista de sistemas de suporte a tomada de decisão em uma ambiente de data warehouse é imensuravelmente mais fácil do que em um ambiente legado".

A Figura 2 apresenta uma visão geral de todo o processo no qual o data warehouse está inserido, na qual são apresentados dois ambientes que se complementam, o ambiente de data warehousing e o ambiente analítico. No ambiente de data warehousing ocorre desde a etapa de acesso às fontes de dados que foram gerados pelos sitemas legados, até a carga destes dados no data warehousing propriamente dito, após a extração e transformação dos mesmos através das técnicas de ETL, detalhadas na Seção 2.2. Com os dados carregados no data warehouse, obtemos as informações, as quais são passadas então para o ambiente analítico, no qual os usuários acessam as informações do data warehouse através de consultas, relatórios e análises, gerando conhecimento. Com o conhecimento gerado, os gestores podem então tomar as decisões necessárias para a administração da organização. É possível notar que o data warehouse é a ponte que interliga os

(17)

15

dados comuns da organização, através das informações armazenadas no mesmo, ao conhecimento organizacional, utilizado pelos gestores (PONNIAH, 2002).

Figura 2: Transformação de dados em informação e, posteriormente, conhecimento. Fonte: Adaptado de (PONNIAH, 2002, pág. 19).

Os principais contextos no que refere-se aos dados de uma organização são o ambiente operacional e o ambiente gerencial da mesma (PONNIAH, 2002).

O ambiente operacional, é o processo de execução que ocorre no dia-a-dia da organização, onde os usuários dos sistemas legados determinam a direção da empresa, por exemplo, realizando cadastros, pedidos e registrando reclamações (PONNIAH, 2002). Estes processos são realizados através de sistemas administrativos, sistemas de controle de estoque, entre outros. Ou seja, é uma etapa mecânica de geração de dados (KIMBALL RALPH; ROSS, 2002). O tipo de processamento desses dados nos sistemas legados é denominado OLTP (Online Transactional Processing), ou seja, os processos rotineiros da organização.

Em contrapartida, no ambiente gerencial há o planejamento e controle. Nesse ambiente encontram-se os usuários que observam o andamento da empresa, fazem análises de negociação e produtos, avaliam o perfil de clientes e contabilizam as informações levando em consideração o fator tempo, fornecendo, desse modo, suporte ao setor de tomada de decisões da organização e objetivando melhorar o negócio. O tipo de processamento das bases de dados gerenciais é OLAP, ou

(18)

seja, o processamento analítico dos dados, de modo que os mesmos se tornem informação útil para a organização (PONNIAH, 2002). A Tabela 1 apresenta as principais diferenças e características confrontadas entre o ambiente operacional e o ambiente gerencial de uma organização.

Tabela 1: Características de ambientes operacionais versus ambientes gerenciais. Característica Ambiente Operacional Ambiente Gerencial

Conteúdo dos dados Valores atuais Valores históricos, derivados e sumarizados Estrutura dos dados Otimizado para transações Otimizado para consultas complexas

Frequência de acesso Alta De média a baixa

Tipo de acesso Leitura, escrita e execução Leitura

Uso Previsível e repetitivo Aleatório e heurístico Tempo de resposta Frações de segundo Segundos ou minutos

Usuários Muitos Relativamente poucos

Fonte: (PONNIAH, 2002)

2.1 ESTRUTURA DO DATA WAREHOUSE

As características mais importantes que concernem a estrutura e a qualidade no desenvolvimento de um data warehouse são: orientação a assuntos, integração, histórico de dados (não-volatilidade), e um conjunto de dados concisos, que forneçam informações úteis ao processo de tomada de decisão (INMON, 2002).

2.1.1 Orientação Por Assunto

Um sistema de data warehouse é criado de forma a ser orientado por assunto. Um assunto é qualquer processo envolvido no negócio que seja útil para análise. A partir da definição dos assuntos são buscados os dados referentes aos mesmos nas bases de dados operacionais. A Figura 3 apresenta o agrupamento de dados orientados a assunto a partir da bases de dados operacionais e o procedimento de passagem desses dados para o data warehouse (KIMBALL RALPH; ROSS, 2002). Ainda na Figura 3, representamos o assunto que desejamos capturar as informações. Neste caso, queremos obter informações sobre as negociações de imóveis. Os dados relacionados ao assunto são transportados para as entidades do data warehouse desejadas, no caso, os imóveis negociados, a localização dos imóveis e o tipo do imóvel negociado (Casa, apartamento, terreno, entre outros).

(19)

17

Figura 3: Transferência de dados orientados a assunto para o data warehouse. Fonte: Próprio autor.

2.1.2 Integração

Como os dados que alimentam o data warehouse são de diversas fontes distintas, é preciso que os mesmos sejam convertidos, reformatados e sumarizados para que apresentem uma imagem física única no data warehouse (INMON, 2002).

Por exemplo, na Figura 4 temos o campo sexo de diferentes formas em três bases de dados. Na base 1 o campo é representado por ”m” para masculino e ”f” para feminino, na base 2, booleanos ”0” e ”1”, e na base 3, ”A” e ”B”, entretanto o data warehouse foi projetado para receber ”m” e ”f”, então estes dados serão transformados para que se tornem compatíveis com o data warehouse, e este, por sua vez, manterá a coesão dos dados (INMON, 2002).

2.1.3 Não Volatilidade

No ambiente operacional, os dados são regularmente atualizados e na maioria das vezes um registro por vez. Já no data warehouse os dados apresentam uma ampla variação de características, pois os mesmos são carregados em massa e representam uma imagem do registros ao longo do tempo. Além disso, os dados não são atualizados, eles são sempre adicionados quando mudanças subsequentes ocorrerem, mantendo desse modo o caratér histórico das informações (INMON, 2002).

(20)

Figura 4: Integração do campo sexo. Fonte: Próprio autor.

2.1.4 Granularidade

A granularidade concerne ao nível de detalhamento dos dados que vamos disponibilizar no data warehouse, quanto menos detalhados os dados que obtermos a partir do data warehouse, maior o nível de granularidade, pois teremos grãos maiores. Por exemplo, para imóveis, podemos utilizar o nível de imóveis vendidos por mês ou por semana. No segundo caso, temos um maior nível de detalhamento, e em consequência, uma granularidade menor. A granularidade é uma característica de projeto, e é avaliada de acordo com o nível de detalhamento necessário para obter informações sobre o negócio em questão (INMON, 2002).

2.2 EXTRAÇÃO, TRANSFORMAÇÃO E CARGA

A etapa ETL prepara os dados para que os mesmos tornem-se informação útil armazenada no data warehouse. Esta etapa é crucial para a confiabilidade, pois sem dados extraídos corretamente, limpos e correlacionados, a consistência da informação fica comprometida (PONNIAH, 2002).

A extração é o procedimento que permite recuperar os dados de diversas fontes, abstraindo as diferenças estruturais das mesmas, seja a fonte um arquivo de dados ou um Sistema Gerenciador de Banco de Dados (SGBD). A extração seleciona os dados necessários a partir dessas fontes. Além disso, a extração deve frequentemente acessar essas diversas fontes de dados e recuperar dados que foram modificados, seja o acesso diário, semanal ou mensal e irá depender do processo de negócio de cada organização (PONNIAH, 2002).

(21)

19

A extração nos fornece o dado puro, entretanto que não está preparado ainda para ser inserido no data warehouse. É preciso adequar a qualidade destes dados para que possam ser carregados. Neste intento, a transformação é uma etapa que manipula tais dados para que os mesmos tornem-se compatíveis com a estrutura do data warehouse (PONNIAH, 2002).

O processo de transferir os dados já extraídos e transformados para o repositório do data warehouse é denominado de carga. A carga geralmente ocorre de três formas: carga inicial, cargas incrementais e atualização completa. A carga inicial ocorre quando a base de dados do data warehouse está vazia e vai ser preenchida pela primeira vez, o que pode levar muito tempo a depender da quantidade de dados. As cargas incrementais ocorrem periodicamente, sempre que necessário. E a atualização completa, apaga todos os dados de alguma tabela e a recarrega com dados atuais, fazendo uma carga inicial apenas na tabela afetada. Além disso, é desejável que o data warehouse esteja offline durante o procedimento de carga, pois requer muitos recursos de entrada e saída, o que pode afetar os usuários caso o sistema esteja online (PONNIAH, 2002).

2.3 ARQUITETURA DO DATA WAREHOUSE

Este capítulo apresenta os conceitos utilizados no projeto da arquitetura proposta para o DW.

2.3.1 Esquema Estrela

O esquema estrela é uma abordagem proposta por Kimball cuja modelagem da base de dados é altamente redundante, de modo que a base se torne de alto desempenho. Os dados são dispostos em tabelas dimensionais desnormalizadas que representam as características, ligadas a uma tabela de fato que armazena as métricas do negócio em questão (KIMBALL RALPH; ROSS, 2002). Esse modelo de redundância permite consultas mais simples e eficientes (SINGH, 2001). As principais vantagens são:

• Reduz a quantidade de junções entre tabelas, melhorando o desempenho; • Pode fornecer uma estrutura dimensional complexa, mas que mantém um

modelo de dados simples;

• Com um modelo de dados simples, facilita a análise dos usuários e diminui a chance de realizar consultas incorretas;

(22)

• Facilita as mudanças futuras do DW (SINGH, 2001).

Como esse tipo de modelagem vai contra os princípios da modelagem relacional clássica, na qual se busca evitar a redundância de dados, o projetista fica tentado em normalizar as dimensões durante a modelagem. Quando isto ocorre, é denominado modelo snowflaking, que em detrimento do modelo estrela apresenta algumas desvantagens (KIMBALL RALPH; ROSS, 2002):

• Aumenta a quantidade de tabelas; • Aumenta a complexidade do modelo;

• Se traduz em queda de desempenho das consultas;

• A economia de espaço não prepondera sobre a facilidade de uso e desempenho do modelo estrela (KIMBALL RALPH; ROSS, 2002).

O esquema estrela é utilizado no processo de modelagem multidimensional proposto neste trabalho.

2.3.2 Modelagem Multidimensional

A modelagem dimensional baseia-se nas dimensões do negócio em questão e de acordo com Ponniah (2002, p. 226):

A modelagem dimensional recebe este nome devido às dimensões do negócio que precisamos incorporar ao modelo de dados lógico. Ela é uma técnica para estruturar as dimensões do negócio e as métricas que serão analisadas junto a estas dimensões. Esta técnica de modelagem é intuitiva para este propósito. E este modelo tem fornecido alto desempenho para consultas e análises em um data warehouse.

A tabela de fato é a principal no modelo dimensional, ela representa as métricas do negócio que nos fornecem as medições numéricas de desempenho do mesmo (KIMBALL RALPH; ROSS, 2002).

A medição é uma linha da tabela de fatos, geralmente de tipos numéricos e aditivos. As tabelas de fatos têm como objetivo ter um alto desempenho, evitando armazenar itens textuais, e além disso, manter os registros ao longo do tempo, permitindo que dados históricos sejam resgatados posteriormente. A tabela de fato tende a crescer bastante, desse modo medidas textuais são evitadas pois podem conter conteúdo imprevisível e ocupar muito espaço de armazenamento numa tabela que armazene até milhões de registros, como no caso da tabela de fato, que chega a ocupar até 90% do armazenamento em uma base de dados dimensional. Além disso,

(23)

21

a tabela de fato possui poucos atributos e a chave da mesma é composta por chaves estrangeiras das tabelas de dimensão. Assim, a tabela de fato representa uma relação de muitos-para-muitos na modelagem dimensional (KIMBALL RALPH; ROSS, 2002).

Além das tabelas de fatos, a modelagem dimensional é composta pelas tabelas de dimensões, que sempre acompanham uma tabela de fato. De modo geral, as tabelas de dimensões podem possuir muitos atributos e uma quantidade de linhas armazenadas pequena em relação a tabela de fato (KIMBALL RALPH; ROSS, 2002). As tabelas de dimensão funcionam como restrições que estabelecem quais são as consultas necessárias a serem realizadas no data warehouse para que a informação solicitada pelo gestor possa ser obtida. A combinação das várias dimensões permite obter as informações a partir das medidas armazenadas na tabela de fato. De modo geral, a tabela de fato reúne as métricas do negócio e as dimensões definem os atributos que descrevem o negócio (KIMBALL RALPH; ROSS, 2002).

Por exemplo, a Figura 5 apresenta a modelagem dimensional para um setor de varejo. Neste modelo, possuímos quatro dimensões: canal de venda, produto, região e tempo. Nas dimensões temos os atributos que são importantes para as informações a serem obtidas. Na tabela de fato é possível perceber que as chaves estrangeiras formam a chave composta da tabela de fato. Ainda na tabela de fato temos as medições desejadas para o negócio, no exemplo, quantidade de itens vendidos e o valor total acumulado nas vendas (KIMBALL RALPH; ROSS, 2002).

Desse modo, podemos responder, através da modelagem dimensional representada na Figura 5, questionamentos como: Qual a quantidade e o valor total de produtos X vendidos através da loja Y na Cidade Z no semestre passado?

Fazendo a intersecção das dimensões desejadas obtêm-se as medidas através da tabela de fato, gerando deste modo as informações desejadas para os processos do negócio.

As tabelas de dimensão geralmente não são normalizadas para que as mesmas sejam mais intuitivas. A normalização dessas tabelas quase não produz resultado, já que as mesmas ocupam pouco espaço de armazenamento em relação a tabela de fato. Logo, é preferível a simplicidade e acessibilidade em detrimento da normalização das tabelas de dimensões (KIMBALL RALPH; ROSS, 2002).

A simplicidade de um modelo dimensional, como o representado na Figura 5, permite que os usuários do negócio tenham maior facilidade em interpretar os dados, além disso o modelo possui um número reduzido de tabelas e há uma diminuição da incidência de erros nas informações. Sobretudo, ocorre um maior

(24)

Figura 5: Modelagem dimensional para um setor de varejo. Fonte: (NEOGRID, 2013).

desempenho por parte dos sistemas gerenciadores de banco de dados, pois os mesmos passam a operar uma estrutura mais simples e com menos relacionamentos (KIMBALL RALPH; ROSS, 2002).

2.3.3 Dimensões Que Variam Lentamente

Com o tempo, os atributos das tabelas de dimensão mudam para se adequaram às mudanças do negócio. Ralph Kimball propôs o conceito de dimensões que mudam lentamente (Slowly Changing Dimensions - SCDs), o qual fornece três técnicas de abordagem para acompanhar as alterações nas dimensões (KIMBALL RALPH; ROSS, 2002).

A técnica do Tipo 1, apenas substitui o valor do atributo da dimensão, trocando o mesmo pelo valor certo. Por exemplo, na linha de dimensão representada na Tabela 2, se desejarmos alterar o atributo Casa Ampla do tipo Casa Comercial para o tipo Casa, então substituímos diretamente o valor, desse modo a linha fica como apresentado na Tabela 3 e mantendo a chave natural do imóvel, que é a chave que identifica unicamente o registro na base de dados de origem (KIMBALL RALPH; ROSS, 2002). A técnica do Tipo 1 é de simples implementação, mas não mantém histórico do atributo, pois perde os valores anteriores (KIMBALL RALPH; ROSS, 2002).

Tabela 2: Linha de dimensão inicial

Chave do imóvel Descrição Tipo Chave natural imóvel

1 Casa Ampla Casa Comercial 2845

(25)

23

Tabela 3: Valor substituído

Chave do imóvel Descrição Tipo Chave natural imóvel

1 Casa Ampla Casa 2845

Fonte: Próprio autor.

Como um dos principais objetivos de um DW é manter o histórico, a técnica do Tipo 2 faz uma abordagem em que quando a linha da dimensão precisa ser alterada ela cria uma nova linha com o novo valor, neste caso, para o exemplo anterior, ficaríamos com a configuração apresentada na Tabela 4. Note que a chave natural do produto não se altera. Isto permite segmentar o histórico, pois poderemos agrupar quando aquele imóvel fazia parte do tipo Casa comercial, e quando passou a fazer parte do tipo Casa. A técnica do Tipo 2 é a mais eficiente e divide automaticamente o histórico (KIMBALL RALPH; ROSS, 2002).

Tabela 4: Inserção de nova linha para a técnica Tipo 2

Chave do imóvel Descrição Tipo Chave natural imóvel

1 Casa Ampla Casa Comercial 2845

2 Casa Ampla Casa 2845

Fonte: Próprio autor.

Embora a técnica do Tipo 2 particione o histórico, a mesma não permite associar o valor novo de um atributo com o valor antigo, então a técnica do Tipo 3 surge para suprir essa necessidade de ter o dois modos de visão ao mesmo tempo, o atual e os anteriores. Para o exemplo citado, seria inserida uma nova coluna, de tipo anterior, conforme pode ser visto na Tabela 5. A técnica do Tipo 3 é utilizada com menos freqüência, pois apresenta limitações de implementação, já que a quantidade de colunas pode crescer bastante para refletir os valores anteriores (KIMBALL RALPH; ROSS, 2002).

Tabela 5: Inserção de nova coluna para a técnica Tipo 3

Chave do imóvel Descrição Tipo Tipo anterior Chave natural imóvel

1 Casa Ampla Casa Casa Comercial 2845

Fonte: Próprio autor.

AS técnicas SCD do Tipo 1 e Tipo 2 foram utilizadas neste trabalho através do Pentaho e são discutidas na seção 3.4.

(26)

2.4 MODELAGEM DO DW

De acordo com Kimball, ”o processo de criação do modelo dimensional consiste em quatro etapas:

1. Busca pelo processo de negócio a ser modelado; 2. Especificação do grão para o processo de negócio;

3. Elaboração das dimensões que se aplicam ao processo de negócio; 4. Identificação das medidas do negócio e criação da tabela de fato”.

A etapa de busca pelo processo de negócio, consiste em procurar atividades que utilizam de sistemas de coletas de dados tais como: estoque, faturamento, pedidos, registro de clientes, etc. De modo geral, para conseguir selecionar o processo de negócio a ser modelado é necessário ouvir os usuários e gestores do negócio.

A segunda etapa consiste na declaração do nível de detalhamento do processo de negócio, ou seja a definição da granularidade em uma linha da tabela de fato.

A terceira etapa é a elaboração das dimensões que estão relacionadas às medidas da tabela de fato, ou seja, como essas medidas podem ser descritas.

A quarta e última etapa consiste na criação da tabela de fato, que são as medidas do negócio, os dados que queremos saber sobre o processo de negócio e as medidas de desempenho que interessam aos gestores (KIMBALL RALPH; ROSS, 2002).

2.5 ONLINE ANALYTICAL PROCESSING (OLAP)

O processamento online analítico permite que uma estrutura com muitos dados e em múltiplas perspectivas seja analisada de forma eficiente. A informação em modelo de dados OLAP é organizada em cubos que contém dimensões e medidas (INMON, 2002).

O cubo OLAP nos fornece a possibilidade de através das dimensões do mesmo localizar uma medida desejada. Eles são pré-calculados, o que nos fornece um desempenho rápido nas consultas (KIMBALL RALPH; ROSS, 2002).

A Figura 6 apresenta um modelo conceitual de um cubo OLAP, no qual temos as dimensões localização, tipo de imóvel e tempo. Cruzando essas dimensões do cubo é possível localizar uma célula do mesmo a qual contém a informação que desejamos saber. Por exemplo, a quantidade de imóveis vendidos, do tipo casa, no bairro 1 para o mês de maio. A célula nos fornecerá, desse modo, a métrica desejada.

(27)

25

O OLAP, além disso, fornece um conjunto de ferramentas que permitem explorar as dimensões do cubo e fazer consultas para gerar relatórios gerenciais. As principais ferramentas são: Drill Down, Drill Up e Drill Across (MACHADO, 2004).

Figura 6: Exemplo de cubo OLAP. Fonte: Adaptado de (URBANEK, 2013).

Drill Down é uma ferramenta OLAP que permite aumentar o nível de detalhes das informações, diminuindo a granularidade das requisições. De modo geral é utilizado para fazer a junção do resultados de uma consulta (MACHADO, 2004). A Figura 7 apresenta um exemplo de operações de Drill Down, onde é desejado explorar a quantidade de vendas no segundo semestre do ano, nas cidades bahianas. Partindo das regiões brasileiras, aumenta-se o nível detalhamento através da operação de Drill Down para os estados, encontrando Bahia e, posteriormente, as cidades pertencentes a Bahia, e assim sucessivamente através desta operação até atingir o nível de detalhamento desejado ou o menor nível de granularidade possível.

O Drill Up, em contrapartida, diminui o nível de detalhes aumentando a granularidade das consultas realizadas, resumindo, desse modo, as informações (MACHADO, 2004). Assim, para o mesmo exemplo citado anteriormente, o Drill Up nos possibilitaria sair do nível de detalhamento de cidade, para estado, diminuindo o nível de detalhamento da informação, e assim sucessivamente.

O Drill Across ocorre quando em uma mesma dimensão pula-se um nível intermediário de detalhes para obter as informações durante a consulta, por exemplo, em uma dimensão tempo, a qual teria dia, mês e ano, durante uma mesma consulta que gera um relatório de dia e ano, estaríamos atravessando o grão mês, e pulando do menor grão, dia, para o maior grão, ano (MACHADO, 2004). No exemplo da

(28)

Figura 7: Exemplo de operaçãoDrill Down. Fonte: Adaptado de (INMON, 2002).

Figura 7, poderíamos desejar uma informação que utilizasse todas as cidades de uma determinada região, ignorando o nível de detalhes por estado.

(29)

27

3 PROJETO DO DATA WAREHOUSE PARA SETOR IMOBILIÁRIO

Este capítulo irá tratar das etapas de projeto do DW proposto, envolvendo a modelagem, o processo de ETL, o modelo multidimensional e os resultados alcançados.

3.1 ARQUITETURA

A arquitetura do projeto proposto consiste no processo apresentado na Figura 8. Inicialmente são criadas as conexões com as bases de dados das imobiliárias A, B, C e D. Depois é realizado o processo de integração dos dados através do ETL (Seção 3.3). Posteriormente, com o modelo multidimensional já implantado na base do DW, é realizada a carga dos dados no mesmo (Seções 3.2, 3.4 e 3.5). Finalmente é feito uma análise das informações obtidas, através de relatórios e do cubo OLAP, conforme pode ser visto no capítulo 4.

Figura 8: Arquitetura do DW proposta. Fonte: Próprio autor.

3.2 MODELO MULTIDIMENSIONAL

O modelo multidimensional proposto foi projetado em conformidade com a proposta de Kimball a partir da realização das quatro etapas descritas na seção 2.4. Seguindo essas etapas, foi iniciado o processo de criação do modelo multidimensional. Como dito na seção 1.1, o processo de negócio (Etapa 1) é relativo às intenções de compra/aluguel de imóveis a partir dos websites das imobiliárias, então foi preciso saber o nível de detalhe necessário para as informações que seriam obtidas a partir

(30)

das intenções de compra/venda. Para isto, o empresário do setor foi entrevistado e nos informou sobre o interesse das imobiliárias em saber sobre a demanda de clientes por imóveis nos bairros de uma cidade, ao longo das épocas do ano, e os tipos de imóveis mais requisitados. A partir disto foi possível perceber que precisaríamos de localização, tipo do imóvel e do fator tempo no DW para poder fornecer informações que fossem úteis. Foi verificado que a localização poderia ser no nível de cidade e bairro. Já o tempo poderia ser dividido ao longo de um ano, trimestre ou mês, pois seriam as características temporais mais convenientes para um gestor imobiliário, conforme sugestão do analista (Etapa 2). Ao analisar as características localização, tipo e tempo, notou-se que as mesmas compõem as dimensões do DW (Etapa 3). Finalmente, foi preciso analisar o que se quer saber sobre essas características, então o empresário informou que seria interessante a soma do preço dos imóvel, e sobretudo a quantidade de imóveis com intenção de compra/aluguel, pois a partir disto é definido o esquema de captação de novos imóveis, sendo um fator fundamental para as imobiliárias.

Com as etapas prontas, foi iniciado o processo de criação do modelo multidimensional, apresentado na Figura 9. Este modelo reúne as dimensões escolhidas na Etapa 2, a tabela de fato com as métricas de venda/aluguel, e tem como base o esquema estrela.

Portanto, o modelo dimensional elaborado foi utilizado como molde para o desenvolvimento do diagrama de ETL (Seção 3.3), pois possibilitou selecionar quais dados seriam necessários para atender à modelagem, e além disso, norteou durante o desenvolvimento do cubo OLAP através do Schema Workbench doPentaho (Seção 3.6).

3.3 PROCESSO DE ETL

A etapa de ETL foi elaborada utilizando o módulo de integração de dados do Pentaho, o Pentaho Data Integration (PDI). Esse módulo permite, através de blocos de execução de denominados steps, criar um diagrama com as operações necessárias para o ETL. Desse modo as conexões com as bases de dados das imobiliárias foram realizadas, assim como as transformações e carga dos dados.

As operações do PDI são executadas através de jobs, que são operações que testam as conexões e os requisitos necessários para prosseguir, e as transformations permitem combinar vários steps de seleção de colunas das tabelas, operações sobre os valores dos campos e junção de fluxos de dados de várias fontes. Para interligar os

(31)

29

Figura 9: Modelagem dimensional realizada para o projeto. Fonte: Próprio autor.

steps utilizamos os hops, que podem copiar os dados entre os steps ou distribuí-los de acordo com a necessidade do projeto.

O Pentaho também permite a utilização da linguagem SQL e diversas linguagens de script. Apenas o SQL foi utilizado no projeto, para consulta aos dados nas bases das imobiliárias e a junção entre tabelas, obtendo, desse modo, as características do imóvel necessárias para o DW. A Figura 10 apresenta uma tela de configuração do step de conexão, que utiliza uma cláusula SQL para fazer a combinação de registros e retornar os dados que seguem no fluxo para os steps posteriores. Este SQL combina o código do imóvel armazenado na tabela de contatos (Vide Figura 1) juntamente com as outras tabelas que armazenam as informações do imóvel propriamente dito, tais como: tipoimovel, cidade, bairro e a tabela imovel, que armazena os valores de venda e aluguel do imóvel.

A Figura 11 apresenta o diagrama do job que foi desenvolvido para o projeto. Cada step deste diagrama possui parâmetros de configuração que são alterados de acordo com o projeto. O steps de conexão permitem configurar os dados para conexões remotas com as bases de dados, através das credenciais de acesso às bases. O step Check Db Connections, por exemplo, verifica se todas as conexões com as imobiliárias e com o DW estão funcionando corretamente. Os steps

(32)

Figura 10: Tela de edição SQL para o step de conexão. Fonte: Próprio autor.

de transformação (Transformation na Figura 11) funcionam como subrotinas, pois possuem internamente os diagramas que processam a transformação.

Figura 11: Job principal. Fonte: Próprio autor.

(33)

31

está contido no step Transformation ETL da Figura 11. O mesmo será detalhado posteriormente em três setores: extração dos dados, seleção dos campos e junção dos fluxos, padronização dos dados e o setor de cálculo da quantidade de imóveis com intenção de compra/aluguel. Esses setores são para simplificar a análise do diagrama e fazem parte do diagrama da Figura 12, desse modo, as Figuras 13, 14 e 17 são ampliações deste diagrama.

Figura 12: Etapa extração, transformação e carga dos dados. Fonte: Próprio autor. A Figura 13 apresenta o primeiro setor na execução do ETL. Nesta etapa são selecionados os campos que serão úteis para o DW através dos steps Selects values, e o fluxo das quatro bases é unido em um único fluxo através dos steps Append streams para que fosse possível realizar as transformações sobre os dados.

A Figura 14 apresenta o segundo setor, no qual ocorre a manipulação dos valores para armazená-los nas dimensões do DW. Por exemplo, a configuração do step "meses"na Figura 14 é detalhado na Figura 15, a qual apresenta o mapeamento do número do mês para o valor literal que será armazenado na dimensão Tempo do DW. Ainda nesse setor, ocorre o mapeamento dos nomes dos bairros, que tinham diferenças entre os bancos. Para exemplificar, enquanto em um banco estava armazenado "Feira X", no outro estava "Feira 10", então foi preciso padronizar esses

(34)

Figura 13: Etapa de extração e seleção dos dados. Fonte: Próprio autor.

dados para ficarem de acordo com o DW. A Figura 16 representa alguns dos valores envolvidos, para os valores fonte e os valores alvo. Além disso, também foram utilizadas transformações de operações sobre strings, que removeram espaços no início e fim e capitalizaram as letras para padronizar os dados. Este processo foi realizado através do trecho representado na Figura 14, utilizando o step String operations.

(35)

33

Figura 15: Mapeamentos dos meses para os respectivos literais. Fonte: Próprio autor.

Figura 16: Mapeamentos dos nomes de bairros. Fonte: Próprio autor.

No último setor, foi preciso atribuir a constante ”1” ao fluxo, quando a intenção de negociação foi enviada e ”0” quando não foi, tanto para aluguel quanto para venda, permitindo posteriormente fazer a soma dos itens e afirmar a quantidade de intenções em compra e/ou aluguel dos imóveis. Para isto foi utilizado o step Switch / Case que verifica se o dado que vem no fluxo é aluguel ou compra. Isto é feito testando o preço do imóvel, se o preço de compra é nulo e o preço de aluguel não, então é para aluguel, e vice-versa, caso exista os dois preços, o imóvel é para aluguel e compra. Finalmente o step Add constants atribui a constante ”1” ou ”0”. Este trecho pode ser visualizado na Figura 17.

Por último, os dados já normalizados são carregados em uma tabela temporária. Isto foi necessário pelo fato de que poderiam haver chaves de imóveis iguais nas diferentes bases, para imóveis distintos, então essa tabela permitiu gerar um identificador único para cada imóvel.

(36)

Figura 17: Etapa de transformação dos dados. Fonte: Próprio autor.

3.3.1 Política de Atualização

Esta seção foi criada especialmente para apresentar a política de atualização do DW, que foi realizada graças ao step Dimension Lookup/Update doPentaho. Este step foi fundamental para as etapas de carga das dimensões e da tabela de fato (Seções 3.4 e 3.5).

O Dimension Lookup/Update (DLU), permite implementar as técnicas Tipo 1 e Tipo 2 por Ralph Kimball. Além de permitir estas atualizações, este step também pode ser utilizado para recuperar valores das dimensões.

O DLU funciona como uma pilha de papéis, cujas informações são válidas em um determinado período de tempo, com uma data de início e fim desse período. Também há um número de revisão que representa a versão da informação ao longo do tempo. A Figura 18 apresenta o conceito descrito.

A Tabela 6 apresenta as principais propriedades utilizadas pelo step DLU. O step recebe o nome de Lookup/Update porque possui essas duas categorias de funcionalidades. O Lookup é o modo de leitura e executa buscas em uma tabela de dimensão que varia lentamente. O Update é o modo de atualização e utiliza as técnicas do Tipo 1 (Atualização) e Tipo 2 (Inserção) para inserir os valores na base de dados.

(37)

35

Figura 18: O DLU contém campos que armazenam as datas em que a informação foi válida e a versão daquela informação. Fonte: Adaptado de (PENTAHO-WIKI, 2013).

Tabela 6: Propriedades do step DLU

Opção Descrição

Chave técnica Chave primária da tabela de dimensão

Campo de versão Mostra a versão do registro na dimensão (número de revisão) Data inicial Data de início da validade do registro

Data final Data de fim da validade do registro Chave naturais Chaves utilizadas nos sistemas fonte

Demais campos Campos que contém as informações da dimensão Fonte: (PENTAHO-WIKI, 2013)

3.4 CARGA DAS DIMENSÕES

A carga das dimensões foi realizada através do uso do step DLU. O modo Update deste step foi utilizado para carregar os dados nas dimensões. A Figura 19 apresenta os diagramas criados para carregar as dimensões. Os dados são lidos da tabela auxiliar e então são carregados através do DLU. Além disso os diagramas da Figura 19, são representados, respectivamente, pelos steps Transformation DIM TIPO, Transformation DIM LOCALIZACAO e Transformation DIM TEMPO do diagrama da Figura 11.

3.5 CARGA DA TABELA DE FATO

A tabela de fato foi carregada utilizando o modo Lookup do step DLU para cada dimensão, de modo a atribuir os valores das chaves estrangeiras na tabela de fato. A Figura 20 apresenta o diagrama desta transformação. Nesse diagrama o step DLU é utilizado para observar cada dimensão e atribuir os valores das chaves. As métricas

(38)

Figura 19: Diagramas de carga das dimensões. Fonte: próprio autor.

vêm no fluxo a partir dos dados da tabela auxiliar, que já passaram pelo processo de ETL. As métricas utilizadas na tabela de fato foram: valor de venda do imóvel, valor de aluguel do imóvel, quantidade de intenções de compra e quantidade de intenções de aluguel.

Figura 20: Etapa de carga dos dados na tabela de fato a partir das dimensões. Fonte: Próprio autor.

(39)

37

3.6 CRIAÇÃO DO CUBO OLAP

OPentaho utiliza um motor OLAP escrito em Java denominado Mondrian. Este utiliza consultas no formato MDX, que é um padrão de expressões multidimensionais desenvolvido pela Microsoft. O Mondrian processa requisições OLAP em bases de metadados XML que utilizam um estrutura específica de cubos OLAP usando os dados das tabelas de dimensões e de fato do DW, e então estes XML são utilizados pelo motor do Mondrian para executar as consultas MDX e fornecer a análise OLAP. Para poder gerar os arquivos XML oPentaho fornece um módulo onde é possível criar visualmente o esquema do cubo OLAP (PENTAHO-MONDRIAN, 2013). A geração desse cubo é essencial para o Pentaho User Console (PUC) que será descrito no capítulo 4.

Inicialmente é preciso configurar a conexão com o DW para o software ter acesso às tabelas de dimensão e de fato. Feito isso, é iniciado o processo de criação do cubo OLAP, selecionando as chaves das dimensões, os respectivos atributos, as métricas da tabela de fato e o tipo de agregação destas métricas, se vai somar, contar, calcular a média, entre outros (PENTAHO-MONDRIAN, 2013).

Com o cubo criado e configurado, foi preciso publicar o mesmo para que estivesse acessível no PUC, o qual apresentará as informações do DW através da análise OLAP.

(40)

4 RESULTADOS E DISCUSSÕES

O Pentaho User Console foi utilizado para obter as informações a partir do cubo OLAP. Trata-se de uma interface Web que permite ao gestor ter fácil acesso às informações do DW.

Ao criar uma nova análise OLAP já é possível selecionar o cubo OLAP que foi publicado pelo Schema Workbench. Ao selecionar o cubo é aberta a tela do OLAP propriamente dito. Essa tela é apresentada na Figura 21, na qual já é possível visualizar as dimensões, as métricas e fazer as operações de Drill up, Drill down e Drill across, além de permitir configurar o cubo OLAP. Ainda é possível escolher quais métricas e dimensões devem aparecer e, sobretudo, existe a possibilidade de gerar gráficos a partir das operações realizadas.

Figura 21: Tela do OLAP. Fonte: Próprio autor.

Ao fazer um Drill down na dimensão de tipo obtemos as medidas separadas pelo tipo de imóvel, conforme apresentado na Figura 22. Podemos ainda fazer operações mais complexas para responder aos diversos questionamentos. Por exemplo, se desejarmos saber o valor total envolvido e a quantidade de apartamentos com intenção de compra em Feira de Santana no bairro Centro no terceiro trimestre de 2013. Então, fazemos um Drill down em tipo, em seguida em localização, encontrando a cidade desejada, logo depois, em tempo e ano, até podermos visualizar as informações que nos interessam, que para este exemplo nos apresentou 4 intenções de compra e um total de R$ 639.900,00. O caminho desta informação pode ser visualizado na área destacada da Figura 23.

(41)

39

Figura 22: Drill-down na dimensão de tipo de imóvel. Fonte: Próprio autor.

Figura 23: Exemplo de visualização de informação através do OLAP. Fonte: Próprio autor.

A partir disto é possível gerar gráficos, por exemplo, para a demanda de compra e aluguel por tipos de imóvel, como pode ser visto na Figura 24. É possível observar também através deste gráfico uma demanda maior por casa, casa em condomínio e apartamento, em ordem decrescente. Já para aluguel, a demanda é maior para casa em condomínio, apartamento e casa, o que poderia indicar que as pessoas que alugam, procuram imóveis que ofereçam maior segurança, por exemplo, ou seja, é possível começar a obter informações intrínsecas ao negócio que não seriam fáceis de visualizar sem um sistema de DW.

(42)

Figura 24: Demanda de imóveis por venda/aluguel por tipo de imóvel. Fonte: Próprio autor.

Já para a demanda de compra e aluguel por bairro foi obtido o gráfico da Figura 25, demostrando que no momento, a demanda por compra é maior nos bairros Sim, Tomba e Santa Mônica, respectivamente. Já para aluguel, a demanda é maior nos bairros Sim, Santa Mônica e Centro.

(43)

41

Figura 25: Demanda de imóveis por venda/aluguel por bairro. Fonte: Próprio autor.

Outro tipo de gráfico que pode ser gerado é o de linha de tempo, o qual fornece a variação da métrica ao longo do tempo. Por exemplo, se desejarmos saber como está variando o quantidade de intenções em compra/aluguel ao longo dos últimos três trimestres de 2013, fazemos a consulta OLAP apresentada na Figura 26, que nos fornece o gráfico de linha de tempo apresentado na Figura 27. O gráfico então informa que as intenções em compra/aluguel aumentaram e que as intenções em compra são aproximadamente três vezes maior que as intenções em aluguel no quarto trimestre. No segundo trimestre, que foi quando iniciou o processo de obtenção dos dados, é possível observar que os mesmos ainda não estavam estabilizados, apresentando uma proximidade entre a quantidade de intenções em compra/aluguel.

(44)

Figura 26: Demanda de compra/aluguel nos três últimos trimestres de 2013. Fonte: Próprio autor.

Figura 27: Gráfico da demanda de compra/aluguel nos três últimos trimestres de 2013. Fonte: Próprio autor.

Um outro exemplo de informação seria qual o mês dos últimos três trimestres que apresentou maior quantidade de intenções em compra de imóvel, e qual o mês nos últimos três trimestres que apresentou maior quantidade em aluguel. A Figura 28 apresenta a análise OLAP para este caso. Essa análise nos informa que o mês com maiores intenções em compra foi outubro, com 31 intenções, já o mês como maiores intenções em aluguel foi setembro, com 14 intenções.

(45)

43

Figura 28: Gráfico da demanda de compra/aluguel para os meses dos três últimos trimestres de 2013. Fonte: Próprio autor.

Desse modo, através da análise OLAP e dos gráficos gerados a partir deste, foi possível encontrar informações para os mais diversos questionamentos, conforme visto nos resultados obtidos. Sobretudo, foi possível fazer a integração dos dados a partir das diversas fontes, o que contribui para a empresa que forneceu acesso a esses dados, no sentido de conhecer a importância e necessidade de um DW, tanto para a integração, quanto para as informações obtidas a partir do mesmo. O empresário se mostrou interessado com os resultados, apesar de ciente que foram apenas dados de intenções de compra/aluguel, citou que foi importante para iniciar o desenvolvimento de um projeto sólido para a empresa, de modo a utilizar dados reais de compra/aluguel a partir da imobiliárias e lançar um novo produto de gestão de informação a partir disto.

(46)

5 CONSIDERAÇÕES FINAIS

Este trabalho teve como finalidade o desenvolvimento de um modelo de DW para interesses de negociação no setor imobiliário feirense. Para isso, passou por um processo envolvendo modelagem, geração de modelo, ETL, projeto do DW e do cubo OLAP. Os resultados demonstraram o potencial de operações que podem ser realizadas no referido setor, como a análise de dados oriundos de diferentes bases de dados. Neste contexto, vale ressaltar o processo automático de ETL realizado através doPentaho. Ademais, a construção do modelo permitiu o entendimento dos processos envolvidos no setor imobiliário de Feira de Santana. A modelagem desenvolvida foi flexível, pois permite ser adequada às necessidades da empresa, conferindo robustez quanto às informações fornecidas através da análise OLAP e, além disso, serve como base para futuras modificações do modelo multidimensional. Neste sentido, o projeto também propiciou iniciar uma parceria com um empresário consultor, que viu potencial quanto aos resultados obtidos através deste trabalho e interessou-se em dar continuidade ao projeto com vistas a fornecer um produto comercial para as empresas imobiliárias de Feira de Santana, utilizando como cerne os conceitos e métodos aqui utilizados, assim como o DW desenvolvido, aprimorando-o de acordo com a necessidade das futuras modificações.

Infelizmente os resultados do OLAP foram limitados para o presente trabalho, pois houve o problema da falta de mais dados históricos e, acima de tudo, pelo fato de serem intenções de negociação e não a negociação finalizada em si, como alertado desde do princípio, entretanto isso não implica em um problema no produto almejado para a empresa, pois poderemos obter dados reais de negociação ao longo do tempo, através da acesso às fontes de dados internas das imobiliárias, assim que permitido o acesso pelas mesmas após a aquisição do produto.

A perspectiva, firmada a referida parceria com o empresário, é investigar mais características e métricas dos imóveis, assim como acrescentar novas dimensões ao projeto do DW como, por exemplo, a dimensão de cliente, que irá avaliar o perfil dos clientes das empresas imobiliárias.

Desse modo, o projetou possibilitou um grande aprendizado sobre os conceitos e processos envolvidos no projeto e construção de um DW, assim como teve a iniciativa de difundir e expandir o uso dessa tecnologia no âmbito regional de Feira de Santana, mostrando que é possível utilizá-la com sucesso, não apenas em grandes organizações, mas também em setores menores.

(47)

45

REFERÊNCIAS

BRUZAROSCO, Donizete; CASTOLDI, André; PACHECO, Roberto. Criando datawarehouse com o modelo dimensional. ISSN 1415-6814: Acta Scientiarum, 2000.

INMON, W. H.Building The Data Warehouse. New York: John Wiley and Sons, Inc., 2002.

KIMBALL RALPH; ROSS, M.The Data Warehouse Toolkit: the complete guide to dimensional modeling. 2. Ed. [S.l.]: Wiley Computing Publishing: New York, 2002. KIMBALLGROUP. Business Intelligence And Data Warehouse Experts. 2013. Disponível em: <http://www.kimballgroup.com/>. Acesso em: 26 setembro 2013. MACHADO, F. N. R.Tecnologia e Projeto de Data Warehouse. São Paulo: Editora Érica., 2004.

NEOGRID. Neogrid e-Collaboration Suite. 2013. Disponível em: <http://hub04.neogrid.com.br/Docs/help/pt_BR/release_notes.htm>. Acesso em: 10 julho 2013.

PENTAHO-MONDRIAN. Mondrian Documentation. 2013. Disponível em: <http://mondrian.pentaho.com/documentation/>. Acesso em: 11 novembro 2013. PENTAHO-WIKI. Dimension Lookup-Update. 2013. Disponível em: <http://wiki.pentaho.com/display/EAI/Dimension+Lookup-Update>. Acesso em: 20 novembro 2013.

PONNIAH, P.Data Warehousing Fundamentals For IT Professionals. New Jersey: John Wiley and Sons, Inc., 2002.

SINGH, H. S. Data Warehouse: Conceitos, Tecnologias, Implementação e Gerenciamento. São Paulo: Makron Books., 2001.

URBANEK, S. Cube, Dimensions, Facts and Measures. 2013. Disponível em: <http://pythonhosted.org/cubes/introduction.html>. Acesso em: 11 setembro 2013.

Referências

Documentos relacionados

Não obstante a reconhecida necessidade desses serviços, tem-se observado graves falhas na gestão dos contratos de fornecimento de mão de obra terceirizada, bem

Com a mudança de gestão da SRE Ubá em 2015, o presidente do CME de 2012 e também Analista Educacional foi nomeado Diretor Educacional da SRE Ubá e o projeto começou a ganhar

A versão reduzida do Questionário de Conhecimentos da Diabetes (Sousa, McIntyre, Martins &amp; Silva. 2015), foi desenvolvido com o objectivo de avaliar o

Neste estudo foram estipulados os seguintes objec- tivos: (a) identifi car as dimensões do desenvolvimento vocacional (convicção vocacional, cooperação vocacio- nal,

Ficou com a impressão de estar na presença de um compositor ( Clique aqui para introduzir texto. ), de um guitarrista ( Clique aqui para introduzir texto. ), de um director

Neste tipo de situações, os valores da propriedade cuisine da classe Restaurant deixam de ser apenas “valores” sem semântica a apresentar (possivelmente) numa caixa

ed è una delle cause della permanente ostilità contro il potere da parte dell’opinione pubblica. 2) Oggi non basta più il semplice decentramento amministrativo.

Os resultados são apresentados de acordo com as categorias que compõem cada um dos questionários utilizados para o estudo. Constatou-se que dos oito estudantes, seis