Souches bactériennes

**Jasmine80** · 16/08/2012, 14h29

Envoyé par f-leb

Recoucou également

ModelSphere ne gère pas la spécialisation/généralisation au niveau conceptuel (dans les MCD façon Merise en tout cas) comme le fait apparemment DB-Main avec le triangle blanc.
On s’en sort quand même avec des cardinalités --0,1----1,1---.

Mais ça je l’ai déjà expliqué ici même…

Dans l’explorateur, il te reste à convertir le diagramme (clic droit puis "Convertir en modèle relationnel…")

Ok, merci, j'attends encore un peu que les autres valident ou invalident mon MCD puis je testerai

**Richard_35** · 16/08/2012, 18h07

Bonjour à tous (ça commence à faire du monde...

),

Concernant la partie Manager <=> Strain <=> Stock de ton MCD, d'après ce que j'ai compris, le labo peut recevoir un STOCK (StockId) sans forcément passer par un STRAIN (Internal_ref) : est-ce exact ?

**JPhi33** · 17/08/2012, 19h33

Bonsoir,

Remarques sur le dernier MCD de Jasmine
- Toutes les cardinalités sont correctes et conformes aux différents messages échangés entre les participants.
- Pour NA_stock, suis les explications de Fabien (f-leb) afin de modéliser correctement la spécialisation. Il ne s'agit pas que d'une mise en forme, cela impacte la manière dont les tables sont générées ensuite par Open ModelSphere. Je ne connais pas bien ce logiciel mais normalement, il devrait générer une table NA_stock dont la clé est celle de la table Stock puisqu'elle en hérite.
- Quelques propriétés restent en double dans Strain et Reference : internal_ref, Accession, external_ref

Concernant les types
Il y a un type de stock et un autre type qui a varié au fil des discussions et des modèles : DNA_RNA puis DNA puis retour à NA. Pour simplifier, pourrait-on envisager de n'avoir qu'une entité type, à savoir stock_type, dont les valeurs seraient 'gDNA', 'pDNA', 'RNA' et 'Glycerol' ? Il s'agit ici de traduire correctement le langage métier et donc , à terme, d'offrir une interface "parlante" aux utilisateurs, plus précisément, parlant le même langage qu'eux.

En clair, ce n'est pas la même chose pour un utilisateur d'avoir 1) :
une liste déroulante "Type de stock" avec les valeurs 'gDNA', 'pDNA', 'RNA' et 'Glycerol'

que d'avoir 2) :
- une première liste "Type de stock" avec 'DNA', 'RNA' et 'Glycerol'
- puis, s'il choisit DNA, une seconde liste (ou bouton d'option, ou autre) "Type d'ADN" lui demandant de choisir 'gDNA' ou 'pDNA'.

ou encore 3) :
- une première liste "Type de stock" avec 'NA' et 'Glycerol'
- puis, s'il choisit NA, une seconde liste "Type d'AN" lui demandant de choisir 'gDNA', 'pDNA' ou 'RNA'

ou même 4) :
- une première liste "Type de stock" avec 'NA' et 'Glycerol'
- puis, s'il choisit 'NA', une seconde liste "Type d'AN" lui demandant de choisir 'DNA' ou 'RNA'
- puis, s'il choisit 'DNA' une 3e liste avec 'gDNA' ou 'pDNA'

L'une ou plusieurs de ces visions peuvent même être choquantes pour l'utilisateur. Il aura l'impression qu'on ne lui a pas donné le bon outil, qu'on n'a pas compris son métier. Il faut donc recueillir l'avis des membres du labo. C'est sur cette base que doit se faire la modélisation (la spécialisation) des entités du stock car une entité "xxx_type" ne peut s'appliquer qu'à un étage de la spécialisation.

La question des entrées
Richard pose une question importante : les entrées au labo doivent-elles enregistrées et conservées en tant que telles ? (entrée 1 : une souche, entrée 2 : un glycerol, etc.) Selon la réponse, la modélisation d'une entité Entrée est pertinente ou non.

Envoyé par Jasmine80

Peut importe la forme reçue en entrée, elle est considérée comme un stock. Il ne faut pas distinguer la forme d'entrée des stocks.

Il semblerait donc que Entrée = Stock et qu'une entité Entrée ne soit pas nécessaire.

**Jasmine80** · 20/08/2012, 09h37

Envoyé par Richard_35

Bonjour à tous (ça commence à faire du monde...

),

Concernant la partie Manager <=> Strain <=> Stock de ton MCD, d'après ce que j'ai compris, le labo peut recevoir un STOCK (StockId) sans forcément passer par un STRAIN (Internal_ref) : est-ce exact ?

Non, c'est faux. Un STOCK, peu importe son type, a toujours un STRAIN qui permet de l'identifier.

**Jasmine80** · 20/08/2012, 09h49

Envoyé par JPhi33

- Pour NA_stock, suis les explications de Fabien (f-leb) afin de modéliser correctement la spécialisation. Il ne s'agit pas que d'une mise en forme, cela impacte la manière dont les tables sont générées ensuite par Open ModelSphere. Je ne connais pas bien ce logiciel mais normalement, il devrait générer une table NA_stock dont la clé est celle de la table Stock puisqu'elle en hérite.

Oui, je vais y regarder

Envoyé par JPhi33

- Quelques propriétés restent en double dans Strain et Reference : internal_ref, Accession, external_ref

Oui, c'est une erreur. STRAIN n'a aucun attribut, si ce n'est StrainId. STRAIN est plus comme un 'carrefour' qui sert de lien pour regrouper les stocks apparentés. C'est plus une entité 'fonctionnelle'.

Envoyé par JPhi33

Concernant les types
Il s'agit ici de traduire correctement le langage métier et donc , à terme, d'offrir une interface "parlante" aux utilisateurs, plus précisément, parlant le même langage qu'eux.

...

L'une ou plusieurs de ces visions peuvent même être choquantes pour l'utilisateur. Il aura l'impression qu'on ne lui a pas donné le bon outil, qu'on n'a pas compris son métier. Il faut donc recueillir l'avis des membres du labo. C'est sur cette base que doit se faire la modélisation (la spécialisation) des entités du stock car une entité "xxx_type" ne peut s'appliquer qu'à un étage de la spécialisation.

Je vais voir ce que la majorité préfère ... mais en général, les autres me disent 'peu importe, fais comme ça te semble le mieux'. Donc, j'aurais tendance à faire au plus simple : une seule liste (choix 1).

Envoyé par JPhi33

Il semblerait donc que Entrée = Stock et qu'une entité Entrée ne soit pas nécessaire.

oui, c'est aussi ce qu'il me semble

Merci beaucoup à vous deux de l'aide que vous m'apportez

**Jasmine80** · 20/08/2012, 09h55

Envoyé par f-leb

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 ?

... désolée pour la réponse si tardive, je n'avais pas vu la question

Ils sont tous complétés et très importants. C'est l'endroit ou est rangé le stock. C'est même une des choses les plus importantes de la base, savoir ce que possède le labo et surtout où le retrouver.

Merci également pour ton aide f-leb

**Jasmine80** · 20/08/2012, 10h04

Voila ce que cela donne (je dois encore voir et discuter avec le labo au sujet de la spécialisation) :

Uploaded with ImageShack.us

f-leb ... sais-tu pourquoi lors de la définition de ma clé primaire, j'obtiens un nombre au lieu du dessin de clé pour StrainId et ReferenceId?

Merci

**Jasmine80** · 20/08/2012, 10h51

Recoucou,

Je viens de discuter avec ma collègue qui gère le projet avec moi et qui est dans la pratique. Elle pense comme moi, qu'une seule liste est préférable.

Je rappelle que les utilisateurs ne pourront qu’interroger la DB et non la modifier. Il faudra qu'ils puissent cocher plusieurs choix dans la liste des types de stock mais ça, je verrai quand je passerai au codage de l'interface graphique.

C'est sur cette base que doit se faire la modélisation (la spécialisation) des entités du stock car une entité "xxx_type" ne peut s'appliquer qu'à un étage de la spécialisation.

Donc, un seul étage de spécialisation? Je laisse 'glycérol' en entité 'mère' et les autres en une même spécialisation 'fille'?

Merci beaucoup,

**f-leb** · 20/08/2012, 12h12

bonjour,

Envoyé par Jasmine80

f-leb ... sais-tu pourquoi lors de la définition de ma clé primaire, j'obtiens un nombre au lieu du dessin de clé pour StrainId et ReferenceId?

Dans la barre d'outils, il faut utiliser le 1er icone pour la clé primaire.

Les autres icones sont là pour mettre en place les clés alternatives.

**Jasmine80** · 20/08/2012, 13h11

Envoyé par f-leb

bonjour,

Dans la barre d'outils, il faut utiliser le 1er icone pour la clé primaire.

Les autres icones sont là pour mettre en place les clés alternatives.

merci ça fonctionne
je n'utilisais pas la barre d'outils mais 'clic droit' puis 'ajouter clé primaire'

**f-leb** · 20/08/2012, 19h52

Envoyé par Jasmine80

Envoyé par f-leb

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 ?

Ils sont tous complétés et très importants. C'est l'endroit ou est rangé le stock. C'est même une des choses les plus importantes de la base, savoir ce que possède le labo et surtout où le retrouver.

Si c'est fondamental, il y a peut-être un travail de modélisation à faire de ce côté là aussi. Si on peut saisir des souches dans le "freezer" F1 situé dans la "room" R1 alors qu'il se situe dans la "room" R2, il y a un problème.

Il faudrait détailler cette partie si tu as un doute.

**JPhi33** · 21/08/2012, 01h55

Envoyé par Jasmine80

Je viens de discuter avec ma collègue qui gère le projet avec moi et qui est dans la pratique. Elle pense comme moi, qu'une seule liste est préférable.

Dans ce cas, tu n'as pas besoin de NA_type. Supprime cette entité. Les occurrences de stock_type sont donc 'gDNA', 'pDNA', 'RNA' et 'Glycerol'.

Envoyé par Jasmine80

Donc, un seul étage de spécialisation? Je laisse 'glycérol' en entité 'mère' et les autres en une même spécialisation 'fille'?

Oui, un seul "étage" de spécialisation tel que modélisé dans ton MCD. L'entité mère est stock_type. Il ne faut surtout pas la nommer 'glycerol', ce serait faux. Pour résumer :
- l'entité "mère" Stock contient les occurrences de tous les stocks, qu'ils soient acides nucléiques ou glycérols
- l'entité "fille" NA_stock ne contient que des occurrences de stocks d'acides nucléiques.

Quand tu auras généré le modèle relationnel, tu auras, pour cette partie de ton MCD, 3 tables : stock, stock_type et NA_stock. Imaginons que tu enregistres un stock de pADN et un stock de glycérol. Tu auras :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Table stock_type
StockTypeId StockType
----------- ---------
1           gDNA
2           pDNA
3           RNA
4           Glycerol

Table Stock
StockId Date       ... StockTypeId
------- ---------- --- -----------
1       20/08/2012 ... 2
2       20/08/2012 ... 4

Table NA_stock
StockId Concentration
------- -------------
1       12

Pour le stock 1 de type pDNA, il y a une ligne dans la table stock et une dans la table NA_stock, identifiées par la même valeur de StockId.
Pour le stock 2 de type Glycerol, seule la ligne de la table stock existe.

**Jasmine80** · 21/08/2012, 08h52

Envoyé par f-leb

Si c'est fondamental, il y a peut-être un travail de modélisation à faire de ce côté là aussi. Si on peut saisir des souches dans le "freezer" F1 situé dans la "room" R1 alors qu'il se situe dans la "room" R2, il y a un problème.

Il faudrait détailler cette partie si tu as un doute.

... à oui, en effet, il y aurait un problème ... merci d'avoir souligné ce point

ça me semblait une DB toute simple à réaliser à première vue mais ça ne cesse de devenir de plus en plus complexe

**Jasmine80** · 21/08/2012, 09h06

Envoyé par JPhi33

Quand tu auras généré le modèle relationnel, tu auras, pour cette partie de ton MCD, 3 tables : stock, stock_type et NA_stock. Imaginons que tu enregistres un stock de pADN et un stock de glycérol. Tu auras :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Table stock_type
StockTypeId StockType
----------- ---------
1           gDNA
2           pDNA
3           RNA
4           Glycerol

Table Stock
StockId Date       ... StockTypeId
------- ---------- --- -----------
1       20/08/2012 ... 2
2       20/08/2012 ... 4

Table NA_stock
StockId Concentration
------- -------------
1       12

Pour le stock 1 de type pDNA, il y a une ligne dans la table stock et une dans la table NA_stock, identifiées par la même valeur de StockId.
Pour le stock 2 de type Glycerol, seule la ligne de la table stock existe.

Jean-Phil, merci beaucoup du temps passé à ces explications, c'est beaucoup plus clair maintenant.

... cette nuit ... il m'est venu une question ... et oui, j'y pense même la nuit ... je me demande si l'entité Strain est vraiment nécessaire ou si il ne vaudrait mieux pas replacer l'entité Reference au centre du modèle. Normalement, une souche n'a qu'une référence et une référence est unique à la souche ... le 1,N qui apparait dans la relation était là en filet de sauvetage. Comme chacun travaille dans son coin, qu'il n'y a aucune convention en ce qui concerne l'attribution des références, par un mauvais hasard, il se pourrait que 2 souches différentes, gérées par deux managers différents, aient reçues les mêmes références. Néanmoins, c'est peu probable et ReferenceId gèrera ce problème. De plus, j'aimerais essayer de faire passer une convention afin que l'attribution des références se fasse de façon plus rigoureuse, entre autre en tenant compte de ce qui existe déjà chez les autres managers de souches.

Ma question est donc : ne vaut-il pas mieux repasser à un MCD centré sur l'entité Reference comme j'étais partie en premier lieu?

Merci beaucoup;

**Jasmine80** · 21/08/2012, 09h18

voici ce que cela donnerait :

Uploaded with ImageShack.us

f-leb ... j'ai un gros problème. J'ai fermé mon projet en cliquant sur la petite croix à droite, ce qui a laissé Open ModelSphere ouvert mais un écran noir a remplacé mon projet clos. Mes projets apparaissent toujours bien dans les différents fichiers à ouvrir mais quelque soit celui que j'essaie d'ouvrir, c'est un écran noir qui s'affiche ... pourrais-tu m'aider s'il te plait?

Merci beaucoup

**f-leb** · 21/08/2012, 19h56

Envoyé par Jasmine80

f-leb ... j'ai un gros problème. J'ai fermé mon projet en cliquant sur la petite croix à droite, ce qui a laissé Open ModelSphere ouvert mais un écran noir a remplacé mon projet clos. Mes projets apparaissent toujours bien dans les différents fichiers à ouvrir mais quelque soit celui que j'essaie d'ouvrir, c'est un écran noir qui s'affiche ... pourrais-tu m'aider s'il te plait?

normalement dans l'explorateur à gauche, il suffit de développer ton projet et double-cliquer sur la ligne Diagramme, non ?

**JPhi33** · 21/08/2012, 23h43

Envoyé par Jasmine80

je me demande si l'entité Strain est vraiment nécessaire ou si il ne vaudrait mieux pas replacer l'entité Reference au centre du modèle. Normalement, une souche n'a qu'une référence et une référence est unique à la souche

Effectivement, c'est un bon argument pour supprimer l'entité Strain.

Maintenant que Reference est au centre du modèle, on peut se poser une autre question. Quel est le concept métier le plus important : Souche ou Référence ? Tu parles de "Référence de souche" et de "manager de souche". Incontestablement c'est la Souche qui est le concept majeur et qui est parlant pour le labo. Les différentes références en sont des propriétés.

Donc il me semble qu'il serait judicieux de renommer l'entité Reference en Strain :
- c'est beaucoup plus cohérent vis-à-vis de l'association avec StrainType
- c'est plus logique de dire qu'une souche a une classification, plutôt que de dire qu'une référence a une classification
- etc.

Envoyé par Jasmine80

j'aimerais essayer de faire passer une convention afin que l'attribution des références se fasse de façon plus rigoureuse, entre autre en tenant compte de ce qui existe déjà chez les autres managers de souches.

J'ai traité plusieurs un cas similaires.

Le principe est d'établir une codification de la référence avec les managers et que tout le monde soit d'accord. Ensuite, c'est l'application informatique qui doit attribuer chaque référence, notamment afin de ne jamais avoir 2 fois le même (inévitable) numéro de séquence présent dans toute codification (ce numéro est pris dans une table et mis à jour à chaque fois).

Dans la pratique, lorsqu'un manager a besoin d'une référence, il se connecte à l'application, indique les informations nécessaires au calcul puis l'application lui retourne la référence. Evidemment, ceci peut se faire au moment de l'enregistrement d'un stock.

**Jasmine80** · 23/08/2012, 09h17

Envoyé par f-leb

normalement dans l'explorateur à gauche, il suffit de développer ton projet et double-cliquer sur la ligne Diagramme, non ?

impec, merci, je n'aurais pas trouvé toute seule

**Jasmine80** · 23/08/2012, 09h20

Envoyé par JPhi33

Donc il me semble qu'il serait judicieux de renommer l'entité Reference en Strain :
- c'est beaucoup plus cohérent vis-à-vis de l'association avec StrainType
- c'est plus logique de dire qu'une souche a une classification, plutôt que de dire qu'une référence a une classification
- etc.

Oui, je vais faire ainsi

Envoyé par JPhi33

J'ai traité plusieurs un cas similaires.

Le principe est d'établir une codification de la référence avec les managers et que tout le monde soit d'accord. Ensuite, c'est l'application informatique qui doit attribuer chaque référence, notamment afin de ne jamais avoir 2 fois le même (inévitable) numéro de séquence présent dans toute codification (ce numéro est pris dans une table et mis à jour à chaque fois).

Dans la pratique, lorsqu'un manager a besoin d'une référence, il se connecte à l'application, indique les informations nécessaires au calcul puis l'application lui retourne la référence. Evidemment, ceci peut se faire au moment de l'enregistrement d'un stock.

Je vais y réfléchir et en discuter avec le groupe, merci pour les conseils