Модель данных съемки - как избежать EAV и чрезмерной денормализации?

Question

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

Мой вопрос: как я должен моделировать ответы на вопросы опроса в СУБД? Использование SQL Server является обязательным. Поэтому альтернативные системы хранения данных должны быть исключены из этого обсуждения. (Конечно, некоторые должны и будут оцениваться, но не здесь, пожалуйста.) Мне не нужно решение для всей модели данных, пока меня интересует только часть ответов.

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

Некоторые предположения о данных мне приходится иметь дело с:

1. Каждое обследование состоит из 1 до п опросных
2. Каждая анкета состоит из 100-2,000 вопросов (не обращайте внимания, что 2000 вопросов действительно звучать как много, чтобы ответить ...)
3. Вопросы могут быть разных типов: множественный выбор, свободный текст, число (например, возраст, доход, проценты, ...)
4. Каждое обследование включает 10-200 стран респонденты не являются респондентами. страны.)
5. В зависимости от типа вопросника на каждый вопросник отвечает 100-20 000 респондентов на страну.
6. Страна может адаптировать вопросники для опроса, то есть добавлять, удалять или редактировать вопросы
7. Данные для одной страны собраны в отдельной базе данных в этой стране. С онлайн-интеграции нет возможности для онлайн-интеграции.
8. Данные для всех стран должны быть интегрированы позже. Это означает, например, если страна удалила вопрос, эти данные должны каким-то образом быть получены из того, что они отправили для достижения единого дизайна во всех странах.
9. Мне нужно будет написать программное обеспечение для интеграции и очистки, которое понадобится для работы со сведениями каждой страны
   1. В конце данные должны быть экспортированы в плоские файлы, одну прямоугольную сетку для каждой страны и вопросник.

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

1. Эксперты домена, которые используются для работы с плоскими файлами (электронные таблицы стилей) для обработки и анализ данных голосования для денормализованнога структуры с нагрузками таблиц и столбцов, как я описал выше (1 таблицу для каждой страны и вопросника). Это звучит ужасно для меня, потому что я узнал, что следует избегать больших таблиц, будет очень сложно определить, какие столбцы находятся на самом деле в таблице при работе с ним, база данных будет забита сотнями таблиц (или мне даже нужно настроить несколько баз данных, каждый с похожим, но немного отличающимся дизайном) и т. д.
2. O-O-программисты голосуют за сильно «нормализованный» дизайн, что эффективно приведет к созданию центральной таблицы, содержащей ответы всех респондентов на все вопросы. Эта таблица должна либо содержать столбец типа sql_variant, либо несколько столбцов ответа с разными типами для хранения ответов разных типов (множественный выбор, свободный текст и т. Д.). Первая по существу была бы моделью EAV. Я склонен следовать за Джо Селко здесь, который сильно отговаривается от его использования (он называет его OTLT или «One True Lookup Table»). Последнее подразумевало бы, что каждая строка будет содержать нулевые ячейки для не применимых типов по дизайну.

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

Извините за то, что вы соскучились со всем этим текстом и благодарим вас за ввод!

Приветствия, Alex

PS: Я задал тот же самый вопрос здесь: http://www.eggheadcafe.com/community/aspnet/13/10242616/survey-data-model--how-to-avoid-eav-and-excessive-denormalization.aspx

Answer 1

Это звучит, как вы боролись с общей проблемой: как использовать молоток, чтобы закрепить винт.

Обе перечисленные вами альтернативы плохи, каждый по разным причинам. Но это потому, что вы пытаетесь внедрить свою конкретную модель данных в систему реляционных баз данных. Хорошим подходом было бы выходить за рамки реляционной базы данных по адресу some other database/storage systems, попробовать пару и найти наилучший вариант для вашего проекта.

---

Я попробовал модель EAV и отказался, потому что он был слишком сложным, и я боюсь, чтобы попробовать модель несколько таблиц с реляционной базой данных. Самое легкое решение, которое я нашел с реляционной базой данных: хранить каждый полный ответ как один CLOB, сериализованный в JSON или YAML (или что-то еще облегченное) в таблице responses.

create table responses (
    id uuid primary key, 
    questionnaire_id uuid references questionnaires.id, 
    data text 
) 

Answer 2

Вы считаете, что не изобретаете колесо? Уже созданы приложения для поиска с открытым исходным кодом. Даже если они не соответствуют вашим потребностям, загрузите несколько и проверьте их модели данных.

Answer 3

Если я использую SQL Server, экспресс будет в порядке, то я хотел бы сделать это:

• таблицы с перечнем вопросов, флаги для типа (бит), если требуется флаг (бит), правильный ответ, если существует, и т.д.
• таблицы со списком стран
• таблицы увязывание стран и вопросов (некоторые страны могут не получить некоторые вопросы
• таблицы для ответов остроумия ч колонна для вопрос (ы) и столбец XML для дополнительных вопросов , включая те, которые добавляют

Если вы не сведущие в измельчении XML затем использовать разреженные столбцы для всех дополнительных вопросов. Я не помню точно, как предел числа разреженных столбцов в таблице, но я считаю, что он превышает 30 000.SQL Server внутренне хранит разреженные столбцы как XML и отбрасывает его при выборе столбца и да, он может быть проиндексирован.

На приведенной ниже диаграмме показана диаграмма, созданная с помощью SQL Server. столбец AL_A4 будет содержать ответ на QL_Id = 4 и имеет разреженный тип. QL_Id в таблице QuestionList не помечен, чтобы вы знали, что столбец в AnswerList разрежен.

Поскольку страны будут добавлять вопросы, создайте QuestionListCustom, QuestiontoCountryCustom и AnswerListСообщите таблицы и добавьте информацию из пользовательских вопросов.

Уверен, что существуют другие способы создания хранилища, так я бы включил домашнюю работу, если это не домашнее задание, то вы, безусловно, работаете в ООН.

Answer 4

Ну Imgur вниз, так что я выложу позже рис.

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

Outbound

Он занимает 4 объектов для определения Обзор страны. Некоторый родительский опрос, страна и список вопросов. Ваши вопросы имеют внутренние отношения, поэтому, когда одна страна «редактирует» вопрос, вы можете отслеживать как вопрос, заданный страной, так и вопрос, из которого он пришел. Другая вещь, в которой вы нуждаетесь, - это объект/таблица Возможного ответа. У каждого вопроса может быть связанный список возможных ответов (множественный выбор или диапазоны и т. Д.). Эти 4 должны полностью определить сторону «OUTBOUND».

Inbound

сторона "въездного" всего 2 новые лица, Ответчик и ответ. Ответчик прост, просто демография этого человека, если вы их знаете, и здесь вы можете включить отношения в страну. Каждый респондент ответил на опрос в данной стране. (Лицо может быть 1: n с Ответчиком, если лицо путешествует или имеет двойное гражданство)

Ответ основной; либо это один из вариантов, перечисленных в списке возможных ответов или он предоставляется. Не увлекайтесь тем, что ответ может быть числом, датой и т. Д. Либо это FK, либо строка символов.

Отчетность

Отчет является объединением по всем из них ... Вы выбираете страну и обследование, получить список вопросов и ответов.

Ответ Сложность

Зависит от того, где вы хотите сделать ваши расчеты. Если вы использовали столбец Varchar2 (4000) для своих ответов, предоставленных пользователем, вы можете добавить атрибут к вопросу, чтобы описать тип данных ответа. Вопрос: Возраст? DT: Целое число (от 0 до 130). Тогда ваш уровень интеграции может выполнять проверку, а не базу данных, обеспечивающую ее. Или вы можете иметь 4 столбца, один для числа, даты, символа и CLOB. И ваш уровень интеграции определит используемый столбец. Когда вы сообщаете эти ответы, вы просто выделите все четыре столбца с Coalesce().

Является ли это EAV, потому что есть небольшая неясность с типом данных «Ответ»

Нет, это не так.

Модель AN EAV разбивает Entity на список атрибутов. так:

Entity  Attribute  Value 
    1   Fname   Stephanie 
    1   Lname   Page 
    1   Age   30 

потому что вы видите столбец Ответ схемы обследования держит оба слова и цифры, как столбец Value делает здесь вы думаете, что определяет EAV. Это не. Как если бы я добавил к этой модели 3 столбца типа данных, это не изменило бы его из EAV.

Я тааак ненавижу, когда

У меня были люди говорят мне, что запрос я тюнинг должен идти «как можно быстрее». Хорошо, дайте мне миллиард долларов и 30 лет. «Подождите, миллиард?» «Столько, сколько», «так же быстро, как», не являются требованиями. Вы можете проверить все, что захотите, в базе данных ... build the shedload of Before triggers, voila! Проверка в изобилии.

Каков тип данных возрастной колонны? Или столбцы Дата рождения? Зависит от источника данных. Некоторые старые записи могут иметь только месяц и год, или только год, или «вокруг» или «около» в течение некоторого года. У вас не может быть только столбец чисел и сделать «как можно большую проверку». и NUMBER (2) может быть ЛУЧШЕЕ подтверждение, чем просто NUMBER. Итак, теперь у вас будет NUMBER (1), NUMBER (2), NUMBER ..., чтобы иметь «столько же».

Где я думаю, что вы получаешь споткнулся

Думай об этом как концептуальной модели данных, а не физической. В этих условиях Опрос является субъектом. Is Вопрос объект или только атрибут опроса. Если вы построили Один стол PER, вы, очевидно, говорите, что вопрос - это всего лишь атрибут опроса и сохранение их по вертикали делает это EAV. То, что показывает эта модель, заключается в том, что Вопрос - это фактически другой объект. Существует взаимосвязь между Вопросами, например. «страна может редактировать вопросы». Был оригинальный вопрос и отредактирован. В каждом вопросе есть набор возможных ответов. И самое главное, что все они - вопросы. В EAV я вызываю fname, lname, bdate, age, major, зарплата и т. Д. ... все очень разрозненные вещи, просто атрибуты. В этом случае мы не включаем имя агентства, которое инициировало опрос, и дату его выдачи, а также дату и т. Д. В качестве вопросов.

Позвольте мне поставить это по-другому. Вы Fedex. Вы хотите сохранить временные метки для определенных событий. Каждый раз, когда пакет входит или покидает объект или транспортное средство. Время на сбор грузовика, время с грузовика и в первый объект, время выхода из этого объекта и на самолет и т. Д. Вы храните их по горизонтали? Откуда вы знаете количество прыжков заранее? Если вы храните их вертикально, это автоматически делает EAV? И если да, то почему.

Вы - компания погоды, получающая временные ограничения от станций по всей стране. Предположим, что датчики предназначены для отправки показаний при изменении температуры +/- полной степени. Если вы храните датчик_ID | timestamp | temp, это таблица для чтения, это EAV? Каждое чтение не является атрибутом датчика, они сами являются объектами, принадлежащими к коллекции/серии.

Единственное, что имеет вертикальное хранилище ответов, с EAV - это сложность в выполнении аналитических запросов.Если вам нужен список всех людей, которые ответили TRUE на вопрос 5 и 10, но FALSE до 6 и 11 было бы очень сложно, если сделать это вертикально. Возможно, именно поэтому вы видите это EAV. Если вы хотите это сделать, вам понадобится другое хранилище. Реляционное хранилище вопросов и ответов - не лучшая база данных отчетов. Вернемся к примеру Fedex. Не просто делать «транзитное» время, когда строки вертикальны.