Дополнительные базы данных Сущности (часть 2)

Question

См 'Почти Решила' ниже

---

ПРИМЕЧАНИЕ: Это продолжение и упрощение Optional Database Entities.

Я разрабатываю новую лабораторную базу данных, которая тестирует широкий спектр тестов для самых разных типов образцов.

Основные Сущности:
    Каждый должен иметь ровно один родителя (за исключением REQ) и по меньшей мере, один ребенка (за исключением MEA).

 
Request  REQ - the form 
Sample  SAM - the materials on the form to be tested 
Test   TST - the procedures to be performed on the sample 
(Trial **  TRI - instance of duplicate methods for statistics) 
Measurement MEA - a single measured number 
** A Trial is optional. (see below) 

Дополнительные Пробные Объяснение
Многие тесты простая процедура с несколькими измерениями. Например, «Добавить 10 мл 15% KNO3 в образец, затем получить плотность и pH».

Однако некоторые тесты требуют, чтобы одна и та же процедура выполнялась на отдельных участках образца. В качестве примера рассмотрим баллистическое тестирование. Заявитель может запросить среднюю скорость и точность выхода для этих 20 пуль. sample - это набор из 20 пуль. test «собирает скорость и точность выхода». trials - это 20 отдельных выстрелов. measurements - скорость и точность выхода для каждого кадра (trial).

ВОПРОС
Как я должен моделировать объекты Test, Trial и Measurement, так как Trial объект является необязательным?

Вариант 1: Используйте «пустую» пробную сущность в качестве заполнителя, если это необходимо.
Хорошо: родительский объект всегда одинаковый.
Плохо: Trial записей существуют, даже если они не нужны.

Вариант 2: Ролл Trial в Test таблицу в качестве суб-теста. Тогда измерение всегда будет иметь test в качестве родителя.
Хорошо: Один родителя типа для измерения (Test)
Bad: Multiple родительского типа для Test: Sample или Test

Вариант 3: измерения еще имеет один из родителей, но родитель может быть либо test или trial.
Хорошо: Один родителя типа для Test (и Event при необходимости)
Bad: Multiple родительского типа для Measurement: Test или Trial

Вариант 4: Trial, как к югу от объекта.Measurement потребовалось test_id и дополнительно trial_num. Испытание имеет PK (test_id, trial_num).
Хорошо: не существует нескольких родительских типов.
Плохо: Не уверен, что

Вариант X: Любой другой вариант уже не упоминается.

---

---

Почти Постановили: Сейчас я считаю Вариант 4 (Trial в качестве суб-организации) является лучшим. Ниже приводятся основные правила для варианта 4. - A measurement всегда относится к test. - A trial существует только при необходимости. - Trial_num устанавливается при наличии нескольких испытаний под множеством. - В противном случае trial_num имеет значение null, указывающее, что trial не требуется.

Simple ER Diagram 
----------------- 
REQ <- SAM <- TST <- MEA 
      ^  | 
       |  | 
       |-(TRI)<-|  

Table Keys 
---------- 

Table | PK    | FK 
------+-----------------+---------------- 
REQ | REQ_id   | 
SAM | SAM_id   | REQ.PK 
TST | TST_id   | SAM.PK 
(TRI | TST_id, TRI_num | TST.PK) 
MEA | MEA_id   | TST.PK, TRI.PK* 

* TRI.PK is null if trial entity is not needed. 

Просьба представить информацию о том, почему это хороший или плохой вариант.

Answer 1

Непонятно, почему необходимо представлять Trial в качестве отдельного объекта. Почему не соответствует следующая схема?

Sample  Test   Measurement 
------  ----   ----------- 
SampleId (PK) TestId (PK) MeasurementId (PK) 
Description SampleId (FK) TestId (FK) 
       TestStartDate Description 
       TestEndDate MeasuredValue 

Из того, что вы сказали, до сих пор, это звучит, как вы могли бы просто делать вывод что Test с более чем одним Measurement подсчетов как Trial. То есть, если ваш пользовательский интерфейс должен показать, что конкретный тест был Trial, если можно просто сделать следующее:

if (test.Measurements.Count > 1) { 
    _View.Title = test.TestName + " (Trial)"; 
} 

Если это не так, какие атрибуты вам нужно, что эта схема не хватает? Что еще должно быть в таблице Trial, которая недоступна здесь?

---

Update: учитывая дополнительные подробности, я бы рекомендовал введение новой организации, которую я буду называть TestRun. A TestRun просто группирует один или несколько Measurements в пределах Test.Trials теперь ассоциируются с TestRuns.

Полученная схема выглядит следующим образом:

Sample  Test   TestRun   Measurement 
------  ----   -------   ----------- 
SampleId (PK) TestId (PK) TestRunId (PK) MeasurementId (PK) 
Description SampleId (FK) TestId (FK)  TestRunId (FK) 
       TestStartDate     Description 
       TestEndDate     MeasuredValue 

Trial 
----- 
TrialId (PK) 
TestRunId (FK) 
Description 

Это очень близко к Вариант 1 в оригинальный вопрос. Если затраты на поддержание пустой (или фиктивной) Trial являются низкими - например, если Trials имеют несколько атрибутов или нет, это может быть лучшим решением.

Answer 2

Из того, что я могу собрать из ваших объяснений, это можно сказать:

Тест может иметь один или несколько испытаний assocaited к нему и Trial только может быть связан с одним Теста.

В этом случае суд является дочерним объектом теста. Если это так, то вы можете иметь две таблицы:

Тестовые
Trial

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

Answer 3

Вот кайт, взлелеянный по предположениям и интерпретации.

A request поставляется с sample и спецификацией процедур, которые должны выполняться на образце. Если sample является особым (бутылка с жидкостью), то это тест и собран один набор измерений. Если sample является кратным (поле с пулями, временными рядами), то это пробный номер, и производится повторный набор мер, по одному на экземпляр sample.

Другими словами, тестовая дихотомия - это красная селедка, а measurement - таблица пересечений между test и sample.

REQUEST 
------- 
RequestId (PK) 
Specification 

SAMPLE 
------ 
RequestId (FK) 
SampleId (PK) 

TEST 
---- 
RequestId (FK) 
TestId (PK) 
TestStartDate 
TestEndDate 

MEASUREMENT 
----------- 
TestId (FK) 
SampleId (FK) 
MeasurementDescription 
MeasuredValue 

Measurement(TestId,SampleId) является составным уникальным ключом. В зависимости от того, как вы относитесь к композитам, вы можете определить суррогат MeasurementId (PK).

Очевидно, что может потребоваться дополнительная нормализация. Например, вам может понадобиться/нужно разбить образец на две таблицы: sample и sample_instance. Трудно сказать, не зная всех связанных с этим атрибутов.