trabalho individual 1 semestre ADS

Prévia do material em texto

SISTEMA DE ENSINO PRESENCIAL CONECTADO
análise e desenvolvimento de sistemas
kaio césar simões pereira de almeida 
bancos de dados e seus objetos
Montes Claros – MG
2014
KAIO CÉSAR SIMÕES PEREIRA DE ALMEIDA
banco de dados e seus objetos
Trabalho apresentado ao Curso Analise e Desenvolvimento de Sistemas da UNOPAR - Universidade Norte do Paraná, para a disciplinas Desenvolvimento Orientado a Objetos; Redes de computadores; Modelagem Orientada a Objetos
Prof. 
Marcio Roberto Chiaveli; Paulo K. Nishitani; Polyanna P. G. Fabris
Montes Claros – MG
2014
SÚMARIO
2 INTRODUÇÃO.......................................................................................................1
3 OBJETIVO.............................................................................................................2
4 DESENVOLVIMENTO ..........................................................................................3
4.1BANCO DE DADOS ORIENTADO A OBJETOS ...............................................4
4.1.1 MECANISMO DE FUNCIONAMENTO............................................................5
4.1.2 DIFERENÇA ENTRE BANCO DE DADOS ORIENTADO
 A OBJETO E BANCO DE DADOS RELACIONAL ...............................................7
4.2 MAPEAMENTO OBJETO RELACIONAL............................................................9
4.2.1. COMO DESENVOLVER UTILIZANDO O MODELO
 ORIENTADO A OBJETOS COM UM BANCO DE DADOS RELACIONAL.............12
4.2.2 O QUE É ORM E PARA QUE É UTILIZADO...................................................13 
4.2.3. QUAIS FERRAMENTAS ESTÃO DISPONÍVEIS HOJE NO MERCADO......14
5 CONCLUSÃO.........................................................................................................17
6 REFERÊNCIAS.......................................................................................................18 
 
 
�
2 INTRODUÇÃO 
A cada dia as empresas dewpendem mais de grandes e crescentes volumes de informação para suas decições de negocio, e essa informação deve estar sempre correta e de fácil acesso. Por isso essas empresas exigem de informação que atendam não só a sua necessidades funcionais, mas também estejam integrados com a necessidade de mudanças no negocio.
Para atender essas necessidades, surgem inúmeros avanços computacionais a fim de possibilitar esses desenvolvimento dos negócios. Entre todos esses avanços computacionais pode – se citar a tecnologia de orientação a objetos. 
 
�
3 OBJETIVO 
É aproximar o leitor de forma simples e comunicativa de como e formado os bancos de dados e para que servem. 
	Entretanto puscando familarizar o conceito complexo do simples sem que passa despercebido como mão apenas usso , mais sabendo o que esta usando e pra que serve tal uso de software. Sem deixar de dizer que o importante não é saber o que fazer e sim pra que o feito está servido , e pra onde vai levar tanta disposição de uso e de entreiterimento de maquina vs homem. 
4. - DESENVOLVIMENTO
4.1 Banco de dados orientados a objetos
BDRs e BDOOs 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 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 BDOO possui três pilares principais: herança, polimorfismo e
encapsulamento, discutidos a seguir. 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.
Modelagem de um BDOO
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. 
Objetos
A modelagem de um banco de dados orientado a objetos está inti
mamente ligada aos diagramas de classes gerados para o sistema. 
Cada objeto possui um estado e comportamentos e é diferenciado por um indicador único (OID ou object identifier). O estado do objeto depende do valor de cada uma de suas propriedades e o comportamento é especificado pelas operações que podem ser executadas pelo objeto, possivelmente, modificando o estado do mesmo. As propriedades podem ser atributos ou relações entre esse objeto e outros objetos que façam parte do domínio do problema. Em um banco de dados orientado a objetos o estado de um objeto consiste no valor de cada uma das suas propriedades, sejam atributos do próprio objeto ou relações com outros objetos. Os valores de atributos podem ser bastante complexos, tendo apossibilidade de serem, inclusive, outros objetos. Os relacionamentos também influenciam no estado do objeto e podem ser binários, ligando dois objetos, logo, potencialmente influenciando o estado de ambos.
Classes
Classes são agrupamentos de objetos de um mesmo tipo, que possuem comportamentos (operações) e propriedades (atributos e relações) em comum. Os tipos de objetos (classes) podem ser utilizados como domínios para propriedades ou argumentos para operações. Os bancos de dados orientados a objetos possibilitam que novos tipos sejam criados para se adequar aos requerimentos de cada aplicação, podendo ser combinados com os tipos já existentes no sistema e sendo utilizados exatamente da mesma maneira.
Herança
Uma classe pode ser derivada de outra classe, em um processo conhecido co
mo especialização. Por exemplo, a classe Veículo exibida na Figura 1 é um molde para quaisquer objetos veículo que se necessite criar. Cada objeto deve ser único e se torna uma instância da classe à qual pertence. 
A herança permite que uma classe seja estendida por outra classe. Tomando o 
exemplo da classe Veículo, pode - se estendê - la, adicionando atributos e comportamentos para atender ao problema, como uma. A partir desse 
conceito básico, é possível supor que exista uma infinidade de classes que podem ser derivadas de Veículo, especializando atributos e comportamentos. Essa característica torna- se bastante útil quando da necessidade de expressar um problema que envolva diversos tipos com atributos e/ou operações em comum mas que possuam particularidades inerentes a algumas classes.
4.1.1 Mecanismo de funcionamento 
	Os Bancos de Dados Orientados a Objetos possuem uma característica importante que é o armazenamento de objetos e suas operações de maneira a fornecer uma ligação transparente com a aplicação, sem a necessidade de uma camada de tradução dos dados, como ocorre com os Bancos de Dados Relacionais.
	Os BDOO surgiram para oferecer uma alternativa de suporte às operações onde os bancos de dados relacionais não eram capazes ou eficientes. Cabe ressaltar o notável crescimento do paradigma de orientação a objeto nas novas aplicações computacionais, motivo ligado diretamente ao crescimento da utilização dos BDOOs. Assim, muitas vantagens são oferecidas por esse modelo de armazenamento, como a persistência de tipos de dados complexos e a representação dos dados e das operações de um objeto que também são persistidos. Os Banco de Dados Orientado a Objetos sugiram da necessidadede 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.
O objeto é formado como se fosse uma tripla (i, c, v), onde o i é o OID doobjeto, o c é um construtor, ou seja, que tipo de valor ele vai receber ex.: atom, tuple,set, list, bag, array e v é o valor corrente. Então o objeto passa a suportar aquilo que foi definido para ele. Se ele vai receber um valor atômico ele só aceitará valores atômicos.
Os construtores de tipos sets, bags, lists e arrays são caracterizados como
tipos de coleções e a diferença entre eles é a seguinte: sets e bags, o pr
imeiro só aceita valores distintos enquanto o segundo aceita valores duplicados. Lists e arrays, o primeiro só aceita números arbitrários, enquanto o segundo, o tamanho deve ser pré - estabelecido.
Umas das características dos sistemas OO é ocultar informação e tipos
abstratos de dados, sendo que é muito complicado aplicar esse modelo na prática.Por exemplo, nos sistemas atuais para uma consulta em uma determinada tabela é necessário saber todos os atributos da tabela, para formar a consulta. Em um sistemaOO, que preza pelo encapsulamento nem toda tabela pode enxergar a outra, o que dificultaria muito as consultas.
4.1.2 Diferença entre banco de dados orientado a objeto e banco de dados relacional.
Analisando de forma sucinta o SGBDOO, temos respectivamente um banco que facilita a aproximação do mundo real, devido a trabalhar com orientação a objetos e suas características (herança, encapsulamento, abstração, polimorfismo), um banco que permite a manipulação de dados complexos, mesmo com desempenho inferior ao relacional e que possui um pobre nível nas consultas dos dados. Continuando a analise só que de um SGBDR, temos um banco que atua a um bom tempo no mercado pelo fato de se ter anos de desenvolvimento, investimentos e aperfeiçoamentos, um banco com desempenho superior aos SGBDOO, um SGBD que apresenta ricas consultas e que possui dificuldade em manipular dados complexos. 
Como podemos notar no parágrafo acima temos em cada tipo de SGBD citado, vantagens e desvantagens nos mesmos. Então se notou a carência de um SGBD que tivesse a capacidade de manipular dados complexos, que se adequasse ao paradigma de programação atual (orientação a objetos), que tivesse bom desempenho e que demonstrasse ricas consultas de dados. É a partir dessas vantagens de cada SGBD que se fundamenta o SGBDOR. O SGBDOR emprega um modelo que coloca a orientação a objetos em tabelas, unindo os dois paradigmas em um só. Utiliza os conceitos de supertabelas, supertipos, herança, reutilização de código, encapsulamento, controle de identidade de objetos (OID), referência a objetos, consultas avançadas e alta proteção dos dados. 
Com esse novo conceito surgiu à necessidade de uma linguagem padrão para o uso com o SGBDOR. É a partir daí que nasce o SQL-3, que na verdade é uma extensão do SQL-2 complementado com características do modelo objeto-relacional. Alguns exemplos de aplicações que utilizam SGBDOR são os seguintes: armazenamento de imagens (obtidas por satélite ou de alguma outra forma digital); projetos de arquitetura; dados sobre o espaço (regiões geográficas, criação de mapas), sistemas de informações geoespaciais, entre outros. 
Os SGBDs relacionais possuem uma característica muito importante: são extremamente confiáveis e mais eficientes, se comparados à maioria dos SGBDs orientados a objetos disponíveis no mercado. Além disso, 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.
Através da linguagem de consulta SQL (Structured Query Language) é possível fazer a busca e recuperação dos dados necessários de forma bastante eficiente.
Dentre as vantagens do modelo relacional, talvez a mais importante esteja relacionada com a persistência dos dados. As regras e rotinas para tratamento da persistência dos dados podem ser criadas no próprio banco de dados relacional.
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.
4.2 Mapeamento Objeto 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 úttimos 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´s como Hibernate, NHibernate, Entity Framework e etc.
 
 
     
Tudo começa como mostrado na figura acima, existem 2 mundos: o relacional e o orinetado a objetos, 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 dados, 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 anco de dados e cada ORM tem suas particularidades, para gerar o SQL referente a 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 deixa-se de escrever os comando SQL para deixar que o próprio ORM, faça isto por você.
	
�
4.2.1. Como desenvolver utilizando o modelo orientado a objetos com um banco de dados relacional. 
Os dados não trabalhados são armazenados no disco usando o sistema gerenciador de arquivos,que geralmente ́e oferecido por algum sistema operacional. O SGBD traduz os comandos da linguagem de manipulação de dados (DML) em comandos de baixo nível do gerenciador de arquivos.
Sendo assim a simplifcação de banco de dados com relacinamento e forma simples . Tendo os dados e diagramas e toda uma equipe facilita , pois os dados estão relacionados a uma forma de editar e projetar certo programa. A organização desses dados relacionais não são , totalemnte voltados ao BDOO, sendo assim a formção desse modelo é concluisva e xplicativa.
Exemplo focativo , tento um objeto de caso seja de uso , como forma comunicativa de cliente para servidor o relacionamento e dado pela interface desse metodo e do banco de dados e so a conclusão de organização. A construção bem sucedida gera a forma comunicativa perfectivamentefuturistica e expansiva.
4.2.2 O que é ORM e para que é utilizado. 
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.
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.
4.2.3. Quais ferramentas estão disponíveis hoje no mercado. 
Infelizmente, os termos "ORM" e "problemas de performance" freqüentemente caminham juntos. Ao ocultar o SQL dos desenvolvedores, ORMs pode oferecer um aumento de produtividade enorme. Infelizmente, eles tornam mais fácil gerar consultas ridiculamente ruins, sem percebermos. Administradores de base de dados normalmente conseguem achar erros em códigos fazendo referência cruzada do stored procedure culpado com os códigos que o chama. Mas com o SQL gerado dinamicamente que os ORM dependem, esse truque raramente funciona. Então vamos dar uma volta em torno de algumas ferramentas para "profilling" de ORMs.
NHibernate
NHibernate Profiler (NHProf) inclui o que você esperaria de um produto básico. Além de manter estatísticas gerais, ele mostra uma lista de consultas recentes com o SQL completo e os "back-traces" que o codigo chama com seus "stack traces". A interface é limpa e bem referenciada, tornando mais fácil mudar de uma análise de consulta isolada, por exemplo, para todas as consultas utilizas em um bloco de código.
A melhor vantagem para NHibernate Profiler é recurso de alertas. Alguns alertas indicam problemas imediatos como erros de banco de dados ou usando acidentalmente uma sessão com varias threads. Outros alertas indicam a possibilidade de problemas como um grande numero de escritas individuais que provavelmente poderiam ser agrupadas dentro de um único lote. Existem também alertas que avisam sobre problemas que podem ocorrer no futuro como conjunto de resultados fora de limites.
Um conjunto de resultados sem limites é quando uma consulta é executada e não e' explicitamente limitado o número de resultados retornados usando setMaxResults () com NHibernate ou TOP ou cláusulas LIMIT no SQL. Normalmente, isso significa que a aplicação assume que uma consulta sempre retornará apenas alguns registros. Isso funciona bem em desenvolvimento e nos testes, mas é uma bomba-relógio prestes a explodir na produção.
O lado negativo do NHibernate Profiler é que ele é um pouco invasivo. Você não pode anexar a um processo em execução, tem que ser configurado por fora. Embora a maneira recomendada é a de incluir uma referência à NHibernate Profiler diretamente no seu código, os usuários do log4net também pode ativar o perfil através de uma configuração app.config.
NHibernate Profiler é um produto comercial que começa em cerca de US $ 300 dólares por usuário.
LINQ to SQL
DataContext logging é a primeira coisa que os desenvolvedores provavelmente vai considerar quando tiver olhando problemas de LINQ para SQL. O objeto DataConext tem uma propriedade de log que encaminha todos os SQLs que sao gerados para um TextWriter da sua escolha Apesar de livre e de graça, o grande volume de linhas de SQL que ele gera torna questionável o uso em aplicações não-triviais.
LINQ to SQL Profiler (L2SProf) é pela mesma empresa que construiu NHibernate Profiler e parece trabalhar de uma forma similar. Além de fazer profilling em tempo real, você pode configurá-lo para gravar os arquivos de log a ser analisado posteriormente. Como NHProf, o valor é de cerca de US $ 300 dólares por usuário. Atualmente ele está em fase beta.
Huagati Query Profiler é outro profiler invasivo. Eles dizem que o “componente runtime são feitos para serem integrados e distribuídos com aplicações que usam tanto o Linq-para-SQL, ou LLBLGen Pro para acessar o SQL Server.” Felizmente o Profiler pode ser ligado e desligado em tempo de execução, conforme necessário.
A interface de usuário para Huagati é totalmente arcaica. É constituída uma grande grid que toma conta de metade da tela com os SQLs e stack traces abaixo dela. Falta-lhe todas as minúcias que NHProf / L2SProf tem como alertas e tela de informações, mas ele tem uma característica atraente para o desenvolvedor de baixo nível, o detalhe.
O Profiler da Huagati é não informa apenas durações absolutas e contagens de linha, realmente vai fundo e tira todas as informações que o SQL Server disponibiliza.Em vez de apenas ver o tempo de reposta, você começa a ver as informações importantes, como quanto tempo foi gasto com a compilação da consulta versus tempo de execução. Leituras e escritas (E/S) estão inclusas e você ainda pode ver o plano de execução.
Huagati Query Profiler é um produto comercial, que começa em US $ 50 dólares para uma versão limitada e US $ 120/usuário para a versão completa.
ADO.NET Entity Framework
A história aqui é francamente lamentável. Primeiro de tudo, nvocê nem tem o log de SQL básico, como o que está disponível no LINQ para SQL. Além disso, parece que ninguém está desenvolvendo profilers para trabalhar com ele.
5 . Conclusão 
Com o crescimento da utilização dos conceitos OO para odesenvolvimento de aplicações de alto nível, torna – se cada vez mais necessário que se utilize uma forma de armazenamento em os objetos possam ser modelados e armazenados sem que haja a necessidade de transformação dos mesmos. 
A necessidades de funcionalidade e desempenho da nova dimensão da computação exigem bancos de dados que transcendam os limites do modelo racional. Com a utilização dos conceitos de OO é possível um representação realista do mundo dos dados complexos. 
Ao estudar BDOO percebe-se que sua conceituação traz recursos antes não exitentes em bancos de dados puramente relacionais. Estes recursos surgiram pelo 
Largo uso de linguagens de programação. 
�
6 Referências 
http://conged.deinfo.uepg.br/artigo4.pdf
http://www.salesiana.edu.br/si/edicao3/banco_de_dados_orientado_a_objetos.pdf
http://rafaeloliveirav.wordpress.com/2009/06/19/artigo-comparativo-entre-banco-de-dados-orientado-a-objetos-bdoo-e-bancos-de-dados-objeto-relacional-bdor-parte-2/
: ORM : Object Relational Mapper http://www.devmedia.com.br/orm-object-relational-mapper/19056#ixzz302tRr6yT
http://www.princiweb.com.br/blog/programacao/aspnet/veja-o-que-e-orm-e-os-frameworks-disponiveis-para-net.html
http://www.infoq.com/br/news/2009/11/ORM-Profiling