ISNet15 16

IS-Net 15 Bases de données relationnelles objets
Informatique de gestion et
systèmes d’information
Implémentation
d'un modèle relationnel-objet
sur la base de données relationnelle
du MEN
Eddy.Meylan@hegne.ch / Octobre 2001

ISNet15_16
TABLE DES MATIERES
1 Introduction.......................................................................................................... 3
1.1 Modèle.......................................................................................................... 4
1.2 Schémas ...................................................................................................... 5
1.2.1 Modèle de classes cible ........................................................................ 6
1.2.2 Modèle E-A source ................................................................................ 7
1.3 Conventions syntaxiques.............................................................................. 8
1.4 Méthodes des classes .................................................................................. 8
1.4.1 Cotation ................................................................................................. 9
1.4.2 Dimensions............................................................................................ 9
1.4.3 Datation ................................................................................................. 9
1.4.4 Mis à jour complexes............................................................................. 9
1.4.5 Interfaçage XML .................................................................................... 9
2 Implémentation .................................................................................................. 10
2.1 Package pour la gestion des erreurs .......................................................... 10
2.2 Mise en place des types ............................................................................. 11
2.2.1 Types abstraits .................................................................................... 11
2.2.2 Types avec implémentation................................................................. 13
2.3 Création des vues....................................................................................... 19
2.3.1 Choix de l’identifiant ............................................................................ 19
2.4 Implémentation des triggers instead of....................................................... 20
2.4.1 vo_matiere........................................................................................... 20
2.4.2 vue vo_image ...................................................................................... 21
2.4.3 vo_element.......................................................................................... 22
2.4.4 vo_intervenant_financier ..................................................................... 23
2.4.5 vo_intervenant_intermediaire .............................................................. 24
2.4.6 vo_collection........................................................................................ 25
2.4.7 vo_ethnie............................................................................................. 27
2.4.8 vo_ordre_matiere ................................................................................ 27
2.4.9 vo_intervenant..................................................................................... 28
2.4.10 vue vo_objet ........................................................................................ 29
2.5 Méthodes.................................................................................................... 32
2.5.1 Méthodes de comportement................................................................ 32
2.5.2 méthodes de mise à jour ..................................................................... 39
2.5.3 Mise à jour des images........................................................................ 41
2.5.4 Méthodes d'intefaçage avec XML........................................................ 41
3 Remarques diverses.......................................................................................... 42
3.1 Création de modèles-objet ......................................................................... 42
3.2 Création de vues-objet avec collection ....................................................... 42
4 Conclusion......................................................................................................... 44
5 Versions............................................................................................................. 44
Implémentation d'une BDRO Page 2 sur 44 09/11/01

au MEN
1 Introduction
Ce document décrit les étapes de la mise en place d'un schéma objet-relationnels

sur la base de données du Musée d’Ethnographie de Neuchâtel (MEN). L'objectif
n’est pas mettre une base de données objet-relationnelle en exploitation au MEN
mais de valider les choix fait dans le projet sur une base véritable base de données
de production et d'ouvrir une réflexion sur la plus-value apportée par cette nouvelle
technologie.
Il s’agit donc ici d’un document pratique qui a pour but d’expliquer toute la mise en
œuvre de ces concepts et d'en démontrer les applications et avantages.
Les choix que nous avons fait pendant le projet seront appliqués, soit :
- Vues relationnelles objets avec double référencement.
- Mise en place de triggers instead of pour les mises à jour.
- Implémentation de méthodes de manipulation de données.
- Intégration de la gestion du texte et des images.
- Gestion centralisée d'erreurs (objet et relationnelles)
- Implémentation des méthodes d'interfaçage XML

au MEN
1.1 Modèle
Nous allons créer une couche relationnelle-objet par "dessus" la base de données
relationnelles de production du MEN.
Modèle relationnel-objet
Réalisation avec des

vues-objets
("updatable" par les
triggers Instead-of)
Modèle
relationnelexistant
Réalisatio avec des

tables, procedures,.
La base de données de production du MEN doit subire quelques modifications

mineurs (changement de types obsolètes et intégration des données multimédia,
texte et images). Ces modification sont décrites dans un autre document, elles
n'apporte pas d'éléments pour la compréhension de la démarche.
Nous avons choisi de créer deux schéma distincts (MEN pour le schéma existant et
MENOBJ pour les fonctionnalités RO1).
Cette séparation nous permet d'encapsuler proprement les données.
L'"utilisateur" MENOBJ doit alors avoir les droits d'accès sur les objets de MEN, et
les deux instructions suivantes devront être exécutées par l'utilisateur MEN pour
chaque table de son schéma.
La séquence sera utilisée lors de l’insertion pour auto-incrémentation de la clé
primaire numero
GRANT SELECT,INSERT,UPDATE,DELETE ON men.nom_table TO menobj ;
GRANT SELECT ON men.nom_sequence TO menobj ;
1
RO : Relationnel - Objet

au MEN
1.2 Schémas
Le modèle que nous allons mettre en place est représenté par un modèle de classe
UML se trouvant à la page suivante.
Nous avons sélectionné les classes en fonction de leur intérêt en étant attentif a être
en présence de tous les cas de figures de relations entre elles. (Liens de composition
ou références, liens mono-valués ou t multi-valués, références uniques ou croisées,
héritage, …).
Nous n'avons donc pas toutes les entités de bases mais nous estimons que la
migration du modèle complet n'apporterait pas d'enseignement supplémentaires.
Pour pouvoir évaluer les performances, nous avons pris l'ensemble des données,
On trouve ensuite le modèle E-A partiel de la base de données relationnelles,
contenant toutes les entités utilisées par le modèle objet.

au MEN
1.2.1 Modèle de classes cible

au MEN
1.2.2 Modèle E-A source

au MEN
1.3 Conventions syntaxiques

Avant d’entrer réellement dans la partie pratique, il est nécessaire de donner une
explication sur la symbolique utilisée lors du préfixage. Pour une meilleure
compréhension des différents mécanismes objet-relationnels, les préfixes suivants
ont toujours été utilisés :
vo_ vue objet

ty_ attribut dans un type
att_ attribut de type
Les tables relationnelles ainsi que leurs colonnes ne sont pas préfixées. Ceci nous
est imposé par le modèle existant.
1.4 Méthodes des classes

La nature même de la mise en place du modèle RO est la gestion d'objet complexe.
Avec la mise en place de méthodes, les points suivants seront traités:
• Gestion de la cotation des objets,

• Gestion du dimensionnement des objets et des éléments,
• Gestion des dates approximatives.
• Simplification des mises à jour complexes
• Interfaçage XML

au MEN
1.4.1 Cotation
La cotation des objets est standardisée, mais le standard a déjà changé trois fois et
pourrait être à nouveau modifié. Il s’agit donc de concevoir des outils permettant de
retourner la cote identifiant l’objet sachant qu’un objet peut posséder plusieurs cotes.
De plus, le type des cotes n'étant pas de type scalaire, un problème se pose lorsque
l'on souhaite ordonner des objets selon leur cotation.
1.4.2 Dimensions
La notion de dimensions d'un objets n'est pas triviale. Les attributs (hauteur,
longueur,…) dépendent de la forme de l'objet. De même des notions dérivées, tel
que le volume est également dépendant de la forme. Comment classer les objets
entre eux par rapport à leur grandeur ? Comment comparer un arc et un casque ?
1.4.3 Datation2
Un des problèmes le plus intéressant à résoudre réside dans la datation des objets. Il
est nécessaire de comprendre qu’un objet ou une collection peut être daté de trois
façons différentes.
- Soit sa date est connue de façon précise (17 juin 1969), on parle alors de date
exacte.
- Soit elle est connue de manière approximative (avant 1830, entre 1700 et 1890,
juin 45), on parle alors de date ordonnable, puisqu’elle peut être représentée sur
l’axe des temps
- Une date peut également être de type documentaire si l’on ne connaît par
exemple que le mois, sans en connaître l’année.
Pour permettre de dater un objet, six attributs doivent être renseignés: l’année, le
mois et le jour de début de la période, l’année, le mois et le jour de la fin de la
période.
La gestion des ces dates approximatives doit permettre de les comparer entre elles,
de les ordonner et de pouvoir répondre si une date approximative est dans un
intervalle donné.
1.4.4 Mis à jour complexes

La mise à jour des informations de la base de données nécessite un contrôle
sémantique parfois compliqué avant de valider la transaction. L'utilisation de
méthodes doit simplifier le travail du programmeur
1.4.5 Interfaçage XML

Des méthodes pour transformer les données de la base en format XML et
inversement seront systématiquement sur les classes non abstraites.
2
Voir le document traitant des dates approximatives

au MEN
2 Implémentation
2.1 Package pour la gestion des erreurs
Pour simplifier la mise en place de notre gestionnaire d'erreurs centralisé, un

package a été créé. Celui-ci fournira une procédure permettant de stocker les
variables d'environnement, ainsi que les informations nécessaires pour la création du
triggers sur événement. Notez bien, que pour pouvoir utiliser cette gestion, il faut
qu'une table "Erreur" existe ainsi que sa séquence.
Voici donc, comment ce package peut être utilisé dans l'implémentation du trigger
sur l'événement SERVERERROR.
CREATE OR REPLACE TRIGGER OnServerError
AFTER SERVERERROR ON SCHEMA
BEGIN
gestion_erreur.traite();
END;
/
La procédure traite() stocke dorénavant la pile d'erreurs émise. En effet, il n'est pas
rare d'occasionner plusieurs erreurs en même temps. De plus, elle stockera aussi le
message d'erreur d'Oracle, même si celui-ci ne comprend plus le nom du module
ayant provoqué l'erreur. (Voir document sur la gestion d'erreurs)
PROCEDURE traite AS
i NUMBER(9) := 1;
msg VARCHAR2(150);
BEGIN
LOOP
msg := SUBSTR(SQLERRM(-ora_server_error(i)), 1, 150);
INSERT INTO Erreur VALUES (
Seq_Erreur.NextVal,
ora_client_ip_address, /* Stockage des
ora_login_user, erreurs tant que la
ora_database_name, pile d'erreurs n'est
ora_server_error(i), pas vide */
msg,
SYSDATE);
i := i + 1;
EXIT WHEN (ora_server_error(i) = 0);
END LOOP;
END traite;

au MEN
2.2 Mise en place des types

La première phase a consiste à créer les différents types de données (classes) sur
lesquelles les vues objets se baseront. Pour une bonne compréhension de ces
types, il est nécessaire de se référer au modèle conceptuel de base du MEN afin de
percevoir les modifications apportées par l’utilisation des types.
L'explication des divers attributs des entités est notifiée au fur et à mesure de la
description des types.
Dans un premier temps, les informations répétitives contenues dans les tables ont
été recherchées pour être transformées en types abstraits, ceci afin de faciliter leur
manipulation et leur utilisation.
2.2.1 Types abstraits
2.2.1.1 ty_dimension
Les six attributs de dimensionnement sont utilisés tant dans la table OBJET que
dans la table ELEMENT ont étés regroupés dans le type ty_dimension.
L'implémentation de méthodes permet de calculer la forme et le volume de l'objet (ou

d'un élément) en fonction du renseignement des champs. Le qualificateur MAP
signifie que les dimensions seront ordonnées par volume.
CREATE OR REPLACE TYPE TY_DIMENSION AS OBJECT (

att_longueur FLOAT,
att_largeur FLOAT,
att_profondeur FLOAT,
att_diametre FLOAT,
att_circonference FLOAT,
att_poids FLOAT,
MEMBER FUNCTION forme RETURN VARCHAR,
MAP MEMBER FUNCTION volume RETURN REAL)

au MEN
2.2.1.2 ty_date_approx
Dans la base du MEN, les objets qui n’appartiennent pas à une collection possèdent
une date. Dans le cas contraire, c’est la collection qui est datée. Les dates sont
gérées de manière spéciale dans la base de données du MEN. Pour comprendre
cette gestion, nous renvoyons le lecteur au document traitant de la problématique
des dates approximatives. Un type ty_date_approx, regroupant les six attributs
définissant une date a été créé.
CREATE OR REPLACE TYPE TY_DATE_APPROX AS OBJECT (

att_jour_debut NUMBER(2) ,
att_mois_debut NUMBER(2) ,
att_annee_debut NUMBER(4) ,
att_jour_fin NUMBER(2) ,
att_mois_fin NUMBER(2) ,
att_annee_fin NUMBER(4) ,
MEMBER FUNCTION TypeDate RETURN NUMBER ,
MEMBER FUNCTION DateOrder RETURN DATE ,
ORDER MEMBER FUNCTION Compare(par_date ty_date_approx)
RETURN INTEGER,
MEMBER FUNCTION EstDansIntervalle(date1 date, date2
date DEFAULT SYSDATE
Optimiste VARCHAR
DEFAULT 'true')
RETURN BOOLEAN ,
MEMBER FUNCTION EstDansIntervalleNumber(date1 date,
date2 date DEFAULT
SYSDATE, Optimiste
VARCHAR DEFAULT 'true')
RETURN NUMBER) ;
/
Les méthodes implémentées sont abondamment documentées dans le document

traitant spécifiquement des dates approximatives.
2.2.1.3 ty_adresse
Ce type sera utile pour mettre en place notre simulation d'héritage, en stockant de
manière identique une adresse d'une personne morale ou physique.
CREATE OR REPLACE TYPE ty_Adresse AS OBJECT (

att_rue VARCHAR2(60),
att_casePostale VARCHAR2(20),
att_npa VARCHAR2(10),
att_localite VARCHAR2(40),
MEMBER FUNCTION getAdresse RETURN VARCHAR2);
/

au MEN
2.2.2 Types avec implémentation

Une fois les types abstraits créés, nous pouvont décrire les type qui seront à la base
des vues objets. Pour ne pas surcharger inutilement ce document, seuls les
spécificités de ces types sont décrits. On trouve dans la documentation du projet, les
scripts de création de ces types.
2.2.2.1 ty_image et ty_table_images

Un objet peut être représenté par plusieurs images, qui sont anciennement stockées
sous forme de fichier sur le serveur. L'utilisation des fonctionnalités multi-média du
SGBD a passablement modifier la structure de la table de base image, puisque
l'ensembles des images du MEN sont stockés dans la base de données.
CREATE OR REPLACE TYPE TY_IMAGE AS OBJECT (
att_numero NUMBER(9),
att_vue VARCHAR2(50),
att_img_high_def BFILE ,
att_img_low_def BLOB ,
att_signature RAW )
/
En plus du type ty_image, il faut créer un type ty_table_images pour regrouper une
collection d'images, regroupant toutes les prises de vues d'un objet.
2.2.2.2 ty_element
Un objet peut être composé de nombreux éléments distincts, qui possèdent plusieurs
caractéristiques. En plus d'une désignation, et d'une cote, le type ty_element
possédera un attribut att_dimensions qui sera du type abstrait précédemment créé,
ty_dimension
CREATE OR REPLACE TYPE TY_ELEMENT AS OBJECT (
att_numero NUMBER(9) ,
att_designation VARCHAR2(20) ,
att_dimensions TY_DIMENSION ,
att_cote VARCHAR2(3)
)
/
Comme pour les images, un type pouvant regrouper une collection d'éléments doit
être créé. (ty_table_element)

au MEN
2.2.2.3 ty_ethnie
La particularité de la classe ethnie réside dans l'utilisation d'un role représentant soit
l'ethnie de production, soit celle de provenance.
Deux attributs supplémentaires ont été crées. Il s'agit de tableaux de pointeurs sur un
type objet. Ces attributs permettent, par l'ethnie (donc par le père), de trouver les
objets qui s'y rapportent.
CREATE OR REPLACE TYPE TY_ETHNIE AS OBJECT (

att_nom VARCHAR2(20) ,
att_eth_provenance TY_TABLE_REFS_OBJ ,
att_eth_production TY_TABLE_REFS_OBJ
)
2.2.2.4 ty_matiere, ty_ordre_matiere

Un objet est composé d'aucune ou plusieurs matières possédant un ordre, soit
première matière, seconde matière, etc… Cette problématique est tout à fait
particulière pour la modélisation objet du MEN.. Le type ty_matiere n'est pas inclus
dans la classe ty_objet car nous avons estimé que la matière a une existence propre,
mais l'appartenance de la matière à l'objet y est incluse.
Il s’agit en fait selon nous d’un cas de lien d’agrégation (et non pas de composition3)
Donc le type ty_ordre_matiere permet d'introduire la notion d'ordre (att_ordre) pour

un objet donné (att_num_objet) et de pointer vers la matière concernée (att_matiere).
Le type ty_table_ordre_matiere permet de les regrouper en collection.
CREATE OR REPLACE TYPE TY_ORDRE_MATIERE AS OBJECT (

att_numero NUMBER(9),
att_objet REF ty_objet,
att_ordre NUMBER(9),
att_matiere REF TY_MATIERE)
/
3
Lien de composition : Type de lien ou l’on privilégie le sens de navigation, se reporter au document :
Eléments de modélisation objet-relationnelle

au MEN
2.2.2.5 ty_collection
Une collection est un regroupement de divers objets. Elle possède une datation et
est fournie par un intervenant. De plus, elle peut être financée par plusieurs
intervenants et passer éventuellement par des intermédiaires..
CREATE OR REPLACE TYPE TY_COLLECTION AS OBJECT (

att_date_creation TY_DATE_APPROX ,
att_objets TY_TABLE_REFS_OBJ ,
att_interv_fournit REF TY_INTERVENANT ,
STATIC FUNCTION initialise RETURN TY_COLLECTION)
/
La collection sera datée par l'intermédiaire de l'attribut att_date_creation qui est de

type ty_date_approx. L'attribut att_objets est un tableau de pointeurs sur des objets,
ce qui permettra à une collection de pointer sur les objets qui la composent. De plus,
un attribut att_interv_fournit de type pointeur sur un intervenant permet de référencer
le fournisseur de la collection.
Afin qu'une collection puisse être référencée (par exemple par un objet ou par un
intervenant) un type pointant sur le type ty_collection a été créé ainsi qu'un tableau
de ce nouveau type.

au MEN
2.2.2.6 ty_intervenant
Un intervenant, personne physique ou morale, peut être celui qui finance une
collection, qui la fournit ou qui fait office d'intermédiaire.
Sur ce cas, nous allons pouvoir utiliser nos simulations d'héritage. Un intervenant
pouvant être distingué un tant que personne physique ou personne morale. Pour ce
faire, nous avons choisi la deuxième simulation d'héritage car tous les liens se
portent sur l'intervenant. (voir document sur l'héritage) De plus, l'adresse d'un
intervenant sera traitée comme une inclusion. Voici comment se présente la structure
actuelle du modèle de classe :
TY_INTERVENANT TY_ADRESSE
att_numero att_rue
att_mnemo 1 0..1 att_casePostale
att_telephone att_npa
att_fax att_localite
att_mailing
méthodes
méthodes …
…
TY_PERSPHYSIQUE
TY_PERSMORALE att_politesse
att_nom
att_institution att_prenom
att_nom att_vivant
méthodes méthodes
… …
Figure 9
Modèle de classe

au MEN
Le modèle se résume ainsi :

CREATE OR REPLACE TYPE ty_PersMorale AS OBJECT (
att_institution VARCHAR2(40),
att_nom VARCHAR2(50),
MEMBER FUNCTION getInstitution RETURN VARCHAR2);
/
CREATE OR REPLACE TYPE ty_PersPhysique AS OBJECT (
att_politesse VARCHAR2(50),
att_nom VARCHAR2(50),
att_prenom VARCHAR2(50),
att_vivant NUMBER(1),
MEMBER FUNCTION getNomComplet RETURN VARCHAR2);
/
Afin que le type ty_intervenant puisse être référencé par une collection, le type
ty_ref_intervenant doit être créé.
CREATE OR REPLACE TYPE TY_REF_INTERVENANT AS OBJECT (
att_ref_intervenant REF TY_INTERVENANT)
Un type ty_ref_intermediaire ainsi qu'un type ty_ref_financier ont été créés. Il s'agit
de types possédant, outre un numéro, deux attributs référençant la collection et
l'intervenant.
Nous pouvons alors créer le "super-type" ty_intervenant qui inclus le type abstrait
ty_adresse
CREATE OR REPLACE TYPE ty_Intervenant AS OBJECT (
att_mnemo VARCHAR2(8) ,
att_adresse TY_ADRESSE ,
att_telephone VARCHAR2(40),
att_fax VARCHAR2(40),
att_mailing NUMBER(1) ,
att_coll_fournit TY_TABLE_REFS_COLLECTION,
att_personne_physique TY_PERSPHYSIQUE,
att_personne_morale TY_PERSMORALE,
MEMBER FUNCTION getMnemo RETURN VARCHAR2,
MEMBER FUNCTION getAdresse RETURN VARCHAR2,
MEMBER FUNCTION getNomComplet RETURN VARCHAR2,
MEMBER FUNCTION getInstitution RETURN VARCHAR2);
/

au MEN
2.2.2.7 ty_objet.
L’objet (la pièce) est l’essence même du musée d’ethnographie. Il est considéré
comme une unité d’inventaire et est muni d’une identification unique. Les objets
saisis dans la base de données du MEN se trouvent stockés dans des dépôts ou
promis par des tierces personnes. Ils peuvent se décomposer en éléments
constitutifs.
Le type ty_objet est le plus compliqué et également le plus intéressant. En plus de

ses attributs et méthodes, nous intégrons la gestion des données textuelles dans
l'attribut att_texte
CREATE OR REPLACE TYPE TY_OBJET AS OBJECT (

att_chronologique VARCHAR2(20) ,
att_topographique VARCHAR2(20) ,
att_egyp VARCHAR2(20) ,
att_designation VARCHAR2(60) ,
att_vernaculaire VARCHAR2(60) ,
att_texte Clob ,
att_date_acquisition TY_DATE_APPROX ,
att_dimensions TY_DIMENSION ,
att_date_localisation_musee DATE ,
att_images TY_TABLE_IMAGES ,
att_elements TY_TABLE_ELEMENTS ,
att_matiere TY_TABLE_ORDRE_MATIERE ,
att_ethnie_provenance REF ty_ethnie ,
att_ethnie_producteur REF ty_ethnie ,
att_ref_collection REF ty_collection ,
att_ref_mode_entree REF ty_mode_entree ,
att_ref_signature REF ty_signature ,
att_ref_categorie REF ty_categorie ,
att_ref_geographie REF ty_geographie ,
MEMBER FUNCTION cote RETURN VARCHAR ,
MAP MEMBER FUNCTION cotetri RETURN VARCHAR
MEMBER FUNCTION getxml(type_meta NUMBER) RETURN CLOB,
STATIC FUNCTION getDTD RETURN CLOB,
STATIC FUNCTION setXML(xmlDoc clob) RETURN NUMBER)
/

au MEN
2.3 Création des vues

Une fois les types créés, l'élaboration des vues "objet" est possible. Comme nous
l'avons vu, l'ordre de création des vues est essentiel à cause du référencement de
celle-ci.
Les références été souvent croisées, il est nécessaire de créer des vues partielles et
de les écraser avec la vue définitives, comme pour les types. La première vue doit
donc être créée avec des références Null . La seconde peut alors être créée avec
une référence sur la première. La troisième étape consiste à remplacer la première
vue, en comportant cette fois la référence sur la seconde. Cette démarche est assez
simple, mais dans certains cas elle nécessite une certaine concentration !!
2.3.1 Choix de l’identifiant
Divers problèmes ont dû être résolus en cours de réalisation des vues "objets".
Lors de cette création, le paramètre à donner dans la clause
WITH OBJECT IDENTIFIER (XXX)
doit être identifiant, donc unique. Il s'agit d'un attribut du type qui identifiera tous les
enregistrements de la vue. Toutefois, l'attribut att_mnemo du type ty_intervenant ne
peut être utilisé bien qu'il soit unique et identifiant. Dès lors et dans tous les cas, il est
nécessaire de baser ce paramètre sur l'attribut att_numero repris dans tous les
types. C'est pourquoi, les types créés auparavant contiennent cet attribut. Si l'option
de travailler directement avec des tables "objets" était retenue, cet attribut pourrait
être supprimé de tous les types puisque dans un modèle RO, c’est l’OID qui joue le
rôle de clé primaire.
Les autres soucis n'ont été que syntaxiques. Le plus difficile à résoudre a été, lors de
la création de la vue vo_objet, de renseigner l'attribut att_matiere qui contient une
collection de numéro d'ordre et de pointeur. Ci-après, la partie concernée du script:
CAST(MULTISET(
SELECT att_numero, att_num_objet, att_ordre, att_matiere
FROM vo_ordre_matiere vo_om
WHERE vo_om.att_num_objet = o.numero) AS
TY_TABLE_ORDRE_MATIERE),

au MEN
2.4 Implémentation des triggers instead of
Les triggers instead of vont maintenant être implémentés dans l'ordre croissant de
leur difficulté..
2.4.1 vo_matiere
TY_MATIERE TY_ORDRE_MATIERE
att_numero att_numero
att_nom att_ordre
méthodes méthodes
… …
Figure 1
Modèle de classe
La vue basé sur le type ty_matiere est triviale et les triggers sur celle-ci le sont aussi.
Outre la vérification de la clé primaire lors de l'insertion, ces triggers utilisent les
données des objets pour alimenter la table matiere.

au MEN
2.4.2 vue vo_image
TY_IMAGE
TY_OBJET
att_numero
attributs 1 0..*
att_vue
… att_img_high_def
att_img_low_def
att_signature
méthodes
… méthodes
…
Figure 2
Modèle de classe
Ici, nous avons le cas d'une inclusion, c'est-à-dire que les images sont incluses dans
un objet et qu'elles ne possèdent pas d'information sur celui-ci. Donc, leur insertion
devra être prise en compte dans le trigger sur la vue vo_objet.
Il va donc falloir exclure l'insertion sur la vue vo_image en levant une exception.
CREATE OR REPLACE TRIGGER tr_Image_Insert
INSTEAD OF INSERT ON vo_Image
FOR EACH ROW
BEGIN
Raise_application_error(-20001, 'Insertion interdite sur
cette vue');
END;
Les données étant principalement les images elle-même, il nous parais judicieux de
ne pas traiter leur mise à jour, car trop complexe. Le modèle relationnel-objet est
particulièrement adapté à la mise en place de méthode manipulant les images, et
cela n'est pas le travail du trigger. Cette mise à jour des images est reprise dans le
chapitre traitant des méthodes de mise à jour.

au MEN
2.4.3 vo_element
TY_DIMENSION
TY_ELEMENT
TY_OBJET
att_longueur
att_numero att_largeur
attributs 1 0..* 1 0..1
att_designation att_profondeur
…
att_cote att_diametre
att_circonference
méthodes
méthodes att_poids
…
…
méthodes
Figure 3 …
Modèle de classe
Les éléments étant inclus dans un objet sont une structure simple, donc l'insertion
sera mise en place sur la vue vo_objet.
Mais le type ty_element possède aussi une inclusion, qu'il faudra gérer lors de la
modification. Nous allons donc devoir vérifier si les dimensions incluses existent pour
éviter d'y accéder si celles-ci sont NULL.
. . .
-- Vérification de l'existence de dimensions
-- pour éviter l'accès à une dimension NULL
IF (:New.att_dimensions IS NOT NULL) THEN
dimension := ty_dimension( :New.att_dimensions.att_longueur,
:New.att_dimensions.att_largeur,
:New.att_dimensions.att_profondeur, /*Gestion
:New.att_dimensions.att_diametre, de
:New.att_dimensions.att_circonference, l'inclusion et
:New.att_dimensions.att_poids); stockage
ELSE dans une
dimension := ty_dimension(NULL,NULL,NULL,NULL variable*/
,NULL,NULL);
END IF;
…
-- Modification
UPDATE MEN.Element SET
designation = :New.att_designation, /* Modification
cote = :New.att_cote, de la base
longueur = dimension.att_longueur, grâce aux
largeur = dimension.att_largeur, données
profondeur = dimension.att_profondeur, collectées*/
diametre = dimension.att_diametre,
circonference = dimension.att_circonference,
poids = dimension.att_poids
WHERE numero = :Old.att_numero;

au MEN
2.4.4 vo_intervenant_financier
TY_OBJET TY_COLLECTION
TY_REF_FINANCIER
attributs 0..1 0..*
attributs
att_numero 0..* 0..1
… …
méthodes
méthodes méthodes
…
… …
Figure 4
Modèle de classe
Notre vue vo_intervenant_financier étant basé sur le type ty_ref_financier, nous

devrons nous occuper de référence d'objet. En effet celui-ci référence les types
ty_objet et ty_intervenant.
La vérification est simple : Si une de ces références existe, il va falloir retrouver le

numéro d'enregistrement par déréférencement. Sinon nous affecterons NULL au
numéro.
. . .
-- Vérification du lien sur les intervenants /* Recherche
IF (:New.att_intervenant IS NOT NULL) THEN du numéro de
SELECT DEREF (:New.att_intervenant) l'intervenant si
INTO intervenant_obj sa référence a
FROM DUAL; été introduite
numeroIntervenant := intervenant_obj.att_numero;
*/
ELSE
numeroIntervenant := NULL;
END IF;
…

au MEN
-- Vérification du lien sur les collections

IF (:New.att_collection IS NOT NULL) THEN
SELECT DEREF (:New.att_collection)
INTO collection_obj
FROM DUAL; /* Recherche
du numéro de
numeroCollection := collection_obj.att_numero;
ELSE la collection si
numeroCollection := NULL; sa référence
END IF; a été
introduite */
-- Insertion
INSERT INTO MEN.Financier (
numero,
colle_numero,
inter_numero)
VALUES ( /* Insertion
numeroVar, des données
numeroCollection, collectées */
numeroIntervenant);
. . .
Le reste de l'implémentation est simple.
2.4.5 vo_intervenant_intermediaire
TY_OBJET TY_DIMENSION
TY_REF_INTERMEDIAIRE
attributs attibuts
0..1 0..* att_numero 0..* 0..1
… …
méthodes
méthodes méthodes
…
… …
Figure 5
Modèle de classe
La vue vo_intervenant_intermediaire est basée sur le type ty_ref_intermediaire.

Ici, l'implémentation des triggers est strictement identique à ceux de la vue
précédente, à savoir vo_intervenant_financier.

au MEN
2.4.6 vo_collection
TY_INTERVENANT
attributs
…
méthodes
…
0..1
TY_DATE_APPRO
0..* X
TY_OBJET
TY_COLLECTION att_jour_debut
attributs att_mois_debut
0..* 0..1 att_numero 1 0..1 att_annee_debut
…
att_jour_fin
méthodes att_mois_fin
méthodes att_annee_fin
…
…
méthodes
…
Figure 6
Modèle de classe
La vue vo_collection est basée sur le type ty_collection qui comprend : une inclusion
de type ty_date_approx, une référence à un intervenant et une collection d'objets.
L'étude des inclusions et des références ayant déjà été traitée précédemment, nous
allons nous concentrer sur le traitement de la collection.
Lors de l'insertion, nous devons tester si une collection a été introduite. Si c'est le
cas, nous devons la parcourir et modifier les objets en leur ajoutant le numéro de
collection
-- Gestion de la collection d'objets
IF (:New.att_objets IS NOT NULL) THEN
FOR i IN :New.att_objets.FIRST..:New.att_objets.LAST LOOP
SELECT DEREF (:New.att_objets(i).att_ref_objet)
INTO objet_obj
FROM DUAL;
UPDATE Men.Objet SET
collection_numero = numeroCollection
WHERE numero = objet_obj.att_numero;
END LOOP;
END IF;

au MEN
Lors de la modification, nous avons décidé de nous occuper que de deux cas de
figure. Soit une collection est ajoutée, soit elle est supprimée. Nous ne pouvons nous
occuper du cas où la collection est modifié car nous n'avons aucun moyen de
comparaison. Pour plus de détail, veuillez consulter le document traitant des
manipulations de données.
-- Gestion de la collection d'objets
IF ((:New.att_objets.COUNT <> 0)
AND (:Old.att_objets.COUNT = 0)) THEN /* Une collection
FOR i IN :New.att_objets.FIRST.. d'objets à été
:New.att_objets.LAST LOOP ajoutée è
SELECT DEREF (:New.att_objets(i) Modification des
.att_ref_objet) objets en leur
INTO objet_obj ajoutant le
FROM DUAL; numéro de
UPDATE Men.Objet SET collection*/
collection_numero = :Old.att_numero
END LOOP;
ELSIF ((:New.att_objets.COUNT = 0)
AND (:Old.att_objets.COUNT <> 0)) THEN
FOR i IN :Old.att_objets.FIRST.. /* Une collection
:Old.att_objets.LAST LOOP d'objets à été
SELECT DEREF (:Old.att_objets(i). supprimée è
att_ref_objet) Modification des
INTO objet_obj objets en leur
FROM DUAL; supprimant le
UPDATE Men.Objet SET numéro de
collection_numero = NULL collection*/
END LOOP;
END IF;
En ce qui concerne l'utilisation des collections, vous remarquerez que le code pour la
modification ne teste pas si la collection est NULL. Ceci vient du fait que nous
interdisons la modification de collection en spécifiant simplement NULL. Cette
décision est intervenue lors d'essai, car il semblerait qu'Oracle stocke des collections
vides plutôt que des collections NULL. Voici donc comment supprimer une collection
d'objets :
UPDATE vo_collection SET
att_objets = ty_table_refs_objet()
WHERE att_numero = 1;
La suppression suivante provoquera une erreur.

UPDATE vo_collection SET
att_objets = NULL
WHERE att_numero 1;

au MEN
2.4.7 vo_ethnie
TY_OBJET TY_ETHNIE
0..* 0..1
attributs Producteur att_numero
… att_nom
0..* 0..1
méthodes méthodes
… Provenance …
Figure 7
Modèle de classe
La vue vo_ethnie, basé sur le type ty_ethnie, comporte deux collections d'objets.
Leur implémentation est identique et suit la logique vue précédemment.
2.4.8 vo_ordre_matiere
TY_OBJET TY_ORDRE_MATIERE TY_MATIERE
attributs att_numero attibuts

1 0..* 0..* 0..1
… att_ordre …
méthodes méthodes méthodes

… … …
Figure 8
Modèle de classe
La difficulté pour les triggers réside dans la vérification des deux références.

au MEN
2.4.9 vo_intervenant
La difficulté ici est due à la simulation d'héritage.
Lors de l'implémentation des triggers, il va falloir faire quelques tests pour distinguer
s'il s'agit d'une personne physique ou morale. De plus, il faudra pouvoir interdire
qu'un intervenant soit à la fois l'un et l'autre.
. . .
-- Distinction pour l'héritage
IF ((:New.att_personne_morale IS NOT NULL)
AND(:New.att_personne_physique IS NULL)) THEN
personneMorale := ty_persMorale(
:New.att_personne_morale.att_institution, NULL);
nom := :New.att_personne_morale.att_nom;
ELSIF ((:New.att_personne_physique IS NOT NULL)

AND(:New.att_personne_morale IS NULL)) THEN
personnePhysique := ty_persPhysique (
:New.att_personne_physique.att_politesse,
NULL,
:New.att_personne_physique.att_prenom,
:New.att_personne_physique.att_vivant);
nom := :New.att_personne_physique.att_nom;
ELSIF ((:New.att_personne_physique IS NOT NULL)

AND(:New.att_personne_morale IS NOT NULL)) THEN
Raise_application_error(-20002, 'Un intervenant ne peut
pas être une personne morale ET physique');
END IF;
. . .
Toutes les informations sont stockées dans trois variables : personnePhysique,

personneMorale et nom. Celles-ci seront utilisée lors de l'insertion ou de la
modification.
Pour le reste, l'implémentation devra s'occuper de l'inclusion de l'adresse ainsi que

d'une collection.

au MEN
2.4.10 vue vo_objet
En ce qui concerne l'implémentation de triggers sur la vue vo_objet, nous serons

confronté à deux inclusions, sept références, une collection et deux collections
d'inclusion. Tout a déjà été traité, à part les collections d'inclusion.
Il s'agit de nos types ty_image et ty_element. Comme ils n'ont pas de référence sur
l'objet, l'insertion n'est pas possible sur leur vue respective. Il va donc falloir s'en
occuper ici. Lors de l'insertion d'un objet, il faudra vérifier si une collection d'image
et/ou une collection d'éléments ont été introduites. Si c'est la cas, les images ou les
éléments devront être insérés dans la base, car il n'existe pas encore. (de par leur
cardinalité 1,1)
Voici le code qui permet l'insertion des images pendant l'insertion d'un objet :
-- Gestion de la collection d'images ==> insertion

IF (:New.att_images IS NOT NULL) THEN
FOR i IN :New.att_images.FIRST..:New.att_images.LAST LOOP
image_obj := :New.att_images(i);
SELECT Men.Seq_Image.NextVal
/* Numéro par
INTO numeroImage séquencement
FROM DUAL; */
INSERT INTO Men.Image (
numero,
vue, /* Parcours de
position_serveur, la collection */
fichier_jpeg, /* Insertion des
objet_numero) images dans la
base de
VALUES (numeroImage, données */
image_obj.att_vue,
image_obj.att_position_serveur,
image_obj.att_fichier_jpeg,
numeroObjet);
END LOOP;
END IF;

au MEN
En ce qui concerne les éléments, il faudra aussi prendre en compte que le type
ty_element possède aussi un inclusion.
-- Gestion de la collection d'elements ==> insertion

IF (:New.att_elements IS NOT NULL) THEN
FOR i IN :New.att_elements.FIRST..:New.att_elements.LAST
LOOP
element_obj := :New.att_elements(i);
SELECT Men.Seq_Element.NextVal /* Numéro par
INTO numeroElement séquencement*/
FROM DUAL;
-- Vérification de l'existence de dimensions
-- pour éviter l'accès à une dimension NULL
IF (element_obj.att_dimensions IS NOT NULL) THEN
dimensions := ty_dimension(
element_obj.att_dimensions.att_longueur,
element_obj.att_dimensions.att_largeur,
element_obj.att_dimensions.att_profondeur, /*Gestion de
element_obj.att_dimensions.att_diametre, l'inclusion et
element_obj.att_dimensions.att_circonference, stockage
dans une
element_obj.att_dimensions.att_poids); variable*/
ELSE
dimensions := ty_dimension(NULL, NULL, NULL,
NULL, NULL, NULL);
END IF;
-- Insertion /*Parcours de
INSERT INTO Men.Element (numero, la collection*/
cote,
designation,
longueur,
largeur,
profondeur,
diametre,
circonference,
poids,
objet_numero) /*Insertion de
l'élément de la
VALUES (numeroElement,
base de données*/
element_obj.att_cote,
element_obj.att_designation,
dimensions.att_longueur,
dimensions.att_largeur,
dimensions.att_profondeur,
dimensions.att_diametre,
dimensions.att_circonference,
dimensions.att_poids,
numeroObjet);
END LOOP;
END IF;

au MEN
En ce qui concerne la modification, nous allons gérer ces collections d'inclusion

comme s'il s'agissait de collections "normales" pour la distinction de cas. Si une
collection est ajoutée, nous allons insérer ces nouvelles données au lieu de les
modifier. Si une collection est supprimée, nous allons supprimer ces données dans la
table adéquate. Et enfin, si une collection est modifié, nous ne pouvons rien faire vu
que nous n'avons aucun moyen de comparaison.
Voici le code nous permettant de gérer la collection d'images lors de la modification
-- Gestion de la collection d'images

IF ((:New.att_images.COUNT <> 0)AND(:Old.att_images.COUNT
= 0)) THEN
--> insertion d'images
FOR i IN :New.att_images.FIRST..:New.att_images.LAST LOOP
image_obj := :New.att_images(i);
SELECT Men.Seq_Image.NextVal
INTO numeroImage
FROM DUAL; /* Une nouvelle
INSERT INTO Men.Image (…) collection a été
VALUES (numeroImage, ajoutée
image_obj.att_vue, è Insertion
….); dans la table
END LOOP; relationnelle */
ELSIF ((:New.att_images.COUNT = 0)
AND(:Old.att_images.COUNT <> 0)) THEN
--> suppression d'images
FOR i IN :Old.att_images.FIRST..:Old.att_images.LAST LOOP
image_obj := :Old.att_images(i);
DELETE Men.Image /* Une collection
WHERE numero = image_obj.att_numero; a été supprimée
END LOOP; è Suppression
END IF; dans la table
relationnelle */
Et enfin, en ce qui concerne la suppression, si une collection incluse d'images est

rattachée à notre objet, il faudra supprimer ces images car elles n'ont plus lieu d'être
(cardinalité 1,1)
-- Gestion de la collection incluse d'images

IF (:Old.att_images.COUNT <> 0) THEN
--> suppression d'images
FOR i IN :Old.att_images.FIRST..:Old.att_images.LAST LOOP
DELETE Men.Image
WHERE numero = :Old.att_images(i).att_numero;
END LOOP;
END IF;

au MEN
2.5 Méthodes
2.5.1 Méthodes de comportement

Les vues étant créées, la résolution de la problématique des comportements, soit la
cotation, les dimensions et la datation peut être traitée
2.5.1.1 Méthodes de ty_objet
2.5.1.1.1 Système de cotation des objets
Les objets saisis dans la base de données possèdent un système de cotation propre
au MEN. La cote est un identificateur unique pour l’objet. Trois types de cotes
existent : Chronologique, topographique et égyptienne. Un objet peut posséder un ou
plusieurs types de cote.
Cote chronologique
Appelée cote française, elle est utilisée pour la codification des objets non-égyptiens.
En vigueur au MEN de 1921 à 1947, elle est utilisée pour la codification des
nouveaux objets à venir.
Cote topographique
Appelée cote germanique, elle a été utilisée pour la reprise de la codification des
objets non-égyptiens et ce de 1921 à 1947.
Cote égyptienne
Utilisée depuis 1926 pour la reprise de la codification des objets d’Egypte ancienne.
Comme déjà mentionné, un objet peut posséder plusieurs cotes. Il est indispensable
de conserver toutes les cotes car certains ouvrages y font référence. Cependant,
comme il a été décidé qu’une seule cote serait affichée dans les listes d'objet, il est
nécessaire d'en connaître la plus récente ou du moins celle qui identifie l'objet.
2.5.1.1.2 Méthode cote()
Dans la base relationnelle, un champ cote est renseigné automatiquement lors de la

saisie de l’objet par la procédure selon l'ordre de priorité suivant:.
- Chronologique
- Topographique
- Egyptienne
Exemple :
Chronologique Topographique Egyptienne Champ cote

52
II.B.998 II.B.998
91.11.9 II.B.998 91.11.9
Eg.56 Eg.56

au MEN
Avec la technologie "objet-relationnelle" la fonction suivante a été créée:
MEMBER FUNCTION cote RETURN VARCHAR,
Cette dernière reprend bien évidemment le code de l'ancienne procédure, mais le

champ cote n'existe plus. Cette redondance a été supprimée mais la valeur peut être
retrouvé tout aussi simplement qu'auparavant et ce en appelant la fonction:
SELECT vo_o.cote()
FROM vo_objet vo_o;
2.5.1.1.3 Méthode cotetri()
att_cotetri est un champ calculé qui a comme seule utilité de permettre de trier
correctement les objets selon leur cotation. Un simple tri avec la méthode cote() ne
suffirait pas dans le cas de ce système de cotation d’objets. Le champ att_cotetri est
renseigné automatiquement lors de la saisie ou la modification de l’objet par une
procédure. Nous ne reviendrons pas sur l'algorithme qui renseigne le champ
att_cotetri.
Comme nous utilisons des vues "objets" sur des tables relationnelles, nous ne
devons pas nous occuper du problème de l'attribut att_cotetri. Ce dernier sera
toujours renseigné par la procédure existante, appelé par un déclencheur.
MAP MEMBER FUNCTION cotetri RETURN VARCHAR
La méthode cotetri() a pour but de retourner l'attribut att_cotetri. De plus, comme il

s'agit d'une fonction MAP toutes comparaisons entre deux objets se basera sur
cette méthode. Il serait dès lors tout à fait possible de comparer dans un bloc
PL/SQL des objets de la façon suivante:
.....IF objet_1 > objet_2 THEN......
Sans appeler expressément la méthode cotetri(), c'est sur cette dernière que ce
basera cette comparaison.
Il est important ici que les méthode cote() et cotetri() seront très souvent utilisées
dans des clause WHERE et/ou comme critère de tri. Leur utilisation risque donc
d’être critique pour les performance, puisque l’accès serait séquentiel. La version
actuelle du SGBD supporte l’indexation d’une fonction, donc d’une méthode membre.
La condition d’indexation pour la fonction peut-être résumée par la propriété d’être
déterministe4.
4
Fonction déterministe : Propriété d’une fonction consistant a renvoyer toujours la même valeur de
retour pour valeur d’entrée fixée. Exemple Random n’est pas détermisniste.

au MEN
2.5.1.2 Méthodes de ty_dimensions

Les éléments et les objets du MEN possèdent ou non des dimensions. Il s'agit entre
autres, d'une longueur, d'une largeur, d'une profondeur et d'un diamètre. Nous allons
mettre en place des règles qui détermine la forme de l'objet en fonction des
rendeignements que nous avons dans les différents attributs.
2.5.1.2.1 Règles de définition des formes

Divers postulats ont du être définis avant d'implémenter des méthodes de calcul de
volumes.
Tout d'abord, l'attribut att_circonférence est un attribut indicatif. Il n'est ni calculé, ni
utilisé pour le volume.
Remarquons qu’il serait nécessaire de faire un contrôle de cohérence lors de la

saisie d'une dimension ainsi qu'un contrôle des données existantes pour que les
méthodes qui seront implémentées ne génèrent pas d'erreurs. Nous partons du
postulat que les données existantes répondent aux critères décrit ci-après:
2.5.1.2.1.1 Forme cubique

Pour être de forme cubique, les attributs att_longueur, att_largeur et att_profondeur
doivent être renseignés et aucun diamètre ne doit exister.
2.5.1.2.1.2 Forme cylindrique

Si l'attribut diamètre est renseigné ainsi que l'attribut profondeur, il s'agit d'un
cylindre.
2.5.1.2.1.3 Forme sphérique

Si l'attribut att_diamètre est renseigné et que les attributs att_largeur, att_longueur, et
att_profondeur ne le sont pas, il s'agit d'une sphère.
P prof
r
o
f
longu diam diam
larg

au MEN
2.5.1.2.2 Méthode forme()
MEMBER FUNCTION forme RETURN VARCHAR
Nous admettons volontiers que la méthode de la détection de la forme d’un objet est
simpliste et qu’elle ne correspond pas à la réalité. Elle à une valeur d’outil de test
pour les fonctionnalités du système.
En plus de retourner le type de forme à laquelle appartient l'objet, cette méthode est
surtout utilisée dans la méthode qui suit. Il est bien entendu possible de l'utiliser dans
une requête pour demander, par exemple, la liste des objets cylindriques.
SELECT o.att_numero,
FROM vo_objet o
WHERE o.att_dimensions.forme() ='cylindrique';
2.5.1.2.3 Méthode volume()
MAP MEMBER FUNCTION volume RETURN REAL
Voici la méthode la plus intéressante de ce type. Se basant sur la précédente

(forme()), elle est à même de calculer le volume d'un objet. De surcroît, étant de type
MAP, toute comparaison entre deux objets se base sur cette méthode. Il devient dès
lors trivial de comparer un casque avec un lance ou de classer les objets par volume.
En trois lignes, il est envisageable de lister tous les objets dont le volume est
inférieur à une valeur donnée.
SELECT o.att_numero,
FROM vo_objet o
WHERE o.att_dimensions.volume()<500;

au MEN
2.5.1.3 Méthodes de ty_date_approximative

Les dates du MEN sont de type approximatif. Pour ne pas nous répéter et en
quelques mots, cela signifie que des dates selon les exemples suivant sont
possibles:
Mai 1968
19 août 1945
Avant 1515
Après 1800
Entre 1500 et 1800
Il est alors fort simple de comprendre qu'avec une technologie relationnelle la

comparaison entre deux dates approximatives ne peut être réalisée par la base de
données lors d’une "simple" requête SQL.
Grâce à l'application des concepts "objet-relationnels", les méthodes suivantes ont

été implémentées:
2.5.1.3.1 Méthode TypeDate
MEMBER FUNCTION TypeDate RETURN NUMBER ,
Elle nous permet de déterminer le type de date à laquelle nous avons à faire. Il est
donc fort simple de demander la liste des collections étant datées de manière exacte.
SELECT c.att_numero
FROM vo_collection c
WHERE c.att_date_creation.TypeDate()=0
2.5.1.3.2 Méthode DateOrder
MEMBER FUNCTION DateOrder RETURN DATE
Elle nous permet d'ordonner des dates approximatives car en fait cette fonction les
transforme en date. En trois lignes, il est possible d'avoir la liste triée des collections.
SELECT c.att_numero,
ORDER BY c.att_date_creation.DateOrder();

au MEN
2.5.1.3.3 Méthode Compare
ORDER MEMBER FUNCTION Compare(par_date

ty_date_approx) RETURN INTEGER
Elle nous permet de comparer, si la comparaison est possible, deux dates de type
approximatif. De plus, comme il s'agit d'une fonction ORDER , toute comparaison
entre deux dates se basera sur cette méthode. Il serait dès lors tout à fait possible de
comparer dans un bloc PL/SQL des dates de la façon suivante:
.....IF date_1 > date_2 THEN......
Avouons ici que la mise en place de cette méthode est principalement justifiée par
notre désire d’évaluer les fonctionnalités MAP.
2.5.1.3.4 Méthode EstDansIntervalle
MEMBER FUNCTION EstDansIntervalleNumber(date1 date,

date2 date DEFAULT SYSDATE,
Optimiste VARCHAR
DEFAULT 'true') RETURN NUMBER
En donnant deux bornes sous forme de date, cette méthode nous permet de savoir
si une date est bien dans un intervalle donné et ce de deux façon possibles. En effet,
le deuxième paramètre nous permet d'obtenir un résultat optimiste ou pessimiste.
L'optimisme veut qu'une date approximative "mai à août 1960" se trouve dans
l'intervalle du 1er au 31 août 1960.
Grâce à cette méthode, la requête demandant la liste des collections dans un

intervalle donné devient d'une facilité enfantine.
WHERE 1 = c.att_date_creation.EstDansIntervalleNumber(
To_Date('01/01/1850','DD/MM/YYYY'),
To_Date('01/01/1900','DD/MM/YYYY'),'false')

au MEN
2.5.1.4 Remarques
Comme vous l'aurez certainement remarqué, une comparaison avec le chiffre 1 est
effectué dans la clause WHERE de la requête ci-dessus. Initialement, la méthode
EstDansIntervalle retournait une valeur booléenne et ce chiffre 1 n'était pas
nécessaire. Tout ceci était sans compter que SQL ne supporte pas le type booléen à
l'inverse de PL/SQL.
Pour remédier à ce petit problème, la méthode EstDansIntervalle renommée

EstDansIntervalleNumber fait appelle à un fonction générale et non à une fonction
du type, appelée DateDansIntervalle. Cette dernière retourne un booléen que
EstDansIntervalleNumber transforme en 0 ou 1. Cette façon de procéder est apparu
la meilleure car la première méthode EstDansIntervalle a également été conservé
afin de pouvoir l'utiliser dans un bloc PL/SQL en utilisant la force des type booléens.
.....IF
EstDansIntervalle(To_Date('01/01/1850','DD/MM/YYYY'),
'false' THEN......
2.5.1.5 Exemple d'utilisation de méthodes

Par cet exemple de requête, demandant la liste, classée par date, des collections
(numéro et date d'ordre) se trouvant dans un intervalle donné et possédant une
datation de type ordonnable, toute la force et l'utilité des méthodes paraissent
évidentes.
To_Char(c.att_date_creation.DateOrder(),'DD/MM/YYYY')
WHERE 1 = c.att_date_creation.EstDansIntervalleNumber(
To_Date('01/01/1900','DD/MM/YYYY'),'false')
AND c.att_date_creation.typeDate() = 1
ORDER BY c.att_date_creation.DateOrder()

au MEN
2.5.2 méthodes de mise à jour
La mise en place des triggers instead of nous a permis de rendre les vues RO d’une
"updatable" mais certaines manipulations complexes sont avantageusement
réalisées avec des méthodes de mise à jour.
Pour évaluer la mise en place de méthode de mise à jour, la vue vo_collection a été
choisie car elle possède une inclusion, une référence et une collection d'objets, ce
qui couvre différents cas d'utilisation. Voici donc les méthodes implantées :
Pour le type ty_collection

Initialise méthode statique constructeur
Pour le type ty_ref_collection

Nouveau méthode statique Insertion d'un nouvel enregistrement
Chercher méthode statique recherche d'un enregistrement
Modifier méthode membre modification d'un enregistrement
Detruire méthode membre suppression d'un enregistrement
SetDateCreation méthode membre accesseurs pour la date de créations
SetIntervenant méthode membre accesseurs pour l'intervenant
SetCollectionObjets méthode membre accesseurs pour la collection d'objets
AjouteObjets méthode membre ajouts d'objets à la collection
EnleveObjets méthode membre suppression d'objets à la collection
Pour de plus amples informations sur ces méthodes, veuillez consulter le chapitre
concernant les manipulations de données.
Nous allons tout de même commenter les deux dernières méthodes. Celles-ci se
proposent de combler un manque lors de l'implémentation par triggers. En effet, dès
que nous gérons des collections d'objets nous n'avons pas la possibilité de comparer
ces dernières entre elles. De ce fait nous ne pouvons pas ajouter à une collection
des objets supplémentaires ou en enlever. Ces deux méthodes nous permettent
donc de faire cela très simplement.
En ce qui concerne ajouteObjets, il suffit de passer en paramètre une collection

d'objets pour que ceux-ci soient ajoutés à la collection existante. La méthode
enleveObjets, quant à elle reçoit une collection en paramètre, dont les objets seront
supprimer de celle existante.

au MEN
Voici un exemple d'utilisation de la méthode ajouteObjets.
BEGIN
SELECT REF(vo_o)
INTO obj1
FROM vo_objet vo_o
WHERE att_numero = 10; /* Recherche des objets */
SELECT REF(vo_o)
INTO obj2
FROM vo_objet vo_o
WHERE att_numero = 20;
/* Création de la
collection_objets := ty_table_refs_obj(
collection qui sera
ty_ref_objet(obj1),
ajoutée */
ty_ref_objet(obj2));
/* Recherche */
collection_ref := ty_ref_collection.chercher(2456);
/* Ajout de la collection */
collection_ref.AjouteObjets(collection_objets);
END;
/
Dans notre cas, ces objets seront ajoutés même s'ils étaient déjà liés à une autre
collection, donc c'est à l'utilisateur de savoir ce qu'il est entrain de faire.
L'utilisation de la méthode EnleveObjets est identique. Mais lors de l'implémentation,

il faudra s'assurer que les objets sont bien liés à notre collection avant d'affecter
NULL à leur clé étrangère.

au MEN
BEGIN
-- Désaffectation des objets de la collection
FOR i IN collection_objets.FIRST..collection_objets.LAST
LOOP
SELECT DEREF (collection_objets(i).att_ref_objet)
INTO objet_obj
FROM DUAL;
SELECT collection_numero /* Recherche

INTO numeroCollection du numéro
de collection
FROM MEN.Objet de l'objet */
SELECT DEREF(SELF.att_ref_collection) /* Recherche

INTO collection_obj du numéro de
FROM DUAL; la collection */
numeroSelf := collection_obj.att_numero;
-- Est-ce que l'objet est bien relié à la collection ?

IF (numeroCollection = numeroSelf) THEN
UPDATE MEN.Objet SET
collection_numero = NULL /*L'objet doit être lié
WHERE numero = objet_obj.att_numero; à la collection pour
ELSE que l'on puisse le
Raise_application_error (-20002, désaffecter*/
'Cet objet ne fait pas partie de cette collection');
END IF;
END LOOP;
END EnleveObjets;
/* Parcours de la
collection d'objets */
2.5.3 Mise à jour des images

Notons encore qu'il serait intéressant de développer des méthodes pour la mise à
jour des images. En effet, avec le nouveau schéma, chaque image est stockée dans
la base de données en deux exemplaire, haute et basse définition. De plus il est
nécessaire de générer la signature pour permettre la comparaison des images.
L'utilisation de méthode est pour cela idéal, mais nous ne l'avons pas réalisé. Il nous
semble qu'il s'agit d'un développement en lui même, qui dépend des choix
d'implémentation de l'application.
2.5.4 Méthodes d'intefaçage avec XML

Pour chaque classe disposant d’une vue RO, donc non abstraites, nous avons
ajouter les méthodes d’interfacage XML5, soit getDTD(),getXML() et setXML(),
5
Pour plus d’informations, consulter le document : Echange de données relationneles-objets avec
XML

au MEN
3 Remarques diverses
Plusieurs constatations ont émergées lors de l'implémentation ou la création des

modèles. Elles sont relatées ici pour éviter de retomber dans certains pièges.
3.1 Création de modèles-objet
Lors de la création d'un modèle-objet composé de vues, il faut garder en tête que
nous devrons pouvoir manipuler ces vues et donc celles-ci doivent impérativement
comprendre tous les attributs obligatoires. De plus si l'on désire implémenter des
méthodes de manipulation de données, le corps de ces méthodes devra être créé
après la création des vues, car certaines d'entre elles nécessitent la recherche d'OID.
3.2 Création de vues-objet avec collection
Les vues avec collection doivent impérativement être créées avant les vues les
référençant avec la commande MAKE_REF. Sans quoi, Oracle ne pourra créer ces
dernières parce qu'une référence circulaire sera trouvée. Si toutefois, la création
hâtive ne peut pas être faite, il faudra passer par une vue partielle en omettant
provisoirement le MAKE_REF.
De plus, lors de la création de la collection, il est fortement conseillé d'effectuer les

jointures en utilisant les tables relationnel et pas en déréférençant des objets. Bien
que cette dernière méthode fonctionne, de gros problèmes d'allocation mémoire
apparaîtront dès que vous utiliserez ces vues. Par exemple, un simple SELECT sur
une vue avec collections nécessitait 5'000'000 octets d'espace mémoire pour pouvoir
s'exécuter.

au MEN
Pour illustrer ce cas, voici deux exemples pour la création de la vue vo_signature.
Dans le premier cas, la collection d'objets est créée grâce au déréférencement de
att_ref_signature qui nous permet d'accéder au numéro de signature. Dans le
deuxième cas, nous passons par des tables relationnelles pour créer notre lien.
CREATE OR REPLACE VIEW vo_signature OF ty_signature

WITH OBJECT IDENTIFIER (att_numero)
AS SELECT numero,
nom,
CAST(MULTISET(
SELECT REF(vo_o)
FROM vo_objet vo_o
WHERE
vo_o.att_ref_signature.att_numero = s.numero
) AS TY_TABLE_REFS_OBJ)
FROM Men.Signature s;
CREATE OR REPLACE VIEW vo_signature OF ty_signature

WITH OBJECT IDENTIFIER (att_numero)
AS SELECT numero,
nom,
CAST(MULTISET(
SELECT REF(vo_o)
FROM vo_objet vo_o, men.objet o
WHERE vo_o.att_numero = o.numero
AND o.signature_numero = s.numero
) AS TY_TABLE_REFS_OBJ)
FROM Men.Signature s;
Le schéma suivant vous montre le cheminement logique de ces jointures. La flèche

en pointillé représente le premier exemple et les flèches pleines, le second.
Vue vo_objet Table signature
att_numero numero
att_ref_signature …
…
Table objet
numero
signature_numero
…
Figure 10
Cheminement logique
Même si, au premier abord, la première méthode paraît plus simple, il est fortement
conseillé de n'utiliser que la deuxième.

au MEN
4 Conclusion
L'implémentation des triggers de manipulations de données s'est bien déroulée et

elle a permis de mettre à jour des problèmes et des cas d'utilisation qui n'étaient pas
ressortis lors des tests sur le modèle Classe – Elève, notamment, les cas d'inclusion
avec vues et la nécessitée de créer correctement les vues avec collections.
De plus, l'utilisation de méthodes de manipulation de données nous a permis de

combler les déficiences des triggers aux niveaux de la gestion des collections
d'objets. Nous pouvons dorénavant ajouter ou supprimer simplement des objets
faisant partie d'une collection.
Et enfin, l'implémentation du concept d'héritage nous a permis de distinguer les

personnes physiques des personnes morales.
En conclusion, ce projet nous conforte dans l'idée que le concept objet sur une
implémentation relationnelle est tout à fait prometteur puisqu'il nous ouvre l'accès au
côté objet tout en conservant les acquis du relationnel ainsi que sa puissance.
Les mAJ sont des objets inclus ne sont pas triviale, mais elles restent maîtrisables
par le développeur.
Le gros intérêt de travailler avec une base RO est la disponibilité des méta-donées.
Pour être pleinement convaincu de l'utilisation du modèle RO il faudrait un client
objet, mais c'est un projet complet
5 Versions
Version d'Oracle : Oracle8i Enterprise Edition Release 8.1.7.1.0

Version documentation : Oracle 8i Documentation Library Release 3 (8.1.7 for
Windows)

au MEN

ISNet15 16

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

ISNet15 16

Transféré par

Droits d'auteur :

Formats disponibles

IS-Net 15 Bases de données relationnelles objets

Eddy.Meylan@hegne.ch / Octobre 2001

TABLE DES MATIERES

Implémentation d'une BDRO Page 2 sur 44 09/11/01

Ce document décrit les étapes de la mise en place d'un schéma objet-relationnels

Implémentation d'une BDRO Page 3 sur 44 09/11/01

Réalisation avec des

Réalisatio avec des

La base de données de production du MEN doit subire quelques modifications

Implémentation d'une BDRO Page 4 sur 44 09/11/01

Implémentation d'une BDRO Page 5 sur 44 09/11/01

1.2.1 Modèle de classes cible

Implémentation d'une BDRO Page 6 sur 44 09/11/01

1.2.2 Modèle E-A source

Implémentation d'une BDRO Page 7 sur 44 09/11/01

1.3 Conventions syntaxiques

vo_ vue objet

1.4 Méthodes des classes

• Gestion de la cotation des objets,

Implémentation d'une BDRO Page 8 sur 44 09/11/01

1.4.4 Mis à jour complexes

1.4.5 Interfaçage XML

Implémentation d'une BDRO Page 9 sur 44 09/11/01

2.1 Package pour la gestion des erreurs

Pour simplifier la mise en place de notre gestionnaire d'erreurs centralisé, un

Implémentation d'une BDRO Page 10 sur 44 09/11/01

2.2 Mise en place des types

2.2.1 Types abstraits

L'implémentation de méthodes permet de calculer la forme et le volume de l'objet (ou

CREATE OR REPLACE TYPE TY_DIMENSION AS OBJECT (

Implémentation d'une BDRO Page 11 sur 44 09/11/01

CREATE OR REPLACE TYPE TY_DATE_APPROX AS OBJECT (

Les méthodes implémentées sont abondamment documentées dans le document

CREATE OR REPLACE TYPE ty_Adresse AS OBJECT (

Implémentation d'une BDRO Page 12 sur 44 09/11/01

2.2.2 Types avec implémentation

2.2.2.1 ty_image et ty_table_images

Implémentation d'une BDRO Page 13 sur 44 09/11/01

CREATE OR REPLACE TYPE TY_ETHNIE AS OBJECT (

2.2.2.4 ty_matiere, ty_ordre_matiere

Donc le type ty_ordre_matiere permet d'introduire la notion d'ordre (att_ordre) pour

CREATE OR REPLACE TYPE TY_ORDRE_MATIERE AS OBJECT (

Implémentation d'une BDRO Page 14 sur 44 09/11/01

CREATE OR REPLACE TYPE TY_COLLECTION AS OBJECT (

La collection sera datée par l'intermédiaire de l'attribut att_date_creation qui est de

Implémentation d'une BDRO Page 15 sur 44 09/11/01

Implémentation d'une BDRO Page 16 sur 44 09/11/01

Le modèle se résume ainsi :

Implémentation d'une BDRO Page 17 sur 44 09/11/01

Le type ty_objet est le plus compliqué et également le plus intéressant. En plus de

CREATE OR REPLACE TYPE TY_OBJET AS OBJECT (

Implémentation d'une BDRO Page 18 sur 44 09/11/01

2.3 Création des vues

2.3.1 Choix de l’identifiant

WITH OBJECT IDENTIFIER (XXX)

Implémentation d'une BDRO Page 19 sur 44 09/11/01

2.4 Implémentation des triggers instead of

Implémentation d'une BDRO Page 20 sur 44 09/11/01

2.4.2 vue vo_image

Implémentation d'une BDRO Page 21 sur 44 09/11/01

Implémentation d'une BDRO Page 22 sur 44 09/11/01

Notre vue vo_intervenant_financier étant basé sur le type ty_ref_financier, nous

La vérification est simple : Si une de ces références existe, il va falloir retrouver le