名称值对和事实表

Question

我正在研究用于分析已发布表单数据的星型模式。表单数据将发布到的站点实际上在托管表单的站点之外，因此只有表单中的数据可用。我将提供一些选项，包括一些额外的有用信息，包括隐藏字段、原始推荐人、会话 ID 等。

我将能够使用正则表达式来匹配某些数据类型并将它们提取到特定维度，例如邮政编码。

我有一个解决维度的任意性质的解决方案，它不是一个很好的解决方案，但它会起作用。

我的问题是我不知道我的事实表中会出现什么，它不像我可以聚合一个很好的数值。除了满足这些标准的“是的，有一个表单帖子”这一事实之外。

我想知道我是否以正确的方式处理这个问题？我是否使用了错误的工具来完成这项工作？还是我只是错过了什么？

西蒙。

更多细节：

有两个功能区域，根据条件过滤表单帖子，例如两个时间戳之间。但就过滤而言，几乎所有东西都可以争夺。选定的表单帖子将用于生成 csv 文件以供导出。

另一个主要领域是分析，研究将广告支出转化为潜在客户是一个明显的起点。也有点开放式，取决于表单数据。

Answer 1

您不是在设计星型模式。您正在设计一个 Entity-Attribute-Value 表，其中包含您要识别的所有问题。

如果您真的不知道您的数据会是什么样子，即存在哪些表单字段以及每个字段应使用哪些数据类型，那么关系数据库不是保存信息的正确工具。试试 XML、YAML 或 JSON。这些是结构化但动态的格式。您可以即时建立元数据。您可以将整个表单实例存储在文件中或数据库中的 BLOB 中。

另一种可以管理动态元数据的新兴技术是RDF，查询语言为SPARQL。 Sesame 是语义数据引擎的一个示例。

Answer 2

没有度量的事实表是可以的 - 它们只是被称为“无事实事实表”。但是您通常仍会在其中放置一个 row_count 列——即使它的值始终为 1——以轻松添加汇总表。您可能会在以后添加其他测量值 - 例如对术语情绪的测量。

而且我不会太担心这看起来不像仓储 101 示例 - 有很多奇怪的事情发生的极端情况。您当然可以将 field_name 和 field_value 作为列，如果您没有 field_name，甚至可以只使用 field_value。这样可行。它提供了极大的灵活性。

但是您错过了一些重要的功能。由于给定的项目或对象实际上被拆分为多行 - 典型的 sql 过滤不会很好地工作。您通常需要将所有行拉入一个可以整体评估它们的小应用程序中 - 或者编写一些非常复杂的多步骤 sql，在其中将每行评估的布尔结果插入临时表，然后按 session_id 分组（或不管是什么），然后最终评估和/或逻辑。

另一种选择 - 走这条路，但逐渐开发您的 ETL 解析功能，以便随着时间的推移您可以将其中的一些内容提取到更传统的维度。也许这会成为您的暂存表或原始表，但您会尝试让大多数报告符合您更传统的星型模式。

最后一个选项 - 考虑一个非关系数据库。更面向文档的内容可能会为您提供更好的功能。