Quando dovremmo usare entità deboli quando modelliamo un database?

12

Questa è fondamentalmente una domanda su cosa sono le entità deboli? Quando dovremmo usarli? Come dovrebbero essere modellati?

Qual è la differenza principale tra entità normali ed entità deboli? Le entità deboli corrispondono agli oggetti valore durante la progettazione guidata dal dominio?

Per aiutare a mantenere la domanda sull'argomento, ecco un esempio tratto da Wikipedia che le persone possono utilizzare per rispondere a questa domanda: inserisci qui la descrizione dell'immagine

In questo esempio è OrderItemstato modellato come entità debole, ma non riesco a capire perché non possa essere modellato come entità normale.
Un'altra domanda è cosa succede se voglio tenere traccia della cronologia degli ordini (ovvero i cambiamenti nel suo stato) sarebbe un'entità normale o debole?

— Songo
fonte

10

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 deciderai apertamente di trasformare qualcosa in un'entità "debole" di per sé; dovresti invece strutturare i dati in modo che siano rappresentativi di qualunque cosa tu stia cercando di modellare. Se, dopo aver fatto ciò, guardi un'entità particolare e ha le caratteristiche di un'entità "debole", puoi documentarla o diagrammarla di conseguenza se per qualche motivo senti il bisogno di chiamarla esplicitamente o per amore di formalità.

— Ed Hastings
fonte

hmmm e il mio esempio? qui OrderItemdipende da Ordercome no orderItemspuò esistere senza appartenere a un order, ma non riesco a capire perché non posso usare ItemLineNumberper identificare esclusivamente un oggetto ?! In realtà potrei semplicemente ItemLineNumbergenerare un auto generato intper assicurare unicità e utilizzare una chiave esterna orderIDper collegare le due entità insieme ?!

— Songo,

2

Se definisci il tuo OrderItem per avere un ID sequenziale che identifica in modo univoco e OrderId non fa parte della chiave, stai trattando OrderItems come cittadini del primo ordine e non hanno davvero un'entità debole. Se lo desideri, puoi copiare individualmente altre tabelle su OrderItems; non è necessario disporre già di un OrderId per accedere a OrderItems. D'altra parte, se si digita OrderItem con OrderId e un sequenceId (o simile) rilevante per l'Ordine, si avrebbe un'entità debole e i singoli elementi pubblicitari sarebbero riferibili solo usando OrderId e sequenceId. Utilizzo del modello come previsto.

— Ed Hastings,

2

Inoltre, un commento tangenziale, può essere molto allettante dare a ogni tabella la propria chiave primaria sequenziale e mantenere le relazioni il più semplici possibile con relazioni PK-> FK a campo singolo. È ottimo in particolare per semplici database ed è facile ragionare. Tuttavia, quando si modellano relazioni più complesse e / o sofisticate, le chiavi composite diventano molto utili e offrono più opzioni per modellare le sfumature.

— Ed Hastings,

1

Un OrderItemnon può esistere senza un ordine o un prodotto. Quindi è debole poiché le sue dipendenze lo controllano.

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

— jgauffin
fonte

-1

Secondo la mia comprensione nel diagramma di cui sopra, hanno incluso le due entità / tabelle anziché una, ad esempio ordini e articolo ordine, in modo che l'accesso alle informazioni diventi facile quando vengono progettate due entità. E l'articolo dell'ordine dipende dall'entità ordini, quindi è considerato un'entità debole. perché la caratteristica dell'entità debole è che dipende da un'altra entità. Supponiamo che se non includi l'entità articolo dell'ordine come sarai in grado di conoscere il prezzo dell'articolo dell'ordine, lo sconto. e come diceva jgauffin Se, ad esempio, rimuovi l'ordine, non hai modo di sapere dove l'articolo dovrebbe essere spedito. O se rimuovi il prodotto non sai cosa spedire.

Il diagramma ER deve essere progettato in base alle esigenze aziendali.

— sam
fonte

-1

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

Ora, supponiamo che 2 clienti abbiano lo stesso ordine. Entrambi acquistano iPhone allo stesso prezzo, sconto, stessa data, ecc. Quindi idealmente dovrebbero esserci due tuple esatte per l'ordine di iPhone in relazione all'ordine. Ma secondo il vincolo di una relazione, tutte le tuple dovrebbero essere uniche. Quindi, consente di collegare due ordini allo stesso problema item_line_number.no fino ad ora. Ora considera uno dei clienti che annulla. IPhone order.anche la tupla item_line_number verrà eliminata. Ora anche gli altri clienti che hanno acquistato iPhone vengono eliminati a causa della corrispondenza M: 1. Quindi finalmente il database è incoerente. Ecco perché utilizziamo una chiave descrittore che sarà orderid.thus l'eliminazione di un iPhone ordinato non causa la corruzione del database.

— Baropia VIVEK
fonte