مرحبًا! اسمي أندريه سيمينوف، وأنا أحد كبار المحللين في Sportmaster. في هذا المنشور أريد أن أثير مسألة عدم تسوية قواعد بيانات نظام تخطيط موارد المؤسسات (ERP). سننظر إلى الظروف العامة، بالإضافة إلى مثال محدد - لنفترض أنها ستكون حانة احتكارية رائعة للقراصنة والبحارة. حيث يجب أن يتم خدمة القراصنة والبحارة بشكل مختلف، لأن أفكار الجمال وأنماط المستهلك لهؤلاء السادة الطيبين تختلف بشكل كبير.
كيف تجعل الجميع سعداء؟ كيف يمكنك تجنب الجنون في تصميم وصيانة مثل هذا النظام؟ ماذا تفعل إذا لم يبدأ القراصنة والبحارة المعتادون فقط في القدوم إلى الحانة؟
كل شيء تحت الخفض. ولكن دعونا نذهب بالترتيب.
1. القيود والافتراضات
كل ما سبق ينطبق فقط على قواعد البيانات العلائقية. لا يتم النظر في عواقب عدم التطبيع في شكل شذوذات التعديل والحذف والإدراج، والتي تمت تغطيتها جيدًا، بما في ذلك على الإنترنت. خارج نطاق هذا المنشور، هناك حالات يكون فيها إلغاء التطبيع مكانًا شائعًا، مع الأمثلة الكلاسيكية: سلسلة جواز السفر ورقمه، والتاريخ والوقت، وما إلى ذلك.
يستخدم المنشور تعريفات بديهية وقابلة للتطبيق عمليًا للأشكال العادية، دون الإشارة إلى المصطلحات الرياضية. بالشكل الذي يمكن تطبيقها به على فحص العمليات التجارية الحقيقية (BP) وتصميم البرامج الصناعية.
يقال إن تصميم مستودعات البيانات وأدوات إعداد التقارير واتفاقيات التكامل (التي تستخدم تمثيلات جدولية للمعلومات) يختلف عن تصميم قواعد بيانات نظام تخطيط موارد المؤسسات (ERP) في سهولة الاستهلاك واستخدام عدم التطبيع الواعي لتحقيق ذلك قد يكون له الأسبقية على النزاهة بيانات الحماية. أشارك هذا الرأي، وما هو موضح أدناه ينطبق فقط على البيانات الرئيسية ونماذج بيانات المعاملات لأنظمة تخطيط موارد المؤسسات (ERP).
يتم تقديم شرح للأشكال العادية باستخدام مثال مفهوم على المستوى اليومي لمعظم القراء. ومع ذلك، كتوضيح مرئي، في الفقرات 4-5، تم استخدام مهمة "خيالية" عمدا. إذا لم تفعل ذلك وأخذت بعض أمثلة الكتب المدرسية، على سبيل المثال، نفس نموذج تخزين الطلب من النقطة 2، فقد تجد نفسك في موقف حيث سيتم تحويل تركيز القارئ من التحلل المقترح للعملية إلى نموذج، للتجربة الشخصية والإدراك لكيفية بناء العمليات والنماذج لتخزين البيانات في نظم المعلومات. بمعنى آخر، خذ اثنين من محللي تكنولوجيا المعلومات المؤهلين، دع أحدهما يقدم الخدمات للوجستيين الذين ينقلون الركاب، والآخر للوجستيين الذين ينقلون آلات إنتاج الرقائق الدقيقة. اطلب منهم، دون مناقشة نقاط العمل الآلية مسبقًا، إنشاء نموذج بيانات لتخزين المعلومات حول رحلة بالقطار.
هناك احتمال غير صفر بأن تجد في النماذج المقترحة ليس فقط مجموعة مختلفة بشكل ملحوظ من السمات، ولكن أيضًا مجموعات متباينة من الكيانات، لأن كل محلل سيعتمد على العمليات والمهام المألوفة له. وفي مثل هذه الحالة، من المستحيل تحديد النموذج "الصحيح"، لأنه لا يوجد معيار للتقييم.
2. الأشكال العادية
النموذج العادي الأول لقاعدة البيانات يتطلب ذرية جميع الصفات.
على وجه الخصوص، إذا كان الكائن A يحتوي على سمات غير أساسية a وb، مثل c=f(a,b) وفي الجدول الذي يصف الكائن A قمت بتخزين قيمة السمة c، فسيتم انتهاك النموذج العادي الأول في قاعدة البيانات . على سبيل المثال، إذا كانت مواصفات الطلب تشير إلى كمية، تعتمد وحدات قياسها على نوع المنتج: في حالة واحدة يمكن أن تكون قطع، في أخرى لتر، في عبوات ثالثة تتكون من قطع (في النموذج أعلاه Good_count_WR) ، ثم يتم انتهاك ذرية السمات في قاعدة البيانات. في هذه الحالة، من أجل تحديد ما يجب أن تكون عليه مجموعة الجدول الخاصة بمواصفات الطلب، فأنت بحاجة إلى وصف مستهدف لعملية العمل في IS، وبما أن العمليات قد تكون مختلفة، فقد يكون هناك العديد من الإصدارات "الصحيحة".
النموذج العادي الثاني لقاعدة البيانات يتطلب الالتزام بالنموذج الأول والجدول الخاص به لكل جهة ذات علاقة بسير العمل في نظام المعلومات. إذا كانت هناك تبعيات في أحد الجداول c=f1(a) وd=f2(b) ولا توجد تبعيات c=f3(b)، فسيتم انتهاك النموذج العادي الثاني في الجدول. في المثال أعلاه، لا توجد تبعية بين الطلب والعنوان في جدول الطلب. قم بتغيير اسم الشارع أو المدينة ولن يكون لك أي تأثير على السمات الأساسية للأمر.
قاعدة بيانات النموذج العادي الثالث يتطلب الالتزام بالشكل العادي الثاني وغياب التبعيات الوظيفية بين سمات الكيانات المختلفة. ويمكن صياغة هذه القاعدة على النحو التالي: "كل ما يمكن حسابه يجب حسابه". بمعنى آخر، إذا كان هناك كائنان A وB. في الجدول الذي يخزن سمات الكائن A، تظهر السمة C، والكائن B له السمة b، بحيث يكون c=f4(b) موجودًا، ثم الشكل العادي الثالث تم انتهاكه. في المثال أدناه، تدعي سمة كمية القطع (Total_count_WR) في سجل الطلب بوضوح أنها تنتهك النموذج العادي الثالث
3. منهجي في تطبيق التطبيع
1. يمكن فقط لعملية الأعمال الآلية المستهدفة أن توفر للمحلل معايير لتحديد الكيانات والسمات عند إنشاء نموذج تخزين البيانات. يعد إنشاء نموذج عملية شرطًا أساسيًا لإنشاء نموذج بيانات عادي.
2. إن تحقيق الشكل الطبيعي الثالث بالمعنى الدقيق للكلمة قد لا يكون عملياً في الممارسة الفعلية لإنشاء أنظمة تخطيط موارد المؤسسات (ERP) إذا تم استيفاء بعض أو كل الشروط التالية:
- نادراً ما تخضع العمليات الآلية للتغيير،
- المواعيد النهائية للبحث والتطوير ضيقة،
- متطلبات سلامة البيانات منخفضة نسبيًا (الأخطاء المحتملة في البرامج الصناعية لا تؤدي إلى خسارة الأموال أو العملاء من قبل عميل البرنامج)
- إلخ
في ظل الظروف الموصوفة، قد لا يكون من الممكن تبرير تكاليف تحديد ووصف دورة حياة بعض الأشياء وخصائصها من وجهة نظر الكفاءة الاقتصادية.
3. يمكن التخفيف من أي عواقب لعدم تسوية نموذج البيانات في نظام المعلومات الذي تم إنشاؤه بالفعل من خلال دراسة أولية شاملة للكود والاختبار.
4. تعد عملية إلغاء التطبيع وسيلة لنقل تكاليف العمالة من مرحلة البحث عن مصادر البيانات وتصميم عملية الأعمال إلى مرحلة التطوير، من فترة التنفيذ إلى فترة تطوير النظام.
5. من المستحسن السعي للحصول على الشكل العادي الثالث لقاعدة البيانات إذا:
- من الصعب التنبؤ باتجاه التغيير في العمليات التجارية الآلية
- هناك تقسيم ضعيف للعمل ضمن فريق التنفيذ و/أو التطوير
- تتطور الأنظمة المتضمنة في دائرة التكامل وفقًا لخططها الخاصة
- يمكن أن يؤدي عدم تناسق البيانات إلى خسارة الشركة للعملاء أو الأموال
6. يجب أن يتم تصميم نموذج البيانات بواسطة محلل فقط فيما يتعلق بنماذج عملية الأعمال المستهدفة والعملية في نظام المعلومات. إذا كان المطور يقوم بتصميم نموذج بيانات، فسيتعين عليه الانغماس في مجال الموضوع إلى الحد الذي يفهم فيه، على وجه الخصوص، الفرق بين قيم السمات - وهو شرط ضروري لعزل السمات الذرية. وبالتالي، القيام بوظائف غير عادية.
4 مشكلة للتوضيح
لنفترض أن لديك حانة آلية صغيرة في الميناء. قطاع السوق الخاص بك: البحارة والقراصنة الذين يأتون إلى الميناء ويحتاجون إلى فترة راحة. أنت تبيع الشاي مع الزعتر للبحارة، والروم وأمشاط العظام لتمشيط اللحى للقراصنة. يتم تقديم الخدمة في الحانة نفسها بواسطة مضيفة روبوتية ونادل آلي. بفضل الجودة العالية والأسعار المنخفضة، قمت بطرد منافسيك، بحيث يأتي كل من ينزل من السفينة إلى الحانة الخاصة بك، وهي الوحيدة في الميناء.
يتكون مجمع أنظمة معلومات الحانة من البرامج التالية:
- نظام إنذار مبكر عن العميل الذي يتعرف على فئته بناءً على السمات المميزة
- نظام التحكم لمضيفات الروبوت والسقاة الروبوت
- نظام إدارة المستودعات والتسليم إلى نقطة البيع
- نظام إدارة علاقات الموردين (SURP)
عملية:
يتعرف نظام الإنذار المبكر على الأشخاص الذين يغادرون السفينة. إذا كان الشخص حليق الذقن، فتعرفه على أنه بحار، وإذا وجد أن الشخص له لحية، فهو يعرفه على أنه قرصان.
عند دخول الحانة، يسمع الضيف تحية من المضيفة الآلية وفقًا لفئته، على سبيل المثال: "Ho-ho-ho، عزيزي القرصان، اذهب إلى الطاولة رقم..."
يذهب الضيف إلى الطاولة المحددة، حيث قام النادل الآلي بإعداد البضائع له وفقًا للفئة. ينقل النادل الآلي معلومات إلى نظام المستودع مفادها أنه يجب زيادة الجزء التالي من التسليم؛ ويقوم نظام معلومات المستودع، استنادًا إلى الأرصدة المتبقية في التخزين، بإنشاء طلب شراء في نظام الإدارة.
في حين أن نظام الإنذار المبكر ربما تم تطويره بواسطة قسم تكنولوجيا المعلومات الداخلي لديك، فقد يكون برنامج إدارة الروبوت الشريطي قد تم إنشاؤه بواسطة مقاول خارجي خصيصًا لشركتك. وأنظمة إدارة المستودعات والعلاقات مع الموردين عبارة عن حلول معبأة حسب الطلب من السوق.
5. أمثلة على عدم التطبيع وتأثيره على تطوير البرمجيات
عند تصميم عملية تجارية، ذكر الخبراء المختصون الذين تمت مقابلتهم بالإجماع أن القراصنة في جميع أنحاء العالم يشربون مشروب الروم ويمشطون لحاهم بأمشاط العظام، ويشرب البحارة الشاي مع الزعتر ويحلقون شعرهم دائمًا.
يظهر دليل أنواع العملاء بقيمتين: 1 - قراصنة، 2 - بحارة، مشترك لدائرة المعلومات الكاملة للشركة.
يقوم نظام إعلام العميل على الفور بتخزين نتيجة معالجة الصور كمعرف (ID) للعميل المعترف به ونوعه: بحار أو قرصان.
معرف الكائن المعترف به
فئة العميل
100500
قرصان
100501
قرصان
100502
بحار
ولنلاحظ ذلك مرة أخرى
1. البحارة لدينا هم في الواقع أناس حليقي الشعر
2. قراصنةنا هم في الواقع أناس ملتحون
ما هي المشاكل في هذه الحالة التي يجب حلها حتى يسعى هيكلنا إلى الشكل الطبيعي الثالث:
- انتهاك ذرية السمة - فئة العميل
- خلط الحقيقة التي تم تحليلها مع النتيجة في جدول واحد
- علاقة وظيفية ثابتة بين سمات الكيانات المختلفة.
في الصيغة الطبيعية سنحصل على جدولين:
- نتيجة الاعتراف في شكل مجموعة من الميزات الراسخة ،
معرف الكائن المعترف به
شعر الرجه
100500
نعم
100501
نعم
100502
لا
- نتيجة تحديد نوع العميل كتطبيق للمنطق المضمن في IS لتفسير الخصائص المحددة
معرف الكائن المعترف به
معرف الهوية
فئة العميل
100500
100001
قرصان
100501
100002
قرصان
100502
100003
بحار
كيف يمكن لمنظمة تخزين البيانات الطبيعية أن تسهل تطوير مجمع الملكية الفكرية؟ لنفترض أنك حصلت فجأة على عملاء جدد. فليكن القراصنة اليابانيين الذين قد لا يكون لديهم لحية، لكنهم يمشون وببغاء على أكتافهم، وقراصنة البيئة، يمكنك التعرف عليهم بسهولة من خلال صورة غريتا الزرقاء على صدرها الأيسر.
وبطبيعة الحال، لا يستطيع قراصنة البيئة استخدام أمشاط العظام ويطالبون بنظير مصنوع من البلاستيك البحري المعاد تدويره.
تحتاج إلى إعادة صياغة خوارزميات البرنامج وفقًا للمدخلات الجديدة. إذا تم اتباع قواعد التطبيع، فلن يتعين عليك سوى استكمال المدخلات لبعض فروع العملية في بعض الأنظمة وإنشاء فروع جديدة فقط لتلك الحالات وفي وحدات المعلومات التي يكون فيها شعر الوجه مهمًا. ولكن، نظرًا لعدم اتباع القواعد، سيتعين عليك تحليل الكود بالكامل، في جميع أنحاء الدائرة بأكملها، حيث يتم استخدام قيم دليل نوع العميل وتثبت بوضوح أنه في حالة واحدة يجب أن تأخذ الخوارزمية في الاعتبار المعايير المهنية نشاط العميل، وفي السمات المادية الأخرى.
بالشكل الذي تهدف إلى للتطبيع، سنحصل على جدولين ببيانات تشغيلية ودليلين:
- نتيجة الاعتراف في شكل مجموعة من الميزات الراسخة ،
معرف الكائن المعترف به
غريتا على الصدر الأيسر
طائر على الكتف
شعر الرجه
100510
1
1
1
100511
0
0
1
100512
1
0
- نتيجة تحديد نوع العميل (ليكن عرضًا مخصصًا يتم فيه عرض الأوصاف من الدلائل)
هل يعني عدم التطبيع المكتشف أنه لا يمكن تعديل الأنظمة لتلبية الظروف الجديدة؟ بالطبع لا. إذا تخيلنا أن جميع أنظمة المعلومات تم إنشاؤها من قبل فريق واحد مع عدم وجود معدل دوران للموظفين، وأن التطورات موثقة بشكل جيد ويتم نقل المعلومات داخل الفريق دون خسارة، فيمكن إجراء التغييرات المطلوبة بجهد لا يكاد يذكر. ولكن إذا عدنا إلى الظروف الأصلية للمشكلة، فسيتم مسح 1,5 لوحة مفاتيح فقط لطباعة بروتوكولات المناقشات المشتركة و0,5 أخرى لمعالجة إجراءات الشراء.
في المثال أعلاه، تم انتهاك النماذج الثلاثة العادية، فلنحاول انتهاكها بشكل منفصل.
انتهاك النموذج العادي الأول:
لنفترض أنه تم تسليم البضائع إلى مستودعك من مستودعات الموردين عن طريق الاستلام باستخدام غزال واحد يبلغ وزنه 1.5 طن ينتمي إلى الحانة الخاصة بك. حجم طلباتك صغير جدًا بالنسبة إلى معدل دوران الموردين بحيث يتم إكمالها دائمًا بشكل فردي دون انتظار الإنتاج. هل تحتاج إلى جداول منفصلة مع مثل هذه العملية التجارية: المركبات، وأنواع المركبات، هل من الضروري فصل الخطة عن الحقيقة في طلباتك للموردين المغادرين؟
فقط تخيل عدد الاتصالات "الإضافية" التي سيتعين على المبرمجين لديك كتابتها إذا استخدمت النموذج أدناه لتطوير البرنامج.
لنفترض أننا قررنا أن الهيكل المقترح معقد بشكل غير ضروري؛ في حالتنا، يعد الفصل بين الخطة والحقيقة في سجل الطلب معلومات زائدة عن الحاجة، وتتم إعادة كتابة مواصفات الطلب التي تم إنشاؤها بناءً على نتائج قبول البضائع التي وصلت، وهو خطأ نادر - تتم تسوية تصنيف ووصول البضائع ذات الجودة غير الكافية خارج نظام المعلومات.
ثم في أحد الأيام ترى كيف تمتلئ قاعة الحانة بأكملها بالقراصنة الساخطين والأشعث. ماذا حدث؟
اتضح أنه مع نمو عملك، زاد استهلاكك أيضًا. ذات مرة، تم اتخاذ قرار إداري بأنه إذا كانت الغزالة محملة بحمولة زائدة من حيث الحجم و/أو الوزن، وهو أمر نادر للغاية، فإن المورد سيعطي الأولوية للحمولة لصالح المشروبات.
انتهى الأمر بالبضائع غير المسلمة بالطلب التالي وغادرت في رحلة جديدة، كما أن وجود الحد الأدنى من الرصيد في المستودع في الحانة جعل من الممكن عدم ملاحظة الحالات المفقودة.
أغلق آخر منافس في الميناء، وأصبحت حالة الحمولة الزائدة للغزال، والتي تم تجاوزها عن طريق تحديد الأولويات على أساس افتراض كفاية الحد الأدنى للرصيد والتنزيل الدوري للمركبة، ممارسة شائعة. سيعمل النظام الذي تم إنشاؤه بشكل مثالي وفقًا للخوارزميات المضمنة فيه وسيتم حرمانه من أي فرصة لتتبع الفشل المنهجي في تنفيذ الطلبات المخطط لها. لن يتمكن من اكتشاف المشكلة سوى السمعة المتضررة والعملاء غير الراضين.
ربما لاحظ القارئ اليقظ أن الكمية المطلوبة في مواصفات الطلب (T_ORDER_SPEC) في القسم 2 والقسم 5 قد تفي أو لا تفي بمتطلبات النموذج العادي الأول. كل هذا يتوقف على ما إذا كانت وحدات القياس المختلفة يمكن أن تقع في نفس المجال، بالنظر إلى مجموعة السلع المختارة.
مخالفة النموذج العادي الثاني:
مع نمو احتياجاتك، يمكنك شراء عدة مركبات بأحجام مختلفة. في السياق المذكور أعلاه، تم اعتبار إنشاء دليل المركبات أمرًا زائدًا عن الحاجة؛ ونتيجة لذلك، فإن جميع خوارزميات معالجة البيانات التي تخدم احتياجات التسليم والمستودعات تنظر إلى حركة البضائع من المورد إلى المستودع على أنها رحلة جوية حصرية بوزن 1,5 طن غزال. لذا، إلى جانب شراء مركبات جديدة، لا يزال بإمكانك إنشاء دليل مركبات، ولكن عند الانتهاء منه، سيتعين عليك تحليل جميع التعليمات البرمجية التي تشير إلى حركة البضائع لمعرفة ما إذا كانت المراجع في كل مكان محدد تشير ضمنيًا إلى الخصائص من السيارة نفسها التي بدأ العمل منها.
مخالفة النموذج العادي الثالث:
في مرحلة ما، عندما تبدأ في إنشاء برنامج ولاء، يظهر سجل العميل العادي. لماذا، على سبيل المثال، قضاء بعض الوقت في إنشاء طرق عرض مادية تخزن البيانات المجمعة عن المبيعات لعميل فردي لاستخدامها في إعداد التقارير ونقلها إلى الأنظمة التحليلية، إذا كان من الممكن في بداية برنامج الولاء وضع كل ما يهم العميل في سجل العميل ؟ وبالفعل، للوهلة الأولى، لا يوجد أي معنى. ولكن في كل مرة يتصل عملك، على سبيل المثال، بقنوات مبيعات جديدة، يجب أن يكون هناك شخص بين المحللين لديك سيتذكر وجود سمة التجميع هذه.
عند تصميم كل عملية جديدة، على سبيل المثال، المبيعات عبر الإنترنت، والمبيعات من خلال الموزعين المتصلين بنظام ولاء مشترك، يجب على شخص ما أن يضع في اعتباره أن جميع العمليات الجديدة يجب أن تضمن سلامة البيانات على مستوى الكود. بالنسبة لقاعدة بيانات صناعية تحتوي على آلاف الجداول، تبدو هذه مهمة مستحيلة.
يعرف المطور ذو الخبرة، بالطبع، كيفية إيقاف جميع المشكلات المذكورة أعلاه، ولكن، في رأيي، مهمة المحلل ذو الخبرة ليست إلقاء الضوء عليها.
أود أن أعرب عن امتناني للمطور الرائد إيفجيني ياروخين لملاحظاته القيمة أثناء إعداد المنشور.
أدب
كونولي توماس، بيج كارولين. قاعدة البيانات. التصميم والتنفيذ والدعم. النظرية والتطبيق
المصدر: www.habr.com