下面是层次数据模型的优点

下面是层次数据模型的优点：

简单：由于数据库基于层次结构，所以各层之间的联系逻辑上（或概念上）简单并且层次数据库的设计也简单。

数据共享：因为所有数据都保存在公共数据库里，所以数据共享成为现实。

数据安全：层次模型是第一个由DBMS提供和强制数据安全的数据库模型。

数据独立性：DBMS提供了保持数据独立性的环境，这充分地降低了编程的难度，减少了对程序的维护工作量。

数据完整性：给定双亲/子女联系，在双亲段和它的子女段之间存在链接。由于子女段是自动地引用它的双亲，所以这种模式保证了数据完整性。

高效率：当数据库包含大量一对多（1∶m）联系的数据并且用户在大量事务中所使用的数据的联系固定时，层次数据模型是非常高效率的。

可用的技术：由于已有许多大型计算机技术基础，因此经验丰富的编程人员可以加以有效利用。

可靠的商业应用程序：在主机环境内部存在大量可靠的商业应用程序。

2.层次数据模型的缺点

实现复杂：虽然层次数据库概念简单、容易设计而且没有数据依赖性问题，但实现起来特别复杂。DBMS要求数据存储的物理级知识，数据库设计者必须要具备一定的物理数据存储特性的知识。数据库结构的任何变化(例如段位置的改变)，都要求所有访问数据库的应用程序随之改变。因此，数据库设计的实现变得非常复杂。

不灵活：层次数据库缺乏灵活性。新的联系或段的改变通常会带来非常复杂的系统管理任务。一个段的删除可能会造成对其下面的所有段的无意识删除。这样一个错误会造成较大的损失。

数据库管理问题：如果改变了层次数据库的数据库结构，那么必须修改所有访问数据库的应用程序。这样，维护数据库和应用程序变得非常困难。

缺乏结构独立性：结构独立性是指数据库的结构发生改变而不会影响DBMS访问数据的能力。层次数据库被称为导航式系统，这是因为数据访问要求使用前序遍历（一种物理存储路径）导航到适合的段。因此，应用程序员应该掌握从数据库访问数据的相关访问路径。物

理结构的修改或变化会导致应用程序出现问题，这就要求必须修改应用程序。因此，在层次数据库系统中由于结构依赖使得数据独立性的好处是有限的。

应用程序编写复杂：编写应用程序非常费时和复杂。由于结构依赖和导航式的结构，应用程序编程人员和终端用户必须准确地知道数据库中数据的物理描述以及如何编写访问数据的线性控制代码。这要求具有复杂指针系统的知识，而只有很少或没有编程技术的普通用户通常是很难掌握这一知识的。

实现的限制：许多普通的联系并不适合于层次数据模型所要求的一对多联系。例如，在大学注册的学生可以选修多门课程，并且每门课程可由多个学生选修。在现实世界中这样普通的多对多（n∶m）联系在层次数据模型中都很难实现。

没有标准：在层次数据模型里，没有精确的标准概念集,也没有明确指定模型执行的特定标准

问：试述网状、层次数据库的优缺点?

答：

网状数据模型的优点主要有：

（1）能够更为直接地描述现实世界，如一个结点可以有多个双亲。

（2）具有良好的性能，存取效率较高。

网状数据模型的缺点主要有：

（1）结构比较复杂，而且随着应用环境的扩大，数据库的结构就变得越来越复杂，不利于最终用户掌握。

（2）其数据定义语言（DDL）、数据操作语言（DML）复杂，用户不容易使用。

（3）数据独立性较差。由于记录之间联系是通过存取路径实现的，应用程序在访问数据时必须选择适当的存取路径，因此，用户必须了解系统结构的细节，加重了编写应用程序的负担。从而影响数据独立性。

层次模型的优点主要有：

（1）层次数据模型本身比较简单，层次分明，便于在计算机内实现。

（2）在层次数据结构中，从根结点到树中任一结点均存在一条唯一的层次路径，为有效地进行数据操纵提供条件。

（3）由于层次结构规定除根结点外所有结点有且仅有一个双亲，故实体集之间的联系可用双亲结点唯一地表示，并且层次模型中的基本层次联系总是从双亲记录指向子女记录，所以记录类型之间的联系名可省略。由于实体集间的联系固定，所以层次模型DBMS 对层次结构的数据有较高的处理效率。

（4）层次数据模型提供了良好的完整性支持。

（5）实体间联系是固定的，且预先定义好的应用系统，采用层次模型来实现，其性能优于

关系模型，不低于网状模型。

可见用层次模型对具有一对多的层次关系的部门描述非常自然、直观，容易理解。这是层次数据库的突出优点。

层次模型的缺点主要有：

（1）现实世界中很多联系是非层次性的，如多对多联系、一个结点具有多个双亲等，层次模型表示这类联系的方法很笨拙，只能通过引入冗余数据(易产生不一致性)或创建非自然的数据组织(引入虚拟结点)来解决。

（2）对插入和删除操作的限制比较多。

（3）查询子女结点必须通过双亲结点。

（4）由于结构严密，层次命令趋于程序化。

数据库系统三级模式结构的优点

三级模式结构分别是外模式、概念模式和内模式优点：减少冗余

数据仓库模型的设计

2.5数据仓库模型的设计数据仓库模型的设计大体上可以分为以下三个层面的设计151: .概念模型设计; .逻辑模型设计; .物理模型设计; 下面就从这三个层面分别介绍数据仓库模型的设计。 2.5.1概念模型设计进行概念模型设计所要完成的工作是: <1>界定系统边界 <2>确定主要的主题域及其内容概念模型设计的成果是，在原有的数据库的基础上建立了一个较为稳固的概念模型。因为数据仓库是对原有数据库系统中的数据进行集成和重组而形成的数据集合，所以数据仓库的概念模型设计，首先要对原有数据库系统加以分析理解，看在原有的数据库系统中“有什么”、“怎样组织的”和“如何分布的”等，然后再来考虑应当如何建立数据仓库系统的概念模型。一方面，通过原有的数据库的设计文档以及在数据字典中的数据库关系模式，可以对企业现有的数据库中的内容有一个完整而清晰的认识;另一方面，数据仓库的概念模型是面向企业全局建立的，它为集成来自各个面向应用的数据库的数据提供了统一的概念视图。概念模型的设计是在较高的抽象层次上的设计，因此建立概念模型时不用考虑具体技术条件的限制。 1.界定系统的边界数据仓库是面向决策分析的数据库，我们无法在数据仓库设计的最初就得到详细而明确的需求，但是一些基本的方向性的需求还是摆在了设计人员的面前: . 要做的决策类型有哪些? . 决策者感兴趣的是什么问题? . 这些问题需要什么样的信息? . 要得到这些信息需要包含原有数据库系统的哪些部分的数据? 这样，我们可以划定一个当前的大致的系统边界，集中精力进行最需要的部分的开发。因而，从某种意义上讲，界定系统边界的工作也可以看作是数据仓库系统设计的需求分析，因为它将决策者的数据分析的需求用系统边界的定义形式反映出来。 2，确定主要的主题域在这一步中，要确定系统所包含的主题域，然后对每个主题域的内

数据库模型设计

数据库模型设计连载(1～6) 最近一直有个愿望：希望把自己所从事的数据库模型设计方面的工作经验和想法付诸文字，算是对此前工作的一个总结，今天终于开始了万里长征的第一步。在正式开始之前，我先向大家介绍两本书——《数据模型资源手册卷一》、《数据模型资源手册卷二》，国内有机械工业出版社出版的中文译本，很多同行可能都已看过，我本人也看过。看过之后深受启发，同时也感到两点美中不足： 1、这两部书的成书时间较早，且原作内容是基于美国企业的业务需求而建，有些最新的行业信息及“中国特色”的东西没有收录。 2、书中原作者所使用的设计符号是作者专用的，而对于目前国内数据库模型设计的专业人员来说， ER图或者PowerDesigner中的CDM、PDM图更容易理解和沟通。所以，在今后一段时间，我希望每天能抽出2个小时，结合上面提到的两部书的内容、PowerDesigner 的PDM模型以及本人相关工作经验，在这里做一个数据库模型设计的连载。本连载计划用120天的时间撰写完毕。这么做的目的，一方面是将头脑里的无形信息落实到文字上、有效避免遗忘，另一方面更加希望抛砖引玉，在与同行们沟通交流之后对我自己也是个促进和提高，对其他同行也起到各借鉴的作用。望广大同行们不吝赐教，大家一起来推动数据库模型设计的资源共享计划。什么是模式？连载之1 原创：胖子刘（转载请注明出处及作者，谢谢。）什么是模式？简单说来，模式类似于定式，就是遇到反复出现的同一问题时所固定使用的解决方案。下围棋的朋友可能对“定式”这个词比较熟悉，定式包含着下棋时做遇到的各种情况下的下法、急所、手筋及死活等基本原理，例如星定式、小目定式、边定式等等，定式懂的越多，围棋下的越好。那么是不是数据库设计模式懂得越多，设计工作越完美呢？理论上是这样，但是在我这里，各位朋友所能看到的数据库设计模式只有四种。为什么只有四种而不是更多？不时有那句话吗：“浓缩的都是精华”！在后面的文章中，您会陆续看到浩浩荡荡的设计实例连篇累牍，却都是利用这四种基本模式设计出来的。《易传·系辞》曰：“易有太极，是生两仪，两仪生四象，四象生八卦。”老子在《道德经》中也说：“道生一，一生二，二生三，三生万物。” 设计模式不必多，只要掌握其中关键的几个，再结合实际的业务需求，一个完整的数据库模型就可以推导出来。下面让我们来逐一介绍这四种主要设计模式——

概念数据模型设计讲解

一、新建概念数据模型 1）选择File-->New,弹出如图所示对话框，选择CDM模型（即概念数据模型）建立模型。 2）完成概念数据模型的创建。以下图示，对当前的工作空间进行简单介绍。（以后再更详细说明）．

3）选择新增的CDM模型，右击，在弹出的菜单中选择“Properties”属性项，弹出如图所示对话框。在“General”标签里可以输入所建模型的名称、代码、描述、创建者、版本以及默认的图表等等信息。在“Notes”标签里可以输入相关描述及说明信息。当然再有更多的标签，可以点击按钮，这里就不再进行详细解释。?牯?尾二、创建新实体 1）在CDM的图形窗口中，单击工具选项版上的Entity工具，再单击图形窗口的空白处，在单击的位置就出现一个实体符号。点击Pointer工具或右击鼠标，释放Entitiy工具。如图所示

2）双击刚创建的实体符号，打开下列图标窗口，在此窗口“General”标签中可以输入实体的名称、代码、描述等信息。．三、添加实体属性 1）在上述窗口的“Attribute”选项标签上可以添加属性，如下图所示。

注意：数据项中的“添加属性”和“重用已有数据项”这两项功能与模型中Data Item的Unique code 和Allow reuse选项有关。 P列表示该属性是否为主标识符;D列表示该属性是否在图形窗口中显示;M列表示该属性是否为强制的，即该列是否为空值。如果一个实体属性为强制的，那么，这个属性在每条记录中都必须被赋值，不能为空。 2）在上图所示窗口中，点击插入属性按钮，弹出属性对话框，如下图所示。

数据模型设计要点

目录 1.数据模型设计的输入4 2.数据模型设计必须的几个阶段4 2.1.概念数据模型设计（Conceptual Data Model） (5) 2.2.逻辑数据模型设计（Logical Data Model） (6) 2.2.1.设计范式要求 7 2.2.1.1.第一范式 7 2.2.1.2.第二范式 7 2.2.1. 3.第三范式 8 2.2.1.4.逆第三范式 9 2.2.2.其他要求 10 2.2.2.1.数据类型定义 10 2.2.2.2.实体名称定义 10 2.2.2. 3.主键定义 10 2.2.2.4.实体关系定义 10 2.2.2.5.数据量估算 11 2.2.2.6.索引定义 11 2.3.物理数据模型（Physical Data Model） (12) 2.3.1.物理库设计 12 2.3.1.1.数据库Server设计 12 2.3.1.2.表空间设计 12 2.3.1.3.用户及权限设计 13 2.3.2.物理表设计 13

2.3.2.1.数据类型设计 13 2.3.2.2.存储设计 13 2.3.2.3.主外键设计 13 2.3.2.4.索引设计 14 2.3.2.5.生成建表语句 14 3.数据模型设计相关工具软件14 4.数据模型设计的产出及规格要求14 4.1.概念数据模型设计阶段 (14) 4.2.逻辑数据模型设计阶段 (15) 4.3.物理数据模型设计阶段 (15)

1.数据模型设计的输入传统的瀑布型的开发模型下，其特点是需求驱动。相应的，数据模型设计的必要输入为需求分析阶段的产出，包括需求规格说明书（需求分析说明书）、数据字典。分析型应用由于其需求不易迅速全面予以明确，所以适合用螺旋式开发模型，逐步迭代。但由于分析型应用是数据驱动，所以数据模型的设计要求更高，需要根据业务和数据的实际情况，进行快速全面分析，并有充分的管理思维，才能设计出比较理想的数据模型。其输入就不仅限于传统的瀑布开发模型下的需求规格说明书和数据字典，而是要从业务层面分析各个现有业务实体，以管理思维的角度，进行必要的抽象、归纳和挖掘，结合未来管理需要，明确潜在业务实体，以及各业务实体之间的关系，最终予以设计实现。 2.数据模型设计必须的几个阶段无论是瀑布模型还是螺旋模型，数据模型的设计都必须经历概念数据模型设计、逻辑数据模型设计和物理数据模型设计三个阶段。其中，概念数据模型设计的主要工作是提取概念实体并分析其关系，这是最关键的工作，直接影响后续工作的质量；逻辑数据模型设计的主要工作是设计各逻辑实体的属性、主键、索引以及各实体之间的关系，此部分与物理数据库无关；物理数据模型设计的主要工作是结合具体的物理数据库平台进行存储设计。这三个阶段并不是完全单向的，而是可以反向调整。假设后面的阶段发现有问题，可以转到上一阶段进行必要的修改后继续进行。但一定不能不管前一阶段的结果，放任自流地进行后面阶段的工作。 2.1.概念数据模型设计（Conceptual Data Model）本阶段的任务是对业务领域的各概念实体进行归纳和总结的过程。该过程以分析概念实体以及它们之间的关系为目标，而不是以细化概念实体的各项属性为目标。该阶段工作非常重要，是进行其他阶段工作的基础。

数据库的设计与建模

基于PowerDesigner合同管理系统的数据库设计与建模摘要：本文以某企业的合同管理系统为例，着重介绍了基于powerdesigner进行数据库设计与建模。从用户数据库的设计阶段到用户基于powerdesigner的建模阶段，最后在sql server2005中执行脚本，形成数据库中的数据表。关键词：数据流图概念模型物理模型合同管理系统一、系统需求分析合同管理软件一般包括合同起草、合同审批、文本管理、履约监督、结算安排、智能提醒合同收付款、项目管理、合同结款情况统计分析、报表输出和决策支持等功能模块。针对某企业对合同管理的具体需求，将本系统的主要功能归纳如下： 1.基础设置模块：包括合同类型、合同性质、合同分组的设置、审批流的设置和用户管理等几部分，实现对合同文件的基础信息的设置和管理。 2.管理模块：包括对待审批的合同的添加和已审批的合同的归档管理。 3.审批模块：实现对合同的审批操作。 4.查询模块：实现对合同的审批情况和归档情况以及付款、实施情况进行综合查询。 5.审核模块：实现部门负责人对合同进行审核。二、数据库设计

1.数据流图。数据流图主要是用来说明数据流的一个流向，是数据在系统内的传输途径，数据流图从数据传递和加工的角度，以图形的方式刻画数据流从输入到输出的变换过程。数据流图的基本元素包括数据流、加工、数据存取文件、输入数据的源点和输出数据的汇点4类。根据系统初步需求，管理人员、经办人、部门负责人、财务部、主管领导等都会产生数据，通过使用本系统得到所需的查询统计结果。因此管理人员、经办人、部门负责人、财务部、主管领导等是数据输入的源点和数据输出的汇点。系统中需要存储各类用户信息、合同基本信息等，因此用户信息、合同基本信息等是数据存储文件，根据以上分析结果，合同管理系统的数据流图如图1。 2.数据字典。三、基于powerdesigner 得出物理数据模型 powerdesigner是sybase公司著名的产品，是dba和软件架构师设计的利器，它提供了一个完整的建模解决方案。用powerdesigner 数据建模是一种很好的软件工程实践，它能够帮助设计人员在正式编写程序代码之前规划数据需求，不仅加速了开发的过程，也向最终用户提供了管理和访问项目信息的一个有效结构。

数据模型设计

四、数据模型设计 4.1概念设计 4.1.1实体分析在本系统中，主要包括二手书、用户以及管理员三个实体集，其中每个实体都有属于自己的独立的属性。此外，在系统中根据业务还可以找到购物车、订单、评论、留言和新闻五个实体集。在实际分析中发现，购物车实体中如果以购物车号作为主键比较繁杂，且购物车记录会因为形成订单而删除，不易操作。因此采用用用户号作为主键的方法，每个用户在形成订单的时候可以清空自己选择购物车的特定内容。 4.1.2实体关系的总体分析在以上几个实体中，购物车、订单、评论都是由书、用户两个实体之间的关系产生的，都需要建立一张单独的基本表。一个用户可以添加多条记录到当前购物车，一个用户可以形成多条订单记录，一个用户可以评论多本书，每本书可以有很多评论。为方便操作，我们把用户号作为购物车号，这样可以解决一个用户将多样书籍添加到购物车，结算时形成一条订单查找删除购物车困难的问题。 4.1.3具体实体联系一个用户可以购买多本书籍，一本书籍可以被多个用户购买（M：N）一本书籍可以生成一个购物车，一个购物车可以包含多本书籍（M：1）一条订单对应一个用户，一个用户对应多条订单（M：1）一个用户拥有一个购物车，一个购物车对应一个用户（1：1）一个购物车形成一条订单，一条订单包含一个购物车记录（1：1）一个用户可以发表多个评论，一个评论只能由一个用户发表（1：M）一本书可以有多个评论，一个评论对应一本书籍（1：M）一个用户可以发表多条留言，一条留言只能由一个用户发布（1：M）一个管理员可以回复多条留言，一条留言只能由一个管理员回复（1：M）一个管理员可以处理多条订单，一个订单只能由一个管理员处理（1：M）

数据仓库多维数据模型的设计说明

1、数据仓库基本概念 1.1、主题（Subject）主题就是指我们所要分析的具体方面。例如：某年某月某地区某机型某款App的安装情况。主题有两个元素：一是各个分析角度（维度），如时间位置；二是要分析的具体量度，该量度一般通过数值体现，如App安装量。 1.2、维（Dimension）维是用于从不同角度描述事物特征的，一般维都会有多层（Level：级别），每个Level 都会包含一些共有的或特有的属性（Attribute），可以用下图来展示下维的结构和组成：以时间维为例，时间维一般会包含年、季、月、日这几个Level，每个Level一般都会有ID、NAME、DESCRIPTION这几个公共属性，这几个公共属性不仅适用于时间维，也同样表现在其它各种不同类型的维。 1.3、分层（Hierarchy） OLAP需要基于有层级的自上而下的钻取，或者自下而上地聚合。所以我们一般会在维的基础上再次进行分层，维、分层、层级的关系如下图：

每一级之间可能是附属关系（如市属于省、省属于国家），也可能是顺序关系（如天周年），如下图所示： 1.4、量度量度就是我们要分析的具体的技术指标，诸如年销售额之类。它们一般为数值型数据。我们或者将该数据汇总，或者将该数据取次数、独立次数或取最大最小值等，这样的数据称为量度。 1.5、粒度数据的细分层度，例如按天分按小时分。 1.6、事实表和维表事实表是用来记录分析的内容的全量信息的，包含了每个事件的具体要素，以及具体发

生的事情。事实表中存储数字型ID以及度量信息。维表则是对事实表中事件的要素的描述信息，就是你观察该事务的角度，是从哪个角度去观察这个内容的。事实表和维表通过ID相关联，如图所示： 1.7、星形/雪花形/事实星座这三者就是数据仓库多维数据模型建模的模式上图所示就是一个标准的星形模型。雪花形就是在维度下面又细分出维度，这样切分是为了使表结构更加规范化。雪花模式可以减少冗余，但是减少的那点空间和事实表的容量相比实在是微不足道，而且多个表联结操作会降低性能，所以一般不用雪花模式设计数据仓库。事实星座模式就是星形模式的集合，包含星形模式，也就包含多个事实表。

数据库模型设计

1.PowerDesigner 15是Sybase公司推出的一个集成了企业架构分析，UML(统一建模语言)和数据建模CASE(计算机辅助软件工程)工具 2.业务处理模型（Business Process Model ,BPM）,主要在需求分析阶段使用，是从业务人员的角度对业务逻辑和规则进行详细描述，并使用流程图表示从一个或多个起点到终点间的处理过程，流程，消息和协作协议 3.概念数据模型（Conceptual Data Model，CDM）主要在系统开发的数据库设计阶段使用，是按用户的观点来对数据和信息进行建模，利用实体关系图（E-R图）来实现 4.项目是PowerDesigner15的新概念，通过项目系统分析设计人员可以对模型以及各类文档进行分组 5.PowerDesigner企业架构模型从业务层，应用层以及技术层对企业的体系架构进行全方面的描述，包括业务流程，业务功能，系统，人员等单元的结构及行为包括3个层面7种企业架构流程图业务层:（1）组织结构图：通过树状图的形式表示组织结构。（2）业务通讯图：用于分析和表现业务元素之间的关系，流程和连接。（3）进程图：用于表示和人员，组织机构无关的业务架构，描述业务功能以及对进层进行分类.(4)城市规划图：用于提供组织架构的总图应用层(1)应用架构图：展示应用架构的高级视图，可用于识别应用，组建，数据库，服务及其之间的关系(2面向服务图:用于展示应用及SOA架构的业务服务之间的关系技术层技术基础框架图：展示了实体框架图，体现了系统所用的硬件关系 6. EAM中的大多数对象都有两种显示模式---图标模式和明细模式。以图标模式现实的对象在图中只能显示一个图标，可以通过右键—更换图片来更换此对象的图标。以明晰模式显示的对象可以在图中显示对象的一些明细信息，可以通过右键---格式---内容页面来选择需要在图片中显示的具体信息，可供选择的项目于对象类型有关。可以通过内弄页面的显示模式下拉列表框、右键图标并切换显示明细菜单项或者用ctrl+Q快捷键来改变现实模式。 7.层次链接表示同一性质的层级关系，只有组织单位之间，个人之间才能使用层次链接，组织单位和个人之间不能使用层次链接，如果需要建立组织单位和个人之间的关系，应当使用链接/扩展依赖进程图用于表示和人员组织机构无关的业务架构,描述业务功能以及对进程进行分类. 8.进程也可以在架构区域内直接创建架构区域:用于包含组织其他对象。系统：表示一组应用，服务或者子系统的组合技术基础框架图是技术层唯一的图,用于展示实体框架图,只要是系统所用到的硬件,都可以在技术基础框架图中呈现. 9.PowerDesigner BPM包括三种流图：处理层次流图：以层次化的形式来识别系统的功能业务处理流图:用于分析一个/组流程的具体实现机制处理服务流图：以业务服务的方式来表述业务流程图 10.BPM中的处理语言可以分为:分析语言，服务编排，协作三种。分析语言包括分析，BPMN1.0和数据流图。服务编排语言包括：面向服务架构，BPEL4WS1.1或WS-BPEL2.0，Sybase工作区业务处理1.53类处理语言。协作语言包括ebXML1.01和1.04. BPM没有保存时会用*来提示。 11从工作区中删除BPM，但BPM文件并不会从计算机中删除，文件没有保存的时候显示的是* 12消息格式是流程和资源流的属性，它能够提供对象间的数据交互类型信息，创建流程时消息格式的属性默认值是“未定义” 13包是用于将元素构成组的机制，它包含模型对象,通过包的形式将多个模型对象有效地组

数据库模型设计

数据库设计概念模型、逻辑模型、物理模型区别侯在钱目录 1.模型种类 (2) 1.1.概念模型 (2) 1.2.逻辑模型 (3) 1.3.物理模型 (3) 1.4.模型区别 (3) 1.4.1.对象转换 (4) 1.4.2.其它对比 (4) 2.常用工具 (5) 2.1.ERWIN (5) 2.1.1.逻辑模型 (5) 2.1.2.物理模型 (5) 2.1.3.常用操作 (6) 2.2.PowerDesigner (8) 2.2.1.概念模型 (8) 2.2.2.逻辑模型 (9) 2.2.3.物理模型 (9) 2.2.4.常用操作 (10)

1.模型种类一般在建立数据库模型时，会涉及到几种模型种类：概念模型、逻辑模型、物理模型。数据库设计中概念模型和逻辑模型区别比较模糊，所以在数据库设计工具ERWIN中只提供了逻辑模型和物理模型，而在PowerDesigner早期版本中也只提供了概念模型和物理模型两种模型，只是在PowerDesigner15版本中提供了三种模型：概念模型、逻辑模型、物理模型。 1.1.概念模型概念模型是对真实世界中问题域内的事物的描述，不是对软件设计的描述。表示概念模型最常用的是"实体-关系"图。 E-R图主要是由实体、属性和关系三个要素构成的。在E-R图中，使用了下面几种基本的图形符号。实体，矩形 E/R图三要素属性，椭圆形关系，菱形

关系：一对一关系，一对多关系，多对多关系。 1.2.逻辑模型逻辑数据模型反映的是系统分析设计人员对数据存储的观点，是对概念数据模型进一步的分解和细化。 1.3.物理模型物理模型是对真实数据库的描述。数据库中的一些对象如下：表，视图，字段，数据类型、长度、主键、外键、索引、是否可为空，默认值。概念模型到物理模型的转换即是把概念模型中的对象转换成物理模型的对象。 1.4.模型区别