Каковы проблемы с этой схемой реляционной базы данных?

Question

Меня попросили спроектировать реляционную базу данных для хранения данных, чтобы отвечать на запросы операций клиники, такие как:

● Перечислите назначения пациентов для каждого врача на определенную дату.

● Когда пациент звонит, чтобы записаться на прием, укажите доступные временные интервалы на определенную дату.

● Получить адрес пациентов для отправки уведомлений через почтовые службы.

У меня есть одна схема базы данных одного отношения, как показано ниже:

ABC (имя-документа, пол-документа, регистрационный номер, квалификация, имя-патта, пол-пола, DOB, адрес, номер телефона, дата назначения, время назначения, тип)

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

DOC (имя, пол, регистрационный номер, квалификация)

PAT (имя, пол, DOB, адрес, номер телефона)

НАЗНАЧЕНИЕ (дата, время, тип)

Есть ли другие проблемы с этим дизайном? Должен ли я избавиться от типа?

Спасибо

Answer 1

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

Следующее, что вы могли бы рассмотреть:

• ID врачей и пациентов
• Назначение Дата и время
• Основные ключи

ID врачей и пациентов
Имена пациентов не являются уникальными, и это не обязательно должно относиться и к именам врачей, поэтому я бы предложил добавить новый столбец в таблицы DOC и PAT для идентификатора. Эти идентификаторы должны быть добавлены в таблицу APPOINT, чтобы связать одного врача и одного пациента с назначением.

Назначение Дата и время
В SQL проще вычислять время и дни, когда вы используете соответствующие объекты DATETIME вашей системы баз данных вместо того, чтобы разбивать дату и время на два разных столбца. Вместо ввода я бы предложил рассчитать новое поле и для времени окончания встречи. Это облегчает расчет доступных временных интервалов врачей.

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

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

DOC:  
- id INT NOT NULL AUTO_INCREMENT  
- name  
- gender  
- registration_num  
- qualification  
- PRIMARY KEY (id)

PAT:  
- id INT NOT NULL AUTO_INCREMENT  
- name  
- gender  
- dob  
- address  
- phone_num  
- PRIMARY KEY (id)

APPOINT:  
- doc_id INT NOT NULL  
- pat_id INT NOT NULL  
- start DATETIME NOT NULL  
- end DATETIME NOT NULL  
- PRIMARY KEY (doc_id, start_datetime)