大型共享資料庫的資料關係模型

未來的資料庫使用者一定是和資料在機器中的儲存（即資料庫的內部模式）相互隔離的。而通過提示服務來提供資訊是一個不太令人滿意的解決方法。當資料可得內部模式表示發生改變，甚至資料外部表示的多個方面發生改變的時候，終端使用者和大多數的應用程式的活動都不會受到影響。因此，查詢、更新和報告儲存資訊型別的自然增長和變動都需要在資料表示中表現出來。

  現存的不可推斷的、格式化的資料系統給使用者提供了樹結構的檔案或者更一般的網路模式的資料。本文的第一部分討論這些模式的不足之處，並且會介紹一種基於n元組關係的模式，一種資料庫關係的正式形式和通用資料子句的概念。第二部分將討論一些關係的操作（不是邏輯層面的），並且把這些操作應用於使用者模式上解決冗餘和一致性的問題。

1.關係模式和一般模式

1.1簡介

  這篇文章是關於系統的基本關係原理的應用，這個原理提供了共享大型格式化資料庫的方法。除了childs[1]的文章有介紹之外，利用資料庫系統關係的主要應用還表現在演繹推理的問答系統中。Levein和Maron[2]提供了大量的關於這個領域的參考資料。

  相比之下，這裡要解決的問題是一些資料獨立性的問題-應用程式和終端活動之於資料型別增長和資料表示變動的獨立性，而資料一致性問題即使在非演繹推理型系統中也是棘手的。

  在目前流行的非演繹推理系統中，第一部分要介紹資料關係檢視（或者叫做模式）在一些方面似乎優於圖模式和網路模式。這種模式提供了一種根據資料的自然結構來描述資料的方式，也就是說，不用為了資料的機器表示而新增其他的結構，因此，這種模式為高水準的資料語言提供了基礎，而這種資料語言機制一方面可以達到最大化程式之間的獨立性，另一方面也可以最大化資料的機器表示和組織之間的獨立性。

  關係模式更高一級的優勢在於它構成了關係處理可導性，冗餘性和一致性的堅固基礎。這些將在第二部分討論。另一方面，網路模型產生了一些混淆，尤其是把連線的源誤作為關係的源。（見第二部分“連線陷阱”）

  最後，關係檢視允許對目前格式化資料系統的範圍和邏輯限制的更清晰的估算，並且有在單獨的系統內競爭資料表示方式的優點（從邏輯的觀點），更清楚這個觀點的例項會在本文中的不同部分中被闡釋，但是支援關係模式的系統實現不會討論。

1.2目前系統的資料相關性

  最近發展的資訊系統中資料描述表的提供是向資料獨立性目標靠近的重要提高，這些表可以使改變資料表示的某些特徵變得更加容易一些。但是，許多資料表示特徵可以在不邏輯的削弱一些應用程式的情況下，被改變的功能仍然受到相當的限制。更進一步，與使用者互動的資料模式仍然有一些散亂的代表性特徵。特別是關於資料收集的描述（如個人名目），三個仍然需要提高的資料獨立性的主要型別是：排序依賴，索引依賴，存取路徑依賴。在一些系統中這些依賴之間並不是明確分隔的。

1.2.1排序依賴（順序依賴）

  資料庫中的資料元素可以有很多種儲存方式，一些是不考慮順序的，一些是允許一個元素只參加一個排序，而另一些則允許每個元素參加多個排序。現在讓我們來看看要求或允許資料元素儲存在至少一個總排序的現存系統，而這種總排序是與硬體決定的排序地址密切相關的。？？？。這種系統通常允許應用程式自己假定檔案記錄的表示順序與其在磁碟上的儲存順序是相同的（或者說是儲存排序的子目）。這些運用檔案儲存順序有利條件的應用程式，如果由於某些原因而變得需要用一個新排序替換這種排序的時候，很可能不能正確的執行。以指標方式實現的儲存序列也有相似的問題。

  我們沒有必要挑選任何一個系統作為例子，因為現在上市的所有著名的資訊系統在清楚區別表示順序和儲存順序方面都是失敗的。重要的實現問題必須得到解決來提供這種獨立性。

1.2.2索引依賴。格式化資料的上下文聯絡中，索引通常被看成資料表示的一個純粹的效能導向元件。它傾向於提高對查詢和更新的響應，同時減慢了對插入和刪除的響應，從資訊的觀點來看，索引是資料表示的冗餘構造成分。如果一個系統全部用索引，並且它在變化活動形式的資料庫環境中能夠表現的很好，那麼不時地產生和銷燬索引的能力可能是必須的，那麼問題來了：應用程式和終端活動在索引項來去的時候仍然能夠不受影響嗎？

  目前，格式化資料系統採用很不同的方法來進行索引，TDMS無條件的提供了所有屬性上的索引，IMS目前釋出的版本為使用者提供了每一檔案選擇的權利：是完全沒有索引（層次序列的組織）和只有主鍵索引（層次化索引序列組織）。沒有一種會使用使用者的用用邏輯依賴於無條件提供的索引的存在。但是IDS允許檔案設計者選擇用於索引的屬性和指定用於與索引通過外加鏈的方式組合成檔案結構的屬性。運用索引鏈效能的優勢的應用程式必須通過名字來引用這些鏈。如果這些鏈後來被刪除了，那麼這些程式就無法正確的運行了。

1.2.3存取路徑依賴

  許多現存格式化資料系統為使用者提供了樹結構的檔案或者更一般的資料網路模式。為和這類系統共同工作而發展的應用程式，在樹和網路的結構改變時，往往會在邏輯層受到削弱。一個簡單的例子如下。設想資料庫包含關於部件和工程的資訊。對於每一個部件，其部件號、部件名字、部件描述、在手的數量和訂單上的數量的資訊都被記錄。對於每一個工程，其工程編號、工程名字和工程描述的資訊被記錄。無論什麼時候，一個工程要用特定部件的時候，用於這個工程的那種部件的數量也會被記錄。假設系統要求使用者或者檔案創作者根據樹結構宣告或者定義資料，那麼，任一層次結構都可以用到如上提到的資訊上（見結構1-5）。

  現在考慮列印用於名為“alpha”的工程每個部件的編號、部件名和數量。不考慮用於面向樹的資訊系統可以用於解決這個問題，我們可以得到以下的發現，如果程式p是開發用於解決這個問題（假設結構是上面五種結構中的一種），也就是說p不會檢測哪一種結構對他來說是有效的，然而這樣的結構是p至少在其中三個結構中都是失效的。更具體的來說，如果p對結構5是行之有效的，那麼在其他結構上就會失敗；如果p對結構3或者4是行之有效的，那麼它至少在1，2,5上是失敗的；如果p對結構1或者2是行之有效的，那麼它至少會在結構3,4,5上是失敗的。對於每一種情況的原因都很簡單，在沒有經過檢測來決定哪種結構是有效的情況下，p會失敗是因為它試圖引用一個不存在的檔案（現在可用的系統把這種情況視為error）或者它沒有引用包含它必需資訊的檔案。有疑問的讀者應該找一些樣例程式來理解這個簡單的問題。由於在一般情況下，開發可以檢測系統允許的所有樹結構的應用程式是不實際的，而且這種程式在結構需要改變的時候會失敗。