DBMS - 快速指南



DBMS - 概述

資料庫是相關資料的集合,資料是事實和數字的集合,可以對其進行處理以產生資訊。

大多數資料表示可記錄的事實。資料有助於產生資訊,資訊基於事實。例如,如果我們有所有學生獲得的分數資料,我們就可以得出關於尖子生和平均分數的結論。

資料庫管理系統以一種更容易檢索、操作和生成資訊的方式儲存資料。

特徵

傳統上,資料以檔案格式組織。DBMS 當時是一個新概念,所有研究都致力於使其克服傳統資料管理方式的不足。現代 DBMS 具有以下特徵:

  • 現實世界實體- 現代 DBMS 更貼近現實,並使用現實世界實體來設計其架構。它也使用行為和屬性。例如,學校資料庫可以使用學生作為實體,並將他們的年齡作為屬性。

  • 基於關係的表格- DBMS 允許實體以及它們之間的關係形成表格。使用者只需查看錶名即可瞭解資料庫的架構。

  • 資料和應用程式的隔離- 資料庫系統與其資料完全不同。資料庫是一個活動實體,而資料被認為是被動實體,資料庫對其進行操作和組織。DBMS 還儲存元資料(即關於資料的資料),以簡化其自身的過程。

  • 冗餘度低- DBMS 遵循規範化規則,當任何屬性的值存在冗餘時,就會拆分關係。規範化是一個數學上豐富且科學的過程,可以減少資料冗餘。

  • 一致性- 一致性是指資料庫中每個關係保持一致的狀態。存在可以檢測到資料庫處於不一致狀態的嘗試的方法和技術。與早期的資料儲存應用程式(如檔案處理系統)相比,DBMS 可以提供更高的一致性。

  • 查詢語言- DBMS 配備了查詢語言,這使得檢索和操作資料更加高效。使用者可以根據需要應用任意數量和任意不同的過濾選項來檢索一組資料。傳統上,在使用檔案處理系統的地方這是不可能的。

  • ACID 屬性- DBMS 遵循原子性一致性隔離性永續性的概念(通常縮寫為 ACID)。這些概念應用於操作資料庫中資料的交易。ACID 屬性有助於資料庫在多事務環境中以及在發生故障時保持健康。

  • 多使用者和併發訪問- DBMS 支援多使用者環境,並允許他們並行訪問和操作資料。儘管當用戶嘗試處理相同的資料項時,對事務有一些限制,但使用者始終沒有意識到這些限制。

  • 多檢視- DBMS 為不同的使用者提供多個檢視。銷售部門的使用者對資料庫的檢視將與生產部門的工作人員不同。此功能使使用者能夠根據自己的需求獲得資料庫的集中檢視。

  • 安全性- 多檢視等功能在一定程度上提供了安全性,使用者無法訪問其他使用者和部門的資料。DBMS 提供了在將資料輸入資料庫和稍後檢索資料時強制約束的方法。DBMS 提供了許多不同級別的安全功能,這使得多個使用者可以擁有具有不同功能的不同檢視。例如,銷售部門的使用者無法檢視屬於採購部門的資料。此外,還可以管理應向用戶顯示多少銷售部門的資料。由於 DBMS 不是像傳統檔案系統那樣儲存在磁碟上,因此不法分子很難破解程式碼。

使用者

典型的 DBMS 具有具有不同許可權和許可的使用者,他們出於不同的目的使用它。一些使用者檢索資料,一些使用者備份資料。DBMS 的使用者可以大致分為以下幾類:

  • 管理員- 管理員維護 DBMS,並負責管理資料庫。他們負責檢視其使用情況以及誰應該使用它。他們為使用者建立訪問配置檔案並應用限制以維護隔離並強制執行安全性。管理員還負責 DBMS 資源,例如系統許可證、所需工具以及其他與軟體和硬體相關的維護。

  • 設計人員- 設計人員是實際負責資料庫設計工作的人員。他們密切關注應該儲存哪些資料以及以何種格式儲存。他們識別和設計實體、關係、約束和檢視的整個集合。

  • 終端使用者- 終端使用者是實際受益於 DBMS 的使用者。終端使用者可以從簡單地關注日誌或市場價格的檢視者到複雜的商業分析師不等。

DBMS - 架構

DBMS 的設計取決於其架構。它可以是集中式、分散式或分層式。DBMS 的架構可以視為單層或多層。n 層架構將整個系統劃分為相關的但獨立的n個模組,這些模組可以獨立地修改、更改或替換。

在 1 層架構中,DBMS 是唯一的實體,使用者直接坐在 DBMS 上並使用它。此處進行的任何更改都將直接在 DBMS 本身上進行。它沒有為終端使用者提供方便的工具。資料庫設計人員和程式設計師通常更喜歡使用單層架構。

如果 DBMS 的架構是 2 層,則它必須有一個應用程式,透過該應用程式可以訪問 DBMS。程式設計師在使用 2 層架構時,透過應用程式訪問 DBMS。在此,應用程式層在操作、設計和程式設計方面完全獨立於資料庫。

3 層架構

3 層架構根據使用者的複雜性和他們如何使用資料庫中存在的資料,將各層彼此分離。它是設計 DBMS 時使用最廣泛的架構。

  • 資料庫(資料)層- 在此層,資料庫及其查詢處理語言駐留。我們還在此級別擁有定義資料及其約束的關係。

  • 應用程式(中間)層- 在此層駐留應用程式伺服器和訪問資料庫的程式。對於使用者而言,此應用程式層提供了資料庫的抽象檢視。終端使用者不知道資料庫在應用程式之外的存在。另一方面,資料庫層不知道應用程式之外的任何其他使用者。因此,應用程式層位於中間,充當終端使用者和資料庫之間的中介。

  • 使用者(表示)層- 終端使用者在此層上操作,他們不知道資料庫在此層之外的存在。在此層,應用程式可以提供資料庫的多個檢視。所有檢視均由駐留在應用程式層的應用程式生成。

多層資料庫架構具有很強的可修改性,因為幾乎所有元件都是獨立的,可以獨立更改。

DBMS - 資料模型

資料模型定義了資料庫的邏輯結構是如何建模的。資料模型是引入 DBMS 抽象的基本實體。資料模型定義了資料如何相互連線以及如何在系統內部處理和儲存。

第一個資料模型可能是平面資料模型,其中所有使用的資料都儲存在同一平面上。早期的資料模型不夠科學,因此容易引入大量重複和更新異常。

實體關係模型

實體關係 (ER) 模型基於現實世界實體及其之間關係的概念。在將現實世界場景轉化為資料庫模型時,ER 模型會建立實體集、關係集、一般屬性和約束。

ER 模型最適合用於資料庫的概念設計。

ER 模型基於:

  • 實體及其屬性

  • 實體之間的關係

下面解釋這些概念。

  • 實體- ER 模型中的實體是具有稱為屬性的屬性的現實世界實體。每個屬性都由其稱為的值集定義。例如,在學校資料庫中,學生被視為實體。學生具有各種屬性,例如姓名、年齡、班級等。

  • 關係- 實體之間的邏輯關聯稱為關係。關係以各種方式對映到實體。對映基數定義了兩個實體之間的關聯數量。

    對映基數:

    • 一對一
    • 一對多
    • 多對一
    • 多對多

關係模型

DBMS 中最流行的資料模型是關係模型。它比其他模型更科學。此模型基於一階謂詞邏輯,並將表定義為n 元關係

Relational Model Table

此模型的主要亮點包括:

  • 資料儲存在稱為關係的表中。
  • 關係可以被規範化。
  • 在規範化的關係中,儲存的值是原子值。
  • 關係中的每一行都包含唯一的值。
  • 關係中的每一列都包含來自同一域的值。

DBMS - 資料模式

資料庫模式

資料庫模式是表示整個資料庫邏輯檢視的骨架結構。它定義了資料如何組織以及它們之間關係是如何關聯的。它制定了要應用於資料的所有約束。

資料庫模式定義了它的實體以及它們之間的關係。它包含資料庫的描述性細節,可以透過模式圖來描述。它是資料庫設計人員設計模式來幫助程式設計師理解資料庫並使其發揮作用。

資料庫模式可以大致分為兩類:

  • 物理資料庫模式 - 此模式涉及資料的實際儲存及其儲存形式,例如檔案、索引等。它定義了資料將如何儲存在輔助儲存器中。

  • 邏輯資料庫模式 - 此模式定義了需要應用於儲存資料的全部邏輯約束。它定義了表、檢視和完整性約束。

資料庫例項

區分這兩個術語非常重要。資料庫模式是資料庫的骨架。它是在資料庫根本不存在時設計的。一旦資料庫開始執行,對其進行任何更改都非常困難。資料庫模式不包含任何資料或資訊。

資料庫例項是在任何給定時間包含資料的正在執行的資料庫的狀態。它包含資料庫的快照。資料庫例項往往會隨著時間而改變。DBMS 透過勤奮地遵循資料庫設計人員施加的所有驗證、約束和條件,確保其每個例項(狀態)都處於有效狀態。

DBMS - 資料獨立性

如果資料庫系統不是多層級的,那麼在資料庫系統中進行任何更改都會變得困難。正如我們前面瞭解到的,資料庫系統是多層級設計的。

資料獨立性

資料庫系統通常除了使用者資料外還包含大量資料。例如,它儲存有關資料的資料,稱為元資料,以便輕鬆定位和檢索資料。一旦元資料儲存在資料庫中,修改或更新它就相當困難。但是隨著 DBMS 的擴充套件,它需要隨著時間的推移而改變以滿足使用者的需求。如果所有資料都存在依賴關係,那麼這將成為一項繁瑣且極其複雜的工作。

Data independence

元資料本身遵循分層架構,因此當我們在一個層級更改資料時,它不會影響另一個層級的資料。這些資料是獨立的,但彼此對映。

邏輯資料獨立性

邏輯資料是關於資料庫的資料,也就是說,它儲存有關資料如何在內部管理的資訊。例如,儲存在資料庫中的表(關係)及其應用於該關係的所有約束。

邏輯資料獨立性是一種機制,它使自身從磁碟上實際儲存的資料中解放出來。如果我們對錶格式進行一些更改,它不應該更改駐留在磁碟上的資料。

物理資料獨立性

所有模式都是邏輯的,實際資料以位格式儲存在磁碟上。物理資料獨立性是在不影響模式或邏輯資料的情況下更改物理資料的能力。

例如,如果我們想更改或升級儲存系統本身——假設我們想用 SSD 替換硬碟——它不應該對邏輯資料或模式有任何影響。

ER 模型 - 基本概念

ER 模型定義了資料庫的概念檢視。它圍繞現實世界中的實體及其之間的關聯。在檢視級別,ER 模型被認為是設計資料庫的良好選擇。

實體

實體可以是現實世界中的物件,無論是生物還是非生物,都可以輕鬆識別。例如,在學校資料庫中,學生、教師、班級和提供的課程可以被視為實體。所有這些實體都具有一些屬性或特性,這些屬性或特性賦予了它們身份。

實體集是相同型別實體的集合。實體集可能包含具有共享相似值的屬性的實體。例如,一個學生集可能包含一所學校的所有學生;同樣,一個教師集可能包含一所學校來自所有院系的所有教師。實體集不必是不相交的。

屬性

實體透過其稱為屬性的特性來表示。所有屬性都有值。例如,學生實體可能具有姓名、班級和年齡作為屬性。

存在可以分配給屬性的值域或範圍。例如,學生的姓名不能是數字值。它必須是字母的。學生的年齡不能為負數,等等。

屬性型別

  • 簡單屬性 - 簡單屬性是原子值,不能進一步細分。例如,學生的電話號碼是 10 位的原子值。

  • 複合屬性 - 複合屬性由多個簡單屬性組成。例如,學生的完整姓名可能包含 first_name 和 last_name。

  • 派生屬性 - 派生屬性是不存在於物理資料庫中的屬性,但其值是從資料庫中存在的其他屬性派生的。例如,部門的 average_salary 不應直接儲存在資料庫中,而是可以派生出來。再舉一個例子,年齡可以從 data_of_birth 派生出來。

  • 單值屬性 - 單值屬性包含單個值。例如 - Social_Security_Number。

  • 多值屬性 - 多值屬性可能包含多個值。例如,一個人可以擁有多個電話號碼、電子郵件地址等。

這些屬性型別可以以如下方式組合:

  • 簡單單值屬性
  • 簡單多值屬性
  • 複合單值屬性
  • 複合多值屬性

實體集和鍵

鍵是唯一標識實體集中實體的屬性或屬性集合。

例如,學生的 roll_number 使他/她能夠在學生中被識別。

  • 超鍵 - 一組(一個或多個)屬性,它們共同標識實體集中的一個實體。

  • 候選鍵 - 最小的超鍵稱為候選鍵。實體集可能有多個候選鍵。

  • 主鍵 - 主鍵是資料庫設計人員選擇用於唯一標識實體集的候選鍵之一。

關係

實體之間的關聯稱為關係。例如,員工部門工作,學生註冊課程。這裡,Works_at 和 Enrolls 被稱為關係。

關係集

一組相同型別的關係稱為關係集。與實體一樣,關係也可以具有屬性。這些屬性稱為描述性屬性

關係度

關係中參與實體的數量定義了關係的度。

  • 二元 = 度 2
  • 三元 = 度 3
  • n 元 = 度

對映基數

基數定義了一個實體集中實體的數量,可以透過關係集與另一個實體集中的實體數量相關聯。

  • 一對一 - 實體集 A 中的一個實體最多可以與實體集 B 中的一個實體相關聯,反之亦然。

  • One-to-one relation
  • 一對多 - 實體集 A 中的一個實體可以與實體集 B 中的多個實體相關聯,但是實體集 B 中的一個實體最多可以與一個實體相關聯。

  • One-to-many relation
  • 多對一 - 實體集 A 中的多個實體最多可以與實體集 B 中的一個實體相關聯,但是實體集 B 中的一個實體可以與實體集 A 中的多個實體相關聯。

  • Many-to-one relation
  • 多對多 - A 中的一個實體可以與 B 中的多個實體相關聯,反之亦然。

  • Many-to-many relation

ER 圖表示

現在讓我們學習如何透過 ER 圖來表示 ER 模型。任何物件,例如實體、實體的屬性、關係集和關係集的屬性,都可以藉助 ER 圖來表示。

實體

實體透過矩形來表示。矩形用它們所代表的實體集命名。

Entities in a school database

屬性

屬性是實體的特性。屬性透過橢圓來表示。每個橢圓代表一個屬性,並直接連線到其實體(矩形)。

Simple Attributes

如果屬性是複合的,則它們將進一步劃分為樹狀結構。然後每個節點都連線到其屬性。也就是說,複合屬性由連線到橢圓的橢圓表示。

Composite Attributes

多值屬性由雙橢圓表示。

Multivalued Attributes

派生屬性由虛線橢圓表示。

Derived Attributes

關係

關係由菱形框表示。關係的名稱寫在菱形框內。所有參與關係的實體(矩形)都透過一條線連線到它。

二元關係和基數

兩個實體參與的關係稱為二元關係。基數是關係中實體的一個例項可以與關係關聯的數量。

  • 一對一 - 當只有一個實體例項與關係相關聯時,它被標記為“1:1”。下圖反映了每個實體只有一個例項應該與關係相關聯。它描述了一對一關係。

  • One-to-one
  • 一對多 - 當一個實體的多個例項與關係相關聯時,它被標記為“1:N”。下圖反映了左側實體只有一個例項,右側實體有多個例項可以與關係相關聯。它描述了一對多關係。

  • One-to-many
  • 多對一 - 當一個實體的多個例項與關係相關聯時,它被標記為“N:1”。下圖反映了左側實體有多個例項,右側實體只有一個例項可以與關係相關聯。它描述了多對一關係。

  • Many-to-one
  • 多對多 - 下圖反映了左側實體有多個例項,右側實體有多個例項可以與關係相關聯。它描述了多對多關係。

  • Many-to-many

參與約束

  • 完全參與 - 每個實體都參與關係。完全參與由雙線表示。

  • 部分參與 - 不是所有實體都參與關係。部分參與由單線表示。

Participation Constraints

泛化聚合

現在讓我們學習如何透過 ER 圖來表示 ER 模型。任何物件,例如實體、實體的屬性、關係集和關係集的屬性,都可以藉助 ER 圖來表示。

實體

實體透過矩形來表示。矩形用它們所代表的實體集命名。

Entities in a school database

屬性

屬性是實體的特性。屬性透過橢圓來表示。每個橢圓代表一個屬性,並直接連線到其實體(矩形)。

Simple Attributes

如果屬性是複合的,則它們將進一步劃分為樹狀結構。然後每個節點都連線到其屬性。也就是說,複合屬性由連線到橢圓的橢圓表示。

Composite Attributes

多值屬性由雙橢圓表示。

Multivalued Attributes

派生屬性由虛線橢圓表示。

Derived Attributes

關係

關係由菱形框表示。關係的名稱寫在菱形框內。所有參與關係的實體(矩形)都透過一條線連線到它。

二元關係和基數

兩個實體參與的關係稱為二元關係。基數是關係中實體的一個例項可以與關係關聯的數量。

  • 一對一 - 當只有一個實體例項與關係相關聯時,它被標記為“1:1”。下圖反映了每個實體只有一個例項應該與關係相關聯。它描述了一對一關係。

  • One-to-one
  • 一對多 - 當一個實體的多個例項與關係相關聯時,它被標記為“1:N”。下圖反映了左側實體只有一個例項,右側實體有多個例項可以與關係相關聯。它描述了一對多關係。

  • One-to-many
  • 多對一 - 當一個實體的多個例項與關係相關聯時,它被標記為“N:1”。下圖反映了左側實體有多個例項,右側實體只有一個例項可以與關係相關聯。它描述了多對一關係。

  • Many-to-one
  • 多對多 - 下圖反映了左側實體有多個例項,右側實體有多個例項可以與關係相關聯。它描述了多對多關係。

  • Many-to-many

參與約束

  • 完全參與 - 每個實體都參與關係。完全參與由雙線表示。

  • 部分參與 - 不是所有實體都參與關係。部分參與由單線表示。

Participation Constraints

泛化聚合

實體關係模型(ER Model)能夠以概念上的層次結構方式表達資料庫實體。隨著層次結構向上,它概括了實體的檢視;當我們深入層次結構時,它提供了每個包含實體的詳細資訊。

向上遍歷這種結構稱為泛化,其中實體被組合在一起以表示更通用的檢視。例如,一個名為Mira的特定學生可以與所有學生一起泛化。實體將是一個學生,並且進一步,學生是一個人。反之則稱為特化,即人是一個學生,而那個學生是Mira。

泛化

如上所述,將實體泛化的過程稱為泛化,其中泛化實體包含所有被泛化實體的屬性。在泛化中,許多實體基於其相似特徵被組合成一個泛化實體。例如,鴿子、麻雀、烏鴉和斑鳩都可以泛化為鳥類。

Generalization

特化

特化與泛化相反。在特化中,一組實體根據其特徵被劃分為子組。以“人”組為例。一個人有姓名、出生日期、性別等。這些屬性在所有人,即人類中都是通用的。但在公司中,可以根據他們在公司中扮演的角色將人員識別為僱員、僱主、客戶或供應商。

Specialization

類似地,在學校資料庫中,可以根據人員在學校中扮演的角色(作為實體)將其特化為教師、學生或職員。

繼承

為了在面向物件程式設計中建立物件類,我們使用ER模型的所有上述特性。實體的細節通常對使用者隱藏;此過程稱為抽象

繼承是泛化和特化的一個重要特性。它允許低階實體繼承高階實體的屬性。

Inheritance

例如,Person類的屬性(如姓名、年齡和性別)可以被低階實體(如Student或Teacher)繼承。

Codd的12條規則

Edgar F. Codd博士在其對資料庫系統關係模型的廣泛研究之後,提出了他自己的12條規則,他認為,為了被視為真正的關係資料庫,資料庫必須遵守這些規則。

這些規則可以應用於任何僅使用其關係功能管理儲存資料的資料庫系統。這是一個基礎規則,作為所有其他規則的基礎。

規則1:資訊規則

儲存在資料庫中的資料,無論是使用者資料還是元資料,都必須是某個表單元格的值。資料庫中的所有內容都必須以表格格式儲存。

規則2:保證訪問規則

每個資料元素(值)都保證可以透過表名、主鍵(行值)和屬性名(列值)的組合進行邏輯訪問。不能使用其他方法(如指標)訪問資料。

規則3:對NULL值的系統化處理

資料庫中的NULL值必須得到系統化和統一的處理。這是一個非常重要的規則,因為NULL可以解釋為以下含義之一:資料丟失、資料未知或資料不適用。

規則4:活動聯機目錄

整個資料庫的結構描述必須儲存在聯機目錄中,稱為資料字典,授權使用者可以訪問該目錄。使用者可以使用與訪問資料庫本身相同的查詢語言來訪問目錄。

規則5:綜合資料子語言規則

資料庫只能使用具有線性語法的語言訪問,該語言支援資料定義、資料操作和事務管理操作。此語言可以直接使用,也可以透過某些應用程式使用。如果資料庫允許在沒有任何此語言幫助的情況下訪問資料,則認為違反了此規則。

規則6:檢視更新規則

資料庫的所有理論上可以更新的檢視都必須由系統可更新。

規則7:高階插入、更新和刪除規則

資料庫必須支援高階插入、更新和刪除。這不能僅限於單行,也就是說,它還必須支援聯合、交集和差集運算以產生資料集記錄。

規則8:物理資料獨立性

儲存在資料庫中的資料必須獨立於訪問資料庫的應用程式。資料庫物理結構的任何更改都不應影響外部應用程式訪問資料的方式。

規則9:邏輯資料獨立性

資料庫中的邏輯資料必須獨立於使用者的檢視(應用程式)。邏輯資料的任何更改都不應影響使用它的應用程式。例如,如果合併兩個表或將一個表拆分為兩個不同的表,則不應影響或更改使用者應用程式。這是最難應用的規則之一。

規則10:完整性獨立性

資料庫必須獨立於使用它的應用程式。所有完整性約束都可以獨立修改,而無需對應用程式進行任何更改。此規則使資料庫獨立於前端應用程式及其介面。

規則11:分佈獨立性

終端使用者不能看到資料分佈在各個位置。使用者應該始終認為資料僅位於一個站點。此規則被認為是分散式資料庫系統的基礎。

規則12:非顛覆規則

如果系統具有提供對低階記錄訪問的介面,則該介面不能能夠顛覆系統並繞過安全性和完整性約束。

關係資料模型

關係資料模型是主要的資料模型,在全球範圍內廣泛用於資料儲存和處理。此模型簡單,並且具有處理資料並提高儲存效率所需的所有屬性和功能。

概念

- 在關係資料模型中,關係以表的格式儲存。此格式儲存實體之間的關係。表有行和列,其中行表示記錄,列表示屬性。

元組 - 表的一行,包含該關係的單個記錄稱為元組。

關係例項 - 關係資料庫系統中的一組有限的元組表示關係例項。關係例項不包含重複的元組。

關係模式 - 關係模式描述關係名稱(表名)、屬性及其名稱。

關係鍵 - 每行具有一或多個屬性,稱為關係鍵,可以唯一地識別關係(表)中的行。

屬性域 - 每個屬性都具有一些預定義的值範圍,稱為屬性域。

約束

每個關係都有一些條件必須滿足才能成為有效的關係。這些條件稱為關係完整性約束。主要有三種完整性約束:

  • 鍵約束
  • 域約束
  • 引用完整性約束

鍵約束

關係中必須至少存在一個最小子集的屬性,可以唯一地識別元組。此屬性的最小子集稱為該關係的。如果存在多個這樣的最小子集,則稱為候選鍵

鍵約束強制:

  • 在具有鍵屬性的關係中,沒有兩個元組可以對鍵屬性具有相同的值。

  • 鍵屬性不能具有NULL值。

鍵約束也稱為實體約束。

域約束

屬性在現實世界場景中具有特定值。例如,年齡只能是正整數。已嘗試在關係的屬性上使用相同的約束。每個屬性都必須具有特定範圍的值。例如,年齡不能小於零,電話號碼不能包含0-9以外的數字。

引用完整性約束

引用完整性約束基於外部索引鍵的概念。外部索引鍵是關係的一個鍵屬性,可以在其他關係中引用。

引用完整性約束規定,如果關係引用不同關係或相同關係的鍵屬性,則該鍵元素必須存在。

關係代數

關係資料庫系統應配備查詢語言,以幫助其使用者查詢資料庫例項。查詢語言有兩種:關係代數和關係演算。

關係代數

關係代數是一種過程式查詢語言,它以關係例項作為輸入,並以關係例項作為輸出。它使用運算子執行查詢。運算子可以是一元二元的。它們接受關係作為輸入,並以關係作為輸出。關係代數遞迴地對關係執行,中間結果也被視為關係。

關係代數的基本操作如下:

  • 選擇
  • 投影
  • 並集
  • 差集
  • 笛卡爾積
  • 重新命名

我們將在以下部分討論所有這些操作。

選擇操作(σ)

它從關係中選擇滿足給定謂詞的元組。

表示法 - σp(r)

其中σ表示選擇謂詞,r表示關係。p是命題邏輯公式,可以使用and、ornot等連線詞。這些術語可以使用關係運算符,如 - =、≠、≥、<、>、≤。

例如 -

σsubject="database"(Books)

輸出 - 選擇主題為“資料庫”的書籍元組。

σsubject="database" and price="450"(Books)

輸出 - 選擇主題為“資料庫”且“價格”為450的書籍元組。

σsubject="database" and price < "450" or year > "2010"(Books)

輸出 - 選擇主題為“資料庫”且“價格”為450的書籍元組,或2010年後出版的書籍元組。

投影操作(∏)

它投影滿足給定謂詞的列。

表示法 - ∏A1, A2, An (r)

其中A1、A2、An是關係r的屬性名稱。

由於關係是集合,因此會自動消除重複的行。

例如 -

subject, author (Books)

從Books關係中選擇並投影名為subject和author的列。

並集操作(∪)

它對兩個給定關係執行二元並集,定義如下:

r ∪ s = { t | t ∈ r or t ∈ s}

表示法 - r U s

其中rs是資料庫關係或關係結果集(臨時關係)。

為了使並集操作有效,必須滿足以下條件:

  • rs必須具有相同數量的屬性。
  • 屬性域必須相容。
  • 重複的元組會自動消除。

author (Books) ∪ ∏ author (Articles)

輸出 - 投影已編寫書籍或文章或兩者的作者的姓名。

差集(-)

差集操作的結果是存在於一個關係中但不存在於第二個關係中的元組。

表示法 - r - s

查詢存在於r中但不存在於s中的所有元組。

author (Books) − ∏ author (Articles)

輸出 - 提供已編寫書籍但未編寫文章的作者的姓名。

笛卡爾積(Χ)

將兩個不同關係的資訊組合成一個。

表示法 - r Χ s

其中rs是關係,它們的輸出將定義為:

r Χ s = { q t | q ∈ r and t ∈ s}

author = 'tutorialspoint'(Books Χ Articles)

輸出 - 生成一個關係,顯示tutorialspoint編寫的所有書籍和文章。

重新命名操作(ρ)

關係代數的結果也是關係,但沒有名稱。重新命名操作允許我們重新命名輸出關係。“重新命名”操作用希臘字母rho ρ表示。

表示法 - ρ x (E)

表示式E的結果以x命名進行儲存。

其他操作包括:

  • 集合交集
  • 賦值
  • 自然連線

關係演算

與關係代數相反,關係演算是一種非過程查詢語言,即它說明做什麼,但從不解釋如何做。

關係演算存在兩種形式:

元組關係演算 (TRC)

過濾元組上的變數範圍

表示法 - {T | 條件}

返回滿足條件的所有元組 T。

例如 -

{ T.name |  Author(T) AND T.article = 'database' }

輸出 - 返回 Author 中撰寫關於“資料庫”文章的 'name' 欄位對應的元組。

TRC 可以進行量化。我們可以使用存在量詞 (∃) 和全稱量詞 (∀)。

例如 -

{ R| ∃T   ∈ Authors(T.article='database' AND R.name=T.name)}

輸出 - 上述查詢將產生與前一個查詢相同的結果。

域關係演算 (DRC)

在 DRC 中,過濾變數使用屬性的域而不是整個元組值(如上面提到的 TRC 中所做的那樣)。

表示法 -

{ a1, a2, a3, ..., an | P (a1, a2, a3, ... ,an)}

其中 a1、a2 是屬性,而P表示由內部屬性構建的公式。

例如 -

{< article, page, subject > | ∈ TutorialsPoint ∧ subject = 'database'}

輸出 - 從 TutorialsPoint 關係中生成 Article、Page 和 Subject,其中 subject 為 database。

就像 TRC 一樣,DRC 也可以使用存在量詞和全稱量詞來編寫。DRC 還涉及關係運算符。

元組關係演算和域關係演算的表達能力等價於關係代數。

ER 模型到關係模型

ER 模型,當概念化為圖表時,提供了實體關係的良好概述,更容易理解。ER 圖可以對映到關係模式,也就是說,可以使用 ER 圖建立關係模式。我們不能將所有 ER 約束匯入關係模型,但可以生成一個近似的模式。

有幾種可用於將 ER 圖轉換為關係模式的過程和演算法。其中一些是自動化的,另一些是手動的。我們可能在這裡關注將圖表內容對映到關係基礎知識。

ER 圖主要包括:

  • 實體及其屬性
  • 關係,即實體之間的關聯。

實體對映

實體是具有某些屬性的現實世界物件。

Mapping Entity

對映過程(演算法)

  • 為每個實體建立一個表。
  • 實體的屬性應成為表中具有各自資料型別的欄位。
  • 宣告主鍵。

關係對映

關係是實體之間的關聯。

Mapping relationship

對映過程

  • 為關係建立一個表。
  • 將所有參與實體的主鍵作為表中具有各自資料型別的欄位新增。
  • 如果關係有任何屬性,則將每個屬性作為表的欄位新增。
  • 宣告一個主鍵,該主鍵由所有參與實體的主鍵組成。
  • 宣告所有外部索引鍵約束。

弱實體集對映

弱實體集是沒有與其關聯的任何主鍵的實體集。

Mapping Weak Entity Sets

對映過程

  • 為弱實體集建立一個表。
  • 將所有屬性作為欄位新增到表中。
  • 新增識別實體集的主鍵。
  • 宣告所有外部索引鍵約束。

層次實體對映

ER 特化或泛化以層次實體集的形式出現。

Mapping hierarchical entities

對映過程

  • 為所有高級別實體建立表。

  • 為低級別實體建立表。

  • 在低級別實體的表中新增高級別實體的主鍵。

  • 在低級別表中,新增低級別實體的所有其他屬性。

  • 宣告高級別表的主鍵和低級別表的主鍵。

  • 宣告外部索引鍵約束。

SQL 概述

SQL 是一種用於關係資料庫的程式語言。它是在關係代數和元組關係演算的基礎上設計的。SQL 與所有主要 RDBMS 發行版捆綁在一起。

SQL 包含資料定義語言和資料操縱語言。使用 SQL 的資料定義屬性,可以設計和修改資料庫模式,而資料操縱屬性允許 SQL 從資料庫中儲存和檢索資料。

資料定義語言

SQL 使用以下命令集來定義資料庫模式:

CREATE

從 RDBMS 建立新的資料庫、表和檢視。

例如 -

Create database tutorialspoint;
Create table article;
Create view for_students;

DROP

從 RDBMS 刪除命令、檢視、表和資料庫。

例如-

Drop object_type object_name;
Drop database tutorialspoint;
Drop table article;
Drop view for_students;

ALTER

修改資料庫模式。

Alter object_type object_name parameters;

例如-

Alter table article add subject varchar;

此命令在article關係中新增一個名為subject的字串型別屬性。

資料操縱語言

SQL 配備了資料操縱語言 (DML)。DML 透過插入、更新和刪除其資料來修改資料庫例項。DML 負責資料庫中所有形式的資料修改。SQL 在其 DML 部分包含以下命令集:

  • SELECT/FROM/WHERE
  • INSERT INTO/VALUES
  • UPDATE/SET/WHERE
  • DELETE FROM/WHERE

這些基本結構允許資料庫程式設計師和使用者將資料和資訊輸入資料庫,並使用許多篩選選項高效地檢索資料。

SELECT/FROM/WHERE

  • SELECT - 這是 SQL 的基本查詢命令之一。它類似於關係代數的投影操作。它根據 WHERE 子句描述的條件選擇屬性。

  • FROM - 此子句以關係名稱作為引數,從中選擇/投影屬性。如果給出了多個關係名稱,則此子句對應於笛卡爾積。

  • WHERE - 此子句定義謂詞或條件,必須匹配才能使屬性有資格被投影。

例如 -

Select author_name
From book_author
Where age > 50;

此命令將生成book_author關係中年齡大於 50 的作者的姓名。

INSERT INTO/VALUES

此命令用於將值插入表的行(關係)。

語法-

INSERT INTO table (column1 [, column2, column3 ... ]) VALUES (value1 [, value2, value3 ... ])

INSERT INTO table VALUES (value1, [value2, ... ])

例如 -

INSERT INTO tutorialspoint (Author, Subject) VALUES ("anonymous", "computers");

UPDATE/SET/WHERE

此命令用於更新或修改表(關係)中列的值。

語法 -

UPDATE table_name SET column_name = value [, column_name = value ...] [WHERE condition]

例如 -

UPDATE tutorialspoint SET Author="webmaster" WHERE Author="anonymous";

DELETE/FROM/WHERE

此命令用於從表(關係)中刪除一行或多行。

語法 -

DELETE FROM table_name [WHERE condition];

例如 -

DELETE FROM tutorialspoints
   WHERE Author="unknown";

DBMS - 規範化

函式依賴

函式依賴 (FD) 是關係中兩個屬性之間的一組約束。函式依賴表示如果兩個元組在屬性 A1、A2、...、An 上具有相同的值,則這兩個元組必須在屬性 B1、B2、...、Bn 上具有相同的值。

函式依賴用箭頭符號 (→) 表示,即 X→Y,其中 X 函式決定 Y。左側屬性決定右側屬性的值。

阿姆斯特朗公理

如果 F 是一組函式依賴,則 F 的閉包,表示為 F+,是由 F 邏輯推匯出的所有函式依賴的集合。阿姆斯特朗公理是一組規則,當重複應用時,會生成函式依賴的閉包。

  • 自反規則 - 如果 alpha 是一組屬性,而 beta 是 alpha 的子集,則 alpha 包含 beta。

  • 增廣規則 - 如果 a → b 成立,而 y 是屬性集,則 ay → by 也成立。也就是說,在依賴項中新增屬性不會改變基本依賴項。

  • 傳遞規則 - 與代數中的傳遞規則相同,如果 a → b 成立且 b → c 成立,則 a → c 也成立。a → b 稱為函式決定 b。

平凡函式依賴

  • 平凡 - 如果函式依賴 (FD) X → Y 成立,其中 Y 是 X 的子集,則稱為平凡 FD。平凡 FD 始終成立。

  • 非平凡 - 如果 FD X → Y 成立,其中 Y 不是 X 的子集,則稱為非平凡 FD。

  • 完全非平凡 - 如果 FD X → Y 成立,其中 x 與 Y 的交集 = Φ,則稱其為完全非平凡 FD。

規範化

如果資料庫設計不完美,則可能包含異常,這對於任何資料庫管理員來說都像噩夢一樣。管理包含異常的資料庫幾乎是不可能的。

  • 更新異常 - 如果資料項分散並且未正確相互連結,則可能導致奇怪的情況。例如,當我們嘗試更新一個數據項時,該資料項的副本分散在多個位置,一些例項得到正確更新,而另一些則保留舊值。此類例項使資料庫處於不一致狀態。

  • 刪除異常 - 我們嘗試刪除記錄,但由於不知道資料也儲存在其他地方,因此部分記錄未被刪除。

  • 插入異常 - 我們嘗試在根本不存在的記錄中插入資料。

規範化是一種消除所有這些異常並將資料庫置於一致狀態的方法。

第一正規化

第一正規化在關係(表)本身的定義中定義。此規則定義關係中的所有屬性都必須具有原子域。原子域中的值是不可分割的單元。

unorganized relation

我們如下重新排列關係(表),以將其轉換為第一正規化。

Relation in 1NF

每個屬性只能包含來自其預定義域的單個值。

第二正規化

在學習第二正規化之前,我們需要了解以下內容:

  • 主屬性 - 候選鍵的一部分的屬性稱為主屬性。

  • 非主屬性 - 不是主鍵一部分的屬性稱為非主屬性。

如果我們遵循第二正規化,則每個非主屬性都應完全函式依賴於主鍵屬性。也就是說,如果 X → A 成立,則 X 的任何真子集 Y 不應存在,對於該子集 Y → A 也成立。

Relation not in 2NF

我們在此處在 Student_Project 關係中看到,主鍵屬性是 Stu_ID 和 Proj_ID。根據規則,非鍵屬性,即 Stu_Name 和 Proj_Name 必須依賴於兩者,而不是單獨依賴於任何一個主鍵屬性。但我們發現 Stu_Name 可以獨立地由 Stu_ID 識別,Proj_Name 可以獨立地由 Proj_ID 識別。這稱為部分依賴,第二正規化不允許這種情況。

Relation  in 2NF

我們如上圖所示將關係分成兩個。因此,不存在部分依賴關係。

第三正規化

要使關係處於第三正規化,它必須處於第二正規化,並且必須滿足以下條件:

  • 非主屬性不傳遞依賴於主鍵屬性。
  • 對於任何非平凡函式依賴 X → A,則:
      X 是超鍵,或
    • A 是主屬性。
Relation not in 3NF

我們發現在上面的 Student_detail 關係中,Stu_ID 是鍵並且是唯一的主鍵屬性。我們發現 City 可以由 Stu_ID 和 Zip 本身識別。Zip 既不是超鍵,City 也不是主屬性。此外,Stu_ID → Zip → City,因此存在傳遞依賴

為了將此關係轉換為第三正規化,我們將關係分成兩個關係,如下所示:

Relation in 3NF

Boyce-Codd 正規化

Boyce-Codd 正規化 (BCNF) 是對第三正規化在嚴格意義上的擴充套件。BCNF 指出:

  • 對於任何非平凡函式依賴 X → A,X 必須是超鍵。

在上圖中,Stu_ID 是關係 Student_Detail 的超鍵,Zip 是關係 ZipCodes 的超鍵。因此,

Stu_ID → Stu_Name, Zip

以及

Zip → City

這證實了這兩個關係都處於 BCNF 狀態。

DBMS - 連線

我們瞭解獲取兩個關係的笛卡爾積的好處,它為我們提供了所有配對在一起的可能的元組。但在某些情況下,獲取笛卡爾積可能不可行,例如遇到包含數千個元組且具有相當大量屬性的大型關係。

連線是笛卡爾積和選擇過程的組合。只有當滿足給定的連線條件時,連線操作才會將來自不同關係的兩個元組配對。

我們將在以下部分簡要描述各種連線型別。

θ 連線

θ 連線組合來自不同關係的元組,前提是它們滿足 θ 條件。連線條件用符號θ表示。

符號

R1 ⋈θ R2

R1 和 R2 是具有屬性 (A1, A2, .., An) 和 (B1, B2,.. ,Bn) 的關係,其中屬性之間沒有任何共同點,即 R1 ∩ R2 = Φ。

θ 連線可以使用各種比較運算子。

學生
SID 姓名 Std
101 Alex 10
102 Maria 11
科目
班級 科目
10 數學
10 英語
11 音樂
11 體育

Student_Detail =

STUDENT Student.Std = Subject.Class SUBJECT

學生詳細資訊
SID 姓名 Std 班級 科目
101 Alex 10 10 數學
101 Alex 10 10 英語
102 Maria 11 11 音樂
102 Maria 11 11 體育

等值連線

當 θ 連線僅使用等於比較運算子時,稱為等值連線。以上示例對應於等值連線。

自然連線()

自然連線不使用任何比較運算子。它不像笛卡爾積那樣進行連線。只有當兩個關係之間至少存在一個公共屬性時,我們才能執行自然連線。此外,這些屬性必須具有相同的名稱和域。

自然連線作用於那些匹配的屬性,其中兩個關係中屬性的值相同。

課程
CID 課程
CS01 資料庫 CS
ME01 力學 ME
EE01 電子學 EE
系主任
主任
CS Alex
ME Maya
EE Mira
Courses ⋈ HoD
CID 課程 主任
CS CS01 資料庫 Alex
ME ME01 力學 Maya
EE EE01 電子學 Mira

外連線

θ 連線、等值連線和自然連線稱為內連線。內連線僅包含具有匹配屬性的元組,其餘元組在結果關係中被丟棄。因此,我們需要使用外連線將參與關係中的所有元組包含在結果關係中。外連線有三種類型:左外連線、右外連線和全外連線。

左外連線(R Left Outer Join S)

左關係 R 中的所有元組都包含在結果關係中。如果 R 中存在任何元組在右關係 S 中沒有匹配元組,則結果關係的 S 屬性將設為 NULL。

A B
100 資料庫
101 力學
102 電子學
A B
100 Alex
102 Maya
104 Mira
Courses Left Outer Join HoD
A B C D
100 資料庫 100 Alex
101 力學 --- ---
102 電子學 102 Maya

右外連線: ( R Right Outer Join S )

右關係 S 中的所有元組都包含在結果關係中。如果 S 中存在任何元組在 R 中沒有匹配元組,則結果關係的 R 屬性將設為 NULL。

Courses Right Outer Join HoD
A B C D
100 資料庫 100 Alex
102 電子學 102 Maya
--- --- 104 Mira

全外連線: ( R Full Outer Join S)

兩個參與關係中的所有元組都包含在結果關係中。如果兩個關係都沒有匹配的元組,則它們各自的未匹配屬性將設為 NULL。

Courses Full Outer Join HoD
A B C D
100 資料庫 100 Alex
101 力學 --- ---
102 電子學 102 Maya
--- --- 104 Mira

DBMS - 儲存系統

資料庫儲存在檔案格式中,其中包含記錄。在物理層面上,實際資料以電磁格式儲存在某些裝置上。這些儲存裝置可以大致分為三種類型:

Memory Types
  • 主儲存器 - CPU 可以直接訪問的記憶體儲存屬於此類別。CPU 的內部記憶體(暫存器)、快取記憶體(快取)和主記憶體(RAM)都可以被 CPU 直接訪問,因為它們都放置在主機板上或 CPU 晶片組上。這種儲存器通常非常小、速度極快且易失。主儲存器需要持續供電才能保持其狀態。如果發生斷電,其所有資料都會丟失。

  • 輔助儲存器 - 輔助儲存裝置用於儲存資料以備將來使用或作為備份。輔助儲存器包括不屬於 CPU 晶片組或主機板的記憶體裝置,例如磁磁碟、光碟(DVD、CD 等)、硬碟、快閃記憶體驅動器和磁帶。

  • 三級儲存器 - 三級儲存器用於儲存海量資料。由於此類儲存裝置位於計算機系統外部,因此速度最慢。這些儲存裝置主要用於備份整個系統。光碟和磁帶被廣泛用作三級儲存器。

記憶體層次結構

計算機系統具有明確定義的記憶體層次結構。CPU 可以直接訪問其主記憶體以及其內建暫存器。主記憶體的訪問時間顯然小於 CPU 速度。為了最大程度地減少這種速度差異,引入了快取。快取提供最快的訪問時間,並且包含 CPU 最常訪問的資料。

訪問速度最快的記憶體也是最昂貴的。較大的儲存裝置提供較慢的速度,並且價格較低,但是與 CPU 暫存器或快取相比,它們可以儲存海量資料。

磁磁碟

硬碟驅動器是當前計算機系統中最常見的輔助儲存裝置。之所以稱為磁磁碟,是因為它們使用磁化概念來儲存資訊。硬碟由塗有可磁化材料的金屬磁碟組成。這些磁碟垂直放置在主軸上。讀/寫磁頭在磁碟之間移動,用於磁化或去磁化其下方的點。磁化點可以識別為 0(零)或 1(一)。

硬碟以明確定義的順序格式化,以便有效地儲存資料。硬碟碟片上有許多同心圓,稱為磁軌。每個磁軌進一步細分為扇區。硬碟上的扇區通常儲存 512 位元組的資料。

RAID

RAID 代表Redundant Array of Independent Disks,這是一項連線多個輔助儲存裝置並將它們用作單個儲存介質的技術。

RAID 由一個磁碟陣列組成,其中多個磁碟連線在一起以實現不同的目標。RAID 級別定義了磁碟陣列的使用。

  • RAID 0 - 在此級別,實現了磁碟的條帶化陣列。資料被分解成塊,這些塊分佈在磁碟之間。每個磁碟接收一個數據塊以並行寫入/讀取。它提高了儲存裝置的速度和效能。級別 0 沒有奇偶校驗和備份。

RAID 0
  • RAID 1 - RAID 1 使用映象技術。當資料傳送到 RAID 控制器時,它會將資料副本傳送到陣列中的所有磁碟。RAID 級別 1 也稱為映象,在發生故障時提供 100% 的冗餘。

RAID 1
  • RAID 2 - RAID 2 使用漢明距離記錄其資料的糾錯碼,並將其條帶化到不同的磁碟上。與級別 0 類似,單詞中的每個資料位都記錄在單獨的磁碟上,並且資料單詞的 ECC 程式碼儲存在不同的磁碟集上。由於其結構複雜且成本高昂,RAID 2 並非商用。

RAID 2
  • RAID 3 - RAID 3 將資料條帶化到多個磁碟上。為資料字生成的奇偶校驗位儲存在不同的磁碟上。此技術使其能夠克服單個磁碟故障。

RAID 3
  • RAID 4 - 在此級別,將整個資料塊寫入資料磁碟,然後生成奇偶校驗並存儲在不同的磁碟上。請注意,級別 3 使用位元組級條帶化,而級別 4 使用塊級條帶化。級別 3 和級別 4 都需要至少三個磁碟才能實現 RAID。

RAID 4
  • RAID 5 - RAID 5 將整個資料塊寫入不同的磁碟,但為資料塊條帶生成的奇偶校驗位分佈在所有資料磁碟上,而不是儲存在不同的專用磁碟上。

RAID 5
  • RAID 6 - RAID 6 是級別 5 的擴充套件。在此級別,生成兩個獨立的奇偶校驗並以分散式方式儲存在多個磁碟上。兩個奇偶校驗提供額外的容錯能力。此級別需要至少四個磁碟驅動器才能實現 RAID。

DBMS - 檔案結構

相對資料和資訊以檔案格式集體儲存。檔案是以二進位制格式儲存的一系列記錄。磁碟驅動器被格式化為多個可以儲存記錄的塊。檔案記錄對映到這些磁碟塊上。

檔案組織

檔案組織定義瞭如何將檔案記錄對映到磁碟塊上。我們有四種檔案組織型別來組織檔案記錄:

File Organization

堆檔案組織

使用堆檔案組織建立檔案時,作業系統會為該檔案分配記憶體區域,而無需任何其他會計詳細資訊。檔案記錄可以放置在該記憶體區域的任何位置。軟體負責管理記錄。堆檔案本身不支援任何排序、排序或索引。

順序檔案組織

每個檔案記錄都包含一個數據欄位(屬性)來唯一標識該記錄。在順序檔案組織中,記錄根據唯一的鍵欄位或搜尋鍵以某種順序放置在檔案中。實際上,不可能以物理形式順序儲存所有記錄。

雜湊檔案組織

雜湊檔案組織對記錄的某些欄位使用雜湊函式計算。雜湊函式的輸出確定要放置記錄的磁碟塊的位置。

聚簇檔案組織

聚簇檔案組織不適用於大型資料庫。在這種機制中,來自一個或多個關係的相關記錄儲存在同一個磁碟塊中,也就是說,記錄的排序不是基於主鍵或搜尋鍵。

檔案操作

資料庫檔案上的操作可以大致分為兩類:

  • 更新操作

  • 檢索操作

更新操作透過插入、刪除或更新來改變資料值。另一方面,檢索操作不改變資料,而是在可選的條件過濾後檢索資料。在這兩種型別的操作中,選擇都起著重要的作用。除了建立和刪除檔案之外,還可以在檔案上執行其他一些操作。

  • 開啟 - 檔案可以以兩種模式之一開啟,讀取模式寫入模式。在讀取模式下,作業系統不允許任何人更改資料。換句話說,資料是隻讀的。以讀取模式開啟的檔案可以在多個實體之間共享。寫入模式允許修改資料。以寫入模式開啟的檔案可以讀取,但不能共享。

  • 定位 - 每個檔案都有一個檔案指標,它指示要讀取或寫入資料的當前位置。此指標可以相應地調整。使用查詢(查詢)操作,可以向前或向後移動它。

  • 讀取 - 預設情況下,當檔案以讀取模式開啟時,檔案指標指向檔案的開頭。使用者可以選擇在開啟檔案時告訴作業系統將檔案指標定位到哪裡。讀取檔案指標後面的下一個資料。

  • 寫入 - 使用者可以選擇以寫入模式開啟檔案,這使他們能夠編輯其內容。它可以是刪除、插入或修改。檔案指標可以在開啟時定位,如果作業系統允許,也可以動態更改。

  • 關閉 - 從作業系統的角度來看,這是最重要的操作。當生成關閉檔案的請求時,作業系統

    • 刪除所有鎖(如果處於共享模式),
    • 將資料(如果已更改)儲存到輔助儲存介質,以及
    • 釋放與檔案關聯的所有緩衝區和檔案控制代碼。

檔案內部資料的組織在這裡起著主要作用。定位檔案指標到檔案內所需記錄的過程取決於記錄是順序排列還是聚簇排列。

DBMS - 索引

我們知道資料以記錄的形式儲存。每個記錄都有一個鍵欄位,可以幫助它唯一地識別。

索引是一種資料結構技術,可以根據已對其進行索引的一些屬性有效地從資料庫檔案中檢索記錄。資料庫系統中的索引類似於我們在書籍中看到的索引。

索引是根據其索引屬性定義的。索引可以是以下型別:

  • 主索引 - 主索引定義在有序資料檔案上。資料檔案根據鍵欄位排序。鍵欄位通常是關係的主鍵。

  • 次索引 - 次索引可以從候選鍵欄位生成,該欄位在每條記錄中都有唯一值,或者是非鍵欄位,具有重複值。

  • 聚簇索引 - 聚簇索引定義在有序資料檔案上。資料檔案根據非鍵欄位排序。

有序索引有兩種型別:

  • 稠密索引
  • 稀疏索引

稠密索引

在稠密索引中,資料庫中的每個搜尋鍵值都有一個索引記錄。這使得搜尋更快,但需要更多空間來儲存索引記錄本身。索引記錄包含搜尋鍵值和指向磁碟上實際記錄的指標。

Dense Index

稀疏索引

在稀疏索引中,並非為每個搜尋鍵建立索引記錄。此處的索引記錄包含一個搜尋鍵和一個指向磁碟上資料的實際指標。要搜尋記錄,我們首先透過索引記錄進行,併到達資料的實際位置。如果我們正在尋找的資料不在我們透過遵循索引直接到達的位置,那麼系統將開始順序搜尋,直到找到所需的資料。

Sparse Index

多級索引

索引記錄包含搜尋鍵值和資料指標。多級索引與實際的資料庫檔案一起儲存在磁碟上。隨著資料庫大小的增長,索引的大小也會增長。迫切需要將索引記錄儲存在主記憶體中,以加快搜索操作。如果使用單級索引,則大型索引無法儲存在記憶體中,這會導致多次磁碟訪問。

Multi-level Index

多級索引有助於將索引分解成多個較小的索引,以便使最外層索引足夠小,可以儲存在單個磁碟塊中,該磁碟塊可以輕鬆地容納在主記憶體中的任何位置。

B+

B+樹是一種平衡二叉搜尋樹,遵循多級索引格式。B+樹的葉子節點表示實際資料指標。B+樹確保所有葉子節點保持相同的高度,從而保持平衡。此外,葉子節點使用連結列表連結;因此,B+樹可以支援隨機訪問以及順序訪問。

B+樹的結構

每個葉子節點與根節點的距離相等。B+樹的階數為n,其中n對於每個B+樹都是固定的。

B+ tree

內部節點 -

  • 內部(非葉子)節點至少包含⌈n/2⌉個指標,根節點除外。
  • 最多,一個內部節點可以包含n個指標。

葉子節點 -

  • 葉子節點至少包含⌈n/2⌉個記錄指標和⌈n/2⌉個鍵值。
  • 最多,一個葉子節點可以包含n個記錄指標和n個鍵值。
  • 每個葉子節點都包含一個塊指標P指向下一個葉子節點,並形成一個連結列表。

B+樹插入

  • B+樹從底部填充,每個條目都在葉子節點完成。

  • 如果葉子節點溢位 -
    • 將節點分成兩部分。

    • i = ⌊(m+1)/2處進行分割槽。

    • i個條目儲存在一個節點中。

    • 其餘的條目(從i+1開始)移動到一個新節點。

    • ith鍵在葉子的父節點中重複。

  • 如果非葉子節點溢位 -

    • 將節點分成兩部分。

    • i = ⌈(m+1)/2處對節點進行分割槽。

    • 最多i個條目儲存在一個節點中。

    • 其餘的條目移動到一個新節點。

B+樹刪除

  • B+樹條目在葉子節點處刪除。

  • 搜尋並刪除目標條目。

    • 如果它是內部節點,則刪除並替換為左側位置的條目。

  • 刪除後,測試下溢,

    • 如果發生下溢,則從其左側的節點分配條目。

  • 如果無法從左側分配,則

    • 從其右側的節點分配。

  • 如果無法從左側或右側分配,則

    • 將節點與其左右合併。

DBMS - 雜湊

對於龐大的資料庫結構,幾乎不可能透過所有級別搜尋所有索引值,然後到達目標資料塊以檢索所需資料。雜湊是一種有效的技術,可以計算磁碟上資料記錄的直接位置,而無需使用索引結構。

雜湊使用搜索鍵作為引數的雜湊函式來生成資料記錄的地址。

雜湊組織

  • - 雜湊檔案以桶格式儲存資料。桶被認為是儲存單元。一個桶通常儲存一個完整的磁碟塊,而一個磁碟塊又可以儲存一個或多個記錄。

  • 雜湊函式 - 雜湊函式h是一個對映函式,它將所有搜尋鍵K的集合對映到放置實際記錄的地址。它是一個從搜尋鍵到桶地址的函式。

靜態雜湊

在靜態雜湊中,當提供搜尋鍵值時,雜湊函式始終計算相同的地址。例如,如果使用模4雜湊函式,則它只能生成5個值。對於該函式,輸出地址始終相同。提供的桶數始終保持不變。

Static Hashing

操作

  • 插入 - 當需要使用靜態雜湊輸入記錄時,雜湊函式h計算搜尋鍵K的桶地址,記錄將儲存在此處。

    桶地址 = h(K)

  • 搜尋 - 當需要檢索記錄時,可以使用相同的雜湊函式檢索儲存資料所在的桶的地址。

  • 刪除 - 這只是一個搜尋後跟刪除操作。

桶溢位

桶溢位的情況稱為衝突。這對任何靜態雜湊函式來說都是一個致命的狀態。在這種情況下,可以使用溢位連結。

  • 溢位連結 - 當桶滿時,為相同的雜湊結果分配一個新桶,並在上一個桶之後連結。這種機制稱為閉合雜湊

Overflow chaining
  • 線性探測 - 當雜湊函式生成一個數據已儲存的地址時,將為其分配下一個空閒桶。這種機制稱為開放雜湊

Linear Probing

動態雜湊

靜態雜湊的問題在於,它不會隨著資料庫大小的增長或縮小而動態擴充套件或收縮。動態雜湊提供了一種機制,可以在其中動態且按需新增和刪除資料桶。動態雜湊也稱為擴充套件雜湊

在動態雜湊中,雜湊函式被設計為產生大量值,並且最初只使用其中一部分。

Dynamic Hashing

組織

整個雜湊值的開頭部分作為雜湊索引。只有雜湊值的一部分用於計算桶地址。每個雜湊索引都有一個深度值,表示用於計算雜湊函式的位數。這些位可以定址2n個桶。當所有這些位都被使用時 - 即當所有桶都滿時 - 深度值線性增加,並分配兩倍的桶。

操作

  • 查詢 - 檢視雜湊索引的深度值,並使用這些位來計算桶地址。

  • 更新 - 執行如上所述的查詢並更新資料。

  • 刪除 - 執行查詢以定位所需資料並刪除相同的資料。

  • 插入 - 計算桶的地址

    • 如果桶已滿。
      • 新增更多桶。
      • 向雜湊值新增額外的位。
      • 重新計算雜湊函式。
    • 否則
      • 將資料新增到桶中,
    • 如果所有桶都滿了,則執行靜態雜湊的補救措施。

當資料以某種順序組織並且查詢需要一定範圍的資料時,雜湊是不利的。當資料離散且隨機時,雜湊表現最佳。

雜湊演算法的複雜度高於索引。所有雜湊操作都在恆定時間內完成。

DBMS - 事務

事務可以定義為一組任務。單個任務是最小的處理單元,不能再進一步細分。

讓我們以一個簡單的交易為例。假設一位銀行職員將500盧比從A的賬戶轉到B的賬戶。這個非常簡單的小額交易涉及到幾個低級別的任務。

A的賬戶

Open_Account(A)
Old_Balance = A.balance
New_Balance = Old_Balance - 500
A.balance = New_Balance
Close_Account(A)

B的賬戶

Open_Account(B)
Old_Balance = B.balance
New_Balance = Old_Balance + 500
B.balance = New_Balance
Close_Account(B)

ACID屬性

事務是程式的一個非常小的單元,它可能包含多個低階任務。資料庫系統中的事務必須維護**原子性**、**一致性**、**隔離性**和**永續性**——通常稱為ACID屬性——以確保準確性、完整性和資料完整性。

  • **原子性**——此屬性規定事務必須被視為一個原子單元,即要麼所有操作都執行,要麼都不執行。資料庫中不應存在事務部分完成的狀態。狀態應在事務執行之前或事務執行/中止/失敗之後定義。

  • **一致性**——在任何事務之後,資料庫都必須保持一致的狀態。任何事務都不應對資料庫中駐留的資料產生任何不利影響。如果資料庫在事務執行之前處於一致狀態,則在事務執行之後也必須保持一致狀態。

  • **永續性**——即使系統發生故障或重新啟動,資料庫也應該足夠持久以保留其所有最新更新。如果事務更新資料庫中的一部分資料並提交,則資料庫將保留修改後的資料。如果事務提交但系統在資料寫入磁碟之前發生故障,則系統恢復執行後將更新該資料。

  • **隔離性**——在資料庫系統中,如果多個事務同時並行執行,則隔離性屬性規定所有事務都將被執行,就好像它是系統中唯一的事務一樣。任何事務都不會影響任何其他事務的存在。

可序列化

當多個事務在多程式設計環境中由作業系統執行時,有可能一個事務的指令與其他事務的指令交錯執行。

  • **排程**——事務的按時間順序執行序列稱為排程。一個排程可以包含許多事務,每個事務包含多個指令/任務。

  • **序列排程**——它是一種排程,其中事務以這樣一種方式排列,即一個事務首先執行。當第一個事務完成其迴圈後,則執行下一個事務。事務一個接一個地排序。這種型別的排程稱為序列排程,因為事務以序列方式執行。

在多事務環境中,序列排程被認為是基準。事務中指令的執行順序不能更改,但兩個事務可以以隨機方式執行其指令。如果兩個事務相互獨立並在資料的不同段上工作,則此執行不會造成任何損害;但如果這兩個事務正在處理相同的資料,則結果可能會有所不同。這種不斷變化的結果可能會導致資料庫進入不一致的狀態。

為了解決此問題,如果事務的可序列化或它們之間存在某種等價關係,則允許並行執行事務排程。

等價排程

等價排程可以是以下型別:

結果等價

如果兩個排程在執行後產生相同的結果,則稱它們為結果等價。它們可能對某些值產生相同的結果,而對另一組值產生不同的結果。這就是為什麼這種等價通常不被認為是重要的。

檢視等價

如果兩個排程中的事務以類似的方式執行類似的操作,則這兩個排程將是檢視等價的。

例如:

  • 如果T在S1中讀取初始資料,則它也在S2中讀取初始資料。

  • 如果T讀取J在S1中寫入的值,則它也讀取J在S2中寫入的值。

  • 如果T在S1中對資料值執行最終寫入,則它也在S2中對資料值執行最終寫入。

衝突等價

如果兩個排程具有以下屬性,則它們將發生衝突:

  • 兩者都屬於單獨的事務。
  • 兩者都訪問相同的資料項。
  • 至少其中一個是“寫”操作。

如果且僅當以下條件成立時,具有多個包含衝突操作的事務的兩個排程才被稱為衝突等價:

  • 兩個排程包含相同的交易集。
  • 兩個排程都保持衝突操作對的順序。

**注意**——檢視等價排程是檢視可序列化的,衝突等價排程是衝突可序列化的。所有衝突可序列化排程也是檢視可序列化的。

事務的狀態

資料庫中的事務可以處於以下狀態之一:

Transaction States
  • **活動**——在此狀態下,正在執行事務。這是每個事務的初始狀態。

  • **部分提交**——當事務執行其最終操作時,據說它處於部分提交狀態。

  • **失敗**——如果資料庫恢復系統進行的任何檢查失敗,則事務被認為處於失敗狀態。失敗的事務不能再繼續進行。

  • **中止**——如果任何檢查失敗並且事務已達到失敗狀態,則恢復管理器將撤消其在資料庫上的所有寫操作,以將資料庫恢復到事務執行之前的原始狀態。處於此狀態的事務稱為中止。資料庫恢復模組可以在事務中止後選擇兩個操作之一:

    • 重新啟動事務
    • 終止事務
  • **提交**——如果事務成功執行了所有操作,則稱其已提交。其所有影響現在都永久地建立在資料庫系統上。

DBMS - 併發控制

在可以同時執行多個事務的多程式設計環境中,控制事務的併發性非常重要。我們有併發控制協議來確保併發事務的原子性、隔離性和可序列化。併發控制協議可以大致分為兩類:

  • 基於鎖的協議
  • 基於時間戳的協議

基於鎖的協議

配備基於鎖的協議的資料庫系統使用一種機制,透過該機制,任何事務在獲取適當的鎖之前都不能讀取或寫入資料。鎖有兩種:

  • **二元鎖**——資料項上的鎖可以處於兩種狀態;它要麼被鎖定,要麼未鎖定。

  • **共享/排他**——這種型別的鎖定機制根據其用途區分鎖。如果獲取資料項上的鎖以執行寫操作,則它是排他鎖。允許多個事務寫入相同的資料項將導致資料庫進入不一致的狀態。讀取鎖是共享的,因為沒有更改任何資料值。

有四種類型的鎖定協議可用:

簡單的鎖定協議

簡單的基於鎖的協議允許事務在執行“寫”操作之前獲取每個物件上的鎖。事務可以在完成“寫”操作後解鎖資料項。

預宣告鎖定協議

預宣告協議評估其操作並建立一個需要鎖定的資料項列表。在開始執行之前,事務會事先向系統請求它需要的所有鎖。如果所有鎖都被授予,則事務執行並在所有操作完成後釋放所有鎖。如果所有鎖都沒有被授予,則事務回滾並等待直到所有鎖都被授予。

Pre-claiming

兩階段鎖定 2PL

此鎖定協議將事務的執行階段分為三個部分。在第一部分,當事務開始執行時,它會請求它所需的鎖的許可。第二部分是事務獲取所有鎖的地方。一旦事務釋放其第一個鎖,第三階段就開始了。在此階段,事務不能要求任何新的鎖;它只釋放獲取的鎖。

Two Phase Locking

兩階段鎖定有兩個階段,一個是**增長**階段,其中所有鎖都由事務獲取;第二個階段是收縮階段,其中事務持有的鎖被釋放。

要宣告排他(寫)鎖,事務必須首先獲取共享(讀)鎖,然後將其升級為排他鎖。

嚴格的兩階段鎖定

嚴格-2PL的第一階段與2PL相同。在第一階段獲取所有鎖後,事務繼續正常執行。但與2PL相反,嚴格-2PL不會在使用後釋放鎖。嚴格-2PL持有所有鎖直到提交點,並在同一時間釋放所有鎖。

Strict Two Phase Locking

嚴格-2PL 沒有像 2PL 那樣的級聯中止。

基於時間戳的協議

最常用的併發控制協議是基於時間戳的協議。此協議使用系統時間或邏輯計數器作為時間戳。

基於鎖的協議在執行時管理事務之間衝突對的順序,而基於時間戳的協議在建立事務時就開始工作。

每個事務都有一個與其關聯的時間戳,並且排序由事務的年齡決定。在0002時鐘時間建立的事務將比其後所有其他事務都舊。例如,任何在0004進入系統的交易“y”都年輕兩秒,並且優先順序將給予較舊的交易。

此外,每個資料項都會獲得最新的讀取和寫入時間戳。這使系統能夠知道上次對資料項執行“讀取和寫入”操作的時間。

時間戳排序協議

時間戳排序協議確保事務在其衝突的讀取和寫入操作中的可序列化。這是協議系統負責確保衝突的任務對應根據事務的時間戳值執行。

  • 事務Ti的時間戳表示為TS(Ti)。
  • 資料項X的讀取時間戳表示為R-timestamp(X)。
  • 資料項X的寫入時間戳表示為W-timestamp(X)。

時間戳排序協議的工作原理如下:

  • 如果事務Ti發出read(X)操作:

    • 如果TS(Ti) < W-timestamp(X)
      • 操作被拒絕。
    • 如果TS(Ti) >= W-timestamp(X)
      • 操作執行。
    • 所有資料項時間戳更新。
  • 如果事務Ti發出write(X)操作:

    • 如果TS(Ti) < R-timestamp(X)
      • 操作被拒絕。
    • 如果TS(Ti) < W-timestamp(X)
      • 操作被拒絕,並且Ti回滾。
    • 否則,執行操作。

Thomas 寫規則

此規則規定,如果 TS(Ti) < W-timestamp(X),則操作被拒絕,並且 Ti 回滾。

時間戳排序規則可以修改以使排程檢視可序列化。

與其讓 Ti 回滾,不如忽略“寫”操作本身。

DBMS - 死鎖

在多程序系統中,死鎖是在共享資源環境中出現的一種不希望出現的情況,其中一個程序無限期地等待另一個程序持有的資源。

例如,假設有一組事務 {T0, T1, T2, ...,Tn}。T0 需要資源 X 來完成其任務。資源 X 由 T1 持有,而 T1 正在等待資源 Y,該資源由 T2 持有。T2 正在等待資源 Z,該資源由 T0 持有。因此,所有程序都等待彼此釋放資源。在這種情況下,沒有一個程序能夠完成其任務。這種情況稱為死鎖。

死鎖對系統不利。如果系統陷入死鎖,則參與死鎖的事務將被回滾或重新啟動。

死鎖預防

為了防止系統中出現任何死鎖情況,DBMS 會積極檢查所有事務即將執行的操作。DBMS 會檢查這些操作並分析它們是否會造成死鎖情況。如果發現可能發生死鎖情況,則永遠不允許執行該事務。

有一些死鎖預防方案使用事務的時間戳排序機制來預先確定死鎖情況。

等待-死亡方案

在這種方案中,如果一個事務請求鎖定一個資源(資料項),而該資源已被另一個事務以衝突鎖持有,則可能發生以下兩種情況之一:

  • 如果 TS(Ti) < TS(Tj) - 即請求衝突鎖的事務 Ti 比 Tj 舊 - 則允許 Ti 等待,直到資料項可用。

  • 如果 TS(Ti) > TS(tj) - 即 Ti 比 Tj 新 - 則 Ti 死亡。Ti 稍後以隨機延遲重新啟動,但使用相同的timestamp。

此方案允許較舊的事務等待,但會終止較新的事務。

傷害-等待方案

在這種方案中,如果一個事務請求鎖定一個資源(資料項),而該資源已被另一個事務以衝突鎖持有,則可能發生以下兩種情況之一:

  • 如果 TS(Ti) < TS(Tj),則 Ti 強制 Tj 回滾 - 即 Ti 傷害 Tj。Tj 稍後以隨機延遲重新啟動,但使用相同的timestamp。

  • 如果 TS(Ti) > TS(Tj),則 Ti 被迫等待,直到資源可用。

此方案允許較新的事務等待;但是,當較舊的事務請求較新的事務持有的項時,較舊的事務會強制較新的事務中止並釋放該項。

在這兩種情況下,後來進入系統的交易都會被中止。

死鎖避免

中止事務並非總是實用方法。相反,可以使用死鎖避免機制來提前檢測任何死鎖情況。“等待圖”等方法可用,但它們僅適用於那些事務輕量級且資源例項較少的系統。在龐大的系統中,死鎖預防技術可能效果更好。

等待圖

這是一種簡單的可用方法,用於跟蹤是否可能出現任何死鎖情況。對於進入系統的每個事務,都會建立一個節點。當事務 Ti 請求對某個專案(例如 X)進行鎖定,而該專案由另一個事務 Tj 持有時,就會從 Ti 到 Tj 建立一條有向邊。如果 Tj 釋放專案 X,則它們之間的邊將被刪除,並且 Ti 會鎖定該資料項。

系統為每個等待其他事務持有的某些資料項的事務維護此等待圖。系統會不斷檢查圖中是否存在任何迴圈。

Wait-for Graph

在這裡,我們可以使用以下兩種方法之一:

  • 首先,不允許任何對已被另一個事務鎖定的專案的請求。這並非總是可行的,並且可能導致飢餓,即事務無限期地等待資料項並且永遠無法獲取它。

  • 第二個選項是回滾其中一個事務。回滾較新的事務並非總是可行的,因為它可能比較舊的事務更重要。藉助某些相對演算法,可以選擇一個要中止的事務。此事務稱為**受害者**,該過程稱為**受害者選擇**。

DBMS - 資料備份

易失性儲存丟失

易失性儲存(如 RAM)儲存所有活動日誌、磁碟緩衝區和相關資料。此外,它還儲存當前正在執行的所有事務。如果這種易失性儲存突然崩潰會發生什麼?它顯然會帶走所有日誌和資料庫的活動副本。這使得恢復幾乎不可能,因為恢復資料所需的一切都丟失了。

在發生易失性儲存丟失的情況下,可以採用以下技術:

  • 我們可以在多個階段設定**檢查點**,以便定期儲存資料庫內容。

  • 易失性記憶體中活動資料庫的狀態可以定期**轉儲**到穩定儲存中,其中可能還包含日誌和活動事務以及緩衝區塊。

  • 每當資料庫內容從非易失性記憶體轉儲到穩定儲存時,都可以在日誌檔案中標記<dump>。

恢復

  • 當系統從故障中恢復時,它可以恢復最新的轉儲。

  • 它可以維護重做列表和撤銷列表作為檢查點。

  • 它可以透過查閱撤銷-重做列表來恢復所有事務的狀態,直到最後一個檢查點。

資料庫備份和災難性故障恢復

災難性故障是指穩定的輔助儲存裝置損壞的情況。隨著儲存裝置的損壞,儲存在其中的所有寶貴資料都將丟失。我們有兩種不同的策略來從這種災難性故障中恢復資料:

  • 遠端備份;此處資料庫的備份副本儲存在遠端位置,以便在發生災難時可以從中恢復。

  • 或者,可以在磁帶上進行資料庫備份,並將其儲存在更安全的地方。此備份以後可以傳輸到新安裝的資料庫中,以將其恢復到備份點。

成熟的資料庫過於龐大,無法頻繁備份。在這種情況下,我們有一些技術,我們可以僅透過檢視其日誌來恢復資料庫。因此,我們在這裡需要做的就是定期備份所有日誌。資料庫可以每週備份一次,而日誌非常小,可以每天或儘可能頻繁地備份。

遠端備份

如果資料庫所在的主要位置遭到破壞,遠端備份可以提供安全感。遠端備份可以是離線、即時或線上的。如果它是離線的,則手動維護。

Remote Data Backup

線上備份系統更即時,並且是資料庫管理員和投資者的救星。線上備份系統是一種機制,其中每個即時資料位都會同時在兩個不同的位置備份。其中一個直接連線到系統,另一個作為備份儲存在遠端位置。

一旦主資料庫儲存失敗,備份系統就會感知到故障並將使用者系統切換到遠端儲存。有時這非常迅速,以至於使用者甚至意識不到故障。

DBMS - 資料恢復

崩潰恢復

DBMS 是一個高度複雜的系統,每秒執行數百個事務。DBMS 的永續性和魯棒性取決於其複雜的架構及其底層硬體和系統軟體。如果它在事務過程中發生故障或崩潰,則預計系統將遵循某種演算法或技術來恢復丟失的資料。

故障分類

為了檢視問題發生在哪裡,我們將故障概括為以下幾個類別:

事務失敗

當事務無法執行或到達無法繼續執行的點時,它必須中止。這稱為事務失敗,其中只有少數事務或程序受到影響。

事務失敗的原因可能是:

  • **邏輯錯誤** - 事務由於存在一些程式碼錯誤或任何內部錯誤條件而無法完成。

  • **系統錯誤** - 資料庫系統本身終止活動事務,因為 DBMS 無法執行它,或者它必須由於某些系統條件而停止。例如,在死鎖或資源不可用時,系統會中止活動事務。

系統崩潰

存在一些外部問題可能導致系統突然停止並導致系統崩潰。例如,電源中斷可能導致底層硬體或軟體故障。

示例可能包括作業系統錯誤。

磁碟故障

在技術發展的早期,硬碟驅動器或儲存驅動器經常出現故障,這是一個常見問題。

磁碟故障包括壞扇區的形成、無法訪問磁碟、磁碟磁頭損壞或任何其他導致所有或部分磁碟儲存損壞的故障。

儲存結構

我們已經描述了儲存系統。簡而言之,儲存結構可以分為兩類:

  • 易失性儲存器 −顧名思義,易失性儲存器無法在系統崩潰後保留資料。易失性儲存裝置放置在非常靠近CPU的位置;通常它們嵌入到晶片組本身。例如,主儲存器和快取儲存器是易失性儲存器的例子。它們速度很快,但只能儲存少量資訊。

  • 非易失性儲存器 −這些儲存器能夠在系統崩潰後保留資料。它們的資料儲存容量很大,但訪問速度較慢。示例可能包括硬碟、磁帶、快閃記憶體和非易失性(電池備份)RAM。

恢復和原子性

當系統崩潰時,可能有多個事務正在執行,並且為它們打開了各種檔案以修改資料項。事務由各種操作組成,這些操作本質上是原子的。但根據DBMS的ACID特性,必須維護事務整體的原子性,即要麼所有操作都執行,要麼都不執行。

當DBMS從崩潰中恢復時,它應該維護以下內容:

  • 它應該檢查所有正在執行的事務的狀態。

  • 事務可能處於某個操作的中間;在這種情況下,DBMS必須確保事務的原子性。

  • 它應該檢查事務現在是否可以完成,或者是否需要回滾。

  • 不允許任何事務使DBMS處於不一致的狀態。

有兩種型別的技術可以幫助DBMS恢復以及維護事務的原子性:

  • 維護每個事務的日誌,並在實際修改資料庫之前將其寫入某個穩定儲存中。

  • 維護影子分頁,其中更改在易失性儲存器上進行,稍後更新實際資料庫。

基於日誌的恢復

日誌是一系列記錄,維護事務執行的操作記錄。重要的是,日誌在實際修改之前寫入並存儲在穩定的儲存介質上,該介質是故障安全的。

基於日誌的恢復的工作原理如下:

  • 日誌檔案儲存在穩定的儲存介質上。

  • 當事務進入系統並開始執行時,它會寫入關於它的日誌。

<Tn, Start>
  • 當事務修改專案X時,它會按如下方式寫入日誌:

<Tn, X, V1, V2>

它讀取Tn已將X的值從V1更改為V2

  • 當事務完成時,它記錄:
<Tn, commit>

可以使用兩種方法修改資料庫:

  • 延遲資料庫修改 −所有日誌都寫入穩定儲存,並在事務提交時更新資料庫。

  • 立即資料庫修改 −每個日誌都跟隨實際的資料庫修改。也就是說,在每次操作之後立即修改資料庫。

併發事務的恢復

當多個事務並行執行時,日誌會交錯。在恢復時,恢復系統很難回溯所有日誌,然後開始恢復。為了簡化這種情況,大多數現代DBMS使用“檢查點”的概念。

檢查點

即時和真實環境中保留和維護日誌可能會耗盡系統中所有可用的記憶體空間。隨著時間的推移,日誌檔案可能會變得太大而無法處理。檢查點是一種機制,它會從系統中刪除所有以前的日誌並將其永久儲存在儲存磁碟中。檢查點宣告一個點,在此之前DBMS處於一致狀態,並且所有事務都已提交。

恢復

當具有併發事務的系統崩潰並恢復時,它會以以下方式執行:

Recovery
  • 恢復系統從最後到最後一個檢查點的末尾反向讀取日誌。

  • 它維護兩個列表,一個撤消列表和一個重做列表。

  • 如果恢復系統看到一個帶有<Tn, Start>和<Tn, Commit>或僅<Tn, Commit>的日誌,則它將事務放入重做列表中。

  • 如果恢復系統看到一個帶有<Tn, Start>但未找到提交或中止日誌的日誌,則它將事務放入撤消列表中。

然後撤消撤消列表中的所有事務並刪除其日誌。重做列表及其先前日誌中的所有事務將被刪除,然後在儲存其日誌之前重新執行。

廣告