Ulbra tcc sistema de informaçao getúlio de oliveira valentim

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



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



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 objectoriented. 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
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
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
7. CAPÍTULO VI - ANALISES E RESULTADOS .......................................................... 71
7.1. INTRODUÇÃO ......................................................................................................... 71
7.2. ANALISES E RESULTADOS .................................................................................. 71
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íﬁco 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. Podese 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
 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
 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
 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.
 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‖.
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.

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);
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.
 Recuperando usuario
ObjectSet<Usuario> usuarios = db.queryByExample(Usuario.class);
 Deletando todos os usuarios
for(Usuario usu : usuarios) {
db.delete(usu);
db.close();

Ulbra tcc sistema de informaçao getúlio de oliveira valentim

Ulbra tcc sistema de informaçao getúlio de oliveira valentim

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Ulbra tcc sistema de informaçao getúlio de oliveira valentim

Ähnlich wie Ulbra tcc sistema de informaçao getúlio de oliveira valentim (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (6)

Ulbra tcc sistema de informaçao getúlio de oliveira valentim