針對支持ODBC的NoSQL文檔存儲的關係行爲

Question

第一個斷言是文檔樣式nosql數據庫（如MarkLogic和Mongo）應將每條信息存儲在嵌套/複雜對象中。

考慮下面的模型

<patient> 
    <patientid>1000</patientid> 
    <firstname>Johnny</firstname> 
    <claim> 
     <claimid>1</claimid> 
     <claimdate>2015-01-02</claimdate> 
     <charge><amount>100</amount><code>374.3</code></charge> 
     <charge><amount>200</amount><code>784.3</code></charge> 
    </claim> 
    <claim> 
     <claimid>2</claimid> 
     <claimdate>2015-02-02</claimdate> 
     <charge><amount>300</amount><code>372.2</code></charge> 
     <charge><amount>400</amount><code>783.1</code></charge> 
    </claim> 
</patient> 

在關係世界中，這將被模擬爲病人表，索賠表，要求收費表。

我們的主要願望是同時向下遊應用程序提供這些數據，並對其執行分析。由於我們不想爲每一項措施編寫複雜的程序，因此我們應該能夠在此之上放置一個工具。例如，Tableau聲稱與通過ODBC的MarkLogic具有本地連接。

當我們在文檔模型上使用範圍索引創建視圖時，MarkLogic中的SQL會針對它返回過多的重複結果。費用數字也用總和函數重複計算。這是行不通的。

思想是通過MarkLogic的這些索引，視圖和可能的片段技術，我們可以定義一個類似於關係結構的語義層。

文檔提示您應該爲每個表創建1個對象，但這似乎違背了首選文檔db結構。

什麼是數據建模和應用程序模式來存儲大量的文檔數據，然後提供一個交鑰匙分析工具的頂部？

如果ODBC連接總是返回錯誤的數據而不知道關係，那麼聲明對NoSQL具有ODBC支持的所有工具都是不正確的。

參考

https://docs.marklogic.com/guide/sql/setup

https://docs.marklogic.com/guide/sql/tableau

http://www.marklogic.com/press-releases/marklogic-and-tableau-build-connection/

https://developer.marklogic.com/learn/arch/data-model

Answer 1

對於您的問題：「什麼是數據建模和應用程序模式來存儲大量的文檔數據，然後提供一個交鑰匙分析工具？」

我使用的經驗法則是當我要計算「對象」時，我將它們建模爲單獨的文檔。所以如果你想運行查詢病人，索賠和費用的查詢，你會把它們放在單獨的文件中。

這並不意味着我們將MarkLogic限制爲僅關係模式。在UML術語中，一對多關係可以是組合或聚合。在關係模型中，我不得不將它們建模爲單獨的表格。但在文檔模型中，我可以爲每個對象分別創建文檔或將它們一起滾動 - 通常基於我想要如何查詢數據。

因此，您的第一個斷言是部分正確的 - 在文檔存儲中，您可以選擇嵌套所有相關數據，但是您不必這樣做。還要注意，因爲MarkLogic是模式不可知的，所以根據您的需求變化來轉換您的數據非常簡單（corb是一個很好的選擇）。某些要求可能需要非規範化才能幫助搜索高效運行。

簡單的例子 - 一個人可以有很多名字（別名，婚前姓名）和許多地址（不同的家庭，工作地址）。在關係模型中，我需要一個人表，名稱表和地址表。但我認爲名稱是一個複合關係 - 名稱的生命週期等於人的生命週期 - 所以我寧願將這些名稱嵌入到人員文檔中。地址OTOH的生命週期與個人無關，因此我會將該地址文檔製作成一個地址文件，並將其元素摺疊到每個相關地址的個人文檔中。從分析的角度來看，我現在可以提出許多有關人員及其姓名，人員和地址的有趣問題 - 我無法有效地計算名稱數量，因爲名稱不在單獨的文檔中。

Answer 2

我想相比於其他文件存儲MarkLogic有點非典型的。如果不將整個表格存儲爲一個文檔，而是每個文檔存儲一個記錄，則效果最佳。 MarkLogic索引針對這種方法進行了優化，並以這種方式輕鬆處理數百萬個文檔。您將會看到，只要將記錄存儲爲文檔，Tableau中的結果將大大提高。

將文檔拆分成這樣的小碎片還可以實現更高的性能和更小的佔位面積。 MarkLogic不會將數據保存爲允許隨機訪問的持久DOM樹。相反，它以非常有效的方式傳輸數據，並依靠索引分辨率快速提取相關碎片。

HTH！