課堂

2.1. 概念設計 數據庫設計分三個階段進行： 概念設計; 邏輯設計； 物理設計。 概念設計階段的目的是根據用戶對主題領域的想法創建概念數據模型。為了實現它，執行了一系列順序程序。實體（概念）模式的示例： 1. 實體及其文檔的定義。為了識別實體，定義了獨立於其他對象存在的對象。這些對像是實體。每個實體都被賦予了一個用戶可以理解的有意義的名稱。實體的名稱和描述被輸入到數據字典中。如果可能，設置每個實體的預期實例數。 2. 確定實體及其文檔之間的關係。只定義滿足數據庫設計要求所必

3.1 數據庫規範化 範式是關係數據模型中關係的一種屬性，它在冗餘方面對其進行了表徵，可能導致採樣或更改數據的邏輯錯誤結果。範式被定義為關係（數據庫中的表）必須滿足的一組要求。 將數據庫關係轉換為符合規範形式的形式的過程稱為規範化。規範化旨在使數據庫的結構成為提供最小邏輯冗餘的形式，而不是為了降低或提高性能，或者減少或增加數據庫的物理量。 規範化的最終目標是減少存儲在數據庫中的信息的潛在不一致性。歸一化過程的一般目的如下： 排除某些類型的冗餘； 修復一些更新異常； 開發一個足

4.1 簡介 通過將數據庫表轉換為常規表，您現在可以分析它們之間的關係。兩個相關表之間交互的元素數稱為基數。基數可幫助您控制將數據分區到表中的效率。 從理論上講，所有實體之間都可以保持相互關係，但在實踐中，實體之間存在三種類型的關係： 一對一 一對多 多對多 4.2 一對一溝通 如果對於實體 B 的每個實例只有一個實體 A 的實例，則稱它們具有一對一的關係（通常表示為“1:1”）。在 ER 圖上，這種關係由兩端各有一個小條的線表示： 1:1 關係通常表示，除非您有充分的理由將

5.1 簡介 Internet 上充斥著關於應如何在關係數據庫中選擇和使用鍵的教條式規則。有時爭論甚至會演化為 holivars：應該使用自然密鑰還是人工密鑰？自動遞增整數或 UUID？ 在閱讀了 64 篇文章，翻閱了 5 本書的章節，並在 IRC 和 StackOverflow 上提出了大量問題之後，我（Joe “begriffs” Nelson，原文章的作者）似乎已經把拼圖的各個部分放在一起並且現在可以調和對手。很多關鍵性的爭論其實都是因為誤解了別人的觀點而產生的。 讓我

6.1 簡介 現在讓我們從理論轉向實踐。 “從理論上講，理論和實踐之間沒有區別。實際上，他們是。” 我們生活在現實世界中，所有的軟件產品最終都是為活著的人創造的。這些活著的人對加載緩慢的網站和運行緩慢的程序感到非常惱火。 而如果一個數據庫查詢花費的時間超過一秒，這是不可接受的。用戶根本不會使用頁面/功能如此緩慢的產品。 但通常，為了顯示一個頁面，您需要對數據庫執行幾十次查詢。如果它們是按順序執行的，那麼您將不再有第二個限制，但假設每個請求 100 毫秒。 以下是程序員加速數據

7.1 DB端緩存 MySQL 在處理表時使用高度可擴展的算法，因此即使使用少量內存也可以運行 MySQL。當然，為了獲得更好的性能，您需要更多的 RAM。 要查看當前設置，請連接到數據庫

8.1 為什麼需要反規範化？ 大表之間計算量最大的操作是連接。因此，如果在一個查詢中需要“通風”幾個由數百萬行組成的表，那麼 DBMS 將花費大量時間進行此類處理。 此時用戶可以移開去喝咖啡。處理的交互性幾乎消失，接近批處理的交互性。更糟糕的是，在批處理模式下，用戶在早上收到前一天請求的所有數據，並冷靜地處理它們，為晚上準備新的請求。 為了避免大量連接的情況，表被非規範化。但無論如何都不是。有一些規則允許您根據為數據倉庫構建表的規則將事務非規範化表視為“規範化”。 在分析處理

1.1 簡介 現在樂趣開始了——交易如何運作的理論。當您在不同線程中更改相同數據時，如何保持系統正常工作？或者您想在另一筆交易中執行一筆交易？我們將開始通過研究事務的隔離性來尋找這些問題的答案…… 事務隔離級別是一個條件值，它決定了由於 DBMS 中邏輯並行事務的執行，允許不一致數據的程度。事務隔離級別的規模包含許多值，從低到高排列；更高的隔離級別對應於更好的數據一致性，但它的使用可能會減少物理上並行事務的數量。 相反，較低的隔離級別允許更多並行事務，但會降低數據準確性。因此

2.1 讀未提交 “事務隔離級別”是指DBMS內部機制（即不需要特殊編程）對事務並行執行時出現的上述所有或部分類型的數據不一致的保護程度。SQL-92 標准定義了四個隔離級別的範圍： 讀取未提交 讀提交 可重複讀 可序列化 第一個是最弱的，最後一個是最強的，後面的每一個都包含了前面的所有。 最低（第一）隔離級別。如果多個並行事務試圖修改同一個表行，那麼最後一行的值將由整個成功完成的事務集決定。在這種情況下，不僅可以讀取邏輯上不一致的數據，還可以讀取尚未記錄更改的數據。 實現此

3.1 酸的出現 縮寫詞 ACID於 1983 年首次出現在 Theo Haerder 和 Andreas Reuter 的一篇文章中。為了簡化文字並使其更具說服力，我將對本文的一個片段進行翻譯（略有刪減）。此代碼段使用銀行交易示例，其中資金從一個帳戶轉移到另一個帳戶。 事務的概念，在示例中包括$BEGIN_TRANSACTION和之間與數據庫的所有交互$COMMIT_TRANSACTION，要求所有操作不可分割地執行：要么所有操作都正確反映在數據庫狀態中，要么什麼都不發生。

4.1 關於 Brewera 的一致性 首先，Eric Brewer 不是，也從未聲稱自己是數據庫專家。他屬於分佈式系統社區，他在“分佈式計算原理”會議上發表了著名的演講，其中出現了 CAP“定理”。（順便說一下，十年後的 2010 年，他再次在同一個會議上作了受邀演講，在這次演講中，他特別給出了一些分佈式系統的例子，其發展考慮到了“定理”的 CAP。）在這方面對數據庫領域中使用的術語有自己的解釋。 特別地，術語“立即一致性”是指在用戶收到系統關於某個數據更新操作成功完成的通

5.1 同時性問題 讓我們從一個遙遠的理論開始。 程序員創建的任何信息系統（或簡單地說，一個應用程序）都由幾個典型的塊組成，每個塊都提供一部分必要的功能。例如，緩存用於記住資源密集型操作的結果以確保客戶端更快地讀取數據，流處理工具允許您將消息發送給其他組件進行異步處理，批處理工具用於“以一定的周期性“耙”累積的數據量。 . 在幾乎每個應用程序中，數據庫 (DB) 都以一種或另一種方式涉及，它們通常執行兩個功能：從您那裡收到數據時存儲數據，然後根據請求提供給您。很少有人會想到創