分层数据模型的替代方案

Posted 2023-02-14

【中文标题】分层数据模型的替代方案

【英文标题】：An alternative to hierarchical data model

【发布时间】：2012-08-15 18:18:45

【问题描述】：

问题域

我正在开发一个相当大的应用程序，它使用分层数据模型。它拍摄图像、提取图像的特征并在这些特征之上创建分析对象。所以基本模型就像Object-(1:N)-Image_features-(1:1)-Image。但是同一组图像可以用于创建多个分析对象（具有不同的选项）。

然后一个对象和图像可以有很多其他连接的对象，例如可以使用附加数据细化分析对象，或者可以基于分析对象和其他数据得出复杂的结论（解决方案）。

当前解决方案

这是解决方案的草图。堆栈代表对象集，箭头代表指针（即图像特征链接到它们的图像，反之亦然）。某些部分：图像、图像特征、附加数据，可能包含在多个分析对象中（因为用户想对不同的对象集进行分析，组合方式不同）。

图像、特征、附加数据和分析对象存储在全局存储（god-object）中。解决方案通过组合存储在分析对象中（并依次包含解决方案特征）。

所有实体（图像、图像特征、分析对象、解决方案、附加数据）都是相应类的实例（如 IImage，...）。几乎所有部分都是可选的（即，我们可能希望在找到解决方案后丢弃图像）。

当前解决方案的缺陷

当您需要像草图中的虚线那样的连接时，导航这个结构是很痛苦的。如果您必须在顶部显示具有几个解决方案特征的图像，您首先必须遍历分析对象以找出其中哪些基于该图像，然后遍历解决方案以显示它们。 如果要解决 1. 您选择显式存储虚线链接（即图像类将具有指向与其相关的解决方案特征的指针），您将花费大量精力来维护这些指针的一致性并不断更新链接当事情发生变化时。

我的想法

我想构建一个更可扩展 (2) 和更灵活 (1) 的数据模型。第一个想法是使用关系模型，分离对象及其关系。为什么不在这里使用 RDBMS - sqlite 对我来说似乎是一个合适的引擎。所以复杂的关系可以通过数据库上的简单（左）JOIN 访问：伪代码“images JOIN images_to_image_features JOIN image_features JOIN image_features_to_objects JOIN objects JOIN solutions JOIN solution_features”），然后按 ID 从全局存储中获取实际 C++ 对象以获得解决方案功能。

问题

所以我的主要问题是

对于我所描述的问题，使用 RDBMS 是一种合适的解决方案，还是不值得，并且有更好的方法来组织我的应用程序中的信息？

如果 RDBMS 没问题，我将不胜感激有关使用 RDBMS 和关系方法存储 C++ 对象关系的任何建议。

【问题讨论】：

嗨骏马。你问的是一个非常困难的问题。你也问了很多问题，不是一个。您将什么称为数据模型？您是否打算通过网络使用数据模型，将其写入内存中的文件？如果没有更多细节和具体问题，答案会变得更加困难

我打开一个文件，创建数据结构，使用它，保存回一个文件。 “数据模型”是指将有关现实世界对象的信息以及它们之间的关系存储在内存中。我会尝试编辑问题以专注于单个问题。

如果我需要进一步改进问题（如何？），请告诉我。

您似乎正在结合对您正在尝试做的事情的描述，对您提出的解决方案的描述以及关于使用什么解决方案的问题。这些都可以成为一个好问题的有用部分，但我认为您需要将它们分开一点并准确说明您在问什么。

我只是想了解您当前解决方案的结构。当您说“树状结构”时，您的意思是它是在单个类中完成的吗？还是相关类的集合？ “数据重复” => 为什么会这样？为什么不维护相关数据的链接而不是复制它？ “如果你有一片叶子，应该做很多工作” => 这是否意味着更多的实施工作或更多的运行时间？基本上，您是在寻找时间优化或更可维护/易于编码的解决方案吗？

【参考方案1】：

您可能希望了解语义 Web 技术，例如 RDF、RDFS 和 OWL，它们提供了另一种可扩展的世界建模方式。有一些开源的 Triple Store 可用，一些主流的 RDBMS 也有 Triple Store 的能力。

特别看看曼彻斯特大学 Protege/OWL 教程：http://owl.cs.manchester.ac.uk/tutorials/protegeowltutorial/

如果你认为这个方向值得进一步研究，我可以推荐"SEMANTIC WEB for the WORKING ONTOLOGIST"

【讨论】：

OWL 教程很精彩！谢谢你的回答。我需要时间来阅读和理解，以及shipr的解决方案。也许我应该创建两个赏金..;)

【参考方案2】：

仅根据图表，我建议 RDBMS 解决方案确实可行。自从我成为 RDMS（当然称为 RDM！）的开发人员以来已经有好几年了，但我能够更新我的知识并获得非常有价值的关于数据结构和布局的见解，这些见解与您通过阅读精彩的描述非常相似Stephane Faroult 所著的《SQL 的艺术》一书。他的书将在很大程度上回答您的问题。

为了确保准确性，我在亚马逊上提供了一个链接：http://www.amazon.com/The-Art-SQL-Stephane-Faroult/dp/0596008945

阅读它不会出错，即使它最终并没有完全解决你的问题，因为作者在清晰地分解关系并提出优雅的解决方案方面做得非常出色。这本书不是 SQL 手册，而是深入分析了如何思考数据以及数据之间的相互关系。看看吧！

使用 RDBMS 跟踪数据之间的链接可能是一种有效的方式来存储和思考您正在寻求的分析，并且链接是“软”的 - 也就是说，当它们链接的硬对象是删除。这确保了数据的完整性； Fauroult 女士可以回答如何确保这一点保持真实。

【讨论】：

感谢您的回答！我一拿到书就去看看。你能想到实现 RDBMS 解决方案的任何缺点或棘手的问题（本书未涵盖）吗？

除了数据使用 RDBMS 引擎存储到磁盘并且不完全包含在内存中之外，我想不出具体的缺点——但当然这可能是一个优点。最棘手的部分是正确建立关系，并在删除数据时维护它们；但是这本书很好地描述了这些事情。

【参考方案3】：

根据您对可扩展和灵活模型的要求，我不推荐 RDBMS。

无论何时更改数据模型，都必须更改数据库架构，这可能比更改代码涉及更多工作。 只有在运行时才发现数据库查询的任何问题。这会对维护成本产生很大影响。

我强烈建议使用标准 C++ OO 编程和 STL。

您可以利用封装来确保正确完成任何数据更改，并更新相关对象和索引。 您可以使用 STL 为数据构建高效索引 您可以创建外观来轻松获取信息，而不必转到多个对象/集合。这将是一次性工作 您可以制作单元测试用例以确保正确性（与使用数据库的单元测试相比复杂得多） 您可以利用多态性来构建不同类型的对象、不同类型的分析等

所有非常基本的点，但我认为如果您改进当前的解决方案而不是寻找基于数据库的解决方案，您的努力将得到最好的利用。

【讨论】：

实际上我最终在没有 DB 的情况下使用 C++ 完成了这一切。只是更多的抽象和更通用的代码。谢谢你的回答。

【参考方案4】：

http://www.boost.org/doc/libs/1_51_0/libs/multi_index/doc/index.html

"你会付出很多努力来保持这些指针的一致性 并在发生变化时不断更新链接。”

借助 Boost.MultiIndex，您可以在“表”上创建几乎所有类型的索引。我认为引用的问题没有那么严重，所以原来的解决方案是可以管理的。

【讨论】：

感谢您的回答，但我无法立即看到如何使用 multi_index 解决我的问题。请你澄清一下好吗？