Correction de l'activité 4.1 - Bases de données Avancées
Ce laboratoire porte sur la modélisation et l'interrogation avancée d'une base de données orientée objet à l'aide du langage ODL (Object Definition Language) et du langage de requête OQL (Object Query Language). Il permet d'apprendre à définir un schéma complexe avec héritage, relations et collections, puis à écrire des requêtes pour extraire des informations précises.
D'après le document Correction de l'activité 4.1 - Bases de données Avancées
Cet article a été rédigé automatiquement à partir du document source, puis vérifié avant publication.

Document source
Database Design and Querying · PDF · 4 pages · 2020
Afficher l'aperçu du document
Ce laboratoire porte sur la modélisation et l'interrogation avancée d'une base de données orientée objet à l'aide du langage ODL (Object Definition Language) et du langage de requête OQL (Object Query Language). Il permet d'apprendre à définir un schéma complexe avec héritage, relations et collections, puis à écrire des requêtes pour extraire des informations précises. Pour réaliser cette activité, il est nécessaire de disposer d'un environnement supportant ODL et OQL, ainsi que des connaissances de base en bases de données orientées objet.
Objectifs
- Modéliser une base de données orientée objet avec héritage et relations complexes.
- Écrire des requêtes OQL pour interroger des objets et leurs relations.
- Utiliser des collections, des structures et des opérations avancées dans OQL.
- Créer des vues pour simplifier l'accès aux données.
Prérequis et installation
- Connaissances en bases de données orientées objet et en modélisation ODL.
- Maîtrise des concepts d'héritage, de relations inverses et d'attributs multivalués.
- Environnement logiciel capable d'interpréter ODL et d'exécuter des requêtes OQL.
- Accès à la base de données contenant les classes et objets décrits.
Définition du schéma ODL
La première étape consiste à définir un schéma ODL pour la base de données. Ce schéma modélise des entités telles que Personne, Voiture, Buveur, Employé, Appartement et Vin, avec des relations et des héritages adaptés.
On choisit d'implémenter des extensions pour les classes Voiture, Vin, Appartement, Buveur, Employé et Personne. L'héritage multiple n'étant pas possible, la classe EmployéBuveur est une extension d'Employé qui répète les propriétés de Buveur.
Voici un extrait du schéma :
class Voiture (extent voitures) {
string nveh;
string couleur;
string marque;
short km;
Personne appartient;
void rouler(in short distance);
};
class Personne (extent personnes) {
string nss;
string nom;
string prenom;
date datenaissance;
Appart habite;
Set<Voiture> possède;
void vieillir();
void dormir();
short age();
};
class Employé extends Personne (extent employés) {
float salaire;
list<float> primes; // attribut multivalué
enum fonct {ingénieur, secrétaire, analyste, programmeur} fonction;
Set<Employé> supérieur;
Set<Employé> inférieurs;
void travailler();
inverse Employé::supérieur;
inverse Employé::inférieurs;
};
class Buveur extends Personne (extent buveurs) {
enum typebuv {petit, moyen, gros} type;
enum etabuv {normal, ivre} etat;
list<Vin> boire(in Vin v);
inverse Vin::bu_par;
};
class Appart (extent Apparts) {
struct adresse {
short etage;
unsigned short numero;
string rue;
unsigned short code;
string ville;
};
Set<Personne> loge;
inverse Personne::habite;
};
class Vin (extent Vins) {
string cru;
string millesime;
string degre;
string qualite;
list<Buveur> bu_par;
inverse Buveur::boire;
};
class EmployéBuveur extends Employé (extent employés_buveurs) {
enum typebuv {petit, moyen, gros} type;
enum etabuv {normal, ivre} etat;
list<Vin> boire(in Vin v);
inverse Vin::bu_par;
};
Ce schéma définit les attributs, relations et méthodes des classes, ainsi que les inverses pour naviguer dans les relations.
Requêtes OQL
Une série de requêtes OQL permet d'interroger la base selon différents critères. Voici les principales requêtes à réaliser, avec leur objectif et syntaxe :
Accéder à la couleur d'une voiture
Attribuer l'objet persistant MAVOITURE à une voiture et obtenir sa couleur :
mavoiture.couleur;
Nom du propriétaire de MAVOITURE
mavoiture.appartient.nom;
Numéros de sécurité sociale des employés inférieurs du propriétaire de MAVOITURE
mavoiture.appartient.inférieurs.nss;
select from m in mavoiture.appartient.inférieurs;
m.nss
Noms et prénoms des grands buveurs
SELECT b.nom, b.prénom
FROM buveurs b
WHERE b.type = 'gros';
Noms et prénoms des employés grands buveurs
SELECT eb.nom, eb.prénom
FROM employés_buveurs eb
WHERE eb.type = 'gros';
Buveurs ayant bu du Volnay
SELECT b.nom, b.prénom
FROM buveurs b, v in b.boire
WHERE v.cru = 'Volnay';
Doublets (nom, ville) pour chaque gros buveur
SELECT STRUCT(nom: b.nom, ville: b.habite.adresse.ville)
FROM buveurs b
WHERE b.type = 'gros';
Nom, prénom des employés buveurs inférieurs du propriétaire de MAVOITURE et liste de leurs vins bus
SELECT STRUCT(
nom: STRUCT(nom_buveur: eb.nom, prenom_buveur: eb.prenom),
vins: (
SELECT STRUCT(
cru_vin: v.cru,
millésime_vin: v.millésime,
degré_vin: v.degre,
qualité_vin: v.qualite
)
FROM v in eb.boire
)
)
FROM employés_buveurs eb
WHERE eb.supérieur = mavoiture.appartient;Objet employé avec numéro de sécurité sociale "77"
element(
SELECT e
FROM employés e
WHERE e.nss = '77'
);
Moyenne des salaires des employés buveurs ayant la fonction "analyste"
avg(
SELECT eb.salaire
FROM employés_buveurs eb
WHERE eb.fonction = 'analyste'
);
Liste des identifiants d’objets des voitures de marque « Renault »
ARRAY(
SELECT v
FROM voiture v
WHERE v.marque = 'renault'
);
Nom, ville d’habitation et âge des employés avec salaire > 10000 et âge < 30 ans
SELECT DISTINCT e.nom, e.habite.adresse.ville, e.age()
FROM employés e
WHERE e.salaire > 10000 AND e.age() < 30;
Buveurs ayant bu le vin « beaujolais 2019 »
SELECT b.nom, b.prénom
FROM buveurs b
WHERE 'beaujolais 2019' IN (
SELECT v.cru FROM v IN b.boire
);
Les employés buveurs programmeurs habitent-ils tous à Tunis ?
for all eb in (
SELECT eb FROM employés_buveurs eb
WHERE eb.fonction = 'programmeur'
) :
eb.habite.adresse.ville = 'Tunis';
Nom et liste des inférieurs mieux payés que chaque employé
SELECT DISTINCT STRUCT(
nom: e.nom,
inf_mieux_payés: LIST(
SELECT i
FROM i IN e.inférieurs
WHERE i.salaire > e.salaire
)
)
FROM employés e;
Trois employés buveurs les mieux payés possédant une voiture "Volswagen"
(SELECT STRUCT(
nom_personne: eb.nom,
prenom_personne: eb.prenom,
salaire: eb.salaire
)
FROM employés_buveurs eb
WHERE eb.Possède.marque = 'Volswagen'
ORDER BY eb.salaire DESC)[0:2];
Salaire moyen des employés par ville si supérieur à 5000
SELECT STRUCT(
ville,
moy: AVG(
SELECT p.salaire FROM p IN PARTITION
)
)
FROM employés e
GROUP BY ville: e.habite.adresse.ville
HAVING AVG(
SELECT p.salaire FROM p IN PARTITION
) > 5000;
Création d'une vue et requête associée
Pour faciliter l'extraction des employés inférieurs d'un supérieur propriétaire d'une voiture donnée, on crée une vue nommée a_pour_inferieurs :
DEFINE a_pour_inferieurs(nveh) AS
SELECT i
FROM employés e, i IN e.inférieurs
WHERE e.possède = nveh;
Ensuite, on peut compter le nombre d'inférieurs pour le propriétaire de la voiture numéro "55" :
count(a IN a_pour_inferieurs('55'));
Résultats attendus
- Le schéma ODL doit refléter correctement les relations et héritages, sans erreur de syntaxe.
- Les requêtes OQL doivent retourner les résultats attendus, par exemple :
- La couleur de MAVOITURE correspond à celle définie dans la base.
- Les noms et prénoms des grands buveurs correspondent aux objets avec type = 'gros'.
- Les listes d'inférieurs, de vins bus, et autres collections sont complètes et cohérentes.
- Les calculs comme la moyenne des salaires ou les tris fonctionnent correctement.
- La vue
a_pour_inferieursdoit permettre d'extraire rapidement les employés inférieurs d'un propriétaire donné.
Pièges courants
- Confondre les relations et leurs inverses, ce qui peut entraîner des erreurs de navigation dans les objets.
- Oublier que l'héritage multiple n'est pas possible, donc dupliquer les propriétés dans les classes dérivées.
- Mal utiliser les collections (listes, sets) dans les requêtes OQL, notamment dans les clauses FROM imbriquées.
- Ne pas respecter la syntaxe exacte des requêtes, notamment les majuscules/minuscules et la structure SELECT-FROM-WHERE.
- Ne pas vérifier que les objets existent dans la base avant d'interroger leurs attributs (ex : MAVOITURE doit être défini).
- Dans les requêtes avec des structures (STRUCT), ne pas oublier de nommer correctement les champs pour une extraction claire.
- Lors de l'utilisation de fonctions comme avg ou count, s'assurer que la sélection porte sur les bons ensembles d'objets.
Commentaires
Aucun commentaire pour le moment. Posez la première question.