Doubt about representing a Shopping Cart in Class Diagram/ER Database implicating ORM

Question

I have to do a task which is reading a text, and create a Class diagram. One of the entities is a Shopping Cart.

My doubt is how to represent a Shopping Cart in a class diagram, later on an E/R diagram and implicating an ORM in the process. I've been reading a little bit before asking but I cannot clarify my ideas.

Definition for Class diagrams is "a map in to real-world objects", right? I've also read that when doing a Class digram, you have to avoid thinking it as an ER Diagram, until here, I'm "okay".

So, if I just think about a real-world Shopping Cart, in a Class Diagram I would represent it like this:

Shopping Cart (attributes)

• Id: int
• User: User
• Product: Product
• Quantity: int
• Price: double

---

So, if I used an ORM I would have a table with those attributes as columns and that's not how I'd want to represent a Shopping Cart in a DB because that's an inefficient way of saving data. They way I would want it in a DB would be:

Shopping Cart Header: (E/R Diagram)

• Id: int
• User: User

Shopping Cart Lines: (E/R Diagram)

• Id: int
• Id_header: int
• Product: Product_Id
• Quantity: int
• Price: double

So, ORM wouldn't be useful in this case.

---

My questions are:

1. If my Shopping Cart in the Class diagram (one Entity) is wrong and it should be like database design (two Entities), then I'm thinking in a "database way" which it's supposed wrong because I would have to think about "real-world objects" to make the Class diagram, since in the real world there is just a Shopping Cart, not a Shopping Cart Header and a Shopping Cart Lines. Do I explain myself? This is the main point struggling me.
2. Would it be wrong if I do one diagram in a Class diagram in a way, and in the ER Diagram this same diagram is different?
3. Is my example, an example demonstrating that an ORM sometimes is useless?

Answer 1

You have a big difference between your class design and your table design.

The ShoppingCart class can hold only any quantity of a single product at a time, but your database tables represent a shopping cart that can hold multiple different products (each with their own quantity).

In class design, a shopping cart that can hold multiple products would look similar to:

class ShoppingCartItem {
  Product product
  int quantity
  double price
}
class ShoppingCart {
  int id
  User user
  Collection<ShoppingCartItem> items
}

The ShoppingCartItem class is not considered to be an entity in its own, but it is needed to create a collection with items that have multiple attributes.
The similarity with the database design can be considered to be coincidence here, and not the result of modelling the classes after the database tables. It just happens that the best solution here looks similar in class and table design.