Discussion :

[aras-vbo]

Bonjour à tous,

Je suis astronome amateur et membre d'une structure informelle, ARAS (Astronomical Ring for Access to Spectroscopy). Il s'agit d'une "association" qui regroupe des astronomes amateurs de nombreux pays (en Europe, aux Etats-Unis et en Australie notamment) qui utilisent leurs télescopes pour enregistrer le spectre des étoiles, principalement des étoiles particulières et/ou variables car ce sont les plus intéressantes à suivre.
Cette activité est avant tout une activité de loisirs pour tous ses membres, à la frontière entre plusieurs domaines de l'astronomie dont la technique mais aussi l'astrophysique car la spectroscopie est un des seuls moyens d'obtenir des informations sur les conditions physiques régnant dans ou à proximité des astres. Pourtant, certains astronomes professionnels s'intéressent à notre activité et mettent en place des collaborations entre astronomes amateurs et professionnels pour obtenir des données spectrales qu'ils ne peuvent pas obtenir grâce aux télescopes professionnels. Ces collaborations permettent de suivre certains astres sur le long terme ou orientent le choix d'observations plus précises avec de gros télescopes en cas d'alertes.
Les données que nous collectons sont parfois analysées scientifiquement et certains de nos suivis ont fait l'objet de publications scientifiques officielles.

ARAS cherche à rassembler les spectres des volontaires à un seul endroit pour qu'ils soient accessibles librement tant pour les amateurs que pour les professionnels qui voudraient les exploiter de manière scientifique. Pour l'instant, nous gérons les spectres au travers de feuilles Excel qui sont ensuite transformées en pages web. Nous cherchons à développer une base de données plus structurée.

J'ai mis ci-dessous le contenu du projet, ainsi qu'un MCD, réalisé avec JMerise, dont j'aimerais que vous me donniez votre avis et vos retours.


OBJECTIF
--------

La base de données se donne pour objectif de gérer les spectres d'étoiles variables obtenues par les astronomes amateurs afin qu'ils puissent être consultés et utilisés soit par les astronomes amateurs, soit par les astronomes professionnels souhaitant les exploiter. La base donne une vision détaillée du suivi spectroscopique de chaque étoile variable (nombre de spectres, date de dernier spectre soumis et/ou validé, etc.).
Son accès est totalement libre et gratuit.

A terme, elle sera aussi un outil destiné à aider les astronomes amateurs à organiser et planifier leurs observations.
Le contenu de la base sera exploité au travers de différents outils et d'un service web, avec 3 objectifs principaux pour les astronomes amateurs :
1 - offrir les informations de base sur les étoiles suivies (coordonnées célestes, magnitudes, type spectral, groupe, période de variabilité, etc.).
2 - proposer des étoiles à observer en fonction de différents critères (visibilité, programme de suivi, appel à observations, etc.).
3 - suggérer des bonnes pratiques afin que les spectres soumis soient scientifiquement exploitables, par exemple en suggérant des étoiles de référence pour l'étalonnage des spectres à basse résolution, etc.


PROCESSUS DE VALIDATION DES SPECTRES
------------------------------------

Les astronomes amateurs soumettent des spectres d'étoiles variables qui sont ensuite validés par des référents expérimentés.

1 - Le spectre soumis est uploadé sur le site impérativement au format FITS (http://fits.gsfc.nasa.gov/). L'en-tête du fichier FITS est automatiquement analysé par le système. Les mots-clés de l'en-tête sont extraits puis ils sont vérifiés automatiquement selon plusieurs critères (présence/absence, longueur du contenu, type du contenu, cohérence du contenu avec le contenu existant déjà dans la base pour certains mots-clés, etc.). Si leur contenu est cohérent, les mots-clés sont soit insérés directement dans la base (date médiane de prise de vue, résolution du spectre, plage de longueur d'onde analysée, temps de pose total, étalonnage en flux ou non, etc.), soit utilisés pour associer le spectre aux différentes données présentes dans la base (astre observé, observateur inscrit, site d'observation référencé, etc.). Si l'en-tête est incomplet ou si son contenu est invalide, le spectre est refusé. Un spectre est refusé tant que l'en-tête du fichier FITS n'est pas conforme aux exigences de la base. Un fichier FITS de spectre ne peut être enregistré qu'une fois et une seule dans la base.

2 - Le spectre enregistré est placé en attente de validation.

3 - Le système indique aux validateurs qu'un spectre soumis est en attente d'affichage et de validation.

4 - Le spectre est vérifié par les validateurs (qualité de l'étalonnage spectral en longueur d'onde, cohérence des valeurs obtenues, aspect du continuum, etc.). Le spectre est ensuite affiché sur le site avec une mention :
- spectre valide si le spectre est jugé excellent et peut raisonnablement être exploité d'un point de vue scientifique
- spectre non valide si le spectre est sémantiquement correct mais sa valeur scientifique est incertaine (décalage dans l'étalonnage spectral, aspect suspect du continuum ou de certaines raies, etc.) ; il pourra être utilisé à titre informatif, par exemple.



En vous remerciant pour vos avis et votre aide,

Vincent

PS : Un grand merci au concepteur de JMerise pour ce logiciel fantastique. C'est un outil tout à fait génial, bien meilleur que certains outils gratuits mieux connus.

[escartefigue]

Bonjour,

Voilà un sujet bien attrayant, je ne suis pas astronome, pas même amateur, mais la littérature et les documentaires sur l'espace m'ont toujours attiré, et regarder les étoiles a quelque chose de magique

Compte tenu du sujet "pointu" vous auriez du expliquer le vocabulaire pour les béotiens dont je suis, en l'état, c'est un peu hermétique
Par exemple un "spectre" qu'est-ce , ou plus encore "coordonnées FK5"

Vous auriez du rédiger la liste de vos règles de gestion, certaines questions concernant les cardinalités sont sans doute dues à cette absence

Le terme "validateur" que vous utilisez à plusieurs reprises, s'il fait partie du jargon métier, doit être expliqué, sinon remplacé (contrôleur, agréeur, certificateur...)

Concernant le MCD :
Instruments
Je ne comprends pas ce que c'est. Vos cardinalités indiquent que ce serait à la fois un télescope, un spectrographe et une caméra !

Ce qui me surprend, sans doute est-ce dû à ma méconnaissance du sujet, est que ce faisant, un observateur qui n'aurait par exemple pas de caméra, ne pourrait pas enregistrer d'observations dans votre base de données ? Si vous confirmez ces cardinalités, alors on pourrait n'avoir qu'une seule entité-type "instrument" qui inclurait aussi les attributs que vous avez mis dans les 3 ET "télescope", "spectrographe" et "caméra"

Astres et étoiles
Là aussi, les cardinalités 1,1 avec coordonnées_FK5 donnent à penser qu'une entité-type unique est possible voire souhaitable
Concernant les différentes magnitudes, ne peut on pas les associer aussi à des astres autres que des étoiles ? une planète par exemple n'a-t- elle pas une magnitude ?
Si oui, faute d'attributs spécifiques aux étoiles et étoiles variables, ces sous-types ne seraient pas requis


Magnitude
Plutôt que de faire autant d'entités-type qu'il y a de types de magnitudes, faites n'en qu'une seule, et créez une ET "type de magnitude" ainsi
ASTRE 0,n --- posseder --- 0,n MAGNITUDE 1,1--- typer --- 0,n TYPE
Autant que je sache, la magnitude est un niveau de luminosité, qui peut donc être le même pour plusieurs astres

Vos attributs sont typés mais pas dimensionnés, à compléter donc

Le type Float est utilisé pour les très grande valeurs (en puissances de 10), ce n'est donc pas idéal pour des latitudes et longitudes

Pour les identifiants des relations, on privilégie en général des verbes. Quoi qu'il en soit vous avez de nombreux homonymes
A corriger s'il y a des attributs ou des relations n de chaque côté, car les tables générées lors de la dérivation du MLD prendront les noms de ces relations, et évidemment les doublons sont interdits

[aras-vbo]

Bonjour Escartefigue,

Merci pour votre réponse.
Il est vrai que lorsqu'on est dans un sujet, on a tendance à oublier que d'autres ne le sont pas forcément.

Voici donc des détails sur le vocabulaire utilisé. C'est une sorte de glossaire.
Je vais rajouter ensuite, dans un autre post, les règles de gestion.

---------------------------------------------------------------------------------

Un SPECTRE BRUT

Un spectre est la mesure de l'intensité de la lumière en fonction de la longueur d'onde.
Quand on décompose la lumière du Soleil avec un prisme par exemple, on forme un spectre, depuis le bleu (environ 400 nm) jusqu'au rouge (environ 750 nm).
En astronomie, on peut décomposer la lumière de n'importe quel astre (étoile, nébuleuse, galaxie, etc.) en ces différentes longueurs d'onde à l'aide d'un spectrographe installé sur un télescope ; la précision de la décomposition, c'est à dire la résolution du spectre, dépendra de la qualité et des propriétés du prisme ou du réseau (plus souvent des réseaux de nos jours).

Un spectre brut ressemble à ceci :



Ce sont les spectres de 2 étoiles bien connues, Bételgeuse et Sirius. Elles sont en noir et blanc mais ça ne pose aucun problème. Par convention, la partie bleue est à gauche (et le rouge est à droite).
Toutefois, ce ne sont pas ces spectres bruts qui sont intéressants mais les courbes de lumières qui leur correspondent, calibrées en longueur d'onde et corrigées de certains biais.
Ce sont ces courbes finales qui sont l'objet de la base.

-----------------------------------------------------------------------------------

Un SPECTRE FITS

Un spectre FITS est un fichier au format normalisé FITS (inventé par la NASA pour stocker les images et informations astronomiques).

Le contenu du corps d'un fichier FITS ressemble à ceci :



Ici, c'est le spectre traité de l'étoile variable appelée EG And. Le spectre brut a été calibré en longueur d'onde (à l'aide d'une référence) et corrigé de certains biais atmosphériques et instrumentaux. je ne rentre pas dans les détails.
En abscisse, on a la longueur d'onde (en angstrom, ici, de 4000 à 7500 angstrom) et en ordonnée, on a une intensité relative, sans unité.
Si, en plus, on calibre le spectre en flux, on a en ordonnée une unité du type erg/cm2/s

Ce sont les fichiers FITS qui seront gérés dans la base.

Le format FITS contient 2 parties : un en-tête contenant des métadonnées (nom de l'astre, nom de l'observateur, date de prise de vue, etc.) et un corps contenant les données proprement dites, sachant qu'un fichier FITS peut contenir des données 1D, 2D ou multivariées ou 1 ou plusieurs images. Dans le cas de spectres, on a généralement du 1D voire plusieurs 1D en même temps (spectres échelles).
Nous allons aussi nous servir du contenu de l'en-tête pour peupler la base mais aussi pour vérifier la cohérence des données. Un traitement automatique va vérifier la présence et la cohérence du contenu des champs de l'en-tête FITS du spectre.

les informations tirées de l'en-tête seront stockées dans les différentes tables de la base (OBSERVATEUR, SITE, ETOILE, etc). Celles qui sont spécifiques au fichier à enregistrer seront stockées dans la table SPECTRE.

----------------------------------------------------------------------------------

Un OBSERVATEUR

Un observateur est un astronome amateur qui enregistre et publie des spectres traités.

----------------------------------------------------------------------------------

Un INSTRUMENT

Le mot Instrument est le terme générique pour désigner un télescope servant à enregistrer les spectres.
En français, un instrument désigne à la fois un télescope ou une lunette astronomique (qui sont 2 types différents d'instrument astronomique)... En anglais, un instrument astronomique s'appelle "telescope" de façon générique ; la concision a parfois du bon. Petit problème : le terme télescope désigne plus souvent la partie optique seule d'un télescope et non l'instrument complet.

Je suis donc parti sur les termes suivants :
INSTRUMENT désigne l'instrument complet
TELESCOPE désigne la partie optique seule

Un INSTRUMENT est donc composé d'un TELESCOPE, d'un SPECTROGRAPHE (qui décompose la lumière) et d'une CAMERA (qui enregistre le spectre).

Il est important de séparer le SPECTROGRAPHE de la CAMERA car leurs propriétés respectives influent sur le spectre final.

----------------------------------------------------------------------------------

Un OBSERVATEUR

Un OBSERVATEUR est un astronome amateur qui enregistre et publie des spectres

----------------------------------------------------------------------------------

Un SITE

Un SITE est le lieu géographique où l'OBSERVATEUR utilise son INSTRUMENT.
On peut rapprocher le terme Site de celui d'Observatoire. je n'ai pas utilisé le terme Observatoire pour 2 raisons :
- un Observatoire désigne plutôt une structure en dur, avec un abri, où l'instrument est en poste fixe. Ce n'est pas souvent le cas chez les astronomes amateurs qui ont tendance à déplacer leur instrument d'un site à un autre ou à utiliser leur télescope dans le fond du jardin.
- un Observatoire désigne très souvent une structure professionnelle (Observatoire de Haute-Provence, Observatoire du Pic du Midi, Palomar Observatory, etc.).

---------------------------------------------------------------------------------

Un ASTRE

Un ASTRE désigne n'importe quel objet céleste, que ce soit une étoile, une nébuleuse, une galaxie, un trou noir, un quasar ... Bref tous les objets célestes.

Un ASTRE est désigné par un ou plusieurs ALIAS (des noms). Chaque astronome qui sort son propre catalogue va quasiment donner un nouvel identifiant à une astre. On arrive donc à des étoiles qui ont 45 identifiants différents, par exemple. L'astre Deneb dans la constellation du Cygne possède les identifiants Alpha Cygni (issu du catalogue Flamsteed), HD 197345 (catalogue Henri Draper), GSC 03574-03347 (catalogue GSC, le Guiding Star Catalog du télescope spatial Hubble), etc. Nous ne conserverons que les identifiants les plus utilisés.
Le souci est que les plus utilisés ne sont pas forcément dans les mêmes catalogues ... Par exemple, pratiquement toutes les étoiles variables ont un identifiant GCVS (Global Catalog of Variable Star). Deneb, qui n'est pas variable, n'a donc pas d'identifiant dans le catalogue GCVS. L'étoile variable cataclysmique SS Cyg (catalogue GCVS) n'a pas de nom usuel ni dans le catalogue Flamsteed, ni dans le catalogue Henri Draper.

Un ASTRE est nécessairement situé à certaines coordonnées: l'ascension droite (équivalente à notre longitude terrestre) et la déclinaison (équivalente à notre latitude terrestre).
Le gros souci en astronomie c'est que, du fait de la précession des équinoxes, les coordonnées des étoiles changent avec le temps. En fait, c'est l'origine des coordonnées qui se déplace (le point vernal). C'est comme si on déplaçait le méridien de Greenwich sur la surface de la Terre, méridien qui sert d'origine pour la longitude. C'est encore pire en astronomie puisque que la "latitude" change aussi...
De ce fait, il existe des référentiels de coordonnées différents selon les époques : J1950 pour les années 1950 (référentiel FK3) et J2000 pour les années 2000 (référentiel FK5). Depuis une dizaine d'années, les astronomes ont semblent-ils réglé le problème en prenant une autre origine quasi-fixe et donc créé un nouveau référentiel qui s'appelle ICRS. les valeurs ICRS correspondent globalement à FK5 mais comme personne n'utilise systématiquement le référentiel ICRS (notamment dans les logiciels de cartographie), on est resté sur FK5. C'est donc le référentiel FK5 que nous allons prendre.

Un ASTRE est classé dans une catégorie.
Cette catégorie est totalement artificielle et elle ne sera utile que pour classer les astres dans le site web

----------------------------------------------------------------------------------

Une ETOILE

Une étoile est un type d'ASTRE

Une ETOILE possède une magnitude. La magnitude est une mesure de l'intensité lumineuse d'une étoile. C'est une échelle logarithmique sans dimension. La valeur varie de -27 (magnitude du Soleil) à +30 (magnitude de l'astre le plus faible jamais détecté par un télescope). On peut donc avoir des valeurs négatives. L'étoile Sirius a une MAGNITUDE VISUELLE de -1,46.
J'ai grandement simplifié la notion de magnitude parce qu'une magnitude est normalement valable à une longueur d'onde donnée.

----------------------------------------------------------------------------------

Une ETOILE VARIABLE

Une ETOILE VARIABLE est un type d'ETOILE

J'ai donc mis en place une cascade d'héritage parce que les étoiles, étoiles variables et astres ne partagent pas systématiquement les même propriétés

Comme elle varie, une ETOILE VARIABLE possède 2 valeurs de magnitude : une MAGNITUDE MINIMALE et une MAGNITUDE MAXIMALE. Ces valeurs oscillent selon une PERIODE DE VARIATION, exprimée en jours.
Il est possible qu'on ne connaisse pas l'une des 2 valeurs de magnitude, ou la valeur de la période de variation.

----------------------------------------------------------------------------------

J'espère que je n'ai rien oublié pour expliquer le vocabulaire utilisé.
Je vais de toute façon poster aussi les règles de gestion pour que vous puissiez juger de la pertinence de mon MCD.

Merci d'avance
Vincent

[aras-vbo]

Le terme "validateur" que vous utilisez à plusieurs reprises, s'il fait partie du jargon métier, doit être expliqué, sinon remplacé (contrôleur, agréeur, certificateur...)

J'ai totalement oublié cette notion dans mon MCD. Je vais le compléter.

Un Validateur est avant tout un Observateur qui possède suffisamment d'expérience pour juger de la bonne qualité d'un spectre qui est soumis. Actuellement, nous avons 3 validateurs.
Je pense que je peux faire figurer la notion de Validation au travers d'une entité DROITS associée à OBSERVATEUR.

Concernant le MCD :
Instruments
Je ne comprends pas ce que c'est. Vos cardinalités indiquent que ce serait à la fois un télescope, un spectrographe et une caméra !

Ce qui me surprend, sans doute est-ce dû à ma méconnaissance du sujet, est que ce faisant, un observateur qui n'aurait par exemple pas de caméra, ne pourrait pas enregistrer d'observations dans votre base de données ? Si vous confirmez ces cardinalités, alors on pourrait n'avoir qu'une seule entité-type "instrument" qui inclurait aussi les attributs que vous avez mis dans les 3 ET "télescope", "spectrographe" et "caméra"

Un INSTRUMENT possède nécessairement un seul TELESCOPE, un seul SPECTROGRAPHE et une seule CAMERA. Si la CAMERA, le SPECTROGRAPHE ou le TELESCOPE est différent alors on considère que l'INSTRUMENT est différent.
Un OBSERVATEUR utilise 1 ou plusieurs INSTRUMENT (il peut avoir plusieurs TELESCOPE, SPECTROGRAPHE ou CAMERA chez lui).
Un INSTRUMENT peut être utilisé par 1 ou plusieurs OBSERVATEUR (il peut s'agir d'une équipe d'observateurs qui utilisent le même instrument d'observatoire, par exemple)

J'ai un doute sur les cardinalités que j'ai indiqué.

J'ai hésité à mettre une cardinalité 1,n du côté TELESCOPE, SPECTROGRAPHE et CAMERA car, par exemple, un spectrographe de marque Shelyak et de type Alpy 600 peut être associé à plusieurs configurations d'instrument possibles pouvant être possédés par plusieurs observateurs différents (qui possèdent chacun un spectrographe Shelyak Alpy 600)
Le souci est que je ne connais pas tous les types de spectrographes disponibles sur le marché. Et que faire des amateurs qui construisent leur spectrographe eux-mêmes ?

Astres et étoiles
Là aussi, les cardinalités 1,1 avec coordonnées_FK5 donnent à penser qu'une entité-type unique est possible voire souhaitable
Concernant les différentes magnitudes, ne peut on pas les associer aussi à des astres autres que des étoiles ? une planète par exemple n'a-t- elle pas une magnitude ?
Si oui, faute d'attributs spécifiques aux étoiles et étoiles variables, ces sous-types ne seraient pas requis

Je vais sans doute rattacher l'entité-type MAGNITUDE VISUELLE à ASTRE et non au sous-type ETOILE. Effectivement, une planète, voire une nébuleuse possède aussi une magnitude, bien que certains astres n'aient pas de magnitude (un trou-noir, par exemple...). Je vais changer la cardinalité en conséquence.

Par contre, les magnitudes minimale et maximale sont à rapprocher des astres variables uniquement. Ces valeurs ne sont pas pertinentes pour des astres dont la magnitude est invariable.

J'ai créé une entité-type COORDONNEES_FK5 car un astre est susceptible de posséder d'autres coordonnées dans un autre référentiel que FK5. Je pourrai effectivement en faire un attribut de ASTRE étant donné que ces valeurs sont obligatoires. Mais j'ai cru comprendre que l'ajout ultérieurs d'attributs est préférable sous forme d'entité-type pour éviter des tables obèses.

Magnitude
Plutôt que de faire autant d'entités-type qu'il y a de types de magnitudes, faites n'en qu'une seule, et créez une ET "type de magnitude" ainsi
ASTRE 0,n --- posseder --- 0,n MAGNITUDE 1,1--- typer --- 0,n TYPE
Autant que je sache, la magnitude est un niveau de luminosité, qui peut donc être le même pour plusieurs astres

Est-ce qu'on ne créé pas de répétition de données dans ce cas ? Faudrait-il créér une entité-type TYPE_MAGNITUDE rattachée à MAGNITUDE ?

Vos attributs sont typés mais pas dimensionnés, à compléter donc

Je les aies dimensionnées dans JMerise mais elles n'apparaissent pas sur mon MCD. Je vais vérifier si il y a moyen de les afficher.

Le type Float est utilisé pour les très grande valeurs (en puissances de 10), ce n'est donc pas idéal pour des latitudes et longitudes

Que me conseillez-vous ? Un type Double ou Numeric ?

Pour les identifiants des relations, on privilégie en général des verbes. Quoi qu'il en soit vous avez de nombreux homonymes
A corriger s'il y a des attributs ou des relations n de chaque côté, car les tables générées lors de la dérivation du MLD prendront les noms de ces relations, et évidemment les doublons sont interdits

Je vais y remédier.
Comment doit-on nommer des relations dont la cardinalité est 0,1 et qui reflète un caractère d'appartenance ?

Merci de vos remarques
Vincent

[escartefigue]

Un Validateur est avant tout un Observateur qui possède suffisamment d'expérience pour juger de la bonne qualité d'un spectre qui est soumis. Actuellement, nous avons 3 validateurs.
Je pense que je peux faire figurer la notion de Validation au travers d'une entité DROITS associée à OBSERVATEUR.

C'est surtout que "validateur" tout comme "valideur" ne sont pas des mots du dictionnaire courant, il convient donc de créer un glossaire des termes spécifiques (jargon) et sigles utilisés.

Un INSTRUMENT possède nécessairement un seul TELESCOPE, un seul SPECTROGRAPHE et une seule CAMERA. Si la CAMERA, le SPECTROGRAPHE ou le TELESCOPE est différent alors on considère que l'INSTRUMENT est différent.

Ce que j' n'arrive pas à voir, c'est si l'instrument a une existence propre, quel est l'intérêt pour vous d'identifier un instrument
Autant, pour les équipements qui le composent, j'arrive à imaginer des attributs : longueur, largeur, poids, précision, consommation électrique, sensibilité etc...
Autant, hors code et libellé, il semble que l'instrument soit dépourvu d'attributs. Qu'en est il vraiment ?
Question subsidiaire : si un astronome possède 2 télescopes mais seulement une caméra et un spectrographe, alors combien cet astronome a-t- il d'instruments ?

J'ai hésité à mettre une cardinalité 1,n du côté TELESCOPE, SPECTROGRAPHE et CAMERA car, par exemple, un spectrographe de marque Shelyak et de type Alpy 600 peut être associé à plusieurs configurations d'instrument possibles pouvant être possédés par plusieurs observateurs différents (qui possèdent chacun un spectrographe Shelyak Alpy 600)
Le souci est que je ne connais pas tous les types de spectrographes disponibles sur le marché. Et que faire des amateurs qui construisent leur spectrographe eux-mêmes ?

Il faut mettre une cardinalité 1,n seulement si le même équipement et non pas le même modèle d'équipement, est utilisé dans 2 instruments.
Exemple : le spectrographe de marque Shelyak, de type Alpy 600 et de numéro de série 123456789 est utilisé dans 2 instruments

J'ai créé une entité-type COORDONNEES_FK5 car un astre est susceptible de posséder d'autres coordonnées dans un autre référentiel que FK5. Je pourrai effectivement en faire un attribut de ASTRE étant donné que ces valeurs sont obligatoires. Mais j'ai cru comprendre que l'ajout ultérieurs d'attributs est préférable sous forme d'entité-type pour éviter des tables obèses.

C'est paradoxal de nommer l'entité-type FK5, si elle concerne des mesures non FK5
Pour les tables obèses, vu que vous n'avez que 2-3 attributs par entité-type ou association, vous n'êtes pas concernés.

Est-ce qu'on ne créé pas de répétition de données dans ce cas ? Faudrait-il créér une entité-type TYPE_MAGNITUDE rattachée à MAGNITUDE ?

C'est bien ce que je vous propose, vous n'avez qu'une seule entité-type "MAGNITUDE", vous créerez autant d'occurrences que nécessaire, chaque occurrence sera typée grâce à la relation entre cette occurrence et l'entité-type "TYPE_MAGNITUDE" (l'ET coté cardinalité 1, héritera de la clef coté n, donc du type de magnitude)

Que me conseillez-vous ? Un type Double ou Numeric ?

Selon l'outil de modélisation, (je ne connais pas JMerise) c'est numeric ou decimal qui convient le mieux. Avec du Float, vous perdrez vos décimales.

Comment doit-on nommer des relations dont la cardinalité est 0,1 et qui reflète un caractère d'appartenance ?

Vous parlez de "possède" par exemple entre "ETOILE" et "MAGNITUDE_VISUELLE" ?
Si c'est ça, "posseder" est préférable
Evitez aussi les accents, blancs, cédilles etc... dans les noms d'ET et de relations, évitez de même les noms réservés (TABLE, SPACE, QUOTE, SELECT par exemple)

[CinePhil]

Bonjour.

Sujet effectivement passionnant et probablement inédit sur ce forum.

Mes observations, un peu en vrac...

1) Le valideur
Une propriété booléenne "est_valideur" ne serait-elle pas suffisante dans l'entité-type "OBSERVATEUR" ?

2) DNS_EMAIL
C'est quoi ?
Les cardinalités 1,1 - 1,1 laissent à penser que c'est juste une propriété de EMAIL qui pourrait donc y être rapatriée.

3) Boucle infernale
Le schéma actuel permet à un observateur d'habiter dans un pays et d'utiliser un instrument qui est installé sur un site situé dans un autre pays. Est-ce possible ?
Sinon il faut mettre une contrainte fonctionnelle.

4) Ambiguïté sur ce qu'est un INSTRUMENT
J'ai bien compris qu'un instrument est composé d'un télescope, d'un spectrographe et d'une caméra mais est-ce qu'un instrument X est un nom générique qui sera composé de toujours les mêmes instruments et qui pourra être acheté tel quel par un observateur O ou P, ou bien est-ce l'instrument de l'observateur O, en tant qu'ensemble d'éléments achetés par O et assemblés uniquement par lui ?

Quelle que soit la réponse, il semble par contre que le télescope T1 soit un équipement disponible dans le commerce et qu'il puisse entré dans la composition de plusieurs instruments différents possédés par des observateurs différents. La cardinalité côté TELESCOPE devrait donc être 1,n ou 0,n.
Idem pour SPECTROGRAPHE et CAMERA.

5) Un astre peut être classé dans plusieurs catégories ?

6) Puisque, si j'ai bien compris, vous n'utiliserez que le système de coordonnées FK5, pourquoi ne pas rapatrier ces coordonnées dans ASTRE ?
Les cardinalités 1,1 - 1,1 justifient d'ailleurs tout à fait ce rapatriement.

7) Magnitudes
Puisqu'il s'agit d'une valeur de mesure qui est propre à l'étoile, pourquoi ne pas en faire une propriété de ETOILE ?
Idem pour les magnitudes min et max, ainsi que la période de variation, qui sont propres aux étoiles variables.
Si j'ai bien compris vos explications, il ne s'agit pas d'entités types mais de propriétés.

[escartefigue]

Bonjour.
4) Ambiguïté sur ce qu'est un INSTRUMENT
J'ai bien compris qu'un instrument est composé d'un télescope, d'un spectrographe et d'une caméra mais est-ce qu'un instrument X est un nom générique qui sera composé de toujours les mêmes instruments et qui pourra être acheté tel quel par un observateur O ou P, ou bien est-ce l'instrument de l'observateur O, en tant qu'ensemble d'éléments achetés par O et assemblés uniquement par lui ?

+1

7) Magnitudes
Puisqu'il s'agit d'une valeur de mesure qui est propre à l'étoile, pourquoi ne pas en faire une propriété de ETOILE ?

Non car :

Je vais sans doute rattacher l'entité-type MAGNITUDE VISUELLE à ASTRE et non au sous-type ETOILE. Effectivement, une planète, voire une nébuleuse possède aussi une magnitude, bien que certains astres n'aient pas de magnitude (un trou-noir, par exemple...). Je vais changer la cardinalité en conséquence.

Il faut donc une cardinalité 0,1 entre astre et magnitude et éventuellement une CIF pour vérifier que si magnitude il y a, elle vérifie que le type d'astre est bien concerné

[CinePhil]

7) Magnitudes
Puisqu'il s'agit d'une valeur de mesure qui est propre à l'étoile, pourquoi ne pas en faire une propriété de ETOILE ?

Je vais sans doute rattacher l'entité-type MAGNITUDE VISUELLE à ASTRE et non au sous-type ETOILE. Effectivement, une planète, voire une nébuleuse possède aussi une magnitude, bien que certains astres n'aient pas de magnitude (un trou-noir, par exemple...). Je vais changer la cardinalité en conséquence.

Il faut donc une cardinalité 0,1 entre astre et magnitude et éventuellement une CIF pour vérifier que si magnitude il y a, elle vérifie que le type d'astre est bien concerné

1) Y a t-il d'autres astres que les trous noirs qui n'aient pas de magnitude ?
2) Je reprends un extrait de votre premier message qui cadre le domaine à modéliser :

Il s'agit d'une "association" qui regroupe des astronomes amateurs de nombreux pays (en Europe, aux Etats-Unis et en Australie notamment) qui utilisent leurs télescopes pour enregistrer le spectre des étoiles, principalement des étoiles particulières et/ou variables car ce sont les plus intéressantes à suivre.

Apparemment, votre BDD contiendra principalement des étoiles variables.
Il peut être intéressant qu'il y ait aussi les étoiles "classiques", peut-être les galaxies (qui ne se distinguent pas à l'oeil nu des étoiles).
Je doute déjà un peu de la pertinence d'enregistrer les planètes. Celles du système solaire ne sont pas dans l'objet de votre étude et elles sont bien connues pour qu'il n'y ait pas de confusion pour les astronomes amateurs qui participent à votre collecte de données et a fortiori pour les astronomes professionnel qui seraient intéressés par vos données. Les planètes extra-solaires ne sont pas observables directement et leur magnitude ne peut donc pas être mesurée.
Quant aux trous noirs, puisque, par définition, il ne peuvent pas être observés, pourquoi vouloir les mettre dans votre BDD ?

Bref, je vous suggère de recentrer votre BDD sur son objet principal, au moins dans un premier temps.
On ne plante pas une punaise dans du carton avec une masse !

Je maintiens donc ma suggestion de mettre la magnitude dans étoile ou dans astre et les magnitudes min et max dans étoile variable. Ça ne présente pas d'intérêt d'en faire une entité-type.

[aras-vbo]

Bonsoir

Quelques précisions concernant la notion d'INSTRUMENT

Un instrument a une existence propre. C'est une configuration de plusieurs éléments : un télescope (un tube optique de télescope ou de lunette astronomique qui possède ses propres caractéristiques comme son diamètre ou sa focale) + un spectrographe (qui possède aussi ses caractéristiques comme son modèle, le nombre de traits/mm du réseau, sa résolution théorique, etc.) + une caméra (avec ses caractéristiques comme son modèle, la taille de son capteur, la taille d'un pixel). A partir du moment où 1 ou plusieurs éléments de la configuration sont modifiés, on peut considérer qu'il s'agit d'un autre instrument.
Par exemple, si un astronome possède 2 télescopes mais une seule caméra et un seul spectrographe, alors il aura 2 instruments différents, c'est à dire 2 combinaisons possibles (le télescope n°1 + spectro + caméra et le télescope n°2 + spectro + caméra).

Chaque configuration se doit d'être identifiée. On ne peut pas considérer que 2 configurations (instruments) possédant 2 spectrographes différents puissent être considérés comme identiques.

Pour les entités CAMERA, TELESCOPE ou SPECTROGRAPHE, ce sont les caractéristiques générales des modèles de télescope, de spectrographes et de caméras qui m'intéressent et non celles de tel ou tel élément particulier. Par exemple, je ne stockerai pas de numéro de série. Je les rapproche de la notion de LIVRE et d'EXEMPLAIRE. Je reste au niveau des caractéristiques du LIVRE et non celles de tel ou tel EXEMPLAIRE.

Dans la base, je veux pouvoir extraire les spectres qui ont été réalisés avec un type de spectrographe (par exemple, un Alpy600) quelle que soit la configuration (le télescope ou la caméra associés). Toutefois, il faut que l'observateur puisse identifier rapidement la configuration qu'il utilise car ce nom va être inséré automatiquement par le logiciel de traitement des spectres (indépendant de la base) dans un mot-clé de l'en-tête du spectre FITS. Comme l'en-tête FITS ne stocke pas systématiquement des identifiants de caméra ou de spectrographe, il faut que je puisse associer une configuration donnée, figurant dans l'en-tête du fichier FITS avec les éléments qu'elle contient (télescope, caméra et spectrographe) car ces éléments sont très importants pour analyser le spectre.

[escartefigue]

Par exemple, si un astronome possède 2 télescopes mais une seule caméra et un seul spectrographe, alors il aura 2 instruments différents, c'est à dire 2 combinaisons possibles (le télescope n°1 + spectro + caméra et le télescope n°2 + spectro + caméra).

Chaque configuration se doit d'être identifiée. On ne peut pas considérer que 2 configurations (instruments) possédant 2 spectrographes différents puissent être considérés comme identiques.

OK, du coup il faut modifier les cardinalités ainsi :
INSTRUMENT 1,1 --- contenir --- 1,n TELESCOPE
idem pour spectrographe et caméra

[aras-vbo]

Tout d'abord merci pour vos conseils avisés et vos questions. Cela permet de remettre les idées en place et de tout bien recadrer.

Suite à vos remarques, j'ai modifié mon MCD de la façon suivante :

1 - j'ai renommé l'entité-type DNS_EMAIL en SUFFIXE_EMAIL pour que ce soit plus explicite. Le suffixe est simplement l'adresse située derrière le caractère @ de l'email ; il est générique pour de nombreuses adresses donc je l'ai factorisé dans une entité-type (comme conseillé par Soutou et Brouard dans leur livre).

2 - j'ai modifié tous les intitulés des relations en y mettant des verbes à l'infinitif, sans caractère spécial.

3 - J'ai modifié la cardinalité des éléments suivants :

INSTRUMENT 1,1 ----- contenir ----- 1,n TELESCOPE
INSTRUMENT 1,1 ----- contenir ----- 1,n SPECTROGRAPHE
INSTRUMENT 1,1 ----- contenir ----- 1,n CAMERA

EMAIL 1,1 ----- inclure ----- 1,n SUFFIXE_EMAIL

4 - J'ai complètement remanié les entités-type des magnitudes. Toutes les magnitudes de tous les types d'astres ont été ramenées dans une seule entité-type MAGNITUDE qui possède une entité liée qui est TYPE_MAGNITUDE. Ceci dit, il faudra que j'étudie les CIF et le moyen de restreindre l'association de certaines magnitudes avec certains types d'étoiles seulement (les magnitudes min et max ne concernent que les étoiles variables).

5 - J'ai ajouté 2 relations entre OBSERVATEUR et SPECTRE_FITS (Soumettre et Valider). J'ai ajouté la propriété "est_valideur" dans OBSERVATEUR pour discriminer les observateurs classiques de ceux qui peuvent valider les spectres soumis. J'ai hésité à utiliser un héritage mais je pense que c'est superflu.
Les règles sont les suivantes :
- un observateur peut soumettre autant de spectres qu'il le souhaite ou aucun ; un spectre peut être proposé par plusieurs observateurs (une équipe utilisant le même instrument, par exemple)
- un valideur peut valider 0 ou n spectres mais un spectre est nécessairement validé par un seul valideur.
Chaque relation est munie d'une propriété de date.

J'ai hésité à renommer mon entité-type INSTRUMENT en CONFIGURATION pour la rendre plus explicite. Le souci est qu'un mot-clé de l'en-tête FITS est précisément INSTRUMENT et correspond exactement à cette notion de " intitulé de la configuration du matériel". Je préfère donc conserver le terme INSTRUMENT pour le faire coller au mot-clé qui sera rempli systématiquement par les observateurs ; c'est un mot-clé obligatoire de l'en-tête.


Voici le MCD modifié :



Voici les réponses à Escartefigue et CinePhil

L'entité-type COORDONNEES_FK5 ne contiendra que les coordonnées (ascension droite et déclinaison) du référentiel FK5 et aucune autre.
Si je mets en place une utilisation des coordonnées ICRS dans l'avenir (qui se substitueront sans doute à FK5), je souhaite créer une nouvelle entité-type COORDONNEES_ICRS que je rattacherai à l'entité ASTRE comme je l'ai fait pour COORDONNEES_FK5. Est-ce que cela vous paraît judicieux ou non ? Ou dois-je considérer les coordonnées, quelles qu'elles soient, comme des propriétés de l'entité-type ASTRE, quitte à les ajouter dans l'entité-type par la suite ? J'ai cru comprendre, selon Frédéric Brouard, qu'il était plus raisonnable d'ajouter des entités-type plutôt que des propriétés pour faire évoluer une base.

Un OBSERVATEUR peut tout à fait habiter dans un pays (ou plutôt avoir 1 ou plusieurs nationalités) mais utiliser un instrument dans un autre pays. Un OBSERVATEUR peut transporter son matériel dans un site de vacances situé dans un autre pays pour y faire des spectres (la météo est plus clémente). Un OBSERVATEUR peut aussi installer son instrument dans une coupole dans un pays et il le pilote à distance depuis un autre (cela se fait de plus en plus chez les amateurs, à l'instar de ce qui se fait chez les professionnels ; il existe des fermes de télescopes ou d'abris).

Un ASTRE peut faire partie de plusieurs CATEGORIES. Certaines étoiles variables n'ont pas de classification définitive et sont placées dans plusieurs catégories car leur comportement les rapproche de plusieurs types à la fois.

J'hésite à mettre dans ASTRE les différentes magnitudes car j'ai la hantise du NULL ...
Certaines étoiles n'ont pas de magnitude visuelle à proprement parlé. C'est le cas des variables dont l'éclat varie et qui n'ont donc pas de magnitude fixe, juste des magnitudes max et min. Certaines variables mal connues n'ont soit pas de magnitude mini, soit pas de magnitude maxi, voire aucune des 2 et seulement une magnitude visuelle (on les sait variables intrinsèquement du fait de leur nature mais on n'a encore jamais observé de variation ou leur période est trop longue).
Du coup, dans le doute, je préfère en faire des entités-types. Je ne sais pas si j'ai raison.

Nous ne faisons pas de spectres des planètes car ce n'est pas notre domaine d'investigation. Par contre, nous faisons le spectre d'étoiles non variables (ou variables) possédant des exoplanètes. Certains d'entre nous (dont Christian Buil, un des initiateurs d'ARAS) ont même réussi à retrouver les planètes à l'aide de la techniques des vitesses radiales : on observe le mouvement de l'étoile par rapport au barycentre du système stellaire complet (avec la ou les planètes) en mesurant le décalage Doppler de certaines raies du spectre de l'étoile.
C'est aussi de cette façon qu'on "observe" les trous noirs. Cygnus X1 est un cas d'école, le premier trou noir découvert, et aussi un des seuls pouvant être spectrographié par des amateurs. En fait, on mesure le spectre de l'étoile-compagnon et/ou du disque d'accrétion de matière entourant le trou noir et non le trou noir lui-même qui, par définition, n'émet rien. j'aurai donc dans la base une catégorie Trou noir dans lequel il y a aura 1 ou 2 objets.

A l'avenir, je souhaite pouvoir inclure dans la base certaines étoiles classiques non variables utilisées comme "références spectroscopiques".
On utilise ces références pour calibrer les spectres des étoiles variables. Ce sont des étoiles dont le spectre est parfaitement connu, soit parce que leur type spectral est générique, soit parce que leur spectre a été enregistré depuis l'espace, hors de notre atmosphère, par des télescopes ou des satellites. En enregistrant le spectre de ces étoiles de référence, on peut ensuite calculer les biais dont souffrent nos mesures (biais optiques, atmosphériques, etc.) et les "soustraire" aux spectres des étoiles variables que l'on souhaite mesurer pour obtenir un spectre le plus objectif que possible.


J'ai complètement oublié de vous donner le lien vers la "base de données" actuelle, dont les pages sont réalisées à partir de feuilles Excel ... : Base ARAS actuelle.

Je vous remercie vraiment pour le temps que vous passez à partager vos conseils.

Vincent

[escartefigue]

4 - J'ai complètement remanié les entités-type des magnitudes. Toutes les magnitudes de tous les types d'astres ont été ramenées dans une seule entité-type MAGNITUDE qui possède une entité liée qui est TYPE_MAGNITUDE. Ceci dit, il faudra que j'étudie les CIF et le moyen de restreindre l'association de certaines magnitudes avec certains types d'étoiles seulement (les magnitudes min et max ne concernent que les étoiles variables).

C'est parfait si plusieurs types d'astres font l'objet de relevés de magnitude, si au contraire seules les étoiles sont concernées, l'option proposée par Cinephil était une autre possibilité.

5 - J'ai ajouté 2 relations entre OBSERVATEUR et SPECTRE_FITS (Soumettre et Valider). J'ai ajouté la propriété "est_valideur" dans OBSERVATEUR pour discriminer les observateurs classiques de ceux qui peuvent valider les spectres soumis. J'ai hésité à utiliser un héritage mais je pense que c'est superflu.
Les règles sont les suivantes :
- un observateur peut soumettre autant de spectres qu'il le souhaite ou aucun ; un spectre peut être proposé par plusieurs observateurs (une équipe utilisant le même instrument, par exemple)
- un valideur peut valider 0 ou n spectres mais un spectre est nécessairement validé par un seul valideur.
Chaque relation est munie d'une propriété de date.

On peut supposer que le valideur n'est jamais le demandeur, si c'est c'est bien ça, c'est une règle supplémentaire qu' il faudra là aussi vérifier par une "CIF" de type "exclusion"

L'entité-type COORDONNEES_FK5 ne contiendra que les coordonnées (ascension droite et déclinaison) du référentiel FK5 et aucune autre.
Si je mets en place une utilisation des coordonnées ICRS dans l'avenir (qui se substitueront sans doute à FK5), je souhaite créer une nouvelle entité-type COORDONNEES_ICRS que je rattacherai à l'entité ASTRE comme je l'ai fait pour COORDONNEES_FK5. Est-ce que cela vous paraît judicieux ou non ? Ou dois-je considérer les coordonnées, quelles qu'elles soient, comme des propriétés de l'entité-type ASTRE, quitte à les ajouter dans l'entité-type par la suite ? J'ai cru comprendre, selon Frédéric Brouard, qu'il était plus raisonnable d'ajouter des entités-type plutôt que des propriétés pour faire évoluer une base.

Vu le peu d'attributs de l'ET astres, ajouter les coordonnées dans cette ET n'est pas un problème si vous n'avez comme c'est le cas qu'une et une seule occurrence de coordonnées pour un astre.
Sauf si lors du passage du système FK5 vers le système ICRS, il y a une période +/- longue pendant laquelle vous aurez les 2 valeurs qui cohabitent, auquel cas il est préférable d'avoir une ET séparée, avec une cardinalité 1,n de astres vers COORDONNEES qui du coup ne devra pas être suffixé FK5, mais être en relation 1,1 avec un type de coordonnées.

Je vous remercie vraiment pour le temps que vous passez à partager vos conseils.
Vincent

Merci à vous de nous faire découvrir ce sujet passionnant

[SQLpro]

En ce qui concerne le stockage des fichiers (image téléscope, spectre, FITS...) vous auriez sans doute intérêt à vous orienter vers un SGBDR capable de stocker des fichiers selon le principe du "datalink" de la norme SQL. Ceci permet de manipuler des fichiers sous le contrôle du SGBDR (donc transactionnés, sauvegardés de manière synchrone aux données) et non plus dissocié des données de la base. Pour info, Pann Starr utilise SQL Server et les images sont stockées via un ensemble de serveurs de fichiers sous le contrôle de la base via le FILESTREAM

Au passage, votre modèle me parait globalement pas mal du tout....

A +

[aras-vbo]

Bonsoir,

Suite à vos derniers retours, j'ai effectué quelques modifications sur le MCD :

1 - J'ai supprimé l'entité-type COORDONNEES_FK5 pour réintégrer les attributs dans l'entité-type ASTRE. Etant donné qu'ils ont un caractère obligatoire, il n'y a aura pas de valeurs NULL pouvant polluer et la relation 1,1 ne justifiait pas la présence d'une entité séparée.

2 - J'ai remanié la partie relative aux spectres à proprement parlé :

- L'entité-type SPECTRE_FITS a été supprimée. Elle ne servait que dans le cas où le spectre est constitué d'une série de fichiers, avec une cardinalité 0,n. Or, je peux (et je dois) considérer que chaque fichier FITS est un spectre à part entière, avec son propre en-tête et son propre processus de validation (un valideur ne valide pas une série complète mais chaque spectre séparément).
Par conséquent, les données obligatoires de l'en-tête qui ne figuraient pas dans l'ancien MCD ont été insérées dans l'entité-type SPECTRE. Le lien vers le fichier FITS correspondant aussi, ainsi que les attributs de validation. Les 2 relations Valider et Soumettre ont été rattachées à SPECTRE.
- La notion de série (série de spectres et donc de fichiers FITS correspondants) est explicitée par l'entité-type SERIE_SPECTRE avec une cardinalité 0,1 ; un spectre pouvant faire partie ou non d'une série.
- Un attribut spécifique à un type de spectre (les spectre échelle) et à caractère obligatoire m'oblige à créer une entité-type SPECTRE_ECHELLE héritée de SPECTRE.

Est-ce que cela vous paraît cohérent ?



Frédéric,

J'ai regardé vos liens et ils sont très intéressants. Cela paraît effectivement très adapté à notre problématique. Ce serait même l'idéal, dans l'absolu.

Le seul souci est le peu d'implémentation de la norme Datalink, hormis dans SQL Server avec FILESTREAM. Je suis surtout utilisateur de Postgresql mais je suis tout à fait ouvert à SQL Server. Toutefois, le coût pour une structure informelle d'un hébergement incluant SQL Server est assez important, plusieurs dizaines d'euros par mois dans le meilleur cas (en fait, dans ce cas, le coût est pris en charge par quelques membres, au nom de la communauté). Ceci dit, nous ne faisons pas affaire avec la même volumétrie et la même criticité que PAN-STARRS ...
Est-ce qu'un hébergement Windows Azure peut faire l'affaire ou faut-il envisager une autre formule ? Peut-on monter un serveur de développement à moindre coût avec SQL Server ?

Vincent

[SQLpro]

Frédéric,

J'ai regardé vos liens et ils sont très intéressants. Cela paraît effectivement très adapté à notre problématique. Ce serait même l'idéal, dans l'absolu.

Le seul souci est le peu d'implémentation de la norme Datalink, hormis dans SQL Server avec FILESTREAM. Je suis surtout utilisateur de Postgresql mais je suis tout à fait ouvert à SQL Server. Toutefois, le coût pour une structure informelle d'un hébergement incluant SQL Server est assez important, plusieurs dizaines d'euros par mois dans le meilleur cas (en fait, dans ce cas, le coût est pris en charge par quelques membres, au nom de la communauté). Ceci dit, nous ne faisons pas affaire avec la même volumétrie et la même criticité que PAN-STARRS ...
Est-ce qu'un hébergement Windows Azure peut faire l'affaire ou faut-il envisager une autre formule ? Peut-on monter un serveur de développement à moindre coût avec SQL Server ?

Vincent

Seuls Oracle et SQL Server offrent à ce jour ce genre de service et SQL Server est 2 à 24 fois moins cher selon les config... Mais vous avez une solution encore moins couteuse c'est de louer un serveur MS SQL en edition Web, c'est quelques dizaines d'euros de plus que PG, pour une puissance sans équivalent...
Par exemple chez OVH :
https://www.ovh.com/fr/serveurs_dedi...sql_server.xml
Cette solution est valable jusqu'à quelques centaines de GO de données relationnelles + données DATALINK illimitées et plusieurs centaines d'utilisateurs simultanés (là c'est plus le CPU, mais avec une limite à 16 coeurs, vous pouvez absorber une charge théorique de 4 000 utilisateurs simultanés...

A +

[aras-vbo]

Je ne pense pas que cela soit si simple et si économique. Par exemple, chez OVH, pour faire tourner un SQL Server (23 € HT/mois dans sa version Web 4 CPU), il faut impérativement un serveur sous Windows Server 2012 (donc prix de la licence à ajouter : 20 € HT/mois en version mono-processeur) qui n'est disponible que sur un serveur dédié (options Cloud, mini 60 € HT/mois). Autant dire que la facture s'allourdit assez vite. Pour le tiers de cette somme, j'ai un hébergement Performance 4 avec Postgresql sur un serveur SQL Privé.
J'ai aussi regardé sur Azure mais SQL Database proposé ne gère pas FILESTREAM.

Il est certain que la solution Microsoft est la plus fiable et la plus solide mais nous ne pouvons pas en assurer le coût pour le moment. Il faut donc que je trouve une solution alternative. Je garde la solution Datalink dans un coin de la tête pour le jour où nous aurons suffisamment de financement pour la mettre en oeuvre.

Vincent

[SQLpro]

Je ne pense pas que cela soit si simple et si économique. Par exemple, chez OVH, pour faire tourner un SQL Server (23 € HT/mois dans sa version Web 4 CPU), il faut impérativement un serveur sous Windows Server 2012 (donc prix de la licence à ajouter : 20 € HT/mois en version mono-processeur) qui n'est disponible que sur un serveur dédié (options Cloud, mini 60 € HT/mois). Autant dire que la facture s'allourdit assez vite. Pour le tiers de cette somme, j'ai un hébergement Performance 4 avec Postgresql sur un serveur SQL Privé.
J'ai aussi regardé sur Azure mais SQL Database proposé ne gère pas FILESTREAM.

Il est certain que la solution Microsoft est la plus fiable et la plus solide mais nous ne pouvons pas en assurer le coût pour le moment. Il faut donc que je trouve une solution alternative. Je garde la solution Datalink dans un coin de la tête pour le jour où nous aurons suffisamment de financement pour la mettre en oeuvre.

Vincent

Non Azure est beaucoup beaucoup plus cher ! C'est le prix une fiabilité hors paire... (redondance synchrone sur un minimum de 3 serveurs).
Méfiez vous des offre alléchantes du "free". Ce sont des prix d'appel dans des configurations si minimale qu'elle assurent juste la lecture d'un blog. Après il faut sans cesse rajouter, rajouter.. Mais ça vous ne le saurez qu'une fois en prod ! Donc avec du volume et des data qu'il faudra migrer et ce sera trop tard...

A +

[aras-vbo]

J'ai remis au propre mon MCD.

La partie Spectre a été bien remaniée. Je crois qu'elle en avait besoin.

Les règles de gestion sont les suivantes :
SP_01 : Un spectre est enregistré par 1 seul instrument
SP_02 : Un spectre est enregistré à une date donnée (date + heure à la seconde près).
SP_03 : Un spectre est enregistré pendant une certaine durée d'exposition (exprimée en secondes).
SP_04 : Un spectre peut appartenir à une série de spectres ou non (une série est ici dans le sens de série temporelle).

Les attributs du spectre sont les suivants :
SP_AT_01 : Un spectre est associé à un fichier FITS, non modifiable, stocké dans le système de fichiers du site Internet après qu'il ait été uploadé et soumis par l'observateur.
SP_AT_02 : Un spectre peut être affiché ou non sur le site
SP_AT_03 : Un spectre peut être dans 3 états de validation : en attente de validation, validé, non validé.


J'ai quelques difficultés à modéliser les mots-clés d'un spectre :

L'en-tête du fichier FITS associé à chaque spectre contient des mots-clés qui sont extraits automatiquement lorsque le fichier FITS est soumis au site par l'observateur. Ces mots-clés servent à 2 choses :
1 - remplir automatiquement certains champs de la base de données (temps de poses, durée, etc.), après une simple vérification de format
2 - associer le spectre à des valeurs déjà existantes dans la base (un observateur, un site, un astre, etc.) pour assurer une intégrité de la base

Je ne sais pas si je dois stocker ces mots-clés dans la base, une fois extraits, sachant qu'ils sont déjà stockés dans l'en-tête du fichier FITS.
Il me semble qu'il serait intéressant de les stocker quand même une seconde fois dans la base, au moins pour pouvoir faire des requêtes sur un certain nombre d'entre eux.

Si je décide de stocker les mots-clés dans la base, est-ce que je dois stocker les mots-clés relatifs à des champs qui peuvent déjà être extraits de la base par d'autres moyens (notamment par des associations existantes) ?
Par exemple, je télécharge un de mes spectres (un fichier FITS) sur le site et il se retrouve associé à un observateur (moi) inscrit sur le site, donc déjà référencé dans la base (avec plusieurs alias dont le principal est VBO). Il existe dans l'en-tête de ce fichier FITS un mot-clé qui s'appelle OBSERVER et qui sera déjà rempli (peut-être avec VBO ou avec un autre de mes alias). Est-ce qu'il sera utile de créer ce mot-clé dans la base, associé à mon spectre, sachant qu'il serait facile de le retrouver à l'aide d'une requête ?

Trois options s'offrent donc à moi :

1 - soit je ne stocke AUCUN mot-clé de l'en-tête sous forme de mot-clé explicite dans la base. J'utilise l'en-tête pour extraire les données manquantes obligatoires et je les stocke sous forme d'attributs ou d'associations. L'avantage est qu'il n'y a pas de doublon et que je peux reconstituer un en-tête artificiel minimal (le plus petit commun diviseur) pour tous les spectres soumis. L'inconvénient est que tous les mots-clés de l'en-tête ayant été remplis ne sont pas stockés ailleurs que dans l'en-tête du fichier, y compris ceux, facultatifs, qui pourraient être intéressants à extraire ou exploiter un jour ou l'autre.

2 - soit je ne stocke dans la base que les mots-clés qui ne peuvent pas être extraits en interrogeant les relations existantes (les temps de pose, les heures de prise de vues, etc.). C'est une solution bâtarde. L'avantage est que je stocke TOUS les mots-clés de l'en-tête, SAUF ceux qui peuvent être déduits des associations de la base (l'observateur, l'étoile, le site, etc.). L'inconvénient est que ça me paraît lourd à administrer ; qui sait si un mot-clé ne sera pas intégré un jour ou l'autre sous forme d'association dans la base, par exemple.

3 - soit je stocke dans la base TOUS les mots-clés de l'en-tête qui possèdent une valeur, y compris ceux qui pourraient faire doublon avec des données pouvant être extraites des associations. L'avantage est que je peux reconstituer un en-tête complet et idéal pour chaque spectre soumis (tous les champs sont correctement remplis, avec des valeurs vérifiées et cohérentes). Je peux éventuellement inciter l'observateur à remplacer l'en-tête de son fichier par celui généré par la base. L'inconvénient est que cela va créer des doublons pour les données pouvant être extraites des associations (l'observateur, l'astre ou le site, par exemple).

Malgré la redondance, je serai tenté par la 3ème solution.
J'ai essayé de modéliser cela de la façon suivante (voir dans le cadre SPECTRE) :



J'ai aussi essayé de modéliser le caractère obligatoire ou non d'un mot-clé.
La "super-classe" SPECTRE impose un certain nombre de mots-clés obligatoires ; les autres sont facultatifs et n'ont pas besoin d'être remplis pour que le spectre soit validé. La "sous-classe" SPECTRE_ECHELLE (qui est un type de spectre particulier donc héritant de SPECTRE) impose d'autres mots-clés obligatoires, en supplément.
A mon avis, j'ai sans doute mal modélisé cette situation, notamment du fait de l'héritage.

Merci par avance,
Vincent

[aras-vbo]

SQLPro,

Si cela ne tenait qu'à moi, je choisirai une solution certes plus chère mais plus sûre, sur SQL Server et basée sur FILESTREAM.
Malheureusement, je dois faire aussi avec les impératifs du projet, notamment les impératifs budgétaires. Notre groupe est informel pour l'instant et les financeurs sont des particuliers qui peuvent librement quitter le groupe. Je ne voudrais pas que quelques personnes se retrouvent avec la charge d'un serveur.

Il existe déjà une base de ce type, à laquelle nous participons en association avec l'Observatoire de Paris-Meudon : BeSS
Il s'agit de la base de données des étoiles de type Be. Elle fonctionne sous Postgresql depuis plusieurs années, sur un serveur installé à l'Observatoire de Paris et elle est interrogeable soit par des scipts PHP (le site web de consultation), soit par VO (Virtual Observatory) sous forme de web service.
La papier descriptif est là.

Si la nouvelle base est efficace, peut-être arriverons-nous à la faire héberger sur le même serveur.

Vincent

[SQLpro]

...

Il existe déjà une base de ce type, à laquelle nous participons en association avec l'Observatoire de Paris-Meudon : BeSS
Il s'agit de la base de données des étoiles de type Be. Elle fonctionne sous Postgresql depuis plusieurs années, sur un serveur installé à l'Observatoire de Paris et elle est interrogeable soit par des scipts PHP (le site web de consultation), soit par VO (Virtual Observatory) sous forme de web service.
La papier descriptif est là.

Si la nouvelle base est efficace, peut-être arriverons-nous à la faire héberger sur le même serveur.

Vincent

PostGreSQL est un choix intermédiaire pas mal du tout. Le seul inconvénient de PG est qu'il supporte difficilement un lourde charge en terme d'accès concurrentiel et mal de fortes volumétries, surtout si la base est complexe (au dela d'une dizaine de jointures dans une même requête il commence à se vautrer...).
Je ne pense pas que votre base soit complexe et que votre base nécessite un fonctionnement 24h/24. EN effet, la maintenance des bases PG s'effectue difficilement à chaud.

Quand au modèle, il me parait pas mal.

A +