pouvons-nous avoir un attribut avec des valeurs multiples dans un design eav?

Question

Je fais une conception de base de données en utilisant EAV. Je suis confronté à un problème lorsque j'essaie de modéliser une entité avec un attribut ayant plusieurs valeurs?

Par exemple

Entité

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

Attribut

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

Valeur

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

Est-ce la bonne façon de gérer la liste des valeurs?

S'il vous plaît fournir un lien utile pour modéliser cela?

Deux autres questions

1) est de type comme une liste correcte? Je veux être sûr que lorsqu'un attribut a plusieurs valeurs, je donnerai le type comme Liste

2) Comment la conception de la base de données va changer quand l'attribut correspond à un objet? Par exemple, l'utilisateur a une adresse .. Comment vais-je gérer les paramètres composites?

Ce serait génial si vous pouvez me fournir une représentation sous forme de tableau rugueux ou diagramme

Merci

Shekhar

Answer 1

Oui! il est tout à fait possible d'avoir des attributs d'attributs multi-valeur dans EAV.
En fait, il est plus facile qu'avec le modèle relationnel traditionnel où il faudrait soit créer une colonne supplémentaire, soit stocker les multiples valeurs avec un format de tri délimité; ces deux approches souffrent d'une complexité supplémentaire lorsqu'elles interrogent la base de données pour une valeur donnée du champ sous-jacent (attribut).

La manière la plus simple d'avoir plusieurs valeurs est simplement d'avoir un enregistrement de valeur supplémentaire! (Comme indiqué dans la question)
En outre, la structure du magasin EAV peut être modifié pour tenir compte explicitement multi-valeurs, avec:

• un champ supplémentaire comme booléennes dans le attribut table pour indiquer si la Le champ peut ou ne peut pas être multi-valeur. (BTW, des propriétés similaires de l'attribut peuvent également être codifiées, par exemple si l'attribut est requis ou non.
• La table valeur peut avoir une colonne supplémentaire pour indiquer le numéro de séquence de la valeur (définie sur 0 ou 1 pour tous les attributs non à valeurs multiples, par ailleurs, un nombre entier incrémenté).

Comme dit, ces modifications du schéma physique de la mémoire de EAV ne sont pas nécessaires, mais ils peuvent être utilisés pour assurer que les données sont conformes à la (logique) schéma ainsi que d'afficher peut-être les plusieurs valeurs d'un multivaleur attributs dans un ordre particulier, etc.

Modifier: (détails sur la mise en œuvre à valeurs multiples et/ou composite (attributs « objet-like »))
Si vous êtes tout à fait positif que le multiple [ « sous » -] valeurs qui constituent un attribut (ou de manière similaire, les parties multiples qui constituent un attribut "type d'objet") sont complètement atomiques, ie ne seront jamais recherchées ou affichées (ou ...) individuellement, vous pouvez stocker un tel attribut 'value' sets ', comme un seul enregistrement dans la table de valeurs, en codant les multiples valeurs en une seule chaîne; Dans ce but, JSON ou XML-at-large vient à l'esprit et semble particulièrement intéressant pour les extensions/génériques, mais tout autre format que vous pouvez analyser et extraire de manière fiable fonctionnerait aussi (disons format délimité). Un moyen plus «naturel» (EAV) de stocker de telles «parties de valeur d'attribut» consiste à les stocker individuellement (dans plusieurs enregistrements de la table de valeurs, éventuellement avec un champ de séquence tel qu'indiqué précédemment). Cette approche permet de gérer les "sous-parties", dans certains contextes, comme si elles étaient des attributs. Dans les deux cas, vous devez modifier la table attributaire pour ajouter les propriétés et codes de types nécessaires pour décrire ces attributs multi-parties. De manière similaire à l'approche de stockage des données (dans la table de valeurs), vous pouvez soit rendre l'enregistrement d'attribut tel que toutes les informations pour un attribut [multi-parties] donné sont stockées dans un enregistrement d'attribut unique, ou, typiquement plus facile et plus flexible] vous pouvez créer un attribut par partie, plus un attribut pour les "lier ensemble" (par exemple avec une propriété qui contient une chaîne délimitée avec chacune des valeurs ID d'attribut des sous-parties.)

par exemple:
un attribut composite pour éléments de canalisation métalliques, pourrait être le diamètre, composé de deux parties:. une valeur numérique et un code d'unité (millimétrique, par rapport pouce)
Avec le premier appr oach:
- il y aurait un enregistrement dans la table d'attributs, avec un type indiquant qu'il s'agit d'une valeur multiple, et une propriété d'extension pour contenir la liste [ordonnée] des types des sous-parties individuelles.
- il y aurait un seul enregistrement dans la table de valeurs, contenant une valeur codée telle que par exemple "0,75 | Inch" (ou <diam>0.75</diam><unit>Inch</unit>). Avec la deuxième approche:
- il y aurait 3 enregistrements dans la table attributaire: un enregistrement ou un type numérique et nommé say "diamvalue", un enregistrement de type string, nommé Diamètre"; ce dernier enregistrement aurait en quelque sorte une référence à l'ID des deux autres attributs (une simple chaîne délimitée par des virgules vient à l'esprit) - il y aurait deux enregistrements dans la table de valeurs, un chacun des attributs diamvalue et unit (tels enregistrements aurait un champ additionnel, appelé "parent" contenant l'attribut AttributeID de l'attribut "Diameter" Eventuellement il pourrait aussi y avoir un enregistrement de valeur pour l'attribut "Diameter" [Personnellement, je trouve ceci redondant avec la propriété "parent"

Comme indiqué précédemment, le principal avantage de la seconde solution est que [le cas échéant] on peut interroger le catalogue pour un ensemble particulier d'éléments basé sur la valeur d'une partie d'attribut, par exemple chercher tous les tuyaux qui ont une unité métrique De telles requêtes sont résolues au niveau SQL, la première approche obligeant SQL à scanner toutes les valeurs d'attribut pour l'attribut "Diamètre" et analyser la valeur pour rechercher le code d'unité.

La valeur d'une image mille mots
Ce diagramme montre une disposition possible des échantillons de données pour la « deuxième approche ».

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 

Quelques remarques:
- Le SeqNr pour les valeurs ids 6 et 7 est égal à 1, pour les deux. Leur ordre est implicite à SubAttribIdList. Si l'attribut 6 a été créé avec un attribut à valeurs multiples ("Répétitions"), une entité peut avoir des couplets supplémentaires de deux valeurs, séquencés, par paire, 2, 3, etc.
- La séquence Nombre d'attributs non répétables est définie à 1, systématiquement, pourrait aussi bien être NULL cela ne s'applique pas.
- La propriété "Obligatoire" de l'attribut ne figure pas dans la question multi-valeur ou composite; Je viens de l'ajouter car il est couramment utilisé pour aider l'application (ou la couche d'accès à l'entité) à appliquer différentes règles d'intégrité.
- Certains des choix de conception de cette mise en page impliquent un maximum d'un niveau d'inclusion pour les attributs composites (un composite ne peut pas être inclus dans un composite) et empêchent un composite d'inclure un attribut à valeurs multiples. Ces limitations peuvent être évitées avec la structure appropriée (et avec un peu de complexité supplémentaire dans la couche d'accès), mais le schéma simplifié est généralement acceptable (les attributs qui nécessiteraient une telle structure fantaisie indiquent souvent une faille dans le schéma logique) .