数据库设计系列1--事实发现

在数据库系统开发周期的各个阶段中，数据库开发者必须捕获必要的事实来构建数据库系统，这些事实覆盖业务和数据库系统用户，主要包括术语，问题，机会，约束，需求和优先权，这些构成了事实发现的目标。

事实发现就是运用面谈和提问等技术来收集有关系统，需求和用户喜好的形式化处理过程。

使用事实发现技术的时机：在数据库开发生命周期的早期阶段，包括数据库规划、系统定义、需求收集和分析，开发人员要了解术语，问题，机会，约束，需求以及业务和系统用户的优先级。

注意事项：大概估计一下要在数据库工程的事实发现上花费多少时间和精力是非常重要的。大量的快速学习将导致瘫痪，而考虑的太少则会由于用错误的方法解决错误的问题而导致不必要的时间和金钱的浪费。

在整个数据库系统的周期中，开发人员需要捕获的事实包括系统当前的或者将来的事实。数据库开发的各个阶段并不是严格按照顺序进行的，而是通过反馈循环包括许多前阶段的重复，这也适用于各个阶段的数据采集和文档产生。

数据库开发人员在一个数据库工程中通常使用几种事实发现技术，常用的技术有五种：检查文档、面谈、观察操作中的业务、研究、问卷报告。

1． 检查文档：当你需要深入了解为什么客户需要数据库应用时,检查文档是非常有用的，检查文档可以发现文档有助于提供与问题相关的业务信息。如果问题与现存系统相关，则一定有与该系统相关的文档。检查与目前系统相关的文档，表格，报告和文件是一种非常好的快速理解系统得方法。

检查当前的文档可以有如下的用途：

a) 描述数据库的问题和需求。有用途的资源包括内部备忘录、电子邮件、会议备忘录、员工客户意见、问题描述文档。

b) 描述受问题影响的业务。有用途的资源包括组织图表、任务陈述、事务战略计划，正被研究的部分任务目标、手工的表格和报告的例子、计算表格和报告举例、完成的表格/报表。

c) 描述当前系统。有用的资源包括不同类型的数据流图和图表，数据字典，数据库应用程序设计、程序文档、用户/培训手册。

2. 面谈

面谈是最常用的，通常也是最有用的事实发现技术，通过面对面谈话可以获取信息，面谈还有其他的目的，如找出事实、确认事实、澄清事实、得到最终用户、标识需求、集中意见和观点。然而使用面谈这种技术需要良好的交流能力，能够有效地和具有不同价值观、不同喜好、观点、动机和个性的人打交道。和其他技术一样，面谈并不是在所有情况下都是最好的，优点如下表所示：

• 谈话对象可以按照谈话人预先确定的感兴趣的内容进行交谈
• 谈话人可以在谈话过程中改编或者重述问题
• 谈话人可以观察谈话对象的肢体语言
• 谈话对象可以自由的、开放地回答问题
• 谈话对象可以了解部分项目

缺点如下所示：

• 非常浪费时间，代价昂贵，可能不切实际
• 是否成功依赖于谈话人的交流技巧

有两种类型的面谈：有组织的和没有组织的。没有组织的面谈通常仅由一个通用的目标指导，并且有非常少的特定问题。谈话人依靠谈话对象提供谈话的框架和方向，这种类型的谈话通常不能抓住问题的焦点，因此，你将发现他不是很适用于数据库分析和设计。有组织的谈话中，谈话人有特定的问题要问谈话对象。根据谈话对象的回答，谈话者将提出一些附加的问题以获得非常明确的答案并进行一些扩展。没有明确框架限制的问题能够让谈话对象用一种看起来适合的方式回答。例如：“为什么你对成员注册报表不满意”，限制框架问题的答案要么是特定的选择，要么是短的直接的回答。例如“你是否按时收到了乘员注册报告”或者成员注册报告所包含的信息是否精确”，这个问题只需要回答“是”或者“否”。

重要提示：为了保证谈话成功，必须选择合适的谈话人选，准备的问题涉及面要广，要引导谈话有效地进行。

3.观察业务的运转。

观察是用来理解一个系统的最有效的事实发现技术之一，使用这项技术可以参与或者观察做事的人来了解系统，当用其他方法收集的数据的有效性值得怀疑或者系统特定方面的复杂性阻碍了最终用户作出清晰的解释时，这种技术尤其有用。

与其他的事实发现技术相比，成功地观察要求非常多的准备。为了确保成功，要尽可能多地了解你要观察的人和活动。例如，所观察的活动的低谷，正常以及高峰期拥分别是什么时候？所观察的人是否会因为有人观察他们并记录他们的活动而心情烦乱。

使用这种技术的优点：

可以检查数据和实施的有效性，观察者可以很准确地看到正在做的事情，观察者也可以获得描述任务的物理环境的数据，相对低廉，观察者可以坐工作测量。

缺点：

当有人观察时人们可能自觉或者不自觉的行为异常，在那段时间，可能会遗漏一些观察任务，这些任务的难度和量都有所不同，有些任务并不总是以他们被观察时的方式运行，可能不切实际。

4.研究。

研究主要是研究应用和问题，计算机行业的杂志、参考书和因特网是非常好的信息来源，他们可以提供有关他人如何解决该问题的信息，也可以告诉你要解决此问题的软件包是否存在。

优点：

如果解决问题的方法已经存在则能够节省时间、研究者可以知道其他人如何解决相似的问题或者怎样满足相似的要求、使研究者能够跟上最新发展。

缺点：

可能很浪费时间、需要获得合适的信息资源、由于问题在其他地方没有写成文档，因此最终可能对解决问题没有什么帮助。

5.问卷调查

问卷是一种有着特定目的的小册子，这样可以在控制答案的同时，集中一大群人的意见。当和大批听众打交道时，其他的事实发现技术都不能有效地把这些事实列成表格。问卷有两种格式，自由形式和固定形式，在自由格式问卷上，答卷人提供的答案有更大的自由，问卷提出后，答卷人在题目后的空白地方写答案。固定格式问卷包含的问题的答案是特定的，给定一个问题，回答着必须从提供的答案中选择一个，因此结果一目了然且容易列表。但另一方面，答卷人不能提供一些有用的附加信息。问卷的优缺点如下所示：

优点：

被调查者可以很方便地回答问卷并交还、相对廉价的从大批人群中收集数据、当调查对象的回答可信度高时，他们提供了真实的情况，回答可以列成表格并迅速分析，可以使用各种方式发放问卷，包括人工发放，邮件，发E_mail。
缺点：

交还率可能很低，可能只有5%-10%，问卷交还是可能没有回答完整。没有机会修改和重新描述被误解的问题，不能观察和分析答卷人的肢体语言。主碑问卷非常浪费时间

数据库设计系列2---事实发现详细介绍--数据库规划

开发数据库应用的第一个步骤是清楚的定义数据库工程的任务陈述，这个任务陈述定义了数据库应用程序的主要目标。任务陈述可以帮助澄清数据库工程的目标，为开发出一个简洁高效的数据库应用程序提供更清楚的途径。定义好任务陈述之后，下一个活动包括确定任务目标，每个任务目标应该标识一个数据库必须支持的特定任务。前提是数据库支持的任务目标在任务陈述中必须有定义。任务陈述和目标可能伴随着许多额外的信息，这些信息通常制定了要完成的工作，完成工作所要使用的资源以及所要支付的金钱。

比如一个StayHome数据库应用系统的任务陈述如下所示：

StayHome的数据库系统的目的是收集、存储和控制公司产生的数据，支持面向会员的录像出租业务，方便分公司之间的合作和信息共享。

创建StayHome 数据库系统的任务目标：创建任务目标的过程包括与员工中的合适人选进行的引导性谈话，自由提问通常在这个阶段中是最有用的，为了获得完整的任务目标，应该与StayHome中不同角色的人员交流。可以问得典型的问题如下：

1. 请描述你的工作
2. 通常在一天中你要做什么工作
3. 你会和什么数据打交道
4. 你要明白哪些事情
5. 公司给你的会员提供哪些服务

这些问题可以问公司的主管或者经理、监理、助理和采购员。当然随着采访用户的不同有必要调整问题。 例如可以询问以下的问题：

请问你在公司做哪些事情？
你每天要处理什么事情？
你处理哪些数据?
你需要使用哪种类型的报表？
哪些类型的事务你需要很明白？
公司为会员提供哪些服务？

你能描述一下你的工作吗？
典型地，你每天要处理什么工作？
你使用哪些报表？
你需要清楚了解哪些事情？

请介绍一下你的工作？
你每天的日常工作是什么？
你处理哪些类型的数据？
你使用哪些报告？
你需要明确哪些事情？

所有这些工作完成之后可能得到一个任务描述如下：

数据库规划产生的文档应该记录备案，下一步，根据数据库的规划来进行需求的收集和分析。

数据库设计系列3---事实发现详细介绍--需求收集和分析

在这个阶段，开发人员应该继续收集前面阶段所标示的用户视图的更多细节，产生用户的需求说明。用户的需求说明详细描述了数据库中应该包含的数据以及数据的使用方式。在收集更多的用户视图相关的数据的同时，也应该努力收集系统的一般需求，收集信息的目的是产生系统的需求说明。系统需求描述了在新的数据库应用中所要包含的各种特性，如网络需求，共享访问需求，效率需求以及安全级别需求。

在收集用户视图需求的数据和整个系统需求的数据时，开发人员将会了解当前系统的运行方式。当然，我们正在建立一个新的系统，在给新的系统引进新的优良特性的同时还应该尽量保留老系统的好的方面。与此阶段相关的一个非常重要的活动是怎样处理有多个视图的情况。

1. 收集数据库系统的用户视图的更多的情况。

a) 为了找到每个用户视图的更多的需求信息，可以再次使用事实发现技术，如面谈和观察业务运转，使用以下的问题类型来了解一个用户视图所需要的数据。

i. 在**中，你要包含哪些类型的数据？
ii. 你要对**作哪些操作？

可以针对数据库中要存储的所有数据问类似的问题，这些问题的回答有助于确定用户需求定义中的必要细节。

2. 收集数据库系统的系统需求信息

a) 在获取数据库视图需求的同时，还应该收集关于系统需求的更一般的信息，可以问以下的问题：

i. 数据库中经常要进行什么操作？
ii. 什么事务对这种业务操作时非常关键的？
iii. 什么时候运行严格的事务？
iv. 他们运行的高峰期，正常期和低谷期各是什么？
v. 数据库系统需要那种类型的安全机制？
vi. 是否存在只能由某些成员使用的敏感数据？
vii. 要保存那些历史数据？
viii. 对数据库系统的网络和共享访问有哪些需求？

3. 设计系统的用户视图

a) 从以上的分析中可以得知用户对那种实体的视图有需求，可以使用视图集中式方法和视图集成方法来设计用户的视图。使用视图集中式方法把具有类似视图需求的用户视图合并起来作为一种视图并且命名。开发各自的用户视图模型，之后再使用视图集成的方式把视图模型合并起来。列出一个主要数据类型的用户视图的交叉引用表是比较方便的，究竟使用视图集中式方法还是使用视图集城式方式没有一个准确的区分规则，作为数据库开发人员，应该根据对数据库系统的复杂性的估计和不同视图的数据重叠程度来作决定。

4. 创建各个用户视图的用户需求定义

a) 用户需求定义作为两部分列出：第一部分描述用户视图使用的数据，第二部分提供数据怎样被用户视图使用，即在数据上执行的事务

i. 数据需求：数据需求描述了每个事务需要的几本院是的数据，按照从整体到局部，从大到小顺序依次执行。比如一个公司的数据包括地址，街道，城市，邮编，每个公司都有员工，包括一个经理，助理等。并且介绍他们之间的基本关系和属性。
ii. 事务需求：主要的数据需求包括数据录入需求，比如录入一个公司的详细情况，录入新员工的详细情况；数据更新/删除，更新/删除分公司的信息，更新/删除给定员工的信息等，数据查询，也就是数据库必须要支持的事务，如：列出给定公司的所有员工，

5. 创建数据库系统的系统说明

a) 系统说明应该列出该数据库系统的所有的重要特点，应该在系统说明中描述的特点如下

i. 初始数据库的大小：主要说明说据库在初始的时候存储那些数据大约多少记录，如大约有50个录像供应商和1000盘录像订单。
ii. 数据库的增长速度：描述每个周期(月或者天)将会出现多少数据如：每月大约有100部新片，每部录像有20份拷贝添加到数据库中。
iii. 记录查找的类型和平均数量：描述所有查询操作的可能次数，比如：查询分公司的详细情况—大约每天10次
iv. 网络和共享访问需求：描述访问的兵法频率，比如：系统必须能够支持每个分公司的至少三名成员同时访问。
v. 性能：在高峰期和非高峰期数据库应用系统的相应时间，比如保存，查询等在规定的时间内。
vi. 安全性：数据库的访问权限和不同用户的访问权限。
vii. 备份和法律问题：每个国家都有管理个人数据的计算机存储方式，数据库应用系统应该调查并且实现所要遵守的法律。

数据库应用的初始需求基本完成了，剩下的就是把这些成果拿回去进行分析，并进行下一步的逻辑数据库设计了。

数据库设计系列4---实体建模

一旦完成了数据库系统生命周期中的需求收集和分析阶段的工作，并且把数据库需求整理成了文档，就可以开始进行数据库设计了。数据库设计中最困难的一个方面就是设计人员，程序员和最终用户看待和使用数据的方式不同，除非能够获得反映公司运行的共性的理解，否则，设计将达不到用户的要求。为了能够让设计人员，程序员和最终用户准确理解数据的本质，理解公司使用这些数据的方法，需要有一个通信模型，这个模型和技术无关，并且没有二义性，ER（Entity-RelationShip实体-关系）模型就是这样的例子。ER建模示一种自上而下的数据库设计方法，通过标示模型中必须要表示的重要数据（实体）以及数据间的关系开始建立ER模型，然后增加细节，如实体关系索要具有的信息（属性），以及实体，关系和属性上的限制。首先介绍一些概念：

1. 实体（ENTITY）一组有相同属性的对象，被用户或者团体标识为独立存在的对象的集合。ER模型的一个基本概念就是实体，代表一组现实世界中的对象集合，他们有相同的属性，每个对象必须在一个集合众被唯一地标示，叫做实体事件。一个实体事独立存在的，代表一组物理存在（现实如员工）或者概念存在（抽象如经理角色）的对象的集合。使用一个唯一的名字和一些特征（属性）来标示每个实体，虽然一个实体有不同的属性集合，但是每个实体对每个属性都有自己的值，实体使用矩形表示，矩形框上写入实体的名字。

2. 关系：实体之间的具有某种含义的关联。一个关系是特定实体之间的一组关联，和实体一样，每个关系在集合中也要被唯一的标识，一个可以唯一标示的关联叫做关系事件。每一个关系有一个名字，此名字描述关系的功能，如角色经理与实体员工之间通过manages关联，一个关系仅在一个方向上标示，代表一个关系仅在一个方向上起作用，因此一旦选择了关系名，必须在名字旁边加箭头指示正确的方向。

a) 关系的度：包含子特定关系中的实体叫做参与者，在关系中参与者的数目叫做关系的度，指明了参与在一个关系中的实体的数目，度数为1的关系成为一元关系，通常被称为递归关系，度数为2的关系叫做二元关系，度数超过2的关系叫做复杂关系，度数为3的关系叫做3元关系，一次类推，经常遇到的关系为二元关系，偶尔会遇到3元关系和四元关系。

b) 递归关系：一元关系，在不同的角色中有多次具有相同实体参与的关系。 例如经理管理员工关系，

在这里，工头也是员工中的一员，换句话说，员工实体参与管理 关系两次，第一次作为工头参与，第二次作为一个民工参与。可以给关系一个角色名字以表明每个参与的实体在关系中所起的作用，角色名字对于递归关系决定参与实体的作用是非常重要的。

1. 属性：实体或者关系的性质，实体的性质叫做属性，属性代表我们需要知道的有关实体的内容。

a) 简单属性和符合属性

i. 简单属性，仅由单个元素组成的属性，简单属性是不能在分的属性，如邮政编码。
ii. 符合属性：由多个元素组成的属性，比如姓名，由姓和名两个元素组成

把姓名属性建模成简单属性还是分解成姓和名的符合属性，取决于访问姓名属性的方式，作为一个整体还是单个组成元素访问。

b) 单值属性和多值属性

i. 单值属性：对于一个实体只有一个值得属性，比如姓名
ii. 多值属性，对于一个实体可以有多个值的属性，比如一个公司有多个电话号码。

简单属性和复合属性侧重于属性的种类，单值属性和多值属性侧重于属性的个数，两者不互相排斥。

C）派生属性，属性质代表一个从相关属性或者属性集派生的值，再相同实体中不时必须的值。比如一个人的年龄可以从出生年月导出来，因此年龄和出生年月是相关联的，年龄通常不存储在数据库中。某些情况下，属性从其他多个属性中导出。

D）键的概念

超键：可以唯一标识一个实体的属性或者属性组。
候选键：可以唯一标识一个实体的具有最小属性数目的超键。
主键：被选中作为标示实体的候选键。
备用键：没有被选中作为实体的候选键。

属性的图形化表示：

实体使用矩形表示，如果知道了主键，主键应该被首先列出来，后面使用{pk}表示，如果是被选键使用{AK}表示，如果是派生属性，使用/age加以标示，如果知道基数，使用[1..10]的方式列出来。

通过以上的描述，我们可以把实体分为强实体和弱实体，强实体：不依赖于另一个实体的实体，换句话说：也就是有自己的主键，并自主键中的任何一个属性不是外键。相对的，弱实体是主键的部分或者全部依赖于其他一个或者多个实体的主键而存在的实体，主键的部分或者全部为外键的实体成为弱实体，强实体有时候被叫做父实体，拥有者或者统治实体，弱实体则相应被叫做子实体，依赖实体或者从属实体。

数据库设计系列5---关系建模

标示了数据库系统的实体之后，下一步骤就是标示实体之间的关系，以及存在于关系之上的约束。这种约束的例子包括：一个分公司必须有多名会员，每个分公司都必须有员工，关系上的约束类型称为多样性。多样性的定义为：一个实体中可能和相关实体的一个存在关联的实体事件的数目。

最常用的关系是度为2的二元关系，二元关系上的多样性约束一般分为一对一，一对多，多对多三种。使用以下的业务规则来考查这三种类型的关系，一名员工管理一个分公司，一个分公司有许多员工，演员出演某部影片。对于每个业务规则，我们说明在没有明确制定的情况下找到其中的多样性约束，并说明怎样在ER模型中表示他们。

1. 一对一关系是最常见的关系，比如一名员工管理一个分公司，但是并不是所有的员工都有分公司可以管理，如下图表示：

一个员工管理一个单位，找出多样性通常需要用样例数据检查特定事务规则的数据之间的关系，可以从填好的表格，报表甚至从与用户的讨论中得到样例数据。为了得出正确的结论，强调被检查和讨论的样例数据能够真实地代表所有数据是非常重要的。

为了图形化表示1:1关系的，在关系的两端放上，0..1或者1..1表示他们之间的描述关系，为了表示一个员工管理0到1个公司，在Branch的一端放上0..1的字样，为了表示一个分公司必须由一个员工管理，在Staff的一端放上1..1，在上图中左边的 表示0..1，同时也表示是可选参与，即当Staff的一个实体确定时，他所管理的分公司可以有，或者没有。而在右边的 表示当一个Branch确定的时候，必须有一个Staff员工来进行管理，即参与。

2.一对多关系也比较常见，比如一个公司有多名员工的情况就属于一对多的关系。

了表示Branch Has Staff，我们在实体Staff的一端标记1..*，表示一个公司1到多多名员工，而一个员工只属于一个分公司，在上图中， 表示1..*,如果知道多样性约束的最大值和最小值，则可以显示这些信息，例如一个分公司有2-10个员工，可以标记2..20。

1. 多对多约束，角色和拥有的权限之间的关系是一个典型的多对多关系，一个角色可以拥有多个权限，一个权限可以被分配到不同的角色中。使用UML图形的表示如下图所示：

为了图形化表示多对多的关系，在互相关联的实体分别标记0..*，如上图中的 所示，

1. 复杂关系的多样性约束。一般来说，n元关系的多样性约束代表关系中其他n-1元关系固定的情况下某个实体潜在的实体事件的数目，

以上所描述的约束中，如果其他n-1元关系确定的情况下，某个实体的参与个数如果大于等一，则为强制参与，否则为可选参与，在一个关系中参与的实体的数目，成为关系的基数。

2. 关系中相关的性质称为关系上的属性，比如在课程和学生之间存在多对多的关系，在多对多的关系中存在分数这个属性，学生对应的某个课程有考试成绩。

ER模型中的设计问题：

在ER模型中可能存在如下的两种陷阱，扇形陷阱和深坑陷阱。

扇形陷阱：从第三个实体与扇出的两个实体之间有1..*的关系，但是扇出的两个实体之间应该有直接关系以提供必要的关系，实际却没有，其形状如下图所示：

如一个工头负责多个工程，同时也管理多个民工，他们都是一对多的关系，民工和工程之间应该有直接的关系表明某个民工在某个工程上工作，但是却没有明确的说明。解决的办法是在工程和民工之间添加一个关系，表示民工在那个工地上工作。

深坑陷阱：一个模型，假设他们之间存在关系，但是这些实体之间不存在路径。深坑陷阱存在的地方是存在可选参与的关系组成了相关实体之间的路径，例如一个公司分配了若各个汽车，部分员工可以使用汽车，这样就有了如下的关系

由于并不是所有的员工都是用汽车，根据这个模型并不能看出来公司拥有多少员工，或者员工属于哪个公司。解决办法是在公司和员工之间添加一个关系，表明公司和员工之间的关系。

扇形陷阱和深坑陷阱之间的区别不是很好理解，在实际的设计中也很少出现此类陷阱。大致有个了解就可以了，不需要深究。

数据库设计系列6---规范化

在前面的部分，我们学习了ER建模方法，一种泛化的自上而下的数据库设计方法，在这一节，我们学习另外的一种泛化的数据库设计的方法，叫做规范化。在数据库设计中，规范化可以有两种使用方法，第一种是把规范化用作自下而上的数据库设计方法，第二种是把规范化方法与ER建模结合起来使用，把规范化作为自下而上的方法包括分析属性之间的关联，基于这个分析，把属性结合在一起形成代表实体和关系的表，然而在属性很多的时候，使用这种方法很难奏效， 因为很难建立属性之间的所有重要的关联。由于这些原因，建议应该使用自上而下的数据库设计方法，先理解数据，我们使用ER建模技术创建代表主要实体和关系的数据模型，然后把ER模型翻译成代表数据的一组表。在这一点我们使用规范化方法检查表的设计是否良好。

规范化是一种用来产生表的集合的技术，这些表具有符合要求的属性，并能支持用户或公司的需求，规范化通常作为对表结构的一系列测试来决定它是否满足或者符合给定范式。存在几种范式形式，但是最常用的是第一范式，第二范式和第三范式。所有这些范式都是基于在表中的列之间的关系的。在以下的内容中，我们首先指出引起数据冗余的错误的结构化表是怎样导致问题的出现的，这些问题叫做更新异常，错误的结构化表可能产生于原始ER模型或者在将ER模型转化成表时出现的错误，然后给出第一范式，第二范式和第三范式的定义，并解释每个范式是怎样用来确定和更正表中的不同类型的问题的。

数据异常和更新异常，关系数据库设计的一个主要目的是把列组合成表使数据的冗余最小，并减少实现基表所需要的文件存储空间，例如有以下的表的定义StaffBranch（StaffNo,name,position,salary,branchNo,branchAddress,telNo）
在StaffBranch表中有冗余数据，因为分公司的细节信息在分公司的每个员工那里被重复了一遍，如果删除所有员工的信息，那么也就没有了分公司的信息。这样就会导致删除异常，如果更新了一个员工所在的分公司的信息，那么员工所在的分公司信息就会不一致，这样就会导致更改异常，如果分公司的新员工尚不存在，插入新员工时就会导致插入异常，所有这些异常统称为更改异常。

如果把StaffBranch表拆分为两个表，Staff和Branch表Staff（StaffNo,name,position,salary）,branch(branchNo,branchAddress,telNo)则他们不会出现以上所示的异常，他们符合一定的范式，下面介绍一下范式的概念。

第一范式：记录的每个列包含一个而且只包含一个值的表，或者说数据项是不可拆分的表，如果一个记录的某一个列有多个值，那么就不是1NF，比如一个电话号码列包含了110,120，119多个电话号码。

第二范式：一个第一范式的表并且任何一个非主属性都完全依赖于主键的表。部分依赖是指一个非主属性可以从主键的部分属性或者部分属性的组合中得到。完全功能依赖是指如任何一个非主属性都必须由主键的全部属性组合中得到。

第三范式：一个已经是第一和第二范式的表，并且所有的非主键列的值只能从主键中得到，而不能从其他的途径得到。也就是说消除了传递依赖。任何一个非主键属性都不传递依赖于主键。

在数据库设计中经常遇到的范式就是第三范式，经过多年的发展不仅有BCNF,第四范式，同时也有了第五范式，他们都在不同程度上解决了一定的数据冗余问题。对于一般的数据库应用，第三范式已经足够使用，因此不需要赘述。有兴趣的读者可以到baidu上搜索以下，在此不多作介绍。

数据库设计系列7—数据库设计过程概览

如果所需要的数据库变得相当复杂，就需要有一种系统化的方法去设计和构建数据库，使数据库既能满足用户需求又能获得性能需求，这种系统化的方法就是数据库设计方法学。设计方法学是一种使用过程，技巧，工具和文档来支持和简化设计过程的结构化方法。数据库设计方法学由一些列步骤组成，这些步骤在工程的每个阶段引导设计这使用合适的技术，这些阶段还帮助设计这规划、管理、控制和评价数据库开发过程。此外，这个方法是一个结构化的方法，用于以标准化的和有组织的方式分析和建立数据库需求模型。

有些设计方法学将数据库设计分成两个主要的阶段，逻辑数据库设计和物力数据库设计。逻辑数据库设计主要是指按照特定的数据模型，构建企业所使用的数据的模型的过程，但独立于特定的DBMS和其他的物理考虑事项。物理数据库设计指在耳际存储上的数据库的实现的描述，他描述基本表、文件组织、用户高效访问数据的索引和相关的完整性约束及安全性限制。

在数据库设计中关键的成功因素主要包括：

1. 尽可能多地与用户进行交流。
2. 在整个数据建模过程中使用一种结构化的方法学
3. 使用数据驱动的方法。
4. 在数据模型中加入结构化和完整性考虑
5. 将规范化和事务有效性技术结合进方法学中。
6. 尽可能多地使用图去表示数据模型。
7. 使用数据库设计语言。
8. 构建数据字典补充数据模型图。
9. 乐于重复以上步骤。

逻辑数据库设计主要分为以下两个主要步骤：

在步骤1中，我们创建一个ER模型并检查这个模型是否有最小冗余，是否可以支持用户事务，这个步骤的输出是一个ER模型，这个模型完全并准确地表达企业对数据的需求。

在步骤2种我们将ＥＲ模型影射为表的集合，对每个表的结构都使用规范化来检查，规范化能够确保表在结构上是一致的、逻辑的并且有最小冗余，对标也进行检察以确保他们能支持所需要的事务，同时也定义数据库要求的完整性约束。

物理数据库设计包括六个主要的步骤：

1. 包括使用目标DBMS的功呢国内设计基本表和完整性约束。
2. 为基本表选择文件的组织方式以及索引，通常DBMS一般有固定的存储结构。
3. 在数据库系统开发生命周期的需求分析和手机阶段确定的用户视图的设计。
4. 设计安全性措施以避免未授权的用户对数据的访问。
5. 放宽在表上的规范化约束，从而改善整个系统的性能，这个步骤只有在需要的时候才作，因为在引入数据冗余时会同时产生一些问题，仍需要维护其一致性，
6. 通过监视和调整操作系统来标示和解决由设计问题引起的性能问题，并实现新的或者改变的需求。

数据库设计是一个迭代过程，开始以后就要不断进行精化，尽管数据库设计方法学是过程化的，但是并不意味着要以过程化的方式执行，在某一个阶段得到的结果可能会改变上一个阶段做出的决定，同时后一个阶段中查看前面的结果是有帮助的。

版权声明：原创作品，允许转载，转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将追究法律责任。http://tianli.blog.51cto.com/190322/48108

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号