universidade do vale do itajaí centro de ciências

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
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
SUMÁRIO
LISTA DE ABREVIATURAS..................................................................iv
LISTA DE FIGURAS................................................................................. v
LISTA DE TABELAS ..............................................................................vii
RESUMO..................................................................................................viii
ABSTRACT................................................................................................ix
1 INTRODUÇÃO ...................................................................................... 1
1.1 PROBLEMATIZAÇÃO ..................................................................................... 3
1.1.1 Formulação do Problema ................................................................................. 3
1.1.2 Solução Proposta ............................................................................................... 3
1.2 OBJETIVOS ........................................................................................................ 4
1.2.1 Objetivo Geral ................................................................................................... 4
1.2.2 Objetivos Específicos ........................................................................................ 4
1.3 METODOLOGIA................................................................................................ 4
1.4 ESTRUTURA DO TRABALHO ....................................................................... 5
2 FUNDAMENTAÇÃO TEÓRICA ........................................................ 6
2.1 DADOS MULTIMÍDIA...................................................................................... 6
2.2 ARMAZENAMENTO E RECUPERAÇÃO DE DADOS MULTIMÍDIA ... 7
2.3 GERENCIAMENTO ELETRÔNICO DE DOCUMENTOS ......................... 9
2.4 BANCO DE DADOS OBJETO-RELACIONAL ........................................... 10
2.4.1 Modelo Relacional (MR) ................................................................................ 11
2.4.2 Modelo de Entidade/Relacionamento (MER) .............................................. 12
2.4.3 Modelo de dados EER - ER Estendido ......................................................... 13
2.5 BANCOS DE DADOS ORIENTADOS A OBJETOS ................................... 19
2.5.1 Modelo de Dados Orientado a Objetos ......................................................... 20
2.5.2 Object Database Management Group (ODMG).......................................... 27
2.6 FERRAMENTAS DISPONÍVEIS DE BANCOS DE DADOS
ORIENTADOS A OBJETOS................................................................................... 32
2.6.1 Caché ................................................................................................................ 32
2.6.2 Poet ................................................................................................................... 35
2.6.3 Jasmine............................................................................................................. 36
2.6.4 Versant ............................................................................................................. 37
2.6.5 Análise comparativa ....................................................................................... 38
2.7 FERRAMENTAS DISPONÍVEIS DE BANCOS DE DADOS OBJETORELACIONAL.......................................................................................................... 39
2.7.1 DB2 ................................................................................................................... 39
2.7.2 Oracle ............................................................................................................... 40
2.7.3 Análise comparativa ....................................................................................... 41
ii
3 DESENVOLVIMENTO ...................................................................... 42
3.1 IMPLEMENTAÇÃO DO PROTÓTIPO DE SISTEMA GEDOO .............. 42
3.1.1 Arquitetura do sistema ................................................................................... 48
3.1.2 Banco de dados OO Caché ............................................................................ 51
3.1.3 Funções do Sistema GEDOO ......................................................................... 55
3.1.4 Diagramas ........................................................................................................ 62
3.2 ANÁLISE DOS RESULTADOS ...................................................................... 66
3.2.1 Armazenamento e recuperação de dados Multimídia................................. 66
3.2.2 Segurança dos dados e compartilhamento ................................................... 70
3.2.3 Facilidade no desenvolvimento ...................................................................... 70
4 CONCLUSÃO ...................................................................................... 72
REFERÊNCIAS BIBLIOGRÁFICAS ................................................... 75
A DIAGRAMA DE CLASSES COMPLETO....................................... 78
B DADOS COLETADOS........................................................................ 81
iii
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
LISTA DE FIGURAS
Figura 1. Comparativo de formas de armazenamento..........................................................................9
Figura 2. Exemplo de modelo de dados relacional. ...........................................................................12
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. ..........................................................................................15
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. ...........................................................................17
Figura 10. Sintaxe para o uso da Herança de tipos. ...........................................................................18
Figura 11. Utilizando OIDs para representar os relacionamentos. ....................................................21
Figura 12. Modelo de objeto do tipo atom. ........................................................................................22
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. .............................................................................25
Figura 16. Persistência de um objeto pelo mecanismo de nomeação. ...............................................25
Figura 17. Persistência de um objeto pelo mecanismo de alcançabilidade........................................26
Figura 18. Declaração de uma classe no padrão ODL. ......................................................................27
Figura 19. Declaração de uma inteface no padrão ODL. ...................................................................28
Figura 20. Herança de comportamento no padrão ODL. ...................................................................28
Figura 21. Herança de estado e comportamento. ...............................................................................28
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. ....................................................29
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é. .......................33
Figura 30. Arquitetura do SGBDOO Caché.......................................................................................34
Figura 31. Armazenamento de um objeto persistente. .......................................................................35
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. ......................................38
Figura 35. Tela da ferramenta Centro de Desenvolvimento do DB2.................................................40
Figura 36. Diagrama de atividades do processo de publicação de documento. .................................43
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. ...........................................................................................47
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. ..........................................................49
Figura 44. Método salvaArquivoDB2 da classe persisteArquivo...................................................50
Figura 45. Exemplo de criação de objeto do banco Caché. ...............................................................53
Figura 46. Criação de uma classe na ferramenta Studio. ...................................................................54
v
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. .................................................................................................56
Figura 50. Tela de submissão de arquivos. ........................................................................................57
Figura 51. Tela de confirmação de arquivo salvo. .............................................................................57
Figura 52. Exemplo de código utilizando a biblioteca commons-fileupload.....................................58
Figura 53. Tela de documentos pendentes de aprovação. ..................................................................59
Figura 54. Tela de aprovação de documentos. ...................................................................................59
Figura 55. Tela de pesquisa de arquivos. ...........................................................................................60
Figura 56. Tela do resultado da pesquisa. ..........................................................................................60
Figura 57. Tela de recuperação do arquivo. .......................................................................................61
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. ............................................................65
Figura 63. Diagrama ER do sistema GEDOO....................................................................................66
Figura 64. Gráfico comparativo entre os tipos de mídia. ...................................................................69
vi
LISTA DE TABELAS
Tabela 1. Comparativo de Banco de dados OO. ................................................................................39
Tabela 2. Comparativo de Banco de dados Objeto-Relacional..........................................................41
Tabela 3. Tabela ARQUIVO..............................................................................................................51
Tabela 4. Tabela VERSAO. ...............................................................................................................51
Tabela 5. Atributos da Classe ArqCh ................................................................................................54
Tabela 6. Resultado dos testes efetuados. ..........................................................................................67
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
RESUMO
LEITE, Marcela. Banco de Dados Orientado a Objetos como Ferramenta para
Armazenamento e Recuperação de Dados Multimídia. Itajaí, 2007. 110 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í, 2007.
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
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
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.
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
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
1.1.1 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.
1.1.2 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
1.2 OBJETIVOS
1.2.1 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.
1.2.2 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
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
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 ObjetoRelacional (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:
•
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
•
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
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
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
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 1992. 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.
2.4.1 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
Figura 2. Exemplo de modelo de dados relacional.
Fonte: Adaptado de Silberschatz; Korth e Sudarshan (2006).
2.4.2 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
é 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.
2.4.3 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
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).
2.4.3.1
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).
2.4.3.2
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
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).
2.4.3.3
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
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).
2.4.3.4
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
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).
2.4.3.5
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 10.
17
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).
2.4.3.6
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
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
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.
2.5.1 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.
2.5.1.1
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
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
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).
2.5.1.2
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
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).
2.5.1.3
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).
2.5.1.4
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
2.5.1.5
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.
2.5.1.6
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
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).
2.5.1.7
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
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).
2.5.1.8
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).
2.5.1.9
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
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.
2.5.2.1
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
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
•
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
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
2.5.2.2
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
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.
2.6.1 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
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
•
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
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.
2.6.2 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
•
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).
2.6.3 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
é apresentado a arquiterura do BDOO Jasmine onde podem ser observados seus principais
componentes.
Figura 33. Arquitetura BDOO Jasmine.
Fonte: Assis (2005).
2.6.4 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
•
Criação de bancos de dados distribuídos;
•
Plataformas heterogêneas; e
•
Suporte nativo a LPOO como Java e C++.
Na Figura 34 é apresentada uma tela da interface de administração do banco de dados
Versant.
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).
2.6.5 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
Tabela 1. Comparativo de Banco de dados OO.
Critério
Definição de dados pelo usuário
Herança Múltipla
Valida cardinalidade entre objetos
Caché
Sim
Sim
Sim
Poet
Não
Não
Não
Suporta transações longas
Linguagem de definição de
atributos
Sim
Java, C++,
Delphi, Visual
Basic e PHP
Sim
Sim
C++
Sim
Sim
Sim
Sim
Sim
Sim
Não
Sim
Sim
Sim
Sim
Não
Somente via
ODBC
Sim
Armazenamento dos métodos no
BD
Compatibilidade com o ODMG
Suporte a SQL
Interface gráfica
Jasmine
Versant
Sim
Sim
Sim
Sim
Apenas no nível
Sim
"0, 1 ou muitos".
Não
Sim
C, C++, ODQL, C, C++, Java
Java
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
2.7.1 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
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 DB2.
2.7.2 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
•
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).
2.7.3 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
Definição de dados pelo usuário
Suporte a dados multidimensionais
Suporte a Objetos Grandes
Linguagem de programação
Armazenamento dos métodos no BD
Armazenamento dados Multimídia
Suporte a Orientação a Objetos
Integração Ferramentas Cases
DB2
Sim
Sim
Sim
Java, C, REXX,
Pearl
Sim
Sim
Sim
Sim
Oracle
Sim
Sim
Sim
Java
Sim
Sim
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
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.
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
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 37.
44
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
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
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
Figura 41. Código do método getArquivosByArea da classe
persisteArquivo.
3.1.1 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
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
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
Tabela 3. Tabela ARQUIVO.
Campo
CODARQUIVO
Tipo
INT (AutoIncrement)
NOMEARQUIVO
VARCHAR
ASSUNTO
VARCHAR
DESCRICAO
VARCHAR
PALAVRASCHAVE VARCHAR
DT_CRIACAO
DATE
HR_CRIACAO
TIME
COD_AREA
VARCHAR
IDUSUARIO
INT
Tamanho Descrição
4
Código do arquivo
Chave primária da tabela
50
Nome do arquivo indicado pelo usuário
50
Assunto relacionado ao arquivo
255
Descrição do arquivo
120
Palavras-chave para pesquisa do arquivo
4
Data de criação do arquivo no sistema
3
Hora de criação do arquivo no sistema
10
Código da área a qual o arquivo está
relacionado
4
Código do usuário que submeteu o arquivo no
sistema.
Tabela 4. Tabela VERSAO.
Campo
CODARQUIVO
CODVERSAO
END_ARQUIVO
ARQUIVO
DT_INCLUSAO
HR_INCLUSAO
DISCO
SITUACAO_ARQ
NMREALARQ
NMORIGARQ
Tipo
INT
Tamanho Descrição
4
Código do Arquivo
Chave Primária da Tabela
INT
4
Código da Versão
Chave primária da tabela
VARCHAR 255
Endereço onde o arquivo está armazenado
utilizado para os casos em que o arquivo é
armazenado em disco
BLOB
4 Mb
Armazena o Arquivo
DATE
4
Data de inclusão da versão do arquivo no
sistema
TIME
3
Hora de inclusão da versão no sistema
INT
4
Indica o tipo de armazenamento do arquivo,
que pode ser 0 – Disco, 1 - DB2 e 2 – Caché
INT
4
Situação do arquivo em relação a sua
aprovação para publicação
VARCHAR 60
Nome real do arquivo, quando o mesmo é
armazenado em disco
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.
3.1.2 Banco de dados OO Caché
51
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
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
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
Codarquivo INT
Codversao
Arquivo
Descrição
Armazena o código do arquivo associado a tabela
VERSAO do banco DB2 que fará o controle dos
arquivos
INT
Armazena o código da versão do 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
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.
3.1.3 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.
3.1.3.1
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
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.
3.1.3.2
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
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
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.
3.1.3.3
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
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
3.1.3.4
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 57.
60
Figura 57. Tela de recuperação do arquivo.
3.1.3.5
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 59.
61
Figura 59. Tela de alteração de arquivos.
3.1.3.6
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.
3.1.4 Diagramas
Nesta seção serão apresentados os principais diagramas desenvolvidos e utilizados para a
implementação do protótipo de sistema GEDOO.
3.1.4.1
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
Figura 60. Diagrama de classes do sistema GEDOO.
3.1.4.2
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
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
Figura 62. Diagrama de Seqüência da pesquisa de arquivos.
3.1.4.3
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
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.
3.2.1 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
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
PDF 1
PDF 2
PDF 3
PDF 4
DOC 1
DOC 2
DOC 3
DOC 4
IMG 1
IMG 2
IMG 3
IMG 4
MP3 1
MP3 2
MP3 3
MP3 4
ZIP 1
ZIP 2
ZIP 3
ZIP 4
Tamanho Tempo Tempo
(Bytes)
Armaz. Armaz.
Disco
DB2
ms
ms
980.104
1.014.909
485.542
5.221.877
803.840
953.856
1.808.896
136.704
1.725.078
24.924
231.249
16.310
4.697.307
3.086.336
3.234.306
3.813.761
2942722
238531
2597334
466249
0
109
62
172
15
16
62
47
47
0
47
62
94
109
203
78
62
16
47
78
2015
312
297
781
234
203
328
78
391
125
140
94
9719
3454
4453
6000
5391
94
4968
922
Tempo
Armaz.
Caché
ms
8000
1704
625
10328
266
235
968
141
2938
141
266
94
6063
2078
2594
2656
1360
141
1266
187
Tempo
Recuperação
Disco
ms
0
32
16
16
437
281
140
125
109
110
109
78
0
0
16
0
0
0
0
0
Tempo
Recuperação
DB2
ms
656
437
62
1125
172
141
515
15
390
16
125
16
625
343
703
719
688
16
234
47
Tempo
Recuperação
Caché
ms
2141
156
157
125
203
109
156
156
109
78
110
78
719
172
94
78
125
110
125
110
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)
Disco
DB2
Caché
75.321
2.037
1.353
67
Recuperação (Bytes/ms)
972.527
5.791
12.698
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).
AVI
Armazena Recupera
gem
ção
MP3
Armazena Recupera
gem
ção
BMP
Armazena Recupera
gem
ção
PDF
Armazena Recupera
gem
ção
Média
Armazena Recupera
gem
ção
DISCO
34.575
0
65.240
0
79.132
0
64.151
0
60.774
-
DB2
3.910
8.365
7.093
19.017
5.021
20.391
8.146
17.223
6.043
16.249
CACHÉ
1.177
54.924
1.558
31.357
3.607
13.169
1.458
50.698
1.950
37.537
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 64.
68
90.000
80.000
70.000
60.000
50.000
40.000
30.000
20.000
10.000
-
DISCO
DB2
AVI
MP3
BMP
Recuperação
Armazenagem
Recuperação
Armazenagem
Recuperação
Armazenagem
Recuperação
Armazenagem
CACHÉ
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
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.
3.2.2 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.
3.2.3 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
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
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
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
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
REFERÊNCIAS BIBLIOGRÁFICAS
APACHE SOFTWARE FOUNDATION. The Apache Jakarta Project. 2005. Disponível em
http://jakarta.apache.org/. Acessado em: 02 mai 2008.
ASSIS, Mateus Calçado. Sistemas de Informação Multimídia para conservação e
democratização de acervos históricos. 2005. 25 f. Monografia (Especialização em Informática,
Ênfase em Tecnologias da Informação e Multimídia) – Universisdade Federal de Minas Gerais,
Belo Horizonte, 2005.
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: <http://www.ca.com/br>. Acesso em: 06 out. 2007.
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, 2005. 46 f.
ELMASRI, Ramez; NAVATHE, B. Shamkant. Sistemas de banco de dados. 4. ed. São Paulo:
Pearson Addison Wesley, 2005.
FANTINI, Sérgio Rubens. Aplicação do gerenciamento eletrônico de documentos: estudo de
caso de escolha de soluções. 2001. 118 f. Dissertação (Mestrado em Engenharia de Produção) Universidade Federal de Santa Catarina, Florianópolis, 2001.
HARRINGTON, Jan L.. Object-oriented database design clearly explained. San Francisco:
Morgan Kaufmann Publishers, 2000.
IBM. Ibm Corporation. Disponível em: <http://www.ibm.com/br>. Acesso em: 01 out. 2007.
INTERSYSTEM. Intersystem Corporation. Disponível em: <http://www.intersystem.com.br>.
Acesso em: 06 out 2007.
JAKARTA. Apache Jakarta Project. Disponível em : http://jakarta.apache.org/. Acessado em 04
mai 2008.
JAVAZOOM. Javazoom.Net. Disponível em:
http://www.javazoom.net/jzservlets/uploadbean/uploadbean.html. Acesso em 02 abr. 2008.
KHOSHAFIAN, Setrag. Banco de dados orientado a objeto. Rio de Janeiro: Infobook, 1994.
NASSU, Eugénio A.; SETZER, Valdemar W. Bancos de dados orientados a objetos. São Paulo:
Edgard Blücher, 1999.
75
NETBEANS. NetBeans IDE. Disponível em: http://www.netbeans.org/products/ide/. Acessado em
03 mar. 2008.
ORACLE. Oracle Corporation. Disponível em: <http://www.oracle.com/global/br>. Acesso em:
01 out. 2007.
RICARTE, Ivan Luiz Marques. Sistemas de bancos de dados orientados a objetos. 1998. 41 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, 1998.
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é. 2008. 10 f.
Iniciação científica (Escola Superior de Criciúma) – Escola Superior de Criciúma, Santa Catarina,
2008.
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. 1999. 18 f. Iniciação científica (Graduando em Ciência da Computação) –
Universidade Federal de Mimas Gerais, Minas Gerais, 1999.
SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de banco de dados.
5. ed. Rio de Janeiro: Elsevier, 2006.
SILVA, Enio Kilder Oliveira da, Um estudo sobre sistemas de banco de dados cliente/servidor.
2001. 99 f. Monografia (Graduação em Processamento de Dados) – Faculdade Paraibana de
Processamento de Dados, João Pessoa, 2001.
SILVA, Ricardo Czelusniak da. Benchmark em banco de dados multimídia: análise de
desempenho em recuperação de objetos multimídia. 2006. 55 f. Dissertação (Mestrado em Ciências
Exatas) – Universidade Federal do Paraná, Curitiba, 2006.
SOUZA, Flávio Rubens de Carvalho. Caché, Banco de dados Pós-relacional. 2005. 49 f.
SUN. Java Servlet Technology. 2008. Disponível em http://java.sun.com/products/servlet/.
Acessado em 15 abr. 2008.
VAUGHAN, Tay. Multimídia na prática. São Paulo: Makron Books, 1994.
VERSANT. Versant Object Technology. Disponível em: < http://www.versant.com>. Acesso em:
06 out. 2007.
76
APÊNDICES
77
A
DIAGRAMA DE CLASSES COMPLETO
Diagrama de Classes do sistema completo:
78
80
B
DADOS COLETADOS
Dados coletados para comparativo de armazenamento e recuperação de dados com
diferentes tipos de mídia.
Disco
VIDEO 1.avi
Bytes
Tamanho
16.312.320
Disco
Arquivo
Arquivo
KB
15.930
MP3 1.MP3
Bytes
Tamanho
4.697.307
Disco
Arquivo
KB
4.587
IMG 1.bmp
Bytes
Tamanho
1.725.078
Disco
Arquivo
KB
1.685
PDF 1.pdf
Bytes
Tamanho
5.221.877
KB
5.099
Tempos em Milisegundos
Armazenamento
Recuperação
1
797
0
2
344
0
3
250
0
4
453
0
5
515
0
Média
471,8
0
Tempos em Milisegundos
Armazenamento
Recuperação
1
62
0
2
79
0
3
78
0
4
63
0
5
78
0
Média
72
0
Tempos em Milisegundos
Armazenamento
Recuperação
1
31
0
2
16
0
3
31
0
4
15
0
5
16
0
Média
21,8
0
Tempos em Milisegundos
Armazenamento
Recuperação
1
78
0
2
94
0
3
78
0
4
79
0
5
78
0
Média
81,4
0
B / ms
B / ms
B / ms
B / ms
34.575
0
DB2
VIDEO 1.avi
Bytes
Tamanho
16.312.320
65.240
0
DB2
Arquivo
15.930
0
DB2
Arquivo
KB
MP3 1.MP3
Bytes
Tamanho
4.697.307
79.132
4.587
0
DB2
Arquivo
KB
IMG 1.bmp
Bytes
Tamanho
1.725.078
64.151
Arquivo
KB
1.685
PDF 1.pdf
Bytes
Tamanho
5.221.877
KB
5.099
Tempos em Milisegundos
Armazenamento
Recuperação
1
4968
2188
2
3687
2047
3
5953
1859
4
3297
1750
5
2953
1906
Média
4171,6
1950
Tempos em Milisegundos
Armazenamento
Recuperação
1
531
219
2
593
235
3
625
313
4
578
250
5
984
218
Média
662,2
247
Tempos em Milisegundos
Armazenamento
Recuperação
1
468
79
2
265
78
3
344
78
4
297
94
5
344
94
Média
343,6
84,6
Tempos em Milisegundos
Armazenamento
Recuperação
1
907
531
2
579
234
3
563
235
4
578
266
5
578
250
Média
641
303,2
B / ms
B / ms
B / ms
B / ms
3.910
8.365
Caché
VIDEO 1.avi
Bytes
Tamanho
16.312.320
19.017
Caché
Arquivo
Tempos em Milisegundos
7.093
15.930
Tempos em Milisegundos
20.391
Caché
Arquivo
KB
MP3 1.MP3
Bytes
Tamanho
4.697.307
5.021
4.587
Tempos em Milisegundos
17.223
Caché
Arquivo
KB
IMG 1.bmp
Bytes
Tamanho
1.725.078
8.146
Arquivo
KB
1.685
PDF 1.pdf
Bytes
Tamanho
5.221.877
Tempos em Milisegundos
KB
5.099
1
2
3
4
5
Média
B / ms
Armazenamento
Recuperação
13250
922
13937
172
13672
125
14890
141
13546
125
13859
297
1.177
54.924
1
2
3
4
5
Média
B / ms
Armazenamento
Recuperação
2844
109
2844
125
2844
125
3094
296
3453
94
3015,8
150
1.558
31.357
83
1
2
3
4
5
Média
B / ms
Armazenamento
Recuperação
312
125
547
125
375
156
407
140
750
109
478,2
131
3.607
13.169
1
2
3
4
5
Média
B / ms
Armazenamento
Recuperação
3593
94
3250
109
3343
109
4438
94
3282
109
3581,2
103
1.458
50.698