Les mémos

Fermer Tables

Fermer Requêtes

Fermer Formulaires

Fermer Etats

Fermer Modules

Fermer Base

Fermer Automation

Fermer Administration

Fermer Registre

Fermer String

Fermer Email CDO

Fermer Outlook

Fermer Net

Fermer Dates - Heures

Fermer Fichiers

Fermer Références

Fermer Vrac

Je débute...

Fermer La normalisation

Fermer VBA

Attention
Aucun support
par émail !

Utilisez le forum pour les questions/réponses concernant MsAccess et les codes que vous trouverez sur ce site.
Visites

   visiteurs

   visiteurs en ligne

La normalisation - La modélisation

La modélisation

Ceci ne devient possible que par l’usage d’un formulaire principal et d’un sous-formulaire, ce qui sous-entend que les données de ces deux formulaires ne soient pas basées sur la même table ou requêtes et soit placés en relation.

Il a fallu auparavant que les données du père et des enfants ne soient pas sauvées dans une seule table, mais dans deux .


Ebauche :

 

Table du père (tblPères)   Tables des enfants (tblEnfants)

PèreID
(Clé primaire - NuméroAuto)

EnfantID
(Clé primaire – NuméroAuto)
PèreNom (Texte) EnfantNom (Texte)

 



Maintenant, nous devons mettre en relation ces deux tables par une clé commune (clé externe).


On peut se poser la question, qu’est ce pour une relation ?

La réponse : 1 père - plusieurs enfants, ou encore, 1 à plusieurs, ou encore, 1 : N


La relation N:1 est celle rencontrée le plus souvent dans une base de données. Grâce à elle, on peut afficher le père dans le formulaire principal (la source étant tblPères) et les enfants dans le sous-formulaire (la source étant cette fois tblEnfants)

Nous avons donc besoin d'une relation entre nos deux tables via deux champs clés communs qui soit avant tout unique!
Mais quel est le type de clé qui, de par sa nature, serait unique? Une clé primaire! Le plus simple pour y arriver est d'utiliser un NuméroAuto, mais un champ texte convient aussi. Le champ NuméroAuto est de type numérique/Entier long. Ainsi, seul ces deux types seront utilisés : "numérique/entier-long" et "texte".

Dans nos deux tables, la clé primaire étant un NuméroAuto et ainsi du type Numérique/Long-Entier

Se pose maintenant la question: dans laquelle des deux tables définit-on la clé externe?

Dans une relation 1 à plusieurs (1:N), la clé externe va du coté plusieurs. Donc, dans notre exemple, elle va du coté tblEnfants.
Comme on peut le voir, PèreID dans tblPère est Clé Primaire et NuméroAuto alors que dans tblEnfants ce n'est pas une clé primaire et numérique (entier-long).

Puisque ce n'est pas une Clé Primaire, ni un NuméroAuto, on pourra introduire plusieurs fois la même valeur numérique. Cela est nécessaire, puisque PèreID devra être introduite autant de fois qu'il y a d'enfants.


Table du père (tblPères)   Tables des enfants (tblEnfants)

PèreID

(Clé primaire – NuméroAuto) =>

EnfantID

(Clé primaire – NuméroAuto)

PèreNom (Texte) <= PèreID (Numérique - entier long)

 

EnfantNom (Texte)


Avec les données :

 

tblPères

PèreID

PèreNom

1

Durant

 


 

tblEnfants

EnfantID

PèreID

EnfantNom

1

1

Paul

2

1

Jacques

3

1

Louis

 


 

Dans la fenêtre des relations, on relie maintenant les deux tables par leurs champ PèreID et coche "l'intégrité référencielle". Nous reviendrons sur cette dernière qui est une chose très utile.

Le coté "plusieurs" sera représenté par le signe infini ~ (tilde) dans la fenêtre des relations.


Il est maintenant important de faire le bilan de ce qui s'est passé :

  • Avec un tel lien, la mise en relation, nous avons laissé derrière nous le couple Word/Excel et somme entré dans ce qui défini une base de données.
  • La répartition des données nous permet de gagner de l'espace mémoire, car nous n'écrivons qu'une seule fois "Durant".
  • La répartition des données nous protège de la plupart des erreurs de saisies, car nous n'écrivons qu'une fois "Durant". Si nous souhaitons remplacer "Durant" par "Durand", nous ne devrions le faire qu'une seule fois dans la table et cela se répercuterait sur tous les enregistrements dont le nom d'un enfant serait relié au père par la clé de "Durant".
  • Nous pouvons aussi créer des formulaires avec sous-formulaire, des états avec sous-état et ainsi rapprocher visuellement les données de plusieurs tables ou requêtes.

Venons en maintenant à l'intégrité référencielle

  • Dans la table tblPères nous avons saisi "Durant" et le NuméroAuto PèreID indique la valeur "1". Dans la table tblEnfants, nous essayons de donner au champ PèreID la valeur "2" - valeur qui n'existe pas dans la table tblPères... et c'est exactement ce que remarque Access lorsque la relation possède la propriété "intégrité référencielle" et nous le signale.
  • Vous essayez de supprimer dans la table tblPères, l'enregistrement "Durant" alors qu'il est encore lié à ses 3 enfants - cela non plus, Access ne le permet pas... car il y aurait alors des enfants dans la table tblEnfants qui n'auraient plus de père! Soit vous supprimer auparavant les enfants et ensuite le père, soit vous attribuez les enfants à un autre père - pour autant qu'il en existe un autre dans la table tblPères.
  • Lorsque vous cochez l'intégrité référentielle dans la fenêtre des relations, vous trouvez en-dessous la possibilité de cocher "la mise à jour en cascade..." et "la suppression en cascade..."
    Avec la mise à jour en cascade, les éventuelles modifications dans la table principale (ici la table tblPères) sont répercutées sur la table secondaire (tblEnfants).
    Lors de la suppression en cascade, voilà ce qui se passerait : Dans la table tblPères vous voulez supprimer l'enregistrement "Durant". Access signalera que cet enregistrement est lié à d'autres tables et demande s'il doit effectivement supprimer. Vous cliquez sur OK et Access supprime non seulement le Durant, mais également les 3 enregistrements liés dans la table tblEnfants. C'est donc une option "dangereuse" que l'on ne devrait pas cocher à la légère!!!

Les requêtes

En plus des fonctions offertes par les requêtes, elles donnent la possibilité de rapprocher les données que vous avez "réparties" sur plusieurs tables. Lorsqu'il existe une relation en deux tables, celle-ci est automatiquement affichée dans la grille de création de requête.

Ici apparaît un autre aspect pour la compréhension d'une base de données : la symbolique de la clé externe (aussi appelée clé étrangère).

- La clé en relation n'est pas simplement un nombre (ou un texte) mais, il est un symbole pour toute la table qu'il représente! Qu'est ce que cela signifie?

Imaginons que, dans la table tblPères il existe maintenant une vingtaine de champs (adresse, téléphone, etc.), vous souhaitez relier les deux tables par une requête. Vous glissez tous les champs des deux tables dans la grille de requête. En mode affichage apparaîtrons trois lignes.

  • Tous les champs de la table tblPères et le nom du premier enfant.
  • Tous les champs de la table tblPères et le nom du second enfant.
  • Tous les champs de la table tblPères et le nom du troisième enfant.

C'est déjà pas mal, car vous n'avez saisi qu'une seule fois les champs de la table tblPères. Mais vous souhaitez maintenant ajouter un quatrième enfant! Il suffit pour cela de saisir la valeur de la clé, ici le numéro "1" pour que automatiquement, Access affiche tous les champs du coté de la table tblPères et il vous suffit de saisir le nom du quatrième enfant. La valeur de la clé n'est pas simplement une valeur numérique, mais bien un symbole pour toute la table qu'elle représente.


Autres types de relations

En plus de la relation 1 à plusieurs existe encore au moins deux autres : 1:1 et M:N (1à 1 et plusieurs à plusieurs)

Relation 1:1

A première vue, c'est la relation qui représente le mieux la table simple que l'on a scindée en deux ou trois tables pour cause d'un trop grand nombre de champs. Mais ces tables n'ont pas de réelle relation, tout au plus une "liaison". Leur clé primaire sont identique et relié entre eux. Plusieurs enfants ne peuvent avoir le même père, ce qui était possible précédemment - et avec cela, tout s'écroule.

L'on pourrait en ce moment utiliser Excel et placer les 280 champs (les cellules) sur une ligne.

Relation M:N

Une espèce plutôt malicieuce!! Une relation M:N doit obligatoirement être scindée en deux relations 1:N (1 à plusieurs)

Exemple: Vous vendez des produits et des clients qui les achètent. Nous créons donc deux tables que nous voulons relier par une 1:N. Cela s'avère problématique: car qui ici est "1" et qui est "plusieurs" ?

Puisque un client peut acheter différents produits et un produit peut être acheté par différents clients... donc: "plusieurs à plusieurs" ou M:N.

L'unicité obligatoire de la clé primaire est alors obtenue en créant une troisième table.


Avant:

 

tblClients

 

tblProduits

ClientID

ClientNom

ProduitID

ProduitNom

1

Durant

1

Marteau

2

Dupont

2

Vis

3(1)

Durant

3

Pince

 

Si le même Durant veut en plus du marteau, achetez une pince, on ne pourra pas saisir à nouveau son ID "1" (puisque ce champ est clé primaire et numéroauto) mais il s'ajoutera un "3". Ainsi, le même Durant à deux numéro, ce qui créera des problèmes.

C'est pour cela qu'ici, ni le ClientID, ni le ProduitID ne peuvent être unique, mais seulement une combinaison des deux. Et cela nous le réalisons en incluant une troisième table qui, dans les cas les plus simple, ne comporte que les deux ID en tant que relation 1:N et constituerons ensemble la clé externe (de type numérique, entier-long).


Après:

 

tblClients

 

tblClientProduit

 

tblProduits

ClientID

ClientNom

ClientID

ProduitID

ProduitNom

 

ProduitID

 

 

En rouge, les clés primaires de chaque table.
Remarquez que dans la tblClientProduit, ce sont
les deux champs qui forment la clé primaire!

 

 

Etant donné que les champs de la table tblClientProduit ne sont pas de type NuméroAuto, mais de type numérique entier-long, un même nombre peut exister plusieurs fois.

La paire 1 / 1 (Durant / Marteau) est unique
La paire 1 / 3 (Durant / Pince) ne peut également exister qu'une seule fois.


Si vous tentez la paire 1 / 3 une seconde fois, Access rouspète et ne vous le permettra pas, car la combinaison de ClientID et ProduitID sont clé primaire et ne peuvent ainsi exister qu'une seule fois.


Mais, me direz-vous, monsieur Durant est capable de revenir le lendemain et vouloir encore acheter une pince - ce qui ne serait pas possible dans notre construction actuelle! Dans ce cas, il faudrait ajouter à la table tblClientProduit un champ "DateAchat" (éventuellement même un champ "HeureAchat").
De cette façon, les trois ou quatre champs formeraient la clé primaire et monsieur Durant pourrait revenir acheter sa pince et même plusieurs fois le même jour...


<<< Page précédente - Page suivante >>>


Date de création : 07/02/2006 : 20:41
Dernière modification : 23/06/2013 : 01:24
Catégorie : La normalisation
Page lue 8101 fois


Imprimer l'article Imprimer l'article

Recherche



Lettre d'information
Pour avoir des nouvelles de ce site, inscrivez-vous à notre Newsletter.
Captcha
Recopier le code :
Au sujet de l'auteur
L'auteur qui fréquente (fréquentait) le forum microsoft.public.fr.access a eu le plaisir d'être nommé MVP Office-Access de janvier 2003 à décembre 2011.

Qui sont les MVP ?

Divers ;-)
Nous contacter

Haut