Всем привет.
Поставили задачу создать БД пусков ракет. Почитав основы, наглядевшись и поизучав примеры структур блогов, интернет-магазинов и прочего решил приступить к проектированию, но в процессе столкнулся с трудностями.

Имеются следующие данные:
Есть 3 вида ракет на которых запускают спутники. Пуск ракеты контролируется датчиками которые снимают ряд параметров (давление в камерах, температура в отсеках, координаты и пр.). Параметров 1000 шт. на каждую ракету, их список точно известен. Параметры сгруппированы по системам (200 параметров по системе управления, 250 - по двигателям, 100 - по системе навигации и тд.) От пуска к пуску различается только информация снятая с этих параметров. Также есть таблица с замечаниями. Замечания могут быть как к системе в целом так и к параметрам (например температура по параметру "темп128" вышла за допустимые пределы).

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

Пока вижу такие таблицы:

Проблемы:
1. Большая таблица с данными параметров (3ракеты*20пусков*1000параметров). Как бы ее разбить на три таблицы для каждой ракеты?
2. Что-то не догоняю как сделать таблицу с замечаниями к системе на определенном пуске.
3. Общая проблема - кажется слишком много пересечений данных.
4. Ну и в целом хотелось бы услышать какие-нибудь рекомендации и советы общего плана.

Спасибо!

SERG1257Определите что значит "пересечение данных" и почему вы видите в этом проблему.

Если посмотреть на диаграмму связей, то видна "зацикленность". Не знаю как объяснить, но вижу что что-то тут не так))) Ощущение, что в процессе добавления данных возможна какая-то коллизия. Не видел схем с похожей замкнутостью таблиц. Может это и нормально, не знаю.

miksoftПри каждом пуске каждый параметр имеет не более одного значения? Или может быть много значений?
В данном случае данные параметра это не делимая единица - массив байт, 200-500Кб каждый параметр.

ВМоисеев, не, Excel не катит. Нужна БД с вебмордой.

Всем спсибо, буду потихоньку переваривать написанное.

experience, не понял, время ЧЕГО? Данные параметра в чистом виде это двумерный массив момент_времени-значение_параметра. в таблице данных параметра будет храниться этот массив в хитро сжатом виде, т.е. в []byte

ВМоисеев, что касается значений параметров, то я уже описал выше, значения параметра нужны именно в виде байтового среза. а описанный вами вариант про хранение сжатых файлов excel можно применить к хранению документов пуска/ракеты/параметра

ВМоисеев>ВМоисеев, сегодня, 11:34 [20350049]
Так Вы хотите хранить необработанные битовые строки (телеметрию), содержащие значения всех параметров в момент опроса (сеанса)?
Ба, да Вы "сырец" хотите хранить. В своё время "обсасывали" идею заменить дискретность функцией или сплайном.
Если Ваш выбор данность, то запись всех параметров запуска последовательно в файл, упаковка его и запись в папку файлового сервера. Суррогатный ключ записи в таблице базы данных по запускам есть переменная часть имени файла.
Что, не хватает мощности цифромолки для обработки сырца?

да, телеметрия, в каком виде бы она ни была, хранится в поле data таблицы param_data. дальнейшая ее судьба за рамками темы)))
работать с телеметрией мощностей хватает. все это - попытка организовать и систематизировать в одном месте всю информацию.

SERG1257, у каждой ракеты свой список телеметрируемых параметров. да, названия параметров с двух разных ракет могут совпасть, но данные совершенно разные, и соответственно рассматривать их нужно как две разные сущности.

softwarer,
softwarerНапоминает бессмертное "свинья даёт 12 сало в день". И ведь что самое смешное, этого никто не увидел.
самое смешное это то, что вы в этом увидели что-то смешное.

softwarerЧестно? Выбросить это и попытаться для начала хотя бы примерно понять предметную область. А то ракеты многоразовые, зато значение параметра, скажем, "температура в камере сгорания первой ступени" ровно одно на все сто двадцать секунд работы её двигателей. Я уж не говорю о таких мелочах, как то, что у одного-единственного "Протона" (это, я так понимаю, и есть "вид ракеты") в зависимости от целевой орбиты может различаться даже количество ступеней (и как следствие, состав получаемой телеметрии).
чушь несете, честное слово, начиная с многоразовости ракет:))
опросность датчика температуры 50Гц, это говорит о том, что за все 120 сек значений будет не "ровно одно" как вы говорите, а 50*120=6000. и это только один из шести двигателей первой ступени того же протона. да и параметр "температура в камере сгорания первой ступени" чисто условный, такого нет.
количество ступеней у протона три. всегда. да, идут обсуждения двухступенчатого протона, но это всего лишь идут обсуждения, не более.
и вообще, такое ощущения что вы меня провоцируете. потому что с такой уверенностью, присущей вашему сообщению, писать такие вещи как минимум глупо.
костяк форума, я так понимаю, это спецы в области администрирования и работы с БД, и обращаются сюда за помощью и консультациями люди из других областей, в том числе. вас в этом костяке я не представляю, ибо был бы ответ по существу, и специалист космической отрасли из вас тоже никакой.

сорри за оффтоп

SERG1257, задача не учебная. и по большей степени поставлена самому себе, чтобы, повторюсь, систематизировать все рабочие материалы по пускам. я себе четко представляю как это должно выглядеть ибо с этим работаю.
примеры запросов:
1. список пусков протона за 2013-2016 года (дата_пуска, выводимый_спутник)
2. список телеметрируемых параметров системы управления протона (название_параметра, описание_параметра)
3. замечания к параметрам при пуске протона 2.07.2013 (система, параметр, текст_замечания)
4. замечания к работе системы управления при пуске протона 2.07.2013 года (текст_замечания). Тут выводятся замечания и к системе и к параметрам системы управления.
5. вернуть данные параметра "темп128" протона при пуске 2.07.2013 (данные), т.е. возвращает просто byte[]
6. вернуть данные параметров системы управления протона при пуске 2.07.2013 (имя_параметра, данные_параметра)
7. вернуть данные параметра "темп128" протона с пусков 16.05.2014г и 16.05.2015г (id_пуска, название_параметра, данные_параметра)
и т.д.

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

думаю, тему можно закрывать, раз пошла такая пьянка-непонятка:))