LEONARDO SANTOS DA MATA GUIA PARA CONSTRUÇÃO DE UM DATA WAREHOUSE

Transcrição

1 LEONARDO SANTOS DA MATA GUIA PARA CONSTRUÇÃO DE UM DATA WAREHOUSE Palmas 2005

2 2 LEONARDO SANTOS DA MATA GUIA PARA CONSTRUÇÃO DE UM DATA WAREHOUSE Trabalho apresentado ao curso de Sistemas de Informação, do Centro Luterano Universitário de Palmas, como requisito da disciplina Prática de Sistemas de Informação I, orientado pela professora Cristina D Ornellas Filipakis. Palmas 2005

3 3 LEONARDO SANTOS DA MATA GUIA PARA CONSTRUÇÃO DE UM DATA WAREHOUSE Trabalho apresentado ao curso de Sistemas de Informação, do Centro Luterano Universitário de Palmas, como requisito da disciplina Prática de Sistemas de Informação I, orientado pela professora Cristina D Ornellas Filipakis. Aprovada em julho de BANCA EXAMINADORA Profa. Cristina D'Ornellas Filipakis Centro Universitário Luterano de Palmas Profa Msc. Madianita Bogo Centro Universitário Luterano de Palmas Profa. Dra. Thereza Patrícia Pereira Padilha Centro Universitário Luterano de Palmas Palmas 2005

4 4 Sumário 1. INTRODUÇÃO 6 2. REVISÃO DE LITERATURA CARACTERÍSTICAS DO DATA WAREHOUSE ORIENTADO POR ASSUNTO INTEGRADO VARIÁVEL EM RELAÇÃO AO TEMPO NÃO VOLÁTIL GRANULARIDADE Níveis Duais de Granularidade Particionamento dos Dados ARQUITETURA DO DATA WAREHOUSE ARQUITETURA GENÉRICA ARQUITETURA DE DUAS CAMADAS ARQUITETURA DE TRÊS CAMADAS MICROSOFT SQL SERVER VISÃO GERAL DISTRIBUTED MANAGEMENT FRAMEWORK (DMF) POWER DESIGNER ARQUITETURA FERRAMENTA ETL BUSINESS OBJECTS 18 MÓDULO DESIGNER 18 BUSINESS OBJECTS 19 BUSINESS MINER 19 WEB INTELLIGENCE 19 DOCUMENT AGENT SERVER 19 SUPERVISOR 20 BUSINESS QUERY METODOLOGIAS DE DATA WAREHOUSING METODOLOGIAS E-COMENT Fases de Desenvolvimento MODELAGEM DIMENSIONAL STAR JOIN SCHEMA 25

5 3 MATERIAIS E MÉTODOS METODOLOGIA FASES DE DESENVOLVIMENTO BANCO DE DADOS ENTREVISTAS COM USUÁRIOS MODELAGEM DO DATA MART CRIAÇÃO DO BANCO DE DADOS PROCESSO EXTRAÇÃO, TRANSFORMAÇÃO E CARGA DOS DADOS ETL IMPLANTAÇÃO DAS CONSULTAS DO DATA MART VALIDAÇÃO DOS DADOS 32 4 RESULTADOS E DISCUSSÃO BANCO DE DADOS ENTREVISTAS COM USUÁRIOS MODELAGEM DO DATA MART BANCO DE DADOS DW PROCESSO DE ETL IMPLANTAÇÃO DA CONSULTA DO DATA MART VALIDAÇÃO DOS DADOS DISCUSSÕES 51 5 CONSIDERAÇÕES FINAIS 53 6 REFERÊNCIAS BIBLIOGRÁFICAS 55

6 6 1. Introdução Segundo Andreatto (1999), os Sistemas de Apoio à Decisão (SAD) sofreram uma grande evolução no século XX, no período entre 1960 a 1990, com o intuito de ajudar os gerentes a solucionar problemas. Os SADs eram a forma de organizar e armazenar os arquivos mestres e fitas magnéticas. Os primeiros SADs eram muito caros e complexos. Este fato ficou comprovado no ano de 1965, pois com o grande crescimento dos arquivos mestres e das fitas magnéticas, foi aumentando também a complexidades dos programas e do hardware para sincronizar todos os dados (ANDREATTO, 1999). Na década de 80 surgiu o Dispositivo de Armazenamento do Acesso Direto (DASD), criado para substituir o armazenamento dos dados em arquivos mestres ou em fitas magnéticas. A partir do DASD, surgiu a idéia do Software de Gerenciamento de Bancos de Dados (SGBD), que tinha por objetivo tornar mais fácil o acesso e armazenamento dos dados, segundo Andreatto (1999). A partir dos anos 90, com o surgimento de Ferramentas CASE e Linguagens de 4ª Geração, o usuário final teve controle sobre os sistemas e os dados. Com a criação dessas duas tecnologias, o usuário final passou a executar processamento de transações online com o acesso direto a sistemas e dados Após a década de 90, com o grande número de informações armazenadas nas empresas, existem informações que os administradores desconhecem. Os administradores necessitam conhecer as informações que existem nas empresas, porém elas estão armazenadas em diversos sistemas e formulários de papel. Na tentativa de solucionar este problema surgiram os SADs e posteriormente o DASD, porém nenhum deles solucionava as necessidades gerenciais dos administradores, pois existia um grande número de informações redundantes.

7 7 A partir disso, o Data Warehouse surgiu com o objetivo de tornar as informações acessíveis para os administradores. O Data Warehouse não é um software, mas sim um ambiente que oferece amplos recursos para consultas. Para a construção deste existem inúmeras ferramentas que auxiliam este trabalho. Na realidade, sua implantação exige a integração de vários produtos e processos (ANDREATTO, 1999). Este trabalho mostrará as etapas de conhecimento do domínio, modelagem do Data Mart, a Extração, Transformação e Carga dos dados, a implantação das consultas e por último a validação das consultas. Este trabalho irá mostrar todos os passos necessários para construção de um Data Warehouse e também as ferramentas utilizadas para desenvolvê-lo. Serão apresentados também os resultados encontrados com a aplicação das etapas de construção do ambiente, predefinidas neste relatório, com o estudo de caso feito com os dados do Congresso Científico do CEULP/ULBRA do ano de 2005.

8 8 2. Revisão de Literatura 2.1. Características do Data Warehouse Este trabalho tem o objetivo de oferecer um guia para a construção do Data Warehouse, que é um sistema que oferece apoio à tomada de decisões. O mesmo é construído para que os dados armazenados possam ser acessados de forma dimensional, ou seja, através da criação de um modelo estrela. O mesmo é formado por uma tabela de fato a qual recebe todos os atributos referentes as dimensões, com ligações nas outras tabelas, fornecendo dados integrados e históricos (MACHADO, 2004). Após a década de 90, com desenvolvimento de novas tecnologias, a arquitetura de desenvolvimento foi alterada para atender as necessidades das empresas, surgindo o ambiente projetado, no qual está o Data Warehouse (DW). O DW consiste a junção de diversas tecnologias que permitem fazer consulta no banco de dados, para posterior análise dos dados, tornando-o imprescindível para os SADs. Devido ao ambiente projetado, o DW tem uma única fonte de dados, que facilita muito o trabalho do analista, porque os dados que lá existem estão tratados e não há redundância. O Data Warehouse é um conjunto de dados baseados em assunto, integrados, não-volátil e variável em relação ao tempo para apoio às decisões gerenciais. (Inmon, 1997, p. 33) A seguir é apresentada breve descrição das características de um Data Warehouse Orientado por assunto

9 9 Assunto refere-se aos sistemas transacionais organizados em uma determinada aplicação de uma empresa. Por exemplo, na Secretaria da Fazenda existem aplicações para os setores de arrecadação e financeiro. Os principais assuntos são os cadastros de contribuintes, impostos a recolher, IPVA e GIAM. A orientação por assunto é uma característica importante, pois toda a modelagem do DW é orientada sobre os principais assuntos da empresa Integrado Essa é a característica mais importante do DW, pois trata da integração, que é feita do ambiente operacional para as aplicações do DW. A integração é realizada visando padronizar os dados dos diversos sistemas em uma única representação, para serem transferidos para a base do DW. Geralmente, esses dados estão armazenados em diversos padrões porque são criados para diversas aplicações e são implementados por vários analistas Variável em relação ao tempo A variação em relação ao tempo consiste na manutenção de um histórico de dados em relação ao período de tempo maior que dos sistemas comuns. Este armazenamento ocorre porque o principal objetivo do DW é poder analisar as informações por um período maior de tempo. Ao analisarmos um dado de um DW, o mesmo sempre estará relacionado a um período determinado de tempo, pois terá uma chave de tempo que irá indicar o dia no qual esses dados foram extraídos Não Volátil Nos sistemas transacionais os dados sofrem diversas alterações como, por exemplo, a inclusão, alteração e exclusão. No ambiente do DW os dados, antes de serem carregados, são filtrados e limpos. Após esta etapa os dados do

10 DW sofrem operações de consulta sem serem alterações, e esta característica representa a não-volatilidade do DW Granularidade Um outro ponto importante do DW é o nível de granularidade dos dados. Esta outra característica trata do nível de detalhamento dos dados contidos no DW. Quanto mais detalhe a consulta exigir mais baixo será o nível de granularidade, de modo inverso, quanto menos detalhe a consulta exigir mais alto será o nível de granularidade. Segundo W. H. Inmon (1997), a razão pela qual a granularidade é a principal questão de projeto consiste no fato de que ela afeta profundamente o volume de dados que residem no DW e, ao mesmo tempo, afeta o tipo de consulta que pode ser atendida. O volume de dados contidos no DW é balanceado de acordo com o nível de detalhamento de uma consulta Níveis Duais de Granularidade O DW tem dois níveis de granularidade e esta forma de trabalho geralmente se encaixa nos requisitos da maioria das empresas. A primeira camada, dos dados levemente resumidos, contém dados extraídos do armazenamento operacional. Os dados são resumidos de forma que a sua utilização fique mais fácil para os analistas e gerentes. Na segunda camada, chamada também de nível de dados históricos, todos os detalhes vindos do ambiente operacional são armazenados. Com a criação dos dois níveis de granularidade, o analista do SAD conseguiu solucionar dois problemas no DW de uma vez, pois a maior parte do processamento do SAD utiliza-se dos dados levemente resumidos porque eles estão mais compactos e mais fácies de acessar. Porém se houver necessidade de haver um maior nível de detalhamento existe o nível de dados históricos, mas o acesso a esses dados é mais complexo.

11 Particionamento dos Dados O principal objetivo do particionamento trata da repartição dos dados em unidades físicas menores. Esta repartição tem por objetivo facilitar o trabalho do projetista, pois permite uma maior flexibilidade no gerenciamento dos dados. Existem vários critérios para divisão dos dados, como por exemplo: por data; por área de negócio; por área geográfica; por unidade organizacional. Além disso, toda unidade de dados pertence a uma e somente uma partição. 2.2 Arquitetura do Data Warehouse Segundo Andreatto (1999), o principal objetivo do estudo da arquitetura é o de investigar como o Data Warehouse faz para armazenar, integrar, comunicar, processar e apresentar os dados que os usuários irão utilizar para as tomadas de decisões. A Arquitetura do DW pode variar conforme o tipo de assunto abordado, isso ocorre devido às necessidades que variam de empresa para empresa. A seguir é apresentada a descrição de cada uma das arquiteturas do DW (ANDREATTO, 1999) Arquitetura Genérica A arquitetura genérica organiza os papéis no DW, conforme mostra a Fig.. 01, e tem por objetivo apresentar a funcionalidade do DW com a criação de várias camadas que podem ser utilizadas em um único componente de software.

12 12 Figura 01 Arquitetura Genérica do Data Warehouse (Favoritos, 2005) A arquitetura genérica compreende a camada dos dados operacionais que serão acessados pela camada de acesso a dados. As camadas de gerenciamento de processos, transporte e data warehouse são responsáveis por distribuir os dados e estão no centro da arquitetura (ANDREATTO, 1999). A camada de acesso à informação possibilita a extração das informações do DW utilizando um conjunto de ferramentas. Segue abaixo uma breve descrição de cada camada, segundo Andreatto (1999). Camada de banco de dados: é composta pelos dados extraídos dos sistemas transacionais e de fontes externas para compor o DW. Camada de Acesso à informação: é composta pelo hardware e software que serão utilizados para a obtenção dos relatórios. Nesta camada a interação do usuário com do DW com a utilização de ferramentas de manipulação, análise e apresentação de dados. Camada de Acesso aos dados: esta camada é responsável pela ligação entre as ferramentas de acesso e o banco de dados. A camada possui acesso universal de dados, pois se comunica com diversos sistemas de banco de dados sob diferentes protocolos de comunicação. Camada de Metadados: as informações que descrevem os dados utilizados são chamadas de metadados, por exemplo, descrição de

13 13 registros, comando para criação de tabelas, diagramas, entre outros. Para o DW ter plena funcionalidade é necessário que ele contenha uma grande quantidade de metadados. Camada de Gerenciamento de processos: esta camada é responsável pelo gerenciamento de processos, a sua finalidade é manter o DW atualizado. Camada de Transporte: esta camada é responsável pelo transporte das informações pelo ambiente de rede. Isto ocorre com a coleta de informações e transações para entregá-las em locais e tempos pré-determinados. Camada do Data WareHouse : Esta camada é responsável pelos dados utilizados para obter as informações. A Camada envolve a visão lógica ou virtual dos dados, podendo não ter armazenamento Arquitetura de Duas Camadas A arquitetura de duas camadas utiliza um computador de alta capacidade, como um servidor, com o auxilio de aplicações front end, que são ferramentas que realizam operações sobre os dados consultados e os transforma em informações úteis para os usuários, e componentes back end, que são ferramentas responsáveis pela extração, limpeza e cargas dos dados, mais conhecidas como ETL, conforme mostrado na Fig As aplicações front end estão localizadas dentro do servidor principal e são criadas com ferramentas que trabalham de forma cliente/servidor, com uma interface amigável. Isso facilita o acesso, escondendo a complexidade dos dados e tornando a visualização mais simples (ANDREATTO, 1999). Esta arquitetura é bem atraente porque utiliza os servidores de banco de dados existentes e não necessita de grandes investimentos, porém não suporta o acesso de vários usuários simultaneamente.

14 14 Figura 02 Arquitetura de Duas Camadas (Favoritos, 2005) Arquitetura de Três Camadas A arquitetura de três camadas suporta vários usuários e serviços porque é flexível e a informação fica armazenada em várias camadas. Conforme é mostrado na Fig.. 03, na primeira camada ficam as interfaces que trabalham com o usuário, que geralmente são gráficas. Na segunda camada estão os servidores de banco de dados e aplicações e, por isso, têm a necessidade de ter um acesso eficiente e veloz aos dados compartilhados, e na última ficam armazenadas as fontes de dados. A arquitetura de três camadas é a mais utilizada (ANDREATTO, 1999).

15 15 Figura 03 Arquitetura de três camadas (Favoritos, 2005) 2.3 Microsoft SQL Server O motivo da utilização do Microsoft SQL Server é que a fonte de dados está criada nesse sistema. Este tópico dará uma visão geral desta ferramenta Visão Geral O SQL Server é um sistema criado para fazer o gerenciamento de banco de dados que tem uma alta integração com o Windows. Ele foi criado para dar suporte ao processamento de transações de grandes volumes, para armazenamento de dados e aplicativos de apoio à decisão e aplicações em redes (COFFMAN, 200).

16 16 Este sistema suporta várias as arquiteturas de hardware suportadas pelo Windows. A arquitetura do SQL Server é paralela e por isso executa as funções do banco de dados para vários usuários. Para fazer o gerenciamento de forma paralela a arquitetura de gerenciamento do SQL Server dispõe de uma interface visual que ajuda nessa atividade (COFFMAN, 200) Distributed Management Framework (DMF) A arquitetura distribuída de gerenciamento do SQL Server é composta por objetos, serviços e componentes. De acordo com Coffman (2000) a arquitetura dos servidores são gerenciados de qualquer local da rede. Segue abaixo a descrição dos componentes que compõe essa arquitetura. SQL DMO: biblioteca de objetos ActiveX que mostra todas as funções de gerenciamento do SQL Server, é compatível com qualquer linguagem ActiveX. Tem a permissão de gerenciar servidores, banco de dados e tabelas. SQL Enterprise Manager: ferramenta gráfica de administração que utiliza os objetos do SQL DMO. Desta forma torna-se mais fácil o gerenciamento de ambientes com vários servidores. Serviços SQLServerAgent e MSSQLServer: O primeiro serviço trabalha como agendador de tarefas como backup por exemplo. Já o MSSQLServer tem a função de permitir inserir, atualizar e consultar os dados que estão armazenados no SQL Server. 2.4 Power Designer Segundo Senger (1999), a ferramenta Power Designer, desenvolvida pela Sybase, permite a análise e projeto de aplicações com recursos para modelagem de negócios, dados e objetos, sendo composto pelos seguintes módulos:

17 17 DataArchitect este módulo permite o desenho do banco de dados e aceita também a projeção de sistemas mais complexos. O DataArchitect permite a modelagem de sistema de informação usando DER, sendo chamado Conceptual Data Model (CDM). Este módulo permite também gerar o Modelo Físico dos Dados (PDM), gerar scripts SQL e gerar triggers. ProcessAnalyst este módulo permite criar modelos de fluxo de dados usando modelos funcionais de fluxos de dados. O ProcessAnalyst permite também a criação de hierarquia de processos e a união de modelos de outras aplicações. APPModeler este módulo permite o desenvolvimento de aplicações usando Visual Basic, Delphi e outras aplicações, pois faz a geração do código do sistema. WarehouseArchitect este módulo permite o desenvolvimento de Data Warehouse com uma eficiente velocidade ao examinar os dados Arquitetura A arquitetura do Power Designer é bastante flexível, pois permite o suporte a qualquer Sistema de Gerência da Base de Dados Relacional (RDBMS) ou geração de objeto em qualquer linguagem. A ferramenta permite também acrescentar recursos customizáveis para geração ou engenharia reversa, para a importação e exportação para diversos tipos de arquitetura. Outro recurso muito importante da arquitetura é o suporte a UML, que permite utilizar técnicas para fazer o melhoramento do padrão com a utilização de símbolos baseados em estereótipos do ambiente real (SYBASE, 2005). 2.5 Ferramenta ETL A fase de ETL é a principal fase no desenvolvimento de um Data Warehouse, pois envolve a movimentação de dados. A primeira parte desse processo envolve definir as fontes dos dados e fazer a extração dos mesmos. Este processo ocorre mesmo que os dados estejam em diferentes bases. Após a

18 18 definição, parte-se para processo de limpeza e transformação dos dados (DW BRASIL, 2005). A transformação é necessária porque os dados são extraídos de diversos sistemas e geralmente não possuem o mesmo formato. A padronização desses dados é importante porque o usuário não pode consultar informações quem estejam em diferentes formatos e para facilitar a análise dos dados(dw BRASIL, 2005). Para fazer a etapa de ETL é utilizada uma ferramenta que vem no pacote do SQL Server chamada de DTS, que em português significa Serviços de Transformação dos Dados (RESOURCES, 2005). A ferramenta DTS auxilia na importação, transformação e exportação de dados. Além de ser uma ótima ferramenta de ETL, ela pode ser utilizada também para modelar fluxos de validação e homologação entre outros serviços (RESOURCES, 2005). A Etapa de ETL é realizada no período de dois anos devida o Congresso Científico ser realizado de dois e dois anos. 2.6 Business Objects O Business Objects é uma ferramenta que oferece suporte a decisão e os usuários que a utilizam podem criar relatórios extraindo dados de diversas fontes. A apresentação desse relatório possui várias opções de formatação e templates. A ferramenta é composta por 8 módulos que serão descritos a seguir (OLAP, 2005). Módulo Designer Neste módulo o usuário da ferramenta pode criar estruturas de dados, denominando-se Universo. O Universo é composto de classes, dimensões, atributos e fatos. O universo está ligado a uma base de dados da qual é importada toda estrutura e restrições. Na criação do Universo o Business Objects faz à checagem da integridade da estrutura criada e armazená-la no repositório para que os outros usuários possam extrair informações sobre a base.

19 19 Para fazer esta extração são utilizados os módulos Business Objects, WebIntelligence e Business Query (BUSINESS, 2005). Business Objects Este módulo faz a recuperação dos dados na forma de relatórios, a partir dos universos criados pelo módulo Designer. Após a geração dos relatórios, pode ser feita a análise dos dados executando as operações de slice-and-dice e drill up/down. Neste componente também é possível fazer consultas em SQL sobre a estrutura de dados (BUSINESS, 2005). Business Miner Neste módulo é utilizada a tecnologia de data mining sobre os dados extraídos de sistemas corporativos, de forma que é possível localizar padrões nos dados analisados (BUSINESS, 2005). O data mining é um processo de mineração de dados que é utilizado para explorar grandes quantidades de dados para encontrar padrões consistentes. O processo de data mining é dividido em exploração, construção do modelo e validação (OLAP, 2005). Web Intelligence Este módulo disponibiliza as mesmas funcionalidades do módulo Business Objects para Internet. O Web Intelligence cria um applet desenvolvido em Java. Com a instalação deste componente não é necessário fazer a instalação do Business Objects. Isso ocorre porque o applet é acessível através de qualquer navegador (BUSINESS, 2005). Document Agent Server Este módulo consiste em um servidor utilizado para atualizar, imprimir, distribuir relatórios e publicá-los na Internet de forma automática. É possível também programar consultas para serem executadas posteriormente e enviar os resultados por (BUSINESS, 2005)..

20 20 Supervisor Este módulo trabalha com a administração do ambiente, controle de recursos e usuários, universos e relatórios. Outras funcionalidades existentes também são as de acessos às linhas das tabelas ou, se desejar, também limitar o tempo de execução das consultas. Esse controle pode ser atribuído em nível de usuário ou grupo de usuários, permitindo que os privilégios sejam herdados por todos os usuários pertencentes a um determinado grupo. Business Query O módulo permite que o usuário execute consultas no Microsoft Excel utilizando os universos criados, sem que haja a necessidade de usar o Business Objects (BUSINESS, 2005) Metodologias de Data Warehousing No mercado existe um grande número de metodologias de Data Warehousing e este tópico fará uma breve descrição e comparação das metodologias mais utilizadas (SEN, 2005). Segundo SEN(2005) as metodologias são classificadas baseando-se em três categorias: Vendedoras de Núcleo de Tecnologia; Vendedoras de Infra-Estrutura; Companhias de Modelagem de Informação. Para fazer está comparação é utilizado um conjunto de atributos considerados essenciais paras metodologias de data warehousing que serão descritos a seguir. Na primeira categoria é considerada a capacidade do núcleo da companhia, observado as diferentes aplicações da metodologia levando em consideração o segmento que a mesma está sendo aplicada, pois as empresas utilizam esquemas no data warehousing para obter vantagens em seus bancos de dados (SEN,2005). As metodologias que têm esse perfil são a NCR s Teradata, Oracle, IBMs DB2, Sybase e a Microsoft SQL Server. Para melhor entendimento, uma comparação das mesmas é apresentada na tabela 01.

21 21 Tabela 01: Representação da comparação da categoria Vendedoras de Núcleo de Tecnologia (SEN, 2005) Na segunda categoria encontram-se as metodologias que trabalham com a infra-estrutura do negócio do Data Warehouse. Estas metodologias utilizam ferramentas de infra-estrutura, trabalham com diferentes bancos de dados e auxiliam na etapa de extração, filtragem e carga dos dados (SEN,2005). Alguns exemplos de metodologias que se encaixam nessa categoria são a SAS, Informática, Computer Associates Plantinum, Visible Technologies e Hyperions. Um comparativo das mesmas é apresentado na tabela 02.

22 22 Tabela 02: Representação da comparação da categoria Vendedoras de Infra- Estrutura (SEN, 2005) Para terceira categoria entram as metodologias que trabalham com planejamento do recurso da empresa, pois o projeto de um Data Warehouse necessita de grande investimentos para a sua construção (SEN,2005). As metodologias que se enquadram nesta categoria são a Cap Gemini Ernst Yong (CGEY), Corporate Information Designs e Creative Data.. A comparação das mesmas é apresentada na tabela 03.

23 23 Tabela 03: Representação da comparação da categoria Companhias de Modelagem de Informação. (SEN, 2005) Todas as metodologias trabalham de formas diferentes, mas têm o objetivo de conhecer e modelar as necessidades do usuário para a construção de um data warehouse. (SEN,2005) A metodologia utilizada para desenvolver este trabalho foi a e-coment, criada recentemente pela Decision Warehouse. Devido a este fato a mesma ainda não se encontra em nenhuma das categorias de comparação. A seguir são apresentadas as fases da metodologia e-coment, conforme (DECISION, 2005).

24 Metodologias e-coment A metodologia e-coment gerência processos e etapas para implementação de soluções de Tecnologia de Informação que são utilizadas para ter-se êxito ao final de um projeto, pois trabalha com a colaboração e transmissão de tecnologia. Durante a implementação do projeto é possível ter um acompanhamento bem detalhado do mesmo. A e-coment poder ser utilizada em projetos de qualquer tamanho porque é bastante flexível, oferece acesso dos membros da equipe aos seguintes procedimentos: Planejamento; Construção; Implementação. Tais procedimentos são utilizados para garantir a eficiência do projeto. A seguir é apresentada a descrição das fases de e-comet Fases de Desenvolvimento Para iniciar o desenvolvimento do Data Warehouse é necessário fazer o estudo do sistema corporativo, que será a fonte para a importação de dados. O próximo passo é fazer o planejamento do Data Mart para levantar todas as necessidades gerenciais, para posteriormente fazer a composição e aprovação do escopo do Data Mart. A próxima etapa é a modelagem do Data Mart, que tem o objetivo de desenhar o banco de dados baseado no escopo, utilizando a modelagem dimensional. Ao término da modelagem iniciam-se os processos de extração, transformação e carga dos dados, também conhecida como ETL.

25 25 Esta etapa ETL tem o objetivo de executar a extração e carga dos dados da base do sistema corporativo ou, caso existissem outras bases, também haveria a extração para a base do Data Warehouse. A próxima etapa é a de implantação da consultas do Data Mart. Nesta fase ocorre a implantação da camada semântica e também os relatórios definidos na fase de escopo. E por último é realizada a etapa de validação dos dados, que consiste em verificar se os resultados encontrados estão de acordo com o que foi planejado. 2.8 Modelagem Dimensional Segundo R. Kimball (2000), a modelagem dimensional é a técnica utilizada pelos analistas para desenvolver um projeto de Data Warehouse e tem por objetivo a apresentação do dado em uma arquitetura padrão para permitir acessos de alta performance. O tipo de modelagem dimensional aplicada para desenvolver este trabalha será o modelo conhecido Star Join Schema Star Join Schema A modelagem dimensional também é conhecida como star join schema ou simplesmente estrela. (R. Kimball, 2000) Neste modelo existe uma tabela de fatos no centro do diagrama com junções se conectando as outras tabelas, chamada de dimensões, conforme representado na Fig. 4. As outras tabelas têm uma única junção com a tabela central. Este tipo de modelagem trabalha com dois conceitos: Tabela de Fatos: trabalha com as medições numéricas do negócio. O fato é um indicador do negócio que corresponde ao que será analisado. Tabela de Dimensão: trabalha com as descrições textuais das dimensões do negócio. A dimensão mostra a visão que será analisada.

26 26 Uma breve descrição das características que compõe o modelo estrela é apresentada a seguir (R. Kimball, 2000): arquitetura previsível; a tabela de fatos e a de dimensão é alterada facilmente apenas inserindo novas colunas, sem comprometer toda a estrutura existente; altas performances nas consultas devido à desnormalização; as aplicações que existiam antes das alterações continuam funcionando sem problemas. Um fato importante para ser analisado neste tipo de modelagem é que a tabela de fatos representa os relacionamentos de muitos-para-muitos entre as dimensões, e a mesma tem como chave primária o conjunto de chaves estrangeiras de todas as dimensões. Figura 04: Representação do modelo estrela A seguir terá início a seção que descreve o material e métodos utilizados para a elaboração deste trabalho.

27 27 3 Materiais e Métodos Este trabalho tem o objetivo da construção de um guia para validação de Um Data Warehouse. Os processos para implementação do Data Warehouse são com o conhecimento e extração dos dados dos sistemas transacionais. Foi utilizado o banco de dados do Congresso Científico para auxiliar no desenvolvimento deste trabalho. O trabalho de extração e organização dos dados foram realizados de forma consistente para a construção do Data Warehouse, de maneira que retrate com confiança a realidade do negócio. Para a construção do Data Warehouse foram utilizadas as seguintes ferramentas: 1. Microsoft SQL Server: A ferramenta onde foi instalada a fonte de dados que será utilizada para fazer a análise dos dados e posteriormente para fazer a criação do Data Warehouse. 2. Power Designer: A ferramenta será utilizada para fazer o escopo do Data Warehouse e posteriormente a geral de scripts para a criação do Data Warehouse. 3. Data Mart: É definido como a Visão de Negócio. Segundo outra definição do Data Mart, contém informações gerenciais sobre um determinado negócio. No caso deste trabalho, serão as informações do IV Congresso Cientifico do CEULP/ULBRA. Um Data Warehouse que contenha vários Data Mart é chamado de Data Warehouse Corporativo. 4. Ferramenta ETL: A ferramenta DTS irá auxiliar na importação, transformação e exportação de dados. Além de ser uma ótima ferramenta de ETL será realizada de dois em dois anos devido o Congresso ser realizado neste período.

28 28 5. Sistemas de Informações executivas: São sistemas que demonstram a visualização simplificada dos dados, isto ocorre que o usuário sem experiência tenha a possibilidade de entender os dados. 3.1 Metodologia Para fazer a elaboração deste guia será utilizada uma metodologia e- Collaborative Methodology (e-comet). Esta metodologia é utilizada para gerenciar processos e etapas para implantação do Data Warehouse. O e-comet possibilita que todos os envolvidos no projeto tenham um conhecimento detalhado do projeto. 3.2 Fases de Desenvolvimento Banco de Dados O banco de dados utilizado para fazer a validação desse guia foi o do IV Congresso Científico e V Jornada de Iniciação Científica realizada pelo CEULP /ULBRA entre os dias 17 e 18 de maio de A base estava sendo disponibilizada no Portal do CEULP/ULBRA para que os usuários fizessem sua inscrição para o Congresso bem como submetessem seus artigos Entrevistas com Usuários A etapa inicial para desenvolver um Data Warehouse é ter conhecimento sob o domínio. Este conhecimento pode ser obtido através de entrevistas e estudo de relatórios dos sistemas que servirão como fontes de dados. Para fazer a validação desse guia ocorreu uma entrevista informal com o professor Fabiano Fagundes, que informou sobre a necessidade de realizar estudos estatísticos sobre o Congresso Científico, sendo que o mesmo me forneceu a base de dados. Após avaliar as doze tabelas que compõe o banco de dados e as informações

29 29 colhidas com a entrevista, a justificativa para construção desse Data Mart foi a flexibilidade para realizar estudos estatísticos sobre a quantidade de artigos inscritos com titulo e autor, artigos inscritos com titulo e áreas e a avaliação recebida pelos artigos inscritos com titulo, data e status final Modelagem do Data Mart A etapa de modelagem ocorre quando a pessoa responsável pela construção do Data Warehouse já obteve informações suficientes parra a criação do modelo que será implementado. Observando as necessidades expostas anteriormente, notou-se a necessidade da criação de quatro dimensões que terão informações importantes para realizar os estudos estatísticos: Dimensão Artigo; Dimensão Avaliação; Dimensão Área_Usuario; Dimensão Usuário. Nestas dimensões serão armazenadas as informações necessárias para realizar os estudos estatísticos, retiradas do Banco de Dados e carregadas no Data Warehouse durante o processo de ETL. A justificativa para criação apenas de quatro dimensões foi que elas atendem as necessidades da Comissão Organizadora do Congresso Cientifico do CEULP/ULBRA. Caso venha surgir mais alguma necessidade da Comissão Organizadora, o modelo do Data Mart poderá ser adaptado para atender estas necessidades. A aprovação do Modelo do Data Mart é feita pelos clientes que serão usuários do Data Warehouse. No caso deste trabalho a aprovação deste modelo foi feita pelo responsável pelo desenvolvimento deste guia, verificou que o mesmo atendia as necessidades explicadas por ele na etapa de entrevistas pelo professor Fabiano Fagundes. A modelagem do Data Mart foi realizada com a ferramenta Case Power Designer com a criação de um novo modelo físico com uma tabela de fatos,

30 30 chamada Ftestagio e quatro da tabela de dimensões, chamadas Área_Usuario, Artigo, Avaliação e Usuário. As informações necessárias para a criação do Data Mart foram retiradas do banco do IV Congresso Cientifico que estão armazenados no SQL Server Criação do Banco de Dados A criação do banco de dados onde será armazenado o Data Warehouse geralmente é responsabilidade de um analista ou pessoa que tenha o mesmo nível de conhecimento da empresa ou corporação onde está sendo construído o Data Warehouse. As informações para a criação do banco são repassadas pelo analista responsável pela construção do Data Warehouse. No caso deste trabalho, com a aprovação do modelo pelo cliente, que foi desenvolvimento na Ferramenta Case Power Designer, foi gerado um script sql contendo todas as informações necessárias para a criação do banco de dados. Finalizado esta etapa, foi utilizada a ferramenta do Query Analyzer do SQL Server para fazer a execução desse script, que criou o banco de dados chamado de DW. Os resultados serão mostrados mais adiante, na próxima seção Processo Extração, Transformação e Carga dos Dados ETL A fase de ETL é uma fase importante no desenvolvimento de um Data Warehouse, pois envolve a movimentação de dados. Por isso, o analista responsável pela construção deve definir as fontes dos dados e escolher a melhor forma de fazer a extração. Esta etapa envolve transformações dos dados e por ultimo fazer a carga dos mesmos no ambiente do Data Warehouse. Para validar este guia foi utilizado como fonte o banco de dados do IV Congresso Científico. Caso houvesse outras fontes de dados, seriam analisadas e o escopo do Data Mart seria alterado para atender as necessidades do cliente. Como a fonte de dados está disponibilizada no formato de SQL, o servidor utilizado para mantê-la foi ambiente Microsoft SQL Server Como o

31 31 ambiente do Data Warehouse pode ser criado em diversas base de dados, decidiu-se criá-lo no SQL Server. Para fazer a Etapa de ETL foi utilizada uma ferramenta do próprio SQL Server, conhecida DTS (Data Transfomation Services), que permite a criação de pacotes que irão fazer toda essa etapa ETL. O processo iniciou-se com a criação de um pacote que fez a etapa extração, carga e transformação da fonte para as três dimensões do Data Warehouse, sendo elas Artigo, Usuário e Área_Usuario. Prosseguindo o processo de ETL, foi criado um pacote que fez a etapa de extração, carga e transformação para a tabela de fatos do Data Warehouse. As informações necessárias para o preenchimento da tabela foram retiradas das três dimensões que foram carregadas anteriormente. Outro pacote foi criado para a etapa de ETL para dimensão Avaliação, devido às restrições do Microsoft SQL Server. Esta restrição foi criada para corrigir o banco de dados onde ficara o Data Warehouse. Caso esta dimensão fosse carregada junto com as outras três, os dados ficariam carregados de forma invalida. Houve a necessidade de criação de uma instrução em SQL de Update que teve a função de alterar a data da tabela de fatos. Este registro foi utilizado para identificar a data em que foi executada a carga no Data Warehouse. Os resultados destes processos estão descritos mais adiante na seção Resultados e Discussão Implantação das Consultas do Data Mart Esta etapa é importante, pois envolve a escolha de uma ferramenta de consulta que atenda as necessidades dos clientes, pois os clientes irão trabalhar em cima dos resultados trazidos por essa ferramenta. No caso deste trabalho serão obtidos resultados que servirão como base para estudos estatísticos do Congresso. Para realizar esta etapa foi utilizada a ferramenta OLAP Business Objects. Utilizou-se o módulo Designer para criação da estrutura de dados. Esta estrutura é tratada pelo Designer como universo, e o mesmo recebeu o nome de

32 32 DW. Este universo é composto por cinco classes que são as dimensões e a tabela de Fatos. A visualização deste universo será mostrada na seção Resultados e Discussão. O próximo passo foi a utilização do módulo BusinessObjects, com a criação de três relatórios. O primeiro relatório tem o objetivo de mostrar a quantidade de artigos inscritos, com titulo e autor no Congresso Científico de O relatório foi gerado com a utilização do atributo FT_ART_ID e FT_DATA da classe FtEstágio, o atributo ART_TITULO da classe Artigo e o atributo USUARIO_NOME da Classe Usuário. Houve a criação de uma restrição com o atributo FT_DATA para que retornasse apenas os artigos inscritos no congresso de O segundo relatório criado tem o objetivo de mostrar os artigos inscritos com suas respectivas áreas. Para validar esse relatório foi utilizado o atributo FT_ART_ID e FT_DATA da classe FtEstágio, o atributo ART_TITULO da classe Artigo e o atributo USUARIO_AREA da classe Área_Usuario. Houve a criação de uma restrição com o atributo FT_DATA para que retornasse apenas os artigos inscritos no Congresso de O terceiro relatório tem por objetivo mostrar a avaliação recebida pelos artigos inscritos com titulo, data e status final. Para validar esse relatório foi utilizado o atributo FT_ART_ID e FT_DATA da classe FtEstágio, o atributo ART_TITULO da classe Artigo e os atributos AVALIACAO_DATA e AVALIACAO_STATUS da classe Avaliação. Houve a criação de uma restrição com o atributo FT_DATA para que retornasse apenas os artigos inscritos no Congresso de Validação dos Dados Nesta etapa ocorre a validação dos resultados encontrados pelas consultas. Depois de criados os três relatórios citados nas etapas anteriores, foi feita uma comparação com a base dados do Congresso Científico para avaliar se os resultados encontrados pela consultas no ambiente do Data Warehouse estão de acordo com as informações no sistemas que serviram de fonte. A validação foi

33 33 feita com o apoio da ferramenta Query Anayzer do SQL Server. Para isso foi utilizada a instrução de Select nos três casos. Os resultados serão apresentados na próxima seção.

34 34 4 Resultados e Discussão Os próximos itens dessa seção irão mostrar os resultados encontrados com a execução de cada etapa para a construção de um Data Warehouse conforme represente a Fig. 05. Figura 05: Representação das etapas para construção de um Data Warehouse. 4.1 Banco de dados A base de dados utilizada neste trabalho estava sendo disponibilizada no Portal do CEULP/ULBRA através de um sistema para que os usuários fizessem sua inscrição para o Congresso bem como submetessem seus artigos. 4.2 Entrevistas com Usuários Nesta etapa aconteceu uma entrevista informal com o professor Fabiano Fagundes, que informou sobre a necessidade de realizar estudos estatísticos sobre o Congresso Científico. Após avaliar o banco de dados e as informações

35 colhidas com a entrevista, a justificativa para construção desse Data Mart foi a flexibilidade para realizar estudos estatísticos sobre o Congresso Científico Modelagem do Data Mart A etapa mais importante para a criação do Data Warehouse foi a etapa de análise dos sistemas que serviram de fonte. Houve a necessidade de conhecer todo o ambiente do qual seriam retiradas às informações que validariam o Data Mart, pois a criação do escopo do Data Mart deve atender todas as necessidades da comissão organizadora do evento. Este é um fator importante, pois caso algum requisito não seja atendido, pode ocorrer à invalidação de todo o projeto. Com o apoio da Ferramenta Case Power Designer, foi criado o modelo físico do banco em que ficará armazenado o Data Warehouse. Foram criados os pacotes Dimensão e Fatos. Dentro do pacote de Dimensão foram criadas quatro tabelas, de acordo com as necessidades que foram definidas anteriormente. Esses tabelas são: Área_Usuario, Artigo, Avaliação, Usuário e FtEstagio. Na tabela Área_Usuario foram armazenadas todas as informações sobre a área do usuário. Nome Tipo Restrição AREA_USUARIO_ID Int Primary Key AREA_USUARIO_AREA Varchar(50) - AREA_USUARIO_LISTA char(50) - Tabela 04: Representação da tabela Area_Usuario no Data Mart artigos. Na tabela Artigo foram armazenadas todas as informações sobre os Nome Tipo Restrição ART_ID Int Primary Key

36 36 ART_AUTOR_ID Int - ART_AREA_ID Int - ART_TIPO Varchar(50) - ART_TITULO Varchar(500) - ART_PALAVRA Varchar(200) - ART_RESUMO Text - ART_INTRODUCAO Text - ART_MATERIAIS Text - ART_RESULTADOS Text - ART_CONCLUSAO Text - ART_REFERENCIAS Text - ART_REFERENCIAS Text - ART_DATA datetime - ART_STATUS Varchar(50) - ART_AVALIADOR Int - Tabela 05: Representação da tabela Artigo no Data Mart Na tabela avaliação foram armazenadas todas as informações sobre as avaliações que os artigos receberam. Nome Tipo Restrição AVALIACAO_ID Int Primary Key AVALICAO_ART_ID Int - AVALIACAO_AVALIADOR_ID Int - AVALIACAO_DATA datetime - AVALIACAO_COMENTARIO text - AVALIACAO_NOTA1 - AVALIACAO_NOTA2 - AVALIACAO_NOTA3 - AVALIACAO_NOTA4 - AVALIACAO_NOTA5 -

37 37 AVALIACAO_NOTA6 - AVALIACAO_STATUS - Tabela 06: Representação da tabela Artigo no Data Mart Na tabela Usuário foram armazenadas todas as informações sobre os usuários que participaram do congresso. Nome Tipo Restrição USUARIO_ID int Primary Key USUARIO_NOME Varchar(50) - USUARIO_ Varchar(50) - USUARIO_SENHA Varchar(50) - USUARIO_AREA Int - USUARIO_TIPO Int - USUARIO_TELEFONE Varchar(50) - USUARIO_ENDERECO Varchar(50) - USUARIO_BAIRRO Varchar(50) - USUARIO_CEP Varchar(10) - USUARIO_CIDADE Varchar(50) - USUARIO_UF Varchar(2) - Tabela 07: Representação da tabela Usuário no Data Mart Na ferramenta Case Power Designer, a estrutura pode ser visualizada conforme representada na Fig. 06.

38 38 art_id art_autor_id art_area_id Artigo int int int <pk> area_usuario_id area_usuario_area area_usuario_lista Area_Usuario int char(50) <pk> Avaliacao avaliacao_id avalicao_art_id avaliacao_avaliador_id avaliacao_data avaliacao_comentario avaliacao_nota1 avaliacao_nota2 avaliacao_nota3 avaliacao_nota4 avaliacao_nota5 avaliacao_nota6 avaliacao_status avaliacao_ok int int int datetime text <pk> Usuario_id Usuario_nome Usuario_ Usuario_senha Usuario_area Usuario_tipo Usuario_telefone Usuario_endereco Usuario_bairro Usuario_cep Usuario_cidade Usuario_uf Usuario_ int int int varchar(10) varchar(2) <pk> Figura 06: Representação da tabelas geradas dentro do pacote Dimensão Dentro do pacote de Fatos foi criada uma tabela de Fatos e as relações necessárias para fazer a validação desse escopo, de acordo com as necessidades que foram definidas anteriormente e serão descritas abaixo. Na tabela FtEstagio foram armazenadas as informações necessárias como, por exemplo, os identificadores das outras tabelas que estão no pacote Dimensão. Nome Tipo Restrição FT_ID int Primary Key FT_ART_ID int Foreign Key FT_DATA datetime - FT_AREA_USUARIO_ID int Foreign Key

39 39 FT_USUARIO_ID int Foreign Key FT_AVALIACAO_ID int Foreign Key Tabela 08: Representação da tabela FtEstágioUsuário no Data Mart Para o escopo ter validade, também foram atribuídas as seguintes referências: Foi atribuída a restrição de chave estrangeira no campo FT_ART_ID da tabela de Fatos FTESTAGIO referenciando o campo ART_ID da tabela de Dimensão ARTIGO. Foi atribuída restrição de chave estrangeira no campo FT_AREA_USUARIO_ID da tabela de Fatos FTESTAGIO referenciando o campo AREA_USUARIO_ID da tabela de Dimensão AREA_USUARIO. Foi atribuída restrição de chave estrangeira no campo FT_ART_ID da tabela de Fatos FTESTAGIO referenciando o campo AVALIACAO_ART_ID da tabela de Dimensão AVALIACAO. Foi atribuída restrição de chave estrangeira no campo FT_USUARIO_ID da tabela de Fatos FTESTAGIO referenciando o campo USUARIO_ID da tabela de Dimensão USUARIO. Na ferramenta Case Power Designer à estrutura acima pode ser visualizada conforme a Fig. 07.

40 40 area_usuario_id area_usuario_area area_usuario_lista Area_Usuario int char(50) <pk> FK_FTESTAGI_FATO_AREA_AREA_USU ft_art_id ft_data ft_area_usuario_id ft_usuario_id Ftestagio int datetime int int <pk,fk3,fk4> <fk1> <fk2> art_id art_autor_id art_area_id art_tipo art_titulo art_palavra art_resumo FK_FTESTAGI_ARTIGO_ARTIGO art_introducao art_materiais art_resultados art_conclusao art_referencias art_data art_status art_avaliador Artigo int int int varchar(500) varchar(200) text text text text text text datetime int <pk> FK_FTESTAGI_AVALIACAO_AVALIACA FK_FTESTAGI_FATO_USUA_USUARIO_ Avaliacao avaliacao_id avalicao_art_id avaliacao_avaliador_id avaliacao_data avaliacao_comentario avaliacao_nota1 avaliacao_nota2 avaliacao_nota3 avaliacao_nota4 avaliacao_nota5 avaliacao_nota6 avaliacao_status int int int datetime text <pk> Usuario_id Usuario_nome Usuario_ Usuario_senha Usuario_area Usuario_tipo Usuario_telefone Usuario_endereco Usuario_bairro Usuario_cep Usuario_cidade Usuario_uf Usuario_ int int int varchar(10) varchar(2) <pk> Figura 07: Representação da tabelas geradas dentro do pacote Fatos 4.4 Banco de Dados DW O script abaixo foi gerado pela Ferramenta Case Power Designer e será utilizado para a criação do banco onde será instalado o DW. /*============================================================*/ /* Table: AREA_USUARIO */ /*============================================================*/ create table AREA_USUARIO ( AREA_USUARIO_ID int not null, AREA_USUARIO_AREA null, AREA_USUARIO_LISTA char(50) null,

41 41 constraint PK_AREA_USUARIO primary key (AREA_USUARIO_ID)) go /*============================================================*/ /* Table: ARTIGO */ /*============================================================*/ create table ARTIGO ( ART_ID Int not null, ART_AUTOR_ID int null, ART_AREA_ID int null, ART_TIPO null, ART_TITULO varchar(500) null, ART_PALAVRA varchar(200) null, ART_RESUMO text null, ART_INTRODUCAO text null, ART_MATERIAIS text null, ART_RESULTADOS text null, ART_CONCLUSAO text null, ART_REFERENCIAS text null, ART_DATA datetime null, ART_STATUS null, ART_AVALIADOR int null, constraint PK_ARTIGO primary key (ART_ID) /*============================================================*/ /* Table: AVALIACAO*/ /*============================================================*/ create table AVALIACAO ( AVALIACAO_ID int not null, AVALICAO_ART_ID int null, AVALIACAO_AVALIADOR_ID int null, AVALIACAO_DATA datetime null, AVALIACAO_COMENTARIO text null, AVALIACAO_NOTA1 null,

42 42 AVALIACAO_NOTA2 null, AVALIACAO_NOTA3 null, AVALIACAO_NOTA4 null, AVALIACAO_NOTA5 null, AVALIACAO_NOTA6 null, AVALIACAO_STATUS null, constraint PK_AVALIACAO primary key (AVALIACAO_ID)) go /*============================================================*/ /* Table: USUARIO_*/ /*============================================================*/ create table USUARIO_ ( USUARIO_ID int not null, USUARIO_NOME null, USUARIO_ null, USUARIO_SENHA null, USUARIO_AREA int null, USUARIO_TIPO int null, USUARIO_TELEFONE null, USUARIO_ENDERECO null, USUARIO_BAIRRO null, USUARIO_CEP varchar(10) null, USUARIO_CIDADE null, USUARIO_UF varchar(2) null, constraint PK_USUARIO_ primary key (USUARIO_ID)) go alter table FTESTAGIO add constraint FK_FTESTAGI_ARTIGO_ARTIGO foreign key (FT_ART_ID) references ARTIGO (ART_ID) go alter table FTESTAGIO add constraint FK_FTESTAGI_AVALIACAO_AVALIACA foreign key (FT_ART_ID)

43 43 references AVALIACAO (AVALIACAO_ART_ID) go alter table FTESTAGIO add constraint FK_FTESTAGI_FATO_USUA_USUARIO_ foreign key (FT_USUARIO_ID) references USUARIO_ (USUARIO_ID) go alter table FTESTAGIO add constraint FK_FTESTAGI_FATO_AREA_AREA_USU foreign key (FT_AREA_USUARIO_ID) references AREA_USUARIO (AREA_USUARIO_ID) go Com a execução do script mostrado acima, denominado de DW, foi criado o banco no SQL Server, conforme o diagrama mostrado abaixo. Figura 08: Representação do banco de dados criado no SQL Server

44 Processo de ETL Como resultado do início do processo de ETL, o primeiro pacote recebeu o nome de Dimensão. Neste pacote foram criadas duas conexões, uma de origem, chamada bd_congresso, em referência a base de dados que serviu como fonte, e a outra conexão, chamada DW, em referência ao destino dos dados, que é o ambiente do Data Warehouse que foi criado. Dentro desse mesmo pacote foram criados três Transfomation Data Task, que são responsáveis por fazer a extração, transformação e carga dos dados da fonte para a dimensão de destino. A seguir uma breve descrição do que cada Transformation Data Task fez. Transformation Data Task Artigo Este foi responsável por fazer o processo ETL para a dimensão Artigo, onde os dados foram extraídos da base de dados do Congresso, da tabela chamada TbArt, e foram carregados no ambiente do DW na dimensão Artigo. As transformações ocorridas foram apenas na seleção de campos que atenderiam as necessidades da comissão organizadora. Portanto, alguns itens da tabela de origem não foram utilizados. Este processo gerou um total de trezentos e cinqüenta e cinco registros exportados. Transformation Data Task Usuario Este foi responsável por fazer o processo ETL para a dimensão Usuario, onde os dados foram extraídos da tabela TbUser, e foram carregados no ambiente do DW, na dimensão Usuario. As transformações ocorridas foram na seleção de campos que atenderiam as necessidades da comissão organizadora. Portanto alguns itens da tabela de origem não foram utilizados. Este processo gerou um total de oitocentos e cinco registros exportados. Transformation Data Task Área_Usuario