はい！EAVに複数値の属性属性を設定することは非常に可能です。
実際、追加の列を作成するか、区切り形式の並べ替えで複数の値を格納する必要がある従来のリレーショナルモデルよりも簡単です。このようなアプローチはどちらも、基になるフィールド（属性）の特定の値をデータベースに照会するときに、さらに複雑になります。
複数の値を設定する最も簡単な方法は、追加の値レコードを作成することです。（質問に示されているように）
さらに、EAVストア構造は、複数の値に明示的に対応するように変更できます。
- フィールドが複数値であるかどうかを示す、属性テーブル内の追加のブール値のようなフィールド。（ところで、属性の同様のプロパティもコード化できます。たとえば、属性が必要かどうかなどです。
- 値テーブルは、値のシーケンス番号を示す追加の列を取得できます（すべての非複数値属性の場合は、0または1に設定されます。それ以外の場合は、増分整数に設定されます）。
前述のように、EAVストアの物理スキーマに対するこれらの変更は必要ありませんが、データが（論理）スキーマに準拠していることを確認したり、特定の複数値属性のいくつかの値を表示したりするために使用できます。注文など
編集:(複数値および/または複合（「オブジェクトのような」）属性の実装に関する詳細）属性
を構成する複数の["sub"-]値（または同様に、 「オブジェクトタイプ」属性）は完全にアトミックです。つまり、個別に検索または表示（または...）されることはありません。このような属性の値「セット」は、値テーブルに単一のレコードとして、エンコードすることで保存できます。複数の値を1つの文字列に。この目的のために、JSONまたはXML-at-largeが思い浮かび、非常に拡張可能/汎用的な場合は特に興味深いように見えますが、信頼できる方法で解析できる他の形式（区切り形式など）でも機能します。
このような「属性値の部分」を格納するためのより「自然な」方法（EAVに関して）は、それらを個別に格納することです（値テーブルの複数のレコードに、場合によっては前に示唆したシーケンスフィールドを使用して）。このアプローチにより、一部のコンテキストでは、「サブパーツ」を属性であるかのように処理できます。
どちらの場合も、属性テーブルを変更して、必要なプロパティとタイプコードを追加し、そのようなマルチパート属性を記述する必要があります。データを（値テーブルに）格納するアプローチと同様に、特定の[マルチパート]属性のすべての情報が単一の属性レコードに格納されるように属性レコードを作成するか、[これは通常、より簡単で柔軟性があります]パーツごとに1つの属性に加えて、「それらを結び付ける」ための1つの属性を作成できます（たとえば、サブパーツの各属性ID値で削除された文字列を含むプロパティを使用します。
例：
金属パイプアイテムの複合属性は、数値と単位コード（ミリメートル、対インチ）の2つの部分で構成される直径である可能性があります。
最初のアプローチでは、次のよう
になります。-属性テーブルに1つのレコードがあり、これが複数値であることを示すタイプと、個々のサブパーツのタイプの[順序付き]リストを含む拡張プロパティがあります。
-値テーブルには、「0.75 | Inch」（または）などのコード化された値を含む単一のレコードがあります<diam>0.75</diam><unit>Inch</unit>。
2番目のアプローチでは：
-属性テーブルには3つのレコードがあります。「diamvalue」という名前のレコードまたはタイプの数値、「unit」という名前のタイプstringのレコード、およびタイプの複合名「Diameter」のレコードです。この最後のレコードは、どういうわけか、他の2つの属性のIDへの参照を持っています（単純なコンマ区切りの文字列が思い浮かびます）-値テーブルには、diamvalueとunit属性のそれぞれに1つずつ、2つのレコードがあります（このようなレコードは「Diameter」属性のAttributeIDを含む「parent」と呼ばれる追加のフィールドがあります。オプションで、「Diameter」属性の値レコードも存在する可能性があります[個人的には、「parent」プロパティでこれが冗長であることがわかります。
前に示したように、2番目のソリューションの主な利点は、[適切な場合]属性パーツの値に基づいて特定のアイテムのセットをカタログに照会できることです。たとえば、メートル法の単位を持つすべてのパイプを検索できます。このようなクエリはSQLのレベルで解決されます。これにより、最初のアプローチでは、SQLはすべての属性値をスキャンして属性「Diameter」を探し、値を解析してユニットコードを検索する必要があります。
千の言葉に値する写真;-)
この図は、「2番目のアプローチ」のサンプルデータを使用した可能なレイアウトを示しています。
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
いくつかの注意事項：
-値ID 6および7のSeqNrは、両方とも1です。それらの順序は、SubAttribIdListに暗黙的に示されます。属性ID6が複数値（ "Repeats"）属性になっている場合、エンティティは2つの値の追加のカプレットを、ペアで、2、3などの順序で持つことができます。-繰り返し
不可能な属性のシーケンス番号は1に設定されます。 、体系的には、NULLになる可能性もありますが、これは当てはまりません。
-属性の「必須」プロパティは、複数値または複合の質問には含まれません。アプリケーション（またはエンティティアクセスレイヤー）がさまざまな整合性ルールを適用するのを支援するために一般的に使用されるため、これを追加しました。
-このレイアウトのいくつかの設計上の選択は、コンポジット属性に最大1レベルの包含を意味し（コンポジットをコンポジットに含めることはできません）、コンポジットに複数値属性を含めることを防ぎます。これらの制限は、適切な構造（およびアクセスレイヤーの複雑さの追加）によって回避できますが、通常はより単純なスキーマが受け入れられます（このような派手な構造を必要とする属性は、多くの場合、論理スキーマの欠陥を示します） 。