Discussion :

[Jasmine80]

Bonjour à tous,

Suite aux conseils de CinePhil, je viens vous proposer mon MCD. Je reprends le début de mes explications avec lui, afin que cela soit complet et plus clair.

La base de données contient la liste des souches bactériennes que possède le laboratoire.

Définition des différentes entités et de leurs champs respectifs :

entité contenant toutes les références associées à l'entrée

Reference :
• Cle auto-incrémentée
• Référence Interne CTMA
• Référence Interne autre que celle du CTMA
• Référence Externe
• Accession


entité contenant les données biologiques servant à la classification de la souche

Classification :
• Genre
• Espèce
• Sous-espèce
• Autres : Variant, Type, Groupe


entité contenant les informations relatives à la souche stockée

Stock_informations :
• Autres formes existantes : Stock glycérol, culot sec,
• Souche de terrain ou référence
• Source


entité relative au stock d'ARN ou d'ADN contenant les informations de celui-ci

Stock_DNA_RNA
• Concentration en ng/µL
• Date (extraction ADN, réception, …)
• Notation tube-aliquot
• Local
• Congélateur
• Tiroir
• Boîte de rangement
• Case de la boîte de rangement


entité relative au stock glycérol contenant les informations de celui-ci (cette entité peut ne pas exister pour une entrée)

Stock_glycerol
• Date (extraction ADN, réception, …)
• Notation tube-aliquot
• Local
• Congélateur
• Tiroir
• Boîte de rangement
• Case de la boîte de rangement


entité contenant le nom du responsable de la souche

Manager
• Manager


entité contenant des informations complémentaires facultatives (cette entité peut ne pas exister pour une entrée)
Complementary_data
• Tests effectués confirmant l'identité
• Séquences (séquence unique ou format fasta possible *)
• Documentations liées
• Remarques


Voici les informations des types des champs :



Uploaded with ImageShack.us


J'essaie d'établir les relations et la cardinalité.

entité Référence 1:1 ... réfère ... 1:N entité Classification


Je n'ai évidemment qu'une référence (ID clé primaire) par entrée (souche bactérienne) dans la table. Et cette ID est obligatoire. Chaque entrée n'a qu'une seule classification. Chaque entité Référence réfère donc 1:1 entité Classification. Par contre, plusieurs entrées de la table peuvent avoir une classification parfaitement identique. Donc, de mêmes entités Classification (communes à plusieurs entrées) peuvent être référées par différentes entités Référence 1:N. J'essaie d'imaginer les ensembles, ça aide beaucoup.

Pensez vous que cela soit correct comme raisonnement?


Voila ce que cela donne :



Uploaded with ImageShack.us


Cela vous semble-t-il correct ... ça doit-être difficile sans connaitre entièrement le sujet, mais n'hésitez pas à me poser des questions.

Merci beaucoup,

[Richard_35]

Bonjour Jasmine,

.../... ça doit-être difficile sans connaitre entièrement le sujet .../...

==> en effet... en conséquence, gardes les mêmes noms partout car les rapprochements sont difficiles pour les non-spécialistes.

Si tu as conversé avec CinePhil, il a dû te conseiller d'établir d'abord, en français, des règles de gestion claires entre tes entités.

Par exemple :

Je n'ai évidemment qu'une référence (ID clé primaire) par entrée (souche bactérienne) dans la table. Et cette ID est obligatoire. Chaque entrée n'a qu'une seule classification. Chaque entité Référence réfère donc 1:1 entité Classification. Par contre, plusieurs entrées de la table peuvent avoir une classification parfaitement identique. Donc, de mêmes entités Classification (communes à plusieurs entrées) peuvent être référées par différentes entités Référence 1:N. J'essaie d'imaginer les ensembles, ça aide beaucoup.

==> peut être traduit par :

1 reference possède, obligatoirement, 1 et 1 seule classification ;
1 classification peut classifier plusieurs reference.

donnant :

Classification -0,n---[Classifier]---1,1- Reference

donnant, en vertu, de cet autre excellent billet de CinePhil (souligné=clé primaire, #=clé étrangère) :

Classification(IdClassification, Libelle, ...)
Reference(IdReference, Nom, #IdClassification, ...)

ton bout de MCD reference/classification est donc correct.

Maintenant, tu l'auras compris, il faudrait écrire, en français et sous cette forme, l'ensemble des autres règles de gestion. Après, ça roule tout seul...... plus ou moins......

Par exemple, peux-tu rédiger, sous cette forme, la partie Référence/Stock_glycerol que je ne saisi pas très bien (notamment, l'attribut qui établi la liaison) ?

[f-leb]

Bonjour à tous,

de ce que je peux voir, il y a deux types de stock (DNA_RNA et Glycerol) qui diffèrent uniquement par l’attribut Concentration.

On peut donc avoir une entité "Stock" spécialisée en DNA_RNA_Stock et Glycerol_Stock. Dans l’entité générique Stock on met les attributs communs puis on rajoute les attributs spécifiques (ici l’attribut Concentration).

La contrainte inter-association "XT" (une simple note dans ModelSphere mais contrainte à implémenter dans le SGBD) rappelle qu’un stock doit être obligatoirement soit de type RNA_DNA, soit de type Glycerol.

Pour modéliser la généralisation/spécialisation dans ModelSphere et générer un MLD correct, on trace les associations --0,1--xxx--1,1--, puis on souligne la cardinalité 1,1 qui devient 1,1 (marque de l’identification relative) en cliquant dessus après avoir sélectionné l’icône "création de clés".

Une question, tu mets quoi exactement dans ces attributs Room, freezer, drawer, box etc. ? Ils sont tous complétés pour chaque ligne ou certains restent à Null ?

[Richard_35]

Bonjour Fabien,

On peut donc avoir une entité "Stock" spécialisée en DNA_RNA_Stock et Glycerol_Stock. Dans l’entité générique Stock on met les attributs communs puis on rajoute les attributs spécifiques (ici l’attribut Concentration).

==> c'est, sans doute, vrai.

Il me semble qu'avant d'attaquer le détail des attributs de toutes les entités, il faut "mettre à plat" les règles de gestion : par cette méthode, ce type de regroupement d'entité devrait apparaître de lui-même.

De même que les entités (peut-être) manquantes (genre, espèce, sous-espèce, etc...) apparaissent, également, d'elles-mêmes.

En résumé, avec la listes exhaustives (en français) des couples du style :

1 xxxxx possède 1 et 1 seul yyyyy ;
1 yyyyy peut correspondre plusieurs xxxxx.

ça devrait rouler tout seul...

[Jasmine80]

Il me semble qu'avant d'attaquer le détail des attributs de toutes les entités, il faut "mettre à plat" les règles de gestion : par cette méthode, ce type de regroupement d'entité devrait apparaître de lui-même.

Oui, je vais commencer par là car le reste est beaucoup trop compliqué pour moi. Je vais y aller pas à pas.


Merci beaucoup pour vos conseils, j'écris toutes mes règles de gestion en français pour commencer et je reviens poster.

[Jasmine80]

1 reference possède, obligatoirement, 1 et 1 seule classification ;
1 classification peut classifier plusieurs reference.

1 reference réfère, obligatoirement, 0 à 1 seule Glycerol_stock
1 Glycerol_stock est référé par 1 seule référence

1 reference réfère, obligatoirement, 0 à 1 seule DNA_RNA_stock
1 DNA_RNA_stock est référé par 1 seule référence

1 Glycerol_stock est lié à 0 à 1 DNA_RNA_stock (même souche)
1 DNA_RNA_stock est lié à 0 à 1 Glycerol_stock (même souche)

1 Glycerol_stock est lié à 0 à 1 Glycerol_stock (même souche)
1 DNA_RNA_stock est lié à 0 à 1 DNA_RNA_stock (même souche)


... je suis déjà bloquée


Je vais essayer d'expliquer en français. Une souche du laboratoire possède plusieurs numéros d'identifications. Une souche peut générer plusieurs stocks glycérol et plusieurs stock DNA_RNA (voire aucun).

Pour une souche, je regroupe ensemble les différents numéros d'identification par un ID auto-incrémenté. C'est l'entité Reference qui possède comme attribut les différents numéros d'identification d'une même souche.

Donc, chaque stock, qu'il soit glycérol ou DNA_RNA, possède un ID propre mais une souche commune. L'ID est donc unique mais les attributs (numéros d'identification) de celui-ci communs à tous ces stocks car ils proviennent d'une même souche.

Le problème est que je n'ai aucune entité 'souche' car celle-ci est définie implicitement par les attributs de l'entité Référence.


Peut-être est-ce une erreur d'écrire mes règles de gestion en tenant compte d'un ID auto-incrémenté qui a pour but d'être la clé primaire. Peut-être que la création de celui-ci, vient après avoir écrit les règles de gestions.

Je vais recommencer à zéro, sans penser à ma clé primaire, juste à écrire en français les règles de gestion ... à moins que vous ne me le déconseillez.

[Richard_35]

Bonjour Jasmine80,

1°/

1 reference possède, obligatoirement, 1 et 1 seule classification ;
1 classification peut classifier plusieurs reference.

==> donne :

Classification -0,n---[Classifier]---1,1- Reference

donnant :

Classification(IdClassification, Libelle, ...)
Reference(IdReference, Libelle, #IdClassification, ...)

2°/

1 reference réfère, obligatoirement, 0 à 1 seule Glycerol_stock
1 Glycerol_stock est référé par 1 seule référence

==> donne :

Reference -0,1---[Référer]---1,1- Glycerol_stock

donnant :

Glycerol_stock(IdGlycerol_stock, #IdReference, ...)

3°/

1 reference réfère, obligatoirement, 0 à 1 seule DNA_RNA_stock
1 DNA_RNA_stock est référé par 1 seule référence

==> donne :

Reference -0,1---[Référer]---1,1- DNA_RNA_stock

donnant :

DNA_RNA_stock(IdDNA_RNA_stock, #IdReference, ...)

4°/

1 Glycerol_stock est lié à 0 à 1 DNA_RNA_stock (même souche)
1 DNA_RNA_stock est lié à 0 à 1 Glycerol_stock (même souche)

==> implicite de par les relations précédentes (via Reference).


5°/

1 Glycerol_stock est lié à 0 à 1 Glycerol_stock (même souche)
1 DNA_RNA_stock est lié à 0 à 1 DNA_RNA_stock (même souche)

==> es-tu certaine qu'il y a une relation de l'entité Glycerol_stock vers elle-même et de DNA_RNA_stock vers elle-même ?


6°/

Le problème est que je n'ai aucune entité 'souche' car celle-ci est définie implicitement par les attributs de l'entité Référence.

==> il me semble que c'est le nœud de ta problématique !... Il me semble indispensable de créer une entité Souche. Puis, comme :

C'est l'entité Reference qui possède comme attribut les différents numéros d'identification d'une même souche.

alors :

Souche -0,n---[Posséder référence]---1,1- Reference

donnant :

Souche(IdSouche, Nom, ...)
Reference(IdReference, Libelle, #IdSouche, #IdClassification, ...)

Qu'en penses-tu ?

[Jasmine80]

Merci beaucoup Richard du temps que tu me consacres.

Bonjour Jasmine80,

1°/
==> donne :

Classification -0,n---[Classifier]---1,1- Reference

donnant :

Classification(IdClassification, Libelle, ...)
Reference(IdReference, Libelle, #IdClassification, ...)

en effet, une classification pourrait ne se rapporter à aucune souche mais alors, ça ne servirait à rien de l'enregistrer dans la DB. Je vais donc garder 1,N. Quoique, dans ce cas, au cours du temps, si une souche disparait de la DB ... il faudra automatiquement penser à supprimer la classification associée afin qu'elle ne se retrouve pas 'orpheline' et crée une erreur de DB. Comment cela fonctionne-t-il?

es-tu certaine qu'il y a une relation de l'entité Glycerol_stock vers elle-même et de DNA_RNA_stock vers elle-même ?

Ce que je voulais indiquer, c'est qu'il peut exister plusieurs stocks glycérol et/ou DNA_RNA pour une même souche. Ces stocks sont donc liés par le fait qu'ils proviennent d'une même souche. Dans tous les stocks de la base, certains sont indépendants et d'autres en relation via la souche dont ils sont issus.


L'utilisation de clés étrangères est vraiment ce qu'il me fallait, merci pour ce conseils ... je n'aurais pas pu faire autrement, mais c'est un rappel qui fait du bien. Peut-être est-ce bien de garder IdReference.


Pour la souche, j'ai créé une entité, mais elle n'a aucun attribut et ne se définit que par les attributs des entités auxquelles elle est liée. Est-ce correct? Je pourrais juste créer un idStrain

Pour ce qui est de Reference, elle réfère obligatoirement quelque chose, mais c'est soit un ARN_ARN_stock, soit un glycérol_stock.





De mon côté, j'étais partie en recréant les règles de gestions en me centrant non plus sur Reference mais sur Strain (la souche) ... mais je n'avais plus de clé primaire et je devais encore la définir.




Uploaded with ImageShack.us



Uploaded with ImageShack.us



* stock_information : les attributs restent encore à définir ou voir si on supprime cette entité




Je vais étudier de plus près ta proposition avec une collègue qui gère les souches du labo et qui m'aide à comprendre la structure du système de gestion afin de l'informatiser. Selon ses conseils et les tiens, j'essaierai de mettre aux propres mes règles de gestion.

[Jasmine80]

Après discussion avec ma collègue, nous allons supprimer l'entité stock_informations :

Voici ce que cela donnerait :

Tables :

Classification(IdClassification, Libelle, ...)
Reference(IdReference, Libelle)
Strain_information(IdStrain_information, Libelle)
Complementary_data(IdComplementary_data, Libelle)
Manager(IdManager, Libelle)

Glycerol_stock(IdGlycerol_stock, Libelle, # IdStrain, ...)
DNA_stock(IdDNA_RNA_stock, Libelle, # IdStrain, ...)
RNA_stock(IdDNA_RNA_stock, Libelle, # IdStrain, ...)

Strain(IdStrain, #IdReference, #IdClassification, # IdStrain_information, # IdComplementary_data, # IdManager)

Strain n'aurait aucun attribut propre mais permettrait de lier les différents id entre eux. Je vais maintenant écrire les cardinalités.

[Jasmine80]

A partir des règles de gestion, définir la cardinalité des relations :

1 Strain génère 0 à N Glyrerol_stock
1 Glyrerol_stock est généré par 1 et 1 seule Strain

Strain - 0,n -- [génèrer] --1,1- Glyrerol_stock


1 Strain génère 0 à N DNA_stock
1 DNA _stock est généré par 1 et 1 seule Strain

Strain - 0,n -- [génèrer] --1,1- DNA_stock


1 Strain génère 0 à N RNA_stock
1 RNA_stock est généré par 1 et 1 seule Strain

Strain - 0,n -- [génèrer] --1,1- RNA_stock


1 Strain est classifiée par 0 et 1 seule Classification ; nb : 0 car Yann possède 3 souches de classification inconnue
1 Classification classifie une à plusieurs Strains.

Strain -0,1 -- [classifier] --1,n – Classification


1 Strain est référée par 1 et 1 seule Reference ;
1 Reference réfère une à plusieurs Strains.

Strain -1,1 -- [référer] --1,n - Reference


1 Strain est informée par 0 et 1 seul Strain_informations ;
1 Strain_informations informe 1 et N Strain

Strain -0,1 -- [informer] --1,n – Strain_informations


1 Strain est informée par 0 et 1 seul Complementary_data ;
1 Complementary_data informe 1 et N Strain

Strain -0,1 -- [informer] --1,n – Complementary_data


1 Strain est possédée 1 et 1 seul Manager ;
1 Manager possède 1 à plusieurs Strains.

Strain -1,1 -- [posséder] --1,n – Manager



et ensuite, qu'est-ce que je fais?

Merci beaucoup

[Richard_35]

J'avoue que cela devient un peu touffu...

Dans l'ordre :

Quoique, dans ce cas, au cours du temps, si une souche disparait de la DB ... il faudra automatiquement penser à supprimer la classification associée afin qu'elle ne se retrouve pas 'orpheline' et crée une erreur de DB. Comment cela fonctionne-t-il?

==> si 0,n est possible, alors il faut laisser 0,n.

Pour la souche, j'ai créé une entité, mais elle n'a aucun attribut et ne se définit que par les attributs des entités auxquelles elle est liée. Est-ce correct?

==> il n'est pas nécessaire qu'une entité possède au moins un attribut : elle peut se justifier d'une manière conceptuelle. Mais bon, une souche/Strain a bien un nom, non ?


D'où provient ton document "rglesgestions.png" ?
Pouvons-nous estimer que ces règles de gestion sont les bonnes ?

Enfin, dans tes tables :

Strain(IdStrain, #IdReference, #IdClassification, # IdStrain_information, # IdComplementary_data, # IdManager)
Strain_information(IdStrain_information, Libelle)

==> cela veut dire :
1 Strain possède obligatoirement 1 et 1 seul Strain_information (en supposant que IdStrain est la clé primaire)
1 Strain_information peut-elle être liée à plusieurs Strain ?

[Jasmine80]

et voila les entités et leurs attributs



Uploaded with ImageShack.us


Toujours selon ce que j'ai mis plus haut :

Classification(IdClassification, Libelle, ...)
Reference(IdReference, Libelle)
Strain_information(IdStrain_information, Libelle)
Complementary_data(IdComplementary_data, Libelle)
Manager(IdManager, Libelle)

Glycerol_stock(IdGlycerol_stock, Libelle, # IdStrain, ...)
DNA_stock(IdDNA_RNA_stock, Libelle, # IdStrain, ...)
RNA_stock(IdDNA_RNA_stock, Libelle, # IdStrain, ...)

Strain(IdStrain, #IdReference, #IdClassification, # IdStrain_information, # IdComplementary_data, # IdManager)

[Jasmine80]

Richard, une fois de plus merci beaucoup. C'est la première fois que je fais ce type de schéma et c'est assez complexe.

J'avoue que cela devient un peu touffu...

ça 'devien't seulement ... pour moi, ça l'est depuis le début!

Dans l'ordre :
==> si 0,n est possible, alors il faut laisser 0,n.

C'est ce que j'ai utilisé

==> il n'est pas nécessaire qu'une entité possède au moins un attribut : elle peut se justifier d'une manière conceptuelle. Mais bon, une souche/Strain a bien un nom, non ?

La souche est une bactérie précise (espèce, genre, souche ...) qui possède des références précises (référence interne au labo + références externes au labo) et est gérée par une personne précise (Manager). Néanmoins, vu que chacun travaille en solo dans son coin, (d'où l'utilité de tout référer dans une DB), il se pourrait que 2 personnes aient attribué des noms 'logiques' (Reference) identiques pour 2 souches distinctes. Enfin, même si en réalité, les souches étaient identiques, il faudrait les distinguer car elles sont générées par différentes personnes (Manager) et rangées à différents endroit du labo. Je te l'accorde c'est compliqué comme à chaque fois quand aucun système n'est bien défini dès le départ et que rien n'est centralisé.

D'où provient ton document "rglesgestions.png" ?
Pouvons-nous estimer que ces règles de gestion sont les bonnes ?

Ce sont les règles que j'ai essayées d'écrire et justement 'peut-on les considérer comme correctes' était ma question

Enfin, dans tes tables :
==> cela veut dire :
1 Strain possède obligatoirement 1 et 1 seul Strain_information (en supposant que IdStrain est la clé primaire)
1 Strain_information peut-elle être liée à plusieurs Strain ?

Strain_information renseigne si la souche est une souche 'de terrain' ou 'de référence' (seulement 2 valeurs possibles) ainsi que l'origine (pays) et donc oui, plusieurs souches peuvent avoir le même strain_information. Ces informations sont trop générales que pour être spécifiques à la souche. Idem que pour la Classification. Le labo possède plusieurs mêmes espèces/genres bactériens mais de souches diverses. Par contre, une souche pourrait ne pas avoir de strain_information si celle-ci est inconnue, ça doit donc être 0,1.


Justement, je n'ai pas compris comment passait-on des phrases écrites avec cardinalité aux tables? J'ai tenté à l'intuition ... mais celle-ci est peut-être défectueuse

cf 10ième message où j'ai écrit toutes mes 'règles de gestion' avec cardinalité


Merci,

[Richard_35]

Hum... ...

La souche est une bactérie précise (espèce, genre, souche ...) qui possède des références précises (référence interne au labo + références externes au labo) et est gérée par une personne précise (Manager).

==> est contradictoire avec

Enfin, même si en réalité, les souches étaient identiques, il faudrait les distinguer car elles sont générées par différentes personnes (Manager)

Je te l'accorde c'est compliqué comme à chaque fois quand aucun système n'est bien défini dès le départ et que rien n'est centralisé.

==> le problème semble être à ce niveau : plutôt que d'adapter les règles de gestion à une organisation (plus ou moins chaotique), ne vaut-il pas mieux adapter l'organisation à des règles de gestions logiques pour le métier ?

Ce sont les règles que j'ai essayées d'écrire et justement 'peut-on les considérer comme correctes' était ma question

==> sémantiquement, elles sont bonnes mais seul les spécialistes "métier" peuvent dire si elles sont correctes !

Strain_information renseigne si la souche est une souche 'de terrain' ou 'de référence' (seulement 2 valeurs possibles) ainsi que l'origine (pays) et donc oui, plusieurs souches peuvent avoir le même strain_information.

==> attention à ne pas mélanger les genres !... "terrain"/"référence" est un type de souche, "origine" est un pays d'origine lié à la souche, si j'ai bien compris. Si c'est le cas, ces informations ne sont pas au même niveau :

Code :

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

1
2
3
Strain -1,1---[Être de type]------0,n- StrainType
  |   
  +-----1,1---[Être originaire]---0,n- Pays

donnant :

StrainType(IdStrainType, Libelle, ...) ==> terrain, référence
Pays(IdPays, Nom, ...)
Strain(IdStrain, #IdStrainType, #IdPays, ...)

Justement, je n'ai pas compris comment passait-on des phrases écrites avec cardinalité aux tables?

==> ce billet de CinePhil balaye tous les cas possibles.


En conclusion :
Je ne sais pas trop par où prendre la chose...
La souche semble être le point d'entrée de tout le système, non ?
Si une souche ne peut être gérée QUE par un seul manager, alors ce manager devrait "la créer" en la codifiant dans le futur système de gestion. Ensuite, toute action devrait être déclenchée en indiquant, d'abord, sur quelle souche l'on travaille. Le fait qu'il y ait des références "identiques" pour plusieurs souches différentes n'est pas grave, car ces références n'existeront QUE via la souche concernée.

Je ne sais pas trop si tout cela t'aide vraiment...

[Jasmine80]

Hum... ...

==> est contradictoire avec

Ca ne me semble pas contradictoire. Disons qu'au niveau du laboratoire, une souche est un tube contenant une bactérie précise et gérée par une personne précise. Si deux personnes différentes du labo possédaient 2 mêmes types de bactéries, dans 2 tubes différents, notés différemment et rangés à deux endroits différents, il faudrait les considérer comme 2 entrées différentes dans la base de données.

==> le problème semble être à ce niveau : plutôt que d'adapter les règles de gestion à une organisation (plus ou moins chaotique), ne vaut-il pas mieux adapter l'organisation à des règles de gestions logiques pour le métier ?

Peut-être est-ce envisageable pour le futur mais, il y a plusieurs milliers de tubes contenant des bactéries, ranger à différents endroits et annotés selon le système propre de chaque utilisateur. Leur demander de tous renommer selon un code général au labo est difficilement envisageable.

==> attention à ne pas mélanger les genres !... "terrain"/"référence" est un type de souche, "origine" est un pays d'origine lié à la souche, si j'ai bien compris. Si c'est le cas, ces informations ne sont pas au même niveau :

Code :

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

1
2
3
Strain -1,1---[Être de type]------0,n- StrainType
  |   
  +-----1,1---[Être originaire]---0,n- Pays

donnant :

StrainType(IdStrainType, Libelle, ...) ==> terrain, référence
Pays(IdPays, Nom, ...)
Strain(IdStrain, #IdStrainType, #IdPays, ...)

==> ce billet de CinePhil balaye tous les cas possibles.

En quoi est-ce que je mélange les genres? Ce sont des données renseignant sur la souche ... si je divise trop mes données, je vais me retrouver avec une multitude d'entités ne contenant chacune qu'un attribut. C'est plutôt arbitraire comme division, non?

La souche semble être le point d'entrée de tout le système, non ?

Oui

Si une souche ne peut être gérée QUE par un seul manager, alors ce manager devrait "la créer" en la codifiant dans le futur système de gestion.

Trouver un système d'annotation précis et commun à tous?

Ensuite, toute action devrait être déclenchée en indiquant, d'abord, sur quelle souche l'on travaille. Le fait qu'il y ait des références "identiques" pour plusieurs souches différentes n'est pas grave, car ces références n'existeront QUE via la souche concernée.

je pense que je comprends

Je ne sais pas trop si tout cela t'aide vraiment...

En fait, à la base, ma DB ne contenait qu'une seule table et était très fonctionnel. Le but n'est pas d'avoir une DB de compétition mais un outil pratique permettant de centraliser les souches que possède le laboratoire. Quand quelqu'un du labo à besoin d'une souche, avant de la commander, il doit pouvoir avoir facilement accès à la réponse de 'quelqu'un d'autre du labo possède-t-il déjà ce que j'ai besoin?'.


Merci énormément, je vais lire le lien que tu me conseilles

[Jasmine80]

[QUOTE=Jasmine80;6834879]Ca ne me semble pas contradictoire. Disons qu'au niveau du laboratoire, une souche est un tube contenant une bactérie précise et gérée par une personne précise. Si deux personnes différentes du labo possédaient 2 mêmes types de bactéries, dans 2 tubes différents, notés différemment et rangés à deux endroits différents, il faudrait les considérer comme 2 entrées différentes dans la base de données.


Peut-être est-ce envisageable pour le futur mais, il y a plusieurs milliers de tubes contenant des bactéries, ranger à différents endroits et annotés selon le système propre de chaque utilisateur. Leur demander de tous renommer selon un code général au labo est difficilement envisageable.





En quoi est-ce que je mélange les genres? Ce sont des données renseignant sur la souche ... si je divise trop mes données, je vais me retrouver avec une multitude d'entités ne contenant chacune qu'un attribut. C'est plutôt arbitraire comme division, non?



Oui


Trouver un système d'annotation précis et commun à tous?

je pense que je comprends


En fait, à la base, ma DB ne contenait qu'une seule table et était très fonctionnel. Le but n'est pas d'avoir une DB de compétition mais un outil pratique permettant de centraliser les souches que possède le laboratoire. Quand quelqu'un du labo à besoin d'une souche, avant de la commander, il doit pouvoir avoir facilement accès à la réponse de 'quelqu'un d'autre du labo possède-t-il déjà ce que j'ai besoin?'. Au pire, je passe par un tableur ... mais autant apprendre à bien faire les chose et me former sur les bases de données. Ensuite, je ferai une interface graphique.


Merci énormément, je vais lire le lien que tu me conseilles

[Richard_35]

Bonjour Jasmine80,

OK, ça se précise : je réponds, d'abord, à tes questions (1°/) et je précise ensuite (2°/).

1°/ Tes questions :

==> attention à ne pas mélanger les genres !... "terrain"/"référence" est un type de souche, "origine" est un pays d'origine lié à la souche, si j'ai bien compris. Si c'est le cas, ces informations ne sont pas au même niveau

En quoi est-ce que je mélange les genres? Ce sont des données renseignant sur la souche ... si je divise trop mes données, je vais me retrouver avec une multitude d'entités ne contenant chacune qu'un attribut. C'est plutôt arbitraire comme division, non?

==> c'est l'avantage d'une base de données. Dans l'exemple, si tu ne crées pas une entité Pays, concrètement, il faudra saisir le nom du pays pour chaque tube, ce qui n'est pas très efficace si tu souhaites effectuer des recherches, des statistiques par pays. En effet, si, pour un tube, l'utilisateur indique "Pays-Bas", pour un autre tube "Hollande" et pour encore un autre "Paysbas", le système considèrera que ces 3 tubes proviennent de 3 pays différents !...
Donc, oui, il faut diviser les données en entités logiques sachant que, si elles sont logiques, elles sont, du même coup, nécessaires.

La souche semble être le point d'entrée de tout le système, non ?

Oui

==> voir le point 2°/.

Si une souche ne peut être gérée QUE par un seul manager, alors ce manager devrait "la créer" en la codifiant dans le futur système de gestion.

Trouver un système d'annotation précis et commun à tous?

==> oui, cela ne fait pas un pli !


2°/ Précisions
En fait, le point d'entrée est, physiquement, un "tube" que tu sembles appeler "souche" : c'est un point fondamental qui n'était pas très clair. Ce sont donc les tubes physiques qu'il faut numéroter de manière unique.
Avant d'aller plus loin, peut-il y avoir plusieurs tubes pour une même souche ?

[Jasmine80]

En fait, le point d'entrée est, physiquement, un "tube" que tu sembles appeler "souche" : c'est un point fondamental qui n'était pas très clair. Ce sont donc les tubes physiques qu'il faut numéroter de manière unique.
Avant d'aller plus loin, peut-il y avoir plusieurs tubes pour une même souche ?

C'est parce que dans le langage usuel du labo, on parle de 'souche'

Oui, une souche, c'est une colonie bactérienne. Pour une même souche, on peut avoir des tubes glycerol_stock, des tubes DNA_stock et des RNA_stock. De 0 à n pour chaque type de tube pour chaque souche. On s'y retrouve grâce aux références (entité Reference) de la colonie bactérienne et grâce à la notation ainsi que la place de rangement du tube stock (attributs des entités glycerol_stock, DNA_stock et des RNA_stock)


Merci.

[Jasmine80]

==> c'est l'avantage d'une base de données. Dans l'exemple, si tu ne crées pas une entité Pays, concrètement, il faudra saisir le nom du pays pour chaque tube, ce qui n'est pas très efficace si tu souhaites effectuer des recherches, des statistiques par pays. En effet, si, pour un tube, l'utilisateur indique "Pays-Bas", pour un autre tube "Hollande" et pour encore un autre "Paysbas", le système considèrera que ces 3 tubes proviennent de 3 pays différents !...
Donc, oui, il faut diviser les données en entités logiques sachant que, si elles sont logiques, elles sont, du même coup, nécessaires.

Je n'ai pas bien compris ... si je crée une entité Pays ... il faudra quand même pour chaque souche indiquer de quel pays elle vient ... où au mieux indiquer la clé primaire de la table 'Pays' ... est-ce cela l'utilité? Indiquer tous les pays différents dans une table afin qu'il n'y ait plus d'erreur d'orthographe possible et que les personnes soient limitées par les données de celle-ci? Ca, je peux comprendre, c'est le principe des types 'liste' d'attributs ... mais il faudra quand même encoder pour chaque souche le lien vers la table 'pays'

[Richard_35]

Bonsoir Jasmine80,

Pour une même souche, on peut avoir des tubes glycerol_stock, des tubes DNA_stock et des RNA_stock

==> d'après ce que j'ai compris, le labo reçoit 1 tube : c'est ce tube qui doit être identifier de manière unique. Le tube que reçois le labo reçoit :

• est de type "tube glycerol_stock", "tubes DNA_stock" ou "RNA_stock" ?

ou

• est-ce le labo qui scinde le tube reçu en ces 3 types ?

si je crée une entité Pays ... il faudra quand même pour chaque souche indiquer de quel pays elle vient ... où au mieux indiquer la clé primaire de la table 'Pays' ... est-ce cela l'utilité? .../... mais il faudra quand même encoder pour chaque souche le lien vers la table 'pays' .../...

==> oui via une liste déroulante présentant la liste des pays de la table Pays : c'est la clé primaire de la table Pays qui sera stockée dans la table Souche. En conséquence, les statistiques par pays seront aisées à réaliser.