MySQL: слияние таблиц отношений один к одному

0

Я пытаюсь упростить базу данных приложения. В этой базе данных у меня есть две таблицы, где можно сказать " Patient и " MedicalRecord. Я знаю, что две таблицы называются отношениями "один-к-одному", если какая-либо данная строка из Table-A может иметь at most одной строки ine Table-B (это означает, что могут быть нулевые соответствия).

Но в моем случае это не at most, это exactly. т.е. каждая строка в Patient должна иметь exactly одну строку в MedicalRecord (нет пациента без медицинской записи).

Таблица Patient содержит все личные данные пациента с его идентификатором как PK. MedicalRecord talbe имеет такие детали, как его группа крови, гемоглобин, bp и т.д. С его идентификатором как PK и FK для Patient.

Мой вопрос: могу ли я объединить эти две таблицы и создать одну таблицу,

PatientDetails: personal_details и группа крови, гемоглобин, bp и т.д.

  • 2
    Если то, что вы описываете, является правильным, то технически обе версии являются действительными представлениями вашего отношения, вам разрешено объединить их. Вы даже можете сделать это с 1: 0, так как вы можете просто оставить каждое значение пустым. Вы будете разбивать 1: 1-реалии на отдельные таблицы по логическим причинам. Но я бы проверил вашу первоначальную гипотезу. Хотя группа крови обычно не меняется, я предполагаю, что артериальное давление, гемоглобин и тому подобное будут зависеть от времени, поэтому у вас может быть несколько значений для разных времен (например, если один и тот же пациент посещает второй раз).
Теги:
database
database-design

2 ответа

1
Лучший ответ

"bp" = "Кровяное давление"? Тогда вы не должны комбинировать таблицы. Вместо этого это 1: много - каждый пациент может иметь множество наборов показаний. Очень важно записывать и отображать тенденции в чтениях.

Положите только постоянные значения в Patient - имя, дата рождения (не возраст, вычислите, что), пол, раса (некоторые расы более склонны к определенным заболеваниям, чем другие), а не высота/вес. И т.п.

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

У каждого пациента должен быть MedicalRecord? Это "бизнес-логика"; проверить его в приложении; не зависят (в данном случае) от чего-либо в базе данных.

Обе таблицы будут иметь patient_id. Patients это было бы PRIMARY KEY; MedicalRecord would have INDEXed '. Это все, что нужно, чтобы иметь 1: много.

В ситуациях, когда таблицы действительно 1:1 (необязательно 1: 0/1), я рекомендую слить таблицу. (Есть исключения.)

  • 0
    Можете ли вы уточнить это => "bp" = "Артериальное давление"? Тогда вы не должны объединять таблицы.
  • 1
    Артериальное давление меняется, поэтому оно не должно быть частью одного ряда для каждого пациента.
1

Если две таблицы имеют один и тот же набор значений подстроек для общего набора столбцов, который является супер-ключом в обоих (SQL PRIMARY KEY или UNIQUE), вы можете заменить эти две таблицы своим естественным соединением. ("Естественное соединение", вероятно, означает то, что вы подразумеваете под "слиянием", но это не определенный технический термин.) Каждая исходная таблица будет равна проекции соединения на исходные столбцы.

(1:1 означает общее количество с обеих сторон, это не означает 1: 0 или -1, хотя большинство писем о мощности неаккуратно и неясно).

Ещё вопросы

Сообщество Overcoder
Наверх
Меню