一．對“現實世界”實體的表達能力比較弱
　　規范化通常導致表與“現實世界”中的實體不對應，它將“現實世界”中的實體分割成幾張表來顯示，以物理表示法來反映實體結構，這樣效率會比較差，常常要在查詢處理中進行很多連接操作。
　　

二．語義過載
　　關系模型表達數據和數據間關系的構造只有一種——表。例如，為了表達實體A和實體B之間的多對多（*:*）關系、我們需要創建三張表，兩個分別用于表達實體A和B，第三張表用于表達實體間的關系。它沒有一種機制來區分實體和關系，也無法區分在實體間存在的不同種類的關系。例如，一個1:*關系可能是Has、Supervises、Manages等等。如果可以進行區分，也許我們就可以將語義構建到操作中。所以，我們說關系模型語義過載了。
　　

三.不能很好的支持業務規則
　　很多商業化系統不能完全支持實體和參照完整性、域等業務規則，所以需要將它們內置到應用程序中。這樣當然是危險的，而且容易導致做重復的工作。更糟糕的是，可能還會引起不一致現象。而且，在關系模型中不支持其他類型的業務規則，這又意味著它們需要被構建到DBMS或應用程序中。
　　

四．有限的操作
　　關系模型只有一些固定的操作集，例如面向集合和記錄的操作，操作是在SQL規格說明中提供的。但是，SQL目前不允許指定新的操作。因此，在給許多“現實世界”對象的行為建模就有了太多的限制。例如，一個GIS應用程序典型的使用點、線、線組、多邊形和一些處理距離、交叉點和包含關系的操作。
　　

五．處理遞歸查詢困難
　　數據的原子性意味著在關系模型中不允許出現重復的數據組，這樣就導致了處理遞歸查詢極為困難。遞歸查詢就是那些有關表和自身直接或間接的關系的查詢。為了解決這個問題，SQL可以嵌入在一個高級程序設計語言中，由高級程序設計語言來提供支持反復操作的功能。而且，很多RDBMS提供了具有類似結構的報表書寫程序。不管是哪種情況，都是應用程序而不是系統的內在功能提供了所需的功能。
　　

六．阻抗失配
　　直到最新版本的SQL標準，都缺少完全的計算功能。為了解決這個問題并且提供更多的靈活性，SQL標準提供嵌入式SQL來幫助開發更加復雜的數據庫應用程序。但是，這引起了阻抗不匹配（impedance mismatch）的問題，因為我們將兩種不同的程序設計模式混合在了一起。
　　1.SQL是一種處理行數據的聲明性語言，而諸如C語言這樣的高級語言則是過程化的語言，一次只能處理一行數據。
　　2.SQL和3GL使用不同的模型來表達數據。比如，SQL提供內置的數據類型Date（日期型）和Interval（時間間隔型），而在傳統的編程語言中卻沒有這樣的類型。因此，就需要應用程序在兩種表示法之間進行轉換。而這樣做無論從程序設計的工作量還是運行時資源的使用來看都是低效的。而且，由于我們使用兩種不同的系統，因此，不可能將類型檢測作為一個整體自動進行。
　　注：SQL標準(SQL3)通過引入許多新的特征已經彌補了上文中講述的一些不足之處。
　　文章來源: baike.duba.net