Простой вопрос проектирования БД - наборы измерений

Question

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

В электронной таблице каждый набор измерений находится в своем собственном столбце, т. Е.

 1  |  2  |  3  | ...
0.5 | 0.7 | 0.2 | ...
0.3 | 0.6 | 0.4 | ...

и так далее. Если у меня есть, скажем, 10 наборов данных и каждый из них имеет 8 измерений, я получаю таблицу 8x10 с 80 значениями.

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

create table Measurement(
    int id not null auto_increment,
    primary key(id)
);

create table Measurement_Data(
    int id not null auto_increment,
    double value not null,
    int measurement,
    primary key(id),
    constraint fk_data foreign key(measurement) references Measurement(id)
}

Это правильно? В результате получается таблица с одним автоматически сгенерированным столбцом (хотя, конечно, я мог бы добавить к нему больше позже) и другая таблица, в которой каждый набор данных хранится «по длине», что означает, что в таблице будет 800 строк с указанными выше значениями. Это правильный способ справиться с этой проблемой? Это также означает, что мне нужно добавить данные, мне нужно вставить строку в таблицу измерений, получить назначенный ей pk, а затем добавить все новые строки в таблицу Measurement_Data, верно?

Я ценю любой совет,

Ken

Answer 1

Как насчет простого решения за одним столом для этого?

CREATE TABLE measurements
(
    id INT AUTO_INCREMENT,
    dataSetId INT,
    measurementNumber INT,
    measurementValue DOUBLE,
    CONSTRAINT UNIQUE (dataSetId, measurementNumber)
);

Если ваша проблема не сложнее, чем вы описываете, этого должно быть достаточно.

Answer 2

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

create table Measurement(
    int  MeasurementId  not null  auto_increment,
    primary key(id)
);

create table MeasurementData(
    int  MeasurementId  not null,
    int  MeasurementDataEntry  not null,
    double  value  not null,
    primary key(MeasurementId, MeasurementDataEntry),
    constraint fk_data foreign key(MeasurementId) references Measurement(MeasurementId)
)

Согласно LukLed, MeasurerementDataEnry будет порядковым значением, начиная с 1 и увеличиваясь на единицу для каждой «записи данных» для этого MeasurementId. Составного первичного ключа должно быть достаточно, так как с учетом указанной проблемы я не вижу реальной необходимости в дополнительном суррогатном ключе для MeasurementData.

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

Answer 3

Сначала я бы изменил имя столбца «измерение» на «идентификатор измерения», потому что это имя не является интуитивно понятным. Вы также можете добавить порядковый номер в таблицу данных измерений, чтобы узнать порядок выполнения измерений и добавить уникальный идентификатор измерения и порядковый номер. Добавляя порядковый номер, вы также можете ограничить количество измерений в каждом тесте с проверочным ограничением.