第一章: 在RDB中的樹結構資料

標籤：編程   功能   gps   海量資料   news   pre   表達   模型   smart   

第一章: 在RDB中的樹結構資料

在本章中，我將寫一個基本的知識來理解這個問題

一  模型的作用

RBD處理樹模型的作用總結為兩點：

1  在RDB表中儲存樹的資料

2  效率的查詢節點的相關節點

1  在RDB表中儲存樹的資料

我們可以定義的標準，該模型是否具有儲存層次資料的功能

可以由儲存的所有節點再現原有的階層

如果不能通過儲存的資料再現原有的樹結構，就不能說這個模型實現了樹。

2  效率的查詢節點的相關節點

通常，我們將資料儲存到資料庫中進行搜尋，資料中儲存了分層資料，可能會查詢任何節點的關係資料（如子樹、父節點、子節點，祖先節點，子孫節點等）。這是一個樹模型的重要作用。

如下[A], [B], [C]等表示節點。

                [A]               |           +---+---+           |       |          [B]     [C]           |       |         +-+-+   +-+-+         |   |   |   |        [D] [E] [F] [G]                     |                   +-+-+                   |   |                  [H] [I]

當我們查詢[C]的子樹時，通過跟蹤向下延伸的分支來擷取所有的節點。

           [C]           |         +-+-+         |   |        [F] [G]             |           +-+-+           |   |          [H] [I]

跟蹤向下延伸的分支是很有規律性的，因此很多人認為如果將分層資料儲存在資料庫中，我們將很容易地尋找到任何節點的相關節點。

樹形結構資料會像一下的資料集合被頻繁的搜尋。

節點	關係	節點集合
[B]	父節點	[A]
[B]	子節點	[D] [E]
[H]	祖宗節點	[A] [C] [G]
[C]	子孫節點	[F] [G] [H] [I]
[C]	部分木	[C] [F] [G] [H] [I]

有效一詞在這裡是非常重要的，不然也沒有必要設計查詢。這裡做查詢時首先要得到所有節點，然後通過查詢條件過濾。然而，在一個百萬級資料的表中，我們擷取全部節點時需要大量的執行時間和記憶體,每次得到所有的節點是不現實的。如果表中有大量的百萬級相關聯的節點，這個系統的設計在速度將很難上達到指標。 二  執行個體

通過執行個體，說明如何利用查詢尋找層次資料中的相關節點。

尋找祖先節點使用網上的"breadcrumbs list"。

1  祖先節點尋找的執行個體

        [Top Page]            |--[Products]            |     |--[Smart Phone Apps]            |     +--[Desktop Apps]            |--[News]            |     |--[2015/10]            |     |--[2015/09]            |     |--[2015/08]            |     +--[2015/07]            +--[About Us]                  |--[Corporate Philosophy]                  |--[Access]                  +--[Contact Us]

當我們查詢[Corporate Philosophy]的節點，通過跟蹤向上延伸在其頂端的節點如下。

Top Page > About Us > Corporate Philosophy

所有的過度的頁面都會被認為是樹結構，首頁為根節點。當能夠找到Corporate Philosophy的祖先節點就可以再現breadcrumbs list。

2  子孫節點尋找的執行個體

論壇有回複注釋的功能，以此為樹，當將所有注釋視為節點時，所儲存的資料具有階層。查詢論壇中的評論時，我們會使用尋找子樹節點。

        [2015/03/31]            |--[Let‘s Party tonight! (John)]            |     |--[I will join! (Mike)]            |     |     +--[Thanks! (John)]            |     |--[Can not join tonight. (Anne)]            |     |     +--[When OK? (John)]            |     +--[OK, but 2 hours only. (Tom)]            |           |--[Me too. (Eucen)]            |           +--[I see! (John)]            +--[I losted my smart phone. (Bill)]                  |--[When? (Diana)]                  |     +--[Yesterday. (Bill)]                  +--[Did you check GPS? (Fred)]                        +--[Yet (Bill)]

如上，在2015年3月31日有兩個線程，當只顯示Let‘s Party tonight! (John)時就需要查詢評論John的所有子樹。在這種情況下，由於論壇海量資料節點的純在效率問題，不能使用尋找所有節點的方法。

三  關聯式模式的問題點

再次重申下RBD處理樹模型的作用。

1  在RDB表中儲存樹的資料

2  效率的查詢節點的相關節點

很難寫出一個高效的查詢原因有一下幾點。

1  要想搜尋，首先要儲存每個節點的所有祖先節點

2  節點關係資料量相對深度呈指數倍增長

3  層次的深度不取決於資料的內容

4  在資料庫中對層次資料賦予索引是困難的。因為樹結構具有二維擴散，但指數是一維結構

5  等等

如果從指定節點找到一組子孫節點，可以通過跟蹤分支方向來確定，這是一個簡單的事。然而SQL是說明性編程（declarative programming），因此不能為每個節點確定關係，比如在單獨的進程中使用命令式編程。

在聲明式編程，我們如何能夠表達在搜尋查詢子樹和祖先節點的關係？

世界各地的資料庫工程師都在挑戰這個問題，RDB中的分層資料的問題點關鍵就在於“如何有效查詢節點相關的任何節點”。

 

四  列的追加

為瞭解決儲存層次樹資料，工程師們已經研發了四種模型來解決這個問題。

鄰接表模型(adjacency list model)

路徑枚舉模型（path enumeration model）

嵌套集合模型（nested set model）

關閉表模型（closure table model）

無論在哪一種模型中，無非都是在RDB中添加一些列來儲存分層資料。所添加的列按照其作用可以分為兩類。

1  階層列

2  效率搜尋列

1  階層列

需要儲存層次資料在RDB表中。也在查詢中被用作為一個檢索條件的列。

2  效率搜尋列

第一章: 在RDB中的樹結構資料