tool - design database online




Qual è la differenza tra le relazioni identificative e quelle non identificanti? (10)

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


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 proprietà di esso può cambiare da un proprietario all'altro. La relazione tra un libro e un proprietario è una relazione non identificante.

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.


Come ben spiegato nel link sottostante, 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 utilizzano simboli o concetti ER e il tipo di relazioni è: identificativo, non identificativo e non specifico.

Identificandoli sono le 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 con i propri attributi e quindi non può essere identificata in modo univoco dal proprio . Ogni accesso alla tabella figlio, sul modello fisico, dipenderà (inclusivo semanticamente) sulla chiave primaria del genitore, che diventa parte o totale della chiave primaria del bambino (anche essendo una chiave esterna), generalmente risultante in una chiave composita dal lato bambino. Le eventuali chiavi esistenti del bambino stesso sono solo pseudo o chiavi parziali, non sufficienti per identificare un'istanza di quel tipo di Entità o Set di Entità, senza il PK del genitore.

Le relazioni non identificative sono le relazioni ordinarie (parziali o totali), di serie di entità completamente indipendenti, le cui istanze non dipendono dalle rispettive chiavi primarie per essere identificate in modo univoco, sebbene possano avere bisogno di chiavi esterne per relazioni parziali o totali, ma non come la chiave primaria del bambino. Il bambino ha la sua chiave primaria. L'idem genitore. Entrambi in modo indipendente. 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 il PK del bambino, come quando è una relazione identificativa.

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


Ecco una buona descrizione:

Le relazioni tra due entità possono essere classificate come "identificative" o "non identificative". Le relazioni di identificazione esistono 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à figlia. Inoltre, le relazioni non identificative possono essere ulteriormente classificate come "obbligatorie" o "non obbligatorie". Esiste una relazione non identificativa obbligatoria 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

Gli attributi migrati dal genitore al figlio aiutano a identificare 1 il bambino?

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

Nota che la dipendenza dall'identificazione implica dipendenza dall'esistenza, ma non viceversa. Ogni FK non NULL significa che un bambino non può esistere senza genitore, ma questo da solo non rende identificabile la relazione.

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

PS Capisco che sono (estremamente) in ritardo per la festa, ma sento che altre risposte non sono del tutto accurate (definendole in termini di dipendenza dall'esistenza invece di dipendenza dall'identificazione), o piuttosto tortuose. Speriamo che questa risposta fornisca maggiore chiarezza ...

1 L'FK del bambino è una parte del vincolo PRIMARY KEY del bambino o un vincolo UNIQUE (non NULL).


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

Se l'elemento figlio deve essere mantenuto anche se il genitore è stato eliminato, allora si tratta di una parentela 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 allenamento
  • gli allenamenti 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 dovrebbero essere cancellate se uno dei tirocinanti, formazione o diploma correlati viene cancellato.


Un buon esempio viene dall'elaborazione degli ordini. Un ordine da un cliente di solito ha un numero d'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 di 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 potrebbero essere calcolati moltiplicando la quantità per l'elemento 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 dell'articolo "1". L'identità completa di un elemento pubblicitario è il numero dell'articolo insieme al numero dell'ordine di cui fa parte.

La relazione padre figlio tra gli ordini e gli elementi pubblicitari è quindi una relazione identificativa. Un concetto strettamente correlato nella modellazione ER va sotto il nome di "subentity", dove l'elemento pubblicitario è una subentità dell'ordine. In genere, una subentità ha una relazione di identificazione figlio-genitore obbligatoria per l'entità a cui è subordinata.

Nel classico design del database, la chiave primaria della tabella LineItems sarebbe (OrderNumber, ItemNumber). Alcuni dei progettisti 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.


Una relazione identificativa è tra due entità forti. Una relazione non identificante 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à genitore.

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

Riferimento basato su Bill Karwin


come utente287724 secondo esempio di risposta del rapporto libro e autore ottenuto 576 voti? !!! , come dice

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

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

Capisco finalmente la differenza tra entrambe le relazioni: ((, quindi per favore non confondermi con questa quantità di voti !!

sì, un libro non può essere scritto senza almeno un autore, ma l'autore (è la chiave straniera) del libro NON IDENTIFICA il libro nella tabella dei libri!

puoi rimuovere l'autore (FK) dalla riga del libro e puoi ancora identificare la riga del libro da qualche altro campo (ISBN, ID, ... ecc.), MA NON l'autore del libro !!

Penso che un valido esempio di identifying relationship sia la relazione tra (tabella prodotti) e una (tabella dettagli prodotto specifici) 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 il Product_ID nella tabella printers_details è considerato un FK fa riferimento alla tabella products.id e ALSO un PK nella tabella printers_details , questa è una relazione di identificazione perché Product_ID (FK) nella tabella delle stampanti IDENTIFICA della riga all'interno del child tabella, non possiamo rimuovere product_id dalla tabella figlio perché non possiamo più identificare la riga perché abbiamo perso la sua 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 importazioni e esportazioni per alcuni database di paesi

la tabella di import è il figlio che ha questi campi (the product_id(FK), the country_id(FK) , the amount of the imports , the price , the units imported , the way of transport(air, sea) ) possiamo usare il (product_id, country_id) per identificare ciascuna riga delle importazioni "se tutte nello stesso anno" qui entrambe le colonne possono comporre insieme una chiave primaria nella tabella figlio (importazioni) e fare anche riferimento alle tabelle padre.

per favore sono felice di aver finalmente capito il concetto della identifying relationship e della identifying relationship non identifying relationship : ( , quindi per favore non dirmi che ho sbagliato con tutti questi voti 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 puoi ancora identificare il libro !!! , per favore non dirmi che ho frainteso il concetto :(


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

Si dice più e più volte che nella relazione e nell'identificazione il bambino non può esistere senza il genitore. (ad es. user287724 ). Questo è vero, ma manca completamente il punto. Basterebbe che la chiave esterna fosse non nulla , per ottenere ciò. Non ha bisogno di essere parte della chiave primaria.

Quindi ecco la vera ragione:

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


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

    Esempio: una Person ha uno o più numeri di telefono. Se avessero un solo numero di telefono, potremmo semplicemente memorizzarlo in una colonna di Person . Dato che vogliamo supportare più numeri di telefono, creiamo una seconda tabella PhoneNumbers , la cui chiave primaria include la person_id riferimento alla tabella Person .

    Potremmo pensare al numero di telefono come a una persona, anche se sono modellati come attributi di una tabella separata. Questo è un person_id indizio che questa è una relazione identificativa (anche se non includiamo letteralmente person_id nella 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 bambino. Un buon esempio di ciò è una tabella di ricerca, ad esempio una chiave esterna su Person.state riferimento alla chiave primaria di States.state . Person è una tabella figlio rispetto agli States . Ma una riga in Person non è identificata dal suo attributo di state . Lo state non è parte della chiave primaria di Person .

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

Vedi anche la mia risposta a Confuso ancora sull'identificazione rispetto alle relazioni non identificative





data-modeling