Chi garantisce l'integrità dei dati di una tabella denormalizzata, io o il DBMS?

Question

Chi garantisce l'integrità dei dati di una tabella denormalizzata, io o il DBMS?

#1 da (6 voti)
#2 da (2 voti)
#3 da (2 voti)

1

Nel seguente database, School_has_Student è una tabella denormalizzata:

Orasehodecisodicambiareilnomedellostudente"paul" in "john" nella tabella Student , il nome dello studente "paul" che esiste due volte nella tabella School_has_Student deve essere automaticamente cambiato in "john" per mantenere l'integrità dei dati.

Allo stesso modo, se il nome dello studente "paul" in una delle due righe della tabella School_has_Student viene cambiato in "john", quindi l'altro nome dello studente "paul" nella tabella School_has_Student e il "paul" il nome dello studente nella tabella Student deve essere automaticamente modificato in "john" per mantenere l'integrità dei dati.

Ma chi si assicura che queste modifiche automatiche avvengano, dovrei scrivere un trigger per assicurarmi che queste modifiche si verifichino, oppure il DBMS offre questa funzionalità fuori dalla scatola (o dipende dal DBMS usato)?

database database-design relational-database

posta Tom 19.10.2018 - 08:53

fonte

3 risposte

Leggi altre domande sui tag database database-design relational-database

Perché la maggior parte delle macchine virtuali del linguaggio sono progettate con un'architettura di carico / archivio? C'è un vantaggio di velocità rispetto a un'architettura di registro-memoria? Unit testing Markov codice catena

score 6 · Answer 1

But who make sure that these automatic changes happen, should I write a trigger to make sure these changes happen, or does the DBMS offer this feature out of the box (or does it depend on the DBMS used)?

Offre questa funzionalità immediatamente, si chiama "normalizzazione". Se il valore è solo in un punto, cambiandolo significherà che tutti quelli che fanno riferimento allo spot hanno l'ultimo valore. Come hai intenzionalmente evitato, devi farlo manualmente, con trigger o logica del programma.

A quel punto, dovresti chiederti perché eviti la normalizzazione. Normalmente è fatto per guadagnare qualcosa. Accertati che sia così, perché la reimplementazione di tutto ciò che puoi avere con un database normalizzato su un database non normalizzato non è un guadagno. Probabilmente è peggio di quello che il database potrebbe già fare fuori dalla scatola. Per ottenere qualcosa, devi lasciare andare qualcosa.

score 2 · Answer 2

Che cosa pensi di guadagnare facendo duplicare i dati student_name e school_name su più tabelle. Il principio fondamentale del design dello schema del database dovrebbe essere " unica fonte di verità ", a meno che tu non abbia una buona ragione.

score 2 · Answer 3

But who make sure that these automatic changes happen ...

Nessuno. Queste modifiche sono non automatiche.

... does the DBMS offer this feature out of the box (or does it depend on the DBMS used)?

Vedi [la mia risposta a] il tuo altro post sull'utilizzo di Views per [dinamicamente] creare la forma denormalizzata da una ragionevole, normalizzata. Come sospetti, diversi DBMS offrono diversi modi per farlo. Le viste probabilmente soddisfano le tue esigenze per ora. Per i Big Data, potrebbe essere necessario ricorrere a Viste materializzate, in cui il database crea una tabella in base a una definizione di visualizzazione e quindi mantiene tale tabella in linea con gli aggiornamenti delle tabelle normalizzate. Per i Big Data è meglio, ma hai [almeno] due copie dei dati in modo che il tuo database sia [molto] più grande. Con una vista, si memorizzano solo le tabelle "origine"; la versione denormalizzata è costruita "al volo".

Penso che, ormai, (dopo almeno tre post in diversi forum) tu abbia capito che provare a mantenere questa "cosa" denormalizzata per te sarà assolutamente orrendo. Mantieni "dentro la scatola" e la tua vita sarà un intero molto più facile.