如何實現邏輯數據模型

2024-07-21 02:35:45

字體：大中小

來源：轉載

供稿：網友

　　業務和系統開發領域絕對不能容許設計上的重大失誤。可是，很多開發人員卻因為不了解設計步驟而恰恰輕視乃至完全忽略了整個設計過程。而實際上，我們中的大多數人也確實缺乏必要的有關技能和知識，結果令我們往往“旁路”了項目開發中最重要的階段。說真的，有本事敢直接繞過設計階段的人還沒誕生呢。
　　
　　
　　
　　假如我們不花點時間創建一個邏輯模型，那么要實現一套高效和優秀的設計是完全不可能的。略過設計步驟會產生大量的錯誤，而這些錯誤又會令我們耗費大量的時間在發現它們的時候反復調試和糾正。下面我就大致討論下設計的邏輯和物理模型，然后引領讀者經過邏輯模型的創建全過程。本文是有關主題系列的開篇，在后續的第2部分里，我會根據已經發現的缺陷修改我們的原始設計。
　　
　　
　　數據庫的設計方法
　　在對數據庫項目的需求著手評估和分析周，接下來的一步就是設計出一套方案幫助你達到項目的要求和目標。在開發領域這一步驟被稱做數據庫設計方法。它是一種結構化的措施，支持設計流程同時還包括了諸如公司業務流程、規定和文檔等一系列工具。步步進階的整套流程幫助開發人員計劃、治理和控制設計及其實現從而高效地完成任務。
　　
　　這意味著，你擁有一整套方法，也就是按照特定順序安排的項目列表，這些方法指引你經過數據模型創建的全過程。請不要錯誤地把這個過程理解為平常的過程，實際上它是完全必要的階段。你應該從完全理解數據和用戶需求這一目的出發研究該過程。
　　
　　每一個項目無論其規模大小都能從以下三種模型中獲益：
　　
　　概念：明確和說明創建數據全局視圖的主要對象，同時輔以一定的稍微細節。許多企業都局限于特定的數據庫治理系統（DBMS），所以這一步可以忽略或者放到邏輯模型一組。
　　邏輯：構造采用特定數據的模型，但還不用考慮最終保存數據以及運營應用程序的具體數據庫系統。由于SQL Server是一種關系型數據庫治理系統（RDBMS），所以我們要依靠于實體關系模型（ER：Entity-Relationship）。在這一階段你必須明確實體、關系、屬性并對你的數據實行規格化。邏輯模型建立在數據集合的基礎之上。為了更深入地了解ER模型，不不妨訪問下 ITS數據庫服務網站或者參考。
　　物理：根據所采用的具體RDBMS設計實現邏輯模型的具體模型。在這一階段，你需要說明數據表、索引等數據庫對象，而物理模型就是根據數據表建立的。
　　建立邏輯模型的真實用意無非是為了確認應用程序能滿足最終的需求（包括輸入和輸出兩方面）。換句話說，邏輯模型必須能產生所有已知的報告、查詢等結果。此外，用戶還應該能夠以合理的方式輸入和操作數據。一旦邏輯模型到位，你就應開始把你所了解的情況應用到項目的物理需求方面——比如說——物理模型。圖A就描述了邏輯和物理模型在這一階段的差別。
　　
　　圖A
　　　如何實現邏輯數據模型（圖一）

　　邏輯和物理數據模型
　　邏輯模型的實現
　　
　　目前階段的所謂“實現”其實就是完成邏輯模型的組件。在明確了實體、關系和屬性的情況下，你應該揭示出那些在工作環境下可能會產生問題的缺陷：
　　
　　缺少的實體
　　表示同一概念實體的多個實體
　　需要額外實體來解決問題的多對多關系
　　多值和冗余的屬性
　　
　　
　　現在我們就以一個實際項目為例看看該如何創建一個合理的邏輯模型，通過這個模型幫助你避免今后的問題。假設你的這個最新項目是供旅行社使用的、一項足夠簡單、處理定單的數據庫應用程序，這家旅行社針對4類客戶實行批發或者零售服務：
　　
　　Agency：授權接受定單上任務的另一家旅行社。
　　Aggregator：一家俱樂部，其成員可以享受打折服務。
　　Corporate：代表其職員下定單的公司。它們不能享受的打折優不過需要獲得旅行社的全方位服務支持。比如說，旅行社必須幫助它們解決一些諸如取消計劃、飛機票訂位過多等方面的問題。企業客戶總是一樣的而旅行者只能是其職員。
　　Retail：不能享受任何折扣優惠的單獨客戶。
　　這時，你應該預備定義應用程序的主要對象或者實體。為了針對客戶類型應用以上的業務規則，你可能會把每一種客戶類型當作單獨的實體，如表A所示。數據類型和其他信息都是針對SQL Server考慮的。
　　
　　表A
　　　如何實現邏輯數據模型（圖二）

　　定義應用實體
　　
　　
　　
　　看圖B，你可以簡化當前的模型：
　　
　　客戶訂單。
　　某種特定類型的客戶。
　　圖B
　　如何實現邏輯數據模型（圖三）

　　不同實體之間的關系
　　
　　正如我們在上面所提到的那樣，業務規則要求我們對客戶實現區別對待。結果，客戶不能總是具有同樣的屬性。我們的第1個解決方案是創建一個數據表，其中包含了各類客戶的特定屬性。這一原始設計帶來了下列問題：
　　
　　所有的客戶數據表都采用系統生成的主鍵，大致以種子值1開始遞增。那就是說，你完全會遭遇重復的ClientID值。結果我們就無法恰當地把每一定單關聯到特定的客戶，因為每一客戶表都包含了重復的值。
　　因為每一客戶表重復公共字段（如ClientID、ClientName、Address和Telephone）而產生了一些冗余的屬性。
　　客戶會有更多的地址嗎？也許他們會具有一個當地地址和一個付費的單位地址。
　　客戶只有一個電話號碼？也許你應該列出多個電話號碼乃至傳真號碼。
　　有必要根據客戶的類型來標識定單嗎？顯然你不能。

　　找出和解決設計問題
　　
　　你首先采取的行動可能和我們用的不同，但那還不是要害的問題。最重要的是你可能沒有熟悉的到設計中隱藏的問題。在后續的文章里我會采用已知的、業已得到證實的方法來尋找和解決設計問題，免得它們在今后的工作中引出不少漏子。

上一篇：Linux下架設FTP

下一篇：學習Linux的七點忠告