РОССИЙСКИЙ НАУЧНЫЙ ЭЛЕКТРОННЫЙ ЖУРНАЛ Электронные библиотеки
2014 | Volume 17| Issue 1|

Архитектура Базы данных двойных звезд BDB

П.В. Кайгородов, Д.А. Ковалева, О.Б. Длужневская, О.Ю. Малков

Аннотация

Представлено описание архитектуры базы данных двойных звезд (Binary star DataBase, BDB), разрабатываемой в Институте астрономии РАН. Целью создания BDB является объединение информации из множества разнородных каталогов двойных и кратных звезд, а также разработка удобного инструмента для работы с данными каталогов. Рассматриваются основные проблемы, возникшие в процессе реализации BDB, методики извлечения информации из исходных каталогов, а также методы кросс-идентификации объектов. BDB реализована на базе фреймворка Nagare (stackless Python/SQLAlchemy/Elixir) и СУБД Postgresql, ее beta-версия доступна по адресу http://bdb.inasan.ru.

Ключевые слова: базы данных, двойные звезды.

1. Введение

Двойные звезды выделяются среди прочих астрономических объектов богатством наблюдательных проявлений, что делает их изучение важной задачей. Компоненты двойной звезды имеют одинаковый возраст, кроме того, их исходный химический состав был одинаков в момент рождения, что делает их идеальным полигоном для проверки эволюционных моделей звезд. Оба компонента двойной звезды находятся на одинаковом расстоянии от Земли, и их излучение испытывает одинаковое влияние межзвездной среды, что весьма важно для определения расстояний и оценки величины межзвездного поглощения. Только для компонентов двойных звезд возможно получение точных оценок масс и радиусов. Наблюдательные проявления двойных звезд весьма разнообразны – взаимодействие компонентов двойных звезд в процессе эволюции может сопровождаться выделением энергии как на их поверхности, так и в межзвездном пространстве, где возникают аккреционные диски, джеты, ударные волны и т.п. элементы течения. Наконец, важной особенностью двойных звезд является их многочисленность – как минимум половина звезд в Галактике является компонентами двойных звезд или звезд большей кратности.

На настоящий момент создано большое количество каталогов и баз данных, содержащих информацию о параметрах двойных звезд различных типов, в том числе визуальных (компоненты которых могут быть разделены при визуальных наблюдениях), интерферометрических (наблюдение отдельных компонентов возможно с использованием интерферометров), затменных (двойственность которых проявляется в виде периодического изменения блеска), спектроскопических (детектируемых по периодическому смещению спектральных линий), а также ряда других. Тем не менее, до настоящего времени не было создано единой базы данных, включающей информацию обо всех типах двойных звезд. Разработка базы данных двойных звезд (BDB) имеет целью создание подобного инструмента.

Основной проблемой при работе с астрономическими данными является их разнородность. Любой отдельно взятый каталог или база данных двойных звезд содержит, как правило, только ограниченный набор параметров, получаемых авторами. При этом, например, информации, содержащейся в каталоге, посвященном затменным двойным (и, соответственно, получаемой по результатам исследования кривых блеска) может быть недостаточно для определения всех параметров компонентов некоторой звезды, однако, в другом каталоге, где эта же звезда представлена как, например, спектроскопическая двойная, могут быть данные об амплитудах лучевых скоростей, позволяющие, совместно с данными первого каталога, вычислить необходимые параметры. Соответственно, для решения многих задач необходимо создание инструмента, позволяющего находить информацию об интересующем объекте во всех доступных источниках.

Множественность источников, содержащих информацию об одном и том же объекте, создает другую проблему – многовариантность данных. Поскольку наблюдения одного и того же объекта могли быть проведены различными группами, в разное время, с использованием различных методик, измеряемые параметры могут иметь разное значение в различных источниках. При этом причиной различия не обязательно может быть недостаточная точность измерений – сами измеряемые параметры могут варьироваться со временем. Например, блеск двойной звезды может меняться при вспышках, затмениях компонентов, а также по ряду других причин. При исследовании двойной звезды важен анализ всей истории наблюдений, соответственно, создаваемый нами инструмент должен предусматривать выдачу результатов всех имеющихся измерений для данного объекта.

Большое количество источников, содержащих информацию о некотором объекте, порождает еще одну проблему – необходимость проведения кросс-идентификации. На данный момент существует несколько десятков систем обозначений, позволяющих идентифицировать астрономические объекты. Двойная звезда может иметь один или несколько идентификаторов в различных системах, при этом в разных источниках могут упоминаться различные ее идентификаторы, что затрудняет поиск. На данный момент не существует единой системы идентификации, покрывающей все типы двойных звезд. Одной из целей создания BDB является разработка такой системы идентификации.

Изначально, BDB разрабатывалась в обсерватории г. Безансон (Франция, http://bdb.obs-besancon.fr) и объединяла данные из следующих каталогов: CCDM и WDS1966 для визуальных двойных, нескольких каталогов затменных двойных, а также трех фотометрических каталогов (UBV, Stromgren, Geneva) [1]. В 2008 году было принято решение о переносе разработки BDB в Институт астрономии РАН, где база данных была существенно переработана. Основные цели и идеи, лежащие в основе BDB, обсуждаются в [2-5].

2. Архитектура BDB

2.1 Источники данных

Данные, которыми наполняется BDB, извлекаются из источников, различающихся по структуре и содержанию. Среди них можно выделить такие типичные виды, как астрономические обзоры, астрономические каталоги и астрономические базы данных.

  • Термин «астрономический обзор» может относиться как к наблюдательной программе, так и к типу организации астрономических данных. Астрономическим обзором принято называть коллекцию астрономических данных об объектах, обладающую полнотой (т.е. включающую все астрономические объекты с параметрами, лежащими в заданных пределах) по некоторым признакам, например, по координатам и/или блеску объектов. Данные астрономических обзоров могут быть представлены как в табличном виде, так и в виде изображений.
  • Астрономический каталог – упорядоченная коллекция большого количества (как правило, подвергнутых некоторой обработке) данных определенного типа, либо относящихся к некоторому определенному типу объектов. В приложении к двойным звездам это могут быть, например, каталоги затменных двойных звезд, либо визуальных звезд, либо звезд, проявляющих рентгеновскую активность. Данные в каталогах представлены, как правило, в табличном виде. Значительная часть выпущенных на настоящий момент астрономических каталогов включена в коллекцию Страсбургского международного центра астрономических данных (CDS, http://cdsarc.u-strasbg.fr/viz-bin/Cat). Типичным примером астрономического каталога может служить объединенный каталог переменных звезд (ОКПЗ, http://www.sai.msu.su/gcvs/). ОКПЗ содержит информацию обо всех известных переменных звездах (десятки тысяч объектов) и является наиболее полным и авторитетным источником информации об астрономических объектах этого типа.
  • Астрономические базы данных представляют собой тематические коллекции астрономических данных с более высокими уровнями структурирования, часто снабженные онлайн-средствами для поиска и получения данных. Они могут содержать данные разных видов (численные данные, изображения, библиографическую информацию, и пр.). Некоторые базы данных периодически обновляются. Содержимое астрономических баз данных может публиковаться в виде каталогов. Примером одной из современных широко используемых астрономических баз данных может служить база данных астрономических каталогов VizieR (http://vizier.u-strasbg.fr/viz-bin/VizieR), позволяющая проводить комплексный поиск астрономических данных в любой выборке из почти 10 тысяч каталогов, содержащихся в CDS.

Каталоги, содержащиеся в CDS, имеют стандартный формат [6] описания и представления данных, позволяющий включать каталог в систему VizieR. Данное описание обязательно включает в себя текстовый файл с именем ReadMe, имеющий четко определенный формат и пригодный для машинной интерпретации. В этом файле содержится как общая информация о каталоге (название, список авторов, текстовое описание, ссылки на публикации), так и список файлов, входящих в каталог, а также полное описание их структуры. Например, раздел, описывающий файлы каталога CCDM выглядит так:

Файлы каталога имеют текстовый формат, данные в них разбиты на строки, которые, в свою очередь, делятся на поля фиксированной ширины. Размеры и положение полей, формат содержащихся в них данных (текст, целые числа, числа с плавающей точкой), а также описание их содержимого (например, единицы измерения) включено в файл ReadMe. Описание файла refpos.dat каталога CCDM выглядит следующим образом:

Содержимое файла refpos.dat:

На данный момент в BDB реализована поддержка формата CDS, каталоги в других форматах должны быть переведены в формат CDS для успешного импорта в BDB.

2.2 Структура базы данных BDB

Как было сказано выше, BDB содержит информацию о двойных и кратных звездах. Кратные звезды могут представлять собой мини-скопления (далее – системы) гравитационно связанных между собой объектов, или составлять иерархию пар, в которой элементом каждой пары может быть либо одиночная звезда, либо другая (в том числе – иерархическая) пара, либо система из нескольких пар и одиночных звезд. Основной сложностью при извлечении данных является то, что разбиение на пары и компоненты в различных каталогах может быть произведено разным способом. Например, в одном каталоге некоторый объект может присутствовать как одиночная звезда, в то время как в другом каталоге он может представлять собой пару, в том числе – иерархическую. Более того, иерархия объектов в одной и той же системе может выстраиваться в разных каталогах неодинаково. При разработке BDB в качестве основного принципа был взят принцип нейтральности – содержимое каталогов, включаемых в BDB, не должно подвергаться фильтрации или изменению. В случае, когда данные каталогов вступают в противоречие друг с другом, BDB должна отобразить это и предоставить пользователю возможность самостоятельного выбора.

Запись в BDB может относиться к одному из следующих типов: система, пара, компонент, ссылка. Система не содержит никаких специфических полей данных, записи этого типа служат только для связки принадлежащих ей пар. Пара ссылается на родительскую систему и содержит поля, специфические для двойных систем: орбитальный период, угловой размер и размер большой полуоси (для фотометрически разрешенных пар), эксцентриситет и т.п. данные, кроме того пара может ссылаться на один или два компонента (один компонент может быть неизвестен для некоторых, т.н. «астрометрических» пар). Компонент содержит поля, специфические для отдельной звезды – блеск, амплитуду лучевой скорости и т.п. Ссылка, как и система, не содержит специфических полей, на записи данного типа могут ссылаться записи систем, пар и компонентов, через поле references (см. ниже). При импорте данных для каждой интерпретируемой строки каталога создается одна или несколько записей, принадлежащих к вышеперечисленным типам. Значения, помещаемые в поля создаваемых записей, вычисляются по алгоритмам, разрабатываемым отдельно для каждого интерпретируемого каталога. При этом каждая запись содержит ссылку на исходный каталог и строку, из которой были взяты данные. Эта информация может быть получена пользователем в процессе работы с BDB. Кроме вышеперечисленных, также в базе данных присутствуют записи, содержащие информацию о каталогах, структуре их файлов, а также правила извлечения данных из них.

При импорте данных в BDB для каждого объекта создается столько записей, сколько раз он упоминается в разных каталогах. При этом в одном каталоге объект может упоминаться несколько раз, в том числе – в разных файлах. Для связи между записями используется внутренние (действующие внутри одного каталога) и внешние (для связи между разными каталогами) идентификаторы. Внутренние идентификаторы могут быть построены произвольным образом (они никогда не отображаются при работе пользователя с BDB), главное требование к ним – каждый объект в пределах одного каталога должен иметь один и только один, уникальный идентификатор. Если объект упоминается несколько раз в каталоге (например, часть параметров представлена в одном файле каталога, а часть – в другом), то создается несколько записей (в каждой из которых заполнена только часть полей), имеющих общий внутренний идентификатор. При отображении информации BDB автоматически найдет все записи с этим внутренним идентификатором и покажет полный набор параметров. Если наборы параметров в разных записях пересекаются, то будут показаны все варианты каждого параметра (перечислением в квадратных скобках). Иногда требуется связать одну запись в каталоге с несколькими различными объектами. Например, в отдельной таблице могут быть представлены ссылки на источники данных, при этом из каждого источника может быть взято несколько объектов. Чтобы отразить данную информацию при выдаче результатов запроса, подобные записи связываются через специальное поле references, которое может содержать произвольное количество внутренних идентификаторов.

Внешние идентификаторы используются для связи записей из разных каталогов. Каждый внешний идентификатор относится к одной из нескольких десятков идентификационных систем, используемых в астрономии. В BDB включаются идентификаторы из следующих систем: ADS, Bayer, CCDM, DM, Flamsteed, GCVS, HD, HIP, IDS, IGR, Name, SBC9 и WDS. Каждый объект (система, пара или компонент) может иметь один или несколько внешних идентификаторов, при этом часто встречается ситуация, при которой несколько объектов могут иметь один идентификатор в некоторой системе. Это связано с тем, что на момент присвоения идентификатора эти объекты не были разрешены и наблюдались как один источник света. Пользователь, делающий запрос к BDB по идентификатору, должен получить исчерпывающую информацию о запрошенном объекте. Соответственно, в рамках BDB должна быть решена задача кросс-идентификации – каждому объекту должен быть сопоставлен список всех когда-либо присвоенных ему идентификаторов, при этом физически разделенные объекты не должны соединяться, даже в случае, если они имеют один или несколько общих идентификаторов. Для обеспечения этих требований нами разработана собственная непротиворечивая система идентификации, которая на данный момент проходит тестирование. Основные принципы построения этой системы приведены в разделе 3.

2.3 Реализация BDB

BDB реализована на языке Python с использованием фреймворка Nagare и Elixir – декларативной надстройки над ORM SQLAlchemy, в качестве СУБД используется PostgreSQL. Для онлайн-запросов к внешним сервисам используется модуль ZSI, реализующий протокол SOAP. BDB состоит из двух частей – web-приложения, обеспечивающего взаимодействие с пользователем, и демона, производящего обработку данных при импорте каталогов. Взаимодействие между этими частями происходит через систему обмена данными memcache. В свою очередь, web-приложение делится на административную и пользовательскую части. Административная часть предназначена для добавления и удаления каталогов, создания и изменения правил их импорта, а также для настройки некоторых параметров BDB. Пользовательская часть служит для поиска и отображения информации, содержащейся в BDB.

Процесс добавления нового каталога состоит из нескольких этапов. Прежде всего, необходимо загрузить на сервер BDB файлы каталога, включающие файл ReadMe. Это может быть сделано либо вручную, загрузкой zip-архива, либо автоматически, указанием имени каталога в CDS, при этом необходимые файлы будут подгружены с ftp-сервера CDS. После загрузки файла ReadMe происходит его автоматический анализ, при этом извлекается информация обо всех файлах каталога, и в базу данных заносятся соответствующие записи. В случае, если в файле ReadMe имеются ошибки, не позволяющие правильно его распознать, содержимое файла может быть отредактировано средствами BDB. После того, как файл ReadMe успешно интерпретирован, загружаются (извлекаются из архива) файлы с данными.

Разбор содержимого файла ведется построчно: для каждой строки выполняется код, сгенерированный на основе заданных правил. Для извлечения данных из файлов необходимо создать отдельный набор правил для каждого из них. Интерфейс для создания правил интерпретации включает в себя несколько разделов: раздел систем, раздел пар, два раздела компонентов, а также раздел общего кода, выполняемого при старте интерпретатора, перед и после интерпретации каждой строки. Кроме того, на странице показывается содержимое первых десяти строк анализируемого файла, а также его описание, извлеченное из ReadMe. В разделах систем, пар и компонентов имеются поля, в которые необходимо вписать код (на языке Python), возвращающий значение (например, орбитальный период для пары или звездную величину для компонента) сохраняемое в соответствующем поле создаваемой записи. Для вычисления некоторых параметров могут использоваться сложные алгоритмы, не умещающиеся в пределах однострочного поля ввода. Их реализация может быть перенесена в раздел общего кода, результат сохранен в виде переменной, а в соответствующем поле ввода указано ее имя. Для алгоритмов, требующих начальной инициализации, существует особый раздел, куда вписывается код, исполняемый однократно при старте интерпретатора.

Кроме полей, специфических для записей разных типов, есть поля общие – поле внутреннего идентификатора (о его назначении см. выше), а также поле флага. Выражение, вписываемое в поле флага, должно возвращать логическое значение True, если в результате интерпретации текущей строки каталога должна быть создана запись данного типа (системы, пары или компонента), в противном случае выражение должно возвращать False. Также имеется общее поле References, которое может содержать массив строк (в нотации Python), каждая из которых должна представлять собой внутренний идентификатор. При непустом поле References у всех сгенерированных при разборе текущей строки записей будут добавлены соответствующие ссылки. При отображении информации пользователю будут показаны не только данные из запрошенных им записей, но и все строки оригинального каталога, на которые у этих записей имеются ссылки. Этот механизм используется, например, для отображения комментариев, включенных в оригинальный каталог.

После ввода всех правил можно провести тестовую интерпретацию первых 100 строк файла, при этом реальные изменения в базу данных не вносятся, а результаты распознавания выводятся на экран. При выявлении ошибок возможен возврат к формам ввода правил для их коррекции. В случае, если ошибки выявлены не были, проводится интерпретация всего файла. Поскольку интерпретация может занимать большое время, ее выполнение вынесено в фоновый процесс, а web-интерфейс отображает лишь степень завершения и оценку оставшегося времени до окончания задачи.

2.4 Поиск и отображение информации

Запрос данных в BDB возможен либо с использованием идентификатора, либо при помощи поиска по параметрам. При поиске по идентификатору пользователь может выбрать систему идентификации из нескольких, включенных в BDB – ADS, Bayer, CCDM, DM, Flamsteed, GCVS, HD, HIP, IDS, IGR, Name, SBC9 или WDS, либо ввести идентификатор в свободной форме (выбрав систему Misc). В последнем случае BDB прежде всего попытается найти введенный идентификатор среди имеющихся в базе. Если найти идентификатор не удалось, будет сделан запрос (с использованием протокола SOAP) к системе Sesame (http://cds.u-strasbg.fr/cgi-bin/Sesame) и среди выданных ею результатов будет выбран идентификатор, имеющийся в BDB. Результаты запросов к Sesame кэшируются. После получения идентификатора:

1. BDB находит все записи (системы, пары или компоненты), ссылающиеся на данный идентификатор. Найденные записи включаются в список (здесь и далее в список включаются только ранее отсутствовавшие в нем элементы).

2. Для каждой найденной записи находятся (и также включаются в список) записи с тем же внутренним идентификатором, что и у нее (как было сказано выше, каждому объекту в BDB может соответствовать несколько записей, имеющих один внутренний идентификатор).

3. Если найденная запись относится к системам, то в список включаются все пары, ссылающиеся на нее. Для пары включаются в список оба ее компонента, а также система, на которую она ссылается. Для компонента в список включается его родительская пара.

4. Составляется список внешних идентификаторов, на которые ссылаются записи, найденные на предыдущих этапах.

Перечисленные этапы повторяются циклически для всех найденных идентификаторов до тех пор, пока формируемый список не перестанет расти. Полученный список отображается на странице, а также визуализируется при помощи Google Sky (http://www.google.com/sky/). Объекты, непосредственно ссылающиеся на запрошенный пользователем идентификатор, будут подсвечены. Для каждого отображаемого объекта приводятся значения заполненных полей. Например, если для пары известно значение периода, оно будет отображено. Если разные источники дают несколько разных значений периода для этой пары, все значения будут отображены. Кроме того, для каждого объекта отображаются все известные BDB идентификаторы. Дополнительно отображаются идентификаторы, получаемые через запросы к Sesame. Данные запросы производятся в фоновом режиме, и соответствующая информация отображается постепенно, по мере получения результатов.

Если пользователя заинтересуют еще какие-то объекты, кроме подсвеченных, он может выбрать их при помощи мыши. После чего, кликнув на кнопку [Next], пользователь может перейти к отображению данных из оригинальных каталогов. Поскольку каждая запись ссылается на конкретную строку в одном из файлов некоторого каталога, BDB может отобразить данные в исходном виде. Дополнительно показывается информация, извлеченная из файлов ReadMe исходных каталогов. Другим способом поиска данных в BDB является поиск по параметрам. Пользователь может выбрать один или несколько критериев поиска, например, указать диапазон орбитальных периодов, звездных величин и отметить эволюционный статус интересующих его звезд. При добавлении критерия автоматически отображаются его максимальное и минимальное значения, встречающиеся в базе. После нажатия кнопки [Search] на экране отображается таблица, включающая в себя идентификаторы найденных объектов (в виде кликабельных ссылок), а также значения всех непустых полей относящихся к ним записей. Объекты отсортированы по возрастанию величин для полей, по которым был сделан запрос. Нажав на идентификатор-ссылку, пользователь может получить данные так, как если бы он сделал запрос с этим идентификатором (см. выше).

По умолчанию отображаются первые 100 найденных объектов, однако пользователь может получать дополнительные результаты (порциями по 100 строк), нажимая кнопку [Next]. Содержимое таблицы может быть получено в виде текстового файла (с выравниванием колонок по позициям) нажатием на ссылку [download as text file]. В дальнейшем планируется добавление возможности получения данных в виде XML-файла, VOTable, а также в виде файла csv.

3. Система обозначений двойных

В каталогах двойных различных типов используются различные системы обозначений, поэтому мы должны разработать и ввести в употребление единую и согласованную систему обозначений объектов в БДБ. Создание такой системы представляет известную проблему, и удовлетворительного решения до сих пор найдено не было. Возможный подход, обладающий рядом преимуществ, представлен ниже.

Система обозначений должна удовлетворять следующим требованиям:

  • система должна корректно откликаться на открытие удаленного компонента;
  • система должна корректно откликаться на разрешение компонента на под-компоненты;
  • всякое имя должно быть присвоено только одному объекту;
  • всякий объект должен быть поименован только одним именем;
  • должна, по возможности, соблюдаться преемственность и согласованность с существующими, традиционными системами.

В соответствии с этими требованиями для каждого объекта в БДБ конструируется единый идентификатор, и с ним ассоциируются все оригинальные, каталогизированные имена объекта.

Для создания системы обозначений мы следовали рекомендациям Международного астрономического союза (МАС), а именно документу «IAU Specifications concerning designations for astronomical radiation sources outside the solar system». В качестве акронима используется аббревиатура «BSDB» (Binary Star DataBase). Практически все входные каталоги предоставляют экваториальные координаты объектов с достаточной точностью, поэтому идентификатор формируется на основе позиционной информации. Наконец, мы используем в идентификаторе спецификаторы для того, чтобы различать системы, пары и компоненты («s», «p» и «c», соответственно). Нам необходимо ввести эти три категории объектов, поскольку различные параметры могут описывать различные категории. Так, например, расстояние и кинематические характеристики описывают, как правило, «систему», орбитальные элементы – «пару» (при этом элемент пары не всегда является одиночной звездой), а астрофизические параметры (масса, радиус и пр.) – «компонент».

Для формирования обозначения мы используем экваториальные (J2000.0) координаты из каталогов, включаемых в БДБ. Точность каталогизированных координат позволяет сформировать эту часть идентификатора в формате HHMMSS.ss+DDMMSS.s или HHMMSS.ss-DDMMSS.s.

Например, кратная система, включенная в различные каталоги как CCDM 06410+0953, WDS 06410+0954 и TDSC 16013, в БДБ обозначается как BSDB J064058.66+095344.7:s. Отметим, что WDS- и CCDM-обозначения также базируются на координатах объектов, однако, они не удовлетворяют правилам МАС. Пара AB в этой системе обозначается как BSDB J064058.66+095344.7:pA-B (заметим, что знак «минус» используется здесь как разделитель для указания компонентов), а ее компоненты имеют идентификаторы BSDB J064058.66+095344.7:cA и BSDB J064058.66+095344.7:cB (несмотря на то, что координаты компонентов могут отличаться).

В нашей схеме мы, в общем, следуем WDS-системе для обозначения компонентов, однако заменяем строчные буквы и цифры на прописные буквы. Таким образом, для пары WDS 04331+2410Ab1,2 вводится идентификатор BSDB J043306.62+240954.9:pABA-ABB.

Предложенная схема распространяется на все наблюдательные типы двойных. Основные каталоги двойных различных типов (ОКПЗ и CEV для затменных, SB9 для спектроскопических и пр.) имеют координатную точность не хуже (а SB9 даже лучше), чем в WDS и CCDM. Заметим, что в случае SB9 (и аналогичных) для формирования идентификатора координаты, согласно правилам МАС, обрезаются, а не округляются.

Новый удаленный компонент системы, будучи открытым, получит в своем обозначении следующую свободную букву алфавита. Разрешение некоего компонента (например, B) на под-компоненты приведет к появлению двух новых идентификаторов для них, с буквами A и B в соответствующей позиции (то есть, BA и BB); при этом обозначение BSDB Jxxxxxx.xx+xxxxxx.x:cB для разрешенного компонента будет выведено из обращения, а для появившейся пары будет сформировано обозначение BSDB Jxxxxxx.xx+xxxxxx.x:pBA-BB.

4. Заключение

База данных BDB – ценный инструмент, потенциально весьма востребованный исследователями двойных звезд. В рамках BDB впервые будет собрана информация обо всех типах двойных звезд, проведена их кросс-идентификация, предоставлена возможность поиска как по идентификаторам, так и по параметрам. Для ее реализации впервые будет реализована непротиворечивая система идентификации двойных и кратных звезд BSDB, устойчивая к открытию новых компонентов у известных звезд и разрешению одиночных звезд на подкомпоненты. По запросу в BDB пользователь будет получать исчерпывающую информацию как о самой запрошенной звезде, так и о ее непосредственном окружении, что может быть полезно, например, при решении задач, связанных с определением эволюционного статуса объектов. Кроме того, запросив информацию об объекте, пользователь получит все имеющиеся данные, собранные за всю историю его наблюдения. Это может быть важно, например, для объектов, демонстрирующих переменность (т.е. практически для всех двойных звезд).

Для реализации BDB выбран фреймворк Nagare (http://www.nagare.org), написанный на языке stackless Python. Фреймворк Nagare основан на использовании продолжений (continuations) и прозрачным образом сохраняет значения переменных между перезагрузками страницы. Эта его особенность позволила существенно сократить размер программы и упростить ее по сравнению с традиционными web-приложениями. Для доступа к базе данных используется интегрированная в Nagare система ORM Elixir (http://elixir.ematia.de/), основанная на SQLAlchemy (http://www.sqlalchemy.org/), позволяющая работать с записями в базе данных как с объектами. Это позволило простым и логичным образом отобразить иерархические структуры кратных систем на таблицы СУБД (в данный момент используется PostgreSQL). Способность фреймворка Nagare прозрачно интегрировать в веб-страницы динамические элементы Ajax дало возможность обновлять часть информации на странице без ее полной перезагрузки, снижая нагрузку на сервер и делая работу интерфейса более плавной.

В настоящее время бета-версия BDB открыта для тестирования по адресу http://bdb.inasan.ru.

Литература

1. Oblak E., Debray B., Kundera T. BDB - a database for all types of double stars. Astronomical Data Analysis Software and Systems (ADASS) XIII, Proceedings of the conference held 12-15 October, 2003 in Strasbourg, France. Edited by Francois Ochsenbein, Mark G. Allen and Daniel Egret. ASP Conference Proceedings, Vol. 314. San Francisco: Astronomical Society of the Pacific, 2004, 217

2. Malkov O., Oblak E., Debray B., The Binary Star Database – BDB, 2009, in ADASS XVIII Conference, eds. David Bohlender, Daniel Durand, Patrick Dowler, Quebec, Nov 2008, ASP Conf. Ser., 411, 442

3. Kaygorodov P., Debray B., Kolesnikov N., Kovaleva D., Malkov O., The new version of Binary star database (BDB), 2012, Baltic Astronomy, 21, 309

4. Malkov O.Yu., Kaygorodov P.V., Kovaleva D.A., Oblak E., Debray E. «Binary star database BDB: datasets and services», 2013, Astronomical and Astrophysical Transactions, in press

5. Скворцов Н.А., Малков О.Ю., Кайгородов П.В., Ковалева Д.А. Подход к разработке базы данных двойных звёзд (BDB). 2012, В сб.: Информационные системы для научных исследований. Труды XV Всероссийской объединенной конференции "Интернет и современное общество". Санкт-Петербург, 10-12 октября 2012 г., 107-117.

6. Ochsenbein F., Standards for Astronomical Catalogues, Version 2.0, 2000, http://cdsweb.u-strasbg.fr/vizier/catstd/catstd-3.1.htx

Благодарности:

Авторы благодарят Эдуарда Облака (Edouard Oblak) и Бернара Дебрэ (Bernard Debray) за сотрудничество и ценные замечания, а также за их вклад в создание BDB. Работа выполнена при поддержке РФФИ (грант 12-07-00528), Программы Президиума РАН «Поддержка ведущих научных школ» (грант НШ-3602.2012.2), а также в рамках реализации ФЦП "Научные и научно-педагогические кадры инновационной России" на 2009 - 2013 годы. В процессе работы были использованы базы данных Simbad, ADS, WDS, GCVS, SB9 и VizieR, каталоги CCDM и TDSC, а также сервис CDS Sesame.

Об авторах

П. Кайгородов – ИНАСАН, руководитель группы программного обеспечения и вычислительной техники; e-mail: pasha@inasan.ru

О. Малков - ИНАСАН, руководитель отдела физики звездных систем;

О. Длужневская – ИНАСАН, руководитель группы Центр астрономических данных;

Д. Ковалева - доктор технич. наук, профессор, Научный Центр аэрокосмических исследований Земли ИГН НАН Украины, Киев, Украина;



Последнее обновление страницы было произведено: 2014-02-27

Все предложения и пожелания по содержанию и структуре портала направляйте по адресу rdlp@iis.ru