1

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

正規表現を使用して特定のデータ型に一致させ、郵便番号などの特定の次元に引き出すことができます。

次元の恣意的な性質に対処するための解決策があります。それは素晴らしいものではありませんが、うまくいくでしょう。

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

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

サイモン。

詳細:

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

もう 1 つの主な分野は分析です。広告費から顧客へのリードへの変換を研究することは、当然の出発点です。また、多少オープンエンドであり、フォームデータに依存します。

4

2 に答える 2

2

スター スキーマを設計していません。あなたが特定しているすべての問題を含むEntity-Attribute-Valueテーブルを設計しています。

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

動的メタデータを管理できるもう 1 つの新しいテクノロジは、クエリ言語SPARQLを使用したRDFです。 Sesameはセマンティック データ エンジンの一例です。

于 2008-11-18T17:24:17.250 に答える
0

測定値のないファクト テーブルを使用してもかまいません。それらは単に「ファクトレス ファクト テーブル」と呼ばれます。ただし、サマリー テーブルを簡単に追加するために、通常はそこに row_count 列を配置します (値は常に 1 ですが)。また、後で他の測定値を追加することになる場合もあります。たとえば、用語のセンチメントの測定値などです。

そして、これが倉庫 101 の例のように見えなくても、あまり心配する必要はありません。奇妙なことが起こるまれなケースがたくさんあります。field_name と field_value を列として使用することも、field_name がない場合は field_value のみを使用することもできます。それはうまくいきます。そして、それは非常に高い柔軟性を提供します。

しかし、いくつかの重要な機能を見逃しています。特定のアイテムまたはオブジェクトは実際には複数の行に分割されているため、通常の SQL フィルタリングはうまく機能しません。通常、すべての行を全体として評価できる小さなアプリにプルする必要があります。または、各行評価のブール結果を一時テーブルに挿入し、session_id (または同等のものは何でも)、最後に and/or ロジックを評価します。

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

最後のオプション - 非リレーショナル データベースを検討してください。よりドキュメント指向のものは、より優れた機能を提供する可能性があります。

于 2009-12-03T22:51:27.647 に答える