名前と値のペアとファクトテーブル

Question

投稿フォームデータの分析のためにスタースキーマに取り組んでいます。フォームデータが投稿されるサイトは、実際にはフォームをホストしているサイトの外部にあるため、フォーム内のデータのみが利用可能になります。隠しフィールド、元のリファラー、セッションIDなどの追加の有用な情報を含めるオプションを提供します。

正規表現を使用して、特定のデータ型を照合し、特定のディメンション、たとえば郵便番号。

次元のdimensions意的な性質に対処する解決策がありますが、それは素晴らしいものではありませんが、機能します。

私が抱えている問題は、ファクトテーブルに何が入るかわからないということです。集計できる素敵な数値があるわけではありません。 「フォームポストがあります」という事実は別として、これらの基準を満たしている。

これに正しい方法でアプローチしているのだろうか？仕事に間違ったツールを使用していますか？それとも私は何かが足りないのですか？

サイモン。

詳細：

機能には2つの領域があり、基準に応じてフォーム投稿をフィルタリングします。 2つのタイムスタンプ間。しかし、フィルタリングに関しては、ほとんど何でも手に入れることができます。選択したフォーム投稿は、エクスポート用のcsvファイルを生成するために使用されます。

もう1つの主要な領域は分析です。広告支出の顧客リードへの変換を調べることは、明らかな出発点です。また、いくぶんオープンエンドで、フォームデータに依存します。

Answer 1

スタースキーマを設計していません。 Entity-Attribute-Value テーブルを設計しています。特定している問題。

データがどのように見えるか、つまりどのフォームフィールドが存在し、各フィールドにどのデータ型を使用すべきかがまったくわからない場合、リレーショナルデータベースは情報を保持するための適切なツールではありません。 XMLまたはYAMLまたはJSONを試してください。これらは構造化されていますが、動的な形式です。その場でメタデータを確立できます。フォームインスタンス全体をファイルまたはデータベースのBLOBに保存できます。

動的メタデータを管理できる別の新しいテクノロジーは、 RDF で、クエリ言語は SPARQL 。 ゴマはセマンティックデータエンジンの例です。

Answer 2

ファクトテーブルに測定値がなくても構いません-「ファクトレスファクトテーブル」と呼ばれます。ただし、通常は常にrow_count列を配置します-常に1の値を持ちますが-サマリーテーブルを簡単に追加します。そして、たとえば用語の感情の測定など、他の測定値を後で追加する場合があります。

そして、これが倉庫101の例のように見えないことをあまり心配しません-奇妙なことが起こる多くのコーナーケースがあります。確かにfield_name＆amp;を持つことができますfield_valueを列として、またはfield_nameがない場合はfield_valueのみ。動作します。また、非常に柔軟性があります。

しかし、いくつかの重要な機能が欠けています。特定のアイテムまたはオブジェクトは実際には複数の行に分割されているため、一般的なSQLフィルタリングはうまく機能しません。通常、すべての行を全体として評価できる小さなアプリにプルするか、各行評価のブール結果を一時テーブルに挿入する非常に複雑なマルチステップSQLを作成し、session_idでグループ化する必要があります（または等）、最終的におよび/またはロジックを評価します。

別のオプション-この方法を使用しますが、ETL構文解析機能を徐々に開発して、時間の経過とともにこれらのものをより伝統的な次元に引き出せるようにします。おそらくこれがステージングテーブルまたは生のテーブルになりますが、ほとんどのレポートが従来のスタースキーマにヒットするようにしようとしています。

最後のオプション-非リレーショナルデータベースを検討します。よりドキュメント指向の何かがより良い機能を提供するかもしれません。