Nom Paires de valeurs et tables de faits

Question

Je travaille sur un schéma en étoile pour l'analyse des données de formulaire publiées. Le site sur lequel les données du formulaire seront postées est en réalité externe au site hébergeant le formulaire. Par conséquent, seules les données du formulaire seront disponibles. Je vais donner l'option d'inclure des informations supplémentaires utiles avec des champs cachés, des références originales, des identifiants de session, etc.

Je serai capable d'utiliser des expressions régulières pour faire correspondre certains types de données et les extraire à des dimensions spécifiques par exemple Codes postaux

J'ai une solution pour traiter la nature arbitraire des dimensions, ce n'est pas un grand, mais ça va marcher. Le problème que j'ai est que je n'ai aucune idée de ce qui va se passer dans ma table de faits, ce n'est pas comme s'il y avait une bonne valeur numérique que je peux agréger. Mis à part le fait que "oui il y a un formulaire" qui satisfait ces critères. Je me demande si j'aborde cela de la bonne façon? Est-ce que j'utilise le mauvais outil pour le travail? Ou suis-je juste manquer quelque chose?

Simon.

détails complémentaires:

Il y a deux zones de fonctionnalités, le filtrage des messages de forme en fonction des critères par exemple entre deux horodatages. Mais à peu près tout est en jeu en termes de filtrage. Les messages de formulaire sélectionnés seront ensuite utilisés pour générer un fichier csv à exporter.

L'autre domaine principal est l'analytique, l'étude de la conversion des dépenses publicitaires en prospects clients est un point de départ évident. Également un peu ouvert et dépend des données de formulaire.

Answer 1

Vous ne concevez pas un schéma en étoile. Vous concevez une table Entity-Attribute-Value, qui présente tous les problèmes que vous êtes en train d'identifier. Si vous ne savez vraiment pas à quoi ressembleront vos données, c'est-à-dire quels champs de formulaires existent et quels types de données utiliser pour chacun d'entre eux, une base de données relationnelle n'est pas le bon outil pour conserver les informations. Essayez XML ou YAML ou JSON. Ce sont des formats structurés, mais dynamiques. Vous pouvez établir des métadonnées à la volée. Vous pouvez stocker l'instance de formulaire entière dans un fichier ou dans un BLOB dans votre base de données.

Une autre technologie émergente qui peut gérer les métadonnées dynamiques est RDF, avec le langage de requête SPARQL. Sesame est un exemple de moteur de données sémantique.

Answer 2

Il est normal d'avoir des tables de faits sans mesures - elles sont simplement appelées "tables de faits sans faits". Mais vous y ajoutez toujours une colonne row_count - même si elle aura toujours une valeur - pour ajouter facilement des tableaux récapitulatifs. Et vous pouvez finir par ajouter d'autres mesures plus tard - comme une mesure du sentiment du terme par exemple.

Et je ne serais pas trop inquiet que cela ne ressemble pas à un exemple d'entreposage - il y a beaucoup de cas de coin où des choses étranges se produisent. Vous pouvez certainement avoir field_name & field_value en colonnes, ou même simplement field_value si vous n'avez pas de nom de champ. Ça marche. Et il fournit une tonne de flexibilité.

Mais vous manquez certaines fonctionnalités importantes. Étant donné qu'un objet ou un objet donné est réellement divisé sur plusieurs lignes, le filtrage sql typique ne fonctionnera pas correctement.Vous devez généralement rassembler toutes les lignes dans une petite application qui peut les évaluer dans leur ensemble - ou écrire un SQL multi-étapes très complexe où vous insérez les résultats booléens de chaque évaluation de ligne dans une table temporaire, puis groupez par session_id (ou quel que soit l'équiv), puis enfin évaluer pour et/ou la logique.

Une autre option - est de suivre cette voie, mais développez progressivement votre fonctionnalité d'analyse ETL de sorte que vous pouvez, avec le temps, tirer certaines de ces choses dans des dimensions plus traditionnelles. Peut-être que cela devient votre table de mise en scène ou votre table brute, mais vous essayez d'avoir la plupart des rapports sur votre schéma en étoile plus traditionnel.

Dernière option - considère une base de données non relationnelle. Quelque chose de plus orienté document peut vous fournir de meilleures fonctionnalités.