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 normalisation

La normalisation

Dans la pratique, il n'est malheureusement pas suffisant de répartir les données dans quelques tables. Il faut d'abord savoir quelles sont les données qui vont dans tel ou tel table... et ceci répond à des règles de jeux précises.


Il existe 5 - 6 règles appellées "formes de normalisation". Dans les bases de données ont utilise les 3 principales qui sont généralement suffisantes. Ces règles sont formulées dans un langage assez obscur pour le commun des mortels, de sorte que nous allons exprimer cela de façon plus simplifiée (éventuellement même approximative). Inutile d'augmenter la difficulté.


Avertissement:

Tout ne sera peut-être pas compris à la première lecture, ceci n'étant pas dû à un manque d'intelligence... mais plutôt au coté abstrait du sujet!

Le fait de se sentir sensibilisé au problème en se disant "Sapristi, je peux faire beaucoup d'erreurs si je ne tiens pas compte de la modélisation et la normalisation" est déjà un premier pas important.

La mise en oeuvre de ces règles est alors une toute autre histoire et qui demande beaucoup de temps. Et ce temps, il faut absolument le prendre et ne jamais se mettre (ou se laisser mettre) la pression.

Place au plus difficile...


Première forme normale (1FN)

On dit qu'une relation est en 1FN si tous les attributs qui la compose sont atomique.

En langage courant: Tous les champs d'une table doivent être tel pour qu'ils ne soient plus décomposables


Exemple 1 :

Il existe un champ "Adresse" dans une table. Il ne serait pas correct, car "Adresse" peut encore être scindée (par exemple en nom, prénom, rue, code postal, ville...)


Exemple 2 :

De mauvaises saisies peuvent-être réalisées dans des tables dont les champs semblent correctement nommés.

Admettons une entreprise qui possède sa cantine et dont les tables sont numérotées (table 1, table 2, etc.)

  • A chaque table sont assis des employés qui possèdent leur numéro personnel, NumPerso (monsieur Durant à le numéro 12, madame Dupont le 56, Leroy le 36 et madame Lafille le 73)
  • Chaque personne choisit son menu
  • La table possède les champs "NoTable", "NumPerso", "Menu"

 

Saisie fausse

NoTable

NumPerso

Menu

1

12, 56

Viande, Viande

2

36, 73

Viande, Poisson

 


 

Saisie correcte

Table

NumPerso

Menu

1

12

Viande

1

56

Viande

2

36

Viande

2

73

Poisson

 



Deuxième forme normale (2FN)

On dit qu'une relation est en 2FN si elle est en 1FN et si toutes les dépendances fonctionnelles entre la clé et les autres attributs sont élémentaires.

En langage courant : Restons dans notre précédent exemple 2 et supposons qu'en plus du numéro de table il existe une autre appellation pour qu'un nouveau serveur puisse s'y retrouver plus simplement.

 

Dans ce cas, la table suivante ne serait pas correcte :

 

NoTable

Endroit

NumPerso

Menu

1

A l'entrée

12

Viande

1

A l'entrée

56

Viande

2

Fenêtre

36

Viande

2

Fenêtre

73

Poisson

 

 

 

Réflexions suivantes:

  • Aucun des champs de cette table n'est un candidat pour être clé primaire, car nous constatons facilement que les trois autres n'en ont pas une totalement dépendance fonctionnelle.
  • Le menu a toutefois une totale dépendance fonctionnelle d'une combinaison des champs NoTable et NumPerso. Car, malgré trois commandes du menu viande, dont 2 fois à la même table, cette combinaison du NoTable et du NumPerso conduit à une unicité (1/12, 1/56, 1/36).

    Cette combinaison est donc candidat à être clé primaire !!!

    En partant du principe que nous créons une table qui n'est destiné qu'à un seul repas, nous pouvons constater qu'aucune combinaison de Table et NumPerso ne peut créer de doublon. Lors du repas du soir ou du lendemain, les mêmes personnes pourraient s'assoir à la même table, nous devrions alors ajouter un champ date et/ou heures et - pour retrouver l'unicité - les ajouter à cette combinaison de Table et NumPerso. Mais ne compliquons pas de trop...
  • Qu'en est-il de ce champ "Endroit" ?
    Ce champ Endroit n'est en relation qu'avec la table et donc son numéro, mais non avec la personne et son NumPerso. Ainsi, le champ Endroit n'est pas en relation avec la clé combinée (NoTable + NumPerso) mais uniquement avec une partie de celle-ci (le numéro de table).
    Donc, Endroit n'est en aucun cas candidat à être clé primaire, n'ayant même pas de totale dépendance fonctionnelle du candidat déjà cité (NoTable + NumPerso).
  • De ce fait, cette table ne répond pas à la seconde forme normale et doit être modifiée en la scindant (les deux tables seront remises en forme par relation via le champ NoTable).

 

 

Mise en relation via ''NoTable''

NumPerso

Menu

NoTable

 

NoTable

Endroit

12

Viande

1

1

A l'entrée

56

Viande

1

2

Fenêtre

36

Viande

2

 

73

Poisson

2

 

  • Par la même occasion, nous nous créons un nouvel avantage : nous empêchons la redondance (la saisie multiple et inutile de certaines données), car la dénomination "A l'entrée" et "Fenêtre" n'existe plus qu'une seule fois dans une table séparée et ne sont plus représenté que par leur numéro de table.

 

Troisième forme normale (3FN)

On dit qu'une relation est en 3FN si elle est en 2FN et si toutes les dépendances fonctionnelles entre la clé et les autres attributs sont élémentaires et directes.

En langage courant : Il ne peut y avoir de dépendance fonctionnelle entre les champs non-clé primaire. Ils ne peuvent être dépendant que de la clé primaire. C'est le cas dans l'exemple ci-dessus. Il est inutile de les modier.

 

 

Ajoutons un champ supplémentaire, le prix :

 

NoTable

NumPerso

Menu

Prix

1

12

Viande

10 euros

1

56

Viande

10 euros

2

36

Viande

10euros

2

73

Poisson

15 euros

 

 

 

Nous obtenons maintenant une situation similaire au cas "Endroit" :

  • Le Prix est dépendant du Menu, alors que Menu n'est pas clé primaire. Il apparaît à nouveau de la redondance, car le Prix du Menu est saisi trois fois (et devrait également être modifié trois fois s'il se produit une augmentation ou une baisse).
  • Menu est encore dépendant de la clé primaire (NoTable + NumPerso), alors que Prix n'est qu'indirectement lié à cette clé primaire.

 

Cela ne peut être et demande une nouvelle scission de la table :

 

Mise en relation via ''Menu''

NumPerso

NoTable

Menu

 

Menu

Prix

12

1

Viande

Viande

10 euros

56

1

Viande

Poisson

15 euros

36

2

Viande

 

73

2

Poisson

 

 

 


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


Date de création : 07/02/2006 : 20:42
Dernière modification : 23/06/2013 : 01:25
Catégorie : La normalisation
Page lue 7628 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
Préférences

Se reconnecter
---

Votre nom (ou pseudo) :

Votre code secret


 Nombre de membres 1 membre


Connectés :

( personne )

Haut