Difficoltà a decidere sulla relazione di identificazione o non identificazione

Question

Ho letto questa domanda: Qual è la differenza tra relazioni identificative e non identificative?

Ma non sono ancora troppo sicuro ... Quello che ho sono tre tabelle.

1. Utenti
2. Oggetti
3. Foto

Un utente può possedere molti oggetti e può anche pubblicare molte immagini per singolo oggetto. Il mio istinto mi dice che questa è una relazione identificativa, perché avrò bisogno dell'ID utente nella tabella degli oggetti e avrò bisogno dell'ID oggetto nelle tabelle delle immagini ...

O sbaglio? Le spiegazioni nell'altro argomento si limitano alla spiegazione teorica del modo in cui il database lo interpreta dopo che è già stato codificato, non come gli oggetti sono collegati nella vita reale. Sono un po 'confuso su come prendere la decisione di identificare e non identificare quando penso a come costruirò il database.

Answer 1

Entrambi sembrano identificarmi relazioni. Se hai sentito i termini uno a uno o uno a molti e molti a molti, relazioni uno a due sono relazioni identificative e < forti> relazioni molti-a-molti sono relazioni non identificative .

• Se il bambino identifica il suo genitore, è una relazione identificativa. Nel link che hai indicato, se hai un numero di telefono, sai a chi appartiene (appartiene solo a uno).

• Se il bambino non identifica il suo genitore, è una relazione non identificativa. Nel collegamento, menziona gli stati. Pensa a uno stato come a una riga in una tabella che rappresenta l'umore. & Quot; Felice " non identifica una persona in particolare, ma molte persone.

Modifica : altri esempi di vita reale:

• Un indirizzo fisico è una relazione non identificativa, poiché molte persone possono risiedere a un indirizzo. D'altro canto, un indirizzo e-mail è (generalmente considerato) una relazione identificativa.
• Un numero di previdenza sociale è una relazione identificativa, poiché appartiene a una sola persona
• I commenti sui video di Youtube identificano le relazioni, perché appartengono a un solo video.
• Un originale di un dipinto ha un solo proprietario (identificativo), mentre molte persone possono possedere ristampe del dipinto (non identificative).

Answer 2

Penso che un modo più semplice per visualizzarlo sia chiedersi se il record del figlio può esistere senza il genitore. Ad esempio, un elemento pubblicitario dell'ordine richiede l'esistenza di un'intestazione dell'ordine. Pertanto, un elemento pubblicitario dell'ordine deve avere l'identificatore dell'intestazione dell'ordine come parte della sua chiave e, quindi, questo è un esempio di relazione identificativa.
D'altra parte, i numeri di telefono possono esistere senza la proprietà di una persona, sebbene una persona possa avere più numeri di telefono. In questo caso, la persona che possiede il numero di telefono è una relazione non chiave o non identificativa poiché i numeri di telefono possono esistere indipendentemente dalla persona del proprietario (quindi, la persona del proprietario del numero di telefono può essere nulla mentre nell'esempio di elemento pubblicitario dell'ordine , l'identificatore dell'intestazione dell'ordine non può essere nullo.

Answer 3

  

NickC Said: le relazioni uno-a-uno stanno identificando le relazioni e le relazioni molti-a-molti sono relazioni non identificative

La spiegazione mi sembra totalmente sbagliata. Puoi avere:

• Relazioni non identificative Ono-to-One
• Relazioni uno-a-molti non identificative
• Relazioni identificative individuali
• Relazioni identificative uno-a-molti
• Relazioni di identificazione molti-a-molti

Immagina di avere le seguenti tabelle: customer , products e feedback . Tutti sono basati sul customer_id che esiste nella tabella cutomer . Quindi, secondo la definizione di NickC non dovrebbe esistere alcun tipo di relazione identificativa Many-to-Many, tuttavia nel mio esempio puoi vedere chiaramente che: Un Feedback può esistere solo se il esiste un prodotto pertinente ed è stato acquistato dal cliente, pertanto cliente, prodotti e feedback devono essere identificativi .

Puoi dare un'occhiata a Manuale MySQL , spiegando come aggiungere chiavi esterne anche su MySQL Workbench.

Answer 4

Mahdi, i tuoi istinti sono corretti. Questa è una domanda duplicata e questa risposta votata non è corretta o completa. Guarda le prime due risposte qui: differenza tra l'identificazione di non identificazione

L'identificazione e la non identificazione non hanno nulla a che fare con l'identità. Chiediti semplicemente che può esistere la documentazione figlio senza il genitore? Se la risposta è sì, non è identificabile.

Il problema principale se la chiave primaria del figlio include la chiave esterna del genitore. Nella relazione non identificativa la chiave primaria (PK) del bambino non può includere la chiave esterna (FK).

Ponetevi questa domanda

• Il record figlio può esistere senza il record padre?

Se il figlio può esistere senza il genitore, la relazione non è identificativa. (Grazie MontrealDevOne per averlo dichiarato più chiaramente)

Relazione identificativa individuale

I numeri di previdenza sociale si adattano perfettamente a questa categoria. Immaginiamo ad esempio che i numeri di previdenza sociale non possano esistere senza una persona (forse possono in realtà, ma non nel nostro database) > person_id sarebbe il PK per la persona , comprese le colonne come un nome e indirizzo . (manteniamolo semplice). La tabella social_security_number includerebbe la colonna ssn e la colonna person_id come chiave esterna. Poiché questo FK può essere utilizzato come PK per la tabella numero_securezza sociale , si tratta di una relazione identificativa.

Relazione uno-a-uno non identificativo

In un grande complesso di uffici potresti avere una tabella ufficio che include i numeri delle camere per piano e numero dell'edificio con un PK e una tabella dipendente separata. La tabella dei dipendenti (figlio) ha un FK che è la colonna office_id dalla tabella PK ufficio . Mentre ogni dipendente ha un solo ufficio e (per questo esempio) ogni ufficio ha un solo dipendente, questa è una relazione non identificativa poiché gli uffici possono esistere senza dipendenti e gli impiegati possono cambiare ufficio o lavorare sul campo.

Relazioni uno-a-molti

Le relazioni uno-a-molti possono essere facilmente classificate ponendo la stessa domanda.

Rapporti molti-a-molti

Le relazioni molti a molti identificano sempre le relazioni. Questo può sembrare contro intuitivo, ma abbi pazienza con me. Prendi due tabelle libary e libri , ogni biblioteca ha molti libri ed esiste una copia di ogni libro in molte biblioteche.

Ecco cosa lo rende e la relazione identificativa: Per implementarlo è necessaria una tabella di collegamento con due colonne che sono le chiavi primarie di ogni tabella. Chiamale colonna library_id e ISBN . Questa nuova tabella di collegamento non ha una chiave primaria separata, ma aspetta! Le chiavi esterne diventano una chiave primaria a più colonne per la tabella di collegamento poiché i record duplicati nella tabella di collegamento sarebbero privi di significato. I collegamenti non possono esistere senza i genitori; pertanto, questa è una relazione identificativa. Lo so, schifo vero?

Il più delle volte il tipo di relazione non ha importanza.

Detto questo, di solito non devi preoccuparti di ciò che hai. Basta assegnare le chiavi primarie ed esterne appropriate a ciascuna tabella e la relazione si scoprirà.

EDIT: NicoleC , ho letto rispondi sei collegato e concorda con il mio. Prendo il suo punto su SSN e sono d'accordo che questo è un cattivo esempio. Proverò a escogitare un altro esempio più chiaro lì. Tuttavia, se iniziamo a utilizzare analogie del mondo reale nella definizione di una relazione di database, le analogie si interrompono sempre. Non importa se un SSN identifica una persona, importa se lo hai usato come chiave esterna.