使用ERwin设计数据库

本文作者结合自己多年的实践经验，系统阐述了利用ERWin进行数据库建模的思想、方法和注意事项，具有一定实用价值。

ERWin Data Modeler是CA公司的数据库建模工具，目前在关系数据库的设计中，有着比较广泛的应用。笔者经过多年的实践，感觉使用ERWin设计数据库，上手还是比较快的，但是要在项目中使用好，对于不同的开发环境和不同的项目，在开发的不同阶段使用ERWin，可能采取的最佳策略也不相同。

使用前的准备

1．学习ERWin支持的方法论

ERWin支持两种方法论，一种是IE（信息工程），另一种是IDEF1X，在使用ERWin之前必须了解其一，不然，将连标记符号也搞不清楚。这里笔者简单谈一下IDEF1X（详细内容在ERWin 的联机文档中有介绍）。IDEF1X为数据模型提供了一种规范的结构，是语义模型化技术，主要描述的对象包括实体、联系和属性。同时，作为一种工业规范，IDEF1X还强调了对开发上述模型需要的方法。这样，标准化的标记语言和相关的辅助方法论组合在一起，就可以充分保证设计的高效率和有效性的平衡了。

2．学习ERWin

掌握了ERWin支持的方法论，并不等于掌握了ERWin，方法论仅仅解决的是逻辑模型，而ERWin还要支持物理模型，还有界面和操作的问题。由于在生成数据库的过程中，需要对于使用的物理数据库有比较多的了解，所以还一定要了解IDEF1X和目标关系数据库之间的差异，这种差异，可能对于微机平台、小数据量的应用关系不大，但是对于大型数据库，还是有很多物理的参数、限制等应该了解。

4．确定数据库表、字段的命名规则

确定数据库表、字段的命名规则，看似容易，其实涉及到的方面很多，而且初始阶段一旦没有处理好，以后再改难度比较大。笔者认为，命名宜考虑如下因素：

●如果新开发的系统是一个大系统的子系统，那么应该考虑原来大系统的数据库、字段命名的规则，即使这样的规则存在问题，也要在取得共识的基础上进行改进。

●考虑开发和运行工具的限制要求，以及生产系统的限制要求。

●在可能的情况下，应考虑匈牙利命名法。对于应用系统，往往对于数据是有分类的，如果能够把这些分类体现在数据库表名和字段名中，则是有益无害的。

●字段名保持惟一能够避免一些不小心导致的对数据库字段的使用错误。

5．对数据库表进行分类

对于数据库表进行分类，能够使数据库更加清晰，也便于系统管理。根据笔者的体会，对于每一类数据库表，如果允许，可以按照匈牙利命名法的规则规定一个特征标记，可以是前缀也可以是后缀。

建立数据库的逻辑模型

ERWin作为一个建模工具，引进了一些概念和工具，这些概念和工具往往贯穿于逻辑模型和物理模型中。但是这些方面如果在逻辑模型中处理不好，到了物理模型的阶段也往往木已成舟，没有办法了。

1．用好Domain

Domain的概念有点像是属性的数据类型，笔者的体会是，如果不打算使用Domain，则不要增加任何Domain，都用ERWin提供的默认值; 如果打算使用Domain，则应该对于每一类数据等同的属性建立一个Domain，而且在修改数据类型的时候，仅仅修改Domain中的内容。总体来看，使用Domain虽然可能增加一些工作量，但是可以建立所有属性数据类型的定义树。

2．用好Definition

Definition和Domain不同，不是一个可操作的实体，而是在每一个Domain，每一个实体和属性中的一个标签。在Domain、实体和属性的建立和修改过程中，正确地维护Definition，是能够随时得到文本数据结构说明的一种有效的方法。

3．处理好键值组命名

采用自己方便和清晰、又能为实现环境所接受的键值组命名。其中，对于主键、次键、外键和单独建立的可重复索引，应该进行区分，因为对银行等行业的多应用交互的大型、复杂的运行环境，如果不加以关注，可能在投产后的系统管理中造成很多麻烦。实际上，ERWin对于上述的键名称和索引，在命名的时候是有所区分的，应该充分利用这种区分，在满足环境的情况下，可以直接使用ERWin给出的命名。

对于外键的命名，在逻辑模型中，体现为关系的命名。ERWin默认的做法是用一个内部连续的编号，这样可以做到保证命名的惟一，但是并不清晰。在实际工作中，笔者发现，父实体对于子实体往往是包含关系，尤其是对于代码类的父实体，更是如此。因此，笔者采用了“子实体3父实体”的方式，其中“子实体”和“父实体”都可以是实体名称的缩写，而“3”的意义是借用了其字形比较像数学中的属于符号的含义。这样，实际上是对IDEF1X一种变形的应用，这个短句包括父实体、动词和子实体，而动词永远是“属于”。

4．充分利用Subject

对于大型的应用，可以用Subject来关注某些方面的内容。可以仅仅将感兴趣的实体放入Subject中进行处理，而且还可以按照Subject来产生建表的脚本。对于图形布局来说，各个Subject是相互独立的。笔者在以下的两种情况下经常使用Subject：

●从业务逻辑分析问题的时候。对于某一个角度，可能往往仅仅涉及到部分表，为了充分利用图形来描述实体间的关系，将这些相关的实体放入一个Subject中，然后用手工进行图形的布局。

●对于工作表和历史数据表，往往具有基本相同的数据结构，但是历史数据表还要增加一些历史纪录信息。一般不论是由ERWin自动进行版面布局还是自己根据需要进行的版面布局，很难将工作表和历史数据表放在一起，而在修改时，这两个表最好是一起修改，不然如果出现不一致的问题就相当麻烦了。

5．谨慎使用参照完整性

在关系数据库中，提供了参照完整性的概念，利用好参照完整性，可以保持应用数据的高度一致性，但一定要谨慎使用。一般来说，实现参照完整性有三种方法，第一种是使用数据库的触发器; 第二种是使用数据库的外键; 第三种是使用应用逻辑。

对于使用数据库的触发器，这种方法有着最大的灵活性。触发器是由数据库的引擎控制的，只要数据库的引擎不出问题，那么触发器就总是有效的，除非人工关闭触发器，否则数据的一致性可以得到最大的保证。但是这样也会引入两个问题: 对于数据的修改没有痕迹，如果是误操作，那后果是不堪设想的; 对于一些联机交易系统，所有的交易必须快速响应，如果采用这样的触发器，系统的响应时间就会变得太长。

对于使用数据库的外键，这种方法相当于设置了一个子表，对于父表不存在的内容，子表不能插入，也不能修改，但是对父表却没有约束。这种方法，在起作用范围内，效率还是比较高的。

对于系统环境不允许使用触发器的情况，或者对于错误定位要求比较明确以致超出外键能够报告的详细程度的情况，就要使用应用逻辑了。使用应用逻辑实际上可能效率会低于外键，而且由于数据库本身已经没有了控制机制，所以对于应用逻辑的错误或者绕开了应用逻辑的情况，是没有办法保证数据一致性的。

处理数据库的物理模型

实际上，在建立数据库逻辑模型的过程中，物理模型就也已经建立了。但是，在处理数据库的物理模型时，仍旧有一些方面要给与特殊的关注。

1．要特别关注逻辑模型到物理模型的映射关系

IDEF1X的实体名对应数据库的表名，属性名对应字段名，关系名对应约束名，外键名对应索引名。这些似乎全部是自动完成的。但是，如果对于Domain使用不当，有可能形成两者不一致的情况，这时，要在改了逻辑名之后，看一下物理名是否也正确。

另外，在逻辑模型中，数据类型是比较丰富的，对应到了物理模型，要看看到底是不是需要的数据类型。

还有一点要说明的是，即使在物理模型中，在图中显示字段的次序按照列（Column）和按照物理次序是不同的。如果编写程序时，使用的是“Select *”之类的用法，想看到字段的物理次序，一定要在物理模型中将“Format”菜单中的“Display Level”选项设为“Physical Order”。

2．需要定义所使用的目标数据库涉及到的物理参数

使用ERWin的优点，就是最终能够做到产生的脚本能够实现完全等价的人工配置，换句话说，ERWin也能够成为DBA的工具。不同的数据库，对于建库脚本中需要的物理参数差异比较大，为了合理地定义参数，开发部门应该与系统管理部门协商，定义参数应该尽量按照继承的方式进行，便于统一协调和管理。

3．正确选择正向工程的选项

ERWin的正向工程，也就是根据物理模型联机建立数据库表或者生成DDL脚本，有很多选项，这些选项的正确选择十分重要，如果选择不当，即使辛辛苦苦做出一个符合要求的模型，建立的数据库却可能是不对的。为此，笔者有如下几点经验：

●对于正向工程可能的选项，决不能想当然，在更换了数据库，甚至升级了数据库的版本后，都应该认真地审查一下选项是否正确。

●对于正向工程在生成时的选项必须认真斟酌，从生成的脚本中，判断每一个选项的作用。

●ERWin可以生成的索引包括主键索引、替换键索引、非惟一索引和外键索引四类。一般来说，主键、次键都是需要的，而非惟一索引是根据业务需要加上去的，一般也会需要。外键索引则首先要看是否在物理模型中使用了外键，其次要看是否根据外键进行检索，再次还要看是否外键的索引就是主键的索引。

●ERWin在默认的情况下，是不按照用户定义的约束名来产生DDL脚本的，如果想按照用户定义的约束名产生DDL脚本，应该在正向工程的“Other Option”选项中，选中“Constraint Name”。

4．逆向工程的一种使用方法

逆向工程能够从一个现有生产库或者数据库的脚本中产生ERWin的物理和逻辑模型，但是，据笔者的体会，逆向工程产生的结果，一般无法判定各个实体之间的关系，也就是说，实际上是一个一个的表，视图也可以产生出来。

逆向工程的一个用途，就是在有十分严格的系统管理，往往不接受指定格式的数据库维护需求的情况下，当提交了更改需求后，可以向DBA请求其操作的DDL脚本，据此生成模型，进行模型级的全面比较。由于比较的时候，可以指定比较的内容，所以可以找到很多手工难以发现的差错。

5．充分利用全面比较功能

对于数据库已经投产后，需要带着数据进行数据库升级的情况，使用全面比较是一种可行的方法。在全面比较时，既可以看到两个版本的全部差异，也可以实现两个版本中的一个向一个靠拢，或者两个版本的合并。需要注意的是，由于目前版本的ERWin还不能指定生成全面比较的DDL脚本与正向工程对应的选项，所以对于生成的DDL脚本，还是应该进行一定的手工验证的。

自数据库的设计开始，对于每一次数据库的更改，均记录相应的版本，然后使用全面比较确定差异，这样可以有效地减少出现错误的概率。即使已经确定使用产生全部新表的方式重建数据库，也应进行全面比较，以确定是否改动了所要改动的，并且没有改动所不要改动的。

（作者E-mail:likuan@https://www.wendangku.net/doc/f313698588.html,）

链接

使用数据库建模工具的好处

便于从总体上把握数据模型

如果采用了数据库建模工具，并按照一定的方法论，建立了逻辑模型，则易于从总体上把握数据库的设计。

能够支持多种物理数据库

大型项目往往需要支持多种数据库，如果采用了数据库建模工具，就易于在逻辑层控制应用对数据要求的一致性。

能够灵活地产生文本格式的数据库说明文档

采用数据库建模工具，可以从模型中直接产生多种格式和内容要求的文档，以满足各个方面的要求。

能够从模型中产生建库和升级的脚本

在指定了目标数据库后，数据库建模工具能够随时在逻辑模型和物理模型之间切换。对于所做的数据更改，也可以产生详细的差异清单，这对于复杂的、多变的数据库设计，是特别有帮助的。

数据库建模经验总结

数据库如何建模 笔者从98年进入数据库及数据仓库领域工作至今已经有近八年的时间，对数据建模工作接触的比较多，创新性不敢谈，本文只是将工作中的经验总结出来，供大家一同探讨和指正。 提起数据建模来，有一点是首先要强调的，数据建模师和DBA有着较大的不同，对数据建模师来说，对业务的深刻理解是第一位的，不同的建模方法和技巧是为业务需求来服务的。而本文则暂时抛开业务不谈，主要关注于建模方法和技巧的经验总结。 从目前的数据库及数据仓库建模方法来说，主要分为四类。 第一类是大家最为熟悉的关系数据库的三范式建模，通常我们将三范式建模方法用于建立各种操作型数据库系统。 第二类是Inmon提倡的三范式数据仓库建模，它和操作型数据库系统的三范式建模在侧重点上有些不同。Inmon的数据仓库建模方法分为三层，第一层是实体关系层，也即企业的业务数据模型层，在这一层上和企业的操作型数据库系统建模方法是相同的;第二层是数据项集层，在这一层的建模方法根据数据的产生频率及访问频率等因素与企业的操作型数据库系统的建模方法产生了不同;第三层物理层是第二层的具体实现。 第三类是Kimball提倡的数据仓库的维度建模，我们一般也称之为星型结构建模，有时也加入一些雪花模型在里面。维度建模是一种面向用户需求的、容易理解的、访问效率高的建模方法，也是笔者比较喜欢的一种建模方式。 第四类是更为灵活的一种建模方式，通常用于后台的数据准备区，建模的方式不拘一格，以能满足需要为目的，建好的表不对用户提供接口，多为临时表。

下面简单谈谈第四类建模方法的一些的经验。 数据准备区有一个最大的特点，就是不会直接面对用户，所以对数据准备区中的表进行操作的人只有ETL工程师。ETL工程师可以自己来决定表中数据的范围和数据的生命周期。下面举两个例子： 1)数据范围小的临时表 当需要整合或清洗的数据量过大时，我们可以建立同样结构的临时表，在临时表中只保留我们需要处理的部分数据。这样，不论是更新还是对表中某些项的计算都会效率提高很多。处理好的数据发送入准备加载到数据仓库中的表中，最后一次性加载入数据仓库。 2)带有冗余字段的临时表 由于数据准备区中的表只有自己使用，所以建立冗余字段可以起到很好的作用而不用承担风险。 举例来说，笔者在项目中曾遇到这样的需求，客户表{客户ID，客户净扣值}，债项表{债项ID，客户ID，债项余额，债项净扣值}，即客户和债项是一对多的关系。其中，客户净扣值和债项余额已知，需要计算债项净扣值。计算的规则是按债项余额的比例分配客户的净扣值。这时，我们可以给两个表增加几个冗余字段，如客户表{客户ID，客户净扣值，客户余额}，债项表{债项ID，客户ID，债项余额，债项净扣值，客户余额，客户净扣值}。这样通过三条SQL就可以直接完成整个计算过程。将债项余额汇总到客户余额，将客户余额和客户净扣值冗余到债项表中，在债项表中通过(债项余额×客户净扣值/客户余额)公式即可直接计算处债项净扣值。

软件工程-数据库设计规范与命名规则

数据库设计规范、技巧与命名规范 一、数据库设计过程 数据库技术是信息资源管理最有效的手段。 数据库设计是指：对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，有效存储数据， 满足用户信息要求和处理要求。 数据库设计的各阶段： A、需求分析阶段：综合各个用户的应用需求(现实世界的需求)。 B、在概念设计阶段：形成独立于机器和各DBMS产品的概念模式(信息世界模型)，用E-R图来描述。 C、在逻辑设计阶段：将E-R图转换成具体的数据库产品支持的数据模型，如关系模型，形成数据库逻辑模式。 然后根据用户处理的要求，安全性的考虑，在基本表的基础上再建立必要的视图(VIEW)形成数据的外模式。 D、在物理设计阶段：根据DBMS特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式。 1. 需求分析阶段 需求收集和分析，结果得到数据字典描述的数据需求(和数据流图描述的处理需求)。 需求分析的重点：调查、收集与分析用户在数据管理中的信息要求、处理要求、安全性与完整性要求。 需求分析的方法：调查组织机构情况、各部门的业务活动情况、协助用户明确对新系统的各种要求、确定新系统的边界。 常用的调查方法有：跟班作业、开调查会、请专人介绍、询问、设计调查表请用户填写、查阅记录。 分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。自顶向下的结构化分析方法(Structured Analysis， 简称SA方法)从最上层的系统组织机构入手，采用逐层分解的方式分析系统，并把每一层用数据流图和数据字典描述。 数据流图表达了数据和处理过程的关系。系统中的数据则借助数据字典(Data Dictionary，简称DD)来描述。 2. 概念结构设计阶段 通过对用户需求进行综合、归纳与抽象，形成一个独立于具体DBMS的概念模型，可以用E-R图表示。 概念模型用于信息世界的建模。概念模型不依赖于某一个DBMS支持的数据模型。概念模型可以转换为计算机上某一 DBMS 支持的特定数据模型。 概念模型特点： (1) 具有较强的语义表达能力，能够方便、直接地表达应用中的各种语义知识。 (2) 应该简单、清晰、易于用户理解，是用户与数据库设计人员之间进行交流的语言。 概念模型设计的一种常用方法为IDEF1X方法，它就是把实体-联系方法应用到语义数据模型中的一种语义模型化技术， 用于建立系统信息模型。 使用IDEF1X方法创建E-R模型的步骤如下所示:

数据库设计规范范本

数据库设计规范

1概述 1.1目的 软件研发数据库设计规范作为数据库设计的操作规范，详细描述了数据库设计过程及结果，用于指导系统设计人员正确理解和开展数据库设计。 1.2适用范围 1.3术语定义 DBMS：数据库管理系统，常见的商业DBMS有Oracle, SQL Server, DB2等。 数据库设计：数据库设计是在给定的应用场景下，构造适用的数据库模式，建立数据库及其应用系统，有效存储数据，满足用户信息要求和处理要求。 概念数据模型：概念数据模型以实体-关系(Entity-RelationShip,简称E-R)理论为基础，并对这一理论进行了扩充。它从用户的观点出发对信息进行建模，主要用于数据库概念级别的设计，独立于机器和各DBMS产品。能够用Sybase PowerDesigner工具来建立概念数据模型（CDM）。 逻辑数据模型：将概念数据模型转换成具体的数据库产品支持的数据模型，如关系模型，形成数据库逻辑模式。能够用Sybase PowerDesigner工具直接建立逻辑数据模型（LDM），或

者经过CDM转换得到。 物理数据模型：在逻辑数据模型基础上，根据DBMS特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式。能够用Sybase PowerDesigner工具直接建立物理数据模型（PDM），或者经过CDM / LDM转换得到。 2数据库设计原则 按阶段实施并形成该阶段的成果物 一般符合3NF范式要求；兼顾规范与效率 使用公司规定的数据库设计软件工具 命名符合公司标准和项目标准 3数据库设计目标 规范性：一般符合3NF范式要求，减少冗余数据。 高效率：兼顾规范与效率，适当进行反范式化，满足应用系统的性能要求。 紧凑性：例如能用char(10)的就不要用char(20)，提高存储的利用率和系统性能，但同时也要兼顾扩展性和可移植性。 易用性：数据库设计清晰易用，用户和开发人员均能容易地理解。

Erwin工具使用指南

Erwin工具使用指南（版本号：V ）

文档修订状况

目录 第一章基本概念 (4) 数据模型（Modal） (4) 视图 (4) 逻辑视图（Logical） (4) 物理视图（Physical） (4) 第二章操作指南 (6) 新建模型 (6) 视图切换 (7) 新建主题区域 (7) 切换主题区域 (9) 编辑主题区域 (10) 选择现有数据实体到指定的主题区域。 (10) 在主题区域新建数据实体 (11) 在主题区域删除数据实体 (12) 数据实体导航 (13)

第一章基本概念 1.1数据模型（Modal） 数据模型是数据实体(Entity)和数据实体间的关系（Relationship）总和。可以简单的理解认为数据实体就是对应数据库表，实体间的关系就是表之间的关系。 1.2视图 Erwin对数据模型提供两种视——逻辑视图、物理视图。 1.2.1逻辑视图（Logical） 是以业务需求的概念对数据模型进行描述。通俗的说，在逻辑视图中我们可以用中文或描述性的语言来描述数据实体（表）和数据实体的属性（字段）。下面就是一个对车辆信信息实体的逻辑视图。 1.2.2物理视图（Physical） 物理视图与逻辑视图一一对应，物理视图是针对一种具体的数据库进行逻辑视图的物理映射。通俗的说，在物理视图中我们必须为每一个在逻辑视图中出现的数据实体（表）指定一个可被具体数据库接纳的表名称，譬如我们使用MySQL作为我们的数据库实现，我们就必须为具体的实体指定一个数据库表名（英文单词或词组），同样的对实体属性（字段）的命名也需进行转换，数据类型也需要具体为数据库支持的数据类型。下面就是对应车辆信息实体针对MySQL数据的物理视图。

建模工具用户手册

明源建模工具操作手册目录 第一章如何使用建模工具 1 1.1 建模工具环境要求 1 1.2 建模工具使用概述 1 第二章表 4 2.1 新建表 4 2.2 设计表 7 2.3 预览数据 8 2.4 删除表 10 第三章查询 11 3.1 新建查询 11 3.2 修改查询 23 3.3 删除查询 23 第四章实体 23 4.1 新建实体 23 4.2 修改实体 28

4.3 删除实体 29 第五章高级管理 30 5.1 对象浏览器 30 5.2 导入导出 31 5.3 日志浏览器 35 第六章其它 36 6.1 快捷键 36 6.2 附录 37 本书使用的符号解释： “”大项说明——用于无先后顺序的明细条目的说明。 “”小项说明——用于在大项下无先后次序的小项说明 “ ” 提示——这个图标提醒您，如果您想把事情做的好些，就要牢记这些信息。 “ ”警告——如果您想避免不必要的损失，就要牢记这些信息

第一章如何使用建模工具 该工具用于CRM的数据建模需要，实现数据层的业务对象定义。支持用户或项目实施人员对实体对象的维护。 1.1 建模工具环境要求 目前建模工具支持CRM管理系统。对系统配置要求如下： 1.2 建模工具使用概述 打开建模工具，弹出数据库配置，如图： 图1-1

【窗口说明】 ● 服务器地址：建模工具连接的服务器地址，服务器地址可以是IP地址或者机器名 ● 数据库：服务器中需要维护的数据库名称 ● 登录名：服务器SQL Server名称 ● 密码：服务器SQL Server登录密码 输入数据库配置信息后，点击登录；打开建模工具操作窗口，如图： 图1-2 【菜单】 图1-3 ● 文件：点击文件，如图：

数据库设计方法、规范与技巧

数据库设计方法、规范与技巧 一、数据库设计过程 数据库技术是信息资源管理最有效的手段。数据库设计是指对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，有效存储数据，满足用户信息要求和处理要求。 数据库设计中需求分析阶段综合各个用户的应用需求（现实世界的需求），在概念设计阶段形成独立于机器特点、独立于各个DBMS产品的概念模式（信息世界模型），用E-R图来描述。在逻辑设计阶段将E-R图转换成具体的数据库产品支持的数据模型如关系模型，形成数据库逻辑模式。然后根据用户处理的要求，安全性的考虑，在基本表的基础上再建立必要的视图（VIEW）形成数据的外模式。在物理设计阶段根据DBMS特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式。 1. 需求分析阶段 需求收集和分析，结果得到数据字典描述的数据需求（和数据流图描述的处理需求）。 需求分析的重点是调查、收集与分析用户在数据管理中的信息要求、处理要求、安全性与完整性要求。 需求分析的方法：调查组织机构情况、调查各部门的业务活动情况、协助用户明确对新系统的各种要求、确定新系统的边界。 常用的调查方法有：跟班作业、开调查会、请专人介绍、询问、设计调查表请用户填写、查阅记录。 分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。自顶向下的结构化分析方法（Structured Analysis，简称SA方法）从最上层的系统组织机构入手，采用逐层分解的方式分析系统，并把每一层用数据流图和数据字典描述。 数据流图表达了数据和处理过程的关系。系统中的数据则借助数据字典（Data Dictionary，简称DD）来描述。 数据字典是各类数据描述的集合，它是关于数据库中数据的描述，即元数据，而不是数据本身。数据字典通常包括数据项、数据结构、数据流、数据存储和处理过程五个部分(至少应该包含每个字段的数据类型和在每个表内的主外键)。 数据项描述＝｛数据项名，数据项含义说明，别名，数据类型，长度， 取值范围，取值含义，与其他数据项的逻辑关系｝ 数据结构描述＝｛数据结构名，含义说明，组成:｛数据项或数据结构｝｝ 数据流描述＝｛数据流名，说明，数据流来源，数据流去向， 组成:｛数据结构｝，平均流量，高峰期流量｝ 数据存储描述＝｛数据存储名，说明，编号，流入的数据流，流出的数据流， 组成:｛数据结构｝，数据量，存取方式｝ 处理过程描述＝｛处理过程名，说明，输入:｛数据流｝，输出:｛数据流｝, 处理:｛简要说明｝｝ 2. 概念结构设计阶段 通过对用户需求进行综合、归纳与抽象，形成一个独立于具体DBMS的概念模型，可以用E-R图表示。概念模型用于信息世界的建模。概念模型不依赖于某一个DBMS支持的数据模型。概念模型可以转换为计算机上某一DBMS支持的特定数据模型。 概念模型特点： (1) 具有较强的语义表达能力，能够方便、直接地表达应用中的各种语义知识。 (2) 应该简单、清晰、易于用户理解，是用户与数据库设计人员之间进行交流的语言。 概念模型设计的一种常用方法为IDEF1X方法，它就是把实体-联系方法应用到语义数据模型中的一种语义模型化技术，用于建立系统信息模型。 使用IDEF1X方法创建E-R模型的步骤如下所示: 2.1 第零步——初始化工程

规范和设计技巧在数据库设计的探讨

规范和设计技巧在数据库设计的探讨 摘要医院的信息收集工作在信息化产业中属于非常关键的构成部分，而且这方面的工作水平，能够对医院数据收集的水平起到决定性的作用，而想要做好这方面的工作，就一定要创建完善的数据库，并对其进行完美的规范和设计。具体的讨论一下数据库设计规范化的意义，信息收集的基本要求和存有的缺陷及设计的主要阶段中需要注意的技巧等问题。 关键词企业信息收集工作；数据库设计；信息化 目前，怎样让信息收集工作的质量得到增强，成为了医院发展过程中的一项重要工作。而且随着我国市场化发展的进步，医院的数据库设计也迎来了全新的发展时代，现如今数据收集的复杂化、智能化的实现，是这项工作取得进步的最好证明。该就以企业信息收集的意义为角度，来具体地讨论一下如何对数据库进行规范化的设计。 1数据库设计工作的规范化

在医院信息收集工作中的意义医院在对信息收集的时候，一定要 确保数据能够具有较高的质量，同时还要确保收集的高效率。医院若 想在竞争激烈的环境中保持一定的竞争力，就必须要做好信息收集工作，这样才能够跟得上时代发展的脚步，同时也是医院能够得到持续 发展的重要一步。随着我国现代化水平的提升，信息产业也迎来了发 展机遇。特别是医院的信息收集工作，它独特的信息化特点已经成为 了医院发展的重要构成部分。医院若想完成信息化建设，就一定要和 信息收集工作相结合，如此一来，就可以很大水准地提升工作效率， 而且也能够为长远发展打下一个坚实的基础。另外，数据库设计质量 如何，更是能够决定医院信息化发展的水准，确保数据库设计的质量，可以作信息化建设工作更加的具有意义。不过现在，很多医院在信息 收集工作方面是存有很大的问题，不仅没有体现出其应该具备的效果，而且还对医院的各方面工作造成了一定的影响，影响了医院信息化发展。而之所以会出现这方面的问题，主要的原因在于数据库设计人员 的能力有限。医院之所以开展数据库设计，主要是想让医院能够找到 更多的数据搜索方式，不过这也因此增加了数据库设计工作的难度， 从而让医院的相关工作人员在梳理信息收集工作和信息化建设这两者 的关系上显得并不合理。 怎样以最快的速度让医院获得更加方便的数据收集方式，成为了 相关工作人员急需到的重要工作项目。医院信息收集工作本身具有统 一性，而且所有部分的工作都存有着一定的联系，对于所有医院工作 人员来说，必须要准确的掌握好数据收集工作和信息化建设的关系， 数据库设计工作才能够取得进步。医院的相关负责人若想通过磋商的 办法来解决收集工作和信息化之间的关系，那么就一定要创建出一套 合理的数据库设计规范制度。医院的数据库设计工作在信息化建设中 占据着重要的位置，而从信息收集的角度考虑的话，增强数据库的建设，可以充分展现出其智能化、高效化的重要举措。而且也意味着在

数据库设计和编码规范

数据库设计和编码规范 Version

目录

简介 读者对象 此文档说明书供开发部全体成员阅读。 目的 一个合理的数据库结构设计是保证系统性能的基础。一个好的规范让新手容易进入状态且少犯错，保持团队支持顺畅，系统长久使用后不至于紊乱，让管理者易于在众多对象中，获取所需或理清问题。 同时，定义标准程序也需要团队合作，讨论出大家愿意遵循的规范。随着时间演进，还需要逐步校订与修改规范，让团队运行更为顺畅。 数据库命名规范 团队开发与管理信息系统讲究默契，而制定服务器、数据库对象、变量等命名规则是建立默契的基本。 命名规则是让所有的数据库用户，如数据库管理员、程序设计人员和程序开发人员，可以直观地辨识对象用途。而命名规则大都约定俗成，可以依照公司文化、团队习惯修改并落实。 规范总体要求 1.避免使用系统产品本身的惯例，让用户混淆自定义对象和系统对象或关键词。 例如，存储过程不要以sp_或xp_开头，因为SQL SERVER的系统存储过程以 sp_开头，扩展存储过程以xp_开头。 2.不要使用空白符号、运算符号、中文字、关键词来命名对象。 3.名称不宜过于简略，要让对象的用途直观易懂，但也不宜过长，造成使用不方 便。 4.不用为数据表内字段名称加上数据类型的缩写。 5.名称中最好不要包括中划线。

6.禁止使用[拼音]+[英语]的方式来命名数据库对象或变量。 数据库对象命名规范 我们约定，数据库对象包括表、视图（查询）、存储过程（参数查询）、函数、约束。对象名字由前缀和实际名字组成，长度不超过30。避免中文和保留关键字，做到简洁又有意义。前缀就是要求每种对象有固定的开头字符串，而开头字符串宜短且字数统一。可以讨论一下对各种对象的命名规范，通过后严格按照要求实施。例如：

Powerdesigner数据库建模工具教程

目标: 本文主要介绍PowerDesigner中概念数据模型 CDM的基本概念。 一、概念数据模型概述 数据模型是现实世界中数据特征的抽象。数据模型应该满足三个方面的要求： 1）能够比较真实地模拟现实世界 2）容易为人所理解 3）便于计算机实现 概念数据模型也称信息模型，它以实体－联系(Entity-RelationShip,简称E-R)理论为基础，并对这一理论进行了扩充。它从用户的观点出发对信息进行建模，主要用于数据库的概念级设计。 通常人们先将现实世界抽象为概念世界，然后再将概念世界转为机器世界。换句话说，就是先将现实世界中的客观对象抽象为实体(Entity)和联系(Relationship),它并不依赖于具体的计算机系统或某个DBMS系统，这种模型就是我们所说的CDM;然后再将CDM转换为计算机上某个DBMS所支持的数据模型，这样的模型就是物理数据模型,即PDM。 CDM是一组严格定义的模型元素的集合，这些模型元素精确地描述了系统的静态特性、动态特性以及完整性约束条件等，其中包括了数据结构、数据操作和完整性约束三部分。 1）数据结构表达为实体和属性; 2）数据操作表达为实体中的记录的插入、删除、修改、查询等操作; 3）完整性约束表达为数据的自身完整性约束（如数据类型、检查、规则等）和数据间的参照完整性约束（如联系、继承联系等）;

二、实体、属性及标识符的定义 实体（Entity），也称为实例，对应现实世界中可区别于其他对象的“事件”或“事物”。例如，学校中的每个学生，医院中的每个手术。 每个实体都有用来描述实体特征的一组性质，称之为属性，一个实体由若干个属性来描述。如学生实体可由学号、姓名、性别、出生年月、所在系别、入学年份等属性组成。 实体集（Entity Set）是具体相同类型及相同性质实体的集合。例如学校所有学生的集合可定义为“学生”实体集，“学生”实体集中的每个实体均具有学号、姓名、性别、出生年月、所在系别、入学年份等性质。 实体类型（Entity Type）是实体集中每个实体所具有的共同性质的集合，例如“患者”实体类型为：患者｛门诊号，姓名，性别，年龄，身份证号.............｝。实体是实体类型的一个实例，在含义明确的情况下，实体、实体类型通常互换使用。 实体类型中的每个实体包含唯一标识它的一个或一组属性，这些属性称为实体类型的标识符（Identifier），如“学号”是学生实体类型的标识符，“姓名”、“出生日期”、“信址”共同组成“公民”实体类型的标识符。 有些实体类型可以有几组属性充当标识符，选定其中一组属性作为实体类型的主标识符，其他的作为次标识符。 三、实体、属性及标识符的表达

数据库设计规范和值得注意的问题

如果把企业的数据比做生命所必需的血液，那么数据库的设计就是应用中最重要的一部分。有关数据 库设计的材料汗牛充栋，大学学位课程里也有专门的讲述。不过，就如我们反复强调的那样，再好的 老师也比不过经验的教诲。所以我们最近找了些对数据库设计颇有造诣的专业人士给大家传授一些设 计数据库的技巧和经验。我们的编辑从收到的个反馈中精选了其中的个最佳技巧，并把这些 技巧编写成了本文，为了方便索引其内容划分为个部分： 第部分—设计数据库之前 这一部分罗列了个基本技巧，包括命名规范和明确业务需求等。 第部分—设计数据库表 总共个指南性技巧，涵盖表内字段设计以及应该避免的常见问题等。 第部分—选择键 怎么选择键呢？这里有个技巧专门涉及系统生成的主键的正确用法，还有何时以及如何索引字段 以获得最佳性能等。 第部分—保证数据完整性 讨论如何保持数据库的清晰和健壮，如何把有害数据降低到最小程度。 第部分—各种小技巧 不包括在以上个部分中的其他技巧，五花八门，有了它们希望你的数据库开发工作会更轻松一些。 第部分—设计数据库之前 . 考察现有环境 在设计一个新数据库时，你不但应该仔细研究业务需求而且还要考察现有的系统。大多数数据库 项目都不是从头开始建立的；通常，机构内总会存在用来满足特定需求的现有系统（可能没有实 现自动计算）。显然，现有系统并不完美，否则你就不必再建立新系统了。但是对旧系统的研究 可以让你发现一些可能会忽略的细微问题。一般来说，考察现有系统对你绝对有好处。 — 我曾经接手过一个为地区运输公司开发的数据库项目，活不难，用的是数据库。我设置 了一些项目设计参数，而且同客户一道对这些参数进行了评估，事先还查看了开发环境下所采取 的工作模式，等到最后部署应用的时候，只见终端上出了几个提示符然后立马在我面前翘辫子 了！抓耳挠腮的折腾了好几个小时，我才意识到，原来这家公司的网络上跑着两个数据库应用， 而对网络的访问需要明确和严格的用户帐号及其访问权限。明白了这一点，问题迎刃而解：只需 采用客户的系统即可。这个项目给我的教训就是：记住，假如你在诸如或者这 类公共环境下开发应用程序，一定要从表面下手深入系统内部搞清楚你面临的环境到底是怎

数据库设计规范

数据库设计规范 V 1.0 2007-8-28

目录 1) 目的 (3) 2) 范围 (3) 3) 术语 (3) 4) 设计概要 (3) 5) 命名规范（逻辑对象） (4) 6) 数据库对象命名 (6) 7) 脚本注释 (8) 8) 数据库操作原则 (9) 9) 常用字段命名(参考) (9)

1) 目的 为了统一公司软件开发的设计过程中关于数据库设计时的命名规范和具体工作时的编程规范，便于交流和维护，特制定此规范。 2) 范围 本规范适用于开发组全体人员，作用于软件项目开发的数据库设计、维护阶段。 3) 术语 数据库对象：在数据库软件开发中，数据库服务器端涉及的对象包括物理结构和逻辑结构的对象。 物理结构对象：是指设备管理元素，包括数据文件和事务日志文件的名称、大小、目录规划、所在的服务器计算极名称、镜像等，应该有具体的配置规划。一般对数据库服务器物理设备的管理规程，在整个项目/产品的概要设计阶段予以规划。 逻辑结构对象：是指数据库对象的管理元素，包括数据库名称、表空间、表、字段/域、视图、索引、触发器、存储过程、函数、数据类型、数据库安全性相关的设计、数据库配置有关的设计以及数据库中其他特性处理相关的设计等。 4) 设计概要 ?设计环境 数据库：ORACLE 9i 、MS SQL SERVER 2000 等 操作系统：LINUX 7.1以上版本，显示图形操作界面; RedHat 9 以上版本 WINDOWS 2000 SERVER 以上 ?设计使用工具 使用PowerDesigner 做为数据库的设计工具，要求为主要字段做详尽说 明。对于SQL Server 尽量使用企业管理器对数据库进行设计，并且要求 对表，字段编写详细的说明（这些将作为扩展属性存入SQL Server中） 通过PowerDesigner 定制word格式报表，并导出word文档，作为数据 字典保存。（PowerDesigner v10 才具有定制导出word格式报表的功能）。

数据建模目前有两种比较通用的方式

数据建模目前有两种比较通用的方式1983年，数学建模作为一门独立的课程进入我国高等学校，在清华大学首次开设。1987年高等教育出版社出版了国内第一本《数学模型》教材。20多年来，数学建模工作发展的非常快，许多高校相继开设了数学建模课程，我国从1989年起参加美国数学建模竞赛，1992年国家教委高教司提出在全国普通高等学校开展数学建模竞赛，旨在“培养学生解决实际问题的能力和创新精神，全面提高学生的综合素质”。近年来，数学模型和数学建模这两个术语使用的频率越来越高，而数学模型和数学建模也被广泛地应用于其他学科和社会的各个领域。本文主要介绍了数学建模中常用的方法。 一、数学建模的相关概念 原型就是人们在社会实践中所关心和研究的现实世界中的事物或对象。模型是指为了某个特定目的将原型所具有的本质属性的某一部分信息经过简化、提炼而构造的原型替代物。一个原型，为了不同的目的可以有多种不同的模型。数学模型是指对于现实世界的某一特定对象，为了某个特定目的，进行一些必要的抽象、简化和假设，借助数学语言，运用数学工具建立起来的一个数学结构。 数学建模是指对特定的客观对象建立数学模型的过程，是现实的现象通过心智活动构造出能抓住其重要且有用的特征的表示，常常是形象化的或符号的表示，是构造刻画客观事物原型的数学模型并用以分析、研究和解决实际问题的一种科学方法。 二、教学模型的分类 数学模型从不同的角度可以分成不同的类型，从数学的角度，按建立模型的数学方法主要分为以下几种模型：几何模型、代数模型、规划模型、优化模型、微分方程模型、统计模型、概率模型、图论模型、决策模型等。 三、数学建模的常用方法 1.类比法 数学建模的过程就是把实际问题经过分析、抽象、概括后，用数学语言、数学概念和数学符号表述成数学问题，而表述成什么样的问题取决于思考者解决问题的意图。类比法建模一般在具体分析该实际问题的各个因素的基础上，通过联想、归纳对各因素进行分析，并且与已知模型比较，把未知关系化为已知关系，

数据库设计规范

数据库设计规范 一、数据库设计过程 数据库技术是信息资源管理最有效的手段。数据库设计是指对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，有效存储数据，满足用户信息要求和处理要求。 数据库设计中需求分析阶段综合各个用户的应用需求（现实世界的需求），在概念设计阶段形成独立于机器特点、独立于各个dbms产品的概念模式（信息世界模型），用e-r图来描述。在逻辑设计阶段将e-r图转换成具体的数据库产品支持的数据模型如关系模型，形成数据库逻辑模式。然后根据用户处理的要求，安全性的考虑，在基本表的基础上再建立必要的视图（view）形成数据的外模式。在物理设计阶段根据dbms特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式。 1. 需求分析阶段 需求收集和分析，结果得到数据字典描述的数据需求（和数据流图描述的处理需求）。 需求分析的重点是调查、收集与分析用户在数据管理中的信息要求、处理要求、安全性与完整性要求。 需求分析的方法：调查组织机构情况、调查各部门的业务活动情况、协助用户明确对新系统的各种要求、确定新系统的边界。 常用的调查方法有：跟班作业、开调查会、请专人介绍、询问、设计调查表请用户填写、查阅记录。 分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。自顶向下的结构化分析方法（structured analysis，简称sa方法）从最上层的系统组织机构入手，采用逐层分解的方式分析系统，并把每一层用数据流图和数据字典描述。 数据流图表达了数据和处理过程的关系。系统中的数据则借助数据字典（data dictionary，简称dd）来描述。 数据字典是各类数据描述的集合，它是关于数据库中数据的描述，即元数据，而不是数据本身。数据字典通常包括数据项、数据结构、数据流、数据存储和处理过程五个部分(至少应该包含每个字段的数据类型和在每个表内的主外键)。 数据项描述＝｛数据项名，数据项含义说明，别名，数据类型，长度， 取值范围，取值含义，与其他数据项的逻辑关系｝ 数据结构描述＝｛数据结构名，含义说明，组成:｛数据项或数据结构｝｝ 数据流描述＝｛数据流名，说明，数据流来源，数据流去向， 组成:｛数据结构｝，平均流量，高峰期流量｝ 数据存储描述＝｛数据存储名，说明，编号，流入的数据流，流出的数据流， 组成:｛数据结构｝，数据量，存取方式｝ 处理过程描述＝｛处理过程名，说明，输入:｛数据流｝，输出:｛数据流｝, 处理:｛简要说明｝｝

数据库设计规范

1概述 1.1目的 软件研发数据库设计规范作为数据库设计的操作规范，详细描述了数据库设计过程及结果，用于指导系统设计人员正确理解和开展数据库设计。 1.2适用范围 1.3术语定义 DBMS：数据库管理系统，常用的商业DBMS有Oracle, SQL Server, DB2等。 数据库设计：数据库设计是在给定的应用场景下，构造适用的数据库模式，建立数据库及其应用系统，有效存储数据，满足用户信息要求和处理要求。 概念数据模型：概念数据模型以实体-关系 (Entity-RelationShip,简称E-R)理论为基础，并对这一理论进行了扩充。它从用户的观点出发对信息进行建模，主要用于数据库概念级别的设计，独立于机器和各DBMS产品。可以用Sybase PowerDesigner工具来建立概念数据模型（CDM）。 逻辑数据模型：将概念数据模型转换成具体的数据库产品支持的数据模型，如关系模型，形成数据库逻辑模式。可

以用Sybase PowerDesigner工具直接建立逻辑数据模型（LDM），或者通过CDM转换得到。 物理数据模型：在逻辑数据模型基础上，根据DBMS特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式。可以用Sybase PowerDesigner工具直接建立物理数据模型（PDM），或者通过CDM / LDM转换得到。 2数据库设计原则 按阶段实施并形成该阶段的成果物 一般符合3NF范式要求；兼顾规范与效率 使用公司规定的数据库设计软件工具 命名符合公司标准和项目标准 3数据库设计目标 规范性：一般符合3NF范式要求，减少冗余数据。 高效率：兼顾规范与效率，适当进行反范式化，满足应用系统的性能要求。 紧凑性：例如能用char(10)的就不要用char(20)，提高存储的利用率和系统性能，但同时也要兼顾扩展性和可移植性。 易用性：数据库设计清晰易用，用户和开发人员均能容

数据分析和数据建模

数据分析和数据建模 大数据应用有几个方面，一个是效率提升，帮助企业提升数据处理效率，降低数据存储成本。另外一个是对业务作出指导，例如精准营销，反欺诈，风险管理以及业务提升。过去企业都是通过线下渠道接触客户，客户数据不全，只能利用财务数据进行业务运营分析，缺少围绕客户的个人数据，数据分析应用的领域集中在企业内部经营和财务分析。 大数据应用有几个方面，一个是效率提升，帮助企业提升数据处理效率，降低数据存储成本。另外一个是对业务作出指导，例如精准营销，反欺诈，风险管理以及业务提升。过去企业都是通过线下渠道接触客户，客户数据不全，只能利用财务数据进行业务运营分析，缺少围绕客户的个人数据，数据分析应用的领域集中在企业内部经营和财务分析。 数字时代到来之后，企业经营的各个阶段都可以被记录下来，产品销售的各个环节也被记录下来，客户的消费行为和网上行为都被采集下来。企业拥有了多维度的数据，包括产品销售数据、客户消费数据、客户行为数据、企业运营数据等。拥有数据之后，数据分析成为可能，企业成立了数据分析团队整理数据和建立模型，找到商品和客户之间的关联关系，商品之间关联关系，另外也找到了收入和客户之间的关联关系。典型的数据分析案例如沃尔玛啤酒和尿布、蛋挞和手电筒，Target的判断16岁少女怀孕都是这种关联关系的体现。

关联分析是统计学应用最早的领域，早在1846年伦敦第二次霍乱期间，约翰医生利用霍乱地图找到了霍乱的传播途径，平息了伦敦霍乱，打败了霍乱源于空气污染说的精英，拯救了几万人的生命。伦敦霍乱平息过程中，约翰医生利用了频数分布分析，建立了霍乱地图，从死亡案例分布的密集程度上归纳出病人分布同水井的关系，从而推断出污染的水源是霍乱的主要传播途径，建议移除水井手柄，降低了霍乱发生的概率。 另外一个典型案例是第二次世界大战期间，统计分析学家改造轰炸机。英美联盟从1943年开始对德国的工业城市进行轰炸，但在1943年年底，轰炸机的损失率达到了英美联盟不能承受的程度。轰炸军司令部请来了统计学家，希望利用数据分析来改造轰炸机的结构，降低阵亡率，提高士兵生还率。统计学家利用大尺寸的飞机模型，详细记录了返航轰炸机的损伤情况。统计学家在飞机模型上将轰炸机受到攻击的部位用黑笔标注出来，两个月后，这些标注布满了机身，有的地方标注明显多于其他地方，例如机身和侧翼。有的地方的标注明显少于其他地方，例如驾驶室和发动机。统计学家让军火商来看这个模型，军火商认为应该加固受到更多攻击的地方，但是统计学家建议对标注少的地方进行加固，标注少的原因不是这些地方不容易被击中，而是被击中的这些地方的飞机，很多都没有返航。这些标注少的地方被击中是飞机坠毁的一个主要原因。军火商按照统计学家的建议进行了飞机加固，大大提高了轰炸机返航的比率。以二战著名的B-17轰炸机为例，其阵亡率由26%降到了7%，帮助美军节约了几亿美金，大大提高了士兵的生还率。 一数据分析中的角色和职责 数据分析团队应该在科技部门内部还在业务部门内部一直存在争议。在业务部门内部，对数据场景比较了解，容易找到数据变现的场景，数据分析对业务提升帮助较大，容易出成绩。但是弊端是仅仅对自己部门的业务数据了解，分析只是局限独立的业务单元之内，在数据获取的效率上，数据维度和数据视角方面缺乏全局观，数据的商业视野不大，对公司整体业务的推动发展有限。业务部门的数据分析团队缺少数据技术能力，无法利用最新的大数据计算和分析技术，来实现数

数据库设计的技巧和规范

数据库设计的技巧和规范 第1 部分- 设计数据库之前 1、调研客户的工作环境或研究已有的系统 在设计一个新数据库时，你不但应该仔细研究业务需求而且还要考察现有的系统。大多数数据库项目都不是从头开始建立的；通常，机构内总会存在用来满足特定需求的现有系统（可能没有实现自动计算）。显然，现有系统并不完美，否则你就不必再建立新系统了。但是对旧系统的研究可以让你发现一些可能会忽略的细微问题。一般来说，考察现有系统对你绝对有好处。 2、定义标准的对象命名规范 一定要定义数据库对象的命名规范。对数据库表来说，可给表的别名定义简单规则，可用项目缩写来给表名打前缀，如cjgl_S。表内的列[字段]要针对键采用一整套设计规则。比如，如果字段是数字类型，你可以用_n作为后缀；如果是字符类型则可以采用_c后缀。对列[字段]名应该采用标准的前缀和后缀。再如，假如你的表里有好多“money”字段，你不妨给每个列[字段]增加一个_m 后缀。还有，日期列[字段]最好以d_作为名字打头。 3、在物理实践之前进行逻辑设计 在深入物理设计之前要先进行逻辑设计。随着大量的case 工具不断涌现出来，你的设计也可以达到相当高的逻辑水准，你通常可以从整体上更好地了解数据库设计所需要的方方面面。 4、理解客户需求 在你百分百地确定系统从客户角度满足其需求之前不要在你的ER（实体关系）模式中加入哪怕一个数据表。了解你的用户的业务需求可以在以后的开发阶段节约大量的时间。一旦你明确了业务需求，你就可以自己做出许多决策了。

一旦你认为你已经明确了业务内容，你最好同客户进行一次系统的交流。采用客户的术语并且向他们解释你所想到的和你所听到的。同时还应该用可能、将会和必须等词汇表达出系统的关系基数。这样你就可以让你的客户纠正你自己的理解然后做好下一步的ER设计。 看起来这应该是显而易见的事，但需求就是来自客户（这里要从内部和外部客户的角度考虑）。不要依赖用户写下来的需求，真正的需求在客户的脑袋里。你要让客户解释其需求，而且随着开发的继续，还要经常询问客户保证其需求仍然在开发的目的之中。一个不变的真理是：“只有我看见了我才知道我想要的是什么”必然会导致大量的返工，因为数据库没有达到客户从来没有写下来的需求标准。而更糟的是你对他们需求的解释只属于你自己，而且可能是完全错误的。 5、创建数据字典和ER图 一定要花点时间创建ER图和数据字典。其中至少应该包含每个字段的数据类型和在每个表内的主外键。创建ER图和数据字典确实有点费时但对其他开发人员要了解整个设计却是完全必要的。越早创建越能有助于避免今后面临的可能混乱，从而可以让任何了解数据库的人都明确如何从数据库中获得数据。 有一份诸如ER图等最新文档其重要性如何强调都不过分，这对表明表之间关系很有用，而数据字典则说明了每个字段的用途以及任何可能存在的别名。对以后设计SQL语句来说这是完全必要的。 6、创建模式 一张图表胜过千言万语：开发人员不仅要阅读和实现它，而且还要用它来帮助自己和用户对话。模式有助于提高协作效能，这样在先期的数据库设计中几乎不可能出现大的问题。模式不必弄的很复杂；甚至可以简单到手写在一张纸上就可以了。只是要保证其上的逻辑关系今后能产生效益。

Greenplum数据库设计开发规范

G r e e n p l u m数据库设 计开发规范 集团企业公司编码：（LL3698-KKI1269-TM2483-LUI12689-ITT289-

目录

第一章前言 1.1文档目的 随着Greenplum数据库的正式上线使用。为了保证Greenplum 数据仓库系统平台的平稳运行，保证系统的可靠性、稳定性、可维护性和高性能。特制定本开发规范，以规范基于Greenplum数据库平台的相关应用开发，提高开发质量。 1.2预期读者 Greenplum数据仓库平台应用的设计与开发人员； Greenplum 数据仓库平台的系统管理人员和数据库管理员； Greenplum 数据仓库平台的运行维护人员； 1.3参考资料 参考Greenplum4.3.x版本官方指引： 《GPDB43AdminGuide.pdf》 《GPDB43RefGuide.pdf》 《GPDB43UtilityGuide.pdf》

第二章设计规范 2.1数据库对象数量 数据库对象类型包括数据表、视图、函数、序列、索引等等，在Greenplum数据库中，系统元数据同时保存在Master 服务器和Segment 服务器上，过多的数据库对象会造成系统元数据的膨胀，而过多的系统元数据造成系统运行逐步变慢；同时，类似数据库的备份、恢复、扩容等较大型的操作都导致效率变慢。因此，依据GreenplumDB产品的最佳时间，单个数据库的对象数量，应控制在10万以内。 GP数据库的对象包括：表、视图、索引、分区子表、外部表等。 如果数据表的数量太多，建议按应用域进行分库，尽量将单个数据库的表数量控制在10万以内，可以在一个集群中创建多个数据库。 【备注】：在Greenplum数据库中，一张分区表，在数据库中存储为一张父表、每张分区子表都是一张独立的库表；例如：一张按月进行分区的存储一年数据的表，如果含默认分区，共14张表。 2.2表创建规范 为了避免数据库表数量太多，避免单个数据表的数据量过大，给系统的运行和使用带来困难，在Greenplum数据库中需遵循如下的表创建规范： 1、GP系统表中保存的表名称都是以小写保存。通常SQL语句中表名对大小写不敏感。但不允许在建表语句中使用双引号（“”）包括表

ERwin使用说明(中英文)

Getting Started with ER win (Erwin 入门) by Dr. Peter Wolcott Department of Information Systems and Quantitative Analysis College of Information Science and Technology University of Nebraska at Omaha（由内布拉斯加州的奥马哈大学信息科学与技术学院门的信息系统和定量分析博士彼得著） Introduction （介绍） ER win is a popular data modeling tool used by a number of major companies in Omaha and throughout the world. （Erwin是受奥马哈和世界各地的一些主要的公司欢迎的数据模型工具） The product is currently owned, developed, and marketed by Computer Associates, a leading software developer.（该产品是由具有领导地位的CA软件开发公司拥有、开发和销售） The product supports a variety of aspects of database design, including data modeling, forward engineering (the creation of a database schema and physical database on the basis of a data model), and reverse engineering (the creation of a data model on the basis of an existing database) for a wide variety of relational DBMS, including Microsoft Access, Oracle, DB2, Sybase, and others.该软件为多种多样的关系型数据库管理系统,包括 Microsoft Access,甲骨文,Sybase,DB2,和其他人提供支持数据库设计的各个方面，包括数据建模、正向工程（在现有的数据模型的基础上创建数据模式和物理数据库）和逆向工程（在现在的数据库基础上创建数据模型） This brief tutorial steps you through the process of creating a data model using ER win.（你可以通过这个简单教程中的步骤运用Erwin来创建数据模 型） It will not explain all aspects of ERwin, but will show you the minimum necessary to create and use data models for this class. （这个课程不可能全面地讲解Erwin，但它向你展示了必要的最基本的创建和使用数据模型的知识） It consists of three major segments, which correspond to the project-related assignments in your class: （这个课程由三个主要部分组成，它与有关项目任务相符） 1.Creation of a basic data model (Conceptual data model) 创建一个 基本的数据模型(概念数据模型) 2.Creation of a database schema 建立数据库模式 3.Creation of the database创建数据库