具有某些特定条件的 ER 图
ER diagram with some specific conditions
假设我有 2 个关系：User 和 Location，它们由关系 going to 连接。现在，going to 有一个名为 date 的属性。如果用户恰好在一个日期最多只能在一个位置，我该如何绘制图表？多个用户可以去多个位置，但 date 属性强制执行某种唯一性条件。
我认为 date 在这种情况下不符合属性。属性是从实体（或关系）集到值集的函数，但 date 不是由 User 和 Location 决定的。相反，date 是关系的主题，就像 User 一样，所以我认为 date 是一个实体。 Location 在这个例子中更像是一个属性。
我认为问题不在于概念模型中的数据建模，而在于物理模型。这种情况的概念模型如下：
"Going to" 这里将被视为一个事件，即用户访问（任何）位置的时刻。由于我们这里有一个N-N关系，所以在created事件（创建的关系）中定义一个属性/属性是没有问题的。这将导致 table 带有两个外键。 table 告诉您用户访问某个位置的日期。
现在，谈谈施加的限制……是的，我们这里有一个限制，这将被视为 SQL 限制。对于一个人在某一天只去一个地方，你可以：
- 将 "user" 和 "date" 列定义为 "VISITS" table
复合主键。
- 定义 "user" 和 "date" 列 "VISITS" table 是
在复合形式中是唯一的，然后使用代理键，对于
实例.
总之，你得到这样的限制，这两列是唯一的，这将导致以下情况：
在此table（VISITS table）中您不能重复相同的用户和相同的日期。结果是一个用户在一个日期只能访问一个地方。
还有另一种方法可以解决这个问题。您可以在将新数据输入数据库时应用一些数据验证（添加新的访问记录）。如果每个日期的访问次数增加，这种方法可能会更好。我的建议是分析您的需求，看看将来是否有可能进行更改/维护。如果是这样，请考虑一下。
尽管验证数据是可能的，但请记住，您的数据库是防止数据不一致的最后一道防线。数据不一致是系统中最严重的问题之一，因为它可能会完全危及系统。因此，您不应该仅仅将验证作为不一致的对策。安全安装的数据库不允许不一致的数据。客户端用户在尝试执行非法操作时可能会收到错误消息，但永远不会保存损坏的数据。
遗憾的是，我对数据库的设置限制、规则和约束没有足够的了解，但一定要研究这个主题
如果您的需求发生变化。创建数据库时，理想情况是除了创建 tables、关系、触发器、存储过程外，还创建某些限制。这些是数据库中定义的规则，使它几乎总是一致的。
希望我在某些方面有所帮助。如果您有任何问题，请随时提出。
假设我有 2 个关系：User 和 Location，它们由关系 going to 连接。现在，going to 有一个名为 date 的属性。如果用户恰好在一个日期最多只能在一个位置，我该如何绘制图表？多个用户可以去多个位置，但 date 属性强制执行某种唯一性条件。
我认为 date 在这种情况下不符合属性。属性是从实体（或关系）集到值集的函数，但 date 不是由 User 和 Location 决定的。相反，date 是关系的主题，就像 User 一样，所以我认为 date 是一个实体。 Location 在这个例子中更像是一个属性。
我认为问题不在于概念模型中的数据建模，而在于物理模型。这种情况的概念模型如下：
"Going to" 这里将被视为一个事件，即用户访问（任何）位置的时刻。由于我们这里有一个N-N关系，所以在created事件（创建的关系）中定义一个属性/属性是没有问题的。这将导致 table 带有两个外键。 table 告诉您用户访问某个位置的日期。
现在，谈谈施加的限制……是的，我们这里有一个限制，这将被视为 SQL 限制。对于一个人在某一天只去一个地方，你可以：
- 将 "user" 和 "date" 列定义为 "VISITS" table 复合主键。
- 定义 "user" 和 "date" 列 "VISITS" table 是 在复合形式中是唯一的，然后使用代理键，对于 实例.
总之，你得到这样的限制，这两列是唯一的，这将导致以下情况：
在此table（VISITS table）中您不能重复相同的用户和相同的日期。结果是一个用户在一个日期只能访问一个地方。
还有另一种方法可以解决这个问题。您可以在将新数据输入数据库时应用一些数据验证（添加新的访问记录）。如果每个日期的访问次数增加，这种方法可能会更好。我的建议是分析您的需求，看看将来是否有可能进行更改/维护。如果是这样，请考虑一下。
尽管验证数据是可能的，但请记住，您的数据库是防止数据不一致的最后一道防线。数据不一致是系统中最严重的问题之一，因为它可能会完全危及系统。因此，您不应该仅仅将验证作为不一致的对策。安全安装的数据库不允许不一致的数据。客户端用户在尝试执行非法操作时可能会收到错误消息，但永远不会保存损坏的数据。
遗憾的是，我对数据库的设置限制、规则和约束没有足够的了解，但一定要研究这个主题 如果您的需求发生变化。创建数据库时，理想情况是除了创建 tables、关系、触发器、存储过程外，还创建某些限制。这些是数据库中定义的规则，使它几乎总是一致的。
希望我在某些方面有所帮助。如果您有任何问题，请随时提出。