数据库设计时有几大范式

三大范式并不是用来区别的，是关系型数据库里的规范，是为了减少数据冗余。如果三个规范都满足说明的你的数据库比较健全，数据冗余少，后期维护也方便。用多了就知道了。如果一定要记下，记住定义就好。第一范式:确保每列的原子性

如果每列(或者每个属性)都是不可再分的最小数据单元(也称为最小的原子单元),则满足第一范式

例如:顾客表(姓名、编号、地址、)其中"地址"列还可以细分为国家、省、市、区等。

第二范式:在第一范式的基础上更进一层,目标是确保表中的每列都和主键相关

如果一个关系满足第一范式,并且除了主键以外的其它列,都依赖于该主键,则满足第二范式

例如:订单表(订单编号、产品编号、定购日期、价格、)，"订单编号"为主键，"产品编号"和主键列没有直接的关系，即"产品编号"列不依赖于主键列，应删除该列。

第三范式:在第二范式的基础上更进一层,目标是确保每列都和主键列直接相关,而不是间接相关

如果一个关系满足第二范式,并且除了主键以外的其它列都不依赖于主键列,则满足第三范式

为了理解第三范式，需要根据Armstrong公里之一定义传递依赖。假设A、B和C是关系R的三个属性，如果A-〉B且B-〉C，则从这些函数依赖中，可以得出A-〉C，如上所述，依赖A-〉C是传递依赖。

数据库设计(Database Design)是指对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，使之能够有效地存储数据，满足各种用户的应用需求（信息要求和处理要求）。

在数据库领域内，常常把使用数据库的各类系统统称为数据库应用系统。

一、数据库和信息系统

(1)数据库是信息系统的核心和基础，把信息系统中大量的数据按一定的模型组织起来，提供存储、维护、检索数据的

功能，使信息系统可以方便、及时、准确地从数据库中获得所需的信息。

(2)数据库是信息系统的各个部分能否紧密地结合在一起以及如何结合的关键所在。

(3)数据库设计是信息系统开发和建设的重要组成部分。

(4)数据库设计人员应该具备的技术和知识：

数据库的基本知识和数据库设计技术

计算机科学的基础知识和程序设计的方法和技巧

软件工程的原理和方法

应用领域的知识

二、数据库设计的特点

数据库建设是硬件、软件和干件的结合

三分技术，七分管理，十二分基础数据

技术与管理的界面称之为“干件”

数据库设计应该与应用系统设计相结合

结构（数据）设计：设计数据库框架或数据库结构

行为（处理）设计：设计应用程序、事务处理等

结构和行为分离的设计

传统的软件工程忽视对应用中数据语义的分析和抽象，只要有可能就尽量推迟数据结构设计的决策早期的数据库设计致力于数据模型和建模方法研究，忽视了对行为的设计

如图：

三、数据库设计方法简述

手工试凑法

设计质量与设计人员的经验和水平有直接关系

缺乏科学理论和工程方法的支持，工程的质量难以保证

数据库运行一段时间后常常又不同程度地发现各种问题，增加了维护代价

规范设计法

手工设计方

基本思想

过程迭代和逐步求精

规范设计法(续)

典型方法：

(1)新奥尔良（New Orleans）方法：将数据库设计分为四个阶段

SBYao方法：将数据库设计分为五个步骤

IRPalmer方法：把数据库设计当成一步接一步的过程

(2)计算机辅助设计

ORACLE Designer 2000

SYBASE PowerDesigner

四、数据库设计的基本步骤

数据库设计的过程(六个阶段)

1需求分析阶段

准确了解与分析用户需求（包括数据与处理）

是整个设计过程的基础，是最困难、最耗费时间的一步

2概念结构设计阶段

是整个数据库设计的关键

通过对用户需求进行综合、归纳与抽象，形成一个独立于具体DBMS的概念模型

3逻辑结构设计阶段

将概念结构转换为某个DBMS所支持的数据模型

对其进行优化

4数据库物理设计阶段

为逻辑数据模型选取一个最适合应用环境的物理结构（包括存储结构和存取方法）

5数据库实施阶段

运用DBMS提供的数据语言、工具及宿主语言，根据逻辑设计和物理设计的结果

建立数据库，编制与调试应用程序，组织数据入库，并进行试运行

6数据库运行和维护阶段

数据库应用系统经过试运行后即可投入正式运行。

在数据库系统运行过程中必须不断地对其进行评价、调整与修改

设计特点:

在设计过程中把数据库的设计和对数据库中数据处理的设计紧密结合起来将这两个方面的需求分析、抽象、设计、实现在各个阶段同时进行，相互参照，相互补充，以完善两方面的设计

设计过程各个阶段的设计描述：

如图：

五、数据库各级模式的形成过程

1需求分析阶段：综合各个用户的应用需求

2概念设计阶段：形成独立于机器特点，独立于各个DBMS产品的概念模式(E-R图)

3逻辑设计阶段：首先将E-R图转换成具体的数据库产品支持的数据模型，如关系模型，形成数据库逻辑模式；然后根据用户处理的要求、安全性的考虑，在基本表的基础上再建立必要的视图(View)，形成数据的外模式

4物理设计阶段：根据DBMS特点和处理的需要，进行物理存储安排，建立索引，形成数据库内模式

六、数据库设计技巧

1 设计数据库之前（需求分析阶段）

1) 理解客户需求，询问用户如何看待未来需求变化。让客户解释其需求，而且随着开发的继续，还要经常询问客户保证其需求仍然在开发的目的之中。

2) 了解企业业务可以在以后的开发阶段节约大量的时间。

3) 重视输入输出。

在定义数据库表和字段需求（输入）时，首先应检查现有的或者已经设计出的报表、查询和视图（输出）以决定为了支持这些输出哪些是必要的表和字段。

举例：假如客户需要一个报表按照邮政编码排序、分段和求和，你要保证其中包括了单独的邮政编码字段而不要把邮政编码糅进地址字段里。

4) 创建数据字典和ER 图表

ER 图表和数据字典可以让任何了解数据库的人都明确如何从数据库中获得数据。ER图对表明表之间关系很有用，而数据字典则说明了每个字段的用途以及任何可能存在的别名。对SQL 表达式的文档化来说这是完全必要的。

5) 定义标准的对象命名规范

数据库各种对象的命名必须规范。

2 表和字段的设计（数据库逻辑设计）

表设计原则

1) 标准化和规范化

数据的标准化有助于消除数据库中的数据冗余。标准化有好几种形式，但Third Normal Form（3NF）通常被认为在性能、扩展性和数据完整性方面达到了最好平衡。简单来说，遵守3NF 标准的数据库的表设计原则是：“One Fact in One Place”即某个表只包括其本身基本的属性，当不是它们本身所具有的属性时需进行分解。表之间的关系通过外键相连接。它具有以下特点：有一组表专门存放通过键连接起来的关联数据。

举例：某个存放客户及其有关定单的3NF 数据库就可能有两个表：Customer 和Order。Order 表不包含定单关联客户的任何信息，但表内会存放一个键值，该键指向Customer 表里包含该客户信息的那一行。

事实上，为了效率的缘故，对表不进行标准化有时也是必要的。

2) 数据驱动

采用数据驱动而非硬编码的方式，许多策略变更和维护都会方便得多，大大增强系统的灵活性和扩展性。

举例，假如用户界面要访问外部数据源（文件、XML 文档、其他数据库等），不妨把相应的连接和路径信息存储在用户界面支持表里。还有，如果用户界面执行工作流之类的任务（发送邮件、打印信笺、修改记录状态等），那么产生工作流的数据也可以存放在数据库里。角色权限管理也可以通过数据驱动来完成。事实上，如果过程是数据驱动的，你就可以把相当大的责任推给用户，由用户来维护自己的工作流过程。

3) 考虑各种变化

在设计数据库的时候考虑到哪些数据字段将来可能会发生变更。

举例，姓氏就是如此（注意是西方人的姓氏，比如女性结婚后从夫姓等）。所以，在建立系统存储客户信息时，在单独的一个数据表里存储姓氏字段，而且还附加起始日和终止日等字段，这样就可以跟踪这一数据条目的变化。

字段设计原则

4) 每个表中都应该添加的3 个有用的字段

dRecordCreationDate，在VB 下默认是Now()，而在SQL Server • 下默认为GETDATE()

sRecordCreator，在SQL Server 下默认为NOT NULL DEFAULT • USER

nRecordVersion，记录的版本标记；有助于准确说明记录中出现null 数据或者丢失数据的原因 •

5) 对地址和电话采用多个字段

描述街道地址就短短一行记录是不够的。Address_Line1、Address_Line2 和Address_Line3 可以提供更大的灵活性。还有，电话号码和邮件地址最好拥有自己的数据表，其间具有自身的类型和标记类别。

6) 使用角色实体定义属于某类别的列

在需要对属于特定类别或者具有特定角色的事物做定义时，可以用角色实体来创建特定的时间关联关系，从而可以实现自我文档化。

举例：用PERSON 实体和PERSON_TYPE 实体来描述人员。比方说，当John Smith, Engineer 提升为John Smith, Director 乃至最后爬到John Smith, CIO 的高位，而所有你要做的不过是改变两个表PERSON 和PERSON_TYPE 之间关系的键值，同时增加一个日期/时间字段来知道变化是何时发生的。这样，你的PERSON_TYPE 表就包含了所有PERSON 的可能类型，比如Associate、Engineer、Director、CIO 或者CEO 等。还有个替代办法就是改变PERSON 记录来反映新头衔的变化，不过这样一来在时间上无法跟踪个人所处位置的具体时间。

7) 选择数字类型和文本类型尽量充足

在SQL 中使用smallint 和tinyint 类型要特别小心。比如，假如想看看月销售总额，总额字段类型是smallint，那么，如果总额超过了$32,767 就不能进行计算 *** 作了。

而ID 类型的文本字段，比如客户ID 或定单号等等都应该设置得比一般想象更大。假设客户ID 为10 位数长。那你应该把数据库表字段的长度设为12 或者13 个字符长。但这额外占据的空间却无需将来重构整个数据库就可以实现数据库规模的增长了。

8) 增加删除标记字段

在表中包含一个“删除标记”字段，这样就可以把行标记为删除。在关系数据库里不要单独删除某一行；最好采用清除数据程序而且要仔细维护索引整体性。

3 选择键和索引（数据库逻辑设计）

键选择原则：

1) 键设计4 原则

为关联字段创建外键。 •

所有的键都必须唯一。 •

避免使用复合键。 •

外键总是关联唯一的键字段。 •

2) 使用系统生成的主键

设计数据库的时候采用系统生成的键作为主键，那么实际控制了数据库的索引完整性。这样，数据库和非人工机制就有效地控制了对存储数据中每一行的访问。采用系统生成键作为主键还有一个优点：当拥有一致的键结构时，找到逻辑缺陷很容易。

3) 不要用用户的键(不让主键具有可更新性)

在确定采用什么字段作为表的键的时候，可一定要小心用户将要编辑的字段。通常的情况下不要选择用户可编辑的字段作为键。

4) 可选键有时可做主键

把可选键进一步用做主键，可以拥有建立强大索引的能力。

索引使用原则：

索引是从数据库中获取数据的最高效方式之一。95%的数据库性能问题都可以采用索引技术得到解决。

1) 逻辑主键使用唯一的成组索引，对系统键（作为存储过程）采用唯一的非成组索引，对任何外键列采用非成组索引。考虑数据库的空间有多大，表如何进行访问，还有这些访问是否主要用作读写。

2) 大多数数据库都索引自动创建的主键字段，但是可别忘了索引外键，它们也是经常使用的键，比如运行查询显示主表和所有关联表的某条记录就用得上。

3) 不要索引memo/note 字段，不要索引大型字段（有很多字符），这样作会让索引占用太多的存储空间。

4) 不要索引常用的小型表

不要为小型数据表设置任何键，假如它们经常有插入和删除 *** 作就更别这样作了。对这些插入和删除 *** 作的索引维护可能比扫描表空间消耗更多的时间。

4 数据完整性设计（数据库逻辑设计）

1) 完整性实现机制：

实体完整性：主键

参照完整性：

父表中删除数据：级联删除；受限删除；置空值

父表中插入数据：受限插入；递归插入

父表中更新数据：级联更新；受限更新；置空值

DBMS对参照完整性可以有两种方法实现：外键实现机制（约束规则）和触发器实现机制

用户定义完整性：

NOT NULL；CHECK；触发器

2) 用约束而非商务规则强制数据完整性

采用数据库系统实现数据的完整性。这不但包括通过标准化实现的完整性而且还包括数据的功能性。在写数据的时候还可以增加触发器来保证数据的正确性。不要依赖于商务层保证数据完整性；它不能保证表之间（外键）的完整性所以不能强加于其他完整性规则之上。

3) 强制指示完整性

在有害数据进入数据库之前将其剔除。激活数据库系统的指示完整性特性。这样可以保持数据的清洁而能迫使开发人员投入更多的时间处理错误条件。

4) 使用查找控制数据完整性

控制数据完整性的最佳方式就是限制用户的选择。只要有可能都应该提供给用户一个清晰的价值列表供其选择。这样将减少键入代码的错误和误解同时提供数据的一致性。某些公共数据特别适合查找：国家代码、状态代码等。

5) 采用视图

为了在数据库和应用程序代码之间提供另一层抽象，可以为应用程序建立专门的视图而不必非要应用程序直接访问数据表。这样做还等于在处理数据库变更时给你提供了更多的自由。

5 其他设计技巧

1) 避免使用触发器

触发器的功能通常可以用其他方式实现。在调试程序时触发器可能成为干扰。假如你确实需要采用触发器，你最好集中对它文档化。

2) 使用常用英语（或者其他任何语言）而不要使用编码

在创建下拉菜单、列表、报表时最好按照英语名排序。假如需要编码，可以在编码旁附上用户知道的英语。

3) 保存常用信息

让一个表专门存放一般数据库信息非常有用。在这个表里存放数据库当前版本、最近检查/修复（对Access）、关联设计文档的名称、客户等信息。这样可以实现一种简单机制跟踪数据库，当客户抱怨他们的数据库没有达到希望的要求而与你联系时，这样做对非客户机/服务器环境特别有用。

4) 包含版本机制

在数据库中引入版本控制机制来确定使用中的数据库的版本。时间一长，用户的需求总是会改变的。最终可能会要求修改数据库结构。把版本信息直接存放到数据库中更为方便。

5) 编制文档

对所有的快捷方式、命名规范、限制和函数都要编制文档。

采用给表、列、触发器等加注释的数据库工具。对开发、支持和跟踪修改非常有用。

对数据库文档化，或者在数据库自身的内部或者单独建立文档。这样，当过了一年多时间后再回过头来做第2 个版本，犯错的机会将大大减少。

6) 测试、测试、反复测试

建立或者修订数据库之后，必须用用户新输入的数据测试数据字段。最重要的是，让用户进行测试并且同用户一道保证选择的数据类型满足商业要求。测试需要在把新数据库投入实际服务之前完成。

7) 检查设计

在开发期间检查数据库设计的常用技术是通过其所支持的应用程序原型检查数据库。换句话说，针对每一种最终表达数据的原型应用，保证你检查了数据模型并且查看如何取出数据。

数据库关系模型(数据库逻辑模型)是将数据概念模型转换为所使用的数据库管理系统(DBMS)支持的数据库逻辑结构,即将E-R图表示成关系数据库模式。数据库逻辑设计的结果不是唯一的,需利用规范化理论对数据库结构进行优化。

在关系模型中,数据库的逻辑结构是一张二维表。在数据库中,满足下列条件的二维表称为关系模型:

1)每列中的分量是类型相同的数据;

2)列的顺序可以是任意的;

3)行的顺序可以是任意的;

4)表中的分量是不可再分割的最小数据项,即表中不允许有子表;

5)表中的任意两行不能完全相同。

由此可见,有序的航空物探测量剖面数据不满足数据库关系模型条件第3条“行的顺序可以是任意的”,因此,不能简单地直接利用关系数据库(如Oracle,SQL Server,Sybase等)来管理剖面数据,需将数据在数据库中的存储方式改为大字段存储,确保不因数据库数据的增加和删除等 *** 作改变剖面数据有序特性。

一、大字段存储

(一)大字段存储技术

大字段LOB(Large Object)技术是Oracle专门用于存放处理大对象类型数据(如多媒体材料、影像资料、文档资料等)的数据管理技术。LOB包括内部的和外部的两种类型。内部LOB又分CLOB(字符型)、BLOB(二进制型)等3种数据类型,其数据存储在数据库中,并且支持事务 *** 作;外部LOB只有BFILE类型,其数据存储在 *** 作系统中,并且不支持事务 *** 作。LOB存放数据的长度最大可以达到4G字节,并且空值列(没有存放数据)不占空间(图2-6)。

图2-6 大字段存储示意图

由于外部LOB存放在 *** 作系统文件中,其安全性比内部LOB差一些。此外,大字段的存储支持事务 *** 作(批量提交和回滚等),而外部LOB不支持事务 *** 作。所以,航空物探测量剖面数据采用BLOB来存储。对于BLOB类型,如果数据量小于4000字节,数据库通常采用行内存储,而数据量大于4000字节采用行外存储。分析航空物探测量剖面数据,每个场值数据占4个字节(单精度),目前航磁数据采样率为10次/s,4000字节只能存储100s数据;一般情况下航空物探测量每条测线飞行时间至少在10min以上,每条测线数据量远远大于4000字节。所以,航空物探测量剖面数据采用行外存储方式,即大字段列指定“Disable Storage In Row”的存储参数。

由于大字段类型长度可变,最大可到4G。假设测线飞行时间为T,场值采样率为n次/s,测线场值数据量为4Tn,所以有4Tn≤4G。单条测线飞行时间T不会超过10h(36000s,航空物探测量1架次至少飞行1个往返2条测线),则场值的采样率n≤4G/4T=4×1024×1024×1024/4×36000次/s=29826次/s。采用大字段来存储测量数据,不仅能够减少数据表的记录数,提高查询效率,而且使得采样率的扩展不受限制。

(二)大字段存储技术应用

由于航空物探数据的数据量较大,现有的航磁测量数据按基准点方式(点存储)存储可达几亿个数据记录。若按磁场数据采样点存储方式(简称“场值存储方式”),则记录条数=(磁场数据采样率/坐标采样率)点存储方式的记录数,达几十亿条数据记录,且随着数据采样率的扩展、测点的加密,航空物探测量数据量随着时间的推移呈现快速增长之势。显然,如果采用常规的表结构来存储,势必造成数据的存储、管理、检索、浏览和提取都非常困难。另一方面,从航空物探专业应用需求来说,很少对单个测点的场值数据进行运算、分析等 *** 作,一般至少是对一条测线或以上测线,多数时候是需要对整个测区的场值数据进行化极、上延、正反演拟合等。

因此,在航空物探数据库表结构设计时,改变过去将基准点或场值点数据记录作为数据库最小管理对象的理念,采用了大字段存储技术,将测线作为数据库最小管理对象,将测线上的测量数据,如坐标数据和磁场、重力场数据分别存储在相应大字段中。在航空物探数据库建设中,大量采用数据库的大字段存储技术(详见《航空物探信息系统数据库结构设计》)。

(三)大字段存储效率

以航磁测量数据为例分析大字段存储技术优势。如果以场值存储方式存储测线数据,则每条记录包含架次号、测线号、基准号、地理坐标、投影坐标、磁场数据等,由于坐标数据采样率2次/s,磁场数据采样率10次/s,每5个磁场数据中,只有第1个磁场数据有坐标数据,其他4个坐标数据是内插出来,因此在测线记录中会产生大量冗余的数据坐标数据。采用点存储方式存储的测线数据记录数等于线上基准点数,若采用大字段存储方式,一条测线数据只存储为1条数据记录(图2-7),一般一条测线的测点数近万个,甚至更多,可见采用大字段存储大大减少测线数据存储记录数,提高数据的存取效率。

以某测区的两条航迹线为例,分别采用3种方式测试数据库的数据存储效率。磁场数据的采样率10次/s,坐标数据采样率2次/s,两条测线上共有基准点8801个。以场值方式存储先内插坐标信息,使得每个场值数据都拥有自己的坐标,然后存入数据库,共有数据记录44005条,写入数据库时间为5722s,读取时间为103s。第二种方式是以采样点的方式进行存储,共有8801条记录,写入数据库时间为947s,读取需要091s。第三种方式是以大字段的形式存储,只有2条记录,写入数据库103s,读取时间为044s(表2-2)。大字段数据存储记录数最少,存取效率最高。用整个测区数据测试效果更加明显。

表2-2 三种数据存储方法的存取效率比较

图2-7 大字段存储方式示意图

二、联合主键

主外键是关系型数据库建立表间关系的核心。在航空物探空间数据库建设过程中,要素类与要素类之间、要素类与对象类之间,以及对象类与对象类之间的关系的描述有3种形式,即拓扑关系——描述要素类与要素类之间结点、邻接和联通关系;叠加关系——描述要素类与要素类之间的相交、包含与分类关系;隶属关系——描述对象类与对象类之间的派生关系。前两种关系是采用空间数据模型建立的关系,而隶属关系是通过主键建立的对象类与对象类之间的关系。在建立一对一、一对多的表间关系时,需要在整个数据库表中确定具有唯一性的一个字段作为主键(主关键字)。

按照传统的航空物探数据的档案管理模式,每个项目分配一个自然数作为档案号,项目的所有资料均与此档案号相联系。勘查项目和科研项目的档案号是独立编号的,且均从001开始。加之人工管理的原因,存在1个项目2个档案号和2个项目1个档案号的情况,因此现行的档案号与项目之间的对应关系不具备唯一性,不能作为项目的唯一标识,即不能作为数据库表的主键。项目编号也不能作为数据库表的主键,项目编号也只是近十年的事,以前的项目没有项目编号。

综合考虑上述因素和项目具有分级、分类的特点,提出了构造项目唯一标识码(简称“项目标识”)的方法,并以此码作为数据库表的主键。

项目标识(主键):AGS+项目类别(2位)+项目起始年份(4位)+档案号(6位)

标识含义:AGS——航空物探的缩位代码;

项目类别——2位代码,01代表勘查项目、02代表科研项目;

起始年份—4位代码,项目开始年号;

档案号—6位代码,为了与传统的项目管理方式相衔接,后面3~4位是

项目档案管理模式下的档案号,不足部分补零。

以上15位编码是一级项目的项目标识,二级及其以下级别的项目标识是在上一级项目标识基础上扩展2位数字代码,中间用“”号隔开,数字为该级项目的序号。项目标识定义为30位编码,适用于六级以内的项目。例如:AGS022004000576080402,表示该项目为2004年开展的档案号为576的航空物探科研项目(一级项目)的第8课题(二级项目)第4子课题(三级项目)的第2专题。由此可见,该项目标识不仅仅是一个建立表间关系的关键字,同时还表达了不同级别项目间的隶属关系。在系统软件开发时,利用此关系生成了项目的分级树形目录,用户对项目的层次关系一目了然,便于项目查询。

数据库的主键一经确定,相应地需要确定联合主键的组成及其表达方式。所谓联合主键就是数据资料的唯一标识,在一个数据库表中选择2个或者2个以上的字段作为主键。由于航空物探数据绝大部分与项目标识有关,加之数据的种类较多,分类复杂,单凭主键确定数据库表中记录的唯一性,势必需要构建极其复杂的主键,这种方法既不利于主键的数据 *** 作,又会造成大量的数据冗余,合理地使用联合主键技术可以很好地解决资料唯一问题。以项目提交资料为例,提交的资料分为文字类资料、图件类资料和媒体类资料,我们对资料进行分类和编号,例如100代表文字资料(110——World文档,120——PDF文档),200代表图件资料(210——基础地理资料、220——基础地质资料,230——航迹线图,240——剖面图,250——等值线图等),300代表媒体资料(310——PPT文档,320——照片等),第1位(百位)表示该资料的类型,第2~3位表示该类资料的序号。

在数据库管理和项目资料查询时,采用项目标识与资料分类编号作为联合主键(图2-8),可以高效地实现复杂数据的查询。在整个数据库系统中多处(项目查询、数据提取等模块)使用联合主键技术。

图2-8 联合主键实例

三、信息标准化

为了实现数据共享,在航空物探数据库建模过程中,参考和引用了近百个国家信息化标准,编制了4个中心信息化标准和1个图件信息化工作指南。

(一)引用的国家信息化标准

1)地质矿产术语分类代码:地球物理勘查,地球化学勘查,大地构造学,工程地质学,结晶学及矿物学,矿床学,水文地质学,岩石学,地质学等。

2)国家基础信息数据分类与代码,国土基础信息数据分类与代码,地球物理勘查技术符号,地面重力测量规范,地面磁勘查技术规程,地面高精度磁测技术规程,大比例尺重力勘查规范,地理信息技术基本术语,地理点位置的纬度、经度和高程的标准表示法,地名分类与类别代码编制规则。

3)地球空间数据交换格式;数学数字地理底图数据交换格式;数字化地质图图层及属性文件格式。

(二)本系统建立的信息化标准

编写了“航空物探空间数据要素类和对象类划分标准”,“航空物探项目管理和资料管理分类代码标准”,“航空物探勘查分类代码标准”,“航空物探信息系统元数据标准”,“航空物探图件信息化工作指南”,以便与其他应用系统进行信息交换,实现数据库资料共享。

航空物探空间数据要素类和对象类划分标准:根据物探方法、数据处理过程以及推断解释方法和过程,把与GIS有关的数据划分为不同类型的要素类-对象类数据,按专业、比例尺、数据内容对要素类和对象类进行统一命名,使空间数据库中的每个要素类和对象类的命名具有唯一性,防止重名出现。规定要素类-对象类数据库表结构及数据项数值类型。

航空物探项目管理和资料管理分类代码标准:规定了航空物探项目管理和资料管理的相关内容,包括航空物探勘查项目和科研项目的项目立项、设计、实施、成果、评审、资料汇交等项目管理的全过程中的内容,以及项目成果资料和收集资料的归档、发送、销毁、借阅等资料管理与服务过程中的内容和数据项代码。

航空物探勘查分类代码标准:在“地质矿产术语分类代码地球物理勘查”(国家标准GB/T964928—1998)增加了航磁、航重专业方面所涉及的数据采集、物性参数、方法手段、仪器设备、资料数据解释及成图图件等内容和数据项代码。

航空物探信息系统元数据标准:规定了航空物探空间数据管理与服务的元数据(数据的标识、内容、质量、状况及其他有关特征)的内容。

四、航迹线数据模型

(一)航迹线模型的结构

航空物探测量是依据测量比例尺在测区内布置测网(测线和切割线)。当飞机沿着设计的测线飞行测量时,航空物探数据收录系统按照一定的采样率采集采样点的地理位置、高度和各种地球物理场信息。采用属性数据分置的方法,将测线地理位置信息从航空物探测量数据中分离出来,形成航迹线要素类表,在此表中只存储与航迹线要素类有关的数据,如项目标识、测区编号、测线号、测线类型(用于区分测线、切割线、不同高度线、重复线等)、坐标、高度值等;将航迹线的对象类数据(磁场、重力场基础数据)分别以大字段形式存储在各自的二维表中,它们共享航迹线,解决了多源有序不同采样率的航空物探测量数据的数据存储问题,在满足要素类空间查询的同时,统一数据的存储方式(图2-9)。航迹线要素类隶属于测区要素类,它们之间为空间拓扑(包含)关系。测区从属于勘查项目,每个勘查项目至少有一个测区,它们之间为1对多关系。有关项目信息存放在项目概况信息对象类表中,各种表之间通过项目标识进行联接。

图2-9 航迹线数据模型结构

(二)航迹线的UML模型

统一建模语言UML(Unified Modeling Language)是一种定义良好、易于表达、功能强大且普遍适用的建模语言。它溶入了软件工程领域的新思想、新方法和新技术。UML是面向对象技术领域内占主导地位的标准建模语言,成为可视化建模语言的工业标准。在UML基础上,ESRI定义了空间数据库建模的ArcGIS包、类库和扩展原则。

图2-10 与航迹线有关的数据库表逻辑模型结构图

在确定航迹线数据模型后,以它为基础,使用UML完成与航迹的有关的项目概况信息、测区信息、原始数据等数据库表逻辑模型设计(图2-10)。

由UML模型生成Geodatabase模式时,模型中的每个类都对应生成一个要素类或对象类。类的属性映射为要素类或对象类的字段。基类属性中包含的字段,在继承类中不需重复创建。例如,每个类都包括项目标识等字段,可以创建一个包含公共属性的基类,其他类从该类继承公共的属性,而无需重复建基类中包含的属性。因为基类没有对应的要素类或对象类,所以将基类设置为抽象类型。要素类之间的关系采用依赖关系表示。

五、数据库逻辑模型

关系数据库的逻辑结构由一组关系模式组成,因而从概念结构到关系数据库逻辑结构的转换就是将概念设计中所得到的概念结构(ER图)转换成等价的UML关系模式(图2-11)。在UML模型图中,要素数据集用Geodatabase工作空间下的静态包表示。要素集包不能互相嵌套,为了容易组织,在生成物理模型后,在要素数据集包中自定义嵌套。要素数据集与空间参考有关,但是空间参考不能在UML中表达。要素类和二维表都是以类的形式创建的,区别是要素类继承Feature Class的属性,而二维表继承Object属性。为了表达每种元素的额外属性,比如设置字符型属性字段的字符串长度,设置要素类的几何类型(点、线或面)需要使用Geodatabase预定义的元素标记值。

图2-11 逻辑设计关系转换

基于航空物探数据的内在逻辑关系进行分析,使用统一建模语言(UML)构建数据实体对象间的关系类,定义了航空物探数据库的逻辑模型(图2-12)。

Access method（访问方法）：此步骤包括从文件中存储和检索记录。

Alias（别名）：某属性的另一个名字。在SQL中，可以用别名替换表名。

Alternate keys（备用键，ER/关系模型）：在实体/表中没有被选为主健的候选键。

Anomalies（异常）参见更新异常（update anomalies）

Application design（应用程序设计）：数据库应用程序生命周期的一个阶段，包括设计用户界面以及使用和处理数据库的应用程序。

Attribute（属性）（关系模型）：属性是关系中命名的列。

Attribute（属性）（ER模型）：实体或关系中的一个性质。

Attribute inheritance（属性继承）：子类成员可以拥有其特有的属性，并且继承那些与超类有关的属性的过程。

Base table（基本表）：一个命名的表，其记录物理的存储在数据库中。

Binary relationship（二元关系）：一个ER术语，用于描述两个实体间的关系。例如，panch Has Staff。

Bottom-up approach（自底向上方法）：用于数据库设计，一种设计方法学，他从标识每个设计组建开始，然后将这些组件聚合成一个大的单元。在数据库设计中，可以从表示属性开始底层设计，然后将这些属性组合在一起构成代表实体和关系的表。

Business rules（业务规则）：由用户或数据库的管理者指定的附加规则。

Candidate key（候选键，ER关系模型）：仅包含标识实体所必须得最小数量的属性/列的超键。

Cardinality（基数）：描述每个参与实体的可能的关系数目。

Centralized approach（集中化方法,用于数据库设计）：将每个用户试图的需求合并成新数据库应用程序的一个需求集合

Chasm trap（深坑陷阱）：假设实体间存在一根，但某些实体间不存在通路。

Client（客户端）：向一个或多个服务器请求服务的软件应用程序。

Clustering field（群集字段）：记录总的任何用于群集（集合）航记录的非键字段，这些行在这个字段上有相同的值。

Clustering index（群集索引）：在文件的群集字段上定义的索引。一个文件最多有一个主索引或一个群集索引。

Column（列）：参加属性（attribute）。

Complex relationship（复杂关系）：度数大于2的关系。

Composite attribute（复合属性）：由多个简单组件组成的属性。

Composite key（复合键）：包含多个列的主健。

Concurrency control（并发控制）：在多用户环境下同时执行多个十五并保证数据完整性的一个DBMS服务。

Constraint（约束）：数据库不允许包含错误数据的一致性规则。

Data conversion and loading（数据转换和加载）：数据库应用生命周期重的一个阶段，包括转换现有数据到新数据库中以及酱下耨应用程序转换到新的数据库上运行。

Data dictionary（数据字典）：参见系统目录（system catalog）。

Data independence（数据独立性）：使用数据的应用程序的数据描述部分。这意味着，如果将新的数据结构添加到数据库中，或者数据库中现有的结构被修改了，那么使用此数据库的就会受到影响，除非应用程序不直接依赖于被修改的部分。

Data model（数据模型）：描述数据、数据间关系以及数据的约束的概念的一个集成的集合。

Data redundancy（数据冗余）：参见冗余数据（redundant data）。

Data security（数据安全）：包括对数据库对象（如表和视图）的访问和使用以及用户可以在这些对象上实施的 *** 作。

Database（数据库）：是逻辑上相关的数据（以及这些数据的描述）的一个共享的集合，用于解决公司对信息的需求。

Database design（数据库设计）：数据库应用生命周期中的一个阶段，包括创建一个支持公司的 *** 作和目标的数据库的设计。

Database integrity（数据库完整性）：指存储数据的正确定和一致性。完整性通常用约束来表达。

Database Management System，DBMS（数据库管理系统）：一个能够让用户定义、创建和维护数据库并控制对数据库的访问的软件系统。

Database planning（数据库规划）：能尽可能有效的实现数据库应用的各阶段的管理活动。

Database server（数据库服务器）：同服务器。

DBMS engine（DBMS引擎）：同服务器。

DBMS selection（DBMS选择）：数据库应用生命周期中的一个阶段，包括选择一个合适的DBMS来支持数据库应用。

Degree of a relationship（关系的度）：一个关系中参与的实体的个数。

Denormalization（反规范化）：形式上，这个术语指的是对基本表结构的修改，这样新的表比原始的表的规范化程度要低。但也可以用此属于更宽泛地形容将两个表和并成一个新表的情形，而这个新表与原来的表具有相同的范式，但比原表包含更多的空值。

Derived attribute（派生属性）：表示其值可以从一个相关属性和属性集的值派生得到的属性，这个属性在实体中不是必须的。

Design methodology（设计方法学）：一种结构化的方法，它使用过程、工具和文档来支持和简化设计过程。

Disjoint constraint（无连接约束）：描述子类的成员间的关系，并指明超类某个成员是否有可能成为一个或多个子类的成员。

Domain（域）：一个或多个属性的取值范围。

Entity（实体）：具有相同性质的对象的集合，它是由用户或公司标识并可独立存在的。

Entity integrity（实体完整性）：在一个基本表中，主健列的值不能为空。

Entity occurrence（实体出现）：实体中的一个可标识的对象。

Entity-Relationship model（实体关系模型）：公司的实体、属性和关系的详细逻辑表示。

Fact-finding（事实发现）：使用诸如面谈和提问等技术收集关于系统的事实、需求和性能的形式化过程。

Fan trap（扇形陷阱）：但从第三个实体扇出的两个实体有1:关系时出现扇形陷阱，但这两个实体在他们之间应该有直接关系以提供必要的信息。

Field（字段）：同元组（Tuple）。

File（文件）：存储在副主存储器中的相关记录的一个命名集合。

File-based system（基于文件的系统）：一个文件集合，用来管理（创建、插入、删除、更新和检索）一个或多个文件中的数据，并产生基于这些文件中的数据的应用（通常是报表）。

File organization（文件组织）：当文件存储在磁盘上时，对文件中的记录的安排方式。

First normal form（1NF，第一范式）：表中的每个列的交叉处以及记录包含切进包含一个值的表。

Foreign key（外健）：一个表中的一个列或者多个列的集合，这些列匹配某些其他（也可能是同一个）表中的候选键。

4GL, Fourth-Generation Language（第四代语言）：一种非过程化语言，比如SQL，他只需要用户定义必须完成什么 *** 作，4GL负责将所进行的 *** 作翻译成如何实现这些 *** 作。

Full functional dependency（完全函数依赖）：一个列在功能上依赖于复合主健，但不依赖于主健的任何一个子集的条件。

Functional dependency（函数依赖）：描述表中列之间的关系。

Generalization（泛化）：通过标识实体间的公共特征使实体间差别最小化的过程。

Generalization hierarchy（泛化层次结构）：同类型层次（type hierarchy）。

Global data model（全局数据模型）：代表整个公司（和被模型化的公司的一部分）的数据模型。

Implementation（实现）：数据库应用生命周期中的一个阶段，包括数据库和应用程序设计的物理实现。

Index（索引）：一种允许DBMS将特定的记录更快的放置到文件中，从而加快对用户查询的响应的数据结构。

Infomation system（信息系统）：能够在整个公司范围内收集、管理、控制和分发数据/信息的资源。

Inheritance（继承）：参见属性继承（attribute inheritance）。

Integrity constaints（完整性约束）：防止出现数据库中的数据不一致的约束。

IS-A hierarchy（IS－A层次结构）：同类型层次结构（type hierarchy）。

Local logical data model（局部逻辑数据模型）：代表特定用户视图或用户视图的组合的数据模型。

Logical database design（逻辑数据库设计）：基于特定的数据模型构建公司的数据的模型的过程，但不依赖于特定的DBMS以及其他的物理条件。

Meta-data（元数据）：关于数据的数据，参见系统目录（system catalog）。

Mision objective（使命目标）：标识数据库必须支持的特定任务。

Mission statement（使命语句）：定义数据库应用程序的主要目标。

Multiplicity（多样性）：定义与某个相关实体的一次出现有关的实体的出现数目。

Multi-valued attribute（多值属性）：为一个实体的出现保存多个值的属性。

Nonkey attribute/column（非键属性/列）：不是键的一部分的属性/列。

Normal forms（范式）：规范化过程的一个阶段。前三个范式分别为第一范式（1NF）、第二范式（2NF）、第三范式（3NF）。

Normalization（规范化）：一种产生带有需要的特性的技术，这种特性能支持用户和公司的需求。

Null（空值）：表示当前不知道或对于这条记录来说不可使用的一个列的值。

Operational maintenance（ *** 作维护）：数据库应用生命周期的一个阶段，包括监视和维护系统安装后的运行。

Participation constraint（参与约束，EER模型）：确定超类中的每个出现是否必须作为子类的一个成员进行参与。

Participation constraint（参与约束，ER模型）：确定是否所有或者仅仅是某些实体出现参与到关系中。

Physical database design（物理数据库设计）：在二级存储上产生数据库实现的描述的过程，它描述基本表、文件的组织、用于获得有效访问的索引以及所有与完整性约束和安全性限制有关的说明。

Primary index（主索引）：在文件的有序键字段上构建的索引。一个文件最多可以有一个主索引或一个群集索引。

Primary key（主健，ER模型）：用来标识每个实体的出现的候选键。

Primary key（主健，关系模型）：在一个表中用来标识记录性的候选键。

Privileges（权限）：允许用户在给定基本表和视图上执行的 *** 作。

Prototyping（原型）：数据库的应用程序生命周期的一个阶段，包括勾践数据库应用程序的工作模型。

Query-by-Example（QBE）：一种用于关系型DBMS的非过程化的数据库语言。QBE是一个图形化的“点－按”查询数据库的方法。

RDBMS：关系型DBMS。

Record（记录）：同元组（Tuple）。

Recovery control（恢复控制）：当时百事，将数据库还原到正确状态的过程。

Rcursive relationship（递归关系）：一种关系，挡同一个实体在不同的角色中参与多次时就会出现递归关系。例如Staff Supervises Staff。

redundant data（冗余数据）：在多个表中存储的重复数据。

Referential integrity（参照完整性）：如果一个表中存在外健，则外健值必须匹配主表中的某些记录的候选键的值。

Relation（关系）：一个关系是一张表，它也有列和行。

Relational model（关系模型）：以表（或关系）的形式表示数据的数据模型。

Relational database（关系数据库）：规范化表的集合。

Relation （关系）：实体间有意义的关系。

Relationship occurrence（关系出现）：两个实体出现之间的可标识的联系。

Requirements collection and analysis（需求收集于分析）：数据库应用程序生命周期的一个阶段，包括收集和分析数据库应用程序所要支持的关于公司的信息，并使用这些信息来标识新的数据库应用需求。

Row（行）：同元组（Tuple）。

Second normal form（第二范式）：一个已经是第一范式的表，同时满足所有的非主健列只能从构成主健的全部列中获得。

Secondary index（二级索引）：在数据文件的非有序字段上定义的索引。

Security（安全）：指防止数据库被非授权的用户访问，包括有意的和无意的。RDBMS通常提供两种类型的安全：数据安全和系统安全。

Server（服务器）：为发出请求的客户提供服务的软件应用程序。参见两层/三层客户端－服务器体系结构。

Simple attribute（简单属性）：只有一个组件的属性。

Single -valued attribute（单值属性）：对于一个实体出现只有一个值的属性。

Specialization（特化）：通过标识用来区分实体间成员的特征来花实体间成员的差别的过程。

Specialization hierarchy（特化层次结构）：同类型层次结构（Type hierarchy）。

SQL（Structured Query Language，结构化查询语言）：一种用于RDBMS的非过程化数据库语言。换言之，你只需要指定你需要那些信息，而不需要指定如何得到这些信息。SQL已经被国际标准化组织（ISO）标准化了，因此SQL是定义和 *** 纵RDBMS的正式和实际上的标准语言。

Strong entity（强实体）：一个不依赖于其他实体的主健的存在而存在的实体。

Subclass（子类）：为（超类）实体中的某些出现并保持特定属性和关系并有不同角色的实体

Superclass（超类）：为实体中的所有出现保存公共属性和关系的实体。可参见特化和泛化。

Superkey（超键，ER模型）：一个属性或属性集，诶译的标识了每个实体地出现。

Superkey（超键，关系模型）：一个列或者列集，的标识了表中地一个记录。

System catalog（系统目录）：保存关于数据库地结构、用户、应用程序等信息地数据。

System definition（系统定义）：数据库应用声明周期重的一个阶段，包括定义数据库应用程序以及他的主要用户视图地范围和边界。

System security（系统安全）：在系统级保护数据库地访问和使用，不如用户名和密码。

Table（表）：同关系（relation）。

Ternary relationship（三元关系）：三个实体间的关系。例如panch，staff和member之间的Registers关系。

Testing（测试）：数据库应用生命周期的一个阶段，包括执行应用程序并有意地发现错误。

Third normal form，3NF（第三范式）：一个已经是1NF和2NF的表，同时满足所有的非主健的列的值仅能从主健列得到，而不能从其他列得到。

3GL, Third-Generation Language（第三代语言）：一种过程化的语言，比如COBOL、C、C＋＋，它需要用户（通常是程序员）指定必须要干什么事情以及如何干这些事情。

Three-tier client-server architecture（三层客户端－服务器体系结构）：由处理用户界面的客户和处理业务逻辑的应用程序服务器以及数据处理曾组成，而数据库服务器是用来来运行DBMS的。

Top-down approach（自顶向下方法，用于数据库设计）：一种设计方法，此种方法从定义系统的主要结构开始，然后将这些结构逐步细分成更小的单元。在数据库设计中，通过标识实体和数据间的关系开始这个顶层的步骤，然后逐步添加细节，比如你希望保存的关于实体和关系的信息（成为属性）以及在实体、关系和属性上的所有约束。

Transaction（事务）：由用户和应用程序执行的一个动作或一系列动作，这些动作访问或修改数据库的内容。

Transaction Processing Monitor，TPM（事务处理监视器）：控制数据在客户端和服务器键转换的程序，以便为联机事务处理（OLTP）提供一个一致的环境。

Transitive dependency（传递依赖）：假设A、B、C是表中的列，如果B依赖于A（A-->B），并且C依赖于B（B- ->C），则C通过B传递而依赖于A（假设A不依赖于B或C）。如果在主健上存在一个传递依赖，则此表就不是3NF的。必须从表中去掉传递依赖以达到3NF的要求。

Tuple（元组）：关系中的一行记录。

Two-tier client-server architecture（两层客户端－服务器体系结构）：由处理主要业务和数据处理逻辑以及与用户的接口的客户端应用程序和管理和控制数据库访问的服务器程序组成。

Type hierarchy（类型层次结构）：一个是提以及它的子类和他们的超类，等等。

UML（Unified Modeling Language，统一建模语言）：在20世纪80年代和90年代引入的诸多面向对象分析与设计方法重的一种较新的方法。

Update anomalies（更新异常）：当用户视图更新一个包含冗余数据的标识可能引起的不一致。有三种类型的异常：插入、删除和更新。

User view（用户视图）：从特定的作业（比如经理或管理者）角度或业务应用领域（比如市场、职员或库存控制）定义的数据库应用的需求。

View（视图）：一个“虚拟底表”，它不实际存在数据库中，但他由 DBMS从现有底它所涉及的基本表中产生。

View integration approach（视图综合法，用于数据库设计）：每个用户视图的需求，用来构建代表用户试图底独立数据模型。在数据库设计阶段，结果数据库模型被合并成一个更大的模型。

是第三范式，就是里面不能有插入删除的冗余，要求是转换为关系，就是给出这样的格式：客户（客户编号，客户名。。。），但是转后厚的关系还要满足刚刚说的第三范式，每个实体的属性要你自己确定 ，你可以自己给，

比如客户的属性有编号，姓名，身份z号，

商品的有编号，商品名，类别，售价，优惠价，生产日期，保质期。

货架的属性有（编号，层数等）

进货商有编号，名称，连联系电话，地址等。

一、数据库设计过程

数据库技术是信息资源管理最有效的手段。

数据库设计是指：对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，有效存储数据，满足用户信息要求和处理要求。

数据库设计的各阶段：

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方法，它就是把实体-联系方法应用到语义数据模型中的一种语义模型化技术，用于建立系统信息模型。

作者: 小灵, 出处:论坛, 责任编辑: 李书琴, 2007-09-27 15:17

本文详细解析了数据库设计过程、设计技巧以及总结了数据库命名规范……

21 第零步——初始化工程

这个阶段的任务是从目的描述和范围描述开始，确定建模目标，开发建模计划，组织建模队伍，收集源材料，制定约束和规范。收集源材料是这阶段的重点。通过调查和观察结果，业务流程，原有系统的输入输出，各种报表，收集原始数据，形成了基本数据资料表。

22 第一步——定义实体

实体集成员都有一个共同的特征和属性集，可以从收集的源材料——基本数据资料表中直接或间接标识出大部分实体。根据源材料名字表中表示物的术语以及具有 “代码”结尾的术语，如客户代码、代理商代码、产品代码等将其名词部分代表的实体标识出来，从而初步找出潜在的实体，形成初步实体表。

23 第二步——定义联系

IDEF1X模型中只允许二元联系，n元联系必须定义为n个二元联系。根据实际的业务需求和规则，使用实体联系矩阵来标识实体间的二元关系，然后根据实际情况确定出连接关系的势、关系名和说明，确定关系类型，是标识关系、非标识关系(强制的或可选的)还是非确定关系、分类关系。如果子实体的每个实例都需要通过和父实体的关系来标识，则为标识关系，否则为非标识关系。非标识关系中，如果每个子实体的实例都与而且只与一个父实体关联，则为强制的，否则为非强制的。如果父实体与子实体代表的是同一现实对象，那么它们为分类关系。

24 第三步——定义码

通过引入交叉实体除去上一阶段产生的非确定关系，然后从非交叉实体和独立实体开始标识侯选码属性，以便唯一识别每个实体的实例，再从侯选码中确定主码。为了确定主码和关系的有效性，通过非空规则和非多值规则来保证，即一个实体实例的一个属性不能是空值，也不能在同一个时刻有一个以上的值。找出误认的确定关系，将实体进一步分解，最后构造出IDEF1X模型的键基视图(KB图)。

25 第四步——定义属性

从源数据表中抽取说明性的名词开发出属性表，确定属性的所有者。定义非主码属性，检查属性的非空及非多值规则。此外，还要检查完全依赖函数规则和非传递依赖规则，保证一个非主码属性必须依赖于主码、整个主码、仅仅是主码。以此得到了至少符合关系理论第三范式的改进的IDEF1X模型的全属性视图。

26 第五步——定义其他对象和规则

定义属性的数据类型、长度、精度、非空、缺省值、约束规则等。定义触发器、存储过程、视图、角色、同义词、序列等对象信息。

3 逻辑结构设计阶段

将概念结构转换为某个DBMS所支持的数据模型(例如关系模型)，并对其进行优化。设计逻辑结构应该选择最适于描述与表达相应概念结构的数据模型，然后选择最合适的DBMS。

将E-R图转换为关系模型实际上就是要将实体、实体的属性和实体之间的联系转化为关系模式,这种转换一般遵循如下原则：一个实体型转换为一个关系模式。实体的属性就是关系的属性。实体的码就是关系的码。

数据模型的优化，确定数据依赖，消除冗余的联系，确定各关系模式分别属于第几范式。确定是否要对它们进行合并或分解。一般来说将关系分解为3NF的标准，即：

表内的每一个值都只能被表达一次。

表内的每一行都应该被唯一的标识(有唯一键)。

表内不应该存储依赖于其他键的非键信息。

作者: 小灵, 出处:论坛, 责任编辑: 李书琴, 2007-09-27 15:17

本文详细解析了数据库设计过程、设计技巧以及总结了数据库命名规范……

4 数据库物理设计阶段

为逻辑数据模型选取一个最适合应用环境的物理结构(包括存储结构和存取方法)。根据DBMS特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式。

5 数据库实施阶段

运用DBMS提供的数据语言(例如SQL)及其宿主语言(例如C)，根据逻辑设计和物理设计的结果建立数据库，编制与调试应用程序，组织数据入库，并进行试运行。 数据库实施主要包括以下工作：用DDL定义数据库结构、组织数据入库 、编制与调试应用程序、数据库试运行 ，(Data Definition Language(DDL数据定义语言)用作开新数据表、设定字段、删除数据表、删除字段，管理所有有关数据库结构的东西)

●Create (新增有关数据库结构的东西，属DDL)

●Drop (删除有关数据库结构的东西，属DDL)

●Alter (更改结构，属DDL)

6 数据库运行和维护阶段

在数据库系统运行过程中必须不断地对其进行评价、调整与修改。内容包括：数据库的转储和恢复、数据库的安全性、完整性控制、数据库性能的监督、分析和改进、数据库的重组织和重构造。

7 建模工具的使用

为加快数据库设计速度，目前有很多数据库辅助工具(CASE工具)，如Rational公司的Rational Rose，CA公司的Erwin和Bpwin，Sybase公司的PowerDesigner以及Oracle公司的oracle Designer等。

ERwin主要用来建立数据库的概念模型和物理模型。它能用图形化的方式，描述出实体、联系及实体的属性。ERwin支持IDEF1X方法。通过使用 ERwin建模工具自动生成、更改和分析IDEF1X模型，不仅能得到优秀的业务功能和数据需求模型，而且可以实现从IDEF1X模型到数据库物理设计的转变。ERwin工具绘制的模型对应于逻辑模型和物理模型两种。在逻辑模型中，IDEF1X工具箱可以方便地用图形化的方式构建和绘制实体联系及实体的属性。在物理模型中，ERwin可以定义对应的表、列，并可针对各种数据库管理系统自动转换为适当的类型。

设计人员可根据需要选用相应的数据库设计建模工具。例如需求分析完成之后，设计人员可以使用Erwin画ER图，将ER图转换为关系数据模型，生成数据库结构;画数据流图，生成应用程序。

二、数据库设计技巧

1 设计数据库之前(需求分析阶段)

1) 理解客户需求，包括用户未来需求变化。

2) 了解企业业务类型，可以在开发阶段节约大量的时间。

3) 重视输入(要记录的数据)、输出(报表、查询、视图)。

4) 创建数据字典和ER 图表

数据字典(Data Dictionary，简称DD)是各类数据描述的集合，是关于数据库中数据的描述，即元数据，不是数据本身。(至少应该包含每个字段的数据类型和在每个表内的主外键)。

数据项描述: 数据项名，数据项含义说明，别名，数据类型，长度，取值范围，取值含义，与其他数据项的逻辑关系

数据结构描述: 数据结构名，含义说明，组成:[数据项或数据结构]

数据流描述: 数据流名，说明，数据流来源，数据流去向， 组成:[数据结构]，平均流量，高峰期流量

数据存储描述: 数据存储名，说明，编号，流入的数据流，流出的数据流，组成:[数据结构]，数据量，存取方式

处理过程描述: 处理过程名，说明，输入:[数据流]，输出:[数据流]，处理:[简要说明]

ER 图表和数据字典可以让任何了解数据库的人都明确如何从数据库中获得数据。ER图对表明表之间关系很有用，而数据字典则说明了每个字段的用途以及任何可能存在的别名。对SQL 表达式的文档化来说这是完全必要的。

5) 定义标准的对象命名规范

数据库各种对象的命名必须规范。

作者: 小灵, 出处:论坛, 责任编辑: 李书琴, 2007-09-27 15:17

本文详细解析了数据库设计过程、设计技巧以及总结了数据库命名规范……

2 表和字段的设计(数据库逻辑设计)

表设计原则

1) 标准化和规范化

数据的标准化有助于消除数据库中的数据冗余。标准化有好几种形式，但Third Normal Form(3NF)通常被认为在性能、扩展性和数据完整性方面达到了最好平衡。简单来说，遵守3NF 标准的数据库的表设计原则是：“One Fact in One Place”即某个表只包括其本身基本的属性，当不是它们本身所具有的属性时需进行分解。表之间的关系通过外键相连接。它具有以下特点：有一组表专门存放通过键连接起来的关联数据。

2) 数据驱动

采用数据驱动而非硬编码的方式，许多策略变更和维护都会方便得多，大大增强系统的灵活性和扩展性。

举例，假如用户界面要访问外部数据源(文件、XML 文档、其他数据库等)，不妨把相应的连接和路径信息存储在用户界面支持的表里。如果用户界面执行工作流之类的任务(发送邮件、打印信笺、修改记录状态等)，那么产生工作流的数据也可以存放在数据库里。角色权限管理也可以通过数据驱动来完成。事实上，如果过程是数据驱动的，你就可以把相当大的责任推给用户，由用户来维护自己的工作流过程。

3) 考虑各种变化

在设计数据库的时候考虑到哪些数据字段将来可能会发生变更。

4) 表名、报表名和查询名的命名规范

(采用前缀命名)检查表名、报表名和查询名之间的命名规范。你可能会很快就被这些不同的数据库要素的名称搞糊涂了。你可以统一地命名这些数据库的不同组成部分，至少你应该在这些对象名字的开头用 Table、Query 或者 Report 等前缀加以区别。如果采用了 Microsoft Access，你可以用 qry、rpt、tbl 和 mod 等符号来标识对象(比如 tbl_Employees)。用 sp_company 标识存储过程，用 udf_ (或者类似的标记)标识自定义编写的函数。

字段设计原则：

1) 每个表中都应该添加的3 个有用的字段。

dRecordCreationDate，在SQL Server 下默认为GETDATE()

sRecordCreator，在SQL Server 下默认为NOT NULL DEFAULT USER

nRecordVersion，记录的版本标记;有助于准确说明记录中出现null 数据或者丢失数据的原因

时效性数据应包括“最近更新日期/时间”字段。时间标记对查找数据问题的原因、按日期重新处理/重载数据和清除旧数据特别有用。

2) 对地址和电话采用多个字段

描述街道地址就短短一行记录是不够的。Address_Line1、Address_Line2 和Address_Line3 可以提供更大的灵活性。还有，电话号码和邮件地址最好拥有自己的数据表，其间具有自身的类型和标记类别。

3) 表内的列[字段]的命名规则(采用前缀/后缀命名)、采用有意义的字段名

对列[字段]名应该采用标准的前缀和后缀。如键是数字类型：用 _N 后缀;字符类型：_C 后缀;日期类型：_D 后缀。再如，假如你的表里有好多“money”字段，你不妨给每个列[字段]增加一个 _M 后缀。

作者: 小灵, 出处:论坛, 责任编辑: 李书琴, 2007-09-27 15:17

本文详细解析了数据库设计过程、设计技巧以及总结了数据库命名规范……

假设有两个表：

Customer 和 Order。Customer 表的前缀是 cu_，所以该表内的子段名如下：cu_name_id、cu_surname、cu_initials 和cu_address 等。Order 表的前缀是 or_，所以子段名是：

or_order_id、or_cust_name_id、or_quantity 和 or_description 等。

这样从数据库中选出全部数据的 SQL 语句可以写成如下所示：

Select From Customer, Order Where cu_surname = "MYNAME" ;

and cu_name_id = or_cust_name_id and or_quantity = 1

在没有这些前缀的情况下则写成这个样子(用别名来区分)：

Select From Customer, Order Where Customersurname = "MYNAME" ;

and Customername_id = Ordercust_name_id and Orderquantity = 1

第 1 个 SQL 语句没少键入多少字符。但如果查询涉及到 5 个表乃至更多的列[字段]你就知道这个技巧多有用了。

5) 选择数字类型和文本类型的长度应尽量充足

假设客户ID 为10 位数长。那你应该把数据库表字段的长度设为12 或者13 个字符长。但这额外占据的空间却无需将来重构整个数据库就可以实现数据库规模的增长了。

6) 增加删除标记字段

在表中包含一个“删除标记”字段，这样就可以把行标记为删除。在关系数据库里不要单独删除某一行;最好采用清除数据程序而且要仔细维护索引整体性。

7) 提防大小写混用的对象名和特殊字符

采用全部大写而且包含下划符的名字具有更好的可读性(CUSTOMER_DATA)，绝对不要在对象名的字符之间留空格。

8) 小心保留词

要保证你的字段名没有和保留词、数据库系统或者常用访问方法冲突，比如，用 DESC 作为说明字段名。后果可想而知!DESC 是 DESCENDING 缩写后的保留词。表里的一个 SELECT 语句倒是能用，但得到的却是一大堆毫无用处的信息。

9) 保持字段名和类型的一致性

在命名字段并为其指定数据类型的时候一定要保证一致性。假如字段在表1中叫做“agreement_number”，就别在表2里把名字改成 “ref1”。假如数据类型在表1里是整数，那在表2里可就别变成字符型了。当然在表1(ABC)有处键ID，则为了可读性，在表2做关联时可以命名为 ABC_ID。

10) 避免使用触发器

触发器的功能通常可以用其他方式实现。在调试程序时触发器可能成为干扰。假如你确实需要采用触发器，你最好集中对它文档化。

作者: 小灵, 出处:论坛, 责任编辑: 李书琴, 2007-09-27 15:17

本文详细解析了数据库设计过程、设计技巧以及总结了数据库命名规范……

3 选择键和索引(数据库逻辑设计)

参考：《SQL优化-索引》一文

4 数据完整性设计(数据库逻辑设计)

1) 完整性实现机制：

实体完整性：主键

参照完整性：

父表中删除数据：级联删除;受限删除;置空值

父表中插入数据：受限插入;递归插入

父表中更新数据：级联更新;受限更新;置空值

DBMS对参照完整性可以有两种方法实现：外键实现机制(约束规则)和触发器实现机制用户定义完整性：

NOT NULL;CHECK;触发器

2) 用约束而非商务规则强制数据完整性

采用数据库系统实现数据的完整性。这不但包括通过标准化实现的完整性而且还包括数据的功能性。不要依赖于商务层保证数据完整性;它不能保证表之间(外键) 的完整性所以不能强加于其他完整性规则之上。如果你在数据层确实采用了约束，你要保证有办法把更新不能通过约束检查的原因采用用户理解的语言通知用户界面。

3) 强制指示完整性

在有害数据进入数据库之前将其剔除。激活数据库系统的指示完整性特性。这样可以保持数据的清洁而能迫使开发人员投入更多的时间处理错误条件。

4) 使用查找控制数据完整性

控制数据完整性的最佳方式就是限制用户的选择。只要有可能都应该提供给用户一个清晰的价值列表供其选择。这样将减少键入代码的错误和误解同时提供数据的一致性。某些公共数据特别适合查找：国家代码、状态代码等。

5) 采用视图

为了在数据库和应用程序代码之间提供另一层抽象，可以为应用程序建立专门的视图而不必非要应用程序直接访问数据表。这样做还等于在处理数据库变更时给你提供了更多的自由。

6) 分布式数据系统

对分布式系统而言，在你决定是否在各个站点复制所有数据还是把数据保存在一个地方之前应该估计一下未来 5 年或者 10 年的数据量。当你把数据传送到其他站点的时候，最好在数据库字段中设置一些标记，在目的站点收到你的数据之后更新你的标记。为了进行这种数据传输，请写下你自己的批处理或者调度程序以特定时间间隔运行而不要让用户在每天的工作后传输数据。本地拷贝你的维护数据，比如计算常数和利息率等，设置版本号保证数据在每个站点都完全一致。

7) 关系

如果两个实体之间存在多对一关系，而且还有可能转化为多对多关系，那么你最好一开始就设置成多对多关系。从现有的多对一关系转变为多对多关系比一开始就是多对多关系要难得多。

8) 给数据保有和恢复制定计划

考虑数据保存策略并包含在设计过程中，预先设计你的数据恢复过程。采用可以发布给用户/开发人员的数据字典实现方便的数据识别同时保证对数据源文档化。编写在线更新来“更新查询”供以后万一数据丢失可以重新处理更新。

9) 用存储过程让系统做重活

提供一整套常规的存储过程来访问各组以便加快速度和简化客户程序代码的开发。数据库不只是一个存放数据的地方，它也是简化编码之地。

本文详细解析了数据库设计过程、设计技巧以及总结了数据库命名规范……

5 其他设计技巧

1) 避免使用触发器

触发器的功能通常可以用其他方式实现。在调试程序时触发器可能成为干扰。假如你确实需要采用触发器，你最好集中对它文档化。

2) 使用常用英语(或者其他任何语言)而不要使用编码

在创建下拉菜单、列表、报表时最好按照英语名排序。假如需要编码，可以在编码旁附上用户知道的英语。

3) 保存常用信息

让一个表专门存放一般数据库信息非常有用。在这个表里存放数据库当前版本、最近检查/修复(对Access)、关联设计文档的名称、客户等信息。这样可以实现一种简单机制跟踪数据库，当客户抱怨他们的数据库没有达到希望的要求而与你联系时，这样做对非客户机/服务器环境特别有用。

4) 包含版本机制

在数据库中引入版本控制机制来确定使用中的数据库的版本。时间一长，用户的需求总是会改变的。最终可能会要求修改数据库结构。把版本信息直接存放到数据库中更为方便。

5) 编制文档

对所有的快捷方式、命名规范、限制和函数都要编制文档。

采用给表、列、触发器等加注释的 数据库工具。对开发、支持和跟踪修改非常有用。

对数据库文档化，或者在数据库自身的内部或者单独建立文档。这样，当过了一年多时间后再回过头来做第2 个版本，犯错的机会将大大减少。

6) 测试、测试、反复测试

建立或者修订数据库之后，必须用用户新输入的数据测试数据字段。最重要的是，让用户进行测试并且同用户一道保证选择的数据类型满足商业要求。测试需要在把新数据库投入实际服务之前完成。

7) 检查设计

在开发期间检查数据库设计的常用技术是通过其所支持的应用程序原型检查数据库。换句话说，针对每一种最终表达数据的原型应用，保证你检查了数据模型并且查看如何取出数据。

三、数据库命名规范

1 实体(表)的命名

1) 表以名词或名词短语命名，确定表名是采用复数还是单数形式，此外给表的别名定义简单规则(比方说，如果表名是一个单词，别名就取单词的前4 个字母;如果表名是两个单词，就各取两个单词的前两个字母组成4 个字母长的别名;如果表的名字由3 个单词组成，从头两个单词中各取一个然后从最后一个单词中再取出两个字母，结果还是组成4 字母长的别名，其余依次类推)

对工作用表来说，表名可以加上前缀WORK_ 后面附上采用该表的应用程序的名字。在命名过程当中，根据语义拼凑缩写即可。注意：将字段名称会统一成大写或者小写中的一种，故中间加上下划线。

作者: 小灵, 出处:论坛, 责任编辑: 李书琴, 2007-09-27 15:17

本文详细解析了数据库设计过程、设计技巧以及总结了数据库命名规范……

举例：

定义的缩写 Sales: Sal 销售;

Order: Ord 订单;

Detail: Dtl 明细;

则销售订单明细表命名为：Sal_Ord_Dtl;

2) 如果表或者是字段的名称仅有一个单词，那么建议不使用缩写，而是用完整的单词。

举例：

定义的缩写 Material Ma 物品;

物品表名为：Material, 而不是 Ma

但是字段物品编码则是：Ma_ID;而不是Material_ID

3) 所有的存储值列表的表前面加上前缀Z

目的是将这些值列表类排序在数据库最后。

4) 所有的冗余类的命名(主要是累计表)前面加上前缀X

冗余类是为了提高数据库效率，非规范化数据库的时候加入的字段或者表

5) 关联类通过用下划线连接两个基本类之后，再加前缀R的方式命名,后面按照字母顺序罗列两个表名或者表名的缩写。

关联表用于保存多对多关系。

如果被关联的表名大于10个字母，必须将原来的表名的进行缩写。如果没有其他原因，建议都使用缩写。

举例：表Object与自身存在多对多的关系,则保存多对多关系的表命名为：R_Object;

作者: 小灵, 出处:论坛, 责任编辑: 李书琴, 2007-09-27 15:17

本文详细解析了数据库设计过程、设计技巧以及总结了数据库命名规范……

2 属性(列)的命名

1) 采用有意义的列名

表内的列要针对键采用一整套设计规则。每一个表都将有一个自动ID作为主健,逻辑上的主健作为第一组候选主健来定义;

A、如果是数据库自动生成的编码，统一命名为：ID

B、如果是自定义的逻辑上的编码则用缩写加“ID”的方法命名，即“XXXX_ID”

C、如果键是数字类型，你可以用_NO 作为后缀;

D、如果是字符类型则可以采用_CODE 后缀

E、对列名应该采用标准的前缀和后缀。

举例：销售订单的编号字段命名：Sal_Ord_ID;如果还存在一个数据库生成的自动编号，则命名为：ID。

2) 所有的属性加上有关类型的后缀

注意，如果还需要其它的后缀，都放在类型后缀之前。

注: 数据类型是文本的字段，类型后缀TX可以不写。有些类型比较明显的字段，可以不写类型后缀。

3) 采用前缀命名

给每个表的列名都采用统一的前缀，那么在编写SQL表达式的时候会得到大大的简化。这样做也确实有缺点，比如破坏了自动表连接工具的作用，后者把公共列名同某些数据库联系起来。

3 视图的命名

1) 视图以V作为前缀，其他命名规则和表的命名类似;

2) 命名应尽量体现各视图的功能。

4 触发器的命名(尽量不使用)

触发器以TR作为前缀，触发器名为相应的表名加上后缀，Insert触发器加'_I'，Delete触发器加'_D'，Update触发器加'_U'，如：TR_Customer_I，TR_Customer_D，TR_Customer_U。

5 存储过程名

存储过程应以'UP_'开头，和系统的存储过程区分，后续部分主要以动宾形式构成，并用下划线分割各个组成部分。如增加代理商的帐户的存储过程为'UP_Ins_Agent_Account'。

6 变量名

变量名采用小写，若属于词组形式，用下划线分隔每个单词，如@my_err_no。

7 命名中其他注意事项

1) 以上命名都不得超过30个字符的系统限制。变量名的长度限制为29(不包括标识字符@)。

2) 数据对象、变量的命名都采用英文字符，禁止使用中文命名。绝对不要在对象名的字符之间留空格。

3) 小心保留词，要保证你的字段名没有和保留词、数据库系统或者常用访问方法冲突

4) 保持字段名和类型的一致性，在命名字段并为其指定数据类型的时候一定要保证一致性。假如数据类型在一个表里是整数，那在另一个表里可就别变成字符型了。

什么是好的数据库设计？

一些原则可为数据库设计过程提供指导。第一个原则是，重复信息（也称为冗余数据）很糟糕，因为重复信息会浪费空间，并会增加出错和不一致的可能性。第二个原则是，信息的正确性和完整性非常重要。如果数据库中包含不正确的信息，任何从数据库中提取信息的报表也将包含不正确的信息。因此，基于这些报表所做的任何决策都将提供错误信息。

所以，良好的数据库设计应该是这样的：

将信息划分到基于主题的表中，以减少冗余数据。

向Aess提供根据需要联接表中信息时所需的信息。

可帮助支持和确保信息的准确性和完整性。

可满足数据处理和报表需求。

设计过程

设计过程包括以下步骤：

确定数据库的用途：这可帮助进行其他步骤的准备工作。

查找和组织所需的信息：收集可能希望在数据库中记录的各种信息，如产品名称和订单号。

划分到表中的信息：将信息项划分到主要的实体或主题中，如“产品”或“订单”。每个主题即构成一个表。

关闭信息项目导入的列确定希望在每个表中存储哪些信息。每个项将成为一个字段，并作为列显示在表中。例如，“雇员”表中可能包含“姓氏”和“聘用日期”等字段。

指定为主键：选择每个表的主键。主键是一个用于唯一标识每个行的列。例如，主键可以为“产品ID”或“订单ID”。

设置表关系：查看每个表，并确定各个表中的数据如何彼此关联。根据需要，将字段添加到表中或创建新表，以便清楚地表达这些关系。

优化您的设计：分析设计中是否存在错误。创建表并添加几条示例数据记录。确定是否可以从表中获得期望的结果。根据需要对设计进行调整。

应用规范化规则：应用数据规范化规则，以确定表的结构是否正确。根据需要对表进行调整。

以上就是关于数据库设计时有几大范式全部的内容，包括:数据库设计时有几大范式、如何进行数据库的设计、数据库逻辑模型等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！