Дополнительные объекты базы данных

Question

ОРИГИНАЛ (см. ОБНОВЛЕННЫЙ ВОПРОС ниже)

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

Следующий список является моим текущим кандидатом на список основных объектов для лучшей модели лабораторной работы.

Для каждого объекта существует отношение 1-ко-многим от этого объекта к объекту ниже. Другими словами, каждая сущность (кроме REQ) имеет как минимум столбцы для entity _id и parent _id.

Основные объекты:
REQ: Запрос (форма)
SAM: Образец (материал)
TST: Тест (запрошенные процедуры)
SUB: ** Субтест (часть стандартного теста)
TRI: ** Trial (один экземпляр: обычно для среднего значения, диапазона и стандартного значения)
MEA: Измерение (измеренное число)
** Не во всех тестах есть подтесты, и не во всех тестах есть испытания.

Подтесты - это набор тестов, сгруппированных по одному имени для удобства ссылок. Например, приемочное испытание партии (LAT) для конкретного продукта определяется как следующие испытания: вязкость,% азота, pH и плотность.

Испытание - это один эксперимент, проводимый несколько раз для обеспечения качества продукта. Например, пятьдесят пуль могут быть застрелены, и каждый выстрел - пробный. Может потребоваться, чтобы точность каждой пули находилась в определенном диапазоне, а средняя точность всех пятидесяти пуль должна быть в более узком диапазоне.

Вопрос: Как мне моделировать случаи, когда под-тесты и / или испытания не нужны?

Вариант 1: Используйте «пустой» суб-тест (или пробный), если не требуется.

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

Вариант 3: Необязательные родители для измерения (проба, под-тест или тест) и испытаний (суб-тест или тест).

Вариант x: Любой другой вариант, заслуживающий рассмотрения.

К вашему сведению: Если потребуется ответить на вопрос, я буду использовать Oracle.

---

ОБНОВЛЕННЫЙ ВОПРОС В общем, моя схема представляет собой иерархию сущностей, где каждая сущность (кроме верхней) должна иметь ОДНОГО родителя и (кроме нижней) должна иметь хотя бы одного дочернего элемента. Как лучше всего справляться со случаями, когда внутренняя сущность не нужна в определенной ситуации, или каковы преимущества / недостатки использования определенного варианта?

Вариант 1 (Пустышка): Используйте запись «пустышка», чтобы указать, что сущность не применяется в этом случае.

Вариант 2 (сведение): Сверните необязательные сущности в следующую вышестоящую родительскую сущность.

Опция 3 (Pick-a-Parent): У объекта (C) ниже необязательного объекта (B) с обязательным объектом (A) должен быть ОДИН родитель, но родитель может быть либо необязательным объектом (B) ) или следующий более высокий (A).

Вариант x: Любой другой вариант, заслуживающий рассмотрения.

Answer 1

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

A TEST - это одна процедура. Несмотря на то, что в нем содержится слово «тест», LAT - это не TEST само по себе, а скорее предопределенный набор таких процедур. Я бы смоделировал этот сценарий как сущность TEST с необязательной родительской сущностью, которую я предпочел бы назвать TEST_GROUP (как это и есть), но лучше использовать доменное имя, SUB_TEST.

A TRIAL представляется отличным от TEST, поэтому смоделируйте его как отдельную сущность. Поэтому у вас есть выбор, когда дело доходит до MEASUREMENT: вы можете иметь одну сущность с двумя необязательными внешними ключами или вы можете иметь TEST_MEASUREMENT и TRIAL_MEASUREMENT. Выбор пути зависит от характеристик и профиля использования.

Ниже приведен начальный удар по отношениям сущностей. Это будет точка в проекте, когда пользователь говорит: «О, нет, я совсем не это имел в виду».

create table sample (
    sample_id number not null
    , constraint samp_pk primary key (sample_id)
)
/
create table sub_test (
    sub_test_id number not null
    , sample_id number not null
    , constraint subt_pk primary key (sub_test_id)
    , constraint subt_samp_fk foreign key (sample_id)
        references sample (sample_id)
)
/
create table test (
    test_id number not null
    , sample_id number not null
    , sub_test_id number 
    , constraint tst_pk primary key (test_id)
    , constraint tst_samp_fk foreign key (sample_id)
        references sample (sample_id)
    , constraint tst_subt_fk foreign key (sub_test_id)
        references sub_test (sub_test_id)
)
/
create table trial (
    trial_id number not null
    , test_id number not null
    , constraint trl_pk primary key (trial_id)
    , constraint trl_tst_fk foreign key (test_id)
        references test (test_id)
)
/
create table measurement (
    measurement_id number not null
    , trial_id number 
    , test_id number 
    , constraint meas_pk primary key (measurement_id)
    , constraint meas_tst_fk foreign key (test_id)
        references test (test_id)
    , constraint meas_trl_fk foreign key (trial_id)
        references trial (trial_id)
    , constraint measurement_ck check (
            (test_id is not null and trial_id is null)
            or (test_id is null and trial_id is not null)
)
/

Редактировать

Решение вашего более общего вопроса.

Вариант 1 (Пустышка)

Никогда не использовать фиктивную запись. Это похоже на использование магического значения вместо нуля. Решение хуже, чем решаемое.

Вариант 2 (сведение)

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

Вариант 3 (Pick-a-Parent)

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

Answer 2

Решение вашего упрощенного вопроса:

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

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

Answer 3

Это мой первый пост. Основываясь на комментариях, я добавлю второй пост.

Вот мой взгляд на архитектурный первый проход. Этот материал, как правило, требует много обратной связи с экспертами в данной области, чтобы получить право.

«Тест» означает одно из:
- принять меры, измерить результаты
- Выполнить несколько действий (подтестов), измерить результаты для каждого
- Не проводите никаких тестов (но вы все еще можете проводить измерения -?)

Я бы настроил это как «родительскую» тестовую таблицу и дочернюю таблицу «SubTest», где Test может иметь 0 или более связанных SubTests, и каждый SubTest должен быть связан с одним и только одним Test. (Если в тесте есть только один субтест, введите его в свою таблицу, не пытайтесь отслеживать субтесты в тестовой таблице.)

Испытания могут существовать, только если существуют под-тесты. Таким образом, Trials являются дочерними элементами таблицы SubTest; Подтесты могут иметь ноль или более Испытаний, и Испытания должны быть связаны с одним и только одним Подтестом.

Меры существуют только при наличии испытаний. Поэтому повторите вышеизложенное с Мерами как потомком Испытаний.

Могут ли быть подтесты без испытаний (или тестов)? Если это так, то не вводите никаких испытаний.

Могут ли быть меры без испытаний? Если нет, вам не нужны какие-либо испытания (или подтесты). Если да (?), При необходимости введите еще раз некоторые правильно помеченные подтесты или пробные подставки или испытания.

Опять же, это элементарно, и требуется больше собеседований с требованиями к вождению.

Answer 4

Использовать внешние соединения. (ПРАВИЛЬНОЕ НАРУЖНОЕ СОЕДИНЕНИЕ и ЛЕВОЕ НАРУЖНОЕ СОЕДИНЕНИЕ)

Они были сделаны специально для этого.

Answer 5

Я возьму второй удар, основываясь на отзывах из моего первого поста. Главное, что нужно понять, это то, что дизайн и архитектура могут быть очень итеративными, и я сомневаюсь, что вы получите идеальную модель без большого количества возвратно-поступательных действий - что-то, что не очень хорошо работает при переполнении стека. Скорее всего, вы возьмете опубликованные идеи (у APC есть некоторые хорошие), поделитесь ими с людьми, с которыми вы работаете, и придумаете что-нибудь, что сработает.

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

Вот сущности, которые я вижу на сегодняшний день:

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

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

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

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

Итак, у вас есть экзамены - определения экзаменов, действительно - так или иначе связанные с несколькими тестами. Далее у вас есть «платный экземпляр» экзамена (приходит клиент X и платит вам за проверку его виджетов). Назовите это CustomerExam ; он содержит всю контактную информацию и информацию для выставления счетов, определяет экзамен, который необходимо выполнить, и, таким образом, относится к тестам, которые должны быть выполнены для клиента. (Возможно, там тоже есть клиентская сущность ...?)

Испытания выполняются для тестов, которые являются частью CustomerExam. Они не связаны с экзаменом или тестом, они являются примером проведения испытания. (Кажется безопасным предположить, что «значение / определение» Испытания будет фактически частью теста - например, если Тест = Точность оружия, то работа, требуемая Испытанием для этого Теста = 50 раз огнестрельного оружия и измерения). Так как Испытания проводятся для Тестов данного CustomerExam. Они выполняются один раз или несколько раз? (Является ли пробная стрельба из пистолета 50 раз, или каждый выстрел засчитывается как пробный? Что делать, если они делают два выстрела по 50 выстрелов?) Как бы то ни было, атрибуты события испытания сохраняются здесь - когда это произошло, кто это сделал это, специальные примечания / обстоятельства, что угодно.

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

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

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

Answer 6

Я не совсем уверен, что понимаю ваш домен, но не могли бы вы сделать что-то подобное?

Tests имеет столбец parent_test_id, который может быть NULL (если установлен, это подтест).

Trials имеет столбец test_id. (Во всех тестах есть хотя бы одно испытание, так как вы сделали что-то и провели хотя бы одно измерение, верно?)

Measurements имеет столбец trial_id.

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

В любом случае, при необходимости, вы можете поставить trial_id и test_id на Measurements, возможно с ограничением, что один или другой должен быть НЕДЕЙСТВИТЕЛЕН (а другой должен быть установлен).

Answer 7

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

Table Test test_id, request, sample, test

Table SubTest subtest_id, test_id (внешний ключ для Test)

Таблица Trial trial_id, trial_name, измерение, subtest_id

Итак, Test - это коллекция подтестов (возможно, только один подтест), а подтест - это коллекцияиспытаний (возможно, только одно испытание)