When mapping an ER diagram to a relational schema, my textbook says that in step.. whatever.. a new relation S should be created for multivalued attributes. But if the multivalued attribute is the primary key of R... that leaves the R with no primary key and S with no primary key?
A:
This is an excellent question and something that always bothered me about the textbook explanations of how to eliminate "complex" types.
The question you need to ask is: What is being identified by the sets of values? What are you trying to model? Most database architects working with SQL would probably say that you ought to invent a new attribute to identify the sets of things that would have made up your multivalued attribute.
Another solution is to embrace "complex" types as first class attributes in their own right - not "multivalued" attributes but sets or arrays that can be assigned to a variable as a single value just like any other value. The Tutorial D language permits relation-valued types withing relations. e.g.:
VAR r BASE RELATION {foo RELATION {bar INTEGER} } KEY {foo};
where foo is a relvar nested within r.
SQL however doesn't support anything like this. Nested tables are supported in SQL but are not usually allowed to be part of keys so in SQL you always have to create a new identifying attribute. In a true RDBMS you arguably shouldn't have to create another attribute because any supported type ought to support being part of a key - if it didn't then you wouldn't even be able to project on that attribute because the result wouldn't contain a key.
dportas
2010-09-28 08:51:14