Дизайн базы данных для приложения стоматолога

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

У меня есть небольшая борьба с дизайном базы данных, хотя...

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

Поэтому я думаю, что у меня должен быть tbl_appointment, а также tbl_treatment, я не уверен, как связать эти таблицы, чтобы иметь несколько типов лечения с разными параметрами лечения и сохранить данные лечения, связанные с назначением.

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

ИЗМЕНИТЬ

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

Если я проведу лечение так же, как и пародонтограмму, у меня будет 20 таблиц, по одной для каждого типа лечения. Я хочу избежать этого!

введите здесь описание изображения

ИЗМЕНИТЬ

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

введите здесь описание изображения

Я прав? Не обращайте внимания на типы отношений, так как они все 1:1, я знаю, что должен использовать там немного M:N, но это было просто для примера.


database medical
person martskins    schedule 06.02.2014    source источник
comment
должен быть первичный ключ для идентификации встреч, например appointmend_id или что-то в этом роде. Затем вы должны использовать его как внешний ключ в таблице tbl_treatment. У вас есть столбец appointment_id, в котором хранится встреча, с которой связано лечение.   -  person dub stylee    schedule 07.02.2014
comment
Я бы также порекомендовал стол для врачей/ортодонтов или кого-то еще, с кем будет встречаться клиент, и doctor_id. используйте это как внешний ключ в tbl_treatment. если вы хотите добавить клиентов с tbl_customer и cust_id и fk, это, вероятно, было бы неплохо. Затем вы начинаете думать о семьях, где вы собираетесь лечить ребенка, но родитель будет контактным лицом, и собираетесь ли вы хранить информацию о страховке, если она должна быть зашифрована… интересно, как кто-нибудь когда-либо закончил программное обеспечение, которое делает это   -  person PsychoData    schedule 07.02.2014
comment
О, кажется, я не совсем ясно выразился... Я знаю, как связать таблицы, просто я не могу придумать структуру базы данных, чтобы она соответствовала перечисленным мною требованиям. Я имею в виду, должен ли я иметь таблицу для процедур и другую для обработки_данных? и, может быть, еще один для Treatment_types? где я должен указать, какие параметры принимает лечение? На самом деле довольно сложно разобраться в этом   -  person martskins    schedule 07.02.2014
comment
Это зависит от того, какой уровень нормализации вы собираетесь использовать. См. agiledata.org/essays/dataNormalization.html для получения дополнительной информации о нормализации базы данных.   -  person dub stylee    schedule 07.02.2014

Ответы (2)


arrow_upward
1
arrow_downward

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

  • имя
  • описание
  • цена
  • необходимое время

Они становятся столбцами таблицы tbl_treatment.

Затем используйте дополнительную таблицу для других (специфических для лечения) атрибутов tbl_treatment_attributes со структурой вроде:

  • id_лечения
  • имя атрибута
  • атрибут_значение

Каждое лечение может иметь множество дополнительных атрибутов, приемлемыми атрибутами (включая значения по умолчанию) можно управлять в tbl_treatment_defaults.

  • id_лечения
  • имя атрибута
  • field_type
  • проверки
  • значение по умолчанию

ИЗМЕНИТЬ

+-------------------+              +--------------------+
| tbl_treatment     |              | tbl_treatment_type |
+===================+              +====================+
|*treatment_id      |              |*treatment_type_id  |
|+treatment_type_id |<-------------| treatment_name     |
|  ......           |              | ......             |
+-------------------+              +--------------------+
         |                                   |
         v                                   v
+--------------------------+       +------------------------+
| tbl_treatment_attributes |       | tbl_treatment_defaults |
+==========================+       +========================+
|*treatment_id             |       |*treatment_type_id      |
| attribute_name           |<------| attribute_name         |
| attribute_value          |       | default_value          |
| ........                 |       | .......                |
+--------------------------+       +------------------------+
person Ian Kenney    schedule 07.02.2014
comment
Как я должен указывать всегда одни и те же атрибуты для каждого вида лечения? Должен ли я делать это на стороне клиента? - person martskins; 07.02.2014
comment
отредактированный ответ - вы можете использовать дополнительную таблицу для определения разрешенных атрибутов для каждого типа лечения - person Ian Kenney; 07.02.2014
comment
Пожалуйста, посмотрите второе редактирование, чтобы проверить, правильно ли я понял - person martskins; 07.02.2014
comment
Это чрезмерно абстрагировано. - person Shiva; 07.02.2014

arrow_upward
0
arrow_downward

Таблица встреч tbl_appointment должна содержать только данные встреч и patientId (внешний ключ в вашу таблицу tbl_Patient)

У вас должна быть третья таблица с именем tbl_Visit, которая содержит внешний ключ в tbl_appointment. Затем другая таблица с именем tbl_Visit_treatment, в которой есть VisitId и TreatmentId. Таким образом, эта tbl_Visit_treatment представляет собой таблицу взаимосвязей «многие ко многим», в которой отслеживаются все виды лечения, выполненные при каждом посещении.

Что касается TreatmentType(s), то это будет просто таблица типов с именем tbl_TreatmentType с полями ID, Name, Code и Description. TreatmentId будет внешним ключом в таблице tbl_Treatment.

person Shiva    schedule 07.02.2014
comment
а как насчет конкретных данных лечения? Я имею в виду данные, которые должны быть полем в одном типе обработки, но не в другом. - person martskins; 07.02.2014
comment
Это будет в tbl_Treatment как поле с именем Description. Если вы хотите отследить, каким именно образом было оказано лечение при посещении пациента, то это должно быть поле в tbl_Visit_Treatment в поле с именем TreatmentDescription. Так, например, если у вас есть "Root Canal" в качестве лечения, tbl_Treatment будет иметь ID = 2, Code = ROOTC, Description = лечение корневых каналов, InsuranceCode = XYZ01 и т. д. А tbl_Visit_Treatment будет что-то вроде VisitID = 4, TreatmentId =2 TreatmentDescription = Удалить корень в корневом канале Зубы S2, закрытые колпачками. и т.п. - person Shiva; 07.02.2014
comment
Но как насчет свойств, которые необходимо сохранить при лечении корневых каналов? Например, как бы вы сохранили номер зуба как атрибут вместо строки в описании? - person martskins; 07.02.2014