I'm having a hard time converting my database tables and foreign keys to a class diagram with classes and associations.

My question is:
"In in a composition relationship, should a child class always should have an ID field?".

In my CD, there are 2 compositor classes: PurchaseItem and PurchaseFinisher, which composite Purchase class. PurchaseItem already comes with an ID field from its table but, PurchaseFinisher doesn't because it is filtered by the id_purchase and id_payment_method foreign keys.

thanks in advance.

This is my DB diagram:

I can't see redundancy in between Purchase or Product, as you said. Could you, please, show me that based on my DB diagram? My tables are well modeled (hope so). My fault is in the classes definition.

CodePudding user response：

In a class diagram, no class requires an id property: each class instance (aka object) has its own identity with or without explicit id property.

In a database, you need of course an explicit id property to uniquely identify the object among others in the database and find it back. By the way, you may annotate such properties with a trailing {id} . UML does not define any semantic for it, but it is in general sufficiently expressive to help database designers.

In the case of composition, the main question is whether a composed object can easily be identified by alternate means. There are several related ORM database techniques, for example:

• you can use the owning object’s id together with another property if this is sufficient to identify the element. The two together would make a composite primary key in database.
• you can use a unique id to identify the object (surrogate primary key) and use the id of the owning object as foreign key.

For PurchaseItem you have everything that is needed, although the diagram does not tell which of the two approaches you’ll use (e.g is the id unique globally, or unique within the purchase?).

But for PurchaseFinisher it is unclear if you could uniquely identify an occurence. If a payment method can only be used once per purchase, it’s fine as it may be used to identify the object. If it would be allowed to pay two times the same amount (half of the overall price) in the same currency with the same payment methods, you’d have undistinguishable duplicates. So, some kind of identifier will be needed from the database point of view.