Módulo VIII: Banco de Dados

Orientado a Objetos e

Relacional-Objeto

(Aula 1)

Clodis Boscarioli

Banco de Dados I

2007

Agenda:

� Banco de Dados Orientado a Objetos

� Introdução e Motivações;

� Conceitos principais;

� Exemplos;

� Principais SGBDOOs;

� Considerações Finais.

Introdução e Motivações

� Novas aplicações ficaram limitadas por restrições impostas pelo modelo relacional.

� As aplicações convencionais possuem características comuns que as tornam passíveis de serem tratadas por bancos de dados relacionais:� Uniformidade: as informações a serem armazenadas podem ser

estruturadas de maneira similar.� Orientação a registros: registros de tamanho fixo são adequados

para a representação desta informação.� Itens de dados pequenos: as informações são estruturadas em

registros pequenos.� Campos atômicos: os campos dentro de um registro são pequenos e

de comprimento fixo. Não há estruturas dentro dos campos, ou seja, a primeira forma normal pode ser mantida.

� O modelo de banco de dados orientado a objetos está baseado no paradigma de programação orientada a objeto.

Introdução e Motivações

� As aplicações mais novas, em geral, não possuem, no mínimo, uma das características já citadas.

� Exemplos dessas aplicações:� Computer-aided design (CAD) – projeto auxiliado por

computador: � É necessário armazenar os dados pertencentes a um projeto de

engenharia, incluindo os componentes do item que está sendo projetado, o inter-relacionamento dos componentes, as versões antigas do projeto.

� Computer-aided software engineering (CASE) – engenharia de software auxiliada por computador:

� É necessário armazenar os dados necessários para apoiar os desenvolvedores de software, incluindo o código-fonte, as dependências entre os módulos de software, as definições e o usode variáveis e o histórico de desenvolvimento do sistema de software.

Introdução e Motivações

� Bancos de dados multimídia:� Contém imagens, dados espaciais, dados de áudio, dados de vídeo

e afins (envolvem principalmente o armazenamento de fotografias e dados geográficos, voz e vídeo).

� Office information system (OIS) – sistemas de informação de escritório:

� Necessidade de suportar dados para ferramentas para criação e recuperação de documentos e ferramentas para manutenção de calendários, permitindo solicitações pertencentes a agendas, documentos e conteúdos de documentos.

� Bancos de dados de hipertexto: � Necessidade de suportar o armazenamento/gerenciamento das

estruturas específicas e indexação de textos enriquecidos com linksque apontam para outros documentos, permitindo a recuperação de documentos baseados em sua estrutura.

Modelagem de BDOOs

� Isso:

Desenvolvedor

Analista

Banco de Dados

Diagrama de Classes

Classe1

Classe4

Classe3

Classe20..1

* **

Modelagem de BDOOs

� Ao invés disso:

Desenvolvedor

Analista

Banco de Dados

Diagrama Entidade Relacionamento

Tabela1

Tabela2

Tabela3 Tabela4

Tabela5

Tabela6

Diagrama de Classes

Classe1

Classe4

Classe3

Classe20..1

* **

O Modelo de Dados Orientado a Objeto

� A estrutura objeto:

� Superficialmente, um objeto corresponde a uma entidade no modelo E-R.

� Este paradigma se baseia no encapsulamento de dados e em código relacionado a um objeto dentro de uma única unidade.

� As interações entre um objeto e o resto do sistema deve ser via mensagens.

� Uma interface entre um objeto e o resto do sistema deve ser definida por um conjunto de mensagens permitidas.

� Em geral, um objeto tem associado a ele:

� Um conjunto de variáveis que contém os dados para o objeto; as variáveis correspondem aos atributos no modelo E-R;

� Um conjunto de mensagens ao qual o objeto responde; cada mensagem pode ter zero, um ou mais parâmetros;

� Um conjunto de métodos, cada qual sendo um corpo de código para implementar a mensagem; um método retorna um valor como resposta à mensagem.

O Modelo de Dados Orientado a Objeto

� O termo mensagem em um contexto orientado a objeto se refere à passagem de pedidos entre os objetos sem considerar detalhes específicos de implementação.

� O termo chamar um método algumas vezes é usado para representar o ato de enviar uma mensagem a um objeto e a execução do método correspondente.

� Exemplo:� Considerando a entidade empregado em um banco de dados. Suponha que o salário

anual de um empregado seja calculado de maneiras diferentes para diferentes empregados. Por exemplo, os gerentes podem ter um bônus dependendo do desempenho do banco, enquanto os caixas podem obter um bônus dependendo de quantas horas eles trabalharam. É possível encapsular o código para calcular o salário para cada empregado como um método que é executado em resposta a uma mensagem salário_anual.

� Todos os objetos empregado respondem à mensagem salário_anual, mas fazem isso de diferentes maneiras. Pelo encapsulamento da informação sobre como calcular o salário anual dentro do objeto empregado, todos os objetos empregados apresentam a mesma interface.

� É possível modificar a definição de um objeto sem afetar o resto do sistema. Esta é uma das habilidades considerada como uma das maiores vantagens do paradigma de programação orientado a objetos.

O Modelo de Dados Orientado a Objeto

� Os métodos de um objeto podem ser:� Somente leitura: não afeta os valores das variáveis em um objeto;� De atualização: pode mudar os valores das variáveis.

� As mensagens às quais um objeto responde podem ser, de maneira similar, classificadas como somente leitura ou de atualização, em função do método que implementa a mensagem.

� Cada atributo de uma entidade deve ser expresso como uma variável e um par de mensagens do objeto no modelo orientado a objeto. A variável é usada para armazenar o valor do atributo, uma mensagem é usada para ler o valor do atributo e o outro método é usado para atualizar o valor. Por exemplo:� O atributo endereço da entidade empregado pode ser representado por:

� Uma variável endereço;� Uma mensagem obter_endereço cuja resposta é o endereço;� Uma mensagem ajustar_endereço, que possui um parâmetro novo_endereço, para

atualizar o endereço.

� Por simplicidade muitos modelos orientados a objeto permitem que as variáveis sejam lidas ou atualizadas diretamente, sem ter de definir mensagens para isso.

Classes de Objetos

� Objetos similares são aqueles que respondem às mesmas mensagens, usam os mesmos métodos e têm variáveis de mesmo nome e tipo.

� Objetos similares são agrupados formando uma classes.� Cada um desses objetos é chamada de uma instância de sua classe.� A noção de uma classe no modelo de dados orientado a objeto corresponde à noção

de um conjunto entidade do modelo E-R.

� Exemplo de definição de uma classe:

Class empregado {/* variáveis */string nome;string endereço;date data_início;int salário;

/* mensagen */int salário_anual();string obter_nome();string obter_endereço();int ajustar_endereço (string novo_endereço);int tempo_emprego();

}

Classes de Objetos

� Cada classe é um objeto em si e inclui uma variável contendo o conjunto de todas as instâncias da classe.

� Uma classe objeto inclui:

� Uma variável conjunto valorada cujo valor é o conjunto de todos os objetos que são instâncias da classe;

� A implementação de um método para a mensagem new, que cria uma nova instância da classe.

Herança� Considerando um banco de dados orientado a objetos para a aplicação

bancária (exemplo – Korth), a classe clientes é similar à classe empregados, pois ambas definem variáveis para nome, endereço e assim por diante. No entanto, há variáveis específicas para empregados (salário) e variáveis específicas para clientes (classificação_crédito).

� Neste caso é desejável definir uma representação para as variáveis comuns em um único local. Para isso, combina-se empregados e clientesdentro de uma classe.

� Para permitir a representação direta de similaridades entre classes, necessita-se colocar as classes em uma hierarquia de especialização.� Empregado e cliente são especializações de pessoa.

� Este conceito é similar ao conceito de especialização no modelo E-R.

� Empregados e clientes podem ser representados por classes que são especializações de uma classe pessoa. Variáveis e métodos específicos a empregados são associados à classe empregados. Variáveis e métodos específicos a clientes são associados à classe cliente. Variáveis e métodos que se aplicam tanto a empregados como a clientes são associados à classe pessoa.

class pessoa {string nome;string endereço;

};class cliente isa pessoa {

int classificação_crédito};class empregado isa pessoa {

date data_início;int salário;

};class escriturário isa empregado {

int número_escriturário;int número_conta_despesa;

};class caixa isa empregado {

int horas_por_semana;int número_estação;

};class secretária isa empregado {

int horas_por_semana;string gerente;

};

Herança

� Um benefício importante da herança em sistemas orientados a objeto é a noção de reusabilidade.

� Qualquer método de uma classe pode ser invocado por qualquer objeto pertencente a qualquer subclasse desta classe.

� Para tratar a hierarquia de classes tem-se duas opções:� Associar à classe empregado todos os objetos empregado, incluindo

aqueles que são instâncias de escriturário, caixa e secretária.� Associar à classe empregado somente aqueles objetos empregado que

não são instâncias nem de escriturário, nem de caixa, nem de secretária.

� É possível determinar o conjunto de todos os objetos empregado, nesse caso, tomando-se a união daqueles objetos associados a todas as subclasses de empregado.

Herança Múltipla

� Suponha que precisemos distinguir entre escriturários, caixas e secretárias de tempo integral e tempo parcial. Além disso, assuma que são necessárias diferentes variáveis e métodos para representar empregados de tempo parcial e tempo integral. Então cada um desses empregados são classificados de duas maneiras diferentes.

secretária_TP

pessoa

empregado cliente

escriturário caixa secretária

caixa_TI caixa_TP secretária_TIescrit_TI escrit_TP

Herança Múltipla

� Existem certas variáveis e métodos específicos para empregado em tempo integral e outros específicos para empregado em tempo parcial. Assim, na hierarquia em análise, as variáveis e métodos para empregados de tempo integral devem ser definidos três vezes: uma vez para escriturário_TI, uma vez para secretária_TI e uma vez para caixa_TI. Redundâncias deste tipo são indesejáveis mediante alterações nas propriedades dos empregados de tempo integral (e parcial), que deverão ser feitas em dois lugares diferentes.

� Existe falha na exploração da reutilização de código.

� Nesta hierarquia também não se consegue representar os empregados que não são escriturários, caixas ou secretárias, mas que possuem características de serem ou de tempo parcial ou integral.

� Se existissem várias classificações de emprego, em vez de duas limitações neste exemplo, as limitações do modelo se tornariam muito mais aparentes.

Herança Múltipla

� Herança múltipla é a habilidade de uma classe herdar variáveis e métodos a partir de múltiplas superclasses.

escrit_TI

pessoa

empregado cliente

tempo_integral tempo_parcial caixa secretária

caixa_TI caixa_TP secretária_TI secretária_TPescrit_TP

escriturário

� Pode haver algum problema?

Herança Múltipla

� Assuma que, em vez de definir salário para a classe empregado, defina-se uma variável chamada pagamento para cada classe: tempo_integral, tempo_parcial, escriturário, caixa e secretária, como a seguir:� Tempo_integral: pagamento é um inteiro de 0 a 100.000 contendo um salário

anual;� Tempo_parcial: pagamento é um inteiro de 0 a 20, contendo uma taxa horária

de pagamento.� Caixa e escriturário: pagamento é um inteiro de 0 a 20.000, contendo um salário

anual;� Secretária: pagamento é um inteiro de 0 a 25.000, contendo um salário anual.

� Considere a classe secretária_TP. Ela pode herdar a definição de pagamento tanto de tempo_parcial como de secretária. O resultado é diferente, dependendo da escolha feita.

� Opções:� Incluir ambas as variáveis, renomenado-as como tempo_parcial.pagamento e

secretária.pagamento;

� Escolher uma ou outra, baseado na ordem em que as classes tempo_parcial e secretária foram criadas;

� Forçar o usuário a fazer a escolha;� Tratar a situação como um erro.

Identidade de Objeto

� Os objetos em um banco de dados orientado a objeto correspondem a uma entidade na empresa que está sendo modelada. Uma entidade mantém sua identidade mesmo se algumas de suas propriedades mudam com o tempo.

� Um objeto mantém sua identidade mesmo se alguns ou todos os seusvalores de variáveis ou definições de métodos mudarem com o tempo.

� Diferente do modelo relacional onde as tuplas de uma relação são diferenciadas somente pelos valores que elas contêm.

� Formas de identidade:� Valor: usado em modelos relacionais � um valor de dado é usado para

identidade da tupla;� Nome: usado em sistemas de arquivos � um nome fornecido pelo usuário é

usado para identidade dos arquivos;� Embutido: usado em sistemas orientados a objetos � a cada objeto é

atribuído automaticamente um identificador pelo sistema quando aquele objeto é criado.

� Identificadores de objetos são únicos. Exemplo de uso do identificador:� Um dos atributos de um objeto pessoa pode ser o atributo cônjuge, que é

realmente um identificador do objeto pessoa correspondendo ao cônjuge da primeira pessoa. Assim, o objeto pessoa pode armazenar uma referência ao objeto que representa o cônjuge de pessoa.

Identidade de Objeto

Objetos Compostos

� As referências entre os objetos podem ser usadas para modelar diferentes conceitos do mundo real. Um desses conceitos é o de objetos compostos.

bicicleta

roda freio marcha quadro

aro raio pneu pedal bloco cabo

É parte de

� O conceito de composição permite que os dados sejam vistos em diferentes granularidades por diferentes usuários.

Modelagem de BDOOs

� Representação no BDOO:� Um BDOO armazena objetos integralmente; � É possível recuperar um objeto a qualquer momento, inclusive todas as

referências.

� Linguagem de definição:� ODL (Object Definition Language);� Utilizada para criar definições de objetos.

� Linguagem de consulta:� OQL (Object Query Language);� Utilizada para recuperar objetos do banco.

Modelagem de BDOOs

NomeCidadeFuncionarios

Fabrica

RenavanModeloCorPrecoFabricantePeças[ ]

Automóvel

NomePresidenteFábricas[ ]

Fabricante

NomeFabricantePotência

Motor

NomeMotorProdução [ ]

Peça

Classes

Modelagem de BDOOs

Ford

João da Silva

[OID1125, OID1127, OID1128]

Fabricante{OID1}

Filial São Bernardo I

São Bernardo

250

Fábrica {OID1127}

Filial São Bernardo II

São Bernardo

130

Fábrica {OID1128}

Central

Camaçari

320

Fábrica {OID1125}

Rocam 1000 16V

OID1

120CV

Motor{OID154}Correia Dentada

Ford

OID154

[OID1125, OID1127, OID1128]

Peça{OID5123}

736194174

Ka

Preto

20000

OID1

[OID5123]

Automóvel{OID12}

Objetos

Modelagem de BDOOs

736194174

Ka

Preto

20000

Automóvel{OID12}

Ford

João da Silva

Fabricante{OID1}

Filial São Bernardo

I

São Bernardo

250

Fábrica {OID1127}

Filial São Bernardo

II

São Bernardo

130

Fábrica {OID1128}

Central

Camaçari

320

Fábrica {OID1125}

Rocam 1000 16V

120 CV

Motor{OID154}

Objeto Complexo

Modelagem Padrão ODMG – ODL

Especificação ODL

class Pessoa

(extent pessoas

key nss)

{

attribute struct Nomep{string sobrenome, string primeiro_nome} nome;

attribute string nss;

attribute date data_nascimento;

attribute enum Genero{M,F} sexo;

attribute struct Endereço

{short num, string logradouro, sort numapto, string cidade, string estado, short cpe}

endereço;

short idade();

};

class Professor extends Pessoa

( extent professores )

{

attribute string classificação;

attribute float salário;

attribute string escritório;

attribute string telefone;

relationship Departamento trabalha_em inverse Departamento::possui_professor;

relationship set<aluno_grad> dá_assistência inverse AlunoGrad::assistente;

relationship set<aluno_grad> no_comitê_de inverse AlunoGrad::comitê;

void dar_aumento(in float aumento);

void promove(in string nova_classificação);

};

Especificação ODL

class Grau

( extent graus)

{

attribute enum GrauValores{A,B,C,D,F,I,P} grau;

relationship Disciplina disciplina inverse Disciplina::alunos;

relationship Aluno aluno inverse Alunos::disciplinas_completadas;

};

Especificação ODL

class Aluno extends Pessoa

( extent alunos)

{

attribute string classe;

attribute Departamento cursa_eletiva_em;

relationship Departamento especializa_em inverse

Departamento::possui_especializações;

relationship set <grau> disciplinas_completadas inverse Grau::alunos;

relationship set <DisciplinaCorrente> registrado_em inverse

DisciplinaCorrente::alunos_registrados;

void alterar_especialização (in string nomed) raises disciplina_inválida);

float mg();

void registrado(in short nomseção; in ValorGrau grau)

raise (disciplina_inválida,grau_invalido);

};

Especificação ODL

select struct (sobrenome:s.nome.sobrenome,primeiro_nome: s.nome.primeiro_nome)

from s in departamentocc.possui_especializações

where s.classe = ‘Superior’

order by sobrenome asc;

select struct (sobrenome:s.nome.sobrenome,primeiro_nome: s.nome.primeiro_nome)

from s in alunos

where s.especializa_em.nomed = ‘Ciência da Computação’

order by sobrenome asc;

Especificação OQL

Linguagens Orientadas a Objeto

� Para que estes conceitos básicos de orientação a objetos sejam usados na prática em um sistemas de banco de dados, eles devem ser expressos em alguma linguagem. Esta representação pode ser feita de duas formas:� Os conceitos são usados puramente como uma ferramenta de

projeto e são codificados, por exemplo, em um banco de dados relacional;

� Os conceitos de orientação a objetos são incorporados em uma linguagem que é usada para manipular o banco de dados.

� Extensão de uma linguagem de manipulação de dados, como a SQL, pela adição de tipos complexos e orientação a objetos.

� Tomar uma linguagem de programação orientada a objeto e estendê-la para tratar banco de dados (são as linguagens de programação persistentes).

Linguagens de Programação Persistentes

� Linguagens de bancos de dados diferem das linguagens de programação tradicionais pelo fato de que elas manipulam diretamente os dados que são persistentes, ou seja, dados que continuam a existir mesmo depois que o programa que os criou tenha terminado.

� Uma linguagem de programação persistente é uma linguagem de programação estendida com estruturas para tratar dados persistentes.

� Versões persistentes de linguagens de programação como C++ ou Smalltalk estão entre as mais importantes. Elas permitem que o programador manipule os dados do banco de dados sem passar por uma linguagem de manipulação de dados como a SQL.

� Essas linguagens são poderosas e é relativamente fácil cometer erros de programação que danifiquem o banco de dados.

Persistência de Objetos

� Persistência por classe: Declarar que uma classe é persistente. Assim, todos os objetos da classe são, por default, persistentes. Os objetos de classes não persistentes são transientes.

� Persistência por criação: Um objeto é persistente ou transiente, dependendo de como ele foi criado.

� Persistência por marcação: Todos os objetos são criados como transientes mas, se um objeto deve persistir alem da execução doprograma, ele deve ser marcado explicitamente como persistente antes do programa terminar.

� Persistência por referência: Um ou mais objetos são explicitamente declarados como objetos persistentes (raiz). Todos os outros objetos são persistentes se (e somente se) forem referidos diretamente, ou indiretamente, a partir do objeto persistente raiz.

Sistemas Persistentes C++

� O grupo de gerenciamento de banco de dados objeto (ODMG) tem trabalhado para padronizar extensões de linguagem ao C++ (e ao Smalltalk) a fim de aceitar persistência e definir bibliotecas de classe para aceitar persistência.� Exemplos:

� o operador new deve ser estendido para alocar um novo objeto no banco de dados, em meio estável;

� tipos para criação de referências (ponteiros persistentes) precisam se criados. Ref<Objeto>: referência persistente para o objeto do tipo Objeto;

� Notações para especificar restrições de integridade referencial também são incorporadas. Inverse deve ser usado nas definições das classes sobre as quais as restrições de integridade referencial serão necessárias.

� Existem duas partes:� Linguagem de Definição de Objeto (ODL);� Linguagem de Manipulação de Objeto (OML).

Principais SGBDOOs

SIMSIMSIMSuporta consultas através de interface gráfica

SIMvia ODBC

Smalltalk - SIMJava - NÃO

SIMSuporta SQL

SIMNÃOSIMSuporta OQL (Object Query

Language)

NÃOSIMSIMSuporta ODL (Object Definition

Language)

SIMSIMNÃO, os métodos são armazenados no

cliente.Armazena os métodos dos objetos no BD

CC++ODQLJava

Java, SmalltalkC++, Java, Smalltalk,

SQLLinguagem de definição de atributos

NÃONÃOSIMSuporta transações longas

SIM (1)NÃOSIMValida cardinalidade entre objetos

SIMSmalltalk - NÃOJava - SIM

SIMHerança Múltipla

SIMSIMSIMDefinição de dados pelo usuário

JasmineComputer Associateswww.cai.com

GemStone (*)GemStone Systemswww.gemstone.com

Objectivity/DBObjectivity, Inc.www.poet.com

Produto

Critério

Principais SGBDOOs

� Objectivity/DB� Integrado diretamente com a aplicação

� Não é necessário um processo separado;� APIs (Application Programming Interfaces):

� C++;� SmallTalk;� Java:

� Integração com IDE Eclipse;� Ferramentas de Administração e Projeto.

� Suporta SQL;� Suporta XML;

Principais SGBDOOs

� GemStone� Armazena métodos dos objetos no banco� APIs:

� C++;� SmallTalk;� Java.

� Suporta SQL apenas através da interface SmallTalk;� Suporta XML, com ambiente de gerenciamento otimizado;� Compatível com .Net.

Principais SGBDOOs

� Jasmine� Desenvolvido pela Computer Associates� APIs:

� C++;� SmallTalk;� Java;

� Oferece todas as funcionalidades de um BD relacional, além das capacidades da OO;

� Suporta OQL;� Suporta SQL;� Possui integração com ferramentas CASE.

Considerações Finais

� Principais Barreiras:� Culturais

� “Pra que mexer em time que está ganhando?”;� Falta de familiaridade com OO;� MID (medo, incerteza e dúvida);

� Grande parte dos SGBDOOs são desenvolvidos por empresas pequenas;

� Risco de ficar “sem suporte”;� Financeiras

� Alto custo de migração;� Tempo para migração;� Treinamento de pessoal;� Necessidade de profissionais mais qualificados;

Considerações Finais

� SGBDOOs:� União de duas tecnologias

� Bancos de Dados;� Orientação a Objetos.

� Objetivos semelhantes� Persistir dados;� Recuperação;� Comparação;� Tratamento / Gerenciamento.

� Vantagem: Utilização da tecnologia OO.� Desvantagem: Ainda pouco popular.

Tendências

� SGBDO-R (Objeto-relacional)

� Armazenamento em memória� Prevayler (www.prevayler.org)

� Repositório de objetos� Desempenho de acesso bastante superior� Limitações ligadas à recuperação em caso de falhas ainda

existem� Interfaces Objeto-Relacionais

� Hibernate (www.hibernate.org)� Camada que provê interface para a aplicação� Persistência de forma transparente� A aplicação trabalha como se estivesse conectada a um BDOO

Referências Bibliográficas

� Sistemas de Banco de Dados. (Cap. 9) Abraham Silberchatz, Henry F. Korth e S. Sudarshan. 5ª Edição. Makron Books, 2006.

� Sistemas de Banco de Dados. (Cap. 20-21) Ramez Elsmari, Shamkant B. Navathe. 4ª Edição. Pearson Addison Wesley, 2005.

� Fundamentals of Database Systems. (Cap. 11-12) Ramez Elsmari, Shamkant B. Navathe. Addison Wesley Longman, 2000.

� Uma Reflexão sobre Banco de Dados Orientados a Objetos. Boscarioli, et. al. CONGED, 2006.

� The Object-Oriented Database System Manifesto. Atkinson, et al. Agosto, 1989.