Potresti prendere in considerazione un modello di dati di tipo/sottotipo. Questo è molto simile a classi/sottoclassi nella programmazione orientata agli oggetti, ma molto più scomodo da implementare e nessun RDBMS (di cui sono a conoscenza) le supporta in modo nativo. L'idea generale è:
- Definisci un tipo (Building), crei una tabella per esso, assegnagli una chiave primaria
- Definisci due o più sottotipi (qui, Ospedale, Clinica, Scuola, Università), crei tabelle per ciascuno di essi, crei chiavi primarie... ma le chiavi primarie sono anche chiavi esterne che fanno riferimento alla tabella Building
- La tua tabella con una colonna "ObjectType" ora può essere compilata con una chiave esterna nella tabella Building. Dovresti unirti ad alcuni tavoli per determinare che tipo di edificio è, ma dovresti farlo comunque. Quello o archiviare dati ridondanti.
Hai notato il problema con questo modello, giusto? Cosa impedisce a un edificio di avere voci in due o più tabelle dei sottotipi? Sono contento che tu abbia chiesto:
- Aggiungi una colonna, forse "BuildingType", a Building, ad esempio char(1) con i valori consentiti di {H, C, S, U} che indicano (duh) il tipo di edificio.
- Crea un vincolo univoco su BuildingID + BuildingType
- Avere la colonna BulidingType nelle sottotabelle. Metti un vincolo di controllo su di esso in modo che possa essere impostato solo sul valore (H per la tabella Ospedali, ecc.) In teoria, questa potrebbe essere una colonna calcolata; in pratica, questo non funzionerà a causa del passaggio seguente:
- Costruisci la chiave esterna per mettere in relazione le tabelle utilizzando entrambe le colonne
Voilà:dato un set di righe EDILIZIA con tipo H, non è possibile impostare una voce nella tabella SCUOLA (con tipo S) per fare riferimento a quell'Edificio
Ricorderai che ho detto che era difficile da implementare.
In effetti, la grande domanda è:vale la pena farlo? Se ha senso implementare i quattro (o più, col passare del tempo) tipi di edificio come tipo/sottotipo (ulteriori vantaggi di normalizzazione:un posto per l'indirizzo e altri attributi comuni a ogni edificio, con attributi specifici dell'edificio memorizzati nelle sottotabelle), potrebbe valere lo sforzo extra per costruire e mantenere. In caso contrario, sei tornato al punto di partenza:un modello logico difficile da implementare nell'RDBMS medio moderno dei giorni nostri.
