名稱值對和事實表

Question

我正在處理髮布的表單數據分析的星型模式。表單數據將發佈到的網站實際上是託管表單的網站的外部，因此只有表單中的數據可用。我想給的選項包括與隱藏字段，原來的引薦，會話ID等一些額外的有用的信息

我就可以使用正則表達式匹配特定的數據類型，和他們拉出來的具體尺寸例如郵政編碼。

我有一個解決方案，以應對尺寸的任意性，它不是一個偉大的，但它會奏效。

，我的問題是，我不知道會是在我的事實表，它不喜歡的有，我可以聚集一個不錯的數值。除了符合這些標準的「是的，有一個表格帖子」的事實。

我想知道我是否以正確的方式接近這一點？我是否使用錯誤的工具來完成這項工作？或者我只是想念一些東西？

Simon。

進一步細節：

有兩個功能域，例如濾波形式帖依賴於標準在兩個時間戳之間。但是就過濾而言，幾乎任何東西都可以抓住。選定的表單文章將被用於生成一個csv文件以便導出。

另一個主要領域是分析，研究將廣告支出轉化爲客戶線索是一個明顯的起點。也有些開放式，取決於表單數據。

Answer 1

您並未設計星型模式。您正在設計Entity-Attribute-Value表，其中包含您正在識別的所有問題。

如果你真的不知道你的數據將是什麼樣子的，即什麼樣的形式存在的領域和應該使用什麼數據類型爲每一個，然後一個關係型數據庫是不是堅持信息的工具。嘗試使用XML或YAML或JSON。這些結構化，但動態的格式。您可以即時建立元數據。您可以將整個表單實例存儲在數據庫中的文件或BLOB中。

可以管理動態元

另一個新興技術是RDF，與查詢語言SPARQL。 Sesame是語義數據引擎的一個例子。

Answer 2

沒有測量值的事實表就可以了 - 他們只是被稱爲「無事實的事實表」。但是，您通常還是會在其中放置一個row_count列 - 即使該列的值始終爲1，以便輕鬆添加彙總表。最後你可能會在後面添加其他測量結果 - 例如對該術語的情緒進行測量。

而且我也不會太擔心，這看起來並不像一個倉庫101的例子 - 有很多的角落情況下，奇怪的事情發生了。如果沒有field_name，您肯定可以將field_namevalue_field作爲列，或者甚至只是field_value。這樣可行。它提供了很大的靈活性。

但是你錯過了一些重要的功能。由於給定的項目或對象實際上是跨多行分割的 - 典型的SQL過濾將無法正常工作。您通常需要將所有行都放入一個可以將它們作爲整體進行評估的小應用程序 - 或者編寫一些非常複雜的多步驟sql，將每行評估的布爾結果插入臨時表，然後按session_id（或無論什麼equiv），然後最終評估和/或邏輯。

另一個選擇 - 就是走這條路線，但逐步開發ETL解析功能，以便隨着時間的推移，您可以將這些東西拉出到更傳統的維度。也許這會成爲你的舞臺或原始表格，但是你會試圖讓大多數報告打擊你更傳統的星型模式。

最後一個選項 - 考慮一個非關係數據庫。更多面向文檔的東西可能會爲您提供更好的功能。