UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO

Transcrição

1 UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO BANCO DE DADOS ORIENTADO A OBJETOS COMO FERRAMENTA PARA ARMAZENAMENTO E RECUPERAÇÃO DE DADOS MULTIMÍDIA Banco de Dados por Marcela Leite Alexandre Biazin, M.Sc Orientador Itajaí (SC), junho de 2008

2 UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO BANCO DE DADOS ORIENTADO A OBJETOS COMO FERRAMENTA PARA ARMAZENAMENTO E RECUPERAÇÃO DE DADOS MULTIMÍDIA Banco de Dados por Marcela Leite Relatório apresentado à Banca Examinadora do Trabalho de Conclusão do Curso de Ciência da Computação para análise e aprovação. Orientador: Alexandre Biazin, M.Sc Itajaí (SC), junho de 2008

3 SUMÁRIO LISTA DE ABREVIATURAS...iv LISTA DE FIGURAS...v LISTA DE TABELAS...vii RESUMO...viii ABSTRACT...ix 1 INTRODUÇÃO PROBLEMATIZAÇÃO Formulação do Problema Solução Proposta OBJETIVOS Objetivo Geral Objetivos Específicos METODOLOGIA ESTRUTURA DO TRABALHO FUNDAMENTAÇÃO TEÓRICA DADOS MULTIMÍDIA ARMAZENAMENTO E RECUPERAÇÃO DE DADOS MULTIMÍDIA GERENCIAMENTO ELETRÔNICO DE DOCUMENTOS BANCO DE DADOS OBJETO-RELACIONAL Modelo Relacional (MR) Modelo de Entidade/Relacionamento (MER) Modelo de dados EER - ER Estendido BANCOS DE DADOS ORIENTADOS A OBJETOS Modelo de Dados Orientado a Objetos Object Database Management Group (ODMG) FERRAMENTAS DISPONÍVEIS DE BANCOS DE DADOS ORIENTADOS A OBJETOS Caché Poet Jasmine Versant Análise comparativa FERRAMENTAS DISPONÍVEIS DE BANCOS DE DADOS OBJETO- RELACIONAL DB Oracle Análise comparativa ii

4 3 DESENVOLVIMENTO IMPLEMENTAÇÃO DO PROTÓTIPO DE SISTEMA GEDOO Arquitetura do sistema Banco de dados OO Caché Funções do Sistema GEDOO Diagramas ANÁLISE DOS RESULTADOS Armazenamento e recuperação de dados Multimídia Segurança dos dados e compartilhamento Facilidade no desenvolvimento CONCLUSÃO...72 REFERÊNCIAS BIBLIOGRÁFICAS...75 A DIAGRAMA DE CLASSES COMPLETO...78 B DADOS COLETADOS...81 iii

5 LISTA DE ABREVIATURAS API BD BDOO BDOR BLOB CLOB EER GED IDE LOB LPOOs MER MR ODL ODMG OID OML OO OQL SGBD SGBDOO SGBDOR SQL TAD TCC UML UNIVALI XML Application Program Interface Banco de Dados Banco de Dados Orientado a Objetos Banco de Dados Objeto-Relacional Binary Large Object Binary Character Large Object Binary Entidade/Relacionamento Estendido Gerenciamento Eletrônico de Documentos Integrated Development Environment Large Object Binary Linguagem de Programação Orientada a Objetos Modelo Entidade/Relacionamento Modelo Relacional Object Definition Language Object Data Management Group Object Identifier Object Manipulation Language Orientada a Objetos Object Query Language Sistemas Gerenciadores de Bancos de Dados Sistemas Gerenciadores de Banco de Dados Orientado a Objetos Sistemas Gerenciadores de Banco de Dados Objeto-Relacional Structured Query Language Tipo Abstrato de Dado Trabalho de Conclusão de Curso Universal Modeling Language Universidade do Vale do Itajaí Extensible Markup Language iv

6 LISTA DE FIGURAS Figura 1. Comparativo de formas de armazenamento...9 Figura 2. Exemplo de modelo de dados relacional Figura 3. Exemplo de modelo de dados entidade/relacionamento...13 Figura 4. Exemplo de modelo de dados EER...14 Figura 5. Sintaxe para definição de tipos Figura 6. Sintaxe para geração de OIDs...15 Figura 7. Exemplo do uso de referência entre tabelas...16 Figura 8. Sintaxe para definição de métodos para um tipo de dado...17 Figura 9. Sintaxe da definição de método Externo Figura 10. Sintaxe para o uso da Herança de tipos Figura 11. Utilizando OIDs para representar os relacionamentos Figura 12. Modelo de objeto do tipo atom Figura 13. Modelo de objeto do tipo tuple...22 Figura 14. Modelo de objeto do tipo set...23 Figura 15. Sintaxe para assinatura de uma classe Figura 16. Persistência de um objeto pelo mecanismo de nomeação Figura 17. Persistência de um objeto pelo mecanismo de alcançabilidade...26 Figura 18. Declaração de uma classe no padrão ODL Figura 19. Declaração de uma inteface no padrão ODL Figura 20. Herança de comportamento no padrão ODL Figura 21. Herança de estado e comportamento Figura 22. Herança múltipla de uma classe...29 Figura 23. Declaração de atributos...29 Figura 24. Representação de relacionamentos do padrão ODMG Figura 25. Sintaxe da assinatura de um método...30 Figura 26. Modelo de esquema de banco de dados para representação de um esquema ODL...30 Figura 27. Exemplo de utilização da linguagem OQL...31 Figura 28. Exemplo de Expressões de caminho...32 Figura 29. Tela da Ferramenta de desenvolvimento de classes e métodos do Caché Figura 30. Arquitetura do SGBDOO Caché...34 Figura 31. Armazenamento de um objeto persistente Figura 32. Armazenamento de índices...35 Figura 33. Arquitetura BDOO Jasmine...37 Figura 34. Tela da interface de administração do banco de dados Versant Figura 35. Tela da ferramenta Centro de Desenvolvimento do DB Figura 36. Diagrama de atividades do processo de publicação de documento Figura 37. Casos de uso do sistema GEDOO...45 Figura 38. Modelo de objetos do sistema...46 Figura 39. Código da definição do formulário...47 Figura 40. Código do Servlet lstultarq Figura 41. Código do método getarquivosbyarea da classe persistearquivo...48 Figura 42. Diagrama de componentes do sistema GEDOO...49 Figura 43. Método condatabase da classe persistearquivo Figura 44. Método salvaarquivodb2 da classe persistearquivo...50 Figura 45. Exemplo de criação de objeto do banco Caché Figura 46. Criação de uma classe na ferramenta Studio v

7 Figura 47. Exemplo de acesso ao Caché utilizando comandos SQL...55 Figura 48. Tela de autenticação do sistema...56 Figura 49. Tela principal do sistema Figura 50. Tela de submissão de arquivos Figura 51. Tela de confirmação de arquivo salvo Figura 52. Exemplo de código utilizando a biblioteca commons-fileupload...58 Figura 53. Tela de documentos pendentes de aprovação Figura 54. Tela de aprovação de documentos Figura 55. Tela de pesquisa de arquivos Figura 56. Tela do resultado da pesquisa Figura 57. Tela de recuperação do arquivo Figura 58. Tela de alteração de arquivos Pesquisa...61 Figura 59. Tela de alteração de arquivos...62 Figura 60. Diagrama de classes do sistema GEDOO...63 Figura 61. Diagrama de Seqüência de submissão de um arquivo...64 Figura 62. Diagrama de Seqüência da pesquisa de arquivos Figura 63. Diagrama ER do sistema GEDOO...66 Figura 64. Gráfico comparativo entre os tipos de mídia...69 vi

8 LISTA DE TABELAS Tabela 1. Comparativo de Banco de dados OO Tabela 2. Comparativo de Banco de dados Objeto-Relacional...41 Tabela 3. Tabela ARQUIVO...51 Tabela 4. Tabela VERSAO Tabela 5. Atributos da Classe ArqCh...54 Tabela 6. Resultado dos testes efetuados Tabela 7. Média do tempo de armazenamento e recuperação...67 Tabela 8. Média do tempo de armazenamento e recuperação por tipo de arquivos (Bytes/ms)...68 vii

9 RESUMO LEITE, Marcela. Banco de Dados Orientado a Objetos como Ferramenta para Armazenamento e Recuperação de Dados Multimídia. Itajaí, f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação) Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, As informações multimídia estão cada vez mais acessíveis e se tornaram ferramentas importantes em escritórios ou salas de aula. Elas abrangem imagens, sons e documentos, entre outras diversas fontes de hiperlinks que estão disponíveis em meio eletrônico e, entre elas, a Internet. Gerenciar dados multimídia tem se tornado uma grande tarefa para os administradores de sistemas, que encontram problemas de recuperação e compartilhamento dessas informações. Uma opção para o armazenamento de dados multimídia é a utilização de banco de dados orientado a objetos, que, além de possuir suporte a dados complexos, facilitam na persistência dos objetos e desenvolvimento de sistemas orientados a objetos. Com a finalidade de avaliar o BDOO como ferramenta para armazenamento e recuperação de dados multimídia, foi implementado o sistema GEDOO - Gerenciamento Eletrônico de Documentos Orientado a Objetos. Este protótipo de sistema para controle de arquivos multimídia que se comporta como um sistema Ged, foi desenvolvido utilizando a linguagem de programação Java no padrão MVC com suporte para armazenar arquivos em três meios diferentes: disco, banco de dados objeto-relacional e orientado à objetos. Com esse protótipo foi realizada a análise de performance para armazenamento e recuperação dos dados multimídia obtendo-se uma visão da forma mais adequada de armazenamento além da análise aprofundada do desenvolvimento e aplicabilidade de um BDOO. Palavras-chave: BDOO.Armazenamento e Recuperação.Multimídia. viii

10 ABSTRACT Multimedia information is more accessible and became an important tool in offices or classrooms. It encloses images, sounds and documents, among other various sources of hyperlinks that are available in electronic media and, among them, Internet. The management of multimedia data has become a great task for system administrators that deal with difficulties in recovering and sharing this information. An option for multimedia storage data could be the use of an object oriented database that, besides having support for the complex data, eases in the persistence of objects and systems development. With proposal to evaluate the OODB as a tool for storing and recovering multimedia data, the GEDOO Management of Electronic Document Object Oriented system was developed. This controller system of multimedia information prototype, designed behaves as a GED system, was developed using the Java program language in MVC pattern, supporting the storage of files into three different ways: disc, relational object database and object oriented database. Using this prototype, it was analyzed the performance of storing and recovering multimedia data, getting knowledge for a better way of storage, such as a deep analysis of the development and applicability of an OODB. Keywords: OODB. Storage and Recovery. Multimedia ix

11 1 INTRODUÇÃO Os bancos de dados se tornaram ferramentas indispensáveis para o gerenciamento e manutenção de dados. Entretanto, com o passar do tempo surgiu a necessidade de armazenar dados mais complexos, o que tornou os bancos mais complexos também. Os bancos de dados relacionais são utilizados em grande escala na construção de sistemas de informação tradicionais. Entretanto, estes bancos de dados possuem algumas limitações que não atendem a projetos de sistemas como: engenharia e manufatura (CAD/CAM e CIM), experimentos científicos, telecomunicações, sistemas de informações geográficos e multimídia (ELMASRI & NAVATHE, 2005). Os Bancos de Dados Orientados a Objetos (BDOO) foram projetados para atender às necessidades dessas aplicações mais complexas através da utilização de conceitos de classes, encapsulamento, herança e polimorfismo que já existiam nas linguagens Orientada a Objetos (OO), e integram a orientação a objeto com características de bancos de dados relacionais. Através de construções orientadas a objeto, pode ser feito o encapsulamento para proteção das classes sem perder a disponibilidade de compartilhar referências comuns no sistema. E é o banco de dados que garante o compartilhamento destas informações, onde os usuários sempre podem obter o estado atualizado dos objetos e salvar novos estados que ficarão gravados permanentemente no disco rígido (KHOSHAFIAN, 1994). Uma característica chave dos BDOO é o poder dado ao projetista para especificar, além da estrutura do banco, as operações que podem ser aplicadas aos objetos do banco. Um objeto geralmente possui dois componentes: estado (valor) e comportamento (operações). Os objetos em uma linguagem de programação OO existem somente durante a execução do programa e são chamados objetos transientes. Um banco de dados OO pode estender a existência de objetos de modo que sejam armazenados de forma permanente, e isso é conhecido como persistência nos BDOO, onde cada objeto possui um identificador único conhecido como OID (Object Identifier) que é gerado automaticamente pelo próprio banco. O usuário externo não possui acesso a esse identificador, sendo acessado somente pelo banco (ELMASRI & NAVATHE 2005). São cada vez mais comuns aplicações de telecomunicação ou sistemas de processamento de imagens. Esses tipos de dados são conhecidos como Multimídia, que podem ser considerados a combinação de texto, arte gráfica, som, animação e vídeo transmitido pelo computador. Quando o usuário controla quando e quais elementos serão transmitidos, é chamada de multimídia interativa.

12 Outro tipo de multimídia é quando há uma estrutura de elementos vinculados pela qual o usuário pode mover-se. Neste caso, a multimídia interativa passa a ser hipermídia (VAUGHAN, 1994). Alguns bancos de dados suportam o armazenamento de dados de tipos grandes como os BLOBs, que podem armazenar dados multimídia. Embora campos grandes possam ser armazenados em arquivos de sistemas operacionais, armazená-los no banco de dados permite que os dados multimídia sejam compartilhados ao mesmo tempo por muitos usuários sob controle de transação (KHOSHAFIAN, 1994). Os modelos de dados tradicionais encontrados nos bancos de dados relacionais não são adequados para o armazenamento de informações multimídia, pois não possuem recursos para suportá-los. Para resolver essa necessidade, são utilizados os BDOO que possuem suporte a esse tipo de dado. Neste trabalho foi desenvolvido um estudo aprofundado sobre os BDOOs, aplicando os conceitos aprendidos em um protótipo de aplicação para armazenamento e recuperação de dados multimídia, analisando o desempenho e a funcionalidade do banco, tanto em nível de programação, quanto em nível de persistência de objetos. Segundo Ricarte (1998): As necessidades dessas novas categorias de aplicações constituem a maior motivação para o surgimento de novas abordagens para o gerenciamento de dados.. Ricarte apresenta em sua tese uma proposta de solucionar o problema de armazenamento de dados multimídia e automação de escritório através da utilização de BDOO. Borba e Morales (2006) apresentam uma proposta de modelagem de dados multidimensional utilizando BDOO, os quais descrevem as vantagens na utilização de um banco de dados puramente orientado a objeto. Segundo sua pesquisa, através da utilização do modelo de dados OO, não é mais necessário reescrever a modelagem do sistema OO para o modelo MER, com a finalidade de criar a base de dados, pois, com a utilização do BDOO, o modelo de dados passará a ser o mesmo para o programa e para a base de dados (BORBA & MORALES, 2006). Silva (2006) apresenta em sua tese, uma análise sobre o desempenho de BDOO na recuperação de dados multimídia utilizando o Banco de Dados Objeto-Relacional (BDOR) PostgreSQL. Ele demonstra que os resultados na utilização de objetos para armazenamento de dados multimídia não foram satisfatórios, obtendo uma perda de performance e que a utilização de OIDs apresentou o pior tempo de recuperação para os dados armazenados. No presente trabalho foi elaborado um comparativo entre salvar dados multimídia em disco e em banco de dados, sendo que foram utilizados dois tipos de banco de dados: Objeto-Relacional e o Orientado a Objetos, com o intuito de avaliar a melhor formar de persistir dados multimídia em 2

13 termos de performance, facilidade no desenvolvimento e segurança da informação armazenada. Para isso foi elaborada uma pesquisa sobre as ferramentas de SGBD disponíveis no mercado, buscando melhor opção para utilização no desenvolvimento do sistema proposto, além de considerar aspectos como: suporte a linguagens de programação conhecidas, interface gráfica, documentação, desempenho, entre outros. 1.1 PROBLEMATIZAÇÃO Formulação do Problema Com o avanço das tecnologias de informação que permitem disponibilizar qualquer tipo de dados nos computadores de forma digital e na Internet, pode-se acessar qualquer informação de qualquer lugar. Tais informações (imagens, áudio ou vídeo) são consideradas Multimídias, não apenas por serem digitais, mas por serem informações interativas. Apesar do aumento da utilização da informação Multimídia, a forma de armazenamento e recuperação desses dados continua sendo feita diretamente em disco físico, utilizando os bancos de dados relacionais como forma de descrever e organizar esses, para que possam ser localizados no arquivo físico, como forma de indexação. Devido a esse avanço na utilização de sistemas de multimídia, os fornecedores de SGBDs relacionais incrementaram suas ferramentas com suporte a objetos multimídia através de campos grandes como Blobs. Mesmo com essa tecnologia, os BDOR não são os mais adequados para o armazenamento de objetos. Muitas pesquisas apontam para a utilização de SGBDOOs para o armazenamento e gerenciamento das informações Multimídia, sendo esse o alvo desta pesquisa Solução Proposta Através da criação de um sistema Gerenciador de Documento Eletrônico (GED) essa pesquisa buscou analisar o desempenho e funcionamento dos bancos de dados orientados a objetos para o armazenamento e gerenciamento dos dados Multimídia. Essa ferramenta possibilitou a gravação, recuperação e gerenciamento de documentos, textos e imagens através de uma interface web conectada a um banco de dados. 3

14 1.2 OBJETIVOS Objetivo Geral O objetivo desse trabalho é investigar as funcionalidades dos Sistemas de BDOOs como ferramenta para armazenamento e recuperação de dados Multimídia e avaliar soluções e recursos disponíveis no mercado para este tipo de dado Objetivos Específicos Analisar e investigar a arquitetura e funcionamentos dos BDOO; Estudar a modelagem de dados em sistemas de DBOO; Analisar as ferramentas disponíveis no mercado; Pesquisar e analisar aplicações de multimídia; Realizar a modelagem do protótipo da aplicação de armazenamento e recuperação de dados multimídia; Implementar um protótipo; Testar e validar a implementação do protótipo; Avaliar o desempenho e funcionalidade do BDOO aplicado a dados multimídia; Analisar a funcionalidade e performance do sistema utilizando outro BDOO para comparativo das ferramentas; e Documentar a pesquisa e os resultados obtidos com a implementação do protótipo. 1.3 Metodologia A metodologia utilizada na primeira fase desse projeto abrangeu quatro etapas. Na primeira etapa realizou-se uma pesquisa e análise sobre dados Multimídia, BDOO e BDOR. Nas duas etapas seguintes, foi realizada a uma pesquisa e análise sobre ferramentas de bancos de dados disponíveis no mercado. Na última etapa foi realizada a modelagem da ferramenta GED que servirá para a análise da performance dos bancos de dados selecionados. 4

15 1.4 Estrutura do trabalho Esse trabalho está estruturado em quatro capítulos: Introdução, Fundamentação Teórica, Projeto e Considerações Finais. O Capítulo 1, Introdução, apresenta uma visão geral do projeto, onde é possível ter uma visão geral da pesquisa realizada e dos objetivos que se desejam alcançar. No Capítulo 2, Fundamentação Teórica, é apresentada uma revisão bibliográfica sobre os assuntos envolvidos no projeto: Dados Multimídia, GED, BDOR e BDOO e ferramentas de bancos de dados disponíveis no mercado selecionadas para o projeto. O Capítulo 3, Desenvolvimento, explica como a ferramenta de GEDOO foi desenvolvida e suas características e também apresenta a análise dos resultados obtidos. O Capítulo 4, Conclusão, finaliza o trabalho apresentando as conclusões finais, bem como as sugestões de trabalhos futuros. 5

16 2 FUNDAMENTAÇÃO TEÓRICA Este capítulo apresenta um estudo elaborado através de livros, artigos, internet e revistas, sobre o tema abordado no projeto, e algumas ferramentas de Sistemas Gerenciadores de Banco de Dados Orientado a Objetos (SGBDOO) e Sistemas Gerenciadores de Banco de Dados Objeto- Relacional (SGBDOR) estudadas. Com o intuito de aperfeiçoar o conhecimento sobre o assunto, dando assim, uma base melhor para a elaboração dos requisitos do protótipo do sistema que será desenvolvido e auxiliando na obtenção dos resultados desejados. 2.1 Dados Multimídia Segundo Silva (2006), multimídia compreende os vários tipos de mídias existente tais como imagens, sons, vídeos, textos e hiperlinks. Ele classifica a multimídia nas seguintes categorias: Mídia de Percepção: É o formato das informações que são apresentas aos usuários. A imagem, o som e o texto são exemplos desse tipo de mídia. Elas são classificadas em contínuas e não contínuas. As contínuas são dependentes do tempo. O som e o vídeo são classificados como contínuas. As mídias não contínuas independem do tempo. A imagem é classificada como uma mídia de percepção não contínua; Mídia de Representação: É referente à forma como os dados são armazenados. A mídia de percepção imagem pode ser representada nos formatos GIF, JPEG, BMP, entre outros; Mídia de Apresentação: Representa a forma como as mídias serão apresentadas aos usuários como monitores, caixas de som e impressoras, os quais promovem a saída de dados e informação, e os teclados, mouse e scanners, que promovem a entrada de dados, são mídias de apresentação; Mídia de Armazenamento: Compreende os dispositivos que armazenam dos dados multimídia como discos rígidos, CD s e DVD s; Mídia de Transmissão: Referente à forma como os dados são transmitidos a outros usuários. As redes de computadores são consideradas mídias de transmissão. Silva (2006) classifica como os principais tipos de dados multimídia os seguintes itens:

17 Texto: Essa mídia é formada por cadeia de caracteres, sendo umas das mídias mais utilizadas. Pode servir também como indexador para outros tipos de mídias na forma de metadados; Imagem: São desenhos ou fotografias digitalizadas em um formato de bitmap ou um formato compactado como JPG. O formato compactado utiliza técnicas matemáticas para diminuir o tamanho da imagem sem perder a sua resolução; Vídeo: São formados por conjuntos de imagens disponibilizados em um espaço temporal. Cada imagem do conjunto é conhecida como frame, que são imagens estáticas. Na execução do vídeo, os frames são exibidos em um intervalo de tempo fixo, o que define a qualidade do vídeo. Quanto mais frames por segundo, melhor será sua qualidade; Áudio: É composto por gravações de sinais sonoros captados através de microfones. Esses sinais podem sem enviados para os computadores, onde são convertidos em uma cadeia de bits, formando assim o áudio digital. 2.2 Armazenamento e Recuperação de dados Multimídia Os bancos de dados Multimídia compreendem o armazenamento e consulta de tipos diferentes de informação como imagens, vídeos, gravações ou documentos (ELMASRI & NAVATHE, 2005). Para consultar esses objetos, é necessário utilizar técnicas de recuperação baseada em conteúdo, porque a fonte multimídia está sendo recuperada com base em certo objeto ou característica. Para isso, é necessário utilizar algum modelo para organizar e indexar as fontes multimídias segundo seus conteúdos (ELMASRI & NAVATHE, 2005). A identificação dos conteúdos de fontes é considerada uma tarefa difícil e demorada. Neste sentido, segundo Elmasri e Navathe (2005), há duas abordagens principais: Através das características matemáticas de seus conteúdos é feito a análise automática das fontes multimídia para consultar um objeto. Essa abordagem emprega diferentes técnicas que dependem do tipo da fonte multimídia (imagem, texto, vídeo ou áudio); e 7

18 Utilização de metadados, onde é feito a identificação manual dos objetos e suas características em cada fonte multimídia, utilizando essa informação para indexar os objetos. Essa técnica pode ser aplicada a todos os diferentes tipos de multimídias, porém, é necessário que uma pessoa examine cada fonte multimídia para identificar e catalogar os objetos e suas características, dessa forma esses metadados poderão ser utilizados para indexação dos objetos. Para Elmasri e Navathe (2005), o armazenamento de dados multimídia em dispositivos físicos apresenta problemas de representação, compressão, mapeamento de hierarquias de dispositivos, arquivamento e buffering durante as operações de entrada e saída. A recuperação de informações em banco de dados está baseada em linguagens de consulta e em estruturas internas de índices. As consultas ao banco de dados utilizam estes índices para recuperação das informações. Para os dados multimídia, isso representa um problema quanto à formulação eficiente de consultas, sua execução e otimização. O problema de indexação não é tão agravante quando se trata de apenas documentos e textos, porém, para aplicações que envolvem reprodução de vídeo ou sincronização de áudio e vídeo, as limitações físicas predominam (ELMASRI & NAVATHE, 2005). Para sistemas de armazenamento de documentos e textos como sistemas de bibliotecas ou sistemas de GED, é fundamental uma eficiente recuperação de textos. Elmasri e Navathe (2005) demonstram as seguintes técnicas utilizadas para recuperação de documentos e textos: Indexação de frase: Utiliza descritores de frase múltiplas palavras (em vez de termos de índice de palavra única) são atribuídas aos documentos e usadas nas consultas; Uso de Thesaurus (dicionário ou enciclopédia): Serve para expandir o vocabulário de consultas utilizado para indexar os documentos; Resolução de Ambigüidade: Uma das razões para a baixa precisão em sistemas de recuperação de informação de texto é que as palavras possuem múltiplos significados. Para isso é necessário analisar o contexto que a palavra está inserida através do uso de dicionários e ontologias. 8

19 Para a indexação de imagens podem ser utilizadas técnicas de processamento de imagens ou metadados associados às imagens. A técnica de processamento de imagem requer um grande processamento e tempo para localizar uma imagem, o que limita sua utilização a padrões de busca simples. Segundo Silva (2006), os sistemas orientados a objetos são a alternativa de armazenamento mais adequada. Porém, as mídias contínuas ainda permanecem com o problema da falta de gerenciamento de acesso em tempo real. Na Figura 1, Silva (2006) apresenta um quadro comparativo entre as formas de armazenamento de dados Multimídia disponíveis atualmente, onde pode-se perceber que a forma mais adequada de armazenamento são os SGBDOO, porém limitando o acesso em tempo real aos dados. Figura 1. Comparativo de formas de armazenamento. Fonte: Silva (2006). 2.3 Gerenciamento Eletrônico de Documentos Os documentos são um elemento fundamental em todas as organizações, por registrarem informações, decisões e atividades por elas executadas (SADIQ, 1997 apud FANTINI, 2001). Segundo Fantini (2001), um documento é um conjunto de informações que agrega dados estruturados, semi-estruturados e não-estruturados e que representam o conhecimento produzido ao longo de um processo da organização. 9

20 A fim de cumprir normas impostas para a certificação de qualidade ISO 9001, muitas empresas passaram a adotar sistemas de gerenciamento eletrônico de documentos, pois estes permitem ter um total controle sobre os principais documentos e processos da empresa, além de possibilitar o controle de versões e cópias controladas (FANTINI, 2001). Os sistemas de GED buscam preservar as características visuais e espaciais, e a aparência do documento original em papel. Estes sistemas gerenciam toda a vida das informações desde sua criação até o arquivamento, e suas várias versões, além de sua localização física e digital (FANTINI, 2001). Fantini (2001) afirma ainda que os sistemas de GED são a melhor forma de tornar documentos disponíveis de forma eficiente para os usuários, permitindo sua recuperação e armazenamento seguro. A localização dos documentos é feita através da atribuição de múltiplos índices eletrônicos que permitem a recuperação mais rápida dos dados. 2.4 Banco de Dados Objeto-Relacional Os Bancos de Dados surgiram a partir da necessidade de armazenar uma grande quantidade de dados de forma permanente e de fácil acesso, junto com a possibilidade de armazenar esses dados em um computador. Os bancos de dados tiveram surgimento a partir dos anos 60 com a difusão dos meios magnéticos. A partir da existência dos bancos de dados surgiram os SGBDs que fornecem um conjunto de ferramentas para acesso e manipulação dos bancos de dados (NASSU & SETZER, 1999). Os sistemas de bancos de dados são projetados para gerenciar grandes blocos de dados, isto envolve desde a definição de suas estruturas aos mecanismos para manipulação destas estruturas. (SILBERSCHATZ; KORTH & SUDARSHAN, 2006). As estruturas de um banco de dados são descritas através de Modelos de Dados, que são constituídos por uma coleção de ferramentas para descrever dados, suas relações, semântica dos dados e restrições de consistência (SILBERSCHATZ; KORTH & SUDARSHAN, 2006). Segundo Edelweiss e Galante (2005), com o surgimento do modelo de dados orientado a objetos, havia uma expectativa de que estes dominariam o mercado, porém, não houve grandes avanços de ferramentas de SGBDs. Com isso, os bancos relacionais continuaram a dominar o 10

21 mercado, onde sofreram variações para atender as novas necessidades de suporte a tipos dados complexos. Os bancos de dados relacionais passaram a incorporar os conceitos de orientação a objeto, unindo os recursos avançados de orientação a objeto com a alta performance e eficiência dos bancos de dados relacionais (EDELWEISS & GALANTE, 2005). A SQL (Structured Query Language) foi criada nos anos 70 e passou por melhorias em 1989 e A linguagem continuou sua evolução até um novo padrão denominado SQL3, o qual acrescentou a orientação a objetos além de outras características, sendo essa versão conhecida como SQL99 (ELMASRI & NAVATHE, 2005). A seguir são apresentados alguns conceitos de modelo de dados, BDOR, suas principais características, SQL99 e armazenamento de dados em BDOR Modelo Relacional (MR) O Modelo Relacional (MR) utiliza um conjunto de tabelas para representar os dados e as relações entre eles. Ele é baseado em registros onde cada tabela possui colunas identificadas por um nome único e formatos fixos. Cada tabela contém registros de um tipo específico, onde estes definem um número fixo de campos ou atributos (SILBERSCHATZ; KORTH & SUDARSHAN, 2006). Segundo Silberschatz; Korth e Sudarshan (2006), existe uma correspondência entre o conceito de tabela e o conceito matemático de relação, de onde vem o nome de modelo de dados relacional. Neste modelo de dados, cada coluna representa um atributo, o qual possui um domínio. O domínio representa um conjunto de valores aceitos para cada tipo de atributo da tabela. No MR a relação do conjunto de dados é representada por um produto cartesiano de uma lista de domínios (SILBERSCHATZ; KORTH & SUDARSHAN, 2006). Na Figura 2 é apresentado um exemplo de modelo de dados relacional. 11

22 Figura 2. Exemplo de modelo de dados relacional. Fonte: Adaptado de Silberschatz; Korth e Sudarshan (2006) Modelo de Entidade/Relacionamento (MER) O Modelo Entidade-Relacionamento (MER) é baseado nos objetos do mundo real e suas relações, onde os objetos são representados por entidades e suas relações. Ele é muito utilizado para mapear processos em uma empresa, empregando três noções básicas: conjunto de entidades, conjunto de relacionamentos e atributos (SILBERSCHATZ; KORTH & SUDARSHAN, 2006). A seguir é apresentado o conceito de cada conjunto desses. Uma entidade é a representação de um ser do mundo real distinto de todos os outros seres existentes. Cada entidade possui um conjunto de propriedades, e os valores para algum conjunto de propriedades podem as identificar de maneira única. Estas podem ser classificadas como concretas ou abstratas. Um conjunto de entidades é formado por entidades do mesmo tipo e com as mesmas propriedades, sendo representada por um conjunto de atributos (SILBERSCHATZ; KORTH & SUDARSHAN, 2006). Atributos são representações das características das entidades. Cada entidade possui um valor para cada um de seus atributos. Para cada atributo existe um conjunto de valores permitidos, chamado de domínio, ou o conjunto de valores desse atributo. Os atributos podem ser simples ou compostos e possuir um valor único ou múltiplos valores (SILBERSCHATZ; KORTH & SUDARSHAN, 2006). Um relacionamento é uma associação entre várias entidades, onde relacionamentos do mesmo tipo constituem um conjunto de relacionamentos. A associação entre conjuntos de entidades 12

23 é denominada participação. Em um diagrama MER, os relacionamentos representam a associação que existe entre os seres reais que estão sendo modelados. Na Figura 3 é apresentado um exemplo de modelo de dados entidade/relacionamento: Figura 3. Exemplo de modelo de dados entidade/relacionamento. Fonte: Adaptado de Silberschatz; Korth e Sudarshan (2006). Com o avanço tecnológico, surgiu a necessidade de armazenar tipos de dados não suportados pelos modelos de dados tradicionais. Essa necessidade impulsionou a criação de modelos de dados voltados a objetos, que adquiriu mais força com o avanço das linguagens de programação orientada a objetos (ELMASRI & NAVATHE 2005). Segundo Ramakrishnan (2003 apud EDELWEISS & GALANTE, 2005) os sistemas orientados a objetos podem ser abordados de duas formas: SGBDOs e SGBDROs Modelo de dados EER - ER Estendido Funciona como uma extensão do MER com noções de encapsulamento, métodos e identidade de objeto (SILBERSCHATZ; KORTH & SUDARSHAN, 2006). A modelagem de dados baseados em objetos é também conhecida como Entidade/Relacionamento Estendido (EER). A modelagem EER une os conceitos da modelagem ER com as definições da UML (Universal Modeling Language). A modelagem do banco passa a ser feita da mesma forma que a aplicação é projetada, englobando conceitos de classe, herança, polimorfismo e especialização (ELMASRI & NAVATHE 2005). Na Figura 4 é apresentado um exemplo de modelo de dados EER. 13

24 Figura 4. Exemplo de modelo de dados EER. Fonte: Adaptado de Elmasri e Navathe (2005). O modelo de dados relacional-objeto possui todas as características de um modelo orientado a objetos, porém, fisicamente sua implementação é feita através de tabelas, ou seja, como um modelo relacional. A semântica da aplicação é modelada e representada através de objetos, enquanto sua implementação física é feita na forma relacional (EDELWEISS & GALANTE, 2005) SQL99 com suporte a OO Foram adicionados vários recursos ao padrão SQL para que este dê suporte aos BDROs. Entre esses inclui-se o tipo row (linha), conceito conhecido como relações aninhadas. Também é fornecido um tipo array (vetor) para representar coleções. A SQL99 inclui um mecanismo para especificar identidade de objetos por meio do uso de tipo referência. O encapsulamento de operações é possível por mecanismos de tipos definidos pelo usuário que podem incluir operações como parte de suas declarações, além de serem disponibilizados mecanismos de herança (ELMASRI & NAVATHE 2005) Relações Aninhadas Para os bancos de dados relacionais os atributos são constituídos por unidades indivisíveis, onde dizemos que seus domínios são atômicos (ELMASRI & NAVATHE 2005). 14

25 Para armazenar dados que representem a realidade de uma forma mais natural, estes precisam ser armazenados como um conjunto de objetos, pois não é possível representar um determinado objeto do mundo real através de somente um registro, sendo necessários vários registros para sua representação, dessa forma dando ao usuário acesso a este banco de dados através dos objetos, sem tomar conhecimento de sua implementação física (EDELWEISS & GALANTE, 2005). Através da SQL99, esse comportamento é tratado através de construtores de tipos de dados definidos pelos usuários como os rows e arrays (ELMASRI & NAVATHE, 2005). Na Figura 5 é apresentada a sintaxe para definição de um tipo de dado row. Figura 5. Sintaxe para definição de tipos. Fonte: Adaptado de Elmasri e Navathe (2005) Identificadores de Objetos e Referências No modelo objeto-relacional, um atributo pode referenciar diretamente um outro objeto. O domínio deste tipo de atributo consiste em um ponteiro lógico para um objeto de um determinado tipo. Desta forma são modelados relacionamentos de associação entre objetos. Somente pode ser referenciada uma tabela que tenha definido um OID (EDELWEISS & GALANTE, 2005). Segundo Elmasri e Navathe (2005) os OIDs são códigos únicos para cada objeto, controlados pelo banco de dados, estes não são visíveis aos usuários, podendo ser gerados pelo banco de dados (SYSTEM GENERATED) ou pelo usuário (USER GENERATED). Eles são criados através do uso da sintaxe apresentado na Figura 6. Figura 6. Sintaxe para geração de OIDs. Fonte: Adaptado de Elmasri e Navathe (2005). 15

26 Em um BDOR, o identificador de um objeto é o valor indicado pelos atributos de referência. Pode ser definido pelo usuário ou pelo sistema, e constituir uma chave primária (EDELWEISS & GALANTE, 2005). Um atributo componente de uma tupla pode ser uma referência a uma tupla de outra tabela ou até mesmo à mesma tabela (ELMASRI & NAVATHE, 2005). Na Figura 7 é apresentado um exemplo de uso de referência entre tabelas. Figura 7. Exemplo do uso de referência entre tabelas. Fonte: Adaptado de Edelweiss e Galante (2005). A utilização de referências não se assemelha a uma chave estrangeira chaves estrangeiras podem ser compostas. O modelo objeto-relacional não permite a definição de chaves estrangeiras (EDELWEISS & GALANTE, 2005). Para referenciar um mesmo tipo para mais de uma tabela, é necessário identificar de qual a tabela que se quer referenciar, ou seja, é necessária a definição do escopo da referência. Para isso é utilizada a cláusula "scope" no momento da definição de uma tabela com o tipo que contém algum atributo do tipo referência. Esta cláusula somente é necessária no caso de existirem duas ou mais tabelas do tipo referenciado (EDELWEISS & GALANTE, 2005). A manipulação de tabelas que contém atributos do tipo referência deve ser feita acessando diretamente os objetos referenciados. Para se obter a linha apontada por uma referência é usado o apontador de referência (EDELWEISS & GALANTE, 2005) Encapsulamento O modelo objeto-relacional permite ao usuário a definição de funções e procedimentos para representar os métodos dos objetos. A SQL99 fornece uma estrutura semelhante à definição de classes para a manipulação de código de programa através de três formas diferentes: métodos, funções e procedimentos (EDELWEISS & GALANTE, 2005). 16

27 Segundo Elmasri e Navathe (2005), um tipo de dado definido pelo usuário pode possuir métodos também definidos pelo usuário. Na Figura 8 é apresentada a sintaxe para definição de um método em um determinado tipo de dado. Figura 8. Sintaxe para definição de métodos para um tipo de dado. Fonte: Adaptado de Elmasri e Navathe (2005). O método será implementado separadamente. Este pode ser de dois tipos: interno ou externo à SQL. As funções internas são escritas utilizando a própria SQL, já as funções externas são escritas em uma linguagem hospedeira, onde somente sua estrutura aparece na definição do tipo de dado (ELMASRI & NAVATHE, 2005) que pode ser visualizado na Figura 9. Figura 9. Sintaxe da definição de método Externo. Fonte: Adaptado de Elmasri e Navathe (2005). Em alguns SGBDORs é possível definir um pacote (package) de Tipos Abstratos de Dados (TAD). Estes funcionam como bibliotecas para implementações e são comprados separadamente dos SGBDORs (ELMASRI & NAVATHE, 2005) Herança Para a orientação a objetos é indispensável a utilização de conceitos de herança. O modelo objeto-relacional suporta somente herança simples, não contemplando a herança múltipla. Na SQL99 a herança é representada através da cláusula UNDER. Ela está presente no nível dos tipos e no das classes (EDELWEISS & GALANTE, 2005). A herança de tipos é representada através de relacionamentos supertipo/subtipo, onde a ordem dos supertipos na cláusula UNDER determina a hierarquia de herança (ELMASRI & NAVATHE, 2005). A sintaxe do comando é apresentada na Figura

28 Figura 10. Sintaxe para o uso da Herança de tipos. Fonte: Adaptado de Elmasri e Navathe (2005). O supertipo identifica os atributos da classe herdada e o subtipo identifica os atributos da subclasse criada. Na herança de tipos, todos os atributos são herdados e uma instância de um subtipo pode ser utilizada em todos os contextos em que é utilizada uma instância do supertipo (ELMASRI & NAVATHE, 2005). A sobrecarga de funções também é implementada nos BDOR, onde um subtipo pode redefinir qualquer função que é definida em seu supertipo, com a restrição de que a assinatura deve ser a mesma. Assim, quando uma função é chamada, a melhor combinação é selecionada com base nos tipos de todos os argumentos (ELMASRI & NAVATHE, 2005). A herança de classes é representada pela herança entre tabelas, ou seja, a definição de subtabelas/supertabelas. Uma subtabela herda todas as colunas de sua supertabela e toda linha de uma subtabela corresponde a uma, e somente uma, linha na supertabela, cada linha de uma supertabela corresponde a pelo menos uma linha em uma subtabela (ELMASRI & NAVATHE, 2005). Para aumentar a eficiência do banco de dados, podem ser implementados diferentes formas de armazenamento. A forma natural é a de armazenar os atributos comuns, herdados pelas subtabelas, somente na tabela da superclasse. Nas subclasses são armazenados somente os atributos específicos de cada uma delas. Entretanto, para melhorar a eficiência, podem ser replicados os atributos herdados nas subclasses, facilitando desta forma as consultas, pois todos os atributos da subclasse seriam encontrados na mesma (tanto os herdados como os específicos) (EDELWEISS & GALANTE, 2005) Objetos Complexos em SQL O suporte ao armazenamento de dados grandes, como imagens e arquivos de textos, atendendo aplicações como de multimídia, requerem que grandes objetos complexos possam ser utilizados na modelagem. Isto é atendido pelo modelo objeto-relacional ao permitir a definição de objetos longos. Estes são tratados como um único objeto, sendo representados diretamente no banco 18

29 de dados, integrados aos outros dados, e não em arquivos separados (EDELWEISS & GALANTE, 2005). A SQL possui tipos de dados para objetos grandes conhecidos como LOBs (large objects binary) e para localizadores de objetos longos. Existem duas variações, os objetos binários longos ou BLOBs (binary large objects binary) e os objetos de texto longo ou CLOBs (character large objects binary). A SQL99 propõe a manipulação de LOBs internamente ao SGBD sem ter de utilizar arquivos externos. Alguns operadores não são aplicáveis a atributos valorados-lobs por exemplo, comparações aritméticas, group by ou order by. Entretanto, a recuperação parcial do valor, a comparação (Like), a concatenação, a subcadeia, a posição e o tamanho são operações que podem ser aplicadas a LOBs (ELMASRI & NAVATHE, 2005). 2.5 Bancos de Dados Orientados a Objetos Um Banco de Dados Orientado a Objetos (BDOO) é um sistema em que a unidade de armazenamento é o objeto, incorporando todos os conceitos das linguagens de programação orientadas a objeto, onde a diferença está na persistência dos objetos, os quais continuam a existir mesmo após o encerramento do programa (NASSU & SETZER, 1999). Os BDOOs têm sido desenvolvidos para aplicações dinâmicas que manuseiam objetos estruturados grandes e complexos, os quais apresentam modificações tanto no seu valor quanto em sua estrutura. A necessidade de características adicionais na modelagem dos dados voltados a orientação a objetos, que são incorporadas aos BDORs, também apontam para a crescente demanda por sistemas que suportem tipos de dados complexos (ELMASRI & NAVATHE, 2005). O crescente uso de linguagens de programação orientadas a objetos também impulsionam a criação e utilização dos BDOOs devido ao fato de que os BDOOs são projetados para integrar diretamente software desenvolvido em linguagem de programação orientada a objetos (ELMASRI & NAVATHE, 2005). À medida que os SGBDOOs tornaram-se disponíveis, sentiu-se a necessidade de um modelo e uma linguagem padrão. Um consórcio de fornecedores e usuários de SGBDOOs, denominado ODMG (Object Database Management Group) propôs um padrão conhecido como ODMG-93 (ELMASRI & NAVATHE, 2005). 19

30 A seguir são apresentados os conceitos do modelo de dados orientado a objetos e os padrões para a modelagem dos dados através do padrão ODMG Modelo de Dados Orientado a Objetos Um modelo de dados orientado a objetos é um conjunto de conceitos para modelagem de dados que se assemelha ao funcionamento do mundo real. A modelagem de dados para BDOO pode ser feita utilizando conceitos da UML (ELMASRI & NAVATHE, 2005). Seu modelo permite o uso de atributos multi-valorados conhecidos como sets (conjuntos) ou bags (multi-conjuntos). Esta propriedade é essencial para a representação de relacionamentos do tipo muito em banco de dados puramente OO (HARRINGTON, 2000). Para criar um relacionamento um-para-muitos, por exemplo, deve-se definir um atributo na classe destino do relacionamento (muitos) do tipo set que conterá os OIDs das classes de origem (um) (HARRINGTON, 2000). Os relacionamentos muitos-para-muitos são diretamente representados através dos atributos do tipo bag que são multi-valorados. Para representá-los, pode ser criado um atributo em cada classe que faz parte do relacionamento para armazenar os OIDs das outras classes relacionadas, porém, pode acarretar na perda de informação. O meio mais abrangente e elegante é representar o relacionamento muitos-para-muitos através da criação de uma terceira classe que conectará os objetos relacionados através de tipos de dados bag, armazenando os OIDs dos objetos relacionados (HARRINGTON, 2000). A seguir são apresentados os principais conceitos envolvidos na modelagem dos dados nos BDOOs Identidade do Objeto Os sistemas de BDOO oferecem um identificador de objeto único conhecido como OID (Object Identifier) para cada objeto armazenado. Esse OID é gerado pelo sistema e seu valor não é visível pelo usuário externo. O valor do OID jamais é alterado no banco de dados OO e não pode ser atribuído a outro objeto, garantindo assim uma identidade única para cada objeto (ELMASRI & NAVATHE, 2005). 20

31 No início da utilização do modelo de dados OO criava-se um OID para cada valor existente no banco, dando a possibilidade de dois objetos distintos utilizarem o mesmo valor para fins diferentes. Percebeu-se que esse modelo não era muito prático pelo número de OIDs gerados no sistema, então adaptou-se o modelo onde cada objeto possui um OID e seus valores, e estes valores não podem ser utilizados por outro objeto (ELMASRI & NAVATHE, 2005). O OID é a propriedade que o objeto tem que o distingue dos demais, sendo a base para a implementação de referências entre objetos, pois nos BDOOs não existe a entidade relacionamento como nos bancos de dados relacionais (HARRINGTON, 2000). Na Figura 11 é apresentado um modelo de dados que representa o relacionamento entre objetos criado pela referência a os OIDs de outros objetos. Figura 11. Utilizando OIDs para representar os relacionamentos. Fonte: Adaptado de Harrington (2000). O valor de um OID, além de ser gerado pelo próprio banco de dados, também pode assumir um valor relacionado com sua localização física no arquivo do banco de dados, como o número da página e um ponteiro para o início da página do arquivo no qual o objeto está armazenado (HARRINGTON, 2000). 21

32 Esta técnica de armazenar informações da localização física do objeto em seu OID é utilizada por alguns sistemas para melhorar a performance na recuperação dos dados. Nesse caso, se o endereço físico do objeto for alterado, é referenciado o novo endereço do objeto no endereço antigo através do uso de ponteiros (ELMASRI & NAVATHE, 2005) Estrutura do Objeto Um objeto em um banco de dados OO é constituído de três atributos (i,c,v), onde i é o OID do objeto, c representa o construtor do objeto onde é definido o seu tipo, e v é o valor atual do objeto. Os construtores podem ser dos seguintes tipos: atom (atômico), tuple (tupla), set (conjunto), list (lista), bag (multi-conjunto) e array (vetor) (ELMASRI & NAVATHE, 2005). Os atoms representam valores básicos como inteiros, números reais, cadeias de caracteres, etc. (ELMASRI & NAVATHE, 2005). Na Figura 12 é apresentado um modelo de objeto do tipo atom. Figura 12. Modelo de objeto do tipo atom. Fonte: Adaptado de Elmasri e Navathe (2005). O tuple corresponde a um Struct da programação OO, sendo considerado um tipo estruturado. O tuple é uma estrutura de dois componentes: o nome de uma variável e o OID do objeto que representa essa variável (ELMASRI & NAVATHE, 2005), sendo apresentado um exemplo de sua construção na Figura 13. Figura 13. Modelo de objeto do tipo tuple. Fonte: Adaptado de Elmasri e Navathe (2005). Os tipos array, list, set e bag são tipos de coleções que armazenam um conjunto de OIDs que referenciam outros objetos. Os arrays representam um vetor que armazena OIDs de outros 22

33 objetos, enquanto que o list armazena uma lista ordenada de OIDs. A diferença entre array e list é que uma lista pode conter um número não definido de elementos, enquanto em um array é definido o tamanho máximo (ELMASRI & NAVATHE, 2005). O set funciona semelhante ao array e list, ele armazena um conjunto de OIDs que possuem o mesmo tipo. O bag possui o mesmo princípio, porém, todos os elementos de um set devem ser distintos, enquanto em um bag os elementos podem estar duplicados (ELMASRI & NAVATHE, 2005). Na Figura 14 é apresentado um modelo de estrutura do tipo set. Figura 14. Modelo de objeto do tipo set. Fonte: Adaptado de Elmasri e Navathe (2005) Objetos Complexos Estruturas de objetos constituídos por outros objetos são considerados objetos complexos. O relacionamento de um objeto complexo e seus objetos constituintes pode ser de duas formas. Ele pode utilizar a semântica de propriedade, onde os subobjetos de um objeto complexo são encapsulados dentro de um objeto complexo, sendo considerados como parte do objeto complexo, ou eles podem utilizar a semântica de referência, onde os componentes do objeto complexo são objetos independentes, mas podem ser referenciados a partir do objeto complexo (ELMASRI & NAVATHE, 2005) Versões de Objetos Os BDOOs oferecem recursos para manter várias versões de um mesmo objeto com a finalidade de facilitar a revisão e fusão de alterações em objetos. Com este recurso é possível que dois usuários façam alterações em um determinado objeto ao mesmo tempo, cada um irá gerar uma versão nova. Quando o banco de dados unir essas versões, irá criar uma terceira versão com o resultado das alterações que poderá ser revisado sem perder as versões antigas (ELMASRI & NAVATHE, 2005). 23

34 Classes Uma classe define um modelo de estrutura de um grupo de objetos com comportamento e atributos semelhantes. Através do uso de classes pode-se definir um padrão de estrutura que pode ser utilizado para criar novos objetos do mesmo tipo. Estes possuem os mesmos métodos e atributos, porém com valores distintos (HARRINGTON, 2000). Segundo Harrington (2000) uma classe pode ser de três tipos: Classes de controle: são classes utilizadas para o controle operacional dos programas. Os objetos criados a partir de uma classe de controle são responsáveis por gerenciar a execução dos aplicativos, chamando os processos internos do aplicativo de acordo com a interação dos usuários com o sistema e enviando as resposta para a interface da execução dos processos internos; Classes de Entidade: as classes de entidade são responsáveis pelos dados armazenados. Elas representam as entidades do mundo real e seus relacionamentos; e Classes de Interface: controlam as entradas e saídas do aplicativo. Os objetos criados para interface com o usuário ou outros aplicativos são da classe de Interface Encapsulamento Assim como nas Linguagens de Programação Orientada a Objetos (LPOO), o encapsulamento através do uso de métodos e funções faz parte da modelagem e implementação dos objetos do BDOO. A estrutura de um objeto é dividida em atributos visíveis e ocultos. Os atributos visíveis podem ser acessados por mecanismos externos, enquanto os atributos ocultos somente podem ser acessados através do uso dos métodos do objeto (ELMASRI & NAVATHE, 2005). Nos BDOOs uma classe é constituída da definição do tipo do objeto e seus métodos. A assinatura dos métodos é definida na classe do objeto enquanto que a implementação é definida em outro local utilizando uma linguagem de programação OO. O objetivo é definir o comportamento de um tipo de objeto com base nas operações que podem ser externamente aplicadas aos objetos daquele tipo, tornando assim a estrutura interna do objeto protegida, sendo que seus atributos ocultos serão acessados somente através do uso de seus métodos (ELMASRI & NAVATHE, 2005). 24

35 Os usuários externos de um objeto conhecem apenas a interface do tipo do objeto, onde é definido o nome e os parâmetros de cada operação. A interface de cada operação é chamada de assinatura, e sua implementação, de método. Um método é invocado pela passagem de uma mensagem ao objeto para que seja executado o método correspondente (ELMASRI & NAVATHE, 2005). Na Figura 15 é apresentada a sintaxe para criação da assinatura na classe. Figura 15. Sintaxe para assinatura de uma classe. Fonte: Adaptado de Harrington (2000). Os parâmetros podem ser de três tipos: entrada, saída ou entrada e saída ao mesmo tempo, devendo ser utilizados os comandos in, out e inout antes da definição dos parâmetros (HARRINGTON, 2000) Persistência Quando um objeto é criado em um banco de dados, ele pode ser persistente, onde continuará existindo após a execução de um programa, ou transiente, onde ele deixa de existir ao término da execução de um programa (ELMASRI & NAVATHE, 2005). Um objeto pode ser persistente de duas formas: Nomeação: nesse mecanismo de persistência, o objeto recebe um nome de persistência único pelo qual poderá ser recuperado pelos programas que o utilizam (ELMASRI & NAVATHE, 2005). A sintaxe dessa definição pode ser observada na Figura 16. Figura 16. Persistência de um objeto pelo mecanismo de nomeação. Fonte: Adaptado de Elmasri e Navathe (2005). Nesse exemplo foi criado um objeto persistente nomeado TodosDepartamentos do tipo Conjunto_de_departamentos que nesse exemplo trata-se de uma classe. 25

36 Alcançabilidade: por não ser viável nomear todos os objetos em um banco de dados de modo que sejam persistentes, é utilizado o recurso da alcançabilidade para que determinados objetos se tornem persistentes a partir de outros objetos nomeados, sendo alcançáveis através destes (ELMASRI & NAVATHE, 2005). Na Figura 17 é apresentado um exemplo de persistência através da alcançabilidade onde um objeto B se tornará persistente através do objeto TodosDepartamentos definido anteriormente. Figura 17. Persistência de um objeto pelo mecanismo de alcançabilidade. Fonte: Adaptado de Elmasri e Navathe (2005) Herança A herança é um mecanismo da OO que permite reutilizar classes e otimizar a modelagem dos dados. Ela pode representar uma generalização no caso das classes pai e uma especialização no caso das classes filhas. A classe pai possuirá os atributos e funções comuns a vários tipos de objetos e as classes filhas herdarão desta classe esses atributos acrescentando seus atributos específicos, o que caracteriza a especialização (ELMASRI & NAVATHE, 2005). A classe de onde se está herdando as definições é conhecida como superclasse, e a classe que está herdando estas definições é a subclasse. Nos BDOOs a herança pode ser de duas formas: herança múltipla, onde uma classe possui várias superclasses, e herança simples, quando possui apenas uma superclasse (EDELWEISS & GALANTE, 2005) Polimorfismo Os BDOO dão suporte ao polimorfismo das operações, conhecido também como sobrecarga de operadores. Essa característica permite que métodos definidos na superclasse possam ser reescritos pelas subclasses utilizando a mesma assinatura da superclasse (ELMASRI & NAVATHE, 2005). 26

37 2.5.2 Object Database Management Group (ODMG) O ODMG é um consórcio de fornecedores de SGBDs que uniram-se para definir um padrão para os bancos de dados OO que hoje é aceito internacionalmente. A versão mais recente deste padrão é a ODMG 3.0 (ELMASRI & NAVATHE, 2005). Os principais componentes deste padrão são: Modelos de objetos ODMG; Linguagem de definição de objetos (Object Definition Language - ODL); Linguagem de consulta a objetos conhecida como OQL (Object Query Language); e Linguagens de manipulação de objetos através do uso de programação OO conhecidos como OML (Object Manipulation Language) (ELMASRI & NAVATHE, 2005). A seguir são apresentados os principais conceitos da ODL e OQL Linguagem de Definição de Objetos A ODL é utilizada para especificar a estrutura dos objetos e suas classes de um BDOO independente de qualquer linguagem de programação (ELMASRI & NAVATHE, 2005). O padrão ODMG suporta dois tipos primitivos de dados que são o objeto e o literal. O objeto possui um identificador único o qual pode ser referenciado, já o literal não possui identificador e não pode ser referenciado (EDELWEISS & GALANTE, 2005). A declaração de classes na ODL é semelhante à criação de classes em linguagens de programação, como C++ ou Java, e sua sintaxe pode ser visualizada na Figura 18. Figura 18. Declaração de uma classe no padrão ODL. Fonte: Adaptado de Harrington (2000). 27

38 Além da possibilidade de criação de classes, a ODMG permite a criação de interfaces onde é definido o comportamento de um objeto. Sua sintaxe pode ser observada na Figura 19. Figura 19. Declaração de uma inteface no padrão ODL. Fonte: Adaptado de Edelweiss e Galante (2005). Quando uma classe implementa uma ou mais interfaces, ou seja, representa a herança de comportamento, é utilizada a sintaxe apresentada na Figura 20 (HARRINGTON, 2000). Figura 20. Herança de comportamento no padrão ODL. Fonte: Adaptado de Harrington (2000). A herança de estado e comportamento é representada através da palavra extends (HARRINGTON, 2000), conforme sintaxe apresentada na Figura 21. Figura 21. Herança de estado e comportamento. Fonte: Adaptado de Harrington (2000). Segundo Harrington (2000), existem algumas regras para a hierarquia de herança entre classes e interfaces: Uma interface pode herdar de outra interface; Uma classe pode herdar de uma interface; 28

39 As interfaces não podem herdar de uma classe; e Uma classe não pode herdar de outra classe. Para representar a herança múltipla de uma classe, utiliza-se o termo extent (HARRINGTON, 2000), conforme é apresentado na Figura 22. Figura 22. Herança múltipla de uma classe. Fonte: Adaptado de Harrington (2000). A declaração de atributos pode ser observada na Figura 23. Figura 23. Declaração de atributos. Fonte: Adaptado de Harrington (2000). Na Figura 24 é apresentada a sintaxe de um relacionamento de um e um relacionamento muitos, respectivamente. Figura 24. Representação de relacionamentos do padrão ODMG. Fonte: Adaptado de Harrington (2000). O comando inverse funciona da mesma forma que a integridade referencial em um banco de dados relacional. Para que o relacionamento funcione nos BDOOs, é preciso que o 29

40 relacionamento da classe de origem para a classe destino exista também da classe de destino para a classe de origem (HARRINGTON, 2000). O termo raises serve para identificar um método que será executado quando ocorrer alguma exceção na execução do método da classe. Na Figura 25 é apresentada a sintaxe para definição da assinatura de um método em uma classe utilizando o termo raises. Figura 25. Sintaxe da assinatura de um método. Fonte: Adaptado de Harrington (2000). Na Figura 26 é apresentado um exemplo de esquema de banco de dados segundo definição ODL dos objetos. Figura 26. Modelo de esquema de banco de dados para representação de um esquema ODL. Fonte: Adaptado de Elmasri e Navathe (2005). 30

41 Linguagem de Consulta de Objetos A OQL é o padrão de consulta especificado pela ODMG, a qual pode ser utilizada em conjunto com uma LPOO. Sua sintaxe é semelhante à SQL onde teremos uma estrutura do tipo select... from... where..., porém, com algumas características a mais para suporte aos objetos (ELMASRI & NAVATHE, 2005). Para que se possa efetuar uma consulta ao banco de dados, é necessário que haja um ponto de entrada referenciando um conjunto de objetos que serão acessados na consulta. Pontos de entrada são objetos que permitem localizar outros objetos a partir dele. Estes objetos possuirão coleções de objetos que serão acessados através do nome do ponto de entrada mais o indicador. e o nome do objeto que se deseja acessar (ELMASRI & NAVATHE, 2005). Na Figura 27 é apresentado um exemplo de consulta OQL considerando a classe Departamento. Figura 27. Exemplo de utilização da linguagem OQL. Fonte: Adaptado de Elmasri e Navathe (2005). Nesse exemplo d representada uma variável de iteração que funciona da mesma forma que no padrão SQL, que pode ser representada também com o termo as ou mesmo sem termo, simplesmente definindo o nome da variável (ELMASRI & NAVATHE, 2005). O OQL não exige que exista uma estrutura do tipo Select, para o retorno da consulta basta definir uma variável que faça referência à classe (ELMASRI & NAVATHE, 2005). 31

42 O resultado de uma consulta vai depender do objeto da consulta, o qual pode ser um literal (uma variável) ou um objeto, que pode ser do tipo coleção como set ou bag, dependendo da estrutura da consulta que se está realizando (ELMASRI & NAVATHE, 2005). A OQL disponibiliza um recurso chamado de Expressões de Caminho pelo qual é possível navegar pelos objetos e suas estruturas utilizando o termo. (ELMASRI & NAVATHE, 2005). Na Figura 28 pode-se verificar um exemplo onde se deseja acessar nota de uma determinada disciplina de um aluno a partir de Aluno a. Figura 28. Exemplo de Expressões de caminho. Fonte: Adaptado de Elmasri e Navathe (2005). 2.6 Ferramentas disponíveis de Bancos de Dados Orientados a Objetos A seguir serão apresentadas algumas ferramentas de SGBDOO selecionadas para esta pesquisa com o intuito de classificar a melhor opção para o armazenamento de dados Multimídia Caché Caché é um SGBDOO desenvolvido pela empresa InsterSystems, sendo esta uma empresa privada de desenvolvimento de software com sede em Massachusetts, fundada em 1978 (INTERSYSTEMS, 2007). O Caché é um banco de dados denominado pós relacional pela empresa Intersystems porque permite uma integração entre dois mundos: SQL e Objetos. Isso é possível porque o Caché disponibiliza todos os dados armazenados como tabelas relacionais através de uma camada de descrição dos objetos, o que possibilita a consulta através do SQL (INTERSYSTEMS, 2007). O Caché possibilita o acesso aos dados armazenados de três formas: através do uso do SQL; acesso direto através da linguagem proprietária do banco chamada Caché Object Script (COS); ou utilizando os Objetos Caché projetados para alguma linguagem suportada pelo banco de dados como Java ou C++, onde através de uma conexão ODBC é possível instanciar e salvar objetos diretamente no banco de dados (INTERSYSTEMS, 2007). 32

43 Na Figura 29 é apresentada uma tela da ferramenta de desenvolvimento do Caché que auxilia a criação e manutenção de classes do banco de dados. Figura 29. Tela da Ferramenta de desenvolvimento de classes e métodos do Caché. Fonte: Intersystems (2007). A seguir são apresentadas suas principais características do Caché, segundo Intersystems (2007): Suporte a transações multidimensionais que dão a possibilidade de criação de bancos de dados distribuídos; Arquitetura unificada de objetos com a alta performance do SQL; Um conjunto de tecnologias e ferramentas que permitem um desenvolvimento rápido de bancos de dados e aplicações web; Suporte nativo a objetos baseados em XML e WebServices; Integração automática com linguagens de programação OO como Java e C++; e 33

44 Construção de páginas dinâmicas através da linguagem de programação própria CSP (Caché Server Pages). Os dados são mapeados internamente como vetores multidimensionais através de um servidor de dados multidimensionais que faz o tratamento desses dados sem a necessidade do mapeamento dos mesmos para uma tabela. Esse mapeamento multidimensional permite que os dados possam ser indexados por qualquer parâmetro, não sendo limitados a linhas e colunas. Sendo esta característica que o torna mais veloz em relação aos demais BDOO que precisam mapear seus objetos como tabelas (KIRSTEN et al,2002 apud ROCHA et al,2008). Na Figura 30 é apresentado um diagrama da arquitetura interna do banco de dados Caché. Figura 30. Arquitetura do SGBDOO Caché. Fonte: Intersystems (2007). Os objetos são armazenados como arrays multidimensionais. Neste caso, o array é sobrescrito pelo valor do OID e os dados de cada instância armazenados compativelmente com os nós do array. Na Figura 31 é apresentado um exemplo de armazenamento de uma classe Employee que possui os atributos nome, identificador e localização: 34

45 Figura 31. Armazenamento de um objeto persistente. Fonte: Intersystems (2007). Para os índices é utilizado um array multidimensional separado com duas dimensões como apresentado na Figura 32. Figura 32. Armazenamento de índices. Fonte: Intersystems (2007). Segundo Hutchinson (2006 apud Intersystems (2006)), a persistência no cachê torna-se simples devido ao fato de não ser necessário fazer o mapeamento do modelo de dados OO para o modelo relacional, o que vem sendo uma das principais vantagens dos BDOO Poet O Poet é um SGBDOO produzido pela Poet Software, a qual é integrante da ODMG, dessa forma seu sistema atende a muitos dos requisitos impostos pelo órgão. Ele funciona em conjunto com compiladores Borland C++ e o Microsoft Visual C++ (NASSU & SETZER, 1999). A seguir são apresentadas as suas principais características segundo Nassu e Setzer (1999): 35

46 Possibilidade de edição utilizando a ODL para criação de esquemas de bancos de dados; É possível gerar código fonte na linguagem C++, através de um pré-processador, denominado PTXX, o qual pode ser utilizado em uma aplicação, que passa a possuir classes persistentes; Um visualizador gráfico dos objetos armazenados num banco de dados; Possui uma interface gráfica para visualizar os objetos e inspecionar classes pertencentes a um banco de dados; Utilização da OQL para consultas ao banco de dados; e Interface para administração do banco de dados, que inclui recuperação, backup e organização do banco de dados. Quando é efetuada uma alteração em algum objeto do banco, as alterações não são efetivamente gravadas em disco até que a instrução CommitTransaction seja executada, mantendo os dados em um estado válido (NASSU & SETZER, 1999) Jasmine Foi desenvolvido inicialmente pela empresa Fujitsu, do Japão, e hoje é comercializado pela Computer Associates. Inicialmente foi desenvolvido para servir como um gerenciador para banco de dados relacional não-normalizado, também da Fujitsu. Juntamente com o Jasmine, é disponibilizado um ambiente de desenvolvimento de aplicativos multimídia e manutenção de Bancos de Dados, o Jade (Jasmine Application Development Environment) (NASSU & SETZER, 1999). O Jasmine é puramente Orientado a Objetos, tornando-se mais adequado para o gerenciamento de dados complexos que o modelo relacional tradicional, além de possuir suporte para a web (SHIKIDA; ANDRADE & ARAÚJO, 1999). Segundo Spangler (1998) apud Assis (2005) o Jasmine possui uma arquitetura clienteservidor multi-thread, que o torna apropriado para armazenamento de dados multimídia, além de possui suporte a liguagem Java o que permite o desenvolvimento de aplicativos Web. Na Figura 33 36

47 é apresentado a arquiterura do BDOO Jasmine onde podem ser observados seus principais componentes. Figura 33. Arquitetura BDOO Jasmine. Fonte: Assis (2005) Versant Versant é um banco de dados Orientado a Objetos desenvolvido pela empresa Versant Corporation. Ele é desenvolvido para tornar mais rápido o desenvolvimento de aplicativos complexos em ambientes heterogêneos. O SGBDOO Versant atende a todos os requisitos estabelecidos pela ODMG e OMG (VERSANT, 2007). A arquitetura do banco de dados Versant é voltada para ambientes distribuídos, com suporte a processamento paralelo e uso de Multi-Threads (múltiplas tarefas) (VERSANT, 2007). A seguir são apresentadas algumas de suas principais características, segundo Versant (2007): Livre definição de tipos de dados complexos; Gerenciamento de Transações; 37

48 Criação de bancos de dados distribuídos; Plataformas heterogêneas; e Versant. Suporte nativo a LPOO como Java e C++. Na Figura 34 é apresentada uma tela da interface de administração do banco de dados Figura 34. Tela da interface de administração do banco de dados Versant. Fonte: Versant (2007). O SGBDOO Versant permite desenvolver os métodos das classes do banco em uma linguagem de alto nível como C e C++. O código fonte dos métodos será armazenado em arquivos separados e não diretamente no banco de dados onde ficará armazenado as classes com a denominação dos métodos (VERSANT, 2007) Análise comparativa Na Tabela 1 é apresentado um comparativo entre os bancos de dados OO Caché, Poet, Jasmine e Versant, discutidos anteriormente, onde e possível observar suas principais características: 38

49 Tabela 1. Comparativo de Banco de dados OO. Critério Caché Poet Jasmine Versant Definição de dados pelo usuário Sim Não Sim Sim Herança Múltipla Sim Não Sim Sim Valida cardinalidade entre objetos Sim Não Apenas no nível Sim "0, 1 ou muitos". Suporta transações longas Sim Sim Não Sim Linguagem de definição de Java, C++, C++ C, C++, ODQL, C, C++, Java atributos Delphi, Visual Basic e PHP Java Armazenamento dos métodos no Sim Sim Sim Sim BD Compatibilidade com o ODMG Sim Sim Não Sim Suporte a SQL Sim Não Somente via Sim ODBC Interface gráfica Sim Sim Sim Sim Os parâmetros definidos para o comparativos dos BDs foram baseados na pesquisa elaborada por Boscarioli et al. (2006), onde o autor elabora um comparativo entre os BDs Objectivity/DB, GemStone e Jasmine, buscando avaliar o desempenho e funcionalidade destes. Através da Tabela 1 pode-se observar que a ferramenta Caché se destaca pelos recursos oferecidos, compatibilidade com o padrão ODMG e suporte a SQL. Nenhuma das ferramentas estudadas é livre de licença, porém a maioria delas oferece uma versão gratuita para desenvolvimento de pesquisas e testes, o que permite a análise para o Trabalho. Através deste comparativo realizado, foi escolhida a ferramenta Caché para o desenvolvimento deste trabalho, por seu desempenho e pelo suporte à linguagem de programação Java, a qual foi utilizada para o desenvolvimento do sistema proposto. 2.7 Ferramentas disponíveis de Bancos de Dados Objeto-Relacional DB2 O DB2 Universal Database é um SGBD relacional desenvolvido pela empresa IBM Corporation e comercializado em todo mundo. Trata-se de um banco de dados robusto com suporte a dados relacionais e objetos (IBM, 2007). O banco de dados DB2 utiliza tecnologias derivadas do conceito de Banco de Dados Universal, que visa ampliar as capacidades da tecnologia de banco de dados, permitindo manipular 39

50 tipos de dados não-convencionais como: informações armazenadas em documentos, planilhas e objetos multimídia. Versões recentes oferecem suporte a vários tipos de aplicações cliente/servidor disponíveis, incluindo a internet (SILVA, 2001). Na Figura 35 é apresentada uma tela da ferramenta Centro de Desenvolvimento que permite desenvolver procedimentos armazenados, funções e gatilhos do banco de dados. Esta ferramenta também permite o desenvolvimento na linguagem Java e C. Figura 35. Tela da ferramenta Centro de Desenvolvimento do DB Oracle Oracle é o banco de dados mais utilizado no mundo, ocupando uma fatia de 47,1 % do mercado de bancos de dados. Sua versão mais atual é a 11g (ORACLE, 2007). A seguir são apresentadas suas principais características: Apresenta tecnologia de Grid Computing, que permite compartilhar uma infra-estrutura para todos os processos de negócios (ORACLE, 2007); 40

51 Possui ferramentas que auxiliam no desenvolvimento de software utilizando o padrão UML, onde é possível gerar códigos fontes em Java (SILBERSCHATZ; KORTH & SUDARSHAN, 2006); Suporte a dados XML (SILBERSCHATZ; KORTH & SUDARSHAN, 2006); Possui a ferramenta Oracle Repository que gerencia todos os objetos armazenados no banco de dados (SILBERSCHATZ; KORTH & SUDARSHAN, 2006); Suporta dados multidimensionais (SILBERSCHATZ; KORTH & SUDARSHAN, 2006); e Armazenamento de objetos com mapeamento relacional de seus atributos (SILBERSCHATZ; KORTH & SUDARSHAN, 2006) Análise comparativa Na Tabela 2 é apresentado um quadro comparativo dos bancos de dados objeto-relacional estudados, com o intuito de observar suas principais características. Tabela 2. Comparativo de Banco de dados Objeto-Relacional. Critério DB2 Oracle Definição de dados pelo usuário Sim Sim Suporte a dados multidimensionais Sim Sim Suporte a Objetos Grandes Sim Sim Linguagem de programação Java, C, REXX, Java Pearl Armazenamento dos métodos no BD Sim Sim Armazenamento dados Multimídia Sim Sim Suporte a Orientação a Objetos Sim Sim Integração Ferramentas Cases Sim Sim Os critérios utilizados para o comparativo foram selecionados para avaliar se o BD poderá ser utilizado para o armazenamento de dados Multimídias e o suporte a OO. As duas ferramentas pesquisadas possuem uma versão livre de licenças que pode ser utilizada para a pesquisa. 41

52 3 DESENVOLVIMENTO Neste capítulo será apresentado o processo de desenvolvimento do protótipo do sistema GEDOO para gerenciamento eletrônico de documentos e análise efetuada a partir deste quanto à utilização de bancos de dados para o armazenamento de dados multimídia. A seção 3.1 apresenta as etapas do desenvolvimento do protótipo e as ferramentas utilizadas nessa etapa. Também é apresentado o funcionamento do protótipo para melhor entendimento dos resultados obtidos. Na seção 3.2 são apresentados os testes realizados e análise dos resultados obtidos. Nesta seção é contextualizada a forma como os BDs selecionados tratam os arquivos de multimídia e armazenam estes. 3.1 Implementação do protótipo de sistema GEDOO O protótipo do sistema GEDOO foi desenvolvido a partir de um projeto que visa atender regras básicas para o controle de documentos de forma eletrônica em uma empresa. Seu objetivo principal é o armazenamento de arquivos como imagens, documentos em PDF, MSWord e MSExcel, como também arquivos de vídeo e música. O sistema GEDOO segue um fluxo de operação simples onde os usuários podem administrar seus documentos por áreas e com controle de segurança para consulta e publicação de documentos. Na Figura 36 é apresentado o diagrama de atividades do sistema.

53 Figura 36. Diagrama de atividades do processo de publicação de documento. No projeto do sistema foi decidida a utilização da linguagem de programação PHP, por ser mais familiar e de fácil implementação, porém a mesma não possuía suporte adequado e documentação para a utilização com o BDOO Caché. Dessa forma foi estudado qual seria a melhor 43

54 opção para atender aos objetivos desse trabalho e que possuía um melhor suporte para o BDOO, optando-se pela linguagem de programação Java. A seguir são apresentadas as priciapais regras de negócios do protótipo: 1. Armazenagem de arquivos Multimídia; 2. Segmentação em áreas; 3. Controle de aprovação e publicação de arquivos; 4. Controle de versões; 5. Controle de acesso aos arquivos e compartilhamento; e 6. Pesquisa de arquivos publicados. Para atender as regras de negócio propostas para o sistema GEDOO foram implementados os casos de usos apresentados na Figura

55 Figura 37. Casos de uso do sistema GEDOO. O sistema GEDOO é um sistema web, desenvolvido na linguagem de programação Java e utilizando recursos como JSP e Servlets como camada intermediária. O projeto do sistema foi elaborado seguindo o modelo MVC, onde há uma camada do software responsável pela interação com os usuários, uma camada que fará o controle da aplicação de acordo com a interação do usuário e a camada de persistência, que será responsável pela implementação das regras de negócio e acesso ao banco de dados. Na Figura 38 é apresentado o modelo de objetos implementados no sistema para atender as regras de negócio, onde podem ser observados três tipos de objetos. 45

56 Figura 38. Modelo de objetos do sistema. Para a camada de controle foi utilizado o conceito de Servlets, que faz o tratamento das requisições dos usuários e interação com a camada de persistência. Toda troca de informação entre a camada de persistência e a camada de interface é efetuada através da utilização desse mecanismo. Para o desenvolvimento do sistema foi selecionada a ferramenta NetBeans, por ser gratuita e de fácil utilização, além de fornecer todos os recursos necessários para implementação desse projeto. O Netbeans é uma IDE (Integrated Development Environment) livre de licenças para desenvolvimento de aplicativos tanto desktop quanto programas web na linguagem Java. Na instalação desta ferramenta, também é instalado o servidor Apache Tomcat, que servirá como servidor web para execução das páginas JSP (NETBEANS, 2006). Na ferramenta, foi criado um projeto chamado Gedoo onde são armazenados todos os fontes do sistema. Neste projeto existem dois tipos de arquivos: arquivos.jsp, que são as páginas web, e arquivos.java, que são os servlets e classes do sistema. O JSP é uma linguagem que permite criar páginas dinâmicas, com suporte à utilização de classes Java. As páginas JSP são executadas em um servidor web Apache Tomcat e se comunicam com a camada de Servlets que fazem o controle do sistema. 46

57 A utilização dos servlets através das páginas JSP funciona da seguinte forma: nas páginas JSP são definidos formulários que possuem como action o nome do servlet que deve ser executado quando o formulário for submetido, conforme apresentado na Figura 39. Figura 39. Código da definição do formulário. O servidor Tomcat interpreta essa ação e executa o servlet indicado. O servlet é uma classe Java que implementa e processa as requisições http. Essa camada é executada do lado do servidor e não possui interface com o usuário (SUN, 2008). No servlet são processadas as requisições, efetuando os tratamentos necessários, e após devolvendo o resultado para as páginas JSP. Na Figura 40 é apresentado um exemplo de implementação de um servlet que busca os últimos arquivos publicados de uma determinada área. Figura 40. Código do Servlet lstultarq. As classes servlet invocam as classes de persistência que buscam os dados na base de dados do sistema GEDOO e retornam um objeto com os dados requisitados. Na Figura 41 é apresentado um exemplo da implementação do método getarquivosbyarea que retorna um Array contendo o objeto arquivo. 47

58 Figura 41. Código do método getarquivosbyarea da classe persistearquivo Arquitetura do sistema O sistema foi desenvolvido para trabalhar com dois bancos de dados diferentes. A estrutura do sistema, seus usuários e áreas são armazenados no banco de dados DB2, sendo que os arquivos submetidos podem ser armazenados de três formas diferentes: em disco, no banco de dados objetorelacional DB2 e no banco de dados Orientado a Objetos Caché. Sendo que, independente da forma de armazenamento do arquivo, os meta-dados destes arquivos serão armazenados no banco DB2. Quando o usuário submete um arquivo na tela de submissão de arquivos, este pode escolher a forma de armazenamento. Dependendo da forma escolhida o sistema irá executar o método adequado. 48

59 Figura 42. Diagrama de componentes do sistema GEDOO. Para comunicação com os bancos de dados foi utilizado drivers JDBC disponibilizados pelos fabricantes dos SGBDs. Estes drivers permitem estabelecer comunicação com os bancos de dados através de comandos SQL. Há dois métodos no sistema, um para cada tipo de banco de dados, que executam a conexão com o banco de dados e retornam um objeto do tipo Conecction que será utilizado para executar as consultas no banco de dados. Na Figura 43 é apresentado o método ConectaDB2 que demonstra um exemplo de utilização deste driver, e na Figura 44 é demonstrado como esse método é utilizado para abrir uma conexão com o banco de dados e executar a inserção de um novo arquivo na base DB2: Figura 43. Método condatabase da classe persistearquivo. 49

60 Figura 44. Método salvaarquivodb2 da classe persistearquivo. Para o banco de dados OO Caché foi utilizado o mesmo mecanismo de comunicação JDBC, pois o banco Caché possui uma característica que o diferencia dos demais bancos de dados que é o suporte a consultas na linguagem SQL. Para o armazenamento dos arquivos foram criadas duas tabelas na base de dados DB2: ARQUIVO e VERSAO. Foi necessário criar esse relacionamento para atender as regras de negócio do sistema que exigem um controle de versão dos documentos onde o sistema deve manter armazenadas todas as versões publicadas de um documento. Nas Tabela 3 e Tabela 4 são apresentadas a estrutura dessas duas tabelas no banco de dados. 50

61 Tabela 3. Tabela ARQUIVO. Campo Tipo Tamanho Descrição CODARQUIVO INT (Auto- Increment) 4 Código do arquivo Chave primária da tabela NOMEARQUIVO VARCHAR 50 Nome do arquivo indicado pelo usuário ASSUNTO VARCHAR 50 Assunto relacionado ao arquivo DESCRICAO VARCHAR 255 Descrição do arquivo PALAVRASCHAVE VARCHAR 120 Palavras-chave para pesquisa do arquivo DT_CRIACAO DATE 4 Data de criação do arquivo no sistema HR_CRIACAO TIME 3 Hora de criação do arquivo no sistema COD_AREA VARCHAR 10 Código da área a qual o arquivo está relacionado IDUSUARIO INT 4 Código do usuário que submeteu o arquivo no sistema. Tabela 4. Tabela VERSAO. Campo Tipo Tamanho Descrição CODARQUIVO INT 4 Código do Arquivo Chave Primária da Tabela CODVERSAO INT 4 Código da Versão Chave primária da tabela END_ARQUIVO VARCHAR 255 Endereço onde o arquivo está armazenado utilizado para os casos em que o arquivo é armazenado em disco ARQUIVO BLOB 4 Mb Armazena o Arquivo DT_INCLUSAO DATE 4 Data de inclusão da versão do arquivo no sistema HR_INCLUSAO TIME 3 Hora de inclusão da versão no sistema DISCO INT 4 Indica o tipo de armazenamento do arquivo, que pode ser 0 Disco, 1 - DB2 e 2 Caché SITUACAO_ARQ INT 4 Situação do arquivo em relação a sua aprovação para publicação NMREALARQ VARCHAR 60 Nome real do arquivo, quando o mesmo é armazenado em disco NMORIGARQ VARCHAR 60 Nome original do arquivo Para a base de dados do sistema caché foi criado a classe ArqCh, que armazena o código do arquivo e versão e o arquivo. O tratamento da base de dados Caché será detalhado na próximo seção Banco de dados OO Caché 51

62 O banco de dados Caché possui uma arquitetura diferente dos demais bancos de dados OO onde o maior destaque está para o suporte a instruções SQL para manipulação dos dados. Quando cria-se uma classe no ambiente de desenvolvimento Studio do Caché, o sistema gera um mapeamento relacional para essa classe. O Caché, além de suas linguagens de programação proprietárias, como COS e CSP, possibilita o desenvolvimento através de linguagens de programação de alto nível como C++ e Java. Para implementação de uma aplicação em Java há várias formas como a utilização do driver JDBC, Objetos Caché e a ferramenta Jalapeño. A utilização do driver JDBC permite acessar a base de dados de forma relacional através da linguagem SQL. Os Objetos do Caché podem ser compilados dentro do Caché e associados ao projeto onde poderão ser instanciados diretamente dentro da aplicação Java através da classe com.intersys.objects, onde os mesmos podem ser salvos diretamente na base de dados. Através da tecnologia Jalapeño é possível efetuar o caminho inverso, onde classes Java podem ser compiladas dentro do Caché e armazenadas pelo SGBD. Para abrir um conexão com o Caché para acesso direto aos objetos é utilizada a o seguinte sintaxe: CacheDatabase.getDatabase(url, username, password); Sendo que para esse tipo de conexão também é utilizado o protocolo JDBC, porém o método getdatabase retorna uma conexão com o banco que permitirá instanciar objetos diretamente no banco de dados e salvá-los sem necessidade de uma instrução SQL. Na Figura 45 é apresentado um exemplo de como instanciar uma classe diretamente na base de dados do Caché e salvar o objeto no banco de dados. 52

63 Figura 45. Exemplo de criação de objeto do banco Caché. Ao criar uma classe no Caché o sistema cria todos os atributos como privados da classe e cria automaticamente os métodos set e get que farão a atualização e consulta do objeto na base de dados. Somente será possível acessar os atributos da classe através desses métodos. Através da ferramenta Studio do Caché é possível criar as classes no banco de dados de forma fácil através de wizards e comandos simples. Utilizando o método Projection o Studio projeta a classe criada para o diretório de saída especificado como parâmetro, para que esta possa ser utilizada em um aplicativo Java da forma demonstrada na Figura 45. Na Figura 46 é apresentada a criação da classe ArqCh que representa a classe que irá armazenar o arquivo na base de dados Caché. 53

64 Figura 46. Criação de uma classe na ferramenta Studio. Essa classe possuirá os atributos Tabela 5: Tabela 5. Atributos da Classe ArqCh. Atributo Tipo Descrição Codarquivo INT Armazena o código do arquivo associado a tabela VERSAO do banco DB2 que fará o controle dos arquivos Codversao INT Armazena o código da versão do arquivo Arquivo GlobalBinaryStream Armazena o arquivo A classe ArqCh somente irá armazenar o arquivo e os dados necessários para relacionar o arquivo aos seus meta-dados que ficarão armazenados na base de dados DB2. Para criar uma conexão JDBC e acessar ao banco Caché de forma relacional, é utilizada a mesma terminologia utilizada para qualquer outra base de dados: Class.forName("com.intersys.jdbc.CacheDriver"); conn = DriverManager.getConnection(url, user, password); 54

65 A partir desta conexão é possível acessar aos dados do banco Caché da mesma forma como um banco relacional com comandos SQL. É devido a essa característica do Caché, de interpretação de comandos SQL que a empresa Intersystems denomina o BDOO como pós-relacional. Na Figura 47 é apresentado um exemplo de código para acesso a base de dados Caché através de comandos SQL. Figura 47. Exemplo de acesso ao Caché utilizando comandos SQL Inicialmente decidiu-se por utilizar os objetos Caché para implementação do módulo do sistema que salvaria os arquivos nesta base de dados. Porém, durante o desenvolvimento percebeuse que o Caché não criava os métodos set e get para atributos do tipo Stream que é o tipo equivalente ao Blob no BDOR. Dessa forma foi necessário implementar um novo método, utilizando conexão JDBC e SQL para inserção e recuperação do arquivo na base de dados Funções do Sistema GEDOO Foram desenvolvidas funcionalidades básicas para o controle de documentos no protótipo de sistema GEDOO. A seguir são apresentadas as funções do sistema e a forma de interação do usuário Autenticação Na tela de autenticação o usuário deve informar usuário e senha previamente cadastrados no sistema. O sistema irá controlar o acesso do usuário através do uso de sessões e caso o usuário deseje sair do sistema, deve utilizar a opção Logoff para eliminar as sessões abertas. Na Figura 48 é apresentada a tela de autenticação do sistema. 55

66 Figura 48. Tela de autenticação do sistema. Ao usuário efetuar autenticação no sistema, será exibida a tela principal do sistema onde serão apresentados os últimos documentos publicados no sistema, as opções de menu que o usuário possui acesso e as áreas relacionadas ao acesso do usuário, conforme apresentado na Figura 49. Figura 49. Tela principal do sistema Submissão de Arquivo Através do menu Incluir Arquivo o usuário irá acessar a tela de submissão de arquivos conforme apresentado na Figura 50. Nesta tela o usuário informa alguns dados básicos do arquivo 56

67 que servirão como meta-dados para pesquisa. O usuário deve indicar o arquivo que deseja submeter e a forma de armazenamento do arquivo, que pode ser diretamente em Disco, no BDOR DB2 ou no BDOO Caché. Figura 50. Tela de submissão de arquivos. Após preenchido o formulário, o usuário pode clicar no botão Enviar que irá processar os dados e redirecionar o usuário para uma tela de confirmação da submissão onde podem ser observados dados como tamanho do arquivo submetido e tempo para armazenar o arquivo no destino, em milissegundos, conforme pode ser observado na Figura 51. Figura 51. Tela de confirmação de arquivo salvo. Para implementação do upload do arquivo inicialmente foi testada a utilização do componente UploadBean. Este componente pode ser integrado com páginas JSP e Servlets para 57

68 upload de arquivos. Ele também permite salvar arquivos em banco de dados, para isso é utilizado o método setdatabasestore para indicar que o arquivo será salvo em banco. O componente irá salvar o arquivo em uma tabela chamada UPLOAD que deve ser criada no banco de dados do sistema (JAVAZOOM, 2008). Devido a essa limitação esse componente não foi utilizado pois para a implementação do projeto proposto foi necessário desenvolver o algoritmo de armazenamento no banco de dados para atender ao banco OR e OO. Optou-se, então, por utilizar a biblioteca commons-fileupload do projeto Jakarta disponibilizado pela organização Apache (APACHE SOFTWARE FOUNDATION, 2005). O projeto Jakarta é um conjunto de componentes desenvolvidos em Java para auxiliar no desenvolvimento de aplicativos Web utilizando a linguagem de programação Java. O Componente commons-fileupload implementa uma classe que trata os arquivos e retorna um objeto serializado do tipo FileStream para armazenamento (JAKARTA, 2008). O tratamento do arquivo é efetuado no servlet UploadArquivo que gera um objeto arquivo que será enviado para a classe persistearquivo que efetuará a gravação do arquivo no destino correto. Na Figura 52 é apresentado um exemplo de como é efetuado o tratamento do arquivo utilizando a biblioteca commonsfileupload. Figura 52. Exemplo de código utilizando a biblioteca commonsfileupload Aprovação da publicação do Arquivo Ao submeter um arquivo no sistema, o usuário deve selecionar uma área a qual o arquivo será relacionado. O sistema irá verificar o aprovador da área selecionada e disponibilizar o arquivo 58

69 para que este usuário efetue a aprovação do mesmo para publicação. O arquivo somente estará disponível para consulta após aprovação. Na Figura 53 é apresentada a tela de aprovação de documentos onde são listados todos os arquivos que estão pendentes de liberação. Figura 53. Tela de documentos pendentes de aprovação. Na tela apresentada na Figura 53 o usuário poderá selecionar o arquivo que deseja efetuar a aprovação. Ao selecionar o arquivo que será analisado o usuário é redirecionada para a tela de efetivação da aprovação, apresentada na Figura 56, onde são mostrados os detalhes dos documento que está sendo analisado. O usuário deve indicar se o arquivo será aprovado ou não e clicar no botão Enviar para confirmar a operação. Figura 54. Tela de aprovação de documentos. Caso o usuário não aprove o documento, este será eliminado da base de dados. Aprovando o documento este será liberado para consultas. 59

70 Pesquisa de arquivos O sistema possui duas formas de pesquisa de documentos que pode ser por assunto ou por palavras-chave. Ao preencher o formulário de pesquisa e clicar no botão Enviar, o sistema apresentará uma listagem de todos os arquivos encontrados relacionados aos termos informados na pesquisa. Na Figura 55 é apresentado como executar a pesquisa. Após clicar no botão pesquisar o sistema exibe uma listagem com os resultados encontrados. Na listagem apresentada é exibido um link para consulta do arquivo pesquisado, conforme apresentado na Figura 56. Figura 55. Tela de pesquisa de arquivos. Figura 56. Tela do resultado da pesquisa. Ao clicar o link para efetuar consulta do arquivo, o sistema carrega o arquivo da base armazenada e apresenta na tela do resultado da recuperação do arquivo, os dados do arquivo e um link para download do mesmo conforme apresentado na Figura

71 Figura 57. Tela de recuperação do arquivo Alteração do Arquivo O sistema disponibiliza uma função para que o usuário possa alterar um arquivo publicado. O sistema irá tratar essa alteração como uma nova versão do arquivo mantendo armazenada a versão antiga para consulta. Para o usuário efetuar a alteração de um documento, inicialmente ele deve pesquisar o documento desejado, conforme apresentado na Figura 58. Figura 58. Tela de alteração de arquivos Pesquisa. Ao efetuar a pesquisa, o sistema listará todos os arquivos do usuário que já foram aprovados para que o usuário possa alterá-los. Clicando no nome do arquivo o sistema apresenta a tela de alteração do arquivo apresetanda na Figura

72 Figura 59. Tela de alteração de arquivos Administração do sistema Cadastro de usuários e áreas A função de administração do sistema permite o usuário administrador cadastrar novas áreas no sistema e gerenciar o cadastro de usuários do sistema. No cadastro de usuários pode ser inserido novo usuário, alterar ou bloqueado o acesso de um usuário. O administrador também deve associar o usuário a uma ou mais áreas, nas quais o usuário poderá publicar ou consultar documentos publicados Diagramas Nesta seção serão apresentados os principais diagramas desenvolvidos e utilizados para a implementação do protótipo de sistema GEDOO Diagrama de Classes O diagrama de classes representa todas as classes presentes no sistema. No caso do sistema GEDOO, as classes de persistências representadas no diagrama servem para a construção da base de dados do sistema. Na Figura 60 é apresentado o diagrama de classe do sistema GEDOO que está dividido em três partes: classes de interface, classes de controle e classes de persistência. 62

73 Figura 60. Diagrama de classes do sistema GEDOO Diagrama de Seqüência Submissão de Arquivo Este diagrama representa o processo de submissão de um novo arquivo ao sistema. O diagrama da Figura 61 demonstra que um usuário submete um novo arquivo ao sistema GEDOO, sendo este arquivo associado a uma área. 63

74 Figura 61. Diagrama de Seqüência de submissão de um arquivo Pesquisa de arquivos Este diagrama representa o processo de pesquisa de um documento no sistema GEDOO. Na Figura 62 é possível observar o fluxo do processo de consulta de um documento. Neste processo o usuário acessa a opção de pesquisa de arquivos, onde tem duas opções de pesquisa: por palavraschave ou por assunto do arquivo. O usuário informa os dados da pesquisa e submete o formulário ao sistema, este processa a pesquisa e retorna os resultados associados com os dados da pesquisa. Caso o usuário deseje visualizar o arquivo, o sistema disponibiliza um link para download onde o usuário é redirecionado para um interface com detalhes do arquivo selecionado. 64

75 Figura 62. Diagrama de Seqüência da pesquisa de arquivos Diagrama ER O modelo Entidade-relacionamento foi utilizado para implementar a versão do sistema para o banco de dados Objeto-Relacional, para atender aos objetivos do presente trabalho em comparar a performance do BDOO e o BDOR. Na Figura 63 podem ser observadas as estruturas das tabelas do GEDOO e seus relacionamentos. 65

76 Figura 63. Diagrama ER do sistema GEDOO. 3.2 Análise dos resultados Após a implementação do protótipo GEDOO foi iniciada a etapa de testes para validação do protótipo. Nos testes realizados foram observadas algumas características novas essenciais para o sistema, a afim de possibilitar a análise objetivo deste trabalho. Uma dessas características foi inclusão de telas que demonstrassem o tempo para processamento e recuperação de arquivos. A seguir são apresentados os dados da análise elaborada a partir do protótipo implementado Armazenamento e recuperação de dados Multimídia Para todos os tipos de armazenamentos abordados, sendo este em disco, no BDOR DB2 e no BDOO Caché, foi necessário implementar o tratamento do arquivo recebido para o formato serializado InputStream através do componente commons-fileupload para realizar o upload deste. O formato do arquivo passou a ser o mesmo para os três tipos de armazenamento, limitando as diferenças de performance ao desempenho do próprio SGBD ou sistema operacional. Os testes 66

77 foram realizados em um computador portátil com processador Pentium M de 1.7 MHz, com 512 MHz de memória RAM. Nos testes realizados foram analisados os seguintes indicadores definidos no projeto para determinar a melhor forma de armazenamento dos dados multimídia: tempo de armazenamento e recuperação, compartilhamento dos arquivos, segurança dos dados armazenados e facilidade de desenvolvimento para implementar o armazenamento. Nos primeiros testes realizados foram processados 5 formatos de arquivo, sendo 4 de cada formato, num total de 20 arquivos em cada destino de armazenamento. Na Tabela 6 são apresentados os dados obtidos com os testes realizados: Tabela 6. Resultado dos testes efetuados. Nome Tamanho (Bytes) Tempo Armaz. Disco ms Tempo Armaz. DB2 ms Tempo Armaz. Caché ms Tempo Recuperação Disco ms Tempo Recuperação DB2 ms PDF PDF PDF PDF DOC DOC DOC DOC IMG IMG IMG IMG MP MP MP MP ZIP ZIP ZIP ZIP Tempo Recuperação Caché ms A partir dos dados coletados na Tabela 6 foi gerada a Tabela 7 onde são apresentadas as médias de bytes armazenados e recuperados por segundo: Tabela 7. Média do tempo de armazenamento e recuperação. Forma armazenamento Armazenagem (Bytes/ms) Recuperação (Bytes/ms) Disco DB Caché

78 A partir da coleta dos dados apresentados nas Tabela 6 e Tabela 7, é possível observar que o armazenamento em disco possui uma performance superior ao armazenamento em um banco de dados. Esse é um fato esperado, sabendo-se que não há nenhum tratamento para os dados armazenados em disco. Essa análise foi abordada para servir como parâmetro para os dados armazenados nos SGBDs, sendo estes valores, o tempo mínimo que poderá se obter para o armazenamento de dados multimídia. Verificou-se com esta primeira coleta de dados que há uma relação entre o tipo de arquivo e tempo necessário para armazenamento e recuperação. Devido a esse fato foi realizado uma segunda coleta de dados, onde um mesmo arquivo foi submetido 5 vezes para obter uma média dos tempos de armazenamento e recuperação. Foram analisados 4 tipos de arquivos (AVI, MP3, BMP e PDF). A média dos recultados obtidos é apresentada na Tabela 8 e a tabela completa dos dados coletados pode ser consultada no Apêndice B. Tabela 8. Média do tempo de armazenamento e recuperação por tipo de arquivos (Bytes/ms). Armazena gem AVI MP3 BMP PDF Média Recupera Armazena Recupera Armazena Recupera Armazena Recupera Armazena ção gem ção gem ção gem ção gem DISCO Recupera ção DB CACHÉ Com este comparativo, pode se observar que realmente há uma difrença entre os tempos de armazenamento de acordo com o tipo de arquivo, porém análise de comparação dos BDs permanece a mesma, onde o SGBDOR apresenta uma performance melhor quanto ao armazenamento, porém o SGBDOO possui uma performance superior na recuperação dos dados armazenados. Esse comportamente pode ser observado no gráfico apresentado na Figura

79 DISCO DB2 CACHÉ Armazenagem Recuperação Armazenagem Recuperação Armazenagem Recuperação Armazenagem Recuperação AVI MP3 BMP PDF Figura 64. Gráfico comparativo entre os tipos de mídia. O armazenamento em SGBDs apresentou uma performance aproximadamente de 90% inferior ao armazenamento em disco. Por isso, pode se observar que é necessário um aperfeiçoamento para armazenamento de dados multimídia em campos BLOBs nos bancos de dados para tornar viável o gerenciamento de uma grande quantidade de dados multimídia em um SGBD. Além da deficiência no armazenamento, a recuperação dos dados em SGBDs também apresentou uma performance muito inferior a recuperação dos dados em disco. Pode-se obbservar que para arquivos de tamanho até 3 Mb o armazenamento e recuperação em SGBDs é viável de implementação, pois o tempo gasto, mesmo sendo superior ao armazenamento em disco é suficientemente rápido para o uso em sistemas domésticos e empresarial. O BDOO Caché, apresentou uma performance inferior ao BDOR DB2 no armazenamento de dados, porém essa diferença não foi grande, o que demonstra um avanço para a tecnologia de SGBDOO. Apesar da performace inferior no armazenamento de dados, o BDOO apresentou uma performance superior na recuperação dos arquivos armazenados. Nesse caso, a implementação de um sistema para armazenamento de dados multimídia em um BDOO ainda precisa ser analisada como uma opção, avaliando-se outros requisitos como a facilidade de implementação e os recursos de pesquisa sematica disponíveis nos BDOOs, além das necessidades básicas do sistema que pretende se desenvolver, onde deve se observar requisitos como: quantas vezes o arquivo será armazenado e quantas vezes este será recuperado. Se analisar-se requisitos comos estes a utilização de um SGBDOO se torna ainda mais interessante. 69

80 Outra vantagem dos SGBDOOs para o armazenamento de dados multimídia é o seu tratamento de versionamento, onde um objeto nunca é excluído. Objetos multimídia nunca serão alterados no banco de dados como um registro comum, estes precisaram ser substitídos completamente na base de dados, a utilização de um controle de versões neste caso se torna muito interessante para não se perder versões antigas de um projeto de CAD por exemplo, onde os usuários geralmente desejam criar comparativos entre versões de um mesmo arquivo Segurança dos dados e compartilhamento É importante ressaltar que o nível de segurança dos dados armazenados em um banco de dados é superior ao armazenamento destes diretamente em disco, pois em um banco, os arquivos ficam protegidos de acessos indevidos e corrupção de arquivo. Isso é uma questão importante, principalmente em sistemas que armazenam documentos confidenciais, como, por exemplo, o sistema desenvolvido para controle eletrônico de documentos, que muitas vezes é implantado em grandes empresas. Além da segurança dos dados armazenados, o compartilhamento dos arquivos passa a ser gerenciado pelo SGBD que possui controle de transações por conexão. O arquivo armazenado em um SGBD é tratado como um dado de uma tabela, onde o sistema irá controlar acessos simultâneos e uso exclusivo do arquivo, o que garante a sua integridade. No armazenamento em disco, o controle de compartilhamento passa a ser gerido pelo software, que deve controlar alterações e acessos simultâneos. Para as duas questões citadas, os bancos de dados utilizados atendem da mesma forma, sendo que o BDOO possui controle de versões de objetos, o que permite criar um acervo dos objetos armazenados sem perder uma versão anterior após uma alteração. Esse característica é muito utilizada em aplicativos CAD e CAM que permitem comparar diferentes versões de um mesmo projeto Facilidade no desenvolvimento Percebeu-se através do protótipo desenvolvido e dos testes realizados que o desenvolvimento com o SGBDOO Caché foi mais fácil de implementar quando não há uma definição relacional dos objetos que serão manipulados. A persistência de um objeto em um BDOO passa a ser simples, sem a necessidade de um mapeamento das classes para o modelo relacional. 70

81 Dependendo do escopo do aplicativo, quando não há necessidade de armazenar uma grande massa de dados, essa facilidade pode ser decisiva para escolha do banco de dados a utilizar. 71

82 4 CONCLUSÃO Neste projeto foi desenvolvido o protótipo GEDOO para análise e comparação dos meios de armazenamento em disco, em um banco de dados objeto-relacional e em um banco de dados orientado a objetos. Foi avaliado o armazenamento de dados multimídia para avaliar a melhor opção para armazenamento desse tipo de informação. Foram escolhidas duas ferramentas de SGBDs para análise: o SGBD Objeto relacional DB2 da empresa IBM e o SGBD Orientado a Objetos Caché da empresa Intersystems. O banco de dados DB2 foi escolhido pelas suas características de objeto-relacional e por ser uma ferramenta de fácil acesso, já consolidada no mercado, e que possui uma versão gratuita para demonstração. O banco de dados Caché foi escolhidos por ser o único BDOO com suporte a consultas SQL, e por possuir boa documentação disponível pelo fabricante, além do suporte à linguagem Java. O Caché também possui uma versão livre para demonstração que permite realizar pesquisas e desenvolvimento para o aprendizado. Além de avaliar o armazenamento de dados multimídia em SGBDs, foi também implementada uma opção para armazenamento em disco para comparar se o armazenamento em bancos de dados possui performance muito inferior ou adequada em relação ao armazenamento diretamente em disco. O desenvolvimento do protótipo de sistema GEDOO proporcionou uma visão mais abrangente da utilização dos conceitos de Orientação a Objetos no desenvolvimento de um sistema e a aplicação destes conceitos na utilização de uma ferramenta de SGBDOO que muitas vezes não é aprofundada durante o curso de ciência da computação. Através da implementação do protótipo integrado com um banco de dados OO pode se observar as principais características e vantagens na utilização deste tipo de SGBD, o que agrega facilidade na implementação do código e persistência de objetos. Porém, observou-se que esse tipo de banco de dados atualmente não é o mais apropriado para o armazenamento de grandes quantidade de dados. O tratamento para campos BLOB precisa ser aperfeiçoado nesse tipo de SGBD para que este possibilite um melhor tratamento no armazenamento e recuperação de arquivos multimídia. Ao iniciar o desenvolvimento da persistência dos dados multimídia na ferramenta Caché, encontrou-se dificuldades para a utilização de seus objetos projetados para a linguagem Java. A 72

83 projeção criada pelo Caché para atributos do tipo Stream, os quais armazenam os dados multimídia, não geram métodos para acesso a esse tipo de atributo. Dessa forma foi necessário alterar a forma de acesso ao BDOO Caché, para que o armazenamento destes dados fosse efetuado através de comandos SQL, que são interpretados pelo banco e traduzidos para o modelo orientado a objetos. A necessidade da interpretação dos comandos SQL pelo SGBDOO gera uma perda de performance, fator esse que ocorre na maioria dos BDOO que internamente armazenam os dados seqüencialmente como no modelo OR, porém para acessá-los o SGBDOO monta uma organização lógica para o modelo OO tornando seu mecanismo de armazenamento e recuperação mais lentos do que um SGBDOR. Observou-se também que houve um grande avanço na tecnologia de SGBDOO em relação ao citado no trabalho, indicando a falta de crescimentos destes SGBDs pela sua baixa performance em relação ao modelo relacional (EDELWEISS & GALANTE, 2005). Hoje estes SGBDs estão mais estáveis e com uma performance aprimorada, o que torna viável a sua utilização para sistemas em que o foco não é o armazenamento de grandes quantidade de dados. A pesquisa de dados em bancos OO se mostra superior ao modelo relacional devido à organização interna dos dados no modelo OO. Porém esse aspecto não é observado para dados do tipo BLOB. O BDOO Caché apresentou muitas facilidades de utilização devido ao suporte à linguagem SQL e à possibilidade de acesso direto aos objetos utilizando a linguagem Java. O Caché é um BDOO com uma arquitetura evoluída que apresenta algumas ferramentas que tornam sua utilização mais fácil, além da documentação disponível no site para o desenvolvimento de aplicativos utilizando a linguagem Java. O objetivo geral do presente trabalho foi alcançado através do desenvolvimento do protótipo de sistema que possibilitou elaborar o comparativo entre os três meios de armazenamento abordados: disco, BDOR DB2 e BDOO Caché, onde o armazenamento e recuperação em disco apresentou um performance superior. Porém o armazenamento em bancos de dados se apresentou viável e mais indicado pela segurança e integridade dos dados armazenados. O protótipo também permitiu observar que o tratamento para dados multimídia no BDOR DB2 possui melhor performance e melhor tratamento para os dados armazenados. Embora o SGBDOO tenha apresentado uma performance inferior ao esperado, ele ainda surpreendeu quanto à sua performance em relação ao SGBDOR, apresentando bom desempenho. Sugere-se a partir da análise elaborada, que para o desenvolvimento de ferramentas semelhantes, 73

84 busque avaliar-se também o escopo do projeto, pois aplicativos de armazenamento de dados multimídia caseiros não necessitam de uma grande base de dados, podendo-se salvar os dados diretamente em disco. Porém, para uma grande corporação onde a informação é patrimônio mais valioso, sugere-se a utilização de um banco de dados OR. Com os resultados obtidos, conclui-se que ainda é necessário um aperfeiçoamento nos SGBDOO para que estes venham a ocupar espaço no mercado, hoje dominado pelas ferramentas relacionais, para armazenamento de grandes massas de dados. Observou-se um avanço nesta tecnologia comparada com trabalhos anteriores a estes onde os sistemas BDOO possuíam uma performance muito baixa. Além desse aspecto, é necessário observar que há uma grande falta de conhecimento no mercado sobre o assunto, e esse desconhecimento sobre a ferramenta não permite grandes avanços na tecnologia, pois não são realizadas muitas pesquisas na área. Como trabalhos futuros com o projeto GEDOO, podem-se citar: 1. Pesquisa por conteúdo através do desenvolvimento de algoritmos de Inteligência Artificial; 2. Compactação de arquivos para armazenamento em um banco de dados através um algoritmo de compressão. 74

85 REFERÊNCIAS BIBLIOGRÁFICAS APACHE SOFTWARE FOUNDATION. The Apache Jakarta Project Disponível em Acessado em: 02 mai ASSIS, Mateus Calçado. Sistemas de Informação Multimídia para conservação e democratização de acervos históricos f. Monografia (Especialização em Informática, Ênfase em Tecnologias da Informação e Multimídia) Universisdade Federal de Minas Gerais, Belo Horizonte, BORBA, Sueli de Fátima Poppi; MORALES, Aran Bey Tcholakian. Aplicação de Banco de dados orientado a objetos na modelagem multidimensional. In: SIMPÓSIO BRASILEIRO DE BANCO DE DADOS, 21, 2006, Florianópolis. Florianópolis: 2006, 146 f. BOSCARIOLI, Clodis; BEZERRA, Anderson; BENEDICTO, Marcos de; DELMIRO, Gilliard. Uma reflexão sobre banco de dados orientados a objetos. In: CONGED CONGRESSO DE TECNOLOGIAS PARA GESTÃO DE DADOS E METADADOS DO CONE SUL, 4, 2006, Paraná. Paraná: 2006, 12 f. CA. Computer Associates. Disponível em: < Acesso em: 06 out EDELWEISS, Nina; GALANTE, Renata de Matos. Banco de dados orientado a objetos e relacional-objeto. In: SIMPÓSIO BRASILEIRO DE BANCO DE DADOS e SIMPÓSIO BRASILEIRO DE ENGENHARIA DE SOFTWARE, 20, 19, f. ELMASRI, Ramez; NAVATHE, B. Shamkant. Sistemas de banco de dados. 4. ed. São Paulo: Pearson Addison Wesley, FANTINI, Sérgio Rubens. Aplicação do gerenciamento eletrônico de documentos: estudo de caso de escolha de soluções f. Dissertação (Mestrado em Engenharia de Produção) - Universidade Federal de Santa Catarina, Florianópolis, HARRINGTON, Jan L.. Object-oriented database design clearly explained. San Francisco: Morgan Kaufmann Publishers, IBM. Ibm Corporation. Disponível em: < Acesso em: 01 out INTERSYSTEM. Intersystem Corporation. Disponível em: < Acesso em: 06 out JAKARTA. Apache Jakarta Project. Disponível em : Acessado em 04 mai JAVAZOOM. Javazoom.Net. Disponível em: Acesso em 02 abr KHOSHAFIAN, Setrag. Banco de dados orientado a objeto. Rio de Janeiro: Infobook, NASSU, Eugénio A.; SETZER, Valdemar W. Bancos de dados orientados a objetos. São Paulo: Edgard Blücher,

86 NETBEANS. NetBeans IDE. Disponível em: Acessado em 03 mar ORACLE. Oracle Corporation. Disponível em: < Acesso em: 01 out RICARTE, Ivan Luiz Marques. Sistemas de bancos de dados orientados a objetos f. Dissertação (Mestrado em Engenharia da Computação e Automação Industrial ) Faculdade de Engenharia Elétrica e de Computação, Universidade Estadual de Campinas, São Paulo, ROCHA, Carlos A. S.; RAICIKI, Helton Alixandre; ROCHA, Muriel F. B.; LUIZ, Rafael Boaventura. Desenvolvimento de Ferramenta de Apoio a Atualização de Sistemas de Informação Baseados no sistema de banco de dados Pós-Relacional Caché f. Iniciação científica (Escola Superior de Criciúma) Escola Superior de Criciúma, Santa Catarina, SHIKIDA, Leonardo Kenji.; ANDRADE, Nélson Spangler de.; ARAÚJO, Arnaldo de Albuquerque. Implementação de um protótipo de um sistema de informações multimídia para documentos históricos f. Iniciação científica (Graduando em Ciência da Computação) Universidade Federal de Mimas Gerais, Minas Gerais, SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de banco de dados. 5. ed. Rio de Janeiro: Elsevier, SILVA, Enio Kilder Oliveira da, Um estudo sobre sistemas de banco de dados cliente/servidor f. Monografia (Graduação em Processamento de Dados) Faculdade Paraibana de Processamento de Dados, João Pessoa, SILVA, Ricardo Czelusniak da. Benchmark em banco de dados multimídia: análise de desempenho em recuperação de objetos multimídia f. Dissertação (Mestrado em Ciências Exatas) Universidade Federal do Paraná, Curitiba, SOUZA, Flávio Rubens de Carvalho. Caché, Banco de dados Pós-relacional f. SUN. Java Servlet Technology Disponível em Acessado em 15 abr VAUGHAN, Tay. Multimídia na prática. São Paulo: Makron Books, VERSANT. Versant Object Technology. Disponível em: < Acesso em: 06 out

87 APÊNDICES 77

88 A DIAGRAMA DE CLASSES COMPLETO Diagrama de Classes do sistema completo: 78

89

90 80