UNIVERSIDADE FEDERAL DE SO CARLOS DEPARTAMENTO DE COMPUTAO

Banco de Dados Orientado a Objetos

Marina Teresa Pires Vieira

Contedo

Contedo........................................................................................................................1 1. Conceitos Avanados sobre Modelagem de Dados..................................................3

1.1. Introduo..................................................................................................................... 3 1.2. Modelos de Dados......................................................................................................... 5
1.2.1. Abstraes no Projeto Conceitual de Banco de Dados ......................................................... 5

1.3. Modelo EER (Extended Entity-Relationship) ........................................................... 6

1.3.1. Atributos compostos: ............................................................................................................ 7 1.3.2. Hierarquia de Generalizao................................................................................................. 7

1.4. Exerccios .................................................................................................................... 10

2. Modelos de Dados Orientados a Objetos................................................................12

2.1. Introduo................................................................................................................... 12 2.2. Conceitos Bsicos ....................................................................................................... 13
2.2.1. Objetos e Identidade ........................................................................................................... 13 2.2.2. Valores................................................................................................................................ 14 2.2.3. Estrutura do objeto.............................................................................................................. 14 2.3.4. OIDs x Chaves Primrias.................................................................................................... 14 2.3.5. Objetos Complexos............................................................................................................. 15 2.3.6. Encapsulamento .................................................................................................................. 15 2.3.7. Mtodos ..............................................................................................................................16 2.3.8. Tipos e Classes.................................................................................................................... 16 2.3.9. Herana ............................................................................................................................... 16 2.3.10. Polimorfismo..................................................................................................................... 19

3. Modelagem de Dados Orientada a Objetos............................................................21

3.1. Motivao.................................................................................................................... 21 3.2. Desenvolvimento de Sistemas Orientados a Objetos............................................... 21 3.3. Modelando Objetos .................................................................................................... 22
3.3.1. Definio de classe ............................................................................................................. 22 3.3.2. Herana ............................................................................................................................... 23 3.4.1. Representao de uma classe de objetos............................................................................. 24 3.4.2. Representao de conjunto, lista e tupla ............................................................................. 24 3.4.3. Herana simples .................................................................................................................. 25 3.4.4. Herana mltipla................................................................................................................. 25 3.4.5. Definio recursiva ............................................................................................................. 26 3.4.6. representao de referncias inversas ................................................................................ 26

3.4. Representao grfica................................................................................................ 23

3.5. Gerao do Esquema Lgico..................................................................................... 26 3.6. Exemplo: Banco de Dados para Gerenciamento de Projetos................................. 28 3.7. Notao adotada X diagrama de classes UML ........................................................ 31 3.8. Exerccios .................................................................................................................... 37

4. Manipulando Objetos..............................................................................................39
4.1. Caractersticas de Linguagens de Consulta OO (LCOO) ...................................... 39

4.1.1. Hierarquias de Agregao................................................................................................... 39 4.1.2. Hierarquia de Herana ........................................................................................................40

4.2. Consultando Objetos.................................................................................................. 40

4.2.1. Hierarquias de Agregao................................................................................................... 40 4.2.2. Hierarquia de Herana ........................................................................................................42

4.3. Definio de Mtodos................................................................................................. 42 4.4. Exerccios .................................................................................................................... 46

5. Sistemas de Gerenciamento de Banco de Dados Orientados a Objetos................48

5.1. Caractersticas dos SGBDs Orientados a Objetos................................................... 48 5.2. Vantagens dos SGBDOOs ......................................................................................... 52 5.3. Alguns SGBDOOs Existentes................................................................................... 53

6. Padres para SGBDOOs.........................................................................................54 6. Padres para SGBDOOs.........................................................................................55 6. Padres para SGBDOOs.........................................................................................56

6.1. SQL3........................................................................................................................... 56 6.2. ODMG-93 ................................................................................................................... 57

7. Bibliografia..............................................................................................................58

1. Conceitos Avanados sobre Modelagem de Dados

1.1. Introduo Bancos de dados so componentes importantes dos sistemas de informao (SIs) e consequentemente, o projeto do banco de dados apresenta-se como uma atividade essencial na fase de desenvolvimento dos SIs. Projetar bancos de dados tem se tornado uma atividade popular, as vezes realizada no somente por profissionais da rea de banco de dados, mas tambm por no especialistas. Freqentemente, a falta de abordagens adequadas para o projeto de um banco de dados pode incorrer em resultados indesejveis, como ineficincia em atender a demanda de aplicaes e problemas com a manuteno do banco de dados. Geralmente a causa disso a falta de clareza em entender a natureza exata dos dados em um nvel conceitual (abstrato). O projeto de um banco de dados decomposto em Projeto Conceitual, Projeto Lgico e Projeto Fsico, conforme mostrado na figura 1.1. Requisitos de dados Projeto Conceitual Esquema conceitual Projeto Lgico Esquema Lgico Projeto Fsico Esquema Fsico Fig. 1.1

O Projeto Conceitual inicia a partir da especificao dos requisitos e resulta no esquema conceitual do banco de dados. Um esquema conceitual uma descrio em alto nvel da estrutura do banco de dados, independente do Sistema de Gerenciamento de Banco de Dados (SGBD) adotado para implement-lo. Um modelo conceitual usado para descrever os esquemas conceituais. O propsito do projeto conceitual descrever o contedo de informao do banco de dados ao invs das estruturas de armazenamento que sero necessrias para gerenciar essa informao. O Projeto Lgico inicia a partir do esquema conceitual e resulta no esquema lgico. Um esquema lgico uma descrio da estrutura do banco de dados que pode ser processada por um SGBD. Um modelo lgico usado para especificar esquemas lgicos. Os modelos lgicos mais amplamente usados pertencem a trs classes: relacional, em redes e hierrquico. O projeto lgico depende da classe do modelo de dados usado pelo SGBD, mas no do SGBD especfico usado. O Projeto Fsico inicia a partir do esquema lgico e resulta no esquema fsico. Um esquema fsico uma descrio da implementao do banco de dados em memria secundria; ele descreve as estruturas de armazenamento e mtodos de acesso usados para efetivamente realizar o acesso aos dados. O projeto fsico direcionado para um SGBD especfico. Decises tomadas durante o projeto fsico, para melhorar o desempenho, podem afetar a estrutura do esquema lgico. Uma vez que o projeto fsico do banco de dados completado, os esquemas lgico e fsico so expressos usando a linguagem de definio de dados do SGBD adotado. O banco de dados criado e populado e pode ser testado para se tornar operacional. O esquema fsico do banco de dados influenciado pelas fases por que passou a construo do banco de dados. A fase de projeto conceitual tida como uma das mais (seno a mais) delicadas em todo esse processo, pois depende muito da habilidade do projetista do banco de dados e das qualidades do modelo de dados adotado para a elaborao do esquema conceitual. A meta nessa fase obter um esquema conceitual do banco de dados que seja to completo e expressivo quanto possvel. Esse esquema deve procurar expressar o mximo da semntica envolvida na informao. Mecanismos de representao de alto nvel so empregados, tais como

representao de hierarquias de subconjunto e de generalizao, representao de restries de cardinalidade e de atributos compostos e multivalorados. O esquema conceitual deve permanecer como uma parte da documentao do processo de projeto, sendo utilizado durante a operao e manuteno do banco de dados, pois facilita o entendimento dos esquemas de dados e das aplicaes que os utilizam. Para auxiliar o projetista a elaborar o projeto conceitual de um banco de dados existem as abstraes de dados, que apresentam as vantagens: ajudam o projetista a entender, classificar e modelar a realidade, melhoram a eficincia de implementaes subsequentes, permitem melhor representar a semntica das novas aplicaes de banco de dados, provenientes de reas no tradicionais.

1.2. Modelos de Dados Modelos de dados so veculos para descrever a realidade. Um modelo de dados uma coleo de conceitos que podem ser usados para descrever um conjunto de dados e operaes para manipular os dados. Os modelos de dados servem de base para o desenvolvimento de Sistemas de Gerenciamento de Banco de Dados (SGBDs). Distinguem-se dois tipos de modelos de dados: Modelos conceituais, que so ferramentas para representar a realidade em alto nvel de abstrao; Modelos lgicos, que suportam descries de dados que podem ser processados por um computador (ex: modelos relacional, hierrquico, em redes). Esses modelos so facilmente mapeados para a estrutura fsica do banco de dados .

1.2.1. Abstraes no Projeto Conceitual de Banco de Dados Para auxiliar o projetista na tarefa de modelar os dados, existem os mecanismos de abstrao de dados que permitem melhor representar a semntica da informao envolvida na aplicao. As abstraes comumente usadas no projeto conceitual so: classificao, agregao e generalizao.

Abstrao de Classificao: usada para alocar objetos similares, caracterizados por propriedades comuns, em classes de objetos. A classificao estabelece um relacionamento -INSTANCIA-DE entre cada elemento da classe e a classe. Ex: classe EMPREGADO - instancias : (Joo, Pedro, ..., Jos). Abstrao de Agregao: um conceito de abstrao para construir objetos compostos a partir de seus objetos componentes. Essa abstrao estabelece um relacionamento -PARTE-DE entre os componentes e a classe. Ex: Uma entidade uma agregao de atributos: PESSOA, composta por Nome, Sexo, Profisso; Um relacionamento uma agregao de entidades e atributos; Um atributo composto uma agregao de atributos; Pode-se agregar entidades relacionadas entre si, compondo uma entidade de nvel mais alto. Abstrao de Generalizao: define um relacionamento de subconjunto entre os elementos de duas ou mais classes. Essa abstrao estabelece um relacionamento -UM entre a classe pai (chamada superclasse) e cada classe filha (subclasse). Ex: classes CARRO e BICICLETA so subconjuntos da classe VECULO. As subclasses so definidas com base em alguma caracterstica da superclasse. No exemplo dado, essa caracterstica tipo de veculo (Carro, Bicicleta). Propriedade Fundamental da Generalizao: Todas as abstraes definidas para a classe genrica so herdadas por todas as classes que so subconjunto.

1.3. Modelo EER (Extended Entity-Relationship) Devido popularidade e ampla utilizao do modelo Entidade-Relacionamento (ER) para o projeto conceitual de bancos de dados, vrias extenses desse modelo foram propostas, visando sua utilizao para a modelagem de informaes mais complexas. 6

O modelo ER foi proposto por Peter Chen em 1976, sendo que originalmente o modelo incluia somente os conceitos de entidade, relacionamento e atributos; posteriormente outros conceitos foram introduzidos no modelo, tais como atributos compostos e hierarquias de generalizao. 1.3.1. Atributos compostos: Um atributo composto representa um grupo de atributos que possuem uma afinidade em significado ou uso. Como exemplo, considere o atributo endereo na figura 1.2, que composto por Rua, Cidade, Estado, Pas e CEP. Rua Cidade Estado Pas CEP

Professor

endereo

Fig. 1.2 - atributo composto 1.3.2. Hierarquia de Generalizao Uma classe E uma generalizao de um grupo de classes E1, E2, ..., En se cada objeto das classes E1, E2, ..., En tambm um objeto da classe E. Uma forma de representar uma hierarquia de generalizao dada na figura 1.3. E

E1

E2

...

En

Fig. 1.3- Hierarquia de generalizao

Propriedades de Cobertura da generalizao Cobertura TOTAL ou PARCIAL A cobertura de uma generalizao total (t) se cada elemento da classe genrica mapeada para pelo menos um elemento das classes especializadas. Ex: A generalizao formada pela classe PESSOA e as subclasses HOMEM MULHER (figura 1.4) possui cobertura total. A cobertura parcial (p) se existe algum elemento da classe genrica que no mapeado para nenhum elemento das subclasses. Exemplo: Suponha que VECULO uma classe cujos elementos so todos os possveis tipos de veculos. A generalizao da figura 1.5 parcial. e

Pessoa

Veculo Carro Bicicleta

Homem

Mulher

Fig.1.4 - cobertura total

Fig.1.5 - cobertura parcial

Cobertura EXCLUSIVA ou de SOBREPOSIO: A cobertura de uma generalizao exclusiva (e) se cada elemento da classe genrica possui no mximo um elemento correspondente em uma das subclasses. Ex: A figura 1.6 representa uma cobertura exclusiva. A cobertura de sobreposio (s) se existe algum elemento da classe genrica que possui elementos correspondentes em duas ou mais subclasses. Ex: Na figura 1.6, suponha que pode existir aluno que cursa a graduao e a psgraduao ao mesmo tempo.

Aluno

AlunoGraduaao

Aluno-PsGraduao

Fig. 1.6 - cobertura de overlapping Notao: Para denotar o tipo de cobertura de uma hierarquia de generalizao ser usada a seguinte notao: (t,e), (t,s), (p,e), (p,s), como exemplificado na figura 1.7. Quando numa generalizao a cobertura no est especificada, admite-se que (t,e). Veculo (p,e) Carro Bicicleta

Fig. 1.7 - cobertura parcial e exclusiva Hierarquia de Subconjunto Uma entidade E1 um subconjunto de outra entidade E2 se toda ocorrncia de E1 for tambm uma ocorrncia de E2. um caso particular da hierarquia de generalizao. Numa hierarquia de subconjunto o tipo de cobertura (p,e) sempre, no sendo necessria sua representao no esquema conceitual. A figura 1.8 um exemplo de hierarquia de subconjunto. nro-cli nome-cli endereo taxa-desconto

Cliente

Cliente Especial

Fig.1.8 - hierarquia de subconjunto Observaes: 1. O identificador da entidade genrica tambm um identificador para as entidades da especializao. 9

2. Entidades da especializao podem ter outros identificadores, como mostrado na figura 1.9. Pessoa
RG nome ttulo

situaoserv-mil

Homem

Mulher
nomesolteira

Empr
nro-emp

Chefe
nome-diviso

Gerente
categoria

Militar
posio

diviso ident-nadiviso

Fig. 1.9 1.4. Exerccios 1. Indique na figura 1.4 se a cobertura exclusiva ou de sobreposio. 2. Indique na figura 1.6 se a cobertura total ou parcial. 3. Indique as propriedades de cobertura da generalizao na figura 1.10. Suposies: - s existem jogadores de futebol e de tnis; - pode ter jogadores que jogam os dois esportes. Jogador

Futebol Fig. 1.10

Tnis

4. Verifique como as propriedades de cobertura da hierarquia de generalizao se relacionam com as restries de cardinalidade de relacionamento. (Sugesto: interprete hierarquias de generalizao como tipos especiais de relacionamento entre classes). 5. Transforme as hierarquias do exerc.4 em relacionamentos entre a classe genrica e as subclasses. 6. Considerando a propriedade fundamental de hierarquias de generalizao, simplifique o esquema da figura 1.11. 10

(1,n) Cidade

mora (1,n) nascida Pessoa (1,1) nome

(1,n) (0,n) trabalha

reside

(1,1)

Masculino idade Soldado

Feminino

(1,1)

Empregado

(0,1) Fig. 1.11

idade

7. Considere o esquema da figura 1.11. Como voc pode mud-lo para representar no esquema todos os empregados, homens e mulheres? 8. Faa o esquema conceitual usando o modelo Entidade-RelacionamentoEstendido, do seguinte problema: Uma companhia mantm informaes sobre as pessoas que, de alguma forma, possuem com ela algum vnculo, dentre essas seus funcionrios. Os seguintes requisitos foram levantados junto aos usurios: a. De cada pessoa mantm-se um cdigo, o nome, endereo. b. De cada funcionrio guarda-se tambm seu salrio e o departamento a que ele pertence. Desses funcionrios, alguns so gerentes e para cada um destes guarda-se os nomes dos projetos que eles gerenciam. c. Dos demais funcionrios que so operrios, guarda-se suas habilidades (um operrio pode ter vrias habilidades). d. Mantm-se tambm os trabalhos executados na Companhia (cdigo e caracterstica) e os operrios que executaram cada trabalho, juntamente com o perodo que isto se deu. Sabe-se tambm que pode haver operrios que no exercem nenhum tipo de trabalho dentre os cadastrados. e. Deve-se tambm manter os dependentes de cada funcionrio (nome, sexo e data de nascimento).

11

2. Modelos de Dados Orientados a Objetos

2.1. Introduo A tcnica da orientao a objetos est cada vez mais popular para projetar e implementar sistemas de natureza variada. Com relao a bancos de dados, essa tcnica tem sido empregada, com predominncia, nos casos aonde os dados envolvidos na aplicao considerada apresentam estrutura complexa. A diferena existente entre os modelos de dados tradicionais (relacional, hierrquico e em redes) e os modelos de dados orientados a objetos est na maneira como eles vem os dados. Os modelos de dados tradicionais vem os dados como uma coleo de tipos de registros ou relaes, cada um tendo uma coleo de registros ou tuplas armazenadas em um arquivo. J num modelo de dados orientado a objetos um banco de dados considerado como uma coleo de objetos do mundo real. Embora a informao sobre objetos complexos do mundo real possa ser espalhada em tabelas relacionais, a meta dos bancos de dados orientados a objetos manter uma correspondncia direta entre os objetos do mundo real e os do banco de dados, podendo estes serem identificados e manipulados como um todo. Representar um objeto complexo no modelo relacional significa que o objeto tem que ser subdividido em um grande nmero de tuplas, o que leva necessidade de realizar um considervel nmero de operaes de juno para recuperar o objeto. Os conceitos da orientao a objetos formam uma boa base para aplicaes de banco de dados mais avanadas, como por exemplo: aplicaes de engenharia tais como CAD/CAM (Computer Aided Design/Computer Aided Manufacturation), CASE (Computer Aided Software Engineering), sistemas de informao geogrfica, sistemas de informao multimdia, sistemas de interface de usurio avanadas, etc. Essas aplicaes tem requisitos e caractersticas que diferem das aplicaes comerciais tradicionais, tais como estruturas de dados mais complexas, transaes de durao mais longa, novos tipos de dados para armazenar imagens ou textos longos e a necessidade de definio de operaes no padres especficas da aplicao. Os bancos de dados orientados a objetos foram propostos para dar suporte s necessidades dessas aplicaes mais complexas.

12

Os modelos de dados orientados a objetos usam os conceitos de abstrao de dados dos modelos semnticos (classificao, generalizao e agregao) e incorporam outros conceitos. 2.2. Conceitos Bsicos Alguns conceitos encontrados nas linguagens de programao orientadas a objetos (LPOO) so tambm aplicados nos modelos de dados orientados a objetos, porm bancos de dados requerem alguns conceitos prprios. Os objetos, em uma LPOO, existem somente durante a execuo do programa e so por isso chamados de transitrios. Um banco de dados orientado a objetos pode estender a existncia dos objetos de modo que eles sejam armazenados permanentemente, isto , os objetos so persistentes (eles persistem aps o trmino do programa e podem ser recuperados posteriormente e compartilhados por outros programas. A seguir so apresentados os principais conceitos envolvidos em bancos de dados orientados a objetos. 2.2.1. Objetos e Identidade Cada entidade do mundo real modelada como um objeto. A cada objeto associado um estado e um comportamento: o estado representado pelos valores dos atributos do objeto; o comportamento definido pelos mtodos que agem sobre o estado do objeto pela invocao de operaes. A cada objeto armazenado no banco de dados associado um identificador nico (OID: Object Identifier), que gerado pelo SGBDOO (sistema de gerenciamento de banco de dados orientado a objetos). O valor do OID no e visvel ao usurio, mas usado internamente pelo sistema para identificar cada objeto de forma nica e criar e gerenciar referncias entre objetos. A principal propriedade de um OID que ele imutvel, isto , o valor do OID de um particular objeto no deve mudar. O SGBDOO deve ter algum mecanismo para gerenciar OIDs e preservar a propriedade de imutabilidade. tambm desejvel que cada OID seja usado somente uma vez, isto , os OIDs dos objetos que so removidos do banco de dados no so reaproveitados. As duas propriedades acima implicam que o OID no deve depender de nenhum valor de atributo do objeto. Geralmente considerado no apropriado basear o OID no endereo fsico do objeto no meio de armazenamento, uma vez que o endereo fsico 13

pode mudar aps a reorganizao do banco de dados. Entretanto, alguns sistemas usam o endereo fsico como OID, para aumentar a eficincia de recuperao do objeto. Nesse caso, se o endereo fsico do objeto muda, pode ser colocado um ponteiro indireto no primeiro endereo, indicando a nova localizao fsica do mesmo. mais comum usar inteiros longos como OIDs e uma funo hash para mapear o valor do OID para o endereo fsico do objeto. 2.2.2. Valores A maioria dos SGBDOOs representam as entidades primitivas, tais como inteiros ou caracteres, por valores (no possuem OIDs), enquanto as entidades no primitivas so representadas como objetos. J outros sistemas, como o O2, permitem a definio de valores complexos que no podem ser compartilhados por outros objetos, uma vez que valores no possuem OIDs. 2.2.3. Estrutura do objeto O valor de cada atributo de um objeto pode ser: - atmico: integer, real, character, booleano, etc. - complexo: definido atravs de construtores: tuple, set, list, bag e array. O construtor de tipo tuple serve para agregar informaes afins. freqentemente chamado de tipo estruturado, pois corresponde ao construtor struct nas linguagens de programao C e C++. Os construtores de tipo set, list, array e bag so chamados de tipos de coleo e servem para definir atributos multivalorados. Podem ser no ordenados (set e bag) ou ordenados (list e array). Em um set no pode haver dois elementos com o mesmo valor, enquanto que na bag isso possvel. 2.3.4. OIDs x Chaves Primrias Nos modelos orientados a objetos no existe o conceito de chave primria como acontece no modelo relacional. Ao invs disso, existem os OIDs dos objetos que, como j dito, so criados e mantidos pelo sistema de gerenciamento de banco de dados e no so de acesso do usurio. As vantagens do uso de OIDs com relao s chaves so: - os programadores de aplicaes no precisam se preocupar com a seleo de chaves para as vrias classes de objetos;

14

- obtm-se melhor desempenho, pois os OIDs so implementados em baixo nvel pelo sistema; - embora as chaves sejam mais significativas ao usurio, muitas vezes o usurio precisa usar cdigos artificiais, sem significado semntico, para poder identificar as tuplas de uma relao. 2.3.5. Objetos Complexos A composio estrutural de um objeto definida atravs de um atributos.

conjunto de

O valor de cada atributo pode ser primitivo, um objeto ou uma

combinao dos construtores tupla, lista, array, conjunto ou bag, envolvendo outros objetos ou no. Objetos complexos so definidos atravs de construtores envolvendo outros objetos. Quando o valor de um atributo de um objeto O um objeto O, o sistema armazena o identificador de O em O ou todo o valor complexo armazenado no atributo do objeto. 2.3.6. Encapsulamento A cada objeto est associada sua estrutura e seu comportamento (os mtodos ou operaes). O comportamento armazenado no banco de dados junto com a estrutura do objeto. O conceito real de encapsulamento determina que somente as operaes sobre os objetos so visveis e sua estrutura escondida. Em banco de dados a noo de invisibilidade da estrutura do objeto afrouxada. desejvel, por exemplo, poder consultar os atributos do objeto atravs de uma linguagem de consulta. Assim, a maioria dos SGBDOOs permitem acesso direto aos atributos fornecendo operaes definidas pelo sistema para a leitura e modificao dos atributos, o que livra o usurio da incumbncia de implementar uma considervel quantidade de mtodos cujo nico propsito ler e escrever os valores dos vrios atributos dos objetos. Isso um exemplo de violao do encapsulamento permitida pelos SGBDOOs. Esses sistemas, porm, possuem mecanismos para que o usurio possa proteger o acesso aos atributos dos objetos, caso desejvel. O sistema O2, por exemplo, permite o usurio estabelecer quais atributos e mtodos so visveis na interface do usurio, atravs da declarao public, o que permite serem invocados por qualquer outro objeto. Os no visveis so referidos como private. 15

2.3.7. Mtodos Os objetos nos SGBDOOs so manipulados atravs de mtodos. Em geral, a definio de um mtodo consiste de assinatura e corpo. A assinatura especifica o nome do mtodo, os nomes e classes dos argumentos e a classe do resultado, se existir. O corpo representa a implementao do mtodo e consiste de um conjunto de instrues expressas em uma dada linguagem de programao. 2.3.8. Tipos e Classes Um tipo modela as caractersticas comuns de um conjunto de objetos e corresponde noo de tipos abstratos de dados. Uma classe um conjunto de objetos que tem exatamente a mesma estrutura interna, i., os mesmos atributos e mesmos mtodos. Os modelos de dados orientados a objetos usam o conceito de classe como uma base para instanciao. 2.3.9. Herana um mecanismo de reusabilidade muito poderoso. Com herana, uma classe chamada uma subclasse pode ser definida com base na definio de outra classe chamada a superclasse. A subclasse herda os atributos, mtodos e mensagens de sua superclasse e pode ter atributos especficos, mtodos e mensagens adicionais. Exemplo: Considere duas classes com informaes sobre um conjunto de nibus e caminhes. As caractersticas das duas classes so mostradas na figura 2.1 cuja notao grfica utilizada representa cada classe por um retngulo dividido em 3 partes. A parte superior contm o nome da classe; a do meio contm os atributos e a inferior contm os mtodos definidos pelo usurio. Como as duas classes possuem algumas caractersticas em comum, pode-se criar a classe Veculo para conter essas caractersticas, como na figura 2.2. Somente as caractersticas prprias de cada subclasse so mantidas na mesma.

16

Caminho nro-placa:STRING modelo:STRING licena:NUMBER data_ltima_reviso:DATE valor_estimado:NUMBER prxima_reviso:DATE Fig.2.1

nibus nro-placa:STRING modelo:STRING lugares:NUMBER data_ltima_reviso:DATE prxima_reviso:DATE

Veculo nro-placa:STRING modelo:STRING data_ltima_reviso:DATE prxima_reviso:DATE

Caminho licena:NUMBER valor_estimado:NUMBER

nibus lugares:NUMBER

Fig. 2.2 - Hierarquia de herana

Vantagens da utilizao de hierarquias de classe: - diminui a quantidade de cdigo a ser escrito; - propicia uma descrio mais precisa e concisa da realidade. Em certos sistemas, uma classe pode ter vrias superclasses, em cujo caso diz-se que ocorre herana mltipla (fig.2.3), enquanto outros impem a restrio de uma nica superclasse, dita herana simples.

17

Veculo nro-placa:STRING modelo:STRING data_ltima_reviso:DATE prxima_reviso:DATE Veculo_Passageiro rota: STRING preo:NUMBER horrio_sada:NUMBER

Caminho licena:NUMBER valor_estimado:NUMBER

nibus lugares:NUMBER

Fig. 2.3 - Herana mltipla

A herana mltipla pode provocar problemas de conflitos, como por exemplo, duas ou mais superclasses podem ter um atributo com o mesmo nome, mas com diferentes domnios. Esses conflitos precisam ser tratados pelo sistema. Se existe uma relao de incluso entre os domnios, ento o domnio mais especfico ser escolhido como o domnio para a subclasse. Por exemplo, se na classe Veculo existir o atributo combustvel cujo domnio : (gasolina, lcool, diesel) e em Veculo_Passageiro existir tambm o atributo combustvel cujo domnio (diesel), a classe nibus herdar o atributo combustvel cujo domnio ser (diesel) (figura 2.4), isto , o domnio mais restrito. Se essa relao no existe, uma soluo adotada a escolha do domnio com base na ordem de precedncia entre as superclasses. Outros sistemas deixam por conta do usurio a resoluo do conflito. Em um esquema de bd, as classes podem ser organizadas em uma hierarquia de herana, formando um grafo acclico dirigido.

18

Veculo nro-placa:STRING modelo:STRING data_ltima_reviso:DATE combustvel:(gasolina, lcool,diesel) prxima_reviso:DATE Veculo_Passageiro rota: STRING preo:NUMBER horrio_sada:NUMBER combustvel:(diesel)

nibus lugares:NUMBER Fig. 2.4 - Herana mltipla combustvel:(diesel)

2.3.10. Polimorfismo Os SGBDOOs oferecem o recurso de polimorfismo de operaes, tambm conhecido como sobrecarga de operador (overloading). Outros conceitos relacionados com o polimorfismo so os de late binding (ligao tardia) e overriding (redefinio de operao). Para melhor expor esses conceitos, considere uma operao display que recebe um objeto como entrada e apresenta o objeto na tela. Se o objeto for: - uma imagem: deseja-se apresentar a imagem; - uma pessoa: deseja-se apresentar os dados sobre a pessoa (nome, endereo, etc); - um grfico: deseja-se apresentar uma representao grfica. Usando um sistema convencional, seriam necessrias 3 operaoes: display_pessoa, display_figura e display_grfico, como mostrado a seguir: for x in X do begin case of type(x) pessoa: display_pessoa(x); figura: display_figura(x); grfico: display_grfico(x); end; end; 19

Em um sistema orientado a objetos, a operao display pode ser definida em uma classe mais geral. A operao tem um nico nome e pode ser chamada indiscriminadamente por vrios objetos. A implementao da operao redefinida para cada uma das subclasses. Essa redefinio chamada overriding. O sistema decide qual implementaco usar para execuo. Assim, o cdigo dado simplificado para: for x in X do display(x) A ligao do nome da operao com a correspondente implementao realizada em tempo de execuo. Essa ligao retardada dita late binding. A sobrecarga (overloading) de operador refere-se ao uso do mesmo smbolo de operador para denotar operaes distintas sobre diferentes tipos de dados.

20

3. Modelagem de Dados Orientada a Objetos

3.1. Motivao A motivao mais imediata para a adoo dos princpios da orientao a objetos para a modelagem de dados que o mundo real pode ser visto como uma variedade de objetos inter-relacionados. Os objetos podem ser vistos em diferentes nveis de detalhe. Por exemplo, para um observador, uma rvore pode ser vista como um objeto indivisvel, sem levar em considerao sua composio em folhas, troncos, raiz, etc. Outro observador pode estar interessado em analis-la com mais detalhe, por exemplo, considerando a cor, textura e forma das folhas. Neste caso, as folhas so consideradas objetos que fazem parte da composio do objeto rvore. Essa maneira natural de ver a composio dos objetos deve ser conservada na modelagem dos objetos e o objetivo dos modelos de dados orientados a objetos, fornecendo uma representao mais natural do mundo real. Assim como na modelagem de dados convencional, a modelagem de dados orientada a objetos aqui abordada ser realizada em 2 fases: 1. Projeto conceitual: Essa fase visa o projeto de um esquema conceitual que apresente uma abstrao do problema do mundo real. Uma diferena quando se trata de projeto conceitual do banco de dados orientado a objetos que, alm da definio da estrutura dos objetos, tambm so definidos os mtodos que manipulam esses objetos. Assim, toda a funcionalidade do sistema definida juntamente com a estrutura dos objetos. 2. Projeto lgico: projeto de uma estrutura lgica, representando o esquema lgico do banco de dados orientado a objetos, com base no esquema conceitual. 3.2. Desenvolvimento de Sistemas Orientados a Objetos O desenvolvimento de sistemas orientados a objetos usa uma abordagem diferenciada daquela utilizada para o desenvolvimento de sistemas de informao tradicionais. 21

Desenvolvimento de sistemas tradicionais: O desenvolvimento de sistemas de informao nos moldes convencionais realizando com base na perspectiva dos dados e na dos processos. Do ponto de vista da perspectiva dos dados, o desenvolvimento do sistema envolve a modelagem E-R dos dados, a anlise relacional, a gerao do esquema lgico e a implementao fsica do bd. Sob a perspectiva dos processos, o desenvolvimento do sistema trata os requisitos funcionais do sistema envolvendo a construo de DFDs (diagramas de fluxos de dados), especificao das funes do sistema e dos mdulos de programa. Desenvolvimento orientado a objetos: O desenvolvimento orientado a objetos usa o princpio de abstrao de dados, aonde as funcionalidades do sistema so associadas com os objetos (objetos encapsulam dados e comportamento). 3.3. Modelando Objetos Na modelagem da estrutura dos objetos, dois tipos de hierarquias so utilizadas: a hierarquia de agregao (relacionamento -PARTE-DE) e a hierarquia de generalizao/especializao (relacionamento -UM). No esquema lgico do banco de dados o.o., hierarquia de agregao estabelecida atravs de referncias. A hierarquia de generalizao/especializao estabelecida atravs de declaraes prprias. A seguir apresenta-se, atravs de exemplos usando uma linguagem de definio de objetos fictcia, como realizada a definio das classes e a definio de hierarquias de generalizao/especializao. 3.3.1. Definio de classe A definio de classe uma especificao abstrata. Por exemplo: classe Conta_Corrente com as propriedades: nro_conta, proprietrio, saldo_corrente (veja especificao abaixo). As propriedades podem ser definidas em termos de outras classes: o proprietrio de uma conta uma instncia de uma classe Cliente. As propriedades de proprietrio representam objetos inteiros, no valores de chaves ou ponteiros. class Conta_Corrente properties 22

nro_conta: Integer; proprietrio: Cliente; saldo_corrente: Money; operations deposito(quantia: Money); retirada(quantia: Money); end Conta_Corrente. class Cliente properties nome: String; ... operations ... end Cliente

3.3.2. Herana Para especificar a hierarquia de classe e subclasse ser utilizada a declarao inherits. No exemplo a seguir tem-se que a classe Carro herda todas as propriedades e operaes da classe Veculo. class Veculo properties nro_reg, marca, modelo: String; cor: String; milhas: Integer; tipo_combustvel: (lcool, gasolina, dsel); ano: Integer; operations ... end Veculo. class Carro inherits Veculo properties tipo_combustvel: (lcool, gasolina); {redefinido} {propriedades adicionais de carro} tamanho: (compacto, mdio, grande); extras: set(String); end Carro.

3.4. Representao grfica A seguir ser apresentada uma notao grfica para representao conceitual de objetos, que tem como objetivo oferecer uma forma simplificada para a modelagem de um banco de dados orientado a objetos. Vrias notaes existem na 23

literatura, entre elas a UML, que podem ser adotadas para essa fase do projeto do banco de dados o.o. A adoo dessa notao visa simplicidade e utilizao dos recursos dos construtores tuple, list e set, que so bastante expressivos para uma variedade de aplicaes de bdoo. 3.4.1. Representao de uma classe de objetos

nome da classe nome_mtodo(param); ...

atributo1 atributo2
...

atributon

3.4.2. Representao de conjunto, lista e tupla Conjunto (SET): Lista (LIST):

Tupla (TUPLE):

Exemplo: nome-rua rua bairro Dependente Fig. 3.1 Na figura 3.1 est representado que uma pessoa pode ter vrios telefones, sendo que os mesmos devem ser armazenados segundo uma ordem. Essa ordem definida de acordo com a semntica da aplicao; por exemplo, a lista de telefones 24 nmero nome sexo datanasc

Pessoa

nome endereo telefone filhos

pode estar representando a ordem de preferncia a ser usado para se entrar em contato com a pessoa. Cada pessoa pode possuir vrios filhos, que esto representados por um conjunto de objetos do tipo Dependente. ATENO: Quando um atributo possui tipo simples e envolve o construtor SET ou LIST, a indicao desse construtor inserida na seta de definio do atributo.

3.4.3. Herana simples a) uma s subclasse nome endereo telefone b) vrias subclasses nome endereo telefone

Pessoa

Pessoa

Cliente

nro-cliente ender-comercial

ClienteCasual

renda limitecred

ClienteFrequente

nro-cliente dbito

Fig. 3.2 a e b - Herana Simples

3.4.4. Herana mltipla * : indica o atributo a ser herdado no caso de conflito.

25

nome endereo cpf

Cliente

Funcionrio

nome* nro-carteira-trab endereo* salrio

Cliente Interno

dbito

Fig. 3.3- Herana Mltipla

3.4.5. Definio recursiva nome endereo filhos

Pessoa

Fig. 3.4 - Definio Recursiva

3.4.6. representao de referncias inversas Quando a referncia entre duas classes nos dois sentidos, usa-se a notao da figura 3.5, aonde est representado que cada projeto possui um conjunto de empregados (atravs do atributo empregs) e cada empregado atua em um projeto.

Projeto

empregs

proj

Empregado

Fig. 3.5 - referncias inversas

3.5. Gerao do Esquema Lgico Para a gerao do esquema lgico ser adotada a linguagem utilizada na seo 3.3, cuja forma geral dada seguir:

26

class nome_da_classe inherits nome_superclasse1, . . ., nome_superclassej properties nome_atrib1: tipo; nome_atrib2: tipo; ... nome_atribj: tipo; operations nome_mtodo(parmetros); ... ; end nome_da_classe A definio do tipo segue a seguinte regra de sintaxe: tipo :: = tipo-bsico / nome-classe /tipos_inversos tuple (nome-atributo: tipo [, nome-atributo:tipo] ...) / set(tipo) / list(tipo) tipo-bsico :: = Integer / Real / String / Boolean / ... nome-classe : nome de uma classe existente (um identificador) nome-atributo : identificador tipos_inversos: nome_classe_inversa inverse is nome_classe_inversa. atrib_inverso/ set(nome_classe_inversa) inverse is nome_classe_inversa. atrib_inverso/ list(nome_classe_inversa) inverse is nome_classe_inversa. atrib_inverso/ Por conveno, nos esquemas conceitual e lgico, os nomes dos atributos so escritos com letras minsculas e os nomes das classes iniciam com letra maiscula. Exemplo : O esquema da figura 3.1 expresso como: class Pessoa properties nome : String; endereo: tuple ( rua: tuple ( nome_rua: String, nmero: Integer), bairro:String); telefone: list (Integer); filhos: set (Dependente); end Pessoa

class Dependente properties nome: String; sexo: String; data_nasc: Date; 27

end Dependente A especificao das classes da figura 3.5 dada a seguir: class Projeto properties empregs: set(Empregado) inverse is Empregado.proj; end Projeto; class Empregado properties proj: Projeto inverse is Projeto.empregs; end Empregado;

3.6. Exemplo: Banco de Dados para Gerenciamento de Projetos Suponha que deseja-se manter um banco de dados com informaes sobre os projetos desenvolvidos pelos grupos de pesquisa de uma instituio. As informaes a serem armazenadas referem-se aquelas sobre projetos, especificando as tarefas que compem cada projeto, os grupos de pesquisa que desenvolvem as tarefas do projeto, os pesquisadores que fazem parte dos grupos e os documentos produzidos relativos aos projetos. O esquema conceitual orientado a objetos desse banco de dados mostrado na figura 3.6, aonde se tem que: - Um projeto pode ser organizado na forma de vrios sub-projetos e a classe Projeto definida recursivamente em termos dela mesma. - Um plano de trabalho, consistindo de vrias tarefas, associado a cada projeto. - Cada tarefa atribuda a um grupo de pesquisa que consiste de vrios pesquisadores e tem um coordenador. Note-se que o coordenador de uma tarefa no necessariamente o coordenador do grupo de pesquisa atribudo para a tarefa. Para cada tarefa so identificadas as tarefas que a antecedem.

28

Para cada projeto h vrios documentos produzidos, que podem ser artigos publicados em jornais ou conferncias ( cujos autores so pesquisadores que atuam no projeto), ou relatrios tcnicos internos do projeto.

Os seguintes mtodos devem ser definidos: Calcular_esforo, para a classe Tarefa, que calcula o esforo dedicado pelos pesquisadores para desenvolvimento da tarefa, em termos do tempo dedicado. Associar_membro, para a classe Grupo, que insere um novo pesquisador num determinado grupo de pesquisadores. Analisar_documento, classificao. Calcular_bnus, que calcula o valor total dos bnus recebidos pelos pesquisadores. A figura 3.6 mostra o esquema conceitual do banco de dados o.o. desse exemplo, usando a notao dada. Para permitir uma comparao com a UML, uma verso desse esquema, usando sua notao, tambm fornecida na figura 3.10. que recupera documentos de uma determinada

29

Projeto

nome_ proj objetivo documento plano_trabalho sub_projeto

Documento
analisar_doc(classif:String)

cdigo_doc nome classificao

tpicos incio_validade fim_validade evoluo

Relatrio_ Tcnico

Artigo

autor tipo_publ local_publ data_publ

Tarefa

calcular_esforo()

data_incio data_fim descrio_tarefa coordenador anos_homem participante precede

Pesquisador calcular_bonus()

nome especializao salrio bnus_produo

Grupo associar_membro() Fig.3.6 Banco de Dados para Gerenciamento de Projetos

nome_grupo membro coordenador

30

3.7. Notao adotada X diagrama de classes UML UML (Universal Modeling Language) uma linguagem de modelagem de objetos, desenvolvida principalmente para projeto de software. Os diagramas de classes, que fazem parte de UML, possuem alguma semelhana com os diagramas EER. Para acompanhar a discusso a seguir, considere o esquema de banco de dados EER de uma companhia, da figura 3.7, e sua representao na notao UML na figura 3.8 (apresentados no livro de Elmasri & Navathe, 2000). Os tipos de entidades da figura 3.7 so modelados como classes na figura 3.8. Na notao UML, uma classe representada por uma caixa com 3 sees: a do topo contm o nome da classe; a seo do meio contm os atributos dos objetos da classe e a ltima seo contm as operaes que podem se aplicadas sobre esses objetos. Opcionalmente pode-se especificar o domnio dos atributos (por exemplo: datanasc: date), como mostrado na figura 3.8. Um atributo composto modelado como um domnio estruturado, como ilustrado pelo atributo Nome da classe Empregado. Um atributo multivalorado geralmente modelado como uma classe separada, conforme ilustrado pela classe Localizao. Na terminologia UML, tipos de relacionamentos so chamados associaes e instncias de relacionamentos so chamados links. Uma associao binria (correspondendo a um tipo de relacionamento binrio do modelo EER) representada atravs de uma linha conectando as classes participantes e podem opcionalmente Ter um nome. Um atributo de relacionamento, chamado de atributo de ligao (link attribute) colocado em uma caixa que conectada linha da associao por uma linha pontilhada. A notao (min, max) usada para especificar restries de relacionamento no modelo EER, chamada de multiplicidade em UML. Multiplicidades so representadas na forma min .. max, e o asterisco (*) indica que no h limite mximo na participao. Note-se que as multiplicidades so colocadas nos lados opostos do relacionamento quando comparadas notao do modelo EER. Em UML, um asterisco sozinho indica uma multiplicidade de 0..*, e 1 sozinho indica uma multiplicidade de 1..1. Um relacionamento recursivo (relacionamento unrio) chamado uma associao reflexiva em UML e os nomes dos papis, da mesma forma que as multiplicidades, so colocados nos lados opostos quando comparados ao diagrama EER. 31

Em UML h dois tipos de relacionamentos: associao e agregao. Uma agregao representa um relacionamento entre um objeto e suas partes componentes. Na figura 3.8 as localizaes de um departamento e a localizao de um projeto foram modelados como agregaes. Associaes e agregaes no possuem propriedades estruturais diferentes, elas diferem apenas no significado semntico. No modelo EER, ambas so representadas como relacionamentos. Associaes ou agregaes unidirecionais, em UML, so mostradas com uma seta para indicar que somente necessria uma direo para acessar os objetos. Instancias de relacionamento podem ser especificadas como sendo ordenadas. nome nroE sexo prim_nome sobrenome endereo salrio data nasc (1,1) (0,1) (0,n)
Supervisiona

nroD Trabalha data-incio Gerncia (4,n)

nro-empregados nome localizao (1,n) Departamento

Empregado

(1,1)

(0,n)

(0,1)

supervisionado

(1,n)

horas Atua (1,n)

Controla (1,1)

Supervisiona (0,n)

Possui (1,1) Dependente nome sexo Data_nasc

Projeto

nro nome localizao

grau-parentesco Figura 3.7- Esquema EER - BD Companhia

32

Empregado 4..* nroE nome prim_nome sobrenome sexo: { M,F} endereo salrio data_nasc: Date 1..1 Trabalha 1..1 0..1

Departamento nroD nome Adiciona-empr Nro-empregados Muda-gerente ... 1..1 controla Atua supervisionado * 0..1 supervisiona Horas 1..* Projeto Nome Nro Adiciona_empr Adiciona_projeto ... * 1..1 0..*

Gerncia Data_Inicio 1..*

1..* Localizao Nome

idade muda-depto ... Nome Dependente

0..*

Dependente Sexo: {M,F} Data nasc: Date Grau-parentesco ... Figura 3.8 Diagrama de classes UML BD Companhia

As operaes dadas em cada classe podem ser acompanhadas pelos parmetros. Entidades fracas podem ser modeladas usando o construtor chamado associao qualificada (ou agregao qualificada). A chave parcial colocada em uma caixa anexada classe proprietria.

33

A notao UML para generalizao/especializao mostrada na figura 3.9. O tringulo vazio indica cobertura exclusiva e o tringulo cheio indica cobertura de sobreposio. Pessoa nro nome endereo RG

Empregado Salrio

Cliente tipo cliente porcent-desconto

Pessoa fisca CPF

Pessoa Juridca CGC

Figura 3.9 Generalizao/especializao em UML Na Figura 3.10 tem-se o BD Companhia modelado segundo a notao de objetos considerada nesta apostila e a figura 3.11 mostra o BD de Projeto modelado segundo a notao UML, usando a ferramenta Rational Rose.

34

nome nroE

prim_nome

sobrenome sexo endereo salrio

data_nasc emprs ger data-incio gerente

Empregado idade muda-depto ... supervisor depends

depto-trab

Departamento Adiciona-empr Nro-empregados Muda-gerente ... projs

nroD nome

atua

horas

Dependente ...

proj

emps

Projeto adiciona-empr adiciona-proj nome nro localizao

grau_parentesco nome sexo data_nas Figura 3.10 Esquema de Objetos - BD companhia

35

+compe 0..1

Projeto nome_proj : string objetivo : string 1 possui 1..*

gera 1 0..*

Documento codigo_doc : int nome : string classificao : string analisar_documento()

0..* +_composto

+_precedida 0..* 0..* +precede

Tarefa data_inicio : date data_fim : date descrio_tarefa : string anos_homem : float calcular_esforo() 1..* participa 1 Grupo nome_grupo : string associar_membro() 0..1 1..* 0..*

Relatrio_Tcnico tpicos : string incio_validade : date fim_validade : date

Artigo tipo_publ : string local_publ : string data : date 0..* escreve

coordena 1 membro 1..*

1..* Pesquisador nome : string especializao : string salrio : float bnus_produo : float calcular_bnus()

coordena

Fig.3.11 - BD de Projeto- notao UML

Legenda
Class ClassName attributes operations() Agregation Association Multiplicity 0 1 0..1 0..* 1..* * zero one zero or one zero or more one or more n

36

3.8. Exerccios 1. Mapeie o esquema da figura 3.6 para a linguagem de especificao de objetos dada na seo 3.5.

2. Desenvolva o esquema conceitual orientado a objetos do problema do exerccio 8 do captulo 1 e faa o mapeamento para a linguagem de especificao de objetos dada. 3. Desenvolva o esquema conceitual orientado a objetos da aplicao a seguir, referente ao cadastro imobilirio de uma cidade. Faa o mapeamento para a linguagem de especificao de objetos dada. Nessa aplicao esto envolvidas informaes relativas a bairros, ruas, quadras, segmentos de quadras e imveis. As informaes a serem mantidas sobre cada bairro so: Nome do bairro, delimitao (regio que delimita o bairro) e composio (quadras que compem o bairro). Sobre cada quadra, necessrio armazenar: cdigo da quadra e composio (imveis que compem a quadra). Com relao s ruas, deve-se guardar o cdigo da rua, nome, o incio da rua (ponto de coordenadas (x,y)) e a composio (segmentos de quadra que compem a rua). Os segmentos de quadra devem possuir um cdigo, nmero inicial, nmero final e composio (uma seqncia ordenada de pontos (x,y)). Quanto aos imveis, as informaes a serem mantidas so: cdigo de inscrio, proprietrio (nome e categoria: particular, municipal,etc), localizao (rua, nmero, bairro). No caso de haver construo no imvel, deve-se guardar tambm informaes sobre: utilizao (residencial, comercial,...) e delimitao da construo.

37

4. Deseja-se desenvolver um banco de dados que armazene informaes sobre um acervo de CDs e Livro. O banco de dados deve conter informaes sobre os CDs, como a nacionalidade, o tipo de CD, se musical ou multimdia, no permitindo para um mesmo CD, ser de ambos os tipos. Se for CD de msica, as informaes consistem no nome do CD, cantores e compositores, gnero, nmero de msicas e tempo total gravado; caso seja multimdia, o tipo de software e a empresa responsvel. Para os Livros deseja-se informaes como nome, autores, editora, gnero, edio e encadernao. A base de dados tambm armazena informaes sobre emprstimo de CDs e Livros a pessoas fsicas, armazenando o nome da pessoa, telefone, e-mail e a data de emprstimo, permitindo assim, o controle do acervo. Suponha que as seguintes atividades devem ser realizadas: a) Dado um ttulo (referente a um nome de Cd ou de Livro), recuperar: gnero e compositores, se for CD de msica; empresa responsvel, se for CD Multimdia; ou nomes dos autores, se for livro.

a) Dado o nome de um CD, recuperar nome e telefone da pessoa que emprestou o CD. b) Dado o nome de uma Pessoa Fsica, mostrar seu telefone e o nome dos CDs que ela emprestou. Faa um esquema conceitual e o esquema lgico correspondente.

38

4. Manipulando Objetos
A manipulao de objetos feita atravs de uma linguagem de consulta a objetos. Uma linguagem de consulta oferece uma forma de recuperar informaes do banco de dados de uma maneira declarativa e formulada em alto nvel. Muitos Sistemas de Gerenciamento de Banco de Dados Orientados a Objetos utilizam uma extenso da linguagem de consulta SQL (Structured Query Language), uma das mais utilizadas para SGBDs relacionais, incorporando nesta mecanismos para manipulao da estrutura complexa dos objetos. A formulao de consultas podem ser feitas interativamente para recuperar objetos do banco de dados ou podem ser embutidas em uma linguagem de programao, na definio de mtodos. 4.1. Caractersticas de Linguagens de Consulta OO (LCOO) 4.1.1. Hierarquias de Agregao No modelo relacional, para consultar informaes envolvendo mais do que uma tabela, usa-se a operao de juno sobre seus atributos chaves (primrias / estrangeiras). Como exemplo, suponha as tabelas abaixo e, a seguir, uma consulta sobre essas tabelas: Projeto (codproj, nome_proj, objetivo, ...) Tarefa (codtarefa, data-incio, data-fim, ...,codproj, codpesq) Pesquisador(codpesq, nome, especializao,salrio) Encontre todos os nomes de projetos que tm pelo menos uma tarefa possuindo, como seu coordenador, um pesquisador especializado em banco de dados. Essa consulta pode ser expressa em SQL como dado a seguir, aonde se nota a utilizao de dois predicados de juno : SELECT DISTINCT Projeto.nome_proj FROM Projeto, Tarefa, Pesquisador WHERE Projeto.codproj = Tarefa.codproj and Tarefa.codpesq = Pesquisador.codpesq and Pesquisador.especializao = BD

39

Nas linguagens de consulta orientadas a objetos so utilizadas expresses de caminho de modo que as junes sejam formuladas de forma mais direta, sendo referidas como junes implcitas. Isso ocorre devido forma em que os objetos so estruturados envolvendo hierarquias de agregao, conforme mostrado na figura 4.1. Nessa figura, o atributo de uma classe C1 tem como domnio uma classe C2 estabelecendo um relacionamento de agregao entre as duas classes. C2, por sua vez, definido em termos da classe C3. Diz-se ento que essas classes esto organizadas no esquema atravs de uma hierarquia de agregao. C1 atrib_c1 C2 atrib_c2 C3 atrib_c3

Fig. 4.1 - Hierarquia de agregao Isso implica em certas extenses linguagem de consulta, para possibilitar a navegao atravs da estrutura do objeto, com facilidade (tente imaginar, por exemplo, como se pode expressar a consulta dada anteriormente, sobre o esquema da figura 3.6, utilizando a juno implcita). 4.1.2. Hierarquia de Herana Numa hierarquia de herana, pode-se querer consultar s a classe raiz ou a classe e todas as suas subclasses. interessante que a linguagem de consulta oferea as duas possibilidades. 4.2. Consultando Objetos 4.2.1. Hierarquias de Agregao Numa hierarquia de agregao, a expresso de caminho pode envolver referncias simples ou multivaloradas. A seguir so apresentadas expresses de consultas envolvendo essas duas formas de referncia. A sintaxe apresentada baseiase em linguagens de consulta de gerenciadores existentes, mas no se refere exatamente sintaxe de um gerenciador especfico. Referncias Simples Com base na figura 4.1, a consulta: selecionar o valor do atributo atrib_c3 de um objeto x pertencente classe C1, que satisfaz uma certa condio 40

pode ser expressa como: Select x. atrib_c1. atrib_c2. atrib_c3 From x in C1 Where condio de seleo Exemplo: Expressar a seguinte consulta no Banco de Dados de Projeto (figura 3.6): Selecionar o nome dos coordenadores das tarefas que iniciaram em 01/02/99. Select t.coordenador.nome From t in Tarefa Where t.data_incio = '01/02/1999' Referncias Multivaloradas Considere a figura 4.2 e a seguinte consulta: Selecionar os valores do atrib_c2 de um objeto x pertencente classe C1, que satisfaz uma certa condio. Como existe uma referncia multivalorada de C1 para C2, necessrio percorrer cada elemento do atributo atrib_c1 para recuperar o valor correspondente de atrib_c2 desse elemento. C1 atrib_c1 C2 atrib_c2

Fig. 4.2 - Uso de Referncia Multivalorada Select y.atrib_c2 From x in C1 y in x.atrib_c1 Where condio de seleo Exemplo: Na figura 3.6: Selecione o cdigo e a classificao dos documentos do Projeto "Projeto A". Select d.cdigo_doc, d.classificao From p in Projeto d in p.documento // documento o nome do atributo e no da classe 41 Where p.nome_proj = "Projeto A"

4.2.2. Hierarquia de Herana A recuperao de informaes de uma subclasse que foram herdadas de uma superclasse, podem ser referenciadas como pertencente subclasse. Exemplo: com base na figura 3.5, pode-se formular a seguinte consulta: Selecione os nomes dos artigos publicados em 20/05/99. Select a.nome From a in Artigo Where a.data = "20/05/1999" 4.3. Definio de Mtodos A seguir so apresentados os algortmos de alguns mtodos desenvolvidos para o Banco de Dados da figura 4.3, que uma simplificao do Banco de Dados de Projeto. Alguns gerenciadores de banco de dados orientados a objetos possuem uma linguagem de quarta gerao, estilo C++, para a codificao dos mtodos. Opcionalmente permitem o uso de outras linguagens de programao, tais como C++, C, Smalltalk, nas quais pode-se embutir comandos da linguagem de consulta do gerenciador.

42

Projeto
Busca_Proj Cadastra_Projeto Mostra_Documentos Elimina_Proj

cod_proj objetivo documento coordenador nome_proj

Documento
Mostra

cdigo_doc nome classificao

tpicos incio_validade fim_validade

Relatrio_ Tcnico
Cadastra_RT Mostra

Artigo
Cadastra_Art Mostra

aut_princ tipo_publ local_publ data_publ

Pesquisador
Busca_Pesq Cadastra_Pesq

nome especializao salrio bnus_produo

Fig. 4.3 - BD de Projeto simplificado Alguns dos mtodos definidos nas classes da figura 4.3 so dados a seguir, usando uma linguagem algortmica. 1. Cadastrar um Projeto, sem documentos e com coordenador Mtodo Cadastra_Projeto(nome_coord:String,codigo:Integer, obj:String, nome_projeto:String) da classe Projeto proj:Projeto; pesq:Pesquisador; { pesq=Busca_Pesq(nome_coord); proj.cod_proj=codigo; proj.objetivo=obj; proj.coordenador=pesq; proj.nome_proj=nome_projeto; Insira proj em Projeto; }

43

2. Recuperar um Pesquisador, dado seu nome. Mtodo Busca_Pesq(nome_pesq:String):Pesquisador da classe Pesquisador {Select pesq From pesq in Pesquisador Where pesq.nome=nome_pesq return(pesq); }

3. Recupera um projeto dado seu cdigo. Mtodo Busca_Proj(codigo_proj:Integer):Projeto da classe Projeto { Select proj From proj in Projeto Where proj.cod_proj=codigo_proj; return(proj); } 4. Mostrar os documentos (Relatrio Tcnico ou Artigo) de um projeto, dado seu cdigo. Se Relatrio Tcnico, mostrar incio e fim de validade e o nome. Se Artigo, mostrar tipo de publicao e nome do artigo. Mtodo Mostra ( ) da classe Documento { } // no faz nada Mtodo Mostra( ) da classe Relatrio_Tcnico // Mostrar incio e fim de validade e nome do relatrio tcnico resultado: tupla(incio_val:Date, fim_val:Date, nome_rel:String) {resultado.inicio_val = self.inicio_validade; resultado.fim_val = self.fim_validade; resultado.nome_rel = self.nome; display(resultado); }

44

Mtodo Mostra( ) da classe Artigo //Mostrar tipo de publicao e nome do artigo resultado: tupla(tipo_pub:String, nome_art:String) {resultado.tipo_pub = self.tipo_publ; resultado.nome_art = self.nome; display(resultado); }

Mtodo Mostra_Documentos (cod_projeto:Integer) da classe Projeto p:Projeto; { p=Busca_proj(cod_projeto); // recupera o projeto Para cada d de p.documento faa d.Mostra( ); // ativar o mtodo mostra no documento d } 5. Eliminar um projeto de cdigo dado (sem eliminar pesquisador e documento) Mtodo Elimina_proj(cod_proj:Integer):Boolean da classe Projeto // sem eliminar um pesquisador e os documentos p:Projeto; { p=Busca_proj(cod_proj); // ou: selecione projeto p na classe Projeto onde p.cod_proj=cod_proj; Se achou ento {Retira p de Projeto return(true)} seno return(false) }

6. Cadastrar um documento (pode ser relatrio tcnico ou artigo). Incluir esse documento no projeto que o gerou ( fornecido como entrada o cdigo do projeto). Mtodo Cadastra_RT (cod_doc:Integer, nome_doc:String, classific:String, tpicos:String; inicio_val, fim_val:Date, cod_proj:Integer) da classe Relatrio_Tcnico rt:Relatorio_Tecnico; proj:Projeto; { rt.codigo_doc=cod_doc; rt.nome=nome_doc; rt.classificacao=classific; rt.topicos=topicos; rt.inici_validade=inicio_val; 45

rt.fim_validade=fim_val; Insira rt em Relatorio_Tecnico; // Inserir o relatorio tecnico nos documentos do projeto dado proj=Busca_proj(cod_proj); Se proj nulo ento Insira rt em proj.documento; }

4.4. Exerccios 1. Faa o mtodo Cadastra_Artigo. Formule as consultas a seguir, com base no esquema da figura 3.6. 2. Recupere os documentos do projeto de nome Projeto A. 3. Supondo que os autores sejam modelados como uma lista de pesquisadores, representando a ordem em que eles aparecem no artigo, formule a consulta: a) Recupere o segundo autor do artigo cujo cdigo 520. b) Recupere o nome do primeiro autor do artigo cujo cdigo 520 4.Recupere o nome dos coordenadores dos grupos que participam das tarefas que iniciaram em 10/03/99. 5. Recupere o nome do coordenador de cada tarefa do projeto de nome Projeto A. 6. Recupere o nome do coordenador do grupo que participa de cada tarefa do projeto de nome "Projeto A", bem como a descrio da respectiva tarefa. Com base no esquema do Cadastro Imobilirio, expresse as consultas a seguir. 7. Recupere a localizao de cada imvel. 8. Recupere o bairro aonde est localizado o imvel de cdigo de inscrio 1000.

46

9. Recupere a composio do bairro aonde est localizado o imvel de cdigo de inscrio 1000. 10. Para cada imvel, selecione a composio do bairro em que ele est situado. 11. Para cada imvel, selecione o cdigo das quadras que compem o bairro em que o imvel est situado. 12. Recupere os imveis cuja rea construida maior que 200 m2. 13. Selecione o 70 segmento de quadra da rua de cdigo X. 14. Formule uma consulta qualquer envolvendo 2 classes ou mais, e expresse-a na linguagem de consulta adotada.

47

5. Sistemas de Gerenciamento de Banco de Dados Orientados a Objetos

Neste captulo resume-se as principais caractersticas dos SGBDs orientados a objetos e apresenta-se alguns SGBDOOs existentes destacando, atravs de uma tabela, quais dessas caractersticas cada um deles possui. 5.1. Caractersticas dos SGBDs Orientados a Objetos Os SGBDOOs so SGBDs baseados nos conceitos de modelos de dados orientados a objetos. Diferentemente dos SGBDs Relacionais que foram desenvolvidos para dar suporte s necessidades das aplicaes comerciais tradicionais, os SGBDs orientados a objetos foram desenvolvidos para satisfazer aos requisitos impostos por aplicaes mais avanadas, ditas no convencionais. Essas aplicaes no convencionais apresentam requisitos e caractersticas tais como: necessidade de estruturas complexas para representar objetos; necessidade de novos tipos de dados para armazenar informaes, tais como imagens, voz e documentos textuais grandes; requisitos de manipulao de dados no bem suportados pelos SGBDs tradicionais. Uma outra caracterstica importante de bancos de dados orientados a objetos a possibilidade, que eles oferecem aos projetistas, de poder especificar a estrutura de objetos complexos e as operaes que podem ser aplicadas a esses objetos. Identificador de Objeto (OID): a implementao de identidade de objeto em sistemas de bdoo envolve 3 tipos de independncia: Independncia de local: a identidade do objeto preservada quando ocorre mudanas de localizao fsica. Independncia de valor: preservao da identidade independente do contedo. Independncia de estrutura: preservao da identidade independente de mudanas em sua estrutura. 48

Vantagens dos OIDs: - facilidade para modelar a estrutura complexa dos objetos; - propicia o compartilhamento de objetos; - propagao de mudanas de valor de um objeto (atravs da referncia) - suporte ao relacionamento entre os objetos - favorece o gerenciamento de verses Atributos e Mtodos Visveis/Invisveis : Alguns sistemas permitem o usurio estabelecer quais atributos e mtodos so visveis (pblicos) na interface do objeto e podem ser invocados por outros objetos. Aqueles que no so visveis so ditos privados. Instncias Excepcionais: O sistema O2 permite a criao de instncias de uma classe com atributos e/ou mtodos adicionais queles especificados para a classe. Objeto Composto: Alguns sistemas (por ex. ORION) permitem aplicaes modelar um conjunto de objetos (ditos objetos componentes) como uma entidade lgica. Isso significa que o sistema pode manipular esse conjunto de objetos como uma unidade para bloqueio, autorizao e clustering fsico. Gerenciamento de Verso: O acesso a estados anteriores ou alternados de objetos uma parte inerente de muitas aplicaes. Como exemplos de aplicaes que exigem acesso evoluo de estados de objetos esto as aplicaes de projeto de engenharia por ex: desenho auxiliado por computador e fabricao auxiliada por computador. Nessas aplicaes, o mesmo objeto passa por muitas alteraes ou transies de estado e desejvel acessar ou investigar estados prvios, ou verses, do objeto. Por exemplo, considere os captulos dessa apostila. Cada captulo sofreu uma evoluo. Para alguns captulos foram mantidas vrias verses, que diferiam em organizao e contedo. Houve captulo em que a verso final foi uma integrao

49

de diversos componentes de verses anteriores. Foi muito til manter-se as verses anteriores e utilizar partes delas nas verses seguintes. O gerenciamento de verses em um banco de dados orientado a objetos consiste em ferramentas e construes que automatizam ou simplificam a construo e a organizao de verses ou configuraes. Sem essas ferramentas, caberia ao usurio organizar e manter as verses. Uma maneira de fazer isso seria utilizar uma conveno de nome que controlasse as vrias verses do mesmo objeto e a relao entre as verses (rvore de derivao).Isso muito trabalhoso e propenso a erro. Assim, em aplicaes de projeto complexas, o gerenciamento de verso um utilitrio til e poderoso. Em aplicaes de engenharia de projeto, os objetos de projeto so normalmente armazenados em um repositrio central (persistente). Os projetistas fazem o check-out do objeto persistente no banco de dados, trabalham nele e, quando acharem que possuem a melhor implementao, fazem o check-in do objeto como uma verso diferente. Depois que um objeto versionado criado, a raiz de um conjunto de verses contm todas as verses preexistentes de objetos. A principal propriedade comum a todas as verses do mesmo objeto a identidade do objeto. Por toda a histria versionada, um objeto pode passar por muitos estados e at por modificaes estruturais. Em suma, a verses servem para registrar os vrios estgios de um projeto, ou para manter vrias alternativas corretas do projeto. Cada alternativa correta pode estar associada a um conjunto de verses, correspondendo aos vrios estgio de desenvolvimento daquela alternativa, para registrar a evoluo do projeto, conforme ilustrado na figura 5.1. Nessa figura tem-se que v2 e v3 so alternativas de v1; v4 e v5 so alternativas de v2. Com exceo da verso inicial e da final, cada verso possui sucessores e predecessores. Algumas linguagens orientadas a objeto que suportam versionamento fornecem construes na linguagem para: o check-out e o check-in deverses do objeto a recuperao de sucessores ou predecessores de verses.

O1: 50

v1: verso original v2 v5 V4 v7: verso final Figura 5.1.- Conjunto de verses de O1 Gerenciamento de Transaes Tradicionalmente, uma transao uma seqncia de aes que l ou grava objetos persistentes e satisfaz as propriedades ACID (atomicidade, consistncia, isolamento e durabilidade). Resumindo, atomicidade significa que a transao ou executada inteiramente ou no executada. Consistncia significa que as transaes mapeiam um banco de dados persistente de um estado coerente para outro. Isolamento significa que as transaes no lem resultados intermedirios de outras transaes no-efetivas. Durabilidade significa que, uma vez que uma transao efetivada, fica garantido que seus efeitos (i.., atualizaes) sero suportados apesar das falhas. Enquanto as transaes em aplicaes mais tradicionais so relativamente curtas, recuperando e/ou atualizando poucos registros do banco de dados, as transaes de aplicaes mais avanadas podem demorar horas e at mesmo dias. Considere, por exemplo, a elaborao de um documento eletrnico em um ambiente de escritrio. Suponha quase trata de um documento que descreve o plano diretor de 5 anos do departamento. Em certo sentido, a transao que cria esse documento e que pode envolver muitos funcionrios se completa quando o documento concludo. O documento passa por muitas fases intermedirias e sua preparao pode levar dias. Esse tipo de transao apresenta alguns desafios e problemas relacionados s estratgias de gerenciamento de transao mais tradicionais.

v3

verses alternativas v6

51

Diversos gerenciadores de banco de dados orientados a objetos oferecem algum suporte para transaes de longa durao. Por exemplo, o Versant e o ITASCA, suportam a noo de transaes de longa e de curta durao. A idia ter transaes curtas aninhadas dentro de transaes demoradas. Quando o usurio inicia uma transao de longa durao, ele pode fazer um check-out do objeto complexo e seus subobjetos, do banco de dados concorrentemente compartilhado e trabalhar nesses objetos em seu banco de dados pessoal. O usurio faz todas as operaes nos objetos e quando elas se completarem ele pode fazer o check in desses objetos. Recuperao: um SGBD recupervel aquele que pode alcanar um estado consistente aps uma falha. Recuperao em SGBDOO mais complexa principalmente devido existncia de transaes de longa durao. Gerenciamento de Dados Multimdia: Um SGBDOO que suporta dados multimdia deve fornecer um sistema de armazenamento e recuperao de dados mais eficiente.

5.2. Vantagens dos SGBDOOs Possuem um poderoso modelo de dados. Permitem representar a semntica do problema do mundo real de forma mais exata do que atravs de um conjunto de tabelas planas. Manipulam objetos complexos. Objetos podem ser reusados em diferentes programas. Herana de relacionamentos entre conjuntos de entidades. Associam comportamento de objetos com definies de objeto ao nvel de esquema. Junes implcitas ao longo de hierarquias de agregaes, baseadas em identidade de objetos. Mecanismos de verses. Melhor gerenciamento de transao e concorrncia. 52

Linguagem de consulta mais expressiva. Melhor suporte para trabalho cooperativo.

5.3. Alguns SGBDOOs Existentes H vrios SGBDOOs em desenvolvimento por fabricantes, laboratrios de pesquisa, universidades. Nos ltimos anos, muitos prottipos experimentais e SGBDOOs comerciais tm se tornado disponveis. As tabelas 5.1 e 5.2 apresentam um resumo das principais caractersticas de alguns SGBDOOs existentes. Esse levantamento foi realizado em 1995. Desde ento houveram mudanas em alguns desses gerenciadores. Por exemplo, o sistema O2, atualmente chamado de Ardent e comercializado pela Ardent Software, permite o uso de C++ e Java para definio de esquemas e desenvolvimento de aplicaes. O sistema ObjectStore permite integrao com a linguagem Java.

53

54

55

6. Padres para SGBDOOs

O sucesso dos sistemas de banco de dados relacionais no resulta apenas de um nvel mais alto de independncia de dados e um modelo de dados mais simples do que os sistemas anteriores. Seu sucesso se deve tambm padronizao que sofreram. A aceitao do padro SQL permite o alto grau de portabilidade e interoperabilidade entre sistemas, simplifica o aprendizado de novos SGBDs relacionais e representa um amplo endosso da abordagem relacional. Portabilidade a capacidade de executar um programa de aplicao particular em diferentes sistemas com modificaes mnimas no programa. Interoperabilidade se refere habilidade de uma aplicao em acessar mltiplos sistemas distintos. Em termos de banco de dados, isso significa que um mesmo programa de aplicao pode acessar alguns dados armazenados segundo um certo SGBD e outros dados armazenados por um outro SGBD. Esses fatores so importantes tambm para SGBDs orientados a objetos. Na indstria de software h vrios grupos trabalhando sobre padres que afetam os SGBDOOs: o ODMG - Object Database Management Group (padres gerais para SGBDOOs), o OMG - Object Management Group (padro CORBA Commom Object Request Broker Architecture, que permite que uma ampla variedade de objetos interaja em um ambiente distribudo), ANSI X3H2 (SQL padro), ANSI X3J16 (C++ padro), ANSI X3J20 (Smalltalk padro). Esses padres visam a portabilidade de cdigo em alguma maneira. Com relao a SGBD orientados a objetos, h trs padres: SQL-92, ODMG93 e SQL3. Os dois principais grupos que trabalham sobre padres para SGBD so o ODMG e o ANSI X3H2.

6.1. SQL3 ANSI X3H2 um comit tcnico do American National Standards Institute (ANSI), formado em 1978, para a definio de uma linguagem para bancos de dados CODASYL ou redes. Em 1982, o modelo relacional estava adquirindo importncia, o que levou o comit X3H2 a ser solicitado para desenvolver o padro SQL. A verso corrente da SQL a SQL-92, que a culminao de trabalhos sobre vrias verses anteriores. Ela baseada na SQL-89, que por sua vez foi baseada na SQL-86. 56

SQL-92 o padro para SGBDs Relacionais. SQL-92 no introduz conceitos de objetos. O comit reconheceu a importncia de adio de objetos sua especificao e tem trabalhado visando a definio da SQL3, que estende a SQL-92 para suportar objetos. SQL3 mantm a compatibilidade com a SQL-92 (e verses anteriores do padro), o que interfere na forma de seu suporte a objetos. Estes, no modelo de objetos da SQL3, so armazenados em tipos especiais de colunas em relaes particulares. Assim, objetos no so considerados primeira classe porque eles no podem existir separadamente das relaes, o que afeta operaes tais como consultas. No possvel acessar um objeto diretamente em SQL3; necessrio faz-lo atravs da relao. Esse passo extra, de acesso a relao para poder recuperar o objeto, pode afetar o desempenho da aplicao, conforme avaliado em (Barry 1996). SQL3 difere do resto dos padres industriais de objeto. um sistema fechado, definido somente em funo de suas antecessoras. Ela no usa nenhum dos padres do OMG ou da comunidade de programao de objeto.

6.2. ODMG-93 ODMG (Object Database Management Group) um consrcio de vendedores e grupos de interesse que trabalham na criao de padres para SGBDOOs. Ele foi concebido em 1991 e a verso 1.0 da especificao do padro ODMG-93 (tambm chamado ODMG 1.0) foi publicada em agosto de1993. Em 1995 o grupo terminou a verso 1.2 do padro ODMG-93 e posteriormente foi revisado e chamado ODMG 2.0. A linguagem de consulta a Objeto (OQL) do ODMG-93 baseada na poro de consulta da SQL-92, porm com algumas variaes, pois a SQL-92 assume um modelo relacional e a OQL assume um modelo de objeto. A meta do ODMG tornar disponvel um conjunto de padres permitindo que um cliente de SGBDOO escreva aplicaes portveis, isto , aplicaes que possam ser executadas por diferentes SGBDOOs. Assim, os esquemas de dados, ligaes com linguagens de programao; manipulao de dados e linguagens de consulta devem ser portveis. Segundo Cattell, em (Cattell 1996), as companhias que so membro do ODMG (Cattell um dos membros do grupo), representando quase toda a indstria de SGBDOO, esto suportando esse padro. A meta no a produo de SGBDOOs 57

idnticos, e sim, portabilidade de cdigo fonte. Haver diferenas entre produtos relativas a desempenho, linguagens suportadas, funcionalidade nica para segmentos particulares do mercado, ferramentas de construo de aplicaes, construtores de interfaces de usurio grficas (GUI), entre outros. O trabalho de padronizao, principalmente, correntemente disponveis. O grupo define um SGBDOO como sendo um SGBD que integra capacidades de banco de dados com capacidades de linguagem de programao orientada a objetos. Um SGBDOO faz com que objetos do banco de dados apresentem-se como objetos de linguagem de programao, em uma ou mais linguagens existentes. Os SGBDOOs tm sido integrados com C++, C, Smalltalk e LISP. Os principais componentes do OGMG-93 so: um Modelo de Objetos uma Linguagem de Definio de Objetos (ODL) uma Linguagem de Consulta a Objetos (OQL) declarativa (no procedural) para consultar e atualizar objetos do banco de dados. Foi usado o padro SQL como base, porm OQL suporta capacidades mais poderosas. O grupo espera que SQL3 ir convergir com a OQL futuramente. Ligao com a linguagem C++. Isso inclui uma verso da ODL que usa a sintaxe de C++, um mecanismo para invocar OQL e procedimentos para operaes sobre banco de dados e transaes. Ligao com a linguagem Smalltalk e Java, com mesmos suportes acima para C++. Vrias das idias embutidas no modelo de objetos ODMG so baseadas em duas dcadas de pesquisa em modelagem conceitual e bancos de dados orientados a objetos realizadas por muitos pesquisadores. Vrias companhias passaram a suportar esse padro em seus produtos a partir final de1995. apresentado pelo grupo, derivado, pela combinao das caractersticas mais fortes dos SGBDOOs

7. Bibliografia
58

Barry, D.K. The Object Database Handbook. John Wiley & Sons, Inc. 1996. Bertino, E.; Martino, L. (1993). Object-Oriented Database Systems: Concepts and Architectures. Addison-Wesley, 1993. Blaha, M.; Premerli, W. Object-Oriented Modeling and Design for Database Applications. Prentice-Hall, 1998. Cattel, R.G.G. Object-Oriented and Extended Relational Database Systems. Addison-Wesley, 1994. Cattell, R.G.G.; Barry, D.K. The Object Database Standard: ODMG-3.0. Morgan Kaufmann Publishers, inc., 2000. Elmasri, R.A.; Navathe, S.B. . Fundamentals of Database Systems. AddisonWesley, 2000 (third edition). Hughes, J.G. Object-Oriented Databases. Prentice-Hall, 1991. Khoshafian, S. Banco de Dados Orientado a Objeto. Livraria e Editora Infobook S.A., 1994. Vieira, M.T.P. (1991) Um modelo de Objetos para um Sistema de Gerncia de Objetos em Ambiente de Desenvolvimento de Sistemas Interativos. Tese de Doutorado, Departamento de Informtica, PUC-RJ, 1991. Zand, M.; Collins, V.; Caviness, D. A Survey of Current Object-Oriented Databases. In: DATA BASE Advances in Information Systems, Vol.26, No. 1, February, 1995.

59