数据库设计方案书概念.docx
《数据库设计方案书概念.docx》由会员分享，可在线阅读，更多相关《数据库设计方案书概念.docx（22页珍藏版）》请在冰点文库上搜索。
数据库设计方案书概念
数据库设计概念
在设计数据库时，需要计划要存储有关哪些事物的信息，以及要保存有关各个事物的哪些信息。
您还需要确定这些事物的相互关系。
如果使用数据库设计中的术语，在这一步创建的数据库原型就称作概念数据库模型。
实体和关系
要存储其相关信息的可识别对象或事物称作实体。
它们之间的关联称作关系。
在数据库描述语言中，可以将实体看做名词，将关系看做动词。
由于概念模型对实体和关系进行了明确的区分，因此这种模型非常有用。
这种模型将在任何特定数据库管理系统中实施设计所涉及的细节隐藏起来，从而使设计者可以集中考虑基础数据库结构。
因此，这种模型也成为了一种用于讨论数据库设计的通用语言。
实体关系图
概念数据库模型主要由一个显示实体和关系的示意图构成。
这个示意图通常称作实体关系图。
因此，许多人也使用实体关系建模这个词来指创建概念数据库模型的任务。
概念数据库设计是一个由上至下的设计方法。
现在有许多功能完备的工具可以帮助您按照这种方法或其他方法进行设计，例如，SybasePowerDesigner。
虽然本章的目的只是进行介绍，但也提供了足够的信息可以帮助您设计简单的数据库。
实体
在数据库中，一个实体对应于一个名词。
可识别的对象，例如，雇员、订单项、部门和产品，都是实体的示例。
在数据库中用表代表各个实体。
置入数据库的实体都源于要使用数据库执行的活动，例如，跟踪销售电话和维护雇员信息，等等。
属性
每个实体都包含一些属性。
属性是指要为事物存储的特定特性。
例如，在雇员实体中，需要存储雇员ID号、姓氏和名字、地址，以及与一个特定雇员相关的其他信息。
属性也称作特性。
实体用一个矩形框表示。
在矩形框内部，列出与该实体相关联的属性。
标识符是指所有其他属性都依赖的一个或多个属性。
它在实体中唯一地标识一个项目。
在要组成标识符的属性名下面加上下划线。
在上面的Employee实体中，EmployeeNumber唯一地标识一个雇员。
所有其他属性都存储只与那个雇员相关的信息。
例如，一个雇员编号唯一地确定一个雇员的名字和地址。
两个雇员可能具有相同的名字或相同的地址，但可以确保他们的雇员编号不同。
EmployeeNumber下面带有下划线，表示它是标识符。
为每个实体都创建一个标识符是一个良好的习惯。
这些标识符在表中将成为主键，下文中将对此进行说明。
主键值必须唯一，并且不能为空或未定义。
主键唯一地标识表中的每一行，并且提高数据库服务器的性能。
关系
在数据库中，实体之间的一个关系对应于一个动词。
一个雇员属于一个部门，或者一个办事处位于一座城市。
数据库中的关系可能表现为表间的外键关系，也可能自身就成为独立的表。
您将在本章中看到这两种情况的示例。
数据库中的关系就是控制实体中数据的规则或惯例的编码。
如果每个部门有一个部门经理，可以在部门和雇员之间建立一对一的关系来标识该部门经理。
当关系置入数据库结构后，就不可能再出现例外。
没有地方可以输入另一个部门经理。
复制部门条目将复制部门ID，而它是标识符。
标识符不允许有重复。
提示
严格的数据库结构有很大好处，因为它可以消除不一致的问题，例如一个部门有两个经理。
另一方面，作为设计者，您应该使设计具有足够的灵活性以便于进行扩展，以满足某些未预见到的需要。
对设计合理的数据库进行扩展通常并不很困难，但修改现有表结构可能会致使整个数据库及其客户端应用程序无法使用。
关系的基数
表之间有三种关系。
这三种关系对应于关系中所涉及的实体的基数（数量）。
∙一对一关系 关系通过在两个实体间画一条连线表示。
连线上可以有其他标记，例如，下图中所示的两个圆圈。
这些标记的用途将在下文中进行说明。
在下图中，一个部门由一个雇员管理。
∙一对多关系 如果[实体1]中包含的一项可以与[实体2]中的多项相关联，这样一种关系用多条连线连接到[实体2]来表示。
在下图中，一个办事处可以有多部电话。
∙多对多关系 在这种情况下，两个实体的连接处都要画多条连线。
这表示一个仓库可以存放许多不同的部件，而同一类部件也可以存放在许多仓库中。
角色
您可以用两个角色来描述每种关系。
角色是用于从每个观察点描述关系的动词或短语。
例如，雇员和部门之间的关系可以用以下两个角色来描述：
1.雇员属于部门。
2.而部门包含雇员。
角色非常重要，因为它们为您提供了一种方便且有效的方法来验证您的工作。
提示
不管是从左到右读取还是从右到左读取，下面的规则都会使读取这些图示变得容易：
读取
（1）第一个实体的名称，
（2）第一个实体旁边的角色，（3）到第二个实体的连接的基数，（4）第二个实体的名称。
强制元素
表示关系的连线末端的小圆圈具有非常重要的作用。
圆圈表示存在于该实体内的元素在另一个实体内不必有对应的元素。
如果出现的是一段交叉线而不是圆圈，则表示另一个实体中的每个元素在该实体中至少应有一个对应元素。
下面举例说明这些标记的含义。
此图具有以下四个含义：
1.一家出版社出版了零或多本书。
2.一本书由恰好一家出版社出版。
3.一本书由一或多位作者撰写。
4.一位作者撰写了零或多本书。
提示
可以把小圆圈看做数字0，把交叉线看做数字1。
圆圈表示至少零。
交叉线表示至少一。
反身关系
有时，同一个实体内的条目之间也存在关系。
这种关系称作反身关系。
关系的两端都连接到同一个实体。
此图具有以下两个含义。
1.一个雇员最多只向另外一个雇员报告。
2.一个雇员管理零个或多个雇员。
请注意，在这个关系中，关系在两个方向上都应该是可选的。
某些雇员不是经理。
同样，至少应该有一个雇员是公司的总经理，因此不向任何人报告。
自然，还应指定一个雇员不能是他自己的经理。
这个限制是一种业务规则。
业务规则将在下文中作为设计过程的一部分进行讨论。
将多对多关系更改为实体
如果有属性与关系相关联，而不是与实体相关联，则可以将该关系更改为实体。
有时，多对多关系可能会出现这种情况。
有些属性特定于关系，因此将其添加到任何一个实体中都不合理。
假设部件存放在多个不同的仓库中。
而您画的设计图如下所示。
但您希望记录各个部件在各个地点的存货数量。
该属性只能与关系相关联。
每个数量都依赖于所涉及的部件和仓库。
要表示这样一种情况，可以按以下方式重画设计图：
请注意以下细节的变化：
1.两个新关系将关系实体分别与原有的两个实体连接起来。
这两个关系的名称继承自原有关系的两个角色：
分别为存放在和包含
2.Inventory实体中的每个条目要求Parts实体中有一个强制条目，Warehouse实体中有一个强制条目。
这些关系都是强制的，因为仓储关系只在与一个特定部件和一个特定仓库相关联时才有意义。
3.新实体既依赖于Parts实体，也依赖于Warehouse实体，表示新实体由这两个实体的标识符共同标识。
在这个新设计图中，Parts实体中的一个标识符和Warehouse实体中的一个标识符唯一地标识Inventory实体中的一个条目。
圆圈和多线条之间的三角形将两个新关系连接到新的Inventory实体，并表示依赖性。
不要在Inventory实体中添加PartNumber或WarehouseID特性。
Inventory实体中的每个条目都依赖于一个特定部件和一个特定仓库，但这些三角形可以更清晰的表示这种依赖性。
设计过程
设计过程包含五个主要步骤。
∙第1步：
确定实体和关系
∙第2步：
确定所需数据
∙第3步：
规范化数据
∙第4步：
解析关系
∙第5步：
验证设计
有关实现数据库设计的详细信息，请参见使用数据库对象。
第1步：
确定实体和关系
实体和关系示例
第2步：
确定所需数据
第3步：
规范化数据
第4步：
解析关系
第5步：
验证设计
第1步：
确定实体和关系
确定设计中的实体及实体之间的关系：
1.确定高级别的活动 确定要使用该数据库执行的一般活动。
例如，可能要用它来跟踪有关雇员的信息。
2.确定实体 对于这些活动，确定需要维护有关哪些类对象的信息。
这些对象将成为实体。
例如，聘用雇员，将雇员分配到某个部门，并确定其技能级别。
3.确定关系 对这些活动进行分析，然后确定实体间会有哪些关系。
例如，部件和仓库之间有关系。
定义两个角色来描述每个关系。
4.分解活动 开始时确定了高级别的活动。
现在，需要进一步分析这些活动，确定是否可以将其中一些分解为较低级别的活动。
例如，象维护雇员信息这样一个高级别活动可以分解为：
o添加新雇员。
o更改现有雇员信息。
o删除已离职的雇员。
5.确定业务规则 对业务说明进行分析，确定应遵守哪些规则。
例如，[一个部门有且仅有一个经理]就可以作为一个业务规则。
这些规则将被置入数据库的结构中。
实体和关系示例
示例
ACMECorporation是一家小公司，它在五个地点设有办事处。
目前，ACME有75名雇员。
该公司正准备迅速发展，并且已经确定了九个部门，每个部门都有自己的部门经理。
为帮助公司招聘新雇员，人事部门确定了68项技能，并且认为公司将来需要具有这些技能的雇员。
聘用了一个雇员后，将对该雇员在每项技能上的专业级别进行评定。
确定高级别的活动
ACMECorporation需要考虑的高级别活动有：
∙聘用雇员。
∙解聘雇员。
∙维护雇员的个人信息。
∙维护有关公司所需技能的信息。
∙维护有关哪个雇员具有哪项技能的信息。
∙维护有关部门的信息。
∙维护有关办事处的信息。
确定实体和关系
确定实体（对象）和连接实体的关系（角色）。
根据以上说明和高级别的活动创建一个设计图。
用矩形框表示实体，用连线表示关系。
用两个角色标记每个关系。
还应使用适当的标注表示那些一对多、一对一和多对多关系。
下面是一个粗略的实体关系图。
在本章后面的部分将逐渐对其进行改进。
分解高级别的活动
根据上述高级别的活动可以确定以下较低级别的活动：
∙添加或删除雇员。
∙添加或删除办事处。
∙列出某个部门的雇员。
∙在技能列表中添加技能。
∙确定某个雇员的技能。
∙确定某个雇员在各项技能上的技能级别。
∙确定在某项技能上具有相同技能级别的所有雇员。
∙更改雇员的技能级别。
使用这些较低级别的活动可以确定是否需要新表或新关系。
确定业务规则
业务规则通常可以表示为一对多、一对一和多对多关系。
可能相关的业务规则有以下几个：
∙现在有五个办事处；扩展计划允许增加到最多十个。
∙雇员可以更换部门或办事处。
∙每个部门有一个部门经理。
∙每个办事处最多有三个电话号码。
∙每个电话号码有一个或多个分机。
∙聘用了一个雇员后，将对该雇员在各项技能上的专业级别进行评定。
∙每个雇员具有三到二十项技能。
∙可以将雇员分配到一个办事处，也可以不分配
第2步：
确定所需数据
确定所需数据：
1.确定支持数据。
2.列出所有需要跟踪的数据。
3.为每个实体设置数据。
4.列出每个实体的可用数据。
描述实体（对象）的数据可以回答涉及何人、何事、何处、何时以及何故的问题。
5.列出每个关系（动词）需要的所有数据。
6.列出适用于每个关系的数据（如果有）。
确定支持数据
您所确定的支持数据将成为实体中属性的名称。
例如，以下数据可能适用于Employee实体、Skill实体，和ExpertIn实体。
雇员
技能
擅长于
雇员ID
技能ID
技能级别
雇员的名字
技能名称
掌握该项技能的日期
雇员的姓氏
技能说明
雇员的部门
雇员所在的办事处
雇员的地址
根据这些数据创建的设计图将如下图所示：
请注意，列出的所有属性并未都在这张设计图中出现。
未出现的属性可归为以下两类：
1.有一些属性隐式包含在其他关系中；例如，雇员的部门和雇员所在的办事处分别用连接Department和Office实体的关系表示。
2.其他一些属性未出现的原因是它们与这些实体并不相关联，而是与这些实体间的关系相关联。
上图并不完整。
在绘制完整的实体关系图时，第一类属性会自然出现。
可以通过将多对多关系转换为实体来添加第二类属性。
新实体同时依赖于"Employee"实体和"Skill"实体。
它将借用这些实体中的标识符，因为它同时依赖于这两个实体。
注意
∙确定支持数据时，一定要参考前面确定的活动以了解将如何访问这些数据。
例如，在某些情况下可能需要按雇员的名字列出雇员，而在另一些情况下可能需要按姓氏列出。
要满足这两种需要，应创建一个FirstName属性和一个LastName属性，而不应创建一个既包含名字又包含姓氏的属性。
将姓氏和名字分开后，以后可以创建两个索引，分别适用于这两项任务。
∙请选择一致的名称。
使用一致的名称可以使数据库便于维护，并且便于阅读报告和输出窗口。
例如，如果一个属性使用了缩略名称，如Emp_status，则另一个属性不应使用完整名称，如Employee_ID。
应使名称保持一致，如Emp_status和Emp_ID。
∙在这个阶段，数据是否与正确的实体相关联并不十分重要。
您可以根据自己的判断进行设计。
在下一节中，将对设计进行测试，检查您的判断是否正确。
第3步：
规范化数据
规范化是指一系列测试，通过这些测试可以消除冗余的数据，并确保数据与正确的实体或关系相关联。
共有五项测试。
本节介绍其中前三项测试。
这三项测试最重要，因此也最常使用。
为什么要进行规范化？
规范化的目的是消除冗余并提高一致性。
例如，如果在多个位置都存储了客户的地址，在这些客户搬家后将很难正确更新所有副本。
有关规范化测试的更多信息，请参见有关数据库设计的书籍。
范式
数据规范化包括几项测试。
数据在通过了第一项测试后，我们认为它满足第一范式；通过了第二项测试后，它满足第二范式；通过了第三项测试后，则满足第三范式。
规范化数据库中的数据：
1.列出这些数据。
o为每个实体至少确定一个键。
每个实体必须有一个标识符。
o确定关系的键。
关系的键是该关系所连接的两个实体的键。
o检查支持数据列表中是否有计算数据。
计算数据通常不存储在关系数据库中。
2.第一范式测试。
o如果一个属性在同一个条目上可以有几个不同的值，则删除这些重复的值。
o用删除的数据创建一个或多个实体或关系。
3.第二范式测试。
o找出带有多个键的实体和关系。
o删除只依赖于键的一部分的数据。
o用删除的数据创建一个或多个实体或关系。
4.第三范式测试。
o删除依赖于实体或关系中的其他数据，而不依赖于键的数据。
o用删除的数据创建一个或多个实体或关系。
数据和标识符
开始进行规范化（对设计进行测试）之前，简单地列出数据，并为每个表确定一个唯一的标识符。
标识符可以由一个数据（属性）或几个数据（复合标识符）组成。
标识符是唯一地标识实体中各行的一组属性。
例如，Employee实体的标识符是EmployeeID。
WorksIn关系的标识符由OfficeCode和EmployeeID属性组成。
数据库中每个关系的标识符可由该关系所连接的各个实体的标识符组成。
在下表中，带有星号的属性为该实体或关系的标识符。
实体或关系
属性
办事处
*办事处代码
办事处地址
电话号码
工作地点为
*办事处代码
*雇员ID
部门
*部门ID
部门名称
经理为
*部门ID
*雇员ID
属于
*部门ID
*雇员ID
技能
*技能ID
技能名称
技能说明
擅长于
*技能ID
*雇员ID
技能级别
掌握日期
雇员
*雇员ID
姓氏
名字
社保号码
地址
电话号码
出生日期
第一范式测试
∙进行第一范式测试时，应找出可能有重复值的属性。
∙如果有多个值都适用于某一项，则删除这些属性。
将这些重复属性移到一个新实体中。
在下面的实体中，Phonenumber可能会重复—一个办事处可以有多个电话号码。
删除重复的属性，并创建一个名为Telephone的新实体。
在Office与Telephone之间建立一个关系。
第二范式测试
∙删除不依赖于整个键的值。
∙只需要检查标识符由多个属性组成的实体和关系。
进行第二范式测试时，应删除所有不依赖于整个标识符的数据。
每个属性都应依赖于组成标识符的所有属性。
在这个示例中，EmployeeandDepartment实体的标识符由两个属性组成。
有些数据与这两个标识符属性并不都具有依赖关系，例如，部门名称只依赖于其中一个属性，DepartmentID，而雇员的名字只依赖于EmployeeID。
将其他雇员数据不依赖的标识符DepartmentID移到其名为Department的实体中。
还应移动所有依赖于它的属性。
在Employee和Department之间创建一个关系。
第三范式测试
∙删除不直接依赖于键的数据。
∙进行第三范式测试时，应删除所有依赖于其他属性而不直接依赖于标识符的属性。
在这个示例中，EmployeeandOffice实体中有一些属性依赖于其标识符EmployeeID。
但是，Officelocation和Officephone等属性却依赖于另一个属性，Officecode。
这些属性不依赖于标识符EmployeeID。
删除Officecode和那些依赖于它的属性。
创建另一个名为Office的实体。
然后，创建一个连接Employee和Office实体的关系。
第4步：
解析关系
执行完规范化过程后，设计几乎就完成了。
唯一还需要做的事情就是生成与概念数据模型相对应的物理数据模型。
这个过程也称作解析关系，因为其中涉及的大量工作就是将概念模型中的关系转换为相应的表和外键关系。
虽然概念模型在很大程度上独立于实施细节，但物理数据模型与特定数据库应用程序中的表结构和可用选项紧密相关。
在这里，我们所指的应用程序就是AdaptiveServerAnywhere。
解析不带有数据的关系
要实施不带有数据的关系，需要定义外键。
外键是指包含另一个表中的主键值的一列或几列。
利用外键一次可以访问多个表中的数据。
使用象SybasePowerDesigner的DataArchitect组件的数据库设计工具可以自动生成物理数据模型。
但如果要自己生成物理模型，有一些基本规则可以帮助您确定将哪些列设置为键。
∙一对多 一个一对多关系总是会变为一个实体和一个外键关系。
请注意，实体将变为表。
实体中的标识符（至少一部分）将变为表中的主键。
属性将变为列。
在一对多关系中，一方的实体中的标识符成为多方的表中新加的外键列。
在这个示例中，Employee实体变为Employee表。
同样，Department实体变为Department表。
Employee表中将出现一个名为DepartmentID的外键。
∙一对一 对于一对一关系，可在其中任意一个表中设置外键。
如果关系在一侧是强制的，但在另一侧是可选的，应在可选的一侧设置外键。
在这个示例中，在Truck表中设置外键（VehicleID）是因为车辆不一定都是卡车。
因此，上面的实体关系模型将解析为下面的数据库基本结构。
∙多对多 在多对多关系中，创建的新表中有两个外键。
必须这样安排才会使数据库更高效。
新的StorageLocation表将Parts和Warehouse表关联起来。
解析带有数据的关系
有些关系可能会带有数据。
这种情况常常会在多对多关系中出现。
在这种情况下，每个实体都将解析为一个表。
每个角色将变为指向另一个表的外键。
Inventory实体借用Parts和Warehouse表中的标识符，因为它与这两个表都有依赖关系。
经过解析后，这些借用的标识符将成为Inventory表的主键。
第5步：
验证设计
实施设计之前，需要确保该设计能够满足您的需要。
检查在设计过程之初确定的活动，确保可以访问这些活动所需要的数据。
∙能否找到一条获取所需信息的途径？
∙设计是否满足您的需求？
∙能否获得所需要的全部数据？
如果您对上述所有问题的回答都是肯定的，那么就可以实现您的设计了。
最终设计
按照第1步到第3步为前面提到的小公司设计数据库，将得到以下实体关系图。
这个数据库现在处于第三范式。
相应的物理数据模型如下所示。
设计数据库表属性
数据库设计将确定需要哪些表，以及每个表中包含哪些列。
本节介绍如何指定每个列的属性。
对于每一列，必须确定列名、数据类型和大小、是否允许空值，以及是否希望数据库限制该列中允许包含的值。
选择列名
选择列的数据类型
选择约束
选择列名
列名中可以是任何字母、数字或符号的组合。
但是，如果列名包含字母、数字或下划线之外的字符，不以字母开头，或者与关键字相同，则必须将列名用双引号引起来。
选择列的数据类型
AdaptiveServerAnywhere中的可用数据类型有：
∙整数数据类型
∙小数数据类型
∙浮点数据类型
∙字符数据类型
∙二进制数据类型
∙日期/时间数据类型
∙域（用户定义的数据类型）
有关数据类型的详细信息，请参见SQL数据类型。
长二进制数据类型可用于在数据库中存储诸如图像（例如，存储为位图）或字处理文档等信息。
这些类型的信息通常称为二进制大对象，或BLOBS。
有关每种数据类型的详细信息，请参见SQL数据类型。
NULL和NOTNULL
如果记录中要求某列必须有值，应将该列定义为NOTNULL。
否则，该列可以包含NULL值，表示没有值。
SQL中的缺省设置是允许NULL值，但如果没有充分的理由来允许NULL值，则应将列显式声明为NOTNULL。
有关NULL值的详细信息，请参见NULL值。
有关在比较中使用NULL的信息，请参见搜索条件。
选择约束
虽然列的数据类型可以限制该列中允许包含的值（例如，只允许包含数字或只允许包含日期），但可能需要进一步限制允许的值。
可以通过指定CHECK约束来限制任何列的值。
可以使用可能出现在WHERE子句中的任何有效条件来限制所允许的值。
大多数CHECK约束都使用BETWEEN或IN条件。
有关有效条件的详细信息，请参见搜索条件。
有关为表和列指派约束的详细信息，请参见确保数据完整性。
示例
示例数据库有一个名为Department的表，该表具有名为dept_id、dept_name和dept_head_id的列。
它的定义如下所示：
列
数据类型
大小
NULL/NOTNULL
约束
dept_id
integer
—
NOTNULL
无
dept_name
char
40
NO
升级会员 