【发布时间】:2013-08-03 05:54:39
【问题描述】:
我使用两个在线资源来了解 5NF,没有任何严格的数学和证明。
- A Simple Guide to Five Normal Forms in Relational Database Theory(由 Kent 撰写。这一篇似乎在他的一篇著作中得到了 CJ Date 本人的审查和认可)
- Fifth Normal Form(维基百科文章)
但是,我无法理解这些参考文献中的任何一个!
让我们首先检查参考文献 #1(Kent 的)。
它说:“但是假设某条规则生效:如果代理销售某种产品,并且他代表一家生产该产品的公司,那么他为该公司销售该产品。”
然后,继续分解原始表(所有表名都由我给出)...
acp(agent, company, product)
-----------------------------
| AGENT | COMPANY | PRODUCT |
|-------+---------+---------|
| Smith | Ford | car |
| Smith | Ford | truck |
| Smith | GM | car |
| Smith | GM | truck |
| Jones | Ford | car |
-----------------------------
...分成3个表:
ac(agent, company)
cp(company, product)
ap(agent, product)
------------------- --------------------- -------------------
| AGENT | COMPANY | | COMPANY | PRODUCT | | AGENT | PRODUCT |
|-------+---------| |---------+---------| |-------+---------|
| Smith | Ford | | Ford | car | | Smith | car |
| Smith | GM | | Ford | truck | | Smith | truck |
| Jones | Ford | | GM | car | | Jones | car |
------------------- | GM | truck | -------------------
---------------------
但我什至不确定我是否理解上述规则的英语含义。我对上述规则的理解是,它的 'then' 子句完全是多余的!对于,
如果代理商正在销售产品
与
如果此代理代表生产该产品的公司,
那么,很明显,该代理正在为该公司销售该产品。
那么,这个声明中的“规则”在哪里?事实上,这对我来说似乎是一个非陈述!
从三个表(ac、cp 和 ap)向后推算,规则似乎真的是:“一家公司可能生产 1 种或更多产品,代理可能代表 1 或更多公司,而当代表一家公司,他可能会也可能不会销售其所有产品。”
但原始表 acp 已经捕获了此规则。所以,我不确定 5NF 的解释是怎么回事。
现在让我们看看参考文献 #2(维基百科)。
它说:但是,假设以下规则适用:“一个旅行推销员在他的曲目中具有某些品牌和某些产品类型。如果品牌 B1 和品牌 B2 在他的曲目中,并且产品类型 P 是那么,在他的曲目中(假设品牌 B1 和品牌 B2 都生产 P 型产品),旅行推销员必须提供由品牌 B1 和 B2 品牌生产的 P 型产品。”
再一次,按照这条规则的英语含义,别无其他,
如果一位推销员拥有品牌 B1 和 B2,以及他的产品 P,
与
如果产品 P 由 B1 和 B2 品牌制造,
那么,他到底为什么不能像原来的三列表'sbp(salesman, brand, product)那样提供品牌B1和B2的产品P ' 甚至在这个新的'规则'生效之前就已经很好地服务了?
有人可以澄清一下吗?
【问题讨论】:
-
它应该是“仅他为该公司销售该产品”。主键不能只是(公司,产品)吗?这将执行规则。
-
不,当您输入“only”时,它就变成了一个完全不同的问题。我想,我终于开始了解规则是什么,因此 5NF 是什么。我相信,无法理解规则是我的问题。谢谢,无论如何。
-
“显然”是错误的。一般而言,“如果代理商正在销售产品并且 [] 该代理商代表制造该产品的公司”,那么“该代理商正在为该公司销售该产品”可能是也可能不是这种情况;他们可能只将其出售给其他公司。但是他们必须为那家公司出售它当有一个规则时,如果...那么...。因此,给定的企业可能有也可能没有该规则。 PS
if x then y == (not x) or y所以当有一个规则是,要么不是 (...) 要么 ...。
标签: database-design relational-database database-normalization