對于應用系統(tǒng)。
長久以來存在著兩個建模。
一個是在數(shù)據(jù)庫層的ER關(guān)系模型，
另一個是在應用系統(tǒng)里的OO模型。
應用系統(tǒng)為什么開發(fā)麻煩，很大一個原因是因為要在一套系統(tǒng)里同時維護兩個模型，動了ER模型，必然會影響到OO模型，動了OO模型必然會影響到ER模型。我們很大一部分精力是在維護這兩個模型的統(tǒng)一。這完全是做無用功。
一個有效率的系統(tǒng)只應該存在一個現(xiàn)實模型。這樣就不必為了維護與另一個模型的對應而絞盡腦汁。
在OO思想還未出現(xiàn)的時候，是沒有這種煩惱的。那時的應用系統(tǒng)是數(shù)據(jù)庫驅(qū)動型，只需要在數(shù)據(jù)庫里建立一個ER模型，則整個現(xiàn)實的模型就已經(jīng)建立，剩下的只是操作和顯示。
OO的引入是對應用系統(tǒng)開發(fā)的一次變革，但遺憾的是數(shù)據(jù)庫方面并沒有同時跟進。面向?qū)ο蟮拈_發(fā)其中心思想是在應用系統(tǒng)里用對象來建立一個現(xiàn)實系統(tǒng)的模型。要遵循面向?qū)ο蟮拈_發(fā)方式則必然會在OO層面建立一個模型，但傳統(tǒng)的數(shù)據(jù)庫模型并沒有拋棄，同樣存在在系統(tǒng)里。這樣我們需要建兩次模，同時需要維護兩個模型，而且還需要維護這兩個模型之間的統(tǒng)一。這無疑是一個愚蠢的做法。
有兩條出路來解決這個問題。
第一，以數(shù)據(jù)庫模型為標準，放棄系統(tǒng)的OO模型，這就是數(shù)據(jù)庫驅(qū)動的開發(fā)方式。不需要對象。這種開發(fā)方式很高效，但麻煩也是顯而易見的，不夠靈活。當需求發(fā)生變動的時候，改動ER模型會帶來巨大的影響。當初拋棄這種方式也應該是為了解決這個問題吧。
第二：拋棄ER模型，只專注于OO模型。這樣系統(tǒng)比較直觀，對于系統(tǒng)的擴展和維護人員的接手都是比較容易的。但麻煩是對象需要存儲。這就需要以一種結(jié)構(gòu)存儲在數(shù)據(jù)庫中。這種結(jié)構(gòu)絕對不能是ER關(guān)系。這就需要創(chuàng)造出另一種關(guān)系模型。然后在對象與數(shù)據(jù)庫之間做好轉(zhuǎn)換。數(shù)據(jù)庫層對對象來說是不可見的，開發(fā)人員只需關(guān)心對象的模型就OK。在對象與數(shù)據(jù)存儲上需要提供一種轉(zhuǎn)換，比如隨著業(yè)務的變更，對象需要新增一個屬性，那么必須要提供一個后臺的轉(zhuǎn)換機制，把這個新增的屬性自動添加到數(shù)據(jù)庫中。還需要提供一個對象的查詢機制。