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