如何建立数据模型
一般作为菜鸟级别的数据库设计人员,往往面对一个项目,不知道如何入手.
或抓着一张纸就开始分析.
或方法单一,根本找不到相应的CASE工具.
或不得要领;或者不知道自己在干啥,书上说要这样做就这样做.
不一而足,我就是这样过来的.
这里结合自己平时的分析经验.谈谈如何建立数据模型.
何谓数据模型呢?王珊老师告诉我们:数据模型就是现实世界的模拟.我的理解数据模型设计就是数据库的设计
那么优秀的数据模型应该是怎样的呢？她应该满足3个要求：
一是能够比较真实的模拟现实世界
二是容易为人所理解
三是便于在计算机上实现。
数据模型的建立一般分为四步：1 需求分析 2 概念模型设计 3物力模型设计 4实施运行维护
Powerdesigner12已经没有PAM,被BPM所取代了.
1 需求分析的时候我们用到如下辅助方法：
业务流程图 建议PD实现
数据词典 建议PD实现
数据流图 建议VISIO实现 pd下用bpm
系统流程图 建议VISIO实现
组织结构图 建议VISIO实现
时序图 建议VISIO实现
状态图 建议VISIO实现
功能分解图 建议VISIO实现
2 概念模型设计的时候我们用到如下辅助方法：
ER图 建议PowerDesigner的CDM实现
数据词典 建议PowerDesigner的Report实现
模型优化 范式求证
设计用户子模式 符合用户习惯,也实现安全性
3 物理模型设计
数据库结构 建议PowerDesigner的PDM实现
综上所述:作为一个优秀的数据库设计人员,需要灵活运用下面辅助方法
业务流程图 (BPM)
数据流图 (DFD： Data Flow Diagram)
实体关系图 (ERD)
用例图: (use case model)
数据词典 (DD： Data Dictionary)
时序图
状态图
系统流程图
组织结构图
功能分解图
一般情况下,面对比较复杂的数据库建模, 规范的做法是:
第一步: 需求分析,获得业务流程图,数据流图和数据字典
第二步:根据数据流图和数据字典建立E-R图
第三步:E-R图转换成为物理数据模型
第四部:实施物理数据模型
如果你对于以上几种图不太了解,建议《数据库系统原理教程》.不过快的办法是找到形象的例图.
参考：
《数据库系统原理教程》 清华大学出版社 王珊，陈红 编著
《湖南师范大学管理信息复习材料》
相关概念解释:
------------------------------------------------------------------------------------
数据图（DFD： Data Flow Diagram）
1．数据流图
就是组织中信息运动的抽象，是管理信息系统模型的主要形式。它与对系统的物理描述无关，只是用一种图形及与此相关的注释来表示系统的逻辑功能，即所开发的系统在管理信息处理方面要做什么。
2．数据流图由四种基本成分组成
（1）外部项（外部实体）：外部项在数据流图中表示所描述系统的数据来源和去处的各种实体或工作环节。这些实体或环节向所开发的系统发出或接收信息。系统开发不能改变这些外部项本身的结构和固有属性。
（2）加工（数据加工）：又称数据处理逻辑，描述系统对信息进行处理的逻辑功能。
（3）数据存储：逻辑意义上的数据存储环节，即系统信息处理功能需要的，不考虑存储物理介质和技术手段的数据存储环节。
（4）数据流：与所描述系统信息处理功能有关的各类信息的载体，是各加工环节进行处理和输出的数据集合。
常用的三类数据沈图基本成份的符号。
3．绘制数据流图的主要原则
（1）明确系统界面，一张数据流图表示某个子系统或某个系统的逻辑模型。
（2）自顶向下逐层扩展。在调查研究的基础上，明确所描述的系统与各部实体的信息联系。绘出最高层的数据流图——关联图。在关联图中，所描述的系统当作一个数据加工项，着重描述系统与外部实体的联系。然后确定系统的几个主要的综合性的逻辑功能，绘
制顶层数据流图。其中每个逻辑功能由一个数据加工符号描述。顶图可进一步分解，其中某些或者所有的数据加工项可分解为数个数据加工项，这样就形成第一层数据流图。依次逐层向下扩展，直到最底层的数据流图表示了所有具体的数据加工功能和输入输出关系。
（3）合理布局。数据流图各种符号买布局合理，分布均匀、整齐、清晰，使读者一目了然。
（4）数据流图只反映数据流向，数据加工和逻辑意义上的数据存储。
（5）数据流图绘制过程，就是系统的逻辑模型的形成过程，必须始终与用户密切接触。
4．绘制数据流图的主要步骤
（1）确定所开发系统的外部项（外部实体），即系统的数据来源和去处。
（2）确定整个系统的输出数据流和输入数据流，把系统作为一个加工环节，画出关联图。一般应把数据来源置于图的左侧，数据去处置于国的右侧。
（3）确定系统的主要信息处理功能，按此将整个系统分解成几个加工环节（子系统）。
（4）根据自须向下，逐层分解的原则，对上层图中全部或加工环节进行分解。
（5）重复步骤（4），直到逐层分解结束。分解结束的标志是：对于每一个最底层的加工，即各层数据流图中不做进一步分解的加工，其逻辑功能已足够简单、明确和具体。
（6）对某图进行检查和合理布局，主要检查分解是否恰当、彻底，DFD中各成分是否有遗漏、重复、冲突之处，各层DFD及同层DFD之间关系是否正确及命名、编号是否确切、合理等。对错误与不当之处进行修改。
（7）和用户进行交流，在用户完全理解数据图内容的基础上征求用户的意见。
（8）用计算机或其它制图，编辑工具画出正规的数据流图。
（9）将正规的数据流图提交系统分析负责人复审。
5．绘制数据流图的几点注释
（l）关于自须向下，逐层分解。数据流图的绘制过程，是系统分析过程的重要组成部分，这一过程自顶向下，逐层分解，就是由系统外部至系统内部，由总体到局部、由抽象到具体的系统逻辑模型建立过程。在数据流图分解中，要保持各层成分的完整性与一致性。
（2）数据流必须通过加工，即送去加工或从加工环节发出。不通过加工环节的数据流不在数据流图上表示。
（3）数据存储环节一般作为两个加工环节的界面来安排。
（4）命名。数据流图上的成分一般都要命名，命名的原则为：
①名称要反映被命名成分的真实和全部的意义；②名称要意义明确，易理解，无歧义，不会造成错觉和混乱；③加工的名称一般以动词十宾语或名词性定语十动名词为宜，以明确反映信息处理的逻辑功能；④避免使用不反映实际内容的空洞词汇；⑤进出数据存储环节的数据流如内容和存储者的数据相同，可采用同一名称。
（5）编号。每个数据加工环节和每张数据流图都要编号。按逐层分解的原则，父图与子图的编号要有一致性，一般子图的图号是父图上对应加工的编号。如顶层图的图号为0，其中各加工环节按1，2，3编号，顺序编号，1号加工环节分解后的子加工技1．l，1．2，1．3……，编号，依次类推。
数据流与数据存储环节也要进行编号以便于编写，分析与维护。编号方法原则上与加工环节的编号方法相同。为避免混淆，可在数据流与数据存储编号的第一位数字前冠以不同的字符以示区别。如数据流符号冠以F，数据存储符号冠以D。
同样，下层图上的数据流或数据存储是由上层图的某个成分的分解而得，则父项与子项的编号要体现数据流图分解的完整性与一致性的原则。
（6）只画所描述的系统稳定工作情况下的数据流图。因而数据流图不描述系统启动时或结束工作时功能和数据流运动规律处于变动状态的情况。
（7）数据流图的局限性。数据流图从总体上描述系统的逻辑功能，系统内各部分的信息联系及与系统外各有关事物的联系，反映系统中信息运动的规律，是系统逻辑模型的主要描述形式。数据流图清晰，明了，容易理解，使人对描述系统的逻辑功能和各部分的数据联系有一目了然的感觉，便于交流。但数据流图在描述系统逻辑功能和有关信息内容的细节方面仍存在较大的局限性。如：①难以在数据流图上标志出数据流，数据存储和加工以及外部项的具体内容；②不能反映系统中的决策与控制过程；③难以对系统中人机交互过程以及信息的反馈与循环处理进行描述。
------------------------------------------------------------------------------------
数据词典（DD：Data Dictionary）
l．数据词典的作用
是给数据流图上每个成分以定义和说明。
2．数据词典描述的主要内容有：数据结构、数据流、数据元素、数据存储、加工外部项，其中数据元素组成数据流的基本成分。
3．编写数据词典的基本要求
（l）对数据流图上各种成分的定义必须明确，易理解、唯一。
（2）命令、编号与数据流图一致，必要时可增加编码，方便查询检索，维护和统计报表。
（3）符合一致性与完整性的要求，对数据流图上的成分定义与说明无遗漏项。
（4）格式规范，风格统一，文字精炼，数字与符号正确。
注意数据字典中数据结构、数据流、数据存储可以直接抽象出来话ER图
------------------------------------------------------------------------------------
实体关系图(ER图)
ER图就是组织中信息运动的抽象，是管理信息系统模型的主要形式。它与对系统的物理描述无关，只是用一种图形及与此相关的注释来表示系统的逻辑功能，即所开发的系统在管理信息处理方面要做什么。
用ERD描述数据模型能够帮助你预先精确定义数据需求，使你能够对以后的改动作出有效的规划
------------------------------------------------------------------------------------
用例图:(use case model)
use case model说明的是最核心的几个作业，象登录、权限管理等并不是特有的核心作业，而是公共的职能，所以不应该在use case model中出现。
再次，采购审批分得太细，一个use case就足够了。这几个use case可以作为“采购审批”的几个活动。一个系统中不应该出现太多太细的use case。
一个系统的use case不应该很多，很容易看出来先后顺序。如果多到需要标明先后顺序的程度就不好了。
------------------------------------------------------------------------------------
业务流程图
业务流程图描述一个组织内部业务处理活动的内容与工作流程，是进行系统调查使用的工具之一。
