我正在研究用于分析已发布表单数据的星型模式。表单数据将发布到的站点实际上在托管表单的站点之外，因此只有表单中的数据可用。我将提供包含一些额外有用信息的选项，包括隐藏字段、原始推荐人、会话 ID 等。
我将能够使用正则表达式来匹配某些数据类型并将它们提取到特定维度，例如邮政编码。
我有一个解决维度的任意性质的解决方案，它不是一个很好的解决方案，但它会起作用。
我遇到的问题是我不知道我的事实表中会出现什么，它不像我可以聚合一个很好的数值。除了满足这些标准的“是的，有一个表单帖子”这一事实之外。
我想知道我是否以正确的方式处理这个问题？我是否使用了错误的工具来完成这项工作？还是我只是错过了什么？
西蒙。
更多细节：
有两个功能区域，根据标准过滤表单帖子，例如在两个时间戳之间。但就过滤而言，几乎所有东西都可以争夺。选定的表单帖子将用于生成 csv 文件以供导出。
另一个主要领域是分析，研究广告支出转化为客户线索是一个明显的起点。也有点开放式，取决于表单数据。
没有测量的事实表是可以的——它们只是被称为“无事实的事实表”。但是您通常仍会在其中放置一个 row_count 列——即使它的值始终为 1——以轻松添加汇总表。您可能会在以后添加其他测量值 - 例如对术语情绪的测量。
而且我不会太担心这看起来不像是仓储 101 的例子——在很多极端情况下会发生奇怪的事情。您当然可以将 field_name 和 field_value 作为列，如果您没有 field_name，甚至可以只使用 field_value。这样可行。它提供了极大的灵活性。
但是你错过了一些重要的功能。由于给定的项目或对象实际上被拆分为多行 - 典型的 sql 过滤不会很好地工作。您通常需要将所有行拉入一个可以整体评估它们的小应用程序中 - 或者编写一些非常复杂的多步骤 sql，在其中将每行评估的布尔结果插入临时表，然后按 session_id 分组（或不管是什么），然后最终评估和/或逻辑。
另一种选择 - 走这条路，但逐渐开发您的 ETL 解析功能，以便随着时间的推移，您可以将其中的一些内容提取到更传统的维度中。也许这会成为您的暂存表或原始表，但您会尝试让大多数报告符合您更传统的星型模式。
最后一个选项 - 考虑一个非关系数据库。更面向文档的东西可能会为您提供更好的功能。