Name: 在关系 (MySQL) 和 NoSQL (MongoDB 和存在) 中执行复杂度增加的查询大小-增长的 ISO/EN 13606 标准化的电子病历数据库 (视频) | JoVE Journal
Uploaded: 2018-03-19T14:30:00.000+00:00
Duration: 7 min 26 s
Description: 了解关系型数据库MySQL与非关系型数据库MongoDB的计算复杂度差异，通过执行复杂度递增的查询并分析响应时间，为电子病历系统选择合适的数据库方案提供参考依据。

ai_agent_IP

ai_agent

maintenance

instantTrialDurationMinutes

isBiopharma

enableNewMyJoveSectionDesign

educationFeatures

seoMetaApi

ai_copilot_institution_blacklist

ai_chat_institution_blacklist

freeAccessWindow

ssoRoleCapture

scheduledMaintenanceBanner

joveLabsFeatures

disable_autoplay_for_bots

extended_trial_duration

5 minutes

作者谨此感谢 EHRCom 任务组负责人、定义 ISO/EN 13606 标准的 Dipak Kalra 博士及其来自伦敦大学学院的团队，感谢他们慷慨授权使用 ISO/EN 13606 W3C XML Schema。
本工作由卡洛斯三世健康研究所资助［资助编号：PI15/00321、PI15/00003、PI1500831、PI15CIII/00010 和 RD16CIII］。

1. 构建关系型 MySQL 数据库管理系统以存储三个双倍规模的标准电子健康记录提取数据库
<ol>
	<li>将对应于 ISO/EN13606 RM 和 ISO21090 数据类型的 W3C（World Wide Web Consortium）XML 模式导入“Java IDE”（集成开发环境）。 
	注意：ISO 代表国际标准化组织，EN 代表欧洲标准。</li>
	<li>在 IDE 中执行 JAXB（Java XML 绑定）插件；该操作将生成与电子健康记录摘要 XML 文件元素结构相对应的 Java 类。</li>
	<li>手动为 JAXB 生成的 Java 类添加 JPA 标签。这些标签用于定义 MySQL 数据库中关系表之间的基数及其他关联关系。</li>
	<li>将 JPA（Java 持久化 API）的库导入 IDE，并执行根据已标注的 Java 类构建 MySQL 数据库的方法。</li>
	<li>创建三个目录，分别包含 5,000、10,000 和 20,000 个符合实际的电子健康记录摘要 XML 文件。</li>
	<li>执行 JPA 方法，将 5,000 个摘要目录中的所有 XML 摘要文件加载到 MySQL 数据库管理系统中。</li>
	<li>重复步骤 1.6 两次，分别使用 10,000 个和 20,000 个摘要的目录。</li>
</ol>
2. 构建一个 NoSQL MongoDB 数据库管理系统以存储三个双倍规模的标准 EHR 提取数据库
<ol>
	<li>使用标准程序（例如 json.org.XML）处理包含 5,000、10,000 和 20,000 份真实电子健康记录（EHR）提取 XML 文件的三个目录，将 XML 文件转换为 JSON 文件。应生成包含 5,000、10,000 和 20,000 个 JSON 文件的三个目录。</li>
	<li>启动 MongoDB 图形用户界面（GUI，参见材料表）。</li>
	<li>在 DOS（磁盘操作系统）系统窗口中执行 mongod 程序，启动 MongoDB 2.6 服务器。</li>
	<li>使用端口 27017 将 MongoDB GUI 连接到本地主机（localhost）服务器。
	<ol>
		<li>选择&#34;连接&#34;菜单。</li>
		<li>为连接输入一个名称（例如“first”）。</li>
		<li>在数据库服务器文本框中输入 localhost:27017。</li>
		<li>点击&#34;连接&#34;按钮；左侧应出现当前数据库的树状结构。</li>
	</ol>
	</li>
	<li>构建一个包含 5,000 份标准化 EHR 提取数据的数据库。
	<ol>
		<li>点击左侧树状结构顶部的连接名称。</li>
		<li>选择&#34;文件&#34;菜单。</li>
		<li>选择&#34;添加数据库&#34;。</li>
		<li>在弹出的对话框中输入数据库名称。</li>
		<li>点击确定。</li>
	</ol>
	</li>
	<li>构建一个包含 5,000 份标准化 EHR 提取数据的集合。
	<ol>
		<li>点击左侧树状结构中的数据库名称。</li>
		<li>选择&#34;数据库&#34;菜单。</li>
		<li>选择&#34;添加集合&#34;。</li>
		<li>在弹出的对话框中输入集合名称。</li>
		<li>点击&#34; 创建&#34;。</li>
		<li>点击集合名称。</li>
		<li>选择&#34;导入&#34;菜单。</li>
		<li>选择单选按钮“JSON - mongo shell / / mongoexport&#34;。</li>
		<li>点击&#34;下一步&#34;。</li>
		<li>点击&#34;添加源文件&#34;按钮。</li>
		<li>使用对话框在计算机中导航。</li>
		<li>打开包含 5,000 个 JSON 提取文件的目录。</li>
		<li>选择该目录中的所有文件。</li>
		<li>点击&#34;打开&#34;。JSON 文件列表应出现在导入对话框中。</li>
		<li>点击&#34;下一步&#34;；数据库中新集合的预览将出现在左侧。</li>
		<li>点击&#34;下一步&#34;。</li>
		<li>点击&#34;开始导入&#34;。导入进度将显示在左侧下方，指示已导入的文件数量和所用时间。</li>
	</ol>
	</li>
	<li>重复步骤 5 和 6，构建一个包含 10,000 份标准化 EHR 提取数据的集合。</li>
	<li>重复步骤 5 和 6，构建一个包含 20,000 份标准化 EHR 提取数据的集合。</li>
</ol>
3. 构建一个NoSQL eXist数据库管理系统以存储三个双倍规模的标准EHR提取数据库
<ol>
	<li>启动 eXist 数据库。</li>
	<li>使用数据库图标，打开 Java 管理客户端。</li>
	<li>输入管理员密码。</li>
	<li>按下 &#34;Connect&#34; 按钮。</li>
	<li>构建一个包含 5,000 份标准化电子健康记录（EHR）提取文件的集合。
	<ol>
		<li>在工具栏中，选择菜单 &#34;Create a new Collection&#34;。</li>
		<li>在弹出的对话框中，输入新集合的名称。</li>
		<li>点击 &#34;accept&#34;；新集合将显示出来。</li>
		<li>选择该集合的名称。</li>
		<li>在工具栏中，选择菜单 &#34;Store files in the database&#34;。</li>
		<li>使用对话框在计算机中导航。</li>
		<li>选择包含 5,000 份标准化 XML 提取文件的目录。</li>
		<li>点击按钮 &#34;Select the files or directories to store&#34;。注意，将弹出一个对话框，显示存储进度、正在存储的文件以及已创建的数据库百分比。</li>
	</ol>
	</li>
	<li>重复步骤 5，构建一个包含 10,000 份标准化电子健康记录（EHR）提取文件的集合。</li>
	<li>重复步骤 5，构建一个包含 20,000 份标准化电子健康记录（EHR）提取文件的集合。</li>
</ol>
4. 在3个关系型MySQL数据库中设计并执行6个复杂度递增的查询
<ol>
	<li>根据电子健康记录（EHR）提取物所使用的原型，设计六个复杂度递增的查询。</li>
	<li>在 MySQL 数据库上使用第一个查询编写 SQL 脚本。由于提取物的标准化（原型），SQL 必须适配 MySQL 数据库的特殊结构。该数据库映射了提取物的完整结构，因此 SQL 查询相对复杂。</li>
	<li>识别数据库中若在其上建立索引可加快查询响应时间的属性，然后构建此类索引，尽管大多数索引由数据库管理系统（DBMS）自动创建。</li>
	<li>如果某个查询需要非自动创建的索引，则手动建立该索引。
	<ol>
		<li>连接到 MySQL 服务器（补充图 1）。</li>
		<li>在左侧选择并点击数据库名称。</li>
		<li>选择并点击索引字段所在的关联表。</li>
		<li>点击标签页 &#34;结构&#34;。</li>
		<li>选择并点击将要建立索引的列。</li>
		<li>点击 &#34;索引&#34;。注意显示生成索引的 SQL 语句，并出现提示信息表明该语句已成功创建。</li>
	</ol>
	</li>
	<li>执行第一个查询。
	<ol>
		<li>在左侧选择并点击数据库名称。</li>
		<li>点击标签页 &#34;SQL&#34;。</li>
		<li>编写或粘贴第一个查询的 SQL 代码（见 补充图 2）。</li>
		<li>按下 &#34;继续&#34;。注意结果显示列表的第一页出现，同时显示查询执行时间的信息。</li>
		<li>重复执行 5 次，并计算平均响应时间。</li>
	</ol>
	</li>
	<li>对第 2 至第 6 个查询重复步骤 5。</li>
	<li>对包含 5,000、10,000 和 20,000 条提取物的数据库，重复整个过程三次。</li>
</ol>
5. 在3个NoSQL MongoDB数据库中设计并执行6个复杂度递增的查询
<ol>
	<li>启动 MongoDB 图形用户界面（参见材料表）。</li>
	<li>通过 DOS 系统窗口执行 mongod 程序来启动 MongoDB 2.6 服务器（参见补充图 3）。</li>
	<li>按照步骤 2.4 的说明，使用端口 27017 将 MongoDB 图形用户界面连接到本地主机服务器。</li>
	<li>在左侧选择并展开 MongoDB 数据库。</li>
	<li>选择集合。</li>
	<li>单击工具栏中的 &#34;集合&#34; 菜单。</li>
	<li>执行第一个 MongoDB 查询。
	<ol>
		<li>双击 &#34;查询构建器&#34; 按钮。</li>
		<li>在右侧的查询构建器中，双击 &#34;查询字段&#34;。</li>
		<li>在查询面板的字段文本框中输入 MongoDB 查询的字段（参见补充图 4）。</li>
		<li>在查询面板的值文本框中输入 MongoDB 查询的值。 
		注：该查询应类似于 {&#34;ns3:EHRExtract.allCompositions.content.items.parts.parts.name.ns2:originalText.value&#34;: &#34;Descripcion&#34;}。字段和值均需用引号括起，并以分号分隔。</li>
		<li>双击查询构建器中的“投影字段”。</li>
		<li>在投影文本框中输入第一个投影（参见补充图 5）。</li>
		<li>双击投影字段以添加一个新的投影文本框。</li>
		<li>在投影文本框中输入第二个投影。 
		注：投影用于选择由查询检索到的文档的一部分。其格式应类似于 {&#34;ns3:EHRExtract.allCompositions.content.items.parts.parts.value.value&#34;: 1} 和 {&#34;ns3:EHRExtract.allCompositions.content.items.parts.parts.value.nullFlavor&#34;: 1}。</li>
		<li>单击蓝色的播放按钮以执行查询。</li>
		<li>在“查询代码”选项卡中查看查询代码。</li>
		<li>在“解释”选项卡中查看结果详情：结果数量、执行时间（毫秒）。</li>
		<li>在“结果”选项卡中查看、展开并检查结果。</li>
		<li>如果需要对查询结果进行进一步处理，请使用 MongoDB Java 驱动程序编写包含该查询及结果处理方法的 Java 程序。</li>
		<li>重复执行 5 次，并计算平均响应时间。</li>
	</ol>
	</li>
	<li>对剩余的第 2 至第 6 个查询执行步骤 5.7。</li>
	<li>在包含 5,000、10,000 和 20,000 条提取记录的 MongoDB 数据库中重复整个过程。</li>
</ol>
6. 在3个NoSQL eXist数据库中设计并执行复杂度递增的查询
<ol>
	<li>启动 eXist 数据库管理系统。</li>
	<li>打开 Java 管理客户端。</li>
	<li>按下按钮 &#34;connect to the database&#34;。</li>
	<li>选择数据库并点击它。</li>
	<li>点击菜单 &#34;Consult database using XPath&#34;；此时将出现查询对话框。</li>
	<li>执行第一个 XPath 查询（参见 补充图6）。
	<ol>
		<li>在对话框的上部区域输入或粘贴第一个查询的 XPath 代码。</li>
		<li>点击对话框工具栏中的菜单 &#34;Execute&#34;。</li>
		<li>在对话框下部区域使用 &#34;XML&#34; 标签页查看 XML 结果。</li>
		<li>在对话框底部查看结果数量以及编译和执行时间。</li>
		<li>重复执行5次，并计算平均响应时间。</li>
	</ol>
	</li>
	<li>对第2至第6个查询重复步骤6。</li>
	<li>对包含 5,000、10,000 和 20,000 个提取物的 eXist 数据库，将整个过程重复三次。</li>
</ol>
7. 使用 MySQL 和 MongoDB 5,000 条提取物数据库设计并执行并发实验
注意：由于在之前的实验中 eXist 数据库性能较差，目前已从实验中移除。
<ol>
	<li>从之前使用5,000个提取物数据库的实验中，选择响应时间最短的三个查询（通常在几秒内）。</li>
	<li>如有必要，识别并手动为这些查询建立适当的属性索引。</li>
	<li>编写两个Java多线程应用程序，一个用于MySQL，另一个用于MongoDB；每个应用程序将包含三个不同优先级的线程，分别对应步骤1中选定的每个查询。</li>
	<li>执行并计算每个线程（查询）的CPU（中央处理器）使用分布。</li>
	<li>运行每个多线程应用程序，在每10分钟时间段内点击执行按钮五次，并计算执行次数最多（最高优先级）查询的平均吞吐量以及三个查询的平均响应时间。</li>
	<li>查看正在执行的查询，包括其优先级和执行时间。</li>
	<li>计算三个查询中每个查询的平均吞吐量和平均响应时间。</li>
</ol>

<ol><li>Codd, E. F. <a target="_blank" href="https://cs.uwaterloo.ca/~david/cs848s14/codd-relational.pdf">A relational model for large shared data banks.</a> Comm ACM. 13 (6), 377-387 (1970).</li>
<li>Kalra, D., Lloyd, D. <a target="_blank" href="http://scholar.google.com/scholar?hl=en&safe=off&q=author%3aKalra%2C+D+%22ISO+13606+electronic+health+record+communication+part+1%3A+reference+model%22">ISO 13606 electronic health record communication part 1: reference model</a>. , ISO. Geneva. ISO 13606-1 (2008).</li>
<li>Kalra, D., et al. <a target="_blank" href="http://scholar.google.com/scholar?hl=en&safe=off&q=author%3aKalra%2C+D+%22Electronic+health+record+communication+part+2%3A+archetype+interchange+specification%22">Electronic health record communication part 2: archetype interchange specification</a>. , ISO. Geneva. ISO 13606-2 (2008).</li>
<li>Kalra, D., Beale, T., Heard, S. <a target="_blank" href="https://www.ncbi.nlm.nih.gov/pubmed/16160223">The openEHR foundation.</a> Stud. Health Technol. Inform. 115, 153-173 (2005).</li>
<li>Health Level seven. Health Level Seven International. , Available from:
 <a target="_blank" href="http://www.hl7.org">http://www.hl7.org</a> (2017).</li>
<li>Beale, T. <a target="_blank" href="https://www.researchgate.net/publication/237033734_Archetypes_Constraint-based_Domain_Models_for_Future-proof_Information_Systems">Archetypes: constraint-based domain models for future proof information systems.</a> OOPSLA, Workshop Behav Semant. , (2002).</li>
<li>Sánchez-de-Madariaga, R., et al. <a target="_blank" href="http://www.ncbi.nlm.nih.gov/pubmed?term=((Examining+database+persistence+of+ISO%2FEN+13606+standardized+electronic+health+record+extracts%3A+relational+vs.+NoSQL+approaches%5BTitle%5D)+AND+%22BMC+Medical+Informatics+and+Decision+Making%22%5BJournal%5D)">Examining database persistence of ISO/EN 13606 standardized electronic health record extracts: relational vs. NoSQL approaches.</a> BMC Medical Informatics and Decision Making. 32 (2), 493-503 (2017).</li>
<li>Ireland, C., Bowers, D., Newton, M., Waugh, K. <a target="_blank" href="https://www.researchgate.net/publication/42800142_Understanding_object-relational_mapping_A_framework_based_approach">Understanding object-relational mapping: a framework based approach.</a> Int. J. Adv. Softw. 2, 202-216 (2009).</li>
<li>Node+Path Persistence. , Available from:
 <a target="_blank" href="https://openehr.atlassian.net/wiki/spaces/dev/pages/6553626/Node+Path+Persistence">https://openehr.atlassian.net/wiki/spaces/dev/pages/6553626/Node+Path+Persistence</a> (2017).</li>
<li>Wang, L., Min, L., Wang, R., et al. <a target="_blank" href="http://www.ncbi.nlm.nih.gov/pubmed?term=((Archetype+relational+mapping+-+a+practical+openEHR+persistence+solution%5BTitle%5D)+AND+%22BMC+Medical+Informatics+and+Decision+Making%22%5BJournal%5D)">Archetype relational mapping - a practical openEHR persistence solution.</a> BMC Medical Informatics and Decision Making. 15, 88(2015).</li>
<li>Kaur, K., Rani, R. <a target="_blank" href="http://ieeexplore.ieee.org/document/7063177/">Managing data in healthcare information systems: many models, one solution.</a> Computer. March. , 52-59 (2015).</li>
<li>Sabo, C., Pop, P. C., Valean, H., Danciulescu, D. <a target="_blank" href="https://link.springer.com/chapter/10.1007/978-3-319-53480-0_1">An innovative approach to manage heterogeneous information using relational database systems.</a> Advances in Intelligent Systems and Computing. 557, Springer. (2017).</li>
</ol>

作者无任何利益冲突需要披露。本实验所使用的数据集由多家西班牙医院在许可条件下提供，仅用于本实验，因此不公开提供。ISO/EN 13606 RM XML 模式由伦敦大学学院健康信息学与多专业教育中心（CHIME）提供。

本方案表明，对于单个患者的查询（Q1、Q3 和 Q4），纯关系型 ORM 系统似乎并不实用，因其响应时间较慢，这可能是由于大量关系表执行了大量高成本的连接操作，以及特定数据库所采用的存储系统所致。NoSQL 数据库以基于文档的方式存储数据，而关系型系统则采用基于表格的方式，将每个文档分散存储在整个数据库中。NoSQL 系统呈现出线性增长趋势，其中 MongoDB 的性能明显优于 eXist DBMS。在并发处理方面，MongoDB 的表现也远优于关系型 MySQL ORM7。
本方案针对文献7中关于 ORM MySQL 数据库管理系统（DBMS）结果的故障排除提供了解决方案。MySQL 系统已更新至最新版本，相关结果也进行了小幅调整。此外，在基于文档的 NoSQL 系统（如 MongoDB）中存在一个关键点：在存储医疗信息时，此类系统可能保持数据一致性7，因为当电子健康记录（EHR）提取件被更新时，并非覆盖原有数据，而是生成并存储一个包含新数据的全新提取件，同时保留原始提取件。这是医疗信息的一项严格要求，因为某些医疗专业人员可能已基于原始数据做出了重要的医疗决策。
改进后的关系型ARM系统大幅减少了关系表的数量，并提升了关系型查询性能。然而，由于该系统修改了关系型模式，因此可以对提取物所包含的医学信息进行查询，但无法将提取物恢复为其原始的精确形式。
对于用于二次利用（研究）的大型数据库，目前尚不明确哪种数据库系统更为合适，因为全患者查询（Q2和Q5）在ORM系统中的表现优于NoSQL系统，但NoSQL系统在12中的表现又优于简化的关系型系统。我们认为Q6是一个介于临床实践与二次利用之间的特殊查询，其性能无法通过这些实验的结果来确定。
然而，该方法的一个局限性在于，目前尚无直接实验将改进的关系型 ARM 系统与 NoSQL MongoDB 在单患者、医疗实践查询方面进行对比，且使用与本方案中完全相同的数据。在包含优化 ARM 的实验完成之前，我们通过插值 表3 和 表5 中关于单患者查询的结果来维持分析。这些实验将留待未来应用中完成。本方案中的一个关键步骤是选择近年来版本相近的免费数据库和类似软件，以便我们能够准确比较这三种技术的最新状态。
这是首次尝试使用真实、合理且标准化的医学信息直接比较关系型数据库与NoSQL系统的研究之一。然而，具体应采用哪种系统在很大程度上取决于实际的应用场景和待解决的问题8。

NoSQL（不仅仅是 SQL）数据库管理系统最近已成为传统关系型数据库管理系统（RDBMS）的一种替代方案。几十年来，关系型数据库管理系统一直主导着数据在数据库系统中的存储方式。经过深入研究和充分理解的关系代数与关系演算，保证了关系型数据库管理系统的高效性与一致性1。NoSQL 系统并不会取代关系型系统，但在某些特定场景和多种条件下可能表现出优势。
在设计用于管理和存储医疗信息的电子健康记录（EHR）系统的数据库持久化时，可能会遇到上述某些特定场景和条件。为了在实践中实现互操作性和可持续性，已采用若干国际标准（如 ISO/EN 13606、openEHR 和 HL72,3,4,5）来规范 EHR 数据的提取。
诸如 ISO/EN 13606 和 openEHR 等多个标准已将信息与知识分离为两个不同层次的抽象，分别由参考模型（Reference Model, RM）和一种称为原型（archetypes）的特殊数据结构来表示。这种分离通常被称为双模型（dual model），它使得电子健康记录（EHR）系统能够实现语义上的互操作性，并允许医学知识在无需重新编程整个 EHR 系统的前提下持续演进，从而在实践中具备可维护性和可持续性6。然而，在标准化的 EHR 系统中实现的双模型要求信息的组织遵循特定的结构，这对系统数据库持久化层级的设计方式产生了深远影响7。
对象关系映射（Object Relational Mapping, ORM）8 是一种基于关系型数据库范式来实现电子健康记录（EHR）系统的方案。ORM 对系统所使用的标准化 EHR 导出 XML（eXtensible Markup Language）文件的结构进行详尽映射，并据此构建大量关系型数据表。这些关系型数据表通过多个外键相互关联，导致最终的系统可能效率较低。
人们已提出多种对对象关系映射（ORM）的改进方法。openEHR 的 Node+Path9 通过将整个提取的 XML 文件的子树序列化为 BLOB（二进制大对象）来减少关系表的数量。然而，这种简化导致了复杂的检索逻辑，损害了复杂查询的性能。模板关系映射（Archetype Relational Mapping, ARM）10 则采用由模板驱动的数据库建模方法，基于模板与关系表之间的映射关系构建新的关系模式。因此，电子健康记录（EHR）提取物中的部分非医疗信息会丢失。
许多基于文档的 NoSQL 数据库存储整个文档，将其作为完整的 BLOB 保存，并保持原始的 XML 或 JSON（JavaScript 对象表示法）格式。这意味着不会构建关系表。这些 NoSQL 数据库没有模式，也不支持连接操作或（ACID）特性11，即原子性、一致性、隔离性或持久性。因此，如果一个文档中的元素通过间接链接引用同一文档或其他文档中的元素，则此类数据库可能效率极低。这是因为为了保持一致性，必须顺序处理所有被引用的文档。然而，如果数据库管理系统执行的主要任务是基于文档的操作，则非关系型数据库仍可能是合适的。这是因为使用基于文档的 NoSQL 数据库时，数据可以保持更接近其真实表示的形式，尽管这一点也与电子健康记录（EHR）医疗文档所实现的特殊持久化策略有关（参见讨论部分）。
这些方法的目的是展示若干实验，以比较采用三种不同数据库管理系统（DBMS）实现标准化电子健康记录（EHR）系统持久层的性能：一种关系型数据库（MySQL）和两种非关系型数据库（基于文档的 MongoDB 和原生 XML 的 eXist）。通过三个规模递增的数据库以及六个复杂度逐步提高的查询，计算并比较了它们的计算复杂度。这三个数据库服务器均在同一台计算机上本地安装和配置，并在该计算机上执行所有查询。技术细节请见材料表。
为了比较关系型MySQL与非关系型MongoDB数据库管理系统的性能，也开展了并发实验。此外，还利用文献中相关的适当结果对所描述的ORM改进方法（Node+Path和ARM）进行了比较10。
数据库管理系统正在以不断加快的速度持续演进。当关系模型是唯一存在的范式时，人们并未预料到这种指数级的发展。例如，参见文献12，其中提出了一种模型，用于实现响应时间更优且保持ACID特性的关系型数据库。

<table><tbody><tr><td>MySQL 5.7.20</td><td></td><td></td><td>MySQL 实验</td></tr><tr><td>Red Hat Enterprise Linux Server release 7.4 (Maipo)，2.60GHz，内存 16GB</td><td></td><td></td><td></td></tr><tr><td>MongoDB 2.6</td><td></td><td></td><td>MongoDB 实验</td></tr><tr><td>Windows 7，2.66GHz，内存 12GB&amp;nbsp;</td><td></td><td></td><td></td></tr><tr><td>eXist 3.0RC1</td><td></td><td></td><td>eXist 实验</td></tr><tr><td>Windows 7，2.66GHz，内存 12GB&amp;nbsp;</td><td></td><td></td><td></td></tr><tr><td>Studio 3T 5.5.1</td><td>3T Software Labs Gmbh</td><td></td><td>MongoDB 图形用户界面</td></tr></tbody></table>

在关系型（mysql）和非关系型（mongodb 与 exist）规模递增的 iso/en 13606 标准化电子健康记录数据库中执行复杂度递增的查询

Executing Complexity-Increasing Queries in Relational (MySQL) and NoSQL (MongoDB and EXist) Size-Growing ISO/EN 13606 Standardized EHR Databases

本研究展示了一种用于评估查询关系型与非关系型（NoSQL，即不仅限于结构化查询语言）标准化电子健康记录（EHR）医疗信息数据库管理系统（DBMS）计算复杂度的实验方案。该方案采用一组包含三个规模依次倍增的数据库， 即 存储 5000、10000 和 20000 份真实标准化电子健康记录（EHR）提取数据的数据库，涵盖三种不同的数据库管理系统（DBMS）：关系型 MySQL 与对象关系映射&#160;（ORM）、基于文档的 NoSQL 数据库 MongoDB，以及原生可扩展标记语言（XML）NoSQL 数据库 eXist。
计算了对六个复杂度递增查询的平均响应时间，结果显示在 NoSQL 情况下呈线性行为。在 NoSQL 领域中，MongoDB 的线性斜率远比 eXist 更平缓。
由于医疗信息更新策略的特殊性，NoSQL 系统可能更适用于维护标准化的医疗信息系统，此类更新策略不应影响存储在 NoSQL 数据库中的数据的一致性和效率。
本方案的一个局限性在于，缺乏使用相同数据获得的改进型关系系统（如原型关系映射，ARM）的直接结果。然而，将数据库规模加倍后的插值结果与文献中报道的及其他已发表的结果进行比较表明，在许多特定场景和待解决问题中，NoSQL 系统可能更为合适。例如，在基于文档的任务中（如临床实践中使用的电子健康记录（EHR）提取、编辑与可视化），或当目标不仅是查询医学信息，还需将 EHR 完全恢复为其原始形式的情况下，NoSQL 可能更为适用。

在包含患者问题信息（包括患者姓名、起始日期、结束日期和严重程度）的真实标准化电子健康记录提取物上执行的六种不同查询如图所示 表1.
三种数据库规模翻倍情况下，各数据库管理系统中六个查询的平均响应时间如表2-4所示。图1-6以图形方式展示了相同的结果（请注意，这些图中的纵坐标轴使用了截然不同的量程）。
在所有NoSQL数据库查询中，计算复杂度均表现出明显的线性行为，尽管由于所使用的3个数据集规模相对较小，需谨慎对待该结论。然而，关系型ORM数据库则表现出不明确的线性行为。MongoDB数据库的斜率远比eXist数据库平缓。
在引言中讨论的改进关系系统在文献中发表的结果可参见表5。将表3中的MongoDB结果与表5中ARM结果在相似查询和数据库规模下进行插值比较，两者在Q1中表现相当，但在Q3中MongoDB更具优势。
并发实验的结果见表5和表6。在吞吐量和响应时间方面，MongoDB 均优于 MySQL。事实上，MongoDB 在并发情况下的表现优于独立运行时的表现，显示出其在并发执行中具有出色的数据库性能。
<img alt="ORM、MongoDB、eXist 响应时间图；查询 1、4；5000-20000 条记录时的性能比较。" class="xfigimg" src="/files/ftp_upload/57439/57439fig1.jpg" data-altupdatedat="1788250015000" data-alt="图 1"> 
图 1：ORM MySQL、MongoDB 和 eXist 数据库管理系统在查询 Q1 和 Q4 中的算法复杂度。本图基于7修改，采用知识共享许可协议（http://creativecommons.org/ licenses/by/4.0/），展示了每种数据库管理系统在 5,000、10,000 和 20,000 条电子健康记录提取数据集规模下，执行查询 Q1 和 Q4 的响应时间（单位：秒）。 <a href="https://cloudflare.jove.com/files/ftp_upload/57439/57439fig1large.jpg" target="_blank">请点击此处查看此图的高清版本。</a>
<img alt="ORM 响应时间与提取物的关系图；性能分析；包含查询 2 数据的折线图。" class="xfigimg" src="/files/ftp_upload/57439/57439fig2.jpg" data-altupdatedat="1788250015000" data-alt="图 2"> 
图 2： ORM MySQL 数据库管理系统在查询 Q2 中的算法复杂度。本图展示了 ORM MySQL 数据库在查询 Q2 时，针对包含 5,000、10,000 和 20,000 条记录的电子健康记录（EHR）提取物的响应时间（单位：秒）。<a href="https://cloudflare.jove.com/files/ftp_upload/57439/57439fig2large.jpg" target="_blank">请点击此处查看此图的放大版本。</a>
<img alt="MongoDB 与 eXist 响应时间对比；查询 Q2、Q5；折线图，提取数量。" class="xfigimg" src="/files/ftp_upload/57439/57439fig3.jpg" data-altupdatedat="1788250015000" data-alt="Figure 3"> 
图 3： MongoDB 与 eXist 数据库管理系统在查询 Q2 和 Q5 上的算法复杂度。本图改编自文献7，采用知识共享许可协议（http://creativecommons.org/licenses/by/4.0），展示了两种数据库管理系统在 5,000、10,000 和 20,000 条电子健康记录提取数据库规模下，执行查询 Q2 和 Q5 的响应时间（单位：秒）。<a href="https://cloudflare.jove.com/files/ftp_upload/57439/57439fig3large.jpg" target="_blank">请点击此处查看此图的高清版本。</a>
<img alt="显示 ORM 的响应时间与提取数量关系的折线图；Q3、Q5 性能分析。" class="xfigimg" src="/files/ftp_upload/57439/57439fig4.jpg" data-altupdatedat="1788250015000" data-alt="Figure 4"> 
图 4：ORM MySQL 数据库管理系统在查询 Q3 和 Q5 上的算法复杂度。显示了每种数据库管理系统在包含 5,000、10,000 和 20,000 条记录的电子健康记录提取数据库上执行查询 Q3 和 Q5 的响应时间（单位：秒）。<a href="https://cloudflare.jove.com/files/ftp_upload/57439/57439fig4large.jpg" target="_blank">请点击此处查看该图的高清版本。</a>
<img alt="MongoDB 与 eXistDB 响应时间对比图表；随着数据量增加的查询性能。" class="xfigimg" src="/files/ftp_upload/57439/57439fig5.jpg" data-altupdatedat="1788250015000" data-alt="Figure 5"> 
图5：eXist 与 MongoDB 数据库管理系统在查询 Q3 上的算法复杂度。本图改编自文献7，采用知识共享许可协议（http://creativecommons.org/licenses/by/4.0/），展示了两种数据库管理系统在处理包含 5,000、10,000 和 20,000 条记录的电子健康记录提取数据库时，执行查询 Q3 的响应时间（单位：秒）。<a href="https://cloudflare.jove.com/files/ftp_upload/57439/57439fig5large.jpg" target="_blank">请点击此处查看此图的高清版本。</a>
<img alt="ORM、eXist、MongoDB 数据提取响应时间性能比较图" class="xfigimg" src="/files/ftp_upload/57439/57439fig6.jpg" data-altupdatedat="1788250015000" data-alt="图 6"> 
图 6： ORM MySQL、eXist 和 MongoDB 数据库管理系统在查询 Q6 上的算法复杂度。该图改编自文献7，采用知识共享许可协议（http://creativecommons.org/licenses/by/4.0/），展示了每种数据库管理系统在包含 5,000、10,000 和 20,000 条记录的电子健康记录提取数据库上执行查询 Q6 时的响应时间（单位：秒）。<a href="https://cloudflare.jove.com/files/ftp_upload/57439/57439fig6large.jpg" target="_blank">请点击此处查看此图的高清版本</a>。
<table border="1" fo:keep-together.within-page="1" fo:keep-with-next.within-page="always">
	<tbody>
		<tr>
			<td></td>
			<td>查询</td>
		</tr>
		<tr>
			<td>Q1</td>
			<td>查找单个患者的所有问题</td>
		</tr>
		<tr>
			<td>Q2</td>
			<td>查找所有患者的所有问题</td>
		</tr>
		<tr>
			<td>Q3</td>
			<td>查找单个患者某一特定问题的</td>
		</tr>
		<tr>
			<td></td>
			<td>初始日期、解决日期和严重程度</td>
		</tr>
		<tr>
			<td>Q4</td>
			<td>查找单个患者所有问题的</td>
		</tr>
		<tr>
			<td></td>
			<td>初始日期、解决日期和严重程度</td>
		</tr>
		<tr>
			<td>Q5</td>
			<td>查找所有患者所有问题的</td>
		</tr>
		<tr>
			<td></td>
			<td>初始日期、解决日期和严重程度</td>
		</tr>
		<tr>
			<td>Q6</td>
			<td>查找患有“咽炎”问题、</td>
		</tr>
		<tr>
			<td></td>
			<td>初始日期 >= '16/10/2007'、解决日期</td>
		</tr>
		<tr>
			<td></td>
			<td> <= '06/05/2008' 且严重程度为“高”的所有患者</td>
		</tr>
	</tbody>
</table>
表1：在包含标准化患者电子健康记录（EHR）提取数据的关系型和NoSQL数据库上执行的六个查询。 本表格改编自7，采用知识共享许可协议（http://creativecommons.org/ licenses/by/4.0/），以自然语言展示了在每种数据库管理系统（DBMS）的三个规模递增的数据库上执行的六个复杂度递增的查询。
<table border="1" fo:keep-together.within-page="1" fo:keep-with-next.within-page="always">
	<tbody>
		<tr>
			<td>ORM/MySQL</td>
			<td>5000 份文档</td>
			<td>10,000 份文档</td>
			<td>20,000 份文档</td>
		</tr>
		<tr>
			<td>Q1 (s)</td>
			<td>25.0474</td>
			<td>32.6868</td>
			<td>170.7342</td>
		</tr>
		<tr>
			<td>Q2 (s)</td>
			<td>0.0158</td>
			<td>0.0147</td>
			<td>0.0222</td>
		</tr>
		<tr>
			<td>Q3 (s)</td>
			<td>3.3849</td>
			<td>6.4225</td>
			<td>207.2348</td>
		</tr>
		<tr>
			<td>Q4 (s)</td>
			<td>33.5457</td>
			<td>114.6607</td>
			<td>115.4169</td>
		</tr>
		<tr>
			<td>Q5 (s)</td>
			<td>9.6393</td>
			<td>74.3767</td>
			<td>29.0993</td>
		</tr>
		<tr>
			<td>Q6 (s)</td>
			<td>1.4382</td>
			<td>2.4844</td>
			<td>183.4979</td>
		</tr>
		<tr>
			<td>数据库大小</td>
			<td>4.6GB</td>
			<td>9.4GB</td>
			<td>19.4GB</td>
		</tr>
		<tr>
			<td>总提取数</td>
			<td>5000</td>
			<td>10,000</td>
			<td>20,000</td>
		</tr>
	</tbody>
</table>
表2：ORM MySQL关系型数据库管理系统在数据库规模成倍增加时，六个查询的平均响应时间（秒） 此表格 展示了使用 ORM MySQL 关系型数据库管理系统和三个数据库的内存大小时，针对每个查询在三个规模依次加倍的数据库上的六次响应时间。
<table border="1" fo:keep-together.within-page="1" fo:keep-with-next.within-page="always">
	<tbody>
		<tr>
			<td>MongoDB</td>
			<td>5000 条文档</td>
			<td>10,000 条文档</td>
			<td>20,000 条文档</td>
			<td>斜率 (*10exp(-6))</td>
		</tr>
		<tr>
			<td>Q1 (s)</td>
			<td>0.046</td>
			<td>0.057</td>
			<td>0.1221</td>
			<td>5.07</td>
		</tr>
		<tr>
			<td>Q2 (s)</td>
			<td>34.5181</td>
			<td>68.6945</td>
			<td>136.2329</td>
			<td>6,780.99</td>
		</tr>
		<tr>
			<td>Q3 (s)</td>
			<td>0.048</td>
			<td>0.058</td>
			<td>0.1201</td>
			<td>4.81</td>
		</tr>
		<tr>
			<td>Q4 (s)</td>
			<td>0.052</td>
			<td>0.061</td>
			<td>o.1241</td>
			<td>4.81</td>
		</tr>
		<tr>
			<td>Q5 (s)</td>
			<td>38.0202</td>
			<td>75.4376</td>
			<td>149.933</td>
			<td>7460.85</td>
		</tr>
		<tr>
			<td>Q6 (s)</td>
			<td>9.5153</td>
			<td>18.5566</td>
			<td>36.7805</td>
			<td>1,817.68</td>
		</tr>
		<tr>
			<td>数据库大小</td>
			<td>1.95GB</td>
			<td>3.95GB</td>
			<td>7.95GB</td>
			<td></td>
		</tr>
		<tr>
			<td>总提取数</td>
			<td>5000</td>
			<td>10,000</td>
			<td>20,000</td>
			<td></td>
		</tr>
	</tbody>
</table>
表3：在MongoDB NoSQL数据库管理系统中，六个查询在数据量翻倍的数据库上的平均响应时间（秒）。 本表格经修改自7，采用知识共享许可协议（http://creativecommons.org/ licenses/by/4.0/），展示了使用NoSQL MongoDB数据库管理系统时，三个数据量依次翻倍的数据库中每个查询的六项响应时间，以及这三个数据库的内存占用大小。每个查询的线性斜率也一并列出。
<table border="1" fo:keep-together.within-page="1" fo:keep-with-next.within-page="always">
	<tbody>
		<tr>
			<td>eXist</td>
			<td>5000 份文档</td>
			<td>10,000 份文档</td>
			<td>20,000 份文档</td>
			<td>斜率 (*10exp(-6))</td>
		</tr>
		<tr>
			<td>Q1 (s)</td>
			<td>0.6608</td>
			<td>3.7834</td>
			<td>7.3022</td>
			<td>442.76</td>
		</tr>
		<tr>
			<td>Q2 (s)</td>
			<td>60.7761</td>
			<td>129.3645</td>
			<td>287.362</td>
			<td>15,105.73</td>
		</tr>
		<tr>
			<td>Q3 (s)</td>
			<td>0.6976</td>
			<td>1.771</td>
			<td>4.1172</td>
			<td>227.96</td>
		</tr>
		<tr>
			<td>Q4 (s)</td>
			<td>0.6445</td>
			<td>3.7604</td>
			<td>7.3216</td>
			<td>445.17</td>
		</tr>
		<tr>
			<td>Q5 (s)</td>
			<td>145.3373</td>
			<td>291.2502</td>
			<td>597.7216</td>
			<td>30,158.93</td>
		</tr>
		<tr>
			<td>Q6 (s)</td>
			<td>68.3798</td>
			<td>138.9987</td>
			<td>475.2663</td>
			<td>27,125.82</td>
		</tr>
		<tr>
			<td>数据库大小</td>
			<td>1.25GB</td>
			<td>2.54GB</td>
			<td>5.12GB</td>
			<td></td>
		</tr>
		<tr>
			<td>提取总数</td>
			<td>5000</td>
			<td>10,000</td>
			<td>20,000</td>
			<td></td>
		</tr>
	</tbody>
</table>
表4：在eXist NoSQL数据库管理系统上，六个查询在数据库规模逐次加倍时的平均响应时间（秒）。 本表格经7修改，采用知识共享许可协议（http://creativecommons.org/ licenses/by/4.0/），展示了使用NoSQL eXist数据库管理系统时，三个规模逐次加倍的数据库中每个查询的六项响应时间，以及这三个数据库的内存占用大小。同时列出了每个查询的线性斜率。
<table border="1" fo:keep-together.within-page="1" fo:keep-with-next.within-page="always">
	<tbody>
		<tr>
			<td></td>
			<td>ARM 论文</td>
			<td>ARM (秒)</td>
			<td>节点+路径 (秒)</td>
		</tr>
		<tr>
			<td>Q1</td>
			<td>查询 2.1</td>
			<td>0.191</td>
			<td>24.866</td>
		</tr>
		<tr>
			<td>Q3</td>
			<td>查询 3.1</td>
			<td>0.27</td>
			<td>294.774</td>
		</tr>
		<tr>
			<td></td>
			<td>数据库大小</td>
			<td>2.90GB</td>
			<td>43.87GB</td>
		</tr>
		<tr>
			<td></td>
			<td>总提取数</td>
			<td>29,743</td>
			<td>29,743</td>
		</tr>
	</tbody>
</table>
表5：改进的关系型系统中与文献10中Q1和Q3查询类似的查询的平均响应时间（单位：秒）。 本表格改编自文献7，采用知识共享许可协议（http://creativecommons.org/ licenses/by/4.0/），展示了与文献10中Q1和Q3最相似的两个查询，分别对应两种改进的关系型数据库系统及其响应时间。同时列出了两个数据库的规模。
<table border="1" fo:keep-together.within-page="1" fo:keep-with-next.within-page="always">
	<tbody>
		<tr>
			<td>ORM/MySQL</td>
			<td>吞吐量</td>
			<td>响应时间</td>
		</tr>
		<tr>
			<td>Q1 (s)</td>
			<td>4,711.60</td>
			<td>0.0793</td>
		</tr>
		<tr>
			<td>Q3 (s)</td>
			<td>4,711.60</td>
			<td>0.1558</td>
		</tr>
		<tr>
			<td>Q4 (s)</td>
			<td>4,711.60</td>
			<td>0.9674</td>
		</tr>
	</tbody>
</table>
表6：ORM MySQL关系型数据库管理系统在并发执行中查询Q1、Q3和Q4的平均吞吐量及响应时间（单位：秒）。 本表格改编自文献7，采用知识共享许可协议（http://creativecommons.org/ licenses/by/4.0/），展示了在使用ORM MySQL关系型系统进行并发执行实验时，三个单患者查询的最高平均吞吐量及其平均响应时间。
<table border="1" fo:keep-together.within-page="1" fo:keep-with-next.within-page="always">
	<tbody>
		<tr>
			<td>MongoDB</td>
			<td>吞吐量</td>
			<td>响应时间</td>
		</tr>
		<tr>
			<td>Q1 (s)</td>
			<td>178,672.60</td>
			<td>0.003</td>
		</tr>
		<tr>
			<td>Q3 (s)</td>
			<td>178,672.60</td>
			<td>0.0026</td>
		</tr>
		<tr>
			<td>Q4 (s)</td>
			<td>178,672.60</td>
			<td>0.0034</td>
		</tr>
	</tbody>
</table>
表7：MongoDB NoSQL数据库管理系统在并发执行中查询Q1、Q3和Q4的平均吞吐量及响应时间（单位：秒）。 本表格经7修改，采用知识共享许可协议（http://creativecommons.org/ licenses/by/4.0/），展示了在使用MongoDB NoSQL系统进行并发执行实验时，三个单患者查询的最高平均吞吐量及其平均响应时间。
补充图1：截图显示了用于连接到 MySQL 服务器的软件界面。<a href="https://cloudflare.jove.com/files/ftp_upload/57439/Supplementary_Figure_1.png" target="_blank">请点击此处下载该图。</a>
补充图2：截图显示了连接到MySQL服务器的SQL界面，其中已编写第一条SQL查询语句。<a href="https://cloudflare.jove.com/files/ftp_upload/57439/Supplementary_Figure_2.png" target="_blank">请点击此处下载该图。</a>
补充图3：通过DOS系统窗口执行服务器mongod来启动MongoDB 2.6本地主机服务器。 <a href="https://cloudflare.jove.com/files/ftp_upload/57439/Supplementary_Figure_3.png" target="_blank">请点击此处下载该图。</a>
补充图4：截图显示了在查询构建器的文本框中输入的查询语句，如步骤5.7.1至5.7.4所示。本截图展示了步骤5.7.3。<a href="https://cloudflare.jove.com/files/ftp_upload/57439/Supplementary_Figure_4.png" target="_blank">请点击此处下载该图。</a>
补充图5：截图显示步骤5.7.6。 <a href="https://cloudflare.jove.com/files/ftp_upload/57439/Supplementary_Figure_5.png" target="_blank">请点击此处下载该图。</a>
补充图6：该截图展示了在对话框上半部分编写XPath查询的过程。<a href="https://cloudflare.jove.com/files/ftp_upload/57439/Supplementary_Figure_6.png" target="_blank">请点击此处下载该图。</a>

本研究比较了关系型与非关系型（NoSQL）标准化医疗信息系统。通过使用规模倍增的数据库，计算了查询此类数据库管理系统（DBMS）响应时间的计算复杂度。这些结果有助于讨论每种数据库方法在不同场景和问题中的适用性。

在关系型（MySQL）和非关系型（MongoDB 与 EXist）规模递增的 ISO/EN 13606 标准化电子健康记录数据库中执行复杂度递增的查询

本研究展示了一种用于评估查询关系型与非关系型（NoSQL，即不仅限于结构化查询语言）数据库计算复杂度的实验方案。

本实验的总体目标是通过响应时间衡量关系型与非关系型（即非仅结构化查询语言，或 NoSQL）数据库系统在处理复杂度递增的查询时的计算复杂性差异。该方法有助于回答数据库管理系统领域中的一些关键问题，例如何种类型的查询更适合何种类型的数据库系统。该技术的主要优势在于，它不仅比较了每种类型两种数据库对查询的响应时间，还同时评估了相应的计算复杂性，因此该方法可为 MySQL、MongoDB 和其他数据库系统提供深入见解。该方法也可应用于其他基于关系文档和原生 XML 的系统，例如 SQL Server 和 BaseX。我们最初在为电子健康记录系统选择持久化系统时了解到此方法。在关系型 MySQL 数据库中设计并执行复杂度递增的查询，且这些查询使用非自动生成的索引。连接到 MySQL 服务器并选择数据库名称。在索引字段中选择关系表并打开结构选项卡。选择将要创建索引的列，然后单击“索引”。用于创建索引的 SQL 语句将显示出来，随后会提示该语句已成功生成。执行第一个查询时，选择数据库名称并打开 SQL 选项卡。输入第一个查询的 SQL 代码，然后单击继续。查询执行时间的消息将随结果列表的第一页一同显示。设计并执行复杂度递增的查询以及非关系型（NoSQL）Mongo数据库时，从DOS系统窗口运行Mongo程序，启动Mongo数据库图形用户界面和Mongo数据库2.6服务器。通过端口27017将Mongo数据库图形用户界面连接至本地主机服务器，并选择连接菜单。在数据库服务器文本框中输入连接名称及本地主机地址，然后单击“连接”。应出现包含当前数据库的树状结构。展开 Mongo 数据库。选择感兴趣的集合，并打开集合菜单。要执行第一个 Mongo 数据库查询，请双击查询构建器和查询字段按钮。将 Mongo 数据库查询的字段输入到查询面板的字段文本框中，并将查询的值输入到查询面板的值文本框中。双击查询构建器的投影字段，并将第一个投影输入到投影文本框中。双击投影区域以添加新的投影文本框，输入第二个投影，然后单击“播放”以执行查询，并在“查询代码”选项卡中查看查询代码。查询结果的详细信息可在“解释”和“结果”选项卡下查看。要在 NoSQL EXist 数据库中设计并执行日益复杂的查询，请启动 EXist 数据库并打开 Java 管理客户端。单击，连接到数据库并选择数据库。单击，使用X路径查询数据库。查询对话框将出现。然后执行第一个 XPath 查询。在此表格中，展示了在包含患者问题信息（包括患者姓名、起始日期、结束日期和严重程度）的真实标准化电子健康记录提取数据上执行的六种不同查询。这六个查询在每种数据库管理系统中，针对三种数据量翻倍的数据库的平均响应时间表明，非关系型数据库在所有查询中均呈现出较长的线性计算复杂度行为，而这一现象在关系型对象关系映射数据库分析中并未观察到。使用类似的查询和原型关系映射结果的数据库规模对 Mongo 数据库结果进行插值，在首次查询中，两种数据库系统产生相等的结果，但在第三次查询中，使用 Mongo 数据库得出的结果更为优越。在并发性实验中，Mongo 数据库在吞吐量和响应时间方面均优于 MySQL 数据库，且在并发处理中表现优于隔离状态，成为并发执行中表现突出的数据库。需要牢记的是，应将所有服务器与客户端置于同一台机器上以执行查询。在完成此操作后，还可以采用其他方法，例如使用其他类型的数据库系统，以回答更多问题，比如某种类型的数据库是否能够在单个患者查询和全体患者查询中同时存在并胜出？该技术在开发完成后，为算法复杂性领域的研究人员探索不同类型数据库系统中的数据库性能比较铺平了道路。观看本视频后，您应能够充分理解如何在规模不断增长、类型差异显著的数据库系统的数据库中执行复杂度逐步增加的查询。

executing-complexity-increasing-queries-relational-mysql-nosql

Research

科研

JoVE Journal

Medicine

医学

在关系 (MySQL) 和 NoSQL (MongoDB 和存在) 中执行复杂度增加的查询大小-增长的 ISO/EN 13606 标准化的电子病历数据库

自然界与实验室中的微生物群落——访谈

已建立一个胸部肿瘤学数据库，用作临床和实验室数据的综合存储库，以支持转化医学研究。该数据库将服务于胸部肿瘤学研究项目中的转化癌症研究人员。此数据库可适用于其他癌症模型以及其他人类疾病。...

生成综合性胸部肿瘤学数据库——转化研究工具

我们提供了一种实验方案及相关的编程代码和元数据样本，以支持基于云平台的自动化识别，在生物医学文献中识别用户选定知识领域内代表独特概念的短语与类别之间的关联。通过本方案量化的短语-类别关联可促进对选定知识领域的深入分析。...

基于云的生物医学出版物中用户定义短语-类别关联的短语挖掘与分析

许多研究人员生成的是“中等规模”、低通量且多维的数据，这类数据使用数据库管理比使用电子表格更为高效。本文对数据库的基本概念进行概述，包括多维数据的可视化、关系型数据库结构中表的关联、半自动化数据流程的映射，以及如何利用数据库揭示数据的内在含义。...

用于高效管理组织工程中中等规模、低通量多维数据的数据库

TBase 将电子健康记录与一种创新的肾移植受者研究数据库相结合。TBase...

TBase——一个用于肾移植受者的整合型电子健康记录与科研数据库

gP2S：一种用于冷冻电镜实验的信息管理系统

术后肠梗阻（POI）是腹部手术后的一种并发症，可导致发病率升高和住院时间延长。由于目前缺乏有效的预防或治疗策略，亟需加强相关研究。因此，我们建立了一种标准化且可行的小鼠模型，用于研究POI的病理生理机制，并探索潜在的治疗方案。...

肠道运动功能及肠壁炎症在啮齿类动物中的功能评估：标准化肠道操作模型中的分析

病灶探查者：一种基于视频指导的标准化方案，用于阿尔茨海默病及正常老年人群中准确可靠的磁共振成像衍生体积测量

我们描述了一种可在室内使用、便携且标准化的路线，可用于评估超低视力个体的避障能力。该路线成本相对较低，操作简便，且已证明具有良好的可靠性和可重复性。...

用于评估超低视力与人工视力视觉功能的标准化障碍路线

本方法旨在通过颈动脉持续输送药物溶液，以评估新药在小鼠模型中的药代动力学。...

小鼠中紫杉烷类药物药代动力学与药效学分析的颈动脉灌注

了解关系型数据库MySQL与非关系型数据库MongoDB的计算复杂度差异，通过执行复杂度递增的查询并分析响应时间，为电子病历系统选择合适的数据库方案提供参考依据。

在关系型（MySQL）和非关系型（MongoDB 与 EXist）规模递增的 ISO/EN 13606 标准化电子健康记录数据库中执行复杂度递增的查询

探索更多视频