Position
Any practice that is not based on solid theory is not worthy of consideration. I am a strict Relational Model practitioner, with a strong grounding in the theory. The Relational Model is based on solid theory, and has never been refuted 1. There is nothing solid in what passes for "relational theory", I have taken them on, and refuted their notions in their space. Further, Relational Database design is a science, not magic, not art 2, therefore I can provide evidence for any of the propositions or charges that I make. My answers are from that position.
1. The are non-science articles, and masses of opinions from those who do not understand the science, yes, but no scientific refutation. Much like pygmies arguing that man cannot fly, it is "true" for them, but not true for mankind, it is based on a complete inability to understand the principle of flight.
2. There is some art in the presentations of high-end practitioners, yes, but that does not make the science an art. It is a science, and only a science, and over and above that, it can be artfully delivered, in models and databases.
《关系论》
我想知道如何在关系中正确设置主键。例如。我们有 ER 图，其中包含以下元素：
如果它是 ERD，那么您将不会查看“关系”，您将查看实体（如果图表较早）或表格（如果已进行）。 “关系”是一个美妙的抽象，与实现无关。 ERD 或数据模型意味着一种实现（非抽象的、真实的）的意图，对物理的意图将抽象的理论世界抛在身后，进入物理世界，在那里愚蠢的抽象被破坏。
此外，声称为数据库空间服务的“理论家”无法区分基本关系和派生关系：虽然这在抽象上下文中可能是可以接受的，但在实现上下文中却是完全错误的。例如。基础关系是表，需要归一化；派生关系是基本关系的派生视图，根据定义是扁平化视图（不是“非规范化”，这意味着略有不同）的基础关系。因此，它们不需要标准化。
- 但“理论家”试图将派生关系“正常化”。受损最严重的两个国家正试图对 1NF 进行定义，我们已经使用了 45 年，这是根本性的、坚如磐石的，他们自己已经支持、改变了这一定义，以便他们的派生关系不需要“正常化” ”，可以归类为“标准化”。如果不是那么悲伤的话，那就太好笑了。
客观真理、科学的一个奇妙品质就是它不会改变。非科学的主观“真理”一直在变化。一个是可以依赖的，在进行实践之前必须理解它，另一个不值得阅读。
隔离
他们生活在自己的世界中，与关系数据库的现实隔离，特别是关系模型，以及他们声称服务的行业。自从四十五年以来RM出来后，他们没有采取任何措施来取得进展RM或关系数据库。
请注意，他们一直在推进各种各样的观念，这些观念超出了关系模型.
进展情况RM（尼安德特人所说的“不完整”的完成）的发生完全是由于标准化（R Brown 和其他人与 Codd 合作，产生了用于建模关系数据库的 IDEF1X 标准）以及高端 SQL 供应商和他们的努力。顾客。
那是商业 RDBMS 供应商，他们已经在 1980 年代建立，而不是过去十年的非 sql 免费软件/共享软件/vapourware 团体，他们将他们的产品冒充为“sql”，这让你很好并粘在他们的“平台”，非便携式。
最糟糕的是，他们出版了有关非关系概念的书籍，并欺骗性地将它们标记为“关系”。而“教授”们就像鹦鹉学舌一样，盲目地“教导”这些废话，而他们根本不理解这些废话，也不了解其本质。关系模型它应该探索。
从中可以得出的一点是，虽然在 E F Codd 博士发表他的开创性工作之后，关系理论和实践非常接近，但在供应商开发 SQL 平台期间，在后 Codd 时代，什么被称为“ “关系理论”完全脱离了原来的关系理论。
- 我可以列举差异，但不能在这里列举。请注意，如果您阅读我涉及此主题的帖子，您可以收集这些详细信息，并自己枚举它们。或者问一个新问题。
问题
我想知道如何在关系中正确设置主键。例如。我们有 ER 图，其中包含以下元素：
没有 ERD 可供检查。好的，在更新中你有一个例子。非常适合您的问题，因为它是一组数据的用户视图，现在可以开始建模。但请注意，这不是 ERD 或模型。我们依赖于对数据的理解；分析它；对其进行分类，而不是查看数据values用显微镜。我意识到这就是你被教导要做的事情。
为了将其转化为关系模型
是的，这就是既定目标。 “翻译”这个词不正确，因为RM不仅仅是一个人“满足”或适合的一组平坦或固定的标准（正如“理论家”所知），它还提供了具体的Methods and Rules。因此，我们将根据关系模型进行建模.
我们应该做一些技巧。
我们不需要技巧，我们用科学，而且只用科学。 “理论家”和追随他们的“教授”，需要技巧，实践非科学。在这方面我无能为力。此外，他们使用的伎俩通常是为了规避和颠覆关系模型，所以要小心他们。
代理人
上面的所有元素都处理关系的主键，但它们都是自然键 - 因此我们可以保留它们原样或用代理键替换。
好了，你的“老师”的第一招就暴露了。
代理是物理记录（而不是行）指针，它们不是逻辑的。
-
不存在“代理键”这样的东西，这两个词互相矛盾。
一个Key有一个特定的定义RM， 它一定要是由数据组成。替代品不是由数据组成的，而是被制造出来的，是系统生成的毫无意义的数字。因此它不是钥匙或“钥匙”。
一把钥匙RM具有许多关系特性，这使得键非常强大。由于代理不是钥匙，它不具有任何这些品质，它没有关系力量。
因此，“代理”和“密钥”各自具有特定的含义，作为单独的术语它们很好，但放在一起，它们是自相矛盾的，因为它们是对立的。
当人们使用术语“代理密钥”时，他们自然会期望密钥具有某些（如果不是全部）品质。但他们不会获得其中任何一个。因此他们被骗了。
-
The Relational Model (the one that the theoreticians know nothing about) has a specific Access Path Independence Rule. As long as Relational Keys are used, this rule is maintained. It provides Relational Integrity 1.
The use of a surrogate violates this rule. The consequence 2 is, Relational Integrity and Relational Navigation 3 are both lost.
其结果是，需要更多的连接才能获得相同的数据（不少于神话和魔法的爱好者不断鹦鹉学舌）。
因此，另一方面，代理人也是不允许的。
-
由于您处于建模阶段，无论是概念还是逻辑，键是逻辑的，代理是物理的，因此代理不应出现在图中。 （如果有的话，只有当逻辑模型完成并且正在考虑物理模型时，它们才会进入图片中进行考虑。）您还远未完成逻辑模型，因此引入代理应该会引发红色旗帜。
这位“老师”以及他所使用的“教科书”的作者在两个方面都是骗子：
那里有直接的科学、纯粹的逻辑、不受疯狂思维的污染，因此不会受到欺诈。逻辑阶段没有代理。
1. Relational Integrity (which the Relational Model provides) is distinctly different to Referential Integrity (which SQL provides, and Record Filing Systems might have). If you do not understand this, please open a new question "What is the difference ..." and ping me.
2. Breaking any rule has always has undesirable consequences, beyond the act itself.
3. If you do not understand this, please open a new question "What is the Relational Navigation ..." and ping me.
所以你的问题的最终答案是：
上面的所有元素都处理关系的主键，但它们都是自然键 - 因此我们可以保留它们原样或用代理键替换。
在概念和逻辑练习中，我们仅处理逻辑键。诸如代理之类的物理概念是非法的。在逻辑练习中，用物理生物替换逻辑密钥被拒绝。使用您拥有的密钥，这些密钥来自数据，并且是自然的。
不是“替代品”
还有一点。 “替代”一词是不正确的。代理永远不能替代自然密钥。
自然钥匙提供的众多品质之一是行唯一性，这也是要求关系模型，不允许有重复的行。
由于代理项不是行的键（它是指向记录的物理指针），因此它无法提供所需的行唯一性。如果您不完全理解我在说什么，请阅读这个答案 https://stackoverflow.com/a/29726132/484814，从顶部到假教师。测试给定的代码练习。
因此，即使在物理建模阶段考虑代理，也始终是一个代理附加列和索引。它不能替代自然的关系键。
反之，如果代理人is作为替换实现，结果是重复的行、非关系文件，而不是关系表。
Case 1
键属性是一个名称 - 因此它必须是 CHAR 或 VARCHAR 类型。通常，名称成为关键属性。
Yes.
通常它们是代码（用户确实使用代码）。通常，代码会跳到你的面前（你的代码中有一个很好的例子）再更新一则）。 {D|右 | B } 也可以 { }。这当然是在逻辑模型阶段的最后阶段，此时模型稳定，并且正在最终确定密钥并优化它们。对于任何早于该阶段的阶段，宽自然键都适用。
我们的想法是让它保持有意义。
键有意义（代理没有意义）。关系键的品质之一是，无论该键作为外键迁移到何处，该含义都会被携带。
-
根据您的示例，无论在何处使用它。包括程序代码。写作：
IF CrewType = "Backup" -- meaningful but fixes a value
IF CrewType = 1 -- meaningless
完全错误。因为 (a) 这并不是真正的键，并且 (b) 用户很可能会更改该数据的值Backup to Reserve等。切勿编写寻址数据值、描述符的代码。所以事实是，Backup是Key的投影、阐述，而代码就是Key。解析为 CrewType.Name，密钥为 CrewTypeCode。
IF CrewTypeCode = "B" -- Key, meaningful, not fixed
当我们使用 Keys 时，请注意：
In the 关系模型，我们有主键、备用键和外键（迁移的主键）。
-
我们没有“候选键”，在RM。这是在国外制造的东西RM。因此它是非相关的。
Worse, they are used by people who implement surrogates as "primary keys" a.
A physical consideration b, but one that should be understood and applied throughout the exercise. When the data is understood and known, the columns will be fixed length. When they are unknown, they might be variable. For Keys, given that they will be indexed, at least on the Primary side, they should never be variable, because that requires unpacking on every access.
a. The use the SQL keyword PRIMARY KEY does not magically transform a surrogate into a PK. If one follows the RM, one (a) determines the possible Keys (no surrogates), and then (b) chooses one as Primary, which (c) means the election is over, therefore (d) the nominated candidates can no longer be called "candidates", the event is history, therefore (e) the remainder, the non-primary Keys, are Alternate Keys.
"Candidate key" is a refusal to conform to the RM and nominate a PK, therefore, in and of itself, it is non-relational. Separate to the fact that they have a surrogate as "primary key", which is a second non-relational item.
b. For those non-technical people who believe that no technical knowledge and foresight, no physical considerations at all, should be evaluated during the logical, that's fine, evaluate them at the physical. Since I am not addressing the physical here, I am just making a note for Umbra.
魔术师依靠他们的魔术，让小兔子看起来像狮子。科学家不需要它们。
Case 2
两个（或多个）识别关系成为关系的复合主键（由外键组成）。
我认为您的想法是正确的，但对于一般情况，措辞不正确。
请阅读我的IDEF1X简介 http://www.softwaregems.com.au/Documents/Documentary%20Examples/IDEF1X%20Introduction.pdf小心。
1. The "theoreticians" do not differentiate Identifying vs Non-identifying, or Dependent vs Independent: all their files are Independent; all their "relationships" between record pointers are Non-identifying. It is a regression to the pre-1970's ISAM Record Filing Systems, devoid of Relational Integrity, power, and speed. That is all they understand, that is all they can teach. Fraudulently labelled as "relational".
Case 3
识别具有弱键属性的关系也成为复合主键。
与“key”有或没有关系的术语“weak”在关系模型。这是“理论家”的虚构。因此我无法回答这个问题。
Case 4
关联实体通常具有两个或多个识别关系
是的。二是正确的。
如果你有两个以上，那么这还没有完全标准化。 Codd 给出了一种明确的方法来规范化，这样就会有两个（或更多）关联实体，每个实体都有两个精确的识别关系。
- “......因此，所有 n 元（两个以上）关系......可以......而且应该解析为二元（两个）关系。”
（针对此上下文进行解释）
所以它们是连接关系（连接表）。
否。“Junction”关系和“Junction”表未在关系模型，因此它们是非关系的。
逻辑中的关联实体成为物理中的关联表。
回答太长
答案的完成超出了 SO 答案的限制。因此，我将答案放在一个文档中，并提供了一个链接。此时分割答案被证明是一种罪过，因此文档包含完整的答案，具有一致的格式等：
完整答案 http://www.softwaregems.com.au//Documents/Student%20Resolutions/Umbra%20Aeternitatis%20PrimaryKey.pdf
