Come modellare i dati relazionali che possono essere organizzati in più modi? [chiuso]

2

Sto lavorando a un progetto che sta creando un sistema per gestire i dati (10-20 milioni di record) raccolti da un'organizzazione di ricerca. Una delle sfide è che anche se i dati sono superficialmente simili in tutta l'organizzazione (con un insieme di campi ragionevolmente simile), ci sono attualmente 20-30 diversi database usati per gestirlo, e forse una dozzina di modi per organizzarlo. Il sistema in costruzione dovrebbe sostituire gradualmente tutti questi elementi.

L'idea è stata quella di creare un singolo modello di dati concettuali e uno schema di database che fosse abbastanza flessibile da gestire tutti i diversi modi di organizzare i dati. Le entità nel modello formano una rete (non una gerarchia rigida) e una singola porzione di dati usa solo alcune delle entità e le relazioni tra di esse. Non ci sarebbe un unico concetto centrale di un "oggetto database" che sarebbe condiviso da tutti.

Sto trovando il modello risultante difficile da capire, sviluppare e spiegare agli utenti, dal momento che ci sono così tanti modi possibili di usarlo ed espanderlo. Sento anche che avere un singolo modello e uno schema di database crea un falso senso di coerenza, senza far pensare alla gente se sia davvero utile avere tanti modi diversi di gestire e archiviare i dati.

Ho iniziato a pensare che invece di un singolo modello flessibile e uno schema di database, forse dovremmo definire solo le entità e gli attributi e avere diversi modelli che descrivono modi alternativi su come possono essere raggruppati. E invece di creare un database relazionale con metodi alternativi per collegare le tabelle, creando un database di documenti che consentirebbe diversi schemi di documenti gerarchici alternativi.

Esistono le best practice sulla modellazione e il database di tali dati che possono essere organizzati in modi molto diversi, nonostante abbiano per lo più set di attributi condivisi?

    
posta Wollemia 30.10.2017 - 21:09
fonte

2 risposte

2

Anche se personalmente non ne ho avuto la necessità, ho sentito parlare di Domain Driven Design più di una volta in incontri di discussione da parte di programmatori per organizzazioni di ricerca locali con problemi simili. In particolare, DDD parla della necessità di contesti limitati e della mappatura del contesto quando la modellazione diventa complessa.

I contesti limitati sono aree in cui vengono utilizzate le stesse parole per descrivere concetti simili ma ambigui. L'esempio nell'articolo che ho collegato nel paragrafo precedente è un conto bancario rispetto a un conto bancario online (il nome utente e la password che utilizzi per accedere, ecc.). Vuoi usare la parola Account per descrivere entrambe le cose. Hanno molti campi in comune, come la stessa persona, ad esempio, ma combinarli in un unico oggetto Account (o tabella di database) sarebbe un errore.

Questi contesti limitati sono identificati con l'aiuto di esperti di dominio. Potresti vedere decine di modi per organizzarlo, ma dovrebbero essere in grado di aiutarti a ridurre questo numero in modo significativo. Consiglio vivamente di prendere il libro DDD e di imparare i dettagli da qualcuno che ne sa molto più di me.

    
risposta data 30.10.2017 - 22:53
fonte
0

È difficile rispondere con le informazioni fornite, ma spesso quando hai bisogno di più modi per guardare gli stessi dati, potresti aver bisogno di una sorta di Database OLAP (elaborazione analitica online) .

In OLAP, dovresti creare (relativamente semplici) tabelle per contenere fatti , quindi una serie di tabelle dimensionali che sono essenzialmente versioni denormalizzate delle tabelle dei fatti. Le tabelle dimensionali consentono ognuna un diverso modo di affettare i dati; per esempio, la tabella tempo-dimensionale denormalizza i fatti in una struttura piatta con il tempo come chiave. Se trovi un nuovo modo di guardare i dati, puoi mantenere le tabelle dei fatti e aggiungere una nuova tabella dimensionale; ad esempio, se vuoi esaminare le differenze per età dell'utente, potresti avere una tabella delle dimensioni per età. L'integrità dei dati viene effettuata tramite la forza bruta; le tabelle delle dimensioni dovranno essere generate e rigenerate man mano che le tabelle dei fatti vengono aggiornate. Quindi questo non è un approccio che avresti mai usato per OLTP. Ma potrebbe funzionare nel tuo caso.

    
risposta data 30.10.2017 - 23:14
fonte