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

الموسوعة الحرة

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

بنية البيانات

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

يتم تسجيل البيانات في ثلاثة أعمدة:

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

مثال

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

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

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

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

كيانيصفقيمة
⟨المريض 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:

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

Certain ("hybrid") classes have some attributes that are non-sparse (present in all or most instances), while other attributes are highly variable and sparse. The latter are suitable for EAV modeling. For example, descriptions of products made by a conglomerate corporation depend on the product category, e.g., the attributes necessary to describe a brand of light bulb are quite different from those required to describe a medical imaging device, but both have common attributes such as packaging unit and per-item cost.

Description of concepts

The entity

In clinical data, the entity is typically a clinical event, as described above. In more general-purpose settings, the entity is a foreign key into an "objects" table that records common information about every "object" (thing) in the database – at the minimum, a preferred name and brief description, as well as the category/class of entity to which it belongs. Every record (object) in this table is assigned a machine-generated object ID.

The "objects table" approach was pioneered by Tom Slezak and colleagues at Lawrence Livermore Laboratories for the Chromosome 19 database, and is now standard in most large bioinformatics databases. The use of an objects table does not mandate the concurrent use of an EAV design: conventional tables can be used to store the category-specific details of each object.

The major benefit to a central objects table is that, by having a supporting table of object synonyms and keywords, one can provide a standard Google-like search mechanism across the entire system where the user can find information about any object of interest without having to first specify the category that it belongs to. (This is important in bioscience systems where a keyword like "acetylcholine" could refer either to the molecule itself, which is a neurotransmitter, or the biological receptor to which it binds.)

The attribute

In the EAV table itself, this is just an attribute ID, a foreign key into an Attribute Definitions table, as stated above. However, there are usually multiple metadata tables that contain attribute-related information, and these are discussed shortly.

The value

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

تاريخ

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

على الرغم من عدم وجود صلة مباشرة بين تقنية EAV وأزواج AV، يبدو أن ستيد وهاموند كانا أول من فكر في استخدامها للتخزين الدائم للبيانات المعقدة بشكل تعسفي. [ 3 ] كانت أنظمة السجلات الطبية الأولى التي استخدمت تقنية EAV هي السجل الطبي الإلكتروني Regenstrief (الذي قاده كليمنت ماكدونالد)، [ 4 ] ونظام TMR (السجل الطبي) الذي طوره ويليام ستيد وإد هاموند، ومستودع البيانات السريرية HELP (CDR) الذي أنشأه فريق هومر وارنر في مستشفى LDS، مدينة سولت ليك، يوتا. [ 5 ] [ 6 ] (استخدم نظام ريجنستريف في الواقع تصميمًا يعتمد على المريض والسمة والطابع الزمني والقيمة: حيث دعم استخدام الطابع الزمني استرجاع القيم لمريض/سمة معينة بترتيب زمني). طُوّرت جميع هذه الأنظمة في سبعينيات القرن الماضي، قبل توفر الأنظمة التجارية القائمة على نموذج قاعدة البيانات العلائقية لإي إف كود ، على الرغم من أن نظام HELP نُقل لاحقًا إلى بنية علائقية وسُوّق تجاريًا من قِبل شركة 3M. (تجدر الإشارة إلى أنه على الرغم من نشر ورقة كود الرائدة عام 1970، إلا أن أسلوبها الرياضي المُعقد كان له أثر سلبي في تقليل سهولة فهمها لدى غير المتخصصين في علوم الحاسوب، وبالتالي تأخير قبول النموذج في أوساط تكنولوجيا المعلومات وموردي البرمجيات. ولا يُمكن المُبالغة في تقدير قيمة مساهمة كريستوفر جيه ديت ، زميل كود في شركة IBM، في ترجمة هذه الأفكار إلى لغة سهلة الفهم، مصحوبة بأمثلة بسيطة تُوضح قوتها).

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

كان نظام إدارة بيانات الدراسات السريرية مفتوح المصدر TrialDB الذي طوره نادكارني وآخرون أول نظام يستخدم جداول 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/CR: تمثيل البنية الفرعية بالفئات والعلاقات

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

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

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

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

البيانات الوصفية

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

تُسهّل البيانات الوصفية التفاعل مع النظام من منظور منطقي بدلاً من المنظور المادي، حيث يستشير البرنامج البيانات الوصفية باستمرار لإجراء عمليات متنوعة مثل عرض البيانات، والتحقق التفاعلي، واستخراج البيانات بكميات كبيرة، والاستعلام المخصص . ويمكن استخدام البيانات الوصفية لتخصيص سلوك النظام.

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

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

Where an EAV system is implemented through RDF, the RDF Schema language may conveniently be used to express such metadata. This Schema information may then be used by the EAV database engine to dynamically re-organize its internal table structure for best efficiency.[15]

Some final caveats regarding metadata:

  • Because the business logic is in the metadata rather than explicit in the database schema (i.e., one level removed, compared with traditionally designed systems), it is less apparent to one who is unfamiliar with the system. Metadata-browsing and metadata-reporting tools are therefore important in ensuring the maintainability of an EAV system. In the common scenario where metadata is implemented as a relational sub-schema, these tools are nothing more than applications built using off-the-shelf reporting or querying tools that operate on the metadata tables.
  • It is easy for an insufficiently knowledgeable user to corrupt (i.e., introduce inconsistencies and errors in) metadata. Therefore, access to metadata must be restricted, and an audit trail of accesses and changes put into place to deal with situations where multiple individuals have metadata access. Using an RDBMS for metadata will simplify the process of maintaining consistency during metadata creation and editing, by leveraging RDBMS features such as support for transactions. Also, if the metadata is part of the same database as the data itself, this ensures that it will be backed up at least as frequently as the data itself, so that it can be recovered to a point in time.
  • The quality of the annotation and documentation within the metadata (i.e., the narrative/explanatory text in the descriptive columns of the metadata sub-schema) must be much higher, in order to facilitate understanding by various members of the development team. Ensuring metadata quality (and keeping it current as the system evolves) takes very high priority in the long-term management and maintenance of any design that uses an EAV component. Poorly documented or out-of-date metadata can compromise the system's long-term viability.[16][17]

Information captured in metadata

Attribute metadata

  • Validation metadata include data type, range of permissible values or membership in a set of values, regular expression match, default value, and whether the value is permitted to be null. In EAV systems representing classes with substructure, the validation metadata will also record what class, if any, a given attribute belongs to.
  • بيانات العرض الوصفية : كيفية عرض السمة للمستخدم (مثلاً، كمربع نص أو صورة بأبعاد محددة، أو قائمة منسدلة، أو مجموعة من أزرار الاختيار). عندما يتكون كائن مركب من سمات متعددة، كما هو الحال في تصميم EAV/CR، توجد بيانات وصفية إضافية حول ترتيب عرض السمات، وكيفية تجميع هذه السمات اختيارياً (تحت عناوين وصفية).
  • بالنسبة للسمات التي تصادف أنها معايير مختبرية، يتم تسجيل نطاقات القيم الطبيعية ، والتي قد تختلف باختلاف العمر والجنس والحالة الفسيولوجية وطريقة التحليل.
  • بيانات التجميع الوصفية : تُعرض السمات عادةً كجزء من مجموعة ذات مستوى أعلى، مثل نموذج خاص بتخصص معين. تتضمن بيانات التجميع الوصفية معلومات مثل ترتيب عرض السمات. بعض بيانات العرض الوصفية، مثل الخطوط/الألوان وعدد السمات المعروضة في كل صف، تنطبق على المجموعة ككل.

بيانات تعريف التحقق المتقدمة

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

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

سيناريوهات الاستخدام

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

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

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

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

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

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

نمذجة السمات المتفرقة

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

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

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

نمذجة العديد من الفئات مع عدد قليل جدًا من الحالات لكل فئة: مخططات ديناميكية للغاية

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

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

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

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

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

العمل مع بيانات المركبات الجوية الكهربائية

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

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

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

التقسيم العلائقي

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

تحسين أداء التمحور

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

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

البدائل

EAV مقابل نموذج البيانات العالمي

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

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

XML و JSON

يمكن لتطبيق 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 بشكل منفصل عن الجداول، باستخدام استعلامات XPath كجزء من عبارات SQL، أو في PostgreSQL ، مع نوع بيانات JSON [ 28 ] الذي يمكن فهرسته والاستعلام عنه. تُحقق هذه التطورات نموذج EAV أو تُحسّنه أو تُستبدله.

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

قواعد بيانات الرسوم البيانية

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

وثمة بديل آخر يتمثل في استخدام مخزن SPARQL .

اعتبارات خاصة ببرامج الخوادم

PostgreSQL: أعمدة JSONB

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

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

SQL Server 2008 والإصدارات الأحدث: الأعمدة المتفرقة

يُقدّم Microsoft SQL Server 2008 بديلاً (خاصاً) لـ EAV. [ 33 ] يُمكن تحديد الأعمدة ذات نوع البيانات الذري (مثل الأعمدة الرقمية أو النصية أو أعمدة التاريخ والوقت) على أنها أعمدة متفرقة ببساطة عن طريق تضمين كلمة SPARSE في تعريف العمود في عبارة CREATE TABLE. تُحسّن الأعمدة المتفرقة تخزين القيم الفارغة (التي لا تشغل أي مساحة على الإطلاق) وتُفيد عندما تحتوي غالبية السجلات في الجدول على قيم فارغة لهذا العمود. كما يتم تحسين الفهارس على الأعمدة المتفرقة: حيث يتم فهرسة الصفوف التي تحتوي على قيم فقط. بالإضافة إلى ذلك، يُمكن تجميع محتويات جميع الأعمدة المتفرقة في صف مُحدد من الجدول في عمود 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 من أمازون، يقتصر نوع البيانات على السلاسل النصية، ويجب تحويل البيانات غير النصية بطبيعتها إلى سلاسل نصية (مثل إضافة أصفار بادئة للأرقام) لإجراء عمليات مثل الفرز. أما Windows Azure Table Storage من مايكروسوفت، فيُقدّم مجموعة محدودة من أنواع البيانات: byte[]، bool، DateTime، double، Guid، int، long، وstringمحرك تطبيقات جوجليُقدّم جوجل أكبر تشكيلة من أنواع البيانات: فبالإضافة إلى تقسيم البيانات الرقمية إلى أعداد صحيحة (int) وأعداد صحيحة طويلة (long) وأعداد عشرية (float)، يُعرّف أيضًا أنواع بيانات مخصصة مثل رقم الهاتف وعنوان البريد الإلكتروني والرمز الجغرافي والرابط التشعبي. يُتيح جوجل، دون أمازون أو مايكروسوفت، إمكانية تحديد بيانات وصفية تمنع ربط سمات غير صالحة بفئة معينة من الكيانات، وذلك من خلال السماح بإنشاء نموذج بيانات وصفية.

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

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

انظر أيضاً

مراجع

  1. ↑ مؤسسة البرمجيات الحرة (10 يونيو 2007)، دليل مرجعي للغة GNU Emacs Lisp ، بوسطن، ماساتشوستس: مؤسسة البرمجيات الحرة، ص.  القسم 5.8، "قوائم الارتباط"، مؤرشف من الأصل في 20 أكتوبر 2011
  2. ↑ مؤسسة أباتشي، دروس UIMA وأدلة المستخدمين. الرابط: http://uima.apache.org/downloads/releaseDocs/2.1.0-incubating/docs/html/tutorials_and_users_guides/tutorials_and_users_guides.html . تاريخ الوصول: أكتوبر 2012.
  3. ↑ ستيد، دبليو دبليو؛ هاموند، دبليو إي؛ ستراوب، إم جيه (1982)، "سجل بدون مخططات - هل هو كافٍ؟"، وقائع الندوة السنوية حول تطبيقات الحاسوب في الرعاية الطبية ، 7 (2 نوفمبر 1982): 89-94 ، doi : 10.1007/BF00995117 ، PMC 2580254 ، PMID 6688264  
  4. ↑ ماكدونالد، سي جيه؛ بليفنز، إل؛ تيرني، دبليو إم؛ مارتن، دي كيه (1988)، "سجلات ريجنستريف الطبية"، الحوسبة الطبية ، 5 (5): 34-47 ، PMID 3231034 
  5. ↑ براير، تي. ألان (1988). "نظام السجلات الطبية HELP". الحوسبة الطبية . 5 (5): 22-33 . PMID 3231033 . 
  6. ↑ وارنر، إتش آر؛ أولمستيد، سي إم؛ روثرفورد، بي دي (1972)، "HELP - برنامج لاتخاذ القرارات الطبية"، مجلة أبحاث الحوسبة الطبية الحيوية ، 5 (1): 65-74 ، doi : 10.1016/0010-4809(72)90007-9 ، PMID 4553324 
  7. ↑ فريدمان، كارول؛ هريبساك، جورج؛ جونسون، ستيفن ب.؛ سيمينو، جيمس ج.؛ كلايتون، بول د. (1990)، "مخطط علائقي معمّم لقاعدة بيانات متكاملة للمرضى السريريين"، وقائع الندوة السنوية حول تطبيقات الحاسوب في الرعاية الطبية : 335-339 ، PMC 2245527 
  8. 1 2 نادكارني، براكاش م.؛ مارينكو، لويس؛ تشين، رولاند؛ سكوفوس، إيمانويل؛ شيبرد، جوردون؛ ميلر، بيري (1999)، "تنظيم البيانات العلمية غير المتجانسة باستخدام تمثيل EAV/CR"، مجلة الجمعية الأمريكية للمعلوماتية الطبية ، 6 (6): 478-493 ، doi : 10.1136/jamia.1999.0060478 ، PMC 61391 ، PMID 10579606  
  9. 1 2 مارينكو، لويس؛ توشيس، نيكولاس؛ كراستو، تشيكيتو؛ شيبرد، جوردون؛ ميلر، بيري ل.؛ نادكارني، براكاش م. (2003)، "تحقيق تطبيقات علوم الحياة القابلة للتطوير باستخدام إطار عمل EAV/CR: التطورات الحديثة"، مجلة الجمعية الأمريكية للمعلوماتية الطبية ، 10 (5): 444-53 ، doi : 10.1197/jamia.M1303 ، PMC 212781 ، PMID 12807806  
  10. ↑ وزارة شؤون المحاربين القدامى: إدارة صحة المحاربين القدامى. مؤرشف بتاريخ 21 فبراير 2006 في أرشيف الإنترنت (Wayback Machine).
  11. ↑
  12. ↑ نادكارني، ب.م.؛ مارينكو، ل.؛ تشين، ر.؛ سكوفوس، إ.؛ شيبرد، ج.؛ ميلر، ب. (1999)، "تنظيم البيانات العلمية غير المتجانسة باستخدام تمثيل EAV/CR"، مجلة الجمعية الأمريكية للمعلوماتية الطبية ، 6 (6): 478-493 ، doi : 10.1136/jamia.1999.0060478 ، PMC 61391 ، PMID 10579606  
  13. ↑ مارينكو، ل؛ توشيس، ن؛ كراستو، س؛ شيبرد، ج؛ ميلر، ب ل؛ نادكارني، ب م (2003)، "تحقيق تطبيقات علوم الحياة القابلة للتطوير باستخدام إطار عمل EAV/CR: التطورات الحديثة"، مجلة الجمعية الأمريكية للمعلوماتية الطبية ، 10 (5): 444-453 ، doi : 10.1197/jamia.M1303 ، PMC 212781 ، PMID 12807806  
  14. 1 2 3 دينو، فالنتين؛ نادكارني، براكاش؛ براندت، سينثيا (2006)، "أساليب التمحور لاستخراج بيانات الكيان-السمة-القيمة بكميات كبيرة"، أساليب وبرامج الحاسوب في الطب الحيوي ، 82 (1): 38-43 ، doi : 10.1016/j.cmpb.2006.02.001 ، PMID 16556470 
  15. ↑ GB 2384875 ، دينجلي، أندرو بيتر، "تخزين وإدارة البيانات شبه المهيكلة"، نُشر في 6 أغسطس 2003، مُسجل باسم شركة هيوليت باكارد 
  16. ↑ نادكارني، براكاش م. (9 يونيو 2011). أنظمة البرمجيات القائمة على البيانات الوصفية في الطب الحيوي: تصميم أنظمة قادرة على التكيف مع المعرفة المتغيرة . سبرينغر. ISBN 978-0857295095.
  17. ↑ نادكارني، براكاش (2011)، أنظمة البرمجيات القائمة على البيانات الوصفية في الطب الحيوي ، سبرينغر، ISBN 978-0-85729-509-5
  18. ↑ دينو، فالنتين؛ نادكارني، براكاش (2007)، "إرشادات للاستخدام الفعال لنمذجة الكيان-السمة-القيمة لقواعد البيانات الطبية الحيوية"، المجلة الدولية للمعلوماتية الطبية ، 76 ( 11-12 ): 769-779 ، doi : 10.1016/j.ijmedinf.2006.09.023 ، PMC 2110957 ، PMID 17098467  
  19. ↑ كايت، توماس. أوراكل الفعّالة بالتصميم. دار نشر أوراكل، ماكجرو هيل أوزبورن ميديا. ٢١ أغسطس ٢٠٠٣. http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:10678084117056
  20. ↑ "Oracle Health Sciences Clintrial - Oracle" . www.oracle.com .
  21. ↑ "Oracle Clinical - نظرة عامة - Oracle" . www.oracle.com .
  22. ↑ "انقسام علائقي حول EAV" .
  23. ↑ ديفيد ماير، جيفري أولمان، موشيه فاردي. حول أسس نموذج العلاقة الشاملة. معاملات ACM لأنظمة قواعد البيانات (TODS). المجلد 9، العدد 2، يونيو 1984. الصفحات 283-308. الرابط: http://dl.acm.org/citation.cfm?id=318580
  24. ↑ حول تصميم قواعد البيانات الشاملة. في "مقدمة في أنظمة قواعد البيانات"، الطبعة الثامنة، بيرسون/أديسون ويسلي، 2003.
  25. ↑ مورفي، إس إن؛ ويبر، جي؛ مينديس، إم؛ غينر، في؛ تشويه، إتش سي؛ تشرشل، إس؛ كوهان، آي (2010)، "خدمة المؤسسة وما وراءها بالمعلوماتية لدمج علم الأحياء والرعاية السريرية (i2b2)"، مجلة الجمعية الأمريكية للمعلوماتية الطبية ، 17 (2): 124-130 ، doi : 10.1136/jamia.2009.000893 ، PMC 3000779 ، PMID 20190053  
  26. 1 2 إيتزيك بن غان، ديجان ساركا، داخل مايكروسوفت إس كيو إل سيرفر 2008: برمجة تي-إس كيو إل (مايكروسوفت برس)
  27. 1 2 جيرون كوسيمانت، " استبدال EAV بـ JSONB في PostgreSQL " (2016)
  28. ↑ Postgres 9.6، " أنواع JSON "
  29. ↑ TinkerPop، أباتشي. "Apache TinkerPop" . tinkerpop.apache.org .
  30. ↑ "مطابقة الأنماط - OpenCog" . wiki.opencog.org .
  31. ↑ " JsQuery – لغة استعلام JSON مع دعم فهرسة GIN " (2014)
  32. ↑ " مشروع 7cart - بديل مستقبلي لـ Shopify و Magento " (2019)
  33. ↑ بيهام (28 فبراير 2023). "استخدام الأعمدة المتفرقة" . msdn.microsoft.com .
  34. ↑ جينينغز، روجر (2009)، "تقاعد مركز البيانات الخاص بك"، مجلة فيجوال ستوديو ، فبراير 2009: 14-25
  35. ↑ "حدود الموارد - مثيل Azure SQL المُدار" . 20 يونيو 2023.