Qual è la differenza tra relazioni identificative e non identificative?

Non sono stato in grado di cogliere appieno le differenze. Puoi descrivere entrambi i concetti e usare esempi del mondo reale?

• Una relazione identificativa si verifica quando l'esistenza di una riga in una tabella figlio dipende da una riga in una tabella padre. Ciò può essere fonte di confusione perché in questi giorni è pratica comune creare uno pseudokey per una tabella figlio, ma non creare la chiave esterna per la parte padre della chiave primaria del figlio. Formalmente, il modo "giusto" per farlo è rendere la chiave esterna parte della chiave primaria del bambino. Ma la relazione logica è che il bambino non può esistere senza il genitore.

  Esempio: A Personha uno o più numeri di telefono. Se avessero un solo numero di telefono, potremmo semplicemente memorizzarlo in una colonna di Person. Poiché vogliamo supportare più numeri di telefono, creiamo una seconda tabella PhoneNumbers, la cui chiave primaria include il person_idriferimento alla Persontabella.

  Potremmo pensare ai numeri di telefono come appartenenti a una persona, anche se sono modellati come attributi di una tabella separata. Questo è un chiaro indizio che si tratta di una relazione identificativa (anche se non includiamo letteralmente person_idla chiave primaria di PhoneNumbers).

• Una relazione non identificativa si verifica quando gli attributi della chiave primaria del genitore non devono diventare attributi della chiave primaria del figlio. Un buon esempio di ciò è una tabella di ricerca, ad esempio una chiave esterna per fare Person.stateriferimento alla chiave primaria di States.state. Personè una tabella figlio rispetto a States. Ma una riga in Personnon è identificata dal suo stateattributo. Cioè statenon fa parte della chiave primaria di Person.

  Una relazione non identificativa può essere facoltativa o obbligatoria , il che significa che la colonna chiave esterna consente NULL o non consente NULL, rispettivamente.

Vedi anche la mia risposta a Ancora confuso sull'identificazione rispetto alle relazioni non identificative

C'è un'altra spiegazione dal mondo reale:

Un libro appartiene a un proprietario e un proprietario può possedere più libri. Ma il libro può esistere anche senza il proprietario e la sua proprietà può cambiare da un proprietario all'altro. La relazione tra un libro e un proprietario è una relazione non identificativa.

Un libro, tuttavia, è stato scritto da un autore e l'autore avrebbe potuto scrivere più libri. Ma il libro deve essere scritto da un autore - non può esistere senza un autore. Pertanto, la relazione tra il libro e l'autore è una relazione identificativa.

La risposta di Bill è corretta, ma è scioccante vedere che tra tutte le altre risposte nessuno sottolinea l'aspetto più significativo.

Si dice ancora e ancora, che nella relazione identificativa il bambino non può esistere senza il genitore. (es. user287724 ). Questo è vero, ma manca completamente il punto. Per ottenere ciò sarebbe sufficiente che la chiave esterna fosse non nulla . Non è necessario che faccia parte della chiave primaria.

Quindi ecco il vero motivo:

Lo scopo di una relazione identificativa è che la chiave esterna non può MAI CAMBIARE , perché fa parte della chiave primaria ... quindi identificando !!!

Una relazione di identificazione specifica che un oggetto figlio non può esistere senza l'oggetto genitore

Le relazioni non identificative specificano un'associazione regolare tra oggetti, cardinalità 1: 1 o 1: n.

Le relazioni non identificative possono essere specificate come facoltative quando non è richiesto un genitore o obbligatorie quando è richiesto un genitore impostando la cardinalità della tabella padre ...

Ecco una buona descrizione:

Le relazioni tra due entità possono essere classificate come "identificative" o "non identificative". Esistono relazioni di identificazione quando la chiave primaria dell'entità padre è inclusa nella chiave primaria dell'entità figlio. D'altra parte, esiste una relazione non identificativa quando la chiave primaria dell'entità padre è inclusa nell'entità figlio ma non come parte della chiave primaria dell'entità figlio. Inoltre, le relazioni non identificative possono essere ulteriormente classificate come "obbligatorie" o "non obbligatorie". Esiste una relazione obbligatoria non identificativa quando il valore nella tabella figlio non può essere nullo. D'altra parte, esiste una relazione non identificativa non obbligatoria quando il valore nella tabella figlio può essere nullo.

http://www.sqlteam.com/article/database-design-and-modeling-fundamentals

Ecco un semplice esempio di una relazione identificativa:

Parent
------
ID (PK)
Name

Child
-----
ID (PK)
ParentID (PK, FK to Parent.ID) -- notice PK
Name

Ecco una relazione non identificativa corrispondente:

Parent
------
ID (PK)
Name

Child
-----
ID (PK)
ParentID (FK to Parent.ID) -- notice no PK
Name

La risposta di user287724 fornisce il seguente esempio della relazione tra libro e autore:

Tuttavia, un libro è stato scritto da un autore e l'autore avrebbe potuto scrivere più libri. Ma il libro deve essere scritto da un autore e non può esistere senza un autore. Pertanto la relazione tra il libro e l'autore è una relazione identificativa.

Questo è un esempio molto confuso e sicuramente non è un esempio valido per un identifying relationship.

Sì, un booknon può essere scritta senza almeno una author, ma la author(è chiave esterna) del booksi non identifica l' booknella bookstavola!

È possibile rimuovere il author(FK) dalla bookfila e ancora in grado di identificare la riga libro di qualche altro campo ( ISBN, ID, ... ecc), ma non l'autore del libro !!

Penso che un valido esempio di identifying relationshipsarebbe la relazione tra (tabella dei prodotti) e una (tabella dei dettagli del prodotto specifico)1:1

products table
+------+---------------+-------+--------+
|id(PK)|Name           |type   |amount  |
+------+---------------+-------+--------+
|0     |hp-laser-510   |printer|1000    |
+------+---------------+-------+--------+
|1     |viewsonic-10   |screen |900     |
+------+---------------+-------+--------+
|2     |canon-laser-100|printer|200     |
+------+---------------+-------+--------+

printers_details table
+--------------+------------+---------+---------+------+
|Product_ID(FK)|manufacturer|cartridge|color    |papers|
+--------------+------------+---------+---------+------+
|0             |hp          |CE210    |BLACK    |300   |
+--------------+------------+---------+---------+------+
|2             |canon       |MKJ5     |COLOR    |900   |
+--------------+------------+---------+---------+------+
* please note this is not real data

In questo esempio, Product_IDnella printers_detailstabella viene considerato un FK che fa riferimento alla products.idtabella e ANCHE un PK nella printers_detailstabella, questa è una relazione di identificazione poiché il Product_ID(FK) nella tabella delle stampanti STA IDENTIFICANDO la riga all'interno della tabella figlio, non è possibile rimuovere la product_iddalla tabella figlio perché non possiamo identificare la riga più perché abbiamo perso è chiave primaria

Se vuoi metterlo in 2 righe:

una relazione identificativa è la relazione quando l'FK nella tabella figlio è considerato un PK (o identificatore) nella tabella figlio mentre fa ancora riferimento alla tabella padre

Un altro esempio potrebbe essere quando si hanno 3 tabelle (importazioni - prodotti - paesi) in un database di importazioni ed esportazioni per alcuni paesi

La importtabella è il figlio che ha questi campi (il product_id(FK), il country_id(FK), la quantità delle importazioni, il prezzo, le unità importate, il modo di trasporto (aereo, marittimo)) we may use the (product_id , thecountry_id`) per identificare ogni riga delle importazioni "se sono tutte nello stesso anno" qui entrambe le colonne possono comporre insieme una chiave primaria nella tabella figlio (importazioni) e anche fare riferimento a tali tabelle padre.

Per favore, sono felice di aver finalmente capito il concetto di identifying relationshipe non identifying relationship, quindi per favore non dirmi che ho torto con tutti questi voti positivi per un esempio completamente non valido

Sì, logicamente un libro non può essere scritto senza un autore, ma un libro può essere identificato senza l'autore, infatti non può essere identificato con l'autore!

Puoi rimuovere al 100% l'autore dalla riga del libro e ancora identificare il libro! .

Relazione non identificativa

Una relazione non identificativa significa che un figlio è imparentato con un genitore ma può essere identificato da solo.

PERSON    ACCOUNT
======    =======
pk(id)    pk(id)
name      fk(person_id)
          balance

La relazione tra ACCOUNT e PERSON non è identificativa.

Identificare la relazione

Una relazione di identificazione significa che il genitore è necessario per dare identità al figlio. Il bambino esiste solo a causa del genitore.

Ciò significa che anche la chiave esterna è una chiave primaria.

ITEM      LANGUAGE    ITEM_LANG
====      ========    =========
pk(id)    pk(id)      pk(fk(item_id))
name      name        pk(fk(lang_id))
                      name

La relazione tra ITEM_LANG e ITEM sta identificando. E tra ITEM_LANG e LANGUAGE.

Se si considera che l'elemento figlio deve essere eliminato quando viene eliminato il genitore, si tratta di una relazione di identificazione.

Se l'elemento figlio deve essere conservato anche se il genitore viene eliminato, si tratta di una relazione non identificativa.

Ad esempio, ho un database di formazione con tirocinanti, corsi di formazione, diplomi e sessioni di formazione:

• i tirocinanti hanno una relazione identificativa con le sessioni di formazione
• i corsi di formazione hanno una relazione identificativa con le sessioni di allenamento
• ma i tirocinanti hanno una relazione non identificativa con i diplomi

Solo le sessioni di formazione devono essere eliminate se viene eliminato uno dei tirocinanti, formazione o diploma correlati.

La relazione identificativa significa che l'entità figlio dipende totalmente dall'esistenza dell'entità madre. Esempio di tabella persona tabella persona e persona account. La tabella persona account viene identificata solo dall'esistenza della tabella account e persona.

La relazione non identificativa indica che la tabella figlio non è identificata dall'esistenza dell'esempio della tabella padre, esiste una tabella come accounttype e account. La tabella accounttype non è identificata con l'esistenza della tabella account.

Come ben spiegato nel link seguente, una relazione identificativa è in qualche modo simile a una relazione di tipo entità debole con il suo genitore nel modello concettuale ER. I CAD in stile UML per la modellazione dei dati non usano simboli o concetti ER e il tipo di relazioni sono: identificativo, non identificativo e non specifico.

Identificare quelli sono relazioni genitore / figlio in cui il bambino è una specie di entità debole (anche nel modello ER tradizionale chiamato relazione identificativa), che non ha una vera chiave primaria dai suoi attributi e quindi non può essere identificato in modo univoco dai suoi . Ogni accesso alla tabella figlio, sul modello fisico, dipenderà (incluso semanticamente) dalla chiave primaria del genitore, che diventa parte o totale della chiave primaria del figlio (essendo anche una chiave esterna), generando generalmente una chiave composita dal lato bambino. Le eventuali chiavi esistenti del figlio stesso sono solo chiavi pseudo o parziali, non sufficienti per identificare qualsiasi istanza di quel tipo di Entità o Insieme di Entità, senza il PK del genitore.

Le relazioni non identificative sono le relazioni ordinarie (parziali o totali), di insiemi di entità completamente indipendenti, le cui istanze non dipendono dalle reciproche chiavi primarie per essere identificate in modo univoco, sebbene possano aver bisogno di chiavi esterne per relazioni parziali o totali, ma non come chiave primaria del bambino. Il bambino ha la sua chiave primaria. L'idem genitore. Entrambi indipendentemente. A seconda della cardinalità della relazione, il PK di uno va come un FK all'altro (lato N) e, se parziale, può essere nullo, se totale, non deve essere nullo. Ma, in una relazione come questa, l'FK non sarà mai anche la PK del bambino, come nel caso di una relazione identificativa.

http://docwiki.embarcadero.com/ERStudioDA/XE7/en/Creating_and_Editing_Relationships

Gli attributi migrati da genitore a figlio aiutano a identificare ¹ figlio?

• Se sì : esiste la dipendenza dall'identificazione, la relazione si sta identificando e l'entità figlio è "debole".
• In caso contrario : la dipendenza dall'identificazione non esiste, la relazione non è identificativa e l'entità figlio "forte".

Si noti che la dipendenza dall'identificazione implica dipendenza dall'esistenza, ma non viceversa. Ogni FK non NULL significa che un figlio non può esistere senza genitore, ma questo da solo non identifica la relazione.

Per ulteriori informazioni su questo (e alcuni esempi), dai un'occhiata alla sezione "Identificazione delle relazioni" della Guida ai metodi ERwin .

PS Mi rendo conto di essere (estremamente) in ritardo alla festa, ma sento che altre risposte non sono del tutto accurate (definendole in termini di dipendenza dall'esistenza invece di dipendenza dall'identificazione), o in qualche modo tortuose. Speriamo che questa risposta fornisca maggiore chiarezza ...

¹ L'FK del bambino fa parte del PRIMARY KEY del bambino o del vincolo UNIQUE (non NULL).

Un buon esempio viene dall'elaborazione dell'ordine. Un ordine da un cliente in genere ha un numero di ordine che identifica l'ordine, alcuni dati che si verificano una volta per ordine come la data dell'ordine e l'ID cliente e una serie di elementi pubblicitari. Ogni elemento pubblicitario contiene un numero articolo che identifica un elemento pubblicitario all'interno di un ordine, un prodotto ordinato, la quantità di quel prodotto, il prezzo del prodotto e l'importo per l'elemento pubblicitario, che possono essere calcolati moltiplicando la quantità per il prezzo.

Il numero che identifica un elemento pubblicitario lo identifica solo nel contesto di un singolo ordine. Il primo elemento pubblicitario in ogni ordine è il numero articolo "1". L'identità completa di un elemento pubblicitario è il numero dell'articolo insieme al numero dell'ordine di cui fa parte.

La relazione figlio principale tra ordini ed elementi pubblicitari è quindi una relazione identificativa. Un concetto strettamente correlato nella modellazione ER si chiama "subentity", in cui l'elemento pubblicitario è una subentity dell'ordine. In genere, una entità secondaria ha una relazione di identità figlio-genitore obbligatoria con l'entità a cui è subordinata.

Nella progettazione classica del database, la chiave primaria della tabella LineItems sarebbe (OrderNumber, ItemNumber). Alcuni dei designer di oggi darebbero a un articolo un ItemID separato, che funge da chiave primaria ed è autoincrementato dal DBMS. Raccomando il design classico in questo caso.

Diciamo che abbiamo quei tavoli:

user
--------
id
name


comments
------------
comment_id
user_id
text

la relazione tra queste due tabelle identificherà la relazione. Perché, solo i commenti possono appartenere al suo proprietario, non ad altri utenti. per esempio. Ogni utente ha il proprio commento e quando l'utente viene eliminato, anche i commenti di questo utente devono essere eliminati.

Una relazione identificativa è tra due entità forti. Una relazione non identificativa potrebbe non essere sempre una relazione tra un'entità forte e un'entità debole. Può esistere una situazione in cui un bambino stesso ha una chiave primaria ma l'esistenza della sua entità può dipendere dalla sua entità madre.

Ad esempio: può esistere una relazione tra un venditore e un libro in cui un libro viene venduto da un venditore in cui il venditore può avere la propria chiave primaria ma la sua entità viene creata solo quando un libro viene venduto

Riferimento basato su Bill Karwin