業務和系統開發領域絕對不能容許設計上的重大失誤
可是
很多開發人員卻因為不了解設計步驟而恰恰輕視乃至完全忽略了整個設計過程
而實際上
我們中的大多數人也確實缺乏必要的有關技能和知識
結果令我們往往
旁路
了項目開發中最重要的階段
說真的
有本事敢直接繞過設計階段的人還沒誕生呢
如果我們不花點時間創建一個邏輯模型
那麼要實現一套高效和優秀的設計是完全不可能的
略過設計步驟會產生大量的錯誤
而這些錯誤又會令我們耗費大量的時間在發現它們的時候反復調試和糾正
下面我就大致討論下設計的邏輯和物理模型
然後引領讀者經過邏輯模型的創建全過程
本文是有關主題系列的開篇
在後續的第
部分裡
我會根據已經發現的缺陷修改我們的原始設計
數據庫的設計方法
在對數據庫項目的需求著手評估和分析周
接下來的一步就是設計出一套方案幫助你達到項目的要求和目標
在開發領域這一步驟被稱做數據庫設計方法
它是一種結構化的措施
支持設計流程同時還包括了諸如公司業務流程
規定和文檔等一系列工具
步步進階的整套流程幫助開發人員計劃
管理和控制設計及其實現從而高效地完成任務
這意味著
你擁有一整套方法
也就是按照特定順序安排的項目列表
這些方法指引你經過數據模型創建的全過程
請不要錯誤地把這個過程理解為平常的過程
實際上它是完全必要的階段
你應該從完全理解數據和用戶需求這一目的出發研究該過程
每一個項目無論其規模大小都能從以下三種模型中獲益
概念
明確和說明創建數據全局視圖的主要對象
同時輔以一定的輕微細節
許多企業都局限於特定的數據庫管理系統（DBMS）
所以這一步可以忽略或者放到邏輯模型一組
邏輯
構造采用特定數據的模型
但還不用考慮最終保存數據以及運營應用程序的具體數據庫系統
由於SQL Server是一種關系型數據庫管理系統（RDBMS）
所以我們要依賴於實體關系模型（ER
Entity
Relationship）
在這一階段你必須明確實體
關系
屬性並對你的數據實行規格化
邏輯模型建立在數據集合的基礎之上
為了更深入地了解ER模型
不不妨訪問下 ITS數據庫服務網站 或者參考
Mapping an ER Model to the Relational Model Web site（是一個
PDF文件）
物理
根據所采用的具體RDBMS設計實現邏輯模型的具體模型
在這一階段
你需要說明數據表
索引等數據庫對象
而物理模型就是根據數據表建立的
建立邏輯模型的真實用意無非是為了確認應用程序能滿足最終的需求（包括輸入和輸出兩方面）
換句話說
邏輯模型必須能產生所有已知的報告
查詢等結果
此外
用戶還應該能夠以合理的方式輸入和操作數據
一旦邏輯模型到位
你就應開始把你所了解的情況應用到項目的物理需求方面——比如說——物理模型
圖A就描述了邏輯和物理模型在這一階段的差別
圖A
邏輯和物理數據模型
邏輯模型的實現
目前階段的所謂
實現
其實就是完成邏輯模型的組件
在明確了實體
關系和屬性的情況下
你應該揭示出那些在工作環境下可能會產生問題的缺陷
缺少的實體
表示同一概念實體的多個實體
需要額外實體來解決問題的多對多關系
多值和冗余的屬性
現在我們就以一個實際項目為例看看該如何創建一個合理的邏輯模型
通過這個模型幫助你避免今後的問題
假設你的這個最新項目是供旅行社使用的
一項足夠簡單
處理定單的數據庫應用程序
這家旅行社針對
類客戶實行批發或者零售服務
Agency
授權接受定單上任務的另一家旅行社
Aggregator
一家俱樂部
其成員可以享受打折服務
Corporate
代表其職員下定單的公司
它們不能享受的打折優不過需要獲得旅行社的全方位服務支持
比如說
旅行社必須幫助它們解決一些諸如取消計劃
飛機票訂位過多等方面的問題
企業客戶總是一樣的而旅行者只能是其職員
Retail
不能享受任何折扣優惠的單獨客戶
這時
你應該准備定義應用程序的主要對象或者實體
為了針對客戶類型應用以上的業務規則
你可能會把每一種客戶類型當作單獨的實體
如表A所示
數據類型和其他信息都是針對SQL Server考慮的
表A
定義應用實體
看圖B
你可以簡化當前的模型
客戶訂單
某種特定類型的客戶
圖B
不同實體之間的關系
正如我們在上面所提到的那樣
業務規則要求我們對客戶實現區別對待
結果
客戶不能總是具有同樣的屬性
我們的第
個解決方案是創建一個數據表
其中包含了各類客戶的特定屬性
這一原始設計帶來了下列問題
所有的客戶數據表都采用系統生成的主鍵
大致以種子值
開始遞增
那就是說
你完全會遭遇重復的ClientID值
結果我們就無法恰當地把每一定單關聯到特定的客戶
因為每一客戶表都包含了重復的值
因為每一客戶表重復公共字段（如ClientID
ClientName
Address和Telephone）而產生了一些冗余的屬性
客戶會有更多的地址嗎？也許他們會具有一個當地地址和一個付費的單位地址
客戶只有一個電話號碼？也許你應該列出多個電話號碼乃至傳真號碼
有必要根據客戶的類型來標識定單嗎？顯然你不能
找出和解決設計問題
你首先采取的行動可能和我們用的不同
但那還不是關鍵的問題
最重要的是你可能沒有認識的到設計中隱藏的問題
在後續的文章裡我會采用已知的
業已得到證明的方法來尋找和解決設計問題
免得它們在今後的工作中引出不少漏子
From:http://tw.wingwit.com/Article/program/Oracle/201311/18780.html
