Trabalho de Conclusão de Curso

INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA
FLUMINENSE
CAMPUS CAMPOS CENTRO
BACHARELADO EM SISTEMAS DE INFORMAÇÃO
DENAILDO JUNIO BORGES DE SOUZA
FELIPE CABRAL VIANA
COMPARANDO A EFICÁCIA DE BANCO DE DADOS ORIENTADO A OBJETOS
COM BANCO DE DADOS RELACIONAL ATRAVÉS DE PESQUISA
BIBLIOGRÁFICA E IMPLEMENTAÇÃO DE PROTÓTIPO
CAMPOS DOS GOYTACAZES
2016
DENAILDO JUNIO BORGES DE SOUZA
FELIPE CABRAL VIANA
COMPARANDO A EFICÁCIA DE BANCO DE DADOS ORIENTADO A OBJETOS
COM BANCO DE DADOS RELACIONAL ATRAVÉS DE PESQUISA
BIBLIOGRÁFICA E IMPLEMENTAÇÃO DE PROTÓTIPO
Monografia apresentada ao Instituto Federal de Educação,
Ciência e Tecnologia Fluminense Campus Campos Centro
como requisito parcial para a conclusão do Curso de
Bacharelado em Sistemas de Informação.
Orientadora: Profª. Aline P. V. de Vasconcelos (D. SC)
Co-orientadora: Profª. Aline Gomes Cordeiro (M. SC)
Campos dos Goytacazes - RJ
Junho/2016
Dados Internacionais de Catalogação na Publicação (CIP)
Biblioteca. Setor de Processos Técnicos (IFF)
S729c Souza, Denaildo Junio Borges de
Comparando a eficácia de Banco de Dados Orientado a Objetos com
Banco de Dados Relacional através de pesquisa bibliográfica e
implementação de protótipo / Denaildo Junio Borges de Souza,
Felipe Cabral Viana – 2016.
50 f.: il.
Orientadora: Aline P. V. de Vasconcelos.
Monografia (Bacharelado em Sistemas de Informação). Instituto
Federal de Educação, Ciência e Tecnologia Fluminense. Campus
Campos Centro. Campos dos Goytacazes (RJ), 2016.
Referências: p. 48-50.
1.
2.
1. Banco de dados relacionais. I. Vasconcelos, Aline P. V. de, orient.
II. Título.
CDD – 005.756
DENAILDO JUNIO BORGES DE SOUZA
FELIPE CABRAL VIANA
COMPARANDO A EFICÁCIA DE BANCO DE DADOS ORIENTADO A OBJETOS
COM BANCO DE DADOS RELACIONAL ATRAVÉS DE PESQUISA
BIBLIOGRÁFICA E IMPLEMENTAÇÃO DE PROTÓTIPO
Monografia apresentada ao Instituto Federal de
Educação, Ciência e Tecnologia Fluminense,
Campus Campos-Centro, como requisito parcial
para conclusão do Bacharelado em Sistemas de
Informação.
Aprovada em _______ de Junho de 2016.
Banca Avaliadora:
......................................................................................................................................................
Profª Aline Pires Vieira de Vasconcelos
Doutora em Engenharia de Sistemas e Computação/COPPE-UFRJ
Instituto Federal de Educação, Ciência e Tecnologia Fluminense
......................................................................................................................................................
Profª Cibelle Degel Barbosa
Doutora em Produção Vegetal/UENF
Instituto Federal de Educação, Ciência e Tecnologia Fluminense
......................................................................................................................................................
Profª Verônica Aguiar da Silva
Doutora em Biociências e Biotecnologia/UENF
Instituto Federal de Educação, Ciência e Tecnologia Fluminense
AGRADECIMENTOS
Agradecemos primeiramente a Deus, por ter nos dado força, foco e fé para chegar
aonde chegamos, a nossos familiares, por terem sido a base e o porto seguro nos momentos
de desanimo e cansaço no decorrer dessa jornada, a todos nossos professores e amigos, que
construíram conosco esse caminho que queremos e temos o desejo de continuar trilhando em
quanto continuarmos com brilho nos olhos. Agradecemos especialmente a Professora e
Orientadora Aline Vasconcelos e a Professora e Co-orientadora Aline Cordeiro por nos
ajudar a crescer ainda mais como profissionais, como pessoas e por estar hoje realizando a
entrega desse projeto para a conclusão de nosso sonho.
RESUMO
Os Bancos de Dados Relacionais existem desde a década de 70, sendo predominantes
no mercado de software, até o momento atual, em função da maturidade e confiabilidade que
as empresas adquiriram nestes. Por outro lado, o paradigma de Orientação a Objetos (OO) se
estabelece, desde a década de 90, como o paradigma dominante nas atividades de análise,
projeto e implementação de sistemas de software, permitindo se trabalhar com abstrações
mais próximas do mundo real, bem como com o mesmo conceito em todo o ciclo de vida do
software. Porém, apesar de permitir uma padronização nas etapas do ciclo de vida, a OO não
emplacou ainda na área de Banco de Dados, exigindo um mapeamento entre estes paradigmas
para se concluir com êxito um projeto de desenvolvimento de software. Dessa forma, este
trabalho tem como objetivo estabelecer uma comparação entre o Banco de Dados relacional e
o Banco de Dados Orientado a Objetos, a fim de se verificar vantagens e desvantagens no seu
uso, de forma a motivar ou não a migração para um Banco Orientado a Objetos. A fim de se
atingir estes objetivos de comparação, foram desenvolvidos protótipos para implementação
em Sistemas Gerenciadores de Bancos de Dados nos dois paradigmas, a partir de um mesmo
domínio de problema. Este modelo foi testado segundo critérios de comparação
adequadamente definidos, com o objetivo de se obter indícios da eficiência e eficácia dos
diferentes bancos.
Palavras chave: Paradigma, Banco de Dados Relacional, Banco de Dados Orientado a
Objetos, Maturidade, Confiabilidade, Eficiência, Eficácia.
ABSTRACT
Relational databases have been around since the 70s and they are predominant in the
software market, until the present time, because of the maturity and reliability that companies
have acquired in these. Furthermore, the Object Oriented Paradigm (OO) is established, since
the 90s, as the predominant paradigm in software system analysis, design and
implementation, allowing the work with abstractions closest to the real world, as well as the
use of the same concept in the entire software life cycle. However, despite of the
standardization that the OO promotes in the distinct stages of the software life cycle, this
paradigm is not yet established in the database area, requiring a mapping between these
paradigms to successfully complete a software development project. Thus, this study aims to
establish a comparison between the relational database and the object database, in order to
verify advantages and disadvantages in their use, motivating or not the migration to a Object
Oriented Database Management System (DBMS). In order to achieve these comparative
purposes, prototypes will be developed for implementation in DBMS in both paradigms, from
the same domain problem. This model will be tested according to properly defined
comparison criteria, in order to obtain evidences of the efficiency and effectiveness of the
different systems.
Keywords: Paradigm, Relational Database, Object Oriented Database, Maturity,
Reliability, Efficiency, Effectiveness.
LISTA DE ILUSTRAÇÕES
Figura 1 – Exemplo de Herança Simples
17
Figura 2 – Exemplo de Herança Múltipla.
17
Figura 3 – Exemplo de Polimorfismo.
18
Figura 4 – Exemplo de Chave Primária e Chave Estrangeira.
20
Figura 5 – Exemplo de Modelo de Classe e Modelo de Banco de dados com chaves. 21
Figura 6 – Exemplo de Mapeamento.
26
Figura 7 – Diagrama de Classe
32
Figura 8 – Mapeamento do Diagrama de Classe
33
LISTA DE TABELAS
Tabela 1 – Resultado dos Testes de Inserção Realizados no SGBDOO
41
Tabela 2 – Resultado dos Testes de Inserção Realizados no Banco Relacional
42
Tabela 3 – Resultado dos Testes de Atualização Realizados no SGBDOO
42
Tabela 4 – Resultado dos Testes de Atualização Realizados no Banco Relacional
42
Tabela 5 – Resultado dos Testes de Consulta Realizados no SGBDOO
43
Tabela 6 – Resultado dos Testes de Consulta Realizados no Banco Relacional
43
Tabela 7 – Resultado dos Testes de Exclusão Realizados no SGBDOO
43
Tabela 8 – Resultado dos Testes de Exclusão Realizados no Banco Relacional
43
Tabela 9 – Resultado Final dos Testes Realizados Anteriormente nos Bancos
44
LISTA DE ABREVIATURAS E SIGLAS
OO – Orientação a Objetos.
IBM – International Business Machines.
SGBD – Sistema de Gestão de Base de Dados.
CPF – Cadastro de Pessoa Física.
RG – Registro Geral.
CNPJ – Cadastro Nacional de Pessoa Jurídica.
SQL – Structured Query Language.
OID – Object Identifier.
DER – Diagrama Entidade-Relacionamento.
SUMÁRIO
1 – INTRODUÇÃO
12
1.1 – MOTIVAÇÃO E JUSTIFICATIVA
12
1.2 - OBJETIVOS
13
1.3 – METODOLOGIA DO TRABALHO
14
1.4 – ORGANIZAÇÃO DO TRABALHO
14
2 – REFERENCIAL TEÓRICO
2.1 – O PARADIGMA DE ORIENTAÇÃO A OBJETOS
15
15
2.1.1 – OBJETO
15
2.1.2 - ENCAPSULAMENTO
15
2.1.3 - HERANÇA
16
2.1.4 - POLIMORFISMO
18
2.2 – O PARADIGMA RELACIONAL
18
2.2.1 – O MODELO RELACIONAL
19
2.2.2 – RESTRIÇÕES DE INTEGRIDADE SOBRE RELAÇÕES
21
2.2.3 – NORMALIZAÇÃO EM BANCOS RELACIONAIS
22
2.2.4 – SQL (STRUCTURED QUERY LANGUAGE)
22
2.2.5 – PROJETO LÓGICO DE BANCOS DE DADOS
23
2.3 – QUEBRA DE PARADIGMAS: O.O. X RELACIONAL
23
2.3.1 – MAPEAMENTO ENTRE MODELOS: O.O. - RELACIONAL
24
2.3.2 – BANCO DE DADOS ORIENTADO A OBJETOS
27
2.3.3 – COMPARANDO BANCO DE DADOS O.O. COM BANCO DE
28
DADOS RELACIONAL
2.4 – CRITÉRIOS DE AVALIAÇÃO
3 – COMPARAÇÃO DOS BANCOS DE DADOS NA PRÁTICA POR MEIO
29
31
DE MODELO ACADÊMICO
3.1 – ESTUDO DE CASO
31
3.2 – TECNOLOGIAS APLICADAS
34
3.2.1 – O BANCO DE DADOS RELACIONAL MySQL
34
3.2.2 – DB4OBJECT
35
3.2.3 – EXEMPLO PRÁTICO: CONFIGURANDO OS SGBD’S PARA
35
USO
3.2.4 – IMPLEMENTANDO O ACESSO AOS BANCOS
37
3.2.5 – TESTANDO OS BANCOS
41
3.3 – CONCLUSÕES OBTIDAS
4 - CONCLUSÃO
45
46
4.1 - CONTRIBUIÇÕES
46
4.2 - LIMITAÇÕES
47
4.3 – TRABALHOS FUTUROS
48
5 – REFERÊNCIAS
48
12
1 - INTRODUÇÃO
1.1 - MOTIVAÇÃO E JUSTIFICATIVA
Atualmente é sabido que o desenvolvimento Orientado a Objetos (OO) é uma
realidade no universo do desenvolvimento de software. Extremamente popular, graças à sua
flexibilidade e suporte à reutilização, ele é explorado pela maioria, das empresas que
trabalham projetando software. O termo “Orientado a Objetos” foi criado por Alan Kay
(1966), mas seus conceitos foram realmente utilizados por Jogan Dahl (1967) e Kristen
Nygaard (1967) na linguagem Simula 67, o que demonstra que este paradigma de software
não é recente, porém, apenas a partir da década de 90 é que este vem sendo aceito nas
grandes empresas de desenvolvimento de software. Como grandes fatores que contribuíram
para o crescimento do paradigma de Orientação a Objetos nos últimos anos, estão a
proximidade dos conceitos deste paradigma a abstrações do próprio mundo real e a utilização
do mesmo conceito, a classe, do início ao fim do ciclo de vida do software. Além disso, por
meio da herança este paradigma propicia o reuso e maior eficácia no desenvolvimento de
software.
O conceito de Orientação a Objetos foi criado para tentar aproximar o mundo real do
virtual, daí a ideia de Objeto, pois, o mundo é composto de Objetos. Diante da propagação do
conceito da OO no processo de análise, projeto e implementação de software, um fator chama
a atenção: grande parte das empresas de desenvolvimento de software opta na área de
persistência por utilizar o modelo de Banco de Dados Relacional. Criado com o intuito de
facilitar e agilizar o acesso a dados, os bancos de dados no início eram basicamente uma
digitalização das fichas de cadastros de empresas sem nenhuma associação entre elas, por
exemplo, produto não era associado à fábrica que o produziu, ambos eram controlados por
um software sem ligação entre eles. Este conceito mudou em 1970 quando o pesquisador
Edgar Frank (Frank, 1970) da IBM lançou o conceito de Banco de Dados Relacional em seu
famoso artigo “A Relational Model of Data for Large Shared Data Banks” revolucionando
por completo a área de persistência de dados. Além da sua popularidade devido ao seu largo
uso, o modelo relacional evoluiu e hoje se tornou um sinônimo de segurança e confiabilidade
para o armazenamento de grandes volumes de dados nas empresas.
Com base nesse cenário, algumas questões são levantadas: Será que o modelo de
Orientação a Objetos é tão revolucionário na área de persistência de dados quanto é na área
do Desenvolvimento? Será que o Banco de Dados Orientado a Objetos é tão seguro e estável
13
quanto o Banco de Dados Relacional, ou seja, tem maturidade? Será que o uso da OO na área
de persistência ainda não emplacou pela confiabilidade que as empresas depositam no Banco
Relacional? Além disso, qual modelo é mais eficiente e eficaz para se utilizar no seu projeto?
A fim de apontar alguns caminhos que possam ajudar a solucionar essas e outras dúvidas,
propõe-se a pesquisa, aqui apresentada, que motiva o desenvolvimento desse trabalho de
conclusão de curso.
1.2 - OBJETIVOS
Diante do exposto, este trabalho tem como objetivo principal a análise das diferenças
de Banco de Dados Relacional para Banco de Dados Orientado a Objetos, demonstrando as
suas vantagens e desvantagens através de critérios de comparação devidamente estabelecidos,
como:
·
Facilidade de implementação do banco de dados, considerando-se o ciclo de vida do
software onde o paradigma OO é adotado nas etapas de análise, projeto e
implementação;
·
Tempo de desenvolvimento de rotinas de acesso ao banco;
·
Eficiência no acesso;
·
Maturidade;
·
Estabilidade;
·
Confiabilidade.
Para se atingir tais objetivos, deverá ser realizada ampla pesquisa bibliográfica, bem como a
implementação de um protótipo, no domínio escolar, desenvolvido para este fim, e levandose em conta a sua implementação em um Gerenciador de Banco de Dados dentro de cada
paradigma.
Os Sistemas Gerenciadores de Bancos de Dados (SGBD’s) utilizados serão o
Db4Objects (Db4O) e o MySQL, utilizaremos os mesmos por serem os mais robustos e mais
utilizados como Banco OO e Relacional, a linguagem a ser utilizada é o Java, devido a sua
facilidade de comunicação com diversos tipos de banco de dados. Os protótipos serão
desenvolvidos tanto para que se comunique com o Banco de Dados Relacional quanto o
Banco de Dados Orientado a Objetos.
14
1.3 - METODOLOGIA DO TRABALHO
Este trabalho se propõe a fazer uma comparação entre o Banco de Dados Relacional e
o Banco de Dados Orientado a Objetos (OO), verificando, assim qual dos dois pode ser mais
eficaz em determinados cenários de uso e avaliando a quebra de paradigma. Para se atingir tal
objetivo, as seguintes etapas de trabalho são identificadas:
-
Pesquisa bibliográfica sobre ambos os paradigmas e sobre trabalhos que já
vislumbraram tal comparação;
-
Modelagem e implementação de protótipo no domínio acadêmico para testes,
abordando os principais conceitos e diferenças entre os dois paradigmas;
-
Análise dos resultados obtidos com a implementação do protótipo em um SGBD
relacional, a saber o MySQL, e em um SGBD OO, a saber, o Db4Object, a partir de
programação do modelo na linguagem Java;
-
Comparação dos resultados obtidos e escrita da monografia.
Por meio do protótipo e das pesquisas, será possível avaliar determinados fatores que
diferenciam os bancos, bem como analisar a quebra de paradigma presente na implementação
e nos testes. A pesquisa bibliográfica deve investigar a maturidade dos SGBDs nos diferentes
paradigmas quanto à capacidade de armazenamento e gerenciamento de grande volume de
dados e de diferentes tipos de dados, como texto, número, mídia, áudio etc.
1.4 - ORGANIZAÇÃO DO TRABALHO
Partindo desta Introdução, esse trabalho está organizado da seguinte forma: o Capítulo
2 trata do Referencial Teórico estudado para embasar este trabalho, envolvendo ambos os
paradigmas, suas diferenças e trabalhos relacionados; o Capítulo 3 aborda a implementação
dos protótipos e os testes realizados nos SGBDs em ambos os paradigmas, levantando
algumas conclusões obtidas com a sua comparação; e, o Capítulo 4 apresenta as Conclusões,
destacando as contribuições, limitações e trabalhos futuros, que visam permitir a
continuidade da presente pesquisa.
15
2 - REFERENCIAL TEÓRICO
Este capítulo traz um breve referencial teórico acerca de conceitos básicos e trabalhos
relacionados sobre os Paradigmas de Orientação a Objetos, Relacional e sobre os Sistemas
Gerenciadores de Bancos de Dados nestes paradigmas.
2.1 - O PARADIGMA DE ORIENTAÇÃO A OBJETOS
O modelo orientado a objetos visualiza os sistemas como coleção de objetos,
permitindo assim a melhora da reusabilidade e multiplicidade dos produtos de software. Tem
como objetivo simular situações do mundo real, transferindo a ideia de objeto que temos para
dentro da computação. Dessa forma, os sistemas não vão ser um conjunto estruturado e sim
um conjunto de objetos que interagem e colaboram entre si. Um outro fator importante da OO
é que o conceito de objeto se mantém por todo o ciclo de vida do software, diferente do que
ocorria nos paradigmas anteriores (FARINELLI, 2007).
2.1.1 - OBJETO
A condição é utilizada para definir um componente do mundo real, uma entidade que
é digna de representação ao ambiente que será simulado, sendo assim, são instâncias de uma
determinada classe componente de um sistema, determinando a informação que o objeto vai
conter e como vai ser feita a manipulação do mesmo. É uma representação da realidade capaz
de conter um estado, o qual deve ser encapsulado, e conceder um série de operações para
recuperar ou alterar este estado.
Como exemplo de objetos, pode-se citar objetos físicos, como um sabonete, uma
vassoura, ou abstratos, como disciplinas, cursos, ou ainda seres reais, como um cliente, um
vendedor etc. O objeto é acessado por eventos que disparam suas ações ou métodos, como
varrer, cadastrar disciplina, o cliente realizar uma compra etc (FARINELLI, 2007). Cada
objeto possui um identificador próprio.
2.1.2 – ENCAPSULAMENTO
Utilizando-se deste princípio, é possível obter transparência no objeto, o qual não
deixa seus dados “a mostra”, sendo esses somente acessíveis por meio de suas operações.
16
Uma classe de objetos, como Pessoa, possui atributos (valores de dados) e métodos
(operações), sendo os atributos privados e os métodos públicos. No exemplo da Pessoa,
poderia se dizer que esta possui como atributos nome, endereço, telefone e cpf, que estão
“escondidos” - encapsulados - e métodos, como, obterNome, atualizarNome, obterCPF,
atualizarCPF, que seriam visíveis a todos para acesso encapsulado aos dados. Assim, o
próprio objeto controla o acesso aos seus dados ou estado.
A forma de utilizar esse mecanismo é diferente da forma tradicional. Na orientação a
objetos esses dados encapsulados estão dentro de uma única entidade e a única forma de
saber o que está dentro ou alterar os atributos é utilizando seus métodos.
A possibilidade de se realizar alterações internas no objeto, agregando novos métodos
sem alterar outros componentes do sistema é mais uma grande vantagem do encapsulamento
(FARINELLI, 2007).
2.1.3 - HERANÇA
Representa uma forma de relacionamento no qual uma classe consegue reutilizar os
atributos, relacionamentos e métodos de outra, para assim, ampliar ou especificar a ela
mesma. Por exemplo, retomando a classe Pessoa, esta poderia especializar-se em Aluno e
Professor, considerando-se um ambiente acadêmico, onde Aluno e Professor herdariam todas
as propriedades de Pessoa, acrescentando as suas particularidades como estudar e lecionar.
Analisando pelo lado prático, a utilização da herança na orientação a objetos nos ajuda no
aproveitamento de modelo e do código, trazendo a vantagem de redução de esforço e custo
no desenvolvimento. Além do reaproveitamento do código, a herança tem também como
vantagem a consistência, pois uma vez que um comportamento é modificado em uma classe,
todas as demais classes descendentes desta também estarão usando o método atualizado sem
precisar reprogramar o código.
Dentro dessa questão temos dois tipos de herança, a herança simples e a herança
múltipla. A mesma é considerada simples quando uma classe herda as características de
apenas uma superclasse ou classe pai como exemplifica a Figura 1.
A mesma é considerada múltipla quando a classe herda características de duas ou
mais superclasses, assumindo diferentes papeis na execução do sistema, conforme
visualizamos na Figura 2 (FARINELLI, 2007). Sendo que nada impede que a classe
FuncionárioCliente tenha seus próprios atributos e métodos, além de herdar das classes
acima.
17
Figura 1 - Exemplo de Herança Simples.
Figura 2 - Exemplo de Herança Múltipla.
18
2.1.4 - POLIMORFISMO
Consiste na técnica de uma variável fazer referência em tempo de execução a objetos
de diversas classes, porém sendo todos “filhos” de uma mesma hierarquia de superclasses.
Assim, polimorfismo, um conceito oriundo da herança, é o nome dado à possibilidade do
método se comportar de uma maneira diferente dependendo do tipo do objeto que receberá a
sua chamada, sendo este referente a uma subclasse em uma mesma hierarquia de classes. O
polimorfismo também pode ser atingido quando objetos implementam uma mesma interface
conforme visualizamos na Figura 3 (FARINELLI, 2007), nessa interface é definida as
opções, dependendo da escolha do usuário, qual método de classe será ativado.
Figura 3 - Exemplo de Polimorfismo.
2.2 - O PARADIGMA RELACIONAL
O Banco de Dados Relacional é o mais usado, por mais que existam novos caminhos
a serem seguidos como a orientação a objetos, ele continua sendo o modelo dominante no
mercado de banco de dados. Embora a OO predomine como paradigma nas fases de Análise,
Projeto e Programação, o modelo relacional ainda impera na área de Banco de Dados, o que
gera uma necessidade de mapeamento entre paradigmas no desenvolvimento completo de um
software. Esse modelo foi proposto por Edgar Codd (70), como uma forma inovadora de
19
representação de dados. Ele demonstrou que a visão relacional dos dados permite a sua
apresentação em uma forma natura, não precisando assim de estruturas para a sua
reprodução. Baseia-se no conceito de álgebra relacional, possuindo base matemática, o que
permitiu que esse modelo superasse os demais modelos existentes naquela época, tendo como
maiores vantagens, a representação simples dos dados, com baixa complexidade, permitindo
que diversas e amplas formas de consultas possam ser facilmente expressas (MACÁRIO et
al. , 2007).
2.2.1 - O MODELO RELACIONAL
A predominante construção para reprodução dos dados é a relação, essa que consiste
de um esquema e de várias instâncias. É representada em forma de tabela, onde os dados são
dispostos na forma de colunas e registros, que são informações acerca de uma pessoa ou
objeto, são as linhas.
O esquema descreve o nome da relação (tabela) e o nome e o domínio de cada coluna,
chamada também de atributo. O domínio do atributo é referido no esquema por seu tipo e tem
importância crucial para restringir os valores que este atributo pode vir a adquirir. Instância
de uma relação é o aglomerado de linhas, nominadas tuplas, diferentes, que assim vão vir a
compor a relação em determinado momento no tempo, sendo variável, uma vez que o número
de tuplas e o conteúdo desses atributos podem sofrer variações. Elas devem acompanhar
sempre o seu respectivo esquema, apreciando o número de atributos, bem como os domínios.
Essa é uma das restrições dos bancos relacionais, chamada restrição de domínio e é tida como
muito importante, podemos visualizar um exemplo na Figura 4 abaixo as chaves primárias:
uidaluno, uidcurso, uidmatriz, uidresultadoaluno, uiddisciplina, uidturma, uidturmaprofessor
e uidprofessor. Como exemplo de chave estrangeira, temos como exemplo o uidturma e o uid
curso que estão na classe Aluno para fazer a referência entre as classes.
20
Figura 4 - Exemplo de Chave Primária e Chave Estrangeira.
21
2.2.2 - RESTRIÇÕES DE INTEGRIDADE SOBRE RELAÇÕES
A integridade do modelo relacional é composta por duas regras gerais, a saber a
integridade da entidade e a integridade referencial. Essas regras são genéricas, no sentido que
podem ser utilizadas em todos os bancos de dados que se proponham a seguir o modelo
relacional. É normal que um determinado banco de dados tenha outras regras, próprias dele,
além das demais regras originais. As regras citadas referem-se, respectivamente, às chaves
primárias e às chaves estrangeiras. A restrição de entidade diz respeito ao fato de que cada
relação ou tabela deve ter um ou mais atributos cujos valores identifiquem as suas tuplas
unicamente. É o conceito de chave primária. No caso da Pessoa, o mais indicado é utilizar um
oid, fazendo referência assim a um identificador único, retirando assim a referência a dados
que podem ser modificados com o tempo, proporcionando assim, uma melhor utilização do
banco. A restrição de integridade referencial estabelece que duas ou mais tabelas se
relacionam pelo valor da chave primária, que se torna chave estrangeira na outra. Por
exemplo, para dizermos que Pessoa trabalha em uma Empresa, o oid da empresa, a sua chave
primária, deveria migrar para a Pessoa, como mais um atributo ou coluna de suas linhas
(DATE, 2003). Confira abaixo um exemplo na Figura 5.
Figura 5 - Exemplo de Modelo de Classe e Modelo de Banco de dados com chaves.
22
2.2.3. – NORMALIZAÇÃO EM BANCOS RELACIONAIS
Podemos utilizar um dado grupo de dependências funcionais para projetar um banco
de dados relacional, evitando a maior das propriedades não desejadas. Quando projetamos,
pode tornar-se desnecessário decompor uma relação em diversas relações menores.
Utilizando a dependência funcional, podemos definir algumas formas normais que
representam “bons” projetos de bancos de dados.
Existem esquemas de relação que não estão normalizados o bastante, no sentido que
eles ainda possuem problemas de repetição de informação. Para realizar o tratamento desse
problema, temos a necessidade de definir uma nova forma de restrição, intitulada de
dependência multivalorada. Como foi feito com as dependências funcionais, utilizaremos as
dependências funcionais multivaloradas para definir uma forma normal para os esquemas das
relações.
A propriedade sem perda na junção é uma das diversas propriedades para o projeto de
um banco de dados, essa propriedade é essencial, sem ela, há perda de informação. Quando
restringimos o conjunto das relações válidas entre as que satisfazem um conjunto de
dependências funcionais e multivaloradas, temos a possibilidade de usar essas dependências
para mostrar que certas decomposições são decomposições sem perda na junção.
Por causa da importância desse conceito, é útil conseguir restringir um conjunto de relações
válidas sobre um esquema para aquelas relações para as quais uma dada decomposição sem
perda na junção, isto será definido como uma restrição, chamada dependência de junção
(SILBERSCHATZ et al., 1999).
2.2.4 - SQL (Structured Query Language)
É a linguagem comercial mais utilizada no mercado para a manipulação e consulta
aos Sistemas Gerenciadores de Bancos de Dados (SGBDs). Ela utiliza uma mistura de
construtores em álgebra e cálculo relacional em suas consultas (SILBERSCHATZ et al.,
1999).
Um banco de dados relacional compõe-se de um conjunto de relações, conforme já
mencionado, onde cada uma dessas relações é designada por um único nome. A linguagem
SQL possui comandos para a manipulação do banco de dados, como: Insert (para a inclusão
de dados); Delete (para a exclusão de dados); Update (para a atualização de dados). Possui
23
comandos também para a definição do esquema, como: Create Table (para a criação de
Tabelas), Alter Table (para a atualização de Tabelas) e Drop Table (para a exclusão de
Tabelas). Porém, o comando para consulta a dados Select é o mais poderoso desta linguagem
e o que motivou a criação da mesma. A estrutura básica de uma expressão SQL - Select
consiste em três cláusulas: Select, From e Where, onde:
● Select – na sua etapa final, corresponde à operação de projeção da álgebra relacional,
é utilizada para relacionar os atributos desejados no resultado de uma consulta.
● From - corresponde à operação de produto cartesiano da álgebra relacional, ela
associa as relações que serão pesquisadas durante a evolução de uma determinada
expressão.
● Where - corresponde à seleção do predicado da álgebra relacional, consiste em um
predicado compreendendo atributos da relação que aparece na cláusula from,
estabelecendo a condição de consulta.
O SQL constrói um produto cartesiano das relações indicadas na cláusula from,
executa uma seleção de interseção em álgebra relacional utilizando o predicado da cláusula
where e indica o resultado sobre os atributos da cláusula select. Na prática, o SQL pode
converter a expressão em uma forma equivalente, que pode ser executada de forma mais
eficaz (SILBERSCHATZ et al. 1999).
2.2.5 - PROJETO LÓGICO DE BANCO DE DADOS
O Modelo Entidade Relacionamento, assim como ocorre com o modelo de classes na
OO, é conveniente para demonstrar um projeto de banco de dados de alto nível, com o
esquema da base dados (SILBERSCHATZ et al., 1999).
2.3 - QUEBRA DE PARADIGMAS: OO x RELACIONAL
Conforme explanado na Introdução, existe uma quebra de paradigmas entre o
desenvolvimento OO e a persistência de dados em bancos relacionais, o que obriga os
desenvolvedores a lançarem mão de técnicas para mapeamento entre os dois mundos no
desenvolvimento de software. Este mapeamento já foi mais “duro”, exigindo grande esforço,
antes do surgimento de frameworks:
24
● Hibernate - Para a linguagem de programação JAVA (http://www.hibernate.org/).
● Django
-
Framework
de
desenvolvimento
web
escrito
em
Python
(https://www.djangoproject.com/).
● OJB - Para a linguagem de programação JAVA (https://db.apache.org/ojb/).
● Doctrine - Para a linguagem de programação PHP (http://www.doctrine-project.org/).
● Active
Record
-
Para
a
linguagem
de
programação
Ruby
on
Rails
(http://guides.rubyonrails.org/active_record_basics.html).
A quebra entre esses paradigmas se expressa em diferenças entre os modelos, como:
-
O paradigma OO utiliza como entidade uma classe de Objetos, que armazena
atributos e define ações/comportamentos/métodos, ao passo que os Bancos
Relacionais apenas armazenam dados em suas Tabelas; com isso, a modularidade e o
Reuso são facilitados na OO;
-
O modelo relacional trabalha com o conceito de chave primária ou atributo de valor
único que identifica o registro (pessoa ou coisa), ao passo que na OO os objetos são
automaticamente identificáveis pelo seu endereço de memória ou de armazenamento
(objetos têm identidade própria);
-
O modelo relacional trabalha com o conceito de chave estrangeira para relacionar os
registros, ao passo que na OO objetos referenciam uns aos outros, ou seja, um objeto
acessa o outro por meio de uma referência que permite o acesso aos seus métodos
públicos, que dão acesso aos seus atributos (princípio do encapsulamento);
-
Objetos colaboram, ou seja, chamam métodos uns dos outros para realizar uma tarefa;
-
A OO trabalha com o conceito de herança e reutilização de atributos e métodos,
enquanto o modelo relacional não tem este conceito, o qual pode ser “simulado” com
o uso da estrutura de generalização/especialização;
-
Na OO pode haver relacionamento N x N, ou seja, um objeto pode referenciar uma
coleção de outros, enquanto no modelo relacional cada atributo deve ter valor único
(primeira forma normal).
2.3.1 - MAPEAMENTO ENTRE MODELOS: ORIENTADO A OBJETOS RELACIONAL
Segundo Uchôa (2004), em virtude da incapacidade de se guardar e recuperar os
objetos de forma direta em um banco de dados relacional, tornasse necessária a utilização de
um mapeamento para favorecer esse processo. Em primeiro momento no mapeamento, cada
25
Classe deve ser diretamente mapeada para uma Tabela. Além disso, deve-se ter em mente a
identidade dos objetos, pois dessa forma diferenciaremos os objetos uns dos outros. Assim, o
primeiro passo para este caso é acrescentar nas Tabelas, originadas a partir das Classes, um
atributo identificador para os objetos ou Object Identifier (OID). Seguindo no mapeamento,
atributos simples são mapeados para campos na tabela que vai ser criada. Já os atributos que
representam coleções de dados ou objetos devem ser decompostos, pois o modelo relacional
não permite atributos multivalorados, os quais devem ser mapeados para estruturas de dados
ou novas tabelas. Nesta nova tabela, a chave primária vai ser formada pela chave primária da
tabela que representa a classe do atributo multivalorado com o acréscimo de um OID para a
tabela que vai representar o próprio atributo multivalorado (chave surrogate).
Quanto ao mapeamento da herança, este apresenta três possibilidades (HOPPEN,
DILL, 2005; Uchôa, 2004): as subclasses são mapeadas para tabelas e copiam os dados da
superclasse, o que acaba por gerar redundância de dados nas tabelas criadas; a segunda
possibilidade é a criação de uma única tabela para toda a hierarquia, o que requer o acréscimo
de um campo com intuito de identificar a qual subclasse o registro vem a pertencer, tendo a
vantagem de criação de poucas tabelas e de se evitar o uso de junções, mas acaba por deixar
campos em branco dependendo do tipo de registro a ser inserido (ex: Pessoa pode ser um
Funcionário ou Empregador); por fim, a opção que mais naturalmente se aproxima do
paradigma OO é o mapeamento de cada classe da hierarquia para uma tabela do banco de
dados, o que, por outro lado, gera o problema de necessidade de inserção em mais de uma
tabela para inserir o mesmo registro, que ficará particionado entre a tabela que representa a
superclasse e aquela que representa a subclasse (ex: dados de um Funcionário que é uma
Pessoa). Esta última solução permite acrescentar tabelas para cada nova subclasse gerada,
realizando-se a junção por meio da chave estrangeira que representa a subclasse e que
apontará para a chave primária da tabela que representa a superclasse. Na realidade, não
existe solução ideal, devendo sempre ser avaliado o custo x benefício de cada solução
adotada.
Em relação ao mapeamento de métodos, que não podem ser implementados no banco
relacional, há a necessidade de se implementar gatilhos e procedimentos armazenados para
manipular e consultar o banco ou a necessidade de implementação dos procedimentos no
código do programa e no banco de dados, reduzindo o poder de modularidade proporcionado
pelo paradigma OO.
Referente a associação entre as classes, temos a associação 1 para 1, associação 0..1
para 1 a mais tranquila de ser implementada, a mesma pode ser mapeada para uma tabela ou
26
para duas tabelas diferentes, onde em cada uma das formas possuem vantagens e
desvantagens. Mapeando para uma única tabela, temos que incluir os campos da classe
associada na classe associadora, incluindo um prefixo para realizar o seu reconhecimento, de
contra partida ao se mapear para duas tabelas diferentes podemos incluir um atributo em uma
das tabelas, assim esse será a chave estrangeira, direcionando assim para a outra tabela.
Dando continuidade as associações, temos a associação 1 para muitos, nessa associação
devemos adicionar um novo atributo na classe cardinalidade muitos, que será a chave
estrangeira para a tabela com cardinalidade 1 e por último, temos a associação muitos para
muitos, que cria uma nova tabela, que receberá dois campos, esses que serão chaves
estrangeiras de ambas duas tabelas da relação, e unidos vão fazer parte da chave primária
desta nova tabela. Confira um exemplo de mapeamento na Figura 6.
Figura 6 - Exemplo de Mapeamento.
27
2.3.2 – BANCO DE DADOS ORIENTADO A OBJETOS
O Banco de Dados Orientado a Objetos tem como característica principal armazenar
as informações na forma de objetos e esses podem ser trabalhados através dos métodos
definidos pela classe na qual está esse determinado objeto. Geralmente existem dois fatores
que levam a escolha da utilização desse banco de dados: a primeira é que se torna complexo o
trabalho de dados complexos no modelo relacional, principalmente pelo fato do modelo
relacional não traduzir diretamente o conceito de objeto, com suas propriedades e métodos, o
qual pode conter dados complexos como coleções; e a segunda é que as aplicações são
construídas no paradigma de orientação a objetos, e, quando não se usa um banco OO, há a
necessidade de se traduzir o código para uma linguagem que o modelo do banco entenda,
tornando a tarefa tediosa, além da perda do tempo que foi empregada nessa tradução do
modelo. Quando o banco segue o mesmo paradigma da linguagem de programação, a
passagem do código para o banco e vice versa é natural. Mesmo havendo frameworks que
contribuem para esta migração, a aplicação fica dependente desses frameworks e alguma
perda de eficácia acaba sendo observada. Além do fato dos frameworks darem transparência
ao mapeamento, não permitindo, na maioria dos casos, interferência do usuário para escolher
as melhores opções de modelagem que solucionem o seu problema (Galante et al., 2007)..
Com o crescimento do paradigma da orientação a objetos, o modelo Orientado a
Objetos vem ganhando mercado. Como banco de dados espaciais, na área de
telecomunicações, e nas área científicas como física de alta energia e biologia molecular, ele
vem ganhando espaço devido à possibilidade de aumento de produtividade, segurança e por
sua fácil manutenção. Como objetos são articulados, as mudanças podem ser realizadas
internamente, não afetando as demais partes do sistema, mesmo assim o Banco de Dados
Orientado a Objetos não teve grande impacto em áreas comerciais, embora tenha sido
aplicado em algumas. Uma das características que chama atenção é que o acesso dos dados
pode ser bem mais rápido que os bancos já utilizados, porque não é necessário junções, já que
nele o acesso pode ser feito direto ao objeto por intermédio de ponteiros (Galante et al.,
2007).
Os dois tipos de bancos de dados apresentam uma série de vantagens e desvantagens,
por exemplo, o orientado a objetos utiliza interface de navegação ao invés de utilizar as
convencionais e esse acesso é muito eficiente, o mesmo é implementado por ponteiros, a
desvantagem seria a inconsistência do modelo em trabalhar com outras ferramentas como
OLAP, com backups e padrões de recuperação de dados. Quanto ao relacional ele tem como
28
vantagem ser fortemente baseado em fundamentos matemáticos o que vem facilitar a
elaboração de consultas diversificadas, envolvendo operações como união, interseção, junção
etc. A dificuldade de implementar o encapsulamento é uma desvantagem do relacional
(Galante et al., 2007), sendo que essa desvantagem é trabalhada no mesmo pelo padrão de
projeto DAO (Data Access Object), o mesmo abstrai e encapsula os mecanismos de acesso a
dados
escondendo
os
detalhes
da
execução
da
origem
dos
dados.
(http://www.macoratti.net/11/10/pp_dao1.htm).
Existem vários bancos de dados orientados a objetos no mercado, dentre eles o
CACHÉ, o VERSANT, DB4Objects, O2, GEMSTONE, JASMINE, MATISSE, Objectivity e
o Ozone (Galante et al., 2007).
2.3.3 – COMPARANDO BANCO DE DADOS ORIENTADO A OBJETOS COM
BANCO DE DADOS RELACIONAL
Devido aos problemas abordados anteriormente sobre Banco de Dados Orientados a
Objetos e Bancos de Dados Relacionais, surgiu para agregar as vantagens da orientação a
objetos o Banco de Dados Objeto Relacional. A forma de armazenamento em Banco de
Dados Orientado Objetos quanto no Banco de Dados Objeto Relacional se mostra muito fácil
de fazer, uma vez que ambos os bancos oferecem suporte para dados complexos, tendo como
principal vantagem manipular dados complexos, persistentes e ao mesmo tempo manter a
facilidade de uso dos métodos de consulta o Banco de Dados Objeto Relacional se mostra
mais completo.
O Banco de Dados Orientado a Objetos possui representação de objetos complexos,
sendo assim extensível, oferece suporte para ocultação de informações e herança, o Banco de
Dados Objeto Relacional, além das características citadas anteriormente, possui uma
otimização de consulta muito mais simples e não perde tanto desempenho como o Banco de
Dados Orientado a Objetos.
Os Bancos de Dados Orientados a Objetos são mais utilizados para aplicações de
pequena escala, já o Banco de Dados Objeto Relacional tem o objetivo de alcançar aplicações
de larga escala, área que é dominada atualmente pelo Banco de Dados Relacional (Pinheiro et
al., 2009).
29
2.4 – CRITÉRIOS DE AVALIAÇÃO
Avaliamos toda a parte de análise, projeto e implementação, com o intuito de verificar
a facilidade de utilização e a agilidade de trabalho com os dois bancos. Realizamos essa
avaliação analisando tudo que foi feito desde o começo, nas três etapas citadas anteriormente
e apresentaremos na conclusão, os resultados. O mesmo foi realizado no tempo de
desenvolvimento dos acessos e de todo o projeto, foi realizada a implementação e verificado
qual dos dois gasta menos tempo nessas fases e é importante citar que só possui avaliar esses
critérios combinando-se a avaliação dos protótipos e o estudo da literatura relacionada na
área de banco de dados.
A eficiência, a eficácia, maturidade, estabilidade, confiabilidade e a manutenibilidade,
foram avaliadas com os dados e com a experiência que obtivemos com a pesquisa que
embasou nosso projeto e com a implementação do protótipo.
Todos os testes foram realizados tendo como embasamento teórico a definição das palavras
citadas e seu significado na área de desenvolvimento.
·
Eficiência – significa realizar um trabalho correto, sem muitos erros, consiste em
fazer
certo
as
coisas.
(http://www.infoescola.com/administracao_/eficiencia-e-
eficacia/)
·
Eficácia – significa realizar um trabalho que atinja totalmente o resultado, concluindo
o que se propôs a fazer com um bom almejo do resultado, consiste em fazer as coisas
certas. (http://www.infoescola.com/administracao_/eficiencia-e-eficacia/)
·
Maturidade – Momento do que se encontra no último estágio do desenvolvimento.
(http://www.dicio.com.br/maturidade/).
·
Estabilidade – Solidez e segurança; qualidade daquilo que é estável, está associada à
idéia
de
permanência
em
um
determinado
estado.
(http://www.dicio.com.br/estabilidade/).
·
Confiabilidade – grau de confiança de algo é a capacidade de algo, não variar em seus
resultados, é a capacidade de um sistema, de realizar e manter seu funcionamento em
circunstâncias de rotina, bem como em circunstâncias hostis e inesperadas
(http://www.dicio.com.br/confiabilidade/).
·
Manutenibilidade – característica inerente a um projeto de sistema ou produto, e se
refere à facilidade, precisão, segurança e economia na execução de ações de
30
manutenção nesse sistema ou produto (BLANCHARD, Benjamin. Logistics
engineering and management. 4th ed. Englewwod Cliffs: Prentice Hall, 1992).
31
3 - COMPARAÇÃO DOS BANCOS DE DADOS NA PRÁTICA POR MEIO DE
MODELO ACADÊMICO
Para fins conclusivos e comparativos, surgiu então a necessidade de se desenvolver
um protótipo de modelo de banco de dados, a fim de ser implantado nos dois tipos de bancos
em estudo, aplicando parte da teoria e dos paradigmas descritos anteriormente. O domínio
selecionado para o desenvolvimento do protótipo foi o escolar, tendo uma versão da
modelagem no paradigma relacional (DER – Diagrama Entidade-Relacionamento) e uma
versão no paradigma de Orientação a Objetos (Diagrama de Classes).
O Sistema Gerenciador de Banco de Dados (SGBD) Relacional escolhido foi o
MySQL e o Gerenciador de Banco de Dados OO selecionado foi o DB4Objects, conforme
será visto no decorrer deste capítulo. O objetivo do desenvolvimento do protótipo e seu uso
em cada SGBD é obtermos indícios de sua eficiência, eficácia e efetividade diante dos
desafios que a tecnologia nos oferece.
3.1 - ESTUDO DE CASO
O Estudo de Caso simulará de forma simplificada o funcionamento, organização e
interpretação de dados de uma faculdade que busca se informatizar, a mesma é constituída de
alunos e professores, cada aluno deve ser apenas matriculado em um curso da faculdade e
fazer parte de uma turma, os professores lecionam aulas em várias turmas e um aluno está
cadastrado em várias disciplinas no curso por semestre, o aluno tem em seu histórico todo o
resultado das disciplinas no qual já estudou.
Visando traduzir esses requisitos, foi elaborado o seguinte modelo de classes,
apresentado na Figura 7 a seguir:
32
Figura 7 – Diagrama de Classes.
Como estamos lidando também com banco de dados relacional, foi necessário efetuar
o mapeamento dessas classes para tabelas, conforme diagrama na Figura 8 a seguir:
33
Figura 8 - Mapeamento do Diagrama de Classe.
34
3.2 - TECNOLOGIAS APLICADAS
Para que os protótipos fossem elaborados, parte da estratégia de seu desenvolvimento
foi definir quais tecnologias seriam aplicadas durante o ciclo de desenvolvimento do mesmo,
conforme segue.
Inicialmente foi definido um sistema operacional que foi o Ubuntu 12.04
(http://www.ubuntu.com), sua escolha deve-se principalmente a ser uma das versões mais
estáveis (se não a mais a estável) do Ubuntu atualmente e o fato de ser um sistema livre e
gratuito. Nele foi instalado o Java que foi a linguagem escolhida para a codificação e
desenvolvimento do protótipo. Sua escolha deve-se principalmente pela facilidade que se tem
em encontrar e aprender técnicas que são aplicadas durante o ciclo de desenvolvimento, bem
como bibliotecas para a sua integração com outros sistemas ou plataformas. Além disso, foi
instalado o Eclipse Juno (https://eclipse.org) que dá suporte ao ambiente de desenvolvimento.
Por fim, foram instalados os dois Sistemas Gerenciadores de Bancos de Dados (SGBDs)
avaliados nesses protótipos que são o MySQL (MySQL) e o Db4Object (DB4Object).
Assim como o Java, esses bancos de dados foram escolhidos devido à sua grande
popularidade em suas áreas (relacional e orientada a objetos), além da fácil instalação,
configuração e integração de cada um deles com o Java.
Como um ciclo clássico de desenvolvimento, após ser desenvolvido o diagrama de
classes, foi realizado o mapeamento para o modelo relacional e a instalação dos SGBDs. A
seguir, iniciou-se então a etapa de configuração, por meio de um driver¹ que permite criar
uma conexão na qual possamos transmitir dados a serem persistidos pelo BD desejado.
3.2.1 - O BANCO DE DADOS RELACIONAL MySQL
O MySQL é um banco de dados de código aberto muito popular que possibilita a
entrega econômica de aplicativos de banco de dados confiáveis na web e incorporados.
Possui boa escalabilidade e desempenho e atende às necessidades dos serviços web que
possuem mais tráfego, reduzindo os custos totais e os riscos.
O banco foi votado como “O melhor gerenciador de dados” no 2011 Impact Awards
(Awards, 2011), e votado como “O melhor banco de dados” pelo choice awards 2011 do
Linux Journal (Linux Journal, 2011). Foi também nomeado um dos 10 melhores produtos de
código aberto de 2011 pela CRN, nomeado um dos 10 melhores no hall da fama dos códigos
abertos do InfoWorld. As principais propriedades da web são escaláveis com êxito no
35
MySQL e empresas modernas nos setores de telecomunicações e web implantam o MySQL
em suas aplicações (Oracle, 2015). Em função dessas características mencionadas, o MySQL
foi escolhido como o exemplo de banco de dados relacional para o nosso trabalho (Oracle,
2015).
3.2.2 - DB4Object
O DB4Object é um banco de dados orientado a objetos, de código aberto, que trata
objetos de forma nativa como base de dados. Nele não existem tabelas, linhas ou colunas,
existem só objetos, onde uma entidade ou tabela pode ser interpretada como sendo o escopo
do objeto ou seja, a sua classe e as linhas e colunas são os próprios objetos, eliminando assim
a complexidade extra e a perda de desempenho com a conversão para outros formatos ou com
mapeamento. Ele não usa a linguagem SQL, o mesmo utiliza uma outra tecnologia chamada
de Native Query para tratar seus objetos e replicação orientada a objetos, aumentando assim
sua performance e os ganhos de desempenho de linguagens orientadas a objeto como o JAVA
e as linguagens da plataforma .NET. Os objetos são persistidos em um arquivo com extensão
.yap que identifica um arquivo DB4Object. A conexão com o banco é feita com a abertura
desse arquivo. Com a utilização do DB4Object podemos criar aplicações cliente-servidor,
desktop e aplicações embarcadas.
As
informações
acima
foram
retiradas
do
site
(http://www.macoratti.net/09/08/net_db4o.htm).
3.2.3 - EXEMPLO PRÁTICO: CONFIGURANDO OS SGBDS PARA USO
As diferenças entre os Paradigmas afetam inclusive a forma como os bancos de dados
são configurados. Primeiramente falaremos do banco de dados relacional.
Neste exemplo, estamos usando o Mysql, o banco de dados é criado de maneira
clássica, via linha de comandos no terminal, e, a seguir é necessário baixar um driver que
estabeleça a comunicação entre a aplicação e este banco de dados e assim se faz a conexão,
eis a imagem da configuração no trecho a seguir:
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.PreparedStatement;
36
import java.sql.ResultSet;
import java.sql.SQLException;
import java.util.ArrayList;
import classes.Aluno;
import classes.Curso;
import classes.Turma;
public class AlunoDAO {
private Connection conexao;
private PreparedStatement stm;
private String url = "jdbc:mysql://localhost/escola";
private String usuario = "root";
private String senha = "root";
Neste trecho vemos a biblioteca importada, o usuário e senha do BD relacional e o
caminho aonde ele se encontra (link).
Já a configuração do SGBDOO é completamente diferente tanto no conceito quanto
na sua criação, a forma como lidamos muito se difere do modo relacional clássico. Não é, por
exemplo, necessário criar um banco de dados e muito menos configurá-lo para que ocorra
uma comunicação entre o BD e a aplicação. O BD simplesmente complementa o sistema de
forma que todas suas funções fiquem disponíveis direto no nível da configuração.
Para que possa ser configurado é necessário primeiramente importar a biblioteca do
DB4O para o sistema em Java. Feito isso, temos acesso a todos os métodos presentes no
Banco de Dados, assim como suas funções fundamentais, como dito acima o BDOO faz parte
do sistema de forma direta sem precisa de configuração ou driver 1para fazer comunicação
mas sim apenas uma biblioteca com suas funções, lembrando que praticamente todos já estão
presentes no Java, ele funciona na máquina virtual do java em nível de aplicação.
Diferentemente dos modelos relacionais, o BDOO fica salvo em arquivos, cada classe
tem um arquivo e este arquivo contém os dados criptografados da classe. Assim que invoco o
comando de salvar um objeto, ele abre o arquivo da classe referente e insere o objeto a ser
1
Driver: Arquivo que contém as funções a serem integradas a um sistema operacional para
controlar um determinado periférico.
37
salvo, exemplo: pessoa tem n carros. O SGBD procura na pasta referente o arquivo 'pessoa',
caso ele não encontre esse arquivo, automaticamente ele gera um arquivo referente a classe
pessoa, contendo o objeto em si com todas suas propriedades.
Aproveitando este caso, podemos notar também que ele salva não só objetos da
classe, mas também outros tipos de objeto, no exemplo acima, pessoa tem uma lista de carro,
todo esse array de objetos é salvo, isso também facilita muito em buscas de conteúdos,
varrendo interligações de classes. Esta característica é interessante, porém perigosa, pois não
há correlação direta entre os arquivos, ou seja, se eu quiser atualizar um carro no array que a
pessoa tem eu devo me ater ao fato de devo buscar este mesmo objeto no arquivo de carros e
atualizá-lo de forma independente. Ou seja o DB4O é agiu em buscas mas frágil em
correlação de dados, deixando inclusive o programador atendo quando for fazer atualizações
com chaves estrangeiras.
Os BD's ficam salvos em arquivos criptografados em um caminho determinado assim
que o método de abertura é invocado. Cada arquivo corresponderá a uma classe, sendo
possível configurar também login e senha além de conexão web. A seguir, uma imagem do
método que 'abre' o BD com os objetos dessa classe, caso nesse caminho ele não encontre
nenhum arquivo ele cria um.
ObjectContainer db4 = Db4o.openFile("\TCC\dados\professores");
3.2.4 - IMPLEMENTANDO O ACESSO AOS BANCOS
A grande diferença entre os SGBDs, na prática, se vê na facilidade da programação.
Enquanto isso no modo tradicional, muito se gasta em codificação, com comandos simples
isso se resolve no BDOO, os exemplos são claros, começando pelo conceito. No modelo
relacional surge a necessidade de criar classes de persistências, onde estão os métodos com os
comandos, na conexão com a configuração do mapeamento, então, para cada classe teremos
uma classe de persistência que faz o mapeamento entre o OO e o relacional, neste caso, como
não há mapeamento e o que é salvo é um objeto direto, os métodos de inserção dele são
atualizados, e as buscas estão incorporadas diretamente na classe.
Pegamos a classe Disciplina como exemplo, para que ocorra comunicação com o
SGBD Relacional e o sistema, foi criada uma classe que estabeleça uma comunicação, essa
classe foi chamada DisciplinaDAO, nesta classe são configurados todos os métodos CRUD e
a consulta além de estabelecer a comunicação com o MySQL.
38
Declarando informações necessárias para subir no início da classe:
public class DisciplinaDAO {
private Connection conexao;
private PreparedStatement stm;
private String url = "jdbc:mysql://localhost/escola";
private String usuario = "root";
private String senha = "root";
Inserção no modelo Relacional:
public void CadastrarDisciplina(Disciplina d) throws SQLException {
conexao = DriverManager.getConnection(url, usuario, senha);
String sql = "insert into Disciplina(uidDisciplina, sigladisc, nomedisc, ementa,
cargoHoraria) values (?, ?, ?, ?, ?)";
stm = conexao.prepareStatement(sql);
stm.setInt(1, d.getUidDisciplina());
stm.setString(2, d.getSiglaDisc());
stm.setString(3, d.getNomeDisc());
stm.setString(4, d.getEmenta());
stm.setDouble(5, 2343);
stm.execute();
conexao.close();
}
Como podemos ver neste método, cada atributo na classe é passado manualmente
para cada campo em uma classe com muitos atributos, gerando um grande trabalho para
desenvolver este método. Para retornar os dados em uma consulta seria necessário a operação
inversa:
public ArrayList<Disciplina> todasDiscplinas() throws SQLException {
conexao = DriverManager.getConnection(url, usuario, senha);
String sql = "select * from Disciplina";
stm = conexao.prepareStatement(sql);
ResultSet resultado = stm.executeQuery();
39
ArrayList<Disciplina> disciplinas = new ArrayList<Disciplina>();
while (resultado.next()) {
Disciplina d = new
Disciplina(resultado.getInt("uidDisciplina"),resultado.getString("sigladisc"),resultado.getStri
ng("nomedisc"),resultado.getString("cargoHoraria"), resultado.getString("nomedisc"));
disciplinas.add(d);
}
return disciplinas;
No modelo orientado a objeto, o processo de inserção se resume a uma linha, e a de
conexão se resume na instância, o arquivo em questão é configurando quando aberto e com
um simples comando (store) o objeto é salvo;
public void inserirDisciplina(Disciplina a){
ObjectContainer db4 = Db4o.openFile(".\Dados\Disciplinas");
try {
db4.store(a);
}finally {
db4.close();
}
Para fazer consulta, o método é ainda mais simples;
public ObjectSet<Disciplina> BuscarDisciplina(Disciplina a){
ObjectContainer db4 = Db4o.openFile("Disciplinas");
ObjectSet<Disciplina> aaa;
try {
aaa = db4.queryByExample(a);
} finally {
db4.close();
}
return aaa;
40
Além disso, os métodos podem ser criados na própria classe em questão, nesse caso
de Disciplina, sem precisar desenvolver um mapeamento para o mesmo. Isto auxilia muito no
tempo desenvolvimento e programação.
Outro fator interessante foi há não necessidade de ID, além de ter a flexibilidade em
consulta personalizadas. Conforme exemplo abaixo:
public void MediadeAlunoPorDisciplina(ResultadoAluno r){
ObjectContainer db2 = Db4o.openFile("ResultadoAlunos");
ObjectSet<ResultadoAluno> lista;
int somador = 0, count = 0;
try {
lista = db2.queryByExample(r);
}finally {
db2.close();
}
System.out.println("Média dos Alunos da Disciplina: " + "\n");
while (lista.hasNext()){
System.out.println("Nome: " + lista.next().getAluno().getNome()+ " Nota " +
lista.next().getMedia()+ "\n");
somador+= lista.next().getMedia();
count++;
}
System.out.println("A média geral da disciplina é:" + (somador/count));
}
Neste exemplo podemos notar que o resultado da busca no BD é uma lista, e nesta
lista eu posso pesquisar através dos métodos e acessar dados necessários, por exemplo: um
dono tem uma lista de carro e carro tem um dono, no conceito orientado a objeto eu consigo
acessar tanto o carro pela lista e o dono pelo carro, tudo feito através de instâncias e
associações.
Utilizamos na nossa implementação o padrão DAO, o mesmo permite criar as classes
de dados independentemente da fonte de dados ser um BD relacional, um arquivo texto, um
arquivo XML, etc. Para isso, ele encapsula os mecanismos de acesso a dados e cria uma
41
interface de cliente genérica para fazer o acesso aos dados permitindo que os mecanismos de
acesso a dados sejam alterados independentemente do código que utiliza os dados.
Existem diversas implementações do padrão DAO, utilizamos algumas em nosso
projeto, em geral podemos relacionar algumas características desejáveis em uma
implementação do padrão DAO:
·
Todo o acesso aos dados deve ser feita através das classes DAO de forma a se ter o
encapsulamento;
·
Cada instância da DAO é responsável por um objeto de domínio;
·
O DAO deve ser responsável pelas operações CRUD no domínio;
·
O DAO não deve ser responsável por transações , sessões ou conexões que devem ser
tratados fora do DAO;
3.2.5 – TESTANDO OS BANCOS
O mais importante de um banco de dados do ponto de vista técnico e comercial é seu
desempenho, isto é notório e fundamental para a sobrevivência de um SGBD. Talvez a
grande dúvida levantada nesta pesquisa é: o SGBDOO é mais eficiente, eficaz e efetivo que o
SGBD Relacional? Para chegamos a uma conclusão se tornou necessário efetuar testes nos
mesmos e analisar o desempenho de ambos. Vale lembrar que ambos estão rodando na
mesma máquina e no mesmo sistema e em suas execuções estará apenas o Eclipse em
funcionamento na máquina.
Foi efetuado o seguinte teste nos dois modelos de Sistema: inserção, atualização,
busca e exclusão, ambos para 100, 500 e 1000 funcionários com repetição de 3 vezes com a
finalidade de tirar um tempo médio dos 3 em milissegundos.
Inserção
Tabela 1 – Resultado dos Testes de Inserção Realizados no SGBDOO;
Total de
Teste 1
Teste 2
Teste 3
Media
3849
3612
4306
3922,3
Usuários
10 usuários
42
50 usuários
16525
25222
17708
19818,3
100 usuários
32692
39770
36036
36166
Tabela 2 - Resultado dos Testes de Inserção Realizados no Banco Relacional;
Total de
Teste 1
Teste 2
Teste 3
Media
10 usuários
1957
0902
924
1261
50 usuários
2141
2131
2031
2101
100 usuários
5436
4273
4484
4731
Usuários
Atualização:
Tabela 3 - Resultado dos Testes de Atualização Realizados no SGBDOO;
Total de
Teste 1
Teste 2
Teste 3
Media
10 usuários
4312
3321
3427
3686,6
50 usuários
18128
20021
17078
18409
100 usuários
33010
51584
33870
39488
Usuários
Tabela 4 - Resultado dos Testes de Atualização Realizados no Banco Relacional;
Total de
Teste 1
Teste 2
Teste 3
Media
10 usuários
510
422
545
492,3
50 usuários
2253
2198
2784
2411,6
100 usuários
5580
3891
3741
4404
Usuários
43
Consulta:
Tabela 5 - Resultado dos Testes de Consulta Realizados no SGBDOO;
Total de
Teste 1
Teste 2
Teste 3
Media
10 usuários
277
430
777
494,6
50 usuários
267
340
775
460,6
100 usuários
266
279
779
441,3
Usuários
Tabela 6 - Resultado dos Testes de Consulta Realizados no Banco Relacional;
Total de
Teste 1
Teste 2
Teste 3
Media
10 usuários
13
12
12
12,3
50 usuários
94
23
180
99
100 usuários
84
32
100
72
Usuários
Exclusão:
Tabela 7 - Resultado dos Testes de Exclusão Realizados no SGBDOO;
Total de
Teste 1
Teste 2
Teste 3
Media
10 usuários
4365
7240
3094
4899,6
50 usuários
15279
18218
14391
15962,6
100 usuários
32465
54938
33180
40194,3
Usuários
Tabela 8 - Resultado dos Testes de Exclusão Realizados no Banco Relacional;
Total de
Usuários
Teste 1
Teste 2
Teste 3
Media
44
10 usuários
489
435
471
465
50 usuários
2793
1967
1756
2172
100 usuários
4389
3900
4484
4257,7
Tabela 9 - Resultado Final dos Testes Realizados Anteriormente nos Bancos;
Técnica aplicada
SGBDOO
SGBD Relacional
Inserção com 10 dados
X
Inserção com 50 dados
X
Inserção com 100 dados
X
Atualização com 10 dados
X
Atualização com 50 dados
X
Atualização com 100 dados
X
Busca com 10 dados
X
Busca com 50 dados
X
Busca com 100 dados
X
Exclusão com 10 dados
X
Exclusão com 50 dados
X
Exclusão com 100 dados
X
Derrota do sistema OO teria explicação? A Tabela 9 mostra através das marcações
realizadas, qual banco se saiu melhor nos testes de Inserção, Atualização, Busca e Exclusão.
Talvez sim, neste modelo feito por nós foi decidido que os métodos de inserção, atualização,
busca e exclusão faria parte da classe, ou seja para cada valor inserido um novo objeto devia
ser instanciado, isto atrapalhou principalmente na ocupação de memória e processamento de
dados, porém, a respeito deste paradigma, o banco de dados se mostrou muito eficiente sendo
instanciado diretamente da execução sem ser agregado a método de nenhuma classe.
45
3.3 – ANÁLISE DOS RESULTADOS
Após a parte da pesquisa bibliográfica, começamos a criar os modelos, para construir
os protótipos, a fim de realizar testes mais conclusivos, referentes a comparação entre os
bancos.
Logo que iniciamos, nos deparamos com as diferenças e a quebra de paradigma
apresentada pelo modelo relacional. Ao criar os modelos, visualizamos que, para o Banco de
Dados Orientado a Objetos, o modelo foi extraído diretamente do código criado, ao passo que
no Banco de Dados Relacional, tivemos que utilizar um framework para realizar o
mapeamento objeto relacional. Assim, só depois de realizar esse mapeamento, tendo esse
trabalho a mais, foi possível iniciar o trabalho de manipulação do banco. Foi possível então
perceber que o gasto de tempo que aconteceu nesse mapeamento, já é uma desvantagem da
utilização do Banco Relacional com o desenvolvimento no paradigma OO. Além desse
problema, poderíamos vir a enfrentar outro, se o framework não funcionasse corretamente,
tendo assim a necessidade de baixar e instalar um novo e realizar o mapeamento novamente,
perdendo ainda mais tempo nessa parte de criação do modelo.
Pensando em cenários de manutenção e evolução do sistema, uma vez que o modelo
de análise e projeto, o código e o banco de dados são Orientados a Objetos, basta se alterar
um deles para que o raciocínio da alteração do restante seja direto. Além disso, a alteração do
código já se reflete na alteração do banco, o que não ocorre quando há a utilização de dois
paradigmas: OO e Relacional.
Com os modelos prontos, começamos a criar os protótipos. Utilizando JAVA como
linguagem de programação, o MySQL como Banco de Dados Relacional e o DB4Object
como Banco de Dados Orientado a Objetos. Neste momento do projeto, nos deparamos com
outros pontos. Um deles, ao programar a construção do modelo proposto, o DB4Object
espelha tudo que foi programado para o banco, de imediato, criando tudo de forma mais
rápida, pois o mesmo, como na orientação a objetos, trata os dados como objetos do mundo
real. Já no Banco de Dados Relacional, começamos programando em orientação a objetos,
depois criamos todo o banco no MySQL, depois de todo esse trabalho, que ocupou muito
mais tempo do que no modelo anterior já apresentado, tivemos que configurar a conexão
entre as duas partes por meio de um driver para o modelo relacional.
Em relação ao desempenho dos SGBDs, com o volume de dados inserido, não foi
possível perceber diferença significativa.
46
Ao nos depararmos com todas essas diferenças, nos perguntamos, por que os Bancos
de Dados Orientados a Objetos ainda não emplacaram? Um dos pontos que pensamos, foi a
mão de obra qualificada para trabalhar de forma segura, com qualidade e retirando o melhor
desses bancos. No decorrer do nosso curso superior, em nenhum momento vimos ou
aprendemos a trabalhar com esse tipo de banco, só tivemos contato com ele através do nosso
trabalho de conclusão de curso. Do começo ao fim do curso, todas as matérias que utilizavam
banco de dados, só focaram nos bancos de dados relacionais. Acreditamos que uma forma de
inibir essa quebra de paradigma apresentada, é começar desde a formação, inserindo esse
pensamento de programar orientado a objetos para bancos orientados a objetos.
Outro ponto que encontramos em nossas pesquisas é o receio das grandes empresas de
passar todos os dados de um banco de dados relacional (Coluna do Estagiário Celepariano:
Sistemas de gerenciamento de banco de dados orientado a objetos), que já está funcionando
de forma correta e servindo bem aos seus objetivos, para um banco de dados orientado a
objetos, que quase nenhuma grande empresa utiliza ainda e que não possui uma mão de obra
qualificada e especializada. Os bancos relacionais são estáveis, maduros e apresentam boa
escalabilidade para grandes volumes de dados. Dessa forma, as empresas ficam receosas com
a migração.
Acreditamos que os relacionais então ainda estejam ganhando mercado, por serem os
mais utilizados há muito mais tempo pelas grandes empresas, terem maturidade e segurança
maior.
A primeira grande diferença percebida é que no BDOO ocorre uma total integração
com a linguagem de programação Java, sua instalação é simples. Basta baixar a biblioteca,
importar para seu projeto e codificar de acordo com sua necessidade, que ele já lhe fornece
todo um conjunto de classes implementadas, no qual precisamos apenas chamar os métodos
que atenderão nossas necessidades. Tal dinâmica é muito diferente da maneira que
persistimos dados atualmente.
4 - CONCLUSÃO
4.1 - CONTRIBUIÇÕES
Com a realização da pesquisa, utilizando como fonte de conhecimento, a literatura
científica composta por artigos e livros e materiais com foco na área de Banco de Dados e
47
seguindo a linha de pensamento e as questões levantadas neste projeto, chegamos as
seguintes conclusões:
·
Foi possível identificar que o Banco de Dados Relacional, por ser mais antigo e mais
utilizado, possui vantagens quanto à sua estabilidade e maturidade, não perdendo
desempenho quando utilizado em larga escala;
·
O Banco de Dados Relacional já possui grande confiabilidade por parte das empresas
devido ao seu tempo em uso;
·
O Banco de Dados Orientado a Objetos é melhor quanto à eficiência e eficácia e
manutenibilidade, sendo mais naturalmente mapeado para o código, e, sendo possível,
dessa forma, se realizar modificações sem mexer na estrutura do sistema;
·
O Banco de Dados OO permite melhor reaproveitamento de código, baixo custo e
esforço com relação à realização de mapeamento, refletindo o mundo real, além de
permitir o armazenamento de coleções e dados complexos.
·
O Banco de Dados OO não usa SQL, não aproveitando assim toda uma cultura já
existente dentro desse padrão de linguagem de consulta e manipulação de dados.
·
A migração dos dados dos Bancos de Dados Relacionais para o Banco de Dados OO é
mais difícil de ser realizada, do que de um Banco Relacional para outro, devido a sua
não padronização e falta de mão de obra qualificada na área.
·
Mão de obra qualificada na área da OO é muito escassa, um dos pontos que faz com
que isso aconteça, é o fato de cada Banco de Dados OO ter seus próprios comandos e
cultura e isso causa ainda mais receio nas empresas de realizar essa migração.
4.2 - LIMITAÇÕES
No decorrer do projeto nos deparamos com a limitação de não poder comprovar a
utilização do Banco Orientado a Objetos em grandes empresas, podendo avaliar seu
desempenho com grande volume de dados. Não foi possível encontrar nenhum artigo ou
projeto que abordasse esse assunto e não conseguiríamos realizar essa pesquisa somente
através de protótipos, que não são capazes de refletir os milhares de dados das grandes
empresas.
Além dessa, nos deparamos com a dificuldade de encontrar site brasileiro que abordasse o
assunto de Banco de Dados Orientado a Objetos, sendo assim, toda a pesquisa relacionada ao
Banco utilizado foi realizada a partir de artigos e pesquisa em sites estrangeiros.
48
4.3 – TRABALHOS FUTUROS
Alguns pontos de pesquisa para trabalhos futuros foram identificados ao longo da
pesquisa e da confecção do projeto, podendo ser abordados em trabalhos futuros, como se
segue:
·
Pesquisa e confecção de um projeto de Banco de Dados Orientado a Objetos voltados
para a escalabilidade do mesmo, com inserção de grande quantidade de dados para
assim, verificar suas reais limitações;
·
Pesquisa relacionada à mão de obra qualificada na área, com relação a uma possível
migração de Bancos de Dados Relacionais de grandes empresas para Bancos de
Dados Orientados a Objetos.
·
Ampliar os estudos comparativos incluindo o Banco de Dados Relacional-Objeto.
5 - REFERÊNCIAS
● DATE, C. J. Introdução a Sistemas de Bancos de Dados, Editora Campus 1990.
● SILBERSCHATZ, A. Sistemas de Bancos de Dados, Makron Books 1999.
● DATE, C.J. Introdução a Sistemas de Bancos de Dados, Editora Campus, 2003.
● FARINELLI, F. Conceitos Básicos de Programação Orientada a Objetos 2007.
●
HOPPEN, M. M., DILL, S. L. Compatibilização do Paradigma Relacional com o
Paradigma Orientado a Objetos 2005.
● GALANTE, A. C., MOREIRA, E. L. R., BRANDÃO, F. C. Banco de Dados
Orientado a Objetos: Uma Realidade 2007.
● MACÁRIO, C. G. N., BALDO, S. M. O Modelo Relacional 2007.
● PINHEIRO, D. R. S., SOUZA, D. S., VASCONCELOS, R. O., SILVA, F. S.
Comparativo entre Banco de Dados Orientado a Objetos e Banco de Dados
Objeto Relacional 2009.
49
● MySQL. <http://www.oracle.com/>Acesso 16/12/15.
● DB4Object. <http://www.macoratti.net/09/08/net_db4o.htm> Acesso 16/12/15.
● UCHÔA E. M. A., Compatibilizando Paradigmas: Projetando Objetos,
Implementando em Banco de Dados Relacional.
● MySQL. <https://www.phparch.com/2011/06/impact-award-winners/>, último
acesso em 18/12/2015.
● MySQL.
<http://www.linuxjournal.com/slideshow/readers-choice-
2011?page=22>, último acesso em 18/12/2015.
● MySQL. <http://www.oracle.com/br/products/mysql/index.html>, último acesso
em 18/12/2015.
● DB4Object. <http://www.macoratti.net/09/08/net_db4o.htm>, último acesso em
18/12/2015.
● Coluna do Estagiário Celepariano: Sistemas de gerenciamento de banco de
dados
orientado
a
objetos.
<http://www.batebyte.pr.gov.br/modules/conteudo/conteudo.php?conteudo=560
>, último acesso em 24/05/2016.
●
Eficiência.
<http://www.infoescola.com/administracao_/eficiencia-e-eficacia/>
Data de acesso: 02/06/2016.
●
Eficácia.
<http://www.infoescola.com/administracao_/eficiencia-e-eficacia/>
Data de Acesso: 02/06/2016.
●
Maturidade.
02/06/2016.
<http://www.dicio.com.br/maturidade/>
Data
de
Acesso:
50
●
Estabilidade.
<http://www.dicio.com.br/estabilidade/>
Data
de
Acesso:
02/06/2016.
●
Confiabilidade. <http://www.dicio.com.br/confiabilidade/> Data de Acesso:
02/06/2016.
●
BLANCHARD, Benjamin. Logistics engineering and management. 4th ed.
Englewwod Cliffs: Prentice Hall, 1992, Manutenibilidade.
●
Data Access Object (DAO). <http://www.macoratti.net/11/10/pp_dao1.htm>
Data de Acesso: 02/06/2016.