Namedin Pereira Teles Júnior

Transcrição

1 Backup Markup Language (BKPML): Uma Proposta para Interoperabilidade e Padronização de Backup de Dados Por Namedin Pereira Teles Júnior Dissertação de Mestrado Universidade Federal de Pernambuco posgraduacao@cin.ufpe.br RECIFE, Fevereiro/2011

2 Universidade Federal de Pernambuco Centro de Informática Pós-graduação em Ciência da Computação Namedin Pereira Teles Júnior Backup Markup Language (BKPML): Uma Proposta para Interoperabilidade e Padronização de Backup de Dados Trabalho apresentado ao Programa de Pós-graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco como requisito parcial para obtenção do grau de Mestre em Ciência da Computação. Orientador: Roberto Souto Maior de Barros RECIFE, Fevereiro/2011

3 Catalogação na fonte Bibliotecária Jane Souto Maior, CRB4-571 Teles Júnior, Namedin Pereira Backup markup language (BKPML) : uma proposta para interoperabilidade e padronização de backup de dados / Namedin Pereira Teles Júnior - Recife: O Autor, xxiv, 107 p. : il., fig., tab. Orientador: Roberto Souto Maior de Barros. Dissertação (mestrado) Universidade Federal de Pernambuco. CIn. Ciência da Computação, Inclui bibliografia. 1. Sistemas de gerenciamento de banco de dados. 2. Sistemas distribuídos de backup. I. Barros, Roberto Souto Maior de (orientador). II. Título CDD (22. ed.) MEI

4

5 Dedico essa dissertação em memória do meu avô Secundino Rocha.

6 Agradecimentos A Deus, por ter me dado saúde e força para proseguir com meus objetivos. E enquanto estive morando em Recife, ajudou-me a suportar toda saudade de minha família em Manaus, pondo em meu caminho pessoas maravilhosas e acolhedoras. A minha mãe, Shirley, pelo grande incentivo e carinho demonstrado durante toda minha vida. A minha esposa, Nívia, pelo apoio, quando morei em Recife, deixando-a em Manaus, pela compreensão ao chegar e dedicar meu tempo exclusivamente ao desenvolvimento deste trabalho, e ao grande amor que nos uniu nesta etapa de nossas vidas. Ao professor e orientador, Roberto, por me orientar sabiamente, me pondo no caminho certo quanto ao desenvolvimento deste trabalho. Pela confiança depositada ao me liberar e concordar em me orientar a distância, e por todo tempo a mim dedicado. A minha irmã, sobrinho e cunhado, Nádia, Cesar e Nailton, pelo incentivo, cuidados e ajuda dada em todos os momentos da minha vida, por me apoiarem em decisões importantes e estarem ao meu lado sempre que precisei. Aos integrandes e amigos do CIN, mais especificamente Jair, Emmanuel, Dalasiel, Rebeca, Marco, Jeisa, Felix, Ademir, Rafael e Crescêncio, e todas as pessoas que participaram de forma direta ou indireta desta conquista. Aos moradores do condomínio Laranjeiras, por me receberem, não só como um amigo, mas como parte integrante de cada família que lá vive, em especial, Antonieta, Gabriel, Tiazinha, Márcia, Ana, Joel e família, Vitória e família. À Universidade Federal de Pernambuco, professores e funcionários que ajudam a manter a universidade limpa e organizadas para os alunos e pesquisadores. A todos que fizeram desta minha luta uma experiência de vida valiosa. vi

7 "O sucesso é um professor perverso. Ele seduz as pessoas inteligentes a as faz pensar que jamais irão cair." BILL GATES (Pensamento)

8 Resumo O atual modelo de negócios de uma empresa moderna está cada vez mais dependente das tecnologias e dos sistemas de informação. Com isso, é necessário que se mantenha os dados protegidos através de uma cópia segurança, conhecida como backup, que garantirá a restauração e migração dos dados quando necessário. Além disso, é comum uma empresa adotar mais de um Sistema de Gerenciamento de Banco de Dados (SGBD) para armazenamento dos dados, gerando ambientes heterogêneos e dificultando a interoperabilidade entre os sistemas quando necessário. Isso porque os SGBD existentes realizam backup, restauração e migração dos dados sob tecnologias específicas e limitadas como (Oracle, Sqlserver, Mysql), não permitindo a restauração dos dados em outros SGBD, somente no seu ambiente de origem. Nesse contexto, este trabalho propõe o desenvolvimento de uma estrutura padrão para os arquivos de backup, utilizando a linguagem de marcação extensible Markup Language (XML), denominada como Backup Markup Language (BKPML). A BKPML tem por objetivo desvincular a dependência dos arquivos de backup de sua fonte de origem, possibilitando manter a interoperabilidade necessária entre SGBD heterogêneos através dos arquivos de backup, e a transformação dos dados para arquivos secundários, como TEXTO, EXCEL, JavaScript Object Notation (JSON), YAML Ain t Markup Language (YAML), Comma-Separated Values (CSV) e XML. Para isso, foi necessário o desenvolvimento de uma ferramenta responsável por administrar os arquivos BKPML gerados. Como proposta de armazenamento seguro, além do armazenamento local, este trabalho utiliza Cloud Computing como alternativa para armazenamento dos arquivos BKPML. Palavras-chave: Ambientes Heterogêneos, Interoperabilidade, Padronização, XML, Sistemas de Gerenciamento de Banco de Dados (SGBD), Backup, Restauração, Migração e Cloud Computing. viii

9 Abstract The current business model of a modern business is increasingly dependent on technology and information systems. Thus, it is necessary to keep data protected by a security copy, known as backup, which will ensure the restoration and migration of data when needed. Furthermore, it is common for a company to adopt more than one Database Management System (DBMS) for data storage, creating heterogeneous environments and hindering the interoperability between the systems when needed. This happens because the existing DBMSs perform backup, restore and data migration under specific and limited platforms such as Oracle, SQLServer, MySQL, not allowing the restoration of data in other database systems, only in its original environment. In this context, this work proposes to develop a standard framework for the backup files, using the Extensible Markup Language (XML), known as Backup Markup Language (BKPML). The BKPML aims to relieve the dependence of the backup files from their sources, enabling the interoperability required between heterogeneous database systems through the backup files, and the processing using data for secondary files as text, Excel, JavaScript Object Notation (JSON), YAML Ain t Markup Language (YAML), commaseparated values (CSV) and XML. This lead us to the development of a tool responsible for managing generated BKPML files. As a proposal for the safe storage, in addition to local storage, this work uses cloud computing as an alternative to BKPML files storing. Keywords: Heterogeneous Environments, Interoperability, Standards, XML, DBMS, Backup, Restore, Migration and Cloud Computing. ix

10 Sumário Lista de Figuras Lista de Tabelas Lista de Abreviaturas xiii xv xvi 1 Introdução Motivação Breve Histórico da evolução da TI Objetivo da dissertação Objetivos específicos Estrutura da dissertação Referencial Teórico Backup de dados Tipos de mídia para backup de dados Segurança dos dados Criptografia dos dados Algoritmo triple des (3DES) Migração de dados Níveis de migração Computação nas nuvens Backup de dados em nuvens Aplicações cloud para backup/recuperação de dados Padronização da informação extensible Markup Language (XML) XML Schema YAML Ain t Markup Language (YAML) JavaScript Object Notation (JSON) Aplicações WEB Tecnologias Web Padrões de projeto O padrão estrutural Decorator O padrão comportamental Strategy x

11 2.6.3 O padrão Data Access Object (DAO) O padrão Model View Controller (MVC) Considerações Finais Backup Markup Language (BKPML) Introdução Apresentação da estrutura BKPML O elemento SchemaDB O elemento Objects Estrutura dos objetos da BKPML O elemento complexo tableobjecttype O elemento complexo indexobjecttype O elemento complexo viewobjecttype O elemento complexo grantobjecttype O elemento complexo triggerobjecttype O elemento complexo methodobjecttype Considerações Finais A Ferramenta: Backup Markup Language Manager (BKPML Manager) Introdução Arquitetura da ferramenta BKPML Manager A camada Cliente Lições Aprendidas A camada Servidor Lições Aprendidas A Camada SGBD Padrões de projeto utilizados Aplicando o padrão Data Access Object (DAO) Aplicando o padrão Decorator Aplicando o Padrão de projetos Strategy Aplicando o Padrão de projetos Model View Controller (MVC) Funcionalidade da BKPML Manager Considerações finais Estudo de caso Apresentação da empresa e domínio do problema xi

12 5.2 Preparando o ambiente para execução do backup Cadastrando as ações de backup Executando o Backup dos dados Preparando o ambiente de restauração e migração Restaurando e transformando os arquivos BKPML Migrando os arquivos BKPML de objetos complexos Testando a eficiência x volume de informação Considerações finais Conclusões e Trabalhos Futuros Conclusões e contribuições Limitações e trabalhos futuros Bibliografia 99 xii

13 Lista de Figuras 2.1 Principais erros que levam a perda de dados Componentes Envolvidos na Criptografia Processo de criptografia Arquitetura da Computação nas nuvens Documento XML Documento XMLSchema Documento XML para YAML Documento JSON Diagrama de Classes do padrão Decorator Diagrama de Classes do padrão Strategy Diagrama do Padrão DAO Representação em árvore da estrutura BKPML Estrutura principal da BKPML Tipo complexo TableObjectType Tipo complexo IndexObjectType Tipo complexo viewobjecttype Tipo complexo GrantObjectType Tipo complexo TriggerObjectType Tipo complexo MethodObjectType Tela principal da BKPML Manager Ciclo de vida dos processos de Backup/Restore da ferramenta BKPML Manager Menu da BKPML Manager Arquitetura da BKPML Manager Padrão DAO da BKPML Manager Padrão Decorator da BKPML Manager Instanciando uma classe backup/restore Aplicando o padrão decorator a um objeto backup Padrão Strategy da BKPML Manager Arquitetura MVC Diagrama de Caso de Uso da BKPML Manager Etapa 3 do processo de preparação do ambiente xiii

14 5.2 Etapa 4 do processo de preparação do ambiente Tela de cadastro de Ações Tela de execução de backup de dados Documento BKPML TBL_CURSO Documento BKPML TBL_EMENTA Documento BKPML TBL_SERVICOS Documento BKPML IDX_BY_DATA_COURSE Documento BKPML FNC_INSERIR_CURSO Documento BKPML FNC_DELETAR_CURSO Documento BKPML FNC_ALTERAR_SERVICOS Documento BKPML PRC_LISTAR_EMENTA Documento BKPML VEW_CURSO_EMENTA Documento BKPML TRG_EXCLUIR_EMENTA Tela de Restauração de dados Restauração dos dados no postgres Objeto TBL_EMENTA em formato CSV Objeto TBL_CURSO em formato Excel Objeto TBL_EMENTA em formato JSON Objeto TBL_SERVICOS em formato YAML Tela de Migração de dados Sintaxe padrão para objetos tipo função Sintaxe padrão para objetos tipo gatilho Resultado da Migração para o ORACLE Express xiv

15 Lista de Tabelas 5.1 Objetos do estudo de caso Geração dos arquivos BKPML por volume e tempo xv

16 Lista de Abreviaturas BKPML CORBA CSS CSV DAO DBMS DCOM DSAAS DTD GML HTML HTTP IAAS IBM JDBC JSF JSON JSP JSTL JVM MathML MVC Backup Markup Language Common Object Request Broker Architecture Cascading Style Sheets Comma-Separated Values Data Access Object Database management system Distributed Component Object Model Data Storage As A Service Document Type Definition Generalized Markup Language Hypertext Markup Language Hypertext Transfer Protocol Infrastructure As A Service International Business Machine Java DataBase Connection Java Server Faces JavaScript Object Notation JavaServer Pages Javaserver page Standard Tag Lib Java Virtual Machine Mathematical Markup Language Model View Controller xvi

17 PAAS RMI S3 SAAS SGBD SI SQL SVG TI UML W3C XBRL XML XSIL YAML Platform As A Service Remote Method Invocation Simple Storage Service Software As A Service Sistemas de Gerenciamento de Banco de Dados Sistema de Informação Structured Query Language Scalable Vectorial Graphics Tecnologia da Informação Unified Modeling Language World Wide Web Consortium extensible Business Reporting Language extensible Markup Language extensible Scientific Interchange Language YAML Ain t Markup Language xvii

18 1 Introdução As novas demandas e a competitividade do mercado criam uma grande expectativa e necessidade a respeito da aplicação da Tecnologia da Informação (TI). Contudo, há também um grande questionamento sobre as reais vantagens da utilização da TI em relação aos problemas e limitações encontrados nessa área de conhecimento. Para avaliar os impactos da TI nas operações e estratégias das empresas, faz-se necessário uma prévia apresentação sobre a evolução das tecnologias e sistemas de informação, o impacto da mudança de paradigma envolvida, bem como os principais fatores que tendem a aumentar o grau de fracasso ou de sucesso na implantação de soluções de TI. Este capítulo tem por objetivo apresentar as principais problemáticas que motivaram o desenvolvimento deste trabalho, bem como a solução proposta para tais problemas. 1.1 Motivação Para atender um mercado cada dia mais exigente, empresas e organizações estão tornando mais comum, em seus modelos de negócio, a utilização da tecnologia da informação em diversas áreas da empresa, com objetivo estratégico e organizacional. De acordo com Turban et al. (2002), um modelo de negócios é um método pelo qual a empresa consegue agir para gerar lucro e sustentar-se. Esse modelo explica detalhadamente como a empresa agrega valor, quais são os consumidores dispostos a pagar por seus produtos, e qual a melhor forma de gerir seus negócios para atender o mercado. Nesse novo modelo de negócios, as informações passam a ser o centro de todo processo empresarial. Martens (2001) comenta que o sucesso empresarial passa a depender fundamentalmente da capacidade da empresa organizar e administrar sua base de informações, e aproveitar ao máximo as diferenciações competitivas oferecidas pela TI. É inegável que a TI esteja cada dia mais presente nos ambientes empresariais. Nota- 1

19 1.1. MOTIVAÇÃO se que recentes avanços na informática como Internet, novas interfaces gráficas, Business to Business, e-commerce e Enterprise Resource Planning estão se tornando mais comuns e necessárias no cotidiano e diálogos empresariais (Terra, 2005). Para as empresas, na visão de Quinn et al. (1997) e Terra (2005), a TI, ou mais especificamente o Sistema de Informação (SI), passa a ser considerado o elemento central do processo inovador, capaz de diminuir, unir e eliminar várias de suas etapas. O uso intensivo de software permite trazer a interação com clientes para um patamar bem mais elevado de qualidade, serviço e personalização, além de permitir a detecção de macro tendências com extrema velocidade. Nesse novo paradigma, os SI deixam de ser simples aplicativos com objetivo de armazenar e recuperar informação, e passam a se tornar poderosas ferramentas para análise e mineração de dados, tornando as informações o principal fator para que uma empresa possa acompanhar essas mudanças. Esse modelo faz com que a segurança da informação transforme-se na chave para manter a continuidade dos negócios e a integridade dos dados. Apesar da grande importância da informação para as empresas, ainda existem empresas que decidem manter a economia financeira em detrimento da segurança dos dados, e não investem em soluções de hardware, software ou recursos humanos para mantê-los protegidos. Um estudo, realizado em maio de 2009 com mais de 1600 empresas de 24 países, mostrou que no Brasil houve um prejuízo de US 297 mil pela perda de dados corporativos (Pernambuco, 2009). Dentre as soluções para Segurança da Informação estão o backup (cópia de segurança) e a restauração dos dados. Chen and Zheng (2008) explicam que aplicações famosas para backup e recuperação de dados possuem um custo elevado, o que deixa empresas de pequeno e médio porte sem muitas alternativas para segurança dos seus dados. A adoção de ferramentas Open Source é uma opção para tentar baixar o custo, mas, dependendo do modelo de negócios adotado, a utilização total de ferramentas Open Source pode não atender ao plano de continuidade de negócio adotado. A cópia de segurança em computadores é um instrumento importante para compensar ou tentar sanar problemas oriundos de hardware, software, erros humanos ou segurança dos dados. Em empresas que dependem fortemente dos sistemas e dos computadores, a perda dos dados pode representar perda de capital. Trazendo essa realidade para a vida cotidiana, na qual o computador é usado como ferramenta de trabalho, perder dados significa perder tempo, perdendo tempo, perdese dinheiro e, por conseguinte, o cliente. Chen and Zheng (2008) comentam que toda 2

20 1.2. BREVE HISTÓRICO DA EVOLUÇÃO DA TI empresa deve possuir um plano de backup e restauração de dados, pois suas operações do dia-a-dia podem gerar uma quantidade considerável de dados, que estão sujeitos a danos lógicos e físicos. Além de manter os dados seguros e íntegros, os arquivos de backup, quando vistos de forma analítica, contribuem para comunicação e troca de informação recíproca entre sistemas legados de uma empresa. Turban et al. (2002) define sistemas legados como sistemas antigos, normalmente desenvolvidos por diferentes fornecedores, utilizando diferentes tecnologias, feitos para atender áreas distintas (administrativa, financeira, contábil, entre outros), e que hoje se tornaram a principal fonte de importantes informações para muitas empresas. A grande problemática com sistemas legados é a dispersão da informação entre diversas tecnologias, o que normalmente compromete a interoperabilidade ou a troca de informação entre diversos sistemas. Para possibilitar o backup e restauração de dados, os Sistemas de Gerenciamento de Banco de Dados (SGBD) disponibilizam ferramentas específicas que apresentam limitações quanto a impossibilidade de troca de informação entre SGBD distintos, visto que cada SGBD realiza backup e restauração dos dados com suas tecnologias específicas e nativas. Como exemplos podem ser citados Oracle (Oracle, 2005), Sqlserver (SQLServer, 2011), Mysql (MYSQL, 2010) e Postgres (Postgres, 2011). Tal limitação impede a interoperabilidade dos dados e recursos entre SGBD. Para melhor entendimento sobre a origem dos sistemas legados, bem como as problemáticas geradas por ele, os tópicos a seguir destinam-se a apresentar um breve histórico sobre a evolução da TI e, por fim, apresentar um breve resumo sobre a solução proposta para o problema em questão. 1.2 Breve Histórico da evolução da TI Cronologicamente, a TI teve início da década de 60, contribuindo de forma progressiva nas áreas empresariais, transporte, rádio, televisão, entre outras de grande importância para a sociedade. Nessa década, segundo Rezende (2002), conhecida como ERA DO PROCESSA- MENTO DE DADOS, todos os recursos eram direcionados para processamento centralizado, realizado por grandes computadores, denominados MAINFRAMES, responsáveis por processar informações de folhas de pagamento, contabilidade e finanças, de forma mecanizada. Esses novos recursos, além de reduzir o tempo de trabalho em dias ou até 3

21 1.2. BREVE HISTÓRICO DA EVOLUÇÃO DA TI mesmo meses, tornaram-se a principal fonte de importantes informações para as empresas. A partir da década de 70 a 80, esses sistemas ficariam conhecidos como sistemas legados, responsáveis pelo início de inúmeras pesquisas sobre comunicação transparente entre sistemas legados (Turban et al., 2002). A década de 70, também conhecida como Era dos sistemas de apoio à decisão, apresenta sistemas que passam a ser um fator vantajoso quanto à concorrência de mercado. Os terminais passam a se tornar flexíveis e com poder de processar diversas tarefas simultaneamente com diversos usuários. A maior evolução técnica dessa época foi a transferência dos dados para SGBD e a utilização da Generalized Markup Language (GML), criada pela International Business Machine (IBM) para armazenamento de grandes quantidades de informação de diversos temas. Foi a partir da GML que surgiu a ideia de padronização de documentos. A partir da década de 80, o termo Processamento de Dados foi perdendo força e abrindo espaço ao termo Tecnologia da Informação. TI tornou-se o termo aceito para englobar a rápida expansão de equipamentos (computadores, dispositivos de armazenamento de dados, redes e dispositivos de comunicação), aplicações e serviços utilizados pelas organizações para fornecer dados, informações e conhecimento (Laurindo, 2000). Em uma definição mais restrita, TI diz respeito ao aspecto tecnológico de um Sistema de Informação (SI) (Turban et al., 2002). Ela inclui hardware, banco de dados, software, redes e outros dispositivos. A TI evoluiu de uma orientação tradicional de suporte administrativo para um papel estratégico dentro da organização. Ela não só sustenta as estratégias de negócios existentes, mas também permite viabilizar novas estratégias empresariais e oportunidades de negócio (Laurindo, 2000). Foi nesta época que os sistemas legados passaram a tornar-se uma preocupação para as empresas. Sistemas que antes centralizavam processamento, agora passam a distribuir e trocar informações com outros sistemas. A questão levantada nessa época foi: Como manter a interoperabilidade entre os novos sistemas e os mais antigos?. A partir desse questionamento, foi dado início a inúmeras pesquisas sobre interoperabilidade entre sistemas legados. O conceito de gestão dos dados e informação surgiu na década de 90, compreendendo atividades como: armazenamento, recuperação e níveis de controle e acesso à informação. Ele intensifica a criação de um plano de contingência e segurança dos dados, além de ver os dados como a principal fonte de apoio a decisões empresarias. Os sistemas estratégicos têm sido vistos como uma melhoria para a competitividade das 4

22 1.3. OBJETIVO DA DISSERTAÇÃO empresas, através do aumento de produtividade, melhorias no trabalho em equipe e comunicação entre empresas, fornecedores e clientes. Segundo REINHARD (1996); Brito et al. (1997); Voas and Zhang (2009), as constantes mudanças ocorridas na TI, aconteceram de acordo com as necessidades, sejam elas voltadas ao aspecto empresarial, ou sob qualquer outra necessidade, ou até mesmo pela realização de grandes e significativos investimentos em novos produtos, serviços e processos fundamentados e apoiados por tecnologias. Além disso, pode-se vincular esse impulso de mudanças às problemáticas oriundas das décadas supracitadas. 1.3 Objetivo da dissertação Em virtude dos problemas relacionados à interoperabilidade entre SGBD no que tange o backup e restauração de dados, este trabalho propõe a padronização de uma estrutura, utilizando a linguagem de marcação XML (Ray, 2006), denominada Backup Markup Language (BKPML), cujo objetivo é desvincular a dependência dos arquivos de backup de sua fonte de origem, possibilitando manter a interoperabilidade necessária entre SGBD heterogêneos através dos arquivos de backup. A possibilidade de migrar os dados para bases heterogêneas a partir de arquivos de backup é algo que vem influenciar de forma positiva os processos de migração, pois, desta forma, os backups de dados originados em um SGBD A poderiam facilmente ser restaurados em um SGBD B. A solução proposta almeja que o backup e restauração dos dados possam ser realizados de forma transparente, e até mesmo a possibilidade de migrar os arquivos de backup (BKPML) para arquivos secundários em formato Texto, extensible Markup Language (XML), YAML Ain t Markup Language (YAML) (YAML, 2010), Comma-Separated Values (CSV) (Creativyst, 2011) e Excel (Microsoft, 2010). Existem três fatores que justificam o desenvolvimento tecnológico deste projeto: Problemas relacionados com dados mantidos em ambientes heterogêneos que tornam difícil a troca de informação e a migração dos dados para outros sistemas. Existem inúmeros motivos pelos quais as empresas precisam migrar os dados: redução dos altos custos com armazenamento de dados em tecnologias proprietárias, obter padronização dos dados em uma tecnologia específica, atualização de tecnologias ou incompatibilidade entre sistemas de banco de dados; e Migrar dados para bases heterogêneas a partir de arquivos de backup é algo que 5

23 1.4. OBJETIVOS ESPECÍFICOS pode influenciar de forma positiva em um processo de migração, pois desta forma os dados não precisariam ser restaurados em sua base de origem para então serem transferidos para a base de destino. O foco da pesquisa proposta está na solução de interoperabilidade entre diferentes plataformas de SGBD. Hoje, os arquivos de backup de dados são gerados baseados em formatos proprietários (Oracle, Sqlserver, Mysql, Postgres, entre outros), e seu principal objetivo está no armazenamento, segurança e restauração das informações apenas em seus ambientes de origem, não podendo ser restaurados em outros ambientes. Atualmente, a interoperabilidade está em estágio pouco avançado. Poucas são as ferramentas que conseguem interagir com outras para a realização de transações. A padronização da estrutura de arquivos de backup não é algo relativamente novo. Oumtanaga et al. (2007) propõe a utilização de um formato XML como modelo para backup de dados. A estrutura proposta foi desenvolvida utilizando Document Type Definition (DTD) (Ray, 2006), que é uma tecnologia mais antiga e limitada para definição de estruturas em XML. No artigo supracitado, podem-se citar desvantagens quanto ao desenvolvimento e uso de certas tecnologias: sintaxe não XML, poucos tipos de dados, limitação na definição de cardinalidade e baixo poder de expressão. Além disso, a proposta foca a migração apenas de objetos tabela, não garantindo a migração de objetos como: visões, gatilhos, permissões e funções. A BKPML propõe a migração dos principais objetos existentes em um esquema de banco de dados. Por se tratar de uma nova linguagem de marcação, a BKPML necessitará de uma aplicação para gerar, restaurar, validar e migrar os dados a partir desses arquivos. 1.4 Objetivos específicos Apresentar os principais conceitos sobre padronização da informação, interoperabilidade de dados, ambientes heterogêneos, backup, migração e segurança da informação; Definir e apresentar uma linguagem para criação e validação das regras sintáticas para os documentos XML como XML Schema; Definir as regras para criação e validação da estrutura do arquivo BKPML; 6

24 1.5. ESTRUTURA DA DISSERTAÇÃO Desenvolver a aplicação responsável por criar, validar e gerenciar os arquivos BKPML; Definir um ambiente de testes; Realizar os testes da aplicação e ajustes da mesma para atingir os objetivos propostos. 1.5 Estrutura da dissertação Como ponto de partida, o Capítulo 2 apresenta a fundamentação teórica desta dissertação, que consiste em uma rápida apresentação sobre os principais conceitos a serem tratados nesta dissertação como: backup e restauração de dados, segurança dos dados, padronização da informação e cloud computing, conceito esse que será abordado nesta dissertação como meio de armazenamento dos backups de dados. O Capítulo 3 consiste em apresentar a estrutura BKPML, que tem por objetivo manter os dados em um formato padrão, dando assim mobilidade aos arquivos de backup, e possibilitando que os mesmos sejam migrados para qualquer SGBD independente de qual SGBD foram originados. No Capítulo 4 é apresentada a arquitetura e são descritas as tecnologias utilizadas para o desenvolvimento da aplicação denominada BKPML Manager, aplicação responsável por gerar, validar, armazenar, restaurar e migrar os dados contidos nos arquivos BKPML para SGBD distintos. O Capítulo 5 apresenta um estudo de caso de uma empresa de pequeno porte de Manaus, utilizando a ferramenta BKPML Manager para gerar e restaurar dados de um SGBD para outro, apresentando os resultados obtidos nos testes realizados para este estudo de caso. Por fim, no Capítulo 6, apresentam-se as conclusões do trabalho, discutindo sua aplicabilidade, abrangência, as condições em que se pode ser usado, suas vantagens, limitações e também discussão sobre possíveis futuras melhorias a respeito da estrutura BKPML e da aplicação BKPML Manager. 7

25 2 Referencial Teórico Este capítulo tem por objetivo abordar os principais conceitos fundamentais para o desenvolvimento deste trabalho. O capítulo se inicia abordando os conceitos básicos de backup de dados, abrangendo aspectos importantes como, segurança de dados e criptografia de arquivos. Em seguida, este capítulo tratará conceitos sobre, migração de dados, computação nas nuvens, padronização da informação, entre outros conceitos de grande importância para o entendimento deste trabalho como um todo. 2.1 Backup de dados Backup é uma palavra em inglês que significa cópia de segurança de um dispositivo de armazenamento (sistema operacional, banco de dados, sistemas administrativos, entre outros.) a outro para que possam ser restaurados em caso de perda dos dados originais. É cada vez maior o número de empresas, organizações e usuários que perdem anos de vida através da perda de dados importantes, sejam estes causado por desastres lógicos, físicos ou fatores humanos. AGUIRRE et al. (2006) relata que cerca de 90 porcento das empresas de pequeno porte não realizam regularmente o backup de segurança dos dados, o que resulta na perda de renda, produtividade e clientes. As causas mais comuns em relação à perda dos dados, segundo AGUIRRE et al. (2006); Packard (2010), é o mau funcionamento ou falhas nos equipamentos de hardware e as falhas humanas, como, exclusão ou alteração acidental de dados ou arquivos, instalação de softwares, roubo de informação, além de incêndio ou desastres naturais, entre outros. A Figura 2.1 mostra os resultados de uma pesquisa realizada em 2002 sobre os principais problemas relacionados à perda de dados corporativos. 8

26 2.1. BACKUP DE DADOS Figura 2.1 Principais erros que levam a perda de dados (Packard, 2010) Tipos de mídia para backup de dados Fazer cópia de segurança dos dados não necessariamente significa que seus dados estão totalmente protegidos contra danos ou catástrofes. Além da realização do backup dos dados, é necessário definir o melhor tipo de dispositivo de armazenamento a ser utilizado para manter essas cópias de segurança. A escolha da mídia correta varia de acordo com local a ser armazenado tais mídias, no mais é aconselhado que além da escolha da mídia correta, é preciso manter essas mídias em locais seguros, de acesso restrito e com menor probabilidade de danos e fatores de risco. As mídias mais utilizadas para cópias de segurança de dados são as seguintes (Fialho, 2007): Fitas - Também conhecidas como fitas streaming ou DAT. São pequenas e suas unidades podem ser instaladas tão fácil quanto as de disquete, CD, DVD, entre outros; Discos - É o meio mais comum utilizado nos dias de hoje; sua capacidade de armazenamento é de 750 MB ou superior a terabytes. Pen Driver - São dispositivos bastante seguros, rápidos e práticos. Usados comumente para armazenar temporariamente os dados; e 9

27 2.1. BACKUP DE DADOS Em nuvens - O armazenamento em nuvens é um novo meio para armazenamento de dados de forma remota. Para acesso a esse serviço, o cliente deverá contratar o mesmo mediante empresa prestadora, como por exemplo: Amazon Web Services (Amazon, 2011) e Locaweb (Locaweb, 2011). Independente do dispositivo de armazenamento utilizado, é importante considerar a importância da cópia de segurança dos dados para continuidade dos negócios de uma empresa. No Brasil está se tornando comum a utilização da Internet como um meio para compra, pagamento e solicitação de serviços. Além das inúmeras formas de armazenamento de dados, os backups de dados são divididos em diferentes tipos, para atender a diferentes necessidades. Após determinar qual o tipo de dispositivo de armazenamento utilizar, deve-se determinar que tipo de backup será utilizado. As ferramentas de backup mais utilizadas, disponibilizam opções para definir os seguintes tipos de backup: Normal, Incremental, Diferencial, Cópia e Diário. O controle sobre o tipo de backup realizado é feito pela ferramenta utilizada (Cardia, 2010; Petkovic, 2008). Backup Normal - Todos os dados do SGBD são copiados, todo backup se inicia com um backup normal, que também é conhecido como backup total. Backups normais são demorados e exigem mais capacidade de armazenamento do que qualquer outro; Backup Incremental - Backups incrementais são os tipos mais rápidos e de menor tamanho. Entretanto, eles são eficientes como conjuntos de recuperação, porque para restauração deve-se primeiro recuperar o normal e em seguida o incremental; e Backup Diferencial - tendem a ser maiores e mais demorados do que os backups incrementais. Quanto à restauração, deve-se restaurar primeiro o normal e em seguida o diferencial mais recente. Os tipos de backup supracitados são normalmente aplicados a backups de sistemas operacionais, no qual se envolve um grande número de arquivos e informações sobre tal. Além desses tipos, pode-se citas os tipos utilizados por ferramentas para backup de dados armazenados em SGBD. Eles são (Oracle, 2005; MYSQL, 2010). Backup Lógico e Físico - É uma cópia dos arquivos de armazenamento de um SGBD para outro local, seja em disco ou armazenamento off-line, como fita. Bac- 10

28 2.1. BACKUP DE DADOS kup lógico contém os dados lógicos de um SGBD, como: tabelas, visões, índices, procedimentos, entre outros; Backup Online e Offline - a diferença entre backup online e off-line está no momento de sua execução. Backup online é realizado enquanto o SGBD está sendo executado. Backup off-line é executado enquanto o servidor do SGBD está parado. Tais backups também são conhecidos como quente e frio; e Backup Local e Remoto - Uma cópia de segurança local é feita na mesma máquina onde o SGBD é executado. Já um backup remoto é feito em um servidor não local. Para alguns tipos de backups, o backup pode ser iniciado a partir de um servidor remoto e gravado em um servidor local. Além dessas características, um arquivo de backup deve possuir uma característica fundamental para segurança e integridade dos dados: a utilização de criptografia dos dados mantidos pelo backup. Existem inúmeros algoritmos para criptografia de dados, tanto de 64 quanto de 128 bits, o que garante ainda mais a segurança e integridade dos dados (Packard, 2010) Segurança dos dados A segurança dos dados é um conjunto de técnicas, processos e componentes que visa garantir certo nível de confiabilidade às transações digitais. A ferramenta que proporciona e garante o nível de confiabilidade requerida é a proteção. O que se visa é proteger o valor da informação. Esse valor depende de três princípios básicos: confidencialidade, integridade e disponibilidade dos dados (CARUSO and STEFFEN, 1999; van Bon, 2006). Confidencialidade - Proteção das informações contra o acesso e uso não autorizados; Integridade - precisão, inteireza e pontualidade das informações; e Disponibilidade - as informações devem ser acessíveis em qualquer ocasião acordada. Essa acessibilidade depende da continuidade proporcionada pelos sistemas de processamento das informações. 11

29 2.1. BACKUP DE DADOS Criptografia dos dados Uma solução adotada para proteção dos dados é a utilização de criptografia. De acordo com CARUSO and STEFFEN (1999), criptografia é um processo matemático usado para embaralhar os dados, ou a ciência e a arte da transformação de mensagens tornandoas seguras e imunes a ataques. A Figura 2.2 mostra os componentes envolvidos na criptografia (FOROUZAN, 2004). Figura 2.2 Componentes envolvidos na criptografia (FOROUZAN, 2004) Antes de ser criptografada, uma mensagem é denominada como texto limpo. Após ser criptografada, passa a ser conhecida como texto cifrado. Um algoritmo de cifragem é responsável por tal transformação. O processo reverso é feito através de um algoritmo de decifragem, responsável por transformar o texto cifrado em um texto claro. O transmissor utiliza um algoritmo de cifragem, enquanto o receptor um algoritmo de decifragem (FOROUZAN, 2004). Processos de criptografia e descriptografia utilizam a técnica de cifras públicas, que utiliza chaves secretas para criptografar ou descriptografar mensagens. Para criptografar uma mensagem, faz-se necessário o uso de um algoritmo de criptografia, uma chave e uma mensagem limpa. Desse conjunto origina-se o texto criptografado. Para descriptografar essa mensagem, precisa-se de um algoritmo de descriptografia, a chave utilizada na criptografia e a mensagem. Esse conjunto revela a mensagem original. A Figura 2.3 ilustra a idéia (FOROUZAN, 2004). Os algoritmos de cifragem e decifragem são públicos, podem ser usados por qualquer um. As chaves são secretas, precisam ser protegidas Algoritmo triple des (3DES) É o principal algoritmo de criptografia utilizado comercialmente por aplicações na Internet. O algoritmo triple DES usa chaves de 168 bits. Esse algoritmo é uma extensão 12

30 2.2. MIGRAÇÃO DE DADOS Figura 2.3 Processo de criptografia (FOROUZAN, 2004) do algoritmo DES. Triple ou três significa que esse algoritmo é três vezes mais pesado e mais seguro que o DES, porque criptografa as mensagens três vezes seguidas, usando o DES. Então, em suma, ele usa três chaves diferentes de 56 bits, que combinadas, resultam em uma chave de 168bits. O Triple DES é utilizado em diversos aplicativos da Microsoft (CARUSO and STEFFEN, 1999; Carmona, 2005). 2.2 Migração de dados Migração de dados é o processo de transferência de informação de uma base de dados para outra, com finalidade de economizar recursos e melhoria de controle e desemprenho. Existem muitos motivos que levam uma empresa a decidir sobre a migração de dados para tecnologias de gerenciamento de dados mais atuais. Antes de migrar, uma empresa deve escolher cuidadosamente a tecnologia que atenda às necessidades atuais e futuras da empresa. Todos os projetos de migração embutem certo nível de risco. Entretanto, um projeto de migração bem planejado e corretamente executado pode fazer com que a empresa proporcione acesso aos dados sem problemas (STERN, 2010). Existem inúmeras razões que levam uma empresa a optar pela migração de dados (IBM, 2010). Dentre elas: Simplificação da infra-estrutura - Ao simplificar a arquitetura de TI e integrar todos os componentes em uma só solução, pode-se economizar recursos e melhorar o controle; Redução de Custos - Hoje, a maioria das companhias que se expõem à possibilidade de migrar, escolhe estratégica e proativamente aumentar o valor do negócio, vinculando os objetivos da empresa com a infra-estrutura de TI. Migrar para outras tecnologias pode proporcionar soluções de impacto que oferecem grande flexibilidade e liberdade de escolha; 13

31 2.2. MIGRAÇÃO DE DADOS Melhorar rendimento das aplicações - Permite que os clientes desfrutem de um melhor serviço e que a equipe de TI administre melhor os sistemas e responda aos objetivos do negócio com maior eficácia; Gestão dos dados - migração de dados para melhores servidores com melhor capacidade de gerir dados sem comprometer a confiabilidade dos mesmos; e Reduzir complexidade e melhoria de gestão - A dificuldade em gerir e adaptarse a certas tecnologias obriga muitas empresas a abandonar e migrar para outras de melhor gestão. Ao migrar dados, existem diversos fatores a serem considerados. Em primeiro lugar, a empresa deve decidir o tipo de migração. Gateway ou migração completa. Na migração com gateway, os dados continuam no banco de dados antigo e são acessados através de um software especial denominado gateway. O gateway lê e grava os dados no SGBD antigo. Mas, do ponto de vista do aplicativo, é como se os dados estivessem no SGBD atual. Por esse motivo os gateways são normalmente lentos. Na migração completa, os dados, objetos e o código fonte do aplicativo são convertidos para acessar os dados do novo SGBD. Uma vez que este tipo de migração seja feito, todas as referências ao SGBD antigo são perdidas. Esse é o tipo de migração mais comum, mas cabe ressaltar que existem outras alternativas além da migração completa Níveis de migração A migração de dados é classificada em três níveis. Esses níveis determinam a quantidade de trabalho e os elementos envolvidos na migração. Por simplicidade, neste trabalho nos referimos aos três níveis simplesmente como nível um, dois e três (STERN, 2010). Nível 1 - Uma migração de nível 1 inclui apenas o esquema, ou definições de dados, e os dados em si. O cenário mais comum para uma migração de nível 1 é quando o aplicativo está usando uma interface que existe tanto no sistema de banco de dados antigo quanto no novo. É necessário migrar somente as definições de dados e os dados em si. São também necessários trabalhos de configuração, mas, uma vez que os dados tenham sido migrados, o aplicativo estará funcionando; Nível 2 - Uma migração de nível 2 inclui o esquema, os dados e alterações no código fonte. Este nível pode ser visto como uma extensão do nível 1. Por exemplo, 14

32 2.3. COMPUTAÇÃO NAS NUVENS em uma migração de nível 1 onde são usadas diferentes versões da mesma interface no banco de dados antigo e no novo. Neste caso, migrar apenas o esquema e os dados não faz com que o aplicativo funcione completamente; é necessário analisar as diferenças entre as versões. Uma vez que essas diferenças tenham sido identificadas, pode-se alterar o código para que o aplicativo funcione com o sistema de banco de dados novo; e Nível 3 - Uma migração de nível 3 é bastante diferente dos dois níveis anteriores. Nos níveis anteriores, o único objetivo da migração é alterar o sistema de armazenamento de dados, isto é, fazer com que o aplicativo funcione com o novo banco de dados, ao invés de apenas os recursos específicos oferecidos pelo novo banco de dados. Em uma migração de nível 3, a maioria dos aplicativos são reescritos. Normalmente, o nível de migração estará em um ou qualquer ponto intermediário nessa escala de três níveis. 2.3 Computação nas nuvens A utilização de software em máquinas locais é um fator que leva à insatisfação de usuários finais em virtude do baixo desempenho da incompatibilidade de software com hardware. Esse e outros motivos estão fazendo com que, de acordo com Voas and Zhang (2009), computação nas nuvens receba um número cada vez maior de seguidores, apesar desta não possuir uma definição concreta. Abaixo a Figura 2.4 apresenta a arquitetura de computação em nuven. Figura 2.4 Arquitetura da Computação nas nuvens 15

33 2.3. COMPUTAÇÃO NAS NUVENS Uma característica de computação nas nuvens é a simplicidade e acessibilidade, pois, a partir de qualquer dispositivo com acesso à Internet, pode-se manipular uma aplicação nas nuvens. Por sua vez, Grossman (2009) define que computação nas nuvens, além de oferecer todos os recursos disponíveis na Internet, tem por objetivo oferecer serviços sob demanda, tais como: Infrastructure As A Service (IAAS) - Toda infra-estrutura está concentrada em um centro de dados e oferece serviços para seus clientes; Platform As A Service (PAAS) - É um serviço oferecido nas nuvens para dar total suporte a desenvolvedores corporativos na criação e teste de aplicações web; Software As A Service (SAAS) - O software é executado em um servidor sem a necessidade de ser instalado localmente; e Data Storage As A Service (DSAAS) - Permite o armazenamento de dados nas nuvens em data centers com capacidade de armazenamento escalável e praticamente ilimitado. Segundo Maggiani (2009), os serviços SAAS e DSAAS são os mais vantajosos disponíveis nas nuvens, pois permitem a disponibilização de aplicações e armazenamento de dados, que podem ser acessados de qualquer computador através de um navegador Backup de dados em nuvens De acordo com Whitehouse (2009), a utilização do serviço DSAAS é possível porque a capacidade de armazenamento disponível através da nuvem é enorme, aparentemente interminável. A proposta é a seguinte: ao invés de se possuir e manter sua própria infraestrutura, computação nas nuvens oferece ao usuário o armazenamento de informações em seus servidores, acessíveis sempre que necessário. A habilidade de se fazer backup de banco de dados e armazená-los em nuvens é fundamental para a sua segurança, uma vez que esses estarão guardados em unidades externas seguras. Backups armazenados em nuvens são mais acessíveis e na maioria das circunstâncias são mais rápidos para restaurar e muito mais confiáveis (Oracle3, 2008). De acordo com Staimer (2008), métodos primitivos para proteção dos dados têm se tornado cada vez mais frustrantes para organizações que são obrigadas a adotar soluções mistas para assegurar a proteção dos dados. Armazenamento em nuvens está se 16

34 2.3. COMPUTAÇÃO NAS NUVENS tornando uma atraente opção para proteção dos dados, além de oferecer benefícios incontáveis, como o consumo baseado em preços e a capacidade operacional, que fazem dessa abordagem uma alternativa atraente diante dos métodos tradicionais Aplicações cloud para backup/recuperação de dados Segundo Oracle2 (2008), apesar da difusão dos conceitos de computação nas nuvens aliados à idéia de utilizar as nuvens como nova alternativa para armazenamento de dados serem algo relativamente novo, algumas empresas já estão trabalhando em soluções para atender a esse novo conceito de backup de dados. Dentre estas empresas, pode-se citar a Oracle, com o módulo Oracle Secure Backup Cloud integrado ao módulo Oracle Recovery Manager (RMAN) e ao serviço Amazon Simple Storage Service (S3), a Microsoft, com integração do seu módulo SQL Data Service ao Zmanda Internet Backup (ZIB), e a Asigra, com o desenvolvimento de uma aplicação para backup de dados em nuvens: Oracle Secure Backup Cloud - Oracle Secure Backup Cloud é um módulo integrado ao Oracle Recovery Manager e que oferece a possibilidade de se fazer backup de banco de dados nas nuvens. Segundo Oracle3 (2008), quando comparado aos métodos tradicionais, o armazenamento nas nuvens é mais acessível, mais rápido para restaurar e, na maioria das circunstâncias, mais confiável. Ainda de acordo com Oracle3 (2008) o novo módulo Oracle Secure Backup Cloud possui inúmeras vantagens sobre os métodos tradicionais de backup como: acessibilidade contínua, confiabilidade e redução de custos; Zmanda Cloud Backup - Segundo Zmanda (2008), Zmanda Cloud Backup é um software desenvolvido para realização de backups online. Seu objetivo é a desafiadora tarefa de backups de arquivos, aplicações, SGBD, dispositivos de e de rede. Todos esses dados devem ser protegidos para garantir a continuidade e conformidade do negócio. Possui um baixo custo, é fácil de utilizar e configurar, e apresenta soluções para empresas de pequeno e médio portes que necessitam de backup e recuperação contra desastres; e Asigra Hybrid Cloud Backup - De acordo com Staimer (2008), Asigra é uma empresa que tem sido líder em soluções de backups distribuídos por 23 anos. O primeiro backup com base em armazenamento remoto foi lançado por ela em O módulo Asigra Hybrid Cloud Backup and Restore da Asigra supera aplicações como Oracle Secure Backup Cloud e Zmanda Cloud Backup, pois seu objetivo é 17

35 2.4. PADRONIZAÇÃO DA INFORMAÇÃO a realização de backups de ambientes híbridos. Com ele é possível verificar se um backup está corrompido ou não antes que seu armazenamento seja efetivado. Em termos de vantagem em nuvens, o Asigra Hybrid Cloud Backup possui as mesmas vantagens oferecidas pelas aplicações supracitadas. 2.4 Padronização da informação De acordo com dicionário popular, padronizar é manter algo em estado concreto, é organizar a informação de forma regular, padronizando o comportamento das informações de forma estruturada, tornando seu entendimento geral e eficiente. Adotar padronização da informação proporciona melhores resultados quanto há necessidade de troca e entendimento da informação entre as partes envolvidas. Existem casos que há também redução de custo, tanto financeiro, quanto temporal. Hoje, com a complexidade dos processos produtivos e gerenciais, torna-se cada vez mais necessário registrar de forma padronizada a maneira de se produzir e trocar informações. Portanto, a padronização deve ser vista dentro de empresas, indústrias e organizações como algo benéfico a todos, desde o nível operacional ao estratégico (Crem, 2010). A necessidade de se padronizar não se restringe apenas às áreas da computação. Segundo Jacoski and Lamberts (2002) houve um crescimento acentuado nos últimos anos de uso de ferramentas eletrônicas, o que conseqüentemente gera um grande volume informações, que apesar da importância, são incapazes de se relacionar. A falta de padronização da informação dificulta na criação de relatórios gerenciais entre os vários departamentos de uma empresa (TOLEDO et al., 2010). No dia 16 de novembro de 2006 a Agência Nacional de Saúde (ANS) apresentou ao mercado o projeto TISS (Troca de Informação da Saúde Suplementar), que visa o fornecimento de informações por parte dos prestadores de serviços médicos. Dados que antes eram trocados via FAX, passam a ser trocados via padrão TISS, tornando a informação clara, padrão e manipulável, permitindo a ANS ter total controle dos dados enviados (Saúde, 2008). Em resumo, padronizar uma informação é torná-la legível a todos os sistemas que a manipulam, independente de plataforma, linguagem ou fabricante. Assim como Inglês e Espanhol foram definidas como linguagens padrão de comunicação entre pessoas, em informática a ideia é a mesma, mas para isso são utilizadas linguagens como XML, YAML, JSON (JSON, 2010), Comma-Separated Values (CSV), entre outras. Sendo 18

36 2.4. PADRONIZAÇÃO DA INFORMAÇÃO assim, as seções a seguir abordam os principais padrões utilizados para padronização da informação extensible Markup Language (XML) XML é uma linguagem de marcação utilizada para definição e padronização de estruturas. Sua definição segundo Ray (2006) não é tão fácil de definir, uma vez que, em um nível, XML é um protocolo para conter e gerenciar informações. Em outro, é uma família de tecnologias que pode fazer tudo, desde formatar documentos até filtrar dados. Em um nível mais alto, é uma filosofia para tratamento de informações, que busca o máximo de utilidade e flexibilidade para os dados. XML representa os dados através de marcações intercaladas para descrever os dados e suas propriedades. As marcações são predominantemente representadas em forma de tags que se distinguem dos textos não marcados. Toda Marcação aberta deverá ser fechada para indicar o início e fim do escopo.abaixo a Figura 2.5 apresenta um exemplo simples de documento XML. Figura 2.5 Documento XML Os documentos XML podem ser validados a partir de estruturas pré-definidas, de forma que se possam ter vários documentos que sigam a mesma estruturação (W3C, 2010). Estas estruturas podem ser definidas através do XML Schema. Normalmente um documento XML bem formatado possui uma estrutura equivalente que o defina XML Schema É um padrão utilizado para definição de estruturas e representação de dados em XML, recomendada pela World Wide Web Consortium (W3C) em maio de XML Schema 19

37 2.4. PADRONIZAÇÃO DA INFORMAÇÃO representa uma importante alternativa ao uso de DTD (W3C, 2010). Esse padrão permite a definição de tipos de dados usando XML. Os tipos de dados ajudam na restrição dos dados a serem validados. Tais tipos são divididos em, tipos especificados pelo usuário e tipos internos. Os internos fornecem tipagem permitida para os valores de entrada das marcações, tipos como, string, número inteiro, decimal, lógico, data, tempo, binários, entre outros. Os tipos definidos pelo usuário são especificados como parte do esquema e podem possuir restrições adicionais para os tipos internos, como um intervalo de números ou uma lista explicitamente enumerada de valores (GRAVES, 2003). A Figura 2.6 apresenta a definição do esquema do documento XML da Figura 2.5 Figura 2.6 Documento XMLSchema Um documento XMLSchema é constituído de elementos, atributos e regras que o definem. Os elementos são definidos pela palavra reservada ELEMENT, que por sua vez utiliza os atributos NAME e TYPE para definir o nome do elemento e o tipo de informação aceita. Além disso, podem-se definir restrições através do uso dos elementos SIMPLETYPE e RESTRICTION. Os atributos são definidos de forma semelhante aos elementos, porém, utilizando a palavra reservada ATTRIBUTE, juntamente com os atributos NAME e TYPE. Além 20

38 2.4. PADRONIZAÇÃO DA INFORMAÇÃO disso é possível utilizar outros atributos no XML Schema para funções específicas, por exemplo, se uma marcação possui valor fixo ou padrão, definidos respectivamente pelos atributos FIXED e DEFAULT (W3C, 2010) YAML Ain t Markup Language (YAML) É uma linguagem aberta para serialização de dados projetada para ser amigável e mais próxima possível da linguagem humana. Projetada para trabalhar nas linguagens de programação mais modernas em tarefas comuns. YAML foi concebida para ser útil e amigável para as pessoas que trabalham com dados e os manipulam (YAML, 2010). Inspirada em conceitos de linguagens como XML (Fonseca and Simões, 2007). Para melhor representação dos dados, a YAML é dividida em três partes: classe, sintaxe e processador. A classe representa um documento YAML. A sintaxe é a representação da YAML através de uma série de caracteres e palavras reservadas. Por fim, o processador YAML é uma ferramenta usada para processamento e conversão das informações. Em YAML todos os dados podem ser representados adequadamente, como combinação de listas e dados escalares. A sintaxe é relativamente simples e de fácil mapeamento, aceita os tipos mais comuns de dados assim como a maioria das linguagens de alto nível. Além disso, YAML utiliza uma notação baseada em identação e um conjunto de caracteres distintos dos utilizados por XML, fazendo com que as duas linguagens sejam facilmente combinadas. A Figura 2.7 apresenta o exemplo de um documento XML convertido para YAML. Figura 2.7 Documento XML para YAML 21

39 2.5. APLICAÇÕES WEB JavaScript Object Notation (JSON) É um formato leve utilizado para troca de dados e objetos Javascript. Baseada em um subconjunto da linguagem de programação. JSON é em formato texto e completamente independente de linguagem de programação e possui implementação para maioria das linguagens disponíveis no mercado (JSON, 2010). JSON utiliza como limitador de escopo a chave aberta que indica o início de um objeto, e a chave fechada indicando o fim. Os pares de nome e valor são separados utilizando virgula e ":".Esta estrutura pode ser combinada aos caracteres [ e ] para representar uma coleção de objetos. A Figura 2.8 apresenta dois tipos de informação, dados simples, representados pelos pares, nome e valor, e uma lista de objetos, representados pelo [ seguidos dos pares, nome e valor, e o ]. Conforme abaixo. Figura 2.8 Documento JSON 2.5 Aplicações WEB Uma aplicação Web é um sistema que permite a seus usuários executar a regra de negócio (ou lógica do negócio, business logic) com um navegador (Conallen, 2003); uma aplicação Web pode ser desde um simples site, até uma aplicação Web completa. Existem destinções entre uma aplicação Web e um site. Uma aplicação Web é um site em que a entrada do usuário, navegação e entrada dos dados afeta diretamente o estado do negócio, além dos contadores e logs de acesso. Já um site é essencialmente uma página constituída de texto, objetos, links, entre outros, usada como front end para uma aplicação de negócio (Conallen, 2003). As aplicações WEB podem ser classificadas em duas categorias: aplicações hipermídia e aplicações de software. As aplicações hipermídia são aplicações não convencionais caracterizadas pela publicação de informação utilizando links, âncoras e estrutura de acesso disponibilizado através da WEB. Já a aplicação de software depende da infraestrutura Web para sua execução. O termo aplicação WEB representa uma aplicação que possui características de ambas as aplicações, hipermídia e software. 22

40 2.5. APLICAÇÕES WEB Tecnologias Web Dependendo da linguagem de programação escolhida, inúmeras tecnologias poderão ser aplicadas para se chegar a um resultado final esperado, como tais tecnologias pode-se citar: Hypertext Markup Language (HTML) (Markup, 2010) - É uma linguagem clara para publicação de hipertexto na Internet. É um formato não proprietário mantido pela W3C. A HTML pode ser desenvolvida usando simples editores de texto até sofisticados editores. HTML utiliza tags para estruturar o texto em cabeçalhos, parágrafos, listas, links, entre outros; Cascading Style Sheets (CSS) (CSS, 2010) - É um mecanismo simples utilizado para adicionar estilo a documentos Web como, fontes, cores, espaçamentos, entre outros. Um documento CSS pode ser escrito no próprio documento HTML, ou em um documento separado que para ser aplicado ao documento HTML; JavaServer Pages (JSP) (JSP, 2010) - É uma tecnologia criada para desenvolvimento de páginas Web, permitindo que desenvolvedores possam criar de forma rápida e fácil páginas Web dinâmicas, além de potencializar os sistemas existentes. Como parte da família da tecnologia Java, a tecnologia JSP permite o desenvolvimento rápido de aplicativos baseados na Web que são independentes de plataforma. Tecnologia JSP separa a interface de usuário de geração de conteúdo, permitindo aos designers alterar o layout geral da página sem alterar o seu conteúdo dinâmico; Javaserver page Standard Tag Lib (JSTL) (JSTL, 2010) - É uma coleção de bibliotecas encapsuladas com o objetivo de oferecer as principais funcionalidades utilizadas pelas páginas web em JSP. Assim como HTML e JSP, JSTL define um conjunto de tags para acesso às funcionalidades encapsuladas. Como tais funcionalidades citam-se: formatação de data e hora, acesso a banco de dados e comando para processamento dos dados; e JavaScript (Flanagan, 2002) - É uma linguagem de programação leve, interpretada e com recursos de orientação a objetos. Adicionada aos principais navegadores de Internet, aprimora a programação Web com a adição de objetos que representem janelas, botões, caixas de texto, entre outros. O JavaScript do lado cliente permite que o conteúdo executável seja incluído na página Web. Isso significa que uma 23

41 2.5. APLICAÇÕES WEB página não precisa mais de HTML estático, mas pode incluir programas que interagem com o usuário, controlam o navegador e criam conteúdo HTML dinâmico. Para desenvolvimento da camada de aplicação/processamento, pode-se utilizar as seguintes tecnologias: Java (Deitel and Deitel, 2009) - Linguagem de programação mantida pela SUN Microsystems idealizada por James Gosling. Java inicialmente foi projetada para programar dispositivos eletrônicos, mas gerou interesse na comunidade comercial por causa do grande interesse pela Internet. Java agora é utilizada para criar páginas Web com conteúdo interativo e dinâmico, além de aplicativos para desktop, celulares, pagers, entre outros; STRUTS2 (Struts2, 2010) - É uma estrutura elegante e extensível para a criação de aplicações Web em Java. A estrutura foi projetada para otimizar o ciclo de desenvolvimento de aplicativos Web, desde a construção, a implantação, a manutenção das aplicações ao longo do tempo. Struts2 era originalmente conhecida como WebWork2. Depois de trabalhar de forma independente durante vários anos, o WebWork Struts e comunidades se uniram para criar Struts2; XERCES (Xerces, 2010) - É um projeto de desenvolvimento de software colaborativo dedicado a fornecer recursos, qualidade comercial parsers XML e tecnologias relacionadas a uma ampla variedade de plataformas de linguagem de programação. Este projeto é gerido em colaboração com várias pessoas de todo o mundo, que utilizam a Internet para se comunicar, planejar e desenvolver software XML. Foi criado para geração, manipulação, validação e melhoria em documento XML; DOM4J (Beat, 2010) - É um framework de código aberto de fácil utilização para trabalhar com XML, XPATH e XSLT na plataforma Java utilizando uma coleção de métodos para manipulação de arquivos XML. Esse framework possui suporte completo às API, DOM, SAX e JAXP; e TOMCAT (Tomcat, 2010) - É um container de servlet desenvolvido pela APACHE FOUNDATION com intuito de manter e executar aplicações Web JAVA utilizando servlets. TOMCAT é uma implementação open source destinada para ser uma colaboração para os programadores de todo o mundo, dando poder em grande escala às aplicações Web. Atualmente, TOMCAT encontra-se na versão 7.0, implementando servlet 3.0 e Javaserver Page 2.2, além de incluir recursos adicionais 24

42 2.6. PADRÕES DE PROJETO que a torna uma plataforma útil para desenvolvimento de aplicações Web e Web Services. Para camada de acesso aos dados, pode-se UTILIZAR as seguintes tecnologias: Hibernate (Gonçalves, 2007) - É um projeto que procura soluções completas para o problema de gerenciamento de dados persistentes em JAVA. O hibernate é um framework que se relaciona com o banco de dados, onde esse relacionamento é conhecido como mapeamento objeto/relacional para JAVA, deixando o desenvolvedor livre para se concentrar em problemas da lógica de negócios. O hibernate se integra ao sistema se comunicando com o banco de dados como se fosse diretamente feito por sua aplicação. Uma mudança de banco de dados, nesse caso, não se torna traumática, alterando apenas um ou outro detalhe nas configurações; e Java DataBase Connection (JDBC) (Reese, 2001) - Percebendo o aumento no número de API proprietárias para acesso a banco de dados, a SUN desenvolveu uma API única para acesso a banco de dados, a JDBC. JDBC é uma API que permite acessar banco de dados e construir instruções Structured Query Language (SQL) e incorporá-las dentro de chamadas de API Java, usando basicamente a linguagem SQL. JDBC permite-se traduzir harmoniosamente entre o mundo de banco de dados e o mundo das aplicações Java. Seus resultados do banco de dados são retornados como objetos Java e os problemas de acesso são considerados exceções. 2.6 Padrões de projeto A ideia de padrões foi inicialmente idealizada por Christopher Alexander ao se fazer a seguinte pergunta: O que está presente em um projeto de boa qualidade que não está presente em um projeto de baixa qualidade? Observando as estruturas, Alexander percebeu que ele poderia discernir similaridades entre fatores que resultaram em projetos de alta qualidade, e a esses fatores ele deu o nome de padrões. Cada padrão descreve um problema que ocorre repetidamente em nosso ambiente e, portanto, descreve o cerne da solução desse problema, de tal forma que se pode utilizar essa solução várias vezes repetidas, sem nunca fazê-la duas vezes do mesmo modo (SHALLOWAY and TROTT, 2002; GAMMA et al., 1995). Foi com base nas pesquisas de Alexander que Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides, aplicaram os conceitos de padrões arquiteturais para padrões 25

43 2.6. PADRÕES DE PROJETO estruturais de software, formalizando vinte e três padrões de projeto classificados em três propósitos, criação, estrutural e comportamental. Os padrões de criação se preocupam com o processo de criação dos objetos. Os padrões estruturais lidam com a composição de classes ou de objetos. Os padrões comportamentais caracterizam as maneiras pelas quais classes ou objetos integram e distribuem responsabilidades. Esses padrões ficaram conhecidos como padrões GOF (Gang Of Four) ou gangue dos quatro (Lasater, 2006; GAMMA et al., 1995). Mas o que são exatamente padrões de projeto? Segundo Braude (2004), padrões são combinações de classes e algoritmos associados que cumprem com propósitos comuns de projeto. Um padrão de projeto, segundo GAMMA et al. (1995), nomeia, abstrai e identifica os aspectos-chave de uma estrutura de projeto comum para torná-la útil para criação de um projeto de software orientado a objetos reutilizável. Ainda segundo GAMMA et al. (1995), projetar software orientado a objetos é difícil, mas projetar software reutilizável orientado a objeto é ainda mais complicado. Por esse motivo que projetistas experientes preferem reutilizar estruturas ao invés de desenvolver uma do zero O padrão estrutural Decorator Sua intenção é agregar responsabilidades adicionais a um objeto de forma dinâmica. Os decorators fornecem uma alternativa flexível ao uso de subclasses para extensão de funcionalidades. Uma forma de adicionar responsabilidade é através do uso de herança. Decorator utiliza herança para adicionar funcionalidades dinamicamente a um objeto. Por exemplo, um toolkit para construção de interfaces gráficas deve permitir a adição de propriedades, como bordas, ou comportamentos, como rolamento de tela (GAMMA et al., 1995). O padrão decorator trabalha permitindo criar uma cadeia de objetos que inicia com os Decorators, os quais são responsáveis pelas novas funções. O diagrama de classe do padrão decorator, mostrado na Figura 2.9, contém uma cadeia de objetos, Scrolldecorator e Borderdecorator, cada cadeia inicia com uma classe componente (seja componente concreto ou decorator). Cada decorator é seguido de outro decorator ou o componente concreto original. Uma classe componente concreta sempre encerra a cadeia (SHAL- LOWAY and TROTT, 2002). 26

44 2.6. PADRÕES DE PROJETO Figura 2.9 Diagrama de Classes do padrão Decorator (SHALLOWAY and TROTT, 2002) Segundo GAMMA et al. (1995), deve-se usar decorator para: Acrescentar responsabilidade a objetos individuais de forma dinâmica e transparente, ou seja, sem afetar outros objetos; Responsabilidades que podem ser removidas; Quando a extensão através do uso de subclasse não é prática. Às vezes, um grande número de extensões independentes é possível e isso poderia produzir uma explosão de subclasses para dar suporte a cada combinação. Ou a definição de uma classe pode estar oculta ou não estar disponível para utilização da classe O padrão comportamental Strategy Um padrão de estratégia é um conjunto de algoritmos encapsulados dentro de classe intercambiáveis que possibilitam que o algoritmo possa variar dependendo da classe utilizada. As estratégias são utilizadas quando se deseja decidir em tempo de execução a utilização de cada algoritmo. Essa variação entre os algoritmos fica sob responsabilidade da classe contexto (Lasater, 2006). O padrão Strategy tem três componentes principais: the Strategy, the Concrete Strategy e Context. O componente Strategy é uma interface comum que une todos os algoritmos implementados no padrão. Normalmente essa classe é abstrata. O componente Concrete Strategy é a classe de implementação, é nela que se encontra toda a lógica dos algoritmos implementados. Esta classe é dividida em grupo de algoritmos, dependende 27

45 2.6. PADRÕES DE PROJETO de quantas estratégias concretas se deseja usar. O componente Context é o objeto que associa uma estratégia concreta a um fluxo de código específico (Lasater, 2006). A Figura 2.10 mostra o diagrama de classes do padrão Strategy. Figura 2.10 Diagrama de Classes do padrão Strategy (Lasater, 2006) Vantagens de se utilizar o padrão Strategy (SHALLOWAY and TROTT, 2002). Define uma família de algoritmos; Os comandos switch e/ou condicionais podem ser eliminados; e Deve-se invocar todos os algoritmos da mesma maneira. A interação entre as classes concretas e de contexto pode requerer a adição de novos métodos, o que pode ser facilmente adicionada sem muitas alterações. O padrão Strategy representa uma escolha melhor em situações onde a classe Component é intrinsecamente pesada, dessa forma tornando a aplicação do padrão Decorator muito onerosa. No padrão Strategy, o componente repassa parte do seu comportamento para um objeto strategy separado, além de permitir alterar ou estender a funcionalidade do componente pela substituição do objeto strategy O padrão Data Access Object (DAO) Aplicativos usam a API JDBC para acesso a dados persistentes, permitindo acesso padrão para manipulação dos dados através do uso de instruções SQL. No entanto, a sintaxe dos comandos SQL pode variar, dependendo do fabricante. Essa dependência torna difícil e tediosa a migração de uma fonte de dados para outra. Quanto às alterações nas fontes de dados, os componentes precisam ser mudados para lidar com a nova fonte de 28

46 2.6. PADRÕES DE PROJETO dados. Uma forma de contornar esse tipo de problema é utilizar o padrão DAO para abstrair e encapsular todo o acesso à fonte de dados (DAO, 2010). DAO implementa um mecanismo para acesso as diversas fontes de dados. O componente de negócio que se baseia no DAO usa uma interface simples que oculta completamente os detalhes da fonte de dados em execução. Como a interface exposta pelo DAO para os clientes não se altera quando há mudanças na implementação do código, esse padrão permite que o DAO possa se adaptar a diferentes esquemas de armazenamento sem afetar seus clientes ou os componentes do negócio. Essencialmente, o DAO age como um adaptador entre o componente e a fonte de dados. O padrão DAO fornece uma interface independente, na qual pode-se usar para persistir objetos de dados. A ideia é colocar todas as funcionalidades de acesso e trabalho com os dados em um só local, tornando simples sua manutenção. Tipicamente um DAO inclui métodos para inserir, selecionar, atualizar e excluir objetos de um banco de dados. Dependendo de como se implementa o padrão DAO, pode-se ter um DAO para cada classe de objetos na aplicação, ou podera-se ter um único DAO responsável por todos os objetos (Gonçalves, 2007). A Figura 2.11 mostra o diagrama de classe que representa as relações para o padrão DAO (DAO, 2010). Figura 2.11 Diagrama do Padrão DAO (DAO, 2010) O padrão Model View Controller (MVC) MVC é um conceito de desenvolvimento e design que tenta separar uma aplicação em três partes distintas. A primeira, o modelo, está relacionada ao trabalho atual que a aplicação administra, outra parte, a visão, está relacionada com a exibição dos dados ou 29

47 2.7. CONSIDERAÇÕES FINAIS informações de uma aplicação, a terceira parte, controle, é responsável por coordenar as camadas Modelo e Visão, exibindo a interface correta ou executando algum trabalho que a aplicação precisa completar (Gonçalves, 2007). Modelo - O modelo é o objeto que representa os dados do programa. Maneja esses dados e controla todas as transformações. Esse modelo não tem conhecimento específico dos controladores e das apresentações, nem contém referência para eles. Portanto, o modelo é composto pelas classes que trabalham no armazenamento e busca de dados; Visão - é o que maneja a apresentação visual dos dados representados pelo Modelo. Em resumo, é responsável por apresentar os dados resultantes do modelo do usuário. Por exemplo, uma apresentação poderá ser um local administrativo onde os administradores se logam em uma aplicação. Cada administrador poderá visualizar uma parte do sistema que outro não vê; e Controle - é o objeto que responde as ordens executadas pelo usuário, atuando sobre os dados apresentados pelo modelo, decidindo como o modelo deverá ser alterado ou ser revisto, e qual apresentação deverá ser exibida. Por exemplo, o controlador recebe um pedido para exibir uma lista de clientes interagindo com o modelo e entregando uma apresentação onde essa lista poderá ser exibida. O modelo MVC é uma forma de desenvolvimento que ajuda na manutenção do sistema, um padrão muito aceito no desenvolvimento de aplicações Java, principalmente no de aplicações escritas para Web. A separação lógica da aplicação assegura que a camada Modelo não conheça o que será exibido; limitando-se a representar as partes do problema a ser resolvido pela aplicação. Igualmente, a camada de apresentação está condicionada apenas na exibiçãp dos dados, e não com a implementação da lógica de negócios que é controlada pelo modelo. O controlador, como um gerenciador de tráfego, dirige as apresentações a serem exibidas e com as devidas mudanças de dados e recuperações vindas da camada modelo (Gonçalves, 2007). 2.7 Considerações Finais Este capítulo abordou os conceitos básicos necessários para o entendimento deste trabalho. Assim, o capítulo tratou os conceitos relacionados a backup, segurança, criptografia 30

48 2.7. CONSIDERAÇÕES FINAIS e migração de dados, uma vez que, o foco principal do protótipo proposto neste trabalho, possui essas finalidades. Por conseguinte, foram apresentados os conceitos relacionados à computação nas nuvens, tendo como foco principal as principais ferramentas responsável pela realização de backup em nuvens, bem como também o armazenamento de dados. A padronização da informação também é foco principal deste trabalho, uma vez que o mesmo propõe a padronização dos arquivos de backup de dados com objetivo de desvincular sua dependência entre ambientes ou aplicações, dando liberdade aos mesmos para serem usados por qualquer aplicação que conheça sua estrutura. Para isso foram pesquisadas as principal linguagem utilizadas para padronização e intercâmbio de dados entre sistemas heterogêneos. Neste contexto as sequintes linguagens foram encontradas, e seus conceitos descritos neste capítulo: XML, cujo foco principal foi à tecnologia XML Schema, utilizada para desenvolvimento da estrutura proposta por esse trabalho, a BKPML a ser vista no próximo capítulo,yaml e JSON foram utilizadas para compor o processo de trasformação dos dados de um arquivo de backup para esse tipo de formato, além de outras, que por sua simplicidade e popularidade, não se fez necessário abordar. Aplicações e tecnologias Web também foram discutidas neste capítulo. É importante ressaltar que tais tecnologias apresentadas são voltadas unicamente para o ambiente JAVA, embiente esse utilizado para desenvolvimento do protótipo. Além das tecnologias, foram abordados os principais conceitos de padrões de projeto, bem como os principais padrões utilizados para desenvolvimento deste trabalho. 31

49 3 Backup Markup Language (BKPML) A modernização dos sistemas de informação, a cada dia, tem fortalecido a dependência dos dados em relação às aplicações proprietárias que, em sua maioria, buscam a restrição dos dados a uma única ferramenta, fortalecendo o vínculo obrigatório entre clientes e fornecedores de software. Para resolver tal problema, inúmeros estudos e soluções têm surgido nas áreas de pesquisa de engenharia de software. extensible Markup Language (XML) é um exemplo que se pode citar como resultado de tais pesquisas. Este capítulo tem por objetivo propor uma nova estrutura, não proprietária, baseada em XML, cujo objetivo é a padronização de arquivos de backup de dados, denominada BKPML. Além disso, serão apresentados todos os elementos e tipos que a constituem. 3.1 Introdução Após a evolução dos Sistemas de Informação (SI) na década de 80, com o surgimento da arquitetura cliente/servidor e o conceito de sistemas integrados, a informação deixa de ser centralizada e passa a ser compartilhada entre sistemas através de uma rede de computadores, deixando os sistemas centralizados/legados isolados, mas com uma grande quantidade de dados de suma importância para tomada de decisões de empresas e organizações (Turban et al., 2002; Laurindo, 2000). Para manter a interoperabilidade entre os sistemas novos e legados, foram desenvolvidos diversos frameworks como, Common Object Request Broker Architecture (CORBA) (OMG, 2010), Remote Method Invocation (RMI) (RMI, 2010) e Distributed Component Object Model (DCOM) (DCOM, 2010). Apesar de cumprirem seu propósito, tais frameworks apresentavam limitações entre linguagens de programação, nível de dificuldade elevada, alguns por serem frameworks proprietários e o custo elevado, que na maioria das vezes não compensava manter a interoperabilidade entre as aplicações, levando al- 32

50 3.1. INTRODUÇÃO gumas empresas a utilizar os sistemas em paralelo, atualizando-os de forma manual. Com o surgimento das linguagens para definição e padronização de estruturas de dados como XML, notou-se a grande vantagem de se utilizar tal linguagem para padronização de dados e interoperabilidade dos mesmos entre aplicações heterogêneas. Os Web Services são exemplos que podem ser citados, pois possuem em sua especificação a linguagem XML para troca de informações entre aplicações. Além dos Web Services, existem inúmeras linguagens derivadas de XML com objetivo de interoperabilidade como a extensible Business Reporting Language (XBRL) (XBRL, 2010), extensible Scientific Interchange Language (XSIL) (CACR, 2010), Scalable Vectorial Graphics (SVG) (SVG, 2010), Mathematical Markup Language (Math- ML) (MathML, 2010), entre outras. A BKPML é uma nova linguagem eletrônica, baseada em XML, desenvolvida como parte integrante deste trabalho, com intuito de padronizar os arquivos de backups de banco de dados. Seu objetivo é desvincular a dependência dos backups do seu SGBD de origem, facilitando assim a recuperação do mesmo em qualquer outro SGBD. Esta linguagem, com o apoio de uma aplicação, permite que um arquivo de backup possa ser restaurado em qualquer SGBD, independente da origem dos dados. Outra vantagem é a possibilidade de transformar os arquivos BKPML para arquivos secundários (Texto, Excel, CSV, XML, JSON e YAML). A BKPML facilita a manipulação das informações de acordo com as necessidades dos usuários, uma vez que a mesma defende a liberdade das informações e a flexibilidade dos dados. SGBD proprietários possuem como objetivo principal o armazenamento, segurança, backup e restauração dos dados em suas plataformas proprietárias, quando copiados para arquivos de backup, os dados oriundos de tais SGBD só poderão ser restaurados no seu ambiente de origem, não podendo ser restaurados em outros ambientes. Com arquivos em formato BKPML, esses dados tornam-se independentes de aplicação, facilitando a manipulação dos dados por parte dos usuários. Para facilitar a persistência e recuperação dos dados, foram selecionados dois formatos de arquivos para armazenamento de grandes volumes de dados, CSV (Creativyst, 2011) e JSON (JSON, 2010). CSV é um formato de arquivo que armazena dados tabelados e que utiliza delimitadores (vírgula e quebra de linha) para separar os valores. O formato também usa aspas em campos no qual são usados os caracteres reservados (vírgula e quebra de linha). JSON é um formato adequado para intercâmbio de dados computacionais, e utilizado principalmente para tráfego de informações em ambientes heterogêneos via Hypertext 33

51 3.1. INTRODUÇÃO Transfer Protocol (HTTP) (Tanenbaum, 2003), assim como XML. JSON e do CSV possuem implementações em várias linguagens de programação, o que viabiliza a utilização dos mesmos junto a XML (JSON, 2010). Os principais fatores que levaram a utilização do JSON e CSV como as principais tecnologias para persistência dos dados na estrutura BKPML, foram: Recuperação da Informação - JSON e CSV possuem uma estrutura padronizada para manter os dados e facilitar a recuperação dos mesmos. Suas interfaces possuem implementações em diversas linguagens de programação, o que facilita ainda mais o processo de recuperação das informações, além de visualmente serem mais organizados que outras estruturas; Representação da Informação - em XML existem certas dificuldades em se representar alguns tipos de dados, lista é um exemplo. JSON, nesses casos, tem se mostrado uma linguagem promissora para representação de dados de tipos mais complexos, pois, através da sua forma de marcação, é possível representar listas de objetos. CSV, por sua vez, apesar de não ser tão claro e organizado quanto JSON, possui uma estrutura conhecida o que facilita muito a recuperação da informação através de outras ferramentas; e Suporte em várias linguagens - JSON e CSV possuem suporte em várias linguagens de programação, facilitando assim o uso da estrutura e reduzindo o trabalho por parte dos programadores no desenvolvimento de algoritmos para retorno dos dados em uma estrutura com marcação não padronizada. Além do CSV e JSON foram pesquisadas outras alternativas para uso e persistência dos dados. Hoje existem alternativas para geração de estrutura e marcação de texto, YAML Ain t Markup Language (YAML) é uma dessas alternativas. YAML é um formato para serialização de dados legível por humanos, assim como XML, mas com uma notação muito mais leve e legível (YAML, 2010). Apesar da YAML também possuir implementações em diversas linguagens de programação, seu uso ainda se torna restrito por se tratar de uma nova linguagem para representação de informação, o que torna difícil seu uso e implementação em outras ferramentas, além da baixa aceitabilidade das mesmas por parte de usuários leigos em tal tecnologia. Apesar da YAML não ser utilizada para persistir as informações na estrutura BKPML, a mesma será utilizada como uma das linguagens para transformação dos arquivos BKPML. 34

52 3.2. APRESENTAÇÃO DA ESTRUTURA BKPML BKPML utilizará JSON e CSV para armazenamento dos dados, pois, além de serem formatos de fácil utilização, foi levada em consideração sua afinidade em relação aos frameworks encontrados, bem como, o desempenho dos mesmos para transferência de grandes volumes de dados. A Figura 3.1 apresenta a estrutura em árvore da BKPML. 3.2 Apresentação da estrutura BKPML Para se obter embasamento necessário para desenvolvimento da estrutura da BKPML, bem como de todos os objetos dos SGBD aceitos pela estrutura, foi necessário adquirir profundos conhecimentos sobre a estrutura das tabelas de metadados dos principais SGBD utilizados pelo mercado (Oracle, Sqlserver, MYSQL e Postgres). Todo enbasamento para desenvolvimento da estrutura dos objetos (Table, Index, View, Grant, Trigger e Method) foram retirados através de suas sintaxes de criação, utilizando o padrão SQL em sua forma mais pura, evitando assim incompatibilidade entre objetos de um SGBD para o outro. Em caso de diferença entre objetos, a mesma deverá ser adicionada de forma manual após a restauração/migração dos dados. A Figura 3.2 apresenta de forma descritiva a estrutura da BKPML bem como de seus objetos. A estrutura principal do documento é constituída de três elementos complexos: o elemento <BKPML>, <SchemaDB> e <Objects>. O elemento <BKPML> é a estrutura raiz do documento, é nele que se encontram as principais informações do arquivo BKPML. O elemento BKPML é constituído de um elemento, denominado <SchemaDB>, cujo objetivo é manter as informações do esquema a ser copiado, bem como os atributos File_Name (nome do arquivo gerado) e Date_Created (data de geração do arquivo). A seguir serão apresentados de forma detalhada todos os elementos que constituem a estrutura BKPML e seus respectivos atributos O elemento SchemaDB O elemento <SchemaDB> possui como tipo, o elemento complexo SchemaDBType, que é responsável por guardar as informações referentes ao esquema. Esta estrutura é constituída dos atributos, Schema_Name, que como o próprio nome já diz, refere-se ao nome do esquema, o atributo DataBase_Source que refere-se ao SGBD que originou os dados. O atributo DataBase_Source é de grande importância para migração dos dados, pois é a partir dele que a arquitetura responsável pela geração dos arquivos BKPML se baseia 35

53 3.2. APRESENTAÇÃO DA ESTRUTURA BKPML Figura 3.1 Representação em árvore da estrutura BKPML 36

54 3.2. APRESENTAÇÃO DA ESTRUTURA BKPML Figura 3.2 Estrutura principal da BKPML para fazer o mapeamento DE-PARA dos tipos e sintaxes de um sistema de banco de dados para outro. A cardinalidade do elemento <SchemaDB> foi definida como 1..1 para que a estrutura BKPML possa dar suporte a apenas a cópia de um único esquema em um mesmo arquivo. Ao migrar um banco de dados, o esquema pode ser um desafio, pois é necessário mapear os tipos de dados do banco antigo para os tipos de dados do banco novo. Eles não precisam ter o mesmo nome, mas devem ter as mesmas funções. Por exemplo, se não forem mapeados os tipos de dados corretamente na migração dos dados, podem ocorrer resultados imprevisíveis ou, pior ainda, os dados podem ser danificados e perdidos (STERN, 2010). 37

55 3.3. ESTRUTURA DOS OBJETOS DA BKPML O elemento Objects Assim como o elemento <SchemaDB>, o elemento <Objects> possui como tipo um elemento complexo ObjectType, que é a estrutura mais importante do documento, pois é nela que serão mantidos todos os objetos pertencentes a um esquema a ser copiado. A cardinalidade desta estrutura foi definida como 1..1 para não permitir que um esquema possa possuir mais de uma coleção de objetos. A primeira versão da BKPML é projetada para atender aos principais objetos existentes em um banco de dados, tais como: tabelas, índices, visões, permissões, gatilho, procedimentos e funções, seqüencialmente representadas pelos tipos complexos: Table- ObjectType, IndexObjectType, ViewObjectType, GrantObjectType, TriggerObjectType e MethodObjectType apresentados a seguir. 3.3 Estrutura dos objetos da BKPML Conforme mencionado, a estrutura da BKPML dá suporte aos principais objetos utilizados em um SGBD. As seções a seguir destinam-se a apresentar apenas as estruturas XML Schema dos objetos aceitos pela BKPML. É importante ressaltar que a estrutura XML Schema desenvolvida foi totalmente baseada na sintaxe SQL padrão dos objetos de SGBD, aceitos pela BKPML. Para melhor aproveitar as vantagens oferecidas pelo XML Schema, a estrutura da BKPML foi dividida em elementos complexos. Essa estratégia possibilita reuso nas estruturas e facilita a manutenção dos objetos. Os elementos complexos serão seqüencialmente apresentados conforme abaixo: TableObjectType IndexObjectType ViewObjectType GrantObjectType TriggerObjectType MethodObjectType 38

56 3.3. ESTRUTURA DOS OBJETOS DA BKPML O elemento complexo tableobjecttype O elemento complexo TableObjectType foi preparado para atender apenas a objetos do tipo tabela. Sua cardinalidade foi definida 0..* pois, em um esquema, pode-se possuir zero ou nenhum objeto do tipo tabela dentro de seu domínio. As informações pertencentes a essa estrutura são: o atributo name, que se refere ao nome da tabela copiada, os elementos <Columns> que mantém todas as informações das colunas de uma tabela e <Records> que são os dados existentes na tabela. O atributo order servirá como o identificador das ocorrências das tabelas. O elemento <Columns>, conforme mencionado, contém uma coleção de elementos <Column_Data> cujo objetivo é manter as informações referentes às colunas da tabela, representado pelos atributos, column_name (nome da coluna), type (tipo de dados), not_null (se aceita ou não campos nulos), max_length (tamanho do campo), primary_key (atributo booleano que indica se é chave primária ou não), foreing_key (chave estrangeira, assim com o campo chave primária este campo também é booleano), reference_table (nome da tabela de referência em caso de chave estrangeira), reference_field (campo de referência da tabela). Quanto ao atributo foreing_key, se o mesmo estiver indicando uma relação de chave estrangeira para um campo, torna-se obrigatória a inserção das informações para os atributos reference_table e reference_field para que a ferramenta possa montar de forma correta essa relação. O atributo column_order é utilizado como identificador para controle das várias ocorrências do elemento <Column_Data>. O elemento <Records> é o elemento no qual persistirão os dados da tabela. Essa estrutura terá como dados uma coleção de elementos <Record_Data>, responsável por representar os registros oriundos da tabela copiada em formato JSON ou CSV. A Figura 3.3 apresenta a estrutura do elemento complexo TableObjectType O elemento complexo indexobjecttype A próxima estrutura a ser apresentada é a do elemento complexo IndexObjectType. Essa estrutura possui um total de seis objetos, três elementos e três atributos em seu escopo. São eles: <index_name> (nome do índice), <index_table> (nome da tabela), <index_field> (campos da tabela) e os atributos: order que é um atributo obrigatório para controle interno de ocorrências, kind e type que são atributos opcionais que representam que tipo de índice se deseja criar (Index, Primary, Unique, fulltext ou Spatial), e qual o tipo do índice (Btree, Hash e Rtree). A Figura 3.4 apresenta essa estrutura. 39

57 3.3. ESTRUTURA DOS OBJETOS DA BKPML Figura 3.3 Tipo complexo TableObjectType O elemento complexo viewobjecttype O elemento complexo ViewObjectType é destinado à persistência de objetos de visão, sua estrutura é constituída por dois elementos, <name> e <query>, e o atributo order, que é responsável pelo controle das visões adicionadas no documento. O elemento <name> é o nome da visão a ser copiada. Já o elemento <query> guarda a consulta responsável por gerar os dados da visão. A Figura 3.5 apresenta a estrutura completa do elemento complexo ViewObjectType O elemento complexo grantobjecttype O próximo elemento complexo a ser apresentado é o tipo GrantObjectType, essa estrutura é responsável por aplicar as regras de segurança e acessibilidade dos usuários do 40

58 3.3. ESTRUTURA DOS OBJETOS DA BKPML Figura 3.4 Tipo complexo IndexObjectType Figura 3.5 Tipo complexo viewobjecttype SGBD. Ela é composta por três elementos e um atributo, são eles: <privilege>, <object>, <user> e order. O elemento <privilege> receberá um ou uma lista de privilégios a serem cedidos a um usuário, esses privilégios podem ser (select, insert, delete, entre outros). O elemento <Object> receberá o nome do objeto (tables, views, triggers, functions, entre outros) a ser concedido o privilégio. Já o elemento <user> indica para que usuário do SGBD os privilégios estão sendo concedidos. A Figura 3.6 apresenta o tipo complexo GrantObjectType. 41

59 3.3. ESTRUTURA DOS OBJETOS DA BKPML Figura 3.6 Tipo complexo GrantObjectType O elemento complexo triggerobjecttype O elemento complexo TriggerObjectType destina-se a representar a estrutura de comando para criação de um objeto trigger ou gatilho. A definição da estrutura TriggerObjectType é composta por cinco elementos: <name>, <time>, <event>, <object>, <body> e o atributo order. Os elementos <name> e <time> destinam-se a manter o nome do gatilho e o tempo em que o comando será executado, antes ou depois de um determinado evento. Já os elementos <event> e <object> destinam-se a guardar em que evento o gatilho será executado (insert, update ou delete) e em que objeto. O último e mais importante elemento desta estrutura é o elemento <body> que destina-se a guardar a lógica ou o algoritmo executado pelo gatilho. A Figura 3.7 apresenta de forma detalhada a estrutura definida para o elemento complexo TriggerObjectType O elemento complexo methodobjecttype O elemento complexo MethodObjectType unifica dois objetos de sintaxes comuns, existentes na maioria dos SGBD comerciais, os objetos procedure e function. Esses objetos possuem o mesmo objetivo (execução de blocos de comandos). O desenvolvimento dessa estrutura foi unificado devido às poucas diferenças entre suas sintaxes. A principal diferença refere-se ao retorno ou não de valor. Em alguns SGBD, é implementado apenas o conceito de procedimentos, cujo retorno se dá através de seus parâmetros. Em funções, esse retorno é realizado através do nome da função. A estrutura MethodObjectType é composta por 3 elementos e 2 atributos, são eles: <name>, <parameter>, <result> e os atributos type e order. O elemento <name> é o nome do procedimento ou função a ser copiada. O elemento <parameter> representa os nomes e tipos de parâmetros associados ao 42

60 3.4. CONSIDERAÇÕES FINAIS Figura 3.7 Tipo complexo TriggerObjectType corpo do método. Esse elemento possui cardinalidade 0..1 para evitar a obrigatoriedade do mesmo, uma vez que um método pode ou não possuir parâmetros. O elemento <result> representa o tipo de valor que a função retornará. Esse campo possui cardinalidade 0..1 pois em caso de procedimento, este campo não será levado em consideração. O elemento <body> representa o bloco de comandos executados pelo método. O atributo type identifica que tipo de método está sendo mantido na estrutura: procedimento ou função, controlados pela tag restriction na estrutura. A Figura 3.8 apresenta a estrutura MethodObjectType. 3.4 Considerações Finais Tendo em vista as dificuldades encontradas nos processos de restauração e migração de dados, este capítulo apresentou a estrutura BKPML, elaborada como proposta para problemas voltados a restauração e migração de dados. BKPML foi projetada com intuito 43

61 3.4. CONSIDERAÇÕES FINAIS Figura 3.8 Tipo complexo MethodObjectType de desvincular a dependência dos arquivos de backup de dados de seus SGBD de origem, uma vez que essa dependência gera um grande esforço quanto à restauração/migração de dados em SGBD Heterogêneos. A idéia principal da BKPML é dar liberdade aos arquivos de backup para que os mesmos possam ser restaurados ou migrados para qualquer SGBD, independente da origem dos mesmos. Migrar e/ou restaurar dados para SGBD heterogêneos a partir dos arquivos de backup, é uma idéia que pode ajudar a reduzir o tempo e custo envolvidos em tais processos, pois com a padronização dos arquivos de backup, não mais será necessário a restauração dos dados no SGBD de origem, eles poderão ser restaurados diretamenta para o SGBD de destino. A seguir são descritas as principais vantagens apresentadas pela BKPML: Independência dos dados - com BKPML os dados já não mais pertencerão a tecnologias específicas e proprietárias. Esses dados poderão ser restaurados para qualquer SGBD, sem que haja necessidade de grandes esforços para que isso aconteça; Redução do tempo para migração - a utilização da BKPML para migração e restauração de dados em sistemas heterogêneos, propõe a redução de tempo e custo envolvidos nos processos de migração e restauração de dados em ambientes 44

62 3.4. CONSIDERAÇÕES FINAIS heterogêneos, através da redução de uma das fases do processo, que é a restauração dos dados em seu ambiente de origem; Estrutura padronizada - quando se deseja chegar à independência dos dados, é importante que se tenha uma estrutura padrão para que outros aplicativos possam saber como utilizar essa estrutura para persistir ou recuperar dados a partir de diferentes programas; e Independência de Tecnologia ou Ambiente - Como BKPML é uma linguagem derivada de XML, não se tem atrelado a essa tecnologia outras tecnologias que venham a manter certo grau de dependência entre a estrutura e uma tecnologia. Isso também se aplica à dependência entre ambientes operacionais. Por se tratar de uma nova linguagem de marcação, a BKPML necessitará de uma aplicação para gerar, restaurar, validar e migrar os dados a partir dos arquivos BKPML. O capítulo a seguir destina-se a apresentar o desenvolvimento da aplicação gerenciadora de arquivos BKPML, bem como abordar as tecnologias que facilitaram o desenvolvimento dessa aplicação e as principais características propostas para a mesma. 45

63 4 A Ferramenta: Backup Markup Language Manager (BKPML Manager) Backup de dados tem se tornado o principal alicerce para proteção e continuidade dos negócios de muitas empresas. Atualmente, o mercado disponibiliza inúmeras ferramentas que pressagiam a continuidade dos negócios através de backup de dados, mas com arquivos em formatos proprietários. O grande problema com esse tipo de formato é tornar os dados dependentes da ferramenta que os originou, dificultando ou até mesmo impossibilitando que outras ferramentas, da mesma área de atuação, possam manipular esses arquivos. Este capítulo tem por objetivo apresentar a BKPML Manager, uma ferramenta desenvolvida para gerar, manipular e gerenciar os arquivos em formato BKPML. Além disso, são apresentados de forma detalhada o desenvolvimento de sua arquitetura, as tecnologias utilizadas e os padrões de projeto da arquitetura, além da apresentação dos principais diagramas e funcionalidades implementadas na ferramenta. 4.1 Introdução Pelo fato da BKPML se tratar de uma nova linguagem de marcação, foi necessário o desenvolvimento de uma ferramenta, responsável por gerenciar as principais funcionalidades da criação de backups em formato BKPML. BKPML Manager é o nome dado à ferramenta desenvolvida para gerenciar e manter todos os artefatos obrigatórios para a geração da estrutura desse formato. Além disso, a ferramenta objetiva facilitar o uso dos processos de Backup, Restauração e Migração através de uma interface amigável. Como a BKPML Manager é uma ferramenta específica para uma determinada área, é evidente que, para utilização desta ferramenta, faz-se necessário ter ou obter profundos 46

64 4.1. INTRODUÇÃO conhecimentos sobre SGBD e a organização de suas tabelas internas, responsáveis por manter os dados e metadados de todos os objetos mantidos pelo sistema. A ferramenta BKPML Manager é baseada em uma arquitetura cliente-servidor (Tanenbaum, 2003), composta por um cliente Web gráfico, responsável por enviar requisições para o servidor de aplicações (Servlet Container) Tomcat6.0 (Tomcat, 2010), e se comunicar com um sistema de banco de dados MYSQL5.0 (MYSQL, 2010), através do driver JDBC disponível em Java foi a linguagem de programação utilizada para desenvolvimento da BKPML Manager, com isso, a BKPML Manager pode ser executada em qualquer servidor que utilize um sistema operacional compatível com a Java Virtual Machine (JVM) (JVM, 2010). Além disso, a BKPML Manager pode ser executada em qualquer computador com acesso à Internet, através de um navegador (Browser) como o Mozilla Firefox (Firefox, 2010) e o Internet Explorer (Internet Explorer, 2010). Além de sua portabilidade, garantida pela JVM, a BKPML Manager possibilita, de forma simples, o uso dos processos de Backup, Restauração e Migração de dados em qualquer plataforma gerenciadora de banco de dados. Para isso, os mesmos devem ser previamente cadastrados nas tabelas internas da ferramenta. Esse cadastro possibilita que um arquivo BKPML possa ser facilmente restaurado em qualquer SGBD, independente de qual SGBD essas informações foram oriundas. A Figura 4.1 apresenta a tela principal da BKPML Manager. Figura 4.1 Tela principal da BKPML Manager Para possibilitar uma visão macro dos principais processos executados pela ferramenta, bem como obter informações sobre as principais funcionalidades existentes, a Figura 4.2 apresenta o ciclo de vida dos processos de backup e restauração dos arquivos 47

65 4.1. INTRODUÇÃO BKPML em suas respectivas ordens de execução. Esses processos são apresentados pela figura em forma de camadas, possibilitando melhor visão da troca de mensagens entre as camadas que representam os principais serviços oferecidos pela BKPML Manager. Figura 4.2 Ciclo de vida dos processos de Backup/Restore da ferramenta BKPML Manager Dependendo do tipo de processo executado pelo ciclo, a leitura do mesmo poderá ser iniciada na camada Conectar Banco de dados e finalizada na camada Salvar/Recuperar arquivos, no caso do processo de backup. Já o processo de restauração, inicia-se na camada Salvar/Recuperar arquivos e finaliza na camada Conectar Banco de dados, caso os dados sejam restaurados em um SGBD, ou na camada Transformação, se a transferência dos dados for direcionada para arquivos secundários. O ciclo de vida dos processos de backup e restore só poderá ser iniciado se e somente se todos os cadastros obrigatórios forem realizados. As camadas de processos são apresentadas abaixo, de acordo com sua ordem de execução: Camada Conectar banco de dados - É a primeira camada a ser executada, pois é esta a responsável por extrair os dados desejados de um banco de dados e repassar os mesmos para a camada backup. Esta camada também é responsável por repassar os dados a serem restaurados para o seu SGBD de origem; Camada backup - A camada backup é responsável por transformar os dados repassados pela camada Conectar Banco de Dados em um arquivo de backup em 48

66 4.1. INTRODUÇÃO formato BKPML válido. Para isso, essa camada realiza as seguintes operações: Gerar BKPML, Compactar e Gerar Hash. A operação Gerar BKPML é responsável pela geração da estrutura BKPML a partir dos dados oriundos da camada Conectar Banco de dados. A operação Criptografar criptografa o arquivo BKPML gerado usando o algoritmo triple DES e encaminha o novo arquivo para a operação Compactar, que por sua vez comprime o arquivo facilitando o envio do mesmo para armazenamento em nuvens se necessário. Após isso, a operação Gerar Hash extrai o código hash do arquivo, para que a integridade do mesmo possa ser validada após sua restauração; Camada Salvar/Restaurar arquivo - essa camada é responsável pelo armazenamento e restauração dos arquivos em formato BKPML. Em um processamento de restauração de dados, essa camada é a primeira a ser executada, pois busca um arquivo solicitado e repassa para camada Restore iniciar seu ciclo de processamento; Camada Restore - Ao receber o arquivo solicitado da camada Salvar/Restaurar arquivo, a camada Restore executa a primeira de suas quatro operações existentes em seu ciclo. A operação Validar Hash recupera o hash do arquivo restaurado e compara com o hash do processamento de backup para verificar a integridade do arquivo. A operação Descompactar descompacta o arquivo e disponibiliza o arquivo criptografado para a operação Descriptografar, que após descriptografar envia o arquivo para a operação Restaurar BKPML fazer suas validações de estrutura e repassar os dados para a camada Transformação ou para camada Conectar banco de dados; e Camada Transformação - A camada transformação é responsável por aplicar transformações nos dados e transferi-los para os formatos desejados. Os formatos com suporte na ferramenta BKPML Manager são: Texto, Excel, XML, CSV, JSON e YAML. A camada transformação é executada quando solicitada, caso contrário, a camada Conectar banco de dados será executada para realizar a transferência dos dados para um SGBD de destino. Além de responsável pela execução do ciclo de processamento de backup e Restauração dos dados, a ferramenta BKPML Manager é também responsável pelas operações básicas e funcionalidades de cadastros necessários para início dos processos de backup, restauração e migração de dados. Essas funcionalidades estão disponíveis para acesso através de um menu, disponível na tela principal da ferramenta. Vale ressaltar que a ordem disposta no menu é a ordem 49

67 4.2. ARQUITETURA DA FERRAMENTA BKPML MANAGER de cadastros a ser seguida pelos usuários para se iniciar qualquer processo, tanto de backup quando de restauração de dados. A ferramenta BKPML Manager, por padrão, possui em sua base de dados interna o cadastro dos principais tipos, sintaxes e objetos e propriedades dos principais SGBD utilizados no mercado. A Figura 4.3 apresenta o menu com as opções de cadastros básicos a serem realizados antes de se iniciar os processos de backup, restauração e migração de dados e objetos. Figura 4.3 Menu da BKPML Manager Além de todas as funcionalidades e processos supracitados, a ferramenta BKPML Manager possui em sua arquitetura, o controle e registro de log (históricos) para todos os processamentos, backup, restore e migração dos dados, para facilitar a resolução de erros oriundos dos processamentos dos dados na ferramenta. Após o término de cada processamento, uma linha de log deverá constar na tela principal da BKPML Manager, conforme apresentado pela Figura 4.1, informando se o processamento foi realizado com sucesso ou com erro. 4.2 Arquitetura da ferramenta BKPML Manager Conforme mencionado, para o desenvolvimento da ferramenta, foram unidas todas as características conglomeradas em uma aplicação WEB, tendo em vista a crescente demanda de clientes que estão migrando suas preferências e utilizando aplicativos WEB para realização de suas atividades cotidianas. 50

68 4.2. ARQUITETURA DA FERRAMENTA BKPML MANAGER A estrutura da ferramenta BKPML Manager está baseada em um modelo cliente servidor, ou seja, há a separação dos modelos computacionais em modelo cliente e modelo servidor, bem como a integração de tais modelos utilizando uma rede de computadores para se comunicar através da troca de mensagens. A maioria das aplicações Web modernas realiza processamento e armazenamento de pequenos, médios e grandes volumes de dados. Para isso, é imprescindível manter a comunicação direta com um banco de dados que atenda essas necessidades. Nesse cenário, a arquitetura cliente servidor possibilita a melhor forma para organização dos dados e para troca de informações entre as camadas. A Figura 4.4 apresenta a arquitetura utilizada. Figura 4.4 Arquitetura da BKPML Manager A arquitetura desenvolvida foi dividida em três camadas, com o objetivo de facilitar o entendimento e demonstrar de forma clara como as requisições são realizadas entre cada camada. As seções a seguir destinam-se à explicação de cada uma das camadas, bem como às tecnologias utilizadas para o desenvolvimento das mesmas A camada Cliente A camada cliente é a parte gráfica da aplicação que é apresentada por um navegador (browser) pelo qual o cliente tem acesso direto à aplicação. É nessa camada que o cliente irá manipular suas requisições para realização de cadastros, execução de processamentos, geração de relatórios, entre outras funcionalidades disponíveis na ferramenta. Para o desenvolvimento dessa camada foram utilizadas as seguintes tecnologias: 51

69 4.2. ARQUITETURA DA FERRAMENTA BKPML MANAGER Hypertext Markup Language (HTML) (Markup, 2010) - HTML foi utilizada para formatar o layout das páginas e se beneficiar dos principais objetos utilizados pela ferramenta, tais objetos são: textos, botões, tabelas, links, entre outros. A formatação do estilo do layout ficou a cargo do CSS; Cascading Style Sheets (CSS) (CSS, 2010) - foi utilizado CSS para criação de estilo e formatação do layout da página e dos objetos, botões, textos, tabelas, cores, entre outros, e para a criação e formatação do menu de opções da ferramenta; JavaServer Pages (JSP) (JSP, 2010) - JSP foi utilizado como ambiente mediados (páginas) para uso e integração das tecnologias JSTL, JAVA e HTML. Além disso foram utilizadas algumas bibliotecas e marcações da JSP para formatação e entrada dos dados. Javaserver page Standard Tag Lib (JSTL) (JSTL, 2010) - JSTL é usada para fazer a comunicação entre a camada de negócios e a camada de visão, além da manipulação de estruturas de dados como lista, variáveis, objetos, entre outros; e Java Script (Flanagan, 2002) - JavaScript foi utilizado para desenvolvimento de métodos e funções para a validação de campos, criação de objetos dinâmicos, ações dinâmicas existentes nas páginas e submeter as páginas através do método post, que consiste em transmitir os dados de uma página WEB para o servidor de aplicação (Servlet Container) Lições Aprendidas O desenvolvimento da camada cliente foi desafiador, uma vez que tecnologias como CSS, JSTL, tags do struts2, entre outras, foram novidades no momento do desenvolvimento da aplicação, sem contar com a falta de experiência para configuração e uso das tecnologias utilizadas. Para isso, foi necessária a realização de uma extensa pesquisa para entendimento, avaliação e conhecimento das formas como essas tecnologias poderiam ser utilizadas para compor a camada cliente de forma a satisfazer as necessidades para desenvolvimento da ferramenta. No início do desenvolvimento, foram utilizadas as tags do struts2 para realizar a comunicação entre a camada de visão (cliente) e a camada de negócios (servidor). Mas no decorrer do projeto, foi notado que alguns objetos pertencentes a essas tags como, buttons, textbox, listbox, entre outros objetos, não mantinham o alinhamento correto nas páginas, o que deixava o layout das páginas ilegível. 52

70 4.2. ARQUITETURA DA FERRAMENTA BKPML MANAGER O problema com a formatação das páginas que utilizavam as tags do struts2 poderia ter sido revertido através da utilização de CSS, para reformular a posição de cada objeto. O principal problema nessa técnica é o tempo levado para formatar a posição de cada objeto da página, sem contar que essa posição muda de acordo com a funcionalidade utilizada. A alternativa tomada para resolução desse problema foi a utilização dos objetos HTML, vinculada ao poder da JSTL para manter a comunicação entre a camada de negócios e a camada de visão, deixando o CSS apenas na formatação do layout principal das páginas A camada Servidor A camada servidor é responsável por processar e responder às requisições enviadas pela camada cliente. Todo processamento é realizado através da aplicação disponibilizada na camada servidora, que com a ajuda de um servidor de aplicação ou um container de servlet como o Tomcat (neste caso), a aplicação torna-se disponível para acesso através de um navegador. Observa-se que na camada servidor tem-se três artefatos disponibilizados. O primeiro é o artefato container de servlet, que utiliza o Tomcat como servidor WEB para carregar as aplicações nele disponibilizadas. A seguir, tem-se o artefato Aplicação, que representa a aplicação BKPML Manager disponível no servidor e pronta para ser executada pelo mesmo. O último artefato disponibilizado na arquitetura da BKPML Manager é o artefato Drivers. O termo foi utilizado no plural porque para cada SGBD cadastrado, deve-se ter um driver vinculado que possibilite a ferramenta realizar a conexão com o SGBD correspondente. Esses drivers, de um modo geral, são utilizados para fazer que com a ferramenta BKPML Manager possa se comunicar com os SGBD registrados na aplicação para realização de transações. Abaixo são descritas todas as tecnologias utilizadas nas camadas e artefatos supracitados: Tomcat (Tomcat, 2010) - A tecnologia de servidor de aplicação Tomcat é representada pelo artefato Container de servlet. Conforme já comentado, Tomcat está sendo utilizado para disponibilização e execução da BKPML Manager através da WEB; Struts2 (Struts2, 2010) - Esse framework é utilizado no artefato Aplicação e faz o controle das requisições entre as camadas modelo, visão e controle existentes na 53

71 4.2. ARQUITETURA DA FERRAMENTA BKPML MANAGER estrutura da ferramenta BKPML Manager. Feito o controle dessa camada através do struts2, foi utilizado o framework Hibernate3 (Gonçalves, 2007) para controle e gerenciamento de persistências entre as camadas Servidor e SGBD; Hibernate3 (Gonçalves, 2007) - O Hibernate é utilizado para facilitar o mapeamento dos atributos entre a base de dados tradicional e o modelo de objetos da aplicação. Esse framework utiliza o artefato Drivers para manter a comunicação entre a camada SGBD; DOM4J (Beat, 2010) - é um framework para leitura e criação de arquivos XML em aplicações Java. Como a ferramenta BKPML Manager trabalha criando arquivos em formato BKPML, a utilização do framework DOM4J é crucial para os processos de Backup, Restauração e Migração de dados nesse formato; Xerces (Xerces, 2010) - Na ferramenta BKPML Manager o framework Xerces é responsável pela validação dos arquivos BKPML gerados através de seu XML schema; e Database Drivers for Java - A ferramenta BKPML Manager mantém toda sua base de dados no SGBD MYSQL5.0, além de realizar transações com diversos SGBD como POSTGRES, ORACLE e SQL SERVER. Para isso, a BKPML Manager necessita manter em sua estrutura um driver para cada SGBD cadastrado, pois é a partir deles que a aplicação iniciará a conexão para realizar transações de consulta, inserção ou alteração dos dados. Esses drivers são representados pelo artefato Drivers localizado na camada Servidor Lições Aprendidas No processo inicial do desenvolvimento da arquitetura, foram pesquisados diversos plugins e frameworks para gerenciamento das mensagens entre as camadas modelo, visão e controle. Dentre eles, apenas dois frameworks foram classificados para testes iniciais da arquitetura: JSF (JSF, 2010) e STRUTS2. Como a BKPML Manager se trata de uma ferramenta Open Source, os critérios escolhidos para classificação dos plug-ins e frameworks foram, facilidade para uso e manutenção, utilização e aceitação dos mesmos no mercado. Após a escolha e realização de testes, o framework STRUTS2 foi escolhido para compor a arquitetura. Os motivos que levaram a essa escolha foram simplicidade de manipulação, fácil utilização sem muitas configurações, facilidade de manutenção e integração com outras tecnologias. 54

72 4.3. PADRÕES DE PROJETO UTILIZADOS Outro fator importante quanto ao desenvolvimento da arquitetura é a utilização de padrões de projeto (design pattern) para compor a arquitetura e facilitar o desenvolvimento, reuso e manutenção da aplicação, além de deixar o código padronizado e legível. A aplicação de padrões em uma arquitetura não é algo trivial, pois, para isso, é necessário conhecer bem o padrão a ser aplicado, bem como, onde aplicar, para que o projeto possa usufruir das vantagens propostas. Para isso, antes de se escolher um padrão, é necessário que se tenha conhecimento de quais objetos irão compor a arquitetura do projeto e qual grau de relação entre eles. De acordo com FOWLER (2003); Kerievsky (2005) os padrões, apesar de vantajosos, devem ser utilizados com moderação, devem ser usados de forma cautelosa no projeto que venha a se beneficiar de sua utilização. Em outras palavras, segundo Ambler (2002), se suspeita-se que um padrão seja aplicável, deve-se modelá-lo de modo a implementar a mínima funcionalidade de que se precisa hoje, mas que se torne fácil de refazer mais tarde, caso necessário, ou seja, não modele em excesso A Camada SGBD Essa camada representa todos os drivers responsáveis por manter a conexão entre os SGBD cadastrados. Inicialmente, a ferramenta mantém em sua biblioteca de componentes os principais drivers para conexão com os SGBD mais utilizados no mercado, como Oracle, MySql5.0, Postgre8.4 e SQL Server, conforme mencionado, qualquer SGBD diferente dos apresentados, os drivers devem ser adicionados de forma manual e a ferramenta recompilada. Além dos componentes supracitados, a arquitetura da BKPML Manager se beneficia com a utilização de três padrões de projeto que facilitam a comunicação entre as classes internas e reduzem o alto acoplamento entre as mesmas. Os tópicos a seguir abordam os padrões de projeto utilizados na arquitetura, bem como apresentar os benefícios encontrados pelo uso dos mesmos no projeto. 4.3 Padrões de projeto utilizados A definição de padrões de projeto pode ser resumida em: personalização de classes e objetos comunicantes para resolver um problema geral de objetos num contexto particular (GAMMA et al., 1995). Para que se possa usufruir dos benefícios oferecidos pelos padrões de projeto, faz-se necessário obter profundos conhecimentos sobre os mesmos, saber a devida aplicabilidade na arquitetura, além da seleção de padrões de projeto simi- 55

73 4.3. PADRÕES DE PROJETO UTILIZADOS lares, e compará-los para então verificar o que melhor proporciona flexibilidade e reuso na arquitetura. Considerando que todo projeto tende a ser alterado a cada novo requisito solicitado, a arquitetura da BKPML Manager foi definida com base em padrões de projeto, que oferecem diversas vantagens para facilitar a implementação de novas funcionalidades ou manutenções das já existentes. A evolução do paradigma orientado a objetos faz com que a arquitetura de software torne-se flexível em relação a aspectos como manutenibilidade e reuso, e o uso de padrões de projeto vem apresentar modelos que viabilizam tais aspectos. As funcionalidades da BKPML Manager beneficiadas pelos padrões de projeto são processo de backup, restauração de dados, cadastros básicos, transformação dos dados e a troca de mensagem entre as camadas apresentadas. O primeiro padrão implantado na arquitetura foi o padrão DAO (DAO, 2010), responsável por gerenciar todas as requisições referentes à camada de persistência. Com a utilização desse padrão, todas as requisições aos dados passam a ser encaminhadas diretamente às classes do padrão DAO. Esse padrão de projeto pode ser desenvolvido de acordo com as necessidades de cada projeto. A seção abaixo apresenta a aplicabilidade do padrão DAO na arquitetura, bem como aborda os outros padrões utilizados Aplicando o padrão Data Access Object (DAO) Gonçalves (2007) comenta que, quanto ao desenvolvimento de aplicações utilizando JDBC, colocar instruções de consulta em meio aos códigos torna o código fonte ilegível e de difícil manutenção. O padrão DAO fornece uma interface independente, que é usada para persistir objetos de dados. A ideia é centralizar as funcionalidades de acesso aos dados em um só local, ou seja, sempre que houver a necessidade de acesso aos dados de uma aplicação, a utilização deste padrão é a melhor a ser empregada. Dependendo da maneira que se utiliza o padrão DAO, pode ser necessário implementar um DAO para cada classe de objetos em sua aplicação, ou pode-se usar um único DAO, responsável por todos os seus objetos. A arquitetura da BKPML Manager implementa um DAO para cada classe de entidade, bem como a utilização das características genéricas de Java5.0, permitindo que uma classe Java possa ser parametrizada com diferentes tipos, conforme apresentado pela Figura 4.5. A principal motivação para o desenvolvimento de uma classe DAO para cada classe de persistência foi que, além das classes possuírem todas as características herdadas de classe mãe Genericdao, cada classe de persistência possui também suas próprias caracte- 56

74 4.3. PADRÕES DE PROJETO UTILIZADOS Figura 4.5 Padrão DAO da BKPML Manager 57

75 4.3. PADRÕES DE PROJETO UTILIZADOS rísticas, o que impossibilita o desenvolvimento de uma única classe para gerenciamento de todas as classes de persistência existentes na arquitetura. Um exemplo disso é a classe Databasedao, que além de herdar os métodos padrãos da classe mãe, a mesma implementa métodos extras para conexão com outros bancos de dados via JDBC ao invés de hibernate. Como a ferramenta BKPML Manager possibilita a conexão com vários SGBD, essas conexões extras são realizadas via JDBC, deixando o hibernate gerenciar apenas os dados da ferramenta. Outros métodos que motivaram a criação de uma classe DAO para cada entidade foram os métodos copydata que informa a cada classe como e quais dados transferir para um objeto, o método validate que diz a cada classe como validar seus dados, e a sobrecarga do método getbyid que para algumas classes é realizado de forma diferente do método herdado da classe mãe. Com a implantação do padrão de projeto DAO na arquitetura, nota-se inúmeras vantagens quanto à reutilização de código, uma vez que não houve a necessidade de escrever em cada classe os métodos salvar, alterar, excluir e buscar, deixando apenas o desenvolvimento de características incomuns de cada classe Aplicando o padrão Decorator O padrão Decorator tem por finalidade fornecer uma maneira de anexar novos estados, comportamentos e características a um objeto de forma dinâmica (GAMMA et al., 1995; SHALLOWAY and TROTT, 2002). As operações de backup e restauração de dados da ferramenta BKPML Manager são beneficiadas por este padrão estrutural de projetos. A Figura 4.6 apresenta o diagrama de classes do padrão de projeto Decorator implementado na arquitetura. Suponha-se que seja necessário que o objeto Operations, responsável pela execução das operações de backup e restore precise iniciar um processo para realização de backup de dados; para isso, faz necessário a declaração de uma variável do tipo Operations que instancie a classe Backup e dentro do parâmetro do construtor da classe Backup, deve-se instanciar as classes decorators BKPML, Cripto, Compression e Hash. Após isso, o método execute deve ser chamado, conforme apresentado pela Figura 4.8 linha 11. Quando executado, o decorator repassa a solicitação de execução para os componentes de ações adicionais (backup ou Restore). Após isso, os decorators adicionam novas características à classe que utilizará o padrão Decorator de forma recursiva. Esse tipo de execução permite que um número ilimitado de características ou funcionalidades seja adicionado ao objeto aplicando o padrão decorator a classe desejada. 58

76 4.3. PADRÕES DE PROJETO UTILIZADOS Figura 4.6 Padrão Decorator da BKPML Manager A classe mãe Operations possui todos os métodos comuns entre as classes, neste caso, os métodos execute() e addloghistoric(). As classes Backup e Restore são classes responsáveis por adicionar, de forma dinâmica, novos comportamentos a um objeto. Essas classes estendem a classe Operations, que é responsável por iniciar os métodos a ela repassados, conforme exemplo abaixo apresentado pela figura 4.7. Figura 4.7 Instanciando uma classe backup/restore A classe Decorator estende a classe Operations e para cada decorator instanciado tem-se um componente de operations, neste caso o método execute é esse componente. Isso significa que o decorator tem uma variável de instância que contém a referência para acesso a esse componente. Por fim, têm-se as classes decorators: BKPML, Cripto, Compression e Hash, nas quais os decorators adicionam novos comportamentos aos 59

77 4.3. PADRÕES DE PROJETO UTILIZADOS objetos. É importante observar que os docorators precisam implementar o método execute(). Abaixo é apresentado um exemplo do uso do padrão decorator na arquitetura da BKPML Manager, na Figura 4.8. Figura 4.8 Aplicando o padrão decorator a um objeto backup No exemplo, é executado o backup para ação com código 1. Este backup utiliza as classes decorators: gerar arquivo BKPML, Comprimir arquivo e extrair o código hash. Nesse processo não foi necessário criptografar o arquivo gerado, mas se preciso, bastaria apenas adicionar o decorator Cripto e o resultado final será um arquivo de backup criptografado. O processo de restore utiliza as mesmas classes, mas que realizam operações inversas do processo de backup de dados Aplicando o Padrão de projetos Strategy Outro padrão utilizado na arquitetura da ferramenta é o padrão Strategy, que como visto, é uma família de algoritmos encapsulados e intercambiáveis, permitindo que os algoritmos variem independente do cliente que o utilize. A ferramenta BKPML Manager utiliza esse padrão de projetos para gerenciar o processo de transformação dos dados, uma vez que nesse processo utiliza-se uma família de algoritmos responsáveis por transformar os dados para arquivos externos. A Figura 4.9 apresenta o diagrama de classe do padrão Strategy implementado na arquitetura. O diagrama de classes do padrão de projetos Strategy, implementado na arquitetura da BKPML Manager, é constituído de uma classe mãe abstrata e seis subclasses. A classe abstrata Transformation representa o supertipo abstrato, que poderia ser representado por uma interface ou uma classe abstrata. Na BKPML Manager, foi utilizada a segunda alternativa, contendo todos os métodos comuns entre as subclasses, que devem se responsabilizar apenas pela implementação concreta dos métodos herdados. 60

78 4.3. PADRÕES DE PROJETO UTILIZADOS Figura 4.9 Padrão Strategy da BKPML Manager Todas as novas classes herdadas de transformação precisam apenas implementar o método execute(). As subclasses de transformação devem possuir diferentes algoritmos executados pelo seu método execute (). Nesse contexto, caso seja considerada uma solicitação para uma nova transformação, HTML, por exemplo, o procedimento a ser tomado nessa situação seria apenas criar uma subclasse que estenda Transformation e implemente no método execute() o algoritmo necessário para essa transformação. A partir desse exemplo, é possível perceber que há uma grande vantagem da utilização do padrão de projetos Strategy em uma arquitetura que tende a estar em constantes mudanças Aplicando o Padrão de projetos Model View Controller (MVC) Como a BKPML Manager é baseada em uma arquitetura Web, o padrão de projetos MVC foi utilizado para dividir a arquitetura do projeto em camadas, facilitando o uso e manutenção do mesmo. Inúmeros são os frameworks encontrados para implementação desse padrão, sendo que: Java Server Faces (JSF) (JSF, 2010), Spring MVC (HEM- RAJANI, 2005) e Struts são os mais conhecidos, utilizados e discutidos pelos usuários das comunidades Java. Após análise e teste dos mesmos, o framework escolhido para utilização no projeto da BKPML Manager foi o Struts2. A implantação do MVC em uma arquitetura é organizada através da divisão das 61

79 4.3. PADRÕES DE PROJETO UTILIZADOS camadas de modelo, visão e controle, e o framework Struts2 para gerenciamento das requisições. A separação das camadas na arquitetura da BKPML Manager se deu através da divisão dos artefatos de cada camada em pacotes. O controle entre as camadas ficou sob responsabilidade do Struts2, para isso, fez-se necessário o mapeamento dos controladores e visões no arquivo Struts.XML. Já, para implementação e mapeamento dos modelos, foi utilizado JavaBeans (Gonçalves, 2008) e Hibernate3.0. A camada visão, responsável pela exibição dos modelos na interface com o usuário, foi implementada utilizando as tecnologias JSP e HTML. Visualmente, a implementação do MVC na arquitetura da BKPML Manager é representada na Figura Figura 4.10 Arquitetura MVC O modelo MVC pode ser empregado em qualquer tecnologia para separação dos papéis entre modelo, visão e controle. Essa separação é um dos princípios mais importantes de um projeto de software. Na BKPML Manager o controlador foi separado da visão por razões de organização da arquitetura, embora essa integração seja feita novamente sob responsabilidade do framework struts2. 62

80 4.4. FUNCIONALIDADE DA BKPML MANAGER 4.4 Funcionalidade da BKPML Manager A ferramenta BKPML Manager é constituída de dezessete funcionalidades, das quais onze são destinadas à configuração dos processos básicos, obrigatórios para uso das funcionalidades de backup, restauração e migração de dados. O restante das funcionalidades é usado para controle interno da ferramenta. Para melhor entendimento das funcionalidades, a Figura 4.11 apresenta o diagrama de casos de uso com todas as funcionalidades presentes no escopo da ferramenta. É importate ressaltar que as funcionalidades descritas por esta seção limitam-se apenas aos cadastros obrigatórios para configuração e uso das funcionalidades backup, restauração e migração de dados, bem como a descrição sucinta das mesmas. As funcionalidades da BKPML Manager foram divididas em quatro módulos, acessados através do menu principal da ferramenta. No primeiro, foram unificadas todas as funcionalidades para cadastros e configurações obrigatórias para uso da ferramenta. Tais funcionalidades podem ser acessadas através da opção Cadastros básicos, disponível na tela principal da ferramenta. No segundo, encontram-se todas as funcionalidades utilizadas para geração, restauração e migração de arquivos de backup BKPML. Essas funcionalidades podem ser acessadas através da opção Funcionalidades. Nos últimos, encontram-se o gerador de relatórios, utilizado para análise dos dados copiados e o monitoramento dos dados, que como o próprio nome diz, é utilizado para monitorar os processos em andamento, parados, com erros, entre outros. Esses módulos estão disponíveis através das opções Relatórios e Monitoramento localizados no menu principal da ferramenta. Para facilitar o uso e localização das funcionalidades na ferramenta, as mesmas serão apresentadas de acordo com as divisões supracitadas. Sendo assim, as divisões serão restritas aos módulos cadastros básicos e funcionalidades, uma vez que nesses se encontram todas as funcionalidades obrigatórias para uso adequado da ferramenta. As funcionalidades encontradas no módulo de cadastros básicos são: Manter tipos, sintaxes e objetos - Utilizada para registar os tipos, sintaxes e objetos não encontrados nas tabelas internas da ferramenta, uma vez que por padrão, a BKPML Manager possui o cadastro de tipos básicos (inteiro, real, lógico, numérico, entre outros), das sintaxes básicas (se, senão, então, enquanto, para, entre outros), e dos objetos aceitos pela estrutura BKPML (table, view, trigger, entre outros). É importante frisar que esses cadastros são de grande importância para o 63

81 4.4. FUNCIONALIDADE DA BKPML MANAGER Figura 4.11 Diagrama de Caso de Uso da BKPML Manager 64

82 4.4. FUNCIONALIDADE DA BKPML MANAGER correto funcionamento da ferramenta; Manter SGBD - Funcionalidade responsável pelo cadastro e teste de conectividade dos SGBD utilizados pela ferramenta para backup, restauração e migração de dados. Tanto SGBD de origem (fonte de dados para backup), quanto SGBD de destino (repositórios de dados) devem ser devidamente cadastrados; Manter Armazenamento - A BKPML Manager exige que, para iniciar um processamento de backup de dados, o mesmo deverá estar associado a um local de armazenamento. Além disso, a ferramenta permite cadastrar inúmeros armazenadores, tanto local quando em nuvens, que servirão como repositórios de dados a um ou mais processos de backup de dados. Essa funcionalidade destina-se ao cadastro desses repositórios; Manter Propriedades - Essa funcionalidade é responsável por cadastrar todos os metadados dos objetos aceitos pela estrutura BKPML. Esse cadastro é de grande importância para realização do mapeamento entre os metadados da BKPML e dos objetos do SGBD. Por padrão a BKPML Manager possui em sua base de dados o cadastro de todas as propriedades (metadados) para todos os objetos aceitos pela estrutura BKPML; Mapear SGBD - Essa funcionalidade mapeia todas as propriedades dos objetos cadastradas na funcionalidade manter propriedades, com as propriedades dos objetos dos SGBD, informando à ferramenta onde e como buscar a propriedade mapeada nas tabelas de metadados dos SGBD. Em resumo, esse mapeamento é um relacionamento DE-PARA entre as propriedades da BKPML e as dos SGBD; Manter Tipos, Sintaxe e Objetos por SGBD - Esses cadastros também são relacionamentos do tipo DE-PARA. É a partir deles que são feitas as relaçãos DE- PARA entre os tipos e sintaxes da ferramenta, com os tipos e sintaxes dos SGBD. Para isso, o usuário deverá informar o SGBD desejado, o tipo ou sintaxe, e informar sua equivalência. Já o cadastro de Objetos por SGBD destina-se à geração de consultas (queries) para obtenção dos metadados informados na funcionalidade Maper SGBD; e Criar ação de backup - Ação é o cadastro das configurações para execução de um backup de dados. No cadastro de ações defini-se o objeto a ser copiado, a data de início para execução, a hora, o repositório de armazenamento de dados, entre 65

83 4.5. CONSIDERAÇÕES FINAIS outras informações referentes à configuração de um backup de dados. Após esse cadastro o processo de backup pode ser iniciado. As funcionalidades encontradas no módulo Funcionalidades são: Gerar backup - Essa funcionalidade tem por objeto a geração de arquivos em formato BKPML de acordo com as configurações previamente informadas na tela de Criar ação de backup. Tal funcionalidade dá início à execução dos processamentos responsáveis pela geração do backup dos dados. A execução desses processos inicia-se através do clique com o mouse no botão de execução da ação desejada; Restaurar dados - Essa funcionalidade restaura os arquivos BKPML nos bancos de dados cadastrados. Conforme se pode observar na Figura 4.11, esse caso de uso estende duas funcionalidades, transferir e transformar. A funcionalidade transferir faz a transferência dos dados do arquivo BKPML para um SGBD de destino. Já a funcionalidade transformar converte os dados para arquivos externos de diversos formatos (CSV, XLS, JSON, YAML e XML). É importante ressaltar que essa funcionalidade utiliza apenas arquivos BKPML de objetos não complexos, ou seja, apenas objetos do tipo tabela. Os demais objetos são utilizados pela funcionalidade Migrar dados complexos; e Migrar dados complexos - É a funcionalidade utilizada para migração de dados complexos. São considerados complexos todos os objetos que necessitam de análise visual ou alteração manual em sua estrutura. A ferramenta BKPML Manager considera como complexo todos os objetos, com excessão do objeto tabela. A grande diferença dessa funcionalidade para a funcionalidade de migração de dados é que nessa os dados sofrem análise visual e alterações manuais, enquanto que na de restauração os dados são migrados de forma direta, sem que haja intervenção do usuário para isso. 4.5 Considerações finais Este capítulo apresentou o protótipo da ferramenta BKPML Manager, cuja proposta é a criação de backups de dados em formato BKPML e sua restauração e migração em diversos SGBD, bastando para isso que os mesmos estejam devidamente cadastrados na base de dados da BKPML Manager. Este Capítulo foi dividido em quatro partes: a primeira destina-se a apresentar a ferramenta BKPML Manager, o ciclo de vida dos 66

84 4.5. CONSIDERAÇÕES FINAIS principais processos (backup e restauração) e a apresentação em ordem de prioridade das funcionalidades com suporte na ferramenta. A segunda parte destinou-se a apresentar a arquitetura cliente/servidor da ferramenta. Tal arquitetura foi dividida em três camadas: a camada cliente, a camada servidora e a camada SGBD. Na apresentação de cada camada são abordadas todas as tecnologias que a compõem. Em alguns casos foram descritos tópicos de lições aprendidas no decorrer da fase de elaboração e desenvolvimento da arquitetura. A terceira parte foca os padrões de projeto utilizados na arquitetura, com objetivo de facilitar a manutenção da mesma, bem como torná-la reutilizável. Para facilitar o entendimento dos mesmos, são apresentados os diagramas de classe referentes a cada padrão apresentado. Por fim são apresentadas de forma detalhada as principais funcionalidades disponíveis na ferramenta BKPML Manager, desde o módulo de cadastro, apresentado em suas respectivas ordens de cadastro, até o módulo de funcionalidades, as quais são constituídas por backup, Restauração e Migração de dados complexos. 67

85 5 Estudo de caso Após a conclusão do desenvolvimento da ferramenta, foram iniciados os testes para avaliação dos cadastros básicos, das funcionalidades de backup, restauração e migração de dados, e do desempenho da ferramenta quanto a pequeno, médio e grande volume de dados. Para início dos testes, foi necessário a realização dos mesmos em ambiente real, para análise de aceitação da ferramenta em empresas de pequeno porte e desempenho da mesma em diferentes ambientes. Este capítulo destina-se a apresentar o estudo de caso realizado em uma empresa de consultoria e treinamento em tecnologia da informação e gerenciamento de projetos, localizada na cidade de Manaus. 5.1 Apresentação da empresa e domínio do problema Primeiramente foi realizada uma pesquisa com um conjunto de empresas de pequeno porte da cidade de Manaus. Empresas essas que em sua grande maioria destinam-se a serviços de consultoria e treinamento nas áreas de tecnologia da informação, gerenciamento de projetos e gestão empresarial. As buscas foram feitas através da Internet, e o contato via . Apenas uma das empresas procuradas concordou em participar dos testes, a empresa Knowhow consultoria. Essa empresa não permitiu a divulgação e acesso a todos os dados, mas autorizou o uso restrito do sistema para testes com a ferramenta BKPML Manager. Mediante a oportunidade cedida, com ajuda de profissionais da empresa, foi configurado o ambiente para início dos testes. A Knowhow consultoria cedeu acesso a uma área restrita do seu sistema de acompanhamento de serviços e avaliação de cursos. Para resguardar informações confidenciais de clientes e da própria empresa, a Knowhow consultoria elaborou uma lista de objetos públicos cujas informações poderiam ser divulgadas e testadas, conforme apresentado 68

86 5.1. APRESENTAÇÃO DA EMPRESA E DOMÍNIO DO PROBLEMA pela Tabela 5.1. Tabela 5.1 Objetos do estudo de caso Ordem Objeto Tipo 1 TBL_CURSO TABELA 2 TBL_EMENTA TABELA 3 TBL_SERVICOS TABELA 4 FNC_INSERIR_CURSO FUNCTION 5 FNC_DELETAR_CURSO FUNCTION 6 PRC_LISTAR_EMENTA PROCEDURE 7 FNC_ALTERAR_SERVICOS FUNCTION 8 VEW_CURSO_EMENTA VIEW 9 TRG_EXCLUIR_EMENTA TRIGGER 10 IDX_BY_DATA_COURSE INDEX O estudo de caso se iniciou com o entendimento de cada objeto cedido pela empresa. O primeiro objeto refere-se à tabela TBL_CURSO. Esse objeto contém informações referentes aos cursos ministrados pela empresa. A tabela TBL_EMENTA é responsável por manter os dados da ementa dos cursos oferecidos pela empresa. Nesse cenário um curso pode conter um ou mais itens de ementa. A tabela TBL_SERVICOS armazena as informações dos serviços prestados pela empresa. Os objetos FNC_INSERIR_CURSO e FNC_DELETAR_CURSO são objetos do tipo método, responsáveis pelo controle de inserção e exclusão de registros da TBL_CURSO. O método FNC_LISTAR_EMENTA lista o curso e sua respectiva ementa, a partir do ID do curso passado como parâmetro para o método. O método FNC_ALTERAR_SERVI - COS altera os registros dos serviços prestados pela empresa. O objeto visão VEW_CURSO_EMENTA é a visão responsável por exibir o curso e sua respectiva ementa, essa visão é utilizada pelo método FNC_LISTAR_EMENTA. O gatilho TRG_EXCLUIR_EMENTA é responsável por excluir a ementa de um curso, esse é executado de forma automática toda vez que um curso é excluído. O objeto IDX_BY_DATA_COURSE é o índice criado para agilizar a busca de cursos pelo campo data. O estudo de caso propõe a geração de backup, restauração e migração dos objetos listados na Tabela 5.1. Esses objetos estão localizados em um dos servidores da empresa, armazenados no SGBD MYSQL5.0. A restauração e migração dos objetos após o backup serão realizadas para os SGBD POSTGRES 8.4 e ORACLE EXPRESS. 69

87 5.2. PREPARANDO O AMBIENTE PARA EXECUÇÃO DO BACKUP O primeiro passo para iniciar o processo de backup dos dados é iniciar a preparação do ambiente. Para isso, as seções a seguir apresentam de forma didática os passos necessários para a criação do backup dos dados. 5.2 Preparando o ambiente para execução do backup Antes de dar início ao processo de backup de dados, é necessário conhecer e realizar todas as etapas obrigatórias envolvidas na preparação do ambiente de execução desse processo. Essas etapas foram divididas em quatro funcionalidades básicas de cadastro: cadastro de SGBD, cadastro de armazenadores, mapeamento de propriedades de objetos por SGBD, e cadastro de objetos por SGBD. Todos os quatro cadastros básicos são de grande importância para a realização do processo de backup de dados, uma vez que esse processo é composto por todas as informações cadastradas por essas funcionalidades. A não realização de uma dessas etapas pode comprometer um ou mais processos envolvidos na geração de backup dos dados. Todas as funcionalidades de cadastros básicos são disponíveis para acesso através do menu, localizado na tela principal da ferramenta. As funcionalidades de cadastros básicos serão apresentadas de forma simplificada, uma vez que não há dificuldades na realização dessas etapas, ou seja não serão abordados detalhes sobre preenchimento de informações, apenas as telas consideradas importantes serão apresentadas para se obter melhor ideia desses processos. A primeira etapa refere-se à funcionalidade de cadastro de SGBD. Essa atapa é responsável pelo cadastro e testes de todos os SGBD envolvidos em um processo de backup, restauração e migração de dados. Para realizar tal tarefa, deve-se clicar com o mouse na opção SGBD no menu principal, opção cadastros básicos, e iniciar o cadastro dos SGBD. Nesse caso, foram cadastrados os SGBD MYSQL5.0, POSTGRES8.4 e o ORACLE XE. Para realização dos testes de conexão, a BKPML Manager dispõe, em sua biblioteca, dos principais drivers JDBC utilizados para conexão com os SGBD supracitados, incluindo o Sql Server. Para uso de qualquer outro SGBD, faz-se necessária a inserção do respectivo driver JDBC na biblioteca da ferramenta e a recompilação da mesma, para que as modificações possam ser efetivadas. A segunda etapa é a funcionalidade de cadastro de armazenadores, a qual tem por objetivo realizar o cadastro de todos os repositórios de dados que serão utilizados para armazenamento dos arquivos de backup gerados. Os locais de armazenamento são clas- 70

88 5.2. PREPARANDO O AMBIENTE PARA EXECUÇÃO DO BACKUP sificados em dois tipos: local e em nuvens. No armazenamento local, deve-se informar o endereço onde se deseja armazenar os dados. Esse endereço pode ser um diretório local ou remoto. Para o armazenamento de dados em nuvens, a ferramenta BKPML Manager utiliza o serviço Simple Storage Service (S3) da Amazon Web Services. Para isso, o usuário deverá possuir uma conta no site e adquirir as chaves de acesso e secreta. Além disso, o usuário deverá solicitar acesso ao serviço S3, de acordo com os pacotes disponibilizados pela Amazon Web Services. No momento dos testes, essa funcionalidade foi questionada pela equipe técnica da Knowhow nos seguintes aspectos: o que aconteceria se o diretório informado não existisse? E se o nome do diretório informado for inválido? Em resposta aos questionamentos, quando o processamento de backup verifica a inexistência do diretório cadastrado, a mesma se responsabiliza por gerar o diretório de acordo com os níveis informados. No caso de ser um nome inválido, um erro é retornado ao usuário, e o processo de backup é cancelado. A terceira etapa é a funcionalidade de mapeamento de propriedades de objetos por SGBD. Por definição, uma propriedade é um atributo ou característica que define um objeto ou parte dele. Por exemplo, as propriedades que definem um objeto tabela são nome da tabela, campos da tabela, tipo de dados dos campos, entre outros. Todo SGBD tem salvo em suas tabelas internas essas informações (metadados) e são essas tabelas que precisam ser mapeadas para que a ferramenta possa saber onde e como montar a estrutura de metadados dos objetos em BKPML. A BLPML Manager possui em suas tabelas internas o cadastro de todas as propriedades dos objetos aceitos pela BKPML, bastando o usuário fazer um cadastro do tipo DE-PARA entre as propriedades dos objetos da BKPML e as dos SGBD. A Figura 5.1 apresenta a tela referente a essa etapa. A quarta e última etapa é a funcionalidade de cadastro de objetos por SGBD, a qual tem por objetivo vincular cada objeto cadastrado na ferramenta ao seu SGBD de destino. Isso se faz necessário, pois, após esse vínculo, deve-se executar a funcionalidade Gerar Consultas para que a consulta de metadados para o objeto selecionado seja gerada de acordo com o SGBD. A geração da estrutura de metadados na BKPML funciona da seguinte maneira: a ferramenta verifica para que tipo de objeto o backup será gerado, localiza a consulta de metadados desse objeto, executa a consulta, e os dados retornados são repassados para o método responsável por gerar a estrutura BKPML. Essas etapas são comuns a todos os objetos da BKPML. Todos os dados utilizados para geração da 71

89 5.2. PREPARANDO O AMBIENTE PARA EXECUÇÃO DO BACKUP Figura 5.1 Etapa 3 do processo de preparação do ambiente consulta de metadados são oriundos do cadastro de propriedades de objetos por SGBD. A Figura 5.2 apresenta a tela de cadastro de objetos por SGBD. Figura 5.2 Etapa 4 do processo de preparação do ambiente A consulta de metadados, quando gerada, é exibida no campo definição de dados. Já o campo chave estrangeira deverá ser preenchido manualmente, uma vez que o mapeamento de propriedades de objetos por SGBD não dá suporte a esse tipo de propriedade. A grande dificuldade encontrada para mapear essa propriedade é que o mapeamento de dados não aceita que a propriedade de um objeto possa estar em tabelas diferentes, o que é o caso da propriedade de chave estrangeira. A solução temporária implementada foi a informação manual da consulta. Dessa forma, quando a ferramenta verifica sua existência, incluirá essa propriedade na estrutura da BKPML. Outra alternativa sería a correção do cadastro de mapeamentos para que o mesmo possa aceitar o mapeamento 72

90 5.3. CADASTRANDO AS AÇÕES DE BACKUP de propriedades de um objeto existentes em outras tabelas. É importante ressaltar que essa propriedade se aplica apenas a objetos do tipo tabela. Para os demais objetos, esse campo deverá permanecer em branco. 5.3 Cadastrando as ações de backup É a partir deste cadastro que o processo de backup de dados será configurado. Até o momento, todos os cadastros realizados referem-se ao SGBD e a seus objetos. Nessa tela, apresentada pela Figura 5.3, são utilizadas as informações de todos os cadastros realizados nas seções anteriores. É nessa etapa que serão cadastradas as ações de backup para cada objeto, apresentado pelo Tabela 5.1. Na tela de cadastro de ações, o usuário deverá selecionar o SGBD com relação ao objeto a ser cadastrado, caso o objeto selecionado seja diferente ao do cadastrado, a ferramenta retornará um erro e o backup dos dados falhará. A segunda informação a ser preenchida é o local para armazenamento dos arquivos de backup. A terceira informação é o nome do objeto cadastrado, esse nome deve ser idêntico ao apresentado no Tabela 5.1, caso contrário o backup falhará. As demais informações por motivo de simplicicação não serão apresentadas. Além disso, é importante ressaltar que o campo Consulta de extração refere-se à consulta responsável por retornar os dados de um objeto tabela, e por esse motivo esta informação é obrigatória para esse tipo de objeto. Para os demais, esse campo não deverá ser preenchido. Em resumo, uma ação é um processo de backup não executado, uma vez que este cadastro possui todas as configurações necessárias para isso. A Figura 5.3 apresenta a tela de cadastro de ações para maiores detalhes. O campo frequência é responsável por controlar o número de execuções semanais dos processos de backup. Esse campo pode receber valores no intervalo de [1..7], que é o intervalo equivalente aos dias da semana. O controle de execução dos processos de backup é independente do dia da semana. Para tando, a ferramenta BKPML Manager gerencia um contador interno de execuções, que é zerado toda semana, tendo como base a data da última execução. 73

91 5.4. EXECUTANDO O BACKUP DOS DADOS Figura 5.3 Tela de cadastro de Ações 5.4 Executando o Backup dos dados Após a conclusão do cadastro de ações de backup, o próximo passo a ser tomado é a execução das ações (backup) cadastradas. Para isso, deve-se acessar o menu Funcionalidades opção Backup. Na tela de backup de dados, são encontrados todos os backups cadastrados pela funcionalidade cadastro de ações. Além disso, são apresentadas informações referentes à configuração de cada backup. Na coluna AÇÕES são encontrados dois métodos. O primeiro método representado pelo botão com a imagem de proibição, é responsável pela desativação de um backup de dados. A desativação de um backup de dados consiste em remover esse backup de lista de backups, impossibilitando assim a sua execução. Uma vez desativado, um backup de dados só poderá ser ativado novamente através da tela de cadastro de ações. O segundo método disponível, representado pelo botão com a imagem de continuidade, é responsável por dar início à execução do backup desejado. Quando executado, esse objeto será submetido ao ciclo de vida do processo de backup, apresentado no capítulo 4 Figura 4.2. No final desse processo o arquivo será armazenado no seu devido local de armazenamento. A Figura 5.4 apresenta a tela de execução de backup de dados. No final do ciclo de vida do processo de backup, os resultados obtidos podem ser vistos conforme apresentado. Vale ressaltar que os resultados apresentados pertencem aos objetos disponibilizados no Tabela 5.1. Além disso, os resultados apresentados não seguem a ordem apresentada pela Figura 5.4, uma vez que os mesmos foram agrupados 74

92 5.4. EXECUTANDO O BACKUP DOS DADOS Figura 5.4 Tela de execução de backup de dados por tipo de objeto. Os primeiros resultados apresentados referem-se aos arquivos de backup de objetos do tipo tabela. O primeiro resultado refere-se ao objeto TBL_CURSO, apresentado pela Figura 5.5. Figura 5.5 Documento BKPML TBL_CURSO O objeto TBL_CURSO é um objeto de tipo tabela, constituído de sete campos e dois registros, representados respectivamente pelas marcações <COLUMNS> e <RE- CORDS>. Essas marcações representam o conjunto de dados e metadados pertencentes 75

93 5.4. EXECUTANDO O BACKUP DOS DADOS ao objeto copiado. Na marcação <COLUMNS>, encontram-se os metadados do objeto copiado, que são representados pela marcação <COLUMN_DATA>. Já na marcação <RECORDS>, encontram-se todos os dados pertencentes a um objeto do tipo tabela. Esses dados são representados pela marcação <RECORD>. Essa marcação se repetirá a quantidade de registros existentes na tabela TBL_CURSO. A Figura 5.6 apresenta a estrutura BKPML do arquivo TBL_EMENTA. Os próximos resultados obtidos do processamento de backup de dados são referentes às tabelas TBL_EMENTA e TBL_SERVICOS representadas pelas Figuras 5.6 e 5.7 Figura 5.6 Documento BKPML TBL_EMENTA A estrutura BKPML do objeto tabela TBL_EMENTA é constituída de quatro campos. Os campos ID e ID_CURSO são as chaves primárias dessa tabela. O campo ID_CURSO funciona como chave estrangeira da tabela TBL_CURSO, como o mesmo não foi mapeado na tabela TBL_EMENTA, a estrutura BKPML contém apenas o mapeamento de chave primária nas tabelas de metadados. Quando um objeto é transposto para a estrutura da BKPML, a análise dos dados pode ser feita de forma rápida e fácil. Com essa análise é possível identificar facilmente erros 76

94 5.4. EXECUTANDO O BACKUP DOS DADOS relacionados à modelagem dos objetos e informações inválidas como caracteres especiais oriundos do SGBD de origem. Erros desse tipo muitas vezes podem comprometer o objeto quando restaurado. O próximo arquivo de backup a ser apresentado refere-se ao objeto TBL_SERVICOS representado na Figura 5.7. Figura 5.7 Documento BKPML TBL_SERVICOS A estrutura BKPML do objeto tabela TBL_SERVICOS é composta por três campos ID, NOME e DESCRICAO, mantidos pela marcação <Columns> que representa os metadados de um objeto do tipo tabela. Como se pode observar, essa tabela não possui um campo chave primária. Com o uso da BKPML, basta apenas realizar a edição do arquivo BKPML e adicionar de forma manual o atributo primary_key no campo desejado. Outro fator que influencia de forma positiva na representatividade dos dados na BKPML, é que a mesma se beneficia do poder de XML representar essas informações. Além disso, o uso da tecnologia JSON para representar os dados de objetos do tipo tabela também ajuda na detecção visual de erros. Por se tratar de erros na entrada dos dados, esse tipo de problema pode comprometer o processamento dos dados como os processos de restauração ou migração, uma vez que um SGBD de destino pode interpretar essas entradas como um erro grave, impedindo a restauração dos mesmos em seu ambiente. Com a estrutura BKPML, esse tipo de erro é facilmente identificado e corrigido, sem comprometer a integridade dos dados. A Figura 5.8 apresenta a arquivo de backup de um objeto do tipo índice. A estrutura BKPML para um objeto do tipo índice é composta de três importantes informações que possibilitam a restauração do mesmo em qualquer SGBD: <in- 77

95 5.4. EXECUTANDO O BACKUP DOS DADOS Figura 5.8 Documento BKPML IDX_BY_DATA_COURSE dex_name>, que representa ao nome do índice, o campo <index_table>, que representa o nome da tabela indexada, e o campo <index_field>, que é o campo indexado, além dos atributos type e kind, mantidos pela marcação <IndexObject>. A partir dessas informações é possível gerar a sintaxe SQL padrão para esse tipo de objeto, aceita por qualquer SGBD. Quaisquer outros detalhes para esse tipo de objeto, particular do SGBD de destino, deverá ser feita de forma manual. Caso contrário, o mesmo poderá ser migrado sem qualquer problema. Os próximos documentos apresentados referem-se a estruturas do tipo método, apresentado pela Figura 5.9. Figura 5.9 Documento FNC_INSERIR_CURSO A estrutura BKPML de um objeto do tipo method é composta pelas principais informações necessárias para geração de sua sintaxe padrão, definida pela própria ferramenta, tendo em vista que esse tipo de objeto não possui uma estrutura padrão comum a todos os SGBD. A estrutura deste tipo de objeto muda de SGBD para SGBD. Para resolver 78

96 5.4. EXECUTANDO O BACKUP DOS DADOS esse tipo de problema, foram definidas as principais informações que compõem os objetos do tipo função e procedimento, e essas foram acopladas em uma só estrutura, uma vez que esses objetos possuem poucas características que os distinguem. Uma estrutura BKPML do tipo métodos é composta pelas seguintes informações: <name>, parameter>, <result> e <body>. Qualquer dúvida a respeito dessas informações, o Capítulo 3 deste trabalho deverá ser consultado. Os próximos documentos a serem apresentados referem-se a objetos do tipo função, apresentados pelas Figuras 5.10 e 5.11 Figura 5.10 Documento FNC_DELETAR_CURSO Figura 5.11 Documento FNC_ALTERAR_SERVICOS Esses métodos são responsáveis por deletar e alterar os dados da tabela TBL_CURSO 79

97 5.4. EXECUTANDO O BACKUP DOS DADOS e da tabela TBL_SERVICOS, conforme pode-se observar pela marcação <body> de ambos os arquivos. O próximo arquivo a ser apresentado é o PRC_LISTAR_EMENTA, que é um objeto do tipo método que representa a estrutura de uma procedure, conforme apresentado pela Figura Figura 5.12 Documento PRC_LISTAR_EMENTA O atributo type da marcação <MethodObject> informa à ferramenta qual o tipo da estrutura que está sendo representada pela BKPML: procedure ou function. Além disso, pode-se observar essa diferença pela falta da marcação <return> uma vez que um procedimento não possui um valor de retorno. Os últimos resultados a serem apresentados são referentes a objetos do tipo Visão e Gatilho. Representados pelas Figuras 5.13 e Figura 5.13 Documento BKPML VEW_CURSO_EMENTA 80

98 5.5. PREPARANDO O AMBIENTE DE RESTAURAÇÃO E MIGRAÇÃO Figura 5.14 Documento BKPML TRG_EXCLUIR_EMENTA Assim como o objeto do tipo índice, a estrutura do objeto tipo visão é composta pelas informações básicas necessárias para geração de sua sintaxe SQL padrão aceita por todos os SGBD relacionais. Sua estrutura possui apenas dois elementos <name> e <query>. Já a estrutura do objeto de tipo gatilho, assim como a estrutura do objeto de tipo método, é composta pelas informações comuns desse objeto para qualquer SGBD. A partir dessas informações a ferramenta transpõe esses dados para uma sintaxe comum, que receberá as adaptações necessárias de acordo com o SGBD de destino. Essas informações são: <name>, <time>, <event>, <object> e <body>. Todos os objetos aqui apresentados são compostos apenas por suas características comuns para todos os SGBD. Características particulares de SGBD para SGBD, conforme mencionado, devem ser adicionadas manualmente. A seção a seguir destina-se a apresentar as etapas e resultados obtidos nos testes de restauração e migração de dados. 5.5 Preparando o ambiente de restauração e migração Para dar início aos processos de restauração e migração de dados, é necessária a realização das configurações básicas para execução desses processos. Essas configurações são divididas em duas etapas: o cadastro de tipos por SGBD e o cadastro de sintaxe por SGBD. Esses cadastros são de grande importância para esses processos pois, antes da restauração dos dados, todos os tipos devem ser validados. O processo de migração de 81

99 5.5. PREPARANDO O AMBIENTE DE RESTAURAÇÃO E MIGRAÇÃO dados complexos utiliza essas informações para auxiliar o processo de substituição de tipos e sintaxes de um objeto complexo. A primeira etapa a ser realizada é o cadastro de tipos por SGBD. Essa etapa consiste em vincular os tipos básicos mantidos pela ferramenta BKPML Manager aos tipos equivalentes dos SGBD receptores. A não realização dessa etapa impossibilitará o processo de transferência dos dados. Uma transferência consiste em passar as informações de um arquivo BKPML para um SGBD. O processo de transformação dos dados, ou seja, a conversão de um arquivo BKPML para um arquivo em formato CSV, EXCEL, YAML, XML ou JSON, não é afetado, uma vez que para isso não se faz necessária validação de tipos. A segunda etapa é o cadastro de sintaxes por SGBD. Esse cadastro possui os mesmos objetivos da primeira etapa: vincular as sintaxes básicas mantidas pela BKPML Manager às sintaxes equivalentes dos SGBD receptores. Ao contrário da primeira etapa, a não realização dessa não impossibilita a realização de nenhum dos processos supracitados, uma vez que esse cadastro é utilizado apenas para auxiliar a funcionalidade de migração dos dados Restaurando e transformando os arquivos BKPML O processo de restauração de dados está disponível para acesso através do menu principal, opção funcionalidades. Na tela de restauração de dados complexos são encontradas todas as informações necessárias sobre arquivos BKPML pertencentes a objetos de tipo tabela, uma vez que essa funcionalidade só trabalha com esse tipo de objeto. Essa tela é composta por dois processos: o processo de transferência e o de transformação. Para isso, o usuário deverá informar na própria tela o tipo de ação desejada: transferência ou transformação. A ferramenta não exibe explicitamente a palavra transformação, mas sim os tipos de transformação permitidos pela ferramenta CSV, JSON, YAML, XML e EXCEL. Para execução do processo de transferência dos dados, o usuário deverá selecionar o SGBD de destino e a opção transferência. Após isso, o botão localizado na coluna ação deverá ser clicado com o mouse para dar início à transferência dos dados no arquivo BKPML para o SGBD selecionado. No processo de transformação dos dados, não se deve informar um SGBD, somente o tipo de transformação desejada. Após isso, o botão de execução deverá ser pressionado com o mouse para dar início ao processo. A Figura 5.15 apresenta a tela para restauração de transformação de dados. Assim como a tela de execução dos backups de dados, a tela de restauração segue 82

100 5.5. PREPARANDO O AMBIENTE DE RESTAURAÇÃO E MIGRAÇÃO Figura 5.15 Tela de Restauração de dados o mesmo padrão, com a diferença nos dados de entrada. O primeiro destina-se a informar o SGBD para destino. Quando clicado com o mouse, esse objeto apresenta todos os SGBD cadastrados na ferramenta. O segundo destina-se às funcionalidades de transferência e transformação. É importante ressaltar que a palavra transformação não é exibida nesse componente, subentende-se que transformação é qualquer opção diferente à transferência. Esse componente quando clicado com o mouse, exibirá todos os tipos de transformação permitidos pela ferramenta. Após a execução e finalização dos processos de restauração e transformação dos dados, alguns resultados serão apresentados a seguir. O primeiro resultado a ser visto refere-se à restauração dos dados dos objetos tabela TBL_CURSO, TBL_EMENTA e TBL_SERVICOS no SGBD Postgres8.4, conforme apresentado pela Figura Figura 5.16 Restauração dos dados no postgres Esses resultados foram obtidos a partir da seleção do SGBD POSTGRES8.4 e da seleção do formato tipo transferência. A seleção desse formato informa à aplicação que 83

101 5.5. PREPARANDO O AMBIENTE DE RESTAURAÇÃO E MIGRAÇÃO a restauração dos dados será realizada diretamente para o SGBD selecionado. Qualquer outra opção indica que os dados serão transferidos para arquivos secundários. As figuras 5.17 a 5.20 apresentam os resultados obtidos com as funcionalidades de transformação dos dados. Vale ressaltar que os resultados apresentados seguem a mesma ordem disposta no menu de opções dessa tela. O formato XML não será apresentado, uma vez que para esse formato a ferramenta retornará o arquivo BKPML, já apresentado anteriormente. O primeiro resultado é a transformação do arquivo de backup da tabela TBL_EMENTA para o formato CSV. Este formato foi escolhido pois a maioria dos SGBD comerciais utiliza esse formato para transferência e restauração de grandes volumes de dados. A Figura 5.17 apresenta os resultados obtidos dessa transformação. Figura 5.17 Objeto TBL_EMENTA em formato CSV No formato EXCEL os dados são transpostos para uma planilha de forma simples, qualquer formatação fica a cargo do usuário. Esse formato foi escolhido para facilitar, quando necessário, a geração de relatórios para dados específicos e que necessitem ser visualizados em formato popular para empresas e organizações. A Figura 5.18 apresenta a transformação dos dados da tabela TBL_CURSO para o formato EXCEL. Figura 5.18 Objeto TBL_CURSO em formato Excel A próxima transformação a ser apresentada é referente ao formato JSON. Esse for- 84

102 5.5. PREPARANDO O AMBIENTE DE RESTAURAÇÃO E MIGRAÇÃO mato inicialmente foi desenvolvido com objetivo de fazer intercâmbio de objetos JavaScript através da Internet, e hoje em dia é utilizado tanto para intercâmbio quanto para representação de informações na Internet. A ferramenta utiliza esse formato por ser um facilitador para transferência de dados entre diferentes plataformas e representar os dados de forma clara. Quando os dados são transformados para esse formato, os mesmos são armazenados em um vetor JSON, o que facilita a restauração dos mesmos utilizando a função eval() no javascript ou utilizando um framework JSON para realização dessa tarefa. A Figura 5.19 apresenta a transformação dos dados da tabela TBL_EMENTA para o formato JSON. Figura 5.19 Objeto TBL_EMENTA em formato JSON O formato YAML foi escolhido como formato para transformação pois, além de ser um formato novo e em expansão no mercado, esse formato propõe a disponibilização dos dados de forma mais legível a humanos, o que facilitaria a análise visual dos dados quando necessário. O último resultado dessa fase de testes é apresentado a seguir pela Figura Figura 5.20 Objeto TBL_SERVICOS em formato YAML A BKPML Manager implementou as funcionalidades de migração de dados para permitir que as informações mantidas nos arquivos BKPML pudessem ser compartilhadas com outras aplicações, sem o intermédio da ferramenta BKPML Manager. Além 85

103 5.5. PREPARANDO O AMBIENTE DE RESTAURAÇÃO E MIGRAÇÃO disso, formatos como XML e JSON, foram utilizados para facilitar o intercâmbio das informações para outros sistemas através da Web. Por fim, pode-se concluir que os testes apresentados alcançaram os objetivos esperados. Todos os arquivos de backup foram restaurados e transformados corretamente. A seção a seguir destina-se a apresentar os testes e resultados obtidos com a funcionalidade de migração de dados complexos Migrando os arquivos BKPML de objetos complexos A funcionalidade de migração de dados complexos é utilizada quando o objeto a ser migrado refere-se a um objeto complexo. Um objeto complexo é aquele que necessita de análise visual e alteração manual em sua estrutura para que a restauração possa ser efetivada. A ferramenta considera como objeto complexo os objetos: visão, índice, permissão, gatilho e método. O único tipo de objeto que não é considerado complexo é o objeto tabela, testado na seção anterior. Os objetos visão, índice e permissão, apesar de possuírem uma estrutura simples, são classificados como objetos complexos pois, na sua migração de um SGBD para outro, o usuário poderá realizar as alterações necessárias antes de sua restauração. Caso contrário, os mesmos poderão ser carregados e submetidos sem intervenção do usuário, uma vez que a ferramenta carrega cada objeto em sua estrutura padrão SQL, com exceção dos objetos dos tipos método e gatilho. O processo de migração de dados funciona da seguinte maneira. Para início desse processo, o usuário deverá selecionar o arquivo BKPML desejado e pressionar o botão carregar objetos. Após isso, o método carregarobjeto envia uma mensagem com o nome do arquivo para o método SalvarRestaurarArquivos, que por sua vez resgata o arquivo solicitado e devolve para o método que o solicitou. Caso o arquivo não seja encontrado, uma mensagem de erro "arquivo não encontrado" será retornada e o processo será cancelado. Ao receber o arquivo solicitado, o método carregarobjeto executa quatro processos de forma recursiva utilizando o padrão decorator: validarhash, Descompactar, Descriptografar e RestaurarBKPML. O método validarhash é responsável por validar o hash do arquivo solicitado com o do arquivo quando gerado. Para isso, o primeiro hash é solicitado do sistema de banco de dados, em seguida o código hash do arquivo enviado é extraído e comparado com o do banco. Caso os códigos não sejam compatíveis, uma mensagem de erro "Arquivo Corrompido" será retornada e o processo será cancelado. Caso contrário, esse método é finalizado e enviado para o próximo método da pilha de recursão, o método Descompactar. 86

104 5.5. PREPARANDO O AMBIENTE DE RESTAURAÇÃO E MIGRAÇÃO O método Descompactar, após receber o arquivo enviado, aplica o algoritmo responsável por descompactar o arquivo e resgatar o arquivo criptografado. Esse método retornará a mensagem "erro ao descompactar, arquivo pode estar corrompido", caso o arquivo não consiga ser descompactado. Caso contrário, o arquivo descompactado é enviado para o próximo método da pilha, o método Descriptografar. Esse método ao receber o arquivo criptografado se responsabiliza em aplicar o algoritmo necessário para descriptografia do arquivo, tornando as informações legíveis para que o próximo método possa validar os dados. Assim como os métodos supracitados, esse método retorna um erro caso não consiga descriptografar o arquivo recebido. O último método a ser executado é o restaurarbkpml. Esse método recebe o arquivo descriptografado, ou seja o arquivo BKPML, e apenas realiza a validação do mesmo para verificar se a estrutura do arquivo está de acordo com a taxonomia definida para BKPML. Se a validação for realizada com sucesso, o arquivo BKPML é repassado para o método solicitador, neste caso o método carregarobjeto, para dar continuidade ao processamento dos dados. Caso contrário, um erro será retornado e o processo será cancelado. Após a recepção do arquivo BKPML o método carregarobjeto repassa o arquivo BKPML para o método gerarsintaxepadrao e esse por sua vez verifica o tipo de objeto pertencente ao arquivo e aplica a sintaxe padrão definida pela ferramenta. Após a transformação, esse método envia a sintaxe para a tela de migração para que os mesmos possam ser modificados de acordo com o SGBD selecionado. Para melhor visualização das funcionalidades do processo de migração de dados, a Figura 5.21 apresenta a tela de migração dos dados. Figura 5.21 Tela de Migração de dados 87

105 5.5. PREPARANDO O AMBIENTE DE RESTAURAÇÃO E MIGRAÇÃO A tela de migração de dados funciona como um editor para adaptação da estrutura dos objetos complexos. Essa tela é composta pelas funcionalidades carregar objeto que, conforme apresentada, é responsável pela transformação dos objetos mantidos no arquivo BKPML para sua sintaxe padrão SQL, com exceção dos objetos do tipo método e gatilho. Para esses objetos, seus metadados são transferidos para uma sintaxe não SQL definida pela própria ferramenta. Para melhor entendimento da sintaxe utilizada pela ferramenta para esses objetos, as Figuras 5.22 e 5.23 apresentam essas sintaxes. Figura 5.22 Sintaxe padrão para objetos tipo função Nesse caso, a estrutura modificada pertence a um objeto do tipo função. A sintaxe de um objeto tipo procedimento segue a mesma ideia, bastando para isso substituir o nome FUNCTION por PROCEDURE e remover o retorno dos dados. O restante é idêntico a ambos os objetos. A Figura 5.23 apresenta a sintaxe para um objeto do tipo gatilho. Figura 5.23 Sintaxe padrão para objetos tipo gatilho Após a sintaxe de um objeto ser carregada para tela de edição, o usuário deverá adaptar a mesma para a sintaxe correspondente do SGBD selecionado. Após isso, o botão Submeter Comando deverá ser pressionado para que o objeto possa ser transferido. A transferência dos objetos complexos ficam sob responsabilidade do método submeter- Comando, que envia os dados para que o sistema de banco de dados possa validar e gerar o mesmo em seu ambiente. Toda validação de sintaxe, tipos e estrutura ficam sob responsabilidade do SGBD, que retornará um erro caso a sintaxe não esteja de acordo com seus padrões. A alteração da sintaxe dos objetos pode ser realizada de duas formas: manual, ou utilizando os métodos Buscar sintaxe Equivalente e Alterar, disponíveis na parte inferior 88

106 5.5. PREPARANDO O AMBIENTE DE RESTAURAÇÃO E MIGRAÇÃO da área de edição. A alteração manual consiste em substituir todas as sintaxes e tipos sem o auxílio da ferramenta. Para utilização dos métodos supracitados, o usuário deverá selecionar o tipo ou sintaxe desejada e clicar com o mouse no botão Buscar Sintaxe Equivalente. Essa funcionalidade, por sua vez, solicita das tabelas internas da ferramenta a sintaxe ou tipo equivalente e o envia para a caixa de texto localizada ao lado do botão pressionado. Em seguida, o usuário deverá confirmar o resultado obtido e pressionar o botão alterar para realizar a substituição. Vale ressaltar que o botão alterar executa um método JavaScript para realização dessa tarefa. Após a alteração da estrutura, sintaxe e tipos, o botão Submeter Comando deverá ser pressionado. Abaixo, a Figura 5.24 apresenta o resultado da migração do objeto FNC_DELETAR_CURSO para o SGBD ORACLE EXPRESS 10G. Figura 5.24 Resultado da Migração para o ORACLE Express O teste realizado na funcionalidade de migração de dados consistiu em migrar todos os objetos considerados complexos pela ferramenta para um SGBD de destino, neste caso foi utilizado o ORACLE EXPRESS. Todos os objetos testados foram migrados corretamente para esse SGBD, conforme pode ser observado na Figura O tempo médio levado para migração desses objetos foi de 1 segundo, que é um tempo aceitável para restauração desse tipo de objeto. Já os objetos de tipo tabela tendem a demorar mais, dependendo da quantidade de dados que esse objeto possua. A seção a seguir destina-se a testar o tempo levado para restauração de diferentes quantidades de dados de arquivos BKPML de objetos de tipo tabela. 89