15-445#1 Relational Data Model

为什么需要 Database？

数据库是对现实世界的某些方面（例如。，在课堂或数字音乐商店中为学生建模）。人们经常混淆“数据库”和“数据库”管理系统”（例如MySQL、Oracle、MongoDB）。数据库管理系统（DBMS）是管理数据库的软件。考虑一个模拟数字音乐商店的数据库（例如Spotify）。让数据库保存信息关于艺术家以及他们发行了哪些专辑。

将数据库存储为逗号分隔的值（CSV）我们自己管理的文件
应用程序代码。
→ 每个实体使用一个单独的文件。
→ 应用程序必须在每次需要时解析文件
读取/更新记录。

我们可以用两个 CSV 文件来分别存储艺术家和专辑信息，然后用程序来解析和序列化相关数据：

• 艺术家（Artists）信息
• 艺术家发行的专辑（Albums）信息

艺术家信息表：

Artist.csv
"Wu Tang Clan",1992,"USA"
"Notorious BIG",1992,"USA"
"Ice Cube",1989,"USA"

专辑信息表：

Album.csv
"Enter the Wu Tang","Wu Tang Clan",1993
"St.Ides Mix Tape","Wu Tang Clan",1994
"AmeriKKKa's Most Wanted","Ice Cube",1990

假设我们想知道 “Ice Cube 在哪年首发”，就会写这样的查询脚本：

for line in file:
    record = parse(line)
    if record[0] == "Ice Cube":
        print(int(record[1]))

但这种简单的方案有很多缺陷：

• 数据的质量方面
  • 很难保证同一个艺术家发行的每条专辑信息中，艺术家字段一致
  • 很难阻止用户在年份字段写入不合法的字符串
  • 很难优雅地处理一张专辑由多个艺术家共同发行的情况
• 实现方面
  • 查询一条特定的记录，效率低
  • 当有多个应用使用该 CSV 数据库
    • 查询脚本需要重复写
    • 多个线程一起写时，如何保证数据一致性
• 数据持久
  • 正在写记录时遇到宕机
  • 如何复制数据库到多台机器上来保证高可用性

以上缺陷迫使我们需要升级 CSV 数据库，于是就有了专业的数据库系统（DBMS）。

DBMS 的提出

DBMS是允许应用程序在数据库中存储和分析信息。一个通用的数据库管理系统被设计成允许定义、创建、查询、更新和管理数据库。

分离逻辑层和物理层

所有系统都会产生数据，因此数据库几乎是所有系统都不可或缺的模块。在早期，各个项目各自造轮子，因为每个轮子都是为应用量身打造，这些系统的逻辑层（logical）和物理层（physical）普遍耦合度很高。

Ted Codd 发现这个问题后，提出 DBMS 的抽象（Abstraction）：

• 用简单的、统一的数据结构存储数据
• 通过高级语言操作数据
• 逻辑层和物理层分离，系统开发者只关心逻辑层，而 DBMS 开发者才关心物理层。

数据模型

在逻辑层中，我们通常需要对所需存储的数据进行建模。如今，市面上有的数据模型包括：

• Relational => 大部分 DBMS 属于关系型，也是本课讨论的重点
• Key/Value
• Graph
• Document
• Column-family
• Array/Matrix

Relational Model

Relation & Tuple

每个 Relation 都是一个无序集合（unordered set），集合中的元素称为 tuple，每个 tuple 由一组属性构成，这些属性在逻辑上通常有内在联系。

Primary Keys

primary key 在一个 Relation 中唯一确定一个 tuple，如果你不指定，有些 DBMSs 会自动帮你生成 primary key。

Foreign Keys

foreign key 唯一确定另一个 relation 中的一个 tuple

利用这些基本概念，我们就可以利用第三张表，ArtistAlbum，来解决专辑与艺术家的 1 对多的关系问题：

Artist
id, name, year, country

Album
id, name, year

ArtistAlbum
artist_id, album_id

Data Manipulation Languages (DML)

在 Relational Model 中从数据库中查询数据通常有两种方式：Procedural 与 NonProcedural：

• Procedural：查询命令需要指定 DBMS 执行时的具体查询策略，如 Relational Algebra
• Non-Procedural：查询命令只需要指定想要查询哪些数据，无需关心幕后的故事，如 SQL

使用哪种方式是具体的实现问题，与 Relational Model 本身无关。

RELATIONAL MODEL

relation是无序集，包含表示实体的属性之间的关系。
tuple是关系中的一组属性值（也称为其domain）。
→ value（通常）是原子/标量。
→ 特殊值NULL是每个域的成员。

关系的primary key唯一地标识一个元组。
如果表没有定义内部主键，一些DBMS会自动创建一个内部主键。


foreign key指定一个关系中的属性必须映射到另一个关系中的元组。

Relational Algebra

relational algebra 是基于 set algebra 提出的，从 relation 中查询和修改 tuples 的一些基本操作，它们包括：

• Select ($\sigma$ )
• Projection ( $\pi$ )
• Union ( $\cup$ )
• Intersection ( ∩ )
• Difference (− )
• Product ( × )
• Join ( ⨝ )
• Rename ( ρ* )
• Assignment ( R←S )
• Duplicate Elimination ( δ )
• Aggregation ( γ )
• Sorting ( τ )
• Division ( R÷S )

将这些操作串联起来，我们就能构建更复杂的操作

注意：使用 Relation Algebra 时，我们实际上指定了执行策略，如：

它们所做的事情都是 ”返回 R 和 S Join 后的结果中，b_id 等于 102 的 tuples“。

虽然 Relational Algebra 只是 Relational Model 的具体实现方式，但在之后的课程将会看到它对查询优化、执行的帮助。

REL ATIONAL ALGEBRA: SELECT（选择）

从满足selection predicate的关系中选择tuple的子集。
→ predicate充当过滤器，只保留满足限定条件的tuple。
→ 可以使用连接/析取组合多个predicate。

$$Syntax:{\sigma }_{predicate}(R)$$

REL ATIONAL ALGEBRA: PROJECTION(投影)

生成仅包含指定属性的元组关系。
→ 可以重新排列属性的顺序。
→ 可以操纵值。

$${\Pi }_{A1,A2,...,An}(R)$$

REL ATIONAL ALGEBRA: UNION（连接）

生成一个关系，其中包含仅出现在一个或两个输入关系中的所有元组。

$$Syntax:R\cup S$$

REL ATIONAL ALGEBRA: INTERSECTION

$$Syntax:(R\cap S)$$

REL ATIONAL ALGEBRA: DIFFERENCE

$$Syntax:(R-S)$$

REL ATIONAL ALGEBRA: PRODUCT（笛卡尔积）

$$Syntax(R\times S)$$

REL ATIONAL ALGEBRA: JOIN

生成一个关系，该关系包含两个元组（每个输入关系一个元组）与一个或多个属性的公共值的组合的所有元组。

$$Syntax:R\bowtie S$$