السابق

التالي

نمذجة البيانات من أجل Dataverse

مكتمل

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

أنواع الجداول

يحتوي Dataverse على ثلاثة أنواع من الجداول:

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

عند إنشاء جدول قياسي مخصص، يجب تحديد ملكيته:

• المستخدم/الفريق - الخيار الافتراضي
• المؤسسة - يُستخدم هذا الخيار للبيانات المرجعية

جداول النشاط المخصصة

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

تتمثل ميزات استخدام جداول النشاط المخصصة فِي ما يلي:

• الظهور فِي قائمة مع أنشطة أخرى.
• يمكن تجميعها مع أنشطة أخرى.
• يمكن إنشاء تبرع فِي أي جدول يدعم الأنشطة.

تتمثل أبرز عيوب استخدام جداول النشاط المخصصة فِي أنه لا يمكن:

• تكوين الأمان بصورة مختلفة عن أي نشاط آخر.
• التحكم فِي الجداول المرتبطة بتبرع ما.

أنواع بيانات الأعمدة

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

نوع البيانات	التعليقات
نعم/لا	لضمان أنك لن تحتاج إلى مزيد من الخيارات
ملف وصورة	يسمح لك بتخزين الملفات والصور المضمنة فِي Dataverse
العميل	يمكن أن يكون جهة اتصال أو حساباً
البحث/الاختيار	تأكد من اختيار الأفضل
التاريخ/الوقت	تأكد من اختيار السلوك الأفضل
رقمي	توجد العديد من الخيارات للاختيار من بينها، لذا اختر بحكمة

جدول الاختيار مقابل جدول البحث

تعتمد كيفية اتخاذ قرار بين استخدام جدول بحث أو جدول اختيار على الظروف.

استخدم جدول اختيار إذا كنت تريد جدولاً:

• لا يخزِّن سوى التسمية والقيمة كزوج قيم المفاتيح.
• يحتوي على ترجمة مضمنة.
• يتم التعامل معه كمكون حل.
• لا يحتوي على طريقة مضمنة لاستبعاد القيم.
• يحتوي على تجربة مستخدم (UX) تعمل على 200 عنصر تقريباً.
• يمكن تصفيته باستخدام JavaScript.
• يتم تخزينه كرقم صحيح فِي الصف.

استخدم جدول بحث إذا كنت تريد جدولاً:

• يمكنه تخزين بيانات أخرى فِي الأعمدة الموجودة فِي الصف.
• يتطلب منك إنشاء الترجمة.
• تتم معاملته كبيانات مرجعية.
• يدعم حالة غير نشطة.
• يحتوي على تجربة مستخدم (UX) يمكن تغيير حجمها لتشمل العديد من العناصر.
• يمكن تصفيته حسب طرق العرض والأمان.
• يتم تخزينه كمرجع كيان.

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

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

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

تعد تجربة المستخدم (UX) للاختيارات مثاليه للكمية الصغيرة، ولكنها لا تعمل بشكل جيد مع المجموعات الكبيرة. توفر عمليات البحث ميزات من نوع البحث غير متوفرة فِي الاختيارات.

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

تخزين بيانات الملفات والصور

لديك العديد من الخيارات لتخزين الملفات والصور:

• Dataverse - لتخزين الملفات والصور باستخدام أنواع بيانات الملفات والصور.
• SharePoint - يُستخدم هذا الخيار للتعاون، ولكنه يتضمن مشكلة تخص الأمان. يتبع أمان الملفات أذونات SharePoint ولا تتم مزامنتها مع أذونات صف Dataverse.
• مساحة تخزين Azure - يُستخدم للأرشفة والوصول الخارجي. يتضمن هذا الاختيار أماناً مستقلاً، ولكن يمكن منحه لفترات صغيرة من الوقت اعتماداً على ارتباط يتم إنشاؤه للاستهلاك (نمط خادم). يمكن لمساحة تخزين Azure معالجة الملفات كبيرة الحجم أيضاً.

تشمل خصائص أنواع بيانات الملفات والصور ما يلي:

• أنها جيدة للتحميل والرجوع إليها.
• يتبع الأمان أذونات السجل.
• مقيدة حسب الحجم.

الأعمدة المحسوبة

تسمح الأعمدة المحسوبة بإجراء عمليات حساب بسيطة على البيانات الموجودة فِي صف ما، وتتميز بما يلي:

• يتم حسابها عند استرداد أحد السجلات.
• تحتوي على قيمة للقراءة فقط.
• يمكن أن تحتوي على أعمدة من الصف نفسه وأعمدة فِي علاقات متعدد إلى واحد.
• يمكن أن تتضمن أعمدة القيمة المحتسبة فِي عملية الحساب.
• لا يمكن تشغيل حدث للتدفق أو المكون الإضافي أو Power Automate.

أعمدة القيمة المحتسبة

تسمح أعمدة القيمة المحتسبة بتجميعات للصفوف المرتبطة فِي علاقات واحد إلى متعدد، وتتميز بما يلي:

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

يمكنك إظهار الأعمدة المحسوبة "البسيطة"، أي أنه لا يمكن إظهار الأعمدة المحسوبة التي تتضمن وظائف غير محددة.

العلاقات

تحدّد العلاقات كيفية ارتباط الصفوف ببعضها البعض فِي Dataverse. يحتوي كل جدول فِي Dataverse على مفتاح أساسي لتوفير مرجع فريد للصفوف الموجودة فِي الجدول. في Dataverse، يكون المفتاح الأساسي معرفاً فريداً عمومياً (GUID) يتم إنشاؤه تلقائيًا بواسطة Dataverse عند إنشاء صف. يتم إنشاء العلاقات عن طريق إضافة مرجع إلى المفتاح الأساسي، والذي يُعرف بالمفتاح الخارجي. في Dataverse، يتم إنشاء العلاقات باستخدام عمود موجود فِي أحد الجداول للاحتفاظ بقيمة المفتاح الخارجي. يُعد هذا المفتاح الخارجي مؤشراً للمفتاح الأساسي فِي الجدول الآخر.

يوجد نوعان من العلاقات المدعومة فِي Dataverse:

• واحد إلى متعدد (1:N)
• متعدد إلى متعدد (N:N)

علاقة واحد إلى متعدد

يوضح تقرير المصروفات التالي مثالاً لعلاقة واحد إلى متعدد (1:N).

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

وتُعد العلاقة بين تقرير المصروفات وصنف البند مثالاً لعلاقة واحد إلى متعدد (1:N). يرتبط الجزء الرئيسي من تقرير المصروفات بأصناف بنود متعددة. يمكنك أيضاً عرض العلاقة من منظور أصناف البنود: لا يمكن ربط كل صنف بند إلا بتقرير مصروفات واحد، وهو ما يمثل علاقة متعدد إلى واحد (N:1).

علاقة متعدد إلى متعدد

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

توفر الأقسام التالية أمثلة لأنواع مختلفة من بنيات البيانات من متعدد إلى متعدد.

المثال رقم 1: طلب الموافقة على إجازة

يوضح المثال التالي مجموعتين من البيانات: إحداهما تمثل الموظف والأخرى تمثل طلب الإجازة. ونظراً لأن كل موظف سيقوم بإرسال العديد من الطلبات، فالعلاقة الموجودة فِي هذا السيناريو هي واحد إلى متعدد، حيث يتمثل "واحد" فِي الموظف و"متعدد" فِي الطلبات. ترتبط بيانات الموظف وبيانات طلب الإجازة ببعضها البعض عن طريق جعل رقم الموظف هو العمود المشترك (يُعرف أيضاً بالمفتاح).

المثال رقم 2: الموافقة على الشراء

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

ونظراً لأن الموظفين قد لا يستخدمون المورد أو الموفر نفسه دائماً، يتم استخدام الموردين من قِبل موظفين متعددين ويعمل كل موظف على عدة موردين. بناءً عليه، فان العلاقة بين الموظفين والموردين هي علاقة متعدد إلى متعدد.

المثال رقم 3: تقارير المصروفات

يوضح المثال التالي مخطط علاقة كيان (ERD) يحتوي على العديد من الجداول لحل تقارير المصروفات.

المثال رقم 4: تعقب الميزتين اللتين حددتهما الشخصية الهامة

يتميز هذا المثال بوجود شخصيتين هامتين: John وMary. اختار John الميزتين شبكة WiFi وغسيل الملابس، واختارت Mary الميزتين شبكة WiFi والثلاجة الصغيرة. يمكنك نمذجة هذا السيناريو بطرق مختلفة. الطريقة الأولى هي نمذجة السيناريو كعلاقة 1:N.

في هذا التكوين:

• سجل الميزات فريد لجهة الاتصال.
• لا تتوفر أي إمكانية للنظر فِي كل جهات الاتصال التي تختار ميزة معينة.
• يمكنك إجراء أمان سجل الميزة استناداً إلى مالك جهة الاتصال.
• يمكنك تخزين المزيد من البيانات فِي سجل الميزة الخاص بجهة الاتصال.
• وتكون العلاقة هي الأصل لهذه الميزة، وبخلاف ذلك، سيتم عزل سجلات الميزة.

الطريقة الثانية هي نمذجة السيناريو كعلاقة N:N.

في هذا التكوين:

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

لا يُعد أي من التكوينين مثالياً.

يوضح المثال التالي إنشاء جدول مخصص (تقاطع) للاحتفاظ بميزات الشخصية الهامة.

هذا التكوين:

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

يوضح المثال التالي استخدام الأعمدة الموجودة فِي جدول جهات الاتصال.

هذا التكوين:

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

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

سلوكيات العلاقة

تتحكم سلوكيات العلاقة فِي كيفية تتالي بعض الإجراءات لأسفل إلى الصفوف المرتبطة بصف الجدول الأساسي من خلال علاقة 1:N. تحتفظ السلوكيات بالتكامل المرجعي كما أنها تمنع نسيان السجلات المعزولة.

هام

يُعد تحديد سلوكيات العلاقات هاماً نظراً لأن تتالي السجلات المعينة يمكن أن يتسبب فِي تعيين السجلات المرتبطة. في حالة الشك، قم بتعيين السلوك على مرجعي ومقيد.

المفاتيح البديلة

يتم استخدام المفاتيح البديلة فِي التكاملات لتقليل الحاجة إلى إجراء استعلام للبحث عن سجل. باستخدام مفتاح بديل، يمكنك تحديث صف دون معرفة GUID.

المفاتيح البديلة:

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

عند إنشاء مفتاح، يتحقق النظام من إمكانية دعم هذا المفتاح بواسطة النظام الأساسي.

أفضل ممارسات المخطط

عند إنشاء مخططات ERD الخاصة بـ Dataverse، يجب عليك القيام بما يلي:

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

متابعة