【文章內容簡介】 數據字典 數據流圖 第 1步： 需求調研 第 2步： 概念分析 第 3步： 邏輯設計 確定客戶需要哪些信息，建立哪些應用，常用的操作及對象有哪些等 。 將概念模型映射為某個特定類型的 DBMS模式數據。 數據建模過程 對已經確定的邏輯結構選擇適當的物理結構，包括存儲結構、存取路徑、存儲分配等 。 第 4步： 物理設計 流水作業(yè) 概念 邏輯 物理 業(yè)務 管理 實現 實 體 1屬 性 1屬 性 2實 體 2屬 性 1屬 性 2實 體 4屬 性 1屬 性 2實 體 3屬 性 1屬 性 2數據工作 DFD工作 驗證工作 數據模型 數據流圖 DFD 利用業(yè)務流程校驗功能、屬性、數據流 校驗完善數據模型 校驗完善 DFD 業(yè)務人員或需求工作 業(yè)務事件、信息收集 概念 邏輯 物理 業(yè)務 管理 實現 功能 功能 功能 實體屬性 C R U 實體屬性 R R U 實體屬性 C D C 業(yè)務概念 描述 事件活動 描述 D F D 1 層D F D 0 層P 1數 據 處 理 1數 據 存 儲 2數 據 存 儲 3P 2數 據 處 理 2數 據 存 儲 1數 據 存 儲 4客 戶P 1 .1數 據 處 理 1數 據 存 儲 6數 據 存 儲 2P 1 .2數 據 處 理 1數 據 存 儲 1數 據 存 儲 5數 據 存 儲 7客 戶P 1 .1數 據 處 理 1數 據 存 儲 6數 據 存 儲 3P 2 .2數 據 處 理 1數 據 存 儲 8數 據 存 儲 4數 據 存 儲 2人員 Who 范圍分析 What 方法hoW 從企業(yè)角度，分析業(yè)務概念和事件活動 功能數據校驗 任務類別 流水作業(yè) 3X3建模過程 3X3矩陣各階段：概念 邏輯 物理 34 目的 交付 要素 概念 分析 用 IT語言表達現實世界問題空間 (信息模型 ) 目標及業(yè)務定位 概念 ERD 概念 DFD CRUD校驗 業(yè)務場景驗證 利用業(yè)務活動逐步分解 ?確定業(yè)務概念 ?確定業(yè)務概念之間的聯(lián)系 ?確定業(yè)務概念關鍵屬性 ?確定業(yè)務值域 邏輯 設計 設計支持現實世界概念模型的邏輯模式和子模式 (外模式 ) 定位圖 邏輯 ERD 邏輯 DFD CRUD校驗 業(yè)務場景驗證 ?邏輯塊之間的聚合關系 ?將 ERD轉化為關系模式 ?對實體和處理進行歸納抽象 ?對實體和處理逐層細化 ?邏輯實體和處理定義 物理 設計 根據 DBMS特點和處理的需要，進行物理存儲安排，形成內模式 物理 ERD 物理 DFD 功能結構圖 集成架構圖 技術架構圖 ?設計 UI/系統(tǒng)接口 ?設計數據存儲 (內存 /文件 /DB) ?設計索引等性能參數 ?設計異常處理及系統(tǒng)管理 ?設計其他技術實現細節(jié) 3X3矩陣各層面：業(yè)務 管理 實現 縱向分為 業(yè)務、管理、實現 三個層面，這是業(yè)務角度上的劃分，它們之間是一種并列關系，但是它們之間互相聯(lián)系，只是它們各自關注的角度不同 業(yè)務 – 處理 核心業(yè)務事件 (RUP:直接使客戶受益的活動 ) – 該類業(yè)務活動的某環(huán)節(jié)一旦停止，業(yè)務即不能正常開展 管理 – 處理為了使業(yè)務運轉的更好所增加的管理活動，主要分以下兩類： – 一類是對活動 本身的管理 ，既 規(guī)則管理 – 另一類是對活動 結果的管理 ，如 經營分析 實現 – 處理為了使核心業(yè)務流程能夠正常運轉所需要開展的 輔助活動 – 如：異常處理，支持與就緒，與參與人的交互等 35 3X3矩陣各層面：概念－邏輯－物理 概念模型設計 – 是整個數據架構設計的關鍵，通過對用戶需求進行綜合、歸納與抽象，形成一個獨立于具體 DBMS的概念模型。 – 概念模型是從 業(yè)務的視角 對企業(yè)運營過程中涉及的 信息的結構化描述 ，是技術中立的模型 邏輯模型設計 – 對概念分析階段中牽涉的業(yè)務，抽象出處理功能，并逐步細化，以達到能在系統(tǒng)中實現。 – 邏輯模型是從 解決方案的角度 對 數據的結構化 描述；是技術相對中立的模型 物理模型設計 – 對邏輯設計中的功能與實體進一步細化，使功能 /數據能在具體的系統(tǒng)中實現 – 物理模型是結合具體的 DBMS等技術選擇，考慮系統(tǒng)的可實現性、性能、接口等因素，在邏輯數據模型基礎上進一步細化設計的模型 目錄 目的 架構建模方法總論 業(yè)務架構建模方法 數據架構建模方法 – 數據建模理論 – 模型分析方法 應用架構建模方法 技術架構設計方法 概念模型分析 定義 – 概念模型是從業(yè)務的視角對企業(yè)運營過程中涉及的信息的結構化描述，是技術中立的模型 目標 – 用 IT語言表達現實世界問題空間：分析出 所有的業(yè)務實體 ，定義業(yè)務概念，闡述清楚 實體之間的基本關系 方法 – 初步劃分業(yè)務活動范圍 – 尋找業(yè)務活動范圍中的業(yè)務實體并描述定義 – 分析并描述業(yè)務 實體之間的關系 從屬關系分析 處理關系分析 管理關系分析 – 分析并描述業(yè)務實體關鍵屬性 – 分析屬性所對應的業(yè)務值域 – 業(yè)務場景校驗、 CRUD校驗 38 邏輯模型分析 定義 – 邏輯模型是從解決方案的角度對數據的結構化描述；是技術相對中立的模型 目標 – 設計支持現實世界概念模型的邏輯模式和子模式 (外模式 ) – 對概念分析階段中牽涉的業(yè)務，抽象出處理功能，并逐步細化，以達到能在系統(tǒng)中實現 方法 – 在概念分析的基礎上劃定系統(tǒng)邊界 – 去掉僅僅代表業(yè)務，而不需要應用系統(tǒng)實現的實體和處理 – 將模型轉化為關系模式 – 將模型中相近的實體和處理進行 歸納抽象，消除冗余 – 引入設計層面所需要的實體 和處理，并逐層細化 – 設計實體類的屬性 ，設計相關的值域，確定實體類的候選標識并進一步確定主標識，建立與屬性相關的業(yè)務規(guī)則 – 定義邏輯實體和處理 – 業(yè)務場景校驗、 CRUD校驗 39 邏輯模型設計方法 轉化為數據模型關系規(guī)范化模式優(yōu)化設計用戶子模式物理設計階段概念模型 :( E R 模型 )邏輯設計階段概念設計階段邏輯模型( 關系模型 )帶主屬性的 ER圖 與具體 DBMS無關：表 、鍵 、 索引及視圖等 ，確定完整性約束 1： 1， M： N等關系的轉化 范式化 完整性約束 完善實體屬性 邏輯模型設計－模型轉換 實體的轉換 – 概念層面的實體可直接轉成邏輯實體 – 根據實體類、關聯(lián)關系存在的相似性，進行適當層次的抽象，形成更為通用的概念； 實體的歸納和細化 – 將模型中相近的實體進行歸納抽象，消除冗余。 歸納是一個由多到少的過程，目的是要達到模型與業(yè)務的無關性，實現數據模型的穩(wěn)定持續(xù)發(fā)展 – 引入設計層面所需要的實體 ，然后對系統(tǒng)開展的活動進一步細化，使得處理功能越來越逼近于函數的實現形式； 細化是一個由少到多的過程，細化的目標是完善實體和功能 關系的轉換： – 若實體間聯(lián)系是 1:1，可以在兩個實體類型轉換成的兩個實體中任意一個實體的屬性中加入另一個實體的標識和聯(lián)系類型 （如層級關系）的屬性。 – 若實體間聯(lián)系是 1:N，則在 N端實體 轉換成的實體中 加入 1端實體的鍵和聯(lián)系類型的屬性。 – 若實體間聯(lián)系是 M:N，則將 聯(lián)系也轉換成實體 ， 其屬性為兩端實體的標識加上聯(lián)系的屬性 ， 而標識為兩端實體標識的組合 。 屬性的轉換 – 概念層面的實體屬性可直接帶到邏輯實體中，補充類型和長度等描述 邏輯設計階段－ 3NF約束 范式化 – 規(guī)范化的目的是使數據模型有更好的結構， 控制和減少數據冗余 ，符合關系數據庫的設計規(guī)則。 – 規(guī)范化的目標是保證 只有一個途徑來知道一個事實 。關系數據庫的一個目的是最大化數據完整性，保證數據的準確性，而實現這一目的的重要方法就是 讓每個概念在數據庫中只出現在一個地方 （外鍵約束除外），如果同時存在多個地方，就會存在數據不一致的隱患，導致對數據完整性的破壞。 – 規(guī)范模型的過程是 刪除模型結構中那些多種途徑來了解相同事實 的模型結構。 三范式 – 第一范式要求實體的 每個屬性的值都是原子的 ，并且必須有單一的含義。 – 第二范式要求符合第一范式后，實體的 每一個非鍵值（ Key）屬性都必須完全依賴于整個鍵值，而不是鍵值的一部分 。 – 第三范式要求符合第二范式后，實體的 每一個非鍵值屬性都不能依賴其它非鍵值屬性 。 物理模型設計 定義 – 物理模型是結合具體的 DBMS等技術選擇，考慮系統(tǒng)的可實現性、性能、接口等因素，在邏輯數據模型基礎上進一步細化設計的模型 目標 – 根據 DBMS特點和處理的需要，進行物理存儲等安排，形成內模式 – 對邏輯設計中的功能與實體進一步細化，使功能 /數據能在具體的系統(tǒng)中實現 方法 – 設計 UI/系統(tǒng)接口 – 考慮性能，進行反規(guī)范化設計 – 設計數據存儲 (內存 /文件 /DB) – 設計索引、視圖、分區(qū)、存儲參數等性能參數 – 引入具體實現層面所需要的實體和處理，并細化 – 設計程序異常處理及系統(tǒng)管理 – 設計其他技術實現細節(jié) – 場景校驗、 CRUD校驗 43 目錄 目的 架構建模方法總論 業(yè)務架構建模方法 數據架構建模方法 應用架構建模方法 技術架構設計方法 系統(tǒng)框架分析方法－ UC矩陣 U/C矩陣分析是在業(yè)務流程、數據流程及數據分析的基礎上，為了整體地考慮 系統(tǒng)的功能子系統(tǒng) 和數據資源的合理分布而進行的系統(tǒng)化的分析方法 U/C矩陣是結構劃系統(tǒng)分析方法中，用來表達 過程與數據兩者之間的關系的方法。矩陣中的列表示數據類，行表示過程，并以字母 U（ Use）和 C（ Create）來表示過程對數據類的使用和產生。 U/C矩陣是一種用關系數據矩陣進行系統(tǒng)分析方法，并對其存儲、正確性檢驗、表上作業(yè)等做了分析，同時 利用結果關系進行了子系統(tǒng)劃分 U/C矩陣是一張表格。它可以表數據 /功能系統(tǒng)化分析的結果。它的左邊第一列列出過程的名稱，上面第一行列出數據類的名稱。表中在各過程與數據類的交叉處，填寫過程與數據類的關系。 U/C矩陣的建立 用矩陣表實現 行表示過程 列表示數據類 在行列交叉處填充 U/C C表示表示這類數據由相應功能產生 Ｕ表示這類功能使用相應的數據類 U/C矩陣使用方法 U/C矩陣的校驗 完備性校驗 一致性校驗 無冗余校驗 完備性校驗： 一個 數據項必須有一個 C和至少一個 U；一個功能則必須 U/C 一致性： 一個 數據項必須且只能有一個 C 無冗余校驗 : U／ C矩陣中不允許有空行和空列 U/C矩陣的求解 調整表中的行或列，使“ C” 元素盡量地朝對角線靠近 求解就是對系統(tǒng)結構劃分的優(yōu)化過程。 系統(tǒng)劃分應相互相獨立且高內聚 系統(tǒng)劃分 在 U/C矩陣中，沿對角線劃矩形，每個矩形即為子系統(tǒng) 矩陣既不能重疊也不能漏掉數據和功能項 所有的 C必須包含在矩陣中 矩陣內的數據項為本系統(tǒng)需要處理的數據 矩陣外的 U表示各個系統(tǒng)之間的數據交互 DFD P1數 據 處 理 1數 據 存 儲 2數 據 存 儲 3P2數 據 處 理 2數 據 存 儲 1數 據 存 儲 4客 戶DD 實 體 1屬 性 1屬 性 2系統(tǒng) 框架 UC矩陣使用過程 U/C矩陣的建立 用表的行和列分別記錄下數據類和過程。表中功能與數據類交叉點上的符號Ｃ表示這類數據由相應功能產生，Ｕ表示這類功能使用相應的數據類 U/C矩陣正確性校驗 完備性校驗： 指對具體的數據項必須有一個產生者（ C）和至少一個使用者（ U），功能則必須有產生或使用（ U或 C）發(fā)生 一致性校驗： 指對具體的數據項必須有且僅有一個產生者（ C） 無冗余校驗 :指 U／ C矩陣中不允許有空行和空列 U/C矩陣的求解 U／ C 矩陣的求解就是對系統(tǒng)結構劃分的優(yōu)化過程。它是基于子系統(tǒng)劃分應相互相對獨立且內部凝聚性高這一原則之上的一種聚類操作。 U／ C 矩陣的求解過程常通過表上作業(yè)法來完成。其具體操作方法是：調整表中的行