FÁBIO HIDEKI GUTIYAMA RENAN LOTTO SACILOTTO Desenvolvimento de um data warehouse para o processo de decisão em uma empresa de telecomunicações São Paulo 2009
FÁBIO HIDEKI GUTIYAMA RENAN LOTTO SACILOTTO Desenvolvimento de um data warehouse para o processo de decisão em uma empresa de telecomunicações Monografia apresentada à Escola Politécnica da Universidade de São Paulo para Conclusão do Curso de Engenharia de Computação Orientador: Prof. Dr. Jorge Rady de Almeida Jr. São Paulo 2009 2
3
4
FÁBIO HIDEKI GUTIYAMA RENAN LOTTO SACILOTTO Desenvolvimento de um data warehouse para o processo de decisão em uma empresa de telecomunicações Monografia apresentada à Escola Politécnica da Universidade de São Paulo para Conclusão do Curso de Engenharia de Computação São Paulo 2009 5
ERRATA PÁGINA LINHA ONDE SE LÊ LEIA-SE 6
DEDICATÓRIA A todas as pessoas que nos ajudaram diretamente ou indiretamente na realização deste trabalho. 7
AGRADECIMENTOS Prof. Dr. Jorge Rady de Almeida Jr., pela orientação durante todo o desenvolvimento do trabalho, e também pela compreensão nas fases onde a dedicação ao trabalho não pode ser grande. Toda a equipe da empresa In.voice que esteve envolvida com o sistema, por disponibilizarem as informações necessárias e por se colocarem a disposição para ajudar. Raphael Mielle Trintinalia e Vitor Araujo Romera, por aceitarem liberar um integrante da equipe para que este trabalho pudesse ser realizado. Deus, por ter evitado que meu laptop fosse roubado com grande parte da monografia. 8
9
10
RESUMO O sistema baseado em data warehouse desenvolvido tem por objetivo auxiliar a solução de problemas da empresa In.voice, a empresa cliente deste projeto. O grande problema abordado diz respeito à manipulação de uma grande quantidade de dados e, conseqüentemente a perda de eficiência na geração de relatórios que utilizam bases de dados tradicionais. O uso de um data warehouse é uma das possíveis soluções para reduzir o tempo de resposta do sistema e apresentar as informações de maneira mais fácil de ser visualizada, assim, este trabalho propõe a modelagem e desenvolvimento da solução baseada em data warehouse para a empresa em questão. O trabalho desenvolvido foi realizado e documentado por etapas com a finalidade de facilitar futuros trabalhos que tenham por objetivo desenvolver sistemas baseados em data warehouse. 11
ABSTRACT The data warehouse system developed aims to solve real problems of In.voice, a company considered the client of this project. The main problem analyzed was about the great amount of data managed by usual relational database systems that took a long time to generate reports. The data warehouse technology seemed to be one of the possible solutions for this kind of problem, aiming the quality of information provided by data and response time of the entire system. This work proposes to model and develop the data warehouse solution for In.voice company. The development was made and wrote by steps, so future articles that aim to implement data warehouse systems will find this document useful. 12
LISTA DE ILUSTRAÇÕES Figura 1 - Modelo Estrela Genérico... 27 Figura 2 - Interface de usuário do pgadminiii... 32 Figura 3 - Interface de Usuário do Pentaho Data Integration... 33 Figura 4 - Interface de usuário do jpivot, acessando o serviço OLAP do Mondrian.. 35 Figura 5 - Interface de usuário do Schema Workbench... 36 Figura 6 - Interface de usuário do Pentaho BI Studio... 37 Figura 7 Modelo dimensional modelado... 41 Figura 8 - Modelo básico de ETL de carga de dimensões... 44 Figura 9 - Modelos de ETL de carga de tabelas-fato (a) série; (b) paralelo... 46 Figura 10 Modelo Multidimensional no Schema Workbench.... 47 Figura 11 - Hierarquia de tempo definida... 49 Figura 12 - Diversos fluxos de carga das dimensões... 50 Figura 13 - ETL da Tabela fato_registro... 51 Figura 14 Tela de boas vindas do sistema web Pentaho BI Studio.... 53 Figura 15 Tela de entrada no sistema.... 54 Figura 16 Controle de logins e políticas de segurança.... 55 Figura 17 Execução da ETL de carga de dimensões através da interface de usuário.... 56 Figura 18 Execução da ETL de Fato através da ferramenta Pentaho Data Integration.... 57 Figura 19 Análise de dados armazenados no data warehouse.... 58 Figura 20 Saída típica de análise de performance após execução de ETL pelo Pentaho Data Integration... 59 13
LISTA DE TABELAS Tabela 1 - Especificação dos atributos da entidade Fato - Registro... 42 Tabela 2 Variáveis de desempenho e resultados obtidos.... 60 14
LISTA DE ABREVIATURAS E SIGLAS ACID: Atomicity, Consistency, Isolation, Durability ETL: Extract Transform Load OLAP: Online Analytical Processing OLTP: Online Transaction Processing SGBD: Sistema de Gerenciamento de Banco de Dados SQL: Structured Query Language DW: Data Warehouse OP: Operational System (Ambiente Operacional) 15
SUMÁRIO 1. Introdução... 19 1.1 Objetivo... 19 1.2 Motivação... 19 1.3 Justificativa... 19 1.4 Metodologia de trabalho... 20 1.5 Estrutura de trabalho... 21 1.6 Restrições... 22 2 Conceitos... 23 2.1 Ambiente Operacional... 23 2.1.1 Modelo ACID... 23 2.1.2 Processamento de transação on-line... 24 2.2 Sistemas de Tomada de Decisão... 24 2.2.1 Processamento analítico on-line... 25 2.3 Data warehouse... 25 2.3.1 Modelo Estrela... 27 2.4 Siglas, Termos e Definições... 27 3 Aplicação... 30 3.1 Descrição do problema... 30 3.2 Idéia para resolução... 30 3.2.1 Ferramentas... 31 4 Etapas do projeto... 38 4.1 Primeiros Passos... 38 4.2 Análise do banco de dados operacional... 38 16
4.3 Especificação de Requisitos... 39 4.3.1 Modelagem do banco de dados dimensional... 40 4.3.2 Extração, Transformação e Carga... 43 4.3.3 Desenvolvimento da base multidimensional (Data warehouse)... 46 4.4 Desenvolvimento das ETLs... 49 4.5 Desenvolvimento do Data warehouse... 52 5 Resultados... 53 5.1 Interfaces de usuário... 53 5.1.1 Interface de usuário de carga de dados... 55 5.1.2 Interface de usuário de análise de dados e relatórios... 57 5.2 Testes... 58 5.2.1 Teste das ETLs... 59 5.2.2 Teste do data warehouse... 59 5.3 Desempenho... 59 6 Considerações finais... 61 6.1 Conclusões... 61 6.2 Contribuições... 61 6.3 Trabalhos futuros... 62 7 Referências Bibliográficas... 63 8 Anexos... 65 8.1 Anexo I... 65 8.2 Anexo II... 67 8.2.1 Anexo II.a - Tabela Dimensão Cliente... 67 8.2.2 Anexo II.b - Tabela Dimensão Operadora... 68 8.2.3 Anexo II.c - Tabela Dimensão Inventario... 69 8.2.4 Anexo II.d - Tabela Dimensão Tempo... 70 8.2.5 Anexo II.e - Tabela Dimensão Tipo de Serviço... 71 17
8.2.6 Anexo II.f - Tabela Dimensão Centro de Custo... 72 8.2.7 Anexo II.g - Tabela Dimensão Unidade de Negocio... 73 8.2.8 Anexo II.h - Tabela Dimensão Entidade... 74 8.2.9 Anexo II.i - Tabela Dimensão Contas... 75 8.2.10 Anexo II.j Tabela Dimensão Fatura... 76 8.3 Anexo III... 77 18
1. Introdução 1.1 Objetivo Este trabalho de formatura tem como objetivo modelar e criar um sistema baseado em um data warehouse, para auxiliar no processo de decisão de uma empresa de gestão em telecomunicações. O sistema, desenvolvido com o fornecimento de dados da empresa In.voice, utiliza dados de um banco de dados relacional já existente, transforma esses dados, armazena em um data warehouse e fornece informações relevantes por meio de relatórios. 1.2 Motivação Um dos ativos mais importantes das empresas é a informação (INMON & HACKATHORN, 1994), e, o principal motivo que leva uma empresa a investir tempo e dinheiro em um data warehouse, é o ambiente competitivo. A fim de se destacar no mercado, é preciso diferenciação, sendo que o data warehouse leva esse benefício à empresa, pois permite que dados dos sistemas que estão em operação em uma empresa sejam coletados e armazenados no decorrer do tempo, para então serem analisados pelos tomadores de decisão/steakholders de uma empresa. A aplicação em telecomunicação se torna interessante ao passo que o volume, granularidade e complexidade de dados neste setor são muito grandes quando se procura registrar todos os eventos telefônicos de uma determinada região por menor que seja. Atualmente, os sistemas baseados em data warehouse não são estudados em cursos comuns de graduação em engenharia de computação, e, além disso, no meio empresarial, muitas empresas ainda utilizam soluções proprietárias. 1.3 Justificativa As justificativas para a realização do trabalho são: a aplicabilidade prática do sistema; a ampliação de conhecimento para criação de alternativas para sistemas de 19
tomada de decisões, baseadas em software de código aberto; além do aprendizado devido à utilização de ferramentas não conhecidas por parte do grupo. A possibilidade de utilizar software de código aberto em um sistema de data warehouse permite que o conhecimento na área de Business Intelligence possa se difundir, além de criar uma alternativa de baixo custo para empresas que necessitam de um sistema de tomada de decisões. O aprendizado dos conceitos teóricos da construção de um data warehouse realiza-se com maior facilidade quando os estudos são acompanhados de uma aplicação prática de tais conceitos (KIMBALL & ROSS, 2002). Portanto, pode-se dizer que a aplicação deste trabalho objetiva a construção de um data warehouse para uma empresa que atua no setor de gestão em telecomunicações, a qual provê serviços para outras empresas que procuram organizar seus gastos com telefonia de forma transparente e eficiente, obtendo, assim controle sobre os gastos dos diversos setores dentro da empresa. Regras de negócio da empresa no que diz respeito à gestão em telecomunicações são baseadas nos registros das faturas de operadoras. Desta forma, o uso de data warehouse para o armazenamento desses dados representaria uma forma eficiente de armazenamento e extração de relatórios, uma vez que o volume de dados é muito grande da ordem de 40 milhões de registros mensais e há necessidade de processamento destes dados para a geração de relatórios que auxiliam o entendimento e análise dos gastos em telecomunicações das empresas que contratam o serviço. 1.4 Metodologia de trabalho A metodologia de desenvolvimento do sistema é constituída das seguintes etapas: Estudo dos conceitos e ferramentas disponíveis: Consiste principalmente do estudo da teoria de data warehouse, analisando as aplicações, os pontos positivos e negativos, e estudo das ferramentas de código aberto disponíveis para apoiar a criação de um sistema baseado em data warehouse. 20
Análise do Banco de Dados Operacional (Relacional): Análise do banco de dados relacional da empresa cliente, levantando os principais dados alvos do projeto. Elaboração dos requisitos: Levantamento dos principais requisitos do sistema, de forma a delimitar o escopo e estabelecer a meta a ser alcançada com o sistema. Modelagem do banco de dados dimensional: Criação do modelo do banco de dados dimensional, com o objetivo de alterar a modelagem dos dados para a migração para o data warehouse. Carga de dados do ambiente operacional: Transporte de dados originários do ambiente operacional para a base dimensional de dados. Esta carga é realizada através de rotinas denominadas ETL Extract, Transform and Load (conforme é definido na seção 2.4). Criação do data warehouse: Modelagem do Data warehouse utilizando a ferramenta Mondrian e o modelo dimensional como base. Geração de relatórios: Compreende a modelagem de formas de se obter das informações e apresentação das mesmas para os usuários do sistema. Os documentos de andamento e a monografia foram elaborados paralelamente às etapas descritas, bem como reuniões com a empresa cliente. 1.5 Estrutura de trabalho O capítulo 1 contém uma introdução ao trabalho de conclusão de curso, apresentando o objetivo, motivações, justificativas, a metodologia, a estrutura e as restrições do trabalho. No capítulo 2 são abordados os conceitos mais importantes que embasam o trabalho. O capítulo 3 contém a descrição do problema, e o raciocínio para a resolução do mesmo, bem como as ferramentas utilizadas. No capítulo 4 são abordadas, de forma seqüencial, todas as atividades desenvolvidas desde o início do projeto até sua conclusão. 21
No capítulo 5 são apresentados os resultados obtidos com o sistema desenvolvido, e os testes realizados. O capítulo 6 contém as conclusões, contribuições e trabalhos futuros relacionados ao projeto. 1.6 Restrições As restrições impostas inicialmente foram relativas às ferramentas a serem utilizadas. A fim de desenvolver a capacidade de buscar conhecimento de novas tecnologias, uma das restrições foi a utilização de ferramentas de código aberto para a realização do trabalho. O projeto também teve como restrição a utilização de um banco de dados relacional específico, uma vez que a empresa cliente mantinha sua base de dados com essa ferramenta. Portanto, em toda a parte de banco de dados relacional, foi utilizado o sistema gerenciador de banco de dados PostgreSQL. 22
2 Conceitos Este capítulo contém os elementos teóricos essenciais que envolvem um sistema baseado em data warehouse. 2.1 Ambiente Operacional O ambiente operacional também conhecido como ambiente transacional é o ambiente necessário para o funcionamento do dia-a-dia da empresa (KIMBALL & ROSS, 2002), normalmente composto por sistemas que operam sobre massas de dados através de operações transacionais (definidas na seção Processamento de transação on-line - item 2.1.2). É neste ambiente que as operações de domínio da empresa acontecem com foco em controle de processos de negócio. Devido à alta taxa de modificações de dados, este ambiente é otimizado para este tipo de tarefa, e normalmente a base do ambiente operacional é um banco de dados relacional, cujos dados são inseridos, alterados, consultados ou removidos. 2.1.1 Modelo ACID As preocupações mais relevantes do ambiente operacional podem ser resumidas nas propriedades ACID (sigla inglesa para Atomicity, Consistency, Isolation, Durability): Atomicity: As transações que ocorrem na base de dados só devem ser concluídas com sucesso se todas as etapas que as compõem forem concluídas com sucesso, caso uma falhe, a transação deve ser cancelada; Consistency: A consistência dos dados deve ser mantida, e, no caso da tentativa de inserção de um dado com tipo incorreto, a transação deve ser cancelada; Isolation: As transações que ocorrem no banco de dados não interferem entre si, ou seja, há um isolamento entre elas; 23
Durability: Os dados inseridos não serão perdidos, mesmo no caso de os mesmos não serem acessados por um longo período. O modelo caracteriza as operações que ocorrem no nível das aplicações e negócios da empresa. 2.1.2 Processamento de transação on-line O processamento mais utilizado pelas empresas para tratar da manipulação de dados (basicamente para inserção, remoção, consulta e alteração de linhas de tabelas) nos bancos de dados relacionais é o processamento conhecido por OLTP (sigla inglesa para On-Line Transaction Processing). A utilidade do processamento de transação on-line pode ser resumido pelas suas funcionalidades (BROWNING, 2001): Suportar operações de negócio em tempo real; Otimizar transações de inserção ou consulta de linhas no banco de dados; Otimizar a validação de dados; Suportar milhares de usuários. 2.2 Sistemas de Tomada de Decisão O desenvolvimento dos sistemas de informação começou na década de 60 com os master files, arquivos que armazenavam informações. E, com o passar do tempo, a grande quantidade de arquivos de informação tornou esse método de armazenagem inviável (principalmente devido à redundância de informação e ao elevado tempo de resposta), foi então criado o modelo de base de dados (SGBD, uma fonte de dados para todo processo ) (INMON, 1996). Com o advento dos PCs, mais usuários começaram a ter acesso aos dados, o que culminou com a criação de transições online de alto desempenho. E, posteriormente, os chamados programas de extração, que apenas copiam os dados de um sistema para outro segundo algum critério. Esses programas de extração foram sendo utilizados cada vez mais, criando-se uma teia de informações (chamada de Arquitetura Evoluída Naturalmente), onde programas de extração eram utilizados em cima de outro programa de extração, e assim sucessivamente. Mas 24
essa nova arquitetura gerou três problemas principais: perda da credibilidade de dados; produtividade; e impossibilidade de transformar dados em informações (INMON, 1996). O data warehouse foi uma das alternativas criadas para resolver essa questão devido suas características (conforme é descrito na seção 2.3). Atualmente, os sistemas de Tomada de Decisão, também conhecidos como sistemas de apoio à decisão (SADs), ajudam os gerentes de nível médio a tomar decisões não usuais (LAUDON & LAUDON, 2007). Sendo que o principal propósito desses sistemas é o de fornecer informações sobre o negócio da empresa (ou partes da mesma), e, através de relatórios, permitir analisar o desempenho corrente da empresa (LAUDON & LAUDON, 2007). O processo de análise das informações utiliza as informações que são inseridas através dos aplicativos da empresa. Pode-se perceber o problema que surge, uma vez que a manipulação de dados e a consulta dos mesmos para a geração de relatórios causam uma sobrecarga. Naturalmente, imagina-se que a melhor solução é separar os dados em dois ambientes, um destinado apenas para o processamento operacional dos dados e outro para a consulta por parte da gerência, e é exatamente isso que um sistema com data warehouse disponibiliza. 2.2.1 Processamento analítico on-line O processamento analítico on-line (em inglês OLAP Online Analytical Processing) é utilizado por sistemas que têm como objetivo principal consultar uma grande quantidade de dados e disponibilizá-los, para que possam ser analisados. O OLAP permite a análise multidimensional de dados, de forma que os usuários vejam os mesmos dados de diferentes maneiras (LAUDON & LAUDON, 2007). 2.3 Data warehouse O data warehouse é um repositório de dados centralizado, caracterizado por: orientação ao assunto, variante no tempo, não volátil e integrado (INMON, 1996). 25
O ambiente operacional é projetado com base nas aplicações e funções da empresa. Por outro lado, o data warehouse é projetado com base nos principais assuntos da empresa, por isso diz-se que ele é orientado ao assunto (INMON & HACKATHORN, 1994). Os dados no ambiente operacional muitas vezes ficam espalhados em diversos bancos de dados, o que pode causar redundância e incoerência nos dados. O data warehouse é estruturado de forma a garantir a integridade dos dados, eliminando alguns dos problemas citados do ambiente operacional. O data warehouse é variante no tempo, ou seja, as informações contidas nele são referentes à evolução ao longo do tempo (usualmente em um período de alguns anos), diferentemente dos dados no ambiente operacional, que representam os dados mais recentes, e normalmente são utilizados em um período da ordem somente poucos de meses (INMON, 1996). A não volatilidade é a característica que diz respeito à alta durabilidade da base de dados, ou seja, o data warehouse permite que os dados sejam armazenados de forma histórica ao longo de vários (INMON, 1996). A consistência dos dados armazenados é garantida ao passo que os dados são somente carregados e acessados. As operações de alteração e remoção de dados são realizadas apenas no ambiente operacional. Assim, uma vez garantida a consistência da massa de dados carregada ao data warehouse, a consistência dos dados armazenados é mantida independentemente da quantidade de vezes que os dados do data warehouse são acessados. De forma diferente dos dados do ambiente operacional necessários para o dia-a-dia da empresa os dados do data warehouse são voltados para a análise e tendência (por isso diz-se que auxiliam no processo de tomada de decisões). Segundo (KIMBALL & ROSS, 2002), o data warehouse deve garantir algumas propriedades. Entre elas: Deve organizar as informações tal que possam ser facilmente acessadas e de forma consistente; Deve ser facilmente adaptável; Deve garantir segurança de dados (do inglês security); e Deve ser essencial para a tomada de decisão. 26
2.3.1 Modelo Estrela O data warehouse é baseado em modelagem multidimensional, deste modo, há conceitos de informações do tipo fato e do tipo dimensões. O primeiro deles diz respeito à informação que se deseja medir, normalmente são eventos temporais aos quais se relacionam um número quantidade de unidades de produto vendidas, receitas de uma venda e duração de uma ligação telefônica são exemplos claros de informações do tipo fato. O tipo dimensão refere-se aos dados que qualificam as o evento retratado nome do produto, data da ocorrência da venda e cliente relacionado ao evento são exemplos de possíveis dimensões. O modelo estrela consiste em uma forma de modelagem do banco dimensional, separando os dados em fatos e dimensões com relacionamentos apenas do tipo fato-dimensão (dimensão-dimensão não é possível neste modelo), este tipo de modelagem é representado ilustrado pela Figura 1. Figura 1 - Modelo Estrela Genérico 2.4 Siglas, Termos e Definições são: As principais siglas, termos e definições que são utilizadas neste documento Banco/Base Operacional: Entidade de armazenamento de dados das transações que ocorrem no dia-a-dia da empresa. 27
Chave de negócio: (business key) É o elemento identificador de um registro que faz sentido no contexto do negócio da empresa. Chave substituta: (surrogate key) É um identificador atribuído a um registro sem que tenha valor semântico no contexto do negócio da empresa. Normalmente definem-se chaves substitutas para otimizar o tempo de junções entre tabelas de dados. Data Mart (DM): Representa uma parte do data warehouse, normalmente pertencendo a apenas um setor da empresa. Data Warehouse (DW): Segundo (Inmon, 1996), data warehouse é um repositório centralizado que abrange toda a empresa. Sendo que ele é caracterizado por: orientação ao assunto, variante no tempo, não volátil e integrado. Drill-Through: Ato de alterar a visualização de informações para obter um maior ou menor grau de detalhamento dos dados. ETL (Extract, Transform and Load): São rotinas executadas periodicamente que alimentam bases de dados a partir de uma ou mais origens. Envolvem os três passos: extrair (Extract) dados de uma determinada fonte, transformá-los (Transform) de modo a adequá-los ao modelo destino e finalmente carregá-los (Load) na base destino. No contexto de data warehouse, são utilizadas para o transporte de informações originárias do ambiente operacional para o banco dimensional. Linguagem MDX: Multidimensional Expressions é uma linguagem introduzida pela Microsoft em 1997 que provê sintaxes para a obtenção e manipulação de dados multidimensionais. Matriz de Barramento: A matriz de barramento realiza o mapeamento das áreas de negócio da empresa, e as dimensões que são aplicadas a cada uma dessas áreas. Metadados: Dados sobre dados, utilizados para funções relacionadas a ETL, na transferência de dados de OLPT para o data warehouse. Modelo Dimensional: Modelagem específica, onde dados numéricos são organizados de forma a serem agregados de acordo com suas características em comum - dimensões. 28
Modelo Relacional: Modelagem específica na qual as tabelas do banco de dados mantêm relações entre si (através de chaves), modelando as entidades reais do negócio da empresa. OLAP (Online Analytical Processing): Análise de uma grande quantidade de dados, normalmente executando operações que não alteram os dados do banco de dados (read-only). OLTP (Online Transaction Processing): Processo utilizado em aplicações orientadas a transações, tais como os bancos de dados relacionais convencionais, que utiliza operações que podem alterar os dados do banco de dados. PostgreSQL: Sistema de Gerenciamento de Banco de Dados (SGBD). Script SQL: Descrição passo-a-passo em linguagem SQL (Structured Query Language) que define operações de consulta, inserção ou remoção de dados de uma base de dados. Tabela Dimensão: As tabelas dimensão são as tabelas "auxiliares", que ficam ao redor da tabela fato (central), e contém os atributos de uma dimensão do negócio. Tabela Fato: A tabela fato é a tabela central, que contém os fatos, valores numéricos, importantes para uma determinada área do negócio. 29
3 Aplicação 3.1 Descrição do problema O aplicativo da empresa In.voice que gera relatórios a partir de sua base de dados operacionais começou a apresentar problemas de desempenho depois que o banco de dados relacional passou a ter uma quantidade muito grande de dados. O aumento do número de clientes fez com que mais informações fossem armazenadas, conseqüentemente o tempo demandado para a geração de relatórios cresceu de modo a inviabilizar algumas operações no sistema. Segundo informações da diretoria da empresa In.voice os relatórios demandavam um tempo de até 6 horas para serem gerados. Para então serem enviados para os respectivos clientes, embora a necessidade devesse ser atendida no momento da requisição. A idéia era disponibilizar informações em tempo hábil para os clientes através de uma interface web. Mas, com a quantidade de tempo demandado para geração dos relatórios, isso era inviável até que esse problema fosse resolvido. 3.2 Idéia para resolução O problema de desempenho apresentado pela empresa In.voice demonstra que utilizar o ambiente operacional para levantar relatórios de análise e suporte pode comprometer o banco de dados relacional por um período, além de não responder em um tempo satisfatório. A idéia principal é separar os dois ambientes, para que um suporte os processos e operações do dia-a-dia da empresa, e o outro ambiente suporte o levantamento de informações para relatórios de análise. Com isso surge a idéia de criar um data warehouse. A empresa possui um banco de dados operacional, o que facilita a implementação de um data warehouse, pois todos os dados inseridos já estão sendo armazenados em meio digital. 30
3.2.1 Ferramentas A criação do data warehouse foi feita em etapas. Sendo que em cada etapa um determinado software (de código aberto) foi essencial para auxiliar no processo. Segue uma breve descrição de cada uma das ferramentas utilizadas durante o projeto. 3.2.1.1 PostgreSQL O PostgreSQL é um sistema gerenciador de banco de dados objeto-relacional de código aberto. Ele suporta os principais tipos de operações realizadas nos banco de dados relacionais comuns, como criação de tabelas, chaves, relacionamentos, entre outros. O banco de dados utilizado pela empresa In.voice é acessado através desta ferramenta. E, através dela, foi criado o modelo dimensional. A manipulação dos esquemas e tabelas pode ser realizado através do PgAdmin III, um software de manipulação e manutenção do banco de dados cuja interface de usuário é ilustrada pela Figura 2. 31
Figura 2 - Interface de usuário do pgadminiii 3.2.1.2 Pentaho Data Integration O Pentaho Data Integration, chamado anteriormente de Kettle, é a ferramenta responsável por extrair, transformar e carregar (em inglês, ETL) processos. O objetivo a ser alcançado com a utilização do Kettle é automatizar a transformação dos dados a partir do banco de dados relacional do usuário para o banco de dados dimensional. Sua interface é ilustrada pela Figura 3. 32
Figura 3 - Interface de Usuário do Pentaho Data Integration A modelagem da ETL se dá através do encadeamento de operações menores que realizam diversas ações sobre o fluxo de dados representado. Cada uma dessas operações é representada por um bloco e o transporte de dados entre dois blocos é representado por uma flecha do bloco fornecedor ao bloco receptor. As principais operações desta ferramenta que serão utilizadas no desenvolvimento no projeto são: Table input (Entrada do tipo tabela): Lê o conteúdo de uma tabela em uma base de dados relacional e o adiciona ao fluxo de dados. Lookup (Consulta): Baseado em uma coluna já pertencente ao fluxo, consulta uma fonte de dados para procurar outro valor que tenha correspondência àquela do fluxo. Table output (Saída do tipo tabela): Grava o conteúdo do fluxo em uma tabela de um banco de dados relacional. 33
Lookup/Update Combination (Combinação de consulta e atualização): Realiza a consulta de um dado em uma base relacional, e compara seus valores com o fluxo. Se houver mudança a base é atualizada conforme a fonte. 3.2.1.3 Mondrian Mondrian (ou Pentaho Analysis Services) é um mecanismo OLAP desenvolvido com a finalidade de apresentar dados de uma forma multidimensional. Esta ferramenta basicamente é um software que provê o serviço de bases OLAP através de interfaces web com outros aplicativos. Ele recebe como entrada um arquivo XML definido pelo desenvolvedor do data warehouse e, através das informações contidas nele, realiza as agregações de informações contidas no modelo dimensional utilizado. O objetivo a ser alcançado com a utilização do Mondrian é a criação de um data warehouse a partir do modelo de banco de dados dimensional previamente modelado. O Mondrian é um serviço executado através de servidores de aplicações Web e inclui em seu pacote o componente jpivot que consiste em uma interface de acesso a dados que é ilustrada pela Figura 4. 34
Figura 4 - Interface de usuário do jpivot, acessando o serviço OLAP do Mondrian 3.2.1.4 Schema Workbench A modelagem do data warehouse é baseada na definição em XML do modelo multidimensional. Esta ferramenta auxilia esta edição, apresentando o documento sob uma forma de árvore e lista as propriedades de cada um dos atributos em uma lista, para cada um dos níveis da árvore. A Figura 5 ilustra sua interface de edição. 35
Figura 5 - Interface de usuário do Schema Workbench 3.2.1.5 Pentaho BI Studio Esta ferramenta é responsável por integrar funcionalidades das demais ferramentas integradas a um sistema web com suporte a definição de políticas de segurança e grupos de usuários. Integra Mondrian (seção 3.2.1.3), Pentaho Reporting e Pentaho Data Integration (seção 3.2.1.2). A interface de usuário baseada em Web está ilutrada na Figura 6. 36
Figura 6 - Interface de usuário do Pentaho BI Studio 37
4 Etapas do projeto 4.1 Primeiros Passos Em etapas iniciais de idealização e definição do tema do projeto, havia a preocupação em modelar e desenvolver uma aplicação de data warehouse para um setor para o qual este tipo de modelagem fosse adequada, de modo que fosse possível obter resultados concretos de desempenho e ganho de eficiência operacional, ao passo que se agilizava a capacidade analítica e performática dos relatórios utilizados. Neste foco, a melhor alternativa encontrada foi pesquisar um caso problemático real, segundo o qual fosse possível retirar todas as conclusões e resultados desejados, comparando ganhos antes e depois da implantação da aplicação através de depoimentos de usuários. A empresa In.Voice se dispôs a apresentar o problema de desempenho que enfrentava, e disponibilizou seus sistemas e ambiente operacional para que o projeto pudesse ser desenvolvido. Iniciou-se, assim, um ciclo de reuniões que possibilitaram o início do projeto com a análise dos dados operacionais que, por sua vez, fez parte do levantamento de requisitos do projeto, que definiu aspectos como escopo e restrições no momento inicial. 4.2 Análise do banco de dados operacional A empresa In.Voice apresentou o sistema de manipulação de informações que, além de editar o conteúdo da base de dados, é também utilizado para a geração de relatórios. Este sistema é baseado em um modelo relacional implementado sobre uma base de dados PostgreSQL 8 (conforme definido na seção 3.2.1.1). O rápido crescimento da empresa e a desorganização de projetos de desenvolvimento do sistema mencionado, unidas à complexidade das operações de negócio realizadas, fez com que a base incorporasse mais de 100 tabelas de dados dispostas de maneiras muitas vezes redundantes e com normalizações 38
inadequadas. O modelo representa o ambiente operacional do projeto de data warehouse de onde se extraem os dados para alimentação da base dimensional. O escopo do trabalho junto à análise de tal estrutura permitiu um refinamento através de um processo de engenharia reversa o qual tomou como ponto de partida os sistemas de geração de relatórios para a conseqüente análise do fluxo de dados e suas respectivas origens na base relacional, resultando na extração da parcela mais significativa (disponível no Anexo I) para a modelagem dimensional e nas quais as próximas etapas do projeto são baseadas. No modelo refinado apresentado, pode-se observar o papel central sobre o conjunto de tabelas Fatura e Inventário, uma vez que estas entidades têm grande importância na análise de custos em telecomunicações das empresas, e uma vez que o significado de negócio dos registros de Fatura são as consolidações de registros telefônicos em conjuntos limitados por data bem definida da ocorrência do evento. A tabela Inventário representa o vínculo entre clientes e suas faturas. O papel centralizador apresentou um caminho para a definição dos dados do tipo Fato, cujas características principais estão em seus atributos temporais e representações numéricas quantitativas. O processo de identificação é descrito posteriormente na etapa de levantamento de requisitos (seção 4.3). 4.3 Especificação de Requisitos As reuniões que se desencadearam após o primeiro contato com a empresa resultou no levantamento de requisitos do projeto de data warehouse, que por fim levou à criação do documento de Especificação de Requisitos, entregue como produto final do primeiro quadrimestre de 2009 da disciplina PCS-2040 (Projeto de Formatura I), porém, após o final desta disciplina, novas reuniões e redefinições do negócio da empresa resultaram em algumas modificações no modelo apresentado que será detalhado nos próximos itens. O principal requisito da empresa era um sistema para geração de relatórios que respondesse em quantidade satisfatória de tempo. Assim, os principais aspectos levantados foram: a. Novo ambiente de geração de relatórios (data warehouse); 39
b. Geração de relatórios em tempo aceitável; c. Aumentar o ganho de informação de um relatório; d. Prover métodos analíticos mais eficientes. O item a desta lista representa a independência de um sistema de data warehouse que não deve influenciar os sistemas em operação na empresa. Os itens b, c e d apresentados acima são requisitos relacionados aos antigos sistemas da empresa em operação. No item b da lista, o termo tempo aceitável faz menção ao tempo de geração de um relatório específico de um cliente que varia de alguns minutos a horas de tempo de espera. Para o item c espera-se que, uma vez que relatórios serão gerados em tempos menores, é possível incluir mais informações, facilitando assim o cumprimento da função básica de relatórios que é o auxílio na tomada de decisões. O item d representa o requisito de maior dinamismo no sistema que, uma vez mais ágil, possa oferecer métodos analíticos de dados mais eficientes como recursos de drill-through em tabelas de dados. Após concluído o primeiro documento de especificação, modificações mostraram-se necessárias, dentre estas a principal diz respeito aos dados armazenados no data warehouse cuja granularidade diminuiu, uma vez que o nível de detalhamento requisitado passou do nível de faturas para o nível de registros. Esta modificação gerou um aumento na massa de dados tratados na proporção dada pelo número médio de registros por fatura, ou seja, cada dado de fatura passa a inserir uma quantidade N de registros de telefonia, onde N é o número médio de registros por fatura. O valor depende do porte da empresa. 4.3.1 Modelagem do banco de dados dimensional A modelagem do banco de dados dimensional inicia-se com a identificação dos dados que representam valores e quantidades relacionados a eventos discretos no tempo e de papel central nas regras de negócio. Define-se, assim, dados do tipo fato e, conseqüentemente, a tabela fato com os diversos atributos do evento. Características do evento de importância relevante ao negócio e definição de relatórios podem ser modeladas em dimensões junto aos seus respectivos atributos. Uma vez concluídas as tabelas, o esquema com as tabelas e relações é criado através de um sistema gerenciador de banco de dados. 40
O diagrama representativo do modelo dimensional é ilustrado pela Figura 7 e cada uma das dimensões tem seus atributos detalhados no Anexo II. O método utilizado baseia-se no modelo estrela (conforme descrito na seção 2.3.1). Sua vantagem está em sua simplicidade construtiva e velocidade de acesso aos atributos de uma dimensão. Em contra partida, dados acabam tornando-se mais esparsos e o nível normalização é baixo. Como há poucas dimensões no projeto que possuem mais de três atributos, e o número de dimensões hierarquizadas é pequeno, isto é, não prejudica a normalização dos dados, o modelo estrela foi adotado a priori. Figura 7 Modelo dimensional modelado 41
4.3.1.1 Tabela Fato A tabela fato é produto do levantamento de requisitos e especificação do sistema e pode ser visualizada nos diagrama relacional (Anexo II) da modelagem dimensional; identificada pelo nome Fato_Registro. Os dados da tabela fato dizem respeito à entidade de negócio denominada Registro, o qual, por sua vez, representa a ocorrência de uma chamada telefônica de um cliente e seus atributos de negócio mais relevantes para o uso em relatórios. Esses atributos estão enumerados e detalhados na tabela abaixo (apenas atributos relativos ao negócio são detalhados nesta tabela). Campo Tipo de dado Significado de Negócio Dt_inicio_registro Data Representa a data de início da chamada telefônica Dt_termino_registro Data Representa a data de término da chamada telefônica Fato_duracao Decimal Representa o valor em segundos da duração da chamada telefônica Fato_valor_original Decimal Representa o valor original cobrado pela chamada sem imposto. Fato_valor_retarifado Decimal Representa o valor retarifado da chamada telefônica. Fato_valor_rebilled Decimal Fato_quantidade Inteiro Representa a quantidade Tabela 1 - Especificação dos atributos da entidade Fato - Registro Ao modelo dimensional foram adicionadas colunas responsáveis por fazer a ligação entre os registros da tabela fato e suas dimensões quando aplicáveis (colunas identificadas com o prefixo sk_ em nosso modelo dimensional). Estas colunas são chaves estrangeiras (termo definido na seção 2.4) que apontam para chaves substitutas (surrogate keys, termo definido na seção 2.4), a importância do uso deste tipo de chaves (que não possuem significado de negócio) está em seu tipo 42
inteiro que torna a associação entre entidades mais ágil e simples de ser tratada em relação ao uso de chaves de negócio que poderiam ser muitas vezes do tipo cadeia de caracteres o que prejudicaria o desempenho do banco de dados. Uma perda de desempenho em tarefas de união (join) afeta diretamente a etapa de carga de informações ao data warehouse que, ao fazer pré-processamento de dados, internamente realiza diversas vezes esta operação para obter dados sob a forma adequada para ser armazenada em sua arquitetura interna. 4.3.1.2 Tabelas Dimensão Assim como a tabela fato, o levantamento de requisitos levou às especificações das tabelas de dimensão. De forma geral as dimensões modeladas foram: dim_unidade_de_negocio: Dimensão da unidade de negócio. dim_ centro_custo: Dimensão do centro de custo. dim_ fatura: Dimensão da fatura. dim_ cliente: Dimensão de cliente. dim_ operadora: Dimensão da operadora. dim_tempo: Dimensão de tempo. dim_ entidade: Dimensão da entidade. dim_ inventario: Dimensão do inventário. dim_ tipo_servico: Dimensão do tipo de serviço. dim_ conta: Dimensão da conta. anexo 8.2. Os atributos das tabelas dimensão e seus significados de negócio estão no 4.3.2 Extração, Transformação e Carga As ETLs foram divididas em dois grupos: ETLs das tabelas dimensão; e ETL da tabela fato. Em teoria as ETLs são modeladas de forma a oferecerem um recurso automatizado de extrair dados de fontes distintas; consolidá-los sob um formato padronizado e então inseri-los em uma base centralizada. Esta idéia é utilizada no projeto, sendo que o banco operacional representa a fonte de dados e o banco 43
dimensional representa o destino. Para tais processos de carga foram elaborados dois modelos básicos de carga em regras gerais que serão apresentados nas seções 4.3.2.1 e 4.3.2.2. O primeiro deles é voltado à carga de tabelas-dimensões e o segundo, carga de tabelas-fato. 4.3.2.1 ETL das tabelas dimensão O Modelo de carga de Dimensões é apresentado na Figura 8. Figura 8 - Modelo básico de ETL de carga de dimensões O processo, em palavras gerais, consiste em extrair dados da fonte e compará-los com os dados presentes no modelo dimensional a fim de identificar linhas que foram modificadas, inseridas ou removidas desde a última carga. Baseado nestas informações, a base dimensional deve ser atualizada a fim de manter o conteúdo sincronizado entre ambos ambientes. 4.3.2.2 ETL da tabela fato Em termos de linhas da tabela fato, deve existir uma ligação de cada um dos registros com as respectivas dimensões, quando estas forem aplicáveis. Porém, esta ligação não é explícita no momento em que ocorre a extração desses dados, devido às diferenças entre os modelos operacional e dimensional, uma vez que cada um 44
deles têm conceitos para identificadores diferentes. No modelo relacional tradicional utiliza-se o conceito de chaves primárias, normalmente numéricas e únicas para cada registro, de forma similar, o modelo dimensional utiliza o conceito de chave de negócio que por sua vez são mapeadas em colunas numéricas surrogate keys (definidas na seção 2.4) para otimizar a performance do banco, assim deve haver um mapeamento entre ambas as chaves para se manter a consistência entre elas. Foram levantadas duas formas diferentes de realizar a carga da tabela fato: buscas em série ou buscas em paralelo. A Figura 9 ilustra ambos os modelos e suas diferenças construtivas. No modelo em série, após a extração dos dados, as buscas por chaves substitutas ocorre linearmente uma após a outra (Figura 9.a), após o termino das buscas insere-se o fluxo resultante no modelo dimensional; em contrapartida, o modelo paralelo (Figura 9.b) realiza buscas simultâneas de chaves substitutas para então realizar a junção do fluxo novamente para então armazená-lo na base dimensional. O modelo utilizado para o desenvolvimento desta ETL é o modelo de busca em série (Figura 9.a). Inicialmente o modelo em paralelo havia sido desenvolvido, mas devido à ocorrência de deadlocks de acesso ao banco de dados no momento das atividades em paralelo, optou-se pelo modelo em série por evitar este tipo de conflito embora ofereça relativa perda de desempenho. 45
Modelo ETL: Carga da Fato (série) Extração de dados de registros no modelo operacional. Busca da PK da dimensão 1 Busca da PK da dimensão 2... Busca da PK da dimensão n Inserção dos dados na base dimensional (a) Modelo ETL: Carga da Fato (paralelo) Extração de dados no modelo operacional Busca da PK da dimensão 1 Busca da PK da dimensão 2... Busca da PK da dimensão n União dos fluxos de dados Inserção dos dados na base dimensional (b) Figura 9 - Modelos de ETL de carga de tabelas-fato (a) série; (b) paralelo 4.3.3 Desenvolvimento da base multidimensional (Data warehouse) A modelagem em estrela, conforme previamente apresentado na seção 4.3.1, coloca a tabela fato no centro do modelo e, relacionadas diretamente a ela, uma a uma, as dimensões. Assim, tal modelo deve ser mapeado ao Mondrian de modo que 46
este seja capaz de instanciar o cubo e, assim, gerar o data warehouse com os dados organizados em dimensões, cumprindo os objetivos do trabalho. Este mapeamento é realizado através da ferramenta Schema Workbench (apresentado na seção 3.2.1.4) que gera um arquivo XML com a sintaxe entendida. A etapa seguinte corresponde à definição das hierarquias dimensionais e por fim, o acabamento final de tratamento de formatações de dados e nomes de campos. Figura 10 Modelo Multidimensional no Schema Workbench. A seguir, são especificadas os detalhes mais relevantes da modelagem multidimensional do data warehouse. 47
4.3.3.1 Métricas As métricas de um modelo multidimensional representam os dados dos eventos do negócio em si. Normalmente são temporais e numéricas, ou seja, têm ocorrência bem definida no tempo e representam entidades quantificáveis no negócio, possibilitando sua agregação em diversos níveis de detalhamento utilizando-se funções matemáticas de agregação (adição, contagem, máximo, mínimo, entre outras). Para o projeto em questão foram definidas como métricas os valores a respeito de uma chamada telefônica (entidade Registro ): Duração; Quantidade; Valor Original; Valor Recobrado; Valor Retarifado. Valores que têm representatividade na criação de relatórios de tomada de decisão para a empresa In.Voice. 4.3.3.2 Dimensões sem hierarquia Dimensões simples, sem uma hierarquização de seus membros, seguem a um mesmo modelo em que a dimensão aponta para a tabela do modelo dimensional e extrai dali todos seus membros e atributos, sem organizá-los hierarquicamente. Para o projeto, a maioria das dimensões, exceto da dimensão de tempo, possuem essas características, uma vez que o nível único de detalhamento de cada uma das dimensões é suficiente para a geração dos relatórios. 4.3.3.3 Dimensão de tempo A hierarquização de dimensão foi aplicada à dimensão de tempo. Desta forma, houve a hierarquização da tabela dim_tempo em Ano > Trimestre > Mês > Dia. 48
Figura 11 - Hierarquia de tempo definida 4.3.3.4 Granularidade A granularidade temporal do modelo em questão segue a mesma granularidade dos dados carregados do ambiente operacional da empresa, que é do nível de registros telefônicos diários. Desta forma, a granularidade permite uma análise profunda e possibilita tanto a análise de registros diários no nível mais baixo, quanto uma análise macro que agrega dados por mês, trimestre ou ano; além da segmentação pelas demais dimensões como fatura ou centros de custo relacionadas. Assim, os usuários desde a tomada de decisão gerencial (pontual) à tomada de decisão estratégica (mais abrangente) são atendidos pelo sistema. 4.4 Desenvolvimento das ETLs Os fluxos de ETLs das tabelas dimensão são muito semelhantes, portanto foi decidido que todas seriam agrupadas em duas ETLs, sendo que os fluxos seriam executados paralelamente. As dimensões dim_unidade_de_negocio, dim_centro_custo, dim_fatura, dim_cliente, dim_operadora, dim_entidade, dim_inventario, dim_tipo_servico e dim_conta tiveram o seguinte fluxo criado: 1. Entrada de dados (Extract): O mecanismo utilizado no software Pentaho Kettle foi o Table input (seção 3.2.1.2), apontando para o banco de dados Bunge (nome do banco de dados do ambiente operacional), esquema GP4 (nome do esquema do banco de dados do ambiente operacional), e cada tabela possui um script escrito em SQL, que 49
seleciona as informações importantes (sendo que cada dimensão teve origem em uma tabela do modelo relacional); 2. Carga de dados da dimensão (Transform & Load): Os novos dados devem ser comparados com os dados já existentes na dimensão a fim de sincronizar ambas e evitar duplicidade de registros. A Figura 12 ilustra os fluxos de ETL das dimensões. Figura 12 - Diversos fluxos de carga das dimensões A tabela dim_tempo pertence a uma ETL das dimensões, mas possui o fluxo diferente. Isso ocorre pois, para a criação da tabela dim_tempo, foi utilizado um arquivo CSV. O que difere esta dimensão das demais no contexto da ETL é que a entrada de dado é feita não por um script SQL, mas sim por um arquivo do tipo CSV. A ETL da tabela fato segue um fluxo diferente das ETLs das dimensões (Figura 13). O fluxo é o seguinte: 50
1. Entrada de dados (Extract): O mecanismo utilizado também foi o Table Input (conforme definido na seção 3.2.1.2) do Pentaho Kettle, apontando para o base de dados operacional, utilizando um script na linguagem SQL, o qual é bastante diferente dos utilizados para as ETLs das dimensões, uma vez que a tabela inicial possui todas as chaves de negócio que serão trocadas por chaves substitutas; 2. Busca de Chaves (Transform): Para cada chave de negócio extraída, deve-se saber a correspondente chave substituta, para isto, uma busca baseada na chave de negócio deve ser realizada. Este tipo de busca é realizada pelo componente Lookup (detalhado em 3.2.1.2). Têm-se então, 9 etapas de lookup uma para cada dimensão. 3. Inserção (Load): Cada um dos registros chega nesta etapa com seus valores originais extraídos adicionados às chaves substitutas, desta forma, basta mapear as colunas entre o fluxo de dados e a tabela destino, que no caso é a tabela Fato_Registro. O processo de inserção dos dados é realizado pelo componente Table output. Figura 13 - ETL da Tabela fato_registro 51
Em termos de desempenho, utilizou-se o armazenamento temporário em memória cachê em cada uma das etapas do fluxo, os resultados comparativos são apresentados neste documento na seção 5.3. 4.5 Desenvolvimento do Data warehouse O modelo multidimensional especificado na seção 4.3.4 foi implementado utilizando o framework Pentaho, que utiliza como servidor OLAP a ferramenta Mondrian. O data warehouse, assim, foi modelado inicialmente pela definição de um XML no formato reconhecido pelo Mondrian seguindo as especificações do projeto. Após o início do desenvolvimento, tomou-se conhecimento da ferramenta lançada durante o desenvolvimento Schema Workbench que facilita a edição do XML através de uma interface gráfica. Uma vez desenvolvido, o modelo deve ser publicado no Mondrian, isto é feito através da edição de um arquivo de configuração interno à ferramenta e consiste na edição das strings de conexão e definição dos dados apontados. 52
5 Resultados 5.1 Interfaces de usuário A ferramenta Pentaho BI Studio contém uma interface baseada em Web. A Figura 14 ilustra a tela de boas vindas do sistema. Figura 14 Tela de boas vindas do sistema web Pentaho BI Studio. 53
Após a autenticação na tela de boas vindas, a tela de entrada do sistema, ilustrada pela Figura 15, é exibida. A partir desta tela é possível realizar todas as operações do ciclo do data warehouse: Carga de dados através das ETLs; Atualização dos dados do repositório; Geração e consulta de relatórios administrativos utilizando dados do data warehouse; Navegação analítica através das métricas e dimensões do data warehouse. Em termos de segurança há controle administrativo de login, fornecido por outra interface administrativa, ilustrado pela Figura 16. Figura 15 Tela de entrada no sistema. 54
Figura 16 Controle de logins e políticas de segurança. 5.1.1 Interface de usuário de carga de dados Para realizar a carga de dados, foram preparadas para os usuários duas possibilidades: executar o pacote ETL utilizando a interface de usuário ou a ferramenta Pentaho Data Integration. No primeiro caso, a carga é executada de maneira muito simples, basta um duplo clique no menu à esquerda da interface que corresponde à carga de dado selecionada, e então a rotina se inicia. No momento do término é exibida uma tela com informações do processo executado como sucesso da operação e um conjunto de dados carregados para verificação rápida. A Figura 17 ilustra a tela de término de execução. Outro método é através da ferramenta Pentaho Data Integration, que possui uma interface amigável, porém com mais recursos de personalização e relatório de desempenho. Para obter o pacote não há necessidade de busca entre os arquivos do sistema, foi desenvolvido um repositório onde a ferramenta consegue buscar as rotinas de carga de forma imediata. A Figura 18 ilustra este método de execução. 55