Bases de données Avancées – Activité 4.0

Ce TP consiste à modéliser une base de données avancée nommée UNIVERSITE en utilisant un schéma EER (Enhanced Entity-Relationship). L'objectif est de représenter les informations relatives aux personnes (professeurs et étudiants), départements, cours, sessions, projets de recherche et subventions. Ce travail permet de comprendre la conception d’un schéma objet pour une base de données complexe, intégrant héritages, relations multiples et attributs spécifiques. Pour réaliser ce TP, il faut disposer d’un logiciel de modélisation EER ou d’un éditeur de schéma ODL (Object Definition Language).

Objectifs

• Définir un schéma EER complet pour une base de données universitaire.
• Modéliser les entités PERSONNE, PROFESSEUR, ETUDIANT, ETUD_DIP, DEPARTEMENT, FACULTE, COURS, SESSION, SUBVENTION.
• Représenter les relations multiples (1:1, 1:N, M:N) entre ces entités.
• Utiliser l’héritage entre entités et sous-classes (ex. PROFESSEUR et ETUDIANT héritant de PERSONNE).
• Établir un schéma ODL conforme à la description fonctionnelle et graphique fournie.

Prérequis et installation

• Connaissance des concepts de bases de données relationnelles et objets.
• Compréhension des schémas EER et des notations graphiques associées.
• Logiciel de modélisation supportant ODL ou EER (ex. Oracle SQL Developer Data Modeler, ou tout autre outil compatible).
• Accès au document décrivant l’analyse des besoins et le schéma objet fourni.

Étape 1 : Analyse des entités et attributs

Commencez par identifier les entités principales et leurs attributs à partir de l’analyse fonctionnelle :

• PERSONNE : Nom, NoSS (numéro de sécurité sociale), Adresse, Sexe, NDate (date de naissance).
• PROFESSEUR (sous-classe de PERSONNE) : Rang, PBureau, PPhone, Salaire.
• ETUDIANT (sous-classe de PERSONNE) : Niveau (1 à 5).
• ETUD_DIP (sous-classe d’ETUDIANT, avec Niveau = 5) : Diplomes (attribut composite multivalué), RESP_RECH (responsable de recherche), COMITE (comité de thèse).
• DEPARTEMENT : DNom, DPhone, DBureau, PDT (président, un professeur), FAC (faculté associée).
• FACULTE : FNom, FBureau, Doyen.
• COURS : NoC (numéro de cours), CNom, CDesc (descriptif).
• SESSION : NoS (numéro de session unique), Annee, Trim (trimestre), enseigne (professeur enseignant la session).
• SESSION_COURANTE (sous-classe de SESSION) : Trim == TrimCour, Annee == AnCour.
• SUBVENTION : Titre, NoSub, Admin (administration attribuant la subvention), DateD (date de début), DR (directeur de recherche), BENEF (chercheurs bénéficiaires).
• BENEF (relation entre SUBVENTION et chercheurs) : Debut, Fin (date de fin si connue), Temps (pourcentage de temps consacré).

Cette étape permet de structurer les données et de préparer la modélisation des relations.

Étape 2 : Modélisation des relations

Représentez les relations entre les entités selon les contraintes suivantes :

• appartient : relation M:N entre PROFESSEUR et DEPARTEMENT (un professeur peut appartenir à plusieurs départements).
• DOMINANTE et SOUSDOMINANTE : relations liant ETUDIANT à des départements.
• INSCRIT : relation entre ETUDIANT et SESSION (sessions auxquelles l’étudiant est inscrit).
• DOSSIER : relation entre ETUDIANT et COURS, avec un attribut Note (note obtenue).
• PDT : relation 1:1 entre DEPARTEMENT et PROFESSEUR (président du département).
• FAC : relation 1:N entre FACULTE et DEPARTEMENT.
• enseigne : relation entre SESSION et PROFESSEUR (enseignant de la session).
• RESP_RECH : relation entre ETUD_DIP et PROFESSEUR (responsable de recherche).
• COMITE : relation entre ETUD_DIP et comité de thèse (si existant).
• BENEF : relation M:N entre SUBVENTION et ENSEIGNANT_CHERCHEUR (professeurs et étudiants diplômés), avec attributs Debut, Fin, Temps.

Cette étape clarifie les liens entre les entités et prépare la définition des cardinalités dans le schéma.

Étape 3 : Définition des sous-classes et héritage

Implémentez les héritages suivants :

• PERSONNE est la super-classe de PROFESSEUR et ETUDIANT.
• ETUD_DIP est une sous-classe de ETUDIANT, avec la contrainte Niveau = 5.
• ENSEIGNANT_CHERCHEUR est un sous-ensemble de l’union de PROFESSEUR et ETUD_DIP, regroupant tous ceux qui enseignent ou font de la recherche.
• SESSION_COURANTE est une sous-classe de SESSION, définie par les prédicats Trim == TrimCour et Annee == AnCour.

Cette organisation permet de gérer les spécificités des différentes catégories d’utilisateurs et sessions.

Étape 4 : Écriture du schéma ODL

À partir des entités, attributs, relations et héritages précédemment définis, rédigez un schéma ODL possible. Par exemple :

interface Personne_IF {
  attribute string Nom;
  attribute string NoSS;
  attribute string Adresse;
  attribute string Sexe;
  attribute date NDate;
};

class PERSONNE {
  attribute string Nom;
  attribute string NoSS;
  attribute string Adresse;
  attribute string Sexe;
  attribute date NDate;
};

class PROFESSEUR extends PERSONNE {
  attribute string Rang;
  attribute string PBureau;
  attribute string PPhone;
  attribute float Salaire;
  relationship set<DEPARTEMENT> appartient inverse DEPARTEMENT::professeurs;
};

class ETUDIANT extends PERSONNE {
  attribute integer Niveau;
  relationship DEPARTEMENT dominante;
  relationship DEPARTEMENT sousdominante;
  relationship set<SESSION> inscrit;
  relationship set<COURS> dossier;
};

class ETUD_DIP extends ETUDIANT {
  attribute multivalued string Diplomes;
  relationship PROFESSEUR resp_rech;
  relationship COMITE comite;
};

class DEPARTEMENT {
  attribute string DNom;
  attribute string DPhone;
  attribute string DBureau;
  relationship PROFESSEUR pdt;
  relationship FACULTE fac;
  relationship set<PROFESSEUR> professeurs inverse PROFESSEUR::appartient;
};

class FACULTE {
  attribute string FNom;
  attribute string FBureau;
  attribute string Doyen;
  relationship set<DEPARTEMENT> departements;
};

class COURS {
  attribute string NoC;
  attribute string CNom;
  attribute string CDesc;
  relationship set<SESSION> sessions;
};

class SESSION {
  attribute string NoS;
  attribute integer Annee;
  attribute integer Trim;
  relationship PROFESSEUR enseigne;
};

class SESSION_COURANTE extends SESSION {
  // Trim == TrimCour et Annee == AnCour
};

class SUBVENTION {
  attribute string Titre;
  attribute string NoSub;
  attribute string Admin;
  attribute date DateD;
  relationship PROFESSEUR dr;
  relationship set<ENSEIGNANT_CHERCHEUR> benef inverse BENEF::subvention;
};

relationship BENEF {
  attribute date Debut;
  attribute date Fin;
  attribute float Temps;
  relationship SUBVENTION subvention;
  relationship ENSEIGNANT_CHERCHEUR chercheur;
};

class ENSEIGNANT_CHERCHEUR {
  // Sous-ensemble de PROFESSEUR et ETUD_DIP
};

Cette définition doit être adaptée selon les contraintes du logiciel utilisé et les conventions ODL.

Résultats attendus

À la fin de ce TP, vous devez obtenir :

• Un schéma EER complet et cohérent représentant toutes les entités, attributs, relations et héritages décrits.
• Un schéma ODL conforme, prêt à être utilisé pour la création d’une base de données objet ou orientée objet.
• Une représentation claire des cardinalités, des sous-classes et des contraintes spécifiques (ex. Niveau = 5 pour ETUD_DIP).
• Une organisation logique permettant de gérer les inscriptions, les dossiers, les projets de recherche et les subventions.

Erreurs courantes

• Oublier la distinction entre PROFESSEUR et ETUDIANT dans l’héritage de PERSONNE.
• Ne pas respecter la contrainte Niveau = 5 pour ETUD_DIP.
• Confondre les relations DOMINANTE et SOUSDOMINANTE pour les départements des étudiants.
• Ignorer la relation M:N entre PROFESSEUR et DEPARTEMENT (appartient).
• Ne pas définir correctement la sous-classe SESSION_COURANTE avec ses prédicats Trim == TrimCour et Annee == AnCour.
• Omettre les attributs spécifiques des relations, notamment dans BENEF (Debut, Fin, Temps).
• Ne pas associer correctement les subventions aux chercheurs et directeurs de recherche.

Vérifiez systématiquement les cardinalités, les attributs obligatoires et les contraintes d’intégrité pour éviter ces erreurs.