Access – Les Bases

CONCEPTION

C’est quoi ? A quoi ça sert ?
La conception de la base est l’étape fondamentale.
Si nous voulons reprendre l’exemple de la construction de la maison, il s’agit tout simplement de la fabrication des plans ! Si les plans sont vite faits, sans concertation avec les différents intervenants, sans prendre en considération le terrain, etc. il parait inconcevable que la maison soit bâtie sans soucis !
En fait, le plan va être réalisé par un architecte, basé sur une étude du terrain réalisée par un géomètre, en accord avec la mairie, les bâtiments de France (si nécessaire) , etc.
De même, pour réaliser la conception de votre base de données, vous allez devoir prendre des informations auprès des différentes sources concernées, auprès des utilisateurs, des décideurs, faire des réunions régulières pour savoir si ce que vous concevez est bien en adéquation avec la réalité … bref, c’est un travail qui demandera un temps certain. Ne vous précipitez donc pas dans cette étape de la réalisation de votre base de données. Une fois la conception faite, le reste ressemblera à une partie de plaisir.

Les principes fondamentaux
Repartons de notre cas précédent, réalisé sur Excel, qui nous posait quelques soucis : celui des commandes.
L’idée est de réussir à rassembler les informations, comme sur des fiches types.
Par exemple, un client est un client. Quel que soit le client, nous allons systématiquement avoir besoin d’informations qui sont propres à chaque client, comme l’adresse, le nom, le téléphone, etc. Nous pouvons gérer ce client, l’enregistrer sur une fiche. D’ailleurs, ne parle-t-on pas de fiche client, et même, de fichier client.
Nous pourrions même imaginer ‘préformater’ des feuilles ainsi, nous n’aurions plus qu’à les remplir et à les mettre dans notre fameux ‘fichier client’.
En fait, cette ‘fiche préformatée’, on pourrait l’appeler ‘entité’. Tout le jeu va donc être, maintenant, de répartir les données que nous avons dans notre tableau de départ, et de les rassembler par ‘fiche type’ et de faire autant de ‘fiche type’ ou ‘entité’ que nous avons d’éléments distincts à gérer. C’est le point de départ du Modèle Entité-Association.

Le Modèle Entité-Association
Le modèle entité-association est un modèle, un dessin qui représente les différents éléments (entités) et leurs interactions (associations) , dans le système qui nous intéresse.
Cette définition est peut-être un peu vague. Aussi, je vous propose d’avancer pas à pas dans la méthode rapide que je vous propose.
a. Définition des Entités
Sur notre problématique, nous avons repéré trois entités : Client, Commande et Produit.
Nous pourrions les dessiner ainsi :
Chose importante, dans chaque entité, nous devons créer une zone qui contiendra une valeur obligatoire et unique à travers toutes les fiches tirées de cette entité. On appelle cela un identifiant. Voici la définition la plus correcte de l’Identifiant : « L’identifiant assure l’unicité de l’occurrence (de la fiche remplie) de l’entité ». Dans le cas du client, ce sera le N° de client. Pour la commande, le N° de Commande. Pour les produits, la référence produit fera l’affaire (un code barre par exemple). Après avoir ajouté nos identifiants, nous obtenons ceci (vous noterez la convention qui consiste à souligner l’Identifiant) :
Maintenant, on va pouvoir ajouter toutes les informations (on les appelle ‘attributs’) que l’on souhaite enregistrer dans chaque fiche. Le résultat obtenu doit ressembler à ceci :
Nous avons maintenant une série de fiches type, et nous sommes capables, dans chaque fiche, de stocker toute l’information qui nous intéresse.
De plus, comme les identifiants sont uniques, on peut très facilement retrouver un client, une commande ou un produit, simplement par son identifiant. Enfin, rien ne nous empêchera d’avoir deux clients ayant le même nom mais étant localisés dans des villes différentes par exemple. Nous ne risquons pas de les mélanger, puisqu’ils ont des identifiants différents.
Cependant rien ne nous permet de déterminer ce qui se passe entre ces fiches type. Par exemple, si nous lisons bien la fiche d’une commande, nous n’avons aucun moyen de savoir quel client l’a passée. Nous avons donc un peu de mal à exploiter les fiches en l’état actuel des choses. Il va falloir déterminer les actions se passant entre les fiches, et savoir en garder trace. C’est tout l’objet de la deuxième étape.