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:
- Eliminate repeating groups in individual tables.
- Create a separate table for each set of related data.
- Identify each set of related data with a primary key
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.
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:
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.
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.
From another:
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.
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.
