Quando dovremmo usare entità deboli durante la modellazione di un database?

Formalmente un'entità "debole" ha le seguenti caratteristiche.

1.  It is existence-dependent on another entity, i.e., 
    it cannot exist without the entity with which it has a relationship.

2.  It inherits at least part of it's primary key from the entity to which 
    it is related. 


    i.e. -> A weak entity's primary key must be a composite key that includes 
       the primary key of the entity on which it is existence-dependent.

Direi che in pratica non deciderà apertamente di fare qualcosa di un'entità "debole" di per sé; dovresti invece strutturare i dati per essere rappresentativi di qualsiasi cosa tu stia cercando di modellare. Se, dopo averlo fatto, guardi un'entità particolare e ha le caratteristiche di un'entità "debole", puoi documentarla o diagramla di conseguenza se per qualche ragione senti il bisogno di chiamarla esplicitamente o per il bene di formalità.

Un OrderItem non può esistere senza un ordine o un prodotto. Quindi è debole dato che le dipendenze lo controllano.

Se ad esempio rimuovi l'ordine, non hai modo di sapere dove deve essere spedito l'articolo. O se rimuovi il prodotto non sai cosa spedire.

Secondo la mia comprensione nel diagramma sopra, hanno incluso le due entità / tabelle invece di uno i.e ordini e ordine in modo tale che l'accesso alle informazioni diventa facile quando sono progettate due entità. E l'ordine è dipendente dall'entità ordini quindi è considerato come un'entità debole. perché la caratteristica dell'entità debole dipende da un'altra entità. Supponiamo che se non si includa l'entità dell'elemento dell'ordine, come sarà possibile conoscere il prezzo dell'articolo dell'articolo, lo sconto. e come ha detto jgauffin Se per esempio rimuovi l'ordine non hai modo di sapere dove l'oggetto dovrebbe essere spedito. O se rimuovi il prodotto non sai cosa spedire.

Il diagramma ER deve essere progettato in base ai requisiti aziendali.

Vedi, un ordine ha molti articoli dell'ordine (attributo multivalore). Quindi secondo la regola creiamo una tabella separata.

Ora diciamo che 2 clienti hanno lo stesso ordine.e.g entrambi acquistano iPhone allo stesso prezzo, sconto, stessa data, ecc. Quindi idealmente ci dovrebbero essere due tuple esatte per l'ordine di iPhone in relazione di ordine. Ma secondo il vincolo di una relazione, tutte le tuple dovrebbero essere uniche. Quindi, consente di mettere in relazione due ordini con lo stesso item_line_number.no problema ora. Ora considera uno dei cancelli del cliente. È iPhone order.also la tupla item_line_number sarà cancellata. Ora anche gli altri clienti che hanno acquistato l'iPhone vengono eliminati a causa della corrispondenza M: 1. Quindi, alla fine il database è incoerente. Ecco perché utilizziamo un codice descrittore che sarà orderid.quando l'eliminazione di un iPhone ordinato non provoca il danneggiamento del database.