Introduction
Avant de commencer, regardons quelques-uns des avantages d'une base de
données.
 Accès à
l'information plus rapidement et facilement.
Toute l'information se retrouve à une seule
place; dans votre base de données.
Plus besoin d'essayer de regrouper l'information
qui provient de plusieurs sources.
Recherche Ad hoc facile.
Ex.: Combien me
reste-t-il en stock du produit X? Qui sont mes dix clients les plus importants
en ce moment? Quels produits sont mes meilleurs vendeurs? Quels sont mes
meilleurs représentants?
Meilleur suivi de l'information.
Meilleure gestion des données.
Meilleure analyse des données.
Meilleure
prise de décision.
Mieux apte à répondre aux besoins de la clientèle.
Automatisation de certaines
tâches répétitives.
POURQUOI APPRENDRE UNE BASE DE DONNÉES RELATIONNELLE?
Ce type de base de données a plusieurs avantages comparés à une base de
données simple aussi appelée "flat file". Elle utilise beaucoup moins d'espace
parce qu'elle réduit au minimum les redondances ou les répétitions des données.
Pour mieux comprendre l'avantage d'un système de gestion de base de données
relationnel (SGBDR), utilisons un exemple de factures pour comparer ces deux
types de BD et pour montrer certains concepts de base d'un SGBDR.
Regardons quelques-unes des données que l'on retrouve normalement sur une
facture:
Ex.: Date, Numéro de facture, Numéro du vendeur, Numéro du produit,
Quantité vendue, Prix unitaire, Description du produit, sous total, Taxes, Total
...
Voici quelques-unes de ces données dans un BD simple.
No. Facture |
Client |
Produit |
Description |
Prix Unitaire |
Qté ... |
1001 |
ABC |
415 |
TRIANGLE |
12.75 |
50 |
1002 |
ABC |
416 |
CARRÉ |
10.00 |
20 |
1003 |
XYZ |
415 |
TRIANGLE |
12.75 |
75 |
L'idée d'une base de données relationnelle est de répartir les données dans
plusieurs BD ou tables et de créer des connexions, des points communs, des
liens, des relations entre chacune d'elles. Voici comment les variables
pourraient être divisées dans une BD relationnelle.
Facture |
Client |
Vendeur |
Inventaire |
No. Facture |
No. Client |
No. Vendeur |
No. Produit |
No. Produit |
Adresse |
Nom |
Description |
Qté vendue |
Code Postal |
Prénom |
Prix unitaire |
No. Vendeur |
No. téléphone |
No. Ass. Soc. |
Qté disponible |
No. Client |
Personne autorisée |
Date d'embauche |
Qté commandée |
Dans le tableau précédent, la table FACTURE va chercher les informations sur
le client de la table CLIENT par le champ commun NO. CLIENT. Il est inutile de
réécrire les données du client plusieurs fois. On peut aller chercher
l'information grâce à une relation entre ces deux tables: soit par le champ No.
Client. La même chose se produit pour les informations nécessaires pour les
tables VENDEUR et INVENTAIRE par leurs variables communes NO. VENDEUR et NO.
PRODUIT respectivement.
De cette manière, il est inutile de réécrire les données redondantes ou
répétitives. Ceci conserve de l'espace pour d'autres données. Pour les trois
factures de l'exemple, on économise de l'espace et du temps à ne pas avoir à
réécrire les informations sur le client ABC ni la description et le prix
unitaire du produit 415.
Définitions
L'utilisation d'une base de données apporte aussi de nouveaux termes à
comprendre. Voici une liste des termes qui seront utilisés pour toutes les pages
sur les sujets d' Access.
Champ : |
Une information nécessaire sur une personne, une chose
ou un événement. Ex.: couleur, taille, modèle, date, nom, prénom, téléphone,
adresses, description, commentaires etc. |
Enregistrement
: |
Un regroupement de champs qui décrient une personne,
une chose ou un événement. Ex.: nom, prénom, date de naissance, téléphone,
numéro d'assurance sociale ou compagnie, adresse, téléphone, télécopieur,
personne responsable ou département, personne responsable, téléphone.
Le champ téléphone est utilisé de trois manières différentes. Il est soit le
numéro de téléphone d'un employé, d'une personne dans une compagnie ou d'un
département. |
Table: |
Un regroupement d'enregistrements sur un thème un
commun. Ex.: employés, inventaire, client, fournisseurs, véhicules, contacts
etc. |
Base de données : |
Un regroupement de tables, de requêtes, de
formulaires, et de rapports et de programmation qui constitue un système
complet. Ex.: gestion de la facturation, gestion de l'inventaire,
immatriculation des véhicules, carnet de numéro de téléphone, réservations etc.
|
La définition d'une base de données prend maintenant un sens plus
large qu'auparavant. Ce n'est plus juste un fichier qui contient de
l'information utile pour l'utilisateur. Il contient aussi les requêtes, les
formulaires, les états, les macros et les modules pour développer une
"application" ou un "système" qui répond aux besoins spécifiques de
l'utilisateur.
Quelles sont les composantes d'Access?
 Tables :
|
Structure de la table, type de champs et les
informations qui y sont entreposées. |
 Requêtes
:
|
Recherche d'informations qui répond à certains
critères déterminés par l'utilisateur. |
 Formulaire
:
|
Présentation de l'information à l'écran d'une manière
pratique pour l'utilisateur. |
 État :
|
Présentation de l'information sur papier d'une manière
pratique pour l'utilisateur. |
 Macro :
|
Développement de routines pour automatiser certaines
tâches. |
 Modules :
|
Programmation |
Création d'une base de données
Pour vous aider à comprendre la création d'une base de données, cette page va
démontrer les étapes à suivre. Afin d'éviter la répétition du texte de ce site,
il vous sera demandé d'aller lire le texte d'autres pages pour les tables et les relations.
L'exercice va consister à créer une base de données pour la facturation d'une
entreprise.
La première étape de la création d'une base de données est l'analyse.
C'est d'ailleurs probablement l'étape la plus importante. Si vous passez trop
rapidement sur cette étape, vous allez ensuite perdre beaucoup de temps et
d'efforts à refaire ce qui aurait dû être accompli auparavant.
Avant de créer votre base de données, il faut avoir une idée claire de ce que
seront vos besoins pour celle-ci. Il faut préparer une analyse approfondie de
vos besoins. Quelles sont les informations dont vous avez besoin? Ex.: Quelles
informations ai-je besoin sur mes clients, sur mes fournisseurs, sur mon
inventaire, sur mon personnel etc.
Une technique parmi d'autres que vous pouvez utiliser consiste à fonctionner
"à l'envers" (top-down). Songez aux formulaires et aux états dont vous aurez
besoin. Connaissant les résultats dont vous avez besoin, il faut découvrir quels
sont les champs nécessaires pour atteindre ceux-ci. Par exemple, il faut
connaître les quantités vendues et à quel prix unitaire avant de connaître le
total des ventes .
Vous pouvez aussi utiliser la technique "bottom-up". À partir de la base,
vous déterminez toutes les informations qui sont nécessaires pour les requêtes,
les formulaires et les états de votre base de données. Vous pouvez utiliser les
deux techniques pour vous assurer d'avoir toutes les informations nécessaires.
Pour les besoins de l'exercice, prenez quelques instants et écrivez sur une
feuille quels champs que l'on retrouve sur une facture. Essayez de trouver
autant de champs que vous pouvez.
Liste des champs
Voici la liste de champs que l'on peut retrouver une facture.
Date, Numéro de facture, Numéro de client, Adresse de facturation du client,
Ville, Numéro de téléphone, Numéro de télécopieur, Adresse de courriel (courrier
électronique), Adresse de livraison, Personne contact, Conditions de paiement,
Numéro de produit, Description du produit, Prix unitaire du produit, Quantité
achetée, Total pour l'item, sous-total, TPS (Taxe sur le Produits et Services,
7% du total), TVQ (Taxe de vente du Québec, 7,5% du total et de la TPS, TVA en
Europe), Grand total, Escompte, Bon de commande, Numéro du vendeur, Nom du
vendeur ...
Ouf! C'est peut être un peu plus que vous vous attentiez.
La seconde étape: regrouper les informations dans
des tables.
Il faut ensuite regrouper en entités toutes ces informations (champs) dans
une table ou un "thème" en commun. Ex.: Est-ce que le champ "Escompte" ou
"Conditions de paiement" ira dans l'entité (table) "Facture" ou avec "Client"?
Je vais premièrement vous démontrer ma technique pour regrouper les champs
dans des tables et pour déterminer les relations entre ces tables. Par après, on
discutera de la technique de la normalisation. Ma technique est un peu plus
simpliste et demande un peu d'expérience. L'utilisation de la technique de la
normalisation est une manière difficile d'accomplir à accomplir et à réaliser.
Mais elle est infaillible lorsqu'on la comprend et on l'applique correctement.
Ces deux manières veulent atteindre le même résultat : regrouper des champs dans
des tables de manière la plus efficiente possible. Premièrement ... ma
technique.
Le concept est de distribuer les champs dans le plus grand nombre de tables
possibles. Mais il y a certaines règles à suivre:
Regroupement des champs dans des tables qui peuvent être
reliées.
Pas de dédoublement de champs, sauf pour les champs en commun.
Pas de
dédoublement d'entrée d'information.
Pas de champs calculables dont on peut
avoir le résultat avec les informations des autres champs des tables. Ex.: Total
= Qté * Prix unitaire
Il faut regrouper les champs dans des tables. Quels sont les champs que l'on
peut regrouper ensemble? Pour vous aider dans cette tâche, basez-vous sur des
éléments de la vie de tous les jours, du concret. Cela aide aussi de connaître
les processus de l'entreprise. Quelles sont les opérations accomplies? Qui
utilise quelle information? Pour la facture, on retrouve des éléments qui
distinguent la facture, le client, les produits et le vendeur. Ce sont les
quatre tables qui seront utilisées.
S'assurer que les champs sont dans la bonne table. Qu'il n'y a pas de tables
cachées à l'intérieur des autres.
À l'exception des champs en commun qui servent à "relier" les tables, un
champ ne devrait pas se retrouver dans plusieurs tables.
Déterminer les clés primaires
Une clé primaire est un champ, ou une série de champs, qui permet de
différencier un enregistrement des autres. Par exemple, bien qu'il puisse avoir
plusieurs factures avec la même date, la même quantité achetée, au même client
ou avec le même vendeur, il n'y aura pas deux factures avec le même numéro de
facture. Une clé primaire n'est pas obligatoire pour une table. Elle le
devient lorsque vous voulez relier deux tables. L'une des tables doit avoir une
clé primaire.
Essayez de déterminer quel champ serait approprié pour une clé primaire pour
la table Employés. Certainement pas le champ sexe. À moins qu'il y ait
seulement un homme et une femme dans l'entreprise. Cela limite un peu la
croissance de l'entreprise! Fumeur? Permanence? Même chose. Il y a seulement
deux valeurs possibles (H ou F, Oui ou Non ...). Puisqu'on ne peut pas entrer
deux fois la même valeur dans une clé primaire, ceux-ci ne sont pas de bon
choix.
Il est possible d'utiliser le champ Nom de famille aussi longtemps que
deux personnes dans l'entreprise n'aient pas le même nom. Ensuite, il est
toujours possible de créer une clé primaire composée de deux champs: nom de
famille et prénom. Cette clé va fonctionner correctement jusqu'à ce
que deux employés aient le même prénom et le même nom. Pour régler ce problème,
il est possible de créer une clé primaire composée du nom de famille, du
prénom et de la date de naissance. Cette clé primaire va
fonctionner correctement jusqu'à ce que ... Cela peut continuer longtemps.
Rendu à un certain point, vous verrez qu'il est préférable d'avoir un champ
nommé Numéro d'employé ou Numéro d'assurance sociale pour distinguer chacun des
enregistrements de la table. Mais il y a des occasions où il est nécessaire
d'avoir une clé primaire qui est composée de plusieurs champs. L'une de ces
situations sera expliquée un peu plus loin sur cette page.
Prenez quelques instants pour essayer de déterminer quels champs dans la
table seraient appropriés pour être la clé primaire ou être dans la clé
primaire. L'explication pour appliquer la clé primaire sur un
ou plusieurs champs de la table est sur la page Web suivante sur les tables.
Déterminer les relations entre les tables
Pour qu'une relation soit possible entre deux tables, il faut:
2 tables (ou
requêtes ou une combinaison des deux)
1 champ en commun dans chacune des
tables.
Même
type de champ (Texte avec texte, numérique avec numérique... sauf exception de
numéroauto avec numérique)
Même longueur (Pas un champ long de 15 caractères
avec un autre long de 50 caractères !)
Même genre d'information (Ex.: Code d'inventaire
avec des codes d'inventaires, NAS avec NAS ...)
Vous n'êtes pas obligé de relier toutes les tables l'une à l'autre. Il est
possible d'accéder à l'information tant que les tables soient reliées
directement ou indirectement en elles. Vous trouverez plus de détails sur
la page des relations.
Déterminer les types de relations
(cardinalité)
Il existe trois types de relations : 1 à 1, 1 à plusieurs et plusieurs à
plusieurs. Afin de ne pas répéter le texte, vous trouverez toutes les
informations nécessaires pour déterminer le type de relation et comment créer
des relations sur la page sur les relations.
Pour l'exemple qui est utilisé sur ce site, voici comment relier les tables
dont les informations se retrouvent sur une facture.
L'image ci-dessus démontre la liste des tables avec les champs qui les
composent. De plus, les lignes indiquent les relations entre les tables. La
relation de types plusieurs à plusieurs requiert une table intermédiaire
composée, au minimum de la clé primaire des deux tables à relier. C'est la
raison d'être de la table Transition Fact-Inv qui pourrait tout aussi
s'appeler Items de la facture.
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.
Il peut arriver par accident que vous retirez la disquette sur laquelle se
retrouve votre base de données avant de l'avoir fermé dans Access. Ou, la base
de données s'est mal sauvegardée sur la disquette. Ceci peut endommager une base
de données. Access vous offre une manière de réparer une base de données
endommagée. La procédure se fait en deux étapes: réparer et compacter la base de
données. Le premier isole le problème et le second le retire de la base de
données.
Ouvrez le programme Access mais n'ouvrez aucune base de
données.
Du menu Outils, sélectionnez l'option Utilitaires de base
de données.
Sélectionnez l'option Réparer une base de données.
Sélectionnez
le fichier à réparer sur le disque dur ou la disquette.
Appuyez sur le bouton Réparer.
Access va prendre quelques instants pour réparer votre base de données. Si
tout s'est bien déroulé, Access vous affiche ensuite un message indiquant que la
base de données a été réparée avec succès.
Compacter une base de données
La dernière étape a isolé le problème. Mais celui-ci est encore dans la base
de données. L'opération de compacter va non seulement retirer les
enregistrements, les tables, les requêtes et les états que vous avez supprimés
de votre base de données, mais aussi le problème. Bien qu'ils ne soient plus
accessibles, ils sont encore dans le fichier de la base de données.
Ouvrez le programme Access mais n'ouvrez aucune base de
données.
Du menu Outils, sélectionnez l'option Utilitaires de base
de données.
Sélectionnez l'option Compacter une base de données.
Sélectionnez
le fichier à compacter sur le disque dur ou la disquette.
Appuyez sur le bouton Compacter.
L'opération pour compacter une base de données consiste à en créer une
nouvelle avec seulement les éléments qui sont encore utiles. Access va ensuite
vous demander quel est le nom de la nouvelle base de données.
Donnez un nom à la nouvelle base de données de votre choix dans la case
"Nom du fichier".
Appuyez sur la touche Entrée
ou le bouton Enregistrer.
Malgré cette procédure, il est toujours possible que la base de données soit
trop endommagée pour être réparée. C'est pour cette raison, autant pour les
bases de données d'Access que pour tout autre document, que vous devriez avoir
une copie de sécurité de vos documents. N'oubliez pas qu'avec Access, il est
impossible de faire une copie de sécurité pendant que la base de données est
ouverte. Vous pouvez copier le fichier de la base de données seulement après
avoir quitté Access.
Note au lecteur
Ceci est la première page d'Access sur ce site. Il y a plusieurs autres pages
sur Access qui couvrent des thèmes précis. Appuyez sur le bouton suivant de la barre d'outils pour voir la suite. Ou cliquez ici pour revoir la liste des thèmes couverts
mentionnée au début de cette page.
http://www.cathyastuce.com Cathy
Astuces, site très intéressant et complet sur plusieurs logiciels incluant
Access et VBA
http://enseignement.insset.u-picardie.fr/deug/ti/cours/access/
Cours sur Access complet.
http://perso.wanadoo.fr/jeanmarc.stoeffler/access/IndexAccess.htm
Offert par Jean-Marc Stoeffler
http://www.mvps.org/accessfr/
Quelques trucs et astuces sur Access
| 
