Copyright © 2021 Yves MARCOUX; dernière modification : 2021-09-24.

Passer d’un SGBD textuel à un SGBD relationnel

Yves MARCOUX - EBSI - Université de Montréal

Préalables à ce texte


Table des matières

Mise en situation

Microsoft Access – l’interface de base

Démarrage

Créer une nouvelle BD

Ouvrir une BD existante

Fermer une BD ouverte et quitter Access

Le volet de navigation

Les tables

Modes de consultation d’une table

Mode Feuille de données

Ajout d’une fiche

Modification d’une fiche

Suppression d’une fiche

Autres opérations

Mode Création

Partie supérieure d’un onglet de table en mode Création

Partie inférieure d’un onglet de table en mode Création

Les champs sans occurrences multiples

NO

Clé primaire

Un nouveau champ : TYPE

Validation et aide à la saisie

Taille du champ

Masque de saisie

Valide si

Champs obligatoires

La touche finale

TITR

TITP

TOED

DATP

L’opérateur Comme

COLC

EDIT

COLL

LANG

Valeur par défaut

RESU

Type Texte long

COTE

Champs à valeurs uniques

Les index en relationnel

DACR

Type Date/Heure

Les listes de choix

Listes fermées

Listes d’autorité modifiables

Création de la requête

Paramétrage de la liste de choix

Exercice

Exercice de saisie

Champs à occurrences multiples

Justification

Réalisation

Clés externes

Création de la table AUTRocc

Configurer la liste d’autorité modifiable

Création de la clé externe

Exercice

Validation du nombre d’occurrences

Sous-feuilles de données

Définir une sous-feuille de données

Saisie dans une sous-feuille de données

Limite des sous-feuilles de données

Exercice de saisie


Mise en situation

Comme premier contact avec les BD relationnelles, nous allons faire l’exercice de concevoir et de développer une BD relationnelle qui répond aux mêmes besoins de gestion d’information que la BD INFORM avec laquelle vous avez eu l’occasion de travailler précédemment.

Pour marquer clairement la différence entre INFORM, une BD textuelle développée avec DB/TextWorks, et la BD relationnelle que nous apprêtons à développer, nous appellerons cette dernière INFORM-R (R pour relationnelle).

Comme vous savez, même si les deux types de BD sont basés sur la structure de table de données, une différence importante réside dans le fait que qu’une BD textuelle peut avoir des champs à occurrences multiples (aussi appelés répétables), alors qu’une BD relationnelle ne le peut pas. Il faut donc s’attendre à ce qu’une grande part de notre travail consiste à faire sans les occurrences multiples que l’on faisait avec les occurrences multiples dans INFORM. Pour cela, nous allons nous appuyer sur une capacité des SGBD relationnels que n’ont pas les textuels : la possibilité d’avoir plusieurs tables dans la même BD.

Essentiellement, les champs qui, dans INFORM, étaient sans occurrences multiples seront stockés dans une seule table d’INFORM-R, alors que chaque champ qui, dans INFORM, permettait les occurrences multiples fera l’objet de sa propre table (dont nous reviendrons en détail sur la structure plus loin). Il y aura donc dans INFORM-R (n+1) tables, où n est le nombre de champs à occurrences multiples dans INFORM.

Les champs à occurrences multiples dans INFORM sont (rappelons que cette information se trouve dans le dictionnaire de données) :

Il y aura donc (2+1) = 3 tables dans INFORM-R.

Avant de nous attaquer à ces champs, cependant, nous nous pencherons sur les autres champs de la BD, exercice qui nous permettra d’introduire d’autres différences entre les BD textuelles et relationnelles, de même que certaines particularités du SGBD relationnel que nous utiliserons : Access, de Microsoft.

D’ailleurs, nous commencerons par nous familiariser avec l’interface de base d’Access.

Suggestion

Pour que la lecture ne demeure pas un exercice théorique, vous êtes invité à effectuer dans Access les manipulations visant à créer la BD INFORM-R, au fur et à mesure qu’elles sont décrites dans le texte. Vous vous retrouverez ainsi en fin de parcours avec une BD fonctionnelle constituant une bonne base pour explorer les possibilités des bases de données relationnelles.

Faites des sauvegardes régulières (Ctrl-S) tout au long de la définition de la BD !


Microsoft Access – l’interface de base

Démarrage

Pour démarrer Access, référez-vous aux instructions données en classe ou dans le matériel distribué.

Au lancement du logiciel, nous obtenons un panneau d’accueil dont la section en haut à gauche ressemble à ceci :

de-textuel-a-relationnel1.png

Créer une nouvelle BD

Pour créer une nouvelle BD, il suffit de cliquer sur la case « Base de données vide ».Vous êtes alors appelé à choisir un nom de fichier et un emplacement pour la nouvelle BD :

de-textuel-a-relationnel2.png

Comme « Nom de fichier », inscrivez le nom que vous avec choisi pour votre BD. Par exemple, pour nommer votre BD INFORM-R, vous inscrivez simplement INFORM-R. Il n’est pas nécessaire d’inscrire l’extension .accdb, qui est ajoutée automatiquement si on l’omet. Choisissez également l’emplacement souhaité pour votre BD, en cliquant sur l’icône du dossier à droite du nom.

Cliquez ensuite sur « Créer ». Un fichier portant le nom de votre BD et l’extension .accdb est créé par Access à l’emplacement spécifié. Une BD Access est constituée d’un seul fichier, Access ne crée donc aucun autre fichier que celui portant l’extension .accdb. Ainsi, lorsque vous voudrez prendre une copie de sécurité de votre BD, l’envoyer à quelqu’un ou la déposer quelque part sur un réseau, vous n’aurez que ce seul fichier à sauvegarder, envoyer ou déposer.

Ouvrir une BD existante

Pour ouvrir une BD existante, il suffit de cliquer sur la BD voulue dans la liste des items sous « Récent », ou encore de cliquer sur « Ouvrir » dans la colonne de gauche puis de localiser la BD à ouvrir.

Bon à savoir

Dès qu’on ouvre une BD Access et qu’on la referme, la date de dernière modification du fichier .accdb est modifiée, même si on n’a absolument rien changé dans la BD.

Quand on ouvre un BD existante, il se peut que l’on obtienne le message suivant :

de-textuel-a-relationnel-2-1.png

Dans le contexte de ce cours, vous pouvez toujours cliquer sans inquiétude sur le bouton « Activer le contenu ». En dehors du cours, vous devriez d’abord vérifier avec la personne qui a créé la BD si vous pouvez activer le contenu actif en toute sécurité.

Deux BD en même temps ?

Contrairement aux autres applications de la suite Microsoft Office, il n’est pas possible comme tel de travailler sur deux BD en même temps dans Access. Si vous faites Fichier → Ouvrir pour ouvrir une BD alors qu’une autre BD est déjà ouverte, cette dernière est d’abord fermée avant que la nouvelle ne soit ouverte.

Cependant, il est possible de démarrer plusieurs copies d’Access en même temps et chacune d’elles peut travailler sur sa propre BD. Ces copies multiples d’Access apparaissent dans la barre des tâches comme autant d’applications distinctes.

De cette façon, il est possible de travailler sur plusieurs BD simultanément, même si ce n’est pas dans la même copie active d’Access. Les opérations de copier-coller sont possibles entre les différentes copies actives d’Access.

Fermer une BD ouverte et quitter Access

Pour fermer la BD ouverte, il suffit de faire Fichier → Fermer. On peut alors ouvrir une autre BD ou en créer une nouvelle via l’item Fichier du menu principal, qui nous amène au panneau d’accueil décrit précédemment. On peut aussi quitter Access, en cliquant sur le x dans le haut à droite de sa fenêtre.

Si on quitte Access alors qu’une BD est ouverte, celle-ci est automatiquement fermée.

Le volet de navigation

Que vous ayez créé une nouvelle BD ou que vous ayez ouvert une BD existante, vous vous retrouvez dans une interface dont la partie de gauche est occupée par le « Volet de navigation ». Ce volet de navigation peut être développé (ouvert) :

de-textuel-a-relationnel3.png

ou fermé :

de-textuel-a-relationnel4.png

Lorsqu’il est ouvert, il peut être redimensionné en déplaçant la ligne verticale qui le délimite à droite.

Les tables

Le volet de navigation donne accès aux différents objets qui composent une BD du point de vue d’Access. Les tables de données (qu’Access appelle simplement tables) que contient la BD sont un des types d’objet que l’on peut y retrouver, mais comme nous verrons plus tard, il peut y avoir d’autres types d’objet, notamment des requêtes et des formulaires.

Tout juste après avoir créé votre BD INFORM-R vide, l’affichage a l’air de ceci :

de-textuel-a-relationnel6.png

Comme on peut voir, le volet de navigation ne contient qu’une section intitulée « Tables », où on trouve la table « Table1 ». Si la BD contenait des requêtes et/ou des formulaires, le volet de navigation contiendrait aussi des sections « Requêtes » et/ou « Formulaires ».

La table « Table1 » n’existe pas encore vraiment, mais comme on ne peut rien faire dans une BD tant qu’elle ne contient pas au moins une table, Access prend l’initiative de mettre en branle la création d’une table. Pour que la table soit vraiment créée, il faut choisir le Mode Création dans le menu « Affichage » qui se retrouve dans le bandeau :

de-textuel-a-relationnel-8.png

Access nous demande alors quel nom donner à la table :

de-textuel-a-relationnel-9.png

à quoi on répond par le nom voulu, par exemple « documents » :

de-textuel-a-relationnel-9-1.png

et ce n’est qu’au moment où on clique OK dans ce dialogue que la table est réellement créée dans la BD. Notez qu’il s’agit d’une sauvegarde « interne » à la BD; peu importe les objets qu’elle contient, une BD occupe toujours un seul fichier : celui portant l’extension .accdb, créé au moment de la création de la BD.

Si on ferme l’onglet de la table, ou la BD elle-même, avant d’avoir complété avec succès le dialogue « Enregistrer sous », la table n’est pas créée.

Créer d’autres tables

Pour la première table d’une BD, c’est Access qui prend l’initiative d’en entamer la création. Si la BD doit comporter plusieurs tables (ce qui est souvent le cas avec une BD relationnelle), on démarre la création d’une nouvelle table en choisissant Créer dans le menu principal, puis en cliquant sur Table dans le ruban. Cela crée un nouvel onglet « Table1 » et, de là, on procède comme pour la première table.

Modes de consultation d’une table

Les tables d’une BD sont l’endroit où sont stockées les informations contenues dans la BD. Rappelons qu’une table de données est structurée en champs (les colonnes) et en fiches, ou enregistrements (les lignes).

Access offre deux modes de consultation d’une table : le mode Feuille de données et le mode Création. Le mode Feuille de données permet de visualiser les informations contenues dans la table, de les modifier et d’ajouter ou supprimer des fiches.

On peut passer d’un mode à l’autre de plusieurs façons différentes. L’une des plus simples est de cliquer sur l’un des deux boutons :

de-textuel-a-relationnel-18.png

visibles dans le bas à droite de l’écran lorsque l’onglet d’une table est actif. La règle et le triangle mènent au mode Création; la grille mène au mode Feuille de données. On peut aussi, comme précédemment, utiliser le menu « Affichage » dans le bandeau pour passer d’un mode à l’autre, mais le bandeau actif ne contient pas toujours cet item.

Le mode Création permet de visualiser et modifier la structure même de la table, à savoir, les champs qui la composent et les différents paramètres qui caractérisent chaque champ, par exemple son type (texte, numérique, date, etc.) et les validations qui s’y appliquent (masque de saisie, valeurs maximum et minimum, etc.).

Quand on vient tout juste de créer une nouvelle table, elle ne contient qu’un seul champ (appelé « N° »), créé automatiquement par Access, et ne contient aucune fiche. Une table qui ne contient aucune fiche est dite vide, même si elle comporte un ou plusieurs champs. Peu importe le nombre de champs, si elle ne contient aucune fiche, elle ne contient forcément aucune donnée et mérite donc le qualificatif « vide ».

Quand on vient tout juste de créer une nouvelle table, avant de commencer à y inscrire des données, la première chose à faire est de définir les champs qu’elle doit comporter et leurs caractéristiques. Ces opérations s’effectuent dans le mode Création. Nous reviendrons en détail à ce mode plus tard, lorsque nous créerons les tables d’INFORM-R. Pour le moment, regardons un peu le mode Feuille de données.

Mode Feuille de données

Si vous voulez expérimenter avec les opérations décrites ci-après, vous pouvez télécharger ici une BD contenant la table qui sert d’exemple.

Voici un exemple de table en mode Feuille de données :

de-textuel-a-relationnel-9-3.png

La table s’appelle « exemple ». Les champs de cette table sont « numéro_de_contact », « nom » et « numéro_de_téléphone ». En ce moment, la table contient trois fiches. L’entête Cliquer pour ajouter n’est pas un nom de champ, mais une zone cliquable permettant l’ajout rapide d’un nouveau champs dans la table. Son utilisation est cependant déconseillée, au profit du mode Création, que nous verrons plus tard.

Ajout d’une fiche

On peut ajouter une nouvelle fiche en positionnant notre curseur successivement sur les différents champs de la ligne marquée d’un astérisque (*) :

de-textuel-a-relationnel-9-4.png

On remarque que l’astérisque s’est déplacée sur une nouvelle ligne et qu’elle a été remplacée par un crayon sur la ligne de la fiche en création. Tant que le crayon est visible, il est possible d’abandonner la création de la nouvelle fiche en appuyant sur ESC (Échapp.), une ou plusieurs fois, jusqu’à ce que les nouvelles données disparaissent et que le crayon redevienne un astérisque.

Dès que l’on déplace le curseur en dehors de la fiche en création, celle-ci est automatiquement sauvegardée dans la table de données, et donc dans la BD :

de-textuel-a-relationnel-9-5.png

Aucune opération explicite de sauvegarde n’est nécessaire pour que les données soient enregistrées. Si on fermait puis rouvrait la BD maintenant, nous retrouverions la nouvelle fiche bien en place dans la table « exemple ».

Modification d’une fiche

Pour modifier une donnée déjà dans la table, il suffit de cliquer sur la case correspondante. Par exemple, si nous réalisons que nous avons fait une erreur dans le prénom de madame Lajoie, nous n’avons qu’à cliquer dans la case en question et remplacer « Julie » par « Anne » :

de-textuel-a-relationnel-10.png

Encore ici, tant que le crayon est visible, il est possible d’abandonner la modification de la fiche en appuyant sur ESC (Échapp.), une ou plusieurs fois, jusqu’à ce que le crayon disparaisse et que les données redeviennent comme avant.

Dès que l’on déplace le curseur en dehors de la fiche en modification, les nouvelles données sont automatiquement sauvegardées dans la table de données, et donc dans la BD :

de-textuel-a-relationnel-11.png

Suppression d’une fiche

Pour supprimer une fiche, il faut la sélectionner en cliquant sur le zone carrée située à sa gauche :

de-textuel-a-relationnel-12.png

puis d’appuyer sur Del (Suppr.). Access demandera de confirmer la suppression :

de-textuel-a-relationnel-13.png

Si la suppression est confirmée, la ligne en question est immédiatement retirée de la table, et donc de la BD, de manière permanente, et n’est donc plus visible :

de-textuel-a-relationnel-14.png

Autres opérations

D’autres opérations affectant l’affichage des données sont aussi possibles en mode Feuille de données, par exemple le tri et le filtrage selon certains critères. Nous reviendrons en détail sur ces opérations plus tard. Nous nous contenterons pour le moment d’un exemple : le tri par nom.

Pour trier les fiches par ordre croissant du champ « nom », il faut cliquer sur le petit triangle à la droite du nom du champ. Le menu des tris et filtres apparaîtra :

de-textuel-a-relationnel-15.png

Il suffit alors de sélectionner l’item « Trier de A à Z » dans ce menu. Les fiches apparaîtront alors triées par ordre alphabétique de nom :

de-textuel-a-relationnel-16.png

Une chose à retenir sur le tri et le filtrage est que leur effet n’est par défaut pas permanent. Si on ferme une table alors qu’un tri et/ou un filtre sont appliqués, Access demande si on veut conserver ces réglages ou non :

de-textuel-a-relationnel-17.png

Si l’on répond non, les tris et filtres courants sont simplement oubliés. Si l’on répond oui, le tri sera appliqué à chaque ouverture de la table et le filtre pourra être réactivé sur demande.

Mode Création

Nous explorerons le mode Création d’une table en procédant à la création de la table principale d’INFORM-R, celle comportant tous les champs sans occurrences multiples d’INFORM.

Dans une BD vide, créons une première table et donnons-lui le nom « documents ». Vous pouvez revoir les instructions ci-dessus au besoin pour effectuer ces opérations qui, une fois complétées, résultent en l’affichage suivant :

de-textuel-a-relationnel-19.png

où l’onglet de la table « documents » est ouvert en mode Création.

Partie supérieure d’un onglet de table en mode Création

Juste sous le nom de l’onglet lui-même (qui est en fait le nom de la table), on retrouve trois informations sur chaque champ de la table, à raison d’un champ par ligne. Pour chaque champ, on peut voir son nom, son type (Type de données), ainsi qu’une description, facultative. Tel qu’attendu, il n’y a initialement qu’un champ, appelé « N° », créé automatiquement par Access.

L’ajout, la modification et la suppression d’information concernant les champs dans cette section de l’onglet fonctionnent exactement comme en mode Feuille de données. Ainsi, pour modifier le nom ou la description d’un champ, on n’a qu’à positionner le curseur dans la case contenant l’ancien contenu et à le remplacer par le nouveau. Même chose pour le type du champ, à la différence que le choix du type se fait dans une liste déroulante, plutôt qu’en tapant au clavier le type désiré.

La description du champ est facultative, mais dans le contexte d’une transposition à partir d’une BD existante, un choix naturel est d’utiliser le nom développé du champ tel qu’on le retrouve dans le dictionnaire de données de la BD existante, et c’est ce que nous ferons.

Création et suppression de champ

Pour créer un nouveau champ, il suffit d’inscrire au minimum son nom et son type sur une ligne inoccupée. Pour en supprimer un, on le sélectionne en cliquant sur le carré à sa gauche, puis on appuie sur Del (Suppr.).

Réordonner les champs

Lorsqu’un champ est sélectionné, on peut aussi le déplacer verticalement relativement aux autres champs, par glisser-déposer avec la souris, ce qui permet de réordonner les champs. L’ordre des champs ici détermine l’ordre dans lequel ils sont présentés, de gauche à droite, lorsqu’on consulte la table en mode Feuille de données. On a donc intérêt à ordonner les champs dans l’ordre le plus « logique » possible.

Partie inférieure d’un onglet de table en mode Création

Quand le curseur se trouve sur un des champs dans la partie supérieure, la partie inférieure de l’onglet (non illustrée dans l’image ci-dessus) donne accès à une foule de paramètres additionnels (appelées aussi propriétés du champ) qui déterminent le comportement exact de ce champ à la saisie. La nature des paramètres applicables dépend du type de données du champ. Par exemple, pour un champ de type Texte court, un des paramètres est la longueur maximum de l’information que l’on peut inscrire dans le champ.

Puisque les paramètres sont nombreux, ils sont regroupés en deux onglets appelés « Général » de « Liste de choix ».

Le nombre de paramètres possibles est très grand et nous n’en explorerons que quelques-uns. Nous les introduirons au fur et à mesure que nous en aurons besoin dans notre travail de transposition d’INFORM vers le modèle relationnel.


Les champs sans occurrences multiples

Tel qu’expliqué dans la Mise en situation, la table « documents », que nous venons de créer, contiendra les champs qui, dans INFORM, étaient sans occurrences multiples. Dans l’ordre où ils sont présentés dans le tableau des champs du dictionnaire de données d’INFORM, les champs sans occurrences multiples sont :

NO, TITR, TITP, TOED, DATP, COLC, EDIT, COLL, LANG, RESU, COTE, DACR

Pour chacun d’eux, il suffit en principe de définir un champ de même nom dans la table « documents » et de paramétrer ce champ de la « même façon » que le champ correspondant dans INFORM. La difficulté vient du fait que le paramétrage d’un champ ne se fait pas exactement de la même façon dans Access et dans DB/TextWorks.

Il faut donc choisir le paramétrage du champ de façon à reproduire le mieux possible le paramétrage qu’il avait dans DB/TextWorks, tout en essayant de tirer parti le plus possible de certaines possibilités propres à Access qui n’existent pas dans DB/TextWorks. Comme nous verrons, Access permettra dans certains cas un meilleur contrôle de l’information que DB/TextWorks alors que dans d’autres cas, ce sera le contraire.

Pour le moment, nous travaillons exclusivement avec les paramètres accessibles dans la partie supérieure de l’onglet de la table et dans l’onglet « Général » de la partie inférieure. Plus loin, nous ferons un « deuxième tour » qui nous permettra de paramétrer plus avant certains des champs, en travaillant à l’onglet « Liste de choix » de la partie inférieure.

NO

Il est très fréquent que les items d’une collection soient identifiées par un numéro séquentiel. D’ailleurs, le champ qu’Access crée par défaut dans une nouvelle table s’appelle justement « N° » et il est de type « NuméroAuto ». Ce type de données est un peu spécial, en ce sens qu’il ne détermine pas comment les données sont validées, mais en fait comment elles sont générées. C’est Access qui, automatiquement, chaque fois qu’une nouvelle fiche est ajoutée dans la table, va inscrire un numéro séquentiel dans ce champ.

Access garde une trace d’où il en est rendu dans les numéros séquentiels et il n’attribuera jamais deux fois le même numéro. Une fois qu’un numéro est utilisé, il ne sera jamais attribué de nouveau, même si la fiche portant ce numéro est détruite. Les numéros sont donc attribués de façon séquentielle, mais il peut y avoir des trous; par contre, il est impossible que deux fiches portent le même numéro. De ce fait, un champ « NuméroAuto » est idéal pour servir d’identifiant des fiches.

Clé primaire

Dans le modèle relationnel, le champ qui sert d’identifiant des fiches d’une table s’appelle la clé primaire de cette table. Quand Access crée automatiquement le champ « N° », il le définit comme clé primaire de la table, ce qui est indiqué par une icône de clé dans le carré à gauche du champ :

de-textuel-a-relationnel-20.png

Un nouveau champ : TYPE

Les numéros automatiques dans INFORM commençaient par une lettre indiquant le type bibliographique du document (Monographie ou Article) : « M » ou « A », suivie de 5 chiffres. Les numéros séquentiels étaient attribués séparément pour chaque type bibliographique (donc, il peut y avoir deux documents portant le numéro séquentiel "00012", mais si on ajoute la lettre, la combinaison est unique et peut donc servir d’identifiant). Cela n’est pas possible dans Access. Les numéros automatiques attribués par Access sont purement numériques et ils sont attribués globalement pour tous les documents, et non par type bibliographique.

Pour profiter de la numérotation automatique d’Access, la meilleure approche est de scinder en deux champs distincts la lettre indiquant le type bibliographique du document (M ou A) et le numéro séquentiel. Les numéros séquentiels sont uniques à travers tous les documents plutôt qu’à l’intérieur d’un type bibliographique, mais demeurent parfaitement adéquats comme identifiants des documents.

Par programmation, il serait possible (et même pas très compliqué) de reproduire exactement le comportement de DB/TextWorks pour la génération automatique des identifiants. Ce serait cependant, à notre avis, un cas de « surarmement » (overkill), puisque la solution que nous proposons est parfaitement adéquate et beaucoup plus simple.

Nous ajoutons donc un nouveau champ (nouveau comparativement à INFORM), que nous appelons « TYPE », obligatoire, dont le contenu sera la lettre identifiant le type bibliographique du document : M ou A. Comme type de données, nous attribuons le type « Texte court », qui correspond à un simple contenu textuel. Nous inscrivons aussi une description adéquate :

de-textuel-a-relationnel-21-1.png

En parcourant la liste déroulante des types de données, vous pouvez voir qu’Access propose un très grand nombre de types différents, dont nous n’explorons dans le cours qu’une petite partie. Il faut retenir que de nombreux types existent pouvant convenir à des genres spécifiques d’informations, par exemple, des montants d’argent.

Regardons maintenant la partie inférieure de l’onglet « documents » lorsque le champ TYPE est sélectionné dans la partie supérieure. Rappelons que cette partie permet de contrôler le comportement exact du champ à la saisie. Access la présente initialement comme suit :

de-textuel-a-relationnel-21-2.png

Validation et aide à la saisie

Pour tirer parti des possibilités de validation et d’aide à la saisie d’Access, nous allons modifier certains paramètres de la partie inférieure :

de-textuel-a-relationnel-21-3.png

Taille du champ

La Taille du champ est la longueur maximum (nombre de caractères) que l’on peut saisir dans le champ. Nous la réglons à 1, puisque le contenu du champ est toujours d’exactement un caractère.

Masque de saisie

Le Masque de saisie spécifié (>L) permet de transformer automatiquement en majuscules les lettres saisies dans le champ (>) et de n’accepter comme contenu qu’exactement une lettre (L).

Les différents caractères que l’on peut retrouver dans un masque de saisie peuvent être consultés ici.

Valide si

Le paramètre Valide si permet de spécifier une expression qui doit être satisfaite par les données saisies pour qu’elles soient considérées valides. Ici, l’expression ="M" Ou ="A" exige que le caractère saisi soit égal soit à M, soit à A. Les guillemets sont nécessaires. Indépendamment du paramètre « Valide si », les contraintes liées au Type de données du champ doivent bien sûr aussi être satisfaites.

Le Message si erreur est le message d’erreur qui sera présenté à l’utilisateur si, à la saisie, il inscrit dans le champ des données qui ne satisfont pas l’expression « Valide si ».

Le langage dans lequel l’expression « Valide si » doit être rédigée est très riche; nous ne verrons dans le cours que quelques exemples. Des exemples de règles Valide si peuvent être consultés ici. Le langage complet est présenté ici.

Champs obligatoires

Pour rendre le champ obligatoire, nous réglons Null interdit à Oui et Chaîne vide autorisée à Non. Avec ces réglages, toute nouvelle fiche sera refusée si on n’inscrit rien dans le champ TYPE.

Incidemment, un champ qui sert de clé primaire est automatiquement obligatoire dans Access; c’est la raison pour laquelle nous n’avons eu aucun paramétrage particulier à faire pour le champ « N° ».

La touche finale

Pour compléter notre transposition du champ NO d’INFORM, nous inscrivons une description appropriée pour le champ « N° ».

Nous pourrions nous arrêter là, mais nous pouvons nous approcher encore plus de la structure originelle d’INFORM en renommant le champ « N° » à « NO » et en déplaçant le champ TYPE au-dessus de NO :

de-textuel-a-relationnel-22.png

TITR

Le champ TITR ne pose pas de grands défis. Il est obligatoire pour les deux types bibliographiques, donc on peut le rendre obligatoire au niveau d’Access. Il s’agit d’un simple champ textuel, pour lequel il suffit de fixer une longueur maximum.

Dans Access, la longueur maximum d’un champ de type Texte court peut être fixée à entre 1 et 255 caractères. Pour un champ dont le contenu peut excéder 255 caractères, il faut utiliser le type Texte long (c’est ce que nous ferons pour le résumé). À moins que le contenu ait une forme très particulière (comme c’était le cas pour TYPE), on peut en général laisser la limite à la valeur proposée de 255. Fixer une limite plus petite n’amène pas une économie d’espace de stockage, puisque l’espace effectivement utilisé pour ce champ dans une fiche est la longueur de l’information réellement inscrite dans le champ.

Nous acceptons donc la longueur maximum proposée de 255 :

de-textuel-a-relationnel-23.png

TITP

Le champ TITP est très similaire à TITR, mais on ne peut pas le rendre obligatoire au niveau d’Access, puisque, bien qu’il soit obligatoire pour les articles, il ne l’est pas pour les monographies (en fait, il est interdit pour les monographies).

Nous le définissons donc de façon très analogue à TITR, les seules différences étant les réglages « Null interdit » et « Chaîne vide autorisée », que nous laissons cette fois-ci tels que proposés initialement par Access, et qui font que le champ est facultatif :

de-textuel-a-relationnel-24.png

TOED

Le champ TOED est facultatif pour les monographies et interdit pour les articles.

Au niveau d’Access, on ne peut évidemment pas rendre le champ obligatoire, puisqu’il doit demeurer vide pour les articles. Il n’y a donc que le nom du champ, son type et sa description à remplir. Comme pour TITP, le paramétrage par défaut proposé par Access dans la partie inférieure n’a pas besoin d’être modifié :

de-textuel-a-relationnel-25.png

DATP

Le champ DATP est un peu particulier : on pourrait penser que le type de données « Date » serait le choix approprié. Cependant, la particularité est qu’on doit accepter deux formes différentes de date : AAAA et AAAA-MM. Or, un champ de type Date ne peut accepter que des dates ayant toutes la même forme. Nous allons donc le définir comme un champ de type texte, mais avec une règle de validation qui permet d’accepter les deux formats.

Nous utilisons donc le paramétrage suivant :

de-textuel-a-relationnel-26.png

La taille du champ est réglée à 7, la longueur de la forme la plus longue (AAAA-MM).

Comme il s’agit d’un champ obligatoire, Null interdit et Chaîne vide autorisée sont réglés en conséquence.

L’opérateur Comme

La validation (Valide si) est réalisée avec l’opérateur Comme, qui permet de s’assurer que les données saisies sont conformes à un certain patron, sans être aussi strict que l’opérateur d’égalité = que nous avons utilisé pour le TYPE. Avec l’opérateur Comme, le dièse (#) est un caractère générique qui représente un chiffre. Le tiret - doit être saisi comme tel.

La forme des patrons que l’on peut vérifier avec Comme est décrite ici.

Il est important de réaliser que la validation de DATP est imparfaite à deux égards. D’une part, avec la forme AAAA-MM, une valeur de MM égale à 0 ou supérieure à 12 serait acceptée. D’autre part, la forme AAAA serait acceptée même pour un article, et celle AAAA-MM le serait même pour une monographie (c’était déjà le cas dans DB/TextWorks avec INFORM).

Dans le monde des bases de données, la philosophie qui prévaut concernant la validation est « Mieux vaut une validation imparfaite que pas de validation du tout ». Il faut exploiter à leur maximum les possibilités de validation des outils utilisés, mais il faut aussi réaliser qu’ils ont leur limites et accepter de vivre avec une certaine probabilité d’erreur dans les données.

COLC

Le champ COLC est parfaitement analogue à TOED : facultatif pour les monographies et interdit pour les articles. Nous le définissons donc de façon identique :

de-textuel-a-relationnel-27.png

EDIT

Le champ EDIT est parfaitement analogue à TITP, dans le sens qu’il est obligatoire pour un type bibliographique et interdit pour l’autre. La différence avec TITP est qu’il est obligatoire pour les monographies plutôt que pour les articles. Du point de vue d’Access, cette différence ne change rien : le champ doit être défini comme facultatif. Nous le donc (comme TOED et COLC) de façon identique à TITP :

de-textuel-a-relationnel-27b.png

COLL

Le champ COLL est parfaitement analogue à TITR : obligatoire pour les deux types bibliographiques, pouvant donc être rendu obligatoire au niveau d’Access. Nous le définissons donc de façon identique à TITR :

de-textuel-a-relationnel-28.png

LANG

Le champ LANG est très similaire au champ TYPE, en ce sens qu’il est obligatoire pour les deux types bibliographiques et qu’il n’a qu’un petit nombre de valeurs possibles, en fait trois : FR, ANG et ESP. Nous allons donc le définir de façon très similaire.

Valeur par défaut

Cependant, nous allons utiliser une possibilité que nous n’avons pas exploitée jusqu’ici, celle de spécifier une valeur par défaut pour le champ. On peut imaginer que la plupart des documents seront dans une langue prédominante dans la collection, et nous supposons ici que cette langue est le français. Le fait de définir FR comme valeur par défaut fait en sorte qu’au moment de la saisie, au lieu d’être présenté vide à l’utilisateur, le champ sera pré-rempli avec la valeur FR. Si cette valeur est la bonne, l’utilisateur peut simplement passer au champ suivant. En revanche, si la valeur par défaut n’est pas applicable, il n’a qu’à modifier le contenu du champ.

Voici le paramétrage complet :

de-textuel-a-relationnel-29.png

La taille du champ est bien sûr la longueur de la valeur acceptée la plus longue (ANG et ESP).

Le ? dans le masque de saisie indique que la saisie d’une troisième lettre est facultative.

Notons en rétrospective qu’il aurait aussi été possible de définir une valeur par défaut pour le champ TYPE. Nous avons choisi de ne pas le faire pour nous assurer que l’utilisateur posait un geste explicite en remplissant le champ, plutôt que de simplement accepter une valeur déjà présente. Ne pas définir de valeur par défaut peut donc être une façon, pour la conceptrice d’une BD, de s’assurer que l’utilisateur porte vraiment attention à l’information qu’il saisit dans un champ.

RESU

Type Texte long

La particularité du champ RESU est d’être un champ textuel dont la longueur peut dépasser 255 caractères. Il faut donc utiliser le type « Texte long ». Comme le champ est facultatif, les paramétrages proposés initialement par Access dans la partie inférieure sont adéquats :

de-textuel-a-relationnel-30.png

La valeur « Texte brut » du paramètre Format du texte convient à nos besoins. Le contenu du champ sera du texte sans attributs de présentation (gras, italique, etc.). Si on avait voulu permettre du texte avec attributs de présentation, on aurait choisi la valeur « Texte enrichi ».

COTE

Champs à valeurs uniques

La particularité du champ COTE est qu’il s’agit d’un champ à valeurs uniques : les valeurs qui y sont inscrites doivent être différentes d’une fiche à l’autre. Pour définir un champ à valeurs uniques, il faut demander la création de ce qu’on appelle un index sans doublons :

de-textuel-a-relationnel-31.png

Avec ce paramétrage, toute nouvelle fiche que l’on voudrait ajouter dans la table sera refusée si elle contient dans le champ COTE une valeur qui se trouve déjà dans le champ COTE d’une des fiches existantes.

Les index en relationnel

Voilà une belle occasion de dire quelques mots à propos du rôle que jouent les index dans un SGBD relationnel et en particulier dans Access.

Alors que, dans DB/TextWorks, les index que l’on définissait sur chaque champ déterminaient les types de recherche qu’il était ensuite possible de faire sur la BD, dans un SGBD relationnel, la présence ou non d’index n’a aucun impact sur les recherches que l’on peut formuler. Le seul effet que peut avoir un index est d’augmenter la performance des recherches, donc leur vitesse d’exécution.

Il y deux types d’index : avec et sans doublons. Les index sans doublons, en plus d’éventuellement accélérer certaines recherches, ont la particularité de rendre à valeurs uniques les champs sur lesquels on les définit. Dans un contexte où la performance des requêtes est secondaire, la possibilité des index sans doublons – pour rendre un champ à valeurs uniques – devient la seule raison d’utiliser les index.

Notons que la clé primaire d’une table est automatiquement indexée sans doublons, ce qui garantit que deux fiches n’auront jamais le même identifiant.

DACR

Le champ DACR doit contenir la date de création de la fiche et on voudrait qu’il soit généré automatiquement par Access. Il s’avère que l’on peut facilement y arriver en utilisant le mécanisme des valeurs par défaut. Nous spécifierons donc une valeur par défaut pour le champ, cependant, ce ne sera pas une date fixe, mais plutôt une expression dont la valeur est la date courante.

Voici le paramétrage approprié du champ :

de-textuel-a-relationnel-32.png

Type Date/Heure

Comme le champ contiendra une date, nous choisissons le type Date/Heure. Le format de date désiré est déterminé par le paramètre Format de la partie inférieure. La forme AAAA-MM-JJ correspond au format « Date, abrégé ».

Le champ est obligatoire, nous choisissons donc Null interdit égal à Oui.

L’expression Maintenant(), donnée comme Valeur par défaut, est une expression dont la valeur donne la date courante. Le langage des expressions que l’on peut inscrire comme valeur par défaut est le même que celui des expressions Valide si.

À la saisie d’une date, Access propose par défaut à l’utilisateur de choisir une date dans un calendrier qu’on appelle un sélecteur de dates. Comme ici la date sera pré-inscrite dans le champ plutôt que saisie, un sélecteur de date est inutile. C’est la raison pour laquelle nous réglons le paramètre Afficher le sélecteur de dates à Jamais.


Les listes de choix

Listes fermées

Les champs TYPE et LANG ont la particularité d’avoir très peu de contenus différents possibles : TYPE n’a que deux contenus possibles (M et A), alors que LANG en a trois (FR, ANG et ESP). Dans ces cas, le paramétrage « Liste de choix » de la partie inférieure de l’onglet de la table permet que la saisie se fasse par un choix dans une liste déroulante plutôt qu’au clavier, ce qui est plus facile et minimise les chances d’erreur.

Voici le paramétrage approprié pour TYPE :

de-textuel-a-relationnel-34.png

Les contenus possibles sont inscrits entre guillemets et séparés par un point-virgule comme paramètre « Contenu » : "M";"A". Le paramétrage pour LANG est comme suit :

de-textuel-a-relationnel-35.png

Listes d’autorité modifiables

Le dictionnaire de données d’INFORM indique que le champ TITP doit être rempli conformément à la « Liste d’autorité des titres de périodiques ». Concrètement, cela veut dire qu’au moment de la saisie, on devrait pouvoir choisir parmi les titres de périodique déjà entrés dans la BD, et seulement si le titre que l’on veut ne s’y trouve pas, taper le nouveau titre directement au clavier. De cette façon, on évite que le même titre soit saisi sous une pluralité de formes avec des petites variantes, comme par exemple « Journal d’Économie Politique » et « Journal d’économie politique ». L’uniformité rigoureuse des intitulés est un facteur important de qualité dans l’information bibliographique.

Ce genre de liste, qui propose d’abord des choix déjà enregistrés, mais accepte qu’on ajoute de nouvelles entrées à cette liste de choix, est appelée liste d’autorité modifiable.

Nous allons utiliser l’onglet Liste de choix pour configurer le champ TITP de sorte qu’il soit doté d’une liste d’autorité modifiable à la saisie. Pour ce faire, nous aurons besoin d’une requête (notre première requête !), qui permet d’extraire de la table « documents » la liste des titres de périodique déjà entrés, sans répétition et triée par ordre alphabétique.

Création de la requête

Fermez d’abord l’onglet de la table « documents ». Faites ensuite Créer au menu principal puis cliquez sur « Création de requête » dans le bandeau qui s’ouvre. Vous obtiendrez un onglet de requête semblable à ceci :

de-textuel-a-relationnel-36.png

Cliquez sur Ajouter les tables sélectionnées au bas à droite de cet onglet; la table « documents » apparaîtra sous le nom de l’onglet « Requête1 » :

de-textuel-a-relationnel-37.png

Au sein de la table qui vient d’apparaître, double-cliquez sur le champ TITP; ce champ apparaîtra dans la partie inférieure gauche de l’onglet :

de-textuel-a-relationnel-38.png

Vis-à-vis « Critères », inscrivez Est Pas Null :

de-textuel-a-relationnel-39.png

Fermez maintenant la section « Ajouter des tables » dans la partie droite de l’onglet :

de-textuel-a-relationnel-40.png

Puis, au sein du bandeau « Conception de requête », cliquez sur Afficher/Masquer et sélectionnez Feuille de propriétés :

de-textuel-a-relationnel-41.png

Ensuite, cliquez n’importe où à droite de la table « documents », sous le nom de l’onglet « Requête1 » :

de-textuel-a-relationnel-42.png

Cela fera en sorte que le volet Feuille de propriétés affiche les propriétés de la requête en construction :

de-textuel-a-relationnel-43.png

Réglez la propriété « Valeurs distinctes » à Oui :

de-textuel-a-relationnel-44.png

La requête est maintenant complète. Pour la sauvegarder, fermez simplement l’onglet « Requête1 » :

de-textuel-a-relationnel-45.png

et acceptez l’invitation de sauvegarde, en spécifiant TITP-autorité comme nom de requête :

de-textuel-a-relationnel-46.png

de-textuel-a-relationnel-47.png

Paramétrage de la liste de choix

Retournons maintenant à la table « documents » en Mode création, puis sélectionnons le champ TITP et l’onglet « Liste de choix » dans la partie inférieure de l’onglet de table. Au sein de cet onglet, appliquons les réglages suivants :

de-textuel-a-relationnel-48.png

Et voilà, le champ TITP est maintenant doté d’une liste d’autorité modifiable, comme vous aurez l’occasion de l’expérimenter dans l’exercice suivant !

Exercice

Paramétrez la Liste de choix du champ EDIT pour que le champ soit doté d’une liste d’autorité modifiable correspondant à la « Liste d’autorité des lieux et maisons d’édition » mentionnée dans le dictionnaire de données d’INFORM. Il faudra au préalable créer une requête appelée EDIT-autorité.


Exercice de saisie

À ce stade-ci, même si nous n’avons pas encore réglé le cas des champs à occurrences multiples, il vaut la peine de prendre une pause du mode Création, de « changer de casquette » et de vous mettre dans la peau d’une personne qui fait de la saisie dans la BD que vous venez de créer.

Pour ce faire, passez en mode Feuille de données avec la table « documents » et amusez-vous à saisir différentes informations dans différents champs. Observez bien l’effet de chacun des paramètres que vous avez définis pour chacun des champs.

Facultatif

Pour plus de confort à la saisie qu’en mode Feuille de données, vous pouvez faire générer par Access un formulaire et faire vos tests de saisie avec ce formulaire. Ce sera un formulaire transitoire que vous pourrez détruire une fois l’exercice complété (vous serez amenés à créer des formulaires définitifs plus tard dans le cours).

Pour créer ce formulaire :

Suggestion de Travail Pratique

En saisissant de l’information dans différentes fiches et différents champs, plusieurs messages d’erreur différents peuvent être obtenus. Par exemple, si les données inscrites ne respectent pas une condition « Valide si », ou encore si on n’inscrit rien dans un champ obligatoire; mais il peut y avoir d’autres raisons.


Champs à occurrences multiples

Justification

Les occurrences multiples sont-elles vraiment nécessaires ? Avec DB/TextWorks, elles ne « coûtaient » pratiquement rien : une simple case à cocher suffisait à permettre les occurrences multiples dans un champ. Comme en relationnel elles exigent plus de travail, la question de leur utilité réelle se pose.

Réfléchissons avec un exemple, celui des auteurs d’un document. Le besoin est de pouvoir inscrire plusieurs auteurs dans la même fiche d’un document. Dans un champ « normal » (sans occurrences multiples), une façon de faire est d’inscrire tous les auteurs un après l’autre en les séparant par un délimiteur préétabli. Par exemple, on peut tout à fait inscrire trois auteurs dans un champ « normal » appelé AUTR, de cette façon :

AUTR :  Luc Roy, Léa Paul, Roger Dion              

En fait, sans occurrences multiples, c’est la meilleure chose que l’on peut faire. Cependant, cette approche comporte plusieurs désavantages.

Un premier désavantage est au niveau de la recherche. Par exemple, pour trouver les documents écrits par Léa Paul, on serait tenté de formuler un critère du genre :

AUTR = "Léa Paul"

Cependant, le contenu du champ n’est pas "Léa Paul", mais bien la chaîne "Luc Roy, Léa Paul, Roger Dion" au complet. Notre fiche ne serait donc pas repêchée, malgré que Léa Paul en est bel et bien une des auteurs. Il faudrait donc recourir à une requête plus complexe, utilisant par exemple la troncature, qui devrait être utilisée à gauche et à droite du nom.

Mais les désavantages de cette approche ne touchent pas que la recherche. La production de rapports, notamment d’index par auteur, pose également des défis. Finalement, comme le champ contient une suite de noms d’auteur plutôt qu’un seul, il est impossible de l’utiliser comme « liste d’autorité modifiable » pour aider à la saisie des noms d’auteur à la création d’une nouvelle fiche, comme nous l’avons fait ci-dessus pour les titres de périodiques. Bref, cette approche est loin d’être idéale.

Fondamentalement, le problème est que les noms sont « enfouis » à l’intérieur du champ, plutôt que bien délimités et séparés les uns des autres. Avec les occurrences multiples, les noms sont isolés les uns des autres, ce que l’on peut illustrer intuitivement comme ceci :

AUTR : Luc Roy
Léa Paul
Roger Dion

Avec les noms ainsi isolés, une requête comme AUTR = "Léa Paul" retournerait effectivement les fiches où Léa Paul n’est pas la seule auteure, les index par auteurs deviennent faciles à produire et le champ peut être utilisé comme « liste d’autorité modifiable » de noms d’auteur à la création d’une nouvelle fiche.

Réalisation

Clés externes

Pour réaliser l’équivalent d’un champ à occurrences multiples en relationnel, on va créer une nouvelle table, qui sera liée à la table principale de la BD par ce qu’on appelle une clé externe. Nous allons introduire le concept de clé externe par le biais d’un exemple : la transposition à INFORM-R du champ à occurrences multiples AUTR d’INFORM.

Pour stocker les noms d’auteur dans INFORM-R, nous allons créer une nouvelle table, appelée « AUTRocc ». Le nom précis n’a pas d’importance, mais on a intérêt à utiliser un nom en lien avec les informations que la table contiendra, ici des noms d’auteur. Le suffixe « occ » est simplement mnémotechnique, pour nous rappeler que la table correspond à des occurrences de nom d’auteur.

Cette table contiendra trois champs :

  1. Un champ contenant les noms d’auteur eux-mêmes. Nous l’appellerons AUTR (comme le champ analogue dans INFORM).
  2. Comme deux auteurs pourraient théoriquement porter exactement le même nom, le champ AUTR ne pourrait pas servir de clé primaire. Nous allons donc définir un champ de type NuméroAuto pour servir de clé primaire. Nous l’appelons NO.
  3. Le troisième champ sera une clé externe vers la table « documents ». C’est ce champ qui fera le lien entre une occurrence de nom d’auteur et un des documents dans la table « documents ». Nous l’appelons noDoc.

Le fait qu’un champ soit une clé externe fait en sorte que le contenu de ce champ « pointe » vers une fiche dans une autre table. Plus précisément, il identifie une fiche de l’autre table par sa clé primaire.

Le principe est mieux illustré graphiquement. Ainsi, supposons que les tables « documents » et « AUTRocc » soient comme suit :

de-textuel-a-relationnel-49.png

et que le champ noDoc est défini comme une clé externe vers « documents ». Alors, la valeur 10 dans la fiche 1 de AUTRocc « pointe » à la fiche 10 de « documents ». Cet auteur est donc un des auteurs du document dont la clé primaire (le champ NO) est 10 :

de-textuel-a-relationnel-50.png

La même valeur 10 se retrouve aussi dans les fiches 2 et 3 de AUTRocc; le document 10 a donc trois « occurrences » d’auteur liées à lui :

de-textuel-a-relationnel-51.png

Les documents 13 et 15, quant à eux, ont chacun une seul occurrence qui leur est rattachée :

de-textuel-a-relationnel-52.png

Une des caractéristiques des SGBD relationnels est d’être capables de parcourir les liens représentés par une clé externe de façon à réunir toutes les informations dans une même table. Ainsi, avec les tables ci-dessus, il est très simple de créer une requête qui « reconnecte » les auteurs aux autres informations sur les documents :

de-textuel-a-relationnel-53.png

Si on ajoute à cette requête le critère AUTR = "Léa Paul", on obtient effectivement les documents dont Léa Paul est auteure, qu’il y ait ou non d’autres auteurs, ce qui était un des objectifs des occurrences multiples.

Nous verrons plus tard dans le cours comment formuler de telles requêtes, appelées jointures.

Création de la table AUTRocc

En revoyant au besoin les instructions pour créer une table ou pour travailler en Mode création, créez une nouvelle table appelée AUTRocc, avec trois champs paramétrés comme suit :

de-textuel-a-relationnel-54.png

de-textuel-a-relationnel-55.png

de-textuel-a-relationnel-56.png

Configurer la liste d’autorité modifiable

En procédant comme nous avons fait ci-dessus pour le champ TITP, créez d’abord une requête, appelée AUTR-autorité, qui extrait de la table AUTRocc la liste des noms d’auteur déjà entrés, sans répétition et triée par ordre alphabétique. Les noms d’auteurs déjà entrés se trouvent dans le champ AUTR de la table AUTRocc.

Ensuite, de façon analogue à ce que nous avons fait pour le champ TITP, paramétrez la liste de choix du champ AUTR pour que la saisie s’effectue dans une Zone de liste déroulante liée à la requête AUTR-autorité.

Création de la clé externe

Pour créer la clé externe, assurez-vous d’abord que tous les onglets de table sont fermés; en particulier, que la table AUTRocc est sauvegardée.

Ensuite :

  1. Cliquez sur Outils de base de données au menu principal, puis cliquez sur Relations au sein du bandeau qui s’ouvre. L’onglet « Relations » et un nouveau bandeau apparaissent à l’écran.
  2. Dans ce nouveau bandeau, cliquez sur Ajouter des tables, puis ajoutez successivement les tables « documents » et « AUTRocc ». Vous obtiendrez cet affichage :

    de-textuel-a-relationnel-57.png

  3. Cliquez sur le champ noDoc dans AUTRocc et, par glisser-déposer, déposez-le sur le champ NO de documents :

    de-textuel-a-relationnel-57b.png

    La fenêtre suivante s’ouvrira :

    de-textuel-a-relationnel-58.png

  4. Faites les réglages suivants dans cette fenêtre, puis cliquez sur Type de jointure… :

    de-textuel-a-relationnel-59.png

  5. Au sein de la nouvelle fenêtre qui s’ouvre, choisissez l’option 2 :

    de-textuel-a-relationnel-60.png

  6. Cliquez OK pour fermer la fenêtre « Propriétés de la jointure ».
  7. Cliquez Créer pour fermer la fenêtre « Modifier les relations ». Une flèche s’est ajoutée dans l’onglet Relations :

    de-textuel-a-relationnel-61.png

    Le champ à côté du symbole de l’infini ∞ est la clé externe qui vient d’être créée.
  8. Enfin, fermez l’onglet « Relations » et confirmer la sauvegarde :

    de-textuel-a-relationnel-63.png

Exercice

La création et le paramétrage de la table et de la clé externe correspondant au champ à occurrences multiples DESC d’INFORM (les descripteurs) sont laissés en exercice. Vous devrez créer une table DESCocc, une requête DESC-autorité et une clé externe de DESCocc vers documents.

Au moment de créer la clé externe, il y aura trois tables à l’onglet Relations. Après la création de la clé externe, l’onglet se présentera ainsi :

de-textuel-a-relationnel-62.png

Il peut être nécessaire de déplacer et/ou redimensionner les tables pour obtenir un affichage aussi clair que celui ci-dessus. Cependant, l’apparence du dessin importe peu, ce qui compte est les paramétrages effectués pendant la création des clés externes.

Vous pouvez vérifier votre solution en comparant avec les différents paramètres des tables et requêtes de cette BD.

Validation du nombre d’occurrences

Dans DB/TextWorks, il était possible de rendre obligatoire un champ à occurrences multiples. Cela signifiait que le logiciel refusait la création d’une nouvelle fiche si elle ne contenait pas au moins une occurrence du champ.

En relationnel, dû à la façon dont sont réalisées les occurrences multiples, il n’y a aucune façon simple d’obliger la saisie d’au moins une occurrence. Cette validation est possible par programmation, mais pas par simple paramétrage des tables. C’est une limite qu’il faut simplement accepter avec un SGBD relationnel (à moins qu’on soit en mesure de l’implanter par programmation).

Notez que si les besoins auxquels répond la BD demandent que le champ soit « obligatoire » (c’est-à-dire qu’on en saisisse toujours au moins une occurrence), alors il faut inscrire cette contrainte au dictionnaire de données de la BD, même si elle ne peut pas être vérifiée par le SGBD. Elle y rejoindra certaines autres règles d’écriture, dont l’application est la responsabilité de la personne effectuant la saisie, mais qui ne peuvent pas être vérifiées automatiquement par le SGBD (par exemple, dans INFORM, les règles d’écriture pour le champ COLL sont de ce type).


Sous-feuilles de données

Il est possible d’entrer des données directement dans les tables AUTRocc et DESCocc, comme vous l’avez fait pour la table documents. Cependant, comme les documents sont identifiés par leur numéro (NO) dans ces tables, il n’est pas facile de savoir à quel document s’applique l’auteur ou le descripteur que l’on est en train de saisir.

Différents mécanismes plus ou moins complexes et/ou conviviaux sont disponibles pour faciliter la saisie d’informations dans les tables qui correspondent à des champs à occurrences multiples. Un des plus conviviaux est celui des formulaires de saisie, que nous avons effleuré ci-dessus, et sur lequel nous reviendrons plus tard dans le cours. Pour le moment, nous explorerons un autre de ces mécanismes, celui des sous-feuilles de données.

Avant d’en expliquer le fonctionnement, montrons tout de suite son effet avec un exemple. Supposons que les tables documents et AUTRocc ont les contenus suivants :

de-textuel-a-relationnel-49.png

et que le champ noDoc de AUTRocc a été défini comme clé externe vers documents. Il est alors possible de configurer la table AUTRocc comme sous-feuille de données de documents, de sorte que cette dernière se présente maintenant ainsi :

de-textuel-a-relationnel-64.png

Notez la présence d’un + encadré (⊞) au début de chaque ligne. Ce symbole est en fait une puce que l’on peut cliquer pour faire apparaître certaines lignes de la table AUTRocc (celle que l’on a définie comme sous-feuille de données). Les lignes qui apparaîtront sont seulement celles qui se rapportent au document dont on a cliqué la puce.

Par exemple, si on clique le ⊞ situé sur la ligne du document 10, les lignes de AUTRocc contenant la valeur 10 comme noDoc, et seulement ces lignes, seront intercalées sous le document lui-même :

de-textuel-a-relationnel-65.png

On peut ainsi voir les auteurs du document 10 (et seulement ceux-là) directement sous les autres informations du document, sans avoir à faire soi-même l’appariement de numéros de document.

Notons que la puce ⊞ s’est transformée en ⊟. Si on clique sur cette nouvelle puce, le document est « refermé » et on retrouve l’affichage originel :

de-textuel-a-relationnel-66.png

Définir une sous-feuille de données

Pour associer une sous-feuille de données à une table, il faut d’abord ouvrir celle-ci en Mode création, puis faire Conception de la table au menu principal et cliquer sur Feuille de propriétés dans le bandeau, ce qui affichera le volet « Feuille de propriétés » de la table. Voici par exemple la Feuille de propriétés de notre table documents :

de-textuel-a-relationnel-71.png

Pour lui associer la table AUTRocc comme sous-feuille de données, il suffit de choisir Table.AUTRocc sur la ligne « Sous-feuille de données nom » :

de-textuel-a-relationnel-72.png

Notez qu’Access remplit lui-même automatiquement les paramètres « Champs fils » et « Champs pères », qui correspondent à la clé externe reliant la sous-feuille de données à la table principale.

Pour sauvegarder l’association de sous-feuille de données, il faut fermer l’onglet de la table et confirmer la sauvegarde.

Saisie dans une sous-feuille de données

La beauté du mécanisme des sous-feuilles de données est qu’il ne sert pas qu’à afficher l’information, il peut aussi être utilisé pour en saisir. Par exemple, si l’on développe le document 13 :

de-textuel-a-relationnel-67.png

D’une part, on voit que Luc Roy est un des auteurs de ce document. D’autre part, on pourrait ajouter un auteur à ce document, en inscrivant simplement son nom dans le champ AUTR de la ligne marquée d’un astérisque dans la sous-feuille de données :

de-textuel-a-relationnel-68.png

Notez qu’Access a lui-même généré une valeur pour le champ NO (puisqu’il s’agit d’un champ de type NuméroAuto). Il a aussi inscrit automatiquement la valeur 13 dans le champ noDoc, puisque la saisie a été faite dans la sous-feuille du document 13.

Comme d’habitude, dès que l’on sort le curseur de la fiche en création, celle-ci est sauvegardée, comme l’indiquent la disparition de l’icône du stylo et le déplacement de l’astérisque à la ligne suivante :

de-textuel-a-relationnel-69.png

Notez que la fiche est bel et bien sauvegardée dans la table AUTRocc, comme on peut le vérifier en ouvrant cette table directement :

de-textuel-a-relationnel-70.png

Limite des sous-feuilles de données

La limite du mécanisme des sous-feuilles de données est qu’il ne peut y avoir qu’une seule sous-feuille de données associée à une table, alors qu’il peut y avoir plusieurs tables correspondant à des champs à occurrences multiples.

Pour la saisie, une façon de contourner cette limite est de faire la saisie pour un champ à occurrences multiples à la fois et de changer la sous-feuille associée pour passer à un autre champ. Cette solution n’est cependant pas vraiment satisfaisante, surtout si l’on envisage que la saisie soit effectuée par l’utilisateur final (plutôt que par la gestionnaire de la BD).

La véritable solution réside dans l’utilisation d’un formulaire de saisie et, plus particulièrement, de sous-formulaires.

Nous verrons ces outils plus tard dans le cours.

Exercice de saisie

Grâce aux sous-feuilles de données, amusez-vous à saisir quelques auteurs puis quelques descripteurs pour certains documents. Allez voir les informations correspondantes directement dans les tables AUTRocc et DESCocc.