Method Article

تنفيذ استعلامات المتزايدة التعقيد في العلائقية (الخلية) و NoSQL (مونجودب وتوجد) تزايد حجم قواعد بيانات السجل الطبي الإلكتروني الموحد 13606 ISO/EN

DOI:

10.3791/57439

⸱

March 19th, 2018

 ,  ,  ,  , 
1Telemedicine and Information Society Department, Health Institute "Carlos III"

In This Article

Summary

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

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

Abstract

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

ويظهر هذا البحث بروتوكول تقييم التعقيد الحسابي للاستعلام عن علائقي وغير العلائقية (NoSQL (ليس فقط لغة الاستعلام الهيكلية)) توحيد نظم الصحة الإلكترونية سجل (السجل الطبي الإلكتروني) المعلومات الطبية قاعدة البيانات (DBMS). ويستخدم مجموعة من مضاعفة حجم قواعد البيانات الثلاث، أي قواعد البيانات تخزين 5000، 10000 و 20,000 واقعية موحدة مقتطفات السجل الطبي الإلكتروني، في ثلاثة أنظمة إدارة قاعدة البيانات المختلفة (DBMS): العلائقية الخلية كائن علائقي رسم الخرائط ذات الصلة (ORM)، NoSQL MongoDB المستندة إلى الوثيقة، ولغة التوصيف القابلة للتوسيع الأصلية موجودة NoSQL (XML).

حسبت مرات متوسط الاستجابة للاستفسارات المتزايدة التعقيد ستة، وأظهرت النتائج خطية وسلوك في الحالات NoSQL. في حقل NoSQL، يعرض MongoDB منحدر خطية تملق كثير مما موجود.

قد تكون أنظمة NoSQL أيضا أكثر ملائمة للحفاظ على نظم معلومات طبية موحدة نظراً للطبيعة الخاصة لسياسات تحديث المعلومات الطبية، والتي ينبغي أن لا يؤثر على اتساق وكفاءة من البيانات المخزنة في قواعد البيانات NoSQL.

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

Introduction

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

NoSQL (ليس فقط من SQL) نظم إدارة قواعد البيانات ظهرت مؤخرا كبديل لنظم إدارة قواعد البيانات العلائقية التقليدية (ردمبس). وقد سيطرت RDBMS بالطريقة التي تم تخزين البيانات في أنظمة قواعد البيانات على مدى عقود. وقد تضمن الجبر العلائقية مدروسة ومفهومة وحساب التفاضل والتكامل بكفاءة واتساق RDBMS1. نظم NoSQL لن تصبح بدائل لنظم العلائقية، ولكن يمكن أن تتصرف مفيد في وحدات سيناريو معينة وفي ظروف عدة.

بعض من هذه السيناريوهات الخاصة والظروف ستنشأ عند تصميم قاعدة البيانات استمرار نظم السجلات الصحية الإلكترونية (السجل الطبي الإلكتروني) المستخدمة لإدارة وتخزين المعلومات الطبية. وقد استخدمت كي يكون قابلاً للتشغيل المتداخل والمستدامة في الممارسة، العديد من المعايير الدولية مثل ISO/EN 13606 وأوبينيهر و HL72،،من34،5 لتوحيد مقتطفات السجل الطبي الإلكتروني.

وقد فصل عدة معايير مثل ISO/EN 13606 وأوبينيهر المعلومات والمعارف إلى مستويين مختلفين من التجريد، ممثلة بنموذج مرجع (RM) وهياكل البيانات الخاصة التي تسمى الأمثلة. غالباً ما يسمى هذا الفصل النموذج المزدوج وتسمح أنظمة السجل الطبي الإلكتروني أن تكون المعرفة لغوياً قابلاً للتشغيل المتداخل والطبية أن تتطور دون إعادة برمجة نظام السجل الطبي الإلكتروني بأكمله، ونتيجة لذلك، لأن الصيانة والمستدامة في الممارسة6 . ومع ذلك، يتطلب النموذج المزدوج المنفذة في نظم السجل الطبي الإلكتروني الموحد أن تنظيم المعلومات يتبع بنية معينة، وهذا له آثار عميقة في الطريق هو مستوى النظام باستمرار قاعدة البيانات المصممة7.

هو كائن علائقي رسم الخرائط (ORM)8 منهجية واحدة لتنفيذ نظام السجل الطبي الإلكتروني باستخدام نموذج قاعدة بيانات علائقية. خرائط ل ORM استفاضة بنية ملفات XML (لغة التوصيف الموسعة) مقتطفات السجل الطبي الإلكتروني الموحد المستخدمة من قبل النظام لقاعدة بيانات علائقية. بنيات ORM العديد من الجداول العلائقية مستفيض عقب بنية ملفات XML مقتطفات السجل الطبي الإلكتروني الموحد. ترتبط هذه الجداول العلائقية من خلال العديد من المفاتيح الخارجية والنظام الناتج قد لا تكون فعالة جداً.

وقد اقترحت عدة تحسينات ل ORM العلائقية. أوبينيهر في مسار العقدة +9 يقلل من عدد الجداول العلائقية بالأشجار الفرعية التسلسلية لاستخراج كل ملف XML إلى BLOBs (كائنات كبيرة ثنائية). ومع ذلك، يؤدي هذا التبسيط منطق استرجاع المعقدة، وإلحاق أضرار في بعض الاستعلامات المعقدة. ركبة رسم الخرائط العلائقية (الذراع)10 يقوم بإنشاء نموذج قاعدة بيانات مدفوعة بالأمثلة، بناء مخطط علائقية جديدة استناداً إلى التعيينات بين الأمثلة والجداول العلائقية. ونتيجة لذلك، يتم فقدان بعض المعلومات غير الطبية من استخراج السجل الطبي الإلكتروني.

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

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

كما أجريت تجارب التوافق من أجل مقارنة أداء العلائقية الخلية و NoSQL MongoDB DBMSs. وقد تم مقارنة بوصف التحسينات ل ORM (مسار العقدة + والذراع) أيضا استخدام النتائج المناسبة ذات الصلة من الأدب10.

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

Protocol

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

1-بناء الخلية DBMS علائقية لتخزين ثلاث قواعد بيانات مقتطفات السجل الطبي الإلكتروني الموحد الحجم مزدوجة

  1. استيراد W3C مخطط XML (World Wide Web Consortium) تناظر RM ISO/EN13606 وأنواع البيانات ISO21090 إلى 'جافا بيئة تطوير متكاملة' (بيئة التطوير المتكاملة).
    ملاحظة: ISO تقف "منظمة المعايير الدولية". EN تقف على "القواعد والمعايير الأوروبية".
  2. تنفيذ في جاكسب (ربط XML جافا) في المكونات في بيئة تطوير متكاملة؛ وهذا ينتج فئات Java المقابلة لهيكل العناصر في ملفات XML مقتطفات السجل الطبي الإلكتروني.
  3. العلامة يدوياً جاوة الطبقات المنتجة مع تسميات نقابة الصحفيين الأردنيين. هذه التسميات تشير إلى كارديناليتيس وغيرها من العلاقات بين الجداول العلائقية قاعدة بيانات الخلية.
  4. استيراد مكتبات النقابة (جافا استمرار API) في بيئة تطوير متكاملة وتنفيذ الأسلوب الذي يبني قاعدة بيانات الخلية من فئات Java المعلمة.
  5. إنشاء الدلائل الثلاثة مع خمسة آلاف، 10,000 و 20,000 واقعية مقتطفات السجل الطبي الإلكتروني ملفات XML.
  6. تنفيذ الأسلوب النقابة لتحميل مقتطف XML في DBMS الخلية على جميع المقتطفات من الدليل مقتطفات 5,000.
  7. كرر الخطوة 1، 6 مرتين، مرة واحدة مع الدليل مقتطفات 10,000 والدليل مقتطفات 20,000 مرة واحدة.

2-بناء DBMS NoSQL MongoDB لتخزين ثلاث قواعد بيانات مقتطفات السجل الطبي الإلكتروني الموحد الحجم مزدوجة

  1. عملية كل ثلاثة الدلائل التي تحتوي على خمسة آلاف، 10,000 و 20,000 واقعية السجل الطبي الإلكتروني مقتطفات ملفات XML مع برنامج قياسي لتحويل ملفات XML لملفات JSON، مثل json.org.XML. ينبغي أن يصدر ثلاثة دلائل مع خمسة آلاف، 10,000 و 20,000 ملفات JSON.
  2. بدء تشغيل واجهة "المستخدم الرسومية مونجودب" (واجهة المستخدم الرسومية، انظر الجدول للمواد).
  3. إطلاق MongoDB 2.6 الخادم تنفيذ البرنامج منجود من نافذة نظام دوس (نظام تشغيل القرص).
  4. قم بتوصيل "واجهة المستخدم الرسومية مونجودب" إلى ملقم مضيف باستخدام ميناء 27017.
    1. حدد من القائمة "الاتصال".
    2. اكتب اسماً للاتصال (على سبيل المثال 'الأول').
    3. اكتب localhost:27017 في مربع النص ملقم DB.
    4. اضغط على الزر "اتصال"؛ يجب أن تظهر شجرة مع قواعد البيانات الحالية على اليسار.
  5. بناء قاعدة بيانات تحتوي على السجل الطبي الإلكتروني الموحد 5,000 مقتطفات.
    1. انقر فوق اسم الاتصال في أعلى شجرة على اليسار.
    2. حدد من القائمة "ملف".
    3. اختر "إضافة قاعدة بيانات".
    4. قم بإدخال اسم قاعدة البيانات في مربع الحوار الذي يظهر.
    5. انقر فوق موافق.
  6. إنشاء مجموعة تحتوي على السجل الطبي الإلكتروني الموحد 5,000 مقتطفات.
    1. انقر فوق اسم قاعدة البيانات في شجرة على اليسار.
    2. اختر القائمة "قاعدة بيانات".
    3. اختر "أدكوليكتيون".
    4. أدخل اسم المجموعة في مربع الحوار الذي يظهر.
    5. انقر فوق " إنشاء".
    6. انقر فوق اسم المجموعة.
    7. حدد من القائمة "استيراد".
    8. اختر زر الاختيار ''JSON-شل مونغو//مونجوكسبورت ".
    9. انقر فوق "التالي".
    10. اضغط على الزر "إضافة ملفات المصدر".
    11. انتقل على الكمبيوتر باستخدام مربع الحوار.
    12. فتح الدليل الذي يحتوي 5,000 JSON استخراج الملفات.
    13. حدد كافة الملفات في الدليل.
    14. اضغط على الزر "فتح". يجب أن تظهر قائمة JSON الملفات في مربع الحوار استيراد.
    15. اضغط على "التالي"؛ تظهر معاينة للمجموعة الجديدة في قاعدة البيانات على اليسار.
    16. اضغط "التالي".
    17. اضغط على "بدء الاستيراد". التقدم المحرز في الاستيراد يظهر أسفل على اليسار، ويشير إلى العدد من الملفات المستوردة والوقت المنقضي.
  7. كرر الخطوتين 5 و 6 لبناء مجموعة من السجل الطبي الإلكتروني الموحد 10,000 مقتطفات.
  8. كرر الخطوتين 5 و 6 لبناء مجموعة من 20,000 السجل الطبي الإلكتروني الموحد مقتطفات.

3-بناء NoSQL توجد نظم إدارة قواعد البيانات "ثلاثة مزدوجة الحجم الموحد السجل الطبي الإلكتروني مقتطفات من قواعد بيانات مخزن"

  1. بدء تشغيل قاعدة بيانات موجودة .
  2. باستخدام رمز قاعدة البيانات، افتح العميل المشرف جافا.
  3. أدخل كلمة مرور المشرف.
  4. اضغط على الزر "اتصال".
  5. إنشاء مجموعة تحتوي على السجل الطبي الإلكتروني الموحد 5,000 مقتطفات.
    1. في شريط الأدوات، حدد من القائمة "إنشاء مجموعة جديدة".
    2. في مربع الحوار الذي يظهر، اكتب اسم المجموعة الجديدة.
    3. انقر فوق "قبول"؛ سوف تظهر مجموعة جديدة.
    4. حدد اسماً للمجموعة.
    5. في شريط الأدوات، حدد من القائمة "ملفات مخزن في قاعدة البيانات".
    6. انتقل على الكمبيوتر باستخدام مربع الحوار.
    7. حدد الدليل الذي يحتوي على XML 5000 موحدة استخراج ملفات.
    8. انقر فوق الزر "تحديد الملفات أو الدلائل لتخزين". لاحظ أن يظهر مربع حوار عرض التقدم، الملفات التي يتم تخزينها، والنسبة المئوية لقاعدة البيانات التي تم إنشاؤها.
  6. كرر الخطوة 5 لبناء مجموعة التي تحتوي على السجل الطبي الإلكتروني الموحد 10,000 مقتطفات.
  7. كرر الخطوة 5 لبناء مجموعة التي تحتوي على السجل الطبي الإلكتروني الموحد 20,000 مقتطفات.

4-تصميم وتنفيذ في قواعد البيانات العلائقية الخلية 3 6 زيادة تعقيد الاستعلامات

  1. تصميم الاستعلامات المتزايدة التعقيد ستة وفقا للأمثلة المستخدمة من مقتطفات السجل الطبي الإلكتروني.
  2. برنامج برنامج نصي SQL في الاستعلام الأول في قاعدة بيانات الخلية. يجب أن تتكيف SQL الخاصة بنية قاعدة بيانات الخلية بسبب توحيد المقاييس مقتطفات (الأمثلة). قاعدة بيانات الخرائط الهيكل كله من المقتطفات. ونتيجة استعلام SQL معقدة بدلاً من ذلك.
  3. تحديد السمات الخاصة بقواعد البيانات التي ستقوم بتسريع زمن الاستجابة للاستعلامات إذا كان فهرس بنيت عليها، ثم بناء مثل هذه الفهارس، وعلى الرغم من أن معظم الفهارس مضمنة تلقائياً قبل DBMS.
  4. إذا كان استعلام يحتاج مؤشر بني غير تلقائياً، بناء عليه يدوياً.
    1. الاتصال بخادم الخلية (تكميلية الشكل 1).
    2. حدد وانقر فوق اسم قاعدة البيانات على اليسار.
    3. حدد وانقر فوق الجدول العلائقية حيث يتواجد الحقل المفهرس.
    4. انقر فوق علامة التبويب "الهيكل".
    5. حدد وانقر فوق العمود حيث سيتم بناء الفهرس.
    6. انقر فوق "الفهرس". لاحظ أن تظهر الجملة SQL بناء الفهرس، وتظهر رسالة تفيد أنه تم بناء الجملة بنجاح.
  5. تنفيذ الاستعلام الأول.
    1. حدد وانقر فوق اسم قاعدة البيانات على اليسار.
    2. انقر فوق علامة التبويب "SQL".
    3. اكتب أو الصق التعليمة البرمجية SQL للاستعلام الأول (انظر تكميلية الشكل 2).
    4. اضغط على "متابعة". علما بأن يظهر على الشاشة الأولى من قائمة النتائج، جنبا إلى جنب مع رسالة مع وقت تنفيذ الاستعلام.
    5. كرر التنفيذ 5 مرات وحساب متوسط وقت الاستجابة.
  6. كرر الخطوة 5 مع استعلامات 2 إلى 6.
  7. القيام بالعملية برمتها ثلاث مرات، بخمسة آلاف، 10,000 و 20,000 مقتطفات قواعد البيانات.

5-تصميم وتنفيذ في قواعد بيانات NoSQL MongoDB 3 6 زيادة تعقيد الاستعلامات

  1. بدء تشغيل "واجهة المستخدم الرسومية مونجودب" (انظر الجدول للمواد).
  2. بدء تشغيل الملقم MongoDB 2.6 تنفيذ البرنامج منجود من نافذة نظام دوس (انظر تكميلية الشكل 3).
  3. اتبع الخطوة 2.4 للاتصال "واجهة المستخدم الرسومية مونجودب" إلى ملقم مضيف باستخدام ميناء 27017.
  4. حدد وقم بتوسيع قاعدة بيانات MongoDB على الجانب الأيسر.
  5. حدد المجموعة.
  6. انقر فوق القائمة "جمع" في شريط الأدوات.
  7. تنفيذ الاستعلام مونجودب الأولى.
    1. انقر نقراً مزدوجاً فوق الزر "منشئ الاستعلام".
    2. انقر نقراً مزدوجاً فوق "حقل الاستعلام" في "منشئ الاستعلام" في اليمين.
    3. كتابة مجال الاستعلام مونجودب في مربع نص حقل استعلام الفريق (انظر تكميلية الشكل 4).
    4. كتابة قيمة الاستعلام مونجودب في مربع نص قيمة الفريق الاستعلام.
      ملاحظة: هذا الاستعلام يجب أن يكون شيئا مثل {"ns3:EHRExtract.allCompositions.content.items.parts.parts.name.ns2:originalText. القيمة ":" ديسكريبسيون "}. ونقلت عن الحقل والقيمة ومفصولة بفاصلة منقوطة.
    5. انقر نقراً مزدوجاً فوق الحقل الإسقاط من "منشئ الاستعلام"
    6. كتابة هذا الإسقاط الأولى في مربع الإسقاط (انظر تكميلية الشكل 5).
    7. انقر نقراً مزدوجاً فوق الحقل الإسقاط لإضافة مربع نص عرض جديد.
    8. كتابة الإسقاط الثاني في مربع الإسقاط.
      ملاحظة: إسقاط تحديد جزء من المستند تم استردادها بواسطة الاستعلام. وهذه ينبغي أن تكون شيئا مثل {"ns3:EHRExtract. allCompositions.content.items.parts.parts.value.value ": 1} و {" ns3: EHRExtract.all Compositions.content.items.parts.parts.value.nullFlavor ": 1}
    9. انقر فوق الزر تشغيل الأزرق لتنفيذ الاستعلام.
    10. تصور رمز الاستعلام في علامة التبويب "رمز الاستعلام".
    11. عرض تفاصيل النتيجة في علامة تبويب التفسير: عدد من النتائج، ووقت التنفيذ في ميلي ثانية.
    12. عرض وتوسيع، ودراسة النتائج في علامة التبويب النتيجة.
    13. إذا كان مطلوباً مزيد من المعالجة للاستعلام، كتابة برنامج Java مع السائق جافا MongoDB مع الاستعلام وأسلوب معالجة النتائج.
    14. كرر التنفيذ 5 مرات وحساب متوسط وقت الاستجابة.
  8. الخطوة 5.7 2 المتبقية عن طريق الاستعلامات 6.
  9. كرر العملية برمتها في 5,000، وعشرة آلاف و 20,000 مقتطفات قواعد بيانات MongoDB.

6-تصميم وتنفيذ في 3 NoSQL توجد قواعد بيانات 6 زيادة تعقيد "الاستعلامات"

  1. إطلاق وجود نظم إدارة قواعد البيانات.
  2. فتح العميل المشرف جافا.
  3. اضغط على زر "الاتصال بقاعدة بيانات".
  4. حدد قاعدة البيانات، وانقر فوقه.
  5. انقر فوق القائمة "التشاور مع قاعدة البيانات باستخدام XPath"؛ يظهر مربع الحوار "التشاور".
  6. تنفيذ أول استعلام XPath (انظر تكميلية الشكل 6).
    1. اكتب أو الصق التعليمة البرمجية XPath الاستعلام الأول في الجزء العلوي من مربع الحوار.
    2. انقر فوق القائمة "Execute" في شريط الأدوات في مربع الحوار.
    3. عرض نتائج XML باستخدام علامة التبويب "XML" في الجزء السفلي من مربع الحوار.
    4. عرض عدد النتائج وتجميع ووقت التنفيذ في الجزء السفلي من مربع الحوار.
    5. كرر التنفيذ 5 مرات وحساب متوسط وقت الاستجابة.
  7. كرر الخطوة 6 لاستعلامات 2 إلى 6.
  8. القيام بالعملية برمتها ثلاث مرات، 5,000، مقتطفات 10000 و 20,000 توجد قواعد البيانات.

7-تصميم وتنفيذ "تجربة التزامن" باستخدام الخلية واستخراج قواعد بيانات MongoDB 5,000

ملاحظة: قاعدة بيانات موجودة، قد أزيلت من هذه التجربة في هذه المرحلة بسبب أسوأ أداء في التجارب السابقة.

  1. حدد الاستعلامات مع ثلاثة ردود وقت أقصر في التجارب السابقة باستخدام قواعد البيانات مقتطفات 5,000 (عادة تحت عدة ثوان).
  2. تحديد وإنشاء فهارس السمات المناسبة لهذه الاستفسارات، يدوياً إذا لزم الأمر.
  3. التطبيقات متعددة العمليات جافا البرنامج اثنين، أحدهما للخلية والآخر ل MongoDB؛ سيكون لدى كل تطبيق ثلاثة مؤشرات ترابط مختلفة ذات أولوية، واحدة لكل استعلام تحديد في الخطوة 1.
  4. تنفيذ وحساب وحدة المعالجة المركزية (وحدة المعالجة المركزية) استخدام التوزيع لكل مؤشر ترابط (الاستعلام).
  5. تنفيذ كل تطبيق متعددة العمليات، النقر فوق الزر execute خمس مرات خلال كل فترة 10-دقيقة، وحساب آخر المنفذة (الأولوية) الاستعلام عن متوسط الإنتاجية ومتوسط الوقت الاستجابة للاستعلامات الثلاثة.
  6. عرض الاستعلامات في التنفيذ، مع أولويات ووقت التنفيذ.
  7. يتم حساب متوسط الإنتاجية ومعدل وقت استجابة كل من الاستعلامات الثلاثة.

Results

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

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

أوقات الاستجابة متوسط الاستعلامات ستة في ثلاثة مضاعفة حجم قواعد البيانات في كل DBMS مبينة في الجداول 2-4. الأرقام 1-6 وتظهر نفس النتائج بيانيا (لاحظ أن المحاور العمودية باستخدام جداول مختلفة جداً في جميع أنحاء هذه الأرقام).

سلوك خطي قوية من التعقيد الحسابي يتضح طوال كافة الاستعلامات من قواعد البيانات NoSQL، على الرغم من أن بحذر المناسبة نظراً لحجم صغير نسبيا من 3 مجموعات البيانات المستخدمة. ومع ذلك، يظهر ORM قاعدة البيانات العلائقية على سلوك خطية غير واضحة. وقد قاعدة بيانات MongoDB منحدر تملق من قاعدة بيانات موجودة.

يمكن الاطلاع على النتائج بتحسين نظم العلائقية التي نوقشت في مقدمة نشرت في الأدب في الجدول 5. التحريف MongoDB النتائج من الجدول 3 مع استعلامات مشابهة وأحجام قاعدة بيانات النتائج الذراع من الجدول 5 يساوي كل نظم قواعد البيانات في Q1، ولكن تفضل مونجودب في Q3.

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

figure-results-1
الشكل 1 : حسابي تعقيد الخلية ل ORM، مونجودب، ووجود نظم إدارة قواعد البيانات للاستعلامات Q1 و Q4. هذا الرقم تم تعديله من7 باستخدام ترخيص Creative Commons (http://creativecommons.org/licenses/by/4.0/) ويبين أوقات الاستجابة بالثواني ل 5,000، تستخرج السجل الطبي الإلكتروني 10000 والحجم 20,000 قواعد البيانات لكل نظم إدارة قواعد البيانات والاستعلامات Q1 و Q4. الرجاء انقر هنا لمشاهدة نسخة أكبر من هذا الرقم-

figure-results-2
الشكل 2 : تعقيد حسابي ORM الخلية نظم إدارة قواعد البيانات للاستعلام Q2. يعرض هذا الشكل أوقات استجابة في ثانية ل 5,000، السجل الطبي الإلكتروني 10000 والحجم 20,000 استخراج قاعدة بيانات الخلية ORM للاستعلام Q2. الرجاء انقر هنا لمشاهدة نسخة أكبر من هذا الرقم-

figure-results-3
الشكل 3 : حسابي تعقيد مونجودب ووجود نظم إدارة قواعد البيانات للاستعلامات Q2 و Q5. وقد تم تعديل هذا الرقم من7 باستخدام ترخيص Creative Commons (http://creativecommons.org/licenses/قبل/4.0) ويبين أوقات الاستجابة بالثواني ل 5,000، تستخرج السجل الطبي الإلكتروني 10000، والحجم 20,000 قواعد البيانات لكل نظم إدارة قواعد البيانات والاستعلامات Q2 و Q5. الرجاء انقر هنا لمشاهدة نسخة أكبر من هذا الرقم-

figure-results-4
الشكل 4 : تعقيد حسابي ORM الخلية نظم إدارة قواعد البيانات للاستعلامات Q3 و Q5. يظهر أوقات الاستجابة بالثواني ل 5,000، تستخرج السجل الطبي الإلكتروني 10000 والحجم 20,000 قواعد البيانات لكل نظم إدارة قواعد البيانات والاستعلامات Q3 و Q5. الرجاء انقر هنا لمشاهدة نسخة أكبر من هذا الرقم-

figure-results-5
الشكل 5: تعقيد حسابي موجود ونظم إدارة قواعد البيانات مونجودب للاستعلام Q3. هذا الرقم تم تعديله من7 باستخدام ترخيص Creative Commons (http://creativecommons.org/licenses/قبل 4.0/) ويبين أوقات الاستجابة بالثواني ل 5,000، تستخرج السجل الطبي الإلكتروني 10000 والحجم 20,000 قواعد البيانات لكل نظم إدارة قواعد البيانات والاستعلام Q3. الرجاء انقر هنا لمشاهدة نسخة أكبر من هذا الرقم-

figure-results-6
الرقم 6 : حسابي تعقيد الخلية ل ORM، موجودة و MongoDB نظم إدارة قواعد البيانات للاستعلام Q6. هذا الرقم تم تعديله من7 باستخدام ترخيص Creative Commons (http://creativecommons.org/licenses/قبل 4.0/) ويبين أوقات الاستجابة بالثواني ل 5,000، تستخرج السجل الطبي الإلكتروني 10000 والحجم 20,000 قواعد البيانات لكل نظم إدارة قواعد البيانات والاستعلام Q6. الرجاء انقر هنا لمشاهدة نسخة أكبر من هذا الرقم-

الاستعلام
Q1العثور على جميع المشاكل لمريض واحد
Q2العثور على جميع المشاكل لجميع المرضى
Q3العثور على تاريخ الأولى وتاريخ القرار وشدة
لمشكلة واحدة لمريض واحد
س 4العثور على تاريخ الأولى وتاريخ القرار وشدة
لجميع المشاكل مشكلة مريض واحد
س 5العثور على تاريخ الأولى وتاريخ القرار وشدة
لكل مشكلة المشاكل لجميع المرضى
س 6العثور على جميع المرضى الذين يعانون من المشكلة 'التهاب البلعوم'،
الأولى تاريخ > = 16 أكتوبر 2007 '، تاريخ القرار
< = 5 يونيو 2008 'وشدة' عالي '

الجدول 1: تنفيذ الاستعلامات ستة على العلائقية و NoSQL قواعد بيانات السجل الطبي الإلكتروني الموحد الذي يتضمن مقتطفات عن مشاكل المرضى. هذا الجدول تم تعديله من7 باستخدام ترخيص Creative Commons (http://creativecommons.org/licenses/by/4.0/) ويظهر ستة تزايد تعقيد الاستعلامات يقوم على ثلاث قواعد بيانات الحجم المتزايد لكل DBMS التي أعرب عنها في الطبيعية اللغة.

ORM/الخليةمستندات 5000مستندات 10,000مستندات 20,000
س 1 (s)25.047432.6868170.7342
Q2 (s)0.01580.01470.0222
Q3 (s)3.38496.4225207.2348
س 4 (s)33.5457114.6607115.4169
س 5 (s)9.639374.376729.0993
س 6 (s)1.43822.4844183.4979
حجم قاعدة البيانات4.6 GB9.4 غيغابايت19.4 جيجابايت
مقتطفات المجموع500010,00020,000

الجدول 2: متوسط أوقات الاستجابة في ثوان الاستعلامات ستة في مضاعفة حجم قواعد البيانات الخلية ORM نظم إدارة قواعد البيانات العلائقية. هذا الجدول يبين ست مرات استجابة لكل استعلام لثلاثة مضاعفة الحجم قواعد البيانات باستخدام الخلية ORM نظم إدارة قواعد البيانات العلائقية وحجم ثلاث قواعد بيانات في الذاكرة.

مونجودبمستندات 5000مستندات 10,000مستندات 20,000الميل (*10exp(-6))
س 1 (s)0.0460.0570.12215.07
Q2 (s)34.518168.6945136.23296,780.99
Q3 (s)0.0480.0580.12014.81
س 4 (s)0.0520.061o.12414.81
س 5 (s)38.020275.4376149.9337460.85
س 6 (s)9.515318.556636.78051,817.68
حجم قاعدة البيانات1.95GB3.95GB7.95 جيجابايت
مقتطفات المجموع500010,00020,000

الجدول 3: متوسط أوقات استجابة في ثانية الاستعلامات ستة في مضاعفة حجم قواعد البيانات MongoDB NoSQL DBMS. هذا الجدول تم تعديله من7 باستخدام ترخيص Creative Commons (http://creativecommons.org/licenses/by/4.0/) ويبين أوقات استجابة ستة من كل استعلام لثلاثة مضاعفة الحجم قواعد البيانات باستخدام قاعدة بيانات MongoDB NoSQL وحجم الذاكرة قواعد البيانات الثلاث. ويرد أيضا انحدار خطي لكل استعلام.

موجودةمستندات 5000مستندات 10,000مستندات 20,000الميل (*10exp(-6))
س 1 (s)0.66083.78347.3022442.76
Q2 (s)60.7761129.3645287.36215,105.73
Q3 (s)0.69761.7714.1172227.96
س 4 (s)0.64453.76047.3216445.17
س 5 (s)145.3373291.2502597.721630,158.93
س 6 (s)68.3798138.9987475.266327,125.82
حجم قاعدة البيانات1.25GB2.54GB5، 12 غيغابايت
مقتطفات المجموع500010,00020,000

الجدول 4: متوسط أوقات استجابة في ثانية الاستعلامات ستة في مضاعفة حجم قواعد بيانات موجودة NoSQL DBMS. هذا الجدول تم تعديله من7 باستخدام ترخيص Creative Commons (http://creativecommons.org/licenses/by/4.0/) ويبين أوقات استجابة ستة من كل استعلام لثلاثة مضاعفة الحجم قواعد البيانات باستخدام NoSQL في وجود نظم إدارة قواعد البيانات وحجم الذاكرة ثلاث قواعد بيانات. ويرد أيضا انحدار خطي لكل استعلام.

ورقة الذراعذراع (s)مسار العقدة + (s)
Q1الاستعلام 2.10، 19124.866
Q3الاستعلام 3.10.27294.774
حجم قاعدة البيانات2.90GB43.87 جيجابايت
مقتطفات المجموع29,74329,743

الجدول 5: متوسط أوقات الاستجابة في ثوان استعلامات مماثلة إلى Q1 و Q3 لتحسين النظم العلائقية التي قدمت في 10 . هذا الجدول تم تعديله من7 باستخدام ترخيص Creative Commons (http://creativecommons.org/licenses/by/4.0/) ويظهر الاستعلامات معظم مماثلة اثنين Q1 و Q3 قدم في10 المقابلة لاثنين من أنظمة قواعد البيانات العلائقية محسنة وأوقات الاستجابة الخاصة بهم. وترد أيضا أحجام قاعدة بيانات اثنين.

ORM/الخليةسرعة النقلوقت الاستجابة
س 1 (s)4,711.600.0793
Q3 (s)4,711.600.1558
س 4 (s)4,711.600.9674

الجدول 6: متوسط الإنتاجية والاستجابة للوقت بالثواني للاستعلامات Q1، Q3 و Q4 الخلية ORM نظم إدارة قواعد البيانات العلائقية في التنفيذ المتزامن. هذا الجدول تم تعديله من7 باستخدام ترخيص Creative Commons (http://creativecommons.org/licenses/by/4.0/) ويظهر أعلى متوسط الإنتاجية من الاستعلامات الثلاثة واحد والمريض وأوقات استجابة متوسط الخاصة بهم في المتزامنة تنفيذ تجربة استخدام نظام الخلية ORM العلائقية.

مونجودبسرعة النقلوقت الاستجابة
س 1 (s)178,672.600.003
Q3 (s)178,672.600.0026
س 4 (s)178,672.600.0034

الجدول 7: متوسط الإنتاجية والاستجابة للوقت بالثواني للاستعلامات Q1، Q3 و Q4 MongoDB NoSQL DBMS في التنفيذ المتزامن. هذا الجدول تم تعديله من7 باستخدام ترخيص Creative Commons (http://creativecommons.org/licenses/by/4.0/) ويظهر أعلى متوسط الإنتاجية من الاستعلامات الثلاثة واحد والمريض وأوقات استجابة متوسط الخاصة بهم في المتزامنة تنفيذ تجربة استخدام نظام MongoDB NoSQL.

التكميلية الرقم 1: الصورة تظهر شاشة البرنامج الاتصال بخادم الخلية. اضغط هنا لتحميل هذا الرقم-

التكميلية الرقم 2: الصورة يظهر الواجهة SQL إلى الخلية الخادم حيث تمت كتابة استعلام SQL الأول- اضغط هنا لتحميل هذا الرقم-

التكميلية الرقم 3: بدأت MongoDB 2.6 مضيف الملقم استخدام إطار نظام DOS المنفذة منجود الخادم. اضغط هنا لتحميل هذا الرقم-

التكميلية الرقم 4: الصورة يظهر الاستعلام كتابتها في مربعات النص في "منشئ الاستعلام" كما هو موضح في الخطوات 5.7.1 عن طريق 5.7.4. ويوضح الصورة الخطوة 5.7.3. اضغط هنا لتحميل هذا الرقم-

التكميلية الرقم 5: الصورة يبين خطوة 5.7.6. اضغط هنا لتحميل هذا الرقم-

التكميلية الرقم 6: الصورة يوضح كتابة استعلام XPath في جزء زوبير من مربع الحوار- اضغط هنا لتحميل هذا الرقم-

Discussion

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

ويبين هذا البروتوكول أن نظم ORM العلائقية نقية لا يبدو عمليا بالنسبة للاستعلامات مريض واحد (Q1 و Q3 و Q4) منذ أوقات الاستجابة أبطأ، ربما بسبب ارتفاع عدد من الجداول العلائقية أداء العديد من عمليات ربط مكلفة، ونظرا نظام التخزين المستخدمة من قبل نوع معين من قاعدة البيانات. NoSQL قواعد البيانات تخزين البيانات بطريقة تستند إلى الوثيقة، بينما نظم العلائقية استخدام طريقة تستند إلى الجدول الذي ينتشر بكل وثيقة في جميع أنحاء قاعدة البيانات بأكملها. نظم NoSQL إظهار انحدار خطي، مع مونجودب أداء أسرع بكثير من وجود نظم إدارة قواعد البيانات. بالتزامن، مونجودب أيضا سلوك أفضل بكثير من العلائقية ORM الخلية7.

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

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

تستخدم قواعد بيانات كبيرة جداً في المرحلة الثانوية (البحث)، وليس من الواضح أي نظام قاعدة البيانات هو أكثر ملاءمة، منذ المريض كافة الاستعلامات (Q2 و Q5) تتصرف في ORM من أفضل النظم NoSQL، ولكن هذه الأنظمة أداء أفضل من المبسطة العلائقية نظم في 12. ونحن نعتبر س 6 استخدام استعلام خاص بين الممارسة السريرية والثانوي السلوك الذي لا يمكن تحديد النتائج التي تنتج عن هذه التجارب.

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

هذا واحدة من المحاولات الأولى لمباشرة مقارنة علائقي ونظم NoSQL استخدام المعلومات الطبية الفعلية والواقعية وموحدة. ومع ذلك، يعتمد نظام محدد لاستخدامها كثير على السيناريو الفعلي ومشكلة يتعين حلها8.

Disclosures

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

الكتاب ليس لها علاقة بالكشف عن. مجموعات البيانات المستخدمة في هذه التجارب قدمت العديد من المستشفيات الإسبانية بموجب ترخيص لهذه التجارب ونتيجة لذلك ليست متاحة للجمهور. قدم مخطط XML RM 13606 ISO/EN "مركز جامعة كوليدج لندن" "المعلوماتية الصحية" والتعليم مولتيبروفيسيونال (الرنين).

Acknowledgements

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,

المؤلف يود أن يشكر الدكتور ديباك كالرا، قائد فرقة العمل آركوم تعريفه 13606 ISO/EN القياسية وفريقه من "جامعة كوليدج لندن" على الإذن الرقيقة باستخدام مخطط XML W3C 13606 ISO/EN.

هذا العمل كان يدعمه دي معهد الصحة كارلوس الثالث [منح أرقام PI15/00321، PI15/00003، PI1500831، PI15CIII/00010 و RD16CIII].

Materials

List of materials used in this article
NameCompanyCatalog NumberComments
MySQL 5.7.20تجارب MySQL
Hat Enterprise Linux Server الإصدار 7.4 (Maipo) ، 2.60 جيجاهرتز ، ذاكرة الوصول العشوائي 16 جيجابايت
MongoDB 2.6تجارب MongoDB
Windows 7 ، 2.66 جيجاهرتز ، ذاكرة الوصول العشوائي 12 جيجابايت   ؛
تجارب eXist 3.0RC1eXist
Windows 7 ، 2.66 جيجاهرتز ، ذاكرة وصول عشوائي 12 جيجابايت   ؛
Studio 3T 5.5.13T Software Labs GmbhMongoDB GUI
Red

References

$$\rightleftharpoonup{xx}$$ $$\longleftharp{xx}$$, $$\longrightharp{xx}$$,
  1. A relational model for large shared data banks. Comm ACM. 13 (6), 377-387 (1970).">Codd, E. F. A relational model for large shared data banks. Comm ACM. 13 (6), 377-387 (1970).
  2. ISO 13606 electronic health record communication part 1: reference model. , ISO. Geneva. ISO 13606-1 (2008).">Kalra, D., Lloyd, D. ISO 13606 electronic health record communication part 1: reference model. , ISO. Geneva. ISO 13606-1 (2008).
  3. Electronic health record communication part 2: archetype interchange specification. , ISO. Geneva. ISO 13606-2 (2008).">Kalra, D., et al. Electronic health record communication part 2: archetype interchange specification. , ISO. Geneva. ISO 13606-2 (2008).
  4. The openEHR foundation. Stud. Health Technol. Inform. 115, 153-173 (2005).">Kalra, D., Beale, T., Heard, S. The openEHR foundation. Stud. Health Technol. Inform. 115, 153-173 (2005).
  5. http://www.hl7.org (2017).">Health Level seven. Health Level Seven International. , Available from: http://www.hl7.org (2017).
  6. Archetypes: constraint-based domain models for future proof information systems. OOPSLA, Workshop Behav Semant. , (2002).">Beale, T. Archetypes: constraint-based domain models for future proof information systems. OOPSLA, Workshop Behav Semant. , (2002).
  7. Examining database persistence of ISO/EN 13606 standardized electronic health record extracts: relational vs. NoSQL approaches. BMC Medical Informatics and Decision Making. 32 (2), 493-503 (2017).">Sánchez-de-Madariaga, R., et al. Examining database persistence of ISO/EN 13606 standardized electronic health record extracts: relational vs. NoSQL approaches. BMC Medical Informatics and Decision Making. 32 (2), 493-503 (2017).
  8. Understanding object-relational mapping: a framework based approach. Int. J. Adv. Softw. 2, 202-216 (2009).">Ireland, C., Bowers, D., Newton, M., Waugh, K. Understanding object-relational mapping: a framework based approach. Int. J. Adv. Softw. 2, 202-216 (2009).
  9. https://openehr.atlassian.net/wiki/spaces/dev/pages/6553626/Node+Path+Persistence (2017).">Node+Path Persistence. , Available from: https://openehr.atlassian.net/wiki/spaces/dev/pages/6553626/Node+Path+Persistence (2017).
  10. Archetype relational mapping - a practical openEHR persistence solution. BMC Medical Informatics and Decision Making. 15, 88(2015).">Wang, L., Min, L., Wang, R., et al. Archetype relational mapping - a practical openEHR persistence solution. BMC Medical Informatics and Decision Making. 15, 88(2015).
  11. Managing data in healthcare information systems: many models, one solution. Computer. March. , 52-59 (2015).">Kaur, K., Rani, R. Managing data in healthcare information systems: many models, one solution. Computer. March. , 52-59 (2015).
  12. An innovative approach to manage heterogeneous information using relational database systems. Advances in Intelligent Systems and Computing. 557, Springer. (2017).">Sabo, C., Pop, P. C., Valean, H., Danciulescu, D. An innovative approach to manage heterogeneous information using relational database systems. Advances in Intelligent Systems and Computing. 557, Springer. (2017).

Reprints and Permissions

Request permission to reuse the text or figures of this JoVE article

Request Permission

Tags

Complexity Increasing QueriesRelational Database SystemsNoSQL Database SystemsMySQL MongoDB EXistElectronic Health RecordsDatabase Management SystemsComputational Complexity AnalysisResponse Time MeasurementDoubling Size DatabasesStandardized EHR Databases

Related Articles