Portfólio Individual_Banco de Dados_Quarto Semestre

Prévia do material em texto

UNIVERSIDADE NORTE DO PARANÁ
Análise e Desenvolvimento de Sistemas
RICARDO ANTONIO COIMBRA
São Paulo
2014
RICARDO ANTONIO COIMBRA
Banco de Dados
 São Paulo
2014
Coimbra, Ricardo Antonio - Banco de Dados 2014 – Análise e Desenvolvimento de Sistemas - UNOPAR
RESUMO
Os dados em uma empresa devem ser guardados com o máximo de cuidado e segurança. Para que as informações permaneçam íntegras, utiliza-se o Banco de Dados. Esta tecnologia proporciona o que há de mais moderno em segurança e integridade de dados.
Este trabalho, sucinto, aborda apenas o Banco de Dados Orientado a Objetos e seus conceitos.
Sumário
Introdução........................................................................................................05
Objetivo............................................................................................................06
1 – Banco de Dados........................................................................................06
2 – Banco de Dados Orientado a Objetos.......................................................07
2.1 – Persistência de Objetos..........................................................................07
2.2 – Objetos Complexos................................................................................07
2.3 – Identificador de Objetos..........................................................................07
2.4 – Classes e Métodos.................................................................................07
3 – Banco de Dados Relacional e Banco de Dados Orientado a Objetos.......10
4 – Desenvolver OO com Banco de Dados Relacional...................................10
5 – ORM (Object Relational Mapper – Mapeamento Objeto Relacional)........12
6 – Vantagens e Desvantagens ORM.............................................................14
Conclusão........................................................................................................15
Referências......................................................................................................16
Introdução
Nas décadas de 1960 e 1970 a IBM (International Business Machines) percebendo que o custo da contratação de muitas pessoas responsáveis em armazenar dados e organizar arquivos era muito alto, iniciou algumas pesquisas a fim de reduzir os custos. Com isso desenvolveu modelos hierárquicos, de rede e relacionais e outros modelos.
Em 1970, um pesquisador da IBM, Ted Codd, publicou o primeiro artigo sobre bancos de dados relacionais. Esse artigo discutia o uso de cálculo e álgebra relacional para permitir que usuários não técnicos armazenassem e recuperassem grande quantidade de informações.
O primeiro sistema comercial de banco de dados foi construído pela Honeywell Information Systems Inc., cujo sistema foi lançado em junho de 1976. O sistema era baseado em muitos princípios do sistema que a IBM havia concebido, mas foi modelado e implementado fora da IBM.
Outros sistemas de banco de dados apareceram no início dos anos 80 com a empresa Oracle através do Oracle 2 e depois com a IBM através do SQL/DS, servindo como sistema e depósito de informações de outras empresas. 
As pesquisas evoluíram e o Sistema R tornou-se DB2 (banco de dados desenvolvido pela IBM), com isso foi criada uma linguagem chamada SQL (Structured Query Language), Linguagem de Consulta Estruturada que até hoje é a linguagem mais utilizada no dia a dia. 
Na década de 1990 surgiram outros bancos de dados, como o DBase III, Paradox,  SQL Server, MySQL e muitos outros.
Nesse período de 1980 e 1990, também surgiu o conceito de banco de dados orientado a objetos (BDOO), objeto deste trabalho, suprindo assim as necessidades onde os bancos relacionais não eram aplicáveis para resolver certos problemas em algumas áreas, tal como medicina, multimídia, física elevada, dentre outros. 
Objetivo
O objetivo deste trabalho é dar uma visão resumida do sistema BDOO e seus conceitos.
Banco de Dados
Em linguagem mais clara, um banco de dados é simplesmente um conjunto de informações onde os dados são organizados de forma lógica e estruturados. O cadastro de peças de um almoxarifado, por exemplo, é um banco de dados. Nele podemos cadastrar um novo item do estoque, alterar algum existente ou excluir algum em desuso. 
Um Sistema Gerenciador de Banco de Dados (SGBD) é o conjunto de programas de computador responsáveis pelo gerenciamento de uma base de dados. O principal objetivo é retirar da aplicação cliente a responsabilidade de gerenciar o acesso, manipulação e organização dos dados. O SGBD disponibiliza uma interface para que os seus clientes possam incluir, alterar ou consultar dados. Em Banco de Dados Relacionais a interface é constituída pelas APIs ou drivers do SGBD, que executam comandos na linguagem SQL.
Banco de Dados Orientado a Objetos
Um Banco de Dados Orientado a Objetos é um banco de dados em que cada informação é armazenada na forma de objetos, ou seja, utiliza a Estrutura de dados denominada Orientação a objetos, muito utilizada nas linguagens mais modernas. 
Existem dois fatores principais que levam a adoção da tecnologia de Banco de Dados Orientado a Objetos. A primeira, é que em um Banco de Dados Relacional se torna difícil de manipular com dados complexos (esta dificuldade se dá porque o modelo relacional se baseia menos no senso comum relativo ao modelo de dados necessário ao projeto e mais nas contingências práticas do armazenamento eletrônico). Segundo, os dados são geralmente manipulados pela aplicação escrita usando linguagens de programação orientada a objetos, como C++, C#, Java, Python ou Delphi (Object Pascal), e o código precisa ser traduzido entre a representação do dado e as tuplas da tabela relacional, o que além de ser uma operação tediosa de ser escrita, consome tempo. Esta perda entre os modelos usados para representar a informação na aplicação e no banco de dados é também chamada de “Perda Por Resistência”. Os conceitos de OO básicos para a estrutura de um BDOO são:
Persistência de objetos
Objetos complexos
Presença de identificadores de objetos
Mecanismos de herança e métodos
Persistência de Objetos
Sem duvida nenhuma, a persistência de objetos é uma característica primordial para os BDOO, pois além de ser uma característica que possibilita diferenciar BDOO das linguagens de POO, ela também é fundamental para os BDOO. 
Persistência de objetos consiste em não deixar com que objetos deixem de existir, diferente de um programa OO que ao finalizar a execução, todos os objetos instanciados deixam de existir. Com isso os valores dos atributos do objeto também desaparecem. Se isso fosse aplicado aos BDOO, o resultado seria desastroso, pois os dados que serão inseridos em um BDOO na forma de atributos de objetos devem existir mesmo após o encerramento do programa de gerenciamento, tendo seu estado armazenado em um meio físico persistente, a menos que os atributos sofram algum tipo de alteração ou exclusão, sendo estas solicitadas pelo usuário. 
Para que os BDOO funcionem, é preciso aplicar a persistência de objetos em sua estrutura, a fim de que os dados não desapareçam. 
Existem várias formas de tornar o objeto persistente. Ei-las: Por tipo de classe onde os objetos pertencentes às classes assim declaradas serão persistentes.
Por referência onde objetos referenciados por objetos persistentes (objetos raízes) também se tornam persistentes.
Por chamada explícita onde o objeto pode se tornar persistente após a sua criação através de comandos reservados.
Objetos Complexos
O modelo de OO suporta a representação das abstrações e comportamento dos objetos. Com isso os BDOO incorporam as características dos objetos da linguagem de POO integrada com noções de estrutura de dados e de comportamento. O conjunto de atributos descreve o estado interno dos objetos. Cada “ocorrência” do objeto no Banco de Dados é denominada de instância do objeto. A estrutura de objetosem banco de dados é muito similar ao conceito de entidades, quando aplicado ao MER. 
Para uma representação direta de objetos complexos, dos quais nos modelos relacionais não possuem representação, proposta a utilização do modelo de dados das linguagens orientadas a objetos a primeira forma normal não é respeitada nos BDOO, pois podemos representar em um objeto valores não atômicos, como conjuntos, listas, vetores etc.
Assim como nas linguagens orientadas a objetos, a representação se torna extremamente fácil devido a esse fato (não normalizado). 
Identificador de Objetos
Nos BDOO, os identificadores de objetos (OID) têm uma identidade muito mais forte que na linguagem de POO, pois nos BDOO, os objetos têm a necessidade de continuarem a existir mesmo após a execução do programa. Isto ocorre devido ao fato de os objetos poderem voltar a ser usados posteriormente. 
O OID deve ser único e imutável durante toda a existência dos objetos e também deve ser valido para todo o banco de dados uma vez que ajudam na recuperação do objeto e são utilizados para estabelecer relacionamentos entre os objetos. 
Classes e Métodos
Todo o conceito e característica de classe e herança da OO devem estar presentes em BDOO. Diante disso, outra importante capacidade em BDOO é o gerenciamento do conceito de herança dentro de uma hierarquia de classes armazenáveis. Da mesma forma que em linguagem de POO, os BDOO podem criar novas classes em função de classes já existentes. 
Uma hierarquia de classes oferece muito mais flexibilidade para efetuar alterações na estrutura de um BDOO (incluindo novos atributos ou métodos nos objetos) bem como possibilita a evolução do esquema de banco de dados através da adição de classes novatas na hierarquia. 
As “classes do sistema” são um exemplo típico da característica de herança dentro de um SGBDOO. Isto porque a maioria dos SGBDOO possuem uma coleção de classes e objetos dentro de sua estrutura. Essa coleção esta estruturada de forma hierárquica. Caso necessário, uma determinada aplicação pode herdar atributos e métodos dessas classes de sistema a fim de implementar suas próprias classes. Em ressumo essas classes do sistema de SGBDOO possuem métodos que têm como propósito o armazenamento, manipulação, controle de concorrência entre outras funções. 
O conceito de encapsulamento para BDOO continua sendo o mesmo, porém, quando se faz uma consulta ao banco de dados, não é possível prever todas as consultas e atualizações que o usuário possa desejar. Assim, não se pode agregar todos os métodos nas classes de antemão. 
Sendo assim pode-se considerar que o encapsulamento não é adequado aos BDOO em algumas situações, entretanto o encapsulamento é uma das características fundamentais para POO e descartar o seu uso em BDOO pode descaracterizar parcialmente o conceito de OO. 
Banco de Dados Relacional e Banco de Dados Orientado a Objetos
BDR e BDOO 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 visíveis. 
Desenvolver OO com Banco de Dados Relacional
Mapeamento Objeto Relacional é persistir de maneira automática e transparente os objetos de um aplicativo para tabelas em um banco de dados relacional, ou seja, transforma dados de uma representação para a outra.
No desenvolvimento de um sistema, muitas vezes o programador dedica boa parte do tempo de desenvolvimento construindo comandos de instruções SQL para realizar a persistência dos dados no banco de dados relacional. Conforme a Figura 1, o aplicativo precisará de uma camada de mapeamento objeto relacional, que irá traduzir as estruturas e operações do sistema orientado a objetos para o banco de dados relacional.
O mapeamento objeto relacional faz a persistência automática de dados de uma representação para outra. Persistência se trata do armazenamento de dados que estão em meio volátil, como a memória RAM, para dispositivos de memória secundária, o disco rígido, por exemplo. Consiste em manter em meio físico recuperável, como banco de dados, arquivo etc. Quando se fala de persistência em linguagem de POO, normalmente a preocupação é de como armazenar dados em um banco de dados relacional.
ORM (Object Relational Mapper – Mapeamento Objeto Relacional)
Segundo Bauer (2005, p.23) Mapeamento Objeto Relacional é “persistir de maneira automática e transparente, os objetos de um aplicativo para tabelas em um Banco de Dados Relacional. Em essência, transforma dados de uma representação para a outra”. Mapeamento objeto relacional faz a persistência automática de dados de uma representação para outra e trata do armazenamento de dados que estão em meio volátil, como a memória RAM, para dispositivos de memória secundária, o disco rígido, por exemplo. Consiste em manter em meio físico recuperável, como banco de dados, arquivo etc. Quando se fala de persistência em linguagem de programação orientada a objetos, normalmente a preocupação é de como armazenar dados em um banco de dados relacional (BAUER, 2007, p. 05). 
Persistência em Banco de Dados Relacionais: O banco de dados relacional suporta criação e alteração de tabelas, inserção, atualização e exclusão de dados, agrupamentos, ordenação e agregação. Sua conexão com o sistema se dá através de uma interface de programação (API - Application Programming Interface) de conectividade do banco de dados, que é responsável em fazer o envio de instruções SQL para o banco de dados relacional. A tarefa de persistir objetos utilizando instruções SQL através da API de conectividade é muito trabalhosa e tediosa, o que pode gerar erros no desenvolvimento do sistema (BAUER, 2007, p. 22). 
Persistência em Banco de Dados Orientado a Objetos: persistência em banco de dados orientados a objetos trabalha com um banco de dados puramente orientado a objetos. Seu funcionamento se dá com o armazenamento de dados organizados em hierarquias de classes e não em tabelas. O problema é que este tipo de banco de dados não possui uma utilização muito difundida devido a sua falta de padronização. Suas APIs possuem diferenças de um banco de dados para outro, não permitindo assim uma portabilidade do sistema, o que não é bom, uma vez que dentro da comunidade de desenvolvedores de sistemas orientado a objetos o que é mais valorizado é justamente a padronização e portabilidade de um sistema (DOEDERLEIN, 2005, p.22).
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 estamos usando. Por exemplo: o programador que use Hibernate na linguagem Java pode usar ficheiros XML ou o sistema de anotações que a linguagem providencia.
Visando aproveitar ao máximo o conceito de OO, o Mapeamento Objeto-Relacional (ORM) consiste em um framework que tem por objetivo suprir as disparidades entre o paradigma OO e o modelo entidade-relacional, criando uma ponte (mapeamento) entre o modelo relacional e o modelo OO. Ou seja, ao trabalhar com essa abordagem, é possível a construção de sistemas utilizando o paradigma OO, 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 elegantee 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.
Hoje no mercado há várias ferramentas ORM disponíveis, segue uma lista de algumas ferramentas mais utilizadas no mercado:
NHibernate
LonqConnect
LLBLGEN
SubSonic
Persistor
Hibernate
Linq To SQL
Entity Framework
Gentle
 Vantagens e Desvantagens 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 as chamadas estarem totalmente isoladas e “automáticas” do ponto de vista da camada de domínio da aplicação. Em Java, temos o JPA (Java Persistence API), que descreve uma especificação dizendo como os fabricantes devem desenvolver seus frameworks, algo que é muito interessante, pois isso possibilita a troca de uma implementação por outra quase sem alterações (a menos que esteja usando algum recurso fora da especificação). Se mudamos nossa base Oracle, podemos trocar nosso ORM de Hibernate para TopLink, por exemplo, em troca de um possível ganho de performance. Em outras linguagens temos o ADO.NET para .NET, ActiveRecord para Ruby, no próprio Java temos IBates, etc.
Desvantagens
Existem alguns contras que é preciso considerar quando se decide usar algum tipo de ORM. A primeira grande desvantagem é a performance. Num ambiente relacional, temos todos aqueles algorítimos que os bancos de dados usam para a recuperação dos dados que 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. À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 professor, por exemplo, contém tudo dentro de um objeto professor. De outra forma teríamos, na vida real um objeto professor e outro DadosProfessor. Para resolver esse problema é possível recorrer a alguns padrões (Factory, DAO, Repository), mas como percebe-se, a complexidade foi elevada.
Conclusão
Persistência dos dados sempre será o maior foco da maioria dos projetos de aplicativos, pois o maior interesse do usuário é manter os dados salvos, de fácil acesso, tanto na agilidade quanto na disponibilidade. 
Os bancos de dados evoluíram nos últimos anos. Hoje um SGBD oferece muitos recursos que facilita a organização e a disponibilização da informação, uma vez que a disponibilização necessita de uma política rígida, pois nem todos os usuários podem acessar qualquer tipo de dado. 
O banco de dados relacional, sem dúvida, ainda apresenta o melhor desempenho, melhor disponibilidade, maior facilidade na configuração da segurança dos dados, além de outras características, e ainda conta com um grande número de usuários. Apesar do crescimento da POO, os BDOO não conseguiram apresentar características melhores ou pelo menos semelhantes ao modelo relacional, por isso o seu uso é pouco expressivo.
Apesar do modelo relacional possuir todas essas características, a comunidade de desenvolvedores da OO ainda sonham em facilitar o seu trabalho, jogando a maioria das funções SQL para um framework ORM. Esses frameworks trazem bastante benefícios para o desenvolvedor, porém eles precisam ser utilizados com cuidado, pois em um caso de consulta, eles trazem todos os dados da tabela consultada para a aplicação, ficando assim ao cargo do desenvolvedor filtrar os dados que serão exibidos para o usuário em linha de programação. Esse processo faz com que a aplicação se torne um pouco mais lenta, por isso cabe uma análise por parte dos analistas e programadores antes de fazer uso do framework.
Referências
http://www.oficinadanet.com.br/artigo/1764/aula_01_-_curso_de_ms_access_-_o_que_e_banco_de_dados_
http://topicosdeinformaticaadm.blogspot.com.br/
http://pt.wikipedia.org/wiki/Banco_de_dados_orientado_a_objetos
http://www.ufpa.br/sampaio/curso_de_sbd/bdoo/apostila/basico.html
http://www.macoratti.net/net_oocb.htm
http://www.grupointegrado.br/conccepar2011/?action=anais_resumo&id=768
http://evieira.wordpress.com/2009/04/08/or-mapping-vale-a-pena/
http://www.metropoledigital.ufrn.br/aulas_avancado/web/disciplinas/banco_de_dados/aula_01.html