PowerDesigner模型分類

原文: PowerDesigner模型分類

版權聲明：本文爲博主原創文章，未經博主容許不得轉載。 https://blog.csdn.net/zjws23786/article/details/80053082

一、ConceptualDataModel（概念數據模型）

        概念數據模型（CDM），能夠幫助你分析信息系統的概念結構，識別主要的實體，及其屬性，以及它們之間的關係。CDM比邏輯（LDM）或物理數據模型（PDM）更抽象。
        基於需求綜合、概括、抽象後對數據和信息進行建模，利用實體關係圖（E-R圖）的形式組織數據。
        CDM反映了業務領域中信息之間的關係，它不依賴於物理實現。
        CMD不考慮物理實現細節，只考慮實體之間的關係。
        目的：統一業務概念，方便業務人員與技術人員溝通。
        分析階段的CDM轉換成PDM後，便將抽象的實體、屬性與關係，對應到實際數據庫的數據表、字段、主鍵、外部索引鍵等內容。

二、LogicalDataModel（邏輯數據模型）

        邏輯數據模型（LDM）能夠幫助你分析信息系統的結構，獨立於任何特定的物理數據庫實現。LDM已肯定實體標識符，沒有概念數據模型（CDM）抽象，但不容許你建視圖模型，索引等具體的物理數據模型（PDM）元素。
        邏輯模型是對概念數據模型的進一步細化與分解
        造成DBMS所支持的數據結構（通常是關係數據模型）
        既要面向業務用戶，又要面向系統
        影響數據庫設計方案選擇

三、PhysicalDataModel（物理數據模型）

        物理數據模型（PDM）能夠幫助你分析表，視圖和其餘數據庫對象，包括數據倉庫的多維對象。 PDM的是更具體的一個概念（CDM）或邏輯（LDM）的數據模型。你能夠爲全部經常使用的DBMS建模、反向工程、生成數據庫。
        基於特定DBMS，在概念數據模型、邏輯數據模型的基礎上進行設計。
        PDM敘述數據庫的物理實現。主要目的是把CDM中創建的現實世界模型生成特定的DBMS腳本，產生數據庫中保存信息的儲存結構，保證數據在數據庫中的完整性和一致性。
        CHAR:
                一、長度固定，當char（15）的元素中只有「abc」時,其他十二位用空格填補；
         VARCAHR:
                一、長度不固定，該列中元素有多少位，就是多少位；
                二、當數據爲空時，該字段爲空字符串；
                三、VARCHAR只對漢字或全角字符佔兩個字節處理，數字和英文等都是一個字節；
         VARCHAR2:
                一、當數據爲空時，該數據顯示爲NULL;
                二、VARCHAR2（通常狀況下）把全部字符都按兩個字節處理，VARCHAR2字符要用幾個字節存儲，要看數據庫使用的字符集。好比GBK，漢字就會佔兩個字節，英文1個，若是是UTF-8，漢字通常佔3個字節，英文仍是1個。 可是通常狀況下，咱們都認爲是兩個字節處理，由於oracle安裝時候默認咱們都選擇GBK的編碼格式，可是咱們在頁面作輸入字符串長度的校驗的時候，仍是以數據庫設計字段最大長度除3來做爲最大長度-----防止數據庫移植時設置不一樣編碼格式；
         nvarcahr和nvarchar(2)
            聯繫：

                一、都用於存儲可變長度的字符串；
                二、SIZE的最大值爲4000，最小值爲1（是字符個數，不是字節數）
                三、這兩種類型跟適合存儲中文；
            區別：

                一、nvarchar中，中文字符按兩個字節計算，英文字符按一個字符計算；
                二、nvarchar2中，全部字符都按兩個字節計算；
                三、nvarchar2雖然更佔內存，可是兼容性比較好，因此推薦使用。
           在空間上，Char要比VarChar和VarChar2耗費空間，由於無論存多少內容，它的長度都爲2000，而VarChar和VarChar2則因長度可變，會節省更多的空間
            在效率上，Char要比VarChar和VarChar2稍高，若是VarChar和VarChar2更常常修改，且修改的數據長度每次都不同，這會引發「行遷移」現象。

定義表、視圖

        *表能夠看做有行和列的電子數據表，表是關係數據庫中一種擁有數據的結構。
        *視圖是一個或多個表中的數據的簡化描述，用戶能夠將視圖當作一個存儲查詢或一個虛擬表
視圖實際的數據來源於原始的數據表，沒有存放在原始表之外的任何其它地方，因此創建視圖不會消耗其餘的空間。
存儲過程
        *存儲過程只在創造時進行編譯，之後每次執行存儲過程都不需再從新編譯可提升數據庫執行速度。
        *當對數據庫進行復雜操做時，可將此複雜操做用存儲過程封裝起來與數據庫提供的事務處理結合一塊兒使用。
        *存儲過程能夠重複使用,可減小數據庫開發人員的工做量
        *安全性高,可設定只有某此用戶才具備對指定存儲過程的使用權
注意：在分佈式系統中要少用存儲過程

定義索引、關鍵字

        *索引是一個與表有關的數據結構，它是經過索引列進行邏輯排序的。索引可以調整模型的可用性，改進系統的性能，消除查找到記錄以前在表中的屢次掃描。索引的存在減慢了數據的修改（插入、修改、刪除）速度。
        候選關鍵字是由一個或多個列組成的，它們的每組值與一條而且只有一條表中的記錄相對應。候選關鍵字具備充當主鍵的資格，只是沒有被選作主鍵。它爲數據訪問提供了方便，調整了數據的可用性。
定義引用
        *引用是在父表和字表間創建一種關係。
        *引用定義引用一致完整性約束在列之間，能夠是主鍵、外鍵或者是替代主鍵
引用最多見的是在主鍵上

定義約束

    PowerDesigner支持下列約束：
        *限制（Restrict）。不容許進行修改或刪除操做。若修改或刪除主表的主鍵時，若是子表中存在子記錄，系統將產生一個錯誤提示。這是缺省的參照完整性設置。
        *置空(Set Null)。若是外鍵列容許爲空，若修改或刪除主表的主鍵時，把子表中參照的外鍵列設置爲空值（NULL）。
置爲缺省(Set Default)。若是指定了缺省值，若修改或刪除主表的主鍵時，把子表中參照的外鍵設置爲缺省值（Default）。

Physical Diagram（物理圖）

Multidimensional Diagram（多維圖）

四、ObjectOrientedModel（面向對象模型）

Class Diagram（類圖）

        類圖是用一種抽象的方法來描述對象及對象之間的關係，並不能描述對象的全部細節。

Sequence Diagram（序列圖）

        是用來描述系統如何實現完成在Use Case圖中定義的功能。能夠畫出對象之間的交互時產生的時序關係。它一方面描述了一次交互，交互中涉及類圖中的類，另外一方面細化了用例的描述。

序列圖有角色(Actor),對象(Object)，消息(Message)和激活期(Activation)幾個要素

消息類型有：
Message:消息
Slef Message 遞歸消息
Call Message帶有激活期的消息
Self Call Message帶有激活期的遞歸消息
Return Message返回消息
Self Return Message遞歸返回消息

Object Diagram（對象圖）

Package Diagram（包裝圖）

Use Case Diagram（用例圖）：用例圖用於系統需求分析階段，進行系統需求和功能設計，它包含執行者和用例兩個要素。執行者指用戶在系統中的角色，用例是用戶與計算機的一次交互。用例圖主要用來描述每一個用例將有哪些執行者進行參與。

        定義執行者和用例之間的關係。單擊「關係」圖標 ，再單擊執行者「顧客」並拖動鼠標至用例「查找」，釋放鼠標，這時在執行者和用例之間創建了關係。雙擊該關係，打開Association Properties窗口，將Name屬性修改成「查詢商品」，將Code屬性修改成SearchProduct。

Communication Diagram（通訊圖）

通訊圖提供了系統結構中重要的用例腳本對象之間的交互、操做的執行、或類之間的相互。

Interaction Diagram（交互做用圖）

交互圖提供了系統的控制流的高層級的圖形視圖，它能夠分解成時序圖和其餘交互圖。

Activity Diagram （活動圖）

        活動圖提供系統行爲的圖形視圖，幫助你從功能上分解系統，以幫助分析其是如何實現的。
        UML 活動圖設計用於幫助您瞭解系統中對象的動態變化。用於描述某一特定類或一組類如何協同工做。與時序圖有所不一樣，活動圖不是一系列與時間相關的通訊，而是從一個任務到另外一任務的控制轉移，同時指定誰（哪一個對象）對發生的任務負責。
        UML 活動圖也是業務流程的技術視圖。可對業務工做流進行分析或在「業務流程建模」工做後可得到活動圖。
        活動圖還可幫助構造系統內元素的詳細動態視圖（EJB 如何互操做等）。

Statechart Diagram（狀態圖）

        狀態圖是一個UML圖，提供了狀態機的圖形視圖，一個分類器（組件或類）的公共行爲，在分類的狀態隨着時間的推移和事件的變化形式，容許從一種狀態過渡到另外一個。
        狀態圖（也稱爲狀態機）描述了特定類或組件在其整個生命週期中不斷變化時的行爲。
        該圖顯示是什麼觸發了從一種狀態向另外一種狀態的轉換，以及在該類上調用哪些操做以提供該狀態的行爲或觸發這種轉換。例如，訂單在被建立時處於初始狀態。在客戶確認訂單正確後，訂單將進入確認狀態。在發貨之後，訂單須要從確認狀態進入發貨狀態。若要保持狀態圖簡單和易讀，您可能發現所定義的一個或多個狀態實際上涉及到更爲複雜的行爲，以致於它自己就能夠定義爲一個狀態圖。此時，與向主圖中添加大量複雜細節的作法相比，更好的作法是將這個單獨的狀態分解爲多個子狀態，進而組成一個輔助圖，以定義父狀態的更爲複雜的內部行爲。

Component Diagram（元件圖）

        組件圖提供軟件組件之間的依賴性和繼承關係的圖形視圖，包括源代碼組件，二進制代碼組件和可執行組件。
        UML 組件圖將被用於在更大的黑匣視圖（BlackBox View）中描述高級對象的定義和相關性。它仍然是一個設計模型,而且是代碼的直接歸納。例如，一個EJB 的組件標識直接連接到實施所必需的一系列類和接口，並將生成所需代碼來推進最終 bean 的開發。組件圖比組件體系結構的代碼層視圖更容易理解和管理。還能夠經過編寫組件接口的文檔來實現代碼的共享和反覆使用，用戶無需（或不多）瞭解組件的實施細節便可在其餘項目和系統中使用這些代碼。

Composite Structure Diagram（複合結構圖）

        複合結構圖是提供組成一個系統的類、接口、包、包括端口及部份內部結構描述。在咱們藉助用例圖、時序圖、活動圖、類圖和組件圖完成基本 UML 建模時，咱們將須要其它一些工具來定義有關係統中某些特定元素的詳細信息。咱們可能但願在對象圖中使用精確的示例來表示對象的結構，或者藉助於狀態圖來更多地瞭解在其內部具備多個複雜狀態的類的行爲。咱們須要使用協做圖從結構角度而不是從時間角度來考察系統組件之間的交互做用。最後，還須要使用部署圖來顯示全部系統組件在運行環境中的物理硬件或服務器中所處的位置，從而更詳盡的瞭解分佈式體系結構的使用方式。 UML 爲咱們提供了更加實用的圖表，以便完成對業務邏輯的技術分析、設計、開發、或部署。將這 9 種圖表與傳統的數據建模方法和新的業務流程建模方法相結合，咱們能夠在從高級需求到技術和數據需求，以及物理實現的各個方面來全面瞭解推進軟件開發的全部因素。

Deployment Diagram（部署圖）

        部署圖提供系統運行時元素物理配置圖形化視圖。
        部署圖能夠幫助咱們肯定全部代碼元素在服務器、工做站和數據庫中的存放位置。有的節點須要依賴硬件或軟件框來運行部分業務邏輯。這些節點交互做用以演示咱們開發的多個計算機和系統是如何交互做用和集成的。節點中包含將部署到數據庫、應用程序或 Web 服務器中的組件實例。部署圖用於將組件實際部署到服務器中。經過定義但願組件運行的位置，咱們能夠快捷的映射、部署和管理分佈在客戶端應用程序和應用程序服務器端組件之間的業務邏輯或數據庫端服務器邏輯。如下是要管理的物理體系結構的 1:1 模型。例如，假定咱們已決定實現兩個Enterprise Java Beans，而且在應用程序服務器上運行它們。下圖顯示了單個節點以及該節點內的兩個組件（每一個 EJB 一個組件）。咱們能夠看出EmployeeBean 依賴於同一應用程序服務器內的 CustomerBean。

五、BusinessProcessModel（業務程序模型）

        業務流程模型（BPM）幫助您識別，描述和分解業務流程。您能夠分析不一樣層級的系統，關注控制流（執行順序）或數據流（數據交換）。您可使用BPEL，BPMN，以及許多其餘的流程語言。
        業務流程建模是一組業務流程分析，設計，實施和執行的技術和標準。它使業務分析師和經理經過分析系統，以理順和優化或爲一個新的系統建模。
        從業務人員的角度對業務邏輯和規則進行詳細描述
        使用流程圖表示起點到終點間的處理過程、流程、消息和協做協議
        能夠有一個或多個起點和終點

Business Process Diagram（業務流程圖）

Process Hierarchy Diagram（工藝層次圖）

Choreography Diagram（編舞圖）

Conversation Diagram（會話圖）

        

六、EnterpriseArchitectureModel（企業架構模型）

        企業架構模型（EAM），能夠幫助你分析和記錄您的組織及其業務功能，以及支持他們的物理架構及其上的應用程序和系統。

Process Map（過程圖）

Organization Chat（組織聊天）

Business Communication Diagram（業務通訊圖）

City Planning Diagram（城市規劃圖）

Service Oriented Diagram（面向服務的流程圖）

Application Architecture Diagram（應用架構圖）

Technology Infrastructure Diagram（技術基礎結構圖）

七、DataMovementMode（數據傳輸模式）

        數據移動模型（DMM）提供，在您的組織的信息運動的全局視圖。你能夠分析和記錄您的數據來源，它移動到哪，以及它是如何轉變的道路上，包括複製和ETL。

八、RequirementsModel（需求模型）

        需求模型（RQM）可幫助您分析各類各樣的書面需求，並將它們與其它模型中的設計對象鏈接起來。您可使用RQM表示任何結構化的文檔（例如：功能規範，測試計劃，企業目標等），並可導入導出MS Word文檔。
        一個做用：定義系統邊界。
        三個視圖：
        需求文檔視圖、追蹤短陣視圖、用戶分配矩陣視圖（來描述系統需求）。
                Requirements Document View(需求文檔視圖):
        經過二維表的形式，以分層的方式表達系統需求；
                Traceability Matrix View(追蹤矩陣視圖):
        描述需求與設計對象、外部文件和其餘需求之間的鏈接關係；
                User Allocation Matrix View(用戶分配矩陣視圖):
        表達需求與用戶或用戶組之間的分配關係。

九、XMLMode

        一個XML模式（XSM）能夠幫助您分析XML架構定義（XSD），文檔類型定義（DTD）或XML數據簡化（XDR）文件。你能夠建模，反向工程，生成這些文件格式。

十、FreeModel（自由模型）

        自由模型能夠爲任何模型的對象或系統建模提供一個上下文環境，容許自定義概念和圖形符號，例如：能夠建立一個自由模型來表示模型和文檔之間的相互關係，企業組織以及組織間的相互關係。

十一、Multi-Model Report（多模型報告）

參考：http://blog.51cto.com/heludd/1317357