Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm trying to derive an Entity Relation diagram from a class diagram. In the class diagram, I have a class Player with one to many relationship to another class Payment. In Payment there is no attribute 'paymentID' and 'playerID' is foreign key. Since the same player ('playerID') can make the same payment many times, I thought of adding an attribute 'paymentID' to the Payment table. Is this right? Will I still follow the requirements? I'm new to all these, thank you for any help.

share|improve this question
What does "the same payment" mean? Is it the same item ordered more than once by the same buyer? – Yasir Arsanukaev Apr 14 '13 at 13:05
In the Payment class there is date and amount attributes. So a player can make the same payment many times (same amount on the same date). That's why I thought of adding an id attribute although this is not on the Class diagram. – user22515 Apr 14 '13 at 13:26
up vote 1 down vote accepted

Short answer : yes , add paymentID (PK) to Payments table.
Explanation. Even without knowing any details about your application, I'm pretty sure payment is quite important concept that has to be treated as a separate entity. Thus, it should have primary key. It's possible payment has a composite candidate key (say, combination of (playerID,paymentTimestamp) is very likely to be unique), but it's much easier to deal with simple primary key rather than composite.

As to following requirements.
Class hierarchy doesn't match 100% table structure. There are many concepts that implemented in different ways (for instance, many-to-many relationships, inheritance). Entity identity is one of them , so your approach looks perfectly valid to me.

share|improve this answer

Every table should have a primary key (I really can't think of a reason not to have one). So having a paymentID column to your payment table is definitely a standard design.

share|improve this answer
Will I still follow the requirements though if I add attributes to my tables on the entity relationship diagram that are not on the given Class diagram? – user22515 Apr 14 '13 at 13:41
What's the requirement? – ETL Apr 14 '13 at 13:44
I mean the design as it is specified on the class diagram. Do I need to create the tables and attributes exactly as they are on that diagram, or I can add the id attribute which is not on the class diagram? – user22515 Apr 14 '13 at 13:49
I can't really answer this question - who made the class diagram? Can the class diagram be changed? Do you use an ORM to go from your Objects to the Database? etc. – ETL Apr 14 '13 at 14:32

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.