|
引言：数据库设计 Step by Step (1)得到这么多朋友的关注着实出乎了我的意外。这也坚定了我把这一系列的博文写好的决心。近来工作上的事务比较繁重，加之我期望这个系列的文章能尽可能的系统、完整，需要花很多时间整理、思考数据库设计的各种资料，所以文章的更新速度可能会慢一些，也希望大家能够谅解。
系列的第二讲我们将站在高处俯瞰一下数据库的生命周期，了解数据库设计的整体流程。
大家对软件生命周期较为熟悉，数据库也有其生命周期，如下图所示。
数据库的生命周期主要分为四个阶段：需求分析、逻辑设计、物理设计、实现维护。 这个系列的博文将主要关注数据库生命周期中的前两个阶段（需求分析、逻辑设计），还会涉及反范式化设计的一些内容。如图中高亮圈出的部分。 数据库的物理设计，包括索引的选择与优化、数据分区等内容。这些内容也非常丰富，而且可以自成体系，园子里也有很多好文章，故在本系列中不作主要关注。本文最后将给出一些链接供大家参考。 数据库生命周期的四个阶段又能细分为多个小步骤，我们配合图（1）来看看每一小步包含的内容。 阶段1 需求分析 数据库设计与软件设计一样首先需要进行需求分析。 我们需要与数据的创造者和使用者进行访谈。对访谈获得的信息进行整理、分析，并撰写正式的需求文档。 需求文档中需包含：需要处理的数据；数据的自然关系；数据库实现的硬件环境、软件平台等；
阶段2 逻辑设计 使用ER或UML建模技术，创建概念数据模型图，展示所有数据以及数据间关系。最终概念数据模型必须被转化为范式化的表。 数据库逻辑设计主要步骤包括： a) 概念数据建模
b) 多视图集成
c) 转化概念数据模型为SQL表
d) 范式化
阶段3 物理设计 数据库物理设计包括选择索引，数据分区与分组等。 逻辑设计方法学通过减少需要分析的数据依赖，简化了大型关系数据库的设计，这也减轻了数据库物理设计阶段的压力。
数据库物理设计的目标是尽可能优化性能。 物理设计阶段，全局表结构可能需要进行重构来满足性能上的需求，这被称为反范式化。 反范式化的步骤包括：
阶段4 数据库的实现维护 当设计完成之后，使用数据库管理系统（DBMS）中的数据定义语言（DDL）来创建数据结构。 数据库创建完成后，应用程序或用户可以使用数据操作语言（DML）来使用（查询、修改等）该数据库。 一旦数据库开始运行，就需要对其性能进行监视。当数据库性能无法满足要求或用户提出新的功能需求时，就需要对该数据库进行再设计与修改。这形成了一个循环：监视 –> 再设计 –> 修改 –> 监视…。
这里只做一个提纲挈领的简介，大家可以根据相应的线索进行扩展。 表、行、列 关系数据库可以想象成表的集合，每个表包含行与列。（可以想象成一个Excel workbook，包含多个worksheet）。 表在关系代数中被称为关系，这也是关系数据库名称的起源（不要与表之间的外键关系混淆）。 列在关系代数中被称为属性（attribute）。列中允许存放的值的集合称为列的域（域与数据类型密切相关，但并不完全相同）。 行在关系代数中的学名是元组（tuple）。 关系数据库的理论基础来自于“关系代数”。但在关系代数中，一个集合的各个元组没有次序的概念，在关系数据库中为了方便使用，定义了行的次序。 键、索引 键是一种约束，目的是保证数据完整性
索引是数据的物理组织形式，目的是提高查询的性能 约束 基本约束
检查约束（Check Constraints）
主键约束（Primary Key Constraints）
唯一性约束（Unique Constraints） 外键约束（Foreign Key Constraints） 关系数据库操作
上述7种是最基本的关系数据库操作，对应于集合论中的关系运算。 有些书籍中还会加入改名（Rename），除（Divide）等关系操作。
1. 数据库生命周期的四个阶段：需求分析、逻辑设计、物理设计、实现维护。 2. 关系数据库的理论基础是关系代数。 数据库物理设计参考资料 第一个链接是我针对查询优化作的读书笔记，后三个链接是SQLServerCentral中几篇关于索引的文章（需要简单注册后才能看到全文） 1. 查询优化系列（查询优化（1），查询优化（2），查询优化（3），查询优化（4），查询优化（5）——总结） 2. Part 1 - The basics of indexes |
|
|
