数据库设计问题

Question

我正在开发一个医疗应用程序，用户需要注册(在其他事情中)患者的临床保健和眼科测量。

临床病历由病史和家族史组成。它们都可以产生一般的病理(如糖尿病)和特殊的病理(如青光眼)。我被要求以两种方式对病理进行分类:如果它是一种特殊的病理，它必须定义眼睛的解剖部分，它是相关的；如果它是一种一般的病理，它需要定义对patology的描述。最后，我必须区分眼科测量是指右眼还是左眼。

现在我做了以下决定，但我不确定，我想听听别人的意见：

临床病史是一个表，其中包含一个日期列“最后更新日期”病理被分组到一个表中，该表具有一个数字pk列、一个名称列、一个描述和一个标志yes/no，该标志指定它是专业的还是一般的病理临床病史和pathology由一个主键绑定在一个表中，该主键由一个关于临床病史的fk和一个fk to pathology表组成，还有一个标志yes/no，用于定义它是患者的病理还是家族的病理。

眼科测量与检查表相关，每次检查可包含0-2条记录(左眼、右眼或不检查眼睛)，再次使用标志识别眼睛。其主键由检查表上的fk和标志组成。最后，由于测量始终存储相同的值类型(浮点数)和一组常见的测量值(类型)，这取决于所使用的仪器(轴、柱面等)，因此我添加了一个n:m (其中n是o-2)表，其中包含由眼科测量pk和仪器类型组成的pk

我对我不得不推断和分组数据的标志感到不舒服，另一方面，我还没有找到比重复表更好的东西来反映我得到的描述(例如，两个病理表，只是列名不同：“解剖部分”或描述)

我想对这个设计中的任何缺陷和任何改进提出一些评论，意见和建议

提前谢谢你

Answer 1

这是一个相当常见的问题--这在某种程度上与“如何在我的数据库中对面向对象的继承概念进行建模？”问题，Craig Larman的书“应用UML和模式”处理得非常好。

您可以选择-在名称反映业务域的特定表中对业务域进行建模本身没有任何错误。特别是对于长寿的应用程序，尽可能的清晰将会减少bug和疯狂。

如果我正确理解了您的问题，“特殊病理学”与“普通病理学”具有不同的属性-我肯定会将它们建模为两个单独的表。

对于您的“考试”表，我会考虑如下内容：

Table: examinations
ExaminationID
LeftEyeExaminationID - FK to EyeExaminations table
RightEyeExaminationID - FK to EyeExaminations table

Table: eye_examinations
EyeExaminationID
Value 

至于标志-真的，讨厌的，容易出错的。大多数数据库允许您定义“类型”，这至少将标志抽象为更易于理解的东西，就像C类语言中的常量一样。

Answer 2

您正在使用哪些医疗系统标准、分类方案和元数据模型？我假设你已经意识到有一系列关于这类事情的国家和国际标准:例如，SNOMED，ICD，HL7，HIPAA。如果您从遵循标准中定义的分类方案、代码和元数据开始，那么这应该是开始您的数据模型的良好基础。