BANCO DE DADOS

SISTEMA DE ENSINO A DISTÂNCIA - EAD

ANÁLISE DE SISTEMAS DA INFORMAÇÃO

HELTON CLEYTON MARINHO

Carpina

2013

 

HELTON CLEYTON MARINHO

Trabalho 4 período elaborado à Universidade do Norte do Paraná – UNOPAR.

Orientador: Eristhon Hugo.

Carpina

2013

SUMÁRIO

1 INTRODUÇÃO 4

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

3DESENVOLVIMENTO........................................................................6 A 15

4CONCLUSAO....................................................................................7

5BIBLIOGRAFIA.................................................................................8

INTRODUÇÃO

Um banco de dados (sua abreviatura é BD, em inglês DB, database) é uma entidade na qual é possível armazenar dados de maneira estruturada e com a menor redundância possível. Estes dados devem poder ser utilizadas por programas, por usuários diferentes. Assim, a noção básica de dados é acoplada geralmente a uma rede, a fim de poder pôr, conjuntamente, estas informações, daí o nome banco. Fala-se, geralmente, de sistema de informação para designar toda a estrutura que reúne os meios organizados para poder compartilhar dados..

OBJETIVO

O objetivo trabalho sobre sistema de banco de dados e mostra ao usuário dos detalhes internos do banco de dados e promover o conhecimento em relação às aplicações, ou seja, facilitar a aplicação e a estratégia de acesso e a forma de armazenamento.

DESENVOLVIMENTO

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.

Orientação a Objetos

A orientação a objetos fornece recursos como encapsulamento, herança,

polimorfismo e sobrecarga que serão rapidamente explicados.

Segundo Elmasri e Navathe, “o conceito de encapsulamento é uma das principais

características das linguagens e dos sistemas OO. Ele está relacionado também com

os conceitos de tipos abstratos de dados e ocultar a informação nas linguagens de

programação”. Encapsular dados significa que as variáveis serão acessadas por

métodos definidos em sua estrutura. Uma vantagem é poder ocultar a complexidade

na manipulação do objeto por meio das operações disponibilizadas de tal forma que

aumenta a segurança e produtividade.

Herança é o mecanismo pelo qual a linguagem de programação orientada a objetos

(LPOO) fornece a possibilidade do reaproveitamento de código. É possível uma

classe herdar os métodos e atributos de outra classe chamada superclasse ou classe

mãe e assim estender a classe mãe.

O polimorfismo é a capacidade que um objeto tem de ora se comportar de uma

maneira, ora de outra. Considere as classes as classes Pessoa, Funcionário e Aluno.

Com uma variável do tipo Pessoa, é possível utilizá-la para representar um objeto do

tipo Pessoa, mas também objetos do tipo Funcionário e Aluno.

O polimorfismo dá a possibilidade da sobrecarga de operadores, no qual subclasses

podem modificar a implementação de um método definido na superclasse.

Considerando o exemplo anterior e que cada classe tenha um método chamado

Remover, para remover uma pessoa basta apenas excluir o seu registro, já para um

aluno é preciso verificar se o mesmo não possui nenhuma pendência na organização,

excluir o aluno das disciplinas que está matriculado e por fim alterar o seu estado. Já

para um funcionário é preciso remover o acesso às informações da instituição,

calcular e pagar a indenização caso se aplique e alterar o estado do funcionário.

Percebe-se que cada classe tem a sua própria implementação, apesar de

compartilharem o mesmo nome do método.

Padrão ODMG

“O sucesso dos sistemas de banco de dados relacionais não resulta apenas de um

nível mais alto de independência de dados e um modelo de dados mais simples do que

os sistemas anteriores. Seu sucesso se deve também à padronização que sofreram. A

aceitação do padrão SQL permite o alto grau de portabilidade e interoperabilidade...

Portabilidade é a capacidade de executar um programa de aplicação particular em

diferentes sistemas com modificações mínimas no programa.” (Vieira, 2001)

Interoperabilidade se refere à habilidade de uma aplicação acessar múltiplos SGDBs

distintos.

O padrão ODGM (Object Database Management Group) se baseia em:

• Modelo de Objetos

• Linguagem de Definição de Objetos (ODL)

• Linguagem de Consulta a Objetos (OQL)

• Acoplamento (binding)

Elmasri e Navathe, 2005, dizem que o modelo de objetos fornece os tipos de

dados, os construtores de tipos e outros conceitos que podem ser utilizados na ODL

para especificar esquemas de BDs. O modelo define objetos e literais no qual os

objetos possuem um OID e um estado, ou valor atual, já as literais possuem apenas

um valor sendo basicamente uma constante. Tanto os objetos como as literais podem

ser do tipo atômico, coleção ou estruturado.

A linguagem ODL é usada para criar a definição dos tipos de objetos, por isso deve

suportar todos os construtores semânticos do Modelo de Objetos. É apenas uma

linguagem de definição e independente de qualquer linguagem de programação, sendo

utilizado o binding para a LPOO específica.

A OQL é uma linguagem declarativa não procedural que pode ser utilizada dentro

linguagens de programação. A OQL é baseada na SQL, adicionando conceitos do

padrão ODMG como OID, objetos complexos, herança, polimorfismo,

relacionamento e operações.

O binding, ou acoplamento, especifica como as estruturas em ODL são mapeadas

para estruturas na LPOO escolhida, como C# por exemplo. É o binding que converte

o objeto do BD para a aplicação.

Banco de Dados Objeto Relacional

Com a evolução dos paradigmas de programação e a gradativa manipulação de

dados complexos, houve a necessidade da evolução dos SGDB’s de forma a

acompanhar e atender as exigências requisitadas. Dessa evolução nascem os

SGBDOO, os SGBDOR e evoluções nos SGBDR.

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

Apesar de ser um conceito relativamente novo no mundo da tecnologia de banco

de dados, o SGBDOR tem sido uma das promessas capaz de substituir o SGBDR e o

SGBDOO. O fato de obter o melhor do SGBDOO e do SGBDR faz tender que seja o

modelo de banco de dados “ideal” para atender as necessidades atuais.

Padrão SQL3 ou SQL99

Assim como o SGBDOO e SGBDR possuem padrões de linguagem de consulta,

com a evolução do conceito objeto relacional ocorreu a necessidade da criação de

mais um padrão para manipular o mesmo, findando assim a criação do padrão SQL3

ou SQL99.

Criado em 1999 com o intuito de propor interação entre o banco de dados e

aplicações orientadas a objetos de forma mais natural, inclui novos tipos de dados,

novos operadores, suporte para a noção de objeto (OIDs, métodos, tipos de dados

estruturados definidos pelo usuário e etc.), consultas recursivas, triggers, navegação

pela estrutura dos objetos, chamada de métodos (na própria formulação da consulta) e

etc. Nele, representamos objetos como linhas (ROW) que definem uma tupla em

forma de registro. Diferente do modelo relacional, onde cada atributo possui valores

atômicos, pode ocorrer de objetos posuirem outros objetos ou de mais de um registro,

caracterizando o conceito de relação aninhada, onde os atributos podem ser

constituídos de outras relações e não apenas de valores atômicos.

Um conjunto de novos operadores pode ser encontrado no SQL3, alguns deles são

os seguintes: Set, Cast-Multiset, Cursor, Bag, List, Array, Row.

Outro ponto que vale ressaltar é o uso do tipo de dado LOB, utilizado para dados

muito grandes como vídeos, música e etc. Possui dois subtipos que são o CLOB

(Character LOB) e BLOB (Binary LOB).

Enfim, um conjunto de outras utilidades pode ser encontrado na linguagem SQL3

ou SQL99 de modo a facilitar o uso do SGBDOR de forma eficiente e padronizada.

Comparação BDOO x BDOR

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.

Aplicações

A maioria das descrições dos bancos de dados orientados a objeto os caracteriza como SGBD de "próxima geração" para aplicações avançadas. Tradicionalmente, estas aplicações avançadas incluíram projeto auxiliado por computador (CAD), manufatura auxiliada por computador (CAM) e escritórios inteligentes, o que inclui automação de escritórios e documentação de imagens.

IMAGEM DE UM BANCO DE DADOS ORIENTADO A OBJETO

Mapeamento objeto-relacional

Mapeamento objecto-relacional ou objeto-relacional ou ORM, do inglês: Object-relational mapping) é 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.

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 objecto 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 a usar. Como exemplo, o programador que use Hibernate na linguagem Java pode usar arquivos XML ou o sistema de anotações que a linguagem providencia.

Esta é uma lista de softwares de mapeamento objeto-relacional mais conhecidos. Ela não está atualizada e nem inclui todos os softwares.

Perl

• DBIx::Class

Python

• Django, ORM incluído no framework Django, código aberto

• SQLAlchemy, código aberto

• SQLObject, código aberto

• Storm, código aberto (LGPL 2.1) desenvolvido na Canonical Ltd.

• Tryton, código aberto

• web2py, as facilidades de um ORM são tratadas pela DAL no web2py, código aberto

Vantagens de se usar um ORM

- Você escreve menos código e programa com muito mais produtividade.

- Seu código fica mais elegante.

- É mais fácil de dar manutenção no projeto.

- Melhora a padronização da sua aplicação.

Exemplo de um código em .NET usando ORM:

Usuario.AddNew();

Usuario.FirstName = this.txtFirstName.Text;

Usuario.LastName = this.txtLastName.Text;

Usuario.Save();

CONCLUSÃO

A orientação a objetos é a tendência seja qual for a situação, o seu dilema é o fato

da perda de desempenho. Assim como primeiras linguagens de programação onde

tudo era um objeto, os BDOOs sofrem com o desempenho. Quando só existia o

BDR, apareceu a necessidade de armazenar dados complexos, uma ótima solução foi

o BDOO, entretanto, por seu desempenho não satisfatório, um outro banco foi

desenvolvido, o BDOR, que agrega características da orientação a objetos e

otimização do BDR. O modelo objeto relacional pode ser comparado às linguagens de

programação atuais, onde apenas dados complexos são representados como objetos,

tendo assim maior desempenho.

O BDOR ainda não alcançou aplicações de larga escala, pois se trata de um banco

relativamente novo, mas como suas vantagens estão se tornando cada vez mais

evidentes, a tendência é que as empresas e aplicações que manipulam dados

complexos comecem a utilizar o BDOR e no futuro este modelo de banco de dados

tome o lugar do tradicional BDR.

BIBLIOGRAFIA

http://pt.wikipedia.org

http://pt.wikipedia.org/wiki/Caso_de_uso

http://analise-unopar.forumeiros.com/

www.trabalhosfeitos.com