Astronomie

Accéder au serveur SDSS SQL server via python

Accéder au serveur SDSS SQL server via python


We are searching data for your request:

Forums and discussions:
Manuals and reference books:
Data from registers:
Wait the end of the search in all databases.
Upon completion, a link will appear to access the found materials.

Existe-t-il un moyen d'accéder directement à l'un des serveurs Sloan Digital Sky Survey via SQL via Python ?

Actuellement, j'ai pu exécuter des requêtes SQL à partir du site Web qu'ils fournissent (par exemple https://skyserver.sdss.org/dr12/en/tools/search/sql.aspx), mais je ne sais pas comment je peux accéder directement depuis une interface Python.

Toutes les suggestions sur les détails de connexion que j'aurais besoin d'utiliser sont très appréciées.


Vous pouvez le faire via le module astroquery SDSS ; il existe une fonction appelée query_sql.


Connectez-vous à SQL Server avec les informations d'identification d'un autre domaine

Comment puis-je me connecter à une base de données SQL Server à l'aide d'un identifiant/mot de passe utilisateur qui se trouve dans un autre domaine ?

Si j'utilise mon compte pour me connecter à DB, ça marche bien :

Mais j'ai besoin d'utiliser les informations d'identification d'un autre utilisateur comme

Lorsque j'essaie ce dernier, j'obtiens une erreur de "connexion échouée pour MY_Domainusername" plutôt que pour l'utilisateur "Another_Domainusername".

Dans les deux cas, en exécutant SQL Server Management Studio, je peux utiliser l'authentification Windows pour me connecter à la base de données.


Dans cet exemple, vous voyez comment exécuter une instruction INSERT en toute sécurité et transmettre des paramètres. Les paramètres protègent votre application de l'injection SQL.

pyODBC utilise le pilote Microsoft ODBC pour SQL Server. Si votre version du pilote ODBC est 17.1 ou ultérieure, vous pouvez utiliser le mode interactif Azure Active Directory du pilote ODBC via pyODBC. Cette option interactive fonctionne si Python et pyODBC autorisent le pilote ODBC à afficher la boîte de dialogue. L'option n'est disponible que sur les systèmes d'exploitation Windows.

Exemple de chaîne de connexion pour l'authentification interactive Azure Active Directory

L'exemple suivant fournit une chaîne de connexion ODBC qui spécifie l'authentification interactive Azure Active Directory :

Pour plus d'informations sur les options d'authentification du pilote ODBC, consultez Utilisation d'Azure Active Directory avec le pilote ODBC.


Accéder au serveur SDSS SQL server via python - Astronomie

1. The Johns Hopkins University, 2. Microsoft, 3. Fermi National Accelerator Laboratory, Batavia, 4. CERN

Abstrait:

Le SkyServer fournit un accès Internet aux données publiques Sloan Digital Sky Survey (SDSS) pour les astronomes et pour l'enseignement des sciences. Ce document décrit les objectifs et l'architecture de SkyServer. Il décrit également notre expérience d'utilisation du SkyServer sur Internet. Les données SDSS sont publiques et bien documentées, ce qui en fait une bonne plate-forme de test pour la recherche sur les algorithmes et les performances des bases de données.

Introduction

Le SkyServer fournit un accès Internet aux données publiques Sloan Digital Sky Survey (SDSS) pour les astronomes et pour l'enseignement des sciences. Le SDSS est une étude sur 5 ans du ciel du Nord (10 000 degrés carrés) à une résolution d'environ 1/2 seconde d'arc à l'aide d'un télescope au sol moderne [[SDSS]. Il caractérisera environ 200M d'objets dans 5 bandes optiques, et mesurera les spectres d'un million d'objets. Les données de la première année sont désormais publiques.

Les données brutes recueillies par le télescope SDSS à Apache Point, au Nouveau-Mexique, sont alimentées par des pipelines de logiciels d'analyse de données au Fermilab. Les pipelines d'imagerie analysent les données de la caméra d'imagerie pour extraire environ 400 attributs pour chaque objet céleste ainsi qu'une image "découpée" en 5 couleurs. Les pipelines spectroscopiques analysent les données des spectrographes, pour extraire des spectres calibrés, des décalages vers le rouge, des raies d'absorption et d'émission, et de nombreux autres attributs. Ces pipelines incarnent une grande partie des connaissances de l'humanité en astronomie [SDSS-EDR]. Le logiciel du pipeline est une partie importante du projet SDSS : environ 25 % du coût et des efforts du projet. Le résultat est un grand catalogue de haute qualité du ciel du Nord, et d'une petite bande du ciel du Sud. Une fois terminées, les données de l'enquête occuperont environ 40 téraoctets (To) de données d'images et environ 3 To de données traitées.

Après étalonnage, la sortie du pipeline est disponible pour les astronomes du consortium SDSS. Après environ un an, le SDSS publie les données à la communauté astronomique et au public. Ainsi, en 2007, toutes les données du SDSS seront accessibles à tous et partout.

Les deux premières années de données SDSS sont désormais publiques. Les données brutes dépassent 2,5 téraoctets et la taille du catalogue est d'environ 800 Go contenant plus de 80 millions d'objets et 180 000 spectres. Vous pouvez accéder aux catalogues publics via le SkyServer sur Internet (http://skyserver.sdss.org/) ou vous pouvez obtenir une copie privée des données. Le serveur Web prend en charge à la fois les astronomes professionnels et l'accès éducatif.

Les modifications apportées aux données publiques du SDSS seront publiées au fur et à mesure que le pipeline d'analyse des données s'améliorera, et les données seront augmentées au fur et à mesure que d'autres seront rendues publiques (la prochaine publication prévue est janvier 2004, DR2). De plus, le SkyServer obtiendra une meilleure documentation et de meilleurs outils au fur et à mesure que nous apprendrons comment il est utilisé. Il existe des versions japonaise et allemande du site Web, et le serveur est mis en miroir dans de nombreuses régions du monde.

Ce document esquisse la conception de SkyServer. Il rend compte de la conception de la base de données et du site Web, décrit le pipeline de chargement des données et rend compte de l'utilisation initiale du site Web.

L'architecture du site Web

L'architecture du SkyServer est assez simple : un serveur Web IIS frontal accepte les requêtes HTTP traitées par JavaScript Active Server Pages (ASP). Ces scripts utilisent Active Data Objects (ADO) pour interroger le serveur de base de données SQL principal. SQL renvoie des jeux d'enregistrements que JavaScript formate en pages. Le site Web contient environ 40 000 lignes de JavaScript et a été créé à l'origine par deux personnes en tant qu'activité de temps libre. Depuis lors, beaucoup plus de personnes ont contribué au code et au contenu, en particulier pour la documentation et l'éducation.

Cette conception dérive du TerraServer [Barclay] - les données structurées et les images sont toutes stockées dans la base de données SQL. Une pyramide d'images à 5 niveaux des cadres est précalculée, permettant aux utilisateurs de voir un aperçu du ciel, puis de zoomer sur des zones spécifiques pour une vue rapprochée d'un objet particulier.

L'aspect le plus difficile de la conception du site Web a été de prendre en charge une interface utilisateur riche pour de nombreux navigateurs différents. La prise en charge de Netscape Navigator, Mozilla et Microsoft Internet Explorer est un défi, en particulier lorsque les nombreuses variantes Windows, Macintosh et UNIX sont prises en compte. Le SkyServer ne télécharge pas d'applets sur les clients (sauf pour sdssQA), mais il utilise à la fois des feuilles de style en cascade et du HTML dynamique. C'est une lutte permanente pour soutenir les navigateurs à mesure qu'ils évoluent.

Les astronomes professionnels ont généralement une bonne maîtrise de l'anglais, mais SkyServer prend en charge une communauté internationale d'utilisateurs comprenant des enfants et des non-scientifiques. Ainsi, la hiérarchie des pages Web se divise de trois manières : il y a une branche anglaise, une branche allemande et une branche japonaise. D'autres langues seront ajoutées par des personnes parlant couramment ces langues. Chaque site en miroir aura toutes les données et prend en charge toutes les langues.

La conception de l'interface Web

La conception graphique est entièrement basée sur des feuilles de style. Un nouveau « skin » a été conçu pour le site par le groupe multimédia de Microsoft. Seuls 4 fichiers du répertoire de niveau supérieur ont été modifiés pour obtenir les différentes impressions visuelles.

Le SkyServer est accessible via Internet à l'aide de navigateurs standard. Il accepte les requêtes pointer-cliquer pour des images du ciel, des images de spectres et pour les sorties tabulaires de la base de données SDSS. Il contient également des liens vers la littérature en ligne sur les objets (par exemple, NED, VizieR et Simbad). Le site contient une description du projet SDSS, des didacticiels sur la manière dont les données ont été collectées et ce que cela signifie, ainsi que des projets adaptés à l'enseignement ou à l'apprentissage de l'astronomie et des sciences informatiques à différents niveaux scolaires. La figure 1 présente les principaux écrans d'accès.

L'accès le plus simple et le plus populaire est un atlas de tables basses de lieux célèbres qui montre des images en couleur d'objets célestes intéressants (et souvent célèbres). Ces images tentent d'amener le spectateur vers des articles sur ces objets et lui permettent d'explorer les objets dans les données SDSS. Il existe également des outils qui permettent à l'utilisateur de naviguer par champ ou par plaque pour obtenir des images et des spectres d'objets particuliers (voir Figure 1). Pour aller plus loin, il existe un texte et une interface graphique SQL qui permet aux utilisateurs sophistiqués d'exploiter la base de données SDSS. Un schéma de panoramique et de zoom par pointer-cliquer permet aux utilisateurs de parcourir une section du ciel et de sélectionner des objets et leurs spectres (le cas échéant).

Figure 2: L'interface de navigation vous permet d'entrer un point dans le ciel pour visualiser la « découpe » de cet endroit. Ensuite, vous pouvez effectuer un zoom avant pour voir les objets de près ou en arrière pour avoir une vue d'ensemble. On peut sélectionner diverses superpositions pour fournir une représentation graphique pratique de divers objets spatiaux (champs, plaques, tuiles, rayures, masques). En pointant sur un objet, on peut obtenir un résumé de ses attributs à partir de la base de données, et on peut également explorer toutes les informations centrées sur un objet photométrique donné.

Les images en couleur du ciel ont été créées spécialement pour le site Web. Les images originales de 5 couleurs à 80 bits ont été converties à l'aide d'un mappage d'intensité non linéaire pour réduire la plage dynamique de luminosité à la qualité de l'écran. Les images aux couleurs augmentées sont RVB 24 bits, stockées au format JPEG. Une pyramide d'images a été construite à 5 niveaux de zoom différents. Les spectres sont également rendus sur des images GIF 8 bits.

Le SkyServer n'est qu'un des moyens d'accéder aux données SDSS. De plus, les fichiers bruts au niveau des pixels SDSS sont disponibles auprès de Data Archive Server (DAS) au Fermilab (http://das.sdss.org/).

Exploration de données SkyServer

L'exploration de données était notre motivation initiale dans la construction du SkyServer. Nous voulions un outil capable de répondre rapidement à des questions telles que : "trouver des lentilles gravitationnelles candidates" ou "trouver d'autres objets comme celui-ci". En effet, nous [Szalay] avons défini 20 requêtes typiques et conçu la base de données SkyServer pour répondre à ces requêtes. Un autre article décrit les requêtes et leurs performances [Gray], mais nous résumons rapidement les résultats ici.

Les requêtes correspondent aux tâches typiques que les astronomes effectueraient avec un programme C++, extrayant des données de l'archive, puis les analysant. Pouvoir énoncer des requêtes simplement et rapidement pourrait être un réel gain de productivité pour la communauté de l'Astronomie. Nous avons été très heureux de découvrir que les 20 requêtes ont des équivalents SQL assez simples. Ce n'était pas évident quand nous avons commencé. Souvent, la requête peut être exprimée sous la forme d'une seule instruction SQL. Dans certains cas, la requête est itérative, les résultats d'une requête alimentent la suivante.

La plupart des requêtes s'exécutent en quelques secondes. Certains impliquant une analyse séquentielle de la base de données prennent environ 3 minutes. Quelques jointures complexes prennent près d'une heure. Parfois, l'optimiseur SQL choisit un plan sous-optimal et une requête peut prendre plusieurs heures. Les requêtes de données spatiales sont à la fois simples à énoncer et à exécuter rapidement à l'aide d'un index spatial. Nous avons contourné une limitation dans SQL Server en précalculant les voisins de chaque objet. Même sans y être obligé, nous aurions pu créer cette vue matérialisée pour accélérer les requêtes. En général, les requêtes ont bénéficié d'indices et de sous-ensembles de colonnes contenant des champs populaires.

Traduire les requêtes en SQL nécessite une bonne compréhension de l'astronomie, une bonne compréhension de SQL et une bonne compréhension de la base de données. Les astronomes "normaux" utilisent des requêtes SQL très simples. Ils utilisent SQL pour extraire un sous-ensemble des données, puis analysent ces données sur leur propre système à l'aide de leurs propres outils. SQL, en particulier le SQL complexe impliquant des jointures et des requêtes spatiales, ne fait tout simplement pas partie de la boîte à outils d'astronomie actuelle. Cela constitue un obstacle à une utilisation plus large du SkyServer par la communauté astronomique. Nous espérons qu'un bon outil de requête visuelle qui facilite la composition de SQL résoudra ce problème.

SdssQA-L'outil de requête SDSS

sdssQA est un outil de requête SQL GUI pour aider à composer des requêtes SQL. Il a été inspiré par l'analyseur de requêtes SQL Server, mais s'exécute comme une applet Java sur les clients UNIX, Macintosh et Windows et est disponible gratuitement à partir de la page de téléchargement sdssQA . Il se connecte via ODBC/JDBC (pour une utilisation locale) et via HTTP ou SOAP pour une utilisation sur Internet.

Figure 3 : sdssQA est une applet Java du domaine public qui s'exécute sur les clients Unix, Macintosh et Windows. Il peut être utilisé pour interroger la base de données SkyServer. Le navigateur d'objets (volet supérieur gauche) obtient le schéma de base de données du serveur de manière dynamique.
sdssQA fournit à la fois un mode de requête basé sur du texte et sur un diagramme. En mode texte, l'utilisateur compose et exécute des requêtes SQL, des procédures stockées ou des fonctions. La fenêtre de requête basée sur du texte est illustrée à gauche de la figure 3.

sdssQA construit un navigateur d'objets hiérarchique de la base de données, des tables, des vues, des fonctions et des constantes dans le volet gauche du catalogue de la base de données (voir Figure 3). Cliquer sur le nom de l'objet fait apparaître une fenêtre d'aide qui indique à l'utilisateur la signification de chaque objet et champ à l'intérieur. Les métadonnées incluent les types de données, les longueurs et les indicateurs nuls.

  • Basé sur la grille, pour une visualisation rapide des résultats,
  • CSV, dans des valeurs ASCII séparées par des virgules, à utiliser dans des feuilles de calcul, etc., et
  • XML, à utiliser dans toute application capable de lire des données XML.

Les statistiques d'exécution des requêtes sont vitales pour les grands ensembles de résultats. La fenêtre d'état affiche le temps d'exécution de chaque requête, arrondi à la seconde la plus proche. Il affiche également les informations de connexion de l'utilisateur, le nom du catalogue et le nom du serveur. Le serveur Web public SkyServer limite les requêtes à 10 000 enregistrements ou 5 minutes de calcul. Pour les requêtes plus exigeantes, les utilisateurs doivent se rattacher à un SkyServer "privé".

Pour une aide plus détaillée sur l'utilisation de sdssQA, les utilisateurs peuvent se référer à la page d'aide sdssQA et à la page d'aide SQL.

SkyServer utilisé pour l'éducation

L'accès public à de vraies données astronomiques et les interfaces Web de SkyServer en font une ressource potentielle énorme pour l'enseignement des sciences et la sensibilisation du public. Aujourd'hui, la plupart des étudiants apprennent l'astronomie à travers des exercices manuels qui utilisent des données artificielles ou des données prises il y a des siècles. Avec SkyServer, les étudiants peuvent étudier des données de galaxies jamais vues auparavant par des yeux humains. Nous concevons plusieurs projets éducatifs interactifs qui permettent aux étudiants d'utiliser SkyServer pour apprendre des concepts de l'astronomie et de la science informatique.

Figure 4 : Un exemple du projet « Old Time Astronomy » compare le croquis de la galaxie M64 réalisé par l'astronome amateur Michael Geldorp (à gauche) à l'image de la même galaxie du Digitized Sky Survey (à droite). Un projet plus avancé demande aux élèves de tracer un diagramme de Hubble à droite (montrant le décalage vers le rouge et la distance relative de neuf galaxies) pour « découvrir » l'expansion de l'univers.
Nous ciblons les projets sur deux publics : premièrement, les étudiants brillants passionnés par l'astronomie qui souhaitent travailler avec des données de manière indépendante, et deuxièmement, les étudiants suivant des cours d'astronomie générale ou d'autres sciences dans le cadre d'un programme scolaire. Pour accommoder les deux publics, nous proposons plusieurs niveaux de projets différents, de « Pour les enfants » (projets pour les élèves du primaire) aux « Défis » (projets conçus pour étirer les étudiants brillants de premier cycle). Tous les projets conçus pour être utilisés dans les écoles incluent un site pour enseignants protégé par mot de passe avec des solutions, des conseils sur la façon de diriger des classes à travers des projets et des corrélations avec les normes nationales d'éducation [Projet 2061].

Par exemple, un projet pour enfants, « Old Time Astronomy » (http://skyserver.sdss.org/en/proj/kids/oldtime/) demande aux élèves d'imaginer à quoi ressemblait l'astronomie avant l'invention de l'appareil photo, lorsque les astronomes a dû enregistrer des données à travers des croquis. Le projet montre des images SDSS d'étoiles et de galaxies, puis demande aux élèves de dessiner ce qu'ils voient. Une fois qu'un élève a esquissé l'image, elle échange avec un autre élève pour voir si l'autre élève peut deviner quelle image a été esquissée (voir la figure 4.)

Un projet pour les étudiants de niveau avancé du secondaire et les étudiants de premier cycle explore l'univers en expansion. Le site Web donne d'abord aux étudiants une lecture de base sur la façon dont les scientifiques savent que l'univers est en expansion. Ensuite, il permet aux élèves de découvrir l'expansion par eux-mêmes en faisant un diagramme de Hubble - un tracé des vitesses (ou décalages vers le rouge) des galaxies lointaines en fonction de leurs distances par rapport à la Terre. Un exemple de diagramme de Hubble d'étudiant est illustré à la figure 4. Entre autres choses, cela enseigne aux étudiants comment travailler avec des données réelles.

De nombreux autres exercices et projets sont en cours de développement autour du SkyServer. L'une d'entre elles a été particulièrement réussie par un enseignant et des étudiants au Mexique. Il existe un intérêt international croissant pour l'utilisation du SDSS pour enseigner les sciences aux étudiants dans leur langue maternelle (l'espagnol dans ce cas).

Trafic du site

Figure 5a : Au cours de ses 4 premiers mois, le SkyServer a traité environ 2 millions de pages consultées, environ un million de pages et environ trente mille sessions.

Le SkyServer fonctionne depuis le 5 juin 2001. Au cours des 4 premiers mois, il a servi environ deux millions de visites, 700 000 pages vues via 50 000 sessions. Environ 4 % d'entre eux sont destinés au sous-web japonais et 3 % au sous-web allemand. Les projets éducatifs ont obtenu environ 8% du trafic : environ 250 pages vues par jour. Il y a eu 11 redémarrages, 8 à pour des mises à niveau logicielles et 3 associés à une panne de courant. Les patchs provoquent des coupures de 5 minutes, les coupures de courant et de fonctionnement durent plusieurs heures. Ne figurent pas dans les statistiques, mais sont clairement visibles sur la figure 5a, deux pannes ou surcharges de réseau qui ont affecté le Fermilab les 22 juin et 26 juillet 2001. A l'inverse, le pic de trafic a coïncidé avec des cours utilisant le site, des articles de presse le mentionnant ou avec des manifestations aux conférences d'astronomie. L'utilisation soutenue est d'environ 400 personnes accédant à environ 3 000 pages par jour. Le site est configuré pour gérer une charge 100 fois plus importante que cela. Environ 30 % du trafic provient d'autres sites « explorant » le SkyServer – extrayant les données et les images. Il y a environ 10 « attaques de pirates » par jour.

Figure 5b : Trafic mensuel de SkyServer depuis son introduction en 6/2001. Le nombre total de visites en septembre 2003 dépassait les 15 millions de visites.

Depuis son introduction en juin 2001, le trafic sur le site SkyServer n'a cessé d'augmenter. La figure 5b montre le trafic mensuel depuis juin 2001. Le nombre total de hits au cours des 2 ans et 3 mois de service du SkyServer dépasse désormais les 15 millions de hits. Au cours de cette période, à l'exception des pannes de courant à l'échelle du site, il a bénéficié d'une disponibilité de plus de 99,9 %. Le dernier rapport de trafic actualisé peut être consulté sur la page Trafic actuel du site.

Le SkyServer est principalement administré à partir de Johns Hopkins et de San Francisco à l'aide de la fonction de système Windows à distance (Terminal Services Client). Pendant les deux premières années, le personnel du Fermilab a géré le matériel physique, le réseau et la sécurité du site, avec un serveur miroir à Johns Hopkins pour le développement et les tests incrémentiels.Depuis août 2003, l'administration et le site principal ont été transférés à l'Université Johns Hopkins et un site miroir sera hébergé au Laboratoire Fermi. Des sites miroirs supplémentaires sont également hébergés en Allemagne (Max-Planck Institute, Garching), au Japon et en Inde (IUCAA).

Les données et bases de données du Sloan Digital Sky Survey

Le pipeline de traitement SDSS du Laboratoire Fermi examine les images en 5 couleurs du télescope et identifie les objets photo comme des étoiles, des galaxies, des traînées (rayons cosmique, satellite, ) ou un défaut. La classification est probabiliste, c'est-à-dire qu'il est parfois difficile de distinguer une étoile faible d'une petite galaxie lointaine et faible. En plus de la classification de base, le pipeline extrait environ 400 attributs d'un objet, y compris une "découpe" des pixels de l'objet dans les 5 bandes de couleurs.

Figure 6 : L'enquête fusionne deux observations (deux bandes de deux nuits) en une bande. La bande est traitée par le pipeline pour produire les images et les objets photo.
Les observations réelles sont prises en bandes d'environ 2,5° de large et 120° de long (voir Figure 6). Pour compliquer encore les choses, ces bandes sont en fait la mosaïque de deux observations nocturnes (deux bandes) avec environ 10 % de chevauchement. Les rayures elles-mêmes ont des chevauchements près de l'horizon. Par conséquent, environ 11% des objets apparaissent plus d'une fois dans le pipeline. Le pipeline sélectionne une instance d'objet comme instance principale, mais toutes les instances sont enregistrées dans la base de données. Encore plus difficile, une étoile ou une galaxie en chevauche souvent une autre, ou une étoile fait partie d'un amas. Dans ces cas, les objets enfants sont dissociés de l'objet parent, et chaque enfant apparaît également dans la base de données (les parents dissociés ne sont jamais primaires.) Au final, environ 80% des objets photo sont primaires.

Les objets photographiques ont des attributs de position - ascension droite et déclinaison dans le système de coordonnées J2000, également représentés comme les composants cartésiens d'un vecteur unitaire, et un index dans un maillage triangulaire hiérarchique (HTM). Ils ont également une luminosité stockée en unités logarithmiques (magnitudes) avec des barres d'erreur dans chacune des cinq bandes de couleur. Ces grandeurs sont mesurées de six manières différentes (pour un total de 60 attributs). Le pipeline de traitement d'image mesure également l'étendue de chaque galaxie de plusieurs manières dans chacune des 5 bandes de couleurs avec des estimations d'erreur. Le pipeline attribue une centaine de propriétés supplémentaires à chaque objet - ces attributs sont appelés drapeaux, statut et type et sont codés sous forme de drapeaux binaires.

Le pipeline corrèle chaque objet avec des objets d'autres catalogues : United States Naval Observatory [USNO], Rüntgen Satellite [ROSAT], Faint Images of the Radio Sky at Twenty-centimeters [FIRST], et d'autres. Les corrélations réussies sont enregistrées dans un ensemble de tables de relations. Les spectrogrammes sont le deuxième type de produit de données principal produit par le Sloan Digital Sky Survey. Environ 600 spectres sont observés à la fois en utilisant une seule plaque avec des fibres optiques allant vers différents CCD. Le traitement pipeline extrait généralement environ 30 raies spectrales de chaque spectrogramme et estime soigneusement le décalage vers le rouge de l'objet.

Pour plus d'informations sur le traitement des données, consultez la branche SDSS de ce site Web.

La conception de la base de données relationnelle

A l'origine, le SDSS a développé l'intégralité de la base de données sur ObjectivityDB [SDSS-Science Archive]. Les concepteurs ont largement utilisé les sous-classes : par exemple, le PhotoObject a des sous-classes Star et Galaxy. ObjectivityDB prend en charge les tableaux afin que les 5 couleurs soient naturellement mappées sur des vecteurs de 5 valeurs. Les connexions aux parents, aux enfants, aux spectres et à d'autres enquêtes ont été représentées comme des références d'objets. Traduire la conception orientée objet en un schéma relationnel n'était pas simple, mais nous voulions préserver autant que possible la conception originale afin de préserver les connaissances, les compétences et la documentation existantes.

Le langage de base de données relationnelle SQL ne prend pas en charge les pointeurs, les tableaux ou les sous-classes - c'est un modèle de données beaucoup plus simple. C'est à la fois une force et un handicap. Nous avons abordé la conception de la base de données SQL en utilisant des vues pour le sous-classement et en utilisant des clés étrangères pour les relations.

Étant donné que le logiciel de traitement des données a subi des changements substantiels depuis le début de l'enquête, nous stockons deux versions différentes de nos images traitées. Dans un premier temps, nous stockons la version des données traitées figée au moment où les cibles pour les observations spectroscopiques ont été sélectionnées. Cette base de données est appelée TARGDR1, où DR1 désigne le numéro de version : Data Release 1.

Ensuite, les données ont été traitées avec la meilleure version disponible du logiciel, et ces objets sont stockés dans la base de données BESTDR1. Le schéma des deux bases de données est identique et de nombreux objets apparaissent dans les deux, mais en raison d'une meilleure gestion du bruit, le nombre d'objets dans BESTDR1 est un peu plus élevé.

Le SkyServer a initialement adopté une approche simple de la conception de bases de données - et depuis que cela a fonctionné, nous nous sommes arrêtés là. La conception compte sur le moteur de stockage SQL et l'optimiseur de requêtes pour prendre toutes les décisions intelligentes concernant la disposition des données et l'accès aux données. La quantité totale de données dans les deux bases de données est de 818 Go et le nombre total de lignes dépasse 3,4 milliards.

Le schéma de la base de données

Il y a trois zones principales du schéma, qui sont liées entre elles. Les observations photométriques donnent lieu à un ensemble de tableaux qui décrivent les quelque 80 millions d'objets détectés dans nos images en 5 couleurs. Ceux-ci sont utilisés pour sélectionner des cibles pour le suivi spectroscopique. Les détails de la sélection de la cible et les observations spétroscopiques sont affichés en bas, dans la zone bleue.
Figure 7a : Le schéma de la base de données pour le SDSS Data Release 1. Les objets photométriques comme les étoiles et les galaxies sont affichés sur le côté droit, dans les limites de l'orage. Le schéma de flocon de neige spectroscopique est montré sur la gauche, dans la limite verte. Les métadonnées pertinentes, la documentation automatisée, les partitions et les index-maps sont affichés en bas, dans la limite bleue.

Objets photographiques

En commençant par les données d'imagerie, la table PhotoObj possède tous les attributs des étoiles et des galaxies. Les 5 tableaux d'attributs de couleur et les tableaux d'erreurs sont représentés par leurs noms (u, g, r, i, z.) Par exemple, ModelMag_r est le nom de la magnitude "rouge" telle que mesurée par le meilleur modèle adapté aux données. Dans les cas où les noms n'étaient pas naturels (par exemple dans le tableau de profil), les données sont encapsulées par des fonctions d'accès qui extraient les éléments du tableau d'un blob. Les pointeurs et les relations sont représentés par des "clés étrangères".

Les vues sont utilisées pour le sous-classement. Les primaryObjects, les galaxies et les étoiles, les sous-classes de la classe PhotoObj sont définies comme les vues PrimaryObjects, Stars et Galaxies de la table de base PhotoObj (les vues sont des tables virtuelles qui se traduisent simplement en requêtes sur la table de base).

Figure 7b : Le schéma des objets photographiques. Les observations sont traitées dans des champs. Chaque champ contient à son tour plusieurs objets. Les objets ont un image et un profil tableau, donnant la luminosité en anneaux concentriques autour de l'objet. Corrélations avec d'autres enquêtes (Rosat, First, USNO, ). Pour les objets observés plusieurs fois, une table de correspondance est créée. Près de voisins sont précalculés. sont enregistrés.
Le résultat est un schéma en flocon de neige avec la table PhotoObjAll au centre d'autres tables regroupées autour (Figure 7). Les 80 millions d'enregistrements PhotoObj ont chacun environ 470 attributs décrivant l'objet - environ 2 Ko par enregistrement. La table Champ décrit le traitement qui a été utilisé pour tous les objets de ce champ, dans toutes les trames. Les autres tables connectent le photoObj aux littéraux (par exemple, flags & fPhotoFlags('primary')), ou connectent l'objet à des objets dans d'autres enquêtes. Une table, les voisins, est calculée après le chargement des données. Pour chaque objet, la table des voisins contient une liste de tous les autres objets à moins d'une demi-minute d'arc de l'objet (généralement 10 objets). Cela accélère les recherches de proximité.

Objets spectroscopiques

Les spectres sont le deuxième type d'objet de données produit par le Sloan Digital Sky Survey. Au total, 640 spectres sont observés à la fois en utilisant une seule plaque avec des fibres optiques allant vers deux spectrographes différents. La description de la plaque est stockée dans la table des plaques et la description du spectrogramme est stockée dans la table specObj (chaque spectrogramme est associé à une belle image GIF.). Le traitement pipeline extrait généralement environ 30 raies spectrales de chaque spectrogramme. Les raies spectrales sont stockées dans la table SpecLine. La table SpecLineIndex contient des quantités dérivées de l'analyse des groupes de lignes. Ces quantités sont utilisées par les astronomes pour caractériser les types et les âges des objets astronomiques. Chaque ligne est corrélée avec un modèle et corrigée du redshift. Les attributs résultants sont stockés dans la table xcRedShift. Un décalage vers le rouge distinct est dérivé en utilisant uniquement des raies d'émission. Ces quantités sont stockées dans la table elRedShift. Encore une fois, comme c'est le cas avec les conceptions de bases de données relationnelles, toutes ces tables sont intégrées à des clés étrangères - chaque objet specObj a une clé specObjID unique, et cette même valeur de clé est stockée dans le cadre de la clé de chaque raie spectrale associée. Pour trouver toutes les raies spectrales de l'objet 512 on écrit la requête

Les tables spectrographiques forment également un schéma en flocon de neige qui donne des noms pour les différents drapeaux et types de lignes. Les clés étrangères connectent les tables PhotoObj et SpecObj si un objet photo a un spectrogramme mesuré.

Figure 7c : Le schéma des objets spectroscopiques. Chaque assiette produit environ 640 spectres qui à leur tour ont chacun environ 30 spectres lignes. Les raies sont ensuite analysées (line-index) et liées aux objets spectro. Les cibles sont sélectionnées automatiquement à partir de la photométrie, puis elles sont affectées à carrelage, et assiettes sont conçus.

Tableaux de métadonnées

Il existe également un ensemble de tableaux « divers » utilisés pour documenter les données, pour capturer l'historique du processus de chargement des données et pour prendre en charge l'interface Web.

La documentation est générée automatiquement à partir du schéma de la base de données. Pour chaque tableau et ligne, il y a une description sur une ligne. Pour chaque attribut, nous spécifions également une unité physique et un descripteur de contenu universel (UCD). Pour les quantités énumérées, nous fournissons un lien vers une liste des énumérations. Nous avons également des liens facultatifs vers des éléments d'un glossaire et des tables d'algorithmes, tous stockés dans la base de données.

7d : Schéma des tables de métadonnées.

Accès à la base de données - Vues, ​​index et fonctions d'accès

  • PhotoPrimary : photoObj avec mode=1
  • Étoiles : PhotoPrimary avec type='star'
  • Galaxies : PrimaryObjects avec type='galaxy'

La plupart des utilisateurs travailleront en fonction de ces tables plutôt que de la table de base. En fait, la plupart des requêtes sont formulées en fonction de ces vues. C'est l'équivalent du sous-classement. L'optimiseur de requêtes SQL réécrit ces requêtes afin qu'elles correspondent à la table photoObj de base avec les qualificatifs supplémentaires.

Pour accélérer l'accès, la table photoObj est fortement indexée (ces index profitent également aux vues). Nous avons également créé une tranche de données verticale, appelée PhotoTag, qui contient les attributs d'objet les plus fréquemment consultés. Cette table de balises est environ sept fois plus petite que la table de base (quelques centaines d'octets plutôt que quelques milliers d'octets).

Notre préoccupation concernant la conception de la table de balises est que les utilisateurs doivent savoir quels attributs se trouvent dans une table de balises et doivent savoir si leur requête est couverte par les champs de la table de balises. Les indices sont une alternative intéressante aux tableaux de balises. Un index sur les champs A, B et C donne une table de balises gérée automatiquement sur ces 3 attributs plus la clé primaire et l'optimiseur de requête SQL utilise automatiquement cet index si la requête est couverte par (contient) uniquement ces 3 champs. Ainsi, les index jouent le rôle de tables de balises et réduisent la charge intellectuelle de l'utilisateur. En plus de fournir un sous-ensemble de colonnes, accélérant ainsi l'accès de dix à cent fois, les index regroupent également les données de sorte que les recherches soient limitées à une seule partie de l'espace objet. Le regroupement peut être par type (étoile, galaxie), ou espace, ou magnitude, ou tout autre attribut. Une limitation est que SQL Server 2000 de Microsoft limite les index à 16 colonnes.

Aujourd'hui, la base de données SkyServer compte des dizaines d'indices, et d'autres seront ajoutés au besoin. Ce qui est bien avec les index, c'est que lorsqu'ils sont ajoutés, ils accélèrent toutes les requêtes qui peuvent les utiliser. L'inconvénient est qu'ils ralentissent le processus d'insertion des données, mais jusqu'à présent, cela n'a pas posé de problème. Environ 30% de l'espace de stockage SkyServer est consacré aux indices.

En plus des index, la conception de la base de données comprend un ensemble assez complet de déclarations de clés étrangères pour s'assurer que chaque profil a un objet, chaque objet se trouve dans un champ valide, et ainsi de suite. Nous insistons également sur le fait que tous les champs sont non nuls. Ces contraintes d'intégrité sont des outils précieux pour détecter les erreurs lors du chargement et elles aident les outils qui naviguent automatiquement dans la base de données.

SQL Server permet l'utilisation de fonctions table. Ceux-ci ont été largement utilisés dans notre conception, en partie pour fournir un accès facile aux valeurs énumérées et au niveau du bit, en partie pour aider au rendu et à la recherche de la documentation automatisée. De plus, les méthodes de recherche spatiale sont basées sur ces fonctions.

Accès aux données spatiales

Les scientifiques du SDSS s'intéressent particulièrement au regroupement galactique et à la structure à grande échelle de l'univers. De plus, l'interface Web demande régulièrement tous les objets dans une certaine zone rectangulaire ou circulaire de la sphère céleste.

Le SkyServer utilise trois systèmes de coordonnées différents. La première ascension droite et la déclinaison (comparable à la latitude-longitude en coordonnées terrestres) sont omniprésentes en astronomie. Le vecteur unitaire (x,y,z) en coordonnées J2000 est stocké pour accélérer les calculs d'angle d'arc. Le produit scalaire et la différence cartésienne de deux vecteurs sont des moyens rapides de déterminer l'angle d'arc ou la distance entre eux.

Pour que les requêtes de zone spatiale s'exécutent rapidement, le code de maillage triangulaire hiérarchique (HTM) de Johns Hopkins HTM, [Kunszt1] a été ajouté à SQL Server. Brièvement, HTM inscrit la sphère céleste dans un octaèdre et projette chaque point céleste sur la surface de l'octaèdre. Cette projection est approximativement iso-aire.

Figure 8a : Un maillage triangulaire hiérarchique (HTM) est une subdivision hiérarchique du ciel, à partir d'un octaèdre. Les côtés des triangles sont toujours des segments de grand cercle. Sur la figure, les triangles sont rendus plats.

HTM divise la sphère en 8 faces d'un octaèdre. Il décompose ensuite hiérarchiquement chaque face avec une séquence récursive de triangles de sorte que chaque niveau de la récursivité divise chaque triangle en 4 sous-triangles (Figure 8a et 8b). SDSS utilise un HTM d'une profondeur de 20 afin que les triangles individuels soient inférieurs à 0,1 seconde d'arc sur un côté. Ainsi, l'ID HTM pour un point très proche du pôle nord (en coordonnées galactiques) serait quelque chose comme 3,0, .,0. Il existe des routines de base pour convertir entre les coordonnées (ra, dec) et HTM.

Figure 8b : Un maillage triangulaire hiérarchique (HTM) attribue récursivement un numéro à chaque point de la sphère. La plupart des requêtes spatiales utilisent l'index HTM pour limiter les recherches à un petit ensemble de triangles. Un index HTM est construit comme une extension des arbres B de SQL Server.

Ces identifiants HTM sont codés sous forme d'entiers 64 bits. Il est important de noter que tous les identifiants HTM du triangle 6,1,2,2 ont des identifiants HTM compris entre 6,1,2,2 et 6,1,2,3. Ainsi, lorsque les identifiants HTM sont mappés dans un index B-tree, ils fournissent un index rapide pour tous les objets d'un triangle donné. La bibliothèque HTM est une procédure stockée étendue SQL enveloppée dans une fonction table spHTM_Cover(<area>). La <area> peut être soit un cercle (ra, déc, rayon), un demi-espace (l'intersection de plans), soit un polygone défini par une séquence de points. La fonction renvoie un tableau, chaque ligne définissant le début et la fin d'un triangle HTM. On peut joindre cette table à la table PhotoObj pour obtenir un sous-ensemble spatial d'objets photo.

La fonction spHTM_Cover() est trop primitive pour la plupart des utilisateurs, ils veulent en fait les objets à proximité d'un certain objet, ou ils veulent tous les objets dans une certaine zone. Ainsi, des fonctions plus simples sont également prises en charge. Par exemple : fGetNearestObjEq(1,1,1) renvoie l'objet le plus proche à moins d'une minute d'arc de la coordonnée équatoriale (1 , 1 ). Ces procédures sont fréquemment utilisées dans les requêtes et dans les pages d'accès au site Web.

Conception physique de la base de données

Les tables de données sont toutes créées dans plusieurs groupes de fichiers. Les fichiers de base de données sont répartis sur un seul volume RAID0. Chaque groupe de fichiers contient plusieurs fichiers de base de données limités à environ 50 Go chacun. Les fichiers journaux et la base de données temporaire sont également répartis sur ces disques. SQL Server répartit les tables sur tous ces fichiers et donc sur tous ces disques. Il détecte l'accès séquentiel, crée les threads de prélecture parallèles et utilise plusieurs processeurs pour analyser les données aussi rapidement que les disques peuvent les produire. Lors de la lecture ou de l'écriture, cela donne automatiquement la somme des bandes passantes du disque (plus de 400 Mbps en crête, 180 Mbps en général) sans aucune programmation utilisateur spéciale.

Au-delà de cette segmentation de groupe de fichiers, SkyServer utilise toutes les valeurs par défaut de SQL Server. Il n'y a pas de réglage particulier. C'est la marque de fabrique de SQL Server - le système vise à n'avoir "pas de boutons" afin que les performances prêtes à l'emploi soient assez bonnes. Le SkyServer est un témoignage de cet objectif.

Processus de chargement de la base de données

Le SkyServer est un entrepôt de données : les nouvelles données sont ajoutées par lots, mais la plupart du temps, les données sont interrogées. Bien sûr, ces requêtes créent des résultats intermédiaires et peuvent déposer leurs réponses dans des tables temporaires, mais la grande majorité des données est en lecture seule. Occasionnellement, un nouveau schéma est chargé (nous sommes actuellement en V4).

Figure 10 : Une capture d'écran de l'interface du chargeur de base de données SkyServer. Le SkyServer fonctionne via Internet à l'aide de Windows2000 Terminal Server, une fonction de bureau à distance intégrée au système d'exploitation et un ensemble de pages ASP. Le chargement et la maintenance du logiciel sont effectués de cette manière. Cette capture d'écran montre certaines des fenêtres de l'interface Web de contrôle de charge.

Du point de vue de l'administrateur SkyServer, la tâche principale est le chargement des données, ce qui inclut la validation des données. Lorsque de nouveaux objets photo ou spectres sortent du pipeline, ils doivent être ajoutés à la base de données. Compte tenu des grandes quantités de données, nous voulions que ce processus de chargement soit aussi automatique que possible.

L'ensemble du processus de chargement est bien décrit par un simple diagramme de flux de travail. Le flux de travail est représenté sous la forme d'un graphique acyclique dirigé (DAG) et stocké dans une table de base de données relationnelle. Cette table pilote tout le processus de chargement. Compte tenu de la grande quantité de données, la plupart de nos efforts ont été consacrés à la conception et à la mise en œuvre de divers contrôles d'intégrité.

Nous avons mis en place un système de messagerie et de journalisation à trois niveaux, le flux de travail est suivi à trois niveaux de granularité différents : tâches, étapes et phases. Il existe un script SQL pour chaque étape de chargement.En plus de charger les données, ces scripts écrivent les enregistrements du journal dans une table enregistrant le temps de chargement, le nombre d'enregistrements dans le fichier source et le nombre d'enregistrements insérés. Une interface utilisateur Web simple affiche l'état du processus de chargement et facilite l'examen des enregistrements du journal.

Une étape de chargement particulière peut échouer parce que les données violent les contraintes de clé étrangère ou parce que les données ne sont pas valides (violent les contraintes d'intégrité). Dans l'interface Web, aide l'opérateur à (1) annuler l'étape de chargement, (2) diagnostiquer et corriger les données problème, et (3) réexécuter le chargement sur les données corrigées. Le chargement s'exécute à environ 15 Go par heure (la conversion des données est très gourmande en processeur), donc les données SkyServer actuelles sont chargées en quelques jours.

Notre infrastructure de chargement est conçue pour effectuer la plupart des étapes en parallèle, sur un cluster de nœuds SQL Server, à l'aide de transactions distribuées. Cela ajoute une vitesse et une évolutivité substantielles au chargement. Nous avons utilisé jusqu'à six machines pour le chargement de l'ensemble de données DR1. Le chargement est un chargement en deux phases : nous chargeons d'abord les données dans les bases de données de tâches, ne dépassant pas 20-30 Go chacune. Là, les données sont entièrement validées avant d'être publiées vers leur destination finale dans la base de données de publication.

  1. Transformer
    Les fichiers binaires produits par les pipelines de données sont convertis en fichiers ASCII (csv) séparés par des virgules. Les images FITS sont converties en JPEG à différents niveaux de zoom.
  2. Exportation
    L'emplacement d'une arborescence de répertoires contenant des données chargeables est entré dans la base de données via une interface Web. Un nouvel enregistrement de tâche est créé dans la base de données du journal.
  3. Vérifier
    Les fichiers de l'arborescence des répertoires sont comparés à un simple fichier journal dans chacun des sous-répertoires. La liste des fichiers à charger est insérée dans la base de données du journal. La taille de la tâche est estimée et saisie dans l'enregistrement de la tâche.
  4. Construire
    Une base de données distincte est créée pour chaque tâche avec la taille appropriée. Le schéma est chargé et le fichier des informations de journal est créé.
  5. Précharger
    Chaque fichier de la base de données du journal qui appartient à la tâche est chargé. Les fichiers CSV sont chargés à l'aide d'une insertion en bloc, et les images JPG et GIF sont chargées à l'aide d'un petit package DTS. Quelques valeurs, comme loadversion, sont définies dans les colonnes chargées.
  6. Valider
    Un "nettoyage des données" très poussé est effectué. Tout d'abord, chaque clé unique est vérifiée pour être unique. Ensuite, la validité de chaque clé étrangère est vérifiée. Enfin, nous effectuons diverses sommes de contrôle et décomptes dans la base de données pour vérifier que tout a été correctement chargé.
  7. Sauvegarde
    Chaque base de données de tâches est sauvegardée sur un serveur de stockage en arrière-plan. Ensuite, la base de données est détachée avant d'être publiée.
  8. Publier
    Le serveur contenant la base de données dans laquelle publier attache la base de données de tâches et la fusionne avec le contenu actuel de la base de données de publication. Le nombre de lignes chargées est vérifié.
  9. Nettoyer
    La base de données des tâches est supprimée du système afin de libérer de l'espace pour d'autres tâches de chargement.
  10. Finir
    Les clés étrangères et primaires restantes sont construites, ainsi que les indices restants. Nous précalculons les tables Neighbors et Match, puis déterminons les limites physiques correspondant aux tâches, et leurs intersections.

Conception et performances matérielles

Le SDSS DR1 fait environ 900 Go. Bien que cela puisse être exécuté sur un système à processeur unique avec des disques ATA bas de gamme, le SkyServer de JHU fonctionne sur un matériel plus performant, soutenu par une subvention de Microsoft Research.

Illustration 11 : La configuration matérielle du cluster SkyServer, composée d'un serveur Web à trois voies à charge équilibrée, d'un cluster de serveurs de base de données triplement redondant et d'un serveur db dédié à la journalisation. Les serveurs de base de données sont sur un réseau privé.

L'interface Web se compose de trois serveurs Dell Poweredge 1750 à double processeur, exécutant Windows Server 2003, IIS 6.0 et Microsoft Network Load Balancing. Ils disposent de 2 Go de mémoire, de deux ports Ethernet Gbit et de deux disques SCSI Ultra320 de 36 Go, fonctionnant dans une configuration Windows SW RAID1 (miroir).

La plupart des requêtes d'exploration de données sont liées aux E/S, les serveurs de base de données sont donc configurés pour offrir une bande passante de disque séquentielle rapide, une puissance CPU saine et une haute disponibilité. Le backend se compose de trois serveurs de base de données Dell 4600, exécutant Windows Server 2003 et SQL Server 2000. Chacun de ces serveurs possède 1,2 téraoctet de disques Ultra SCSI à 10 000 tr/min, répartis entre les contrôleurs, 4 disques sur un canal SCSI. Les serveurs ont 4 Go de mémoire chacun. Cette configuration peut analyser les données à 400 Mbit/s pour une simple requête. Dans un cas typique de multi-utilisateurs, les requêtes ont tendance à s'exécuter à 160-200 Mbps.

Les serveurs de base de données communiquent via Gbit Ethernet, forment un réseau privé et se connectent aux ports Ethernet principaux des serveurs Web. L'un des trois serveurs DB est dédié aux requêtes courtes sur le site public, les deux autres serveurs sont dédiés aux requêtes plus longues pour les utilisateurs enregistrés, mais servent également de sauvegarde pour les basculements.

Une grande partie du développement et de l'organisation des données s'est déroulée sur un serveur Itanium2 HP RX5670 avec 24 Go de mémoire et 3 To de disques SCSI, offerts par HP et Intel. Nous avons également un serveur de base de données distinct, un Dell 4400, exécutant la même configuration logicielle, qui dispose de 3 volumes en miroir de 18 Go utilisés pour diverses bases de données de journaux, liés aux journaux Web et aux journaux SQL.

MonSkyServer

Un sous-ensemble de 1% de la base de données SkyServer (environ 1,3 Go de base de données SQL Server) peut tenir (cpompressed) sur un CD ou être téléchargé sur le Web. Cela inclut le site Web et tous les objets photo et spectrographiques dans un carré de 6° du ciel. Ce SkyServer personnel s'adapte aux ordinateurs portables et de bureau. Il est utile pour expérimenter des requêtes, pour développer le site Web et pour faire des démonstrations. Essentiellement, n'importe quelle salle de classe peut avoir un mini-SkyServer par élève.

Résumé et prochaines étapes

Le SkyServer est un site Web et une base de données SQL de 900 Go contenant les données Sloan Digital Sky Survey Data Release 1 (environ 80 millions d'objets célestes et 200 000 spectres). Il est accessible sur Internet via un site Web qui fournit un accès pointer-cliquer ainsi que plusieurs interfaces de requête, notamment des rapports basés sur des formulaires, des requêtes SQL brutes et un générateur de requêtes GUI.

Nous avons conçu le SkyServer à la fois comme un site Web pour un accès public facile et comme un site d'exploration de données. Pour tester les capacités d'exploration de données, nous avons mis en œuvre 20 requêtes astronomiques complexes et évalué leurs performances. Nous sommes satisfaits de la prestation. D'autres peuvent cloner le serveur pour quelques milliers de dollars. Les données et le serveur Web sont également reproduits dans divers instituts d'astronomie et d'informatique pour explorer les données ou expérimenter de meilleures façons d'analyser et de visualiser les données.

Les outils décrits ici sont une étape modeste vers l'objectif de fournir d'excellents outils d'analyse et de visualisation des données. Nous espérons que le SkyServer permettra aux informaticiens de faire progresser ce domaine en construisant de meilleurs outils. Le SkyServer a maintenant quatre branches évolutives principales :

SkyServer public : De nouvelles versions des données SDSS seront publiées une ou deux fois par an au fur et à mesure que le pipeline d'analyse des données s'améliorera, et les données seront augmentées à mesure que d'autres deviennent publiques. De plus, le SkyServer obtiendra une meilleure documentation et de meilleurs outils à mesure que nous acquerrons une plus grande expérience de son utilisation. Il existe des clones japonais et allemands du site Web, et il est prévu de le cloner sur plusieurs autres sites. Un serveur de base coûte moins de dix mille dollars.

Observatoire Virtuel (VO): Le SDSS n'est qu'une des nombreuses archives et ressources d'astronomie sur Internet. Internet sera bientôt le meilleur télescope au monde. Il disposera d'une grande partie des données astronomiques mondiales en ligne couvrant toutes les bandes spectrales mesurées. Les données seront croisées avec la littérature. Il sera accessible à tous partout. Et, si la VO réussit, il y aura d'excellents outils pour analyser toutes ces données.

Les archives scientifiques : Un deuxième groupe de SkyServers avec des données préliminaires (pas encore publiées) formera un réseau privé virtuel accessible au consortium SDSS. Ces serveurs auront des utilisateurs plus sophistiqués qui connaissent intimement les données. Ces serveurs auront donc des besoins uniques.

Sensibilisation et développement du programme : Les données SDSS sont un excellent moyen d'enseigner à la fois l'astronomie et la science informatique. Les données sont réelles - tout vient avec des barres d'erreur, tout a une forte composante scientifique. Les données SDSS ont également de fortes composantes graphiques, spatiales et temporelles. Il est assez bien documenté et est public. Et bien sûr, c'est grand par rapport aux normes d'aujourd'hui. Nous espérons que les éducateurs « découvriront » le SkyServer et son potentiel éducatif à la fois au niveau K-12 et au niveau universitaire.

Remerciements

Nous reconnaissons notre dette évidente envers les personnes qui ont construit le télescope SDSS, ceux qui l'exploitent, ceux qui ont construit les pipelines de traitement SDSS et ceux qui exploitent le pipeline au Fermilab. Les données SkyServer dépendent des efforts de toutes ces personnes. Compaq et Microsoft ont généreusement fait don de matériel, de logiciels et d'argent pour soutenir le SkyServer. Tom Barclay nous a conseillé sur la conception, la construction et l'exploitation du site Web. Roy Gal, Steve Kent, Rich Kron, Robert Lupton, Steve Landy, Robert Sparks, Mark Subba Rao, Don Slutz et Tamas Szalay ont contribué au contenu et au développement du site. Sadanori Okamura, Naoki Yasuda et Matthias Bartelmann ont construit les versions japonaise et allemande du site. Rosa Gonzalez et Kausar Yasmin ont aidé aux tests et ont développé des cours martiaux.

Les références

[Barclay] T. Barclay, D.R. Slutz, J. Gray, "TerraServer : un entrepôt de données spatiales," Proc. ACM SIGMOD 2000, p. : 307-318, juin 2000

[PREMIÈRE] Images pâles du ciel radio à vingt centimètres (PREMIÈRE) http://sundog.stsci.edu

[FITS] FITS - Système de transport d'images flexible, http://heasarc.gsfc.nasa.gov/docs/heasarc/fits.html

[Gris] SDSS 20 requêtes répondues. http://skyServer.sdss.org/en/download/

[HTM] Hierarchical Triangular Mesh http://www.sdss.jhu.edu/htm/ [Kunszt] PZ Kunszt, AS Szalay, I. Csabai, AR Thakar "The Indexing of the SDSS Science Archive" dans Proc ADASS IX , éd. N. Manset, C. Veillet, D. Crabtree, (ASP Conference series), 216, 141-145 (2000)

[Malik] Analyseur de requêtes SkyServer, http://skyServer.sdss.org/en/download/

[MAST] Archives multi-missions au télescope spatial. http://archive.stsci.edu/index.html

[Memspeed] http://research.microsoft.com/BARC/ Sequential_IO /memspeed.zip

[NED] Base de données extragalactique NASA/IPAC, http://nedwww.ipac.caltech.edu/

[Projet 2061] Principes et normes, http://www.project2061.org/

[ROSAT] Rüntgen Satellite (ROSAT) http://heasarc.gsfc.nasa.gov/docs/rosat/rass.html

[SDSS] D.G. York et al., The Sloan Digital Sky Survey: Technical Summary, The Astronomical Journal. 120 (2000) 1579-1587,

[SDSS-EDR] C. Stoughton et. al., "Sloan Digital Sky Survey Early Data Release", The Astronomical Journal, sous presse (2002)

[Archive SDSS-Science] http://www.sdss.jhu.edu/ScienceArchive/doc.html

[Simbad] Base de données astronomique SIMBAD, http://simbad.u-strasbg.fr/

[Szalay] A. Szalay, P.Z. Kunszt, A. Thakar, J. Gray, D.R. Slutz. « Conception et exploitation d'archives d'astronomie de plusieurs téraoctets : l'étude du ciel numérique de Sloan », Proc. ACM SIGMOD 2000, pp.451-462, 2000


4 réponses 4

Vous devez arrêter d'utiliser les pages de codes et passer à Unicode. C'est le seul moyen de se débarrasser de ce genre de problèmes.

Commentaire original transformé en réponse :

cp1250 et cp1252 ne sont PAS des "encodages latin1". Un classement n'est pas un encodage. Concernant votre commentaire : Qui a dit que "le serveur est encodé en latin1" ? Si le serveur s'attend à ce que toutes les entrées/sorties soient encodées en latin1 (ce dont je doute), alors vous ne pouvez tout simplement pas obtenir certains caractères d'Europe de l'Est dans votre base de données (ni russe, chinois, grec, etc.).

Il faut chercher plus loin que le classement. """msdn.microsoft.com/en-us/library/ms174596(v=SQL.90).aspx suggère, pour Latin1_General_CI_AS l'encodage utilisé est cp1252""" est codswallop. La table fournit un LCID (locale ID), défaut classement et page de codes pour chaque paramètre régional. Oui, le classement "Latin1_General_CI_AS" est répertorié en association avec la page de codes cp1252 pour plusieurs paramètres régionaux. Pour deux locales (arménien et géorgien), il est répertorié en association avec la page de codes "Unicode" (. ).

Tout simplement, vous devez savoir ce que page de codes la base de données utilise.

Essayez d'extraire des données de la base de données sans spécifier d'encodage du tout. Ne pas prendre la peine d'encoder cela, quel que soit l'encodage que vous pensez que votre console peut utiliser - cela ne fait qu'ajouter une autre source de confusion. À la place, utilisez print repr(data) . Rapportez ici ce que vous obtenez du repr() où vous attendez des caractères non latins1.


Accéder au serveur SDSS SQL server via python - Astronomie

sdssQA est un outil de requête SQL GUI pour aider à composer des requêtes SQL. Il a été inspiré par l'analyseur de requêtes SQL Server, mais fonctionne comme une application Java sur les clients UNIX, Macintosh et Windows et est disponible gratuitement sur ce site Web. Il se connecte via ODBC/JDBC (pour une utilisation locale) et via HTTP ou SOAP pour une utilisation sur Internet.

Outil SQL en ligne de commande

sqlcl est un outil de requête SQL en ligne de commande pour aider à composer des requêtes SQL. C'est un outil simple écrit en Python qui vous permet de soumettre des requêtes avec un minimum de tracas.

GalaxyExplorer : un outil de visualisation 3D

Auteur: Szalay, Tamas
Date: janvier 2002

Cet outil permet un survol interactif, semblable à un jeu vidéo, de la distribution des galaxies en 3D dans le Sloan Digital Sky Survey. Cet outil fonctionne sous Windows, nécessite DirectX8.0 ou supérieur et une carte graphique prenant en charge la 3D.

Le SDSS SkyServer - Accès public aux données de l'enquête sur le ciel numérique de Sloan

Auteur: Szalay, Alexander Gray, Jim Thakar, Ani Kunszt, Peter Z. Malik, Tanu
Raddick, Jordan Stoughton, Christopher VandenBerg, Jan
Date: novembre 2001

Le SkyServer fournit un accès Internet aux données publiques Sloan Digital Sky Survey (SDSS) pour les astronomes et pour l'enseignement des sciences. Ce document décrit les objectifs et l'architecture de SkyServer. Il décrit également notre expérience d'utilisation du SkyServer sur Internet. Les données SDSS sont publiques et bien documentées, ce qui en fait une bonne plate-forme de test pour la recherche sur les algorithmes et les performances des bases de données. Cela est apparu comme un rapport technique Microsoft, MS-TR-2001-104.

Concevoir et exploiter des archives d'astronomie de plusieurs téraoctets : The Sloan Digital Sky Survey

Auteur: Szalay, Alexander S. Kunszt, Peter Thakar, Ani Gray, Jim Slutz, Donald Brunner, Robert J.
Date: juin 1999 (révisé en février 2000)

Les archives permettront aux astronomes d'explorer les données de manière interactive. L'accès aux données sera facilité par des indices spatiaux et attributaires multidimensionnels. Les données seront partitionnées de plusieurs manières. Les petits objets de balise composés des attributs les plus populaires accéléreront les recherches fréquentes. La division des données entre plusieurs serveurs permettra des E/S parallèles et évolutives et une analyse des données parallèles. Les techniques de hachage permettront un clustering efficace et des algorithmes de comparaison par paires qui devraient se paralléliser correctement. Des sous-ensembles échantillonnés au hasard permettront le débogage de requêtes autrement volumineuses sur le bureau. Les serveurs centraux exploiteront une pompe de données pour prendre en charge les recherches de balayage touchant la plupart des données. Les requêtes anticipées nécessiteront des opérateurs spéciaux liés aux distances angulaires et aux tests de similarité complexes des propriétés des objets, comme les formes, les couleurs, les vecteurs de vitesse ou les comportements temporels. Ces problèmes posent des défis intéressants en matière de gestion des données.

Le document décrit notre vision du SkyServer, datée d'environ un an avant que nous ne commencions à construire le système de production. Cela est apparu comme un rapport technique Microsoft, MS-TR-99-30.


Conditions préalables

Pour commencer, vous devrez installer quelques prérequis. Tout d'abord, puisque vous vous connecterez à une instance SQL Server à partir de Python, vous aurez besoin d'un module Python. Un module Python commun pour se connecter à SQL s'appelle PyODBC. Ce module permet d'interroger des bases de données SQL via ODBC via un pilote ODBC SQL Server pour Linux. Pour installer la dernière version, utilisez pépin (le gestionnaire de paquets Python).

Si cela ne fonctionne pas, vous n'avez peut-être pas installé pip. Pour installer pip :

Ensuite, vous devez créer un script Python. Je vais appeler celui-ci serveur_sql.py. Pour créer un script Python, créez d'abord un fichier vierge.

Ensuite, à l'aide de l'éditeur de votre choix, ajoutez les lignes ci-dessous. Le shebang suivi du chemin vers le binaire Python indique à l'interpréteur qu'il s'agit d'un script Python. L'instruction import vous permet ensuite d'appeler les méthodes de la bibliothèque à l'intérieur du module pyodbc. Enregistrez ce script.

Une fois le script Python créé, exécutez le script :

Si cela fonctionne sans erreur, le module pyodbc a été installé avec succès.

Ensuite, ajoutez le code pour exécuter une requête de test. Pour ce faire, créez une chaîne ODBC.

Pour en savoir plus sur la création de chaînes ODBC, voici une bonne ressource.

La chaîne ODBC est pointilleuse sur ce qui est inclus. Il a fallu un certain temps pour comprendre comment faire fonctionner cela, mais voici à quoi ressemble le mien. Ci-dessous, je passe la chaîne ODBC en tant qu'argument à la méthode connect() qui est incluse avec le pyodbc module.

La plupart de la chaîne ODBC est évidente, mais un fait important est la double barre oblique inverse pour le UID. Assurez-vous toujours que vous avez échappé aux barres obliques inverses dans la chaîne ODBC. De plus, certaines des options que j'utilise sont facultatives.

En outre, vous pouvez soit utiliser le nom d'hôte pour SERVER comme je l'ai fait ci-dessus, soit utiliser l'adresse IP SQL Server.

N'hésitez pas à les ajouter ou à les supprimer comme bon vous semble pour correspondre à votre serveur SQL.

Ensuite, vous devez créer un objet curseur qui vous permettra de passer une instruction T-SQL à. Cela se fait avec la méthode curseur().

Vous avez maintenant un objet avec une méthode execute () qui peut être utilisée pour passer n'importe quelle instruction T-SQL dans laquelle nous aimons, comme indiqué ci-dessous. Cela crée une variable de lignes contenant l'ensemble de données résultant.

Vous en êtes maintenant au point où vous devrez décider quoi faire avec l'ensemble de données. Vous pouvez envoyer les résultats dans un fichier CSV, mettre les résultats dans une autre base de données ou écrire le contenu dans la console.

Ci-dessous, j'imprime les résultats sur la console si l'ensemble de données est rempli.

Impression de lignes SQL en Python

Vous pouvez voir que si l'ensemble de données est imprimé sur la console, la sortie n'est pas trop jolie. À ce stade, c'est à vous de décider comment formater ou analyser les données de la base de données. Le plus dur est passé !

Vous obtenez maintenant un script qui ressemble à ceci :


Exemple de connexion Python et SQL Server

Dans cet exemple, nous vous montrons comment établir la connexion entre Python et SQL Server à l'aide de la bibliothèque pyodbc avec un exemple pratique.

Dans ce python, connectez-vous au programme du serveur SQL, tout d'abord, nous importons la bibliothèque pyodbc. Et il possède toutes les fonctions requises pour établir une connexion avec SQL Server à partir de Python IDE.

Si vous n'avez pas la bibliothèque Python, ouvrez l'invite de commande en tant qu'administrateur, puis accédez aux scripts Python (facultatif) et tapez pip install pyodbc.

Ensuite, nous utilisons la fonction de connexion pour connecter Python aux serveurs SQL. Ici, nous utilisons l'authentification Windows, et c'est pourquoi nous n'avons pas spécifié le nom d'utilisateur et le mot de passe. Cependant, en temps réel, vous devez spécifier à la fois le nom d'utilisateur et le mot de passe pour vous connecter au serveur SQL.

Ensuite, nous importons les données de la table Employ présente dans le serveur SQL.

Enfin, nous utilisons la boucle For pour itérer chaque ligne présente dans la table Employ, puis imprimons la sortie.


Le modèle de données du catalogue SDSS

Les données du catalogue SDSS sont stockées dans un système commercial de gestion de base de données relationnelle (SGBD) - SQL Server de Microsoft. Les données sont donc organisées en plusieurs tableaux à 2 dimensions. Les tables et leurs relations entre elles sont appelées les schéma dans le jargon des bases de données.

Vue schématique du schéma DR7

Il existe 3 types de données différents dans les tableaux - les données d'imagerie sont dans le photo groupe de tableaux, les données spectroscopiques et de pavage sont dans le spectro tableaux, et d'autres données telles que la documentation ou d'autres informations sur les données photo et spectro, c'est-à-dire les métadonnées, se trouvent dans le méta les tables. Certaines tables sont également créées spécifiquement pour la speef ou la commodité, par exemple la table SpecPhotoAll, qui contient une jointure pré-calculée des champs pertinents dans les tables PhotoObjAll et SpecObjAll.

Les tableaux importants sont décrits ci-dessous, ainsi que les vues qui sont actuellement définis sur chaque table. Une vue est un sous-ensemble de la table correspondante qui peut être utilisée à la place de la table - en d'autres termes, c'est un table virtuelle. Une vue est généralement plus rapide que l'utilisation de la table de base, car elle ne charge qu'un sous-ensemble des objets, mais plus important encore, les vues que nous avons définies sur les tables sélectionnent uniquement les objets importants pour la science et filtrent les non-sciences. des objets tels que le ciel, l'assurance qualité ou des observations défectueuses. Ainsi, même si nous listons ci-dessous les tableaux de base par souci d'exhaustivité, dans la grande majorité des cas, vous devez utiliser les vues définies sur les tables au lieu des tables elles-mêmes, par exemple. utilisez les vues PhotoObj et SpecObj pour la science au lieu des tables PhotoObjAll et SpecObjAll.

BESTDR7, TARGDR7 et autres bases de données

Il existe deux ensembles de données principaux dans le serveur d'archives de catalogue SDSS - les ensembles de données BEST et TARGET qui sont contenus dans des bases de données distinctes. Chacun contient des retraitements différents des mêmes données brutes :

  • le jeu de données BEST est contenu dans le BESTDR7 base de données et représente le dernier et le plus grand étalonnage des données brutes. BESTDR7 est la base de données par défaut pour les requêtes. Les autres bases de données doivent être explicitement spécifiées (voir ci-dessous pour un exemple de syntaxe).
  • L'ensemble de données TARGET est contenu dans le TARGDR7 base de données, et représente un instantané des données telles qu'elles étaient lorsque l'algorithme de sélection de cible y a été exécuté, c'est-à-dire qu'il s'agit de l'étalonnage sur lequel les cibles spectroscopiques ont été choisies. La préservation de cette version des données est importante pour faire de la science avec les données.

Les deux bases de données ont le même schéma (tables), mais des données différentes. La base de données BESTDR7 contient également les données spectroscopiques et de mosaïque, tandis que la base de données TARGDR7 ne contient que des données d'imagerie. La grande majorité des requêtes sont exécutées sur la base de données BESTDR7.

Pour choisir une base de données autre que celle par défaut BESTDR7 dans votre requête, vous devez le spécifier comme <dbname>..<tablename>, par exemple, TARGDR7..PhotoObj : veuillez consulter la page d'introduction SQL pour plus d'aide sur les requêtes SQL.

Le maillage triangulaire hiérarchique (HTM)

Nous avons construit un schéma d'indexation spatiale appelé Hierarchical Triangular Mesh (HTM) qui décompose spatialement la région du ciel couverte par les données SDSS et permet des recherches spatiales beaucoup plus rapides des données par des coupes de coordonnées.

Indices de base de données

En plus du HTM, qui est un schéma d'indexation global pour les données spatiales multidimensionnelles, le SGBD lui-même a la capacité de définir des index pour des recherches rapides sur chaque table. nous avons défini indices sur toutes les grandes tables.

  • Index de clé primaire - index sur la clé primaire unique d'une table.
  • Index de clé étrangère - index sur une clé étrangère d'une table, c'est-à-dire une colonne qui est une clé primaire d'une autre table.
  • Indice de couverture - un index qui couvre une ou plusieurs colonnes d'une table. Il s'agit d'un index combiné sur ces champs, il accélère donc les recherches si l'un de ces champs est inclus dans la clause WHERE.

Tableaux de données d'imagerie (photo)

- De loin la plus grande table de la base de données, PhotoObjAll contient plus de 100 paramètres pour chaque objet d'imagerie (photo). Pour la plupart de ces paramètres, il y a en fait 5 lignes chacune, une pour chaque bande de longueur d'onde. Ce tableau comprend des données sur tout des objets photo, pas seulement des objets scientifiques, d'où le nom PhotoObjTout. La vue de ce tableau qui inclut uniquement les objets scientifiques et exclut le ciel et d'autres objets inconnus est la PhotoObj vue. La table PhotoObjAll est là pour être complet, mais les requêtes scientifiques sont généralement effectuées sur la vue PhotoObj.

PhotoObjToutes les vues :

Afficher le nomContenuLa description
PhotoAuxAll Voir pour PhotoAuxAll pour une compatibilité descendante avec DR5. Il sélectionne les colonnes requises dans PhotoObjAll.
PhotoAuxAll Voir pour PhotoAuxAll pour une compatibilité descendante avec DR5. Il sélectionne les colonnes requises dans PhotoObjAll.
PhotoAuxAll Voir pour PhotoAuxAll pour une compatibilité descendante avec DR5. Il sélectionne les colonnes requises dans PhotoObjAll.
PhotoAuxAll Voir pour PhotoAuxAll pour une compatibilité descendante avec DR5. Il sélectionne les colonnes requises dans PhotoObjAll.
PhotoAuxAll Voir pour PhotoAuxAll pour une compatibilité descendante avec DR5. Il sélectionne les colonnes requises dans PhotoObjAll.
PhotoAuxAll Voir pour PhotoAuxAll pour une compatibilité descendante avec DR5. Il sélectionne les colonnes requises dans PhotoObjAll.
PhotoAuxAll Voir pour PhotoAuxAll pour une compatibilité descendante avec DR5. Il sélectionne les colonnes requises dans PhotoObjAll.
PhotoFamille Celles-ci sont dans PhotoObj, mais ni PhotoPrimaire ni Photosecondaire. Ces objets sont générés s'il ne s'agit ni d'objets d'étude primaires ni secondaires, mais d'un objet composite qui a été déblayé ou de la partie d'un objet qui a été déblayée à tort (comme les bras spiraux d'une galaxie). Ces objets sont conservés pour suivre le fonctionnement du débrideur. Il hérite de tous les membres de la classe PhotoObj.
PhotoObj Tous les objets primaires et secondaires de la table PhotoObjAll, qui contient tous les attributs de chaque objet photométrique (image). Il sélectionne PhotoObj avec mode=1 ou 2.
PhotoPrimaire Ces objets sont les principaux objets de l'enquête. Chaque objet physique dans le ciel n'a qu'un seul objet principal qui lui est associé. Lors d'observations ultérieures, des objets secondaires sont générés. Étant donné que les bandes d'enquête se chevauchent, il y aura des objets secondaires pour plus de 10 % de tous les objets primaires, et dans les bandes sud, il y aura une multitude d'objets secondaires pour chaque primaire (c'est-à-dire des réobservations).
PhotoSecondaire Les objets secondaires sont des réobservations du même objet primaire.

PhotoObjTous les indices :

- Il s'agit d'une partition verticale de la table PhotoObjAll, et ne contient que les colonnes les plus souvent demandées. En raison de la taille plus petite de chaque ligne de la table, beaucoup plus de lignes peuvent être chargées dans le cache mémoire en même temps, par conséquent les recherches sur la table PhotoTag sont beaucoup plus rapides que les recherches sur PhotoObjAll. Dans la mesure du possible, utilisez la table PhotoTag au lieu de PhotoObjAll ou PhotoObj.

Indices PhotoTag :

- Ce tableau contient les paramètres de base associés à un segment, qui est une unité de données correspondant à une seule colonne de caméra dans un morceau.

Indices de segment :

- Ce tableau contient tous les paramètres mesurés de chaque champ d'imagerie, ainsi que les statistiques récapitulatives pertinentes et les informations astrométriques et photométriques.

Indices de champ :

- Un morceau est une section contiguë de données d'imagerie au sein d'une portée (bande pour le sud). Il se compose de bandes nord et sud complètes entre les limites inférieure et supérieure du mu. Un morceau est composé d'un ensemble de segments primaires (ou parties de segments) qui se touchent mais ne se chevauchent pas.

Indices de bloc :

- Ce tableau contient les profils lumineux des objets photo SDSS.

Indices de profil photo :

- Ce tableau contient les profils lumineux des objets de champ SDSS.

Indices de profil de champ :

- Les objets SDSS à moins de 0,5 arcmins et leurs paramètres de correspondance sont stockés ici. Assurez-vous de filtrer les PhotoObj indésirables, comme les secondaires.

Indices voisins :

- Ce tableau contient des paires PhotoObj (objet primaire et secondaire) provenant de différentes séries (observations) qui sont probablement le même objet. En effet, ce tableau enregistre plusieurs observations de chaque objet.

Indices de correspondance :

- Cette table enregistre l'objet canonique de chaque cluster de correspondance et les statistiques de cluster. Les observations pour un objet (telles qu'enregistrées dans la table Match) forment un cluster nommé par l'objID minimum dans le cluster. MatchHead a des informations récapitulatives sur le cluster saisi par l'objID.

Indices MatchHead :

Tableaux de données Spectro/Pilage

- Ce tableau contient les données exportées (le X est pour l'export) d'une plaque donnée utilisée pour les observations spectroscopiques. Chaque plaque a 640 spectres observés et donc 640 entrées correspondantes dans SpecObjAll.

Indices PlateX :

- Il s'agit d'une table de base contenant TOUT les informations spectroscopiques, y compris de nombreuses données en double et erronées. Utilisez le SpecObj voir à la place (voir ci-dessous), qui a les données correctement filtrées pour la propreté.

SpecObjToutes les vues :

Afficher le nomContenuLa description
SpecObj Une vue des objets Spectro qui n'a que les spectres propres. La vue exclut QA et Sky et les doublons. Utilisez-le comme principal moyen d'accéder aux objets spectro.

Indices SpecObjAll :

- Un recueil de toutes les raies spectrales trouvées dans tous les objets spectroscopiques de la table SpecObjAll. Contient tous les paramètres mesurés pour chaque raie spectrale. Il existe une vue SpecLine de cette table qui contient uniquement les lignes qui ont été mesurées.

SpecLineToutes les vues :

Afficher le nomContenuLa description
LigneSpéc Une vue des objets SpecLines qui ont été mesurés La vue exclut les objets SpecLine qui ont la catégorie=1, ils n'ont donc pas été mesurés. C'est la vue que vous devez utiliser pour accéder aux données SpecLine.

SpecLineTous les indices :

- Indices de raies spectrales précalculés. Ce sont des combinaisons d'intensités de raies spectrales utilisées pour déterminer diverses propriétés des galaxies, comme l'âge ou la métallicité.

Vues SpecLineIndex :
Indices SpecLineIndex :

- Contient des informations sur les tuiles individuelles sur le ciel.

TileToutes les vues :

Afficher le nomContenuLa description
Tuile Une vue de TileAll qui ont jusqu'à=0 La vue exclut les tuiles qui ont été créées.

Indices TileAll :

- Ce tableau stocke des informations qui permettent de savoir pourquoi une cible a été affectée à une vignette.

TiledTargetToutes les vues :

Afficher le nomContenuLa description
Cible en mosaïque Une vue des objets TiledTargetAll qui ont jusqu'à = 0 La vue exclut les objets TiledTarget qui ont été désactivés.

TiledTargetTous les indices :

- Cette table contient des informations géométriques sur les régions de tuilage, y compris les limites de tuilage. La vue TileBoundary sert les limites.

Vues TileingGeometry :

Afficher le nomContenuLa description
CarrelageFrontière Une vue des objets TilingGeometry qui ont isMask = 0 La vue exclut les objets TilingGeometry qui ont isMask = 1. Voir aussi TilingMask.
CarrelageMasque Une vue des objets TilingGeometry qui ont isMask = 1 La vue exclut les objets TilingGeometry qui ont isMask = 0. Voir aussi TilingBoundary.

Indices TileingGeometry :

Métadonnées et autres tableaux

- Les paramètres spectro et photo combinés d'un objet dans SpecObjAll. Il s'agit d'une jointure précalculée entre les tables PhotoObjAll et SpecObjAll. Les attributs de la photo comprenaient une couverture à peu près identique à celle de PhotoTag. La table comprend également certains attributs de la table Tile.

SpecPhotoToutes les vues :

Afficher le nomContenuLa description
SpecPhoto Une vue des objets Spectro et Photo joints qui ont les spectres propres. La vue n'inclut que les paires où le SpecObj est un sciencePrimary et le BEST PhotoObj est un PRIMARY (mode=1).

Indices SpecPhotoAll :

Connexion à une instance distante de SQL Server à l'aide de Python

L'intégration de Python par SQL Server a été fortement commercialisée auprès des spécialistes de l'apprentissage automatique et de la BI, mais offre-t-elle quelque chose pour le DBA ?

Toute l'attention a été portée sur l'apprentissage automatique, à tel point que pendant un certain temps, je n'y ai pas prêté attention du tout, mais j'ai ensuite pensé à moi-même. Les administrateurs de bases de données de partout adorent PowerShell en ce moment, il peut faire tellement de choses, n'est-ce pas ? C'est fantastique pour l'automatisation, nous pouvons envoyer des scripts vers plusieurs serveurs en appuyant sur un bouton, nous pouvons extraire les données de toutes nos instances dans une base de données de gestion centralisée. C'est génial pour garder les choses à jour, cela rend la gestion centralisée de nos instances aussi simple que vous le souhaitez et la surveillance, plus besoin d'avoir des tâches ou des agents en cours d'exécution sur tous ces serveurs, un seul script PowerShell peut sortir et découvrez tout ce que nous devons savoir.

Maintenant, Python est un langage de programmation très riche, si seulement il pouvait se connecter à un serveur SQL distant, il serait soudainement aussi utile que PowerShell s'est avéré l'être. Si cela était possible, nous pourrions accéder à tous nos serveurs à partir d'un seul processus stocké sans avoir besoin de quoi que ce soit pour des choses désagréables comme CMDEXEC ou des serveurs liés.

Eh bien, c'est possible, il suffit de vérifier ceci….

Sélection à partir d'un serveur distant

Contrairement à l'utilisation de PowerShell, il n'est pas nécessaire de passer des appels externes à l'aide de CMDEXEC, nous pouvons exécuter nos scripts Python à partir de T-SQL en utilisant le plutôt joli sp_execute_external_script. C'est le même processus que vous utilisez pour exécuter des scripts R (si vous êtes enclin à cela), mais maintenant, avec SQL2017, nous pouvons également l'utiliser pour exécuter des scripts Python. Une partie de moi se demande si Microsoft a l'intention d'étendre davantage sa portée, lui permettant également d'exécuter PowerShell et peut-être même du code .NET.

La syntaxe de base de sp_execute_external_script est simple, tout ce que nous avons à faire est d'attribuer le paramètre @language, la langue que nous utilisons, dans ce cas ‘Python’ et le paramètre @script prendra le code que nous voulons exécuter .

Microsoft nous a très gentiment fourni tout un tas de packages qui font toutes sortes de choses géniales. Pour se connecter à un serveur distant et renvoyer un ensemble de données, il y en a deux qui nous intéressent, pyodbc et pandas. pyodbc expose une API que nous pouvons utiliser pour nous connecter à notre serveur et pandas est un package principalement conçu pour l'analyse de données, mais pour nos besoins, il peut renvoyer un ensemble de données à SQL.

Le code suivant se connectera à un serveur distant et renverra une liste de bases de données sur cette instance.

Le code est assez simple, nous commençons par importer les deux packages dont nous avons besoin. Nous créons un objet de connexion en utilisant une chaîne de connexion à notre instance distante de SQL. Nous attribuons notre commande sql à la variable de requête et appelons enfin la méthode Pandas ‘read_sql’ qui utilisera la chaîne de connexion fournie pour se connecter à l'instance distante et exécuter la requête. Les résultats sont affectés à OutputDataSet et c'est cet ensemble de données qui est renvoyé à SQL.

Si nous le voulions, nous pouvons même transmettre des paramètres au script, nous pouvons utiliser @params pour définir les paramètres à transmettre au script python. L'exemple ci-dessous passe la requête SQL dans le script.

Modification des données

On peut donc choisir sur un serveur distant mais comment faire pour modifier les données ?

Assez simple vraiment, jetez un œil au code ci-dessous pour une mise à jour rapide….

Alors voilà, bien qu'il n'y ait rien de bouleversant ici, j'espère que vous pourrez voir à quel point Python pourrait être utile pour le DBA et pas seulement pour le BIData Scientist. La vraie beauté est que tout ce code pourrait se trouver dans un proc stocké, quelque chose que vous ne pouvez pas faire aussi bien avec PowerShell.


Voir la vidéo: Обзор SQL Server 2008 Analysis Services (Septembre 2022).