Banco de Dados Orientado a Objetos e ORM

Prévia do material em texto

18
Sistema de Ensino Presencial Conectado
Tecnologia em Análise e Desenvolvimento de Sistemas
ANA CAROLINA TEIXEIRA DOS SANTOS
Atividade Interdisciplinar - Individual
Gurupi - TO
2013
ANA CAROLINA TEIXEIRA DOS SANTOS
Atividade Interdisciplinar - Individual
Trabalho apresentado ao Curso de Tecnologia em Análise e Desenvolvimento de Sistemas da Universidade Norte do Paraná – UNOPAR
Professores: Paulo Kiyoshi Nishitani
Polyanna Pacheco Gomes Fabris
	Sérgio de Goes Barboza
Márcio Chiaveli
	Anderson Macedo
Gurupi - TO
2013
SUMÁRIO
1	INTRODUÇÃO	3
2	OBJETIVO	4
3	DESENVOLVIMENTO	5
3.1 Banco de dados orientado a objetos	5
3.1.1	Aplicação e seu mecanismo de funcionamento.	5
3.1.2	Diferença entre banco de dados orientado a objeto e banco de dados relacional	5
3.2	Orm (object relational mapper) – mapeamento objeto relacional	5
3.2.1	Como desenvolver utilizando o modelo orientado a objetos com um banco de dados relacional	8
3.2.2	O que é ORM e para que é utilizado.	9
3.2.3	Quais ferramentas estão disponíveis hoje no mercado.	10
Arquitetura	11
Vantagens	11
Desvantagens	12
Ferramentas Auxiliares	12
Fluent NHibernate	12
ConfORM	14
Entity Framework	14
4	CONCLUSÃO	17
REFERÊNCIAS	18
INTRODUÇÃO
Neste trabalho será abordada toda a matéria do 4º Semestre, dentro deste contexto serão apresentados às vantagens do diagrama de estado e do diagrama de implantação.
Em relação às questões éticas, como elas seriam trabalhadas na prática e como seria a noção de uma empresa socialmente responsável no cenário proposto e quais projetos possíveis de responsabilidade social desta empresa.
No contexto do cenário proposto será mostrado um Stored Procedure para cadastrar um livro no banco de dados.
Serão apresentadas também duas ferramentas para se fazer ORM, bem como a explanação sobre o que é ORM e seus paradigmas.
OBJETIVO
Tem-se como objetivo desta produção textual o aprofundamento dos conteúdos estudados durante o semestre, bem como a aplicação prática de alguns conceitos vistos no decorrer das matérias.
 DESENVOLVIMENTO
3.1 Banco de dados orientado a objetos
Aplicação e seu mecanismo de funcionamento.
Diferença entre banco de dados orientado a objeto e banco de dados relacional
Os diagramas de implantação não são importantes somente para visualizar, especificar e documentar sistemas embutidos, cliente/servidor e distribuídos, mas também para o gerenciamento de sistemas por engenharia de produção e engenharia reversa.
Os diagramas de implantação são empregados para modelagem da visão estática de implantação de um sistema. Essa visão direciona primariamente a distribuição, entrega e instalação das partes que formam o sistema físico. Na maior parte, isso envolve a modelagem da topologia do hardware em que o sistema é executado. Os diagramas de implantação são essencialmente diagramas de classes que focalizam os nós do sistema.
Orm (object relational mapper) – mapeamento objeto relacional
Mapeamento de Objeto Relacional (ORM) é uma abordagem que permite a construção de sistemas utilizando o paradigma orientado a objetos com a persistência destes objetos em bancos de dados relacionais. Utilizando-se de técnicas e estratégias específicas, é possível mapear classes com seus atributos e associações para o modelo relacional (SILVA, 2006).
 Segundo (AMBLER, 1999), “o mapeamento de classes pode ser feito mediante a paridade entre classe e tabela, ou seja, uma classe é mapeada para uma tabela”. Este mapeamento direto de classes para tabelas representa a forma mais simples de mapeamento, tornando mais fácil o entendimento e a manutenção de uma aplicação.
Mapeamento de Tabelas – Simples
Porém, nem sempre o mapeamento é tão simples assim. No caso de uma estrutura hierárquica, várias classes podem ser mapeadas para uma tabela, bem como uma classe pode ser mapeada para várias tabelas.
Mapeamento de Tabelas – Complexo
As tabelas Classe1 e Classe2 possuem, respectivamente, relacionamento com as tabelas Tabela1 e Tabela3. Esse mapeamento seria de certa forma trivial, e poderia ser tratado como relacionamento simples. Um terceiro relacionamento feito pelas duas tabelas impossibilita esse tratamento, pois ambas possuem atributos na Tabela2. Dessa forma é necessário que haja uma especificação de quais atributos pertencem a cada classe.
Ao tratar do mapeamento de atributos de uma classe para colunas em tabelas de um banco de dados relacional, deve-se levar em conta que os atributos podem ser de tipos de dados primitivos como inteiros, pontos flutuantes, caracteres, booleanos e binários, bem como ser de tipos de dados complexos como tipos baseados criados pelo usuário. Os atributos podem ser ainda multivalorados, o que viola as regras de normalização do modelo relacional.
Além disso, podem existir atributos de controle ou utilizados em cálculos, que geralmente não necessitam serem mapeados (AMBLER, 1999). Desta forma, os atributos simples podem ser mapeados diretamente para colunas em uma tabela, já os atributos complexos e multivalorados podem necessitar de tabelas adicionais para seu armazenamento. Estes atributos complexos, geralmente, possuem características recursivas, ou seja, são classes que possuem outros atributos e, assim, sucessivamente.
O mapeamento segue o seguinte conceito: as classes mapeiam cada uma das tabelas do banco de dados de modo que as linhas dessas tabelas se tornam objetos e as colunas referem-se aos atributos dessa classe.
Mapeamento de Tabelas, Objetos e Atributos
Essa técnica possibilita mais do que códigos limpos, permite que persistências de objetos no banco de dados sejam feitas sem simples e transparente.
O ORM se comporta como uma camada que possui uma gama de métodos que cuidam dessa tarefa, tais como: create (cria um novo objeto da classe a partir dos dados da tabela), find (busca um determinado registro no banco e o torna um objeto da classe), delete (exclui registros do banco) e update (atualiza registros de uma tabela de acordo com as solicitações). Esses métodos variam de acordo com a linguagem utilizada.
Na primeira tabela, é possível observar um pouco das facilidades e de como a legibilidade do código fica melhor ao se utilizar o ORM ao invés de se injetar dentro de seu código o SQL puro, o que fere as boas práticas de programação, que sugere que códigos SQL estejam separados dos códigos de desenvolvimento (RODRIGES; COSTA; SILVEIR, 2001).
Essa camada, chamada de persistência, encontra-se entre a camada de negócio (onde estão as classes de domínio da aplicação, ou seja, classes que definem as regras de negócio) e o banco de dados. Esta camada permite que o impacto das modificações em uma delas seja atenuado em relação à outra. Isto diminui o grau de dependência do banco de dados e aumenta a facilidade de manutenção do código. 
Toda responsabilidade por persistir objetos fica a cargo da camada de persistência, liberando a aplicação destas tarefas, e assim aumentando a produtividade no desenvolvimento (YODER; JOHNSON; WILSON, 1998). Na camada de persistência está a definição das estratégias de mapeamento do modelo orientado a objetos para o modelo relacional, apresentadas anteriormente.
 A camada de classes representa todo o conjunto de classes (controllers, views dentre outras) que podem utilizar métodos da camada de persistência. Assim, as transações com o banco de dados ficam transparentes.
Como desenvolver utilizando o modelo orientado a objetos com um banco de dados relacional
Um dos problemas na comunicação entre uma aplicação Java, por exemplo, e um banco de dados é o conflito de paradigmas. O banco de dados é organizado seguindo o modelo entidade relacionamento, enquanto as aplicações Java, geralmente, utilizam o paradigma orientado a objetos.
A transição de dados entre o modelo entidaderelacionamento e o modelo orientado a objetos não é simples. Para realizar essa transição, é necessário definir um mapeamento entre os conceitos desses dois paradigmas. Por exemplo, classes podem ser mapeadas para tabelas, objetos para registros, atributos para campos e referência entre objetos para chaves estrangeiras.
Para facilitar a comunicação entre aplicações Java que seguem o modelo orientado a objetos e os banco de dados que seguem o modelo entidade relacionamento, podemos utilizar ferramentas que automatizam a transição de dados entre as aplicações e os diferentes bancos de dados e que são conhecidas como ferramentas de ORM (Object Relational Mapper).
Outra consequência, ao utilizar uma ferramenta de ORM, é que não é necessário escrever consultas em SQL, pois a própria ferramenta gera as consultas de acordo com a sintaxe da linguagem SQL correspondente ao banco que está sendo utilizado.
O que é ORM e para que é utilizado.
.
Durante o desenvolvimento de software, é evidente a preocupação em que se tem em aumentar a produtividade sem abrir mão da qualidade. No que se refere a banco de dados, é possível a utilização de um framework ORM que nos permita focar mais nas regras de negócios da aplicação do que na persistência de dados em si, permitindo um desenvolvimento mais rápido e consistente. Neste post, você verá os principais conceitos de ORM e alguns .
Visando aproveitar ao máximo o conceito de Orientação a Objetos, o Mapeamento Objeto-Relacional (ORM) consiste em um framework que tem por objetivo suprir as disparidades entre o paradigma orientado a objetos e o modelo entidade-relacional, criando uma ponte (mapeamento) entre o modelo relacional e o modelo orientado a objetos. Ou seja, ao trabalhar com essa abordagem, é possível a construção de sistemas utilizando o paradigma orientado a objetos, cujo os objetos são persistidos em um banco de dados relacional.
Um ORM possui diversos métodos básicos que irão realizar a interação entre a aplicação e o banco de dados, se responsabilizando por algumas tarefas básicas, como o CRUD (Create, Read, Update e Delete), por exemplo. Além disso, o ORM irá gerenciar os detalhes de mapeamento de um conjunto de objetos para um banco de dados.
O ORM reduz ao mínimo a necessidade de escrever códigos de conexão e queries SQL. Dessa forma, é possível obter uma redução significativa nos códigos da aplicação, gerando um código mais elegante e consequentemente ampliando a facilidade de posteriores manutenções na aplicação.
É importante deixar claro que a utilização de um framework ORM não substitui totalmente a necessidade da utilização de SQL na sua aplicação. Embora o ORM satisfaça a maior parte das necessidades de interação com o banco de dados, em alguns casos, haverá a necessidade, por exemplo, de consultas mais customizadas, que terão que ser realizadas por meio de SQL.
A forma como o ORM irá realizar o mapeamento dependerá especificamente do framework utilizado. Neste artigo, iremos abordar algumas soluções e vantagens agregadas com o uso do NHibernate e Entity Framework – dois dos mais conhecidos frameworks voltados especificamente para ambientes .NET – e algumas ferramentas que auxiliam sua utilização.
Quais ferramentas estão disponíveis hoje no mercado.
O NHibernate é um ORM Open-Source, que surgiu através do Hibernate, voltado exclusivamente para desenvolvedores Java, sendo a princípio era um port do Hibernate, mas passou a ser um projeto independente. Sendo assim, apresenta uma certa maturidade, principalmente por ser um framework com uma equipe colaborando ativamente.
Arquitetura
Arquitetura NHibernate
Simplificadamente, o NHibernate funciona da seguinte maneira: na aplicação é realizada a persistência dos objetos normalmente por mapeamento object/relational em um arquivo XML, relacionando tabelas com classes e atributos. Além disso, é necessária a criação de alguns arquivos de configuração que permita que o NHibernate se conecte ao banco e realize as interações. Esses arquivos contêm informações referentes a onde o NHibernate deverá ir buscar e persistir os dados. Normalmente, essas informações são inseridas em uma seção dentro do arquivo de configuração da aplicação (Web.Config ou App.Config).
Vantagens
A utilização do NHibernate trás diversas vantagens durante o desenvolvimento de um projeto. Por ser um port do Hibernate, o framework apresenta uma certa maturidade, proporcionando um projeto com um maior nível de confiabilidade. Além disso, o NHibernate consiste em um framework Open-Source, resultando em uma economia de custos no desenvolvimento do projeto.
Uma outra vantagem do NHibernate é possuir um suporte ativo, uma boa documentação e diversos fóruns sobre o tema.
O NHibernate oferece algumas facilidades em relação a mudanças, tanto no mapeamento quanto no banco de dados, sendo possível fazer com que o NHibernate crie ou atualize o banco de dados para coincidir com o modelo na aplicação.
Desvantagens
Um dos pontos do NHibernate que podem ser considerados negativos é a alta curva de aprendizado devido a complexidade que o framework apresenta. De fato, o que acontece é que existem muitas configurações e otimizações que são desconhecidas para a maioria dos profissionais que o utilizam, requerendo mais estudo e dedicação de quem irá utilizá-la.
Uma outra desvantagem é o trabalho em que se tem para gerar todos os arquivos XML necessários para a realização da persistência.
Ferramentas Auxiliares
Para a utilização do NHibernate, é necessário gerar para cada tabela do banco de dados um arquivo de mapeamento XML, porém existem ferramentas que auxiliam esse processo como o Fluent NHibernate e o ConfORM, descritas a seguir.
Fluent NHibernate
Como citado anteriormente, uma das desvantagens do NHibernate é o trabalho em que se tem para gerar todos os arquivos XML necessários para a realização da persistência. O FluentNHibernate surgiu visando facilitar esse processo, auxiliando na realização dos mapeamentos. Sendo assim, ao invés de usar o padrão de arquivos XML do NHibernate (.hbm) para a realização do mapeamento, o Fluent NHibernate permite realizar o mapeamento pelo próprio código, sem a necessidade de utilizar os arquivos .hbm.
Assim como o NHibernate, o FluentNHibernate consiste em um framework Open-Source. Nas imagens abaixo, é possível ver a facilidade que o FluentHibernate oferece durante a realização do mapeamento se comparado com o NHibernate.
Mapeamento em xml do NHibernate.
Na imagem abaixo, é possível observar a facilidade obtida durante o mapeamento com a utilização do Fluent NHibernate.
Mapeamento utilizando o Fluent NHibernate.
Atualmente, existem outras ferramentas para a geração de mapeamento como o MyGeneration. Diferentemente do NHibernate onde a geração da query SQL é realizada através dos arquivos de mapeamento hbm.xml e .cs, o MyGeneration tem como vantagem gerar esses arquivos de forma rápida e automática para todas as tabelas do banco de dados.
ConfORM
O ConfORM é uma ferramenta que surgiu da necessidade de automatizar o processo de mapeamento do NHibernate através de convenções, ou seja, regras que determinam um padrão a ser seguido.
A principal vantagem do ConfORM é essa possibilidade de definir regras para o mapeamento, o que torna possível determinar que toda propriedade chamada Nome, por exemplo, deverá ter um tamanho de 100 caracteres e não permitir valores nulos. Sendo assim, se no seu projeto contiver 10 propriedades “Nome”, todas serão mapeadas utilizando essa regra.
Diferentemente do NHibernate, o arquivo HbmMapping será gerado automaticamente através das convenções estabelecidas no projeto, sendo posteriormente adicionados diretamente à configuração do NHibernate.
Através do ConfORM, é possível pular o mapeamento em XML, aumentando a produtividade, além de proporcionar uma facilidade de manutenção, pois qualquer alteração será realizada nos arquivos de convenção e não nos arquivos de mapeamento do projeto.
Porém, por ser uma tecnologia relativamente nova, a documentaçãoé escassa, gerando certa dificuldade em sua utilização.
Entity Framework
O Entity Framework consiste em um framework ORM criado pela Microsoft visando ocultar a complexidade das classes ADO .NET e permitir o mapeamento de tabelas como objetos, abstraindo a camada de acesso aos dados. Assim como o NHibernate, o Entity Framework também é Open-Source, podendo ser encontrado aqui. Além do SQL Server, o Entity Framework oferece suporte a outros bancos de dados como Oracle, DB2, MySQL, entre outros.
Arquitetura
No Entity Framework, a modelagem de dados é dividida em três partes, como mostra a figura a seguir:
Arquitetura Entity Framework
O EDM (Entity Data Model) consiste em um modelo de dados Entidade-Relacionamento, formado pelo Modelo Conceitual (Conceptual Model), Lógico (Mapping) e Físico (Storage Model) podendo ser definido pelos seguintes arquivos:
Arquivo de definição de schema conceitual (.csdl): este arquivo contém o Modelo Conceitual, onde são definidas as entidades e os relacionamentos da aplicação.
Arquivo de especificação de mapeamento (.msl): aqui são definidas as informações de como seu Modelo Conceitual será mapeado para um Modelo Físico.
Arquivo de definição schema de armazenamento (.ssdl): aqui é definido o Modelo Físico, que é nada mais do que o seu banco de dados constituído por tabelas, views, stored procedures e seus relacionamentos e chaves.
Além do Entity Data Model, o Entity Framework inclui alguns serviços como mostra a figura abaixo.
Serviços do Entity Framework
O LINQ to Entities e o Entity SQL são linguagens de consultas utilizadas para escrever queries, retornando entidades que são definidas no Modelo Conceitual. A realização das consultas será feita através do ObjectServices. Esse componente também é responsável por retornar dados como objetos. O Entity Client irá converter L2E ou consultas Entity SQL em uma consulta SQL que é entendida pelo banco de dados subjacente. Ele se comunica com ADO.Net Data Provider que por sua vez envia ou recupera dados de um banco de dados, por meio do padrão ADO.Net.
Por fim, um ORM possui diversos recursos para o desenvolvedor estar utilizando em projetos, sendo inegáveis as vantagens providas pela utilização de um ORM, como a redução da impedância que existe entre um banco de dados relacional e os objetos de uma aplicação e o consequente aumento da produtividade e redução do tempo gasto em manutenções. Opções de ferramentas disponíveis no mercado são o que não faltam, porém ao escolher um ORM deve-se estar atento a alguns critérios como a qualidade da documentação oferecida pelo framework, o custo, a curva de aprendizado, performance, entre outros. Esses critérios deveram ser analisados cuidadosamente, de acordo com a necessidade do desenvolvedor e do projeto.
CONCLUSÃO
Através da confecção deste trabalho observou-se o quanto é necessário um projeto do sistema através dos diagramas da UML antes de se iniciar a programação propriamente dita. 
Foi observado que um dos problemas na comunicação entre uma aplicação desenvolvida em uma linguagem orientada a objeto e um banco de dados é o conflito de paradigmas. Para facilitar tal tarefa existe o ORM, Mapeamento de Objeto Relacional, que é uma abordagem que permite a construção de sistemas utilizando o paradigma orientado a objetos com a persistência destes objetos em bancos de dados relacionais.
Notou-se também que os Stored Procedures (procedimentos armazenados), melhoram o tráfego da rede e a performance das aplicações e criam mecanismos de segurança e manutenção dos códigos SQL.
REFERÊNCIAS
TANAKA, Simone Sawasaki. Análise de sistemas III. São Paulo. Editora Pearson, 2012.
FLORES, Emerson Ricardo. Linguagens e técnicas de programação III. São Paulo. Editora Pearson, 2012
<http://www.efetividade.net/2008/01/08/etica-no-trabalho-indo-alem-dos-codigos-de-etica/>
Acessado em: 12/09/2013
<
http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=4&ved=0CDoQFjAD&url=http%3A%2F%2Fwww.rp-bahia.com.br%2Frevista%2Fa_iniciativa_privada_no_contexto_social3.pdf&ei=k29cUM2KB4fM9QSC2YHICg&usg=AFQjCNFUzFm1gH18vci2GTVb5WvcskGHhA&cad=rja>
Acessado em: 21/09/2013
<
http://www.slideshare.net/alexdutra/sql-server-stored-procedures>
Acessado em: 25/09/2013
<http://www.linhadecodigo.com.br/artigo/3428/crud-usando-stored-procedures-e-csharp.aspx>
Acessado em: 07/10/2013
http://www.princiweb.com.br/blog/programacao/aspnet/veja-o-que-e-orm-e-os-frameworks-disponiveis-para-net.html
Acessado em: 07/10/2013