笔记分享: 墨尔本大学INFO20003数据库系统——01. ER模型

更多资料与笔记

$\text{ER Modelling}$

$\text{1. Introduction}$

$\text{1.1. Data→DBMS}$

1️⃣$\text{Data vs. Information:}$

$\text{Item}$	定义	描述	示例
$\text{Data}$	$\text{Known facts stored and recorded}$	$\text{Raw Data}$	$\text{123}$
$\text{Information}$	$\text{Data presented in context}$	$\text{Processed Data}$	$\text{StuID=123}$

2️⃣$\text{Metadata: }$

1. 含义：描述数据的数据，提供数据的背景和结构信息
2. 示例：书籍的标题/作者/出版年份/$\text{ISBN}$等信息

3️⃣$\text{Database: }\text{Large integrated}\text{ and }\text{structured }\text{collection of data }$

4️⃣$\text{DBMS (Database Management System)}$

1. 定义：$\text{Software designed to }\text{store/manage/facilitate access}\text{ to databases.}$
2. 比如$\text{MySQL}$

$\text{1.2. DB Development Process}$

$\text{1.2.1. High Level Design}$

1️⃣$\text{Database Planning:}$ 比如企划银行的结构，有客户/账户/员工等以及对应关系

2️⃣$\text{System Definition:}$ 确定系统的边界与接口；比如抵押系统如何从客户系统获取必要信息

3️⃣$\text{Requirements Definition/Analysis:}$ 确定系统需求(能实现什么)，比如银行系统能否汇率转换

$\text{1.2.2. Core Design}$

1️⃣$\text{Conceptual Design/ER Modelling}$

1. 独立于物理实现的数据模型
2. 最常见的概念设计方法为$\text{ER Modelling}$
   • 包含$\text{Entity(Employee)+Attributes(ssn/name/age)}$
   • 常见的$\text{ER Diagram}$有$\text{Chen’s}$还有$\text{Crow’s Foot}$

2️⃣$\text{Logical Design/Relational Model}$

Employee (ssn, name, age) -- Employee为关系，(ssn, name, age)为其三个属性

1. 独立于具体数据库的逻辑模型
2. 最常见的逻辑设计方法为$\text{Relational Model}$
   • $\text{ER Modelling}\stackrel{\{\begin{array}{l}\text{Entity}\to \text{Reation(表)}\\ \\ \text{Attribute}\to \text{Attribute(列)}\end{array}}{\to }\text{Relational Model}$

3️⃣$\text{Physical Design:}$

Employee (ssn CHAR(11), name VARCHAR(20), age INTEGER)

1. 实现具体数据库的物理模型
2. 其实就是$\text{Logical}\stackrel{\text{Choose data type}}{\to }\text{Physical}$

4️⃣$\text{Implementation \& Instance:}$

1. $\text{Implementation:}$ 通过$\text{MySQL Workbench}$创建表格

   CREATE TABLE Employee (
      ssn CHAR(11),
      name VARCHAR(20), 
      age INTEGER, 
      PRIMARY KEY (ssn)
   );
   

2. $\text{Instance:}$ 往实现好了的$\text{SQL}$表格中填充数据
   

$\text{1.2.3. Other Design}$

1️⃣$\text{Application Design:}$ 设计使用数据库的用户界面$\text{APP}$

2️⃣测试和维护

$\text{2. ER Modelling (Chen’s)}$

$\text{2.1. Basic Concepts}$

1️⃣概述

$\text{Concept}$	解释	备注
$\text{Entity(Set)}$	真实世界中的对象(集合)	单个实体由多个属性描述
$\text{Attribute}$	对于一个实体的描述	实体的属性中必有一个$\text{Key}$(区分每个个体)
$\text{Relationship(Set)}$	两个/多个实体的联结(集合)	关系也可能有$\text{(Descriptive)Attribute}$

2️⃣综合示例($\text{(Chen’s Model)}\{\begin{array}{l}\text{Entity: Employee/Department}\\ \\ \text{Relation: Works in}\end{array}$

• $\text{Primary Key}$要用下划线标出

3️⃣注意事项：

1. 同一实体可出现在不同关系
2. 同一实体可有不同角色(员工的上下级)

$\text{2.2. Relation}$

$\text{2.2.1. Binary: Relation Constraints}$

0️⃣关系基数：$\text{1-1/1-M/M-M}$三种

1️⃣$\text{Key/Cardinalitiy Constraints:}$ 确定了数量的上限$\text{1/N}$

关系类型	$\text{Employee(Manager)}$	员工键约束	$\text{Department}$	部门键约束
$\text{M-M}$	$\text{N}$(一部门有多员工)	❌	$\text{N}$(一员工在多部门)	❌
$\text{1-M}$	$\text{1}$(一部门只有一经理)	✔️	$\text{N}$(一经理管多部门)	❌
$\text{1-1}$	$\text{1}$(一部门只有一经理)	✔️	$\text{1}$(一经理管一部门)	✔️

2️⃣$\text{Participation Constraints:}$ 确定了数量的下限$\text{0/1}$

1. $\text{Total/Partial Participation:}$ 一个实体集中所有实体必须/非必须参与到关系中
2. $\text{Chen’s}$表示：$\text{Total participation is represented by bold line}$
   

3️⃣两种限制的组合：确定了数量的上下限

$\text{Type}$	$\text{Participation}$	$\text{Key Constraint}$	$\text{E.g. Prof may teach\_lecture}$
$\text{Optional Many}$	$\text{Partial}$(下限$\text{0}$)	❌(上限$\text{N}$)	$\text{0/1/N}$
$\text{Mandatory Many}$	$\text{Total}$(下限$\text{1}$)	❌(上限$\text{N}$)	$\text{1/N}$
$\text{Optional One}$	$\text{Partial}$(下限$\text{0}$)	✔️(上限$\text{1}$)	$\text{0/1}$
$\text{Mandatory One}$	$\text{Total}$(下限$\text{1}$)	✔️(上限$\text{1}$)	$\text{1}$

• 注意$\text{Chen’s}$模型中，靠近一方实体的线$\{\begin{array}{l}决定这一方实体的\text{Optional/Mandatory}\\ \\ 决定另一方实体的\text{One/Many}(箭头指向\text{One})\end{array}$

$\text{2.2.2. Ternary Relationships}$

1️⃣含义：三个实体同时参与一个关系

2️⃣示例：

1. 部门($\text{Depaertment}$)/供应商($\text{Supplier}$)之间，建立了一个有关组件($\text{Part}$)的合同
2. 关系的属性包含了合同中组件的数量

$\text{2.3. Entity: Weak Entity}$

1️⃣弱实体基本要素

1. 强弱实体

   $\text{Entity}$	描述
   $\text{Owner/Strong Entity}$	弱实体所赖以存在的实体
   $\text{Weak Entity}$	依赖于强实体而存在的实体

2. $\text{Identifying/Weak Relationship:}$ 连接强弱实体的关系，所有弱实体必定有一个弱关系

2️⃣关于$\text{Weak Entity}$的$\text{Key}$

$\text{Key}$	描述
$\text{Weak Entity}$的$\text{PK}$	又称为$\text{Partial Key}$，在$\text{Chen’s}$中用虚下滑线表示
$\text{Owner Entity}$的$\text{PK}$	塞进$\text{Weak Entity}$当$\text{PFK}$，识别弱实体要自身$\text{PK+}$强实体$\text{PK(PFK)}$

3️⃣如何辨认$\text{Weak Entity}$

1. 如果$\text{A}$不存在$\text{B}$也不能存在，则$\text{B}$是$\text{A}$的$\text{Weak Entity}$
2. 如果需要识别出$\text{A}$，不仅要$\text{A}$的$\text{PK}$还需要$\text{B}$的$\text{PK}$，则$\text{B}$是$\text{A}$的$\text{Weak Entity}$
3. $\text{Weak Entity}$和$\text{Owner Entity}$通常是$\text{1-M}$关系，且弱对强一定是$\text{Mandatory One}$(粗箭头)
   • 弱实体必定有赖于强实体而存在($\text{Mandatory}$)
   • 弱实体也只能依赖唯一的强实体($\text{One}$)

4️⃣$\text{Chen’s ER Diagram:}$ 员工家属$\text{(Dependent)}$是弱实体

1. 弱实体/弱关系边框加粗
2. $\text{Partial Key}$需要用虚线下划线标记

$\text{2.4. Attribute (Special Type)}$

$\text{2.4.1. Multi-Valued Attributes}$

1️⃣概念：一个属性拥有多个(但非无限)个同类型值，比如一个员工拥有多个电话

2️⃣$\text{Chen’s ER Diagram:}$ 用镶嵌气泡表示

$\text{2.4.2. Composite Attributes}$

1️⃣概念：拥有内部结构的属性，比如员工地址内还包含邮政编码/街道名/街道号

2️⃣$\text{Chen’s ER Diagram:}$ 气泡插到气泡上，

$\text{2.4.3. Derived Attributes}$

1️⃣含义：从别的属性派生出来的属性

2️⃣特点：并不会在物理层面存储该属性，所以在物理设计阶段就会消失

3️⃣$\text{Chen’s ER Diagram:}$ 用虚框表示

• $\text{Years Employeed}$可以由以下规则派生

  DATE.now - Contact.start
  

$\text{2.5. Conceptual Design: Entity or Attribute?}$

1️⃣通常情况下，选择设计成$\text{Entity}$比设计成$\text{Attribute}$灵活性更高，也是首选

2️⃣示例：用户($\text{UserID}$订阅$\text{Plan}$及其$\text{Type}$

1. 当$\text{Type}$为$\text{Attribute:}$ 如果要新增$\text{TypeX}$，则需强制增加一个使用$\text{TypeX}$的$\text{UserID}$，明显不行

   $\text{Plan}$表	$\text{UserID}$	$\text{Type}$
   $\text{/}$	$\text{1}$	$\text{TypeA}$
   $\text{/}$	$\text{2}$	$\text{TypeB}$
   $\text{/}$	$\text{3}$	$\text{TypeC}$
   $\text{/}$	$\text{?}$	$\text{TypeX}$

2. 当$\text{Type}$为$\text{Entity:}$ 可以灵活新增$\text{TypeX}$，不鸟$\text{UserID}$如何独立存在

   $\text{Plan}$表	$\text{UserID}$	$\text{Plan}$表	$\text{TypeID}$
   $\text{/}$	$\text{1}$	$\text{/}$	$\text{A}$
   $\text{/}$	$\text{2}$	$\text{/}$	$\text{B}$
   $\text{/}$	$\text{3}$	$\text{/}$	$\text{C}$
   $\text{/}$	$\text{/}$	$\text{/}$	$\text{X}$

$\text{3. ER Modelling (Crow’s Foot)}$

$\text{3.1. Basic Component}$

1️⃣$\text{Entity}$

$\text{Concept}$	$\text{Chen’s Notation}$	$\text{Crow’s Foot Notation}$
$\text{Entity}$
$\text{Weak Entity}$

2️⃣$\text{Attributes}$

1. 各种类型的属性

   $\text{Concept}$	$\text{Chen’s Notation}$	$\text{Crow’s Foot Notation}$
   $\text{Attribute}$
   $\text{Mutivalue A.}$
   $\text{Composote A.}$
   $\text{Derived A.}$

2. $\text{Key(Covered Later in Relational Model)}$

   $\text{Concept}$	$\text{Chen’s Notation}$	$\text{Crow’s Foot Notation}$
   $\text{Key A.}$
   $\text{Weak/Partial Key A.}$

3. 示例($\text{In Workbench}$)
   

   $\text{Primary Key}$	$\text{Foreign Key}$	$\text{Mandatory}$/NOT NULL	$\text{Optional}$/NULL

3️⃣$\text{Relationship}$

1. 强弱关系

   $\text{Concept}$	$\text{Chen’s}$	$\text{Crow’s Foot}$
   $\text{Relationship}$
   $\text{Relationship/Identifying Relationship}$

2. 示例
   

$\text{3.2. Relationship Constraints}$

1️⃣$\text{Constraints}$

$\text{Type}$	$\text{Chen’s Vs. Crow’s Foot}$	$\text{Crow’s Foot E.g.}$
$\text{Optional Many}$
$\text{Mandatory Many}$
$\text{Optional One}$
$\text{Mandatory One}$

2️⃣$\text{Relationship (Cardinalitiy Only)}$

$\text{Type}$	$\text{Chen’s}$	$\text{Crow’s Foot}$
$\text{M-M}$
$\text{1-M}$
$\text{1-1}$

$\text{3.3. Chen’s}\stackrel{转换}{\leftrightarrow }\text{Crow’s Foot}$

1️⃣转换的核心规则：$\text{Crow’s Foot}$一侧的鸦足标记$\stackrel{对应}{\leftrightarrow }\text{Chen’s}$另一侧的线/箭头

2️⃣示例

$\text{4. Relational Model}$

$\text{4.1. Basic Conception}$

1️⃣$\text{Relational Data Model}$

1. $\text{Data Model:}$ 将$\text{Real-World}$实体转化为计算机$\text{Readable}$的结构，比如$\text{Relational Model}$
2. $\text{Relational Model}$的基本要素:
   
   • $\text{Schema: }$关系(表格)的名称$\text{+}$表格每列的属性名/属性类型
   • $\text{Instance: }$表格每行的$\text{Tuple}$
3. $\text{Data→Relational Model}$转换
   • $\text{Data}\underset{\text{Represent Data With Table}}{\overset{\{\begin{array}{l}\text{Tuple/Record}\to \text{Row}\\ \\ \text{Attribute}\to \text{Column}\end{array}}{\to }}\text{Relational Model}$

2️⃣$\text{Relational Databases: }$利用$\text{Relation}$存储数据的数据库

1. $\text{Records}\underset{组成}{\overset{\text{一系列记录}}{\to }}\text{Relations}\underset{组成}{\overset{\text{一系列关系}}{\to }}\text{Relational Databases}$
2. $\text{Relations}\stackrel{\text{Populated With Actual Data}}{\to }\text{Instance/Table}$

3️⃣$\text{Cardinality/Degree}$

1. 含义

   	含义	备注
   $\text{Cardinality}$	表中$\text{Rows/Records/Tuples}$数量	表中记录可以无序，但要唯一
   $\text{Degree}$	表中$\text{Column/Attributes/Fields}$数量	$\text{N/A}$

2. 示例：$\text{Cardinality=3/Degree=5/All Rows Distinct}$
   

$\text{4.2. Key}$

1️⃣$\text{Super Key:}$

1. 含义：$\text{A set of attributes that uniquely identifies each tuple}$(一个/多个属性都行)
2. 特点：
   • $\text{Super Key Value}\stackrel{一一对应}{\leftrightarrow }\text{Tuple}$
   • 每个关系必定有一组属性组成超键(因为关系中每行必唯一)
   • 假设属性集$\text{A}$是$\text{Super Key}$，则$\text{A+}$任意其他$\text{Attributes}$也是$\text{Super Key}$
3. 示例：$\text{Super Key}$为names+login+age
   

2️⃣$\text{Primary Key(PK)}$

1. $\text{Key in a Relationship:}$
   • 最小化的$\text{Super Ksy}$，用最少的信息区分每一个$\text{Tuple}$
   • 即使是最小化，但也不一定只有一个属性
2. 两种键类型
   

   $\text{Key Type}$	含义	备注	示例
   $\text{Primary}$	唯一标识每个记录的属性(集)	每个关系只有一个主键	sid
   $\text{Candidate}$	所有可能作为主键的属性(集)	基本和主键混为一谈	login

3. 特殊键类型
   

   $\text{Key Type}$	含义	备注	示例
   $\text{Composite}$	多个属性组成的主键	无单一属性主键时适用	sid+name
   $\text{Surrogate}$	自定义的(代理)主键	无任何属性当主键，就自定义	$\text{N/A}$

   • 代理键在$\text{MySQL}$中的值，默认为$\text{1/2/3.....}$即$\text{Auto-Incremented}$

3️⃣$\text{Foreign Key(FK)}$

1. $\text{Foreign Key(FK)}$
   • 含义

     $\text{Type}$	概念	示例
     $\text{Primary key}$	确保表中每个记录都唯一，能唯一定位	course.cid, Student.sid
     $\text{Foreign Key}$	指向另一个表格中$\text{Data Entry}$	course.sid

   • 示例
     
2. $\text{Primary Foreign Key(PFK)}$
   • 含义：既是自的$\text{PK}$又是别的关系的$\text{FK}$，常见于$\text{Associative Entity}$ / $\text{Weak Entity}$
   • 示例：中间联结表的两个键
     

$\text{4.3. Integrity}$(完整性)

1️⃣$\text{Integrity Constraint:}$ 建立表格所要满足一下所有条件

$\text{Integrity Constraint}$	描述
$\text{Key}$	关系的$\text{Primary Key}$必须唯一
$\text{Referential Integrity}$	所有$\text{Foreign Key}$(引用)必须有效
$\text{Domain Integrity}$	作$\text{Data Type}$的区分，比如只给整数属性上输入整数数据
$\text{Entity Integrity}$	属性值可以$\text{Optional}$($\text{NULL}$)，或者必须有值($\text{NOT NULL}$)

2️⃣示例

操作对象	操作行为	结果
$\text{Enroll}$表	插入记录(其sid不存在于$\text{Student}$表)	违反完整性约束$\to$拒绝
$\text{Student}$表	删除一个记录	同时也删除对应$\text{Enroll}$表中的数据

$\text{5. ER→Relational Model}$

$\text{5.1. Entity Conversion}$

$\text{5.1.1. Single Entity}$

1️⃣转换原理

$\text{Entity}$的$\text{Attributes}$类型	操作
普通情况	正常转换
$\text{Composite Attributes}$	把复合属性展开($\text{Flatten}$)
$\text{Multi-Valued Attributes (Small/Fixed Number of Values)}$	展开
$\text{Multi-Valued Attributes (Large Number of Values)}$	创建新表(弱实体)
$\text{Derived Attributes}$	直接忽略

2️⃣$\text{Chen’s}$的转换示例

1. 普通情况：
   

   Employee(SSN(Key),Name,Age)
   

2. $\text{Composite Attributes:}$ 去除原有复合属性，展开内部的属性
   

   Employee(SSN(Key),Name,Age,Postcode,Street_name,Street_num)
   

3. $\text{Multi-Valued Attribute:}$ 去除原有多值属性，展开内部的属性
   

   Employee(SSN(Key),Name,Age,Num_1,Num_2)
   

3️⃣$\text{Crow’s Foot}$示例

1. $\text{Composite Attributes:}$ 去掉复合属性本身，展开复合属性内部的属性
   
2. $\text{Multi-Valued Attributes (Small/Fixed Number of Values)}\to$直接展开
   
3. $\text{Multi-Valued Attributes (Large Number of Values)}$
   • 建立$\text{1-N}$关系：$\text{1-Employee}\stackrel{\text{Plays}}{\to }\text{N-Roles}$，建立$\text{Role}$弱实体
     
   • 建立$\text{N-N}$关系：$\text{N-Employee}\stackrel{\text{Plays}}{\to }\text{N-Roles}$，建立$\text{Role}$弱实体$+$一个联结表
     

$\text{5.1.2. Weak Entity}$

1️⃣规则：其实也就是说辨认一个$\text{Weak Entity}$需要——自身$\text{PK+Strong Entity}$的$\text{PK}$

弱实体的键	规则	备注
弱实体的主键	强实体的主键$+$弱实体自身一/多个属性	$\text{N/A}$
弱实体的外键	强实体的主键	$\text{Aka PFK}$(外主键)

2️⃣$\text{Chen’s}$示例：箭头指向一侧的$\text{PK}$过来，到箭头的另一端当==$\text{PFK}$==

CREATE TABLE Dependent (
   dname CHAR(20) NOT NULL,
   age INTEGER NULL,
   cost DECIMAL(7,2) NOT NULL,
   ssn CHAR(11) NOT NULL,
   PRIMARY KEY (dname, ssn), -- weak+owner key as composite primary key
   FOREIGN KEY (ssn) REFERENCES Employees   -- refer to owner entity
   ON DELETE CASCADE -- Owner deleted, all weak entities deleted(确保完整性)
);

• 注意ON DELETE CASCADE，意思是主实体删除时，弱实体也随之删除

3️⃣$\text{Crow’s Foot}$示例

$\text{5.2. Relationship Conversion}$

$\text{5.2.1. Unary Relationship}$

$\text{Typle}$	处理方法
$\text{1-1}$	$\text{Put a Foreign key in the relation}$
$\text{1-N(Key Constrains)}$	$\text{Put a Foreign key in the relation}$
$\text{N-N}$	$\text{Generate an Associative Entity}$

1️⃣$\text{1-1}$关系示例：婚姻关系，一个人的主键变成另一个人的外键，即增加一个配偶$\text{ID}$外键

2️⃣$\text{1-N}$关系示例：员工(包含部分管理者)关系，管理者的主键成为员工的外键

3️⃣$\text{N-N}$关系示例：$\text{Item}$(包括各种$\text{Componment}$成分)关系，建立$\text{Componment}$弱实体

1. 弱实体的两个外键成为复合主键
2. 弱实体要包含关系的描述属性($\text{Descriptive Attributes}$)

$\text{5.2.2. Binary Relationship}$

1️⃣$\text{N-N}$关系：

1. 规则：
   • 建立$\text{Associative Entity}\stackrel{包含}{\to }\text{Descriptive Attributes+}$两边的$\text{PK}$(作为自身$\text{PFK}$)
   • $\text{Associative Entity}$是原有两实体的$\text{Weak Entity}$
   • $\text{Crow’s Foot}$转换时，关系种类交叉处理(详见示例红虚线)
2. $\text{Chen’s}$示例：创建新关系Works_In(ssn, did, since)
   

   $\text{Relations}$	$\text{PK}$	$\text{FK}$
   Employee(ssn, name, age)	ssn	N/A
   Department(did, dname, budget)	did	N/A
   Works_In(ssn, did, since)	ssn,did	ssn,did

3. $\text{Crow’s Foot}$示例：$\text{Conceptual}\to \text{Physical}$
   • 注意联结实体实质上是一个弱实体(实线)，联结实体的行数是联结两端的行数乘积
   • 原有的$\text{Crow’s Foot}$标志需要交叉放置
     
4. $\text{Implemetation}$

   CREATE TABLE Customer (
      CustomerID INT PRIMARY KEY, -- 此处记得空两格，记得逗号; 可以在此处就定义PK
      CustFirstName VARCHAR(45)
   );
   CREATE TABLE Address (
      AddressID INT,
      StreetNumber VARCHAR(45),
      PRIMARY KEY (AddressID)  -- 也可以在最末尾定义PK
   );
   CREATE TABLE Address_has_Customer (
      AddressID INT,
      CustomerID INT,
      AddressDateFrom VARCHAR(45),
      AddressDateTo VARCHAR(45),
      PRIMARY KEY (AddressID, CustomerID),
      FOREIGN KEY (AddressID) REFERENCES Address(AddressID), -- FK起始
      FOREIGN KEY (CustomerID) REFERENCES Customer(CustomerID)
   );
   

2️⃣$\text{1-N}$关系($\text{Key Constraints}$)

类型	规则
$\text{Crow’s Foot}$	$\text{PK from ONE side}\to \text{FK at MANY side}$
$\text{Chen’s}$	箭头指向一侧的$\text{PK}$过来，到箭头的另一端当==$\text{FK}$==，同时描述属性也过来

1. $\text{Crow’s Foot}$示例：一个客户有多个账户
   
2. $\text{Chen’s}$示例
   

   Employee (ssn, name, age)                   -- PK ssn
   Department (did, dname, budget, ssn, since) -- PK did + FK ssn
   
   

3️⃣$\text{1-1}$关系

1. 规则

   关系的$\text{Participation}$限制	$\text{Move the Key to the\_\_}$
   $\text{Optional-Optional}$	随意将一方的$\text{PK}$移到另一方作$\text{FK}$
   $\text{Mandatory-Mandatory}$	随意将一方的$\text{PK}$移到另一方作$\text{FK}$
   $\text{Mandatory-Optional}$	将$\text{Mandatory}$的$\text{PK}$移动到$\text{Optional}$作$\text{FK}$

2. 示例
   • 概念设计
     
   • 逻辑设计
     

$\text{5.2.3. Ternary Relationship}$

1️⃣规则：

1. 更具关系创建新实体，关系描述属性成为新实体的属性
2. 关系中三个实体的$\text{PK}\to$新实体中的$\text{PFK}$

2️⃣$\text{Chen’s}$示例

Contracts   (supplier_id,part_id,department_id) -- three of each are PFKs
Suppliers   (id,name)                           -- id(PK)
Parts       (id,name)                           -- id(PK)
Departments (id,name)                           -- id(PK)

3️⃣$\text{Crow’s Foot}$示例

1. 概念设计
   
2. 逻辑设计
   

$\text{5.3. Participation Constraint}$

1️⃣转为逻辑设计时，要指定属性$\text{NULL/NOT NULL}$，以确定是$\text{Optional/Mandatory}$

2️⃣示例：$\text{Eevery department MUST have a manager}$

CREATE TABLE Department (
   did INTEGER NOT NULL,
   dname CHAR(20) NOT NULL,
   budget FLOAT NULL,
   ssn CHAR(11) NOT NULL,   -- ssn 表示每一个Department必须有一个Employee
   since DATE NULL,
   PRIMARY KEY (did),
   FOREIGN KEY (ssn) REFERENCES Employee
   ON DELETE NO ACTION
);

3️⃣$\text{PK}$一定是$\text{NOT NULL}$的