書圖的關系模式

Question

我制作了下圖來顯示與它們有關系的書籍和人物：

有兩個節點：

• 人
• 書

和三個關系（及其屬性，圖中未顯示）：

• 閱讀（日期，num_stars）
• 寫（日期）
• 已審核（日期、num_stars、text_review）

如果這要在關系數據庫中建模，架構會是什么樣子？ 我的想法是打破每一個關系和節點，比如：

節點人

• 個人ID
• 姓名

節點書

• 書號
• 標題

邊讀

• FromPersonID
• ToBookID
• 日期
• num_stars

邊寫

• FromPersonID
• ToBookID
• 日期

邊緣評論

• FromPersonID
• ToBookID
• 日期
• num_stars
• text_review

或者，所有節點都應該是一個表嗎？ 如果我們要添加 Movies 作為另一個節點，我們將如何顯示 Review 邊緣可能來自 Person->Book 或 Person->Movie 的 go。 似乎更通用的方法可能是：

節點：

• ID
• 類型
• // 來自特定 Edge 表的 FK

邊緣：

• 發件人ID
• ToID
• 類型
• // 來自特定 Edge 表的 FK

改用這種后一種方法有什么缺點嗎？

Answer 1

1 上下文

注意relational-database標簽。

首先，我們需要了解這個問題存在的整個背景，包括各種可用的方法； 每個人的能力； 和限制（如果有）。 之后，很容易理解解決方案。 在關系范式中只有一個正確的解決方案。

1.1 前關系

在 Codd 產生他的關系 Model (1970) 之前，已經有 20 年非常好的 DBMS。 此外，供應商花了 10 多年的時間才生產出真正的 RDBMS（1981 年）。 在那些日子里，計算機和軟件很昂貴，而且是專有的。

• 初始訪問是通過密鑰（在分層 DBMS 中改進的 ISAM；在網絡 DBMS 中散列）
• 關系被實現為指針
  這導致了維護問題，並且導出/導入需要一個程序
• 在分層 DBMS 中，它是一棵真正的樹（有向無環圖）
• 在網絡 DBMS 中具有更大的靈活性，可以實現樹或網絡。

雖然鍵是合乎邏輯的，但指針當然是物理的。 系統因此受到限制。

出於對科學（邏輯；理智）的熱愛，沒有實現循環引用（循環圖）。 換句話說，只有真實的層次結構（有向無環圖；樹），因為它們存在於現實世界或人造世界中的邏輯，被實施。

1.2 關系型 Model

第一個基於或建立在邏輯上的，具有數學定義的，這使得它被稱為Model 。 它改變了 DBMS 的世界。 與此問題相關的主要區別是：

• 由於數學定義
  • 因此它是 100% 邏輯的（即它是從物理 SQL 實現中刪除的一個抽象級別）
  • 沒有什么是無法定義的
    既然世界已經瘋了，我必須添加限定詞：自然宇宙中的任何事物和任何合乎邏輯的人造事物，都可以被定義。 任何不合邏輯的事情都是瘋狂的
• 關系被實現為鍵
  消除了維護難題，並提供了輕松的導入/導出

1.3 反關系

EF Codd 博士是一名工程師，他與科學家一起為 IBM 工作。 同樣，其他 DBMS 供應商也有科學家和工程師。

學術界討厭 Codd 和IDEF1X ，因為它們完全脫離現實，完全與行業和 DBMS 供應商隔絕。 他們使用和撰寫只有學者炮制的東西。 那時，一直到現在：

• 他們否認 SQL 兼容平台的現實，並培養了一種不兼容甚至不是語言的“sql”；

• 他們抑制了IDEF1X，而是培養了對建模毫無希望的ERD，並且無法處理關系鍵（復合）並且不能用於任何類型的建模

• 他們討厭科德和像我這樣的從業者，因為我們不是學者，我們是現實主義者

• 他們壓制了邏輯關系 Model ，並推廣了 1960 年代（DBMS 之前）的物理記錄歸檔系統，欺詐性地宣傳為“關系”。 這些以RecordIDs （物理記錄，而不是邏輯行）為特征。

  • 請注意，這樣的 RFS 是原始的，非常有限。 它們被放置在 SQL 容器中，以便於訪問 (DML) 和方便（備份等）。 這種限制被錯誤地歸因於 SQL，但實際上是由於原始 RFS。
  • RecordIDs不提供RM中要求的行唯一性，以防止重復數據。 （它們確實提供RecordID唯一性，這完全無關緊要，更糟糕的是，您可能認為您已經防止了數據重復，而實際上您沒有
  • 此外， RecordIDs總是一個額外的非數據字段，並且比關系等價物多一個額外的索引。
  • 由於RM中的訪問路徑獨立規則失敗，它們會強制執行更多的JOINs 。

• 有關討論，請參閱：
  僅使用 2 個不同的 auto_increment §1 和 2 創建關系表。

因此，由於對RM的無知，他們提出了愚蠢的主張，例如“ RM不能做這個或那個”，這對他們的“RM”來說是正確的，但對於 Codd 的RM來說是完全錯誤的。

1.4 SQL 與“SQL”

同樣，Codd 定義了一種單一的數據子語言，並且主要供應商（不包括 Oracle）實現了它。 那是真正的 SQL，它被制定為 ANSI->ISO/IEC 標准。 有一篇著名的論文Codd’s Twelve Rules for compliance with his data sub-language，各大廠商都遵守，免費軟件甚至都沒有接近。

免費軟件和 Oracle 不符合 SQL，他們使用 SQL 一詞是欺詐性的。 Postgres 和 Oracle 中的實現甚至不是一種語言。

因此，再次由於對RM和SQL的無知； 他們與現實和行業隔離開來； 以及他們對私有“RM”和“SQL”的執着，他們做出愚蠢的聲明，例如“SQL 不能做這個或那個”，這對他們的“SQL”和他們的“RM”來說是正確的，但對於他們的“RM”來說是歇斯底里的錯誤。真正的RM和 SQL。

這導致世界上 95% 的數據庫被標記為“關系型”，但它們根本不是關系型的，它們不提供關系型 Model的任何功能和優點。 當然，它不會按預期工作。 因此，從關系（實際上是“關系”）轉向各種非關系“數據庫”。

該塊最新的孩子是“圖形數據庫”，它根本不是數據庫（沒有完整性，沒有標准），但它們確實提供了“關系”或“SQL”據稱無法提供的功能或 function。 同時，實際上，在 Codd 的關系型 Model和真正的 SQL 中，沒有什么是無法定義的，並且數據層次結構（DAG；圖表；樹）易於設計和實現。

值得注意的是，IBM 專門委托 Codd 解決的一個問題是他們的 HDBMS 中的一個特定問題，該問題涉及著名的物料清單問題，他確實解決了這個問題並且非常出色。 即RM完全支持各種dat層次結構，普通【正版】SQL可以用來導航。

1.5 開發者作為建模者

三個問題是典型的。

首先，理解上面的上下文，這樣你就會明白你已經被反關系的廢話轟炸了，這些廢話不能將各種邏輯數據結構（例如圖形）處理為“關系”，並且關系和 SQL 可以很好地處理所有這些結構。

• 因此，我將以關系術語為您的問題提供相當簡單的解決方案，並且通過真正的 SQL 易於使用。 您需要了解，圖形數據庫可以做任何RM不能做的事情，或者它在任何方面都優越的概念是錯誤的。

第二個問題是常見的開發人員心態，他們專注於他們的 GUI； 皮膚，以及他們對數據的需求。 （我知道我需要什么，以及 GUI 的樣子）這很容易，因為學者們建議他們根據 Excel 電子表格（可怕的RecordIDs ）來思考。 確切地說，而不是數據是什么。

• 這削弱了建模練習。 Genuine Data Modeling（Relational or not），是一門學問，有model的數據，而且只有數據，不考慮使用（用例）。
• 而每次發布時使用情況都會發生變化，並且在添加計划外使用時會發生巨大變化
• 而數據的結構沒有改變（如果建模正確，反映了從中提取數據的真實世界）。

第三，可能最重要的是，分析和建模數據的科學和方法與分析的科學和方法非常不同。 設計； 和建模過程。 不幸的是，如今的開發人員被 OO/ORM 迷住了，因為完全錯誤的觀念是，宇宙中的一切都可以通過 Object 的鏡頭來感知和理解。

• 他們將“數據庫”視為存儲奴隸，其唯一目的是為他們的神奇對象提供持久性，更不用說重構和 CRUD。
• “數據庫”在邏輯上是在app內部，只能通過app才能訪問，而且有很大的好處，比如持久性； 開放存取； 開放式架構等丟失了； 未知。

2 解決方案 • 關系型 Model

2.1 問題

現在我們有了上面的上下文和解釋，我們可以考慮您提供的圖表。 請注意，這是一張圖片，而不是任何類型的 model，它專注於、描述了一些示例數據以及該示例數據之間的一些可能關系。 還有一張好看的圖。

• 但它只是 output（用例）的完整細節，以圖形形式呈現。 它不是圖（DAG；樹）。 如果由於視覺原因，人們認為它包含循環引用（數據實際上不包含循環引用），則可能會被原諒。 同樣，過多地關注用例，以犧牲理解數據和對其建模（以及對其建模而不是作為 1960 年代的記錄歸檔系統）為代價。

---

如果這要在關系數據庫中建模，架構會是什么樣子？

因此，我會要求您釋放所有關於以下內容的概念：

• 物理RecordIDs （謹防反關系欺詐性地冒充“關系”），
• 用例心態（你需要什么，而不是數據獨立於你需要什么），
• 圖形和圖形“數據庫”，包括該術語，尤其是一些數據樣本的出色圖表（數據的圖形報告）
• 您可能擁有的任何 OO/ORM 心態，以便您能夠有效地理解普通的關系術語和概念。 另有說明，上述任何附件都會使數據 model 和數據庫變得模糊。

這是純粹的關系。 它可以在任何真正的 SQL 平台（不包括免費軟件和 Oracle）中實施，並且可以毫不費力地工作。 任何和所有報告都將通過單個SELECT提供。 順序跟隨你的問題。

---

如果這要在關系數據庫中建模，架構會是什么樣子？ 我的想法是打破每一個關系和節點，比如：

是的。 忽略小錯誤，這就是 Normalization 的樣子。

我們可以刪除以圖形為中心的名稱，因為數據庫旨在反映現實，而不是許多可能的用途之一就是從中生成圖形。 它可用於從數據中提供任何報告，而不僅僅是圖表。

2.2 關系數據 Model • 初始

關系數據建模的第一次迭代，在 IDEF1X 中給出。

• IDEF1X 簡介是必不可少的閱讀材料。

---

或者，所有節點都應該是一個表嗎？

不，那將是一個平面文件，完全未標准化。 實施的怪物； 維持; 和SELECT來自。 它沒有聲明性引用完整性，因此它不符合數據庫的條件，更不用說關系數據庫了。

---

如果我們要添加 Movies 作為另一個節點，我們將如何顯示 Review 邊緣可能來自 Person->Book 或 Person->Movie 的 go。

忘記“邊緣”，它只是多種可能的顯示類型之一，而專注於數據和關系，它支持任何類型的顯示。

每一個（ Person; Book; Movie ）都是一個單獨的、離散的事實（“節點”），每個箭頭都是一個單獨的、離散的關系，具有明確的動詞短語。

您已經添加了 Movie 實體，這需要大量額外的建模。 用於定義Book或Movie的Item的普通 pre-Relational（60 年代和 70 年代）和 Relational（80 年代）方法是子類型集群。

• 解釋：參考子類型文檔
• 討論：參考：
  構建數據庫關系以跟蹤應用程序設置的不同變化，以及
  如何解決這種關系數據庫設計的味道？

---

似乎更通用的方法可能是：...

你的屬性不完整。 當您添加相關屬性時，您最終會得到兩個未標准化的文件，其中包含可為空的字段。 與數據庫截然相反，通常是維護和使用的噩夢。

從物種轉移到屬不是一個非黑即白的決定，認為它“總是好的”是一個嚴重的錯誤。 關系型 Model ，特別是正確的子類型，實現了屬（基本類型）和物種（子類型），因此可以無限使用。

改用這種后一種方法有什么缺點嗎？

是的。 違背科學或涵蓋某個主題的標准總是有可怕的缺點。 列舉幾個：

• 聲明性引用完整性（ FOREIGN KEY ）是不可能的，因此數據沒有完整性
• 非常復雜的 SQL，用於維護數據的事務以及用於提取和顯示數據的報告
• 由於“數據庫”在邏輯上不可訪問，“數據庫”用戶將轉變為刺客
• 早禿是有保障的
• 也保證完全替換“數據庫”和應用程序代碼。

2.3 關系數據 Model • 進展

試試這個，這是我們建模練習中的第二次迭代。 我已經實現了以下規則（隨意更改或添加更多規則，我將更新數據模型）：

• Subtype 集群是 Non-Exclusive，這意味着Item要么是Book ，要么是Movie ，或兩者兼而有之
• %Reviewer必須首先是Reader/Viewer
• Author.Sequence是唯一的，即。 兩位Authors不能共享“第二名”
  • 或者，可以添加一個CONSTRAINT以確保增量Sequence ，在這種情況下可以刪除AK

• PDF 中的數據model

• 如果您在顯示數據庫中的數據時遇到任何困難，以任何報告或圖表的形式，使用標准 SQL，請指出，我將提供 SQL。

• 請隨時提出問題，或提供您的要求的進一步定義。