Discussion :

[aras-vbo]

Bonjour,

Voici le MCD modifié. Le détail des relations SPECTRE, TELESCOPE, SITE et UTILISATEUR est détaillé ci-dessous ; le MCD complet est en pièce jointe.

Dans SPECTRE, les champs ont été renommés pour ne pas être entièrement dépendants des noms des mots-clés FITS. Le format d'enregistrement des spectres étant susceptible d'évoluer, autant nommer les champs de la façon la plus généraliste possible.
Les valeurs obligatoires ont été insérées dans la relation SPECTRE. Les valeurs facultatives ont été isolées dans des relations. Le cas des spectres Echelle est traité dans une relation particulière héritant de SPECTRE.
Le statut du spectre est dans une relation à part. Il peut être modifié par un utilisateur qui doit être différent de l'utilisateur soumettant le spectre. Le statut est historisé.



Je vous soumet ma modélisation de la liaison complexe entre UTILISATEUR, TELESCOPE, SITE et SPECTRE.
L'entité-type associative INSTRUMENT_SITE a été renommée OBSERVATOIRE. L'entité-type INSTRUMENT a été renommée TELESCOPE. Ces renommages permettent, à mon avis, de simplifier les explications et améliorent la compréhension.
Les entités-type TELESCOPE et SITE sont considérées comme faibles ; c'est le couple TELESCOPE + SITE (regroupé dans OBSERVATOIRE) qui enregistre le SPECTRE, d'où les cardinalités (1,1) pour TELESCOPE et SITE.

Dans l'attente de vos commentaires.
Vincent

[escartefigue]

Bonjour,

Ca me semble une excellente chose d'avoir transformé la relation en type d'entité, un observatoire est en effet un objet de gestion et non une relation

Par contre, si le télescope est une entité-type faible pour qu'il soit identifié relativement à l'observatoire, il convient de mettre les cardinalités (1,1) coté télescope et non coté observatoire

[fsmrel]

Travail exemplaire

Dans SPECTRE, les champs ont été renommés pour ne pas être entièrement dépendants des noms des mots-clés FITS. Le format d'enregistrement des spectres étant susceptible d'évoluer, autant nommer les champs de la façon la plus généraliste possible.

Votre remarque est pertinente. Être indépendant des contraintes externes est indispensable.

Les valeurs obligatoires ont été insérées dans la relation SPECTRE. Les valeurs facultatives ont été isolées dans des relations.

Voilà qui est raisonnable, à défaut d’être audacieux ; la prudence est la mère de toutes les vertus...

Les entités-type TELESCOPE et SITE sont considérées comme faibles ;

Pour l’entité-type SITE, de quelle(s) entité(s)-type(s) plus fortes dépend-elle ?

Pour l’entité-type TELESCOPE, c’est une possibilité, considérant qu’un télescope est l’association d’un tube optique, d’un spectrographe et d’une caméra, mais sémantiquement parlant, ne peut-on pas aussi interpréter TELESCOPE comme entité-type forte, en considérant qu’un télescope est un objet que l’on a équipé d’un tube optique, d’un spectrographe et d’une caméra (et peut-être d’autres éléments) ? A noter qu’avec l’identification relative, au stade MLD puis SQL, la clé primaire de la table TELESCOPE sera le quadruplet {id_site, id_tube_optique, id_spectrographe, id_camera} et que la clé primaire de chacune des tables SPECTRE, UTILISER et ENREGISTRE en héritera. A vous de voir si le jeu en vaut la chandelle, autrement dit s’il sera utile que les requêtes SQL portant sur ces 3 tables fassent référence à tout ou partie des attributs du quadruplet ; qu’en est-il ?

J'ai aussi ajouté une contrainte d'exclusion entre les relations Valider et Soumettre, pour faire apparaître le fait qu'un observateur ne peut pas valider les propres spectres qu'il soumet à la base.

Désormais, l’entité-type STATUT rompt la contrainte. D’un point de vue relationnel, la contrainte joue seulement sur le singleton {id_utilisateur} et non pas sur la paire {id_utilisateur, id_spectre}, autrement dit, soit l’utilisateur Raoul peut soumettre, soit il peut changer, il se spécialise en quelque sorte dans une seule de ces deux activités, ce qui ne correspond pas précisément à la règle de gestion. En attendant votre position à ce sujet, je vais regarder cela de plus près et examiner l’historisation du statut.

[aras-vbo]

Bonjour à tous,

Petit retour en arrière concernant le nommage de mon entité de liaison. Le terme OBSERVATOIRE pouvant prêter à confusion, notamment chez les astronomes, je reviens à la dénomination TELESCOPE_SITE qui exprime plus clairement le fait qu'un TELESCOPE est installé dans un SITE, et que c'est cette association qui enregistre un SPECTRE.


@escartefigue

J'ai effectivement un problème concernant TELESCOPE_SITE... J'ai peut-être mal saisi la notion d'identification relative et les cardinalités qui doivent y être associées. J'ai en tête l'image des appartements portant le même numéro et les immeubles, décrits par C. Soutou dans son livre "Modélisation des bases de données".
Pour moi, le TELESCOPE est une entité faible, à l'image de l'appartement, puisqu'il ne suffit pas à identifier seul l'élément qui enregistre un SPECTRE. C'est l'association TELESCOPE+SITE qui enregistre les SPECTRES.

Je dois tenir compte aussi des règles de gestion suivantes :
- Un TELESCOPE est composé d'un TUBE OPTIQUE, d'un SPECTROGRAPHE et d'une CAMERA
- Un TUBE OPTIQUE peut être associé à plusieurs TELESCOPES
- Un SPECTROGRAPHE peut être associé à plusieurs TELESCOPES
- Une CAMERA peut être associée à plusieurs TELESCOPES
- Un TELESCOPE peut être installé dans 0 ou plusieurs SITES

Si je fais la relation suivante (l'inverse de ce qui apparaît sur mon MCD) :
TELESCOPE -- (1,1) -- Equiper -- 0,n -- TELESCOPE_SITE
Cela signifie qu'un TELESCOPE ne peut apparaître que dans une seule association TELESCOPE_SITE, c'est à dire qu'il ne peut être installé que dans un seul SITE. Ce n'est pas correct.
De même, cela signifie que l'association TELESCOPE_SITE n'est pas unique, ce qui revient à dire que cette association peut se référer à plusieurs TELESCOPES installés sur le même SITE et donc qu'il n'est pas possible de savoir quel TELESCOPE a enregistré un SPECTRE sur le SITE donné. Là aussi, ça ne va pas.

Je dois donc conserver ma relation :
TELESCOPE -- 0,n -- Equiper -- 1,1 -- TELESCOPE_SITE
Un TELESCOPE peut apparaître dans plusieurs TELESCOPE_SITE. Il peut être installé dans plusieurs SITES, voire dans aucun, et il ne peut pas être simultanément dans plusieurs sites pour y enregistrer un SPECTRE donné.
TELESCOPE_SITE est unique, cette fois-ci puisqu'il se réfère bien qu'à un seul TELESCOPE, installé dans un SITE, au moins au moment où un SPECTRE donné est enregistré. Le TELESCOPE peut être installé ensuite dans un autre SITE pour y enregistrer un autre SPECTRE.

Du coup, je me demande si la relation suivante est pertinente et si une identification relative est nécessaire.
TELESCOPE -- 0,n -- Equiper -- (1,1) -- TELESCOPE_SITE
Cela revient à dire que TELESCOPE_SITE est l'entité faible...
Je dois néanmoins considérer le fait que c'est la clé composite {id_site, id_telescope, id_spectre} qui identifiera formellement un SPECTRE.
Ca devient assez confus dans mon esprit, cette histoire .


@fsmrel

Pour l’entité-type SITE, de quelle(s) entité(s)-type(s) plus fortes dépend-elle ?

Pour l’entité-type TELESCOPE, c’est une possibilité, considérant qu’un télescope est l’association d’un tube optique, d’un spectrographe et d’une caméra, mais sémantiquement parlant, ne peut-on pas aussi interpréter TELESCOPE comme entité-type forte, en considérant qu’un télescope est un objet que l’on a équipé d’un tube optique, d’un spectrographe et d’une caméra (et peut-être d’autres éléments) ? A noter qu’avec l’identification relative, au stade MLD puis SQL, la clé primaire de la table TELESCOPE sera le quadruplet {id_site, id_tube_optique, id_spectrographe, id_camera} et que la clé primaire de chacune des tables SPECTRE, UTILISER et ENREGISTRE en héritera. A vous de voir si le jeu en vaut la chandelle, autrement dit s’il sera utile que les requêtes SQL portant sur ces 3 tables fassent référence à tout ou partie des attributs du quadruplet ; qu’en est-il ?

SITE ne dépend pas d'une entité plus forte qu'elle, je pense. Je peux donc supprimer toute identification relative.

Etant donné que TELESCOPE "agrège" en quelque sorte l'association d'un TUBE OPTIQUE, d'un SPECTROGRAPHE et d'une CAMERA (sans doublon), il ne me semble pas utile que leurs clés apparaissent dans d'autres tables.

Désormais, l’entité-type STATUT rompt la contrainte. D’un point de vue relationnel, la contrainte joue seulement sur le singleton {id_utilisateur} et non pas sur la paire {id_utilisateur, id_spectre}, autrement dit, soit l’utilisateur Raoul peut soumettre, soit il peut changer, il se spécialise en quelque sorte dans une seule de ces deux activités, ce qui ne correspond pas précisément à la règle de gestion. En attendant votre position à ce sujet, je vais regarder cela de plus près et examiner l’historisation du statut.

Je vais sans doute supprimer cette contrainte dans un premier temps, surtout pour des raisons purement "pratiques" : les personnes suffisamment qualifiés pour valider les spectres ne sont pas nombreux et ce sont ceux qui en soumettent le plus eux-mêmes dans la base... Nous risquons donc de nous retrouver avec un gros problème de validation si les validateurs doivent impérativement être différents de ceux qui soumettent les spectres.
La règle avait été définie de façon à permettre une certaine objectivité dans la publication.


Merci pour votre aide.
Vincent

[escartefigue]

Je dois tenir compte aussi des règles de gestion suivantes :
- Un TELESCOPE est composé d'un TUBE OPTIQUE, d'un SPECTROGRAPHE et d'une CAMERA
- Un TUBE OPTIQUE peut être associé à plusieurs TELESCOPES
- Un SPECTROGRAPHE peut être associé à plusieurs TELESCOPES
- Une CAMERA peut être associée à plusieurs TELESCOPES
- Un TELESCOPE peut être installé dans 0 ou plusieurs SITES

Bonjour Aras-vbo

Je reviens à des questions de sémantiques et sur les cardinalités

-1- Je n'y avais pas pris garde auparavant, mais en relisant ce qui précède, je suis très surpris
Sauf erreur de ma part (j'ai consulté quelques plans sur la toile car je ne suis pas astronome) le tube ne peut être associé qu'à un seul télescope, en tout cas si le tube est la partie principale à l'intérieur de laquelle sont maintenus les miroirs et sur laquelle est fixé le porte oculaire.
Si on démonte ce tube, il n'y a plus de télescope.
Du coup j'aurais tendance à dire un tube ne peut être associé qu'à un et un seul télescope, ou à la rigueur, à plusieurs à condition d'avoir une relation à date de façon à n'avoir pour un tube qu'un seul télescope à un instant "t"
Qu'en est il ?
Pour la caméra et le spectrographe il en va peut-être de même

-2- La règle "Un TELESCOPE peut être installé dans 0 ou plusieurs SITES" est-elle bien aussi à date ? je veux dire, à un instant "t" un télescope est bien dans un seul site non ?

-3- Quand à l'observatoire, n'est-ce pas un lieu géographique dans lequel peuvent se trouver un ou plusieurs télescopes, comme l'observatoire de Meudon ou celui du pic du midi par exemple ?
Si c'est bien le cas, le terme Observatoire me semble plus judicieux que "telescope_site"

Concernant l'identification relative, elle prend tout son sens quand l'entité-type dite faible n'a pas d'existence propre. L'exemple des n° d'appartements dans des immeubles, celui des lignes de factures par rapport à une facture ou des lignes de commande par rapport à la commande en sont l'illustration.
Le télescope, dans la compréhension qui est la mienne, n'est pas une entité-type faible. Il a sa propre existence indépendamment du site dans lequel il est installé et des composants avec lesquels il est assemblé.

[aras-vbo]

-1- Je n'y avais pas pris garde auparavant, mais en relisant ce qui précède, je suis très surpris
Sauf erreur de ma part (j'ai consulté quelques plans sur la toile car je ne suis pas astronome) le tube ne peut être associé qu'à un seul télescope, en tout cas si le tube est la partie principale à l'intérieur de laquelle sont maintenus les miroirs et sur laquelle est fixé le porte oculaire.
Si on démonte ce tube, il n'y a plus de télescope.
Du coup j'aurais tendance à dire un tube ne peut être associé qu'à un et un seul télescope, ou à la rigueur, à plusieurs à condition d'avoir une relation à date de façon à n'avoir pour un tube qu'un seul télescope à un instant "t"
Qu'en est il ?
Pour la caméra et le spectrographe il en va peut-être de même

Un tube peut effectivement être associé à plusieurs télescopes, avec une relation à date. Je peux monter mon tube optique de type Kepler 200 sur un télescope un jour "j" et l'installer sur un autre télescope le lendemain. Il en va de même pour le spectrographe et pour la caméra.
Toutefois, je ne cherche pas à identifier un tube optique en particulier dans un télescope (un tube possédant tel numéro de série, comme l'exemplaire n°2 d'un livre dans une bibliothèque). Ce qui m'intéresse, c'est de connaître la "configuration" utilisée : le tube optique d'un certain type + le spectrographe d'un certain type + la caméra d'un certain type. Peu m'importe de savoir qu'il s'agit du tube optique n°0021 de M. Tournesol qui a enregistré le spectre ; c'est le modèle de tube et ces propriétés optiques qui prévalent.
Dans tous les cas, une configuration (ou un TELESCOPE) qui enregistre un SPECTRE est toujours composé d'un seul TUBE OPTIQUE, d'une seule CAMERA et d'un seul SPECTROGRAPHE.
Par contre, plusieurs TELESCOPE différents peuvent être équipés du même tube, de type Kepler 200, par exemple.

-2- La règle "Un TELESCOPE peut être installé dans 0 ou plusieurs SITES" est-elle bien aussi à date ? je veux dire, à un instant "t" un télescope est bien dans un seul site non ?

Oui, il s'agit bien d'une relation" à date".

-3- Quand à l'observatoire, n'est-ce pas un lieu géographique dans lequel peuvent se trouver un ou plusieurs télescopes, comme l'observatoire de Meudon ou celui du pic du midi par exemple ?
Si c'est bien le cas, le terme Observatoire me semble plus judicieux que "telescope_site"

C'est bien là toute l'origine de la confusion qui pourrait apparaître.
Pour un astronome, quel qu'il soit, l'Observatoire désigne plus le lieu géographique que le matériel qui s'y trouve (cela correspondrait plutôt à SITE dans mon MCD). En plus, dans un "vrai" Observatoire (au sens de l'astronome), le matériel est fixe et peu susceptible de bouger; l'association TELESCOPE/SITE est donc implicite (le T2M est au Pic du Midi ; il y a peu de chance qu'il change de place).
Un astronome amateur déplace souvent son matériel d'un site à l'autre. L'assocation TELESCOPE/SITE doit donc être explicite. Si j'emmène mon télescope au Col du Restefond, un site en pleine nature excellent pour l'astronomie amateur, est-ce que cela fait du Col du Restefond un Observatoire au sens de l'astronome ? Non. Tout site où je peut poser mon télescope est donc un Observatoire potentiel.
Je préfère donc conserver l'appellation TELESCOPE_SITE pour bien faire le distinguo avec un Observatoire, au sens propre du terme.

Concernant l'identification relative, elle prend tout son sens quand l'entité-type dite faible n'a pas d'existence propre. L'exemple des n° d'appartements dans des immeubles, celui des lignes de factures par rapport à une facture ou des lignes de commande par rapport à la commande en sont l'illustration.
Le télescope, dans la compréhension qui est la mienne, n'est pas une entité-type faible. Il a sa propre existence indépendamment du site dans lequel il est installé et des composants avec lesquels il est assemblé.

Je suis tout à fait d'accord. Si je considère que TELESCOPE n'est plus une entité faible, est-ce que je n'aurai pas d'ambiguïté sur l'association TELESCOPE + SITE dans mon entité TELESCOPE_SITE ? Est-ce que je dois ajouter une notion de temporalité dans l'association ou est-ce que les simples attributs de date (début de prise + durée) du SPECTRE que j'enregistre avec une association TELESCOPE + SITE donnée suffisent à la caractériser implicitement ?

Vincent

[escartefigue]

Je n'avais pas pensé au matériel amateur beaucoup plus mobile que le matériel professionnel bien sur (je plains les déménageurs qui devraient bouger le télescope du pic du midi )
Après avoir relu le sujet d'origine pour mieux comprendre l'apparition de l'entité-type INSTRUMENT-SITE, je me demande si la modélisation suivante ne correspondrait pas au besoin tout en simplifiant l'approche.

Au niveau conceptuel :

Pièce jointe 367557


Soit les tables suivantes :

Pièce jointe 367561

Ainsi, un instrument est bien localisé à date sur un site unique
La relation "mesurer" permet de garantir le lien unique entre le spectre, le site et l'instrument

La difficulté consistera à vérifier que l'instrument qui mesure le spectre à un instant "t" est bien localisé sur le site de la relation "mesurer" pour la période considérée.
Un simple contrainte ne pourra pas être utilisée pour ce besoin, il faudra donc passer par un trigger.

[aras-vbo]

Bonsoir escartefigue,

En reprenant mon MCD, je m'aperçois que j'ai fait une erreur à propos des configurations de télescopes. J'ai en fait 2 problématiques à concilier et j'avais négligé la deuxième :
1 - c'est la configuration d'un TELESCOPE (l'association d'un TUBE OPTIQUE, d'un SPECTROGRAPHE et d'une CAMERA ; peu importe son propriétaire) et le SITE dans lequel il est installé, qui caractérisent techniquement le SPECTRE. Dans ce cas, la notion de temporalité, de configuration "à date" n'importe pas.
2 - un UTILISATEUR peut enregistrer son TELESCOPE (sa configuration de TUBE OPTIQUE, de SPECTROGRAPHE et de CAMERA ; personnelle, cette fois-ci) de façon à faciliter la soumission de ses spectres, d'où les attributs code_telescope et nom_telescope. Il peut ensuite installer son TELESCOPE dans un SITE différent, avec l'entité associative TELESCOPE_SITE. Dans ce cas, la notion de temporalité est importante puisqu'il doit être impossible qu'un TELESCOPE donné soit sur 2 sites différents en même temps pour y enregistrer des spectres.

Par conséquent, votre approche est sans doute la bonne, pour tenir compte de la contrainte la plus forte qui est la 2ème.
Toutefois, je pense qu'il n'y pas de possibilité de doublon et qu'une entité CA_calend ne sera pas forcément utile. Ce sont les indications temporelles de l'association mesurer qui certifieront implicitement la contrainte temporelle de TELESCOPE_SITE, n'est ce pas ?
De toutes façons, je ne vois pas un utilisateur gérer un calendrier d'installation de son matériel sur ses différents sites d'observation...

Je vais modifier mon MCD.

Vincent

[fsmrel]

Salve Vincent et Le capitaine,

Vous avez défini une entité-type associative INSTRUMENT_SITE : parfait. Au stade MLD, on aura une table INSTRUMENT_SITE ayant pour clé primaire la paire {id_instrument, id_site} et là j’estime que ça coince, car cela veut dire que l’instrument I1 peut être simultanément localisé sur les sites S1, S2,..., Sn. Si par exemple à l’instant T1 l’ instrument I1 ne peut que se trouver sur le site S2, comment le savoir ? Autrement dit il faudrait ajouter un attribut du genre Date_localisation_intrument dans l’en-tête de la table INSTRUMENT_SITE et c’est la paire {{id_instrument, Date_localisation_intrument} qui alors deviendra clé primaire. Dans ces conditions, à un instant donné un instrument ne peut être que sur un site et un seul. Mais peut-être avez-vous des arguments à faire valoir pour la pertinence de la clé {id_instrument, id_site} ?

La règle "Un TELESCOPE peut être installé dans 0 ou plusieurs SITES" est-elle bien aussi à date ? je veux dire, à un instant "t" un télescope est bien dans un seul site non ?

la notion de temporalité est importante puisqu'il doit être impossible qu'un TELESCOPE donné soit sur 2 sites différents en même temps pour y enregistrer des spectres.

Well! Il y a là un consensus ! Nos observations (pas du ciel !) sont en phase (pas de la lune !) : à une date donnée l’objet qui sert à pondre les spectres est installé à tel endroit, sans bilocation possible ni comportement quantique quelconque...

un instrument est bien localisé à date sur un site unique
La relation "mesurer" permet de garantir le lien unique entre le spectre, le site et l'instrument.

Capitaine, dans ton MLD, la table LOCALISER a pour identifiant primaire {SI_id, IN_id, CA_date}, autrement dit un instrument donné peut se retrouver sur plus d’un site au même moment... Pour empêcher cela, il eut fallu une CIF (contrainte d’intégrité fonctionnelle) au stade MCD (mais il est vrai que PowerAMC est plutôt faiblard ès matière ) :

La flèche rouge symbolise la CIF. Cela dit tu peux rattraper le coup au stade MLD en éliminant manuellement SI_id de l’identifiant.

La difficulté consistera à vérifier que l'instrument qui mesure le spectre à un instant "t" est bien localisé sur le site de la relation "mesurer" pour la période considérée.
Un simple contrainte ne pourra pas être utilisée pour ce besoin, il faudra donc passer par un trigger.

Pour éviter le trigger, tu peux retoucher ton MLD ainsi :

(1) La paire {instrumentId, dateLocalisation} étant identifiant primaire de LOCALISER, tu définis en plus un suridentifiant {instrumentId, dateLocalisation, siteId} ;

(2) Tu supprimes les liens MESURER - SITE et MESURER - INSTRUMENT au bénéfice d’un lien unique, à savoir MESURER - LOCALISER, ciblant non pas l’identifiant primaire mais le suridentifiant.

(3) En passant, pour éviter un cycle entre MESURER et SPECTRE, tu mets en oeuvre un rôle dépendant (D), cf. « Propriétés de la relation MESURER » :

Ce sont les indications temporelles de l'association mesurer qui certifieront implicitement la contrainte temporelle de TELESCOPE_SITE, n'est ce pas ?

Autrement dit, dans la table LOCALISER (synonyme de TELESCOPE_SITE), on peut renommer dateLocalisation en dateDebutMesure et faire l’économie de MESURER :

On demande à l’AGL de ne pas générer de table pour l’entité-type CALENDRIER :

Est-ce bien ce que vous attendez ? Sinon, on rebelote jusqu'à consensus !

[escartefigue]

Capitaine, dans ton MLD, la table LOCALISER a pour identifiant primaire {SI_id, IN_id, CA_date}, autrement dit un instrument donné peut se retrouver sur plus d’un site au même moment...]

Bigre ! tout à fait.
Je suis allé un peu vite en besogne

[aras-vbo]

Bonjour François (et escartefigue)

Je ne présumerai de rien sur la bilocation du télescope ; la physique quantique est pleine de mystère. Tel le chat de Schrödinger, mon télescope est peut être à la fois sur un site et sur un autre, dans un univers des possibles alternatif...

Votre modélisation me paraît bien coller à la problématique. Il m'évite une gestion de l'occupation des sites pour les télescopes qu'il m'est impossible d'implémenter.
Mais comment puis-je faire remonter l'information temporelle de localisation ? Elle provient de la donnée que me fourni un spectre, au travers de l'association :
[TELESCOPE_SITE] -- 0,n -- (enregistre : date_debut, temps_pose) -- 1,1 -- [SPECTRE]
Si je transforme cette association, les attributs de "enregistre" sont envoyés dans la table SPECTRE. L'attribut date_debut n'apparaîtra pas dans TELESCOPE_SITE ?
Il me suffit de modéliser une entité CALENDRIER dans laquelle je mets l'attribut date_debut ?

Voilà ce que cela donne sur le MCD, en implémentant la modélisation de François :




J'ai l'impression que ça se finalise, tout ça !

Vincent

[aras-vbo]

Petite remarque pratique concernant JMerise (0.4.0.1) :

J'ai tenté de convertir mon MCD en MLD et j'ai eu plusieurs messages d'erreur :
1 - la duplication des noms des relations. JMerise m'indique que certains noms existent plusieurs fois... Je peux éventuellement régler le problème en renommer les noms de relations dupliqués mais c'est plutôt embêtant.
2 - Lien relatif : le lien entre l'entité SPECTRE et la relation "posséder" doit être de type 0,n ou 1,n

Pour le point 2, il s'agit des relations suivantes :
[SPECTRE] -- 0,1 -- posséder -- 1,1 -- [RESOLUTION]
[SPECTRE] -- 0,1 -- binner -- 1,1 -- [BINNING]

Là, ça pose un problème car un SPECTRE ne peut posséder que 0 ou 1 RESOLUTION ou BINNING et non plusieurs.
Est-ce que je peux contourner le problème en mettant une cardinalité 0,n du côté SPECTRE pour générer le MLD puis mettre une contrainte UNIQUE à la clé étrangère id_spectre qui apparaîtra dans la table RESOLUTION afin d'éviter tout doublon ?

Vincent

[fsmrel]

Salve Vincent,

comment puis-je faire remonter l'information temporelle de localisation ? Elle provient de la donnée que me fourni un spectre, au travers de l'association :
[TELESCOPE_SITE] -- 0,n -- (enregistre : date_debut, temps_pose) -- 1,1 -- [SPECTRE]
Si je transforme cette association, les attributs de "enregistre" sont envoyés dans la table SPECTRE. L'attribut date_debut n'apparaîtra pas dans TELESCOPE_SITE ?
Il me suffit de modéliser une entité CALENDRIER dans laquelle je mets l'attribut date_debut ?

Etant donné qu’on modélise le QUOI et pas le COMMENT, on est légitimement censé ne pas savoir que l’information a été fournie par un fantôme, heu je veux dire par un spectre. Autrement dit, que l’information soit dans SPECTRE ou dans TELESCOPE_SITE, peu importe, on a le choix dans la date, le tout est qu’elle ne soit pas redondante, c'est-à-dire dans les deux entités-types à la fois. Maintenant, ce qui nous intéresse, c’est de respecter la règle de gestion des données Rx comme quoi un télescope ne peut pas être présent sur deux sites au même moment ; pour cette raison, il est nécessaire et suffisant de modéliser une entité-type CALENDRIER dont l'attribut unique et identifiant sera date_debut, tandis que l’attribut temps_pose restera sagement à sa place.

Attention, afin de respecter la règle de gestion des données Rx, le lien entre TELESCOPE_SITE et EQUIPER ne doit pas être identifiant !

P.-S. Avez-vous des tuyaux sur la téléportation et la bilocation des fantômes ?

JMerise m'indique que certains noms existent plusieurs fois.

Pour éviter cela : onglet Configuration > Paramètres > Contraintes MCD, et décocher la case « Redondance des noms des associations ».

Lien relatif : le lien entre l'entité SPECTRE et la relation "posséder" doit être de type 0,n ou 1,n.

Selon votre MCD, le lien est lambda, où voyez-vous un lien relatif ? (qui de toute façon n’a pas lieu d’être).

Là, ça pose un problème car un SPECTRE ne peut posséder que 0 ou 1 RESOLUTION ou BINNING et non plusieurs.

Votre problème a été pris en compte pour la version 0.5 de JMerise, et c’est votre propre cas qui a servi d’exemple

Est-ce que je peux contourner le problème en mettant une cardinalité 0,n du côté SPECTRE pour générer le MLD puis mettre une contrainte UNIQUE à la clé étrangère id_spectre qui apparaîtra dans la table RESOLUTION afin d'éviter tout doublon ?

Il y aura pas mal de correctifs à apporter au code SQL généré, donc ne vous compliquez pas la vie. Les choix possibles :

(1) Attendre l’arrivée de la version 0.5 de JMerise (si vous ne l’avez pas encore fait, vous lirez avec profit les échanges avec rabDev) :

J'ai programmé la livraison de la version 0.5 pour la fin du mois d'Avril ou pour le début du mois de Mai au plus tard.

(2) Passer à DB-MAIN (gratuit).

(3) Modéliser le MLD avec MySQL Workbench (gratuit).

(4) Acquérir PowerAMC, mais il faut compter dépenser une grosse poignée de milliers d’euros ^^

(5) Récupérer le code SQL généré avec la version actuelle de JMerise, le copier (balise CODE) dans votre prochain message ; je récupérerai ce code et le corrigerai (ce qui ne devrait pas vous empêcher de faire la même chose en //, histoire de vous exercer à ce sport).

Je pense que le point (5) est à privilégier. Votre avis ?

[aras-vbo]

Etant donné qu’on modélise le QUOI et pas le COMMENT, on est légitimement censé ne pas savoir que l’information a été fournie par un fantôme, heu je veux dire par un spectre. Autrement dit, que l’information soit dans SPECTRE ou dans TELESCOPE_SITE, peu importe, on a le choix dans la date, le tout est qu’elle ne soit pas redondante, c'est-à-dire dans les deux entités-types à la fois. Maintenant, ce qui nous intéresse, c’est de respecter la règle de gestion des données Rx comme quoi un télescope ne peut pas être présent sur deux sites au même moment ; pour cette raison, il est nécessaire et suffisant de modéliser une entité-type CALENDRIER dont l'attribut unique et identifiant sera date_debut, tandis que l’attribut temps_pose restera sagement à sa place.
Attention, afin de respecter la règle de gestion des données Rx, le lien entre TELESCOPE_SITE et EQUIPER ne doit pas être identifiant !

Merci. L'explication est limpide.

P.-S. Avez-vous des tuyaux sur la téléportation et la bilocation des fantômes ?

Malheureusement non. Mes compétences se limitent à une forme de télépathie instrumentale : le pilotage de télescopes à distance.

Pour éviter cela : onglet Configuration > Paramètres > Contraintes MCD, et décocher la case « Redondance des noms des associations ».

Merci pour l'astuce. JMerise manque de documentation sur certaines fonctions.

Selon votre MCD, le lien est lambda, où voyez-vous un lien relatif ? (qui de toute façon n’a pas lieu d’être).

Le lien relatif (1,1) est du côté de l'entité RESOLUTION dans la relation Posséder (qui n'apparaît pas sur ma dernière capture de MCD) et non de l'entité SPECTRE.

Votre problème a été pris en compte pour la version 0.5 de JMerise, et c’est votre propre cas qui a servi d’exemple

J'ai lu la discussion d'un regard distrait... mais j'ai constaté que l'exemple y figurait. Merci d'avoir soulevé ce lièvre.

Il y aura pas mal de correctifs à apporter au code SQL généré, donc ne vous compliquez pas la vie. Les choix possibles :

(1) Attendre l’arrivée de la version 0.5 de JMerise (si vous ne l’avez pas encore fait, vous lirez avec profit les échanges avec rabDev) :


(2) Passer à DB-MAIN (gratuit).

(3) Modéliser le MLD avec MySQL Workbench (gratuit).

(4) Acquérir PowerAMC, mais il faut compter dépenser une grosse poignée de milliers d’euros ^^

(5) Récupérer le code SQL généré avec la version actuelle de JMerise, le copier (balise CODE) dans votre prochain message ; je récupérerai ce code et le corrigerai (ce qui ne devrait pas vous empêcher de faire la même chose en //, histoire de vous exercer à ce sport).

Je pense que le point (5) est à privilégier. Votre avis ?

Je vais les relire de façon plus approfondie, même si certaines discussions très techniques dépassent mes compétences.
J'aurai sans doute l'occasion de tester la version 0.5 ; je fais parti des donateurs depuis peu. J'aime encourager la création d'outils gratuits et de qualité dont le concepteur est accessible et ouvert aux critiques et suggestions (et en français, ce qui ne gâche rien).

Je ne connaît pas DB-MAIN mais j'utilise MySQL Workbench (qui ne fait malheureusement pas de MCD).
J'ai utilisé AMC Designer il y a déjà un certain temps, lors d'une formation, mais le prix de la licence actuelle de PowerDesigner, l'absence d'une quelconque version de démonstration et la politique de licences prohibitives de SAP ont le don de dissuader toute tentative d'utilisation de leurs produits...


J'ai toujours pensé que la méthode (5) était à privilégier car la plus formatrice.
Je vais donc générer le MLD puis le code pour PostgresQL avec JMerise. Je vais ajouter des éléments, notamment les domaines, dont je ne comprend pas le mode de gestion dans JMerise (il est possible de définir des valeurs précises mais pas des plages telles que VALUE BETWEEN +90 AND -90 ou des NOT NULL... C'est surprenant).

Je vous soumettrai mes modifications ensuite, en créant sans doute un nouveau sujet synthétique dans le sous-forum schéma et ne fermant celui-ci (et en l'indiquant comme résolu).

Vincent