2013-03-18 2 views
2

В настоящее время я пытаюсь определить, как построить таблицу измерения ключевых слов. Мы отслеживаем посещения сайтов на нашем веб-сайте и хотели бы найти наиболее используемые ключевые слова, используемые для поиска через поисковую систему для сайта, а также любые поисковые термины, используемые во время посещения сайта (цена> 100 долларов США, обзор> 4 звезды и т. д.). Поскольку ключевые слова являются полностью динамическими и могут использоваться в бесконечном количестве комбинаций, мне трудно найти способы хранения этих ключевых слов. У меня есть таблица фактов просмотра страниц, которая включает запись каждый раз, когда просматривается страница. Источник, из которого я выхожу, включает все условия поиска в разделительном списке. Я могу анализировать регулярное выражение, я просто не знаю, как его хранить в базе данных, поскольку количество ключевых слов может значительно варьироваться от просмотра страницы к просмотру страниц. Я думаю, что это может быть больше подходит для решения NOSQL, которое пытается втиснуть его в таблицу MSSQL, но я не знаю. Любая помощь очень ценится!измерение ключевого слова clickstream

+0

Как их хранить во 2-й таблице, как обычно, в среде OLTP? – usr

+0

Вторая таблица? Я не уверен, что я следую, ты имеешь в виду звездную схему? Я бы хотел, чтобы эти условия поиска были в удобном для поиска измерении. При поиске предметов, превышающих 100 долларов США и более 4 звезд, сложно, когда вам нужно работать: «minyear = 2000, minprice = 100, stars = 4, category = new» в одном столбце для данного посещения – crosan

+1

Я имею в виду, что вы храните посещения в '(ID INT PK, ...)' и ключевые слова в 'VisitKeywords (VisitID INT PK, строка ключевого слова PK, строка значений)'. Это похоже на стандартное решение. Будет ли это работать? – usr

ответ

1

В зависимости от того, как вы хотите анализировать данные, существует несколько решений.

Но для объема данных, которые вы, вероятно, анализируете, я бы просто создал таблицу, которая использует PK этого факта для хранения каждого ключевого слова.

FACT_PAGEVIEW_ID bigint -- Surrogate key of fact table. Or natural key if you don't have a surrogate. 
KEYWORD varchar(255) -- or whatever max len the keywords are 
VALUE varchar(255) 

Гранулярность этой таблицы составляет 1 строку на идентификатор/комбинацию ключевых слов. Возможно, вам придется добавить значение, если вы разрешаете одно и то же ключевое слово несколько раз в querystring.

Это позволяет группировать ключевые слова по просмотру страниц или начинать с факта просмотра страницы, фильтровать его, а затем присоединяться к этому, чтобы идентифицировать ключевые слова.

Другим вариантом будет измерение ключевого слова и многомиллионная таблица с «группой ключевых слов», но поскольку любое количество комбинаций может быть использовано, это, вероятно, более быстрый путь и, вероятно, даст вам 90% путь там. Большинство вопросов, таких как «какая комбинация ключевых слов используется наиболее часто», и «какие ключевые слова больше всего используются в топ-10% пользовательской базы», ​​можно получить с помощью этой структуры.

+0

, поэтому вы, по сути, используете таблицу фактов посещения как своеобразное измерение для этой новой таблицы ключевых слов или обратное измерение, если хотите (сохраняя PK факта в измерении, а не наоборот). Я стараюсь как можно ближе придерживаться методологий Кимбалла, но я думаю, что это должно сработать. Если у кого-то еще есть какие-то другие идеи, я бы с удовольствием их услышал. Спасибо N West и usr! – crosan

+0

Да. Вы можете по-прежнему хотеть измерение ключевого слова, если количество ключевых слов невелико, и у них есть другие атрибуты, которые вы хотите сгруппировать. Просто замените KEYWORD на KEYWORD_ID, а «value» - ваша «текстовая» мера. –

Смежные вопросы