Uma Plataforma Analítica para Suporte à Gestão de Portos Marítimos

Transcrição

1 Uma Plataforma Analítica para Suporte à Gestão de Portos Marítimos Sandrina Maciel 1, Sónia Sousa 1 1 Mestrado de Informática, Departamento de Informática, Universidade do Minho, Campus de Gualtar, , Braga, Portugal pg11096@alunos.uminho.pt, pg10919@alunos.uminho.pt Resumo. Os sistemas de data warehousing são apresentados aos executivos a partir de plataformas analíticas OLAP, oferecendo um suporte à tomada de decisão nas organizações. É com base nas ferramentas e tecnologias disponibilizadas pelos sistemas de data warehousing, que os agentes de tomada de decisão obtêm resultados que lhes permitem tomar opções acertadas, de forma rápida [1]. Os sistemas de data warehousing incluem ferramentas capazes de extrair dados de diversas fontes. Os dados passam por um processo de transformação antes de sua integração, feita de forma periódica, no sistema. Estes são agrupados por área de negócio e apresentam, desta forma, vistas multidimensionais sobre as diversas áreas contempladas pelo sistema. Os resultados obtidos são apresentados ao utilizador num ambiente poderoso com um interface agradável e de fácil manuseamento. O presente artigo descreve todo o processo de criação de uma plataforma analítica para a gestão de portos marítimos. Palavras-Chave: OLAP, Data Warehouse, Sistemas de Suporte à Decisão, ETL, Base de Dados relacionais. 1 Introdução A Lei de Modernização dos Portos (8630/93) tem trazido novos desafios à indústria marítima relacionados com o aumento de carga e congestionamento nos portos, o fluxo rodoviário e ferroviário, a utilização de navios de contentores e a busca de expansão da sua capacidade [12]. Tais desafios aumentam a complexidade da estrutura organizacional dos portos que se vêem na necessidade de controlar e aproveitar a informação que neles circula [2]. Uma solução para superar os desafios do sector passa pela implementação de um sistema de suporte à decisão que permita à gestão portuária medir os efeitos das mudanças de variáveis de capacidade operacional, tecnológica e de investimento e, assim, apoiar seus executivos no processo de tomada de decisão [13]. As plataformas analíticas OLAP (On-Line Analytical Processing) fazem parte da categoria dos sistemas de suporte à decisão e são vistas como ferramentas que

2 permitem aos analistas, gestores e administradores obter de uma forma rápida, eficiente e consistente, ganhos a partir dos dados presentes no seio da organização. As ferramentas OLAP apresentam ao utilizador diversas vistas sobre a realidade da organização [14]. As análises multidimensionais, que caracterizam as plataformas OLAP, permitem aos utilizadores efectuarem uma série de consultas e operações sobre os dados da organização, tais como cálculos sobre as dimensões consideradas ou análises temporais. Os resultados fornecidos pelas plataformas analíticas OLAP são obtidos pelo uso de modelos multidimensionais de armazenamento e apresentação da informação. Os dados são organizados em cubos, definidos por um espaço multidimensional e constituídos por várias dimensões que englobam um conjunto de níveis de agregação [14]. A materialização dos cubos é conseguida com recurso a sistemas de data warehousing que envolvem todo um processo de selecção e transformação prévia dos dados antes de seu carregamento para o cubo. São as ferramentas de ETL (Extract, Transform, Load) que impulsionam estes resultados já que são responsáveis pela extracção dos dados de uma ou diversas fontes, pela sua limpeza, pela sua padronização e inserção no sistema de data warehousing [7]. O projecto aqui apresentado inferiu na implementação de uma plataforma analítica como forma de suporte às actividades da gestão portuária, cujos dados em análise foram extraídos do sistema operacional de uma solução de gestão portuária. A plataforma foi desenvolvida recorrendo iniciando-se com a extracção dos dados em estudo pela ferramenta ETL e finalizando-se com a disponibilização de recursos para consultas e operações sobre os resultados obtidos. 1.1 Motivação Os sistemas operacionais que suportam a actividade de uma organização são utilizados para registar as inúmeras transacções que decorrem no dia-a-dia da organização. As transacções registadas são estruturadas, repetitivas e atómicas. Os sistemas operacionais estão preparados para responder a queries relativamente simples no mínimo de tempo possível de modo a facultar suporte à organização nas suas actividades diárias. Contrariamente, as plataformas analíticas são projectadas para dar suporte à decisão. Dados históricos, sumarizados e consolidados que possibilitam o entendimento das tendências e permitem fazer predições são, como tal, mais importantes do que registos detalhados e individuais. Os responsáveis pela gestão portuária, vulgo, as entidades da administração portuária, sentiram a necessidade de analisar a evolução da rentabilidade dos seus portos, assim como fazer previsões sobre possíveis acontecimentos. As respostas que eles precisavam teriam de lhes ser facultadas em tempo real e mediante as suas necessidades. Esta crescente necessidade por parte da gestão portuária justificou o desenvolvimento desta plataforma analítica descrita nas próximas secções deste artigo.

3 1.2 Objectivos O principal objectivo deste projecto incidiu na implementação de uma plataforma analítica para suporte à gestão portuária. Este sistema vai permitir aos administradores e gestores dos portos marítimos tomarem as decisões mais adequadas ao bom funcionamento do porto através de um controlo muito maior sobre a informação que nele circula. Toda a informação relativa aos navios tais como entradas, estadias, saídas será analisada e será possível saber qual a duração da estadia dos navios no porto ou ainda qual a altura do ano com mais movimento no porto. Da mesma forma, será possível saber qual o valor das mercadorias facturadas no porto, qual o peso dessas mercadorias, qual a altura do ano em que são facturadas mais mercadorias. Estes resultados serão obtidos devido às diversas características das plataformas analíticas: Elaborar previsões baseadas em dados históricos, nos desempenhos passados e actuais da organização. Criar cenários que evidenciam o impacto da alteração de diversas variáveis. Permitir o acesso ad-hoc aos dados para responder a questões não prédefinidas Analisar detalhadamente a organização, obtendo um conhecimento mais profundo da mesma [4]. Todo o processo de desenvolvimento da plataforma analítica será feito com recurso à ferramenta SQL Server 2005 Business Intelligence que contém todas as funcionalidades necessárias à construção da plataforma analítica. A ferramenta permite a integração de múltiplas fontes de dados através do módulo Integration Services, o enriquecimento de dados e a criação de complexos processos de análise empresarial através do Analysis Services, e finalmente a elaboração, gestão e disponibilização de relatórios optimizados através do módulo Reporting Services. Com todas estas respostas será disponibilizado um software, considerado como um apoio fundamental para a formulação de estratégias, maximizando os lucros que daí advêm e, por outro lado, visto como uma forma de ajuda para os gestores dos portos descobrirem ineficiências internas e oportunidades de inovação [4]. 2 Estrutura do Sistema Analítico Seguindo a metodologia de Kimball [6], procedeu-se à análise dos requisitos do módulo em estudo, do seu sistema operacional e do seu modelo de negócio. Esta análise levou à identificação de dois possíveis data marts, o data mart Navios e o data mart Mercadorias. O data mart Navios tem por objectivo descrever todo o processo de entradas, estadias e saídas dos navios no porto, enquanto o data mart Mercadorias tem como finalidade apresentar todas as transacções que envolvem as mercadorias. A organização dos dados nos data marts que compõem este projecto é representada por um esquema em estrela cujos dados em análise são agrupados numa tabela conhecida por tabela de factos, situada no centro da estrela e rodeada por tabelas, as chamadas dimensões, que possibilitam a análise à área de negócio [5]. A integridade

4 dos dados da tabela de factos é mantida através das ligações às dimensões, fazendo uso das regras de integridade referencial. Toda a informação necessária para dar resposta às necessidades dos agentes de decisão encontra-se disponível no sistema operacional que se traduz numa base de dados dividida em diferentes esquemas (schemas), dos quais se destacam o CDNM e TARIFARIO, que guardam toda a informação relativa ao módulo. O esquema CDNM armazena toda a informação relativa aos processos que afectam os navios e mercadorias. Por sua vez, o esquema TARIFARIO só intervém quando o processo de um navio é fechado, ou seja, quando é registada, pela administração portuária, a saída de um navio que tenha operado no Porto. Quando isso acontece, os processos encerrados estão prontos a ser taxados, sendo o esquema TARIFARIO a fonte de informação relativa às taxas. Na aplicação, estes processos quando taxados, são transformados em guias para criação de facturas. Fig. 1. Esquema em forma de estrela representativo do data mart Navios Após definir os data marts existentes, tornou-se necessário analisar a granularidade dos factos a serem armazenados. O grão é o nível de detalhe com que os factos são armazenados no data warehouse. É recomendado armazenar os factos no maior nível de detalhe disponível nos sistemas operacionais [6]. Com base na análise feita aos sistemas operacionais acima mencionados, conclui-se que o grão para o data mart Navios é o objecto Aviso de Chegada, já que ele representa todos os processos/documentos de navios que operam no porto de mar, definido na tabela A1_AVISO_CHEGADA. No entanto, apenas os processos fechados são alvo de análise. Por sua vez, o grão para o data mart Mercadorias é o objecto Manifesto, documento onde é registada toda a informação relativa às mercadorias transportadas por um navio registado como um processo/documento no Aviso de Chegada. Este objecto Manifesto é representado pela tabela B1_MANIF_DOC_MERC. Ambas as tabelas representativas dos grãos estão contidas no esquema CDNM.

5 Finalmente, a modelação da estrutura do sistema analítico passa pela definição das dimensões e seus atributos e, pela definição dos factos a serem armazenados de acordo com o grão definido [6]. O data mart Navios, representado pela Figura 1, é composto por quatro dimensões e uma tabela de factos. De acordo com o grão definido para este data mart, a escolha das dimensões foi bastante intuitiva. Como tal, inclui-se a dimensão DIM_AVISOCHEGADA que armazena os dados de cada aviso de chegada (processo) fechado. São igualmente incluídas a dimensão DIM_NAVIOS que guarda alguma informação relativa à ficha do navio, já que a linha de análise incide apenas sobre parte do conteúdo informativo de um navio, a dimensão DIM_TERMINAIS que permite obter dados sobre os terminais onde atracaram os navios no porto e, finalmente, a dimensão DIM_TEMPO que permite uma análise temporal sobre os dados, quer a nível da entrada do navio no porto como da sua saída. As dimensões do data mart Navios têm uma variação muito lenta, como tal os atributos que as compõem não têm nenhuma política de actualização. Independentemente disso, os atributos das dimensões podem sofrer alterações nas suas descrições no caso de erros ortográficos, e nesse caso o atributo é reescrito não guardando registo de valores anteriores. As tabelas que se seguem apresentam a informação relativa a cada atributo das dimensões e tabela de factos do data mart Navios. Tabela 1. Descrição detalhada da dimensão DIMNAVIOS NAVIO Código natural e unívoco de Não actualizável cada navio ID_NAVIO Identificação do Navio (Nº IMO) Não actualizável NOME_NAVIO Nome do navio Não actualizável GT Unidade de arqueação mínima Não actualizável CALADO Calado máximo Não actualizável COMPRIMENTO Comprimento fora a fora Não actualizável BANDEIRA País de origem do navio Não actualizável Tabela 2. Descrição detalhada da dimensão DIMAVISOCHEGADA AVISOCHEGADA Código natural e unívoco de Não actualizável cada aviso de chegada NUM_DOCUMENTO Número do documento Não actualizável apresentado ao utilizador NUM_PROCESSO Número do processo apresentado Não actualizável ao utilizador VERSAO Identifica a versão do documento Não actualizável

6 Tabela 3. Descrição detalhada da dimensão DIMTERMINAIS TERMINAL Código natural e unívoco de Não actualizável cada terminal ID_TERMINAL Código do terminal no sistema Não actualizável operacional DES_TERMINAL Descrição do terminal Reescrever (tipo1) Tabela 4. Descrição detalhada da dimensão DIMTEMPO TEMPO Código natural e unívoco de Não actualizável cada data DIA Dia do mês Não actualizável MES Mês Não actualizável TRIMESTRE Trimestre Não actualizável ANO Ano Não actualizável A tabela de factos é composta pelas chaves de cada uma das suas dimensões e pela medida N_DIAS_ESTADIA. Esta medida define o número de dias de uma estadia de um navio no porto. É, como tal, um número inteiro, calculado através de um somatório. O data mart Mercadorias, representado pela Figura 2, é composto por 7 dimensões e a tabela de factos. De acordo com o grão definido para este data mart, a escolha das dimensões foi bastante facilitada. Como tal, inclui-se a dimensão DIM_MERCADORIAS que armazena os dados de cada mercadoria. São igualmente incluídas a dimensão DIM_PORTOS que guarda a informação relativa aos portos de origem e destino das mercadorias, a dimensão DIM_ENTIDADES que permite obter dados sobre os as entidades que intervêm no processo das mercadorias tais como os clientes, a empresa de estiva ou o importador/exportador, a dimensão DIM_PROCESSOS que representa todos os processos fechados que envolvem mercadorias, a dimensão DIM_TERMINAIS que armazena informação sobre os terminais onde são carregadas e/ou descarregadas as mercadorias, a dimensão DIM_OPERACAO que indica se as mercadorias são cargas ou descargas e, finalmente, a dimensão DIM_TEMPO que permite uma análise temporal sobre os dados.

7 Fig. 2. Esquema em forma de estrela representativo do data mart Mercadorias Tal como foi feito para o data mart Navios, as tabelas que se seguem vão descrever em pormenor os atributos que compõem as dimensões e tabela de factos do data mart Mercadorias. Tal como para o data mart Navios, as dimensões que compõem o data mart Mercadorias têm uma variação muito lenta porque na sua maioria, são resultantes de tabelas do sistema operacional com informação uniformizada, disponibilizada pelo Instituto Nacional de Estatística, como tal os atributos que as compõem não têm nenhuma política de actualização. Mesmo assim e tal como no data mart Navios, os atributos das dimensões podem sofrer alterações nas suas descrições em caso de erros ortográficos, e nesse caso o atributo é reescrito não guardando registo de valores anteriores. As dimensões DIM_TEMPO e DIM_TERMINAIS, visto serem idênticas às dimensões DIM_TEMPO e DIM_TERMINAIS do data mart Navios, não serão novamente detalhadas. Tabela 5. Descrição detalhada da dimensão DIM_MERCADORIAS MERCADORIA Código natural e unívoco de Não actualizável cada mercadoria ID_MERCADORIA Código da mercadoria no Não actualizável sistema opeacional DES_MERCADORIA Descrição da mercadoria Reescrever (tipo 1) ID_SUBTIP_CARGA Código do subtipo de carga Não actualizável DES_SUBTIP_CARGA Descrição do subtipo de Reescrever (tipo1) carga ID_TIPO_CARGA Código tipo de carga Não actualizável DES_TIPO_CARGA Descrição do tipo de carga Reescrever (tipo1)

8 Tabela 6. Descrição detalhada da dimensão DIM_PORTOS PORTO Código natural e unívoco de Não actualizável cada porto ID_PORTO Codigo do Porto no Sistema Não actualizável operacional DES_PORTO Descrição do porto Reescrever (tipo 1) PAIS Descrição do país Não actualizável Tabela 7. Descrição detalhada da dimensão DIM_ENTIDADES ENTIDADE Código natural e unívoco de Não actualizável cada entidade ID_ENTIDADE Código no sistema Não actualizável operacional NOME_ENTIDADE Nome da entidade Reescrever (tipo1) Tabela 8. Descrição detalhada da dimensão DIM_PROCESSOS PROCESSO Código natural e unívoco de Não actualizável cada processo NUM_DOCUMENTO Número do documento do Não actualizável Aviso de Chegada NUM_PROCESSO Número do processo Não actualizável ID_NAVIO Código do navio Nº IMO Não actualizável NOME_NAVIO Nome do navio Reescrever (tipo1) Tabela 9. Descrição detalhada da dimensão DIM_OPERACAO OPERACAO Código natural e unívoco de Não actualizável cada operação ID_OPERACAO Código da operação no Não actualizável sistema operacional DES_OPERACAO Designação da operação Reescrever (tipo1) A tabela de factos é composta pelas chaves de cada uma das dimensões e pelas medidas PESO e VALOR. A medida peso permite obter o peso total das mercadorias, é como tal um número decimal, representado pela unidade Quilogramas, e é calculada através de um somatório. Por sua vez, a medida valor permite saber o valor total das mercadorias com a taxa aplicada. É igualmente um número decimal, representado pela unidade euro, e calculado através de um somatório.

9 3 Definição e Caracterização do Sistema de Preparação e Povoamento 3.1 Definição Preliminar dos planos de Extracção, Transformação e Integração dos Dados A implementação de um sistema de data warehousing vê pelo menos um terço do seu orçamento gasto no desenvolvimento do ETL [7]. Tais dados evidenciam claramente a complexidade e sensibilidade do desenvolvimento do ETL na construção do sistema de data warehousing. De modo a evitar erros no processo, é necessário planear o processo de ETL revendo certos conceitos e apresentando decisões e técnicas a serem tidas em conta no processo de desenvolvimento. O processo de extracção dos dados das suas fontes pode revelar-se bastante consumidor de recursos computacionais e pode inviabilizar o bom funcionamento dos sistemas operacionais se não forem definidas as estratégias adequadas. Assim, idealmente, o processo de extracção deverá decorrer num horário em que a utilização do sistema operacional seja a mais reduzida possível. Mediante a iteração em que o processo de ETL é invocado (primeiro dia ou restantes), o processo de extracção irá decorrer de modo distinto. Assim, numa primeira invocação, o processo de extracção irá requisitar a totalidade dos dados contidos no sistema operacional. Nas fases seguintes, poderia cair-se na tentação de repetir este processo. No entanto, isto iria revelar-se extremamente ineficiente devido à quantidade enorme de dados a serem transferidos. Deste modo, na segunda fase apenas vão ser recolhidos os dados que foram recentemente actualizados ou adicionados. Esta distinção é conseguida recorrendo-se a tabelas de auditoria, que visto não existirem no actual sistema operacional, foram necessariamente criadas. O preenchimento das tabelas de auditoria é feito de forma automática por triggers que são automaticamente despoletados quando são inseridos ou alterados registos sobre as tabelas que povoam o data warehouse. Após extrair os dados, é necessário transformá-los antes de serem enviados para o data mart. Estas transformações vão ser feitas em tabelas auxiliares presentes na área de retenção que vão permitir, entre outras coisas, a execução de todos os cálculos necessários para obter o valor das mercadorias. Finalmente, surge a parte relativa ao povoamento dos data marts dividida em duas fases. A primeira fase envolve o povoamento da estrela pela primeira vez, enquanto a segunda fase abrange o povoamento dos restantes dias. O povoamento da estrela pela primeira vez obriga ao povoamento de todas as dimensões, enquanto os restantes povoamentos estão relacionados com mudanças no sistema operacional, isto significa que somente as dimensões que armazenam informação de tabelas que tenham sofrido alterações no sistema operacional são alteradas. Como tal, cada novo povoamento tem uma carga computacional diferente que varia consoante as alterações do sistema operacional. As dimensões apresentam diferentes características de povoamento. A dimensão DIM_TEMPO surge nos dois data marts e o seu comportamento é idêntico em ambos. O seu povoamento é efectuado uma única vez recorrendo a um script de geração de datas para um período de 20 anos. As restantes dimensões vão ser

10 povoadas totalmente na primeira iteracção. Nas seguintes elas serão preenchidas mediante um evento particular que, no caso do data mart Navios, será quando for registado o fecho do processo de um navio, por parte da Administração Portuária, ou quando um navio existente sofrer alguma alteração, enquanto no caso do data mart Mercadorias, será quando forem fechados processos que contenham documento de registo de mercadorias a operar (Manifesto). Todo o processo de Extracção, Transformação e Carregamento dos dados para o sistema de data warehousing será despoletado de 24 em 24 horas e, uma vez que o sistema operacional sofre menos alterações no período nocturno, o processo de ETL ocorrerá no inicio de cada dia extraindo do sistema operacional os dados inseridos ou alterados no dia anterior. 3.2 Os Processos de ETL Tendo em vista o povoamento do data warehouse, torna-se necessário criar uma área intermédia, designada por área de retenção (staging area), que auxiliará o ETL durante todo o seu processo. O papel da área de retenção é versátil e engloba funções tais como realizar todas as transformações e limpezas necessárias sobre os dados, evitar que a fonte de dados realize essas tarefas, agir como moderador do sistema de data warehousing no caso de este não conseguir lidar com o tráfego vindo da fonte de dados, ou realizar várias tarefas como resumir a preparação do ETL e gerir a qualidade do serviço [8]. É, como tal, necessário projectar e desenvolver uma base de dados auxiliar para conter as estruturas necessárias para apoiar o processo de povoamento dos data marts. Sendo a primeira etapa do processo de ETL a extracção dos dados das suas fontes, torna-se necessário armazená-los em tabelas temporárias que permitam evitar suas repetidas extracções em caso de falha do processo. Estas tabelas permitem, deste modo, extrair apenas os dados que ainda não o tinham sido previamente. Para isso, além dos atributos que permitem armazenar os dados extraídos e que devem ter os mesmos tipos de dados dos atributos das tabelas do sistema operacional, é também necessário adicionar a estas tabelas atributos que permitam identificar o tipo de operação, inserção ou actualização, que foi realizada sobre os dados. A Figura 3 apresenta as tabelas que auxiliam o processo de extracção dos dados do sistema operacional para o data mart Navios.

11 Fig. 3. Tabelas que auxiliam a fase de extracção dos dados do sistema operacional O sistema operacional possui uma cópia das tabelas presentes na Figura 3, assim como as tabelas que auxiliam a extracção dos dados para o data mart Mercadorias. Estas tabelas são preenchidas através da execução de triggers e que são activados quando é despoletada uma acção pré-definida. Após a fase da extracção dos dados surge a fase de transformação destes. Os dados que vão povoar o data mart Navios são coerentes e como tal não necessitam de passar por nenhuma transformação de maior complexidade, indo directamente das tabelas de auditoria do sistema operacional para o data mart. Embora haja a necessidade do cálculo do número de dias da estadia de um navio/processo, este valor pode ser calculado de forma rápida e armazenado na tabela de auditoria aquando o despoletar do trigger sem fazer uso de tabelas auxiliares. Por sua vez, existem dados que vão ser carregados para o data mart Mercadorias sofrendo certas transformações para permitir efectuar os cálculos sobre o valor das mercadorias. Vão, como tal, ser armazenados numa tabela auxiliar na área de retenção de modo a passar por todas as transformações necessárias antes de povoarem o data mart. A etapa que se segue refere-se ao povoamento dos data marts. Como já foi referido este processo divide-se em duas fases, o povoamento do primeiro dia e o povoamento dos restantes. Visto os dois data marts possuírem duas dimensões idênticas, a dimensão DIM_TEMPO e a dimensão DIM_TERMINAIS, o povoamento dos dois data marts vai ser feito em simultâneo. Para mais fácil entendimento do processo de povoamento, a explicação de ambas as fases vai ser apresentada numa secção separada. Povoamento dos Data Marts: 1º dia Este processo vai decorrer apenas uma vez, o data warehouse vai ser preenchido com toda a informação útil existente no sistema operacional.

12 O povoamento da dimensão DIM_TEMPO, partilhada por ambos os data marts, é distinto do povoamento das restantes dimensões. O seu povoamento é feito com recurso a um script SQL que gera datas diárias para um período de 20 anos, iniciando esse periodo a dia 1 de Agosto de 2008 visto ser nessa data que a aplicação para apoio à gestao portuária ficou disponível, e as insere na dimensão DIM_TEMPO. No primeiro dia, as dimensões de ambos os data marts são preenchidas com os dados vindos das tabelas do sistema operacional. Após povoar as dimensões são povoadas ambas as tabelas de factos. A Figura 4 apresenta os fluxos de dados do data mart Navios e do data mart Mercadorias no seu primeiro povoamento. Fig. 4. Fluxo de dados no 1º povoamento dos data marts Navios e Mercadorias Povoamento dos Data Marts: Restantes Dias O povoamento dos data marts nos restantes dias tem por objectivo actualizar o data warehouse de acordo com as ocorrências dos sistemas ao longo do dia. Assim no final do dia é extraída toda a informação das tabelas de auditoria existentes no sistema operacional, que são diariamente alimentadas por triggers, para, após serem realizadas todas as transformações necessárias sobre os dados, estes preencherem o data warehouse usando as técnicas descritas nos capítulos anteriores. No final do processo, torna-se necessário limpar todas as tabelas auxiliares, para no dia seguinte conterem apenas novos registos. A grande diferença entre estes povoamentos e o ocorrido no primeiro dia resulta na quantidade de dados bem menor a ser processada. A dimensão DIM_TEMPO é povoada totalmente no primeiro dia, não precisando como tal de ser alterada nos restantes povoamentos. A Figura 5 ilustra os fluxos de dados dos dois data marts no povoamento dos restantes dias.

13 Fig. 5. Fluxo de dados nos restantes dias do povoamento dos data marts 4 Ambiente de Exploração das Ferramentas Utilizadas Nas secções anteriores foram apresentadas e descritas as etapas para o povoamento do sistema de data warehousing. Nesta fase, os dados obtidos estão armazenados nos chamados cubos presentes no sistema. Um cubo de dados, em termos técnicos, não é mais do que uma projecção multidimensional redundante de uma relação, tendo sido proposto como uma generalização do operador SQL Group-By [10]. Um cubo pode ser visualizado como uma grelha multidimensional construída a partir dos valores das dimensões. O processamento analítico on-line (OLAP Online Analytical Processing) permite analisar informação de um cubo dimensional em vários níveis de foco e agregação. Existem quatro tipos de operações mais usuais utilizadas para analisar dados nas ferramentas OLAP. Estas operações são drill-down, roll-up e slice and dice [11]. A estrutura do cubo Navios, representada pela Figura 1, identifica quatro dimensões: DIM_TEMPO (com hierarquia ANO TRIMESTRE MES DIA), DIM_NAVIOS (com as hierarquias ID_NAVIO VERSAO NOME_NAVIO, GT ID_NAVIO VERSAO NOME_NAVIO, CALADO ID_NAVIO VERSAO NOME_NAVIO e COMPRIMENTO ID_NAVIO VERSAO NOME_NAVIO), DIM_AVISOCHEGADA (com as hierarquias: NUM_DOCUMENTO VERSAO e NUM_PROCESSO VERSAO) e DIM_TERMINAIS. A medida associada a esse cubo é N_DIAS_ESTADIA que representa o número de dias que um navio está atracado no porto. Ao processar o cubo é possível obter resultados em relação às diversas dimensões em análise. É possível, por exemplo saber o número de dias que um determinado navio ficou num

14 determinado terminal em todo o período em análise (desde o início até à data), agrupando estes resultados por trimestres. Mas pode-se, por exemplo, aplicar slice no cubo e determinar que a mesma análise vai ser feita somente no ano É possível, igualmente, fazer drill-down sobre a hierarquia da dimensão DIM_TEMPO e obter os resultados por mês. Inversamente, aplicando roll-up na hierarquia da dimensão DIM_TEMPO, é possível obter os mesmos resultados agrupados por ano. Por sua vez, a estrutura do cubo Mercadorias, evidenciada pela Figura 2, apresenta seis dimensões DIM_TEMPO (ANO TRIMESTRE MES DIA), DIM_PORTOS (com a hierarquia: PAIS DES_PORTO), DIM_ENTIDADES, DIM_MERCADORIAS (com hierarquia DES_TIPO_CARGA DES_SUBTIP_CARGA DES_MERCADORIA), DIM_PROCESSOS e DIM_TERMINAIS. Por sua vez, existem duas medidas, PESO e VALOR, associadas a este cubo. Processando os dados do cubo Mercadorias, é possível obter respostas a perguntas tais como qual o valor das mercadorias facturadas, por tipo de carga, no Porto x até à data?, qual o valor das mercadorias facturadas, por tipo de carga, no Terminal y até à data?, ou ainda aplicar essas questões relativamente ao peso total das mercadorias. Aplicando o slice no cubo, é possível igualmente restringir os resultados ao ano de 2009, agrupando estes por mês. Pode-se, igualmente, fazer drilldown sobre a hierarquia da dimensão DIM_MERCADORIAS e obter os resultados por subtipo de carga ou ainda fazer roll-up sobre a hierarquia da dimensão DIM_TEMPO e agrupar os resultados por trimestre. Os resultados obtidos com o processamento dos cubos são apresentados aos utilizadores sob forma de gráficos, tabelas ou relatórios manipuláveis mediante as necessidades do utilizador como evidenciado pelas figuras 6 e 7. Fig. 6. Gráfico que apresenta o peso total das mercadorias em diversos terminais

15 Fig. 7. Tabela que apresenta o valor/peso das mercadorias facturadas para um certo cliente 5 Conclusões Apesar da plataforma analítica ter sido implementada, o desenvolvimento do projecto nem sempre decorreu como o que era pretendido. O sistema operacional do qual extraímos os dados é armazenado no sistema de gestão de base de dados da Oracle, como tal e para obter uma melhor integração dos dados avançamos com o desenvolvimento do sistema de data warehousing recorrendo às ferramentas disponibilizadas pelo mesmo fabricante (Oracle Warehouse Builder). Porém, por falta de formação, tivemos de desistir dessa ferramenta já numa fase bastante avançada do projecto, já que está à partida seria pouco intuitiva para um manuseamento satisfatório, e optamos pelo SQL Server 2005 Business Intelligence com o qual já tinhámos desenvolvido um projecto no âmbito académico. Este obstáculo dificultou e atrasou bastante o desenvolvimento do projecto. Podemos igualmente salientar que mais data marts poderiam ter sido desenvolvidos. Ou seja, a plataforma desenvolvida não está completa pois pelo menos mais um data mart foi identificado. Porém devido às limitações de tempo impostas pelo projecto optamos por não desenvolver mais do que os dois data marts apresentados neste artigo. Futuramente, poderão ser desenvolvidos os restantes data marts identificados de modo a completar a solução. Finalmente, esta plataforma foi desenvolvida num ambiente real, todos os dados utilizados existem de facto. Tivemos algum problema em obter a informação necessária à elaboração deste projecto atempadamente que atrasou ainda mais a obtenção dos resultados finais. Por outro lado, outro entrave para uma melhor perspectiva de funcionamento da nossa plataforma, é a escassez de informação.

16 Apesar da aplicação estar disponível desde 1 de Agosto de 2008 para vários clientes (Portos de Mar), as suas actividades apenas começaram a ser registadas, no sistema operacional utilizado, no início do presente ano, e apenas um porto já havia fechado processos de navios com e sem mercadorias movimentadas. Foi com base na informação deste porto que desenvolvemos a plataforma analítica aqui relatada. Referências 1. Chaudhuri, S., Dayal, U.: An overview of data warehousing and OLAP technology. ACM SIGMOD Record, Vol. 26, Issue 1. ACM, New York (1997) Kimball, R., Merz, R., Ross, M.: The Data Warehouse Toolkit. The Complete Guide to Dimensional Modeling (2nd edition). John Wiley & Sons, New York (2002) 3. Gupta, H., Harinarayan, V., Rajamaran, A., Ullman, J.D.: Index selection for OLAP. Proc. of International Conference on Data Engineering (ICDE), Burmingam U.K. (1997) Santos, M.Y., Ramos, I.: Como tornar o seu negócio realmente competitivo: desafios tecnológicos e de gestão. CXO: tecnologias de informação para executivos, Portugal. (2006) Bonifati, A., Cattaneo, F., Ceri, S., Fuggetta, A., Paraboschi, S.: Designing Data Marts for Data Warehouses. ACM Transactions on Software Engineering and Methodology, Vol. 10, No. 4, New York (2001) Kimball, R., Reeves, L., Ross, M., Thornthwaite, W.: The Data Warehouse Lifecycle Toolkit: Expert Methods for Designing, Developing, and Deploying Data Warehouses. John Wiley & Sons, New York (1998) 7. Vassiliadis, P., Simitsis, A., Skiadopoulos, S.: Conceptual modeling for ETL processes. Data Warehousing and OLAP, Proceedings of the 5th ACM international workshop on Data Warehousing and OLAP, ACM, New York (2002) Karakasidis, A., Vassiliadis, P., Pitoura, E.: ETL queues for active data warehousing. Information Quality in Informational Systems, Proceedings of the 2nd international workshop on Information quality in information systems, ACM, New York (2005) Lachev, T.: Applied Microsoft Analysis Services 2005: And Microsoft Business Intelligence Platform. Prologika Press, USA (2005) 10. Gray, J., Bosworth, A., Layman, A., Pirahesh, H.: Data Cube: A Relational Aggregation Operator Generalizing Group-By, Cross-Tab, and Sub-Totals. Proceedings of the 12th International Conference on Data Engineering, IEEE, New Orleans (1996) 11. Machado, F.: Projeto de Data Warehouse: Uma Visão Multidimensional, Érica, São Paulo (2000) 12. Hyland, T.: Four east coast ports share growth strategies. Transportation &Distribution (2001) 13. WADHWA, L., C.: Capacity and performance of bulk handling ports. Proceedings of Australian Transport Research Forum, Vol 15, Part 1(1990) 14. Vassiliadis, P., Sellis, T.: A survey of logical models for OLAP databases, ACM, New York (1999) 64-46