数据库设计/数据库开发流程

软件工程的核心方面是将开发过程细分为一系列阶段或步骤，每个阶段都专注于开发的一个方面。这些步骤的集合有时被称为软件开发生命周期 (SDLC)。软件产品会经历这个生命周期（有时会随着它被改进或重新开发而重复），直到最终从使用中退休。理想情况下，生命周期的每个阶段都可以在进入下一阶段之前检查其正确性。

软件开发生命周期 - 瀑布模型

让我们从瀑布模型的概述开始，就像您在大多数软件工程教科书中看到的那样。如图 13.1 所示，这个瀑布模型图说明了一个通用的瀑布模型，可以应用于任何计算机系统开发。它将流程显示为一个严格的步骤序列，其中一个步骤的输出是下一个步骤的输入，并且必须完成一个步骤的所有内容才能进入下一个步骤。

图 13.1. 瀑布模型。

我们可以使用瀑布流程作为一种方法来识别所需的任務，以及每个活动的输入和输出。重要的是活动的范围，可以总结如下

建立需求涉及与利益相关者进行协商，并在利益相关者之间达成一致，以确定他们希望从系统中获得什么，并将其表达为需求说明。
分析从考虑需求说明开始，并以生成系统规格说明结束。规格说明是系统应该做什么的正式表示，以独立于其实现方式的方式表达。
设计从系统规格说明开始，生成设计文档，并提供有关如何构建系统的详细说明。
实施是根据给定的设计文档构建计算机系统，并考虑到系统将运行的环境（例如，开发中可用的特定硬件或软件）。实施可以分阶段进行，通常从一个初始系统开始，该系统可以在发布最终系统以供使用之前进行验证和测试。
测试将实现的系统与设计文档和需求规格说明进行比较，并生成验收报告，或者更常见的是生成需要分析、设计和实施过程审查以纠正的错误和缺陷列表（测试通常是导致瀑布模型在生命周期中迭代的任务）。
维护涉及处理需求或实施环境的变化，修复缺陷或将系统移植到新环境（例如，将系统从独立的 PC 迁移到 UNIX 工作站或网络环境）。由于维护涉及对所需更改的分析、解决方案的设计、该解决方案的实施和测试，因此在维护软件系统的整个生命周期中，瀑布生命周期将被反复重新访问。

数据库生命周期

我们可以使用瀑布周期作为数据库开发模型的基础，该模型包含三个假设

我们可以将数据库的开发（即，定义数据库中数据的模式的规范和创建）与使用数据库的用户进程分开。
我们可以使用三级模式体系结构作为区分与模式相关的活动的基础。
我们可以将约束表示为在数据库中强制执行一次以强制执行数据的语义，而不是在使用数据的每个用户进程中都表示一次。

图 13.2. 数据库开发活动的模型及其输出。

使用这些假设和图 13.2，我们可以看到该图代表了数据库开发活动的模型及其输出。它适用于任何类别的 DBMS，而不仅仅是关系方法。

数据库应用程序开发是获取现实世界需求、分析需求、设计系统的数据和功能，然后在系统中实现操作的过程。

需求收集

第一步是需求收集。在此步骤中，数据库设计人员必须与客户（数据库用户）进行访谈，以了解提议的系统并获取和记录数据和功能需求。此步骤的结果是包含用户提供详细需求的文档。

建立需求涉及与所有用户进行协商，并与所有用户达成一致，以确定他们希望存储哪些持久数据，以及对数据元素的含义和解释达成一致。数据管理员在这一过程中发挥着关键作用，因为他们概述了组织内部影响数据需求的业务、法律和道德问题。

数据需求文档用于确认与用户对需求的理解。为了确保易于理解，它不应过于正式或高度编码。该文档应简要概述所有用户的需求，而不仅仅是一些人的需求，因为目的是开发一个共享的数据库。

需求不应描述如何处理数据，而应描述数据项是什么、它们有哪些属性、适用哪些约束以及数据项之间存在哪些关系。

分析

数据分析从数据需求说明开始，然后生成一个概念数据模型。分析的目的是获得对数据的详细描述，以满足用户需求，从而处理数据的高级和低级属性及其使用。这些属性包括允许的属性值范围（例如，在学校数据库示例中，学生的课程代码、课程名称和学分）。

概念数据模型提供了在数据库开发过程中客户和开发人员之间沟通内容的共享正式表示 - 它专注于数据库中的数据，而不考虑该数据在用户进程中的最终使用或在特定计算机环境中的实施。因此，概念数据模型关注数据的含义和结构，而不关注影响其实现方式的细节。

然后，概念数据模型是对数据库应包含的数据和数据必须满足的约束的正式表示。这应该以独立于模型实现方式的方式表达。因此，分析集中在“需要什么？”这个问题上，而不是“如何实现？”

逻辑设计

数据库设计从一个概念数据模型开始，并生成一个逻辑模式的规范；这将确定所需数据库系统的具体类型（网络、关系、面向对象）。关系表示仍然独立于任何特定 DBMS；它是另一个概念数据模型。

我们可以使用概念数据模型的关系表示作为逻辑设计过程的输入。此阶段的输出是所有表格和约束的详细关系规范（逻辑模式），这些表格和约束需要满足概念数据模型中数据的描述。正是在这个设计活动中，才会对哪些表格最适合表示数据库中的数据做出选择。这些选择必须考虑各种设计标准，包括例如灵活性的变化、重复控制以及如何最好地表示约束。由逻辑模式定义的表格决定了数据库中存储的数据以及如何操作这些数据。

熟悉关系数据库和 SQL 的数据库设计人员可能会在生成概念数据模型后直接进入实施阶段。但是，将关系表示直接转换为 SQL 表格并不一定会导致具有所有理想属性的数据库：完整性、完整性、灵活性、效率和可用性。一个好的概念数据模型是具有这些属性的数据库的必要第一步，但这并不意味着直接转换为 SQL 表格会自动生成一个好的数据库。第一步将准确地表示满足概念数据模型描述所需的所有表格和约束，因此将满足完整性和完整性要求，但它可能不灵活或提供较差的可用性。然后对第一个设计进行弯曲以提高数据库设计的质量。弯曲是一个术语，旨在捕捉将某物弯曲以用于不同目的以及在弯曲时削弱其某些方面的同时想法。

图 13.3 总结了数据库设计中涉及的迭代（重复）步骤，基于给出的概述。它的主要目的是区分应该使用哪些表的总体问题以及每个表的组成部分的详细定义 - 这些表被逐个考虑，尽管它们并不相互独立。每次涉及表修订的迭代都将导致新的设计；它们通常被称为二次设计，即使该过程迭代了不止一个循环。

图 13.3。数据库设计中涉及的迭代步骤的总结。

首先，对于给定的概念数据模型，并非所有它代表的用户需求都需要由单个数据库满足。开发多个数据库可能有各种原因，例如在不同位置需要独立运行或部门对“其”数据的控制。但是，如果数据库集合包含重复数据，并且用户需要访问多个数据库中的数据，那么可能存在一个数据库可以满足多个需求的原因，或者需要检查与数据复制和分发相关的问题。

其次，关于数据库开发的一个假设是，我们可以将数据库的开发与使用它的用户进程的开发分开。这是基于这样的预期，即一旦数据库被实施，所有当前识别出的用户进程所需的数据都已定义并可以访问；但我们也需要灵活性，以便能够满足未来的需求变化。在为某些应用程序开发数据库时，可能能够预测将向数据库提出的常见请求，因此我们可以针对最常见的请求优化我们的设计。

第三，在详细级别上，数据库设计和实施的许多方面取决于使用的特定 DBMS。如果 DBMS 的选择是固定的，或者在设计任务之前完成，那么该选择可用于确定设计标准，而不是等到实施时才确定。也就是说，可以将针对特定 DBMS 的设计决策纳入，而不是生成通用设计，然后在实施过程中将其定制为 DBMS。

通常会发现，单个设计无法同时满足良好数据库的所有属性。因此，重要的是设计人员要优先考虑这些属性（通常使用来自需求规范的信息）；例如，要决定在给定开发中，完整性是否比效率更重要，以及可用性是否比灵活性更重要。

在我们的设计阶段结束时，逻辑模式将由 SQL 数据定义语言 (DDL) 语句指定，这些语句描述了需要实施以满足用户需求的数据库。

实施

实施包括根据逻辑模式的规范构建数据库。这将包括指定适当的存储模式、安全执行、外部模式等等。实施受可用 DBMS、数据库工具和操作环境的选择的影响很大。除了简单地创建数据库模式和实施约束之外，还有其他任务 - 数据必须输入表中，需要解决与用户和用户进程相关的问题，以及与公司数据管理更广泛方面的管理活动需要得到支持。为了保持与 DBMS 方法的一致性，我们希望尽可能多地将这些问题在 DBMS 中解决。我们现在简要地看一下其中的一些问题。

在实践中，在给定 DBMS 中实施逻辑模式需要非常详细地了解 DBMS 所提供的特定功能和设施。在理想情况下，为了保持良好的软件工程实践，实施的第一阶段将涉及将设计要求与最佳可用实施工具进行匹配，然后使用这些工具进行实施。用数据库术语来说，这可能涉及选择最适合我们需要实施的数据库的 DBMS 和 SQL 变体的供应商产品。但是，我们并不生活在一个理想的世界中，而且通常硬件选择和关于 DBMS 的决策是在考虑数据库设计之前就做出的。因此，实施可能涉及对设计进行额外的调整，以克服任何软件或硬件限制。

实现设计

创建逻辑设计后，我们需要根据我们生成的设计创建数据库。对于使用关系型 DBMS 的实施，这可能涉及使用 SQL 创建满足逻辑模式描述的表和约束，以及选择适当的存储模式（如果 DBMS 允许该级别的控制）。

实现这一点的一种方法是将适当的 SQL DDL 语句写入一个文件，该文件可以由 DBMS 执行，以便存在一个独立的记录，一个文本文件，其中包含定义数据库的 SQL 语句。另一种方法是使用像 SQL Server Management Studio 或 Microsoft Access 这样的数据库工具进行交互式操作。无论使用何种机制来实施逻辑模式，结果都是定义了一个数据库，它具有表和约束，但不会包含用户进程的任何数据。

填充数据库

创建数据库后，有两种方法可以填充表 - 来自现有数据或通过使用为数据库开发的用户应用程序。

对于某些表，可能存在来自另一个数据库或数据文件的数据。例如，在为医院建立数据库时，您会期望已经存在一些必须包含在数据库中的所有员工的记录。数据也可能来自外部机构（地址列表通常来自外部公司）或在大量数据输入任务期间产生（将硬拷贝的手动记录转换为计算机文件可以由数据输入机构完成）。在这种情况下，填充数据库的最简单方法是使用 DBMS 中提供的导入和导出功能。

通常提供用于以各种标准格式导入和导出数据的工具（在某些系统中，这些功能也被称为加载和卸载数据）。导入允许将数据文件直接复制到表中。当数据存储在不适合使用导入功能的文件格式中时，则需要准备一个应用程序，该应用程序读取旧数据，根据需要进行转换，然后使用专门为此目的生成的 SQL 代码将其插入数据库。将大量现有数据传输到数据库被称为批量加载。批量加载数据可能涉及将大量数据加载到一个表中，因此您可能会发现 DBMS 提供的功能可以将约束检查推迟到批量加载结束时进行。

开发 ER 图的指南

注意：这些是一般指南，将有助于为实际数据库设计（逻辑模型）奠定坚实的基础。

记录在信息收集阶段发现的所有实体。
记录属于每个实体的所有属性。选择候选键和主键。确保每个实体的所有非键属性都完全依赖于主键。
开发初始 ER 图，并与相关人员进行审查。（请记住，这是一个迭代过程。）
为多值属性和重复组创建新实体（表）。将这些新实体（表）纳入 ER 图。与相关人员进行审查。
通过规范化表来验证 ER 建模。

关键词

分析: 从考虑需求陈述开始，以生成系统规范结束

批量加载: 将大量现有数据传输到数据库

数据需求文档: 用于确认对用户需求的理解

设计: 从系统规范开始，生成设计文档，并提供有关如何构建系统的详细描述

建立需求: 涉及与利益相关者协商并达成一致，以确定他们对系统的期望；以需求陈述的形式表达

弯曲: 一个术语，它捕捉了将某物弯曲用于不同目的以及在弯曲时削弱其某些方面的同时存在的想法

实施: 根据给定的设计文档构建计算机系统

维护: 涉及处理需求或实施环境的变化、错误修复或将系统移植到新的环境

需求收集: 数据库设计人员采访数据库用户以了解拟议系统，并获取和记录数据和功能需求的过程

二次设计: 所有迭代的集合，每次迭代都涉及表修订，从而导致新的设计

软件开发生命周期 (SDLC): 数据库开发过程中涉及的一系列步骤

测试: 将已实施的系统与设计文档和需求规范进行比较，并生成验收报告

瀑布模型: 将数据库开发过程显示为严格的步骤序列，其中一个步骤的输出是下一个步骤的输入

瀑布过程: 识别数据库开发所需任务的一种方法，以及每个活动的输入和输出（参见瀑布模型）。

练习

描述瀑布模型。列出步骤。
SDLC的首字母缩略词是什么意思？SDLC描述了什么？
为了适应数据库设计，瀑布模型需要哪些修改？
提供数据库设计中涉及的迭代步骤。

归属

本节《数据库设计》（包括所有图像，除非另有说明）是开放大学的《数据库开发生命周期》的衍生作品，根据知识共享署名-非商业性使用-相同方式共享 3.0 许可证授权。

以下内容由 Adrienne Watt 撰写。

关键词
练习

参考文献

BCOpenCampus：数据库设计

← 规范化

数据库设计

数据库用户 →