Portifolio Individual 4 Semestre Ads

SUMÁRIO

1 INTRODUÇÃO 4

2 OBJETIVO.................................................................................................................5

3 DESENVOLVIMENTO 6

3.1 BANCOS DE DADOS ORIENTADOS A OBJETOS 6

3.1.1. DIFERENÇA ENTRE BANCO DE DADOS ORIENTADO A OBJETOS E BANCO DE DADOS RELACIONAL 6

3.2. ORM......................................................................................................................8

3.2.1 O CONCEITO RELACIONAL..............................................................................8

3.2.2. MAPEAMENTO OBJETO RELACIONAL (ORM)..............................10

3.2.3. FERRAMENTAS DISPONÍVEIS HOJE NO MERCADO 10

3.2.4. VANTAGENS E DESVANTAGENS DE SE USAR UMA FERRAMENTA ORM...........................................................................................................................11

4 CONCLUSÃO 12

REFERÊNCIAS 13

1. INTRODUÇÃO

Para que os sistemas desenvolvidos possam ter uma boa base de tecnologia, alguns conceitos são aplicados para auxiliar os desenvolvedores e analistas, a proposta deste trabalho é utilização de praticas de pesquisa sobre diretrizes estabelecidas envolvendo todas as disciplinas do curso.

.

2. OBJETIVO.

Com base nos conceitos propostos e através de pesquisas, iremos abordar assuntos aprendidos no decorrer do curso para colocar em pratica tudo que foi estudado no processo de aprendizado.

3. DESENVOLVIMENTO

3.1 Banco de Dados Orientado a Objetos

Os Banco de Dados Orientado a Objetos sugiram da necessidade de armazenar dados complexos e de acabar com a disparidade que havia na modelagem da aplicação e do Banco de Dados (BD). Com o advento das linguagens de programação orientadas a objetos, os programadores passaram a utilizar este paradigma e a modelagem então naturalmente passou também a seguir este modelo. O outro ponto é que objetos complexos precisam ser quebrados em diversas tabelas, ou relações, para serem armazenados e com isto para recuperar tal informação é preciso realizar um JOIN entre diversas tabelas.

Com a orientação a objetos, é possível modelar objetos de forma mais próxima ao mundo real, como por exemplo, em um sistema de geoprocessamento, engenharia, pesquisa científica e tantos outros sistemas não triviais. Um Bando de Dados Orientado a Objetos – BDOO – permite ainda que a aplicação manipule objetos, independente se eles são persistentes ou não, pois é possível armazenar todo o objeto e não apenas seus atributos. Diferentemente do modelo Relacional, o BDOO não utiliza o conceito de chave primária ou secundária. As chaves foram substituídas pelo identificador de objeto (OID – Objetct Identifier), que é controlado pelo próprio SGBD – Sistema Gerenciador de Banco de Dados – e não é visível ao usuário do Banco de Dados. O OID pode ser visto como uma referência ao objeto em memória, assemelhando-se a um ponteiro, porém um OID nunca é alterado e nem reaproveitado, diferentemente do que acontece quando o objeto está em memória, onde é utilizado o endereço físico da memória RAM (Random Access Memory). Apesar da característica mencionada, é possível criar campos como chave para facilitar a identificação dos objetos armazenados por parte do usuário.

3.1.1 Diferença entre banco de dados orientado a objeto e banco de dados relacional.

A necessidade de manipulação e armazenamento de dados complexos vem crescendo rapidamente com o passar do tempo. Essa necessidade fez com que o paradigma orientado a objetos fosse agregado aos Sistemas Gerenciadores de Banco de Dados (SGBDs). As informações complexas, como gráficos, imagens, áudio, vídeo, mapas, entre outros, requerem funcionalidades que vão além do que o modelo relacional de banco de dados pode oferecer. Por essa razão, surgiu o modelo de banco de dados orientado a objetos, que traz muitos benefícios em relação ao banco de dados relacional, pela sua produtividade ao agregar a orientação a objetos ao banco de dados. Entretanto, por ser um modelo jovem e imaturo que carece de mais estudo e desenvolvimento, suas operações são lentas quando comparadas com os bancos de dados relacionais existentes.

Como já apresentado, os Banco de Dados Orientado a Objetos (BDOO) sugiram da necessidade de armazenar dados complexos e de acabar com a disparidade que havia na modelagem da aplicação e do Banco de Dados (BD). Logo, as vantagens do BDOO vieram rapidamente à tona: possui uma abordagem flexível, facilidade de manusear objetos complexos, trabalha com noções de objetos, classes, relacionamento e identidade de objetos. Entretanto, logo foram percebidas suas limitações, principalmente a relacionada ao desempenho quando comparado com o Banco de Dados Relacional (BDR) e a falta de fundamentação matemática, o que dificulta realizar consultas complexas. Por conta, principalmente destas limitações, foi desenvolvido do Banco de Dados Objeto Relacional (BDOR). Este apresenta diversas vantagens em relação ao BDOO e ao BDR. Em poucas palavras, pode-se dizer que o BDOR surgiu para agregar as vantagens da orientação a objetos (herança, polimorfismo, encapsulamento, abstração) que há no BDOO, juntamente com o alto desempenho, eficiência e maturidade do BDR. O armazenamento de dados, tanto em BDOO, quanto em BDOR, se torna relativamente simples, uma vez que em ambos os bancos oferecem suporte a dados complexos. Entretanto, a principal vantagem do BDOR é a capacidade manipular dados complexos, persistentes e ao mesmo tempo manter a facilidade de uso dos métodos de consulta do SQL3. O BDOO possui um modelo rico de dados, ou seja, possui representação de objetos complexos, é extensível (oferece suporte para novos tipos de dados capazes de operar no objeto), ofereço suporte à ocultação da informação e herança. Seu ponto fraco é seu baixo desempenho, uma vez que sua otimização de consultas é bastante complexa, logo é perdido um tempo precioso neste processo. O BDOR oferece todas as características citadas no parágrafo anterior, exceto a do baixo desempenho. O BDOR possui uma otimização de consulta mais simples, e consequentemente, não perde tanto desempenho quanto o BDOO. Com relação ao mercado, o BDOO é voltado para aplicações de pequena escala, por questões de desempenho. Já o BDOR busca alcançar aplicações de larga escala, a qual é atualmente dominada pelos BDR.

3.2 ORM: (Object Relational Mapepr) – Mapeamento Objeto Relacional

3.2.1 O CONCEITO RELACIONAL:

Ele propõe a transformação de classes e objetos em tabelas e tuplas de maneira invisível, fácil e reutilizável ao programador. Ao invés do programador ter que criar todas as instruções SQL para as operações no banco de dados, ele pode utilizar um framework capaz de fazer essas operações sem sair do paradigma de orientação a objetos, de maneira transparente. Assim, todo aquele trabalho árduo de codificação e testes se resume a algumas configurações e um mínimo de código, sem manter um contato direto com o banco dedados.

Até então o ORM era só um conceito para qualquer linguagem orientada a objetos e para que esse conceito saísse do papel, em 2006 a Sun lançou a JSR 220 especificando os Enterprise JavaBeans (EJB) 3.0. Juntamente com o EJB 3.0, a Java Persistence API 1.0 foi disponibilizada ao público desenvolvedor. Mais posteriormente, em 2009, a JSR 317 foi divulgada, dessa vez contendo apenas a especificação JPA 2.0. Em suma, essa API apresenta anotações e interfaces, para que os frameworks que forem desenvolvidos sigam um padrão de funcionamento. A JPA não possui grande quantidade de código. De fato ela não faz o papel de um framework ORM. Ela apenas dita como eles deverão funcionar na plataforma Java.

FERRAMENTAS-UTILIZADAS:

HIBERNATE

O Hibernate faz o papel de um provedor de persistência. Um provedor de persistência geralmente é um framework ORM que implementa as especificações JPA e disponibiliza toda a programação necessária para o efetivo Mapeamento Objeto-Relacional e a persistência de dados. Mesmo o Hibernate tendo um papel tão fundamental na persistência de dados e no Mapeamento Objeto-Relacional, todo o acesso às suas funcionalidades acontece de uma maneira quase que transparente, uma vez que o programador utiliza na maior parte do tempo apenas as anotações e interfaces disponibilizadas pela JPA.

O Hibernate surgiu antes da especificação JPA e foi ele quem motivou a criação dessa especificação. Quando o Hibernate ganhou popularidade, a Sun previu que muitos outros frameworks seriam desenvolvidos e se uma maneira padronizada de mapeamento objeto-relacional não fosse criada, os desenvolvedores desses outros frameworks sairiam prejudicados caso optassem por uma migração da ferramenta. Prejudicados pelo fato de não poderem reutilizar código para persistência, configurações e mapeamentos. É importante lembrar que existem outros provedores ORM e não apenas o Hibernate. Alguns exemplos são o EclipseLink, OJB, OpenJPA e DataNucleus. Desses exemplos, o mais notável é o EclipseLink. Ele foi o RI (Reference Implementation) do JPA 2 e hoje é um dos mais utilizados.

Muitas corporações mundiais já adotaram o Hibernate como sua ferramenta de desenvolvimento. Alguns exemplos são: Sony, AT&T, PwC e Cisco. Para mais informações sobre ORM e Hibernate.

 

NoSQL

Os bancos de dados NoSQL (Not only SQL) é muito mais do que apenas um tipo de banco de dados. Esse termo é bem abrangente, envolvendo vários conceitos, tecnologias e estruturas. Ele foi criado em 1998 por Carlo Strozzi e teve como objetivo substituir bancos de dados relacionais, a fim de prover uma maneira mais leve e dinâmica de armazenamento de dados sem expor a utilização da linguagem SQL.

Outro aspecto importante no qual os bancos de dados NoSQL se diferenciam, é a maneira como operam. Enquanto os bancos de dados relacionais se baseiam no conceito ACID (Atomicidade, Consistência, Isolamento e Durabilidade), bancos de dados NoSQL utilizam o conceito BASE (Basically Available, Soft state, Eventually consistent).

ECLIPSELINK

O diferencial do projeto EclipseLink é permitir uma abstração da persistência de dados, permitindo persistir em banco de dados, arquivos XML, sistemas legados, tudo isso com uma única API.

OJB

É uma ferramenta para mapeamento objeto relacional que realiza a persistência transparente de objetos Java em banco de dados relacionais. É open-source, leve e fácil de usar, fácil de integrar numa aplicação já existente.

Permite a utilização de vários padrões de persistência: proprietário (PersistenceBroker API), JDO e Object Data Management Group (ODMG) 3.0.

 

DATANUCLEUS

O DataNucleus é um framework de persistência objeto-relacional que anteriormente era conhecido como JPOX, é desenvolvido pela comunidade de software livre e disponibilizado sem custos para ser utilizado no desenvolvimento de aplicações. É um dos frameworks ORM mais flexíveis dentre os disponíveis no mercado devido ao suporte às especificações de persistência JDO e JPA, bancos de dados e linguagens de consulta diferentes.

3.2.2 MAPEAMENTO OBJETO RELACIONAL (ORM):

É 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.

3.2.3 FERRAMENTAS DISPONÍVEIS HOJE NO MERCADO:

EXEMPLOS DE FRAMEWORKS ORM

a)C++: LiteSQL,QxOrm e ODB;

b)JAVA: Hibernate, ActiveJDBC, Athena Framework, JavaPersistence API, ORMLite e TopLink;

c).NET: ADO.NET, AgileFx, Business Logic Toolkit, NHibernate,OpenAccess ORM, Persistor.NET e Quick Objects;

d)Perl: DBIx::Class;

e)PHP: Agile Toolkit, CakePHP, CodeIgniter, Doctrine, FuelPHP,PdoMap e Zend Framework;

f)Python: Django, ORB, SQLAlchemy, SQLObject, Storm, Tryton eWeb2py;

g)Visual Basic 6.0: DatabaseObjects;

h)Ruby: ActiveRecord, Datamapper e iBATIS;i)Smalltalk: TOPLink/Smalltalk.

3.2.4 VANTAGENS E DESVANTAGENS DE SE USAR UMA FERRAMENTA ORM

VANTAGENS: A grande vantagem 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.

DESVANTAGENS: Temos alguns contras 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 é acomplexidade e o nível de entropia (grau de desorganização) 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. Às vezes, utilizado de maneira incorreta, o mapeamento pode acabar separando das entidades os dados e as regras de negócio.

4. CONCLUSÃO.

A realização deste portifólio me proporcionou uma maneira mais pratica para demonstrar os conhecimentos adquiridos no decorrer do semestre, todos fazendo parte de um único cenário interdisciplinar.

REFERÊNCIAS

Bibliográficas:

http://pt.wikipedia.org

Unopar web aula

Unopar Biblioteca Digital.

TANAKA, Simone Sawasaki; Análise de sistemas II – São Paulo: Pearson Prentice Hall,2009.

MATEUS, Eloá Jane Fernandes; Sistemas Operacionais - São Paulo: Pearson Education do Brasil,2010.

NISHIMURA, Roberto Yukio; Banco de Dados II - Pearson Prentice Hall,2009.

Fonseca, André de A.; Neto, Antonio de A. S.; Souza, Lucas T. de; Dourado, Tasso L.Banco de Dados Objeto-Relacional (BDOR).

MEDEIROS, Ernani Sales. Desenvolvendo software com UML 2.0: definitivo .São Paulo: Pearson Makron Books, 2004.TANAKA, Simone Sawasaki. Análise de sistemas III . São Paulo: Pearson PrenticeHall, 2009.CALDEIRÃO, Denise Morselli Fernandes.

Ética e responsabilidade social :RH/Denise Morselli Fernandes Caldeirão, Thiago Nunes Bazoli, Nádia Brunetta. SãoPaulo: Pearson Prentice Hall, 2009.VIEIRA, Eduardo. O/R Mapping – Vale a pena? 2009. Disponível em:http://evieira.wordpress.com/2009/04. Acesso em: 29 ago. 2012.WIKIPÉDIA, Disponível em: http://en.wikipedia.org/wiki/List_of_object relational_mapping_software. Acesso em: 21 ago. 2013.