Functional dependencies are the attributes that their values are determined in a unique way by another attribute.Given that, can a multivalued attribute be dependent upon a primary key?

- 14,867
- 6
- 39
- 83

- 11
- 6
-
Sure! You can just create a surrogate key – FirebladeDan Aug 21 '15 at 15:51
-
a surrogate key is a key with no business meaning. Can you give me an example? – mankavvalos Aug 21 '15 at 16:02
-
Your statement about business meaning needs an asterisk. From a db point of view they are pretty nifty. The idea is just to provide a unique ID to some row of data. If your selected primary key is eh... This allows you to make those relationships across tables easier because it is number instead of blah, blah. This would work perfect in your situation unless your question isn't completely defined. – FirebladeDan Aug 21 '15 at 16:10
-
I'm trying to normalize my database-scheme and show theoretically, through functional dependency axioms, that my database-scheme is correct. So i came upon a multivalued attribute, (which in my scheme-the one i want to prove- is a different table), and i'm trying to figure out if the primary key is determining the multivalued attribute. – mankavvalos Aug 21 '15 at 16:16
-
Your question uses technical terms wrongly & strangely. Try presenting a minimal design & its justification that shows your problem (per processes and definitions that you are using). Re design see [the "educate yourself" section of this answer](https://stackoverflow.com/a/31397135/3404097). – philipxy Aug 22 '15 at 00:57
1 Answers
"FDs are the attributes that their values are determined in a unique way by another attribute" is unintelligible. Find a way to say it correctly or how can you understand it?
An attribute (or set of attributes) is functionally determined by a set of attributes.
There is no such thing as a "multivalued attribute" in a relation. A tuple has an attribute value for each attribute name. (Maybe you mean, a set of attributes is being determined? Maybe you mean, a multi-valued dependency?) 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 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.
Superkeys are sets of columns that determine every column. Since every set of attributes always determines the attributes in it, superkeys are sets of columns that determine every other column. CKs are superkeys that contain no smaller superkey. (So CKs are sets of columns that are unique but contain no smaller set of columns that are unique.)
You don't know all the CKs until you find all the FDs. But you might know that a particular set of attributes is unique and has no smaller unique set, so that you know that it is a CK and you can call it "the PK". (Eg an id attribute in a relation variable that can have more than one row.)
can a multivalued attribute be dependent upon a primary key?
- Every attribute is dependent on every CK by definition of CK. So every attribute is dependent on every PK by definition of PK.(But you must clarify what you mean by "multivalued attribute" and "dependent".)

- 14,867
- 6
- 39
- 83