資料庫資料結構研究(一)：資料樹範例

回首頁

一、資料庫的兩個發展方向：

在現今關聯資料庫大行其道的今天，各資料庫功能的發展，可以化約成兩大面向。

更廣泛的互相流通功能：

如 SQL 資料庫間結構化查詢語言、ODBC 資料連接等，目的是希望能在更多的不同資料庫間，達成資料存取及流通的功能。尤其在 Internet 大行其道的今天，不只要求的是不同資料庫間的資料流用，更希望有跨 OS 系統的資料存取功能。尤其是 PC Winmdows 與 Net 的 Unix 的對談，更是許多資料庫使用者極力發展的技術及目標。
更多樣的資料結構功能：

如果資料互相流通代表的是資料庫使用者廣度的發展，那麼如何在現有關聯資料庫同層式結構的限制下，發展出更具變化，更能與現實社會現象相符合的，甚至是有階層架構的資料關係，就可以稱做是資料庫功能深度的發展。比起資料庫廣度的發展，資料庫深度的發展就顯的比較落寞冷清。的確，資料庫能做做進銷存，管管工商報表，也就市場廣大到利用無盡了。又何必再進一步去研究資料庫更進一步的結構變化，就算真有什麼新發現，實用價值如何，另人懷疑。

二、資料庫深度發展的一個方向------階層結構的建立

不管資料庫深度發展如何冷門，但相信玩久了關聯資料庫的玩家，總會有那麼點懷疑。那就是關聯資料庫的每筆記錄都是平等的，同層次的，在同一個資料表中，你很難去表明那筆記錄的位階比其他位階高，而那筆記錄又從屬於那筆記錄，總歸一句話，關聯資料庫的記錄結構是平面的，是單層的，你很難建立一種記錄間的階層結構出來。但這與現實社會的現象是相當脫節的，因為社會現象中比比皆是一事物從屬於另一事物，一事物受另一事物的影響，也就是社會事物就是有階層的。因此資料庫功能被局限在進銷存，多少也是受限於關聯資料庫只能管理同質記錄，欠缺管理異質記錄的能力有關。

事實上有人已經開始批評我雞蛋裏挑骨頭了，關聯資料庫本就是一種同質記錄資料庫，要表現異質記錄，就該用樹狀資料庫。問題是現在還有那個樹狀資料庫還在風行的？如果我們還回頭用樹狀資料庫，恐怕真和現今資料庫發展趨向愈行愈遠了。

三、建立關聯資料庫階層結構的可行辦法：

或許有人會說用資料表與資料表關聯啊，把一個資料表當父資料表，一個資料表當子資料表，就有階層從屬關係啦。問題是那只有兩層，如果子資料表還有子資料，那是不是要第三張資料表來關聯，如果一個階層架構有個幾十層，或根本不知有幾層，那要關聯多少張資料表呢？所以完全靠資料表關聯來建立資料階層結構是理論可以，但實務會複雜到根本無法操作。剩下一個辦法是一般關聯資料庫套裝軟體使用者無法操作，只有資料庫程式操作者才能再包裝改變使用方式的辦法。那就是在記錄的欄位結構上做成有對應架構，其原型及操作如下：

每筆記錄除其他顯示欄位資料外，必須有個唯一鍵值的 PrimaryKey 欄位做為每筆記錄的代號(以下簡稱 P_Key)。
每筆記錄要多加一個欄位，來記載它與同資料表聯結對應的其他筆記錄的P_Key 值，以做為 LinkKey (以下簡稱 L_Key)。
當我們要找尋此筆記錄對應紀錄時，就到 L_Key 裏抓出 P_Key 值，再依P_Key 尋找對應記錄。
如果我們要找出資料表中所有對應到此筆記錄的記錄時，就要取出此筆記錄的 P_Key 值，逐一比對資料表中每筆記錄的 L_Key 值，從而列出那些記錄與此筆記錄對應。

OK，就這樣，我們就做出了同資料表中記錄與記錄的對應關係，而此種對應關係就提供一個基本架構，供我們進一步做出記錄的階層結構來。這種記錄對應的原型並未決定我們將要發展出的階層結構是怎麼個模樣，它只為資料表階層結構提供一個無與倫比的優越條件，那就是所有記錄的階層結構，不管它有多少層，通通只需要一張資料表。

四、用記錄對應關係做資料庫的資料樹：

當我們在資料表中形成的記錄對應結構後，整個階層結構並未成型，階層結構只在我們決定怎樣利用這種對應關係時才會決定下來。本篇就在討論如何利用記錄對應結構做出類似檔案目錄結構的目錄樹來，現舉例如下：

如記錄 A 與記錄 B 有對應關係，而記錄 B 的 L_Key 記載著記錄 A 的 P_Key 值，那麼記錄 B 稱為關聯記錄，記錄 A 稱為被關聯記錄。
我們把被關聯記錄視為根、父或上一層，而關聯記錄視為分支、子或下一層。
每筆記錄的 L_Key 裏，都應該有另筆記錄的 P_Key 值，標明它在資料表中的從屬關係，而如果一筆記錄 L_Key 裏的 P_Key 值找不到相對應的記錄，就會被視為另一個獨立的資料樹的最原始的根記錄。在資料表中的資料樹與檔案目錄稍有不同的是整個檔案結構只能有一棵樹，但資料表中的資料樹，可以由您設下法則，定義它只有一棵樹，還是可以同時有很多棵樹。
每筆記錄必須要關聯到另一記錄去，就如同每一個支一定有其根一般，但每一記錄不必然被其他記錄關聯，正如每個根或有分支，或無分支。
記錄和記錄的關聯是單向不可逆的，也就是一被關聯記錄永遠不可關聯到它的下層記錄去。

這些記錄對應的規律，在關聯資料庫裏是沒有規定的，唯有我們透過程式給它這樣的條件操作，也就是資料庫記錄呈現的再包裝，才會呈現一個具有階層架構的資料樹出來。這次夾檔 DataTree.zip 中，DataTree.vbp 專案，就是利用有記錄對應結構的資料表，以程式再包裝的方式，塑造出一個資料樹的階層結構出來，有興趣的朋友可以操作或參考程式碼看看。不過抱歉的是我只會 VB ，所以不熟 VB 的朋友，只有請你看看 DataTree.Mdb 這個 Access 資料庫檔的資料表及查詢表，再用自己的語言操作看看。

五、SQL 查詢和自表關聯對資料樹結構呈現的便利：

基本上當你的資料表有記錄對應的結構，並且遵守資料樹關係建立的規則建立記錄關聯時，你就可以做出資料樹，而不在乎你用那種資料庫或程式語言。但VB 操作資料庫的 Dao 物件，配合上 SQL 查詢，對於呈現及操作一個資料庫的資料樹結構，卻提供很方便而快捷的功能。現分述如下：

SQL 查詢對查詢某記錄分支的便利：

在早期如 DBase 的 DBF 檔操作，你必須先將 L_Key 欄位 Index 後，再針對整個資料表逐筆 Seek 該筆記錄的 P_Key 值，用一個迴圈程式加一個跳離判斷，才能逐一列出該記錄的分支，但當你用 SQL 查詢時，只要你用 WHERE 敘述，以 L_Key=Record.P_KeyValue 為條件，傳回的 Recordset ，就是該記錄的所有分支，用一行程式敘述查出所有分支，就是 SQL 提供的第一個便利功能。
什麼叫自表關聯：

關聯相信使用資料庫的朋友都不陌生，就是 Relationship ，也就是兩張資料表透過兩個相同型態欄位的對應，在兩張資料表中形成一種記錄連動的關係。但我們前面談過，一個有記錄對應關係的資料結構，從頭到尾只用一張資料表，透過 Dbase 解釋就是只有一個 Dbf ，那要如何做兩張資料表的Relationship ？讓關聯記錄與被關聯記錄形成一種 Relationship 聯動呢？我們換個腦筋，假想一下，就是把同樣的 Dbf 檔再複製一份，然後用原表 P_Key當 PrimaryKey ，複製表的 L_Key 當 ForeignKey ，把原表和複製表給Relationship 起來，那不就建立起記錄對應的操作環境了嗎？對，這就是自表關聯的技術概念原型。
Querydef 是解決自表關聯的最佳方案：

我前面講自表關聯是資料表記錄對應操作的技術原型，而不說是解決方案，是因為如果你真在 Dbase 這種早期資料庫如此做，未必真的便利，因為如果整個資料表記錄都已做好，不再新增或變動，那用原表關聯複製表真的很便利，因為你不必先 Seek P_Key 一次，再 Seek L_Key 一次，你只要在原表找到P_key，轉到複製表，就是第一筆對應的 L_Key 記錄位置，但如果你要新增或編輯記錄呢？是不是又得原表 Update 一次，複製表 Update 一次，關聯帶來的便利便被重複的 Update 給抵消了。

但這到了 VB 的 Dao 物件裏就不是這樣的動作了，如果你熟悉 Dao ，你就會知道使用者操作資料庫時真正操作的不是資料表本身，而是它的記憶體執行複本 Recordset ，而且一個資料表在同一時期，可以有好多個執行複本(Recordset)一起執行，如果配合上 SQL ，還可以做成變型的 Recordset 。以前陣子喧騰一時的宋七力案來說，資料表 Tabeldef 是本尊，但實際執行的是無數個 Querydef 和 Recordset 分身。既然可以有很多分身，那用分身和分身去關聯，當然不成問題。你可以在個分身中 Seek、Find、Edit 和 Append ，至於要如何回覆到其他分身及本尊資料表，自有 Dao 為你代勞。所以在夾檔的 datatree.Mdb 中，我就用 qrydatalink 這個 Querydef 為資料表 DataStore 做了第一個分身，再用 qrytreelink 這個 Querydef 把 DataStore 本尊和qrydatalink 分身關聯起來，成了一個標準的自表關聯，為對應的記錄結構安排好了操作的環境，也就是說用了關聯資料庫的便利功能來操作資料樹結構。

六、在資料庫資料樹和檔案目錄資料樹中尋找記錄的不同：

不管我們怎麼包裝資料庫，資料庫的記錄基本上仍是平行的，同層的，所以在資料庫資料樹中找特定記錄會比檔案目錄資料樹中找檔案單純太多了。我們都知道在檔案目錄資料樹中找檔案還真是程式設計師的一個不大不小的折磨，幾乎你不用遞迴程式是無法在一層又一層子目錄中找到特定檔案的。但在資料庫資料樹中找特定記錄就和找一般記錄一樣，都是 Seek or Find 欄位=欄位值這樣一行程式解決。所以在資料庫資料樹中你不必去在意記錄搜尋比對的功能，因為這是關聯資料庫的專長，你要注意的是如何維持及呈現它的階層結構而已。

七、我的一點盼望：

就如我先前一再強調的，關聯資料庫結構的變化，絕對是一個值得研究的專題，而本篇提出的，也只是一點小小的運用而已。希望這塊不怎麼起眼的小磚頭，能引出真正的美玉。如果你曾在資料庫結構上有過怎樣特殊的安排，從而達成某些特殊功能，希望也能分享我們。此外我是個半路出家的程式使用者，對資料庫的基本原裡並不紮實，如果有什麼謬誤，請不吝指正，或者我說的並不透徹，實際上有什麼資料庫原理更為清
楚完備，也請為我們闡明。謹以此篇，求教於所有資料庫玩家。

下載資料庫資料樹範例 DataTree.Zip

回首頁

資料庫資料結構研究(一)：資料樹範例

回首頁

一、資料庫的兩個發展方向：

更廣泛的互相流通功能：

更多樣的資料結構功能：

二、資料庫深度發展的一個方向------階層結構的建立

三、建立關聯資料庫階層結構的可行辦法：

四、用記錄對應關係做資料庫的資料樹：

五、SQL 查詢和自表關聯對資料樹結構呈現的便利：

SQL 查詢對查詢某記錄分支的便利：

什麼叫自表關聯：

Querydef 是解決自表關聯的最佳方案：

六、在資料庫資料樹和檔案目錄資料樹中尋找記錄的不同：

七、我的一點盼望：