為什麼使用“關係（al）”一詞？
用英語，我們可能會談論鮑勃和蒂姆之間的關係。也許他們是堂兄弟。在這種情況下，“關係”一詞對我來說很有意義。
在關係數據庫的上下文中，我理解該術語指的是什麼，但我不明白為什麼要使用它。我認為了解為什麼使用它將有助於我更好地了解該領域，所以我想了解為什麼使用它。
- 例如，為什麼將 Person 視為“關係”？在英語中，關係是描述兩個實體如何關聯的名詞。它不指實體本身。在關係數據庫的上下文中，“關係”是指實體本身。為什麼？
- 我知道關係模型是在層次模型和網路模型（例如父、鄰居）之後出現的。但在這些模型中，實體之間也存在關係。那麼為什麼稱這個模型為關係模型呢？有更具體的片語/術語嗎？或者我們應該說這三個模型都是關係模型，但是層次模型和網路模型是關係模型的特定類型？
- 如果我們有彼此不相關的獨立實體怎麼辦。說，人、門和樹。術語“relation(al)”是否仍然適用？
（也許這應該是多個問題。我認為答案是高度相關的 - 也許只有一個答案 - 所以我認為這是一個問題是有道理的。如果我錯了，請告訴我，我’ 將創建單獨的問題。）
編輯：此圖可能有助於視覺化一種關係將不同的域相互關聯：
首先，我強烈推薦Edgar Frank Codd 博士在 1970 年向公眾發表關係框架的科學論文，即A Relational Model of Data for Large Shared Data Banks。在第 1.1 節“簡介”中，Codd 博士本人指出：
本文關注基本關係理論在系統中的應用，這些系統提供對大量格式化數據的共享訪問。
© 電腦協會。ACM 通訊，第 13 卷，第 6 期（第 377-387 頁），1970 年 6 月。
所以，是的，術語關係和（因此）關係來自數學背景。Codd 博士——除了他的學術和研究證書外，在計算和資訊處理方面擁有大約 20 年的第一手經驗——設想在數據管理領域應用關係（自然是抽象結構）的巨大優勢.
我不是數學家，但基本上來說，關係是集合之間的關聯，集合是元素的集合（這個外部資源給出了數學關係的定義，可能有助於從不同的角度理解它）。在 SQL 數據庫管理系統（簡稱 DBMS）的幫助下工作時，一個眾所周知的關係近似是一個表，在這種情況下，關聯發生在其列的**類型之間。顯然，在提供 DOMAIN 支持的 SQL 平台（例如Firebird和PostgreSQL）中，關聯發生在為相關表格的列固定的*域；*有關重要詳細資訊，請參閱以下部分。
在這方面，我將再次引用 Codd 博士，他在第 1.3 節“數據的關係視圖”中斷言：
術語關係在這里以其公認的數學意義使用。給定集合S 1，S 2，⋯ ，S n，（不一定不同），如果它是一組n 個元組，每個元組的第一個元素來自S 1，它的第二個元素， R就是這n 個集合的關係從S 2，依此類推。1我們將S j稱為R的第j個域。如上所定義，R的度數為 n. 1 階關係通常稱為一元、2階二元、3階三元和n 階關係。
1更簡潔地說，R是笛卡爾積S 1 × S 2 × S 3 ⋯ × S n的子集。
© 電腦協會。ACM 通訊，第 13 卷，第 6 期（第 377-387 頁），1970 年 6 月。
我同意其他答案，因為指出 Codd 博士對數學關係進行了一些修改以充分利用它在數據管理方面的作用是非常相關的，並且它們在前面提到的論文中進行了解釋，在他廣泛的參考書目中。
關係與關係**
一個值得提出的情況是，在處理這些主題時，由於關係和關係這兩個術語的日常（非數學、非技術）定義存在相似性，可能會產生混淆——作為非以英語為母語的人，我覺得特別容易理解——。
實體關係視圖和關係模型**
我認為可能引起混淆的其他因素（並且與上面提到的兩個術語的技術內涵密切相關）是，在學習設計數據庫時，通常首先向學生或實踐者介紹Dr. . Peter Pin-Shan Chen在entity-relationship view of data（1976 年發表）中，提出了兩種不同的實現方式（即實體和關係）來描繪一個概念圖式，然後，只有在定義好所述圖式之後是穩定的，學生或從業者在聲明**相關數據庫的邏輯佈局。在參考的概念框架內，關係的含義更接近於這個詞的日常意義。
那麼，也許這種情況也增加了關係和關係的問題——但是首先定義概念圖式，然後聲明相應的邏輯設計的順序當然是非常合適的，我將在下面的部分中詳細說明——。
對您的每個子問題的回答
我認為包含這三個子問題確實很相關，因為它們為文章建立了更廣泛的背景，因此不應忽視它們。這樣，除了專門解決為什麼使用術語關係和關係（這當然非常重要並且是文章的標題，但不是整個文章）之外，所述子問題可以幫助理解更多的範圍當一個人參與整個資訊管理項目時的關係和關係模型（非常相關，因為這是一個關於數據庫管理的站點）並且因此在不同**的抽象級別上工作. 通過這種方式，我將在下面分享我對這些細節的看法。
子問題編號 1
例如，為什麼將 Person 視為“關係”？在英語中，關係是描述兩個實體如何關聯的名詞。它不指實體本身。在關係數據庫的上下文中，“關係”是指實體本身。為什麼？
概念層面
在給定的業務環境中，可以將Person視為一種**實體類型，具體取決於在那里工作的人員（業務專家和數據庫設計人員）如何對其進行概念化。而且，是的，在那個業務環境中，可能存在與Person實體類型相關的不同屬性，例如**Name、BirthDate、Gender等。
此外，Person實體類型可能與自身或其他實體類型持有某些關係（或關聯或連接）類型；例如，Person可能與名為UserProfile的實體類型相關聯，而後者又可能具有自己感興趣的屬性，比如Username和Password。
但是，（a）實體類型，（b）它們的相應屬性，（c）實體類型之間的關係類型和（d）屬性本身之間的關係是“屬於”它們所在的特定業務環境的概念認為具有重要意義。它們是數據庫設計人員使用的設備，與業務專家密切合作，以便在設計階段定義特定於上下文的概念模式。
因此，在概念層面，我們基本上處理現實世界感興趣的部分中出現的想法的結構，即（1）事物原型和（2）事物原型之間關係的原型，我們不使用(3)關係——在數據關係框架的意義上使用最後一個術語——。
邏輯級
在將Person在概念層面精確描述為實體類型之後，如果要實現一個關係數據庫，它可以傳達Person的含義以及與之相關的所有概念，那麼關於該類型實體的事實可以通過以下方式進行管理邏輯級別的數學關係，並利用可以在該抽象結構上執行的基於科學的操作（即定義它、約束它和操縱它）。
是的，在定義數據庫的邏輯排列時，可以將某個關係命名為Person，但這並沒有將Person的“現實世界”概念轉換為關係，因為在管理資訊時獲得的好處，可以這樣處理它關於它，例如，對其應用關係代數運算以導出新關係（因此正在導出“新”資訊）。考慮到某種類型的實體組成一個集合，並且某個屬性的值也組成一個集合這一事實，上述好處變得更加明顯。
而且，是的，正如前面段落和其他答案中所提到的，關係的最重要方面之一是其域之間存在的連接——通常用於表示實體或關聯類型的屬性，它們是一個概念圖式——。例如，假設我們聲明了以下（三元）關係：
Salary (*PersonNumber*, *EffectiveDate*, Amount)…讓我們假設，在所討論的業務環境中，元組——（i）代表一個特定的實體，即來自適用概念模式的實體類型的實例，以及（ii）其 SQL 對應項是行——
Salary (x, y, z)……會帶有意義
x“在 EffectiveDate支付給 PersonNumber 標識的人的薪水對應於”y的金額z。因此——以近似的方式描述事物——三個領域之間的聯繫是最重要的，它們都是相關的（而且，是的，一元關係只涉及一個領域）。某個域的所有值之間的聯繫也非常重要，因為它們構成了一**組精確的類型。此外，關係的每個元組的內容
Salary必須符合上述斷言的結構。概念級關係和邏輯級關係**
正如所展示的，我現在處理了兩個不同抽象級別的數據庫管理，即概念和邏輯——還有一個稱為物理的較低級別，在 SQL DBMS 中通常涉及索引、頁面、範圍、等等。-。
因此，根據前面解釋的概念，在邏輯層面上，人們只使用 (a) 數學關係，其中 (b)概念關係或關聯由(c)這種數學關係的元組中包含的值表示，並且這些值通常通過 FOREIGN KEY 約束來分隔，以便它們能夠準確地表示適用的關係。
而且，是的，關聯實體，即具有多對多 (M:N) 基數比的關係類型的實例，可以通過單個數學關係的元組來傳達 - 並適當聲明相應的約束，課程-。
子問題編號 2
我知道關係模型是在層次模型和網路模型之後出現的。但在這些模型中，實體之間也存在關係。那麼為什麼稱這個模型為關係模型呢？有更具體的片語/術語嗎？或者我們應該說這三個模型都是關係模型，但是層次模型和網路模型是關係模型的特定類型？
網路和分層 DBMS 早於其正式的理論支持
值得指出的是，圍繞分層和網路方法的理論支持實際上是根據先前存在的DBMS 創建的，除其他方面外，目的是測試和確定 (1) 所述類型的可靠性軟體和 (2) 關聯的數據管理實踐——在我看來，這是一種顛倒的現象——。
與關係框架相比不完整
話雖如此，儘管在關係模型之前就有分層和網路 DBMS，即使 Codd 博士將這些方法中的每一種都稱為“模型”，但沒有一個與關係框架的定義方式相同。關係範式為 (i) 定義、(ii) 限制和 (iii) 數據操作提供了科學構造，而分層和網路方法缺乏完整的理論支持來涵蓋前面提到的所有三種構造。
網路和分層特徵
此外，如前所述，實體和關係類型是概念級別的設備，它們不屬於分層或網路方法，每種方法都提供了表示所述方面的特定機制：
- 網路範式需要兩種用於數據表示的設備，即節點和弧（並且該特徵當然意味著兩種不同類型的數據操作操作），與關係模型（根據資訊原理）僅需要一個構造相比（關係）表明以網路方式工作所涉及的不必要的複雜性。例如，鑑於它採用兩種表示工具，網路方法會施加不切實際的查詢偏差，從而阻礙數據操作。
- 就其本身而言，分層視圖建議通過（物理！）文件表示數據，這些文件由以三類排列組織的記錄（又由欄位組成）組成；即，一個父記錄通過**指針與可能的許多子對應項鍊接在一起，這會產生關於數據操作的物理*訪問路徑。*這種方法也是不利的，因為它提出了概念和物理方面的糾纏，因此物理儲存安排的變化需要重新組織資料結構，這反過來又需要改變相關的數據操作操作。
如圖所示，分層視圖和網路視圖將它們的構造強加於要管理的數據，而關係模型建議通過關聯事實集（其中n種後續類型的集合，預計在設計階段，可以推導出來等等！）。
關係模型沒有子模型
而且，非常重要的是，層次視圖和網路視圖**都不是特定類型的關係模型，它們只是人們可能遵循的其他範式（a）建構 DBMS 和（b）創建數據庫，但請記住，層次結構幾十年來，網路方法被認為已經過時。
子問題編號 3
如果我們有彼此不相關的獨立實體怎麼辦。說，人、門和樹。術語“relation(al)”是否仍然適用？
是的，如果（1）通過適應的數學關係管理有關這些實體類型的資訊，並且（2）在給定關係 DBMS 的支持下管理的某個數據庫中的邏輯級別執行適用的關係操作，則它是完全適用的.
在概念級別上，所述實體類型是否與其他實體類型沒有關係類型並不重要（值得注意的是，實體類型可以具有一對零一或多基數比的關係與自身），因此沒有傳達或執行所考慮的關係的元組的值之間的任何關係。