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

A labeled-property graph model is represented by a set of nodes, relationships, properties, and labels. Both nodes of data and their relationships are named and can store properties represented by key–value pairs. Nodes can be labelled to be grouped. The edges representing the relationships have two qualities: they always have a start node and an end node, and are directed;^[16] making the graph a directed graph. Relationships can also have properties. This is useful in providing additional metadata and semantics to relationships of the nodes.^[17] Direct storage of relationships allows a constant-timetraversal.^[18]

In an RDF graph model, each addition of information is represented with a separate node. For example, imagine a scenario where a user has to add a name property for a person represented as a distinct node in the graph. In a labeled-property graph model, this would be done with an addition of a name property into the node of the person. However, in an RDF, the user has to add a separate node called hasName connecting it to the original person node. Specifically, an RDF graph model is composed of nodes and arcs. An RDF graph notation or a statement is represented by: a node for the subject, a node for the object, and an arc for the predicate. A node may be left blank, a literal and/or be identified by a URI. An arc may also be identified by a URI. A literal for a node may be of two types: plain (untyped) and typed. A plain literal has a lexical form and optionally a language tag. A typed literal is made up of a string with a URI that identifies a particular datatype. A blank node may be used to accurately illustrate the state of the data when the data does not have a URI.^[19]

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

تُطبّق قواعد بيانات الرسوم البيانية عادةً خاصية التجاور بدون فهرسة ، حيث تُخزّن العُقد مراجع مباشرة إلى عُقد أخرى في قاعدة البيانات، على عكس قواعد البيانات العلائقية التي تستخدم فهرسًا عالميًا واحدًا . تُشبه المراجع المباشرة "الفهرس المصغر"، وتتيح عادةً أوقات وصول ثابتة O(1) عند الاستعلام عن العُقد المجاورة، بينما يكون الاستعلام عن فهرس عادةً O(log( n )) ، حيث n هو حجم الفهرس، مما يعني أن أوقات الاستعلام تتناسب مع مقدار الرسم البياني الذي يتم الاستعلام عنه وليس مع حجم الرسم البياني نفسه. ^{[ 21 ] : 149-154}

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

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

على النقيض من ذلك، تخزن قواعد بيانات الرسوم البيانية العلاقات بين السجلات مباشرةً. فبدلاً من البحث عن عنوان بريد إلكتروني باستخدام مفتاح المستخدم في العمود userpk، يحتوي سجل المستخدم على مؤشر يشير مباشرةً إلى سجل عنوان البريد الإلكتروني. أي أنه بمجرد تحديد مستخدم، يمكن تتبع المؤشر مباشرةً إلى سجلات البريد الإلكتروني، دون الحاجة إلى البحث في جدول البريد الإلكتروني للعثور على السجلات المطابقة. وهذا يُلغي عمليات الربط المكلفة. على سبيل المثال، عند البحث عن جميع عناوين البريد الإلكتروني للمستخدمين في المنطقة "311"، يقوم محرك البحث أولاً بإجراء بحث تقليدي للعثور على المستخدمين في "311"، ثم يسترجع عناوين البريد الإلكتروني باتباع الروابط الموجودة في تلك السجلات. أما قاعدة البيانات العلائقية، فتقوم أولاً بالعثور على جميع المستخدمين في "311"، ثم تستخرج قائمة بالمفاتيح الأساسية، وتُجري بحثًا آخر عن أي سجلات في جدول البريد الإلكتروني تحمل تلك المفاتيح الأساسية، ثم تربط السجلات المطابقة معًا. من الناحية النظرية، تُعد قواعد بيانات الرسوم البيانية أسرع في هذه الأنواع من العمليات الشائعة. ^{[ 28 ]}

تتجلى القيمة الحقيقية لمنهجية الرسم البياني عند إجراء عمليات بحث تتجاوز مستوى واحدًا. على سبيل المثال، لنفترض البحث عن مستخدمين لديهم "مشتركون" (جدول يربط المستخدمين ببعضهم) في منطقة الرمز البريدي "311". في هذه الحالة، يتعين على قاعدة البيانات العلائقية أولًا البحث عن جميع المستخدمين الذين يقع رمز منطقتهم ضمن "311"، ثم البحث في جدول المشتركين عن أيٍّ من هؤلاء المستخدمين، وأخيرًا البحث في جدول المستخدمين لاسترجاع المستخدمين المطابقين. في المقابل، تبحث قاعدة بيانات الرسم البياني عن جميع المستخدمين في "311"، ثم تتبع الروابط الخلفية عبر علاقة المشتركين للعثور على المشتركين. هذا يتجنب العديد من عمليات البحث والاستعلام، بالإضافة إلى استهلاك الذاكرة اللازم لتخزين جميع البيانات المؤقتة من سجلات متعددة مطلوبة لإنشاء المخرجات. من حيث ترميز Big O ، سيكون هذا الاستعلام كالتالي:${\displaystyle O(\log n)+O(1)}$الوقت – أي يتناسب مع لوغاريتم حجم البيانات. في المقابل، ستكون النسخة العلائقية متعددة${\displaystyle O(\log n)}$عمليات البحث، بالإضافة إلى${\displaystyle O(n)}$الوقت اللازم لدمج جميع سجلات البيانات. ^{[ 28 ]}

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

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

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

لتوضيح ذلك أكثر، تخيل نموذجًا علائقيًا يتكون من جدولين: peopleجدول (يحتوي على person_idعمودين person_name) وجدول friend(يحتوي على friend_idمفتاح person_idخارجي من الجدول people). في هذه الحالة، سيؤدي البحث عن جميع أصدقاء جاك إلى استعلام SQL التالي.

SELECT p2.person_name FROM people p1 JOIN friend ON ( p1.person_id = friend.person_id ) JOIN people p2 ON ( p2.person_id = friend.friend_id ) WHERE p1.person_name = ' Jack ' ;​​​​​​​​​​

يمكن ترجمة نفس الاستعلام إلى --

• سايفر ، لغة استعلام لقواعد بيانات الرسوم البيانية

  MATCH ( p1 : person { name : 'Jack' }) -[ : FRIEND_WITH ]- ( p2 : person ) RETURN p2 . name

• Gremlin ، وهي لغة استعلام عن الرسوم البيانية ذات نمط إجرائي يتم صيانتها بواسطة Apache TinkerPop وتستخدمها العديد من قواعد بيانات الرسوم البيانية ^{[ 30 ].}

  g.V (). hasLabel ( "person" ). has ( "name" , "Jack" ). out ( "friendsWith" ) . hasLabel ( "person" ) . values ( "name" )

• SPARQL ، وهي لغة استعلام لقواعد بيانات الرسوم البيانية RDF، تم توحيدها بواسطة W3C وتستخدم في العديد من مخازن RDF الثلاثية والرباعية
  • الشكل الكامل

    البادئة foaf : <http://xmlns.com/foaf/0.1/>SELECT ?name WHERE { ?s a foaf : Person . ?s foaf : name "Jack" . ?s foaf : knows ?o . ​​?o foaf : name ?name . }

  • صيغة مختصرة

    البادئة foaf : <http://xmlns.com/foaf/0.1/>SELECT ?name WHERE { ?s foaf : name "Jack" ; foaf : knows ?o . ​​?o foaf : name ?name . }

• SPASQL، وهي لغة استعلام قواعد بيانات هجينة، توسع لغة SQL باستخدام SPARQL

  SELECT people.name FROM ( SPARQL PREFIX foaf : <http://xmlns.com/foaf/0.1/> SELECT ? name WHERE { ?s foaf : name "Jack" ; foaf : knows ?o . ? o foaf : name ?name . } ) AS people ;

تُعدّ الأمثلة السابقة توضيحًا بسيطًا لاستعلام العلاقات الأساسي. وهي تُجسّد فكرة تعقيد استعلامات نماذج العلاقات، والذي يزداد مع ازدياد حجم البيانات. في المقابل، يُمكن لاستعلام قاعدة بيانات الرسم البياني فرز بيانات الرسم البياني للعلاقات بسهولة لعرض النتائج.

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