結構化查詢語言/關係型資料庫管理系統 (rDBMS)
關係型資料庫管理系統是根據關係模型的設計規則對資料儲存的實現。這種方法允許根據關係代數對資料進行操作，例如投影、選擇、連線、集合運算（並集、差集、交集，…）等等。加上布林代數（與、或、非、存在，…）和其他數學概念，關係代數構建了一個完整的數學系統，包括基本運算、複雜運算以及運算之間的轉換規則。DBA 或應用程式程式設計師不需要了解關係代數。但瞭解你的 rDBMS 基於這種數學基礎是有幫助的——以及它有自由將查詢轉換為多種形式。
關係模型將資料結構設計為關係（表），包含屬性（列）以及這些關係之間的關係。關於現實世界中一個實體的資訊儲存在表的一行中。但是，術語現實世界中一個實體必須謹慎使用。可能是我們的智力以這種方式識別出一個像飛機這樣的機器。根據資訊需求，將所有資訊放入飛機表的一行中可能就足夠了。但在許多情況下，有必要將實體分解成它的組成部分，並將這些組成部分建模為離散實體，包括與整體的關係。例如，如果需要關於飛機中每個座位的詳細資訊，則需要一個名為座位的第二個表以及某種將座位與飛機連線起來的方法。
這種將關於真實實體的資訊分解成複雜資料模型的方式在很大程度上取決於業務概念的資訊需求。此外，還有一些獨立於任何應用程式的形式要求：最終的資料模型應符合所謂的正規化。通常，這些資料模型包含大量表格以及它們之間的關係。這些模型不會預先確定它們在應用程式中的使用；它們純粹是描述性的，不會以任何方式限制對資料的訪問。
資料庫中的操作必須能夠不僅對單個行，而且對行集進行操作。關係代數提供了這種可能性。因此，基於關係代數的語言，例如：SQL，提供了一個強大的語法來在一個命令中操作大量資料。
由於關係代數中的操作可以用不同的但邏輯上等效的操作來代替，因此基於關係代數的語言不應預先確定其語法如何對映到操作（執行計劃）。該語言應該描述應該做什麼，而不是如何做。注意：這種操作的選擇與是否使用索引無關。
正如之前所描述的，關係模型傾向於將物件分解成子物件。在這種情況下和其他情況下，通常需要將來自一堆表中的關聯資訊收集到一個資訊單元中。如何在沒有參與表和行之間連結的情況下實現這一點？答案是：所有連線都是基於實際儲存在屬性中的值進行的。rDBMS 必須自行決定如何到達所有相關的行：是讀取所有可能受影響的行並忽略那些不相關的行（全表掃描），還是使用某種索引並僅讀取匹配條件的那些行。這種基於值的方案甚至允許使用除等於運算子以外的其他運算子，例如
SELECT * FROM gift JOIN box ON gift.extent < box.extent;
此命令將所有“禮物”記錄連線到所有“盒子”記錄，其中“盒子”的“範圍”更大（無論“範圍”是什麼意思）。