Quando denormalizzi un database, devo mantenere le tabelle genitore?

Il tuo secondo esempio è effettivamente denormalizzato e le tabelle originali sono ridondanti, ma questo non è l'unico modo per denormalizzare i dati e mi azzarderei a dire che casi come questo sono rari. La denormalizzazione è un'ottimizzazione delle prestazioni, il che significa che lo fai perché hai problemi di prestazioni. Questi problemi sono diversi da caso a caso, quindi anche i modi per risolverli sono diversi.

Ricorda che la denormalizzazione ha un costo. Aggiornare il nome di una scuola è banale nel tuo primo esempio, ma costoso nel secondo.

Non penso che ci sia molto da guadagnare mettendo la colonna school_name in School_has_Student - quanto spesso cerchi il nome di una scuola, dato uno studente, alla rinfusa? Che tipo di volume raggiungerà ragionevolmente quel tipo di query? Il contrario (cercare i nomi di tutti gli studenti di una scuola) è più probabile che sia tassativo, quindi mantenere student_name potrebbe avere senso. Ora Student è ridondante, ma School non lo è.

Un altro esempio di denormalizzazione dello stesso database originale consiste nell'aggiungere una colonna number_of_students alla tabella School . Questo ottimizza per un tipo specifico di domande ("Quanti studenti ha questa scuola?", "Quale scuola ha il maggior numero di studenti?", Ecc.) Rimuovendo la necessità di guardare più righe nella tabella School_has_Student , ma tutte le tabelle sono ancora necessarie per le altre query.

Se anche gli studenti avevano un genere, dovresti mantenere la tabella Student poiché quelli non sono inclusi nella tabella School_has_Student . Puoi anche mantenere il rapporto di genere nella tabella School (un'altra denormalizzazione) e ora non hai tabelle ridondanti.

Puoi rimuovere tabelle ridondanti, ma non è probabile che tu le abbia.

... do I need to keep the School table and the Student table in the database or can I delete them?

Come sempre, dipende.

Come fonte di [particolari] rapporti, la tua forma denormalizzata è ragionevole.

Per il tipo qualsiasi di elaborazione delle transazioni (aggiornamento), non lo è.

Se possibile, mi piacerebbe avere entrambi . Questo è esattamente ciò che può ottenere una Vista (o, eventualmente, una Vista materializzata , a seconda del tuo DBMS). Entrambi generano la "forma" desiderata della tabella denormalizzata ed entrambi garantiscono che questa forma denormalizzata sarà al passo con le tabelle sensibilmente aggiornabili e normalizzate.

create view SchoolStudentView as 
select ss.school_id 
,      sch.school_name 
,      ss.student_id 
,      stu.student_name 
from       school_students  ss 
inner join schools  sch 
      on   ss.school_id = sch.id 
inner join students  stu 
      on   ss.student_id = stu.id ; 

Supponiamo di aver identificato argomenti validi per una tabella denormalizzata (ad esempio, comodità per le query con strumenti di terze parti, prestazioni, database distribuiti, ecc ...).

Se hai tutte le colonne delle tue tabelle originali nella tua tabella ridondante, potresti prendere in considerazione la rimozione delle tabelle originali.

Tuttavia, ti consiglio vivamente di mantenere le tabelle originali per i seguenti motivi:

• le tue tabelle School e Student potrebbero avere dati non ridondanti aggiuntivi (ad esempio indirizzo della scuola, ultimo grado dello studente).
• le tue tabelle School e Student potrebbero evolvere e prima o poi necessiteranno di tali dati aggiuntivi e potrebbero non essere necessariamente pertinenti per i componenti già sviluppati.
• dati criterio di accesso per dati aggiuntivi School o Student potrebbero essere diversi da School_has_student . Ad esempio, i vincoli sulla privacy (GDPR?) Potrebbero richiedere che l'età e l'indirizzo dello studente siano limitati a personale amministrativo con privilegi speciali.
• cambia in School e Student deve essere canalizzato tramite le tabelle originali, soprattutto se desideri implementare alcuni logica delle transazioni e blocco .
• gestire identità entità con ID univoci per School e Student è più facile con le tabelle originali, poiché è possibile utilizzare la funzione di numerazione automatica nella maggior parte degli RDBMS, mentre questa funzione non sarebbe utilizzabile con la tabella denormlizzata. Inoltre, l'uso dell'integrità referenziale può evitare errori di battitura e incongruenze.
• l'evoluzione dello schema di DB complessivo è prevedibile, ad esempio con una relazione molti-a-molti aggiuntiva come School - Teacher . La coerenza dei dati sarebbe facile da implementare con le tabelle originali (di nuovo, se necessario, con una denormalizzazione nella nuova relazione). Ma come garantiresti tale coerenza senza le "tabelle genitore" originali?

Molto spesso viene utilizzata una copia trasformata e denormalizzata di un database (per report, analisi, ecc.) piuttosto che attirare l'attenzione sul proprio database OLTP. Non è aggiornato al momento della versione "corretta", appena estratto e ricostruito periodicamente. In questi casi non è necessario mantenere l'originale poiché i dati sono precotti in base alle proprie esigenze. Le tabelle originali sono disponibili nella stadiazione e utilizzate solo durante l'ETL. Tuttavia dipende molto dal tuo caso d'uso. Allontanerei finché non ne avrai bisogno e anche in questo caso non tenterò di risolvere tutti i problemi allo stesso modo.