同一张图上的三个标签

INFS5710 的 Lecture 反复用同一张 Database Systems Infrastructure 图。图上有三条数据通路：左边是用 ERM 和 Normalisation 设计出来的 Relational Database，中间是经过 ETL 装进去的 Data Warehouse，右边是从社交媒体和 IoT 流进 Hadoop 的 Big Data。三块旁边分别标着 Normalised、De-Normalised 和 Not Normalised。

按 2026T3 的课表，Week 5 讲 Normalisation，Week 6 讲 Data Warehousing，Week 7 和 Week 8 讲 Big Data、MapReduce 和 NoSQL。这几周连着上，前一周刚把表拆到 3NF，下一周的 star schema 又把表合在一起。三个标签取决于两个条件：数据写进去以后还会不会被改，以及读的时候是查一条记录还是扫一大片。

Relational Database：数据常被改，所以拆

Normalisation 那一讲的 ConstructCo 例子里，一张表同时存项目、员工、职位和工时，主键是 (PROJ_NUM, EMP_NUM)。表里有一条依赖 JOB_CLASS → CHG_HOUR：职位决定每小时收费。CHG_HOUR 跟着员工记录存，同一个职位的费率就会在很多行里重复出现。公司调整 Systems Analyst 的费率时，要把这个职位所有员工的行都改一遍，漏改一行，两个同职位员工的费率就对不上，这就是 modification anomaly。

3NF 把 CHG_HOUR 移到单独的 JOB 表，EMPLOYEE 只留 JOB_CLASS 当外键。费率只存一处，改一次就够。运营数据库每卖出一件货就要改一次库存，写入非常频繁，所以 Lecture 给 relational database 的经验规则是拆到至少 3NF。

Data Warehouse：装进去就不再改，所以合

Data warehouse 的四个特征里有一条 non-volatile：数据由 ETL 定期批量装入，装进去以后只读，不再修改。拆表防的是改一处漏一处，数据不再改，这类 anomaly 也就很少出现。仓库里的查询多是按时间、地点、产品汇总销售额，表拆得越细，一次汇总要做的 join 越多。

Star schema 因此把维度表合并。Lecture 的例子把 product_table 和 brand_table 合成一张 prod_dimension，品牌直接写在产品行里，brandid 外键去掉。textbook Fig 13.11 的 SALES fact table 约 3,000,000 行，四张维度表只有 25 到 3,000 行：大表只存外键和 SALES_QUANTITY、SALES_PRICE 这类数值，小表多存一些重复的文字，换来更少的 join。把维度表再拆回 3NF，得到的是 snowflake schema，省空间，但每次查询要多走几次 join。

Big Data：先存原样，用的时候再取结构

Big Data 那一块标的是 Not Normalised。HDFS 的设计假设之一是 write-once, read-many：文件按 64 MB 的 block 分散在多台机器上，写入一次，之后整份顺序读取，不做单条记录的修改。数据来自社交媒体文本、IoT 传感器和外部 Excel，格式各不相同，没法在写入前先画好 ERD 再拆表。

结构在处理数据时才取出来。MapReduce 那一讲的气温例子里，原始数据是一行行 ASCII 文本，mapper 从每一行里截出年份和气温，组成 (1950, 22) 这样的 key-value，reducer 再按年份取最大值。Document database 同样不要求统一的表结构，同一个 collection 里的记录可以有不同字段，Lecture 里客户 10014 的记录就没有 Initial 这一项。

三层放在一张表里