第3章 · 趣味学习

数据库系统：外卖数据存哪儿、怎么存

📖 原文阅读 📝 知识精要 🎭 趣味学习 ✏️ 练习题

订单像雪花一样飞来，老王美滋滋："数据都存Excel里不就行了？"小明差点把咖啡喷出来："你用Excel存百万级订单？查询要等到下辈子！咱得用数据库。"老王不服："数据库不就是存表的嘛，建个表插数据完事。"

大牛哥摇头："数据库系统这章东西多——从模式范式到设计流程、事务并发、备份恢复、分布式、数据仓库、数据挖掘、NoSQL、大数据，全是架构师吃饭的家伙。老王你那'建个表'的想法，就是项目翻车的起点。"

🗂️ 3.1 DBMS类型：按数据模型分家

数据库管理系统按数据模型分：关系型DBMS（主流）、文档型、键值型、对象型等。商业DBMS主要还是关系数据模型，对象数据模型有但用得少，NoSQL近年带来些新模型。

📐 3.2 数据库模式与范式

3.2.1 三级抽象与三级模式

ANSI/SPARC三级划分：用户级(外模式)、概念级(概念模式)、物理级(内模式)。

  • 👁️ 外模式(用户模式/子模式)：用户能看到用的那部分逻辑结构，一个库可有多个外模式，一个应用只用一个
  • 🧩 概念模式(模式/逻辑模式)：全体数据逻辑结构，DBA视图，所有用户视图的最小并集，一个库只有一个
  • 💾 内模式：数据物理结构和存储方式，最低层，一个库只有一个

关系：模式是中心关键；内模式依赖模式、独立于外模式和存储设备；外模式面向应用、独立于内模式；应用程序依赖外模式、独立于模式和内模式。

两级独立性：①物理独立性（模式↔内模式映射，物理存储变应用不变）；②逻辑独立性（外模式↔模式映射，逻辑结构变应用不变）。逻辑独立性比物理独立性更难实现。

💡 秒懂技巧：三级模式像看一栋楼——外模式是"住户看到的自己家户型"，概念模式是"建筑师的整楼图纸"，内模式是"施工队的钢筋管线走法"。住户换个户型（外模式变）不影响整楼图纸；改了管线走法（内模式变）住户户型图不用重画。这就是两级独立性。

📊 3.2.2 数据模型：层次/网状/关系/面向对象

数据模型分两大类：概念数据模型（E-R模型，面向用户、用于设计）和基本数据模型（结构数据模型，面向计算机、用于DBMS实现）。基本数据模型由数据结构、数据操作、完整性约束三部分组成。

  • 🌲 层次模型：树形结构，指针实现联系，查询快但只能表示1:n，m:n复杂难掌握
  • 🕸️ 网状模型：有向图，指针实现，m:n易实现查询快，但编程复杂、要熟悉逻辑结构
  • 📋 关系模型：表格结构表达实体集，外键表示联系。数学基础严格、概念单一、存取路径透明、独立性好安全性好——主流就它
  • 🎯 面向对象模型：更丰富语义
层次模型像家族族谱——一个父亲多个孩子，查"爷爷的孙子"快，但查"舅舅的姐夫"要绕死人；网状模型像朋友圈关系网——谁都能连谁，灵活但容易绕晕；关系模型像Excel表格——清清楚楚，外键就是"另一张表里对应的那行"，普通人也能看懂，所以赢了。

➗ 3.2.2 关系代数：对表做运算

关系代数基本运算：并∪、差−、交∩、笛卡尔积×、投影π、选择σ、连接⋈、除÷。

  • 并：R∪S = R和S所有元组（要求同列数）
  • 差：R−S = R有而S没有的
  • 交：R∩S = R和S都有的，且 R∩S = R−(R−S)
  • 笛卡尔积：R×S，R有u元组S有v元组则结果u×v个，列数m+n
  • 投影π：抽指定列（如π1,2(R)取第1、2列）
  • 选择σ：按条件选行（从元组角度）
  • θ连接：从笛卡尔积中选属性间满足条件的元组。θ为=叫等值连接；比较分量相同属性组且去重复属性的叫自然连接
  • 除÷：R÷S结果是在X属性上投影的子集，该子集与S的笛卡尔积必须包含在R中。用于"查询全部/所有"类问题
💡 秒懂技巧：投影是"挑列"（竖着切），选择是"挑行"（横着切）。笛卡尔积是"所有可能组合全列出来"（A表3行×B表2行=6行）。除法是"找谁和S的所有组合都在R里"——典型场景"查询选修了全部课程的学生"，用除法一句搞定。

📏 3.2.4 数据的规范化：范式升级打怪

范式由低到高：1NF → 2NF → 3NF → BCNF → 4NF。规范化就是逐步消除不合适的函数依赖，把低一级关系分解成高一级。分解要遵守两准则：无损连接性（信息不失真）和函数依赖保持性（不破坏依赖）。

函数依赖

像自变量x确定则f(x)唯一确定——属性K唯一决定U中元组则K是码，选一个作主码。包含在码中的是主属性，不在的是非主属性。X不是R的码但X是另一个关系的码，X是R的外码。

各级范式

  • 1NF：所有属性值域不可再分（原子性）。这是关系的基本性质，必须满足。如"地址"含省+市需拆成两列
  • 2NF：1NF + 所有非主属性完全依赖于主码（消除部分依赖）。如(省份,姓名,证书名称,证书编号,...)中"发证部门"只依赖证书名称（主码的一部分），需拆成两表
  • 3NF：2NF + 非主属性不传递依赖于主码。如(职工,工资级别,工资额)中工资额传递依赖职工，需拆成(职工,工资级别)+(工资级别,工资额)
  • BCNF：1NF + 每个函数依赖的决定因素都含码。是3NF的改进，消除主属性间的函数依赖
范式 消除的问题 一句话
1NF属性不可再分别把数组塞一个格子里
2NF部分依赖非主属性要完全依赖整个主码
3NF传递依赖非主属性不通过中间人间接依赖主码
BCNF主属性间依赖决定因素必须含码
💡 秒懂技巧：范式升级像整理衣柜——1NF是"袜子不能塞鞋里"（原子化）；2NF是"外套别只依赖衣柜的一个隔层"（消除部分依赖）；3NF是"衣服别通过'颜色'间接决定放哪层"（消除传递依赖）。每升一级冗余和异常少一点，但查询可能要连更多表。

♻️ 3.2.5 反规范化：为性能破坏规则

规范化减冗余省空间、加快增删改，但查询要多表连接拖慢速度。有时为提高查询性能故意破坏规范，叫反规范化。常见技术：

  • ➕ 增加冗余列：成绩表加"姓名"列，省得每次连学生表
  • 🧮 增加派生列：订单表加"订单总价"（单价×数量），免得每次现算
  • 🔗 重新组表：两个常连的表合成一个
  • ✂️ 分割表：水平分割（按行分，如按地区/时间分表）、垂直分割（按列分，常用列和不常用列分开）
反规范化像"为了点外卖快，冰箱里多备几瓶可乐"——本来该去超市买（连表查询），但常喝就囤着（冗余列）。代价是可乐过期要记得换（数据不一致风险）。设计者得在"查询快"和"更新麻烦"间权衡。

🏗️ 3.3 数据库设计：四步走

设计方法有直观设计法、规范设计法、计算机辅助法、自动化法。规范设计法源于1978年新奥尔良会议，分四阶段。基于3NF的设计法分5步：设计企业模式→逻辑模式→物理模式→评价物理模式→实现。

3.3.2 四个基本步骤

  • 📝 需求分析：收集信息需求和处理需求，形成需求说明书（元数据用数据字典管理）
  • 🧩 概念结构设计：构造与DBMS无关的E-R概念模型，面向现实世界、用户易懂
  • 📋 逻辑结构设计：概念模型转成特定DBMS支持的逻辑模型（外模式+概念模式+DDL）
  • 💾 数据库物理设计：设计存储形式、存取路径、索引等内模式

整个过程是反复迭代的，每步都可能回头改前面的。

📝 3.3.3 需求分析：第一步走错全盘皆输

三任务：①确认需求确定设计目标（实地调查、功能范围）；②分析和收集数据（信息需求、处理需求、完整性、安全性）；③整理文档形成需求说明书。需求说明书由用户领导专家共同评审，是后面所有阶段的依据。

🧩 3.3.4 概念结构设计：画E-R图

目标是产生用户易懂、反映信息需求的整体概念结构（概念模型，常用E-R模型）。设计策略有自底向上、自顶向下、由里向外、混合。先设计各局部视图再集成。

视图设计四步

确定局部视图范围 → 识别实体及标识 → 确定实体间联系 → 分配属性。局部视图实体数不宜超过9个（7±2原则，人脑同时顾及5~9件事）。

联系三种类型

  • 1:1：一个施工单位每项工程最多一名工程师管，一名工程师最多管一项工程
  • 1:n：一个专业管很多学生，每个学生只属一个专业
  • m:n：教师与学生教与学的关系，同一教师可教多门、同门可多次教——联系标识可能要加属性如(教师号,课程号,授课日期)

还有实体内部联系(自联系)（如职工间的管理者与被管理者）和多元联系（如供应商-工程-零件的三元联系）。

视图集成：处理冲突

  • 同名异义：同名不同含义，靠换名解决
  • 异名同义：不同名同含义，换名或合并
  • 同名不同层次：一个是实体一个是属性，靠属性↔实体转换
  • 联系测度不同：一处1:n一处m:n，取较高测度
🎮 实战场景：饿了么么设计时，订单部把"商家"当实体，配送部把"商家"当"订单"的属性——这就是同名不同层次冲突。解决办法：统一升级成实体，订单表用外键引用商家实体。视图集成的本质就是把各部门的"自家话"翻译成统一语言。

🔄 3.3.5 逻辑结构设计：E-R转成关系模型

把E-R图转成DBMS支持的逻辑结构。基本原则：实体和联系转成关系，属性转成关系属性。

  • 1:1：可转三个关系(E1,E2,R)或合并成两个（看属性多少和冗余权衡）
  • 1:n：可转三个关系，或把少端并入多端成两个关系（关键字为多端标识）
  • m:n：三个关系，联系转成的关系关键字由两端实体标识组成
  • 多元联系：各实体分别转关系，联系转成关系，关键字由各实体标识组成
  • 自联系：同一实体集内，扮演不同角色
  • 弱实体类：存在依赖另一实体（如职工亲属依赖职工），不能单独转关系

模型优化：改善性能（减少连接=逆规范化、减小关系大小=水平/垂直分割、用快照）和节省空间（编码缩写、假属性分类减少重复）。设计是综合性工作，常"有得有失"。

💾 3.3.6 物理结构设计

在物理设备上设计存储结构和存取方法（文件结构、索引设计），即设计内模式。完全依赖给定硬件和DBMS。设计者要了解应用要求、DBMS性能、外存设备特性。设计目标主要是提高性能，其次是节省空间。

🔐 3.4 事务管理：要么全做要么不做

事务是数据库运行的基本工作单位，相当于OS的进程。ACID特性：

  • ⚛️ 原子性Atomicity：不可分割，要么都做要么都不做
  • ✅ 一致性Consistency：从一个一致态到另一个一致态
  • 🚧 隔离性Isolation：不能被其他事务干扰
  • 💾 持续性Durability：提交后改变永久

事务以BEGIN TRANSACTION开始，COMMIT(成功)或ROLLBACK(失败)结束。

3.4.1 并发控制

并发操作带来：丢失更新、不一致分析(读过时数据)、读"脏"数据(依赖未提交更新)。解决靠封锁技术：

  • 🔒 X封锁(排他型)：只允许持有者读写，别人啥也干不了
  • 📖 S封锁(共享型)：允许并发读但不能改，解S锁前不许X锁

三级封锁协议：

  • 一级：改数据前先X锁到事务结束。防丢失修改，不防脏读和不可重复读
  • 二级：一级+读前S锁、读完即释放。防丢失修改+防脏读，不保证可重复读
  • 三级：一级+读前S锁到事务结束。防丢失修改+防脏读+防不可重复读
  • 两段锁协议：扩展阶段(先全加锁)→收缩阶段(后全解锁)。遵守两段锁的并发调度可串行化，但可能死锁

封锁粒度：小则并发高开销大，大则并发低开销小。死锁可预防（顺序申请/一次申请）或检测恢复。

💡 秒懂技巧：X锁像独占卫生间（别人门外等），S锁像图书馆借阅室（大家都能进来看书但不能把书带走改）。一级协议=改东西前锁好别让人改没了；二级=读之前也锁一下别读到半截被人改了；三级=读之前锁好一直不撒手，保证我能重复读出一样的结果。两段锁="先全部拿完钥匙再开始还钥匙"，不能拿一个还一个。

🚑 3.4.2 故障与恢复

四类故障：①事务故障（运算溢出、违反完整性、死锁等未正常终止）；②系统故障（CPU故障、停电，内存丢外存不丢）；③介质故障（磁盘损坏，破坏性最大）；④计算机病毒。

恢复靠转储+日志文件：

  • 事务故障：反向扫描日志，对该事务更新做逆操作(Undo)。
  • 系统故障：正向扫描日志，已提交未写入的Redo，未完成的Undo。
  • 介质故障/病毒：装最新后备副本→从故障点反向读日志找已提交→正向Redo。
  • 检查点恢复：建检查点时记下正在执行的事务清单和日志地址，重启时从检查点扫，U队Undo、R队Redo。
日志像记账本——每笔交易都记一笔。Undo是"这笔撤回"（事务没完成要回滚），Redo是"这笔重做"（已提交但没落库要重写）。检查点像"每月对账日"——从对账日开始算，不用从年头翻账本，恢复快。

📦 3.5 备份与恢复：给数据买保险

两原则：①数据丢失尽量少或不丢；②备份恢复时间尽量短。物理备份（操作系统层备份数据文件）分冷备(关库备份)和热备(不关库备份)。备份方式组合：完全备份+增量备份(只备上次后改的)+累积备份(备上次完全/累积后改的)。逻辑备份用DBMS自带工具（如Oracle的exp/imp，按表/表空间/用户/全库四层次）。大型库一般物理完全+增量/累积+磁带库。

完全备份像每月大扫除拍全景照；增量备份像"今天动了啥拍啥"；累积备份像"从上次大扫除到现在所有改动拍一张"。恢复顺序：先恢复最近完全备份，再按时间顺序导入增量/累积。逻辑备份像手抄笔记——慢但灵活，适合日常单表备份。

🌐 3.6 分布式数据库系统：数据分散逻辑统一

3.6.1 概念

分布式数据库(DDB)是数据分布在网络不同计算机上、每个结点可独立处理(场地自治)又可执行全局应用的系统。DDBMS保证物理分布对用户透明。

特点：①数据分布性；②统一性（逻辑统一+管理统一）；③透明性。优点：坚固性好、可扩充、可改善性能(就近访问)、自治性好。

分类：按DDBMS同构度(同构/异构)、按局部自治度(无自治/联邦多数据库)、按分布透明度(高度透明/无透明/部分透明)。

理想目标12条：局部自治、不依赖中心结点、连续操作、位置/分片/复制独立性、分布式查询和事务管理、硬件/OS/网络/DBMS独立性。

3.6.2 六层架构

全局外模式→全局概念模式→分片模式→分布模式→局部概念模式→局部内模式。下半部分是集中式DB结构，上半部分是分布式增加的。分片模式定义全局关系到片段的映像(一对多)，分布模式定义片段存放结点。

分布式vs并行数据库

并行库为发挥多机性能、高速网互联、负载均衡、无局部自治；分布式库为场地自治和全局透明共享、局域/广域网互联、减少传输、有局部自治。最主要区别：分布式每个场地是独立DB系统有自治性，并行各结点协同处理无局部应用。

数据分片

水平分片(按行)、垂直分片(按列)、混合分片、导出分片。分布透明性三层：分片透明(最高，用户不管分片)→位置透明(知道分片不知存哪)→局部数据模型透明(知道分片和场地不知数据模型)。

💡 秒懂技巧：分布式数据库像连锁超市——各店有自家库存(场地自治)又能查全连锁的货(全局应用)。分片透明=顾客只管搜"可乐"不管哪家有；位置透明=知道分"北京仓/上海仓"不知存哪个货架；模型透明=知道存哪个仓不知那仓用啥记账系统。用户越省心，透明度越高。

📊 3.7 数据仓库：为决策而生

3.7.1 概念

Inmon定义：数据仓库是面向主题的、集成的、相对稳定的、随时间变化的数据集合，用于支持管理决策。

  • 🎯 面向主题：按主题域组织（如顾客、保单、保费、索赔），不是按应用
  • 🔗 集成：最重要特性。抽取清理汇总消除源数据不一致，形成全局一致信息
  • 🛋️ 相对稳定：大量查询少修改删除，定期加载刷新
  • ⏰ 随时间变化：含历史信息，必有时间元素

3.7.2 结构

数据源→数据准备区(净化处理)→数据仓库数据库→数据集市/知识挖掘库→应用工具(OLAP等)。

OLAP服务器三种实现：ROLAP(基本+聚合数据都在RDBMS)、MOLAP(都在多维数据库)、HOLAP(基本在RDBMS聚合在多维库)。前端工具有报表/查询/分析/数据挖掘工具。

3.7.3 实现方法

自顶向下（先定商业需求再实现，适合技术成熟决策层目标清楚）、自底向上（先做数据集市原型快速见效，适合技术评估和小投入）、联合方法（兼顾两者优点，难管理）。

数据库像超市收银台——记录每笔交易（面向应用、实时更新）；数据仓库像超市年终总结——把各分店数据抽出来清理汇总，按"顾客/商品/时段"主题分析（面向主题、历史、少改）。OLAP像在数据仓库里多角度切蛋糕，ROLAP用关系表存、MOLAP用多维立方体存、HOLAP折中。

⛏️ 3.8 数据挖掘：从矿石里淘金

3.8.1 概念

数据挖掘从大量、不完全、有噪声、模糊、随机的数据中，提取隐含的、事先不知道但潜在有用的信息和知识。三大基础技术：海量数据搜集、强大多处理器计算机、数据挖掘算法。与数据分析本质区别：没有明确假设地挖掘信息。发现的信息越出乎意料越有价值——经典案例：纸尿布和啤酒的关联。

3.8.2 五类功能

  • 🔮 自动预测趋势和行为：市场预测、预报破产
  • 🔗 关联分析：找变量间规律(简单/时序/因果关联)，带可信度
  • 📊 聚类：划分为有意义子集，概念描述和偏差分析的前提
  • 📝 概念描述：特征性描述(共性)和区别性描述(差异)
  • ⚠️ 偏差检测：找异常记录，如反常实例、特例

3.8.3 常用技术

  • 关联分析：发现"买了A也买B"的规律，调整商品布局或降价促销搭售
  • 序列分析：发现一定时间间隔内接连发生的事件，加时间约束
  • 分类分析：贝叶斯、神经网络、决策树、支持向量机等。对顾客分类、文本/图片分类
  • 聚类分析：无类别样本聚成组，组内相似组间不似
  • 预测：估算连续变量取值，常用回归分析
  • 时间序列分析：随时间变化的事件序列，预测趋势/找相似模式/发现周期规律

3.8.4 流程

问题定义→建立数据挖掘库→分析数据→调整数据→模型化(核心环节，用神经网络/决策树/统计/时间序列)→评价和解释。需三类人：业务分析人员、数据分析人员、数据管理人员。

🎮 实战场景：饿了么么用关联分析发现"点外卖的程序员周五晚上常点啤酒+炸鸡"——于是周五给这类用户推啤酒炸鸡套餐，销量涨30%。这就是"数据爆炸但知识贫乏"的破解之道：挖掘出人想不到的关联。分类分析还能把用户分"价格敏感/品质导向/夜猫子"几类，精准推优惠。

🗄️ 3.9 NoSQL：不只是SQL

NoSQL(Not Only SQL)为应对Web2.0超大规模高并发SNS而兴起。关系库表结构固定、每个元组分配所有字段（即使不需要）是性能瓶颈因素。NoSQL以键值对存储，结构不固定，每元组可有不同字段。

四大优点：①易扩展（去关系性，数据无关系好扩展）；②大数据量高性能（Cache是记录级细粒度，比MySQL的表级Query Cache强）；③灵活数据模型（无须事先建字段，随时存自定义格式）；④高可用（如Cassandra/HBase复制模型）。缺点：无标准、内部混乱、缺专家支持。

关系库像统一规格的方格本——每行每列都一样，哪怕你这行不写字那格也得留出来；NoSQL像自由笔记——每页想写啥写啥，灵活省地方但不方便统一查询和连接。互联网海量数据要的是扩展和速度，NoSQL就火了。

🌊 3.10 大数据：4个V的洪流

大数据是无法用常规软件工具捕捉管理处理的数据集合，需要新处理模式。4V特征：

  • 📐 Volume（体量大）：TB→PB→EB→ZB。人类所有印刷材料200PB，说过的话约5EB
  • 🎨 Variety（类型多）：结构化+非结构化（网络日志、音视频、图片、地理位置）
  • 💎 Value（价值密度低）：1小时视频可能有用的就1-2秒，需"提纯"
  • ⚡ Velocity（处理速度快）：区别于传统数据挖掘的最显著特征，处理效率是企业的生命

关键技术：大数据采集→预处理→存储管理→分析挖掘→展现应用(检索/可视化/应用/安全)。

🎮 实战场景：饿了么么每天产生千万级订单、骑手轨迹、用户点击日志——Volume大；订单是结构化、骑手轨迹是半结构化、点击日志是非结构化——Variety多；千万条轨迹里真正反映路线优化的关键点可能就几百个——Value密度低；高峰期订单要秒级处理——Velocity快。这就是典型大数据场景，传统数据库搞不定，得上大数据技术栈。
← 上一章 📚 目录 下一章 →