分層數據模型的替代方案

Question

問題域

我正在開發一個相當大的應用程序，它使用分層數據模型。 它采用圖像，提取圖像的特征並在這些特征之上創建分析對象。 所以基本模型就像Object-（1：N）-Image_features-（1：1）-Image。 但是同一組圖像可用於創建多個分析對象（具有不同選項）。

然后一個對象和圖像可以有很多其他連接對象，就像分析對象可以用附加數據或復雜的結論（解決方案）可以基於分析對象和其他數據。

當前解決方案

這是解決方案的草圖。 堆棧表示對象集，箭頭表示指針（即圖像特征鏈接到它們的圖像，但反之亦然）。 一些部分：圖像，圖像特征，附加數據，可以包含在多個分析對象中（因為用戶想要對不同的對象集進行分析，以不同的方式組合）。

圖像，特征，附加數據和分析對象存儲在全局存儲（上帝對象）中。 解決方案通過組合存儲在分析對象內（並依次包含解決方案功能）。

所有實體（圖像，圖像特征，分析對象，解決方案，附加數據）都是相應類的實例（如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 work 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. 您可以利用多態來構建不同類型的對象，不同類型的分析等

所有非常基本的觀點，但我認為如果你改進當前的解決方案而不是尋找基於數據庫的解決方案，你的努力將得到最好的利用。