Создайте объект базы данных, который имеет несколько значений для всех столбцов

Ниже приведена таблица фактической формы, которую мы дадим нашим пациентам для заполнения, чтобы сохранить информацию, которую они будут предоставлять во время их первоначального экзамена. Меня просят разработать/моделировать объекты базы данных для хранения этой информации. Я определил, что в основном поля в левой части этого изображения (например, "главная жалоба", "задний и т.д.") Являются атрибутами и станут столбцами в таблице. Флажки - это фактические значения для этих таблиц. Все столбцы могут иметь несколько значений (что означает, что для каждого столбца можно установить несколько флажков).

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

1) Создайте одну таблицу, которая будет иметь столбец для каждого возможного значения для каждого атрибута.

за и против (на мой взгляд):

  • Он сделает выбор и сохранение данных из этой таблицы для экрана, который мы проектируем, легко и просто.

  • Таблица будет очень широкой таблицей (в ней будет почти 200 столбцов)

Я нарушаю некоторые очень основные принципы проектирования баз данных здесь, создавая одну большую таблицу, которая вызовет проблемы в будущем, если есть изменения в экране/шаблоне?

2) Поверните все флажки в таблицы кодов (в основном они станут собственными)

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

Это приведет к созданию нескольких кодовых таблиц и одной коррелированной таблицы для каждого столбца. (На сегодняшний день имеется 18 коррелированных таблиц)

Если я последую этому дизайну, то, чтобы показать полную картину первоначального экзамена, мне придется выбирать данные из более чем 18 таблиц, участвующих здесь, и забыть об их обновлении.

Я склоняюсь к первому решению, потому что это просто,

Второе решение осложнено, и я считаю, что я нарушаю основные принципы проектирования баз данных, поворачивая столбцы/атрибуты (задний, передний и т.д.) На объекты, превращая их в коррелированные таблицы, тогда как они действительно являются атрибутами и должны приводить к столбцам. Мне нужно будет присоединиться к 18 столам, по крайней мере, если я хочу показать полную фотографию экзамена.

Надеюсь, что я изобразил свою дилемму здесь, мне нужно правильно спроектировать этот объект, и два вышеупомянутых подхода - это единственное, что я могу придумать, мне нужна помощь, чтобы принять решение, и может быть, есть еще одна сторона для всего этого, что я даже не принимая во внимание. Я надеюсь, что кто-то сделал что-то подобное раньше, и я могу обсудить это с ними.

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

таблица первоначального экзамена (основная таблица)

attributes/columns possible values
posterior class1 class11 crowded rotated
anterior overbite open bite upper lower
erosion spaced abraded fractured discolored
bleeding normal light moderate advanced

2 ответа

Нет необходимости повторно изобретать колесо, вам нужно: "Entity-attribute-value model"


Если я понимаю ваш вопрос, вы хотите построить таблицу атрибутов для хранения всех возможных значений атрибутов.

Вы можете создать таблицу атрибутов следующим образом.

Attribute
---------
Attribute
Value

Основной (кластеризационный) ключ (Атрибут, Значение). Вы бы выбрали SQL в атрибуте, и все строки значений будут возвращены.

Ваши строки будут выглядеть так:

Attribute Value
 ---------------- -----------------
 posterior class1
 posterior class11
 posterior crowded
 posterior rotated
 anterior overbite
 ...

licensed under cc by-sa 3.0 with attribution.