分层数据模型的替代方案

Question

问题域

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

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

当前解决方案

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

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

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

目前的解决方案缺点

1. 当您需要草图中的虚线连接时，导航此结构会很痛苦。如果必须在顶部显示具有几个解决方案功能的图像，则首先必须遍历分析对象以查找基于此图像的图像，然后遍历解决方案以显示它们。
2. 如果要解决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 ++对象关系的任何建议表示赞赏。

Answer 1

您可能希望了解语义Web技术，例如RDF，RDFS和OWL，它们提供了一种替代的，可扩展的世界建模方法。有一些开源三元组可用，一些主流RDBMS也具有三重存储功能。

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

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

Answer 2

基于该图，我建议RDBMS解决方案确实可行。自从我成为RDMS的开发人员（当然叫做RDM）以来已经有好几年了，但是我能够更新我的知识并获得很多关于数据结构和布局的宝贵见解，非常类似于你通过阅读神话般的描述预订Stephane Faroult撰写的“SQL的艺术”。他的书将很长一段时间来回答你的问题。

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

通过阅读它不会出错，即使最终它没有完全解决你的问题，因为作者在明确的条款中打破关系并提出优雅的解决方案做得非常出色。本书不是SQL的手册，而是深入分析如何思考数据及其如何相互关联。看看吧！

使用RDBMS跟踪数据之间的链接可以是存储和思考您正在寻找的分析的有效方式，并且链接是“软”的 - 也就是说，当它们链接的硬件对象时它们会消失删除。这确保了数据完整性;而Mssr Fauroult可以回答如何做以确保这一点。

Answer 3

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

  

“你会非常努力地保持这些指针的一致性   当事情发生变化时不断更新链接。“

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

Answer 4

我不建议根据您对可扩展和灵活模型的要求来使用RDBMS。

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

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

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

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