Discussion :

[fsmrel]

Bien, j'attends le nouveau digramme...

[fsmrel]

Bonsoir,

Le message #15 contenait une image qui n’était pas la bonne concernant le diagramme ACCESS des personnes. J’ai rectifié le tir.

Sinon, comment se portent les optiques ?

[Femtozaza]

Bonjour,

Merci pour cette correction, je pense que l'idée illustrée était tout aussi claire dans l'autre image si mes souvenirs sont bons..

Les optiques vont bien et je suis désolée d'avoir tardé à vous donner des nouvelles, mais cette création de BDD n'est pas la priorité de mes activités et je n'ai pas eu le temps de m'en occuper avant aujourd'hui.

J'ai complètement pompé sur le modèle proposé dans un post précédent (n° -Merci encore) mais je me heurte à un problème:
Comment faire des clés multiples sous access? (Clé primaire et clé alternative)



Comme vous le voyez sans-doute, j'ai finalement laissé les caractéristiques dans la Table Fournisseur_Références (j'en ai mis quelques-unes pour illustrer l'idée).
Et une autre question: la Table Ligne_Commande n'a pas d'Id propre dans le modèle que j'ai pompé sans scrupule, c'est normal ou c'est une omission? (ou alors j'ai encore loupé un truc?)

J'essaye de me retenir encore mais les questions "Comment" ont tendance à envahir ma réflexion..

[fsmrel]

Bonsoir,

Comment faire des clés multiples sous Access?

1) Prenons le cas par exemple de la table LIGNE_COMMANDE. Pour en fabriquer la clé primaire : un clic gauche sur le nom de la table, puis un clic droit sur le choix qui va bien (« Design View » ou son équivalent en français si ça n’est pas le même terme) :



Quand les colonnes sont affichées, vous sélectionnez celles qui sont concernées (FournisseurId, CommandeId, OptiqueCat) et vous cliquez sur l’onglet DESIGN :



Dans un 2e temps, il ne vous reste plus qu’à cliquez sur l’icône « Primary key » et les petites clés jaunâtres apparaissent à côté du nom des colonnes :





2) Pour les clés alternatives, il faut passer par une requête SQL : loin des lampions et flonflons décorant les fenêtres d’ACCESS, on va devoir saisir du texte.

Supposons par exemple que le quadruplet {FournisseurId, CommandeId, OptiqueCatId, Etat} doive faire l’objet d’une clé alternative pour la table OPTIQUE. Vous devez en passer par la création d’une requête SQL, en slalomant d’abord parmi un tas de fenêtres... On commence :

Onglet CREATE > Query Design :




Vous avez alors droit à une fenêtre du genre de celle-ci, et vous cliquez sur Close :




Pour fermer, ça ferme !




Vous faites un clic droit au hasard dans le « bleu », apparaît alors une liste de choix, suite à quoi vous faites un clic gauche sur « SQL View » :




Enfin un os SQL à ronger !




Vous remplacez le texte bien maigrelet proposé par une formule cabalistique :


Ce qui se lit :

M. ACCESS, merci de créer (« ADD ») la contrainte OPTIQUE_AK et de l'attacher à la table OPTIQUE, c’est une contrainte d’unicité (du fait du mot magique « UNIQUE »), il faut interdire les doublons pour le quadruplet {FournisseurId, CommandeId, OptiqueId, Etat}.

Vous fermez cette fenêtre nommée ici « Query2 », et la renommez par exemple en « CREATE_OPTIQUE_AK1 » :




Et voilà. Si on fait « OK » et si ACCESS n’a pas trouvé d’erreur de syntaxe ou autre, plus moyen de créer des doublons pour le quadruplet de colonnes.

On peut aussi supprimer une contrainte, on remplace alors « ADD » par « DROP » :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

 ALTER TABLE  OPTIQUE DROP CONSTRAINT OPTIQUE_AK ;

Comment ça, tout ça c’est tordu ?

Soit. Mais si la clé alternative ne comporte qu’une colonne, on palliera plus simplement au moyen d’un index de type UNIQUE. Prenons le cas de la colonne OptiqueNumero de la table OPTIQUE :

1) Clic droit sur le nom de la table dans le volet qui va bien, et choisir l’option « Design view » :




On sélectionne la colonne OptiqueNumero et on valorise la propriété « Indexed » à « Yes (No Duplicates) » :







Bonne journée !

[f-leb]

Hello la compagnie,

2) Pour les clés alternatives, il faut passer par une requête SQL : loin des lampions et flonflons décorant les fenêtres d’ACCESS, on va devoir saisir du texte.

Supposons par exemple que le quadruplet {FournisseurId, CommandeId, OptiqueCatId, Etat} doive faire l’objet d’une clé alternative pour la table OPTIQUE. Vous devez en passer par la création d’une requête SQL, en slalomant d’abord parmi un tas de fenêtres...

En fait il me semble que le bouton [index] permet de créer les clés alternatives sans passer par SQL :



Et v'là le travail

[fsmrel]

Trop fort Fabien !

Il est vrai qu'en tant que vieux sqleux, bien des fonctionnalités d'ACCESS (que je ne pratique que modérément) m'échappent...

Ta remarque est très juste, je vote pour toi !


Une précision quand même : une clé alternative est un concept relationnel. Un index est autre chose, il se situe au niveau physique (donc même pas traité dans la norme SQL) mais permet lui aussi de garantir le principe d'unicité.

[f-leb]

On dirait pourtant que tu as troqué ton Access 2000-2003 pour une version plus récente. Tu vas pouvoir nous faire profiter de tes connaissances sur les nouveautés d'Access

[fsmrel]

Heu... J'ai essayé les triggers (auxquels tu fais peut-être allusion). Avec SQL Server, DB2 et compagnie on s'en sort (assez ^^) facilement, mais avec ACCESS c'est un truc à vous rendre schizo, et en plus ça m’a tout l’air d’être bogué (au moins pour les triggers « Before »). Par exemple, dans le cas de l'insert, pour la ligne en cours, demandons-lui la valeur de la colonne FournisseurId de la table FOURNISSEUR : si {FournisseurId} est clé primaire, il ne renvoie rien (null), si {FournisseurId} n'est plus clé primaire, il fournit la valeur attendue... (Le problème ne se pose pas si on fait un update.) Faudra que je signale ça à M. Microsoft, à moins qu'un caïd du sérail comme Tofalu puisse nous éclairer à ce sujet.

[fsmrel]

Intégrité référentielle : une précision au sujet des clés alternatives.


Habituellement, la cible d’une clé étrangère est une clé primaire, mais ça peut aussi être une clé alternative, conformément à la théorie relationnelle (selon laquelle, à juste titre, on ne fait pas de distinguo entre ces deux types de clés, il n’y a que des clés candidates).


A titre d’exemple :

Si on a préalablement défini un index de type UNIQUE pour la colonne T1code de la table Table1, alors on peut établir une contrainte référentielle ayant Table1 pour cible :

[Femtozaza]

Hou lala merci pour tout ça c'est fort intéressant.
Je vais sans doute paraître nunuche mais je n'arrive pas à voir ce que je dois faire après toutes ces informations.
Je réfléchis donc en écrivant si vous me permettez..

Une clé primaire permet d'identifier chaque enregistrement de façon unique c'est ça? Donc d'après ce qui est expliqué quelques posts plus haut, la clé primaire peut aussi être un groupe d'attributs? (Excusez moi si je me trompe dans les termes, je ne maîtrise pas encore bien le vocabulaire-on part de loin..)
Mais je comprends aussi qu'il vaut mieux qu'une clé primaire ne soit pas descriptive de l'enregistrement.

(J'ai tout bon jusque là?)

D'où (c'est un peu la question) l'intérêt des clés alternatives, c'est ça? Qui du coup seront "descriptives" mais permettront de créer des relations entre tables?
Après l'unicité permet d'éviter des doublons ou de faire une erreur d'enregistrement ou de se retrouver dans la panade en cas de modification... C'est ça?

Si j'ai tout bon là on pourra continuer. Je suis désolée mais tellement de concept nouveaux pour moi. et loin de ce que je fais au quotidien..
Sinon je dis: "crotte de biquette!"

J'en profite pour poser une seconde question directement (ça m'évite de chercher): je pars en Inde prochainement et je me demandais si je pourrai pas en profiter pour lire un peu sur le sujet. Auriez-vous un livre a recommander pour une néophyte surtout pour la modélisation déjà. Merci d'avance

[fsmrel]

Bonsoir Femtozaza,

Je n'arrive pas à voir ce que je dois faire après toutes ces informations.

Après un tel tir de barrage, c’est un peu normal, mais tout ça s’arrangera avec le temps...

Une clé primaire permet d'identifier chaque enregistrement de façon unique c'est ça? Donc d'après ce qui est expliqué quelques posts plus haut, la clé primaire peut aussi être un groupe d'attributs?

La clé primaire est un cas particulier de ce qu’on appelle une clé candidate (clé en abrégé).

Appelons « en-tête » (heading) la liste des noms des colonnes d’une table. (En relationnel pur, on n’utilise pas le terme colonne qui est propre à SQL, mais attribut, cela dit je les utilise tous les deux quand je fais du SQL, mais je ne pense pas qu’on m’en voudra... Quand à Access, il utilise le terme champ, mais c’est Access...)

Par exemple, par référence à la représentation ci-dessous, la table COMMANDE a pour en-tête {FournisseurId, CommandeId, CommandeNumero, CommandeDate}. J’ai mis cette liste de noms entre accolades, car en fait c’est un ensemble au sens de la théorie des ensembles.



Définition :

Soit une table T et K un sous-ensemble (non strict) d’éléments de l’en-tête H de T. K est clé candidate (clé en abrégé) si et seulement si K vérifie les deux propriétés suivantes :

Unicité : Deux lignes distinctes de T ne peuvent avoir simultanément même valeur de K.
Irréductibilité (minimalité) : il n’existe pas X strictement inclus dans K tel que X vérifie aussi la propriété d’unicité.

Ainsi, dans le cas de la table COMMANDE, le singleton K = {FournisseurId} n’est pas clé candidate car pour FournisseurId = 1, on a trois lignes ayant même valeur de K.
Il en va de même pour le singleton {CommandeId} et le singleton {CommandeDate}. Par contre, le singleton {CommandeNumero} est clé candidate, parce qu’on a décidé (règle de gestion imposée par l’utilisateur) que deux commandes ne pourraient jamais avoir le même numéro.

Qu’en est-il de la paire {FournisseurId, CommandeId} ? C’est nous, en tant que concepteurs de la base de données, qui avons décidé que CommandeId était un séquenceur des commandes relativement au fournisseur : on ne trouvera jamais deux fois la valeur <i, j> pour cette paire, laquelle constitue donc une clé candidate.

Qu’en est-il de la paire {FournisseurId, CommandeDate} ? Dans la mesure où l’on peut passer dans la journée plus d’une commande au même fournisseur, cette paire ne peut pas être clé candidate.

Qu’en est-il de la paire {CommandeNumero, CommandeDate} ? Elle respecte la règle d’unicité, mais elle contient le sous-ensemble strict {CommandeNumero} qui est déjà clé candidate, donc cette paire ne respecte pas la règle d’irréductibilité : ça n’est pas une clé candidate. Même chose pour les triplet {FournisseurId, CommandeId, CommandeDate} et {FournisseurId, CommandeId, CommandeNumero}, et a fortiori pour le quadruplet {FournisseurId, CommandeId, CommandeNumero, CommandeDate}.

Ainsi, on deux clés candidates, {CommandeNumero} et {FournisseurId, CommandeId}. Les autres sous-ensembles qui respectent la règle d’unicité constituent ce qu’on appelle des surclés :

Définition

Une surclé (superkey) est un sous-ensemble de colonnes K de l’en-tête H d’une table T, respectant la contrainte d’unicité imposée aux clés candidates, mais facultativement celle d’irréductibilité.

Ainsi, une clé candidate est une surclé particulière, respectant la contrainte d’irréductibilité.

La paire {FournisseurId, CommandeDate} est une surclé, même chose pour l’ensemble des triplets et pour le quadruplet.

Qu’en est-il de la clé primaire ?

Du point de vue de la théorie relationnelle, ce concept n’existe plus, mais il survit dans le monde SQL. Disons que si on a mis en évidence plusieurs clés candidates pour une table, on procédera à l’élection de Miss Clé primaire. L’usage est de retenir comme critères principaux l’invariance et l'absence de signification de cette clé (revoyez ce qu’à écrit Yves Tabourier), car à défaut, si elle subit des modifications et si elle sert de référence pour une autre table (table LIGNE_COMMANDE dans notre exemple) , ça peut pénaliser (un peu, beaucoup, etc.) les performances. De la sorte, si l’on part du principe que l’utilisateur peut avoir envie de modifier un numéro de commande, même pas grave, ça ne touche que la table COMMANDE. Concernant les colonnes FournisseurId et CommandeId, elles sont dépourvues de toute signification, invariantes par construction : la paire {FournisseurId, CommandeId} a toutes les qualités requises pour être élue Miss clé primaire. Sa dauphine {CommandeNumero} devient de facto clé alternative (alternate key).

J'ai tout bon jusque là?

Ça manque un peu de rigueur, mais sur le fond c'est déjà pas trop mal

N.B. Ce que vous appelez enregistrement vient du fond des âges (j’employais ce terme dans les années soixante (on utilisait alors des cartes perforées, des bandes magnétiques, mais pas de disques...), et repris manifestement par Access). En SQL on utilise le terme ligne, et en relationnel le terme tuple (ou n-uplet, n-tuple).


Je reviendrai sur la littérature que l’on peut vous recommander.

[Femtozaza]

Après un tel tir de barrage, c’est un peu normal, mais tout ça s’arrangera avec le temps...

Merci beaucoup pour ces encouragements!


J'ai tout compris sur les clé candidate (unicité et irréductibilité) et miss clé primaire. Même s'il faut sans doute du temps pour maîtriser leur manipulation (et pas se gourer) mais je vais faire l'exercice sur mon modèle (pour être sûre).

[fsmrel]

je vais faire l'exercice sur mon modèle (pour être sûre).

Voilà une bonne résolution, aussi je vote pour vous.

En ce qui concerne la littérature, pour le niveau conceptuel, je vous recommande l'ouvrage de Michel Diviné : Parlez-vous Merise ?, gratuit et téléchargeable (Merci Michel !) Par contre évitez la partie où il traite des bases de données et des tables, ça n’est pas son domaine et il s’égare. Téléchargez aussi l’ouvrage du Professeur Georges Gardarin, une grande pointure des bases de données.

Sinon, pour le niveau conceptuel (disons Merise), l’ouvrage les plus complet est celui de Nanci et Espinasse : Ingénierie des systèmes d'information : Merise; 2eme génération , mais il semble ne rester que quelques exemplaires en vente de l’avant dernière édition (environ 50 euros).

je pars en Inde prochainement

A ce propos, je ne peux m’empêcher de citer Francis Blanche avec son fameux raccourci (qui ne vous vise pas !) :

« Brahmâ la guerre et Vishnou la paix ! »

[Femtozaza]

Me revoilà!

Tout d'abord, merci pour les ouvrages proposés, j'irai faire un tour à la bibliothèque voir si je ne trouve pas celui qui est rare et je téléchargerai les autres.

Donc j'ai rassemblé mes idées pour essayer de faire l'exercice promis... Mais je ne suis pas très sûre de moi. Je repars sur les même éléments que ma dernière proposition.

Donc voici mes clé candidates pour chaque table:

• FOURNISSEUR: {FournisseurID}, j'ai supposé qu'il n'était pas impossible que plusieurs fournisseurs aient le même nom (même si à mon niveau je pense que c'est fort improbable)
  
• COMMANDE: {CommandeNumero}, {CommandeId,FournisseurID} je n'en ai pas vu d'autres que celui que tu avais proposé dans ton explication des clés candidates
  
• FOURNISSEUR_REFERENCES: {RefId}, {RefFournisseur, FournisseurId}
  
• OPTIQUE: {OptiqueId}, {OptiqueNum}
  
• LIGNE_COMMANDE: {FournisseurId, CommandeId, RefId}

Alors j'ai oublié des choses? J'ai mis des candidates qui n'en étaient pas?

[fsmrel]

Revoilà Elsa !

Voici mes clé candidates pour chaque table :

• FOURNISSEUR: {FournisseurID}, j'ai supposé qu'il n'était pas impossible que plusieurs fournisseurs aient le même nom (même si à mon niveau je pense que c'est fort improbable)
  
• COMMANDE: {CommandeNumero}, {CommandeId,FournisseurID} je n'en ai pas vu d'autres que celui que tu avais proposé dans ton explication des clés candidates
  
• FOURNISSEUR_REFERENCES: {RefId}, {RefFournisseur, FournisseurId}
  
• OPTIQUE: {OptiqueId}, {OptiqueNum}
  
• LIGNE_COMMANDE: {FournisseurId, CommandeId, RefId}

Commentaires :

— Table OPTIQUE : D’accord.

— Table FOURNISSEUR : de fait, définir une clé candidate pour le nom interdirait que deux fournisseurs portent le même nom, ce qui ne serait pas très pertinent... Par contre, deux fournisseurs peuvent-ils avoir le même numéro de téléphone ? La même adresse de courriel ?

— Table COMMANDE : c’est bon. Une remarque en passant : du point de vue théorique, une clé est un ensemble, donc qu’elle soit représentée sous la forme {CommandeId, FournisseurID} ou sous la forme {FournisseurID, CommandeId}, peu importe, c’est blanc bonnet et bonnet blanc. En revanche, sous le capot, au niveau physique, cette clé fera l’objet d’un index, et pour la performance d’exécution des requêtes (qui, par exemple, rechercheront toutes les commandes d’un fournisseur donné), l’ordre des attributs est important, aussi est-il préférable dans ce cas-là d’opter pour la représentation {FournisseurID, CommandeId}.

— Table LIGNE_COMMANDE : c’est bon, à condition que RefId corresponde à ce que j’ai appelé OptiqueCatId (cf. messages 9 et 24).

— FOURNISSEUR_REFERENCES : il semble qu’il y ait un hiatus (incidemment, prononcer « un niatus » ^^) car, par référence à ce que je viens d’écrire pour la table LIGNE_COMMANDE, RefId (OptiqueCatId chez moi) sert à numéroter les références relativement au fournisseur, tandis que RefFournisseur (OptiqueReference chez moi) représente alors la référence « officielle » et fait l’objet d’une clé (alternative) :



Autrement dit, en reprenant les noms que vous avez donnés aux attributs, je verrais les clés suivantes : {FournisseurId, RefId} et {RefFournisseur}. Sommes-nous en phase ?

Alors j'ai oublié des choses? J'ai mis des candidates qui n'en étaient pas?

Aux remarques près que j’ai faites, c’est un début encourageant, qui mérite donc un vote positif.

[Femtozaza]

Je suis assez fière de moi, après une conférence en Inde, réussir à rassembler mes idées n'était pas gagné ^^ (J'n'ai pas vu Brahma, mais j'ai vu Vishnou (en statue mais bon,...) , l'espoir est permis)

Donc pour ce qui est des FOURNISSEURs, effectivement il ne peuvent pas avoir la même adresse, ni la même adresse mail (je pense qu'on pourrai aussi dire qu'il est fort peu probable qu'ils aient le même nom de contact mais il ne vaut mieux pas prendre de risque
De fait je peux ajouter les clés candidates: {FournisseurNom, FournisseurTel}, {FournisseurNom, FournisseurMail}, {FournisseurNom, ContactTel} et {FournisseurNom, ContactMail}.

Ensuite RefID était effectivement l'équivalent de votre OptiqueCatId.

Effectivement si l'on considère que RefId est relatif au fournisseur (ce qui me semble une excellente idée a priori encore que je ne sais pas trop encore comment on va utiliser ceci ensuite), je comprends les clés candidates proposées (en supposant que 2 fournisseurs n'utilisent pas les même références dans leur catalogue, ce que je n'ai jamais vu il faut le dire).

Donc je crois que nous sommes en phase.
Je suppose qu'une fois que j'ai mes clé candidate il va falloir que j'élise Miss clé primaire pour chaque table?

[fsmrel]

Hello Elsa !

J'n'ai pas vu Brahma, mais j'ai vu Vishnou

Lui avez-vous exposé le problème des clés candidates ? Il doit savoir pluri-manipuler ça (tout du moins un de ses avatars)...

Pour ce qui est des FOURNISSEURs, effectivement il ne peuvent pas avoir la même adresse, ni la même adresse mail (je pense qu'on pourrait aussi dire qu'il est fort peu probable qu'ils aient le même nom de contact mais il ne vaut mieux pas prendre de risque

D’accord pour l’adresse de courriel, mais pour l’adresse postale, rien n’interdit que deux fournisseurs aient la même. Pour ma part j’avais plutôt parlé de numéros de téléphone...

De fait je peux ajouter les clés candidates: {FournisseurNom, FournisseurTel}, {FournisseurNom, FournisseurMail}, {FournisseurNom, ContactTel} et {FournisseurNom, ContactMail}.

En vertu du principe d’irréductibilité des clés candidates, {FournisseurNom, FournisseurTel} n’est pas clé candidate, {FournisseurTel} l’est dans la mesure où un numéro de téléphone détermine un [et un seul] fournisseur.

Effectivement si l'on considère que RefId est relatif au fournisseur (ce qui me semble une excellente idée a priori encore que je ne sais pas trop encore comment on va utiliser ceci ensuite)

Reprenons l’exemple du message #11 :




On utilise 1 à plusieurs types d’optiques par fournisseur, la clé primaire de la table FOURNISSEUR_CATALOGUE prend les valeurs suivantes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
FournisseurId    OptiqueCatId
            1               1
            1               2
            1               3
            2               1
            2               2
            2               3
            3               1
            3               2
          ...             ...

C'est-à-dire que la numérotation pour l’attribut OptiqueCatId commence à 1 pour chaque fournisseur. Normalement, cette numérotation peut être complètement sous-traitée à ACCESS, à l’aide de ce qu’on appelle un trigger, mais le produit contient un bug qui nous empêche de faire ça (j’ai appelé Microsoft, mais en vain...) Solution non automatisée : voyez la discussion avec Raph137.

Cela dit, des attributs « artificiels » comme FournisseurId et OptiqueCatId n’ont pas à être connus de l’utilisateur de l’application. Pour accéder au données d’un fournisseur (table FOURNISSEUR), l’utilisateur se sert de FournisseurRef, faisant l’objet d’une clé alternative {FournisseurRef}. Si pour la table FOURNISSEUR_CATALOGUE l’attribut OptiqueRef (RefFournisseur dans votre table FOURNISSEUR_REFERENCES) peut contenir des doubles, il faudra qu’on voie à définir un attribut faisant l’objet d’une clé candidate et visible par l’utilisateur (en gros : la copie de OptiqueRef, avec un chouïa en plus pour éviter les collisions).

Je suppose qu'une fois que j'ai mes clé candidate il va falloir que j'élise Miss clé primaire pour chaque table?

Yes! Règle simple : la recommandation est qu'une clé primaire soit non modifiable, dépourvue de signification, donc calculée par le système. Disons par auto-incrémentation (absolue) pour les entités-types fortes (ne dépendant pas d’autres entités-types) : {FournisseurId} pour la table FOURNISSEUR, {OptiqueId} pour la table OPTIQUE. Par incrémentation relative pour les entités-types faibles (dépendant d’autres entités-types) : {FournisseurId, RefId} pour la table FOURNISSEUR_REFERENCES, {FournisseurId, CommandeId} pour la table COMMANDE, {FournisseurId, CommandeId, RefId} pour la table LIGNE_COMMANDE.

C’est illustré par l’exemple du message #11 :

[Femtozaza]

Merci encore pour cette réponse,

Je vais voir la discussion citée pour essayer de faire ce qu'il faut avec mes clés primaires et l'auto-numérotation absolue et relative.
Je pense que je vais avoir un peu de lecture et un temps d'assimilation. Mais je ne lâche rien et je reviens avec mon modèle pour critique et correction

Vraiment merci de tout le temps passé à m'expliquer et m'aiguiller, j'apprends beaucoup et je trouve tout ceci fort intéressant.

[fsmrel]

Ave Elsa,


Tenez bon, je reste à l'écoute ^^

[Femtozaza]

Bonjour bonjour,

Après quelque jours d'absence, j'avoue que je rame un peu...
Les info sont toutes liées à du codage pour faire cette incrémentation, et je ne comprends pas tout bien (je ne suis pas encore perméable à ce langage que je ne connais pas du tout). Et je ne comprends pas tous les mots utilisé dans le cours "Numérotation personnalisée des enregistrements dans Access 2010" de C. Warin.... Par exemple je ne comprends pas bien ce qu'est un évènement de table. J'ai bien l'impression que ça correspond en gros à ce que vous appelez un trigger mais c'est pas bien clair. (Je crois que j'ai compris la notion de trigger par contre c'est comme quand on utilise un oscilloscope...)

Bon je ne désespère pas (encore tout à fait) mais par où commencer? dois-je apprendre à programmer des macros avant toute choses? Dois-je revoir mes envies d'une belle base de données à la baisse (si ça devient trop complexe par rapport à mon expérience des bases de données en général et sous Access en particulier)?...

Quand considère-t-on qu'une modélisation est "terminée"? Faut il avoir tout prévu en terme de requête, formulaire et états? Ou est-ce que les relations entre tables suffisent? N'entre-t-on pas déjà dans le "comment" lorsque l'on cherche à faire de l'incrémentation relative?

Merci d'avance pour vos réponses!

Edit:

Après ce moment de panique générale (un thé et un carré de chocolat plus tard), j'ai fait une tentative de mise en place des relations entre mes clés (repartir sur du concret ça aide parfois... Mais pas toujours).

Mais me voici à nouveau coincée pour établir mes relations, ça ne me semble pas propre et d'ailleurs Access n'est pas trop d'accord pour établir ces relations.
Donc dois-je établir d'abord des index comme nous avions discuté dans un message précédent? Comment fais-je? (Je pense que c'est pas la peine que j'écrive "Au secours!!")