数据库设计概念.docx

数据库设计概念.docx

《数据库设计概念.docx》由会员分享，可在线阅读，更多相关《数据库设计概念.docx（19页珍藏版）》请在冰豆网上搜索。

数据库设计概念

数据库设计概念

在设计数据库时，需要计划要存储有关哪些事物的信息，以及要保存有关各个事物的哪些信息。

您还需要确定这些事物的相互关系。

如果使用数据库设计中的术语，在这一步创建的数据库原型就称作概念数据库模型。

实体和关系 

要存储其相关信息的可识别对象或事物称作实体。

它们之间的关联称作关系。

在数据库描述语言中，可以将实体看做名词，将关系看做动词。

由于概念模型对实体和关系进行了明确的区分，因此这种模型非常有用。

这种模型将在任何特定数据库管理系统中实施设计所涉及的细节隐藏起来，从而使设计者可以集中考虑基础数据库结构。

因此，这种模型也成为了一种用于讨论数据库设计的通用语言。

实体关系图 

概念数据库模型主要由一个显示实体和关系的示意图构成。

这个示意图通常称作实体关系图。

因此，许多人也使用实体关系建模这个词来指创建概念数据库模型的任务。

概念数据库设计是一个由上至下的设计方法。

现在有许多功能完备的工具可以帮助您按照这种方法或其他方法进行设计，例如，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

技能级别

雇员的名字

技能名称

掌握该项技能的日期

雇员的姓氏

技能说明

雇员的部门