KÊNIA DIAS ZORZIN IMPLEMENTAÇÃO DE UM DATA WAREHOUSE PARA AUXILIAR NAS TOMADAS DE DECISÕES DO HEMOCENTRO COORDENADOR DE PALMAS

Transcrição

1 KÊNIA DIAS ZORZIN IMPLEMENTAÇÃO DE UM DATA WAREHOUSE PARA AUXILIAR NAS TOMADAS DE DECISÕES DO HEMOCENTRO COORDENADOR DE PALMAS Palmas 2006

2 ii KÊNIA DIAS ZORZIN IMPLEMENTAÇÃO DE UM DATA WAREHOUSE PARA AUXILIAR NAS TOMADAS DE DECISÕES DO HEMOCENTRO COORDENADOR DE PALMAS Relatório apresentado como exigência curricular do Curso de Sistemas de Informação, nas disciplinas de TCC I e TCC II, sob orientação do Prof. Ricardo Marx e Prof. M. Sc. Fabiano Fagundes. Palmas 2006

3 iii KÊNIA DIAS ZORZIN IMPLEMENTAÇÃO DE UM DATA WAREHOUSE PARA AUXILIAR NAS TOMADAS DE DECISÕES DO HEMOCENTRO COORDENADOR DE PALMAS Relatório apresentado como exigência curricular do Curso de Sistemas de Informação, nas disciplinas de TCC I e TCC II, sob orientação do Prof. Ricardo Marx e Prof. M. Sc. Fabiano Fagundes. Aprovada em dezembro de 2006 BANCA EXAMINADORA Prof. M. Sc. Fabiano Fagundes - Orientador Centro Universitário Luterano de Palmas Prof. Cristina D Ornellas Filipakis Souza Centro Universitário Luterano de Palmas Profª. M. Sc. Madianita Bogo Centro Universitário Luterano de Palmas Palmas 2006

4 iv Dedico este trabalho a minha mamãe, Maria Lúcia e a minha avó Gabriela.

5 v AGRADECIMENTOS A Deus, pela minha vida e minha saúde. À minha mamãe e minha vovó pelo incentivo, paciência e apoio em todos os momentos dessa longa caminhada. Aos meus familiares, Winder, Wesley, tio Wilson, tia Marilda, Diminhas, Claudinha, Lázaro, Beatriz, Eli e muitos outros que sempre me incentivaram na conclusão do curso me dando muita força e ânimo. A minha prima Leila por me apoiar neste momento decisivo de minha vida. À TODOS os meus amigos pela amizade e companheirismo, que não citarei todos os nomes, porque senão, não caberá na folha, mas que permanecem presentes em minha memória todos os dias. Em especial ao meu amigo e companheiro de batalha Robson Nery, pela força e incentivo, não me deixando desistir e nem desanimar nos momentos mais críticos desta caminhada. Obrigada pelas historinhas contadas e por me aturar na sua casa durante tanto tempo. Ao meu amigo Leonardo da Mata, pelas noites em claro regadas à pizza e refrigerante, pelo incentivo e pela pressão psicológica, que me ajudou bastante. Aos meus amigos Marco Antônio, Mirian, Islaide e Francisco Júnior por me apoiarem e entenderem a minha ausência durante todo esse tempo, fazendo me sentir importante com apenas uma mensagem no celular ou um telefonema. Aos meus companheiros de trabalho, que mostraram que eu realmente tenho uma segunda família no trabalho. Obrigada a TODOS, com especial agradecimento à Aldriene, Valdenisa, Vinícius, Júlio César, José Nilton, Geice, Neidivaldo, Márcia, Fabiano e muitos outros pelo carinho especial demonstrado por mim. Ao meu eterno papito orientador, Fabiano Fagundes, principalmente pelo incentivo, pelo apoio, pelas bordoadas, e principalmente pela amizade, acreditando em mim, até mesmo nos momentos em que nem eu mesma acreditava. E a todos os professores que contribuíram para a minha vitória. Muito obrigada a TODOS que me acompanharam durante todo esse tempo de crescimento e aprendizado.

6 vi "A vida é construída nos sonhos e concretizada no amor". [Francisco Cândido Xavier] "Quem sabe concentrar-se numa coisa e insistir nela como único objetivo, obtém, ao cabo, a capacidade de fazer qualquer coisa.. [Mahatma Gandhi]

7 vii SUMÁRIO LISTA DE FIGURAS... IX LISTA DE TABELAS... XI LISTA DE ABREVIATURAS... XII RESUMO... XIII 1. INTRODUÇÃO REVISÃO DE LITERATURA EVOLUÇÃO DOS DADOS E SISTEMAS CONCEITO DE BUSINESS INTELLIGENCE (BI) DEFINIÇÃO DE DATA WAREHOUSE Orientado por assuntos Integração Não Volátil Variação de tempo Granularidade DIFERENÇA ENTRE BANCO DE DADOS TRANSACIONAIS E ANALÍTICOS ON-LINE ANALYTIC PROCESSING (OLAP) Drill Down Drill Up Drill Across DATA MART (DM) ARQUITETURAS DE DATA WAREHOUSE Arquitetura Top Down Arquitetura Bottom Up MODELAGEM DIMENSIONAL Tabelas de Fatos Tabelas de Dimensões Modelo Estrela (Star Schema) Modelo Floco de Neve (Snowflake) PROJETO PARA CONSTRUÇÃO DE UM DATA WAREHOUSE Planejamento de um Data Warehouse Levantamento das necessidades da Empresa...44

8 viii Modelagem Dimensional Projeto físico do banco de dados Projeto de ETL (Extract, Transform and Load) Desenvolvimento de aplicações Validação e testes MATERIAIS E MÉTODOS LOCAL E PERÍODO MATERIAL Fontes bibliográficas Hardwares Softwares MÉTODOS RESULTADOS E DISCUSSÕES PROJETO PARA CONSTRUÇÃO DE UM DATA WAREHOUSE PARA O HEMOCENTRO COORDENADOR DE PALMAS (HEMOTO) Planejamento do Data Warehouse Levantamento das necessidades da Empresa Modelagem Dimensional Projeto físico do banco de dados Projeto de ETL (Extract, Transform and Load) Desenvolvimento de aplicações, Validação e testes CONCLUSÕES E TRABALHOS FUTUROS CONCLUSÕES TRABALHOS FUTUROS REFERÊNCIAS BIBLIOGRÁFICAS ANEXOS...119

9 ix LISTA DE FIGURAS FIGURA 1 ORIENTAÇÃO POR ASSUNTO, ADAPTADO DE MACHADO (2004, P. 28) FIGURA 2 INTEGRAÇÃO DE DADOS, ADAPTADO DE MACHADO (2004, P. 31)...24 FIGURA 3 NÃO VOLÁTIL NO DW, ADAPTADO DE MACHADO (2004, P 30) FIGURA 4 EXEMPLO DE GRANULARIDADE, ADAPTADO DE MACHADO (2004, P. 47) FIGURA 5 EXEMPLO DE DM ADAPTADO DE MACHADO (2004, P. 44) FIGURA 6 ARQUITETURA DE UM AMBIENTE DE DW (SOARES, 1998, P. 21) FIGURA 7 MODELO TOP DOWN (SOARES, 1998, P. 26) FIGURA 8 EXEMPLO DA ARQUITETURA BOTTOM UP (SOARES, 1998, P. 28) FIGURA 9 EXEMPLO DO MODELO ESTRELA ADAPTADO DE MOREIRA (2006)...39 FIGURA 10 EXEMPLO DO MODELO FLOCO DE NEVE ADAPTADO DE MOREIRA (2006)...40 FIGURA 11 ETAPAS BÁSICAS DA CONSTRUÇÃO DO DW DO HEMOCENTRO...52 FIGURA 12 FLUXO DAS INFORMAÇÕES DO CICLO DO SANGUE FIGURA 13 MODELO DIMENSIONAL DO DW DO HEMOVIDA FIGURA 14 MODELO DO DM DE ATENDIMENTO...76 FIGURA 15 MODELO DO DM DA TRIAGEM...77 FIGURA 16 MODELO DO DM DA COLETA FIGURA 17 MODELO DO DM DO PROCESSAMENTO...79 FIGURA 18 MODELO DO DM DA SOROLOGIA...80 FIGURA 19 MODELO DO DM DA IMUNOHEMATOLOGIA...81 FIGURA 20 EXEMPLO DE CÓDIGO GERADO PELO DBDESIGNER FIGURA 21 - MODELO FÍSICO DO DW DO HEMOVIDA...83 FIGURA 22 EXEMPLO DE CONSULTA PARA PREENCHIMENTO DAS DIMENSÕES...84 FIGURA 23 RESULTADO DA CONSULTA PARA O PREENCHIMENTO DE TABELAS DE DIMENSÃO FIGURA 24 EXEMPLO DE LIMPEZA DOS DADOS NO PROCESSO ETL FIGURA 25 ACESSO AO DTS PELO SQL SERVER FIGURA 26 INÍCIO DO PROCESSO DE DTS FIGURA 27 ESCOLHENDO A ORIGEM E O DESTINO DOS DADOS NO DTS...88 FIGURA 28 MOSTRA OS TIPOS DE CRIAÇÃO DA TABELA E A ESCOLHA DA TABELA DE ORIGEM FIGURA 29 ESCOLHA DOS ATRIBUTOS E DE SALVAMENTO DAS AÇÕES TOMADAS...89 FIGURA 30 - MENSAGEM DE FINALIZAÇÃO DO PROCESSO DTS E PROGRESSO DA OPERAÇÃO...90 FIGURA 31 TABELA DE DIMENSÃO D_PENDENCIA PREENCHIDA APÓS PROCESSO DTS...91 FIGURA 32 EXEMPLO DE SQL PARA PREENCHIMENTO DA TEMP_SOROLOGIA...91 FIGURA 33 RESULTADO DE PREENCHIMENTO DE TABELA TEMPORÁRIA DA SOROLOGIA...92 FIGURA 34 DADOS DA TABELA TEMPORÁRIA DA SOROLOGIA EM PROCESSO DE LIMPEZA...93 FIGURA 35 CÓDIGO FONTE DE PREENCHIMENTO DA TABELA DE FATOS F_SOROLOGIA...94 FIGURA 36 EXEMPLIFICA O SELECT EFETUADO PARA PREENCHIMENTO DA F_SOROLOGIA...95

10 x FIGURA 37 TABELA DE FATOS F_SOROLOGIA PREENCHIDA FIGURA 38 CÓDIGO DE CONSULTAS EFETUADAS PARA PREENCHIMENTOS DE DIMENSÕES...96 FIGURA 39 CÓDIGOS DE PREENCHIMENTO DAS TABELAS TEMPORÁRIAS E DE FATOS...97 FIGURA 40 CÓDIGO SQL GERADO PARA O PRIMEIRO RELATÓRIO...99 FIGURA 41 RELATÓRIO GERADO PARA A PRIMEIRA CONSULTA FIGURA 42 GRÁFICO GERADO PARA O PRIMEIRO RELATÓRIO FIGURA 43 CÓDIGO SQL GERADO PARA A SEGUNDA CONSULTA FIGURA 44 GRÁFICO GERADO PARA O SEGUNDO RELATÓRIO FIGURA 45 GRÁFICO GERADO PARA O SEGUNDO RELATÓRIO FIGURA 46 CÓDIGO SQL GERADO PARA A TERCEIRA CONSULTA FIGURA 47 RELATÓRIO GERADO PARA A TERCEIRA CONSULTA FIGURA 48 GRÁFICO GERADO PARA A TERCEIRA CONSULTA FIGURA 49 CONSULTA SQL GERADA PARA A QUARTA CONSULTA FIGURA 50 RELATÓRIO GERADO PARA A QUARTA CONSULTA FIGURA 51 GRÁFICO GERADO PARA A QUARTA CONSULTA FIGURA 52 CÓDIGO SQL GERADO PARA A QUINTA CONSULTA FIGURA 53 RELATÓRIO GERADO PARA A QUINTA CONSULTA FIGURA 54 GRÁFICO GERADO PARA A QUINTA CONSULTA FIGURA 55 CÓDIGO SQL GERADO PARA A SEXTA CONSULTA FIGURA 56 RELATÓRIO GERADO PARA A SEXTA CONSULTA FIGURA 57 GRÁFICO GERADO PARA A SEXTA CONSULTA FIGURA 58 CÓDIGO SQL GERADO PARA A SÉTIMA CONSULTA FIGURA 59 RELATÓRIO GERADO PARA A SÉTIMA CONSULTA FIGURA 60 GRÁFICO GERADO PARA A SÉTIMA CONSULTA...113

11 xi LISTA DE TABELAS TABELA 1 PRINCIPAIS DIFERENÇAS ENTRE UM BANCO DE DADOS OPERACIONAL E UM DW (DILL, 2002, P.13; TIVES, 2006, P.23; LIMA, 2006, P.15) TABELA 2 VANTAGENS E DESVANTAGENS DE UTILIZAR A ARQUITETURA TOP DOWN (MACHADO, 2004, P.53)...33 TABELA 3 VANTAGENS E DESVANTAGENS DE UTILIZAR A ARQUITETURA BOTTOM UP (MACHADO, 2004, P.53)...35 TABELA 4 REPRESENTAÇÃO DOS ATRIBUTOS DA TABELA F_ATENDIMENTO...58 TABELA 5 REPRESENTAÇÃO DOS ATRIBUTOS DA TABELA D_DOADOR...59 TABELA 6 REPRESENTAÇÃO DOS ATRIBUTOS DA TABELA D_LOCAL_COLETA...60 TABELA 7 REPRESENTAÇÃO DOS ATRIBUTOS DA TABELA D_DATA...61 TABELA 8 REPRESENTAÇÃO DOS ATRIBUTOS DA TABELA D_SUSPENSO TABELA 9 REPRESENTAÇÃO DOS ATRIBUTOS DA TABELA D_TIPAGEM_ABO...62 TABELA 10 REPRESENTAÇÃO DOS ATRIBUTOS DA TABELA F_TRIAGEM...62 TABELA 11 REPRESENTAÇÃO DOS ATRIBUTOS DA TABELA D_PRE_TRIAGEM...63 TABELA 12 REPRESENTAÇÃO DOS ATRIBUTOS DA TABELA F_COLETA TABELA 13 REPRESENTAÇÃO DOS ATRIBUTOS DA TABELA D_BOLSA...64 TABELA 14 REPRESENTAÇÃO DOS ATRIBUTOS DA TABELA D_DOACAO...65 TABELA 15 REPRESENTAÇÃO DOS ATRIBUTOS DA TABELA F_PROCESSAMENTO TABELA 16 REPRESENTAÇÃO DOS ATRIBUTOS DA TABELA D_FRACIONAMENTO TABELA 17 REPRESENTAÇÃO DOS ATRIBUTOS DA TABELA D_DISTRIBUICAO...67 TABELA 18 REPRESENTAÇÃO DOS ATRIBUTOS DA TABELA D_EXPURGO...67 TABELA 19 REPRESENTAÇÃO DOS ATRIBUTOS DA TABELA F_SOROLOGIA TABELA 20 REPRESENTAÇÃO DOS ATRIBUTOS DA TABELA D_PENDENCIA...69 TABELA 21 REPRESENTAÇÃO DOS ATRIBUTOS DA TABELA D_BLOQUEIO TABELA 22 REPRESENTAÇÃO DOS ATRIBUTOS DA TABELA D_REPETICAO...70 TABELA 23 REPRESENTAÇÃO DOS ATRIBUTOS DA TABELA F_IMUNOHEMATOLOGIA TABELA 24 REPRESENTAÇÃO DOS ATRIBUTOS DA TABELA D_EXAME_IMUNO....71

12 xii LISTA DE ABREVIATURAS DW BD SGBD BI DM ER Data Warehouse Banco de Dados Sistema de Gerenciamento de Banco de Dados Business Intelligence Data Mart Entidade Relacionamento

13 xiii RESUMO As empresas atualmente estão procurando novos recursos tecnológicos, procurando se tornar mais competitivas permanecendo no mercado empresarial com diferenciais. Com o surgimento de novas tecnologias, como o ambiente de Data Warehouse (DW) passou a ser possível, aos administradores das empresas, a aquisição de informações de forma rápida, consistente e confiável, oferecendo meios de extrair informações que geram conhecimento, auxiliando nos processos de tomada de decisão e tendências futuras. Por essas características do DW, surgiu a proposta desse trabalho, que consiste na implementação de um Data Warehouse para organizar os dados do Hemocentro Coordenador de Palmas, utilizando a Base de Dados do Hemovida. Os dados serão coletados e disponibilizados de maneira mais clara e objetiva, dando aos gerentes e coordenadores um suporte maior e facilitando nos processos de tomadas de decisão da empresa. Palavras-chave: Business Intelligence, Data Warehouse, Hemovida.

14 14 1. INTRODUÇÃO Com a evolução tecnológica crescente nos últimos tempos, o volume de dados que passou a ser armazenado nos SGBDs (Sistemas de Gerenciamento de Banco de Dados) aumentou consideravelmente. Muitas dessas informações acabam ficando sem utilização, uma vez que não é feito qualquer tipo de tratamento para adquirir conhecimento a partir desses dados. A informação pode ser considerada o centro de toda organização que deseja obter sucesso no mercado competitivo em que vivem atualmente. Muitas empresas têm problemas referentes à organização dos seus dados. A empresa que será analisada nesse trabalho será o HEMOTO (Hemocentro Coordenador de Palmas), localizado na Quadra 301 Norte, Conjunto 02, Lote 01, em Palmas Tocantins. O sistema de distribuição e abastecimento de sangue do Estado do Tocantins está concentrado somente na rede pública do Estado. Este fato é uma das maiores vitórias para o Estado do Tocantins, tirando por comparação outros Estados como o de Goiás e Paraná, os quais possuem Bancos de Sangue privados que oferecem vantagem para que os doadores doem o seu sangue, e cobram do receptor todos os gastos que eles tiveram em todo o processo, desde a coleta até a distribuição do sangue. Cobrança essa que não é feita no Tocantins, por ser uma Instituição Pública. De acordo com a RDC Nº 151 de 21 de Agosto de 2001, Art. 11, Parágrafo 2º, os Hemocentros Privados podem cobrar dos receptores (pacientes que necessitem de transfusão) todos os gastos que tiveram desde a coleta do mesmo até a transfusão dos hemocomponentes. As vantagens que os Hemocentros Particulares oferecem para os doadores dificultam as coletas nos Hemocentros Públicos, pois de acordo com a mesma

15 15 RDC Nº 151 de 21 de Agosto de 2001, Art. 11, Parágrafo 1º, o Hemocentro Público deve fornecer todos os hemocomponentes necessários para um receptor, sem lhe cobrar nenhum tipo de serviço prestado, por já serem ressarcidos pelo SUS (Sistema Único de Saúde). Mas, conforme a RDC 153 de 14 de Julho de 2004, Art. 1º, Anexo I, Parágrafo B.1, uma doação de sangue deve ser voluntária, anônima, altruísta e não remunerada, direta ou indiretamente. Entende-se, pela RDC, que o doador deve ir ao Hemocentro de livre e espontânea vontade para realizar uma doação, que um doador não pode saber para quem será transfundido o seu sangue que foi doado, e nem o receptor deve saber de quem veio o sangue que o mesmo recebeu ou irá receber. Sua doação deve ser feita por amor ao próximo, sem interesses, sem remuneração, sem presentes ou qualquer outro tipo de incentivo que leve o doador a comparecer para doar, com o interesse de ganhar alguma coisa. Mas a maioria das doações que se recebe nos Hemocentros atualmente é de doadores de reposição. Esses doadores comparecem ao Hemocentro com o intuito de doar para uma pessoa que já está precisando para poder fazer uma cirurgia marcada com antecedência. Esse tipo de doação somente repõe o estoque do Hemocentro para que, em casos de urgência, o paciente não venha a óbito por falta de sangue. O Ministério da Saúde, juntamente com os Hemocentros do País, está trabalhando para que não se necessite mais de doações de reposição. Isso seria possível se tivesse no mínimo 80% de doações voluntárias nos Hemocentros. Esses 80% são a meta estabelecida pelo Ministério, para ser atingida até No Hemocentro Coordenador de Palmas, têm-se 48% de doadores voluntários, o que ainda não é suficiente para suprir a necessidade de todo o Estado. Os Hemocentros de todo o País procuram formular estratégias de captação de doadores criativas e eficientes para conscientizar a população brasileira da importância da doação de Sangue. Os Setores de Captação de Doadores trabalham incessantemente tentando mostrar aos jovens e adultos o quanto é importante esse ato de amor vida. Essa não é uma tarefa fácil. Ainda mais quando se trabalha com uma escassez de recursos financeiros e de informações, como é o caso do Tocantins, e ainda se trabalha tentando mudar a formação cultural de um indivíduo.

16 16 No HEMOTO, utiliza-se o sistema Hemovida (Sistema de Gerenciamento em Serviços de Hemoterapia). Analisou-se esse sistema, no qual foi identificada uma dificuldade de obtenção de informações estatísticas. Atualmente, o processo de retirada de informações gerenciais é feito manualmente, sendo um processo demorado, dispendioso e cansativo. O Hemovida é um Sistema criado pelo DataSus do Rio de Janeiro, que organiza desde a recepção do doador no Hemocentro até sua finalização da doação, e ainda registra todos os dados referente a cada bolsa de sangue total que entra no Setor de Fracionamento do Hemocentro, até os resultados de Sorologia e Imunohematologia. Todos os dados que são coletados no Ciclo do Sangue, que vai desde a recepção do doador até a distribuição do hemocomponente, são armazenados no Banco de Dados do Hemovida utilizando o SQL Server Devido a enorme quantidade de informação dispersa armazenada no Banco de Dados do Hemovida, a retirada de relatórios estatísticos detalhados que envolvem vários setores do fluxo do sangue, se torna mais difícil. Faz-se necessário a organização desses dados de forma a facilitar a obtenção de informações. Para resolver esse problema, surgiu a proposta deste trabalho, consistindo no desenvolvimento de um Data Warehouse (DW), em que será criado um banco de dados capaz de manipular o grande volume de dados existente no Hemovida, objetivando um bom desempenho e melhorando o gerenciamento da empresa, através de relatórios que facilitarão as tomadas de decisões e a formulação de novas estratégias. Entretanto, a criação de um DW não é uma tarefa fácil e rápida de se desenvolver, pois engloba vários conceitos e tecnologias existentes no mercado. Faz-se necessário um bom entendimento desses conceitos e tecnologias, que serão abordados em seções posteriores, além de exigir o domínio do Sistema de Informação que será utilizado na construção do DW, que no caso desse trabalho é o Hemovida. Com a implantação do DW, o gestor do Hemoto poderá obter resultados de grande importância, possibilitando, através dele, fazer um levantamento de qual o perfil do doador, por exemplo, qual o maior nível de escolaridade dos doadores

17 17 em determinadas épocas do ano, qual o período em que se obtém o maior índice de inaptidão na triagem dos doadores, entre outras informações que não podem ser analisadas com a base de dados existente. Este trabalho encontra-se organizado da seguinte forma: No capítulo 2, Revisão de Literatura, são apresentados conceitos referentes a evolução dos dados, de sistemas e de Business Intelligence. Após, seguem algumas definições de Data Warehouse, as suas características, diferenças entre bancos relacionais, e as principais formas de utilização do modelo dimensional. E, por fim, é mostrada uma seqüência de passo proposta por Barbieri (2001, p. 68), para a construção de um DW. Para a construção do DW do Hemoto foi utilizada a abordagem do Barbieri. No capítulo 3, Materiais e Métodos, é informado qual o período de elaboração desse trabalho, quais os materiais utilizados, incluindo referências bibliográficas, os equipamentos de hardware e os softwares utilizados na construção do DW e elaboração desse projeto. E, por fim, são descritos quais os métodos utilizados para a elaboração deste trabalho. No capítulo 4, Resultados e Discussões, são descritos os passos executados para a construção do DW, os passos utilizados para construir os relatórios e os resultados obtidos com a construção dos mesmos. No capítulo 5, Conclusões e Trabalhos Futuros, são apresentadas as conclusões obtidas através da elaboração desse trabalho e a relação de possíveis trabalhos que poderiam ser executados no futuro.

18 18 2. REVISÃO DE LITERATURA Este capítulo tem por objetivo apresentar as características de um Data Warehouse, e os conceitos relacionados ao tema, assim como suas funcionalidades e mostrar também um roteiro de construção de um DW. 2.1 Evolução dos Dados e Sistemas Nos anos 70, segundo Barbieri (2001, p.2), Seymour Pappert afirmou que os dados e correlatos seriam responsáveis por uma grande revolução na forma que a sociedade entenderia os dados e sistemas. Os dados eram tratados em segundo plano no processo de desenvolvimento de sistemas, sendo utilizadas para as tomadas de decisões metodologias e inspirações de algumas pessoas. Na década seguinte apareceram novos movimentos metodológicos que mudaram o conceito anterior, dando uma posição de mais destaque para os dados. Nesse período surgiram os conceitos de Administração de Banco de Dados, Modelagem de Dados, da Engenharia da Informação, e da Análise dos dados. A partir dessa década a forma de desenvolvimento de sistemas, que tinham características estáticas nas suas estruturas hierárquicas, foi substituída por o modelo relacional que ofereceu um recurso de flexibilidade das relações entre os programas (INMON,1997, p.5). Com a flexibilização das relações, deu-se início ao processo de integração dos dados dos bancos dimensionais, onde os registros contidos nesses ambientes eram transformados em matrizes bidimensionais (INMON,1997, p. 5).

19 19 Na década de 90, segundo Barbieri (2001, p. 5), surgiu o conceito de Data Mining (Mineração dos dados) que tinha por objetivo oferecer recursos para mineração de dados para auxiliar durante a busca de informações na identificação de padrões de correlação que são geralmente difíceis de detectar com as análises convencionais. Em seguida surgiu o conceito de Business Intelligence (BI) que tem por objetivo auxiliar no processo de tomadas de decisões. No tópico a seguir será abordado o conceito de BI para explicar as características desse conceito, pois com a tecnologia de BI surgiu à necessidade da criação e utilização de um banco de dados diferenciado, assim foi criado o Data Warehouse, para fornecer um suporte melhor nas tomadas de decisões empresariais. Os conceitos de DW serão explicados mais adiante neste trabalho. 2.2 Conceito de Business Intelligence (BI) Segundo Sousa (2003), a inteligência é o conhecimento adquirido a partir da organização e do tratamento dos dados. Com a utilização deste conhecimento nos processos decisórios de uma empresa, novas metas e oportunidades podem ser propostas e alcançadas, proporcionando uma vantagem competitiva para a empresa. O BI é uma tecnologia que oferece recursos para estruturar, acessar e explorar um grande volume de dados, para desenvolver padrões e conhecimentos que permitam identificar padrões que auxiliam na tomadas de decisões (KIMBALL, 2000). Conforme Barbieri (2001, p. 5), essas informações são guardadas normalmente em Data Warehouse (DW) ou Data Mart (DM), com o objetivo de auxiliar a transformação dessas informações em conhecimento estratégico para a empresa. Após essas informações serem transformadas e organizadas, necessita-se que sejam trabalhadas, fazendo combinações, compilações e distribuições, com o objetivo de transformá-las em conhecimento. Os benefícios de ter um Sistema formal de BI são, segundo Sousa (2003): antecipar mudanças no mercado;

20 20 antecipar ações dos competidores; descobrir novos ou potenciais competidores; aprender com os sucessos e falhas das outras empresas; conhecer melhor os seus possíveis parceiros ou aquisições; conhecer novas tecnologias, produtos ou processos que tenham impacto no seu negócio; entrar em novos negócios; rever suas próprias práticas do negócio; auxiliar em novas implementações de ferramentas gerenciais. A utilização das tecnologias de BI faz com que os gerentes e administradores analisem com mais detalhes suas empresas e os seus concorrentes, obtendo resultados que auxiliaram nas mudanças internas que se poderão ser necessárias, nas decisões táticas e estratégicas a serem implantadas para que a empresa cresça. Conforme Sousa (2003), o BI é composto atualmente de muitas tecnologias, entre elas podem ser citadas o Data Warehouse, Data Mart, Metadados, Data Mining, dentre outras. Na próxima sessão serão mostradas as principais características e funcionalidades de um Data Warehouse, auxiliando no entendimento das vantagens de se construir um DW, adquirindo conhecimento para obter novos resultados. 2.3 Definição de Data Warehouse Segundo Machado (2004, p. 20), um DW é um armazém de dados que é utilizado para guardar a história de uma empresa e mantê-lo disponível e acessível para consultas posteriores. Essas consultas devem fornecer resultados rápidos e claros, para realmente auxiliar na competitividade das empresas no mercado de trabalho. Conforme Barbieri (2001, p.49), o DW é definido como um banco de dados, destinado a sistemas de apoio à tomada de decisão e cujos dados foram armazenados em estruturas lógicas dimensionais, possibilitando o seu processamento analítico por ferramentas especiais (OLAP e Mining). A partir

21 21 dessa definição pode-se afirmar que o principal objetivo do DW é fornecer informações que auxiliem os administradores das empresas nas suas tomadas de decisões. Singh (2001, p. 16) diz que o DW integra dados de várias fontes de informações incompatíveis em um repositório de dados único e consolidado. Permite-se, assim, que sejam retiradas informações que se transformarão em conhecimento após uma análise precisa e consistente dos administradores da empresa. As principais justificativas de se implantar a tecnologia de DW em uma organização é a existência de alguns fatores na empresa (MACHADO, 2004, p.26), tais como: a existência e utilização de várias plataformas de hardware e de software; as constantes alterações nos sistemas transacionais corporativos; as dificuldades acentuadas na recuperação de dados históricos em períodos superiores ao ano atual em que está sendo operados as informações; a existência de programas de fornecedores diferentes; a falta de padronização e integração dos dados existentes dos diversos programas utilizados pelas empresas; a falta de documentação e segurança no armazenamento dos dados; a dificuldade de reunir informações dos diversos sistemas existentes nas empresas. Como resultado da implementação de um DW, têm-se a obtenção das seguintes variações do conhecimento que podem ser obtidos do mesmo, segundo Machado (2004, p. 22): informações disponíveis para auxiliar na gestão da empresa; visão das variações do comportamento dos concorrentes e clientes; agilidade de ferramentas para apoio a tomadas de decisões; segurança de que as informações utilizadas nas análises realmente auxiliaram nas decisões;

22 22 uma visão mais abrangente dos indicadores de tendências de mercado; recursos mais abrangentes para análise de negócios; através das tecnologias da informação, atender as necessidades e expectativas dos administradores. Todas as informações e conhecimentos retirados de um DW podem proporcionar um ganho para as empresas em relação a custos e benefícios, economia de tempo e, principalmente, aumento na produtividade das empresas. Pois, através da analise dos dados obtidos do DW os empresários podem fazer novos negócios para melhorar suas empresas e tornarem-nas mais competitivas no mercado de trabalho. E, conforme Inmon (1997, p. 33) um DW é um conjunto de dados baseado em assuntos, integrado, não-volátil, variável em relação ao tempo e de apoio à tomadas de decisões gerenciais. Quando se opta pela construção de um DW deve-se levar em consideração e analisar muito bem as características afirmadas por Inmon. Para melhor entendimento, a seguir serão explicadas e exemplificadas essas características. Mas, além dessas características, a granularidade do DW também deve ser analisado com cuidado, sendo explicada após as características de Inmon Orientado por assuntos Os dados do DW devem ser agrupados pelos assuntos mais importantes ou pelos processos principais da empresa. Geralmente são processos de demonstram o desempenho e os indicadores da mesma. A figura 1 ilustra um exemplo dessa característica.

23 23 AMBIENTE TRANSACIONAL DATA WAREHOUSE Automóvel Vendas Saúde Produtos Perdas Clientes Orientado a aplicações Orientado a assuntos Figura 1 Orientação por assunto, adaptado de Machado (2004, p. 28). A figura 1 mostra a diferença entre um modelo transacional e o DW. No primeiro modelo, o banco de dados é orientado conforme as aplicações existentes na empresa, já no segundo modelo, tem-se o banco de dados dividido pelos principais assuntos da empresa Integração A integração é referente à forma com que os dados são convertidos, padronizados em um único formato e armazenados na base de dados original ou transacional (INMON, 1996, p. 34) e (MACHADO, 2004, p. 31). Os programas normalmente são desenvolvidos, cada um usando uma forma diferente de armazenar seus dados, causando incoerência dos dados no momento de uma junção de bancos de dados, como exemplifica a figura 2.

24 24 Sistema A Sexo: M ou F Retirada e padronização DATA WAREHOUSE Sistema B Sexo: M ou F Sexo: 0 ou 1 Figura 2 Integração de dados, adaptado de Machado (2004, p. 31). Os dados referentes ao sexo dos clientes dos Sistemas A e B, são guardados em suas bases de formas diferentes. No Sistema A, esse dado é armazenado o sexo feminino como sendo a letra F e o sexo masculino como sendo a letra M. No Sistema B, este dado é armazenado o sexo feminino como sendo 1 e o masculino como sendo 0. Os dados provenientes dos Sistemas A e B devem passar por um processo de padronização e limpeza, antes de serem inseridos no DW. Deve ser adotada uma forma padrão de armazenamento, como exemplificado na figura 2, o sexo do tipo feminino será armazenado como F e o masculino como M. Cada desenvolvedor de DW deve prestar bastante atenção a essa característica, pois se esses dados não forem padronizados, podem causar problemas no carregamento do DW, dificultando o trabalho e atrasando o projeto Não Volátil Segundo Inmon (1996, p. 35) os dados são carregados para o DW em grande quantidade após a sua limpeza e padronização sendo acessados constantemente. Mas, a atualização desses dados normalmente não ocorre.

25 25 E, conforme Machado (2004, p. 30), é permitido apenas dois tipos de ações a serem executadas no DW, o de inserção de informações e o de consultas. As operações de atualização e de retirada dos dados não podem ocorrer, para evitar inconsistências nos dados do DW. A figura 3, exemplifica a característica. Banco de Dados Transacional DATA WAREHOUSE Incluir Excluir Alterar BD_A DW_Empresa Incluir Consultar Consultar Figura 3 Não Volátil no DW, adaptado de Machado (2004, p 30). A figura 3 mostra os tipos de consultas que podem ocorrer em um banco de dados transacional e em um DW. A exclusão e a alteração dos dados no DW não são permitidas para que se possam garantir um histórico correto das transações efetuadas nos sistemas de origem dos dados Variação de tempo Segundo Singh (2001, p. 37) os sistemas transacionais não guardam dados históricos por muito tempo, por falta de espaço para manter um nível de desempenho bom dos sistemas. E, conforme Inmon (1996, p. 36) e Machado (2004, p. 29), o tempo em que os bancos transacionais normalmente guardam suas informações são de 60 a 90 dias, após esse tempo os BD passam por atualizações, perdendo os históricos dos dados. O DW deve ser projetado de forma a garantir esse histórico dos dados, em que a cada nova carga feita no DW, deve ser guardada a data em que foi realizada a mesma. E, além de guardar essa data, deve-se utilizar o campo data como um dado chave. Com isso, garantem-se os dados históricos das empresas.

26 Granularidade Inmon (1996, p. 45) define a granularidade como sendo o aspecto mais importante do DW. Essa característica diz respeito ao nível de detalhamento ou de resumo das informações que irão conter no DW. Segundo Inmon (1996, p. 45) e Machado (2004, p. 59) quanto mais detalhes existir no banco, mais baixo será o nível de granularidade, e quanto menos detalhes existir no banco, mais alto será o nível de granularidade. A figura 4, exemplifica as diferenças das granularidades. Alto nível de detalhes = Baixo nível de granularidade Baixo nível de detalhes = Alto nível de granularidade Exemplo: Os detalhes de cada consulta realizada por um médico em um mês. Exemplo: O resumo de todas as consultas feitas por um médico em um mês. 40 Mil bytes por mês 200 registros por mês 200 bytes 1 registro por mês Figura 4 Exemplo de Granularidade, adaptado de Machado (2004, p. 47). A Figura 4 mostra um exemplo da granularidade para as consultas médicas efetuadas por um médico durante um mês de trabalho, na qual podem ser observadas as diferenças entre o menor grau de granularidade e o de maior grau. O primeiro arquivará uma maior quantidade de informações na base do DW e o segundo guardará uma quantidade bem menor na base de dados. A definição de qual grau de granularidade utilizar é definida pelos desenvolvedores, conforme as necessidades dos especialistas do domínio, durante o planejamento do DW.

27 Diferença entre banco de dados transacionais e analíticos Os Sistemas transacionais, segundo Mata (2005, p.12), são utilizados para armazenar as operações diárias de uma empresa e é a base original que fornecem as informações para os sistemas analíticos. Segundo Dill (2002, p.12) os ambientes operacionais são usados para oferecer um desempenho satisfatório para os clientes. Podem ser identificadas facilmente as transações que são executadas neste ambiente e os horários em que a base é mais utilizada, facilitando o gerenciamento e o dimensionamento da base na sua carga. Em um ambiente analítico de DW os processos executados são mais complexos, por trabalharem com uma quantidade grande de informações. A forma de retirar informações da base de dados de um DW não é padronizada e seus horários de maior fluxo de acesso não são conhecidos, dificultando o gerenciamento e o dimensionamento da carga dos dados da base, conforme afirma Dill (2002, p.12). As principais diferenças entre os tipos de bancos de dados são apresentadas na Tabela 1. Tabela 1 Principais diferenças entre um banco de dados operacional e um DW (DILL, 2002, p.13; TIVES, 2006, p.23; LIMA, 2006, p.15). Banco de dados Operacional Banco de Dados Analítico de Data Warehouse Baseado em objetivos operacionais Operações de Consulta, Inclusão, Alteração e Exclusão são permitidos Operações acessam poucos registros Estrutura Normalizada Usuários que acessam são os operadores Baseado em registros históricos São permitidos apenas operações de Inclusão e Consulta Operações acessam muitos registros Estrutura permite redundância Usuários que acessam são os responsáveis pelas tomadas de decisões

28 28 Modelagem Relacional dos Dados Atualização realizada em tempo real Modelagem Dimensional dos Dados Atualização realizada periodicamente 2.5 On-Line Analytic Processing (OLAP) O OLAP é um conjunto de ferramentas fornece condições para acessar e explorar os dados contidos em um DW (MACHADO, 2004, p.86). Os dados adquiridos da base do DW geralmente são retirados para responder as perguntas dos gerentes, executivos e analistas. As ferramentas OLAP fornecem aplicações em que os usuários finais possam efetuar operações básicas de consultas e construir seus relatórios gerenciais. As principais ferramentas são: Drill Down, Drill Up e Drill Across (MACHADO, 2004, p. 86). Segundo Machado (2004, p.87) são operações para movimentar a visão dos dados ao longo dos níveis hierárquicos de uma dimensão ; são formas de mostrar os resultados finais para um usuário Drill Down Segundo Barbieri (2001, p. 41), Machado (2004, p. 87) e Lima (2006, p. 17) o Drill Down está diretamente ligado ao aumento do nível de detalhe da informação, buscando dados mais detalhados diminuindo a granularidade da consulta. Geralmente esse tipo de consulta é utilizado para juntar resultados de uma consulta Drill Up O Drill Up, ao contrário do Drill Down, diminui o nível de detalhe da informação, buscando dados com menos detalhes da base do DW, aumentando assim, o grau de granularidade das informações consultadas (BARBIERI, 2001, p. 41; MACHADO, 2004, p. 87; LIMA, 2006, p. 17).

29 Drill Across Conforme Machado (2004, p. 89) o conceito de Drill Across está relacionado diretamente com o fato de pular um nível intermediário dentro de uma mesma dimensão numa consulta. Como por exemplo, numa dimensão tempo do DW, em que ele possui os atributos dia, mês, ano; bimestre, semestre e ano, quando na realização de uma consulta para um relatório, faz-se uma pesquisa utilizando os dias e no mesmo relatório consulta dados do ano inteiro; essa consulta passou do nível de detalhamento máximo exemplificado pelo dia para o nível de detalhamento mínimo que seria o ano. 2.6 Data Mart (DM) O termo Data Mart significa, conforme Barbieri (2001, p. 50), um depósito de dados relacionados a um setor específico da empresa, criados para auxiliar no processo decisório dessa empresa. Assim, pode-se dizer que um DM é um DW setorial. Segue as mesmas características de um DW geral, mas tendo os seus dados voltados apenas para um setor. Portanto, um DW é formado por vários DM s. DATA WAREHOUSE Data Mart Vendas Data Mart RH Data Mart Compras Figura 5 Exemplo de DM adaptado de Machado (2004, p. 44).

30 30 A Figura 5 mostra um DW composto por 3 (três) DM setoriais, dos setores de Vendas, Recursos Humanos e Compras. Com a construção dos DM s pode-se construir um DW com uma maior facilidade. A partir de um DW também existe a possibilidade desenvolver os DM s com uma maior rapidez. Cada forma de programar depende da necessidade da empresa. Antes de ser desenvolvido um DW ou um DM, deve ser feito uma análise das necessidades da empresa, definindo a qual arquitetura e o modelo a ser utilizado na implementação do projeto. Os tipos de arquiteturas mais utilizados serão descritas na seção seguinte. 2.7 Arquiteturas de Data Warehouse Conforme os estudos de Machado (2004, p. 31) a arquitetura de um DW inclui, além de estruturas de dados, mecanismos de comunicação, processamento e apresentação da informação para o usuário. Normalmente, são utilizados conjuntos de ferramentas que auxiliam desde o processo de retirada e limpeza dos dados até o processamento dos relatórios gerados a partir de um DW. Na arquitetura do DW podem ser analisados os principais componentes, como os papéis exercidos por pessoas, as ferramentas que podem ser utilizadas, os dados e os processos que podem conter no mesmo. A figura 6 mostra um exemplo de uma arquitetura de um ambiente de DW.

31 31 Figura 6 Arquitetura de um ambiente de DW (SOARES, 1998, p. 21). A Figura 6 mostra graficamente algumas fontes de informações para carregamento de um DW. Os dados geralmente estão armazenados em bases diferentes em formatos distintos, com níveis de detalhes diferentes e sem seguirem um padrão no armazenamento dos dados, sendo necessário o uso de aplicações que executam a filtragem e integração dos dados. Para fazer a análise do que será implementado no banco do DW e quais as informações que deverão ser retiradas do mesmo, é necessário conter na equipe de desenvolvimento os profissionais que são responsáveis pelas cargas dos dados no DW, tendo o conhecimento das bases de origem e do modelo do DW. Também deve conter especialistas do domínio, gerentes, executivos que utilizarão o DW nas suas decisões e administradores da rede e banco de dados, para garantir que a comunicação do DW com suas bases de origens estejam disponíveis durante as cargas do DW. Concluindo o processo de análise, o DW é carregado, dando início ao processo de extração dos dados da base, através de ferramentas de Data Mining, implementação de aplicativos desenvolvidos pelos programadores da empresa ou através de aplicativos e ferramentas OLAP.

32 32 Com o DW carregado têm-se a possibilidade de criação de DM com uma maior facilidade, mas a criação dos DM depende das necessidades da empresa. No processo de criação dos DM o DW seria dividido por áreas gerenciais da empresa para auxiliar os setores na busca de suas prõprias informações Existem duas abordagens de implementações principais para desenvolvimento de um DW, são elas: Top Down e Bottom Up (Machado, 2004, p.47). A escolha de qual arquitetura utilizar é definida normalmente no início do projeto, mas pode ser mudada durante a análise e implementação do DW. A escolha depende do tempo disponível para o desenvolvimento do projeto, quais os retornos serão adquiridos após o término do mesmo, quanto tempo levará para o início da aquisição de conhecimento a partir do DW implementado, a satisfação dos administradores da empresa e os recursos financeiros, operacionais, computacionais, entre outros, disponíveis na empresa (Machado, 2004, p. 47). Em seguida serão apresentados os conceitos das duas arquiteturas Arquitetura Top Down Essa foi a primeira arquitetura proposta para o desenvolvimento em um ambiente de DW. Também é conhecida como arquitetura padrão. Consiste na extração dos dados do DW geral para os DM s setoriais, necessitando de que sua escolha seja definida no início do projeto e precisa ter um conhecimento da visão geral da empresa. Segundo Machado (2004, p. 52) essa arquitetura inicia o seu processo com a extração, a transformação e a integração dos dados externos ou bancos independentes, passando essas informações para um Operational Data Store (ODS). Esse processo de construção do ODS é opcional, mas a sua construção diminuiria os esforços na construção o DW final, pois todos os esforços quanto a integração dos dados seriam depositados no ODS. Finalizando a construção do ODS, passaria para a transferência das informações para o DW. A partir do DW carregado podem ser extraído os dados e metadados para os DM s. Terminando todo o processo de carregamento e preenchimento do DW e dos DM s, são utilizadas ferramentas OLAP, de Data Mining ou mesmo

33 33 aplicações desenvolvidas pelos próprios programadores componentes da equipe, para retirar as informações dos bancos para auxiliar na decisões da empresa. A figura 7 ilustra um exemplo dessa arquitetura. Figura 7 Modelo Top Down (SOARES, 1998, p. 26). Este modelo de arquitetura possui suas vantagens e desvantagens, segundo Machado (2004, p. 53), e que serão apresentadas na tabela 2: Tabela 2 Vantagens e Desvantagens de utilizar a arquitetura Top Down (MACHADO, 2004, p.53) Vantagens Desvantagens Herança da arquitetura do DW pelos DM s Visão da empresa como um todo Concentração dos dados e metadados em um único repositório e simplicidade na manutenção Implementação muito longa, por envolver todos os setores da empresa Alta taxa de riscos, por não existir garantias de resultados nesse tipo de ambiente Heranças de cruzamentos funcionais, que exige ao final do projeto profissionais altamente capacitados para garantir a manutenção do sistema

34 34 Regras de extração, limpeza e integração centralizados, facilitando a manutenção A demora na construção do DW e a falta de retorno rápido, causa ansiedade e expectativas nos usuários Essa arquitetura exige que seus programadores tenham conhecimento de todo o processo de funcionamento da empresa, tornando a sua implementação mais demorada, além de exigir que a empresa mantenha na equipe de funcionários, profissionais altamente qualificados para garantir a manutenção do DW. Mas, em contra partida, após o DW finalizado, a retirada de DM s se torna simples, pois seria apenas uma cópia do DW geral, mas sendo apenas de um departamento e facilitando a sua manutenção por se localizar fisicamente em um mesmo lugar. Com o DW mantêm-se uma visão da empresa por completo e concentra os trabalhos de atualizações apenas em um local Arquitetura Bottom Up Machado (2004, p. 54), verificou as dificuldades encontradas na implementação Top Down, em que requer um tempo maior para ser concluído, possui uma demora para apresentar resultados e o custo de construção terminava caro. Após a análise das informações citadas anteriormente, pode-se perceber que a utilização da arquitetura Bottom Up passou a ser mais usada, por ser uma arquitetura que objetiva a construção de um DW incremental, iniciando pelos DM s e evoluindo para a construção do DW. Os DM s permitem que seus planejamentos e seus desenhos possam ser feitos sem necessitar de uma visão da corporação inteira, bastando apenas conhecer o fluxo existente em uma área da empresa, implementando DW incremental. Segundo Machado (2004, p. 54) essa arquitetura inicia o seu processo com a extração, a transformação e a integração dos dados externos ou bancos independentes, passando essas informações para um ou mais DM s. Finalizando a construção dos DM s, passaria para a transferência das informações para um DW geral.

35 35 A partir dos DM s carregados podem ser extraídos os dados e metadados para o DW. Terminando todo o processo de carregamento e preenchimento dos DM s e do DW, são utilizadas ferramentas para retirar as informações dos bancos para auxiliar nas decisões da empresa. A figura 8 ilustra um exemplo dessa arquitetura. Figura 8 Exemplo da Arquitetura Bottom Up (SOARES, 1998, p. 28). Este modelo de arquitetura possui algumas vantagens e desvantagens, segundo Machado (2004, p. 55), sendo apresentadas algumas na tabela 3: Tabela 3 Vantagens e Desvantagens de utilizar a arquitetura Bottom Up (MACHADO, 2004, p.53) Vantagens Desvantagens Implementação direcionada, permitindo um desenvolvimento rápido Fornece um retorno rápido para o usuário, por ser desenvolvida mais rápido Perigo dos DM s se tornarem DM s independentes, que dificultam e as vezes inviabilizam a integração com o DW geral Desafio de possuir e manter uma visão do negócio como um todo. Esse controle dificulta a extração e combinação das fontes que serão utilizadas no DW.

36 36 Manutenção do enfoque da empresa, fazendo com que toda a atenção dos desenvolvedores fique em uma determinada área de empresa. Herança das informações pelo DW de forma incremental, reduzindo os riscos no projeto Dificulta a administração das equipes de desenvolvimento, que normalmente são divididas para desenvolver DM s em paralelo. A maldição do sucesso começa a perseguir os desenvolvedores do projeto. Enquanto uns usuários ficam felizes com seu DM atualizado, outros ficam aguardando que o seu DM seja atualizado, fazendo com que seus desenvolvedores tenham que administrar políticas de atualizações e de recursos. A utilização dessa arquitetura necessita que os analistas passem a conhecer as áreas da empresa de forma incremental. As duas abordagens têm boas características, mas a escolha de uma delas depende do que as empresas estão necessitando, por isso os modelos da arquitetura devem ser definidos no início do projeto. A seguir serão mostrados alguns conceitos sobre a modelagem dimensional de um DW. 2.8 Modelagem Dimensional Através da modelagem dimensional ou multidimensional é possível observar o banco de dados de vários ângulos, usando a abordagem no formato de um cubo, que pode conter duas, três ou quantas dimensões for possível. Nos ambientes operacionais construídos atualmente, a técnica de modelagem Entidade Relacionamento (ER) tem sido a mais utilizada nos desenvolvimentos dos projetos. Conforme Dill (2002, p. 28), com o surgimento dos sistemas e processos de DW necessitou-se de uma nova técnica de modelagem que se adequasse melhor à forma de implementação do novo ambiente.

37 37 A modelagem dimensional, segundo Machado (2004, p. 79), é mais simples de ser modelada, mais expressiva e facilita o entendimento, mas por ser uma modelagem nova, ainda não possui técnicas detalhadas de desenvolvimento firmes como já tem o modelo ER. Ainda conforme Dill (2002, p. 30), a modelagem dimensional é uma técnica para conceitualização e visualização de um conjunto de medidas existentes num negócio. É muito útil na construção de dados sumarizados e reorganização das informações, como é o caso dos DW s. Apesar dessa forma de modelagem ser nova, é muito utilizada na modelagem de dados para construção de DW s, por facilitar a organização e visualização das informações que irão conter no mesmo. Essa fase do processo é de extrema importância, pois segundo Soares (1998, p. 44), pode definir o sucesso ou o fracasso no desenvolvimento de um DW, pois sendo bem feita trará os resultados desejados, mas se for mal elaborado o modelo não trará resultados satisfatórios. O modelo dimensional é formado por 2 (dois) elementos básicos (MACHADO, 2004, p. 79): Tabelas de Fatos; Tabelas de Dimensões Tabelas de Fatos A tabela de fatos, conforme os estudos de Soares (1998, p. 55) representam as informações que serão analisadas, sendo formada normalmente por valores numéricos que representam dados de medidas. Mas nem sempre essas tabelas possuem totais ou valores numéricos, passando a ser considerada uma tabela que fará o mapeamento dos eventos ocorridos. Soares (1998, p. 56) afirma que a tabela de fatos geralmente possui uma grande quantidade de informações. Segundo Machado (2004, p. 79) cada fato representa um item, uma transação ou um evento do negócio. Esses dados mostram os acontecimentos diários de uma empresa, o que auxiliará no processo de análise da empresa.

38 38 A tabela de fatos é formada normalmente por uma chave primária composta pelas chaves primárias das tabelas dimensões Tabelas de Dimensões Segundo Machado (2004, p. 80) as tabelas de dimensões são os elementos que fazem parte da tabela de fato. Essas tabelas armazenam os dados das dimensões da empresa e normalmente são menores do que a tabela de fatos e não possuem atributos numéricos de somatórios. As tabelas de dimensões podem ser utilizadas por mais de uma tabela de fato, pois descrevem e classificam seus elementos, podendo estar inseridas em mais de um assunto no DW. Conforme Dill (2002, p.32) uma das principais funções da criação de uma tabela de dimensões é de servir como fonte de informações para uma consulta efetuada no DW ou como cabeçalhos de linha nas respostas oferecidas aos usuários finais. A seguir serão definidos os modelos dimensionais que podem ser utilizados para implementar a arquitetura física de um DW Modelo Estrela (Star Schema) O modelo estrela é o mais utilizado na modelagem de DW por sua rapidez nas consultas. Esse modelo é composto por uma entidade central chamada de fato e um conjunto de entidades menores ligadas a ela, chamadas de dimensões (MACHADO, 2004, p. 93). A figura 9 mostra um modelo de representação do modelo estrela.

39 39 Dimensão Marketing Dimensão Cliente Dimensão Produto Fato Vendas Dimensão Loja Dimensão Tempo Dimensão Promoção Figura 9 Exemplo do modelo estrela adaptado de Moreira (2006). Segundo Singh (2001, p. 159) uma característica importante desse modelo é fato de suas dimensões serem desnormalizadas. A desnormalização é o fato de ter dados sendo repetidos na base de dados, para conferir simplicidade e desempenho nas consultas. Portanto, dados podem ser repetidos em dimensões, para garantir um maior desempenho. O modelo estrela oferece algumas vantagens importantes, segundo Singh (2001, p. 159): permite criar uma estrutura multidimensional complexa com um modelo de dados simples; facilita a definição de relacionamentos hierárquicos dentro de cada dimensão e facilita as consultas entre muitas tabelas; reduz a quantidade de consultas feitas entre tabelas fisicamente, melhorando o desempenho; ao simplificar a visualização do modelo de dados, diminui a chance de os usuários fazerem consultas erradas que consomem a máquina e trazem resultados duvidosos; permite a expansão e a evolução do DW com pouca manutenção.

40 40 A simplicidade de entendimento dos dados mostrados a partir desse modelo e fácil manutenção do banco de dados influenciam em muitos aspectos na análise e escolha do modelo que uma empresa irá utilizar Modelo Floco de Neve (Snowflake) Segundo Machado (2004, p. 95) o modelo floco de neve é o resultado da decomposição de uma ou mais dimensões que possuem hierarquias entre seus membros. Conforme Sing (2001, p. 160) normalizando os dados das tabelas dimensionais de um modelo estrela transforma o mesmo em um modelo floco de neve ilustrado na figura 10. Dimensão Promoção Dimensão Loja Meio Fato Vendas Dimensão Tempo Dimensão Produto Marca Categoria Ano Mês Dia Departamento Figura 10 Exemplo do modelo floco de neve adaptado de Moreira (2006). Através desse modelo podem ser definidos relacionamentos entre tabelas de dimensões, o que não pode ocorrer no modelo estrela, o que torna esse

41 41 modelo de fácil entendimento por estar normalizado, mas torna difícil adquirir informações da sua base de dados. Esse modelo possui algumas desvantagens em relação ao modelo estrela, segundo Sing (2001, p. 161): a estrutura dos dados normalizada acaba se tornando mais complexa; a navegação executada sobre o modelo, se torna mais difícil, por ter que passar por muitas tabelas para chegar ao resultado; a carga e a manutenção dos dados no DW, acaba sendo mais difícil de ser executado e dificulta a administração desse processo. O modelo floco de neve é visualmente mais fácil de identificar as hierarquias, mas a perda de performance por causa do aumento das tabelas torna-o mais inviável do que o modelo estrela. Mas, existem casos em que a identificação dessas hierarquias se faz necessária, dependendo apenas do domínio em que está sendo aplicado. 2.9 Projeto para construção de um Data Warehouse Conforme Mata (2005, p. 25) a utilização das tecnologias de BI têm como principal objetivo melhorar todos os produtos e serviços oferecidos pelas empresas, visando obter uma maior satisfação do usuário final e dos profissionais envolvidos no processo de desenvolvimento do projeto. Para se construir um DW ou DM que são tecnologias de BI, devem ser seguidos alguns aspectos. Nesse trabalho será exemplificado o processo de criação proposto por Barbieri (2001, p. 68). Os passos para execução do projeto de construção de um DW consistem em: planejamento de um Data Warehouse; levantamento das necessidades da empresa; modelagem dimensional; projeto físico do banco de dados; projeto de ETC; desenvolvimento das aplicações;

42 42 validação e testes. Nas seções seguintes serão explicadas cada fase do planejamento para construção de um DW Planejamento de um Data Warehouse Esta é a primeira etapa para a construção de um DW, no qual é definido o escopo do projeto que deverá atender as necessidades gerenciais da empresa. Essa etapa pode ser definida em 4 (quatro) etapas básicas, segundo Barbieri (2001, p ), são elas: definição do foco do negócio; definição da abordagem do sistema; planejamento para a integração dos dados; definição da arquitetura tecnológica Definição do foco do negócio É a fase de identificação do escopo da empresa, tendo por base os levantamentos feitos pela gerência da empresa, que visam tornar a empresa mais forte e competitiva (BARBIERI, 2001, p. 69). Portanto, a definição do foco do negocio é uma das principais etapas, pois é a partir dela que se obtém uma visão das áreas de atuação da empresa e busca focalizar os assuntos que serão implementados no DW Definição da abordagem do sistema Nessa fase são definidos quais os assuntos que serão abordados no projeto para a construção do DW. E consiste na escolha de qual a forma de implementação será utilizada. Define-se se será criado primeiro o DW e depois os DM s, ou se serão criados primeiros os DM s e depois gradativamente será construído o DW (BARBIERI, 2001, p. 70).

43 43 Como por exemplo, em um supermercado, podem ser abordadas as áreas de compras, venda, recursos humanos, logística, marketing entre outras. Com isso pode-se escolher a forma de implementação que será utilizada no desenvolvimento do DW Planejamento para a integração dos dados Após a definição dos assuntos que serão implementados, parte-se para a identificação das principais dimensões, o que cada dimensão significa, quais os dados que deverão conter cada uma delas e as suas hierarquias. Essa tarefa pode trazer um pouco de dificuldades na sua análise, mas auxiliará na definição geral do DW, identificar as dimensões e seus dados permitirá a integração dos DM s com uma maior facilidade na montagem do DW (BARBIERI, 2001, p. 70) Definição da arquitetura tecnológica A identificação da arquitetura tecnológica será a base para o projeto, por esse motivo devem ser definidos os componentes básicos, pois fatores como desempenho e disponibilidade, podem diferenciar em algumas análises do projeto. Alguns componentes necessários para a análise nessa fase, segundo Barbieri (2001, p ), são: sistema de Gerenciador de Bancos de Dados (SGBD): é onde deverá ser armazenado o DW, normalmente é utilizado uma máquina mais potente que suporte bastante processamento, tendo uma boa disponibilidade, uma boa performance nas consultas e em muitos casos, possua um nível de segurança mais alto; ferramentas de Desenvolvimento de Sistemas OLAP e de Data Mining: é a definição das ferramentas utilizadas para o desenvolvimento de aplicações OLAP e de aplicações utilizando Data Mining. ferramentas de Extração, Transformação e Carga (ETC): é a definição do conjunto de ferramentas que serão utilizadas no processo de ETC. A

44 44 escolha de ferramentas que garantam a integridade dos dados que irão para o DW é muito importante, para evitar problemas durante o carregamento dos dados p o DW. catálogo para o controle de Metadados: é uma ferramenta desenvolvida pelos próprios programadores do projeto ou mesmo comprada, com o objetivo de identificar quais as informações que irão conter em todo o projeto. mecanismos para transferência de dados entre ambientes diferentes: são ferramentas variadas que permitem a transferência entre ambientes heterogêneos. Essas ferramentas podem ser OLE/DB, ODBC, Gatewayes procedurais ou transparente, ou qualquer outro tipo de mecanismo. servidor de Data Mart: similar ao utilizado para o DW, para ser utilizado para aplicações específicas menores. extratos de Dados para o Data Mining: é a forma de armazenar informações que podem trazer informações especiais do DW, que são transformadas em conhecimento Levantamento das necessidades da Empresa Nessa etapa devem ser analisados dois modelos: modelo dimensional e modelo fonte de dados. O primeiro modelo representa os dados necessários para ter no final do projeto um sistema que dê suporte nas decisões da empresa, devendo-se fazer uma análise detalhada desses dados. O segundo modelo representa os dados das bases de originais e/ou as fontes externas de informações, sendo guardadas as suas descrições, formas de armazenamento e de uso desses dados. O modelo de fonte de dados será a base para a construção do modelo dimensional (BARBIERI, 2001, p. 73) Modelagem Dimensional A modelagem dimensional é uma fase crítica para o projeto, podendo causar o fracasso do projeto se feito de forma errada. Os dados devem ser analisados de forma diferente da modelagem relacional, em que os dados serão

45 45 armazenados de forma compacta, dependendo do grau de granularidade escolhido no projeto (BARBIERI, 2001, p. 74) Projeto físico do banco de dados Nessa etapa deverá ser criado o banco de dados do DW no SGBD escolhido. Criando as tabelas de dimensões e fatos como seus atributos, assim como fazendo suas indexações, relacionamentos e implantações das regras (BARBIERI, 2001, p. 74). Com a conclusão desta etapa, têm-se o banco de dados com todas as suas tabelas de fatos e dimensões criadas e com as ligações entre as chaves primárias e estrangeiras Projeto de ETL (Extract, Transform and Load) Nesta etapa deve ser feita a transferência das informações das fontes de dados originais para o banco de dados do DW. Essa fase é subdividida em 5 etapas, conforme Barbieri (2001, p. 75), que serão descritas a seguir Filtro de Dados Esse processo é utilizado para evitar que dados indesejados sejam carregados para o DW. Um exemplo seria no caso de uma consulta em que se necessita somente de informações das vendas efetuadas no valor acima de R$ 100,00. Somente serão selecionadas, na base de origem as informações que se encaixam na condição citada Integração de Dados Esse processo define a forma que deve ser feita a padronização de dados que são correlacionados, mas que são guardados de formas diferentes em bases diferentes, ou mesmo em fontes diferentes. É de essencial importância que essa integração ou padronização seja feita antes de ser carregada as informações para

46 46 o DW. Um exemplo seria o sexo de uma pessoa, em que numa base ele é guardado como sendo F ou M e em outra base é guardada como sendo 0 ou 1. Antes de transferir essas informações para o DW, essas informações devem ser padronizadas Condensação de Dados É a forma de reduzir a quantidade de registros que serão guardadas no DW. Esse processo será utilizado dependendo do tipo de granularidade escolhida para a construção do DW. Um exemplo seria colocar as informações no DW por trimestre ou por ano. Assim, reduziria a quantidade de registros a serem guardados, mas também impossibilitaria uma pesquisa que necessitasse de mais detalhes Conversão de Dados É a definição das formas em que serão transformados os dados de unidades, formatos ou dimensões diferentes. Um exemplo seria quando em uma base original os produtos são cadastrados como caixa e no DW eles devem ser cadastrados como unidade Derivação de Dados É a utilização de fórmulas para adquirir dados virtuais, a partir de dados existentes nas bases de origem. Sendo utilizada para diminuir os processamentos em tempo de execução de uma consulta no DW. Um exemplo seria acrescentar um campo para o somatório de todas as vendas de um mês numa tabela de fatos do DW Desenvolvimento de aplicações Nessa etapa devem ser construídas aplicações que busquem as informações na base de dados do DW, para mostrar as consultas ao usuário final.

47 47 Essas ferramentas podem ser desenvolvidas tanto para desktop quanto para a Web. Dependendo das necessidades e condições da empresa, podem ser utilizadas ferramentas de Data Mining, que irão proporcionar informações de busca de padrões. Cada empresa define a melhor forma de disponibilizar essas informações para os usuários do sistema, mas a forma mais usada atualmente é a internet, por trazer uma comodidade maior para as empresas. As preocupações com a interface do sistema devem ser mantidas em todo o processo de desenvolvimento do mesmo, para evitar telas muito carregada de informações e relatórios sem sentido Validação e testes Nessa fase o sistema deve ser testado de várias formas, considerando as consultas que mais exigem processamento e trabalhando com um volume maior de informações. Após os testes realizados, o sistema deve ser liberado para algumas pessoas usarem e verificarem se possui alguma falha ou não, como por exemplo, se está faltando alguma informação ou se tem alguma consulta retornando resultados errados. Após a conclusão dessa fase o sistema pode ser liberado para todos os usuários e deverá ser ministrado um treinamento de como utilizar o sistema. Assim, pode ser considerado que o desenvolvimento do sistema de DW foi concluído, restando somente a fase de manutenção do sistema ou de atualização, dependendo das necessidades da empresa.

48 48 3. MATERIAIS E MÉTODOS Nesta seção serão descritos os materiais e os métodos utilizados para o desenvolvimento deste trabalho. 3.1 Local e Período Este trabalho foi desenvolvido utilizando o meu computador pessoal, o computador pessoal do Robson e um notebook. O desenvolvimento desse trabalho iniciou em Agosto de 2006 e finalizou em novembro de Material O material utilizado para o desenvolvimento deste trabalho pode ser dividido em: Fontes bibliográficas, Hardwares e Softwares Fontes bibliográficas Utilizaram-se livros emprestados pela Biblioteca do Centro Universitário Luterano de Palmas (CEULP / ULBRA), livros emprestados por Professores do Curso de Sistemas de Informação do CEULP / ULBRA, livros pessoais, monografias emprestadas pela Coordenação do Curso de Sistemas de Informação, matérias e artigos encontrados na Internet Hardwares

49 49 Foram utilizados os computadores pessoais da minha casa, da casa do Robson e um notebook emprestado pela Sra. Leila Ramos. As configurações dos computadores são: Pessoal microcomputador com processador Pentium IV com clock de 1,4GHz, com 512Mb de memória RAM e três HD s, dois de 40Gb e outro de 160Gb. Robson microcomputador com processador Pentium IV com clock de 2,4GHz, com 448Mb de memória RAM e dois HD s, um de 80Gb e outro de 40Gb. Leila Ramos notebook com processador Celeron M com clock de 1,8 GHz, com 256Mb de memória RAM e HD com capacidade de 40Gb Softwares Foram utilizados neste trabalho os softwares descritos a seguir: Sistemas Operacionais Microsoft Windows XP Professional e Windows XP Home Edition, como base para utilização dos computadores; Microsoft Office Word 2003, utilizado para visualização de material de referência bibliográfica e para a elaboração do trabalho final de conclusão de curso; Notepad, utilizado para visualização rápida de códigos fontes escritos gerados pelo software DBDesigner e alteração dos mesmos. E foi utilizado para manter as páginas da Web que foram acessadas durante as pesquisas efetuadas na internet; Adobe Acrobat Reader 5.0, utilizado para visualização de material de referência bibliográfica; Microsoft Office Excel 2003, utilizado para realização de limpeza dos dados no processo de ETL do DW;

50 50 Microsoft SQL Server 2005, utilizado para armazenar a base de dados do Hemovida e para armazenar a base de dados criada para o Data Warehouse; Microsoft Internet Explorer 6.0, utilizado para realizar pesquisas na internet de material de referência bibliográfica; CorelDraw 12, utilizado para criação e editoração de imagens utilizadas nesse trabalho; Paint, utilizado para editar imagens utilizadas no trabalho; DBDesigner, utilizado inicialmente para criar o modelo dimensional do DW, e para gerar automaticamente o código fonte para criação da base de dados no SQL Server 2005; Crystal Reports XI free trial, utilizado para criação dos relatórios utilizando a base de dados do DW; DTS do SQL Server 2005, utilizado para fazer a importação dos dados da base original do Hemovida e dos arquivos do Excel para o DW; Microsoft Power Point, utilizado para visualização de material de referência bibliográfica e na construção da apresentação final desse trabalho; Winrar, utilizado para compactar e descompactar arquivos utilizados em todas as fases do projeto. 3.3 Métodos Para atingir os objetivos traçados para o desenvolvimento desse trabalho, foi necessário adquirir conhecimento sobre a tecnologia de Data Warehouse, realizando pesquisar e fazendo um levantamento bibliográfico sobre o assunto. Essa pesquisa teve por objetivo identificar as características, a estrutura, os componentes, as técnicas e analisar os conceitos da tecnologia de DW, possibilitando a partir da conclusão da pesquisa, desenvolver um projeto de construção de um DW geral para uma empresa. A empresa escolhida para ser construído o DW, foi o Hemocentro Coordenador de Palmas, por ser uma empresa pública que necessita de informações constantes de análise, e por possuir um conhecimento prévio da

51 51 base utilizada na empresa, para a modelagem e construção do DW foi utilizado a proposta do Barbieri (2001, p.68). Foi realizado um estudo da base de dados do Hemovida e definidas as informações que tinham mais relevância para o processo de análise no Hemoto. A partir dessa análise, foi definido o modelo dimensional do DW e o modelo físico do mesmo. Com isso, passou-se para o processo de extração, transformação e integração dos dados para ser carregado a base de dados do banco do DW. Com o DW carregado, foram realizadas algumas consultas utilizando a base, podendo assim, concluir o trabalho de implementação do DW e passando para a análise de alguns resultados obtidos da base do DW. Os passos seguidos para a realização deste trabalho serão mostrados na próxima seção.

52 52 4. RESULTADOS E DISCUSSÕES Esta seção tem por objetivo descrever os passos executados durante a implementação do Data Warehouse que foi desenvolvido para o Hemocentro Coordenador de Palmas. A figura 11 mostra as etapas básicas desenvolvidas durante o processo. BD do Hemovida Data Warehouse Modelagem DBDesigner 4 Processo ETL SQL Server Figura 11 Etapas básicas da construção do DW do Hemocentro. A figura 11 mostra apenas as etapas básicas desenvolvidas durante esse projeto, a seguir, serão descritas todas as etapas efetuadas, iniciando da análise do projeto e finalizando nos relatórios obtidos nas consultas ao DW desenvolvido. 4.1 Projeto para construção de um Data Warehouse para o Hemocentro

53 53 Coordenador de Palmas (HEMOTO) Para se construir o DW para o Hemoto, foi utilizado o processo de criação proposto por Barbieri (2001, p. 68). Os passos para execução desse projeto constituem-se em: planejar um Data Warehouse; levantar as necessidades da empresa; modelar o modelo dimensional; projetar o projeto físico do banco de dados; projetar o projeto de ETC; desenvolver aplicações; validar e testar. A seguir será explicada cada fase do processo de desenvolvimento do DW proposto para o Hemocentro Coordenador de Palmas Planejamento do Data Warehouse Essa foi a primeira etapa a ser definida durante o projeto, sendo que a mesma é subdividida em 4 (quatro) etapas, descritas a seguir Definição do foco do negócio O Hemocentro tem por objetivo e meta coletar e fornecer sangue com qualidade para todos os locais que necessitem do serviço, por ser a única Instituição Pública no Estado que disponibiliza a coleta de sangue e distribuição do mesmo. Os Hemocentros passam por muitas dificuldades para conseguir atrair a atenção dos doadores para a necessidade do ato da doação. O maior problema encontrado no Hemocentro é a dificuldade em esclarecer a população da importância da doação de sangue. A falta de informações estatísticas que forneçam dados que facilitem a programação de palestras que são ministradas dificulta a fase de captação de doadores. Com a

54 54 criação do DW, passa-se a oferecer dados do perfil dos doadores que pode auxiliar a focar e planejar melhor as formas de trabalhar as informações que serão passadas para os futuros doadores Definição da abordagem do sistema O sistema de DW que foi desenvolvido buscou abordar todo o ciclo do sangue dentro do Hemocentro. Esse ciclo envolve desde a recepção do doador no Hemocentro até a saída dos hemocomponentes retirados do sangue, para as Agências Transfusionais, como ilustra a figura 12. RECEPÇÃO PRÉ TRIAGEM TRIAGEM CLÍNICA TRIAGEM HEMATOLÓGICA COLETA EXPURGO FRACIONAMENTO SOROLOGIA IMUNOHEMATOLOGIA ESTOQUE DISTRIBUIÇÃO AGÊNCIAS E HOSPITAIS Figura 12 Fluxo das informações do ciclo do sangue. A Figura 12 mostra o fluxo completo do sangue dentro do Hemocentro Coordenador de Palmas. Para controlar esse fluxo é utilizado o Sistema de Gerenciamento em Serviços de Hemoterapia (Sistema Hemovida). Esse programa foi desenvolvido pelo DATASUS para informatizar a Rede Hemoterápica do País.

55 55 O Hemovida é um sistema que gerencia todo o fluxo do sangue dentro de um Hemocentro. Têm a modularidade como uma de suas principais características, sendo constituído por subsistemas que cobrem as funcionalidades dos diversos setores de uma Unidade Hemoterápica. Esta abordagem permite que ele seja instalado tanto em uma unidade de pequeno porte como em uma de grande porte, de acordo com os setores que cada unidade possuir. A Figura 12 apresenta, em cada retângulo, o nome dos setores principais do Hemocentro que fazem parte do ciclo do sangue, em que o primeiro a ser acessado é a recepção do doador, no qual é feito o cadastro do candidato à doação mediante um documento de identidade com fotografia. Neste setor, também é realizado o cadastro de receptor, o cadastro para realização de 2ª amostra (no caso de exames inconclusivos), o encaminhamento para atendimento a resultados soro reagentes e entrega de atestados de comparecimento (quando o candidato foi inapto à doação). O próximo setor é o de pré-triagem, em que o candidato à doação recebe a verificação de pressão arterial, pulso, peso e altura. Neste setor são confeccionadas as carteirinhas de doadores, assim como sua atualização. Em seguida, no setor de triagem clínica, é realizado um questionário complexo sobre a saúde e comportamentos de risco do candidato à doação, que deve ser respondido claramente e francamente. Neste setor poderão ser excluídos candidatos temporariamente ou definitivamente, dependendo da avaliação realizada pelo triagista e embasado na resolução RDC nº 343 de 13 de dezembro de 2002, DOU de 17/01/2003, da Agencia Nacional de Vigilância Sanitária. No próximo setor, o da triagem hematológica, é realizado um exame para exclusão de candidatos que apresentarem níveis de hematócrito fora do padronizado pela resolução RDC nº 343. Neste exame é identificado se o doador pode ou não estar com anemia. Sendo impresso o número do código de barras que é gerado exclusivamente para cada doador. O setor seguinte é o da coleta, em que o doador efetuada a doação de sangue, que poderá durar de 5 a 15 minutos, sendo cadastradas os dados da bolsa de sangue total no sistema. O doador doa uma bolsa de sangue total com aproximadamente 462ml e é retirado em um tubo de ensaio 5ml e em outro 10ml

56 56 de sangue para serem feitos os exames necessários nos setores de imunohematologia e de sorologia. Assim, termina o ciclo da doação de sangue para um doador. A bolsa de sangue total é enviada para o setor de fracionamento, o tubo de ensaio com 5ml de sangue vai para o setor de imunohematologia e o tubo de ensaio com 10ml segue para o setor de sorologia. No setor de fracionamento, a bolsa de sangue total passa por alguns processos de centrifugação para a produção dos hemocomponentes, que são armazenados conforme exigências feitas pela RDC e ficam aguardando os resultados dos exames sorológicos realizados pelos setores de sorologia e imunohematologia. Após a liberação dos resultados dos dois setores no sistema, sendo todos negativos, as bolsas são rotuladas e passam para o setor de estoque, em que são armazenadas. A partir daí fica-se aguardando solicitações de requisições de sangue dos hospitais ou agências transfusionais, para que sejam distribuídas. Quando solicitadas, passam para o setor de distribuição, para que sejam enviadas para os locais solicitantes. O setor de Distribuição realiza a distribuição dos hemocomponentes para as Agências Transfusionais, Postos de Coleta e até Hemocentros Regionais ligados ao Hemocentro Coordenador que solicitarem sangue. Se houver algum problema com alguma bolsa durante a produção dos hemocomponentes, ou mesmo quando os exames efetuados da mesma apresentam alguma alteração, a bolsa é enviada para o expurgo, onde passa pelo processo de auto clavagem e são enviadas para o aterro sanitário do município. No setor de imunohematologia são realizados os exames de tipagem ABO/Rh do doador, além dos exames de verificação de presença de traço falciforme e de pesquisa dos anticorpos irregulares no sangue. Estando todos os exames prontos, os mesmos são divulgados para o doador, utilizando para isso, o código de barras que é pregado no tubo de ensaio no setor de triagem hematológica, sendo divulgado no sistema Hemovida. No setor de Sorologia são realizados todos os exames sorológicos para identificação de doenças transmissíveis pelo sangue. No Hemocentro do Tocantins são feitos os exames para Chagas, Malária, Sífilis, HIV, HTLV, Hepatite B e Hepatite C. Se todos os resultados da amostra forem negativos, o resultado é divulgado para o doador e a bolsa é liberada também, mas se algum exame der

57 57 alguma alteração, esse exame será repetido. Confirmando a alteração esse resultado é cadastrado no sistema, onde a bolsa com o código de barras da amostra será enviada para o expurgo e o resultado é divulgado para o doador. E este doador será informado dessa alteração para que compareça ao hemocentro para repetir o exame. Vale ressaltar que durante todo o processo de doação do sangue até a coleta, o nome do doador é a forma de identificação do mesmo. A partir do momento em que as bolsas e os tubos passam para os laboratórios, a única informação que os funcionários possuem que faz uma ligação com o doador é o código de barras que foi gerado no Setor de Triagem Hematológica. Isso ocorre para garantir o sigilo e o anonimato dos resultados do doador. E esse anonimato um DW pode quebrar, caso não seja feito o controle das informações que são requisitadas pelo cliente. Com a análise realizada em todo o sistema, optou-se por construir um DW que englobasse toda a Instituição. O conhecimento necessário da base de dados e do fluxo das informações no Hemocentro foi adquirido e assim foi possível utilizar essa abordagem de implementação de arquitetura. A arquitetura Top Down foi escolhida por proporcionar uma visão geral da empresa e por centralizar as informações em apenas um local facilitando sua manutenção e evitando erros. Apesar de ser uma implementação mais demorada, as suas vantagens são mais atrativas para a empresa Planejamento para a integração dos dados Para se iniciar o processo de modelagem dimensional do DW, primeiro foram analisados os dois modelos de implementação. O modelo estrela ou star schema foi escolhido por tornar a consulta mais rápida e eficaz. Para se obter uma visualização das dimensões que serão criadas no DW, fez-se necessária uma análise de diversos ângulos do Sistema Gerencial. Para isso foram examinados os dados do ciclo do sangue no Hemocentro Coordenador de Palmas e a base de dados do Hemovida. A base de dados do Hemovida possui atualmente um total de 141 tabelas. A sua modelagem foi desenvolvida de forma que não foi possível gerar um

58 58 modelo Entidade Relacionamento (ER) a partir do próprio banco, pois não foram identificadas as ligações entre as chaves estrangeiras nas tabelas e suas respectivas chaves primárias nas tabelas de origem das informações. Mesmo com o problema da geração do modelo ER, a base foi analisada e a análise do DW pôde ser realizada sem muitos problemas. Na modelagem dimensional do DW foram identificadas 6 tabelas de fatos e 15 tabelas de dimensões. As tabelas de fatos definidas foram: F_Atendimento, F_Triagem, F_Coleta, F_Processamento, F_Sorologia, F_Imunohematologia. As tabelas de dimensões que foram identificadas são: D_Doador, D_Suspenso, D_Local_Coleta, D_Data, D_Pre_Triagem, D_Tipagem_ABO, D_Bolsa, D_Doacao, D_Pendencia, D_Bloqueio, D_Repeticao, D_Distribuicao, D_Expurgo, D_Fracionamento, D_Exame_Imunohemato. O modelo dimensional do DW foi criado inicialmente na ferramenta DBDesigner 4 e através dela foi gerado um código para a criação do modelo físico do DW no SQL. Esse código será mostrado e analisado detalhadamente na seção Nas subseções seguintes serão apresentadas todas as tabelas relacionadas a este DW, as ligações entre as tabelas de fatos e as tabelas de dimensões Tabela de Fato: F_Atendimento Essa tabela de fato possui os dados referentes ao atendimento prestado ao doador no hemocentro. Com isso a mesma possui em seus atributos a referência de todas as dimensões relacionadas a ela, que são: D_Doador, D_Local_Coleta, D_Data, D_Suspenso, D_Tipagem_ABO. Esta tabela foi chamada de F_Atendimento e seus atributos estão representados abaixo. Tabela 4 Representação dos atributos da tabela F_Atendimento. F_Atendimento

59 59 Atributos Seq_D_Doador Seq_D_Local_Coleta Seq_D_Data Seq_D_Suspenso Seq_D_Tipagem_ABO Tipo_doacao Descrição Chave estrangeira da dimensão doador Chave estrangeira da dimensão local da coleta Chave estrangeira da dimensão data Chave estrangeira da dimensão suspenso Chave estrangeira da dimensão do tipo de sangue Indica se a doação foi voluntária, reposição, autóloga, convocado, dirigido ou campanha Tabela de Dimensão: D_Doador A tabela D_Doador, possui todos os dados para identificar um determinado doador. A tabela 5 mostra os seus atributos. Tabela 5 Representação dos atributos da tabela D_Doador. D_Doador Atributos Seq_D_Doador Cod_doador Dat_nascimento Cor Sexo Naturalidade Municipio Estado_civil Bairro Escolaridade Descrição Chave primária da tabela Identificador dos doadores Identifica a data de nascimento do doador Identifica a cor do doador Indica o sexo do doador Identifica a cidade em que o doador nasceu Identifica a cidade onde o doador reside Indica o estado civil do doador Identifica o bairro da cidade onde o doador reside Indica qual o grau de escolaridade do doador

60 60 A tabela 5, D_Doador, possui os dados que identificam um determinado doador. Nesta tabela é possível identificar a cor, sexo, naturalidade entre outras características do doador Tabela de Dimensão: D_Local_Coleta Essa dimensão está relacionada com o local da coleta de sangue. A tabela D_Local_Coleta armazena todos o municípios em que são oferecidos o serviço de coleta de sangue. A mesma pode ser conferida na tabela seguinte. Tabela 6 Representação dos atributos da tabela D_Local_Coleta. D_Local_Coleta Atributos Seq_D_Local_Coleta Nome Municipio Descrição Chave primária da tabela Identifica o nome do local da coleta Refere-se ao município responsável por uma determinada coleta Tabela de Dimensão: D_Data A tabela D_Data no DW contém todas as datas existentes num período de tempo, que foi definido pelo desenvolvedor do DW e está dividido por dia, mês, ano e data completa. Foi utilizado o período de tempo entre 01/01/1980 e 31/12/2030, pois as doações que estão cadastradas na base de dados só tiveram início no ano de 1999, mas a aplicação necessita de uma margem de tempo maior, pois se precisar cadastrar algum dado antes dessa data, o sistema deve fornecer o suporte para o mesmo. Quanto ao ano de 2030, este pode e deve ser aumentado de acordo com a necessidade da organização. Esta tabela se chama D_Data e está representada a seguir.

61 61 Tabela 7 Representação dos atributos da tabela D_Data. D_Data Atributos Seq_D_Data Dia Mes Ano Data Descrição Chave primária da tabela Identifica um determinado dia Identifica um determinado mês Identifica um determinado ano Refere-se a uma data completa Tabela de Dimensão: D_Suspenso Essa tabela armazena os dados referentes ao tempo em que o doador ficará inapto para doação, identificado pelo responsável da triagem ou por intervalo de tempo, sendo possível identificar se o doador pode iniciar o processo de doação de sangue. A tabela 8 representa os atributos desta tabela. Tabela 8 Representação dos atributos da tabela D_Suspenso. D_Suspenso Atributos Seq_D_Suspenso Cod_doador Tipo Motivo Num_dias Tipo_inaptidao Descrição Chave primária da tabela Identificador dos doadores Identifica se o doador ficou suspenso por intercorrência ou por doação Identifica o motivo da suspensão Refere-se ao número de dias que o doador ficará suspenso Identifica o tipo da suspensão, se é definitivo ou temporário

62 Tabela de Dimensão: D_Tipagem_ABO Nesta tabela estão contidas todas as informações referentes à tipagem sangüínea do doador. Também é possível identificar nesta dimensão o fator Rh dos sangues existentes. Seus atributos estão representados na tabela 6. Tabela 9 Representação dos atributos da tabela D_Tipagem_ABO. D_Tipagem_ABO Atributos Seq_D_Tipagem_ABO Grupo_ABO Rh Descrição Chave primária da tabela Indica as tipagens sangüíneas utilizadas no hemocentro Identifica se o fator Rh do doador é positivo ou negativo Tabela de Fatos: F_Triagem A tabela F_Triagem está ligada às seguintes dimensões: Dimensao_Doador, Dimensao_Tempo, Dimensao_Suspenso e apenas uma das dimensões diferencia-se das dimensões citadas anteriormente, a Dimensao_Pre_Triagem. A seguir serão mostradas os atributos das tabelas F_Triagem e da D_Pre_Triagem. A tabela de fato F_Triagem contém os relacionamentos com as dimensões indicadas anteriormente, e a mesma possui informações importantes referente à triagem feita no Hemocentro identificando se o doador foi liberado para a doação ou não. Abaixo estão os atributos contidos nesta tabela. Tabela 10 Representação dos atributos da tabela F_Triagem. F_Triagem Atributos Descrição

63 63 Seq_D_Doador Seq_D_Data Seq_D_Suspenso Seq_D_Pre_Triagem Situação_aptidao Volume_solicitado Auto_excluiu Chave estrangeira da dimensão doador Chave estrangeira da dimensão tempo Chave estrangeira da dimensão suspenso Chave estrangeira da dimensão pré-triagem Indica se o doador está apto a doar Identifica o volume solicitado para coleta Indica se o doador auto excluiu Tabela de Dimensão: D_Pre_Triagem Nesta tabela é possível identificar fatores que podem evitar que doador doe sangue no hemocentro, caso ele não esteja em condições para efetivar a doação ele pode ficar inapto. Os dados coletados no setor de pré-triagem deverão ser informados nesta tabela. Os atributos da tabela serão mostrados na tabela 11. Tabela 11 Representação dos atributos da tabela D_Pre_Triagem. D_Pre_Triagem Atributos Seq_D_Pre_Triagem Cod_doador Peso Temperatura Pulso Pressão Hematocrito Data_atendimento Descrição Chave primária da tabela Identificador o código do doador Identifica se o fator Rh do doador é positivo ou negativo Indica a temperatura do doador Indica a pulsação do doador Identificador de pressão do doador Indica se o doador está anêmico Refere-se à data que ocorreu a pré-triagem Tabela de Fatos: F_Coleta

64 64 Essa tabela está ligada às dimensões: D_Doador, D_Bolsa, D_Data, D_Suspenso, D_Tipagem_ABO, D_Doacao. As dimensões D_Doador e D_Doacao ainda não foram descritas e mais abaixo serão mostrados os seus atributos. Na tabela de fatos F_Coleta, é possível identificar informações sobre a coletas de sangue efetuadas no Hemocentro. Os atributos desta tabela estão representados na tabela 12. Tabela 12 Representação dos atributos da tabela F_Coleta. F_Coleta Atributos Seq_D_Doador Seq_D_Bolsa Seq_D_Tempo Seq_D_Suspenso Seq_D_Doacao Descrição Chave estrangeira da dimensão doador Chave estrangeira da dimensão bolsa Chave estrangeira da dimensão tempo Chave estrangeira da dimensão suspenso Chave estrangeira da dimensão doação Tabela de Dimensão: D_Bolsa Esta dimensão armazenará os dados referentes à doação de sangue de um doador. Seus atributos serão mostrados a seguir na tabela 13. Tabela 13 Representação dos atributos da tabela D_Bolsa. D_Bolsa Atributos Seq_D_Bolsa Volume Conector Descrição Chave primária da tabela Indica o volume de sangue da bolsa coletada Identifica o número do conector utilizado na coleta do sangue

65 Tabela de Dimensão: D_Doacao Nesta tabela serão armazenados os dados referentes ao código de doação de um doador e seu código de identificação no sistema, para que se possa fazer a ligação entre o doador e a doação. A tabela 14 mostra os atributos da dimensão. Tabela 14 Representação dos atributos da tabela D_Doacao. D_Doacao Atributos Seq_D_Doacao Cod_doador Cod_doacao Dat_doacao Descrição Chave primária da tabela Indicador do código do doador Identifica o número da doação gerado para o doador do campo Cod_doador. Representa a data em que foi efetuada a doacao Tabela de Fatos: F_Processamento Nesta tabela de fatos estão ligadas as seguintes tabelas de dimensões: D_Fracionamento, D_Distribuicao, D_Expurgo, D_Tipagem_ABO, D_Doacao, D_Data. A seguir serão mostrados os campos das tabelas que ainda não foram explicadas. A tabela de fatos F_Processamento faz a ligação entre a doação realizada pelo doador, e os hemocomponentes que foram produzidos da mesma. O campo situação bolsa, irá controlar a localização da bolsa no setor de processamento. A tabela 15 mostra os atributos da tabela de fatos do processamento. Tabela 15 Representação dos atributos da tabela F_Processamento.

66 66 F_Processamento Atributos Seq_D_Fracionamento Seq_D_Distribuicao Seq_D_Expurgo Seq_D_Tipagem_ABO Seq_D_Doacao Seq_D_Data Situação_bolsa Descrição Chave estrangeira da dimensão fracionamento Chave estrangeira da dimensão distribuição Chave estrangeira da dimensão expurgo Chave estrangeira da dimensão Tipagem ABO Chave estrangeira da dimensão doação Chave estrangeira da dimensão data Identifica a situação da bolsa no setor, se está no estoque, Tabela de Dimensão: D_Fracionamento Nesta tabela serão cadastradas todas as bolsas de hemocomponentes que forem produzidas no Hemocentro. A tabela 16 mostra os atributos da tabela de dimensão D_Fracionamento. Tabela 16 Representação dos atributos da tabela D_Fracionamento. D_Fracionamento Atributos Seq_D_Fracionamento Cod_doacao Hemocomponente Volume Dat_validade Descrição Chave primária da dimensão fracionamento Indica o código de identificação da bolsa Indica o hemocomponente utilizado Indica o volume da bolsa que esta sendo utilizado Indica a data de validade da bolsa Tabela de Dimensão: D_Distribuicao

67 67 Nesta tabela serão armazenados os registros de todas as saídas de bolsas, informando qual o hemocomponente que está sendo distribuído e para qual hospital ou órgão de destino dos mesmos. A tabela 17 mostra os atributos da tabela de dimensão. Tabela 17 Representação dos atributos da tabela D_Distribuicao. D_Distribuicao Atributos Descrição Seq_D_Distribuicao Chave primária da dimensão distribuição Cod_doacao Indica o código de identificação da bolsa Hemocomponente Indica o hemocomponente utilizado Num_distribuicao Indica qual o número da distribuição utilizado Destino Indica o local de destino da bolsa do hemocomponente Tabela de Dimensão: D_Expurgo Esta tabela é armazenado os dados referentes as bolsas que são expurgadas e jogadas fora, informando o motivo pelo qual foram expurgadas. A tabela 18 mostra os atributos da tabela de dimensão. Tabela 18 Representação dos atributos da tabela D_Expurgo. D_Expurgo Atributos Seq_D_Expurgo Cod_doacao Hemocomponente Motivo_expurgo Descrição Chave primária da dimensão distribuição Indica o código de identificação da bolsa Indica o hemocomponente utilizado Indica qual o motivo que a bolsa foi enviada para o expurgo

68 Tabela de Fatos: F_Sorologia A tabela de fatos da sorologia recebeu o nome de F_Sorologia, esta tabela é ligada as tabelas de dimensões: D_Pendencia, D_Bloqueio, D_Repeticao, D_Doacao, D_Data. As tabelas que ainda não foram definidas anteriormente serão definidas a seguir. A tabela 19 mostra os atributos da tabela de fatos da sorologia, que possui as ligações entre as tabelas de dimensões. Tabela 19 Representação dos atributos da tabela F_Sorologia. F_Sorologia Atributos Descrição Seq_D_Pendencia Chave estrangeira da dimensão pendência Seq_D_Repeticao Chave estrangeira da dimensão repetição Seq_D_Bloqueio Chave estrangeira da dimensão bloqueio Seq_D_Doacao Chave estrangeira da dimensão doação Seq_D_Data Chave estrangeira da dimensão data Resultado Identifica o resultado da amostra, se é bloqueado ou liberado Situação Identifica a situação da amostra no sistema, se a mesma é positivo ou negativo Tabela de Dimensão: D_Pendencia Esta tabela guardará informações relacionadas às amostras que ficaram pendentes no setor de sorologia. Quando um exame realizado em uma amostra detecta alguma alteração o código da amostra é colocado na pendência, para que sejam repetidos os exames. A tabela 20 mostra os atributos que serão armazenados sobre as pendências das amostras no setor de sorologia.

69 69 Tabela 20 Representação dos atributos da tabela D_Pendencia. D_Pendencia Atributos Seq_D_Pendencia Cod_doacao Exame Metodologia Motivo_pendencia Situação Descrição Chave primária da dimensão pendência Indica o código de identificação da amostra Indica o exame em a amostra ficou pendente Indica a metodologia do exame que ficou pendente Indica o motivo pelo qual a amostra ficou pendente Indica a situação da amostra, se foi liberada ou se está aguardando Tabela de Dimensão: D_Bloqueio Esta tabela irá armazenar os dados das amostras que foram bloqueadas pela sorologia, quando uma amostra é cadastrada nessa tabela, significa que seu resultado realmente é de sorologia positiva para algum exame. A tabela 21 mostra os atributos da tabela de fatos. Tabela 21 Representação dos atributos da tabela D_Bloqueio. D_Bloqueio Atributos Seq_D_Bloqueio Cod_doacao Exame Metodologia Descrição Chave primária da dimensão bloqueio Indica o código de identificação da amostra Indica o exame em a amostra ficou bloqueado Indica a metodologia do exame que ficou bloqueado Tabela de Dimensão: D_Repeticao

70 70 Nesta tabela serão armazenados os dados referentes aos resultados das amostras que são repetidas na sorologia. A tabela 22 mostra os atributos dessa tabela. Tabela 22 Representação dos atributos da tabela D_Repeticao. D_Repeticao Atributos Seq_D_Repeticao Cod_doacao Exame Metodologia Diagnostico Descrição Chave primária da dimensão repeticao Indica o código de identificação da amostra Indica o exame em a amostra ficou bloqueado Indica a metodologia do exame que ficou bloqueado Indica o resultado do exame realizado como inconclusivo, soro reagente e soro não reagente Tabela de Fatos: F_Imunohematologia Esta tabela de fatos armazenará as informações referente a imunohematologia. As dimensões que são ligadas a ela são: D_Exame_Imuno, D_Doacao, D_Tipagem_ABO, D_Data. A tabela D_Exame_Imuno é a única que ainda não foi definida anteriormente, e será definida a seguir. A tabela 23 mostra os atributos da tabela de fatos F_Imunohematologia. Tabela 23 Representação dos atributos da tabela F_Imunohematologia. F_Imunohematologia Atributos Seq_D_Doacao Seq_D_Tipagem_ABO Seq_D_Data Seq_D_Exame_Imuno Descrição Chave estrangeira da dimensão doação Chave estrangeira da dimensão tipagem ABO Chave estrangeira da dimensão data Chave estrangeira da dimensão exame imuno

71 Tabela de Dimensão: D_Exame_Imuno Nesta tabela serão armazenados os dados referentes aos resultados dos exames realizados pelo setor de imunohematologia. A tabela 24 mostra os atributos referentes a essa tabela. Tabela 24 Representação dos atributos da tabela D_Exame_Imuno. D_Exame_Imuno Atributos Seq_D_Exame_Imuno Cod_doacao D_fraco Hemoglobina_s PAI Cde_c Cde_d Cde_e Abo_reversa Descrição Chave primária da dimensão exame imuno Indica o código de identificação da amostra Indica o resultado do exame de D Fraco, se é positivo ou negativo Indica o resultado do exame, informado se o doador possui ou não um traço falciforme, como resultado é armazenado como negativo ou positivo Indica o resultado do exame, informando se o doador possui a presença de algum anticorpo irregular, informando positivo ou negativo Indica se o doador possui alguma reação para o anticorpo do tipo c, informando negativo ou positivo Indica se o doador possui alguma reação para o anticorpo do tipo d, informando negativo ou positivo Indica se o doador possui alguma reação para o anticorpo do tipo e, informando negativo ou positivo Indica qual a tipagem abo reversa que foi

72 72 Resultado realizada. Indica a liberação dos exames da imuno, sendo informado se está liberado ou não liberado Definição da arquitetura tecnológica Para evitar problemas com desempenho do banco, foram definidos alguns componentes básicos que seria utilizado no trabalho, são eles: sistema de Gerenciador de Bancos de Dados (SGBD): o sistema de gerenciamento escolhido para o desenvolvimento deste trabalho foi SQL Server 2005, pois é utilizada na base de dados de origem, e o conhecimento desse SGBD facilita a retirada das informações; ferramentas de Desenvolvimento de Sistemas OLAP e de Data Mining: será utilizada a ferramenta Crystal Report XI, para auxiliar na retirada dos relatórios. Não será utilizada nenhuma ferramenta de Data Mining, pois a proposta do trabalho não engloba retirada de relatórios minerados na base de dados do DW. ferramentas de Extração, Transformação e Carga (ETC): foi utilizado como ferramenta para auxiliar no processo ETC deste trabalho, o DTS do SQL Server catálogo para o controle de Metadados: a explicação do que conterá em todo o projeto está sendo definida nesse trabalho, assim, não está sendo desenvolvido nenhum outro arquivo de metadados. mecanismos para transferência de dados entre ambientes diferentes: não está sendo utilizada nenhum mecanismo, pois a base de dados é apenas uma. servidor de Data Mart: como servidor dos DM s será utilizado o SQL Server 2005 também, mas inicialmente não será desenvolvido nenhum DM separado, será desenvolvido o DW geral completo. extratos de Dados para o Data Mining: não será utilizada nenhuma ferramenta ou técnica de utilização de Data Mining.

73 Levantamento das necessidades da Empresa O modelo ER da base de dados do Hemovida, não foi possível o seu desenvolvimento, pois a base é muito grande e complexa, inviabilizando a construção desse modelo, mas a base foi analisada observando as tabelas diretamente da base. Após a análise da base, foi definido o modelo dimensional que será utilizado neste trabalho. A figura 13 exemplifica o modelo dimensional desenvolvido para o DW do Hemovida.

74 Figura 13 Modelo Dimensional do DW do Hemovida. 74

75 75 A Figura 13 mostra o modelo dimensional projetado para todo o ciclo do sangue no hemocentro, visando suprir as necessidades de aquisição de informações gerenciais. Para desenvolver esse modelo foi utilizado o programa DBDesigner 4. Foi modelado 6 tabelas de fatos e 15 tabelas de dimensões, sendo definidas as ligações entre cada tabela. Na seção seguinte serão explicadas detalhadamente as decisões desse modelo dimensional Modelagem Dimensional Antes de iniciar explicação da modelagem dimensional, mostrada na figura 13, devem ser esclarecidos alguns pontos da análise da modelagem. A definição da granularidade do DW foi feita analisando os resultados esperados do projeto. Algumas consultas dependem de um grau de detalhamento maior e outras de um grau de detalhamento dos dados menor. Por esse motivo optou-se por utilizar uma granularidade baixa, para que atendesse às duas abordagens. O modelo dimensional mostrado na figura 13, possui 6 tabelas de fatos, cada tabela de fatos representa uma área do Hemocentro, e cada tabela de fatos possui tabelas de dimensões ligadas a ela, que se relacionam informando todos os dados necessários nesses setor, por esse motivo, podemos nomear cada setor desses e suas dimensões como Data Mart (DM). Em seguida será explicado todos os DM definidos na modelagem Data Mart de Atendimento O DM de Atendimento tem como objetivo armazenar todas as informações importantes referentes ao atendimento do doador no Hemocentro. A figura 14 mostra o modelo do DM de Atendimento.

76 76 Figura 14 Modelo do DM de Atendimento A Figura 14 mostra o DM referente ao atendimento do doador. A tabela de fatos F_Atendimento, possui uma ligação com as tabelas de Dimensão D_Doador, D_Data, D_Local_Coleta e D_Tipagem_ABO. Os campos contidos em cada tabela já foram explicados anteriormente. A Dimensão D_Doador foi analisada de forma que o usuário do DW não tivesse acesso ao nome do doador, e evitando que a junção das informações, chegasse a descobrir o nome do mesmo. Por esse motivo foram utilizados dados mais genéricos dos dados do doador. As demais tabelas de dimensões estão armazenando apenas as informações mais importantes. A tabela de fatos F_Atendimento está fazendo a ligação com as 4 (quatro) dimensões, e a mesma possui o atributo chamado Tipo_doacao, onde é informado se o doador é voluntário, reposição, entre outros. A seguir será mostrado o DM da Triagem Clínica.

77 Data Mart de Triagem Este DM tem por objetivo armazenar e proporcionar consultas referentes aos dados da triagem clínica realizada em um doador. A figura 15 mostra o modelo desse DM. Figura 15 Modelo do DM da Triagem A Figura 15 mostra as tabelas de dimensões que são ligadas a tabela de fatos F_Triagem. As descrições das tabelas já foram definidas na seção anterior. A seguir será mostrado o modelo do DM da coleta Data Mart de Coleta Este DM armazena os principais dados referentes a coleta de sangue de um doador. Para isso foram ligadas a tabela de fatos F_Coleta, as dimensões que possuíam informações pertinentes para essa tabela de fatos. A figura 16 mostra o modelo deste DM.

78 78 Figura 16 Modelo do DM da Coleta. A figura 16 mostra o modelo do DM em que a tabela de fatos F_Coleta possui a ligação entre as tabelas de dimensões que são necessárias para armazenar as informações referentes a coleta de sangue do doador. A seguir será mostrado o DM do processamento Data Mart de Processamento Este DM objetiva armazenar todas as principais informações referentes a área de processamento do sangue no Hemocentro. A figura 17 mostra o modelo do DM do processamento.

79 79 Figura 17 Modelo do DM do processamento A Figura 17 mostra a tabela de fatos F_Processamento, em que é ligada as tabelas de dimensões que são necessárias para obter os dados referentes ao setor de processamento. A seguir será mostrado o modelo do DM da sorologia Data Mart de Sorologia Este modelo armazena os dados referentes aos exames sorológicos efetuados no Hemocentro. A figura 18 mostra o modelo do DM da sorologia.

80 80 Figura 18 Modelo do DM da sorologia A Figura 18 mostra o modelo do DM desenvolvido para o setor de sorologia. Na tabela de fatos F_Sorologia são ligadas as tabelas de dimensões que são necessárias para adquirir as informações referentes a sorologia. A seguir será mostrada o modelo do DM da imunohematologia Data Mart de Imunohematologia Este DM fornecerá informações referentes ao setor de Imunohematologia do Hemocentro, informando os dados dos resultados dos exames realizados nesse setor. A figura 19 mostra o modelo do DM da imunohematologia.

81 81 Figura 19 Modelo do DM da imunohematologia A Figura 19 mostra o modelo do DM desenvolvido para o setor de imunohematologia. Na tabela de fatos F_Imunohematologia são ligadas as tabelas de dimensões necessárias para fornecer as informações referentes a imunohematologia. Foram mostrados os modelos dimensionais dos DM desenvolvidos para o DW geral do Hemocentro. Na seção seguinte mostra o projeto físico dessa modelagem dimensional Projeto físico do banco de dados Com a finalização da modelagem dimensional foi criada a base de dados do DW no SQL Server Para auxiliar na construção dessa base, foi utilizada uma função da ferramenta DBDesigner 4, que gera um script em SQL que cria as tabelas com as configurações modeladas da base do DW. A figura 20 mostra um exemplo do código gerado, o código completo pode ser conferido em anexo.

82 82 CREATE TABLE D_Pendencia ( Seq_D_Pendencia INTEGER UNSIGNED NOT NULL AUTO_INCREMENT, Cod_doacao CHAR(15) NULL, Exame CHAR(50) NULL, Metodologia CHAR(15) NULL, Motivo_pendencia CHAR(50) NULL, Situacao CHAR(30) NULL, PRIMARY KEY(Seq_D_Pendencia) ); Figura 20 Exemplo de código gerado pelo DBDesigner 4. Nesse script gerado foi necessário fazer algumas alterações para ser executado no SQL Server 2005, pois o mesmo foi gerado para ser utilizado em MySQL. Foi necessário retirar os comandos UNSIGNED e AUTO_INCREMENT, dos campos chave primária das tabelas, assim foi possível criar as tabelas fisicamente no banco de dados. O código alterado pode ser conferido em anexo. O modelo da base de dados pode ser observado na figura 21.

83 83 D_Bloqueio Seq_D_Bloqueio Cod_doacao Exame Metodologia D_Bolsa Seq_D_Bolsa Cod_doacao Volume Conector D_Data Seq_D_Data Dia Mes Ano Data D_Distribuicao Seq_D_Distribuicao Cod_doacao Hemocomponente Num_distribuicao Destino D_Doacao Seq_D_Doacao Cod_doacao Cod_doador Dat_doacao D_Doador Seq_D_Doador Cod_doador Dat_nascimento Cor Sexo Naturalidade Municipio Estado_civil Bairro Escolaridade D_Exame_Imuno Seq_D_Exame_Imuno Cod_doacao D_fraco Hemoglobina_s PAI Cde_c Cde_d Cde_e Abo_reversa Resultado D_Expurgo Seq_D_Expurgo Cod_doacao Hemocomponente Motivo_expurgo D_Fracionamento Seq_D_Fracionamento Cod_doacao Hemocomponente Volume Dat_validade D_Local_Coleta Seq_D_Local_coleta Nome Municipio D_Pendencia Seq_D_Pendencia Cod_doacao Exame Metodologia Motivo_pendencia Situacao D_Pre_Triagem Seq_D_Pre_Triagem Cod_doador Peso Temperatura Pulso Pressao Hematocrito Dat_atendimento D_Repeticao Seq_D_Repeticao Cod_doacao Exame Metodologia Diagnostico D_Suspenso Seq_D_Suspenso Cod_doador Tipo Motivo Num_dias Tipo_inaptidao D_Tipagem_ABO Seq_D_Tipagem_ABO Grupo_ABO Rh F_Atendimento Seq_D_Doador Seq_D_Local_Coleta Seq_D_Data Seq_D_Suspenso Seq_D_Tipagem_ABO Tipo_doacao F_Coleta Seq_D_Doador Seq_D_Bolsa Seq_D_Data Seq_D_Suspenso Seq_D_Tipagem_ABO Seq_D_Doacao F_Imunohematologia Seq_D_Doacao Seq_D_Tipagem_ABO Seq_D_Data Seq_D_Exame_Imuno F_Processamento Seq_D_Fracionamento Seq_D_Distribuicao Seq_D_Expurgo Seq_D_Tipagem_ABO Seq_D_Doacao Seq_D_Data Situacao_bolsa F_Sorologia Seq_D_Pendencia Seq_D_Repeticao Seq_D_Bloqueio Seq_D_Doacao Seq_D_Data Resultado Situacao F_Triagem Seq_D_Doador Seq_D_Data Seq_D_Suspenso Seq_D_Pre_Triagem Situacao_aptidao Volume_solicitado Auto_excluiu Figura 21 - Modelo físico do DW do Hemovida.

84 84 A Figura 21 mostra o modelo completo do banco do DW feito no SQL Server A partir dele, podem ser separados os DM s, conforme mostrado anteriormente. Concluindo o processo de criação da base de dados do DW, foi iniciado o processo de retirada das informações da base de dados original do Hemovida e foi preenchido o banco de dados do DW, conforme será explicado na seção seguinte Projeto de ETL (Extract, Transform and Load) Nesta fase do projeto, após a limpeza e integração dos dados, foi efetuado o carregamento da base de dados do DW com as informações da base de dados original do Hemovida. E segundo Barbieri (2005, p. 75) esse carregamento é subdivido nos passos seguintes Filtro de Dados Nesta fase foram realizadas consultas na base de dados de origem, buscando as informações que seriam necessárias conter no DW. Essas consultas foram feitas no SQL Server 2005, diretamente na base do Hemovida. O script mostrado na figura 22, é um exemplo de uma consulta efetuada para preenchimento da dimensão D_Pendencia, que é ligada à tabela de fatos F_Sorologia. --Preenchimento Dimensao Pendencia select p.doacao,e.descricao,p.reacao,ps.motivo, p.liberado from soropend p left outer join pendsoro ps ON p.pendencia=ps.codigo left outer join texame e ON p.exame=e.codigo Figura 22 Exemplo de consulta para preenchimento das dimensões. A Figura 22 mostra o código SQL utilizado para preencher a dimensão D_Pendencia. Foi efetuado uma consulta na tabela em que é armazenado no

85 85 banco de dados do Hemovida as informações referentes às amostras que ficaram pendentes, está tabela é chamada de soropend, para se obter a descrição da pendência e o motivo foi necessário pesquisar nas tabelas pendsoro e texame. O resultado dessa consulta pode ser observado na figura 23 exibida a seguir. Figura 23 Resultado da consulta para o preenchimento de tabelas de dimensão. A Figura 23 mostra o resultado da execução do código mostrado na figura. Na consulta foram solicitados somente os dados que seriam inseridos na tabela de dimensão. Esse processo foi realizado para preenchimento de todas as tabelas de dimensões. A seção seguinte mostra as formas de integração que foram utilizadas no desenvolvimento deste trabalho.

86 Integração de Dados Após a consulta realizada no tópico anterior, o resultado foi copiado para o Excel e foi feito o processo de limpeza dos dados. A figura 24 mostra a tabela limpa e padronizada. Figura 24 Exemplo de limpeza dos dados no processo ETL. A Figura 24 mostra os dados obtidos da tabela do Hemovida limpos e padronizados. Em todos os atributos das tabelas foram realizadas pesquisas a procura de campos nulos e com espaços em branco, esses campos foram substituídos por -1 quando o atributo era do tipo numérico e por Nao Informado se o atributo era do tipo char ou varchar. Campos como o atributo resultado, que na tabela original possui informações como A ou L, são substituídos pelos valores completos, A por Aguardando e L por Liberado.

87 87 Esse processo foi efetuado para a carga de todas as tabelas do DW. Finalizando esse processo de limpeza, os dados foram carregados para a base do DW, utilizando a ferramenta Transformation Data Task do SQL Server 2005, a partir dele foi possível extrair os dados de tabelas e de outros formatos como de planilhas do Excel. Algumas tabelas foram carregadas diretamente da base original para o DW, utilizando a mesma ferramenta de DTS do SQL, mas esse processo só pôde ser executado para tabelas em que não houve a necessidade de limpeza do seu conteúdo. A figura 25 mostra o acesso ao DTS pelo SQL Server. Figura 25 Acesso ao DTS pelo SQL Server. A Figura 25 mostra o acesso ao processo de DTS pelo banco de dados SQL Server. Clicando com o botão direito do mouse no nome da base de dados do DW têm-se acesso a um sub-menu em que deve acessar a opção Tasks e depois na opção Import Data. A figura 26 mostra a próxima tela, que se refere ao início do processo de carregamento das informações.

88 88 Figura 26 Início do processo de DTS. A Figura 26 mostra a tela de boas vindas a início do processo de DTS. A figura 27 mostra a primeira fase do processo de DTS. Figura 27 Escolhendo a origem e o destino dos dados no DTS.

89 89 A Figura 27 mostra na primeira tela a origem dos dados, onde é informado o banco de dados ou o tipo de arquivos que tem as informações de origem. Se for um banco de dados, basta escolher o nome do banco e se for um arquivo tem que localizar o arquivo. Assim, passa para a próxima tela, onde é feita a escolha do banco de destino. A figura 28 mostra a escolha da ação a ser tomada e mostra a tela de escolha da tabela de origem. Figura 28 Mostra os tipos de criação da tabela e a escolha da tabela de origem. A Figura 28 mostra na primeira tela as opções para escolher a ação a ser executada, se será copiar os dados para uma tabela ou criar uma nova tabela. Na tela seguinte são mostrados as planilhas existentes no arquivo Excel que podem ser escolhidas. A figura 29 mostra os próximos passos para escolha dos atributos. Figura 29 Escolha dos atributos e de salvamento das ações tomadas.

90 90 A Figura 29 mostra, na primeira tela, os atributos existentes no arquivo de origem e permite a escolha do atributo de destino na tabela escolhida. A tela seguinte fornece as opções de passar para o próximo sem salvar, o que foi feito, e também disponibiliza a opção de salvar esses dados. A figura 30 mostra os dois últimos passos para finalizar o processo de DTS. Figura 30 - Mensagem de finalização do processo DTS e progresso da operação. A Figura 30, na primeira tela, mostra uma mensagem em que informa que as configurações do processo de DTS foi finalizado com sucesso, e a segunda tela mostra o progresso do processo de transferência das informações. Finalizando esse processo a tabela de dimensão estará preenchida, como mostra a figura 31.

91 91 Figura 31 Tabela de Dimensão D_Pendencia preenchida após processo DTS. A Figura 31 mostra a tabela de dimensão preenchida. Esse processo de DTS deve ser feito para todas as tabelas de dimensões. Para se preencher as tabelas de fatos, o processo é um pouco diferente. Necessita-se da criação de uma tabela temporária, que auxiliará no processo de interligação entre as tabelas de dimensões e as tabelas de fatos. A tabela temporária conterá um atributo que identificará cada tabela de dimensão que faz parte da chave primária concatenada da tabela de fatos correspondente. A figura 32 mostra um exemplo do SQL utilizado para preenchimento de uma tabela de fatos e o resultado de sua consulta. select l.doacao as Cod_Sorologia, s.doacao as Cod_Pendencia, o.doacao as Cod_Repeticao, b.doacao as Cod_Bloqueio, d.doacao as Cod_Doacao,l.dtexame, l.resultado, l.situacao from sorolog l left outer join doacao d on l.doacao = d.doacao left outer join soropend s on l.doacao = s.doacao left outer join sororpt o on l.doacao = o.doacao left outer join bloqueio b on l.doacao = b.doacao Figura 32 Exemplo de SQL para preenchimento da Temp_Sorologia

92 92 A Figura 32 mostra o código SQL utilizado para o preenchimento da tabela temporária que servirá de referência para a tabela de fatos da sorologia. Está tabela foi preenchida fazendo uma junção entre as tabelas sorolog, doação, soropend, sororpt e bloqueio. Dessa junção foram retiradas as informações que seriam necessárias para o preenchimento da tabela de fatos da sorologia. A figura 33 mostra o resultado dessa consulta que foi realizada no banco de dados do Hemovida. Figura 33 Resultado de preenchimento de tabela temporária da sorologia. A Figura 33 mostra o resultado da consulta no SQL Server, após a realização dessa consulta, os dados devem passar por todo o processo de DTS, que para o próximo passo seria a limpeza dos dados. Para essa limpeza os dados devem ser levados para o Excel. Conforme ilustra a figura 34.

93 93 Figura 34 Dados da Tabela Temporária da sorologia em processo de limpeza. A Figura 34 mostra os dados já padronizados e limpos. Após esse processo concluído, dever ser realizado o processo de carga dessas informações para a base de dados do DW, para a tabela Temp_Sorologia, seguindo o processo de carga descritos nas Figuras 25 até a 30. A única diferença desse processo está na utilização do arquivo do Excel que acabou de ser criado e a tabela de destino é a temporária da tabela de fato sorologia. Os demais processos são idênticos. Com a tabela temporária da tabela de fatos da sorologia preenchida, iniciase o processo de carga da tabela de fatos. Esse processo de carregamento das informações é um pouco diferente do utilizado para carregar as dimensões e as tabelas temporárias. O carregamento da tabela de fatos F_Sorologia foi efetuado através do comando Insert descrito na figura 35.

94 94 INSERT INTO F_Sorologia(Seq_D_Doacao,Seq_D_Pendencia, Seq_D_Repeticao, Seq_D_Bloqueio, Seq_D_Data, Resultado, Situacao ) SELECT distinct(isnull(d.seq_d_doacao,44991)),isnull(p.seq_d_pendencia,4501), ISNULL(r.Seq_D_Repeticao,699), ISNULL (b.seq_d_bloqueio, 4333), ISNULL(dt.Seq_D_Data,18629), s.resultado, s.situacao FROM Temp_F_Sorologia s LEFT OUTER JOIN D_Pendencia p ON (s.cod_pendencia = p.cod_doacao) LEFT OUTER JOIN D_Repeticao r ON (s.cod_repeticao = r.cod_doacao) LEFT OUTER JOIN D_Bloqueio b ON (s.cod_bloqueio = b.cod_doacao) LEFT OUTER JOIN D_Doacao d ON (s.cod_doacao = d.cod_doacao) LEFT OUTER JOIN D_Data dt ON (s.data_exame = dt.data) Figura 35 Código fonte de preenchimento da tabela de fatos F_Sorologia. A Figura 35 mostra o código SQL utilizado para preenchimento da F_Sorologia. Nesse código pode ser observado que se têm um comando insert no início e um outro comando select depois. O comando select faz as pesquisas e comparações necessárias para o preenchimento da tabela de fatos e o comando insert preenche a tabela de fatos. No comando select é realizada as comparações entre os campos que fazem a ligação entre um doador ou entre uma doação da tabela temporária, com as tabelas de dimensões. Finalizando essas comparações, são retornados como resultado do select, os campos seqüenciais criados nas tabelas de dimensões, por serem campos com números únicos. Como ilustra a tabela 36. Esses seqüenciais são inseridos na tabela de fatos com o comando insert. A figura 37 mostra o resultado do preenchimento da tabela de fatos.

95 95 Figura 36 Exemplifica o select efetuado para preenchimento da F_Sorologia. Figura 37 Tabela de fatos F_Sorologia preenchida.

96 96 Os processos de DTS de preenchimento das tabelas de dimensões e de fatos seguem as mesmas linhas de raciocínio. As diferenças estão nas consultas efetuadas na base de dados original do Hemovida e os inserts criados para o preenchimento das tabelas de fatos. A figura 38 mostra alguns exemplos de consultas realizadas na base para preenchimento das tabelas de dimensões. --Preenchimento Dimensao Doacao select c.doacao,c.doador,c.dtatend from coleta c, doacao d where (c.doacao=d.doacao) and (c.doador=d.doador) --Preenchimento Dimensao Bloqueio select doacao,exame,reacao from bloqueio --Preenchimento Dimensao Distribuicao select d.nrdistrib,d.doacao,h.descricao,hosp.nome from distrib d left outer join hemocomp h ON d.hemocomp=h.hemocomponente left outer join hospital hosp ON d.destino=hosp.codigo --Preenchimento Dimensao Exame Imuno select doacao,du,testemancha, t_anticorpos,cde_c,cde_d,cde_e,abo_reversa,resultado from imunohe --Preenchimento Dimensao Expurgo select e.doacao,h.descricao,d.descarte from expurgo e left outer join hemocomp h ON e.hemocomp=h.hemocomponente left outer join descarte d ON d.codigo=e.descarte --Preenchimento Dimensao Fracionamento select ff.doacao,h.descricao,ff.volume, ff.dtvalidade from fracao ff left outer join fraciona f ON f.doacao=ff.doacao left outer join hemocomp h ON ff.hemocomp=h.hemocomponente --Preenchimento Dimensao Repeticao select sr.doacao,e.descricao,sr.reacao,sr.diagnostico from sororpt sr left outer join texame e ON sr.exame=e.codigo Figura 38 Código de consultas efetuadas para preenchimentos de dimensões. O primeiro código mostrado na figura 38, mostra uma consulta realizada nas tabelas de coleta e doação, buscando as informações necessárias para preencher a tabela dimensão D_Doacao. Esse processo de consulta é realizado para o preenchimento de todas as tabelas de dimensões, sendo que suas

97 97 consultas são realizadas nas tabelas que possuem os dados relacionados com cada dimensão. A figura 39 mostra algumas consultas efetuadas para o preenchimento das tabelas temporárias e das tabelas de fatos. --Preenchimento Temporaria do Processamento SELECT f.doacao as Cod_Fracionamento,h.descricao,d.doacao as Cod_Distribuicao,e.doacao as Cod_Expurgo,i.grupoabo, i.fatorrh, dd.doacao as Cod_Doador, f.dtfraciona, es.situacao FROM fracao f LEFT OUTER JOIN hemocomp h on (f.hemocomp = h.hemocomponente) LEFT OUTER JOIN distrib d on (f.doacao = d.doacao) and (f.hemocomp = d.hemocomp) LEFT OUTER JOIN expurgo e on (f.doacao = e.doacao) and (f.hemocomp = e.hemocomp) LEFT OUTER JOIN imunohe i on (f.doacao = i.doacao) LEFT OUTER JOIN doacao dd on (f.doacao = dd.doacao) LEFT OUTER JOIN estoque es on (f.doacao = es.doacao) and (f.hemocomp = es.hemocomp) --Preenchimento da Fato Processamento INSERT INTO F_PROCESSAMENTO(Seq_D_Fracionamento, Seq_D_Distribuicao, Seq_D_Expurgo, Seq_D_Tipagem_ABO, Seq_D_Doacao, Seq_D_Data, Situacao_bolsa ) SELECT ISNULL(f.Seq_D_Fracionamento,98556), ISNULL(d.Seq_D_Distribuicao,41411), ISNULL (e.seq_d_expurgo, 55539), ISNULL (t.seq_d_tipagem_abo, 9), ISNULL(dd.Seq_D_Doacao,44991), ISNULL(dt.Seq_D_Data,18629), p.situacao FROM Temp_F_Processamento p LEFT OUTER JOIN D_Fracionamento f ON (p.cod_fracionamento = f.cod_doacao) and (p.hemocomponente = f.hemocomponente) LEFT OUTER JOIN D_Distribuicao d ON (p.cod_distribuicao = d.cod_doacao) and (p.hemocomponente = d.hemocomponente) LEFT OUTER JOIN D_Expurgo e ON (p.cod_expurgo = e.cod_doacao) and (p.hemocomponente = e.hemocomponente) LEFT OUTER JOIN D_Tipagem_ABO t on (p.grupo_abo = t.grupo_abo) and (p.fator_rh = t.rh) LEFT OUTER JOIN D_Doacao dd ON (p.cod_doacao = dd.cod_doacao) LEFT OUTER JOIN D_Data dt ON (p.data_fracionamento = dt.data) --Preenchimento da Temporaria da Imunohematologia SELECT i.doacao,i.grupoabo,i.fatorrh,i.dtimuno FROM Imunohe i --Preenchimento da Fato Imunohematologia INSERT INTO F_IMUNOHEMATOLOGIA (Seq_D_Doacao, Seq_D_Tipagem_ABO, Seq_D_Data, Seq_D_Exame_Imuno) SELECT ISNULL(dd.Seq_D_Doacao,44991), ISNULL(t.Seq_D_Tipagem_ABO,9), ISNULL(dt.Seq_D_Data,18629),ISNULL(e.Seq_D_Exame_Imuno,41455) FROM Temp_F_Imunohematologia i LEFT OUTER JOIN D_Doacao dd ON (i.cod_doacao = dd.cod_doacao) LEFT OUTER JOIN D_Tipagem_ABO t ON (i.grupo_abo = t.grupo_abo) and (i.fator_rh = t.rh) LEFT OUTER JOIN D_Data dt ON i.dat_imunohemato = dt.data LEFT OUTER JOIN D_Exame_Imuno e ON i.cod_doacao = e.cod_doacao Figura 39 Códigos de preenchimento das tabelas temporárias e de fatos.

98 98 O primeiro código mostrado na Figura 39 exibe uma consulta realizada para preenchimento da tabela temporária do fracionamento, onde é feita uma pesquisa utilizando as tabelas fracao, hemocomp, distrib, expurgo, imunohe, doacao e estoque, em que é pesquisado em cada tabela, um código que seja único, para que ao comparar com os dados existentes nas tabelas de dimensões, seja possível encontrar as referências entre as tabelas da base original e as tabelas das dimensões. O segundo código da Figura 39 mostra uma instrução SQL em que realiza a inserção dos dados no DW e uma instrução que realizada a pesquisa e as comparações entre as tabelas de dimensões e a tabela temporária. Com a finalização do carregamento das tabelas do DW, pode ser afirmado que o processo de construção do mesmo foi finalizado. A partir desse momento, deve-se passar para a construção dos relatórios para retirar informações do DW construído Condensação de Dados Este trabalho não utilizou esse processo de redução das informações para os dados que seriam armazenados no DW, pois sua granularidade foi estipulada como baixa possuindo obrigatoriamente muitos detalhes nos dados na base Conversão de Dados Os tipos de conversões utilizados foram os do processo de integração dos dados. Para os atributos em que era armazenada na base do Hemovida apenas uma letra, que tem seu significado apenas definido na aplicação, foi necessário substituir essas letras pelos seus significados. Isso aconteceu para os atributos sexo, situação da bolsa, situação de aptidão, entre outros Derivação de Dados Este processo da construção do DW não foi utilizado, pois na análise não se julgou necessária à criação de campos de somatórios, médias ou qualquer

99 99 outro tipo de campo seguindo esse estilo, pois essas informações podem ser adquiridas com facilidade e rapidez através dos relatórios Desenvolvimento de aplicações, Validação e testes Após a finalização do preenchimento do DW, foi iniciado o processo de retirada de relatórios, com o intuito de fornecer informações que auxiliassem o Hemocentro nas decisões gerenciais. A proposta deste trabalho não foi à criação de aplicações para acessar as informações do DW, por esse motivo, foram criadas algumas consultas apenas para validar e testar a real aplicação da criação do DW proposto. Para a realização dessas consultas foi utilizada a ferramenta Crystal Reports XI (CRYSTAL, 2006), que auxiliou na criação dos relatórios e gráficos. A seguir serão apresentados os resultados encontrados a partir das consultas criadas. A primeira questão levantada foi com relação à quantidade de atendimentos registrados no Hemocentro no ano de 2005, levando-se em consideração que o doador residia no Centro de Palmas e sendo doações voluntárias. Para a construção deste relatório foi utilizada a consulta SQL ilustrada pela figura 40. SELECT dt.mes, t.grupo_abo,t.rh, COUNT(a.tipo_doacao),d.sexo FROM F_Atendimento a LEFT OUTER JOIN D_Data dt on dt.seq_d_data = a.seq_d_data LEFT OUTER JOIN D_Doador d on d.seq_d_doador = a.seq_d_doador LEFT OUTER JOIN D_Local_Coleta l on l.seq_d_local_coleta = a.seq_d_local_coleta LEFT OUTER JOIN D_Tipagem_ABO t on t.seq_d_tipagem_abo = a.seq_d_tipagem_abo WHERE (a.tipo_doacao = 'Voluntario') and (d.bairro = 'Centro') and (dt.ano = '05') GROUP BY dt.mes, rh,grupo_abo, sexo ORDER BY dt.mes, grupo_abo,sexo Figura 40 Código SQL gerado para o primeiro relatório. A Figura 40 mostra o código SQL que foi utilizado para a criação do primeiro relatório proposto, em que se fez uma consulta na tabela de fatos F_atendimento, comparando com as tabelas de dimensões D_Data,

100 100 D_Doador, D_Local_Coleta e D_Tipagem_ABO, verificando se os dados que continham na tabela de fatos correspondia aos dados das tabelas de dimensão, obedecendo os critérios de consulta. Para essa consulta foi gerado o relatório final mostrado na figura 41 e o gráfico mostrado na figura 42. Figura 41 Relatório gerado para a primeira consulta. A Figura 41 mostra os campos retornados na consulta SQL, sendo que a partir desses dados foi gerado o gráfico mostrado na figura 42.

101 101 Figura 42 Gráfico gerado para o primeiro relatório. O relatório mostrado na figura 41 e o gráfico mostrado na figura 42 tiveram por objetivo mostrar a relação entre os atendimentos realizados no Hemocentro durante o ano de 2005, separados por mês, sexo e tipagem sanguínea do doador. A partir desse relatório, podem ser realizadas várias comparações gerenciais, como por exemplo, no mês de março foi registrado o maior número de doação para o tipo sanguíneo A positivo, sendo que nos demais a tipagem O positivo sempre foi a de maior quantidade. Com esse dado, pode ser realizada uma pesquisa no Hemocentro verificando se ocorreu algum evento diferente nesse período, para identificar o motivo dessa mudança. A segunda questão levantada foi com relação à quantidade de inaptos na triagem clínica, separados por motivo de inaptidão, estado civil e município em que o doador reside. Para a construção deste relatório foi utilizada a consulta SQL ilustrada pela figura 43.

102 102 SELECT s.motivo, count(s.motivo), d.estado_civil, d.municipio FROM F_Triagem t LEFT OUTER JOIN D_Data dt on dt.seq_d_data = t.seq_d_data LEFT OUTER JOIN D_Doador d on d.seq_d_doador = t.seq_d_doador LEFT OUTER JOIN D_Suspenso s ON s.seq_d_suspenso = t.seq_d_suspenso LEFT OUTER JOIN D_Pre_Triagem pt ON pt.seq_d_pre_triagem = t.seq_d_pre_triagem WHERE (s.tipo = 'Intercorrencia') and (dt.ano = '05') group by s.motivo, d.estado_civil, d.municipio order by count(s.motivo) desc, d.municipio Figura 43 Código SQL gerado para a segunda consulta. A Figura 43 mostra o código SQL que foi utilizado para a criação do segundo relatório proposto, que faz uma consulta na tabela de fatos F_Triagem comparando com as informações das tabelas de dimensões D_Data, D_Doador, D_Suspenso e D_Pre_Triagem, verificando os dados correspondentes entre elas, respeitando os critérios de restrições dessa consulta. Para essa consulta foi gerado o relatório final mostrado na figura 44 e o gráfico mostrado na figura 45. Figura 44 Gráfico gerado para o segundo relatório.

103 103 A Figura 44 mostra os campos retornados na consulta SQL, a partir desses dados foi gerado o gráfico mostrado na figura 45. Figura 45 Gráfico gerado para o segundo relatório. O relatório mostrado na figura 44 e o gráfico mostrado na figura 45 tiveram por objetivo mostrar a relação entre as triagens clínicas realizadas em que o doador ficou inapto durante o ano de 2005, separados pelo município de residência do doador, o estado civil e o motivo pelo qual o doador ficou inapto. A partir desse relatório, podem ser realizadas várias análises gerenciais, como por exemplo, foi observado que o maior índice de inaptidão registrado foi pelo motivo de comportamento de risco, no município de Palmas, e com o estado civil sendo de casado, e em 8º lugar ficou o motivo de múltiplos parceiros, também em Palmas e para o estado civil de casado. Este dado pode ser analisado de várias formas, uma dessas pode ser citada a falta de compromisso com o casamento, pois o maior índice de inaptidão está sendo entre os casados. A terceira questão levantada foi com relação à quantidade de doadores que se auto-excluíram, separados por sexo, estado civil, escolaridade e município em

104 104 que o doador reside. Para a construção deste relatório foi utilizada a consulta SQL ilustrada pela figura 46. SELECT d.sexo, d.estado_civil, d.escolaridade, d.municipio, count(t.auto_excluiu) FROM F_Triagem t LEFT OUTER JOIN D_Data dt on dt.seq_d_data = t.seq_d_data LEFT OUTER JOIN D_Doador d on d.seq_d_doador = t.seq_d_doador LEFT OUTER JOIN D_Suspenso s ON s.seq_d_suspenso = t.seq_d_suspenso LEFT OUTER JOIN D_Pre_Triagem pt ON pt.seq_d_pre_triagem = t.seq_d_pre_triagem WHERE (t.auto_excluiu = 'Sim')-- and (dt.ano = '05') group by d.estado_civil, d.sexo, d.escolaridade, d.municipio order by count(t.auto_excluiu) desc,d.estado_civil, d.sexo, d.escolaridade, d.municipio Figura 46 Código SQL gerado para a terceira consulta. A Figura 46 mostra o código SQL que foi utilizado para a criação do terceiro relatório proposto, mostrando a comparação entre a tabela de fato F_Triagem e as dimensões D_Data, D_Doador, D_Suspenso e D_Pre_Triagem, respeitando as restrições dessa consulta. Para essa consulta foi gerado o relatório final mostrado na figura 47 e o gráfico mostrado na figura 48. Figura 47 Relatório gerado para a terceira consulta.

105 105 A Figura 47 mostra os campos retornados na consulta SQL, a partir desses dados foi gerado o gráfico mostrado na figura 48. Figura 48 Gráfico gerado para a terceira consulta. O relatório mostrado na figura 47 e o gráfico mostrado na figura 48 tiveram por objetivo mostrar a relação entre os doadores que se auto-excluíram, separados pelo município de residência do doador, o estado civil, sexo e escolaridade do doador. A partir desse relatório, podem ser realizadas algumas análises, como por exemplo, foi observado que o maior índice registrado foi por homens casados que possuem o 2º grau completo e que moram em Palmas, seguido por homens solteiros com 2º grau completo e que também moram em Palmas. Analisando esses dados pode ser visualizado o perfil do doador que normalmente se autoexcluem em Palmas e, com isso, podem ser tomadas decisões no Hemocentro. A quarta questão levantada foi com relação à quantidade de doadores que doaram durante o ano de 2005, separados por sexo, estado civil, escolaridade,

106 106 cor e município em que o doador reside. Para a construção deste relatório foi utilizada a consulta SQL ilustrada pela figura 49. SELECT d.sexo, d.estado_civil, d.escolaridade, d.cor, d.municipio, count(dd.cod_doacao) FROM F_Coleta c LEFT OUTER JOIN D_Doador d on d.seq_d_doador = c.seq_d_doador LEFT OUTER JOIN D_Bolsa b on b.seq_d_bolsa = c.seq_d_bolsa LEFT OUTER JOIN D_Data dt on dt.seq_d_data = c.seq_d_data LEFT OUTER JOIN D_Suspenso s ON s.seq_d_suspenso = c.seq_d_suspenso LEFT OUTER JOIN D_Tipagem_ABO t ON t.seq_d_tipagem_abo = c.seq_d_tipagem_abo LEFT OUTER JOIN D_Doacao dd on dd.seq_d_doacao = c.seq_d_doacao WHERE (dt.ano = '05') group by d.sexo, d.estado_civil, d.escolaridade, d.cor, d.municipio order by count(dd.cod_doacao) desc Figura 49 Consulta SQL gerada para a quarta consulta. A Figura 49 mostra o código SQL que foi utilizado para a criação do quarto relatório proposto, que faz uma consulta na tabela de fatos F_Coleta comparando com as informações com as tabelas de dimensões D_Doador, D_Bolsa, D_Data, D_Suspenso, D_Tipagem_ABO e D_Doacao, verificando os dados correspondentes entre elas, respeitando os critérios e restrições dessa consulta. Para essa consulta foi gerado o relatório final mostrado na figura 50 e o gráfico mostrado na figura 51. Figura 50 Relatório gerado para a quarta consulta.

107 107 A Figura 50 mostra os campos retornados na consulta SQL, a partir desses dados foi gerado o gráfico mostrado na figura 51. Figura 51 Gráfico gerado para a quarta consulta O relatório mostrado na figura 50 e o gráfico mostrado na figura 51 tiveram por objetivo mostrar um perfil do doador durante o ano de 2005, informando o sexo, escolaridade, estado civil, cor e município de residência do doador. A partir desse relatório, pode iniciar a análise do perfil do doador palmense. Foi observado que a maioria dos doadores de Palmas já concluiu o 2º grau, são homens entre solteiros e casados, sendo da cor caucasiana ou caucasiana brasileiro. Essas informações podem auxiliar na montagem das palestras com dados estatísticos e em várias outras atividades do Hemocentro. A quinta questão levantada foi com relação à quantidade de exames com o resultado sendo de soro reagente para qualquer um dos exames realizados no Hemocentro, sendo organizada pelo período de meses e de anos registrados no Hemovida, desde instalação do Sistema. Para a construção deste relatório foi utilizada a consulta SQL ilustrada pela figura 52.