Examen bases de données avancées master 2011 2012 pdf

Examen bases de données avancées master 2011 2012 Bases de d

Télécharger PDF

Modélisation et Optimisation des Bases de Données Avancées

Ce billet explore des concepts fondamentaux en bases de données avancées, notamment la modélisation orientée objet avec le langage ODL et les requêtes OQL, ainsi que les stratégies de fragmentation et d'allocation dans un contexte de bases de données distribuées. Ces techniques sont essentielles pour concevoir des systèmes robustes et performants.

Conception d'une Base de Données Universitaire

Une université gère des enseignants, des étudiants et des modules de cours. Chaque entité possède des caractéristiques spécifiques et des interactions définies pour assurer le suivi académique et administratif.

Étudiant : Caractérisé par un numéro, un nom, un ou plusieurs prénoms, et une date de naissance.
Enseignant : Caractérisé par un numéro, un nom, un prénom, un grade (MA, MC, Pr) et une adresse. Le suivi des promotions est crucial.
Corps Enseignants :
- Titulaires : Possèdent un grade et une spécialité, peuvent être responsables d'un module (au maximum un seul).
- Moniteurs : Étudiants bénéficiant d'un contrat d'enseignement à durée déterminée, avec un nombre maximal d'heures par semaine.
- Vacataires : Rémunérés en fonction de leur charge horaire d'enseignement.
Formation : Composée de plusieurs modules, caractérisée par un intitulé et un cycle (premier, deuxième, etc.).
Module : Identifié par un code, un libellé, et une durée semestrielle en heures. Un module peut être commun à plusieurs formations et est dispensé par un ou plusieurs enseignants.
Inscription : Les étudiants s'inscrivent aux modules. Un module est acquis si la note est supérieure à 10/20. L'inscription peut avoir des prérequis.
Prérequis : L'inscription à un module peut nécessiter l'obtention préalable d'autres modules.
Opérations clés :
- Inscrire : Vérifie les prérequis (note supérieure à 10 ou possession des formations contenant les modules prérequis) avant d'autoriser l'inscription.
- Valider_formation : Un étudiant valide une formation s'il a acquis tous les modules la composant.

Modélisation Conceptuelle (Diagramme de Classes)

La modélisation conceptuelle, souvent représentée par un diagramme de classes UML, permet de structurer les entités du système, leurs attributs, leurs relations, y compris l'héritage et les classes d'association. Voici les éléments clés du modèle de l'université :

Classe Formation :
- Attributs : Intitulé (clé), Cycle.
- Relation : Associe une formation à plusieurs Modules (via la relation Matière/Cursus).
Classe Module :
- Attributs : Code (clé), Libellé, Durée.
- Relations : Lié à des Formations, des Enseignants (Mod-Enseigné), un Titulaire responsable (Mod-Resp), et à d'autres Modules en tant que prérequis.
Classe Enseignant :
- Attributs : Num (clé), Nom, Prénom (ensemble de chaînes), Grade, Adresse.
- Relation : Peut enseigner plusieurs Modules.
Classe Étudiant :
- Attributs : Numéro (clé), Nom, Prénom (ensemble de chaînes), Date de Naissance.
- Opérations (Méthodes) : Valider_Diplôme(), Inscrire().
Classe Inscription (Classe d'association entre Étudiant et Module) :
- Attribut : Note.
- Relations : Représente la liaison entre un Étudiant et un Module avec une note associée.
Héritage des Enseignants :
- Titulaire : Hérite d'Enseignant. Attributs : Grade, Spécialité.
- Moniteur : Hérite d'Enseignant et d'Étudiant (héritage multiple). Attribut : NB-Heures.
- Vacataire : Hérite d'Enseignant. Attribut : Charge.

Définition du Schéma de Base de Données Orientée Objet (ODL)

L'ODL (Object Definition Language) est le langage standard utilisé pour définir le schéma d'une base de données orientée objet (BDOO). Il permet de spécifier les classes, leurs attributs, leurs relations (avec des inversions pour garantir la cohérence bidirectionnelle) et leurs méthodes, comme illustré ci-dessous pour le modèle universitaire.

    Université {
        Classe Formation {
            Extents Formations Key(Intitulé)
            Attribute Intitulé string;
            attribute Cycle int;
            Relationship <Set> Module ::Matière inverse Formation ::Cursus;
        }
        Classe Module {
            Extents Modules Key(Code)
            Attribute Code int;
            attribute Libellé string;
            Attribute Durée int;
            Relationship <Set> Formation ::Cursus inverse Module ::Matière;
            Relationship <Set> Inscription ::Inscr-mod inverse Module ::Mod-inscr;
            Relationship <Set> Enseignant ::Mod-Enseigné inverse Enseignant ::Enseignant;
            Relationship <Set> Titulaire ::Mod-Resp inverse Titulaire ::Responsable;
            Relationship <Set> Module ::Pré-requis inverse Module ::Est-Pré-requis;
        }
        Classe Enseignant {
            Extents Enseignants Key(Num)
            Attribute Num int;
            attribute Nom string;
            Attribute Prénom <Set> string;
            Attribute Grade string;
            Attribute Adresse string;
            Relationship <Set> Module ::Enseignant inverse Enseignant ::Mod-Enseigné;
        }
        Classe Etudiant {
            Extents Etudiants Key(Numéro)
            Attribute Numéro int;
            attribute Nom string;
            Attribute Prénom <Set> string;
            Attribute DN date;
            Relationship <Set> Inscription ::Inscr-etud inverse Etudiant::Etud-Inscr;
            Method valider_diplôme();
            Method Inscrire();
        }
        Classe Inscription {
            Extents Inscriptions Key(Module ::Code,Etudiant ::Numéro)
            Attribute Note float;
            Relationship Module ::Mod-Inscr inverse Inscription::Inscr-Mod;
            Relationship Etudiant ::Etud-Inscr inverse Inscription::Inscr-Etud;
        }
        Classe Titulaire INHERIT Enseignant {
            Extents Titulaires
            Attribute Grade string;
            attribute Spécialité string;
            Relationship Module ::Mod-Resp inverse Titulaire ::Responsable;
        }
        Classe Moniteur INHERIT Enseignant, Etudiant {
            Extents Moniteurs
            Attribute NB-heure int;
        }
        Classe Vacataire INHERIT Enseignant {
            Extents Vacataires
            Attribute Charge int;
        }
    }

Requêtes sur la Base de Données Orientée Objet (OQL)

OQL (Object Query Language) est le langage de requête standard pour les bases de données orientées objet. Il permet d'interroger les objets, leurs attributs et leurs relations de manière puissante et déclarative.

Donner les étudiants Amin, Ali et Réda ayant comme premier prénom Mohamed.
```
Select e
From Etudiants e
where (select p from e.Prénom p order by p asc limit 1) = 'Mohamed'
  and exists (select p from e.Prénom p where p in ('Amin', 'Ali', 'Réda'))
            
```
Note : L'attribut Prénom de la classe Etudiant a été défini comme un ensemble (<Set> string) pour permettre plusieurs prénoms, conformément à la description du problème. L'accès au "premier prénom" est interprété ici par un tri alphabétique pour un ensemble, et la vérification de la présence des autres prénoms via exists.

Donner, pour chaque formation de 1er cycle, l’ensemble des codes des modules.

Select f.Intitulé, (select m.Code from f.Matière m)
from Formations f
where f.Cycle = 1

Donner le nom des professeurs responsables des modules de plus de 30 h et composant les formations de 1er cycle.

Select t.Nom
from Titulaires t
where t.Responsable.Durée > 30
  AND exists (select f_cursus from t.Responsable.Cursus f_cursus where f_cursus.Cycle = 1)

Donner les enseignants de grade professeur qui enseignent tous les modules ayant une durée de plus de 30 h.

Select e
from Enseignants e
where e.Grade = 'Pr'
  and for all m in Modules: (m.Durée > 30 implies m in e.Mod-Enseigné)

Concepts Avancés en Bases de Données Distribuées

Les bases de données distribuées permettent de stocker et de gérer des données sur plusieurs sites physiques. La fragmentation est une technique clé pour optimiser les performances et la disponibilité en divisant les tables en parties plus petites, appelées fragments. Cela permet de placer les données au plus près de leurs utilisateurs principaux.

Gestion d'un Concessionnaire Automobile Distribué

Considérons une base de données pour un concessionnaire automobile avec deux tables principales :

Véhicule : Contient des informations détaillées sur chaque véhicule (Numéro de série, Année de première circulation, Marque, Type, Nombre d'airbags, Nombre de vitesses, Nombre de cylindres, Couleur, Énergie, Vitesse maximale, Climatisation).
Ventes : Enregistre les transactions de vente (Numéro de série du véhicule, ID du client, Date de vente, Montant).

Le concessionnaire dispose de trois services localisés : Après-Ventes (Site A), Marketing (Site B), et Technique (Site C), chacun avec des besoins spécifiques en données.

Fragmentation Horizontale des Données

La fragmentation horizontale divise une table en fragments distincts en fonction de valeurs d'attributs spécifiques, chaque fragment contenant un sous-ensemble de lignes. Cela est particulièrement utile pour les services qui n'ont besoin que d'une partie des données.

Schéma de Fragmentation Initial pour le Service Après-Ventes

Le service après-ventes (Site A) s'intéresse uniquement aux véhicules vendus mis en service après 2009. Pour répondre à ce besoin, la table Véhicule est fragmentée horizontalement :

Véhicule1 : Contient les véhicules dont l'année de première circulation est supérieure ou égale à 2009.

Véhicule1 = σ Année_première_circulation >= 2009 (Véhicule)
Véhicule2 : Contient les véhicules dont l'année de première circulation est inférieure à 2009.

Véhicule2 = σ Année_première_circulation < 2009 (Véhicule)

La table Ventes est ensuite fragmentée en fonction de la fragmentation de Véhicule pour maintenir l'intégrité référentielle et faciliter les jointures locales. Cette méthode est appelée fragmentation dérivée.

Ventes1 : Contient les ventes de véhicules présents dans Véhicule1.

Ventes1 = Ventes ⋉ Véhicule1
Ventes2 : Contient les ventes de véhicules présents dans Véhicule2.

Ventes2 = Ventes ⋉ Véhicule2

Allocation des Fragments sur les Sites

Une allocation judicieuse des fragments sur les sites physiques réduit le trafic réseau et améliore les performances des requêtes locales :

Site A : Accueille Véhicule1 et Ventes1. Cette allocation est logique car le service après-ventes (intéressé par les véhicules récents) est situé au Site A, permettant ainsi l'exécution locale de la plupart de ses requêtes.
Site B : Accueille Véhicule2 et Ventes2.

Commandes SQL pour la Fragmentation

La fragmentation peut être mise en œuvre en SQL à l'aide de clauses de partitionnement. Voici des exemples pour les tables Véhicule et Ventes, incluant les attributs pour une meilleure clarté :

Table Véhicule :

Create Table VéhiculeFrag (
    N_série INT PRIMARY KEY,
    Année_première_circulation INT,
    Marque VARCHAR(50),
    Type VARCHAR(50),
    Nb_airbag INT,
    Nb_vitesses INT,
    Nb_cylindre INT,
    Couleur VARCHAR(20),
    Énergie VARCHAR(20),
    Vitesse_max INT,
    Climatisation BOOLEAN
)
Partition by range (Année_première_circulation) (
    Partition Véhicule2 Values less than 2009,
    Partition Véhicule1 Values less than MAXVALUE
);

Table Ventes :

Create Table VentesFrag (
    N_Série INT,
    IDClient INT,
    Date_Ventes DATE,
    Montant DECIMAL(10, 2),
    CONSTRAINT pk_ventes PRIMARY KEY (N_Série, IDClient, Date_Ventes),
    CONSTRAINT fk_vehicule FOREIGN KEY(N_Série) REFERENCES VéhiculeFrag(N_Série)
)
Partition by reference (fk_vehicule);

Réécriture de la Requête R1 après Fragmentation Horizontale

La requête R1 originale est : Select Nb_Vitesses, Moy(Montant) From Véhicule V, Ventes T where T.N_Série=V.N_Série and V.Année_première_circulation<2011. Pour exécuter cette requête sur des fragments distribués, elle doit être réécrite pour interroger chaque fragment pertinent et combiner les résultats à l'aide d'un opérateur UNION ALL.

Select Nb_Vitesses, Moy(Montant)
From Véhicule1 V, Ventes1 T
where T.N_Série = V.N_Série and V.Année_première_circulation < 2011
UNION ALL
Select Nb_Vitesses, Moy(Montant)
From Véhicule2 V, Ventes2 T
where T.N_Série = V.N_Série and V.Année_première_circulation < 2011;

Stratégies d'Exécution de la Requête R1

Les stratégies d'exécution des requêtes dans un environnement distribué varient considérablement en fonction du site de lancement et de l'emplacement des fragments. Elles visent à minimiser les coûts de communication et de traitement.

Si R1 est lancée au Site A :
- La première sous-requête (impliquant Véhicule1 et Ventes1) est exécutée localement au Site A, car les fragments y sont stockés.
- Pour la deuxième sous-requête (impliquant Véhicule2 et Ventes2, situées au Site B) :
  1. Stratégie 1 (Transfert de données, puis exécution) : Les fragments Véhicule2 et Ventes2 sont envoyés intégralement au Site A. La sous-requête est exécutée au Site A, puis l'union des résultats est effectuée localement.
  2. Stratégie 2 (Exécution distante, puis transfert de résultats) : La jointure entre Ventes2 et Véhicule2 est exécutée localement au Site B. Le résultat partiel (agrégé ou filtré) est ensuite envoyé au Site A, où l'union des résultats est effectuée. Cette stratégie est généralement préférée pour minimiser les transferts de données sur le réseau.
Si R1 est lancée au Site C :
- Stratégie S1 (Exécution parallèle et union finale) : La première sous-requête est exécutée au Site A, et la deuxième sous-requête au Site B. Les deux résultats sont ensuite envoyés au Site C où l'union finale est effectuée.
- Stratégie S2 (Exécution séquentielle sur un site intermédiaire) : La première sous-requête est exécutée au Site A. Ensuite, les tables Ventes2 et Véhicule2 sont envoyées au Site A. La deuxième sous-requête est exécutée au Site A. L'union est effectuée au Site A, puis le résultat final consolidé est envoyé au Site C.
- Stratégie S3 (Déplacement complet des données) : Tous les fragments (Véhicule1, Ventes1, Véhicule2, Ventes2) sont déplacés au Site C. Les deux sous-requêtes et l'union sont exécutées localement au Site C. Cette stratégie peut être très coûteuse en termes de trafic réseau initial si les fragments sont volumineux.

Fragmentation Mixte (Horizontale et Verticale)

En plus de la fragmentation horizontale, la fragmentation verticale divise une table en fragments contenant un sous-ensemble de colonnes. La combinaison des deux approches permet une fragmentation mixte, qui optimise l'accès aux données pour des requêtes ciblant des ensembles d'attributs spécifiques.

Nouveau Schéma de Fragmentation pour la Table Véhicule

Pour répondre aux besoins spécifiques des services Marketing (caractéristiques commerciales) et Technique (caractéristiques techniques), la fragmentation horizontale initiale est affinée par une fragmentation verticale.

Chaque fragment horizontal (Véhicule1 et Véhicule2) est subdivisé verticalement :

Fragments de Véhicule1 (pour véhicules ≥ 2009) :

Véhicule1Comm : Contient les caractéristiques commerciales.

PROJECTION (N_Série, Année_première_circulation, Marque, Type, Couleur, Énergie, Climatisation) (Véhicule1)

Véhicule1Tech : Contient les caractéristiques techniques.

PROJECTION (N_Série, Nb_airbag, Nb_vitesses, Nb_cylindre, Vitesse_max) (Véhicule1)

Fragments de Véhicule2 (pour véhicules < 2009) :

Véhicule2Comm : Contient les caractéristiques commerciales.

PROJECTION (N_Série, Année_première_circulation, Marque, Type, Couleur, Énergie, Climatisation) (Véhicule2)

Véhicule2Tech : Contient les caractéristiques techniques.

PROJECTION (N_Série, Nb_airbag, Nb_vitesses, Nb_cylindre, Vitesse_max) (Véhicule2)

Ce type de fragmentation est appelé Fragmentation Mixte.

Réécriture de la Requête R1 suite à la Fragmentation Mixte

Avec la fragmentation mixte, la requête R1 doit désormais joindre les fragments verticaux appropriés avant de pouvoir effectuer les calculs. Il est crucial d'inclure les clés primaires (N_Série) dans chaque fragment vertical pour permettre ces jointures.

Select V2.Nb_Vitesses, Moy(T.Montant)
From Véhicule1Comm V1, Véhicule1Tech V2, Ventes1 T
where T.N_Série = V1.N_Série
  and V1.N_Série = V2.N_Série
  and V1.Année_première_circulation < 2011
UNION ALL
Select V2.Nb_Vitesses, Moy(T.Montant)
From Véhicule2Comm V1, Véhicule2Tech V2, Ventes2 T
where T.N_Série = V1.N_Série
  and V1.N_Série = V2.N_Série
  and V1.Année_première_circulation < 2011;

Note : L'attribut Année_première_circulation est présent dans Véhicule1Comm et Véhicule2Comm, tandis que Nb_Vitesses se trouve dans Véhicule1Tech et Véhicule2Tech. Les jointures entre les fragments commerciaux et techniques (V1.N_Série = V2.N_Série) sont essentielles.

Stratégies d'Exécution de R1 sur le Site C avec Fragmentation Mixte

Lorsqu'une requête est lancée sur le Site C avec une fragmentation mixte, les stratégies d'exécution deviennent plus complexes et doivent gérer les jointures entre les fragments horizontaux et verticaux distribués :

Stratégie A : Effectuer toutes les jointures nécessaires (entre Ventes, VéhiculeComm et VéhiculeTech) localement dans chaque site (Site A pour les fragments Véhicule1 et Site B pour les fragments Véhicule2). Les résultats partiels sont ensuite envoyés au Site C où l'union finale est effectuée.
Stratégie B : Déplacer toutes les données pertinentes (tous les fragments) vers le Site C. Exécuter ensuite les deux sous-requêtes complètes (incluant les jointures entre fragments verticaux) et réaliser l'union localement sur le Site C. Cette approche peut générer un trafic réseau initial très important.
Stratégie C : Exécuter la première sous-requête (liée aux fragments du Site A) au Site A. Envoyer ce résultat intermédiaire au Site B. Sur le Site B, exécuter la deuxième sous-requête (liée aux fragments du Site B) et effectuer l'union des résultats partiels. Le résultat combiné est ensuite envoyé au Site C.
D'autres stratégies complexes peuvent impliquer des semi-jointures pour réduire les données transférées, ou l'utilisation d'un site désigné comme coordinateur pour orchestrer les exécutions et les fusions de résultats.

Foire Aux Questions (FAQ)

Qu'est-ce que l'ODL (Object Definition Language) ?: L'ODL est un langage standard utilisé pour définir la structure (le schéma) des bases de données orientées objet. Il permet de spécifier les classes, leurs attributs, les relations entre elles et les méthodes qu'elles peuvent exécuter, offrant une approche de modélisation plus proche de la programmation orientée objet.
À quoi sert la fragmentation dans une base de données distribuée ?: La fragmentation consiste à diviser une table logique en plusieurs sous-ensembles (fragments) qui peuvent être stockés sur différents sites physiques d'un système distribué. Elle vise à améliorer la performance des requêtes (en réduisant les données à scanner), la disponibilité des données, la fiabilité et la sécurité en localisant les données au plus près de leurs utilisateurs ou applications.
Quelle est la différence principale entre la fragmentation horizontale et verticale ?: La fragmentation horizontale divise une table en lignes distinctes, chaque fragment contenant un sous-ensemble des enregistrements basés sur un critère (par exemple, tous les véhicules produits avant 2009). La fragmentation verticale divise une table en colonnes distinctes, chaque fragment contenant un sous-ensemble des attributs de la table (par exemple, un fragment avec les attributs commerciaux et un autre avec les attributs techniques d'un véhicule).