Résultat et résumé

Résultat et résumé

A première vue, la table d'origine ressemble assez bien à la table suivante qui a pourtant l'air bien innocente (remarquez que cette table est déjà modifiée selon la première forme normale, disons donc une version deux !! )

A la fin de la normalisation apparaît une construction qui semble être inutilement compliquée !

Les relations se font d'un coté par NoTable et de l'autre coté par Menu

En réalité, nous devons encore ajouter à la table de droite un champ NoMenu et utiliser dans la table centrale ce NoMenu au lieu du champ Menu.

Le jeux en vaut-il la chandelle ?

En y regardant de plus près, on remarque rapidement l'utilité de cette méthode (il suffit d'imaginer que la table d'origine version 2, ce ne sont pas 4 mais 2000 enregistrements):

• Nous aurions alors écrit 2000 fois le mot "Viande" ou "Poisson", "A l'entrée" ou "Fenêtre" à la place du numéro "1" ou "2". Il en résulterait un travail plus important et plus de consommation d'espace mémoire dans la base de données.
• Lors d'une modification du prix des menus de 10 à 11 euros et de 15 à 16 euros, nous devrions modifier les 2000 prix de la table. Alors que dans les tables normalisées, il suffit de modifier les 2 prix dans la table de droite. D'où un énorme gain en temps et de sécurite de la saisie.
• Un résultat comparable lors de la modification de l'appellation "A l'entrée" ou "Fenêtre".
• Le tri sur les "Menu" ou "Endroit" ne sont pratiquement pas réalisable dans la version 2.
• Dans la version 1 et Version 2, la redondance des données augmenterait à chaque fois que nous ajouterions un champ dans la table.
• Au cas ou nous voudrions étendre les possibilités dans notre base de données en y ajoutant des tables et les relier à la table version 1 ou version 2, nous hériterions aussi des problèmes et les démultipliants. Ce que nous avons éliminé avec la version 3 et version 4.

De fait, une extension est déjà existante depuis le début : la table "Personnel" qui doit au moins posséder les champs "NoPerso" et "NomPerso".

Chaque extension future de la base de données profitera de cette modularité

Le sujet est très loin d'être complet et totalement traité, mais aidera le débutant à appréhender le sujet. Chose qu'il se doit de faire, s'il veut tirer de sa base de données un quelconque plaisir ou avantage à l'utiliser.

Un conseil pour finir :

Ne vous lancez pas dès le début dans une usine à gaz avec des dizaines de tables et de relations. Une petite base avec quelques tables et peu de champs est idéal pour se faire la main, pour comprendre les mécanismes qui doivent gérer cela. Une fois les automatismes acquits, vous éviterez les pièges grossiers qui vous feront abandonner en cours de réalisation.

Et retenez encore ceci :

Dans une base de données, les données se rangent verticalement et non horizontalement, comme vous pourriez en avoir pris l'habitude en utilisant un tableur.

<<< Page précédente