Produção Textual Interdisciplinar Individual - 4º Semestre

1 DESENVOLVIMENTO:D 
1.1 BANCO DE DADOS ORIENTADO A OBJETO:lol!: 
O SGBD Orientado Objeto é mais adequado para o tratamento de objetos complexos. Esses objetos são classificados como estruturados e não estruturados. Sendo que um objeto complexo não estruturado possui um tipo de dado que requer um grande volume de armazenamento, por adquirir novos tipos de dados para armazenamento de imagens ou textos longos. E os estruturados são definidos pela aplicação de determinados construtores de tipos, como, conjunto (coleções), tupla, lista ou array (ordem) (NAVATHE, 2005).
Conforme Setzer (2005), o desenvolvimento do referido SGBD teve combinação de ideias dos modelos de dados tradicionais e das linguagens de programação orientada a objetos. E, o contexto rico desses objetos é verificado no nível lógico e possui características não encontradas nas linguagens de programações tradicionais, como operadores de manipulação de estruturas, gerenciamento de armazenamento e outros.
Na verdade, para que um sistema de banco de dados seja considerado orientado a objetos, é importante a presença de Identificadores de Objetos (OID), mecanismo de herança (única ou múltipla), objetos complexos e persistência de objetos.
A seguir são apresentados alguns conceitos importantes para a orientação a objetos que foram recomendados para adicionar as funcionalidades de banco de dados às linguagens de programação orientada a objetos.
3.1.1 Objetos Complexos
Quando nos referimos a um objeto, o mesmo possui, caracteristicamente, dois componentes: estado (valores) e comportamento (operações). Assim, é semelhante a uma variável de programa em uma linguagem de programação, exceto que geralmente terá uma estrutura de dados complexa.
Um conceito mais simples relacionado a um objeto é que o mesmo é uma entidade lógica que contém dado e código com o objetivo de manipular esses dados. Os dados são destinados como sendo atributos do objeto, e o código que o manipula é denominado de método. Sendo que um método é uma função que manipula a estrutura de dados do objeto.
Objetos complexos são formados por construtores (conjuntos, listas, tuplas, registros, coleções, array) aplicados a objetos simples (inteiros, booleanos, string). A distinção do modelo OO em relação ao modelo relacional, é que no modelo OO qualquer construtor pode ser aplicado a qualquer objeto, já no modelo relacional este não é o caso, visto que só é possível aplicar o construtor de conjuntos nas tuplas e o construtor de registros nos valores atômicos (ARBEGAUS, 2003). Para tal, existem praticamente dois tipos de objetos complexos em um SGBDOO:
• Objetos embutidos: são caracterizados como “objetos filhos”, que constituem os atributos, que só podem ser acessados pelo seu “objeto-pai”. São resultados da estrutura de agregação ou “todo-parte”. Objetos embutidos não possuem OID próprio e são, em geral, armazenados na mesma estrutura física de seu “objeto pai”. Os mesmos possuem como exemplo os casos dos relacionamentos dependentes, como os “itens de um pedido de venda”. Nesse exemplo, os “itens” são objetos embutidos dos “pedidos de venda”.
• Objetos referenciados: são caracterizados como objetos originários das regras de integridade referencial. Qualquer relacionamento, como por exemplo, de uma “Cidade” com o seu respectivo “Estado” corresponde à criação de um objeto composto do tipo referenciado. Os objetos referenciados possuem OID próprio e podem ser acessados diretamente ou através de seus objetos relacionados.
3.1.2 Identificador de Objetos
No SGBDOO, o OID é dito persistente, ou seja, a identidade do objeto persiste não só entre execuções de programas, mas também durante reorganizações estruturais de dados. A identidade do objeto é geralmente gerada pelo sistema quando o objeto é criado. No entanto, segundo Silva (2001) um OID em SGBDOO não pode ser:
a) Um endereço (como um nome de variável ou referencia de memória de uma linguagem de programação) porque não é externo ao objeto;
b) Uma chave (como chave primária de um BDR) porque não é um valor de dados mutável;
c) Um register ID porque não é uma coluna lógica.
Para Silva (2001) a identidade de objetos tende a eliminar 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.
Para Navathe (2005), a identidade única de cada objeto armazenado na base de dados é geralmente implementada por meio de um identificador de objeto (OID). Sendo que o valor de um OID não é visível para um usuário externo, mas é utilizado internamente pelo sistema, com a finalidade de identificar univocamente cada objeto.
3.1.3 Herança Única e Múltipla
Um conceito essencial no banco de dados OO é que a herança é um tipo de relacionamento entre classes, onde uma classe compartilha (herda) estrutura de dados (atributos) e métodos (operações) de outras classes.
Logo, há dois tipos de herança, que são classificados como herança simples e múltipla. Na herança simples, uma classe é subclasse de apenas uma superclasse. Na herança múltipla, uma classe pode ser subclasse de várias superclasses, herdando variáveis e métodos de várias classes (GONÇALVES, 2008).
As “Classes de Coleção” ou “Classes de Sistema” são exemplos principais das características de herança em um SGBDOO. A maior parte desses SGBD possuem uma coleção própria de classes de objetos, onde estas classes são organizadas numa hierarquia. Na verdade, uma determinada aplicação pode desenvolver sua própria classe e herdar atributos ou métodos de alguma classe do sistema. Logo, as classes de sistema dos SGBDOO implementam os métodos de armazenamento, manipulação, controle de concorrência, entre outros (ARBEGAUS, 2003).
Para Arbegaus (2003), os SGBDOO armazenam as declarações das classes, confeccionando-as como parte do esquema do banco de dados. Logo, uma hierarquia de classes proporciona muito mais flexibilidade para modificar a estrutura de um banco de dados (incluindo novos atributos ou métodos nos objetos) possibilitando a evolução do esquema do banco de dados por meio da adição de novas classes na hierarquia.
3.1.4 Persistência de Objetos
Nas linguagens de programação OO, durante a execução do programa, ao se eliminar um objeto que foi instanciado, ou criado, ele passa a deixar de existir. Esses objetos são denominados como transientes, pois só existem durante a execução do programa e desaparecem quando o programa termina (SETZER, 2005).
Para garantir que um objeto continue persistindo após o término do programa é preciso que o banco de dados OO estenda a existência desses objetos de uma maneira que sejam armazenados de forma permanente na base de dados. Para isso acontecer, deve ser associado a um mecanismo de nomeação, que consiste em dar a um objeto um nome persistente único pelo qual ele possa ser recuperado pelo programa em execução e outros programas. Este nome de objeto persistente pode ser atribuído por meio de um comando específico ou uma operação no programa. Todos os nomes atribuídos aos objetos devem ser únicos dentro de um determinado banco de dados. Portanto, os objetos persistentes nomeados são utilizados como pontos de entrada pelos quais os usuários e as aplicações podem iniciar o acesso ao banco de dados. Com isso, um objeto estará realmente armazenado, e todos os seus componentes também serão tornados persistentes (NAVATHE, 2005).
Na visão de Setzer (2005. p. 280):
A solução mais simples adotada foi a de se estabelecer que a persistência seja uma característica de todos os objetos criados em um processamento. Uma outra foi a de se especificar quais objetos devem ser persistentes, isto é, quando eliminados durante ou no fim do processamento, os valores de seus atributos não são perdidos. Essa é a solução mais flexível, porém mais complexa.
3.1.5 Características
A seguir são algumas características que são importantes em um SGBDOO.
• Tipos abstratos de dados (Classes): É definido como um conjunto de objetos que compartilham a mesma estrutura e o mesmo comportamento (operações). Sendo que um objeto é uma instância de uma classe, ou seja, suas características são definidas na classe a qual foi instanciado (GONÇALVES, 2008).
• Encapsulamento: Essa definição se refere à independência dos dados de um objeto em relação a outros objetos, isto é, nenhum método de um objeto pode obter ou alterar diretamente os dados de outro. Desse modo, o objetivo do encapsulamento é de ocultar detalhes da implementação dos métodos e da estrutura dos atributos (SETZER, 2005).
• Identificador de objeto: Os objetos possuem identificadores únicos que são independentes de seus valores de atributos.
• Polimorfismo ou Sobrecarga de Operador: No conceito de orientação a objetos, dentro de uma classe, operações podem ser sobrecarregadas para serem aplicadas a diferentes tipos de objetos com diferentes implementações (NAVATHE, 2005).
Para Setzer (2005. p. 277):
Uma classe da OO contém um conjunto de dados, denominados de variáveis de classes ou atributos, e um conjunto de procedimentos, denominados de métodos, formando um todo. Os dados de uma classe são globais a todos os métodos da mesma, isto é, estão disponíveis em todos estes. Os dados de uma classe só podem ser alterados pelos métodos da classe (e de subclasses, no mecanismo de herança).
3.1.6 Restrições de Integridade
A maior parte das restrições de integridade existentes nos bancos de dados tradicionais se aplica também aos SGBDOO. No entanto, devido às construções e ao poder de modelagem do modelo de dados orientado a objetos, algumas restrições deixam de ser relevantes, outros adquirem formas diferentes, logo os BDOO acrescentaram outros tipos de restrições e especificações de integridade (ARBEGAUS, 2003). Para tal, as restrições de integridade são classificadas como Restrições de Integridade de Chave, Restrições de Integridade Referencial, Restrição Existencial, Restrição NOT NULL, Restrições de Pré-Condições e Pós-Condições de Métodos e Restrições de Cobertura.
3.1.6.1 Restrições de integridade de chave
Nos Bancos de Dados Relacionais é frequente a especificação de chaves para as relações, com o objetivo de identificar exclusivamente as tuplas de uma relação tanto em nível físico quanto em nível lógico, com o intuito de otimizar os processos de consulta. No entanto, nos BDOO é função do OID (object ID) identificar exclusivamente em nível físico as instâncias de uma classe e, para identificação em nível lógico; os BDOO permitem que sejam definidas chaves para uma determinada classe. Nos BDOO as chaves também otimizam os processos de consulta.
3.1.6.2 Restrições de integridade referencial
Os objetos de um banco de dados normalmente estão relacionados com outros objetos no banco de dados. Da existência das relações vem à necessidade da integridade referencial, que tem por objetivo assegurar que objetos não contenham relacionamentos com objetos que não existam mais no banco de dados. As especificações de restrição de integridade referencial garantem que não haja referências “pendentes” para objetos de uma classe.
Referente ao conceito desta restrição, o que distingue o modelo relacional do modelo OO é que, no modelo relacional, o mecanismo mais utilizado para referenciar objetos entre si é o da chave estrangeira, que relacionam os objetos pelos valores de seus atributos. Logo, nos SGBDOO que permitem o conceito de OID do objeto, não há necessidade de restrições de integridade do tipo “chave estrangeira”, visto que o OID permite referenciar objetos diretamente.
3.1.6.3 Restrição de integridade existencial
As restrições existenciais suportam somente sistemas que executam o conceito de OID, a mesma tem a finalidade de assegurar que um objeto compartilhado referencialmente possui um domínio “ativo” (um grupo específico de objetos que no momento existem em função de determinada condição) no qual ele deve existir. Por exemplo: se numa locadora de livros possui um sistema de folha de pagamento multi-empresa e no cadastro de empresas do sistema existe um campo denominado “Telefone”, logo, consiste numa restrição existencial certificar, que todo o telefone informado no campo “Telefone Comercial” do cadastro de funcionários é um telefone existente no domínio ativo do cadastro de empresas (telefones cadastrados nas empresas).
3.1.6.4 Restrição not null
Para um SGBDOO suportar restrições NOT NULL, ele será obrigado a suportar valores NULL. Um valor referente à NULL define que este valor não existe ou está indisponível. Quando uma restrição NOT NULL é definida para um atributo, a faixa de valores que esse atributo pode receber corresponde à faixa especifica para o tipo definido para o atributo. Portanto, os valores NOT NULL não são aceitos, como um valor válido, porque são permitidos apenas valores correspondentes à faixa de valores determinados para o atributo.
3.1.6.5 Restrições de pré-condições e pós-condições de métodos
As restrições de pré-condições permitem a definição de certas restrições nas variáveis de instância que devem ser satisfeitas, para que um determinado método possa ser executado. Já as restrições de pós-condições permitem a definição de outras restrições que devem ser cumpridas depois da execução do método.
3.1.6.6 Restrições de cobertura
As restrições de cobertura determinam que uma superclasse não possa possuir instâncias que não sejam elementos de determinado grupo de suas subclasses. Uma maneira de obter tal restrição consiste em definir a superclasse como sendo classe abstrata. Desta forma não seria possível criar uma instância da superclasse, somente de suas subclasses. Porém, podem existir situações onde seja necessário instanciar uma superclasse, mas mesmo assim manter a restrição de cobertura, sendo que o sistema iria levantar uma exceção somente se esta instância criada fosse salva como um elemento da superclasse e não como um elemento de uma das subclasses de cobertura.
1.2 APLICAÇÃO E MECANISMO DE FUNCIONAMENTO DO BDOO:lol!: 
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.
A seguir vou detalhar a abordagem de modelagem utilizada pela orientação a objetos.
3.2.1 Objetos e Atributos
Na orientação a objetos, objetos têm uma identificação única que não depende de valores de seus atributos. Esta identificação de objeto (OID) é utilizada para referências a objetos, tanto internas como (possivelmente) externas. Deste modo, limitações relacionadas ao processamento de chaves (primárias, “estrangeiras”) em sistemas de banco de dados relacionais não estariam presentes em sistemas de banco de dados orientados a objetos.
Não obstante, o conceito de um atributo chave está presente em muitas aplicações. Deste modo, apesar de não ser um conceito da orientação a objetos, vários sistemas gerenciadores de base de objetos oferecem a definição de atributos chaves como um mecanismo de acesso adicional ao identificador de objeto, mais próximo da compreensão dos usuários e oferecendo as mesmas restrições de integridade presentes em sistemas gerenciadores de banco de dados relacionais.
Atributos de objetos estão presentes em qualquer sistema gerenciador de banco de dados, sendo que em sistemas tradicionais usualmente tais atributos estão restritos a valores literais e atômicos.
Uma diferença em sistemas gerenciadores de base de objetos está na maior flexibilidade oferecida para a definição destes atributos, que podem simples ou complexos.
Atributos simples são aqueles cujos valores são literais. Em muitas aplicações, valores multimídia são considerados atributos simples, onde o BLOB referente ao objeto multimídia é considerado um valor literal, atômico e não estruturado. Um sistema gerenciador de banco de dados multimídia é essencialmente um sistema gerenciador de base de objetos onde os dados multimídia recebem tratamento diferenciado, não sendo considerados simples BLOB literais.
Atributos complexos podem ser de três tipos: referências, coleções ou virtuais. Referências ou associações estabelecem relacionamentos entre objetos, tendo como valores identificadores de objetos. Um aspecto fundamental em sistemas gerenciadores de base de objetos é a manutenção da consistência entre referências a objetos.
Atributos complexos do tipo coleção são utilizados para definir conjuntos, listas ou arranjos de valores. Coleções são exemplos de tipos parametrizados presentes em sistemas gerenciadores de base de objetos; os três tipos citados são as construções parametrizáveis fundamentais, porém outras podem estar presentes em distintas execuções.
Atributos virtuais ou derivados são aqueles cujos valores não estão explicitamente armazenados na base de dados, mas ao invés são computados através de procedimentos. Em geral, tais atributos são definidos como read-only, sendo raro o oferecimento de mecanismos para atualizar seus valores.
3.2.2 Aspectos comportamentais
Um sistema gerenciador de base de objetos precisa oferecer mais que simplesmente novos mecanismos de estruturação de dados. Além da orientação a objetos estrutural, é preciso suportar a orientação a objetos comportamental, que pode ser obtida através da definição de métodos, procedimentos que permitem encapsular a semântica de um objeto. Em geral, atributos de um objeto é propriedade privada e exclusiva do objeto, sendo que apenas através dos métodos públicos a informação associada ao objeto pode ser manipulada. Este mecanismo de encapsulação é fundamental para atingir independência de dados em sistemas gerenciadores de base de objetos.
A definição estrita de encapsulação exige a satisfação de três critérios:
a. Apenas métodos podem ser públicos;
b. Métodos são definidos em uma linguagem procedimental;
c. Métodos podem manipular apenas dados do próprio objeto.
Esta definição é satisfeita em Smalltalk. Há, no entanto diversas outras linguagens de programação orientada a objeto e sistemas gerenciadores de base de objetos que relaxam uma ou mais destas restrições para oferecer um melhor desempenho de execução às custas de se aceitar um grau menor de encapsulação.
A representação de comportamento em sistemas gerenciadores de base de objetos permite definir dados ativos, que incluem os atributos derivados, regras e agentes. Regras ou triggers são definidas como pares padrão-ação, onde as ações são ativadas quando modificações à base de dados tornam verdadeiro o predicado expresso no padrão da regra. Restrições de integridade são casos particulares de regras onde as ações estão limitadas a sinalizações de condições de erro. Agentes são caracterizados por processos associados ao sistema gerenciador de base de objetos, porém independentes, podendo realizar ações que extrapolam o ambiente da base de dados, tipo enviar uma mensagem por correio eletrônico.
3.2.3 Tipos e Herança
Objetos com estrutura similar são agrupados em classes, sendo que o tipo do objeto é definido através de uma declaração de classe. Usualmente, tipos são criados através de uma linguagem de definição de dados ou, mais especificamente em sistemas gerenciadores de base de objetos, através de uma linguagem de definição de objetos. Uma diferença entre uma linguagem de definição de dados e uma linguagem de definição de objetos é que esta última pode permitir como já observada, a definição de procedimentos associados à estrutura, como no caso de atributos virtuais, incorporando assim aspectos de linguagem de manipulação de dados.
Um conceito avançado que pode estar presente um uma linguagem de definição de objetos é o conceito de herança, que permite definir novos tipos de objetos a partir de tipos já existentes. Herança é um mecanismo de execução do conceito de generalização, importante para bancos de dados como ressaltado no trabalho de Smith e Smith sobre abstração de dados. Os novos subtipos podem ser diferenciados dos tipos dos quais foram derivados por mecanismos tais como especialização, com o acréscimo de novos atributos, ou sobrecarga (overloading), onde se oferece uma efetivação diferenciada para um método já existente no tipo ancestral. Deste modo, o esquema de tipos de objetos define uma árvore ou hierarquia de tipos relacionados.
Herança múltipla refere-se ao mecanismo de herança através do qual um novo tipo de objeto pode ser derivado a partir de mais de um tipo ancestral. Entretanto, a semântica de herança múltipla nem sempre é clara. Ademais, a execução de herança múltipla requer cuidados adicionais para lidar com situações como o conflito de resolução para atributos ou métodos. Quando herança múltipla é suportada, o esquema de tipos de objetos passa a ser organizado como uma malha ou grafo de tipos.
Em um sistema gerenciador de base de objetos, a modificação de um tipo implica na modificação do esquema de dados. Em um sistema gerenciador de banco de dados tradicional, modificações no esquema eram ações que afetavam extremamente as aplicações, muitas vezes necessitando de processamento off-line para converter os dados de um esquema para o outro. Em um sistema gerenciador de base de objetos, esta evolução de esquemas deve ocorrer de forma mais natural. São três as categorias de modificações que implicam em evolução do esquema: mudanças em componentes (atributos ou métodos) de um tipo, mudanças na hierarquia (ou malha) de tipos, ou mudanças na definição de tipos, através de modificação de nome, inclusão ou remoção de tipos.
3.2.4 Consultas
Um dos principais aspectos a se considerar na manipulação de bases de dados é o mecanismo oferecido para expressar operações sobre os dados. Em geral, aplicações usando bases de dados são desenvolvidas em alguma linguagem de programação e integram expressões de manipulação de dados aos programas. A diferença entre estas linguagens de programação e de manipulação de dados dá origem ao problema de “descasamento de impedâncias” (impedance mismatch) entre as linguagens, que é endereçado de maneiras distintas em diversos sistemas gerenciadores de base de objetos. Entretanto, nenhuma destas abordagens, descritas a seguir, consegue eliminar completamente o problema do descasamento de impedâncias entre as aplicações.
Uma estratégia de integração de linguagens é o query download, onde todos os objetos relevantes para a operação da aplicação são recuperados da base de dados, traduzidos para a representação adequada para a linguagem de programação, manipulados, retraduzidos e armazenados de volta à base de dados. Uma variante deste esquema limita a operação a um único objeto por interação, com o objetivo de maximizar a concorrência de acesso à base de dados. Outra alternativa é armazenar objetos da linguagem de programação como BLOB na base de dados, que nesta situação não conteria nenhuma informação sobre a estrutura do objeto.
Em outra direção de integração, alguns sistemas estendem linguagens de manipulação de dados com construções procedimentais. Sybase adotou esta abordagem ao estender SQL com construções de controle de execução para sistemas relacionais. Outros sistemas oferecem novos tipos de dados na linguagem de programação para refletir tipos e operações referentes à base de dados.
Uma abordagem mais transparente de integração entre linguagens de programação orientadas a objetos e sistemas gerenciadores de base de objetos é a incorporação de mecanismos de persistência de objetos à linguagem de programação. Nesta situação, a base de dados é utilizada de forma implícita e transparente como meio de manutenção do estado de objetos da aplicação entre sessões.
Métodos de especificação de persistência em sistemas gerenciadores de base de objetos podem ser por tipo, por invocação explícita ou por referência. Na especificação por tipo, apenas alguns tipos pré-definidos são persistentes. Uma crítica a este modelo é que persistência e especificação de tipos são conceitos ortogonais, e que associar persistência a apenas alguns tipos fere essa ortogonalidade. Na especificação de persistência por invocação explícita, a aplicação solicita explicitamente ao sistema gerenciador de base de objetos o armazenamento persistente do objeto em questão. Na especificação por referência, um ou mais objetos (as raízes) são declarados como persistentes, e todos os objetos por eles referenciados tornam-se automaticamente persistentes. Este é o mecanismo mais transparente, mas que exige mais em termos de processamento da parte do sistema gerenciador de base de objetos.
Outro aspecto importante relativo a consultas em sistemas gerenciadores de base de objetos refere-se ao tipo de resultado que uma consulta gera. Em sistemas relacionais, existe um único tipo (a relação); portanto, operandos e resultados de consultas são relações. Em sistemas gerenciadores de base de objetos, o grau de liberdade é maior. Alguns sistemas podem limitar a resposta obtida a alguns tipos específicos, embora a tendência seja permitir a manipulação de resultados abertos — literal, objeto, coleções de objetos ou até mesmo relações (arranjos tabulares de dados).
Consultas envolvendo múltiplos objetos necessitam de alguma forma de mecanismo de junção. Duas variantes da operação de junção em sistemas gerenciadores de base de objetos são a junção por referência e a junção por valor. A junção por referência utiliza associações definidas na base de objetos para obter objetos associados. A junção por valor, assim como a junção de sistemas relacionais, é realizada sobre valores de atributos que compartilham um domínio comum, não necessitando, portanto de associações explícitas para sua realização.
3.2.5 Concorrência e recuperação
Como dados em uma base de dados são persistentes e usualmente compartilhados por várias aplicações e/ou usuários, é preciso que haja mecanismos para controle de acesso concorrente, de recuperação de dados em caso de operações falhas e de manutenção de integridade dos dados. Em um sistema gerenciador de base de objetos, diferentemente do que ocorre em sistemas tradicionais, uma aplicação manipula de forma natural dados transientes e dados persistentes, o que pode criar dificuldades adicionais na manutenção de consistência dos dados.
Operações sobre objetos persistentes são usualmente definidas no escopo de transações, assim como ocorre em sistemas gerenciadores de banco de dados tradicionais. Uma possível diferença é que sistemas gerenciadores de base de objetos podem (e geralmente o fazem) incluir transações longas e, em alguns casos, transações aninhadas.
Versões oferecem um mecanismo alternativo para controle de concorrência. Através do mecanismo de versões libera-se o sistema de manter uma única cópia de um objeto na base, o que alivia uma eventual degradação que poderia ocorrer com a incorporação de transações (e consequentemente lock) longas. Com versões, evoluções alternativas nos estados dos objetos são permitidas. Um conceito relacionado a este é configuração, um conjunto de versões de objetos mutuamente consistente.
Configurações equivalem a snapshots (ou visões instantâneas) consistentes da base de objetos.
3.2.6 Implementação de identificadores
Um dos fatores mais importantes no desempenho de um sistema gerenciador de base de objetos é a forma de execução da representação de seus objetos, como são armazenados, identificados e recuperados da base de dados.
A representação de identificadores de objetos pode ser física ou lógica. A representação física contém o endereço real do objeto, como ocorre em linguagens de programação orientadas a objetos onde objetos são identificados por sua posição na memória. A representação lógica envolve algum mecanismo de mapeamento entre uma representação interna e o endereço do objeto As quatro abordagens básicas de implementação de identificadores são utilização simples do endereço, um identificador físico; utilização de endereços estruturados, que contém uma componente lógica e outra física; utilização de surrogates, identificadores lógicos que são mapeados para endereços físicos através de um índice ou de uma tabela; e a utilização de surrogates tipados, onde a informação sobre o tipo do objeto é incluída no identificador lógico.
A unicidade de um identificador de objeto é um aspecto fundamental para a manutenção da consistência de uma base de objetos. Identificadores de objetos são utilizados tanto pelas aplicações como pela própria base de objetos, para representar associações entre objetos. O mecanismo para garantir unicidade pode variar entre execuções distintas. Alguns sistemas garantem que identificadores de objetos removidos não são reaproveitados; outros buscam garantir unicidade entre múltiplas bases de objetos interligadas em rede, incorporando o endereço da máquina servidora no identificador de objeto.
Identificadores de objetos puramente físicos, por endereços, oferecem o melhor potencial de desempenho para recuperação de objetos. Porém, fixar a posição do objeto na base torna-a menos flexível, dificultando operações como relocação de objetos. A relocação pode ser necessária para ampliar o espaço de armazenamento associado a um objeto ou realizar uma compactação ou reclustering da base de objetos. Por este motivo, endereços físicos não são utilizados na prática. ONTOS e Objectivity/DB utilizam endereços estruturados, GemStone e POSTGRES utilizam surrogates, e ORION e Itasca adotam surrogates tipados.
Além da referência a objetos por identificadores de objetos, diversos sistemas oferecem a possibilidade de se localizar um objeto através de atributos chaves. Em geral, a implementação deste mecanismo em sistemas gerenciadores de base de objetos é similar àquela de sistemas tradicionais, onde valores de atributos chaves são mapeados a identificadores de objetos através de índices hash ou B-trees.
3.2.7 Swizzling
Swizzling é o processo de conversão entre a representação persistente do objeto, na base de objetos, e sua representação dinâmica, na linguagem de programação orientada a objetos adotada pela aplicação, onde o objeto será efetivamente manipulado. Evidentemente, é um processo importante na manipulação de objetos, sendo determinante para o desempenho do sistema gerenciador de base de objetos.
A conversão que deve ocorrer através de Swizzling envolve tipicamente traduções de referências e, eventualmente, modificações na estrutura e no formato de representação de dados. Referências dinâmicas são tipicamente ponteiros na linguagem de programação, e não identificadores de objetos.
A tradução de identificadores de objetos para referências a objetos na linguagem de programação é a principal atividade desempenhada durante o Swizzling. Mudanças na estrutura podem ocorrer através da incorporação de cabeçalhos e campos para utilização em tempo de execução. Mudanças na representação interna dos dados podem ser necessárias principalmente quando a base de objetos é compartilhada em ambientes heterogêneos.
Swizzling pode ocorrer em momentos distintos, de acordo com a implementação adotada para este mecanismo. Tipicamente, uma das quatro abordagens a seguir é adotada:
a. A conversão ocorre no momento em que o objeto é transferido da base de objetos para o espaço de memória da aplicação (checkout).
b. A conversão ocorre no momento em que o objeto, já transferido para a memória, é referenciado pela primeira vez pela aplicação.
c. A conversão ocorre no momento em que a aplicação a solicita explicitamente.
d. A conversão ocorre quando não é possível reaproveitar um endereço físico designado anteriormente, o qual é registrado também na base de dados.
Esta última abordagem é adotada em ObjectStore, que busca explorar a grande capacidade de endereçamento virtual dos processadores modernos para alocar um objeto sempre à mesma posição de memória virtual.
3.2.8 Granularidade de transferência
Bases de objetos podem transferir informação entre o disco e a memória em unidades de dimensão, ou granularidades, distintas. Tipicamente, as granularidades adotadas são páginas, objetos ou resultados de consultas.
A abordagem mais utilizada nas implementações de sistemas gerenciadores de base de objetos é passar para a aplicação uma imagem do disco, adotando granularidade de uma página.
Esta abordagem simplifica o trabalho do servidor de páginas, onde o processamento será mínimo.
Entretanto, o tráfego de dados pela rede é ampliado, pois uma página pode conter mais informação que a solicitada pela aplicação.
Quando a granularidade adotada é um objeto ou um resultado de consulta, o tráfego de dados pela rede é reduzido, pois se garante que a aplicação estará recebendo apenas o que foi solicitado.
Entretanto, exige-se nessas situações que o servidor de objetos já realize algum processamento sobre a base de objetos. Se o sistema gerenciador de base de objetos for compartilhado por muitas aplicações, um alto número de requisições simultâneas pode ter impacto significativo no desempenho do servidor.
A abordagem de imagem do disco, embora eficiente, pode apresentar riscos à integridade dos dados presentes na página. Este risco está presente principalmente quando a aplicação utiliza uma linguagem de programação onde é permitido aos programas examinar e alterar qualquer posição de seu espaço de memória, como ocorre em C#, por exemplo. Em tais situações, seria necessário que o sistema gerenciador de base de objetos impusesse mecanismos adicionais de manutenção da integridade dos dados em uma página manipulada pela aplicação, evitando sua degradação através de ações inadvertidas ou maliciosas. Entretanto, as implementações correntes de sistemas gerenciadores de base de objetos não incorporam mecanismos com este fim.
Citei como uma das atividades durante o Swizzling a incorporação de informação para manipulação de objetos em tempo de execução. Informação típica de runtime para um objeto inclui o mapeamento de um identificador de objeto para endereço físico, o registro de quais objetos estão na memória da aplicação, manutenção de dirty bits para indicar se objetos foram atualizados ou apenas consultados, e contadores de referências para sustentar atividades internas de swapping e garbage collection. Abordagens para manipulação deste tipo de informação incluem a manutenção de tabelas em memória, utilização de descritores de objetos e incorporação de status bits no próprio objeto.
3.2.9 Atributos
A forma de implementação mais simples para a representação de atributos de um objeto seria utilizar relações, com campos de dimensão fixa, como foi proposto por alguns protótipos iniciais de sistemas gerenciadores de base de objetos. Entretanto, esta alternativa limita severamente a flexibilidade de representação para objetos, não permitindo operar de modo eficiente com atributos de dimensões variáveis, com coleções com quantidade variável de elementos, a evolução de esquema pela inclusão de atributos e o armazenamento eficiente para atributos não utilizados por um objeto.
Listas de propriedades oferecem um mecanismo mais versátil de implementação de atributos de um objeto. Uma lista de propriedades é composta por elementos contendo três campos, representando um identificador de atributo, o tamanho do valor do atributo e o valor. Este mecanismo é flexível, porém demanda um maior grau de processamento da parte dos métodos que manipulam a estrutura interna do objeto.
Herança é outro aspecto que traz impacto na representação de atributos. Em sistemas onde apenas herança simples é permitida, o mecanismo de lista de propriedades é ainda adequado. Neste caso, a lista de propriedades de um objeto é composta pela concatenação dos atributos do tipo do objeto com os atributos do tipo de objeto ancestral, e assim recursivamente até encontrar os atributos do tipo de objeto que é a raiz da hierarquia. Para lidar com herança múltipla, mecanismos mais elaborados são necessários para estabelecer prioridades na concatenação e resolver conflitos entre tipos ancestrais com atributos de mesmo nome.
Manipulação de coleções é outro aspecto crítico em sistemas gerenciadores de base de objetos, sendo esse mecanismo amplamente utilizado na descrição de estrutura de atributos de objetos e no retorno de consultas. Como coleções podem ser demasiadamente extensas e/ou conter objetos grandes, é preciso oferecer mecanismos que permitam manipulá-las de modo mais eficiente. O principal mecanismo adotado é a utilização de objetos iteradores. Um iterador é um objeto temporário que contém referências aos membros da coleção, oferecendo métodos tais como produzir o próximo elemento da coleção (lista) ou buscar o -ésimo elemento da coleção (arranjo).
A manipulação de atributos do tipo BLOB é usualmente implementada através de interfaces stream. Assim como iteradores, um stream permite referenciar objetos sem que esses estejam completamente concretizados em memória, com métodos para posicionar, ler e escrever blocos de dados binários. Alternativas para a manipulação de BLOB incluem a paginação por demanda e utilização de piece streams. Na paginação por demanda, a aplicação tem o objeto completo em memória virtual, sendo que páginas do objeto são transferidas para a aplicação à medida que seus bytes são referenciados.
Um piece stream é um mecanismo de stream com facilidades adicionais que permitem a atualização de conteúdo do BLOB, tais como inserção e remoção de bytes na posição corrente.
3.2.10 Associações
A execução de relacionamentos não precisa refletir diretamente a forma como a aplicação os define conceitualmente. A estratégia de execução pode depender da multiplicidade das associações.
Por exemplo, um relacionamento um-para-muitos pode ser representado por contiguidade física, por indexação, por ligação ou através de objetos intermediários criados pelo sistema gerenciador de base de objetos.
Um tipo de associação implícita entre os elementos de uma coleção é a ordenação. Apesar de estar presente em muitas aplicações, nem sempre este mecanismo é suportado em sistemas gerenciadores de base de objetos, onde apenas coleções do tipo conjunto (assim como relações, sem critérios de ordenação entre elementos) são suportadas. A importância da ordenação da coleção é reconhecida de longa data; o modelo CODASYL definia associações de ordenação manual (critério de ordenação estabelecido pela aplicação) e automática (estabelecido pelo sistema sobre algum atributo da coleção).
Outro aspecto importante na execução de associações é a manutenção da integridade referencial.
O mecanismo mais amplamente adotado para este fim é a utilização de pares de atributos inversos. Assim, se a aplicação define uma referência de um objeto “a” para um objeto “b”, denotada a  b, o sistema gerenciador de base de objetos cria internamente a referência b  a. Alternativamente, o sistema pode implementar um contador de referências para o objeto, só permitindo sua remoção quando o valor deste contador for nulo.
3.2.11 Clustering
A incorporação do conceito de objeto complexo em sistemas gerenciadores de base de objetos introduz grande flexibilidade de estruturação dos dados. Por outro lado, a recuperação de objetos complexos pode introduzir degradação no desempenho dos sistemas. Afinal, o conteúdo de um objeto complexo é composto por outros objetos, que potencialmente podem estar distribuídos em diversas páginas espalhadas pelo disco. Assim, recuperar o conteúdo de um objeto complexo pode acarretar em várias solicitações de páginas do servidor para o cliente.
Clustering é um mecanismo que pode ser adotado para minimizar esta degradação no desempenho.
Simplesmente colocado, o conceito de clustering é adotar alguma estratégia de alocação de objetos no sistema de armazenamento de modo a minimizar a quantidade de páginas necessárias para manipular objetos. As estratégias de clustering mais utilizadas são:
a. Objetos complexos: adota o relacionamento de agregação para identificar objetos que devem ser armazenados próximos, preferencialmente, na mesma página ou em páginas contíguas.
b. Referências: adota a existência de relacionamentos quaisquer entre objetos para direcionar a proximidade de armazenamento. A estratégia de clustering por objetos complexos é um caso especial desta estratégia.
c. Tipos de objetos: adota o critério de aproximar o armazenamento de objetos de uma mesma classe.
Este é um critério equivalente ao adotado pela maior parte dos sistemas gerenciadores de banco de dados relacionais, onde tuplas de uma mesma relação são armazenadas contiguamente.
d. Índices: adota o valor de um atributo como critério de ordenação dos objetos, e aproxima o armazenamento de objetos com valores próximos neste atributo.
e. Definição do usuário: utiliza um indicativo da aplicação, em tempo de execução, para buscar a melhor posição de armazenamento de um objeto. Um exemplo de implementação utiliza um identificador de um objeto existente como parâmetro na criação de um novo objeto, indicando que os dois devem ser armazenados em posições próximas.
A seleção de um critério de clustering deve depender da forma de recuperação mais adotada para o objeto na aplicação. Por exemplo, em sistemas CAD provavelmente a estratégia de objetos complexos seria a preferencial, enquanto que para uma aplicação comercial, envolvendo sequências de recuperações em ordem alfabética, a estratégia de índices seria a mais adequada.
3.2.12 Evolução de esquemas
Em grande parte dos sistemas gerenciadores de base de objetos, o esquema de dados é em si armazenado como um objeto. Entretanto, este objeto nem sempre é diretamente manipulável pela aplicação em tempo de execução; restrições de acesso são impostas como forma de manutenção da integridade da base de objetos. Mudanças no esquema devem obedecer a tais restrições, determinando como esquemas podem evoluir.
Há quatro estratégias básicas que determinam como um esquema pode evoluir: tipo de uma escrita, atualização imediata, atualização posterior, e mapeamento de esquema.
A estratégia de tipos de uma escrita (ou tipos write-once) é a abordagem mais simples, que determina que qualquer tipo que já contenha pelo menos uma instância não pode ser modificado.
Modificações no tipo, tal como a inclusão de um novo atributo, deve ser explicitamente desempenhada pela aplicação através da criação de um novo tipo e cópia do conteúdo de objetos já existentes para objetos do novo tipo.
A estratégia de atualização imediata é a mais adotada em sistemas gerenciadores de base de objetos correntes. Nesta estratégia, qualquer modificação no tipo de um objeto é imediatamente refletida para os objetos. Assim, a inclusão de um novo atributo em um tipo faria com que todos os objetos daquele tipo tivessem sua estrutura atualizada para conter um campo adicional contendo o valor nulo.
Na estratégia de atualização posterior, a estrutura de um objeto cujo tipo tenha sido modificado não é alterada a não ser no primeiro momento em que o objeto é acessado após a alteração do tipo.
Nesta abordagem, é preciso que o sistema gerenciador de base de objetos mantenha informação histórica sobre a evolução de esquemas e sobre procedimentos de conversão para poder manter a consistência da base.
A estratégia de mapeamento de esquema equivale a uma estratégia de atualização posterior onde o momento de atualização é postergado indefinidamente, até o momento em que uma reorganização da base de objetos seja explicitamente solicitada. Nesta estratégia é preciso manter os mapas de conversão entre todas as possíveis versões de esquema, o que possibilitaria que usuários pudessem ter visões de um mesmo objeto sob diferentes versões de esquema. Entretanto, a execução de tal estratégia seria extremamente complexa, não tendo sido implementada em nenhum sistema gerenciador de base de objetos até o momento.
1.3 DIFERENÇA ENTRE BANCO DE DADOS ORIENTADO A OBJETO E BANCO DE DADOS RELACIONAL:lol!: 
Banco de Dados Orientado a Objetos e Banco de Dados Relacionais 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 Banco de Dados Relacional (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 Banco de Dados Orientado a Objeto (BDOO) possui três pilares principais: herança, polimorfismo e encapsulamento. 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.
3.4 OBJECT RELATIONAL MAPPER – ORM (MAPEAMENTO OBJETO RELACIONAL) 

Mapeamento objeto-relacional (ORM: Object-relational mapping) é uma técnica de desenvolvimento utilizada para reduzir a impedância da programação orientada aos objetos utilizando bancos de dados relacionais. As tabelas do banco de dados são representadas através de classes e os registros de cada tabela são representados como instâncias das classes correspondentes.
Com esta técnica, o programador não precisa se preocupar com os comandos em linguagem SQL; ele irá usar uma interface de programação simples que faz todo o trabalho de persistência.
Não é necessária uma correspondência direta entre as tabelas de dados e as classes do programa. A relação entre as tabelas onde originam os dados e o objeto que os disponibiliza é configurada pelo programador, isolando o código do programa das alterações à organização dos dados nas tabelas do banco de dados.
A forma como este mapeamento é configurado depende da ferramenta que vamos usar.
3.4.1 Desenvolver utilizando o Modelo Orientado a Objetos com o Banco de Dados Relacionais
Nos últimos anos, o paradigma de orientação a objetos vem se desenvolvendo na área de programação. Várias experiências têm mostrado que esse paradigma aumenta a produtividade dos programadores a modularidade dos programas. Na área de Bancos de Dados (BD), sabe-se que os modelos de dados clássicos, como por exemplo o modelo relacional, não são apropriados para descrever e manipular os dados das chamadas "novas aplicações", tais como projeto assistido por computador (CAD), manufatura de produtos (CAM), produção de software (CASE), automação de escritórios (OIS), aplicações médicas e científicas, representação do conhecimento para aplicações de inteligência artificial, etc. Os dados dessas aplicações são muito complexos e evolutivos, sendo necessária a modelagem não somente de sua estrutura, mas também de seu comportamento.
Para compensar estas deficiências, vários modelos de dados tem sido propostos. Primeiramente, os estudos na área foram dirigidos para os modelos semânticos e extensões do modelo relacional. Mais recentemente, surgiram modelos que procuram enfatizar os aspectos comportamentais dos objetos que manipulam, sendo baseados principalmente em conceitos oriundos da programação orientada a objetos. Isso se deve ao fato de que a orientação a objetos auxilia a lidar com a complexidade nas mais diferentes aplicações. Esses modelos são denominados modelos de dados orientados a objetos.
Os modelos de dados orientados a objetos são mais expressivos e flexíveis que o modelo relacional. 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. Por outro lado, os modelos orientados a objetos foram projetados para a criação e representação de estruturas bem mais complexas de uma maneira coerente e uniforme.
Apesar de inúmeras vantagens encontradas ao se utilizar o paradigma de orientação a objetos, ainda não existem SGBD OO comercialmente disponíveis para aplicações de grande porte. Os SGBD relacionais ainda representam o estado da arte na tecnologia tradicional de bancos de dados e são os mais estudados na literatura. Suas maiores vantagens são a simplicidade e a portabilidade entre execuções. Esses sistemas continuam a dominar o mercado, sendo utilizados nas mais diversas aplicações.
Entretanto, os conceitos de orientação a objetos podem ser utilizados como mecanismos de abstração para o projeto de bancos de dados relacionais. A modelagem orientada a objetos, por utilizar conceitos mais claros e naturais, permite produzir bancos de dados relacionais mais adequados às aplicações do mundo real, evitando os problemas de normalização frequentemente associados ao projeto relacional. Além disso, a modelagem orientada a objetos aumenta a integração entre os dados e as aplicações. Dessa forma, uma abordagem orientada a objetos para o projeto de lógico de bancos de dados relacionais permite que as aplicações sejam projetadas de forma integrada, em que dados e operações podem ser projetados ao mesmo tempo.
Com o crescimento do mercado, as linguagens orientadas a objetos começaram a dar maior enfoque em um novo paradigma, a análise, projeto e codificação de sistemas. É claro que os bancos de dados não poderiam ficar imunes a esse novo modo de encarar o desenvolvimento de sistemas. Houve, entretanto, um desenvolvimento mais rápido nas linguagens orientadas a objetos (OO) que nos Sistemas Gerenciadores de Bancos de Dados Orientados a Objetos (SGBD OO), o que deixou os desenvolvedores e administradores de BD numa situação curiosa: mesmo querendo adotar a orientação a objetos, eles têm que parar na hora de manipular seus dados. Linguagens visuais como o JAVA, por exemplo, embora sejam orientada a objeto em sua essência, acessam os bancos de dados de maneira convencional, ou seja, não orientada a objetos e usando SQL. Com isso, um mesmo programa tem uma parte OO e uma parte estruturada. Alguns autores dizem que quando linguagens OO utilizam SQL embutido para acesso a dados remotos em um SGBD, as facilidades e vantagens da orientação a objetos presentes nessas linguagens não são exploradas totalmente.
Outro ponto importante, é saber se a aplicação da OO no armazenamento estático de dados será tão mais eficiente para dados convencionais (strings e números) como parecem ser para dados especiais como som, imagens e textos desestruturados. Caso ela não represente um grande avanço em relação aos SGBD relacionais também nessa área, haverá sempre a possibilidade de termos um grande uso de SGBD OO para armazenamento de dados multimídia e os velhos e bons SGBD relacionais para dados convencionais, o que não representaria pouco.
Enquanto o armazenamento de dados OO não se tornar comercialmente disponível apenas, a opção mais adequada é desenvolver o sistema utilizando OO na análise e no projeto, e posteriormente armazenar os dados relacionalmente.
3.4.2 ORM (Object Relational Mapper) e sua utilização:lol!: 
ORM (Object Relational Mapper) ou mapeador objeto relaciona, é um tipo de ferramenta muito utilizada hoje em dia, com o propósito de unir o mundo orietado a objetos e o mundo 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 ú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. Existem ótimos ORM como Hibernate, NHibernate, Entity Framework e etc.

Tudo começa como mostrado na figura acima, existem dois mundos: o Relacional e o Orientado a Objeto, 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 Bados, 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 Banco de Dados e cada ORM tem suas particularidades, para gerar o SQL referente à 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 se deixa de escrever os comandos SQL para deixar que o próprio ORM, faça isto por você.
3.4.3 Ferramentas Disponíveis no Mercado e Análise dos melhores ORM (Object-Relational Mapping) para plataforma .NET
Um ORM, 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 de Dados.
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 (BDR). 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 de Dados, query de SQL a todo momento, preservando as características de orientação a objetos da linguagem face à natureza relacional dos bancos de dados atuais.
3.4.3.1 Vantagens e Desvantagens de se usar um ORM
A grande sacada 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 às 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 mudarmos 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.
Você escreve menos código e programa com muito mais produtividade. Seu código fica mais elegante. É mais fácil de dar manutenção no projeto. Melhora a padronização da sua aplicação.
Exemplo de um código em .NET usando ORM:
Usuario.AddNew();
Usuario.FirstName = this.txtFirstName.Text;
Usuario.LastName = this.txtLastName.Text;
Usuario.Save();
Exemplo de um código em .NET usando classes nativas do .NET Framework:
strConn = "string de conexão aqui";
SqlConnection objCon = new SqlConnection(strConn);
SqlCommand objComand = objCon.CreateCommand();
objComand.CommandText = "insert into Usuario (FirstName , LastName ) values (@FirstName , @LastName )";
objComand.CommandType = CommandType.Text;
objComand.Parameters.Add("@FirstName ", txtFirstName.Text );
objComand.Parameters.Add("@LastName ", txtLastName.Text );
objComand.ExecuteNonQuery();

É importante ressaltar que dificilmente você achará uma solução que substitua 100% das classes do ADO.NET, eventualmente você será obrigado a fazer uma gambiarra no meio do caminho para obter determinados resultados. No entanto, seguramente os melhores Frameworks resolverão mais de 95% das suas necessidades.
Como nem tudo são flores, temos algumas desvantagens que existem quando se decide usar algum tipo de ORM. A primeira grande desvantagem é o desempenho. 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. Às 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 se percebe, a complexidade foi elevada.
3.4.3.2 Como escolher um ORM
Estes são uns dos critérios para escolher um ORM para adoção dentro de uma empresa ou projeto.
• Qualidade da documentação;
• Tipo e qualidade do suporte;
• Custo;
• Curva de aprendizado;
• Continuidade (Novos releases do projeto e periodicidade);
• Capacidade de execução de stored procedures do legado;
• Bancos de dados suportados;
• Suporte a querys dinâmicas;
• Suporte a dados hierarquizados;
• DataBind a .Net controls;
• Capacidade de fazer transações;
• Performance;
• Facilidade de manutenção do código (incluindo aí a inteligibilidade do mesmo).
Normalmente, o frameworks que existem atuam como geradores de código criando classes baseadas nas suas tabelas de banco de dados.
Existem vários free e pagos. Os free normalmente carecem de suporte e documentação, os pagos conseguem suprir melhor esta deficiência por um motivo óbvio. Os melhores free são o que possuem amplo apoio da comunidade ou têm um grupo de desenvolvedores bastante ativos distribuindo novos releases num curto espaço de tempo.
Nota minha: Estou referenciando os free como aqueles que você pode usar sem pagar pela licença de uso. Isso não quer dizer que eles sejam Open Source, Software Livre, GPL ou FreeWare nem nada. Veja no site do produto a forma de utilização, licenciamento e distribuição de cada um para saber mais.
3.4.3.3 Análise de alguns dos principais ORM
Procurando no Google e em sites especializados, descobri mais de 40 deles. Boa parte já teve seu desenvolvimento abandonado (a maioria Free), mas os melhores têm conseguido sobreviver.
Eu separei a lista em Inativos, Free e Pagos. Os Inativos são o que não têm tido releases lançados nos últimos anos e tiveram seu desenvolvimento paralisado, provavelmente.
Em caso de dúvidas, baixe o framework e teste-o para ter uma opinião própria.
Produtos Inativo

Produtos Free

Produtos Pagos

Entre os Free, projetos que merecem um acompanhamento:
- NHibernate
- SubSonic
- Codus
- ObjectMapper
O NHibernate é Subsonic são os que têm mais futuro, pelo apoio da comunidade que desenvolve os projetos.
Baseado no Hibernate do JAVA, o NHibernate é Framework extremamente completo e poderoso. Existem alguns geradores de código como o próprio MyGeneratiom e Codus que facilitam o trabalho de configuração do XML.
O SubSonic tem a grande vantagem de a configuração ser quase nula. Ele lê o schema do banco de dados e gera as classes de mapeamento quando você dá o primeiro build no projeto. Os releases são muito rápidos permitindo que diversos bugs sejam corrigidos e as melhorias sejam implementadas num curto espaço de tempo.
Entre os Pagos, os seguintes projetos se destacaram pelo custo/benefício.
- Entity Spaces
- LLBLGen Pro
- eXpress Persistent Objects
O Entity Spaces vale o investimento, pois o produto é excelente por conta da documentação que é muito completa e do suporte que é rápido.

Bom trabalho a todos e não esqueçam que a data limite é 11/10/2013. 

Corsario escreveu:1 DESENVOLVIMENTO:D 
1.1 BANCO DE DADOS ORIENTADO A OBJETO:lol!: 
O SGBD Orientado Objeto é mais adequado para o tratamento de objetos complexos. Esses objetos são classificados como estruturados e não estruturados. Sendo que um objeto complexo não estruturado possui um tipo de dado que requer um grande volume de armazenamento, por adquirir novos tipos de dados para armazenamento de imagens ou textos longos. E os estruturados são definidos pela aplicação de determinados construtores de tipos, como, conjunto (coleções), tupla, lista ou array (ordem) (NAVATHE, 2005).
Conforme Setzer (2005), o desenvolvimento do referido SGBD teve combinação de ideias dos modelos de dados tradicionais e das linguagens de programação orientada a objetos. E, o contexto rico desses objetos é verificado no nível lógico e possui características não encontradas nas linguagens de programações tradicionais, como operadores de manipulação de estruturas, gerenciamento de armazenamento e outros.
Na verdade, para que um sistema de banco de dados seja considerado orientado a objetos, é importante a presença de Identificadores de Objetos (OID), mecanismo de herança (única ou múltipla), objetos complexos e persistência de objetos.
A seguir são apresentados alguns conceitos importantes para a orientação a objetos que foram recomendados para adicionar as funcionalidades de banco de dados às linguagens de programação orientada a objetos.
3.1.1 Objetos Complexos
Quando nos referimos a um objeto, o mesmo possui, caracteristicamente, dois componentes: estado (valores) e comportamento (operações). Assim, é semelhante a uma variável de programa em uma linguagem de programação, exceto que geralmente terá uma estrutura de dados complexa.
Um conceito mais simples relacionado a um objeto é que o mesmo é uma entidade lógica que contém dado e código com o objetivo de manipular esses dados. Os dados são destinados como sendo atributos do objeto, e o código que o manipula é denominado de método. Sendo que um método é uma função que manipula a estrutura de dados do objeto.
Objetos complexos são formados por construtores (conjuntos, listas, tuplas, registros, coleções, array) aplicados a objetos simples (inteiros, booleanos, string). A distinção do modelo OO em relação ao modelo relacional, é que no modelo OO qualquer construtor pode ser aplicado a qualquer objeto, já no modelo relacional este não é o caso, visto que só é possível aplicar o construtor de conjuntos nas tuplas e o construtor de registros nos valores atômicos (ARBEGAUS, 2003). Para tal, existem praticamente dois tipos de objetos complexos em um SGBDOO:
• Objetos embutidos: são caracterizados como “objetos filhos”, que constituem os atributos, que só podem ser acessados pelo seu “objeto-pai”. São resultados da estrutura de agregação ou “todo-parte”. Objetos embutidos não possuem OID próprio e são, em geral, armazenados na mesma estrutura física de seu “objeto pai”. Os mesmos possuem como exemplo os casos dos relacionamentos dependentes, como os “itens de um pedido de venda”. Nesse exemplo, os “itens” são objetos embutidos dos “pedidos de venda”.
• Objetos referenciados: são caracterizados como objetos originários das regras de integridade referencial. Qualquer relacionamento, como por exemplo, de uma “Cidade” com o seu respectivo “Estado” corresponde à criação de um objeto composto do tipo referenciado. Os objetos referenciados possuem OID próprio e podem ser acessados diretamente ou através de seus objetos relacionados.
3.1.2 Identificador de Objetos
No SGBDOO, o OID é dito persistente, ou seja, a identidade do objeto persiste não só entre execuções de programas, mas também durante reorganizações estruturais de dados. A identidade do objeto é geralmente gerada pelo sistema quando o objeto é criado. No entanto, segundo Silva (2001) um OID em SGBDOO não pode ser:
a) Um endereço (como um nome de variável ou referencia de memória de uma linguagem de programação) porque não é externo ao objeto;
b) Uma chave (como chave primária de um BDR) porque não é um valor de dados mutável;
c) Um register ID porque não é uma coluna lógica.
Para Silva (2001) a identidade de objetos tende a eliminar 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.
Para Navathe (2005), a identidade única de cada objeto armazenado na base de dados é geralmente implementada por meio de um identificador de objeto (OID). Sendo que o valor de um OID não é visível para um usuário externo, mas é utilizado internamente pelo sistema, com a finalidade de identificar univocamente cada objeto.
3.1.3 Herança Única e Múltipla
Um conceito essencial no banco de dados OO é que a herança é um tipo de relacionamento entre classes, onde uma classe compartilha (herda) estrutura de dados (atributos) e métodos (operações) de outras classes.
Logo, há dois tipos de herança, que são classificados como herança simples e múltipla. Na herança simples, uma classe é subclasse de apenas uma superclasse. Na herança múltipla, uma classe pode ser subclasse de várias superclasses, herdando variáveis e métodos de várias classes (GONÇALVES, 2008).
As “Classes de Coleção” ou “Classes de Sistema” são exemplos principais das características de herança em um SGBDOO. A maior parte desses SGBD possuem uma coleção própria de classes de objetos, onde estas classes são organizadas numa hierarquia. Na verdade, uma determinada aplicação pode desenvolver sua própria classe e herdar atributos ou métodos de alguma classe do sistema. Logo, as classes de sistema dos SGBDOO implementam os métodos de armazenamento, manipulação, controle de concorrência, entre outros (ARBEGAUS, 2003).
Para Arbegaus (2003), os SGBDOO armazenam as declarações das classes, confeccionando-as como parte do esquema do banco de dados. Logo, uma hierarquia de classes proporciona muito mais flexibilidade para modificar a estrutura de um banco de dados (incluindo novos atributos ou métodos nos objetos) possibilitando a evolução do esquema do banco de dados por meio da adição de novas classes na hierarquia.
3.1.4 Persistência de Objetos
Nas linguagens de programação OO, durante a execução do programa, ao se eliminar um objeto que foi instanciado, ou criado, ele passa a deixar de existir. Esses objetos são denominados como transientes, pois só existem durante a execução do programa e desaparecem quando o programa termina (SETZER, 2005).
Para garantir que um objeto continue persistindo após o término do programa é preciso que o banco de dados OO estenda a existência desses objetos de uma maneira que sejam armazenados de forma permanente na base de dados. Para isso acontecer, deve ser associado a um mecanismo de nomeação, que consiste em dar a um objeto um nome persistente único pelo qual ele possa ser recuperado pelo programa em execução e outros programas. Este nome de objeto persistente pode ser atribuído por meio de um comando específico ou uma operação no programa. Todos os nomes atribuídos aos objetos devem ser únicos dentro de um determinado banco de dados. Portanto, os objetos persistentes nomeados são utilizados como pontos de entrada pelos quais os usuários e as aplicações podem iniciar o acesso ao banco de dados. Com isso, um objeto estará realmente armazenado, e todos os seus componentes também serão tornados persistentes (NAVATHE, 2005).
Na visão de Setzer (2005. p. 280):
A solução mais simples adotada foi a de se estabelecer que a persistência seja uma característica de todos os objetos criados em um processamento. Uma outra foi a de se especificar quais objetos devem ser persistentes, isto é, quando eliminados durante ou no fim do processamento, os valores de seus atributos não são perdidos. Essa é a solução mais flexível, porém mais complexa.
3.1.5 Características
A seguir são algumas características que são importantes em um SGBDOO.
• Tipos abstratos de dados (Classes): É definido como um conjunto de objetos que compartilham a mesma estrutura e o mesmo comportamento (operações). Sendo que um objeto é uma instância de uma classe, ou seja, suas características são definidas na classe a qual foi instanciado (GONÇALVES, 2008).
• Encapsulamento: Essa definição se refere à independência dos dados de um objeto em relação a outros objetos, isto é, nenhum método de um objeto pode obter ou alterar diretamente os dados de outro. Desse modo, o objetivo do encapsulamento é de ocultar detalhes da implementação dos métodos e da estrutura dos atributos (SETZER, 2005).
• Identificador de objeto: Os objetos possuem identificadores únicos que são independentes de seus valores de atributos.
• Polimorfismo ou Sobrecarga de Operador: No conceito de orientação a objetos, dentro de uma classe, operações podem ser sobrecarregadas para serem aplicadas a diferentes tipos de objetos com diferentes implementações (NAVATHE, 2005).
Para Setzer (2005. p. 277):
Uma classe da OO contém um conjunto de dados, denominados de variáveis de classes ou atributos, e um conjunto de procedimentos, denominados de métodos, formando um todo. Os dados de uma classe são globais a todos os métodos da mesma, isto é, estão disponíveis em todos estes. Os dados de uma classe só podem ser alterados pelos métodos da classe (e de subclasses, no mecanismo de herança).
3.1.6 Restrições de Integridade
A maior parte das restrições de integridade existentes nos bancos de dados tradicionais se aplica também aos SGBDOO. No entanto, devido às construções e ao poder de modelagem do modelo de dados orientado a objetos, algumas restrições deixam de ser relevantes, outros adquirem formas diferentes, logo os BDOO acrescentaram outros tipos de restrições e especificações de integridade (ARBEGAUS, 2003). Para tal, as restrições de integridade são classificadas como Restrições de Integridade de Chave, Restrições de Integridade Referencial, Restrição Existencial, Restrição NOT NULL, Restrições de Pré-Condições e Pós-Condições de Métodos e Restrições de Cobertura.
3.1.6.1 Restrições de integridade de chave
Nos Bancos de Dados Relacionais é frequente a especificação de chaves para as relações, com o objetivo de identificar exclusivamente as tuplas de uma relação tanto em nível físico quanto em nível lógico, com o intuito de otimizar os processos de consulta. No entanto, nos BDOO é função do OID (object ID) identificar exclusivamente em nível físico as instâncias de uma classe e, para identificação em nível lógico; os BDOO permitem que sejam definidas chaves para uma determinada classe. Nos BDOO as chaves também otimizam os processos de consulta.
3.1.6.2 Restrições de integridade referencial
Os objetos de um banco de dados normalmente estão relacionados com outros objetos no banco de dados. Da existência das relações vem à necessidade da integridade referencial, que tem por objetivo assegurar que objetos não contenham relacionamentos com objetos que não existam mais no banco de dados. As especificações de restrição de integridade referencial garantem que não haja referências “pendentes” para objetos de uma classe.
Referente ao conceito desta restrição, o que distingue o modelo relacional do modelo OO é que, no modelo relacional, o mecanismo mais utilizado para referenciar objetos entre si é o da chave estrangeira, que relacionam os objetos pelos valores de seus atributos. Logo, nos SGBDOO que permitem o conceito de OID do objeto, não há necessidade de restrições de integridade do tipo “chave estrangeira”, visto que o OID permite referenciar objetos diretamente.
3.1.6.3 Restrição de integridade existencial
As restrições existenciais suportam somente sistemas que executam o conceito de OID, a mesma tem a finalidade de assegurar que um objeto compartilhado referencialmente possui um domínio “ativo” (um grupo específico de objetos que no momento existem em função de determinada condição) no qual ele deve existir. Por exemplo: se numa locadora de livros possui um sistema de folha de pagamento multi-empresa e no cadastro de empresas do sistema existe um campo denominado “Telefone”, logo, consiste numa restrição existencial certificar, que todo o telefone informado no campo “Telefone Comercial” do cadastro de funcionários é um telefone existente no domínio ativo do cadastro de empresas (telefones cadastrados nas empresas).
3.1.6.4 Restrição not null
Para um SGBDOO suportar restrições NOT NULL, ele será obrigado a suportar valores NULL. Um valor referente à NULL define que este valor não existe ou está indisponível. Quando uma restrição NOT NULL é definida para um atributo, a faixa de valores que esse atributo pode receber corresponde à faixa especifica para o tipo definido para o atributo. Portanto, os valores NOT NULL não são aceitos, como um valor válido, porque são permitidos apenas valores correspondentes à faixa de valores determinados para o atributo.
3.1.6.5 Restrições de pré-condições e pós-condições de métodos
As restrições de pré-condições permitem a definição de certas restrições nas variáveis de instância que devem ser satisfeitas, para que um determinado método possa ser executado. Já as restrições de pós-condições permitem a definição de outras restrições que devem ser cumpridas depois da execução do método.
3.1.6.6 Restrições de cobertura
As restrições de cobertura determinam que uma superclasse não possa possuir instâncias que não sejam elementos de determinado grupo de suas subclasses. Uma maneira de obter tal restrição consiste em definir a superclasse como sendo classe abstrata. Desta forma não seria possível criar uma instância da superclasse, somente de suas subclasses. Porém, podem existir situações onde seja necessário instanciar uma superclasse, mas mesmo assim manter a restrição de cobertura, sendo que o sistema iria levantar uma exceção somente se esta instância criada fosse salva como um elemento da superclasse e não como um elemento de uma das subclasses de cobertura.
1.2 APLICAÇÃO E MECANISMO DE FUNCIONAMENTO DO BDOO:lol!: 
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.
A seguir vou detalhar a abordagem de modelagem utilizada pela orientação a objetos.
3.2.1 Objetos e Atributos
Na orientação a objetos, objetos têm uma identificação única que não depende de valores de seus atributos. Esta identificação de objeto (OID) é utilizada para referências a objetos, tanto internas como (possivelmente) externas. Deste modo, limitações relacionadas ao processamento de chaves (primárias, “estrangeiras”) em sistemas de banco de dados relacionais não estariam presentes em sistemas de banco de dados orientados a objetos.
Não obstante, o conceito de um atributo chave está presente em muitas aplicações. Deste modo, apesar de não ser um conceito da orientação a objetos, vários sistemas gerenciadores de base de objetos oferecem a definição de atributos chaves como um mecanismo de acesso adicional ao identificador de objeto, mais próximo da compreensão dos usuários e oferecendo as mesmas restrições de integridade presentes em sistemas gerenciadores de banco de dados relacionais.
Atributos de objetos estão presentes em qualquer sistema gerenciador de banco de dados, sendo que em sistemas tradicionais usualmente tais atributos estão restritos a valores literais e atômicos.
Uma diferença em sistemas gerenciadores de base de objetos está na maior flexibilidade oferecida para a definição destes atributos, que podem simples ou complexos.
Atributos simples são aqueles cujos valores são literais. Em muitas aplicações, valores multimídia são considerados atributos simples, onde o BLOB referente ao objeto multimídia é considerado um valor literal, atômico e não estruturado. Um sistema gerenciador de banco de dados multimídia é essencialmente um sistema gerenciador de base de objetos onde os dados multimídia recebem tratamento diferenciado, não sendo considerados simples BLOB literais.
Atributos complexos podem ser de três tipos: referências, coleções ou virtuais. Referências ou associações estabelecem relacionamentos entre objetos, tendo como valores identificadores de objetos. Um aspecto fundamental em sistemas gerenciadores de base de objetos é a manutenção da consistência entre referências a objetos.
Atributos complexos do tipo coleção são utilizados para definir conjuntos, listas ou arranjos de valores. Coleções são exemplos de tipos parametrizados presentes em sistemas gerenciadores de base de objetos; os três tipos citados são as construções parametrizáveis fundamentais, porém outras podem estar presentes em distintas execuções.
Atributos virtuais ou derivados são aqueles cujos valores não estão explicitamente armazenados na base de dados, mas ao invés são computados através de procedimentos. Em geral, tais atributos são definidos como read-only, sendo raro o oferecimento de mecanismos para atualizar seus valores.
3.2.2 Aspectos comportamentais
Um sistema gerenciador de base de objetos precisa oferecer mais que simplesmente novos mecanismos de estruturação de dados. Além da orientação a objetos estrutural, é preciso suportar a orientação a objetos comportamental, que pode ser obtida através da definição de métodos, procedimentos que permitem encapsular a semântica de um objeto. Em geral, atributos de um objeto é propriedade privada e exclusiva do objeto, sendo que apenas através dos métodos públicos a informação associada ao objeto pode ser manipulada. Este mecanismo de encapsulação é fundamental para atingir independência de dados em sistemas gerenciadores de base de objetos.
A definição estrita de encapsulação exige a satisfação de três critérios:
a. Apenas métodos podem ser públicos;
b. Métodos são definidos em uma linguagem procedimental;
c. Métodos podem manipular apenas dados do próprio objeto.
Esta definição é satisfeita em Smalltalk. Há, no entanto diversas outras linguagens de programação orientada a objeto e sistemas gerenciadores de base de objetos que relaxam uma ou mais destas restrições para oferecer um melhor desempenho de execução às custas de se aceitar um grau menor de encapsulação.
A representação de comportamento em sistemas gerenciadores de base de objetos permite definir dados ativos, que incluem os atributos derivados, regras e agentes. Regras ou triggers são definidas como pares padrão-ação, onde as ações são ativadas quando modificações à base de dados tornam verdadeiro o predicado expresso no padrão da regra. Restrições de integridade são casos particulares de regras onde as ações estão limitadas a sinalizações de condições de erro. Agentes são caracterizados por processos associados ao sistema gerenciador de base de objetos, porém independentes, podendo realizar ações que extrapolam o ambiente da base de dados, tipo enviar uma mensagem por correio eletrônico.
3.2.3 Tipos e Herança
Objetos com estrutura similar são agrupados em classes, sendo que o tipo do objeto é definido através de uma declaração de classe. Usualmente, tipos são criados através de uma linguagem de definição de dados ou, mais especificamente em sistemas gerenciadores de base de objetos, através de uma linguagem de definição de objetos. Uma diferença entre uma linguagem de definição de dados e uma linguagem de definição de objetos é que esta última pode permitir como já observada, a definição de procedimentos associados à estrutura, como no caso de atributos virtuais, incorporando assim aspectos de linguagem de manipulação de dados.
Um conceito avançado que pode estar presente um uma linguagem de definição de objetos é o conceito de herança, que permite definir novos tipos de objetos a partir de tipos já existentes. Herança é um mecanismo de execução do conceito de generalização, importante para bancos de dados como ressaltado no trabalho de Smith e Smith sobre abstração de dados. Os novos subtipos podem ser diferenciados dos tipos dos quais foram derivados por mecanismos tais como especialização, com o acréscimo de novos atributos, ou sobrecarga (overloading), onde se oferece uma efetivação diferenciada para um método já existente no tipo ancestral. Deste modo, o esquema de tipos de objetos define uma árvore ou hierarquia de tipos relacionados.
Herança múltipla refere-se ao mecanismo de herança através do qual um novo tipo de objeto pode ser derivado a partir de mais de um tipo ancestral. Entretanto, a semântica de herança múltipla nem sempre é clara. Ademais, a execução de herança múltipla requer cuidados adicionais para lidar com situações como o conflito de resolução para atributos ou métodos. Quando herança múltipla é suportada, o esquema de tipos de objetos passa a ser organizado como uma malha ou grafo de tipos.
Em um sistema gerenciador de base de objetos, a modificação de um tipo implica na modificação do esquema de dados. Em um sistema gerenciador de banco de dados tradicional, modificações no esquema eram ações que afetavam extremamente as aplicações, muitas vezes necessitando de processamento off-line para converter os dados de um esquema para o outro. Em um sistema gerenciador de base de objetos, esta evolução de esquemas deve ocorrer de forma mais natural. São três as categorias de modificações que implicam em evolução do esquema: mudanças em componentes (atributos ou métodos) de um tipo, mudanças na hierarquia (ou malha) de tipos, ou mudanças na definição de tipos, através de modificação de nome, inclusão ou remoção de tipos.
3.2.4 Consultas
Um dos principais aspectos a se considerar na manipulação de bases de dados é o mecanismo oferecido para expressar operações sobre os dados. Em geral, aplicações usando bases de dados são desenvolvidas em alguma linguagem de programação e integram expressões de manipulação de dados aos programas. A diferença entre estas linguagens de programação e de manipulação de dados dá origem ao problema de “descasamento de impedâncias” (impedance mismatch) entre as linguagens, que é endereçado de maneiras distintas em diversos sistemas gerenciadores de base de objetos. Entretanto, nenhuma destas abordagens, descritas a seguir, consegue eliminar completamente o problema do descasamento de impedâncias entre as aplicações.
Uma estratégia de integração de linguagens é o query download, onde todos os objetos relevantes para a operação da aplicação são recuperados da base de dados, traduzidos para a representação adequada para a linguagem de programação, manipulados, retraduzidos e armazenados de volta à base de dados. Uma variante deste esquema limita a operação a um único objeto por interação, com o objetivo de maximizar a concorrência de acesso à base de dados. Outra alternativa é armazenar objetos da linguagem de programação como BLOB na base de dados, que nesta situação não conteria nenhuma informação sobre a estrutura do objeto.
Em outra direção de integração, alguns sistemas estendem linguagens de manipulação de dados com construções procedimentais. Sybase adotou esta abordagem ao estender SQL com construções de controle de execução para sistemas relacionais. Outros sistemas oferecem novos tipos de dados na linguagem de programação para refletir tipos e operações referentes à base de dados.
Uma abordagem mais transparente de integração entre linguagens de programação orientadas a objetos e sistemas gerenciadores de base de objetos é a incorporação de mecanismos de persistência de objetos à linguagem de programação. Nesta situação, a base de dados é utilizada de forma implícita e transparente como meio de manutenção do estado de objetos da aplicação entre sessões.
Métodos de especificação de persistência em sistemas gerenciadores de base de objetos podem ser por tipo, por invocação explícita ou por referência. Na especificação por tipo, apenas alguns tipos pré-definidos são persistentes. Uma crítica a este modelo é que persistência e especificação de tipos são conceitos ortogonais, e que associar persistência a apenas alguns tipos fere essa ortogonalidade. Na especificação de persistência por invocação explícita, a aplicação solicita explicitamente ao sistema gerenciador de base de objetos o armazenamento persistente do objeto em questão. Na especificação por referência, um ou mais objetos (as raízes) são declarados como persistentes, e todos os objetos por eles referenciados tornam-se automaticamente persistentes. Este é o mecanismo mais transparente, mas que exige mais em termos de processamento da parte do sistema gerenciador de base de objetos.
Outro aspecto importante relativo a consultas em sistemas gerenciadores de base de objetos refere-se ao tipo de resultado que uma consulta gera. Em sistemas relacionais, existe um único tipo (a relação); portanto, operandos e resultados de consultas são relações. Em sistemas gerenciadores de base de objetos, o grau de liberdade é maior. Alguns sistemas podem limitar a resposta obtida a alguns tipos específicos, embora a tendência seja permitir a manipulação de resultados abertos — literal, objeto, coleções de objetos ou até mesmo relações (arranjos tabulares de dados).
Consultas envolvendo múltiplos objetos necessitam de alguma forma de mecanismo de junção. Duas variantes da operação de junção em sistemas gerenciadores de base de objetos são a junção por referência e a junção por valor. A junção por referência utiliza associações definidas na base de objetos para obter objetos associados. A junção por valor, assim como a junção de sistemas relacionais, é realizada sobre valores de atributos que compartilham um domínio comum, não necessitando, portanto de associações explícitas para sua realização.
3.2.5 Concorrência e recuperação
Como dados em uma base de dados são persistentes e usualmente compartilhados por várias aplicações e/ou usuários, é preciso que haja mecanismos para controle de acesso concorrente, de recuperação de dados em caso de operações falhas e de manutenção de integridade dos dados. Em um sistema gerenciador de base de objetos, diferentemente do que ocorre em sistemas tradicionais, uma aplicação manipula de forma natural dados transientes e dados persistentes, o que pode criar dificuldades adicionais na manutenção de consistência dos dados.
Operações sobre objetos persistentes são usualmente definidas no escopo de transações, assim como ocorre em sistemas gerenciadores de banco de dados tradicionais. Uma possível diferença é que sistemas gerenciadores de base de objetos podem (e geralmente o fazem) incluir transações longas e, em alguns casos, transações aninhadas.
Versões oferecem um mecanismo alternativo para controle de concorrência. Através do mecanismo de versões libera-se o sistema de manter uma única cópia de um objeto na base, o que alivia uma eventual degradação que poderia ocorrer com a incorporação de transações (e consequentemente lock) longas. Com versões, evoluções alternativas nos estados dos objetos são permitidas. Um conceito relacionado a este é configuração, um conjunto de versões de objetos mutuamente consistente.
Configurações equivalem a snapshots (ou visões instantâneas) consistentes da base de objetos.
3.2.6 Implementação de identificadores
Um dos fatores mais importantes no desempenho de um sistema gerenciador de base de objetos é a forma de execução da representação de seus objetos, como são armazenados, identificados e recuperados da base de dados.
A representação de identificadores de objetos pode ser física ou lógica. A representação física contém o endereço real do objeto, como ocorre em linguagens de programação orientadas a objetos onde objetos são identificados por sua posição na memória. A representação lógica envolve algum mecanismo de mapeamento entre uma representação interna e o endereço do objeto As quatro abordagens básicas de implementação de identificadores são utilização simples do endereço, um identificador físico; utilização de endereços estruturados, que contém uma componente lógica e outra física; utilização de surrogates, identificadores lógicos que são mapeados para endereços físicos através de um índice ou de uma tabela; e a utilização de surrogates tipados, onde a informação sobre o tipo do objeto é incluída no identificador lógico.
A unicidade de um identificador de objeto é um aspecto fundamental para a manutenção da consistência de uma base de objetos. Identificadores de objetos são utilizados tanto pelas aplicações como pela própria base de objetos, para representar associações entre objetos. O mecanismo para garantir unicidade pode variar entre execuções distintas. Alguns sistemas garantem que identificadores de objetos removidos não são reaproveitados; outros buscam garantir unicidade entre múltiplas bases de objetos interligadas em rede, incorporando o endereço da máquina servidora no identificador de objeto.
Identificadores de objetos puramente físicos, por endereços, oferecem o melhor potencial de desempenho para recuperação de objetos. Porém, fixar a posição do objeto na base torna-a menos flexível, dificultando operações como relocação de objetos. A relocação pode ser necessária para ampliar o espaço de armazenamento associado a um objeto ou realizar uma compactação ou reclustering da base de objetos. Por este motivo, endereços físicos não são utilizados na prática. ONTOS e Objectivity/DB utilizam endereços estruturados, GemStone e POSTGRES utilizam surrogates, e ORION e Itasca adotam surrogates tipados.
Além da referência a objetos por identificadores de objetos, diversos sistemas oferecem a possibilidade de se localizar um objeto através de atributos chaves. Em geral, a implementação deste mecanismo em sistemas gerenciadores de base de objetos é similar àquela de sistemas tradicionais, onde valores de atributos chaves são mapeados a identificadores de objetos através de índices hash ou B-trees.
3.2.7 Swizzling
Swizzling é o processo de conversão entre a representação persistente do objeto, na base de objetos, e sua representação dinâmica, na linguagem de programação orientada a objetos adotada pela aplicação, onde o objeto será efetivamente manipulado. Evidentemente, é um processo importante na manipulação de objetos, sendo determinante para o desempenho do sistema gerenciador de base de objetos.
A conversão que deve ocorrer através de Swizzling envolve tipicamente traduções de referências e, eventualmente, modificações na estrutura e no formato de representação de dados. Referências dinâmicas são tipicamente ponteiros na linguagem de programação, e não identificadores de objetos.
A tradução de identificadores de objetos para referências a objetos na linguagem de programação é a principal atividade desempenhada durante o Swizzling. Mudanças na estrutura podem ocorrer através da incorporação de cabeçalhos e campos para utilização em tempo de execução. Mudanças na representação interna dos dados podem ser necessárias principalmente quando a base de objetos é compartilhada em ambientes heterogêneos.
Swizzling pode ocorrer em momentos distintos, de acordo com a implementação adotada para este mecanismo. Tipicamente, uma das quatro abordagens a seguir é adotada:
a. A conversão ocorre no momento em que o objeto é transferido da base de objetos para o espaço de memória da aplicação (checkout).
b. A conversão ocorre no momento em que o objeto, já transferido para a memória, é referenciado pela primeira vez pela aplicação.
c. A conversão ocorre no momento em que a aplicação a solicita explicitamente.
d. A conversão ocorre quando não é possível reaproveitar um endereço físico designado anteriormente, o qual é registrado também na base de dados.
Esta última abordagem é adotada em ObjectStore, que busca explorar a grande capacidade de endereçamento virtual dos processadores modernos para alocar um objeto sempre à mesma posição de memória virtual.
3.2.8 Granularidade de transferência
Bases de objetos podem transferir informação entre o disco e a memória em unidades de dimensão, ou granularidades, distintas. Tipicamente, as granularidades adotadas são páginas, objetos ou resultados de consultas.
A abordagem mais utilizada nas implementações de sistemas gerenciadores de base de objetos é passar para a aplicação uma imagem do disco, adotando granularidade de uma página.
Esta abordagem simplifica o trabalho do servidor de páginas, onde o processamento será mínimo.
Entretanto, o tráfego de dados pela rede é ampliado, pois uma página pode conter mais informação que a solicitada pela aplicação.
Quando a granularidade adotada é um objeto ou um resultado de consulta, o tráfego de dados pela rede é reduzido, pois se garante que a aplicação estará recebendo apenas o que foi solicitado.
Entretanto, exige-se nessas situações que o servidor de objetos já realize algum processamento sobre a base de objetos. Se o sistema gerenciador de base de objetos for compartilhado por muitas aplicações, um alto número de requisições simultâneas pode ter impacto significativo no desempenho do servidor.
A abordagem de imagem do disco, embora eficiente, pode apresentar riscos à integridade dos dados presentes na página. Este risco está presente principalmente quando a aplicação utiliza uma linguagem de programação onde é permitido aos programas examinar e alterar qualquer posição de seu espaço de memória, como ocorre em C#, por exemplo. Em tais situações, seria necessário que o sistema gerenciador de base de objetos impusesse mecanismos adicionais de manutenção da integridade dos dados em uma página manipulada pela aplicação, evitando sua degradação através de ações inadvertidas ou maliciosas. Entretanto, as implementações correntes de sistemas gerenciadores de base de objetos não incorporam mecanismos com este fim.
Citei como uma das atividades durante o Swizzling a incorporação de informação para manipulação de objetos em tempo de execução. Informação típica de runtime para um objeto inclui o mapeamento de um identificador de objeto para endereço físico, o registro de quais objetos estão na memória da aplicação, manutenção de dirty bits para indicar se objetos foram atualizados ou apenas consultados, e contadores de referências para sustentar atividades internas de swapping e garbage collection. Abordagens para manipulação deste tipo de informação incluem a manutenção de tabelas em memória, utilização de descritores de objetos e incorporação de status bits no próprio objeto.
3.2.9 Atributos
A forma de implementação mais simples para a representação de atributos de um objeto seria utilizar relações, com campos de dimensão fixa, como foi proposto por alguns protótipos iniciais de sistemas gerenciadores de base de objetos. Entretanto, esta alternativa limita severamente a flexibilidade de representação para objetos, não permitindo operar de modo eficiente com atributos de dimensões variáveis, com coleções com quantidade variável de elementos, a evolução de esquema pela inclusão de atributos e o armazenamento eficiente para atributos não utilizados por um objeto.
Listas de propriedades oferecem um mecanismo mais versátil de implementação de atributos de um objeto. Uma lista de propriedades é composta por elementos contendo três campos, representando um identificador de atributo, o tamanho do valor do atributo e o valor. Este mecanismo é flexível, porém demanda um maior grau de processamento da parte dos métodos que manipulam a estrutura interna do objeto.
Herança é outro aspecto que traz impacto na representação de atributos. Em sistemas onde apenas herança simples é permitida, o mecanismo de lista de propriedades é ainda adequado. Neste caso, a lista de propriedades de um objeto é composta pela concatenação dos atributos do tipo do objeto com os atributos do tipo de objeto ancestral, e assim recursivamente até encontrar os atributos do tipo de objeto que é a raiz da hierarquia. Para lidar com herança múltipla, mecanismos mais elaborados são necessários para estabelecer prioridades na concatenação e resolver conflitos entre tipos ancestrais com atributos de mesmo nome.
Manipulação de coleções é outro aspecto crítico em sistemas gerenciadores de base de objetos, sendo esse mecanismo amplamente utilizado na descrição de estrutura de atributos de objetos e no retorno de consultas. Como coleções podem ser demasiadamente extensas e/ou conter objetos grandes, é preciso oferecer mecanismos que permitam manipulá-las de modo mais eficiente. O principal mecanismo adotado é a utilização de objetos iteradores. Um iterador é um objeto temporário que contém referências aos membros da coleção, oferecendo métodos tais como produzir o próximo elemento da coleção (lista) ou buscar o -ésimo elemento da coleção (arranjo).
A manipulação de atributos do tipo BLOB é usualmente implementada através de interfaces stream. Assim como iteradores, um stream permite referenciar objetos sem que esses estejam completamente concretizados em memória, com métodos para posicionar, ler e escrever blocos de dados binários. Alternativas para a manipulação de BLOB incluem a paginação por demanda e utilização de piece streams. Na paginação por demanda, a aplicação tem o objeto completo em memória virtual, sendo que páginas do objeto são transferidas para a aplicação à medida que seus bytes são referenciados.
Um piece stream é um mecanismo de stream com facilidades adicionais que permitem a atualização de conteúdo do BLOB, tais como inserção e remoção de bytes na posição corrente.
3.2.10 Associações
A execução de relacionamentos não precisa refletir diretamente a forma como a aplicação os define conceitualmente. A estratégia de execução pode depender da multiplicidade das associações.
Por exemplo, um relacionamento um-para-muitos pode ser representado por contiguidade física, por indexação, por ligação ou através de objetos intermediários criados pelo sistema gerenciador de base de objetos.
Um tipo de associação implícita entre os elementos de uma coleção é a ordenação. Apesar de estar presente em muitas aplicações, nem sempre este mecanismo é suportado em sistemas gerenciadores de base de objetos, onde apenas coleções do tipo conjunto (assim como relações, sem critérios de ordenação entre elementos) são suportadas. A importância da ordenação da coleção é reconhecida de longa data; o modelo CODASYL definia associações de ordenação manual (critério de ordenação estabelecido pela aplicação) e automática (estabelecido pelo sistema sobre algum atributo da coleção).
Outro aspecto importante na execução de associações é a manutenção da integridade referencial.
O mecanismo mais amplamente adotado para este fim é a utilização de pares de atributos inversos. Assim, se a aplicação define uma referência de um objeto “a” para um objeto “b”, denotada a  b, o sistema gerenciador de base de objetos cria internamente a referência b  a. Alternativamente, o sistema pode implementar um contador de referências para o objeto, só permitindo sua remoção quando o valor deste contador for nulo.
3.2.11 Clustering
A incorporação do conceito de objeto complexo em sistemas gerenciadores de base de objetos introduz grande flexibilidade de estruturação dos dados. Por outro lado, a recuperação de objetos complexos pode introduzir degradação no desempenho dos sistemas. Afinal, o conteúdo de um objeto complexo é composto por outros objetos, que potencialmente podem estar distribuídos em diversas páginas espalhadas pelo disco. Assim, recuperar o conteúdo de um objeto complexo pode acarretar em várias solicitações de páginas do servidor para o cliente.
Clustering é um mecanismo que pode ser adotado para minimizar esta degradação no desempenho.
Simplesmente colocado, o conceito de clustering é adotar alguma estratégia de alocação de objetos no sistema de armazenamento de modo a minimizar a quantidade de páginas necessárias para manipular objetos. As estratégias de clustering mais utilizadas são:
a. Objetos complexos: adota o relacionamento de agregação para identificar objetos que devem ser armazenados próximos, preferencialmente, na mesma página ou em páginas contíguas.
b. Referências: adota a existência de relacionamentos quaisquer entre objetos para direcionar a proximidade de armazenamento. A estratégia de clustering por objetos complexos é um caso especial desta estratégia.
c. Tipos de objetos: adota o critério de aproximar o armazenamento de objetos de uma mesma classe.
Este é um critério equivalente ao adotado pela maior parte dos sistemas gerenciadores de banco de dados relacionais, onde tuplas de uma mesma relação são armazenadas contiguamente.
d. Índices: adota o valor de um atributo como critério de ordenação dos objetos, e aproxima o armazenamento de objetos com valores próximos neste atributo.
e. Definição do usuário: utiliza um indicativo da aplicação, em tempo de execução, para buscar a melhor posição de armazenamento de um objeto. Um exemplo de implementação utiliza um identificador de um objeto existente como parâmetro na criação de um novo objeto, indicando que os dois devem ser armazenados em posições próximas.
A seleção de um critério de clustering deve depender da forma de recuperação mais adotada para o objeto na aplicação. Por exemplo, em sistemas CAD provavelmente a estratégia de objetos complexos seria a preferencial, enquanto que para uma aplicação comercial, envolvendo sequências de recuperações em ordem alfabética, a estratégia de índices seria a mais adequada.
3.2.12 Evolução de esquemas
Em grande parte dos sistemas gerenciadores de base de objetos, o esquema de dados é em si armazenado como um objeto. Entretanto, este objeto nem sempre é diretamente manipulável pela aplicação em tempo de execução; restrições de acesso são impostas como forma de manutenção da integridade da base de objetos. Mudanças no esquema devem obedecer a tais restrições, determinando como esquemas podem evoluir.
Há quatro estratégias básicas que determinam como um esquema pode evoluir: tipo de uma escrita, atualização imediata, atualização posterior, e mapeamento de esquema.
A estratégia de tipos de uma escrita (ou tipos write-once) é a abordagem mais simples, que determina que qualquer tipo que já contenha pelo menos uma instância não pode ser modificado.
Modificações no tipo, tal como a inclusão de um novo atributo, deve ser explicitamente desempenhada pela aplicação através da criação de um novo tipo e cópia do conteúdo de objetos já existentes para objetos do novo tipo.
A estratégia de atualização imediata é a mais adotada em sistemas gerenciadores de base de objetos correntes. Nesta estratégia, qualquer modificação no tipo de um objeto é imediatamente refletida para os objetos. Assim, a inclusão de um novo atributo em um tipo faria com que todos os objetos daquele tipo tivessem sua estrutura atualizada para conter um campo adicional contendo o valor nulo.
Na estratégia de atualização posterior, a estrutura de um objeto cujo tipo tenha sido modificado não é alterada a não ser no primeiro momento em que o objeto é acessado após a alteração do tipo.
Nesta abordagem, é preciso que o sistema gerenciador de base de objetos mantenha informação histórica sobre a evolução de esquemas e sobre procedimentos de conversão para poder manter a consistência da base.
A estratégia de mapeamento de esquema equivale a uma estratégia de atualização posterior onde o momento de atualização é postergado indefinidamente, até o momento em que uma reorganização da base de objetos seja explicitamente solicitada. Nesta estratégia é preciso manter os mapas de conversão entre todas as possíveis versões de esquema, o que possibilitaria que usuários pudessem ter visões de um mesmo objeto sob diferentes versões de esquema. Entretanto, a execução de tal estratégia seria extremamente complexa, não tendo sido implementada em nenhum sistema gerenciador de base de objetos até o momento.
1.3 DIFERENÇA ENTRE BANCO DE DADOS ORIENTADO A OBJETO E BANCO DE DADOS RELACIONAL:lol!: 
Banco de Dados Orientado a Objetos e Banco de Dados Relacionais 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 Banco de Dados Relacional (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 Banco de Dados Orientado a Objeto (BDOO) possui três pilares principais: herança, polimorfismo e encapsulamento. 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.
3.4 OBJECT RELATIONAL MAPPER – ORM (MAPEAMENTO OBJETO RELACIONAL) 

Mapeamento objeto-relacional (ORM: Object-relational mapping) é uma técnica de desenvolvimento utilizada para reduzir a impedância da programação orientada aos objetos utilizando bancos de dados relacionais. As tabelas do banco de dados são representadas através de classes e os registros de cada tabela são representados como instâncias das classes correspondentes.
Com esta técnica, o programador não precisa se preocupar com os comandos em linguagem SQL; ele irá usar uma interface de programação simples que faz todo o trabalho de persistência.
Não é necessária uma correspondência direta entre as tabelas de dados e as classes do programa. A relação entre as tabelas onde originam os dados e o objeto que os disponibiliza é configurada pelo programador, isolando o código do programa das alterações à organização dos dados nas tabelas do banco de dados.
A forma como este mapeamento é configurado depende da ferramenta que vamos usar.
3.4.1 Desenvolver utilizando o Modelo Orientado a Objetos com o Banco de Dados Relacionais
Nos últimos anos, o paradigma de orientação a objetos vem se desenvolvendo na área de programação. Várias experiências têm mostrado que esse paradigma aumenta a produtividade dos programadores a modularidade dos programas. Na área de Bancos de Dados (BD), sabe-se que os modelos de dados clássicos, como por exemplo o modelo relacional, não são apropriados para descrever e manipular os dados das chamadas "novas aplicações", tais como projeto assistido por computador (CAD), manufatura de produtos (CAM), produção de software (CASE), automação de escritórios (OIS), aplicações médicas e científicas, representação do conhecimento para aplicações de inteligência artificial, etc. Os dados dessas aplicações são muito complexos e evolutivos, sendo necessária a modelagem não somente de sua estrutura, mas também de seu comportamento.
Para compensar estas deficiências, vários modelos de dados tem sido propostos. Primeiramente, os estudos na área foram dirigidos para os modelos semânticos e extensões do modelo relacional. Mais recentemente, surgiram modelos que procuram enfatizar os aspectos comportamentais dos objetos que manipulam, sendo baseados principalmente em conceitos oriundos da programação orientada a objetos. Isso se deve ao fato de que a orientação a objetos auxilia a lidar com a complexidade nas mais diferentes aplicações. Esses modelos são denominados modelos de dados orientados a objetos.
Os modelos de dados orientados a objetos são mais expressivos e flexíveis que o modelo relacional. 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. Por outro lado, os modelos orientados a objetos foram projetados para a criação e representação de estruturas bem mais complexas de uma maneira coerente e uniforme.
Apesar de inúmeras vantagens encontradas ao se utilizar o paradigma de orientação a objetos, ainda não existem SGBD OO comercialmente disponíveis para aplicações de grande porte. Os SGBD relacionais ainda representam o estado da arte na tecnologia tradicional de bancos de dados e são os mais estudados na literatura. Suas maiores vantagens são a simplicidade e a portabilidade entre execuções. Esses sistemas continuam a dominar o mercado, sendo utilizados nas mais diversas aplicações.
Entretanto, os conceitos de orientação a objetos podem ser utilizados como mecanismos de abstração para o projeto de bancos de dados relacionais. A modelagem orientada a objetos, por utilizar conceitos mais claros e naturais, permite produzir bancos de dados relacionais mais adequados às aplicações do mundo real, evitando os problemas de normalização frequentemente associados ao projeto relacional. Além disso, a modelagem orientada a objetos aumenta a integração entre os dados e as aplicações. Dessa forma, uma abordagem orientada a objetos para o projeto de lógico de bancos de dados relacionais permite que as aplicações sejam projetadas de forma integrada, em que dados e operações podem ser projetados ao mesmo tempo.
Com o crescimento do mercado, as linguagens orientadas a objetos começaram a dar maior enfoque em um novo paradigma, a análise, projeto e codificação de sistemas. É claro que os bancos de dados não poderiam ficar imunes a esse novo modo de encarar o desenvolvimento de sistemas. Houve, entretanto, um desenvolvimento mais rápido nas linguagens orientadas a objetos (OO) que nos Sistemas Gerenciadores de Bancos de Dados Orientados a Objetos (SGBD OO), o que deixou os desenvolvedores e administradores de BD numa situação curiosa: mesmo querendo adotar a orientação a objetos, eles têm que parar na hora de manipular seus dados. Linguagens visuais como o JAVA, por exemplo, embora sejam orientada a objeto em sua essência, acessam os bancos de dados de maneira convencional, ou seja, não orientada a objetos e usando SQL. Com isso, um mesmo programa tem uma parte OO e uma parte estruturada. Alguns autores dizem que quando linguagens OO utilizam SQL embutido para acesso a dados remotos em um SGBD, as facilidades e vantagens da orientação a objetos presentes nessas linguagens não são exploradas totalmente.
Outro ponto importante, é saber se a aplicação da OO no armazenamento estático de dados será tão mais eficiente para dados convencionais (strings e números) como parecem ser para dados especiais como som, imagens e textos desestruturados. Caso ela não represente um grande avanço em relação aos SGBD relacionais também nessa área, haverá sempre a possibilidade de termos um grande uso de SGBD OO para armazenamento de dados multimídia e os velhos e bons SGBD relacionais para dados convencionais, o que não representaria pouco.
Enquanto o armazenamento de dados OO não se tornar comercialmente disponível apenas, a opção mais adequada é desenvolver o sistema utilizando OO na análise e no projeto, e posteriormente armazenar os dados relacionalmente.
3.4.2 ORM (Object Relational Mapper) e sua utilização:lol!: 
ORM (Object Relational Mapper) ou mapeador objeto relaciona, é um tipo de ferramenta muito utilizada hoje em dia, com o propósito de unir o mundo orietado a objetos e o mundo 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 ú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. Existem ótimos ORM como Hibernate, NHibernate, Entity Framework e etc.

Tudo começa como mostrado na figura acima, existem dois mundos: o Relacional e o Orientado a Objeto, 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 Bados, 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 Banco de Dados e cada ORM tem suas particularidades, para gerar o SQL referente à 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 se deixa de escrever os comandos SQL para deixar que o próprio ORM, faça isto por você.
3.4.3 Ferramentas Disponíveis no Mercado e Análise dos melhores ORM (Object-Relational Mapping) para plataforma .NET
Um ORM, 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 de Dados.
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 (BDR). 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 de Dados, query de SQL a todo momento, preservando as características de orientação a objetos da linguagem face à natureza relacional dos bancos de dados atuais.
3.4.3.1 Vantagens e Desvantagens de se usar um ORM
A grande sacada 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 às 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 mudarmos 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.
Você escreve menos código e programa com muito mais produtividade. Seu código fica mais elegante. É mais fácil de dar manutenção no projeto. Melhora a padronização da sua aplicação.
Exemplo de um código em .NET usando ORM:
Usuario.AddNew();  
Usuario.FirstName = this.txtFirstName.Text;  
Usuario.LastName = this.txtLastName.Text;  
Usuario.Save();  
Exemplo de um código em .NET usando classes nativas do .NET Framework:
strConn = "string de conexão aqui";
SqlConnection objCon = new SqlConnection(strConn);
SqlCommand objComand = objCon.CreateCommand();
objComand.CommandText = "insert into Usuario (FirstName , LastName ) values (@FirstName , @LastName )";
objComand.CommandType = CommandType.Text;
objComand.Parameters.Add("@FirstName  ", txtFirstName.Text );
objComand.Parameters.Add("@LastName  ", txtLastName.Text );
objComand.ExecuteNonQuery();

É importante ressaltar que dificilmente você achará uma solução que substitua 100% das classes do ADO.NET, eventualmente você será obrigado a fazer uma gambiarra no meio do caminho para obter determinados resultados. No entanto, seguramente os melhores Frameworks resolverão mais de 95% das suas necessidades.
Como nem tudo são flores, temos algumas desvantagens que existem quando se decide usar algum tipo de ORM. A primeira grande desvantagem é o desempenho. 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. Às 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 se percebe, a complexidade foi elevada.
3.4.3.2 Como escolher um ORM
Estes são uns dos critérios para escolher um ORM para adoção dentro de uma empresa ou projeto.
• Qualidade da documentação;
• Tipo e qualidade do suporte;
• Custo;
• Curva de aprendizado;
• Continuidade (Novos releases do projeto e periodicidade);
• Capacidade de execução de stored procedures do legado;
• Bancos de dados suportados;
• Suporte a querys dinâmicas;
• Suporte a dados hierarquizados;
• DataBind a .Net controls;
• Capacidade de fazer transações;
• Performance;
• Facilidade de manutenção do código (incluindo aí a inteligibilidade do mesmo).
Normalmente, o frameworks que existem atuam como geradores de código criando classes baseadas nas suas tabelas de banco de dados.
Existem vários free e pagos. Os free normalmente carecem de suporte e documentação, os pagos conseguem suprir melhor esta deficiência por um motivo óbvio. Os melhores free são o que possuem amplo apoio da comunidade ou têm um grupo de desenvolvedores bastante ativos distribuindo novos releases num curto espaço de tempo.
Nota minha: Estou referenciando os free como aqueles que você pode usar sem pagar pela licença de uso. Isso não quer dizer que eles sejam Open Source, Software Livre, GPL ou FreeWare nem nada. Veja no site do produto a forma de utilização, licenciamento e distribuição de cada um para saber mais.
3.4.3.3 Análise de alguns dos principais ORM
Procurando no Google e em sites especializados, descobri mais de 40 deles. Boa parte já teve seu desenvolvimento abandonado (a maioria Free), mas os melhores têm conseguido sobreviver.
Eu separei a lista em Inativos, Free e Pagos. Os Inativos são o que não têm tido releases lançados nos últimos anos e tiveram seu desenvolvimento paralisado, provavelmente.
Em caso de dúvidas, baixe o framework e teste-o para ter uma opinião própria.
Produtos Inativo

Produtos Free

Produtos Pagos

Entre os Free, projetos que merecem um acompanhamento:
- NHibernate
- SubSonic
- Codus
- ObjectMapper
O NHibernate é Subsonic são os que têm mais futuro, pelo apoio da comunidade que desenvolve os projetos.
Baseado no Hibernate do JAVA, o NHibernate é Framework extremamente completo e poderoso. Existem alguns geradores de código como o próprio MyGeneratiom e Codus que facilitam o trabalho de configuração do XML.
O SubSonic tem a grande vantagem de a configuração ser quase nula. Ele lê o schema do banco de dados e gera as classes de mapeamento quando você dá o primeiro build no projeto. Os releases são muito rápidos permitindo que diversos bugs sejam corrigidos e as melhorias sejam implementadas num curto espaço de tempo.
Entre os Pagos, os seguintes projetos se destacaram pelo custo/benefício.
- Entity Spaces
- LLBLGen Pro
- eXpress Persistent Objects
O Entity Spaces vale o investimento, pois o produto é excelente por conta da documentação que é muito completa e do suporte que é rápido.

Bom trabalho a todos e não esqueçam que a data limite é 11/10/2013. 

==================================================

Corsário Posso Repassar Pra Um Amigo O Que Postastes? Eu Já Fiz O Meu, Posso Passar Este Pra Ele?

Posso Passar Para Um Amigo O Que Postastes? Já Fiz O Meu Trabalho, Pode Ser?