Здравствуйте,
В некоторых книгах и статьях по проектированию БД указывается, что отношение один к одному чаще всего указывает на ошибку в проектирование, поэтому меня терзают смутные сомнения по поводу следующего:
Имеются таблицы:

Обследования пациентов(Examinations), со следующими полями:

ExamID |длин.цел.
DrID |длин.цел.
PatientID |длин.цел.
ResearchDay |дата дата начала обследования

и ряд таблиц с семантически одинаковыми полями(syndroms, symptoms, Anamnesises и т.д.), которые заполняются в процессе обследования:

SyndromID |длин. цел.
SyndromTypeID|длин. цел. Типы синдромов в зависимости от заболевания
Comment |текст Дополнительное описание вносится вручную.

Какой тип отношений будет между этими таблицами, если в результате обследования на данную дату начала обследования(ResearchDay), м. б. получены данные для заполнения, только по одной записи для каждого поля таблицы.
Допустим на данную дату у пациента м.б. только один Syndrom, Anamnesis и т.д и множество symptoms.

Для symptoms отношение один ко многим это видно сразу, а как быть с остальными.

Когда стоит создавать дополнительную таблицу?
Например:

ExamID |длин.цел.
SyndromID |длин.цел.
SymptomID |длин.цел.

такой слой абстракции нужен?


[offtopic] Посоветуйте хорошую медицинскую электронную энциклопедию?[/offtopic]

Здравствуйте, G2, Вы писали:

G2>Допустим на данную дату у пациента м.б. только один Syndrom, Anamnesis и т.д и множество symptoms.
G2>Для symptoms отношение один ко многим это видно сразу, а как быть с остальными.

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

Практика: заказчики-врачи сказали, что такого никогда не будет? ОНИ ПОКЛЯЛИСЬ??? нет, не так... мало... Ты работаешь по официальному договору, и это условие четко прописано в утвержденном ТЗ??? Тогда пожалуй можно, на всякий случай еще раз посоветовавшись со своей жопой, поверить им и не плодить лишних таблиц. Потому что в противном случае переделывать потом — угадай кто будет?

Здравствуйте, G2, Вы писали:

G2>В некоторых книгах и статьях по проектированию БД указывается, что отношение один к одному чаще всего указывает на ошибку в проектирование,

"Чаще всего" — понятие плохо определимое, да и "ошибка в проектировании" — тоже. Определенная правда в этом есть — но из этого не следует, что "один к одному" не имеет права на существование.

G2>и ряд таблиц с семантически одинаковыми полями(syndroms, symptoms, Anamnesises и т.д.), которые заполняются в процессе обследования:

Прежде всего — на всякий случай — стоит отметить, что "семантически одинаковые поля" не означают, что соответствующие записи надо укладывать в одну таблицу. Бывает и такое, но это скорее исключение.

G2>Допустим на данную дату у пациента м.б. только один Syndrom, Anamnesis и т.д и множество symptoms.

Я бы, скорее всего, включил в Exam поля SyndromId, SyndromComment, AnamnesisId, AnamnesisComment и сделал бы детальную Symptoms.

Причина — в том, что эти таблицы вряд ли имеют хоть какую-то ценность поотдельности от Exam. То есть крайне маловероятны запросы, в которых будут участвовать Syndrom и не будет — Exam. Соответственно, выделение отдельных таблиц только усложнит запросы и приведет к трате дополнительных ресурсов.

G2>Когда стоит создавать дополнительную таблицу?

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

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