Dubbi sulla rappresentazione di un carrello acquisti in Class Diagram / ER Database implicante ORM

1

Devo svolgere un'attività che sta leggendo un testo e creare un diagramma di classe. Una delle entità è un carrello acquisti.

Il mio dubbio è come rappresentare un carrello acquisti in un diagramma di classe, in seguito in un diagramma E / R e implicando un ORM nel processo. Ho letto un po 'prima di chiedere ma non riesco a chiarire le mie idee.

La definizione dei diagrammi di classe è "una mappa negli oggetti del mondo reale", giusto? Ho anche letto che quando si fa un digramma di classe, bisogna evitare di pensarlo come un diagramma ER, fino a qui, sto "bene".

Quindi, se penso a un carrello della vita reale, in un diagramma di classe lo rappresenterei in questo modo:

Carrello acquisti (attributi)

  • Id: int
  • Utente: utente
  • Prodotto: prodotto
  • Quantità: int
  • Prezzo: doppio

Quindi, se avessi usato un ORM avrei una tabella con quegli attributi come colonne e non è così che vorrei rappresentare un carrello acquisti in un DB perché è un modo inefficiente di salvare i dati. Il modo in cui lo vorrei in un DB sarebbe:

Intestazione carrello acquisti : (schema E / R)

  • Id: int
  • Utente: utente

Linee carrello acquisti : (diagramma E / R)

  • Id: int
  • Id_header: int
  • Prodotto: ID prodotto
  • Quantità: int
  • Prezzo: doppio

Quindi, ORM non sarebbe utile in questo caso.

Le mie domande sono:

  1. Se il mio carrello della spesa nel diagramma di classe (una entità) è sbagliato e dovrebbe essere come la progettazione del database (due entità), allora sto pensando in un "modo database" che è sbagliato, perché dovrei pensare su "oggetti del mondo reale" per creare il diagramma Class, poiché nel mondo reale c'è solo un carrello della spesa, non un'intestazione del carrello della spesa e una linea del carrello della spesa. Mi spiego? Questo è il punto principale a cui mi sto sforzando.
  2. Sarebbe sbagliato se faccio un diagramma in un diagramma di classe in un modo, e nel diagramma ER questo stesso diagramma è diverso?
  3. È il mio esempio, un esempio che dimostra che un ORM a volte è inutile?
posta seRgiOOOOOO 10.03.2017 - 01:20
fonte

1 risposta

2

Hai una grande differenza tra la progettazione della tua classe e il design della tua tabella.

La classe ShoppingCart può contenere solo una quantità qualsiasi di un singolo prodotto alla volta, ma le tabelle del database rappresentano un carrello della spesa che può contenere più prodotti diversi (ciascuno con la propria quantità).

Nella progettazione della classe, un carrello della spesa che può contenere più prodotti sarebbe simile a:

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

La classe ShoppingCartItem non è considerata un'entità a sé stante, ma è necessaria per creare una raccolta con elementi che hanno più attributi.
La somiglianza con la progettazione del database può essere considerata una coincidenza qui, e non il risultato della modellazione delle classi dopo le tabelle del database. Succede solo che la soluzione migliore qui sembra simile nella progettazione di classi e tabelle.

    
risposta data 10.03.2017 - 10:55
fonte