Computer Science · An Overview · Chapter 9
数据库系统DATABASE SYSTEMS
数据库是把大量数据转化成抽象工具的系统——用户以简便的方式搜索和提取相关的信息项。本章讨论数据库这个主题，还将讨论与数据挖掘相关的领域和传统的文件结构。
数据库是把大量数据转化成抽象工具的系统——用户以简便的方式搜索和提取相关的信息项。本章讨论数据库这个主题，还将讨论与数据挖掘相关的领域和传统的文件结构。
每节末尾附「本节小结」与 2 道课堂选择题（A / B / C / D），共 14 题，参考答案见页尾。一条主线：数据库系统应用抽象，把大型数据集合转换为有用的信息源。
| 小节 | 核心问题 | 关键概念 |
|---|---|---|
| 9.1 数据库基础 | 为什么要用数据库而不是分散的文件？ | 多维数据集合 · 模式/子模式 · DBMS · 数据库模型 |
| 9.2 关系模型 | 数据怎样存成“表格”并被查询？ | 关系/元组/属性 · 无损分解 · SELECT/PROJECT/JOIN · SQL |
| 9.3 面向对象数据库 | 对象范型如何与数据库结合？ | 对象间的链接 · 持久对象 persistent |
| 9.4 维护数据库完整性 | 多用户并发下如何防止数据出错？ | 事务 · 提交/回滚 · 日志 · 共享锁/独占锁 |
| 9.5 传统文件结构 | 数据库技术从哪儿演变而来？ | 顺序文件 · 索引文件 · 散列 hash |
| 9.6 数据挖掘 | 如何从数据里发现未知的模式？ | 数据仓库 · 类描述/辨别 · 聚类/关联/离群/时序 |
| 9.7 社会影响 | 数据库技术带来哪些伦理问题？ | 数据收集 · 隐私 · 法律与舆论 |
数据库 database：多维的数据集合——之所以说多维，是因为通过数据项之间的内部链接，可以从不同的角度获取信息。数据库旨在高效处理大量数据，同时提供数据的一致性、安全性和完整性。
面向文件：客服部管客户记录、薪资部管工资记录、人事部管雇员记录……各部门各自维护文件——数据重复、不一致，难以汇总决策。
面向数据库：所有部门共享一个集成的数据库——这种信息集成池提供的有价值的资源，可以支持管理层做出决策。
元数据 metadata：关于其他类型数据的信息——可以是关于图像、网页或其他复杂对象的描述性数据。
元数据通过提供数据各方面的附加信息，增加数据或数据集的有效使用。例：照片的EXIF 信息（拍摄时间、相机型号）就是元数据。
模式 schema：整个数据库结构的一个描述，数据库系统用模式来维护数据库。
子模式 subschema：只是与特定用户需求相关的那部分数据库的描述——让不同用户访问不同信息，是管理敏感信息使用权的有用工具。注意：非常大型的动态分布式数据库在实践中很难完全保护。
分层视角：用户 → 应用软件 → 数据库管理系统（DBMS）→ 实际的数据库。应用软件并不直接操纵数据库，实际操纵者是 DBMS——每个软件层都从自己的抽象视角看待数据。
数据库模型 database model：组织和管理数据的结构、操作与关系的框架。寻找更好模型的工作永无止境：让复杂系统容易概念化、请求表达简明、DBMS 高效。
数据库 = 多维的数据集合，内部链接让信息可从多角度获取；数据库把分散文件整合成“信息集成池”支持管理决策。模式描述整个数据库，子模式描述特定用户可见的部分——既共享数据又控制访问；元数据是关于数据的数据。应用软件不直接操纵数据库，DBMS 是中间的实际操纵者。一句话：文件各管各的，数据库大家共享——集成带来价值，也带来访问控制的需求。
关系模型 relational model：数据存储在类似电子表格的表格中，这些表格称为关系 relation——E.F.Codd 于 1970 年提出，利用数学中的集合论和关系代数管理数据，成为数据库设计的主流模型。
关系中的一行称为一个元组 tuple——表示一个实体的记录；一列称为属性 attribute——描述对应实体的特征。
例：EMPLOYEE 关系中，一行 = 一名员工（EmplId、Name、Address、SSNum 四个属性）。
设计关系数据库的关键步骤是设计构成数据库的关系。把一个关系分解成几个较小的关系时，信息有时丢失、有时不丢失。
不丢失信息的分解称为无损分解 lossless decomposition——目标：找出会引发问题的关系特征（如冗余），并重组消除它们。
| 关系运算 | 作用 | 例子 |
|---|---|---|
| SELECT | 从一个关系中提取行（选满足条件的元组） | NEW ← SELECT from EMPLOYEE where EmplId='34Y70' |
| PROJECT | 从一个关系中提取列 | MAIL ← PROJECT Name, Address from EMPLOYEE |
| JOIN | 按条件把两个关系的元组拼接成一个新关系 | 新关系的属性 = 原来两个关系的属性之和 |
SELECT EmplId, Dept FROM Assignment, Job WHERE Assignment.JobId = Job.JobId AND Assignment.TermDate = '*'
每条 SQL 查询 = 三条子句 SELECT + FROM + WHERE，本质 = 先对 FROM 中的关系做 JOIN，再按 WHERE 条件做 SELECT，最后对 SELECT 列出的列做 PROJECT。SQL 是陈述性语句——描述“要什么”而不是“怎么做”，应用程序员不必为开发处理关系的算法花费精力。
关系 = 表格；行 = 元组，列 = 属性；设计关系是建库的关键步骤，分解要追求无损。SELECT 提取行，PROJECT 提取列，JOIN 按条件拼接两个关系——运算结果都是新关系；SQL 是陈述性语句，把三条子句翻译成 JOIN→SELECT→PROJECT 的组合。一句话：陈述“要什么”而不是“怎么做”——这就是 SQL 的解放。
对象范型与数据库结合：数据库由对象构成，对象之间用链接表示关联——员工数据库可以由三个类（对象类型）构成：Employee、Job 和 Assignment。
对象之间的链接由 DBMS 维护：新增对象时，应用软件只需指明它应该链接到哪些对象，DBMS 会创建所需的链接系统（例如用类似链表的方式把一个员工的多个 Assignment 串起来）。
普通面向对象程序中的对象是短暂的 transient：程序终止就被丢弃。加入数据库的对象必须在创建它的程序终止后仍然保存——称为持久的 persistent。创建持久对象是对常规的显著突破。
面向对象的方法允许整个软件系统（应用软件 + DBMS + 数据库本身）在同一个范型下设计——这与历史上的常见做法形成对比：用命令式语言开发的应用软件去查询关系数据库，两种范型之间存在固有的冲突。
面向对象数据库：数据 = 对象，关联 = 对象间的链接，链接由 DBMS 维护（可类似链表实现）；数据库中的对象是持久的——程序终止后仍被保存；同一范型贯穿整个系统是最大卖点。一句话：顺着链接找对象——关系靠表格连接，对象靠指针相连。
个人用的小型数据库出错了还能手动补救；大型多用户商用数据库中，数据出错或丢失的代价巨大——DBMS 的重要角色：防止事务只做了一半、或事务之间相互干扰。
一个事务 transaction（如转账：一个账户减、另一个账户加）在数据库层面涉及多个步骤，中间状态可能不一致。DBMS 把每个事务的活动先记入日志 log（非易失存储）。
所有步骤都记录完毕的时刻叫提交点 commit point——此后 DBMS 负责保证事务生效；提交点之前出故障，则用日志回滚 roll back 撤销已做的部分。注意级联回滚 cascading rollback：回滚一个事务可能牵连别的事务。
并发危险：错误汇总问题 incorrect summary（转账进行到一半时统计总额）与丢失更新问题 lost update（两个事务基于同一余额各自扣款）。
对策：访问前先声明类型。共享锁 shared lock：只读，允许多个事务共享；独占锁 exclusive lock：要修改，必须独占。请求被拒就等待——可能死锁 deadlock，用 wound-wait 协议让老事务优先。
事务 = 一组要么全做、要么全不做的步骤；日志先行——提交点后 DBMS 保证生效，提交点前可用日志回滚；回滚可能级联。锁定协议区分共享访问（只读、可共享）与独占访问（修改、独占），防错误汇总与丢失更新；等待可能死锁，老事务优先（wound-wait）可解。一句话：先记日志再动手——做到一半出故障，也能按日志“倒带”。
数据存储与检索系统的历史起点——今天的数据库技术由此演变而来；索引与散列至今仍是构建大型数据库的重要工具。
顺序文件 sequential file：从头到尾串行访问的文件——音频、视频、文档都是。例：员工文件每条记录定长 31 字符（姓名 25 + 编号 6），按逻辑记录 logical record 存取。顺序处理很高效，乱序查找很狼狈。
索引文件 indexed file：为文件建一本“书的索引”——索引 index 列出键及对应记录的存放位置。索引通常先调入主存，查记录 = 索引里找键 → 按位置直接取块。
顺序文件串行访问，适合按存储顺序处理；索引文件靠“键 → 位置”的索引快速定位；散列文件用散列函数直接把键值算成桶号——取记录 = 算桶号 → 取该桶 → 桶内查找。散列还可用于认证网上传送的消息。索引与散列是今天数据库系统的基石。一句话：索引像查书的目录，散列像算出来的柜号——目的都是少翻几页。
数据挖掘 data mining：在数据集合上发现模式的技术——不同于传统数据库查询只检索已存储的事实；数据挖掘的对象是静态的数据仓库 data warehouse（数据库的快照），因为静态系统比动态系统更容易找模式。
找出刻画某一组数据的性质——例：购买小型经济车的人群有什么特征。
找出区分两组的性质——例：买二手车的客户 vs 买新车的客户有何不同。
发现“类”本身——例：观影人群分成 4~10 岁与 25~40 岁两群（孩子与家长？）。
寻找数据组之间的关联——例：买薯片的顾客往往也买啤酒和汽水。
识别不符合常规的数据项——例：信用卡盗刷会突然偏离正常消费模式；也可用于发现数据错误。
发现随时间变化的行为模式——例：股市、气候的变化趋势；挖掘结果可用于预测未来行为。
数据挖掘 = 在数据中发现未知的模式，对象是静态的数据仓库而非在线数据库；它与统计学渊源深厚。六种常见形式：类描述、类辨别、聚类分析、关联分析、离群分析、时序模式分析——结果可用于预测，也常用于更好地理解数据（如解读 DNA）。一句话：传统查询取回“你知道有的”，数据挖掘发现“你不知道有的”。
曾经埋在故纸堆里的信息变得触手可及——法律与伦理上的影响（无论好坏）不是学术辩题，而是现实。
明显的：问卷调查、竞赛报名表、政府规定要求提供——自愿与否取决于视角（申请贷款时提供个人信息算自愿吗？）。
隐蔽的：信用卡公司记录消费习惯、网站记录访客身份、超市积分卡悄悄汇总你的购物清单——记录的价值远超折扣本身。
数据库技术把不同来源的数据链接、比对，揭示原本埋藏的关系：信用卡消费模式被分类成交叉营销画像；买健身器材的人收到健身杂志订阅单；福利记录与犯罪记录比对找出违反假释者——组合信息的方式有时非常有想象力。
例：美国《1974 年隐私法》Privacy Act of 1974——要求政府机构公布其数据库、允许公民查阅和更正个人信息。但立法只能让滥用非法，并不能阻止其发生；官僚系统的拖延同样值得警惕。
或许更有力的办法是舆论：滥用的代价超过收益，数据库就不会被滥用——企业最怕声誉受损。保护隐私，技术之外还需要制度与监督。
数据库技术放大了数据的价值，也放大了隐私与安全的风险——收集可能明显，也可能在你不知情时发生；数据的价值（能被链接出隐藏信息）是收集热潮的根本动力。防范滥用：法律手段 + 公众舆论双管齐下。一句话：数据越能链接，隐私越需守护——能力是技术，分寸是伦理。
逐题一句话解析；错题请回到对应小节复习。速记：9.1→B C｜9.2→B B｜9.3→B C｜9.4→B B｜9.5→B B｜9.6→B B｜9.7→B B
Q1 B 子模式 = 特定用户相关部分的描述；模式才是整体描述。
Q2 C 应用软件不直接碰数据库，DBMS 才是实际操纵者。
Q3 B SELECT 提取行，PROJECT 提取列。
Q4 B SQL 是陈述性语句：描述要什么，而非怎么做。
Q5 B 持久对象 = 程序终止后仍被保存的对象。
Q6 C 对象间的链接由 DBMS 维护，程序员不用操心实现。
Q7 B 所有步骤记入日志的时刻 = 提交点；之前可回滚。
Q8 B 要修改数据必须独占访问——独占锁。
Q9 B 索引文件：索引里找键，按位置取记录。
Q10 B 散列：用散列函数把键值直接算成桶号。
Q11 B 找数据组之间的关联 = 关联分析。
Q12 B 数据挖掘在静态的数据仓库（快照）上进行。
Q13 B 法律 + 舆论等多种途径共同防范滥用。
Q14 B 数据能链接出价值，价值驱动收集热潮。
数据库系统应用抽象，把大型数据集合转换为有用的信息源。下一章预告：计算机图形学。
| 小节 | 一句话总结 |
|---|---|
| 9.1 数据库基础 | 多维数据集合；模式/子模式控访问；DBMS 实际操纵数据库 |
| 9.2 关系模型 | 关系 = 表格：行元组、列属性；SELECT/PROJECT/JOIN；SQL 陈述所需 |
| 9.3 面向对象数据库 | 数据 = 对象，关联 = 链接；对象必须是持久的 |
| 9.4 维护完整性 | 日志先行、提交点生效、可回滚；共享/独占锁防干扰 |
| 9.5 传统文件结构 | 顺序串行、索引查键、散列算桶——数据库技术的源头 |
| 9.6 数据挖掘 | 在数据仓库中发现未知模式：六种分析形式 |
| 9.7 社会影响 | 数据可链接出价值，也可侵犯隐私——法律与舆论共同约束 |