Система такая:

Вообще система такая:
1. Приходит клиент в приёмную к Человеку1. Человек заполняет основные данные по клиенту (паспорт и т.п) + заполняет заказ (какие гены этот человек хочет исследовать). Жмёт кнопку в форме и автоматически заполняется по шаблону методом поиска и замены Договор, содержащий ту же основную информацию, список заказанных генов, стоимость и т.п.
Далее забирается материал для исследования у клиента.
2. Сотрудники в лаборатории выполняют поиск несделанных генов. Причём не бывает такого, что сотрудник выбирает для работы все гены одного клиента. Это нелогично. Сотрудник выбирает, например, 20 одинаковых генов от 20 разных клиентов, чтобы сразу поставить реакцию и получить 20 результатов.
И так, сотрудник выбирает гены для исследования и ставит пометку, что он взял эти гены для исследования, ставит своё имя напротив. Ставит дату проведения исследования.
3. После проведения исследования сотрудник ищет по своему имени и дате гены, которые он выбрал. Заполняет поле Аллель, т.е. вписывает результат исследования. Ставит дату завершения.
4. Человек 1 осуществляет мониторинг. Если появляются клиентки у которых сделаны все анализы, то она должна заполнить (тоже автоматически) ещё три документа: АКТ, ПРОТОКОЛ и ПАСПОРТ. Там свои нюансы. После этого Человек1 ставит пометку ПОЛНОСТЬЮ ГОТОВО (или как-то так).
Акт - заполняется схоже с договором.
Протокол - содержит информацию об исследовании и условиях проведения
Паспорт - это "брошюрка" для клиента, в которой понятным языком написано что и как. Ген, расшифровка, результат и функции гена. И т.п.

Вот примерно так.
Скажите, что не так в базе???

Mikle83,
AO_MMM,

Спасибо!
Вот исправленный вариант. Что скажете?

П-Л,

Т.е. у меня всё плохо? Или как?

Mikle831. Есть подозрение, что в рамках одного обращения клиент может сдать более чем один образец на анализ.


Да нет. Он сдаёт только одно - образец буккального эпителия (ватной палочкой в полости рта). А дальше выделяем мы ДНК и проводим нужные анализы.

Кот Матроскин,

Да. Результат всех анализов - это аллель. И не отсутствие\присутствие, а какая именно (из 3-х возможных для каждого гена).

Кот Матроскин+ В виде исключения в таблице аллелей я бы сделал составной перичный ключ (ID_Гена, ID_Аллеля) - это поможет ссылочной целостности в таблице "результаты", невозможно будет в заказе указать один ген, а в результате ввести аллель от другого.
Т.е в таблицу Аллели сделать оба поля ИД_Аена и ИД_Аллеля ключевыми?

Вы смотрели обновлённую схему данных, которая ниже? (просто вы пишете ID_Гена, когда как в новой всё переведено на русский)

Mikle83,

Т.е сделать так:
1. Таблица Обращения (ИД_Обращения, ИД_Клиента, Номер образца, ИД_Статуса)
2. Таблица Статусы_Обращений (ИД_Обращения, ИД_Статуса , Дата_поступления, Дата_Начала_Выделения, Дата_завершения)
3. Статусы ( ИД_Статуса , Наименование). В наименование записать: ДНК_выделено?, Распечатано?, Выполнено?

Только я теперь совсем запутался, как их связать?

автор2. Мелочь но будет приятно - в "Заказанные_Гены" переименуйте поле "ИД_Заказа" в "ИД_Обращения".

Т.е. убрать ИД_Обращения, которое там уже есть. А после переименовать ИД_Заказа, пропустив через него все связи?

Спасибо большое!

Mikle83,

хм... Никогда не пробовал делать м:м, но попробую. Идея прекрасная. Где-то через час смогу заняться базой. Отпишусь!
Спасибо ещё раз.

Mikle83,

Mikle832. Мелочь но будет приятно - в "Заказанные_Гены" переименуйте поле "ИД_Заказа" в "ИД_Обращения".
Так и не понял зачем это делать.... =_=


Mikle83Никита ОсеннийТ.е сделать так:
1. Таблица Обращения (ИД_Обращения, ИД_Клиента, Номер образца, ИД_Статуса)
2. Таблица Статусы_Обращений (ИД_Обращения, ИД_Статуса , Дата_поступления, Дата_Начала_Выделения, Дата_завершения)
3. Статусы ( ИД_Статуса , Наименование). В наименование записать: ДНК_выделено?, Распечатано?, Выполнено?

Только я теперь совсем запутался, как их связать?


Эм. Получается стандартная схема связи "М:М" для таблиц "Обращения" и "Статусы".
У вас одно Обращение может иметь более чем один статус, и один статус может быть назначен более чем одному обращению.

Соответственно создается третья таблица, в которой в одной строке есть и ИД_Статуса и ИД_Обращения.
Вы можете выбрать историю статусов для данного обращения.
К примеру, в Статусах у вас всего две записи:
ИД Наименование1 Получен2 Выделен3 Выдан результат

Тогда для обращения с ИД = 1 в таблице " Статусы_Обращений " могут быть следующие записи:
ИД_Обращения ИД_Статуса Дата11 2014/06/2312 2014/06/2413 2014/06/25

И не надо добавлять в расширенную таблицу все даты сразу =)

Вот что у меня вышло. Только в таблице Обращения появляется окно выбора таблицы, которую нужно отображать в качестве подтаблицы, если нажать на плюс в строке. Это, как я понимаю, от того, что у меня несколько связей. Это нормально? Всё правильно получается?

Mikle83,

авторпро изменение ИД_Заказа - это забыть надо :)
Структура по наименованию полей не совсем привычная - отсюда не сразу разобрался. Так что тут ничего менять не надо.
Ок) А то я сразу перепугался.

авторДавайте дальше посмотрим
1. "Результаты исследования" и "Заказанные гены" связаны как 1:1.
Смысл тогда в выделение отдельной таблицы? Получается ИД_Результата сопоставляется только с одним ИД_ЗАказа, так может быть использовать ИД_Заказа без создания новой сущности и нового идентификатора?
Не знаю. Так посоветовали . А разбить на таблицы разные тоже кто-то говорил, чтобы разгрузить таблицу одну.

автор2. По статусам. Если правильно понял исходные условия - более интересны именно статусы отдельных заказов, а не обращений. Дабы сотрудники искали еще "не выполненные" гены.
Т.е. каждый ген может быть так же в нескольких статусах, а статус обращения в большей степени зависит от "суммы" статусов генов (если все гены готовы - обращение готово, если хотя бы один из генов не готов - обращение в статусе "в производстве", если не готов ни один ген - обращение в статусе "принято").
Всё гораздо проще. Если есть результат исследования (аллель), значит ген готов. Если все гены для обращения имеют результат, значит обращение выполнено\готово\закрыто (не суть). А промежуточный статут (выполняется и т.п.) нас не интересует. Вот. Так что не думаю, что всё это надо для не столь серьёзной базы и в моём случае.


авторИли же (тут вам виднее) - можно ввести независимые понятия статусов для обращения и статусов для заказов.
авторболее интересны именно статусы отдельных заказов, а не обращений
Думаю проще отказаться от связи м:м и лишних таблиц. Всё не так серьёзно. Просто в таблице вернуть строки с датами обращения\начала\завершения исследования (это же не статус, а важная информация) и выделения ДНК + готовности - вот это уже статусы, но их мало, чтобы столько для них делать.

автор3. К вашему вопросу в соседней теме про "флажки".
Изучите т.н. битовые маски. В самом простом случае - генам давайте в десятиричной системе ИДишники по разрядно,
к примеру - первый ген: ИД = 1, второй ген ИД = 10, третий ген ИД = 100

Соотв. выставлен флаг - сделал +ИД к общей сумме, снят флаг - минус ИД.
Сумма ИДишников будет однозначно определять какие гены Вами были выбраны.

(К примеру, 101 - третий и первый, 110 - второй и третий, 11 - первый и второй и т.д.)
Ну и более продвинутая схема = с двоичной системой, когда каждый бит кодирует нужный ген - потребуется в разы меньше места для хранения информации.
С флажками мне помогли. Вот . Как я понял из кода, то там нужно описать процедуру записи в определённую таблицу и поле из переменной IDs всех записанных в неё Id. Но вот как это сделать я не знаю. А пример этот ооочень классный. Суперский просто.