قاعدة بيانات الملاحة
قاعدة البيانات الملاحية هي نوع من قواعد البيانات التي يتم فيها العثور على السجلات أو الكائنات بشكل أساسي من خلال تتبع المراجع من كائنات أخرى. وقد شاع هذا المصطلح بفضل عنوان ورقة تشارلز باخمان البحثية الحائزة على جائزة تورينج عام 1973 ، بعنوان "المبرمج كملاح" . [ 1 ] أكدت هذه الورقة البحثية على حقيقة أن أنظمة قواعد البيانات الجديدة القائمة على الأقراص تسمح للمبرمج باختيار مسارات ملاحية عشوائية تتبع العلاقات من سجل إلى آخر، على عكس قيود أنظمة الأشرطة المغناطيسية والبطاقات المثقبة السابقة حيث كان الوصول إلى البيانات تسلسليًا بشكل صارم.
كانت قاعدة البيانات المتكاملة (IDS) واحدة من أوائل قواعد البيانات الملاحية ، والتي طورها باخمان لشركة جنرال إلكتريك في الستينيات. وأصبحت IDS أساسًا لنموذج قاعدة بيانات CODASYL في عام 1969.
على الرغم من أن باخمان وصف مفهوم التنقل بعبارات مجردة، إلا أن فكرة الوصول إلى التنقل أصبحت مرتبطة ارتباطًا وثيقًا بالتصميم الإجرائي للغة معالجة البيانات CODASYL . فعلى سبيل المثال، ذكر تسيتشريتزيس ولوخوفسكي [ 2 ] في كتاباتهما عام 1982 أن "مفهوم العملة أساسي لمفهوم التنقل". ويقصدان بمفهوم العملة فكرة أن البرنامج يحتفظ (صراحةً أو ضمنًا) بموقع حالي في أي تسلسل من السجلات التي يعالجها، وأن عمليات مثل GET NEXTاسترجاع GET PRIORالسجلات بالنسبة لهذا الموقع الحالي، مع تغيير الموقع الحالي أيضًا إلى السجل المسترجع.
وهكذا، أصبح يُنظر إلى برمجة قواعد البيانات الملاحية على أنها إجرائية بطبيعتها ، وتعتمد أيضًا على صيانة مجموعة ضمنية من المتغيرات العامة ( مؤشرات العملة ) التي تُحدد الحالة الراهنة. ولذلك، اعتُبر هذا النهج مناقضًا تمامًا لأسلوب البرمجة التصريحي المُستخدم في النموذج العلائقي . وقد وفرت الطبيعة التصريحية للغات العلائقية، مثل SQL، إنتاجية أفضل للمبرمجين ومستوى أعلى من استقلالية البيانات (أي قدرة البرامج على مواصلة العمل مع تطور بنية قاعدة البيانات). ونتيجة لذلك، تراجعت أهمية واجهات الملاحة تدريجيًا خلال ثمانينيات القرن الماضي لصالح لغات الاستعلام التصريحية.
خلال تسعينيات القرن الماضي، بدأ يتضح أن حسابات العلاقات محدودة في بعض التطبيقات التي تتعامل مع بيانات معقدة (مثل قواعد البيانات المكانية والهندسية). في ذلك الوقت، بدأت إعادة تقييم شاملة لسوق قواعد البيانات، حيث وصفت العديد من الشركات أنظمتها الجديدة باستخدام مصطلح NoSQL التسويقي . وقد أدخلت العديد من هذه الأنظمة لغات لمعالجة البيانات، والتي، على الرغم من ابتعادها عن لغة CODASYL DML بمؤشراتها الخاصة بالعملات، يمكن فهمها على أنها تجسيد لرؤية باخمان "الملاحية". بعض هذه اللغات إجرائية، بينما البعض الآخر (مثل XPath ) تصريحي بالكامل. وقد وجدت فروع المفهوم الملاحي، مثل قاعدة بيانات الرسوم البيانية ، استخدامات جديدة في أحمال عمل معالجة المعاملات الحديثة .
وصف
يرتبط الوصول الملاحِي تقليديًا بنموذج الشبكة والنموذج الهرمي لقواعد البيانات ، ويصف عادةً واجهات برمجة تطبيقات معالجة البيانات التي تُعالَج فيها السجلات (أو الكائنات) واحدًا تلو الآخر، بشكل تكراري. ومع ذلك، فإن السمة الأساسية كما وصفها باخمان هي إيجاد السجلات بحكم علاقتها بسجلات أخرى: لذا يمكن أن تظل الواجهة ملاحية إذا كانت تحتوي على ميزات موجهة نحو المجموعات. [ 3 ] من وجهة النظر هذه، يكمن الاختلاف الرئيسي بين لغات معالجة البيانات الملاحِي واللغات العلائقية في استخدام علاقات مُسماة صريحة بدلاً من عمليات الربط القائمة على القيم . fordepartmentwithname="Sales",findallemployeesinsetdepartment-employeesfind employees, departments where employee.department-code = department.code and department.name="Sales"
لكن عمليًا، كانت معظم واجهات برمجة التطبيقات الخاصة بالملاحة إجرائية: سيتم تنفيذ الاستعلام أعلاه باستخدام منطق إجرائي على غرار الشفرة الزائفة التالية:
احصل على القسم الذي يحمل الاسم 'المبيعات' ، ثم احصل على أول موظف في مجموعة موظفي القسم، وهكذا حتى نهاية المجموعة . كرر ما يلي: احصل على الموظف التالي في مجموعة موظفي القسم، ثم قم بمعالجة بيانات الموظف .من وجهة النظر هذه، فإن الفرق الرئيسي بين واجهات برمجة التطبيقات الخاصة بالملاحة والنموذج العلائقي (المطبق في قواعد البيانات العلائقية ) هو أن واجهات برمجة التطبيقات العلائقية تستخدم تقنيات "تصريحية" أو برمجة منطقية تسأل النظام عما يجب جلبه، بينما تقوم واجهات برمجة التطبيقات الخاصة بالملاحة بتوجيه النظام في سلسلة من الخطوات لكيفية الوصول إلى السجلات المطلوبة.
تندرج معظم الانتقادات الموجهة لواجهات برمجة تطبيقات الملاحة ضمن إحدى الفئتين التاليتين:
- سهولة الاستخدام: يصبح رمز التطبيق غير قابل للقراءة بسرعة ويصعب تصحيحه
- استقلالية البيانات: يجب تغيير كود التطبيق كلما تغيرت بنية البيانات
لسنوات عديدة، كان الأداء هو الدافع الرئيسي وراء واجهات برمجة تطبيقات التنقل. غالبًا ما تستخدم أنظمة قواعد البيانات التي تدعم هذه الواجهات هياكل تخزين داخلية تحتوي على روابط أو مؤشرات مادية بين السجلات. ورغم أن هذه الهياكل قد تتيح تنقلًا فعالًا للغاية، إلا أنها تنطوي على عيوب، إذ يصعب إعادة تنظيم التوزيع الفعلي للبيانات. من الممكن تمامًا تطبيق واجهات برمجة تطبيقات التنقل دون الحاجة إلى تتبع المؤشرات على مستوى منخفض (إذ تصورت ورقة باخمان تطبيق العلاقات المنطقية كما في الأنظمة العلائقية، باستخدام المفاتيح الأساسية والأجنبية)، لذا لا ينبغي الخلط بين الفكرتين. ولكن بدون مزايا الأداء التي توفرها المؤشرات على مستوى منخفض، يصبح تبرير استخدام واجهات برمجة تطبيقات التنقل أكثر صعوبة.
غالبًا ما تُنشئ النماذج الهرمية مفاتيح أساسية للسجلات عن طريق دمج المفاتيح التي تظهر في كل مستوى من مستويات التسلسل الهرمي. توجد هذه المعرفات المركبة في أسماء ملفات الحاسوب/usr/david/docs/index.txt ، وفي معرّفات الموارد الموحدة (URIs)، وفي نظام ديوي العشري ، وحتى في العناوين البريدية. يمكن اعتبار هذا المفتاح المركب بمثابة مسار تنقل إلى سجل ما؛ ولكن في الوقت نفسه، يمكن اعتباره مفتاحًا أساسيًا بسيطًا يسمح بالوصول الترابطي.
مع بروز الأنظمة العلائقية في ثمانينيات القرن الماضي، تعرضت واجهات برمجة التطبيقات (APIs) الخاصة بالتنقل (وخاصةً واجهات برمجة التطبيقات الإجرائية) لانتقادات حادة وفقدت شعبيتها. إلا أن تسعينيات القرن الماضي شهدت ظهور موجة جديدة من قواعد البيانات الموجهة للكائنات ، والتي غالبًا ما وفرت واجهات تعريفية وإجرائية. أحد تفسيرات ذلك هو استخدامها في كثير من الأحيان لتمثيل المعلومات ذات البنية البيانية (مثل البيانات المكانية والبيانات الهندسية)، حيث يكون الوصول إليها متكررًا بطبيعته: فالرياضيات التي بُنيت عليها لغة SQL في الأصل (وتحديدًا حساب التفاضل والتكامل من الدرجة الأولى ) لا تمتلك القدرة الكافية لدعم الاستعلامات المتكررة، حتى تلك البسيطة كالإغلاق المتعدي . أما تطبيقات SQL الأحدث، فتدعم الاستعلامات الهرمية والمتكررة .
يُعدّ نموذج كائن المستند (DOM) مثالًا شائعًا على واجهات برمجة التطبيقات (API) للتنقل، وهو نموذج يُستخدم بكثرة في متصفحات الويب ويرتبط ارتباطًا وثيقًا بلغة جافا سكريبت . يُعتبر DOM في جوهره قاعدة بيانات هرمية في الذاكرة، بواجهة برمجة تطبيقات إجرائية وتنقلية في آنٍ واحد. في المقابل، يُمكن الوصول إلى البيانات نفسها ( XML أو HTML ) باستخدام XPath ، الذي يُصنّف ضمن الواجهات التصريحية والتنقلية: حيث يتم الوصول إلى البيانات من خلال تتبع العلاقات، دون أن يُصدر البرنامج المُستدعي سلسلة من التعليمات التي يجب اتباعها بالتسلسل. كما تُعتبر لغات مثل SPARQL، المُستخدمة لاسترجاع البيانات المرتبطة من الويب الدلالي، لغات تصريحية وتنقلية في الوقت نفسه.
أمثلة
انظر أيضاً
مراجع
- ↑ باخمان، تشارلز و. (1973). "المبرمج كملاح" . اتصالات رابطة آلات الحوسبة . 16 (11). Portal.acm.org: 653–658 . doi : 10.1145/355611.362534 . S2CID 18635540 .
- ↑ ديونيسيوس سي. تسيتشريتزيس وفريدريك إتش. لوخوفسكي (1982). نماذج البيانات . برنتيس هول. ص 67. ISBN 0-13-196428-3.
- ^ بلازيفيتش، جاسيك؛ كروليكوفسكي، زبيسكو؛ مورزي، تاديوش (2003). دليل البيانات والإدارة في نظم المعلومات . سبرينغر. ص. 18. رقم ISBN 3-540-43893-9.
روابط خارجية
- تصنيف DB-Engines لأنظمة إدارة قواعد البيانات الملاحية حسب الشعبية، ويتم تحديثه شهريًا
- إدارة البيانات
- أنواع قواعد البيانات
