Stéphane Pelle

poste 3159

 
 
 
 
 

21 août 2001

Quelques conseils pour construire facilement une base de données relationnelle
(par exemple sous Access)

Construire une base de données relationnelle ...

Quelques conseils pour construire une base de données relationnelle (par exemple sous Access).

1) Modéliser les données grâce à une méthode orientée objets *

1.1) Commencer par modéliser le cas général de manière simple *

1.2) Modéliser les détails du cas général *

1.3) Modéliser chaque application *

 2) Traduire le modèle de données en tables relationnelles * 2.1) Traduction d'une classe et de ses attributs *

2.2) Traduction d'un lien *

2.3) Traduction d'une hyperclasse *

 3) Construire les vues (requêtes sélection sous Access) * 3.1) Afficher les valeurs d'attributs prises dans une liste de choix *

3.2) Masquer des attributs *

3.3) Créer une vue sur un lien *
Quelques conseils pour construire une base de données relationnelle
(par exemple sous Access)

1) Modéliser les données grâce à une méthode orientée objets

La méthode HBDS présentée dans le document http://www.ensg.ign.fr/~spelle/HBDSConseils.htm a l'avantage d'être graphiquement simple, donc les schémas de données sont très faciles à lire.

1.1) Commencer par modéliser le cas général de manière simple

Figure  : Base de données générale de l’ENSG (version du 25/07/2001)

1.2) Modéliser les détails du cas général Après plusieurs cycles auteur/lecteurs, la modélisation s'affinera d'elle-même. Un lecteur n'a pas besoin d'avoir de l'expérience pour s'approprier le modèle (et son graphisme) et proposer des amendements. L'auteur devra par contre assurer la cohérence de l'ensemble et le respect des concepts : classe, attribut et lien.

Figure  : Base de données générale de l’ENSG (version du 20/08/2001)

1.3) Modéliser chaque application Le modèle général devant schématiser les données partagées, il ne suffit pas pour certaines applications. Tout lecteur concerné par un domaine particulier proposera des amendements spécifiques à son centre d'intérêt en précisant quelques fois que certaines données sont sensibles. On peut prendre l'exemple des évaluations des formés ou des formateurs : il est notoire que les formés et les formateurs sont évalués mais les conditions et surtout le résultat de ces évaluations n'ont pas besoin d'être publiques : ces données risquent d'encombrer inutilement la base de données générale et compliquer le contrôle des accès.

Figure  : Application de la base de données générale de l’ENSG à la notation des élèves (version du 20/08/2001)

On crée donc pour chaque application un modèle qui vient se greffer sur le modèle général afin de conserver la cohérence des données partagées. L'ajout d'attributs sur les classes du modèle général doit être examiné. On peut supposer que les attributs "ajoutés" sur les classes du modèle général sont des attributs privés (ou protégés) c'est-à-dire qu'ils ne sont accessibles que sous contrôle. On verra plus loin que les bases de données relationnelles introduisent la notion de vues pour permettre ces contrôles restreints ; les langages orientés objets comme C++ ou UML précisent pour chaque attribut s'il est public, privé ou protégé.

2) Traduire le modèle de données en tables relationnelles

Pour faciliter l'exploitation du modèle de données, il est nécessaire de se fixer des règles de traduction en tables. Ces règles peuvent être adaptées en gardant la cohérence de l'ensemble. Les règles présentées ci-dessous ne sont donc pas universelles mais permettent d'illustrer le discours avec des solutions éprouvées.

2.1) Traduction d'une classe et de ses attributs Une Classe Personnes est traduite par une table ClaPersonnes avec une colonne identifiant (dont le type de données est NuméroAuto sous Access) qui sert de clé primaire. On rappelle qu'une clé primaire est un ensemble minimum de colonnes dont la concaténation des valeurs pour chaque ligne est unique. La colonne identifiant suffit à elle seule pour assurer l'unicité de la ligne.

Figure  : Table ClaPersonnes (traduction en table de la classe Personnes)

Un attribut de la classe Personnes est donc traduit :

Figure  : Table ClaPersonnes (enregistrement 1/17…)

Figure  : Table ClaPersonnes (enregistrement 1/17 suite et fin)

Une liste de valeurs possibles pour un attribut Type de la classe Personnes est traduit par une table Type_Personnes avec une colonne identifiant (NuméroAuto) qui sert de clé primaire et une colonne type qui contient les valeurs possibles (sous forme de texte).
 

Figure  : Table Type_Personnes_ENSG (traduction en table d'un attribut "liste de choix")

Access permet de garder la correspondance automatique entre l'attribut id_type_personne_ensg de la table ClaPersonnes et l'attribut identifiant de la table Type_Personnes_ENSG grâce à une relation.

Figure  : Relation entre les tables ClaPersonnes et Type_Personnes_ENSG

Contrairement à ce qu'annonce l'Assistant Liste de Choix d'Access, il est préférable de ne pas cacher la clé primaire (colonne clé). Car si on cache cette clé, la valeur de id_type_personne_ensg de la table ClaPersonnes apparaîtra comme du TEXTE et n'ont pas comme une référence vers la table Type_Personnes_ENSG. L'affichage paraît a priori plus joli mais la saisie et les requêtes deviennent par la suite plus délicates. On utilisera la notion de vue décrite ci-après pour optimiser l'affichage de la table…

Figure  : Activer l'affichage de la clé secondaire dans l'Assistant Liste de Choix

2.2) Traduction d'un lien Un lien Anime de la classe Formateurs vers la classe Cours est traduit par une table LienAnime avec une colonne id_formateur (liste de choix dont les valeurs sont prises dans la colonne identifiant de la table ClaFormateurs) et une colonne id_seance (liste de choix dont les valeurs sont prises dans la colonne identifiant de la table ClaSeances). Les deux colonnes principales d'une table de lien sont donc construites comme des attributs listes de choix. On peut alors rajouter les éventuels attributs du lien comme autant de colonnes. Les deux colonnes principales (par exemple, id_formateur et id_seance) constituent la clé primaire de cette table (pas besoin de rajouter d’identifiant…).

Figure  : Table LienAnime (traduction en table du lien Anime)

2.3) Traduction d'une hyperclasse La traduction d'une hyperclasse est moins immédiate qu'il n'y paraît a priori. En effet, une hyperclasse HBDS peut servir à représenter deux notions, l'association et l'agrégation, distinctes dans d'autres langages comme UML. Si le mécanisme d'héritage est sous-jacent, il ne s'agit pas exactement de l'héritage des langages de programmation orientée objets comme C++.

Une hyperclasse HBDS sert à regrouper des classes et ne peut donc pas contenir directement des objets. Autrement dit, tous les objets sont dans une des classes incluses dans l'hyperclasse. La "suppression" de l'hyperclasse consisterait donc à recopier ("descendre") les attributs et les liens de l'hyperclasse sur chacune des classes incluses. Cette solution est envisageable lorsque tout objet modélisé est traduit dans une classe et une seule. Par exemple, les objets à ranger dans l'hyperclasse Moyens sont soit des objets de la classe Salles, soit de la classe Matériels (mais ne peuvent pas être traduits dans les deux).

Cependant, certaines hyperclasses et leurs classes ne sont qu'un moyen de distinguer les objets par leur fonction au sein du phénomène modélisé. Par exemple, une même personne (au sens de l'unicité des attributs de l'hyperclasse Personnes) peut être le responsable organisant un cours et le formateur animant une séance donc traduite par 2 objets (un objet de la classe Responsables et un objet de la classe Formateurs). La "suppression" de l'hyperclasse consisterait donc à créer une classe Personnes reliée à chacune des classes incluses. En outre, l'identifiant de chaque classe peut être avantageusement remplacé par une référence vers l'identifiant de la classe qui traduit l'hyperclasse (on conserve ainsi la notion d'hyperclasse).

Figure  : Table ClaPersonnes et ses relations (traduction en table de l'hyperclasse Personnes)

Il est évident que la traduction de l'hyperclasse en une classe est plus facile (on regroupe les attributs et les liens qui seraient dupliqués) mais elle devra nécessiter de contrôler l'utilisation des objets s'ils n'ont pas la même fonction au sein du système. A nouveau, les vues présentées ci-après nous permettront de mettre en œuvre ces contrôles…

3) Construire les vues (requêtes sélection sous Access)

Dans les Systèmes de Gestion de Bases de Données Relationnelles, les vues sont des sélections sur les colonnes d'une table avec ou sans jointures (sélection de lignes par correspondance entre la colonne d'une table et la colonne d'une autre table). Elles permettent de faire apparaître ou de masquer des colonnes en fonction des applications. Nous utiliserons donc des vues pour faire apparaître la valeur TEXTE de chaque attribut Liste de Choix ou pour masquer des colonnes privées ou protégées…

3.1) Afficher les valeurs d'attributs prises dans une liste de choix Pour manipuler facilement chaque table et spécialement les tables qui contiennent des valeurs prises dans des listes de choix, il est préférable de construire une requête pour cette classe. Par exemple, si la classe Personnes porte l’attribut Type de personne ENSG alors la table ClaPersonnes est en relation avec la table Type_Personnes_ENSG grâce à l'attribut id_type_personne_ensg ; dans ce cas la requête devra relier ces deux tables reprendre tous les champs de chacune des deux tables. Cette vue peut porter le nom de la classe, par exemple Personne, parce qu’elle " présente " vraiment les objets de la classe Personnes…

Figure  : Vue Personne (requête sélection traduction de l'hyperclasse Personnes)

Figure  : Vue Personne (enregistrement 1/17…)

Figure  : Vue Personne (enregistrement 1/17 suite et fin)

3.2) Masquer des attributs Cette vue construite, on peut l'utiliser avantageusement pour créer la vue sur la table ClaFormateurs. Si on veut gérer des accès restreints à certaines colonnes, il suffit de les exclure de la vue. On trouvera ci-dessous l'exemple de la vue (requête) Formateur dans laquelle on a volontairement omis l'attribut somme_vacations…

Figure  : Vue Formateur "partielle"
(requête sélection traduction de la classe Formateurs sans l'attribut somme_vacations)

Figure  : Vue Formateur "partielle" (enregistrement 1/9…)

Figure  : Vue Formateur "partielle" (enregistrement 1/9 suite…)

Figure  : Vue Formateur "partielle" (enregistrement 1/9 suite et fin)

3.3) Créer une vue sur un lien De même pour manipuler le lien Anime entre les classes Formateurs et Séances, il est préférable de créer une requête reliant les vues Formateur et Séance et la table LienAnime représentant le lien. On a toujours intérêt à garder dans un premier temps tous les champs des deux vues et de la table du lien. Cette vue peut porter le nom du lien sous la forme relationAnime, parce qu’elle " présente " les relations entre les objets des deux classes.

Figure  : Vue relationAnime
(requête sélection traduction du lien "Formateurs anime Séances")

Figure  : Vue relationAnime (enregistrement 1/16…)

Figure  : Vue relationAnime (enregistrement 1/16 suite et fin)