Discussion :

[tony_2009]

Salut à tous !
Je viens tout juste de m'inscrire. Je suis un néophyte qui s'attaque à MySQL via EasyPhp.
J'ai du mal à identifier comment organiser ma base de données. En fait je veux créer une petite application qui me permet d'établir des listings de boites d'instruments chirurgicaux. En fait je pensais créer une table "instruments" contenant toutes les références possibles et imaginables: pince hémostatique Kelly, ecarteur de farabeuf... Je pensais également créer une table composition qui contiendraient les compositions listées à l'aide de l'application. Par exemple cette table pourrait contenir 300 ou 400 compositions qui auraient pour nom urologie1, cataracte Dr Durand …Chacune de ces compositions contenant le détail des instruments la composant. Par exemple la composition cataracte contient 9 instruments qui sont « ciseaux de vannas, ecarteur de castroviejo … »

Mes questions sont les suivantes :

1-est-ce que je dois créer une seule table « instrument » contenant toutes les références ? (il y aura plus de 10 000 références). Ou bien créer plusieurs tables par famille d’instruments, 1 table pour les ecarteurs, 1 table pour les pinces hémostatiques…

2-Pour créer les listings de composition je veux procéder comme ceci : à l’aide d’un petit moteur de recherche je tape une syllabe qui me permet de retrouver l’instrument souhaité. Je sélectionne cet instrument et je l’ajoute dans ma composition. Est- ce que je dois créer une table pour chaque composition ? et je ne sais pas à l’avance le nombre d’instruments qu’il y aura dans la composition, ce sera variable. Comment faire vis à vis de ce nombre de champs variables dans ma composition ?En fait il me faudrait une table composition qui ne contiendrait que les noms des compositions et chacune de ces compositions contiendrait une «sous-table » qui serait le listing des instruments ? listing dont on ne connaît pas à l’avance le nombre d’instruments.

Merci pour votre future aide

[f-leb]

Je viens tout juste de m'inscrire.

S’lut moi aussi

En fait je pensais créer une table "instruments" contenant toutes les références possibles et imaginables: pince hémostatique Kelly, ecarteur de farabeuf... .

OK, donc une table Instruments (ID_Instrument, référence)

Par exemple la composition cataracte contient 9 instruments qui sont « ciseaux de vannas, ecarteur de castroviejo … »

OK, donc si j’ai bien compris, une entité Compositions avec une asso. Contenir
Compositions---(1,n)-----contenir-----(1,n)----Instruments
Quand même écarteur, pince j’vais vomir

1-est-ce que je dois créer une seule table « instrument » contenant toutes les références ? (il y aura plus de 10 000 références).

Si c’est juste pour faire des listings d’instruments, autant créer ta base avec Excel.

Ou bien créer plusieurs tables par famille d’instruments, 1 table pour les ecarteurs, 1 table pour les pinces hémostatiques…

Ta structure de données est relationnelle donc : instruments, famille d’instruments, compositions. Tout ça en relation donc qqchose comme ça
Compositions---(1,n)---contenir---(1,n)---Instruments---(1,1)---contenir(2)---(1,n)---FamillesInstruments

Est- ce que je dois créer une table pour chaque composition ? et je ne sais pas à l’avance le nombre d’instruments qu’il y aura dans la composition, ce sera variable.

Oulahh, j’vais trop vite moi ? Tout ce que j’ai dit + haut ça doit ressembler à du chinois pour toi.
Bon, on reprend depuis le bédut, soit le schéma Entités-Associations
Compositions---(1,n)---contenir---(1,n)---Instruments---(1,1)---contenir(2)---(1,n)---FamillesInstruments
Ça signifie :
1 composition contient 1 à plusieurs instruments (selon la composition)
1 instrument est contenu dans 1 à plusieurs compositions, hypothèse à confirmer j’y connais rien en instruments de torture ;
1 instrument appartient à une famille d’instruments et une seule, hypothèse à confirmer là aussi.
1 famille d’instruments comporte 1 à plusieurs instruments.
Dans le schéma, il y a des « n » qui signifient « plusieurs » ça veut dire autant que tu veux.
C’est pas comme dans un tableur ou t’as besoin de savoir le nombre de lignes/colonnes à insérer à l’avance. Dans une table d’un SGBDR, tu ajoutes tes enregistrements au fur et à mesure et puis c’est tout.
Si les règles de gestion proposées + haut te conviennent, t’as pas besoin de connaître le nombre d’enregistrements à l’avance. Heureusment qu’un SGBD puisse gérer ça.

Comment faire vis à vis de ce nombre de champs variables dans ma composition ?En fait il me faudrait une table composition qui ne contiendrait que les noms des compositions et chacune de ces compositions contiendrait une «sous-table » qui serait le listing des instruments ? listing dont on ne connaît pas à l’avance le nombre d’instruments.

Je vois ce que tu veux dire mais là encore c’est pas comme ça que ça marche. Il faut d’abord apprendre à concevoir à un niveau conceptuel. Le schéma entités-associations est fait pour ça. Les tables et les relations suivent ensuite par traduction de ce schéma.
Par exemple, d’après le schéma j’en déduis qu’il faudra une table Contenir :
Contenir (#ID-Composition, #ID-instrument)
Exemple de contenu de la table Contenir :
IDcomposition1, IDInstrument1
IDcomposition1, IDinstrument2
IDcomposition2, IDinstrument3
Etc… La composition1 comprend les instruments 1 et 2, la composition2 comprend l’instrument 3, etc…et chaque composition comprend le nombre d’instruments que tu veux.

Je te conseille vivement de consulter les nombreux tuto du site, notamment celui ci http://cyril-gruau.developpez.com/um.../ConceptionBD/. Après ça tu devrais ressentir comme une illumination sur la modélisation conceptuelle et la logique relationnelle des bases de données et cette discussion te semblera futile.

Bon courage et à +