Как хранить данные, которые могут быть структурированы или неструктурированы одновременно?

Question

У меня есть база данных со следующей таблицей:

PATIENT (PATIENT_ID*, MEDICAL_EXAMINATIONS) 

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

В последнее время было решено, что медицинское обследование может быть сообщено КАК как свободный текст (как всегда) ИЛИ структурированным способом (разделенным на имя экзамена, дату, результаты и т. Д.).

Так я думал, изменить схему, как последующие (поля, отмеченные звездочкой составляют ключ):

PATIENT (PATIENT_ID*, MEDICAL_EXAMINATIONS) 
MEDICAL_EXAMINATION (PATIENT_ID*, NUMBER*, NAME, DATE, RESULT) 

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

Я действительно не знаю, как выразить свой вопрос, но эта ситуация кажется СТРАННОЙ для меня. Интересно, возникает ли проблема из-за ошибки из спецификации (которую я не могу изменить) или если есть лучший способ моделировать «две версии» данных.

Answer 1

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

PATIENT(PATIENT_ID) 
MEDICAL_EXAMINATION(PATIENT_ID,NAME,DATE,RESULT) 
MEDICAL_EXAMINATION_NOTES(PATIENT_ID,NOTES) 

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

Это дает вам дополнительную гибкость, так как вы могли бы иметь несколько экзаменов «свободной формы» в какой-то момент в будущем, если хотите.

Выбирать оба из них всегда будет хлопотно, так как у вас есть другое строение данных. Вы, вероятно, будет ограничена наименьшим общим знаменателем и вытащить их как строки, если вы хотите, чтобы получить их вместе, вот так:

SELECT 'Name ' + NAME + ', Date ' + DATE + ', Result: ' + RESULT AS EXAM 
FROM MEDICAL_EXAMINATION WHERE PATIENT_ID = @PATIENT_ID 

UNION ALL 

SELECT NOTES AS EXAM FROM MEDICAL_EXAMINATION_NOTES WHERE PATIENT_ID = @PATIENT_ID 

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

Answer 2

Вы можете добавить столбцы NAME, DATE, RESULT в таблицу PATIENT. Если условие «имеет либо произвольные или структурированные данные, но не оба», должно быть выполнено, вы можете добавить триггер, который предотвращает нарушения условия.

Answer 3

Я хотел бы сделать:

• Пациент: ID, имя, дата рождения, экзаменационной и т.д.
• медицинская экспертиза: ID, ID пациента (FK), имя, дата, результат

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

Однако при этом возникают всевозможные проблемы обнаружения и контроля ошибок. Медицинская транскрипция - деликатная область (понятно).

Возможно, вы могли бы нормализовать это и описать каждый возможный экзамен, дать ему идентификатор и другие данные, а затем поместить идентификатор экзамена в объект медицинского осмотра вместо простого столбца «Имя».

Но все зависит от ваших требований.

Answer 4

Это не очень хорошая ситуация. Один из подходов, который может быть немного чище, заключается в том, чтобы оставить медицинскую экспертизу из таблицы пациентов (она все равно не принадлежит), а таблица медицинского осмотра имеет имя пациента, имя, дата, результат и свободный_текст. Если значение free_text для данной строки введено, остальные игнорируются. Это означает, что вы не можете, например, сделать дату обязательным полем в БД, но она по-прежнему лучше, чем текущая версия.

Это также даст вам путь к переходу от худшего к лучшим данным:

Фазы 1: большинство пациентов имеют одну связанную medical_examination строки с бесплатным текстом, который описывает несколько экзаменов.

Фаза 2: у большинства пациентов есть несколько взаимосвязанных медицинских строк с бесплатным текстом, который описывает каждый отдельный экзамен.

Фаза 3: у большинства пациентов есть несколько связанных медицинских рядов со строгими данными для каждого отдельного экзамена.

Answer 5

Вы можете добавить комментарий к столбцу в таблицу MEDICAL_EXAMINATION.

Это будет выглядеть

MEDICAL_EXAMINATION (PATIENT_ID, NAME, DATE, RESULT,comment) 

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

Answer 6

Одно из основных правил реляционных баз данных было выражено Джо Селко как «Один факт, одно место, один путь» (иногда добавляется «Одно время»). Имея данные - очень важные данные, по внешнему виду - присутствуют два раза в базе данных, хранятся в двух очень разных моделях, это не очень хорошая идея. Не могли бы вы сделать что-то вроде этого:

• Если есть ключевые факты, которые должны присутствовать на экспертизу, создать столбцы для них (как и для имени, дата, Result)
• Учитывая, что, что еще может быть включенным в описания? Я попытался бы получить это отдельно и сохранить в его собственном столбце (скажем, комментарии)
• С этим вы можете построить «стандартизованное» бесплатное текстовое описание «на лету» на основе соответствующих данных.

Что-нибудь еще, и вам придется сортировать два разных и потенциально несогласных источника для вашей информации.

Answer 7

Что мы имеем здесь, является примером полуструктурированных данных, один из способов борьбы с этим - использовать поле типа данных XML для ExamDetails. Вы могли бы:

<root> 
<ExamName></ExamName> 
<ExamResult></ExamResult> 
<FreeText></FreeText> 
</root> 

Не все элементы должны присутствовать в каждой записи. Вы должны использовать свои возможности XML-XML для запроса поля. Все мэры (MS SQl Server, Oracle, DB2) могут хранить и запрашивать XML.

Немного больше нот:
я бы минимум три таблицы: Пациент, доктор, экзамен

TABLE Patient (ID (PK), Name, other patient details...) 
TABLE Doctor (ID (PK), Name, other doctor details...) 
TABLE Exam (ID (PK), PatientID (FK), DoctorID (FK), Date, ExamDetails XML, more here...) 

Если оба врача и пациента, случается, люди (в отличие от ветеринарной клиники или осмотра дома) вы могли бы добавить таблицу Person и подтипы пациента и доктора в таблицу Person - таким образом, в клинике также может быть врач в качестве пациента. Например:

TABLE Person (ID (PK), FirstName, LastName, Phone, Address, other details common to people...) 
TABLE Patient (PersonID (PK, FK), ...specific patient details only) 
TABLE Doctor (PersonID (PK, FK), ...specific doctor details only) 
TABLE Exam (ID (PK), PatientID (FK), DoctorID (FK), Date, ExamDetails XML, more here...) 

Поскольку пациент и доктор являются тип человека, PersonID должна быть такой же номер, что и идентификатор в таблице Person.

Answer 8

Это сложная проблема, и у вас есть несколько хороших ответов здесь, что я нахожусь в процессе upvoting, как я их интерпретировать.

Моим личным путем было бы разделить колонку бесплатных текстовых экзаменов из рядов пациентов. В большинстве физических моделей это будет ntext, text или varchar (MAX) или подобное, и вы не хотите, чтобы он занимал место в строке, и эти типы обычно хранят свои данные за пределами строки, но в любом случае , хорошо разобраться. Как правило, у меня было бы 1-1 на пациента. Это делает ваши пациенты более компактными и более управляемыми.

Тогда я бы сделал отдельную таблицу, в которой данные интерпретируются, извлекаются и нормализуются в столбцы и строки, много-1 с пациентом.

Вы говорите, что данные ИМЕЮТСЯ. Если это так, свободный текст не нужен для сохранения, и вы можете использовать нормализованную таблицу экзаменов (и даже сделать вид, чтобы восстановить исходный «свободный текст»)

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

Answer 9

«В последнее время было принято решение о том, что медицинское обследование может быть сообщено как свободный текст (как всегда) ИЛИ структурированным способом (разделенным на имя экзамена, дату, результаты и т. Д.)».

Это поражает меня как нерешенное решение (возможно, сделанное non-cognoscenti). Из того, что я могу сделать из этого, это так называемое «решение» по-прежнему оставляет провайдеру информации свободу предоставлять информацию так, как он хочет, структурирован или неструктурирован. (Примечание: мой ответ не применяется, если поставщик информации вынужден сделать окончательный выбор между «структурированными» и «неструктурированными».)

«Структурированный» означает, что существуют «правила компоновки» (например, CSV) и «правила контента» (например, «имя экзамена должно быть именем известного курса/экзамена»), которому должен соответствовать поставщик информации.

Но «неструктурированные» по определению будут по-прежнему иметь в виду, что «независимо от информации, предоставляемой поставщиком информации, эта информация всегда будет по крайней мере удовлетворять« неструктурированным », поэтому любая информация, по определению, всегда приемлема в соответствии с «неструктурированной» интерпретации.

Таким образом, это так называемое «решение разрешить структурированное слишком» имеет значение , не имеет никакого значения для всех. И (принимая во внимание предостережение, о котором я упоминал), логический вывод состоит в том, что «не делать ничего вообще» с этим решением (которое кажется совершенно фальшивым) является вашим лучшим вариантом.

Без сомнения, вы будете думать: «Но я просто не могу этого сделать». Возможно, вы правы, если ваше руководство полностью нечувствительно к логически обоснованным рассуждениям.

PS

Что касается замечания, которые были сделаны «» Один факт, одно место, One Way»: (! ВРЕМЕННО) Такие случаи, как это могло бы быть иллюстрацией того, почему иногда нужно расслабиться, что «Один факт, одно место, одно из двух возможных способов». Просто для того, чтобы облегчить переход на скорости пользователей.