数据库设计规范
左锋义【草】2010-3-3 锋恩科学技术发展有限公司
1. 数据库设计的模式准则:三级模式二级映像
1.1. 外模式
外模式,也称为用户模式。在一个数据库模式中,有N个外模式,每一个外模式对应一个用户。外模式保证数据的逻辑独立性。
设计外模式要保证数据的可扩展性。一个外模式对应一个用户需求;这些需求在相同的数据结构中具有可扩展性,如果说用户的需求对数据结构的改动比较大,这表明用户模式需要重构。用户需求的变更比较频繁和导致的数据结构的重构,这些需求可能导致整个数据库都需要重新设计。因此,外模式保证的数据逻辑独立性是相对于相对稳定的数据模式的。
外模式在关系数据库中用视图来表示。因为有一部分更新视图理论上是不可以更新的;又由于数据库管理系统厂家实现数据库的复杂度不同,也有一部分理论上可以更新的视图而在实际项目开发中而不能更新。一般行列子集视图是可以更新的;表达式视图和分组视图不可以更新。
外模式提供了数据隐藏和隔离的功能,不同的用户具有不同的数据;这就保证了数据的安全性。
外模式屏蔽了程序员的编码复杂性,隐藏了数据的存储路径和一些底层些节。这样程序员只关注业务逻辑,提高了开发效率。
外模式使得功能测试成为可能,因为外模式对应不同的用户,不同的用户具有有限的功能,这有利于测试用例的制定和测试文档的合成。
外模式规定了用户操作界面。这就保证了系统菜单的存在性。
外模式规定了用户操作手册。这就为产品没有开发出来,为企业提供了先行培训的可能性,提供了企业的竞争力。
在项目设计中,在数据库方面表现为E-R图,在业务逻辑方面表现为数据流程图。
1.2. 模式
模式属于逻辑模型,因此,对于一个数据库只有且仅有一个模式。模式向外模式提供了统一的操作界面。模式保证了数据的物理独立性。
模式是整个项目的对象及其联系的有机整体。模式规定了数据操作的逻辑即数据流的流动方向和行为。
模式包含了整个数据库的所有对象,因此,这有利于构建模块、构建接口;有利于调整模块之间数据耦合度、对象层册的建模。
模式包含了对象这件的联系,因此,这些保证了数据流的流向或消息发送的目标;进而,规定了对象的状态,从而使得数据完整性有据可依。
模式使得视图的构建成为可能。视图可能需要多个表来组建,而模式的修改在一定程度上
隔离组建视图的可能性,进而,不会影响用户业务逻辑。
模式使得集成测试有了保证。这不仅规定了要先测试那些模块,而且也规定了要先测试那些层册的模块。
模式使得结构化设计成为可能。不仅可以映射到外模式的设计,同时也反映到内模式的设计。由此可以看出,模式是系统的核心,也是模式设计的关键。
在项目设计中,在关系数据库中表现为数据关系,在业务逻辑方面表现为模块接口。
1.3. 内模式
内模式属于物理模式,因此,一个数据库只有一个内模式;内模式规定了数据的存储方式、规定了数据操作的逻辑、规定了数据的完整性、规定了数据的安全性、规定了数据存储性能。
内模式是建立在开发环境的基础上,因此,开发环境必须提供数据的存储方式、数据完整性、数据安全性、数据存储性能的支持以及开发语言功能完备性的支持。所以,内模式决定了一个项目要采用的开发环境。从而,一个项目依赖于开发环境,进而决定了一个企业是否具有这样的开发环境、是否具有这方面的人才储备。
内模式规定了数据的完整性。要求系统必须提供或者手动提供完整性的约束,保证数据的正确性、安全性。
内模式规定了数据的操作逻辑。数据的操作逻辑应该封装成单元,提供统一一致的接口,提供确定的服务。因此,内模式确定了单元测试的过程;确保进行各种测试提供了基础性的技术保障和项目成功交付的先决条件。
内模式规定了数据的可靠性。由不同的操作逻辑重复验证一个确定的输入和是否有一个确定的输出,通过仲裁机制可以完成数据的可靠性。
内模式制定了模块间以及模块内的服务接口。这样可以提供程序的并行开发,加快开发速度。同时,审计服务接口可以确保命名空间是否冲突、功能是否完善、前期制定接口测试用例、编写功能说明书和测试档案等。
内模式为保证系统性能提供了保障。根据测试,可以找到系统的运行瓶颈。系统的性能测试的准则是保证整体性能的前提优化局部系能。
内模式还有保证系统的安全性,限制数据的存储,系统日志记录,以及错误发生后的恢复,用于系统管理的高级操作等。
随着系统的运行,系统的一些功能可能需要优化、一些错误需要排除、一些需求可能需要变更;这就为内模式的重构提供了需求基础;因此,内模式的修改最大化的不要影响模式的变更,从而保证数据的物理对立性和逻辑独立性。
1.4. 外模式/模式映像
外模式/模式映像功能是保证数据逻辑对立性的。有关数据逻辑独立性的相关信息都保存在外模式中:包括数据类型,数据来源,数据完整性检测,约束关系等。外模式提供给程序员,是程序员处理的对象,是业务逻辑加工的对象。外模式减轻了程序员的工作量,屏蔽了访存控制操作逻辑。最重要的是,当模式修改时,只要保证外模式的界面不变,就不许有更改用户业务逻辑。
1.5. 模式/内模式映像
模式/内模式映像功能是保证数据物理独立性的。数据物理独立性的信息记录在模式中:包括数据类型,数据完整性,约束关系,安全性,对性能的要求。模式是数据库的核心,一般通过概念模型抽象得到,然后,向上转换到用户模型,向下转换到物理模型。因此,模式是设计外模式和内模式的关键,同时,也反映了系统架构。
2. 数据库设计的模型准则:概念模型、逻辑模型、物理模型
2.1. 概念模型
2.1.1. E-R
E-R模型是实体联系模型。E-R模型用来呈现实体的属性以及实体之间的联系;是语义范围内的模型;通过需求分析,从功能中提取出数据。
2.1.2. UML
UML模型是对象模型。UML表示了对象具有的属性、事件、方法以及对象之间消息的发送。
实体联系E-R模型和统一建模UML模型都可以很好的描述现实世界、易于理解、易于实现、通用性强,因此这两种模型要求熟练掌握。
2.2. 逻辑模型
2.2.1. LM
层次数据库模型能很好的表达数据的完整性、存储效率较高,但是数据独立性比较差。
2.2.2. NM
网状数据库模型能比层次数据库模型更好的表述世界,也具有存储效率高的特点,但是,数据完整性和独立性控制也是比较差。
2.2.3. RM
关系数据库模型是以关系代数为基础,具有形式化理论化的演算方法。因此关系数据库能够达到项目设计的目标。关系模型和层析模型、网状模型的最主要区别就是数据结构单一和需要查询优化。
2.2.4. OOM
面向对象的模型是采用面向对象的方法来建模现实世界。
2.2.5. 模糊模型
2.3. 物理模型
物理模型主要是指数据在存储设备上的存储格式,这种格式要有利于快速访问和存储,有利于提高数据的访问效率。数据的存储格式主要有:B+结构、图结构、Hash结构、拓扑结构、
聚簇结构等
3. RDBMS关系数据库设计的十二条准则
3.1. 关系数据库的自管理准则
关系数据库的自管理准则不仅要用关系管理用户数据库系统,而且还要管理RDBMS系统;不仅要实现系统的数据字典,还要用数据字典管理用户的实体联系以及权限等内容。关系数据库的自管理准则是关系的最基本的准则,也是关系数据库设计的十二条准则的基石。
3.2. 信息准则
信息准则保证关系数据库要有统一的数据结构,并且这样的数据结构具有描述现实世界的能力;这种结构不仅规定了数据输入格式,而且也规定了数据的输出格式。
3.3. 保证访问准则
保证访问准则要求对关系的操作支持完备,而且这些操作要保证数据物理独立性,不仅要屏蔽数据的存储机制,还要是业务逻辑处理流程清晰,具有较高的语义性、可读性、可维护性、可扩展性和可移植性。
3.4. 空值的系统处理准则
系统化的处理空值:非主属性空值、参照属性空值处理、不同数据类型的空值间的相互转换。提供系统化的空值处理不仅有利于业务逻辑验证,有利于数据完整性约束;而且主要的是提高了系统的开发效率。
3.5. 数据字典准则
数据字典记录了系统的各种操作规范、约束条件、存储管理机制。可以动态的添加、修改、删除数据库系统的应用信息,同时保证动态联机的扩展性。
3.6. 统一的数据子语言准则
全面支持数据库的各种操作语言:数据定义语言DDL,数据查询语言DQL,数据操纵语言DML,数据控制语言DCL。提供统一的数据子语言支持自含式编程和嵌入式编程。
3.7. 视图更新准则
视图更新准则是从应用角度提供三级模式二级影像功能的支持,最大程度化的保证了数据的逻辑独立性和物理独立性。视图一般有行列子集视图、表达式视图、分组视图。这些视图有一部分在理论上是可以更新的,有一部分是不可以更新的。对于理论上可以更新的视图,由于关系数据库管理系统产品对于这部分的支持不同,因此在开发数据库系统时要对产品进行考察,判断它是否支持视图更新机制以及支持的程度。一般原则是理论上可以更性的视图,要保证视图可以更新。视图更新的原理来自于视图消解。
3.8. 高级别的插入更新和删除准则
高级别的插入更新和删除准则,首要条件就是保证数据数据的完整性;不紧要支持多表操作,还要支持查询结果的存储、导出等。在数据插入更新和删除操作市一定要保证不同的机制,进行约束控制验证,以及在故障出现时能恢复系统。
3.9. 物理独立性准则
物理对立性准则是提供三级模式二级映像功能服务中最基本的原则,该准则保证业务逻辑与内模式的相对对立,使得数据结构的变更或重构不至于影响业务逻辑的处理。物理独立性准则主要是规划数据的存储和访存效率,提供系统的性能。目前,集中数据库的数据的存储开销主要是I/O瓶颈,分布式数据库的问题主要在于网络传输开销。
3.10. 逻辑独立性准则
逻辑独立性准则是提供三级模式二级映像功能服务业务逻辑的服务,是处理业务逻辑与模式的相对独立性。逻辑独立性保证数据模式的修改不至于影响业务逻辑的处理,从而使得程序员有足够的精力处理算法分析,提供程序的可理解性,可维护性。
3.11. 完整独立性准则
完整独立性准则保证数据更新要保证数据的语义完整性。完整独立性不仅体现在自动验证数据之间的约束,而且也体现出用户语义的完整含义,从而提高系统的可靠性、提高系统的开发效率。
3.12. 分布式独立性准则
分布式独立性准则保证数据的物理存储位置对用户是透明的。分布式独立性准则向用户提供数据的访问机制,用户不需要了解数据到底存储在什么地方。分布式对立性准则是从数据的物理存储场地来阐述,目的是提供服务的质量。
3.13. 无破坏准则
无破坏准则通常表述为宿主语言与数据库语言的阻抗匹配,要求宿主语言不能破坏或绕过完整性准则和用高级关系语言表达的约束条件。通常情况是绕过关系数据库管理系统而直接修改数据库文件,在这种情况下,数据库管理系统要有监测完整性的机制,从而保证数据库的无破坏准则。
4. RDBMS关系数据库的完整性准则
4.1. 实体完整性准则
实体完整性表述为,在一个实体集中,每一个对象都是可以自描述的或者通过一个符号来标识;换句话说,就是标识每一个对象的符号是唯一确定的。总之,实体完整性要求码或键不能是空值。
4.2. 参照完整性准则
参照完整性表述为,一个实体的属性要依靠另一个实体的属性(码或键)。参照完整性就是限制一个实体的外码属性要么取空值,要么取另一个实体的属性值(码或键)。参照完整性定义了在插入更新和删除记录市要保证的约束条件。
4.3. 自定义完整性准则
自定义完整性准则通常情况下是定义实体内部属性之间要满足的约束条件,是语义范围内业务逻辑在数据库上的实现,用数据库的约束机制减轻业务逻辑的复杂度。
5. RDBMS关系数据库的查询优化准则
选择运算
投影运算
链接运算
并运算
差运算
关系数据库查询优化是关系数据库管理系统实现的关键技术,因为关系运算提供可保证访问的不依靠物理路径的方式,因此,关系运算不进行优化很可能导致性能低下。因为关系运算有较高的语义性,并且有关系代数演算理论支持;所以,能够重建关系语法树通过关系演算来优化系统运行性能。
查询优化的步骤是:
尽可能早做选择运算和投影运算;如果能同时执行选择运算和投影运算的应该一次进行运算;如果不能同时执行的运算,要先做选择运算,再做投影运算。
尽可能推迟链接运算。链接运算是数据库操作中最常用的运算,也是最影响性能的运算。
最后执行并运算和差运算。
6. RDBMS关系数据库的范式准则
关系数据库范式是关系数据库设计的标准和尺度,是衡量一个数据库模式符合哪一级别范式的有用工具。一个数据库根据实际系统需要,决定要达到的范式级别。
6.1. 1NF原子性范式
第一范式:原子性范式是关系数据库最基本的准则,关系中的每一项都必须是不可再分的数据,也就是说,关系不能嵌套关系。
6.2. 2 NF非主属性对码的非部分非平凡的函数依赖范式
第二范式,是非主属性对码的部分非平凡函数依赖,如果在关系中非主属性对码有部分依赖,则说明该范式不是第二范式,因此要进行模式分解,直到消除了部分依赖,满足第二范式。
6.3. 3 NF非主属性对码的非传递性非平凡的函数依赖范式
第三范式,是非主属性对码的传递非平凡函数依赖,如果在关系中非主属性对码有传递非平凡函数依赖,则需要进行模式分解,直到消除了非平凡传递函数依赖。
6.4. BCNF主属性对码的非部分或传递非平凡的函数依赖范式
BCNF范式是修正的第三范式,主要是处理主属性之间的部分函数依赖或传递函数依赖,如果一个关系中主属性之间有部分函数依赖或传递函数依赖,则需要进行模式分解,直到达到第三范式。
6.5. 4 NF主属性对码的非多值非平凡的多值依赖范式
第四范式是解决主属性之间非平凡多值依赖的问题,如果主属性之间存在多值依赖,那么,该关系不是第四范式,必须进行模式分解,以达到第四范式。
6.6. 5 NF主属性对码的非链接依赖范式
第五范式是解决域-码之间的连接依赖。第一范式到第四范式是解决语义范围的问题,而第五范式是连接之间的问题。
7. RDBMS关系数据库的模式分解准则
关系数据库进行规范化模式分解的原则就是分解后的关系可进行可逆化的操作、必须与原关系等价。模式分解的准则一般有:无损连接模式分解准则,函数依赖模式分解准则。
7.1. 保持无损链接模式分解准则
保持无损连接就是在模式分解之后,进行连接操作能够和模式分解之前相等价,既不会产生无效的记录,也不会产生冗余的记录。
7.2. 保持函数依赖模式分解准则
保持函数依赖模式分解就是进行模式分解后,原关系属性之间的函数依赖不能被破坏。
使用不同的模式分解准则,将达到不同的范式;具体使用模式分解达到那一个范式,由系统的具体实现要求有关。
7.3. 既保持无损链接又保持函数依赖分解准则
8. 数据库的可扩展性准则
设计的数据库的可扩展性要强,这是设计数据库时要保证的一个基本准则。要给可预见的操作行为、功能使用留下扩展的机会,以避免系统运行后功能的修改而影响整个系统的运行。数据库的扩展一般包括:模块扩展、功能扩展、和系统的可配置性。
8.1. 模块扩展
模块扩展,就是在系统运行中能很方便的在系统中嵌入一个模块,而且,嵌入的模块不影响或者很少影响其他模块。这种即插即用的模块扩展是满足系统可配置的首要前提。
8.2. 功能扩展
功能扩展就是为接口考虑过多的需求,一旦需要,直接启动这个接口即可,功能扩展应该不影响其他业务逻辑。
8.3. 功能裁剪(可配置性)
可配置性就是可以动态的加载功能模块,把需要的屏蔽掉;并且,可以随时启用被屏蔽调的功能。
9. 自动存储控制准则
自动存储控制是保证数据安全的一个方法,是数据库管理系统为应用程序提供的用户自动存储数据的安全审核。一般是通过权限的分配和回收来实现自动存储控制。权限的分配和回收一般包括操作对象和操作行为,是定义权限的具体内容。
权限的分配和回收
操作对性:属性、表、视图、存储过程、数据库
操作行为:查询、插入、修改、删除、创建、所有行为
10. 数据库管理员帐户(角色)和用户的权限配置
在做数据库设计时,首要的问题是实现数据库的所有功能,同时尽可能早的定义每个功能的使用权限,这样能保证在设计数据库的同时,能够确定每一个功能的权限和不同角色的所对应的菜单项,这就保证编制后台管理菜单时不至于重读设计文档以及再考虑菜单设置的级别等。通常情况下应用系统包括如下角色,不过,在具体设计时,可以根据具体情况来设计应用系统包括的角色。
超级管理员
高级管理员
中级管理员
普通管理员
数据库客户
11. 功能菜单清单配置
菜单的功能一般要划分清晰,尽量保证最底层菜单的功能单一,一般情况要包含如下内容:
版本(菜单在不同的版本中的可见性,或者说是可配置性)
使用功能的权限(菜单所对应功能的操作权限 )
菜单项 | 版本1 | … | 版本N | 权限 | 功能 | 接口 | |
角色1 | 角色N | ||||||
|
|
|
|
|
|
|
|
12. 数据字典的配置
数据字典是数据库应用系统开发中最重要的工具,也是其他系统开发的工具。数据字典,顾名思义,记录了系统开发中用到的所有数据,以及数据之间的关系。也是实现数据库中的关系、程序设计中的结构、记录类的继承层次的方法;是实现编程语言的机制。通常情况数据字典要记录如下信息:
12.1. 属性
属性,在关系数据库中称为属性,在C语言中称为数据成员或域,在面向对象语言中称为数据域的set、get标识。
12.2. 函数依赖
函数依赖是属性之间的联系,是实现模式规范化的依据;函数依赖在数据结构中表现为数据之间的关系,和关系数据库中的属性之间的联系是有区别的。
12.3. 表
在关系数据库中可以看作关系的名称,或者实体集的名称;在数据结构中,就是操作对象的数据项的组成结构。
12.4. 视图
视图是表的实现对用户的公开。
12.5. 存储过程
存储过程是表的实现对用户公开的又一种方法。
12.6. 处理逻辑和操作行为
形式化的描述操作行为处理对象的算法。
12.7. 事件
形式化的描述对象状态的改变所触发的验证规则以及处理内容。