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
將圖書管理員和大廳聯合起來的表格。這是必要的,因為一個圖書館員可以在幾個房間工作,但幾個圖書館員可以在同一個房間工作。
在設計數據庫的時候,你至少應該能像上面的例子那樣推理。如果您認為自己成功了,那麼讓我們走得更遠:甚至更多的理論。
GO TO FULL VERSION