关系数据库设计

关系数据库使用表状结构存储数据，以行和列形式组织数据。非关系数据库采用更灵活的数据模型，如文档、键值对或图形，以适应非结构化或半结构化数据。

范式等级： 1NF ⊆ 2NF ⊆ 3NF ⊆ BCNF ⊆ 4NF ⊆ 5NF 1971-1972 年，科德提出了 1NF、2NF、3NF 概念，讨论规范化问题；1974 年，科德和博伊斯提出 BCNF；1976 年，法金提出 4NF，后来有人提出 5NF。规范化条件按上述顺序逐级增强。 范式概念可理解为符合特定等级的关系模式集合，可表示为 R ∈ xNF。关系模式规范化设计过程是将低级范式关系模式分解为符合高一级范式的关系模式集合。

根据依赖关系 F={{Sno,Cno}→Grade，Cno→Teacher，Teacher→Dept}，可以绘制如下函数依赖图：技术进步的引领下，这些关系模式中存在部分函数依赖和传递函数依赖。为了消除这些缺陷，我们需要优化这些关系模式，以获得更有效的数据库设计方案。

关系数据库基于关系数据模型构建，其核心是关系数据库管理系统（RDBMS）。关系数据模型源于概念数据模型，用于设计逻辑数据模型，为关系数据库的构建提供理论基础。

定义关系的模式其实就像是给数据库打好地基。tR（U，D，DOM，F）这套形式，听起来像数学公式，其实挺直观的。tR是表名，U是属性集合，D是各属性对应的域，DOM是映射关系，而F就是属性之间的依赖规则。逻辑严谨，但理解起来不算难，关键是搞懂每一块的角色就行了。 像你在做数据库建模的时候，经常需要先理清这些关系。不然，后面表设计一乱，SQL 写得再漂亮也白搭。哦对了，数据依赖这部分重要，能影响表的规范化。推荐你看看这篇相关文章，讲得比较清楚：关系模式中的数据依赖。 要是你平时学生信息表、订单系统之类的，属性之间的依赖关系一多，越要搞清楚F这块。比如一个订单编号决定客户信息，那就是典型的函数依赖，

属性集闭包的计算，是数据库设计中绕不开的一步。关系模式一上来，先别急着建表，先看看它的函数依赖写得靠不靠谱。属性集闭包这个东西，说白了，就是给你一组属性，让你看看它到底能推出哪些别的属性。嗯，有点像从钥匙猜能开哪几个门，挺直观的对吧？ X+的求法其实也不难：初始给个集合 X，反复把能推出的新属性加进去，直到加不动为止。就像泡方便面一样，水一倒下去，面自然就开花了——关键是水要对，时间要够。你要是写代码模拟，也就一层循环的事。 这个算法好用的地方在于，你不用把所有函数依赖都列出来（那太吓人了），你只要关心某个属性子集能推出什么就行。比如你在做候选码判断、范式设计时，这一招就派上用场了。配合下文里

关系数据库术语解析 本讲义通过示例图标，解析以下关系数据库核心术语：* 关系* 关系模式* 元组* 属性* 域* 关键字* 外部关键字 思考题 结合上述术语，思考以下概念在示例图标中的体现形式：* 实体* 实体属性* 实体型* 实体集

东南大学徐教授的数据库导论课程涵盖：1. 关系数据模型2. 数据库管理系统实现3. 安全性与完整性约束4. 数据库设计5. 分布式数据库6. 数据仓库

关系数据库作为一种结构化数据存储方式，具有以下显著优势： 数据结构化: 采用特定数据模型组织数据，确保数据一致性和完整性，便于管理和维护。 资源共享: 允许多用户同时访问和使用数据，提高数据利用率，促进协同工作。 冗余度低: 通过数据规范化减少数据冗余，降低存储成本，提升查询效率。 可扩展性强: 能够灵活应对数据量增长和业务变化，方便进行系统扩展和升级。 易于开发: 提供丰富的 API 和工具，简化数据库应用程序的开发过程。

支持关系模型的数据库系统，就是咱们常说的关系数据库，像是 MySQL、PostgreSQL、Oracle 都是代表。这种系统最大的特点就是用表格结构来管理数据，行是记录、列是字段，清晰明了。关系操作集合挺好用的，SELECT、INSERT、JOIN 这些你肯定都不陌生，配合完整性约束，用起来又安全又靠谱。比如一个用户表和订单表通过外键连起来，就能自动保证数据一致性。讲到完整性约束，这块内容不少，像实体完整性、参照完整性、用户自定义完整性，该限制的时候限制，防止数据乱飞。你可以看看下面这些文章，细节讲得挺细，是做课程设计或者写业务逻辑的时候挺管用。比如SQL Server 的主从表关系那篇，讲了