《Web程序设计——ASP.NET项目实训》 - 蒋冠雄叶晓彤戴振中沈士根 - 清华大学出版社 - 香港大書城

	登入帳戶　 \|　訂單查詢　 \|　購物車/收銀台(0)　\|　在線留言板　 \|　付款方式　 \|　運費計算　 \|　聯絡我們　 \|　幫助中心　\|　加入書簽
		會員登入新用戶登記

HOME

新書上架

暢銷書架

好書推介

2023年度TOP

臺灣用戶

品種：超過100萬種各類書籍/音像和精品，正品正價，放心網購，悭钱省心

服務：香港／台灣／澳門／海外

送貨：速遞／郵局／服務站

新書上架：簡體書繁體書
暢銷書架：簡體書繁體書
好書推介：簡體書繁體書

『簡體書』Web程序设计——ASP.NET项目实训

書城自編碼： 3000914
分類：簡體書→大陸圖書→教材→研究生/本科/专科教材
作者：蒋冠雄叶晓彤戴振中沈士根
國際書號(ISBN)： 9787302466642
出版社：清华大学出版社
出版日期： 2017-06-01
版次： 1 印次： 1
頁數/字數： 403/631000
書度/開本： 32开釘裝：平装

售價：HK$ 71.1

我要買件

** 我創建的書架 **
未登入.

新書推薦：

《岁月待人归：徐悲鸿自述人生艺术》
售價：HK$ 61.4

《女人的中国医疗史：汉唐之间的健康照顾与性别》
售價：HK$ 103.8

《资治通鉴熊逸版：第四辑》
售價：HK$ 470.8

《中国近现代名家精品——项维仁：工笔侍女作品精选》
售價：HK$ 66.1

《宋瑞驻村日记（2012-2022）》
售價：HK$ 115.6

《汗青堂丛书138·帝国的切口：近代中国口岸的冲突与交流（1832-1914）》
售價：HK$ 127.4

《人世事，几完缺 —— 啊，晚明》
售價：HK$ 115.6

《樊树志作品：重写明晚史系列（全6册崇祯传+江南市镇的早期城市化+明史十二讲+图文中国史+万历传+国史十六讲修订版）》
售價：HK$ 498.0

建議一齊購買：

HK$ 83.3
《ASP.NET数据库网站设计教程（C#版）》

HK$ 115.1
《Web程序设计：ASP.NET实用网站开发》

編輯推薦：

书中每个项目都按照小型敏捷软件开发的思想，介绍了需求分析、功能设计、界面设计、数据库设计、系统架构搭建以及功能实现等整个过程所需要的思考方法和知识运用技巧。这三个案例从简单到复杂，所需要的知识和技能层层递进，形成一条螺旋式上升的学习路径。本书适合作为高等院校计算机相关专业的Web程序设计、网络程序设计、数据库原理与应用等课程的项目实训教材，也适合对Web软件开发有兴趣的人员自学使用。

內容簡介：

本书是《Web程序设计ASP.NET实用网站开发（第2版）》的配套项目实训教材，全书将带领读者开发完成小明音乐库管理系统企业KPI查询系统和小明电器商城三个完整的Web软件项目。
每个项目都按照小型敏捷软件开发的思想，介绍需求分析、功能设计、界面设计、数据库设计、系统架构搭建以及功能实现等整个过程所需要的思考方法和知识运用技巧。这三个案例从简单到复杂，所需要的知识和技能层层递进，形成一条螺旋式上升的学习路径。
书中内容紧密围绕案例展开，按实用的角度编排，读者宜将学习重点放在软件开发思路上，另外，还应该掌握通过网络快速获取知识的能力。为方便教师教学和读者自学，本书提供了完整的案例源代码和素材。
本书仅要求读者具备面向对象程序设计的基础，对于项目所用编程知识、数据库技术都有详细讲解，适合作为高等院校计算机相关专业的Web程序设计网络程序设计数据库原理与应用等课程的项目实训教材，也适合对Web软件开发有兴趣的人员自学使用。

第1篇小明音乐库管理系统
第1章需求分析和设计3
1.1 需求分析3
1.2 概要设计4
习题18
第2章 Web界面开发10
2.1 编写页面10
2.2 发布网站16
2.3 实现首页22
习题231
第3章数据库设计33
3.1 数据库基本概念33
3.2 概念模型34
3.3 数据模型39
习题346
第4章创建并访问数据库47
4.1 准备工作47
4.2 定义数据49
4.3 查询数据55
习题464
第5章实现前台页面66
5.1 连接数据库66
5.2 修改首页布局69
5.3 实现首页音乐列表73
5.4 实现动态音乐列表75
5.5 实现动态详细资料页78
5.6 发布MPMM网站81
习题583
第6章实现后台管理85
6.1 界面设计85
6.2 数据更新功能90
6.3 音乐分类管理93
6.4 音乐资料管理101
习题6114
第2篇企业KPI查询系统
第7章需求分析和设计121
7.1 需求分析121
7.2 概要设计123
习题7125
第8章 Web界面设计和实现126
8.1 界面详细设计126
8.2 实现登录页面布局129
8.3 实现母版页布局136
习题8140
第9章数据库设计143
9.1 概念模型设计143
9.2 逻辑模型设计146
9.3 三级模式结构设计150
习题9155
第10章系统设计和实现158
10.1 数据库实施158
10.2 系统架构164
10.3 用户登录和权限174
习题10187
第11章实现管理功能190
11.1 指标管理190
11.2 部门指标管理203
11.3 采集指标列表215
11.4 指标数据明细222
习题11232
第12章高级Web界面开发235
12.1 数据分析模块235
12.2 JavaScript基础240
12.3 实现日期输入245
12.4 jQuery基础249
12.5 实现指标走势图258
习题12265
第3篇小明电器商城
第13章需求分析271
13.1 背景271
13.2 业务流程分析271
13.3 用例分析273
习题13275
第14章系统设计276
14.1 功能模块设计276
14.2 界面设计277
14.3 系统架构281
习题14283
第15章数据库管理284
15.1 数据库设计284
15.2 数据库实施288
15.3 数据库可编程性291
15.4 数据库保护295
习题15302
第16章系统实现305
16.1 搭建系统架构305
16.2 实现管理员后台317
16.3 实现业务后台335
习题16353
第17章完成系统356
17.1 前台浏览页面356
17.2 购物车模块362
17.3 我的商城377
17.4 分组统计分析389
习题17396
附录部分习题参考答案398

內容試閱：

传统的高校专业培养方案是将整个专业人才培养过程按照科目分解为一门一门的课程进行教学，而每一门课程的内容再按照知识的相关性组织成章节，学生依次学习各章节的内容，从而掌握这门课的内容，有时也会通过一些涉及多个章节的练习来掌握一些综合知识。其组织方式类似于生产线工艺专业化原则布局，可将其称为知识模块化组织方式。
通常来说，计算机软件开发类的课程所涉及的知识比较庞杂，其理论体系没有传统学科那么完备。以模块化的方式组织课程内容、开展课程教学，可以将庞杂凌乱的知识根据学习心理机制和认识、记忆规律组织起来，使其条理化。其最大的优势就在于知识传授效率的最大化。
但模块化组织方式最大的缺点在于学生缺少对整体框架的认识，停留在掌握知识的层面，而不会运用知识。例如，传统的Web开发技术课程内容通常按照HTML、CSS、ASP.NET（或者JSP等其他动态Web开发技术）、ADO.NET（或者其他数据库访问技术）、JavaScript等模块分别予以介绍和强化。经过反复训练，每个模块学生都可以掌握得很好，但面对一个具体的软件开发项目时，学生会觉得无从下手。
针对模块化组织方式的缺陷，人们提出了综合化或者项目化的组织方式。也就是首先设定一个课程的应用型目标，然后通过一个或多个应用项目，将相关的知识串联起来。学生的学习过程始终围绕着应用项目开展，通过项目的需要来驱动学习。这种方式不但可以让学生快速掌握知识，而且可以更好地运用所学的知识。
综合化组合方式的主要问题在于具体的实施，其中项目的设计水平直接决定了综合化组织方式的实际效果，在实践中常常会产生以下问题。
（1）综合性和实践性不足，无法从根本上解决学生对认识软件整体框架和完整开发过程的需求。
（2）受教学大纲的限制，为了能够覆盖大纲规定的内容，不得不设计一些脱离实际应用的内容。
本书的编写从内容的组织上来说采用了综合化的方式。为了避免综合化方式可能产生的问题，设计了由简单到复杂的三个软件项目，三个软件项目所覆盖的内容有部分重复，有部分不同，还有部分属于提高的关系。通过三个项目的有机结合，既保证了项目设计的合理性、综合性，又保证了内容的全面性。
由于开发一个Web应用软件，涉及软件工程Web程序设计和数据库原理与应用等方面的内容，这些内容从实践的角度看应该是互相融合、互相依赖的要能够开发一个真正的软件系统，必须同时交叉运用这些课程所涉及的内容。为此，将这些课程由纵向分割改变为综合交叉，具体的Web项目和内容组织如下表所示。

项目
内容分类
教学内容
实践作用分析

小明音乐库管理系统
软件工程

需求分析基本概念；
界面设计基本概念；
类图、活动图
需求分析和概要设计

Web程
序设计

HTML框架、常用标签；
网站发布和动态网站原理；
ASP.NET原理和基础；
Request对象和Response对象；
ASP.NET Literal控件
Web软件界面构造

数据库原
理与应用

数据库基本概念；
概念模型设计（ER图、类图）；
关系模型设计；
创建数据库表的SQL；
SELECT语句（单表、连接、嵌套）
数据库系统的基本概念；
数据库表的设计、创建、操纵

Web程
序设计

ADO.NET连接数据库、连接串；
DbCommand对象和DataReader对象的简单应用；
单表和主从表的CRUD操作
通过ADO.NET操纵数据库；
基本ASP.NET控件的使用

企业KPI查询系统
软件工程

角色用例分析；
功能模块设计；
界面设计
软件需求分析和概要设计

Web程
序设计

CSS和DIV页面布局；
ASP.NET母版页
软件系统界面实现技术

数据库原
理与应用

概念模型设计（类图、数据流图、数据字典）；
关系数据库理论基本概念；
范式理论和模式分解；
三级模式（索引和视图）；
数据库实施（用户和权限）
正确、合理的数据库模型

软件工程
Web程
序设计

三层架构概念；
UI、BLL和DAL的项目创建；
LINQ to SQL；
用户登录和身份验证；
网站状态管理（SessionState Cookie
HiddenFieldQueryString）
软件系统架构的概念和实践；
LINQ to SQL开发技术；
用户管理模块的实现；
Web应用状态管理的实现

Web程
序设计

GridView控件和数据绑定表达式；
状态管理的运用；
Visible属性控制；
TreeView树形控件
ASP.NET中的常用编程技巧

Web程
序设计

Javascript和DOM模型；
Javascript日期控件；
jQuery和jQuery日期控件；
MsChart控件和jqPlot图表插件
Web界面综合设计

续表

项目
内容分类
教学内容
实践作用分析

小明电器商城
软件工程

业务流程图；
功能模块图；
界面设计
熟悉软件分析和设计方法

Web程
序设计

CSS模板的应用；
完整的三层架构；
ASP.NET成员管理；
表单认证和角色控制
完善Web软件架构

数据库原
理与应用

数据库保护（触发器、事务、恢复）；
数据库并发控制（乐观并发控制）；
LINQ和SQL统计、SQL分组统计
数据库应用的综合实践

Web程
序设计

Repeater控件；
分页机制；
购物车
Web程序设计的综合实践

本书以VisualStudioExpress2013和SQLServer2012Express为开发平台，使用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年出版，经多次印刷，受到了众多高校和广大读者的欢迎，很多不相识的读者来邮件与我们交流并给出了宝贵意见，在此表示衷心感谢。
希望本书能成为初学者从入门到精通的阶梯。书中存在的疏漏及不足之处，欢迎读者批评指正，以便再版时改进。我们的邮箱是：cnjgx110@163.com。

编者
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-3MPMM实体类图和关联属性
图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-9MPMM的ER图
ER图和类图非常类似，可以认为类图是ER图的增强版，而且符合面向对象设计的思想，所以以后应该使用类图来设计概念模型。表3-1给出了ER图和类图的对照。
表3-1ER图和类图对照表

概念
ER图
类图
说明

实体

同样用矩形表示实体，但类图中，从上到下分为类名区、属性区和操作区三部分

属性

属性在ER图中用线连接到实体，在类图中直接放到属性区

联系

同样用连线表示实体间的联系。ER图在连线中放置一个菱形表示联系名；类图一般忽略联系名，并且提供更多的联系类型

多实
体联
系

多个实体的联系，如表示某音乐爱好者从某个商家购买了某件音乐资料。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音乐资料表

ID
名称
介质
出版
表演者
出版日
保存地

1
爱，不解释
CD
星外星唱片
张杰
2013-12-27
A-1-2

2
张学友私人珍藏
黑胶CD
广州市新时
代影音公司
张学友
2010-06-10
A-1-2

3
Today Is A Beautiful Day
BD
Supercell
初音未来
2014-03-20
借：张航渡

（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个术语在数据库中都是同一个概念

属性
属性
实体对象的属性，对应为列。同类型的实体对象具有相同的属性，对应元组的同一属性放在同一列

域
域
属性的取值范围

码
码
关系模型中强调码可能有多个，所以又叫候选码

实体型
关系模式
属性的排列顺序是无所谓的

实体集
关系
把实体集中的实体按二维表的格式排列起来，就是关系。实体集中实体无顺序关系，所以二维表的行顺序也无所谓

联系
关系
概念模型的联系也是通过关系来表示的

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

ID
Code
Name
Description

1
Lhy
灵魂乐
灵魂乐是一种结合了节奏蓝调和福音音乐的音乐流派

2
Ygy
摇滚乐
摇滚乐主要受到节奏布鲁斯、乡村音乐和叮砰巷音乐的影响发展而来。摇滚乐分支众多，形态复杂

3
mzcf
民族唱法
民族唱法是由中国各族人民按照自己的习惯和爱好创造和发展起来的歌唱艺术的一种唱法

表3-5音乐资料表Music

ID
Code
Name
Performers
PublishDate

1
Abjs
爱,不解释
张杰
2013-12-27

2
Zxysrzc
张学友私人珍藏
张学友
2010-06-10

3
tiabd
Today Is A Beautiful Day
初音未来
2014-03-20

注：表中省略了一些字段。
表3-6非数字化音乐表MediaMusic

ID
MeidaType
GoWhere

1
CD
A-1-2

2
黑胶CD
A-1-2

3
BD
借：张航渡

1）1对1
图1-9中数字化音乐和非数字化音乐都继承了音乐资料，这也是一种联系。而且这是1：1的联系，一个Music实体只会对应一个MediaMusic或DigitalMusic实体；一个MediaMusic或DigitalMusic实体也只会对应一个Music实体。多重性为1：1的联系，只需要在任意实体集中增加外键，保存对应实体的主键值即可。例如，在MediaMusic表中增加一列Music_Id即可表示出MediaMusic实体和Music实体之间的联系，如表3-7所示。
表3-7添加参照的非数字化音乐表

ID
MeidaType
GoWhere
Music_ID

1
CD
A-1-2
3

2
黑胶CD
A-1-2
1

3
BD
借：张航渡
2

根据表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添加参照的音乐资料表

ID
Code
Name
Performers
PublishDate
Category_ID

1
Abjs
爱，不解释
张杰
2013-12-27
2

2
Zxysrzc
张学友私人珍藏
张学友
2010-06-10
1

3
tiabd
Today Is A Beautiful Day
初音未来
2014-03-20
1

根据表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音乐资料分类表

ID
Category_ID
Music_ID

1
1
1

2
2
1

3
1
2

4
2
3

从表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

字段名
类型
属性
说明

ID
Int32
PK，IDENTITY
分类ID

Code
String 50
NULL
分类编码，用于快速录入

Name
String 250
NOT NULL
分类名称

Description
String 1000
NULL
分类的详细描述

表3-11音乐资料表Music

字段名
类型
属性
说明

ID
Int64
PK，IDENTITY
音乐资料ID

Code
String 50
NULL
音乐资料编码，用于快速录入

Name
String 100
NOT NULL
音乐资料名称

Authors
String 100
NULL
音乐资料作者名单

Performers
String 100
NULL
音乐资料表演者名单

Photo
String 1000
NULL
音乐资料图片文件所在的路径。如果为空，则表示用默认图片

Description
String 2000
NULL
音乐资料的详细介绍

PublishDate
Date
NULL
发表日期

Memo
String 500
NULL
备注

MediaType
String1
NOT NULL
媒体类别：0-文件、1-CD、2-DVD、3-BD、4-磁带

MediaFile
String1000
NULL
音乐资料数字化文件所在的路径。如果MediaType=0，则不能为空

GoWhere
String100
NULL
去向。保存地点或外借人

Category_ID
Int32
FK,NOT NULL
音乐资料所属的音乐分类ID

针对表中的内容说明以下几点。
（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：nB）0：nC）1：nD）1：1
3．E-R图中的联系可以与（）实体有关。
A）0个B）1个C）2个D）2个或以上
二、填空题
1．数据的数据库管理方式相对于文件管理方式来说，最大的区别是。
2．根据数据模型的发展，数据库技术可以划分为三个发展阶段：第一代的网状和层次数据库系统，第二代关系数据库系统，第三代以为主要特征的新一代数据库系统。
3．独立于计算机系统，只用于描述某个特定组织所关心的信息结构的模型，称为；直接面向数据库的逻辑结构的模型，称为。
4．若关系的某一属性组（或单个属性）的值能够唯一地标识一个元组，则称该属性组或属性为。
三、是非题
（）1．在数据库中空值用NULL表示，不同于0或空串，它表示值未知。
（）2．关系模型中，实体和联系的表示方法是统一的，都用关系来表示。
四、实践题
1．请设计一个图书馆数据库。此数据库中对每个借阅者保存读者记录，包括：读者号、姓名、地址、性别、年龄、单位。对每本书存有：书号、书名、作者、出版社。对每本被借出的书存有读者号、借出日期、应换日期。请画出类图，并根据类图完成关系模型的设计。
2．完成《个人通讯录》的概念模型，并将其转换成关系模型。

書城介紹　 \|　合作申請　\|　索要書目　 \|　新手入門　\|　聯絡方式　 \|　幫助中心　\|　找書說明　 \|　送貨方式　\|　付款方式	香港用户　 \|　台灣用户　\|　大陸用户　\|　海外用户

	megBook.com.hk
Copyright © 2013 - 2024 （香港）大書城有限公司　 All Rights Reserved.