将具有频繁重复字符串值的关系属性分开是否合理？
Is it reasonable to separate relation atributes with frequently duplicate string values?
考虑关系 SPACESHIP_FLAT:
╔═════╤════════════════╤════════════════╤═══════════╗
║ ID │ NAME │ TYPE │ LV ║
╟─────┼────────────────┼────────────────┼───────────╢
║ 1 │ Soyuz TMA-14 │ Soyuz │ Soyuz-FG ║
║ 2 │ Endeavour │ Space Shuttle │ Shuttle ║
║ 3 │ Soyuz TMA-15M │ Soyuz │ Soyuz-FG ║
║ 4 │ Atlantis │ Space Shuttle │ Shuttle ║
║ 5 │ Soyuz TM-31 │ Soyuz │ Soyuz-U ║
║ 6 │ EFT-1 │ Orion │ Delta-IV ║
║ 7 │ XXX │ CST-100 │ Delta-IV ║
║ 8 │ YYY │ CST-100 │ Falcon-9 ║
║ 9 │ ZZZ │ Dragon V2 │ Falcon-9 ║
║ ... │ ... │ ... │ ... ║
╚═════╧════════════════╧════════════════╧═══════════╝
此处属性 TYPE 和 LV 具有重复的字符串值。所以我的问题是：将这些属性投射到新的关系中是否合理？结果将如下所示。
SPACESHIP
╔═════╤════════════════╤═══════╤══════╗
║ ID │ NAME │ TYPE │ LV ║
╟─────┼────────────────┼───────┼──────╢
║ 1 │ Soyuz TMA-14 │ 1 │ 1 ║
║ 2 │ Endeavour │ 2 │ 2 ║
║ 3 │ Soyuz TMA-15M │ 1 │ 1 ║
║ 4 │ Atlantis │ 2 │ 2 ║
║ 5 │ Soyuz TM-31 │ 1 │ 3 ║
║ 6 │ EFT-1 │ 3 │ 4 ║
║ 7 │ XXX │ 4 │ 4 ║
║ 8 │ YYY │ 4 │ 5 ║
║ 9 │ ZZZ │ 5 │ 5 ║
║ ... │ ... │ ... │ ... ║
╚═════╧════════════════╧═══════╧══════╝
SSTYPES
╔═════╤════════════════╗
║ ID │ TYPE ║
╟─────┼────────────────╢
║ 1 │ Soyuz ║
║ 2 │ Space Shuttle ║
║ 3 │ Orion ║
║ 4 │ CST-100 ║
║ 5 │ Dragon V2 ║
║ ... │ ... ║
╚═════╧════════════════╝
LVEHICLES
╔═════╤═══════════╗
║ ID │ LV ║
╟─────┼───────────╢
║ 1 │ Soyuz-FG ║
║ 2 │ Shuttle ║
║ 3 │ Soyuz-U ║
║ 4 │ Delta-IV ║
║ 5 │ Falcon-9 ║
║ ... │ ... ║
╚═════╧═══════════╝
我已将我的关系模型规范化为 5NF，并且发现没有理由将 TYPE 和 LV 从关系中分离出来（这些不会导致更新异常）。但是如果 SPACESHIP_FLAT 关系中有大量元组，它将消耗大量资源（正如我所想的那样）——因此将它们分开会更有效率一些。但是我在数据库设计理论中没有找到。
更新
好的，让我们澄清一些要点。
Attribute TYPE entirely depends on attribute NAME. NAME indicates an instance of class TYPE - one and more instances belong to one class. Soyuz TMA-14 is an instance of Soyuz ship series. So it can have one and only one value of TYPE. Relationship between two sets of values NAME and TYPE is many-to-one (no multivalued dependency).
Attribute LV depends on attribute NAMEin the same manner.
But if I eventually decide to clarify the Soyuz TYPE and set all the Soyuz TMA-XX spacecrafts as Soyuz TMA TYPE, Soyuz TM-XX as Soyuz TM and so on then I need to update each Soyuz* record no matter if I use the first variant with flat relation or variant with three different relations. The second one will ease editing value Soyuz (so it looks better in terms of data integrity).
As for surrogate keys - I use 'em because I need them to be represented in cross-reference relations (many-to-many, even SPACESHIP_FLAT or SPACESHIP- there are no top-level relations in my data model).
当然，您应该将这些类型分成不同的实体。这不仅会给space的经济带来好处，更重要的是会给你带来约束。因为现在我可以在这些列中输入任何值，例如 Blabla 或 Michael Jordan。但是当您创建单独的实体并添加一些约束时，您将只能在这些列中输入批准的值。
可以说我将从业务层管理那些东西，但在一本好书中说：
If your column accepts NULLs, and you have implemented some strong logic which prevents entering NULLs from BL, anyway NULL will always find its way to your column.
您现在可以轻松地对您的列类型说同样的话。
初步
不知道你看的是什么书，但我注意到现代书都是垃圾。你的单曲table是一个平面文件。
你有两个table的名字叫SPACESHIP.为了避免混淆，我就叫单table版本SPACESHIP_FLAT.
I've normalized my relational model to 5NF
抱歉，这不是规范化的。甚至不到 1NF。
如果我们从字面上看 1NF 和 2NF，在 post-Codd 时代写书的那种 non-experts，当然，它 "satisfies" 1NF 和2NF.
但是如果我们考虑到我们不需要一长串例外情况，那么我们不是试图破坏 1NF 和 2NF 的定义，那就是我们本着精神和意图接受它，那么您的单个文件将无法通过 1NF 和 2NF。
同样，对于 well-informed 人类，3NF 的 Codd 定义是完整的。但是新人需要BCNF, 4NF, 5NF, 十几个还没写出来的NF，从精神和意图上接近原来定义认为是3NF的Normalization水平。
它也不是关系型的，因为它打破了关系模型中的许多规则。
你只有代理，记录 ID，这是 pre-relational 时代的产物，大多数现代作者已经退化到那个时代，因为这是他们唯一能理解的东西。但他们错误地将其标记为 "relational".
因此您没有关系完整性（与参照完整性不同）、能力或速度。
明确禁止记录 ID 等。
and found no reason to separate TYPE and LV from the relation
对不起，这也不是关系。它是普遍关系，派生关系，所有关系的扁平化视图。
请注意 post-Codd 作者没有（也不能）区分基本关系和派生关系，他们试图 "normalise" 两者，并尖叫 "SQL can't ..." 和 "Relational Model doesn't ..."。这实际上只是证明了他们的无能。
眼下，原模型的两个最大对手正在对1NF发起攻击。
我们只需要标准化和设计基础关系。
these does not cause update anomalies.
对不起，又是假的。这可能意味着您不了解更新异常是什么（相反，您的平面文件没有它们）。
有几种不同类型的更新异常。他们可以被定义为一个群体，通过以下简单的（即简单的，技术性的，不完整的学术性的）定义。
An Update Anomaly is one where, when you need to update just one row, the tables are such that other rows (in the same or other table) must also be updated, in order to preserve integrity and Consistency of the data.
如果我UPDATESPACESHIP_FLAT文件的记录ID 5中的TYPE字段，从Soyuz到Proto-Soyuz，那么记录 1 和 3 不再一致，它们也必须更新。那是更新异常。
如果我在稍微规范化的 three-file 版本中进行相同的更新，我 UPDATE SSTYPES 的记录 ID 1 中的 TYPE 字段文件，从 Soyuz 到 Proto-Soyuz，该更改将反映在使用 SSTYPES 的投影中。无需更新其他记录。没有更新异常。
更新异常是 结果 无效或不完整的规范化。它是一面旗帜，一个警钟。它本身是无法纠正的，你必须回到规范化阶段，在那里纠正它。
注意。这只是一种更新异常。但它们都是归一化练习中错误的结果。
But in case of huge numbers of tuples in SPACESHIP relation it will consume a lot of resources (as I suppose) - so separating them will be a bit more efficient
好点，当然是，但不是出于正确的理由。正确的原因和程序 导致 分离 tables 具有关系完整性，效率更高，等等，等等，
But I did not found it in theory of database design.
那是因为没有正确教授数据库设计和关系理论。看过的书都烂透了，爱丽丝的书尤其烂
诚信
你不明白的是，单个文件中的数据没有完整性。 three-file 组合中的数据更完整，但不是 关系模型 提供的完整数据集。
回答
因此，three-file 集群比单个文件更标准化。
但它需要更多的规范化、更多的关系化才能完成。
删除记录 ID。
如果您想详细了解 Record ID 的可怕之处，请阅读 ，从顶部到 False Teachers，以及查找表部分。
保持规范化（你做得很好，直观地理解它），直到你有：
没有任何重复数据
你需要的所有事实（数据库是关于现实世界的事实的集合）
表示为关系键
那么您将拥有一个关系数据库。
把那些书扔掉。只读 E F Codd 博士。他的论文是免费的，但术语是 out-of-date，而且它是开创性的，某些术语的含义已经丢失（或被积极压制）。
回复评论和更新
And trying to create logical model as optimal as possible.
是的。所以我们会把这个问答保留在逻辑模型层面。当它被解决、归一化、优化（仅在逻辑级别）时，您就可以继续进行物理模型了。
在这种情况下，请注意 ID 字段是物理字段，而不是逻辑字段。 ID 字段不存在于正在考虑的数据中（讨论域）。现代书籍会误导 reader，为所有事物引入 ID，以及其他危害科学的罪行。删除它们，然后我们可以开始 逻辑模型。我们不能开始 当数据被感染时，当它包含在纯未受污染的数据中不存在的额外污染物时。
Attribute TYPE entirely depends on attribute NAME. NAME indicates an instance of class TYPE - one and more instances belong to one class. Soyuz TMA-14 is an instance of Soyuz ship series. So it can have one and only one value of TYPE.
（我将使用关系术语，而不是 OO/ORM 术语。我们没有 类 和实例，我们有域和元组或行。）
Relationship between two sets of values NAME and TYPE is many-to-one (no multivalued dependency).
理解并接受。除了一个例外：你的两个段落意味着 NAME 依赖于 TYPE，而不是相反（你的开头句与其余句相矛盾）。
现在在关系模型中，我们有依赖度。
典型的查找 table 被引用，以及记录归档系统中的所有文件，其中不能说主题（引用）table 行不能除非引用的 table 存在，否则依赖项为 Non-Identifying。关系线为虚线。
关系数据库中绝大多数 table 的典型（减去那些 Lookup table），其中主题 table 行仅存在于引用 table 的上下文，依赖关系是识别的。父PK用于形成子PK。感情线稳固。
如果 SPACESHIP 仅存在于 TYPE 的上下文中，则 SPACESHIP (a) 依赖于 TYPE，并且 (b) TYPE PK 用于形成 SPACESHIP PK。
我倾向于认为SPACESHIP is Dependent on both TYPE and LAUNCH_VEHICLE, TYPE and LAUNCH_VEHICLE各自标识SPACESHIP.
Attribute LV depends on attribute NAME in the same manner.
没有。被诅咒的人扰乱了你的大脑。 NAME 取决于 LAUNCH_VEHICLE (LV)，而不是相反。
But if I eventually decide to clarify the Soyuz TYPE and set all the Soyuz TMA-XX spacecrafts as Soyuz TMA TYPE, Soyuz TM-XX as Soyuz TM and so on then I need to update each Soyuz record no matter if I use the first variant with flat relation or variant with three different relations.*
完全正确。
这正是我说您的模型不在 1NF 中的原因。你的"name"其实不是一串字符，它是由零件组成的。这些部分具有特定含义（Date 无法理解）。这些部分实际上是 (a) TYPE (b) LAUNCH_VEHICLE，和 (c) 尚未阐明的内容。 TMA vs TM-XX 有意义，它与 TYPE 相似，但是是一个单独的集合。
我会让你解决 (c)。注意重复；弄清楚每个组成部分的含义；等。然后将其提取到单独的 table.
真正的名字是 Discovery、Endeavour、Volna、Yenesei、Lena 等。标有 NAME 的东西是正式分类词（TYPE、LAUNCH_VEHICLE 和 XXXX）的串联。
The second one will ease editing value Soyuz (so it looks better in terms of data integrity).
我们不关心科学的外表。这是对还是错。某一列要么具有数据完整性，要么不具有。第一个没有任何数据完整性，第二个具有一定的数据完整性（已经讨论过，还有更多内容）。
As for surrogate keys - I use 'em because I need them to be represented in cross-reference relations (many-to-many, even SPACESHIP_FLAT or SPACESHIP- there are no top-level relations in my data model).
没有"surrogate key"这样的东西。它只是一个替代品。它具有钥匙所具有的 none 品质。因此，"surrogate key" 一词具有欺诈性，因为人们自然会期望钥匙具有某些（如果不是全部）品质，而它不具备任何这些品质。
代理是物理的，不是逻辑的。在这个逻辑阶段我们不需要它们。
我们不需要关系模型中的代理项。特别是不用于关联行。关系模型之前的记录归档系统使用记录 ID（物理、代理）来关联记录。关系模型的最大区别在于它使用逻辑键而不是记录 ID（物理、代理）来关联行。
任何人都可以通过数字关联电子表格中的条目。需要更多的理解才能 (a) 放弃数据的电子表格视图，以及 (b) 通过 Key 关联条目。
One-to-one； one-to-many; many-to-many，使用Keys，一点问题都没有。
that cancer-causing book is C. J. Date. Introduction to Database Systems - contained more theory on database systems of all books I've managed to grab (in my native language).
那又怎样：不好就是不好。如果它加深了对关系模型的理解，它加深了对关系模型.
的理解
证据，无论是在这个问题中，还是在每个项目中，这种风格的追随者都会产生 anti-relational 结果。在这里，他让您认为您正在生成符合 关系模型 的逻辑模型，但证据是，它是一个 anti-relational 物理文件系统，具有 none 关系数据库的能力、完整性、能力或速度，具有 pre-relational 记录 ID。
如果您需要更多证据，请查看我在 SO 上的回答（转到我的个人资料）。请注意，寻求者是真正的人，他们和您一样，正在关注那些书籍，并创建了可怕的文件系统，同时相信 "relational" 和 "database"。这才是Date真正的成功。
这些 anti-relational 的书很畅销。现在它们被用作大学的教科书。所以呢。他们还是错了。
我再说一遍，扔掉那些书，只读 Dr E F Codd。当然，还有 Codd 的真正门徒。不是那些引用 Codd 而是教导相反的骗子。
C. J. Date said that 5NF will not make the relation free from all update anomalies (as you've shown on SPACESHIP_FLAT example).
戴特和他的同事们一直在破坏科学。科学基于 objective 真理。他们一直在把它变成主观真理。在 Codd 时代，我们有 1NF、2NF、3F。是objective，没有人争论。
"mathematicians" "improve" 科学的时代到来了。他们在 3NF 中找到了 "holes"，这是一个诚实的人不会找到的。他们将 "theses" 和 "mathematical definitions" 写到 "plug the holes" （他们自己不诚实制造的漏洞）。所以现在他们有了 BCNF、4NF、5NF。对于我这样的人来说，这些都是多余的废话。
他们互相争论什么是 NF，什么不是，关于什么是数学证明，什么不是。现在 Date 和 Darwen 正试图改变 1NF 的定义，以适应他们自己的目的，在它已经被数百万人定义和使用了 45 年之后。
他们中的大多数人同意（截至今天，但明天可能会改变）5NF 确保没有更新异常。
I have several large banking databases that were honest 3NF, long before 5NF was hatched, I made written declarations that they did not have Update Anomalies. My customers had occasion, ten years later, after 5NF was hatched, to ask me to comply with 5NF, in order to ensure no Update Anomalies. I examined the old 3NF data model, and to everyone's surprise, it "satisfied" 5NF, and no surprise, it did not have any Update Anomalies.
How did that happen ?
By
(a) being technically honest (ie. not trying to find ways of not-complying, while looking like I am complying) and
(b) Normalising according to science and principle (ie. not according to the fragments of NFs in the form of "mathematical definitions")
I just Normalised, and ensured that there were no Update Anomalies.
That act, ensured that the database would "satisfy" BCNF, 4NF, 5NF, and any other NF that has not been defined or "mathematically defined" yet. As evidenced.
As far as I am concerned, based on my 36 years in the science, BCNF, 4NF and 5NF, are all simply their 3NF restated (they re-defined 3NF after Codd died).
- They need it to "plug holes" because they subvert the Codd definition of 3NF, and then, that subverted "definition", sure enough, has "holes". Being fraudsters, they will be finding "holes" and "plugging holes" for the rest of the century.
Meanwhile, back at the farm, honest men use the Codd definition for 3NF, in which there are no holes, there is nothing to plug.
Up to 2007, I was producing databases that were 95% DKNF, according to the Codd definition and intent in the Relational Model. That last 5% was prevented, due only to a limitation in SQL. Since 2007, when the last obstacle was removed, I have been producing 100% DKNF databases.
- But the "theoreticians" flatly state that it cannot be done. They are relying on their "mathematical poofs". I am relying on Codd's definition.
Even when I wrote to the authors of the DKNF "mathematical definition", and gave them a full data model plus diagrams plus documentation, it turned out, they couldn't understand it.
- They understand only (a) "mathematical definitions" that are (b) based on their previous "mathematical definitions".
- A fraud in and of it self.
- A proof, in and of itself, that they do not understand Codd or his Relational Model. Let alone follow his model or his intent.
根据他们自己提供的证据，post-Codd 作者不理解 关系模型 。非常严肃地注意这一点：因此他们不知道，他们不理解关系模型提供的是什么：关系完整性（与参照完整性不同）；关系力量（在你的质疑水平上，这意味着加入力量）；关系速度。他们只知道RFSnon-integrity； RFS 导航； RFS 速度。
更新异常
底线：
- 通过科学、原则、逻辑规范化。最重要的是，通过 Codd 在 关系模型 .
中给出的方法
不是 NF 定义。无论如何，您不能通过 NF 定义进行规范化，因为它们没有提供任何方法。
注意Codd在RM明确定义了两个NF，post-Codd时代写书的怪胎，声称成为 "relational" (a) 否认和 (b) 压制，只是在他们被诅咒的书中从不提及它们或方法。
- 通过了解什么是更新异常来防止更新异常。
不是转瞬即逝的 "mathematical definition"，因为 (a) 不会产生没有更新异常的数据库，(b) 他们争论是否 "mathematical definition" "proves" 它提议证明什么，以及 (c) "mathematical definitions"、证明和论证，一直在变化。
这就是pseudo-science的主观真理（non-permanent，不断变化）的所有证据。科学基于 objective 真理。 objective 真理的特性之一是，它是永恒的，不会改变。
另请注意，Philip 的 "update anomaly" 概念是一种观点。和几十年前的定义无关，是objective的真理。虽然您的数据模型无法防止更新异常（根据我提供的证据），但它很可能 "satisfy" 某人，任何人对杂碎的看法。同时，不管这些 ever-changing 意见如何，数据模型仍然无法防止更新异常。
One more question: do I need to get rid of all surrogate keys?
是的。如果你想要一个关系数据库。如果您对具有 none 完整性的记录归档系统感到满意；力量;或关系数据库具有的速度，您可以保留它们。以及 RFS 附带的所有体力劳动。
如上所述。它们是物理的，而不是逻辑的。它们不是密钥，它们是记录归档系统中的 pre-relational 物理指针。
任何特定 post-Codd 作者使用记录 ID 的事实，证明该作者不了解 RM[=402 中最基本的基本要求=].他们只懂 RFS，因此他们只能教这些。
他们在逻辑模型级别教授记录 ID 的事实证明他们正在积极地进行欺诈，使物理 ID 看起来像逻辑对象，使其看起来像 "key". Anti-relational.
代码
If so - how it will affect foreign keys, JOINs?
你是什么意思？你需要代码吗？好吧，你的模型还不够先进，无法编写代码，而且我无法使用它现在拥有的 ID。让我们使用这个 Data Model.
那是一个IDEF1X数据模型。 IDEF1X 是关系数据库建模的标准，我们自 1987 年以来一直拥有（自 1993 年以来作为标准）。 Date、Darwen、Fagin 等人避开它，他们只使用文本，或者发明他们自己的 "diagrams"。使用标准会将他们的方法公开为 sub-standard.
请注意每一个小滴答；缺口;并做标记；鱼尾纹；实线与虚线；方角与圆角；意味着非常具体和重要的事情。参考IDEF1X Notation。如果您不理解符号，您将无法理解或工作模型。
外键为粗体，并使用与父 PF 完全相同的列名。例外情况是 (a) 同一父项有多个 FK，或 (b) 为清楚起见，我们使用 RoleNames.
TaxonomyNo 对您来说可能看起来像一个代理人，但它不是。该模型非常成熟（第七次迭代）。请注意它是如何用于构建分类法的层次结构 类。这与 Unix Inode（也是数字，而不是代理项）的实现相同，后者以其简单和强大而闻名。
让我们得到一份使用 many-to 许多关系的报告，例如您所关心的。列出所有物种（不是整个分类树，只是叶级别）及其活动。 "Activity" 是 CHAR(X) 代码，我们要 Name:
SELECT [Species] = T.Name,
[Activity] = A.Name
FROM Species S
JOIN Taxonomy T
ON S.SpeciesNo = T.TaxonomyNo
JOIN SpeciesActivity SA
ON S.SpeciesNo = SA.SpeciesNo
JOIN Activity A
ON SA.Activity = A.Activity
And is it ok to realize many-to-many relationships between two entities using composite PRIMARY key that consists of two foreign VARCHAR keys?
是的。那是正常的，行人的，普通的。这就是关系的意思，通过键关联。关系数据库中的大多数键都是复合键（复合）。
物种Activity就是一个例子。
在 table 上使用 ID 列完全是多余的，因为组合 (SpeciesNo, Activity) 是唯一提供行唯一性的组合；就这样PK了。
再多的 "unique" 记录 ID 也无法改善这一点。
并且如果它不是声明的PK，无论使用了多少"unique"记录ID，那么重复行将得到保证。
下一点是关于物理的，而不是逻辑的，但我不会回避它。那个 VARCHAR 必须离开。到处使用 VARCHAR 是另一个错误。
始终使用固定长度，只有在绝对必要时才使用可变长度。
在 Keys 中使用 VARCHAR 特别糟糕，因为它最终出现在一个或多个索引中，这意味着每个索引条目都必须是 packed/unpacked，每次访问这些条目时。
如果您不知道长度应该是多少，这本身就证明您对数据的了解不足以对其建模。所以去了解数据，了解并喜欢它。不是为了去除 VARCHAR，而是为了建模之前要求的熟悉度。
回复评论 2
So database model which is in MySQL Workbench can not be called logical model, does it?
抱歉，我不知道像 MySQL 这样的免费软件能做什么（我很清楚它们不能做什么），除非万不得已，否则我不会碰它们或 PC，所以我真的不能回答这个问题。
不过我能猜到。这个问题意味着它自动包含 ID 字段。查看是否有阻止该行为的设置。如果不是，那么是的，它不能用于 逻辑模型，或关系数据库的物理模型。不管你怎么称呼它产生的东西。
If I remove all IDs from the relations then I will get the same relations (as SPACESHIP_FLAT) but with Foreign Key constraints on attributes TYPE and LV as well as two additional relations SSTYPES and LVEHICLES that hold criteria for FK constraints.
是的。
换句话说，您可以使用 3-table 模型；删除 ID 字段；并将 SPACESHIP.TYPE 和 LV 中的数字替换为字符串。然后你有一个 (a) 真正的关系数据模型，和 (a) 一个逻辑模型。
但是等等，还有更多。作为正常建模练习的一部分，您可能会注意到携带宽列（例如 TYPE 和 LV）作为子项中的 FK 有点愚蠢，并且会导致更大的存储空间。在这个阶段，在最终确定逻辑模型之前，通常要做的是使用一个简短的 CHAR(1) 或 CHAR(2) 代码，它们有意义地表示字符串。
这比 ENUM 或 ID 好多了。
请注意，这有助于编码人员在调试时，您可以从 SPACESHIP 行本身（没有 JOIN到查找 tables).
SSTYPE
SS_Code Name
------- -------------
Sz Soyuz
SS Space Shuttle
Or Orion
C1 CST-100
D2 Dragon V2
SPACESHIP 将有 SS_Code 和 LV_Code 作为 FK。
And yes - that would be great for me to be able to see the difference between database concept[ual model] and database logic[al model].
抱歉，我也帮不了你。我重复一遍，在我深思熟虑的观点中，概念模型的概念是 (a) 一场闹剧，并且 (b) 完全不清楚（每个 "theoretician" 对它是什么都有不同的概念）。
我只做 fixed-price、high-end 工作。我无法证明为这样一项荒谬的任务付出的代价是合理的。我只对逻辑模型和实施收费（物理是实施的一部分）。
如果我能对整个项目进行报价，那么根据定义，我已经彻底理解了这个概念（包括数据的概念模型）。此外，我从不为逻辑和物理使用单独的模型，我只是将逻辑扩展到物理中。只有 ERwin 提供该功能，其余 CASE 工具需要单独的模型和迁移；同步；复制；以及与复制任何东西相关的常见恐怖事件。
如果客户需要一个概念模型，我会要求他们定义它，这样我就可以为它报价。这通常会让他们闭嘴。
Perhaps I should rephrase my question as: Shall I add Foreign Key constraints on attributes?
绝对是。如果您没有 FK 约束，那么您就没有 (a) 参照完整性，或 (b) 数据库，更不用说关系数据库了。
再补充一点。你称他们为 "attributes"。他们不是。他们是钥匙。 Primary 或 Foreign，具体取决于主题位置。 RM 区分键和属性，并且对待 不同。在一个好的实现中，该处理一直进行到物理，使用私有数据类型（逻辑中的域）等。
post-Codd"theoreticians"，没有Keys。他们只有称为 "keys" 的物理 ID 字段，因此其他所有内容（实际的主键字段、外键字段以及 non-key 字段）都是一个属性。它没有关系键的值。都是non-relational.
他们有"candidate keys"这是拒绝接受关系模型中的处方。这不仅仅是术语上的差异。
此外，标签"candidate"是一个笑话，因为其中之一必须被选为Primary，在逻辑阶段的早期（如您所见），并在选举之后，失败者不再是"candidates"，他们是失败者（他们是RM中的Alternate Keys）。这是以这种方式完成的，以隐藏以下事实：(a) 它们没有关系键（逻辑），以及 (b) 它们使用记录 ID（物理指针）作为 "primary key"。因此，结果，哦，哦，一些属性是 "candidates".
这让我回到你最初的问题：
Is it reasonable to separate relation atributes with frequently duplicate string values?
- 规范化的练习主要是删除重复值，并部署以分隔 tables。
不仅合理，而且需要。 （这就是为什么我一开始就说，这件事没有规范化。）
- 现在您知道它们不是属性，它们是关系键。
这个简单的模型没有它，但是大多数关系 table 都会有复合（复合）键。
But in case of huge numbers of tuples in SPACESHIP_FLAT relation it will
consume a lot of resources (as I suppose) - so separating them will be
a bit more efficient.
不假设。 "Premature optimization is the root of all evil." 是的，通常 DMBS 对原始版本使用更多 space；但他们通常会花更多（加入）时间给对方。正如在任何工程权衡中一样，您应该证明一种设计更好。
关系模型的一个好处是，如果您决定稍后更改版本，那么可以为使用原始版本的应用程序提供适当的视图，而不会知道更改。 （数据独立性。）
But I did not found it in theory of database design.
它不是规范化的一部分。规范化不会引入新列。但这并不是好的设计的全部。
考虑关系 SPACESHIP_FLAT:
╔═════╤════════════════╤════════════════╤═══════════╗
║ ID │ NAME │ TYPE │ LV ║
╟─────┼────────────────┼────────────────┼───────────╢
║ 1 │ Soyuz TMA-14 │ Soyuz │ Soyuz-FG ║
║ 2 │ Endeavour │ Space Shuttle │ Shuttle ║
║ 3 │ Soyuz TMA-15M │ Soyuz │ Soyuz-FG ║
║ 4 │ Atlantis │ Space Shuttle │ Shuttle ║
║ 5 │ Soyuz TM-31 │ Soyuz │ Soyuz-U ║
║ 6 │ EFT-1 │ Orion │ Delta-IV ║
║ 7 │ XXX │ CST-100 │ Delta-IV ║
║ 8 │ YYY │ CST-100 │ Falcon-9 ║
║ 9 │ ZZZ │ Dragon V2 │ Falcon-9 ║
║ ... │ ... │ ... │ ... ║
╚═════╧════════════════╧════════════════╧═══════════╝
此处属性 TYPE 和 LV 具有重复的字符串值。所以我的问题是：将这些属性投射到新的关系中是否合理？结果将如下所示。
SPACESHIP
╔═════╤════════════════╤═══════╤══════╗
║ ID │ NAME │ TYPE │ LV ║
╟─────┼────────────────┼───────┼──────╢
║ 1 │ Soyuz TMA-14 │ 1 │ 1 ║
║ 2 │ Endeavour │ 2 │ 2 ║
║ 3 │ Soyuz TMA-15M │ 1 │ 1 ║
║ 4 │ Atlantis │ 2 │ 2 ║
║ 5 │ Soyuz TM-31 │ 1 │ 3 ║
║ 6 │ EFT-1 │ 3 │ 4 ║
║ 7 │ XXX │ 4 │ 4 ║
║ 8 │ YYY │ 4 │ 5 ║
║ 9 │ ZZZ │ 5 │ 5 ║
║ ... │ ... │ ... │ ... ║
╚═════╧════════════════╧═══════╧══════╝
SSTYPES
╔═════╤════════════════╗
║ ID │ TYPE ║
╟─────┼────────────────╢
║ 1 │ Soyuz ║
║ 2 │ Space Shuttle ║
║ 3 │ Orion ║
║ 4 │ CST-100 ║
║ 5 │ Dragon V2 ║
║ ... │ ... ║
╚═════╧════════════════╝
LVEHICLES
╔═════╤═══════════╗
║ ID │ LV ║
╟─────┼───────────╢
║ 1 │ Soyuz-FG ║
║ 2 │ Shuttle ║
║ 3 │ Soyuz-U ║
║ 4 │ Delta-IV ║
║ 5 │ Falcon-9 ║
║ ... │ ... ║
╚═════╧═══════════╝
我已将我的关系模型规范化为 5NF，并且发现没有理由将 TYPE 和 LV 从关系中分离出来（这些不会导致更新异常）。但是如果 SPACESHIP_FLAT 关系中有大量元组，它将消耗大量资源（正如我所想的那样）——因此将它们分开会更有效率一些。但是我在数据库设计理论中没有找到。
更新
好的，让我们澄清一些要点。
Attribute
TYPEentirely depends on attributeNAME.NAMEindicates an instance of classTYPE- one and more instances belong to one class. Soyuz TMA-14 is an instance of Soyuz ship series. So it can have one and only one value ofTYPE. Relationship between two sets of valuesNAMEandTYPEis many-to-one (no multivalued dependency).
AttributeLVdepends on attributeNAMEin the same manner.
But if I eventually decide to clarify the SoyuzTYPEand set all the Soyuz TMA-XX spacecrafts as Soyuz TMATYPE, Soyuz TM-XX as Soyuz TM and so on then I need to update each Soyuz* record no matter if I use the first variant with flat relation or variant with three different relations. The second one will ease editing value Soyuz (so it looks better in terms of data integrity).
As for surrogate keys - I use 'em because I need them to be represented in cross-reference relations (many-to-many, evenSPACESHIP_FLATorSPACESHIP- there are no top-level relations in my data model).
当然，您应该将这些类型分成不同的实体。这不仅会给space的经济带来好处，更重要的是会给你带来约束。因为现在我可以在这些列中输入任何值，例如 Blabla 或 Michael Jordan。但是当您创建单独的实体并添加一些约束时，您将只能在这些列中输入批准的值。
可以说我将从业务层管理那些东西，但在一本好书中说：
If your column accepts
NULLs, and you have implemented some strong logic which prevents enteringNULLsfromBL, anywayNULLwill always find its way to your column.
您现在可以轻松地对您的列类型说同样的话。
初步
不知道你看的是什么书，但我注意到现代书都是垃圾。你的单曲table是一个平面文件。
你有两个table的名字叫SPACESHIP.为了避免混淆，我就叫单table版本SPACESHIP_FLAT.
I've normalized my relational model to 5NF
抱歉，这不是规范化的。甚至不到 1NF。
如果我们从字面上看 1NF 和 2NF，在 post-Codd 时代写书的那种 non-experts，当然，它 "satisfies" 1NF 和2NF.
但是如果我们考虑到我们不需要一长串例外情况，那么我们不是试图破坏 1NF 和 2NF 的定义，那就是我们本着精神和意图接受它，那么您的单个文件将无法通过 1NF 和 2NF。
同样，对于 well-informed 人类，3NF 的 Codd 定义是完整的。但是新人需要BCNF, 4NF, 5NF, 十几个还没写出来的NF，从精神和意图上接近原来定义认为是3NF的Normalization水平。
它也不是关系型的，因为它打破了关系模型中的许多规则。
你只有代理，记录 ID，这是 pre-relational 时代的产物，大多数现代作者已经退化到那个时代，因为这是他们唯一能理解的东西。但他们错误地将其标记为 "relational".
因此您没有关系完整性（与参照完整性不同）、能力或速度。
明确禁止记录 ID 等。
and found no reason to separate TYPE and LV from the relation
对不起，这也不是关系。它是普遍关系，派生关系，所有关系的扁平化视图。
请注意 post-Codd 作者没有（也不能）区分基本关系和派生关系，他们试图 "normalise" 两者，并尖叫 "SQL can't ..." 和 "Relational Model doesn't ..."。这实际上只是证明了他们的无能。
眼下，原模型的两个最大对手正在对1NF发起攻击。
我们只需要标准化和设计基础关系。
these does not cause update anomalies.
对不起，又是假的。这可能意味着您不了解更新异常是什么（相反，您的平面文件没有它们）。
有几种不同类型的更新异常。他们可以被定义为一个群体，通过以下简单的（即简单的，技术性的，不完整的学术性的）定义。
An Update Anomaly is one where, when you need to update just one row, the tables are such that other rows (in the same or other table) must also be updated, in order to preserve integrity and Consistency of the data.
如果我
UPDATESPACESHIP_FLAT文件的记录ID 5中的TYPE字段，从Soyuz到Proto-Soyuz，那么记录 1 和 3 不再一致，它们也必须更新。那是更新异常。如果我在稍微规范化的 three-file 版本中进行相同的更新，我
UPDATESSTYPES的记录 ID 1 中的TYPE字段文件，从Soyuz到Proto-Soyuz，该更改将反映在使用SSTYPES的投影中。无需更新其他记录。没有更新异常。更新异常是 结果 无效或不完整的规范化。它是一面旗帜，一个警钟。它本身是无法纠正的，你必须回到规范化阶段，在那里纠正它。
注意。这只是一种更新异常。但它们都是归一化练习中错误的结果。
But in case of huge numbers of tuples in SPACESHIP relation it will consume a lot of resources (as I suppose) - so separating them will be a bit more efficient
好点，当然是，但不是出于正确的理由。正确的原因和程序 导致 分离 tables 具有关系完整性，效率更高，等等，等等，
But I did not found it in theory of database design.
那是因为没有正确教授数据库设计和关系理论。看过的书都烂透了，爱丽丝的书尤其烂
诚信
你不明白的是，单个文件中的数据没有完整性。 three-file 组合中的数据更完整，但不是 关系模型 提供的完整数据集。
回答
因此，three-file 集群比单个文件更标准化。
但它需要更多的规范化、更多的关系化才能完成。
删除记录 ID。
如果您想详细了解 Record ID 的可怕之处，请阅读
保持规范化（你做得很好，直观地理解它），直到你有：
没有任何重复数据
你需要的所有事实（数据库是关于现实世界的事实的集合）
表示为关系键
那么您将拥有一个关系数据库。
把那些书扔掉。只读 E F Codd 博士。他的论文是免费的，但术语是 out-of-date，而且它是开创性的，某些术语的含义已经丢失（或被积极压制）。
回复评论和更新
And trying to create logical model as optimal as possible.
是的。所以我们会把这个问答保留在逻辑模型层面。当它被解决、归一化、优化（仅在逻辑级别）时，您就可以继续进行物理模型了。
在这种情况下，请注意 ID 字段是物理字段，而不是逻辑字段。 ID 字段不存在于正在考虑的数据中（讨论域）。现代书籍会误导 reader，为所有事物引入 ID，以及其他危害科学的罪行。删除它们，然后我们可以开始 逻辑模型。我们不能开始 当数据被感染时，当它包含在纯未受污染的数据中不存在的额外污染物时。
Attribute TYPE entirely depends on attribute NAME. NAME indicates an instance of class TYPE - one and more instances belong to one class. Soyuz TMA-14 is an instance of Soyuz ship series. So it can have one and only one value of TYPE.
（我将使用关系术语，而不是 OO/ORM 术语。我们没有 类 和实例，我们有域和元组或行。）
Relationship between two sets of values NAME and TYPE is many-to-one (no multivalued dependency).
理解并接受。除了一个例外：你的两个段落意味着 NAME 依赖于 TYPE，而不是相反（你的开头句与其余句相矛盾）。
现在在关系模型中，我们有依赖度。
典型的查找 table 被引用，以及记录归档系统中的所有文件，其中不能说主题（引用）table 行不能除非引用的 table 存在，否则依赖项为 Non-Identifying。关系线为虚线。
关系数据库中绝大多数 table 的典型（减去那些 Lookup table），其中主题 table 行仅存在于引用 table 的上下文，依赖关系是识别的。父PK用于形成子PK。感情线稳固。
如果 SPACESHIP 仅存在于 TYPE 的上下文中，则 SPACESHIP (a) 依赖于 TYPE，并且 (b) TYPE PK 用于形成 SPACESHIP PK。
我倾向于认为SPACESHIP is Dependent on both TYPE and LAUNCH_VEHICLE, TYPE and LAUNCH_VEHICLE各自标识SPACESHIP.
Attribute LV depends on attribute NAME in the same manner.
没有。被诅咒的人扰乱了你的大脑。 NAME 取决于 LAUNCH_VEHICLE (LV)，而不是相反。
But if I eventually decide to clarify the Soyuz TYPE and set all the Soyuz TMA-XX spacecrafts as Soyuz TMA TYPE, Soyuz TM-XX as Soyuz TM and so on then I need to update each Soyuz record no matter if I use the first variant with flat relation or variant with three different relations.*
完全正确。
这正是我说您的模型不在 1NF 中的原因。你的"name"其实不是一串字符，它是由零件组成的。这些部分具有特定含义（Date 无法理解）。这些部分实际上是 (a) TYPE (b) LAUNCH_VEHICLE，和 (c) 尚未阐明的内容。 TMA vs TM-XX 有意义，它与 TYPE 相似，但是是一个单独的集合。
我会让你解决 (c)。注意重复；弄清楚每个组成部分的含义；等。然后将其提取到单独的 table.
真正的名字是 Discovery、Endeavour、Volna、Yenesei、Lena 等。标有 NAME 的东西是正式分类词（TYPE、LAUNCH_VEHICLE 和 XXXX）的串联。
The second one will ease editing value Soyuz (so it looks better in terms of data integrity).
我们不关心科学的外表。这是对还是错。某一列要么具有数据完整性，要么不具有。第一个没有任何数据完整性，第二个具有一定的数据完整性（已经讨论过，还有更多内容）。
As for surrogate keys - I use 'em because I need them to be represented in cross-reference relations (many-to-many, even SPACESHIP_FLAT or SPACESHIP- there are no top-level relations in my data model).
没有"surrogate key"这样的东西。它只是一个替代品。它具有钥匙所具有的 none 品质。因此，"surrogate key" 一词具有欺诈性，因为人们自然会期望钥匙具有某些（如果不是全部）品质，而它不具备任何这些品质。
代理是物理的，不是逻辑的。在这个逻辑阶段我们不需要它们。
我们不需要关系模型中的代理项。特别是不用于关联行。关系模型之前的记录归档系统使用记录 ID（物理、代理）来关联记录。关系模型的最大区别在于它使用逻辑键而不是记录 ID（物理、代理）来关联行。
任何人都可以通过数字关联电子表格中的条目。需要更多的理解才能 (a) 放弃数据的电子表格视图，以及 (b) 通过 Key 关联条目。
One-to-one； one-to-many; many-to-many，使用Keys，一点问题都没有。
that cancer-causing book is C. J. Date. Introduction to Database Systems - contained more theory on database systems of all books I've managed to grab (in my native language).
那又怎样：不好就是不好。如果它加深了对关系模型的理解，它加深了对关系模型.
的理解证据，无论是在这个问题中，还是在每个项目中，这种风格的追随者都会产生 anti-relational 结果。在这里，他让您认为您正在生成符合 关系模型 的逻辑模型，但证据是，它是一个 anti-relational 物理文件系统，具有 none 关系数据库的能力、完整性、能力或速度，具有 pre-relational 记录 ID。
如果您需要更多证据，请查看我在 SO 上的回答（转到我的个人资料）。请注意，寻求者是真正的人，他们和您一样，正在关注那些书籍，并创建了可怕的文件系统，同时相信 "relational" 和 "database"。这才是Date真正的成功。
这些 anti-relational 的书很畅销。现在它们被用作大学的教科书。所以呢。他们还是错了。
我再说一遍，扔掉那些书，只读 Dr E F Codd。当然，还有 Codd 的真正门徒。不是那些引用 Codd 而是教导相反的骗子。
C. J. Date said that 5NF will not make the relation free from all update anomalies (as you've shown on SPACESHIP_FLAT example).
戴特和他的同事们一直在破坏科学。科学基于 objective 真理。他们一直在把它变成主观真理。在 Codd 时代，我们有 1NF、2NF、3F。是objective，没有人争论。
"mathematicians" "improve" 科学的时代到来了。他们在 3NF 中找到了 "holes"，这是一个诚实的人不会找到的。他们将 "theses" 和 "mathematical definitions" 写到 "plug the holes" （他们自己不诚实制造的漏洞）。所以现在他们有了 BCNF、4NF、5NF。对于我这样的人来说，这些都是多余的废话。
他们互相争论什么是 NF，什么不是，关于什么是数学证明，什么不是。现在 Date 和 Darwen 正试图改变 1NF 的定义，以适应他们自己的目的，在它已经被数百万人定义和使用了 45 年之后。
他们中的大多数人同意（截至今天，但明天可能会改变）5NF 确保没有更新异常。
I have several large banking databases that were honest 3NF, long before 5NF was hatched, I made written declarations that they did not have Update Anomalies. My customers had occasion, ten years later, after 5NF was hatched, to ask me to comply with 5NF, in order to ensure no Update Anomalies. I examined the old 3NF data model, and to everyone's surprise, it "satisfied" 5NF, and no surprise, it did not have any Update Anomalies.
How did that happen ?
By (a) being technically honest (ie. not trying to find ways of not-complying, while looking like I am complying) and (b) Normalising according to science and principle (ie. not according to the fragments of NFs in the form of "mathematical definitions")
I just Normalised, and ensured that there were no Update Anomalies.
That act, ensured that the database would "satisfy" BCNF, 4NF, 5NF, and any other NF that has not been defined or "mathematically defined" yet. As evidenced.
As far as I am concerned, based on my 36 years in the science, BCNF, 4NF and 5NF, are all simply their 3NF restated (they re-defined 3NF after Codd died).
- They need it to "plug holes" because they subvert the Codd definition of 3NF, and then, that subverted "definition", sure enough, has "holes". Being fraudsters, they will be finding "holes" and "plugging holes" for the rest of the century.
Meanwhile, back at the farm, honest men use the Codd definition for 3NF, in which there are no holes, there is nothing to plug.
Up to 2007, I was producing databases that were 95% DKNF, according to the Codd definition and intent in the Relational Model. That last 5% was prevented, due only to a limitation in SQL. Since 2007, when the last obstacle was removed, I have been producing 100% DKNF databases.
- But the "theoreticians" flatly state that it cannot be done. They are relying on their "mathematical poofs". I am relying on Codd's definition.
Even when I wrote to the authors of the DKNF "mathematical definition", and gave them a full data model plus diagrams plus documentation, it turned out, they couldn't understand it.
- They understand only (a) "mathematical definitions" that are (b) based on their previous "mathematical definitions".
- A fraud in and of it self.
- A proof, in and of itself, that they do not understand Codd or his Relational Model. Let alone follow his model or his intent.
根据他们自己提供的证据，post-Codd 作者不理解 关系模型 。非常严肃地注意这一点：因此他们不知道，他们不理解关系模型提供的是什么：关系完整性（与参照完整性不同）；关系力量（在你的质疑水平上，这意味着加入力量）；关系速度。他们只知道RFSnon-integrity； RFS 导航； RFS 速度。
更新异常
底线：
- 通过科学、原则、逻辑规范化。最重要的是，通过 Codd 在 关系模型 . 中给出的方法
不是 NF 定义。无论如何，您不能通过 NF 定义进行规范化，因为它们没有提供任何方法。
注意Codd在RM明确定义了两个NF，post-Codd时代写书的怪胎，声称成为 "relational" (a) 否认和 (b) 压制，只是在他们被诅咒的书中从不提及它们或方法。
- 通过了解什么是更新异常来防止更新异常。
不是转瞬即逝的 "mathematical definition"，因为 (a) 不会产生没有更新异常的数据库，(b) 他们争论是否 "mathematical definition" "proves" 它提议证明什么，以及 (c) "mathematical definitions"、证明和论证，一直在变化。
这就是pseudo-science的主观真理（non-permanent，不断变化）的所有证据。科学基于 objective 真理。 objective 真理的特性之一是，它是永恒的，不会改变。
另请注意，Philip 的 "update anomaly" 概念是一种观点。和几十年前的定义无关，是objective的真理。虽然您的数据模型无法防止更新异常（根据我提供的证据），但它很可能 "satisfy" 某人，任何人对杂碎的看法。同时，不管这些 ever-changing 意见如何，数据模型仍然无法防止更新异常。
One more question: do I need to get rid of all surrogate keys?
是的。如果你想要一个关系数据库。如果您对具有 none 完整性的记录归档系统感到满意；力量;或关系数据库具有的速度，您可以保留它们。以及 RFS 附带的所有体力劳动。
如上所述。它们是物理的，而不是逻辑的。它们不是密钥，它们是记录归档系统中的 pre-relational 物理指针。
任何特定 post-Codd 作者使用记录 ID 的事实，证明该作者不了解 RM[=402 中最基本的基本要求=].他们只懂 RFS，因此他们只能教这些。
他们在逻辑模型级别教授记录 ID 的事实证明他们正在积极地进行欺诈，使物理 ID 看起来像逻辑对象，使其看起来像 "key". Anti-relational.
代码
If so - how it will affect foreign keys, JOINs?
你是什么意思？你需要代码吗？好吧，你的模型还不够先进，无法编写代码，而且我无法使用它现在拥有的 ID。让我们使用这个 Data Model.
那是一个IDEF1X数据模型。 IDEF1X 是关系数据库建模的标准，我们自 1987 年以来一直拥有（自 1993 年以来作为标准）。 Date、Darwen、Fagin 等人避开它，他们只使用文本，或者发明他们自己的 "diagrams"。使用标准会将他们的方法公开为 sub-standard.
请注意每一个小滴答；缺口;并做标记；鱼尾纹；实线与虚线；方角与圆角；意味着非常具体和重要的事情。参考IDEF1X Notation。如果您不理解符号，您将无法理解或工作模型。
外键为粗体，并使用与父 PF 完全相同的列名。例外情况是 (a) 同一父项有多个 FK，或 (b) 为清楚起见，我们使用 RoleNames.
TaxonomyNo 对您来说可能看起来像一个代理人，但它不是。该模型非常成熟（第七次迭代）。请注意它是如何用于构建分类法的层次结构 类。这与 Unix Inode（也是数字，而不是代理项）的实现相同，后者以其简单和强大而闻名。
让我们得到一份使用 many-to 许多关系的报告，例如您所关心的。列出所有物种（不是整个分类树，只是叶级别）及其活动。 "Activity" 是 CHAR(X) 代码，我们要 Name:
SELECT [Species] = T.Name,
[Activity] = A.Name
FROM Species S
JOIN Taxonomy T
ON S.SpeciesNo = T.TaxonomyNo
JOIN SpeciesActivity SA
ON S.SpeciesNo = SA.SpeciesNo
JOIN Activity A
ON SA.Activity = A.Activity
And is it ok to realize many-to-many relationships between two entities using composite PRIMARY key that consists of two foreign VARCHAR keys?
是的。那是正常的，行人的，普通的。这就是关系的意思，通过键关联。关系数据库中的大多数键都是复合键（复合）。
物种Activity就是一个例子。
在 table 上使用 ID 列完全是多余的，因为组合 (SpeciesNo, Activity) 是唯一提供行唯一性的组合；就这样PK了。
再多的 "unique" 记录 ID 也无法改善这一点。
并且如果它不是声明的PK，无论使用了多少"unique"记录ID，那么重复行将得到保证。
下一点是关于物理的，而不是逻辑的，但我不会回避它。那个 VARCHAR 必须离开。到处使用 VARCHAR 是另一个错误。
始终使用固定长度，只有在绝对必要时才使用可变长度。
在 Keys 中使用 VARCHAR 特别糟糕，因为它最终出现在一个或多个索引中，这意味着每个索引条目都必须是 packed/unpacked，每次访问这些条目时。
如果您不知道长度应该是多少，这本身就证明您对数据的了解不足以对其建模。所以去了解数据，了解并喜欢它。不是为了去除 VARCHAR，而是为了建模之前要求的熟悉度。
回复评论 2
So database model which is in MySQL Workbench can not be called logical model, does it?
抱歉，我不知道像 MySQL 这样的免费软件能做什么（我很清楚它们不能做什么），除非万不得已，否则我不会碰它们或 PC，所以我真的不能回答这个问题。
不过我能猜到。这个问题意味着它自动包含 ID 字段。查看是否有阻止该行为的设置。如果不是，那么是的，它不能用于 逻辑模型，或关系数据库的物理模型。不管你怎么称呼它产生的东西。
If I remove all IDs from the relations then I will get the same relations (as SPACESHIP_FLAT) but with Foreign Key constraints on attributes TYPE and LV as well as two additional relations SSTYPES and LVEHICLES that hold criteria for FK constraints.
是的。
换句话说，您可以使用 3-table 模型；删除 ID 字段；并将 SPACESHIP.TYPE 和 LV 中的数字替换为字符串。然后你有一个 (a) 真正的关系数据模型，和 (a) 一个逻辑模型。
但是等等，还有更多。作为正常建模练习的一部分，您可能会注意到携带宽列（例如 TYPE 和 LV）作为子项中的 FK 有点愚蠢，并且会导致更大的存储空间。在这个阶段，在最终确定逻辑模型之前，通常要做的是使用一个简短的 CHAR(1) 或 CHAR(2) 代码，它们有意义地表示字符串。
这比
ENUM或 ID 好多了。请注意，这有助于编码人员在调试时，您可以从 SPACESHIP 行本身（没有 JOIN到查找 tables).
SSTYPE SS_Code Name ------- ------------- Sz Soyuz SS Space Shuttle Or Orion C1 CST-100 D2 Dragon V2
SPACESHIP 将有 SS_Code 和 LV_Code 作为 FK。
And yes - that would be great for me to be able to see the difference between database concept[ual model] and database logic[al model].
抱歉，我也帮不了你。我重复一遍，在我深思熟虑的观点中，概念模型的概念是 (a) 一场闹剧，并且 (b) 完全不清楚（每个 "theoretician" 对它是什么都有不同的概念）。
我只做 fixed-price、high-end 工作。我无法证明为这样一项荒谬的任务付出的代价是合理的。我只对逻辑模型和实施收费（物理是实施的一部分）。
如果我能对整个项目进行报价，那么根据定义，我已经彻底理解了这个概念（包括数据的概念模型）。此外，我从不为逻辑和物理使用单独的模型，我只是将逻辑扩展到物理中。只有 ERwin 提供该功能，其余 CASE 工具需要单独的模型和迁移；同步；复制；以及与复制任何东西相关的常见恐怖事件。
如果客户需要一个概念模型，我会要求他们定义它，这样我就可以为它报价。这通常会让他们闭嘴。
Perhaps I should rephrase my question as: Shall I add Foreign Key constraints on attributes?
绝对是。如果您没有 FK 约束，那么您就没有 (a) 参照完整性，或 (b) 数据库，更不用说关系数据库了。
再补充一点。你称他们为 "attributes"。他们不是。他们是钥匙。 Primary 或 Foreign，具体取决于主题位置。 RM 区分键和属性，并且对待 不同。在一个好的实现中，该处理一直进行到物理，使用私有数据类型（逻辑中的域）等。
post-Codd"theoreticians"，没有Keys。他们只有称为 "keys" 的物理 ID 字段，因此其他所有内容（实际的主键字段、外键字段以及 non-key 字段）都是一个属性。它没有关系键的值。都是non-relational.
他们有"candidate keys"这是拒绝接受关系模型中的处方。这不仅仅是术语上的差异。
此外，标签"candidate"是一个笑话，因为其中之一必须被选为Primary，在逻辑阶段的早期（如您所见），并在选举之后，失败者不再是"candidates"，他们是失败者（他们是RM中的Alternate Keys）。这是以这种方式完成的，以隐藏以下事实：(a) 它们没有关系键（逻辑），以及 (b) 它们使用记录 ID（物理指针）作为 "primary key"。因此，结果，哦，哦，一些属性是 "candidates".
这让我回到你最初的问题：
Is it reasonable to separate relation atributes with frequently duplicate string values?
- 规范化的练习主要是删除重复值，并部署以分隔 tables。
不仅合理，而且需要。 （这就是为什么我一开始就说，这件事没有规范化。）
- 现在您知道它们不是属性，它们是关系键。
这个简单的模型没有它，但是大多数关系 table 都会有复合（复合）键。
But in case of huge numbers of tuples in
SPACESHIP_FLATrelation it will consume a lot of resources (as I suppose) - so separating them will be a bit more efficient.
不假设。 "Premature optimization is the root of all evil." 是的，通常 DMBS 对原始版本使用更多 space；但他们通常会花更多（加入）时间给对方。正如在任何工程权衡中一样，您应该证明一种设计更好。
关系模型的一个好处是，如果您决定稍后更改版本，那么可以为使用原始版本的应用程序提供适当的视图，而不会知道更改。 （数据独立性。）
But I did not found it in theory of database design.
它不是规范化的一部分。规范化不会引入新列。但这并不是好的设计的全部。