關係持久性建模

關係持久性建模 物件導向是偉大的技術。關聯式資料庫是偉大的技術。如果這兩種技術相互隔絕，那將是人類生活的一次災難，更是我們的巨大悲哀。幸運的是，這種假設沒有成為現實。上述兩種偉大的技術得到了人們的重視，同樣應該受到重視的還有如何將它們調和在一起。 並不是世界上所有的東西都能夠輕而易舉地結合起來。關聯式資料庫和物件導向就是這樣。可是造物弄人，偏偏是這樣背景不同特性迥異的兩個東西卻有著一個無法抗拒的理由把它們聯絡到一塊。同時使用關聯式資料庫和物件導向技術可以使我們編寫出能夠管理大量資料的複雜的應用程式。正是基於此，才使我們有如此大的衝動，想要認真探究一下關聯式資料庫與物件導向之間究竟有哪些異同。 首先讓我們來瞭解一下關聯式資料庫系統所具有地特點∶
    資料以二維表格形式表達；    表中資料之間的關係以儲存在表中的值來表達；    使用SQL，可以動態地建立資料之間的關係；    具體的某些資料實體之間的關係在資料庫最初設計時，不一定要定義或可觀察。在來看一下物件導向系統地特點∶    應用程式由一組對象組成，對象當然包括屬性和操作；    對象是由開發人員定義的資料類型；    對象之間可能具有很複雜的關係，如繼承、關聯、彙總和組合；    類，準確地說是資料類型，之間的關係不容易修改，也不容易在系統建成之後動態建立；    持久對象應該可以儲存到外儲存空間上。基於他們各自的這些特點，關聯式資料庫和物件導向之間存在以下不同∶    類型系統不同；    語言不同；    範例不同；    基本資料實體不同。 不同的類型系統關聯式資料庫類型系統比較簡單。關聯式資料庫資料類型用來定義資料庫表中的欄位。儲存在欄位裡的資料必須符合該列的類型。每一行每一列的資料類型必須是原子的。物件模型則比較複雜。每個對象都可以包含眾多屬性和操作。所以對象顯然不是原子性的。我們根本無法在表中儲存物件。對象的特性是封裝、繼承和多態性。而關聯式資料庫裡談這些都是廢話。 不同的語言關聯式資料庫裡我們使用SQL完成所有的事情。但是SQL沒有處理對象的能力，不可能支援封裝、繼承、多態。SQL最基本的目的就是存取資料庫表裡面的資料，這是它唯一能做的。而物件導向的語言則可愛得多。支援封裝、繼承、多態。我們可以隨心所欲建立複雜的資料類型。但是當我們必須把大量持久對象寫在硬碟上並且時不時進行查詢時就會發現，這些語言在這方面的能力實在蹩腳。SQL可以儲存並查詢大量資料，但沒有對象處理能力。物件導向語言能夠處理複雜的對象，但對象持久化方面的能力非常弱。 不同的範例使用關聯式模式必須讓資料適應模型，而物件導向則需要儘力使模型適應真實世界。 不同的基本資料實體物件模型到關聯式模式的映射，是類到關係表之間的映射。類對應著表，對象對應著記錄，屬性對應欄位。困難在於，物件導向語言的基本資料實體是類，而關聯式模式的基本資料實體是欄位。 以上的四點不同最終導致了我們在設計階段的困難。對於我們這些篤信物件導向的傢伙來說，災難往往發生在設計階段接近尾聲，編碼工作即將來臨之際。當我們費盡九牛二虎之力，在用況圖上畫出一堆又一堆達芬其的雞蛋，完成了充滿律動的順序圖，製作了嚴肅規整的類圖並且在上面布滿各式各樣的小箭頭之後，突然發現，我們真正需要的是一個能夠方便儲存大量資料的關聯式資料庫，藉助它才是把那些活躍的小對象們安頓到硬碟上的最好方式。但是我們如何才能得到這個急需的關聯式資料庫呢？難道我們就應該回到最初的需求文檔，按照傳統的方式，從頭再來一遍嗎？當然不是。這並非是單純的怕麻煩，更重要的是，我們需要進行持久化的是對象，而不是傳統意義上的“資料”，畢竟我們要打造的系統是一個物件導向的系統。按照傳統方法繪製E-R圖未必能夠設計出真正符合系統需要的資料庫。既然如此，我們就完全有理由按照物件導向的思路繼續走下去。此時的我們真正需要做的是繪製一個持久模型，藉助它我們完全可以把對象映射到關聯式資料庫。 要把對象映射到關聯式資料庫其實很簡單，我們只需要一些基本的技巧，簡單的說，有如下幾項∶    把屬性對應到列；    把類映射到表；    在關聯式資料庫中“實現繼承”；    映射關聯、彙總和組合。 把屬性對應到列類的一個屬性可以映射到一列，也可能需要映射到多個列，當然也可能需要把多個屬性對應到表的一列。但是通常都只需要把一個屬性對應到一個列。另外，並非所有的屬性都需要持久化。比如，有一些屬性完全可以當成計算資料行來處理。 把類映射到表把類映射到表。這句話看起來比較容易理解，但是卻容易讓人產生誤解。有些人可能會誤以為一個類就應該映射到一張表。但是這並不總是正確的。實際上這種一一對應並不是總那麼靈驗。有些時候一個類也需要映射成多個表，而另一些時候多個類卻也可以映射成一張表。這需要一些經驗，需要具體問題具體分析。 在關聯式資料庫中“實現繼承”這當然是不可能的。前面已經反覆提到過，關聯式資料庫不可能支援繼承。這個問題的本質是，當把類映射到表的時候，如何解決那些存在泛化關係的類。我們有三個方法應對這種問題，都不複雜。三種方法各有憂略，沒有哪一種是十全十美的。我們不妨通過執行個體來理解這些方法。 首先，我們看到這樣一張類圖： 圖1：三個要映射到關聯式模式的類 人類顯然是一個抽象類別，類名是斜體字。它有兩個子類，學生和教授。學生類只有一個屬性，成績。同樣教授類也只有一個屬性，工資。我們忽略掉方法，因為和我們要討論的問題無關。我們要把這樣一個類層次映射到關聯式資料庫有三種方法可以選擇。 方法一：對整個類層次使用一個資料實體說得明白點就是把三個類影射到同一張資料表裡面去，三個類的所有屬性都映射成同一張表裡的列。就像圖二這樣。 圖2：對整個類層次使用同一個資料實體（這不是類圖，儘管看起來很像）  這個方法很簡單。這個表用起來也很方便。但是，我不說大家也知道。簡單的東西往往都有一些小缺憾。浪費空間是顯而易見的，即使我們只有三個類。但是設想一下如果我們有五個十個甚至更多的類，它們之間存在繼承關係，的時候，這樣作會怎麼樣。那樣對空間的浪費真的是可怕的。另外，如果某一個類增加了一個屬性，那麼表就要增加一個屬性，這樣實際上影響了三個類的對象。如果增加單個屬性時發生了錯誤，會影響整個層次中的所有類。這種錯誤一旦在程式運行過程中發作，你可能根本摸不到頭腦，它們真的非常隱蔽，令人難以察覺。 方法二：每個具體類都使用一個資料體每個具體類都會被映射到一張表。所謂具體類，在本例中，是指“學生”和“教授”類，當然不包括抽象類別“人”。每個表代表著一個類，它包含那個類的所有必須的屬性，更重要的是它包含了那個類的繼承屬性。3所示。 圖3：每個具體類都使用一個資料體（這不是類圖，儘管看起來很像）  這種方法同樣有一個顯著的缺點，如果需要修改一個類，那就必須修改它的表和所有子表。另外，如果有一個人即是學生又是教授的時候就比較麻煩了。這樣需要在兩個表裡面分別儲存同一個人的記錄。而且這個人會有一個學生編號和一個教授編號。有一些時候，可能這是無法容忍的。 方法三：每個類使用一個資料實體為每一個類建立一張表。子類的表的主鍵同時作為外鍵。如： 圖4：每個類使用一個資料實體（這不是類圖，儘管看起來很像） 我最喜歡這種方式，因為這樣最符合物件導向的概念。某一個類發生變化時，也很容易修改相應的表。但是，缺點是資料庫裡面會有很多表。讀寫資料的效率可能會有一些慢。另外，採用這種方法還要注意靈活使用視圖。正如前面所說的那樣，沒有任何一個方法是十全十美的。究竟選擇哪種方法，需要在實踐過程中具體問題具體分析，擇其善者而從之。 映射關聯、彙總和組合僅僅把類映射到表，屬性對應到列，這樣顯然是不夠的。與此同時還必須把類之間的關係映射到關聯式資料庫裡面。類之間的關係無非就是繼承、關聯、彙總、組合。繼承剛才已經單獨討論，現在就來看關聯、彙總和組合是如何映射到關聯式模式中去的。 使用外鍵在關聯式資料庫實作類別之間關聯可以使用外鍵在關聯式資料庫中實現關聯。比如，存在這樣一種關聯關係，“一個僱員工作在一個崗位上”。類圖顯然應該如所示：  圖5：一個僱員工作在一個崗位上 在關聯式資料庫裡，可以在僱員表上添加一個外鍵，像這樣。 圖6：在僱員表上添加一個外鍵（不是類圖，儘管看起來很像） 通過關聯表在關聯式資料庫實作類別之間的多對多關聯假設存在這樣一種常見的關聯，“一個騎士可以騎多匹馬，每匹馬也可以由多名騎士來騎”。類圖如下：圖7：一個騎士可以騎多匹馬，每匹馬也可以由多名騎士來騎 在關聯式資料庫上加一個關聯表來表示兩個類之間多對多的關聯關係。圖8：使用關聯表表示類之間多對多關聯關係 使用以上介紹的技巧，完全可以把持久對象有效映射到關聯式資料庫裡面。根據我自己的嘗試，這的確是一個有效方法。如果大家感興趣不妨在實踐中嘗試一下。