Concevoir une base de données

En fonction de vos besoins, il existe deux façons de travailler. Si vous souhaitez créer une petite base de données pour la collection de vos livres et que vous êtes le seul à utiliser votre base de données, vous privilégierez certainement l’aspect « standalone » de votre application. Autrement dit, les tables de stockage ainsi que l’accès aux données par des formulaires et des états sont dans le même fichier ACCESS. Cet aspect présente l’avantage d’avoir tout sous la main, et d’être facilement transportable d’une machine à une autre.

Si vous êtes plusieurs utilisateurs à travailler sur une même application, il convient de travailler avec un couple de fichiers. Les tables seront mises dans la base « dorsale » (back-end en anglais) et les formulaires, requêtes et états seront dans la base « frontale » (front-end en anglais). La dorsale est un fichier unique, mis en disponibilité sur un réseau. La frontale (souvent appelée Application) sera distribuée sur les postes clients.

L’avantage de cette technique est multiple. D’une part, les données sont séparées de l’application. Il est donc plus aisé de faire des opérations de maintenance sur le serveur de la dorsale, comme la sauvegarde des données. D’autre part, plusieurs utilisateurs peuvent utiliser en même temps, par leur application, les données de la dorsale. Chaque utilisateur peut en outre utiliser une frontale différente (le comptable de la société n’utilisera pas la même application que le vendeur).

ACCESS permet la conversion d’une base standalone en couple dorsale/frontale et inversement, par les opérations de fractionnement et de regroupement. Nous le verrons plus loin.

Le modèle entité-association

Avant de concevoir une base de données, il faut savoir la modéliser. Ce cours ne traitera pas les différentes méthodes d’analyses d’une base de données, telles que l’UML, Merise, etc. Cependant, il est beaucoup plus facile de concevoir une base de données à partir d’un modèle papier. La méthode de modélisation la plus proche d’ACCESS est celle du Modèle entité-association. Sans entrer dans les détails, nous aborderons les quelques notions utiles de ce modèle.

icône table accessChaque table sera représentée comme ceci. C’est ce qu’on appelle une entité. Cette entité désigne la table et les champs qu’elle contient. La clé primaire est toujours signifiée en italique. La clé primaire est ce qu’on appelle un identifiant. Nous reviendrons sur cette notion plus loin dans le cours.

Les entités sont liées entre elles par des associations. Une association permet de définir l’action réalisée entre deux entités. Généralement, une association est désignée par un verbe.

relation à 3 entités

Dans cet exemple, nous avons défini 3 entités. Une personne habitant une ville et qui souhaite acheter divers produits dans un magasin. Il y a donc 2 associations : la personne habite dans une ville et achète des produits.

Il nous reste maintenant à définir les cardinalités. Une cardinalité permet de savoir le type de relation entre les tables.

Pour définir une cardinalité, il suffit d’employer la phrase suivante : est-ce qu’un (e) {entité} peut {association} plusieurs {autre entité} ?

Dans l’exemple ci-dessus, est-ce qu’une Personne peut habiter plusieurs Villes ? Non, bien évidemment. Mais est-ce qu’une Ville peut être habitée par plusieurs Personnes ? Oui !

La cardinalité est donc définie.

relation cardinalité

Les types de relations

Définissons maintenant les types de relations possibles dans une base de données. D’après les cardinalités ci-dessus, nous remarquons qu’il n’y a que trois types différents :

  • Les cardinalités (relations) 1 à 1 ;
  • Les cardinalités (relations) 1 à n ;
  • Les cardinalités (relations) n à n ;

La relation 1 à 1

Les relations 1 à 1 sont des relations extrêmement rares. En effet, si une entité ne peut être liée qu’avec une seule autre entité, en réalité il s’agit de la même ! Par exemple, une personne possède un n° national unique et propre à chacun. Il n’y a donc aucun intérêt à stocker les n° nationaux dans une table à part, alors qu’un simple en champ en plus dans la table T_Personne suffit ! Mais il peut arriver que cette relation soit nécessaire. Par exemple pour étendre une table sans toucher à sa structure.

Pratiquement, dans ACCESS, les tables seront regroupées en une seule table, sauf cas particulier.

La relation 1 à n

C’est un des cas les plus fréquents, et le cas le plus facile à gérer. Dans ACCESS, il suffit d’ajouter un champ, qu’on appellera la clé externe, dans la table ayant la cardinalité « n ». Cette clé externe sera liée à la clé primaire de l’autre table.

La relation n à n

Autre cas fréquent, cette relation n’est pourtant pas réalisable dans ACCESS. Il faut alors la transformer en deux relations 1 à n. Pour cela, il faut créer une table intermédiaire.

création d'une table intermédiaire

Le modèle E-A dans ACCESS

Une fois ce modèle théorique défini, il faut le transposer dans un modèle plus proche d’ACCESS. Cette transposition se fait en suivant ces quelques règles :

  • Règle n° 1 : Chaque table doit disposer d’une clé primaire. Cette clé représentera de manière univoque chaque enregistrement de la table.
  • Règle n° 2 : Si certains champs ont une valeur unique dans une table, ils doivent être indexés sans doublons.
  • Règle n° 3 : Tout champ dont la valeur risque d’être introduite plusieurs fois dans les enregistrements de la table doit :
    • Soit être retirés de la table et placés dans une nouvelle. Cette nouvelle table devra respecter les autres règles.
    • Soit être remplacé par une liste de choix si les valeurs ne sont pas évolutives ou trop nombreuses.
  • Règle n° 4 : Pour chaque relation 1 à n, il faut ajouter une clé externe dans la table ayant le côté « n » de la relation. Cette clé externe sera du même type que la clé primaire de l’autre table.
  • Règle n° 5 : Pour chaque relation n à n, il faut remplacer la relation par une table intermédiaire. Cette table intermédiaire sera reliée par deux relations 1 à n aux tables d’origine. Cette table intermédiaire doit respecter les règles précédentes.

Avec ces 5 règles, re-modélisons notre base de données. Nous remarquerons que la table intermédiaire peut contenir d’autres champs, tels que la quantité.

Une fois ce schéma réalisé, il ne nous reste plus qu’à le mettre en œuvre dans ACCESS.

modélisation finale de la base de données

Exercice

Dans ce syllabus, nous allons concevoir une base de données de A à Z. Définissons d’abord le contexte.

Nous souhaitons créer un outil de gestion de bibliothèque. Cet outil nous permettra :

  • d’encoder une liste d’auteurs ;
  • d’encoder une liste de catégories ;
  • d’encoder une série de livres ;
  • d’attacher des mots-clefs aux livres ;
  • de générer un catalogue ;
  • de générer une fiche produit.

Commençons par analyser l’application avec le modèle entité-association.

Combien de tables avons-nous besoin ?
Nous avons besoin de 4 tables :

  • la table des catégories,
  • la table des auteurs,
  • la table des mots-clefs,
  • la table des livres.

Passons aux relations. Pour rappel, l’établissement d’une relation se fait en posant les bonnes questions.

Quelles sont les relations ?
  • un auteur peut-il écrire plusieurs livres ? OUI !
  • un livre peut-il être écrit par plusieurs auteurs ? NON ! (techniquement, oui, mais simplifions un peu…)
  • une catégorie peut-elle contenir plusieurs livres ? OUI !
  • un livre peut-il appartenir à plusieurs catégories ? NON ! (quoique..)
  • un livre peut avoir plusieurs mot-clefs ? OUI !
  • un mot clef peut être associé à plusieurs livres ? OUI !

En fonction des réponses données, on connait le type de relations, ce qui donne de schéma suivant. Aidez-vous des 5 règles !

Quel est le schéma ?

access exercice ea

Du fait qu’une de nos relations est de type n à n, nous sommes obligés de passer par une table intermédiaire ! Elle est en rouge sur le schéma. Les champs ont aussi été définis. Je n’ai mis que le strict minimum, votre solution sera certainement différentes, mais les relations devraient être identiques.

[sb_sibling_prev] [sb_sibling_next]
Print Friendly, PDF & Email