XIII.

1

LOBJET-RELATIONNEL ET SQL3

1. INTRODUCTION
Le dveloppement des SGBD objet sest rapidement heurt la ncessit de conserver la
compatibilit avec lexistant. En effet, la fin des annes 80 a vu le dploiement des SGBD
relationnels et des applications client-serveur. Les utilisateurs ntaient donc pas prts remettre
en cause ces nouveaux systmes ds le dbut des annes 90.
Cependant, les tables relationnelles ne permettaient gure que la gestion de donnes
alphanumriques. Avec lavnement du Web au milieu de la dcennie 90, la ncessit de
supporter des donnes complexes au sein de la base de donnes sest amplifie. Ces donnes
complexes peuvent tre des documents textuels, des donnes gomtriques ou gographiques,
audiovisuelles ou soniques. En bref, il sagit de supporter de manire intelligente des donnes
multimdia (voir figure XIII.1).

Figure XIII.1 Le besoin de types de donnes multimdia
Ce chapitre est consacr ltude du modle objet-relationnel et du langage de requtes associ
SQL3. SQL3 est une extension de SQL2, dveloppe par le groupe de normalisation ANSI X3
H2 et internationalise au niveau de lISO par le groupe ISO/IEC JTC1/SC21/WG3. Il sagit de

XIII.2
la nouvelle version de SQL. SQL3 comporte beaucoup daspects nouveaux, lessentiel tant sans
doute son orientation vers une intgration douce de lobjet au relationnel. Ce chapitre traite en
dtail de cette intgration et survole les autres aspects de SQL3.
Aprs cette introduction, la section 2 motive lintgration de lobjet au relationnel, en soulignant
les forces et faiblesses du relationnel, qui justifient la fois sa conservation et son extension. La
section 3 dfinit les notions de base drives de lobjet et introduites pour tendre le relationnel.
La section 4 propose une vue densemble de SQL3 et du processus de normalisation. La section 5
dtaille le support des objets en SQL3 avec de nombreux exemples. La section 6 rsume les
caractristiques essentielles du langage de programmation de procdures et fonctions SQL/PSM,
appoint essentiel SQL pour assurer la compltude en tant que langage de programmation. Nous
concluons ce chapitre en soulignant quelques points obscurs et lintrt dune fusion entre OQL
et SQL3.
2. POURQUOI INTEGRER LOBJET AU RELATIONNEL ?
Le modle relationnel prsente des points forts indiscutables, mais il a aussi des points faibles.
Lobjet rpond ces faiblesses. Do lintrt dune intgration douce.
2.1 Forces du modle relationnel
Le relationnel permet tout dabord une modlisation des donnes adapte la gestion laide de
tables dont les colonnes prennent valeurs dans des domaines alphanumriques. Le concept de
table dont les lignes constituent les enregistrements successifs est simple, bien adapt pour
reprsenter par exemple des employs, des services, ou des paiements. Avec SQL2, les domaines
se sont diversifis. Les dates, les monnaies, le temps et les intervalles de temps sont parfaitement
supports.
Dans les annes 80, les SGBD relationnels se sont centrs sur le transactionnel (On Line
Transaction Processing OLTP) et sont devenus trs performants dans ce contexte. Les annes
90 ont vu le dveloppement du dcisionnel (On Line Analysis Processing OLAP). Le
relationnel sest montr capable dintgrer la prsentation multidimensionnelle des donnes
ncessaire lOLAP. En effet, il est simple de coder un cube 3D en table, trois colonnes
mmorisant les valeurs dune dimension et la quatrime la grandeur analyse.
En bref, grce au langage assertionnel puissant que constitue le standard universel SQL2, sa
bonne adaptation aux architectures client-serveur de donnes, sa thorie bien assise aussi bien
pour la conception des bases (normalisation), loptimisation de requtes (algbre, rcriture,
modle de cots) et la gestion de transactions (concurrence, fiabilit) intgre, le relationnel
sest impos dans lindustrie au cours des annes 80.
2.2 Faiblesses du modle relationnel
Le relationnel prsente cependant des faiblesses qui justifient son extension vers lobjet. Tout
dabord, les rgles de modlisation imposes pour structurer proprement les donnes savrent
trop restrictives.

XIII.3
Labsence de pointeurs visibles par lutilisateur est trs pnalisante. Dans les architectures
modernes de machine o la mmoire accs directe est importante, il devient intressant de
chaner directement des donnes. Le parcours de rfrences est rapide et permet dviter les
jointures par valeurs du relationnel. Des enregistrements volumineux reprsentant de gros objets
peuvent aussi tre stocks une seule fois et points par plusieurs lignes de tables : le partage
rfrentiel dobjets devient ncessaire. Par exemple, une image sera stocke une seule fois, mais
pointe par deux tuples, un dans la table Employs, lautre dans la table Clients. Passer par une
cl didentification (par exemple, le numro de scurit sociale) ncessite un accs par jointure,
opration lourde et coteuse. En clair, il est temps de rhabiliter les pointeurs sous la forme
didentifiants dobjets invariants au sein du relationnel.
Le non-support de domaines composs impos par la premire forme normale de Codd est
inadapt aux objets complexes, par exemple aux documents structurs. Lintroduction de champs
binaires ou caractres longs (Binary Large Object BLOB, Character Large Object CLOB)
et plus gnralement de champs longs (Large Object LOB) est insuffisante.
Notion XIII.1 : Objet long (Large Object)
Domaine de valeurs non structures constitu par des chanes de caractres (CLOB) ou de
bits (BLOB) trs longues (pouvant atteindre plusieurs giga-octets) permettant le stockage
dobjets multimdia dans les colonnes de tables relationnelles.
Les objets longs prsentent deux inconvnients majeurs : ils ne sont pas structurs et ne
supportent pas les recherches associatives. La seule possibilit est de les lire squentiellement. Ils
sont donc particulirement insuffisants pour le stockage intelligent de documents structurs, o
lon souhaite accder par exemple une section sans faire dfiler tout le document. En clair, il
faut pouvoir lever la contrainte datomicit des domaines, serait-ce que pour stocker des attributs
composs (par exemple ladresse compose dune rue, dun code postal et dune ville) ou
multivalus (par exemple les points dune ligne).
La non intgration des oprations dans le modle relationnel constitue un manque. Celui-ci
rsulte dune approche traditionnelle o lon spare les traitements des donnes. Certes, les
procdures stockes ont t introduites dans le relationnel pour les besoins des architectures
client-serveur, mais celles-ci restent spares des donnes. Elles ne sont pas intgres dans le
modle. Il est par exemple impossible de spcifier des attributs cachs de lutilisateur, accessibles
seulement via des oprations manipulant ces attributs privs.
Tout ceci conduit un mauvais support des applications non standard telles que la CAO, la
CFAO, les BD gographiques et les BD techniques par les SGBD relationnels. En effet, ces
applications grent des objets structures complexes, composs dlments chans souvent
reprsents par des graphes. Le relationnel pur est finalement mal adapt. Il en va de mme pour
le support dobjets multimdia que lon souhaite pouvoir rechercher par le contenu, par exemple
des photos que lon souhaite retrouver partir dun portrait robot.

XIII.4
2.3 Lapport des modles objet
Les modles objet sont issus des langages objets. Ils apportent des concepts nouveaux importants
qui rpondent aux manques du relationnel, comme lidentit dobjets, lencapsulation, lhritage
et le polymorphisme.
Lidentit dobjet permet lintroduction de pointeurs invariants pour chaner les objets entre eux.
Ces possibilit de chanage rapide sont importantes pour les applications ncessitant le support de
graphes dobjets. On pourra ainsi parcourir rapidement des suite dassociations, par navigation
dans la base. Par exemple, passer dun compos ses composants puis la description de ces
composants ncessitera simplement deux parcours de pointeurs, et non plus des jointures longues
et coteuses.
Lencapsulation des donnes permet disoler certaines donnes dites prives par des oprations
et de prsenter des interfaces stables aux utilisateurs. Ceci facilite lvolution des structures de
donnes qui peuvent changer sans modifier les interfaces publiques seules visibles des
utilisateurs. Au lieu doffrir des donnes directement accessibles aux utilisateurs, le SGBD pourra
offrir des services cachant ces donnes, beaucoup plus stables et complets. Ceux-ci pourront plus
facilement rester invariants au fur et mesure de lvolution de la base de donnes.
Lhritage doprations et de structures facilite la rutilisation des types de donnes. Il permet
plus gnralement ladaptation de composants son application. Les composants pourront tre
des tables, mais aussi des types de donnes abstraits, cest--dire un groupe de fonctions
encapsulant des donnes caches. Il sera dailleurs possible de dfinir des oprations abstraites,
qui pourront, grce au polymorphisme, porter le mme nom mais sappliquer sur des objets
diffrents avec pour chaque type dobjet un code diffrent. Cela simplifie la vie du dveloppeur
dapplications qui na plus qu se soucier doprations abstraites sans regarder les dtails
dimplmentation sur chaque type dobjet.
2.4 Le support dobjets complexes
Lapport essentiel de lobjet-relationnel est sans doute le support dobjets complexes au sein du
modle. Ceci nest pas inhrent lobjet, mais plutt hrit des premires extensions tendant
faire disparatre la premire forme normale du relationnel. On parle alors de base de donnes en
non premire forme normale (NF
2
).
Notion XIII.2 : Non premire forme normale (Non First Normal Form - NF
2
)
Forme normale tolrant des domaines multivalus.
Un cas particulier intressant est le modle relationnel imbriqu [Scholl86].

XIII.5
Notion XIII.3 : Modle relationnel imbriqu (Nested Relational Model)
Modle relationnel tendu par le fait quun domaine peut lui-mme tre valu par des tables
de mme schma.
Par exemple, des services employant des employs et enregistrant des dpenses pourront
directement tre reprsents par une seule table externe imbriquant des tables internes :
SERVICES (N INT, CHEF VARCHAR, ADRESSE VARCHAR, {EMPLOYES (NOM, AGE)},
{DEPENSES (NDEP INT, MONTANT INT, MOTIF VARCHAR)})
Employs correspond une table imbrique (ensemble de tuples) de schma (Nom, Age) pour
chaque service, et de mme, Dpenses correspond une table imbrique pour chaque service.
Notons que le modle relationnel permet une imbrication plusieurs niveaux, par exemple,
Motif pourrait correspondre une table pour chaque dpense.
N Chef Adresse Employs Dpenses
25 Paris Patrick
Montant
185
Motif NDep
42 Eric
51
Services Services
24 Versailles Paul
Montant
134
219
Motif
037
NDep
Nom Age
Nom
Age
45 Pierre
37 Marie
1 2600 Livres
2 8700 Mission
3 15400 Portable
5 3000 Livres
7 4000 Mission
Julie

Figure XIII.2 Exemples de relations imbriques
Le multimdia, particulirement la gomtrie, a ncessit dintroduire des attributs multivalus
plus gnraux. Comme lobjet, lobjet-relationnel offre des collections gnriques prdfinies
telles que des listes, ensembles, tableaux qui peuvent tre imbriques pour reprsenter des objets
trs compliqus. Par exemple, on pourra dfinir une ligne comme une liste de points, chaque
point tant dfini par une abscisse et une ordonne. Une rgion pourra tre dfinie par une liste de
lignes ferme. Ces possibilits sont essentielles pour la reprsentation de structures complexes.
Celles-ci peuvent tre caches par des fonctions offertes aux utilisateurs afin den simplifier la
vision. Ainsi, objets complexes et encapsulation seront souvent coupls.
3. LE MODELE OBJET-RELATIONNEL
Le modle objet-relationnel est fond sur lide dextension du modle relationnel avec les
concepts essentiels de lobjet (voir figure XIII.3). Le cur du modle reste donc conforme au

XIII.6
relationnel, mais lon ajoute les concepts cls de lobjet sous une forme particulire pour faciliter
lintgration des deux modles.
Relationnel
Types utilisateurs
et encapsulation
Collection
et objets complexes
Rfrence
et identit
Hritage
et rutilisation

Figure XIII.3 Les extensions apportes au relationnel
3.1 Les concepts additionnels essentiels
Les types utilisateur permettent la dfinition de types extensibles utilisables comme des
domaines, supportant lencapsulation.
Notion XIII.4 : Type de donnes utilisateur (User data type)
Type de donnes dfinissable par lutilisateur compos dune structure de donnes et
doprations encapsulant cette structure.
Le systme de type du SGBD devient donc extensible, et nest plus limit aux types
alphanumriques de base, comme avec le relationnel pur et SQL2. On pourra par exemple dfinir
des types texte, image, point, ligne, etc. Les types de donnes dfinissables par lutilisateur sont
appels types abstraits (ADT) en SQL3. La notion de type abstrait fait rfrence au fait que
limplmentation est spcifique de lenvironnement : seule linterface dun type utilisateur est
visible.
Notion XIII.5 : Patron de collection (Collection template)
Type de donnes gnrique permettant de supporter des attributs multivalus et de les
organiser selon un type de collection.
Les SGBD objet-relationnels offrent diffrents types de collections, tels que le tableau
dynamique, la liste, lensemble, la table, etc. Le patron LISTE(X) pourra par exemple tre
instanci pour dfinir des lignes sous forme de listes de points : LIGNE LISTE(POINT).

XIII.7
Notion XIII.6 : Rfrence dobjet (Object Reference)
Type de donnes particulier permettant de mmoriser ladresse invariante dun objet ou
dun tuple.
Les rfrences sont les identifiants dobjets (OID) dans le modle objet-relationnel. Elles sont en
thorie des adresses logiques invariantes qui permettent de chaner directement les objets entre
eux, sans passer par des valeurs ncessitant des jointures.
Notion XIII.7 : Hritage de type (Type inheritance)
Forme dhritage impliquant la possibilit de dfinir un sous-type dun type existant, celui-
ci hritant alors de la structure et des oprations du type de base.
Lhritage de type permet donc de dfinir un sous-type dun type SQL ou dun type utilisateur.
Une table correspondant un type sans opration, lobjet-relationnel permet aussi lhritage de
table.
Notion XIII.8 : Hritage de table (Table inheritance)
Forme dhritage impliquant la possibilit de dfinir une sous-table dune table existante,
celle-ci hritant alors de la structure et des ventuelles oprations de la table de base.
En rsum, le modle objet-relationnel conserve donc les notions de base du relationnel
(domaine, table, attribut, cl et contrainte rfrentielle) auxquelles il ajoute les concepts de type
utilisateur avec structure ventuellement prive et oprations encapsulant, de collections
supportant des attributs multivalus (structure, liste, tableau, ensemble, etc.), dhritage sur
relations et types, et didentifiants dobjets permettant les rfrences inter-tables. Les domaines
peuvent dornavant tre des types utilisateurs. La figure XIII.4 illustre tous ces concepts. Deux
vues sont possibles : la vue relationnelle dans laquelle les relations sont des relations entre objets
(voir figure XIII.5), chaque colonne tant en fait value par un objet ; la vue objet (voir figure
XIII.6) o une ligne dune table peut correspondre un objet simple (un tuple) ou complexe (un
tuple avec des attributs complexes).

XIII.8
Domaine
Table
Attribut
Cl
Rfrence
RELATIONNEL
OBJET
Opration
Hritage
Identifiant
Polymorphisme
Types
utilisateurs
Collections

Figure XIII.4 Les concepts de lobjet-relationnel
Rapport
134
219
Photo
037
Accident

Figure XIII.5 Une relation entre objets
24 Paris Paul
Conducteur Age
45 Paul
17 Robert
Rapport
134
219
Photo
037
Accident
Objet Police
Police Nom Adresse Conducteurs Accidents

Figure XIII.6 Un objet complexe dans une table

XIII.9
3.2 Les extensions du langage de requtes
Au-del du modle, il est ncessaire dtendre le langage de manipulation de donnes pour
supporter les nouvelles avances du langage de dfinition. SQL3 va donc comporter un langage
de requtes tendu avec notamment les appels doprations en rsultat et en qualification, la
surcharge des oprateurs de base de SQL (par exemple laddition), le support automatique de
lhritage, le parcours de rfrences, la constitution de tables imbriques en rsultat, etc. Nous
tudierons ces diffrentes fonctionnalits laide dexemples.
4. VUE DENSEMBLE DE SQL3
SQL3 est une spcification volumineuse, qui va bien au-del de lobjet-relationnel. Nous
examinons dans cette section ses principaux composants.
4.1 Le processus de normalisation
Au-del du groupe ANSI nord-amricain trs actif, la normalisation est conduite par un groupe
international dnomm ISO/IEC JTC1/SC 21/WG3 DBL, DBL signifiant Database Language.
Les pays actifs sont essentiellement lAustralie, le Brsil, le Canada, la France, lAllemagne, le
Japon, la Core, la Hollande, le Royaume-Uni et bien sr les Etats-Unis. Lessentiel du travail est
bien prpar au niveau du groupe ANSI X3H2 (http://www.ansi.org) dont Jim Melton est le
prsident. Ce groupe a dj ralis le standard SQL2 prsent dans la partie relationnelle. Les
standards accepts taient contrls aux Etats-Unis par le NIST (http://ncsl.nist.gov) qui
dfinissait des programmes de tests de conformit. Ceux-ci existent partiellement pour SQL2
mais pas pour SQL3. Depuis 1996, le congrs amricain a supprim les crdits du NIST si bien
quil ny a plus de programmes de validation esprs
4.2 Les composants et le planning
Alors que SQL2 tait un unique document [SQL92], SQL3 a t divis en composants pour en
faciliter la lisibilit et la manipulation, lensemble faisant plus de 1.500 pages. Les composants
considrs sont brivement dcrits dans le tableau reprsent figure XIII.7.

XIII.10
Partie Contenu Titre Description
1

le cadre SQL/Framework Une description non-technique de la faon
dont le document est structur et une
dfinition des concepts communs toute les
parties.
2 les fondements SQL/Foundation Le noyau de base, incluant les types de
donnes utilisateurs et le modle objet-
relationnel.
3

linterface client SQL/CLI Linterface dappel client permet le
dialogue client-serveur pour laccs aux
donnes via SQL2 puis SQL3.
4

les procdures
stockes
SQL/PSM Le langage de spcification de procdures
stockes.
5 lintgration aux
langages
classiques
SQL/Bindings Les liens SQL dynamique et embedded
SQL repris de SQL-92 et tendus SQL3.

6 la gestion de
transactions
SQL/Transaction Une spcification de linterface XA pour
moniteur transactionnel distribu.
7 la gestion du
temps
SQL/Temporal Le support du temps, des intervalles
temporels et des sries temporelles.
8 abandonn
9 laccs aux
donnes externes
SQL/MED Lutilisation de SQL pour accder des
donnes non-SQL.
10 lintgration aux
langages objet
SQL/OBJ Lutilisation de SQL depuis un langage
objet, tel C++, Smalltalk ou Java.

Figure XIII.7 Les composants de SQL3
Le planning de SQL3 a t dcal a plusieurs reprises, ces dcalages tmoignant de la difficult et
de lampleur de la tche. Les parties 1 7 de SQL sont ltat de brouillons internationaux (Draft
International Standard) depuis fin 1997. Ils devraient devenir de vritables standards fin 1998 ou
en 1999. Les deux derniers sont prvus pour lan 2000.
Au-del de SQL3, dautres composants sont prvus tels SQL/MM pour la spcification de types
utilisateurs multimdia et SQL/RDA pour la spcification du protocole RDA de transfert de
donnes entre client et serveur. On parle dj de SQL4, sans doute pour aprs lan 2000.
4.3 La base
Le composant 2 contient lessentiel du langage SQL3, en particulier les fonctionnalits de base
pour dfinir les autres composants (Basic SQL/CLI capabilities , Basic SQL/PSM capabilities),
les dclencheurs (Triggers), les types utilisateurs appels types abstraits (Abstract Data Types) et
les fonctionnalits orientes objets que nous allons tudier en dtail ci-dessous. Un mot sur les
dclencheurs : bien que partie intgrante du relationnel tudie en tant que telle au chapitre VIII,

XIII.11
les dclencheurs ne sont normaliss que dans SQL3. Il sagit l de combler une lacune de la
normalisation.
5. LE SUPPORT DES OBJETS
Dans cette section, nous allons prsenter lessentiel des commandes composant les
fonctionnalits objet de SQL3 : dfinition de types abstraits, support dobjets complexes, hritage
de type et de table. Pour chaque commande, nous donnons la syntaxe simplifie et quelques
exemples.
5.1 Les types abstraits
5.1.1 Principes
La premire nouveaut de SQL3 est lapparition dune commande CREATE TYPE. Au-del des
types classiques (numriques, caractres, date) de SQL, il devient possible de crer des types
dpendant de lapplication, multimdia par exemple (voir figure XIII.8). Une instance dun type
peut tre un objet ou une valeur. Un objet possde alors un OID et peut tre rfrenc . Une
valeur peut simplement tre copie dans une ligne dune table. Un type possde en gnral des
colonnes, soit directement visibles, soit caches et accessibles seulement par des fonctions
encapsulant le type. Les oprateurs arithmtiques de SQL (+, *, -, /) peuvent tre redfinis au
niveau dun type. Par exemple, on redfinira laddition pour les nombres complexes. Enfin, un
type peut possder des clauses de comparaison (=, <) permettant dordonner les valeurs et peut
tre reprsent sous la forme dun autre type, une chane de caractres par exemple.
Types
simples
Types
multimdias
Numrique 245
Caractres Jean
Date 20-Dec-98
Texte
Spatial
Image
Vido
Spcialis Application

Figure XIII.8 Exemples de types de donnes extensibles
5.1.2 Syntaxe
La syntaxe de la commande de dclaration de type est la suivante :
CREATE [DISTINCT] TYPE <NOM ADT> [<OPTION OID>] [<CLAUSE SOUS-TYPE>]
[AS] (<CORPS DE LADT>)
Le mot cl DISTINCT est utilis pour renommer un type de base existant dj, par exemple dans
la commande :

XIII.12
CREATE DISTINCT TYPE EURO AS (DECIMAL(9,2)
La clause :
<OPTION OID> ::= WITH OID VISIBLE
permet de prciser la visibilit de lOID pour chaque instance (objet). Par dfaut, une instance de
type est une valeur sans OID. Cette clause semble plus ou moins avoir disparue de la dernire
version de SQL3, le choix tant report sur les implmentations.
La clause :
<CLAUSE SOUS-TYPE> ::= UNDER <SUPERTYPE>[,<SUPERTYPE>]
permet de spcifier les super-types dont le type hrite. Il y a possibilit dhritage multiple avec
rsolution explicite des conflits.
La clause <CORPS DE LADT> se compose dune ou plusieurs clauses membres :
<CLAUSES MEMBRES> ::=
< DEFINITION DE COLONNE >
| < CLAUSE EGALE >
| < CLAUSE INFERIEURE>
| < CLAUSE CAST >
| < DECLARATION DE FONCTION >
| < DECLARATION DOPERATEUR >
La dfinition de colonne permet de spcifier les attributs du type sous la forme <NOM> <TYPE>.
Un type peut bien sr tre un type de base ou un type prcdemment cr par une commande
CREATE TYPE. Un attribut peut tre priv ou public, comme en C++. La clause gale permet de
dfinir lgalit de deux instances du type, alors que la clause infrieure dfinit loprateur
logique <, important pour comparer et ordonner les valeurs du type. La clause CAST permet de
convertir le type dans un autre type. Plusieurs clauses CAST sont possibles.
Une dclaration de fonction permet de dfinir les fonctions publiques qui encapsulent le type. Il
existe diffrents types de fonctions : les constructeurs permettent de construire des instances du
type ; ils portent en gnral le nom du type ; les acteurs agissent sur une instance en manipulant
les colonnes du type ; parmi les acteurs, il est possible de distinguer les observateurs qui ne font
que lire ltat et les mutateurs qui le modifient ; les destructeurs dtruisent les instances et
doivent tre appels explicitement pour rcuprer la place disque (pas de ramasse-miettes). Plus
prcisment, la syntaxe dune dfinition de fonction est la suivante :
<DECLARATION DE FONCTION> ::=
[<FUNCTION TYPE>] FUNCTION <FUNCTION NAME> <PARAMETER LIST>
RETURNS <FUNCTION RESULTS>
{ <SQL PROCEDURE> | <FILE NAME> } END FUNCTION
Le type est dfini par :

XIII.13
<FUNCTION TYPE> ::= CONSTRUCTOR | ACTOR | DESTRUCTOR
Les fonctions SQL3 ne sont pas forcment associes un type ; elles peuvent aussi tre associes
une base ou une table. Elles peuvent tre programmes en SQL, en SQL/PSM (voir ci-
dessous) ou dans un langage externe comme COBOL, C, C++ ou Java. Comme en C++, un
oprateur est une fonction portant un nom particulier et dclare comme oprateur.
5.1.3 Quelques exemples
Voici quelques exemples de cration de types :
1. Type avec OID pouvant tre utilis comme un objet :
CREATE TYPE PHONE WITH OID VISIBLE (PAYS VARCHAR, ZONE VARCHAR,
NOMBRE INT, DESCRIPTION CHAR(20))
2. Type sans rfrence :
CREATE TYPE PERSONNE (NSS INT, NOM VARCHAR, TEL PHONE)
3. Sous-type :
CREATE TYPE ETUDIANT UNDER PERSONNE (CYCLE VARCHAR, ANNEE INT)
4. Type numr :
CREATE TYPE JOUR-OUVRE (LUN, MAR, MER, JEU, VEN);
5. Type avec OID et fonction :
CREATE TYPE EMPLOYE WITH OID VISIBLE
(NOM CHAR(10), DATENAIS DATE, REPOS JOUR-OUVRE, SALAIRE FLOAT,
FUNCTION AGE (E EMPLOYE)RETURNS (INT)
{ CALCUL DE LAGE DE E }
END FUNCTION;);
6. Autre type sans OID avec fonction :
CREATE TYPE ADRESSE WITHOUT OID
(RUE CHAR(20), CODEPOST INT, VILLE CHAR(10),
FUNCTION DEPT(A ADRESSE) RETURNS (VARCHAR) END FUNCTION);
7. Cration de procdure SQL de mise jour associe au type employ :
CREATE procedure AUGMENTER (E EMPLOYE, MONTANT MONEY)
{ UPDATE EMPLOYE SET SALAIRE = SALAIRE + MONTANT WHERE EMPLOYE.OID = E}
END PROCEDURE
5.2 Les constructeurs dobjets complexes
SQL3 supporte la construction dobjets complexes par le biais de types collection
paramtrs. Ces types gnriques, appels patrons de collections, doivent tre fournis comme une
bibliothque avec le compilateur SQL3. Celui-ci doit assurer la gnricit et en particulier la
possibilit de dclarer des collections de types dobjets ou de valeurs quelconques. Chaque patron
de collection fournit des interfaces spcifiques pour accder aux lments de la collection.

XIII.14
Tout environnement SQL3 doit offrir les patrons de base SET(T), MULTISET(T) et
LIST(T). Un multiset, encore appel bag, se comporte comme un ensemble mais permet de
grer des doubles. Par exemple, il est possible de dfinir un type personne avec une liste de
prnoms et un ensemble de tlphones comme suit :
CREATE TYPE PERSONNE WITH OID VISIBLE
(NSS INT, NOM VARCHAR, PRENOMS LIST(VARCHAR), TEL SET(PHONE)).
Il est aussi possible de crer un ensemble de personnes :
CREATE TYPE PERSONNES (CONTENU SET (PERSONNE))
ou un ensemble didentifiants de personnes :
CREATE TYPE RPERSONNES (CONTENU SET(REF(PERSONNE))).
Au-del des types de collections SET, LIST et MULTISET, SQL3 propose des types
additionnels multiples : piles (stack), files (queue), tableaux dynamiques (varray), tableaux
inserables (iarray) pour grer des textes par exemple. Un tableau dynamique peut grandir par la
fin, alors quun tableau insrable peut aussi grandir par insertion partir dune position
intermdiaire (il peut donc grandir par le milieu). Ces types de collections sont seulement
optionnels : ils ne sont pas intgrs dans le langage de base mais peuvent tre ajouts.
De manire gnrale, il est possible de rfrencer des objets via des OID mmoriss comme
valeurs dattributs. De tels attributs sont dclars rfrences (REF) comme dans lexemple ci-
dessous :
CREATE TYPE VOITURE (NUMERO CHAR(9), COULEUR VARCHAR,
PROPRIETAIRE REF(PERSONNE))
5.3 Les tables
Les tables SQL restent inchanges, ceci prs que le domaine dun attribut peut maintenant tre
un type cr par la commande CREATE TYPE. De plus, des fonctions peuvent tre dfinies au
niveau dune table pour encapsuler les tuples vus comme des objets. Aussi, lhritage de table qui
permet de rutiliser une dfinition de table est possible.
Par exemple, la table reprsente figure XIII.5 sera simplement cre par la commande :
CREATE TABLE ACCIDENTS (ACCIDENT INT, RAPPORT TEXT, PHOTO IMAGE)
en supposant dfinis les types TEXT (texte libre) et IMAGE, qui sont gnralement fournis avec
un SGBD objet-relationnel, comme nous le verrons plus loin.
La table de la figure XIII.6 pourra tre dfinie partir des mmes types avec en plus :
CREATE TYPE CONDUCTEUR (CONDUCTEUR VARCHAR, AGE INT)
CREATE TYPE ACCIDENT (ACCIDENT INT, RAPPORT TEXT, PHOTO IMAGE)
par la commande :

XIII.15
CREATE TABLE POLICE (NPOLICE INT, NOM VARCHAR, ADRESSE ADRESSE, CONDUCTEURS
SET(CONDUCTEUR), ACCIDENTS LIST(ACCIDENT)).
SQL3 donne aussi des facilits pour passer dun type une table de tuples de ce type et
rciproquement, dune table au type correspondant.
Par exemple, en utilisant le type EMPLOYE dfini ci-dessus, il est possible de dfinir simplement
une table demploys par la commande :
CREATE TABLE EMPLOYES OF EMPLOYE ;
En dfinissant une table VINS, il sera possible de dfinir le type VIN compos des mmes
attributs comme suit :
CREATE TABLE VINS(NV INT, CRU VARCHAR, DEGRE FLOAT(5.2))
OF NEW TYPE VIN ;
Comme mentionn, lhritage de table qui recopie la structure est possible par la clause :
CREATE TABLE <TABLE> UNDER <TABLE> [WITH (LISTE DATTRIBUTS TYPES)].
La liste des attributs typs permet dajouter les attributs spcifiques la sous-table. Par exemple,
une table de vins millsim pourra tre cre par :
CREATE TABLE VINSMILL UNDER VINS WITH (MILLESIME INT, QUALITE VARCHAR).
5.4 Lappel de fonctions et doprateurs dans les requtes
Le langage de requtes est tendu afin de supporter les constructions nouvelles du modle.
Lextension essentielle consiste permettre lappel de fonctions dans les termes SQL, qui
peuvent figurer dans les expressions de valeurs slectionnes ou dans les prdicats de recherche.
Une fonction sapplique laide de la notation parenthse sur des termes du type des arguments
spcifis.
Considrons par exemple la table demploys contenant des instances du type EMPLOYE dfinit ci-
dessus. La requte suivante retrouve le nom et lge des employs de moins de 35 ans :
SELECT E.NOM, AGE(E)
FROM EMPLOYES E
WHERE AGE(E) < 35;
La notation pointe applique au premier argument est aussi utilisable pour invoquer les
fonctions :
SELECT E.NOM, E..AGE()
FROM EMPLOYES E
WHERE E..AGE() < 35;
Il sagit dun artifice syntaxique, la dernire version utilisant dailleurs la double notation pointe
(..) pour les fonctions et attributs composs, la notation pointe simple (.) tant rserve au SQL
de base (accs une colonne usuelle de tuple).

XIII.16
Au-del des fonctions, SQL3 permet aussi laccs aux attributs composs par la notation pointe.
Supposons par exemple une table demploys localiss dfinies comme suit :
CREATE TABLE EMPLOYESLOC UNDER EMPLOYES WITH (ADRESS ADRESSE).
La requte suivante permet de retrouver le nom et le jour de repos des employs des Bouches-du-
Rhne habitant Marseille :
SELECT NOM, REPOS
FROM EMPLOYESLOC E
WHERE DEPT(E.ADRESS) = "BOUCHES DU RHONE"
AND E.ADRESS..VILLE = "MARSEILLE";
Notons dans la requte ci-dessus lusage de fonctions pour extraire le dpartement partir du
code postal et lusage de la notation pointe pour extraire un champ compos. Nous prfrerons
utiliser partout la notation pointe ; il faut cependant distinguer fonction et accs attribut par la
prsence de parenthses.
Afin dillustrer plus compltement, supposons dfinis un type point et une fonction
distance entre deux points comme suit :
TYPE POINT ( ABSCISSE X, ORDONNEE Y,
FUNCTION DISTANCE(P1 POINT, P2 POINT) RETURN (REAL) ) ;
Considrons une implmentation des employs par la table :
EMPLOYES (MUNEMP INT, NOM VARCHAR, ADRESS ADRESSE, POSITION POINT) ;
La requte suivante recherche alors les noms et adresses de tous les employs moins de 100
units de distance (par exemple le mtre) de lemploy Georges :
SELECT E.NOM, E.ADRESS
FROM EMPLOYES G, EMPLOYES E
WHERE G.NAME = "GEORGES" AND DISTANCE(G.POSITION,E.POSITION) < 100.
Supposons de plus dfini le type CERCLE comme suit :
TYPE CERCLE (CENTRE POINT, RAYON REAL,
CONSTRUCTOR FUNCTION CERCLE(C POINT, R REAL) RETURN (CERCLE))
Ajoutons une fonction boolenne CONTIENT au type point :
CREATE FUNCTION CONTIENT (P POINT, C CERCLE)
{ CODE DE LA FONCTION } RETURN (BOLEAN)
END FUNCTION.
La question suivante retrouve les employs dont la position est contenu dans un cercle de rayon
100 autour de lemploy Georges :

XIII.17
SELECT E.NAME, E.ADRESS
FROM EMPLOYES G, EMPLOYES E
WHERE EMPLOYES.NOM = "GEORGES" AND
CONTIENT(E.POSITION, CERCLE(G.POSITION,1));
Les deux requtes prcdentes sont de fait quivalents et gnrent les mmes rponses.
5.5 Le parcours de rfrence
SQL3 permet aussi de traverser les associations reprsentes par des attributs de type rfrences.
Ces attributs peuvent tre considrs comme du type particulier rfrence, sur lequel il est
possible dappliquer les fonctions Ref pour obtenir la valeur de lOID et DeRef pour obtenir
lobjet point. Afin de simplifier lcriture, DeRef peut tre remplace par la notation . Celle-ci
permet donc les parcours de chemins. On peut ainsi crire des requtes mlangeant la notation
simple point (accs un attribut), double point (accs un attribut ADT compos) et flche
(parcours de chemins). Esprons que la notation point simple pourra tre utilise partout comme
une amlioration syntaxique !
Considrons le type VOITURE dj dfini ci-dessus comme suit :
CREATE TYPE VOITURE (NUMERO CHAR(9), COULEUR VARCHAR,
PROPRIETAIRE REF(PERSONNE)).
Crons une table de voitures :
CREATE TABLE VOITURES OF TYPE VOITURE.
La requte suivante recherche les noms des propritaires de voitures rouges habitant Paris :
SELECT V.PROPRIETAIRENOM
FROM VOITURES V
WHERE V.COULEUR = "ROUGE" AND V.PROPRIETAIREADRESSE..VILLE = "PARIS".
SQL3 permet de multiples notations abrges. En particulier, il est possible dviter de rpter
des prfixes de chemins avec la notation pointe suivie de parenthses. Par exemple, la requte
suivante recherche les numros des voitures dont le propritaire habite les Champs-Elyss Paris
et a pour prnom Georges :
SELECT V.NUMERO
FROM VOITURES V
WHERE V.PROPRIETAIRE(ADRESSE..(VILLE = "PARIS"
AND RUE = "CHAMPS ELYSES") AND PRENOM = "GEORGES").
5.6 La recherche en collections
Les collections de base sont donc les ensembles, listes et sacs. Ces constructeurs de collections
peuvent tre appliqus sur tout type dj dfini. Les collections sont rendues permanentes en
qualit dattributs de tables. La construction TABLE est propose pour transformer une collection
en table et lutiliser derrire un FROM comme une vritable table. Toute collection peut tre

XIII.18
utilise la place dune table prcde de ce mot cl TABLE. Par exemple, supposons lajout
dune colonne PASSETEMPS la table des personnes value par un ensemble de chanes de
caractres :
ALTER TABLE PERSONNES ADD COLUMN PASSETEMPS SET(VARCHAR).
La requte suivante retrouve les rfrences des personnes ayant pour passe-temps le vlo :
SELECT REF(P)
FROM PERSONNES P
WHERE "VELO" IN
SELECT *
FROM TABLE (P.PASSETEMPS).
Plus complexe, la requte suivante recherche les numros des polices dassurance dont un
accident contient un rapport avec le mot cl Pont de lAlma :
SELECT P.NPOLICE
FROM POLICE P, TABLE P.ACCIDENTS A, TABLE A.RAPPORT..KEYWORDS M
WHERE M = "PONT DE LALMA".
Cette requte suppose la disponibilit de la fonction KEYWORDS sur le type TEXT du rapport qui
dlivre une liste de mots cls. Nous tablons tout dabord la liste des accidents, puis la liste des
mots cls du rapport de chaque accident. Ceci donne donc une sorte dexpression de chemins
multivalus. SQL3 est donc trs puissant !
5.7 Recherche et hritage
Lhritage de tables est pris en compte au niveau des requtes. Ainsi, lorsquune table possde
des sous-tables, la recherche dans la table retrouve toutes les lignes qui qualifient au critre de
recherche, aussi bien dans la table que dans les sous-tables
Par exemple, considrons la table BUVEURS dfinie comme suit :
CREATE TABLE BUVEURS UNDER PERSONNES WITH ETAT ENUM(NORMAL,IVRE).
La recherche des personnes de prnom Georges par la requte :
SELECT NOM, PRENOM, ADRESSE
FROM PERSONNES
WHERE PRENOM = "GEORGES"
retournera la fois les personnes et les buveurs de prnom Georges.
6. LE LANGAGE DE PROGRAMMATION PSM
Le composant PSM dfinit un L4G adapt SQL. Il a t adopt tout dabord dans le cadre
SQL2, puis tendu SQL3.

XIII.19
6.1 Modules, fonctions et procdures
SQL/PSM (Persistent Store Modules) est un langage de programmation de modules persistants et
stocks dans la base de donnes [Melton98]. Les modules sont crs et dtruits par des
instructions spciales CREATE MODULE et DROP MODULE. Un module se compose de
procdures et/ou de fonctions. Il est possible de crer directement des procdures (CREATE
PROCEDURE) ou des fonctions (CREATE FUNCTION) non contenues dans un module. Un
module est associ un schma de base de donnes sur lequel peuvent tre dfinies des
autorisations et des tables temporaires. Il est aussi possible de dfinir des curseurs partags entre
les procdures et fonctions composantes.
SQL/PSM parachve SQL pour en faire un langage complet. Cependant, il est possible dcrire
des procdures stockes en pur SQL ou dans un langage pour lequel lintgration avec SQL est
dfinie (ADA, C, COBOL, FORTRAN, PASCAL, PL/I et MUMPS). Pour ces langages, PSM
permet de dfinir les paramtres dentre et de retour des procdures (mots cls IN pour les
paramtres dentre et OUT pour ceux de sortie) ou des fonctions (clause RETURN <type>),
Ces procdures sont en gnral invoques depuis des programmes htes par des ordres EXEC
SQL plus ou moins spcifiques du langage hte, ou directement depuis dautres procdures PSM
par des ordres CALL <procdure> ou des appels directs de fonctions.
6.2 Les ordres essentiels
Lintrt essentiel de SQL/PSM est de fournir un langage de programmation homogne avec
SQL et manipulant les mmes types de donnes. Ce langage comporte des dclarations de
variables, des assignations, des conditionnels CASE, IF, des boucles LOOP, REPEAT, WHILE,
FOR et des traitements derreurs et exceptions SIGNAL, RESIGNAL.
Une dclaration de variable est analogue une dclaration de colonne en SQL :
<DECLARATION DE VARIABLE> ::= DECLARE <VARIABLE> <TYPE> [DEFAULT <VALEUR>]
Par exemple, une dclaration possible est :
DECLARE PRIX INT DEFAULT 0 ;
Une assignation seffectue par une clause SET suivie dune expression de valeur conforme
SQL, ou par lassignation du rsultat dune requte dans une variable. Par exemple :
DECLARE MOYENNE DECIMAL(7.2)
SELECT AVG(SALAIRE) INTO MOYENNE FROM EMPLOYES
assigne le rsultat de la requte la variable MOYENNE.
Lordre CASE permet de tester diffrents cas de valeurs dune expression de valeur en paramtre
du CASE (expression de valeur1) ou de plusieurs expressions de valeurs boolennes :

XIII.20
<ORDRE CASE> ::=
CASE [<EXPRESSION DE VALEUR1>]
WHEN <EXPRESSION DE VALEUR2 > THEN <ORDRE SQL> ;
[WHEN <EXPRESSION DE VALEUR> THEN <ORDRE SQL> ;]
ELSE <ORDRE SQL> ;
END CASE
Par exemple :
CASE MOYENNE
WHEN <100 THEN CALL PROC1 ;
WHEN = 100 THEN CALL PROC2 ;
ELSE CALL PROC3 ;
END CASE
permet de traiter diffrents cas de la variable MOYENNE.
Les boucles LOOP, REPEAT et WHILE sont des boucles de calculs en mmoire classiques, qui ne
font pas directement appel la base. La boucle FOR permet au contraire de parcourir le rsultat
dune requte par le biais dun curseur. Sa syntaxe simplifie est la suivante :
<ORDRE FOR> ::=
[<ETIQUETTE> :]FOR <NOM DE BOUCLE>
AS [<NOM DE CURSEUR> CURSEUR FOR] <SPECIFICATION DE CURSEUR>
DO
<ORDRE SQL>
END FOR <ETIQUETTE> ;
Ltiquette permet de rfrencer la boucle FOR. Le nom de boucle sert de qualifiant pour les
colonnes de la table virtuelle correspondant au curseur, afin de les distinguer si ncessaire. Le
nom de curseur est optionnel pour permettre la rutilisation du curseur. Une dfinit ion de curseur
est classique en SQL : il sagit en gnral dune requte.
6.3 Quelques exemples
Voici la syntaxe des constructions essentielles du langage et un exemple de procdure et de
fonction. Nous travaillons sur la base des vins composes des tables :
VINS (NV INT, CRU VARCHAR, MILL INT, DEGRE FLOAT(5.2))
COMMANDES (NCO INT, NV INT, DAT DATE, QUANTITE INT)
Une procdure pour calculer la variance des quantits commandes dun cru donn en
paramtre peut tre dfinie comme suit :

XIII.21
CREATE PROCEDURE (IN C VARCHAR,
OUT VARIANCE DECIMAL(10.2))
BEGIN
DECLARE MOYENNE DECIMAL(10.2) ;
VARIANCE = 0 ;
SELECT AVG(QUANTITE) INTO MOYENNE
FROM COMMANDES C, VINS V
WHERE V.NV = C.NV AND V.CRU = C ;
BOUCLE1:
FOR M AS SELECT NCO, QUANTITE
FROM COMMANDES C, VINS V
WHERE V.NV = C.NV AND V.CRU = C
DO
SET VARIANCE = VARIANCE+(M.QUANTITE MOYENNE)**2
END FOR BOUCLE1 ;
END
Tout SQL est bien sr intgr PSM. Il serait possible dutiliser un curseur et une boucle WHILE
avec un FETCH dans la boucle la place de la boucle FOR.
Pour montrer la compltude du langage, nous dfinissons la fonction factorielle comme suit :
CREATE FUNCTION FACTORIELLE (N INT)
RETURNS INT
DETERMINISTIC
BEGIN
DECLARE FAC INT DEFAULT 1 ;
DECLARE I INT ;
SET I = N ;
WHILE I > 1 DO
FAC = FAC*I ;
I = I-1 ;
END WHILE ;
RETURN FAC ;
END
Dautres types de boucles peuvent bien sr tre utiliss pour calculer cette fonction [Melton98].
6.4 Place de PSM dans le standard SQL
SQL/PSM est un standard international dans sa version SQL2. Il a t intgr en 1996 au
standard SQL2. Une version plus complte est en cours de spcification pour SQL3. Cette
version prsentera lavantage de pouvoir utiliser les types abstraits et les collections de SQL3
dans le langage de programmation. SQL/PSM est assez proche des langages de quatrime

XIII.22
gnration de systmes tels quORACLE, INFORMIX ou SYBASE. Malheureusement, aucun
systme nimplmente actuellement exactement PSM.
7. CONCLUSION
SQL3 est un standard en volution. Comme nous lavons vu, les composants ne sont pas tous au
mme niveau davancement. La plupart sont au stade de brouillons internationaux, et vont donc
subir encore des modifications. Lensemble devrait tre termin vers lan 2000.
SQL3 se situe, au moins pour la partie objet et les interfaces avec les langages objet, comme un
concurrent de lODMG. Il est support par tous les grands constructeurs, comme IBM, Oracle et
Sybase, et est impliqu dans un processus de standardisation international. Au contraire, lODMG
est un accord entre quelques constructeurs de SGBD objet autour dun langage pur objet.
LODMG traite bien les aspects collections et, dans une moindre mesure, traverse de chemins.
Les deux propositions pourraient donc apparatre comme complmentaires, condition de
converger. Il existe dailleurs un accord entre les groupes ANSI X3 H2 responsable de SQL et
ODMG pour explorer la convergence. Souhaitons que cet accord aboutisse.
Dautres, comme Stonebraker [Stonebraker96], pensent plutt que les bases de donnes objet ont
un crneau dapplication diffrent de celui des bases de donnes objet-relationnel. Les premires
seraient plutt orientes vers les applications crites en C++ ou Java, naviguant dans les bases
mais ne formulant pas de questions complexes sur de gros volumes de donnes persistantes. Au
contraire, les bases de donnes objet-relationnel profiteraient de lorientation disque du
relationnel et seraient capables de supporter des questions complexes sur des donnes complexes.
La figure XIII.9 rsume ce point de vue. Il est possible de mesurer la complexit des requtes en
nombre de jointures et agrgats, la complexit des donnes en nombre dassociations. Cependant,
lvolution des systmes objet vers la compatibilit SQL, et donc vers lobjet-relationnel, pousse
par le march, ne plaide gure pour la validit de ce tableau.

Figure XIII.9 Relationnel, Objet ou Objet-Relationnel ?

XIII.23
Et aprs SQL3 ? On parle dj de SQL4, notamment pour les composants orients applications
ou mtiers. Il est en effet possible, voire souhaitable, de standardiser les types de donnes pour
des crneaux dapplications, tels le texte libre, la gographie ou le multimdia. Nous tudierons
plus loin ces types de donnes multimdia qui sont dactualit. Au-del, on peut aussi penser
dvelopper des types pour la CAO, la finance, lassurance ou lexploration ptrolire par
exemple. On aboutira ainsi des parties de schmas rutilisables, complment souhaitable
dobjets mtiers. Beaucoup de travail reste faire. Reste savoir si SQL est le cadre adquat, et
sil nest pas dj trop complexe pour tre tendu.
8. BIBLIOGRAPHIE
[Darwen95] H. Darwen, C-J. Date, Introducing the Third Manifesto , Database Programming
& Design Journal, Vol. 1, N8, pp 25-35, Jan. 1995.
Cet article plaide pour le modle objet-relationnel vu comme une extension naturelle du
relationnel, tel que propos par Codd (et Date). Pour C. Date, lapport essentiel utile du modle
objet est la possibilit de dfinir des types de donnes utilisateur. En clair, aucune modification
nest ncessaire au modle relationnel qui avait dj le concept de domaine : il suffit douvrir les
domaines et de les rendre extensibles.
[Gardarin89] Gardarin G., Cheiney J.P., Kiernan J., Pastre D., Managing Complex Objects in
an Extensible DBMS , 15
th
Very Large Data Bases International Conference, Morgan Kaufman
Pub., Amsterdam, Pays-Bas, aot 1989.
Une prsentation dtaille du support dobjets complexes dans le SGBD extensible Sabrina. Ce
systme est driv du SGBD relationnel SABRE et fut lun des premiers SGBD supportes des
types abstraits comme domaines dattributs. Il a ensuite volu vers un SGBD gographique
(GoSabrina) qui fut commercialis par la socit INFOSYS.
[Gardarin92] Gardarin G., Valduriez P., ESQL2: An Object-Oriented SQL with F-Logic
Semantics , 8
th
Data Engineering International Conf., Phoenix, Arizona, Feb. 1992.
Cet article dcrit le langage ESQL2, prcurseur de SQL3 compatible avec SQL2, permettant
dinterroger la fois des bases de donnes objets et relationnelles. Le langage supporte des
relations rfrenant des objets complexes. Une notation fonctionnelle est utilise pour les
parcours de chemins et les applications de mthodes. Une version plus labore de ESQL2 avec
classes et relations a t spcifie dans le projet EDS. La smantique base sur la F-Logic (une
logique pour objets) illustre les rapports entre les modles objets et logiques.
[Godfrey98] M. Godfrey, T. Mayr, P. Seshadri, T. von Eicken, Secure and Portable Database
Extensibility , Proc. of the 1998 ACM SIGMOD Intl. Conf. On Management of Data, ACM Pub.
SIGMOD Record Vol. 27, N2, pp. 390-401, Juin 1998.

XIII.24
Cet article dcrit limplmentation de types abstraits dans le SGBD PREDATOR en Java. Il
montre lintrt de fonctions sres et portables, mais souligne aussi les difficults de
performance par comparaison une implmentation en C++.
[Haas90] L. Haas, W. Chang, G.M. Lohman, J. McPherson, P.F. Wilms, G. Lapis, B. Lindsay, H.
Pirahesh, M. Carey, E. Shekita, Starburst Mid-Flight : As the Dust Clears , IEEE Transactions
on Knowledge and Data Engineering, Vol. 2, N1, Mars 1990.
Cet article dcrit Starburst, un des premiers SGBD objet-relationnel. Starbust a t implment
IBM Almaden, et fut un des prcurseurs de DB2 Universal Server. Il a conduit de nombreux
dveloppements autour de lobjet-relationnel, notamment des techniques dvaluation de
requtes.
[Melton98] J. Melton, Understanding SQLs Stored Procedures, Morgan Kaufman Pub., 1998.
Ce livre prsente la version 96 de PSM, intgre SQL2. Il est trs complet, aborde les diffrents
aspects (concepts de base, cration de modules et procdures, routines externes, polymorphisme,
contrles, extensions prvues) et donne un exemple dapplication.
[Scholl86] M. Scholl, S. Abiteboul, F. Bancilhon, N. Bidoit, S. Gamerman, D. Plateau, P.
Richard, A.Verroust, VERSO: A Database Machine Based On Nested Relations. Nested
Relations and Complex Objects , Intl. Workshop Theory and Applications of Nested Relations
and Complex Objects, Darmstadt, Germany, April 1987, in Lecture Notes in Computer Science,
Vol. 361, pp. 27-49, Springer Verlag 1989.
La machine bases de donnes Verso (Recto tant le calculateur frontal) fut dveloppe lINRIA
au dbut des annes 1980. Bas sur le modle relationnel imbriqu, ce projet a dvelopp un
prototype original intgrant un filtre matriel spcialis et la thorie du modle relationnel NF2.
[Seshadri97] Seshadri P., Livny M., Ramakrishnan R., The Case for Enhanced Abstract Data
Types , Proc. of 23
rd
Intl. Conf. On Very Large Databases, Athens, Greece, pp. 66-75, 1997.
Cet article plaide pour des types abstraits amliors exposant la smantique de leurs mthodes
sous forme de rgles. Il dcrit limplmentation et les techniques doptimisation de requtes dans
le systme PREDATOR. Dautres implmentation de types abstraits sont voques.
[Siberschatz91] A. Silberschatz, M. Stonebraker, J. Ullman, Next Generation Database Systems
Achievements and Opportunities , Comm. of the ACM, Vol. 34, N10, pp. 110-120, Oct.
1991.
Cet article fait le point sur lapport des systmes relationnels et souligne les points essentiels que
la future gnration de SGBD devra rsoudre.
[Stonebraker86] M. Stonebraker, L. Rowe, M. Hirohama, The Implementation of PostGres ,
IEEE Transactions on Knowledge and Data Engineering, Vol. 2, N1, pp. 125-142, Mars 1990.

XIII.25
Cet article dcrit limplmentation de PostGres, le systme ralis Berkeley aprs Ingres.
PostGres fut le premier systme objet-relationnel. Il a t plus tard commercialis sous le nom
dIllustra, qui fut rachet par Informix en 1996.
[Stonebraker96] Stonebraker M., D. Moore, Object-Relational DBMSs : The Next Great wave,
Morgan Kaufmann Pub., San Fransisco, CA, 1996.
Ce livre dfinit ce quest un SGBD objet-relationnel. Les fonctionnalits du SGBD Illustra sont
mises en avant pour situer les objectifs essentiels des systmes objet-relationnels, en particulier
du point de vue du modle de donnes, du langage de requtes et de loptimisation.
[Zaniolo83] C. Zaniolo, The Database Language GEM , Proc. of 1983 ACM SIGMOD Intl.
Conf. on Management of Data, San Jos, Ca, pp. 207-218, Mai 1983.
Cet article propose une extension du modle relationnel et du langage de requte QUEL pour
intgrer des tables fortement types, des gnralisations, des rfrences, des expressions de
chemins et des attributs multivalus. Il dcrit un langage de requtes prcurseur de SQL3.