1

我有一个包含下表的数据库：

PATIENT (PATIENT_ID*, MEDICAL_EXAMINATIONS)

其中该字段MEDICAL_EXAMINATIONS包含对患者进行的检查的自由文本描述。

最近，决定可以以自由文本（一如既往）或结构化方式（按检查名称、日期、结果等划分）报告体检。

所以我想改变模式如下（用星号标记的字段组成键）：

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

但我发现这个解决方案有点令人不安，因为我将相同的信息（体检）存储在两个表中。在这种情况下，“选择患者进行的所有体检”的查询结果就不是那么“优雅”了。

我真的不知道如何表达我的问题，但这种情况对我来说似乎很奇怪。我想知道问题是否源于规范（我无法更改），或者是否有更好的方法来模拟数据的“两个版本”。

4

9 回答 9

3

就个人而言，我会将医疗检查的概念完全从患者分离到两个单独的表格中，如下所示：

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

“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

更好的是，如果该数据库支持某种业务对象，则有一个用于“自由格式”和“结构化”检查的单独类，然后是一个提供医疗检查字符串表示的通用接口。这样，您的业务层可以选择单独处理它们或一起使用它们。

于 2009-10-29T13:46:46.040 回答
2

我会做：

  • 患者：身份证、姓名、出生日期、检查等
  • 体检：ID、患者 ID (FK)、姓名、日期、结果

将Patient.Examination自由文本字段视为基本上未处理或尚未转录的考试。这个想法是，当您从自由文本字段中转录数据时，您将其从那里删除并将其添加到另一个表中。

然而，这带来了各种错误检测和控制问题。医学转录是一个微妙的领域（可以理解）。

可以说，您可以进一步规范化并描述每个可能的检查，给它一个 ID 和其他数据，然后将检查 ID 放入体检实体而不是简单的名称列。

但这一切都取决于您的要求。

于 2009-10-29T13:44:10.013 回答
2

这不是一个很好的情况。一种可能更简洁的方法是将体检排除在患者表之外（无论如何它都不属于那里），并让体检表具有患者 ID、姓名、日期、结果和自由文本。如果输入了给定行的 free_text 值，则忽略其他行。例如，这意味着您不能将日期作为数据库中的必填字段，但我认为它仍然比当前版本更好。

它还可以为您提供从更差数据向更好数据过渡的途径：

阶段 1：大多数患者都有一个相关联的 medical_examination 行，其中包含描述多项检查的自由文本。

第 2 阶段：大多数患者有多个相关联的 medical_examination 行，其中包含描述每个单独检查的自由文本。

第 3 阶段：大多数患者有多个相关联的 medical_examination 行，其中包含每个单独检查的结构化数据。

于 2009-10-29T13:44:20.257 回答
2

Joe Celko 将关系数据库的主要规则之一表达为“一个事实，一个地方，一种方式”（有时会添加“一次”）。让数据——从外观上看非常重要的数据——在数据库中出现两次，以两种截然不同的方式存储，这不是一个好主意。你能做这样的事情吗：

  • 如果有必须在考试中出现的关键事实，请为它们创建列（就像您为名称、日期、结果所做的那样）
  • 鉴于此，描述中还可能包含哪些内容？我会尝试将其单独呈现并存储在它自己的列中（例如，评论）
  • 有了这个，您可以根据相关数据即时构建“标准化”自由文本描述。

其他任何事情，您都必须对两个不同且可能不同意的信息来源进行分类。

于 2009-10-29T13:50:42.543 回答
0

您可以将 NAME、DATE、RESULT 列添加到 PATIENT 表中。如果必须满足条件“具有自由格式或结构化数据，但不能同时具有两者”，则可以添加一个触发器来防止违反条件。

于 2009-10-29T13:43:46.657 回答
0

您可以将列注释添加到 MEDICAL_EXAMINATION 表。

它看起来像

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

因此，您可以将非结构化数据存储在注释列中。

于 2009-10-29T13:48:14.697 回答
0

我们这里有一个半结构化数据的示例，处理这种情况的一种方法是使用 XML 数据类型字段ExamDetails。你可以有：

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

并非所有元素都必须出现在每条记录中。您将使用您的 DB XML 功能来查询该字段。所有的市长 DB（MS SQl Server、Oracle、DB2）都可以存储和查询 XML。

更多注意事项：
我将至少有三个表格：Patient、Doctor、Exam

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 和子类型 Patient 和 Doctor 表格添加到 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...)

因为 Patient 和 Doctor 是人员类型，所以 PersonID 应该与 Person 表中的 ID 相同。

诊所模型

于 2009-10-29T16:22:33.347 回答
0

这是一个难题，您在这里有几个很好的答案，我在解释它们时正在投票赞成。

我个人的路径是将自由文本检查列从患者行中拆分出来。在大多数物理模型中，它将是 ntext、text 或 varchar(MAX) 或类似的，并且您不希望它占用行中的空间，并且这些类型通常将它们的数据存储在行之外，但无论如何，拿出来就好了。通常，我会对患者进行 1-1 调查。它使您的患者行更小，更易于管理。

然后我会制作一个单独的表，其中数据被解释、提取和规范化为列和行，与患者多对 1。

你说数据是一样的。如果是这样，自由文本是没有必要保留的，你可以使用规范化的考试表（甚至可以做一个视图来重构原始的“自由文本”）

实际上，我通常会将自由文本视为遗留文本并限制对其的访问，并从规范化数据中驱动所有视图和更新。如果自由文本需要与规范化版本保持同步，有许多技术可以像触发器一样处理这种情况，但是如果允许更改个别事务并且“自由文本”需要有一些，它们可能会非常混乱部分改变。

于 2009-10-29T18:02:42.833 回答
0

“最近，决定可以以自由文本（一如既往）或结构化方式（按考试名称、日期、结果等划分）报告体检。”

这让我觉得这是一个非决定（可能是由非行家做出的）。据我所知，这个所谓的“决定”仍然让信息提供者可以自由地以他想要的任何方式提供信息，无论是结构化的还是非结构化的。（注意：如果信息提供者被迫在“结构化”和“非结构化”之间做出明确选择，我的回复将不适用。）

“结构化”是指信息提供者必须遵守的“布局规则”（例如 CSV）和“内容规则”（例如“examName 必须是已知课程/考试的名称”）。

但是，根据定义，“非结构化”仍然意味着“无论信息提供者提供什么信息，该信息将始终至少满足“非结构化”，因此根据定义，提供的任何信息在“非结构化”下始终是可接受的。结构化”的解释。

因此，这个所谓的“允许结构化的决定”对你来说根本没有用。而且（考虑到我提到的警告），合乎逻辑的结论是，对这个决定（这似乎完全是假的）“根本不做任何事情”是你最好的选择。

毫无疑问，你会想“但我就是做不到”。你可能是对的，如果你的管理层对逻辑上有根据的推理完全不敏感。

附言

至于已发表的评论““一个事实，一个地方，一种方式”：诸如此类的案例可能说明了为什么有时有必要将其（暂时！）放松为“一个事实，一个地方，一个两种可能的方式”。只是为了促进以用户的速度进行过渡。

于 2009-10-29T20:53:28.957 回答