Una colonna di chiave esterna fa riferimento a una singola tabella. Se si desidera fare riferimento a una tabella diversa come chiave esterna, è necessario disporre di una colonna chiave diversa o seconda chiave esterna. Non puoi avere una singola colonna che sia un tipo di unione di chiavi esterne diverse (la prima colonna della tua chiave composta suggerita). Non esiste nemmeno un tipo di colonna per la tabella stessa (la seconda parte della chiave composta suggerita).
Puoi simulare ciò usando stringhe per le chiavi e le stringhe per le tabelle (yuk!), ma avrà un impatto drammatico su tutte le tue tabelle e le loro query.
Tutto questo fa parte di ciò che è noto come Corrispondenza relazionale all'oggetto
.
Il polimorfismo per classe non è semplicemente una caratteristica del modello relazionale standard, sebbene alcuni database specifici includano l'ereditarietà come estensione.
Il supporto per il polimorfismo e / o l'ereditarietà è presente principalmente nel modello relazionale come attributi: (1) gli attributi possono essere facoltativi, ovvero possono memorizzare null invece di un valore e (2) nuovi attributi possono essere aggiunti a piacimento per supporta nuove sottoclassi. Quindi, probabilmente la mappa più pulita di una classe con sottoclassi è quella di modellare ogni attributo nella stessa tabella singola, con attributi per sottoclassi come attributi opzionali, mentre gli attributi per la classe base sono obbligatori (se così fosse).
Funziona piuttosto bene per alcune cose, ma non è perfetto almeno nel seguente:
- non esiste un'identificazione speciale di quale sottoclasse è vera una particolare riga e,
- non c'è modo di garantire che gli attributi richiesti di una determinata sottoclasse siano tutti presenti quando la riga è intesa come un'istanza di quella particolare sottoclasse (perché dovevamo contrassegnare gli attributi della sottoclasse come facoltativi).
Per ulteriori informazioni sulla modellizzazione dell'ereditarietà nei db relazionali, vedi: