PrecedentSuivant

La normalisation et les formes normales.

L'avantage d'une base de données relationnelle est d'éviter au maximum les répétitions ou les redondances d'information. La normalisation sert à séparer la liste des champs en plusieurs tables pour avoir une base de données qui est plus efficace. On parle de retirer progressivement quelques problèmes que l'on retrouve dans les bases de données pour afficher la base de données sous différentes formes normales (1ère, 2ième, 3ième ...) Pour le moment, nous allons seulement regarder les trois premières formes normales.

Première forme normale : répétition des données

Pour atteindre la première forme normale, il faut éliminer les groupes répétitifs en les séparant en plusieurs tables. Le travail à accomplir pour atteindre la première forme normale est d'éviter complètement les répétitions d'entrée de données.

Par exemple, une facture peut contenir plusieurs produits.

Numéro de facture

Numéro de produit

1

1, 3, 5

Donc, il peut avoir plusieurs numéros de produits pour une même facture. Ceci est de la redondance et ce n'est pas une forme appropriée pour conserver de l'information dans une base de données relationnelle. Comment fera-t-on ensuite pour relier une modification au bon produit? Il faut donc mettre Numéro de produit dans une table autre que Facture. On peut en même temps déplacer les champs similaires dans l'autre table. Le test de la deuxième forme normale va s'assurer que les champs sont à la bonne place.

Il faut s'assurer que l'utilisateur ne va entrer plusieurs fois la même information. Par exemple, cela ne serait pas efficace d'avoir une table "Facture" qui contiendrait aussi les champs "Nom du client", "Adresse de livraison", "personne contact". Cela ne passerait pas à la première forme normale. La raison est qu'il faudrait que l'utilisateur rentre pour chaque facture la même information qu'il a déjà entrée dans les factures précédentes pour le même client. Après tout, combien de fois peut-on entrer la même adresse? Pas vraiment efficient! C'est pour cette raison qu'il faut "découper" la liste des champs dont vous avez besoin dans plusieurs tables pour avoir une forme efficiente d'entrée et d'utilisation des données. La même situation se répète pour les informations sur le vendeur.

Facture: Numéro de facture, date, bon de commande, escompte

Clients : Numéro de client, adresse de facturation, ville, numéro de téléphone, numéro de télécopieur, adresse de courriel, adresse de livraison, personne-ressource, escompte, conditions de paiement

Employés : Numéro du vendeur, nom, prénom, numéro d'assurance sociale

Inventaire : Numéro de produit, description, prix unitaire, quantité achetée, quantité disponible

Il faut ensuite déterminer la clé primaire pour chaque table. Cela est nécessaire pour la seconde forme normale. Une clé primaire est un champ, ou une série de champs, qui permet de distinguer un enregistrement des autres. Pour la table Facture, la clé primaire est le champ Numéro de facture. Le contenu de tous les autres champs de la table peut se répéter ce qui serait contraire à la convention d'une clé primaire.

Deuxième forme normale: Dépendance directe à la clé primaire

Pour se rendre à la deuxième forme normale, il faut premièrement avoir passé à travers la première forme normale. Il faut ensuite éliminer les dépendances partielles. Cela veut dire qu'il faut s'assurer que tous les champs de la table dépendent de la clé primaire de la table. Sinon, il faudra créer une nouvelle table ou déplacer le champ.

Le problème pour ce niveau est le champ Quatité achetée. Il dépend en même temps du numéro de facture et du numéro de produit. Une facture peut avoir plusieurs produits. Mais un produit peut aussi se retrouver sur plusieurs factures. Il y a donc une relation de plusieurs à plusieurs entre ces deux tables.

Facture : Numéro de facture, Date, bon de commande, escompte

Clients : Numéro de client, adresse de facturation, ville, numéro de téléphone, numéro de télécopieur, adresse de courriel, adresse de livraison, personne-ressource, escompte, conditions de paiement

Employés : Numéro du vendeur, nom, prénom, numéro d'assurance sociale

Inventaire : Numéro de produit, description, prix unitaire, quantité disponible

Items : Numéro de facture, Numéro de produit, Quantité achetée

Voici un exemple du contenu de la table items. Pour cette base de données, la table est appelée Transition Fact-Inv puisqu'elle permet de relier les tables Facture et Inventaire. Vous remarquez aussi que la clé primaire de cette table est composée de deux champs: Numéro de facture et Numéro de produit. Ce sont aussi les clés primaires des tables Facture et Inventaire.

Numéro de facture

Numéro de produit

Quantité achetée

1

1

10

1

2

25

2

1

50

2

2

100

Dans cette table, un même numéro de facture et un même numéro de produit peuvent être utilisés plusieurs fois. Mais seulement un à la fois. Il n'y aura jamais deux fois le même numéro de facture et le même numéro de produit.

Troisième forme normale : Dépendances partielles de la clé

Troisième forme normale: éliminer les dépendances transitives. Il faut s'assurer qu'il n'y a pas de tables qui soient cachées parmi les autres.

Aussi, les tables ne devraient jamais contenir de champs calculés. Par exemple, il ne devrait pas avoir les champs "sous total", "Total", "TPS", "TVQ", "TVA" ou "Autres taxes" dans les tables puisqu'il est possible de les calculer à partir des données qui sont déjà dans les tables. Il est possible d'avoir le "sous total" en multipliant les "Quantité vendue" par les "Prix unitaire". Donc, il est inutile de l'avoir dans les tables.

La troisième étape est de déterminer les relations entre les différentes tables. Il faut regarder quelles sont les relations possibles entre les entités. Pour avoir une relation, deux tables doivent avoir au moins un champ en commun. On peut relier une facture à un client par le champ "ID_Client". Ou encore, relier un produit à une facture par le champ "ID_Produit" etc. Vous devriez à ce moment vous apercevoir que certains champs seraient mieux placés dans une autre entité. Une fois que vous avez réalisé les regroupements et déterminé les relations, vous avez votre base pour la création des tables.

Maintenant que vous avez les entités et les champs qui les composent, pensez à quoi devrait ressembler vos formulaires et vos états. Est-ce que les champs que vous avez choisis répondent à tous vos besoins? Prenez tout le temps nécessaire pour l'analyse. Il vous coûtera beaucoup plus de temps et d'effort si vous passez trop rapidement à la création et oubliez des éléments importants.

Attention!

Si vous êtes dans le laboratoire d'informatique au moment de la création de votre première base de données, assurez-vous de sauvegarder le fichier sur le lecteur A: . Ne créez pas votre base de données sur le disque dur. Sinon, un technicien sera obligé de venir vous aider à la déplacer sur votre disquette. À chaque session, un étudiant "perd" sa base de données qu'il, ou elle, a créé sur le disque dur au lieu de sa disquette personnelle.

*Du menu Fichier, sélectionnez l'option Nouveau.
* Access va ensuite vous demander quel nom vous voulez donner à votre fichier et sur quel lecteur. Pour les besoins des démonstrations appelez-le ACCESS1.MDB.
*Appuyez sur le bouton OK.

Maintenant que vous avez créé la base de données, il reste qu'a créer les tables, entrer l'information, créer les requêtes, les formulaires, les états, les macros et les modules pour votre base de données. Donc, il reste encore beaucoup de travail.