0

INSTITUTO LUTERANO DE ENSINO SUPERIOR DE ITUMBIARA-GOIÁS
CURSO DE SISTEMAS DE INFORMAÇÃO

GETÚLIO DE OLIVEIRA VALENTIM
...
1

GETÚLIO DE OLIVEIRA VALENTIM

ESTUDO COMPARATIVO ENTRE BANCOS DE DADOS RELACIONAIS E
ORIENTADOS A OBJETOS VISANDO APLIC...
2

Dados Internacionais de Catalogação na Publicação (CIP)
Bibliotecária Maria Lúcia Silva – CRB1 1417

V155e
Valentim, Ge...
3

ESTUDO COMPARATIVO ENTRE BANCOS DE DADOS RELACIONAIS E
ORIENTADOS A OBJETOS VISANDO APLICAÇÕES COMERCIAIS

GETÚLIO DE O...
4

Dedico este trabalho primeiramente aos meus queridos
pais que sempre me deram apoio. À toda minha família, minha
namora...
5

AGRADECIMENTOS

Aos meus pais, por tudo que fizeram por min durante está etapa da minha vida
pelo apoio, dedicação, com...
6

―Não deixe o barulho da opinião dos outros abafar sua voz interior. E
mais importante, tenha a coragem de seguir seu co...
7

RESUMO

Com a quantidade de informações crescentes que vem ocorrendo nos últimos anos, se vê hoje
a necessidade do arma...
8

ABSTRACT

With the growing amount of information that has been occurring in recent years, we see today
the need for dat...
9

LISTA DE FIGURAS

Figura 1 - Sistema de Banco de Dados ...................................................................
10

LISTA DE TABELAS
Tabela 1 - Teste de inserção nos bancos de dados .......................................................
11

SUMÁRIO

INTRODUÇÃO .....................................................................................................
12

2.10.VANTAGENS E DESVANTAGENS DOS MODELOS RELACIONAIS E
ORIENTADO A OBJETOS .............................................
13

6.2. COMPARATIVO DE FUNCIONALIDADES .......................................................... 66
6.3. DESCRIÇÃO DAS F...
14

INTRODUÇÃO

Com a quantidade de informações crescentes que vem ocorrendo nos últimos
anos, se vê hoje a necessidade do...
15

desvantagens de cada um desses dois modelos, tornando relevante o desenvolvimento do
trabalho.
O objetivo geral é faze...
16

pouco recurso computacional e ter fácil aprendizado (MACHADO, 2009). Foram escolhidos
dois modelos relacionais sendo u...
17

2. CAPÍTULO I - REFERENCIAL TEÓRICO

2.1. Introdução
Os bancos de dados e sua tecnologia têm um impacto muito importan...
18

Nos sistemas computacionais, as bases de dados são mantidas e acessadas por
meio de um software conhecido como Sistema...
19

•

Modelos lógicos, que suportam descrições de dados que podem ser processados
por um computador (ex: modelos relacion...
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 can...
21

2.5. Componentes de um SGBD
Para Côrtes (2001), um SGBD é composto por diversos componentes de
softwares, tendo cada u...
22



Gerente de Transação: executa comandos necessários pelas operações
recebidas das transações.



Scheduler (Escalon...
23

Figura 3 - Componentes do módulo gerente de banco de dados
Fonte: Côrtes, 2001

2.6. Tipos de banco de dados
Para Erin...
24



Banco de Dados Analíticos: Este tipo de banco de dados é usado
principalmente em cenários de processamento analític...
25

2.8. Modelo Relacional

Segundo Elmasri e Navathe (2011), o Modelo Relacional (MR) é um modelo de
dados representativo...
26

Figura 5 - Representação dos conceitos do modelo relacional
Fonte: Bonfioli, 2006

2.8.1. Chaves Primárias e Chaves es...
27

2.8.2. Integridade de dados
Para Date (2000), a integridade refere-se à exatidão ou correção dos dados no
banco de dad...
28

em nível de coluna e em nível de tabela no CREATE TABLE,
procedimentos armazenados e gatilhos. (MICROSOFT, 2013)

2.8....
29

normal, é preciso identificar as colunas que são funcionalmente
dependentes das outras colunas não chave e extraí-las ...
30

é uma linguagem procedimental. Neste tipo de linguagem não é especificado como, ou em
que ordens os processos devem se...
31

e escolhido por desenvolvedores; a divergência entre os objetos e as estruturas das entidades
do modelo relacional; su...
32

Mas segundo Galante (2007), em 2004 foi dado um passo importante para que
houvesse uma certa padronização, com o adven...
33

Para Ricarte (1998), a utilização de sistemas de banco de dados era propicia para
que as aplicações conseguissem alcan...
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 me...
35

Objetos complexos estruturados são os objetos que contém vários tipos de objetos
dentro deles. Por exemplo, um objeto ...
36

A identidade de objeto (OID) permite identificar unicamente um objeto, podendo ser
números longos, caracteres, entre o...
37

strings). Na linguagem OO, qualquer construtor pode ser aplicado a qualquer objeto. Também
podemos utilizar estes tipo...
38

tarde reutilizar estes dados em outro processo. Sendo assim considera-se persistente o objeto
quando ele continua exis...
39

em JAVA ou .NET possui um desempenho ate 44X maior que banco de dados
relacional, processa aproximadamente 200.000 obj...
40

Group). Grupo este formado por representações da maioria dos fabricantes no mercado. O
termo modelo orientado a objeto...
41

OQL é a linguagem de consulta declarativa definida pela ODMG (1995). Prevê
suporte ao tratamento de objetos complexos,...
42

 Bastante usado e com um grande legado (Date, 2000);
 Grande número de ferramentas e características que implementam...
43

 Habilidade de alterar a definição de um objeto sem modificar o resto do
sistema (Silberschatz et al., 1999);
 Não p...
44

2.11. Linguagem Programação Orientada A Objetos
Segundo David (2007) O termo Programação Orientada a Objetos foi criad...
45

um único objeto. Essa mesma característica é transferida para o mundo computacional,
quando se cria uma solução comput...
46

usando herança é uma das grandes vantagens da orientação a objetos. Ainda mais importante
que a economia de código é a...
47

 Servir de base à modelagem da base de dados
É considerada outra vantagem da programação orientada à objetos,
tido qu...
48

3. CAPÍTULO II – SGBD UTILIZADOS NA AVALIAÇÃO

3.1. Introdução
Serão abordadas neste capítulo as principais caracterís...
49

Segundo Machado (2009), empresas como a Boing, Bocsh, Hertz, BMW, Intel
Seagate já utilizam o db4o. Estas empresas opt...
50

O banco de dados no db4o é criado através de classes em Java, a única
procedimento que se deve fazer é declaração da b...
51

 Criando um objeto usuário
Usuario usu = new Usuario("teste", "123", " de Teste", "teste@teste");
 Armazenando o usu...
52

 Criando o protótipo de exemplo
Usuario usu = new Usuario (―teste‖, null, null, null, );
 Recuperando usuario
Object...
Ulbra tcc sistema de informaçao getúlio de oliveira valentim
Ulbra tcc sistema de informaçao getúlio de oliveira valentim
Ulbra tcc sistema de informaçao getúlio de oliveira valentim
Ulbra tcc sistema de informaçao getúlio de oliveira valentim
Ulbra tcc sistema de informaçao getúlio de oliveira valentim
Ulbra tcc sistema de informaçao getúlio de oliveira valentim
Ulbra tcc sistema de informaçao getúlio de oliveira valentim
Ulbra tcc sistema de informaçao getúlio de oliveira valentim
Ulbra tcc sistema de informaçao getúlio de oliveira valentim
Ulbra tcc sistema de informaçao getúlio de oliveira valentim
Ulbra tcc sistema de informaçao getúlio de oliveira valentim
Ulbra tcc sistema de informaçao getúlio de oliveira valentim
Ulbra tcc sistema de informaçao getúlio de oliveira valentim
Ulbra tcc sistema de informaçao getúlio de oliveira valentim
Ulbra tcc sistema de informaçao getúlio de oliveira valentim
Ulbra tcc sistema de informaçao getúlio de oliveira valentim
Ulbra tcc sistema de informaçao getúlio de oliveira valentim
Ulbra tcc sistema de informaçao getúlio de oliveira valentim
Ulbra tcc sistema de informaçao getúlio de oliveira valentim
Ulbra tcc sistema de informaçao getúlio de oliveira valentim
Ulbra tcc sistema de informaçao getúlio de oliveira valentim
Ulbra tcc sistema de informaçao getúlio de oliveira valentim
Ulbra tcc sistema de informaçao getúlio de oliveira valentim
Ulbra tcc sistema de informaçao getúlio de oliveira valentim
Ulbra tcc sistema de informaçao getúlio de oliveira valentim
Próximos SlideShares
Carregando em…5
×

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

1.352 visualizações

Publicada em

ESTUDO COMPARATIVO ENTRE BANCOS DE DADOS RELACIONAIS E ORIENTADOS A OBJETOS VISANDO APLICAÇÕES COMERCIAIS

Publicada em: Tecnologia
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

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

  1. 1. 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
  2. 2. 1 GETÚLIO DE OLIVEIRA VALENTIM ESTUDO COMPARATIVO ENTRE BANCOS DE DADOS RELACIONAIS E ORIENTADOS A OBJETOS VISANDO APLICAÇÕES COMERCIAIS Projeto de Monografia apresentado ao curso de Sistemas de Informação, do Instituto Luterano de Ensino Superior de Itumbiara-GO, como requisito parcial para obtenção do titulo de Bacharel em sistemas de informação, orientado pelo professor Bruno Souto Borges. Itumbiara, junho de 2013.
  3. 3. 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
  4. 4. 3 ESTUDO COMPARATIVO ENTRE BANCOS DE DADOS RELACIONAIS E ORIENTADOS A OBJETOS VISANDO APLICAÇÕES COMERCIAIS GETÚLIO DE OLIVEIRA VALENTIM Monografia defendida e aprovada, em 25 de Junho de 2013, pela banca examinadora: Professor Especialista Bruno Souto Borges Orientador e Professor do Curso de Sistemas de Informação Professor Hulgo Leonardo Jacinto Andrade Professor do Curso de Sistemas de Informação Professor Fabio Palhares dos Santos Professor do Curso de Sistemas de Informação
  5. 5. 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.
  6. 6. 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.
  7. 7. 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)
  8. 8. 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
  9. 9. 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
  10. 10. 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
  11. 11. 10 LISTA DE TABELAS Tabela 1 - Teste de inserção nos bancos de dados ..............................................................................64 Tabela 2 - Comparativo entre funcionalidades dos bancos .................................................................67
  12. 12. 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
  13. 13. 12 2.10.VANTAGENS E DESVANTAGENS DOS MODELOS RELACIONAIS E ORIENTADO A OBJETOS ............................................................................................. 41 2.10.1. Vantagens do Modelo Relacional ...................................................................... 41 2.10.2. Desvantagens do Modelo Relacional ................................................................. 42 2.10.3. Vantagens do Modelo de Objetos ...................................................................... 42 2.10.4. Desvantagens do Modelo de Objetos ................................................................. 43 2.11. LINGUAGEM PROGRAMAÇÃO ORIENTADA A OBJETOS ............................. 44 2.11.1. Conceitos da Orientação a Objetos ................................................................... 44 2.11.1.1. Abstração ....................................................................................................... 45 2.11.1.2. Encapsulamento ............................................................................................. 45 2.11.1.3. Herança .......................................................................................................... 45 2.11.1.4 Polimorfismo ................................................................................................... 46 2.11.2. Benefícios da POO ............................................................................................ 46 2.11.2.1. Produtividade ................................................................................................. 46 2.11.2.2. Ciclo de vida maior ........................................................................................ 47 2.12. CONSIDERAÇÕES FINAIS ................................................................................... 47 3. CAPÍTULO II – SGBD UTILIZADOS NA AVALIAÇÃO .......................................... 48 3.1. INTRODUÇÃO ......................................................................................................... 48 3.2. BANCO DE DADOS ORIENTADO A OBJETOS - DB4OBJECTS (DB4O) ........... 48 3.2.1. Definição e manipulação de dados ...................................................................... 49 3.3. BANCO DE DADOS RELACIONAL - SQL SERVER 2012 .................................... 53 3.3.1. Ferramentas de gerenciamento projeto e consulta ............................................... 53 3.3.1.1. SQL Server Management Studio ...................................................................... 53 3.4.BANCO DE DADOS RELACIONAL - POSTGRESQL ............................................ 54 3.5. CONSIDERAÇÕES FINAIS ..................................................................................... 56 4. CAPÍTULO III – METODOLOGIA............................................................................. 57 4.1. INTRODUÇÃO ......................................................................................................... 57 4.2. METODOLOGIA UTILIZADA ................................................................................ 57 4.3. CONSIDERAÇÕES FINAIS ..................................................................................... 58 5. CAPÍTULO IV – SOFTWARE UTILIZADO NO TESTE .......................................... 59 5.1. INTRODUÇÃO ......................................................................................................... 59 5.2. O SOFTWARE.......................................................................................................... 59 5.3. SOFTWARES UTILIZADOS NO PROJETO ........................................................... 60 5.4. SQL SERVER X POSTGRESQL X DB4O ............................................................... 60 5.4.1. SQL Server 2012 ................................................................................................. 60 5.4.2. PostgreSQL ......................................................................................................... 61 5.4.3.db4objects ............................................................................................................ 62 5.5. TESTE....................................................................................................................... 63 5.5.1. Inserção .............................................................................................................. 64 5.6. CONSIDERAÇÕES FINAIS ..................................................................................... 65 6. CAPÍTULO V – COMPARATIVO ............................................................................... 66 6.1. INTRODUÇÃO ......................................................................................................... 66
  14. 14. 13 6.2. COMPARATIVO DE FUNCIONALIDADES .......................................................... 66 6.3. DESCRIÇÃO DAS FUNCIONALIDADES .............................................................. 68 6.4. CONSIDERAÇÕES FINAIS ..................................................................................... 70 7. CAPÍTULO VI - ANALISES E RESULTADOS .......................................................... 71 7.1. INTRODUÇÃO ......................................................................................................... 71 7.2. ANALISES E RESULTADOS .................................................................................. 71 7.3. CONSIDERAÇÕES FINAIS ..................................................................................... 72 8. CAPÍTULO VII – CONCLUSÕES E TRABALHOS FUTUROS ............................... 73 8.1. INTRODUÇÃO ......................................................................................................... 73 8.2. CONCLUSÕES ......................................................................................................... 73 8.3. TRABALHOS FUTUROS ........................................................................................ 74 REFERÊNCIA BIBLIOGRÁFICA .................................................................................. 75
  15. 15. 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
  16. 16. 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
  17. 17. 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.
  18. 18. 17 2. CAPÍTULO I - REFERENCIAL TEÓRICO 2.1. Introdução Os bancos de dados e sua tecnologia têm um impacto muito importante sobre o uso crescente dos computadores. É correto afirmar que os bancos de dados desempenham um papel fundamental em quase todas as áreas em que se utilizam computadores, incluindo negócios, comércio eletrônico, engenharia, medicina, genética, direito, educação e várias outras que hoje em dia são muitas. Serão abordadas neste capítulo as características dos modelos de banco de dados relacional e orientados a objetos, descrevendo suas características que são relevantes para a realização deste trabalho. 2.2. Banco de dados Segundo Date (2004), bancos de dados são conjuntos de dados com uma estrutura regular que organizam informação, ou seja, é um conjunto de registros dispostos em estrutura regular que possibilita a reorganização dos mesmos e produção de informação. Essas estruturas costumam ter a forma de tabelas: cada tabela é composta por linhas e colunas. Informações utilizadas para um mesmo fim são agrupadas num banco de dados. A apresentação dos dados pode ser semelhante à de uma planilha eletrônica, porém os sistemas de gestão de banco de dados possuem características especiais para o armazenamento, classificação e recuperação dos dados. Um banco de dados é uma coleção de dados relacionados que pode ser armazenada sob alguma forma física. Os dados armazenados em um banco de dados representam algum aspecto específico do mundo real — um universo de discurso de onde os dados são obtidos — e apresentam algum grau de coerência lógica entre seus componentes. Portanto, uma coleção aleatória de dados não constitui um banco de dados. (RICARTE, 1998)
  19. 19. 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;
  20. 20. 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.
  21. 21. 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.
  22. 22. 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.
  23. 23. 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
  24. 24. 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.
  25. 25. 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.
  26. 26. 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.
  27. 27. 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.
  28. 28. 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
  29. 29. 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
  30. 30. 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
  31. 31. 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
  32. 32. 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.
  33. 33. 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)
  34. 34. 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.
  35. 35. 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.
  36. 36. 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.
  37. 37. 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,
  38. 38. 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
  39. 39. 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
  40. 40. 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
  41. 41. 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.
  42. 42. 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:
  43. 43. 42  Bastante usado e com um grande legado (Date, 2000);  Grande número de ferramentas e características que implementam o SQL, como padrões de conectividade, ferramentas de relatório, ferramentas de OLAP e de backup, padrões de recuperação e ferramentas gráficas (Machado, 2009);  Quando o sistema de Modelo Relacional é instalado, já vem pronto para uso (Date, 2000);  O Banco de Dados pode ser manipulado e alterado independentemente da aplicação (Date, 2000);  Utiliza na normalização para ser mais compreensível e aplicável. 2.10.2. Desvantagens do Modelo Relacional As principais desvantagens do Modelo Relacional são:  Necessidade de seleção de chaves entre tabelas;  Necessidade de mapeamento para conversão entre a linguagem de programação orientada a objetos e o formato relacional para transformar objetos em estruturas de tabelas, o que o torna mais lento em tempo de compilação e execução e ainda exige parte substancial de código (Silberschatz et al., 1999);  Codificação de conversão entre Objetos e Tuplas opera fora do paradigma de programação orientada a objetos e há um risco maior de erros não detectados (Silberschatz et al., 1999);  Dificuldade de modelar novas aplicações e objetos complexos, como por exemplo, dados multimídia (Silberschatz et al., 1999). 2.10.3. Vantagens do Modelo de Objetos As principais vantagens do Modelo de Objetos são:  Utilização dos princípios das linguagens de programação orientada a objetos (Silberschatz et al., 1999);  Maior consistência em manipulações de dados;  Armazenamento direto de tipos de dados complexos (Silberschatz et al., 1999);
  44. 44. 43  Habilidade de alterar a definição de um objeto sem modificar o resto do sistema (Silberschatz et al., 1999);  Não possuem Chaves Primarias nem Estrangeiras, aumentando o desempenho das consultas e processo (Santos, 2009);  Utilização de identificador de objeto (OID) único e imutável, criado pelo sistema automaticamente e que são implementados em baixo nível (Silberschatz et al., 1999);  Permite manipular o Banco de Dados diretamente com a linguagem de programação sem intermediação de outra linguagem, o que possibilita ter objetos muito complexos sem necessidade de transformar os dados (Silberschatz et al., 1999);  Objetos se comunicam entre si através de mensagens (Santos. 2009). 2.10.4. Desvantagens do Modelo de Objetos As principais desvantagens do Modelo de Objetos são:  Pouco usado (Date, 2000);  Ferramentas gráficas para desenvolvimento possuem poucos recursos. Ausência das ferramentas e características disponíveis em SQL (Machado, 2009);  Quando o sistema é instalado não fica disponível para uso imediato, ele é adaptado para construções de classes e métodos (Date, 2000);  Instabilidade no direcionamento de aplicações, já que tudo se resume a objetos (Machado, 2009);  Linguagens para consultas não padronizadas (Date, 2000);  Gasta-se mais tempo para implementação do código para manusear objetos persistentes e apresenta dificuldades de especificar restrições (Date, 2000);  Mais chance de cometer erros no Banco de Dados, já que as linguagens de programação são mais poderosas (Silberschatz et al., 1999);  Identificadores são específicos do sistema e devem ser traduzidos se houver necessidade de mudar para outro sistema (Silberschatz et al., 1999).
  45. 45. 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
  46. 46. 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
  47. 47. 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.
  48. 48. 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.
  49. 49. 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.
  50. 50. 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.
  51. 51. 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");
  52. 52. 51  Criando um objeto usuário Usuario usu = new Usuario("teste", "123", " de Teste", "teste@teste");  Armazenando o usuário acima db.store(usu);  Fechando o arquivo db4o db.close();  Classe para consulta. Para recuperar um objeto no db4 é necessário criar um protótipo do objeto para usar como exemplo do que deve ser recuperado. Pois a instancia de ObjectContainer recuperará os objetos que se pareça com protótipo que é informado.  Abrindo o arquivo db4o ObjectContainer db = Db4o.openFile("nome da Package.dbo");  Criando o prototipo de exemplo Usuario usu = new Usuario (―teste‖, null, null, null);  Invocando a consulta ObjectSet<Usuario> result = db.queryByExample(usu); O objeto recuperado estará em result. Neste exemplo foram recuperados todos os objetos onde o login era ―teste‖.  Fechando o arquivo db4o db.close();  Classe para atualização. Para atualizar um objeto também e necessário utilizar um protótipo. Pois a instancia de ObjectContainer recuperará os objetos que se pareça com protótipo que é informado e os atualizará com os novos atributos.  Abrindo o arquivo db4o ObjectContainer db = Db4o.openFile("nome da Package.dbo");
  53. 53. 52  Criando o protótipo de exemplo Usuario usu = new Usuario (―teste‖, null, null, null, );  Recuperando usuario ObjectSet<Usuario> usuarios = db.queryByExample(usu); Usuario usua = usuarios.next();  Atualizando dados de login usua.setlogin(―exemplo‖);  Armazena o usuário atualizado db.store(usu);  Fechando o arquivo db4o db.close();  Classe Para deletar os dados. É preciso invocar uma consulta que recuperara todos os usuários armazenados e em seguida utilizar o método para deletados.  Abrindo o arquivo db4o ObjectContainer db = Db4o.openFile("nome da Package.dbo");  Recuperando usuario ObjectSet<Usuario> usuarios = db.queryByExample(Usuario.class);  Deletando todos os usuarios for(Usuario usu : usuarios) { db.delete(usu);  Fechando o arquivo db4o db.close();

×