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?
  • Classes don't have to represent real world objects. Relational database tables are a more primitive way to compose data. This is why your initial class structure would be preferred, with mapping code performing the translation between the database structure and the class structure. The class is a higher level abstraction. – Frank Hileman Mar 10 '17 at 8:47
  • Except in this case your class contains only one product. Why? – Frank Hileman Mar 10 '17 at 8:50
  • Originally, ER diagrams were used to represent ER models. Today, most ER diagrams represent relational models. The difference is very significant in this context. An "entity" is much more like an "object" than a relation (or a table) is. A real ER model and a class model should correspond rather nicely, although not exactly. Constructing arelational model from an ER model is pretty straightforward. – Walter Mitty Mar 10 '17 at 10:55

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.

Your Answer

