Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 21
я так понимаю Вам придется не только структуризировать информацию, но и заодно попытаться навести порядок в каталогах?
А так — я бы начал строить структуру снизу- вверх. Ввести атомарное понятие — так понимаю, что у Вас это одна звезда. Звезды группируются в следующий агрегат — двойная. Двойные в свою очередь идут в кратную систему. Да?
Точнее я даже предположить пока не могу.
Теперь по поводу каталогов. Можно сделать элементарную структуру —
таблицаТиповКаталогов (id, наименование)
таблицаЗначений(id, типКаталога, свойство, значение)
Ну и рюшки в зависимости от специфики.
Прошу сильно ногами не пинать — ибо ни разу не DBA а так, иногда сталкивающийся.
А так — я бы начал строить структуру снизу- вверх. Ввести атомарное понятие — так понимаю, что у Вас это одна звезда. Звезды группируются в следующий агрегат — двойная. Двойные в свою очередь идут в кратную систему. Да?
Точнее я даже предположить пока не могу.
Теперь по поводу каталогов. Можно сделать элементарную структуру —
таблицаТиповКаталогов (id, наименование)
таблицаЗначений(id, типКаталога, свойство, значение)
Ну и рюшки в зависимости от специфики.
Прошу сильно ногами не пинать — ибо ни разу не DBA а так, иногда сталкивающийся.
да, я так тоже сначала подумал. И даже сделал пробную версию, которая работала. Но. Нет смысла хранить все значения в таблицах. Поиска по ним нет (по подавляющему большинству, по крайней мере), а самих значений очень много. Таблица с ними (даже если хранить только непустые ячейки) перевалит за несколько миллионов записей. По моему, это немного перебор.
Далее — не всегда в базе будет существовать звезда, как атомарное понятие. Большая часть каталогов оперирует парами. Причем иногда пара может состоять только из одной звезды, поскольку по второй звезде нет данных. Но точно известно, что звезда — член пары. А есть еще кратные системы. Как все это уложить в таблицы — не ясно :(
Далее — не всегда в базе будет существовать звезда, как атомарное понятие. Большая часть каталогов оперирует парами. Причем иногда пара может состоять только из одной звезды, поскольку по второй звезде нет данных. Но точно известно, что звезда — член пары. А есть еще кратные системы. Как все это уложить в таблицы — не ясно :(
Поддерживаю OldFornit. Если я верно понял, то по сути у нас есть одна сущность — звезда. Звезды могут объединятся в пары. Также эти звезды заносятся в каталоги. Надо определится, что заносить в каталоги — звезды или пары.
Создаете некую сущность, которая будет хранить все характеристики каждой звезды. Создаете сущность, которая будет описывать связи звезд — просто две колонки с идентификаторами звезд. Для неизвестных предусмотреть специальную отметку в связях либо использовать NULL и правильно его интепретировать программно (что предпочтительнее).
А каталоги — это просто наборы идентификаторов наших звезд. Весь поиск будет сводится к поиску по таблице звезд и таблице связей звезд.
Для связывания с внешними каталогами надо определится с глобальным первичным ключем, который однозначно идентифицирует звезду во всем мире и желательно во все времена (я так полагаю, у звезд есть некоторые кодированные названия, которые включают дату открытия или какой-то уникальный номер). Для импорта внешнего каталога необходимо будет используя глобальный уникальный идентификатор найти повторы (обновить их, если необходимо), добавить новые звезды, определить идентификаторы в нашей БД, обновить таблицу связей между звездами и создать новую таблицу для каталога внеся в нее наши внутренние идентификаторы.
Вроде все.
Создаете некую сущность, которая будет хранить все характеристики каждой звезды. Создаете сущность, которая будет описывать связи звезд — просто две колонки с идентификаторами звезд. Для неизвестных предусмотреть специальную отметку в связях либо использовать NULL и правильно его интепретировать программно (что предпочтительнее).
А каталоги — это просто наборы идентификаторов наших звезд. Весь поиск будет сводится к поиску по таблице звезд и таблице связей звезд.
Для связывания с внешними каталогами надо определится с глобальным первичным ключем, который однозначно идентифицирует звезду во всем мире и желательно во все времена (я так полагаю, у звезд есть некоторые кодированные названия, которые включают дату открытия или какой-то уникальный номер). Для импорта внешнего каталога необходимо будет используя глобальный уникальный идентификатор найти повторы (обновить их, если необходимо), добавить новые звезды, определить идентификаторы в нашей БД, обновить таблицу связей между звездами и создать новую таблицу для каталога внеся в нее наши внутренние идентификаторы.
Вроде все.
вся проблема в том, что разные каталоги оперируют разными понятиями. Где-то хранятся «звезды», с неким полем, по которому их можно объединить в «системы». Тут все понятно. Где-то каждая запись — это «пара», таких — подавляющее большинство. Причем звезда X может в одном каталоге быть в паре со звездой Y, а в другом — со звездой Z. Или она может входить в несколько пар в одном каталоге (это вообе типично для визуальных двойных). В паре может быть информация только об одной звезде и, скажем, об орбитальном периоде пары. Одна и та же звезда может быть в одном каталоге описана как член пары, а в другом — как одиночная (например, ее компаньен не был открыт на момент выпуска одного из каталогов).
почему бы не посмотреть структуру БД уже существующих аналогичных каталогов звезд?
А эта база как, представляет интерес для астрономов-любителей? Если её воможно в свободный доступ открыть, то можно тогда организовать open source (точнее, free software) сообщество и сделать хорошо и красиво для всех.
Э… Такая идея мне приходила в голову, но тут есть два возражения. Первое — система очень специфична. Ее пользователи практически гарантированно не захотят участвовать в разработке. Фактически, астрофизикой двойных звезд занимается не так много людей и многих из них я знаю :) Второе — я лично не готов брать на себя организацию разработки opensource-проекта. Нет ни времени, ни призвания для этого. Я могу написать код и вяло поддерживать его следующие -дцать лет, но это максимум, что я готов сделать для этого проекта :)
кстати, сама база будет в открытом доступе, разумеется.
Ну для начала надо определить объекты. Таблица объектов, таблица систем со ссылками на объекты. В каждой таблице свои id. Видимо для неопознанных надо ввести служебную запись типа id=0, name=«Unkown». И вводить ее если ничего не известно и ни в каких каталогах невидимой звезды нет. Ежели есть хоть что-то — заводить с пустыми полями.
Каталоги. Я бы сделал отдельными таблицами. Поля пересекаются слабо, для поиска придется писать свои запросы, так что проще иметь их разными для разных каталогов.
Кросс таблицы придется переделать в ссылки на объект или систему в поле в каталоге. Если там есть неопределенность или нельзя однозначно сопоставить, то надо детали что бы что-то советовать. И да, всю идентификацию объекта в каталоге выносим в таблицы объектов или систем — название или номер в реестре. Оставляем только ссылку. Если систем идентификации много и они разные — каждую выносим в отдельную таблицу, ссылающуюся на таблицу объектов.
Добавление каталога — новая таблица.
select stars.* from stars join position_catalog as p on (p.id=stars.id) where distance(p.position,point)<radius
ну что там с координатами, которые я условно написал как p.position и point я как считать растояние думаю разберетесь :)
для сотен тысяч наверно можно впрямую считать.
по приколу пусть тип будет в type_catalog, ссылающая на звезду, а период в period_catalog ссылающая на систему
звезда stars.id есть в systems.star_id ( строка в которой — звезда )
select stars.* from stars join systems as s on (s.star_id=stars.id)
join type_catalog as t on (t.id=stars.id)
join period_catalog as p on (p.id=s.id)
where t.type='T Tau' and p.period<10*86400
ну конечно константы надо бы тоже как-то утилизировать — либо реф.таблицы либо enum
все ссылочные поля конечно надо индексировать и желательно поставить на них constraint.
Поля для поиска в каталогах — тоже индексировать только не уникально.
Каталоги. Я бы сделал отдельными таблицами. Поля пересекаются слабо, для поиска придется писать свои запросы, так что проще иметь их разными для разных каталогов.
Кросс таблицы придется переделать в ссылки на объект или систему в поле в каталоге. Если там есть неопределенность или нельзя однозначно сопоставить, то надо детали что бы что-то советовать. И да, всю идентификацию объекта в каталоге выносим в таблицы объектов или систем — название или номер в реестре. Оставляем только ссылку. Если систем идентификации много и они разные — каждую выносим в отдельную таблицу, ссылающуюся на таблицу объектов.
Добавление каталога — новая таблица.
найти все звезды в определенном радиусе вокруг точки на небесной сфере
select stars.* from stars join position_catalog as p on (p.id=stars.id) where distance(p.position,point)<radius
ну что там с координатами, которые я условно написал как p.position и point я как считать растояние думаю разберетесь :)
для сотен тысяч наверно можно впрямую считать.
звезды типа T Tau, с периодами <10 дней
по приколу пусть тип будет в type_catalog, ссылающая на звезду, а период в period_catalog ссылающая на систему
звезда stars.id есть в systems.star_id ( строка в которой — звезда )
select stars.* from stars join systems as s on (s.star_id=stars.id)
join type_catalog as t on (t.id=stars.id)
join period_catalog as p on (p.id=s.id)
where t.type='T Tau' and p.period<10*86400
ну конечно константы надо бы тоже как-то утилизировать — либо реф.таблицы либо enum
все ссылочные поля конечно надо индексировать и желательно поставить на них constraint.
Поля для поиска в каталогах — тоже индексировать только не уникально.
вот от заведения новых таблиц при добавлении каталогов хотелось бы уйти. Тем более, что это не так сложно — поиск все равно будет идти по ограниченному набору полей, которые (пусть даже насильно), но будут у всех записей. А остальные поля можно хранить хоть простой текстовой строкой и парсить при выводе. Проблема в другом. Есть, скажем, звезда из трех компонент. Две из них — спектральная двойная (не разделяемая визуально), одна из звезд не видна. Третий компонент — одиночная звезда, обращающася вокруг двойной на приличном расстоянии. Как такой объект красиво запихать в базу?
Hemul ↑: от заведения новых таблиц при добавлении каталогов хотелось бы уйти
Куда? Можно вести одну здоровую, можно ввести нечто генерализованное, но по моему это все будет хуже. Большая таблица будет ворочаться хуже — поскольку размер строки таки важен для кэширования и в конце концов для скорости выборки и не стоит его делать слишком большим.
И да, запись для звезды и для системы должны быть, по идее разные. Хотя конечно можно и закрыть глаза или повторять значения… но зачем все это?
Если хочется унифицировать поиск, то можно сделать view в который подключить все каталоги через left join. Но видимо все равно придется разделять звезды и системы.
Тут еще надо посмотреть как будут обновляться каталоги. Если например в каждый каталог с разной частотой приходят дополнения или изменения. Или в базе понадобиться ввести какие-то метаданные или связи ( например авторы или юзеры с правами на изменения ) отдельно для каталога, то так или иначе придется разделять их.
Есть, скажем, звезда из трех компонент.
Можно завести 3 звезды, можно и 2 в системе — вопрос лишь в том зачем плодить сущности. Если двойная во всех отношениях, то есть по всем параметрам, проходит в каталогах как одиночная с хитрым спектром — то тогда остается причина только идеологическая, как например стройность кода ;) Но если например в классификации ее лучше ( удобнее для представления в UI или код будет проще ) представить как две звезды со своими спектрами и стандартными типами, то конечно лучше в системе прописать 3 звезды.
на вскидку:
1. таблица звезд с базовыми параметрами — класс, спектр, координаты, etc.
2. таблица двойных (кратных) систем — здесь название и какие-то общие параметры системы
3. таблица связей — звезд с системами, сюда же можно добавить поля обязательных параметров связей, например период обращения, какая звезда является главной и т.д.
4. Опционально — табличка с необязательными параметрами. Можно ее до кучи формализовать например в виде ключ-значений, и создать вспомогательную таблицу связей основных таблиц с таблицей доппараметров.
у всех табличке, кроме таблицы связей — уникальные, генерируемые базой первичные ключи, по ним и связывать таблицы. Это не отменяет необходимость наличие естественных уникальных ключей — например название звезды, которые будут использоваться при заливке новых каталогов, но позволяет не заморачиваться с формализацией этих ключей
Если в двойной звезде не указана одна из звезд — значит заводим в каталоге звезд — дефолтную звезду-шаблон.
В таблички хорошо бы добавить поле достоверности информации, чтобы помечать при первичном ипорте записи требующие уточнения информации. До кучи можно создать пару таблиц хранящих историю обсуждения и уточнения информации пользователями системы, чтобы можно было комментарии по ходу уточнения хранить.
PS. Больших таблиц особо бояться не стоит, 10-20-30 млн. записей это ерунда для современных БД =))
У меня тут под боком оракловые базы на полмиллиарда новых строк в месяц и ничо, работает все =).
1. таблица звезд с базовыми параметрами — класс, спектр, координаты, etc.
2. таблица двойных (кратных) систем — здесь название и какие-то общие параметры системы
3. таблица связей — звезд с системами, сюда же можно добавить поля обязательных параметров связей, например период обращения, какая звезда является главной и т.д.
4. Опционально — табличка с необязательными параметрами. Можно ее до кучи формализовать например в виде ключ-значений, и создать вспомогательную таблицу связей основных таблиц с таблицей доппараметров.
у всех табличке, кроме таблицы связей — уникальные, генерируемые базой первичные ключи, по ним и связывать таблицы. Это не отменяет необходимость наличие естественных уникальных ключей — например название звезды, которые будут использоваться при заливке новых каталогов, но позволяет не заморачиваться с формализацией этих ключей
Если в двойной звезде не указана одна из звезд — значит заводим в каталоге звезд — дефолтную звезду-шаблон.
В таблички хорошо бы добавить поле достоверности информации, чтобы помечать при первичном ипорте записи требующие уточнения информации. До кучи можно создать пару таблиц хранящих историю обсуждения и уточнения информации пользователями системы, чтобы можно было комментарии по ходу уточнения хранить.
PS. Больших таблиц особо бояться не стоит, 10-20-30 млн. записей это ерунда для современных БД =))
У меня тут под боком оракловые базы на полмиллиарда новых строк в месяц и ничо, работает все =).
да, видимо, в итоге так и сделаю. Только вместо ссылки на «дефолтную звезду» просто будет NULL, тем более, что это не нарушает foreign keys.
я думаю, что CWN имел ввиду, что «дефолтная» звезда для неизвестного компаньона всегда создается при заведении записи о паре.
NULL не удачный выбор, для неизвестной звезды в таблице связей все равно придется запись создавать. А так создаете по шаблону некую запись для неизвестной звезды (для каждой неизвестной свою) и ставите признак необходимости уточнения — вдруг ее найдут, или она уже есть в других каталогах.
Еще советую для порядка завести таблицы-справочники на которые будете ссылаться в основных таблицах — это упростит код в итоге.
Еще советую для порядка завести таблицы-справочники на которые будете ссылаться в основных таблицах — это упростит код в итоге.
Как в итоге сделали-то? :-)
решили не мудрить :)
Есть таблица для систем (задает опорные координаты для «главной» звезды системы), на систему ссылается одна или несколько записей в таблице для «пар», а на «пару» могут ссылаться записи из таблицы «компонент», описывающие «одиночные» звезды. Получилось немного некрасиво, так как для существенной части каталогов порождаются тысячи записей «система-пара», ссылающихся на одну и ту же строку исходного каталога (и ничего больше), но это можно пережить.
Сейчас идет наполнение системы данными и отладка интерфейса, кроме того у нас внезапно возникли большие проблемы с кросс-идентификацией (не программистского плана), но мы собираемся все решить и выкатить базу в открытый доступ в течение месяца.
Есть таблица для систем (задает опорные координаты для «главной» звезды системы), на систему ссылается одна или несколько записей в таблице для «пар», а на «пару» могут ссылаться записи из таблицы «компонент», описывающие «одиночные» звезды. Получилось немного некрасиво, так как для существенной части каталогов порождаются тысячи записей «система-пара», ссылающихся на одну и ту же строку исходного каталога (и ничего больше), но это можно пережить.
Сейчас идет наполнение системы данными и отладка интерфейса, кроме того у нас внезапно возникли большие проблемы с кросс-идентификацией (не программистского плана), но мы собираемся все решить и выкатить базу в открытый доступ в течение месяца.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
База данных по двойным звездам