Разработка базы данных системы опроса

Question

Я работаю над так называемой системой наблюдения за факторами риска (BRFSS), системой веб-запросов, в которой каждый год заполняются вопросники.

Мне было трудно найти подходящий дизайн базы данных. Вот в чем проблема: каждый вопросник содержит около 80 вопросов с демографической информацией, например. возраст, образование и т. д., а также вопросы опроса, например. курение, здоровье и т. д. Каждый год некоторые вопросы меняются, некоторые - нет. Источник данных - это файл Excel с 80 + столбцами. Система должна поддерживать такие запросы, как:

SELECT [question var], [demo var], count(*) 
FROM survey 
WHERE age in (...) AND educ in (...) [etc] 
GROUP BY <question var> 

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

Я попытался нормализовать ответы на три таблицы: вопросы, ответы и response_values, которые могут поддерживать варианты вопросов. Но тогда таблица ответов охватывает более 98 * 14268 = 1 398 264 строки в течение одного года! Это действительно огромно. Запрос медленный, как сумасшедший!

Как мне создать базу данных? Любая помощь приветствуется! Заранее спасибо!

пс. Я использую Python + Django + Sqlite.

Answer 1

Вы проверили DatabaseAnswers, чтобы увидеть, есть ли схема, которую вы могли бы использовать в качестве отправной точки?

Answer 2

Звучит как случай для схемы звезды.

Вы бы (огромный) таблицы фактов, как это:

question_id, survey_id, age_group_id, health_classifier_id, is_smoking ..., ANSWER_VALUE

и denormalised таблицы измерения:

age_group: group_name, min_age, max_age, age_group_id

1,4 миллиона строк не так уж звучат для такой системы.

Некоторых базы данные имеют специальные функции для поддержки запросов на таком роде схема:

В Oracle это будет:

• «Размеры» для поддержки aggragation allong Размеры
индекса
• растровых для фильтрации на атрибуты низкой мощности, такие как age_group_id и is_smoking
• bitmap joind index для фильтрации по атрибутам низкой мощности в объединенной таблице, то есть выбор из таблицы фактов, но фильтрация по min_age в t стол age_group.
• таблицы секционирования для обработки больших таблиц
• материализованные представления для предварительного вычисления агрегирования результатов

Есть также специализированные БД системы для такого рода данных, которые называются многомерной базы данных.

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

Answer 3

вам нужна как минимум 3 таблица:

1) Questions, который содержит текст для каждого вопроса, с автоинкрементом идентификатором ключом

например: (123, "Какой цвет волос?")

2) Questionaires, что отображение Q # 's на вопросы.

eg) вопрос № 10 на вопроснике № 3 на вопрос № 123.

3) Answers, которые связывают каждый respondant с их анкетирования и данными

например) ответ Боба на вопрос № 10 на Опросные # 3, «коричневый».

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

Я оставлю его как упражнение о том, как преобразовать его в sql.

Answer 4

Я тоже думал после моего сообщения о stackoverflow. Вот как я могу использовать денормализованную широкую таблицу (80 + столбцов) для поддержки изменения вопроса каждый год, а также совокупную кросс-таблицу. Пожалуйста, прокомментируйте. Благодаря

1. Создать новую таблицу для каждого года с вопросами, размещенных на колоннах например

   ID год доход возраст, пол, общеобразовательный ... курить Hiv пить ...

2. Создайте две таблицы: Вопрос и Query_Year, многие-ко-многим таблицы Question_Year. Затем мы можем заполнить список вопросов, которые доступны в течение указанного года, и наоборот.

3. Запросов в течение одного года легко. И запросы лет через год, мы можем использовать оператор UNION. Поскольку вопросы должны быть совместимыми в течение выбранных лет, СОЮЗ является законным. например

   SELECT * FROM ( SELECT, идентификатор,, COUNT () ОТ survey_2001 UNION ALL ВЫБРАТЬ идентификатор,, COUNT () ОТ survey_2003 UNION ALL ВЫБРАТЬ идентификатор,, COUNT (*) ОТ survey_2004 UNION ALL и т.д. и т.п. ) где ( AGE в (...) И EDUC в (...) и т.д. и т.п. ) GROUP BY,

Я полагаю, что UNION является реляционным оператором, который не должен уменьшать эффективность РСУБД. Так что это не больно, если я объединю множество таблиц по объему. Двигатель также может выполнять некоторые анализы запросов, чтобы повысить скорость.

Я думаю, что этот достаточно адекватен и достаточно прост. Пожалуйста, прокомментируйте. Благодаря!