database design- diagrams

Question

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.

Answer 1

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.

Answer 2

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.