Можем ли мы иметь один атрибут с несколькими значениями в проекте eav?

Question

Я делаю дизайн базы данных с использованием EAV. Я столкнулся с проблемой, когда пытаюсь моделировать объект с атрибутом, имеющим несколько значений?

Например

Entity

id   | name   | description 
--   | ----   | ------------ 
1   | configuration1 | configuration1 

Атрибут

id   | entityId | name | type 
--   | -------- | ---- | ---- 
1   | 1   | att1 | string 
2   | 1   | att2 | int 
3   | 1   | att3 | List<String> (How will i model this?) 

Значение

id  | attributeId | value 
--  | ----------- | ----- 
1   | 1    | a  
2   | 2    | 1 
3   | 3    | b 
4   | 3    | c  
5   | 3    | d 

Это правильный способ обработки списка значений?

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

еще два вопроса

1) Является ли тип в списке правильный? Я хочу быть уверенным, что когда один атрибут имеет несколько значений, я дам тип как Список

2) Как изменится дизайн базы данных, когда атрибут соответствует объекту? Например, у пользователя есть адрес. Как обрабатывать составные параметры?

Было бы замечательно, если вы можете предоставить мне примерное представление табличный или диаграммы

Благодаря

Шекхар

Answer 1

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

Самый простой способ иметь несколько значений - просто иметь дополнительную запись значений! (Как показано в вопросе)
Кроме того, EAV магазин структура может быть изменена явным образом приспособить мульти-значение, с:

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

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

Редактировать: (подробнее о реализации многозначных и/или композита («объект типа») атрибуты)
Если вы абсолютно уверены, что многократный [ «суб» -] значение, которые представляют собой атрибут (или аналогичным образом множественные части, которые составляют атрибут «тип объекта»), являются полностью атомными, т.е. никогда не будут искать или отображать (или ...) индивидуально, вы можете хранить такие атрибуты «значения» наборы «как единую запись» в таблице значений, путем кодирования нескольких значений в одну строку; С этой целью JSON или XML-at-large приходят на ум и кажутся особенно интересными для очень расширяемого/универсального, но любой другой формат, который вы можете анализировать и выходить в надежном режиме, также будет работать (например, в формате с разделителями).

Более «естественный» способ (EAV-мудрый) для хранения таких «частей значения атрибута» заключается в их сохранении отдельно (в нескольких записях таблицы значений, возможно, с полем последовательности, как было намечено ранее). Этот подход позволяет обрабатывать «подчасти» в некоторых контекстах, как если бы они были атрибутами.

В обоих случаях вам необходимо изменить таблицу атрибутов, чтобы добавить необходимые коды свойств и типов, чтобы описать такие атрибуты с несколькими частями. Подобно подходу хранения данных (в таблице значений), вы можете либо сделать запись атрибута такой, чтобы вся информация для данного атрибута [многочастная] хранилась в одной записи атрибута, или [и это как правило, проще и гибче], вы можете создать один атрибут для каждой части, плюс один атрибут, чтобы «связать их вместе» (например, с свойством, которое содержит строку, разделенную с каждым из значений идентификатора атрибутов подчастей.

Например:
Составной атрибут для металлических элементов трубы, может быть диаметр, выполненный из двух частей:. числовое значение и кода единиц (миллиметр, против дюйма)
с первым провером oach:
- в таблице атрибутов будет одна запись с типом, указывающим, что это многозначное значение, и свойство расширения, которое содержит [упорядоченный] список типов отдельных подчастей.
- в таблице значений будет содержаться одна запись, содержащая закодированное значение, например, «0.75 | дюймы» (или <diam>0.75</diam><unit>Inch</unit>).
Со вторым подходом:
- в таблице атрибутов должно быть 3 записи: запись или тип числовой и названная, обозначающая «diamvalue», запись строки типа с названием «единица» и запись составного имени типа « Диаметр"; эта последняя запись каким-то образом будет ссылаться на идентификатор двух других атрибутов (на ум приходит простая строка с разделителями-запятыми) - в таблице значений будет две записи, каждая из которых имеет атрибут diamvalue и unit (такие записи будет иметь дополнительное поле, называемое «родительским», содержащим атрибут AttributeID атрибута «Diameter». Возможно, также может быть запись значения для атрибута «Diameter» [я лично считаю это избыточным с «родительским» свойством.

Как указывалось ранее, основным преимуществом второго решения является то, что [при необходимости] можно запросить каталог для определенного набора элементов на основе значения части атрибута, например, для поиска всех труб, которые имеют метрическую единицу . Такие запросы разрешаются на уровне SQL, поэтому при первом подходе SQL придется сканировать все значения атрибута для атрибута «Диаметр» и проанализировать значение для поиска кода единицы.

стоит картину в тысячу слов ;-)
Эта диаграмма показывает возможную компоновку с образцами данных для «второго подхода».

Entity 
    id | name   | description 
    -- | ----   | ------------ 
    1 | configuration1 | configuration1 

Attribute 
    id | name  | type  | Required | Repeats | SubAttribIdList 
    -- | ----  | ----  | -------- | ------- | --------------- 
    1 | att1  | string | N  | N  | null (only applicable to composite types) 
    2 | att2  | int  | Y  | N  | null 
    3 | att3  | string | Y  | Y  | null 
    4 | DiamValue | numeric | Y  | N  | null 
    5 | Unit  | string | Y  | N  | null 
    6 | Diameter | composite| N  | N  | 4,5 

Value 
    id | entityId| attributeId | ParentAttribId |SeqNr | value  
    -- | --------| ----------- | -------------- |----- | ----- 
    1 | 1  | 1   | null   | 1 | a  
    2 | 1  | 2   | null   | 1 | 1 
    3 | 1  | 3   | null   | 1 | b (this value and next show show a repeating attribute) 
    4 | 1  | 3   | null   | 2 | c  
    5 | 1  | 3   | null   | 3 | d 
    6 | 1  | 4   | 6    | 1 | 0.75 (this value and next one shows a composite attribute 
    7 | 1  | 5   | 6    | 1 | Inches 

Несколько замечаний:
- The SeqNr для значений Идентификаторы 6 и 7 является 1, для обоих. Их порядок неявляется в SubAttribIdList. Если атрибут id 6 был присвоен атрибуту multi-value («Repeats»), у объекта могут быть дополнительные двустилетные два значения, упорядоченные в паре, 2, 3 и т. Д.
- Номер последовательности для не повторяющихся атрибутов установлен 1, систематически, также может быть NULL, это не применяется.
- свойство «Обязательный» атрибута не фигурирует в многозначном или сложном вопросе; Я просто добавил его, поскольку он обычно используется, чтобы помочь приложению (или уровню доступа к сущности) применять различные правила целостности.
- Некоторые из вариантов дизайна в этом макете подразумевают максимум 1 уровень включения для составных атрибутов (композит не может быть включен в составный), а также препятствовать тому, чтобы композит включал атрибут multi-value. Эти ограничения можно избежать с помощью надлежащей структуры (и с некоторой сложностью на уровне доступа), но более простая схема обычно приемлема (атрибуты, которые требуют такой причудливой структуры, часто указывают на недостаток логической схемы) ,