2016-06-09 2 views
0

Я создал модель базы данных, где есть пользовательский объект, который может содержать врача и пасьянс. Они будут разделены атрибутом «флаг». Следующим объектом является таблица встреч, которая назначает встречи. Проблема, с которой я сталкиваюсь, заключается в том, что у меня есть много разных отношений. Чтобы исправить это, я хочу добавить другую таблицу, но я не знаю, что я должен назвать и какую информацию она должна содержать.База данных moddeling | Пользователь M: M Назначение

Image of the database design

ответ

1

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

У вас есть одна таблица, Пользователи, в которой есть как врачи, так и пациенты с полем «Флаг», которое различает их. Предположение: флаг содержит «D» для врача или «P» для пациента.

Предложение: создать уникальное ограничение/индекс в таблице Users для идентификатора комбинации и флага. Это значительно облегчит следующие проблемы с целостностью данных:

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

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

create table Appointments(
    DrID  int not null, 
    DrFlag char(1), 
    PatientID int not null, 
    StartTime date not null, 
    EndTime date, 
    constraint ApptDrOnly check(DrFlag = 'D'), 
    constraint ApptDrSelf check(DrID <> PatientID), 
    constraint PK_ApptUserDoctor foreign key(DrID, DrFlag) 
     references Users(ID, Flag), 
    constraint PK_ApptUserPatient foreign key(PatientID) 
     references Users(ID) 
); 

Из-за нового уникального ограничения на таблицу пользователей для ID и флаг полей, они могут быть использованы в качестве справочного материала в FK, используя поля DrID и DrFlag в таблице пересечений. Ограничение, которое DrFlag может содержать только «D», ограничивает цель этого FK только врачам. PatientID PK относится к ПК таблицы «Пользователи», поэтому может относиться к врачам или пациентам. Проверка того, что DrID и PatientID не могут быть одинаковыми, не позволяет врачам назначить встречу с собой.

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

Если предположение неверно, внесите соответствующие изменения. Например, если назначение может быть сделано только между пользователем, назначенным врачом, и другим пользователем, определенным как пациент, проверка (DrID <> PatientID) может быть удалена, а поле PatientFlag с проверкой (PatientFlag = 'P') может быть добавлен.

0

Вы бы создать «userappointment» таблицу, которая связывает пользователей с назначениями, по одному за раз.

+0

1: m отношения от обеих таблиц до 1 новой таблицы. Я понимаю. Но как я называю это? и что я могу добавить помимо id и внешних ключей? –

+0

Gertjan, я обычно называю эти таблицы комбинацией обеих ссылочных таблиц, т. Е. Таблица, которая описывает отношения между пользователем и назначением таблиц, будет называться userappointment. Таким образом, вы говорите, что у вас может быть несколько пациентов и несколько врачей за одну встречу. Хотя это не то, что я обычно вижу, когда я иду к врачу, у вас все еще есть все подходящие поля в таблице встреч.Таблица userappointment будет содержать что-то конкретное для роли человека, например. одним врачом может быть ведущий врач. Или только ключи, как вы сказали. – cdonner

Смежные вопросы