Embed Size (px)
DESCRIPTION
ESTUDO COMPARATIVO ENTRE BANCOS DE DADOS RELACIONAIS E ORIENTADOS A OBJETOS VISANDO APLICAÇÕES COMERCIAIS
Citation preview
0
INSTITUTO LUTERANO DE ENSINO SUPERIOR DE ITUMBIARA-GOIÁS
CURSO DE SISTEMAS DE INFORMAÇÃO
GETÚLIO DE OLIVEIRA VALENTIM
ESTUDO COMPARATIVO ENTRE BANCOS DE DADOS RELACIONAIS E
ORIENTADOS A OBJETOS VISANDO APLICAÇÕES COMERCIAIS
Itumbiara, junho de 2013
1
GETÚLIO DE OLIVEIRA VALENTIM
ESTUDO COMPARATIVO ENTRE BANCOS DE DADOS RELACIONAIS E
ORIENTADOS A OBJETOS VISANDO APLICAÇÕES COMERCIAIS
Projeto de Monografia apresentado ao curso de Sistemas de Informação, do Instituto Luterano de Ensino Superior de
Itumbiara-GO, como requisito parcial para obtenção do titulo
de Bacharel em sistemas de informação, orientado pelo
professor Bruno Souto Borges.
Itumbiara, junho de 2013.
2
Dados Internacionais de Catalogação na Publicação (CIP)
Bibliotecária Maria Lúcia Silva – CRB1 1417
V155e
Valentim, Getúlio de Oliveira
Estudo comparativo entre bancos de dados relacionais e orientados a
objetos visando aplicações comerciais. / Getúlio de Oliveira Valentim - 2013.
78 f. ; 21cm x 29,7 cm.
Trabalho de Conclusão de Curso (Bacharel em Sistemas de Informação)
ULBRA - Instituto Luterano de Ensino Superior de Itumbiara Goiás, 2013.
Orientador Prof. Bruno Souto Borges.
1. Sistema de Informação. 2. Banco de dados . 3. Linguagem de
programação. 4. Desenvolvimento de software.
CDU 004.4
3
ESTUDO COMPARATIVO ENTRE BANCOS DE DADOS RELACIONAIS E
ORIENTADOS A OBJETOS VISANDO APLICAÇÕES COMERCIAIS
GETÚLIO DE OLIVEIRA VALENTIM
Monografia defendida e aprovada, em 25 de Junho de 2013, pela banca examinadora:
Professor Especialista Bruno Souto Borges
Orientador e Professor do Curso de Sistemas de Informação
Professor Hulgo Leonardo Jacinto Andrade
Professor do Curso de Sistemas de Informação
Professor Fabio Palhares dos Santos
Professor do Curso de Sistemas de Informação
4
Dedico este trabalho primeiramente aos meus queridos
pais que sempre me deram apoio. À toda minha família, minha
namorada, meus amigos, professores e a todos que me ajudaram a
conquistar o maior objetivo da minha vida.
5
AGRADECIMENTOS
Aos meus pais, por tudo que fizeram por min durante está etapa da minha vida
pelo apoio, dedicação, compreensão e esforço para que eu conseguise meu sonho.
A minha namorada, pela compreensão e o incentivo.
Ao professor Bruno Souto Borges, que com sua experiência e seus ensinamentos
durante toda a orientação me mostrou o caminho e me ajudou para que o trabalho fosse
concluido.
A todos os professores que me acompanharam e compartilharam um pouco de seu
conhecimento. Para que eu pudesse concluir o curso de Bacharel Em Sistemas De Informção
e me tornar um bom profissional.
Aos meus colegas de sala, não só pela amizade. Mas pela colaboração que me
deram em relação as disciplinas cursadas durante o curso.
E por fim agradeço a todas as pessoas que de alguma forma, contribuíram para
que eu chegasse até onde cheguei. Mesmo quando não tive confiança de que conseguiria. Isto
inclui todo o corpo docente que lecionou para min, dos quais alguns deles não estão mais
presentes no ILES/ULBRA.
6
―Não deixe o barulho da opinião dos outros abafar sua voz interior. E
mais importante, tenha a coragem de seguir seu coração e sua
intuição. Eles de alguma forma já sabem o que você realmente quer se
tornar. Tudo o mais é secundário‖. (Steve Jobs)
7
RESUMO
Com a quantidade de informações crescentes que vem ocorrendo nos últimos anos, se vê hoje
a necessidade do armazenamento de dados de formas mais eficientes, seguras, estáveis,
viáveis e fáceis para armazenamento destes dados. Além da utilização hoje de Banco de dados
Relacionais, outro paradigma que está tomando o mercado meio tímido ainda, mas que vem
crescendo é o paradigma Orientado a Objetos. À medida que as bases de dados foram sendo
utilizadas em um âmbito maior de aplicações, as limitações impostas pelo modelo relacional
emergiram como obstáculos. Como resultado, pesquisadores da área de bancos de dados
inventaram novos modelos de dados que superassem as restrições do modelo relacional. Este
projeto avalia os modelos de banco de dados relacionais e orientados a objetos, comparando-o
através de um software para fazer inúmeras inserções de dados, e quadros comparativos com
os principais pontos dos bancos de dados, apresentando suas características e diferenças,
vantagens e desvantagens e o desempenho de cada um dos modelos estudados a fim de
demonstrar qual o modelo é mais vantajoso no desenvolvimento de aplicações comerciais.
Fez - se o uso da linguagem de programação Java IDE NetBeans e os bancos de dados SQL
Server 2012 e PostgreSQL como bancos relacionais e o db4objects como banco de dados
orientado a objetos. Para o desenvolvimento do software foram realizadas coletas de dados, a
aplicação da UML para uma melhor estruturação e visualização lógica do desenvolvimento do
software e o uso de fundamentos da engenharia de software durante o projeto e toda a
implementação do software. Chegando a conclusão que para o uso no desenvolvimento de
aplicações comerciais que utilizam dados não tão complexos o melhor banco de dados a ser
adotado é o relacional por ser um banco de dados que possui uma linguagem de consulta
muito bem definida com varias ferramentas que auxiliam estas consultas e o manuseio de
dados, e também por ser mais popular e possuir uma maturidade maior por estar no mercado
há mais tempo.
Palavras Chave: Banco de dados, vantagens, desvantagens, características, desempenho
8
ABSTRACT
With the growing amount of information that has been occurring in recent years, we see today
the need for data storage more efficient ways, secure, stable, viable and easy to store these
data. In addition to using today Relational Database, another paradigm that is taking the
market still kind of shy, but that has been growing is the Object-Oriented paradigm. As the
databases were being used in a larger scope of applications, the limitations imposed by the
relational model emerged as obstacles. As a result, researchers in databases invented new data
models that outweigh the restrictions of the relational model. This project evaluates models of
relational databases and object-oriented, comparing it using software to do many inserts data
and comparative tables with the main points of the databases, presenting their characteristics
and differences, advantages and disadvantages and performance of each of the models studied
to demonstrate which model is more advantageous in the development of commercial
applications. Fez - the use of the Java programming language and NetBeans IDE databases
SQL Server 2012 and PostgreSQL as relational databases and db4objects as database object-
oriented. For software development data were collected, the application of UML for better
structuring and logical view of the development of software and the use of fundamentals of
software engineering during the whole design and implementation of software. Reaching the
conclusion that for use in developing commercial applications that use data not so complex
the best database to be adopted is to be a relational database that has a query language very
well defined with several tools that help these queries and data handling, and also to be more
popular and have a maturity greater for being on the market longer.
Keywords: Database, advantages, disadvantages, features, performance
9
LISTA DE FIGURAS
Figura 1 - Sistema de Banco de Dados ..............................................................................................19
Figura 2 - Componentes de um SGBD ..............................................................................................22
Figura 3 - Componentes do módulo gerente de banco de dados .........................................................23
Figura 4 - Exemplo de armazenamento em tabela ..............................................................................25
Figura 5 - Representação dos conceitos do modelo relacional ............................................................26
Figura 6 - Definição de dados SQL ...................................................................................................29
Figura 7 - Armazenamento de objetos em B.D relacional e no db4o ..................................................49
Figura 8 - Interface do SQL Server Management Studio ....................................................................54
Figura 9 - Interface do PostgreSQL ...................................................................................................55
Figura 10 - Tabela criada no PostgreSQL ..........................................................................................56
Figura 11 - Tela do Software de teste de inserção ..............................................................................59
Figura 12 - Comando SQL para criar tabela no SQL Server 2012 ......................................................61
Figura 13 - Tabela criada no SQL Server 2012 ..................................................................................61
Figura 14 - Comando SQL para criar tabela no PostgreSQL ..............................................................62
Figura 15 - Tabela criada no PostgreSQL ..........................................................................................62
Figura 16 - Declaração da classe para armazenar dados do db4o ........................................................63
Figura 17 - Gráfico do teste de inserção nos bancos de dados. ...........................................................65
10
LISTA DE TABELAS
Tabela 1 - Teste de inserção nos bancos de dados ..............................................................................64
Tabela 2 - Comparativo entre funcionalidades dos bancos .................................................................67
11
SUMÁRIO
INTRODUÇÃO .................................................................................................................. 14
2. CAPÍTULO I - REFERENCIAL TEÓRICO ............................................................ 17
2.1. INTRODUÇÃO ......................................................................................................... 17
2.2. BANCO DE DADOS ................................................................................................ 17
2.3. MODELOS DE DADOS .......................................................................................... 18
2.4. SISTEMA DE BANCO DE DADOS ........................................................................ 19
2.4.1 Dados................................................................................................................... 19
2.4.2 Hardware ............................................................................................................. 20
2.4.3 Software ............................................................................................................... 20
2.4.4 Usuários .............................................................................................................. 20
2.5. COMPONENTES DE UM SGBD ............................................................................. 21
2.6. TIPOS DE BANCO DE DADOS............................................................................... 23
2.7. CICLO DE VIDA DE UM BANCO DE DADOS ...................................................... 24
2.8. MODELO RELACIONAL ....................................................................................... 25
2.8.1. Chaves Primárias e Chaves estrangeiras ............................................................. 26
2.8.2. Integridade de dados ........................................................................................... 27
2.8.3. Normalização ...................................................................................................... 28
2.8.4. SQL ..................................................................................................................... 29
2.8.4.1. Aplicabilidade da linguagem SQL .................................................................... 29
2.8.5. Limitações do modelo relacional ......................................................................... 30
2.9. BANCO DE DADOS ORIENTADO A OBJETOS .................................................... 31
2.9.1. Incorporação de orientação a objetos a sistemas de banco de dados ................... 32
2.9.2. Estrutura e características .................................................................................. 33
2.9.4. Identidade de objeto (OID) .................................................................................. 35
2.9.5. Estrutura do objeto ............................................................................................. 36
2.9.6. Objetos complexos .............................................................................................. 36
2.9.7. Encapsulamento, nomeação e acessibilidade ....................................................... 37
2.9.8. Persistência de dados .......................................................................................... 37
2.9.9. Banco de dados OO no mercado ......................................................................... 38
2.9.10. ODMG (Object Database Management Group) ................................................. 39
2.9.10.1 Object Definition Language (ODL) – Linguagem de definição de dados ......... 40
2.9.10.2 Object Query Language (OQL) – Linguagem de consulta de objetos ............... 40
2.9.10.3 Modelo de objetos ........................................................................................... 41
2.9.10.4 Acoplamento com linguagens de programação orientadas a objetos. ................ 41
12
2.10.VANTAGENS E DESVANTAGENS DOS MODELOS RELACIONAIS E
ORIENTADO A OBJETOS ............................................................................................. 41
2.10.1. Vantagens do Modelo Relacional ...................................................................... 41
2.10.2. Desvantagens do Modelo Relacional ................................................................. 42
2.10.3. Vantagens do Modelo de Objetos ...................................................................... 42
2.10.4. Desvantagens do Modelo de Objetos ................................................................. 43
2.11. LINGUAGEM PROGRAMAÇÃO ORIENTADA A OBJETOS ............................. 44
2.11.1. Conceitos da Orientação a Objetos ................................................................... 44
2.11.1.1. Abstração ....................................................................................................... 45
2.11.1.2. Encapsulamento ............................................................................................. 45
2.11.1.3. Herança .......................................................................................................... 45
2.11.1.4 Polimorfismo ................................................................................................... 46
2.11.2. Benefícios da POO ............................................................................................ 46
2.11.2.1. Produtividade ................................................................................................. 46
2.11.2.2. Ciclo de vida maior ........................................................................................ 47
2.12. CONSIDERAÇÕES FINAIS ................................................................................... 47
3. CAPÍTULO II – SGBD UTILIZADOS NA AVALIAÇÃO .......................................... 48
3.1. INTRODUÇÃO ......................................................................................................... 48
3.2. BANCO DE DADOS ORIENTADO A OBJETOS - DB4OBJECTS (DB4O) ........... 48
3.2.1. Definição e manipulação de dados ...................................................................... 49
3.3. BANCO DE DADOS RELACIONAL - SQL SERVER 2012 .................................... 53
3.3.1. Ferramentas de gerenciamento projeto e consulta ............................................... 53
3.3.1.1. SQL Server Management Studio ...................................................................... 53
3.4.BANCO DE DADOS RELACIONAL - POSTGRESQL ............................................ 54
3.5. CONSIDERAÇÕES FINAIS ..................................................................................... 56
4. CAPÍTULO III – METODOLOGIA............................................................................. 57
4.1. INTRODUÇÃO ......................................................................................................... 57
4.2. METODOLOGIA UTILIZADA ................................................................................ 57
4.3. CONSIDERAÇÕES FINAIS ..................................................................................... 58
5. CAPÍTULO IV – SOFTWARE UTILIZADO NO TESTE .......................................... 59
5.1. INTRODUÇÃO ......................................................................................................... 59
5.2. O SOFTWARE.......................................................................................................... 59
5.3. SOFTWARES UTILIZADOS NO PROJETO ........................................................... 60
5.4. SQL SERVER X POSTGRESQL X DB4O ............................................................... 60
5.4.1. SQL Server 2012 ................................................................................................. 60
5.4.2. PostgreSQL ......................................................................................................... 61
5.4.3.db4objects ............................................................................................................ 62
5.5. TESTE....................................................................................................................... 63
5.5.1. Inserção .............................................................................................................. 64
5.6. CONSIDERAÇÕES FINAIS ..................................................................................... 65
6. CAPÍTULO V – COMPARATIVO ............................................................................... 66
6.1. INTRODUÇÃO ......................................................................................................... 66
13
6.2. COMPARATIVO DE FUNCIONALIDADES .......................................................... 66
6.3. DESCRIÇÃO DAS FUNCIONALIDADES .............................................................. 68
6.4. CONSIDERAÇÕES FINAIS ..................................................................................... 70
7. CAPÍTULO VI - ANALISES E RESULTADOS .......................................................... 71
7.1. INTRODUÇÃO ......................................................................................................... 71
7.2. ANALISES E RESULTADOS .................................................................................. 71
7.3. CONSIDERAÇÕES FINAIS ..................................................................................... 72
8. CAPÍTULO VII – CONCLUSÕES E TRABALHOS FUTUROS ............................... 73
8.1. INTRODUÇÃO ......................................................................................................... 73
8.2. CONCLUSÕES ......................................................................................................... 73
8.3. TRABALHOS FUTUROS ........................................................................................ 74
REFERÊNCIA BIBLIOGRÁFICA .................................................................................. 75
14
INTRODUÇÃO
Com a quantidade de informações crescentes que vem ocorrendo nos últimos
anos, se vê hoje a necessidade do armazenamento de dados de formas mais eficientes,
seguras, estáveis, viáveis e fáceis para o armazenamento destes dados, que hoje em dia não
ficam mais só em caracteres ou simples dados numéricos, mas em grandes quantidades de
dados como imagens, vídeos, filmes, áudios e dados mais complexos.
Date (2004), define banco de dados como: ―conjuntos de dados com uma estrutura
regular que organizam informação, ou seja, é um conjunto de registros dispostos em estrutura
regular que possibilita a reorganização dos mesmos e produção de informação‖.
Além da utilização hoje de Banco de dados Relacionais que vem sendo muito bem
sucedido em aplicações comerciais, mas que apresenta algumas limitações quando aplicações
de banco de dados mais complexas precisam ser projetadas e implementadas, outro paradigma
que está tomando o mercado meio que tímido ainda, mas que vem crescendo é o paradigma
Orientado a Objetos.
Com base nisso o presente estudo, tem como tema o estudo comparativo entre
bancos de dados relacionais e orientados a objetos visando aplicações comerciais, procurando
responder especificamente ao seguinte problema: ―Qual o melhor modelo de banco de dados a
ser adotado no desenvolvimento de aplicações comerciais?‖
A relevância deste estudo justifica-se pelo fato de que à medida que as bases de
dados foram sendo utilizadas em um âmbito maior de aplicações, a demanda por maneiras de
se tratar dados mais complexos tem crescido e as limitações impostas pelo modelo relacional
emergiram como obstáculos. Percebe-se ai então a necessidade de se conhecer outros
paradigmas que possam suprir esta carência deixada pelo o modelo relacional. Pensando nisso
teve-se a idéia de se fazer uma comparação entre o Banco de Dados Relacional e o Banco de
dados Orientado a Objetos, buscando descrever diferenças, características, vantagens e
15
desvantagens de cada um desses dois modelos, tornando relevante o desenvolvimento do
trabalho.
O objetivo geral é fazer um estudo comparativo, com o intuito de avaliar as
características de um banco de dados orientado a objetos e um banco de dados relacional,
apresentando qual é o banco de dados mais adequado para o desenvolvimento de aplicações
comerciais. Para se conseguir este objetivo, será feita uma apresentação de vantagens e
desvantagens de cada um dos modelos. Para avaliar essas vantagens e desvantagens será
necessária a utilização de um quadro comparativo com várias funcionalidades de cada um dos
modelos apresentados e o desenvolvimento de um software para testar os modelos acima
citados. Para que se possa chegar a esse objetivo geral é preciso que se cumpram os seguintes
objetivos específicos:
Verificar por meio de uma pesquisa bibliográfica, o uso de banco de dados
Relacional e o banco de dados Orientados a Objetos;
Realizar a modelagem dos Bancos de dados Relacionais e Orientados a Objetos
para realização dos testes;
Através de um software fazer inúmeras inserções de dados nos dois tipos de
bancos, a fim de buscar vantagens e desvantagens; com o intuito de descrever
se o banco de dados orientado a objetos é vantajoso e mostrar quais os casos
em que ele poderá obter melhores desempenhos.
Desenvolver um quadro comparativo entre os dois modelos;
A linguagem escolhida para o desenvolvimento do software foi Java pelo fato de
ser orientada a objetos e ser compatível tanto com o modelo de dados relacional quanto com o
modelo orientado a objetos, é uma linguagem muito utilizada atualmente, além de ser gratuita
e multiplataforma.
O software desenvolvido irá se conectar a dois bancos de dados relacionais, o
PostgreSQL escolhido por ser considerado por muitos como sendo o banco de dados de
código aberto mais avançado atualmente (BONFIOLI, 2006), e o SQL Server 2012 escolhido
por ser um dos bancos de dados pagos mais utilizados nas grandes empresas, e também
fornece uma grande coleção de ferramentas gráficas e assistentes que ajudam a orientar os
administradores de banco de dados em várias tarefas (SILBERSCHATZ, 2006). E também
será conectado a um banco de dados orientado a objetos o db4objetcs que foi escolhido por
ser de código aberto, executar de forma confiável tarefas utilizando de poucas linhas de
código, não importando a complexidade das estruturas, pela rapidez de inserção, por utilizar
16
pouco recurso computacional e ter fácil aprendizado (MACHADO, 2009). Foram escolhidos
dois modelos relacionais sendo um de código aberto e um pago, para a comparação com um
orientado a objetos de código aberto, pela necessidade de se comparar em qual dos ambientes
o banco orientado a objetos se sai melhor.
Devido à utilização de dados mais complexos em um número maior de aplicações,
o modelo de dados relacional apresentou algumas restrições. A hipótese então é de que pelo
fato de haver a necessidade de se utilizar ferramentas mais potentes, modernas e capazes, o
banco de dados orientado a objetos futuramente possa a vim a suprir esta carência deixada
pelo modelo relacional de forma consistente e objetiva.
Esta monografia está estruturada em introdução, sete capítulos e referencial
bibliográfico. Na primeira parte é feita uma introdução do estudo, onde são apresentados os
objetivos gerais e específicos da pesquisa e a justificativa para a escolha do tema.
No capítulo um, é apresentado o referencial teórico da pesquisa, onde revisões
bibliográficas foram feitas a fim de apresentar suas principais características.
O capítulo dois apresenta as principais características dos SGBD propostos para o
estudo, que são: db4objects (db4o), SQL Server 2012 e PostgreSQL.
No capítulo três, está estruturada a metodologia de trabalho dessa pesquisa, com
suas características de desenvolvimento.
O capítulo quatro apresenta as principais características do software de teste, os
softwares que foram utilizados para sua construção e sua estruturação, os códigos utilizados
em cada banco testado, e os resultados de inserção.
Nos capítulos cinco e seis, estão descritos respectivamente o comparativo e as
analises e resultados da pesquisa.
No capítulo sete está descrito a conclusão do trabalho.
Por fim estão referenciadas as bibliografias que deram todo o suporte para o
desenvolvimento desta monografia.
17
2. CAPÍTULO I - REFERENCIAL TEÓRICO
2.1. Introdução
Os bancos de dados e sua tecnologia têm um impacto muito importante sobre o
uso crescente dos computadores. É correto afirmar que os bancos de dados desempenham um
papel fundamental em quase todas as áreas em que se utilizam computadores, incluindo
negócios, comércio eletrônico, engenharia, medicina, genética, direito, educação e várias
outras que hoje em dia são muitas.
Serão abordadas neste capítulo as características dos modelos de banco de dados
relacional e orientados a objetos, descrevendo suas características que são relevantes para a
realização deste trabalho.
2.2. Banco de dados
Segundo Date (2004), bancos de dados são conjuntos de dados com uma estrutura
regular que organizam informação, ou seja, é um conjunto de registros dispostos em estrutura
regular que possibilita a reorganização dos mesmos e produção de informação. Essas
estruturas costumam ter a forma de tabelas: cada tabela é composta por linhas e colunas.
Informações utilizadas para um mesmo fim são agrupadas num banco de dados. A
apresentação dos dados pode ser semelhante à de uma planilha eletrônica, porém os sistemas
de gestão de banco de dados possuem características especiais para o armazenamento,
classificação e recuperação dos dados.
Um banco de dados é uma coleção de dados relacionados que pode ser armazenada
sob alguma forma física. Os dados armazenados em um banco de dados representam algum aspecto específico do mundo real — um universo de discurso de onde os
dados são obtidos — e apresentam algum grau de coerência lógica entre seus
componentes. Portanto, uma coleção aleatória de dados não constitui um banco de
dados. (RICARTE, 1998)
18
Nos sistemas computacionais, as bases de dados são mantidas e acessadas por
meio de um software conhecido como Sistema Gerenciador de Banco de Dados (SGBD).
―Normalmente um SGBD adota um modelo de dados, de forma pura, reduzida ou estendida.
Muitas vezes o termo banco de dados é usado, de forma errônea, como sinônimo de SGBD‖
(SILBERSCHATZ, 2006).
No início dos anos 60, foram lançados os primeiros sistemas gerenciadores de
banco de dados (SGBD), que tinham como objetivo principal aumentar a produtividade nas
atividades que envolviam o desenvolvimento e a manutenção dos sistemas, que naquela época
eram realizados totalmente de forma artesanal utilizando de linguagens de programação
convencionais de primeira e segunda geração. Natural de ambientes de mainframes, os SGBD
aumentaram satisfatoriamente a sua popularidade quando começaram a ser utilizados os
microcomputadores. A partir destes acontecimentos cada vez mais as fronteiras entre os dois
mundos vem se estreitando e a concorrência pelo domínio de mercado de SGBD, tem levado
os fabricantes a investirem mais e sofisticarem os seus produtos. A cada versão nova lançada
no mercado uma grande novidade, sendo interfaces novas que facilitam a sua utilização,
algumas ferramentas de apoio ao desenvolvimento, vários utilitários para o gerenciamento de
BD e facilidades para extração e a manipulação dos dados armazenados. ―Essa evolução vem
tornando o trabalho de programadores, analistas e usuários menos artesanal, com reflexos na
qualidade e produtividade‖ (SILBERSCHATZ, 2006).
De acordo com Silberschatz (2006), SGBD são projetados para gerenciar uma
grande quantidade de informação. O gerenciamento destes dados envolve definir estruturas
para o armazenamento da informação e fornecer mecanismo para que se possa realizar a
manipulação destas informações. Além disso, o SGBD precisa garantir a segurança das
informações armazenadas, apesar das falhas de sistema ou de tentativas de acesso não
autorizado.
2.3. Modelos de dados
Vieira (2003), diz que modelos de dados são veículos para descrever a realidade.
Um modelo de dados é uma coleção de conceitos que podem ser usados para descrever um
conjunto de dados e operações para manipular os dados. Os modelos de dados servem de base
para o desenvolvimento de SGBD.
Distinguem-se dois tipos de modelos de dados:
• Modelos conceituais, que são ferramentas para representar a realidade em alto
nível de abstração;
19
• Modelos lógicos, que suportam descrições de dados que podem ser processados
por um computador (ex: modelos relacional, hierárquico, em redes). Esses
modelos são facilmente mapeados para a estrutura física do banco de dados.
2.4. Sistema de banco de dados
Para Date (2004), um sistema de banco de dados é ―um sistema computadorizado cuja
finalidade geral é armazenar informações e permitir que os usuários busquem e atualizem
essas informações quando as solicitar‖. Ainda segundo Date (2004), um sistema de banco de
dados é composto por quatro componentes principais: dados, hardware, software e usuários.
Figura 1 - Sistema de Banco de Dados
Fonte: Date, 2004
2.4.1 Dados
Para Elmasri e Navathe (2011), dados são ―fatos conhecidos que podem ser
registrados e possuem significado implícito‖, Pensados assim um dado pode ser qualquer
elemento que em sua forma bruta não conduz a uma compreensão de determinado fato ou
situação.
Desta forma um número de cadastro, número de peças em um estoque, número de
horas trabalhadas por um funcionário, é um dado, pois é um fato conhecido, representado
como dados alfanuméricos sendo passível de registro.
20
2.4.2 Hardware
São os elementos físicos que compõe os sistemas de banco de dados, como mídias de
armazenamento, os canais de entrada e saída, entre outros. Para Date (2004) os componentes
de hardware do sistema consistem em:
• Volumes de armazenamento secundário: discos magnéticos que são usados
para manter os dados armazenados, juntamente com dispositivos de E/S
associados.
• Processadores de hardware e memória principal associada, que é usado
para dar suporte à execução do software do sistema de banco de dados.
2.4.3 Software
São os SGBD ( Sistema de gerenciamento de banco de dados), o SGBD é um
conjunto de software responsável por gerenciar a base de dados. Seu principal objetivo é
gerenciar o acesso, a manipulação e a organização dos dados armazenados.
Para Date (2004), a função geral oferecida pelo SGBD, é a de ―isolar os usuários
do banco de dados dos detalhes no nível de hardware‖. Ele oferece aos usuários uma visão do
banco de dados um tanto elevada acima do nível de hardware, e admite operações do usuário
que são expressas em termos dessa visão de nível mais elevado.
2.4.4 Usuários
Segundo Elmasri e Navathe (2011), Alguns usuários estão interessados no
conteúdo do banco de dados, pois necessitam dos dados lá armazenados para desenvolverem
suas atividades diárias. Outros, porém, tem contato com o banco apenas para manter o sistema
funcionando corretamente.
Para Date (2004), existem três categorias de usuário:
• Programador de aplicação: desenvolve programas sobre o banco de dados,
ou seja, cria aplicações que acessarão o sistema de banco de dados;
• Usuário final: público que consulta e atualiza o banco de dados utilizando-se,
geralmente, das aplicações desenvolvidas pelos componentes da classe de
usuários anterior. Pode ter conhecimentos da área de tecnologia da informação
(TI);
• Administrador de banco de dados (DBA): responsável por gerir o SGDB.
21
2.5. Componentes de um SGBD
Para Côrtes (2001), um SGBD é composto por diversos componentes de
softwares, tendo cada um uma função operacional específica. Muitas funcionalidades dos
SGBD são apoiadas por funções dos sistemas operacionais, tais como exclusividade de acesso
a arquivos, prioridades de execução dos processos, etc. Assim o SGBD deve ser construído
em camadas acima dos sistemas operacionais buscando sempre utilizar destes serviços.
Os principais componentes de SGBD segundo Côrtes (2001) são:
Processador de Consulta: transforma as consultas submetidas aos SGBD
em uma série de instruções de baixo nível para o gerente de Banco de
Dados.
Gerente de Banco de Dados: Recebe as solicitações enviadas pelo
processado de consulta, e examina os esquemas externos e conceitual para
determinar que registros são necessários.
Gerente de Arquivos: Manipula os arquivos para armazenamento e
gerencia a alocação dos espaços em disco.
Processador de DML: converte os comandos DML (Data Manipulation
Language) embutidos nos programas de aplicação em chamadas de
funções padrões das linguagens hospedeiras.
Compilador de DDL: converte os comandos DDL (Data Definition
Language) em um conjunto de tabelas contendo as meta-informações
(metadados).
Gerente de Dicionário: gerencia o acesso e mantém os dados no
dicionário.
Controle de Autorização: verifica se o usuário possui autorização
necessária sobre o recurso solicitado para executar a operação desejada.
Processador de Comando: Feita a verificação e certificação de que o
usuário possuía a autorização necessária para utilizar o recurso, o controle
é passado para este módulo que coordena a execução da instrução.
Verificador de Integridade: para operações que alterem o banco de
dados, este verifica se a operação desejada irá satisfazer as restrições do
banco tais como integridade, chaves e domínios de atributos, etc.
Otimizador de Consulta: determina a melhor estratégia para execução da
consulta.
22
Gerente de Transação: executa comandos necessários pelas operações
recebidas das transações.
Scheduler (Escalonador): responsável por assegurar que as operações
processadas no banco ocorram sem conflitos com outras operações.
Gerente de Recuperação: responsável por assegurar que o banco
permaneça em um estado consistente em casos de falhas lógicas ou físicas
no sistema.
Gerente de Buffer: responsável por transferir dados entre a memória
principal e o armazenamento secundário, tal como disco ou fita.
Figura 2 - Componentes de um SGBD
Fonte: Côrtes, 2001
23
Figura 3 - Componentes do módulo gerente de banco de dados
Fonte: Côrtes, 2001
2.6. Tipos de banco de dados
Para Erinaldo (2012), existem dois tipos de banco de dados encontrados na gestão
de banco de dados, são eles:
Banco de Dados Operacionais: Este tipo de banco de dados é usado
principalmente em cenários de processamento de transações on-line
(OLTP), ou seja, em situações onde é necessário recolher, modificar e
manter dados em uma base que seja diária. O tipo de dados que se
armazena em um banco de dados operacional é dinâmico, isto significa
que dentro do banco ocorrem constantes mudanças que refletem
constantemente nas informações armazenadas.
24
Banco de Dados Analíticos: Este tipo de banco de dados é usado
principalmente em cenários de processamento analítico on-line (OLAP),
ou seja, em situações onde é necessário armazenar e controlar dados
históricos e depende de tempo. O banco de dados analítico é um recurso
muito valioso quando se tem a necessidade de acompanhar as tendências,
veda dados estatísticos durante um longo período de tempo, e fazer
projeções de negócios táticas ou estratégicas. Este tipo de banco de dados
armazena dados estáticos, que são dados que nunca ou muito raramente é
modificado.
Ainda segundo Erinaldo (2012), bancos de dados analíticos se alimentam de
banco de dados operacionais, assim pode se perceber certa associação entre eles, no entanto
eles executam tipos muito específicos de processamento de dados, necessidades, e a criação
de suas estruturas requerem metodologias de projeto completamente diferentes umas das
outras.
2.7. Ciclo de vida de um banco de dados
O ciclo de vida de um banco de dados é o conjunto de fases que compreende
desde a criação até a manutenção e a evolução do banco de dados.
O ciclo de vida de um banco de dados incorpora os passos básicos envolvidos na
concepção de um esquema global do banco de dados lógico, alocando dados através
de uma rede de computadores, e definindo um esquema local para um SGBD
específico. Uma vez que o projeto esteja completo, o ciclo de vida continua com a
implementação e manutenção do banco de dados. (ERINALDO, 2012)
De acordo com a Microsoft (2013), o DLM (banco de dados de gerenciamento de
ciclo de vida), é uma abordagem que se baseia em políticas para poderem gerenciar banco de
dados e os ativos dos dados. DLM não é um produto mas uma abordagem bem abrangente
para o gerenciamento de esquemas de banco de dados, os dados e metadados para um
aplicativo de banco de dados. A abordagem e pró-ativa para DML consegue fazer com que a
organização consiga gerenciar todos os recursos de dados acompanhando os níveis adequados
dos dados, proteção, disponibilidade e os custos. A DML divide-se em: primeira parte com a
discussão do projeto e intenção, continua com o desenvolvimento do banco de dados, teste,
construção, implantação, manter, monitorar e as atividades de backup, e termina com o
arquivo dos dados.
25
2.8. Modelo Relacional
Segundo Elmasri e Navathe (2011), o Modelo Relacional (MR) é um modelo de
dados representativo (ou de implementação) proposto por Ted Codd, em 1970. O modelo
fundamenta-se em conceitos da matemática – teoria dos conjuntos e lógica de predicado. Os
primeiros sistemas comerciais baseados no MR foram disponibilizados em 1980 e desde então
ele vem sendo implementado em muitos sistemas, tais como Access, Oracle, MySQL, entre
outros.
Para Bonfioli (2006), dentre os modelos existentes hoje, o modelo relacional se
mostrou ser o mais flexível e adequado a solucionar os inúmeros problemas que se colocam
ao nível de desenvolvimento e implementação da base de dados. Ainda segundo Bonfioli
(2006), a estrutura fundamental do modelo relacional é a relação. Uma relação (Tabela) é
constituída por um ou mais atributos (Campos), que mostram o tipo de dados que deve ser
armazenado. Cada instância do esquema (linha) designa por uma tupla (registro). O modelo
relacional armazena dados de forma estruturada em tabelas. Mas para se trabalhar com estas
tabelas tiveram-se que se impor algumas restrições para evitar alguns aspectos não muito
desejáveis como a repetição de informação, a incapacidade de representar parte da informação
e a perda da informação. Essas restrições são: integridade referencial, chaves primarias ou
estrangeiras e integridade de junções de relações.
Essa visão de dados organizados em tabelas oferece um conceito simples e familiar
para a estruturação dos dados, sendo um dos motivos do sucesso de sistemas
relacionais de dados. Certamente, outros motivos para esse sucesso incluem o forte
embasamento matemático por trás dos conceitos utilizados em bancos de dados
relacionais e a uniformização na linguagem de manipulação de sistemas de bancos
de dados relacionais através da linguagem SQL. (RICARTE, 2002)
Figura 4 - Exemplo de armazenamento em tabela
Fonte: Própria
De acordo com Bonfioli (2006), na terminologia formal do modelo relacional,
uma linha é chamada de tupla, o titulo da coluna é denominado de atributo e a tabela e
chamada de relação. O tipo de dado que descreve os tipos de valores que podem aparecer em
cada coluna é denominado de domínio.
26
Figura 5 - Representação dos conceitos do modelo relacional
Fonte: Bonfioli, 2006
2.8.1. Chaves Primárias e Chaves estrangeiras
Uma tabela possui uma coluna ou conjunto de colunas que contém valores
exclusivos que identificam uma tabela. Á essa coluna se denomina-se de chave primária (PK)
da tabela garantindo que dados sejam únicos e garantindo assim a integridade da tabela.
Para Bonfioli (2006), a chave primária é responsável por estabelecer as restrições
de integridade e estabelecer os relacionamentos entre as tabelas.
O termo chave primária é usado para denotar uma chave candidata que é escolhida pelo projetista de banco de dados como o principal meio de identificar tuplas dentro
de uma relação. Uma chave (seja primária, candidata ou superchave) é uma
propriedade da relação inteira, e não das tuplas individuais. Nenhum par de tuplas na
relação pode ter o mesmo valor nos atributos de chave ao mesmo tempo, a
designação de um chave representa uma restrição constante na empresa real sendo
modelada. (SILBERSCHATZ, 2006)
Sempre que se deseja referenciar uma tabela a outra dentro de um banco de dados
se utiliza da chave estrangeira onde se cria uma coluna dentro da tabela identificando a
mesma com a chave primaria da outra tabela. A chave estrangeira é o mecanismo que define
os relacionamentos em um banco de dados relacional (DATE, 2000).
Uma chave estrangeira (FK) é uma coluna ou combinação de colunas usadas para
estabelecer uma relação entre os dados de duas tabelas, onde se busca sempre manter o
controle sobre os dados que podem ser armazenados na tabela de chave estrangeira. Em uma
chave estrangeira, é criada uma relação entre duas tabelas quando a coluna ou as colunas que
possuem o valor de chave primária de uma tabela são referenciadas pela coluna ou colunas da
outra tabela. Essa coluna passa a ser uma chave estrangeira na segunda tabela.
27
2.8.2. Integridade de dados
Para Date (2000), a integridade refere-se à exatidão ou correção dos dados no
banco de dados. Aplicar a integridade de banco de dados garante a qualidade dos dados, por
exemplo, uma chave primária não pode ter valor nulo, se a uma chave primária for atribuído
um valor 123, não deverá mais ser permitido pelo banco de dados que seja criada outra chave
primária com o mesmo valor. Se estiver destinado a uma coluna receber valores inteiros de 1
a 10 o banco de dados não poderá aceitar nenhum outro valor que não seja inteiro e que não
esteja dentro deste intervalo.
Segundo a Microsoft (2013), duas etapas são muito importantes no planejamento
de tabelas uma é a identificação de valores válidos para a coluna e a outra é de como se
aplicará a integridade de dados a esta coluna. Ainda segundo a Microsoft (2013), a
integridade de dados se encaixa nas seguintes categorias.
Integridade de entidade: A restrição de integridade de entidade é
especificada em relações individuais e declara que nenhum valor da chave
primária pode ser nulo. Isso se justifica porque o valor da chave primária
sendo nula implica que não podermos identificar algumas tuplas (Elmasri
e Navathe 2005).
Integridade de domínio: A integridade de domínio é a validade de
entradas para uma coluna específica. É possível aplicar a integridade de
domínio para restringir o tipo usando tipos de dados; restringir o formato
usando restrições e regras CHECK ou restringir o intervalo de valores
possíveis usando as restrições FOREIGN KEY, restrições CHECK,
definições DEFAULT, definições NOT NULL e regras. (MICROSOFT,
2013).
Integridade referencial: Informalmente, a restrição de integridade
referencial declara que uma tupla em uma relação que se refere à outra
relação deve se referir a uma tupla existente naquela relação (Elmasri e
Navathe, 2005).
Integridade definida pelo usuário: A integridade definida pelo usuário
permite definir regras comerciais que não se encaixam em outras
categorias de integridade. Todas as categorias de integridade oferecem
suporte à integridade definida pelo usuário. Isto inclui todas as restrições
28
em nível de coluna e em nível de tabela no CREATE TABLE,
procedimentos armazenados e gatilhos. (MICROSOFT, 2013)
2.8.3. Normalização
A Normalização é o processo da construção de um banco de dados onde se aplica
regras a todas as tabelas do banco de dados, buscando evitar que aconteçam falhas no projeto,
como repetição de dados, mistura de diferentes assuntos em uma entidade, e outros vários
problemas. Para evitar estes problemas são utilizadas a formas normais onde as mais
conhecidas são a primeira, a segunda e a terceira forma normal. Segundo Gonçalves (2007),
―Uma forma normal é uma regra que deve ser aplicada na construção das tabelas do banco de
dados para que estas fiquem bem projetadas‖. Se aplicado as formas normais respeitando
todas as regras e garantido que ao final do projeto se obtenha um banco de dados integro, com
uma grande possibilidade de sucesso.
Para garantir este sucesso Melo (2011), define as principais formas normais da
seguinte forma:
1FN – 1ª Forma Normal: a tabela não deve conter grupos repetidos e nem
atributos com mais de um valor. Para deixar nesta forma normal, é preciso
identificar a chave primária da tabela, identificar a(s) coluna(s) que
possuem dados repetidos e removê-la(s), criar uma nova tabela com a
chave primária para armazenar o dado repetido e, por fim, criar uma
relação entre a tabela principal e a tabela secundária.
2FN – 2ª Forma Normal: para estar na 2FN é preciso estar na 1FN. Além
disso, todos os atributos não chaves da tabela devem depender unicamente
da chave primária (não podendo depender apenas de parte dela). Para
deixar na segunda forma normal, é preciso identificar as colunas que não
são funcionalmente dependentes da chave primária da tabela e, em
seguida, remover essa coluna da tabela principal e criar uma nova tabela
com esses dados.
3FN – 3ª Forma Normal: para estar na 3FN, é preciso estar na 2FN. Além
disso, os atributos não chave de uma tabela devem ser mutuamente
independentes e dependentes unicamente e exclusivamente da chave
primária (um atributo B é funcionalmente dependente de A se, e somente
se, para cada valor de A só existe um valor de B). Para atingir essa forma
29
normal, é preciso identificar as colunas que são funcionalmente
dependentes das outras colunas não chave e extraí-las para outra tabela.
2.8.4. SQL
SQL é uma linguagem padrão, padronizada pela ANSI (American National
Standard Institute), para banco de dados. Conhecendo a Linguagem SQL é possível
programar em qualquer SGBD (Sistema Gerenciador de Banco de Dados) relacional.
(ANGELI, 2005)
Baseada nas linguagens de Álgebra e Cálculo Relacional, e inicialmente
denominada SEQUEL (Structured English Query Language), SQL hoje é a
linguagem padrão para Sistemas Gerenciadores de Bancos de Dados Relacionais
(SGBDR), sendo mais inteligível do que suas linguagens maternas – consideradas
técnicas demais para o usuário. (ELMASRI e NAVATHE, 2011).
De acordo com Date (2004), a SQL possui, entre outros, os seguintes
componentes: Data Definition Language (DDL) ou Linguagem de Definição de Dados e Data
Manipulation Language (DML) ou Linguagem de Manipulação de Dados.
Linguagem de definição de dados (DDL) – A DDL da SQL Fornece
comandos para definir esquemas de relação, excluir relações e modificar
esquemas.
Linguagem de manipulação de dados (DML) – A DML da SQL inclui uma
linguagem de consulta baseada na álgebra relacional e no calculo relacional de
tupla. Ela também inclui comandos para inserir, excluir e modificar tuplas no
banco de dados.
Figura 6 - Definição de dados SQL
Fonte: Própria
2.8.4.1. Aplicabilidade da linguagem SQL
Para Angeli (2005), a linguagem SQL se baseia simplesmente na consulta a banco
de dados. Este tipo de linguagem se diferencia muito das demais linguagens comuns de
programação existentes no mercado hoje em dia, sua diferença mais importante é que ela não
30
é uma linguagem procedimental. Neste tipo de linguagem não é especificado como, ou em
que ordens os processos devem ser executados para poderem reportar os resultados que o
forem requeridos, na SQL apenas se informa o que é desejado e o sistema de banco de dados
que se torna responsável pela escolha adequada dos procedimentos que devem ser executados,
de uma forma que se obtenham os resultados da maneira mais eficiente e satisfatória possível.
A linguagem SQL por ser relacional se torna ideal para o tratamento de dados relacionais.
Dados relacionais são todos os dados que podem ser armazenados e organizados em uma
tabela, onde cada linha se torna uma unidade lógica de dados. A linguagem SQL pode ser
tanto de manipulação quanto de definição de dados, sendo assim podemos definir e construir
tabelas, e ao mesmo tempo manipular inúmeras relações de forma que se obtenham todos os
resultados esperados.
Ainda segundo Angeli (2005), a linguagem SQL existe e um grande número de
sistemas de banco de dados, podendo estar visível ou embutida. Estando visível o usuário
consegue entrar com comandos diretamente em um prompt de comando, onde através do
mesmo também se é possível visualizar os resultados obtidos, já de forma embutida a
linguagem não se encontra visível ao usuário, os programadores através desta forma
conseguem embutir os comandos utilizando de um programa que cria interfaces mais
amigáveis para com o usuário, facilitando o desenvolvimento por parte dos usuários. Sendo
assim usuários conseguem manipular banco de dados mesmo sem terem conhecimento da
linguagem SQL.
2.8.5. Limitações do modelo relacional
Com a quantidade de informações crescentes que vem ocorrendo nos últimos
anos, se vê hoje a necessidade do armazenamento de dados de formas mais eficientes,
seguras, estáveis, viáveis e fáceis para armazenamento destes dados, que hoje em dia não
ficam mais só em caracteres ou simples dados numéricos, mas em grandes quantidades de
dados como imagens, vídeos, filmes, áudios e dados mais complexos.
Segundo Bonfioli (2006), os bancos de dados funcionam muito bem quando se
trata do armazenamento de dados simples, que envolvem poucas associações entre relações,
mas apresentam deficiências quando se trata de aplicações mais complexas. Ainda segundo
Bonfioli (2006), podem-se destacar limitações quando não se tem tipos definidos pelo usuário
como: a dificuldade em representar objetos do mundo real; a incompatibilidade com as
linguagens de programação orientadas a objetos que hoje em dia é o paradigma mais utilizado
31
e escolhido por desenvolvedores; a divergência entre os objetos e as estruturas das entidades
do modelo relacional; suporte a grandes bancos de dados; suporta a longas transações; e
suporte ao processamento do conhecimento.
Para Elmasri e Navathe (2005), o método de orientação a objetos quando se
tratando de banco de dados foram propostos para tentar resolver estas limitações impostas
pelo modelo relacional de dados. Oferecendo maior flexibilidade para lidar com estas
exigências sem se limitar pelos tipos de dados e linguagens de consulta que se encontra
disponíveis nos sistemas de banco de dados convencionais.
2.9. Banco de dados orientado a objetos
Segundo Elmasri e Navathe (2005), Um banco de dados orientado a objeto é um
banco em que cada informação é armazenada na forma de objetos, e só pode ser manipuladas
através de métodos definidos pela classe que esteja o objeto. O conceito de banco de dados
OO e o mesmo da Linguagem Orientada a Objetos, havendo uma pequena diferença: a
persistência de dados. Existem pelo menos dois fatores que levam a adoção desse modelo, a
primeira é que banco de dados relacional se torna difícil trabalhar com dados complexos, a
segunda é que aplicações são construídas em linguagens orientadas a objetos (Java, C++, C#)
e o código precisa ser traduzido para uma linguagem que o modelo de banco de dados
relacional entenda o que torna essa tarefa muito tediosa. Essa tarefa também é conhecida
como ―perda por resistência‖.
O modelo OO ganhou espaço nas áreas espaciais, de telecomunicações, e nas áreas
científicas como física de alta energia e biologia molecular. Isso porque essa
tecnologia oferece aumento de produtividade, segurança e facilidade de manutenção.
Como objetos são modulares, mudanças podem ser feitas internamente, sem afetar
outras partes do programa. O modelo OO não teve grandes impactos nas áreas
comerciais embora tenha sido aplicado em algumas. (GALANTE, 2006)
Para Nobre (2012), os BDOO’s fazem parte de uma importante etapa na evolução
dos Sistemas gerenciadores de banco de dados, além de se caracterizar por ter recursos que
satisfazem ás exigências que são colocadas pelas aplicações de banco de dados mais
―avançadas‖, estes também podem se beneficiar do poderoso conceito da modelagem dos
BDOO’s. No futuro próximo uma grande quantidade de usuários se beneficiarão de produtos
que ofereçam um modelo OO com persistência e recursos de banco de dados, mas ainda se
encontra nesta linguagem pontos ainda não definidos principalmente quando o assunto é
padrões e modelos ajustados.
32
Mas segundo Galante (2007), em 2004 foi dado um passo importante para que
houvesse uma certa padronização, com o advento de banco de dados OO livres que
possibilitaram o crescimento deste tipo de linguagem. A Object Data Management Group
(ODMG) com a Object Query Language (OQL) padronizou uma linguagem de consulta para
objetos. Uma característica que vale a pena ser ressaltada, é que o acesso a dados pode ser
bem mais rápido, porque não é necessário junções, Já que o acesso é feito diretamente ao
objeto seguindo os ponteiros. Outra característica importante é que o BDOO oferece suporte a
versões, isto é, um objeto pode ser visto de todas e várias versões.
Para Maschietto (2012), os modelos de dados OO têm um papel essencial nos
SGBD por serem mais adequados para o tratamento de objetos complexos e dinâmicos como
textos, gráficos, imagens, vídeos, programas e simulações, por possuírem maior naturalidade
conceitual e por sempre estarem em harmonia com as tendências e linguagens de
programação e engenharia de software. A união entre as linguagens de programação e os
bancos de dados sempre foi um problema que atualmente esta sendo tratado de uma forma
mais adequada no contexto de orientação a objetos.
Segundo Galante (2007), Os bancos de dados OO e relacionais apresentam uma
série de características, e cada um tem a sua vantagem e desvantagem. Como por exemplo, os
modelos OO utilizam interfaces navegacionais ao invés das relacionais, e o acesso
navegacional é bem eficiente implementada por ponteiros. Um problema seria a
inconsistência desse modelo em trabalhar com outras ferramentas como OLAP, backup e
padrões de recuperação. E os críticos afirmam que o modelo relacional é fortemente baseado
em fundamentos matemáticos o que facilita a consulta, já os modelos OO não, o que
prejudicaria e muito as consultas. A dificuldade de implementar encapsulamento seria um
outro problema, porque como serão feitas as consultas se não é possível ver os atributos.
2.9.1. Incorporação de orientação a objetos a sistemas de banco de dados
A operação de bases de dados em ambientes distribuídos já apresentava soluções
sob a forma de sistemas de banco de dados distribuídos em meados dos anos 80, mesmo que a
solução não fosse à ideal, uma vez que os problemas de ambientes com bases de dados
heterogêneas e ambientes multidatabases ainda são objetos de estudo, era muito mais do que
oferecido por qualquer linguagem de programação. Outro aspecto melhor atendido por
sistemas de banco de dados era a questão do suporte a múltiplos usuários em acesso
concorrente às bases de dados. (RICARTE, 1998)
33
Para Ricarte (1998), a utilização de sistemas de banco de dados era propicia para
que as aplicações conseguissem alcançar a independência dos dados, assim sendo era possível
implementar aplicações sem a necessidade de se conhecer internamente a estrutura dos dados
registrados. Para a implementação de aplicações em sistemas de informação era de
fundamental importância que se observasse duas conseqüências desta propriedade, primeiro
as alterações necessárias dentro da estrutura interna de armazenamento não afetavam a
implementação da aplicação, logo em seguida se torna possível o compartilhamento de dados
entre inúmeras aplicações, permitindo assim uma manutenção simplificada, onde se era
necessária somente um único repositório de dados para a aplicação.
Ricarte (1998), afirma que apesar da distância que existe entre linguagens de
programação OO e sistemas de banco de dados, as vantagens vistas para que houvesse a
integração entre estas duas abordagens eram claramente vistas. As perspectivas criadas sobre
a possibilidade de se ter um modelo de objetos, onde o mundo real pudesse ser representado
no esquema de dados utilizando um alto nível de abstração, parecia ser para muitos a solução
dos problemas existentes entre as modelagens e o mundo real.
2.9.2. Estrutura e características
Umas das características dos sistemas OO é ocultar informação e tipos abstratos
de dados, sendo que é muito complicado aplicar esse modelo na prática. Por exemplo, nos
sistemas atuais para uma consulta em uma determinada tabela é necessário saber todos os
atributos da tabela, para formar a consulta. Em um sistema OO, que preza pelo
encapsulamento nem todo objeto pode enxergar o outro, o que dificultaria muito as consultas.
Segundo Elmasri e Navathe (2005), a idéia do encapsulamento em um BDOO, já
que não dá para ser aplicado a rigor, é pelo menos tratar o comportamento do objeto com
funções pré-definidas. Por exemplo, insert, delete, update etc. Ou seja, a estrutura interna do
objeto é escondida, e os usuários externos só conhecem a interface do tipo de objeto como os
argumentos (parâmetros), de cada operação. Então a implementação é oculta para usuários
externos que está incluído a definição da estrutura interna, de dados do objeto e a
implementação das operações que acessam essas estruturas. Enfim o BDOO propõe o
seguinte, dividir estrutura do objeto em partes visíveis e ocultas então para operações que
exigem atualização da base de dados torna se oculta e para operações que exige consultas,
torna-se visível.
34
Em grande parte, os bancos de dados OO tem suas restrições com relação às
extensões, isto é, as extensões possuem o mesmo tipo ou classe. Na Linguagem OO nem
sempre é assim. SMALLTALK, por exemplo, permite ter uma coleção de objetos de diferentes
tipos.
Galante (2007), cita que é comum em aplicações de banco de dados que cada tipo
ou subtipo de dado possua uma extensão associada, que mantenha a coleção de todos os
objetos persistentes daquele tipo ou subtipo. Nesse caso, a restrição é de que todo objeto
numa extensão que corresponda a um subtipo também deva ser um membro de extensão que
corresponda a seu supertipo. Alguns sistemas de banco de dados OO possuem um tipo de
sistema predefinido (chamado de classe raiz (root) ou classe objeto, cuja extensão contém
todos os objetos do sistema. A classificação então segue, designando objetos para supertipos
adicionais que são significativos para a aplicação, criando uma hierarquia de tipo ou
hierarquia de classe para o sistema).
Grande parte do modelo OO separa claramente o que é objeto persistente, e objeto
transiente. Por exemplo, quando é realizada uma consulta, é carregada uma lista de objetos
numa classe transiente (temporária), o sistema pode manipular os dados nessa classe e assim
que forem feitas as manipulações necessárias elas deixam de existirem.
Uma das grandes vantagens de um SGBDOO é que ele permite salvar objetos
grandes e depois obter a recuperação facilmente desses grandes objetos como textos longos,
imagens etc. Eles são considerados não estruturados porque o SGBD não conhece a sua
estrutura. A aplicação pode utilizar várias funções para manipular esses objetos. E o mais
importante é que o SGBD não conhece essas funções, mas através de técnicas oferecidas por
ele é capaz de reconhecer esses objetos e buscá-los no banco de dados, caso o objeto seja
muito grande ele pode utilizar técnicas como buffering e caching.
Galante (2007), frisa que SGBDOO não é capaz de processar diretamente
condições de seleções e outras operações desses objetos. É necessário que esses dados sejam
passados para o BD para que ele possa saber tratar os objetos corretamente. Por exemplo,
considere objetos que são imagens bitmap bidimensional. Suponha que a aplicação precise
selecionar a partir de uma coleção de tais objetos somente aqueles que incluem certo padrão.
Nesse caso, o usuário deve fornecer o programa de reconhecimento do padrão, como um
método em objetos do tipo bitmap. O SGBDOO recupera, então, um objeto do banco de
dados e aplica nele o método para o reconhecimento do padrão para determinar se o objeto
adere ao padrão desejado.
35
Objetos complexos estruturados são os objetos que contém vários tipos de objetos
dentro deles. Por exemplo, um objeto é composto de um list, de tupla, de um set, isto é, o
SGBDOO conhece todas essas estruturas, porém o objeto se torna complexo por composto de
tipos de objetos diferentes.
2.9.3. Afinal o que é um objeto?
Nobre (2012), define objeto como sendo, ―abstrações de dados do mundo real,
com uma interface de nomes de operações e um estado local que permanece oculto‖. Ou seja,
objetos possuem um estado interno que é representado por atributos que somente podem ser
acessadas por operações que são definidas pelo criador do objeto.
Segundo Boscarioli (2006), uma das propriedades mais importantes de um objeto
é sua identidade. Sem esta identidade não é possível saber com qual objeto se comunicar
através dos métodos e mensagens, o ideal é um objeto assumir sua identidade no mesmo
instante que se é criado e utilizar desta identidade em toda sua vida útil. Embora se pareça
bastante com a chave primaria utilizada pelos bancos relacionais, o conceito de OO possui
varias diferenças, enquanto a chave primaria identifica uma única tupla, em um BDOO, pode
ter dois estados idênticos, mas terem identidades diferentes, além disso, uma chave primaria
identifica uma única tupla em uma tabela um OID identifica um único objeto dentro de toda
base.
2.9.4. Identidade de objeto (OID)
Segundo Silberschatz (1999), No modelo Orientado a Objetos, o objeto mantém a
identidade mesmo que suas propriedades (variáveis, métodos, atributos, etc.) se alterem. A
forma de identidade que o Modelo de Objeto usa é embutida, ou seja, é atribuído um
identificador automático, ao contrário do Relacional em que se precisa atribuir uma chave
primária em uma tabela como identificador único.
Segundo Vieira (2003), A cada objeto armazenado no banco de dados é associado um
identificador único (OID: Object Identifier), que é gerado pelo SGBDOO (sistema de
gerenciamento de banco de dados orientado a objetos). O valor do OID não e visível ao
usuário, mas é usado internamente pelo sistema para identificar cada objeto de forma única e
criar e gerenciar referências entre objetos.
36
A identidade de objeto (OID) permite identificar unicamente um objeto, podendo ser
números longos, caracteres, entre outros, onde a habilidade de armazenar é mais importante
do que um nome de fácil compreensão pelo usuário. O objeto armazena uma referência do
objeto que o representa. O problema é que os identificadores são específicos do sistema e
devem ser traduzidos se houver necessidade de mudar para outro sistema, pois este já possui
identificadores únicos externo ao sistema (Silberschatz, 1999).
Vieira (2003), também diz que a principal propriedade de um OID é que ele é
imutável, isto é, o valor do OID de um particular objeto não deve mudar. O SGBDOO deve
ter algum mecanismo para gerenciar OID’s e preservar a propriedade de imutabilidade. É
também desejável que cada OID seja usado somente uma vez, isto é, os OID’s dos objetos
que são removidos do banco de dados não são reaproveitados.
2.9.5. Estrutura do objeto
De acordo com Elmasri e Navathe (2005), no banco de dados OO, o estado, valor
corrente de um objeto complexo, pode ser construído a partir de outros objetos ou outros
valores, utilizando construtores de tipo. Os objetos podem ser visualizados como o trio (i, c,
v), onde ―i‖ é o OID, ―c‖ é o construtor de tipo (indicação de como o estado do objeto é
construído) e ―v‖ é o estado do objeto (ou valor corrente).
Segundo Vieira (2003), o valor do atributo de um objeto pode ser:
Atômico: integer, real, charácter, booleano, etc.
Complexo: definido através de construtores: tuple, set, list, bag e array.
Ainda Segundo Vieira (2003), o construtor de tipo tuple serve para agregar
informações, é quase sempre chamado de tipo estruturado, pois corresponde ao construtor
struct nas linguagens de programação C e C++. Os construtores de tipo set, list, array são
chamado de tipos de coleção e servem para definir atributos multivalorados, podem ser não
ordenados (set e bag) ou ordenados ( list e array). Em um set é proibida a existência de dois
elementos como mesmo valor, enquanto que na bag isso é possível.
2.9.6. Objetos complexos
De acordo com Elmasri e Navathe (2005), um dos principais motivos que levou a
criação do modelo de banco de dados orientados a objetos, foi à necessidade de se lidar com
os objetos complexos.
Para Santos (2009), objetos complexos são formados por construtores (conjuntos,
lista, tuplas, registros, coleções, arrays) aplicados a objetos simples (inteiros, booleanos,
37
strings). Na linguagem OO, qualquer construtor pode ser aplicado a qualquer objeto. Também
podemos utilizar estes tipos de dados estruturados, onde a consulta precisa ser bem complexa,
pelo fato de que não se faz acesso a tabelas e registros e sim a listas, tuplas, arrays, etc. Ainda
segundo Santos (2009), segue abaixo alguns exemplos de aplicações complexas e algumas
características destas aplicações:
Aplicações complexas: projetos de engenharia e arquitetura, experiências
cientificas, telecomunicação, sistemas de informação geográficas,
multimídia.
Características das aplicações: transações de duração mais longa, novos tipos
de dados para armazenar imagens ou grandes itens de texto, necessidade
de definir operações especificas de aplicações não-padronizadas.
2.9.7. Encapsulamento, nomeação e acessibilidade
Segundo Elmasri e Navathe (2005), o encapsulamento tem com idéia principal
definir o comportamento do objeto baseando-se nas operações que podem ser aplicadas no
objeto. Toda a estrutura interna do objeto fica oculta somente podendo ser acessível através de
uma serie de operações predefinidas (métodos). Normalmente o método que é por onde
conseguimos fazer qualquer tipo de modificação no objeto é invocado enviando-se mensagem
para objeto, para que seja executado o método correspondente ao que foi solicitado.
Segundo Bonfioli (2006), o mecanismo de nomeação envolve dar a um
determinado objeto um nome persistente único, aonde ele possa no futuro ser recuperado por
aquele o outro programa. Estes nomes dados aos objetos devem ser exclusivos dentro do
banco. Nomeando assim objetos persistentes para serem utilizados como o ponto de entrada
para o banco de dados, através dos quais usuários e aplicações sejam capazes de encontrá-los
e acessá-los no banco de dados.
Ainda Segundo Bonfiolli (2006), o mecanismo de acessibilidade trabalha para
tornar objetos acessíveis a partir de algum objeto persistente. Um objeto ―B‖ se torna
acessível a partir de um objeto ―A‖ se uma seqüência de referencias no gráfico do objeto
conduzirem do objeto ―A‖ ao objeto ―B‖.
.
2.9.8. Persistência de dados
De acordo com Ishiki (2004), o conceito de persistência trata da habilidade de um
programador em manter seus dados vivos durante todo um processo, com a finalidade de mais
38
tarde reutilizar estes dados em outro processo. Sendo assim considera-se persistente o objeto
quando ele continua existindo após o final da transação que o originou. Diferente dos bancos
de dados relacionais os dados de objetos persistentes não alteram suas configurações apesar
de poderem ser remanejados entre as aplicações e os bancos de dados nos quais eles residem
permanentemente.
Para Nobre (2012), dados persistentes normalmente consistem nos banco de dados
compartilhados, que são acessados e atualizados através de transações.
2.9.9. Banco de dados OO no mercado
Existem vários bancos de dados orientados a objeto, discutir cada um deles é
essencial para a tomada de decisão. É importante saber qual modelo é mais apropriado para o
uso da sua aplicação. A seguir estão alguns exemplos citados por Galante (2007):
.
Jasmine: Possui alta conectividade com Web, suporte à linguagem Java. Pode-
se ainda desenvolver aplicações em Visual Basic usando Active/X, em HTML
(HyperText Markup Language) usando as ferramentas de conectividade para
Web disponíveis no Jasmine, em C e C++ usando APIs e em Java usando
interfaces de middleware embutidas no Jasmine. É um banco de dados
comercial.
Matisse: Trabalha com as seguintes linguagens: Java, C#, C++, VB, Delphi,
Perl, PHP, Eiffel, SmallTalk. É um banco de dados comercial.
Objectivity/DB: trabalha com as seguintes linguagens: C#; C++; Java; Python,
Smalltalk; SQL++ (SQL com objeto - extensões orientadas) e XML (para a
importação e a exportação somente). É um banco de dados comercial.
Órion: Existem vários tipos de SGBDOO, vários deles de suma importância
para determinadas funções. Dentre eles existe o Órion que é muito utilizado em
perícias. O Órion conta com 1103 veículos de carga e 4121 veículos de passeio
e comerciais leves cadastrados em seu banco de dados, alem de ser o mais
barato do mercado. Presente em mais de 640 oficinas, o Órion possibilitou a
realização de mais de130 mil perícias, no ano de 2006, e mais de 58 mil, até
maio deste ano, pelo processo de imagem.
Db4O: Existe também o DB4O, um poderoso SGBDOO para manipulação de
objetos como base de dados, fácil maneira de se armazenar objetos nativamente
39
em JAVA ou .NET possui um desempenho ate 44X maior que banco de dados
relacional, processa aproximadamente 200.000 objetos por segundo, seu
código é aberto e seu custo é muito baixo (praticamente zero).
Caché: trabalha com as seguintes linguagens: Java, Net, C++, XML e outras. É
um banco de dados comercial.
Segundo Maschietto (2012), o Caché é um SGBDOO com toda a
tecnologia em banco de dados orientados a objetos. O cachê é um banco de
dados pós-relacional orientado a objetos, que vem conquistando espaço no
mercado devido ao seu desempenho com as aplicações. Além de seu
desempenho ele permite a integração entre a linguagem padrão de banco de
dados, que é a SQL (Structured Query Language – Linguagem de Consultas
Estruturadas), e objetos, assim trabalhando com SQL e OQL (Object Query
Language – Linguagem de Consultas a Objetos). Devido a essa gama de
possibilidades do Caché, as aplicações relacionais podem fazer uso dos
componentes de negócios construídos em OO (Orientado a Objeto).
Zodb: O Banco de Dados de Objetos do Zope (ZODB) fornece um banco de
dados orientado a objeto para Python que provê um alto grau de transparência.
Aplicações podem tirar vantagem dos recursos do banco de dados objeto com
pouca, ou nenhuma, alteração na lógica da aplicação. Com a exceção de
objetos "root" (raiz), não é necessário consultar ou atualizar objetos dentro de
interações do banco de dados. Objetos são obtidos e atualizados através de
interações normais de objetos. Uma interface de armazenamento conectável
fornece uma gama incrível de flexibilidade para gerenciar dados. Transações
podem ser desfeitas de uma maneira que mantém a integridade da transação.
Um cache de objetos fornece alto desempenho, uso eficiente de memória, e
proteção contra buracos na memória impostos por referências circulares. O
ZODB é um software livre, mantido sob a licença ZPL.
GemStone: : trabalha com as seguintes linguagens: Java, C++, C#, XML e
outras. Sua linguagem de Consulta é o DML. É um banco de dados comercial.
2.9.10. ODMG (Object Database Management Group)
Segundo Bonfiolli (2006), o padrão para os bancos de dados orientados a objetos
foi feito pelo grupo de gerenciamento dados objetos (ODMG – Object Data Management
40
Group). Grupo este formado por representações da maioria dos fabricantes no mercado. O
termo modelo orientado a objetos é usado para o documento padrão onde consta a descrição
geral de facilidades de um conjunto de linguagens de POO e a biblioteca de classe que pode
formar a base para o sistema de banco de dados.
Elmasri e Navathe (2005), afirma que com a criação dos SGBDOOs de vários
fabricantes diferentes, surgiu a necessidade de estabelecer um padrão para a tecnologia.
Assim os sistemas seriam mais portáteis, pois aplicações que fossem desenvolvidas nesta base
poderiam facilmente se adaptar a outras bases. Para tanto que se criou o padrão ODMG.
Segundo Ishiki (2004), o ODMG foi criado com o objetivo de integrar e
padronizar as funcionalidades de banco de dados em uma linguagem de POO. Abaixo os
componentes do padrão:
Linguagem de definição de dados (ODL);
Linguagem de consulta (OQL);
Modelo de Objetos;
Acoplamento com linguagens de programação orientada a objetos.
2.9.10.1 Object Definition Language (ODL) – Linguagem de definição de dados
Segundo Galante (2007), a ODL surgiu para ajudar aos construtores semânticos
do modelo de objetos ODMG e é independente de qualquer linguagem de programação em
particular. O ODL tem como objetivo criar especificações de objetos sendo classes e
interfaces. Esta linguagem de programação não é considerada completa, mas permite que o
usuário especifique um bando de dados independente da linguagem de programação.
2.9.10.2 Object Query Language (OQL) – Linguagem de consulta de objetos
Segundo Ishiki (2004), OQL Consiste em uma extensão da linguagem SQL. Ela
possui suporte ao tratamento de objetos complexos, OID, invocações de métodos,
polimorfismo e herança. Pode também ser utilizada em programas escritos em outras
linguagens como Java e C++ utilizando de mecanismos de ligação.
41
OQL é a linguagem de consulta declarativa definida pela ODMG (1995). Prevê
suporte ao tratamento de objetos complexos, invocação de métodos, herança e
polimorfismo. É projetada para trabalhar acoplada com as linguagens de programação com as quais o modelo ODMG define um biding, como C++,
SMALLTALK e JAVA. Isso faz com que qualquer consulta OQL embutida em uma
dessas linguagens de programação pode retornar objetos compatíveis com os
sistemas de tipos dessa linguagem. Fornece suporte para lidar com set, structure, list
e array, tratando estas construções com a mesma eficiência. Permite expressões
aninhadas. Pode chamar métodos dos tipos envolvidos na consulta. Não fornece
operadores para atualização, mas pode chamar operações definidas nos objetos para
realizar esta tarefa, não violando assim a semântica do modelo de objetos, o qual,
por definição, é gerenciado pelos métodos especificados no objeto. É possível
definir um nome para uma determinada consulta, que é armazenada no BD. Para uso
posterior, a consulta é referenciada através do nome definido. Apresenta
construtores de objetos, structure, set, list, bag e array. Uma consulta em OQL parte dos pontos de entrada do banco de dados e constrói como resposta, um objeto que é
tipicamente uma coleção. Suporta as cláusulas SELECT, FROM, WHERE, GROUP
BY, HAVING e ORDER BY. (GALANTE, 2007)
Ishiki (2004), ainda diz que a consulta OQL parte dos pontos de entrada do banco
e constrói como resposta, um objeto que é tipicamente uma coleção. Para um grande numero
de consultas, o ponto de entrada é o nome de Extent de uma classe, pois ele é considerado o
nome de objeto persistente do tipo coleção.
2.9.10.3 Modelo de objetos
Segundo Elmasri e Navathe, 2005, o modelo de objetos fornece os tipos de dados,
os construtores de tipos e outros conceitos que podem ser utilizados na ODL para especificar
esquemas de banco de dados. O modelo de objetos define objetos e literais no qual os objetos
possuem um OID e um estado, ou valor atual, já as literais (dados primitivos) possuem apenas
um valor sendo basicamente uma constante. Tanto os objetos como as literais podem ser do
tipo atômico, coleção ou estruturado.
2.9.10.4 Acoplamento com linguagens de programação orientadas a objetos.
Segundo Vasconcelos (2009), o binding, ou acoplamento, especifica como as
estruturas em ODL são mapeadas para estruturas na LPOO escolhida. É o binding que
converte o objeto do BD para a aplicação.
2.10. Vantagens e desvantagens dos modelos relacionais e orientado a objetos
2.10.1. Vantagens do Modelo Relacional
As principais vantagens do Modelo Relacional são:
42
Bastante usado e com um grande legado (Date, 2000);
Grande número de ferramentas e características que implementam o SQL,
como padrões de conectividade, ferramentas de relatório, ferramentas de
OLAP e de backup, padrões de recuperação e ferramentas gráficas (Machado,
2009);
Quando o sistema de Modelo Relacional é instalado, já vem pronto para uso
(Date, 2000);
O Banco de Dados pode ser manipulado e alterado independentemente da
aplicação (Date, 2000);
Utiliza na normalização para ser mais compreensível e aplicável.
2.10.2. Desvantagens do Modelo Relacional
As principais desvantagens do Modelo Relacional são:
Necessidade de seleção de chaves entre tabelas;
Necessidade de mapeamento para conversão entre a linguagem de
programação orientada a objetos e o formato relacional para transformar
objetos em estruturas de tabelas, o que o torna mais lento em tempo de
compilação e execução e ainda exige parte substancial de código (Silberschatz
et al., 1999);
Codificação de conversão entre Objetos e Tuplas opera fora do paradigma de
programação orientada a objetos e há um risco maior de erros não detectados
(Silberschatz et al., 1999);
Dificuldade de modelar novas aplicações e objetos complexos, como por
exemplo, dados multimídia (Silberschatz et al., 1999).
2.10.3. Vantagens do Modelo de Objetos
As principais vantagens do Modelo de Objetos são:
Utilização dos princípios das linguagens de programação orientada a objetos
(Silberschatz et al., 1999);
Maior consistência em manipulações de dados;
Armazenamento direto de tipos de dados complexos (Silberschatz et al., 1999);
43
Habilidade de alterar a definição de um objeto sem modificar o resto do
sistema (Silberschatz et al., 1999);
Não possuem Chaves Primarias nem Estrangeiras, aumentando o desempenho
das consultas e processo (Santos, 2009);
Utilização de identificador de objeto (OID) único e imutável, criado pelo
sistema automaticamente e que são implementados em baixo nível
(Silberschatz et al., 1999);
Permite manipular o Banco de Dados diretamente com a linguagem de
programação sem intermediação de outra linguagem, o que possibilita ter
objetos muito complexos sem necessidade de transformar os dados
(Silberschatz et al., 1999);
Objetos se comunicam entre si através de mensagens (Santos. 2009).
2.10.4. Desvantagens do Modelo de Objetos
As principais desvantagens do Modelo de Objetos são:
Pouco usado (Date, 2000);
Ferramentas gráficas para desenvolvimento possuem poucos recursos.
Ausência das ferramentas e características disponíveis em SQL (Machado,
2009);
Quando o sistema é instalado não fica disponível para uso imediato, ele é
adaptado para construções de classes e métodos (Date, 2000);
Instabilidade no direcionamento de aplicações, já que tudo se resume a objetos
(Machado, 2009);
Linguagens para consultas não padronizadas (Date, 2000);
Gasta-se mais tempo para implementação do código para manusear objetos
persistentes e apresenta dificuldades de especificar restrições (Date, 2000);
Mais chance de cometer erros no Banco de Dados, já que as linguagens de
programação são mais poderosas (Silberschatz et al., 1999);
Identificadores são específicos do sistema e devem ser traduzidos se houver
necessidade de mudar para outro sistema (Silberschatz et al., 1999).
44
2.11. Linguagem Programação Orientada A Objetos
Segundo David (2007) O termo Programação Orientada a Objetos foi criado por
Alan Kay, autor da linguagem de programação Smalltalk. Mas mesmo antes da criação do
Smalltalk, algumas das idéias da POO já eram aplicadas, sendo que a primeira linguagem a
realmente utilizar estas idéias foi a linguagem Simula 67, criada por Ole Johan Dahl e Kristen
Nygaard em 1967. Este paradigma de programação já é bastante antigo, mas só agora vem
sendo aceito realmente nas grandes empresas de desenvolvimento de Software. Alguns
exemplos de linguagens modernas utilizadas por grandes empresas em todo o mundo que
adotaram essas idéias: Java, C#, C++, Object Pascal (Delphi), Ruby, Python, Lisp.
Farinelli (2007) cita que a orientação a objetos é uma tecnologia que vê os
sistemas como uma grande coleção de dados que se integram permitindo uma melhora na
reusabilidade e extensibilidade dos softwares. Esta tecnologia segunda Farinelli (2007) é
fundamentada no modelo de objetos que engloba os princípios da abstração hierarquização,
encapsulamento, classificação, modularização, relacionamento, simultaneidade e persistência.
A POO foi criada para tentar aproximar o mundo real do mundo virtual: a idéia
fundamental é tentar simular o mundo real dentro do computador. Para isso, nada mais natural
do que utilizar Objetos, afinal, nosso mundo é composto de objetos. (DAVID, 2007)
Para Davi (2007) o programador é responsável por moldar o mundo dos objetos, e
explicar para estes objetos como eles devem interagir entre si. Os objetos "conversam" uns
com os outros através do envio de mensagens, e o papel principal do programador é
especificar quais serão as mensagens que cada objeto pode receber, e também qual a ação que
aquele objeto deve realizar ao receber aquela mensagem em específico.
Uma mensagem é um pequeno texto que os objetos conseguem entender e, por questões técnicas, não pode conter espaços. Junto com algumas dessas mensagens
ainda é possível passar algumas informações para o objeto (parâmetros), dessa
forma, dois objetos conseguem trocar informações entre si facilmente. (DAVID,
2007)
Alvarez (2004) afirma que a programação Orientada a objetos (POO) é uma forma
especial de programar, é a que mais fica próximo de como expressaríamos as coisas na vida
real do que outros tipos de programação.
2.11.1. Conceitos da Orientação a Objetos
O mundo é muito complexo. Esta complexidade é percebida todos os dias sempre
que paramos para analisar os detalhes que estão em tal mundo, mesmo que nos concentre em
45
um único objeto. Essa mesma característica é transferida para o mundo computacional,
quando se cria uma solução computadorizada para que resolva um problema do mundo real.
A orientação a objeto procura ter certo domínio sobre esta complexidade através
de uma serie de conceitos. Dentre estes conceitos Farinelli (2007) cinta como princípios
básicos a abstração, encapsulamento, herança e polimorfismo.
2.11.1.1. Abstração
Para Ricarte (2001) a Abstração consiste de focalizar nos aspectos essenciais a
uma entidade e ignorar propriedades que não sejam tão importantes. Em termos de
desenvolvimento de sistemas, isto significa concentrar-se no que um objeto é e faz antes de se
decidir como ele será implementado. O uso de abstração preserva a liberdade para tomar
decisões de desenvolvimento ou de implementação apenas quando há um melhor
entendimento do problema a ser resolvido.
Para Farinelli (2007) o termo abstração, aplicado ao desenvolvimento de sistemas,
significa a grosso modo que só deve ser representado pelo objeto aquilo que vai ser usado.
2.11.1.2. Encapsulamento
Ricarte (2001) define encapsulamento como sendo a separação dos aspectos
externos de um objeto, os quais são acessíveis a outros objetos, dos detalhes internos de
implementação do objeto, os quais permanecem escondidos dos outros objetos. O uso de
encapsulação evita que um programa torne-se tão interdependente que uma pequena mudança
tenha grandes efeitos colaterais.
Conforme Farinelli (2007), o encapsulamento é o principio pelo qual cada
componente de um programa deve agregar toda a informação que seja relevante para a sua
manipulação como se fosse uma unidade (uma cápsula). Neste principio todos os dados ficam
juntos e encapsulados em uma única unidade tendo como única maneira de conhecer ou
alterar os atributos através de seus métodos.
2.11.1.3. Herança
De acordo com Ricarte (2001), as técnicas de programação utilizadas na
orientação a objetos promovem compartilhamento em diversos níveis distintos. Herança de
estrutura de dados e comportamento permite que estruturas comuns sejam compartilhadas
entre diversas classes derivadas similares sem redundância. O compartilhamento de código
46
usando herança é uma das grandes vantagens da orientação a objetos. Ainda mais importante
que a economia de código é a clareza conceitual de reconhecer que operações diferentes são
na verdade a mesma coisa, o que reduz o número de casos distintos que devem ser entendidos
e analisados
2.11.1.4 Polimorfismo
O polimorfismo para Ricarte (2001), é o princípio pelo qual duas ou mais classes
derivadas de uma mesma superclasse podem invocar métodos que têm a mesma identificação
(assinatura) mas comportamentos distintos, especializados para cada classe derivada, usando
para tanto uma referência a um objeto do tipo da superclasse. A decisão sobre qual o método
que deve ser selecionado, de acordo com o tipo da classe derivada, é tomada em tempo de
execução, através do mecanismo de ligação tardia.
Segundo Leandro (2006), o polimorfismo é a capacidade de métodos com mesmo
nome tem de realizar rotinas diferentes devido à sua assinatura.
2.11.2. Benefícios da POO
A técnica da orientação a objetos apresenta uma série de vantagens, cada vez mais
necessárias para o atual desenvolvimento de sistemas computacionais. Entre estas vantagens
Leandro (2006), apresenta alguns dos benefícios da POO.
2.11.2.1. Produtividade
Conforme se estende o tempo de vida do projeto é cada vez mais notável como a
produtividade aumenta. Dentre as principais características da POO para aumentar a
produtividade podemos citar:
Reutilização de código
Com certeza a principal vantagem da POO é poder beneficiar-se da
reutilização de código, uma vez escrito nunca será reescrito, no máximo
modificado com o polimorfismo.
Agregação de módulos prontos
Módulos podem ser agregados ao longo do projeto, mesmo tendo
seu desenvolvimento separado do mesmo, simplesmente importamos suas
funcionalidades e os utilizamos como se fossem implementados no mesmo.
47
Servir de base à modelagem da base de dados
É considerada outra vantagem da programação orientada à objetos,
tido que as modelagens são similares hoje em dia muitos projetos
simplesmente persistem os objetos na base de dados.
Menor custo de desenvolvimento
Como pudemos notar com essas técnicas podemos desenvolver
cada vez mais por cada vez menos. Ao longo do tempo, muitos módulos já
prontos serão agregados à novos projetos e muito código já escrito será
reutilizado, aumentando assim a produtividade com o custo de
desenvolvimento cada vez menor.
2.11.2.2. Ciclo de vida maior
A POO oferece também técnicas para aumentar o ciclo de vida do projeto, dentre
elas, Leandro (2006), cita:
Expansividade
Com o poder de agregar módulos prontos ao projeto, torna-se
notável o quesito de expansividade do mesmo, tornando assim maior seu ciclo
de vida.
Manutenção
Aqui está uma das maiores, se não a maior vantagem da POO,
todos sabemos que os maiores custos de um projeto estão diretamente ligados
com os custos de manutenção, mas na POO isso pode mudar drasticamente
levando-se em conta que todas as técnicas da mesma se preocupam com esse
critério.
2.12. Considerações finais
Este capítulo apresentou as principais características dos modelos de banco de
dados relacional e orientado a objetos, descrevendo suas vantagens e desvantagens que são
relevantes para o estudo.
48
3. CAPÍTULO II – SGBD UTILIZADOS NA AVALIAÇÃO
3.1. Introdução
Serão abordadas neste capítulo as principais características dos SGBD propostos
para o estudo, que são: db4objects (db4o), SQL Server 2012 e PostgreSQL.
Estes SGBD foram escolhidos pelo fato do SQL Server 2012 ser um SGBD
relacional de licença paga e também por ser um dos mais populares e utilizados no mundo e o
PostgreSQL um SGBD relacional que entre os de licença grátis é o mais popular e vem
crescendo muito nos últimos anos, e o db4objects um SGBD orientado a objetos grátis muito
conhecido por desenvolvedores do mundo todo.
O intuito é realizar uma comparação do db4o com o os dois tipos de banco de
dados relacional, para testar em qual caso ele se sai melhor, contra o SQL Server 2012
conhecido mundialmente ou contra o PostgreSQL que vem crescendo no cenário mundial
como uma ótima escolha de SGBD de código aberto.
3.2. Banco de dados orientado a objetos - db4objects (db4o)
O db4o é um banco de dados orientados a objetos de pequeno tamanho. Ele é
gratuito e projetado para aplicações do tipo embarcadas, cliente-servidor e desktop.
Segundo Machado (2009), o db4o possui modo nativo para Java e .Net. O db4o
utiliza de uma única biblioteca de desenvolvimento que é facilmente integrada pelas
aplicações que a utiliza e executa de forma confiável tarefas utilizando de poucas linhas de
código, não importando o quanto são complexas as estruturas.
Para Lima (2009), o db4o possui a mesma confiabilidade encontrada em banco de
dados relacionais, quando ocorre qualquer tipo de falha durante um processo, todos os objetos
são restaurados para o primeiro estado que se encontravam consistentes antes de ter iniciado o
processo.
49
Segundo Machado (2009), empresas como a Boing, Bocsh, Hertz, BMW, Intel
Seagate já utilizam o db4o. Estas empresas optaram pela utilização do db4o pela rapidez de
inserção, utiliza pouco recurso computacional, tem fácil aprendizado e outras varias vantagens
em relação ao modelo relacional. Quando um objeto criado em uma linguagem de
programação OO, é armazenado em um banco de dados relacional que utiliza de tabelas, é
necessário que este objeto seja desmontado para ser armazenados na estrutura da tabela, e no
db4o o objeto e diretamente armazenado como objeto.
Figura 7 - Armazenamento de objetos em B.D relacional e no db4o
Fonte: Machado, 2009
Recursos de consultas são fundamentais para qualquer banco de dados e o db4o
oferece alguns métodos de recuperação de dados. Machado (2009), cita alguns:
QBE (Query by Example): No método QBE, você cria um modelo de objeto,
que é uma instância da classe que você deseja pesquisar. Se atribuir valores
para um ou mais atributos no seu modelo, então db4o procura por objetos no
Banco de Dados com os atributos correspondentes. É um método simples e de
fácil aprendizagem, mas só é ideal para consultas que não precisam de
operadores lógicos.
SODA (Simple Object Data Access): Constrói um grafo de consulta
navegando referências em classes e as restrições que impõe. Utiliza strings para
identificar os campos. Rápido, mas o conceito pode ser difícil de acostumar.
NQ (Native Query): É uma consulta nativa expressa inteiramente na
linguagem de programação e com checagem de tipos durante a compilação.
Oferece consultas com várias vantagens importantes.
3.2.1. Definição e manipulação de dados
O db4o é simplesmente um JAR ou uma DLL, isso depende do ambiente
escolhido, e é somente deste JAR que será preciso para utilizar o framework.
50
O banco de dados no db4o é criado através de classes em Java, a única
procedimento que se deve fazer é declaração da biblioteca JAR na IDE. E as classes do
arquivo de programa deve referenciar o pacote de classes do db4o ( import com.db4o.*;).
Para realizar o acesso ao arquivo do banco de dados, é invocado o método
Db4o.openFile() passando como parâmetro o caminho onde se encontra o arquivo. Esse
procedimento nos retornara uma instancia de ObjetcContainer, que representa o banco de
dados e será o principal meio de acesso ele. Caso o arquivo não exista, ele será criado. O
método close () fecha o arquivo e libera qualquer recurso que estiver preso a ele.
Exemplo de inserção, alteração, consulta e remoção utilizando db4o e o método
de consulta QBE.
Primeiro deverá ser criada uma classe que propriamente dita seria o banco de
dados.
public class Usuario {
private String login;
private String senha;
private String nome;
private String email;
public Usuario(String login, String senha, String nome, String email) {
this.login = login;
this.senha = senha;
this.nome = nome;
this.email = email;
}
// get's e set's omitidos
}
Em outra classe será implementado os códigos. Para criar um objeto:
Abrindo o arquivo db4o
ObjectContainer db = Db4o.openFile("nome da Package.dbo");
51
Criando um objeto usuário
Usuario usu = new Usuario("teste", "123", " de Teste", "teste@teste");
Armazenando o usuário acima
db.store(usu);
Fechando o arquivo db4o
db.close();
Classe para consulta. Para recuperar um objeto no db4 é necessário criar um
protótipo do objeto para usar como exemplo do que deve ser recuperado. Pois a
instancia de ObjectContainer recuperará os objetos que se pareça com protótipo
que é informado.
Abrindo o arquivo db4o
ObjectContainer db = Db4o.openFile("nome da Package.dbo");
Criando o prototipo de exemplo
Usuario usu = new Usuario (―teste‖, null, null, null);
Invocando a consulta
ObjectSet<Usuario> result = db.queryByExample(usu);
O objeto recuperado estará em result. Neste exemplo foram recuperados todos os
objetos onde o login era ―teste‖.
Fechando o arquivo db4o
db.close();
Classe para atualização. Para atualizar um objeto também e necessário utilizar
um protótipo. Pois a instancia de ObjectContainer recuperará os objetos que se
pareça com protótipo que é informado e os atualizará com os novos atributos.
Abrindo o arquivo db4o
ObjectContainer db = Db4o.openFile("nome da Package.dbo");
52
Criando o protótipo de exemplo
Usuario usu = new Usuario (―teste‖, null, null, null, );
Recuperando usuario
ObjectSet<Usuario> usuarios = db.queryByExample(usu);
Usuario usua = usuarios.next();
Atualizando dados de login
usua.setlogin(―exemplo‖);
Armazena o usuário atualizado
db.store(usu);
Fechando o arquivo db4o
db.close();
Classe Para deletar os dados. É preciso invocar uma consulta que recuperara
todos os usuários armazenados e em seguida utilizar o método para deletados.
Abrindo o arquivo db4o
ObjectContainer db = Db4o.openFile("nome da Package.dbo");
Recuperando usuario
ObjectSet<Usuario> usuarios = db.queryByExample(Usuario.class);
Deletando todos os usuarios
for(Usuario usu : usuarios) {
db.delete(usu);
Fechando o arquivo db4o
db.close();
53
3.3. Banco de dados relacional - SQL Server 2012
Segundo Silberschatz (2006), a Microsoft, SQL Server é um sistema de
gerenciamento de banco de dados relacional que é usado de laptops a servidores de grandes
empresas. O SQL Server foi desenvolvido na década de 1980 na Sybase para os sistemas
UNIX e depois para sistemas Windows NT pela Microsoft. Desde 1994, a Microsoft vem
lançando versões desenvolvidas independentemente da Sybase, que parou de usar o nome
SQL Server no final da década de 1990. O Analysis Services, uma parte integrante do
sistema, agrega recurso analítico on-line (OLAP) e mineração de dados. Ele também fornece
uma grande coleção de ferramentas gráficas e assistentes que ajudam a orientar os
administradores de banco de dados em várias tarefas.
3.3.1. Ferramentas de gerenciamento projeto e consulta
Segundo Silberschatz (2006), o SQL Server fornece um pacote de ferramentas
para gerenciar todos os aspectos do desenvolvimento, consulta, configuração, testes e
administração. Grande parte dessas ferramentas são baseadas no SQL Server Management
Studio. O mesmo administra todos os serviços associados ao SQL Server, que inclui o
Database Engine, o Analysis Services, o Reporting Services, O SQL Server Mobile e o
Integration Services.
3.3.1.1. SQL Server Management Studio
De acordo com Silberschatz (2006), o SQL Server Management Studio não só
fornece o acesso ao projeto e as ferramentas de banco de dados alem de ser fácil de usar, mas
também aceita o gerenciamento centralizado de todos os aspectos das instalações múltiplas do
SQL Server Database Engine, do Analsysis Services o Reporting Services, O SQL Server
Mobile e o Integration Services, incluindo segurança, eventos, alertas, agendamento, backup,
configuração de servidor, ajuste, pesquisa de texto e duplicação. Ele também permite que o
administrador crie, modifique, delete e copie esquemas de banco de dados dos SQL Server e
objetos com tabelas, views e acionadores. O SQL Server Management Studio tira a
necessidade do administrador de conhecer todas as etapas e sintaxes específicas para que se
possa concluir uma tarefa. Ele oferece vários assistentes responsáveis por guiar o usuário
pelos processos de configurar e gerenciar uma instalação do SQL Server.
54
Figura 8 - Interface do SQL Server Management Studio
Fonte: Própria
3.4.Banco de dados relacional - PostgreSQL
Segundo Bonfioli (2006), o modelo relacional substitui muito bem os modelos
anteriores de dados pela sua simplicidade, mas esta simplicidade acabou tornando a
implementação de certas aplicações mais complexas muito difícil. O PostgreSQL oferece
recursos adicionais por incorporar vários conceitos de funcionalidades. Dentre elas pode-se
destacar:
Herança (especialização e generalização)
Avançado sistema de tipos de dado
Funções
Restrições
Gatilhos
Integridade da transação
Segundo Ishiki (2004), o PostgreSQL é um banco de dados de código aberto que
foi o pioneiro em muitos conceitos objetos-relacionais que agora esta se tornando disponíveis
em banco de dados comerciais. Oferece um grande poder adicional, onde os seus usuários
podem estender o seu sistema para o suporte de conceitos de orientação a objetos como
55
herança. Mas apesar destes conceitos ele está fortemente ligado aos bancos de dados
relacionais.
Para Bonfioli (2006), o PostgreSQL é considerado por muitos como sendo o
banco de dados de código aberto mais avançado atualmente, oferecendo controle de
concorrência multiversão, suportando praticamente todas as construções do SQL, incluindo
subconsultas, transações , tipos definidos pelo usuário e funções, e dispondo de um amplo
conjunto de ligações com linguagens procedurais, incluindo C, C++, Java, Perl, Tcl e Python.
Oriundo do Postgres95, o PostgreSQL tem sua ênfase na melhoria das funcionalidades e dos
recursos. As principais melhorias incluem: o bloqueio no nível de tabela foi substituído por
um sistema de concorrência multi-versão, permitindo os que estão lendo continuarem a ler
dados consistentes durante a atividade de escrita, possibilitando efetuar cópias de segurança
utilizando o pg_dump enquanto o banco de dados se mantém disponível para consultas; a
implementação de funcionalidades importantes no servidor, incluindo subconsultas, padrões,
restrições e gatilhos, triggers.
Ainda segundo Bonfioli (2006), há incorporações de funcionalidades que são
compatíveis com a linguagem SQL92, como chaves primarias e estrangeiras, identificadores
entre aspas, conversão implícita de tipo de cadeias de caracteres literais, conversão explicita
de tipos e inteiros binários e hexadecimal. Os tipos nativos foram aperfeiçoados, incluindo
vários tipos para data, hora, vetores e matrizes, e suporte adicional para tipos geométricos.
Figura 9 - Interface do PostgreSQL
Fonte: Própria
56
Figura 10 - Tabela criada no PostgreSQL
Fonte: própria
3.5. Considerações finais
Este capítulo apresentou as principais características dos SGBD que foram
propostos, para que a realização do estudo comparativo fosse possível.
57
4. CAPÍTULO III – METODOLOGIA
4.1. Introdução
Este capítulo apresenta a metodologia utilizada para a coleta de dados, o tipo da
pesquisa, a forma que os dados foram analisados e a maneira em que se desenvolveu a
pesquisa.
4.2. Metodologia utilizada
O projeto desenvolvido possui várias etapas que foram seguidas. Iniciou-se com uma
investigação e escolha do tema de pesquisa, para ver a qual área direcionar a pesquisa e
buscar apresentar uma solução ao problema proposto.
Após esta etapa foi feito o levantamento bibliográfico referente ao tema e aos métodos
de desenvolvimento propostos. O estudo proposto se caracterizou como uma pesquisa
bibliográfica em livros, artigos e internet, os dados coletados foram analisados de forma
qualitativa descrevendo e comparando os modelos de bancos de dados, e as fundamentações
teóricas analisadas de acordo com o tema proposto, pois esses dados coletados foram
necessários para que fosse feito esse levantamento de informações disponíveis.
Ás abordagens qualitativas para coleta de dados são usadas tipicamente no estado
exploratório do processo de pesquisa. Seu papel é identificar e/ou refinar problemas de pesquisa que podem ajudar a formular e testar estruturas conceituais. Tais estudos
normalmente envolvem o uso de amostras ou estudos de caso (MONEY; BABIN;
SAMOUEL, 2005).
Após a coleta dos dados iniciou-se o desenvolvimento dos bancos de dados para
posterior comparação, que é a parte principal do projeto, foram criados três bancos de dados
para que fosse possível se fazer a comparação entre o banco dados orientado a objetos e os
bancos de dados relacionais. Para o desenvolvimento dos bancos de dados relacionais foram
utilizados o SQL Server 2012 e o PostgreSQL, e para o desenvolvimento do Banco de dados
58
Orientado a Objetos foi escolhido o db4objects. Para a inserção de dados nestes bancos de
dados foi desenvolvido um software, que utilizou a linguagem de programação Java, IDE
Netbeans 7.0.1. Após a realização de todas as etapas que compões o desenvolvimento dos
bancos e do software, iniciaram-se os testes, foram inseridos 2500 registros em cada banco de
dados, sendo estes dados analisados a cada 250 registros. Esta análise foi feita calculando o
tempo gasto em segundos, em seguida estes dados foram apresentados em um gráfico para
melhor compreensão. A fim de obter as informações necessárias, para definir as
características, vantagens e desvantagens de cada banco.
Também foi utilizado um quadro comparativo com as funcionalidades e com os
requisitos encontrados. Dessa maneira foi possível diferenciar de maneira mais precisa os
banco de dados e alcançar o objetivo desse trabalho, que é comparar os bancos de dados e
identificar as suas vantagens, desvantagens, características e qual deles se adapta melhor no
para o desenvolvimento de aplicações comerciais.
4.3. Considerações finais
Este capítulo apresentou toda a metodologia utilizada para a coleta dos dados, o
tipo da pesquisa, a forma que os dados foram analisados e a maneira em que se desenvolveu a
pesquisa.
59
5. CAPÍTULO IV – SOFTWARE UTILIZADO NO TESTE
5.1. Introdução
Serão abordadas neste capítulo as principais características do software de teste,
os softwares que foram utilizados para sua construção e sua estruturação, os códigos
utilizados em cada banco testado, e os resultados de inserção.
5.2. O software
O software consiste em um programa desenvolvido em Java com interface gráfica
que possibilita uma melhor interação e a escolha quanto à quantidade de dados a ser inserida e
em qual SGBD realizar a inserção dos dados, e também visualizar o tempo gasto entre o inicio
e o fim da inserção. O mesmo utiliza de dois bancos de dados relacionais o SQL Server 2012
e o PostgreSQL e um banco de dados orientado a objetos o db4objects. A Figura 11 mostra o
software em uso.
Figura 11 - Tela do Software de teste de inserção
Fonte: Própria
60
Para a implementação do software, para o teste relacional foi necessário instalar o
SQL Server 2012 e o PostgreSQL, configurar o servidor local e a conexão, sem seguida criar
o banco de dados com suas respectivas tabelas para então dar inicio a implementação em
Java.
A diferença observada na implementação do software, para o teste orientado a
objetos, que utiliza o db4objects, é que não é preciso instalar, configurar e criar um banco de
dados para dar inicio a implementação do software. A única tarefa de que é necessário é a
adição da biblioteca do db4o no projeto criado. As instruções foram implementadas
manualmente, na codificação. Neste processo foi necessário declarar a classe que iria compor
os objetos para a modelagem do software. Para salvar um objeto foram necessárias algumas
linhas de código para armazenar diretamente a classe como objeto no banco.
5.3. Softwares utilizados no projeto
Para o desenvolvimento do software que é responsável pelos testes foi necessário
a utilização de vários softwares a IDE para desenvolvimento, o sistema operacional e os
SGBD para armazenamentos dos dados.
Os seguintes softwares foram utilizados para o desenvolvimento do projeto:
IDE NetBeans 7.0.1
Windows 7 Ultimate 32 bits – Sistema Operacional
SQL Server 2012 Express
PostgreSQL 9.0
Db4objects 8.0
5.4. SQL Server X PostgreSQL X db4o
Segue abaixo os códigos que foram utilizados para realizar a criação dos bancos
de dados O primeiro utiliza o banco de dados relacional SQL Server 2012, o segundo o banco
de dados relacional PostgreSQL e o terceiro o banco de dados orientado a objetos db4objects.
5.4.1. SQL Server 2012
Abaixo é possível visualizar os comandos SQL utilizados para a construção das
tabelas no SQL Server 2012, foi criado uma base de dados chamada ―TCC‖, dentro desta base
de dados foi criado à tabela clientes com 14 atributos, sem contar o cod_clientes que foi
61
atribuído à chave-primária que é gerada automaticamente. Abaixo na figura 12 é possível
visualizar a os comandos SQL utilizados para criar a tabela clientes no SQL Server 2012. E na
figura 13 a tabela criada após a execução dos comandos e a inserção de alguns dados.
Figura 12 - Comando SQL para criar tabela no SQL Server 2012
Fonte: Própria
Figura 13 - Tabela criada no SQL Server 2012
Fonte: Própria
5.4.2. PostgreSQL
No PostgreSQL também foi criada uma base de dados chamada ―TCC‖, dentro
desta base foi criando uma tabela possuindo os mesmos atributos que a tabela criada no SQL
Server 2012, já que o intuito e fazer a comparação igualmente entre todos os SGBD. Foi
criada utilizando comandos SQL uma tabela chamada cliente possuindo 14 atributos, sendo
atribuído ao cod_cliente a chave-primária sendo gerada automaticamente não sendo
necessário o seu preenchimento sendo assim desconsiderada como um atributo para os testes.
62
Abaixo na figura 14 é exibido os comandos SQL utilizados para a construção da tabela e na
figura 15 a tabela criada após a execução dos comandos e a inserção de alguns dados.
Figura 14 - Comando SQL para criar tabela no PostgreSQL
Fonte: Própria
Figura 15 - Tabela criada no PostgreSQL
Fonte: Própria
5.4.3.db4objects
Como o db4o não utiliza de uma instalação como normalmente se encontra nos
modelos relacionais. Não se é possível manipular este banco através de uma ferramenta de
Studio, somente é necessário a instalação de uma biblioteca JAR no IDE utilizado, que no
caso deste projeto é o IDE Netbeans. Como foi citado anteriormente o db4 utiliza somente da
declaração de uma classe para o armazenamento no banco de dados, esta classe é que
63
armazena o objeto dentro do banco de dados. Abaixo temos a declaração da classe utilizada
no software.
Figura 16 - Declaração da classe para armazenar dados do db4o
Fonte: Própria
5.5. Teste
Para testar os bancos de dados foi criado o software, que ira avaliar os banco de
dados relacional SQL Server 2012 e o PostgreSQL, e o banco de dados orientado a objetos
db4o, utilizando respectivamente as tabelas e a classe mostradas anteriormente. O Software
possui pré-definidos os cadastros a serem realizados, é um cadastro simples de cliente
contendo 14 atributos (razão, fantasia, CNPJ, CPF, inscrição-estadual, RG, endereço, numero,
bairro, cidade, fone, e-mail, situação, observação), onde o usuário escolhe a quantidade de
vezes que este cadastro deve ser realizado, e a partir desta entrada o software realiza os
64
cadastros e reporta o tempo gasto em segundos para realizar o cadastro. Os testes foram
realizados com o intuito de avaliar o tempo gasto para a inserção de 2500 registros em cada
um dos bancos de dados. Os cadastros em todos os bancos foram feitos, e avaliado o tempo
gasto por cada um a cada 250 registros, dando inicio em 250 registros e terminando os testes
em 2500 registros. O objetivo foi verificar o tempo gasto para a inserção dos dados em cada
um dos bancos estudados. O teste de inserção pode ser acompanhado na tabela 1.
5.5.1. Inserção
O teste realizado para inserção mostrou que o db4o comparado entre dois bancos
de dados relacionais, sendo um pago e o outro não, mostrou o seguinte resultado:
Tabela 1 - Teste de inserção nos bancos de dados
Fonte: Própria
TESTE DE INSERÇÃO
Qtd. De dados SQL Server 2012 PostgreSQL db4objects
Tempo/Segundos Tempo/Segundos Tempo/Segundos
250 1 11 2
500 2 24 4
750 2 35 7
1000 4 45 9
1250 5 58 13
1500 5 72 18
1750 6 82 22
2000 6 93 29
2250 8 108 34
2500 10 116 42
% Tempo gasto 5,95% 69,05% 25,00%
O db4o comparado com o banco de dados relacional de mesma categoria
(gratuito) se mostrou excelente na tarefa de inserção de dados, foram cerca de 42 segundos,
25% do tempo total gasto que foi de 168 segundos para inserção de 2500 registros por parte
do db4objects e 116 segundos por parte do postgreSQL 69% do tempo total gasto,
demonstrando uma grande diferença entre eles, dando grande vantagem ao banco de dados
orientados a objetos. Já em comparação com o SQL Server 2012 que é um banco de dados
pago ele não se mostrou tão eficiente, foram cerca de 10 segundos, 5,95% do tempo total
gasto, para inserção de 2500 registros por parte SQL Server 2012 contra 42 segundos do db4o
65
25% do tempo total gasto. Abaixo é possível observar melhor no gráfico a diferença existente
entre cada um dos bancos testados durante vários momentos da inserção dos registros.
Figura 17 - Gráfico do teste de inserção nos bancos de dados.
Fonte: Própria.
5.6. Considerações finais
Este capítulo apresentou as principais características do software utilizado para
fazer os testes de inserção, os softwares que foram utilizados para a construção e estruturação
do software, os códigos utilizados para o desenvolvimento de cada banco e os resultados
obtidos com o teste de inserção.
66
6. CAPÍTULO V – COMPARATIVO
6.1. Introdução
Este capítulo apresenta um comparativo entre algumas das funcionalidades e
requisitos de cada um dos bancos de dados estudados, demonstrando algumas vantagens e
desvantagens.
6.2. Comparativo de funcionalidades
No quadro abaixo esta descrito um comparativo com algumas das funcionalidades de
cada um dos três bancos de dados estudados, o modelo relacional com o SQL Server 2012 e o
PostgreSQL e o orientado a objetos com o db4objects. Utilizando deste quadro comparativo
conseguiu-se observar melhor algumas diferenças que eles apresentam, possibilitando
observar algumas vantagens e desvantagens e algumas características.
Satisfaz a exigência
Não satisfaz a exigência
Legenda
67
Tabela 2 - Comparativo entre funcionalidades dos bancos
Fonte: Própria
Banco de Dados Microsoft
SQL Server
2012
PostgreSQL
9.0 Db4objects
Funcionalidades
Lista de Requisitos Técnicos
Processador de 1 GHz no mínimo
Processador de 1.2 GHz no mínimo
Processador de 1.8 GHz no mínimo
Mínimo de 256 MB de memória RAM
Mínimo de 512 MB de memória RAM
Mínimo de 1 GB de memória RAM
Mínimo de 1 GB de espaço Disco Rígido
Necessidade de Unidade de DVD ROM
Necessidade de Conexão TCP/IP
Sistema operacional: Windows Server 2003
Sistema operacional: Windows Server 2008
Sistema operacional: Windows XP
Sistema operacional: Windows Vista
Sistema operacional: Windows 7
Sistema operacional: Windows 8
Sistema operacional: Mac OS X
Sistema operacional: Linux
Sistema operacional: Solaris
Português
Fácil usabilidade das ferramentas
Preço entre R$ 1000 e R$8000
68
Banco de Dados Microsoft
SQL Server
2012 R2
PostgreSQL
9.0 Db4objects
Funcionalidades
Lista de Requisitos Técnicos
Gratuito
Orientado a Objetos
Relacional
Utiliza da normalização dos dados
Armazenamento em Tabelas
Armazenamento em Objetos
(encapsulamento)
Sistema de tipo de dados abstratos
Utiliza de Métodos (Manipulação)
Controle de redundância
Restrições de chave primaria
Identificação de objetos (OID)
Herança
Definição de dados pelo usuário
Suporta consulta através de interface gráfica
6.3. Descrição das funcionalidades
Segue abaixo a descrição de cada uma das funcionalidades descritas na tabela 2:
Processador: o SQL Server 2012 e o PostgreSQL trabalham com uma
capacidade de processamento de no mínimo 1 GHz menor que o db4objects
que necessita de 1.2 GHz. Isso se explica pelo fato de os modelos relacionais
normalmente trabalharem com dados convencionais e os modelos orientados a
objetos trabalharem mais com dados complexos como vídeos, imagens e etc.
Memória de armazenamento: dentre os três SGBD estudados todos
necessitam de no mínimo 512 MB.
69
Necessidade de unidade de DVD ROM: Em nenhum dos três é necessário a
utilização de DVD ROM, pois os mesmo são adquiridos pela internet, ou são
instalados na máquina não necessitando do DVD ROM para utilizar o
aplicativo.
Necessidade de conexão TCP/IP: as conexões TCP/IP são necessárias no
SQL Server 2012 e no PostgreSQL pela necessidade de comunicação entre o
SGBD e o IDE de desenvolvimento, já o db4objects não necessita desta
conexão por ser somente uma biblioteca JAR que é importada para dentro do
projeto que esta sendo desenvolvido.
Sistema Operacional: o db4o e PostgreSQL, pode ser utilizado em todos os
sistemas operacionais apresentados na tabela, o nessa avaliação o SQL Server
2012 não é compatível com o Mac OS X, Windows Server 2003. Windows XP
e com o Linux.
Idioma: Todos eles são desenvolvidos em vários idiomas como alemão,
chinês, inglês, etc. mas nenhum em português.
Fácil usabilidade de ferramentas: O SQL Server 2012 e o PostgreSQL
possuem um Studio de desenvolvimento interativo e com varias opções de
auxilio direto o usuário já o db4objetcs por se tratar simplesmente de uma
biblioteca importada para o projeto não possuem nenhuma ferramenta de
auxilio toda manipulação do banco e feita pela a IDE de desenvolvimento do
Software.
Preço: De acordo com o site www.microsafe.com.br uma licença do SQL
Server 2012 esta avaliada em dois mil e novecentos reais, o PostgreSQL e o
db4objects são de código aberto não tendo custos.
Modelo de banco de dados: O PostgreSQL e SQL Server 2012 utiliza o
modelo de dados relacional e o db4objects o orientado a objetos.
Normalização de dados: a normalização de dados são regras aplicadas na
construção de tabelas para evitar erros, são utilizadas somente em modelos
relacionais por isso somente o SQL Server 2012 e o PostgreSQL utiliza da
normalização. O db4objects por ser armazenado os dados como objetos e ser
orientado a objetos não é normalizado.
70
Tipo de armazenamento de dados: O SQL Server 2012 e PostgreSQL
armazenam seu dados em tabelas e o db4objects armazena seu dados
diretamente como objetos.
Controle de redundância: Nos modelos relacionais o controle de redundância
é feito pelas chaves – primarias, e no modelo orientado a objeto é utilizado a
identificação de objeto (OID), é atribuído um identificador automático, não
tendo a necessidade de atribuir uma chave – primaria.
Definição de dados pelo usuário: em todos os modelos os dados são definidos
pelo usuário.
Suporta consulta através de interfaces gráficas: todos os bancos suportam
consultas através de interfaces gráficas.
6.4. Considerações finais
Este capítulo apresentou um comparativo entre algumas das funcionalidades e
requisitos dos bancos de dados estudados, demonstrando algumas vantagens e desvantagens.
E descrevendo algumas de suas funcionalidades.
71
7. CAPÍTULO VI - ANÁLISES E RESULTADOS
7.1. Introdução
Este capítulo apresenta os métodos utilizados na análise do melhor banco de
dados para aplicações comerciais e os resultados obtidos com pesquisa desenvolvida nos
capítulos anteriores.
7.2. Analises e resultados
Este estudo foi desenvolvido para a realização de um comparativo entre os
modelos de bancos de dados relacionais e os bancos de dados orientados a objetos, a fim de
identificar características que apresentem as suas vantagens e desvantagens para o
desenvolvimento de aplicações comerciais.
Para identificar estas características foi desenvolvido um software para testar os
bancos de dados. Foram feitos vários testes de inserção nos dois modelos de dados. Os testes
mostraram que no comparativo de inserção de dados nos bancos relacionais e orientados
objetos, o db4objects se saiu melhor do que o PostgreSQL, ele foi superior em todos os testes,
já em comparação com o banco de dados SQL Server 2012 não obteve resultados tão
satisfatórios. Lembrando que o SQL Server 2012 não trabalha com plataformas gratuitas, isso
seria uma vantagem para o orientado a objeto db4o, pois se comparado ao banco de dados
relacional gratuito o PostgreSQL, a economia de tempo de inserção por parte do db4o é
enorme. A provável causa que explicaria por que o banco de dados relacional foi melhor por
parte do SQL Server 2012, pode ser o fato de terem sido implementados dados simples, como
strings e números. No teste não houve dados complexos, como, por exemplo, vídeos e
imagens no qual o banco de dados orientado a objetos parece ser melhor e mais adequado a
trabalhar, e sim dados comuns. Se fossem dados complexos e vários níveis de herança talvez
os dados da velocidade de inserção fossem diferentes.
72
Outro ponto observado foi o comparativo de funcionalidades onde são
demonstrados vários pontos de cada um dos bancos, que de forma resumida expressa pontos
fortes e fracos de cada um, podem ser observar por este comparativo que não é necessário um
nível muito alto de processamento e armazenamento para ser possível utilizar os SGBD
estudados, pode se observar também que em termos de sistemas operacionais o db4objects e o
PostgreSQL levam vantagens sobre o SQL Server 2012, pode-se observar também que o
db4objects não utiliza da normalização de dados e não armazena dados em tabelas, seus dados
são armazenados como objetos encapsulados somente podendo ser manipulados por meio de
mensagens e métodos. Esse fato do encapsulamento prejudica o banco de dados orientado a
objetos quando se trata de consultas, quando se é necessário uma consulta de um objeto o
programa busca o objeto envia uma mensagem para o método que recebe esta mensagem
executa a operação e retorna o resultado da consulta, este processo acaba tornando uma
simples consulta em algo demorado. Já no modelo relacional estes dados ficam armazenados
em tabelas onde a qualquer momento pode-se escolher qualquer dado em qualquer lugar da
tabela.
Os resultados alcançados no desenvolvimento da pesquisa mostram que o uso do
modelo orientado a objetos é inviável para o controle de dados convencionais onde se é
armazenado somente dados como números e strings. Se fosse trabalhados dados complexos
como vídeos e imagens talvez o orientado a objetos fosse viável.
7.3. Considerações finais
Este capítulo apresentou os métodos utilizados na análise do melhor banco de
dados para aplicações comerciais e os resultados que foram alcançados durante o
desenvolvimento da pesquisa.
73
8. CAPÍTULO VII – CONCLUSÕES E TRABALHOS FUTUROS
8.1. Introdução
Este capítulo apresenta a conclusão final desta monografia, e relaciona os
possíveis trabalhos futuros.
8.2. Conclusões
Com a quantidade de dados, e diversidade de softwares será difícil existir no
mercado uma forma definitiva de armazenar dados. Tanto o modelo de dados relacional
quanto o orientado a objetos possuem suas vantagens e desvantagens. O ponto que mais pesa
para o modelo relacional ser hoje o mais utilizado é pelo fato de que ele é mais utilizado em
aplicações comerciais e possui um grande legado, pois informações antigas das empresas
estão ligadas diretamente a este modelo há muitos anos, e uma migração para outro paradigma
seria difícil pelo fato de que todos os dados estão estruturados no modelo relacional em forma
de tabelas e o modelo orientado a objetos não utiliza de tabelas, são armazenados diretamente
na forma de objetos uma estrutura muito diferente como foi visto nas pesquisas realizadas e
nos comparativos, durante o desenvolvimento deste estudo. Já o modelo orientado a objetos
se beneficia do fato de utilizar o conceito de programação orientado a objeto, que na
linguagem de programação hoje é mais utilizada, não necessitando de um tradutor entre as
linguagens, facilitando o trabalho com os dados persistentes e complexos.
Os testes realizados nos bancos de dados, mostram que em comparação com o
PostgreSQL, um SGBD gratuito o db4objects obteve uma larga vantagens quanto as inserções
de dados, e com o SQL Server 2012 um SGBD pago seu desempenho foi um pouco inferior.
O banco de dados orientado a objetos pode ser superior a alguns SGBD relacionais quanto à
inserção de dados, mas hoje o mais importante para um banco de dados de acordo com a
74
pesquisa realizada é o seu poder de consulta, pois os usuários de sistema consultam mais
dados do que acabam inserindo, atualizando ou removendo, e pelo estudo realizado pode se
disser que o banco de dados orientado a objetos não possui um padrão de pesquisa definido,
suas consultas são prejudicas pelo fato de o objeto estar encapsulado sendo possível a
manipulação somente por mensagens e métodos, e também não possuem ferramentas que
facilitam o manuseio dos dados. Diferente do modelo relacional, que possui todos os seus
dados estruturados em tabelas completamente acessíveis a qualquer consulta, possui um
padrão de pesquisa definido e várias ferramentas que auxiliam esta consulta, sem mencionar
também que o relacional, é mais popular e possui uma maturidade maior, por estar no
mercado há mais tempo. Já o orientado a objetos apesar de estar a muito tempo no mercado
ainda não é tão conhecido e é pouco usado gerando certa desconfiança por parte de novos
usuários quanto ao seu uso, isso acaba se tornando um obstáculo para que o banco de dados
orientado a objetos evolua e ganhe um espaço maior no mercado.
Sendo assim este estudo respondeu a questão que deu origem ao projeto e a
resposta é que no caso de aplicações comerciais que utilizam dados não tão complexos o
melhor banco de dados a ser adotado é o relacional.
O estudo contribuiu para auxiliar na escolha de qual o melhor modelo de banco de
dados utilizar para a implementação de aplicações comerciais, para que se obtenha a melhor
solução para o caso em questão.
8.3. Trabalhos Futuros
Como continuação deste trabalho, considera-se importante os seguintes temas:
Analise de banco de dados Objeto-Relacional;
Manipulação de dados complexos utilizando banco de dados orientados a
objetos;
Selecionar mais banco de dados para comparação.
75
REFERÊNCIAS BIBLIOGRÁFICAS
ALVAREZ, Miguel Ângelo, O que é a programação orientada a objetos. 2004. Disponível
em < http://www.criarweb.com/artigos/215.php >. Acesso em 20 de junho de 2012 ás 22:00
min.
ANGELI, Juliano Francisco, Sql. 2005. Disponível em <
http://fit.faccat.br/~julianoangeli/linguagens/trabalhosql.html 06-05-2005>. Acesso em 15 de
junho de 2012 ás 15:00 min.
BELLO, José Luiz de Paiva, Metodologia Científica. 2004. Disponível em <
http://www.pedagogiaemfoco.pro.br/met01.htm > Acesso em 11 de junho de 2013 ás
21:23min.
BONFIOLI, Guilherme Ferreira. Banco de dados relacional e objeto-relacional uma
comparação usando PostgreSQL, Lavras, Universidade Federal de Lavras. 2006.
BOSCARIOLI, Clodis, Anderson Bezerra, Marcos de Benedicto, Gilliard Delmiro. Uma
reflexão sobre banco de dados orientados a objetos. São Paulo 2006. Faculdades
associadas de são Paulo.
CÔRTES, Sérgio da Costa, Carlos José Pereira de Lucena. Um Framework de Regras
Ativas para Sistemas de Gerência de Banco de Dados Distribuído. 2001. Disponível em:
<ftp://ftp.inf.puc-rio.br/pub/docs/techreports/01_16_cortes.pdf> Acesso em 22 de maio de
2013 ás 17:08 min.
COSTA, Elizângela Rocha. Banco de Dados Relacionais. 2011. Disponível em <
http://www.fatecsp.br/dti/tcc/tcc0025.pdf> Acesso em 14 de maio de 2013 ás 22:33 min.
DATE, C. J. Introdução a Sistemas de Banco de Dados. 7. Ed. Rio de Janeiro: Editora
Campus, 2000.
DATE, C. J. Introdução aos Sistemas de Banco de Dados. 8ª edição. Editora Campus,
2004. Silbershatz, Abraham,Henry F. Korth,S. Sudarshan. Sistemas de banco de dados.Rio de
Janeiro 5º edição, editora campus, ano 2006. Tradução de Daniel vieira.
76
DAVID, Marcio Frayze. Programação orientada a objetos: uma introdução. 2007.
Disponível em: < http://www.hardware.com.br/artigos/programacao-orientada-objetos/ >
Acesso em 27 de Maio de 2012 ás 10:30min.
ELMASRI, Ramez. Sistemas de banco de dados. Ramez Elmasri e Shamkant B. Navathe;
revisor técnico Luis Ricardo de Figueiredo. São Paulo: Addison Wesley, 2005.
ELMASRI, Ramez; NAVATHE, Shamkant B.. Sistemas De Banco De Dados. 6. Ed. São
Paulo: Addison Wesley, 2011.
ERINALDO. Banco de dados relacional. 2012. Disponível em: <
http://erinaldosn.files.wordpress.com/2012/02/aula1-banco-de-dados-relacional1.pdf >
Acesso em 22 de maio de 20013 ás 16:28 min.
FARINELLI, Fernanda, Conceitos Básicos de Programação Orientada a Objetos. 2007.
Disponível em <
http://sistemas.riopomba.ifsudestemg.edu.br/dcc/materiais/1662272077_POO.pdf >. Acesso
em 14 de maio de 20013 ás 20:38 min.
GALANTE, Alan Carvalho, Banco de dados orientados a objetos. 2007, Disponível em <
http://www.fsma.edu.br/si/edicao3/banco_de_dados_orientado_a_objetos.pdf>. Acesso em 17
de junho de 2012 ás 22:00 min.
GONÇALVES, Mauri. Modelagem De Dados – Final (Normalização). 2007. Disponível
em:<http://imasters.com.br/artigo/7020/banco-de-dados/modelagem-de-dados-final-
normalizacao/> Acesso em 22 de maio de 2013 ás 22:57 min.
ISHIKI, Ronaldo Tsuji. Estudo comparativo de banco de dados orientados a objetos.
Londrina 2004. Universidade estadual de londrina
LEANDRO, Programação orientada a objetos. 2006. Disponível em <. http://br-
java.blogspot.com.br/>. Acesso em 20 de junho de 2012 ás 22:30 min.
LIMA, Alexandre. Persistência orientada a objetos com Db4. 2009. Disponível em <
http://javabahia.blogspot.com.br/2009/03/persistencia-orientada-objetos-com-db4o.html>
Acesso em 31 de maio de 2013 ás 15:25 min.
MACHADO, David Rodrigues. Comparação entre banco de dados relacionais e banco de
dados orientado a objetos: características e implementação de um protótipo. Itatibaia
2009. Universidade São Francisco.
MASCHIETTO, Leandro Cesari. Banco de dados orientados a Objetos. 2012. Disponível
em <http://lmtelecom.blogspot.com.br/2012/04/banco-de-dados-orientados-objetos.html>.
Acesso em 24 de maio de 2013 ás 20:16 min.
MELO, Izabela Vanessa de Almeida. Normalização de Banco de Dados Relacionais. 2011,
Disponível
em:<http://www.dsc.ufcg.edu.br/~pet/jornal/maio2011/materias/recapitulando.html> Acesso
em 22 de maio de 2013 ás 21:45 min.
77
MICROSOFT. Restrições Banco de dados Lifecycle Management (DLM). 2013
Disponivel em: <http://msdn.microsoft.com/en-us/library/jj907294.aspx > Acesso em 23 de
maio de 2013 ás 20:45 min.
MONEY, Arthur H.; BABIN, Barry; SAMOUEL, Phillip. Fundamentos de métodos de
pesquisa em administração. Porto Alegre: Bookman, 2005.
NOBRE, Izenete, Banco de dados Orientado a Objetos. 2012. Disponível em <
http://www.ebah.com.br/content/ABAAAfDTsAD/banco-dados-orientado-a-objeto>. Acesso
em 24 de maio de 2013 ás 19:47 min.
RICARTE, Ivan Luiz Marques, Banco de dados relacional. 2002. Disponível em <
http://www.dca.fee.unicamp.br/cursos/PooJava/javadb/bdrel.html >. Acesso em 18 de junho
de 2012 ás 22:10 min.
RICARTE, Ivan Luiz Marques. Introdução a Orientação a objetos. 2001. Disponível em <
http://www.dca.fee.unicamp.br/cursos/POOCPP/node3.html > Acesso em 14 de maio de 2013
ás 21:27 min.
RICARTE, Ivan Luiz Marques. Sistema de banco de dados Orientados a objetos,
Campinas: Universidade estadual de Campinas, 1998
SANTOS, Jackson Matias dos Santos, Artur Luiz Torres de Oliveira, Aislan Rafael Rodrigues
de Sousa. Tecnologia de banco de dados orientado a objetos, um novo paradigma para
SGBD’s, Picos - PI, Instituto Federal de Educação, Ciência e Tecnologia do Piaui. 2009.
SILBERSCHATZ, Abraham. Sistema de banco de dados. Rio de janeiro: Elsevier, 2006.
Tradução de Daniel Vieira.
SILBERSCHATZ; Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de Banco de
Dados. 3. Ed. São Paulo: Markron Books, 1999.
VASCONCELOS, Rafael Oliveira. Comparativo entre banco de dados orientados a
objetos (BDOO) e banco de dados relacional (BDOR). 2009 Disponível em < http://rafaeloliveirav.wordpress.com/2009/06/18/artigo-comparativo-entre-banco-de-dados-
orientado-a-objetos-bdoo-e-bancos-de-dados-objeto-relacional-bdor-parte-1/ > Acesso em 25 de
maio de 2013 ás 00:21 min.
VIEIRA, Marina Teresa Pires, Banco de Dados Orientado a Objetos. 2003 Disponível em
<http://www2.dc.ufscar.br/~zorzo/latosensu2003/material/ApostilaBDOO.pdf > Acesso em
17 de maio de 2013 ás 21:32 min.
