Técnicas de mapeamento objeto relacional

Começar. É Gratuito
ou inscrever-se com seu endereço de e-mail
Rocket clouds
Técnicas de mapeamento objeto relacional por Mind Map: Técnicas de mapeamento  objeto relacional

1. Introdução

1.1. Apesar do paradigma orientado a objetos estar sendo cada vez mais difundido no processo de desenvolvimento de software, não existem hoje soluções comerciais robustas e amplamente aceitas neste paradigma para a persistência de dados. Mercado este dominado pelos bancos de dados relacionais.

1.1.1. Por quê ?

1.1.1.1. 1: Por uma análise mais criteriosa dos mapeamentos realizados de forma automática.

1.1.1.2. 2: Facilitar uso dos frameworks de outros tipos de paradigmas. ( Pra usar um framework de outro tipo primeiro você tem que conhecer oque será na maioria dos casos o paradigma vigente.)

2. Modelo Relacional

2.1. Modelo relacional A abordagem relacional está baseada no princípio de que as informações em uma base de dados podem ser consideradas relações matemáticas e que estão representadas de maneira uniforme com o uso de tabelas bidimensionais. Ao se fazer a análise para o desenvolvimento de uma aplicação, é muito importante saber se os tipos de dados a serem armazenados são tipos simples, tais como strings e números. Se este for o caso, é mais indicada a utilização de SGBDs relacional

2.1.1. Quais as vantagens de se usar os SGBDS relacionais

2.1.1.1. 1> Os SGBDs relacionais possuem uma característica muito importante: são extremamente confiáveis e mais eficientes

2.1.1.1.1. 2> 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.

2.1.2. E quais são as desvantagens ?

2.1.2.1. Uma das grandes desvantagens do modelo relacional pode ser observada no momento da realização da análise de um sistema a ser implementado: a grande dificuldade em abstrair a realidade, ou seja, traduzir para um modelo de tabelas, com suas relações entre si, suas chaves primárias e estrangeiras, um problema do mundo real.

3. Modelo Orientado a objetos

3.1. O modelo de dados orientado a objetos é uma extensão do paradigma orientado a objetos, possuindo basicamente os mesmos conceitos. O paradigma orientado a objetos se baseia na construção de aplicações a partir de objetos abstraídos da realidade, com dados e comportamento associados. Esses objetos possuem atributos (propriedades que contém valores que descrevem o objeto) e métodos (especificações de comportamentos dos objetos). Exemplo: Carro{ Atributos( placa, cor, modelo. } Métodos{ acelarar, parar, desligar, ligar. }

3.1.1. Além disso, o modelo Orientado a Objetos possui outras características importantes

3.1.2. Encapsulamento : Os valores dos atributos e os detalhes da implementação dos métodos estão escondidos de outros objetos. Em banco de dados se diz que um objeto está encapsulado quando o estado é oculto ao usuário e o objeto pode ser consultado e modificado exclusivamente por meio das operações a ele associadas

3.1.3. Herança: Relacionamento entre classes numa hierarquia. É a capacidade de criação de uma nova classe a partir de outra existente. Quando uma classe herda características de mais de uma classe, diz-se que houve herança múltipla. As principais vantagens de herança são prover uma maior expressividade na modelagem dos dados, facilitar a reusabilidade de objetos e definir classes por refinamento, podendo fatorar especificações e implementações como na adaptação de métodos gerais para casos particulares.

3.1.4. Mensagens: Meio de comunicação entre objetos. Troca de mensagens significa chamar um método do objeto

3.1.5. Polimorfismo : Capacidade de existir diferentes implementações para métodos com a mesma assinatura em diferentes classes da mesma hierarquia de herança. Em sistemas polimórficos, uma mesma operação pode se comportar de diferentes formas em classes distintas.

3.2. Vantagens do modelo Orientado a Objetos

3.2.1. 1 >No modelo Orientado a Objetos, a abstração da realidade é mais simplificada, pois um objeto nada mais é do que uma abstração direta da realidade. Por exemplo: um computador tem teclado, cpu e mouse. O teclado é um objeto, a cpu é outro objeto e o mouse também é um objeto.

3.2.2. 2 > Outra grande vantagem deste modelo é a questão da reutilização. Um objeto pode ser facilmente reutilizado no mesmo programa ou até mesmo em programas diferentes.

3.2.3. 3 > O modelo orientado a objetos foi projetado para a criação e representação de estruturas complexas de uma maneira coerente e uniforme. Isto representa uma grande vantagem em relação ao modelo de dados relacional, que foi criado sem se preocupar com o armazenamento de estruturas mais complexas. Outro ponto a favor do modelo orientado a objetos é a facilidade em expressar relações complexas entre objetos.

3.3. Desvantagens do Modelo Orientado a Objetos

3.3.1. 1 > O primeiro grande problema do paradigma orientado a objetos é que : os bancos de dados atuais não oferecem uma boa aderência aos princípios da orientação a objetos. Isto é, em termos de armazenamento, os bancos de dados orientados a objetos não conseguiram ainda substituir a tecnologia comprovadamente eficiente dos bancos de dados relacionais.

3.3.2. 2 > Em função da má aderência os administradores e desenvolvedores de bancos de dados acabam ficando em uma situação difícil, pois mesmo querendo adotar a orientação a objetos, eles têm que parar na hora de manipular seus dados. Até mesmo linguagens de programação orientadas a objetos, como Java, acessam os bancos de dados de maneira convencional e utilizando SQL. Com isso, um mesmo programa acaba tendo uma parte orientada a objetos e outra parte estruturada, fazendo com que as características da orientação a objetos não possam ser exploradas na sua plenitude.

3.3.3. 3 >Devido a isso, o que está ocorrendo nos dias de hoje é que o desenvolvimento é orientado a objetos, mas o banco de dados é relacional ou objeto-relacional. No modelo orientado a objetos, a implementação acaba se tornando mais complicada do que no modelo relacional, pois as estruturas de dados usadas no banco e as usadas na programação podem ser completamente diferentes. Isso reforça a necessidade da criação de uma camada de persistência, fazendo com que se gaste um bom tempo do desenvolvimento para mapear as estruturas da programação em estruturas do banco de dados.

3.4. Banco de dados Orientado a Objeto

3.4.1. Os bancos de dados orientados a objetos podem ser divididos em dois grupos: • Bancos de Dados Puramente Orientados a Objetos (BDPOO): baseia-se somente no modelo de dados orientado a objetos. Está baseado no conceito de objetos persistentes e usa declarações de classes muito semelhantes às declarações das linguagens orientadas a objetos; • Bancos de Dados Objeto-Relacionais (BDOR): correspondem a bancos relacionais que possibilitam o armazenamento de objetos.

3.4.1.1. Características dos BDPOO

3.4.1.1.1. 1 > Permitem a representação de relacionamentos 1-n, n-n e de herança;

3.4.1.1.2. 2 > A representação de um relacionamento é feita incluindo-se dentro de um objeto os “object identifiers” dos outros objetos com os quais ele se relaciona; o “Object Identifier” é um identificador interno do banco de dados para cada objeto. Os “object identifiers” são atribuídos e utilizados somente pelo SGBD, nunca pelos usuários.

3.4.1.1.3. 3 > Não possuem um padrão único de implementação como os bancos relacionais. Assim, cada produto tem a sua própria especificação para criação de classes e relacionamentos;

3.4.1.2. Características dos BDOR

3.4.1.2.1. Um banco objeto-relacional é um banco que permite o armazenamento de objetos em suas tabelas;

3.4.1.2.2. Uma classe representa um domínio, atuando como um data type para uma coluna. A classe, diferentemente dos bancos orientados a objetos, não representa mais um elemento envolvido em relacionamentos;

3.4.1.2.3. Todas as regras de um banco relacional continuam válidas;

3.4.1.2.4. Uma coluna cujo data type seja uma classe, só poderá ter uma instância desta classe. Imagine, por exemplo, uma coluna cujo data type seja uma classe TELEFONE. Nos BDOR, esta coluna não poderá ter várias instâncias da classe TELEFONE, mas apenas uma. Se o banco fosse OO, poderia ter mais do que uma.