PUZZLE DATABASE, PROPOSTA DE UM MIDDLEWARE PARA A DISTRIBUIÇÃO DE BANCO DE DADOS

Tamanho: px
Começar a partir da página:

Download "PUZZLE DATABASE, PROPOSTA DE UM MIDDLEWARE PARA A DISTRIBUIÇÃO DE BANCO DE DADOS"

Transcrição

1 UNIVERSIDADE DO ESTADO DE SANTA CATARINA BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO Danilo Gonçalves da Cruz PUZZLE DATABASE, PROPOSTA DE UM MIDDLEWARE PARA A DISTRIBUIÇÃO DE BANCO DE DADOS Maurício Aronne Pillon Orientador Éverlin Fighera Costa Marques Co-orientadora Joinville Junho, 2008

2 II UNIVERSIDADE DO ESTADO DE SANTA CATARINA BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO Danilo Gonçalves da Cruz PUZZLE DATABASE, PROPOSTA DE UM MIDDLEWARE PARA A DISTRIBUIÇÃO DE BANCO DE DADOS Trabalho de conclusão de curso submetido à Universidade do Estado de Santa Catarina como parte dos requisitos para a obtenção do grau de Bacharel em Ciência da Computação. Maurício Aronne Pillon Orientador Éverlin Fighera Costa Marques Co-orientadora Joinville Junho, 2008

3 III Puzzle Database, Proposta de um Middleware para a distribuição de banco de dados Danilo Gonçalves da Cruz Este Trabalho de Conclusão de Curso foi julgado adequado para a obtenção do título de Bacharel em Ciência da Computação e aprovado em sua forma final pelo Curso de Ciência da Computação Integral do CCT/UDESC. Banca Examinadora Maurício Aronne Pillon, Dr (orientador) Omir Correa Alves Jr, M.Sc Éverlin Fighera Costa Marques, M.Sc Débora Cabral Nazário, M.Sc.

4 IV A minha família, Por acreditarem em meus sonhos e apoiarem-me durante toda essa trajetória.

5 V AGRADECIMENTOS Primeiramente a Deus, ser sublime e infinitamente bom no qual muitas vezes silenciosamente busquei força, persistência e dedicação nos momentos difíceis de toda essa Jornada. À minha mãe (Maria José), mulher de luta, de desafios, espelho para minha dedicação e caráter, exemplo de amor. Ao meu pai (Jonas) que esteve presente nessa jornada. A Maria Rodrigues, por sempre compartilhar desse sonho comigo, fazendo-me acreditar que o mesmo era possível. Ao meu irmão Rodrigo, por demonstrar inúmeras vezes generosidade e companheirismo indescritíveis. A Rejane e Ana Letícia, irmãs que sempre acreditaram no meu sucesso. Em memória de Ana Rodrigues Ferreira, gostaria muito que você estivesse aqui para presenciar esse momento. Ao professor doutor Maurício Aronne Pillon, orientador que sempre auxiliou todo esse projeto e fez com que o mesmo não fosse apenas um sonho, exemplo de competência e profissionalismo, professores como você fazem com que os acadêmicos despertem para a docência. A professora Éverlin, co-orientadora desse projeto. Ao professor Salvador Santos, por acreditar nos jovens proporcionando prazerosos diálogos extraclasse. Aos amigos Fábio Haertel, Fernando Rebelo, Cristian Rossi, que nosso companheirismo esteja sempre além das fronteiras da universidade. A todos os demais colegas. Por todos que acreditaram em mim, nunca desisti por maior que fosse a adversidade, entretanto esse é apenas mais um passo de uma longa jornada, fica aqui a certeza de que a busca pelo conhecimento é insaciável. Muito Obrigado!!!!

6 VI SUMÁRIO LISTA DE TABELAS... XII LISTA DE ILUSTRAÇÕES... XIII LISTA DE GRÁFICOS... XV LISTA DE ABREVIATURAS E SIGLAS... XVI 1 INTRODUÇÃO Objetivos Objetivo Geral Objetivos Específicos Estrutura do Trabalho de Conclusão de Curso BANCO DE DADOS DISTRIBUÍDOS Definições gerais banco de dados distribuídos Replicação em banco de dados distribuídos Transparência de Replicação Inconsistência das bases durante a replicação Fragmentação em Banco de dados distribuídos Fragmentação Vertical Fragmentação Horizontal Fragmentação Horizontal Primária Fragmentação Horizontal Derivada Fragmentação Mista Transparência de Fragmentação Projeto de banco de dados distribuídos Consultas em banco de dados distribuídos Otimização de Consultas em bancos de dados distribuídos... 37

7 VII 2.7 Considerações do capítulo SISTEMAS DISTRIBUÍDOS Definição de sistema distribuído Objetos distribuídos Controle de concorrência Replicação em ambientes distribuídos Algoritmo Berkeley Tecnologias para construção de sistemas distribuídos Distributed Component Object Model Web Services Common Object Request Broker Architecture JAVA RMI Considerações do capítulo PUZZLE DATABASE Contexto do trabalho Arquitetura do Puzzle Database Implementação do Puzzle Database Estudo de caso Plataforma JAVA Considerações do capítulo O PROTÓTIPO PUZZLE DATABASE Puzzle XML Puzzle Compiler Puzzle Distributed Puzzle SQL... 69

8 VIII 5.5 Integração dos núcleos no Puzzle Database Análise de Desempenho do Puzzle Database Metodologia da análise de desempenho Estrutura Física da análise de desempenho SGBD s da análise de desempenho Métrica de análise de desempenho CONSIDERAÇÕES FINAIS Trabalhos futuros ANEXOS REFERÊNCIAS... 94

9 IX... A Vida não é um jogo onde só quem testa seus limites é que leva o prêmio. Não sejamos vítimas ingênuas desta tal competitividade. Se a meta está alta demais, reduza-a. Se você não está de acordo com as regras, demita-se. Invente seu próprio jogo. Faça o que for necessário para ser feliz. Mas não se esqueça que a felicidade é um sentimento simples, você pode encontrá-la e deixá-la ir embora por não perceber sua simplicidade... (Autor Desconhecido)

10 X RESUMO Através da computação distribuída e suas técnicas é possível, no contexto atual, obter inúmeros benefícios para a resolução de problemas nas esferas tecnológico-científicas. A divisão de tarefas em módulos objetiva reduzir a complexidade do problema a ser tratado e, assim, permite a sua distribuição entre vários computadores e/ou processos facilitando a sua resolução. No cenário atual, as organizações e corporações apresentam-se distribuídas, entretanto, os departamentos e/ou setores não possuem suas próprias bases de dados com informações referentes à sua atuação. A centralização dessas informações não permite, assim, utilizar um meio lógico de acesso aos dados para manipular a base de dados como sendo uma única base distribuída. Nesse contexto, o presente trabalho, apresenta uma proposta de Middleware para a distribuição de banco de dados. O objetivo é distribuir bancos de dados seqüenciais gerenciando as operações referentes à DQL (Data Query Language) e DDL (Data Definition Language), e assim, mascarar as heterogeneidades entre os diversos Sistemas Gerenciadores de Banco de Dados, caso essas existam. Palavras-chave: Banco de dados, Middleware para distribuição de dados, Sistema de Banco de dados Distribuídos.

11 XI ABSTRACT Through distributed computing and its techniques is possible, in the current context, to obtain numerous benefits for the resolution of problems in the scientific-technological spheres. The division of labor in modules aims to reduce the complexity of the problem to be treated and, thus, allow its distribution among multiple computers and / or processes to facilitate their resolution. In the current scenario the organizations and corporations have been distributed, however, the departments and / or sectors do not have their own databases with information relating to its activities. The centralization of this informations does not permit, therefore, the use a logical way to access the data and manipulate the database as a single distributed database. In this context, the present work, presents a proposal for a Middleware for databases distribution. The goal is to distribute sequential-databases by managing operations related to DQL (Data Query Language) and DDL (Data Definition Language), and thus, mask the differences between the various Database Managing Systems, if such exist. Keywords: Database, middleware to distribution of data, distributed database system.

12 XII LISTA DE TABELAS Tabela 1 - Comparativo entre Mysql e Postgre Tabela 2 - Fragmento da tabela empregados (Recursos Humanos) Tabela 3 - Fragmento da tabela empregados (Financeiro) Tabela 4 - Relação empregados Tabela 5 - Relação departamentos Tabela 6 - Centros acadêmicos da UDESC... 61

13 XIII LISTA DE ILUSTRAÇÕES Figura 1 - Ambiente de banco de dados Figura 2 - Ambiente de um banco de dados distribuído Figura 3 - Um Exemplo de replicação de dados Figura 4 - Fragmentação horizontal primária da tabela empregados Figura 5 - Fragmentação horizontal derivada da tabela empregados Figura 6 - Fragmentação Mista Figura 7- Fragmentação Mista da Relação ClientesConta Figura 8 - Conversão de esquemas Figura 9 - Árvore de relações algébricas Figura 10 - Modelo cliente-servidor Figura 11 - Invocação de objetos distribuídos Figura 12- Objetos distribuídos em BDD fragmentado Figura 13 - Consulta/Atualização réplica Figura 14 - Camada de serviços em sistemas distribuídos Figura 15 - Componentes middleware CORBA Figura 16 - Funcionamento JAVA RMI Figura 17 - Indisponibilidade do sistema Figura 18 Arquitetura de camadas, puzzle database Figura 19 interoperabilidade de SQL Figura 20 puzzle distributed/puzzle SQL Figura 21 - Relações banco de dados distribuído Figura 22 - Protocolo JRMP Figura 23 - Middleware para a distribuição de banco de dados Figura 24 - Centralização de dados sistema acadêmico UDESC Figura 25 - Banco de dados distribuído Figura 26 - Compilação/Execução JAVA Figura 27 - Estrutura puzzle XML Figura 28 - Interface puzzle XML Figura 29 - Estrutura puzzle properties Figura 30 - Referência Local Figura 31- Referência Remota Figura 32 - Integração Núcleos Puzzle Database... 70

14 XIV Figura 33- Tamanho da Amostra Figura 34 - Valores Críticos Associados ao Tamanho de Amostra Figura 35 - Cálculo da Amplitude Figura 36 - Amostra Final Figura 37 - Média de Acessos puzzle Database Figura 38 - Ambiente de Testes Figura 39 - Variância acesso postgresql Figura 40 - Variância acesso MySQL Figura 41 - Relações Distribuídas Figura 42 - Variância acesso seqüencial x puzzle Database Figura 43 - Tela de Execução puzzle Database... 85

15 XV LISTA DE GRÁFICOS Gráfico 1 - Acesso Seqüencial PostgreSQL Gráfico 2 - Acesso Seqüencial MySQL Gráfico 3 - Puzzle Database - PostgreSQL Seqüencial Gráfico 4 - Puzzle Database MySQL Seqüencial Gráfico 5 - Puzzle Database Gráfico 6 - Gráfico Desempenho Puzzle Database... 80

16 XVI LISTA DE ABREVIATURAS E SIGLAS API BDD CORBA ECG GPL HTML HTTP IDL IP JVM ORB OMG PDA RMI RPC SD SGBDD SOAP SQL TCP URL UML XML Application Program Interface Banco de Dados Distribuídos Common Object Request Broker Architecture Esquema Conceitual Global Licença Pública Geral Hypertext Markup Language HyperText Transfer Protocol Interface Description Language Protocolo de Internet Java virtual machine Object Request Broker Object Management Group Assistente Pessoal Digital Invocação remota de métodos Chamada remota de procedimentos e/ou funções Sistemas Distribuídos Sistemas de Gerência de Bancos de Dados Distribuídos Simple Object Access Protocol Linguagem Estruturada de Consultas Transmission Control Protocol Universal Resource Locator Unified Modeling Language extensible Markup Language

17 17 1 INTRODUÇÃO A utilização de banco de dados e suas tecnologias de armazenagem proporcionam grande crescimento no uso de computadores e contribuem para constantes avanços tecnológicos (Elmasri & Navathe, 2005). Os bancos de dados possuem papel importante em todas as áreas do conhecimento, pois registra informações que possuem significado implícito e que são fundamentais para a estruturação de negócios nos mais variados ramos de atividades (empresarias estudantis, cooperativista dentre outras). Armazenar dados, nesse contexto, pode ser definido como uma tarefa que exige constantes estudos técnico-cientifícos, pois manipula informações que são vitais para as corporações. As informações podem ser consideradas os principais bens que compõem uma organização. As pequenas e médias corporações muitas vezes não possuem uma política de distribuição de dados segura, dessa maneira, as informações são geralmente centralizadas, e assim, a segurança física dos dados juntamente com sua disponibilidade de acesso apresentase comprometida. No cenário atual as organizações e/ corporações apresentam-se distribuídas, entretanto, não é comum que cada departamento e/ou setor possuam suas próprias bases de dados com informações referentes à sua atuação. A fragmentação, nesse contexto, contribui enfaticamente para que cada nó de dados possua informações referentes à sua atuação. A implementação de um banco de dados distribuído, assim, apresenta-se como um processo importante, pois, permite acesso lógico às informações que estão descentralizadas. A utilização de bancos de dados distribuídos (BDD) segundo (Özsu & Valduriez, 2001) pode ser visto como um novo paradigma de processamento de dados onde as informações apresentam-se descentralizadas, assim, essa reorganização dos dados é configurada de maneira independente. Segundo (Date, 2004), os arquivos de um BDD podem estar replicados ou fragmentados. Quando replicadas, as informações são inseridas em outra base criando um novo nó na rede com informações idênticas. A fragmentação caracteriza-se pela não replicação dos dados, onde cada nó integrante da rede de dados armazena informações diferentes. Os administradores e usuários de BDD, nessa dinâmica, tendem a abstrair a divisão dos dados, visto que o conteúdo final de todas as informações estarão disponíveis em nós de dados adjacentes. O projeto e implementação de banco de dados distribuídos tende a ser uma tarefa complexa, pois apresentam fatores de complicação decorrentes de sistemas distribuídos. Fatores como a concorrência estão diretamente interligados com a sincronização de acessos

18 18 ao banco de dados distribuído e o seu controle deve ser feito de maneira a preservar a integridade dos dados e das várias bases de dados que podem estar replicadas e/ou fragmentadas. As transações configuram um ponto de estudo em banco de dados distribuídos, (Vargas, J.Bacon, & K.Moody, 2006 ) definem transação como sendo uma unidade de execução confiável que engloba atomicamente um número de operações e garante que todas ou nenhuma operação sejam executadas. Segundo (O'Neil & O'Neil, 2001) as transações podem ser subdivididas em transações de escritas, ou seja, aquelas responsáveis por inserir informações nas bases de dados e transações de leitura responsáveis por recuperar informações. As transações de escrita configuram um problema de sincronização em banco de dados distribuídos e, assim, as informações devem ser isoladas durante o seu acesso. A sincronização é um instrumento que busca assegurar a qualidade específica entre o aplicativo e os serviços do BDD (Aygun & Patil, 2006). Reafirmando a necessidade de mecanismos de consultas (também abordado na literatura como transações do tipo somente leitura) eficientes em BDD, (Loureiro, 2001) define consultas como funcionalidades básicas e essenciais de um BDD e essas consistem em oferecer uma linguagem estruturada de consultas (SQL) para recuperação dos dados armazenados em disco. Através das consultas é possível definir quais dados serão retornados, sem especificar detalhes sobre como esses dados serão recuperados. A localização física dessas informações deve apresentar-se indiferente para os aplicativos e usuários. Os usuários, assim, não necessitam ter conhecimento sobre as estruturas internas do banco de dados. Segundo a literatura, com o uso de técnicas e modelos da área de sistemas distribuídos, os bancos de dados distribuídos são estruturados de forma a permitir que os dados sejam recuperados independentemente da sua localização física, e da heterogeneidade existente entre as diversas bases relacionais que integram os BDD. As técnicas existentes para criar, gerenciar e administrar sistemas distribuídos são de extrema importância para a configuração, funcionamento e gerenciamento de banco de dados distribuídos. O presente trabalho apresenta uma proposta de Middleware, que terá como objetivo principal distribuir banco de dados. O Middleware irá automatizar a distribuição de banco de dados proporcionando acesso transparente às bases de dados que serão distribuídas.

19 Objetivos Objetivo Geral Definir uma proposta de Middleware para a distribuição de banco de dados que será estruturado sobre uma rede de computadores. A proposta consiste em inter-relacionar várias bases de dados (homogêneas ou heterogêneas) através de uma camada de software posicionada sobre o nó da rede que possui a base de dados. O inter-relacionamento lógico dos dados, nesse contexto, será realizado através da invocação remota de métodos. Os objetos remotos, assim, irão interagir entre si e com a base de dados local unificando as várias bases, em uma única base de dados distribuída. A aplicação, nesse contexto, irá comunicar-se diretamente com o middleware, e esse fará a comunicação lógica com a base de dados requisitada. Os desafios da proposta são disponibilidade, heterogeneidade de SQL e transparência 1 de acesso às bases de dados Objetivos Específicos Estudar e compreender o processo de distribuição de banco de dados, projeto, administração e modelagem. Buscar na literatura possíveis métodos e algoritmos disponíveis para acesso a banco de dados distribuídos e, por fim, selecionar uma arquitetura para construção de aplicações distribuídas que será utilizada para implementar um protótipo de middleware que vise mascarar a heterogeneidade de plataformas, software e hardware. 1.2 Estrutura do Trabalho de Conclusão de Curso O presente trabalho está estruturado em duas partes, a primeira apresenta e discorre sobre o estudo feito para entendimento de banco de dados distribuídos, o capítulo 2 irá abordar questões referentes a banco de dados distribuídos. A segunda etapa será composta pelo estudo de sistemas distribuídos, e como esses interagem quando relacionados a banco de dados distribuídos, essa etapa é elucidada no capítulo 03 e terá como abordagem central questões pertinentes a sistemas distribuídos. Por fim os conhecimentos obtidos na primeira e segunda etapas serão utilizados para elaborar e definir a proposta de middleware que terá como objetivo fundamental distribuir banco de dados. Ao final do projeto (término do TCC- II) serão apresentados em forma de anexos as classes e diagramas utilizados para a modelagem do protótipo. 1 Que deixa passar a luz e ver nitidamente o que está por trás; límpido, cristalino (Houaiss,2004). Transparência, nesse contexto, é realizar o acesso aos dados sem distinção entre bases de dados remotas e bases locais. A aplicação e/ou usuário, portanto, não necessitam conhecer o endereço físico da base de dados.

20 20 2 BANCO DE DADOS DISTRIBUÍDOS O presente capítulo tem por finalidade elucidar os principais conceitos referentes a banco de dados distribuídos, entretanto, faz-se necessário revisitar aspectos relevantes de um ambiente de banco de dados. Ao término do referencial teórico de banco de dados é apresentada a principal motivação para a construção de um ambiente de banco de dados distribuídos. A replicação e fragmentação são descritas como as principais estratégias de distribuição de banco de dados, e assim, serão abordadas durante o presente capítulo. 2.1 Definições gerais de banco de dados Segundo (Date, 2004) e (Abrahan, Henry, & Sudarshan, 1999) bancos de dados podem ser descritos como um sistema computadorizado de manutenção de registros/dados e informações que são associados a um conjunto de programas denominados sistema gerenciador de banco de dados. Um sistema gerenciador de banco de dados é uma coleção de arquivos e programas que permitem ao usuário acessar e manipular as informações por ele gerenciadas (Abrahan, Henry, & Sudarshan, 1999). O sistema gerenciador de banco de dados, assim, visa garantir acesso aos dados armazenados. Segundo a literatura os sistemas de banco de dados são projetados para manipular uma quantidade sempre crescente de informações. (Hector, Jeffrey, & Jennifer, 2001) enfatizam que os bancos de dados são essenciais para todos os ramos de negócios visto que esses são utilizados para armazenar informações que são vitais para as corporações. No cenário atual existe uma quantidade crescente de bancos de dados grátis e open-source, que são estruturados sobre a licença GPL. As pequenas e médias corporações, assim, optam por soluções como Postgre, MySql, Firebird, dentre outras. Essas soluções, entretanto, não atendem ao perfil distribuído das corporações, ou seja, não é possível recuperar informações espalhadas pelos nós de dados a partir de uma localização remota de maneira transparente. A Figura 1 ilustra um ambiente de banco de dados construído a partir de soluções grátis e open-source. Servidor Cliente Cliente Cliente Figura 1 - Ambiente de banco de dados

21 21 Observe na Figura 1 que a base de dados é centralizada em um nó da rede, e assim, o acesso a base de dados acorre a partir de uma instância do usuário que coleta informações no banco de dados requisitado. Tal ambiente de banco de dados segundo (Date, 2004), (Özsu & Valduriez, 2001), (Hector, Jeffrey, & Jennifer, 2001) e (Elmasri & Navathe, 2005) apresenta um problema de disponibilidade, ou seja, os dados estão centralizados em uma única base, e se, este nó de dados falhar, todas as requisições feitas ao banco serão conseqüentemente interrompidas. Objetivando resolver tal problema, a presente proposta irá fragmentar as bases de dados, e assim, se um nó de dados ficar indisponível, apenas as requisições referentes a este nó serão interrompidas. A construção de um sistema de banco de dados distribuídos apresenta-se como uma solução aos problemas ilustrados anteriormente, entretanto, apenas as soluções proprietárias consolidadas no mercado permitem suporte nativo à distribuição de dados (Oracle, SqlServer entre outras). O grande desafio, nessa dinâmica, é a construção de um sistema de banco de dados distribuídos a partir de soluções open-source. Um problema, entre outros, resultante de trabalhar com diferentes bases de dados é que apesar de existir a norma ISO/IEC 9075:2003 que visa padronizar o uso de SQL (também abordada na literatura como SQL: 2003) existe uma descontinuidade de padrões entre as diversas soluções existentes. A Tabela 1 apresenta algumas incompatibilidades entre as principais soluções gratuitas disponibilizadas atualmente. TIPOS DE DADOS MySQL Postgre Comentário Integer auto_increment serial Inteiro 4 bytes com auto-incremento JUNÇÕES MySQL Postgre Comentário Left Join Right Join Straight Join Left Join Right Join Inner Join Natural Join Full Outer Join Cross Join Tabela 1 - Comparativo entre Mysql e Postgre Junção automática da tabela A e B Mostra todos os tipos possíveis de junção Força ordem em uma tabela especifica Objetivando solucionar o problema de bases de dados centralizadas é proposto um middleware que terá por objetivo distribuir banco de dados open-source. O sistema, nessa dinâmica, será implementado de maneira a mascarar as principais heterogeneidades entre as

22 22 bases MySql e Postgre ilustradas na Tabela 1. Para implementar a proposta do middleware faz-se necessário o estudo de banco de dados distribuídos e como esses são projetados no cenário atual. 2.2 Definições gerais banco de dados distribuídos Bancos de dados distribuídos são uma coleção de múltiplos bancos de dados logicamente relacionados sobre uma rede de computadores (Özsu & Valduriez, 2001). Segundo (Date, 2004) o suporte completo a banco de dados distribuídos implica que uma única aplicação deve ser capaz de operar de maneira transparente sobre dados dispersos em uma variedade de bancos de dados diferentes. Um sistema de banco de dados distribuídos pode ser abordado como sendo o agrupamento de arquivos e/ou sistemas gerenciadores de banco de dados. Os arquivos, nessa dinâmica, devem estar inter-relacionados de maneira lógica, posicionados em uma rede de computadores e gerenciados através de uma interface comum. Os Sistemas de Gerência de Bancos de Dados Distribuídos (SGBDD) estendem as facilidades usuais de gerência de dados de tal forma que o armazenamento de um banco de dados possa ser dividido ao longo dos nós de uma rede de computadores (Elmasri & Navathe, 2005). A Figura 2 ilustra SGBDD onde uma aplicação pode acessar qualquer uma das bases de dados sobre um sistema operacional utilizando a rede de computadores como meio de comunicação. Figura 2 - Ambiente de um banco de dados distribuído Fonte: Adaptação (Date, 2004)

23 23 Observe que, na Figura 2, com exceção de Boston, cada aplicação possui seu próprio banco de dados local controlado por um determinado sistema gerenciador de banco de dados e com seus mecanismos individuais de controle de transações. A distribuição física dos dados de um banco de dados distribuído não implica necessariamente que os sistemas de computadores estejam distantes, na realidade, os sistemas poderiam estar presentes no mesmo ambiente físico (Özsu & Valduriez, 2001). A distribuição, nesse contexto, apenas indica que a comunicação entre os sistemas de bancos de dados passa a ser realizada através de uma rede de computadores. No modelo de banco de dados distribuídos, portanto, a memória não é um recurso compartilhado, ao invés disso, a rede torna-se o único recurso compartilhado, pois essa é responsável pela comunicação lógica e pelo inter-relacionamento entre os diversos sistemas gerenciadores de bancos de dados presentes em bancos de dados distribuídos. A literatura discorre sobre inúmeras vantagens da utilização de bancos de dados distribuídos, essas razões variam desde questões referentes à descentralização até questões como a distribuição lógica das corporações. Segundo (Abrahan, Henry, & Sudarshan, 1999) algumas das vantagens de utilizar bancos de dados distribuídos são: compartilhamento de dados, autonomia. Compartilhamento de dados: Proporciona um ambiente através do qual os usuários de uma determinada aplicação e/ou site podem ter acesso a dados posicionados em outro ambiente (Elmasri & Navathe, 2005). Autonomia: Cada aplicação e/ou site possui autonomia sobre os dados posicionados localmente. Segundo (Date, 2004) e (Hector, Jeffrey, & Jennifer, 2001), as corporações apresentam-se distribuídas logicamente em várias divisões como: departamentos, grupos de trabalhos, fábricas, laboratórios dentre outros. Os dados das corporações, nessa dinâmica, em geral apresentam-se distribuídos, tal distribuição contribui para que cada unidade organizacional mantenha os dados que são adequados à suas operações, assim, um sistema de bancos de dados distribuídos apresenta-se extremamente útil a essa configuração. 2.3 Replicação em banco de dados distribuídos Os bancos de dados distribuídos podem apresentar-se replicados, isto é, os seus dados podem possuir cópias em lugares distintos(hector, Jeffrey, & Jennifer, 2001). A

24 replicação das bases de dados pode ser apontada como um ponto importante, pois beneficia o sistema através do aumento da disponibilidade e da tolerância a falhas (Mattoso, Zimbrão, Lima, & Baião, 2005). Segundo (Özsu & Valduriez, 2001) a replicação é uma técnica fundamental para aumentar a confiabilidade e o desempenho em um sistema de banco de dados distribuídos. O caso mais extremo é a replicação do banco de dados inteiro em todos os nós da rede que compõem o sistema de banco de dados distribuído, criando assim, um banco de dados totalmente replicado (Elmasri & Navathe, 2005). A replicação, em geral, aumenta o desempenho e disponibilidade dos dados para transações do tipo somente leitura, contudo, as transações de atualização geram grande overhead 2, visto que as atualizações devem ser propagadas pelas diversas bases de dados existentes(abrahan, Henry, & Sudarshan, 1999). A replicação, portanto, segundo a literatura pode ser definida como uma técnica responsável por manter a consistência lógica das informações. A replicação de dados, nesse contexto, torna o acesso às informações simples, rápido e sem grandes custos, dessa maneira, princípios como disponibilidade, confiabilidade e desempenho justificam a sua utilização em um sistema de banco de dados distribuídos. Disponibilidade: Uma vez que os dados podem ser replicados 3 em vários locais, o sistema pode não ter que interromper o processamento apenas porque um local ou componente falhou(hector, Jeffrey, & Jennifer, 2001). A replicação, assim, contribui para o processo contínuo de melhoria, visto que o sistema de banco de dados distribuído pode continuar a operar desde que pelo menos um dos nós da rede de dados esteja operando de maneira correta(elmasri & Navathe, 2005). Confiabilidade: Mesmo se um nó da rede falhar haverá outro local que irá fornecer as mesmas informações do nó de dados que falhou (Hector, Jeffrey, & Jennifer, 2001). Desempenho: Uma consulta de recuperação de dados pode ser processada a partir do nó de dados local ao qual foi submetida(özsu & Valduriez, 2001). A transparência de replicação configura outro ponto de estudo em bases de dados replicadas. Réplicas (cópias) dos dados podem estar presente em locais distintos, assim, cabe ao projetista do banco de dados distribuído definir a melhor alternativa para acesso às informações. É desejável, porém, que usuários e aplicações não preocupem-se com a 2 Um custo adicional em processamento ou armazenamento que, como conseqüência, piora o desempenho de um dispositivo de processamento (Arnaut, 2007). 3 Diz-se que um banco de dados é replicado quando esse possui uma cópia dos seus dados em locais distintos (Hector, Jeffrey, & Jennifer, 2001). 24

25 localização física das informações. A transparência de replicação, portanto, apresenta-se como uma necessidade em sistemas de banco de dados distribuídos Transparência de Replicação A replicação em um sistema de banco de dados distribuído deve apresentar-se ao usuário de modo transparente, ou seja, os usuários devem ser capazes de comportar-se de um ponto de vista lógico como se os dados não fossem replicados (Date, 2004). A transparência de replicação (também abordada na literatura como independência de replicação) implica que o sistema de banco de dados distribuído deve tratar o sistema de gerenciamento de cópias de forma a não envolver o usuário na manipulação das informações (Özsu & Valduriez, 2001). Um sistema de banco de dados distribuído, assim, admite replicação se determinadas cópias da base de dados podem ser posicionadas em locais distintos. A Figura 3 ilustra um ambiente onde as bases de dados foram replicadas. NOVA YORK LONDRES Empregados_NovaYork EMP# DEPTO# SALÁRIO E1 D1 R$ 1.800,00 E2 D1 R$ 1.500,00 Empregados_Londres EMP# DEPTO# SALÁRIO E3 D2 R$ 1.450,00 E4 D2 R$ 2.560,00 E5 D3 R$ 1920,00 EMP# DEPTO# SALÁRIO E3 D2 R$ 1.450,00 E4 D2 R$ 2.560,00 Réplica Empregados_Londres EMP# DEPTO# SALÁRIO E1 D1 R$ 1.800,00 E2 D1 R$ 1.500,00 E5 D3 R$ 1920,00 Réplica Empregados_NovaYork Figura 3 - Um Exemplo de replicação de dados Fonte: Adaptação (Date, 2004) Observa-se que, na Figura 3, os usuários não decidem sobre a localização das réplicas. Uma vez que as mudanças afetam diretamente o desempenho da aplicação qualquer decisão sobre a localização das réplicas torna-se responsabilidade da aplicação.

26 26 Embora a replicação possa ser apontada como uma técnica extremamente útil para a construção de banco de dados distribuídos, essa reduz em geral a velocidade de propagação das atualizações. Durante a replicação, uma única atualização lógica deve ser executada em todos os nós de dados da rede de banco de dados distribuídos o que pode resultar em problemas de sincronização e inconsistência das bases Inconsistência das bases durante a replicação A replicação segundo (Buretta, 1997) pode ser caracterizada em síncrona e assíncrona em virtude do tempo de propagação de suas atualizações. (Lorêdo & Ferreira, 2004), enfatizam que, no modelo de replicação síncrona, todas as bases replicadas devem ser atualizadas simultaneamente. O modelo síncrono, portanto, apresenta réplicas idênticas durante todo o tempo. A replicação assíncrona resulta em problema de inconsistência das bases, visto que, as réplicas podem sofrer atualizações em diferentes intervalos de tempo. (Buretta, 1997) e (Lorêdo & Ferreira, 2004) elucidam que para uma replicação bem sucedida é necessário definir-se um modelo mestre/escravo onde todas as bases são sincronizadas a partir dessa relação. Alguns autores discorrem sobre disponibilidade, confiabilidade e desempenho como sendo algumas vantagens para utilizar-se replicação. A presente proposta de middleware, contudo, não irá implementar um sistema de banco de dados distribuído com bases replicadas. A replicação ainda que feita a partir da relação mestre/escravo acarreta inúmeros problemas como inconsistência, concorrência e sincronização. Problemas esses que são fruto de estudo e levaram (Almir, Danilov, Miskin-Amir, & Stanton, 2002) a propor uma nova forma de realizar replicação síncrona baseada em camadas que define elos entre o nó de dados principal (aqui denotado por mestre) e os nós de dados escravos. Levando-se em consideração a relação complexidade/vantagem para realizar replicação e o estudo existente sobre o mesmo, o presente trabalho limita-se a trabalhar com a fragmentação das relações Fragmentação em Banco de dados distribuídos A fragmentação em banco de dados distribuídos caracteriza-se pela divisão dos dados, dessa maneira, cada nó integrante da rede de dados armazena informações diferentes. Um SGBDD admite fragmentação se determinada relação de dados pode ser divida em fragmentos distintos. Esses fragmentos, assim, podem estar posicionados em locais variados

27 27 dentro dos nós de dados que irão compor o SGBDD (Date, 2004). Os fragmentos espalhados pela rede de dados, contudo, deverão fornecer informações suficientes para permitir a reconstrução da relação de dados original(abrahan, Henry, & Sudarshan, 1999). A literatura discorre sobre várias vantagens para a fragmentação em banco de dados distribuídos, em sua maioria, a vantagem freqüentemente abordadas por (Özsu & Valduriez, 2001), (Date, 2004) e (Elmasri & Navathe, 2005) é o aumento de desempenho no sistema de banco de dados distribuídos, visto que, os dados fragmentados podem ser armazenados no local em que serão utilizados freqüentemente reduzindo o tráfego de dados na rede. Na fragmentação, uma questão importante é a unidade lógica de distribuição (Elmasri & Navathe, 2005), em geral os aplicativos acessam uma dada relação que reside em uma unidade lógica de dados (também abordado na literatura como nó de dados). É importante decompor uma relação em fragmentos de acordo com sua utilização pelos aplicativos (Özsu & Valduriez, 2001). O acesso aos dados, complementarmente, deve ser realizado de maneira local e não sobre toda a rede de dados que compõem o sistema de banco de dados distribuído. Embora a literatura discorra sobre as vantagens de utilizar-se a fragmentação para aumentar o desempenho em um sistema de bancos de dados distribuídos, alguns quesitos devem ser abordados. O projeto de fragmentação deve incluir estudos sobre o tamanho dos fragmentos, forma de acesso a esses fragmentos e requisitos de rede como largura de banda, latência e sobrecarga (Abreu, 2006). Após análise desses requisitos e verificação da relação custo/benefício, a fragmentação deve ser projetada de maneira a evitar trabalho dispendioso como a junção de dois fragmentos retornados por uma consulta. (Abrahan, Henry, & Sudarshan, 1999) discorre sobre a fragmentação vertical e horizontal como dois esquemas básicos para distribuir uma relação, contudo, (Elmasri & Navathe, 2005) e (Özsu & Valduriez, 2001) apresentam um novo esquema de fragmentação denominado fragmentação mista (também conhecida como fragmentação híbrida) Fragmentação Vertical A fragmentação vertical caracteriza-se por dividir uma dada relação verticalmente segundo as colunas (Elmasri & Navathe, 2005). A fragmentação vertical de uma relação R, assim, produz fragmentos R1,R2,R3,...,Rn, e cada um desses atributos contém um subconjunto dos atributos de R bem como sua chave primária (Özsu & Valduriez, 2001). Segundo (Abrahan, Henry, & Sudarshan, 1999) A fragmentação vertical de R implica na definição de vários subconjuntos de atributos de forma que:.

28 28 A fragmentação, contudo, deve permitir a reconstrução da relação mesmo quando os fragmentos são armazenados separadamente. (Özsu & Valduriez, 2001) enfatizam que a reconstrução das relações fragmentadas se torna possível devido à operação de junção descrita por, assim, uma vez que o fragmento denotado por R i esteja completo, a operação de junção que irá reconstruir toda a relação torna-se possível graças a variável k que detona as chaves primárias dos fragmentos. A Tabela 2 e a Tabela 3 ilustram a fragmentação vertical de um projeto de banco de dados distribuídos para uma empresa que possua várias filiais. Nesse projeto o setor de recursos humanos está presente na filial 1, que tem por objetivo registrar todos os dados referentes a vida profissional do colaborador. O setor financeiro e contábil da empresa apresenta-se na filial 2, essa tem por finalidade controlar a vida financeira do funcionário a partir de suas atividades desenvolvidas. Observa-se que tanto a filial 1 quanto a filial 2 podem recuperar informações que não são referentes ao seu setor, contudo, a maior parte das consultas realizadas nas filias tendem a retornar resultados do fragmento local da tabela. #PK #PK_Colaborador DT_Admissão Dependentes... 1 Carlos Ferreira 19/02/ José da Silva 05/12/ Maria Antônia 15/09/ Tabela 2 - Fragmento da tabela empregados (Recursos Humanos) #PK #PK_Colaborador VL_Hora Horas_Mensais Salário... 1 Carlos Ferreira R$ 13, R$#2.970, José da Silva R$ 45, R$#10.032, Maria Antônia R$ 3, R$ 465,60... Tabela 3 - Fragmento da tabela empregados (Financeiro) Observa-se que ambos os fragmentos descritos na Tabela 2 e Tabela 3 possuem chave primária, tal característica garante a integridade semântica 4 do banco de dados. Segundo (Özsu & Valduriez, 2001) a integridade semântica garante a consistência do banco de dados, pois rejeita aplicações que levem a um estado inconsistente da base. 4 Integridade dos dados e informações garantida através da chave primária. Em banco de dados chave primária (primary key) é um conjunto de campos (um ou mais) onde as tuplas não são duplicadas. Chaves primárias também podem ser utilizadas como índices para outras relações. Para maiores informações sobre integridade semântica e chave primária consulte (Abrahan, Henry, & Sudarshan, 1999), (Date, 2004) e (Elmasri & Navathe, 2005)

29 Fragmentação Horizontal De acordo com (Özsu & Valduriez, 2001) e (Elmasri & Navathe, 2005), a fragmentação horizontal particiona uma relação em tuplas que pertencem a um dado fragmento horizontal. Dessa maneira, os fragmentos são especificados a partir de uma condição sobre seus atributos. O particionamento das tuplas resulta em uma seqüência de subconjuntos que podem ser denotados pela relação R. As tuplas da relação R devem obrigatoriamente pertencer a pelo menos um fragmento, de modo que a relação original possa ser reconstruída pela união dos fragmentos de R (Abrahan, Henry, & Sudarshan, 1999). Portanto para uma relação denotada por, sua reconstrução é elucidada por: (Özsu & Valduriez, 2001). (Özsu & Valduriez, 2001), entretanto, afirmam que uma relação horizontal pode ser particionada de forma primária e derivada Fragmentação Horizontal Primária A fragmentação horizontal primária divide uma relação horizontalmente agrupando linhas para criar subconjuntos de tuplas que possuem significado lógico (Elmasri & Navathe, 2005). Segundo (Almentero, Baião, & Matosso, 2004) a fragmentação horizontal primária é definida por uma operação de seleção que divide os fragmentos a partir de uma seleção sobre as tuplas da relação. (Özsu & Valduriez, 2001) definem a fórmula expressada por como sendo responsável por definir os fragmentos horizontais. F i nessa equação, é a condição que utiliza-se para definir as tuplas do fragmento R. A Figura 4 ilustra uma fragmentação horizontal primária para a tabela empregados. Figura 4 - Fragmentação horizontal primária da tabela empregados. Observa-se que, na Figura 4, houve a decomposição da tabela empregados em dois fragmentos horizontais que são definidos aqui como Frag_1 e Frag_2. Nota-se ainda que

30 30 Frag_1 lista somente os salários que são menores a , dessa maneira, a função F i é definida por. Assim,. Seguindo o mesmo raciocínio lógico utilizado para Frag_1 deduz-se. A relação R pode ser construída pela fórmula, onde Fragmentação Horizontal Derivada Uma fragmentação horizontal derivada é definida a partir de uma relação primária de acordo com uma operação de seleção definida por F i. A seleção, assim, pode ser especificada a partir de uma relação secundária. Na fragmentação horizontal derivada a relação secundária é relacionada com a primária a partir da chave estrangeira. O vínculo entre as relações primárias e a secundária é definido a partir de uma junção de equivalência (Elmasri & Navathe, 2005). O particionamento da relação secundária é feito de acordo com a fragmentação da relação primária, contudo, o resultado da fragmentação deve ser definido somente sobre os atributos que compõem a relação secundária. A Figura 5 ilustra uma fragmentação horizontal derivada para a tabela empregados. Figura 5 - Fragmentação horizontal derivada da tabela empregados Considere um vínculo 5 entre as relações Empregados e Departamento ilustrado na Figura 5 e denotado como H 1. Na relação Departamento, esse vínculo é estabelecido através da chave primária representada pelo ID do Departamento. O vínculo primário de H 1, assim, é Departamento, e esse, pode ser escrito usando notação formal como Primária(H 1 ) = 5 Na Figura 5 existe um vínculo sobre as relações Empregados e Departamento. Observa-se que a chave primária de departamentos é a chave estrangeira de funcionários.

31 31 Departamentos. A relação Funcionário, contudo, apresenta o ID como uma chave estrangeira que relaciona-se com Departamento, dessa maneira, o vínculo secundário de H 1 é funcionários ou Secundária(H 1 ) = Funcionários. Os funcionários, nesse contexto, poderão ser reunidos em dois fragmentos de acordo com o seu salário. O primeiro fragmento expressado por Func_1 contém os funcionários que recebem salários menores que O segundo fragmento Func_2 agrupa os funcionários cujos salários são superiores ou iguais a Os dois fragmentos Func_1 e Func_2 são representados na álgebra relacional como a junção da relação funcionários com a relação departamentos, dessa forma, e. Melhorando a representação formal, pode-se dizer que Primária(H 1 ) = S e Secundária(H 1 ) = R. Segundo (Özsu & Valduriez, 2001) os fragmentos horizontais derivados de uma relação R devem ser reconstruídos a partir da especificação formal onde w é o número máximo de fragmentos que serão definidos sobre R. R i é a junção do vínculo primário e secundário. S i é um formalismo descrito como onde F i é uma fórmula que define o fragmento primário, nesse caso, Si expressa o valor dos salários nos departamentos Fragmentação Mista A fragmentação mista caracteriza-se por utilizar seguidamente as estratégias de fragmentação vertical e horizontal. Utiliza-se a fragmentação mista quando faz-se necessário uma estrutura de fragmentação em forma de árvore para atender as necessidades dos aplicativos do usuário. A Figura 6, ilustra a fragmentação mista para uma dada relação. Figura 6 - Fragmentação Mista Fonte: Adaptado (Özsu & Valduriez, 2001)

32 32 A fragmentação horizontal pára quando dois fragmentos constituem uma única tupla de elementos, contudo, a fragmentação vertical apresenta como critério de parada um atributo que compõem um único fragmento. A fragmentação mista utiliza-se das mesmas regras de reconstrução utilizadas na fragmentação vertical e horizontal, dessa maneira, a reconstrução começa nas folhas da árvore e em seguida sobe na mesma em direção a raiz. Na Figura 6 a reconstrução da parte vertical da fragmentação mista é dada por, por conseguinte, a reconstrução final do fragmento global pode ser obtido realizando a união de R1 com R2 aqui expressada por. Segundo (Özsu & Valduriez, 2001), o número de aninhamentos certamente não é infinito, o que viabiliza a reconstrução da árvore de fragmentação. A Figura 7 ilustra a fragmentação mista. Figura 7- Fragmentação Mista da Relação ClientesConta A fragmentação mista pode ser descrita em uma seqüência de três passos onde: 1 - Inicialmente a relação ClientesContas é fragmentada seguindo os conceitos da fragmentação horizontal primária, na Figura 7 utilizou-se a função. 2 - Os remanescentes são então fragmentados verticalmente, nesse modelo de fragmentação as tuplas são divididas verticalmente. 3 - Ao fragmentar verticalmente um relação deve ser criado um elo entre os fragmentos verticais, na Figura 7 esse elo é denominado de LK. Por fim cada fragmento pode ser posicionado separadamente e a sua reconstrução é realizada utilizando a álgebra relacionada descrita na Figura 6.

33 33 A transparência de fragmentação em sistemas de bancos de dados distribuídos é extremamente útil, pois permite que usuários e aplicações realizem acesso dos dados sem que para isso seja preciso informar o endereço físico da relação Transparência de Fragmentação A transparência de fragmentação permite ao usuário comporta-se do ponto de vista lógico como se os dados não estivessem fragmentados. Segundo (Date, 2004) a transparência de fragmentação permite que os dados sejam refragmentados a qualquer momento, o que pode facilitar a redistribuição das informações. A transparência, nessa dinâmica, simplifica o acesso as informações a partir de um terminal de consultas. Os usuários apenas percebem uma visão geral dos dados formada por união e junções de fragmentos que estão distribuídos a partir dos nós de dados. Segundo (Özsu & Valduriez, 2001) e (Abrahan, Henry, & Sudarshan, 1999) um sistema de banco de dados distribuído quando fragmentado proporciona um esforço adicional para elucidar a transparência de fragmentação. Os objetos fragmentados são manipulados por consultas que foram projetadas para funcionar sobre relações inteiras, contudo, a execução dessas passa a ter um universo de sub-relações. Proporcionar a transparência, nesse contexto, pode ser visto como um problema complexo, pois, envolve o estudo de algoritmos que sejam capazes de transformar fragmentos de dados em relações inteiras sem que exista grande overhead na manipulação/consulta desses fragmentos. Para facilitar a construção de sistemas de banco de dados distribuídos, a literatura elucida a importância de projetar a distribuição das bases dados. O projeto de banco de dados distribuídos, assim, deve solidificar-se antes do início da sua implementação. 2.5 Projeto de banco de dados distribuídos O projeto de banco de dados distribuídos segundo (Özsu & Valduriez, 2001) inclui o projeto de distribuição das bases de dados e o projeto de distribuição dos aplicativos que irão funcionar no ambiente distribuído. A rede de dados também deve ser projetada de acordo com as decisões relativas à distribuição visto que as requisições dos aplicativos utilizam-se da mesma para mover os resultados da consultas. Um ambiente heterogêneo, seja de bases de dados ou de sistema operacional, dificulta a implementação do projeto, uma vez que, durante a execução as especificidades de cada ambiente devem ser mascaradas.

34 34 A fragmentação e replicação de dados são etapas importantes do projeto, pois essas definem a maneira como os aplicativos terão acesso às bases de dados. A distribuição, nesse contexto, deve levar em consideração o perfil distribuído das corporações e/ou organizações e segundo tal perfil, pode-se definir a melhor estratégia para as bases (replicar e/ou fragmentar). A literatura orienta que, para os usuários mais inexperientes, um alto grau de transparência irá facilitar a utilização do sistema de banco de dados distribuídos. Contudo, trará mais dificuldades à implementação do projeto. A literatura discorre sobre dois processos, que fazem parte do projeto de banco de dados distribuídos: top-down e bottom-up. Top-down: nesse processo, a primeira etapa do projeto consiste da análise de requisitos que proporcionam conhecimento suficiente para realizar o projeto conceitual e definir as interfaces para os usuários finais. Bottom-up: processo utilizado quando existe implementado um sistema de banco de dados local e deseja-se fazer a distribuição. Esse processo, assim, tem como ponto inicial o estudo dos esquemas locais das bases. Utiliza-se a reestruturação local para gerar o esquema conceitual global e conseqüentemente transformar as várias bases individuais em uma única base global. A interoperabilidade, segundo (Özsu & Valduriez, 2001) é um problema decorrente de projetos de banco de dados distribuídos do tipo Bottom-up que não utiliza a fragmentação horizontal primária. Os esquemas individuais são transformados em esquemas globais o que pode resultar em problemas de reutilização das relações, visto que essas não possuem um elo de ligação dos fragmentos característicos das fragmentações mista, horizontal e secundária. A literatura salienta que, caso seja utilizada uma fragmentação diferente da horizontal primária, irá existir uma depreciação do esquema global de integração dos dados e assim, este deve sofrer uma etapa denominada de conversão ilustrado na Figura 8. Na Figura 8 a conversão pode ser elucidada como sendo uma tradução de esquemas, ou seja, utiliza-se uma representação canônica denotada por InS que tenha capacidade de produzir n conversores que recebem os esquema locais. Após a conversão, utiliza-se um integrador de dados que agrupa os esquemas gerando ao final um esquema conceitual global (ECG)

35 35 Figura 8 - Conversão de esquemas Fonte: (Özsu & Valduriez, 2001) O projeto top-down facilita a implementação de banco de dados distribuídos visto que as bases de dados são projetadas e posicionadas levando-se em consideração as necessidades de cada aplicação. Cada nó de dados, dessa maneira, pode possuir sua própria interface de acesso aos dados o que facilita a autonomia em banco de dados distribuídos. Como não existe esquemas locais individuais fragmentados verticalmente, ou seja, não existe na base tabelas subdividas verticalmente, a interoperabilidade não apresenta um problema que resulte em conversão de esquemas. Levando-se em contas tais facilidades a presente proposta limita-se a distribuir banco de dados a partir de um projeto bottom-up tal distribuição só será possível porque a fragmentação escolhida é a horizontal primária. O presente middleware não terá como foco principal a distribuição de bases de dados anteriormente projetadas a partir de esquemas locais e que sofreram e/ou irão sofrer fragmentação mista, vertical e horizontal secundária. 2.6 Consultas em banco de dados distribuídos Segundo (Abrahan, Henry, & Sudarshan, 1999), (Özsu & Valduriez, 2001) e (Elmasri & Navathe, 2005), em um sistema de banco de dados distribuídos, as consultas devem ser projetadas para otimizar o tempo total de apresentação dos resultados. As consultas, nesse sentido, proporcionam uma melhor performance ao sistema de banco de dados distribuído quando o tráfego de dados na rede é minimizado. O processo de consultas, assim, pode consistir de uma etapa de otimização denominada de global, seguida de etapas

36 locais de otimização em cada nó de dados (Date, 2004). A seguir, é apresentado um sistema de consultas distribuídas que tem como meta principal reduzir a transferência de dados pela rede. #PK NM_Empregado NR_Fone DT_Nascimento Sexo NR_Cpf $FKD 01 Carlos da Silva /12/1985 M Maria da Dores /02/1978 F Tabela 4 - Relação empregados 36 Ao supor que a Tabela 4 possua registros e que cada tupla ocupe um espaço físico em disco de 100 bytes, a relação empregados resultaria em bytes de informações. Cada empregado está obrigatoriamente alocado em um departamento - o que é uma relação disponibilizada remotamente. A Tabela 5 possui 200 registros que ilustram todos os departamentos da empresa. Uma tupla da Tabela 5 possui 30 bytes de informações e conseqüentemente a relação departamentos ocupa 6000 bytes em disco. #PK NM_Departamento FG_Status 1 Tecnologia 1 2 Desenvolvimento Tabela 5 - Relação departamentos O usuário de uma determinada aplicação requisitou uma consulta no banco de dados que retorne todos os empregados da empresa com seu respectivo departamento de atuação, tal usuário reside em um terceiro nó de dados aqui denominado de resultado da consulta. A consulta pode ser definida na álgebra relacional como, onde P é o resultado da junção entre as relações Departamentos e Empregados. Tal junção é realizada a partir da chave primária da tabela departamentos denotada por #PK e relaciona-se com empregados a partir da chave estrangeira $FKD. Uma vez que o resultado na consulta será exibido remotamente, ilustram-se três estratégias simples para executar a consulta distribuída. 1. Transferir ambas as relações para o nó de dados denominado resultado, assim, um total de = bytes seriam transferidos. Após a transferência realizar a junção das relações empregados e departamentos.

37 37 2. Supondo que o resultado das junções empregados e departamentos resulte em uma tupla de 115bytes transferir a relação empregados para o nó de dados onde encontra-se a relação departamentos. Realizar, em seguida, a junção entre as relações e posteriormente enviar o resultado até o nó de dados resultados da consulta. A transferência total de informações, portanto, seria de 115* = = bytes seriam transferidos. 3. Transferir a relação Departamentos para o nó de dados onde encontra-se a relação empregados realizando a junção das relações posteriormente. Tendo em vista que o resultado da junção empregados e departamentos gera uma tupla de 115 bytes e que a relação empregados possui registros um total de bytes ( * 115 = ) seriam transferidos para o nó de dados resultado. Visto que em uma consulta distribuída tem-se como objetivo otimizar o tráfego de dados na rede e conseqüentemente aumentar o desempenho da rede de dados a estratégia três seria a escolhida Otimização de Consultas em bancos de dados distribuídos A otimização de consultas consiste de um plano para a sua execução que vise minimizar o seu custo total. A literatura discorre sobre a utilização de módulos de software responsáveis por tal otimização. (Özsu & Valduriez, 2001) enfatizam que um módulo composto por três componentes denominados de espaço de pesquisa, modelo de custo e estratégia de pesquisa torna-se eficiente no processo de otimização. Espaço de pesquisa: definição de árvore de operadores que reafirma a ordem de execução das operações. Modelo de custo: composto por funções de custo com fórmulas estatísticas para avaliar os resultados. Estratégia de pesquisa: desenvolvimentos de algoritmos dinâmicos capazes de procurar exaustivamente o melhor plano para reconstruir as relações. Segundo a literatura essa alternativa torna-se ineficiente quando o número de relações excede a cinco. (Mattoso, Zimbrão, Lima, & Baião, 2005) Discorrem sobre um processador de consulta denominado ParGres que utiliza-se de computação paralela para cria um cluster capaz de ordenar, coordenar e realizar as operações de consultas que consomem grande tempo para o seu processamento.

38 38 Para (Hector, Jeffrey, & Jennifer, 2001) a otimização de consultas pode ser alcançada através de um compilador que analisa as entradas em formado SQL construindo em seguida uma árvore de expressões algébricas relacionais. Tal árvore é decomposta em um plano físico de consultas que irá indicar as operações e ordem de execução das consultas, juntamente com o melhor algoritmo para essas etapas. A árvore de expressões relacionais, contudo, segundo a literatura pode utilizar-se de heurísticas que sejam capazes de usar leis algébricas simples como comutação, associação e projeção. A heurística, entretanto, deve evitar produtos cartesianos que não são requisitados pela consulta, pois, segundo (Date, 2004) uma das melhores e mais eficientes maneiras de otimizar as consultas é reduzir o tráfego de dados na rede, ainda que, o sistema de banco de dados distribuído tenha interface de redes de alta velocidade. A Figura 9 ilustra uma árvore de relações algébricas. Figura 9 - Árvore de relações algébricas Fonte: Adaptado (Hector, Jeffrey, & Jennifer, 2001) Observe na Figura 9 que se o produto cartesiano entre as relações H e J não for requisitado pela consulta o produto cartesiano entre essas relações será descartado pela heurística de construção de árvores relacionais. É possível perceber o agrupamento de operadores relacionais, nota-se, que na árvore relacional resultante a relações foram agrupadas a partir das operações de junção e união. As árvores relacionais vão sempre possuir um número finito de operadores, nessa dinâmica, agrupar tais operadores consiste em reordená-los para que seja reduzido o tempo de sua execução. Otimizar consultas em banco de dados distribuídos, nessa dinâmica, exige a construção de heurísticas e algoritmos que sejam capazes de diminuir o tempo de execução de operações relacionais e que reduzam conseqüentemente o tráfego de dados na rede. Diminuir

39 o tráfego consiste em escolher uma dada relação que tenha menor quantidade de tuplas para realizar as operações relacionais Considerações do capítulo Bancos de dados distribuídos são de extrema importância no cenário atual, contudo, a sua implementação envolve o estudo de técnicas que são constantemente atualizadas a partir de pesquisas tecnológicas e científicas. O projeto em banco de dados distribuídos apresenta-se extremamente útil. O projeto de banco de dados distribuídos facilita sua implementação, visto que, as bases são projetas e posicionadas levando-se em consideração as necessidades de cada aplicação. Bancos de dados distribuídos podem ser fragmentados e/ou replicados, A fragmentação consiste em dividir as bases de dados em fragmentos que poderão ser posicionados em nós de dados distintos. A fragmentação, nessa contexto, melhora o desempenho da base de dados visto que essas poderão executar transações de leitura e transações de escrita de maneira concorrente. Em virtude dessa característica a proposta irá trabalhar com a fragmentação horizontal primária das relações, visto que, cada tupla fragmentada irá possuir uma chave primária e assim problemas de inconsistência de fragmentos e conversão de esquemas serão evitados. A fragmentação, entretanto, deve ser projetada de acordo com as aplicações que irão utilizar o sistema de banco de dados distribuídos. As consultas, nesse contexto, poderão ser otimizadas utilizando as técnicas de consulta em banco de dados distribuídos descritas na seção 2.6 do presente trabalho, assim, a junção de dois os mais fragmentos deve evitar overhead s. A replicação em banco de dados distribuídos pode ser parcial e/ou total. Quando parcial apenas algumas relações das bases de dados são replicadas. A replicação total, nesse contexto, irá fazer cópias de todas as relações das bases de dados. Embora a replicação seja importante visto que os dados possuem backup, essa, apresenta como desvantagem a sincronização dos dados durante as transações de escrita em virtude dessa característica a proposta de middleware não irá replicar as relações.

40 40 3 SISTEMAS DISTRIBUÍDOS O presente capítulo tem por finalidade elucidar os principais conceitos referentes a sistemas distribuídos que serão aplicados à construção da proposta. Faz-se necessário, assim, o estudo e entendimento das principais tecnologias utilizadas para construção de sistemas distribuídos. Nesse contexto, será definido para à implementação do protótipo um modelo arquitetural, ou seja, um modelo que aborda aspectos sobre a disposição das partes de um sistema distribuído sobre uma rede de computadores. 3.1 Definição de sistema distribuído Segundo (Coulouris, 2005), um sistema distribuído é um sistema onde os seus componentes são interligados por uma rede de computador e que coordena suas ações apenas por passagem de mensagem. Entretanto, (Tanembaum & Steen, 2002) define sistema distribuído como sendo uma coleção de computadores independentes que se apresentam ao usuário como um sistema único coerente. (Wu, 1999) elucida sistemas distribuídos como sendo a distribuição de hardware, software, que tem por finalidade descentralizar e gerenciar o controle de dados. Um sistema distribuído, portanto, pode ser definido como sendo uma extensão de redes de computadores onde os seus componentes cooperam/colaboração entre si coordenando suas tarefas através da passagem de mensagem a fim de ser visualizado como sendo um sistema único. 3.2 Objetos distribuídos Segundo (Coulouris, 2005) objetos distribuídos é um modelo de programação para aplicativos que estão distribuídos e que precisam invocar operações (métodos 6 ) em processos diferentes que podem estar posicionados em computadores distintos. No modelo de programação utilizando objetos distribuídos, contudo, deve ser utilizada uma arquitetura de sistemas distribuídos para efetivar a comunicação entre os objetos distribuídos. Os modelos arquiteturais, nessa dinâmica, são de extrema importância a implementação de sistemas distribuídos, assim, cabe ao projetista definir o modelo que irá proporcionar um melhor desempenho/confiabilidade à sua aplicação. Aplicações cujo foco é a 6 Na programação orientada a objetos um método é uma definição (habilidade) dentro de uma classe. A instância de uma classe retorna um objeto que pode acessar (executar) métodos.

41 41 escalabilidade, ou seja, aumentar em proporções logarítmicas 7 o número de usuários e/ou componentes devem utilizar o modelo peer-to-peer, nesse modelo, os processos cooperam entre si e não existe a distinção entre cliente e servidor. Uma vez que a proposta de middleware não objetiva um crescimento logarítmico tal modelo arquitetural não será utilizado. Um modelo de sistema distribuído que utilize a requisição e/ou solicitação de serviços devem utilizar, entretanto, um modelo arquitetural denominado de cliente/servidor. A Figura 10 ilustra tal arquitetura. Figura 10 - Modelo cliente-servidor Observe na Figura 10 que o processo denominado servidor irá disponibilizar serviços e/ou recursos ao processo solicitante (cliente), note ainda, que tal comunicação pode ocorrer entre dois processos servidores, contudo, um processo servidor será caracterizado como cliente, ou seja, realizará a requisição/solicitação de serviços. Uma vez que a presente proposta de middleware terá como objetivo fragmentar os dados permitindo que as tuplas sejam recuperadas a partir da solicitação/ requisições, o modelo cliente/servidor apresenta-se ideal para tal configuração, e assim, será o utilizado. A comunicação entre os objetos distribuídos, nessa dinâmica, é realizada a partir de invocações remotas a métodos que trocam parâmetros e que podem recebem resultados. Segundo (Deitel & Deitel, 2006) na arquitetura cliente/servidor os objetos remotos são gerenciados pelo servidor e os clientes apenas invocam tais métodos. (Horstmann & Cornell, 2002), assim, salientam, que o objeto servidor reúne as informações emitidas pelo cliente e, nessa perspectiva, pode acessar um banco de dados retornando as informações solicitadas/requisitadas. O objeto servidor, nesse contexto, irá acessar a base de dados fragmentada retornando ao cliente as tuplas solicitadas, e assim, os fragmentos de dados serão 7 Uma função logarítmica pode ser descrita como a inversa de uma função exponencial, se a sua representação logarítmica será (Flemming & Gonçalves, 1992). Como exemplo de função logarítmica em ambiente distribuídos pode-se ilustrar o número de computadores na web que cresce constantemente em intervalos sempre menores de tempo. Para maiores informações sobre escalabilidade na web consulte (Coulouris, 2005).

42 42 manipulados pelo objetos remotos que irão colaborar entre si criando um ambiente de banco de dados distribuído com fragmentação da base de dados. A Figura 11 ilustra um ambiente de invocação de objetos distribuídos. Figura 11 - Invocação de objetos distribuídos Observe na Figura 11 que o objeto A pode invocar métodos remotamente do objeto B, contudo, para que está comunicação seja estabelecida o objeto remoto B deve disponibilizar ao objeto A uma referência de objeto remoto. A referência de objeto remoto consiste em atribuir um identificador único ao objeto, assim, todo o sistema distribuído terá como referência esse identificador. Os objetos remotos, entretanto, devem possuir uma interface remota, ou seja, uma especificação que irá conter todos os métodos que poderão ser invocados remotamente. Note também que o objeto B pode acessar de maneira local os objetos C e D, contudo, (Coulouris, 2005) salienta que o acesso e/ou localização entre objetos devem satisfazer os desafios de transparência de acesso e localização. Transparência de acesso: Os objetos locais e remotos são acessados pela mesma classe de operações, portanto, não deve existir distinção entre operações de acesso local e remoto. Transparência de localização: Os objetos remotos podem ser acessados sem que o usuário e/ou aplicação informem a sua localização física, assim, não é necessário informar o endereço IP durante a comunicação entre os objetos. Como elucidado na seção 2.7 do presente trabalho a proposta de middleware irá fragmentar as relações, ou seja, fragmentos da base serão posicionados em computadores distintos, assim, o relacionamento dos fragmentos será feito utilizando o modelo de programação com objetos distribuídos. Nesse modelo de programação uma estação (1) vai requisitar dados de uma relação presente em outra estação (4). A Figura 12 ilustra o processo de recuperação de relações fragmentadas utilizando objetos distribuídos.

43 43 Figura 12- Objetos distribuídos em BDD fragmentado Na Figura 12 um objeto distribuído é posicionado em cada nó do banco de dados distribuído. Cada objeto distribuído pode invocar métodos remotamente enviando parâmetros e em seguida receber resultados. Os objetos distribuídos, contudo, podem ser acessados localmente por aplicações que irão requisitar serviços. Observe o nó de dados 4, uma aplicação acessa localmente o objeto distribuído presente nesse nó solicitando tuplas presentes em uma determinada tabela. O objeto remoto (nó de dados 4) estabelece conexão com a base de dados local, se a tabela solicitada for encontrada, as tuplas retornadas são então devolvida para a aplicação. Entretanto, caso a tabela solicitada não esteja localmente, o objeto distribuído acessa de maneira transparente ao usuário o método de conexão com a base de dados 1 (nó de dados 1) enviado como parâmetro o SQL desejado. O objeto remoto 1 efetua a consulta na sua respectiva base de dados, devolvendo em seguida as tuplas retornadas para o objeto distribuído 4 que por sua vez retorna as tuplas para a aplicação que requisitou as informações. É importante ressaltar que os sistemas distribuídos devem ocultar do usuário final a separação de componentes. Em nível de projeto e implementação, entretanto, o projetista/programador conhece toda a estrutura interna de comunicação entre os componentes do sistema distribuído. Cada objeto distribuído, assim, terá conhecimento de quais tabelas existem na base de dados local, e qual será o endereçamento das respectivas tabelas do banco de dados distribuídos. O usuário da aplicação, contudo, não será capaz de afirmar se as tuplas estão sendo recuperadas remotamente e/ou localmente.

44 44 Uma vez que os fragmentos são recursos compartilhados inúmeros elementos podem estar acessando esses recursos de maneira concorrente, conseqüentemente, um mecanismo de controle de concorrência deve ser utilizado a fim de evitar que o recurso compartilhado tenha o seu conteúdo e/ou informação alterado. 3.3 Controle de concorrência Concorrência pode ser definida com uma situação onde os componentes e/ou aplicações (dois ou mais) de um sistema distribuído tentam acessar um recurso compartilhado de maneira simultânea. Para que o recurso compartilhado não seja danificado mecanismos de controle de concorrência devem ser implementados pelo programador de sistemas distribuídos. Na presente proposta de middleware, entretanto, as bases de dados serão fragmentadas de forma horizontal primária, nesse modelo de fragmentação, as chaves primárias das relações estão presentes nos fragmentos e segundo (PostgreSQL, 2006) e (MySQL, 2005) os próprios gerenciadores de banco de dados utilizados (Mysql e postgres) implementam internamente mecanismos de controle de concorrência que visam garantir as propriedades de atomicidade, consistência, isolamento e durabilidade. Atomicidade: cada transação é realizada de maneira atômica, e assim, deve ser executada integralmente ou então deve ser desfeita. Consistência: as transações devem levar os fragmentos a um estado consistente, ou seja, as restrições e unicidades de chaves devem ser respeitadas. Isolamento: a execução de uma transação não deve ser afetada por outra. Durabilidade: os efeitos de uma transação só podem ser desfeitos por outra transação. O controle de concorrência, nessa dinâmica, será implementado internamente pelos próprios bancos de dados utilizados, nesse modelo, mesmo que um ou mais objetos distribuídos tentem acessar o mesmo fragmento no intervalo de tempo t os próprios fragmentos a partir das bases de dados garantem a consistência das informações. A replicação em banco de dados distribuídos, entretanto, acarreta problemas referentes à sincronização das bases replicadas.

45 Replicação em ambientes distribuídos A replicação em banco de dados distribuídos segundo (Buretta, 1997) deve caracterizar pela atualização simultânea das bases, assim, como descrito na seção a replicação em banco de dados resulta em problemas de inconsistência de bases, entretanto, um ambiente distribuído com replicação acresce inúmeros desafios como a sincronização dos elementos distribuídos. Inicialmente pode-se ilustrar a sincronização interna entre dois ou mais processos que tentam acessar uma determinada réplica. Segundo (Coulouris, 2005) em um sistema distribuído síncrono são conhecidos os limites e taxas de derivação dos relógios e o atraso máximo de transmissão de mensagens, contudo, dois processos A e B podem buscar acesso á mesma réplica em um instante de tempo t. A Figura 13 ilustra uma tentativa de acesso simultâneo. Figura 13 - Consulta/Atualização réplica Observe na Figura 13 que o processo A tem por objetivo fazer uma consulta em uma determinada réplica, contudo, no mesmo intervalo de tempo t o processo B objetiva atualizar as informações. O problema resultante de tal situação é que todas as réplicas no banco de dados distribuídos devem ser atualizadas no instante de tempo t para que não exista, assim, inconsistência de informações. É fato que a operação de atualização deveria ter precedência sobre a consulta, entretanto, para que ocorra tal situação o processo B deveria enviar o tempo de seu relógio local para o processo A, assim, a consulta seria executada no intervalo de tempo t + T trans onde T trans é o tempo que leva a transmissão da mensagem m do processo B

46 46 até o processo A. A sincronização, dessa maneira, seria realizada. O processo B iria propagar a atualização, nesse momento, um controle de concorrência como a exclusão mútua 8 com estrita alternância poderia ser ativado, e assim, a consulta seria realizada após a atualização. O problema resultante é que T trans segundo (Coulouris, 2005) pode sofrer variações e é desconhecido, e segundo (Horstmann & Cornell, 2002), os outros processos disputam recursos com os processos a serem sincronizados e a mensagem m compete com as outras mensagens transmitidas pela rede. Uma vez que a comunicação só ocorre através da troca de mensagens e existe limites de sincronização dos elementos em rede, a noção de tempo (relógio global) torna-se inexistente. Em solução a este problema (Cristian, 1989) sugeriu o uso de um servidor de tempo, conectado a um dispositivo que recebe sinais UTC 9, para sincronizar computadores externamente. Outra alternativa de sincronização é descrita como algoritmo Berkeley Algoritmo Berkeley (Gussela & Zatti, 1989) apresentaram em 1989 um algoritmo de sincronização para computadores em ambiente UNIX Berkeley, tal mecanismo foi batizado de algoritmo Berkeley devido ao versão do sistema operacional. O algoritmo consiste em coordenar a sincronização através de um computador central denominado mestre. O computador central (mestre) consulta periodicamente os computadores escravos que devem ter seus relógios sincronizados. Os escravos, nessa dinâmica, devem enviar os valores de seus relógios internos ao mestre que em seguida deve estimar o tempo entre os relógios (escravos) considerando o tempo de envio e recebimento das mensagens. A estimativa de tempo realizado pelo mestre é semelhante ao método de sincronização proposto por (Cristian, 1989), entretanto, o mestre deve calcular a média dos relógios escravos gerando, assim, probabilidades balanceadas. segundo (Gussela & Zatti, 1989) o balanço das probabilidades tende a extinguir as discrepâncias entre os relógios internos, entretanto, para que o protocolo funcione o tempo máximo de comunicação entre mestre e escravos devem ser menor que o tempo de comunicação das demais mensagens do sistema. O mestre, assim, obrigatoriamente elimina os tempos de leitura maiores que o seu valor máximo. 8 Mecanismo de controle de concorrência que consiste é controlar o acesso à região critica, (informação e/ou dados compartilhados), o modelo com estrita relevância não permite o acesso simultâneo á região critica. 9 Coordenada de tempo universal. Antigamente conhecido como tempo médio de Greenwich (GMT) (Gpsglobal, 2003)

47 47 Replicação de um banco de dados em um ambiente distribuído envolve um complicado processo de sincronização dos inúmeros processos que buscam acesso á réplicas. Questões como determinar com exatidão o tempo entre troca de mensagens, medir o tempo entre tarefas distribuídas e inexistência de um relógio global proporcionam uma complexidade logarítmica à implementação de tal funcionalidade. Ainda que existam algoritmos como os de (Cristian, 1989) e (Gussela & Zatti, 1989) a presente proposta não irá replicar as bases de dados visto que ambos os algoritmos apresentam o fator tempo com um ponto crítico. Como descrito na seção existe uma enorme variação entre os relógios internos de cada escravo o que dificulta ainda mais a implementação de um banco de dados distribuído com replicação de bases. Por fim, um mecanismo de sincronismo mal implementado pode levar as transações de leitura e escrita a entrarem em deadlock 10, ou ainda alterar o erroneamente o conteúdo da réplica acessada e assim resultar em inconsistências em todo o banco de dados distribuído, visto que, a réplica inconsistente realizará atualizações em todas as réplicas existentes. Diante de tais fatores a replicação poderá ser implementada em trabalhos futuros que terão como objetivo apenas assegurar um correto processo de replicação em banco de dados distribuídos. O presente trabalho terá como foco principal a divisão de uma base de dados centralizada em vários fragmentos, dessa maneira, o perfil distribuído das aplicações poderá ser explorado. Para implementar a fragmentação será utilizado objetos distribuídos em conjunto como as tecnologias existentes para construção de sistema distribuídos. 3.5 Tecnologias para construção de sistemas distribuídos Objetivando facilitar a implementação de sistemas distribuídos o programador/analista pode utilizar-se de um middleware, ou seja, uma camada de software que fornece uma abstração de programação para sistemas distribuídos e que oculta do programador as especificidades de hardware, software e sistema operacional. O programador, assim, não necessita desprender tempo preocupando com protocolos de redes, visto que, segundo (Coulouris, 2005) o middleware fornece um modelo de programação baseada em objetos remotos que mascara as heterogeneidades de rede, apresenta notificação remota de eventos e acesso a banco de dados remotos. 10 Situação em que um processo espera por um recurso que nunca poderá alocar. Um caso típico é quando um processo A está utilizando um recurso X e espera pelo recurso Y, já alocado por um processo B, que por sua vez espera pelo recurso X.

48 48 Segundo (Deitel & Deitel, 2006) o RPC (Remote Procedure Call) desenvolvido na década 80 pode ser descrito como um dos primeiros modelos de middleware para programação distribuída e tinha por finalidade realizar o acesso transparente a procedimentos e funções remotas em programas estruturados. O surgimento do paradigma orientado a objetos, contudo, elucidou um novo conceito de programação. As unidades de software, nesse modelo, podem interagir a partir de instâncias de classes que tem por função executar/referenciar métodos dentro de objetos. O RMI (Remote Method Invocation ), assim, foi concebido como uma tecnologia semelhante ao RPC, mas que, tem por finalidade fazer a invocação remota de métodos que então contidos dentro de objetos. A Figura 14 ilustra as camadas de software, hardware e rede para construção de sistema distribuídos baseados no modelo de programação RMI/RPC. Figura 14 - Camada de serviços em sistemas distribuídos Na Figura 14, as camadas inferiores denominada de plataforma fornecem serviços as camadas superiores, assim, o programador não preocupa-se com os componentes inferiores, ou seja, a invocação remota a partir de RMI e/ou RPC mascara todas as especificidades referentes aos componentes de software, hardware e protocolos de redes das plataformas. A constante utilização da computação distribuída para a resolução de problemas nas esferas científicas e tecnológicas proporcionou o surgimento de diversas implementações de middleware RMI no cenário atual. Contudo, (Tari & Bukhres, 2001) define DCOM (Distributed Component Object Model), CORBA (Common Object Request Broker Architecture), e JAVA RMI como sendo os principais padrões de middleware orientados a objetos, entretanto, a tecnologia WS (Web Services) é uma implementação de middleware que está em constante crescimento sendo utilizada no cenário atual para promover serviços na web, apesar de não ser orientado a objetos.

49 Distributed Component Object Model DCOM (Distributed Component Object Model) é uma tecnologia proprietária da Microsoft que permite a comunicação entre objetos distribuídos. Os objetos clientes devem ser criados a partir de um comando CoCreateInstance para que possa ser efetuada a comunicação com o servidor (Msdn, 1999). No modelo DCOM o cliente recebe uma referência para um objeto proxy que estende uma classe de interface responsável pela serialização 11 dos parâmetros de entrada. Na chamada remota o cliente/aplicação informa os parâmetros a serem transmitidos a partir da rede (Strings s, Arrays e até mesmo objetos) o servidor recebe os parâmetros invocando os métodos desejados, e em seguida, retransmite o resultado dos respectivos métodos. Por ser uma tecnologia proprietária não existe implementação para arquiteturas Linux/Unix, assim, o DCOM só pode ser implementado a partir de sistema operacionais da família Windows, Macintosh e Solaris o que constitui uma enorme desvantagem Web Services Web Services é uma tecnologia que permite às aplicações utilizarem o protocolo HTTP (HyperText Transfer Protocol) para enviar e receber dados a partir de um formato universal denominado XML (extensible Markup Language), nesse contexto, o XML fornece um sintaxe comum para a representação dos dados (Msdn, 1999). A troca de mensagens entre os clientes e os serviços é disponibilizada a partir de um protocolo denominado SOAP (Simple Object Access Protocol). O protocolo SOAP permite a comunicação entre cliente e serviços através da chamada remota de procedimentos e/ou funções (RPC). As chamadas RPC emitidas pelo cliente são serializadas no protocolo HTTP, e assim, são transmitidas até o serviço remoto. Ao receber a mensagem o serviço remoto extrai a chamada repassando-a para uma aplicação servidora. Os dados retornados da aplicação servidora são então codificados sobre o formato XML, e em seguida serializados para serem devolvidos ao cliente através do protocolo HTTP. No cliente as informações são extraídas e/ou decodificadas e então repassadas para a aplicação. Apesar do constante crescimento de Web Services, essa tecnologia apresenta desvantagens quando comparadas as demais elucidadas por (Tari & Bukhres, 2001). Uma vez que utiliza-se de RPC não estende o modelo de programação orientado a objetos e assim limita-se apenas a invocar procedimentos,ou seja, não pode manipular objetos. A tecnologia 11 Encapsular

50 50 web services apresenta desempenho reduzido quando comparada como JAVA RMI, CORBA e DCOM, uma vez, que esses middleware não necessitam utilizar um parsing XML para serializar dados o seu desempenho segundo (Megginson, 2005) pode ser superior Common Object Request Broker Architecture CORBA é uma arquitetura criada pelo OMG (Object Management Group) que permite a comunicação entre aplicações distribuídas independente das plataformas de hardware, software e protocolos de redes. Os objetos CORBA implementam uma interface de definição da linguagem (IDL), e assim, os objetos distribuídos podem ser implementados em qualquer linguagem de programação. Os clientes, então, a partir da IDL requisita os métodos por meio de RMI. Segundo (Orfati & Harkey, 1997) no modelo de programação CORBA os clientes não precisam ser necessariamente objetos, estes, podem ser qualquer programa que envie mensagens para objetos remotos e que possam receber respostas. A Figura 15 ilustra os principais componentes do middleware CORBA. Figura 15 - Componentes middleware CORBA Fonte: (Orfati & Harkey, 1997) ORB-Core: tem como principal objetivo auxiliar o cliente a invocar o método requisitado, assim, recebe informações do cliente e repassa ao servidor. Adaptador de Objetos: Registra as classes servidoras no repositório de implementação objetivando realizar instância de objetos em tempo de execução levando-se em consideração a demanda de clientes. O adaptador de objetos, por fim, gera e gerencia as referências aos objetos realizando a ligação entre os objetos CORBA e IDL.

51 51 Skeleton: São classes geradas pelo compilador IDL na linguagem de programação do servidor, assim, cada invocação remota deve ser encaminha através do skeleton apropriado a cada objeto servidor em particular. Proxys/Stubs: São classes na linguagem de programação do cliente fornecidas pelo compilador IDL que recebem as invocações remotas oriundas dos clientes. Repositório de implementação: Pode ser descrito como um repositório em tempo de execução para todas as classes e instâncias de objetos que são suportadas pelo servidor. Repositório de interface: Repositório que fornece informações sobre as IDL registradas para os clientes e servidores. O funcionamento do CORBA consiste em traduzir uma linguagem declarativa a partir da IDL gerando Stubs e Skeletons em uma linguagem intermediária, assim, cliente e servidor podem comunicar-se através da linguagem intermediária resultante JAVA RMI JAVA RMI é um middleware disponibilizado pela Sun Microsystem que estende o modelo de programação JAVA para implementação de sistemas distribuídos disponibilizando objetos que podem invocar métodos remotos usando a mesma sintaxe da invocação local (Coulouris, 2005). As aplicações distribuídas em JAVA RMI inicialmente devem possuir uma classe denominada interface listando todos os métodos que poderão ser invocados remotamente. Ao compilar uma interface serão gerados stubs e skletons, ou seja, referências do objeto que serão utilizadas para invocar métodos remotos no cliente e/ou servidor. As referência dos objetos são armazenadas no formato URL (Universal Resource Locator) em um servidor de nomes denominado RMIregistry, assim, a URL contém as referências remotas (EndereçoServidor:Porta/NomeObjeto, onde NomeObjeto é uma instância do objeto remoto) que serão utilizadas pelos clientes. A Figura 16 ilustra o funcionamento de JAVA RMI.

52 52 Figura 16 - Funcionamento JAVA RMI Fonte: (Argonavis, 2004) Com base na Figura 16 pode-se descrever o funcionamento de JAVA RMI em uma seqüência de seis passos, onde: 1. O programador deve definir a classe de interface onde será listado todos os métodos que poderão ser requisitados remotamente. Essa classe estende o pacote JAVA RMI (remote) disponibilizado pela Sun Microsystem. 2. Os métodos definidos na interface devem ser implementados, para tanto esses devem ser uma extensão do pacote JAVA RMI (UnicastRemoteObject) e serem na seqüência uma implementação dos métodos descritos na interface. A classe que implementa a interface seria Class MensagemImpl extends UnicastRemoteObject implements Mensagem e essa deve ser submetida ao compilador JAVA. 3. A classe de implementação (MensagemImpl) deve ser submetida ao compilador RMIC (RMI compiler) que irar gerar stubs e skeletons (referências para cada objeto ) 4. A classe Servidora deve ser escrita, contudo, o objeto (instância da classe de implementação) deve ser registrado no servidor de nome (RMIregistry) para ser recuperado posteriormente pelos clientes. Namig.bind (instância do objeto, nomeobjeto )

53 53 5. Ao escrever a classe cliente um objeto do tipo interface (instância da classe interface) faz uma requisição do objeto remoto a partir do servidor de nomes Namig.lookup( nomeobjeto ), dessa maneira, um objeto remoto pode ser acessado. 6. Ambas as classes clientes e servidor são submetidos ao compilador Java, e assim, utilizando o JAVA JRMP (JAVA Remote Method Protocol) os stubs clientes acessam independentemente de plataforma e protocolos de rede o objeto remoto contido no servidor. JAVA RMI estende todas as funcionalidade da linguagem de programação JAVA, assim, proporciona a implementação de sistemas totalmente orientados a objetos. Nessa dinâmica, apresenta-se simplista quando comparada ao CORBA, visto que, nesse último middleware uma enorme quantidade de parâmetros deve ser configurada antes que seja possível estabelecer conexão com os objetos remotos. Segundo (Candeia & Brusso, 2003) JAVA RMI possui desempenho superior ao CORBA (JAVA IDL) 12, uma vez que não utiliza inúmeras linguagens não necessita de uma IDL para tradução das linguagens declarativas de cliente e servidor. Para mais informações sobre desempenho de tecnologias distribuídas consulte (Candeia & Brusso, 2003). Quando comparada ao DCOM JAVA RMI apresenta superioridade, pois é portável, e assim, não restringe sua utilização a poucos sistemas operacionais, todavia, é importante ressaltar que DCOM é um middleware proprietário da Microsoft e que este não possui implementação para as arquiteturas Linux/Unix, diferente de JAVA RMI. Em relação à web services JAVA RMI proporciona total interação em um ambiente web, pois pode facilmente integrar-se a applets 13 manipulando objetos remotamente sem a necessidade de um parsing XML para realizar a serialização dos dados retornados. Por todas essas razões e por ser uma linguagem em constante evolução, comercialmente atrativa e por oferecer por intermédio da Sun Microsystem uma extensa API (Application Program Interface), ou seja, um conjunto de rotinas, protocolos e ferramentas para a construção de aplicativos de software; JAVA RMI será o middleware utilizado para a implementação da presente proposta. 12 JAVA IDL é a tecnologia JAVA para objetos distribuídos baseados na arquitetura CORBA. 13 Programas JAVA que podem ser incorporados a documentos HTML (Hypertext Markup Language). Quando um navegador executa uma página web contendo um applet este é baixado e executado na máquina cliente (Deitel & Deitel, 2006). Para maiores informações consulte (Deitel & Deitel, 2006) e (Horstmann & Cornell, 2002).

54 Considerações do capítulo Utilizando as técnicas de sistemas distribuídos é possível criar e gerenciar um ambiente de banco de dados distribuídos. A utilização de um modelo de programação orientado a objetos e baseado em objetos remotos torna possível a integração de vários fragmentos de banco de dados distribuídos. A constante utilização de sistema distribuídos para resolver problemas nas mais variadas esferas do conhecimento proporcionou o surgimento de inúmeros middleware que possibilitam construir sistemas distribuídos sobre arquiteturas diversas de hardware, software, redes de computadores e até mesmo sobre sistemas operacionais distintos. Middlewares como CORBA, DCOM, Web Services e JAVA RMI propiciam uma comunicação transparente entre objetos remotos, e assim, mascaram as heterogeneidades entre os componentes distribuídos. O desafio de heterogeneidade da presente proposta, assim, limita-se a mascarar as especificidades de SQL existente entre os sistemas de banco de dados utilizados. Diante da diversidade de tecnologias para a construção de sistemas distribuídos cabe ao programador/analista escolher uma arquitetura de middleware que adapte-se melhor ao seu projeto. Por inúmeras facilidades descritas na seção do presente trabalho, JAVA RMI foi o middleware escolhido para a implementação da presente proposta. Para entender as relações entre as partes que compõem um sistema distribuído juntamente com a redução de custo para que se tenha uma implementação fácil de gerenciar e confiável, a presente proposta irá utilizar o modelo arquitetural cliente/servidor. Nesse modelo, os objetos remotos interagem a partir da requisição/solicitação de serviços, assim, o conteúdo de relações serão solicitadas remotamente.

55 55 4 PUZZLE DATABASE O presente capítulo tem por finalidade descrever e apresentar o puzzle Database, uma proposta de middleware para a distribuição de banco de dados que será estruturado sobre uma rede de computadores. O trabalho, assim, apresenta a principal motivação para a distribuição de banco de dados. 4.1 Contexto do trabalho No cenário atual, as corporações e organizações apresentam-se distribuídas em vários setores e/ou departamentos, entretanto, na maioria dos casos o perfil distribuído das mesmas não é aplicado à base de dados. É comum centralizar em uma única base de dados todo o conteúdo da organização. O acesso aos dados, portanto, ocorre a partir de uma instância do usuário que coleta informações no banco de dados requisitado. Tal ambiente, entretanto, apresenta problemas de disponibilidade, visto que, se o nó de rede (que possui o banco de dados) falhar todo o sistema ficará indisponível, situação ilustrada na Figura 17. Figura 17 - Indisponibilidade do sistema Com base na Figura 17 é possível perceber que todas as requisições/solicitações de dados são encaminhadas ao nó da rede 1. Este nó agrupa todas as informações de uma organização/corporação distribuída. Uma indisponibilidade desse nó no instante t (ilustrada na Figura 17) resulta em uma completa indisponibilidade do sistema. Observando esse cenário, pode-se concluir que um ambiente de banco de dados centralizado pode apresentar-se ineficiente para organizações/corporações distribuídas, assim, é proposta uma arquitetura de

56 middleware para distribuição de banco de dados, utilizando os modelos de programação e arquiteturas de middleware oriundos de sistemas distribuídos Arquitetura do Puzzle Database Middleware na computação distribuída pode ser descrito como uma camada em nível de software que tem por finalidade mascarar, ocultar do programador e/ou aplicativo especificidades de comunicação, protocolos de rede e dependência de sistemas operacionais. Uma camada em nível de software, nessa dinâmica, tem como objetivo final proporcionar a projetistas e desenvolvedores um modelo produtivo para a construção de aplicativos e/ou sistemas relacionados à computação distribuída. Um middleware, nesse contexto, é composto por um conjunto de objetos que podem estar subdivididos através de uma rede de computadores. Contudo, deve existir interação entre os objetos e esses devem comunicar-se a fim de compartilhar determinados recursos. Na presente proposta, o puzzle database, é formalizado como uma camada de software que visa simplificar o desenvolvimento de banco de dados distribuídos, tal camada irá interagir banco de dados homogêneos ou heterogêneos criando um ambiente de bases de dados distribuídas. A fim de ocultar do programador todas as dependências relacionadas a plataformas, o puzzle Database será posicionado sobre o middleware RMI que permite comunicação transparente entre as diversas plataformas existentes. A Figura 18 estrutura em camadas o posicionamento do puzzle database. Figura 18 Arquitetura de camadas, puzzle database onde: A arquitetura do puzzle database, pode ser descrita em uma seqüência de 5 passos

57 57 1. A aplicação faz uma requisição à base de dados, assim, se a base existir localmente ela é acessada sem a necessidade de utilizar invocação remota de métodos. O puzzle database é estrategicamente posicionando sobre o middleware RMI configurando uma arquitetura para a construção de sistemas distribuídos em formato de L, essa reconfiguração da arquitetura distribuída permite a projetistas e programadores utilizarem RMI diretamente vinculando o puzzle database somente à distribuição de banco de dados. 2. A base de dados, entretanto, pode estar posicionada remotamente, dessa maneira, o puzzle database irá utilizar a invocação remota de métodos através de RMI. 3. Uma vez que RMI permite a invocação transparente de métodos mascarar a heterogeneidade de plataformas fica sobre responsabilidade da respectiva invocação. 4. O puzzle database permite transparência de acesso, ou seja, os objetos remotos e locais podem ser acessados através da mesma classe de serviços que irá devolver para a aplicação tuplas retornadas da base de dados. 5. RMI realiza a comunicação e abstração de sistemas operacionais e protocolos de rede durante a invocação remota. O puzzle database através de um arquivo com a extensão xml faz o endereçamento físico de todas as relações do banco de dados distribuído garantindo acesso transparente as bases de dados fragmentadas. Conhecidas as relações a interoperabilidade de SQL configura um cenário típico de um ambiente heterogêneo de banco de dados distribuídos, assim, cada base de dados apresenta sintaxe própria para a requisição de tuplas. A adequação do SQL é realizada através do puzzle SQL um núcleo que baseia-se no endereço físico da base e no drive do banco de dados. Por fim a puzzle database utiliza o modelo de programação distribuída para acessar remotamente bases de dados que estão dispostas sobre uma rede de computadores. A Figura 19 ilustra a arquitetura do middleware proposto. Figura 19 interoperabilidade de SQL

58 58 Na Figura 19, o puzzle database receberá uma requisição SQL, em seguida essa será submetida ao parser 14 puzzle SQL. Uma vez que podem existir bancos de dados heterogêneos o puzzle SQL tem por função mapear todas as interoperabilidades de SQL existentes e assim, permitir que as chamadas SQL estejam adequadas a base onde será executada. A comunicação entre a aplicação e o puzzle database será realizada de maneira transparente, nesse contexto, não será necessário ao programador alterar ou reimplementar sua aplicação. Objetivando validar a proposta do puzzle database, a seção implementação descreve as estratégias adotadas para sua implementação. 4.3 Implementação do Puzzle Database O puzzle database possui um núcleo central denominado de puzzle distributed que inter-relaciona várias bases de dados através de uma camada de software posicionada sobre o nó da rede que possui a base de dados. O inter-relacionamento lógico dos dados, nesse contexto, é realizado através da chamada remota de métodos. Os objetos remotos, assim, irão interagir entre si e com a base de dados local transformando as várias bases em uma única base de dados distribuída. Os objetos remotos do puzzle distributed, nesse contexto, terão conhecimento de todas as relações e endereçamento físico existentes no banco de dados distribuído. Assim, uma vez que a aplicação requisitar tuplas, se essas não estiverem presentes localmente, o puzzle distributed irá estabelecer uma relação de cliente/servidor com o objeto remoto e esse com a base de dados que possui os dados, e assim, ira requisitá-los para a aplicação. A Figura 20 ilustra a requisição de tuplas remotamente com heterogeneidade de SQL. Figura 20 puzzle distributed/puzzle SQL 14 Em ciência da computação parser (também conhecido como análise sintática) consiste em realizar a análise de uma entrada determinando sua estrutura gramatical segundo uma gramática formal.

59 59 Na Figura 20 a aplicação irá comunicar-se diretamente com o puzzle database e esse fará a comunicação lógica com a base de dados solicitada. Uma vez que as bases podem ser heterogêneas existirá heterogeneidade de SQL, sendo responsabilidade do puzzle SQL adaptar a sintaxe SQL de acordo com a base solicitada. A base de dados, contudo, pode estar posicionada remotamente (ilustrado na Figura 20), assim, cada objeto remoto irá conhecer todas as relações do banco de dados distribuído juntamente com sua localização física observe a Figura 21. Figura 21 - Relações banco de dados distribuído Visto que cada objeto conhece as respectivas relações e endereçamento físico das mesmas a comunicação será realizada de maneira transparente, para tanto será utilizada a tecnologia JAVA RMI que permite a comunicação transparente a partir do protocolo de rede JRMP (JAVA Remote Method Protocol). Figura 22 - Protocolo JRMP Na Figura 22 o programa servidor utiliza método (bind()) para registrar no serviço de nomes do JAVA RMI (RMIRegistry) os objetos a serem recuperados remotamente, para tanto, o nome (referência ao objeto) deve ser único. O cliente obtém o método remoto através do método (lookup()) que irá especificar o nome do servidor. Por fim a comunicação entre cliente e servidor é realizada de maneira transparente utilizando o protocolo JRMP. A Figura 23 ilustra a arquitetura da presente proposta.

60 60 Figura 23 - Middleware para a distribuição de banco de dados A Figura 23 apresenta a arquitetura final para construção do puzzle database para distribuição de banco de dados. É possível perceber nesta figura que a integração de vários fragmentos de dados será realizada a partir das técnicas de sistemas distribuídos 15, assim, o ambiente final do banco de dados distribuídos será capaz de integrar as diversas relações como sendo uma única base. Diante de bases de dados integradas, as organizações e/ou corporações poderão explorar o seu ambiente distribuído registrando na sua base local apenas as informações referente à sua atuação. Entretanto, como a arquitetura final é distribuída relações poderão ser recuperadas e/ou manipuladas remotamente Estudo de caso Com o objetivo de validar o puzzle database será implementado um protótipo que pretende distribuir a base de dados do sistema acadêmico da Universidade do Estado de Santa Catarina (UDESC). No cenário atual todas as informações referentes aos alunos, professores e funcionários são centralizadas em um único centro acadêmico, Centro de ciências AgroVeterinárias (CAV). A UDESC, entretanto, apresenta-se como uma instituição multicampi e possui centros espalhados por todo o estado de Santa Catarina, observe a Tabela 6. Sigla Centro Acadêmico Cidade CCT Centro de Ciências Tecnológicas Joinville CAV Centro de Ciências Agroveterinárias Lages ESAG Centro de Administração Florianópolis CEFID Centro de Educação Física, Fisioterapia e Desportos Florianópolis FAED Centro de Ciências da Educação Florianópolis CEO Centro Educacional do Oeste Chapecó, Palmitos, 15 Invocação remota de métodos

61 61 Pinhalzinho CEAD Centro de Educação a Distância - CEPLAN Centro de Ensino do Planalto Norte São Bento do Sul CEAVE Centro do Alto Vale do Estado Ibirama Tabela 6 - Centros acadêmicos da UDESC Esse modelo de armazenamento de dados centralizados, ilustrado na Figura 24, não vai de encontro com a proposta de descentralização da universidade, que busca, através de seus campi espalhados pelo estado atender as necessidades e especificidades de cada região. Figura 24 - Centralização de dados sistema acadêmico UDESC Observe na Figura 24 que todos os dados são obrigatoriamente requisitados do centro de ciências agroveterinárias, (CAV). Nesse modelo, uma simples indisponibilidade do mesmo resulta na total paralisação do sistema acadêmico da Universidade do Estado de Santa Catarina. O atual sistema acadêmico, assim, pode ser descrito como uma solução ineficiente perante a proposta de distribuição da UDESC. Para aumentar a disponibilidade dos dados é proposto um banco de dados distribuído com fragmentação horizontal primária da atual base de dados em várias bases que serão posicionadas junto a cada centro acadêmico. Dessa maneira, a falha em um único centro acadêmico não resulta em total indisponibilidade do sistema e as informações poderão ser recuperadas levando-se em consideração o centro acadêmico a qual pertence. A Figura 25 ilustra o ambiente de banco de dados distribuído proposto.

62 62 Figura 25 - Banco de dados distribuído Observe na Figura 25 que o banco de dados está distribuído e fragmentado de acordo com as informações de cada centro, entretanto, o puzzle database irá permitir a recuperação de informações remotas. Um professor a partir do CCT pode recuperar informações do ESAG. Tal procedimento é possível graças às técnicas de sistemas distribuídos apresentadas na seção 3 do presente trabalho. Faz-se necessário reafirmar que no estudo de caso não será reimplementado todo o sistema acadêmico da UDESC, mas sim, serão simulados sistema acadêmico e alguns centros para validação da proposta Plataforma JAVA A plataforma JAVA é uma ambiente computacional desenvolvido pela Sun Microsystem no início da década de 90. A grande vantagem dessa plataforma é permitir o desenvolvimento de aplicativos e/ou sistemas distribuídos em um ambiente heterogêneo, ou seja, independe de sistemas operacionais, hardware e software. Para mascarar as heterogeneidades os programas escritos em JAVA são compilados para uma linguagem independente de plataforma denominada bytecodes. Os bytecodes são então interpretados pela JVM (JAVA Virtual Machine) e traduzidos em tempo de execução para instruções nativas do processador. A Figura 26 ilustra o ambiente de execução/compilação de um programa JAVA.

63 63 Figura 26 - Compilação/Execução JAVA Na Figura 26 depois de escrito o programa em código JAVA (arquivo.java) esse é compilado/traduzindo para uma linguagem intermediária denominada bytecode que possui a extensão.class (arquivo.class). O arquivo.class é então interpretado em qualquer uma das arquiteturas que tenham implementadas a máquina virtual JAVA. Uma vez que existe uma tradução/interpretação de código a cada execução do sistema, poder-se-ia dizer que JAVA sempre será mais lenta que as linguagens que geram código nativo do sistema operacional como C, C++. No ano de 1996, entretanto, foi desenvolvido pela Sun Microsystem um compilador Just-in-time (JIT) que dinamicamente analisa o código JAVA retirando trechos desnecessários e conseqüentemente melhora o desempenho de execução dos programas. Segundo a Sun Microsystem a compilação dinâmica JIT torna a execução de programas JAVA mais rápida. Por ser uma plataforma concebida para ser portável apresentando um middleware JAVA RMI para construção de sistemas distribuídos e por estar em constante evolução (JPU 16 ), JAVA é a linguagem utilizada para a construção do puzzle database. 4.4 Considerações do capítulo Bancos de dados distribuídos são de extrema importância no cenário atual, contudo, a sua implementação envolve o estudo e aplicação de modelos de programação pertinentes a sistemas distribuídos. Questões como a simples escolha de um modelo arquitetural de sistemas distribuídos pode influenciar diretamente no desempenho do banco de dados 16 JAVA Process Unit (JPU), projeto da Sun Microsystem que objetiva criar um acelerador a nível de hardware para otimizar e proporcionar mais velocidade a execução de programas JAVA. Para mais informações consulte

64 64 distribuído. Diante desse cenário, muitas corporações por falta de conhecimento técnico científico acabam por centralizar os dados sobre uma única base. Todavia as pequenas e médias corporações e/ou organizações governamentais acabam frustrando tentativas de distribuição e muitas vezes esbarram nos altos valores comerciais de soluções proprietárias que realizam a distribuição. Com o intuito de promover a distribuição de dados a partir de ferramentas e sistemas gerenciadores de banco de dados gratuitos a presente proposta elaborou uma arquitetura de middleware, ou seja, uma camada em nível de software que utilizando bases de dados opensource e um modelo de programação oriundo de sistemas distribuídos promove a distribuição (fragmentação) de bancos de dados. Objetivando entender as relações entre os fragmentos que compõem um sistema de banco de dados distribuído juntamente com a redução de custo das transações do tipo leitura e escrita os fragmentos são posicionados junto ao departamento e/ou setor que faz uso dessas informações, e assim, o acesso ocorre de maneira transparente ao usuário e/ou aplicação que utilize o sistema. Por fim, a presente proposta de middleware poderá ser obtida gratuitamente junto ao GRADIS, no departamento de ciência da computação da Universidade do Estado de Santa Catarina e/ou sourceforge (https://sourceforge.net/projects/puzzledatabase/).

65 65 5 O PROTÓTIPO PUZZLE DATABASE Após o entendimento dos conceitos básicos referentes a banco de dados distribuídos e a sistemas distribuídos, esse capítulo tem por finalidade descrever em uma seqüência lógica a utilização e configuração do puzzle database. O diagrama de estados em anexo, apresenta os estados do puzzle database, e suas respectivas precondições para alcançar as etapas seguintes durante a execução do middleware. O programador e/ou projetista não necessitará reimplementar sua aplicação, entretanto, faz-se necessário apenas gerar o JAR da respectiva aplicação que irá utilizar banco de dados distribuídos. O puzzle database consiste em um middleware para distribuição de banco de dados composto por cinco núcleos lógicos, cada núcleo desempenha tarefas especificas para a configuração/distribuição da base de dados e são descritos como: puzzle Distributed, puzzle XML, puzzle SQL, puzzle Compiler e puzzle Properties. O puzzle database possui um diretório denominado lib, esse contém todas as bibliotecas que serão necessárias para a correta execução do middleware, dentre as bibliotecas do puzzle database os conectores de base de dados JAVA devem ser atualizados de acordo com a versão do SGBD. Na atual distribuição o puzzle database utiliza MySQL e PostgreSQL , a atualização dessas bases devem sempre ser feitas com o drive de conexão JAVA garantindo assim a integridade do middleware. 5.1 Puzzle XML A transparência do puzzle database é assegurada através do endereçamento lógico das relações fragmentadas, assim, para requisitar tuplas nas bases específicas faz-se necessário o mapeamento de todas as relações a partir de um documento XML, desenvolvido com a API JDOM 17. Durante a execução do puzzle database operações de leitura são executas nesse documento, a fim de obter informações sobre a localização da base de dados remota. O diagrama de classe puzzle XML em anexo, de maneira sucinta, apresenta as classes e componentes utilizados durante o processo de confecção de documentos XML no puzzle database. A Figura 27 ilustra a estrutura do documento gerado com o puzzle XML. 17 API JAVA otimizada e de baixo custo utilizada para geração de documentos XML. Utiliza as normas existentes do document obect model para gerar documentos XML bem formados e consistentes. Para maiores informações sobre JDOM consulte:

66 66 Figura 27 - Estrutura puzzle XML As tags do puzzle XML são de preenchimento obrigatório e incluem as relações de um determinado host. Ao executar um determinado SQL é possível identificar com precisão o seu host e seus respectivos SGBD s. O puzzle XML possui uma interface simples e interativa que facilita e automatiza o desenvolvimento do XML de configuração do puzzle database. Figura 28 - Interface puzzle XML Pode-se gerar um único documento XML com todas as informações necessárias para a distribuição, após a configuração do host todas as suas relações podem ser inseridas e caso necessite inserir ou remover novos host s e/ou relações pode-se utilizar os botões posicionados na parte direita da interface (Figura 28). O XML de configuração é de vital

67 67 importância para o correto funcionamento do puzzle database, portanto, o programador/projetista do banco de dados distribuído pode selecionar o diretório desejado para armazenar o documento. Ao iniciar o puzzle database, um diretório temporário é gerado tendo como base as configurações temporárias do usuário que está com a sessão do sistema operacional ativa. Em tempo de execução um arquivo de extensão XML denominado puzzle properties captura o endereço do XML de configuração e armazena- o no diretório temporário puzzle database. Quando a aplicação solicita uma execução remota de SQL o puzzle database procura no seu diretório temporário pelo puzzle properties, e nesse documento, encontra a destinação final do arquivo de configuração do puzzle database. A Figura 29 ilustra a estrutura do arquivo de propriedades do puzzle database. Figura 29 - Estrutura puzzle properties O puzzle properties constrói as instâncias XML a partir do modelo de DTD 18 properties disponibilizado pela Sun Microsystem, nesse modelo, os atributos são bem estruturados formatados na seqüência chave valor, tornando-se auto-descritivo, pois mescla o conteúdo das tags com os dados. Esse modelo facilita a validação das informações, uma vez que, as aplicações JAVA possuem a instrução Properties.loadFromXML, um método que valida os dados que serão manipulado através da classe Properties. O puzzle properties possui quatro chaves. PathXml armazena o endereço físico absoluto do XML de distribuição do puzzle database, atributo obrigatório do puzzle properties que tem sua chave inserida no momento que o puzzle XML grava em disco o XML definido pelo programador/projetista, essa chave pode ser alterada pela tela de configuração do puzzle database. Main, atributo opcional responsável por armazenar a classe principal do programada que será distribuído a partir do puzzle database. JAR, nome do aplicativo que será distribuído. JVMCompiler versão da JDK que será utilizado para re-compilar a classe de conexão com banco de dados do aplicativo a ser distribuído, caso essa chave não seja definida o puzzle compiler utiliza a última versão do Java virtual machine instalada no computador. 18 Definição do tipo de documento. Para maiores informações consulte a documentação da w3c disponível em

68 Puzzle Compiler Compilador do puzzle database responsável por re-compilar a aplicação utilizando o modelo de compilação JAVA RMI, nesse modelo, os métodos são alterados recebendo referências para chamadas remotas. O puzzle compiler altera os bytecodes do aplicativo, sem alterar, contudo, o modelo de dados que os métodos locais manipulavam. Utilizando técnicas de polimorfismo, a integridade nominal dos métodos é mantida, sendo a compilação transparente ao programador. A compilação puzzle segue o modelo JIT (Just in time), assim, a compilação pode ser procedida com o puzzle database em execução. O puzzle compiler ao ser executado importa na classe o puzzle distributed, utilizando a sintaxe JAVA import.org.udesc.puzzledistributed; em seguida as referências locais de acesso a base são substituídas pelo kernel puzzle distributed. Comparando as Figuras 30 e 31, é possível visualizar as alterações realizadas pelo puzzle compiler para substituir referências. public ResultSet Alunos() {... try { ResultSetC = stmt.executequery(("select * FROM ALUNOS")); } catch ( Exception e ) {e.printstacktrace();} } return ResultSetC; Figura 30 - Referência Local import org.udesc.puzzledatabase.puzzledistributed;... PuzzleDistributed Distributed = new PuzzleDistributed(); public ResultSet Alunos() {... 3 try { ResultSetC = Distributed.executeQuery(("SELECT * FROM ALUNOS")); } catch ( Exception e ) {e.printstacktrace();} } return ResultSetC; Figura 31- Referência Remota O núcleo de distribuição do puzzle database é carregado na classe (1), ao inserir esse módulo todos os métodos public 19 do puzzle distributed são disponibilizados ao programador, Modificador de acesso JAVA. Um método com essa definição pode ser acessado por qualquer classe.

69 inevitavelmente, os métodos só poderão ser acessados através de um objeto, ou seja, uma instância da classe distributed (2) que por sua vez é uma subclasse 20 do pacote JAVA RMI. O objeto distributed (3) executa um método nativo do objeto Statement 21 (executequery), mas que será referenciado remotamente através do kernel de distribuição. O puzzle distributed deve então encaminhar a instrução SQL SELECT * FROM ALUNOS ao objeto remoto contido em um host que faz parte do sistema de banco de dados distribuídos, modificando assim, os bytecodes e todo o sistema de referência local. 5.3 Puzzle Distributed É o kernel central do puzzle database que utiliza o middleware RMI para integrar todo o sistema de banco de dados distribuídos; integra em seu núcleo métodos e especificações do puzzle XML para criar e gerenciar objetos remotos que são registrados no servidor de nomes puzzle name. O puzzle distributed é estruturado em um conjunto de quatro classes definidas hierarquicamente a partir da classe remote, package java.rmi.*. A comunicação entre os objetos do kernel distributed é realizada através da passagem de mensagem serializável, ou seja, objetos complexos (estruturas, classes e instância de objetos) são codificados em bits, para serem trafegados na rede. As referências remotas dos métodos executequery e executeupdate disponibilizam respectivamente à aplicação objetos da classe java.resultset e java.int, assim, o puzzle database assegura que os objetos manipulados pela aplicação sempre terão como superclasse objetos JAVA. Embora a aplicação esteja acessando métodos remotos, o tipo de informação resultante não é modificado, tal característica assegura a transparência dos objetos manipulados pelo puzzle database, conseqüentemente, a execução de métodos seqüenciais ou distribuídos manipulam a mesma classe de objetos. O diagrama de classe do puzzle distributed em anexo, apresenta ao programador/projetista de sistemas distribuídos a estruturação lógica das classes e objetos manipulados durante a execução do puzzle database. 5.4 Puzzle SQL Kernel integrado ao puzzle distributed responsável por promover a interoperabilidade da sintaxe SQL. Ao receber uma string, o puzzle SQL realiza uma análise léxica da instrução mapeando as possíveis heterogeneidades, múltiplos SQL são oriundos dessa etapa, pois, Extensão de classe superior chamada de classe pai. 21 Segundo a Sun Microsystem Statement é o objeto usado para executar um comando SQL estático e retornar os resultados que produz. Para maiores informações consulte a API JAVA disponível em:

70 70 estarão em conformidade com as bases onde serão executados. Durante a análise léxica todas as relações são redirecionadas ao puzzle distributed que irá solicitar ao puzzle XML o mapeamento lógico dessas relações, e então, submeter ao host específico o SQL a ser executado. O diagrama de classe puzzle SQL em anexo ilustra a iteração com o kernel de distribuição do puzzle database. 5.5 Integração dos núcleos no Puzzle Database Os núcleos do puzzle database são integrados a partir do puzzle distributed durante a execução da aplicação que utiliza o sistema de banco de dados distribuídos, Figura 32. Figura 32 - Integração Núcleos Puzzle Database 1- Aplicação deve ser compilada com o puzzle compiler, alterando, assim, as referências do método executequery. A compilação altera automaticamente os bytescodes da classe, contudo, o JAR da aplicação deverá ser gerado novamente. 2- A aplicação invoca o método executequery, presente no kernel distributed. O SQL recebido é submetido à análise léxica (puzzle SQL), entretanto, o SQL deve estar adequado a base de execução (MySQL ou PostgreSQL). 3- Os bytecodes da classe de conexão da aplicação possuem como referência o objeto distributed e não mais o objeto stament nativo da programação JAVA. 4- O puzzle distributed verifica o caminho do XML gerado, dessa maneira é possível obter o endereçamento físico das relações. 5- Após obter informações do servidor de dados o puzzle distributed conecta-se ao objeto remoto, utilizando as informações do documento XML de distribuição. O objeto remoto executa a instrução SQL na base de dados.

71 71 6- O objeto remoto devolve o resultado do SQL ao puzzle distributed que retorna para a aplicação as tuplas resultantes da instrução SQL. 5.6 Análise de Desempenho do Puzzle Database A análise de desempenho teve por finalidade comparar o desempenho de um sistema de banco de dados distribuídos desenvolvido a partir do puzzle database e um sistema de acesso seqüencial a base de dados. Oportunamente essa análise é realizada em conjunto com o estudo de caso descrito na seção do presente trabalho. O ambiente de testes é descrito como um ambiente limpo, ou seja, somente os processos relacionados ao sistema de banco de dados distribuídos juntamente com os processos essenciais ao sistema operacional estavam ativos Metodologia da análise de desempenho Segundo (Bussab & Morettin, 2004) repetidas mensurações executas em aparelhos equilibrados tendem a apresentar resultados variados, pois um conjunto de valores oscilam de maneira simétrica próximo ao verdadeiro valor. Em trabalhos sobre erros de observações astronômicas Gauss 22 deduziu matematicamente tal comportamento intitulando-o de lei normal dos erros, também designada como distribuição normal 23. Em virtude das descobertas de Gauss, matemáticos e físicos acreditavam que todos os fenômenos da vida poderiam ser ajustados simetricamente, não ocorrendo tal simetria, suspeitava-se do processo de coleta das informações. Embora não exista uma curva universal que descreva a realidade, o modelo de distribuição normal segundo (Bussab & Morettin, 2004) pode ser descrito como o mais importante método estatístico, e assim, será utilizado como metodologia de análise do puzzle database. Os primeiros testes do puzzle database apresentaram a variância descrita por (Bussab & Morettin, 2004), visando solucionar tal discrepância foi definido um grau de confiança de 90%, assim, é possível segundo (Silva, 1998) determinar o tamanho mínimo da amostra para que os resultados da pesquisa sejam considerados válidos. Uma estimativa confiável pode ser obtida através da média populacional descrita pela fórmula. 22 Johann Carl Friedrich Gauss, Matemático, Físico e Astrônomo Alemão, considerado por muitos o maior gênio da história da matemática. 23 (Bussab & Morettin, 2004) descreve a distribuição normal como um modelo fundamental de probabilidades e inferências estatísticas. Para mais informações consulte Estatística Básica (Bussab & Morettin, 2004) páginas 175 à 180

72 72 Figura 33- Tamanho da Amostra Fonte: (Silva, 1998) Na Figura 33, o define o tamanho mínimo da amostra utilizada. Representa o valor critico, ou seja, a correspondência do grau de confiança desejável, segundo (Bussab & Morettin, 2004) o grau de confiança permite julgar qual a possível magnitude do erro cometido. O desvio padrão, ou seja, a dispersão estatística 24 é descrita por. A diferença máxima entre a média amostral ( ) e a verdadeira média populacional ( ) é representada por. O valor máximo aceito como erro ( ) está diretamente conectado ao grau de confiança definido, observe a Figura 34. Grau de Confiança Valor Crítico - 90% 0,10 1,645 95% 0,05 1,96 99% 0,01 2,575 Figura 34 - Valores Críticos Associados ao Tamanho de Amostra Fonte: (Bussab & Morettin, 2004) Com base na Figura 34 é possível definir os valores das incógnitas utilizadas no cálculo do tamanho da amostra. O grau de confiança definido foi 90%, logo o valor crítico é portanto = 1,645. Para obter o erro máximo de estimativa, basta substituir, assim,. O desvio padrão, entretanto, não é conhecido. (Silva, 1998) Sugere a utilização de estimativas encontradas em trabalhos anteriores, contudo, no referencial teórico não foram encontrados trabalhos com os mesmos objetivos e características, assim, não existem valores antecipados que podem ser usados como base de informações. (Bussab & Morettin, 2004) Descreve o cálculo da amplitude como uma técnica estatística confiável capaz de substituir o desvio padrão, nesse modelo, o pesquisador deve utilizar valores hipotéticos para calcular a variância máxima entre o pior e o melhor valor esperado. A Figura 35 ilustra tal equação. Figura 35 - Cálculo da Amplitude Fonte: Adaptado de (Bussab & Morettin, 2004) 24 Medida da variância dos valores quando se substitui cada iteração calculada pela média.

73 73 O melhor resultado esperado para o puzzle database seria a execução de transações de leitura e escrita em um intervalo de tempo t = 0 onde não existiria delay durante a requisição de informações nas bases de dados distribuídas, entretanto, foi definido t = 18 como o pior resultado esperado, pois o acesso as bases de dados teriam 18 minutos como tempo médio. Logo conclui-se. A Figura 36 Ilustra o tamanho final da amostra utilizada no puzzle database. Figura 36 - Amostra Final Uma amostra de 676 elementos implica que cada ponto plotado no gráfico será composto por uma interpolação média de 676 execuções no banco de dados utilizando a mesma quantidade de bytes. A Figura 37 apresenta uma motivação para entendimento à interpolação média. N Bytes Tempo (s) N=1 65,8 bytes 0,015 s N=2 65,8 bytes 0,008 s N=3 65,8 bytes 0,040 s... 65,8 bytes... N=676 65,8 bytes 0,09 s 65,8 bytes Demorou em média 0,002 s Figura 37 - Média de Acessos puzzle Database Estrutura Física da análise de desempenho Foram utilizados três computadores com unidade central de processamento Pentium IV com freqüência de 2.4 Ghz e 1 GB de memória primária (RAM), sendo dois módulos de 512 MB e freqüência de 400 Mhz. Os módulos de memória estavam com a opção dual channel habilitados. Ambos os computadores possuíam placa-mãe Intel modelo PERL865. O sistema operacional utilizado foi o Microsoft Windows XP Service Pack 2. Uma rede fast ethernet de 100 Mbits com cabeamento estruturado de par traçado com conectores RJ45 foi utilizado para interligar os computadores descritos. Na análise de desempenho, a porta de comunicação estava habilitada exclusivamente ao puzzle database,contudo, caso seja utilizando um firewall 25 para monitorar 25 Um firewall é um dispositivo ou software que monitora o fluxo de dados entre um computador e outro dentro de uma rede. (MOHAY, 2003)

74 o tráfego entre redes e/ou subredes essa porta de comunicação deve estar liberada para tráfego de dados TCP SGBD s da análise de desempenho Foram utilizados os sistemas gerenciadores de banco de dados MySQL e postgresql com versões respectivamente descritas como e , o número de registros foi o mesmo para os SGBD s. O plano de execução do SQL em ambas as bases foram mantidos como padrão, nenhum estatística de dados foi calculada, não sendo utilizada nenhuma outra técnica que possibilite alteração de desempenho durante o acessos a bases de dados, por fim, o puzzle database tinha acesso à todas as relações armazenadas nos SGBD s. Dois computadores, hipoteticamente, descritos como host 01 e host 02 (Figura 38) foram servidores das bases de dados Figura 38 - Ambiente de Testes Nesses host s o puzzle database foi executado estando pronto para receber requisições remotas de SQL. O host 01 recebeu a base de dados denominada CCT e abrigava tuplas referentes aos cursos oferecidos pelo centro de ciências tecnológicas da Universidade do Estado de Santa Catarina. O host 02 abrigava informações do CAV, assim, foi definido: host 01 CCT base de dados postgresql, host 02 CAV base de dados MySQL. No host 03 um protótipo do sistema acadêmico interagia diretamente com puzzle database requisitando informações que estavam distribuídas nos host 01 e Métrica de análise de desempenho A metodologia de desempenho adotada teve como métrica o números de bytes trafegados pela rede em um intervalo de tempo t. Utilizando o método

75 Tempo (S) Tempo (S) 75 System.currentTimeMillis() foi calculado o tempo total de execução dos métodos à base de dados, compreendendo o processo de conexão, desconexão e listagem de resultados na aplicação. O número de bytes foi agrupado de acordo com as tuplas requisitadas, onde uma tupla corresponde à 65,8 bytes. A carga de dados mínima foram 658 bytes, equivalentes a 10 tuplas. A carga de dados máxima representou 1400,05 KiloBytes (aproximadamente 1,36 MegaBytes) resultante da requisição de tuplas de informações. Inicialmente foi estimado o tempo de acesso a bases de dados seqüenciais, um protótipo do sistema acadêmico requisitava informações em um servidor de banco de dados postgresql posicionado remotamente (Gráfico 1). Em anexo encontram-se todas as tabelas de resultados da análise juntamente com os respectivos SQL s. 40,00 35,00 30,00 25,00 20,00 15,00 10,00 5,00 0,00 Acesso Seqüencial PostgreSQL 0,02 3,13 7,90 15,86 23,64 36,73 Dados (KB) Gráfico 1 - Acesso Seqüencial PostgreSQL O SGBD postgresql foi substituído pelo MySQL mantendo-se o mesmo número de registros. Observe o desempenho no Gráfico 2. 40,00 35,00 30,00 25,00 20,00 15,00 10,00 5,00 0,00 Acesso Seqüencial MySQL 0,02 3,13 7,93 15,66 36,01 23,62 Dados (KB) Gráfico 2 - Acesso Seqüencial MySQL

76 Tempo(S) 76 Estima-se um ganho de performance ao utilizar um servidor remoto de banco de dados MySQL (observe gráficos 01 e 02). A variância do tempo máximo de acesso a base de dados PostgreSQL e MySQL é equivalente a 72 centésimos de segundos, acredita-se que nesse intervalo o MySQL poderia listar aproximadamente 500 registros (consulte quadro de desempenho em anexo), assim, no intervalo de tempo t= 36,73 o MySQL seria capaz de acessar aproximadamente tuplas contra do postgresql. O puzzle Database é uma camada em nível de software que processa requisições SQL para criar e gerenciar um ambiente de banco de dados distribuídos. Em um ambiente seqüencial as requisições seguem o fluxo Aplicação Rede de computadores Servidor de dados remoto. O puzzle Database, por sua vez apresenta um ciclo de iteração descrito como: Aplicação puzzle Database Rede de Computadores puzzle Database Servidor de dados. Observando tal ciclo pode-se analisar o desempenho de um acesso seqüencial de requisições SQL que são processadas pelo puzzle Database, e assim, obter o acréscimo de tempo inferido pelo posicionamento de mais uma camada de software que irá abstrair a distribuição de banco de dados. Observe no Gráfico 3 tal acréscimo para o SGBD postgresql. Puzzle Database-PostgreSQL Seqüencial 40,00 35,00 30,00 25,00 20,00 15,00 10,00 5,00 0,00 0,27 3,74 9,13 15,39 37,66 25,37 Dados (KB) Gráfico 3 - Puzzle Database - PostgreSQL Seqüencial Analisando os gráficos 1 e 3, é possível verificar que o desempenho de bases de dados seqüenciais é superior quando comparado ao puzzle database. Na primeira carga de informações o servidor de banco de dados seqüencial postgresql posicionado remotamente demora aproximadamente 0,02 segundos para prover à aplicação 0,64 kbytes, entretanto, o puzzle Database apresenta uma demora de 0,27 segundos. A variância continua ao longo da curva ilustrado nos gráficos (Figura 39).

77 Tempo (S) Variância PostgreSQL- Acesso Seqüencial x puzzle Database seqüencial KiloBytes Acesso Seqüencial (s) Puzzle Database Seqüencial (s) Variância 0,64 0,02 0,27 0, ,11 3,13 3,74 0,61 302,78 7,90 9,13 1,23 605,52 15,86 15,39 0,47 908,23 23,64 25,37 1, ,05 36,73 37,66 0,93 A variância média acesso seqüencial x puzzle Database seqüencial é 0,45 segundos Figura 39 - Variância acesso postgresql É importante observar que a variância não é exponencial e não aumenta na proporção da carga de bytes, uma requisição no intervalo [302,78-605,52] apresentou uma variância de 0,47s apesar da carga de bytes ter sido dobrada nesse mesmo intervalo. O Gráfico 4 analisa o desempenho de requisições seqüenciais submetidas ao puzzle Database com um SGBD MySQL ,00 35,00 30,00 25,00 20,00 15,00 10,00 5,00 0,00 0,25 PuzzleDatabase - MySQL Seqüencial 3,82 8,88 36,27 19,87 13,55 Dados (KB) Gráfico 4 - Puzzle Database MySQL Seqüencial Observando os gráficos 2 e 4 é possível inferir que o acréscimo de tempo na requisição de tuplas independe do SGBD utilizado, contudo, o SGBD MySQL apresenta variância de acesso superior ao postgresql. Variância MySQL- Acesso Seqüencial x puzzle Database seqüencial KiloBytes Acesso Seqüencial (s) Puzzle Database Seqüencial (s) Variância 0,64 0,02 0,25 0, ,11 3,13 3,82 0,69 302,78 7,93 8,88 0,95 605,52 15,66 13,55 (2,11) 908,23 23,62 19,87 3,75

78 Tempo(S) 1400,05 36,01 36,27 0,26 A variância média acesso seqüencial x puzzle Database seqüencial é 0,62 segundos Figura 40 - Variância acesso MySQL Na última análise o puzzle database simulou um ambiente hibrido de bancos de dados distribuídos (Figura 41). As relações alunos e disciplinas foram propositalmente alocadas em host s com endereços físicos distintos. Um protótipo do sistema acadêmico requisitava com uma sintaxe especifica informações referentes aos alunos e determinada disciplina (Todos os alunos do CCT que estão cursando a disciplina TCC-II). 78 PostgreSQL Alunos - CCT 1 Disciplinas - CAV 2 MySQL Alunos - CAV Disciplinas - CCT Protótipo Sistema Acadêmico 3 Figura 41 - Relações Distribuídas A junção das relações fragmentadas é realizada através do puzzle distributed que utiliza-se dos metadados para encontrar chaves primárias e estrangeiras espalhadas em host s do ambiente distribuído. O Gráfico 5 analisa o desempenho desse ambiente distribuído. Puzzle Database 50,00 45,00 40,00 35,00 30,00 25,00 20,00 15,00 10,00 5,00 0,00 1,55 43,55 28,22 19,38 11,02 Dados (KB) Gráfico 5 - Puzzle Database

79 Comparando o Gráfico 5 com os gráficos de acesso seqüencial é possível perceber que a maior variância (totalmente previsível) está presente em um ambiente de bancos de dados totalmente distribuído. Observe a Figura 42. Variância - Acesso Seqüencial x puzzle Database KiloBytes Acesso Seqüencial (s) Puzzle Database (s) Variância 0,64 0,02 1,55 1, ,11 3,13 5,66 2,53 302,78 7,90 11,02 3,12 605,52 15,86 19,38 3,52 908,23 23,64 28,22 4, ,05 36,73 43,55 6,82 A variância média acesso seqüencial x puzzle Database é 3,58 segundos Figura 42 - Variância acesso seqüencial x puzzle Database Uma variância média de 3,58 segundos é totalmente aceitável, implica que em média a recuperações de informações em um ambiente distribuído será 3,58 segundos mais lenta que o acesso realizado de maneira seqüencial. O último ponto de amostra, equivalente a tuplas recuperadas teve uma amplitude de 6,82 segundos. (Bussab & Morettin, 2004) e (Silva, 1998), entretanto, discorrem sobre o erro padrão presente em toda inferência estatística. Segundo eles o grau de confiança selecionando implicitamente define a porcentagem do erro padrão na amostra, assim, 90% de confiança resulta em uma margem de erro equivalente a 10%. O limite máximo do Gráfico 5 estaria em um intervalo real de 39,19s - 47,90s, na melhor das hipóteses o limite inferior das tuplas de informações seria não mais 43,55s e sim 39,19s o que faria a variância nesse ponto, cair de 6,82s para apenas 2,46s. Gráfico 6 representa de maneira sucinta a análise de desempenho realizada no puzzle database. 79

80 Tempo(S) 55,00 50,00 Puzzle Database x Acesso Seqüencial 80 45,00 40,00 35,00 43,55 37,66 36,73 30,00 25,00 28,22 20,00 19,38 15,00 10,00 11,02 5,00 0,00 0,64 1,21 1,87 2,45 3,08 6,10 12,15 18,21 24,26 30,31 60,60 121,11 302,78 605,52 908, ,05 Dados (KB) Sequêncial PuzzleDatabase - Sequencial PuzzleDatabse - Distribuído Gráfico 6 - Gráfico Desempenho Puzzle Database

81 81 6 CONSIDERAÇÕES FINAIS O puzzle database é um middleware para distribuição de banco de dados estruturado sobre uma rede de computadores. Utilizando bases de dados open-source, o puzzle database, inter-relaciona vários servidores de dados através de uma camada de software posicionada sobre o nó da rede que possui a base de dados. O inter-relacionamento lógico dos dados é realizado através da invocação remota de métodos, esse modelo de programação distribuída, permite maior flexibilidade e facilidades no desenvolvimento de banco de dados distribuídos. Definida a partir de uma ampla pesquisa bibliográfica a fragmentação utilizada no puzzle database contribui para uma maior disponibilidade dos dados. Não existe a centralização das informações em um único nó da rede, assim, uma indisponibilidade de um servidor não resulta em total paralisação do sistema de banco de dados. Implementado com a linguagem de programação JAVA, o puzzle database pode ser utilizado em conjunto com os mais variados sistemas operacionais, contudo, faz-se necessário a instalação do Java virtual machine 1.6 ou superior. Inúmeros foram os desafios existentes no desenvolvimento do puzzle database, desempenho, transparência, tráfego de objetos complexo nas redes de computadores, interoperabilidade de SQL dentre outros. Essa complexidade impõe a certeza de que o processo de melhoria deve ser aperfeiçoado continuadamente. Futuras versões certamente terão seus algoritmos reavaliados para construir um perfeito ambiente de banco de dados distribuídos a partir de soluções open-source baseados em um modelo de programação orientados a objetos com referências remotas de objetos que são acessados e trafegados ao longo de uma rede de computadores. Embora a segurança, segundo (Coulouris, 2005) e (Tanembaum & Steen, 2002) figure entre os desafios insolúveis de sistemas distribuídos, nas versões subseqüentes do puzzle database, algoritmos que visem garantir a segurança das informações inevitavelmente deverão estar implementados.

82 Trabalhos futuros A replicação em banco de dados distribuídos proporciona vantagens como a disponibilidade dos dados, assim, se apenas um nó de dados estiver funcionando corretamente todas as informações poderão ser recuperadas a partir desse. Em um ambiente de banco de dados distribuídos, entretanto, a replicação apresenta inúmeros desafios como a sincronização de bases durante as transações de escritas. Os desafios de sincronização, contudo, podem ser solucionados utilizando as técnicas de sincronização propostas por (Cristian, 1989) e (Gussela & Zatti, 1989), para mais detalhes consulte a seção 3.4 do presente trabalho. A replicação, assim, poderá ser implementada em trabalhos futuros que terá como objetivo apenas assegurar um correto processo de replicação em banco de dados distribuídos. A interoperabilidade certamente é uma vertente da computação amplamente discutida, assim o puzzle database, certamente, pode aprimorar-se com algoritmos e estratégias que possibilitem promover ainda mais a interoperabilidade englobando um número crescente de banco de dados e especificações SQL. Embora o crescimento das redes de altas velocidades baseadas em tecnologia gigabit possibilite uma melhora de desempenho durante a requisição de informações espalhadas no ambiente de banco de dados distribuídos, em alguns casos, o tráfego na rede pode comprometer tal desempenho. A inteligência baseada em exames, entretanto, apresenta inúmeros algoritmos capazes de procurar o melhor caminho e ou rota, além de ser útil em tomadas de decisões referentes a processamento e ao escalonamento de sistemas distribuídos. Diante de cenário, um trabalho futuro para melhorar a performance do puzzle database poderia apresentar-se com um kernel baseada em inteligência de enxames, que seria responsável por traçar a melhor e menor rota durante o tráfego de dados na rede. Não obstante, esse mesmo kernel provido de inteligência, poderia migrar relações inteiras de acordo com as estatísticas de tráfego de dados e acesso a essas informações. Esse kernel, aqui denominado de puzzle inteligence certamente envolveria um longo processo de estudo e conhecimento das estratégias de distribuição debatidas ao longo da proposta. Observando esse contexto, sugere-se como trabalho futuro a criação do kernel puzzle inteligence para integrar o puzzle database.

83 ANEXOS 83

84 84 Diagrama de Estados Visão Geral/Configuração puzzle Database 1- Gerar XML com endereçamento lógico dos host s e respectivas relações puzzle XML. 2- Gravar no puzzle Properties caminho do XML gerado, processo realizado automaticamente no momento de geração do XML. 3- Recompilar a classe de conexão com banco de dados utilizando o puzzle Compiler. 4- Adicionar no Projeto que será distribuído o JAR puzzle database_ Gerar o JAR da Aplicação que será distribuída. 6- Executar o JAR puzzle database_1.0 nos host s que foram endereçados no puzzle XML como servidores de banco de dados. A imagem de execução do puzzle database de ser exibida. 7- Executar a aplicação que utiliza o sistema de banco de dados distribuídos. Observação: Todas as etapas descritas devem ser realizadas para efetivar a distribuíção.

85 85 Para acessar a tela de configuração (puzzle config), basta clicar com o botão auxiliar sobre a imagem do puzzle database (canto esquerda da barra de tarefas do sistema operacional), escolhendo em seguida a opação show. A Figura 43 será exibida Figura 43 - Tela de Execução puzzle Database 1- Gera XML de Distribuição. 2- Compila classe de conexão com banco de dados da aplicação. 3- Sai do puzzle database. 4- A aba settings irá exibir para o projetista/programador informações referentes JVM instalada, bem como possibilitará a alteração do caminho do XML de configuração. Diagrama de Classe Puzzle XML Ao receber as informações inseridas na tela do puzzle XML, Figura 28, é gerado o XML de configuração do puzzle database utilizando a API do JDOM, após esse processo, pode-se visualizar a estrutura do documento a partir do navegador padrão do sistema operacional. O método openxmlbroser, assegura tal procedimento.

Bancos de Dados Distribuídos. Filipe Gomes Pinto Guilherme Marquesini Reis Ribeiro Matheus Leônidas Silva Pedro Duarte

Bancos de Dados Distribuídos. Filipe Gomes Pinto Guilherme Marquesini Reis Ribeiro Matheus Leônidas Silva Pedro Duarte Bancos de Dados Distribuídos Filipe Gomes Pinto Guilherme Marquesini Reis Ribeiro Matheus Leônidas Silva Pedro Duarte Conceitos Sistema distribuído. Banco de dados distribuído (BDD). Coleção de multiplos

Leia mais

Bancos de dados distribuídos Prof. Tiago Eugenio de Melo tiagodemelo@gmail.com. http://www.tiagodemelo.info

Bancos de dados distribuídos Prof. Tiago Eugenio de Melo tiagodemelo@gmail.com. http://www.tiagodemelo.info Bancos de dados distribuídos Prof. Tiago Eugenio de Melo tiagodemelo@gmail.com Última atualização: 20.03.2013 Conceitos Banco de dados distribuídos pode ser entendido como uma coleção de múltiplos bds

Leia mais

Introdução a Banco de Dados

Introdução a Banco de Dados Introdução a Banco de Dados O modelo relacional Marta Mattoso Sumário Introdução Motivação Serviços de um SGBD O Modelo Relacional As aplicações não convencionais O Modelo Orientado a Objetos Considerações

Leia mais

BANCO DE DADOS DISTRIBUÍDOS e DATAWAREHOUSING

BANCO DE DADOS DISTRIBUÍDOS e DATAWAREHOUSING BANCO DE DADOS DISTRIBUÍDOS e DATAWAREHOUSING http://www.uniriotec.br/~tanaka/tin0036 tanaka@uniriotec.br Bancos de Dados Distribuídos Conceitos e Arquitetura Vantagens das Arquiteturas C/S (em relação

Leia mais

SISTEMA DE BANCO DE DADOS. Banco e Modelagem de dados

SISTEMA DE BANCO DE DADOS. Banco e Modelagem de dados SISTEMA DE BANCO DE DADOS Banco e Modelagem de dados Sumário Conceitos/Autores chave... 3 1. Introdução... 4 2. Arquiteturas de um Sistema Gerenciador... 5 3. Componentes de um Sistema... 8 4. Vantagens

Leia mais

Características Básicas de Sistemas Distribuídos

Características Básicas de Sistemas Distribuídos Motivação Crescente dependência dos usuários aos sistemas: necessidade de partilhar dados e recursos entre utilizadores; porque os recursos estão naturalmente em máquinas diferentes. Demanda computacional

Leia mais

SUMÁRIO CAPÍTULO 1 - INTRODUÇÃO 19 CAPÍTULO 2 - CONCEITOS 25

SUMÁRIO CAPÍTULO 1 - INTRODUÇÃO 19 CAPÍTULO 2 - CONCEITOS 25 SUMÁRIO LISTA DE FIGURAS LISTA DE TABELAS LISTA DE SIGLAS E ABREVIATURAS Pág. CAPÍTULO 1 - INTRODUÇÃO 19 CAPÍTULO 2 - CONCEITOS 25 2.1 A tecnologia de orientação a objetos 25 2.1.1 Projeto de software

Leia mais

Banco de Dados Distribuídos

Banco de Dados Distribuídos Banco de Dados Distribuídos Emmanuel Filho¹, Maria Cristina C. Rodrigues¹ Nayguron Henrique de S. Barreto¹, Wilton de Serpa Monteiro¹ ¹ Tecnologia em Análise e Desenvolvimento de Sistemas do Instituto

Leia mais

Banco de Dados Distribuídos

Banco de Dados Distribuídos A imagem não pode ser exibida. Talvez o computador não tenha memória suficiente para abrir a imagem ou talvez ela esteja corrompida. Reinicie o computador e abra o arquivo novamente. Se ainda assim aparecer

Leia mais

Metas de um Sistema Distribuído

Metas de um Sistema Distribuído Metas de um Sistema Distribuído Sistemas Distribuídos Mauro Lopes Carvalho Silva Professor EBTT DAI Departamento de Informática Campus Monte Castelo Instituto Federal de Educação Ciência e Tecnologia do

Leia mais

UNIPAC - UNIVERSIDADE PRESIDENTE ANTÔNIO CARLOS FACULDADE DE CIÊNCIA DA COMPUTAÇÃO E COMUNICAÇÃO SOCIAL CURSO DE CIÊNCIA COMPUTAÇÃO

UNIPAC - UNIVERSIDADE PRESIDENTE ANTÔNIO CARLOS FACULDADE DE CIÊNCIA DA COMPUTAÇÃO E COMUNICAÇÃO SOCIAL CURSO DE CIÊNCIA COMPUTAÇÃO UNIPAC - UNIVERSIDADE PRESIDENTE ANTÔNIO CARLOS FACULDADE DE CIÊNCIA DA COMPUTAÇÃO E COMUNICAÇÃO SOCIAL CURSO DE CIÊNCIA COMPUTAÇÃO Cynthia Pereira Silva BANCO DE DADOS DISTRIBUÍDOS BARBACENA DEZEMBRO

Leia mais

Projeto de Banco de Dados Distribuído Proj o e j to t o de d B a B nc n o o d e d Da D do d s o D i D str t ibu b í u do d s

Projeto de Banco de Dados Distribuído Proj o e j to t o de d B a B nc n o o d e d Da D do d s o D i D str t ibu b í u do d s Projeto de Alcides Pamplona alcides.pamplona@gmail.com Conteúdo Revisão de Conceitos Arquitetura Distribuída Fragmentação Horizontal Fragmentação Vertical 1 Definição de Banco de Dados Distribuído Um Banco

Leia mais

Arquitetura dos Sistemas de Informação Distribuídos

Arquitetura dos Sistemas de Informação Distribuídos Arquitetura dos Sistemas de Informação Distribuídos Quando se projeta um sistema cuja utilização é destinada a ser feita em ambientes do mundo real, projeções devem ser feitas para que o sistema possa

Leia mais

Laboratório de Banco de Dados

Laboratório de Banco de Dados Universidade Federal de Mato Grosso-UFMT Sistemas de Informação Laboratório de Banco de Dados Prof. Clóvis Júnior Laboratório de Banco de Dados Conteúdo Administração de Usuários de Papéis; Linguagens

Leia mais

Processos (Threads,Virtualização e Migração de Código)

Processos (Threads,Virtualização e Migração de Código) Processos (Threads,Virtualização e Migração de Código) Roteiro Processos Threads Virtualização Migração de Código O que é um processo?! Processos são programas em execução. Processo Processo Processo tem

Leia mais

Cliente/Servidor. Conceitos Gerais. Graça Bressan. Graça Bressan/LARC 2000 1

Cliente/Servidor. Conceitos Gerais. Graça Bressan. Graça Bressan/LARC 2000 1 Cliente/Servidor Conceitos Gerais Graça Bressan Graça Bressan/LARC 2000 1 Forças de marketing que conduzem à arquitetura cliente/servidor "Cliente/Servidor é um movimento irresistível que está reformulando

Leia mais

Trabalho de Sistemas Distribuídos

Trabalho de Sistemas Distribuídos Cássio de Olivera Ferraz Trabalho de Sistemas Distribuídos Petrópolis 2015, v-1.0 Cássio de Olivera Ferraz Trabalho de Sistemas Distribuídos Trabalho sobre sistemas distribuídos e suas tecnologias. Universidade

Leia mais

SISTEMAS DE BANCO DE DADOS. Prof. Adriano Pereira Maranhão

SISTEMAS DE BANCO DE DADOS. Prof. Adriano Pereira Maranhão SISTEMAS DE BANCO DE DADOS Prof. Adriano Pereira Maranhão 1 REVISÃO BANCO DE DADOS I O que é banco de dados? Ou seja afinal o que é um SGBD? REVISÃO BD I REVISÃO DE BD I Um Sistema de Gerenciamento de

Leia mais

CONCEITOS BÁSICOS. 1. Conceitos básicos de BD, SBD e SGBD BANCO DE DADOS I

CONCEITOS BÁSICOS. 1. Conceitos básicos de BD, SBD e SGBD BANCO DE DADOS I CONCEITOS BÁSICOS 1. Conceitos básicos de BD, SBD e SGBD A importância da informação para a tomada de decisões nas organizações tem impulsionado o desenvolvimento dos sistemas de processamento de informações.

Leia mais

Arquitetura de SGBD. Prof. Antonio Almeida de Barros Junior

Arquitetura de SGBD. Prof. Antonio Almeida de Barros Junior Arquitetura de SGBD Prof. Antonio Almeida de Barros Junior Agenda Caracterização de SGBDs SGBDs Centralizados SGBDs Cliente-Servidor SGBDs Distribuídos Homogêneos Multi-SGBDs Heterogêneos SGBDs Paralelos

Leia mais

SISTEMAS DISTRIBUIDOS

SISTEMAS DISTRIBUIDOS 1 2 Caracterização de Sistemas Distribuídos: Os sistemas distribuídos estão em toda parte. A Internet permite que usuários de todo o mundo acessem seus serviços onde quer que possam estar. Cada organização

Leia mais

Etapas da evolução rumo a tomada de decisão: Aplicações Isoladas: dados duplicados, dados inconsistentes, processos duplicados.

Etapas da evolução rumo a tomada de decisão: Aplicações Isoladas: dados duplicados, dados inconsistentes, processos duplicados. Histórico Etapas da evolução rumo a tomada de decisão: Aplicações Isoladas: dados duplicados, dados inconsistentes, processos duplicados. Sistemas Integrados: racionalização de processos, manutenção dos

Leia mais

Sistemas Distribuídos Comunicação entre Processos em Sistemas Distribuídos: Middleware de comunicação Aula II Prof. Rosemary Silveira F. Melo Comunicação em sistemas distribuídos é um ponto fundamental

Leia mais

Bancos de Dados Distribuídos

Bancos de Dados Distribuídos Bancos de Dados Distribuídos Visão geral de BDD Fernanda Baião baiao@cos.ufrj.br Departamento de Informática Aplicada UNIRIO 2006.2 Bibliografia Utilizada Conteúdo Özsu, M.T. Valduriez, P. "Principles

Leia mais

Roteiro 2 Conceitos Gerais

Roteiro 2 Conceitos Gerais Roteiro 2 Conceitos Gerais Objetivos: UC Projeto de Banco de Dados Explorar conceitos gerais de bancos de dados; o Arquitetura de bancos de dados: esquemas, categorias de modelos de dados, linguagens e

Leia mais

SISTEMA GERENCIADOR DE BANCO DE DADOS

SISTEMA GERENCIADOR DE BANCO DE DADOS BANCO DE DADOS Universidade do Estado de Santa Catarina Centro de Ciências Tecnológicas Departamento de Ciência da Computação Prof. Alexandre Veloso de Matos alexandre.matos@udesc.br SISTEMA GERENCIADOR

Leia mais

Banco de Dados I. Introdução Conceitos

Banco de Dados I. Introdução Conceitos Banco de Dados I Introdução Conceitos Prof. Rodrigo Rocha prof.rodrigorocha@yahoo.com Apresentação Prof. Rodrigo Rocha prof.rodrigorocha@yahoo.com Ementa Conceitos Fundamentais de Banco de Dados; Características

Leia mais

Introdução a Computação

Introdução a Computação Introdução a Computação Aula 04 SGBD Sistemas Gerenciadores de Bancos de Dados Prof. MSc. Edilberto Silva edilms@yahoo.com Conceitos Básicos DADOS: são fatos em sua forma primária. Ex: nome do funcionário,

Leia mais

Ferramentas Web para controle e supervisão: o que está por vir

Ferramentas Web para controle e supervisão: o que está por vir Artigos Técnicos Ferramentas Web para controle e supervisão: o que está por vir Marcelo Salvador, Diretor de Negócios da Elipse Software Ltda. Já faz algum tempo que ouvimos falar do controle e supervisão

Leia mais

Dado: Fatos conhecidos que podem ser registrados e têm um significado implícito. Banco de Dados:

Dado: Fatos conhecidos que podem ser registrados e têm um significado implícito. Banco de Dados: MC536 Introdução Sumário Conceitos preliminares Funcionalidades Características principais Usuários Vantagens do uso de BDs Tendências mais recentes em SGBDs Algumas desvantagens Modelos de dados Classificação

Leia mais

Sistemas Distribuídos. Introdução

Sistemas Distribuídos. Introdução Sistemas Distribuídos Introdução Definição Processos Um sistema distribuído é um conjunto de computadores independentes, interligados por uma rede de conexão, executando um software distribuído. Executados

Leia mais

Para construção dos modelos físicos, será estudado o modelo Relacional como originalmente proposto por Codd.

Para construção dos modelos físicos, será estudado o modelo Relacional como originalmente proposto por Codd. Apresentação Este curso tem como objetivo, oferecer uma noção geral sobre a construção de sistemas de banco de dados. Para isto, é necessário estudar modelos para a construção de projetos lógicos de bancos

Leia mais

Projeto de Sistemas Distribuídos. Prof. Andrêza Leite andreza.lba@gmail.com

Projeto de Sistemas Distribuídos. Prof. Andrêza Leite andreza.lba@gmail.com Projeto de Sistemas Distribuídos Prof. Andrêza Leite andreza.lba@gmail.com Exemplos de SD Quais podem ser? Ex. de SD: Internet Internet é um conjunto de redes de computadores, de muitos tipos diferentes,

Leia mais

BANCO DE DADOS. Introdução a Banco de Dados. Conceitos BásicosB. Engenharia da Computação UNIVASF. Aula 1. Breve Histórico

BANCO DE DADOS. Introdução a Banco de Dados. Conceitos BásicosB. Engenharia da Computação UNIVASF. Aula 1. Breve Histórico Banco de Dados // 1 Banco de Dados // 2 Conceitos BásicosB Engenharia da Computação UNIVASF BANCO DE DADOS Aula 1 Introdução a Banco de Dados Campo representação informatizada de um dado real / menor unidade

Leia mais

Gonçalo Amador Ricardo Alexandre. Bases de Dados Distribuídas

Gonçalo Amador Ricardo Alexandre. Bases de Dados Distribuídas Sistemas Distribuidos e Tolerância a Falhas Gonçalo Amador Ricardo Alexandre Departamento de Informática Universidade da Beira Interior Bases de Dados Distribuídas 1 Modelos de Bases de Dados 2 Conceitos

Leia mais

Gerenciamento de Redes

Gerenciamento de Redes Gerenciamento de Redes As redes de computadores atuais são compostas por uma grande variedade de dispositivos que devem se comunicar e compartilhar recursos. Na maioria dos casos, a eficiência dos serviços

Leia mais

Introdução Banco de Dados

Introdução Banco de Dados Introdução Banco de Dados Vitor Valerio de Souza Campos Adaptado de Vania Bogorny Por que estudar BD? Os Bancos de Dados fazem parte do nosso dia-a-dia: operação bancária reserva de hotel matrícula em

Leia mais

Introdução. Unidade 1. Engenharia de Computação / Engenharia de Produção Banco de Dados Prof. Maria das Graças da Silva Teixeira

Introdução. Unidade 1. Engenharia de Computação / Engenharia de Produção Banco de Dados Prof. Maria das Graças da Silva Teixeira Unidade 1 Introdução Engenharia de Computação / Engenharia de Produção Banco de Dados Prof. Maria das Graças da Silva Teixeira Material base: Banco de Dados, 2009.2, prof. Otacílio José Pereira Contexto

Leia mais

Integração de Dados na Web. Ana Carolina Salgado Bernadette Lóscio

Integração de Dados na Web. Ana Carolina Salgado Bernadette Lóscio Integração de Dados na Web Ana Carolina Salgado Bernadette Lóscio Conteúdo Introdução Integração de Informações Consultando a Web Introdução Motivação Web e BD Arquitetura na Web Introdução Evolução da

Leia mais

Banco de Dados. Aula 1 - Prof. Bruno Moreno 16/08/2011

Banco de Dados. Aula 1 - Prof. Bruno Moreno 16/08/2011 Banco de Dados Aula 1 - Prof. Bruno Moreno 16/08/2011 Roteiro Apresentação do professor e disciplina Definição de Banco de Dados Sistema de BD vs Tradicional Principais características de BD Natureza autodescritiva

Leia mais

Persistência e Banco de Dados em Jogos Digitais

Persistência e Banco de Dados em Jogos Digitais Persistência e Banco de Dados em Jogos Digitais Prof. Marcos Francisco Pereira da Silva Especialista em Engenharia de Software Jogos Digitais - Computação Gráfica 1 Agenda Vantagens de usar a abordagem

Leia mais

Componentes para Computação Distribuída

Componentes para Computação Distribuída Componentes para Computação Distribuída Conceitos Foi a partir do fenômeno da Internet (WWW), no início dos anos noventa, que a computação distribuída passou a ter relevância definitiva, a ponto de a Internet

Leia mais

Bancos de Dados Distribuídos

Bancos de Dados Distribuídos Bancos de Dados Distribuídos Fernanda Baião baiao@cos.ufrj.br Departamento de Informática Aplicada UNIRIO 2007.2 Bibliografia Utilizada Principal: Özsu, M.T. Valduriez, P. "Princípios de Sistemas de Banco

Leia mais

Sistemas Distribuídos

Sistemas Distribuídos Sistemas Distribuídos Soquetes Um soquete é formado por um endereço IP concatenado com um número de porta. Em geral, os soquetes utilizam uma arquitetura cliente-servidor. O servidor espera por pedidos

Leia mais

GBC043 Sistemas de Banco de Dados. Introdução. Ilmério Reis da Silva ilmerio@facom.ufu.br www.facom.ufu.br/~ilmerio/sbd UFU/FACOM

GBC043 Sistemas de Banco de Dados. Introdução. Ilmério Reis da Silva ilmerio@facom.ufu.br www.facom.ufu.br/~ilmerio/sbd UFU/FACOM GBC043 Sistemas de Banco de Dados Introdução Ilmério Reis da Silva ilmerio@facom.ufu.br www.facom.ufu.br/~ilmerio/sbd UFU/FACOM Página 2 Definição BD Def. Banco de Dados é uma coleção de itens de dados

Leia mais

Prof. Marcelo Machado Cunha www.marcelomachado.com mcelobr@yahoo.com.br

Prof. Marcelo Machado Cunha www.marcelomachado.com mcelobr@yahoo.com.br Prof. Marcelo Machado Cunha www.marcelomachado.com mcelobr@yahoo.com.br Ementa Introdução a Banco de Dados (Conceito, propriedades), Arquivos de dados x Bancos de dados, Profissionais de Banco de dados,

Leia mais

Disciplina: Tecnologias de Banco de Dados para SI s

Disciplina: Tecnologias de Banco de Dados para SI s Curso de Gestão em SI Disciplina: Tecnologias de Banco de Dados para SI s Rodrigo da Silva Gomes (Extraído do material do prof. Ronaldo Melo - UFSC) Banco de Dados (BD) BD fazem parte do nosso dia-a-dia!

Leia mais

PEER DATA MANAGEMENT SYSTEM

PEER DATA MANAGEMENT SYSTEM PEER DATA MANAGEMENT SYSTEM INTRODUÇÃO, INFRA-ESTRUTURA E MAPEAMENTO DE ESQUEMAS AGENDA Data Management System Peer Data Management System P2P Infra-estrutura Funcionamento do PDMS Mapeamento de Esquemas

Leia mais

Conceitos de Banco de Dados

Conceitos de Banco de Dados Conceitos de Banco de Dados Autor: Luiz Antonio Junior 1 INTRODUÇÃO Objetivos Introduzir conceitos básicos de Modelo de dados Introduzir conceitos básicos de Banco de dados Capacitar o aluno a construir

Leia mais

Introdução. Banco de dados. Por que usar BD? Por que estudar BD? Exemplo de um BD. Conceitos básicos

Introdução. Banco de dados. Por que usar BD? Por que estudar BD? Exemplo de um BD. Conceitos básicos Introdução Banco de Dados Por que usar BD? Vitor Valerio de Souza Campos Adaptado de Vania Bogorny 4 Por que estudar BD? Exemplo de um BD Os Bancos de Dados fazem parte do nosso dia-a-dia: operação bancária

Leia mais

Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2

Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2 Curso Tecnológico de Redes de Computadores 5º período Disciplina: Tecnologia WEB Professor: José Maurício S. Pinheiro V. 2009-2 Aula 2 Computação em Nuvem Desafios e Oportunidades A Computação em Nuvem

Leia mais

Bases de Dados aplicadas a Inteligência de Negócios

Bases de Dados aplicadas a Inteligência de Negócios Agenda Bases de Dados aplicadas a Inteligência de Negócios Professor Sérgio Rodrigues professor@sergiorodrigues.net Sistemas de Gerenciamento de Bancos de Dados (SGBD) Tipos de Banco de Dados Noções de

Leia mais

08/04/2013. Agenda. O Sistema CACHÉ. O Sistema CACHÉ. O Sistema CACHÉ. O Sistema CACHÉ

08/04/2013. Agenda. O Sistema CACHÉ. O Sistema CACHÉ. O Sistema CACHÉ. O Sistema CACHÉ Agenda Caché Server Pages Uma Aplicação Banco de Dados Fernando Fonseca Ana Carolina Salgado Mestrado Profissional 2 SGBD de alto desempenho e escalabilidade Servidor de dados multidimensional Arquitetura

Leia mais

2 Conceitos relativos a Web services e sua composição

2 Conceitos relativos a Web services e sua composição 15 2 Conceitos relativos a Web services e sua composição A necessidade de flexibilidade na arquitetura das aplicações levou ao modelo orientado a objetos, onde os processos de negócios podem ser representados

Leia mais

Introdução. Conceitos Básicos. Conceitos Básicos. Conceitos Básicos

Introdução. Conceitos Básicos. Conceitos Básicos. Conceitos Básicos Conceitos Básicos Introdução Banco de Dados I Prof. Guilherme Tavares de Assis Universidade Federal de Ouro Preto UFOP Instituto de Ciências Exatas e Biológicas ICEB Departamento de Computação DECOM Dados

Leia mais

BANCO DE DADOS AULA 02 INTRODUÇÃO AOS BANCOS DE DADOS PROF. FELIPE TÚLIO DE CASTRO 2015

BANCO DE DADOS AULA 02 INTRODUÇÃO AOS BANCOS DE DADOS PROF. FELIPE TÚLIO DE CASTRO 2015 BANCO DE DADOS AULA 02 INTRODUÇÃO AOS BANCOS DE DADOS PROF. FELIPE TÚLIO DE CASTRO 2015 NA AULA PASSADA... 1. Apresentamos a proposta de ementa para a disciplina; 2. Discutimos quais as ferramentas computacionais

Leia mais

Banco de Dados 1 Prof. MSc Wagner Siqueira Cavalcante

Banco de Dados 1 Prof. MSc Wagner Siqueira Cavalcante Banco de Dados 1 Programação sucinta do curso:. Conceitos fundamentais de Banco de Dados.. Arquitetura dos Sistemas Gerenciadores de Banco de Dados (SGBD ou DBMS).. Características típicas de um SGBD..

Leia mais

Roteiro. Sistemas Distribuídos. Sistemas de Arquivos Distribuídos. Sistema de arquivos distribuídos

Roteiro. Sistemas Distribuídos. Sistemas de Arquivos Distribuídos. Sistema de arquivos distribuídos Sistemas Distribuídos Sistemas de Arquivos Distribuídos Roteiro Sistema de arquivos distribuídos Requisitos Arquivos e diretórios Compartilhamento Cache Replicação Estudo de caso: NFS e AFS Sistemas Distribuídos

Leia mais

1. CONCEITOS BÁSICOS DE BD, SBD E SGBD

1. CONCEITOS BÁSICOS DE BD, SBD E SGBD Introdução 1. CONCEITOS BÁSICOS DE BD, SBD E SGBD A importância da informação para a tomada de decisões nas organizações tem impulsionado o desenvolvimento dos sistemas de processamento de informações.

Leia mais

Eduardo Bezerra. Editora Campus/Elsevier

Eduardo Bezerra. Editora Campus/Elsevier Princípios de Análise e Projeto de Sistemas com UML 2ª edição Eduardo Bezerra Editora Campus/Elsevier Capítulo 11 Arquitetura do sistema Nada que é visto, é visto de uma vez e por completo. --EUCLIDES

Leia mais

Camadas de Software - o Middleware. Sistemas Distribuídos Capítulo 2: Modelos e Arquitecturas. Aplicações. Middleware.

Camadas de Software - o Middleware. Sistemas Distribuídos Capítulo 2: Modelos e Arquitecturas. Aplicações. Middleware. Camadas de Software - o Middleware Sistemas Distribuídos Capítulo 2: Modelos e Arquitecturas Modelos de Arquitecturas para sistemas distribuidos Interfaces e Objectos Requerimentos para Arquitecturas Distribuídas

Leia mais

INTRODUÇÃO E CONCEITOS BÁSICOS. Prof. Ronaldo R. Goldschmidt

INTRODUÇÃO E CONCEITOS BÁSICOS. Prof. Ronaldo R. Goldschmidt INTRODUÇÃO E CONCEITOS BÁSICOS Prof. Ronaldo R. Goldschmidt Hierarquia Dado - Informação - Conhecimento: Dados são fatos com significado implícito. Podem ser armazenados. Dados Processamento Informação

Leia mais

Éverton Alves de Oliveira. Banco de Dados Distribuído no Desenvolvimento de Aplicações Comerciais

Éverton Alves de Oliveira. Banco de Dados Distribuído no Desenvolvimento de Aplicações Comerciais Éverton Alves de Oliveira Banco de Dados Distribuído no Desenvolvimento de Aplicações Comerciais Londrina 2006 Éverton Alves de Oliveira Banco de Dados Distribuído no Desenvolvimento de Aplicações Comerciais

Leia mais

Introdução a Informática. Prof.: Roberto Franciscatto

Introdução a Informática. Prof.: Roberto Franciscatto Introdução a Informática Prof.: Roberto Franciscatto 6.1 ARQUIVOS E REGISTROS De um modo geral os dados estão organizados em arquivos. Define-se arquivo como um conjunto de informações referentes aos elementos

Leia mais

Introdução. Motivação. Sistema Gerenciador de Banco de Dados (SGBD) Banco de Dados (BD) Sistema de Banco de Dados (SBD)

Introdução. Motivação. Sistema Gerenciador de Banco de Dados (SGBD) Banco de Dados (BD) Sistema de Banco de Dados (SBD) Pós-graduação em Ciência da Computação CCM-202 Sistemas de Banco de Dados Introdução Profa. Maria Camila Nardini Barioni camila.barioni@ufabc.edu.br Bloco B - sala 937 2 quadrimestre de 2011 Motivação

Leia mais

Considerações no Projeto de Sistemas Cliente/Servidor

Considerações no Projeto de Sistemas Cliente/Servidor Cliente/Servidor Desenvolvimento de Sistemas Graça Bressan Graça Bressan/LARC 2000 1 Desenvolvimento de Sistemas Cliente/Servidor As metodologias clássicas, tradicional ou orientada a objeto, são aplicáveis

Leia mais

Treinamento PostgreSQL - Aula 01

Treinamento PostgreSQL - Aula 01 Treinamento PostgreSQL - Aula 01 Eduardo Ferreira dos Santos SparkGroup Treinamento e Capacitação em Tecnologia eduardo.edusantos@gmail.com eduardosan.com 27 de Maio de 2013 Eduardo Ferreira dos Santos

Leia mais

BANCO DE DADOS CONCEITOS BÁSICOS

BANCO DE DADOS CONCEITOS BÁSICOS Universidade Federal da Paraíba UFPB Centro de Energias Alternativas e Renováveis - CEAR Departamento de Eng. Elétrica DEE BANCO DE DADOS CONCEITOS BÁSICOS Isaac Maia Pessoa Introdução O que é um BD? Operações

Leia mais

Banco de Dados I. Introdução. Fabricio Breve

Banco de Dados I. Introdução. Fabricio Breve Banco de Dados I Introdução Fabricio Breve Introdução SGBD (Sistema Gerenciador de Banco de Dados): coleção de dados interrelacionados e um conjunto de programas para acessar esses dados Coleção de dados

Leia mais

XDR. Solução para Big Data.

XDR. Solução para Big Data. XDR Solução para Big Data. ObJetivo Principal O volume de informações com os quais as empresas de telecomunicações/internet têm que lidar é muito grande, e está em constante crescimento devido à franca

Leia mais

Introdução. Definição de um Sistema Distribuído (1) Definição de um Sistema Distribuído(2) Metas de Sistemas Distribuídos (2)

Introdução. Definição de um Sistema Distribuído (1) Definição de um Sistema Distribuído(2) Metas de Sistemas Distribuídos (2) Definição de um Sistema Distribuído (1) Introdução Um sistema distribuído é: Uma coleção de computadores independentes que aparecem para o usuário como um único sistema coerente. Definição de um Sistema

Leia mais

Sistemas Distribuídos: Conceitos e Projeto Estilos Arquitetônicos e Arquitetura Cliente/Servidor

Sistemas Distribuídos: Conceitos e Projeto Estilos Arquitetônicos e Arquitetura Cliente/Servidor Sistemas Distribuídos: Conceitos e Projeto Estilos Arquitetônicos e Arquitetura Cliente/Servidor Francisco José da Silva e Silva Laboratório de Sistemas Distribuídos (LSD) Departamento de Informática /

Leia mais

Qual o Papel de um DBA? Saiba mais sobre o que faz um administrador de banco de dados e como se tornar um

Qual o Papel de um DBA? Saiba mais sobre o que faz um administrador de banco de dados e como se tornar um Qual o Papel de um DBA? Saiba mais sobre o que faz um administrador de banco de dados e como se tornar um Carina Friedrich Dorneles, dorneles@upf.br, Universidade de Passo Fundo (UPF) Ronaldo dos Santos

Leia mais

Bancos de Dados Móveis

Bancos de Dados Móveis Agenda Bancos de Dados Móveis Acadêmicas: Anete Terezinha Trasel Denise Veronez Introdução Banco de Dados Móveis (BDM) Projetos de BDM SGBD Móveis Conclusão Referências Bibliográficas Introdução Avanços

Leia mais

XML e Banco de Dados. Prof. Daniela Barreiro Claro DCC/IM/UFBA

XML e Banco de Dados. Prof. Daniela Barreiro Claro DCC/IM/UFBA XML e Banco de Dados DCC/IM/UFBA Banco de Dados na Web Armazenamento de dados na Web HTML muito utilizada para formatar e estruturar documentos na Web Não é adequada para especificar dados estruturados

Leia mais

Banco de Dados. Uma coleção de dados relacionados [ELMASRI/NAVATHE]

Banco de Dados. Uma coleção de dados relacionados [ELMASRI/NAVATHE] 1/6 Banco de Dados O que é um Banco de Dados? Uma coleção de dados relacionados [ELMASRI/NAVATHE] Conjunto de dados integrados que tem por objetivo atender a uma comunidade específica [HEUSER] Um conjunto

Leia mais

Prof.: Clayton Maciel Costa clayton.maciel@ifrn.edu.br

Prof.: Clayton Maciel Costa clayton.maciel@ifrn.edu.br Programação com acesso a BD Prof.: Clayton Maciel Costa clayton.maciel@ifrn.edu.br 1 Modelos de Dados, Esquemas e Instâncias 2 Modelos de Dados, Esquemas e Instâncias Modelo de dados: Conjunto de conceitos

Leia mais

Sistema de Bancos de Dados. Conceitos Gerais Sistema Gerenciador de Bancos de Dados

Sistema de Bancos de Dados. Conceitos Gerais Sistema Gerenciador de Bancos de Dados Sistema de Bancos de Dados Conceitos Gerais Sistema Gerenciador de Bancos de Dados # Definições # Motivação # Arquitetura Típica # Vantagens # Desvantagens # Evolução # Classes de Usuários 1 Nível 1 Dados

Leia mais

Arquitetura de Sistemas Distribuídos. Introdução a Sistemas Distribuídos

Arquitetura de Sistemas Distribuídos. Introdução a Sistemas Distribuídos Introdução a Sistemas Distribuídos Definição: "Um sistema distribuído é uma coleção de computadores autônomos conectados por uma rede e equipados com um sistema de software distribuído." "Um sistema distribuído

Leia mais

Sistemas Distribuídos. Professora: Ana Paula Couto DCC 064

Sistemas Distribuídos. Professora: Ana Paula Couto DCC 064 Sistemas Distribuídos Professora: Ana Paula Couto DCC 064 Introdução Capítulo 1 Definição Um sistema distribuído é um conjunto de computadores independentes entre si que se apresenta a seus usuários como

Leia mais

2 Trabalhos Relacionados

2 Trabalhos Relacionados 2 Trabalhos Relacionados Nesse capítulo, apresentamos os trabalhos relacionados ao GridFS, entrando em mais detalhes sobre os sistemas citados durante a introdução e realizando algumas considerações sobre

Leia mais

APLICAÇÕES EM SISTEMAS DISTRIBUÍDOS Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com

APLICAÇÕES EM SISTEMAS DISTRIBUÍDOS Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com - Aula 6 - ALGORÍTIMOS PARALELOS MPI - Parallel Virtual Machine e PVM - Parallel Virtual Machine 1. INTRODUÇÃO Inicialmente é necessário conceber alguns conceitos para entendimento dos algoritmos paralelos:

Leia mais

Modelos de Arquiteturas. Prof. Andrêza Leite andreza.lba@gmail.com

Modelos de Arquiteturas. Prof. Andrêza Leite andreza.lba@gmail.com Modelos de Arquiteturas Prof. Andrêza Leite andreza.lba@gmail.com Agenda Introdução Arquitetura de Sistemas Distribuídos Clientes e Servidores Peer-to-Peer Variações Vários Servidores Proxy Código Móvel

Leia mais

Intranets. FERNANDO ALBUQUERQUE Departamento de Ciência da Computação Universidade de Brasília 1.INTRODUÇÃO

Intranets. FERNANDO ALBUQUERQUE Departamento de Ciência da Computação Universidade de Brasília 1.INTRODUÇÃO Intranets FERNANDO ALBUQUERQUE Departamento de Ciência da Computação Universidade de Brasília 1.INTRODUÇÃO As intranets são redes internas às organizações que usam as tecnologias utilizadas na rede mundial

Leia mais

Plano de Ensino. Apresentação da Unidade Curricular

Plano de Ensino. Apresentação da Unidade Curricular Plano de Ensino Plano de Ensino Apresentação da Unidade Curricular o Funcionamento, arquitetura e conceitos fundamentais dos bancos de dados relacionais e objeto relacionais. Utilização de linguagem DDL

Leia mais

Modelos e Arquiteturas de Sistemas Computacionais

Modelos e Arquiteturas de Sistemas Computacionais Modelos e Arquiteturas de Sistemas Computacionais Prof. Ricardo J. Rabelo UFSC Universidade Federal de Santa Catarina DAS Departamento de Automação e Sistemas SUMÁRIO Importância da definição da Arquitetura

Leia mais

Sistemas distribuídos:comunicação

Sistemas distribuídos:comunicação M. G. Santos marcela@estacio.edu.br Faculdade Câmara Cascudo - Estácio de Sá 16 de abril de 2010 Formas de comunicação Produtor-consumidor: comunicação uni-direccional, com o produtor entregando ao consumidor.

Leia mais

Engenharia de Software I

Engenharia de Software I Engenharia de Software I Rogério Eduardo Garcia (rogerio@fct.unesp.br) Bacharelado em Ciência da Computação Aula 05 Material preparado por Fernanda Madeiral Delfim Tópicos Aula 5 Contextualização UML Astah

Leia mais

Banco de Dados. Introdução. João Eduardo Ferreira Osvaldo Kotaro Takai. jef@ime.usp.br DCC-IME-USP

Banco de Dados. Introdução. João Eduardo Ferreira Osvaldo Kotaro Takai. jef@ime.usp.br DCC-IME-USP Banco de Dados Introdução João Eduardo Ferreira Osvaldo Kotaro Takai jef@ime.usp.br DCC-IME-USP Importância dos Bancos de Dados A competitividade das empresas depende de dados precisos e atualizados. Conforme

Leia mais

MASSACHUSETTS INSTITUTE OF TECHNOLOGY SLOAN SCHOOL OF MANAGEMENT

MASSACHUSETTS INSTITUTE OF TECHNOLOGY SLOAN SCHOOL OF MANAGEMENT MASSACHUSETTS INSTITUTE OF TECHNOLOGY SLOAN SCHOOL OF MANAGEMENT 15.565 Integração de Sistemas de Informação: Fatores Tecnológicos, Estratégicos e Organizacionais 15.578 Sistemas de Informação Global:

Leia mais

CORBA. Common Object Request Broker Architecture. Unicamp. Centro de Computação Rubens Queiroz de Almeida queiroz@unicamp.br

CORBA. Common Object Request Broker Architecture. Unicamp. Centro de Computação Rubens Queiroz de Almeida queiroz@unicamp.br CORBA Common Object Request Broker Architecture Unicamp Centro de Computação Rubens Queiroz de Almeida queiroz@unicamp.br Objetivos Apresentação Tecnologia CORBA Conceitos Básicos e Terminologia Considerações

Leia mais

Sistemas de Informação James A. O Brien Editora Saraiva Capítulo 5

Sistemas de Informação James A. O Brien Editora Saraiva Capítulo 5 Para entender bancos de dados, é útil ter em mente que os elementos de dados que os compõem são divididos em níveis hierárquicos. Esses elementos de dados lógicos constituem os conceitos de dados básicos

Leia mais

ADMINISTRAÇÃO DOS RECURSOS DE HARDWARE E SOFTWARE

ADMINISTRAÇÃO DOS RECURSOS DE HARDWARE E SOFTWARE Capítulo 6 ADMINISTRAÇÃO DOS RECURSOS DE HARDWARE E SOFTWARE 6.1 2003 by Prentice Hall OBJETIVOS Qual é a capacidade de processamento e armazenagem que sua organização precisa para administrar suas informações

Leia mais

1 http://www.google.com

1 http://www.google.com 1 Introdução A computação em grade se caracteriza pelo uso de recursos computacionais distribuídos em várias redes. Os diversos nós contribuem com capacidade de processamento, armazenamento de dados ou

Leia mais

Hoje é inegável que a sobrevivência das organizações depende de dados precisos e atualizados.

Hoje é inegável que a sobrevivência das organizações depende de dados precisos e atualizados. BANCO DE DADOS Universidade do Estado de Santa Catarina Centro de Ciências Tecnológicas Departamento de Ciência da Computação Prof. Alexandre Veloso de Matos alexandre.matos@udesc.br INTRODUÇÃO Hoje é

Leia mais

Banco de Dados Distribuídos

Banco de Dados Distribuídos Banco de Dados Distribuídos Brasília-DF, 2011. Elaboração: Ednewton de Vasconcelos Produção: Equipe Técnica de Avaliação, Revisão Linguística e Editoração Banco de Dados Distribuídos 2 Sumário Apresentação...

Leia mais

ADMINISTRAÇÃO DOS RECURSOS DE HARDWARE E SOFTWARE

ADMINISTRAÇÃO DOS RECURSOS DE HARDWARE E SOFTWARE ADMINISTRAÇÃO DOS RECURSOS DE HARDWARE E SOFTWARE 1 OBJETIVOS 1. Qual é a capacidade de processamento e armazenagem que sua organização precisa para administrar suas informações e transações empresariais?

Leia mais

Unidade 5 Armazenamento e Indexação

Unidade 5 Armazenamento e Indexação Unidade 5 Armazenamento e Indexação Engenharia de Computação / Engenharia de Produção Banco de Dados Prof. Maria das Graças da Silva Teixeira Material base: Banco de Dados, 2009.2, prof. Otacílio José

Leia mais

Implementar servidores de Web/FTP e DFS. Disciplina: Serviços de Redes Microsoft Professor: Fernando Santorsula fernando.santorsula@esamc.

Implementar servidores de Web/FTP e DFS. Disciplina: Serviços de Redes Microsoft Professor: Fernando Santorsula fernando.santorsula@esamc. Implementar servidores de Web/FTP e DFS Disciplina: Serviços de Redes Microsoft Professor: Fernando Santorsula fernando.santorsula@esamc.br Conteúdo programático Introdução ao protocolo HTTP Serviço web

Leia mais

UFG - Instituto de Informática

UFG - Instituto de Informática UFG - Instituto de Informática Especialização em Desenvolvimento de Aplicações Web com Interfaces Ricas EJB 3.0 Prof.: Fabrízzio A A M N Soares professor.fabrizzio@gmail.com Aula 13 Web Services Web Services

Leia mais