🗄️ 第一章 数据库的基础知识
📄 一句话概括

图书馆检索和网购下单,背后是同一套思路——把现实世界的东西变成一张张表;本节用两个熟悉的场景给整个第一章收账。

📝 本节和前面几节的关系

1-7 看了超市一个场景;本节再看两个场景,并借它们把全章概念(数据→数据库→DBMS→SQL→场景)串成一条线——这是第一章的收官节。

一、图书馆系统:书就是记录

图书馆借阅系统是最经典的数据库教学案例,因为它把概念对得工工整整:

现实世界 数据库世界
每一本书 图书表里的一条记录
书名/作者/ISBN/在架位置 记录里的字段
检索台搜书名 SELECT 查询(1-6)
借书 更新该书记录的状态字段:【在架】→【已借出】+ 写一条借阅记录
还书 状态改回【在架】,借阅记录补上归还日期
逾期罚金 按【应还日期】字段计算——字段不许空(1-4 的限制)

一句话:图书馆系统=把【书】和【借书行为】变成表,再把日常动作变成 SQL。

二、购物网站:一次下单动了好几张表

一个大中型购物网站,底下至少有这几张表:

表 存什么
商品表 商品名、价格、库存、图片链接
用户表 账号、昵称、收货地址
购物车表 谁把什么放进了购物车
订单表 订单号、谁买的、买了什么、状态

按下【提交订单】那一秒,系统同时干三件事:

  1. 往订单表插一条记录(INSERT)
  2. 商品表的库存减一(UPDATE)
  3. 购物车表里清掉对应条目(DELETE)

这三件事要么全成、要么全不成——只插了订单、库存没减,商品就【超卖】了。这个【一揽子保证】的机制叫事务,是后面章节的大主角,这里先埋个种子。

三、两个场景 × 全章概念,对号入座

第一章知识点 图书馆 购物网站
数据(1-1) 书目、借阅记录 商品、用户、订单
整理成表(1-2) 图书表/借阅表 商品表/用户表/订单表
DBMS(1-3) 图书馆后台系统 网站后台服务
限制(1-4) ISBN 唯一、应还日期非空 库存不许为负、手机号唯一
并发控制(1-4) 多个检索台同时查 双十一几亿人同时下单
权限(1-4) 读者只能查、管理员才能改 用户只能看自己的订单
SQL(1-6) 检索 = SELECT 下单 = INSERT+UPDATE+DELETE

四、第一章的概念链条(收官总结)

数据(对事实的记录)
  ↓ 有组织地放
数据库(统一管理的仓库)
  ↓ 谁来管
DBMS(管理员系统:查快/拦错/控并发/分权限/能恢复)
  ↓ 怎么指挥
SQL(声明式通用语言:SELECT/INSERT/UPDATE/DELETE/CREATE/GRANT)
  ↓ 用在哪
场景(POS 收银、订单、分析、图书馆、购物网站)

从这章起,你看到任何一个软件,都可以问三个问题:它有哪些表?谁在管?那句 SQL 是什么?

五、动手 Demo:画出一次网购动过的表

回忆你最近一次网购,仿照第二节,填一张三列表:

动作 动了哪张表 干了什么
搜索【台灯】 商品表 按关键词查询
加入购物车 购物车表 插入一条
提交订单 订单表/商品表/购物车表 插订单+减库存+清购物车(事务)
确认收货 订单表 状态改为【已完成】

看到什么算成功:至少写满 4 行,并且【提交订单】那一行能说出【同时动了三张表】。

六、30 秒实验

打开任意购物网站,搜一件商品:

七、常见误区

  1. "一个网站只有一个数据库" —— 常常不是:用户库、商品库、订单库可能分开放,甚至分散在多台服务器上(为的是各自扛各自的流量)。
  2. "购物车就是订单" —— 两张表两个概念:购物车是【意向清单】,提交那一刻才生成订单;购物车里的东西可以一直躺着不下单。
  3. "页面显示库存 3 件,库里就一定是 3 件" —— 不一定:几百人同时在下单,库存每一毫秒都在变;并发控制(1-4)保证的是最终账目正确,页面数字只是某一瞬间的快照。
自测三问(点开对答案) 1. 借书在数据库里对应什么操作? **更新图书表的状态字段(在架→已借出)+ 插入一条借阅记录**。 2. 提交订单一秒内动了哪三张表? **订单表(插)、商品表(减库存)、购物车表(清条目)**——三件事要么全成要么全不成。 3. 第一章的概念链条,从上到下五个词? **数据 → 数据库 → DBMS → SQL → 场景**。

相关笔记