Database 在数据库领域建模方面处理3NF，其中添加属性时知道它们创建了可传递的依赖关系

我目前正在建立一个数据库域模型，在规范化方面，由于可传递依赖性，我将面临挑战。但是，对于这个特定的模型，我们选择添加这种可传递依赖是有原因的，我想知道您将如何在规范化方面处理这种情况

让我来说明我的意思：

我有一个名为UserSubscription的表，它具有以下属性：

id {dbgenerated}
created
user
price
currency
subscriptionid

以下各项的值：

price
currency

取决于subscriptionid，它指向第二个表Subscription（其中subscriptionid是对该表PK的FK引用）。有人可能会说，为什么我甚至会考虑从<强>订阅< /强>表中包含重复的值到<强>用户订阅< /强>表中？原因是，订阅可能会在任何时间点发生变化，作为参考，我们希望将订阅的原始值存储在UserSubscription中，以便即使它发生变化，我们仍然拥有用户最初注册的值

从规范化的角度来看，我知道我创建的这个可传递的依赖关系应该是固定的，理想情况下，我会将值移回订阅表中，不允许修改值，而是在必要时创建一个新的订阅

但在理想情况下，我不想在存在的订阅中每次需要更改时都创建新的订阅，因为预期这些更改会经常发生，比如说市场竞争价值。同时，对于创建的每个新订阅，任何用户都将有更多选择

这也意味着，如果我们不想再使用订阅，我们需要：删除它，然后创建一个新的订阅。这可以通过简单的更新来解决，因为我们无论如何都不再需要旧的

---

以上是一个学校项目，我只是想知道，如果我选择这样做的话，在规范化方面选择这样的方法是否“合适”，并在我预计新订阅会频繁更改时减少与删除和创建新订阅相关的任务。

为什么不改为创建一个M:N表（映射表）用户与订阅之间的关系在哪里？您可以历史性地将所有值存储在那里，而不必删除/创建任何更改。。如果用户决定退出，您只需更新激活的标志、删除的标志、结束的标志、对您有效的任何标志

下面是一个简单的演示模型：

USER
id_user PK
name
... other details

SUBSCRIPTION
id_subscription PK
name
details
flag_active (TRUE|FALSE or 1|0 values)
... other details

USER_SUBSCRIPTION
id_user               FK
id_subscription       FK
dtime_start       -- when the subscription started
dtime_end         -- when the subscription ended
flag_valid (T|F or 1|0)  -- optional, will give you a quick headsup about active subscriptions ... but this is sort of redundant, for you can get it from the dtime_start vs dtime_end .. up to you

---

这将为您提供一个非常通用（因此具有灵活性/可伸缩性）的模型来处理用户的订阅。。。无重复，全部由FK/PK引用约束处理。。。etc

如果您只想存储原价，您不妨将其存储为Subscription.OriginalPrice（a la）。或者，更可能的情况是，您希望在历史记录表中存储属性子集的完整历史记录。不清楚具有相同subscriptionid的两行是否可以具有不同的价格货币对。您的意思是可以将subscriptionid更改为两行，使其具有相同的新值，而保留不同的旧价格货币对吗？如果可以，那么就没有FD了。PS这种设计不太可能来自于您所遵循的任何信息建模方法。PS“过早优化是万恶之源。”PS为什么你需要我们告诉你违反3NF的问题是什么？您的问题是什么？@philipxy的想法是，UserSubscription表中的subscriptionid用于引用值产生的“原始”订阅。因此，如果subscriptionid=5，那么我们仍然拥有订阅用来保存的值（这与这里的用户上下文相关，用户需要为此付费）。就我的问题而言，我试图清楚地表明我打破了3NF，我只是想知道这种方法是否有用，或者无论怎样，任何影响都是不好的。请通过编辑澄清，而不是评论。PS您还没有澄清“具有相同subscriptionid的两行是否可以具有不同的价格货币对”。是还是不是？根据您的描述（不清楚什么时候发生了更改；举个例子会有所帮助），2行可以（通过更新）具有相同的subscriptionid行，并且具有不同的（旧的）价格货币对；但如果这可以发生，那么就不存在传递性FD。PS将信息放在一个可用的表中（是否违反NF）是一个常见问题。似乎历史的c-p对只存储在这个表中，而当前的s并不能确定它，所以对于这篇文章的问题，设计很好。不去问你在一个已经发布的设计方法中陷入了什么境地的问题是——你希望得到一个什么样的答案？它必须重写你的方法的教程演示文稿，而不告诉我们你的方法是什么，或者你在哪里陷入了困境。信息建模方法和数据库设计方法并不是单一的。而且，如果你没有理由按照一种方法去做你正在做的事情，你为什么还要这样做呢？（修辞）谢谢你的投入，我考虑过用很多方法来解决我的问题，你也提供了这样一个例子。我的主要问题不是我如何解决它，而是我是否需要解决它。我试图找出为什么我的模型与3NF有关，而这个例子（在我看来）不是一个非常独特的例子，但可以应用于许多不同和类似的问题。这样做的目的只是为了降低每次发生变化时（通常情况下）必须向订阅表中添加更多模型的复杂性。我仍然不太确定您想要实现或获得什么