資料庫系統由一個互相關聯的資料的集合和一組用以訪問這些資料的程式組成。這個資料的集合通常被稱為資料庫。
主要目的：方便、高效地對共享資料有效的組織、管理和存取。

檔案系統

早期使用檔案系統管理大量的資料（將資料儲存在多個檔案中），但在使用中發現以下問題：

• (1) 無法判斷資料是否冗餘
  同一資料可能儲存在多個獨立的檔案中（比如檔案和程式是在很長的一段時間內，由不同的程式設計師建立），這種冗餘除了導致儲存和訪問開銷增大外，還可能導致資料不一致（同一資料的不同副本不一致）問題。
• (2) 資料訪問困難
  傳統的檔案處理環境不支援以一種方便而高效的方式去獲取所需的資料，需要開發通用的、能對變化的需求做出更快反應的資料檢索系統。
• (3) 資料孤立
  資料分散在多個檔案，無法統一規範檔案的格式，可能需要編寫多套程式碼去讀取不同型別檔案裡的資料。
• (4) 資料完整性問題
  資料庫儲存的資料必須滿足某些特定的一致性約束（如非空約束、唯一性約束、範圍約束等等），對於檔案系統，只能在程式中強制執行某些約束。使用檔案系統，會使約束的處理變得麻煩起來。
• (5) 原子性問題
  計算機系統也會存在故障，一旦故障發生，資料就應被恢復到故障發生之前的一致狀態。如對某應用來說，需要將A賬戶餘額中的500元轉到B賬戶餘額中。假如A賬戶的餘額減去500元，但B賬戶的餘額還未除錯時，系統發生故障，這將會造成資料庫狀態的不一致。為保證資料庫的一致性，上述兩個操作必須是要麼都發生，要麼都不發生。在傳統的檔案系統中，保持原子性是很難做到的。
• (6) 併發訪問異常
  為提高系統的總體效能以及加快響應速度，許多系統允許多個使用者同時更新資料。在這樣的情況下，併發的更新操作可能相互影響，有可能導致資料的不一致。如A賬戶有1000元，使用者1和使用者2同時分別向該賬戶存入200元和300，那麼A賬戶的餘額既不應該是1200，也不是1300，而是1500。為了消除這種情況發生的可能性，系統必須進行某種形式的管理。但，由於資料可能被多個不同的應用程式訪問，且程式之間事先並沒有協調，必須在檔案系統層面給出處理，但檔案系統在這方面的處理不是很好。
• (7) 安全性問題
  訪問資料時，不同型別的使用者僅能訪問與之相關的資料，而不是所有資料。檔案系統對許可權管理方面還需要加強。

資料檢視

資料庫系統的一個主要目的是給使用者提供資料的抽象檢視，也就是說，系統隱藏關於資料儲存和維護的某些細節。

資料抽象(data abstraction)

一個可用的系統必須能高效地檢索資料。這種高效性的需求促使資料庫設計者使用複雜的資料結構來表示資料。同時，為簡化使用者與系統的互動，系統開發人員通過分層抽象，對使用者遮蔽複雜性。
資料抽象是指，只向外界提供關鍵資訊，並隱藏其後臺的實現細節，即只表現必要的資訊而不呈現細節。資料抽象是一種依賴於介面和實現分離的技術。
讓我們舉一個現實生活中的真例項子，比如一臺電視機，您可以開啟和關閉、切換頻道、調整音量、新增外部元件（如喇叭、錄影機、DVD 播放器），但是您不知道它的內部實現細節，也就是說，您並不知道它是如何通過纜線接收訊號，如何轉換訊號，並最終顯示在螢幕上。
因此，我們可以說電視把它的內部實現和外部介面分離開了，您無需知道它的內部實現原理，直接通過它的外部介面（比如電源按鈕、遙控器、聲量控制器）就可以操控電視。
資料抽象技術應用到不同的領域，其抽象層次是不同的。資料庫的資料抽象分為三個層次：
(1) 物理層
最低層次的抽象，描述資料實際上的怎樣儲存的。物理層詳細描述複雜的底層資料結構。
(2) 邏輯層
比物理層層次稍高的抽象，描述資料庫中儲存何種資料，以及這些資料存在什麼關係。這樣邏輯層就可以通過少量相對簡單的結構描述整個資料庫。雖然邏輯層的簡單結構實現可能涉及複雜的物理層結構，但邏輯層的使用者不必知道這樣的複雜性。這稱作物理資料獨立性（physical data independence）。（分層的價值）
(3) 檢視層
最高層次的抽象，只描述整個資料庫的某個部分。儘管在邏輯層使用了比較簡單的結構，但由於一個大型資料庫所儲存資訊的多樣性，仍存在一定程度的複雜性。
資料庫資料抽象的三個層次圖示如下：

在物理層，資料可能被描述為連續儲存位置組成的儲存塊。編譯器為資料庫程式設計人員遮蔽了這一層的細節。與此類似，資料庫系統為資料庫程式設計人員遮蔽許多最底層的儲存細節。
在邏輯層，資料通過型別定義進行描述。與此同時，在邏輯層還要定義這些資料型別的相關關係。程式設計人員正是在這個抽象層次上使用某種程式設計語言進行工作。
在檢視層，計算機使用者看見的是為其遮蔽了資料型別細節的一組應用程式。檢視層定義了資料庫的多個檢視，資料庫使用者看到的就是這些檢視。除了遮蔽資料庫的邏輯層細節外，檢視還提供了防止使用者訪問資料庫的某部分安全性機制。（許可權控制）

模式

資料庫的總體設計稱作資料庫模式（schema）。資料庫系統可以分為幾種不同的模式。物理模式（physical schema，也稱內模式）在物理層描述資料庫的設計，而邏輯模式（logical schema，也稱概念模式）則在邏輯層描述資料庫的設計。資料庫在檢視層也有幾種模式，有時稱為子模式（subschema，也稱外模式）。資料庫模式和資料抽象關係圖如下：

兩種資料獨立性

(1) 物理資料獨立性
由內模式與概念模式之間的對映實現。物理資料獨立性是指當資料庫的內模式發生改變時，資料的邏輯結構不變，從而使用者編寫的應用程式可以不變。
(2) 邏輯資料獨立性
由概念模式與外模式之間的對映實現。邏輯資料獨立性是指當概念資料庫模式發生改變時，資料庫的外模式不變，從而建立在外模式上的應用程式不需要修改。

資料模型

資料模型是一種描述資料、資料聯絡、資料語義以及一致性約束的概念工具的集合。資料模型提供了一種描述物理層、邏輯層以及檢視層資料庫設計的方式。目前，主流資料模型主要有四類：

• (1) 關係模型
  關係模型用表的集合來表示資料和資料間的聯絡。關係模型是基於記錄的模型的一種。
• (2) 實體-聯絡模型
  實體-聯絡（Entity-Relation）資料模型基於對現實世界的這樣一種認知：現實世界由一組稱作實體的基本物件以及這些物件間的聯絡構成。實體-聯絡模型廣泛用於資料庫設計。
• (3) 基於物件的資料模型
  物件導向設計已經成為占主導地位的軟體開發方法。這導致了物件導向資料模型的發展。物件導向模型可以看做E-R模型增加了封裝、方法（函式）和物件標識等概念後的擴充套件。
• (4) 半結構化資料模型
  半結構化資料模型允許相同型別的資料項含有不同的屬性集的資料定義。之前介紹的三種資料模型，所有資料項都必須具有相同的屬性集。如XML、JSON、YAML等。

資料庫設計

資料庫系統被設計用來管理大量的資訊。資料庫設計的主要內容是資料庫模式的設計。高層的資料模型為資料庫設計者提供了一個概念框架，去說明資料庫使用者的資料需求，以及將怎樣構造資料庫結構以滿足這些需求。因此，資料庫設計的初始階段是全面刻畫預期的資料庫使用者的資料需求。這個階段的成果是指定出使用者需求的規格文件（使用者需求說明書，明確需要提供哪些功能）。
下一步，在概要設計階段，資料庫設計者需要選擇一個資料模型（如關係模型、實體-聯絡模型等），並運用該選定的資料模型的概念，將需求轉換成一個資料庫的概念模式。從關係模型的角度來看，概念設計階段涉及決定資料庫中應包含哪些屬性，以及如何將這些屬性組織到多個表中。解決這個問題有兩種方法：一種是使用實體-聯絡模型，另一種是引入一套演算法，這套演算法將所有屬性集作為輸入，生成一組關係表。在這個階段，資料設計者可以對模式進行復審，確保它滿足功能需求。
接著，在邏輯設計階段，資料庫設計者將高層的概念模式對映到要使用的資料庫系統的實現資料模型（如關係模型）上；然後設計者將得到的特定於系統的資料庫模式用到物理設計階段。在這個階段，指定資料庫的物理特性，這些特性包括檔案組織形式以及內部的儲存結構。

規範化

設計關聯式資料庫需要用到的另外一種方法是通常稱為規範化的過程。它的目標是生成一個關係模式集合，使我們儲存資訊時，沒有不必要的冗餘，同時又能輕鬆地檢索資料。這種方法是設計一種符合適當的正規化（normal form）的模式。
規範化的詳盡理論已經研究形成，它有助於形式化地定義什麼樣的資料庫是不好的，以及如何得到我們想要的設計。

資料庫體系結構

一個資料庫系統各個部分以及它們之間的聯絡如下圖所示：

資料庫系統的體系結構很大程度取決於資料庫系統所執行的計算機系統。資料庫系統可以是集中式的、客戶/伺服器式的(一臺伺服器為多個客戶機執行任務)，也可以針對平行計算機體系結構設計資料庫系統；分散式資料庫包含地理上分離的多臺計算機。
現今，資料庫系統的大多數使用者並不直接面對資料庫系統，而是通過網路與其連線。資料庫應用也由兩層體系結構過渡到三層體系結構：

資料探勘和資訊檢索

資料探勘（Data Mining）指半自動地分析大型資料庫並從中找出有用的模式的過程。資料探勘是在資料庫中發現知識。
為在各式各樣的資料上高效地執行查詢，企業建立了資料倉儲（Data Warehouse）。資料倉儲從多個來源收集資料，建立統一的模式，駐留在單個節點上。於是，就為使用者提供了單個統一的資料介面。
文字資料也爆炸式增長。文字資料是非結構化的，與關聯式資料庫中嚴格的結構化資料不同。查詢非結構化的文字資料被稱為資訊檢索（Information Retrieval）。

特種資料庫

除了基於關係模型的關聯式資料庫，還有基於物件模型的物件資料庫、基於半結構化資料的XML等。

參考

https://www.db-book.com/
https://www.runoob.com/cplusplus/cpp-data-abstraction.html
https://blog.csdn.net/zcj18537150970/article/details/105327117