Pt - Ads - Sem 4 - Atividade Individual

Prévia do material em texto

�PAGE �
LISTA DE FIGURAS
6Figura 1 - Representação da Estrutura de um BDOO	�
15Figura 2 - ORM (Mapeamento Objeto-Relacional)	�
16Figura 3 - Como Funciona o ORM	�
�SUMÁRIO
31	INTRODUÇÃO	�
42	OBJETIVO	�
53	DESENVOLVIMENTO	�
53.1	FAÇA UMA PESQUISA SOBRE BANCO DE DADOS ORIENTADO A OBJETO	�
53.1.1	DESCREVA SUA APLICAÇÃO E SEU MECANISMO DE FUNCIONAMENTO	�
73.1.1.1	ABSTRAÇÃO	�
73.1.1.2	PERSISTÊNCIA DE OBJETOS	�
83.1.1.3	OBJETO	�
93.1.1.4	IDENTIDADE DE OBJETO	�
93.1.1.5	OBJETOS COMPLEXOS	�
103.1.1.6	ENCAPSULAMENTO	�
103.1.1.7	TIPO DE OBJETOS	�
103.1.1.8	MÉTODOS	�
103.1.1.9	CLASSES	�
113.1.1.10	HERANÇA	�
113.1.1.11	TIPOS DE HERANÇA	�
123.1.1.12	POLIMORFISMO	�
123.1.1.13	OUTROS CONCEITOS	�
123.1.2	QUAL A DIFERENÇA ENTRE BANCO DE DADOS ORIENTADO A OBJETO E BANCO DE DADOS RELACIONAL	�
143.2	PESQUISE SOBRE ORM (OBJECT RELATIONAL MAPPER) – MAPEAMENTO OBJETO RELACIONAL	�
143.2.1	COMO DESENVOLVER UTILIZANDO O MODELO ORIENTADO A OBJETOS COM UM BANCO DE DADOS RELACIONAL	�
163.2.2	O QUE É ORM E PARA QUE É UTILIZADO	�
173.2.3	QUAIS FERRAMENTAS ESTÃO DISPONÍVEIS HOJE NO MERCADO?	�
183.2.4	QUAIS AS VANTAGENS E DESVANTAGENS DE SE USAR UMA FERRAMENTA ORM?	�
183.2.4.1	VANTAGEM	�
193.2.4.2	DESVANTAGEM	�
204	CONCLUSÃO	�
21REFERÊNCIAS	�
��
INTRODUÇÃO
A necessidade de manipulação e armazenamento de dados complexos vem crescendo rapidamente com o passar do tempo. Essa necessidade fez com que o paradigma orientado a objetos fosse agregado aos Sistemas Gerenciadores de Banco de Dados (SGBDs). As informações complexas, como gráficos, imagens, áudio, vídeo, mapas, entre outros, requerem funcionalidades que vão além do que o modelo relacional de banco de dados pode oferecer. Por essa razão, surgiu o modelo de banco de dados orientado a objetos, que traz muitos benefícios em relação ao banco de dados relacional, pela sua produtividade ao agregar a orientação a objetos ao banco de dados. Entretanto, por ser um modelo jovem e imaturo que carece de mais estudo e desenvolvimento, suas operações são lentas quando comparadas com os bancos de dados relacionais existentes. Por essa razão, foi desenvolvido o banco de dados objeto relacional, o qual agrega características de ambos os bancos, o BDOO e o BDR, possuindo assim características da orientação a objetos combinada com tecnologia relacional que domina o mercado e funciona perfeitamente, seja no desempenho ou na confiabilidade do SGBD. 
Este trabalho apresentará características dos BDOO e DBOR, com uma comparação das vantagens e desvantagens dos dois modelos.
OBJETIVO
Esta produção textual interdisciplinar do 4º semestre do curso de Análise e Desenvolvimento de Sistemas, tem como objetivo aplicar e exercitar os conteúdos assimilados no período, abordando os diversos conceitos, técnicas e práticas sobre banco de dados orientado a objeto, banco de dados relacional e ORM (Object Relational Mapepr) – Mapeamento Objeto Relacional.
DESENVOLVIMENTO
FAÇA UMA PESQUISA SOBRE BANCO DE DADOS ORIENTADO A OBJETO
Hoje, o banco de dados orientados a objeto é um fator emergente que integra banco de dados e a tecnologia de orientação a objetos. Por um lado, a necessidade de realizar manipulações complexas para os banco de dados existentes e uma nova geração de aplicações de banco de dados geralmente requisitam mais diretamente um banco de dados orientado a objeto. Por outro lado, aplicações de linguagens orientadas a objeto e sistemas estão exigindo capacidades de banco de dados, tais como continuidade, simultaneidade e transações, dos seus ambientes. Estas necessidades estão levando à criação de sistemas poderosos, chamados banco de dados orientados a objeto.
DESCREVA SUA APLICAÇÃO E SEU MECANISMO DE FUNCIONAMENTO
O desenvolvimento dos Sistemas de Gerenciamento de Banco de Dados Orientado a Objetos (SGBDOO) teve origem na combinação de ideias dos modelos de dados tradicionais e de linguagens de programação orientada a objetos.
No SGBDOO, a noção de objeto é usada no nível lógico e possui características não encontradas nas linguagens de programação tradicionais, como operadores de manipulação de estruturas, gerenciamento de armazenamento, tratamento de integridade e persistência dos dados.
Os modelos de dados orientados a objetos tem um papel importante nos SGBDs porque, em primeiro lugar, são mais adequados para o tratamento de objetos complexos (textos, gráficos, imagens) e dinâmicos (programas, simulações). Depois, por possuírem maior naturalidade conceitual e, finalmente, por estarem em consonância com fortes tendências em linguagens de programação e engenharia de software. O casamento entre as linguagens de programação e banco de dados é um dos problemas que estão sendo tratados de forma mais adequada no contexto de orientação a objetos.
Alguns conceitos encontrados nas linguagens de programação orientadas a objetos (LPOO) são também aplicados nos modelos de dados orientados a objetos, porém bancos de dados requerem alguns conceitos próprios. Os objetos, em uma LPOO, existem somente durante a execução do programa e são por isso chamados de transitórios. Um banco de dados orientado a objetos pode estender a existência dos objetos de modo que eles sejam armazenados permanentemente, isto é, os objetos são persistentes (eles persistem após o término do programa e podem ser recuperados posteriormente e compartilhados por outros programas. 
Figura 1 - Representação da Estrutura de um BDOO
A seguir são apresentados os principais conceitos envolvidos em bancos de dados orientados a objetos.
ABSTRAÇÃO
É a consideração apenas das propriedades comuns de um conjunto de objetos, omitindo os detalhes, utilizada com frequência na definição de valores similares e na formação de um tipo a partir de outro, em diferentes níveis de abstração. O uso de abstrações permite a geração de tipos baseada em hierarquias de tipos e de relacionamentos.
Os principais conceitos de abstração utilizados em banco de dados são generalização e agregação. A generalização corresponde à associação "é um" onde, a partir de propriedades comuns de diferentes entidades, é criada uma outra entidade. O processo inverso é a especialização. A agregação corresponde a associação "parte de".
PERSISTÊNCIA DE OBJETOS
Sem duvida nenhuma, a persistência de objetos é uma característica primordial para os BDOO, pois alem de ser uma característica que possibilita diferenciar BDOO das linguagens de POO, ela também é fundamental para os BDOO.
Persistência de objetos consiste em não deixar com que objetos deixem de existir, ou seja, ao finalizar a execução de um programa que tenha como base uma linguagem de POO, todos os objetos instanciados deixam de existir. Com isso os valores dos atributos do objeto também desaparecem. Se isso fosse aplicado aos BDOO, o resultado seria uma catástrofe, pois os dados que serão inseridos em um BDOO na forma de atributos de objetos devem existir mesmo após o encerramento do programa de gerenciamento, tendo seu estado armazenado em um meio físico persistente, a menos é claro que os atributos sofram algum tipo de alteração ou exclusão, sendo estas solicitadas pelo usuário.
Para que os BDOO possam funcionar, é preciso aplicar a persistência de objetos em sua estrutura, a fim de que os dados não desapareçam.
Existem diversas maneira de torna o objeto persistente e todas elas variam conforme o sistema utilizado. Dentre essas formas podem-se considerar as seguintes:
Por tipo de classe onde os objetos pertencentes às classes assim declaradas serão persistentes.
Por chamada explícita onde o objeto pode se tornar persistente após a sua criação através de comandos reservados.
Por referência onde objetos referenciados por objetos persistentes (objetos raízes) também se tornam persistentes.
OBJETO
Os objetos são abstrações de dados do mundo real, com uma interface de nomes de operaçõese um estado local que permanece oculto. As abstrações da representação e das operações são ambas suportadas no modelo de dados orientado a objetos, ou seja, são incorporadas as noções de estruturas de dados e de comportamento. Um objeto tem um estado interno descrito por atributos que podem apenas ser acessados ou modificados através de operações definidas pelo criador do objeto. Um objeto individual é chamado de instância ou ocorrência de objeto. A parte estrutural de um objeto (em banco de dados) é similar à noção de entidade no modelo Entidade-Relacionamento.
A cada objeto armazenado no banco de dados é associado um identificador único (OID: Object Identifier), que é gerado pelo SGBDOO (sistema de gerenciamento de banco de dados orientado a objetos). O valor do OID não e visível ao usuário, mas é usado internamente pelo sistema para identificar cada objeto de forma única e criar e gerenciar referências entre objetos. 
A principal propriedade de um OID é que ele é imutável, isto é, o valor do OID de um particular objeto não deve mudar. O SGBDOO deve ter algum mecanismo para gerenciar OIDs e preservar a propriedade de imutabilidade. É também desejável que cada OID seja usado somente uma vez, isto é, os OIDs dos objetos que são removidos do banco de dados não são reaproveitados.
OIDs x Chaves Primárias
Nos modelos orientados a objetos não existe o conceito de chave primária como acontece no modelo relacional. Ao invés disso, existem os OIDs dos objetos que, como já dito, são criados e mantidos pelo sistema de gerenciamento de banco de dados e não são de acesso do usuário. 
As vantagens do uso de OIDs com relação às chaves são:
- os programadores de aplicações não precisam se preocupar com a seleção de chaves para as várias classes de objetos;
- obtém-se melhor desempenho, pois os OIDs são implementados em baixo nível pelo sistema;
- embora as chaves sejam mais significativas ao usuário, muitas vezes o usuário precisa usar códigos artificiais, sem significado semântico, para poder identificar as tuplas de uma relação.
IDENTIDADE DE OBJETO
Num modelo com identidade de objetos, estes têm existência independente de seus valores correntes e dos endereços de armazenamento físico. A identidade do objeto é geralmente gerada pelo sistema. A impossibilidade de garantir a identificação de objetos exclusivamente através de suas propriedades estruturais e comportamentais motivou a definição de identificadores únicos de objetos, que persistem no tempo de forma independente ao estado interno do objeto.
A identidade de objetos elimina as anomalias de atualização e de integridade referencial, uma vez que a atualização de um objeto será automaticamente refletida nos objetos que o referenciam e que o identificador de um objeto não tem seu valor alterado.
OBJETOS COMPLEXOS
Os objetos complexos são formados por construtores (conjuntos, listas, tuplas, registros, coleções, arrays) aplicados a objetos simples (inteiros, booleanos, strings). Nos modelos orientados a objetos, os construtores são em geral ortogonais, isto é, qualquer construtor pode ser aplicado a qualquer objeto. No modelo relacional este não é o caso, visto que só é possível aplicar o construtor de conjuntos às tuplas e o construtor de registro a valores atômicos.
A manutenção de objetos complexos, independente de sua composição, requer a definição de operadores apropriados para sua manipulação como um todo, e transitivos para seus componentes. Exemplos destas operações são: a atualização ou remoção de um objeto e cópia profunda ou rasa.
ENCAPSULAMENTO
O encapsulamento possibilita a distinção entre a especificação e a implementação das operações de um objeto, além de prover a modularidade que permite uma melhor estruturação das aplicações ditas complexas, bem como a segurança dentro do sistema. Em banco de dados se diz que um objeto está encapsulado quando o estado é oculto ao usuário e o objeto pode ser consultado e modificado exclusivamente por meio das operações a ele associadas.
TIPO DE OBJETOS
O tipo de objeto pode ser visto como a descrição ou especificação de objetos. Um tipo possui duas partes, interface (visível para o usuário do tipo) e implementação (visível só para o usuário construtor do tipo).
Existem várias vantagens em se ter um sistema de tipos em um modelo de dados. Além de modularidade e segurança, do ponto de vista da evolução do sistema os tipos são especificações do comportamento que podem ser compostos e modificados incrementalmente, para formar novas especificações.
MÉTODOS
Os objetos nos SGBDOOs são manipulados através de métodos. Em geral, a definição de um método consiste de assinatura e corpo. A assinatura especifica o nome do método, os nomes e classes dos argumentos e a classe do resultado, se existir. O corpo representa a implementação do método e consiste de um conjunto de instruções expressas em uma dada linguagem de programação.
CLASSES
Um conjunto de objetos que possui o mesmo tipo (atributos, relacionamentos, operações) pode ser agrupado para formar uma classe. A noção de classe é associada ao tempo de execução, podendo ser vista como uma representação por extensão, enquanto que o tipo é uma representação intencional. Cada classe tem um tipo associado, o qual especifica a estrutura e o comportamento de seus objetos. Assim, a extensão da classe denota o conjunto dos objetos atualmente existentes na classe e o tipo provê a estrutura destes objetos.
HERANÇA
Herança é um mecanismo que permite ao usuário definir tipos de forma incremental, por refinamento de outros já existentes, permitindo composição de tipos em que as propriedades de um ou mais tipos são reutilizadas na definição de um novo tipo. De fato, ela corresponde a transferência de propriedades estruturais e de comportamento de uma classe para suas subclasses.
As principais vantagens de herança são prover uma maior expressividade na modelagem dos dados, facilitar a reusabilidade de objetos e definir classes por refinamento, podendo fatorar especificações e implementações como na adaptação de métodos gerais para casos particulares, redefinindo-os para estes, e simplificando a evolução e a reusabilidade de esquemas de banco de dados.
TIPOS DE HERANÇA
Os dois tipos de herança, simples e múltipla, são descritos a seguir:
Herança Simples: Na herança simples um certo tipo pode ter apenas um supertipo, da mesma forma uma subclasse só herda diretamente de uma única classe. Podemos classificar esta herança em quatro subtipos: de substituição, de inclusão, de restrição e de especialização. 
Herança Múltipla: Nesta herança um tipo pode ter supertipos e os mesmos refinamentos de herança simples. Há basicamente dois tipos de conflitos referentes à herança múltipla: entre o tipo e o supertipo e entre múltiplos supertipos. O primeiro pode ser resolvido dando-se prioridade à definição presente no tipo, e não a no supertipo. Com os conflitos entre múltiplos supertipos, como uma resolução por default pode causar heranças não desejadas, a abordagem mais segura é baseada na requisição explícita da intervenção do usuário. 
Métodos e Mensagens
Um método, em relação a um objeto, corresponde ao comportamento dos objetos, implementando uma operação associada a uma ou mais classes, de forma similar aos códigos dos procedimentos usados em linguagens de programação tradicionais, que manipula o objeto ou parte deste. Cada objeto tem um certo número de operações para ele definida. Para cada operação pode-se ter um ou mais métodos de implementação associados.
As mensagens são a forma mais usada para se ativar os métodos. Num SGBDOO os objetos se comunicam e são ativados através de mensagens enviadas entre eles.
POLIMORFISMO
Em sistemas polimórficos uma mesma operação pode se comportar de diferentes formas em classes distintas. Como exemplo temos o operação print que será implementada de forma diferente se o objeto correspondente for um texto ou uma imagem: dependendo do objeto teremos um tipo de impressão. Tem-se também polimorfismoquando ocorre a passagem de diferentes tios de objetos como parâmetros enviados a outros objetos
Um mesmo nome pode ser usado por mais de uma operação definida sobre diferentes objetos, o que caracteriza uma sobrecarga (overloading). A redefinição do operador para cada um dos tipos de objetos definidos caracteriza uma sobreposição (overriding). As operações são ligadas aos programas em tempo de execução caracterizando o acoplamento tardio ou late binding.
OUTROS CONCEITOS
Finalmente há duas propriedades fundamentais para a construção de um SGBDOO: extensibilidade e completude computacional. A primeira garante que o conjunto de tipos oferecidos pelo sistema permite a definição de novos tipos e não há distinção entre os tipos pré-definidos e os definidos pelo usuário. A segunda implica que a linguagem de manipulação de um banco de dados orientado a objetos pode exprimir qualquer função computacional.
QUAL A DIFERENÇA ENTRE BANCO DE DADOS ORIENTADO A OBJETO E BANCO DE DADOS RELACIONAL
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 neste trabalho. 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.
Silbeschatz et. al. (2001) concluem que as bases de dados tradicionais são bastante eficientes para tarefas ligadas ao processamento de dados. A geração de folhas de pagamento e o gerenciamento de contas correntes, são exemplos. Esse tipo de aplicação trabalha basicamente com tipos de dados simples: numéricos, texto e datas. Além disso, essas aplicações possuem itens de dados que podem ser representados como registros razoavelmente pequenos e campos atômicos.
Apesar do conceito de bancos de dados orientados a objetos ser bastante distinto do modelo relacional, o mesmo resulta da integração entre a orientação a objetos e a tecnologia de banco de dados tradicionais. Enquanto na programação orientada a objetos, os objetos existem apenas enquanto o programa que os criou está em execução, os bancos de dados orientados a objetos podem criar objetos que sejam persistentes e compartilhados entre diferentes aplicativos.
PESQUISE SOBRE ORM (OBJECT RELATIONAL MAPPER) – MAPEAMENTO OBJETO RELACIONAL
COMO DESENVOLVER UTILIZANDO O MODELO ORIENTADO A OBJETOS COM UM BANCO DE DADOS RELACIONAL
Durante o desenvolvimento de software, é evidente a preocupação em que se tem em aumentar a produtividade sem abrir mão da qualidade. No que se refere a banco de dados, é possível a utilização de um framework ORM que nos permita focar mais nas regras de negócios da aplicação do que na persistência de dados em si, permitindo um desenvolvimento mais rápido e consistente.
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.
Esta técnica ultimamente tem sido muito utilizada e vem crescendo bastante nos últimos 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.
Figura 2 - ORM (Mapeamento Objeto-Relacional)
Fonte: http://www.devmedia.com.br/orm-object-relational-mapper/19056
Na figura acima, existem 2 mundos: o relacional e o orientado 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.
Figura 3 - Como Funciona o ORM
Fonte: http://www.devmedia.com.br/orm-object-relational-mapper/19056
A figura acima, nos faz ter uma ideia de como o ORM trabalha. Ele faz o mapeamento da sua classe para o banco 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ê.
O QUE É ORM E PARA QUE É UTILIZADO
Você que é desenvolvedor de aplicações orientadas a objetos, sabe que de alguma maneira precisa armazenar e recuperar informações em bancos de dados relacionais. Um ORM (Object-Relational Mapping), nada mais é do que um Framework ou um conjunto de classes que permite que você faça este trabalho sem precisar escrever códigos de conexão com o banco, querys de SQL a todo momento, preservando as características de orientação a objetos da linguagem face à natureza relacional dos bancos de dados atuais.
Mapeamento de Objeto-Relacional (ORM) é uma abordagem que permite a construção de sistemas utilizando o paradigma orientado a objetos com a persistência destes objetos em bancos de dados relacionais. Utilizando-se de técnicas e estratégias específicas, é possível mapear classes com seus atributos e associações para o modelo relacional (SILVA et al.; 2006).
Segundo (Bauer e King, 2005), ORM consiste de quatro partes: 
Uma API para executar operações de criar, ler, atualizar e apagar em objetos de classes persistentes.
Uma linguagem ou API para especificar consultas que referenciam classes e propriedades de classes.
Um recurso para especificar o mapeamento de metadados.
Uma técnica para interagir com objetos transacionais a fim de executar a verificação suja, buscas de associações ociosas e outras funções de otimização.
O ORM pode ser dividido em quatro níveis: Orelacional puro, o mapeamento de objetos leves, o mapeamento de objeto médio e o mapeamento completo de objetos. O nível de dependência ou de independência do modelo relacional vai diminuindo a medida que o mapeamento fica mais completo. E no último nível a modelagem sofisticada de objetos é suportada como herança, polimorfismo, etc.
QUAIS FERRAMENTAS ESTÃO DISPONÍVEIS HOJE NO MERCADO?
Lista de alguns softwares de mapeamento objeto-relacional disponíveis no mercado:
ADO.NET Entity Framework – Para a linguagem de programação Visual Basic .NET e C#;
DBIx::Class – Para a linguagem de programação Perl;
SQLObject – Para a linguagem de programação Python;
Hibernate – Para a linguagem de programação Java;
OJB – Para à linguagem de programação Java, da Apache Software Foundation;
Django (framework web) – Framework de desenvolvimento web escrito em Python que possui um ORM próprio;
ECO - Enterprise Core Object – Para a linguagem de programação Delphi;
NHibernate - Para a linguagem de programação .NET;
EntityCloud – Um ORM tipificado para .NET;
Doctrine - Para a linguagem de programação PHP;
Active Record - Para a linguagem de programação Ruby on Rails;
TMS Aurelius - Para a linguagem de programação Delphi;
Syrius ORM – Framework ORM escrito em PHP;
Propel ORM – Mapeamento Objeto-Relacional para PHP5;
Outros: Subsonic, CODUS, DataTier Generator, MyGeneration, Gentle.NET, NDO.NET, Persistor, TierDeveloper, DEV Force, etc.
QUAIS AS VANTAGENS E DESVANTAGENS DE SE USAR UMA FERRAMENTA ORM?
VANTAGEM
De acordo com Esjug (2007, p.14) implementar um mapeamento objeto relacional pode ser considerada uma tarefa complexa, porém esta tecnologia possui algumas vantagens: 
Produtividade – com a eliminação dos códigos SQL no código fonte, as classes passam a ser mais simples e com isso o sistema é desenvolvido em menor tempo.
Manutenibilidade – por reduzir o número de linhas do código fonte do sistema, menor será o trabalho de manutenção do sistema. 
Desempenho – o tempo economizado no desenvolvimento, pode ser dedicado a programar otimizações do sistema. 
Independência de Fornecedor – por mais que um banco de dados utilize a mesma linguagem SQL, alguns comandos, tipos de dados, podem ser diferentes de um banco para outro.
O grande diferencial da utilização dessa abordagem é o nível de abstração das operações com os dados, pois dependendo da estratégia utilizada, temos a nítida sensação de que estamos trabalhando com os dados sempre em memória, devido as chamadas a base estarem totalmente isoladas e “automáticas” do ponto de vista da camada de domínio da aplicação. Em Java, temos o JPA (Java Persistence API), que descreve uma especificação dizendo como os fabricantes devem desenvolver seus frameworks, algo que é muito interessante, pois isso possibilita a troca de uma implementação por outra quase sem alterações (a menos que esteja usando algum recurso fora da especificação). Se mudamos nossa base Oracle, podemos trocar nosso ORM de Hibernate para TopLink, por exemplo, em troca de um possível ganho de performance. Em outras linguagens temos o ADO.NET para .NET, ActiveRecord para Ruby, no próprio Java temos IBates, etc.
DESVANTAGEM
Temos alguns contras que existem quando se decide usar algum tipo de ORM. A primeira grande desvantagem é a performance. Num ambiente relacional, temos todos aqueles algoritmos que os bancos de dados usam para a recuperação dos dados, são de longe muito mais performáticos do que qualquer outro tipo de tratamento dos dados na aplicação. Outra desvantagem é a complexidade e o nível de entropia que é necessário para construir-se um bom design. Não é tão simples desenhar a arquitetura de um sistema utilizando uma estratégia desse tipo, o que pode ocasionar designs fracos e ruins, como disse anteriormente. As vezes, utilizado de maneira incorreta, o mapeamento pode acabar separando das entidades os dados e as regras de negócio. Do ponto de vista OO isso é um pouco estranho, pois um carro, por exemplo, contém tudo dentro de um objeto carro, certo? Ou na vida real existe um objeto Carro e outro DadosCarro? Para resolver esse problema podemos recorrer a alguns padrões (Factory, DAO, Repository), mas como percebe-se, a complexidade foi elevada.
CONCLUSÃO
Através da confecção deste trabalho observou-se o quanto amplo a tecnologia de orientação a objetos está permeando praticamente todas as novas aplicações computacionais. O que há algum tempo atrás era apenas uma buzzword que dava um “ar de modernidade” para algumas aplicações é atualmente uma tecnologia relativamente madura, com utilização efetiva nas mais diversas categorias de aplicação. 
Banco de dados é apenas uma das áreas que vem se beneficiando desta tecnologia. Provavelmente, mais do que simplesmente oferecer a capacidade de ter um repositório orientado a objetos para aplicações isoladas, a importância de sistemas gerenciadores de base de objetos será permitir a integração de aplicações em ambientes de objetos distribuídos. Nesta abordagem, os serviços de um sistema gerenciador de base de objetos poderão ser incorporados a aplicações de forma uniforme e transparente, da mesma maneira que assim o serão serviços de interfaces gráficas com usuários ou invocação dinâmica de serviços distribuídos.
Não há duvida de que a modelagem orientada a objeto veio para ficar e tem influenciado o tradicional modelo relacional. A união das duas abordagens, programação orientada a objeto e banco de dados relacionais provê a base dos bancos de dados objeto-relacional. 
Por fim, um ORM possui diversos recursos para o desenvolvedor estar utilizando em projetos, sendo inegável as vantagens providas pela utilização de um ORM, como a redução da impedância que existe entre um banco de dados relacional e os objetos de uma aplicação e o consequente aumento da produtividade e redução do tempo gasto em manutenções.
Foi bastante prazeroso e gratificante poder transformar em um documento prático e objetivo todos os conceitos ministrados no 4º período do curso de Análise e Desenvolvimento de Sistemas da UNOPAR e ter a certeza de que os mesmo nos ajudarão em nossas carreiras futuramente.
REFERÊNCIAS
BAUER, Christian; King, Gavin; “Hibernate Em Ação”, Ciência Moderna Ltda., 2005.
BOSCARIOLI, Clodis; Bezerra, Anderson; Benedicto, Marcos de; Delmiro, Gilliard. Uma reflexão sobre Banco de Dados Orientados a Objetos. Disponível em < http://conged.deinfo.uepg.br/artigo4.pdf > Acesso em 29/09/2013.
DEVMEDIA. ORM: Object Relational Mapper. Disponível em: < http://www.devmedia.com.br/orm-object-relational-mapper/19056 > Acesso em: 30/09/2013.
ELMASRI, Ramez. Sistemas de banco de dados. Ramez Elmasri e Shamkant B. Navathe; revisor técnico Luis Ricardo de Figueiredo. São Paulo: Addison Wesley, 2005.
FONSECA, André de A.; Neto, Antonio de A. S.; Souza, Lucas T. de; Dourado, Tasso L. Banco de Dados Objeto-Relacional (BDOR). Disponível em < https://disciplinas.dcc.ufba.br/pub/MATA60/WebHome/BDOR_2008.1.pdf > Acesso em 30/09/2013.
LINHA DE CÓDIGO. Uma Nova Era na Tecnologia dos Bancos de Dados. Disponível em: < http://www.linhadecodigo.com.br/artigo/68/uma-nova-era-na-tecnologia-dos-bancos-de-dados.aspx > Acesso: 10/10/2013.
NISHIMURA, Roberto Yukio (org.). Banco de Dados II: Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas - 3. São Paulo: Pearson Education do Brasil, 2009.
NISHIMURA, Roberto Yukio. Banco de Dados I: Curso superior de tecnologia em Análise e Desenvolvimento de Sistemas - 2. São Paulo: Pearson Education do Brasil, 2009.
OKANO, Marcelo. Análise dos melhores ORM (Object-Relational Mapping) para plataforma .NET. Disponível em: < http://www.devmedia.com.br/analise-dos-melhores-orm-object-relational-mapping-para-plataforma-net/5548 > Acesso em: 10/10/2013.
SILBERSCHATZ, A.; KORTH, H. F. and SUDARSHAN, S. (2001). Database System Concepts, McGraw-Hill, 4th edition.
 VIEIRA, Eduardo. O/R Mapping – Vale a pena? Disponível em: 
< http://evieira.wordpress.com/2009/04/> Acesso em: 08/10/2013.
Sobral - CE
2013.2
PRODUÇÃO TEXTUAL INTERDISCIPLINAR:
Individual
JOSÉ VIDAL DE ARAÚJO
JOSÉ VIDAL DE ARAÚJO
PRODUÇÃO TEXTUAL INTERDISCIPLINAR:
Individual
Trabalho de Análise e Desenvolvimento de Sistemas, apresentado à Universidade Norte do Paraná - UNOPAR, como requisito parcial para a obtenção de média semestral nas disciplinas de: Desenvolvimento Orientado a Objetos, Redes de Computadores, Modelagem Orientada a Objetos, Tópicos em Desenvolvimento de Sistemas e Seminários IV.
Orientador: Profs. Márcio Roberto Chiaveli
 Paulo K. Nishitani
 Polyanna P. G. Fabris
 Adriana A. Loper
Sobral - CE
2013.2
Sistema de Ensino Presencial Conectado
ANÁLISE E DESENVOLVIMENTO DE SISTEMAS