نموذج الكيان والسمة والقيمة

نموذج الكيان والسمة والقيمة ( EAV ) هو نموذج بيانات مُحسَّن لتخزين قيم الخصائص أو البيانات المتفرقة أو المخصصة بكفاءة من حيث المساحة ، والمخصص للمواقف التي تكون فيها أنماط الاستخدام وقت التشغيل تعسفية أو عرضة لاختلاف المستخدم أو غير متوقعة باستخدام تصميم ثابت. تستهدف حالة الاستخدام التطبيقات التي تقدم نظامًا كبيرًا أو غنيًا بأنواع الخصائص المحددة، والتي تكون بدورها مناسبة لمجموعة واسعة من الكيانات، ولكن حيث يتم عادةً إنشاء مجموعة صغيرة محددة فقط من هذه الأنواع (أو الاحتفاظ بها) لكيان معين. لذلك، يرتبط هذا النوع من نموذج البيانات بالمفهوم الرياضي للمصفوفة المتفرقة . يُعرف نموذج EAV أيضًا باسم نموذج الكائن والسمة والقيمة ، ونموذج قاعدة البيانات الرأسية ، والمخطط المفتوح .

هذا التمثيل للبيانات يشبه الطرق الموفرة للمساحة لتخزين مصفوفة متفرقة ، حيث يتم تخزين القيم غير الفارغة فقط. في نموذج بيانات EAV، كل زوج من السمات والقيم هو حقيقة تصف كيانًا، ويخزن صف في جدول EAV حقيقة واحدة. غالبًا ما يتم وصف جداول EAV بأنها "طويلة ونحيفة": يشير "طويل" إلى عدد الصفوف، و"نحيف" إلى الأعمدة القليلة.

يتم تسجيل البيانات على شكل ثلاثة أعمدة:

• الكيان : العنصر الذي يتم وصفه .
• السمة أو المعلمة : يتم تنفيذها عادةً كمفتاح خارجي في جدول تعريفات السمات. قد يحتوي جدول تعريفات السمات على الأعمدة التالية: معرف السمة، واسم السمة، والوصف، ونوع البيانات ، والأعمدة التي تساعد في التحقق من صحة الإدخال، على سبيل المثال ، الحد الأقصى لطول السلسلة والتعبير العادي، ومجموعة القيم المسموح بها، وما إلى ذلك.
• قيمة السمة .

ولنتأمل هنا كيف يمكن للمرء أن يحاول تمثيل سجل سريري عام في قاعدة بيانات علائقية. ومن الواضح أن إنشاء جدول (أو مجموعة من الجداول) يحتوي على آلاف الأعمدة ليس بالأمر الممكن، لأن الغالبية العظمى من الأعمدة ستكون فارغة . ولتعقيد الأمور، ففي السجل الطبي الطولي الذي يتتبع المريض بمرور الوقت، قد تكون هناك قيم متعددة لنفس المعلمة: فطول ووزن الطفل، على سبيل المثال، يتغيران مع نمو الطفل. وأخيراً، يستمر عالم النتائج السريرية في النمو: على سبيل المثال، تظهر الأمراض ويتم ابتكار اختبارات معملية جديدة؛ وهذا يتطلب إضافة مستمرة للأعمدة، ومراجعة مستمرة لواجهة المستخدم. ويُستخدم مصطلح "تقلب السمات" في بعض الأحيان لوصف المشاكل أو المواقف التي تنشأ عندما تحتاج قائمة السمات المتاحة أو تعريفاتها إلى التطور بمرور الوقت.

يوضح الشكل التالي مجموعة مختارة من صفوف جدول EAV للنتائج السريرية من زيارة للطبيب بسبب الحمى في صباح يوم 1998-05-01. الإدخالات المعروضة بين قوسين هي مراجع لإدخالات في جداول أخرى، تظهر هنا كنص وليس كقيم مفتاح أجنبي مشفرة لسهولة الفهم. في هذا المثال، القيم كلها قيم حرفية، ولكنها يمكن أن تكون أيضًا قوائم قيم محددة مسبقًا. تكون الأخيرة مفيدة بشكل خاص عندما يكون من المعروف أن القيم المحتملة محدودة (أي قابلة للعد ).

• الكيان . بالنسبة للنتائج السريرية، يكون الكيان هو حدث المريض : مفتاح خارجي في جدول يحتوي على الأقل على معرف المريض وعلامة زمنية واحدة أو أكثر (على سبيل المثال، تاريخ/وقت بداية ونهاية الفحص) تسجل وقت حدوث الحدث الموصوف.
• السمة أو المعلمة : مفتاح خارجي في جدول تعريفات السمات (في هذا المثال، تعريفات النتائج السريرية). على أقل تقدير، سيحتوي جدول تعريفات السمات على الأعمدة التالية: معرف السمة، واسم السمة، والوصف، ونوع البيانات ، ووحدات القياس ، والأعمدة التي تساعد في التحقق من صحة الإدخال، على سبيل المثال، الحد الأقصى لطول السلسلة والتعبير العادي، والحد الأقصى والحد الأدنى للقيم المسموح بها، ومجموعة القيم المسموح بها، وما إلى ذلك.
• قيمة السمة . وهذا يعتمد على نوع البيانات، وسنناقش كيفية تخزين القيم بإيجاز.

يوضح المثال أدناه نتائج الأعراض التي قد تظهر لدى مريض مصاب بالالتهاب الرئوي .

كيان	يصف	قيمة
⟨المريض XYZ، 1998-05-01 09:30⟩	⟨درجة الحرارة بالدرجات المئوية⟩	"38.9"
⟨المريض XYZ، 1998-05-01 09:30⟩	⟨وجود السعال⟩	"حقيقي"
⟨المريض XYZ، 1998-05-01 09:30⟩	⟨نوع السعال⟩	"مع البلغم، مصفر، خطوط من الدم"
⟨المريض XYZ، 1998-05-01 09:30⟩	⟨معدل ضربات القلب بالنبضات في الدقيقة⟩	"98"

البيانات الخاصة بـ EAV الموضحة أعلاه قابلة للمقارنة بمحتويات إيصال مبيعات السوبر ماركت (والتي ستنعكس في جدول عناصر سطر المبيعات في قاعدة البيانات). يسرد الإيصال فقط تفاصيل العناصر التي تم شراؤها بالفعل، بدلاً من سرد كل منتج في المتجر ربما اشتراه العميل ولكنه لم يفعل. ومثل النتائج السريرية لمريض معين، فإن إيصال المبيعات هو تمثيل مضغوط لبيانات متفرقة بطبيعتها.

• "الكيان" هو معرف البيع/المعاملة — وهو مفتاح خارجي في جدول معاملات البيع. ويستخدم هذا لوضع علامة على كل بند من البنود داخليًا، على الرغم من أن المعلومات المتعلقة بالبيع تظهر في الجزء العلوي (موقع المتجر وتاريخ/وقت البيع) وفي الجزء السفلي (القيمة الإجمالية للبيع).
• إن "السمة" هي مفتاح خارجي لجدول المنتجات، حيث يمكن للمرء أن يبحث عن الوصف، وسعر الوحدة، والخصومات والعروض الترويجية، وما إلى ذلك. (المنتجات متقلبة مثل النتائج السريرية، وربما أكثر من ذلك: يتم طرح منتجات جديدة كل شهر، في حين يتم سحب منتجات أخرى من السوق إذا كان قبول المستهلك ضعيفًا. لن يقوم أي مصمم قاعدة بيانات كفء بترميز منتجات فردية مثل دوريتوس أو دايت كوك كأعمدة في جدول).
• القيم هي الكمية المشتراة وسعر البند الإجمالي.

نمذجة الصفوف ، ^{[ بحاجة لتوضيح ]} حيث يتم تسجيل الحقائق حول شيء ما (في هذه الحالة، معاملة بيع) على هيئة صفوف متعددة بدلاً من أعمدة متعددة ، هي تقنية نمذجة بيانات قياسية. الاختلافات بين نمذجة الصفوف وقيمة التكلفة الإجمالية (والتي يمكن اعتبارها تعميمًا لنمذجة الصفوف) هي:

• إن الجدول الذي يتم تصميمه على شكل صف متجانس في الحقائق التي يصفها: فجدول البنود السطرية يصف المنتجات المباعة فقط. وعلى النقيض من ذلك، يحتوي جدول القيمة الإجمالية للمبيعات على أي نوع من الحقائق تقريبًا.
• إن نوع البيانات لعمود/أعمدة القيمة في جدول نموذجي للصف يتم تحديده مسبقًا من خلال طبيعة الحقائق التي يسجلها. وعلى النقيض من ذلك، في جدول EAV، يعتمد نوع البيانات المفاهيمي لقيمة في صف معين على السمة الموجودة في ذلك الصف. ويترتب على ذلك أنه في أنظمة الإنتاج، فإن السماح بإدخال البيانات مباشرة في جدول EAV سيكون بمثابة وصفة لكارثة، لأن محرك قاعدة البيانات نفسه لن يكون قادرًا على إجراء التحقق من صحة الإدخال بشكل قوي. سنرى لاحقًا كيف يمكن بناء أطر عامة تؤدي معظم مهام التحقق من صحة الإدخال، دون ترميز لا نهاية له على أساس سمة تلو الأخرى.

في مستودع البيانات السريرية، يجد نمذجة الصفوف أيضًا العديد من الاستخدامات؛ عادةً ما يتم نمذجة المخطط الفرعي للاختبار المعملي بهذه الطريقة، لأن نتائج الاختبار المعملي عادةً ما تكون رقمية، أو يمكن ترميزها رقميًا.

يتم سرد الحالات التي قد تحتاج فيها إلى تجاوز نمذجة الصفوف القياسية إلى EAV أدناه:

• يختلف نوع البيانات الخاصة بالسمات الفردية (كما هو الحال مع النتائج السريرية).
• إن فئات البيانات عديدة، متنامية أو متقلبة، ولكن عدد الحالات (السجلات/الصفوف) داخل كل فئة صغير جدًا. هنا، مع النمذجة التقليدية، قد يحتوي مخطط الكيان-العلاقة لقاعدة البيانات على مئات الجداول: يتم التأكيد بصريًا على الجداول التي تحتوي على آلاف/ ملايين الصفوف/الحالات بنفس الدرجة مثل تلك التي تحتوي على عدد قليل جدًا من الصفوف. هذه الأخيرة مرشحة للتحويل إلى تمثيل EAV. ينشأ هذا الموقف في بيئات النمذجة الأنطولوجية ، حيث يجب غالبًا إنشاء الفئات ("الفئات") أثناء التنقل، وغالبًا ما يتم التخلص من بعض الفئات في دورات لاحقة من النمذجة الأولية.

تحتوي بعض الفئات ("الهجينة") على بعض السمات غير المتفرقة (موجودة في جميع الحالات أو معظمها)، في حين أن السمات الأخرى متغيرة للغاية ومتفرقة. والأخيرة مناسبة لنمذجة EAV. على سبيل المثال، تعتمد أوصاف المنتجات التي تصنعها شركة تكتل على فئة المنتج، على سبيل المثال، السمات اللازمة لوصف علامة تجارية لمصباح كهربائي مختلفة تمامًا عن تلك المطلوبة لوصف جهاز تصوير طبي، لكن كلاهما لهما سمات مشتركة مثل وحدة التعبئة والتغليف وتكلفة كل عنصر.

في البيانات السريرية، يكون الكيان عادةً حدثًا سريريًا، كما هو موضح أعلاه. وفي الإعدادات ذات الأغراض العامة، يكون الكيان مفتاحًا خارجيًا في جدول "كائنات" يسجل معلومات مشتركة حول كل "كائن" (شيء) في قاعدة البيانات - على الأقل، اسم مفضل ووصف موجز، بالإضافة إلى فئة/فئة الكيان الذي ينتمي إليه. يتم تعيين معرف كائن تم إنشاؤه بواسطة الآلة لكل سجل (كائن) في هذا الجدول.

كان توم سليزاك وزملاؤه في مختبرات لورانس ليفرمور رائدين في استخدام أسلوب "جدول الكائنات" في قاعدة بيانات الكروموسوم 19، وهو الآن أسلوب قياسي في أغلب قواعد بيانات المعلوماتية الحيوية الضخمة. ولا يفرض استخدام جدول الكائنات الاستخدام المتزامن لتصميم EAV: إذ يمكن استخدام الجداول التقليدية لتخزين التفاصيل الخاصة بكل فئة من الكائنات.

الفائدة الرئيسية لجدول الكائنات المركزي هي أنه من خلال وجود جدول داعم للمرادفات والكلمات الرئيسية للكائنات، يمكن للمرء توفير آلية بحث قياسية تشبه جوجل عبر النظام بأكمله حيث يمكن للمستخدم العثور على معلومات حول أي كائن ذي اهتمام دون الحاجة إلى تحديد الفئة التي ينتمي إليها أولاً. (هذا مهم في أنظمة العلوم البيولوجية حيث يمكن لكلمة رئيسية مثل "أستيل كولين" أن تشير إما إلى الجزيء نفسه، وهو ناقل عصبي، أو المستقبل البيولوجي الذي يرتبط به.)

في جدول EAV نفسه، يعد هذا مجرد معرف سمة، وهو مفتاح خارجي لجدول تعريفات السمات، كما هو مذكور أعلاه. ومع ذلك، توجد عادةً جداول بيانات وصفية متعددة تحتوي على معلومات متعلقة بالسمات، وسيتم مناقشة هذه الجداول بإيجاز.

إن إجبار جميع القيم على تحويلها إلى سلاسل، كما في مثال بيانات EAV أعلاه، يؤدي إلى بنية بسيطة ولكنها غير قابلة للتطوير: يلزم إجراء تحويلات بين أنواع البيانات الثابتة إذا أراد المرء القيام بأي شيء بالقيم، كما أن الفهرس الموجود في عمود القيمة في جدول EAV غير مفيد بشكل أساسي. كما أنه ليس من الملائم تخزين البيانات الثنائية الكبيرة، مثل الصور، في شكل مشفر بتنسيق Base64 في نفس الجدول مثل الأعداد الصحيحة الصغيرة أو السلاسل. لذلك، تستخدم الأنظمة الأكبر جداول EAV منفصلة لكل نوع بيانات (بما في ذلك الكائنات الثنائية الكبيرة ، "BLOBS")، مع تحديد البيانات الوصفية لسمة معينة لجدول EAV الذي سيتم تخزين بياناته فيه. هذا النهج فعال للغاية في الواقع لأن الكمية المتواضعة من بيانات التعريف الخاصة بالسمات لفئة أو نموذج معين يختاره المستخدم للعمل معه يمكن تخزينها مؤقتًا في الذاكرة بسهولة. ومع ذلك، فإنه يتطلب نقل البيانات من جدول إلى آخر إذا تم تغيير نوع بيانات السمة.

نشأت EAV، كوسيلة عامة الغرض لتمثيل المعرفة ، بمفهوم " قوائم الارتباط " ( أزواج السمة والقيمة ). تُستخدم هذه الأزواج بشكل شائع اليوم، وقد تم تقديمها لأول مرة في لغة LISP . ^[1] تُستخدم أزواج السمة والقيمة على نطاق واسع في تطبيقات متنوعة، مثل ملفات التكوين (باستخدام بناء جملة بسيط مثل السمة = القيمة ). ومن الأمثلة على استخدام EAV خارج قاعدة البيانات في UIMA (هندسة إدارة المعلومات غير المنظمة)، وهو معيار تديره الآن مؤسسة Apache Foundation ويُستخدم في مجالات مثل معالجة اللغة الطبيعية . عادةً ما تقوم البرامج التي تحلل النص بوضع علامات ("تعليقات توضيحية") على مقطع: المثال المقدم في البرنامج التعليمي UIMA هو برنامج يقوم بالتعرف على الكيان المسمى (NER) على مستند، مع التعليق على مقطع النص "الرئيس بوش" بثلاثية التعليق التوضيحي والسمة والقيمة (الشخص، الاسم الكامل، "جورج دبليو بوش") . ^[2] يمكن تخزين مثل هذه التعليقات التوضيحية في جدول قاعدة بيانات.

في حين أن EAV ليس له اتصال مباشر بأزواج AV، يبدو أن Stead وHammond هما أول من تصور استخدامهما للتخزين الدائم للبيانات المعقدة بشكل تعسفي. ^[3] كانت أول أنظمة السجلات الطبية التي تستخدم EAV هي السجل الطبي الإلكتروني Regenstrief (الجهد الذي قاده كليمنت ماكدونالد)، ^[4] ونظام TMR (السجل الطبي) الخاص بويليام ستيد وإد هاموند ومستودع البيانات السريرية HELP (CDR) الذي أنشأته مجموعة هومر وارنر في مستشفى LDS، سولت ليك سيتي، يوتا. ^{[5] [6]} (استخدم نظام Regenstrief في الواقع تصميم Patient-Attribute-Timestamp-Value: استخدام الطابع الزمني لاسترجاع القيم لمريض/سمة معينة بترتيب زمني.) تم إصدار جميع هذه الأنظمة، التي تم تطويرها في السبعينيات، قبل توفر الأنظمة التجارية القائمة على نموذج قاعدة البيانات العلائقية لـ EF Codd ، على الرغم من نقل HELP بعد ذلك بكثير إلى بنية علائقية وتسويقه بواسطة شركة 3M. (لاحظ أنه على الرغم من نشر ورقة Codd الرائدة في عام 1970، إلا أن نبرتها الرياضية الثقيلة كان لها التأثير المؤسف المتمثل في تقليل إمكانية الوصول إليها بين الأنواع غير المتخصصة في علوم الكمبيوتر وبالتالي تأخير قبول النموذج في دوائر تكنولوجيا المعلومات وبائعي البرامج. لا يمكن المبالغة في قيمة المساهمة اللاحقة لكريستوفر جيه ديت ، زميل كود في IBM، في ترجمة هذه الأفكار إلى لغة يمكن الوصول إليها، مصحوبة بأمثلة بسيطة توضح قوتها.)

كانت مجموعة في المركز الطبي كولومبيا-بريسبتيريان أول من استخدم محرك قاعدة بيانات علائقية كأساس لنظام EAV. ^[7]

كان نظام إدارة بيانات الدراسات السريرية مفتوح المصدر TrialDB الخاص بـ Nadkarni وآخرين هو أول من استخدم جداول EAV متعددة، جدول واحد لكل نوع من أنواع بيانات DBMS . ^[8]

تم تصميم إطار عمل EAV/CR، والذي صممه في الأساس لويس مارينكو وبراكاش نادكارني، على أساس مبادئ توجيه الكائنات على EAV؛ ^[9] وتم بناؤه على نهج جدول الكائنات الخاص بتوم سليزاك (الموصوف سابقًا في قسم "الكيان"). تم بناء SenseLab، وهي قاعدة بيانات علم الأعصاب المتاحة للعامة، باستخدام إطار عمل EAV/CR.

يشير مصطلح "قاعدة بيانات EAV" إلى تصميم قاعدة بيانات حيث يتم تصميم نسبة كبيرة من البيانات على أنها EAV. ومع ذلك، حتى في قاعدة البيانات الموصوفة بأنها "تعتمد على EAV"، فإن بعض الجداول في النظام عبارة عن جداول علائقية تقليدية.

كما ذكرنا أعلاه، فإن نمذجة EAV منطقية لفئات البيانات، مثل النتائج السريرية، حيث تكون السمات عديدة ومتفرقة. عندما لا تتوفر هذه الشروط، فإن النمذجة العلائقية القياسية (أي عمود واحد لكل سمة) هي الأفضل؛ لا يعني استخدام EAV التخلي عن الفطرة السليمة أو مبادئ التصميم العلائقي الجيد. في أنظمة السجلات السريرية، يتم عادةً نمذجة المخططات الفرعية التي تتعامل مع التركيبة السكانية للمريض والفواتير بشكل تقليدي. (في حين أن معظم مخططات قواعد بيانات البائعين مملوكة، فإن VistA ، النظام المستخدم في جميع أنحاء نظام وزارة شؤون المحاربين القدامى في الولايات المتحدة (VA) الطبي، والمعروف باسم إدارة صحة المحاربين القدامى (VHA)، ^[10] مفتوح المصدر ومخططه قابل للتفتيش بسهولة، على الرغم من أنه يستخدم محرك قاعدة بيانات MUMPS بدلاً من قاعدة بيانات علائقية.)

كما تمت مناقشته بإيجاز، فإن قاعدة بيانات EAV غير قابلة للصيانة بشكل أساسي بدون العديد من الجداول الداعمة التي تحتوي على بيانات وصفية داعمة . جداول البيانات الوصفية، والتي يفوق عددها عادةً جداول EAV بعامل لا يقل عن ثلاثة أو أكثر، هي عادةً جداول علائقية قياسية. ^{[8] [9]} ومن الأمثلة على جدول البيانات الوصفية جدول تعريفات السمات المذكور أعلاه.

في تصميم EAV البسيط، تكون قيم السمة عبارة عن أنواع بيانات بسيطة أو بدائية فيما يتعلق بمحرك قاعدة البيانات. ومع ذلك، في أنظمة EAV المستخدمة لتمثيل بيانات شديدة التنوع، من الممكن أن يكون لكائن معين (مثيل فئة) بنية فرعية: أي أن بعض سماته قد تمثل أنواعًا أخرى من الكائنات، والتي قد يكون لها بدورها بنية فرعية، بمستوى تعسفي من التعقيد. على سبيل المثال، تحتوي السيارة على محرك وناقل حركة وما إلى ذلك، ويحتوي المحرك على مكونات مثل الأسطوانات. (يتم تعريف البنية الفرعية المسموح بها لفئة معينة داخل بيانات تعريف سمة النظام، كما تمت مناقشته لاحقًا. وبالتالي، على سبيل المثال، يمكن تطبيق السمة "ذاكرة الوصول العشوائي" على فئة "الكمبيوتر" ولكن ليس على فئة "المحرك").

لتمثيل البنية الفرعية، يتم دمج جدول EAV خاص حيث يحتوي عمود القيمة على مراجع إلى كيانات أخرى في النظام (أي قيم المفتاح الخارجي في جدول الكائنات). للحصول على جميع المعلومات حول كائن معين، يتطلب الأمر مسحًا متكررًا للبيانات الوصفية، متبوعًا بمسح متكرر للبيانات التي تتوقف عندما تكون كل سمة مسترجعة بسيطة (ذرية). المسح المتكرر ضروري سواء تم تمثيل تفاصيل فئة فردية في شكل تقليدي أو EAV؛ يتم إجراء هذا المسح في أنظمة الكائنات العلائقية القياسية، على سبيل المثال. في الممارسة العملية، يميل عدد مستويات التكرار إلى أن يكون متواضعًا نسبيًا لمعظم الفئات، وبالتالي فإن عقوبات الأداء بسبب التكرار متواضعة، خاصة مع فهرسة معرفات الكائنات.

يشير EAV/CR (EAV with Classes and Relationships) ^{[11] [12] [13]} إلى إطار عمل يدعم البنية الفرعية المعقدة. اسمه غير دقيق إلى حد ما: في حين أنه كان نتيجة لعمل على أنظمة EAV، في الممارسة العملية، يمكن تمثيل العديد من الفئات أو حتى معظمها في مثل هذا النظام في شكل علاقاتي قياسي، بناءً على ما إذا كانت السمات متفرقة أو كثيفة. يتميز EAV/CR حقًا ببياناته الوصفية التفصيلية للغاية، والتي تعد غنية بما يكفي لدعم التوليد التلقائي لواجهات التصفح للفئات الفردية دون الحاجة إلى كتابة كود واجهة المستخدم لكل فئة على حدة. أساس واجهات المتصفح هذه هو أنه من الممكن إنشاء مجموعة من استعلامات SQL الديناميكية المستقلة عن فئة الكائن، من خلال استشارة بياناته الوصفية أولاً واستخدام معلومات البيانات الوصفية لإنشاء سلسلة من الاستعلامات مقابل جداول البيانات، وقد تكون بعض هذه الاستعلامات متكررة بشكل تعسفي. يعمل هذا النهج بشكل جيد لاستعلامات الكائن في كل مرة، كما هو الحال في واجهات التصفح المستندة إلى الويب حيث يؤدي النقر فوق اسم الكائن إلى إظهار جميع تفاصيل الكائن في صفحة منفصلة: كما تسهل البيانات الوصفية المرتبطة بفئة هذا الكائن أيضًا عرض تفاصيل الكائن، لأنها تتضمن تسميات توضيحية للسمات الفردية، والترتيب الذي يجب تقديمها به بالإضافة إلى كيفية تجميعها.

أحد الأساليب المتبعة في EAV/CR هو السماح للأعمدة بحمل هياكل JSON ، والتي توفر بالتالي هيكل الفئة المطلوب. على سبيل المثال، يوفر PostgreSQL ، اعتبارًا من الإصدار 9.4، دعم العمود الثنائي JSON (JSONB)، مما يسمح بالاستعلام عن سمات JSON وفهرستها وضمها.

على حد تعبير البروفيسور دكتور دانييل ماسيس (رئيس قسم المعلوماتية الطبية سابقًا بجامعة فاندربيلت)، فإن تحديات العمل مع EAV تنبع من حقيقة أنه في قاعدة بيانات EAV، يختلف "المخطط المادي" (الطريقة التي يتم بها تخزين البيانات) بشكل جذري عن "المخطط المنطقي" - الطريقة التي ينظر بها المستخدمون والعديد من تطبيقات البرامج مثل حزم الإحصائيات، أي كصفوف وأعمدة تقليدية لفئات فردية. (نظرًا لأن جدول EAV يمزج مفهوميًا بين التفاح والبرتقال والجريب فروت والشوب سووي، إذا كنت تريد إجراء أي تحليل للبيانات باستخدام برنامج قياسي جاهز للاستخدام، في معظم الحالات يجب عليك تحويل مجموعات فرعية منها إلى شكل عمودي. ^[14] عملية القيام بذلك، والتي تسمى التمحور ، مهمة بما يكفي لمناقشتها بشكل منفصل.)

تساعد البيانات الوصفية في أداء الخدعة التي تسمح للمستخدمين بالتفاعل مع النظام من حيث المخطط المنطقي وليس المادي: يستشير البرنامج البيانات الوصفية باستمرار لعمليات مختلفة مثل عرض البيانات والتحقق التفاعلي واستخراج البيانات بالجملة والاستعلام المخصص . يمكن استخدام البيانات الوصفية في الواقع لتخصيص سلوك النظام.

تتنازل أنظمة EAV عن البساطة في البنية المادية والمنطقية للبيانات من أجل التعقيد في بياناتها الوصفية، والتي تلعب، من بين أمور أخرى، الدور الذي تلعبه قيود قاعدة البيانات والنزاهة المرجعية في تصميمات قواعد البيانات القياسية. مثل هذه المقايضة جديرة بالاهتمام بشكل عام، لأنه في المخطط المختلط النموذجي لأنظمة الإنتاج، يمكن للبيانات في الجداول العلائقية التقليدية أيضًا الاستفادة من الوظائف مثل إنشاء الواجهة التلقائية. إن بنية البيانات الوصفية معقدة بما يكفي بحيث تتضمن مخططًا فرعيًا خاصًا بها داخل قاعدة البيانات: تشير المفاتيح الخارجية المختلفة في جداول البيانات إلى الجداول داخل هذا المخطط الفرعي. هذا المخطط الفرعي هو معياري علائقي، مع استخدام ميزات مثل القيود والنزاهة المرجعية إلى أقصى حد.

إن صحة محتويات البيانات الوصفية، من حيث سلوك النظام المقصود، أمر بالغ الأهمية، وتعني مهمة ضمان الصحة أنه عند إنشاء نظام EAV، يجب بذل جهود تصميمية كبيرة لبناء واجهات مستخدم لتحرير البيانات الوصفية يمكن استخدامها من قبل الأشخاص في الفريق الذين يعرفون مجال المشكلة (على سبيل المثال، الطب السريري) ولكنهم ليسوا بالضرورة مبرمجين. (تاريخيًا، كان أحد الأسباب الرئيسية لفشل نظام TMR قبل العلاقات في تبنيه في مواقع أخرى غير مؤسسته الأصلية هو أن جميع البيانات الوصفية تم تخزينها في ملف واحد ببنية غير بديهية. كان تخصيص سلوك النظام عن طريق تغيير محتويات هذا الملف، دون التسبب في تعطل النظام، مهمة دقيقة لدرجة أن مؤلفي النظام وثقوا بأنفسهم فقط للقيام بذلك.)

عندما يتم تنفيذ نظام EAV من خلال RDF ، يمكن استخدام لغة مخطط RDF بشكل ملائم للتعبير عن مثل هذه البيانات الوصفية. يمكن بعد ذلك استخدام معلومات المخطط هذه بواسطة محرك قاعدة بيانات EAV لإعادة تنظيم بنية الجدول الداخلي بشكل ديناميكي لتحقيق أفضل كفاءة. ^[15]

بعض التحذيرات النهائية فيما يتعلق بالبيانات الوصفية:

• نظرًا لأن منطق العمل موجود في البيانات الوصفية وليس صريحًا في مخطط قاعدة البيانات (أي أنه بعيد عن المستوى، مقارنة بالأنظمة المصممة تقليديًا)، فإنه أقل وضوحًا لمن ليس على دراية بالنظام. لذلك، تعد أدوات تصفح البيانات الوصفية وإعداد تقارير البيانات الوصفية مهمة في ضمان إمكانية صيانة نظام EAV. في السيناريو الشائع حيث يتم تنفيذ البيانات الوصفية كمخطط فرعي علائقي، فإن هذه الأدوات ليست أكثر من تطبيقات مبنية باستخدام أدوات إعداد التقارير أو الاستعلام الجاهزة التي تعمل على جداول البيانات الوصفية.
• من السهل على المستخدم الذي يفتقر إلى المعرفة الكافية أن يفسد (أي يُدخل تناقضات وأخطاء في) البيانات الوصفية. لذلك، يجب تقييد الوصول إلى البيانات الوصفية، ووضع مسار تدقيق للوصول والتغييرات للتعامل مع المواقف التي يكون فيها العديد من الأفراد قادرين على الوصول إلى البيانات الوصفية. إن استخدام نظام إدارة قواعد البيانات العلائقية للبيانات الوصفية من شأنه أن يبسط عملية الحفاظ على الاتساق أثناء إنشاء البيانات الوصفية وتحريرها، من خلال الاستفادة من ميزات نظام إدارة قواعد البيانات العلائقية مثل دعم المعاملات. أيضًا، إذا كانت البيانات الوصفية جزءًا من نفس قاعدة البيانات مثل البيانات نفسها، فهذا يضمن نسخها احتياطيًا على الأقل بنفس تكرار نسخ البيانات نفسها، بحيث يمكن استردادها في وقت معين.
• يجب أن تكون جودة التعليقات والتوثيق داخل البيانات الوصفية (أي النص السردي/التوضيحي في الأعمدة الوصفية للمخطط الفرعي للبيانات الوصفية) أعلى بكثير، وذلك لتسهيل الفهم من قبل مختلف أعضاء فريق التطوير. إن ضمان جودة البيانات الوصفية (وإبقائها محدثة مع تطور النظام) له أولوية عالية جدًا في الإدارة والصيانة طويلة المدى لأي تصميم يستخدم مكون EAV. يمكن للبيانات الوصفية غير الموثقة بشكل جيد أو القديمة أن تعرض قابلية النظام للاستمرار على المدى الطويل للخطر. ^{[16] [17]}

• تتضمن بيانات التحقق الوصفية نوع البيانات ونطاق القيم المسموح بها أو العضوية في مجموعة من القيم ومطابقة التعبيرات العادية والقيمة الافتراضية وما إذا كان يُسمح للقيمة بأن تكون فارغة. في أنظمة EAV التي تمثل الفئات ذات البنية الفرعية، ستسجل بيانات التحقق الوصفية أيضًا الفئة، إن وجدت، التي تنتمي إليها سمة معينة.
• بيانات التعريف الخاصة بالعرض : كيفية عرض السمة للمستخدم (على سبيل المثال، كمربع نص أو صورة بأبعاد محددة، أو قائمة منسدلة أو مجموعة من أزرار الاختيار). عندما يتكون الكائن المركب من سمات متعددة، كما هو الحال في تصميم EAV/CR، توجد بيانات تعريف إضافية حول الترتيب الذي يجب أن تُعرض به السمات، وكيفية تجميع هذه السمات اختياريًا (تحت عناوين وصفية).
• بالنسبة للسمات التي تعتبر معلمات مختبرية، يتم تسجيل نطاقات القيم الطبيعية ، والتي قد تختلف حسب العمر والجنس والحالة الفسيولوجية وطريقة التحليل.
• تجميع البيانات الوصفية : يتم تقديم السمات عادةً كجزء من مجموعة ذات ترتيب أعلى، على سبيل المثال، نموذج خاص بتخصص معين. تتضمن البيانات الوصفية التجميعية معلومات مثل الترتيب الذي يتم به تقديم السمات. تنطبق بعض البيانات الوصفية للعرض، مثل الخطوط/الألوان وعدد السمات المعروضة في كل صف، على المجموعة ككل.

• بيانات التعريف الخاصة بالتبعية : في العديد من واجهات المستخدم، يلزم إدخال قيم معينة في حقول/سمات معينة إما لتعطيل/إخفاء حقول أخرى معينة أو تمكين/إظهار حقول أخرى. (على سبيل المثال، إذا اختار المستخدم الإجابة "لا" على سؤال منطقي "هل المريض مصاب بالسكري؟"، فيجب تعطيل الأسئلة اللاحقة حول مدة الإصابة بالسكري والأدوية المستخدمة لعلاجه وما إلى ذلك.) يتضمن تنفيذ ذلك في إطار عام تخزين التبعيات بين السمات المتحكمة والسمات المتحكم فيها.
• الحسابات والتحقق المعقد : كما هو الحال في جدول البيانات، يمكن حساب قيمة سمات معينة وعرضها، استنادًا إلى القيم المدخلة في الحقول التي يتم تقديمها في وقت سابق بالترتيب. (على سبيل المثال، مساحة سطح الجسم هي دالة للارتفاع والعرض). وبالمثل، قد تكون هناك "قيود" يجب أن تكون صحيحة حتى تكون البيانات صالحة: على سبيل المثال، في تعداد خلايا الدم البيضاء التفاضلي، يجب أن يكون مجموع تعدادات أنواع خلايا الدم البيضاء الفردية مساويًا دائمًا لـ 100، لأن التعدادات الفردية تمثل النسب المئوية. يتم تنفيذ الصيغ المحسوبة والتحقق المعقد بشكل عام عن طريق تخزين التعبيرات في البيانات الوصفية التي يتم استبدالها بالقيم التي يدخلها المستخدم ويمكن تقييمها. في متصفحات الويب، يحتوي كل من JavaScript و VBScript على وظيفة Eval() يمكن الاستفادة منها لهذا الغرض.

إن التحقق من صحة البيانات الوصفية وعرضها وتجميعها يجعل من الممكن إنشاء أطر عمل برمجية تدعم إنشاء واجهة مستخدم تلقائية لكل من تصفح البيانات وكذلك التحرير التفاعلي. في نظام الإنتاج الذي يتم تسليمه عبر الويب، يتم نقل مهمة التحقق من صحة بيانات EAV بشكل أساسي من الطبقة الخلفية/قاعدة البيانات (والتي لا تملك القدرة على القيام بهذه المهمة) إلى الطبقة الوسطى/خادم الويب. في حين أن التحقق من صحة الخلفية هو دائمًا مثالي، لأنه من المستحيل تقويضه عن طريق محاولة إدخال البيانات مباشرة في جدول، فإن التحقق من صحة الطبقة الوسطى من خلال إطار عام قابل للتنفيذ تمامًا، على الرغم من أن قدرًا كبيرًا من جهد تصميم البرامج يجب أن يذهب إلى بناء الإطار أولاً. يمكن أن يساعد توفر الأطر مفتوحة المصدر التي يمكن دراستها وتعديلها لتلبية الاحتياجات الفردية كثيرًا في تجنب إعادة اختراع العجلة. ^{[ بحاجة لمصدر ]}

(الجزء الأول من هذا القسم عبارة عن ملخص للمقالة المرجعية لـ Dinu / Nadkarni في Central، ^[18] والتي يتم توجيه القارئ إليها لمزيد من التفاصيل.)

لقد كانت نمذجة EAV، تحت المصطلحات البديلة " نمذجة البيانات العامة " أو "المخطط المفتوح"، أداة قياسية لمصممي نماذج البيانات المتقدمين. ومثلها كمثل أي تقنية متقدمة، يمكن أن تكون ذات حدين، ويجب استخدامها بحكمة.

كما أن استخدام EAV لا يمنع استخدام أساليب نمذجة قواعد البيانات العلائقية التقليدية ضمن نفس مخطط قاعدة البيانات. في السجلات الطبية الإلكترونية التي تعتمد على نظام إدارة قواعد البيانات العلائقية، مثل Cerner ، والتي تستخدم نهج EAV لمخطط البيانات السريرية الفرعي الخاص بها، فإن الغالبية العظمى من الجداول في المخطط يتم نمذجتها تقليديًا في الواقع، مع تمثيل السمات كأعمدة فردية بدلاً من صفوف.

في الواقع، يعد نمذجة المخطط الفرعي للبيانات الوصفية لنظام EAV ملائمًا جدًا للنمذجة التقليدية، نظرًا للعلاقات المتبادلة بين المكونات المختلفة للبيانات الوصفية. في نظام TrialDB، على سبيل المثال، يفوق عدد جداول البيانات الوصفية في المخطط عدد جداول البيانات بنحو عشرة إلى واحد. ولأن صحة البيانات الوصفية واتساقها أمر بالغ الأهمية للتشغيل الصحيح لنظام EAV، فإن مصمم النظام يريد الاستفادة الكاملة من جميع الميزات التي توفرها أنظمة إدارة قواعد البيانات العلائقية، مثل سلامة المرجع والقيود القابلة للبرمجة، بدلاً من الاضطرار إلى إعادة اختراع عجلة محرك نظام إدارة قواعد البيانات العلائقية. وبالتالي، فإن جداول البيانات الوصفية العديدة التي تدعم تصميمات EAV تكون عادةً في شكل علاقات طبيعي ثالث.

تستخدم أنظمة السجلات الصحية الإلكترونية التجارية (EHRs) نمذجة الصفوف لفئات البيانات مثل التشخيصات والإجراءات الجراحية التي أجريت ونتائج الاختبارات المعملية، والتي يتم فصلها إلى جداول منفصلة. في كل جدول، يكون "الكيان" مركبًا من معرف المريض وتاريخ/وقت إجراء التشخيص (أو الجراحة أو الاختبار المعملي الذي تم إجراؤه)؛ والسمة هي مفتاح خارجي في جدول بحث مُعيَّن خصيصًا يحتوي على مفردات مُتحكم فيها - على سبيل المثال، ICD-10 للتشخيصات، المصطلحات الإجرائية الحالية للإجراءات الجراحية، مع مجموعة من سمات القيمة. (على سبيل المثال، بالنسبة لنتائج الاختبارات المعملية، قد يسجل المرء القيمة المقاسة، سواء كانت في النطاق الطبيعي أو المنخفض أو المرتفع، ومعرف الشخص المسؤول عن إجراء الاختبار، وتاريخ/وقت إجراء الاختبار، وما إلى ذلك). وكما ذكرنا سابقًا، هذا ليس نهج EAV كاملًا لأن نطاق السمات لجدول معين مقيد، تمامًا كما يكون نطاق معرفات المنتجات في جدول المبيعات في السوبر ماركت مقيدًا بنطاق المنتجات في جدول المنتجات.

ومع ذلك، لالتقاط البيانات حول المعلمات التي لا يتم تعريفها دائمًا في المفردات القياسية، توفر السجلات الصحية الإلكترونية أيضًا آلية EAV "نقية"، حيث يمكن لمستخدمي الطاقة المعينين خصيصًا تحديد سمات جديدة ونوع بياناتها والقيم القصوى والدنيا المسموح بها (أو مجموعة القيم/الرموز المسموح بها)، ثم السماح للآخرين بالتقاط البيانات بناءً على هذه السمات. في السجلات الصحية الإلكترونية Epic (TM)، تسمى هذه الآلية "Flowsheets"، وتُستخدم عادةً لالتقاط بيانات مراقبة التمريض للمرضى الداخليين.

الحالة النموذجية لاستخدام نموذج EAV هي للسمات المتفرقة غير المتجانسة، مثل المعلمات السريرية في السجلات الطبية الإلكترونية، كما ذكر أعلاه. ولكن حتى هنا، من الدقيق أن نقول إن مبدأ نمذجة EAV يُطبق على مخطط فرعي من قاعدة البيانات وليس على كل محتوياتها. (على سبيل المثال، يتم نمذجة التركيبة السكانية للمرضى بشكل طبيعي في هيكل علائقي تقليدي يتكون من عمود واحد لكل سمة).

وبالتالي، تعكس الحجج حول EAV مقابل التصميم "العلاقي" فهمًا غير كامل للمشكلة: يجب استخدام تصميم EAV فقط لذلك المخطط الفرعي لقاعدة البيانات حيث يلزم نمذجة السمات المتفرقة: حتى هنا، يجب دعمها بجداول بيانات وصفية من النموذج الطبيعي الثالث . هناك عدد قليل نسبيًا من مشاكل تصميم قاعدة البيانات حيث يتم مواجهة السمات المتفرقة: وهذا هو السبب في أن الظروف التي يكون فيها تصميم EAV قابلاً للتطبيق نادرة نسبيًا. حتى في الحالات التي يتم فيها مواجهة هذه الحالات، فإن مجموعة من جداول EAV ليست الطريقة الوحيدة لمعالجة البيانات المتفرقة: الحل القائم على XML (الذي تمت مناقشته أدناه) قابل للتطبيق عندما يكون العدد الأقصى للسمات لكل كيان متواضعًا نسبيًا، ويكون الحجم الإجمالي للبيانات المتفرقة متواضعًا أيضًا. ومن الأمثلة على هذا الموقف مشاكل التقاط السمات المتغيرة لأنواع مختلفة من المنتجات.

قد تحدث السمات المتفرقة أيضًا في مواقف التجارة الإلكترونية حيث تقوم المؤسسة بشراء أو بيع مجموعة واسعة ومتنوعة للغاية من السلع، مع كون تفاصيل الفئات الفردية من السلع متغيرة للغاية.

إن أحد التطبيقات الأخرى لـ EAV هو نمذجة الفئات والسمات التي، على الرغم من أنها ليست نادرة، فهي ديناميكية، ولكن حيث يكون عدد صفوف البيانات لكل فئة متواضعًا نسبيًا - بضع مئات من الصفوف على الأكثر، ولكن عادةً بضع عشرات - ويطلب من مطور النظام أيضًا توفير واجهة مستخدم نهائية قائمة على الويب في غضون فترة زمنية قصيرة جدًا. تعني "الديناميكية" أن الفئات والسمات الجديدة تحتاج إلى تعريف وتعديل مستمر لتمثيل نموذج بيانات متطور. يمكن أن يحدث هذا السيناريو في المجالات العلمية المتطورة بسرعة وكذلك في تطوير الأنطولوجيا، وخاصة أثناء مراحل النمذجة الأولية والتحسين التكراري.

في حين أن إنشاء جداول وأعمدة جديدة لتمثيل فئة جديدة من البيانات ليس عملاً شاقًا بشكل خاص، فإن برمجة واجهات الويب التي تدعم التصفح أو التحرير الأساسي مع التحقق من صحة النوع والنطاق تتطلب الكثير من الجهد. في مثل هذه الحالة، فإن الحل الأكثر قابلية للصيانة على المدى الطويل هو إنشاء إطار عمل حيث يتم تخزين تعريفات الفئة والسمات في بيانات وصفية، ويقوم البرنامج بإنشاء واجهة مستخدم أساسية من هذه البيانات الوصفية بشكل ديناميكي.

تم إنشاء إطار عمل EAV/CR، المذكور سابقًا، لمعالجة هذا الموقف بالذات. لاحظ أن نموذج بيانات EAV ليس ضروريًا هنا، ولكن قد يعتبره مصمم النظام بديلاً مقبولًا لإنشاء، على سبيل المثال، ستين جدولًا أو أكثر تحتوي على إجمالي لا يزيد عن ألفي صف. هنا، نظرًا لأن عدد الصفوف لكل فئة قليل جدًا، فإن اعتبارات الكفاءة أقل أهمية؛ مع الفهرسة القياسية حسب معرف الفئة/معرف السمة، يمكن لمحسنات نظام إدارة قواعد البيانات تخزين البيانات الخاصة بفئة صغيرة في الذاكرة بسهولة عند تشغيل استعلام يتضمن تلك الفئة أو السمة.

في سيناريو السمات الديناميكية، يجدر بالذكر أن إطار وصف الموارد (RDF) يُستخدم كأساس لعمل علم الوجود المرتبط بالويب الدلالي. RDF، المقصود منه أن يكون طريقة عامة لتمثيل المعلومات، هو شكل من أشكال EAV: يتألف ثلاثي RDF من كائن وخاصية وقيمة.

في نهاية كتاب جون بنتلي "كتابة برامج فعّالة"، يحذر المؤلف من أن جعل الكود أكثر كفاءة بشكل عام يجعل فهمه وصيانته أكثر صعوبة، وبالتالي لا يسارع المرء إلى تعديل الكود ما لم يحدد أولاً وجود مشكلة في الأداء، وما لم تحدد تدابير مثل تحديد ملف تعريف الكود الموقع الدقيق للاختناق. بمجرد القيام بذلك، يمكنك تعديل الكود المحدد فقط الذي يحتاج إلى التشغيل بشكل أسرع. تنطبق اعتبارات مماثلة على نمذجة EAV: يمكنك تطبيقها فقط على النظام الفرعي حيث يُعرف أن النمذجة العلائقية التقليدية مسبقًا غير قابلة للإدارة (كما هو الحال في مجال البيانات السريرية)، أو يتم اكتشافها أثناء تطور النظام، أنها تشكل تحديات صيانة كبيرة. على سبيل المثال، يشير خبير قواعد البيانات (ونائب رئيس Core Technologies حاليًا في شركة Oracle Corporation) توم كايت، ^[19] بشكل صحيح إلى عيوب استخدام EAV في سيناريوهات الأعمال التقليدية، ويشير إلى أن مجرد "المرونة" ليست معيارًا كافيًا لاستخدام EAV. (ومع ذلك، فهو يدعي بشكل قاطع أنه يجب تجنب EAV في جميع الظروف، على الرغم من أن قسم علوم الصحة في شركة Oracle يستخدم EAV لنمذجة سمات البيانات السريرية في أنظمتها التجارية ClinTrial ^[20] وOracle Clinical. ^[21] )

تتمثل نقطة الضعف في EAV في صعوبة العمل مع كميات كبيرة من بيانات EAV. غالبًا ما يكون من الضروري التحويل المؤقت أو الدائم بين التمثيلات العمودية والصفية أو التمثيلات النموذجية EAV لنفس البيانات؛ يمكن أن يكون هذا عرضة للخطأ إذا تم يدويًا وكذلك مكثفًا لوحدة المعالجة المركزية. تعالج الأطر العامة التي تستخدم بيانات التعريف الخاصة بالسمات وتجميع السمات القيد الأول ولكن ليس القيد الثاني؛ يكون استخدامها إلزاميًا إلى حد ما في حالة المخططات المختلطة التي تحتوي على مزيج من البيانات التقليدية العلائقية وبيانات EAV، حيث يمكن أن يكون حاصل الخطأ كبيرًا جدًا.

تُسمى عملية التحويل بالتدوير . لا يُطلب التدوير فقط لبيانات EAV ولكن أيضًا لأي شكل من أشكال البيانات النموذجية للصفوف. (على سبيل المثال، يتم استخدام البيانات النموذجية للصفوف في تنفيذ خوارزمية Apriori لتحليل الارتباط، والتي تُستخدم على نطاق واسع لمعالجة بيانات مبيعات السوبر ماركت لتحديد المنتجات الأخرى التي من المرجح أن يشتريها مشتري منتج معين، كخطوة أولى.) تحتوي العديد من محركات قواعد البيانات على ملحقات SQL خاصة لتسهيل التدوير، كما تدعمها أيضًا حزم مثل Microsoft Excel. يتم النظر في الظروف التي يكون فيها التدوير ضروريًا أدناه.

• تصفح كميات متواضعة من البيانات الخاصة بكيان فردي، متبوعًا بشكل اختياري بتحرير البيانات استنادًا إلى التبعيات بين السمات. يتم تسهيل هذه العملية من خلال تخزين كميات متواضعة من البيانات الوصفية الداعمة المطلوبة في ذاكرة التخزين المؤقت. بعض البرامج، مثل TrialDB، يمكنها الوصول إلى البيانات الوصفية لإنشاء صفحات ويب شبه ثابتة تحتوي على كود برمجة مضمن بالإضافة إلى هياكل بيانات تحمل البيانات الوصفية.
• إن الاستخراج بالجملة يحول كميات كبيرة (ولكن يمكن التنبؤ بها) من البيانات (على سبيل المثال، البيانات الكاملة لدراسة سريرية) إلى مجموعة من الجداول العلائقية. وعلى الرغم من أن هذه المهمة تتطلب الكثير من وحدة المعالجة المركزية، إلا أنها نادرة ولا يلزم القيام بها في الوقت الفعلي؛ أي أنه يمكن للمستخدم الانتظار حتى اكتمال عملية مجمعة. ولا يمكن المبالغة في أهمية الاستخراج بالجملة، خاصة عندما يتم معالجة البيانات أو تحليلها باستخدام أدوات خارجية قياسية لا تدرك تمامًا بنية EAV. وهنا، لا يُنصح بمحاولة إعادة اختراع مجموعات كاملة من العجلات من خلال إطار عام، ومن الأفضل استخراج بيانات EAV بالجملة إلى جداول علائقية ثم العمل عليها باستخدام أدوات قياسية.
• يجب أن تعرض واجهات الاستعلام المخصصة للبيانات المصممة على شكل صف أو نموذج EAV، عند الاستعلام عنها من منظور السمات الفردية (على سبيل المثال، "استرجاع جميع المرضى الذين يعانون من أمراض الكبد، مع وجود علامات فشل الكبد وعدم وجود تاريخ لإدمان الكحول") نتائج الاستعلام مع السمات الفردية كأعمدة منفصلة. بالنسبة لمعظم سيناريوهات قاعدة بيانات EAV، يجب أن يكون أداء الاستعلام المخصص مقبولاً، ولكن الاستجابات التي تقل عن الثانية ليست ضرورية، لأن الاستعلامات تميل إلى أن تكون استكشافية بطبيعتها.

ومع ذلك، فإن بنية نموذج بيانات EAV هي مرشح مثالي للتقسيم العلائقي، انظر الجبر العلائقي . باستخدام استراتيجية فهرسة جيدة، من الممكن الحصول على وقت استجابة في أقل من بضع مئات من المللي ثانية على جدول EAV يحتوي على مليار صف. لقد أثبت بيتر لارسون، الخبير الرئيسي في Microsoft SQL Server، ذلك على جهاز كمبيوتر محمول وجعل الحل متاحًا بشكل عام. ^[22]

• أحد التحسينات الممكنة هو استخدام " مستودع " منفصل أو مخطط قابل للاستعلام يتم تحديث محتوياته في وضع الدفعات من مخطط الإنتاج (المعاملات). راجع مستودع البيانات . تتم فهرسة الجداول في المستودع بشكل كبير وتحسينها باستخدام إزالة التطبيع ، والتي تجمع بين جداول متعددة في جدول واحد لتقليل عقوبة الأداء بسبب ضم الجداول.
• يمكن تحويل بيانات EAV معينة في المستودع إلى جداول قياسية باستخدام " العروض المادية " (انظر مستودع البيانات )، ولكن هذا عادةً ما يكون الملاذ الأخير الذي يجب استخدامه بعناية، لأن عدد العروض من هذا النوع يميل إلى النمو بشكل غير خطي مع عدد السمات في النظام. ^[14]
• هياكل البيانات المخزنة في الذاكرة : يمكن للمرء استخدام جداول التجزئة والمصفوفات ثنائية الأبعاد في الذاكرة جنبًا إلى جنب مع بيانات التعريف الخاصة بتجميع السمات لتدوير البيانات، مجموعة واحدة في كل مرة. تُكتب هذه البيانات على القرص كملف مفصول مسطح، مع الأسماء الداخلية لكل سمة في الصف الأول: يمكن استيراد هذا التنسيق بسهولة إلى جدول علائقي. تتفوق تقنية "الذاكرة" هذه بشكل كبير على الطرق البديلة من خلال الحفاظ على الاستعلامات على جداول EAV بسيطة قدر الإمكان وتقليل عدد عمليات الإدخال/الإخراج. ^[14] يسترد كل بيان كمية كبيرة من البيانات، وتساعد جداول التجزئة في تنفيذ عملية التمحور، والتي تتضمن وضع قيمة لمثيل سمة معينة في الصف والعمود المناسبين. ذاكرة الوصول العشوائي (RAM) وفيرة بما يكفي وبأسعار معقولة في الأجهزة الحديثة بحيث تتناسب مجموعة البيانات الكاملة لمجموعة سمة واحدة حتى في مجموعات البيانات الكبيرة تمامًا في الذاكرة، على الرغم من أنه يمكن جعل الخوارزمية أكثر ذكاءً من خلال العمل على شرائح من البيانات إذا تبين أن هذا ليس هو الحال.

من الواضح، بغض النظر عن الأساليب التي تتبعها، أن استعلام EAV لن يكون سريعًا مثل استعلام البيانات العلائقية القياسية المصممة على شكل أعمدة لأنواع معينة من الاستعلامات، بنفس الطريقة التي لا يكون بها الوصول إلى العناصر في المصفوفات المتفرقة سريعًا مثل تلك الموجودة في المصفوفات غير المتفرقة إذا كانت الأخيرة تتناسب تمامًا مع الذاكرة الرئيسية. (تتطلب المصفوفات المتفرقة، التي يتم تمثيلها باستخدام هياكل مثل القوائم المرتبطة، عبور القائمة للوصول إلى عنصر في موضع XY معين، بينما يمكن إجراء الوصول إلى العناصر في المصفوفات الممثلة كمصفوفات ثنائية الأبعاد باستخدام عمليات سجل وحدة المعالجة المركزية السريعة.) ومع ذلك، إذا اخترت نهج EAV بشكل صحيح للمشكلة التي كنت تحاول حلها، فهذا هو الثمن الذي تدفعه؛ في هذا الصدد، يعد نمذجة EAV مثالاً على المقايضة بين المساحة (وصيانة المخطط) ووقت وحدة المعالجة المركزية.

في الأصل، افترض ماير وأولمان وفاردي ^[23] أن "نموذج البيانات الشامل" (UDM) يسعى إلى تبسيط الاستعلام عن مخطط علاقات معقد من قبل المستخدمين السذج، من خلال خلق الوهم بأن كل شيء مخزن في "جدول عالمي" عملاق واحد. ويفعل ذلك من خلال الاستفادة من العلاقات بين الجداول، بحيث لا يحتاج المستخدم إلى القلق بشأن الجدول الذي يحتوي على أي سمة. ومع ذلك، أشار سي جيه ديت ^[24] إلى أنه في الظروف التي يكون فيها الجدول مرتبطًا بشكل مضاعف بآخر (كما هو الحال في قواعد بيانات الأنساب، حيث يكون والد ووالدة الفرد فردين أيضًا، أو في بعض قواعد بيانات الأعمال حيث يتم تخزين جميع العناوين مركزيًا، ويمكن أن يكون لدى المنظمة عناوين مكتب وعناوين شحن مختلفة)، لا توجد بيانات وصفية كافية داخل مخطط قاعدة البيانات لتحديد الارتباطات الواضحة. عندما يتم تسويق UDM، كما هو الحال في SAP BusinessObjects ، يتم التغلب على هذا القيد من خلال إنشاء "Universes"، وهي وجهات نظر علائقية مع انضمامات محددة مسبقًا بين مجموعات من الجداول: يقوم مطور "Universe" بإزالة الغموض عن الانضمامات الغامضة عن طريق تضمين الجدول المرتبط بشكل متعدد في عرض عدة مرات باستخدام أسماء مستعارة مختلفة.

بصرف النظر عن الطريقة التي يتم بها نمذجة البيانات صراحةً (UDM يستخدم ببساطة وجهات نظر علائقية للتوسط بين المستخدم ومخطط قاعدة البيانات)، يختلف EAV عن نماذج البيانات العالمية في أنه ينطبق أيضًا على الأنظمة المعاملاتية، وليس فقط الأنظمة الموجهة للاستعلام (للقراءة فقط) كما هو الحال في UDM. أيضًا، عند استخدامه كأساس لأنظمة استعلام البيانات السريرية، فإن تنفيذات EAV لا تحمي المستخدم بالضرورة من الاضطرار إلى تحديد فئة كائن الاهتمام. في سوق البيانات السريرية i2b2 المستند إلى EAV، ^[25] على سبيل المثال، عندما يبحث المستخدم عن مصطلح، يكون لديه خيار تحديد فئة البيانات التي يهتم بها المستخدم. على سبيل المثال، يمكن أن تشير عبارة " الليثيوم " إما إلى الدواء (الذي يستخدم لعلاج الاضطراب ثنائي القطب )، أو اختبار معمل لمستوى الليثيوم في دم المريض. (يجب مراقبة مستوى الليثيوم في الدم بعناية: فالكثير من الدواء يسبب آثارًا جانبية شديدة، في حين أن القليل جدًا غير فعال.)

يمكن لتطبيق Open Schema استخدام عمود XML في جدول لالتقاط المعلومات المتغيرة/المتفرقة. ^[26] يمكن تطبيق أفكار مماثلة على قواعد البيانات التي تدعم الأعمدة ذات القيمة JSON : يمكن تمثيل البيانات المتفرقة والتسلسلية على هيئة JSON. إذا كانت قاعدة البيانات تدعم JSON، مثل PostgreSQL و(جزئيًا) SQL Server 2016 والإصدارات الأحدث، فيمكن استعلام السمات وفهرستها وضمها. يمكن أن يوفر هذا تحسينات في الأداء تزيد عن 1000 ضعف مقارنة بتطبيقات EAV الساذجة، ^[27] ولكنه لا يجعل تطبيق قاعدة البيانات الإجمالي أكثر قوة بالضرورة.

لاحظ أن هناك طريقتين لتخزين بيانات XML أو JSON: الطريقة الأولى هي تخزينها كسلسلة عادية، غير شفافة لخادم قاعدة البيانات؛ والطريقة الأخرى هي استخدام خادم قاعدة بيانات يمكنه "رؤية" البنية. من الواضح أن هناك بعض العيوب الشديدة لتخزين السلاسل غير الشفافة: لا يمكن الاستعلام عنها بشكل مباشر، ولا يمكن تكوين فهرس بناءً على محتوياتها، ومن المستحيل إجراء عمليات الانضمام بناءً على المحتوى.

يصبح بناء تطبيق يتعين عليه إدارة البيانات معقدًا للغاية عند استخدام نماذج EAV، نظرًا لمدى البنية الأساسية التي يجب تطويرها من حيث جداول البيانات الوصفية وكود إطار عمل التطبيق. يحل استخدام XML مشكلة التحقق من صحة البيانات المستندة إلى الخادم (والتي يجب أن تتم بواسطة كود الطبقة المتوسطة والمستند إلى المتصفح في الأطر المستندة إلى EAV)، ولكن لها العيوب التالية:

• إن هذه الطريقة تتطلب الكثير من المبرمجين. فمن المعروف أن كتابة مخططات XML يدويًا أمر صعب للغاية، ومن الطرق الموصى بها إنشاء هذه المخططات من خلال تعريف الجداول العلائقية، وتوليد كود مخطط XML، ثم حذف هذه الجداول. وهذا يمثل مشكلة في العديد من عمليات الإنتاج التي تنطوي على مخططات ديناميكية، حيث يتعين على المستخدمين المتمرسين الذين يفهمون مجال تطبيق معين (مثل إدارة المخزون أو الطب الحيوي) تعريف سمات جديدة ولكنهم ليسوا بالضرورة مبرمجين. وعلى النقيض من ذلك، في أنظمة الإنتاج التي تستخدم EAV، يقوم هؤلاء المستخدمون بتعريف سمات جديدة (وأنواع البيانات وعمليات التحقق من الصحة المرتبطة بكل منها) من خلال تطبيق واجهة المستخدم الرسومية. ولأن البيانات الوصفية المرتبطة بالتحقق مطلوب تخزينها في جداول علائقية متعددة في تصميم موحد، فإن تطبيق واجهة المستخدم الرسومية الذي يربط هذه الجداول معًا ويفرض عمليات التحقق من اتساق البيانات الوصفية المناسبة هو الطريقة العملية الوحيدة للسماح بإدخال معلومات السمات، حتى للمطورين المتقدمين - حتى لو كانت النتيجة النهائية تستخدم XML أو JSON بدلاً من الجداول العلائقية المنفصلة.
• إن التشخيصات المستندة إلى الخادم والتي تؤدي إلى حل XML/JSON إذا تمت محاولة إدخال بيانات غير صحيحة (على سبيل المثال، التحقق من النطاق أو انتهاكات نمط التعبيرات العادية) تكون غامضة للمستخدم النهائي: لنقل الخطأ بدقة، يتعين على المرء، على الأقل، ربط تشخيص خطأ مفصل وسهل الاستخدام بكل سمة.
• الحل لا يعالج مشكلة إنشاء واجهة المستخدم.

إن كل العيوب المذكورة أعلاه يمكن علاجها عن طريق إنشاء طبقة من البيانات الوصفية وأكواد التطبيق، ولكن عند إنشاء هذه الطبقة، اختفت "الميزة" الأصلية المتمثلة في عدم الاضطرار إلى إنشاء إطار عمل. والحقيقة هي أن نمذجة سمات البيانات المتفرقة بشكل قوي تشكل مشكلة صعبة تتعلق بتصميم قاعدة البيانات والتطبيق بغض النظر عن نهج التخزين المستخدم. ومع ذلك، يثبت عمل ساركا، ^[26] جدوى استخدام حقل XML بدلاً من جداول EAV العلائقية الخاصة بالنوع لطبقة تخزين البيانات، وفي المواقف التي يكون فيها عدد السمات لكل كيان متواضعًا (على سبيل المثال، سمات المنتج المتغيرة لأنواع مختلفة من المنتجات) يكون الحل القائم على XML أكثر إحكاما من الحل القائم على جدول EAV. (قد يُنظر إلى XML نفسه كوسيلة لتمثيل بيانات السمة والقيمة، على الرغم من أنه يعتمد على نص منظم وليس على جداول علائقية.)

توجد عدة طرق أخرى لتمثيل البيانات ذات البنية الشجرية، سواء كانت XML أو JSON أو تنسيقات أخرى، مثل نموذج المجموعة المتداخلة ، في قاعدة بيانات علائقية. من ناحية أخرى، بدأ بائعو قواعد البيانات في تضمين دعم JSON وXML في هياكل البيانات وميزات الاستعلام الخاصة بهم، كما هو الحال في IBM Db2 ، حيث يتم تخزين بيانات XML كـ XML منفصلة عن الجداول، باستخدام استعلامات XPath كجزء من عبارات SQL، أو في PostgreSQL ، مع نوع بيانات JSON ^[28] يمكن فهرسته والاستعلام عنه. تعمل هذه التطورات على إنجاز أو تحسين أو استبدال نهج نموذج EAV.

إن استخدامات JSON وXML ليست بالضرورة هي نفسها استخدام نموذج EAV، على الرغم من أنها يمكن أن تتداخل. XML أفضل من EAV للبيانات الهرمية التعسفية التي تكون متواضعة نسبيًا في الحجم لكيان واحد: فهي ليست مخصصة للتوسع إلى مستوى متعدد الجيجابايت فيما يتعلق بأداء معالجة البيانات. ^{[ بحاجة لمصدر ]} لا يهتم XML في حد ذاته بمشكلة السمات المتفرقة، وعندما يمكن تحليل نموذج البيانات الأساسي للمعلومات المراد تمثيلها بشكل مباشر إلى بنية علائقية، فإن XML أكثر ملاءمة كوسيلة لتبادل البيانات من آلية التخزين الأساسية. EAV، كما ذكرنا سابقًا، ينطبق بشكل خاص (وفقط) على سيناريو السمات المتفرقة. عندما يحدث مثل هذا السيناريو، فإن استخدام جداول السمات والقيم الخاصة بنوع البيانات والتي يمكن فهرستها حسب الكيان والسمة والقيمة والتلاعب بها من خلال عبارات SQL البسيطة أكثر قابلية للتوسع بشكل كبير من استخدام بنية شجرة XML. ^{[ بحاجة لمصدر ]} يستخدم محرك تطبيقات Google، المذكور أعلاه، ^{[ بحاجة لمصدر ]} جداول القيم ذات النوع القوي لسبب وجيه. ^{[ بحاجة لمصدر ]}

النهج البديل لإدارة المشاكل المختلفة التي تواجهها البيانات المهيكلة بـ EAV هو استخدام قاعدة بيانات الرسوم البيانية . تمثل هذه الكيانات كعقد للرسم البياني أو الرسم البياني الفائق ، والسمات كروابط أو حواف لهذا الرسم البياني. تتم معالجة مشكلة الانضمامات إلى الجداول من خلال توفير لغات استعلام خاصة بالرسم البياني، مثل Apache TinkerPop، ^[29] أو مُطابق نمط OpenCog atomspace. ^[30]

البديل الآخر هو استخدام متجر SPARQL .

يتضمن إصدار PostgreSQL 9.4 دعمًا لأعمدة JSON الثنائية (JSONB)، والتي يمكن الاستعلام عنها وفهرستها وضمها. يسمح هذا بتحسينات الأداء بمعاملات تصل إلى ألف أو أكثر مقارنة بتصميمات جداول EAV التقليدية. ^[27]

يحتوي مخطط قاعدة البيانات المستند إلى JSONB دائمًا على عدد أقل من الجداول: يمكن للمرء أن يتداخل مع أزواج السمات والقيم في حقول نوع JSONB لجدول الكيان. وهذا يجعل مخطط قاعدة البيانات سهل الفهم واستعلامات SQL موجزة. ^[31] يصبح كود البرمجة للتلاعب بكائنات قاعدة البيانات على طبقة التجريد أقصر كثيرًا. ^[32]

يقدم Microsoft SQL Server 2008 بديلاً (ملكيًا) لـ EAV. ^[33] يمكن تصنيف الأعمدة ذات نوع البيانات الذري (على سبيل المثال، الأعمدة الرقمية أو varchar أو أعمدة التاريخ والوقت) على أنها متفرقة ببساطة عن طريق تضمين كلمة SPARSE في تعريف العمود في عبارة CREATE TABLE. تعمل الأعمدة المتفرقة على تحسين تخزين قيم NULL (التي لا تشغل أي مساحة على الإطلاق الآن) وهي مفيدة عندما تحتوي غالبية السجلات في الجدول على قيم NULL لهذا العمود. يتم أيضًا تحسين الفهارس الموجودة على الأعمدة المتفرقة: تتم فهرسة الصفوف التي تحتوي على قيم فقط. بالإضافة إلى ذلك، يمكن تجميع محتويات جميع الأعمدة المتفرقة في صف معين من الجدول بشكل جماعي في عمود XML واحد (مجموعة أعمدة)، يكون محتواه من النموذج [<column-name>column contents </column-name>]*....في الواقع، إذا تم تعريف مجموعة أعمدة لجدول كجزء من عبارة CREATE TABLE، تتم إضافة جميع الأعمدة المتفرقة المحددة لاحقًا إليها عادةً. وهذا له نتيجة مثيرة للاهتمام وهي أن عبارة SQL SELECT * from <tablename>لن تعيد الأعمدة المتفرقة الفردية، بل ستجمعها كلها في عمود XML واحد يكون اسمه هو اسم مجموعة الأعمدة (والذي يعمل بالتالي كعمود محسوب افتراضي). والأعمدة المتفرقة ملائمة لتطبيقات الأعمال مثل معلومات المنتج، حيث يمكن أن تكون السمات القابلة للتطبيق متغيرة للغاية اعتمادًا على نوع المنتج، ولكن حيث يكون العدد الإجمالي للسمات المتغيرة لكل نوع منتج متواضعًا نسبيًا.

ومع ذلك، فإن هذا النهج لنمذجة السمات المتفرقة له عدة قيود: فقد اختارت أنظمة إدارة قواعد البيانات المنافسة، على وجه الخصوص، عدم استعارة هذه الفكرة لمحركاتها الخاصة. وتشمل القيود ما يلي:

• الحد الأقصى لعدد الأعمدة المتفرقة في الجدول هو 10000، وهو ما قد يكون أقل من الحد الأقصى لبعض التطبيقات، مثل تخزين البيانات السريرية، حيث يكون العدد المحتمل للسمات أكبر بمقدار مرتبة واحدة من حيث الحجم. لذلك، هذا ليس حلاً لنمذجة *كل* السمات السريرية المحتملة للمريض.
• إن إضافة سمات جديدة – أحد الأسباب الرئيسية التي قد تدفعنا إلى البحث عن نموذج EAV – لا تزال تتطلب وجود مسؤول قاعدة بيانات. علاوة على ذلك، لم يتم تناول مشكلة بناء واجهة مستخدم لبيانات السمات المتفرقة: فقط آلية التخزين هي التي تم تبسيطها. * يمكن كتابة التطبيقات لإضافة وإزالة الأعمدة المتفرقة من الجدول بشكل ديناميكي في وقت التشغيل: على النقيض من ذلك، فإن محاولة تنفيذ مثل هذا الإجراء في سيناريو متعدد المستخدمين حيث لا يزال مستخدمون/عمليات أخرى يستخدمون الجدول ستُمنع بالنسبة للجداول التي لا تحتوي على أعمدة متفرقة. ومع ذلك، في حين توفر هذه القدرة القوة والمرونة، إلا أنها تدعو إلى إساءة الاستخدام، ويجب استخدامها بحكمة وبصورة غير متكررة.
  • يمكن أن يؤدي هذا إلى عقوبات كبيرة على الأداء، ويرجع ذلك جزئيًا إلى إبطال أي خطط استعلام مجمعة تستخدم هذا الجدول تلقائيًا.
  • إن إضافة أو إزالة العمود الديناميكي هي عملية يجب تدقيقها، لأن إزالة العمود يمكن أن تتسبب في فقد البيانات: السماح لتطبيق بتعديل جدول دون الاحتفاظ بنوع ما من المسار، بما في ذلك مبرر الإجراء، ليس ممارسة برمجية جيدة.
• لا يمكن تطبيق قيود SQL (على سبيل المثال، عمليات التحقق من النطاقات، وعمليات التحقق من التعبيرات العادية) على الأعمدة المتفرقة. والفحص الوحيد الذي يتم تطبيقه هو التحقق من نوع البيانات الصحيح. ويتعين تنفيذ القيود في جداول البيانات الوصفية وكود الطبقة المتوسطة، كما هو الحال في أنظمة EAV الإنتاجية. (ينطبق هذا الاعتبار أيضًا على تطبيقات الأعمال).
• يحتوي SQL Server على قيود على حجم الصف عند محاولة تغيير تنسيق تخزين عمود: لا يمكن أن يتجاوز إجمالي محتويات جميع أعمدة البيانات الذرية، المتفرقة وغير المتفرقة، في صف يحتوي على بيانات 8016 بايت إذا كان هذا الجدول يحتوي على عمود متفرق لنسخ البيانات تلقائيًا.
• تتطلب الأعمدة المتفرقة التي تحتوي على بيانات عبئًا تخزينيًا يبلغ 4 بايتات لكل عمود بالإضافة إلى التخزين لنوع البيانات نفسه (على سبيل المثال، 4 بايتات لأعمدة التاريخ والوقت). يؤثر هذا على كمية بيانات الأعمدة المتفرقة التي يمكنك ربطها بصف معين. يتم تخفيف قيد الحجم هذا لنوع البيانات varchar، مما يعني أنه إذا وصل المرء إلى حدود حجم الصف في نظام إنتاج، فيجب عليه الالتفاف حوله من خلال تعيين الأعمدة المتفرقة على أنها varchar حتى لو كان لديها نوع بيانات جوهري مختلف. لسوء الحظ، يعمل هذا النهج الآن على تقويض فحص نوع البيانات من جانب الخادم.

يقدم العديد من بائعي الحوسبة السحابية مخازن بيانات تعتمد على نموذج EAV، حيث يمكن ربط عدد عشوائي من السمات بكيان معين. يقدم روجر جينينجز مقارنة متعمقة ^[34] لهذه. في عرض أمازون، SimpleDB، يقتصر نوع البيانات على السلاسل، ويجب إجبار البيانات غير السلسلة جوهريًا على السلسلة (على سبيل المثال، يجب حشو الأرقام بأصفار بادئة) إذا كنت ترغب في إجراء عمليات مثل الفرز. يقدم عرض Microsoft، Windows Azure Table Storage، مجموعة محدودة من أنواع البيانات: byte[] وbool وDateTime وdouble وGuid وint وlong وstring [1]. يقدم محرك تطبيقات Google [2] أكبر مجموعة متنوعة من أنواع البيانات: بالإضافة إلى تقسيم البيانات الرقمية إلى int أو long أو float، فإنه يحدد أيضًا أنواع بيانات مخصصة مثل رقم الهاتف وعنوان البريد الإلكتروني والرمز الجغرافي والارتباط التشعبي. تتيح لك Google، ولكن ليس Amazon أو Microsoft، تحديد البيانات الوصفية التي من شأنها منع ربط السمات غير الصالحة بفئة معينة من الكيانات، من خلال السماح لك بإنشاء نموذج بيانات وصفية.

تتيح لك Google العمل على البيانات باستخدام مجموعة فرعية من SQL؛ وتقدم Microsoft صيغة استعلام تعتمد على عنوان URL يتم تجريدها عبر مزود LINQ ؛ وتقدم Amazon صيغة أكثر محدودية. ومن المثير للقلق أن الدعم المدمج لدمج كيانات مختلفة من خلال الانضمامات غير موجود حاليًا (أبريل 2010) مع جميع المحركات الثلاثة. يجب تنفيذ مثل هذه العمليات بواسطة كود التطبيق. قد لا يكون هذا مصدر قلق إذا كانت خوادم التطبيق موجودة في نفس موقع خوادم البيانات في مركز بيانات البائع، ولكن سيتم توليد قدر كبير من حركة المرور على الشبكة إذا تم فصل الاثنين جغرافيًا.

إن نهج EAV مبرر فقط عندما تكون السمات التي يتم نمذجتها عديدة ومتفرقة: إذا كانت البيانات التي يتم التقاطها لا تلبي هذا المتطلب، فإن نهج EAV الافتراضي لبائعي السحابة غالبًا ما يكون غير متوافق مع التطبيقات التي تتطلب قاعدة بيانات خلفية حقيقية (على عكس مجرد وسيلة لتخزين البيانات الدائمة). إن إعادة تركيب الغالبية العظمى من تطبيقات قواعد البيانات الحالية، والتي تستخدم نهجًا تقليديًا لنمذجة البيانات، على بنية سحابية من نوع EAV، يتطلب جراحة كبرى. اكتشفت Microsoft، على سبيل المثال، أن قاعدة مطوري تطبيقات قواعد البيانات الخاصة بها كانت مترددة إلى حد كبير في استثمار مثل هذا الجهد. لذلك، في عام 2010، أطلقت Microsoft عرضًا متميزًا، SQL Server Azure، وهو محرك علاقاتي كامل يمكن الوصول إليه عبر السحابة ويسمح بنقل تطبيقات قواعد البيانات الحالية بتغييرات متواضعة فقط. اعتبارًا من أوائل عشرينيات القرن الحادي والعشرين، تسمح الخدمة بأحجام قواعد بيانات مادية قياسية تصل إلى 8 تيرابايت، ^[35] مع توفر عروض "ضخمة الحجم" و"حاسمة للأعمال" أيضًا.

• نظام السمة والقيمة
• البيانات المرتبطة
• إطار وصف الموارد (RDF)
• الويب الدلالي
• تريبل ستور
• تغيير الأبعاد ببطء
• داتوميك