Skip to content

Commit 99a94c9

Browse files
Sync from obsidian
2 parents 464e354 + 5632e88 commit 99a94c9

13 files changed

Lines changed: 624 additions & 6 deletions

File tree

.cursor/rules/learning-agent.mdc

Lines changed: 3 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -79,4 +79,6 @@ The minimum depth level is 1, and the maximum is 10. Lower depth levels cover fo
7979
10. Level 10: Cutting-Edge Research: Explore the latest research and discoveries, providing profound understanding of current progress and future directions.
8080
This standard can also represent the depth of content students expect to learn.
8181

82-
- If document formatting issues are found, they should be promptly raised using the `📝 A minor formatting suggestion` tag and appended at the end of the response
82+
- If document formatting issues are found, they should be promptly raised using the `📝 A minor formatting suggestion` tag and appended at the end of the response.
83+
84+
- When user requests an instruction similar to "completing notes based on the tag directory / the structure / the exists content of the note," please fill it in using concise, simple, and easy-to-understand language suitable for beginners, preferably supplemented with practical examples to aid comprehension.
38.4 KB
Loading
48.7 KB
Loading
48.7 KB
Loading
38 KB
Loading
26.2 KB
Loading
52.2 KB
Loading
Lines changed: 19 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,5 @@
11
---
2-
date: 2026-03-16 14:29:38
2+
date: 2026-03-22 15:08:38
33
title: 信息的三种世界及描述
44
permalink: info-description
55
publish: true
@@ -8,3 +8,21 @@ tags:
88
---
99

1010
# 信息的三种世界及描述
11+
12+
将现实世界以计算机能理解和表现的形式反映到数据库中,通常分为分为三个阶段,称之为三种世界:
13+
14+
- 现实世界
15+
16+
- 信息世界
17+
18+
- 计算机世界(数据世界)
19+
20+
![](assets/info-description/db-descr_example.jpg)
21+
22+
- 现实世界的事物及联系,通过需求分析转换成为信息世界的概念模型(数据库设计人员)
23+
24+
- 然后再把概念模型转换为计算机上某个DBMS所支持的逻辑模型(数据库设计人员和数据库设计工具DBMS)
25+
26+
- 最后逻辑模型再转换为最底层的物理模型,从而进行最终实现(DBMS)
27+
28+
![](assets/info-description/db-descr.jpg)
Lines changed: 245 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1,5 +1,5 @@
11
---
2-
date: 2026-03-16 15:23:00
2+
date: 2026-03-23 01:01:00
33
title: 关系模型
44
permalink: rela-model
55
publish: true
@@ -8,3 +8,247 @@ tags:
88
---
99

1010
# 关系模型
11+
12+
- 关系模型是数据库使用的一种典型数据模型
13+
14+
- 在关系模型中,其数据结构为具有一定特征的二维表
15+
16+
- 在关系数据库中,数据是以关系表形式存储实体数据
17+
18+
- 关系是一个由行和列组成的二维表
19+
20+
## 关系数据结构
21+
22+
### 关系
23+
24+
关系是单一的数据结构。无论是实体集,还是实体集之间的联系均由单一的关系表示。其逻辑结构为二维表,从用户的角度来说关系模型的逻辑结构就是一张二维表。
25+
26+
- 关系建立在集合代数的基础上。
27+
28+
- 元数据: 关于数据库结构的数据。如:表名,列名,表列的属性等。
29+
30+
### 关系中的基本术语
31+
32+
#### 元组
33+
34+
- **元组***Tuple*)是关系中的一****,对应表中的一条**记录**
35+
36+
- 一个 $n$ 元关系中的每个元组有 $n$ 个**分量**,分别来自各属性所在域;同一关系中任意两个元组不能完全相同(见下文[「关系的性质」](#关系的性质))。
37+
38+
#### 属性
39+
40+
- **属性***Attribute*)是关系中的一****,常称为**字段**;列头即**属性名**
41+
42+
- 同一关系中属性名互不相同;不同列可以来自同一域,但仍需不同属性名以区分语义。
43+
44+
- 属性有**类型**(及长度等),由该属性所来自的域及向域的映像决定。
45+
46+
#### 候选码
47+
48+
- **候选码***Candidate Key*)是能**唯一标识**关系中任意元组的**属性或属性组**,且具有**最小性**:从中再删去任一属性就不再能唯一标识。
49+
50+
- 一个关系可以有一个或多个候选码;多个候选码时除选作主码的一个外,其余常称为**备用码**
51+
52+
#### 主码
53+
54+
- **主码***Primary Key*)是从若干候选码中**选定**、在实现与约束上作为**主要唯一标识**使用的那一个(或那一组属性)。
55+
56+
- 主码用于实体完整性:主码属性不得为空(多属性主码时,组成主码的每个属性都不得为空)。
57+
58+
##### 主码选择的注意事项
59+
60+
- **稳定性**:优先选择现实世界中**不易改变**的业务标识(如学号),避免频繁变更主码及外码引用。
61+
62+
- **最小与明确**:在能唯一标识的前提下尽量**属性少**;语义上要能代表「这一行是谁」。
63+
64+
- **自然键与代理键**:若业务键过长、易变、或存在隐私/复合度过高,可另设**代理键**(见下)作主码,业务键仍可建唯一约束。
65+
66+
- **空值与组合**:主码属性不能为 `NULL`;多属性主码时需整体考虑唯一性,不能只保证其中一部分。
67+
68+
#### 代理键
69+
70+
- **代理键***Surrogate Key*)是系统生成的、**无业务含义**的唯一标识(如自增整数、UUID),仅用于在库内稳定区分行。
71+
72+
- 典型用法:表增加 `id` 作主码,自然业务键(如身份证号)另存并可加 `UNIQUE`;便于连接、迁移,且减少对业务规则变化的敏感度。
73+
74+
#### 全码
75+
76+
- **全码**:关系的**全部属性**合在一起才构成候选码(即不存在真子集能唯一标识元组)。多见于多对多联系单独成表且仅当所有列组合唯一时的情形。
77+
78+
#### 主属性
79+
80+
- **主属性**:出现在**任一候选码**中的属性。
81+
82+
- **非主属性**:不出现在任何候选码中的属性。
83+
- 规范化、函数依赖分析中常区分主属性与非主属性(例如求候选码、判断范式时)。
84+
85+
### 数据库中关系的类型
86+
87+
- 基本表(基本关系或者基表):实际存在的表,它是实际存储数据的逻辑表示。
88+
89+
- 查询表:查询结果表或查询中生成的临时表。
90+
91+
- 视图表:由基本表或其他视图表导出的表,是虚表,不对应实际存储的数据。
92+
93+
### 关系的性质
94+
95+
- 列是同质的,即每列中的分量是同一类型的数据,来自同一个域。
96+
97+
- 不同的列可出自同一个域,其中的一列称为一个属性,不同的属性要给予不同的属性名在同一关系中,属性名不能相同。
98+
99+
- 列的顺序无所谓,即列的次序可以任意交换。
100+
101+
- 任意两个元组不能完全相同,即关系中不能有完全相同的两条记录。
102+
103+
- 行的顺序无所谓,即行的顺序可以任意交换。
104+
105+
- 行与列的交集称为分量,每个分量的取值必须是原子值,即每个分量都必须是不可分的数据项,每个属性不能再分割。
106+
107+
### 其他概念
108+
109+
- 关系模式(Relation Schema)是型
110+
111+
- 关系是值
112+
113+
- 关系模式是对关系的描述
114+
115+
- 元组集合的结构
116+
117+
- 属性构成
118+
119+
- 属性来自的域
120+
121+
- 属性与域之间的映象关系
122+
123+
- 元组语义以及完整性约束条件
124+
125+
- 属性间的数据依赖关系集合
126+
127+
- 关系模式形式化定义:$R(U, D, DOM, F)$
128+
129+
- $R$:关系名
130+
131+
- $U$:组成该关系的属性名的集合
132+
133+
- $D$:属性组$U$中属性所来自的域
134+
135+
- $DOM$:属性向域的映象集合
136+
137+
- $F$ :属性间的数据依赖关系集合
138+
139+
- 关系模式通常可以简记为 $R(U)$ 或 $R(A_1, A_2, \ldots, A_n)$。其中 $R$ 为关系名,$A_1, A_2, \ldots, A_n$ 为字段名
140+
141+
- 域名及属性向域的映像常直接称为属性的类型及长度
142+
143+
- 关系和关系模式的联系与区别
144+
145+
- 关系模式是关系的框架或结构,是静态的、稳定的。
146+
147+
- 关系是按关系模式组合的表格,关系既包括结构也包括其数据,关系的数据是动态的、随时间不断变化的。
148+
149+
- 关系是关系模式在某一时刻的状态或内容。
150+
151+
- 实际应用中,人们通常把关系模式和关系都称为关系
152+
153+
- 关系数据库中关于表的三组术语对应的关系:
154+
155+
| 关系 | 元组 | 属性 |
156+
|:-:|:-:|:-:|
157+
||||
158+
| 文件 | 记录 | 字段 |
159+
160+
## 关系操作
161+
162+
关系操作的三大功能:
163+
164+
- **数据查询**: 数据检索、统计、排序、分组以及用户对信息的需求等功能
165+
166+
- **数据维护**: 数据添加、删除、修改等数据自身更新的功能
167+
168+
- **数据控制**: 为了保证数据的安全性和完整性而采用的数据存取控制及并发控制等功能
169+
170+
关系操作的数据查询和数据维护功能使用关系代数中的8种操作来表示,即*****Union*)、*****Difference*)、*****Intersection*)、**广义的笛卡儿积***Extended Cartesian Product*)、**选择***Select*)、**投影***Project*)、**连接***Join*)和*****Divide*)。
171+
172+
其中**选择****投影************笛卡尔积**是5种基本操作。其他操作可以由基本操作导出。
173+
174+
在关系模型中,关系数据库操作通常是用代数方法或逻辑方法实现,分别称为*关系代数**关系演算*
175+
176+
关系操作语言可以分为3类:
177+
178+
- **关系代数语言**: 用对关系的运算来表达查询要求
179+
180+
- **关系演算语言**: 用谓词演算表达查询要求
181+
182+
- **具有关系代数和关系演算双重特点的语言**: 如SQL
183+
184+
## 关系的完整性
185+
186+
- 关系模型的完整性规则是对关系的某种约束条件
187+
188+
- 关系模型允许定义3类完整性约束
189+
190+
- **实体完整性**
191+
192+
- **参照完整性**
193+
194+
- **用户自定义的完整性**
195+
196+
前两个完整性是关系模型必须满足的完整性约束,称为两个不变性;由关系系统自动支持。
197+
198+
### 实体完整性规则
199+
200+
- **实体完整性规则**: 若属性A是基本关系R的主属性,则属性A不能取空值
201+
202+
例如,学生关系“学生(学号,姓名,性别,专业号,年龄)”中,“学号”为主码,则“学号”不能取空值。
203+
204+
- 实体完整性规则规定基本关系的主码不能取空值,若主码由多个属性组成,则所有这些属性都不可以取空值
205+
206+
例如,学生选课关系“选修(学号,课程号,成绩)”中,“学号、课程号”为主码,则“学号”和“课程号”两个属性都不能取空值。
207+
208+
- 实体完整性规则是针对基本关系而言的。一个基本表通常对应信息世界的一个实体集
209+
210+
- 信息世界中的实体是可区分的,即它们具有某种唯一性标识
211+
212+
- 关系模型中以主码作为唯一性标识
213+
214+
- 主码中的属性即主属性不能取空值
215+
216+
### 参照完整性规则
217+
218+
- **参照完整性规则**: 若属性(或属性组)$F$ 是基本关系 $R$ 的外码,它与基本关系 $S$ 的主码 $K_s$ 相对应(基本关系 $R$ 和 $S$ 有可能是同一关系),则对于 $R$ 中每个元组在 $F$ 上的值必须为以下值之一:
219+
220+
- 取空值: $F$ 的每个属性值均为空值
221+
222+
- 等于 $S$ 中某个元组的主码值
223+
224+
- 主码(主键)与外码(外键)的列名不一定相同,唯一的要求是它们的值的域必须相同
225+
226+
!!! example
227+
学生关系和专业关系表示如下,其中主码用斜体标识:
228+
229+
学生(*学号*,姓名,性别,专业号,年龄)
230+
专业(*专业号*,专业名)
231+
232+
则“学生”关系中的“专业号”属性只能取下面两类值:
233+
234+
- 空值,表示尚未给该学生分配专业。
235+
236+
- 非空值,这时该值必须是专业关系中某个元组的“专业号”值。
237+
238+
### 用户自定义的完整性
239+
240+
针对某一具体关系数据库的约束条件的,它反映某一具体应用所涉及的数据必须满足的语义要求。
241+
242+
DBMS可以为用户实现如下自定义完整性约束:
243+
244+
- 定义域的数据类型和取值范围。
245+
246+
- 定义属性的数据类型和取值范围。
247+
248+
- 定义属性的缺省值。
249+
250+
- 定义属性是否允许空值。
251+
252+
- 定义属性取值唯一性。
253+
254+
- 定义属性间的数据依赖性。

0 commit comments

Comments
 (0)