1.1 簡介
設計數據庫有點類似於設計 Java 項目的架構。您可以將所有數據放在幾個表中，或者您可以從模式和數十個表構建一個漂亮的數據結構。
以下是開發人員在設計數據庫時通常面臨的任務：
- 確保所有必要的信息都存儲在數據庫中。
- 確保獲得有關所有必要請求的數據的可能性。
- 減少數據的冗餘和重複。
- 確保數據庫完整性
- 數據訪問速度優化
要記住的主要事情是你不能建立一個理想的數據庫結構，因為。它和您的代碼一樣，也會不斷變化。設計數據庫結構時應牢記三點：
- 結構必須足夠好。
- 凡事必有其人能看得懂的邏輯。
- 過早的優化是萬惡之源。
你不必做出世界上最好的數據庫結構。她還是會變的。你的任務是確保在對數據庫結構進行 20 次更改後，很容易弄清楚。
很可能在您工作的頭幾年，沒有人會信任您從頭開始設計基地。您將對現有架構進行更改。你需要試著了解它是根據什麼原則安排的並遵守它們。有了他們的憲章，他們就不會爬進別人的修道院。
除非有必要，否則不要優化數據庫。如果表只有幾百行，那麼 DBMS 很可能會將其保存在內存中並緩存對它的查詢。
另一方面，您應該能夠將重要請求的工作速度提高數十倍甚至數百倍。如果您知道該怎麼做，那就太好了。他們在高中一年級怎麼說？“忘掉你在學校學到的一切……”
如果你知道什麼是數據庫規範化，那麼我趕緊取悅你，在你的工作中你很可能會處理反規範化。對於項目的避難所來說，沒有什麼比數據庫的速度更重要了。而且，如果為了加快從數據庫中選擇數據的速度，您需要將 200（！）個表合併為一個（具有巨大的冗餘），您將不得不這樣做。
1.2 圖書館設計
讓我們深入探討一下主題領域，並使用像典型圖書圖書館一樣簡單的東西來思考數據庫設計。
任何圖書館的主要任務都是圖書基金的處理。很容易區分三個主要的系統用戶組：讀者、圖書管理員、管理員。每個活動都顯示在用例圖中。
現在已經可以區分未來數據庫的一些實體和關係：
這種做法，不清楚如何將讀者與書聯繫起來（讀者在“發行/接收”關係中沒有實體。如果書有幾本，那麼它可以發行給幾個讀者。甚至如果一本書被理解為一本，那麼在保存在當前讀者的書目表中時，將無法獲得誰（以及多少次）之前拿過這本書的信息。
解決方案可能是引入一個額外的實體——發行書籍的卡片。將書發給讀者時，會製作一張卡片，將書交給讀者時，會在上面打上相應的標記。在這些卡片的幫助下，確定每個用戶的債務併計算書籍使用的統計數據。讀者在預訂文獻時，也會啟動一張卡片，如果在一定時間內，讀者沒有取走所預訂的文獻，卡片就會被銷毀。讀者可以預訂的書籍數量是有限制的。
選擇文獻時，用戶可以查看文獻目錄，並可以按作者、標題、出版年份篩選搜索結果。
可以計算圖書館所有書籍的統計數據，以及給定時間段內書籍的發行數量。您還可以設置執行計算的書籍實例的最小數量。根據這些統計數據，未使用的書籍已從圖書館註銷。
可以區分主題領域的以下主要實體：
- 用戶（圖書館員和管理員）；
- 讀者;
- 閱覽室;
- 書;
- 圖書發行卡；
- 預訂卡。
修改後的數據庫ER圖如圖所示。
根據圖 1 所示的用例，數據庫應執行以下查詢（並非詳盡列表）：
- 顯示符合指定條件的圖書；
- 顯示持有未按時關閉的發書卡的用戶（圖書管理員正在尋找欠款人）；
- 顯示給定用戶的借書卡對應的所有未及時關閉的圖書（用戶來圖書館借新書——你需要查看他是否是藉書人並通知他）；
- 刪除超過 N 秒前創建的所有預訂卡；
- 顯示指定用戶未關閉的圖書預訂卡對應的所有圖書（讀者訂購圖書並來到圖書館取閱 - 圖書管理員需要獲得此列表才能將其分發）。
1.3 模式形成
要形成數據模式，您必須首先用實體的詳細信息補充 ER 圖（對其進行細化）。有時，與此同時，在構建 ER 圖時可能會發現錯誤——在這個任務中，發現這本書需要“以某種方式”與圖書館大廳相連。
這可以通過在書中放置必要的“大廳編號”來完成，但是，使用這種方法，同一本書將不得不在數據庫中被描述多次（如果它出現在不同的大廳）。更正確的做法是引入一個額外的實體“book placement”。該圖顯示了一個添加了實體和道具的 ER 圖。
上面的ER圖反映了主要的表、關係和屬性，在此基礎上可以構建數據庫模型。ER圖沒有標準，但是有很多符號（Chen，IDEFIX，Martin等），但是領域模型的標準和符號都找不到。然而，在構建這樣的圖表的過程中，關鍵字段（外部和內部）必須突出顯示，有時是索引和數據類型。
在這種情況下，在下圖中：
- 對於鏈接，使用 Martin 符號（使用“魚尾紋”）；
- 表格顯示為分為 3 個部分的矩形：
- 表名；
- 內部鍵（用標記標記）；
- 其餘字段，而必填字段則標有標記。
在開發這個模型時，希望將管理員表與圖書館員表連接起來——添加用戶表，但是：
- 管理員與特定房間沒有關聯（您必須在相應字段中填寫空值）；
- 這可能會使訪問權限的分配變得複雜 - 現在只有數據庫管理員（通過特殊的 DBMS 面板工作並且在正在開發的系統中沒有帳戶）可以訪問管理員表。但是，在連接表時，用戶查詢需要訪問新表。
在構建此圖時，發現並更正了 ER 圖中的一個缺陷 - 添加了一張librarians_rooms將圖書管理員和大廳聯合起來的表格。這是必要的，因為一個圖書館員可以在幾個房間工作，但幾個圖書館員可以在同一個房間工作。
在設計數據庫的時候，你至少應該能像上面的例子那樣推理。如果您認為自己成功了，那麼讓我們走得更遠：甚至更多的理論。