لماذا نحتاج إلى قاعدة بيانات زمنية؟

https://stackoverflow.com/questions/800331

03-07-2019
|

سؤال

كنت أقرأ عن قواعد البيانات المؤقتة ويبدو أنها بنيت في جوانب زمنية.أتساءل لماذا نحتاج إلى مثل هذا النموذج؟

ما مدى اختلافه عن نظام RDBMS العادي؟ألا يمكن أن يكون لدينا قاعدة بيانات عادية، أي؟RDBMS ونقول هل لديك مشغل يربط طابعًا زمنيًا بكل معاملة تحدث؟قد يكون هناك نجاح في الأداء.لكنني ما زلت متشككًا في أن قواعد البيانات المؤقتة لها حجة قوية في السوق.

هل تدعم أي من قواعد البيانات الحالية مثل هذه الميزة؟

المحلول

وقاعدة بيانات الزمنية بكفاءة بتخزين سلسلة زمنية من البيانات، وعادة من خلال وجود بعض زمني ثابت (مثل ثانية أو حتى ميلي ثانية) ومن ثم تخزين التغييرات الوحيدة في البيانات المقاسة. A الطابع الزمني في RDBMS هو القيمة المخزنة بتحفظ لكل قياس، والتي هي غير فعالة للغاية. وكثيرا ما يستخدم قاعدة بيانات الزمنية في مراقبة التطبيقات في الوقت الحقيقي مثل SCADA. نظام راسخة هو قاعدة البيانات PI من OSISoft ( http://www.osisoft.com/ ).

نصائح أخرى

ضع في اعتبارك موعدك/مذكراتك اليومية - فهي تبدأ من 1 يناير إلى 31 ديسمبر.يمكننا الآن الاستعلام عن المواعيد/إدخالات دفتر اليومية في اليوميات في أي يوم.ويسمى هذا الترتيب وقت الصلاحية.ومع ذلك، لا يتم عادةً إدراج المواعيد/الإدخالات بالترتيب.

لنفترض أنني أرغب في معرفة المواعيد/الإدخالات الموجودة في مذكراتي في الرابع من أبريل.أي كل السجلات التي كانت موجودة في مذكراتي في الرابع من أبريل.هذا ال وقت المعاملة.

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

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

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

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

يجب أن توفر قيود الاستبعاد PostgreSQL 9.0 طرقًا جديدة لتنظيم البيانات المؤقتة، على سبيل المثال.يجب ألا تتداخل المعاملة والفترات الزمنية الصالحة لنفس المجموعة.

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

داروين ودايت ولورنتزوس"البيانات الزمنية والنموذج العلائقي" (نفدت طبعته)،
و (بدرجة مختلفة جذريًا) "تطوير تطبيقات قواعد البيانات الموجهة نحو الوقت في SQL"، ريتشارد ت.سنودجراس، مورجان كوفمان للنشر، سان فرانسيسكو، يوليو، 1999، 504+xxiii صفحة، ISBN 1-55860-436-7.لقد نفدت طبعته ولكنه متاح بصيغة PDF على موقعه على الإنترنت على cs.arizona.edu (لذا فإن بحث Google يسهل العثور عليه).

وغالبا ما تستخدم

وقواعد البيانات الزمانية في قطاع الخدمات المالية. أحد الأسباب هو أن كنت نادرا ما (إذا كان أي وقت مضى) يسمح لحذف أي بيانات، لذلك ValidFrom - تستخدم حقول نوع ValidTo على السجلات تعتبر مؤشرا عندما كان سجل الصحيح

وبصرف النظر عن قراءة مقالة ويكيبيديا؟قاعدة البيانات التي تحتفظ بـ "سجل التدقيق" أو سجل المعاملات المشابه سيكون لها بعض خصائص كونها "مؤقتة".إذا كنت بحاجة إلى إجابات لأسئلة حول من فعل ماذا ولمن ومتى إذن لديك مرشح جيد لقاعدة البيانات المؤقتة.

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

وعلى الرغم من هذا، هو مجرد عادة تخزين البيانات الزمني في RDBMS العادي. الإنترنت، على سبيل المثال لديها بعض ملحقات الزمنية ، مما يجعل من الأسهل هذا قليلا.

يتبادر إلى ذهني سببان:

تم تحسين بعضها للإدراج والقراءة فقط ويمكن أن تقدم تحسينات كبيرة في الأداء
يتمتع البعض بفهم أفضل للوقت مقارنة بـ SQL التقليدية - مما يسمح بتجميع العمليات حسب الثانية والدقيقة والساعة وما إلى ذلك

وفقط تحديثا، قاعدة بيانات الزمنية القادمة إلى SQL Server 2016.

لمسح كل ما تبذلونه من الشكوك لماذا يحتاج المرء قاعدة بيانات الزمنية، بدلا من تكوين مع طرق مخصصة، ومدى كفاءة وبسلاسة خادم SQL بتكوين لانها لكم، والتحقق من الفيديو في العمق والعرض على Channel9.msdn هنا: <ل أ href = "https://channel9.msdn.com/Shows/Data-Exposed/Temporal-in-SQL-Server-2016" يختلط = "نوفولو"> https://channel9.msdn.com/Shows/Data-Exposed / الزمانية-في-SQL الخادم 2016

وصلة MSDN: HTTPS: // MSDN. microsoft.com/en-us/library/dn935015(v=sql.130).aspx

وحاليا مع CTP2 (بيتا 2) إصدار SQL Server 2016 يمكنك اللعب معها.

هذا الفيديو على كيفية استخدام الجداول الزمنية في SQL Server 2016.

إلى جانب "ما الأشياء الجديدة التي يمكنني فعلها بها"، قد يكون من المفيد التفكير في "ما هي الأشياء القديمة التي توحدها؟".تمثل قاعدة البيانات المؤقتة تعميمًا خاصًا لقاعدة بيانات SQL "العادية".على هذا النحو، قد يمنحك حلاً موحدًا للمشاكل التي بدت سابقًا غير ذات صلة.على سبيل المثال:

تزامن الويب عندما تحتوي قاعدة البيانات الخاصة بك على واجهة مستخدم ويب تتيح لعدة مستخدمين إجراء تعديلات قياسية للإنشاء/التحديث/الحذف (CRUD)، يتعين عليك مواجهة المشكلة مشكلة تغييرات الويب المتزامنة.في الأساس، تحتاج إلى التحقق من أن تعديل البيانات الواردة لا يؤثر على أي سجلات تم تغييرها منذ آخر مرة شاهد فيها هذا المستخدم هذه السجلات.ولكن إذا كانت لديك قاعدة بيانات مؤقتة، فمن المحتمل جدًا أنها تربط بالفعل شيئًا مثل "معرف المراجعة" بكل سجل (نظرًا لصعوبة جعل الطوابع الزمنية فريدة وتصاعدية بشكل رتيب).إذا كان الأمر كذلك، فستصبح هذه الآلية الطبيعية "المضمنة بالفعل" لمنع تشابك بيانات المستخدمين الآخرين أثناء تحديثات قاعدة البيانات.
السجلات القانونية/الضريبية يركز النظام القانوني (بما في ذلك الضرائب) على البيانات التاريخية أكثر مما يفعل معظم المبرمجين.وهكذا، سوف تجد في كثير من الأحيان نصيحة حول مخططات الفواتير ولهذا تحذرك من حذرة حذف السجلات أو التطبيع بطريقة طبيعية-والتي يمكن أن تؤدي إلى عدم القدرة على الإجابة على الأسئلة القانونية الأساسية مثل "نسيان عنوانهم الحالي ، ما هو العنوان الذي أرسلته إلى هذه الفاتورة في عام 2001 ؟ " مع قاعدة إطار زمنية ، تختفي جميع المكائد لتلك المشكلات (عادة ما تكون خطوات في منتصف الطريق إلى وجود قاعدة بيانات زمنية).ما عليك سوى استخدام المخطط الأكثر طبيعية، والحذف عندما يكون ذلك منطقيًا، مع العلم أنه يمكنك دائمًا العودة والإجابة على الأسئلة التاريخية بدقة.

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

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

وهو أن تتجه أفهمه من قواعد البيانات الزمانية نحو تخزين أنواع معينة من المعلومات الزمنية. هل يمكن محاكاة ذلك مع RDBMS القياسية، ولكن باستخدام قاعدة البيانات التي تدعم ذلك كنت قد بنيت في التعابير لكثير من المفاهيم ولغة الاستعلام قد يكون الأمثل لهذا النوع من الاستعلامات.

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

وهناك قواعد البيانات الأكاديمية وبعض منها تجارية. Timecenter لديه بعض الروابط.

وثمة مثال آخر من حيث قاعدة بيانات الزمنية مفيدة هو المكان تغييرات البيانات مع مرور الوقت. قضيت بضعة سنوات من العمل لمتاجر التجزئة الكهرباء حيث قمنا بتخزين قراءات العدادات لمدة 30 دقيقة كتل من الزمن. يمكن تنقيح تلك قراءات العدادات في أي لحظة ولكن ما زلنا بحاجة إلى أن تكون قادرة أن ننظر إلى الوراء في التاريخ من التغييرات للقراءات.

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

و(أما وقد قلت ذلك، ونحن جهة منحوتة في SQL، لكنها كانت نزيهة منذ فترة. لن اتخاذ هذا القرار في هذه الأيام).

مرخصة بموجب: CC-BY-SA مع الإسناد

لا تنتمي إلى StackOverflow