Ну, imgur не работает, поэтому я опубликую фото позже.
Я думаю, что это вполне осуществимо в реляционной модели.Я построил CDM, чтобы показать, как я это сделаю.
Исходящий
Требуется 4 объекта для определения Обзора страны.Некоторые опросы родителей, страны и список вопросов.Ваши вопросы имеют внутреннюю связь, поэтому, когда одна страна «редактирует» вопрос, вы можете отслеживать как вопрос, заданный страной, так и вопрос, из которого она возникла.Другая вещь, в которой вы нуждаетесь, это сущность / таблица Возможный ответ.С каждым вопросом может быть связан список возможных ответов (множественный выбор или диапазоны и т. Д.).Эти 4 должны полностью определить «внешнюю» сторону этого.
Входящий
Сторона "INBOUND" - это всего лишь 2 новых объекта, Ответчик и ответ.Респондент прост, только демография этого человека, если вы его знаете, и здесь вы можете включить отношения обратно в страну.Каждый респондент ответил на опрос в данной стране.(Лицо может быть 1: n с ответчиком, если лицо путешествует или имеет двойное гражданство)
Ответ является основным;либо это один из вариантов, перечисленных в списке возможных ответов, либо он указан.Не увлекайтесь тем, что ответом может быть число, дата и т. Д.Либо это ФК или строка символов.
Отчетность
Отчет - это объединение всех этих ... Вы выберете страну и опрос, получите список вопросов и ответов.
Сложность ответа
Зависит от того, где вы хотите сделать свои расчеты.Если вы использовали столбец Varchar2 (4000) для предоставленных пользователем ответов, вы можете добавить атрибут к вопросу, чтобы описать тип данных ответа.Q: возраст?DT: целое число от (0 до 130).Тогда ваш интеграционный уровень может выполнить проверку вместо базы данных, которая его обеспечивает.Или вы можете иметь 4 столбца, один для числа, даты, символа и CLOB.И ваш уровень интеграции определит колонку для использования.Когда вы сообщите об этих ответах, вы просто выделите все четыре столбца с помощью Coalesce ().
Является ли это EAV, потому что есть некоторая двусмысленность для типа данных «Ответ»
Нет, это не так.
Модель EAV ломаетсяСущность в список атрибутов.например, так:
Entity Attribute Value
1 Fname Stephanie
1 Lname Page
1 Age 30
, потому что вы видите, что столбец Ответ схемы Survey содержит и слова, и цифры, как в столбце Значение, как вы думаете, здесь определяется EAV.Это не.Точно так же, как если бы я добавил 3 столбца данных в эту модель, он не изменил бы его из EAV.
Я так ненавижу, когда
У меня есть люди, которые говорятмне, что запрос, который я настраиваю, должен идти "как можно быстрее".Итак, дайте мне миллиард долларов и 30 лет."Подождите, миллиард что?"«Столько, сколько», «так быстро, как» не являются требованиями.Вы можете проверить все, что вы хотите в базе данных ... создать загрузку Перед триггерами, вуаля!Валидация в изобилии.
Какой тип столбца возраста?Или колонка рождения?Зависит от того, что ваш источник данных.Некоторые старые записи могут иметь только месяц и год, или только год, или около или около года.Вы не могли иметь только числовой столбец и делать «как можно больше проверок».и NUMBER (2) может быть ЛУЧШЕ, чем просто NUMBER.Так что теперь у вас будет NUMBER (1), NUMBER (2), NUMBER ... чтобы иметь «столько, сколько».
Где, я думаю, вас сбивают с толку
Думайте об этом как о Концептуальной Модели данных, а не Физической.В этих терминах Опрос является юридическим лицом.Является ли Вопрос сущностью или просто атрибутом опроса.Если вы построили Одна таблица на PER , вы явно говорите, что Вопрос - это просто атрибут опроса, и его вертикальное хранение делает это EAV.Эта модель показывает, что Вопрос - это на самом деле другая сущность.Между Вопросами существует связь, например, «страна может редактировать вопросы».Был оригинальный вопрос и отредактирован один.На каждый вопрос есть коллекция возможных ответов.И самое главное, что это все вопросы .В EAV я называю fname, lname, bdate, age, major, заработную плату и т. Д. - все очень разные вещи, просто атрибуты.В этом случае мы не включаем название агентства, которое подготовило опрос, и дату его проведения, а также дату, когда он должен быть возвращен, и т. Д. ... как вопросы.
Позвольте мне выразить это иначе,Ты ФедексВы хотите хранить метки времени для определенных событий.Каждый раз, когда посылка въезжает или покидает объект или транспортное средство.Время на погрузку грузовика, время на выходе из грузовика и на первый объект, время на выходе из этого объекта на самолет и т. Д. Вы храните их горизонтально?Как узнать заранее количество прыжков?Если вы храните их вертикально, это автоматически делает их EAV?И если да, то почему.
Вы - метеорологическая компания, получающая временные данные со станций по всей стране.Допустим, датчики предназначены для отправки показаний, когда температура изменяется на +/- на полный градус.Если вы храните sensor_ID | timestamp | temp - это таблица чтения, это EAV?Каждое чтение не является атрибутом датчика, они сами являются сущностями, которые принадлежат к коллекции / серии.
Единственное, что вертикальное хранение ответов имеет общее с EAV, - это сложность выполнения аналитических запросов.Если вы хотите получить список всех людей, которые ответили на ИСТИННО на вопросы 5 и 10, но ЛОЖЬ на 6 и 11, было бы очень трудно, если бы они были выполнены вертикально.Может быть, поэтому вы видите это EAV.Если вы хотите сделать это, вам нужно другое хранилище.Реляционное хранение вопросов и ответов - не самая лучшая база данных отчетов.Давайте вернемся к примеру с FedEx.Это не просто сделать «транзитный» отчет о времени, когда строки расположены вертикально.