Bonsoir Elsa,
Je pense que pour celui qui n’est pas rompu à VBA (Visual Basic for Applications) certaines formules peuvent paraître magiques, sinon hermétiques (remplacer alors le chocolat par de l’aspirine)...
Les macros, ça passe après la modélisation. Cela dit, connaissez-vous VBA ? SQL ? Avez-vous déjà utilisé des formulaires ACCESS ? (ou plus simplement, que connaissez-vous d’ACCESS ?) Avez-vous utilisé (en développement) d’autres SGBD qu’ACCESS ?
Pourquoi revoir à la baisse ? S’il le faut, on vous aidera à mettre tout ça œuvre. En compagnie de gens sympathiques et toujours prêts à rendre service comme Claude Leloup et f-leb, on devrait s’en sortir.
La modélisation est achevée quand elle répond pleinement au besoin fonctionnel, c'est-à-dire quand on sait que la base de données qui en sera dérivée contiendra tous les éléments permettant de répondre aux questions (exprimées en bon français, ça suffira à ce stade) qu’on est susceptible de poser. La base de données est la réalisation physique du modèle, lequel est une abstraction, disons la définition de la machine abstraite dédiée à ses utilisateurs). Les besoins fonctionnels doivent être recensés dans le dossier de conception où figure le modèle. Considérons ces besoins comme des axiomes et le dossier comme leur corpus.
Bien entendu, un modèle n’est pas figé et doit pouvoir évoluer en fonction des besoins nouveaux des utilisateurs. Cela suppose que la fondation théorique soit robuste et saine...
Accessoirement, il est très vivement recommandé que la structure des tables réponde à ce qu’on appelle la forme normale de Boyce-Codd (BCNF), mais je ne voudrais pas vous traumatiser avec cette histoire qui a trait en fait aux redondances...
Non ! Ces choses ne font pas partie des axiomes. Une requête n’est qu’un moyen langagier de consulter ou mettre à jour la base de données (je note en passant que ce qu’on appelle requête en ACCESS correspond à ce qu’on appelle vue dans la norme SQL et dans les SGBDR en général, et une vue n’est pas un axiome mais un théorème). Si une requête (au sens instruction SQL) n’est pas performante, on la réécrira, on mettra en place les index qui vont bien, etc. Si un formulaire n’est pas beau, ou est incomplet, on le retravaillera sans avoir besoin de modifier le corpus ! Un état n’est qu’un résultat, mais là encore on devra évidemment s’assurer que le corpus est complet.
Les relations entre tables relèvent de l’intégrité des données, plus précisément de l’intégrité référentielle : une commande ne doit pas être orpheline, elle doit référencer un fournisseur présent dans la table FOURNISSEUR, sinon on est très mal. Même chose, pour les lignes de commande vis à vis des commandes et des références des fournisseurs, etc.
L’intégrité référentielle joue un rôle capital dans la robustesse et la crédibilité de la base de données. Cela dit, si les relations relèvent du modèle et y sont donc représentées, au stade de la réalisation elles doivent faire l’objet de l’intégrité référentielle, sous-traitée au SGBD (clés étrangères référençant les clés candidates pertinentes, cf. les images ci-dessous).
On est évidemment au stade du comment, cet aspect des choses ne relève pas du modèle, mais de la réalisation.
Manifestement il s’agit de la même chose. En fait, un trigger est un programme développé par nos soins, associé à une table, auquel le SGBD est prié de passer le relais quand se produit un événement (ajout, modification, suppression de lignes dans la table en question). Quand le trigger a fait ce qu’il avait à faire, il rend la main au SGBD. Ce qui est ballot avec ACCESS, c’est que pour les triggers, le jeu d’instructions est [beaucoup trop] réduit, je ne sais pas ce que leurs parents avaient dans le crâne pour nous fournir quelque chose d’aussi indigent (et contraignant dans la mise en œuvre)... En passant je rappelle ce que j’avais écrit précédemment (j’ai signalé son bogue à M. Microsoft, mais j’attends encore une réponse qui ne viendra sans doute jamais...) :
Allons-y avec calme et décontraction.
Etablissons l’association entre COMMANDE et LIGNE_COMMANDE, en nous situant dans les conditions initiales de température et de pression : COMMANDE et LIGNE_COMMANDE sont débranchées :
L’association doit être faite entre la clé primaire PKc = {FournisseurId, CommandeId} de la table COMMANDE et la paire FKg = {FournisseurId, CommandeId} de la table LIGNE_COMMANDE, paire considérée comme clé étrangère (chaque valeur de FKg doit d’abord être une valeur de PKc, intégrité référentielle oblige).
Pour brancher PKc et FKg, techniquement on sélectionne la paire {FournisseurId, CommandeId} de la table COMMANDE, puis on fait un « drag/drop » vers le cartouche intérieur de la table LIGNE_COMMANDE, ce qui provoque l’ouverture de la fenêtre « Edit Relationship » :
Reste à préciser à ACCESS de quoi est faite la clé étrangère FKg. On utilise la liste déroulante qui va bien (« Related Table/Query ») :
On met en correspondance les deux paires d’attributs (sans oublier de cocher la case « Enforce Referential Integrity ») :
Et quand on ferme la fenêtre « Edit Relationship » (bouton « Create), ô magie ! Les liens sont là :
Le principe est le même pour établir les associations entre FOURNISSEUR_REFERENCE et LIGNE_COMMANDE d’une part, et LIGNE_COMMANDE et OPTIQUE d’autre part.
Affaire à suivre, préparez le thé et l’aspirine (pour moi ça sera un Lagavulin bien tourbé)...
Partager