基于web的临床数据库的通用设计

简介

临床数据库可能包含来自不同领域的大量数据，例如，患者就诊、测试结果、实验室报告、诊断、治疗、药物和程序。临床数据库可能有不同的用途，例如，患者管理、电子患者记录、临床研究和质量控制。临床数据库通常有大量的用户，他们对数据库的视图有不同的需求。管理员不希望查看每个患者的数据，而护士必须能够查找特定患者的当前药物。研究人员可能希望对数千或数百万名患者的临床信息进行数据挖掘，而临床医生应该能够看到他或她的门诊时间表。大多数临床数据库只包含这些功能的一部分，但是这些例子说明了临床数据库设计者所面临的挑战。此外，与许多其他领域(如金融和公共管理)的模式相比，临床数据的逻辑数据模式总是不完整的和不断发展的。

在数据库中，实体是可以存储关于其数据的单个人、地点或事物(例如，患者或诊断测试)。在传统的关系数据库设计中，使用一行或多行的值将每个实体映射到一个或多个表，以唯一地标识每条记录。这意味着对于每个实体至少存在一个表。这种策略适用于大多数数据库，即使域中涉及的概念数量可能很高。只要感兴趣的领域保持相对不变，那么表布局(即物理模式)应该可以工作很多年。然而，特别是临床科学领域(以及一般的生物学)，随着新概念的出现和旧概念的修改或推迟，一直处于不断发展之中。

在传统数据库(即传统关系数据库)中，必须创建新表来记录新概念。为了使用户能够访问新表，必须设计新的表单，并且必须在用户界面中提供到这些表单的链接。如果需要修改数据库中已经存在的表，则必须注意不要破坏现有数据，也不要破坏任何约束。因此，必须重新设计用户界面表单，以反映现有表中的更改(例如，已添加或删除的字段)。

因此，如果使用常规设计来布局数据，那么临床信息领域的复杂性、快速演变和扩展就需要大量的维护开销。因此，临床数据库应该灵活，允许修改和添加新类型的数据，而不必更改物理数据库模式。因此，理想的临床数据库应该在完全通用的物理模式中实现高度详细的逻辑数据库模式，该模式将各种临床数据存储在少量(且不变)的表中。

这个项目的目的是提供基于web的临床数据库通用设计的技术和问题的概述。

方法

通过PubMed搜索Medline [1］．通过使用关键字组合进行试错来进行搜索，以获得涉及该问题的文章的最佳匹配。此外，为谷歌设计了一种搜索策略[2]使用类似的试错策略。

结果

最后一次PubMed搜索是在2003年7月11日进行的，搜索词是:

这一术语被PubMed翻译为:

找到了33篇论文，根据题目选出了13篇。其中，有7篇论文是基于其摘要和全文论文[3.-9]都是从丹麦国家科学与医学图书馆下载或订购的。

谷歌在同一天使用搜索词进行搜索:

搜索仅限于前30个搜索结果。额外一篇论文[10]及1个网页资源[11]的兴趣被发现。

这9个资源全部来自两个研究小组:纽约哥伦比亚大学医学信息系和康涅狄格州纽黑文耶鲁大学医学信息学中心。这两个研究小组的研究以三个生产数据库为基础:哥伦比亚长老会医学中心(CPMC)的临床数据存储库、适应性临床试验数据库(ACT/DB)和SENSELAB。

中国石油物资公司(8-10它是一个大型的临床资料库，可以追溯到20世纪90年代初，里面有数百万病人。多个前端应用程序提供了对数据库的访问，为卫生保健专业人员、管理员和研究人员提供了不同的视图。

行为/ DB [3.，4，6，7，11是一个临床试验数据库，建立在与CPMC相同的设计原则之上。Nadkarni等人介绍了术语“实体-属性-值(EAV)设计”，用于关系数据库中数据的通用结构[7］．该数据库可透过一般的网页介面(WebEAV)查阅[4］．用于显示和编辑数据的Web表单是在运行时从存储在数据库中的元数据自动生成的。

SENSELAB [5是一个异构神经元数据的数据库。因此，它不是一个临床数据库。然而，SENSELAB体系结构通过定义类和关系(EAV/CR)对EAV模型使用了面向对象的方法。一般来说，EAV/CR架构对科学数据很有用，但它对临床数据库特别有意义。

这些数据库所涉及的原则和设计问题是本文其余部分的重点。我不会详细介绍这些系统的具体实现，而是介绍通用数据库系统设计中涉及的技术。有关这3个数据库系统的设计细节，建议读者参考参考文献。

Entity-Attribute-Value设计

在传统的数据库设计中，每个感兴趣的参数都表示在表中的单独列中。由于需要管理新的数据类型，列和/或表的数量也需要增长。

若要向传统的关系数据库设计中添加用于患者描述(例如，电话号码)的新属性(表1)，则必须向表中添加另一列。

然而，在EAV设计中，数据可以存储在单个表中，其中(概念上)有3列:1列用于实体标识，1列用于属性，1列用于属性值(表2）.

要在EAV表中添加电话号码属性(表2)，所需要做的就是为存储在属性列中的电话号码定义一个新代码。不需要更改表模式。理论上，存储在数据库中的大多数事实都可以存储在单个EAV表中。

EAV设计有几个优点:

• 灵活性:每个实体的属性数量没有限制。逻辑数据库模式可以在不影响物理模式的情况下增长。
• 储存:在临床数据库中，可以获得数千个参数，而每个患者只能记录少数几个参数。在传统的设计中，这可能会导致空字段(NULL)。EAV设计不需要为具有NULL值的属性保留空间。
• 以实体为中心的高效查询:例如，如果需要单个患者的所有信息，则有必要查询所有数据表以查找关于该患者的信息。在传统数据库中，这可能是一项耗时的任务，需要查看数百个表，每个表中可能有或没有该患者的信息。随着表和列数量的增加，必须对查询重新编程。在EAV数据库中，只需要查询1个表，不需要连接，随着域的发展不需要更改代码。(连接基于一个公共属性组合来自2个或更多表的数据。)

然而，EAV设计有一些缺点:

• 数据显示:正如后面讨论的那样，用户自然认为数据按常规组织在表和列中，而不管数据的物理布局如何。因此，在显示数据时，可能需要将(“枢轴”)EAV数据转换为常规布局。这和传统数据库自动执行的其他任务(例如，参考完整性检查或表单到子表单链接)需要在EAV设计中进行大量的前端编程。(参考完整性检查是检查一个表中打算用作另一个表的键的值是否确实在第二个表中找到。)
• 以属性为中心的查询效率较低:与以实体为中心的查询相比，基于属性值的复杂的以属性为中心的查询在EAV数据库中的效率明显较低，而且在技术上比在传统数据库中更难。查询“show me name以……开头的所有患者”J在传统数据库中，谁的出生日期早于1970年是很简单的。要在EAV数据库中实现相同的结果，必须在多个版本的EAV表上执行集合操作(例如INTERSECT)或连接。(INTERSECT是一种比较两个查询以识别在两个查询中都找到的记录的操作。)设置操作和连接比简单的选择操作慢得多。随着属性数量的增加，执行时间会呈指数增长。后面将更详细地讨论查询EAV数据。
• 约束检查:在设计良好的常规数据库中，约束检查不是不必要就是微不足道。例如，在常规表中，可以在列上放置非空约束，以防止保存不完整的记录。例如，如果用户忘记填写表单上的某个字段，就会出现不完整的记录。在EAV表中，缺少属性-值对通常会导致缺少记录。例如，如果EAV表中没有保存一个患者的姓氏记录，从逻辑角度来看，这将导致数据不一致，即该患者的数据将与其他患者的数据不相似。为了防止这种情况发生在EAV数据库中，应该将此类约束的检查编程到用户界面中。

元数据

EAV设计是一种简化数据库物理模式的方法，使其与领域无关。不管物理模式如何，用户自然会将数据视为表和列中的常规结构。的逻辑模式数据库的好坏反映了用户对数据的看法。在EAV数据库中，逻辑模式与物理模式有很大不同。在传统数据库中，这两者是相似的。因此，EAV系统必须有一些将物理模式转换为反映用户对数据理解的逻辑模式的方法。这是通过元数据(或字典)表实现的，其内容定义了被建模的域的语义。元数据表的一个例子可以是列出数据可用属性的表表2．在这个例子中，元数据表将有2条记录，Name和DateOfBirth。如果有必要记录关于患者的进一步信息，如性别和电话号码，则只需将这些信息添加到元数据表中。因此，在这种情况下，元数据表示传统数据表的列名。通过向元数据表中添加更多的描述性属性，元数据模型可以得到极大的增强。这些属性可能有多种用途——例如，定义属性的数据类型、约束或显示布局(文本字段、选择框等)。这些问题将在下一节中更详细地讨论。

EAV模型的演变

在下面的部分中，我将给出不同的EAV模式示例，从最简单、最不灵活的模式到最先进、最灵活的模式。“简单”一词不应被解释为不充分。简单的解决方案可能是特定任务的正确解决方案。

这些例子反映了文献中描述的系统，但出于教学原因进行了简化。

简单的EAV模型

中概述了临床数据库的简单EAV模式图1．

‎ 查看此图

表3的模式中描述的数据库表图1．数据被安排在一个用于患者人口统计的常规表、一个用于临床事件的EAV表和一个定义EAV表可用属性的元数据表中。表3代表来自的患者表1在2003年7月1日至2003年7月11日的流感病程结束后:

Data表的实体部分由patientID和date的组合定义。attributeID列包含对Attribute表的引用，该表定义了可用属性的名称和类型。在实际的生产数据库中，可能会有另一个表保存数据类型的定义。

值当然可以是任何类型，例如文本、数字或布尔值(true/false)。在表3， Data表的Value字段为文本类型。这种设计通过将所有简单类型存储为文本值来实现简单性。然而，这种方法有一些缺点。首先，并非所有数据类型都适合文本字段。二进制对象，如x射线图片或心电图曲线，和长文本(备忘录字段)一样太大。其次，基于值的查询对于非文本值的效率较低。文本“12”比文本“2”小，尽管它在数字上更大，因为文本是从左到右逐字符排序的。

已经使用了不同的策略来存储二进制数据和提高基于值的查询的效率。简单的解决方案是忽略这个问题，并接受所有值都存储为文本。如果不需要存储二进制数据，并且不需要对大型数据集进行基于值的快速查询，那么这种方法可能是完全可以接受的。另一种方法是为每个必要的数据类型在Data表中添加一列。对于每条记录，只会填充1个值字段(表4）.

当然，这种方法不符合良好数据库设计的规则，因为每条记录都记录了空字段。然而，在小型“快速而肮脏”的应用中，它可能是可以接受的[12］．

从数据库设计人员的角度来看，最可靠且正确的解决方案是根据属性的数据类型将数据表隔离为多个表(表5）.

该方法应用于CPMC、ACT/DB和SENSELAB。为了简单起见，我选择在插图中只显示一个数据表。

在单独的常规表而不是EAV表中建模患者人口统计数据是有意为之(尽管没有必要)。对于不希望经常更改的模式，例如患者人口统计情况，EAV布局的优点并不超过缺点;传统餐桌和EAV餐桌可以愉快地共存。此外，这种设计便于对患者和临床事件之间的一对多关系进行建模。在简单的EAV设计中，EAV表中实体之间的关系建模非常复杂。例如，在电子病人记录系统中，应该能够记录临床事件之间的关系(例如，感染导致青霉素疗程或心肌梗死导致死亡)。稍后将使用EAV/CR模式描述EAV设计的增强，以处理类之间的复杂关系。

对于主要用于数据输入的简单应用程序，简单的EAV模式就足够了。然而，由于需要更高级的用户界面来实现数据显示和输入目的，一些分组属性的方法就变得必要了。使用简单的EAV模式，只能根据实体(patientID和date)或属性对显示表单上的属性进行分组。应用程序没有办法告诉EAV数据记录是如何相关的，应该一起显示——例如，来自同一个血液化学面板的多个值。

增强EAV模型

为显示目的对相关属性进行分组可以通过几种方式实现。可以将一个或多个描述性列添加到数据表的“实体部分”，或者可以增强元数据模式。中显示了这两种方法的组合示例图2．

‎ 查看此图

元数据模式中已经添加了组表和表单表。属性现在可以分组，属性组可以是表单的一部分。数据表的实体部分添加了一个新字段formID，告诉应用程序数据记录属于哪个表单。现在，数据表中记录的任何医疗事件都属于一个表单，然后可以与该表单上的所有其他属性一起显示。此外，这种设计便于在不同形式上重用属性组。

根据所建模的域和用户的需求，其他元数据模式可能是合适的。

上面讨论的简单的和增强的EAV模式是在临床数据库应用程序中使用通用EAV表的例子。尽管在某种程度上是通用的，但所提议的模式将需要根据实际的领域进行调整。为了实现完全的领域独立性，必须创建更精细的模型。

面向对象的EAV建模方法

EAV/CR模型通过定义类和关系为EAV模型添加了面向对象的框架。EAV/CR模型一般是为科学数据开发的，但对临床数据有用[5］．

图3展示了SENSELAB数据库中使用的EAV/CR表布局的简化示例。类和属性表保存类及其字段的定义。ClassHierachy表记录了类之间的关系。在这个例子中，一个子类可以有任意数量的超类，一个超类可以有任意数量的子类。属性表记录了属性所属的类和属性的类型。属性可以是任何简单类型，甚至可以是类类型。类实例(对象)记录在Object表中，实例字段记录在Data表中，这与简单EAV模型中的数据表类似。

‎ 查看此图

例子是表6描述2个类，病人和医生，它们是一个普通人类的子类型。患者类有一个对象类型的属性，指向患者的负责医生。为了可读性，id以名称而不是数字的形式呈现。

的使用继承而且作文在数据库设计中。继承和组合是面向对象编程中的两个重要概念。继承可以看作是对象之间的“是-是”关系，即患者是一个人，还有医生是一个的人。组合通常被称为“有-有”关系-病人有一个医生。

因此，使用这种简单的布局(概念上)只有5个表，任何现实世界的对象都可以被记录。此外，对象可以是其他对象的一部分;对象可以通过继承进行关联。物体之间的特殊关系(如青霉素导致皮疹)可以记录为物体本身。出于这个目的，可以用两个属性定义一个类ObjectRelation, objectID和relatedObjectID。如果需要，可以向该类添加更多的描述性属性——例如，因果关系。

显然，在实际生产环境中，需要大量的前期编程来驱动EAV/CR模型的人体工程学用户界面。另一方面，这是一次性的工作。EAV/CR设计的另一个缺点是，为了设计有用的类，系统管理员必须对面向对象框架有深刻的理解。因此，EAV/CR数据库很难成为普通临床医生或研究人员的最终用户工具。一如既往，灵活性是有代价的。

查询EAV数据

从数据库的角度来看，查询EAV数据与查询常规数据没有什么不同。然而，如前所述，在EAV数据库中，物理布局与逻辑布局有很大不同，用户通常希望看到以常规格式显示的数据。

以查询为例表1了解那些名字以延斯1970年之前出生的人是很直接的:

SELECT * FROM table1 WHERE name LIKE 'Jens%' AND dob < '1970';

从查询中获得相同的结果表2需要执行一个相当复杂的SQL(结构化查询语言)语句:

选择d1。patientIDAS patientID, d1.value AS name, d2.value AS dob FROM table2 AS d1 INNER JOIN table2 AS d2 USING (patientID) WHERE d1.attribute='name' AND d1.value LIKE 'Jens%' AND d2.attribute = 'dob' AND d2.value < '1970';

可以通过几种方式获得相同的结果，但在任何情况下，查询都必须包括集合操作(INTERSECT)，或者像本例中一样，每个属性都有一个自连接。(自连接是表与自身的连接。)这些操作不仅复杂而且对大多数终端用户来说难以实现，而且比简单的选择语句要慢得多。

我做了一个实验，使用100万名患者的数据，用3个属性来描述:姓名、出生日期和性别。这些事实在一个常规表和一个MySQL数据库的EAV表中被复制。分别对具有1、2和3个属性的表执行三个查询。对于常规表，不管属性的数量如何，执行时间大约为2秒。EAV表的执行时间分别为7秒、14秒和24秒。因此，执行时间随着行数(常规表中为100万，EAV表中为300万)和EAV表中的行数(查询中涉及的连接数)呈线性增加。然而，在传统的表中，连接的数量并不影响查询时间。

有人提出了一些解决这个问题的策略:

• 可能没有问题。以属性为中心的查询对研究问题很重要;它们的表现对于个别患者的护理并不重要。如果不经常需要跨患者数据，则EAV设计的优点可能超过缺点。
• 任何对定期跨患者数据访问的需求都可以通过对生产数据库进行备份并将其恢复到单独的硬件上来满足。在备份数据上运行的资源密集型查询不会影响生产服务器。此外，EAV数据模式可以在备份后转换为许多常规表，从而简化了具有中等SQL技能的最终用户的查询设计[6］．
• 如果复杂的、以属性为中心的、用户定义的特殊查询对应用程序很重要，那么应该采取步骤来促进这一点。首先，应该构建一个用户界面，无论是否图形化，以帮助用户检索数据。用户应该能够自由地选择属性和标准的任何组合。然后，接口应该将用户请求转换为语义有效和语法有效的SQL语句;从用户的角度来看，数据是存储在常规表还是EAV表都不重要。Nadkarni和Brandt在开发ACT/DB查询内核时采用了这种方法[6］．
• 查询的优化可以大大提高效率。将复杂的SQL语句分解为按顺序运行的更小的部分可以提高查询速度。每个部分访问1或2个表来创建一个临时表(或视图)。然后将这些(较小的)临时表连接在一起[3.］．根据数据库引擎设计有效搜索策略的能力，与自连接完整的EAV表相比，创建和连接较小的临时表可以提高整体查询速度。然而，高效的数据库引擎本身应该能够优化原始查询，因此从这种方法中获得的好处很少。在上面描述的MySQL数据库中，创建一个临时表所花费的时间(超过30秒)比执行完整的3个属性搜索所花费的时间(24秒)要长。
• 约翰逊等[10]建议对SQL查询语言进行扩展，以促进将以属性为中心的数据“旋转”到传统的布局—扩展多功能(EMF) SQL。扩展的多特性SQL处理时间与属性的数量成线性比例。

总而言之，查询EAV数据比查询常规布局中的数据更复杂;与传统数据相比，EAV数据以属性为中心的查询效率较低。

图形用户界面

EAV数据库的用户界面设计人员面临的挑战是显示数据，并让用户模拟常规布局操作数据，而不考虑物理布局——换句话说:在物理模式和逻辑模式之间架起桥梁。

万维网提供了简化数据库部署和维护的机会。在典型的Web数据库应用程序中，用户的浏览器从远程Web服务器请求数据，远程Web服务器将请求发送到数据库服务器。从数据库服务器接收数据后，Web服务器将其格式化为Web页面并将其发送到客户机浏览器。

Web部署有以下几个优点:

• 表单部署的问题被消除了，因为所有表单都位于Web服务器上。
• 由于Web浏览器是免费的，因此可以降低部署成本。此外，硬件成本也降低了，因为浏览器通常比桌面数据库管理系统对硬件的要求更小。
• Web页面的表单呈现模型比传统软件平台的表单呈现模型更简单、更智能。当浏览器窗口调整大小或用户更改字体大小时，Web页面上的对象可以自动重新格式化。传统软件开发人员必须在物理屏幕大小问题上投入大量精力。这对于Web表单来说是不必要的。
• Web浏览器使用聪明的缓存算法。这意味着当浏览器访问一个特定的页面时，它的内容被缓存在客户端上。在重新访问时，只有更改过的组件才会再次下载。这减少了下载时间和网络负载。

由于这些原因，Web部署在多用户应用程序中变得越来越流行。但是，Web数据库应用程序的开发要比传统数据库应用程序复杂得多，原因如下:

• web开发工具不如传统软件开发工具成熟;Web数据库应用程序的开发仍然需要大量的“手工编码”。例如，一些简单的错误，如拼写错误的变量名，在传统环境中会在编辑或编译时被捕获，直到Web应用程序运行时才会被检测到。
• 浏览器-服务器通信本质上是无状态的;当服务器向客户机发送了一个Web页面时，它就会“忘记”客户机。因此，通过多个Web页面跟踪信息(例如，用户身份验证)需要进行额外的编程。为了维护信息，开发人员必须将数据存储在Web页面的(隐藏的)表单字段中，或者存储在会话变量中，只要会话持续，就可以访问这些变量。这两种方法都使开发复杂化，并可能危及安全性，因为其他用户(或进程)可能有意或无意地访问这些数据。
• 设计Web表单比在传统的客户机-服务器环境中设计表单需要更多的编程。Web表单字段是无类型的，用于格式化用户输入的输入掩码也不是Web表单的固有部分。(在无类型字段中，用户可能会意外地在纯文本字段中输入数字，或者意外地在纯数字字段中输入文本。)这给程序员施加了压力，要求他们在客户端和服务器端数据验证上都投入大量精力。在传统环境中，表单字段可以被类型化;因此，例如，程序员不需要担心用户在数字字段中输入字母或在日期字段中输入无效日期。在Web表单中，所有验证过程都必须手工编码。最后，用动态数据填充选择框(下拉菜单)和单选按钮(选项按钮)在传统环境中通常比在Web表单中容易得多。

对Web表单进行编程非常繁琐且容易出错，因此强烈推荐自动化。Nadkarni等人研究了用于显示和操作EAV数据(WebEAV)的自动生成Web表单的通用框架[4］．主要目标是基于EAV数据库中的元数据自动生成Web表单。当请求有关事件的详细信息时，将从所涉及属性的元数据生成一个表单。每个表单字段都有一个唯一的名称，该名称的构造使字段名称包含自己的元数据。当数据发送回服务器时，服务器通过解析字段名创建正确的SQL语句，并相应地更新数据。

WebEAV广泛使用客户端数据验证。JavaScript形式的标准验证代码内置于Web页面中。验证依赖于表单字段事件(如OnChange、OnFocus和OnBlur)和表单属性的元数据(如数据类型、最大和最小边界以及非空需求)的使用。

讨论

基于文献检索，实体-属性-值模型对于临床数据库的通用设计是有用的。最先进的模型使用面向对象的方法，并提供了极大的灵活性，允许设计人员在感兴趣的领域中建模任何类型的概念和概念之间的任何关系，而不必担心更改表布局或维护用户界面。随着临床信息领域的不断变化和发展，通用设计对于临床数据库特别重要，因为对逻辑模式的更改不会影响物理模式。然而，来自其他领域(如生物学或文学)的数据库设计人员可能也会发现EAV方法很有用。

从历史上看，EAV被引入到20世纪70年代杜克大学建立的TMR(医疗记录)的临床数据库中[13，14］．除了本文提到的，使用EAV组件的生产数据库还包括TrialDB [14]、HELP系统[15]、Cerner和3M资料库、ClinTrial和Oracle临床资料库。

EAV设计的利弊

通用设计的优点是显而易见的。然而，缺点可能不那么明显，并取决于所讨论的特定应用程序的目标。

从性能的角度来看，EAV设计的优势在于有效的以实体为中心的查询，因为在传统设计中，事实分布在数百个表中，检索关于实体的所有事实(例如，患者或医疗事件)不需要连接。缺点在于低效的以属性为中心的查询，因为请求的每个属性都需要(自)连接。

对于小型数据库，EAV表的性能可能不是问题，但对于拥有数百个并发用户的大型临床存储库，查询时间可能是一个关键因素。此外，不同应用程序对复杂的以属性为中心的数据检索的需求也有很大差异。例如，电子患者记录系统通常旨在显示以患者为中心(即以实体为中心)的事实，而研究数据库通常必须有一些方法来聚集大量患者的数据。但是，在后者中，查询效率可能不是问题，因为数据摘要只是间歇性地检索，并且可能存储在单独的硬件上。

这些问题要求仔细设计数据库模式，并谨慎决定何时使用常规表代替通用EAV表。根据经验，传统的表设计适用于模式不需要经常更改的实体(例如人或机构)。

元数据保存信息

数据库模式的简单性和灵活性也增加了从数据收集和显示信息的复杂性。用户需要在同一个表单上查看和输入相关数据。单个值通常没有意义，除非与其他值结合。以176磅(80公斤)的体重为例。对于一个身高5英尺10英寸(182厘米)的成年男性来说，这是非常正常的(对我们中的一些人来说也是可取的)。对于一个10岁的女孩来说，176磅是非常令人不安的。使用简单的EAV数据表布局，数据之间的关系会丢失，除非也采取步骤存储这些数据。这就是元数据的全部思想——保存关于原子数据值之间关系的信息。中给出的不同EAV模型之间唯一的区别是元数据模式图1，图2,图3以及文中给出的EAV模型的实际实现之间的差异。数据部分在实际用途上是相同的。

元数据模式本身可能或多或少是通用的，这取决于它们与实际建模的领域的密切关系。元数据模式越具体，它的灵活性就越低。另一方面，与高度通用的元数据模式相比，特定的元数据模式需要更少的编程来驱动用户界面。

总结这一部分，模型的选择取决于领域和灵活性的要求。面向对象的方法是迄今为止最灵活的解决方案，在许多方面都是一种优雅的解决方案。另一方面，除非域需要对对象和关系进行细粒度控制，否则此模型引入的复杂性可能是不合理的。简单的模型很可能是简单工作的正确解决方案。

数据库和对象

在推广临床数据库方面已经做了很多努力。最灵活和通用的模型采用面向对象的方法对关系数据库中对象到表的映射进行数据建模。毫无疑问，面向对象的设计在医学领域是“热门”的。但是，将面向对象的通用数据库从传统的关系数据库移植到生成面向对象的数据库管理系统(oodbms)似乎并不近在咫尺。其中一个原因当然可能是面向对象的数据库管理系统在效率和可用性方面仍然落后于关系数据库管理系统，尽管这一领域正在进行广泛的研究。此外，对于大多数设计数据库的临床医生来说，面向对象仍然是一个新概念。但是，即使对面向对象编程语言(如Java)有一定的掌握，面向对象编程和面向对象数据管理之间的相似之处似乎也很惊人。

面向对象的数据库有两种形式[16]:

• 通过向数据操作语言(如SQL)添加复合属性、类层次结构和扩展，为关系系统提供面向对象扩展的系统。这些系统被称为对象关系系统。
• 扩展现有面向对象编程语言(如c++或Java)以处理数据库的系统。这样的语言被称为持续的编程语言。术语“持久”指的是即使程序没有运行，编程语言也必须设计一些存储对象的方法。基于持久编程语言构建的数据库被称为面向对象的数据库。

前一种方法与本项目中描述的方法有相似之处，它们都建立在传统的关系数据库管理系统之上。SENSELAB数据库允许组合和继承，CPMC已经探索了SQL的扩展，以促进以属性为中心的EAV数据查询。

后一种方法通用的据我所知，医学文献中没有对数据库设计进行过描述。在每个对象中封装与对象相关的所有数据和功能的想法为临床信息系统的开发人员和管理人员提供了大量感兴趣的可能性:

• 面向对象范式(“一切都是对象”)是描述真实世界概念的一种方法，对于临床医生来说，对象可能比关系数据库中的复杂关系集更容易理解。可以说，面向对象设计将逻辑模式和物理模式结合在一起。即使这可能不完全正确，用户也不应该担心如何设计存储对象的表。数据库会处理这个问题。
• 面向对象语言处理复杂的属性和继承比设计最巧妙的关系数据库要优雅得多。在面向对象编程语言中引用对象时，用户可以通过对象的接口立即使用对象的字段和方法。要在关系数据库中模拟对象，必须查询数据库中所有感兴趣的属性，并且必须分别访问每个值。
• 对象可以包含方法。例如，person对象可能包含print()方法，该方法以合适的格式输出与对象相关的所有信息。构建用户界面的客户端程序员不必担心如何收集这些信息。程序员只需要获取信息，并将其以漂亮的布局呈现在表单上。此外，person类的不同子类型，例如patient或doctor，可能具有print()方法的不同实现。这是多态性的一个例子，也是面向对象编程语言最强大的特性之一。
• 类可以被重用。如果一个类已经设计好了，它可以在其他应用程序中重用;如果一个类被重新设计了(例如，为了提高执行速度)，只要类的接口没有改变，客户端程序员就不需要知道这一点。

面向对象编程的详细讨论超出了本文的范围。然而，面向对象编程的力量可以用以下术语来概括封装而且多态性．封装意味着对象了解自身的一切，并且仅通过定义良好的接口与周围环境进行交互。封装有助于重用和安全编程。多态性意味着“有多种形式”。多态引用可以在不同时间引用不同(子)类型的对象，这正是我们在泛型数据库中所需要的。

很明显，面向对象编程语言的这些(和其他)功能在创建通用临床数据库方面具有巨大的价值。然而，重要的是要认识到一个数据库管理系统，无论是面向对象的还是非面向对象的，包含的不仅仅是一种编程和查询语言——重要的问题是存储管理、事务管理和并发控制——这些问题在面向对象的数据库管理系统中仍然处于开发阶段。(并发控制包括锁定数据库的某些部分，以防止无意中覆盖数据。)

结论

通用数据库设计的目标是提供健壮的物理数据库模式，该模式不需要随着领域的发展而改变。通用数据库对临床信息系统有特殊的意义，已经实施了几种通用设计方法。它们共同使用实体-属性-值表来存储数据，并使用大量元数据表来描述数据之间的语义和关系。对元数据进行通用建模的面向对象方法是迄今为止最灵活且与领域无关的方法。但是，对于较低级的应用程序，采用这种方法的开销可能不合理。

建议进一步研究以通用临床数据库为目的的面向对象数据库管理系统的实现。