Discussion :

[blackadder]

Bonjour,
Je suis chargé de reprendre une base de données de gestion des instruments d’un laboratoire. Devant migrer d’un outil développé sous ACCESS vers un outil avec une présentation « WEB ». J’ai commencé par refaire un MCD afin de lui intégrer les retours des utilisateurs de la première version :

Petite spécification pour comprendre mon MCD

• Une campagne de mesure est une période temporelle durant laquelle un ensemble de systèmes de mesure et d’instruments est utilisées pour réaliser des mesures dans un lieu précis.
• Un système de mesure se compose d’instrument (et de sous système).
• Un instrument est défini par des caractéristiques communes à toutes les familles, et des caractéristiques héritées de sa famille.
• Un instrument possède un planning, cela permet de connaître ces périodes d’indisponibilités et d’agir en conséquence.
• On peut suivre la vie d’un instrument, système (sous système) et campagne de mesure grâce à une fiche de vie contenant des informations (utilisations, problèmes rencontrés, etc...)
• L’outil permet d’associer des documents (qualités, procédure d’étalonnage, résultat de mesure) aux familles, instruments, systèmes et campagnes.

Il manque deux associations que je n’ai pas pu créer à cause de limitation du logiciel que j’utilise pour représenter le MCD:

• de « famille » sur « famille » : je désire réaliser une arborescence pour représenter les familles. Cela me permettra d’avoir des enregistrements de type « oscilloscope », « numérique » pour créer la famille « oscilloscope numérique » qui sera utilisé pour caractériser des instruments.
• de « systeme » sur « systeme » : pour permettre de créer des systèmes de mesure composées de sous système.

Il s'agit la de ma première vrai modélisation, je n'ai qu’une expérience purement scolaire. J’aimerais avoir des commentaires/avis de personnes expérimentées avant de me lancer dans le MPD/développement.

[fsmrel]

Bonsoir,


J’ai effectué un survol du MCD, a priori il n’y a rien de véritablement choquant. Évidemment, il y a toujours quelque chose à dire (par exemple, on n’identifie pas une entité-type par un nom, cf. Campagne, Système, etc.) Certaines simplifications sont peut-être à a apporter, des contraintes à mettre en évidence. JPHi33 et TheLeadingEdge auront certainement des questions à vous poser. Wait and see.

Je vous suggère d’utiliser un outil qui permette de modéliser les nomenclatures. Ainsi, l’ébauche de MLD ci-dessous a été réalisée avec MySQL Workbench (gratuit). D’accord, au sens strict du terme, ça n’est pas un MCD mais il est très facile d’inférer celui-ci.




Puisqu’on est au niveau MLD, au lieu de parler d’entités-types, on parle de tables, que ce soit pour des entités-types fortes (kernels) telles que Campagne Instrument ou Systeme ou pour des associations-types (qui peuvent être vues ici comme des entités-types associatives), cas de InstrSyst, SystCamp, SysSyst.

Les clés primaires des tables sont symbolisées par des petites clés jaunes. Les clés étrangères (qui ne sont pas en même temps clés primaires) par des losanges rouges et les attributs lambda par des losanges bleus (attention les daltoniens...)

Les liens entre tables sont représentés par des traits pleins ou en pointillés : dans le premier cas, la clé primaire (simultanément clé étrangère) d’une table dépendante est héritée de celle de la (ou des) tables(s) parentes(s), on retrouve le principe de l’identification relative du niveau MCD. Dans le second cas, la clé primaire de la table parente ne fait l’objet que d’une clé étrangère (cas de l’attribut SystemeParentId de la table SystSyst).

La représentation des cardinalités est simple à comprendre : une valeur de l’attribut InstrumentId de la table Instrument peut se retrouver de 0 à N fois dans la table InstrSyst (attribut InstrumentId). Une valeur de l’attribut InstrumentId de la table InstrSyst fait référence à exactement une valeur de la table Instrument (attribut InstrumentId). Une valeur de l’attribut SystemeId de la table Systeme doit se retrouver de 1 à N fois dans la table InstrSyst (attribut SystemeId), etc.

A noter qu’une valeur de l’attribut SystemeId de la table SystSyst fait référence à exactement une valeur de la table Système (attribut SystemeId), mais aussi qu’une valeur de l’attribut peut se retrouver au plus une fois dans l’attribut SystemeId de la table SystSyst (effet 0,1).

A suivre.

[JPhi33]

blackadder,

Quelques remarques/questions après une première lecture du MCD :

- Une campagne de mesure est une période temporelle durant laquelle un ensemble de systèmes de mesure et d’instruments est utilisées pour réaliser des mesures dans un lieu précis.
- Un système de mesure se compose d’instrument (et de sous système).

1. Pourquoi une cardinalité 0,1 sur la patte "Campagne"---"Utilise a" ? N'y a-t-il pas toujours un lieu de mesure ?

2. Je soupçonne des incohérences dans le triplet d'associations "Utilise pour", "Compose" et "Compose2" entre les entités Campagne, Système et Instrument :

2.1. Un Instrument peut-il réellement faire partie de plusieurs Systèmes ?

2.2. Dans une Campagne, on utilise des Systèmes, eux-mêmes composés d'Instruments. Quelle est l'utilité de l'association Compose2 ? Cela signifierait que seuls certains Instruments d'un Système sont utilisés dans le cadre d'une Campagne. Si tel est le cas, pourquoi l'association "Utilise pour" ? En effet, si on n'utilise pas la totalité d'un Système, quel avantage y a-t-il à savoir qu'on l'utilise pour la Campagne, il suffit de connaitre la liste des Instruments par l'association "Compose 2" ?

2.3. Enfin, il existe un risque de redondance, par exemple :
- Campagne1 --(utilise pour)-- Système1 --(compose)-- Instrument1
- Campagne1 --(compose2)-- Instrument1
L'Instrument1 est présent 2 fois dans la liste des instruments utilisés dans la Campagne1. Cela ne risque-t-il pas de poser un problème ?

Un instrument possède un planning, cela permet de connaître ces périodes d’indisponibilités et d’agir en conséquence.

3. Quelle est l'utilité des associations "Utilisé par" et "Utilisé par 2" entre Planning et, respectivement, Système et Campagne ?

3.1. S'il s'agit de connaître le planning des instruments depuis Système et Campagne, alors ces associations sont plus qu'inutiles (elles ne correspondant à aucune réalité). En effet, pour un Système, on connaît la liste des instruments par l'association "Compose" ; on a donc accès aux plannings de l'instrument. Idem pour une Campagne.

3.2. L'alternative parait peu envisageable : il s'agirait des plannings des Systèmes et Campagnes ; les notions d'indisponibilité de Système et Campagne sont peu crédibles. Au cas où on peut dire ceci : les cardinalités des pattes Planning sont fausses toutes les 3 (elles devraient être toutes les 3 de 0,1 dans ce contexte)

On peut suivre la vie d’un instrument, système (sous système) et campagne de mesure grâce à une fiche de vie contenant des informations (utilisations, problèmes rencontrés, etc...)

4. La modélisation n'est pas cohérente avec cette règle. En effet, dans le MCD :
- Un instrument a plusieurs fiches de vie et non pas une seule
- La même fiche de vie peut être partagée par plusieurs instruments. Est-ce réel ?

5. Une fiche de vie est "remplie par" des systèmes et des campagnes ? Attention à ne pas tenter de modéliser le comportement du SI (l'aspect dynamique) dans le MCD. "remplie par" semble relever du MCT et non pas du MCD.

L’outil permet d’associer des documents (qualités, procédure d’étalonnage, résultat de mesure) aux familles, instruments, systèmes et campagnes.

6. Cette partie du MCD me semble lourde mais je n'ai pas de remarque constructive à son sujet.


Voila pour une première réflexion sur ce MCD.


JPhi33

[blackadder]

Merci fsmrel, je vais transcrire mon mcd sous ton logiciel des ce soir.

Merci JPhi33, je vais essayer de répondre au mieux à tes questions

1. Pourquoi une cardinalité 0,1 sur la patte "Campagne"---"Utilise a" ? N'y a-t-il pas toujours un lieu de mesure ?

Une erreur de ma part, la cardinalité doit être 1,1. Une campagne a toujours un lieu de mesure

2.1. Un Instrument peut-il réellement faire partie de plusieurs Systèmes ?

Un instrument peut effectivement appartenir à plusieurs systèmes de mesure.

2.2 Dans une Campagne, on utilise des Systèmes, eux-mêmes composés d'Instruments. Quelle est l'utilité de l'association Compose2 ?

Un système peut être un ensemble d’instrument capteur pré-ampli-ampli-analyseur. Et dans le cadre d’une campagne, il faut lui adjoindre un instrument ordinateur pour pouvoir acquérir/sauvegarder les données.
Les instruments associés directement a une campagne ne soit pas de la même famille que ceux composant un système

2.3 L'Instrument1 est présent 2 fois dans la liste des instruments utilisés dans la Campagne1. Cela ne risque-t-il pas de poser un problème ?

Les instruments associés directement a une campagne ne soit pas de la même « famille » que ceux composant un système. Ces problèmes de redondance seront traités par la « couche » métier de l’outil

3. Quelle est l'utilité des associations "Utilisé par" et "Utilisé par 2" entre Planning et, respectivement, Système et Campagne ?

En créant ces associations, je voulais surtout pouvoir obtenir à partir du planning d’un instrument le système ou la campagne responsable de cette indisponibilité, sachant qu’une indisponibilité peux également être dut a l’envoi de l’instrument a l’étalonnage.

4. La modélisation n'est pas cohérente avec cette règle. En effet, dans le MCD :
- Un instrument a plusieurs fiches de vie et non pas une seule
- La même fiche de vie peut être partagée par plusieurs instruments. Est-ce réel ?

Valable pour la question 5
J’ai mal expliqué ce point,
La fiche de vie sera le regroupement de l’ensemble des « enregistrements » affilié à un instrument, système, campagne.
Chaque « enregistrement » ne peut être associé qu’à un seul instrument, système, campagne.
Il est vrai que la fiche de vie d’un instrument pourra être remplie par un système, instrument mais cette fonctionnalité n’est pas représentée ici (ou alors par erreur).

6. Cette partie du MCD me semble lourde mais je n'ai pas de remarque constructive à son sujet.

Cela ne représente que la partie immergé de l’iceberg « gestion des documents »




Il y a une contrainte d’assurance qualité forte derrière cette base. On tient a pouvoir retrouver, dans quelques années, l’ensemble des instruments ayant servi a réaliser telle ou telle campagne de mesure. En conséquence, même si ce MCD ne le représente pas, il n’y aura que très peu de suppression d’ « enregistrement ».

merci de votre ecoute

[JPhi33]

Bonjour,

Voici la suite pour certains points.

2. Dans ce cas on peut distinguer deux populations d'instruments : ceux faisant partie d'un système (capteurs) et les autres (ordinateurs). La modélisation qui en découle fait intervenir le concept de généralisation - spécialisation. Plutôt qu'un long discours, voici un petit schéma (attention, AnalyseSI ne sait pas modéliser la généralisation - spécialisation, concept pourtant essentiel du modèle EA) :


3. Une indisponibilité concerne 1 intrument pendant 1 période. Est-il réaliste que plusieurs systèmes ou campagnes puissent en être à l'origine ? Autrement dit, les cardinalités de "utilisé par" et "utilisé par 2" ne devraient-elles pas être "0,1" côté Planning au lieu de "0,n" ?

4 et 5.

Chaque « enregistrement » ne peut être associé qu’à un seul instrument, système, campagne.

Chaque occurrence de l'entité "ficheDeVie" représente un "enregistrement".
Voici ce que dit le MCD :
- un enregistrement peut être associé à 0,n instruments
- un enregistrement peut être associé à 0,n systèmes
- un enregistrement peut être associé à 0,n campagnes

Ta règle et ton MCD sont contradictoires, non ?


JPhi33

[blackadder]

[QUOTE=JPhi33;3454888]Bonjour,

Voici la suite pour certains points.

2. Dans ce cas on peut distinguer deux populations d'instruments : ceux faisant partie d'un système (capteurs) et les autres (ordinateurs). La modélisation qui en découle fait intervenir le concept de généralisation - spécialisation. Plutôt qu'un long discours, voici un petit schéma

L’idée est intéressante, Je pensais faire la distinction « instrument système » et « instrument campagne » au niveau de ma présentation. Comme cela, si certaines familles devaient changer d’association en passant de système à campagne ou vise versa, cela me permettra de faire évoluer l’outil plus rapidement.
Pourquoi une relation 1.n entre « instrument_capteur » et « système », cela me force à insérer l’instrument dans un système des sa création. Il peut s’agir d’un instrument de rechange non affecté a un système particulier.

3. Une indisponibilité concerne 1 instrument pendant 1 période. Est-il réaliste que plusieurs systèmes ou campagnes puissent en être à l'origine ? Autrement dit, les cardinalités de "utilisé par" et "utilisé par 2" ne devraient-elles pas être "0,1" côté Planning au lieu de "0,n" ?

Je lis mon association:
Une indisponibilité ne peut être causée que par un système, et un système peut rendre indisponible plusieurs instruments.

Alors que je lis ton association:
Une indisponibilité ne peut être causée que par un système, et un système ne peut rendre qu'un instrument indisponible.
Si j'ai bien compris ton raisonnement il faudrait que je change la cardinalité entre "planning" et "indisponible quand" de 1.1 à 1.n pour pouvoir associer une période a plusieurs instruments.

4 et 5.
Chaque occurrence de l'entité "ficheDeVie" représente un "enregistrement".
Voici ce que dit le MCD :
- un enregistrement peut être associé à 0,n instruments
- un enregistrement peut être associé à 0,n systèmes
- un enregistrement peut être associé à 0,n campagnes
Ta règle et ton MCD sont contradictoires, non ?

Oui, j'avais laissé (par oubli) les cardinalités par défaut d’analyseSI.

Mise à jour du MCD.

[JPhi33]

Bonjour,

Pourquoi une relation 1.n entre « instrument_capteur » et « système », cela me force à insérer l’instrument dans un système des sa création. Il peut s’agir d’un instrument de rechange non affecté a un système particulier.

J'ai mis en rouge cette cardinalité justement pour que tu y réagisses car c'est une déduction que j'avais faite à partir des phrases ci-dessous mais je n'étais pas du tout sûr de moi. J'avais supposé que tous les instruments "non ordinateurs" font obligatoirement partie d'un système. Comme ce n'est pas le cas, la cardinalité doit donc être 0,n.

Un système peut être un ensemble d’instrument capteur pré-ampli-ampli-analyseur. Et dans le cadre d’une campagne, il faut lui adjoindre un instrument ordinateur pour pouvoir acquérir/sauvegarder les données.
Les instruments associés directement a une campagne ne soit pas de la même famille que ceux composant un système

Je lis mon association:
Une indisponibilité ne peut être causée que par un système, et un système peut rendre indisponible plusieurs instruments.

Ca, c'est ce que tu lis dans le 3e MCD posté (message n° 6). Si tu regardes le 2e MCD (message n° 4) sur lequel j'ai basé mes précédentes remarques, les cardinalités sont bien 0,n pour les associations "utilisé par" et "utilisé par 2" côté entité Planning.

Alors que je lis ton association:
Une indisponibilité ne peut être causée que par un système, et un système ne peut rendre qu'un instrument indisponible.

Non, ce que j'ai dit ne se lit pas comme ça.

J'ai dit "... les cardinalités de "utilisé par" et "utilisé par 2" ne devraient-elles pas être "0,1" côté Planning au lieu de "0,n" ?", ce qui veut dire (du moins, telle était la question) que les cardinalités devraient être 0,1 sur la patte qui relie l'entité "Planning" à l'association "utilisé par" (et idem pour "utilisé par 2") -- schéma ci-dessous -- mais je n'ai rien dit sur l'autre cardinalité (côté Système et côté Campagne).

[ Planning ]--0,1----( utilisé par )----0,n--[ Système ]

Ce qui se lit : "Une indisponibilité peut être causée par un système et un système peut rendre indisponible plusieurs instruments." ou "Une indisponibilité est causée par 0 ou un système et un système rend indisponible 0 à plusieurs instruments."

Attention, dans le 3e MCD tu as modélisé :

[ Planning ]--0,1----( utilisé par )----0,1--[ Système ]

et :
[ Planning ]--0,1----( utilisé par 2 )----0,n--[ Campagne ]
(ici c'est correct)

Une suggestion au passage : renommer l'entité Planning en Indisponibilité et les associations "utilisé par..." en "causée par..."

Si j'ai bien compris ton raisonnement il faudrait que je change la cardinalité entre "planning" et "indisponible quand" de 1.1 à 1.n pour pouvoir associer une période a plusieurs instruments.

Mon raisonnement devait être un peu obscur car ce n'est pas du tout ce que je voulais dire (voir au-dessus).


Fiche de vie : Les cardinalités sont maintenant 1,1 sur les pattes "ficheDeVie"---"remplie par 2" et "ficheDeVie"---"remplie par 3" obligeant un enregistrement à être "rempli" par un système et une campagne. Est-ce normal ?


JPhi33

[blackadder]

Merci de tes remarques,
C’est vrai que je suis un peu rapide pour faire des changements, et je ne l’ai réfléchi pas assez ce qui provoque ce genre d’incohérence/erreur. Bon ce soir je fais un gros dodo, m’évitera de te dire/faire des conneries a cause de la fatigue.


Indisponibilité :
[ Planning ]--0,1----( utilisé par 2 )----0,n--[ Campagne ]
D’accord, je pensais bien à quelques choses comme cela.


Fiche de vie :
Un « enregistrement » ne peut être rempli que par un instrument ou un système ou une campagne, mais il doit nécessairement être associé à une de ces entités. C’est ce que j’ai représenté (maladroitement) avec ces cardinalités. Les cardinalités doivent être de 0,1, l’aspect « métier » s’assurant du respect de la précédente règle.

Encore merci pour ta patience et tes remarques constructives (suis fan).

[JPhi33]

Bonjour,

Pour moi, tout a l'air clair maintenant sauf les fiches de vie. Ce que j'en ai compris jusqu'à présent est confus car, pour moi, deux notions se mélangent :

- un enregistrement (c'est-à-dire une occurrence de l'entité "ficheDeVie") est un événement de la vie de : un Instrument ou bien un Système ou bien une Campagne
==> un seul des 3

- un enregistrement est rempli par : un Instrument ou un Système ou une Campagne
==> un des 3, deux des 3, les 3, mais pas aucun


Qu'en est-il ?

[blackadder]

- un enregistrement (c'est-à-dire une occurrence de l'entité "ficheDeVie") est un événement de la vie de : un Instrument ou bien un Système ou bien une Campagne

Oui, un enregistrement représente un événement de la vie d'un instrument ou bien d'un système ou bien d'une campagne. C’est bien l'un ou l'autre, mais pas les 3.

- un enregistrement est rempli par : un Instrument ou un Système ou une Campagne
==> Un des 3, deux des 3, les 3, mais pas aucun

Un et un seul des 3. Le fait de stocker l'ensemble des occurrences de l'entité "fichedevie" dans une seule "table" m'impose de mettre des cardinalités 0,1 sur les associations (remplie par). Le respect de la règle étant assurer par la couche "métier".
Si je crée une entité "fichedevieX" associé a chaque entité "Instrument", "Système», "Campagne". Je pourrais avoir des cardinalités 1,1, cela réduirait le risque d’erreur.

[ FicheDeVieIns ]--1,1---- ( remplie par) ---- 0,n -- [ Instrument ]
[ FicheDeVieSys ]--1,1---- ( remplie par 2 ) ---- 0,n --[ Systeme ]
[ FicheDeVieCmp ]--1,1---- ( remplie par 3 ) ---- 0,n --[ Campagne ]

[JPhi33]

Question finale :

Lorsqu'un enregistrement appartient à un instrument (par exemple) peut-il être "rempli par" un système ou une campagne.

Autrement dit (et c'est là où je voulais en venir) existe-t-il deux associations distinctes, l'une caractérisant l'appartenance de la fiche de vie, l'autre caractérisant l'origine des informations qui alimentent l'enregistrement ?

Par exemple, on aurait :

L'enregistrement n° 91 concerne l'oscilloscope n° 27, il contient le texte "l'instrument est tombé d'une hauteur de 1 mètre... (etc.)" qui a pour origine ("est rempli par") la campagne n°53.

Est-ce réaliste ou suis-je à côté de la plaque ? Si c'est réaliste, il manque évidemment des associations dans le MCD.


JPhi33

[blackadder]

Question intéressante.
Il faut que je me renseigne pour savoir si l’information est pertinente.

Cependant, je pense pouvoir retrouver cette information grâce à l’horodatage des enregistrements de la fiche de vie. Ce qui me permet soit en allant chercher dans l’entité « indisponibilité » si l’appareil était en campagne, et si oui laquelle. Ou alors en allant chercher directement dans l’entité « campagne », les campagnes auxquelles appartient l’instrument, et de chercher celle en cours ce jours la. Il se peut également que l’instrument en questions soit tombé au cours d’un rangement dans notre local de stockage.

Dédoubler l’association « remplie par » en une association « appartient » et une association « remplie par » m’éviterais des problèmes en cas d’erreur dans la saisie de la date dans une entité « indisponibilité » ou « campagne », et me permettrais de faire des requêtes plus simple pour retrouver cette information.

Comme nous sommes en plein dans les vacances je ne pense pas avoir une réponse avant lundi.
Je mets ce a quoi pourrait ressembler le mcd. J’ai fait une version allégée de la gestion des documents et des indisponibilités.

[JPhi33]

Cependant, je pense pouvoir retrouver cette information grâce à l’horodatage des enregistrements de la fiche de vie. Ce qui me permet soit en allant chercher dans l’entité « indisponibilité » si l’appareil était en campagne, et si oui laquelle. Ou alors en allant chercher directement dans l’entité « campagne », les campagnes auxquelles appartient l’instrument, et de chercher celle en cours ce jours la.

J'avais pris Campagne comme exemple mais le problème est le même pour Système et là, pas d'horodatage pour retrouver quoi que ce soit.

Dédoubler l’association « remplie par » en une association « appartient » et une association « remplie par » m’éviterais des problèmes en cas d’erreur dans la saisie de la date dans une entité « indisponibilité » ou « campagne », et me permettrais de faire des requêtes plus simple pour retrouver cette information.

Il ne faut pas penser qu'à l'optimisation des requêtes. Le MCD est aussi (voire avant tout) la représentation du réel. J'ai déjà expliqué sur le forum qu'une bonne abstraction (une bonne modélisation) a des répercussions positives au niveau physique se traduisant souvent par la simplification des requêtes, par une meilleure maintenabilité ou une meilleure évolutivité de la base de données qu'une modélisation moins proche de la réalité (ça coule de source mais il est bon de le rappeler de temps en temps).

Je mets ce a quoi pourrait ressembler le mcd. J’ai fait une version allégée de la gestion des documents et des indisponibilités.

Pour être complet, il faudrait modéliser une contrainte d'exclusion entre les 3 associations "Appartient à ..." d'une part et entre les 3 associations "Remplie par ..." d'autre part (AnalyseSI ne sait pas modéliser les contraintes).


JPhi33

[blackadder]

Oui, je me suis un peu emporté en parlant aussi vite des requêtes.

Je débute sous powerAMC, il me semble, en lisant la documentation Sybase, que je peux créer des contraintes d'exclusion:

• sur un MPD en utilisant des triggers
• sur un MCD en utilisant une règle de gestion.

Existe-t-il une autre solution ?

J'ai téléchargé la version d'évaluation de powerAMC, j’ai failli en tomber amoureux mais une incompatibilité avec word2007 a brisé le charme.

[JPhi33]

En ce qui concerne le modèle Entité-Association (MCD Merise), ce sont les règles de gestion que l'on traduit en modélisant des contraintes sémantiques de différents types dont les contraintes logiques (exclusion, inclusion, simultanéité, etc.) Ceci dit, peut-être que dans PowerAMC (que je n'ai pas) les contraintes se nomment "règles de gestion" ?

Au niveau physique, je crois savoir qu'il n'y a pas que les triggers qui permettent de traduire des contraintes logiques mais si fsmrel passe par ici il pourra t'en dire beaucoup plus long que moi.

As-tu obtenu une réponse à propos de la nécessité de distinguer des associations "rempli par xxx" et "Appartient à xxx" ?

[fsmrel]

Bonsoir,

On s’intéresse donc plus particulièrement à la fiche de vie et aux contraintes de type exclusion et compagnie la concernant.

Je lis ceci :

Fiche de vie : Un « enregistrement » ne peut être rempli que par un instrument ou un système ou une campagne, mais il doit nécessairement être associé à une de ces entités.
J’interprète donc les "ou" comme exclusifs.

Par ailleurs, tant que blackadder ne s’est pas prononcé, je ne tiens pas compte de la fine remarque de JPhi33 :

L'enregistrement n° 91 concerne l'oscilloscope n° 27, il contient le texte "l'instrument est tombé d'une hauteur de 1 mètre... (etc.)" qui a pour origine ("est rempli par") la campagne n°53.

Fin des remarques préalables. C'est parti pour la fiche de vie.

Fiche de vie est comme un soleil à 6 rayons, mais ces rayons sont tous facultatifs, ce qui fera que lors de la dérivation du MCD en MLD, vous aurez autant de clés étrangères composées chacune d’un attribut pouvant être marqué NULL. Et là, les tous les dangers sont possibles, il faut attaquer par une autre face.

A mon sens, une fiche de vie n’est pas une entité autonome, elle n’existe que relativement à une entité forte : instrument, système ou campagne, et dans ces conditions, elle n’en est qu’une propriété multivaluée. S’il faut supprimer un instrument (oui je sais, on ne supprime jamais, mais admettons) en toute logique on supprime ses fiches de vie. En effet, à quoi servirait de conserver une fiche de vie d’un instrument devant être supprimé ?

Dans ces conditions, le MCD prendrait l’allure suivante (Power AMC), l’identification relative étant symbolisée par la mise entre parenthèses de la cardinalité 1,1.





Je n’ai pas trop capté les subtilités concernant l’association "Remplie par", aussi je me suis contenté de mettre en œuvre un attribut xxxRedacteur et un booléen xxxBoollErr.

A ceci près, cette représentation convient pour les requêtes "verticales", du genre "Quelles sont les fiches de vie de tel instrument ?"

Code généré par Power AMC (j’utilise SQL Server) :

Code SQL :

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
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
/*==============================================================*/
/* Nom de SGBD :  Microsoft SQL Server 2000                     */
/* Date de création :  22/07/2008                               */
/*==============================================================*/
 
 
/*==============================================================*/
/* Table : Campagne                                             */
/*==============================================================*/
Create Table Campagne (
   CampagneId           Int                  Not null,
   CampagneNom          Varchar(48)          Not null,
   Constraint Campagne_PK Primary Key  (CampagneId)
)
;
 
/*==============================================================*/
/* Table : Instrument                                           */
/*==============================================================*/
Create Table Instrument (
   InstrumentId         Int                  Not null,
   InstrumentNom        Varchar(48)          Not null,
   Constraint Instrument_PK Primary Key  (InstrumentId)
)
;
 
/*==============================================================*/
/* Table : Systeme                                              */
/*==============================================================*/
Create Table Systeme (
   SystemeId            Int                  Not null,
   SystemeNom           Varchar(48)          Not null,
   Constraint Systeme_PK Primary Key  (SystemeId)
)
;
 
/*==============================================================*/
/* Table : Instr_Syst                                           */
/*==============================================================*/
Create Table Instr_Syst (
   InstrumentId         Int                  Not null,
   SystemeId            Int                  Not null,
   Constraint Instr_Syst_PK Primary Key  (InstrumentId, SystemeId),
   Constraint Instr_Syst_Instrument_1 Foreign Key (InstrumentId)
      References Instrument (InstrumentId),
   Constraint Instr_Syst_Systeme_2 Foreign Key (SystemeId)
      References Systeme (SystemeId)
)
;
 
/*==============================================================*/
/* Table : Camp_FicheDeVie                                      */
/*==============================================================*/
Create Table Camp_FicheDeVie (
   CampagneId           Int                  Not null,
   CampFVIdRelatif      Int                  Not null,
   CampFVTexte          Varchar(48)          Not null,
   CampFVDate           Datetime             Not null,
   CampFVRedacteur      Varchar(48)          Not null,
   CampBoolErr          Char(1)              Not null,
   Constraint Camp_FicheDeVie_PK Primary Key  (CampagneId, CampFVIdRelatif),
   Constraint Camp_FicheDeVie_Campagne_1 Foreign Key (CampagneId)
      References Campagne (CampagneId)
)
;
 
/*==============================================================*/
/* Table : Syst_Camp                                            */
/*==============================================================*/
Create Table Syst_Camp (
   SystemeId            Int                  Not null,
   CampagneId           Int                  Not null,
   Constraint Syst_Camp_PK Primary Key  (SystemeId, CampagneId),
   Constraint Syst_Camp_Systeme_1 Foreign Key (SystemeId)
      References Systeme (SystemeId),
   Constraint Syst_Camp_Campagne_2 Foreign Key (CampagneId)
      References Campagne (CampagneId)
)
;
 
/*==============================================================*/
/* Table : Syst_FicheDeVie                                      */
/*==============================================================*/
Create Table Syst_FicheDeVie (
   SystemeId            Int                  Not null,
   SystFVIdRelatif      Int                  Not null,
   SystFVTexte          Varchar(48)          Not null,
   SystFVDate           Datetime             Not null,
   SystFVRedacteur      Varchar(48)          Not null,
   SystBoolErr          Char(1)              Not null,
   Constraint Syst_FicheDeVie_PK Primary Key  (SystemeId, SystFVIdRelatif),
   Constraint Syst_FicheDeVie_Systeme_1 Foreign Key (SystemeId)
      References Systeme (SystemeId)
)
;
 
/*==============================================================*/
/* Table : Instr_FicheDeVie                                     */
/*==============================================================*/
Create Table Instr_FicheDeVie (
   InstrumentId         Int                  Not null,
   InstrFVIdRelatif     Int                  Not null,
   InstrFVTexte         Varchar(48)          Not null,
   InstrFVDate          Datetime             Not null,
   InstrFVRedacteur     Varchar(48)          Not null,
   InstrBoolErr         Char(1)              Not null,
   Constraint Instr_FicheDeVie_PK Primary Key  (InstrumentId, InstrFVIdRelatif),
   Constraint Instr_FicheDeVie_Instrument_1 Foreign Key (InstrumentId)
      References Instrument (InstrumentId)
)
;

Concernant les requêtes transversales, du genre "Quelles sont les fiches de vie pour telle période ?", qu’il s’agisse indifféremment d’instruments, de systèmes ou de campagnes, pour simplifier la vie de l’utilisateur final, il suffit de mettre en oeuvre une table virtuelle, une vue composée de l’union de l’ensemble des fiches de vie, dans le genre :

Code SQL :

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
20
21
22
23
24
25
26
27
28
29
Create View FicheDeVie (FVTypeFiche, FVIdPrincipal, FVIdRelatif, FVTexte, FVDate, FVRedavteur, FVBoolErr) 
  As
       Select    'Instrument',    
                 InstrumentId, 
                 InstrFVIdRelatif,
                 InstrFVTexte,
                 InstrFVDate,
                 InstrFVRedacteur,
                 InstrBoolErr
       From      Instr_FicheDeVie
    UNION ALL
       Select    'Systeme',    
                 SystemeId, 
                 SystFVIdRelatif,
                 SystFVTexte,
                 SystFVDate,
                 SystFVRedacteur,
                 SystBoolErr
       From      Syst_FicheDeVie
    UNION ALL
       Select    'Campagne',    
                 CampagneId, 
                 CampFVIdRelatif,
                 CampFVTexte,
                 CampFVDate,
                 CampFVRedacteur,
                 CampBoolErr
       From      Camp_FicheDeVie
;

N.B. Dans tout cela, je ne vois pas de contraintes à traduire sous forme de triggers.

J'ai téléchargé la version d'évaluation de powerAMC, j’ai failli en tomber amoureux mais une incompatibilité avec word2007 a brisé le charme.

Que vient faire Word dans cette affaire ?

[blackadder]

Bonjour,
Jphi33 :
Je rencontre la personne « cliente » cette après-midi. Je dois lui faire une présentation du MCD, j’en profiterais pour éclaircir les zones d’ombres qui subsistent.



Frsmel :
J’avais commencé à réfléchir sur une solution ressemblante à la tienne mais je ne l’avais pas présentée ici.
En stockant les éléments des fiches dans tables « spécialisées » par entité forte Instruments, Systèmes et Campagnes, tu n’a effectivement pas les mêmes contraintes qu’en les stockant dans une table commune. Ce qui peut expliquer le fait que tu n’aies pas besoin de trigger.



Effectivement mon problème avec Word n’a rien à faire sur ce post. Cependant je fais pars de retour d’expérience de l’utilisation de ce logiciel, peut être pas dans le bon sujet de discussion.