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