数据库设计
● 开发与平台无关的数据库应用程序
目前国际上应用最广泛的数据库系统有Oracle、DB2、Informix、Sybase和SQL Server。
这些数据库系统之间的激烈竞争即有好处又有坏处。竞争的好处是使数据库系统不断发展和完善,并且避免价格垄断。竞争的最大坏处是逼迫数据库厂商不断开发出独特的功能以吸引更多的用户,所以各个数据库系统的独特功能无法形成统一标准,导致用户难以开发出与平台无关的数据库应用程序,因为用户很难抵御数据库系统独特功能的诱惑。
读者也许会问:“结构化查询语言(SQL)难道不是数据库系统的标准吗?”
是的,SQL是数据库系统的标准查询语言。可是数据库厂商提供了太多超出SQL标准的特色功能,使人们陷入了进退两难的境地:
如果你想使程序与数据库平台无关,那么只能使用SQL,放弃各个数据库系统的独特功能。
如果你超越SQL,使用了某个数据库系统的独特功能,那么这样的程序就是与平台相关的。
类似问题也存在于操作系统、Web浏览器这些领域。理论上讲,只有绝对垄断才能形成绝对统一的标准,但是人们既希望打破垄断又希望有统一的标准,这种矛盾无法彻底解决,只能折衷、妥协。建议如下:
如果你开发的是通用的数据库应用软件,不想让应用软件与特定的数据库系统捆绑在一起,那么你就老老实实地用SQL语言写程序。
如果你开发的是行业专用的数据库应用软件,并且这个行业已经指定了数据库系统(这种局部垄断现象普遍存在),最近若干年都不会改变的话,那么你可以超越SQL使用该数据库系统的独特功能。
● 数据库性能优化问题
数据库设计的主要挑战是“高速处理大容量的数据”。如何优化数据库的性能是设计人员经常面临的问题。数据库性能优化主要有两种途径:
优化表结构本身。例如对第三范式的表结构进行反规范化处理,允许表中存在冗余数据,从而减少多个表链接操作,达到提高性能的目的。
优化数据库的环境参数。例如提高硬件设施,调整表的空间尽量减少数据碎片等。
在表的物理设计阶段,设计人员应当按照第三范式设计表结构(即规范化处理)。这样做的好处是:表中没有冗余数据,表结构很清晰,将来修改或者扩充非常方便。但是按第三范式设计也存在一些缺点:产生了许多表,每个表有相对较少的列,并且这些列必须使用“主健/外健”关联起来,因此某个查询操作可能会产生复杂的表链接,导致性能降低。
反规范化处理是指对第三范式的表进行修改,通过合并一些表,或者在表中创建冗余的列,从而减少表链接操作代价,达到提高性能的目的。要注意的是反规范化处理存在很大的负面影响:管理冗余数据很麻烦,如果冗余数据不同步的话,那么会发生数据错误这种严重的问题。
所以,对表进行第三范式的规范化处理是第一重要的,而反规范化处理则需谨慎考虑、不宜过多使用。“规范化处理”以及“反规范化处理”不是自相矛盾之举,而是性能优化的策略。
除了优化表结构之外,优化数据库的环境参数也能够提高数据库的性能。例如给服务器配置更快的CPU,增加内存。运行数据库是非常消耗内存的,内存对数据库性能影响比较大。由于现在市场上的内存条越来越便宜,所以为服务器配置足够多的内存恐怕是成本最低、难度最低、见效最快的性能优化方法。
在安装数据库系统时,要为系统指定“块大小”(一次物理读写操作所设计的字节数)。在创建表时,也要为表指定一定的空间。如果“块大小”和“表空间”与实际的数据存储不匹配的话,那么会产生许多磁盘碎片,这将降低数据库物理操作的性能。
能否有效地优化应用软件数据库的性能,主要取决于开发者对数据库系统的熟悉程度以及开发经验。
● 数据库安全问题
提高软件系统的安全性应当从“管理”和“技术”两方面着手。这里仅考虑技术手段(因为安全管理超出了软件工程范畴),一般原则如下:
用户只能用帐号登陆到应用软件,通过应用软件访问数据库,而没有其它途径可以操作数据库。
对用户帐号的密码进行加密处理,确保在任何地方都不会出现密码的明文。
确定每个角色对数据库表的操作权限,如创建、检索、更新、删除等。每个角色拥有刚好能够完成任务的权限,不多也不少。在应用时再为用户分配角色,则每个用户的权限等于他所兼角色的权限之和。
模块设计
在设计好软件的体系结构后,就已经在宏观上明确了各个模块应具有什么功能,应放在体系结构的哪个位置。我们习惯地从功能上划分模块,保持“功能独立”是模块化设计的基本原则。因为,“功能独立”的模块可以降低开发、测试、维护等阶段的代价。但是“功能独立”并不意味着模块之间保持绝对的孤立。一个系统要完成某项任务,需要各个模块相互配合才能实现,此时模块之间就要进行信息交流。
评价模块设计优劣的三个特征因素:“信息隐藏”、“内聚与耦合”和“封闭——开放性”。
● 信息隐藏
为了尽量避免某个模块的行为去干扰同一系统中的其它模块,在设计模块时就要注意信息隐藏。应该让模块仅仅公开必须要让外界知道的内容,而隐藏其它一切内容。
模块的信息隐藏可以通过接口设计来实现。接口是模块的外部特征,应当公开;而数据结构、算法、实现体等则是模块的内部特征,应当隐藏。一个模块仅提供有限个接口(Interface),执行模块的功能或与模块交流信息必须且只须通过调用公有接口来实现。如果模块是一个C++对象,那么该模块的公有接口就对应于对象的公有函数。如果模块是一个COM对象,那么该模块的公有接口就是COM对象的接口。一个COM对象可以有多个接口,而每个接口实质上是一些函数的集合。
● 高内聚
内聚(Cohesion)是一个模块内部各成分之间相关联程度的度量。内聚程度从低到高大致划分为低端、中段和高端,如图3-15所示。模块设计者没有必要确定内聚的精确级别,重要的是尽量争取高内聚,避免低内聚。
顺序性内聚 功能性内聚
时序性内聚 过程性内聚 通讯性内聚
偶然性内聚 逻辑性内聚
低端… 中段… 高端…
各种内聚类型的含义如下:
偶然性内聚。如果一个模块的各成分之间的关系彼此松散(几乎无关),称为偶然性内聚。
逻辑性内聚。几个逻辑上相关的功能被放在同一模块中,则称为逻辑性内聚。例如一个模块读取各种不同类型外设的输入。
时序性内聚。如果一个模块内的几个功能必须在同一时间内执行(如系统初始化),但这些功能只是因为时间因素关联在一起,则称为时间性内聚。
过程性内聚。如果一个模块内部的处理成分是相关的,而且这些处理必须以特定的次序执行,则称为过程性内聚。
通信内聚。如果一个模块的所有成分都操作同一数据集或生成同一数据集,则称为通信内聚。
顺序内聚。如果模块内的某个成分的输出作为另一个成分的输入,则称为顺序内聚。
功能内聚。模块的所有成分对于完成单一的功能都是必须的,则称为功能内聚。
● 低耦合
耦合(Coupling)是模块之间依赖程度的度量。内聚和耦合是密切相关的,与其它模块存在强耦合的模块通常意味着弱内聚,而强内聚的模块通常意味着与其它模块之间存在弱耦合。
耦合的强度依赖于以下几个因素:(1)一个模块对另一个模块的函数调用数量;(2)一个模块向另一个模块传递的数据量;(3)一个模块施加到另一个模块的控制的多少;(4)模块之间接口的复杂程度。
耦合程度从低到高大致划分为低端、中段和高端,如图3-16所示。模块设计应当争取“高内聚、低耦合”,而避免“低内聚、高耦合”。
印记耦合 控制耦合
公共耦合 内容耦合
非直接耦合 数据耦合
低端… 中段… 高端…
各种耦合类型的含义如下:
非直接耦合。模块之间没有直接的信息传递,称为非直接耦合。
数据耦合。模块之间通过接口传递参数(数据),称为数据耦合。
标记耦合。模块间通过接口传递内部数据结构的一部分(而不是简单的参数),称为印记(Stamp)耦合。此数据结构的变化将使相关的模块发生变化。
控制耦合。模块传递信号(如开关值、标志量等)给另一个模块,接收信号的模块根据信号值调整动作,称为控制耦合。
公共耦合。两个以上的模块共同引用一个全局数据项,称为公共耦合。
内容耦合。当一个模块直接修改或操作另一个模块的数据,或者直接转入另一个模块时,就发生了内容耦合。
数据结构与算法设计
设计高效率的程序是基于良好的数据结构与算法,而不是基于编程小技巧。
一般说来,数据结构与算法就是一类数据的表示及其相关的操作(这里算法不是指数值计算的算法)。从数据表示的观点来看,存储在数组中的一个有序整数表也是一种数据结构。算法是指对数据结构施加的一些操作,例如对一个线性表进行检索、插入、删除等操作。一个算法如果能在所要求的资源限制(Resource Constraints)范围内将问题解决好,则称这个算法是有效率(Efficient)的。例如一个资源限制可能是“用于存储数据的内存有限”,或者“允许执行每个子任务所需的时间有限”。一个算法如果比其它已知算法所需要的资源都少,这个算法也被称为是有效率的。算法的代价(Cost)是指消耗的资源量。一般说来,代价是由一个关键资源例如时间或空间来评估的。
毋庸置疑,人们编写程序是为了解决问题。只有通过预先分析问题来确定必须达到的性能目标,才有希望挑选出正确的数据结构。有相当多的程序员忽视了这一分析过程,而直接选用某一个他们习惯使用的,但是与问题不相称的数据结构,结果设计出一个低效率的程序。如果使用简单的设计就能够达到性能目标时,选用复杂的数据结构也是没有道理的。
人们对常用的数据结构与算法的研究已经相当透彻,可以归纳出一些设计原则:
1) 一种数据结构与算法都有其时间、空间的开销和收益。当面临一个新的设计问题时,设计者要彻底地掌握怎样权衡时空开销和算法有效性的方法。这就需要懂得算法分析的原理,而且还需要了解所使用的物理介质的特性(例如,数据存储在磁盘上与存储在内存中,就有不同的考虑)。
2) 开销和收益有关的是时间——空间的权衡。通常可以用更大的时间开销来换取空间的收益,反之亦然。时间——空间的权衡普遍地存在于软件开发的各个阶段中。
3) 设计人员应该充分地了解一些常用的数据结构与算法,避免不必要的重复设计工作。
4) 数据结构与算法为应用服务。我们必须先了解应用的需求,再寻找或设计与实际应用相匹配的数据结构。
数据结构与算法设计的一般流程如下:
(1)数据结构与算法有全局和局部之分,当然先设计全局的,后设计局部的(通常在模块设计时进行)。
(2)根据问题的特征,先查找已经存在的数据结构与算法,挑选最合适的(并不一定是最先进的)。如果不存在现成的,那么自己设计。
(3)设计并且编写代码之后,要进行测试。如果不满足性能要求,那么要进一步优化数据结构和算法。
责任编辑:小草