大型数据库的设计原则与开发技巧

随着计算机技术越来越广泛地应用于国民经济的各个领域 在计算机硬件不断微型化的同时 应用系统向着复杂化 大型化的方向发展 数据库是整个系统的核心 它的设计直接关系系统执行的效率和系统的稳定性 因此在软件系统开发中 数据库设计应遵循必要的数据库范式理论 以减少冗余 保证数据的完整性与正确性 只有在合适的数据库产品上设计出合理的数据库模型 才能降低整个系统的编程和维护难度 提高系统的实际运行效率 虽然对于小项目或中等规模的项目开发人员可以很容易地利用范式理论设计出一套符合要求的数据库 但对于一个包含大型数据库的软件项目 就必须有一套完整的设计原则与技巧

一 成立数据小组

大型数据库数据元素多 在设计上有必要成立专门的数据小组 由于数据库设计者不一定是使用者 对系统设计中的数据元素不可能考虑周全 数据库设计出来后 往往难以找到所需的库表 因此数据小组最好由熟悉业务的项目骨干组成

数据小组的职能并非是设计数据库 而是通过需求分析 在参考其他相似系统的基础上 提取系统的基本数据元素 担负对数据库的审核 审核内容包括审核新的数据库元素是否完全 能否实现全部业务需求 对旧数据库（如果存在旧系统）的分析及数据转换 数据库设计的审核 控制及必要调整

二 设计原则

规范命名 所有的库名 表名 域名必须遵循统一的命名规则 并进行必要说明 以方便设计 维护 查询

控制字段的引用 在设计时 可以选择适当的数据库设计管理工具 以方便开发人员的分布式设计和数据小组的集中审核管理 采用统一的命名规则 如果设计的字段已经存在 可直接引用 否则 应重新设计

库表重复控制 在设计过程中 如果发现大部分字段都已存在 开发人员应怀疑所设计的库表是否已存在 通过对字段所在库表及相应设计人员的查询 可以确认库表是否确实重复

并发控制 设计中应进行并发控制 即对于同一个库表 在同一时间只有一个人有控制权 其他人只能进行查询

必要的讨论 数据库设计完成后 数据小组应与相关人员进行讨论 通过讨论来熟悉数据库 从而对设计中存在的问题进行控制或从中获取数据库设计的必要信息

数据小组的审核 库表的定版 修改最终都要通过数据小组的审核 以保证符合必要的要求

头文件处理 每次数据修改后 数据小组要对相应的头文件进行修改（可由管理软件自动完成） 并通知相关的开发人员 以便进行相应的程序修改

三 设计技巧

分类拆分数据量大的表 对于经常使用的表（如某些参数表或代码对照表） 由于其使用频率很高 要尽量减少表中的记录数量 例如 银行的户主账表原来设计成一张表 虽然可以方便程序的设计与维护 但经过分析发现 由于数据量太大 会影响数据的迅速定位 如果将户主账表分别设计为活期户主账 定期户主账及对公户主账等 则可以大大提高查询效率

索引设计 对于大的数据库表 合理的索引能够提高整个数据库的 *** 作效率 在索引设计中 索引字段应挑选重复值较少的字段 在对建有复合索引的字段进行检索时 应注意按照复合索引字段建立的顺序进行 例如 如果对一个 万多条记录的流水表以日期和流水号为序建立复合索引 由于在该表中日期的重复值接近整个表的记录数 用流水号进行查询所用的时间接近 秒 而如果以流水号为索引字段建立索引进行相同的查询 所用时间不到 秒 因此在大型数据库设计中 只有进行合理的索引字段选择 才能有效提高整个数据库的 *** 作效率

数据 *** 作的优化 在大型数据库中 如何提高数据 *** 作效率值得关注 例如 每在数据库流水表中增加一笔业务 就必须从流水控制表中取出流水号 并将其流水号的数值加一 正常情况下 单笔 *** 作的反应速度尚属正常 但当用它进行批量业务处理时 速度会明显减慢 经过分析发现 每次对流水控制表中的流水号数值加一时都要锁定该表 而该表却是整个系统 *** 作的核心 有可能在 *** 作时被其他进程锁定 因而使整个事务 *** 作速度变慢 对这一问题的解决的办法是 根据批量业务的总笔数批量申请流水号 并对流水控制表进行一次更新 即可提高批量业务处理的速度 另一个例子是对插表的优化 对于大批量的业务处理 如果在插入数据库表时用普通的Insert语句 速度会很慢 其原因在于 每次插表都要进行一次I/O *** 作 花费较长的时间 改进后 可以用Put语句等缓冲区形式等满页后再进行I/O *** 作 从而提高效率 对大的数据库表进行删除时 一般会直接用Delete语句 这个语句虽然可以进行小表 *** 作 但对大表却会因带来大事务而导致删除速度很慢甚至失败 解决的方法是去掉事务 但更有效的办法是先进行Drop *** 作再进行重建

数据库参数的调整 数据库参数的调整是一个经验不断积累的过程 应由有经验的系统管理员完成 以Informix数据库为例 记录锁的数目太少会造成锁表的失败 逻辑日志的文件数目太少会造成插入大表失败等 这些问题都应根据实际情况进行必要的调整

必要的工具 在整个数据库的开发与设计过程中 可以先开发一些小的应用工具 如自动生成库表的头文件 插入数据的初始化 数据插入的函数封装 错误跟踪或自动显示等 以此提高数据库的设计与开发效率

避免长事务 对单个大表的删除或插入 *** 作会带来大事务 解决的办法是对参数进行调整 也可以在插入时对文件进行分割 对于一个由一系列小事务顺序 *** 作共同构成的长事务（如银行交易系统的日终交易） 可以由一系列 *** 作完成整个事务 但其缺点是有可能因整个事务太大而使不能完成 或者 由于偶然的意外而使事务重做所需的时间太长 较好的解决方法是 把整个事务分解成几个较小的事务 再由应用程序控制整个系统的流程 这样 如果其中某个事务不成功 则只需重做该事务 因而既可节约时间 又可避免长事务

适当超前 计算机技术发展日新月异 数据库的设计必须具有一定前瞻性 不但要满足当前的应用要求 还要考虑未来的业务发展 同时必须有利于扩展或增加应用系统的处理功能

lishixinzhi/Article/program/SQL/201311/16498

第四章 关系数据库的模式设计

45 什么是关系数据库：

关系数据库是以关系模型为基础的数据库，它利用关系来描述现实世界。一个关系既可以用来描述一个实体及其属性，也可以用来描述实体间的联系。关系实质上是一张二维表。

46 一个关系模型有哪两个方面内容：

一个关系模型包括外延和内涵两个方面的内容。

外延就是通常所说的关系，或实例，或当前值。它与时间有关，随着时间的推移在不断变化。（由于元组的插入、删除、修改引起的）

内涵是与时间独立的，包括关系、属性、及域的一些定义和说明，还有各种数据完整性约束。

47 数据完整性约束分为哪两类：

数据完整性约束分为静态约束和动态约束。

静态约束：包括各种数据之间的联系（数据依赖），主键的设计和关系值的各种限制等等。这一类约束是如何定义关系的有效数据问题。

动态约束：主要定义如插入、删除、和修改等各种 *** 作的影响。

48 关系数据库设计理论主要包括哪些内容：

关系数据库设计理论主要包括三个方面的内容：数据依赖、范式、模式设计方法。其中数据依赖起着核心的作用。

49 数据库使用过程中存在的问题是什么：

数据冗余、更新异常、插入异常、删除异常。

50 函数依赖（FD）的定义：

设有关系模式R（A1，A2，……，An）（即R（U）），X，Y是U的子集，r是R的任一具体关系，如果对r的任意两个元组t1，t2，由t1[X]=t2[X]导致t1[Y]=t2[Y]，则称X函数决定Y，或Y函数依赖于X，记为X→Y，X→Y为模式R的一个函数依赖。

或者说，对于X的每一个具体值，都有Y惟一的具体值与之对应，即Y值由X值决定，因而

这种数据依赖称为函数依赖。

51 函数依赖的逻辑蕴涵、FD的闭包F+：

设F是关系模式R的一个函数依赖集，X，Y是R的属性子集，如果从F中的函数依赖能够推出X—>Y，则称F逻辑蕴涵X—>Y，记为F X→Y。

被F逻辑蕴涵的函数依赖的全体构成的集合，称为F的闭包，记为F+。F+={X→Y|F X→Y}

52 候选键、主属性、非主属性：

设有关系模式R（A1，A2，……，An），F是R的一个函数依赖集，X是{A1，A2，……，An}的一个子集。如果

① X→A1A2……An∈F+，且

② 不存在X真子集Y，使得Y→A1A2……An成立，则称X是R的候选键。

包含在任何一个候选键中的属性称为主属性，不包含在任何一个候选键中的属性称为非主属性。

53 函数依赖的推理规则：

设有关系模式R（A1，A2，……，An）和属性集U= A1，A2，……，An，X，Y，Z，W是U的一个子集，F是R的一个函数依赖集，推理规则如下：

（1） 自反律：如果Y X U，则X→Y在R上成立。

（2） 增广律：如果X→Y为F所蕴涵，Z U，则XZ→YZ在R上成立。

（3） 传递律：如果X→Y和Y→Z在R上成立，则X→Z在R上成立。

FD的其他三个推理规则：

（4） 合并律：如果X→Y成立，那么X→YZ成立。

（5） 伪传递律：如果X→Y和WY→Z成立，那么WX→Z成立。

（6） 分解律：如果X→Y和Z Y成立，那么X→Z成立。

54 什么是平凡的FD？平凡的FD可根据哪一条推理规则推出？

如果X→Y，并且Y X，则称X→Y是平凡的FD。根据推理规则的自反律可推出。

55 关系模式的分解有几个不同的衡量标准：

分解具有无损联接;

分解要保持函数依赖;

分解既要保持依赖，又要具有无损联接。

56 什么是无损连接：

设有关系模式R，分解成关系模式ρ＝｛R1，R2，……Rk｝，F是R的一个函数依赖集。如果对R中满足F的每一个关系r都有：r=πR1（r）|×|πR2（r）|×|……πRK（r），则称这个分解ρ是无损联结分解。

57 试叙保持函数依赖的定义：

设F是属性集U上的一个函数依赖集，Z是U上的一个子集，F在Z上的一个投影定义为：πZ（F）={X→Y|X→Y∈F+且XY Z}

设关系模式R的一个分解为ρ＝｛R1，R2，……Rk｝，F是R的一个函数依赖集，如果

则称为分解ρ保持函数依赖。

58 第一范式（1NF）：

如果关系模式R的所有属性的值域中每一个值都是不可再分解的值，则称R是属于第一范式模式。

59 第二范式（2NF）：

如果关系模式R为第一范式，并且R中每一个非主属性完全函数依赖于R的候选键，则称R是第二范式模式。

60 第三范式（3NF）：

如果关系模式R是第一范式，且每个非主属性都不传递依赖于R的候选键，则称R是第三范式的模式。

61 BCNF：

如果关系模式R是第一范式，且每个属性都不传递依赖于R的候选键，那么称R是BCNF的模式。从BCNF的定义可明显地得出如下结论：

（1） 所有非主属性对键是完全函数依赖。

（2） 所有主属性对不包含它的键是完全函数依赖。

（3） 没有属性完全函数依赖于非键的任何属性组。

如果模式R是BCNF，则它必定是第三范式，反之，则不一定。

62 模式设计方法的原则：

关系模式R相对于函数依赖集F分解成数据库模式ρ＝｛R1，R2，……Rk｝，一般应具有下面三个特性：

（1） ρ中每个关系模式Ri是3NF或BCNF

（2） 保持无损联结

（3） 保持函数依赖集

（4） ρ中模式个数最少和属性总数最少。

63 一个好的模式设计方法应符合哪三条原则：

表达性，分离性，最小冗余性。

表达性涉及到两个数据库模式的等价性问题，即数据等价和依赖等价，分别用无损联接和保持函数依赖性来衡量。

分离性是指属性间的“独立联系”应该用不同的关系模式表达。

最小冗余性要求在分解后的数据库能表达原来数据库的所有信息这个前提下实现。

关系模式设计方法基本上可以分为分解与合成两大类。

64 多值依赖MVD：

设R（U）是属性集U上的一个关系模式，X，Y是U的子集，若对R（U）的任一关系r，对于X的一个给定的值存在着Y的一组值与其对应，同时Y的这组值又不以任何方式与U-X-Y中的属性相关，那么称Y多值依赖于X，记为X→→Y。

65 平凡多值依赖：

对于属性集U上的一个多值依赖X→→Y，如果Y X或者XY=U，那么称X→→Y是一个平凡多值依赖。

66 第四范式（4NF）：

设关系模式R，D是一个多值依赖集，如果D中存在一个非平凡多值依赖X→→Y，并且X必是R的超键，那么称R是4NF模式。

一、摇篮和萌芽阶段：首先使用"DataBase"一词的是美国系统发展公司在为美国海军基地在60年代研制数据中引用。

1963年，C·W·Bachman设计开发的IDS(IntegrateDataStore)系统开始投入运行，它可以为多个COBOL程序共享数据库。

1968年，网状数据库系统TOTAL等开始出现;

1969年，IBM公司McGee等人开发的层次式数据库系统的IMS系统发表，它可以让多个程序共享数据库。

1969年10月，CODASYL数据库研制者提出了网络模型数据库系统规范报告DBTG，使数据库系统开始走向规范化和标准化。正因为如此，许多专家认为数据库技术起源于20世纪60年代末。数据库技术的产生来源于社会的实际需要，而数据技术的实现必须有理论作为指导，系统的开发和应用又不断地促进数据库理论的发展和完善。

二、发展阶段：20世纪80年代大量商品化的关系数据库系统问世并被广泛的推广使用，既有适应大型计算机系统的，也有适用与中、小型和微型计算机系统的。这一时期分布式数据库系统也走向使用。

1970年，IBM公司SanJose研究所的E·F·Code发表了题为"大型共享数据库的数据关系模型"论文，开创了数据库的关系方法和关系规范化的理论研究。关系方法由于其理论上的完美和结构上的简单，对数据库技术的发展起了至关重要的作用，成功地奠定了关系数据理论的基石。

1971年，美国数据系统语言协会在正式发表的DBTG报告中，提出了三级抽象模式，即对应用程序所需的那部分数据结构描述的外模式，对整个客体系统数据结构描述的概念模式，对数据存储结构描述的内模式，解决了数据独立性的问题。

1974年，IBM公司SanJose研究所研制成功了关系数据库管理系统SystemR，并且投放到软件市场。

1976年，美籍华人陈平山提出了数据库逻辑设计的实际（体）联系方法。

1978年，新奥尔良发表了DBDWD报告，他把数据库系统的设计过程划分为四个阶段:需求分析、信息分析与定义、逻辑设计和物理设计。

1980年，J·D·Ulman所著的《数据库系统原理》一书正式出版。

1981年E·F·Code获得了计算机科学的最高奖ACM图林奖。

1984年，DavidMarer所著的《关系数据库理论》一书，标志着数据库在理论上的成熟。

三、成熟阶段：80年代至今，数据库理论和应用进入成熟发展时期易观国际发布《IT产品和服务－2007年中国数据库软件市场数据监测》，考察了中国数据库管理软件市场。数据显示，中国商业数据库市场2007年度整体规模达到2172亿人民币，比去年同期增长15%。从厂商竞争格局来看，国际软件巨头占据市场的绝大多数份额。Oracle、IBM、Microsoft和Sybase牢牢占据国内数据库软件市场前四位，拥有938%的市场份额。国产数据库的市场份额在本季度继续提升，正在抓住国家提倡自主创新的机遇，以“有自主知识产权”的产品为契机，满足部委和地方政府的信息整合平台需求。2008年，中国商业数据库市场整体规模达到了2825亿元，比上个年度增长了30%，一方面，主要是因为中国电子政务建设的大幅增加，以及中国政府对版权的高度重视。其中，Oracle占据了其中44%的市场份额，IBM占据了其中20%的份额、微软占据了18%的份额，Sybase占据了10%，而国产数据库因为在政府的支持下，已经占据了8%的市场份额，较2007年同比提升了25%。其中，达梦数据库年销售额为6600万元，为国产数据库中市场份额最大的。预计中国商业数据库市场在2009年达到31亿元的市场规模，同时，国产数据库在中国政府鼓励自主创新的基础下，会占据更大的市场份额。另外，包括Mysql等开源数据库也占据了大量的政府及中小企事业用户，同时，盗版数据库更是占据了中国数据库市场的较大份额，其数值不亚于整个商业数据库的市场份额。

数据库系统:databasesystem(DS)，databasemanagementsystem(DBMS)，数据库系统(DS)，数据库管理系统(DBMS)，关系和关系数据库table=relation，column=attribute属性，domain，atomicdomain，row=tuple，relationaldatabase，relationschema，relationinstance，databaseschema，databaseinstance;

数据库系统（DataBaseSystem，DBS)定义：是由数据库，数据库管理系统（及应用开发工具），应用程序和数据库管理员（DataBaseAdministrator，DBA）组成的存储，管理，处理和维护数据的系统。

一、学习一种简单的文件型数据库的应用，比如ACCess或Foxpro(Foxbase)，了解最基础的 *** 作。

二、学习数据库原理或叫数据库概论的书，掌握关系型数据库的理论

三、学习大型数据库，比如MySql,Oracle或Sqlserver，掌握数据库的安装、维护管理和开发应用。

一门课一个月，三个月就可以应付一般的工作了。

　要说数据库，一般以SQL Server作为入门的学科，它适合中小型项目开发，而现在比较流行于大型开发的有:

Oracle

现在具有企业大型软件的绝对占有率

DB2 在以IBM服务的公司以及单位（中国银行）

MySql 相对不是很正式的开发，使用MySql

当然还有一些：Access(桌面数据库),FoxPro(中国教育),Informix的数据库系统

刚开始入门的时候可以找点视频教程来学习，视频教程一般讲得比较好，但不要企图于通过它达到比较高的水平。然后要学会将自己所知道的去实践，多实践。当觉得实践到一定程度而没有什么冲劲了，就去学习理论，当觉得理论知识需要发挥的时候就去实践，时间的周期不一定，没有什么定论，但自己的时间安排需要定论就可以了。

我一直都认为在计算机行业要学会一门技术太简单了，但如果要把技术发挥到一定程度就有难处了，一定程度是什么意思，就是把技术如何发挥到具体的业务之中，会动脑筋去思考，而把技术作为相对次要的东西了。

数据库的DBA人员需要兼有系统分析员和运筹学的业务素质。在技术上讲，我个人认为数据库的前续学科是“数据结构”。

我现在刚学SQL Server一段时间,就自己的感想谈谈:

1数据库是非常快的数据处理程序,其内在的本质依旧是"文件"因为

Windows *** 作系统管理机制就有:磁盘、文件、目录。Linux的方式只有文件。所以数据库重本质的角度来说是一种平台软件，是将文件翻译成逻辑语言的软件，成为我们软件程序数据交换的中心，为什么那，一个很重要的原因就是“快”，还有就是“安全”、“集成”等等。因为以前的语言程序要处理数据要编写大量算法十分麻烦而且很容易出错等等。大家就想到集成了。。。。。

2其实，要谈到 *** 作数据库，简单的就太简单了，但是数据库最难的不是 *** 作，而是在数据库的设计上。一个大型程序设计者肯定是一个数据库的高手，因为大型程序要死板地去完成它是非常困难和不理智也是不安全不稳定的，我们要充分利用自己所有的能力去挖掘其数据之间的奥秘，然后体系化数据库结构，相当于在数据库中如何层次化地建立数据结构。将需求中的矛盾事物改变成可以相互融合的。

我说的数据库 *** 作简单是指一般 *** 作，如果难的 *** 作还是有点技术的，但还是难不到那里去。下面我把我的一个小数据库程序给你看看：（下面这个程序已经建立数据库library，然后用dbo用户建立了表relatBook，并将表的第一个字段设置为“主键”PK）

该程序想说的第一点是：程序按照标准用户写入法则写入。

另外就是在执行多个 *** 作的时候每一步骤的 *** 作我们都必须为其设置错误的回滚 *** 作。所以程序前两个段落都是一样的，在插入的时候故意出现异常，看第1和第3个语句是否能成功执行。

从上面看出点什么没有，你我执行了三个 *** 作，第一个 *** 作是肯定成功的，第二个是肯定失败的，第三个跟在后面，那么你想一想第一个和第三个 *** 作能插入数据库中吗？我这个程序没有什么意义，但只是未了说明问题。

答案是：不能。

为什么不能，这是SQL所支持的“事务”外完成的，这是技术问题，没有什么的，会了大家都会。为什么要这样做那，那才是要学习的前提。你想一想如果你建立了一个地区的帐物管理系统，当一个单位向另外一个单位转帐的时候，需要执行两个 *** 作就是将一边的信息刷掉，一边的信息添加上去，而当执行一半的时候出现了某种异常中断，比如高优先级的抢占，服务器重起、停电。当时你知道有多少人在访问你的服务器，那要造成多大的数据库信息丢失，甚至于导致数据库的查询的严重失败。那么我就知道需要上面知识的支持了。

3为什么说上面的东西都很简单那，因为只要你会，那就可以了，而设计方面的东西是永远不是那么简单的，永远带有创新和追求，没有最高的境界。

就一个十分常见的问题，如何在数据库中配合好人员、角色、权限、类别、级别、可 *** 作性这几者的关系，如果是没有经验的人直接上手可能会乱来（我们最早也是这样的）。有经验的人也会设计一段时间，而且随着软件复杂性的增加，其数据库的这几者之间的复杂性就越来越复杂。所以大型软件是非常难的。就一个很简单的例子，在很多的网站中，有上百的栏目信息，而每一个栏目间又保持独立。的位置和的信息都是动态更新的。某些网站的可 *** 作性都以树型结构提供，而树型结构的子树类别和和叶子都是不重复而不错误。而且其层数都是动态的。有些人给我说可以通过前台的判定语句来执行树型结构的生成，但我问了一个问题，如果是一个邮政编码系统，有几十万个邮政编码你在前台要写多少个case语句，而且每一次要遍历一次已经生成的树，还有用前台的case语句编写出来的树型结构其二级子树全部“定死”，而且树型结构的层树也被定死。这不是完全动态级别的网站。为以后对网站的维护带来麻烦。

总之，数据库是一门入门容易却达到高手很难的学科,通过不断在失败中吸取经验,才能得到一些书籍上无法学会的东西,那才是真正的高手。也就是说，学技术是很快的，要会将技术运用于实际的业务分析，才可以成为一个自我型的DBA，而不是一个简单的程序员。

以上就是关于大型数据库的设计原则与开发技巧全部的内容，包括:大型数据库的设计原则与开发技巧、数据库原理第四章关系数据库的模式设计、数据库的发展过程等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！