作者：Sinclair Target

編譯：碼農翻身

原文：

https://twobithistory.org/2017/10/07/the-most-important-database.html

1962年，肯尼迪總統向美國人發起挑戰，這十年結束前能把人送往月球，而一個英勇的工程計劃將此推上頂峰，即尼爾·阿姆斯特朗邁出了探索月球表面的第一步。 

這一開拓性嘗試可謂是碩果累累，清晰可見而又令人振奮——新型宇宙飛船,嶄新太空服，月球車等等。然而阿波羅計劃龐雜多樣，不得不發明新技術，IBM的資訊管理系統(IMS)就是這些技術之一。 

IMS是一個數據庫管理系統，NASA（美國國家航空航天局）需要這樣的系統來追蹤瞭解所有建造土星五號運載火箭的部件，因為足足有兩百萬個零件，這肯定是一個巨大的挑戰。  

1965年，NASA命IBM和北美航空公司以及卡特彼勒公司展開合作共建資料庫。到1968年，IBM已在NASA安裝有IMS的工作版本，儘管當時稱其為ICS/DL/I，即資訊控制系統和資料語言/介面。

兩年後，IBM將ICS/DL/I重塑為“IMS”的形象，並開始出售給其他客戶。這是最早的商業化的資料庫管理系統之一。 

不可思議的是，IMS今天仍在使用，而且使用範圍可不小，銀行，保險公司，醫院以及政府機構仍利用IMS執行各種各樣的艱鉅任務。超過95%的財富1000強公司使用IMS ,而美國五大銀行也是如此。

不管何時從ATM中取錢，你有極大概率在交易過程中與IMS產生聯絡。在這個世界上，雖然IMS是使人“憎厭的”、1970年關係資料庫發明之前的那一時代的遺留物，但仍然是負責重要資料的資料庫。 

IMS基於層次模型工作，這意味著IMS不會將資料視為可以Join的二維表，而是將資料視為樹。 

舉個例子，假設你要儲存銀行客戶的資訊。你可能有一種型別的記錄來表示客戶(Customer)，另一種型別的記錄來表示該客戶的帳戶(Account)。 

關係資料庫中每個表都有列，在層次資料庫中，這些記錄將有不同的欄位; 例如給每個客戶提供名字欄位，姓氏欄位和城市欄位。  

然後，我們必須決定是首先查詢Customer，然後查詢有關該客戶的Account資訊，或者反過來。假設我們決定首先訪問Customer，那麼將使我們的Account成為Customer的子項。如圖所示，我們的資料庫模型看起來像這樣：

實際的資料可能如下所示： 

每個父記錄都包含指向其子節點的指標，這意味著我們可以從根節點向下移動。（實際上，每個父記錄基本上只儲存一個指向第一個子節點的指標。子節點們包含指向其他子節點的指標。這確保了記錄的大小不會隨著子節點的數量而變化。）  

（碼農翻身注：圖中的箭頭並不是“指標”，而是表達父子關係） 

只要我們以第一次構建資料庫時預期的方式訪問資料（先訪問Customer，再訪問Account），就可以非常快速地進行資料訪問。 根據IBM的說法，IMS例項每秒可處理超過100,000個事務，這可能是IMS仍在使用的主要原因，特別是在銀行。 

然而，缺點是我們失去了很多靈活性。 如果我們想要以未經預設的方式訪問資料，可能會遭遇困難，比如，使用者給出了一個Account Number， 然後想更新自己的地址（在Customer型別當中），怎麼辦呢？ 所有的訪問都是從樹的根部（即Customer）開始，這個時候想要找到Account Number的記錄，代價是非常高的。 

一種解決辦法是引入使用重複的資料，比如新建一個層次模型，這個模型的根是Account，然後把Cutomer作為子節點。  

正是這種不靈活性和資訊重複的問題促使E. F. Codd（埃德加·弗蘭克·科德）在1970年的論文“大型共享資料庫的資料關係模型”中提出了關係模型。使用這種模型，使用者就不必關心資料的具體儲存方式。 

從某種意義上看，分層模型是一種自下而上的模型，是對具體現實的表示。而關係模型是基於關係代數的抽象模型，並且是自上而下的，因為資料儲存方案可以是任意的，只要它適應模型。  

不像MySQL，IMS並不是你可以自行下載並在計算機上隨心使用的東西。首先，IMS不是免費的，因此你必須從IBM購買它。但更大的問題是IMS只能在像IBM z13這樣的IBM大型機上執行，這是很遺憾的，因為嘗試IMS將是一件樂事，還能確切瞭解到它與MySQL之類的區別。 

但即使沒有這個機會，想到軟體系統以我們意料之外或尚不習慣的方式工作，也很有趣。特別有趣的是，儘管這些系統看起來不為人知，實際上卻是當地醫院，整個金融部門甚至聯邦政府的支柱。