I'm really trying to wrap my head around the concept of transforming EER Diagrams into relations. I understand that simple attributes must be mapped directly on the relation. My problem arises when dealing with composite and multivalued attributes. Do you create new relations for either one of them? For example, a customer entity may have a name, address, and postal code. The address attribute contains street, city, state, and address #. Does this mean that a new relation should be created or all component attributes should be listed in the customer relation? And lastly how is a multivalued attribute properly mapped, in easy to understand terms with an example?
Thanks for any help.
Multivalued attributes are almost certainly better off being removed to a separate relation. That is called First Normal Form and you have to work pretty hard to find an example where violating 1NF can be justified.
There is no reason for creating a new relation for composite attributes. You split attributes into a new relation because of their cardinality and their dependency on your primary and candidate keys.
Composite attributes don't actually occur in nature, they are a figment of the conceptual modeling imagination. OK, this statement is slightly facetious. The point is that when you go past the conceptual model into a physical model, you have a decision to make about your practical business requirements. The level of granularity at which your composite attributes are persisted phyisically depends on how you plan to use the data. If you are tracking an address to print an envelope or shipping label, you may well decide to collapse your address elements into two columns. On the other hand, you may decide that your business requirements call for address element analysis so keeping each part of the address in its own column makes more sense.