描述
开 本: 32开纸 张: 胶版纸包 装: 平装-胶订是否套装: 否国际标准书号ISBN: 9787302466642丛书名: 21世纪高等学校计算机专业核心课程规划教材
每个项目都按照小型敏捷软件开发的思想，介绍需求分析、功能设计、界面设计、数据库设计、系统架构搭建以及功能实现等整个过程所需要的思考方法和知识运用技巧。这三个案例从简单到复杂，所需要的知识和技能层层递进，形成一条螺旋式上升的学习路径。
书中内容紧密围绕案例展开，按实用的角度编排，读者宜将学习重点放在软件开发思路上，另外，还应该掌握通过网络快速获取知识的能力。为方便教师教学和读者自学，本书提供了完整的案例源代码和素材。
本书仅要求读者具备面向对象程序设计的基础，对于项目所用编程知识、数据库技术都有详细讲解，适合作为高等院校计算机相关专业的“Web程序设计”“网络程序设计”“数据库原理与应用”等课程的项目实训教材，也适合对Web软件开发有兴趣的人员自学使用。
第1篇 小明音乐库管理系统
第1章 需求分析和设计 3
1.1 需求分析 3
1.2 概要设计 4
习题1 8
第2章 Web界面开发 10
2.1 编写页面 10
2.2 发布网站 16
2.3 实现首页 22
习题2 31
第3章 数据库设计 33
3.1 数据库基本概念 33
3.2 概念模型 34
3.3 数据模型 39
习题3 46
第4章 创建并访问数据库 47
4.1 准备工作 47
4.2 定义数据 49
4.3 查询数据 55
习题4 64
第5章 实现前台页面 66
5.1 连接数据库 66
5.2 修改首页布局 69
5.3 实现首页音乐列表 73
5.4 实现动态音乐列表 75
5.5 实现动态详细资料页 78
5.6 发布MPMM网站 81
习题5 83
第6章 实现后台管理 85
6.1 界面设计 85
6.2 数据更新功能 90
6.3 音乐分类管理 93
6.4 音乐资料管理 101
习题6 114
第2篇 企业KPI查询系统
第7章 需求分析和设计 121
7.1 需求分析 121
7.2 概要设计 123
习题7 125
第8章 Web界面设计和实现 126
8.1 界面详细设计 126
8.2 实现登录页面布局 129
8.3 实现母版页布局 136
习题8 140
第9章 数据库设计 143
9.1 概念模型设计 143
9.2 逻辑模型设计 146
9.3 三级模式结构设计 150
习题9 155
第10章 系统设计和实现 158
10.1 数据库实施 158
10.2 系统架构 164
10.3 用户登录和权限 174
习题10 187
第11章 实现管理功能 190
11.1 指标管理 190
11.2 部门指标管理 203
11.3 采集指标列表 215
11.4 指标数据明细 222
习题11 232
第12章 高级Web界面开发 235
12.1 数据分析模块 235
12.2 JavaScript基础 240
12.3 实现日期输入 245
12.4 jQuery基础 249
12.5 实现指标走势图 258
习题12 265
第3篇 小明电器商城
第13章 需求分析 271
13.1 背景 271
13.2 业务流程分析 271
13.3 用例分析 273
习题13 275
第14章 系统设计 276
14.1 功能模块设计 276
14.2 界面设计 277
14.3 系统架构 281
习题14 283
第15章 数据库管理 284
15.1 数据库设计 284
15.2 数据库实施 288
15.3 数据库可编程性 291
15.4 数据库保护 295
习题15 302
第16章 系统实现 305
16.1 搭建系统架构 305
16.2 实现管理员后台 317
16.3 实现业务后台 335
习题16 353
第17章 完成系统 356
17.1 前台浏览页面 356
17.2 购物车模块 362
17.3 我的商城 377
17.4 分组统计分析 389
习题17 396
附录 部分习题参考答案 398
传统的高校专业培养方案是将整个专业人才培养过程按照科目分解为一门一门的课程进行教学，而每一门课程的内容再按照知识的相关性组织成章节，学生依次学习各章节的内容，从而掌握这门课的内容，有时也会通过一些涉及多个章节的练习来掌握一些综合知识。其组织方式类似于生产线“工艺专业化”原则布局，可将其称为“知识模块化”组织方式。
通常来说，计算机软件开发类的课程所涉及的知识比较庞杂，其理论体系没有传统学科那么完备。以模块化的方式组织课程内容、开展课程教学，可以将庞杂凌乱的知识根据学习心理机制和认识、记忆规律组织起来，使其条理化。其的优势就在于知识传授效率的化。
但模块化组织方式的缺点在于学生缺少对整体框架的认识，停留在掌握知识的层面，而不会运用知识。例如，传统的Web开发技术课程内容通常按照HTML、CSS、ASP.NET（或者JSP等其他动态Web开发技术）、ADO.NET（或者其他数据库访问技术）、JavaScript等模块分别予以介绍和强化。经过反复训练，每个模块学生都可以掌握得很好，但面对一个具体的软件开发项目时，学生会觉得无从下手。
针对模块化组织方式的缺陷，人们提出了综合化或者项目化的组织方式。也就是首先设定一个课程的应用型目标，然后通过一个或多个应用项目，将相关的知识串联起来。学生的学习过程始终围绕着应用项目开展，通过项目的需要来驱动学习。这种方式不但可以让学生快速掌握知识，而且可以更好地运用所学的知识。
综合化组合方式的主要问题在于具体的实施，其中项目的设计水平直接决定了综合化组织方式的实际效果，在实践中常常会产生以下问题。
（1）综合性和实践性不足，无法从根本上解决学生对认识软件整体框架和完整开发过程的需求。
（2）受教学大纲的限制，为了能够覆盖大纲规定的内容，不得不设计一些脱离实际应用的内容。
本书的编写从内容的组织上来说采用了综合化的方式。为了避免综合化方式可能产生的问题，设计了由简单到复杂的三个软件项目，三个软件项目所覆盖的内容有部分重复，有部分不同，还有部分属于提高的关系。通过三个项目的有机结合，既保证了项目设计的合理性、综合性，又保证了内容的全面性。
由于开发一个Web应用软件，涉及“软件工程”“Web程序设计”和“数据库原理与应用”等方面的内容，这些内容从实践的角度看应该是互相融合、互相依赖的——要能够开发一个真正的软件系统，必须同时交叉运用这些课程所涉及的内容。为此，将这些课程由纵向分割改变为综合交叉，具体的Web项目和内容组织如下表所示。
续表
本书以Visual Studio Express 2013和SQL Server 2012 Express为开发平台，使用C#开发语言。为方便教师教学和读者自学，本书提供了配套的实例源代码、素材等，可到http://www.tup.com.cn下载。
本书仅要求读者具备面向对象程序设计基础，对于项目所用编程知识、数据库技术都有较详细的讲解，适合作为高等院校计算机相关专业的“Web程序设计”“网络程序设计”“数据库原理与应用”等课程的项目实训教材，也适合对Web软件开发有兴趣的人员自学使用。
本书第1～9章、第13～15章由蒋冠雄编写，戴振中编写第10～12章，叶晓彤编写第16、17章，全书由蒋冠雄和沈士根负责统稿。
本套系列图书《Web程序设计——ASP.NET实用网站开发》《Web程序设计——ASP.NET上机实验指导》第1版和第2版分别于2009年和2014年出版，经多次印刷，受到了众多高校和广大读者的欢迎，很多不相识的读者来邮件与我们交流并给出了宝贵意见，在此表示衷心感谢。
希望本书能成为初学者从入门到精通的阶梯。书中存在的疏漏及不足之处，欢迎读者批评指正，以便再版时改进。我们的邮箱是：[email protected]。
编 者
2017年3月
数据库设计
学习目标
- 了解ER图，掌握类图的绘制；
- 了解数据库模型、概念模型、数据模型三者之间的关系，了解数据结构、数据操作和完整性的概念；
- 掌握关系、元组、属性、码、域、分量、关系模式、主属性、非主属性等关系模型的概念；
- 了解概念模型和关系模型概念之间的对应关系，掌握将概念模型转换成关系模型的方法；
- 深刻理解关系模型表示联系的方法，深刻理解“主–从”记录的概念，深刻理解1对1、1对多、多对多的概念；
- 了解DB、DBMS、DBS的概念区别和联系，了解DBA的概念。
3.1 数据库基本概念
一个应用系统往往要处理大量数据，而数据绝大多数情况下需要保存到数据库中，为此首先需要掌握基本的数据库概念。
1．信息和数据
信息和数据是一对容易混淆的概念，要搞清楚两者之间的联系和区别。
信息（Information），指音信、消息、通信系统传输和处理的对象，泛指人类社会传播的一切内容。1948年，数学家香农在题为“通讯的数学理论”的论文中指出：“信息是用来消除随机不定性的东西”。这是一个针对人来说的一个概念。
数据（Data），是描述客观事物的符号，是计算机中可以操作的对象，是能被计算机识别，并输入给计算机处理的符号。数据不仅指数值（整数、实数等），还包括文字、声音、图像，甚至视频等。所以，数据是指计算机能够处理的各种符号，这是针对计算机来说的一个概念。
2．数据库
数据库、数据库管理系统和数据库系统是三个密切相关但又不同的概念。它们具有不同的英文缩写，应该熟悉它们的含义和英文缩写。
数据库（Database，DB），简单来说数据库就是数据的集合，但这个集合具有以下特点：① 结构性，数据按照一定的结构实现联系和组织；② 独立性，数据的逻辑结构和应用程序相互独立；③ 集中性，不同的用户或同一用户的数据集中在一起统一管理。
由此，可以给出数据库的定义如下：依照某种数据模型组织起来并存放在外存储器中的数据集合，对数据的操作由统一的软件进行管理和控制。
数据库管理系统（Database Management System，DBMS），就是负责对数据库进行集中管理和控制的软件系统。常见的数据库管理系统有SQL Server，MySql，Oracle，Access，DB2等。
数据库系统（Database System，DBS），是指引入数据库后的计算机系统，是一个综合体。一般认为数据库系统的构成包括数据库、数据库管理系统、数据库管理员、数据库应用系统以及计算机硬件。要分清楚DBS和DBMS的区别，后者仅仅是前者的组成部分。
DBS考虑了人的因素，也就是数据库管理员（Database Administrator，DBA）。总的来说，DBA负责全面管理和控制数据库系统。
3.2 概 念 模 型
需求分析阶段已经给出了数据结构的设计——类图，数据库的设计可以在此基础上进行细化，从而得到实体类图。实体类图也是类图，但其中的类都是实体类（也就是需要保存到数据库中的类），而且会增加一些和数据库存储相关的特性。接下来用VS创建MPMM的实体类图，然后学习相关的概念。
1．创建实体模型
打开前一章创建的MPMM解决方案，在解决方案资源管理器中右键单击MPMM，选择“添加→新建项”命令。在如图3-1所示的对话框中选择LINQ to SQL类，输入模型文件的名称MPMM.dbml，单击“添加”按钮，VS打开如图3-2所示模型设计界面。
图3-1 添加LINQ to SQL类对话框
图3-2 实体模型可视化设计界面
2．设计实体类
在如图3-2的界面中，从工具箱拖放两个Class图标到对象关系设计器中，修改实体类的名称、属性等设置，得到MPMM的实体类图，如图3-3所示，对比图1-9，看看有什么不同？
图3-3 MPMM实体类图和关联属性
图3-3中将Music、DigitalMusic和MediaMusic三个类组合成了一个Music类，没有考虑使用继承的概念。需要注意的是，实体类虽然合并了，但两类音乐资料的处理有所不同，这里通过MediaType属性来实现区分。通过MediaType属性的不同取值，例如CD、DVD、BD、磁带、文件……其中文件表示是数字化音乐。显然，Music类中的MediaFile属性只对于MediaType属性值为文件的音乐资料有效，而GoWhere属性只对其他音乐资料有效。
Category类和Music类之间的连线表示关联关系，选择该连线可以看到如图3-3中的关联属性，其中基数属性为“一对多”，这个基数又叫做多重性。图3-3中Category端多重性为1，表示1个Music实体关联1个Category实体，说明一件音乐资料可以属于某一个音乐分类；Music端多重性为“多”，表示1个Category实体可以关联0个或多个Music实体，说明一个音乐分类可以包含任意数量的音乐资料；这是典型的一对多关系，这种情况下就称Category类是主类，Music类是从类。在设计界面关联两个类时，需要从主类画到从类（单击工具箱的“关联”，然后用鼠标从主类拖到从类）。
一对多是常见的关联多重性，需要注意多重性是由业务需求确定的。例如，如果现实业务中，小明希望一件音乐资料可以同时属于多个音乐分类，那么Category类和Music类就是“多对多”的关系了。所以说业务决定设计，而不是设计决定业务。
另外，图3-3中关联的属性有一个名称为Category的父属性，这是一个特殊的属性，它用于记录一件音乐资料所属的音乐分类，是Music类和Category类之间关联关系的体现。实际上，Category类也拥有到Music类的子属性Music，而且这是一个集合属性（因为一个Category实体可以含有多个Music实体）。
后，还需要明确一些和数据库有关的特性定义。例如Music类的MediaType属性实际上应该是一个枚举型，因此定义MediaType属性的数据类型为int，如图3-4所示。
图3-4 属性MediaType的属性
在数据库中存放枚举型数据时通常保存代码而不是名称。因为代码更便于计算机进行检查、比较，名称相对来说比较随意，而MPMM系统是需要对类别进行操作的（例如，数字化音乐资料需要能够在线播放），所以定义MediaType属性的数据类型为int，并在MPMM设计文档中说明：“0-文件、1-CD、2-DVD、3-BD、4-磁带”。
也有直接保存类别名称的情况，此时，MediaType属性的类型应该是String。String类型的属性应该规定一个长度，长度不能太短，以免存放不下内容，但也不能太长，以免浪费存储空间，这里设置长度为20。当然，还必须在MPMM设计文档中明确说明：如果MediaType的值是“文件”，那么就是数字化音乐，可以在线播放。
显然，字符串的值会比较随意（如其他人会认为应该保存“文档”而不是“文件”），所以不推荐用于这种更适合用枚举类型的场景。
3．概念模型
实体类图主要反映了业务数据的特征，在数据库理论中称为概念模型。理解数据库概念模型和相关的概念可以避免设计出来的数据库缺少一些必要的内容，对于正确设计数据库是非常重要的。
概念模型又称概念数据模型、信息模型，是现实世界的业务在人们头脑中形成的反映，是人脑对业务的理解。需要注意的是，概念模型不仅仅是静态业务的反映，还要能够反映业务可能的变化。
实体Entity指客观存在并可相互区别的事物。建立概念模型时实体往往局限于业务对象。一般来说，同一类业务对象具有完全相同的特征，对应现实世界中的同一类事物，给这一类事物取一个名字，即实体名。例如，音乐库管理业务中的音乐资料，就是一类实实在在的事物，而且正是需要管理的事物。实体也可以对应抽象的事物，例如音乐分类，就是一类概念上的事物，但也是需要管理的事物。如图3-5所示为《Gamelot》的音乐资料实体。
注意，实体名代表的是同一类事物，它和具体的单个实体是不同的。例如，音乐资料是全体音乐资料的名称，而具体的单件音乐资料的名称则可能叫《爸爸去哪儿》。
属性Attribute指实体所具有的某种特性或特征。一个具体的实体，除了知道它是属于哪一类的实体外，往往还会希望掌握它的各种业务特性。例如，在MPMM中希望能够掌握一件音乐资料的“作品名称”“作者”“表演者”“出版年月”等，甚至可能还会关心它的“封面图片”“存放地点”，这些都是音乐资料实体的属性。
显然，同一类实体的属性应该是相同的，通常不严格区分某个实体和某类实体的属性，而统称为实体的属性，或简称属性。图3-6给出了音乐资料《Endlessly》的属性和取值。
图3-5 《Gamelot》的音乐资料实体 图3-6 某件音乐资料的属性和属性值
域Domain指属性的取值范围。注意不要混淆属性的域和数据类型，数据类型是计算机程序设计的概念。例如音乐资料的MediaType属性，数据库中可以用Int32数据类型来保存，取值范围是-2 147 483 648～2 147 483 647，但这个属性的域是{0，1，2，3，4}。
码（键）Key指标识实体的属性集。码、键、关键字，都是指一个或多个实体的属性，不同实体的这些属性值至少有一处是不同的；反之，如果实体的这些属性值全部相同，那么一定是同一个实体。例如每个中国公民都有一个身份证号码，在不考虑出错的情况下，通过身份证号码能够确定是哪个中国公民，所以身份证号码就是中国公民的关键字。
关键字在数据库中是非常重要的概念，下面是几个需要注意的地方。
（1）关键字可以是一个属性，也可以是多个属性的组合。如果是多个属性，则性是指多个属性值的组合具有性。因此关键字不是“一个字”，而可能是“多个字”。例如，音乐资料实体，{名称}不是关键字，但属性组合{名称，表演者，出版时间}就是关 键字。
（2）属性或属性组合是否是关键字，关键是有否可能出现重复值。只要理论上可能出现不的情况，该属性或属性组合就不能作为关键字。
（3）实际业务中，实体不一定有关键字。也就是说不管怎么组合都可能出现属性值完全相同，但实际上的确是不同实体的情况。例如某幼儿园，没有给小朋友们编学号，那么可能有两个小朋友在同一个班级，而且姓名、出生年月、性别都完全一样。这种情况下，设计数据库时往往会给实体增加一个计算机自动生成值的属性（通常叫Id）。为了处理方便，有些软件开发者会给每类实体都增加这样一个关键字。
（4）一类实体的关键字可以有多个，其中常用的关键字叫做主关键字。所谓常用由设计人员主观确定，并没有明确定义。实际操作中常常选择简单的那个关键字。
实体型指同类实体的抽象和刻画，用实体名加上属性集合来刻画，UML中叫做实体类。例如图3-3中的Music类，给出了实体名字Music，还给出了Music实体的属性清单（ID，Code，Name，…），这就定义了是从哪些角度来描述一件音乐资料的，但这并不是对具体某件音乐资料的描述。要正确区分“型—值”的关系，也就是UML中“类—对象”的关系。图3-7是音乐资料型的示意图。
实体集指同类实体的集合。实体集中是一个个具体的实体，体现在数据库中就是对一个个实体的描述，也就是每个实体属性的具体值。实体集中的实体当然是会变化的，但它们都是同一类的实体，都是一个实体类的不同实例对象。例如，某一个时刻，小明音乐库中有300件音乐资料，这就构成了一个音乐资料实体集。某天小明新买了一张CD，使得音乐库中的音乐资料增加到了301件，这就是另一个音乐资料实体集。图3-8是音乐资料集的示意图。
图3-7 音乐资料型的示意图 图3-8 音乐资料集示意图
联系这里是指实体集之间的联系。实体集的联系就是前面类图中提到的关联，只是类图可以表示不同类别的关联，从而更细致地表示不同情景的联系。
现实世界中很少存在没有任何联系的实体，所以联系是非常重要的概念，但也是常常被初学者忽略的概念，下面强调一下相关的注意事项。
（1）可以给联系取个名字便于称呼，例如音乐分类和音乐资料之间存在“属于”联系。
（2）所谓实体集之间的联系是指实体集中的实体之间可能会有的联系。例如一件音乐资料必然归入某个音乐分类，而某个音乐分类可能会包含若干件音乐资料，就可以说音乐分类和音乐资料之间存在着“属于”联系。这绝不是说任何音乐分类都和所有音乐资料之间存在这个联系。
（3）联系可能有很多，设计时只关注那些需要管理的联系。例如，小明和音乐资料之间存在着“管理”联系，但MPMM系统面向小明单个用户，因此没有必要关心这个联系。如果设计一个允许多人使用的系统，那音乐资料和管理者之间的管理联系就会变成必需 的了。
（4）联系一般发生在两个不同的实体集之间，但也可以发生在多个实体集之间，甚至发生在同一个实体集中（参照前述“注意事项（2））”，就不难理解这个道理）。例如，这件音乐资料是张三从新华书店买来的，“买来”这个联系就涉及音乐资料、人和商店三类实体。进一步，如果音乐分类是分级的（如港台歌曲下面又分成男歌手、女歌手、组合），那么音乐分类存在一个到本身的“上级”联系，表示某个分类是属于另一个分类的下级分类。
（5）联系具有多重性，多重性主要有1对1、1对多和多对多三类，分别简记为1:1、1:n和n:m。
4．ER图和类图
传统数据库设计经常使用实体关系（Entity-Relationship，ER）图来描述实体和联系，图3-9是MPMM的ER图。
从图3-9中可以看到，ER图用矩形表示实体型，如“音乐资料”和“音乐分类”。用椭圆表示实体属性，用无向边将其与实体型连接起来，如“名称”“作者”等。用菱形表示实体型之间的联系，用无向边分别相应的实体型连接起来，如音乐资料“属于”音乐分类；同时在无向边旁标上联系的多重性，如一件音乐资料属于一种音乐分类，而一种音乐分类可以包含多件音乐资料，所以这是1:n型。
图3-9 MPMM的ER图
ER图和类图非常类似，可以认为类图是ER图的增强版，而且符合面向对象设计的思想，所以以后应该使用类图来设计概念模型。表3-1给出了ER图和类图的对照。
表3–1 ER图和类图对照表
3.3 数 据 模 型
1．数据库系统
概念模型的作用就是帮助理解软件系统将要管理的数据和数据间的联系，但计算机并不能够直接管理概念模型，开发人员必须找到一种方法实现相应的数据管理。
软件发展的早期，程序员直接将数据存储在文件中，通过自行编程的方式实现数据处理。随着计算机技术的发展，出现了专门负责数据管理的软件系统，也就是数据库系统。数据库相对于文件来说，的区别就是数据库中的数据是有结构的，而且数据库系统提供了一系列的操作功能来实现对数据和结构的处理，因此可以用数据库系统提供的功能来非常方便地实现数据管理。
2．数据库模型
数据库系统提供的数据结构以及其上的操作功能，决定了使用数据库实现概念模型的能力，决定了操作数据的效率。那么数据库系统提供了什么样的数据模型呢？这个数据模型好用吗？为此，需要掌握数据模型的概念。
数据模型：是数据与数据间逻辑联系的表示形式。一般应从系统的静态结构、动态特性和完整性约束条件三个方面进行说明。 静态结构就是前面所说的实体、属性和实体间的联系等方面的内容；动态特性是数据变化方面的描述；而完整性约束条件是关于数据正确性方面的规定。
数据模型根据面向的领域，可以分为概念模型和逻辑模型。
- 概念模型：前一节进行了详细介绍，也可以叫做概念数据模型、信息模型，是面向客观世界、面向用户的模型，主要用于数据库设计。
- 逻辑数据模型：有时候所谓的数据模型就仅指逻辑数据模型，是面向计算机系统的模型，主要用于数据库实现。
一个好的数据模型，可以方便地实现各种概念模型，包括静态结构、业务操作和完整性约束，也就是数据模型的三个构成要素。
（1）数据结构：研究对象的集合及联系。它是数据模型的基础，是对系统静态特性的描述。《数据结构》中的集合、线性表、矩阵、树、图等都是可以考虑的数据结构，不同的数据结构能够实现概念模型的能力也不同。
（2）数据操作：所研究对象（实体、属性、联系）上的操作及其所应该遵守的规则，它是对系统动态特性的描述。数据操作是由概念模型所对应的业务规则决定的，基本的操作包括创建（Create）、删除（Delete）、修改（Update）和查询（Retrieve）。通常可以用上述英文单词的首字母来表示相应的操作，例如CRUD表示上述4个操作，CUD表示除查询以外的其他3个操作……
（3）完整性约束条件：在数据操作过程中，可能出现不合逻辑的情况，这是不允许的，数据的正确性通过完整性约束条件来控制。所谓数据模型上的完整性约束条件，也就是规定数据正确性、有效性、相容性的规则集合。完整性由业务逻辑来确定，例如同样是音乐资料的出版年月，如果介质类型是CD，那就不可能早于1980年（因为CD是1980年才推出的），但如果是密纹唱片的出版年月就可以了。数据库系统不可能提供所有完整性约束条件的管理能力，因此除了基本完整性定义以外，往往要靠软件开发人员通过编程来进行控制。
3．关系模型
前面已经完成了MPMM概念模型设计，接下来是设计数据模型。设计数据模型，也就是将概念模型转换成数据模型。
既然是基于数据库系统来实现数据管理，那就必须根据数据库系统所支持的数据结构来进行转换。目前常用的数据库为关系数据库，本节介绍如何把概念模型转换成关系模型。首先学习几个重要的关系模型概念。
（1）关系（Relation）：把一张二维表称为一个关系。注意，关系在这里就是一个术语而已，和它的字面意思没有什么联系。例如表3-2是一张音乐资料的二维表，就是一个关系。
表3–2 音乐资料表
（2）元组（Tuple）：表中的一行。例如，表3-2中有3个元组。
（3）属性（Attribute）：表中的一列。例如，表3-2中有ID、名称、……、保存地，共7个属性。
（4）码（Key，候选码）：表中的某个属性（组），它的值可以确定一个元组。
（5）域（Domain）：属性的取值范围。
（6）分量：元组中的一个属性值。
（7）关系模式：对关系结构的描述。通常表示形式为“关系名（属性名1，属性名 2，……，属性名n）”。例如，表3-2的关系模式为“音乐资料（ID，名称，介质，出版，表演者，出版日，保存地）”。
（8）主属性：包含在任意候选码中的属性。
（9）非主属性：不包含在所有候选码中的属性。
对比概念模型中介绍的术语，可以看到两者具有清晰的对应关系，互相之间的转换关系如表3-3所示。
表3–3 概念模型和关系模型转换表
4．关系操纵和完整性
关系模型支持的基本操作就是CRUD，即增加、查询、更新和删除。但关系模型支持的这4种操作都是集合操作，也就是说可以一次性增加、查询、更新或删除多条记录。
关系模型的集合操作给操作数据带来了很大的便利，目前主流的程序语言都支持直接对关系数据库进行集合操作，不过程序语言对数据操作的模式通常仍是逐条进行的，开发人员需要通过循环来实现两者之间的转换。
为了保证操作结果的正确性，关系模型也提供了完整性约束条件，包括实体完整性、参照完整性和用户自定义完整性，所谓完整性不妨先简单地理解为正确性。为了能将概念模型正确地转换成关系模型，还需要学习几个重要的概念。
空值：数据库中用NULL表示空值，它的含义是“没有值”或“不知道”，适用于所有数据类型。许多语言中都有null的概念，但通常仅用于“指针”或“引用”数据类型。不要混淆null和0或者字符串“NULL”，NULL就像布尔型的true、false一样，是一个值。
实体完整性：实体完整性要求每一个表中的主键（主关键字的简称）字段都不能为空或出现重复值。例如，假设音乐资料表的主键定为{名称，表演者，出版时间}，那么对于表中任何一条记录，这3个字段值每一个都不能为NULL；对于表中任意两条记录，这3个字段值（综合起来）不能重复。实体完整性的检查范围是实体集内用于保证一个实体的数据是正确的。作为主关键字，用于确定一个实体，其值不为空且不重复是基本的要求。所以，对于绝大多数的数据库系统，这个完整性是强制执行的。
外码（外键）：如果一个关系中含有某个关系主键对应的属性（组），则称这个属性（组）为外码。外码实际上就是用来表示实体间关系的属性，因为根据外码的值可以确定这条记录关联的其他实体。
参照完整性：关系中的外码取值除非（都）为NULL，否则在被参照关系中必须存在相同主键值的元组。参照完整性的检查范围涉及两个实体集，用于保证一个实体的关联实体是存在的。这个完整性通常数据库系统也是强制执行的。因此，当删除“主实体”（被参照实体）时有两个选择：要么把所有“从实体”（参照主实体的实体）外键取值设为NULL，要么把所有“从实体”也一起删除（称为级联删除）。如果两个选择都不选，那么在存在“从实体”的情况下就不允许删除“主实体”（称为拒绝删除）。
自定义完整性：用户自定义完整性指针对某一具体关系数据库的约束条件，它反映具体业务对数据的要求。数据库系统通常会提供一些自定义完整性的工具，例如索引、默认值等，但无法满足所有可能的业务完整性要求。因此自定义完整性需要开发人员自己编写代码来实现。
由于数据库系统强制执行实体完整性和参照完整性，有些开发人员在设计数据库时通过不定义主键和参照的方法来绕过数据库系统的这个机制。但这并不是说此时就没有完整性的概念了，这只是将维护完整性的任务完全交给了开发人员自己。这种做法在得到了灵活性的同时增加了出错的风险，像这种普遍的、基本的完整性应该交给数据库系统去 负责。
5．用关系表示联系
从表3-3中可以看到，关系模型中，实体和联系的表示方法是统一的，都用关系来表示。这样一来，的好处是把实体和联系的操作方法也统一起来了，操作联系就和操作实体一样方便。这是关系模型的突出优点之一。
那么，怎么用关系来表示联系呢？其实，前面介绍参照完整性和外码时已经给出了答案，下面以图1-9为例，针对不同的关联多重性说明联系的表示方法。首先给出图中几个类对应的关系，例如表3-4、表3-5和表3-6所示。其中，为了后续管理和软件开发方便，为每个关系添加了一个名为Id的主键。
表3–4 音乐分类表Category
表3–5 音乐资料表Music
注：表中省略了一些字段。
表3–6 非数字化音乐表MediaMusic
1）1对1
图1-9中“数字化音乐”和“非数字化音乐”都继承了“音乐资料”，这也是一种联系。而且这是1:1的联系，一个Music实体只会对应一个MediaMusic或DigitalMusic实体；一个MediaMusic或DigitalMusic实体也只会对应一个Music实体。多重性为1:1的联系，只需要在任意实体集中增加外键，保存对应实体的主键值即可。例如，在MediaMusic表中增加一列Music_Id即可表示出MediaMusic实体和Music实体之间的联系，如表3-7所示。
表3–7 添加参照的非数字化音乐表
根据表3-7中的记录，ID=1的MediaMusic实体其Music_ID=3，查表3-5可知其对应的Music实体为《Today Is A Beautiful Day》。反过来，对于Id=1的Music实体《爱，不解释》，在表3-7中查找可知Music_ID=1的行，媒体类型为“黑胶CD”，保存在“A-1-2”这个柜子里面。所以，通过在MediaMusic表的Music_Id外键保存Music表的主键值，实现了两张表之间的联系。
当然，通过在Music表中增加MediaMusic_Id外键，记录MediaMusic表的主键值，也可以实现两张表之间的联系。但考虑到Music表和DigitalMusic表之间也存在相同的联系，在MediaMusic表中记录这个联系会方便一些。
后，对于1:1的情况，由于实体之间是一一对应的，所以两张表可以合并成一张，在图3-3中就是这样设计的。
2）1对多
图1-9中Category类和Music类之间是典型的1:n的联系。由于和一个Category实体存在联系的Music实体数量不确定，因此无法确定Category表到Music表的外键数量，但可以确定Music表到Category表外键数量就是1个。所以，对于1:n的情况，应该在“从实体”表中增加外键，保存对应“主实体”的主键值。例如，在Music表中增加Category_Id字段，如表3-8所示。
表3–8 添加参照的音乐资料表
根据表3-8中的记录确定实体之间的关系和1:1的情况基本相同，只是1个Category实体所对应的Music实体应该是一个集合，而不是单条记录。
对于1:n的情况，初学者可能会认为也可以将两张表合并成一张：也就是直接把Music实体中对应的Category实体信息保存在Music记录中。表面上看也可以达到相同的目的，但实际上存在很大的问题，本书下一篇中会对这个问题进行详细讨论。
3）多对多
假设允许将一件音乐资料同时归入某几个音乐分类，此时两者之间就成了n:m的联系，即一个Category实体可以包含多个Music实体，同时一个Music实体也可以属于某几个Category实体。这样，既无法确定Category表到Music表的外键数量，也无法确定Music表到Category表的外键数量。
这种情况下，需要单独为两者之间的联系定义一张表，表中同时保存到Music表和Category表的两个外键，如表3-9所示。
表3–9 音乐资料分类表
从表3-9中可以知道，Music_ID=1的《爱，不解释》同时属于Category_ID=1灵魂乐和Category_ID=2摇滚乐两个音乐分类。和1:n的情况相同，n:m的情况也不能将其合并到一张实体表中。
关系模型统一用“关系”解决了表示联系的问题。实际上，用一张独立表来表示各种联系都是可行的，而且如果有联系自己的属性时，只要在联系表中增加相应的字段即可。
多个实体之间的联系比两个实体间联系的多重性要复杂得多，但万变不离其宗，如何用关系来表示多实体间的联系留给读者思考。
6．MPMM关系模型
将图3-3的概念模型转换成关系模型，只需要两张表，具体设计说明如表3-10和表3-11所示。
表3–10 音乐分类表Category
表3–11 音乐资料表Music
针对表中的内容说明以下几点。
（1）类型列。该字段的数据类型，考虑到不同DBMS支持的数据类型各不相同，这里的数据类型采用了C#语言中的名称。对于有长度限制的字段，数据类型的括号中补充说明了该字段的长度。数据类型的选择受业务逻辑和DBMS两者的限制，要选择合理（效率高、空间小、满足需求）的类型。
（2）属性列。该字段的补充规范，主要有PK——主键，IDENTITY——自增长， FK——外键，NULL——允许为空，NOT NULL——不允许为空。
（3）ID字段。每张表都设置了一个ID字段作为主键。该字段的要求就是不能重复，为此采用由数据库自动生成的方式。
（4）Category_ID字段。该字段为音乐资料表到音乐分类表的外键，在图3-3的概念模型中并没有这个字段。这个字段是概念模型中两个实体间联系在关系模型中的体现，因为模型中规定了该联系是1:*的，也就是一件音乐资料必须属于某个音乐分类，所以该外键不允许为空。
（5）MeidaType字段。虽然MediaType字段值看上去像整数，但该值是无须进行数值计算的。其字段类型用1位长度的字符串既能够满足要求，又能够节省空间，还可以避免被当作数值进行运算处理。
使用表格的方式来描述数据模型的好处是可以准确地描述模型细节，方便创建数据库，缺点是实体间的联系不直观。更理想的做法是同时给出关系表格和关系图。
习 题 3
一、选择题
1．下面哪个不是数据模型的三要素之一（ ）。
A）数据结构 B）数据操作 C）逻辑结构 D）完整性约束条件
2．设有部门和职员两个实体，每个职员只能属于一个部门，一个部门可以有多名职员，则部门与职员实体之间的联系类型是（ ）。
A）m:n B）0:n C）1:n D）1:1
3．E-R图中的联系可以与（ ）实体有关。
A）0个 B）1个 C）2个 D）2个或以上
二、填空题
1．数据的数据库管理方式相对于文件管理方式来说，的区别是 。
2．根据数据模型的发展，数据库技术可以划分为三个发展阶段：代的网状和层次数据库系统，第二代关系数据库系统，第三代以 为主要特征的新一代数据库系统。
3．独立于计算机系统，只用于描述某个特定组织所关心的信息结构的模型，称为 ；直接面向数据库的逻辑结构的模型，称为 。
4．若关系的某一属性组（或单个属性）的值能够地标识一个元组，则称该属性组或属性为 。
三、是非题
（ ）1．在数据库中空值用NULL表示，不同于0或空串，它表示“值未知”。
（ ）2．关系模型中，实体和联系的表示方法是统一的，都用关系来表示。
四、实践题
1．请设计一个图书馆数据库。此数据库中对每个借阅者保存读者记录，包括：读者号、姓名、地址、性别、年龄、单位。对每本书存有：书号、书名、作者、出版社。对每本被借出的书存有读者号、借出日期、应换日期。请画出类图，并根据类图完成关系模型的设计。
2．完成《个人通讯录》的概念模型，并将其转换成关系模型。
评论
还没有评论。