数据库设计模式

A. 简述数据库应用系统的设计步骤

数据库设计的基本步骤：

1、系统需求分析与设计。

2、概念结构分析与设计。

3、逻辑结构分析与设计。

4、物理结构分析与设计。

5、系统实施。

6、系统维护。

(1)数据库设计模式扩展阅读：

数据库设计技巧：

1、原始文件与实体的关系

它可以是一对一，一对多，多对多的关系。一般来说，它们是一对一的关系：一个原始文档只对应于一个实体。在特殊情况下，它们可以是一对多或多对一关系，即一个原始文档对应于多个实体，或者多个原始文档对应于一个实体。

这里的实体可以理解为基本表。在对应关系明确后，对输入接口的设计非常有利。

2、主键和外键

一般来说，实体不能既没有主键也没有外键。在E－R图中，叶中的实体可以定义主键或不定义主键（因为它没有子代），但它必须有外键（因为它有父项）。

主键和外键的设计在全局数据库的设计中起着重要的作用。当全球数据库的设计完成后，一位美国数据库设计专家说：“钥匙无处不在，只有钥匙。”。这是他数据库设计的经验，也体现了他对信息系统核心（数据模型）高度抽象的理念。

因为：主键是一个高度抽象的实体。主键和外键的配对表示实体之间的连接。

3、基本表的属性

基本表不同于中间表和临时表，因为它具有以下四个特点：

原子性。基本表中的字段不可分解。

原始主义。基本表中的记录是原始数据（基本数据）的记录。

演绎的。所有输出数据都可以从基本表和代码表中的数据导出。

稳定。基本表的结构比较稳定，表中的记录要长期保存。

在了解基本表的性质之后，在设计数据库时，可以将基本表与中间表和临时表区分开来。

B. 数据库的三极模式结构及其优缺点是什么

数据库系统的三级模式结构是指数据库是由外模式、模式和内模式三级构成。
内模式也称存储模式，它是数据物理结构和存储结构的描述，是数据在数据库内部的表示方式。并且一个数据库只有一个内模式。
模式也称逻辑模式，是数据库中全体数据的逻辑结构和特征的描述，是所有用户的公共数据视图。它是数据库系统模式结构的中间层，不涉及数据的物理存储细节和硬件环境，与具体的应用，与所使用的开发工具及高级程序设计语言无关。
外模式也称子模式或用户模式，它是数据库用户（包括应用程序员和最终用户）看见和使用的局部数据的逻辑结构和特征的描述，是根据库用户的视图，是与某一应用有关的数据的逻辑表示。外模式是模式的子集，一个数据库可以有多个外模式。
有很多的优点。
数据库系统的三级模式的优点主要是由于这三级模式之间的独立性。
外模式和模式之间：由于外模式的用户只能看到和访问所对应的外模式数据，所以数据库中的其他数据对他们来说是不可见的，因此这样使数据具有访问权限，保证了数据的安全性和隐私性，对数据库的安全性也是一个重要保证。
内模式和模式之间：内模式描述数据的存储结构，模式描述数据的逻辑结构，两者各司其职，在设计模式时则不需要考虑数据如何存储，如何调用，提高了对数据库结构的设计效率。
由于特定的应用程序是在外模式描述的数据结构上编制的，它依赖于特定的外模式，与数据库的模式与存储结构独立。而数据库的二级映象功能保证了数据库外模式的稳定性，从而从底层保证了应用程序的稳定性。

C. 设计模式都有哪些

总体来说设计模式分为三大类：

一、创建型模式，共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。

二、结构型模式，共七种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。

三、行为型模式，共十一种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。

1、工厂方法模式：

定义一个用于创建对象的接口，让子类决定实例化哪一个类。Factory Method 使一个类的实例化延迟到其子类。

工厂模式有一个问题就是，类的创建依赖工厂类，也就是说，如果想要拓展程序，必须对工厂类进行修改，这违背了闭包原则，所以，从设计角度考虑，有一定的问题，这就用到工厂方法模式。

创建一个工厂接口和创建多个工厂实现类，这样一旦需要增加新的功能，直接增加新的工厂类就可以了，不需要修改之前的代码。

2、抽象工厂模式：

提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。抽象工厂需要创建一些列产品，着重点在于"创建哪些"产品上，也就是说，如果你开发，你的主要任务是划分不同差异的产品线，并且尽量保持每条产品线接口一致，从而可以从同一个抽象工厂继承。

3、单例模式：

单例对象（Singleton）是一种常用的设计模式。在Java应用中，单例对象能保证在一个JVM中，该对象只有一个实例存在。这样的模式有几个好处：

（1）某些类创建比较频繁，对于一些大型的对象，这是一笔很大的系统开销。

（2）省去了new操作符，降低了系统内存的使用频率，减轻GC压力。

（3）有些类如交易所的核心交易引擎，控制着交易流程，如果该类可以创建多个的话，系统完全乱了。（比如一个军队出现了多个司令员同时指挥，肯定会乱成一团），所以只有使用单例模式，才能保证核心交易服务器独立控制整个流程。

4、建造者模式：

将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。

5、原型模式：

原型模式虽然是创建型的模式，但是与工程模式没有关系，从名字即可看出，该模式的思想就是将一个对象作为原型，对其进行复制、克隆，产生一个和原对象类似的新对象。本小结会通过对象的复制，进行讲解。在Java中，复制对象是通过clone()实现的，先创建一个原型类。

6、适配器模式：

适配器模式将某个类的接口转换成客户端期望的另一个接口表示，目的是消除由于接口不匹配所造成的类的兼容性问题。主要分为三类：类的适配器模式、对象的适配器模式、接口的适配器模式。

7、装饰器模式：

顾名思义，装饰模式就是给一个对象增加一些新的功能，而且是动态的，要求装饰对象和被装饰对象实现同一个接口，装饰对象持有被装饰对象的实例。

8、代理模式：

代理模式就是多一个代理类出来，替原对象进行一些操作，比如我们在租房子的时候回去找中介，为什么呢？因为你对该地区房屋的信息掌握的不够全面，希望找一个更熟悉的人去帮你做，此处的代理就是这个意思。

9、外观模式：

外观模式是为了解决类与类之家的依赖关系的，像spring一样，可以将类和类之间的关系配置到配置文件中，而外观模式就是将他们的关系放在一个Facade类中，降低了类类之间的耦合度，该模式中没有涉及到接口。

10、桥接模式：

桥接模式就是把事物和其具体实现分开，使他们可以各自独立的变化。桥接的用意是：将抽象化与实现化解耦，使得二者可以独立变化，像我们常用的JDBC桥DriverManager一样。

JDBC进行连接数据库的时候，在各个数据库之间进行切换，基本不需要动太多的代码，甚至丝毫不用动，原因就是JDBC提供统一接口，每个数据库提供各自的实现，用一个叫做数据库驱动的程序来桥接就行了。

11、组合模式：

组合模式有时又叫部分-整体模式在处理类似树形结构的问题时比较方便。使用场景：将多个对象组合在一起进行操作，常用于表示树形结构中，例如二叉树，数等。

12、享元模式：

享元模式的主要目的是实现对象的共享，即共享池，当系统中对象多的时候可以减少内存的开销，通常与工厂模式一起使用。

13、策略模式：

策略模式定义了一系列算法，并将每个算法封装起来，使其可以相互替换，且算法的变化不会影响到使用算法的客户。需要设计一个接口，为一系列实现类提供统一的方法，多个实现类实现该接口，设计一个抽象类（可有可无，属于辅助类），提供辅助函数。

14、模板方法模式：

一个抽象类中，有一个主方法，再定义1...n个方法，可以是抽象的，也可以是实际的方法，定义一个类，继承该抽象类，重写抽象方法，通过调用抽象类，实现对子类的调用。

15、观察者模式：

观察者模式很好理解，类似于邮件订阅和RSS订阅，当我们浏览一些博客或wiki时，经常会看到RSS图标，就这的意思是，当你订阅了该文章，如果后续有更新，会及时通知你。

其实，简单来讲就一句话：当一个对象变化时，其它依赖该对象的对象都会收到通知，并且随着变化！对象之间是一种一对多的关系。

16、迭代子模式：

顾名思义，迭代器模式就是顺序访问聚集中的对象，一般来说，集合中非常常见，如果对集合类比较熟悉的话，理解本模式会十分轻松。这句话包含两层意思：一是需要遍历的对象，即聚集对象，二是迭代器对象，用于对聚集对象进行遍历访问。

17、责任链模式：

责任链模式，有多个对象，每个对象持有对下一个对象的引用，这样就会形成一条链，请求在这条链上传递，直到某一对象决定处理该请求。但是发出者并不清楚到底最终那个对象会处理该请求，所以，责任链模式可以实现，在隐瞒客户端的情况下，对系统进行动态的调整。

18、命令模式：

命令模式的目的就是达到命令的发出者和执行者之间解耦，实现请求和执行分开。

19、备忘录模式：

主要目的是保存一个对象的某个状态，以便在适当的时候恢复对象，个人觉得叫备份模式更形象些，通俗的讲下：假设有原始类A，A中有各种属性，A可以决定需要备份的属性，备忘录类B是用来存储A的一些内部状态，类C呢，就是一个用来存储备忘录的，且只能存储，不能修改等操作。

20、状态模式：

状态模式在日常开发中用的挺多的，尤其是做网站的时候，我们有时希望根据对象的某一属性，区别开他们的一些功能，比如说简单的权限控制等。

21、访问者模式：

访问者模式把数据结构和作用于结构上的操作解耦合，使得操作集合可相对自由地演化。访问者模式适用于数据结构相对稳定算法又易变化的系统。因为访问者模式使得算法操作增加变得容易。

若系统数据结构对象易于变化，经常有新的数据对象增加进来，则不适合使用访问者模式。访问者模式的优点是增加操作很容易，因为增加操作意味着增加新的访问者。访问者模式将有关行为集中到一个访问者对象中，其改变不影响系统数据结构。其缺点就是增加新的数据结构很困难。

22、中介者模式：

中介者模式也是用来降低类类之间的耦合的，因为如果类类之间有依赖关系的话，不利于功能的拓展和维护，因为只要修改一个对象，其它关联的对象都得进行修改。

如果使用中介者模式，只需关心和Mediator类的关系，具体类类之间的关系及调度交给Mediator就行，这有点像spring容器的作用。

23、解释器模式：

解释器模式一般主要应用在OOP开发中的编译器的开发中，所以适用面比较窄。

(3)数据库设计模式扩展阅读：

介绍三本关于设计模式的书：

1、《设计模式：可复用面向对象软件的基础》

作者：[美] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides

出版社： 机械工业出版社

2、《软件秘笈：设计模式那点事》

作者：郑阿奇

出版社：电子工业出版社

3、《设计模式：基于C#的工程化实现及扩展》

作者：王翔

出版社：电子工业出版社

D. 微信朋友圈数据库模式如何设计的

其实微信朋友圈的数据库设计模式无非就是符合了三种设置模式，其中最常用的是第三种。
第一范式（1NF）
在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。
所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。在第一范式（1NF）中表的每一行只包含一个实例的信息。例如，对于图3-2 中的员工信息表，不能将员工信息都放在一列中显示，也不能将其中的两列或多列在一列中显示；员工信息表的每一行只表示一个员工的信息，一个员工的信息在表中只出现一次。简而言之，第一范式就是无重复的列。
第二范式（2NF）
第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。第二范式（2NF）要求数据库表中的每个实例或行必须可以被惟一地区分。为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。如图3-2 员工信息表中加上了员工编号（emp_id）列，因为每个员工的员工编号是惟一的，因此每个员工可以被惟一区分。这个惟一属性列被称为主关键字或主键、主码。
第二范式（2NF）要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。简而言之，第二范式就是非主属性非部分依赖于主关键字。
第三范式（3NF）
满足第三范式（3NF）必须先满足第二范式（2NF）。简而言之，第三范式（3NF）要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。例如，存在一个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。那么在图3-2的员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表，则根据第三范式（3NF）也应该构建它，否则就会有大量的数据冗余。简而言之，第三范式就是属性不依赖于其它非主属性。

E. 文档型数据库设计模式：如何存储树形数据

在数据库中存储树形结构的数据，这是一个非常普遍的需求，典型的比如论坛系统的版块关系。在传统的关系型数据库中，就已经产生了各种解决方案。 此文以存储树形结构数据为需求，分别描述了利用关系型数据库和文档型数据库作为存储的几种设计模式。 A.关系型数据库设计模式1idnameparent_id1ANULL2B13C14D2 上图表示了传统的设计方法之一，就是将树形结构的每一个结点作为关系型数据库中的一行进行存储，每一个结点保存一个其父结点的指针。 优点：结构简单易懂，插入修改操作都很简单 缺点：如果要获取某个结点的所有子结点，将是一件很恶心的事 B.关系型数据库设计模式2idnameparent_ 上图在模式1的基础上多了两列，left和right，相当于btree中的左右分支，分别存储了左右分支结点的最大值和最小值。 优点：要查找一个结点的子结点很容易，只需要做一个范围查询就行了(比如B节点的子结点，只需要查询 id >=2 && id<=5) 缺点：由于树结构存在在这里面了，所以添加或修改已存在结点将可能产生连锁反应，操作过于复杂 C.文档型数据库设计模式1 { "name": "A", "children": [ {"name": "B", "children": [{"name": "D"}]}, {"name": "C"}]} 将整个树结构存成一个文档，文档结构既树型结构，简明易懂。

F. 数据库设计中反映用户对数据要求的模式是 A.外模式 B.内模式 C.概念模式 D.设计模式

概念模式，选c，是由数据库设计者综合所有用户的数据，按照统一的观点构造的全局逻辑结构，是对数据库中全部数据的逻辑结构和构造特征的总体描述，是所有用户的公共数据视图，它是由数据库管理系统提供的数据模式描述语言来描述的，

G. 数据库设计过程中的各级模式是哪些

设计步骤：
The process of designing the general structure of the database:
1.User requirements(用户需求分析):is the initial phase of database design to characterize fully the data needs of the prospective database users.
2.conceptual-design（概念设计） :provides a detailed overview of the enterprise
3.Logical-design（逻辑设计）:maps the high-level conceptual schema into the implementation data model of the database system that will be used
4.Functional requirements（分析功能需求）:users describe the kinds of operations that will be performed on the data(modifying,updating ,searching,retrieving,deleting)
5.Physical-design（结构设计，物理设计）:specify internal storage structures.

设计模式：
Database systems have several schemas,partitioned according to the levels of abstraction.
Physical schema: database design at the physical level 物理模式：物理水平的设计方式
Logical schema: database design at the logical level 逻辑模式：逻辑水平的设计方式
Subschema:database design at the view level 子模式：描述数据库的不同视图

以上参考的是Database system concepts（数据库系统概念），Abraham Silberschatz(美)着，高等教育出版社，2006，6
不知道你是不是需要这个

H. 支持多种数据库的操作类采用什么设计模式

可以用策略模式来设计，不同的数据库使用不同的策略类

I. 查询数据库用什么设计模式好

观察者模式和工厂模式太有点学究气息了.实际看你的问题并不是查询的问题,而属于信息处理的运用问题.我们简化说:
信息属于按照时间堆积量.仅就查询而言,在前最后一次查询到现在出新的就是新数据.
查询出来的新数据按照信息关联分类是非常重要的,通常不需要添加到新表中,只需要按照信息分类标定即可;新数据标定和时间决定的.
专门有程序来按照分类新数据进行处理,这个程序可以由分类程序结束后启动.
只是建议,能否满足你的要求呢?

J. 采用什么设计模式来应对数据库软件的不确定性

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

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

一、数据库和信息系统
(1)数据库是信息系统的核心和基础，把信息系统中大量的数据按一定的模型组织起来，提供存储、维护、检索数据的
功能，使信息系统可以方便、及时、准确地从数据库中获得所需的信息。
(2)数据库是信息系统的各个部分能否紧密地结合在一起以及如何结合的关键所在。
(3)数据库设计是信息系统开发和建设的重要组成部分。
(4)数据库设计人员应该具备的技术和知识：
数据库的基本知识和数据库设计技术
计算机科学的基础知识和程序设计的方法和技巧
软件工程的原理和方法
应用领域的知识

二、数据库设计的特点
数据库建设是硬件、软件和干件的结合
三分技术，七分管理，十二分基础数据
技术与管理的界面称之为“干件”
数据库设计应该与应用系统设计相结合
结构（数据）设计：设计数据库框架或数据库结构
行为（处理）设计：设计应用程序、事务处理等
结构和行为分离的设计
传统的软件工程忽视对应用中数据语义的分析和抽象，只要有可能就尽量推迟数据结构设计的决策早期的数据库设计致力于数据模型和建模方法研究，忽视了对行为的设计
如图：

三、数据库设计方法简述
手工试凑法
设计质量与设计人员的经验和水平有直接关系
缺乏科学理论和工程方法的支持，工程的质量难以保证
数据库运行一段时间后常常又不同程度地发现各种问题，增加了维护代价
规范设计法
手工设计方
基本思想
过程迭代和逐步求精
规范设计法(续)
典型方法：
(1)新奥尔良（New Orleans）方法：将数据库设计分为四个阶段
S.B.Yao方法：将数据库设计分为五个步骤
I.R.Palmer方法：把数据库设计当成一步接一步的过程
(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) 检查设计
在开发期间检查数据库设计的常用技术是通过其所支持的应用程序原型检查数据库。换句话说，针对每一种最终表达数据的原型应用，保证你检查了数据模型并且查看如何取出数据。