Sousa Mestrado

Emulao de um Gerenciador de Dados Orientado a
Objetos atravs de uma Interface de Programao de

Aplicativos sobre um Gerenciador Relacional1
Elaine Parros Machado de Sousa
Orientao:
Prof. Dr. Caetano Traina Jnior
Dissertao apresentada ao Instituto de Cincias Matemticas e de Computao

da Universidade de So Paulo como parte dos requisitos para a obteno do ttulo
de Mestre em Cincias - rea de Cincias de Computao e Matemtica
Computacional.
ICMC - USP, So Carlos

Novembro de 2000
Trabalho realizado com auxlio da FAPESP
Ao Humberto e
aos meus pais
com muito amor
ii
Agradecimentos
Ao Prof. Dr. Caetano Traina Jr., meu orientador e amigo, pelo precioso trabalho de
orientao, estmulo e confiana.
Ao Prof. Dr. Mauro Biajiz e ao Prof. Dr. Carlos Valncio, pela colaborao no
embasamento terico deste trabalho.
Prof. Dra. Maria Cristina Ferreira e Prof. Dra. Rosely Sanches, que prontamente me
auxiliaram como orientadora e co-orientadora acadmica, respectivamente.
s funcionrias Beth, Laura, Marlia, Adriana e Sandrinha, pelo atendimento atencioso na
secretaria da ps-graduao e na seo de bolsas.
FAPESP, pelo apoio financeiro que viabilizou o desenvolvimento deste trabalho.
Prof. Dra. Agma Traina, por todo o incentivo e o carinho demonstrados.
Aos amigos do Grupo de Bases de Dados e Imagens do ICMC, por toda a ajuda prestada
no decorrer do trabalho.
Ao meu marido Humberto, por estar sempre perto e pronto a me apoiar profissionalmente e
pessoalmente.
Aos meus pais, Celso e Maria Helena, pelo incentivo, apoio e confiana que sempre
dedicaram durante toda minha vida.
Aos amigos, que direta ou indiretamente, contriburam para a realizao deste trabalho.
iii
Resumo
Este trabalho mostra o desenvolvimento de uma Interface de Programao de Aplicativos
(Application Program Interface API) para um gerenciador de dados orientado a objetos.
A API composta por um conjunto de primitivas que integram a definio e a
manipulao de objetos em uma representao compatvel com uma linguagem de
programao orientada a objetos.
A definio da API explora os recursos bsicos de modelos de dados orientados a objetos e
baseia-se nas extenses de um metamodelo baseado em quatro abstraes: classificao,
generalizao, agregao e composio. O suporte abstrao de classificao com
hierarquias em mltiplos nveis tratado com especial destaque, pois resulta em uma das
caractersticas predominantes da API: o tratamento homogneo de tipos e instncias em
tempo de execuo, unificando comandos usualmente separados em DDL (Data Definition
Language) e DML (Data Manipulation Language).
A implementao da API sobre um gerenciador relacional emula um gerenciador de dados
orientado a objetos. Os conceitos envolvidos no trabalho de emulao foram aplicados no
desenvolvimento de uma verso com ncleo relacional do Gerenciador de Objetos SIRIUS,
criando em ambiente experimental, precursor verso com ncleo nativo desse
gerenciador. A API definida neste trabalho compatvel com ambas as verses do
Gerenciador SIRIUS, permitindo que uma aplicao utilize qualquer uma das verses sem
alteraes em seu cdigo fonte.
Para exemplificar a utilizao prtica da API, foi implementado um utilitrio de bases de
dados destinado representao de modelagens baseadas no modelo de dados SIRIUS
usando a verso relacional do Gerenciador de Objetos SIRIUS. Esse utilitrio, alm de
demonstrar a utilizao da API, demonstra tambm como as operaes tpicas da DDL e da
DML so integradas em um nico conjunto de comandos que no faz diferena entre a
definio de tipos e de instncias.
iv
Abstract
This work develops an Application Program Interface (API) for an object oriented data
manager. The API is composed by a set of methods that includes object definition and
manipulation appropriated for an object oriented programming language.
The API definition explores basic resources of object oriented data models. It is based on
extensions of a meta-model based on four abstractions: classification, generalization,
aggregation and composition. One of the API predominant characteristics is the support to
the classification abstraction. It is used a multiple-level classification hierarchy, enabling a
seamless treatment of types and instances, unifying the commands usually divided in the
DDL and DML parts of the query language.
The API was constructed employing a relational manager, aiming to emulate an object
oriented data manager. The target data model was based on the SIRIUS model, creating a
relational version of the SIRIUS Object Manager. Thus, this relational version is an
experimental environment, aiding the development of the full native version of that
manager. The API defined in this work is compatible with both versions of the SIRIUS
Manager, allowing applications to use any version without modifications in their codes.
In this work, the API usage is exemplified with the development of a database tool
designed to represent target modeling based on SIRIUS data model, using the relational
version of the SIRIUS Object Manager. This utility also shows how the DDL and DML
parts of the query language are unified in a unique, seamless command set, in which there
is no distinction between types and instances.
Sumrio
Lista de Figuras
Lista de Tabelas
Siglas e Abreviaes
1
INTRODUO............................................................................................................. 1
1.1
1.2
1.3
CONSIDERAES INICIAIS ......................................................................................... 1

OBJETIVOS DO TRABALHO ........................................................................................ 2
ORGANIZAO DO TRABALHO .................................................................................. 3
CONCEITOS DE SGBDOOS E PADRES.............................................................. 5

2.1 INTRODUO............................................................................................................. 5
2.2 CARACTERSTICAS DE SGBDOOS ............................................................................ 5
2.3 ARQUITETURA ........................................................................................................... 8
2.4 API ........................................................................................................................... 9
2.5 LINGUAGEM DE CONSULTA ..................................................................................... 13
2.6 PADRES PARA GERENCIAMENTO DE DADOS ORIENTADOS A OBJETOS .................. 14
2.6.1 ODMG ............................................................................................................. 15
2.6.2 SQL3 ................................................................................................................ 20
2.7 CONSIDERAES FINAIS.......................................................................................... 25
SISTEMAS ORIENTADOS A OBJETOS ............................................................... 26

3.1 INTRODUO........................................................................................................... 26
3.2 SISTEMA O2 ............................................................................................................ 26
3.2.1 Arquitetura do Sistema .................................................................................... 27
3.2.2 Modelo de Dados e Linguagem O2C .............................................................. 28
3.2.3 Linguagem de Consulta................................................................................... 29
3.2.4 Interfaces para Linguagens de Programao ................................................. 30
3.3 SISTEMA JASMINE ................................................................................................... 31
3.3.1 Arquitetura do Sistema .................................................................................... 32
3.3.2 Modelo de Dados............................................................................................. 33
3.3.3 Linguagem de Base de Dados ......................................................................... 35
3.4 OUTROS SISTEMAS .................................................................................................. 36
MODELO DE DADOS SIRIUS ................................................................................ 39

4.1 INTRODUO........................................................................................................... 39
4.2 CONCEITOS DO MODELO SIRIUS............................................................................ 40
4.2.1 Abstrao de Agregao ................................................................................. 40
4.2.2 Abstrao de Composio ............................................................................... 42
4.2.3 Abstrao de Generalizao ........................................................................... 44
4.3 ABSTRAO DE CLASSIFICAO ............................................................................. 45
vi
API DO GERENCIADOR SIRIUS........................................................................... 50

5.1 INTRODUO........................................................................................................... 50
5.2 GERENCIADOR DE OBJETOS SIRIUS ....................................................................... 51
5.3 API SIRIUS............................................................................................................ 54
5.3.1 Definio da API ............................................................................................. 54
5.3.2 Implementao da API .................................................................................... 67
EDITOR DE ESQUEMAS SIRIUS .......................................................................... 72

6.1
6.2
6.3
6.4
INTRODUO........................................................................................................... 72
DESCRIO DO E2SIRIUS ......................................................................................... 72
UTILIZAO DA API NO E2SIRIUS ........................................................................... 74
CONSIDERAES FINAIS.......................................................................................... 78
CONCLUSO ............................................................................................................. 79
7.1
7.2
7.3
CONSIDERAES INICIAIS ....................................................................................... 79

CONTRIBUIES APRESENTADAS ............................................................................ 81
SUGESTES PARA TRABALHOS FUTUROS ................................................................ 82
Referncias Bibliogrficas
Anexo: API do Gerenciador SIRIUS
vii
Lista de Figuras
FIGURA 1 - UTILIZAO DE UM SGBDOO........................................................................... 15

FIGURA 2 - ESTRUTURA FUNCIONAL DO SISTEMA O2 .......................................................... 27
FIGURA 3 - ARQUITETURA DO O2 ENGINE ........................................................................... 28
FIGURA 4 - ARQUITETURA DO SISTEMA JASMINE ................................................................. 32
FIGURA 5 - ABSTRAES DO MODELO SIRIUS .................................................................... 39
FIGURA 6 - ELEMENTOS DE UMA ABSTRAO ...................................................................... 40
FIGURA 7 EXEMPLO DA ABSTRAO DE AGREGAO ...................................................... 42
FIGURA 8 - EXEMPLO DA ABSTRAO DE COMPOSIO ...................................................... 43
FIGURA 9 - EXEMPLO DA ABSTRAO DE GENERALIZAO ................................................ 44
FIGURA 10 - EXEMPLO DA ABSTRAO DE CLASSIFICAO ................................................ 46
FIGURA 11 EXEMPLO DE ATRIBUTO EXTRA NA HIERARQUIA DE CLASSIFICAO ............... 48
FIGURA 12 - SISTEMA SIRIUS ............................................................................................. 50
FIGURA 13 - GERENCIADOR SIRIUS COM NCLEO NATIVO ................................................. 52
FIGURA 14 - GERENCIADOR SIRIUS COM NCLEO RELACIONAL ......................................... 53
FIGURA 15 - EXEMPLO DE MODELAGEM SIRIUS................................................................. 59
FIGURA 16 - ESTRUTURA DE IMPLEMENTAO DA API........................................................ 67
FIGURA 17 - ESTRUTURA DO SOBRESTANTE OBJETO............................................................. 68
FIGURA 18 - FORMULRIO OBJECT DO E2SIRIUS ................................................................ 73
2
SIRIUS ORIGINAL .................................................................... 76
SIRIUS REFORMULADO ........................................................... 77
FIGURA 19 - CDIGO
NO E
FIGURA 20 - CDIGO
NO E
viii
Lista de Tabelas
TABELA 1 - COMPARAO ENTRE APIS DE SGBDOO ......................................................... 12

TABELA 2 - CARACTERSTICAS DE ATRIBUTOS .................................................................... 41
TABELA 3 - CORRESPONDNCIA ENTRE ELEMENTO SINTTICO E CLASSE DA API ............... 54
TABELA 4 - CORRESPONDNCIA ENTRE CARACTERSTICA DE ATRIBUTO E CLASSE DA API. 55
TABELA 5 - CORRESPONDNCIA ENTRE CONJUNTO RECUPERADO E CLASSE DA API........... 55
TABELA 6 - COMPOSIO DOS MDULOS SEMNTICOS ....................................................... 56
TABELA 7 - CARACTERSTICAS DE API NO GERENCIADOR SIRIUS ..................................... 66
ix
Siglas e Abreviaes
API
Application Program Interface
CAD
Computer-Aided Design
CAM
Computer-Aided Manufacturing
CASE
Computer-Aided Software Engineering
CIM
Computer Integrated Manufacturing
DDL
Data Definition Language
DHC
Diagrama Hierrquico de Colnias
DML
Data Manipulation Language
DRI
Diagrama de Representao de Instncias
ODBC
Open Database Connectivity
ODL
Object Definition Language
ODMG
Object Database Management Group
OId
Object Identifier
OIF
Object Interchange Format
OML
Object Manipulation Language
OQL
Object Query Language
SGBD
Sistema de Gerenciamento de Base de Dados
SGBDOO
Sistema de Gerenciamento de Base de Dados Orientado a Objetos
TAD
Tipo Abstrato de Dado
1 Introduo
1 Introduo
1.1 Consideraes Iniciais

Sistemas de Gerenciamento de Bases de Dados Orientados a Objetos (SGBDOOs)
surgiram da necessidade de atender exigncias de aplicaes no convencionais, voltadas
predominantemente para problemas tcnicos e cientficos [Cattell_94]. Ao contrrio das
aplicaes tradicionais, voltadas para ambientes de negcio, as aplicaes no
convencionais possuem caractersticas particulares, como por exemplo, estruturas de dados
heterogneas e complexas, que no so eficientemente suportadas por Sistemas de
Gerenciamento de Bases de Dados (SGBDs) relacionais [Elmasri_00]. Por outro lado, a
flexibilidade inerente abordagem de orientao a objetos, integrando modelos de dados,
bases de dados e linguagens de programao, oferece o suporte necessrio para projeto e
desenvolvimento de tais aplicaes.
As aplicaes em questo abrangem o desenvolvimento de ambientes de projeto voltados
para engenharia (CASE1, CAD2, CAM3 e CIM4), sistemas de apoio medicina, aplicaes
cientficas, sistemas baseados em conhecimento, automao de escritrio e sistemas que
manipulam imagens mdicas, informaes geogrficas, partituras musicais e informaes
multimdia em geral. Com o advento dessa nova abordagem, pesquisas envolvendo
desenvolvimento e formalizao de modelos de objetos [Bertino_91], implementao de
gerenciadores de objetos [Cattell_94], projeto de linguagens de consulta a objetos
[Bertino_92] e algoritmos de suporte a conceitos orientados a objetos fornecem os
subsdios para a construo de SGBDOOs. Neste contexto, foram desenvolvidos vrios
SGBDOOs [Cattell_94] [Zand_95], incluindo sistemas comerciais e prottipos
1
Computer-Aided Software Engineering

Computer-Aided Design
3
Computer-Aided Manufacturing
4
Computer-Integrated Manufacturing
2
1 Introduo
experimentais. Alm disso, alguns padres [Cattell_94] [Cattell_95] [Cattell_97]

[Eisenberg_98], combinando modelos de dados e linguagens de base de dados, foram
criados com o objetivo de permitir melhor produtividade dos programadores,
representaes mais completas e principalmente portabilidade de aplicaes no
convencionais.
A API do SGBDOO um mecanismo de comunicao entre a aplicao e a base de dados.
O ODBC (Open Database Connectivity) [ODBC_00a] [ODBC_00b], por exemplo, uma
API padro de acesso a bases de dados relacionais compatvel com diferentes SGBDs,
como Oracle, Sybase, InterBase, Access, Fox, entre outros.
Na maior parte dos sistemas de bases de dados tradicionais, as APIs so especificadas
atravs da insero de linguagens de manipulao de dados (DML) em linguagens de
programao convencionais. Esta abordagem, no entanto, exige dos programadores a
utilizao de duas ou mais linguagens (ou modelos de dados) nas fases de projeto e
implementao das aplicaes [Perez_91]. Em SGBDOOs, a integrao transparente entre
base de dados e linguagem de programao orientada a objetos permite que o programador
utilize apenas uma linguagem, ou modelo de dados, no processo de desenvolvimento da
aplicao. Para tanto, a API de um SGBDOO composta por rotinas compatveis com a
linguagem de programao utilizada.
Em geral, a API de um SGBDOO deve permitir a definio de tipos e classes e a
manipulao de objetos, ou instncias, das classes e tipos definidos. Alm disso,
fundamental que a API suporte consultas a objetos armazenados da base de dados,
abrangendo consultas efetuadas no contexto da aplicao e consultas independentes
[Perez_91].
1.2 Objetivos do Trabalho

Este trabalho tem como objetivo emular um gerenciador de dados orientado a objetos
atravs da definio e implementao de uma API sobre um gerenciador relacional.
O processo de definio da API foi baseado nos conceitos de um modelo de dados
semanticamente mais rico do que atualmente pode ser considerado como um modelo de
2
1 Introduo
dados orientado a objetos padro, incluindo um maior conjunto de abstraes do que o

considerado bsico. Em particular, os modelos de dados orientados a objetos padres
consideram a existncia de duas Abstraes de Dados principais: Generalizao e
Agregao (e suas respectivas abstraes inversas). Neste trabalho, foram consideradas
tambm as Abstraes de Classificao e de Composio, procurando explorar
principalmente o suporte hierarquia de classificao em mltiplos nveis e a conseqente
unificao entre os comandos de manipulao de dados (DML) e os comandos de
definio de dados (DDL) das linguagens de acesso a bases de dados.
A implementao da API sobre um gerenciador relacional emula um gerenciador de dados
orientado a objetos baseado nos conceitos inerentes s abstraes de agregao,
generalizao, classificao e composio. Portanto, alm do suporte necessrio a
operaes de definio e manipulao de dados, a API desenvolvida disponibiliza um
conjunto de primitivas para o tratamento de particularidades dessas abstraes, destacandose o tratamento homogneo a tipos e instncias em tempo de execuo, fundamental para
abstrao de classificao.
1.3 Organizao do Trabalho

O Captulo 2 apresenta uma reviso bibliogrfica abrangendo os principais conceitos dos
SGBDOOs, dentre os quais esto os recursos bsicos presentes em sistemas de bases de
dados, as diferentes abordagens para arquitetura, as principais caractersticas da API de um
gerenciador, aspectos de linguagens de consulta, e padres como o ODMG e o SQL3,
difundidos como mecanismos de aceitao e utilizao da tecnologia de bases de dados
orientadas a objetos.
O Captulo 3 descreve alguns sistemas de bases de dados orientados a objetos, destacando
as principais caractersticas do modelo de dados, arquitetura e linguagem de consulta de
cada um. Sistemas como o O2 e o Jasmine oferecem suporte ao desenvolvimento de
aplicaes no convencionais, e assim como tantos outros, comerciais ou experimentais,
vm contribuindo para o desenvolvimento de tecnologia para a resoluo de problemas em
diferentes reas de conhecimento, tais como engenharia e medicina.
1 Introduo
O Captulo 4 apresenta o Modelo de Dados SIRIUS, descrevendo seus principais conceitos

e o tratamento dado s abstraes de classificao, generalizao, agregao e composio.
A abordagem diferencial da abstrao de classificao no modelo SIRIUS apresentada
com mais detalhes, enfatizando a hierarquia de tipos em mltiplos nveis suportada nesse
modelo.
O Captulo 5 dedicado a descrever o trabalho desenvolvido. As principais caractersticas
de definio e implementao da API so descritas com o objetivo de mostrar como as
abstraes de agregao, composio e classificao so suportadas na API e emuladas
num gerenciador relacional.
O Captulo 6 tem por objetivo validar a API, mostrando a sua utilizao no
desenvolvimento de um utilitrio de bases de dados genrico centrado num gerenciador de
dados orientado a objetos emulado. Os resultados obtidos com o prottipo do utilitrio so
satisfatrios, validando a API desenvolvida como uma interface consistente para um
gerenciador de objetos.
O Captulo 7 conclui o trabalho, apresentando suas principais contribuies e propostas
para trabalhos futuros.
Em seqncia, esto as referncias bibliogrficas e um Anexo contendo a descrio das
classes da API, detalhando a funcionalidade e a interface de cada mtodo.
2 Conceitos de SGBDOOs e Padres
2 Conceitos de SGBDOOs
e Padres
2.1 Introduo
Sistemas de Gerenciamento de Bases de Dados Orientados a Objetos so genericamente
definidos como SGBDs que integram a funcionalidade dos gerenciadores de bases de
dados e a funcionalidade das linguagens de programao orientadas a objetos. Em um
SGBDOO os objetos da base de dados so tratados como objetos da linguagem de
programao.
SGBDOOs possuem caractersticas que abrangem princpios inerentes a sistemas de bases
de dados e princpios do paradigma de orientao a objetos. Algumas caractersticas
podem ou no estar presentes num SGBDOO, dependendo da abordagem adotada para o
mesmo. Analogamente, o modelo de dados, a API, a linguagem de programao e a
linguagem de consulta podem apresentar particularidades compatveis com as prioridades
do SGBDOO do qual fazem parte.
As sees seguintes apresentam uma viso geral das principais caractersticas dos
SGBDOOs, algumas abordagens para a arquitetura destes sistemas, caractersticas
importantes da API e da linguagem de consulta, e padres para a construo de aplicaes
apoiadas em SGBDOOs, destacando os padres ODMG e o SQL3.
2.2 Caractersticas de SGBDOOs

Como citado anteriormente, os SGBDOOs incorporam recursos de sistemas de bases de
dados, como persistncia, gerenciamento de armazenamento secundrio, controle de
concorrncia, recuperao de falhas e mecanismo de consulta, e recursos do paradigma de
orientao a objetos, como objetos complexos, identidade de objetos, encapsulamento,
tipos ou classes, herana, sobrecarga (polimorfismo), binding atrasado (late binding),

extensibilidade e completude computacional [Atkinson_94] [Cattell_94] [Elmasri_00]
[Nierstrasz_89]. Essas caractersticas so discutidas brevemente nos itens a seguir.
Persistncia - os dados (objetos) de um processo (ou transao) persistem aps o

trmino da execuo do mesmo. Persistncia um requisito evidente para bases de
dados, mas no para linguagens de programao, cujos objetos no "sobrevivem"
execuo do processo, ou seja, so transientes. Persistncia deve ser ortogonal, isto ,
permitir que qualquer objeto, independente de seu tipo, torne-se persistente.
Gerenciamento de armazenamento secundrio - caracterstica clssica de SGBDs

que prov independncia entre o sistema lgico e o sistema fsico. usualmente
suportada atravs de mecanismos como gerenciamento de ndices, buffering de dados,
seleo de caminhos de acesso, alocao de espao em disco, transferncia de dados
para a memria principal, otimizao de consulta, entre outros. Tais mecanismos,
embora crticos para a performance do sistema, so transparentes ao programador.
Controle de concorrncia - gerenciamento de mltiplos usurios interagindo

simultaneamente com o sistema.
Recuperao de falhas - capacidade de, em caso de falhas de software ou hardware,

retornar o sistema e seus dados a um estado anterior consistente.
Mecanismo de consulta - realizao de consultas base de dados. Uma consulta dever

ser especificada atravs de uma expresso de alto nvel, alm de ser eficiente em
termos de tempo de resposta e independente da aplicao.
Objetos complexos - suporte a objetos grandes em tamanho (objetos complexos

no-estruturados) e a objetos estruturados, como conjuntos, listas, tuplas e vetores.
Conseqentemente, torna-se necessrio o suporte s operaes que manipulam estes
objetos.
Identidade de objetos - cada objeto da base de dados deve possuir um identificador

nico e imutvel (OId - Object Identifier), gerado automaticamente pelo sistema. Um
OId deve ser utilizado apenas uma vez, o que significa que mesmo que o objeto seja
removido da base de dados, aquele OId no deve ser novamente associado a nenhum
outro objeto.
Encapsulamento - um objeto da base de dados encapsula dados que definem sua

estrutura interna e operaes que definem seu comportamento. A estrutura interna e a
definio do comportamento de um objeto ficam escondidas, e o objeto acessado
atravs das operaes pr-definidas para seu tipo.
Tipos, classes e herana - suporte a hierarquias de tipos ou hierarquias de classes

atravs do conceito de herana, o que permite que novos tipos (classes) sejam definidos
a partir de tipos (classes) pr-definidos. Os subtipos (subclasses) herdam os atributos e
as rotinas dos supertipos (superclasses), podendo no entanto possuir atributos e rotinas
prprios.
Sobrecarga (polimorfismo) - permite que um mesmo nome de operao seja utilizado

para implementaes diferentes, dependendo do tipo de objeto ao qual a operao
aplicada.
Binding atrasado ou dinmico - realiza a traduo de nomes das operaes em

endereos de programas em tempo de execuo. O binding realizado em tempo de
compilao, ao contrrio, chamado de binding esttico (static binding). O binding
atrasado, embora seja lento e dificulte a checagem de tipos, necessrio para viabilizar
a utilizao de sobrecarga de operaes. O grau de checagem de tipos em tempo de
compilao depende do sistema, mas quanto maior este grau, menor a quantidade de
potenciais erros de tipo em tempo de execuo.
Extensibilidade - o conjunto de tipos pr-definidos do sistema deve ser extensvel,

permitindo que o programador defina novos tipos. Embora o tratamento de tipos
definidos pelo usurio seja diferente do tratamento de tipos do sistema, esta diferena
deve ser imperceptvel para o programador e para a aplicao.
Completude computacional - um SGBD computacionalmente completo possui uma

linguagem de acesso base de dados que pode realizar as mesmas operaes realizadas
por uma linguagem de programao. Esta caracterstica pode ser alcanada atravs de
uma conexo coerente entre o sistema de base de dados e uma linguagem de
programao. Um sistema computacionalmente completo tambm possui recursos para
7
desfazer tudo o que for construdo, ou seja, pode levar o sistema passo a passo para
qualquer estado anterior que j tenha existido, a partir de qualquer estado atual.
Alm dos princpios discutidos nos itens anteriores, algumas caractersticas adicionais
podem aumentar a funcionalidade de um SGBDOO, como suporte a verses, distribuio e
transaes planejadas (transaes longas e transaes aninhadas).
2.3 Arquitetura
Os SGBDOOs, de um modo geral, so construdos com base em trs abordagens principais
[Cattell_94]:
Sistemas baseados em linguagens de programao orientadas a objetos - integram

linguagens de programao orientadas a objetos e a tecnologia de bases de dados. As
aplicaes so desenvolvidas em uma extenso de uma linguagem de programao
existente. A linguagem e sua respectiva implementao (pr-processador, compilador e
ambiente de execuo) so estendidos para incorporar a funcionalidade e as
caractersticas das linguagens de bases de dados. Dentre os sistemas que adotam essa
abordagem esto O2 [Bancilhon_92] [Deux_90] [Deux_91], ObjectStore [Lamb_91],
GemStone [Butterworth_91] e Objectivity/DB [Cattell_94].
Sistemas relacionais estendidos - possuem modelo de dados relacional e linguagem

de consulta estendidos, de forma a incorporar os conceitos do paradigma de orientao
a objetos e a funcionalidade das linguagens de programao. Sistemas que adotam essa
abordagem utilizam uma base de dados relacional como repositrio de dados. O
sistema POSTGRES [Stonebraker_91], que utiliza o gerenciador relacional INGRES
para armazenamento de dados, provavelmente um dos mais poderosos sistemas
relacionais estendidos [Cattell_94].
Sistemas baseados em modelos de dados orientados a objetos - baseados em

modelos de dados originalmente orientados a objetos. Os sistemas que seguem essa
abordagem so construdos a partir dos princpios do modelo de dados, de modo a
suportar os conceitos formalizados no modelo. So exemplos os sistemas IRIS
[Fishman_89] [Wilkinson_90] e SIRIUS [Araujo_98a] [Biajiz_96a] [Biajiz_96b].
2.4 API
As caractersticas da API de um SGBDOO [Perez_91] podem ser classificadas em
caractersticas relevantes para o sistema de base de dados e caractersticas relevantes para
os objetos individuais manipulados pela aplicao e gerenciados pelo sistema de base de
dados. Embora as APIs possam diferir de um SGBDOO para outro, algumas caractersticas
consideradas fundamentais so apresentadas nos itens seguintes.
Interface do sistema de base de dados - a API de um SGBDOO deve incorporar
interfaces que permitam que o programa da aplicao defina os limites entre a base de
dados e a execuo das transaes.
Shutdown e Startup do sistema - uma aplicao deve indicar ao SGBDOO que

pretende iniciar ou finalizar uma interao com o sistema, de forma que este possa
realizar as aes necessrias para, respectivamente, atender s requisies da
aplicao, ou terminar a conexo de maneira apropriada e eficiente. A API deve
oferecer suporte para o shutdown e o startup. Entretanto, o modo de execuo
destas aes, explicitamente pela aplicao ou implicitamente atravs da semntica
da linguagem de programao, uma deciso de projeto. Vale enfatizar que a
execuo implcita reduz o nmero de aes codificas explicitamente, o que pode
contribuir para uma maior produtividade do programador da aplicao.
Incio e fim de transaes - interaes envolvendo definies de classes e de

objetos podem alterar o estado do sistema e portanto devem ser inseridas no
contexto de uma transao, garantindo a consistncia da base de dados em caso de
eventuais falhas durante a transao. Sendo assim, a API do sistema deve permitir a
indicao do incio de uma transao, possibilitando que o sistema seja preparado
para as operaes de manipulao de objetos. Analogamente, aps o trmino das
operaes envolvendo a base de dados, a aplicao deve efetivar (commit) o
trabalho realizado, salvar os objetos persistentes e atualizar o estado da base; ou
abortar o trabalho, sem alterar o estado da base de dados. Alm disso, a aplicao
deve indicar o trmino da transao para que o sistema execute as aes
apropriadas e mantenha a base de dados num estado consistente. As especificaes
de projeto determinam se as operaes de inicializao e finalizao de transao
so executadas diretamente atravs da API ou atravs de construtores da linguagem

de programao que implicitamente utilizam as interfaces apropriadas.
Interface de objetos individuais - a API de um sistema de base de dados deve
incorporar interfaces para a criao, recuperao e manipulao de objetos persistentes,
bem como para a manipulao dos estados dos objetos na base.
Alocao e desalocao de objetos - o programador da aplicao deve dispor de

recursos para alocar e desalocar objetos, persistentes ou transientes, quando
necessrio1. Para tanto, a linguagem de programao pode possuir construtores
diferentes para objetos persistentes e objetos transientes, ou utilizar o mesmo
construtor para ambos (ortogonalidade de persistncia), o que mais eficiente em
termos de produtividade do programador.
Atribuio e comparao de referncias para objetos persistentes - a API deve

permitir a atribuio de uma referncia a um objeto persistente, bem como a
atribuio de uma referncia a outra, e a comparao entre valores de duas
referncias. De maneira anloga alocao de objetos, a ortogonalidade de
persistncia para essas operaes depende do projeto dos construtores da linguagem
de programao.
Indicao de persistncia de objetos - numa aplicao, os objetos potencialmente

persistentes alocados em uma transao podem tornar-se persistentes atravs da
indicao de persistncia, que deve ser feita antes do trmino da transao em
questo. A API deve fornecer interfaces para esta operao, que pode ser ativada
implicitamente quando da alocao de um objeto ou explicitamente antes do
trmino da transao. Ambas as opes so decises de projeto.
Indicao de modificao para objetos persistentes - quando uma transao

finalizada com xito, o sistema deve ser informado, atravs da API, de todos os
objetos lidos da base para a memria e modificados durante uma transao, pois
estes objetos devem ser atualizados na base de dados.
Nas consideraes a respeito da API, o termo persistente utilizado para objetos persistentes e para objetos
potencialmente persistentes (objetos transientes que podem tornar-se persistentes); o termo transiente
utilizado para objetos completamente transientes (objetos transientes que nunca se tornaro persistentes)
10
Recuperao de objetos persistentes - a API deve possibilitar a recuperao de

objetos armazenados na base de dados, trazendo-os para o espao de trabalho da
aplicao. Os objetos podem ser recuperados implcita ou explicitamente atravs da
API do SGBDOO, dependendo das decises de projeto do sistema. Quando a
aplicao avalia o valor de uma referncia para obter o endereo de um objeto
persistente, necessrio verificar se o objeto est ou no em memria, pois se no
estiver, este deve ser recuperado da base de dados. Esta verificao pode ser feita
implicitamente pelo sistema, o que causa um overhead em tempo de execuo, ou
pode ser explicitamente executada na aplicao, o que potencialmente pode causar
erros se o teste de verificao for esquecido.
Ajuste de referncia - quando um objeto definido em memria e posteriormente

passa a receber referncias a partir de outros objetos persistentes, as referncias
originalmente feitas em memria precisam ser convertidas para referncias
persistentes em disco.
Algumas caractersticas adicionais podem ser integradas API de um SGBDOO com o

objetivo de aumentar sua funcionalidade. Dentre as caractersticas adicionais relevantes
para a interface do sistema de base de dados esto o suporte a transaes aninhadas e o
suporte a agrupamento de objetos, visando uma melhor performance nas operaes de
recuperao. Finalmente, dentre as caractersticas adicionais relacionadas interface de
objetos individuais destacam-se: recuperao de verses anteriores do objeto (em sistemas
que armazenam mais de uma verso de um mesmo objeto), suporte a travamento (locking)
de objetos em bases de dados compartilhadas e nomeao de objetos para facilitar a
recuperao dos mesmos.
Como ilustrao, a Tabela 1 apresenta uma comparao em relao s caractersticas
apresentadas pelas APIs de alguns SGBDOOs e do padro ODBC. Os smbolos S, N e ?
indicam respectivamente, SIM (caracterstica existente), NO (caracterstica inexistente),
e indeterminado (no est claro na literatura disponvel se a caracterstica existe ou no).
Os nmeros referem-se a observaes relevantes s APIs dos sistemas, e so apresentadas
logo aps a Tabela 1. O dados referentes aos sistemas GemStone, ObjectStore,
POSTGRES e Iris so encontrados em [Perez_91], e os dados do padro ODBC foram
includos neste trabalho apenas com o objetivo de ilustrar as caractersticas de uma API
11
padro de acesso a bases de dados relacionais, comparando-as a APIs de SGBDOO e

SGBD relacionais estendidos.
ODBC
GemStone
ObjectStore
POSTGRES
IRIS
Shutdown
Incio de Transao
Commit de Transao
Abort de Transao
"no se
aplica"
Objetos Modificao
Recuperao
Transaes Elaboradas
Grupos de Objetos
Verses Anteriores
Locks em Objetos
Nomeao de Objetos
Interface Startup
Do
Sistema
Interface Alocao/Desalocao
Atribuio/Comparao
de
Outras
Persistncia
Tabela 1 - Comparao entre APIs de SGBDOO
Observaes da Comparao:
1. O ObjectStore permite apenas alocao de objetos completamente transientes ou
completamente persistentes. Objetos no podem ser alocados como transientes e
posteriormente indicados como persistentes.
2. No sistema IRIS todos os objetos so persistentes.
12
2.5 Linguagem de Consulta

A linguagem de consulta um importante componente para qualquer SGBD. No entanto,
algumas linguagens de consulta de SGBDOOs no so to poderosas quanto em sistemas
relacionais e sistemas relacionais estendidos [Cattell_94]. Em SGBDOOs, a sintaxe da
linguagem de consulta usualmente uma extenso da linguagem de programao,
possuindo a mesma estrutura de tipos e sendo executada no mesmo do processo. A
linguagem de consulta orientada a objetos no possui construtores prprios, pois pretende
combinar os construtores de tipos da linguagem de programao orientada a objetos numa
linguagem de consulta declarativa de alto nvel [Bertino_92], no estilo da linguagem de
consulta relacional.
As linguagens de consulta orientadas a objetos tm como caracterstica principal o suporte
a conceitos do paradigma de orientao a objetos [Bertino_92] [Chan_94], como os citados
nos itens a seguir.
Identidade de objetos - a linguagem de consulta precisa operar sobre os

identificadores dos objetos (OIds). Os predicados de igualdade, por exemplo, so
aplicados sobre os valores dos objetos e sobre seus identificadores. Este conceito
tambm vlido para valores e identificadores de propriedades.
Mtodos - num sistema orientado a objetos, os mtodos so a interface de acesso ao

contedo de um objeto. Portanto, uma caracterstica importante das linguagens de
consulta orientadas a objetos o suporte invocao de mtodos.
Objetos complexos - uma linguagem de consulta orientada a objetos deve suportar

resultados de diferentes tipos, pois consultas sobre objetos complexos podem resultar
em valores bsicos, em objetos ou em colees. Alm disso, importante que a
linguagem permita a navegao em objetos complexos estruturados e a utilizao de
expresses de caminho para formular consultas (joins implcitos) para estruturas
aninhadas.
Hierarquia de classes - importante que a linguagem de consulta possibilite que

uma consulta aplicada a uma classe seja estendida a suas subclasses, explorando a
informao semntica representada atravs da hierarquia de classes.
13
Binding atrasado - o princpio de sobrecarga, ou polimorfismo, da orientao a

objetos requer que a linguagem de consulta suporte a noo de binding atrasado, o
que permite a correta execuo de mtodos sobrecarregados quando de sua
invocao.
Alm dos princpios bsicos da orientao a objetos, uma linguagem de consulta orientada
a objetos pode aumentar sua funcionalidade atravs do suporte a consultas recursivas,
consultas aninhadas e criao dinmica de objetos no contexto de uma consulta
[Bertino_92] [Chan_94].
2.6 Padres para Gerenciamento de Dados Orientados a Objetos

Padres representam uma parte importante no estudo de sistemas de base de dados, pois
permitem a construo de aplicaes portveis [Cattell_94]. Os SGBDs relacionais, por
exemplo, embora apresentem alto nvel de independncia de dados e um modelo de dados
simples, alcanaram seu sucesso, tanto comercialmente como em pesquisas, devido
padronizao que oferecem. O padro SQL [Date_97], amplamente aceito e utilizado por
sistemas relacionais, possibilita alto grau de portabilidade e interoperabilidade entre
sistemas, alm de simplificar o aprendizado de novos SGBDOOs.
Os padres para SGBDOOs so essenciais para viabilizar o entendimento e a aceitao da
tecnologia de bases de dados orientadas a objetos, pois sistemas que utilizam esta
abordagem diferem muito em relao aos modelos de dados e s linguagens de
programao [Cattell_94]. O objetivo principal a utilizao de padres para a construo
de aplicaes portveis baseadas em SGBDOOs, cuja principal caracterstica a integrao
entre base de dados e linguagem de programao.
Alguns padres, projetados e especificados por organizaes e comits de padres
[Eisenberg_98], so amplamente difundidos e utilizados em aplicaes baseadas
SGBDOOs. As sees seguintes descrevem dois dos padres que se destacam: ODMG e
SQL3. Ambos os padres, se analisados como recursos utilizados por aplicaes para
acesso a bases de dados, podem ser considerados como APIs para SGBDs.
14
2.6.1 ODMG
O padro ODMG (Object Database Management Group) [Barry_98a] [Cattell_94]
[Cattell_97] [ODMG_00] foi projetado para SGBDs orientados a objetos com arquiteturas
baseadas em linguagens de programao. O objetivo principal do ODMG viabilizar a
construo de aplicaes portveis que possam ser executadas em diferentes SGBDOOs.
Para tanto, o esquema de dados, o binding da linguagem de programao e as linguagens
de manipulao de dados e de consulta tambm devem ser portveis.
De maneira geral, o ODMG pretende ser adotado como um padro de desenvolvimento de
aplicaes centradas em sistemas que integram linguagens de programao e bases de
dados orientadas a objetos. Para tais aplicaes o padro ODMG pode apresentar
resultados mais satisfatrios em relao, por exemplo, ao padro SQL3 [Barry_98b].
Declarao em
ODL ou ODL LP
Fonte da
Aplicao em LP
Pr-processador
de Declarao
Compilador LP
SGBDOO
Aplicao
Binria
Metadado
Linker
Acesso a
Dados
Base de Dados
Aplicao
Executvel
Figura 1 - Utilizao de um SGBDOO
A Figura 1 [Cattell_97] apresenta uma viso genrica de como um SGBDOO utilizado

no processo de desenvolvimento de uma aplicao. Como ilustrado, o programador escreve
as declaraes para o esquema e o programa fonte com a implementao da aplicao. O
cdigo fonte escrito em uma linguagem de programao (LP) determinada pelo
programador e utiliza uma biblioteca de classes que fornece uma linguagem completa de
manipulao de objetos da base de dados (OML - Object Manipulation Language),
incluindo transaes e consultas aos objetos. As declaraes do esquema podem ser
escritas em uma extenso da linguagem de programao, chamada na Figura 1 de ODL
15
LP, ou em uma linguagem de definio de objetos (ODL - Object Definition Language)

independente da linguagem de programao. Em ambos os casos, um pr-processador
transforma as declaraes de acordo com a sintaxe exigida pelo compilador da linguagem
de programao utilizada. As declaraes e o programa fonte so compilados e integrados
(linked) com o SGBDOO, gerando a aplicao executvel. A aplicao acessa a base de
dados, cujos tipos devem ser compatveis com as declaraes do esquema. Uma mesma
base de dados pode ser compartilhada entre diversas aplicaes ao longo de uma rede,
considerando-se que um SGBDOO deve prover servios de compartilhamento atravs de
transaes e gerenciamento de locks, permitindo que dados sejam armazenados e
manipulados em memria cache no espao de trabalho da aplicao.
Com base no contexto ilustrado na Figura 1, o ODMG integra os seguintes componentes:
Modelo de Objetos, Linguagens de Especificao de Objetos, Linguagem de Consulta a
Objetos e Bindings padres de SGBDOOs para as linguagens C++, Smalltalk e Java. Uma
viso geral destes componentes apresentada nas subsees seguintes, destacando as
principais caractersticas de cada um deles. Descries detalhadas sobre o Modelo de
Objetos, sobre a sintaxe, a gramtica e as particularidades das Linguagens de Especificao
(ODL e OIF) e da Linguagem de Consulta (OQL), bem como especificaes dos
componentes ODL, OML e OQL dos bindings para as linguagens C++, Smalltalk e Java,
podem ser encontradas em [Cattell_97].
2.6.1.1 Modelo de Objetos
O padro ODMG define um modelo de objetos que especifica os tipos de informaes
semnticas que podem ser suportados em um SGBDOO compatvel com o ODMG. A
semntica do Modelo de Objetos determina, entre outras coisas, as caractersticas dos
objetos, os tipos de relacionamento entre eles e como os objetos podem ser nomeados e
identificados.
O Modelo de Objetos do ODMG tem como primitivas bsicas de modelagem o objeto, que
possui identificador nico (OId), e a literal, que no tem identificador. Objetos e literais
so categorizados de acordo com seus tipos, o que implica que todos os elementos de um
mesmo tipo possuem conjuntos de estados e comportamento comuns. O estado de um
objeto determinado pelos valores de suas propriedades, as quais podem ser atributos ou
relacionamentos. Por outro lado, o comportamento do objeto definido pelo conjunto de
16
operaes que podem ser executadas sobre ou pelo objeto. Os construtores do modelo,
destacados acima, so utilizados na modelagem de aplicaes centradas em SGBDOOs,
permitindo a declarao explcita de relacionamentos e operaes. O modelo de objetos
gerado para uma aplicao corresponde ao esquema lgico na base de dados.
2.6.1.2 Linguagens de Especificao de Objetos
O padro ODMG possui linguagens de especificao, independentes da linguagem de
programao, que so usadas para a definio de esquemas, operaes e estados dos
objetos da base de dados de um SGBDOO. Essas linguagens tm como objetivo facilitar a
portabilidade de bases de dados em implementaes ODMG compilveis. Alm disso, as
linguagens de especificao auxiliam a interoperabilidade entre SGBDOOs de diferentes
vendedores. O ODMG possui duas linguagens de especificao principais: ODL - Object
Definition Language e OIF - Object Interchange Format.
A linguagem ODL, utilizada para a especificao dos tipos de objetos do Modelo de
Objetos do ODMG, oferece suporte a todos os construtores semnticos do modelo. A ODL
atua como uma linguagem de definio para a especificao de objetos (DDL para tipos de
objetos) e no como uma linguagem de programao completa.
A ODL pode ser adotada em projetos de aplicaes sem levar em considerao a
linguagem de programao a ser utilizada na implementao. Desta forma, os resultados de
um projeto podem ser utilizados diretamente no SGBDOO ou traduzidos para uma
linguagem qualquer de descrio de dados. No entanto, as especificaes ODL podem ser
traduzidas ou implementadas com mais eficincia pelas linguagens C++, Java e Smalltalk,
para as quais esto definidos bindings ODMG. Alm disso, a ODL permite que uma
mesma base de dados seja compartilhada por diferentes linguagens de programao,
possibilitando ainda que uma aplicao seja portada para uma linguagem diferente sem que
a definio do esquema seja re-escrita. A ODL tambm fornece um contexto de integrao
de esquemas de origens variadas, mesmo que estes esquemas tenham sido definidos a
partir de modelos de dados e linguagens de definio diferentes. Por exemplo, padres
como o SQL3 podem ter seus modelos mapeados para especificaes ODL, formando uma
base que permite que vrios modelos sejam integrados com uma semntica comum.
17
A OIF uma linguagem de especificao utilizada para salvar em arquivos o estado

corrente da base de dados, e para ler dos arquivos esta mesma informao. A OIF tambm
utilizada para migrar objetos entre bases de dados, fornecer documentao e gerenciar
conjuntos de testes na base.
2.6.1.3 Object Query Language (OQL)
O padro ODMG possui uma linguagem de consulta, OQL, que oferece suporte aos
construtores do Modelo de Objetos. A OQL uma linguagem declarativa destinada a
consultas e atualizaes de objetos da base de dados. simples e completa no que se refere
a linguagens de consulta que acessam SGBDOOs, embora no seja computacionalmente
completa.
A linguagem OQL incorpora algumas formas sintticas da linguagem SQL, alm de
apresentar algumas caractersticas similares ao padro SQL2 e ser compatvel com o
SQL3. As principais extenses da OQL em relao ao SQL2 so de suporte s noes de
orientao a objetos, como objetos complexos, identidade de objetos, polimorfismo,
expresses de caminho, invocao de operaes e binding atrasado.
A OQL fornece primitivas de tratamento eficiente de construtores como listas, vetores e
estruturas em geral, mas no restringe o tratamento de conjuntos de objetos a estes
construtores. Como linguagem funcional, a OQL permite a composio de operadores,
desde que os operandos respeitem o sistema de tipos. Esta restrio uma conseqncia
direta do fato de que o resultado de qualquer consulta pode ser consultado novamente, e
portanto deve ter um tipo pertencente ao sistema de tipos do ODMG.
As clusulas OQL podem ser chamadas por implementaes em linguagens de
programao para as quais existam bindings ODMG. Analogamente, clusulas OQL
podem chamar operaes programadas nessas linguagens.
2.6.1.4 Bindings para Linguagens de Programao
A noo de binding no padro ODMG baseada na utilizao e extenso da sintaxe e da
semntica das linguagens de programao para fornecer suporte ao desenvolvimento de
aplicaes apoiadas em SGBDOOs [Cattell_94]. Em sua verso 2.0 [Cattell_97], o ODMG
possui bindings definidos para as linguagens C++, Smalltalk e Java, e para cada um deles
18
existem trs componentes: ODL, OML e OQL. O componente ODL trata a definio do
esquema da base de dados, enquanto o OML manipula as instncias dos tipos definidos no
esquema, a partir dos OIds dos objetos. O componente OQL um subconjunto do OML
destinado a consultas associativas, ou seja, acesso baseado em valores associados s
propriedades (atributos e relacionamentos) dos objetos.
O objetivo principal dos bindings para linguagens de programao tornar a existncia de
duas linguagens (linguagem de programao e linguagem de base de dados) transparente
para o programador, ou seja, o programador deve pensar que est trabalhando com
apenas uma linguagem. Conseqentemente, o sistema de tipos da linguagem de
programao e da base de dados unificado, e as instncias destes tipos podem ser
persistentes (caracterstica das bases de dados) ou transientes (caracterstica das linguagens
de programao).
O binding para uma determinada linguagem de programao mantm a sintaxe e a
semntica da linguagem bsica qual inserido. O binding estruturado apenas como um
subconjunto da linguagem de programao base, e portanto no altera a funcionalidade j
existente. As expresses em OML e OQL podem ser combinadas com expresses da
linguagem de programao base, e vice-versa.
Um aspecto importante no contexto de aplicaes apoiadas em bases de dados o suporte
a persistncia [Atkinson_94] [Cattell_94] [Elmasri_00]. Portanto, torna-se relevante que os
bindings para linguagens de programao ofeream esse suporte, uma vez que as
linguagens de programao tratam apenas objetos transientes. O binding para a linguagem
C++ permite a criao de classes que podem ter instncias persistentes ou transientes. Estas
classes, chamadas persistence-capable classes, utilizam operadores sobrecarregados cujos
argumentos definem o "tempo de vida" de um objeto, isto , criam objetos persistentes ou
transientes. O binding para a linguagem Java suporta persistncia atravs da noo de
"alcanabilidade", o que significa que quando uma transao efetivada (committed), os
objetos referenciados direta ou indiretamente por objetos persistentes tornam-se tambm
persistentes. O binding para Smalltalk, que habilita o armazenamento de objetos Smalltalk,
tambm trata persistncia por "alcanabilidade" e os objetos "no alcanados" so
coletados por um sistema de garbage collection.
19
2.6.2 SQL3
SQL3 um padro importante para gerenciamento de dados orientados a objetos e
relevante principalmente em sistemas de bases de dados relacionais estendidos[Cattell_94].
Entretanto, pode ter impacto sobre outras abordagens de arquiteturas de bases de dados,
uma vez que o padro SQL largamente difundido e utilizado em sistemas de bases de
dados. O padro SQL3 indicado para criar ou estender aplicaes relacionais com suporte
a objetos. Para tais aplicaes o SQL3 a abordagem mais simples e apropriada, se
comparado com o ODMG [Barry_98b].
Caracterizado como SQL orientado a objetos [Eisenberg_99], SQL3 uma linguagem de
consulta relacional a objetos definida a partir da extenso e do aprimoramento da segunda
gerao do padro SQL, conhecida como SQL2 ou SQL-92 [Date_97]. Logo, a definio
do SQL3 inclui toda a linguagem SQL2 como um subconjunto. Alm das caractersticas
herdadas do SQL2, o SQL3 possui extenses que incluem um modelo de dados que
permite a representao de informaes para as quais o formato tabular relacional no
adequado. Outra extenso a incluso de caractersticas procedimentais que possibilitam
criao, gerenciamento e consulta de objetos persistentes.
As subsees seguintes apresentam as caractersticas mais recentes introduzidas ao padro
SQL3 para suportar os requisitos da abordagem orientada a objetos, e fazer do SQL uma
linguagem computacionalmente completa [Cattell_94]. Descries mais detalhadas a
respeito dessas e outras caractersticas do SQL3, e especificaes sintticas e semnticas
da linguagem, como predicados, construtores, palavras-chave, regras e restries para
definio de clusulas, entre outros, podem ser encontradas em [Date_97], [Eisenberg_99]
e [SQL3_97].
2.6.2.1 Tipos de Dados e Funes Definidos pelo Usurio
O suporte a tipos e funes definidos pelo usurio, e conseqente suporte a Tipos
Abstratos de Dados (TADs), so considerados caractersticas fundamentais introduzidas ao
padro SQL3, pois so recursos de suporte orientao a objetos [Cattell_94]
[Eisenberg_99].
Os TADs na linguagem SQL3 especificam basicamente atributos e rotinas. Cada atributo
pode ser de um tipo bsico como INTEGER, de um tipo coleo como ARRAY, ou de um
20
outro TAD definido pelo usurio. As rotinas podem ser procedimentos, mtodos e funes
que representam os aspectos de comportamento do TAD, ou seja, as operaes vlidas
associadas ao mesmo. Assim como em linguagens de programao orientadas a objetos, as
rotinas de um TAD em SQL3 podem ser sobrecarregadas.
O exemplo a seguir ilustra a definio do tipo Pessoa, com os atributos Nome, RG e
Data_Nasc, e a rotina Idade:
CREATE TYPE Pessoa (
Nome
VARCHAR(20),
RG
INTEGER,
Data_Nasc DATE,
FUNCTION Idade RETURNS INTEGER
< Cdigo para calcular a idade>,
);
Todos os atributos e rotinas de um TAD so encapsulados, sendo que apenas aqueles

declarados como PUBLIC so acessveis fora da definio do TAD [SQL3_97]. No caso
de sistemas de gerenciamento de dados orientados objetos, os atributos e as rotinas
pblicos de um TAD compem a interface de acesso aos objetos criados como instncias
do TAD em questo.
Uma vez que o SQL3 oferece suporte ao conceito de objetos, torna-se necessrio o suporte
a identificadores nicos de objetos (OIds). Esta necessidade est diretamente associada ao
relacionamento entre TADs e tabelas relacionais, pois embora a linguagem permita a
utilizao de TADs em declaraes e clusulas, o armazenamento efetivo de informaes
representadas como TADs requer a manipulao de tabelas relacionais [Cattell_94]. Para
tanto, o SQL3 fornece um mecanismo de definio de tabelas chamadas "typed tables"
[Eisenberg_99], cujas colunas so derivadas de atributos de um tipo estruturado. Cada
coluna de uma tabela corresponde a um atributo do TAD, e cada linha representa uma
instncia com um OId nico dentro da base de dados. As rotinas definidas para o TAD
operam sobre as linhas da tabela. A clusula abaixo ilustra a criao de uma typed table
Pes associada ao TAD Pessoa definido anteriormente:
CREATE TABLE Pes OF Pessoa;
Os valores dos OIds so definidos a partir de um tipo especial chamado REF

[Eisenberg_99], que associado ao TAD. Os valores do tipo REF, derivados dos valores
21
de um dos atributos do TAD, so os identificadores dos objetos. Desta forma, um valor de

um tipo REF faz referncia a apenas uma linha, e sempre mesma, da typed table
associada ao TAD, ou ento no faz referncia a mais nada. O exemplo seguinte ilustra a
utilizao do tipo REF, acrescentando ao TAD Pessoa uma declarao que determina
que os OIds dos objetos do tipo Pessoa so derivados do atributo RG:
CREATE TYPE Pessoa (

Nome
RG
Data_Nasc
REF (RG),
VARCHAR(20),
INTEGER,
DATE,
FUNCTION Idade RETURNS INTEGER

< Cdigo para calcular a idade>,
);
O padro SQL3 suporta a noo de hierarquia, o que significa que TADs j definidos
podem ser especializados em novos TADs (subtipos), compondo hierarquias de tipos. Os
subtipos herdam dos supertipos todos os atributos e rotinas, embora possam incluir novos
atributos e novas rotinas, como ilustrado no exemplo abaixo:
CREATE TYPE Empregado UNDER Pessoa (

Salrio
REAL,
Emp_Id
INTEGER,
Data_Admisso
DATE,
FUNCTION Tempo_Trabalho RETURNS INTEGER
<Cdigo para calcular o tempo de trabalho>,
);
O tipo Empregado um subtipo de Pessoa e possui, alm dos atributos e rotinas de

Pessoa, novos atributos (Salrio, Emp_Id e Data_Admisso) e uma nova
rotina (Tempo_Trabalho).
2.6.2.2 Novos Tipos de Dados
SQL3 possui quatro novos tipos de dados [Eisenberg_99]: LARGE OBJETC (LOB),
BOOLEAN e os tipos compostos ARRAY e ROW.
O tipo LARGE OBJECT possui as variaes CHARACTER LARGE OBJECT (CLOB) e
BINARY
LARGE
OBJECT (BLOB), que representam respectivamente strings de
caracteres e strings binrias de comprimentos variveis. Ambas as variaes possuem

22
restries que no permitem sua utilizao como chave primria (PRIMARY KEY) e como
chave estrangeira (FOREIGN KEY) [Eisenberg_99]. Alm disso, as comparaes entre
valores do tipo LOB so restritas a testes de igualdade e no igualdade.
O tipo ARRAY permite o armazenamento de colees de valores diretamente em uma
coluna de uma tabela da base de dados. Por exemplo, a clusula:
DIAS_DA_SEMANA VARCHAR(10) ARRAY[7]
armazena os nomes dos sete dias da semana diretamente em uma nica linha e em uma
nica coluna de uma tabela da base de dados. Neste caso, embora a informao
armazenada possa ser decomposta, pode-se dizer que o SQL3 no satisfaz a Primeira
Forma Normal (1NF) [Elmasri_00], que define que um atributo de uma tupla deve assumir
apenas valores atmicos, ou seja, armazenar coleo de valores em uma nica coluna e em
uma nica linha proibido pela 1NF.
O tipo ROW utilizado para armazenar valores estruturados em uma nica coluna, como
ilustrado pelo atributo Endereo nas clusulas abaixo:
CREATE TABLE Pessoa (
Nome
VARCHAR(30),
Endereo
ROW (
Rua
VARCHAR(30),
Cidade
VARCHAR(20),
Estado
CHAR(2),
),
);
As consideraes a respeito da 1NF para o tipo ARRAY tambm so vlidas para o tipo
ROW.
2.6.2.3 Segurana Adicional
O padro SQL3 disponibiliza um recurso baseado em papis (roles) definidos pelo usurio
que permite que privilgios sejam concedidos indistintamente mediante identificadores de
autorizao e mediante papis [Date_97] [Eisenberg_99]. Os papis, por sua vez, tambm
so privilgios concedidos a identificadores de autorizao e a outros papis. Este
mecanismo aninhado pode simplificar o gerenciamento de segurana em um ambiente de
base de dados.
23
2.6.2.4 Novos Aspectos Semnticos

SQL3 incorpora alguns novos aspectos de comportamento, dentre os quais esto consultas
recursivas, transaes com savepoints e atualizao de vises.
A consulta recursiva atende s aplicaes para as quais o processamento recursivo um
requisito importante e necessrio [Date_97]. Por exemplo, numa base de dados que
armazena informaes de pesquisas genealgicas, encontrar todos os ancestrais de uma
pessoa uma consulta comum que requer um processo recursivo. Esta consulta pode ser
construda como no exemplo abaixo, em que Pai_De (Pai, Filho) uma tabela que
representa o relacionamento de paternidade. Ancestral_De chamado de nome da
consulta e integra os pares (Ancestral, Descendente) que resultam da consulta
recursiva. A segunda parte da consulta seleciona, entre os pares(Ancestral,
Descendente), todos os ancestrais de Jlia.
WITH RECURSIVE Ancestral_De (Ancestral, Descendente)
AS (
SELECT Pai, Filho FROM Pai_De
UNION
SELECT A.Pai, P.Filho
FROM Ancestral_De AS A, Pai_De AS P
WHERE A.Filho = P.Pai
)
SELECT Ancestral_De.Ancestral FROM Ancestral_De
WHERE Ancestral_De.Descendente = "Jlia"
As transaes com savepoints atuam como subtransaes que garantem que apenas as
aes realizadas a partir de um determinado ponto (savepoint) sejam afetadas por
operaes de "desfazer" (roll back). Isto evita que todas as aes de uma transao sejam
desfeitas, preservando as atualizaes efetuadas antes do savepoint especificado
[Eisenberg_99].
O mecanismo de vises, utilizado em muitas aplicaes, geralmente no permite operaes
de atualizao em vises. O SQL3, entretanto, permite que dependncias funcionais
inerentes aplicao determinem quais vises podem ser atualizadas e como as alteraes
so realizadas na base de dados [Eisenberg_99].
24
2.6.2.5 Extenses Procedimentais

SQL3 inclui novos construtores procedimentais, entre os quais esto declaraes
condicionais, como IF/THEN/ELSE e CASE, e declaraes de repeties, como WHILE
e FOR. Estes construtores contribuem para fazer do SQL3 uma linguagem
computacionalmente completa.
2.7 Consideraes Finais

Neste captulo aborda os principais conceitos de Sistemas de Gerenciamento de Bases de
Dados Orientados a Objetos. Em geral, os princpios de orientao a objetos fundamentam
as caractersticas dos SGBDOOs e de seus componentes, bem como dos padres
especificados para auxiliar o desenvolvimento de aplicaes portveis apoiadas nestes
sistemas.
A reviso conceitual apresentada neste captulo representa o embasamento terico inicial
para o desenvolvimento do trabalho proposto. Em particular, as consideraes a respeito da
API dos SGBDOOs (seo 2.4) so de fundamental importncia no contexto do trabalho,
uma vez que este tem como objetivo principal definir uma API para um SGBDOO. O
sistema SIRIUS, para o qual pretende-se criar uma API, tratado no captulo seguinte,
onde so abordadas as caractersticas predominantes de alguns SGBDOOs clssicos.
25
3 Sistemas Orientados a Objetos
3.1 Introduo
Os SGBDOOs oferecem o suporte apropriado a aplicaes de mbito tcnico-cientfico,
como as citadas no Captulo 1. Tais aplicaes abrangem diferentes reas de
conhecimento, entre as quais esto engenharia, medicina e inteligncia artificial. No
entanto, aplicaes tradicionais voltadas para ambientes de negcios, usualmente apoiadas
em SGBDs relacionais, tambm podem obter benefcios da tecnologia dos SGBDOOs
[Cattell_94].
Vrios SGBDOOs vm sendo desenvolvidos com um objetivo em comum: integrar bases
de dados e linguagens de programao orientadas a objetos para oferecer suporte adequado
s exigncias de aplicaes no convencionais, ou seja, modelagem e tratamento adequado
de objetos complexos, armazenamento e gerenciamento de dados em larga escala,
extensibilidade, portabilidade, entre outras.
As sees seguintes descrevem os sistemas O2 e Jasmine, sintetizando as caractersticas de
seus principais componentes, lembrando que no objetivo deste trabalho fazer uma
descrio completa e detalhada de tais sistemas, mas sim apresentar uma viso geral de
cada um deles. Outros SGBDOOs so brevemente comentados na seo 3.5.
3.2 Sistema O2
O2 [Bancilhon_92] [Deux_90] [Deux_91] um sistema comercial atualmente
desenvolvido pela O2 Technology e comercializado pela Ardent Software, Inc. O O2
adequado ao desenvolvimento de aplicaes no convencionais, como sistemas de apoio
engenharia, sistemas geogrficos e automao de escritrios, podendo tambm ser
utilizado por aplicaes tradicionais.
26
O sistema O2 integra interface com o usurio, linguagem de programao e base de dados,

utilizando o paradigma de orientao a objetos e mantendo a conformidade com padres.
Com isso, pretende aumentar a produtividade no processo de desenvolvimento de
aplicaes e melhorar a qualidade do produto final, em termos de aparncia, performance,
manutenibilidade e habilidade de customizao.
O2Tools
C
C++
O2C
O2Query
O2Look
O2Engine
Figura 2 - Estrutura Funcional do Sistema O2
O O2 integra um conjunto de componentes que fazem dele um sistema de bases de dados e

um sistema de programao orientado a objetos. A Figura 2 [Deux_91] ilustra a
configurao funcional do O2, destacando o O2Engine - ncleo do sistema - e os dois tipos
de interfaces (APIs) suportadas por este ncleo: as interfaces de linguagens para C e C++,
e o ambiente O2, composto por uma linguagem de objetos de 4a gerao denominada O2C,
uma linguagem de consulta O2Query (tambm chamada de O2SQL [Cattell_94]), um
gerador de interfaces de usurio O2Look, e um ambiente grfico de programao O2Tools,
o qual inclui um debugger e um browser para esquema e base de dados. As subsees
seguintes descrevem os elementos relevantes do O2 para o contexto deste trabalho.
3.2.1 Arquitetura do Sistema
O O2Engine um engine de base de dados orientado a objetos, responsvel pelo
armazenamento de objetos complexos (estruturados e multimdia) e por funes de
gerenciamento de disco, distribuio, gerenciamento de transaes, concorrncia,
recuperao, segurana e administrao de dados.
A arquitetura do O2Engine organizada em trs camadas principais, como ilustrado na
Figura 3. O nvel mais alto o Gerenciador de Esquemas, cuja funcionalidade abrange a
criao, acesso, atualizao e a destruio de classes, mtodos e nomes globais. Ainda
nessa camada so manipulados os mecanismos de importao entre esquemas, verificao
de consistncia de esquemas e verificao de regras semnticas em hierarquias de tipos.
27
Na camada intermediria est o Gerenciador de Objetos, responsvel gerenciamento de

objetos, trocas de mensagens, manipulao de valores estruturados e operaes aplicadas
sobre estes valores. O Gerenciador de Objetos implementa tambm o princpio da
alcanabilidade para persistncia de objetos, garbage collection para objetos no
referenciados, gerenciamento de transaes, estratgias de indexao e clustering baseadas
em objetos complexos, e herana.
Gerenciador de Esquemas
Gerenciador de Objetos
Extenso do WiSS
Figura 3 - Arquitetura do O2 Engine
A camada mais interna, tambm chamada de O2Store [Cattell_94], uma extenso do

WiSS (Wisconsin Storage System), que atua como o gerenciador de disco do O2. O WiSS
prov funes de tratamento de estruturas persistentes, gerenciamento de disco e controle
de concorrncia. As extenses do WiSS original para o O2 incluem arquitetura
cliente/servidor no nvel do O2Store, recuperao de falhas e rollback, e suporte multithread para o servidor.
3.2.2 Modelo de Dados e Linguagem O2C
A linguagem O2C - considerada uma linguagem de 4a gerao por integrar programao,
manipulao de base de dados e gerao de interface de usurio - implementa todos os
conceitos e construtores do modelo de dados do O2.
O modelo de dados e a linguagem O2C suportam os tipos atmicos integer, real,
character, string, boolean e bits, e tipos complexos definidos recursivamente atravs dos
construtores tuple, list e set. As instncias dos tipos so chamadas de valores.
No O2, o esquema da base de dados definido por classes que descrevem a estrutura e o
comportamento de um conjunto de objetos, identificados univocamente atravs de OIds. A
parte estrutural de uma classe definida por um tipo e o comportamento representado por
um conjunto de mtodos. O exemplo a seguir ilustra a criao da classe Restaurante,
com os atributos Nome, Menu e Cidade e o mtodo Inserir_Novo_Prato. Os
28
atributos Nome e Cidade so do tipo string e o atributo Menu uma lista de tuplas
formadas por Preo e Contedo. O mtodo, assim como em linguagens de
programao orientadas a objetos, implementado fora da especificao da classe.
class Restaurante
type tuple (
Nome: string,
Menu: list(tuple(Preo: real,
Contedo: string)),
Cidade: string)
method Inserir_Novo_Prato (real: PREO, string: Contedo)

end;
O O2 suporta o conceito de herana, simples e mltipla, permitindo que uma classe tenha
seu tipo e seus mtodos herdados de outras classes. A herana mltipla pode gerar
eventuais colises de nomes quando atributos ou mtodos herdados de classes diferentes
possuem o mesmo nome. Neste caso, os nomes conflitantes so explicitamente
renomeados na subclasse (comando renaming). Novos atributos e mtodos podem ser
definidos para a subclasse, assim como tipos e mtodos podem ser redefinidos localmente.
O tratamento persistncia segue o princpio da "alcanabilidade", onde um objeto tornase persistente se estiver ligado a um objeto raiz persistente atravs de um relacionamento
de herana ou de composio (colees). O conceito de encapsulamento tratado no O2
em trs nveis: encapsulamento de atributos e mtodos numa classe, encapsulamento de um
conjunto de classes no esquema e encapsulamento da base de dados. Os dois ltimos tipos
permitem reusabilidade, pois um esquema pode exportar um conjunto de classes para outro
esquema, assim como uma aplicao rodando sobre uma base de dados em particular pode
acessar outra base de dados apenas invocando um mtodo que ser executado na base
remota.
3.2.3 Linguagem de Consulta
A linguagem de consulta O2Query um subconjunto da O2C, mas pode ser utilizada como
uma linguagem interativa independente ou pode ter seus comandos chamados dentro de
programas C e C++.
O2Query uma linguagem SQL-like estendida para manipular valores e objetos
complexos. Alm disso, todos os tipos de dados, operadores e mtodos so aceitveis em
uma consulta em O2Query. As consultas so especificadas basicamente em trs partes: a
29
parte do select define a estrutura do resultado; a parte do from introduz as classes de

objetos, os conjuntos e listas sobre os quais a consulta ser executada; e a parte where
define o predicado que "filtra" o resultado. O exemplo a seguir ilustra uma consulta sobre
objetos da classe Restaurante (definida na seo 3.2.2) que resulta em uma estrutura
com as seguintes informaes: nomes dos restaurantes de So Paulo onde pode-se comer
por menos de 50 reais e as respectivas opes do menu, contendo os pratos e os preos.
select tuple (Restaurante: R.Nome,
Opes: select tuple (Preo: Opo.Preo,
Prato: Opo.Contedo)
from Opo in M)
from R in Restaurante,
M in R.Menu
where R.Cidade = "So Paulo" and (exists Opo in M:
Opo.Preo < 50)
As linguagens O2Query e O2C constituem uma das formas de construo de aplicaes e

manipulao de dados, pois fazem parte da interface do ambiente O2. Por outro lado,
aplicaes tambm podem ser implementadas nas linguagens C e C++, e conectadas ao O2
atravs das interfaces para linguagens de programao.
3.2.4 Interfaces para Linguagens de Programao
O sistema O2 suporta interfaces de programao para as linguagens C e C++, viabilizando
o desenvolvimento de aplicaes nestas linguagens e a reutilizao de aplicaes
existentes.
A integrao de uma linguagem de programao <LP> e o O2 pode ocorrer de duas
maneiras. Na primeira, o O2 exporta classes do esquema para o ambiente da linguagem de
programao. O comando export to <LP> gera classes <LP> correspondentes s classes
do esquema, permitindo que a aplicao manipule os dados do O2. A segunda abordagem,
simtrica primeira, permite que as classes sejam definidas na aplicao em linguagem
<LP>. As classes criadas na aplicao, assim como os objetos destas classes, podem
tornar-se persistentes atravs do comando import from <LP>, que gera no esquema O2 as
classes correspondentes s classes especificadas em <LP>.
O exemplo a seguir ilustra a utilizao do comando export to C++, supondo que a
aplicao C++ pretende utilizar a classe Restaurante definida anteriormente. No
exemplo, a aplicao no precisa utilizar os mtodos da classe, mas apenas o seu tipo.
30
export class Restaurante type to C++
Este comando gera as seguintes declaraes em C++:

class o2_ Restaurante {...}
class Restaurante: o2_root{
public:
char *Nome,
struct {
int Tamanho;
struct {
float Preo;
char *Contedo;
}*Opo;
// Tipo do ponteiro persistente

// para a classe Restaurante
// o2_root traz persistncia para
// esta classe
// A coleo Menu
// transformada
// um vetor dinmico
}Menu;
char *Cidade;
};
A interface para a linguagem C++ incrementa o ambiente de desenvolvimento C++ com

quatro caractersticas adicionais para suportar a integrao com o sistema O2:
Ponteiros persistentes: permitem acesso transparente a qualquer objeto persistente.

Um ponteiro persistente pr-definido como um template que implementa a sintaxe e o
comportamento de um ponteiro padro da linguagem C++.
Colees genricas: provem gerenciamento de colees transientes e persistentes,

como listas, conjuntos e vetores, pois permitem a definio de classes para os
construtores de colees do O2: set e list.
Razes persistentes: so objetos nomeados atravs dos quais objetos C++ transientes
podem tornar-se persistentes pelo princpio da alcanabilidade.
Suporte a bases de dados: inclui transaes, indexao e O2Query embutido.
3.3 Sistema Jasmine

O sistema Jasmine [Ishikawa_93] [Ishikawa_96] [Jasmine_00], atualmente desenvolvido e
comercializado pela Computer Associates, pretende atender s necessidades de aplicaes
no convencionais com nfase em tarefas voltadas para engenharia, tais como
gerenciamento de dados de projeto, suporte a CAD inteligente e gerenciamento de
31
documentos de engenharia (textos, figuras, tabelas, entre outros). Dentre as caractersticas

do Jasmine, algumas so relevantes para aplicaes em engenharia, como facilidade de
gerenciamento de restries, facilidade de incluso de regras de restries, alimentao
automtica da base de dados e integrao de esquemas. Alm disso, o Jasmine oferece
suporte ao desenvolvimento de aplicaes multimdia, que envolvem gerenciamento de
dados complexos.
As subsees seguintes apresentam uma viso geral da arquitetura, do modelo de dados e
da linguagem de base de dados do sistema Jasmine.
3.3.1 Arquitetura do Sistema
O Jasmine possui uma estrutura em camadas que consiste de um nvel de gerenciamento de
objetos, um nvel de gerenciamento de dados e uma base de dados relacional utilizada
como repositrio de dados. A Figura 4 [Ishikawa_96] ilustra a arquitetura do sistema,
sobre a qual operam dois subsistemas predominantes: o subsistema de gerenciamento de
dados e o subsistema de gerenciamento de objetos.
Usurio
Aplicao
Gerenciamento de Objetos
Gerenciamento de Dados
Base de Dados
Figura 4 - Arquitetura do Sistema Jasmine
O subsistema de gerenciamento de dados definido como um SGBD relacional estendido

de propsito geral, pois utiliza a tecnologia relacional para o gerenciamento de dados. Esse
subsistema possui mtodos eficientes para armazenar e acessar objetos em memria
secundria atravs das relaes da base de dados relacional. Uma extenso tecnologia
relacional tradicional o suporte a relaes aninhadas, incorporado ao subsistema para
32
armazenar objetos complexos agrupados e permitir a definio de estruturas de ndices

para acesso rpido aos objetos. O subsistema de gerenciamento de dados tambm
responsvel por servios bsicos de gerenciamento de transaes, controle de concorrncia,
recuperao do sistema em caso de falhas e gerenciamento de I/O em disco.
O subsistema de gerenciamento de objetos oferece suporte ao modelo de dados e
linguagem de base de dados, utilizando o subsistema de gerenciamento de dados para
implement-los. No subsistema de gerenciamento de objetos esto includos o compilador
e o interpretador de linguagem, e as bibliotecas de suporte em tempo de execuo. As
operaes de otimizao de consulta so estendidas para consultas orientadas a objetos,
incluindo suporte s hierarquias de classes e invocao de mtodos.
Os objetos manipulados pelo Jasmine so traduzidos em relaes automaticamente pelo
sistema. As instncias de uma classe so armazenadas em uma relao correspondente
classe, onde cada instncia representada por uma tupla e cada atributo mapeado num
campo da relao. Atributos multi-valorados e atributos estruturados so mapeados em
relaes aninhadas, as quais tambm so utilizadas para armazenar objetos complexos
agrupados, aumentando a performance das operaes de acesso a estes objetos.
3.3.2 Modelo de Dados
No Modelo de Dados do Jasmine, os objetos so caracterizados como colees de
atributos, os quais podem ser categorizados em propriedades que definem a estrutura dos
objetos, e em mtodos que definem as operaes que podem ser aplicadas sobre os
objetos. Os objetos, identificados univocamente atravs de atributos OIds gerados
automaticamente pelo sistema, so divididos em instncias e classes. Objetos podem
incluir outros objetos como atributos, definindo objetos complexos ou objetos compostos,
os quais suportam o conceito de agregao.
O exemplo abaixo ilustra a definio de uma classe Pessoa e de sua subclasse
Estudante.
Pessoa
Db Universidade
Super Composite
Enumerated
STRING Nome mandatory
INTEGER RG
Estudante
Db Universidade
Super Pessoa
Enumerated
INTEGER Nmero mandatory
DISCIPLINAS dc multiple
33
STRING Endereo
Cidade_Or Origem
STRING Turma
No exemplo, a palavra chave mandatory indica que o atributo no pode receber valor
nulo. Multiple indica atributo multi-valorado e enumerated indica incio de uma lista de
atributos definidos pelo programador. A palavra chave Db precede o nome da base de
dados qual a classe definida deve fazer parte e super indica quem sua superclasse. A
classe Composite, definida pelo sistema, uma superclasse das classes que esto no
nvel mais alto da hierarquia de classes criada pelo usurio. No exemplo, a classe Pessoa
no possui superclasse definida pelo usurio, ou seja, est no nvel mais alto da hierarquia.
Portanto, a superclasse de Pessoa a classe Composite definida pelo sistema.
Assume-se, para este exemplo, que a classe Cidade_Or, tipo do atributo Origem, foi
previamente definida.
O exemplo abaixo ilustra uma possvel instncia da classe Pessoa:
UniversidadePessoa001
Nome
"Paulo"
RG
99999
Endereo "Rua 05, nro 30"
Origem
UniversidadeCidade010
As classes so organizadas em uma hierarquia atravs de relacionamentos de

generalizao, oferecendo suporte a hierarquias de classes e herana mltipla. Em uma
hierarquia de classes, qualquer classe pode ser instanciada diretamente, sendo que as
instncias de classes "no folhas" da hierarquia podem expressar conhecimento incompleto
do domnio da aplicao. Por exemplo, se a classe Pessoa especializada nas subclasses
Estudante e Professor, as instncias diretas da classe Pessoa denotam um
conjunto de pessoas que a priori no so nem estudantes nem professores.
Uma classe pode ser interpretada como um conjunto de todas as suas instncias diretas e de
todas as instncias de suas subclasses, o que caracteriza o conceito de classificao no
modelo de dados do Jasmine. Em contrapartida, uma classe pode ser dividida em
subclasses disjuntas, formando uma partio. Para a classe Pessoa, por exemplo, pode-se
definir uma partio contendo as subclasses Adulto e Criana. Esta categorizao
pode ser especificada atravs de valores de algum atributo. Para o exemplo, um atributo
34
Idade poderia determinar a semntica da partio. O conceito de categorizao pode ser

utilizado para otimizao de consultas.
Finalmente, os atributos de um objeto podem estar associados a funes especializadas,
chamadas demons, que atuam como mecanismos de tratamento de eventos e restries. Os
demons podem ser combinados, por exemplo, na implementao de bases de dados ativas.
3.3.3 Linguagem de Base de Dados
O sistema Jasmine possui uma linguagem de bases de dados, denominada Jasmine/C, que
integra uma linguagem de programao de propsito geral (C) e uma linguagem de base da
dados orientada a objetos. A Jasmine/C oferece suporte a dois tipos de acesso a objetos:
acesso individual e acesso orientado a conjunto. O primeiro baseado na manipulao de
objetos atravs do envio de mensagens, permitindo atribuies de valores aos atributos e
referncias a valores de atributos. O segundo tipo de acesso, direcionado base de dados,
implementado como consultas a objetos.
Uma expresso de consulta em Jasmine/C dividida em duas partes: uma contendo uma
expresso de objetos, ou uma lista de expresses, e outra contendo uma combinao lgica
de predicados que comparam as expresses de objetos. Um consulta em uma classe retorna
todas as instncias da classe e de suas subclasses. As expresses de objetos, formadas
predominantemente por nomes de classes seguidos de nomes de atributos, denotam os
joins de objetos, que podem ser definidos implicitamente atravs de "caminhos" na
expresso de objetos. O exemplo abaixo ilustra o join implcito em uma consulta em que
pretende-se recuperar o nome da cidade de origem da pessoa cujo nome Alice:
Pessoa.Cidade_Or.Nome where Pessoa.Nome == "Alice"
As expresses de objetos podem invocar demons que verificam restries definidas pelo
programador da aplicao. Alm disso, mtodos de classes e mtodos definidos pelo
sistema, como put, delete e print, tambm podem ser executados a partir de uma consulta.
O tratamento a mtodos definidos pelo sistema e mtodos definidos pelo usurio
uniforme. Na consulta abaixo, por exemplo, o mtodo put insere um novo valor para o
conjunto de disciplinas cursadas pelo estudante Paulo:
Estudante.put("Disciplinas","ICC-II")
where Estudante.Nome == "Paulo"
35
A linguagem de base de dados e o modelo de dados do Jasmine so baseados em um

formalismo matemtico que pode ser encontrado em [Ishikawa_93], onde descries
detalhadas a respeito do Jasmine e inmeros exemplos so apresentados.
3.4 Outros Sistemas

Esta seo faz uma apresentao breve de outros sistemas de gerenciamento de bases de
dados orientados a objetos.
ObjectStore [Lamb_91] um SGBDOO que utiliza C++ como linguagem de programao
de base de dados. O ObjectStore prov funes bsicas de gerenciamento de objetos,
manipulao de objetos complexos e colees, e mecanismos de herana mltipla. Alm de
incorporar um browser de base de dados e uma ferramenta interativa para projetos de
esquemas.
GemStone [Butterworth_91] possui uma linguagem de programao de bases de dados
similar ao Smalltalk, chamada OPAL. Alm da OPAL, este sistema possui interfaces para a
linguagem C++. O GemStone suporta uma arquitetura cliente-servidor, sobre a qual
prevalecem dois processos: o Stone, responsvel pelo gerenciamento de dados, e o Gem,
responsvel principalmente pela compilao da linguagem OPAL. O GemStone tambm
oferece suporte a objetos complexos, servios de garbage collection, evoluo de
esquemas e ferramentas de interface com o usurio.
Objectivity/DB [Cattell_94] integra uma interface de programao C++ com nfase no
SGBD, visando robustez e escalabilidade. O Objectivity/DB suporta uma arquitetura
cliente-servidor e implementa transparncia de operaes sobre mltiplas bases de dados,
esquemas, computadores, usurios, hardware, redes e sistemas operacionais heterogneos.
A interface de programao do Objectivity/DB inclui bibliotecas C e C++ e suporte aos
padres SQL e ODMG.
POSTGRES [Stonebraker_91] um sistema relacional estendido que utiliza uma base de
dados INGRES como repositrio de dados. Uma caracterstica importante do POSTGRES
o mecanismo de no-overwrite, que considera operaes de atualizao como novas
inseres, mantendo um histrico de dados anteriores. Este recurso viabiliza operaes de
36
time travel, que permitem que o usurio faa uma consulta histrica e obtenha dados
vlidos de acordo como o "tempo" especificado na consulta.
KROSS [Kim_96] um sistema de base de dados espacial orientado a objetos que utiliza o
ObjectStore como plataforma de implementao. O KROSS incorpora um modelo de
dados baseado em assinatura espacial (SAS - spatial signature) que suporta os tipos de
objetos espaciais e as operaes correspondentes. A linguagem de consulta espacial
orientada a objetos (SOQL - spatial object query language), alm de manipular objetos
espaciais, possui um mecanismo integrado para recuperao e apresentao grfica de
objetos espaciais. Sistemas de informaes geogrficas e sistemas de gerenciamento de
imagens mdicas so exemplos de aplicaes baseadas em dados espaciais.
TriGS [Kappel_98] um sistema de triggers implementado sobre o GemStone, inserindo
conceitos ativos em um SGBDOO. O TriGS oferece suporte ao desenvolvimento de
aplicaes centradas em bases de dados ativas, permitindo a definio de regras associadas
a eventos, condies e aes. So exemplos de tais aplicaes: gerenciamento de fluxo de
trabalho, CAM e aplicaes multimdia.
SIRIUS um SGBDOO que vem sendo desenvolvido pelo Grupo de Banco de Dados e
Imagem (GBDI) do ICMC-USP. A pesquisa bsica e a pesquisa tecnolgica a cerca do
desenvolvimento do SIRIUS tm como objetivo principal aplicar os resultados obtidos em
atividades de desenvolvimento de sistemas centrados em bases de dados, voltados para
aplicaes no convencionais. Destacam-se sistemas de apoio medicina e ambientes de
armazenamento e distribuio de imagens.

Este captulo discute uma pequena amostragem da variedade de SGBDOOs que podem ser
encontrados na literatura. Em geral, estes sistemas diferem em relao abordagem da
arquitetura e s linguagens de programao e de consulta. As diferenas pertinentes s
linguagens podem ser amenizadas com utilizao de padres, como o ODMG e o SQL3,
apresentados na seo 2.6. Sistemas compatveis com padres de gerenciamento de objetos
permitem o desenvolvimento de aplicaes portveis.
37
Apesar das diferenas, os SGBDOOs comerciais e experimentais vm sendo projetados e

implementados visando tanto a contribuio no avano da tecnologia de bases de dados
orientadas a objetos quanto o suporte ao desenvolvimento de aplicaes no convencionais
voltadas para diferentes reas de conhecimento.
O Sistema SIRIUS, em particular, de grande interesse no contexto deste trabalho, cujo
resultado principal a definio da API para o Gerenciador de Objetos SIRIUS. Portanto,
detalhes a respeito do Sistema SIRIUS sero apresentados nos captulos seguintes,
enfatizando o Modelo de Dados e Gerenciador de Objetos SIRIUS, componentes
diretamente relacionados a este trabalho.
38
4 Modelo de Dados SIRIUS
4.1 Introduo
O Modelo de Dados SIRIUS um metamodelo orientado a objetos baseado em quatro
abstraes:
classificao,
generalizao,
agregao
composio
[Biajiz_96a]
[Biajiz_96b]. A composio e a agregao so especializaes da associao, como

ilustrado na Figura 5.
Abstrao
Classificao
Associao
Generalizao
Agregao
Composio
Figura 5 - Abstraes do modelo SIRIUS
Cada construtor semntico do modelo determina como uma ou mais abstraes so

utilizadas e como se relacionam com as demais abstraes e com os demais construtores
semnticos [Araujo_98a]. Os elementos sintticos do SIRIUS, estruturados segundo as
abstraes que o modelo suporta, so representados por objetos, atributos, caractersticas
de atributos, estruturas de composio (colnias), estruturas de generalizao, e seus
respectivos tipos.
As abstraes do SIRIUS so consideradas em pares: classificao/instanciao,
generalizao/especializao,
agregao/separao
composio/decomposio.
estrutura hierrquica de cada abstrao permite a navegao em nveis abstratos ou de

detalhe, e a utilizao do objeto detalhe e do objeto abstrato numa modelagem ou num
39
sistema. A Figura 6 ilustra o relacionamento entre um objeto detalhe e um objeto abstrato,

onde um conjunto de objetos detalhe descreve um objeto abstrato, e um objeto abstrato
sumariza as informaes genricas e comuns de um conjunto de objetos detalhe. As
propriedades desse relacionamento so definidas pelas caractersticas da abstrao.
Abstrato
Descreve
Abstrai
Propriedades
Detalhe
Figura 6 - Elementos de uma Abstrao
A seo 4.2 descreve os conceitos principais do modelo SIRIUS, relacionados s

abstraes de agregao, generalizao e composio. Uma descrio mais detalhada da
abstrao de classificao apresentada na seo 4.3, pois o suporte oferecido pelo
SIRIUS ao conceito de classificao mais abrangente e completo que o encontrado na
literatura. Consequentemente, o suporte abstrao de classificao na API do
Gerenciador SIRIUS um dos principais resultados deste trabalho.
4.2 Conceitos do Modelo SIRIUS

4.2.1 Abstrao de Agregao
A abstrao de agregao ocorre de trs maneiras distintas: agregao de atributos a
objetos, agregao de atributos a atributos e agregao de objetos a objetos. A Figura 7
ilustra ocorrncias da abstrao de agregao.
Um objeto SIRIUS definido como uma agregao de atributos, como ilustrado na Figura
7a. Cada atributo tem um tipo e um conjunto de valores que caracterizam o objeto. Por
outro lado, cada de atributo est associado a uma caracterstica que indica a funcionalidade
e as operaes que podem ser aplicadas ao atributo. O modelo SIRIUS define 15
caractersticas agrupadas em estticas, dinmicas, de interface e estruturais [Araujo_98a],
como apresentado na Tabela 2.
40
Tipo de Caracterstica
Caracterstica
Smbolo
Esttica
texto
Tx
nmero
Nu
booleano
Bo
regra
Rg
procedimento
Pc
visualizao
Vs
som
So
partitura
Pa
imagem
Im
grfico
Gr
estrutura de dados
Ed
tempo
Tm
tupla
Tp
atributo de atributo
Aa
relacionamento
Re
Dinmica
Interface
Estrutural
Tabela 2 - Caractersticas de Atributos
A agregao de atributos a atributos define a formao de atributos com caractersticas

tupla e atributo de atributo. A tupla definida como um conjunto de atributos que
associados formam um outro atributo. O atributo de atributo, por sua vez, possui um
atributo principal, chamado de identificador, ao qual esto associados sub-atributos que
adicionam informaes relevantes ao atributo principal. A Figura 7b ilustra a tupla
Endereo, formada pelos atributos Rua, Nmero e Cidade, e o atributo de atributo
Passaporte, onde o atributo Nro Passaporte o identificador da estrutura, e possui
os sub-atributos Data de Expedio e rgo Expedidor.
41
a) Agregao de atributo
a objeto
b) Agregao de atributo a atributo

Tx Rua
Tp Endereo
Tx Nome
Nu Nmero
Nu Idade
Tx Cidade
Tx Profisso
Aa Passaporte
Pessoa
Nu Nro Passaporte
Data Expedio
rgo Expedidor
c)
Agregrao de objeto a objeto
Empregado
Re Trabalha Em
Empresa
Re Emprega
Figura 7 Exemplo da Abstrao de Agregao
A agregao de objetos a objetos ocorre atravs de atributos com caracterstica

relacionamento, como exemplificado na Figura 7c. Os atributos Trabalha Em e
Emprega definem o relacionamento entre os objetos dos tipos Empregado e Empresa,
respectivamente.
Quando um atributo agregado a um objeto, algumas propriedades da abstrao de
agregao devem ser definidas, tais como a organizao do atributo, ou seja, se a atributo
mono-valorado ou multi-valorado, e os limites inferior e superior, que determinam
respectivamente o nmero mnimo e mximo de valores que podem ser assumidos pelo
atributo.
4.2.2 Abstrao de Composio
Os objetos em SIRIUS podem ser compostos por outros objetos, criando hierarquias de
composio. Os elementos sintticos colnia e tipo de colnia so as estruturas utilizadas
para representar o conceito de composio.
Uma colnia um conjunto de todos os objetos que compem diretamente outro objeto, de
acordo com um aspecto especfico. Numa hierarquia de composio, o objeto abstrato,
chamado de objeto composto, constringe uma colnia onde habitam os objetos detalhe,
chamados de objetos parte.
42
Numa representao grfica, dois diagramas representam a ocorrncia da composio

[Araujo_98a]:
Diagrama Hierrquico de Colnias (DHC) representa a composio por tipo,

definindo os tipos de colnia e os tipos dos objetos que vo constringir e habitar as
colnias instncias dos tipos de colnia definidos;
Diagrama de Representao de Instncias (DRI) representa as colnias, os objetos

que as habitam e os objetos que as constrigem.
b) DRI
a) DHC
Global
Global
Universidade
Universidade
Usp
Universidade
UFSCar
CCursos
CCursos
CCursos
Curso
Curso
Matemtica
Curso
Computao
Curso
Fsica
Curso
Computao
CDiscip
Disciplina
CDiscip
Disciplina
ICC - I
Disciplina
Bases de Dados
Figura 8 - Exemplo da Abstrao de Composio
A Figura 8a ilustra um DHC. No exemplo, o tipo de objeto Universidade constringe o

tipo de colnia CCursos. Em colnias do tipo CCursos vo habitar objetos do tipo
Curso. Analogamente, o tipo de objeto Curso constringe o tipo de colnia CDiscip, e
em colnias deste tipo vo habitar objetos do tipo Disciplina.

A Figura 8b ilustra um DRI, onde os objetos USP e UFSCar so objetos do tipo
Universidade, e habitam uma colnia do tipo Global1. O objeto USP constringe uma
colnia do tipo CCursos, como definido no DHC apresentado na Figura 8a. Nessa
colnia habitam os objetos Computao e Matemtica, do tipo Curso, que compem o
objeto USP. Da mesma forma, o objeto UFSCar constringe uma colnia do tipo CCursos,
1
O tipo de colnia Global e a colnia instncia deste tipo so definidos pelo sistema. Na colnia do tipo
Global habitam todos os objetos do tipo Meta Tipo, tambm definido pelo sistema.
43
onde habitam os objetos que o compem: Fsica e Computao, tambm do tipo

Curso. O objeto Computao, que habita a colnia constrita por USP, constringe uma
colnia do tipo CDiscip onde habitam os objetos ICC I e Bases de Dados, do tipo
Disciplina.
Por definio, um objeto habita exatamente uma colnia. No entanto, um objeto composto
pode constringir vrias colnias, desde que sejam de tipos diferentes [Ferreira_96].
4.2.3 Abstrao de Generalizao
A abstrao de generalizao fundamental em modelos de dados orientados a objetos,
pois atravs dela abstrai-se em um objeto genrico o comportamento e as propriedades de
objetos especficos [Biajiz_96a]. Um tipo de objeto, chamado de sub-tipo ou tipo
especfico, pode especializar um outro tipo de objeto j existente, chamado de super-tipo
ou tipo genrico, acrescentado detalhes pertinentes somente ao tipo de objeto especfico,
criando a hierarquia de generalizao.
Um tipo de objeto especializado segundo um critrio de especializao, que pode ser
definido pelo valor de um nico atributo, num domnio discreto e pr-definido, ou atravs
da avaliao de um predicado sobre os valores de um ou mais atributos. Alm disso, duas
restries so aplicadas especializao: a disjuno (D) ou sobreposio (S), e a
participao total (T) ou parcial (D).
Pessoa
D
Idade
Adulto
Criana
Idade <= 12
Inic.
12 < Idade < 60 Inic.
Idoso
Idade >= 60
Inic.
Disjuno ou Sobreposio (D/S)

Restries
Participao Total ou Parcial (T/P)
Figura 9 - Exemplo da Abstrao de Generalizao
44
A Figura 9 exemplifica uma hierarquia de generalizao, onde o super-tipo Pessoa

especializado nos sub-tipos Criana, Adulto e Idoso. O critrio de especializao
utilizado a avaliao de predicados sobre o atributo Idade. Por exemplo, uma pessoa
do tipo especfico Criana quando possui Idade <= 12. A propriedade Inic.
(Inicializao) define como os atributos de um objeto especfico so inicializados quando o
objeto criado, e as restries de disjuno (D) e participao total (T) completam a
definio da hierarquia de generalizao.
4.3 Abstrao de Classificao

A Abstrao de Classificao [Machado_00] um conceito importante em sistemas de
bases de dados, pois permite que os elementos de um esquema de dados sejam instanciados
em uma base extensional. Entretanto, a classificao utilizada em SGBDs de forma
restrita, sendo usualmente tratada como um relacionamento implcito entre o esquema e a
base extensional, pr-determinando o nmero de nveis da hierarquia de classificao.
Em modelos que no so caracterizados como metamodelos, como o ER, ER-X e OMT, a
hierarquia de classificao possui apenas um nvel, representado pelo relacionamento
implcito entre tipo e instncia. Em metamodelos, como o modelo relacional e o ODMG,
os relacionamentos, tambm implcitos, entre meta tipo e tipo, e entre tipo e instncia
definem uma hierarquia de dois nveis.
O modelo SIRIUS, no entanto, oferece suporte a hierarquias de classificao de mltiplos
nveis, representando a classificao explicitamente, atravs de um construtor semntico
dedicado a representar objetos e tipos de objetos. Como a classificao um conceito j
presente em bases de dados, o novo construtor integra-se ao uso que vem sendo feito dessa
abstrao.
Os objetos, como citado anteriormente, so caracterizados atravs de atributos. O suporte
abstrao de classificao divide os atributos em dois tipos: atributos de instanciao, que
representam as propriedades e os mtodos do objeto propriamente dito, e atributos de
classificao, que caracterizam o objeto como um tipo, definindo os atributos das
instncias desse tipo.
45
Os atributos de classificao de um tipo de objeto determinam as propriedades comuns de

suas instncias, que formam um conjunto de objetos estruturalmente idnticos. Logo, um
tipo de objeto pode ser instanciado em um objeto, que por sua vez pode ser instanciado em
outro objeto, e assim sucessivamente. Esse processo define a hierarquia de classificao de
mltiplos nveis, onde o nmero mximo de nveis determinado pela semntica da
aplicao.
A Figura 10 apresenta uma representao do construtor da classificao. Um objeto
representado por um retngulo dividido por uma linha horizontal. Na parte inferior
colocado o nome do objeto e na parte superior, do lado esquerdo, colocado o nome do
tipo do objeto. No lado direito da parte superior colocado o nome do tipo da colnia onde
habitam as instncias do objeto representado. Quando o campo do tipo de colnia
deixado em branco, subentende-se que as instncias do objeto habitam uma colnia do tipo
Global. Os atributos de classificao so representados acima do retngulo que representa
o objeto, enquanto os atributos de instanciao so representados logo abaixo do mesmo.
a)
(1) Ttulo
1 Autor
(2) Edio
2 Ano
(3) Nro Cpia
3 Emprestado Para
Livro
Livro
(1) Nro C pia

1 Emprestado Para
Bases de Dados
Bases de Dados
2a Edio
Ano: 1995
1 Ano
(2) Nro Cpia
2 Emprestado Para
Bases de Dados
Meta Tipo
c)
(1) Edio
b)
Autor: Jos Silva
d)
Bases de Dados
2a Edio
BD2a_001
Emprestado Para:
Joo Silva
Figura 10 - Exemplo da Abstrao de Classificao
Para exemplificar uma ocorrncia da classificao numa situao real, ser considerado um
sistema de informao de uma biblioteca, onde cada ttulo de livro pode ter vrias edies
e cada edio pode ter vrias cpias. Isso significa que o conceito de Livro instanciado
em Ttulo, Ttulo instanciado em Edio e Edio instanciado em Cpia. Como
Livro instncia de Meta-Tipo (definido pelo sistema), define-se uma hierarquia de
quatro nveis, como ilustrado na Figura 10. As Figuras 10a, 10b, 10c e 10d representam,
respectivamente, o objeto Livro como uma instncia de Meta-Tipo, o ttulo Bases de
46
Dados como instncia de Livro, Bases de Dados 2a Edio como instncia de

Bases de Dados, e BD2a_001 como instncia de Bases de Dados 2aEdio.
Um requisito fundamental para o conceito de classificao em mltiplos nveis um objeto

do esquema da base de dados assumir os papis de tipo e instncia. Por exemplo, o objeto
Bases de Dados instncia de Livro e tipo de Bases de Dados 2a Edio.
Os atributos de classificao definem um template para instanciar um tipo de objeto, ou

seja, definem as caractersticas estruturais e de comportamento das instncias do tipo de
objeto em cada nvel da hierarquia de classificao e o nmero de nveis que podem ser
criados a partir desse tipo. Na representao grfica da classificao, o nmero que precede
o atributo indica o nvel onde o atributo ser instanciado, tornando-se um atributo de
instanciao.
No exemplo da Figura 10, o nmero 2 antes do atributo Ano do objeto Livro indica que
este atributo ser instanciado no segundo nvel de instanciao, recebendo o valor 1995
como um atributo de instanciao do objeto Bases de Dados 2a Edio. O nmero
entre parnteses indica que o atributo identificador das instncias no respectivo nvel. No
exemplo, o atributo Ttulo do objeto Livro identifica as instncias do primeiro nvel de
instanciao de Livro. Portanto, Bases de Dados o valor do atributo Ttulo nessa
instncia de Livro.
A abstrao de classificao envolve ainda conceitos como atributo fixo, atributo extra e
valor default. Um atributo de classificao fixo de um tipo de objeto ser um atributo fixo,
de classificao ou de instanciao (dependendo do nvel), das instncias desse tipo, e
assim sucessivamente por toda a hierarquia. Por exemplo, na Figura 10 o atributo
Emprestado Para um atributo fixo de nvel 3, e portanto est presente em todos os
nveis da hierarquia.
O suporte a atributo extra um recurso importante para a classificao em mltiplos
nveis. Os atributos extras permitem que novos atributos, tanto de classificao quanto de
instanciao, sejam includos em qualquer nvel da hierarquia. Deste modo, um atributo
extra pode ser vinculado a um objeto mesmo que no esteja previsto em seu tipo. Na
Figura 10a, todos os atributos de Livro so atributos extras, pois o objeto Meta-Tipo
no tem esses atributos definidos.
47
A Figura 11 apresenta uma extenso ao exemplo da Figura 10 para ilustrar o conceito de

atributo extra utilizado num nvel intermedirio da hierarquia de classificao. Supondo
que o livro Bases de Dados passe a ter um CD complementar a partir da 3a edio, e
que esse CD possa ser emprestado separadamente, o objeto Bases de Dados 3aEdio
passa a ter um atributo CD Emprestado Para, que no existe em Bases de Dados
2aEdio e que no foi previsto em Bases de Dados.
a)
b)
(1) Nro Cpia
1 Emprestado Para
1 CDEmprestado Para: ningum
Bases de Dados
Bases de Dados
3a Edio
Ano: 2000
Bases de Dados
3a Edio
BD3a__001
Emprestado Para: Joo Silva
CD Emprestado Para:
Maria Silva
Figura 11 Exemplo de atributo extra na hierarquia de classificao
Em 11a, o conceito de valor default ilustrado atravs da atribuio do valor ningum

para o atributo de classificao CD Emprestado Para, indicando que esse valor ser
atribudo a CD Emprestado Para quando Bases de Dados 3a Edio for
instanciado. Em 11b, um novo valor atribudo a este atributo (Maria Silva), seguindo
o princpio de que um valor default carimbado ao atributo quando o tipo de objeto
instanciado, mas pode ser alterado nas instncias individualmente, sem que isso afete o
tipo de objeto ou outras instncias. Da mesma forma, se um valor default alterado num
tipo de objeto, as instncias j existentes no sofrem alterao alguma, pois o novo valor
default s afetar as instncias criadas aps sua alterao. Note-se que valor default
diferente de valor herdado, presente na abstrao de generalizao. O valor herdado pelas
instncias de um sub-tipo no pode ser alterado, e se esse valor for modificado no supertipo, a alterao dever ser propagada por toda a hierarquia de generalizao.
Algumas outras propriedades so definidas quando um atributo de classificao criado,
como por exemplo: determinar se o atributo definido, indefinido ou nulo, ou seja, se o
atributo deve assumir um valor, ou se pode permanecer sem valor definido ou assumir o
valor nulo.
48

Neste captulo so apresentadas as principais caractersticas do modelo SIRIUS,
enfatizando o suporte abstrao de classificao atravs de um construtor semntico
dedicado a representar explicitamente o conceito de hierarquia de classificao em
mltiplos nveis. No objetivo deste trabalho apresentar uma discusso exaustiva do
SIRIUS, uma vez que descries detalhadas de todos conceitos pertinentes ao modelo, tais
como formalismo matemtico, fundamento terico, notao e exemplos podem ser
encontrados em [Araujo_98a ] [Biajiz_96a] [Ferreira_96] [Machado_00].
O captulo seguinte discute como as abstraes aqui apresentadas so tratadas na API do
Gerenciador SIRIUS.
49
5 API SIRIUS
5 API do Gerenciador SIRIUS
5.1 Introduo
O sistema SIRIUS, como citado no Captulo 3, vem sendo desenvolvido pelo Grupo de
Banco de Dados e Imagens do ICMC-USP com o objetivo de oferecer suporte aplicao
de resultados das atividades de pesquisa cientfica do grupo.
A origem do sistema SIRIUS remota construo do GErenciador de Objetos - GEO
[Traina_91], cuja implementao teve como base os conceitos do modelo de dados MRO Modelo de Representao de Objetos [Biajiz_92] [Traina_92]. O sistema GEO/MRO foi
criado como uma "bancada de experimentao" para o desenvolvimento de algoritmos e
tcnicas que contribussem para a criao de SGBDOOs eficientes e confiveis. A
experincia e o conhecimento adquiridos nesse processo levaram definio do modelo
SIRIUS, descrito no Captulo 4, a partir do qual iniciou-se o desenvolvimento do sistema
SIRIUS, mais especificamente do Gerenciador de Objetos SIRIUS, descrito na seo 5.2.
Aplicao
Centrada em
SGBD Relacional
Aplicao Centrada em
Gerenciador SIRIUS
Gerenciador
Relacional
Projeto Fsico segundo

o Modelo Relacional
Projeto Fsico segundo

o Modelo SIRIUS
Tcnicas de
Desenvolvimento
SIRIUS
Especificao
da Aplicao
Gerenciador de
Objetos SIRIUS
Modelo
SIRIUS
Sistema SIRIUS
Figura 12 - Sistema SIRIUS
O sistema SIRIUS, ilustrado na Figura 12, consta ainda de um conjunto de Tcnicas de

Desenvolvimento a serem utilizadas nas fases de projeto lgico e fsico de sistemas
centrados em bases de dados. As Tcnicas de Desenvolvimento SIRIUS encontram-se em
fase inicial de desenvolvimento. O modelo SIRIUS, elemento central do sistema, foi
50
5 API SIRIUS
concebido para suportar atividades de projeto de aplicaes apoiadas em bases de dados e

o Gerenciador SIRIUS vem sendo desenvolvido para suportar tais aplicaes. importante
enfatizar que no se pretende que a implementao de aplicaes projetadas atravs das
Tcnicas de Desenvolvimento SIRIUS fique restrita ao Gerenciador SIRIUS. Por outro
lado, pretende-se que o SIRIUS possa oferecer suporte a aplicaes em geral, independente
da tcnica de projeto utilizada.
O sistema, devido a suas caractersticas, constitui uma plataforma adequada ao
desenvolvimento de uma interface de programao de aplicativos, que o objetivo deste
captulo. Nesse sentido, a API foi construda visando emular um gerenciador de dados
SIRIUS, tendo por suporte um gerenciador de dados relacional.
5.2 Gerenciador de Objetos SIRIUS

O gerenciador de objetos essencial para o sistema SIRIUS, pois propicia o suporte
necessrio para desenvolvimento, teste e validao de algoritmos e tcnicas de projeto.
Como a disponibilidade de um gerenciador de objetos de fundamental importncia para a
consolidao do sistema, duas verses do Gerenciador SIRIUS vm sendo elaboradas: uma
verso nativa e uma verso relacional. Ambas as verses so compostas por dois
componentes principais: um Ncleo e um conjunto de Mdulos Semnticos. Em qualquer
uma de suas verses, o Gerenciador de Objetos SIRIUS possui uma interface de
programao de aplicativos, chamada de API SIRIUS, responsvel pela comunicao entre
o gerenciador e aplicaes centradas no modelo de dados SIRIUS.
A verso nativa baseada em um ncleo desenvolvido especificamente para o suporte a
gerenciadores de objetos, responsvel por operaes de alocao de espao para objetos,
gerenciamento de espao em memria principal e memria secundria, transferncia de
objetos de e para memria principal, gerenciamento de identificadores de objetos, controle
de transaes, garantia de segurana fsica e controle de concorrncia em registros
[Valncio_00].
A Figura 13 apresenta a arquitetura em camadas do ncleo nativo do gerenciador de
objetos. A camada superior, o Subsistema de Gerenciamento de Atributos (SG-Atr),
oferece suporte manipulao de atributos estruturados (tuplas e listas), suporte a
estruturas de ndices sobre estes atributos, suporte a objetos extensos no estruturados
51
5 API SIRIUS
(BLOBs) e objetos compostos. A camada intermediria, SG-Log, responsvel pela

alocao, coeso e recuperao de espaos contnuos em registros fsicos. Na camada
inferior, o Subsistema de Gerenciamento de Transaes realiza o controle das transaes
executadas durante a utilizao do Gerenciador SIRIUS. Esta camada tambm
responsvel pelas operaes de controle de acesso e alocao de espao fsico em memria
secundria.
Interface de Programao de Aplicativos - API
Nvel
Semntico
Mdulos Semnticos
N c l e o
Subsistema de Gerenciamento de Atributos

Tupla
Lista
ndice
SG-Atr
Blob
Composio
Subsistema de Gerenciamento de
Registros Lgicos
SG-Log
Subsistema de Gerenciamento de
Transaes
SG-Tran
Figura 13 - Gerenciador SIRIUS com ncleo nativo
Os Mdulos Semnticos, construdos sobre o ncleo do gerenciador, implementam a lgica

de todos os construtores semnticos do modelo SIRIUS. A interface superior dos Mdulos
Semnticos constitui a interface de programao de aplicativos (API) do Gerenciador
SIRIUS.
A verso nativa eficiente e pode suportar os conceitos do modelo SIRIUS mais ampla e
adequadamente, apresentando tempo de resposta muito satisfatrio. Atualmente, existe um
prottipo do gerenciador nativo [Valncio_00], porm a implementao completa deste
gerenciador, abrangendo todos os recursos do modelo SIRIUS, uma tarefa complexa e
requer ainda muito tempo de desenvolvimento.
O ncleo nativo do Gerenciador SIRIUS genrico e independente do modelo de dados
adotado, podendo ser utilizado para suportar os conceitos de outros modelos de dados
orientados a objetos [Valncio_00]. A semntica do modelo de dados conhecida e tratada
apenas no nvel semntico do gerenciador de objetos. O ncleo otimizado para o suporte
a abstraes de objetos. Logo, o suporte a partir de modelos que no seguem o paradigma
de orientao a objetos provavelmente no seria to eficiente como o suporte dado por um
ncleo especificamente construdo para suportar as abstraes do modelo alvo.
52
5 API SIRIUS
A verso sobre ncleo relacional
possui a arquitetura apresentada na Figura 14,
baseada em um ncleo que utiliza um gerenciador relacional padro SQL. Essa verso
oferece o suporte bsico aos mdulos semnticos do modelo SIRIUS e, embora no seja
to eficiente quanto a verso nativa, j possui um prottipo operacional, resultante deste
trabalho. Um ponto importante a ser considerado aqui que a tcnica utilizada para a
implementao realizada permite emular construes semnticas oriundas de um modelo
orientado a objetos ( e suas respectivas abstraes) em um modelo muito mais simples,
como o caso do modelo relacional.
Interface de Programao de Aplicativos - API
Mdulos Semnticos
Nvel
Semntico
SGBD
Relacional
Figura 14 - Gerenciador SIRIUS com ncleo relacional
A verso relacional teve seu desenvolvimento iniciado atravs de uma ferramenta de

representao e armazenagem de modelagens baseadas no modelo SIRIUS, utilizado um
2
gerenciador relacional como repositrio de dados. Esta ferramenta, chamada de E SIRIUS

(Editor de Esquemas SIRIUS) [Araujo_98a] [Araujo_98b], foi projetada para suportar
tipos persistentes e tratamento homogneo de objetos e tipos de objetos em tempo de
execuo. Este fator primordial para a definio de hierarquias de classificao de
mltiplos nveis, uma vez que a maioria das linguagens de programao tratam tipos
2
apenas em tempo de compilao. Neste trabalho, o E SIRIUS foi reformulado, tornando-se

um aplicativo de edio de modelagens que utiliza apenas as primitivas da API do
Gerenciador SIRIUS para acessar a base de dados, em qualquer uma das verses do
gerenciador. Todo o cdigo de acesso direto base de dados relacional desenvolvido para
a verso original do Editor de Esquemas foi removido, e as clusulas SQL contidas nesse
cdigo foram utilizadas como ponto de partida para o desenvolvimento da verso
relacional do Gerenciador SIRIUS. A API definida para o Gerenciador SIRIUS, assim
como o prottipo da verso relacional do gerenciador, so descritos nas sees seguintes.
53
5 API SIRIUS
O que se pretende com a verso sobre ncleo relacional disponibilizar uma bancada
experimental para a elaborao de algoritmos, tcnicas de desenvolvimento e extenses
para suporte a aspectos ainda no tratados, possibilitando a definio de alternativas
adequadas para uma implementao mais eficiente na verso nativa.
5.3 API SIRIUS

A API SIRIUS [Sousa_00] compatvel com as verses nativa e com ncleo relacional do
Gerenciador SIRIUS. Como ilustrado nas Figura 13 e 14, uma API nica est definida
para ambas as verses do gerenciador de objetos, permitindo que aplicativos utilizem
indistintamente qualquer uma das verses, sem que sejam necessrias alteraes no cdigo
fonte da aplicao.
5.3.1 Definio da API
A API do Gerenciador de Objetos SIRIUS definida como um conjunto de classes que,
integradas, compem os mdulos semnticos do gerenciador. Cada uma das classes
representa um ou mais elementos sintticos do modelo SIRIUS.
Neste trabalho, foram implementadas classes representando os elementos objeto, tipo de
objeto, atributo, colnia e tipo de colnia, como apresentado na Tabela 3.
Elemento Sinttico
Classe da API
Objeto e Tipo de Objeto
SiriusObject
Atributo
SiriusAttribute
Colnia
SiriusColony
Tipo de Colnia
SiriusColonyType
Tabela 3 - Correspondncia entre Elemento Sinttico e Classe da API
O modelo SIRIUS oferece suporte a 15 caractersticas de atributos [Araujo_98a], como

descrito no Captulo 4. As particularidades de cada caracterstica so tratadas na API
atravs de classes derivadas da classe SiriusAttribute, devendo ser definida uma
classe para cada caracterstica. No escopo deste trabalho, foram criadas classes especficas
54
5 API SIRIUS
para as caractersticas Texto, Nmero e Atributo de Atributo. A Tabela 4 apresenta as

classes correspondentes s caractersticas citadas acima.
Caracterstica de Atributo
Classe da API
Texto
SiriusAttribText
Nmero
SiriusAttribNumber
Atributo de Atributo
SiriusAttribAttrib
Tabela 4 - Correspondncia entre Caracterstica de Atributo e Classe da API
A API oferece suporte consulta e recuperao de conjuntos de objetos, atributos e

colnias, assim como de seus respectivos tipos. Os critrios de busca que podem ser
utilizados numa consulta so simples e diretos, destacando-se busca de objetos por tipo e
por colnia que habitam, busca de objetos por igualdade de valor de atributo, busca de
atributos de um objeto e busca de colnias por tipo. Uma primitiva de busca seleciona
todos os objetos que satisfazem o critrio de busca e armazena seus OIds numa estrutura
interna API. Como a interface desenvolvida destina-se ao uso em programao (em
linguagem C ou C++), o paradigma adotado o navegacional. O conjunto de objetos
recuperados percorrido por um cursor, e os objetos so passados um a um para a
aplicao.
A Tabela 5 apresenta as classes criadas para consultas que manipulam
conjuntos.
Elementos Recuperados
Classe da API
Objetos e Tipos de Objeto
SiriusObjectCursor
Atributos
SiriusAttributeCursor
Colnias e Tipos de Colnia
SiriusColonyCursor
Tabela 5 - Correspondncia entre Conjunto Recuperado e Classe da API
As classes definidas para a API compem alguns dos mdulos semnticos do Gerenciador
SIRIUS: Mdulo Objeto, Mdulo Atributo Texto, Mdulo Atributo Nmero, Mdulo
Atributo de Atributo e Mdulo Colnia. Esses mdulos implementam a semntica das
55
5 API SIRIUS
abstraes de classificao, composio e agregao (agregao de atributo a objeto e

agregao de atributo a atributo). A composio de cada um dos mdulos semnticos
apresentada na Tabela 6.
Mdulo Semntico
Classes da API
Mdulo Objeto
SiriusObject
SiriusObjectCursor
SiriusAttribute
Mdulo Atributo Texto
SiriusAttribText
Mdulo Atributo Nmero
SiriusAttribute
SiriusAttribNumber
Mdulo Atributo de Atributo
SiriusAttribute
SiriusAttribAttrib
Mdulo Colnia
SiriusColony
SiriusColonyType
SiriusColonyCursor
Tabela 6 - Composio dos Mdulos Semnticos
A classe SiriusObject a principal classe da API, e portanto constitui a base para as

demais. As instncias ou objetos dessa classe so representaes em memria de objetos de
uma base de dados SIRIUS. Para que o uso do termo objeto no fique confuso, os
objetos da base SIRIUS sero chamados de objetos-sirius, e os objetos ou instncias da
classe SiriusObject criados em memria sero chamados de sobrestantes1 objeto.
importante ressaltar que criar um sobrestante objeto atravs do construtor da classe
SiriusObject no implica em criar um objeto-sirius. Quando um sobrestante objeto
criado, sua estrutura interna inicializada de forma a preparar o sobrestante para a criao
de um novo objeto-sirius (mtodo CreateObject), ou para a leitura de um objeto-sirius
armazenado na base de dados (mtodo ReadObject).
1
O termo sobrestante utilizado com o mesmo significado do termo handler

56
5 API SIRIUS
A operao de criao de objetos-sirius ortogonal para tipos e instncias, o que permite

que a aplicao crie, da mesma maneira, tipos e instncias, em tempo de execuo. As
demais operaes implementadas nas classes SiriusObject e SiriusObjectCursor
tambm so ortogonais para tipos e instncias, permitindo que objeto-sirius, tipos ou no,
sejam manipulados atravs de um mesmo conjunto de mtodos. Esse tratamento
homogneo de tipos e instncias imprescindvel para o suporte classificao em
mltiplos nveis, onde tipos e instncias existem e podem ser criados em tempo de
execuo. Consequentemente, operaes que usualmente so separadas em DDL e DML
so unificadas num conjunto nico de comandos.
Todo novo objeto-sirius criado, por default, como transiente, podendo ser declarado
explicitamente como persistente atravs do mtodo SetAsPersistent. Quando lido da
base para a memria, o objeto-sirius automaticamente declarado persistente. Embora
objetos-sirius transientes sejam manipulados de maneira semelhante a objetos-sirius
persistentes, somente objetos-sirius persistentes possuem OIds, gerados automaticamente
pelo Gerenciador SIRIUS quando o objeto-sirius declarado persistente.
Uma aplicao que utiliza a API SIRIUS pode acessar um objeto-sirius armazenado na
base atravs de seu OId ou atravs do seu nome e do nome de seu tipo. O mtodo
ReadObject sobrecarregado, permitindo as duas formas de acesso citadas acima. O
acesso a objetos-sirius restrito a colnias abertas, isto , a aplicao somente tem acesso a
objetos-sirius que habitam suas colnias abertas. A classe SiriusColony possui o
mtodo OpenColony, que explicitamente abre uma colnia para a aplicao. Uma
instncia da classe SiriusColony, chamada de sobrestante colnia, representa em
memria as informaes de uma colnia definida na base de dados. Cada colnia
acessada pela aplicao atravs do nome de seu tipo e do OId do objeto-sirius que a
constringe. Assim como na classe SiriusObject, criar um sobrestante colnia no
significa criar uma colnia, pois a classe SiriusColony tambm possui um mtodo
dedicado a essa operao: CreateColony.
A classe SiriusColonyType oferece suporte criao da hierarquia de tipos da
abstrao de composio, definida atravs do DHC, descrito no Captulo 4. A aplicao
tem acesso s informaes de um tipo de colnia atravs de seu nome. Os tipos de colnia
57
5 API SIRIUS
so representados em memria por instncias da classe SiriusColonyType, chamadas

sobrestantes tipo de colnia.
A classe SiriusAttribute destina-se ao tratamento de atributos quando no se conhece,
a priori, a caracterstica do atributo. Os mtodos dessa classe tm como funcionalidade
principal o acesso a informaes do esquema associadas s abstraes de classificao e
agregao.
Por
exemplo,
os
mtodos
GetClassificationInfo
GetAggregationInfo recuperam, respectivamente, as propriedades da classificao e
de agregao, como descritas no Captulo 4. As classes derivadas de SiriusAttribute

so utilizadas para a manipulao de atributos cujas caractersticas so conhecidas, e
portanto oferecem o suporte adequado aos valores dos atributos.
As instncias da classe SiriusAttribute e de suas derivadas so chamadas de
sobrestantes atributo. Ao contrrio do que ocorre nas demais classes, a criao de um
sobrestante atributo implica na criao de um atributo. No entanto, o atributo s pode ser
vinculado ao objeto-sirius atravs do mtodo AddAttribute da classe SiriusObject.
Existe ainda a classe SIRIUS, que disponibiliza um conjunto de mtodos para iniciar e
finalizar uma conexo com a base de dados, e para iniciar e finalizar (commit ou abort)
transaes.
O tratamento de erros realizado atravs da classe SiriusError, que utiliza uma
abordagem semelhante ao tratamento de excees oferecido pela biblioteca padro C++
(exception handling). Nessa abordagem, a aplicao pode verificar a ocorrncia de erros
por blocos de comando, utilizando por exemplo comandos try e catch da linguagem C++.
O exemplo a seguir ilustra como os mtodos da API podem ser utilizados para manipular
informaes modeladas a partir do modelo SIRIUS e armazenadas numa base de dados
SIRIUS. A Figura 15 exemplifica uma modelagem de objetos que utiliza a notao grfica
adotada para o modelo de dados em questo. Em 15a, o DHC define que o tipo de objetosirius Biblioteca constringe o tipo de colnia CBibl, em cujas instncias (colnias) vo
habitar objetos-sirius dos tipos Livro e Peridico. Em 15b, o objeto-sirius Prof.
Achille Bassi, do tipo Biblioteca, constringe uma colnia do tipo CBibl onde
habitam os objetos-sirius Transactions
in
Computer
Science, Computer
Networks e 3rd Edition, dos tipos Peridico, Livro e Computer Networks,

58
5 API SIRIUS
respectivamente. A Figura 15c ilustra duas hierarquias de classificao: uma de dois

nveis, composta por Biblioteca e Prof. Achille Bassi, e outra de trs nveis,
criada pelos objetos-sirius Livro, Computer Networks e 3rd Edition.
a) DHC
b) DRI
Global
Meta Tipo Global

Bibliotec a
Biblioteca
Prof. Achille B as si
CBibl
Meta Tipo CBibl

Livro
Livro
Pe ridico
CBibl
Com puter
Networks
Transactions in
Com puter Science
Meta Tipo CBibl

Peridico
Com puter
Networks
CBibl
3rd Edition
c)
(1)Tx Ttulo
(1)Tx Nom e
Meta Tipo Global

Biblioteca
1 Nu Ano
2 Nu Ano
(2)Tx Edio
1 Tx Instituio: USP
Bibliotec a
Prof. Achille B as si
Meta Tipo CBibl

Livro
(1)Tx Edio
Livro
CBibl
Com puter
Networks
Com puter
Networks
CBibl
3rd Edition
Ano: 1996
Instituio:
ICMC/US P
Figura 15 - Exemplo de Modelagem SIRIUS
O objeto-sirius Biblioteca do tipo Meta Tipo e habita a colnia do tipo Global, que
est sempre aberta para a aplicao. Portanto, Biblioteca pode ser o primeiro objetosirius a ser criado. Na criao de Biblioteca, METATYPE e GLOBAl so palavras prdefinidas na API para o Meta Tipo (que tipo de Biblioteca) e para o tipo de colnia
Global (que o tipo de colnia onde vo habitar as instncias de Biblioteca). O
mtodo SetAsPersistent torna o objeto-sirius persistente e retorna o OId gerado. O

tipo de dado SOID definido na API para armazenar os OIds dos objetos-sirius da base de
dados. Note-se que todos os tipos definidos na API tm seus nomes iniciados pela letra S,
de SIRIUS.
SOID bibOId;
SiriusObject *vBiblioteca = new SiriusObject;
vBiblioteca->CreateObject( Biblioteca, METATYPE, GLOBAL);
bibOId = vBiblioteca->SetAsPersistent(
);
59
5 API SIRIUS
O atributo Nome criado como atributo fixo identificador no nvel de instanciao 1,

mono-valorado, definido e sem valor default. O mtodo AddAttribute vincula o atributo
ao objeto-sirius Biblioteca. Para tratar as propriedades de classificao e agregao, a
API possui palavras pr-definidas escritas em letras maisculas, como IDENTIFIER,
DEFINED, FIX, entre outras. Todos os termos e tipos definidos na API e exportados
para as aplicaes so descritos em Anexo.

SClassification class; // propriedades da classificao
SAggregation agreg;
// propriedades da agregao
SiriusAttribText *vNome = new SiriusAttribText( Nome );

class.level = 1;
// nvel de instanciao
class.id = IDENTIFIER;
// identificador
class.def = DEFINED;
// definido
class.dflt = NON-DEFAULT;
// sem valor default
class.fix = FIX;
// fixo
agreg.org = MONOVALUED;
// mono-valorado
agreg.lBound = 1;
// Lower Bound mnimo de 1 valor
agreg.uBound = 1;
// Upper Bound mximo de 1 valor
vBiblioteca->AddAttribute( vNome, class, agreg );
O atributo Instituio criado como atributo fixo, no identificador, de nvel de

instanciao 1, mono-valorado, definido e com valor default. O mtodo SetValue insere
o valor USP para o atributo.
SiriusAttribText *vInst =
new SiriusAttribText( Instituio );
class.level = 1;
class.id = NON-IDENTIFIER;
class.dflt = DEFAULT;
class.fix = FIX;
agreg.lBound = 1;
agreg.uBound = 1;
vInst->SetValue( USP );
vBiblioteca->AddAttribute( vInst, class, agreg );
60
5 API SIRIUS
O objeto-sirius Prof. Achille Bassi, do tipo Biblioteca, habita a colnia do tipo

Global. Este objeto-sirius est no ltimo nvel da hierarquia, ou seja, no possui
instncias, e portanto no possui tipo de colnia definido para instncias. Neste caso, o
mtodo CreateObject chamado apenas com os parmetros de nome e tipo do objetosirius. Os atributos definidos em Biblioteca so criados implicitamente para sua
instncia. As propriedades de classificao e agregao so preservadas, alterando-se
apenas o nvel de instanciao, que decrementado. O valor default USP pode ser alterado
em Prof. Achille Bassi, como ilustrado na modelagem. Para tanto, o mtodo
GetAttribute habilita o acesso ao atributo Instituio atravs do sobrestante
vAttrib, e o mtodo UpdateValue altera o valor default para ICMC-USP. Note-se que
mesmo antes do objeto-sirius ser declarado como persistente, possvel manipular os

valores dos atributos. Como citado anteriormente, objetos-sirius transientes so tratados de
maneira semelhante a objetos-sirius persistentes. Algumas operaes, entretanto, esto
restritas a objetos-sirius persistentes, como criao e remoo de atributos.
SOID bassiOId;
SiriusAttribText *vAttrib;
SiriusObject *vBassi = new SiriusObject;
vBassi->CreateObject( Prof. Achille Bassi, Biblioteca );
vAttrib = vBassi->GetAttribute( Instituio );
vAttrib->UpdateValue( USP, ICMC/USP );
bassiOId = vBassi->SetAsPersistent(
);
O passo seguinte definir o tipo de colnia CBibl, constrito pelo objeto-sirius

Biblioteca, cujo OId bibOId (gerado no incio do exemplo).
SiriusColonyType *vCBibl = new SiriusColonyType;
vCBibl->CreateColType( CBibl, bibOId);
Criado o tipo de colnia CBibl, possvel criar uma colnia deste tipo constrita pelo
objeto-sirius Prof. Achille Bassi, representado no sobrestante vBassi.
SiriusColony *vColony = new SiriusColony;
vColony->CreateColony( CBibl, vBassi );
61
5 API SIRIUS
delete vColony;
A linha de cdigo delete
vColony invoca o mtodo destrutor da classe
SiriusColony, que apenas libera o espao em memria anteriormente alocado para o
sobrestante colnia, no tendo efeito algum sobre a colnia j criada na base de dados. Os
destrutores das demais classes atuam da mesma forma, havendo uma pequena diferena no
destrutor da classe SiriusObject, j que se um sobrestante objeto for removido, o
objeto-sirius correspondente s existir na base se for persistente. As classes da API
definem mtodos especficos para a remoo de elementos da base SIRIUS, como por
exemplo, DeleteObject da classe SiriusObject.
Retornando ao exemplo da modelagem, o objeto-sirius Livro, cujo tipo Meta Tipo,
habita a colnia do tipo Global e define CBibl como o tipo de colnia onde vo habitar
suas instncias. De maneira anloga criao de Biblioteca, as linhas de cdigo a
seguir criam o objeto-sirius Livro.
SOID livroOId;
SiriusObject *vLivro = new SiriusObject;
vLivro->CreateObject( Livro, METATYPE, CBibl );
livroOId = vLivro->SetAsPersistent(
);
O atributo Ttulo criado como atributo fixo identificador no nvel de instanciao 1,

mono-valorado, definido e sem valor default.
SiriusAttribText *vTtulo = new SiriusAttribText( Ttulo );
class.level = 1;
class.fix = FIX;
agreg.lBound = 1;
agreg.uBound = 1;
vLivro->AddAttribute( vTtulo, class, agreg );
62
5 API SIRIUS
O atributo Edio criado como atributo fixo identificador no nvel de instanciao 2,

SiriusAttribText *vEdio = new SiriusAttribText( Edio );
class.level = 2;
class.fix = FIX;
agreg.lBound = 1;
agreg.uBound = 1;
vLivro->AddAttribute( vEdio, class, agreg );
O atributo Ano criado como atributo fixo, no identificador, de nvel de instanciao 2,

SiriusAttribNumber *vAno = new SiriusAttribNumber( Ano );
class.level = 2;
class.id = NON-IDENTIFIER;
class.fix = FIX;
agreg.lBound = 1;
agreg.uBound = 1;
vLivro->AddAttribute( vAno, class, agreg );
Para criar as instncias de Livro preciso abrir uma colnia do tipo CBibl. O mtodo
OpenColony abre a colnia criada anteriormente.
vColony->OpenColony( CBibl, vBassi );
As linhas de cdigo seguintes criam os objetos-sirius Computer Networks e 3rd

Edition. Os comandos try e catch ilustram a utilizao da classe SiriusError.
63
5 API SIRIUS
try
{
SOID cnOId, edOId;
SiriusObject *vCN = new SiriusObject;
vCN->CreateObject(Computer Networks,Livro,CBibl );
cnOId = vCN->SetAsPersistent(
);
SiriusAttribNumber *vAttrib;
SiriusObject *vEd = new SiriusObject;
vEd->CreateObject( 3rdEdition, Computer Networks );
edOId = vEd->SetAsPersistent(
);
vEd->GetAttribute( Ano );
vAttrib->SetValue( 1996 );
}
catch ( SiriusError erro )
printf( Erro: %s , erro.GetMessage( ) );
Para exemplificar a utilizao de mtodos de consulta, dois tipos de busca podem ser
considerados:
Buscar todos os ttulos de livros da biblioteca Prof. Achille Bassi. Como as
instncias de Livro habitam colnias do tipo CBibl, necessrio abrir a colnia
constrita por Prof. Achille Bassi, pois como j foi dito anteriormente, os
mtodos da API s tm acesso a objetos-sirius de colnias abertas para a aplicao.
Quando a aplicao requisita que uma colnia seja aberta, o mtodo OpenColony
fecha qualquer outra colnia do mesmo tipo que estiver aberta, pois SIRIUS define que
apenas uma colnia de cada tipo pode estar aberta simultaneamente para a aplicao.
O mtodo SearchObject sobrecarregado na classe e faz a busca segundo o critrio
especificado nos parmetros. Todos os OIds recuperados na consulta so armazenados e
percorridos atravs do cursor controlado no mtodo EndOfObjects. O mtodo
GetObject retorna para a aplicao o OId apontado pelo cursor.
vColony->OpenColony( CBibl, vBassi );
SOID objId;
64
5 API SIRIUS
SiriusObjectCursor *buscaObj = new SiriusObjectCursor;

buscaObj->SearchObj( livroOId );
while ( !buscaObj->EndOfObjects( ) )
{
objId = buscaObj->GetObject( );
// processa OId
}
Buscar todos os atributos do objeto-sirius Computer
Network. O mtodo
SearchAttribute armazena os atributos do objeto-sirius em sobrestantes atributo,
cujas referncias so retornadas para a aplicao atravs do mtodo GetAttribute. O

mtodo GetName retorna o nome do atributo.
SiriusAttribute *vAtrib;
SString nomeAt;
SiriusAttributeCursor *buscaAt = new SiriusAttributeCursor;
buscaAt->SearchAttribute( vCN );
while ( !buscaAt->EndOfAttributes( ) )
{
vAtrib = buscaAt->GetAttribute( );
nomeAt = vAtrib->GetName( );
printf( Atributo: %s \n, nomeAt );
}
Na seo 2.4, foram discutidas algumas caractersticas consideradas fundamentais na API

de um SGBDOO. A Tabela 1 apresentou uma comparao entre APIs de alguns
SGBDOOs e do padro ODBC. A Tabela 7 utiliza o mesmo conjunto de caractersticas e
mostra se a API SIRIUS suporta ( S ) ou no ( N ) cada uma delas. O smbolo * refere-se a
uma observao a ser feita a respeito da caracterstica. A quarta coluna da tabela descreve
como a caracterstica suportada na API SIRIUS. Para as caractersticas tratadas
explicitamente atravs de mtodos da API, so apresentados o(s) nome(s) do(s) mtodo(s)
e o nome da classe correspondente.
65
5 API SIRIUS
SIRIUS
Startup
Classe: SIRIUS
Mtodo: Connect( ... )
Interface Shutdown
Classe: SIRIUS
Mtodo: Disconnect( ... )
Do
Incio de Transao
Classe: SIRIUS
Mtodo: BeginTransaction( ... )
Sistema
Commit de Transao
Classe: SIRIUS
Mtodo: CommitTransaction( ... )
Abort de Transao
Classe: SIRIUS
Mtodo: AbortTransaction( ... )
Alocao/Desalocao
Classe: SiriusObject
Mtodos: SiriusObject( ... )
~SiriusObject( ... )
Interface
Atribuio/Comparao
a atribuio e comparao de referncias suportada

atravs dos operadores de atribuio ( = ) e
comparao ( == ) da linguagem C++
Persistncia
De
Objetos
Mtodo: SetAsPersistent(... )
Modificao
a verificao de modificao realizada

implicitamente pelo sistema
Recuperao
Mtodo: ReadObject( ... )
Outras
Transaes Elaboradas
Grupos de Objetos
Verses Anteriores
Locks em Objetos
Nomeao de Objetos
os objetos possuem um identificador, ou nome,

definido pelo usurio como o valor do atributo
identificador
Tabela 7 - Caractersticas de API no Gerenciador SIRIUS
66
5 API SIRIUS
Observao:
* Caractersticas no previstas na API, pois ainda no foi definido o suporte a cada uma
delas no Gerenciador de Objetos SIRIUS.
5.3.2 Implementao da API
As classes definidas para a API SIRIUS, com exceo da classe SiriusAttribAttrib,
foram implementadas como uma DLL que exporta os mtodos pblicos destas classes para
a aplicao. A implementao da API compe um conjunto de mdulos semnticos para a
verso com ncleo relacional do Gerenciador de Objetos SIRIUS. A Figura 16 ilustra a
estrutura implementada.
Aplicao
Objeto Atrib.
Texto
Atrib.
Atrib.
Nmero Atrib.
API
Colnia
Mdulos Semnticos
Mdulo de Acesso
aos Dados
SGBD
Relacional
Figura 16 - Estrutura de implementao da API
Um gerenciador de base de dados relacional utilizado como ncleo da verso relacional

do Gerenciador SIRIUS. Acima do SGBD relacional, a camada semntica dividida em
duas sub-camadas principais: um conjunto de Mdulos Semnticos e um Mdulo Acesso
aos Dados. Os Mdulos Semnticos Objeto, Atributo Texto, Atributo Nmero, Atributo de
Atributo e Colnia implementam grande parte dos conceitos e da semntica do modelo de
dados SIRIUS. O Mdulo de Acesso aos Dados implementa todo o cdigo de acesso ao
gerenciador relacional. Essa diviso na camada semntica tem por objetivo isolar todo o
acesso base no Mdulo de Acesso aos Dados, facilitando assim a manuteno do cdigo
de tratamento dos dados e a migrao de um gerenciador relacional para outro, uma vez
que o Mdulo de Acesso aos Dados concentra todo o cdigo que est suscetvel a
alteraes decorrentes do processo de migrao.
67
5 API SIRIUS
O conjunto de clusulas SQL que permitem o acesso aos dados armazenados na base
relacional, na verso da API sobre ncleo relacional, foi gerado a partir das clusulas SQL
2
criadas para a verso original do E SIRIUS, como citado na seo 5.2. Algumas dessas
clusulas foram alteradas para otimizar algumas operaes, mas a essncia da estrutura de
2
tabelas definida no E SIRIUS foi mantida [Araujo_98a].

A classe SiriusObject, como citado na seo anterior, a principal classe da API. Os
membros privados de um sobrestante objeto armazenam as informaes relevantes do
objeto-sirius armazenado na base de dados. A Figura 17 ilustra a estrutura de um
sobrestante objeto, composto pelo OId (OID) e o nome do objeto-sirius (Name), o OId de
seu tipo (Type), o nome da colnia onde o objeto-sirius habita (Colony), o nome do tipo de
colnia onde habitam suas instncias (InstCol), e uma lista dos atributos do objeto-sirius
representado. A lista divide os atributos por caracterstica, onde cada atributo
representado por um sobrestante atributo da classe apropriada. Em cada sobrestante
atributo armazenado o identificador (AtId) e o nome do atributo (AtName), e o(s)
valor(es) assumido(s) por esse atributo.
Object
OID Name Type Colony InstCol Attributes
Text Number AttribAttrib
...
...
Attrib1 Attrib2 Attrib3 ...
AtId
AtNm Value(s)
SiriusAttribText *Attrib1, *Attrib2, *Attrib3, ...
Figura 17 - Estrutura do sobrestante objeto
O OId de um objeto-sirius implementado de maneiras diferentes nas verses nativa e

relacional do Gerenciador SIRIUS, pois o conceito de OId, caracterstico do paradigma de
orientao a objetos, foi emulado num ambiente relacional. Entretanto, a estrutura de
representao do OId utilizada na API compatvel com ambas as verses do gerenciador.
68
5 API SIRIUS
O OId composto por dois campos: um campo address e um campo counter. Na verso
nativa, address armazena do endereo lgico do objeto-sirius e counter armazena o
nmero de vezes que esse endereo foi utilizado por objetos-sirius diferentes, mantendo
assim duas propriedades importantes do OId: a unicidade e a no reutilizao do mesmo
durante toda a existncia da base de dados [Valncio_00]. Na verso relacional, o campo
address perde o sentido, e portanto mantido com valor 0 (zero); o campo counter
gerado automaticamente pelo gerenciador para objetos-sirius declarados persistentes,
mantendo as propriedades citadas acima.
Assim como os objetos-sirius, atributos, colnias e tipos de colnia tambm possuem
cdigos identificadores nicos, gerados pelo gerenciador. Entretanto, a aplicao tem
acesso somente aos OIds dos objetos-sirius; os atributos so identificados atravs de seus
nomes; uma colnia identificada atravs do nome de seu tipo e do OId do objeto-sirius
que a constringe, e o tipo de colnia identificado por seu nome.
O sobrestante objeto possui ainda um flag indicando se o objeto-sirius persistente ou
transiente e, se for transiente, um flag indicando se valores de atributos foram adicionados,
removidos ou alterados, pois quando declarado persistente, o objeto-sirius representado
no sobrestante objeto dever ser criado na base de dados assim como definido no
sobrestante. Quando um objeto-sirius de um determinado tipo criado no sobrestante
objeto, toda a estrutura do sobrestante criada independentemente do novo objeto-sirius
ser persistente ou transiente. Se, por exemplo, o tipo em questo possuir valor default para
algum atributo, o novo objeto-sirius tambm possuir esse valor para o atributo. Porm, se
esse valor for alterado enquanto o objeto-sirius for transiente, essa alterao dever ser
mantida quando o objeto-sirius tornar-se persistente e for criado na base de dados.
As classes que manipulam conjuntos, ou seja, as classes SiriusObjectCursor,
SiriusAttributeCursor e SiriusColonyCursor, so estruturadas como listas
dinmicas encadeadas, e armazenam respectivamente OIds, nomes de atributos e estruturas

de identificao de colnias, compostas pelo nome do tipo da colnia e OId do objetosirius que a constringe. Estas listas so criadas para armazenar os resultados de consultas
na base de dados, como por exemplo: a requisio buscar todos os objetos-sirius de um
determinado tipo resulta numa lista dos OIds de todos os objetos-sirius recuperados na
consulta em questo. As listas possuem um ponteiro, aqui chamado de cursor, que percorre
69
5 API SIRIUS
todos os seus elementos, permitindo que a aplicao recupere um a um todos os elementos

resultantes da consulta.
Como um sobrestante uma representao em memria de um elemento de uma base
SIRIUS, seria possvel criar uma base de dados transiente completa no espao de memria
da aplicao, ou seja, definir em memria hierarquias de tipos correspondentes a cada uma
das abstraes e criar instncias para alimentar essa base transiente em memria,
independentemente dessas informaes tornarem-se ou no persistentes posteriormente.
Entretanto, o suporte a esse conceito aumentaria significativamente a complexidade da
implementao dos mtodos da API, tornado-se invivel no contexto deste trabalho.
Para efeito de demonstrao, o conceito descrito acima foi implementado para a hierarquia
da abstrao de classificao, com a seguinte restrio: todo objeto-sirius, persistente ou
transiente, instncia de um tipo persistente. Assim, visualizando a hierarquia de
classificao como uma rvore, onde o n raiz representado pelo Meta Tipo, todos os
ns folha podem ser transientes, enquanto os intermedirios so obrigatoriamente
persistentes. Considerando ento os ns intermedirios como os tipos definidos na base de
dados, pode-se alimentar toda a base na memria da aplicao. Para tanto, um conjunto
de mtodos da classe SiriusObject trata objetos-sirius transientes e persistentes de
maneira ortogonal. Assim, possvel criar quantos objetos-sirius transientes quantos forem
necessrios, desde que sejam de tipos persistentes. Para objetos-sirius transientes, assim
como para persistentes, possvel consultar informaes como tipo, colnia onde habita,
tipo de colnia das instncias e atributos. Valores de atributos podem ser inseridos,
removidos ou alterados em objetos-sirius transientes, mas h restries quanto s
operaes de insero e remoo de atributos, que somente podem ser efetuadas para
objetos-sirius persistentes.
As atividades de implementao das classes da API foram realizadas em ambiente
Windows, utilizando a ferramenta de desenvolvimento Inprise/Borland C++ Builder. O
gerenciador relacional InterBase (Inprise/Borland) foi utilizado como ncleo da verso
relacional do Gerenciador de Objetos SIRIUS. As clusulas SQL de acesso base de dados
seguem o padro SQL, e portanto tornam a verso relacional do Gerenciador SIRIUS
independente do SGBD relacional utilizado como ncleo.
70
5 API SIRIUS

Este captulo descreve o Gerenciador de Objetos SIRIUS, apresentando a arquitetura e as
principais caractersticas de cada uma de suas verses: a verso com ncleo nativo e a
verso com ncleo relacional. Ambas as verses do gerenciador possuem uma API nica,
chamada de API SIRIUS, que permite que aplicaes utilizem qualquer uma das verses
sem alteraes em cdigo fonte.
A API SIRIUS oferece suporte s abstraes de classificao, composio e agregao,
destacando-se o tratamento homogneo de tipos e instncias inerente hierarquia de
classificao em mltiplos nveis. Este captulo apresenta ainda diversos exemplos para
ilustrar a utilizao de alguns mtodos da API.
71
6 E2SIRIUS
6 Editor de Esquemas SIRIUS
6.1 Introduo
2
O E Sirius [Araujo_98a] [Araujo_98b], embora tenha sido criado com base no modelo
SIRIUS, foi desenvolvido com a finalidade de demonstrar principalmente o suporte a
atributos extras e a hierarquias de classificao em mltiplos nveis, utilizando um
conjunto nico de comandos para o tratamento de tipos e instncias em tempo de
execuo.
2
A verso original do E Sirius incorpora um conjunto de operaes de acesso direto a uma

2
base de dados relacional. Neste trabalho, o E Sirius foi re-implementado, e suas operaes
passaram a utilizar apenas as primitivas da API desenvolvida. Este captulo pretende
apresentar a nova abordagem de implementao do Editor de Esquemas, demonstrando que
a API pode ser utilizada na criao de um utilitrio de bases de dados genrico, como o
2
E Sirius, e portanto vlida para o desenvolvimento de aplicaes em geral centradas em

um gerenciador de dados orientado a objetos.
6.2 Descrio do E2Sirius

2
O E Sirius composto por um conjunto de formulrios grficos agrupados em

subconjuntos que tratam separadamente as abstraes de classificao, agregao,
composio e generalizao. Os formulrios esto interligados, representando o
relacionamento entre as abstraes, que coexistem numa modelagem. Os formulrios do
editor constituem a interface com o usurio, permitindo uma representao coerente e
completa de informaes de acordo com os conceitos propostos no modelo SIRIUS.
O formulrio Object, apresentado na Figura 18, representa o ponto de partida para a
definio de hierarquias das abstraes de dados, e portanto o mais complexo do
72
6 E2SIRIUS
utilitrio. Nesse formulrio, o interador Object, composto pelos campos Object Name,
Object Type e Instances Colony Type definem, respectivamente, o nome do
objeto, seu tipo e o tipo da colnia onde habitam as suas instncias. Para criar um objeto, o
usurio escolhe seu tipo dentre os disponveis em Object Type. Quando a base de dados
criada, existe apenas o tipo Meta Tipo, definido pelo sistema. Logo, o primeiro objeto
criado deve ter esse tipo, iniciando a hierarquia de classificao. Os prximos objetos a
serem criados podem ser de qualquer tipo disponvel, ressaltando que um objeto
considerado tipo quando sua definio inclui atributos de classificao, como descrito no
Captulo 4.
Figura 18 - Formulrio Object do E2SIRIUS
Os OIds dos objetos, gerados automaticamente pelo sistema, compartilham um mesmo

domnio e so utilizados internamente por operaes suportadas pelo editor, de maneira
que todo comando pode ser indistintamente aplicado a objetos e tipos de objetos. O
2
E Sirius no apresenta diferena alguma no tratamento de tipos e instncias, sendo que o

mesmo formulrio permite a criao e visualizao de objetos e tipos de objetos em
qualquer nvel da hierarquia de classificao. Os botes Classify e Instantiate
permitem a navegao por toda a hierarquia.
73
6 E2SIRIUS
A abstrao de agregao tratada por um subconjunto de formulrios acionados atravs

dos botes + Attribute e Attribute, que disponibilizam respectivamente as
operaes: de criao de atributos para o objeto, definindo propriedades de classificao e
agregao; e de remoo de atributos do objeto. A atribuio de valores default a atributos
de classificao feita atravs do boto Edit Value, no interador Classif. Attrib.,
enquanto a atribuio de valores a atributos de instanciao realizada atravs do boto
Edit Value no interador Instanc. Attrib.
A abstrao de composio representada atravs da informao definida no campo

Instances Colony Type e de um subconjunto de formulrios vinculados aos botes
Define Colony, Constringe e Inhabit. A abstrao de generalizao tratada por
um subconjunto de formulrios vinculados aos botes Generalize e Specialize.

O Editor de Esquemas possui um conjunto de regras que garantem restries de
integridade e consistncia, aplicadas principalmente a operaes de edio que podem
causar inconsistncia na base de dados.
6.3 Utilizao da API no E2Sirius

O Editor de Esquemas foi re-implementado utilizando apenas as primitivas da API
desenvolvida neste trabalho, tornando-se um utilitrio centrado num gerenciador de dados
orientado a objetos. Como a emulao desse tipo de gerenciador foi desenvolvida com o
cuidado de se preservar uma mesma interface para as verses relacional e nativa do
2
Gerenciador SIRIUS, a nova verso do E Sirius pode utilizar, como utilitrio, tanto a
verso relacional quanto a verso nativa desse gerenciador.
A funcionalidade geral do Editor de Esquemas foi preservada na nova implementao, pois
os conceitos inerentes s abstraes de dados que o editor suporta, com exceo da
abstrao de generalizao, esto presentes na API. Entretanto, o cdigo resultante bem
mais conciso e mais simples, pois todas as operaes de acesso direto base de dados
emulando um ambiente orientado a objetos so feitas na API. Alm disso, as operaes
especficas de verificao de consistncia e de restries de integridade referentes ao
modelo de dados tambm so tratadas na API, deixando para o utilitrio apenas a tarefa de
verificar, se como resultado, houve ou no a ocorrncia de erros. Alm disso, a maioria dos
74
6 E2SIRIUS
trechos de cdigo que envolvem uma lgica mais complexa ficaram implementados
internamente API.
Essa nova abordagem de implementao facilitou significativamente a atividade de
desenvolvimento do editor, finalizado num tempo muito menor que a verso original,
mesmo levando-se em considerao a experincia anteriormente adquirida com o
desenvolvimento da mesma. Uma medida quantitativa desse ganho pode ser vista pelo
nmero de linhas de cdigo do editor: desconsiderando-se os mdulos que no foram
alterados por no haver sido criado na API o suporte necessrio (como por exemplo o
suporte abstrao de generalizao), 6.389 linhas de cdigo da verso original foram
transformadas em 2.948 linhas na verso que utiliza a API. Uma vantagem importante
dessa nova abordagem a reduo na complexidade da tarefa de manuteno e extenso do
Editor de Esquemas.
Para ilustrar, so apresentados trechos de cdigo da verso original e da verso utilizando
a API para a mesma operao. A Figura 19 apresenta o cdigo que efetua a criao de um
novo objeto na verso original do editor, e a Figura 20 apresenta o cdigo para a mesma
operao na verso que utiliza a API. Note-se que no exemplo da verso original todas as
funes utilizadas foram implementadas na prpria ferramenta, enquanto no exemplo da
verso utilizando a API so utilizados apenas mtodos implementados nas classes da API,
com exceo da funo RefreshGrids, que refere-se apenas interface com o usurio, e
da macro SAFEDELETE, cuja lgica refere-se a restries impostas pelo editor.
75
6 E2SIRIUS
// Nome do Boto: + Objeto (Inserir Objeto)

void __fastcall TForm_Objeto::BitBtn1_salvar_Click(TObject *Sender)
{
int codigo_objeto, tipo_corrente, tipo_col_instancias, tipo_col_habita,
colonia_aberta, codigo_atributo;
// Testa se o campo nome e o tipo do objeto esto preenchido
if (Form_Objeto->ComboBox1_nome_objeto->Text == "\0" ||
Form_Objeto->ComboBox_tipo_obj->ItemIndex == -1)
if (MessageBox(0,"Certifique-se de que todos os campos estejam
preenchidos", "Informao incompleta", MB_OK)==IDOK)
return;
// Busca o cdigo do tipo de objeto definido para o objeto a ser

// inserido
tipo_corrente = Buscar_Obj_Por_Nome(ComboBox_tipo_obj->Text);
// Busca o tipo da colnia onde o objeto vai habitar
tipo_col_habita = Buscar_TColonia_Instancias(tipo_corrente);
// Verifica se existe alguma colnia (aberta) do tipo encontrado. Se no houver, o
// objeto nopode ser inserido na base antes que a colnia apropriada seja aberta
if ((colonia_aberta = Colonia_Aberta(tipo_col_habita)) == 0)
if (MessageBox(0,"No existe colnia aberta",
"Informao incompleta", MB_OK)==IDOK)
return;
// Verifica se j existe outro objeto com o mesmo nome na mesma colnia
if ((codigo_objeto = Buscar_Obj_Por_Nome (ComboBox1_nome_objeto->Text))!=0)
if (MessageBox(0,"O objeto especificado j existe",
"Valor duplicado", MB_OK)==IDOK)
return;
ModuloDado->Gerador->Prepare();
ModuloDado->Gerador->ExecProc();
codigo_objeto = ModuloDado->Gerador->ParamByName("Codigo_Retorno")->AsInteger;
if (ComboBox1_colonia->Text == "\0")
tipo_col_instancias = NULL;
else
// Busca o cdigo do tipo da colnia onde as instncias do objeto iro habitar
tipo_col_instancias = Buscar_TColonia_Por_Nome(ComboBox1_colonia->Text);
Inserir_Objeto(codigo_objeto,tipo_corrente, ComboBox1_nome_objeto->Text,
colonia_aberta, tipo_col_instancias);
// Cdigo para caso Tipo_Obj == MetaTipoObjeto
if (tipo_corrente == 2)
Inserir_Valor_Texto(3,codigo_objeto,-1, ComboBox1_nome_objeto->Text);
else
{
// Busca o cdigo do atributo identificador do objeto pai a partir de seu
// cdigo
codigo_atributo = Buscar_Ident_Nivel_Especifico(tipo_corrente, 1);
Inserir_Valor_Texto(codigo_atributo,codigo_objeto,-1,
ComboBox1_nome_objeto->Text);
Inserir_Vinculos_Fixos(codigo_objeto, tipo_corrente);
}
ModuloDado->Grid_Classificacao->Close();
ModuloDado->Grid_Classificacao->ParamByName("Codigo")->AsInteger = codigo_objeto;
ModuloDado->Grid_Classificacao->Open();
Seta_Valor_Grid();
if (MessageBox(0,"Objeto armazenado na base", "Confirmao", MB_OK)==IDOK)
return;
}
Figura 19 - Cdigo no E2SIRIUS original
76
6 E2SIRIUS
// Button "+ Object"

void __fastcall TForm_Object::BitBtn_AddObjectClick(TObject *Sender)
{
char *message;
int index;
// object is created as member of the form object to represent the // current
object
__SAFEDELETE( object );
if (ComboBox_ObjName->Text == "\0" ||
ComboBox_ObjType->ItemIndex == -1)
{
if (MessageBox(0,"Check if all fields are fulfilled",
"Incomplete Information", MB_OK)==IDOK)
return;
}
object = new SiriusObject;
try
{
object->CreateObject( ComboBox_ObjName->Text,
ComboBox_ObjType->Text,
ComboBox_ColType->Text );
object->SetAsPersistent( );
}
catch ( SiriusError error )
{
message = ( error.GetErrorMessage( ) ).c_str( );
if (MessageBox(0,message, "Error in creating object",
MB_OK)==IDOK)
{
__SAFEDELETE( object );
return;
}
}
RefreshGrids( );
index = ComboBox_ObjName->Items->Add( object->GetName( ) );
ComboBox_ObjName->ItemIndex = index;
if (MessageBox(0,"Object created", "Confirming...", MB_OK)==IDOK)
return;
}
Figura 20 - Cdigo no E2SIRIUS reformulado
O Editor de Esquemas foi re-implementado com o objetivo de validar a API definida neste
trabalho, a qual comprovou ser um mecanismo consistente de desenvolvimento de
aplicativos centrados num gerenciador de dados orientado a objetos. Foi demonstrado que
a API pode ser utilizada para implementar um utilitrio de bases de dados genrico e
abrangente, oferecendo suporte consistente aos conceitos das abstraes de dados de um
modelo orientado a objetos. Naturalmente, a API tambm pode ser utilizada no
desenvolvimento de aplicaes para a resoluo de problemas mais especficos, e pode ser
expandida para suportar tipos de dados complexos caractersticos de aplicaes no
convencionais, em diversas reas de conhecimento.
77
6 E2SIRIUS

Este captulo mostra a utilizao da API desenvolvida neste trabalho na re-implementao
de um Editor de Esquemas, cuja funcionalidade predominante a edio de modelagens
centradas num modelo de dados orientado a objetos baseado nas abstraes de
classificao, agregao, composio e generalizao.
O editor, desenvolvido originalmente como uma ferramenta cujas operaes acessavam
diretamente uma base de dados relacional, foi re-escrito para que seu cdigo acessasse um
gerenciador de base de dados orientado a objetos. A nova abordagem do Editor de
Esquema utiliza apenas primitivas da API, cuja implementao sobre um gerenciador
relacional emula um gerenciador de dados orientado a objetos.
A reformulao do editor demonstrou a consistncia da API no suporte aos conceitos
inerentes s abstraes de dados citadas acima, destacando o tratamento homogneo a tipos
e instncias, o suporte a atributos extras e o suporte ao Meta Tipo (definido pelo
sistema), imprescindveis para a hierarquia de classificao em mltiplos nveis.
78
7 Concluso
7 Concluso
7.1 Consideraes Iniciais

Este trabalho descreve uma Interface de Programao de Aplicativos (Application
Program Interface API) desenvolvida para um gerenciador de dados orientado a objetos.
A API resultante integra de maneira consistente os recursos bsicos que devem estar
presentes na API de um gerenciador de objetos, incluindo as operaes de criao,
remoo, atualizao e consulta, e os recursos necessrios ao suporte das caractersticas
particulares de abstraes de dados tratadas em modelos de dados orientados a objetos.
O Modelo de Dados SIRIUS foi escolhido como alvo para a definio da API por tratar-se
de um metamodelo semanticamente rico, e bem conhecido pelos membros do Grupo de
Bases de Dados e Imagens (GBDI). Este modelo considera quatro abstraes de dados:
classificao, agregao, generalizao e composio. Um aspecto diferencial que motivou
a utilizao do SIRIUS foi o conceito de hierarquia em mltiplos nveis proposta para a
abstrao de classificao. Nesta abordagem, o modelo define um construtor semntico
especfico para representar a classificao no esquema de uma aplicao, onde o nmero
de nveis da hierarquia determinado de acordo com a realidade do problema a ser tratado.
Portanto, objetos assumem indistintamente os papis de tipos e instncias manipulados
atravs de um conjunto nico de operaes.
Os mtodos que compem a API foram implementados sobre um gerenciador relacional
para emular um gerenciador de dados orientado a objetos. Os dados armazenados numa
base relacional so tratados por uma camada semntica que implementa a lgica do
modelo de objetos, tornado o formato relacional dos dados totalmente transparente para
a aplicao. Como a base conceitual da criao da API foi o modelo SIRIUS, o
gerenciador emulado foi desenvolvido como uma verso com ncleo relacional do
Gerenciador de Objetos SIRIUS.
79
7 Concluso
A API, assim como o prottipo da verso com ncleo relacional do Gerenciador SIRIUS,
foi validada atravs da reformulao do Editor de Esquemas SIRIUS, que passou a realizar
toda a comunicao com a base de dados atravs dos mtodos definidos na API
[Araujo_98b]. O resultado obtido foi um cdigo conciso, consistente e compatvel com as
necessidades do editor, ou seja, suporte edio de modelagens centradas no modelo
SIRIUS, alimentao da base de dados, consulta e atualizao. A reformulao do editor
demonstrou que a API oferece os recursos adequados ao desenvolvimento de uma
ferramenta que incorpora as particularidades das abstraes de classificao, agregao,
composio e generalizao, como o caso do Editor de Esquemas. Portanto, a API pode
ser utilizada no desenvolvimento de aplicaes cujas informaes sejam representadas
segundo as abstraes citadas acima.
Conclui-se que a API resultante deste trabalho atende aos requisitos considerados
fundamentais no contexto ao qual est inserida:
incorpora a funcionalidade bsica da API de um gerenciador de base de dados,
disponibilizando operaes de criao, remoo, atualizao e consulta;
abrange os conceitos principais do modelo SIRIUS, destacando-se as abstraes de
dados que o modelo suporta;
permite acesso ao esquema e manipulao de dados utilizando um mesmo conjunto de
primitivas, unificando operaes usualmente divididas em DDL e DML;
compatvel com as verses com ncleo relacional e com ncleo nativo do gerenciador
de objetos SIRIUS;
oferece suporte adequado abstrao de classificao com hierarquia em mltiplos
nveis atravs do tratamento homogneo de tipos e instncias.
Este ltimo requisito particularmente significativo, pois demonstra (pela primeira vez na
literatura, segundo o melhor de nosso conhecimento), de maneira prtica, a utilizao da
abstrao de classificao em um ambiente relacional, e a unio dos subconjuntos DDL e
DML de uma linguagem de consulta em apenas um conjunto de comandos [Machado_00].
80
7 Concluso
7.2 Contribuies Apresentadas

Dentre as contribuies apresentadas por este trabalho, destacam-se:
definio de uma API consistente para um gerenciador de dados orientado a objetos,
abrangendo os conceitos pertinentes s abstraes de dados suportadas por um
metamodelo orientado a objetos baseado nas abstraes de classificao, generalizao,
associao e composio. Embora tenha sido definida a partir dos princpios do modelo
SIRIUS, a API pode ser adaptada a qualquer modelo baseado em abstraes de dados,
pois a semntica de cada abstrao definida e implementada atravs de um conjunto
bem definido de mtodos das classes que compem os mdulos semnticos da API.
Numa aplicao imediata, a API poder ser utilizada no desenvolvimento de
ferramentas centradas no Gerenciador de Objetos SIRIUS, para o qual foi criada uma
verso com ncleo relacional;
suporte abstrao de classificao, demonstrando como a hierarquia de tipos em
mltiplos nveis, definida num modelo de dados, pode ser aplicada na prtica atravs
do tratamento homogneo de tipos e instncias num gerenciador orientado a objetos;
unificao de operaes de uma linguagem de consulta normalmente divididas em
DDL e DML num conjunto nico de comandos, compatvel com uma linguagem de
programao orientada a objetos, permitindo a criao, remoo e manipulao de
objetos e tipos de objetos em tempo de execuo;
as contribuies citadas acima consolidam a abordagem diferencial dada abstrao de
classificao no modelo de dados SIRIUS. A definio e implementao da API, e sua
utilizao no desenvolvimento de um utilitrio como o Editor de Esquemas,
comprovam a aplicabilidade do conceito de classificao em mltiplos nveis, atravs
de um construtor semntico, na representao de informaes do mundo real num
sistema, incluindo modelagem de dados e suporte adequado num gerenciador de dados
orientado a objetos;
81
7 Concluso
desenvolvimento de um gerenciador de dados orientado a objetos emulado, resultando

num prottipo da verso com ncleo relacional do Gerenciador de Objetos SIRIUS.
Esta verso ser utilizada como um ambiente experimental para testes de algoritmos,
tcnicas de desenvolvimento e suporte a conceitos ainda no tratados, possibilitando a
avaliao de alternativas de projeto e implementao para a verso nativa do
gerenciador.
7.3 Sugestes para Trabalhos Futuros

Uma das motivaes deste trabalho foi o de tornar disponvel uma verso operacional de
um gerenciador de dados apoiado no modelo SIRIUS. Esse objetivo foi cumprido, dentro
das restries tpicas de um programa de mestrado, tais como prazos, delimitao
acadmica dos resultados (comparando com a disponibilidade completa de recursos teis
para a usabilidade diria da ferramenta-produto, mas que conceitualmente consistem na
mera repetio de conceitos j tratados em outros aspectos da ferramenta). Dentro dessa
perspectiva, uma continuao bvia do trabalho consiste em se completar a ferramenta,
com o suporte a todos os recursos do modelo SIRIUS. Essa tarefa importante para
permitir a utilizao real da ferramenta em outros projetos em andamento no Grupo de
Bases de Dados e Imagens do ICMC, e como uma ferramenta de divulgao desses
conceitos entre outros grupos de pesquisa. Essa tarefa poderia, por exemplo, ser
desenvolvida por alunos de Iniciao Cientfica, ou tcnicos vinculados ao projeto.
Outra motivao deste trabalho foi explorar a idia de que tcnicas de implementao de
conceitos voltados orientao a objetos podem ser mais fcil e rapidamente
implementados e testados num ambiente relacional do que num ambiente nativo.
Obviamente, tal soluo no leva a um desempenho to bom quanto pode ser obtido no
ambiente nativo, servindo assim como uma bancada de experimentao (ou prototipao)
que no substitui a verso nativa, mas pode prover mais rapidamente parmetros para a
deciso sobre alternativas de implementao. Essa motivao pode agora ser explorada, e a
API desenvolvida pode ser utilizada para a experimentao de novas tcnicas de
implementao de conceitos voltados orientao a objetos.
Utilizando um editor com suporte completo ao modelo de dados, diversos tpicos de
pesquisa tornam-se interessantes, e so descritos a seguir.
82
7 Concluso
Suporte a novos conceitos sem impacto em aplicaes j existentes. Uma caracterstica

importante, associada ao uso de gerenciadores de dados a chamada Independncia de
Dados. Essa caracterstica, fortemente procurada nos primeiros modelos de dados (que
seguem a especificao CODASYL), no adequadamente tratada em gerenciadores
relacionais. Modelos de dados orientados a objetos, por outro lado, tm sido citados como
melhores plataformas para enfatizar essa caracterstica. Temos visto que na prtica, a
extenso de um banco de dados em um empreendimento para suportar um novo conceito
leva incluso de novos dados e procedimentos em muitas das tabelas j existentes, e
necessidade de modificaes nos processos correspondentes a diversos aplicativos. A
incluso de uma nova camada, como a que suporta o SIRIUS, em um empreendimento j
existente causa menos impacto arquitetura do sistema de informao do empreendimento,
pois definida atravs de suas prprias relaes e procedimentos, causando um impacto
menor (ou mesmo nulo) nas aplicaes existentes. Por outro lado, como um novo conceito
provavelmente deve ser mais facilmente desenvolvido utilizando um modelo de dados
semanticamente mais rico, a soluo natural que ele seja incorporado no diretamente
pelo modelo relacional, mas atravs de uma ferramenta como a API aqui desenvolvida.
Suporte a imagens. Este tpico em parte decorrente do anterior, considerando ser o
suporte a imagens um novo conceito a ser suportado. Nesse caso, uma aplicao (nova ou
j existente) ir se referenciar a imagens em qualquer parte (relao) onde a lgica do
empreendimento indicar o uso de imagens. Se o suporte a imagens tiver que ser tratado
fora do gerenciador, como a situao atualmente, no um, mas diversos atributos, com
suas respectivas restries e procedimentos tm que ser includos em cada parte onde
imagem deva ser suportada. Por exemplo, se um suporte a busca por contedo deve ser
empregado, os mtodos de acesso a caractersticas de imagens (features) e os atributos
resultantes devem ser inseridos e replicados em cada lugar onde uma imagem deve ser
armazenada. Utilizando a API desenvolvida, um atributo imagem inserido como um
identificador para o SIRIUS, assim um nico atributo estabelece a ligao da aplicao
com qualquer suporte a imagens que venha a ser construdo sobre SIRIUS (como o caso
atualmente, em que diversos projetos do GBDI vm desenvolvendo uma estrutura de
suporte a imagens em SIRIUS).
Desenvolvimento e suporte de novas tcnicas de indexao. Este tpico leva em conta
que a maioria dos gerenciadores relacionais existentes so arquiteturas fechadas, tornando
83
7 Concluso
inexeqvel a sua utilizao com estruturas de indexao no suportadas nativamente pelo

gerenciador. Atravs da API, qualquer atributo que deva ser includo numa estrutura de
indexao pode ser tratado por esta interface. A partir da, a estrutura de indexao pode
ser includa como parte da funcionalidade da API, ou pode ser ativada como um mdulo
externo prpria API, que assim atua apenas como uma ponte entre os atributos a serem
indexados (colocados na estrutura de dados da aplicao) e os mtodos de indexao
supridos pela aplicao.
Desenvolvimento de uma linguagem de consulta textual. Da mesma maneira que a API
pode dar suporte a um editor de esquemas para o modelo SIRIUS, ela pode dar suporte a
uma linguagem de consulta textual SQL-like. No entanto, como SIRIUS prov muitos
recursos alm dos suportados por SQL, uma linguagem consistente deve ser projetada, em
particular provendo recursos para a existncia de um mecanismo de otimizao e
permitindo o desenvolvimento de um bom otimizador de consultas.
84
[Araujo_98a] Araujo, M. R. B. - Representao de Construtores Semnticos em SIRIUS e
Suporte atravs de um Editor de Esquemas, Dissertao de Mestrado - ICMC - USP,
So Carlos, 1998.
[Araujo_98b] Araujo, M. R. B.; Traina Jr, C.; Biajiz, M.; Machado, E. P. - Editor de
Esquemas com Suporte para Hierarquias de Classificao, Anais do XIII Simpsio
Brasileiro de Banco de Dados, pp. 135 - 149, Maring, Outubro 1998.
[Atkinson_94] Atkinson, M. et al. - The Object-Oriented Database System Manifesto,
Readings in Database System, edited by M. Stonebraker, Morgan Kaufmann
Publishers, pp. 946 - 954, 1994, Second Edition.
[Bancilhon_92] Bancilhon, F.; Delobel, L.; Kanellakis, P. - Building an Object-Oriented
Database System, The Story of O2, Morgan Kaufmann, 1992.
[Barry_98a] Barry, D. There's an ODMG Database in Your Future, Database
Programming & Design, pp. 66, April 1998. Disponvel on line em
http://www.odmg.org.
[Barry_98b] Barry, D. If You Want Better Answers..., Database Programming &
Design, pp. 72, July 1998. Disponvel on line em http://www.odmg.org.
[Bertino_91] Bertino, E.; Martino, L. Object-Oriented Database Management Systems:
Concepts and Issues, Computer IEEE, vol. 24, no. 4, pp. 33 - 47, April 1991.
[Bertino_92] Bertino, E.; Negri, M.; Pelagatti, G.; Sbattella, L. Object-Oriented Query
Languages: The Notion and the Issues, IEEE Transactions on Knowledge and Data
Engineering, vol. 4, no. 3, pp. 223 - 237, June 1992.
[Biajiz_92] Biajiz, M. Uma Atualizao do Modelo de Representao de Objetos e
Uma Abordagem Formal, Dissertao de Mestrado - ICMC -USP, So Carlos, Julho
1992.
[Biajiz_96a] Biajiz, M. - Representao de Modelos de Dados Orientados a Objetos
atravs de Parametrizao de Abstraes, Tese de Doutorado IFSC - USP, So
Carlos, Setembro 1996.
[Biajiz_96b] Biajiz, M.; Traina Jr., C.; Vieira, M. T. P. - SIRIUS - Modelo de Dados
Orientado a Objetos Baseado em Abstraes de Dados, Anais do XI Simpsio
Brasileiro de Banco de Dados, pp. 338 - 352, So Carlos, Outubro 1996.
[Butterworth_91] Butterworth, P.; Otis, A.; Stein, J. - The GemStone Object Database
Management System, Communications of the ACM, vol. 34, no. 10, pp. 64 - 77,
October 1991.
[Cattell_94] Cattell, R. G. G. - Object Data Management - Object-Oriented and Extended
Relational Database Systems, Addison - Wesley, 1994.
85
[Cattell_95] Cattell, R. G. G. - Object Databases and Standards, Lecture Notes in

Computer Science, no. 940, pp. 1 - 11, 1995.
[Cattell_97] Cattell, R. G. G. et al. The Object Database Standard: ODMG 2.0",
Morgan Kaufmann Publishers, 1997.
[Chan_94] Chan, D. K. C.; Trinder, P. W. ; Welland, R. C. - Evaluating Object-Oriented
Query Languages, The Computer Journal, vol. 37, no. 10, pp. 858 - 872, 1994.
[Date_97] Date, C. J.; Darwen, H. - A Guide to The SQL Standard, Addison-Wesley,
1997, Fourth Edition.
[Deux_90] Deux, O. et al. - The Story of O2, IEEE Transactions on Knowledge and
Data Engineering, vol. 2, no. 1, pp. 91 - 108, March 1990.
[Deux_91] Deux, O. et al. - The O2 System, Communications of the ACM, vol. 34, no.
10, pp. 34 - 49, October 1991.
[Eisenberg_98] Eisenberg, A.; Melton, J. Standards In Practice, SIGMOD Record,
vol. 27, no. 3, pp. 53 - 58, September 1998.
[Eisenberg_99] Eisenberg, A.; Melton, J. SQL:1999, formerly known as SQL3,
SIGMOD Record, vol. 28, no. 1, pp. 131 - 138, March 1999.
[Elmasri_00] Elmasri, R.; Navathe, S. B. - Fundamentals of Database Systems, Addison
Wesley, 2000, Third Edition.
[Ferreira_96] Ferreira, J. E.; Traina Jr., C. Controle de Compartilhamento e Acesso em
GBDOO Baseado em Composio de Objetos, Anais do XI Simpsio Brasileiro de
Banco de Dados, pp. 143 157, So Carlos SP, Outubro 1996.
[Fishman_89] Fishman, D. H. et al. - Overview of the Iris DBMS, Object-Oriented
Concepts, Databases and Applications, edited by W. Kim and F. H. Lochovsky, ACM
Press, pp. 219 - 250, 1989.
[Ishikawa_93] Ishikawa, H. et al. The Model, Language and Implementation of an
Object-Oriented Multimedia Knowledge Base Management System, ACM
Transactions on Database Systems, vol. 18, no. 1, pp. 1 - 50, March 1993.
[Ishikawa_96] Ishikawa, H.; Yamane, Y.; Izumida, Y.; Kawato, N. An Object-Oriented
Database System Jasmine: Implementation, Application, and Extension, IEEE
Transactions on Knowledge and Data Engineering, vol. 8, no. 2, pp. 285 - 340, April
1996.
[Jasmine_00]
Jasmineii
Computer
http://www.cai.com/products/jasmine.htm, acessado em Novembro 2000.
Associates,
[Kappel_98] Kappel, G.; Retschitzegger, W. - The TriGS Active Object-Oriented

Database System - An Overview, SIGMOD Record, vol. 27, no. 3, pp. 36 - 41,
September 1998.
86
[Kim_96] Kim, Y. H. et al. The Object-Oriented Design of KROSS: An Object-Oriented

Spatial Database System, Lecture Notes in Computer Science, no. 1134, pp. 603 612, 1996.
[Lamb_91] Lamb, C. et al. - The ObjectStore Database System, Communications of the
ACM, vol. 34, no. 10, pp. 50 - 63, October 1991.
[Machado_00] Machado, E. P.; Traina Jr., C.; Araujo, M. R. B. Classification
Abstraction: an intrinsic element in Database Systems, In proceedings of First
Biennial Conference on Advances in Information Systems (ADVIS 2000) - Lecture
Notes in Computer Science, vol. 1909, Turkey, October 2000.
[Nierstrasz_89] Nierstrasz, O. A Survey of Object-Oriented Concepts, Object-Oriented
Concepts, Databases, and Applications, edited by W. Kim and F. H. Lochovsky, ACM
Press, pp. 3 - 21, 1989.
[Perez_91] Perez, E. A strawman reference model for an application program interface
to an Object-Oriented Database, Computer Standards & Interfaces, vol. 13, pp. 123 138, 1991.
[ODBC_00a] ODBC
Novembro 2000.
Guide,
http://www.cs.hut.fi/~las/odbc.htm,
acessado
em
[ODBC_00b] Open Database Connectivity, http://www.microsoft.com/data/odbc,

acessado em Novembro 2000.
[ODMG_00] Object Database Management Group, http://www.odmg.org, acessado em
Novembro 2000.
[Sousa_00] Sousa, E. P. M.; Traina Jr., C. Interface de Programao de Aplicativos
para o Gerenciador de Objetos SIRIUS, Relatrio Tcnico a ser publicado, ICMC
USP, Dezembro 2000.
[SQL3_97] SQL3 Object Model, http://ww.objs.com/x3h7.sql3.htm, acessado em
05/07/99.
[Stonebraker_91] Stonebraker, M.; Kemnitz, G. - The POSTGRES Next-Generation
Database Management System, Communications of the ACM, vol. 34, no. 10, pp. 78 92, October 1991.
[Traina_91] Traina Jr., C. GEO: Um Sistema de Gerenciamento de Bases de Dados
Orientado a Objetos - Estado atual de Desenvolvimento e Implementao, VI
Simpsio Brasileiro de Banco de Dados, pp. 193 - 207, Manaus, Maio 1991.
[Traina_92] Traina Jr., C. Um Modelo de Representao de Objetos, Notas Internas
no. 104, ICMC-USP, So Carlos, Fevereiro 1992.
[Traina_93b] Traina Jr., C.; Camolesi Jr., L. Primitivas do Ncleo do Gerenciador de
Esquemas de Dados no Modelo MRO*, Relatrio Tcnico no. 010, ICMC-USP, So
Carlos, Maio 1993.
87
[Valncio_00] Valncio, C. R. Ncleo Gerenciador de Objetos: Compatibilizando

Eficincia e Flexibilidade, Tese de Doutorado - IFSC - USP, Setembro 2000.
[Wilkinson_90] Wilkinson, K.; Lyngbaek, P.; Hasan, W. The Iris Architecture and
Implementation, IEEE Transactions on Knowledge and Data Engineering, vol. 2, no.
1, pp. 63 - 75, March 1990.
[Zand_95] Zand, M.; Collins, V.; Caviness, D. A Survey of Current Object-Oriented
Databases, The Database for Advances in Information System, vol. 26, no. 34, pp. 14
- 29, February 1995.
88
Anexo:
API do Gerenciador de Objetos SIRIUS
89
Descrio das Classes da API

Obs: na descrio das classes, os tipos de dado dos parmetros e dos retornos dos mtodos so
colocados em negrito. Os tipos definidos na API so descritos no final do Anexo, onde so
feitas as observaes necessrias pertinentes a cada tipo.
Classe SiriusObject
Mtodo:
void CreateObject ( SString objectName, SString typeName,

SString colTypeName = \0 )
Descrio:
Cria um objeto temporrio, que pode ser explicitamente declarado como

persistente atravs do mtodo SetAsPersistent.
Parmetros:
Parmetros de entrada:
Uma instncia da classe SiriusObject, chamada de sobrestante objeto, uma representao

em memria de um objeto armazenado na base de dados.
Mtodo:
SiriusObject ( )
Descrio:
Construtor da classe: cria um sobrestante objeto vazio, permitindo a

criao de um novo objeto ou a recuperao de um objeto armazenado
na base de dados
objectName - nome do objeto a ser criado

typeName - nome do tipo do objeto
colTypeName - nome do tipo de colnia onde habitam as instncias do
objeto criado. Default: colTypeName == \0
Exemplos:
Cria no sobrestante vPerson o objeto Person, cujo tipo METATYPE

(tipo pr-definido do sistema). As instncias de Person habitam colnias
do tipo GLOBAL (tipo de colnia pr-definido do sistema):
vPerson->CreateObject( Person, METATYPE,GLOBAL);
Parmetros:
Exemplos:
Cria no sobrestante vJohn o objeto John, cujo tipo Person:

Cria os sobrestantes vPerson e vJohn:
vJohn->CreateObject(John, Person);
SiriusObject *vPerson = new SiriusObject;

SiriusObject *vJohn = new SiriusObject;
Mtodo:
~SiriusObject ( )
Descrio:
Destrutor da classe - libera o espao em memria alocado para o

sobrestante objeto. Se o objeto representado no sobrestante for
persistente, o destrutor no tem efeito algum sobre o objeto armazenado
na base de dados.
Mtodo:
SOID SetAsPersistent ( )
Descrio:
Torna o objeto persistente e retorna o OId criado para esse objeto
Parmetros:
Retorno:
SOID - OId do objeto persistente
Exemplos:
Torna persistentes os objetos Person e John, respectivamente

representados nos sobrestantes vPerson e vJohn:
SOID personId = vPerson->SetAsPersistent( );
SOID johnId = vJohn->SetAsPersistent( );
Mtodo:
bool IsPersistent ( )
Descrio:
Verifica se o objeto persistente ou no
Parmetros:
Mtodo:
void ReadObject ( SString objectName,

SString typeName = METATYPE )
Descrio:
Recupera um objeto armazenado na base de dados
Parmetros:
Retorno:
true - objeto persistente
false - objeto transiente
Exemplos:
Verifica se o objeto Person, representado no sobrestante vPerson

persistente:
objectName - nome do objeto a ser lido

typeName - nome do tipo do objeto. Default: METATYPE
Exemplos:
bool persistent = vPerson->IsPersistent( );
SiriusObject *vPaul = new SiriusObject;

vPaul->ReadObject( Paul, Person );
Resultado:
persistent == true;
Mtodo:
void ReadObject ( SOID object )
Descrio:
Recupera um objeto armazenado na base de dados
Parmetros:
Parmetro de entrada:
object - OId do objeto a ser lido
Cria um sobrestante vPaul e traz para este sobrestante as informaes do

objeto Paul, do tipo Person, armazenado na base de dados:
Mtodo:
void DeleteObject ( )
Descrio:
Remove da base de dados o objeto representado no sobrestante
Parmetros:
Exemplos:
Remove da base o objeto Paul, representado no sobrestante vPaul:

vPaul->DeleteObject( );
Exemplos:
Cria um sobrestante vObject e traz para este sobrestante as informaes

do objeto de cdigo objectId armazenado na base de dados:
SiriusObject *vObject = new SiriusObject;
vObject->ReadObject( objectId );
Mtodo:
void AddAttribute ( SiriusAttribute *attribute,

SClassification classInfo, SAggregation aggregInfo )
Descrio:
Associa ao objeto um atributo previamente criado atravs da classe

correspondente caracterstica do atributo. Atributos somente podem ser
associados a objetos persistentes.
Parmetros:
Mtodo:
void DeleteAttribute ( SString attribName )
Descrio:
Remove um atributo do objeto
Parmetros:
attribName - nome do atributo a ser removido
Exemplos:
Remove o atributo Address do objeto Person
attribute - referncia para um sobrestante atributo correspondente

caracterstica do atributo a ser associado ao objeto
classInfo - propriedades da abstrao de classificao
aggregInfo - propriedades da abstrao de agregao
Exemplos:
vPerson->DeleteAttribute( Address );
Mtodo:
SiriusAttribute* GetIdAttribute ( SLevel level )
Descrio:
Acessa o atributo identificador do objeto num determinado nvel de

instanciao
Parmetros:
level - nvel de instanciao do atributo identificador a ser manipulado
Cria um sobrestante vName para o atributo Name:

SiriusAttribText *vName = new SiriusAttribText( Name );
Vincula o atributo Name ao objeto Person. Name atributo

monovalorado, identificador no primeiro nvel de instanciao, fixo,
definido e no possui valor default:
SAggregation aggregInfo;
SClassification classInfo;
aggregInfo.org = MONOVALUED;
aggregInfo.uBound = 1;
aggregInfo.lBound = 1;
classInfo.level = 1;
classInfo.id = IDENTIFIER;
classInfo.def = DEFINED;
classInfo.deflt = NON-DEFAULT;
classInfo.fix = FIX;
vPerson->AddAttribute( vName, classInfo, aggregInfo )
Retorno:
SiriusAttribute* - referncia para o sobrestante do atributo identificador
Exemplos:
Recupera o atributo identificador do objeto Person no nvel 1 de

instanciao:
SiriusAttribute *vId;
vId = vPerson->GetIdAttribute( 1 );
Mtodo:
SiriusAttribute* GetAttribute ( SString attribName )
Mtodo:
SString GetColonyType ( )
Descrio:
Acessa um atributo do objeto
Descrio:
Recupera o nome do tipo da colnia onde habitam as instncias do

objeto, de acordo com o Diagrama Hierrquico de Colnias
Parmetros:
attribName - nome do atributo a ser manipulado
Parmetros:
Retorno:
SString - nome do tipo de colnia
Exemplos:
Recupera o nome do tipo de colnia onde habitam as instncias do

objeto Person, representado no sobrestante vPerson
Retorno:
SiriusAttribute* - referncia para o sobrestante do atributo
Exemplos:
Recupera o atributo Age do objeto Paul. vAge uma referncia para o

sobrestante que representa o atributo Age:
SString typeName = vPerson->GetColonyType(

printf( %s, typeName.c_str( ));
SiriusAttribNumber *vAge;
vAge = (SiriusAttribNumber*) vPaul->GetAttribute( Age );
Resultado:
);
typeName == GLOBAL
O atributo Age pode ser manipulado atravs dos mtodos da classe

SiriusAttribNumber (especfica para a caracterstica Nmero):
vAge->SetValue( 20" );
SNumberValue value = vAge->GetValue( );
Mtodo:
SString GetName ( )
Resultado:
Descrio:
Recupera o nome do objeto.
Parmetros:
Retorno:
SString - nome do objeto
Exemplos:
Recupera o nome do objeto representado no sobrestante vPerson:
value == 20
SString objName = vPerson->GetName( );
Resultado:
objName == Person
Mtodo:
SString GetColony ( SOID *ctrObject )
Mtodo:
SOID GetType ( )
Descrio:
Recupera a colnia onde o objeto habita, de acordo com o DRI. A

colnia identificada pelo nome de seu tipo e pelo OId do objeto que a
constringe.
Descrio:
Recupera OId do tipo do objeto representado no sobrestante
Parmetros:
Retorno:
SOID - OId do tipo do objeto
Exemplos:
Recupera o OId do tipo do objeto representado no sobrestante vPerson:
Parmetros:
Parmetro de Retorno:
ctrObject - OId do objeto que constringe a colnia recuperada
Retorno:
SString - nome do tipo da colnia recuperada
Exemplos:
SOID typeOId = vPerson->GetType( );
Recupera a colnia que onde habita o objeto Person, representado no

sobrestante vPerson:
Mtodo:
bool operator== ( SiriusObject& )
SOID obj;
SString colony = vPerson->GetColony( &obj );
Descrio:
Verifica se dois sobrestantes objeto representam o mesmo objeto
Resultado:
colony == GLOBAL
Obs: neste exemplo, o valor de obj no alterado porque o tipo de

objeto Meta Tipo, que constringe a colnia do tipo Global, no pode ter
seu OId manipulado pela aplicao.
Mtodo:
SOID GetOId ( )
Descrio:
Recupera o OId do objeto representado no sobrestante
Parmetros:
Retorno:
SOID - OId do objeto
Exemplos:
Recupera o OId do objeto representado no sobrestante vPerson:

SOID OId = vPerson->GetOId( );
Parmetros:
Exemplos:
Verifica se vJohn e vPerson representam o mesmo objeto da base de

dados:
if (vJohn == vPerson ) { ... };
Classe SiriusObjectCursor
Uma instncia da classe SiriusObjectCursor, chamada de sobrestante cursor objeto,
armazena os OIds de um conjunto de objetos da base de dados recuperados numa consulta,
segundo algum critrio.
Mtodo:
SiriusObjectCursor ( )
Descrio:
Construtor da classe: cria uma estrutura para armazenar um conjunto de

OIds de objetos que satisfazem um critrio de busca numa consulta. O
conjunto de OIds percorrido atravs de cursores definidos para esta
estrutura.
Mtodo:
void SearchObject ( int isType = 0 )
Descrio:
Busca por colnias abertas: seleciona os objetos das as colnias abertas
Parmetros:
isType - define um critrio de seleo dos objetos das colnias:
isType = 0 (default) - seleo de todos os objetos, tipos ou no
isType = 1 - seleo de objetos que so tipos
Exemplos:
vResult->SearchObject( );
Parmetros:
Exemplos:
Busca todos os objetos das colnias abertas:
SiriusObjectCursor *vResult = new SiriusObjectCursor;
Mtodo:
void SearchObject ( SOID typeOId )
Descrio:
Busca por tipo: seleciona, em colnias abertas, os objetos de um

determinado tipo
Parmetros:
typeOId - OId do tipo de objeto
Exemplos:
Busca todos os objetos do tipo Person:

SOID personOId;
SiriusObject *vPerson = new SiriusObject;
vPerson->ReadObject( Person, METATYPE );
personOId = vPerson->GetOId( );
vResult->SearchObject( personOId );
Mtodo:
void SearchObject ( SOID typeOId, SString attribName,

SData value )
Descrio:
Busca por valor: seleciona, em colnias abertas, os objetos de um

determinado tipo que possuem um valor especfico para um atributo
Parmetros:
typeOId - OId do tipo de objeto
attribName - nome do atributo
value - valor a ser procurado
Exemplos:
Busca os objetos do tipo Person que possuem o valor doctor para o

atributo Profession:
vResult->SearchObject( personId, Profession,doctor );
Mtodo:
void SearchObject ( SiriusColony *colony, int isType = 0 )
Mtodo:
bool EndOfObjects( )
Descrio:
Busca por colnia: seleciona os objetos de uma colnia
Descrio:
Verifica se o cursor est no fim do conjunto de OIds recuperados na

consulta
Parmetros:
Parmetros:
Retorno:
1 - todos os OIds foram percorridos
0 - ainda existem OIds a serem percorridos
Exemplos:
Busca todos os objetos do tipo Person, cujo OId personId, e percorre

todo o conjunto de OIds selecionados, processando-os um a um:
colony - referncia para a colnia aberta onde deve ser feita a busca
isType - define um critrio de seleo dos objetos da colnia:
isType = 0 (default) - seleo de todos os objetos, tipos ou no
isType = 1 - seleo de objetos que so tipos
Exemplos:
Busca todos os objetos na colnia do tipo Countries, constrita pelo

objeto Europe, representado no sobrestante vEurope:
SOID object;
vResult->SearchObject( personOId );
SiriusColony *vEuroCountries = new SiriusColony;

vEuroCountries->OpenColony(Countries,vEurope );
vResult->SearchObject( vEuroCountries );
while ( !vResult->EndOfObjects( ) )
{
object = vResult->GetObject( );
.....
}
Seleciona apenas os objetos que so tipos:

vResult->SearchObject(vEuroCountries, 1);
Mtodo:
Mtodo:
~SiriusObjectCursor ( )
Descrio:
Destrutor da classe
SOID GetObject ( )
Descrio:
Retorna o OId apontado pelo cursor interno que manipula o conjunto de

OIds recuperados numa consulta anterior. O cursor passa a apontar o
prximo elemento do conjunto.
Parmetros:
Retorno:
SOID - OId do objeto
Exemplos:
SOID object = vResult->GetObject( );
Classe SiriusAttribute
Uma instncia da classe SiriusAttribute, chamada de sobrestante atributo, uma
representao em memria de um atributo vinculado a um objeto armazenado na base de
dados e representado num sobrestante objeto.
Mtodo:
SiriusAttribute ( )
Descrio:
Construtor da classe: cria um sobrestante atributo vazio.
Mtodo:
~SiriusAttribute ( )
Descrio:

sobrestante atributo, no tendo efeito algum sobre o atributo armazenado
na base de dados.
Mtodo:
SString GetName ( )
Descrio:
Recupera o nome do atributo
Parmetros:
Retorno:
SString - nome do atributo
Exemplos:
Recupera o nome do atributo representado no sobrestante vAddr:

SString attribName = vAddr->GetName( );
Mtodo:
SFeature GetFeature ( )
Descrio:
Recupera a caracterstica do atributo
Parmetros:
Retorno:
SFeature - caracterstica do atributo
Exemplos:
Acessa o atributo Address do objeto Person e recupera a caracterstica

deste atributo:
SiriusAttribute *vAddr;
vAddr = vPerson->GetAttribute( Address );
SFeature ftr = vAddr->GetFeature( );
if ( ftr == TEXT ) { ... };
Mtodo:
SClassification GetClassificationInfo ( )
Descrio:
Recupera, numa estrutura SClassification, todas as informaes inerentes

abstrao de classificao.
Parmetros:
Retorno:
SClassification - propriedades da abstrao de classificao
Exemplos:
Retorna as propriedades de classificao de Age em Person:

SiriusAttribute *vAge;
SClassification classInfo;
vAge = vPerson->GetAttribute( Age );
classInfo = vAge->GetClassificationInfo( );
Resultado:
classInfo.level == 1;
classInfo.id == NON-IDENTIFIER;
classInfo.dflt == NON-DEFAULT;
classInfo.def == DEFINED;
classInfo.fix == FIX;
Mtodo:
SAggregation GetAggregationInfo ( )
Descrio:
Retorna, numa estrutura SAggregation, todas as informaes inerentes

abstrao de agregao.
Parmetros:
Parmetro de retorno:
SAggregation - propriedades da abstrao de agregao
Exemplos:
Retorna as propriedades de agregao do atributo Age do objeto Person

SiriusAttribute *vAge;
SAggregation aggregInfo;
vAge = vPerson->GetAttribute( Age );
aggregInfo = vAge->GetAggregationInfo( );
Resultado:
aggregInfo.org == MONOVALUED;
aggregInfo.lBound == 1;
aggregInfo.uBound == 2;
Mtodo:
Descrio:
Uma instncia da classe SiriusAttribText chamada de sobrestante atributo, e representa um

atributo com caracterstica Texto.
Mtodo:
SiriusAttribText ( )
Descrio:
Construtor da classe - cria um sobrestante atributo vazio
Mtodo:
SiriusAttribText ( SString attribName )
Descrio:
Construtor da classe - cria um sobrestante atributo, criando um atributo

com caracterstica Texto
Parmetros:
attribName - nome do atributo criado
Exemplos:
Cria o atributo Profession com caracterstica Texto no sobrestante

vProfession:
bool operator== ( SiriusAttribute& )

Verifica se dois sobrestantes atributo representam o mesmo atributo de
um objeto
SiriusAttribText *vProfession =
new SiriusAttribText( Profession );
Verifica se vAge e vProfession representam o mesmo atributo:
Vincula o atributo Profession ao objeto Person, onde classInfo

encapsula as propriedades de classificao e aggregInfo as propriedades
de agregao:
if (vAge == vProfession ) { ... };
vPerson->AddAttribute( vProfession, classInfo, aggregInfo );
Parmetros:
Exemplos:
Classe SiriusAttribText
(derivada da classe SiriusAttribute)
Mtodo:
void SetValue( STextValue value )
Mtodo:
void DeleteValue ( STextValue value )
Descrio:
Atribui um valor ao atributo
Descrio:
Remove um valor do atributo
Parmetros:
value - valor a ser atribudo ao atributo
Parmetros:
Exemplos:
Exemplos:
SiriusAttribText *vNicknames;
vNicknames = (SiriusAttribText *)
vJohn->GetAttribute( Nicknames );
vNicknames->DeleteValue( Jonny );
Atribui o valor doctor para o atributo Profession do objeto John:

SiriusAttribText *vProfession;
vProfession = (SiriusAttribText *)
vJohn->GetAttribute( Profession );
vProfession->SetValue( doctor );
Mtodo:
STextValue GetValue( )
Descrio:
Os valores de um atributo so armazenados numa lista interna ao

sobrestante atributo. Um cursor percorre a lista toda e retorna um a um
os valores para a aplicao.
O mtodo GetValue recupera o valor apontado pelo cursor, e o cursor
passa a apontar o prximo elemento da lista.
Parmetros:
Retorno:
STextValue - valor do atributo
Exemplos:
Recupera o valor do atributo Profession do objeto John:

vProfession = (SiriusAttribText*)
STextValue value = vProfession->GetValue( );
Resultado:
value == doctor
Remove o valor Jonny do atributo Nicknames do objeto John:
Mtodo:
SiriusAttribute operator= ( SiriusAttribute&)
Descrio:
Atribui o contedo de um sobrestante atributo da classe SiriusAttribute

para um sobrestante atributo da classe SiriusAttribText
Parmetros:
Exemplos:
SiriusAttribText *textAttrib = new SiriusAttribText;

SiriusAttribute *vProf;
vProf = vJohn->GetAttribute( Profession );
*textAttrib = *vProf;
Mtodo:
bool EndOfValues( )
Mtodo:
void UpdateValue ( STextValue currentValue,

STextValue newValue )
Descrio:
Verifica se a lista de valores foi percorrida at o final, ou seja, se ainda

existem valores a serem percorridos
Descrio:
Modifica um valor do atributo
Parmetros:
Parmetros:
Exemplos:
Retorno:
0 - ainda existem valores a serem percorridos
1 - todos os valores foram percorridos
currentValue - valor atual do atributo

newValue - novo valor do atributo
Verifica se um atributo tem mais de um valor:

SiriusAttribText *vAttrib;
vAttrib = (SiriusAttribText *)
vObject->GetAttribute( attribute
);
STextValue value = vAttrib->GetValue( );
if ( !vAttrib->EndOfValues( ) )
then atributo tem outros valores
else atributo no tem outros valores
Recupera os valores do atributo Nicknames do objeto John:

STextValue value;
while( !vNicknames->EndOfValues( ) )
{
value = vNicknames->GetValue( );
// processa valor ...
}
Exemplos:
Altera o valor do atributo monovalorado Profession do objeto John:

STextValue currentValue = doctor;
STextValue newValue = engineer;
vProfession = (SiriusAttribText *)
vProfession->UpdateValue(currentValue, newValue );
Altera um dos valores do atributo multivalorado Nicknames do objeto

John:
vNicknames->UpdateValue( Jo, Jonny );
Classe SiriusAttribNumber
Uma instncia da classe SiriusAttribNumber chamada de sobrestante atributo, e representa
um atributo com caracterstica Nmero.
Mtodo:
SiriusAttribNumber ( )
Descrio:
Mtodo:
SiriusAttribNumber ( SString attribName )
Descrio:

com caracterstica Nmero
Parmetros:
Exemplos:
Mtodo:
void SetValue ( SNumberValue value )
Descrio:
Atribui um valor ao atributo
Parmetros:
value - valor a ser atribudo ao atributo
Exemplos:
Atribui o valor 25 para o atributo Age do objeto John:

vAge = (SiriusAttribNumber *)
vAge->SetValue( 25 );
vJohn->GetAttribute( Age );
Mtodo:
SNumberValue GetValue( )
Descrio:
Recupera o valor apontado pelo cursor, e o cursor passa a apontar o

prximo elemento da lista.
Cria um sobrestante vAge para representar o atributo Age com

caracterstica Nmero:
Parmetros:
Retorno:
SNumberValue - valor do atributo
Exemplos:
Recupera o valor do atributo monovalorado Age do objeto John:
SiriusAttribNumber *vAge = new SiriusAttribNumber( Age );
Vincula o atributo Age ao objeto Person, onde classInfo e aggregInfo

encapsulam respectivamente as propriedades de classificao e
agregao:
vPerson->AddAttribute( vAge, classInfo, aggregInfo );
SNumberValue value;
vAge = (SiriusAttribNumber *)
value = vAge->GetValue( );
Resultado:
value == 25;
vJohn->GetAttribute( Age );
Mtodo:
bool EndOfValues( )
Mtodo:
void UpdateValue ( SNumberValue currentValue,

SNumberValue newValue )
Descrio:
Verifica se a lista de valores foi percorrida at o final, ou seja, se ainda

existem valores a serem percorridos
Descrio:
Modifica um valor do atributo
Parmetros:
Parmetros:
Exemplos:
Retorno:
0 - ainda existem valores a serem percorridos
1 - todos os valores foram percorridos
currentValue - valor atual do atributo

newValue - novo valor do atributo
Verifica se um atributo tem mais de um valor:

SiriusAttribNumber *vAttrib;
SNumberValue value;
vAttrib = (SiriusAttribNumber *)
vObject->GetAttribute( attribute );
value = vAttrib->GetValue( );
if ( !vAttrib->EndOfValues( ) )
then atributo tem outros valores
else atributo no tem outros valores
Exemplos:
SNumberValue currentValue = 25";
SNumberValue newValue = 26";
vAge = (SiriusAttribNumber *) vJohn->GetAttribute( Age );
vAge->UpdateValue( currentValue, newValue );
Altera um dos valores do atributo BankAccounts do objeto John:
Recupera os valores do atributo BankAccounts do objeto John:
SiriusAttribNumber *vBankAc;
vBankAc = (SiriusAttribNumber *)
vJohn->GetAttribute( BankAccounts );
vBankAc->UpdateValue(22334", 22335);
SNumberValue value;
vJohn->GetAttribute( BankAccounts );
while( !vBankAc->EndOfValues( ) )
{
value = vBankAc->GetValue( );
// processa valor ...
}
Altera o valor do atributo Age do objeto John:
Mtodo:
void DeleteValue ( SNumberValue value )
Descrio:
Remove um valor do atributo
Parmetros:
value - valor a ser removido
Exemplos:
Remove o valor 22335 do atributo BankAccounts do objeto John:

vJohn->GetAttribute( BankAccounts
);
vBankAc->DeleteValue( 22335 );
Mtodo:
Descrio:

para um sobrestante atributo da classe SiriusAttribNumber
Parmetros:
Exemplos:
SiriusAttribNumber *numberAttrib = new SiriusAttribNumber;

SiriusAttribute *vProfession;
vProfession = vJohn->GetAttribute( Age );
*numberAttrib = *vProfession;
Mtodo:
~SiriusAttribNumber ( )
Descrio:

na base de dados.
Classe SiriusAttribAttrib
Uma instncia da classe SiriusAttribAttrib chamada de sobrestante atributo, e representa
um atributo com caracterstica Atributo de Atributo.
Mtodo:
SiriusAttribAttrib ( )
Descrio:
Mtodo:
SiriusAttribAttrib ( SString attribName )
Descrio:

com caracterstica Atributo de Atributo
Parmetros:
Exemplos:
Cria um sobrestante vPassport para representar o atributo Passport com

caracterstica Atributo de Atributo:
SiriusAttribAttrib *vPassport =
new SiriusAttribAttrib( Passport
);
Vincula o atributo Passport ao objeto Person, onde classInfo e

aggregInfo encapsulam respectivamente as propriedades de classificao
e agregao:
vPerson->AddAttribute( vPassport, classInfo, aggregInfo );
Mtodo:
void AddSubAttribute ( SiriusAttribute *attribute,

IdFlag isIdentifier = NON-IDENTIFIER )
Descrio:
Cria um sub-atributo para estrutura do Atributo de Atributo
Parmetros:
Exemplos:
Mtodo:
SiriusAttribute* GetSubAttribute ( SString attribName)
Descrio:
Acessa um sub-atributo do Atributo de Atributo
Parmetros:
attribName - nome do atributo a ser acessado
attribute - sobrestante atributo que representa o sub-atributo

isIdentifier - flag indicando se o sub-atributo identificador na estrutura
do Atributo de Atributo. Default: NON-IDENTIFIER
Retorno:
SiriusAttribute* - referncia para o sobrestante atributo que representa
o sub-atributo requerido
Cria o atributo Passport Number e vincula-o como sub-atributo

identificador do Atributo de Atributo Passport:
Exemplos:
SiriusAttribNumber *vPassNr =
new SiriusAttribNumber( Passport Number);
vPassport->AddSubAttribute(vPassNr,IDENTIFIER);
Cria o atributo Issued by e vincula-o como sub-atributo no identificador

do Atributo de Atributo Passport:
Acessa o sub-atributo Issue by do Atributo de Atributo Passport e atribui

o valor DPFB para o sub-atributo:
SiriusAttribText *vIssued = (SiriusAttribText*)
vPassport->GetSubAttribute(Issued by);
vIssued->SetValue(DPFB)
Mtodo:
DeleteSubAttribute (SString attribName)
Descrio:
Remove um sub-atributo do Atributo de Atributo
Parmetros:
attribName - nome do sub-atributo a ser removido
Exemplos:
Remove Issued by do Atributo de Atributo Passport:
SiriusAttribText *vIssued = new SiriusAttribText(Issued by);

vPassport->AddSubAttribute(vIssued);
vPassport->DeleteSubAttribute(Issued by);
Mtodo:
SiriusAttribute* GetIdSubAttribute ( )
Descrio:
Acessa o sub-atributo identificador do Atributo de Atributo
Parmetros:
Retorno:
SiriusAttribute* - referncia para o sobrestante atributo que representa
o sub-atributo identificador
Exemplos:
Uma instncia da classe SiriusAttributeCursor, chamada de sobrestante cursor atributo,

armazena referncias para um conjunto de atributos de um objeto recuperados numa consulta,
segundo algum critrio.
Mtodo:
SiriusAttributeCursor ( )
Descrio:

atributos recuperados em uma consulta. O conjunto de atributos
percorrido atravs de cursores definidos para esta estrutura.
Acessa o sub-atributo identificador do Atributo de Atributo Passport:

SiriusAttribute *vAttrib;
vAttrib = vPassport->GetIdSubAttribute( );
SString attribName = vAttrib->GetName( );
Parmetros:
Resultado:
Exemplos:
SiriusAttributeCursor *vResult = new SiriusAttributeCursor;
Mtodo:
~SiriusAttributeCursor ( )
Descrio:
Destrutor da classe
Mtodo:
void SearchAttribute ( SiriusObject *object )
Descrio:
Seleciona os atributos de um objeto representado num sobrestante objeto
Parmetros:
object - sobrestante objeto que representa o objeto do qual sero
selecionados os atributos
Exemplos:
Seleciona todos os atributos do objeto Person:
attribName == Passport Number
Mtodo:
Descrio:

para um sobrestante atributo da classe SiriusAttribAttrib
Parmetros:
Exemplos:
Classe SiriusAttributeCursor
SiriusAttribAttrib *attribAttrib = new SiriusAttribAttrib;

SiriusAttribute *vPassport;
vPassport = vJohn->GetAttribute(Passport);
*attribAttrib = *vPassport;
Mtodo:
~SiriusAttribAttrib ( )
Descrio:

na base de dados.
vResult->SearchAttribute( vPerson );
Mtodo:
SiriusAttribute* GetAttribute ( )
Descrio:
Retorna uma referncia para o sobrestante atributo apontado pelo cursor

no conjunto resultante de uma consulta. O cursor passa a apontar o
prximo sobrestante atributo do conjunto.
Classe SiriusColonyType
Uma instncia da classe SiriusColonyType, chamada de sobrestante tipo de colnia, uma
representao em memria de um tipo de colnia definido na base de dados.
Mtodo:
SiriusColonyType ( )
Parmetros:
Retorno:
SiriusAttribute * - referncia para um sobrestante atributo que representa
um atributo do objeto
Descrio:
Construtor da classe - cria um sobrestante tipo de colnia vazio para

representar um tipo de colnia definido na base de dados.
Exemplos:
SiriusAttribute *attrib;
attrib = vResult->GetAttribute( );
Mtodo:
~SiriusColonyType ( )
Descrio:
Mtodo:
bool EndOfAttributes ( )

sobrestante tipo de colnia, no tendo efeito algum sobre o tipo de
colnia definido na base de dados.
Descrio:
Verifica se ainda existem sobrestantes atributo apontados pelo cursor no

conjunto resultante de uma consulta
Mtodo:
void ReadColType ( SString typeName )
Descrio:
Recupera um tipo de colnia definido na base de dados
Parmetros:
typeName - nome do tipo de colnia a ser lido
Exemplos:
Traz para o sobrestante vCountries as informaes do tipo de colnia

Countries:
Parmetros:
Exemplos:
Retorno:
0 - ainda existem atributos a serem percorridos
1 - todos os atributos foram percorridos
Seleciona todos os atributos do objeto Person, cujo OId personId, e
percorre todo o conjunto de atributos selecionados, imprimindo um a um
os nomes dos atributos:
SiriusAttribute * attrib;
vResult->SearchAttribute( personId );
while( !vResult->EndOfAttributes( ) )
{
attrib = vResult->GetAttribute( );
attribName = (attrib->GetName( )).c_str( );
printf( %s, attribName);
}
SiriusColonyType *vCountries = new SiriusColonyType;

vCountries->ReadColType( Countries );
Mtodo:
SOID GetCHDObject ( )
Mtodo:
void CreateColType( SString colName, SOID ctrObject )
Descrio:
Recupera o OId do tipo de objeto que constringe o tipo de colnia,

segundo o DHC (Colonies Hierarchical Diagram - CHD).
Descrio:
Cria um novo tipo de colnia
Parmetros:
Parmetros:
Retorno:
SOID - OId do tipo de objeto
Exemplos:
colName - nome do tipo de colnia a ser criado

ctrObject - OId do tipo de objeto que constringe o tipo de colnia
Recupera o OId do tipo de objeto que constringe o tipo de colnia

Countries:
SOID object = vCountries->GetCHDObject( );
Mtodo:
void DeleteColType ( )
Descrio:
Remove da base de dados o tipo de colnia representado no sobrestante
Parmetros:
Exemplos:
Remove o tipo de colnia Countries:

vCountries->DeleteColType(
);
Exemplos:
Cria um tipo de colnia Countries constrito pelo objeto Continent:

SiriusObject *vContinent = new SiriusObject;
vContinent->ReadObject( Continent,METATYPE );
SOID obj = vContinent->GetOId( );
SiriusColonyType *vCountries = new SiriusColonyType;
vCountries->CreateColType( Countries, obj );
Classe SiriusColony
Uma instncia da classe SiriusColony, chamada de sobrestante colnia, uma representao
em memria de uma colnia definida na base de dados.
Mtodo:
SiriusColony ( )
Descrio:
Construtor da classe - cria um sobrestante colnia vazio para representar

uma colnia da base de dados
Mtodo:
bool IsOpen ( )
Descrio:
Verifica se a colnia est aberta para a aplicao
Parmetros:
Retorno:
1 - colnia aberta
0 - colnia fechada
Exemplos:
Mtodo:
~SiriusColony ( )
Descrio:

sobrestante colnia, no tendo efeito algum sobre a colnia armazenado
na base de dados.
Mtodo:
void OpenColony ( SString colType, SiriusObject *ctrObject)
Descrio:
Abre uma colnia definida na base de dados.
Parmetros:
colType - nome do tipo da colnia a ser aberta
ctrObject - sobrestante objeto que representa o objeto que constringe a
colnia , de acordo com o Diagrama de Representao de Instncias
Fecha a colnia EuroCountries, se estiver est aberta:

if (vEuroCountries->IsOpen( ))
vEuroCountries->CloseColony( );
Mtodo:
SString GetType ( )
Descrio:
Recupera o nome do tipo da colnia
Parmetros:
Retorno:
SString - nome do tipo da colnia
Exemplos:
Recupera o nome do tipo da colnia representada no sobrestante

vEuroCountries:
SString typeName = vEuroCountries->GetType( );
Resultado:
typeName == Countries
Exemplos:
Traz para o sobrestante vEuroCountries as informaes da colnia do

tipo Countries, constrita pelo objeto Europe, representado no sobrestante
vEurope:
SiriusColony *vEuroCountries = new SiriusColony;
vEuroCountries->OpenColony ( Countries, vEurope );
Mtodo:
void CreateColony ( SString colName, SiriusObject *ctrObject )
Mtodo:
SOID GetIRDObject ( )
Descrio:
Cria uma nova colnia
Descrio:
Recupera o OId do objeto que constringe a colnia, segundo o DRI

(Instances Representation Diagram - IRD)
Parmetros:
Parmetros:
Retorno:
SOID - OId do objeto que constringe a colnia
Exemplos:
Recupera o OId do objeto que constringe a colnia representada no

sobrestante vEuroCountries:
colName - nome do tipo da colnia a ser criada

ctrObject - sobrestante objeto que representa o objeto que constringe a
colnia
Exemplos:
Cria uma colnia do tipo Countries constrita pelo objeto Asia,

representado no sobrestante vAsia
SiriusColony *vAsianCountries = new SiriusColony;
vAsianCountries->CreateColony( Countries,vAsia );
SOID obj = vEuroCountries->GetIRDObject(
);
Mtodo:
void DeleteColony ( )
Remove da base de dados a colnia representada no sobrestante
Mtodo:
void ReadColony ( SString colName, SOID ctrObject )
Descrio:
Descrio:
L as informaes de nova colnia definida na base de dados
Parmetros:
Parmetros:
Exemplos:
Remove da base a colnia do tipo Countries e constrita pelo objeto Asia:

vAsianCountries->DeleteColony(
);
colName - nome do tipo da colnia

ctrObject - OId do objeto que constringe a colnia
Exemplos:
L a colnia do tipo Countries constrita pelo objeto Asia, cujo OId

asiaId:
Mtodo:
void CloseColony ( )
Descrio:
Fecha a colnia aberta para a aplicao
SiriusColony *vAsianCountries = new SiriusColony;

vAsianCountries->ReadColony( Countries,asiaId );
Parmetros:
Exemplos:
Fecha a colnia do tipo Countries, constrita pelo objeto Europe.

vEuroCountries->CloseColony( );
Classe SiriusColonyCursor
Uma instncia da classe SiriusColonyCursor, chamada de sobrestante cursor colnia,
armazena colnias recuperadas numa consulta, segundo algum critrio.
Mtodo:
Descrio:
Mtodo:
void SearchCHDTypes ( SOID ctrObject )
Descrio:
Busca todos os tipos de colnia constritos por um tipo de objeto, de

acordo com o DHC (Colonies Hierarchical Diagram - CHD).
Parmetros:
ctrObject - OId do tipo de objeto
Exemplos:
Busca todos os tipos de colnia constritos pelo objeto Continent, cujo

OId contId
SiriusColonyCursor ( )
colnias recuperadas em uma consulta. O conjunto de colnias
percorrido atravs de cursores definidos para esta estrutura.
Obs: a colnia identificada pelo nome de seu tipo e pelo OId do objeto
que a constringe.
Parmetros:
Exemplos:
Mtodo:
SiriusColonyCursor *vResult = new SiriusColonyCursor;
vResult->SearchCHDTypes( contId );
Mtodo:
void SearchOpenColonies ( )
Descrio:
Busca todas as colnias abertas para a aplicao
void SearchCHDTypes ( )
Parmetros:
Descrio:
Busca todos os tipos de colnia definidos na base de dados, de acordo

com o DHC (Colonies Hierarchical Diagram - CHD).
Parmetros:
Exemplos:
Exemplos:
vResult->SearchOpenColonies( );
Mtodo:
void SearchColony ( SOID ctrObject )
Descrio:
Busca todas as colnias constritas por um objeto
Parmetros:
ctrObject - OId do objeto
Exemplos:
Busca todas as colnias constritas por Europe, cujo OId EuroId:
Busca todos os tipos de colnia definidos na base:

vResult->SearchCHDTypes(
);
vResult->SearchColony( EuropeId );
Mtodo:
void SearchColony ( SString colType )
Mtodo:
bool EndOfColonies ( )
Descrio:
Busca todas as colnias de um determinado tipo
Descrio:
Verifica se ainda existem colnias apontadas pelo cursor no conjunto de

colnias selecionadas na consulta
Parmetros:
colName - nome do tipo de colnia
Parmetros:
Retorno:
Exemplos:
0 - ainda existem colnias a serem percorridas

1 - todas as colnias foram percorridas
Busca todas as colnias do tipo Countries

vResult->SearchColony( Countries );
Exemplos:
Mtodo:
SString GetColony ( SOID *ctrObject = 0 )
Descrio:
Retorna a colnia apontada pelo cursor que manipula o conjunto de

colnias selecionadas numa consulta anterior
Parmetros:
Parmetro de retorno:
ctrObject - OId do objeto que constringe a colnia. O parmetro default
= Null pode ser utilizado quando feita busca de tipos de colnias, pois
estes podem ser identificados apenas por seus nomes.
Busca todas as colnias abertas e percorre todo o conjunto recuperado

na consulta, processando as colnias uma a uma:
SString colName;
SOID ctrObject;
vResult->SearchOpenColonies( );
while (!vResult->EndOfColonies( ) )
colName = vResult->GetColony(&ctrObject);
Busca todos os tipos de colnia definidos na base de dados e imprime os

nomes dos tipos recuperados:
SString typeName;
vResult->SearchCHDTypes( );
while (!vResult->EndOfColonies( ) ) {
typeName = vResult->GetColony( );
printf( %s, typeName.c_str( ) );
}
Retorno:
SString - nome do tipo da colnia
Exemplos:
Mtodo:
~SiriusColonyCursor ( )
Descrio:
Destrutor da classe
Classe SiriusError
A classe SiriusError destina-se ao tratamento de erros da API, numa abordagem similar ao
tratamento de excees disponvel na biblioteca padro da linguagem C++. Na implementao
da API, a ocorrncia de um erro, ou de uma situao que pode gerar inconsistncia na base,
gera uma exceo que pode ser tratada na aplicao atravs dos comandos try e catch da
linguagem C++.
Mtodo:
SErrorId GetErrorId ( )
Descrio:
Retorna o identificador do erro ocorrido
Parmetros:
Retorno:
SErrorId - identificador do erro
Exemplos:
Na criao do objeto Math, verifica se o tipo de objeto Course existe:

SiriusObject *vObj = new SiriusObject;
try
{
vObj->CreateObject( Math, Course);
}
catch (SiriusError error)
{
SErrorId errorId = error.GetErrorId( );
if ( errorId == UNKNOWN_TYPE )
printf( Tipo de objeto no existe);
}
Mtodo:
SString GetErrorMessage ( )
Descrio:
Retorna a mensagem correspondente ao erro ocorrido
Parmetros:
Retorno:
SString - mensagem de erro
Exemplos:
Na criao do objeto Math, imprime mensagem de erro:

SiriusObject *vObj = new SiriusObject;
try
{
vObj->CreateObject( Math, Course);
}
{
SString message = error.GetErrorMessage( );
printf( Erro: %s, message.c_str( ) );
}
Mtodo:
~SiriusError( )
Descrio:
Destrutor da classe
Classe SIRIUS
Esta classe responsvel por operaes de interface com o gerenciador de dados. Um objeto
da classe SIRIUS representa uma conexo com a base de dados.
Mtodo:
SIRIUS ( )
Descrio:
Construtor da classe
Mtodo:
~SIRIUS ( )
Descrio:
Destrutor da classe
Mtodo:
void Connect (SString databaseAlias, SString username,

SString password )
Descrio:
Estabelece a conexo com a base de dados.
Parmetros:
databaseAlias - alias que identifica a base de dados
username - nome do usurio
password - senha do usurio
Exemplos:
Estabelece uma conexo do usurio SYSDBA com a base de dados

identificada atravs do alias SIRIUS:
SIRIUS *base = new SIRIUS;
base->Connect(SIRIUS,SYSDBA,masterkey);
Mtodo:
int BeginTransaction ( )
Descrio:
Inicia uma transao.
Parmetros:
Retorno:
int - identificador da transao
Exemplos:
Define um vetor para gerenciar as transaes e inicia uma transao na

base de dados:
int trans[N];
trans[0] = base->BeginTransaction( );
...
Mtodo:
void AbortTransaction ( int transId )
Descrio:
Aborta uma transao.
Parmetros:
transId - identificador da transao
Exemplos:
Aborta a transao na ocorrncia de um erro:

int trans[N];
try
{
...
}
{
base->AbortTransaction( trans[0] );
}
Mtodo:
void CommitTransaction ( int transId )
Descrio:
Finaliza uma transao.
Parmetros:
transId - identificador da transao
Exemplos:
Finaliza a transao com sucesso ou aborta a transao na ocorrncia de

erros:
int trans[N];
try
{
...
base->CommitTransaction( trans[0] );
}
base->AbortTransaction( trans[0] );
Mtodo:
void Disconnect ( )
Descrio:
Finaliza a conexo com a base de dados.
Parmetros:
Exemplos:
base->Disconnect( );
Tipos de dado definidos na API

struct SOID - Object Identifier
Membros:
unsigned long int address (endereo lgico do objeto na base de dados)
unsigned long int counter (identifica o objeto como n-simo objeto
a ocupar o endereo lgico)
SString - tipo definido para manipular strings, como nome de objeto, nome de atributo,
nome de tipo de colnia e mensagem de erro.
Obs: o tipo SString utiliza uma classe especfica do C++ Builder para essa tarefa: a classe
AnsiString. Quando uma varivel declarada do tipo SString, qualquer string pode ser
atribuda a esta varivel. Quando o valor dessa varivel precisa ser utilizado como um char*,
como na funo printf, o mtodo c_str( ) retorna o valor da varivel como char*.
SFeature - Caracterstica de atributo: enum { TEXT, NUMBER, ATTRIBATTRIB }
STextValue - Valor para atributos com caracterstica Texto: string
SNumberValue - Valor para atributos com caracterstica Nmero: inteiro ou real
SData - Valor para atributos Texto ou Nmero.
SOrganization - Referente abstrao de agregao - organizao do atributo quando
vinculado a um objeto: enum { MONOVALUED, MULTIVALUED }.
SBound - Referente abstrao de agregao - valor inteiro para limites inferior e superior
do nmero de valores que podem ser assumidos por um atributo quando vinculado a um
objeto.
SLevel - Referente abstrao de classificao - nvel de instanciao na hierarquia de
classificao.
SIdFlag - Referente abstrao de classificao - flag indicando se o atributo ou no
identificador do objeto num determinado nvel de instanciao, ou se o sub-atributo
identificador de um atributo de atributo: enum {IDENTIFIER, NON_IDENTIFIER }.
SDefFlag - Referente abstrao de classificao - flag indicando se o atributo possui valor
definido, indefinido ou valor nulo: enum {DEFINED, UNDEFINED, NULL_VALUE}.
SDfltFlag - Referente abstrao de classificao - flag indicando se o atributo possui
valor default ou no: enum { DEFAULT, NON_DEFAULT}.

SFixFlag - Referente abstrao de classificao - flag indicando se o atributo fixo ou
no: enum { FIX, NON_FIX}.
struct SAggregation - estrutura que armazena as propriedades da abstrao de
agregao.
Membros:
SOrganization org;
SBound lBound;
SBound uBound;
struct SClassification - estrutura que armazena as propriedades da abstrao de
classificao.
Membros:
SLevel level;
SIdFlag id;
SDefFlag def;
SDfltFlag deflt;
SFixFlag fix;
SErrorId - identificador de erros:
enum { SYSTEM_OBJECT,
UNKNOWN_TYPE,
UNKNOWN_OBJECT,
UNKNOWN_COLONY_TYPE,
UNKNOWN_COLONY,
UNKNOWN_ATTRIBUTE,
UNKNOWN_VALUE,
UNDEFINED_COLONY,
UNDEFINED_IDENTIFIER,
CLOSED_COLONY,
TRANSIENT_OBJECT,
DUPLICATED_NAME,
DUPLICATED_ATTRIBUTE,
DUPLICATED_IDENTIFIER,
DUPLICATED_VALUE,
DUPLICATED_COLONY_TYPE,
DUPLICATED_COLONY,
TYPE_MISMATCH,
VALUES_OVERFLOW,
CHD_ERROR }
Error Id
Error Message
SYSTEM_OBJECT
"Access denied - System-defined object"
UNKNOWN_TYPE
"Type doesn't exist"
UNKNOWN_OBJECT
"Object doesn't exist"
UNKNOWN_COLONY_TYPE
"Colony type doesn't exist"
UNKNOWN_COLONY
"Colony doesn't exist"
UNKNOWN_ATTRIBUTE
"Attribute doesn't exist"
UNKNOWN_VALUE
"Value doesn't exist"
UNDEFINED_COLONY
"Colony not defined"
UNDEFINED_IDENTIFIER
"Identifier not defined"
CLOSED_COLONY
"Colony not open"
TRANSIENT_OBJECT
"Object isn't a persistent object"
DUPLICATED_NAME
"Name already defined"
DUPLICATED_ATTRIBUTE
"Attribute already linked to the object"
DUPLICATED_IDENTIFIER
"Identifier already exists for the specified level"
DUPLICATED_VALUE
"Value already set to the attribute"
DUPLICATED_COLONY_TYPE
"Colony type already exists"
DUPLICATED_COLONY
"Colony already exists"
TYPE_MISMATCH
"Incompatible value type"
VALUES_OVERFLOW
"Upper Bound already reached"
CHD_ERROR
"Object type doesn't constringe the colony type"

Sousa Mestrado

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Sousa Mestrado

Hochgeladen von

Copyright:

Verfügbare Formate

Emulao de um Gerenciador de Dados Orientado a

Objetos atravs de uma Interface de Programao de

Elaine Parros Machado de Sousa

Dissertao apresentada ao Instituto de Cincias Matemticas e de Computao

ICMC - USP, So Carlos

Trabalho realizado com auxlio da FAPESP

CONSIDERAES INICIAIS ......................................................................................... 1

CONCEITOS DE SGBDOOS E PADRES.............................................................. 5

SISTEMAS ORIENTADOS A OBJETOS ............................................................... 26

MODELO DE DADOS SIRIUS ................................................................................ 39

API DO GERENCIADOR SIRIUS........................................................................... 50

EDITOR DE ESQUEMAS SIRIUS .......................................................................... 72

CONSIDERAES INICIAIS ....................................................................................... 79

FIGURA 1 - UTILIZAO DE UM SGBDOO........................................................................... 15

SIRIUS ORIGINAL .................................................................... 76

SIRIUS REFORMULADO ........................................................... 77

TABELA 1 - COMPARAO ENTRE APIS DE SGBDOO ......................................................... 12

Application Program Interface

Computer-Aided Software Engineering

Computer Integrated Manufacturing

Data Definition Language

Diagrama Hierrquico de Colnias

Data Manipulation Language

Diagrama de Representao de Instncias

Open Database Connectivity

Object Definition Language

Object Database Management Group

Object Interchange Format

Object Manipulation Language

Object Query Language

Sistema de Gerenciamento de Base de Dados

Sistema de Gerenciamento de Base de Dados Orientado a Objetos

Tipo Abstrato de Dado

1.1 Consideraes Iniciais

Computer-Aided Software Engineering

experimentais. Alm disso, alguns padres [Cattell_94] [Cattell_95] [Cattell_97]

1.2 Objetivos do Trabalho

dados orientado a objetos padro, incluindo um maior conjunto de abstraes do que o

1.3 Organizao do Trabalho

O Captulo 4 apresenta o Modelo de Dados SIRIUS, descrevendo seus principais conceitos

2 Conceitos de SGBDOOs e Padres

2.2 Caractersticas de SGBDOOs

2 Conceitos de SGBDOOs e Padres

tipos ou classes, herana, sobrecarga (polimorfismo), binding atrasado (late binding),

Persistncia - os dados (objetos) de um processo (ou transao) persistem aps o

Gerenciamento de armazenamento secundrio - caracterstica clssica de SGBDs

Controle de concorrncia - gerenciamento de mltiplos usurios interagindo

Recuperao de falhas - capacidade de, em caso de falhas de software ou hardware,

Mecanismo de consulta - realizao de consultas base de dados. Uma consulta dever

Objetos complexos - suporte a objetos grandes em tamanho (objetos complexos

Identidade de objetos - cada objeto da base de dados deve possuir um identificador

2 Conceitos de SGBDOOs e Padres

Encapsulamento - um objeto da base de dados encapsula dados que definem sua

Tipos, classes e herana - suporte a hierarquias de tipos ou hierarquias de classes

Sobrecarga (polimorfismo) - permite que um mesmo nome de operao seja utilizado

Binding atrasado ou dinmico - realiza a traduo de nomes das operaes em

Extensibilidade - o conjunto de tipos pr-definidos do sistema deve ser extensvel,

Completude computacional - um SGBD computacionalmente completo possui uma

2 Conceitos de SGBDOOs e Padres

Sistemas baseados em linguagens de programao orientadas a objetos - integram

Sistemas relacionais estendidos - possuem modelo de dados relacional e linguagem

Sistemas baseados em modelos de dados orientados a objetos - baseados em

2 Conceitos de SGBDOOs e Padres

Shutdown e Startup do sistema - uma aplicao deve indicar ao SGBDOO que