Requête SQL

Cette page vous permet d’exécuter des requêtes SQL de base sur la base de données MOCA, et d’exporter les résultats au format CSV ou de les copier. Les sorties sont limitées à 10 000 lignes, et la création de tables temporaires n’est pas autorisée. Pour ce type d’usage, nous recommandons d’utiliser un clien SQL ou la librairie Python mocapy afin d’obtenir une meilleure intégration dans le code avec des dataframes pandas.

La base de données MOCA est construite en MySQL, et une vaste quantité d’aide en ligne est disponible pour en apprendre les bases. Notez que nous ne prévoyons pas de prendre en charge d’autres variantes de SQL telles qu’ADQL.

Les utilisateurs devraient d’abord se familiariser avec le schéma de la base de données afin de comprendre la liste des tables et des colonnes disponibles pour les requêtes.

Entrez Votre Requête SQL

Votre requête doit commencer par SELECT et un LIMIT y sera ajouté automatiquement. Vous pouvez contrôler l’offset avec le premier nombre et la limite avec le second nombre ; une limite maximale de 10 000 est possible. Pour des requêtes plus volumineuses, veuillez utiliser un client MySQL ou le paquet Python mocapy comme décrit ici.

LIMIT ,

Effectuer une correspondance croisée avec une liste de noms d’étoiles personnalisés est possible, mais nécessite l’utilisation de la librairie Python mocapy, et des exemples sont fournis dans la documentation de la page GitHub de mocapy.

Il existe 6 types de tables dans MOCA, commençant par les préfixes suivants :

  • moca_ : Tables répertoriant les identifiants uniques dans la base de données, tels que les objets astrophysiques, les associations jeunes ou d’autres quantités, avec leurs informations pertinentes.
  • cat_ : Catalogues externes dont toutes les colonnes ont été transférées dans MOCA, généralement seulement pour les étoiles incluses dans la base de données MOCA.
  • data_ : Tables contenant des données brutes issues de la littérature ou de catalogues astronomiques.
  • calc_ : Tables contenant des quantités intermédiaires calculées par MOCA.
  • mechanics_ : Tables générées automatiquement par MOCA en tant que produits dérivés qui ne sont pas nécessairement des calculs. Un exemple serait une liste de toutes les désignations pour une étoile donnée, ou des listes compilées des membres d’association les plus probables.
  • summary_ : Tables qui répertorient un grand nombre de propriétés pour une étoile, une jeune association, ou des listes de membres.

Le pipeline habituel de mise à jour de MOCA (effectué uniquement par l’administrateur) consiste à inclure soit de nouvelles mesures, soit de nouvelles appartenances revendiquées dans des tables commençant par data_. Des programmes automatisés iront ensuite récupérer toutes les lignes disponibles dans divers catalogues cat_, propager les mesures pertinentes des tables cat_ vers plusieurs tables data_, puis mettre à jour toutes les tables calc_, mechanics_ et summary_ pertinentes.

Il existe plusieurs noms de colonnes dans la base de données qui commencent par le préfixe moca_ ; ceux-ci indiquent généralement des clés uniques propres à la base de données MOCA. Par exemple, moca_oid (ID d’objet) est un nombre entier qui se réfère de façon unique à un seul objet astrophysique (p. ex., une étoile, une naine blanche ou une naine brune), et moca_aid (ID d’association) est une courte chaîne de caractères qui fait référence à une association. Ces colonnes sont souvent utiles pour relier des tables entre elles avec des instructions SQL JOIN.

Un grand nombre de requêtes de base peuvent être réalisées en n’utilisant que la table summary_all_members, qui contient les listes de membres les plus à jour pour chaque jeune association. Cette table peut contenir des entrées répétées pour une même étoile, lorsqu’elle peut être un membre candidat de plus d’une association. La table summary_all_objects est similaire, mais ne répertorie chaque objet astrophysique qu’une seule fois, avec sa meilleure appartenance et d’autres informations.

Un utilisateur peut, par exemple, ne lister que les membres candidats du groupe beta Pic (moca_aid=BPMG) avec plusieurs de leurs propriétés de base, en excluant les membres de faible qualité (types d’appartenance qui ne sont pas LM ou R, c.-à-d. des membres candidats à faible probabilité ou des membres rejetés), à l’aide de la requête suivante (les retours à la ligne sont facultatifs) :

SELECT *
FROM summary_all_members
WHERE moca_aid='BPMG' AND moca_mtid != 'R' AND moca_mtid != 'LM'

Des filtres de base peuvent être appliqués facilement à l’aide des colonnes disponibles dans summary_all_members, par exemple des coupures basées sur l’ascension droite (ra), la déclinaison (dec), ou les magnitudes en bande G de Gaia DR3 (gmag). Notez que toute coupure appliquée à une colonne qui contient des valeurs manquantes (NULL) rejettera automatiquement toutes les lignes avec une valeur manquante, à moins que les NULL soient explicitement autorisés, comme dans cet exemple :

SELECT *
FROM summary_all_members
WHERE moca_aid='BPMG' AND moca_mtid != 'R' AND moca_mtid != 'LM' AND (gmag >= 12 OR gmag IS NULL) AND `dec` > 0 AND (ra > 200 OR ra <20)

Notez que, dans l’exemple ci-dessus, le symbole était requis pour entourer le nom de colonne « dec » parce que ce nom est malheureusement un mot réservé en SQL. Le symbole indique qu’il s’agit d’un nom de colonne, peu importe le terme ou les symboles qu’il peut contenir.

Des contraintes basées sur les types spectraux peuvent être spécifiées à l’aide d’une comparaison LIKE (% agit alors comme un caractère générique), ou en utilisant la colonne sptn (numéro de type spectral), où 0 correspond à M0, 10 correspond à L0, et -10 correspond à K0, etc. Ces deux exemples mèneraient donc de façon similaire à la sélection de toutes les naines M de BPMG :

SELECT *
FROM summary_all_members
WHERE moca_aid='BPMG' AND moca_mtid != 'R' AND moca_mtid != 'LM' AND (spectral_type LIKE 'M%' OR spectral_type LIKE '(M%')
SELECT *
FROM summary_all_members
WHERE moca_aid='BPMG' AND moca_mtid != 'R' AND moca_mtid != 'LM' AND sptn >= 0 AND sptn < 10

Dans le premier exemple, nous devions autoriser explicitement le symbole de parenthèse (, car les types spectraux basés sur des estimations photométriques sont donnés entre parenthèses.

Des requêtes plus avancées nécessiteront que les utilisateurs se familiarisent avec les instructions JOIN ou LEFT JOIN en SQL. Notez que JOIN est équivalent à INNER JOIN, et que LEFT JOIN est équivalent à LEFT OUTER JOIN.

Un exemple qui nécessiterait une instruction JOIN serait la requête de toutes les mesures de vitesse radiale disponibles pour une étoile donnée. Dans cet exemple, nous interrogerions l’étoile AU Mic en résolvant d’abord son nom avec la table mechanics_all_designations. Cette table permet d’obtenir le moca_oid de l'étoile AU Mic, puis de joindre ses mesures de vitesses radiales via la table data_radial_velocities. Notez que la table radial_velocities contiendra de nombreuses entrées associées à AU Mic ; par conséquent, la ligne unique renvoyée par la première étape de la requête (pour résoudre le nom AU Mic) sera dupliquée autant de fois qu’il existe de vitesses radiales. Dans cet exemple, j’ai attribué des alias de table pour faciliter l’utilisation, ce que j’ai toujours tendance à faire lorsque je commence à joindre des tables entre elles :

SELECT drv.*
FROM mechanics_all_designations AS mdes
JOIN data_radial_velocities AS drv USING(moca_oid)
WHERE mdes.designation='AU Mic'

L’instruction USING permet à la base de données de savoir quelle colonne doit être utilisée pour relier les deux tables. Elle ne peut être utilisée que lorsque les deux colonnes ont le même nom, ou lorsque la correspondance est non ambiguë, mais une manière plus explicite de faire exactement la même chose serait :

SELECT drv.*
FROM mechanics_all_designations AS mdes
JOIN data_radial_velocities AS drv ON(mdes.moca_oid=drv.moca_oid)
WHERE mdes.designation='AU Mic'

De même, on peut vouloir obtenir les détails de publication pour chaque mesure de vitesse radiale, et pas seulement l’identifiant de publication propre à MOCA (moca_pid), avec un JOIN en chaîne :

SELECT drv.*, mpub.*
FROM mechanics_all_designations AS mdes
JOIN data_radial_velocities AS drv ON(mdes.moca_oid=drv.moca_oid)
JOIN moca_publications AS mpub ON(drv.moca_pid=mpub.moca_pid)
WHERE mdes.designation='AU Mic'

Cela permettrait aussi de trier la table par date de publication, par exemple des articles les plus récents aux plus anciens :

SELECT drv.*, mpub.*
FROM mechanics_all_designations AS mdes
JOIN data_radial_velocities AS drv ON(mdes.moca_oid=drv.moca_oid)
JOIN moca_publications AS mpub ON(drv.moca_pid=mpub.moca_pid)
WHERE mdes.designation='AU Mic'
ORDER BY mpub.pubdate DESC

ou les données pourraient plutôt être triées par époque de mesure :

SELECT drv.*, mpub.*
FROM mechanics_all_designations AS mdes
JOIN data_radial_velocities AS drv ON(mdes.moca_oid=drv.moca_oid)
JOIN moca_publications AS mpub ON(drv.moca_pid=mpub.moca_pid)
WHERE mdes.designation='AU Mic'
ORDER BY drv.epoch DESC

D’autres exemples de requêtes avancées sur la base de données se trouvent sur la page GitHub de mocapy.