Standardizzazione dell'estrazione dei dati

1

Faccio parte di un team incaricato di eseguire alcune analisi predittive con un enorme database relazionale. I dati sono un disastro. La documentazione varia da mediocre a errata a assente. Le informazioni sono sparse su tutti i tavoli.

Ad esempio, se voglio abbinare gli indirizzi ai numeri di telefono, posso interrogare tre o quattro tabelle diverse, ciascuna contenente informazioni sconosciute agli altri, e forse ci sono alcune informazioni che non dovrei usare.

Per ottenere dati, le persone con cui lavoro si affidano strongmente al folklore: sanno che per ottenere i numeri di telefono dagli indirizzi, devi interrogare questo e questo in quel modo perché John glielo ha detto alcuni anni fa. E John lo sapeva perché Sam glielo aveva detto. E così via. Il folklore non è essenzialmente sfidato e spesso non è così giusto.

Recuperare le informazioni è un problema e passiamo la maggior parte del nostro tempo semplicemente estraendolo dal database, senza nemmeno provare a fare qualcosa di intelligente con esso.

Mi piacerebbe stabilire uno standard che possiamo usare in tutti i nostri progetti. Inoltre, mi piacerebbe che migliorasse mentre raccogliamo il folklore. Non voglio creare un super documento "How to do it" che probabilmente genererà un milione di varianti locali. Quindi, in sostanza, penso di voler incapsulare la conoscenza del dominio in "qualcosa".

Ho pensato che potremmo creare tabelle che aggregano informazioni sparse in un unico posto, documentano e interrogano quei nuovi tavoli da ora in poi invece di affidarsi al folklore. Quindi non più tre posizioni per numeri di telefono e indirizzi, una tabella TelephoneToAddress .

Ha senso? Nel contesto dello sfruttamento dei dati, è anche una buona idea?

    
posta Brasillement 06.12.2016 - 06:52
fonte

4 risposte

1

L'approccio pratico consiste nell'incapsulare ciò che apprendi sui dati nelle viste del database, che forniscono un'interfaccia coerente e interrogabile ai dati sottostanti.

Inserisce la logica nel database, dove può essere utilizzata e la esprime in termini che gli esperti di database conoscono (cioè SQL).

    
risposta data 06.12.2016 - 10:26
fonte
0

Considerando che non hai molta idea sull'organizzazione dei dati. Se fossi in te, prenderei in considerazione la possibilità di raccogliere diversi folklore di accesso ai dati richiesti e chiedere loro di modellarlo attorno a un grafico con i nodi come tabelle e campi come bordi.

Una volta preparati questi set di grafici, puoi eliminare quelli ridondanti (ad esempio se hai tre modi diversi per trovare i numeri di telefono ma ne vuoi solo uno, puoi utilizzare il modello che sembra funzionare meglio (o qualsiasi altro vincolo che possiedi) e impostalo come standard e deprecare gli altri grafici).

Una volta ottenuti questi grafici, utilizzali come modello per creare le tue tabelle più recenti.

E / O Considerando che sembra che tu debba fare qualche analisi predittiva (che comporterà l'interrogazione dei dati in una moltitudine di modi), un database grafico sembra essere un approccio adatto per il database enorme standard aggregato. Questo ti aiuterà ragazzi con benefici come le query espressive e la gestione semplice delle relazioni con i dati, da cui il problema sembra derivare.

    
risposta data 06.12.2016 - 08:20
fonte
0

Non ha senso mettere una persona morta in bei vestiti. Non sarà in grado di ballare. Se la tua fonte di dati è marcia, non spendere un centesimo per ottenere dati puliti. Piuttosto, consolidare i dati da dove provengono e renderli un'unica fonte. Se sei costretto a ballare con i morti, cerca un altro lavoro.

    
risposta data 06.12.2016 - 09:45
fonte
-1

Vorrei andare con la rimozione delle varianti ridondanti prima & inserendolo in una tabella come si pensava piuttosto riferendosi a un'origine dati ridondante. Scrivi un pacchetto che verrà eseguito su intervallo & fai la pulizia.

    
risposta data 06.12.2016 - 08:47
fonte

Leggi altre domande sui tag