trabalho individual 2014 1º semestre

Prévia do material em texto

SISTEMA DE ENSINO PRESENCIAL CONECTADO 
ANÁLISE E DESENVOLVIMENTO DE SISTEMAS 
KAIO CÉSAR SIMÕES PEREIRA DE ALMEIDA 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
BANCOS DE DADOS E SEUS OBJETOS 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Montes Claros – MG 
2014 
 
 
KAIO CÉSAR SIMÕES PEREIRA DE ALMEIDA 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
BANCO DE DADOS E SEUS OBJETOS 
 
 
 
 
 
 
 
 
Trabalho apresentado ao Curso Analise e Desenvolvimento 
de Sistemas da UNOPAR - Universidade Norte do Paraná, 
para a disciplinas Desenvolvimento Orientado a Objetos; 
Redes de computadores; Modelagem Orientada a Objetos 
 
Prof. 
Marcio Roberto Chiaveli; Paulo K. Nishitani; Polyanna P. G. 
Fabris 
 
 
 
 
 
 
 
Montes Claros – MG 
2014 
 
 
 
SÚMARIO 
 
2 INTRODUÇÃO.......................................................................................................1 
3 OBJETIVO.............................................................................................................2 
4 DESENVOLVIMENTO ..........................................................................................3 
4.1BANCO DE DADOS ORIENTADO A OBJETOS ...............................................4 
 
4.1.1 MECANISMO DE FUNCIONAMENTO............................................................5 
 
4.1.2 DIFERENÇA ENTRE BANCO DE DADOS ORIENTADO 
 A OBJETO E BANCO DE DADOS RELACIONAL ...............................................7 
 
4.2 MAPEAMENTO OBJETO RELACIONAL............................................................9 
 
 
4.2.1. COMO DESENVOLVER UTILIZANDO O MODELO 
 ORIENTADO A OBJETOS COM UM BANCO DE DADOS RELACIONAL.............12 
 
4.2.2 O QUE É ORM E PARA QUE É UTILIZADO...................................................13 
 
4.2.3. QUAIS FERRAMENTAS ESTÃO DISPONÍVEIS HOJE NO MERCADO......14 
 
5 CONCLUSÃO.........................................................................................................17 
 
6 REFERÊNCIAS.......................................................................................................18 
 
 
 
 
 
 
 
 
 
 
 
 
 
2 INTRODUÇÃO 
 
A cada dia as empresas dewpendem mais de grandes e crescentes volumes de 
informação para suas decições de negocio, e essa informação deve estar sempre 
correta e de fácil acesso. Por isso essas empresas exigem de informação que atendam 
não só a sua necessidades funcionais, mas também estejam integrados com a 
necessidade de mudanças no negocio. 
Para atender essas necessidades, surgem inúmeros avanços computacionais a 
fim de possibilitar esses desenvolvimento dos negócios. Entre todos esses avanços 
computacionais pode – se citar a tecnologia de orientação a objetos. 
 
 
3 OBJETIVO 
 
É aproximar o leitor de forma simples e comunicativa de como e formado os 
bancos de dados e para que servem. 
 Entretanto puscando familarizar o conceito complexo do simples sem que passa 
despercebido como mão apenas usso , mais sabendo o que esta usando e pra que 
serve tal uso de software. Sem deixar de dizer que o importante não é saber o que 
fazer e sim pra que o feito está servido , e pra onde vai levar tanta disposição de uso e 
de entreiterimento de maquina vs homem. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
4. - DESENVOLVIMENTO 
 
 
4.1 Banco de dados orientados a objetos 
 
BDRs e BDOOs possuem características distintas mas basicamente servem ao mesmo 
propósito: persistir dados necessários para a manutenção do negócio para o qual são 
aplicados, possibilitando a recuperação, comparação e tratamento desses dados a fim 
de produzir resultados tangíveis. 
Em BDR, uma coleção de tabelas, todas com nomes únicos, compõem a base de 
dados,podendo estar relacionada a uma ou mais tabelas. Conceitos como integridade 
referencial de dados – que garantem que um dado referenciado em uma tabela esteja 
presente na tabela que está sendo referenciada – e chaves primárias estão presentes e 
garantem que um conjunto de informações possa ser representado de maneira 
consistente, independente da forma de acesso. 
Já um BDOO possui três pilares principais: herança, polimorfismo e 
encapsulamento, discutidos a seguir. Este modelo apresenta maior flexibilidade na 
manipulação de seu conteúdo e por meio de identificadores de objetos manipula os 
dados de forma consistente. 
 
Modelagem de um BDOO 
O paradigma da orientação a objetos possui uma maneira própria de representar um 
problema. Essa maneira difere muito da forma tradicional de modelagem de dados 
utilizada pelos bancos de dados relacionais, apesar de guardar algumas semelhanças, 
sobretudo, relativas à cardinalidade das relações entre as entidades. 
 
Objetos 
A modelagem de um banco de dados orientado a objetos está inti 
mamente ligada aos diagramas de classes gerados para o sistema. 
Cada objeto possui um estado e comportamentos e é diferenciado por um indicador 
único (OID ou object identifier). O estado do objeto depende do valor de cada uma de 
suas propriedades e o comportamento é especificado pelas operações que podem ser 
executadas pelo objeto, possivelmente, modificando o estado do mesmo. As 
propriedades podem ser atributos ou relações entre esse objeto e outros objetos que 
façam parte do domínio do problema. Em um banco de dados orientado a objetos o 
estado de um objeto consiste no valor de cada uma das suas propriedades, sejam 
atributos do próprio objeto ou relações com outros objetos. Os valores de atributos 
podem ser bastante complexos, tendo apossibilidade de serem, inclusive, outros 
objetos. Os relacionamentos também influenciam no estado do objeto e podem ser 
binários, ligando dois objetos, logo, potencialmente influenciando o estado de ambos. 
 
Classes 
Classes são agrupamentos de objetos de um mesmo tipo, que possuem 
comportamentos (operações) e propriedades (atributos e relações) em comum. Os tipos 
de objetos (classes) podem ser utilizados como domínios para propriedades ou 
argumentos para operações. Os bancos de dados orientados a objetos possibilitam que 
novos tipos sejam criados para se adequar aos requerimentos de cada aplicação, 
podendo ser combinados com os tipos já existentes no sistema e sendo utilizados 
exatamente da mesma maneira. 
 
Herança 
Uma classe pode ser derivada de outra classe, em um processo conhecido co 
mo especialização. Por exemplo, a classe Veículo exibida na Figura 1 é um molde para 
quaisquer objetos veículo que se necessite criar. Cada objeto deve ser único e se torna 
uma instância da classe à qual pertence. 
A herança permite que uma classe seja estendida por outra classe. Tomando o 
exemplo da classe Veículo, pode - se estendê - la, adicionando atributos e 
comportamentos para atender ao problema, como uma. A partir desse 
conceito básico, é possível supor que exista uma infinidade de classes que podem ser 
derivadas de Veículo, especializando atributos e comportamentos. Essa característica 
torna- se bastante útil quando da necessidade de expressar um problema que envolva 
diversos tipos com atributos e/ou operações em comum mas que possuam 
particularidades inerentes a algumas classes. 
 
 
4.1.1 Mecanismo de funcionamento 
 
 Os Bancos de Dados Orientados a Objetos possuem uma característica 
importante que é o armazenamento de objetos e suas operações de maneira a fornecer 
uma ligação transparente com a aplicação, sem a necessidade de uma camada de 
tradução dos dados, como ocorre com os Bancos de Dados Relacionais. 
 Os BDOO surgiram para oferecer uma alternativa de suporte às operações onde 
os bancos de dados relacionais não eram capazes ou eficientes. Cabe ressaltar o 
notável crescimento do paradigma de orientação a objeto nas novas aplicações 
computacionais,motivo ligado diretamente ao crescimento da utilização dos BDOOs. 
Assim, muitas vantagens são oferecidas por esse modelo de armazenamento, como a 
persistência de tipos de dados complexos e a representação dos dados e das 
operações de um objeto que também são persistidos. Os Banco de Dados Orientado a 
Objetos sugiram da necessidade de armazenar 
dados complexos e de acabar com a disparidade que havia na modelagem da 
aplicação e do Banco de Dados (BD). Com o advento das linguagens de programação 
orientadas a objetos, os programadores passaram a utilizar este paradigma e a 
modelagem então naturalmente passou também a seguir este modelo. O outro ponto é 
que objetos complexos precisam ser quebrados em diversas tabelas, ou relações, para 
serem armazenados e com isto para recuperar tal informação é preciso realizar um 
JOIN entre diversas tabelas. 
Com a orientação a objetos, é possível modelar objetos de forma mais próxima ao 
mundo real, como por exemplo, em um sistema de geoprocessamento, engenharia, 
pesquisa científica e tantos outros sistemas não triviais. Um Bando de Dados 
Orientado a Objetos – BDOO – permite ainda que a aplicação manipule objetos, 
independente se eles são persistentes ou não, pois é possível armazenar todo o objeto 
e não apenas seus atributos. 
O objeto é formado como se fosse uma tripla (i, c, v), onde o i é o OID doobjeto, 
o c é um construtor, ou seja, que tipo de valor ele vai receber ex.: atom, tuple,set, list, 
bag, array e v é o valor corrente. Então o objeto passa a suportar aquilo que foi definido 
para ele. Se ele vai receber um valor atômico ele só aceitará valores atômicos. 
Os construtores de tipos sets, bags, lists e arrays são caracterizados como 
tipos de coleções e a diferença entre eles é a seguinte: sets e bags, o pr 
imeiro só aceita valores distintos enquanto o segundo aceita valores duplicados. Lists e 
arrays, o primeiro só aceita números arbitrários, enquanto o segundo, o tamanho deve 
ser pré - estabelecido. 
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 
sistemaOO, que preza pelo encapsulamento nem toda tabela pode enxergar a outra, o 
que dificultaria muito as consultas. 
 
4.1.2 Diferença entre banco de dados orientado a objeto e banco 
de dados relacional. 
 
 
 
Analisando de forma sucinta o SGBDOO, temos respectivamente um banco que 
facilita a aproximação do mundo real, devido a trabalhar com orientação a objetos e 
suas características (herança, encapsulamento, abstração, polimorfismo), um banco 
que permite a manipulação de dados complexos, mesmo com desempenho inferior ao 
relacional e que possui um pobre nível nas consultas dos dados. Continuando a analise 
só que de um SGBDR, temos um banco que atua a um bom tempo no mercado pelo 
fato de se ter anos de desenvolvimento, investimentos e aperfeiçoamentos, um banco 
com desempenho superior aos SGBDOO, um SGBD que apresenta ricas consultas e 
que possui dificuldade em manipular dados complexos. 
Como podemos notar no parágrafo acima temos em cada tipo de SGBD citado, 
vantagens e desvantagens nos mesmos. Então se notou a carência de um SGBD que 
tivesse a capacidade de manipular dados complexos, que se adequasse ao paradigma 
de programação atual (orientação a objetos), que tivesse bom desempenho e que 
demonstrasse ricas consultas de dados. É a partir dessas vantagens de cada SGBD 
que se fundamenta o SGBDOR. O SGBDOR emprega um modelo que coloca a 
orientação a objetos em tabelas, unindo os dois paradigmas em um só. Utiliza os 
conceitos de supertabelas, supertipos, herança, reutilização de código, 
encapsulamento, controle de identidade de objetos (OID), referência a objetos, 
consultas avançadas e alta proteção dos dados. 
Com esse novo conceito surgiu à necessidade de uma linguagem padrão para o 
uso com o SGBDOR. É a partir daí que nasce o SQL-3, que na verdade é uma 
extensão do SQL-2 complementado com características do modelo objeto-relacional. 
Alguns exemplos de aplicações que utilizam SGBDOR são os seguintes: 
armazenamento de imagens (obtidas por satélite ou de alguma outra forma digital); 
projetos de arquitetura; dados sobre o espaço (regiões geográficas, criação de mapas), 
sistemas de informações geoespaciais, entre outros. 
 
Os SGBDs relacionais possuem uma característica muito importante: são 
extremamente confiáveis e mais eficientes, se comparados à maioria dos SGBDs 
orientados a objetos disponíveis no mercado. Além disso, o modelo de dados relacional 
foi criado para permitir a representação de uma grande variedade de problemas usando 
um pequeno conjunto de conceitos simples. 
Através da linguagem de consulta SQL (Structured Query Language) é possível fazer a 
busca e recuperação dos dados necessários de forma bastante eficiente. 
Dentre as vantagens do modelo relacional, talvez a mais importante esteja relacionada 
com a persistência dos dados. As regras e rotinas para tratamento da persistência dos 
dados podem ser criadas no próprio banco de dados relacional. 
Uma das grandes desvantagens do modelo relacional pode ser observada no momento da 
realização da análise de um sistema a ser implementado: a grande dificuldade em abstrair a 
realidade, ou seja, traduzir para um modelo de tabelas, com suas relações entre si, suas 
chaves primárias e estrangeiras, um problema do mundo real. 
 
 
4.2 Mapeamento Objeto Relacional. 
 
 
ORM (Object Relational Mapper) é uma técnica de mapeamento de objeto relacional 
que permite fazer uma relação dos objetos com os dados que os mesmos representam. 
Ultimamente tem sido muito utilizada e vem crescendo bastante nos úttimos anos. 
 Este crescimento, tem se dado principalmente pelo fato de muitos desenvolvedores 
não se sentirem a vontade de escrever código SQL e pela produtividade que esta 
técnica nos proporciona. Existem ótimos ORM´s como Hibernate, NHibernate, Entity 
Framework e etc. 
 
 
 
 
Tudo começa como mostrado na figura acima, existem 2 mundos: o relacional e o 
orinetado a objetos, no mundo relacional prevalecem princípios matemáticos com a 
finalidade de armazenar e gerenciar corretamente os dados, de forma segura e se 
trabalha com a linguagem SQL que é utilizada para dizer o banco de dados “O QUE?” 
fazer e não como fazer. Já no mundo orientado a objetos, trabalhamos com classes, 
métodos ou seja, trabalhamos fundamentados na engenharia de software e seus 
princípios que nos dizem “COMO” fazer. O ORM é justamente, a ponte entre estes dois 
mundos, ou seja, é ele quem vai permitir que você armazene os seus objetos no banco 
de dados, para isto fazendo um mapeamento dos seus objetos para as tabelas do 
banco de dados. 
 
 
 
 
 A figura acima, nos faz ter uma ideia de como o ORM trabalha. Ele faz o 
mapeamento da sua classe para o anco de dados e cada ORM tem suas 
particularidades, para gerar o SQL referente a inserção do objeto que corresponde a 
uma tabela no banco de dados e realizar a operação. Utilizando um ORM, também se 
ganha produtividade, pois deixa-se de escrever os comando SQL para deixar que o 
próprio ORM, faça isto por você. 
 
 
 
 
 
 
4.2.1. Como desenvolver utilizando o modelo orientado a objetos 
com um banco de dados relacional. 
 
 
Os dados não trabalhados são armazenados no disco usando o sistema gerenciador de 
arquivos,que geralmente e oferecido por algum sistema operacional. O SG traduz os 
comandos da linguagem de manipulação de dados (DML) em comandos de baixo nível 
do gerenciador de arquivos. 
Sendo assim a simplifcação de banco de dados com relacinamento e forma 
simples . Tendoos dados e diagramas e toda uma equipe facilita , pois os dados estão 
relacionados a uma forma de editar e projetar certo programa. A organização desses 
dados relacionais não são , totalemnte voltados ao BDOO, sendo assim a formção 
desse modelo é concluisva e xplicativa. 
Exemplo focativo , tento um objeto de caso seja de uso , como forma 
comunicativa de cliente para servidor o relacionamento e dado pela interface desse 
metodo e do banco de dados e so a conclusão de organização. A construção bem 
sucedida gera a forma comunicativa perfectivamente futuristica e expansiva. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
4.2.2 O que é ORM e para que é utilizado. 
 
Visando aproveitar ao máximo o conceito de Orientação a Objetos, o Mapeamento 
Objeto-Relacional (ORM) consiste em um framework que tem por objetivo suprir as 
disparidades entre o paradigma orientado a objetos e o modelo entidade-relacional, 
criando uma ponte (mapeamento) entre o modelo relacional e o modelo orientado a 
objetos. Ou seja, ao trabalhar com essa abordagem, é possível a construção de 
sistemas utilizando o paradigma orientado a objetos, cujo os objetos são persistidos em 
um banco de dados relacional. 
Um ORM possui diversos métodos básicos que irão realizar a interação entre a 
aplicação e o banco de dados, se responsabilizando por algumas tarefas básicas, como 
o CRUD (Create, Read, Update e Delete), por exemplo. Além disso, o ORM irá 
gerenciar os detalhes de mapeamento de um conjunto de objetos para um banco de 
dados. 
O ORM reduz ao mínimo a necessidade de escrever códigos de conexão e queries 
SQL. Dessa forma, é possível obter uma redução significativa nos códigos da aplicação, 
gerando um código mais elegante e consequentemente ampliando a facilidade de 
posteriores manutenções na aplicação. 
É importante deixar claro que a utilização de um framework ORM não substitui 
totalmente a necessidade da utilização de SQL na sua aplicação. Embora o ORM 
satisfaça a maior parte das necessidades de interação com o banco de dados, em 
alguns casos, haverá a necessidade, por exemplo, de consultas mais customizadas, 
que terão que ser realizadas por meio de SQL. 
A forma como o ORM irá realizar o mapeamento dependerá especificamente do 
framework utilizado. Neste artigo, iremos abordar algumas soluções e vantagens 
agregadas com o uso do NHibernate e Entity Framework – dois dos mais conhecidos 
frameworks voltados especificamente para ambientes .NET – e algumas ferramentas 
que auxiliam sua utilização. 
Vantagens 
A utilização do NHibernate trás diversas vantagens durante o desenvolvimento de um 
projeto. Por ser um port do Hibernate, o framework apresenta uma certa maturidade, 
proporcionando um projeto com um maior nível de confiabilidade. Além disso, o 
NHibernate consiste em um framework Open-Source, resultando em uma economia de 
custos no desenvolvimento do projeto. 
Uma outra vantagem do NHibernate é possuir um suporte ativo, uma boa 
documentação e diversos fóruns sobre o tema. 
O NHibernate oferece algumas facilidades em relação a mudanças, tanto no 
mapeamento quanto no banco de dados, sendo possível fazer com que o NHibernate 
crie ou atualize o banco de dados para coincidir com o modelo na aplicação. 
Desvantagens 
Um dos pontos do NHibernate que podem ser considerados negativos é a alta curva de 
aprendizado devido a complexidade que o framework apresenta. De fato, o que 
acontece é que existem muitas configurações e otimizações que são desconhecidas 
para a maioria dos profissionais que o utilizam, requerendo mais estudo e dedicação de 
quem irá utilizá-la. 
Uma outra desvantagem é o trabalho em que se tem para gerar todos os arquivos XML 
necessários para a realização da persistência. 
 
4.2.3. Quais ferramentas estão disponíveis hoje no mercado. 
 
 
Infelizmente, os termos "ORM" e "problemas de performance" freqüentemente caminham juntos. 
Ao ocultar o SQL dos desenvolvedores, ORMs pode oferecer um aumento de produtividade 
enorme. Infelizmente, eles tornam mais fácil gerar consultas ridiculamente ruins, sem 
percebermos. Administradores de base de dados normalmente conseguem achar erros em códigos 
fazendo referência cruzada do stored procedure culpado com os códigos que o chama. Mas com o 
SQL gerado dinamicamente que os ORM dependem, esse truque raramente funciona. Então 
vamos dar uma volta em torno de algumas ferramentas para "profilling" de ORMs. 
NHibernate 
NHibernate Profiler (NHProf) inclui o que você esperaria de um produto básico. Além de manter 
estatísticas gerais, ele mostra uma lista de consultas recentes com o SQL completo e os "back-
traces" que o codigo chama com seus "stack traces". A interface é limpa e bem referenciada, 
tornando mais fácil mudar de uma análise de consulta isolada, por exemplo, para todas as 
consultas utilizas em um bloco de código. 
A melhor vantagem para NHibernate Profiler é recurso de alertas. Alguns alertas indicam 
problemas imediatos como erros de banco de dados ou usando acidentalmente uma sessão com 
varias threads. Outros alertas indicam a possibilidade de problemas como um grande numero de 
escritas individuais que provavelmente poderiam ser agrupadas dentro de um único lote. Existem 
também alertas que avisam sobre problemas que podem ocorrer no futuro como conjunto de 
resultados fora de limites. 
Um conjunto de resultados sem limites é quando uma consulta é executada e não e' 
explicitamente limitado o número de resultados retornados usando setMaxResults () com 
NHibernate ou TOP ou cláusulas LIMIT no SQL. Normalmente, isso significa que a aplicação 
assume que uma consulta sempre retornará apenas alguns registros. Isso funciona bem em 
desenvolvimento e nos testes, mas é uma bomba-relógio prestes a explodir na produção. 
O lado negativo do NHibernate Profiler é que ele é um pouco invasivo. Você não pode anexar a 
um processo em execução, tem que ser configurado por fora. Embora a maneira recomendada é a 
de incluir uma referência à NHibernate Profiler diretamente no seu código, os usuários 
do log4net também pode ativar o perfil através de uma configuração app.config. 
NHibernate Profiler é um produto comercial que começa em cerca de US $ 300 dólares 
por usuário. 
LINQ to SQL 
DataContext logging é a primeira coisa que os desenvolvedores provavelmente vai 
considerar quando tiver olhando problemas de LINQ para SQL. O objeto DataConext 
tem uma propriedade de log que encaminha todos os SQLs que sao gerados para um 
TextWriter da sua escolha Apesar de livre e de graça, o grande volume de linhas de 
SQL que ele gera torna questionável o uso em aplicações não-triviais. 
LINQ to SQL Profiler (L2SProf) é pela mesma empresa que construiu NHibernate 
Profiler e parece trabalhar de uma forma similar. Além de fazer profilling em tempo real, 
você pode configurá-lo para gravar os arquivos de log a ser analisado posteriormente. 
Como NHProf, o valor é de cerca de US $ 300 dólares por usuário. Atualmente ele está 
em fase beta. 
Huagati Query Profiler é outro profiler invasivo. Eles dizem que o “componente runtime 
são feitos para serem integrados e distribuídos com aplicações que usam tanto o Linq-
para-SQL, ou LLBLGen Pro para acessar o SQL Server.” Felizmente o Profiler pode ser 
ligado e desligado em tempo de execução, conforme necessário. 
A interface de usuário para Huagati é totalmente arcaica. É constituída uma grande grid 
que toma conta de metade da tela com os SQLs e stack traces abaixo dela. Falta-lhe 
todas as minúcias que NHProf / L2SProf tem como alertas e tela de informações, mas 
ele tem uma característica atraente para o desenvolvedor de baixo nível, o detalhe. 
O Profiler da Huagati é não informa apenas durações absolutas e contagens de linha, 
realmente vai fundo e tira todas as informaçõesque o SQL Server disponibiliza.Em vez 
de apenas ver o tempo de reposta, você começa a ver as informações importantes, 
como quanto tempo foi gasto com a compilação da consulta versus tempo de execução. 
Leituras e escritas (E/S) estão inclusas e você ainda pode ver o plano de execução. 
Huagati Query Profiler é um produto comercial, que começa em US $ 50 dólares para 
uma versão limitada e US $ 120/usuário para a versão completa. 
ADO.NET Entity Framework 
A história aqui é francamente lamentável. Primeiro de tudo, nvocê nem tem o log de 
SQL básico, como o que está disponível no LINQ para SQL. Além disso, parece que 
ninguém está desenvolvendo profilers para trabalhar com ele. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
5 . Conclusão 
 
Com o crescimento da utilização dos conceitos OO para o desenvolvimento de 
aplicações de alto nível, torna – se cada vez mais necessário que se utilize uma forma 
de armazenamento em os objetos possam ser modelados e armazenados sem que 
haja a necessidade de transformação dos mesmos. 
A necessidades de funcionalidade e desempenho da nova dimensão da 
computação exigem bancos de dados que transcendam os limites do modelo racional. 
Com a utilização dos conceitos de OO é possível um representação realista do mundo 
dos dados complexos. 
Ao estudar BDOO percebe-se que sua conceituação traz recursos antes não 
exitentes em bancos de dados puramente relacionais. Estes recursos surgiram pelo 
Largo uso de linguagens de programação. 
 
 
 
 
 
 
 
6 Referências 
 
http://conged.deinfo.uepg.br/artigo4.pdf 
 
http://www.salesiana.edu.br/si/edicao3/banco_de_dados_orientado_a_objetos.pdf 
 
http://rafaeloliveirav.wordpress.com/2009/06/19/artigo-comparativo-entre-banco-de-
dados-orientado-a-objetos-bdoo-e-bancos-de-dados-objeto-relacional-bdor-parte-2/ 
: ORM : Object Relational Mapper http://www.devmedia.com.br/orm-object-relational-
mapper/19056#ixzz302tRr6yT 
 
http://www.princiweb.com.br/blog/programacao/aspnet/veja-o-que-e-orm-e-os-
frameworks-disponiveis-para-net.html 
http://www.infoq.com/br/news/2009/11/ORM-Profiling