Sottotipizzazione tabelle di database

Question

Ho sentito molto su sottotipizzazione tavoli durante la progettazione di un database, e io sono pienamente consapevole della teoria dietro di loro. Tuttavia, non ho mai visto in realtà tavolo subtyping in azione. Come si può creare sottotipi di tabelle? Sto usando MS Access, e sto cercando un modo di farlo in SQL, nonché attraverso la GUI (Access 2003).

Cheers!

Answer 1

Un esempio semplice sarebbe quella di avere un tavolo Persona con una chiave primaria e alcune colonne in quella tabella. Ora è possibile creare un'altra tabella chiamata studente che ha una chiave esterna alla tabella persona (il suo supertipo). Ora la tabella studente ha alcune colonne che il supertipo non ha come GPA, Maggiore, ecc Ma il nome, il cognome e tale sarebbe nella tabella padre. È sempre possibile accedere al nome del candidato Ritorna nella tabella persona attraverso la chiave esterna nella tabella degli studenti.

In ogni modo, basta ricordare quanto segue:

• La gerarchia raffigura rapporto tra supertipi e sottotipi
• Supertipi ha attributi comuni
• I sottotipi sono unici attributi

Answer 2

I sottotipi di tabelle è una cosa concettuale nei diagrammi EER. Non ho visto un RDBMS (esclusi i DBMS relazionale ad oggetti) che supporta direttamente. Di solito sono implementati in entrambe

1. Un set di colonne Null per ogni proprietà del sottotipo in un'unica tabella
2. Con un tavolo per le proprietà del tipo di base e alcuni altri tavoli con al massimo una riga per ogni tabella di base che conterrà proprietà sottotipo

Answer 3

La nozione di tabella sottotipi è utile quando si utilizza un mapper ORM per la produzione di classe sottotipo gerarchia che esattamente modelli dominio.

Una tabella sottotipo avrà sia una chiave esterna alla sua madre che è anche la chiave primaria della tabella del sotto-tipi.

Answer 4

Tenga presente che nella progettazione di un'applicazione associata, come con un'applicazione di Access, i sottotipi impongono un costo pesante in termini di join.

Per esempio, se si dispone di una tabella supertipo con tre tavoli sottotipo ed è necessario visualizzare tutti e tre in una singola forma in una sola volta (e avete bisogno di mostrare non solo la data supertipo), si finisce con una scelta di utilizzare tre outer join e Nz (), o avete bisogno di un UNION ALL di tre istruzioni SELECT reciprocamente esclusive (una per ogni sottotipo). Nessuno di questi sarà modificabile.

stavo per incollare qualche SQL dalla prima grande applicazione in cui ho lavorato con tavoli eccellente / sottotipo, ma a guardarla, la SQL è così complicato sarebbe solo confondere la gente. Che non è tanto perché la mia app è stato complicato, ma è perché la natura del problema è complesso - presentare la serie completa di dati per l'utente, sia super e sottotipi, è per sua natura complessa molto. La mia conclusione di lavorare con lui era che sarei stato meglio con un solo tavolo sottotipo.

Non Vale a dire che non è utile in alcune circostanze, solo che le forme rilegate di accesso non necessariamente lo rendono facile da presentare questi dati per l'utente.

Answer 5

Ho un problema simile che ho lavorato su.

Mentre alla ricerca di un modello ripetibile, ho voluto assicurarsi che non ho abbandonato l'integrità referenziale, il che significa che non vorrei utilizzare un (TABLE_NAME, PK_ID) soluzione.

Alla fine ho optato per:

Tipo basso Tabella: CLIENTE

Sottotipo Tabelle: persona, affari, GOVT_ENTITY

ho messo PRERSON_ID annullabile, BUSINESS_ID e campi GOVT_ENTITY_ID di cliente, con chiavi esterne su ciascuno, e un vincolo di controllo che solo uno non è nullo. E 'facile aggiungere nuovi tipi di sub, solo bisogno di aggiungere la chiave esterna annullabile e modificare il vincolo di controllo.