0

I'm interested in database design and now reading the corresponding literature. Through the book, i have faced a strange example that makes me feel uncertain. There is a relation

enter image description here

In this table we have a composite primary key (StudentID, Activity). But ActivityFee is partially dependent on the key of the table (Activity -> ActivityFee), so the author suggests to divide this relation into two other relations:

enter image description here

Now if we take a look at the STUDENT_ACTIVITY, Activity becomes a foreign key and relation still has a composite primary key.

We've got the table in which the whole columns defines a composite primary key, is it OK?

If it is not, what should we do in this case? (probably define a surrogate key?)

What is a good way to deal with multivalued attribute (Activity in our case) in order eliminate possible data anomalies?

nvogel
  • 24,981
  • 1
  • 44
  • 82
metacube
  • 328
  • 3
  • 14

2 Answers2

3

A table which consists only of a composite key is perfectly OK if that matches your business requirement.

Activity is not a multivalued attribute. There is a single value for activity for each tuple.

nvogel
  • 24,981
  • 1
  • 44
  • 82
2

There is nothing wrong with a composite candidate key. (If your reference doesn't talk in terms of candidate keys, ie if it talks about primary keys in any other case than when there just happens to be only one candidate key, get a new reference.)

Your text will tell you what is good and bad design. There is no point in worrying about every property you notice about a relation that it might be "bad". The kind of "good" it is currently addressing is that given by "normalization".

"Activity" is not a "multivalued attribute". A "multivalued" attribute is a non-relational notion. The term is frequently but incorrectly used to mean either an "attribute" in a non-relational "table" that somehow (which is never explained) has more than one entry per "row", or for a column in a relational table that has a value with multiple similar parts (set, list, bag, table, etc) that somehow (which is never explained) doesn't apply to say, strings & numerals, or for a column in a relational table that has a value with multiple different parts (record, tuple, etc) that somehow (which is never explained) doesn't apply to, say, dates. (Sometimes it is even misapplied to mean a bunch of attributes with similar names and values, which ought to be replaced by a single attribute with a row for each original name.) (These are just cases of unwanted designs.) "Multivalued" gets used as an antonym of the similarly misused/abused term "atomic".

Having the same (value or) subrow of values appear more than once in a column or table is, again, neither good or bad per se. Again, your reference will tell you what is good design.

Community
  • 1
  • 1
philipxy
  • 14,867
  • 6
  • 39
  • 83