Мировая орбитальная группировка: сколько их?

[Игорь Борисович Степанов]

Liss пишет:
 
Да, печальная картина. А у Баканова нереально узнать, который номер в американском каталоге соответствует спутнику, который Ваша структура призвана защищать? Он-то не может этого не знать, так как имеет расписание пролетов и сеансов связи через него...

Нет у меня выхода на президента ОАО "Спутниковая система "Гонец". Попробую, конечно, через своё руководство, но не факт ...

[Старый]

Боюсь что ситауция такова что наши космические начальники не только не знают какой номер присвоен их аппаратам в американском каталоге, но и не знают о самом существовании американского каталога.

[Старый]

Вобщем, джентльмены, как я понимаю вы хотите сделать базу типа как сделано на хэвенсэбаве?
То есть в поле "что вы хочите?" вводишь "все запуски" или там "только с выходом на орбиту", в поле "что показывать по каждому запуску?" вводишь "только основные КА" или "все КА" или "КА и ракетные ступени" или "все объекты" потом, под заглавием "показывать" ставишь флаги в окошках "дату" "время" "апогей" "перигей" "космодром" "площадка", жмёшь кнопку "Поехали!" и бац - таблица на экране? 

[ОАЯ]

Уважаемый, Старый! Я здесь самый малопонимающий, но мне кажется, интерфейс, хотя и важная часть БД, и самая интересная, но я думаю сейчас до этого очень далеко. Надо просто молиться на GK и потакать всем его запросам, что бы наконец началось заполнение таблиц БД. 

Может быть главными таблицами с индексами задающими поиск сделать "объекты"? И растащить по времени периода орбиты по таблицам? Например: Период от 0 до 20 минут, 15 минут до 35, от 25 до 40, от 35 до 55 и т.д. Тогда для поиска низкоорбитальных достаточно проверить три таблицы, и т.д. И сделать две таблицы для маневрирующих объектов: до года и свыше? Получится громоздко, но зато получится однозначность и простота связанности между таблицами.

[peery]

G.K. пишет:

ОАЯ пишет:
Для нашего случая очень важно найти, что будет служить индексом для всех таблиц.

Это сложный вопрос. Мне кажется, что у нас будет свой столбец ID, поскольку ни NORAD номер, ни какое-то закрытое военное обозначение не годится. Первое из-за невыдаваемых публично американцами КА, а второе- потому что военное.

ID однозначно свой по очень простой причине - ни одна из существующих в мире систем учёта объектов, доступных ПУБЛИЧНО, не обеспечивает уникальность адресации  (ссылки) на конкретный объект или событие. Объекты, каталогизированные КК ВВС США, - наглядный тому пример:
1) без изменения каталожного номера и международного обозначения могут легко и по-тихому "обменять" орбиты между физически разными объектами  (особенно в запусках, где есть много объектов)
2) каталожный номер и орбита сохраняется, меняют международное обозначение (это, как правило, для фрагментов, после пересмотра решения об источнике образования)
3) каталожный номер сохраняется, международное обозначение и орбита изменяются; тем самым, объект, по которому выдавалась орбита до этого, вообще пропадает из учёта
и т.д.
В каждом из этих случаев под одним и тем же идентификатором в базе образуется либо "смесь" орбитальных данных, либо смесь наименований и других характеристик, относящихся к физически разным объектам

Таким образом, для ведения собственного учёта нужен свой ID и далее некие построения в модели, позволяющие отслеживать соответствие этого ID идентификаторам в других системах учёта (замечу, это далеко не простая задача)

[peery]

ОАЯ пишет:
Уважаемый, Старый! Я здесь самый малопонимающий, но мне кажется, интерфейс, хотя и важная часть БД, и самая интересная, но я думаю сейчас до этого очень далеко. Надо просто молиться на GK и потакать всем его запросам, что бы наконец началось заполнение таблиц БД.

Может быть главными таблицами с индексами задающими поиск сделать "объекты"? И растащить по времени периода орбиты по таблицам? Например: Период от 0 до 20 минут, 15 минут до 35, от 25 до 40, от 35 до 55 и т.д. Тогда для поиска низкоорбитальных достаточно проверить три таблицы, и т.д. И сделать две таблицы для маневрирующих объектов: до года и свыше? Получится громоздко, но зато получится однозначность и простота связанности между таблицами.

Уважаемые форумчане! Прошу ещё раз обратить внимание на мою просьбу - посмотрите критически перечень предложенных атрибутов, которые предполагается хранить в базе, и скажите, чего не хватает, на ваш взгляд. Также попытайтесь каждому атрибуту (ну кроме совершенно очевидных) дать определение. Эти определения будут положены в основу правил, по которым будет осуществляться заполнение базы, контроль целостности данных и отображение данных в пользовательском интерфейсе. Правила эти нужно программировать и поэтому если не будет согласованных определений, то не будет правил и не будет базы.

Вопрос к Liss'у - можно ли для удобства собрать мои посты с предложенным описанием модели в какое-то одно место, чтобы было удобно читать и не искать по всей ветке? Но чтобы правки по результатам обсуждения вносить могли, скажем, только я и G.K.?

Что касается ВНУТРЕННИХ идентификаторов (не видимых, как правило, пользователю в интерфейсе), обеспечивающих целостность данных, то я предлагаю здесь не обсуждать этот аспект - это точно не для данной ветки форума, а для тех, кто будет реально заниматься реализацией модели в виде программного продукта. Если что - по этому вопросу предлагаю писать сообщения мне и G.K., чтобы не заваливать данную ветку чисто программистскими аспектами. 

А вот правила формирования  ПОЛЬЗОВАТЕЛЬСКИХ идентификаторов запусков - это как раз нужно обсудить. Брать ли за основу подход, используемый Джонатаном, с внесением каких-либо дополнений (или без оных)? Также если у кого-то есть какие-то соображения по идентификаторам объектов (помимо самого простого и очевидного - использовать последовательность положительных целых чисел), то тоже можно обсудить. В том числе это касается и "международных обозначений". Должны ли они охватывать объекты аварийных запусков? 

Какие объекты аварийных запусков вообще должны быть внесены в базу - только КА или все (исключая, скажем, фрагменты) объекты, которые образовались бы на орбите, если бы запуск прошёл успешно? Спрашиваю потому, что в т.н. "аварийных орбитальных" запусках (т.е. когда на орбите что-то образовалось, но орбита не та, КА не отделились и т.п.) для каждого составного объекта в базе будут храниться записи по каждому "индивидуальному" объекту, входящему в состав основного.

[peery]

G.K. пишет:

peery пишет:
В общем и целом скелет модели я набросал, жду комментариев, замечаний и предложений.

Ну свои идеи я накидал.

Предложение одно- максимально уйти от реальной СУБД ( того же аксесса, коли мы о нём заикнулись), ибо Старый его просто не потянет. А с клиентом есть небольшой шанс.

Уйти, я думаю, не получится, поскольку в этом случае придётся поступить как Джонатан МакДауэлл - написать свой обработчик системы текстовых файлов определённого формата и свою систему контроля целостности данных в этой системе. А это уже "доморощенная" СУБД. 

Мне кажется, нужно сделать так. Определиться со структурой данных и всеми правилами, описать всё это на SQL, потом выбрать СУБД (Postgres, на мой взгляд, был бы оптимальным), реализовать структуру там и прикрутить к ней веб-интерфейс. Поставить всё это хозяйство где-то на постоянно работающем сервере (найдём) и далее организовать процесс следующим образом:
- все пользователи (должны ли они регистрироваться, кстати?)  могут отбирать из базы и выгружать нужные им данные с помощью интерфейса, проводить анализ и формировать свои замечания/пожелания/предложения
- сформированные замечания/пожелания/предложения выкладывать на тот же сервер в том же веб-интерфейсе (посредством специальной формы)
- наиболее опытные (в части работы с программными комплексами) пользователи из числа форумчан будут отрабатывать эти пожелания (после обсуждений на форуме, если возникнут вопросы), а также заносить в баз данные о новых объектах и событиях (правила занесения данных тоже нужно будет обсудить, чтобы не возникло дублирующихся записей и т.п.)
- орбитальные данные - отдельная песня, нужно будет иметь автоматизированный процесс, но с предварительным контролем данных оператором до записи в базу

[peery]

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

Т.е. Вы предлагаете иметь в базе следующие атрибуты:
- наименование на языке заказчика (так, наверное, правильно, потому что производитель производит то, что ему заказали)
- наименование по-русски

С транскрипцией не понял. Имеется в виду фонетическая транскрипция? Т.е. графическая запись звучания слова?

Во-вторых я или просмотрел или его нет, это мое любимое место расположение оператора КА(кнопки), в-третьих в списке тех кто хотел полететь, но неполетел нужно включить все проекты , которые имели хоть какое-нибудь материальное воплощение, если что извиняюсь за надоедливость.

Действительно, пока не было. Поскольку "оператор" (я кстати задал вопрос - кто такой "оператор" - и пока никто не прореагировал) для одного и того же КА может меняться, то все записи об "операторах" будут в отдельном блоке со ссылкой на блок с информацией по КА.

И не нужно извиняться! Это же процесс обсуждения. Главное, чтоб не зацикливаться на чём-то одном 

[peery]

G.K. пишет:

ОАЯ пишет:
 Но мы то с вами инженеры, черт возьми

Каждый раз писать всё это достаточно неудобно. Можно оставить возможность задания произвольного запроса, но типовые должны быть реализованы заранее.

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

Также согласен, что можно составить и реализовать ограниченный перечень типовых запросов и поместить его в интерфейс.

[ОАЯ]

[ОАЯ]

Если против - удалю рисунок

[peery]

ОАЯ пишет:
Если против - удалю рисунок

Общий подход обеспечения ссылочной целостности - он всегда такой, вот только плодить несколько таблиц в базе для описания одних и тех же сущностей не просто не следует, а категорически нельзя - целостность такой базы поддерживать в практическом плане (на программном уровне) не реально. Точнее, всё можно сделать, но какой ценой и, главное, зачем? Поэтому давайте отойдём от обсуждения программной реализации и оставим это тем, кто будет ей заниматься, как я уже предложил выше, поскольку существует масса практически реализованных решений, как это сделать. Давайте вернёмся к сущностям и будем обсуждать их - там всё намного сложнее (пока, по крайней мере).

[ОАЯ]

Этот рисунок не только иллюстрация идеологии базы данных для таких как я. В каждой таблице должен быть индекс. Я думаю, Вы с этим согласны. В первых 10 таблицах он должен задаваться. Я так и предлагаю - любому отдельному объекту (боковушке, КА...) назначать свой ID номер. 

Затем создавать отдельные таблицы по космодромам, номерам регистрации, носителям без повторов сущностей, как Вы их назвали. Только связь между таблицами через ID номера.

Нпример. После пуска Союза на орбите остались: боковушка ID111111, КА ID111112, переходное кольцо ID111113. В таблице место запуска будут три записи (строчки с этими ID номерами). И в таблице регистрации тоже три строчки с ними. Но повторов про параметры, названия, наклонения и пр. там не будет. Все раскидано по своим таблицам и только ID номер связывает их. 

Поиск:  Набираем номер КК ВВС США. Компьютер находит этот параметр в таблице регистрации, находит номер КК ВВС США, по нему ID номер и зная его, находит все строчки с этим номером по всем таблицам. И выдает полную информацию по номеру КК ВВС США: объект, космодром, дата начала проекта...
.

[peery]

ОАЯ пишет:
Этот рисунок не только иллюстрация идеологии базы данных для таких как я. В каждой таблице должен быть индекс. Я думаю, Вы с этим согласны. В первых 10 таблицах он должен задаваться. Я так и предлагаю - любому отдельному объекту (боковушке, КА...) назначать свой ID номер. 

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

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

Нормализацию структуры нужным образом мы проведём, уж поверьте - опыт в этом большой.

Поэтому я и предлагаю обсудить в первую очередь концептуальную модель.

Также замечу, что обычный пользователь никогда не будет видеть физическую структуру хранения данных, поскольку она ему не нужна (каике ключи, сколько их и т.д. - это нужно только тем, кто программирует структуру БД). Даже задачи, которые будут формировать и запускать запросы из интерфейса, не будут видеть эту структуру, поскольку она будет закрыта виртуальными (логическими) таблицами, т.н. представлениями (view).  

Затем создавать отдельные таблицы по космодромам, номерам регистрации, носителям без повторов сущностей, как Вы их назвали. Только связь между таблицами через ID номера.

У меня большая просьба - ещё раз внимательно посмотрите то описание концептуальной модели, которое я предложил несколькими страницами ранее. Там так всё и устроено. Нужно понять, ничего ли не пропущено, и сформулировать определения для атрибутов.

[ОАЯ]

Я Вашу концепцию и использовал. Только мне показалось, что поточное индексирование ВСЕХ объектов логичнее, чем разделение объектов по функции. Но Вам виднее. Хотел только прореагировать на призыв провести ликбез на конкретном примере. Остальные же вообще молчат.

[ВВК]

peery пишет:
С транскрипцией не понял. Имеется в виду фонетическая транскрипция? Т.е. графическая запись звучания слова?

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

[ОлегЗайцев]

Предлагаю параллельно создавать на базе имеющейся в базе информации создать подобие информационно-справочного ресурса (подобного wikipedia), в котором можно будет хранить данные, которые плохо ложатся на предлагаемую  peery  реляционную структуру. Например если страница википедии имеет специальное форматирование из нее возможно извлекать информацию , подобно получению выборки из бд. Пример на странице http://dbpedia.org/page/USA-230 приведена структурированная информация по объекту.

[ВВК]

peery пишет:
Т.е. Вы предлагаете иметь в базе следующие атрибуты:
- наименование на языке заказчика (так, наверное, правильно, потому что производитель производит то, что ему заказали)
- наименование по-русски

Наверно ещё раз , немного подумав, так про язык заказчика и по-русски, да и про транскрипцию, короче есть оригинальное название, может быть название под которым оно занесено в каталоги, произношение по-русски это ещё одно, и есть перевод  на русский.  Например  КА Sentinel по-русски звучит Сентинель, а перевод Страж. Первое это название на языке заказчика(МО Франции) или страны производителя, под ним оно наверно входит в разные каталоги, второе нужно для понимания правильности произношения, а третье дает сразу представление о нем, т.к. перевод. И вроде в данном случае они все интересны, т.к. они дополняют друг и как бы могут употребляться равнозначно. А вот всякие там Intelsat, SES, Astra вооще переводить не стал, а то чего доброго можно подумать что какой-то отечественный аппарат, а латинские буквы у нас почти все кто в школе учился знают.

[ОАЯ]

Старый пишет:
Вобщем, джентльмены, как я понимаю вы хотите сделать базу типа как сделано на хэвенсэбаве?
То есть в поле "что вы хочите?" вводишь "все запуски" или там "только с выходом на орбиту", в поле "что показывать по каждому запуску?" вводишь "только основные КА" или "все КА" или "КА и ракетные ступени" или "все объекты" потом, под заглавием "показывать" ставишь флаги в окошках "дату" "время" "апогей" "перигей" "космодром" "площадка", жмёшь кнопку "Поехали!" и бац - таблица на экране?

так-то так, но при очень широком запросе "Все запуски" система может надолго зависнуть, т.к. данных должно быть очень много. А если еще по каждому показывать дату, данные орбиты, ссылки на интернет, то мы все будем знать кто свалил базу данных

[G.K.]

Старый пишет:
То есть в поле "что вы хочите?" вводишь "все запуски" или там "только с выходом на орбиту", в поле "что показывать по каждому запуску?" вводишь "только основные КА" или "все КА" или "КА и ракетные ступени" или "все объекты" потом, под заглавием "показывать" ставишь флаги в окошках "дату" "время" "апогей" "перигей" "космодром" "площадка", жмёшь кнопку "Поехали!" и бац - таблица на экране?

Ну я бы хотел именно так. Во всяком случае один проект (базу TLE ) делали именно так. Удобно, работает.