Database design 数据库设计问题

我正在开发一个医疗应用程序，用户需要注册（除其他外）患者临床生理和眼科测量

临床病史由患者病史和家族史组成。这两种疾病都可以同时存在一般性疾病（糖尿病除外）和特殊性疾病（青光眼除外）。 我被要求从两个方面对病理学进行分类：如果是一种特殊的病理学，它必须定义与其相关的眼睛解剖部位；如果是一般病理学，则需要定义病理学的描述。 最后，我必须区分眼科测量是指右眼还是左眼

目前，我已经做出了以下决定，但我不确定，我想听听其他人的意见：

“临床病史”是一个表，其中包含患者的fk，并包含日期列“上次更新日期” 病理分为一个表，表中有一个数字pk列、一个名称列、一个描述和一个“是/否”标志，用于指定它是专门病理还是一般病理 临床病史和病理学由一个表绑定，该表的主键由fk on Clinical history和fk to patologies表组成，并带有一个标志yes/no，用于定义是患者病理学还是家族病理学

眼科测量与检查表相关，每次检查（左眼、右眼或未检查眼睛）可包含0-2条记录，眼睛用标志再次识别。其pk由检查台上的fk和标志组成。 最后，由于测量值总是存储相同的值类型（浮点）和一组通用的测量值（类型），具体取决于所使用的仪器（轴、圆柱体等），因此我添加了一个n:m（其中n是o-2）表，其中pk由光学测量pk和仪器类型组成

我觉得我不能用标记来推断和分组数据，另一方面，我还没有找到比重复表更好的方法来反映我得到的描述（例如两个病理表，它们只在列的名称上有所不同：“解剖部分”或描述）

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

---

提前感谢您

这是一个相当常见的问题-它有点与“如何在我的数据库中建模面向对象的继承概念？”问题有关，Craig Larman的书“应用UML和模式”非常好地处理了这个问题

您可以选择—在名称反映业务域的特定表中建模业务域本身并没有什么错误。特别是对于长寿命的应用程序，尽可能地清晰将减少错误和疯狂

如果我正确理解了你的问题，“特殊病理学”与“一般病理学”有不同的属性——我肯定会将它们建模为两个独立的表格

对于你的“考试”表，我会考虑一些类似的事情：

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

Table: eye_examinations
EyeExaminationID
Value 

---

至于标志——真实、恶劣、容易出错。大多数数据库允许您定义一个“类型”，它至少可以将标志抽象为更易懂的内容，就像C语言中的常量一样。

您正在研究哪些医疗系统标准、分类方案和元数据模型？我想您已经知道，这类产品有一系列的国家和国际标准：例如SNOMED、ICD、HL7、HIPAA。如果您首先遵循标准中定义的分类方案、代码和元数据，那么这应该是开始数据模型的良好基础