[AC-2007] Conception BDD Composition d'un produit

[koluche]

Bonjour à tous, je suis actuellement en stage.
Durant ce stage, j'ai déjà créé une base de données contenant tous les produits de mon entreprise. Cependant, j'ai mis pas mal de temps a m'en sortir a cause de petits problèmes de modélisation au départ.
De ce fait, je viens vous voir pour etre sur de partir sur de bonne bases (de données ).

Mon but est de créer une "FICHE DE VIE" pour un produit. C'est une fiche assez simple (je pense passer par un état) qui regroupe:
Le nom et numéro de série du produit final
Une arborescence contenant le nom et le N° de Série de chaque sous-ensemble (et même sous-sous-ensemble etc...)

Vous l'aurez compris, je comptais passer par une association reflexive (un produit est un composant mais aussi un composé, même principe que pour un arbre généalogique).

Cette BDD sera remplie grace à un terminal de saisie à codes-barres, mais cela importe peut ici.

Pour ceux qui ont le temp, j'ai joint un fichier word contenant une présentation assez complète de cette BDD. Si vous avez le temps de donner votre avis sur ma façon de faire, je serais ravi, sinon, pas de soucis!

Voici mon MLD actuel:


Explications:
-MODELES contient les informations sur les "modeles de tracabilité". Ils servent juste à indiquer le nom et la référence (a ne pas confondre avec le N°Serie) des produits a scanner, le tout étant "hierarchisé" (c'est pour ça qu'on a : ID_pdt et ID_parent)
Etant donnée qu'il doit y avoir plusieurs modèles dans la BDD, j'ai aussi une colonne ID_Modele.

- TRACABILITES contient les informations utiles à la génération d'une fiche de vie. Elle contient l'ID du modele auquel appartient le produit, un ID de traçabilité (unique, mais pas clé primaire car pour une tracabilité, il y a plusieurs produits), le N° de série du pproduit, et enfin l'ID du produit, et l'ID de son "père".

En fait, je pense ne garder que les tables MODELES et TRACABILITE.
Le table modele ne serait pas modifiée, mais la table traçabilité elle deviendrait la suivante:
-ID_produit (le meme que dans la table MODELES avec une relation 1 a 1)
-NS_pdt (le numéro de serie du produit)
-ID_modele (pour savoir a quelle modele appartient cette tracabilité)
-ID_tra (Pour identifier clairement une tracabilité).

Voici un exemple concret:



Qu'en pensez vous?
Merci de me faire profiter de votre expérience, n'hésitez surtout pas à critiquer!! Je suis la pour ça =)

EDIT: je suis en train de lire http://warin.developpez.com/tutoriel...access/#LIII-A . Je n'avais jamais été le voir durant mes recherches car le titre de ce post ne me semblait pas en rapport avec ce que je cherchais... Desolé si ma réponse est la dedans, mais vous pouvez toujours donner votre avis!

[f-leb]

Bonjour Koluche,

Quelques éclaircissements me paraissent nécessaires…

Concernant tes produits (les modèles), on a finalement un doute sur la façon de les organiser :
- Soit de manière hiérarchique, avec une clé étrangère Modeles.ID_Parent
- Soit sous forme de nomenclature avec ta table Composition (parce qu’un modèle "enfant" peut avoir plusieurs modèles "parent".

C’est l’une ou l’autre mais tu as modélisé les deux !!??

En supposant que l’on parte sur un modèle hiérarchique (d’après ton exemple).
J’ai du mal à comprendre le concept de "traçabilité", je suppose qu’une ligne de "traçabilité" correspond à un exemplaire unique d’un modèle identifié par son numéro de série. Me trompé-je ?

Par exemple tu as un modèle d’ordinateur (identifié par sa référence ORDI123) mais qui peut exister en plusieurs exemplaires (dont un avec le n°1212 d’après ton tableau).

Bien entendu, tu veux suivre chaque exemplaire et savoir par exemple que la carte mère n°2323 est montée sur l’ordinateur n°1212.

La relation hiérarchique entre les modèles semble également indiquer que dans ta traçabilité, tu voudrais éviter que l’on puisse monter un exemplaire de disque dur sur un exemplaire d’aspirateur (quoi que…)

Bon, on attend tes éclaircissements, pour le moment je ne vois pas la relation 1-1...

PS : il est d’usage dans les hiérarchies de mettre l’ID_Parent à Null pour l’élément racine.
L’élément racine étant celui qui n’a pas de parent et non pas celui qui a pour parent lui-même