• 0
HuSsAm Klhasan

Native XML Database

سؤال

مصطلح native XML database أو ما يسمى قواعد بيانات XML الأصلية ظهر أول مرة في الحملة التسويقية لشركة Tamino وبسبب نجاح هذه الحملة انتشر مفهوم قواعد بيانات الـ XML انتشارا واسعا.

قواعد بيانات XML الأصلية يجب أن تحقق ما يلي:

تعرف نموذج منطقي لمستندات الــ XML يقوم بتخزين واسترجاع المستندات ويجب أن يتضمن العناصر والخصائص (الصفات)والــ PCDATA ويأخذ بعين الاعتبار ترتيب المستند .من الأمثلة عن هذه النماذج XPath

مستند الـ XML هو الوحدة الأساسية للتخزين المنطقي لها تماما كما نجد في قواعد البيانات العلائقية أن السطر هو الوحدة الأساسية للتخزين المنطقي .

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

بنية قواعد البيانات Native XML:

يوجد نوعين من قواعد البيانات Native XML وفقا للبنية وهما text-based و model-based

Text-based : هي قواعد البيانات التي تخزن الــ XML كنص وذلك يمكن أن يكون ملف في نظام الملفات أو BLOB في قواعد البيانات العلائقية أو نمط تخزين نصي خاص (من المهم أن نلحظ أن قواعد البيانات التي أضافت دعم للــ XML من خلال CLOB Character Large Object تمثل قواعد بيانات XML أصلية )

من المعروف أن قواعد البيانات text-based native XML هي عبارة عن فهارس تسمح لمحرك الاستعلام أن يقفز بسهولة إلى أي نقطة من المستند مما يعطي هذه القواعد سرعة هائلة عند استرجاع المستندات أو أجزاء منها ويعود السبب في ذلك إلى وجود فهرس وحيد (index lookup) و وضع رأس القرص مرة واحدة وذلك بسبب أن الأجزاء الضرورية من المستند تخزن على بايتات متجاورة من القرص وبالتالي يتم استرجاع المستند أو أجزاء منه بعملية قراءة واحدة على عكس ما يتم في قواعد البيانات العلائقية أو بعض قواعد بيانات XML الأصلية من النمط model-based حيث يتم تجميع المستند من أجزاء مما يتطلب فهارس (index lookup) عديدة وكذلك عمليات قراءة متعددة.

قواعد بيانات XML الأصلية text-based مشابهة لقواعد البيانات الهيكلية (hierarchical) حيث كل منهما تفوق قواعد البيانات العلائقية في استرجاع البيانات وفقا لهيكلية معرفة مسبقا ولكنهما يمكن أن تواجها مشاكل في الأداء عند استرجاع البيانات بصيغ أخرى مثل عكس الهيكلية أو استرجاع جزء منها على الرغم من أن هذا الأمر غير مثبت بعد إلا أن قواعد البيانات العلائقية تسمح لكل الاستعلامات بنفس درجة التعقيد أن تنفذ بنفس الزمن .

Model-based : بدلا من تخزين مستند الـ XML كنص فإنه يتم بناء object model داخلي للمستند وتخزين هذا الــ model , كيفية تخزين هذا النموذج (model) تعتمد على قاعدة البيانات . بعض قواعد البيانات تخزن الــ model في قاعدة بيانات علائقية أو غرضية التوجه مثلا تخزين الـ DOM في قاعدة بيانات علائقية ينتج جداول مثل :

Elements, Attributes, PCDATA, Entities, EntityReferences

قواعد أخرى تستخدم أنماط تخزين خاصة بها.

قواعد بيانات model-based native XML المبنية على قواعد بيانات أخرى لها أداء مشابه لتلك القواعد .

أما قواعد بيانات model-based native XML التي تستخدم أنماط تخزين خاصة بها فأداؤها مشابه لــ text-based عند استرجاع البيانات بنفس الترتيب الذي خزنت به وذلك لأنها تستخدم مؤشرات فيزيائية بين العقد (text-based أسرع عند استرجاع المستندات كنص أما model-based فهي أسرع عند استرجاع المستند كأشجار DOM )و بأسلوب مشابه للــ text-based فإن الـــ model-based تواجه مشاكل عند محاولة استرجاع البيانات بترتيب مختلف عن الترتيب الذي خزنت فيه .

>>>>يتبع,, مميزات ,,,منتجات,,,,

اخواني ,,,,,

هنا بدأت مشاركتي تأخذ المنحى العلمي البحثي,,,

ماأذكره عبارة عن دراستي لمجموعة من الكتب ومقالات البحث العلمية في هذا المجال,,,

وعلى هذا فهي تحتمل الخطأ والصواب,,,

وللامانة أنا ساقوم بذكر المراجع المعتمدة والله ولي التوفيق,,,

السلام عليكم

2

شارك هذا الرد


رابط المشاركة
شارك الرد من خلال المواقع ادناه

4 إجابة على هذا السؤال .

  • 0

مشكور أخي HuSsAm Klhasan صاحب الموضوع .

و أضيف أن أهم قواعد البيانات (الأصلية) native XML databases المفتوحة المصدر هي :

  • BaseX
  • eXist
  • Senda
  • berkeley DB XML
  • و لتحميله انزل لأسفل صفحة التحميل و ميز بينه و بين قاعدة بيانات بيركيلي العادية الموجودة بأعلى صفحة التحميل .
  • Timber
  • TopX
  • TPOX

و يوجد العديد من ملفات الــXML التي يمكن التعامل معها مثل :

DBLP: و يمكن تحميلها من الموقع الأصلي هنا و هي قاعدة بيانات عن الأبحاث research papers و لدينا أيضا IMDB و هي تتحدث عن الأفلام و الممثلين فيها .

و بعد تحميل الملف كقاعدة بيانات يمكنك إنشاء فهارس لتسريع البحث و يوجد الكثير من الأبحاث التي تتحدث عن XML Indexing

و بعدها نقوم بالاستعلام من القاعدة باستخدام XQuery و XPath

2

شارك هذا الرد


رابط المشاركة
شارك الرد من خلال المواقع ادناه
  • 0

لماذا نحتاج إلى قواعد بيانات XML الأصلية :

الفائدة الأساسية لــ native XML databases من ناحية تطور الــ schema هي إمكانية تخزين مستندات مطابقة لنسخ متعددة ومختلفة من الــ schema .

وهذه يحقق ميزات تفوق قواعد البيانات العلائقية التي تتطلب أن تكون بياناتها متطابقة مع schema وحيدة :

يمكن تغيير الــ schema بدون حاجة إلى نقل البيانات كما هو الحال في قواعد البيانات العلائقية .بالنسبة للبيانات الضخمة أو عند الحاجة إلى تغيير الــ schema بشكل متكرر عملية النقل مكلفة جدا .كما أنه من غير الممكن دوما نقل البيانات .

من الممكن تغيير الــ schema بدون نقل البيانات , إذا أردنا إضافة حقل جديد ,في native xml database يمكن إضافة مستندات جديدة في نفس مجموعة المستندات القديمة أما في قواعد البيانات العلائقية فالبيانات الجديدة تخزن ي جدول جديد (عندما لا توجد إمكانية نقل البيانات )وبالتالي في nativeXML الاستعلامات على البيانات القديمة تبقى ممكنة أما في قواعد البيانات العلائقية فلا .

يمكن تخزين البيانات حتى لو كانت مطابقة لنسخة غير معروفة من الــ schema وبالتالي لن تضيع أي بيانات .

الفائدة الثانوية لــ native XML databases هي دعمها لــ XQUery ,التعابير الشرطية والتوابع المعرفة من قبل المستخدم في هذه اللغة تكون مفيدة جدا في الاستعلام عن مستندات متعددة الــ schema .

هذا لا يعني أن native XML databases تعالج كل مشاكل المتعلقة بتطور الــ schema ( تطور الــ schema يبقى مشكلة تتطلب التفكير والعمل المضني ) ,إلا أن هناك إجماع من المنتجين والزبائن على مرونة قواعد بيانات native XML توفر حلولا لم تكن ممكنة من قبل .

وفيما يلي نذكر بعض فوائد native XML databases :

إدارة البيانات المشتركة والمحلية Local and Shared data management : بشكل أساسي تستخدم QuiLogic's SQL/XML-IMDB لإدارة البيانات المحلية .بدلا من استخدام القوائم والأرتال يتم استخدام SQL/XML-IMDB لتخزين البيانات ذات مستويات مختلفة من التعقيد .مما يسمح بتعريف البنى بأسلوب تصريحي باستخدام XQuery و SQL .وبما أن SQL/XML-IMDB تدعم استخدام الذاكرة المشتركة يمكن استخدامها لمشاركة البيانات بين عدة معالجات .

Complete Web site : يمكن استخدام native XML database لبناء مواقع ويب ,يتم تخزين البيانات في قاعدة البيانات كــ XML والاستعلام عنها وتعديلها باستخدام XQuery وتحويلها إلى XHTML باستخدام XQuery أو XSLT .

الأداء performance : لاحظ المنتجون أن الزبائن لا يختارون native XML databases بسبب الأداء , ولكن الأداء يمثل مقياس ثانوي فالتطبيقات التي تستخدم document-centric XML أو بيانات semi-structured والتي كانت بالأصل تستخدم نظام ملفات أو قواعد بيانات علائقية انتقلت لاستخدام native XML databases لأسباب متعلقة بالمميزات التي تتمتع بها الأخيرة والأداء .

Mid-tier data cache : غالبا ماتستخدم قواعد البيانات native XML لتخبئة البيانات في طبق وسطى كما في تكامل البيانات و التجارة الالكترونية

(e-commerce) ومواقع الويب وذلك من أجل الأداء وأيضا إدارة البيانات بصيغة موحدة (XML) .

1

شارك هذا الرد


رابط المشاركة
شارك الرد من خلال المواقع ادناه
  • 0

مميزات native xml database:

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

Document Collection :

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

مثال أخر:بفرض أننا نخزن( manuals)طرق الاستخدام لمنتجات شركة في قاعدة بيانات أصيلة,في هذه الحالة ربما تريد أن تعرف هرمية مجموعات بحيث على سبيل المثال لديك مجموعة لكل منتج وخلال هذه المجموعة مجموعات للأقسام(chapters) لكل دليل استخدام manual ,المجموعات يمكن أن تتداخل اعتمادا على قاعدة البيانات.

Query Languages:

معظم قواعد البيانات الأصيلة تدعم واحدة أو أكثر من لغات الاستعلام والأكثر شيوعا منها xpath,xquery.

عندما نتكلم عن قاعدة بيانات أصيلة يجب أن نتأكد من أن لغة الاستعلام المستخدمة تلبي حاجاتنا من طر البحث والاستعلام وغيرها.

من الجدير ذكره انه حاليا وفي المستقل جميع قواعد البيانات الأصيلة ستدعم إلxquery المقدمة من w3c.

: Updates and Deletes

إن قواعد البيانات الأصيلة لديها عدة استراتيجيات متبعة من اجل عمليات الحذف والتعديل للمستندات من حذف أو استبدال مستند موجود إلى التعديل من خلال live Dom tree إلى لغات يمكنها تحديد كيف سنعدل أجزاء من المستند .

من الجدير بالذكر أن اغلب هذه الطرق هي proprietary. معظم اللغات المستخدمة في ذلك تتضمن دمج مابين:

Xupdate: وهي محققة في العديد من القواعد الحالية.

-مجموعة من التوسعات المقدمة لxquery والمقترحة من w3c والتي فيما بعد أصبحت الأساس للشكل القوا عدي لعمليات التحديث والتعديل في لغة xquery.

Transactions, Locking, and Concurrency:

بشكل افتراضي كل قواعد بيانات native XML تدعم transactions (ومن المحتمل أن تدعم rollbacks ) .

القفل locking يكون على مستوى المستند ككل وليس على مستوى العقد ولذلك التنافس قد يكون قليل نسبيا . هذا المفهوم يعتمد على التطبيق وعلى ما يحتويه المستند ,مثلاً :

• المستند عبارة عن فصل في كتاب ويقوم الكتاب بتحرير الفصول ,في هذه الحالة القفل على مستوى المستند لن يسبب مشاكل في التنافس فمن غير المحتمل أن يقوم كاتبان بتعديل نفس الفصل في نفس اللحظة .

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

• المستند يحتوي بيانات تستخدم في تدفق العمل , مثل العقود المالية.في كل خطوة من العمل يتم قراءة البيانات من المستند وإضافة بيانات جديدة .مثلا :في خطوة ما يتم فحص الرصيد وإضافة حاصل الرصيد إلى المستند , وفي خطوة أخرى يتم فحص الحسابات الجارية للعقود الأخرى لنفس الزبون وإضافة الحساب الجاري الكلي .إذا تم القفل على مستوى العقدة يمكن تنفيذ بعض هذه الخطوات على التفرع , أما إذا تم القفل على مستوى المستند فستنفذ هذه الخطوات تسلسليا ,مما يؤدي إلى تأخير غير مقبول في التطبيقات الضخمة .

المشكلة في القفل على مستوى العقدة هي كيفية التحقيق . قفل عقدة يتطلب قفل العقدة الأب لها وبالتالي قفل الأب للأخيرة أيضا وهكذا وصولا إلى الجذر مما يعني قفل المستند ككل .ولنشرح سبب ذلك : بفرض أن transation ما قام بقراءة عقدة ورقة بدون الحصول على قفل لسلف هذه العقدة وقام transaction آخر بحذف هذا السلف وبالتالي تلك الورقة .ومن الواضح أن المناقلات الأخرى يجب أن تكون قادرة على تعديل أجزاء أخرى من المستند لا تقع على المسار المباشر للورقة وتتفرع من نفس الجذر .

تم إيجاد حل جزئي لهذه المشكلة من قبل Stijn Dekeyser, etal , حيث لم تمنع مشكلة قفل عقد السلف تماما بل تم جعل عملية القفل أكثر مرونة بتعريف مسار العقد التي يجب قفلها وصولا إلى العقدة الهدف مما يتيح لأي transaction أن يتأكد من عدم حدوث تضارب مع الــ transactions الأخرى التي تملك أقفال.

عدد قليل فقط من قواعد بيانات native XML تدعم القفل على مستوى العقدة ولكن من المتوقع مستقبلا أن تدعم كل هذه القواعد هذا النوع من القفل .

Application Programming Interfaces (APIs)

قواعد البيانات الأصيلة تدعم مجموعة من application Programming Interfaces (APIs) والتي تكون بصيغة ODBC LIKE INTERFACE مع مجموعة من الدوال للاتصال بقاعدة المعطيات

واستكشاف الميتاداتا وتنفيذ الاستعلامات واسترجاع النتائج. النتائج تسترجع عادة كسلسلة xml string , أو dom tree,أو sax parserأو xmal reader من خلال المستند المعاد. بالنسبة للاستعلامات لتي تعيد عدة مستندات توجد دوال معينة للمرور على النتائج والتعامل معها.

بالرغم من أن قواعد البيانات الأصيلة تقدم دوال تتسم بالخاصية proprietary إلا انه وجدت حديثا مجموعة من المنتجات كالتالي:

,

Two vendor-neutral XML database APIs have been (are being) developed [July, 2004]:

• The XML:DB API from XML:DB.org is programming language-neutral, uses Path as its query language, and is being extended to support Query. It has been implemented by a number of native XML databases and may have been implemented over non-native databases as well.

• JSR 225: XQuery API for Java (XQJ) is based on JDBC and uses XQuery as its query language. It is being developed through Sun's Java Community Process (JCP) and a draft version is available. Because this initiative is being led by IBM and Oracle, its eventual wide-spread adoption seems likely.

معظم قواعد البيانات الأصيلة توفر دعم لتنفيذ استعلامات وإعادة نتائجها من خلال HTTP

: Round-Tripping

من أهم مميزات قواعد بيانات native XML هي أنها تستطيع أن تتنقل بشكل دائري على مستند الــ XML (round-trip) ,وهذا يعني إمكانية تخزين مستند الـ XML في القاعدة

ومن ثم استرجاعه منها .وهذه العملية مهمة للتطبيقات document-centric حيث مقاطع CDATA واستخدام entity والتعليقات ومعالجة التعليمات تمثل كامل المستند .

وهي مهمة أيضا للتطبيقات القانونية والطبية حيث نسخ طبق الأصل من المستندات .

الــ Round-Tripping أقل أهمية بالنسبة للتطبيقات data-centric والتي تهتم فقط بالعناصر والخصائص والنص والترتيب الهرمي .

كل البرمجيات التي تنقل البيانات بين مستندات XML وقواعد البيانات يمكن أن تعمل round-trip للعناصر السابقة .

كل قواعد البيانات native XML يمكن أن تعمل round-trip للمستندات على مستوى العناصر والخصائص وPCDATA و ترتيب المستند ,وبعض القواعد توفر أكثر من ذلك .

قواعد البيانات text-based native XML تعمل round-trip للمستند تماما,بينما قواعد البيانات model-based native XML تعمل round-trip للمستندات على مستوى document model .

بما أن عملية round-trip تعتمد على التطبيق فيمكن أن تكون الخيارات أمامنا مفتوحة أو ضيقة لاختيار قاعدة بيانات native XML .

: Remote Data

بعض قواعد البيانات الأصيلة يمكن أن تتضمن بيانات بعيدة في المستندات المخزنة ضمنها.

وهذه البيانات عادة تكون مسترجعة من قاعدة بيانات علاثقية(ODBC ,OLE DB)ونمذجت باستخدام(TABLE BASED MAPPING, OBJECT RELATIONAL MAPPING)ٍ.

-لتحقيق مفهوم البيانات البعيدة لذا فان التعديل في قاعدة البيانات الأصيلة يجب أنا يكون له تعديل مقابل على قاعدة البيانات العلائقية والتي هي عبارة عن القاعدة المصدر التي تم استرجاع البيانات منها.معظم قواعد البيانات الأصيلة من المكن أن تور دعم لهذا المفهوم.

Indexes:

كل قواعد البيانات الأصيلة تدعم مفهوم الفهرسة لتزيد من سرعة الاستعلام, يوجد لدينا ثلاثة أنواع من الفهارس

VALUE INDEXEمفهرس القيمة:

"Find all elements or attributes whose value is 'Santa Cruz'."

STRUCTURAL INDXEمفهرس البنيوي:

"Find all Address elements."

يمكن حل هذا الاستعلام باستخدام مفهرس القيمة والمفهرس البنيوي

"Find all City elements whose value is 'Santa Cruz'."

FULL-TEXT INDEXE:

"Find all documents that contain the words 'Santa Cruz',"

يمكن حل هذا الاستعلام باستخدام مفهرس النصي والمفهرس البنيوي

"Find all documents that contain the words 'Santa Cruz' inside an Address element."

-معظم قواعد البيانات الأصيلة تدعم مفهرس القيم والمفهرس البنيوي وبعضها يدعم FULL-TEXT INDEXE

External Entity Storage: ٍ

السؤال الصعب عند تخزين مستندات الــ XML هو كيف سنتعامل مع الكائنات الخارجية .هل يجب توسعتها وتخزين قيمها في نهاية المستند أم يجب أن نخزن مراجع لهذه الكائنات ؟؟ هناك عدة إجابات لهذا السؤال :

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

مثال آخر : ليكن لديناproduct manual والذي يحتوي فقط مراجع لكائنات خارجية توضح فصول الـ manual .

لو كانت هذه الفصول مستخدمة في مستندات أخرى مثلا manuals لموديلات مختلفة من المنتج , عندها سيكون من الخطأ تخزين القيم التي تشير إليها هذه المراجع لأن ذلك سيؤدي إلى نسخ متعددة من نفس الفصول .

السلام عليكم,,,

تم تعديل بواسطه HuSsAm Klhasan
2

شارك هذا الرد


رابط المشاركة
شارك الرد من خلال المواقع ادناه
  • 0

أدرج هنا رابط لمجموعة من قواعد البيانات الأصيلة

Native XML Products

الرابط

0

شارك هذا الرد


رابط المشاركة
شارك الرد من خلال المواقع ادناه

من فضلك سجل دخول لتتمكن من التعليق

ستتمكن من اضافه تعليقات بعد التسجيل



سجل دخولك الان

  • يستعرض القسم حالياً   0 members

    لا يوجد أعضاء مسجلين يشاهدون هذه الصفحة .