Можно ли построить OLAP-куб, если детали модели заранее неизвестны?

Простите меня за неуместный вопрос - я не очень хорошо знаком с OLAP и кубами. Объясню свою ситуацию...

Я хотел бы создать базу данных для хранения результатов анкеты, где может быть несколько десятков вопросов на анкету. Собрав несколько тысяч заполненных анкет, я хотел бы проанализировать результаты, и это звучит как хороший кандидат на материал типа OLAP (о котором я очень мало знаю). Мне нужно иметь возможность выполнять запросы «всех респондентов мужского пола в возрасте 20–30 лет, у которых есть собака», т. е. комбинировать ответы на вопросы «сколько вам лет», «есть ли у вас собака» и т. д.

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

Вот суть моего вопроса: в то время как в этом месяце в моей анкете могут быть вопросы о поле, возрасте и владении собакой, анкета следующего месяца может включать вопрос о (скажем) цвете глаз. Это может (или не может) также оставить некоторые вопросы. Выполнимо ли это в мире OLAP, или вам нужно знать все «размеры» (если я использую правильный термин) заранее, когда вы проектируете свой куб?

Кроме того, если я провожу несколько разных опросов с разными, но перекрывающимися вопросами, могу ли я хранить их все в одном кубе и запускать запросы в разных опросах? В каждом опросе может быть несколько десятков вопросов, при этом пара десятков частично совпадают с другими опросами. Поддерживают ли OLAP-системы такие вещи? Я просто не знаю, насколько они жесткие и действительно ли они подходят для такого использования.

Любая помощь очень ценится.

PS. Прежде чем кто-то предложит это, я только что купил набор инструментов хранилища данных Кимбалла, но еще не имел возможности прочитать его. (Я подозреваю, что это может не дать прямого ответа на этот вопрос в любом случае).


person Gary McGill    schedule 16.06.2009    source источник


Ответы (3)


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

person Darren Gosbell    schedule 13.07.2009
comment
URL-адрес изменен: sqlbi.com/wp-content/ загрузки/ Страница 112+ - person TvdH; 11.02.2015
comment
Многомерная модель начинается на странице 24, страница 112 — это табличная модель. - person TvdH; 11.02.2015

Я начну с того, что я тоже новичок в OLAP, но я думаю, что знаю, чего вы хотите достичь.

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

Вам также может понадобиться другое измерение, связанное с вопросом, которое группирует их в анкеты, но это может быть просто значение в самом измерении вопроса, т. е. Question { QuestionnaireID = 1, QuestionNumber = 4, QuestionText = «У вас есть собака?» }.

Не уверен, что это поможет, но, надеюсь, даст вам некоторые идеи, если ничего другого.

person Lazarus    schedule 16.06.2009
comment
Спасибо за Ваш ответ. Хотя я не уверен на 100%, что следую. Вы говорите, что вопрос имеет одно измерение или много? (У меня могут быть десятки вопросов, и я где-то читал, что не стоит иметь в кубе более 12 измерений). Может быть, вы имеете в виду, что некоторые вопросы выражены в виде измерений (то есть тех, по которым мне нужно обрезать данные), но что тогда происходит с другими? Единое измерение для вопросов также звучит чревато, так как ответы на разные вопросы могут сильно различаться — у некоторых может быть числовой ответ, у некоторых будет множественный выбор, у некоторых даты... - person Gary McGill; 17.06.2009

Еще один новичок в OLAP...

1) У меня есть опыт создания OLAP-кубов только с Mondrian (Pentaho), что позволяет вам пересматривать схему куба, которая представляет собой просто XML-файл, и перестраивать их (или, говоря языком Pentaho, публиковать). Так что для этой платформы, во всяком случае, нет таких требований знать все свои размеры заранее

2) Я согласен с рекомендацией Лазуруса о создании измерения вопросов. Не обязательно, чтобы каждый из ваших «фактов» имел значение, присутствующее во всех измерениях, поэтому, если вы должны просмотреть измерение для «Вопроса n», то я полагаю, что это должно дать вам данные только для вопросников, где «Вопрос n" является релевантным размером.

person Kyril    schedule 16.06.2009
comment
Спасибо. Я не упомянул, что хотел бы, чтобы мои пользователи контролировали свои анкеты, поэтому в идеале они должны использовать (веб) пользовательский интерфейс для добавления вопросов — эта повторная публикация шага куба звучит немного неуклюже; хорошо знать, что мне нужно беспокоиться об этом. К сожалению, нет никакой гарантии, что вопрос будет иметь один и тот же номер вопроса во всех анкетах, но я думаю, все, что мне действительно нужно, — это какой-то идентификатор, который можно использовать для связывания связанных вопросов. Никто пока не говорит, что количество вопросов (каждый из которых может иметь десятки возможных ответов) является проблемой. Это обнадеживает. - person Gary McGill; 16.06.2009
comment
Если у вас есть опыт реляционного моделирования, попробуйте сначала создать реляционную модель ваших данных. После этого (и после прочтения книги Кимбалла) у вас будет гораздо лучшее представление о том, как преобразовать реляционный дизайн в многомерный. Для вопросов я бы создал одно измерение со всеми вопросами и ответами в форме [QuestionnaireID,QuestionnaireText,QuestionID,QuestionText,AnswerID,AnswerText]. Поместите ответы пользователей в таблицу фактов, и вы сможете разделить все ответы всех пользователей по анкете, вопросу и ответу. - person Sergey Volegov; 19.06.2009