Discussion :

[crismans]

Bonjour,

Dans le cadre d'un projet, je cherche à organiser les données qui seront générées afin d'éviter les éventuelles erreurs dues à un mélange de fichier. Je voulais créer un fichier excel mais une Base de donnée sous access me semble plus adapté. Mon problème est que c'est ma première base de donnée et que je ne sais pas si je pars dans la bonne direction ou pas. Afin d'être le plus clair possible, je vous met mon speudo Cahier des charges. Si des personnes peuvent me guider dans la démarche de création d'une base de donnée, je vous en remercie par avance.

Lors de ce projet nous avons à créer plusieurs produits.

- Un produit est défini par sa référence, son auteur, son nom, sa date de création et la date de dernière révision de l'un de ses composants

- Chaque produit est composé de pièces, il existe deux types de pièces :

- les pièces standards
- les pièces révisables

Une même pièce peut être utilisable par plusieurs produits.

- Une pièce révisable est caractérisée par son auteur, son nom, sa date de création, sa référence et le numéro de sa révision active.
- Une pièce non révisable est caractérisée par son nom, sa date de création et sa référence
- Une révision est une modification sauvegardée d'une pièce. On connait son auteur, sa date de révision (dernière modification) et sa position au sein du système de fichiers (chemin UNC),
- Chaque révision contient également un numéro de révision (qui s'incrémente de 1 à chaque nouvelle révision),
- On doit connaître la révision active d'une pièce. Il est en effet possible d'avoir une révision plus récente que celle qui est active.
- Un auteur est défini par son nom, prénom et par un rôle (Concepteur, Chef de projet...)
- Les rôles ne sont pas saisis lors de la création de l'auteur mais doivent être sélectionnés depuis une liste.

Avant de modéliser les tables sous access, j'ai dans un premier temps essayé de définir linéairement les tables dont j'aurai besoin. Je ne suis pas sure d'avoir bien compris ce qu'est une clef primaire et une clef secondaire.

Liste des tables :

T_Auteur (Id_Auteur, Nom_Auteur, Prenom_Auteur, Role)
T_Produit (Ref_Produit, Ref_PieceS, Ref_PieceR, Id_Auteur, Nom_Produit, DateCrea_Produit)
T_PieceR (Id_Auteur, Nom_PieceR, DateCrea_PieceR, Ref_PieceR, NumRevA_PieceR, Id_Revision)
T_PieceS (Nom_PieceS, DateCrea_PieceS, Ref_PieceS)
T_Revision (Id_Revision, Id_Auteur, DateRev)
T_CREER (Id_Auteur, Ref_Produit, Ref_PieceR, Id_Revision)
T_ROLE (Id_Auteur, Designer, Concepteur, Chef de Projet)

Merci de votre aide.

Passez de bonne fêtes.

[Jeannot45]

Avant de modéliser les tables sous access, j'ai dans un premier temps essayé de définir linéairement les tables dont j'aurai besoin. Je ne suis pas sure d'avoir bien compris ce qu'est une clef primaire et une clef secondaire.

Pour bien démarrer, tu trouveras dans les tutos, les bases nécessaires à connaitre :
Introduction à Access - Les bases
Les Relations et les jointures

Bonne continuation

[f-leb]

Bonjour crismans, Jeannot45

Je ne suis pas sure d'avoir bien compris ce qu'est une clef primaire et une clef secondaire.

Commençons avec la table: Auteur(idAuteur, Nom, Prenom, …)
(clé primaire soulignée)

…- Un auteur est défini par son nom, prénom et par un rôle (Concepteur, Chef de projet...)

La clé primaire idAuteur est de type numérique (entier long) auto-incrémenté (type plus facile à manipuler en informatique). Bien entendu, cet identifiant artificiel n’ayant aucune signification (porteur d’aucune information), ce numéro est réservé au développeur pour identifier l’enregistrement, faire ses opérations de jointures et autres travaux pénibles alors que l’utilisateur de l’application ne se doutera même pas de son existence et ne verra que les noms, prénoms,… sur son écran.

Concernant les rôles et afin notamment d’éviter le gaspillage d’octets, nous fuirons la table :

Code :

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

1
2
3
4
5
6
Auteur :
idAuteur     Nom        prenom    LibelleRole
   1       Dupond       Jean       Designer
   2       Durand       Jacques    Designer
   3       Dubois       Pierre     Designer
…

où le libellé "Designer" redonde (les 8 mêmes caractères à stocker autant de fois qu’il y aura de designer), au profit d’une codification du rôle :

Code :

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

1
2
3
4
5
6
Auteur :
idAuteur     Nom       prenom    idRole
   1       Dupond       Jean       2
   2       Durand       Jacques    2
   3       Dubois       Pierre     2
…

avec la table supplémentaire : Role(idRole, libelleRole)

Code :

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

1
2
3
4
5
Role :
idRole     libelleRole
   1       Concepteur
   2       Designer
   3       Chef de projet

Quel progrès ! Imagine déjà le gain d’octets et l’avantage que nous avons sur le terrain s’il nous prenait de mettre à jour le libellé "Designer" en "Dessinateur " ou "styliste" sur des centaines, des milliers… d’auteurs qui auraient ce rôle dans la base.

On pourrait en rester là mais des gens bien intentionnés ont poussé plus loin en inventant le concept de clé étrangère et l’intégrité référentielle qui va avec.

Le truc est de mettre en relation le champ Auteur.idRole et Role.idRole grâce à un mécanisme d’ "ntégrité référentielle" qui interdit à tout auteur de se voir codifier un rôle qui n’existerait pas dans la table des rôles :

Code :

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

1
2
idAuteur     Nom     prenom    idRole
   1       Dupond     Jean       4 <==impossible, le rôle n°4 n’existe pas dans la table Role

Et c’est ainsi que Auteur.idRole devint "clé étrangère" reliée à la clé primaire de la table Role :
Auteur(idAuteur, Nom, prenom, #idRole)
(clé étrangère précédée d’un #)

Dans la fenêtre des relations d’Access :
Auteur-∞--------1-Role

Sur un plan conceptuel, la relation "un à plusieurs" (-1------∞-) est la traduction des règles de gestion (cf tutos de M.Hubiche proposés par Jeannot45):
Dans le sens Auteur→Rôle :
Un {auteur} {a} un {rôle}

Dans le sens Rôle→Auteur :
Un {rôle} {peut avoir} plusieurs {Auteur}

…et une clef secondaire

Clé secondaire ou clé étrangère (voire clé externe)… le terme angliche est " Foreign Key ".

Bon, je reprends ma respiration et je reviens plus tard, il y a encore beaucoup de choses à dire sur tes tables…


Note : je viens de lire ça :

- Les rôles ne sont pas saisis lors de la création de l'auteur mais doivent être sélectionnés depuis une liste.

Je ne comprends pas le sens de cette phrase.

[Richard_35]

Bonjour Crismans et Jeannot45,

... et à F-leb qui a répondu pendant que j'écrivais (à qui j'ai piqué "∞").

Outre les excellents tutos proposés par [le non moins excellent] Jeannot45, je te félicite, Crismans, d'avoir, au moins, bossé sur le sujet. Cela m'a donné "envie" de te donner un point de vue.
Voici la liste des tables et relations qu'il me semble nécessaire (à discuter). Les postulats peuvent servir de base de travail.

T_Role :
- Id_Role (clé primaire, numéro auto)
- Libelle_role ("Designer", "Concepteur", "Chef de Projet")
...

T_Auteur :
- Id_Auteur (clé primaire, numéro auto)
- Nom_Auteur
- Prenom_Auteur
...

T_Produit :
- Ref_Produit (clé primaire, numéro auto)
- Nom_Produit
- DateCrea_Produit
- Id_Auteur
- Id_Role
...
==> Postulat : un même auteur peut avoir un rôle différent selon le produit.

T_Piece :
- Ref_Piece (clé primaire, numéro auto)
- Type_piece ("S" : pièce standard, "R" : pièce révisable)
- Nom_Piece
- DateCrea_Piece
...

T_Revision :
- Id_Revision (clé primaire, numéro auto)
- Id_Auteur
- DateRev
...
==> Postulat : pas de rôle au niveau "révision".

T_Produit_Piece :
- Id_couple (clé primaire, numéro auto)
- Ref_Produit
- Ref_Piece
...
==> Attention : index unique sur Ref_Produit/Ref_Piece.
==> Postulat : cette table est la nomenclature d'un produit.


Relations :
T_Auteur 1----∞ T_Produit via Id_Auteur ;
T_Role 1----∞ T_Produit via Id_Role ;
T_Auteur 1----∞ T_Revision via Id_Auteur ;
T_Produit 1----∞ T_Produit_Piece via Ref_Produit ;
T_Piece 1----∞ T_Produit_Piece via Ref_Piece.

[crismans]

Bonjour tout le monde,

Je vous remercie pour les éléments de réponse que vous m'avez apportés, je travaille ça et j'essaie de réaliser mes relations entre tables.

Pour répondre à f-leb, je voulais dire que lorsque je crée un nouvel auteur j'ai une liste prédéfinie des rôles que je peux lui attribuer. Je souhaitais réaliser une liste de valeur (menu déroulant).
Avant ça je vais bosser les tutos.

Merci de votre aide

Bonnes fêtes

[crismans]

Bonsoir,

Après avoir écouté vos conseils, j'ai refait mes tables (jointes en fichier pdf). L'idée de créer une table nomenclature (T_BOM) était très intéressante, je l'ai donc reprise mais j'ai un petit soucis concernant mes liaisons, si j'ai bien compris ce que j'ai lu dans les tutos et ce que vous m'avez expliqué, pour la relation entre T_pieceR et T_BOM, j'ai une relation 1---∞. Ce qui veut dire que ma pièce peut appartenir à plusieurs BOM mais qu'une BOM ne peut avoir qu'une seule pièce ? Or cela me pose un problème car j'aimerais avoir une une relation ∞---∞. Est ce possible ?

Concernant la table T_Role, je l'ai reliée comme cela (voir pdf) car je souhaite qu'un rôle puisse avoir plusieurs auteurs, mais qu'un auteur puisse avoir qu'un seul rôle et je voudrais que ça m'oblige à créer un autre auteur, avec Nom et Prénom Identique mais avec un second rôle lorsque je veux qu'un auteur ait plusieurs rôles suivant le produit.

Mes tables et relations vous semblent-elles correctes ?

Merci de votre aide

Bonne soirée

[f-leb]

Salut,

concernant les pièces, je reformules les règles de gestion:
- Une pièce est caractérisée par sa référence, son nom et sa date de création
- Une pièce révisable est une pièce. Elle est alors caractérisée en plus par son auteur et un numéro de révision active.

Ou encore en pseudo-langage (façon M.Hubiche dans son tutoriel):
Une {PIECE REVISABLE} {est} une {PIECE}
Une {PIECE} peut {être} une {PIECE REVISABLE}

Et nous voilà face à une relation peu usitée de type "un à un" que nous pouvons modéliser sous Access :

Piece(idPiece, RefPiece, NomPiece, DateCreation)
PieceRevisable(#idPiece, #idAuteur, #idRevisionActive)

PieceRevisable.idPiece étant à la fois clé primaire et clé étrangère référençant Piece.idPiece.

Piece-1--------1-PieceRevisable

Code :

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

1
2
3
4
5
6
Piece :
idPiece    RefPiece   NomPiece   …
   1        XXXX      Bielle
   2        YYYY      Manivelle
…
10000       ZZZZ      piston

Code :

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

1
2
3
PieceRevisable:
idPiece    idAuteur   idRevisionActive…
   2          123          278

Seule la pièce n°2 est révisable et son auteur a le n°123 puisque l’identifiant de cette pièce apparaît dans la table PieceRevisable.

Le reste consiste à raccorder PieceRevisable aux révisions, aux auteurs de révisions, etc…


Je reviens plus tard, à suivre…

Au fait, c'est quoi une BOM ??

[crismans]

Bonsoir f-leb

Une {PIECE REVISABLE} {est} une {PIECE}
Une {PIECE} peut {être} une {PIECE REVISABLE}

En faisant ça, si je suis bien, je n'ai pas besoin d'avoir une table pour les pièces standards (T_PieceS) et une table pour les pièces révisables (T_PiècesR), Je regroupe les deux en une seule et même table et je crée une table pour les pièces révisables. C'est bien ça ?

Au fait, c'est quoi une BOM ??

BOM = Bill Of Materials, ou encore Nomemclature en français. C'est mon coté faineant, 3 lettres, c'est plus rapide à écrire sous access. ;-)

[f-leb]

Autrement dit dans le schéma: Piece-1--------1-PieceRevisable,

dans "Piece" tu retrouves toutes les pièces révisables ou standards (avec leurs références, leurs noms, date de création)

Dans "PieceRevisable", tu reportes l'identifiant des "Piece" qui sont révisables avec les propriétés supplémentaires auteur, Num révision actif.

Tu vois ?

Je regarde le reste...

[crismans]

Oui je vois merci, en plus ça semble plus logique et plus "propre".

Je n'ai pas relié les tables pièce et révision à la table auteur, en pensant pouvoir me servir de la table produit pour faire le lien, mais je pense que c'est une erreur car les auteurs peuvent être différents.

Merci de votre aide

[f-leb]

bonjour,

Concernant la table T_Role, je l'ai reliée comme cela (voir pdf) car je souhaite qu'un rôle puisse avoir plusieurs auteurs, mais qu'un auteur puisse avoir qu'un seul rôle et je voudrais que ça m'oblige à créer un autre auteur, avec Nom et Prénom Identique mais avec un second rôle lorsque je veux qu'un auteur ait plusieurs rôles suivant le produit.

on ne va certainement pas dupliquer les auteurs dans la table.

si j'ai bien compris, ce qu'a proposé Richard plus haut (à qui je n'ai pas encore souhaité la bonne année, voilà c'est fait) devrait te convenir:

T_Produit :
- Ref_Produit (clé primaire, numéro auto)
- Nom_Produit
- DateCrea_Produit
- Id_Auteur
- Id_Role
...
==> Postulat : un même auteur peut avoir un rôle différent selon le produit.

[crismans]

Bonjour f-leb,

Je tiens d'abord à vous remercier pour l'aide que vous m'avez apporté. J'ai une dernière question avant de poser le tag Résolu.

Je n'arrive pas à relier la table T_Révision avec T_PieceR.

J'ai suivi votre conseil en faisant :

T_Piece ( Id_Piece, Ref_piece, Piece_Rev)
T_PieceR (#Id_Piece, #id_auteur, numrevactive)

Avec une relation entre T_Piece.IdPiece 1-----1 T_PieceR.Id_Piece

Ca j'ai bien compris, et ça fonctionne bien.

Je n'arrive pas à relier la table T_revision à T_pieceR, sachant qu'une pièce révisable peut avoir plusieurs révisions mais qu'une révision ne peut appartenir qu'à une seule PieceR. J'ai besoin d'une liaison 1 ---- ∞.

Sinon concernant les autres tables, tout marche comme je le voulais, je vous remercie pour les astuces du type codage des rôles. J'ai pu créer quelques requêtes et des formulaires.

Merci

Bonne soirée

[f-leb]

bonjour,

Je n'arrive pas à relier la table T_revision à T_pieceR, sachant qu'une pièce révisable peut avoir plusieurs révisions mais qu'une révision ne peut appartenir qu'à une seule PieceR. J'ai besoin d'une liaison 1 ---- ∞.

curieux ! ça devrait donner:
T_Revision(idRevision, DateRevision, ..., #Id_Piece)

avec la relation: T_PieceR-1-----∞-T_Revision

Que se passe-t-il ? Message d'erreur ?

[crismans]

Bonjour,

J'ai résolu le problème, en fait j'avais déjà une donnée dans la table pour la tester, et sans faire attention j'avais pas le bon type de donnée pour mon #Id_piece, mais je n'arrivais pas à le modifier du fait de la donnée déjà dans la table. Bref... Des erreurs de débutant.

En tout cas un grand merci pour votre aide dans mes début sous access.