نمط العرض المتحقق

تخزين Azure

قم بإنشاء طرق عرض معبأة مسبقاً للبيانات في واحد أو أكثر من مخازن البيانات عندما لا يتم تنسيق البيانات بشكل مثالي لعمليات الاستعلام المطلوبة. يمكن أن يساعد ذلك في دعم الاستعلام واستخراج البيانات بكفاءة، وتحسين أداء التطبيق.

السياق والمشكلة

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

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

حل

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

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

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

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

المسائل والاعتبارات

راع النقاط التالية عند تحديد كيفية تنفيذ هذا النمط:

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

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

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

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

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

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

حيث تدعمها آلية التخزين، ضع في اعتبارك فهرسة العرض الفعلي لزيادة الأداء. تدعم معظم قواعد البيانات الارتباطية الفهرسة لطرق العرض، كما تفعل حلول البيانات الضخمة استناداً إلى Apache Hadoop.

موعد استخدام النمط

هذا النمط مفيد عندما:

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

هذا النمط غير مفيد في الحالات التالية:

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

تصميم حمل العمل

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

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

كما هو الحال مع أي قرار تصميم، ضع في اعتبارك أي مفاضلات ضد أهداف الركائز الأخرى التي يمكن إدخالها مع هذا النمط.

مثال

يبين الشكل التالي مثالاً على استخدام نمط طريقة العرض الفعلي لإنشاء ملخص للمبيعات. يتم دمج البيانات في جداول Order و OrderItem و Customer في أقسام منفصلة في حساب تخزين Azure لإنشاء طريقة عرض تحتوي على إجمالي قيمة المبيعات لكل منتج في فئة الإلكترونيات، بالإضافة إلى عدد العملاء الذين أجروا عمليات شراء لكل عنصر.

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

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

الخطوات التالية

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

الموارد ذات الصلة

قد تكون الأنماط الموضحة أدناه مناسبة أيضًا عند تنفيذ هذا النمط:

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

قم بإنشاء طرق عرض معبأة مسبقاً للبيانات في واحد أو أكثر من مخازن البيانات عندما لا يتم تنسيق البيانات بشكل مثالي لعمليات الاستعلام المطلوبة. يمكن أن يساعد ذلك في دعم الاستعلام واستخراج البيانات بكفاءة، وتحسين أداء التطبيق.

السياق والمشكلة

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

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

حل

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

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

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

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

المسائل والاعتبارات

راع النقاط التالية عند تحديد كيفية تنفيذ هذا النمط:

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

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

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

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

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

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

حيث تدعمها آلية التخزين، ضع في اعتبارك فهرسة العرض الفعلي لزيادة الأداء. تدعم معظم قواعد البيانات الارتباطية الفهرسة لطرق العرض، كما تفعل حلول البيانات الضخمة استناداً إلى Apache Hadoop.

موعد استخدام النمط

هذا النمط مفيد عندما:

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

هذا النمط غير مفيد في الحالات التالية:

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

تصميم حمل العمل

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

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

كما هو الحال مع أي قرار تصميم، ضع في اعتبارك أي مفاضلات ضد أهداف الركائز الأخرى التي يمكن إدخالها مع هذا النمط.

مثال

يبين الشكل التالي مثالاً على استخدام نمط طريقة العرض الفعلي لإنشاء ملخص للمبيعات. يتم دمج البيانات في جداول Order و OrderItem و Customer في أقسام منفصلة في حساب تخزين Azure لإنشاء طريقة عرض تحتوي على إجمالي قيمة المبيعات لكل منتج في فئة الإلكترونيات، بالإضافة إلى عدد العملاء الذين أجروا عمليات شراء لكل عنصر.

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

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

الخطوات التالية

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

الموارد ذات الصلة

قد تكون الأنماط الموضحة أدناه مناسبة أيضًا عند تنفيذ هذا النمط:

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