Domanda

Esistono coppie di domande in merito alla richiesta di differenze / spiegazioni sull'identificazione e la non identificazione della relazione nel database delle relazioni.

La mia domanda è: riesci a pensare a un termine più semplice per questi gerghi? Comprendo che i termini tecnici devono essere specifici e inequivocabili. Ma avere un "nome alternativo" potrebbe aiutare gli studenti a relazionarsi più facilmente al concetto alla base.

In realtà vogliamo usare un termine più profano nel nostro strumento di modellizzazione del database, in modo che gli utenti alle prime armi senza un grande background di informatica possano imparare più velocemente.

evviva!

È stato utile?

Soluzione

Vedo spesso tabella figlio o tabella dipendente usata come termine laico. Puoi utilizzare uno di questi termini per una tabella con una relazione di identificazione

Quindi dire che una tabella di riferimento è una tabella con una relazione non identificativa.

Ad esempio, PhoneNumbers è un figlio di Users , poiché un numero di telefono ha una relazione identificativa con il suo utente (ovvero la chiave primaria di PhoneNumbers include una chiave esterna per la chiave primaria di Users ).

Mentre la tabella Users ha una colonna state che è una chiave esterna della tabella States , rendendola una relazione non identificativa. Quindi potresti dire Users referenze States , ma non ne è figlio di per sé.

Altri suggerimenti

Penso che appartenga a sarebbe un buon nome per la relazione identificativa.

Un tipo di entità "debole" " non ha una propria chiave, solo una "chiave parziale", quindi ogni istanza di questo tipo di entità debole deve appartenere a qualche altra istanza di entità in modo che possa essere identificata, e questa è una "relazione identificativa". Ad esempio, un proprietario potrebbe avere un database con appartamenti e camere . Una stanza può essere chiamata cucina o bagno , e mentre quel nome è unico all'interno di un appartamento, ci saranno molte stanze nel database con name cucina , quindi è solo una chiave parziale. Per identificare in modo univoco una stanza nel database, devi dire che è la cucina in questo particolare appartamento. In altre parole, le stanze appartengono a appartamenti.

Raccomanderò il termine "entità debole" dalla modellazione ER.

Alcuni modellisti concettualizzano l'argomento come costituito da entità e relazioni tra entità. Ciò dà origine al modello Entity-Relationship (ER Modeling). Un attributo può essere associato a un'entità o una relazione e i valori memorizzati nel database sono istanze di attributi.

Se si esegue la modellazione ER, esiste un tipo di entità chiamata "entità debole". Parte dell'identità di un'entità debole è l'identità di un'entità più forte, a cui appartiene quella debole.

Un esempio potrebbe essere un ordine in un sistema di elaborazione degli ordini. Gli ordini sono costituiti da elementi pubblicitari e ogni elemento pubblicitario contiene un ID prodotto, un prezzo unitario e una quantità. Ma gli elementi pubblicitari non hanno un numero identificativo per tutti gli ordini. Invece, un elemento pubblicitario è identificato da {numero articolo, numero ordine}. In altre parole, un elemento pubblicitario non può esistere a meno che non faccia esattamente parte di un ordine. L'articolo numero 1 è il primo oggetto in qualunque ordine appartenga, ma per identificare un articolo sono necessari entrambi i numeri.

È facile trasformare un modello ER in un modello relazionale. È anche facile per le persone che sono esperte nei dati ma non sanno nulla dei database per abituarsi a un modello ER dei dati che comprendono.

Ci sono altri modellisti che discutono con veemenza contro la necessità di modellare ER. Non sono uno di loro.

Niente, assolutamente niente nel tipo di modellazione in cui si incontrano cose come "relazioni". (ER, presumo) è "tecnico", "preciso" o "non ambiguo". Né può essere.

A) La modellazione ER è sempre e per necessità informale, perché non può mai essere sufficiente per acquisire / esprimere l'intera definizione di un database.

B) Esistono così tanti dialetti ER diversi che è impossibile per tutti usare esattamente gli stessi termini con lo stesso significato. Di recente, ho anche scoperto che alcune università del Regno Unito che insegnano la modellazione ER, usano il termine "sottotipo entità". per la stessa cosa che ho sempre usato per nominare il "tipo di entità" e viceversa!

Si potrebbe usare connessione .

Hai una connessione tra due tabelle, in cui gli ID sono gli stessi.

Questo tipo di cose.

che ne dici

  • Associazione
  • Link
  • Correlazione
Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top