不足
一．對“現實世界”實體的表達能力比較弱
規範化通常導致表與“現實世界”中的實體不對應，它將“現實世界”中的實體分割成幾張表來顯示，以物理表示法來反映實體結構，這樣效率會比較差，常常要在查詢處理中進行很多連線操作。
二．語義過載
關係模型表達數據和數據間關係的構造只有一種——表。例如，為了表達實體a和實體b之間的多對多（*:*）關係、我們需要創建三張表，兩個分別用於表達實體a和b，第三張表用於表達實體間的關係。它沒有一種機制來區分實體和關係，也無法區分在實體間存在的不同種類的關係。例如，一個1:*關係可能是has、supervises、manages等等。如果可以進行區分，也許我們就可以將語義構建到操作中。所以，我們說關係模型語義過載了。
三.不能很好的支持業務規則
很多商業化系統不能完全支持實體和參照完整性、域等業務規則，所以需要將它們內置到應用程式中。這樣當然是危險的，而且容易導致做重複的工作。更糟糕的是，可能還會引起不一致現象。而且，在關係模型中不支持其他類型的業務規則，這又意味著它們需要被構建到dbms或應用程式中。
關係
關係模型的數據結構非常單一。在關係模型中，現實世界的實體以及實體間的各種聯繫均用關係來表示。在用戶看來，關係模型中數據的邏輯結構是一張二維數據表。
關係操作
關係模型給出了關係操作的能力，但不對RDBMS語言給出具體的語法要求。
關係模型中常用的關係操作包括：選擇（select）、投影（project）、連線（join）、除（Divide）、並（Union）、交（Intersection）、差（Difference）等查詢（Query）操作和增加（Insert）、刪除（Delete）、修改（Update）操作兩大部分。查詢的表達能力是其中最重要的部分。
關係操作的的特點是集合操作方式，即操作的對象和結構都是集合。這種操作方式也稱為一次一集合（set-at-a-time）的方式。相應地，非關係數據模型的數據操作方式則為一次一記錄（record-at-a-time）的方式。
早期的關係操作能力通常用代數方式或邏輯方式來表示，分別稱為關係代數和關係演算。關係代數是用對關係的運算來表達查詢要求的方式。關係演算是用謂詞來表達查詢要求的方式。關係演算又可按謂詞變元得基本對象是元組變數還是域變數分為元組關係演算和域關係演算。關係代數、元組關係演算和域關係演算三種語言在表達能力是完全等價的。
關係代數、元組關係演算和域關係演算均是抽象的查詢語言，這些抽象的語言與具體的DBMS中實現的實際語言並不完全一樣。但它們能用作評估實際系統中查詢語言能力的標準或基礎。實際的查詢語言除了提供關係代數或關係演算的功能外，還提供了許多附加功能，例如集函式、關係賦值、算數運算等。
關係語言是一種高度非過程化的語言，用戶不必請求DBA為其建立特殊的存取路徑，存取路徑的選擇由DBMS的最佳化機制來完成，此外，用戶不必求助於循環結構就可以完成數據操作。
三類完整約束
關係模型允許定義三類完整性約束；實體完整性、參照完整性和用戶定義的完整性。其中實體完整性和參照完整性是關係模型必須滿足的完整性約束條件，體現了具體領域中的語義約束。
實體完整性規則：若屬性A是基本關係R的主屬性，則屬性A不能取空值。實體完整性規則規定基本關係的所有主屬性都不能取空值，而不僅是主碼整體不能取空值。
（1）實體完整性規則是針對基本關係而言的。一個基本表通常對應現實世界的一個實體集。例如學生關係對應於學生的集合。
（2）現實世界中的實體是可區分的，即它們具有某種唯一性標誌。
（3）相應地，關係模型中以主碼作為唯一性標誌。
（4）主碼中的屬性即主屬性不能取空值。所謂空值就是“不知道”或“無意義”的值。如果主屬性取空值，就說明存在某個不可標識的實體，即存在不可區分的實體。這與第（2）點相矛盾，因此這個規則成為實體完整性。
參照完整性規則：若屬性（或屬性組）F是基本關係R的外碼，它對於基本關係S的主碼K相對應（基本關係R和S不一定是不同的關係），則對於R中的每個元組在F上的值必須為：或者取空值（F的每個屬性值均為空值）；或者等於S中某個元組的主碼值。
用戶定義的完整性就是針對某一具體關係資料庫的約束條件。它反映某一具體套用所涉及的數據必須滿足的語義要求。例如某個屬性必須取唯一值、某些屬性值之間應滿足一定的函式關係、某個屬性的取值範圍在0~100之間等。關係模型應提供定義和檢驗這類完整性的機制，以便於用統一的系統的方法處理他們，而不要由應用程式承擔這一功能。
