1、ConceptualDataModel（概念数据模型）
概念数据模型（CDM），可以帮助你分析信息系统的概念结构，识别主要的实体，及其属性，以及它们之间的关系。CDM比逻辑（LDM）或物理数据模型（PDM）更抽象。
基于需求综合、归纳、抽象后对数据和信息进行建模，利用实体关系图（E-R图）的形式组织数据。
CDM反映了业务领域中信息之间的关系，它不依赖于物理实现。
CMD不考虑物理实现细节，只考虑实体之间的关系。
目的：统一业务概念，方便业务人员与技术人员沟通。
分析阶段的CDM转换成PDM后，便将抽象的实体、属性与关系，对应到实际数据库的数据表、字段、主键、外部索引键等内容。
2、LogicalDataModel（逻辑数据模型）
逻辑数据模型（LDM）可以帮助你分析信息系统的结构，独立于任何特定的物理数据库实现。LDM已确定实体标识符，没有概念数据模型（CDM）抽象，但不允许你建视图模型，索引等具体的物理数据模型（PDM）元素。
逻辑模型是对概念数据模型的进一步细化与分解
形成DBMS所支持的数据结构（一般是关系数据模型）
既要面向业务用户，又要面向系统
影响数据库设计方案选择
3、PhysicalDataModel（物理数据模型）
基于特定DBMS，在概念数据模型、逻辑数据模型的基础上进行设计。
PDM叙述数据库的物理实现。主要目的是把CDM中建立的现实世界模型生成特定的DBMS脚本，产生数据库中保存信息的储存结构，保证数据在数据库中的完整性和一致性。
CHAR:
1、长度固定，当char（15）的元素中只有“abc”时,其余十二位用空格填补；
VARCAHR:
1、长度不固定，该列中元素有多少位，就是多少位；
2、当数据为空时，该字段为空字符串；
3、VARCHAR只对汉字或全角字符占两个字节处理，数字和英文等都是一个字节；
VARCHAR2:
1、当数据为空时，该数据显示为NULL;
2、VARCHAR2（一般情况下）把所有字符都按两个字节处理，VARCHAR2字符要用几个字节存储，要看数据库使用的字符集。比如GBK，汉字就会占两个字节，英文1个，如果是UTF-8，汉字一般占3个字节，英文还是1个。 但是一般情况下，我们都认为是两个字节处理，因为oracle安装时候默认我们都选择GBK的编码格式，但是我们在页面做输入字符串长度的校验的时候，还是以数据库设计字段最大长度除3来作为最大长度-----防止数据库移植时设置不同编码格式；
nvarcahr和nvarchar(2)
联系：
2、SIZE的最大值为4000，最小值为1（是字符个数，不是字节数）
3、这两种类型跟适合存储中文；
区别：
2、nvarchar2中，所有字符都按两个字节计算；
3、nvarchar2虽然更占内存，但是兼容性比较好，所以推荐使用。
在空间上，Char要比VarChar和VarChar2耗费空间，因为不管存多少内容，它的长度都为2000，而VarChar和VarChar2则因长度可变，会节省更多的空间
在效率上，Char要比VarChar和VarChar2稍高，如果VarChar和VarChar2更经常修改，且修改的数据长度每次都不一样，这会引起“行迁移”现象。
定义表、视图
*表可以看作有行和列的电子数据表，表是关系数据库中一种拥有数据的结构。*视图是一个或多个表中的数据的简化描述，用户可以将视图看成一个存储查询或一个虚拟表
视图实际的数据来源于原始的数据表，没有存放在原始表以外的任何其它地方，所以建立视图不会消耗其他的空间。
存储过程
*存储过程只在创造时进行编译，以后每次执行存储过程都不需再重新编译可提高数据库执行速度。
*当对数据库进行复杂操作时，可将此复杂操作用存储过程封装起来与数据库提供的事务处理结合一起使用。
*存储过程可以重复使用,可减少数据库开发人员的工作量
*安全性高,可设定只有某此用户才具有对指定存储过程的使用权
注意：在分布式系统中要少用存储过程
定义索引、关键字
*索引是一个与表有关的数据结构，它是通过索引列进行逻辑排序的。索引能够调整模型的可用性，改进系统的性能，消除查找到记录之前在表中的多次扫描。索引的存在减慢了数据的修改（插入、修改、删除）速度。候选关键字是由一个或多个列组成的，它们的每组值与一条并且只有一条表中的记录相对应。候选关键字具有充当主键的资格，只是没有被选做主键。它为数据访问提供了方便，调整了数据的可用性。
定义引用
*引用是在父表和字表间建立一种关系。
*引用定义引用一致完整性约束在列之间，可以是主键、外键或者是替代主键
引用最常见的是在主键上
定义约束
PowerDesigner支持下列约束：*限制（Restrict）。不允许进行修改或删除操作。若修改或删除主表的主键时，如果子表中存在子记录，系统将产生一个错误提示。这是缺省的参照完整性设置。
*置空(Set Null)。如果外键列允许为空，若修改或删除主表的主键时，把子表中参照的外键列设置为空值（NULL）。
置为缺省(Set Default)。如果指定了缺省值，若修改或删除主表的主键时，把子表中参照的外键设置为缺省值（Default）。
Multidimensional Diagram（多维图）
4、ObjectOrientedModel（面向对象模型）
Class Diagram（类图）
Sequence Diagram（序列图）
Message:消息
Slef Message 递归消息
Call Message带有激活期的消息
Self Call Message带有激活期的递归消息
Return Message返回消息
Self Return Message递归返回消息
，再单击执行者“顾客”并拖动鼠标至用例“查找”，释放鼠标，这时在执行者和用例之间建立了关系。双击该关系，打开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。
5、BusinessProcessModel（业务程序模型）
业务流程模型（BPM）帮助您识别，描述和分解业务流程。您可以分析不同层级的系统，关注控制流（执行顺序）或数据流（数据交换）。您可以使用BPEL，BPMN，以及许多其他的流程语言。业务流程建模是一组业务流程分析，设计，实施和执行的技术和标准。它使业务分析师和经理通过分析系统，以理顺和优化或为一个新的系统建模。
从业务人员的角度对业务逻辑和规则进行详细描述
使用流程图表示起点到终点间的处理过程、流程、消息和协作协议
可以有一个或多个起点和终点
6、EnterpriseArchitectureModel（企业架构模型）
企业架构模型（EAM），可以帮助你分析和记录您的组织及其业务功能，以及支持他们的物理架构及其上的应用程序和系统。7、DataMovementMode（数据传输模式）
数据移动模型（DMM）提供，在您的组织的信息运动的全局视图。你可以分析和记录您的数据来源，它移动到哪，以及它是如何转变的道路上，包括复制和ETL。
8、RequirementsModel（需求模型）
需求模型（RQM）可帮助您分析各种各样的书面需求，并将它们与其它模型中的设计对象连接起来。您可以使用RQM表示任何结构化的文档（例如：功能规范，测试计划，企业目标等），并可导入导出MS Word文档。
一个作用：定义系统边界。
三个视图：
需求文档视图、追踪短阵视图、用户分配矩阵视图（来描述系统需求）。
Requirements Document View(需求文档视图):
通过二维表的形式，以分层的方式表达系统需求；
Traceability Matrix View(追踪矩阵视图):
描述需求与设计对象、外部文件和其他需求之间的连接关系；
User Allocation Matrix View(用户分配矩阵视图):
表达需求与用户或用户组之间的分配关系。
9、XMLMode
一个XML模式（XSM）可以帮助您分析XML架构定义（XSD），文档类型定义（DTD）或XML数据简化（XDR）文件。你可以建模，反向工程，生成这些文件格式。
10、FreeModel（自由模型）
自由模型可以为任何模型的对象或系统建模提供一个上下文环境，允许自定义概念和图形符号，例如：可以创建一个自由模型来表示模型和文档之间的相互关系，企业组织以及组织间的相互关系。
