Имя Значение пары и таблицы фактов

Question

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

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

У меня есть решение проблемы произвольной природы измерений, оно не великое, но оно будет работать.

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

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

Саймон.

Подробнее:

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

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

Answer 1

Вы не проектируете звездную схему. Вы разрабатываете таблицу Entity-Attribute-Value , в которой есть все проблемы, которые вы идентифицируете.

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

Еще одной новой технологией, которая может управлять динамическими метаданными, является RDF с языком запросов SPARQL . Сезам является примером механизма семантических данных.

Answer 2

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

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

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

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

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