Пары значений имени и таблицы фактов

Question

Я работаю над звездообразной схемой для анализа данных опубликованной формы.Сайт, на котором будут опубликованы данные формы, фактически является внешним по отношению к сайту, на котором размещена форма, поэтому будут доступны только данные в форме.Я собираюсь предоставить возможность включать дополнительную полезную информацию со скрытыми полями, исходным реферером, идентификатором сеанса и т. д.

Я смогу использовать регулярные выражения для сопоставления определенных типов данных и приводить их к определенным измерениям, например.Почтовые индексы.

У меня есть решение проблемы произвольности размеров, оно не очень хорошее, но сработает.

Проблема в том, что я понятия не имею, что будет в моей таблице фактов, это не значит, что есть хорошее числовое значение, которое я мог бы агрегировать.Не считая того, что «да, есть форма сообщения», удовлетворяющая этим критериям.

Мне интересно, правильно ли я подхожу к этому?Я использую неправильный инструмент для работы?Или я просто что-то упускаю?

Саймон.

Дальнейшие детали:

Существует две области функциональности: фильтрация сообщений формы в зависимости от критериев, например.между двумя метками времени.Но с точки зрения фильтрации можно получить практически все.Выбранные сообщения формы затем будут использоваться для создания CSV-файла для экспорта.

Другая основная область — аналитика. Очевидной отправной точкой является изучение конверсии рекламных расходов в потенциальных клиентов.Также несколько открытый и зависит от данных формы.

Answer 1

Вы не разрабатываете звездообразную схему.Вы разрабатываете Сущность-атрибут-значение таблица, в которой есть все выявленные вами проблемы.

Если вы действительно понятия не имеете, как будут выглядеть ваши данные, т.е.какие поля формы существуют и какие типы данных следует использовать для каждого из них, то реляционная база данных не является подходящим инструментом для сохранения информации.Попробуйте XML, YAML или JSON.Это структурированные, но динамичные форматы.Вы можете устанавливать метаданные на лету.Вы можете сохранить весь экземпляр формы в файле или в BLOB-объекте в вашей базе данных.

Еще одна новая технология, которая может управлять динамическими метаданными, — это РДФ, с языком запросов СПАРКЛ. Кунжут является примером механизма семантических данных.

Answer 2

Вполне нормально иметь таблицы фактов без измерений — их просто называют «таблицами фактов без фактов».Но вы все равно обычно помещаете туда столбец row_count (даже если он всегда будет иметь значение, равное единице), чтобы легко добавлять сводные таблицы.И позже вы можете добавить другие измерения — например, измерение настроения термина.

И я бы не стал слишком волноваться, что это не похоже на пример складского хранения 101 — есть много крайних случаев, когда происходят странные вещи.Конечно, вы можете использовать имя_поля и значение_поля в качестве столбцов или даже просто значение_поля, если у вас нет имени_поля.Это работает.И это обеспечивает массу гибкости.

Но вы упускаете некоторые важные функции.Поскольку данный элемент или объект действительно разделен на несколько строк, типичная фильтрация sql не будет работать должным образом.Обычно вам нужно перенести все строки в небольшое приложение, которое может оценить их как единое целое, или написать очень сложный многошаговый sql, в котором вы вставляете логические результаты оценки каждой строки во временную таблицу, а затем группируете их по session_id (или независимо от эквивалента), затем, наконец, оцените логику и/или логику.

Другой вариант — пойти по этому пути, но постепенно развивать свою функциональность синтаксического анализа ETL, чтобы со временем вы могли перенести некоторые из этих вещей в более традиционные измерения.Возможно, это станет вашей промежуточной или необработанной таблицей, но вы стараетесь, чтобы большинство отчетов соответствовало вашей более традиционной звездообразной схеме.

Последний вариант — рассмотреть нереляционную базу данных.Что-то более ориентированное на документы может обеспечить вам лучшую функциональность.