Имеется некий прибор, который проводит физические замеры подсовываемых ему проб. В процессе единичного измерения прибор изменяет температуру воздуха в рабочей камере с некоторым шагом и выплевывает текстовый файл с 9-ю столбцами: Т, S1 ... S8, где Т - температура, а S1 ... S8 - собсбвенно физические параметры. Файл содержит также информацию о текущих настройках прибора. Измерение одной и той же пробы проводится многократно, т.е. имеем много таких файлов в которых число строк различно, так как начальная и конечная температура измерения различны.

Т.е. имеем например:

file1
Т
20
...
400

file2
Т
30
...
420

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

Я сделал так (опуская некоторые детали):

CREATE TABLE List_of_files
(
ID_File integer NOT NULL PRIMARY KEY IDENTITY (1,1),
File_Name varchar(50) NOT NULL,
Datum datetime NOT NULL,
UNIQUE (File_Name, Datum)
)

CREATE TABLE Descriptions
(
ID_Description integer NOT NULL PRIMARY KEY IDENTITY (1,1),
... %здесь идут еще 8 столбцов идентифицирующие пробу и настройки прибора
)

CREATE TABLE EDaten
(
ID_Dat integer NOT NULL PRIMARY KEY IDENTITY (1,1),
ID_Description integer NOT NULL FOREIGN KEY REFERENCES Descriptions ID_Description),
T decimal(6,2) NOT NULL,
S1 decimal(12,5),
...
S8 decimal(12,5),
ID_File integer NOT NULL FOREIGN KEY REFERENCES List_of_files (ID_File)
)

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

Может кто покритиковать, что-то посоветовать?

Yossarian, ну что ж, спасибо на добром слове.

Не пойму только или я слишком неясно изложил, или в самом деле все настолько "оптимально", что сказать нечего :)

Cat2, спасибо за добрые слова.

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

На самом деле тут есть больное место, которое тоже хотелось бы обсудить. Напишу потом с работы. Все таки в выходные положено отдыхать :)

Итак, "больное" место:

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

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

Введением UNIQUE (File_Name, Datum) я подстраховался от возможности дважды внести в базу данные из одного и того же файла. Это в принципе не исключает других возможных ошибок на этапе внесения данных в базу.

Собственно проблема, конечно, не относится напрямую к проектированию БД, но буду рад если услышу какие-то мысли по этому поводу.

Да, забыл добавить.

Это является еще одной причиной, почему я храню Имя файла. Если обнаруживается, что какие данные выглядят весьма сомнительно, то я могу всегда сказать: "А посмотри, уважаемый, не наколбасил ли ты чего в таких то файлах." Что существенно проще, чем искать эти файлы по всей сети имея только время их создания.

Так, отвечаю по частям.

Первое:
CREATE TABLE Descriptions
(
ID_Description integer NOT NULL PRIMARY KEY IDENTITY (1,1),
ID_ProbenName integer NOT NULL FOREIGN KEY REFERENCES ProbenNamen (ID_ProbenName),
ID_Behandlung integer NOT NULL FOREIGN KEY REFERENCES Behandlungen (ID_Behandlung),
ID_Sensor1 tinyint NOT NULL FOREIGN KEY REFERENCES Sensors (ID_Sensor),
ID_Sensor2 tinyint NOT NULL FOREIGN KEY REFERENCES Sensors (ID_Sensor),
ID_Sensor3 tinyint NOT NULL FOREIGN KEY REFERENCES Sensors (ID_Sensor),
Board int NOT NULL FOREIGN KEY REFERENCES Boards (Board),
C2H4 int,
Klasse varchar(14),
Benutzer varchar(14) NOT NULL
)

Здесь ID_Sensor1, ID_Sensor2, ID_Sensor3 и Board приходят из файла с данными. Т.е. каждый файл содержит эту информацию. Ясно, что для одного и того же эксперимента эта информация повторяется. Это тоже проверяется при занесении в базу.

Benutzer - пользователь.
ProbenNamen - названия проб (материал в терминах wara)
Behandlungen - тесктовые описания. Что-то вроде: "помолившись и помыв руки засунул я в прибор свежесгнившее яблоко". Т.е. если исследователь считает, что от того, помолился он или нет, зависят результаты, то он должен в последствии суметь различать эксперименты.
C2H4 - точное измерение одного важного параметра другим, тестовым, прибором (может быть не задан). Не путать с S1...S8. Это другая физическая величина.
Klasse - один из четырех возможных классов визуальной оценки пробы (может быть не задан)

Далее - одна и та же проба не может быть исследована при разных настройках прибора разными людьми. Это будет уже другая проба.


Второе:
Как вносятся данные:

1. Пользователь выбирает файлы, данные из которых он собирается внести в базу.
2. Выбирает из уже имеющихся или вводит новые ProbenNamen, Behandlungen.
3. Вводит если заданы C2H4 и Klasse

Далее ID_Sensor1, ID_Sensor2, ID_Sensor3 и Board читаются из файлов, проверяются на совпадение и данные пишутся в базу.

> Основная проблема у автора вопроса не только в том "как придумать структуру", а в том "как правильно организовать регистрацию фактов эксперимента".

Это верно.

> Я бы дополнил структуру следующими таблицам ...
Ну дак они есть. То есть база нормализована по максимуму.

А вот про разбиение таблицы Descriptions на две я пока не въехал, хорошо это мне или нет. Подумать надо.

> Тут у нас прямо "итеративный процесс постановки задачи с наращиванием возможностей" :-)

Есть такое :-)

Просто я хотел сначала посоветоваться только по одному поводу и убрал все "лишнее" для упрощения. Но аппетит приходит во время еды. Да еще и народ такой дружелюбный, грех не пообщаться :)

Ну "кровавые битвы на подушках", наверное, на всех форумах случаются.

По поводу разбиения таблицы Descriptions.
Не вижу никакого смысла. Т.е. у меня сейчас могут быть два или более эксперимента с полностью идентичными данными. Различу я их по ID_Description. И это хорошо. Захочу - возьму данные для анализа вместе, захочу - раздельно.