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

Question

ORIGINAL (см ОБНОВЛЕНО вопрос ниже)

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

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

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

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

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

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

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

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

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

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

Вариант x: Любой другой вариант, который стоит рассмотреть.

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

---

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

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

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

Вариант 3 (Pick-а-Родитель): Сущность (С) ниже дополнительного объекта (B) с требуемым объектом (A) должен иметь один из родителей, но родитель может быть либо дополнительный объект (В) или следующий более высокий (A).

Вариант x: Любой другой вариант, который стоит рассмотреть.

Answer 1

адресации упрощенный вопрос:

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

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

Answer 2

Использование внешних соединений. (ПРАВИЛЬНОЕ ВСТУПЛЕНИЕ ВЗАИМОДЕЙСТВУЮЩЕГО И ВЗАИМОДЕЙСТВУЮЩЕГО ВЗАИМОДЕЙСТВИЯ).

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

Answer 3

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

Таблицы испытания test_id, запрос, образец, тест

Таблица Субтест subtest_id, test_id (внешний ключ Test)

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

Таким образом, тест представляет собой сборник о f подтесты (возможно, только один подтест), а подтест - это сборник пробных версий (возможно, только одно испытание)

Answer 4

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

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

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

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

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

Во всяком случае, в случае необходимости, можно поставить одновременно trial_id и test_id на Measurements, возможно, с ограничением, что один или другой должен быть NULL (а другой должен быть установлен).

Answer 5

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

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

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

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

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

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

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

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

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

Answer 6

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

A TEST - это единая процедура. Несмотря на то, что слово «тест» содержит слово «тест», он не является 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 7

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

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

Вот сущности, я вижу, к дате:

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

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

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

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

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

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

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

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

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