قاعدة بيانات زمنية
تُخزّن قاعدة البيانات الزمنية بياناتٍ تتعلق بلحظات زمنية محددة. وهي توفر أنواع بيانات زمنية، وتخزن معلوماتٍ تتعلق بالماضي والحاضر والمستقبل. ويمكن أن تكون قواعد البيانات الزمنية أحادية الزمن، أو ثنائية الزمن، أو ثلاثية الزمن.
وبشكل أكثر تحديداً، تشمل الجوانب الزمنية عادةً وقت الصلاحية ، ووقت المعاملة ، و/أو وقت اتخاذ القرار .
- الوقت الصالح هو الفترة الزمنية التي يكون فيها الحدث صحيحًا في العالم الحقيقي، سواء كان ذلك خلال وقت وقوع الحدث أو خلاله.
- وقت المعاملة هو الوقت الذي تم فيه تسجيل حقيقة ما في قاعدة البيانات.
- وقت اتخاذ القرار هو الوقت الذي تم فيه اتخاذ القرار بشأن الحقيقة. ويُستخدم هذا الوقت للاحتفاظ بسجل للقرارات المتعلقة بأوقات صالحة.
الأنواع
أحادي الزمن
تحتوي قاعدة البيانات أحادية الزمن على محور زمني واحد، إما نطاق الصلاحية أو نطاق وقت النظام.
ثنائي الصدغ
تحتوي قاعدة البيانات ثنائية الزمن على محورين زمنيين:
- وقت الصلاحية
- وقت المعاملة أو وقت اتخاذ القرار
ثلاثي الصدغ
تحتوي قاعدة البيانات ثلاثية الأبعاد على ثلاثة محاور زمنية:
- وقت الصلاحية
- وقت المعاملة
- وقت اتخاذ القرار
يُضيف هذا النهج تعقيدات إضافية.
تختلف قواعد البيانات الزمنية عن قواعد البيانات الحالية (لا ينبغي الخلط بينها وبين قواعد البيانات المتاحة حاليًا)، والتي تخزن فقط الحقائق التي يُعتقد أنها صحيحة في الوقت الحالي.
سمات
تدعم قواعد البيانات الزمنية إدارة البيانات الزمنية والوصول إليها من خلال توفير ميزة واحدة أو أكثر من الميزات التالية: [ 1 ] [ 2 ]
- نوع بيانات الفترة الزمنية، بما في ذلك القدرة على تمثيل الفترات الزمنية التي لا نهاية لها (اللانهاية أو الأبدية).
- القدرة على تحديد سمات الفترة الزمنية الصالحة والمعاملاتية والعلاقات الزمنية الثنائية
- وقت المعاملة الذي يديره النظام
- المفاتيح الأساسية الزمنية ، بما في ذلك قيود الفترة غير المتداخلة
- القيود الزمنية، بما في ذلك التفرد غير المتداخل والسلامة المرجعية
- تحديث وحذف السجلات الزمنية مع تقسيم ودمج الفترات الزمنية تلقائيًا
- الاستعلامات الزمنية في الوقت الحالي، أو نقاط زمنية في الماضي أو المستقبل، أو على مدى فترات زمنية محددة
- دوال استعلام عن الفترات الزمنية، غالباً ما تستند إلى علاقات الفترات الزمنية لألين
تاريخ
مع تطور لغة SQL واستخدامها المتزايد في التطبيقات العملية، أدرك مستخدمو قواعد البيانات أن إضافة أعمدة التاريخ إلى الحقول الرئيسية يُثير بعض المشكلات. فعلى سبيل المثال، إذا كان للجدول مفتاح أساسي وبعض السمات، فإن إضافة تاريخ إلى المفتاح الأساسي لتتبع التغييرات التاريخية قد يؤدي إلى إنشاء صفوف أكثر من اللازم. كما يجب التعامل مع عمليات الحذف بشكل مختلف عند تتبع الصفوف بهذه الطريقة. في عام ١٩٩٢، تم التعرّف على هذه المشكلة، لكن نظرية قواعد البيانات القياسية لم تكن قادرة على حلّها آنذاك، وكذلك لم يكن معيار SQL-92 الذي تم إقراره حديثًا .
اقترح ريتشارد سنودغراس في عام 1992 أن يقوم مجتمع قواعد البيانات الزمنية بتطوير امتدادات زمنية للغة SQL. واستجابةً لهذا الاقتراح، شُكّلت لجنة لتصميم امتدادات لإصدار عام 1992 من معيار SQL (ANSI X3.135-1992 وISO/IEC 9075:1992)؛ وقد طُوّرت هذه الامتدادات، المعروفة باسم TSQL2، خلال عام 1993 من قِبل هذه اللجنة. [ 3 ] وفي أواخر عام 1993، قدّم سنودغراس هذا العمل إلى المجموعة المسؤولة عن المعيار الوطني الأمريكي للغة قواعد البيانات SQL، وهي اللجنة الفنية ANSI X3H2 (المعروفة الآن باسم NCITS H2). ونُشرت المواصفات الأولية للغة في عدد مارس 1994 من سجل ACM SIGMOD. وبناءً على الردود على تلك المواصفات، أُجريت تعديلات على اللغة، ونُشرت النسخة النهائية من مواصفات لغة TSQL2 في سبتمبر 1994. [ 4 ]
جرت محاولة لدمج أجزاء من TSQL2 في معيار SQL الجديد SQL:1999 ، المسمى SQL3. أُدرجت أجزاء من TSQL2 في معيار فرعي جديد من SQL3، وهو ISO/IEC 9075-7، المسمى SQL/Temporal. [ 3 ] تعرض نهج TSQL2 لانتقادات شديدة من كريس ديت وهيو داروين . [ 5 ] أُلغي مشروع ISO المسؤول عن الدعم الزمني قرب نهاية عام 2001.
اعتبارًا من ديسمبر 2011، تضمنت المواصفة القياسية ISO/IEC 9075، لغة قواعد البيانات SQL:2011 الجزء 2: SQL/Foundation، بنودًا في تعريفات الجداول لتحديد "جداول فترات زمنية للتطبيق" ( جداول زمنية صالحة )، و"جداول ذات إصدارات نظامية" ( جداول زمنية للمعاملات )، و"جداول فترات زمنية للتطبيق ذات إصدارات نظامية" ( جداول ثنائية الزمن ). يتمثل أحد الاختلافات الجوهرية بين مقترح TSQL2 وما تم اعتماده في SQL:2011 في عدم وجود أعمدة مخفية في معالجة SQL:2011، كما أنها لا تحتوي على نوع بيانات جديد للفترات؛ بدلاً من ذلك، يمكن ربط عمودين يحتويان على طوابع زمنية (DS) أو طوابع زمنية-تاريخيةPERIOD FOR (DTS) معًا باستخدام تعريف. يتمثل اختلاف آخر في استبدال مُعدِّلات العبارات (البادئة) المثيرة للجدل من TSQL2 بمجموعة من المسندات الزمنية. [ 1 ]
تشمل الميزات الأخرى لمعيار SQL:2011 المتعلقة بقواعد البيانات الزمنية تقسيم الفترة الزمنية التلقائي، والمفاتيح الأساسية الزمنية، والتكامل المرجعي الزمني، والمسندات الزمنية مع جبر الفترات الزمنية لألين والاستعلامات المقسمة زمنيًا والمتسلسلة.
مثال
على سبيل المثال، انظر إلى السيرة الذاتية القصيرة التالية لرجل خيالي يُدعى جون دو:
- وُلد جون دو في 3 أبريل 1975 في مستشفى الأطفال بمقاطعة ميديسن، وهو ابن جاك دو وجين دو اللذين كانا يسكنان في سمولفيل. سجّل جاك دو بفخر ميلاد ابنه البكر في 4 أبريل 1975 في مبنى بلدية سمولفيل. نشأ جون طفلاً سعيداً، وبرز كطالب متفوق وتخرج بامتياز عام 1993. بعد تخرجه، انتقل للعيش بمفرده في بيغ تاون. ورغم أنه غادر المنزل في 26 أغسطس 1994، إلا أنه نسي تسجيل تغيير عنوانه رسمياً. لم تتذكر والدته ذلك إلا مع بداية فصل الخريف، فقام بالتسجيل بعد بضعة أيام في 27 ديسمبر 1994. ورغم أن جون كان ينتظره مستقبل واعد، إلا أن قصته انتهت نهاية مأساوية. فقد صدمته شاحنة عن طريق الخطأ في 1 أبريل 2001. وأعلن الطبيب الشرعي تاريخ وفاته في اليوم نفسه.
استخدام قاعدة بيانات غير زمنية
لتخزين بيانات حياة جون دو في قاعدة بيانات حالية (غير مؤقتة)، نستخدم جدولًا person (name, address). (لتبسيط الأمر، nameيُعرَّف الجدول بأنه المفتاح الأساسي للجدول person).
أبلغ والد جون رسميًا عن ولادته في 4 أبريل 1975. وفي هذا التاريخ، أدخل مسؤول في سمولفيل البيانات التالية في قاعدة البيانات: Person(John Doe, Smallville). لاحظ أن التاريخ نفسه غير مُخزَّن في قاعدة البيانات.
بعد التخرج، انتقل جون من منزله، لكنه نسي تسجيل عنوانه الجديد. لم يتم تحديث بيانات جون في قاعدة البيانات حتى 27 ديسمبر 1994، عندما أبلغ عنها أخيرًا. قام مسؤول في بيغ تاون بتحديث عنوانه في قاعدة البيانات. personيحتوي الجدول الآن على Person(John Doe, Bigtown)معلومات تفيد بأن جون كان يسكن في سمولفيل. لاحظ أنه تم استبدال معلومات سكن جون في سمولفيل، لذا لم يعد من الممكن استرجاع تلك المعلومات من قاعدة البيانات. لو قام مسؤول بالدخول إلى قاعدة البيانات في 28 ديسمبر 1994، لظهرت له معلومات تفيد بأن جون يسكن في بيغ تاون. بتعبير أدق: لو قام مسؤول قاعدة البيانات بتشغيل الاستعلام في 26 ديسمبر 1994، لكانت النتيجة . أما تشغيل الاستعلام نفسه بعد يومين فسيؤدي إلى نتيجة أخرى .SELECTADDRESSFROMPERSONWHERENAME='John Doe'SmallvilleBigtown
حتى وفاته، كانت قاعدة البيانات تُشير إلى أنه كان يسكن في بيغ تاون. في 1 أبريل 2001، قام الطبيب الشرعي بحذف سجل جون دو من قاعدة البيانات. بعد ذلك، لم تُظهر الاستعلامات المذكورة أعلاه أي نتائج.
| تاريخ | حدث واقعي | إجراء قاعدة البيانات | ما تُظهره قاعدة البيانات |
|---|---|---|---|
| 1975-04-03 | ولادة جون | لا شئ | لا يوجد شخص يُدعى جون دو |
| 1975-04-04 | أعلن والد جون رسمياً عن ولادة جون | تم إدراج: شخص (جون دو، سمولفيل) | يعيش جون دو في سمولفيل |
| 26-08-1994 | بعد التخرج، ينتقل جون إلى بيجتاون، لكنه ينسى تسجيل عنوانه الجديد | لا شئ | يعيش جون دو في سمولفيل |
| 26-12-1994 | لا شئ | لا شئ | يعيش جون دو في سمولفيل |
| 27-12-1994 | جون يسجل عنوانه الجديد | تحديث: شخص (جون دو، بيغ تاون) | يعيش جون دو في بيج تاون |
| 2001-04-01 | جون يموت | تم الحذف: شخص (جون دو) | لا يوجد شخص يُدعى جون دو |
باستخدام محور واحد: وقت الصلاحية أو وقت المعاملة
الوقت الصحيح هو الوقت الذي تكون فيه الحقيقة صحيحة في العالم الواقعي. قد تكون الفترة الزمنية الصحيحة في الماضي، أو تمتد إلى الوقت الحاضر، أو تحدث في المستقبل.
في المثال أعلاه، لتسجيل وقت صالح، personأُضيف حقلان إلى الجدول، وهما: valid_fromو valid_to. يحدد هذان الحقلان الفترة التي يكون فيها عنوان الشخص صالحًا في الواقع. في 4 أبريل 1975، سجّل والد جون ميلاد ابنه. ثم أضاف مسؤولٌ سجلًا جديدًا في قاعدة البيانات يفيد بأن جون يقيم في سمولفيل منذ 3 أبريل. لاحظ أنه على الرغم من إدخال البيانات في الرابع من أبريل، إلا أن قاعدة البيانات تُشير إلى أن المعلومات صالحة منذ الثالث من أبريل. لا يعلم المسؤول بعد ما إذا كان جون سينتقل إلى مكان آخر أو متى، لذا valid_toتم ضبط قيمة الحقل على ما لا نهاية (∞). السجل في قاعدة البيانات هو:
| اسم | مدينة | يسري من | صالح لـ |
|---|---|---|---|
| جون دو | سمولفيل | 1975-04-03 | ∞ |
في 27 ديسمبر 1994، أبلغ جون عن عنوانه الجديد في بيغ تاون، حيث يقيم منذ 26 أغسطس 1994. وقد تم تسجيل هذه المعلومة في قاعدة البيانات.
| اسم | مدينة | يسري من | صالح لـ |
|---|---|---|---|
| جون دو | بيغ تاون | 26-08-1994 | ∞ |
Person (John Doe, Smallville, 1975-04-03, ∞)لم يُحذف السجل الأصلي ، ولكن تم valid_toتحديث سماته ليعكس معرفة أن جون توقف عن الإقامة في سمولفيل بتاريخ ٢٦ أغسطس ١٩٩٤. تحتوي قاعدة البيانات الآن على سجلين لجون دو:
| اسم | مدينة | يسري من | صالح لـ |
|---|---|---|---|
| جون دو | سمولفيل | 1975-04-03 | 26-08-1994 |
| جون دو | بيغ تاون | 26-08-1994 | ∞ |
عند وفاة جون، يتم تحديث بياناته في قاعدة البيانات لتوضيح أنه لم يعد يسكن في بيغ تاون. تصبح قاعدة البيانات الآن على النحو التالي:
| اسم | مدينة | يسري من | صالح لـ |
|---|---|---|---|
| جون دو | سمولفيل | 1975-04-03 | 26-08-1994 |
| جون دو | بيغ تاون | 26-08-1994 | 2001-04-01 |
باستخدام محورين: وقت الصلاحية ووقت المعاملة
يسجل وقت المعاملة الفترة الزمنية التي يُعتبر خلالها إدخال قاعدة البيانات صحيحًا. وهذا يُتيح الاستعلامات التي تُظهر حالة قاعدة البيانات في وقت مُحدد. لا يمكن أن تحدث فترات وقت المعاملة إلا في الماضي أو حتى الوقت الحالي. في جدول وقت المعاملة، لا تُحذف السجلات أبدًا. يُمكن فقط إدراج سجلات جديدة، وتحديث السجلات الموجودة عن طريق تحديد وقت انتهاء المعاملة الخاص بها لإظهار أنها لم تعد سارية.
لتمكين وقت المعاملة في المثال أعلاه، تمت إضافة حقلين آخرين إلى جدول الأشخاص: transaction_fromو transaction_to. هنا، transaction_fromيمثل وقت إجراء المعاملة، ويمثل transaction_toوقت استبدال المعاملة (والذي قد يكون غير محدود إذا لم يتم استبدالها بعد). هذا يجعل الجدول جدولًا ثنائي الزمن .
ماذا يحدث إذا كان عنوان الشخص المُسجّل في قاعدة البيانات غير صحيح؟ لنفترض أن أحد الموظفين أدخل عنوانًا أو تاريخًا خاطئًا عن طريق الخطأ؟ أو لنفترض أن الشخص كذب بشأن عنوانه لسبب ما. عند اكتشاف الخطأ، يقوم الموظفون بتحديث قاعدة البيانات لتصحيح المعلومات المُسجّلة.
على سبيل المثال، انتقل جون دو إلى بيتشي في الفترة من 1 يونيو 1995 إلى 3 سبتمبر 2000. ولكن لتجنب دفع ضريبة الإقامة الباهظة في بيتشي، لم يُبلغ السلطات بذلك. لاحقًا، خلال تحقيق ضريبي، اكتُشف في 2 فبراير 2001 أنه كان بالفعل في بيتشي خلال تلك الفترة. لتسجيل هذه المعلومة، يجب تقسيم السجل الحالي الذي يُفيد بأن جون كان يسكن في بيغ تاون إلى سجلين منفصلين، وإضافة سجل جديد يُسجل إقامته في بيتشي. ستظهر قاعدة البيانات حينها على النحو التالي:
| اسم | مدينة | يسري من | صالح لـ |
|---|---|---|---|
| جون دو | سمولفيل | 1975-04-03 | 26-08-1994 |
| جون دو | بيغ تاون | 26-08-1994 | 1995-06-01 |
| جون دو | شاطئي | 1995-06-01 | 2000-09-03 |
| جون دو | بيغ تاون | 2000-09-03 | 2001-04-01 |
مع ذلك، لا يوجد في قاعدة البيانات أي سجل يُثبت أنه أقام في بيغ تاون خلال الفترة من 1 يونيو 1995 إلى 3 سبتمبر 2000. قد يكون من المهم معرفة ذلك لأغراض التدقيق، أو لاستخدامه كدليل في التحقيق الضريبي الذي يجريه المسؤول. يسمح وقت المعاملات بتسجيل هذه المعلومات المتغيرة في قاعدة البيانات، حيث لا يتم تعديل أو حذف البيانات بشكل مباشر. بدلاً من ذلك، يسجل كل إدخال وقت إدخاله ووقت استبداله (أو حذفه منطقيًا). وبالتالي، تبدو محتويات قاعدة البيانات كما يلي:
| اسم | مدينة | يسري من | صالح لـ | تم الدخول | تم استبداله |
|---|---|---|---|---|---|
| جون دو | سمولفيل | 1975-04-03 | ∞ | 1975-04-04 | 27-12-1994 |
| جون دو | سمولفيل | 1975-04-03 | 26-08-1994 | 27-12-1994 | ∞ |
| جون دو | بيغ تاون | 26-08-1994 | ∞ | 27-12-1994 | 2001-02-02 |
| جون دو | بيغ تاون | 26-08-1994 | 1995-06-01 | 2001-02-02 | ∞ |
| جون دو | شاطئي | 1995-06-01 | 2000-09-03 | 2001-02-02 | ∞ |
| جون دو | بيغ تاون | 2000-09-03 | ∞ | 2001-02-02 | 2001-04-01 |
| جون دو | بيغ تاون | 2000-09-03 | 2001-04-01 | 2001-04-01 | ∞ |
لا تسجل قاعدة البيانات ما حدث في العالم الحقيقي فحسب، بل تسجل أيضًا ما تم تسجيله رسميًا في أوقات مختلفة.
باستخدام ثلاثة محاور: وقت الصلاحية، ووقت اتخاذ القرار، ووقت المعاملة
يُعدّ وقت اتخاذ القرار بديلاً لفترة وقت المعاملة لتسجيل الوقت الذي يُمكن فيه قبول إدخال قاعدة البيانات على أنه صحيح. وهذا يُتيح الاستعلامات التي تُظهر الحقائق المُعترف بها رسميًا في وقت مُحدد، حتى لو كان هناك تأخير في إدخال تلك الحقائق في قاعدة البيانات. ويحافظ دعم وقت اتخاذ القرار على السجل الكامل ويمنع فقدان المعلومات أثناء التحديثات. [ 6 ]
لا يمكن أن تحدث فترات اتخاذ القرار إلا في الماضي أو حتى وقت المعاملة. وكما هو الحال في جدول أوقات المعاملات، لا تُحذف السجلات أبدًا. يُمكن فقط إدراج سجلات جديدة، وتحديث السجلات الموجودة عن طريق تحديد وقت انتهاء قرارها لإظهار أنها لم تعد سارية.
لتمكين حساب وقت اتخاذ القرار، يُضاف حقلان إضافيان إلى جدول قاعدة البيانات: decision_fromو decision_to. هنا، decision_fromيُمثل وقت اتخاذ القرار، بينما decision_toيُمثل وقت إلغاء القرار (والذي قد يكون غير محدود إذا لم يتم إلغاؤه بعد). عند دمجه مع وقت المعاملة، يُصبح الجدول جدولًا ثلاثي الأبعاد . فيما يلي قائمة بالأحداث الحقيقية التي وقعت بين الانتخابات الرئاسية الأمريكية لعامي 1964 و1976 :
| تاريخ | صانع القرار | حدث واقعي |
|---|---|---|
| 1964-11-03 | المجمع الانتخابي | انتخابات عام 1964 |
| 1968-11-05 | المجمع الانتخابي | انتخابات عام 1968 |
| 1972-11-07 | المجمع الانتخابي | انتخابات عام 1972 |
| 10-10-1973 | سبيرو أغنيو | استقالة أغنيو |
| 1973-10-12 | ريتشارد نيكسون | نيكسون يرشح فورد |
| 1973-12-06 | الكونغرس | الكونجرس يُقرّ تعيين فورد |
| 9 أغسطس 1974 | ريتشارد نيكسون | استقال نيكسون |
| 20 أغسطس 1974 | جيرالد فورد | فورد يرشح روكفلر |
| 1974-12-19 | الكونغرس | الكونجرس يقر تعيين روكفلر |
| 1976-11-02 | المجمع الانتخابي | انتخابات عام 1976 |
في هذا المثال، يُفترض وجود تأخير ثابت لمدة سبعة أيام بين وقت اتخاذ القرار ووقت إدخال البيانات في قاعدة البيانات. وبناءً على هذه الشروط، كانت قاعدة البيانات ستحتوي على المعلومات التالية بعد انتخابات عام 1976:
| صالح | قرار | عملية | |||||
|---|---|---|---|---|---|---|---|
| رئيس | نائب | من | ل | من | ل | من | ل |
| جونسون | همفري | 20 يناير 1965 | 20 يناير 1969 | 1964-11-03 | ∞ | 10-11-1964 | ∞ |
| نيكسون | أغنيو | 20 يناير 1969 | 20 يناير 1973 | 1968-11-05 | ∞ | 1968-11-12 | ∞ |
| نيكسون | أغنيو | 20 يناير 1973 | 20 يناير 1977 | 1972-11-07 | ∞ | 14-11-1972 | 17-10-1973 |
| نيكسون | أغنيو | 20 يناير 1973 | 20 يناير 1977 | 1972-11-07 | 10-10-1973 | 17-10-1973 | ∞ |
| نيكسون | أغنيو | 20 يناير 1973 | 10-10-1973 | 10-10-1973 | ∞ | 17-10-1973 | ∞ |
| نيكسون | (شاغر) | 10-10-1973 | 20 يناير 1977 | 10-10-1973 | ∞ | 17-10-1973 | 13 ديسمبر 1973 |
| نيكسون | فورد | ∞ | 20 يناير 1977 | 1973-10-12 | ∞ | 1973-10-19 | 13 ديسمبر 1973 |
| نيكسون | (شاغر) | 10-10-1973 | 20 يناير 1977 | 10-10-1973 | 1973-12-06 | 13 ديسمبر 1973 | ∞ |
| نيكسون | (شاغر) | 10-10-1973 | 1973-12-06 | 1973-12-06 | ∞ | 13 ديسمبر 1973 | ∞ |
| نيكسون | فورد | ∞ | 20 يناير 1977 | 1973-10-12 | 1973-12-06 | 13 ديسمبر 1973 | ∞ |
| نيكسون | فورد | 1973-12-06 | 20 يناير 1977 | 1973-12-06 | ∞ | 13 ديسمبر 1973 | 15 أغسطس 1974 |
| نيكسون | فورد | 1973-12-06 | 20 يناير 1977 | 1973-12-06 | 1974-08-08 | 15 أغسطس 1974 | ∞ |
| نيكسون | فورد | 1973-12-06 | 9 أغسطس 1974 | 1974-10-08 | ∞ | 15 أغسطس 1974 | ∞ |
| فورد | (شاغر) | 9 أغسطس 1974 | 20 يناير 1977 | 1974-10-08 | ∞ | 15 أغسطس 1974 | 26-12-1974 |
| فورد | روكفلر | ∞ | 20 يناير 1977 | 20-10-1974 | ∞ | 27-08-1974 | 26-12-1974 |
| فورد | (شاغر) | 9 أغسطس 1974 | 20 يناير 1977 | 1974-10-08 | 1974-12-19 | 26-12-1974 | ∞ |
| فورد | (شاغر) | 9 أغسطس 1974 | 1974-12-19 | 1974-12-19 | ∞ | 26-12-1974 | ∞ |
| فورد | روكفلر | ∞ | 20 يناير 1977 | 20 أغسطس 1974 | 1974-12-19 | 26-12-1974 | ∞ |
| فورد | روكفلر | 1974-12-19 | 20 يناير 1977 | 1974-12-19 | ∞ | 26-12-1974 | ∞ |
| كارتر | مونديل | 20 يناير 1977 | 20 يناير 1981 | 1976-11-02 | ∞ | 9 نوفمبر 1976 | ∞ |
بالنظر إلى الجدول أعلاه الذي يحتوي على تأخير لمدة 7 أيام، فإن السؤال "من كان الرئيس ونائب الرئيس خلال الفترة الصحيحة من 1977-01-01" (والذي يمكن أن يوفر بيانات عن 1976-12-25 بالنظر إلى التأخير لمدة 7 أيام) سيكون كالتالي:
- نيكسون/أغنيو عند استخدام وقت اتخاذ القرار ووقت المعاملة 14-11-1972
- نيكسون/(شاغر) عند استخدام وقت اتخاذ القرار ووقت المعاملة 1973-10-17
- نيكسون/فورد عند استخدام وقت اتخاذ القرار ووقت المعاملة 1974-08-08
- فورد/(شاغر) عند استخدام وقت اتخاذ القرار 1974-08-08 ووقت المعاملة الحالي
- فورد/روكفلر عند استخدام وقت اتخاذ القرار ووقت المعاملة الحالي
النمذجة ثنائية الزمن
يحتوي النموذج ثنائي الزمن على كلٍ من وقت الصلاحية ووقت المعاملة. يوفر هذا معلومات تاريخية ومعلومات استرجاعية . تُقدم المعلومات التاريخية (مثل: "أين كان جون يسكن عام ١٩٩٢؟") من خلال وقت الصلاحية. أما المعلومات الاسترجاعية (مثل: "أين اعتقدت قاعدة البيانات أن جون كان يسكن عام ١٩٩٢؟") فتُقدم من خلال وقت المعاملة. قد لا تكون الإجابات على هذه الأسئلة متطابقة ، إذ ربما تكون قاعدة البيانات قد عُدّلت منذ عام ١٩٩٢، مما يؤدي إلى اختلاف نتائج الاستعلامات.
لا يشترط أن يتطابق وقت الصلاحية مع وقت المعاملة لنفس المعلومة. على سبيل المثال، لنفترض قاعدة بيانات زمنية تخزن بيانات عن القرن الثامن عشر. يقع وقت صلاحية هذه المعلومات بين عامي 1701 و1800. أما وقت المعاملة فيُظهر تاريخ إدخال هذه المعلومات في قاعدة البيانات (على سبيل المثال، 21 يناير 1998).
تطور المخطط
تُعدّ مسألة دعم الاستعلامات الزمنية في قاعدة بيانات تعمل في وقت المعاملات ضمن مخطط متطور تحديًا كبيرًا . ولتحقيق جودة أرشفة مثالية، من الأهمية بمكان تخزين البيانات وفقًا لإصدار المخطط الذي ظهرت فيه لأول مرة. مع ذلك، حتى أبسط استعلام زمني يُعيد كتابة تاريخ قيمة سمة ما، سيتطلب إعادة كتابته يدويًا في كل إصدار من إصدارات المخطط، وهو ما قد يصل إلى المئات كما هو الحال في ميدياويكي . [ 7 ] ستكون هذه العملية مرهقة للغاية للمستخدمين. يتمثل أحد الحلول المقترحة في توفير إعادة كتابة تلقائية للاستعلامات، [ 8 ] [ 9 ] على الرغم من أن هذا ليس جزءًا من لغة SQL أو المعايير المشابهة.
تتمثل طرق تقليل تعقيدات تطور المخططات فيما يلي:
- استخدم قاعدة بيانات شبه مهيكلة / قاعدة بيانات NoSQL التي تقلل من تعقيدات نمذجة بيانات السمات ولكنها لا توفر ميزات للتعامل مع محاور زمنية متعددة. [ 10 ]
- استخدم قاعدة بيانات قادرة على تخزين كل من البيانات شبه المهيكلة للسمات والبيانات المهيكلة لمحاور الوقت (مثل SnowflakeDB و PostgreSQL ).
تطبيقات في منتجات بارزة
توفر التطبيقات التالية ميزات زمنية في نظام إدارة قواعد البيانات العلائقية (RDBMS).
- أضاف الإصدار 10.3.4 من MariaDB دعمًا لمعيار SQL:2011 باسم "الجداول ذات الإصدارات النظامية". [ 11 ]
- Oracle Database – Oracle Workspace Manager هي ميزة في Oracle Database تمكن مطوري التطبيقات ومديري قواعد البيانات من إدارة الإصدارات الحالية والمقترحة والتاريخية للبيانات في نفس قاعدة البيانات.
- أضاف الإصدار 9.2 من PostgreSQL أنواع بيانات نطاقية أصلية قادرة على تنفيذ جميع ميزات امتداد pgFoundry الزمني. [ 12 ] [ 13 ] وتدعم أنواع النطاقات في PostgreSQL العديد من المعاملات والدوال الأصلية.
- توفر شركة Teradata منتجين. يحتوي كل من إصدار Teradata 13.10 وإصدار Teradata 14 على ميزات زمنية تعتمد على TSQL2 [ 14 ] مدمجة في قاعدة البيانات.
- أضاف الإصدار 10 من IBM Db2 ميزة تسمى "استعلام السفر عبر الزمن" [ 2 ] والتي تعتمد على الإمكانيات الزمنية لمعيار SQL:2011 . [ 1 ]
- قدمت مايكروسوفت SQL Server ميزة الجداول المؤقتة في إصدار SQL Server 2016. وقد تم شرح هذه الميزة في فيديو على موقع "القناة 9" التابع لمايكروسوفت. [ 15 ]
أنظمة إدارة قواعد البيانات غير العلائقية (NoSQL) التي توفر ميزات زمنية تشمل ما يلي:
- TerminusDB هي قاعدة بيانات رسومية مفتوحة المصدر كاملة الميزات تدعم بشكل أصلي التحكم في الإصدارات، والاستعلامات المتعلقة بالسفر عبر الزمن، ووظائف المقارنة. تتميز ببنية طبقة غير قابلة للتغيير تعتمد على ترميز دلتا وهياكل بيانات موجزة . [ 16 ]
- أضافت MarkLogic دعم البيانات ثنائية الزمن في الإصدار 8.0. يتم تخزين الطوابع الزمنية لوقت الصلاحية ووقت النظام في مستندات JSON أو XML. [ 17 ]
كانت قواعد البيانات الزمنية من أوائل أشكال التحكم في إصدارات البيانات ، وقد أثرت على تطوير أنظمة التحكم في إصدارات البيانات الحديثة. [ 18 ]
البدائل
يمكن استخدام الأبعاد المتغيرة ببطء لنمذجة العلاقات الزمنية.
للمزيد من القراءة
- سي جيه ديت ، هيو داروين ، نيكوس لورنتزوس (2002). البيانات الزمنية والنموذج العلائقي، الطبعة الأولى (سلسلة مورغان كوفمان في أنظمة إدارة البيانات)؛ مورغان كوفمان؛ الطبعة الأولى؛ 422 صفحة. ISBN 1-55860-855-9.
- جو سيلكو (2014). لغة SQL للأذكياء من جو سيلكو: برمجة SQL المتقدمة (سلسلة مورغان كوفمان في إدارة البيانات)؛ مورغان كوفمان؛ الطبعة الخامسة. ISBN 978-0-12-800761-7— يناقش الفصلان 12 و 35 على وجه الخصوص القضايا الزمنية.
- سنودجراس، ريتشارد تي. (1999). " تطوير تطبيقات قواعد البيانات الموجهة زمنيًا في لغة SQL " (PDF) . (4.77 ميجابايت ) (سلسلة مورغان كوفمان في أنظمة إدارة البيانات)؛ مورغان كوفمان؛ 504 صفحات؛ رقم ISBN 1-55860-436-7
انظر أيضاً
مراجع
- 1 2 3 كولكارني، كريشنا، وجان-إيك ميشيلز. " الميزات الزمنية في لغة SQL: 2011 ". سجل ACM SIGMOD 41.3 (2012): 34-43.
- 1 2 ساراكو، سينثيا م.؛ نيكولا، ماتياس؛ غاندي، لينيشا (3 أبريل 2012). "مسألة وقت: إدارة البيانات الزمنية في DB2 10" . آي بي إم . مؤرشف من الأصل في 25 أكتوبر 2012. تم الاطلاع عليه في 27 أكتوبر 2020 .
- 1 2 سنودغراس، 1999، ص. 9
- ↑ ريتشارد تي. سنودغراس . "لغة الاستعلام الزمني TSQL2" . www.cs.arizona.edu . قسم علوم الحاسوب بجامعة أريزونا . تاريخ الاسترجاع: 14 يوليو 2009 .
- ↑ هيو داروين، سي جيه ديت، " نظرة عامة وتحليل للمقترحات القائمة على منهج TSQL2 "، في كتاب ديت عن قواعد البيانات: كتابات 2000-2006 ، سي جيه ديت، أبريس، 2006، الصفحات 481-514
- ↑ ماريو أ. ناسيمينتو، مارغريت هـ. إيتش، " وقت اتخاذ القرار في قواعد البيانات الزمنية "، في وقائع ورشة العمل الدولية الثانية حول التمثيل الزمني والاستدلال ، 1995، ص 157-162
- ↑ معيار تطور المخطط - تطور المخطط
- ↑ هيون ج. مون؛ كارلو أ. كورينو؛ ألين دويتش؛ سي.-واي. هو وكارلو زانيولو (2008). إدارة قواعد البيانات في وقت المعاملات والاستعلام عنها في ظل تطور المخطط . قاعدة البيانات الضخمة جدًا (VLDB). مؤرشف من الأصل بتاريخ 27-03-2024 . تم الاسترجاع بتاريخ 11-06-2008 .
- ↑ هيون ج. مون؛ كارلو أ. كورينو وكارلو زانيولو (2010). بنية قابلة للتوسع وتحسين الاستعلام لقواعد البيانات في وقت المعاملات ذات المخططات المتطورة . SIGMOD. مؤرشف من الأصل في 27 مارس 2024. تم الاسترجاع في 6 فبراير 2010 .
- ↑ أنتوني ب. كوتس (2015). لماذا تهتم البنوك بالزمنية المزدوجة . مؤتمر مارك لوجيك العالمي 2015.
- ↑ "جداول ذات إصدارات نظامية" . مؤرشف من الأصل بتاريخ 24-01-2018 . تم الاطلاع عليه بتاريخ 24-01-2018 .
- ↑ باكير، مايكل (1 نوفمبر 2012). "أبرز ميزات Postgres 9.2: أنواع النطاقات" . مايكل باكير - مطور برامج مفتوحة المصدر مقيم في اليابان . مؤرشف من الأصل بتاريخ 23 أبريل 2016.
- ↑ كاتز، جوناثان س. "أنواع النطاق: لن تكون حياتك كما كانت من قبل" (ملف PDF) . تم الاطلاع عليه بتاريخ 14 يوليو 2014 .
- ↑ الكاتب، محمد وآخرون. " معالجة الاستعلامات الزمنية في تيراداتا ". المؤتمر الدولي لتكنولوجيا البيانات/التكنولوجيا الرقمية 13، 18-22 مارس 2013، جنوة، إيطاليا
- ↑ بيانات مؤقتة في SQL Server 2016 ، مؤرشفة من الأصل بتاريخ 2021-05-07 ، تم استرجاعها بتاريخ 2019-07-19
- ↑ "terminusdb/terminusdb-server" . GitHub . تم الاسترجاع في 2020-09-04 .
- ↑ بريدج ووتر، أدريان (24 نوفمبر 2014). "البيانات جيدة، لكن البيانات ثنائية الاتجاه وثنائية الزمن أفضل" . فوربس .
- ^ بهاردواج ، أنانت. بهاتاشيرجي، سوفيك؛ شافان، أميت؛ ديشباندي، أمول؛ إلمور، آرون ج. مادن، صموئيل. باراميسواران، أديتيا ج. (02/09/2014). “DataHub: علوم البيانات التعاونية وإدارة إصدارات مجموعة البيانات على نطاق واسع”. أرخايف : 1409.0798 [ cs.DB ].
روابط خارجية
- الصفحة الرئيسية لمركز الوقت . مركز الوقت . قسم علوم الحاسوب، جامعة أريزونا. مؤرشف من الأصل بتاريخ ٢٤ فبراير ٢٠٢٠.
- العلاقات الزمنية في RDF
- النطاق الزمني لثلاثيات RDF
- IBM DB2 10 لنظام التشغيل z/OS
- سلسلة مقالات "مرارًا وتكرارًا" بقلم راندي وايس وتوم جونستون
- الأنماط الزمنية بقلم مارتن فاولر
- أنظمة إدارة قواعد البيانات
- نظرية قواعد البيانات
- معالجة المعاملات
- قواعد البيانات الزمنية