数据库设计概念

数据库设计概念

在设计数据库时，需要计划要存储有关哪些事物的信息，以及要保存有关各个事物的哪些信息。您还需要确定这些事物的相互关系。如果使用数据库设计中的术语，在这一步创建的数据库原型就称作概念数据库模型。

实体和关系

要存储其相关信息的可识别对象或事物称作实体。它们之间的关联称作关系。在数据库描述语言中，可以将实体看做名词，将关系看做动词。

由于概念模型对实体和关系进行了明确的区分，因此这种模型非常有用。这种模型将在任何特定数据库管理系统中实施设计所涉及的细节隐藏起来，从而使设计者可以集中考虑基础数据库结构。因此，这种模型也成为了一种用于讨论数据库设计的通用语言。

实体关系图

概念数据库模型主要由一个显示实体和关系的示意图构成。这个示意图通常称作实体关系图。因此，许多人也使用实体关系建模这个词来指创建概念数据库模型的任务。

概念数据库设计是一个由上至下的设计方法。现在有许多功能完备的工具可以帮助您按照这种方法或其他方法进行设计，例如，Sybase PowerDesigner。虽然本章的目的只是进行介绍，但也提供了足够的信息可以帮助您设计简单的数据库。

实体

在数据库中，一个实体对应于一个名词。可识别的对象，例如，雇员、订单项、部门和产品，都是实体的示例。在数据库中用表代表各个实体。置入数据库的实体都源于要使用数据库执行的活动，例如，跟踪销售电话和维护雇员信息，等等。

属性

每个实体都包含一些属性。属性是指要为事物存储的特定特性。例如，在雇员实体中，需要存储雇员ID 号、姓氏和名字、地址，以及与一个特定雇员相关的其他信息。属性也称作特性。

实体用一个矩形框表示。在矩形框内部，列出与该实体相关联的属性。

标识符是指所有其他属性都依赖的一个或多个属性。它在实体中唯一地标识一个项目。在要组成标识符的属性名下面加上下划线。

在上面的Employee 实体中，Employee Number 唯一地标识一个雇员。所有其他属性都存储只与那个雇员相关的信息。例如，一个雇员编号唯一地确定一个雇员的名字和地址。两个雇员可能具有相同的名字或相同的地址，但可以确保他们的雇员编号不同。Employee Number 下面带有下划线，表示它是标识符。

为每个实体都创建一个标识符是一个良好的习惯。这些标识符在表中将成为主键，下文中将对此进行说明。主键值必须唯一，并且不能为空或未定义。主键唯一地标识表中的每一行，并且提高数据库服务器的性能。

关系

在数据库中，实体之间的一个关系对应于一个动词。一个雇员属于一个部门，或者一个办事处位于一座城市。数据库中的关系可能表现为表间的外键关系，也可能自身就成为独立的表。您将在本章中看到这两种情况的示例。

数据库中的关系就是控制实体中数据的规则或惯例的编码。如果每个部门有一个部门经理，可以在部门和雇员之间建立一对一的关系来标识该部门经理。

当关系置入数据库结构后，就不可能再出现例外。没有地方可以输入另一个部门经理。复制部门条目将复制部门ID，而它是标识符。标识符不允许有重复。

关系的基数

表之间有三种关系。这三种关系对应于关系中所涉及的实体的基数（数量）。

一对一关系关系通过在两个实体间画一条连线表示。连线上可以有其他标记，例如，下图中所示的两个圆圈。这些

标记的用途将在下文中进行说明。在下图中，一个部门由一

个雇员管理。

?一对多关系如果[实体1] 中包含的一项可以与[实体2] 中的多项相关联，这样一种关系用多条连线连接到[实体2]

来表示。在下图中，一个办事处可以有多部电话。

?多对多关系在这种情况下，两个实体的连接处都要画多条连线。这表示一个仓库可以存放许多不同的部件，而同一类

部件也可以存放在许多仓库中。

角色

您可以用两个角色来描述每种关系。角色是用于从每个观察点描述关系的

动词或短语。例如，雇员和部门之间的关系可以用以下两个角色来描述：

1. 雇员属于部门。

2. 而部门包含雇员。

角色非常重要，因为它们为您提供了一种方便且有效的方法来验证您的工作。

提示

不管是从左到右读取还是从右到左读取，下面的规则都会使读取这些图示变得容易：读取(1) 第一个实体的名称，(2) 第一个实体旁边的角色，(3) 到第二个实体的连接的基数，(4) 第二个实体的名称。

强制元素

表示关系的连线末端的小圆圈具有非常重要的作用。圆圈表示存在于该实

体内的元素在另一个实体内不必有对应的元素。

如果出现的是一段交叉线而不是圆圈，则表示另一个实体中的每个元素在

该实体中至少应有一个对应元素。下面举例说明这些标记的含义。

此图具有以下四个含义：

1. 一家出版社出版了零或多本书。

2. 一本书由恰好一家出版社出版。

3. 一本书由一或多位作者撰写。

4. 一位作者撰写了零或多本书。

反身关系

有时，同一个实体内的条目之间也存在关系。这种关系称作反身关系。关系的两端都连接到同一个实体。

此图具有以下两个含义。

1. 一个雇员最多只向另外一个雇员报告。

2. 一个雇员管理零个或多个雇员。

请注意，在这个关系中，关系在两个方向上都应该是可选的。某些雇员不是经理。同样，至少应该有一个雇员是公司的总经理，因此不向任何人报告。

自然，还应指定一个雇员不能是他自己的经理。这个限制是一种业务规则。业务规则将在下文中作为设计过程的一部分进行讨论。

将多对多关系更改为实体

如果有属性与关系相关联，而不是与实体相关联，则可以将该关系更改为实体。有时，多对多关系可能会出现这种情况。有些属性特定于关系，因此将其添加到任何一个实体中都不合理。

假设部件存放在多个不同的仓库中。而您画的设计图如下所示。

但您希望记录各个部件在各个地点的存货数量。该属性只能与关系相关联。每个数量都依赖于所涉及的部件和仓库。要表示这样一种情况，可以按以下方式重画设计图：

请注意以下细节的变化：

1. 两个新关系将关系实体分别与原有的两个实体连接起来。这

两个关系的名称继承自原有关系的两个角色：分别为存放在

和包含

2. Inventory 实体中的每个条目要求Parts 实体中有一个强制

条目，Warehouse 实体中有一个强制条目。这些关系都是强

制的，因为仓储关系只在与一个特定部件和一个特定仓库相

关联时才有意义。

3. 新实体既依赖于Parts 实体，也依赖于Warehouse 实体，

表示新实体由这两个实体的标识符共同标识。在这个新设计

图中，Parts 实体中的一个标识符和Warehouse 实体中的

一个标识符唯一地标识Inventory 实体中的一个条目。圆圈

和多线条之间的三角形将两个新关系连接到新的Inventory

实体，并表示依赖性。

不要在Inventory 实体中添加Part Number 或Warehouse ID 特性。Inventory 实体中的每个条目都依赖于一个特定部件和一个特定仓库，但这些三角形可以更清晰的表示这种依赖性。

设计过程

设计过程包含五个主要步骤。

?第1 步：确定实体和关系

?第2 步：确定所需数据

?第3 步：规范化数据

?第4 步：解析关系

?第5 步：验证设计

有关实现数据库设计的详细信息，请参见使用数据库对象。

第 1 步：确定实体和关系

实体和关系示例

第 2 步：确定所需数据

第 3 步：规范化数据

第 4 步：解析关系

第 5 步：验证设计

第 1 步：确定实体和关系

确定设计中的实体及实体之间的关系：

1. 确定高级别的活动确定要使用该数据库执行的一般活动。例如，

可能要用它来跟踪有关雇员的信息。

2. 确定实体对于这些活动，确定需要维护有关哪些类对象的信息。

这些对象将成为实体。例如，聘用雇员，将雇员分配到某个部门，并确定其技能级别。

3. 确定关系对这些活动进行分析，然后确定实体间会有哪些关系。

例如，部件和仓库之间有关系。定义两个角色来描述每个关系。

4. 分解活动开始时确定了高级别的活动。现在，需要进一步分析

这些活动，确定是否可以将其中一些分解为较低级别的活动。例

如，象维护雇员信息这样一个高级别活动可以分解为：

o添加新雇员。

o更改现有雇员信息。

o删除已离职的雇员。

5. 确定业务规则对业务说明进行分析，确定应遵守哪些规则。例

如，[一个部门有且仅有一个经理] 就可以作为一个业务规则。这

些规则将被置入数据库的结构中。

实体和关系示例

示例

ACME Corporation 是一家小公司，它在五个地点设有办事处。目前，ACME 有75 名雇员。该公司正准备迅速发展，并且已经确定了九个部门，每个部门都有自己的部门经理。

为帮助公司招聘新雇员，人事部门确定了68 项技能，并且认为公司将来需要具有这些技能的雇员。聘用了一个雇员后，将对该雇员在每项技能上的专业级别进行评定。

确定高级别的活动

ACME Corporation 需要考虑的高级别活动有：

?聘用雇员。

?解聘雇员。

?维护雇员的个人信息。

?维护有关公司所需技能的信息。

?维护有关哪个雇员具有哪项技能的信息。

?维护有关部门的信息。

?维护有关办事处的信息。

确定实体和关系

确定实体（对象）和连接实体的关系（角色）。根据以上说明和高级别的活动创建一个设计图。

用矩形框表示实体，用连线表示关系。用两个角色标记每个关系。还应使用适当的标注表示那些一对多、一对一和多对多关系。

下面是一个粗略的实体关系图。在本章后面的部分将逐渐对其进行改进。

分解高级别的活动

根据上述高级别的活动可以确定以下较低级别的活动：

?添加或删除雇员。

?添加或删除办事处。

?列出某个部门的雇员。

?在技能列表中添加技能。

?确定某个雇员的技能。

?确定某个雇员在各项技能上的技能级别。

?确定在某项技能上具有相同技能级别的所有雇员。

?更改雇员的技能级别。

使用这些较低级别的活动可以确定是否需要新表或新关系。

确定业务规则

业务规则通常可以表示为一对多、一对一和多对多关系。

可能相关的业务规则有以下几个：

?现在有五个办事处；扩展计划允许增加到最多十个。

?雇员可以更换部门或办事处。

?每个部门有一个部门经理。

?每个办事处最多有三个电话号码。

?每个电话号码有一个或多个分机。

?聘用了一个雇员后，将对该雇员在各项技能上的专业级别进行评定。

?每个雇员具有三到二十项技能。

?可以将雇员分配到一个办事处，也可以不分配

第 2 步：确定所需数据

确定所需数据：

1. 确定支持数据。

2. 列出所有需要跟踪的数据。

3. 为每个实体设置数据。

4. 列出每个实体的可用数据。描述实体（对象）的数据可以回

答涉及何人、何事、何处、何时以及何故的问题。

5. 列出每个关系（动词）需要的所有数据。

6. 列出适用于每个关系的数据（如果有）。

确定支持数据

您所确定的支持数据将成为实体中属性的名称。例如，以下数据可能适用于Employee 实体、Skill 实体，和Expert In 实体。

根据这些数据创建的设计图将如下图所示：

请注意，列出的所有属性并未都在这张设计图中出现。未出现的属性可归为以下两类：

1. 有一些属性隐式包含在其他关系中；例如，雇员的部门和雇

员所在的办事处分别用连接Department 和Office 实体的

关系表示。

2. 其他一些属性未出现的原因是它们与这些实体并不相关联，

而是与这些实体间的关系相关联。上图并不完整。

在绘制完整的实体关系图时，第一类属性会自然出现。

可以通过将多对多关系转换为实体来添加第二类属性。

新实体同时依赖于"Employee"实体和"Skill"实体。它将借用这些实体中的标识符，因为它同时依赖于这两个实体。

注意

?确定支持数据时，一定要参考前面确定的活动以了解将如何访问这些数据。

例如，在某些情况下可能需要按雇员的名字列出雇员，而在

另一些情况下可能需要按姓氏列出。要满足这两种需要，应

创建一个First Name 属性和一个Last Name 属性，而不应

创建一个既包含名字又包含姓氏的属性。将姓氏和名字分开

后，以后可以创建两个索引，分别适用于这两项任务。

?请选择一致的名称。使用一致的名称可以使数据库便于维护，并且便于阅读报告和输出窗口。

例如，如果一个属性使用了缩略名称，如Emp_status，则另

一个属性不应使用完整名称，如Employee_ID。应使名称保

持一致，如Emp_status 和Emp_ID。

?在这个阶段，数据是否与正确的实体相关联并不十分重要。

您可以根据自己的判断进行设计。在下一节中，将对设计进

行测试，检查您的判断是否正确。

第 3 步：规范化数据

规范化是指一系列测试，通过这些测试可以消除冗余的数据，并确保数据与正确的实体或关系相关联。共有五项测试。本节介绍其中前三项测试。这三项测试最重要，因此也最常使用。

有关规范化测试的更多信息，请参见有关数据库设计的书籍。

范式

数据规范化包括几项测试。数据在通过了第一项测试后，我们认为它满足第一范式；通过了第二项测试后，它满足第二范式；通过了第三项测试后，则满足第三范式。

规范化数据库中的数据：

1. 列出这些数据。

o为每个实体至少确定一个键。每个实体必须有一

个标识符。

o确定关系的键。关系的键是该关系所连接的两个

实体的键。

o检查支持数据列表中是否有计算数据。计算数据

通常不存储在关系数据库中。

2. 第一范式测试。

o如果一个属性在同一个条目上可以有几个不同的

值，则删除这些重复的值。

o用删除的数据创建一个或多个实体或关系。

3. 第二范式测试。

o找出带有多个键的实体和关系。

o删除只依赖于键的一部分的数据。

o用删除的数据创建一个或多个实体或关系。

4. 第三范式测试。

o删除依赖于实体或关系中的其他数据，而不依赖

于键的数据。

o用删除的数据创建一个或多个实体或关系。

数据和标识符

开始进行规范化（对设计进行测试）之前，简单地列出数据，并为每个表确定一个唯一的标识符。标识符可以由一个数据（属性）或几个数据（复合标识符）组成。

标识符是唯一地标识实体中各行的一组属性。例如，Employee 实体的标识符是Employee ID。Works In 关系的标识符由Office Code 和Employee ID 属性组成。

数据库中每个关系的标识符可由该关系所连接的各个实体的标识符组成。在下表中，带有星号的属性为该实体或关系的标识符。

第一范式测试

?进行第一范式测试时，应找出可能有重复值的属性。

?如果有多个值都适用于某一项，则删除这些属性。将这些重复属性移到一个新实体中。

在下面的实体中，Phone number 可能会重复—一个办事处可以有多个电话号码。

删除重复的属性，并创建一个名为Telephone 的新实体。在Office 与Telephone 之间建立一个关系。

第二范式测试

?删除不依赖于整个键的值。

?只需要检查标识符由多个属性组成的实体和关系。进行第二范式测试时，应删除所有不依赖于整个标识符的数据。每个

属性都应依赖于组成标识符的所有属性。

在这个示例中，Employee and Department 实体的标识符由两个属性组成。有些数据与这两个标识符属性并不都具有依赖关系，例如，部门名称只依赖于其中一个属性，Department ID，而雇员的名字只依赖于Employee ID。

将其他雇员数据不依赖的标识符Department ID 移到其名为Department 的实体中。还应移动所有依赖于它的属性。在Employee 和Department 之间创建一个关系。

第三范式测试

?删除不直接依赖于键的数据。

?进行第三范式测试时，应删除所有依赖于其他属性而不直接依赖于标识符的属性。

在这个示例中，Employee and Office 实体中有一些属性依赖于其标识符Employee ID。但是，Office location 和Office phone 等属性却依赖于另一个属性，Office code。这些属性不依赖于标识符Employee ID。

删除Office code 和那些依赖于它的属性。创建另一个名为Office 的实体。然后，创建一个连接Employee 和Office 实体的关系。

第 4 步：解析关系

执行完规范化过程后，设计几乎就完成了。唯一还需要做的事情就是生成与概念数据模型相对应的物理数据模型。这个过程也称作解析关系，因为其中涉及的大量工作就是将概念模型中的关系转换为相应的表和外键关系。

虽然概念模型在很大程度上独立于实施细节，但物理数据模型与特定数据库应用程序中的表结构和可用选项紧密相关。在这里，我们所指的应用程序就是Adaptive Server Anywhere。

解析不带有数据的关系

要实施不带有数据的关系，需要定义外键。外键是指包含另一个表中的主键值的一列或几列。利用外键一次可以访问多个表中的数据。

使用象Sybase PowerDesigner 的DataArchitect 组件的数据库设计工具可以自动生成物理数据模型。但如果要自己生成物理模型，有一些基本规则可以帮助您确定将哪些列设置为键。

?一对多一个一对多关系总是会变为一个实体和一个外键关系。

请注意，实体将变为表。实体中的标识符（至少一部分）将

变为表中的主键。属性将变为列。在一对多关系中，一方的

实体中的标识符成为多方的表中新加的外键列。

在这个示例中，Employee 实体变为Employee 表。同样，

Department 实体变为Department 表。Employee 表中将出

现一个名为Department ID 的外键。

?一对一对于一对一关系，可在其中任意一个表中设置外键。如果关系在一侧是强制的，但在另一侧是可选的，应在

可选的一侧设置外键。在这个示例中，在Truck 表中设置外

键(Vehicle ID) 是因为车辆不一定都是卡车。

因此，上面的实体关系模型将解析为下面的数据库基本结构。

多对多在多对多关系中，创建的新表中有两个外键。必须这样安排才会使数据库更高效。

新的Storage Location 表将Parts 和Warehouse 表关联

起来。

解析带有数据的关系

有些关系可能会带有数据。这种情况常常会在多对多关系中出现。

在这种情况下，每个实体都将解析为一个表。每个角色将变为指向另一个表的外键。

Inventory 实体借用Parts 和Warehouse 表中的标识符，因为它与这两个表都有依赖关系。经过解析后，这些借用的标识符将成为Inventory 表的主键。

第 5 步：验证设计

实施设计之前，需要确保该设计能够满足您的需要。检查在设计过程之初确定的活动，确保可以访问这些活动所需要的数据。

?能否找到一条获取所需信息的途径？

?设计是否满足您的需求？

?能否获得所需要的全部数据？

如果您对上述所有问题的回答都是肯定的，那么就可以实现您的设计了。

最终设计

按照第 1 步到第 3 步为前面提到的小公司设计数据库，将得到以下实体关系图。这个数据库现在处于第三范式。

相应的物理数据模型如下所示。

设计数据库表属性

数据库设计将确定需要哪些表，以及每个表中包含哪些列。本节介绍如何指定每个列的属性。

对于每一列，必须确定列名、数据类型和大小、是否允许空值，以及是否希望数据库限制该列中允许包含的值。

选择列名

选择列的数据类型

选择约束

选择列名

列名中可以是任何字母、数字或符号的组合。但是，如果列名包含字母、数字或下划线之外的字符，不以字母开头，或者与关键字相同，则必须将列名用双引号引起来。

选择列的数据类型

Adaptive Server Anywhere 中的可用数据类型有：

?整数数据类型

?小数数据类型

?浮点数据类型

?字符数据类型

?二进制数据类型

?日期/时间数据类型

?域（用户定义的数据类型）

有关数据类型的详细信息，请参见SQL 数据类型。

长二进制数据类型可用于在数据库中存储诸如图像（例如，存储为位图）或字处理文档等信息。这些类型的信息通常称为二进制大对象，或BLOBS。

有关每种数据类型的详细信息，请参见SQL 数据类型。

NULL 和NOT NULL

如果记录中要求某列必须有值，应将该列定义为NOT NULL。否则，该列可以包含NULL 值，表示没有值。SQL 中的缺省设置是允许NULL 值，但如果没有充分的理由来允许NULL 值，则应将列显式声明为NOT NULL。

有关NULL 值的详细信息，请参见NULL 值。有关在比较中使用NULL 的信息，请参见搜索条件。

选择约束

虽然列的数据类型可以限制该列中允许包含的值（例如，只允许包含数字或只允许包含日期），但可能需要进一步限制允许的值。

可以通过指定CHECK 约束来限制任何列的值。可以使用可能出现在WHERE 子句中的任何有效条件来限制所允许的值。大多数CHECK 约束都使用BETWEEN 或IN 条件。

有关有效条件的详细信息，请参见搜索条件。有关为表和列指派约束的详细信息，请参见确保数据完整性。

示例

示例数据库有一个名为Department 的表，该表具有名为dept_id、dept_name 和dept_head_id 的列。它的定义如下所示：

如果指定NOT NULL，则必须为该表中的每一行提供值。

数据库课后题答案 第7章 数据库设计

第7章数据库设计 1．试述数据库设计过程。 答：这里只概要列出数据库设计过程的六个阶段：( l ）需求分析；( 2 ）概念结构设计；( 3 ）逻辑结构设计；( 4 ）数据库物理设计；( 5 ）数据库实施；( 6 ）数据库运行和维护。这是一个完整的实际数据库及其应用系统的设计过程。不仅包括设计数据库本身，还包括数据库的实施、运行和维护。设计一个完善的数据库应用系统往往是上述六个阶段的不断反复。 2 ．试述数据库设计过程各个阶段上的设计描述。 答：各阶段的设计要点如下：( l ）需求分析：准确了解与分析用户需求（包括数据与处理）。( 2 ）概念结构设计：通过对用户需求进行综合、归纳与抽象，形成一个独立于具体DBMS 的概念模型。( 3 ）逻辑结构设计：将概念结构转换为某个DBMS 所支持的数据模型，并对其进行优化。( 4 ）数据库物理设计：为逻辑数据模型选取一个最适合应用环境的物理结构（包括存储结构和存取方法）。( 5 ）数据库实施：设计人员运用DBMS 提供的数据语言、工具及宿主语言，根据逻辑设计和物理设计的结果建立数据库，编制与调试应用程序，组织数据入库，并进行试运行。( 6 ）数据库运行和维护：在数据库系统运行过程中对其进行评价、调整与修改。 3 ．试述数据库设计过程中结构设计部分形成的数据库模式。 答：数据库结构设计的不同阶段形成数据库的各级模式，即：( l ）在概念设计阶段形成独立于机器特点，独立于各个DBMS 产品的概念模式，在本篇中就是 E 一R 图；( 2 ）在逻辑设计阶段将 E 一R 图转换成具体的数据库产品支持的数据模型，如关系模型，形成数据库逻辑模式，然后在基本表的基础上再建立必要的视图( Vi 娜），形成数据的外模式；( 3 ）在物理设计阶段，根据DBMS 特点和处理的需要，进行物理存储安排，建立索引，形成数据库内模式。 4 ．试述数据库设计的特点。 答：数据库设计既是一项涉及多学科的综合性技术又是一项庞大的工程项目。其主要特点有：( l ）数据库建设是硬件、软件和干件（技术与管理的界面）的结合。( 2 ）从软件设计的技术角度看，数据库设计应该和应用系统设计相结合，也就是说，整个设计过程中要把结构（数据）设计和行为（处理）设计密切结合起来。 5 ．需求分析阶段的设计目标是什么？调查的内容是什么？ 答：需求分析阶段的设计目标是通过详细调查现实世界要处理的对象（组织、部门、企业等），充分了解原系统（手工系统或计算机系统）工作概况，明确用户的各种需求，然后在此基础上确定新系统的功能。调查的内容是“数据’夕和“处理”，即获得用户对数据库的如下要求：( l ）信息要求，指用户需要从数据库中获得信息的内容与性质，由信息要求可以导出数据要求，即在数据库中需要存储哪些数据；( 2 ）处理要求，指用户要完成什么处理功能，对处理的响应时间有什么要求，处理方式是批处理还是联机处理；( 3 ）安全性与完整性要求。 6 ．数据字典的内容和作用是什么？ 答：数据字典是系统中各类数据描述的集合。数据字典的内容通常包括：( l ）数据项；( 2 ）数据结构；( 3 ）数据流；( 4 ）数据存储；( 5 ）处理过程五个部分。其中数据项是数

数据库概念设计ER图

数据库概念设计 ER图 注:提交时,将文件名命名为(数据库系统概论ER图练习:学号+姓名+日期) 第一题:参考 大学实行学分制，学生可根据自己的情况选课。每名学生可同时选修多门课程，每门课程可由多位教师主讲；每位教师可讲授多门课程。 指出学生与课程的联系类型。 指出课程与教师的联系类型。 若每名学生有一位教师指导，每个教师指导多名学生，则学生与教师是何联系? 在原E-R图上补画教师与学生的联系，并完善E-R图。

第二题:将ER图转化为关系模式 单位 职工 第三题:画ER图 职工：职工号、姓名、地址和所在部门 部门：部门所有职工、部门名、经理和销售的产品 产品：产品名、制造商、价格、型号和产品内部编号 制造商：制造商名称、地址、生产的产品名和价格 部门有很多职工，职工仅在一个部门工作； 部门销售多种产品，这些产品也在其它部门销售； 制造商生产多种产品，其它制造商也制造这些产品。

画ER图 第四题:画ER图 科室：科名、科地址、科电话、医生姓名 病房：病房号、床位号、所属科室名 医生：姓名、职称、所属科室名、年龄、工作证号 病人病历号、姓名、性别、诊断、主臂医生、病房号一个科室有多个病房、多个医生; 一个病房只能属于一个科室； 一个医生只属于一个科室，但可负责多个病人的诊治;

一个病人的主管医生只有一个。 完成如下设计: 设计该计算机管理系统的E-R图。 将该E-R图转换为关系模式结构。 指出转换结果申每个关系模式的候选码。 第五题:画ER图 某田径运动会组委会需要一运动会管理系统，现提出如下需求。该系统中存在运动队和运动会两方面的实体。 1．运动队方面 运动队：队名、教练姓名 队员：编号、姓名、性别、项名 其中，一个运动队有多个队员，一个队员仅属于一个运动队，一个队一般有一个教练，一个队员可参加多个项目 2．运动会方面 运动队：队编号、队名、教练姓名 项目：项目名、参加运动队编号、场地 其中，一个项目可由多个队参加，一个运动队可参加多个项目，一个项目一个比赛场地。现要求：(1).分别设计运动队和运动会的局部ER图。

数据库设计方案书概念

数据库设计概念 在设计数据库时，需要计划要存储有关哪些事物的信息，以及要保存有关各个事物的哪些信息。您还需要确定这些事物的相互关系。如果使用数据库设计中的术语，在这一步创建的数据库原型就称作概念数据库模型。 实体和关系 要存储其相关信息的可识别对象或事物称作实体。它们之间的关联称作关系。在数据库描述语言中，可以将实体看做名词，将关系看做动词。 由于概念模型对实体和关系进行了明确的区分，因此这种模型非常有用。这种模型将在任何特定数据库管理系统中实施设计所涉及的细节隐藏起来，从而使设计者可以集中考虑基础数据库结构。因此，这种模型也成为了一种用于讨论数据库设计的通用语言。 实体关系图 概念数据库模型主要由一个显示实体和关系的示意图构成。这个示意图通常称作实体关系图。因此，许多人也使用实体关系建模这个词来指创建概念数据库模型的任务。 概念数据库设计是一个由上至下的设计方法。现在有许多功能完备的工具可以帮助您按照这种方法或其他方法进行设计，例如，Sybase PowerDesigner。虽然本章的目的只是进行介绍，但也提供了足够的信息可以帮助您设计简单的数据库。 实体 在数据库中，一个实体对应于一个名词。可识别的对象，例如，雇员、订单项、部门和产品，都是实体的示例。在数据库中用表代表各个实体。置入数据库的实体都源于要使用数据库执行的活动，例如，跟踪销售电话和维护雇员信息，等等。 属性 每个实体都包含一些属性。属性是指要为事物存储的特定特性。例如，在雇员实体中，需要存储雇员ID 号、姓氏和名字、地址，以及与一个特定雇员相关的其他信息。属性也称作特性。 实体用一个矩形框表示。在矩形框内部，列出与该实体相关联的属性。

数据库设计实例需求分析、概念结构、逻辑结构

数据库设计实例分析 一、需求分析实例 现要开发高校图书管理系统。经过可行性分析和初步的需求调查，确定了系统的功能边界，该系统应能完成下面的功能： （1）读者注册。 （2）读者借书。 （3）读者还书。 （4）图书查询。 1、数据流图 顶层数据流图反映了图书管理系统与外界的接口，但未表明数据的加工要求，需要进一步细化。根据前面图书管理系统功能边界的确定，再对图书管理系统顶层数据流图中的处理功能做进一步分解，可分解为读者注册、借书、还书和查询四个子功能，这样就得到了图书管理系统的第0层数据流图 从图书管理系统第0层数据流图中可以看出，在图书管理的不同业务中，借书、还书、查询这几个处理较为复杂，使用到不同的数据较多，因此有必要对其进行更深层次的分析，即构建这些处理的第1层数据流图。下面的图8-7分别给出了借书、还书、查询子功能的第1层数据流图 2、数据字典 数据项 数据项名称：借书证号 别名：卡号 含义说明：惟一标识一个借书证 类型：字符型 长度：20 …… 数据结构 （1）名称：读者类别 含义说明：定义了一个读者类别的有关信息 组成结构：类别代码+类别名称+可借阅数量+借阅天数+超期罚款额 （2）名称：读者 含义说明：定义了一个读者的有关信息 组成结构：姓名+性别+所在部门+读者类型 （3）名称：图书 含义说明：定义了一本图书的有关信息 组成结构：图书编号+图书名称+作者+出版社+价格 ……

数据流 （1）数据流名称：借书单 含义：读者借书时填写的单据 来源：读者 去向：审核借书 数据流量：250份/天 组成：借书证编号+借阅日期+图书编号 （2）数据流名称：还书单 含义：读者还书时填写的单据 来源：读者 去向：审核还书 数据流量：250份/天 组成：借书证编号+还书日期+图书编号 …… 数据存储 （1）数据存储名称：图书信息表 含义说明：存放图书有关信息 组成结构：图书+库存数量 说明：数量用来说明图书在仓库中的存放数 （2）数据存储名称：读者信息表 含义说明：存放读者的注册信息 组成结构：读者+卡号+卡状态+办卡日期 说明：卡状态是指借书证当前被锁定还是正常使用 （3）数据存储名称：借书记录 含义说明：存放读者的借书、还书信息 组成结构：卡号+书号+借书日期+还书日期 说明：要求能立即查询并修改 …… 处理过程 （1）处理过程名称：审核借书证 输入：借书证 输出：认定合格的借书证 加工逻辑：根据读者信息表和读者借书证，如果借书证在读者信息表中存在并且没有被锁定，那么借书证是有效的借书证，否则是无效的借书证。 …… 二、概念结构设计实例 1．标识图书管理系统中的实体和属性 参照数据字典中对数据存储的描述，可初步确定三个实体的属性为： 读者：｛卡号，姓名，性别，部门，类别、办卡日期，卡状态｝ 读者类别：{类别代码，类别名称，可借阅天数、可借阅数量，超期罚款额}

数据库概念设计及数据建模(一)有答案

数据库概念设计及数据建模(一) 一、选择题 1. 数据库概念设计需要对一个企业或组织的应用所涉及的数据进行分析和组织。现有下列设计内容 Ⅰ．分析数据，确定实体集 Ⅰ．分析数据，确定实体集之间的联系 Ⅰ．分析数据，确定每个实体集的存储方式 Ⅰ．分析数据，确定实体集之间联系的基数 Ⅰ．分析数据，确定每个实体集的数据量 Ⅰ．分析数据，确定每个实体集包含的属性 以上内容不属于数据库概念设计的是______。 A.仅Ⅰ、Ⅰ和Ⅰ B.仅Ⅰ和Ⅰ C.仅Ⅰ、Ⅰ和Ⅰ D.仅Ⅰ和Ⅰ 答案：D [解答] 数据库概念设计主要是理解和获取引用领域中的数据需求，分析，抽取，描述和表示清楚目标系统需要储存和管理什么数据，这些数据共有什么样的属性特征以及组成格式，数据之间存在什么样的依赖关系，同时也要说明数据的完整性与安全性。而数据的储存方式和数据量不是概念设计阶段所考虑的。 2. 关于数据库概念设计阶段的工作目标，下列说法错误的是______。 A.定义和描述应用系统设计的信息结构和范围

B.定义和描述应用系统中数据的属性特征和数据之间的联系 C.描述应用系统的数据需求 D.描述需要存储的记录及其数量 答案：D [解答] 数据库概念设计阶段的工作目标包括定义和描述应用领域涉及的数据范围；获取应用领域或问题域的信息模型；描述清楚数据的属性特征；描述清楚数据之间的关系；定义和描述数据的约束；说明数据的安全性要求；支持用户的各种数据处理需求；保证信息模型方便地转换成数据库的逻辑结构(数据库模式)，同时也便于用户理解。 3. 需求分析阶段的文档不包括______。 A.需求说明书 B.功能模型 C.各类报表 D.可行性分析报告 答案：D [解答] 数据库概念设计的依据是需求分析阶段的文档；包括需求说明书、功能模型(数据流程图或IDEF0图)以及在需求分析阶段收集到的应用领域或问题域中的各类报表等，因此本题答案为D。 4. 数据库概念设计的依据不包括______。

数据库概念设计ER图练习题

数据库概念设计E-R图练习题1．上海可的商业连锁集团需要建立信息系统。该系统中存在3个实体集，一是“商店”实体集，属性有商店编号、商店名、地址等；二是“商品”实体集，属性有商品号、商品名、规格、单价等；三是“职工”实体集，属性有职工编号、姓名、性别、业绩等。 商店与商品间存在“销售”联系，每个商店可销售多种商品，每种商品也可以放在多个商店销售，每个商店销售的一种商品有月销售量；商店与职工之间存在“聘用”联系，每个商店有许多职工，每个职工只能在一个商店工作，商店聘用职工有聘期和工资。试画出E-R 图。 2.某集团公司需要建立一个数据库存储以下信息： (1).该集团公司由多个工厂组成，每个工厂具有厂名和厂长名两个属性；一个厂内有多个车间，每个车间有车间号、车间主任姓名、地址和电话。 (2).一个车间有多个工人，每个工人有职工号、姓名、年龄、性别和工种。 (3).一个车间生产多种产品，产品有产品号和价格。 (4).一个车间生产多种零件，一个零件也可能由多个车间制造。零件有零件号、重量和价格。 (5).一个产品由多种零件组成，一种零件也可装配出多种产品。 (6).产品与零件均分类存贮在特定仓库中。 (7).厂内有多个仓库，仓库有仓库号、仓库主任姓名和电话。 3. Company资料库中纪录某家公司员工、部门与计划等资料。假设在需求收集与分析后，资料库分析人员将这个资料库描述如下： 这家公司是由多个部门所组成。每个部门有一个唯一名称、唯一编号，并且由一名特定员工来管理此部门。此外，一个部门也可以有好几个地点，一个地点也可以多个部门公共。每个部门都负责控管一些计划，每个计划都有一个唯一名称、唯一编号和唯一的工作地点。我们将每位员工的姓名、身分证号码、地址、薪资、性别与生日加以记录储存。每个员工会被指派到某一个部门，但可能会为好几个计划工作，而这些计划并不一定属于同一部门。我们会记录每位员工在每个计画里的每周工作时数，还有每个员工的直属主管。为了管理保险

数据库设计各阶段

1.数据库应用系统的设计步骤 按规范设计的方法可将数据库设计分为以下六个阶段 （1）需求分析; （2）概念结构设计; （3）逻辑结构设计; （4）数据库物理设计; （5）数据库实施; （6）数据库运行和维护。 2.需求分析 需求收集和分析是数据库应用系统设计的第一阶段。明确地把它作为数据库应用系统设计的第一步是十分重要的。这一阶段收集到的基础数据和一组数据流图（DataFlowDiaˉgram———DFD）是下一步设计概念结构的基础。概念结构对整个数据库设计具有深刻影响。 而要设计好概念结构，就必须在需求分析阶段用系统的观点来考虑问题、收集和分析数据及其处理。如何分析和表达用户需求呢？在众多的分析方法中，结构化分析（StructuredAnalysis，简称SA方法）是一个简单实用的方法。SA方法用自顶向下、逐层分解的方式分析系统。用数据流图，数据字典描述系统。然后把一个处理功能的具体内容分解为若干子功能，每个子功能继续分解，直到把系统的工作过程表达清楚为止。在处理功能逐步分解的同时，它们所用的数据也逐级分解。形成若干层次的数据流图。数据流图表达了数据和处理过程的关系。处理过程的处理逻辑常常用判定表或判定树来描述。数据字典（DataDictionary，简称DD）则是对系统中数据的详尽描述，是各类数据属性的清单。对数据库应用系统设计来讲，数据字典是进行详细的数据收集和数据分析所获得的主要结果。数据字典是各类数据描述的集合，它通常包括以下5个部分： （1）数据项，是数据最小单位。

（2）数据结构，是若干数据项有意义的集合。 （3）数据流，可以是数据项，也可以是数据结构。表示某一处理过程的输入输出。 （4）数据存储，处理过程中存取的数据。常常是手工凭证、手工文档或计算机文件。 （5）处理过程。 3."概念结构设计 如同软件工程中重视需求分析与规范说明的思想一样，数据库设计中同样十分重视数据分析、抽象与概念结构的设计。概念结构的设计，是整个数据库设计的关键之 一。"概念结构独立于数据库逻辑结构，独立于支持数据库的DBMS，也独立于具体计算机软件和硬件系统。归纳总结，其主要特点是： （1）能充分地反映现实世界，包括实体和实体之间的联系，能满足用户对数据处理的要求，是现实世界的一个真实的模型，或接近真实的模型。 （2）易于理解，从而可以和不熟悉计算机的用户交换意见。用户的积极参与是数据库应用系统设计成功与否的关键。 （3）易于更动。当现实世界改变时容易修改和扩充，特别是软件、硬件环境变化时更应如此。 （4）易于向关系、网状或层次等各种数据模型转换。概念结构是各种数据模型的共同基础，它比任意一种数据模型更独立于机器，更抽象，从而更加稳定。描述概念结构的有力工具是E-R模型。P.P.S.Chen把用E-R模型定义的概念结构称为组织模式。设计概念结构的策略有3种： （1）自顶向下首先定义全局概念结构的框架，然后逐步细化。 （2）自底向上首先定义各局部应用的概念结构，然后将它们集成，得到全局概念结构。

概念数据库设计(学员视图)

网上培训系统概念数据库设计（学员视图） 一、学员子模块E-R图 二、学员子模块E-R图描述 1．学员选课（Student applies course） （1）课程列表 学员进入课程列表页面，查看已选课程，未选课程，待确认课程，已取消课程，全部课程，了解课程的情况，了解自己的必修课，旁听课等。 其中已取消课程包括所有历史上取消课程的成功申请。 待确认课程中包括选课申请和取消申请。 ●首先页面显示学员已选课程，包括必修课和旁听课。 ●获取学员id，从课程学员表中查出该学员已选课程的记录。 ●学员点击课程的链接，可以查看课程的详细情况， ●调用课程详细信息显示公用页面。传递参数课程ID。 ●选择未选课程，页面显示所有该学员未选的课程列表。 ●获取学员ID，从课程学员表中查出该学员已选课程，查询两个表课程信息表和课 程学员表，所有不在该学员的课程学员表中出现的课程为未选课程。

●显示课程详细信息同上。 ●选择待确认课程，显示待确认课程列表，查询申请表中申请状态为N的记录。应 当包括了申请和取消申请两类。 ●选择已取消课程，显示学员申请取消课程，管理员同意取消的课程列表。查询申请 表中申请类型为C申请状态为A的记录。 ●选择全部课程，显示全部开设的课程，从课程学员表中得到所有课程状态为N的 记录。 ●点击课程链接，可以查看课程详细信息。 （2）旁听申请 ●学员进入旁听申请页面，页面显示所有未选的课程， ●学员在要旁听的课程前打勾，可以多选， ●点击确定按钮，提交申请， ●程序获取所有用户选择的课程ID，在课程申请表中插入记录，申请状态为N，申 请类型为P。同时在课程申请历史表中插入该记录和学员ID，时间，操作流水。 在日志表log_action插入记录，操作内容为“选课旁听申请”，在log_table插入记 录，操作内容为插入数据库的sql语句。 ●如果操作成功，系统自动返回课程列表，否则根据错误代码，调用公共错误显示页 面，显示错误信息。 ●页面自动返回课程列表 （3）取消申请 ●学员进入取消申请页面，页面显示所有已选课程，包括已选待确认课程， ●选择要取消申请的课程，可以多选， ●点击确定按钮，提交申请， ●程序获取所有用户选择的课程ID，对于必修课和已经被管理员确认的旁听课，在 课程申请表中插入记录，申请状态为N，申请类型为C，并在历史表和日志表中插 入相应的记录；对于未被确认的旁听课，在课程申请表中删除对应的课程申请，在 申请历史表中插入该记录，在两个日志表中插入相应的记录。 ●成功则页面显示用户选择了哪几门课程取消，其中旁听申请未确认的课程已被取 消，其他课程等待管理员确认。 ●如果失败，系统根据错误代码显示错误页面。 （4）课程取消 ●页面显示所有被管理员取消的课程列表，包括历史上的记录。 ●在课程信息表中选择所有课程状态为“已取消”的课程记录。 ●点击返回按钮返回课程列表页面 2．学员课堂(Student study the course in the classroom) (1)学员登录系统后，选择学员课堂，进入课堂课程列表页面， (2)系统根据学员ID，在课程学员表中查找所有除了已备份的课程的记录，显示在页面上。 （允许进入的课程包括正上课的和已结业的课程） (3)进入课堂时，如果是已结业的课程，一律不记录时间，也不允许学员完成练习和作业， 也不允许学员答疑和提问。（不如干脆取消已结业课程） (4)选择某门要上的课程，进入该课程的课堂主页面，如果课程是正在上的课程，系统开始

(完整版)数据库设计课后答案

第六章数据库设计 习题解答和解析 1. 1.试述数据库设计过程。 答：这里只概要列出数据库设计过程的六个阶段： (1)需求分析;(2)概念结构设计;(3)逻辑结构设计;(4)数据库物理设计;(5)数据库实 施;(6)数据库运 行和维护。这是一个完整的实际数据库及其应用系统的设计过程。不仅包括设计数据库本身,还包括数据库的实施、运行和维护。设计一个完善的数据库应用系统往往是上述六个阶段的不断反复。 解析：希望读者能够认真阅读《概论》6.1的内容,了解并掌握数据库设计过程。 2. 2.试述数据库设计过程各个阶段上的设计描述。 答：各阶段的设计要点如下： (1)需求分析：准确了解与分析用户需求(包括数据与处理)。 (2)概念结构设计：通过对用户需求进行综合、归纳与抽象,形成一个独立于具体DBMS 的概念模型。 (3)逻辑结构设计：将概念结构转换为某个DBMS所支持的数据模型,并对其进行优化。 (4)数据库物理设计：为逻辑数据模型选取一个最适合应用环境的物理结构(包括存储结构和存取方法)。 (5)数据库实施：设计人员运用DBMS提供的数据语言、工具及宿主语言,根据逻辑设计和物理设计的结果建立数据库,编制与调试应用程序,组织数据入库,并进行试运行。 (6)数据库运行和维护：在数据库系统运行过程中对其进行评价、调整与修改。 解析： 这是进一步了解数据库设计的具体内容。设计描述是指在各个阶段体现设计内容,描述设计结果的各种文档、程序。读者可以参考《概论》上图6.3。 3. 3.试述数据库设计过程中结构设计部分形成的数据库模式。 答：数据库结构设计的不同阶段形成数据库的各级模式,即： (1)在概念设计阶段形成独立于机器特点,独立于各个DBMS产品的概念模式,在本篇中就是E-R图； (2)在逻辑设计阶段将E-R图转换成具体的数据库产品支持的数据模型,如关系模型,形成数据库逻辑模式,然后在基本表的基础上再建立必要的视图(View),形成数据的外模式； (3)在物理设计阶段,根据DBMS特点和处理的需要,进行物理存储安排,建立索引,形成数据库内模式。 读者可以参考《概论》上图6.4。图中概念模式是面向用户和设计人员的,属于概念模型的层次；逻辑模式、外模式、内模式是DBMS支持的模式,属于数据模型的层次,可以在DBMS 中加以描述和存储。 4. 4.试述数据库设计的特点。 答：数据库设计既是一项涉及多学科的综合性技术又是一项庞大的工程项目。其主要特点有： (1)数据库建设是硬件、软件和干件(技术与管理的界面)的结合。 (2)从软件设计的技术角度看,数据库设计应该和应用系统设计相结合,也就是说,整个设计过程中要把结构(数据)设计和行为(处理)设计密切结合起来。详细的可以参考《概论》

1 数据库设计概述

1 数据库设计概述 数据库设计是指对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，使之能够有效地存储数据。 数据库设计的基本步骤： 数据库各阶段设计描述

2 概念结构设计 在早期的数据库设计，在需求分析阶段后，就直接进行逻辑结构设计。由于此时既要考虑现实世界信息的联系与特征，又要满足特定的数据库系统的约束要求，因而对于客观世界的描述受到一定的限制。同时，由于设计时要同时考虑多方面的问题，也使设计工作变得十分复杂。1976年P.P.S.Chen提出在逻辑结构设计之前先设计一个概念模型，并提出了数据库设计的实体--联系方法(Entity--RelationshipApproach)。这种方法不包括深的理论，但提供了一个简便、有效的方法，目前成为数据库设计中通用的工具。 使用E-R模型来进行概念模型的设计通常分两步进行，首先是建立局

部概念模型，然后综合局部概念模型，成为全局概念模型。 2.1 E-R模型基本符号 实体的表示：用长方形 联系的表示：用菱形，1:1、1:n 、(m:1)、(m:n) 属性的表示：用椭圆形

E-R图具有以下几个特性： 一个联系集合可以定义在两个或两个以上的实体集合上，例如老师--学生--课程的联系集合S-T-C，就是定义在三个实体上。 一个联系集合也可以定义在一个实体集合上，例如零件下又分有子零件，每个零件又可由m个子零件组成，每个子零件又可组合成n个零件。 对于给定的实体集合，可以定义一个以上的联系集合，例如工程项目--工人可以定义两个联系集合，其中一个表示工程项目和工人的联系，另一个表示工程项目和工人中的工程项目负责人的联系。前者是n:m的联系，后者是1:1的联系。 实体联系图可以表示一个实体类型对另一个实体类型的存在的依赖性，例如工人这一实体下反映其被抚养者的关系，就是依赖关系，

数据库概念设计ER图实例集

数据库概念设计ER图实例集 例1．某田径运动会组委会需要一运动会管理系统，现提出如下需求。该系统中存在运动队和运动会两方面的实体。 1．运动队方面 运动队：队名、教练姓名 队员：编号、姓名、性别、项名 其中，一个运动队有多个队员，一个队员仅属于一个运动队，一个队一般有一个教练，一个队员可参加多个项目 2．运动会方面 运动队：队编号、队名、教练姓名 项目：项目名、参加运动队编号、场地 其中，一个项目可由多个队参加，一个运动队可参加多个项目，一个项目一个比赛场地。 现要求：(1).分别设计运动队和运动会的局部ER图。 (2).将它们合并为一个全局E-R图。 (3).合并时存在什么冲突，如何解决？

运动队局部ER图： ER图： 运动会局部 存在的冲突 (1).命名冲突：项名、项目名异名同义，统一命名为项目名； (2).结构冲突：项目在两个局部ER图中，一个做多值属性，一个作实体。统一为实体；运动队在两个局部图里的结构不一致也需统一。

例2．上海可的商业连锁集团需要建立信息系统。该系统中存在3个实体集，一是“商店”实体集，属性有商店编号、商店名、地址等；二是“商品”实体集，属性有商品号、商品名、规格、单价等；三是“职工”实体集，属性有职工编号、姓名、性别、业绩等。 商店与商品间存在“销售”联系，每个商店可销售多种商品，每种商品也可以放在多个商店销售，每个商店销售的一种商品有月销售量；商店与职工之间存在“聘用”联系，每个商店有许多职工，每个职工只能在一个商店工作，商店聘用职工有聘期和工资。 (1).试画出E-R 图。 (2).将该E-R 图转换成关系模式，并指出主码和外码。 ER 图： 关系模式： 商店（商店编号，商店名，地址） 职工（职工编号，姓名，性别，业绩，商店编号，聘期，工资） 商品（商品号，商品名，规格，单价）

数据库概念设计及数据建模三

数据库概念设计及数据建模(三) (总分：99.00，做题时间：90分钟) 一、{{B}}选择题{{/B}}(总题数：39，分数：78.00) 1.数据库概念设计需要对一个企业或组织的应用所涉及的数据进行分析和组织。现有下列设计内容 Ⅰ．分析数据，确定实体集 Ⅱ．分析数据，确定实体集之间的联系 Ⅲ．分析数据，确定每个实体集的存储方式 Ⅳ．分析数据，确定实体集之间联系的基数 Ⅴ．分析数据，确定每个实体集的数据量 Ⅵ．分析数据，确定每个实体集包含的属性 以上内容不属于数据库概念设计的是______。 ?A.仅Ⅰ、Ⅳ和Ⅵ ?B.仅Ⅱ和Ⅴ ?C.仅Ⅲ、Ⅳ和Ⅵ ?D.仅Ⅲ和Ⅴ （分数：2.00） A. B. C. D. √ 解析：[解析] 数据库概念设计主要是理解和获取引用领域中的数据需求，分析，抽取，描述和表示清楚目标系统需要储存和管理什么数据，这些数据共有什么样的属性特征以及组成格式，数据之间存在什么样的依赖关系，同时也要说明数据的完整性与安全性。而数据的储存方式和数据量不是概念设计阶段所考虑的。 2.数据库概念设计的目标是理解和表达数据需求，确定和描述数据库中需要存储和处理的数据。关于概念设计有下列说法或做法： Ⅰ．概念设计的重点是从需求文档所定义的业务背景中抽象出实体集及实体集之间的关系 Ⅱ．可采用分类方法将业务背景中具有相同属性特征的客观对象归为类，在此基础上概括命名，得到实体集 Ⅲ．按照业务规则标识和定义实体集之间的联系时，不仅要定义实体集之间的直接联系，也要定义实体集之间的间接联系 Ⅳ．在确定实体集的属性时，不仅要检查每个属性与实体集间的所属关系，也要检查每个实体集属性的完备性 Ⅴ．概念设计的结果通常用DFD或ERD描述，图形表达既能清楚地说明应用系统的数据需求，也便于用来与用户交流和沟通 以上说法或做法正确的是______。 ?A.仅Ⅰ、Ⅱ和Ⅳ ?B.仅Ⅱ、Ⅲ和Ⅳ ?C.仅Ⅰ、Ⅲ和Ⅴ ?D.仅Ⅰ、Ⅳ和Ⅴ ）2.00（分数： A. √

数据库概念设计说明书V1.0

数据库概念设计说明书 External Design Document （The Concept of Database Design ） 项目领域： 项目名称： 修订历史记录

目录 External Design Document (1) （The Concept of Database Design） (1) 一、表清单 (3) 二、表设计说明 (4) 1．部品文件表（mqRecieveParts_temp） (4) 2．车型文件表（mqRecieveVehicle_temp） (5) 3．车型临时表（Vehicle_temp） (6) 4．车型表（VehicleT） (8) 5．车型备份表（Vehicle_BK） (9) 6．部品临时表（Parts_temp） (10) 7．部品表（PartsT） (11) 8．部品备份表（Parts_BK） (12) 9、BomMaster临时表（BomMasterTmp） (13) 10、BomMaster表（BomMaster） (14) 11、CO03BOM表（M_Bom） (14) 12、颜色码对照转换表（Color_change） (17) 13、CO03输出（BOM_Out） (20) 14、用户表（user） (20) 15、日志表（Log） (21) 16、废止零件车型表（vehicleDelete） (21) 17、接收日表（receivetimet） (21) 18、油漆油料BOM表（BOMOIL） (22) 19、18位车型码与SAP侧12位码对照转换表（SAP12_VEH18） (22) 20、部品纳方表 (23) 21、堀越表 (23) 22、ESB数据拆分表 (23)

数据库设计实例需求分析概念结构逻辑结构完整版

数据库设计实例需求分 析概念结构逻辑结构 HEN system office room 【HEN16H-HENS2AHENS8Q8-HENH1688】

数据库设计实例分析 一、需求分析实例 现要开发高校图书管理系统。经过可行性分析和初步的需求调查，确定了系统的功能边界，该系统应能完成下面的功能： （1）读者注册。 （2）读者借书。 （3）读者还书。 （4）图书查询。 1、数据流图 顶层数据流图反映了图书管理系统与外界的接口，但未表明数据的加工要求，需要进一步细化。根据前面图书管理系统功能边界的确定，再对图书管理系统顶层数据流图中的处理功能做进一步分解，可分解为读者注册、借书、还书和查询四个子功能，这样就得到了图书管理系统的第0层数据流图 从图书管理系统第0层数据流图中可以看出，在图书管理的不同业务中，借书、还书、查询这几个处理较为复杂，使用到不同的数据较多，因此有必要对其进行更深层次的分析，即构建这些处理的第1层数据流图。下面的图8-7分别给出了借书、还书、查询子功能的第1层数据流图 2、数据字典 数据项 数据项名称：借书证号 别名：卡号 含义说明：惟一标识一个借书证 类型：字符型 长度：20 …… 数据结构 （1）名称：读者类别 含义说明：定义了一个读者类别的有关信息 组成结构：类别代码+类别名称+可借阅数量+借阅天数+超期罚款额 （2）名称：读者 含义说明：定义了一个读者的有关信息 组成结构：姓名+性别+所在部门+读者类型 （3）名称：图书 含义说明：定义了一本图书的有关信息

组成结构：图书编号+图书名称+作者+出版社+价格 …… 数据流 （1）数据流名称：借书单 含义：读者借书时填写的单据 来源：读者 去向：审核借书 数据流量：250份/天 组成：借书证编号+借阅日期+图书编号 （2）数据流名称：还书单 含义：读者还书时填写的单据 来源：读者 去向：审核还书 数据流量：250份/天 组成：借书证编号+还书日期+图书编号 …… 数据存储 （1）数据存储名称：图书信息表 含义说明：存放图书有关信息 组成结构：图书+库存数量 说明：数量用来说明图书在仓库中的存放数 （2）数据存储名称：读者信息表 含义说明：存放读者的注册信息 组成结构：读者+卡号+卡状态+办卡日期 说明：卡状态是指借书证当前被锁定还是正常使用 （3）数据存储名称：借书记录 含义说明：存放读者的借书、还书信息 组成结构：卡号+书号+借书日期+还书日期 说明：要求能立即查询并修改 …… 处理过程 （1）处理过程名称：审核借书证 输入：借书证 输出：认定合格的借书证 加工逻辑：根据读者信息表和读者借书证，如果借书证在读者信息表中存在并且没有被锁定，那么借书证是有效的借书证，否则是无效的借书证。 …… 二、概念结构设计实例

数据库概念设计步骤及实例

数据库概念设计 概念设计的目标是产生反映企业组织信息需求的数据库概念结构，即概念模式。 概念模式是独立于数据库逻辑结构，独立于支持数据库的DBMS,不依赖于计算机系统的。 5.4.1 概念设计的必要性 考核要求：达到“识记”层次 知识点：概念设计的好处 （1）将概念设计从设计过程中独立开来的好处； （2）概念模式在数据库的各级模式中的位置。 5.4.2 概念模型 考核要求：达到“识记”层次 知识点：概念模型的概念及其要求 概念模型：可以看成是现实世界到机器世界的一个过渡的中间层次。在设计数据库系统时，要把现实世界的事物通过认识和抽象转换为信息世界的概念模型，再把概念模型转换为机器世界的数据模型。 对概念模型的要求，主要有以下要点： 有丰富的语义表达能力，能表达用户的各种需求； 简洁、明晰、独立于机器、容易理解； 易于变动； 易于向各种数据模型转换。 .4.3 概念设计的主要步骤 考核要求：达到“识记”层次 知识点：概念设计的主要步骤 分三步完成： (1)进行数据抽象，设计局部概念模式； (2)将局部概念模式综合成全局概念模式； (3)评审 5.4.4 数据抽象 考核要求：达到“识记”层次 知识点：聚集和概括的理解 数据抽象的两种形式：聚集和概括 聚集：其数学意义就是笛卡尔积的概念，通过聚集，形成对象之间的一个联系对象。 比如有以下对象:"学号，姓名，性别，出生年月，身高，..."，通过聚集可以得到一个联系对象"学生基本情况"。聚集表示的是“是...的一部分”（is_part_of）的关系，如“姓名”是"学生基本情况"的一部分 概括：是从一类其他对象形成一个对象。比如，有梅花、月季、兰花等对象，通过概括或以得到一个对象"花"。概括表示的是“是...一种”（is_a）的关系，如“兰花”是一种“花”。