数据库中“关系模式”的定义是什么？

哦，听到你这么说，我脑子里嗡嗡作响。
这是什么年纪了？现在仍然有人这样做。
关系模式和关系数据库听起来令人难以抗拒。

2 008 年我刚进入这个行业时，我正在为一家小公司做采购、销售和库存系统。
当时老板不懂事，非要让我用最新的技术，开发关系型数据库。
刚刚去看了《数据库系统导论》那些书，看得我头晕。

后来我想了一下。
说白了，关系模型就是一张表的结构。
就像我们现在使用的 Excel 一样，电子表格也有列和行。
列是属性，行是元组。
属性名称是列名称，例如“产品名称”和“数量”。
这些是 U，属性名称集。
每个属性的数据类型，例如“产品名称”是字符串，“数量”是数字。
这就是 D，属性集 U 中的属性所来自的域。

再比如，我们公司规定“产品名称”不能为空，这是一个限制。
另外，“金额”必须大于或等于0，这也是一个限制。
这些是F，属性之间数据依赖关系的集合。
说白了，就是规则，不能乱。

当时，我们的系统出现了一些问题。
有一次，有人把“金额”填成了负数，结果系统崩溃了。
这是因为完整性约束没有做好。
所以关系模型的约束非常重要。

后来我做了更多的项目，也遇到了类似的问题。
有时候，客户自己甚至没有想清楚需要什么样的表结构，需要什么样的约束。
结果，系统上线后，错误较多，调试时间也较长。

所以当你开发数据库时，你需要了解关系模型并设置约束。
不然以后会有很多麻烦。

数据库 关系模式 范式问题

哦，让我给你解释一下这个数据库设计问题。
看看这套F。
它包含相当完整的信息，包括订单号、客户号和产品号。
它还分为产品名称和价格。
包括电话号码在内的客户信息也很详细。
它就像一个大数据集合，包含着巨大的信息量。

我们先看L类别，即订单号、产品号、客户号和数量。
此四事。
由于这些信息在R中是独立的，即它们可以自己确定一条记录，因此它们应该是R的候选代码。
就像你可以从他的手机号码中获取这个人的所有信息。

然后看（订单号、产品号、数量）的组合，其中包括订单号、订单日期、客户编号、客户姓名、客户电话号码、产品编号、产品名称、价格、数量等信息。
也就是说，有了这三条信息，就可以找到整个订单信息，所以订单号、产品号、数量就是R的候选码。
我们先说范式。
在R中，非主要属性，即不参与确定记录的信息，取决于所有候选代码。
就像超市收银台一样。
每个产品的价格、数量和产品名称是根据您的订单号确定的，并不是随机生成的。
所以这个数据库符合第一范式。

说实话，我当时并没有考虑过候选代码和模式这个问题，但后来想想，我发现其实很简单。
就像你去超市一样，每种产品都有条形码。
条形码是确定产品信息的唯一标识符。
数据库中的候选代码也是如此，可以唯一确定一条记录。

数据库关系模式有哪些类型？

记得上次帮同事调试数据库时，他指着屏幕说：“为什么这个表的数据删除不了？”我一看，原来主要代码已经被删除了，但是表结构还存在，所以数据自然就消失了。
这让我想起了关系模型中的符号。
选择得好不好，直接影响到使用的顺利与否。

例如，我们公司的库存系统最初使用学生证作为主要代码。
然而，每次学生毕业并更新数据时，它都会崩溃。
后来我们转换为员工ID，系统运行了一年多，没有出现任何问题。
这类似于选择超级代码、候选代码和主代码。
看似一个小问题，但实际使用中，差别却很大。

我突然想到选课系统的例子。
Students 和 Courses 之间存在多对多关系，但通过Optional 表将其转换为多对多关系。
这种分解实际上与数据库设计中的模型理论相吻合。
当时的设计文件称“BCNF优先，最低3 NF可以接受”。
然而，在开发过程中，为了性能，它被修改为2 NF。
现在我有时会收到测试评论“某所大学的课程重复”。

等等，还有别的事。
我记得当我第一次学习数据库时，我常常将“属性”和“元组”混淆。
老师举了超市收银员的例子：收银台扫描到的商品（条形码、名称、价格）是行，整个购物车结构（商品种类、规格条目）是属性。
现在想一想，这不就是关系模型定义中的U和D吗？
降级标准是指“无损通信”。
上周重建用户表时我几乎没有注意到这一点。
我已将用户 ID 和手机号码分成两个表。
事实证明我忘记创建外键约束。
结果后来查询用户关联的手机号时，系统居然跑出了两条记录……这让我想起了drop操作，在U1 上drop F，F1 ，F2 ……drop。
我真的需要了解投影仪的原理。

手机号码现在已添加回用户表中，但这次添加了一个触发器来验证唯一性。
有时候我觉得数据库设计就像做饭。
起初我想我用了更复杂的食谱（BCNF），但尝过之后我发现它太糟糕了，我最终做了自制的3 NF。