Domanda

Sto lavorando a uno schema a stella per l'analisi dei dati dei moduli pubblicati. Il sito in cui verranno inviati i dati del modulo è in realtà esterno al sito che ospita il modulo, quindi saranno disponibili solo i dati nel modulo. Darò la possibilità di includere alcune informazioni extra utili con campi nascosti, referrer originale, ID sessione ecc.

Sarò in grado di utilizzare espressioni regolari per abbinare determinati tipi di dati ed estrarli a dimensioni specifiche, ad es. Codici postali.

Ho una soluzione per affrontare la natura arbitraria delle dimensioni, non è eccezionale ma funzionerà.

Il problema che ho è che non ho idea di cosa sarà nella mia tabella dei fatti, non è come se ci fosse un bel valore numerico che posso aggregare. A parte il fatto che "sì, esiste un modulo post" che soddisfa questi criteri.

Mi chiedo se mi sto avvicinando a questo nel modo giusto? Sto usando lo strumento sbagliato per il lavoro? O mi sto perdendo qualcosa?

Simon.

Ulteriori dettagli:

Esistono due aree di funzionalità, che filtrano i post del modulo in base a criteri, ad es. tra due timestamp. Ma praticamente tutto è in palio in termini di filtraggio. I post del modulo selezionato verranno quindi utilizzati per generare un file CSV per l'esportazione.

L'altra area principale è l'analisi, lo studio della conversione della spesa pubblicitaria in lead dei clienti è un ovvio punto di partenza. Anche un po 'aperto e dipende dai dati del modulo.

È stato utile?

Soluzione

Non stai progettando uno schema a stella. Stai progettando una Entity-Attribute-Value , che contiene tutti i problemi che stai identificando.

Se davvero non hai idea di come appariranno i tuoi dati, ovvero quali campi del modulo esistono e quali tipi di dati dovrebbero essere usati per ognuno, un database relazionale non è lo strumento giusto per conservare le informazioni. Prova XML o YAML o JSON. Questi sono formati strutturati, ma dinamici. Puoi stabilire metadati al volo. È possibile memorizzare l'intera istanza del modulo in un file o in un BLOB nel database.

Un'altra tecnologia emergente in grado di gestire metadati dinamici è RDF , con il linguaggio di query SPARQL . Sesame è un esempio di un motore di dati semantico.

Altri suggerimenti

Va ??bene avere tabelle dei fatti senza misurazioni - sono semplicemente chiamate "tabelle dei fatti senza fatti". Ma in genere inserisci comunque una colonna row_count - anche se avrà sempre un valore di uno - per aggiungere facilmente tabelle di riepilogo. E potresti finire per aggiungere altre misurazioni in seguito, ad esempio una misurazione del sentimento del termine.

E non mi preoccuperei troppo che questo non sembri un esempio di magazzino 101 - ci sono molti casi angolari in cui accadono cose strane. Puoi certamente avere field_name & amp; field_value come colonne, o anche solo field_value se non hai field_name. Che funzioni. E offre una grande flessibilità.

Ma ti stai perdendo alcune importanti funzionalità. Poiché un determinato articolo o oggetto è realmente suddiviso su più righe, il tipico filtro sql non funzionerà bene. In genere è necessario inserire tutte le righe in una piccola app in grado di valutarle nel loro insieme o scrivere un sql multi-step molto complesso in cui inserire i risultati booleani di ogni valutazione di riga in una tabella temporanea, quindi raggruppare per session_id (o qualunque sia l'equiv), infine valuta e / o logica.

Un'altra opzione è quella di seguire questa strada, ma gradualmente sviluppare la funzionalità di analisi ETL in modo che nel tempo sia possibile estrarre alcune di queste cose in dimensioni più tradizionali. Forse questo diventa il tuo staging o tabella non elaborata, ma cerchi di fare in modo che la maggior parte dei report raggiunga il tuo schema a stella più tradizionale.

Ultima opzione: considera un database non relazionale. Qualcosa di più orientato ai documenti può offrirti una migliore funzionalità.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top