0

所以在我的一个学校项目中，我们必须为一个伪电子商务网站创建一个数据库。项目说明要求我们使用 Boyce–Codd 范式来实现我们的数据库，但我认为这种范式存在一些歧义。

假设我们这样实现实体Users：

Users(*email, username, password, some_other_fields)

（注：*meens 主键）

首先，如果我很好地理解了 BCNF，那么这个实体就不是 BCNF。如果usernames 和 s 一样是唯一email的，那么我们也可以像这样定义这个实体：

Users(*username, email, password, some_other_fields)

我的第一个问题是如何以 Boyce–Codd 范式创建这个实体？

然后我对这个 BCNF 表格还有另一个问题：缺少id. 假设用户可以更改他的用户名和电子邮件。主键也将发生变化。我的问题是我真的没有一个时间常数来定义我的实体中的一个元素。这意味着，例如，有关日志记录的一些问题：假设我们使用主键记录用户的操作，如果foo@smth.com将他的电子邮件更改为foo2@smth.com，我们可以拥有这种日志：

[foo@smth.com] : action xxx
[foo@smth.com] : action yyy
[foo2@smth.com] : action zzz

然后，如果我们没有发现电子邮件更改，我们所有的先例日志都将毫无意义：我们不知道是谁foo@smth.com。

然后，我的第二个问题是，您不认为使用时间常数 id（例如整数）更安全吗？

4

1 回答 1

2

唯一性对于 BCNF 来说是不够的。BCNF 强调功能依赖。也就是说，属性是否在功能上依赖于键。

在这种情况下，属性不能依赖于电子邮件。电子邮件可以被其他人更改、停用和回收。因此，唯一性并不足以证明它是候选键。如果功能限制用户名被更改，用户名可能具有更高的可靠性。

功能依赖本质上取决于功能设计。如果您为其创建表的应用程序假定永远不允许更改用户名，则属性可以依赖用户名作为候选键。如果功能设计确实允许更改用户名，那么您需要引入或组合一个既独特又功能可靠的密钥。

如果引入了额外的唯一 ID，它们并不比此处的用户名“本质上”更“安全”。但是他们“感觉”或“变得”安全，因为大概功能和功能设计不期望 id 被更改。同样，如果您的功能设计允许更改该 id，那么这将不会保持安全。最终，这一切都取决于您的功能、要求以及您的属性如何根据该功能规范表现。

如果您必须考虑引入 ID，但对用户名的可靠性不满意，那么请考虑使用 GUID 而不是 int/integer，原因有很多，例如：

  1. int/interger 通常是周期性的，也就是说，它们在给定平台的限制之后回收，例如对于 16 位整数限制是 32767 到 -32768。GUID 也可能会再次出现，但在统计上这种可能性要小得多。
  2. 对于发生在不同子系统且需要稍后同步的操作，可能会创建非唯一 ID。考虑一个连锁店的两个商店，它们可以离线模式注册客户，然后在云端同步。第一个商店创建 ID 为 3000 的客户，第二个商店也这样做。当他们的数据同步时，您必须使用不同的复合键结构来适应它。GUID 具有更高的唯一性，可以解决它们。
于 2014-11-29T01:17:54.780 回答