规范封面是哪种范式？ [英] Canonical cover is in which normal form?
问题描述
我想知道规范封面处于哪种范式。我知道在进行规范化之前我们先找到规范封面，所以我认为它是第一范式。但这可能不是标准格式，因为Wikipedia对1NF的定义是没有行应该重复：
I want to know which normal form a canonical cover is in. I know before doing normalization we find the canonical cover so I think it is in first normal form. But it may be in no normal form as the definition of 1NF by Wikipedia is no row should have a duplicate:
以下是第一个标准格式条件：
First normal form enforces below criteria:
- 消除单个表中的重复组。
- 为每个表集创建一个单独的表相关数据。
- 用主键标识每组相关数据
推荐答案
普通形式适用于关系（值和变量），而不适用于规范封面。封面是一组FD（功能依赖项），关系中的所有FD都从该FD中遵循。规范封面是某种形式的封面。如果您具有规范的封面和关系的属性，则可以找到该关系所处的正态形式。
Normal forms apply to relations (values and variables), not canonical covers. A cover is a set of FDs (functional dependencies) from which all the FDs in a relation follow. A canonical cover is a cover in a certain form. If you have a canonical cover and a relation's attributes then you can find what normal form the relation is in.
行的定义不能重复 ;关系。关系具有 set 行。 （但是，SQL表可以具有重复的行。）没有列/属性可以是多值的。或重复组。属性具有 a 值。
No row can have a duplicate by definition of "relation". A relation has a set of rows. (SQL tables, though, can have duplicate rows.) No column/attribute can be "multivalued" or a "repeating group". An attribute has a value.
维基百科在其相关文章中有很多废话，包括引用的内容。但是来自我的答案：
Wikipedia has a lot of nonsense in its relational articles including the one you quote. But from this answer by me:
定义中，关系的元组属性具有来自域的 a 值。回复：重复组：不能包含任何内容，这是关系前数据库的内容。关于非原子的：Codd将关系定义为能够具有关系值域。他指出，在关系上下文中（在日常意义上）将值视为非原子性的唯一方法是关系值。即，他定义了原子。在关系上下文中不是指关系。他定义了归一化。表示没有关联值（即非原子）属性。 （所有这些都在 1970 中。）后来，他将 1NF定义为归一化。并开发了 2NF & 3NF。然后（在肯特和博伊斯之后） BCNF。因此，他对这些术语的使用假定没有关联值域。
By definition, a relation's tuple's attribute has a value from a domain. Re: "repeating groups": It can't have any, that's something from pre-relational databases. Re "non-atomic": Codd defined relations as able to have relation-valued domains. He pointed out that the only way that a value could be considered (in the everyday sense) non-atomic in a relational context was to be relation-valued. Ie he defined "atomic" in a relational context to mean not a relation. He defined "normalized" to mean having no relation-valued (ie non-atomic) attributes. (All this in 1970.) Later he defined "1NF" as normalized. And developed "2NF" & "3NF". Then (after Kent & with Boyce) "BCNF". So his use of these terms assumed no relation-valued domains.
但是归一化理论的提出与域无关。也就是说，它仅是每个有问题的JD分解[联接依赖项]。因此， 1NF也习惯于只是一种关系。而其他 NF习惯于不考虑领域。 （尽管如果存在关系值域，则可能存在与FD和JD不同但相似的约束条件，这些约束条件会引起不同但相似的异常，并且即使在所有有问题的JD分解后，也会导致组件中的约束条件和异常。）关系具有关系值域，而无论用 1NF表示什么意思？或规范化或规范化，即您遵循的分解程序，可将有问题的JD从有问题的FD移除为您所称的[a] NF，而与域无关。
But normalization theory is presented independent of domains. Ie it's considered to just be decomposition per problematic JDs [join dependencies]. So "1NF" also gets used for just being a relation. And the other "NFs" get used without regard to domains. (Although if there are relation-valued domains then there can be constraints different from but similar to FDs & JDs that cause different but similar anomalies, and that cause constraints and anomalies in components even after decomposition per all problematic JDs.) Regardless of whether a relation has relation-valued domains and regardless of what one means by "1NF" or "normalized" or "normalization", the decomposition procedure you're following to remove problematic JDs from problematic FDs to what you're calling [a ]NF is independent of domains.
来自另一个：
-
不存在多值属性之类的东西。关系中。元组的每个属性名称都有一个一个属性值。 [...]如果您具有一个考虑的属性以包含多个零件，即您想在不使用带有其类型参数的运算符的情况下通用查询零件，则通常为好的设计，以便有一个单独的表，其中包含这些部分的属性。但这无法通过规范化解决。 任何值可以被认为具有多种形式的多个部分，并且由您的应用程序/查询确定何时停止创建其属性为其他值的部分值并且仅具有值。同样，如果您有一堆扮演相似角色的属性（通常具有相似的名称），那么良好的设计通常是拥有一个单独的表且仅包含一个角色属性。
There is no such thing as a "multivalued attribute" in a relation. A tuple has an attribute value for each attribute name. [...] If you have an attribute that you consider to contain multiple parts, ie you want to generically query about the parts without using operators with parameters of their types, then it is usually good design to have a separate table with attributes for those parts. But that's not addressed by normalization. Any value can be considered to have multiple parts in multiple ways and it is your application/queries that determine when you stop making tables whose attributes are the values of parts of other values and just have an attribute for a value. Similarly, if you have a bunch of attributes that play a similar role (often with similar names) then it is usually good design to have a separate table with just one attribute for the role. But that's not addressed by normalization.
候选键对FD，MVD，JD和归一化很重要。 PK（主键）没有。您可以选择一个CK作为 PK。但是它的原始性与关系模型无关。这可能与某些信息建模方法或产品有关。
Candidate keys matter to FDs, MVDs, JDs and normalization. PKs [primary keys] don't. You can pick one CK as "the PK" but its primariness is irrelevant to the relational model. It might be relevant to some information modeling method or product.
如果对您的关系，属性，属性类型，规范覆盖或规范化过程有特别的担忧，则应在问题中进行解释。
If you have particular concerns about your relation(s), attributes, attribute types, canonical cover or normalization process then you should explain in your question.
这篇关于规范封面是哪种范式？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
