ہیلو! میرا نام Andrey Semenov ہے، میں Sportmaster میں سینئر تجزیہ کار ہوں۔ اس پوسٹ میں میں ERP سسٹم ڈیٹا بیس کے غیر معمولی ہونے کا مسئلہ اٹھانا چاہتا ہوں۔ ہم عام حالات کے ساتھ ساتھ ایک مخصوص مثال پر بھی نظر ڈالیں گے - آئیے کہتے ہیں کہ یہ قزاقوں اور ملاحوں کے لیے ایک شاندار اجارہ دار ہوٹل ہوگا۔ جس میں بحری قزاقوں اور ملاحوں کو مختلف طریقے سے پیش کیا جانا چاہیے، کیونکہ ان اچھے حضرات کے حسن اور صارفین کے خیالات نمایاں طور پر مختلف ہیں۔
سب کو خوش کیسے کیا جائے؟ آپ اس طرح کے نظام کو ڈیزائن اور برقرار رکھنے کے پاگل ہونے سے کیسے بچ سکتے ہیں؟ اگر نہ صرف عام قزاق اور ملاح ہوٹل میں آنا شروع ہو جائیں تو کیا کریں؟
سب کچھ کٹ کے نیچے ہے۔ لیکن آئیے ترتیب سے چلتے ہیں۔
1. حدود اور مفروضات
مندرجہ بالا تمام کا اطلاق صرف متعلقہ ڈیٹا بیس پر ہوتا ہے۔ ترمیم، حذف، اور اندراج کی بے ضابطگیوں کی شکل میں غیر معمولی ہونے کے نتائج، جن کا اچھی طرح احاطہ کیا گیا ہے، بشمول انٹرنیٹ پر، پر غور نہیں کیا جاتا ہے۔ اس اشاعت کے دائرہ کار سے باہر ایسے معاملات ہیں جہاں غیر نارملائزیشن ایک عام جگہ ہے، کلاسک مثالوں کے ساتھ: پاسپورٹ سیریز اور نمبر، تاریخ اور وقت وغیرہ۔
پوسٹ میں ریاضی کی اصطلاحات کے حوالے کے بغیر، عام شکلوں کی بدیہی اور عملی طور پر قابل اطلاق تعریفیں استعمال کی گئی ہیں۔ اس فارم میں جس میں انہیں حقیقی کاروباری عمل (BP) اور صنعتی سافٹ ویئر کے ڈیزائن کے امتحان کے لیے لاگو کیا جا سکتا ہے۔
یہ دلیل دی جاتی ہے کہ ڈیٹا گوداموں، رپورٹنگ ٹولز اور انضمام کے معاہدوں کا ڈیزائن (جو معلومات کی ٹیبلولر نمائندگی کا استعمال کرتے ہیں) ERP سسٹم ڈیٹا بیس کے ڈیزائن سے اس قدر مختلف ہے کہ استعمال میں آسانی اور اسے حاصل کرنے کے لیے شعوری طور پر غیر معمول کے استعمال کو سالمیت پر فوقیت حاصل ہو سکتی ہے۔ تحفظ کے اعداد و شمار. میں اس رائے کا اشتراک کرتا ہوں، اور جو ذیل میں بیان کیا گیا ہے وہ مکمل طور پر ERP سسٹمز کے ماسٹر ڈیٹا اور ٹرانزیکشنل ڈیٹا ماڈلز پر لاگو ہوتا ہے۔
عام شکلوں کی وضاحت ایک مثال کا استعمال کرتے ہوئے دی گئی ہے جو زیادہ تر قارئین کے لیے روزمرہ کی سطح پر قابل فہم ہے۔ تاہم، بصری مثال کے طور پر، پیراگراف 4-5 میں، جان بوجھ کر ایک "افسانہ" کام کو جان بوجھ کر استعمال کیا گیا تھا۔ اگر آپ ایسا نہیں کرتے ہیں اور کچھ نصابی کتابوں کی مثال لیتے ہیں، مثال کے طور پر، پوائنٹ 2 سے وہی آرڈر اسٹوریج ماڈل، آپ اپنے آپ کو ایسی صورتحال میں پا سکتے ہیں جہاں قاری کی توجہ عمل کے مجوزہ گلنے سے ماڈل میں منتقل ہو جائے گی، IS میں ڈیٹا کو ذخیرہ کرنے کے طریقہ کار اور ماڈلز کو کس طرح بنایا جانا چاہیے اس کے ذاتی تجربے اور تصور کے لیے۔ دوسرے لفظوں میں، دو مستند آئی ٹی تجزیہ کاروں کو لیں، ایک مسافروں کو نقل و حمل کرنے والے لاجسٹک ماہرین کو، دوسرے کو مائیکرو چپس کی تیاری کے لیے مشینوں کی نقل و حمل کرنے والے لاجسٹک ماہرین کو خدمات فراہم کرنے دیں۔ ریلوے کے سفر کے بارے میں معلومات کو ذخیرہ کرنے کے لیے ایک ڈیٹا ماڈل بنانے کے لیے، خودکار BPs پر پہلے سے بات کیے بغیر، ان سے پوچھیں۔
اس بات کا ایک غیر صفر امکان ہے کہ مجوزہ ماڈلز میں آپ کو نہ صرف نمایاں طور پر مختلف صفات کا مجموعہ ملے گا بلکہ ہستیوں کے مختلف سیٹ بھی ملیں گے، کیونکہ ہر تجزیہ کار اپنے واقف عمل اور کاموں پر انحصار کرے گا۔ اور ایسی صورت حال میں یہ کہنا ناممکن ہے کہ کون سا ماڈل "درست" ہے، کیونکہ تشخیص کا کوئی معیار نہیں ہے۔
2. عام شکلیں
ڈیٹا بیس کی پہلی عام شکل تمام صفات کی جوہری ضرورت ہے۔
خاص طور پر، اگر آبجیکٹ A میں غیر کلیدی صفات a اور b ہیں، جیسے کہ c=f(a,b) اور آبجیکٹ A کو بیان کرنے والے جدول میں آپ c کی قدر ذخیرہ کرتے ہیں، تو ڈیٹا بیس میں پہلی عام شکل کی خلاف ورزی ہوتی ہے۔ . مثال کے طور پر، اگر آرڈر کی تصریح کسی مقدار کی نشاندہی کرتی ہے، جس کی پیمائش کی اکائیاں پروڈکٹ کی قسم پر منحصر ہوتی ہیں: ایک صورت میں یہ ٹکڑے ہوسکتے ہیں، دوسرے لیٹر میں، ٹکڑوں پر مشتمل تیسرے پیکیج میں (اوپر کے ماڈل میں Good_count_WR) ، پھر ڈیٹا بیس میں صفات کی ایٹمییت کی خلاف ورزی کی جاتی ہے۔ اس معاملے میں، یہ بتانے کے لیے کہ آرڈر کی تفصیلات کا ٹیبل کلسٹر کیا ہونا چاہیے، آپ کو IS میں کام کے عمل کی ٹارگٹڈ تفصیل درکار ہے، اور چونکہ عمل مختلف ہو سکتے ہیں، اس لیے بہت سے "درست" ورژن ہو سکتے ہیں۔
ڈیٹا بیس کی دوسری عام شکل 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. پہلے سے بنائے گئے IS میں ڈیٹا ماڈل کے غیر معمولی ہونے کے کسی بھی نتائج کو کوڈ کے ابتدائی مطالعہ اور جانچ کے ذریعے کم کیا جا سکتا ہے۔
4. ڈی نارملائزیشن ڈیٹا کے ذرائع کی تحقیق اور کاروباری عمل کو ڈیزائن کرنے کے مرحلے سے لے کر ڈیولپمنٹ کے مرحلے تک، نفاذ کی مدت سے نظام کی ترقی کی مدت تک لیبر کے اخراجات کو منتقل کرنے کا ایک طریقہ ہے۔
5. یہ مشورہ دیا جاتا ہے کہ ڈیٹا بیس کی تیسری عام شکل کے لیے کوشش کی جائے اگر:
- خودکار کاروباری عمل میں تبدیلی کی سمت کا اندازہ لگانا مشکل ہے۔
- عمل درآمد اور/یا ترقیاتی ٹیم کے اندر محنت کی کمزور تقسیم ہے۔
- انٹیگریشن سرکٹ میں شامل نظام اپنے اپنے منصوبوں کے مطابق تیار ہوتے ہیں۔
- ڈیٹا کی عدم مطابقت کے نتیجے میں کمپنی صارفین یا پیسے کھو سکتی ہے۔
6. ڈیٹا ماڈل کا ڈیزائن ایک تجزیہ کار کے ذریعہ صرف ہدف کاروباری عمل کے ماڈلز اور IS میں عمل کے سلسلے میں کیا جانا چاہئے۔ اگر کوئی ڈویلپر ڈیٹا ماڈل ڈیزائن کر رہا ہے، تو اسے اپنے آپ کو موضوع کے علاقے میں اس حد تک غرق کرنا پڑے گا کہ، خاص طور پر، وہ انتساب کی قدروں کے درمیان فرق کو سمجھے - جوہری صفات کو الگ کرنے کے لیے ایک ضروری شرط۔ اس طرح، غیر معمولی افعال پر لے جا رہا ہے.
4 مثال کے لیے مسئلہ
ہم کہتے ہیں کہ آپ کے پاس بندرگاہ میں ایک چھوٹا روبوٹک ہوٹل ہے۔ آپ کا بازار کا حصہ: ملاح اور قزاق جو بندرگاہ میں آتے ہیں اور انہیں وقفے کی ضرورت ہوتی ہے۔ آپ ملاحوں کو تھیم کے ساتھ چائے بیچتے ہیں، اور قزاقوں کو داڑھیوں کو کنگھی کرنے کے لیے رم اور ہڈیوں کے کنگھے بیچتے ہیں۔ ہوٹل میں سروس خود ایک روبوٹ ہوسٹس اور ایک روبوٹ بارٹینڈر فراہم کرتی ہے۔ آپ کے اعلیٰ معیار اور کم قیمتوں کی بدولت، آپ نے اپنے حریفوں کو بھگا دیا ہے، تاکہ جہاز سے آنے والا ہر شخص آپ کے ہوٹل میں آتا ہے، جو بندرگاہ میں واحد ہے۔
ٹیورن انفارمیشن سسٹم کمپلیکس درج ذیل سافٹ ویئر پر مشتمل ہے:
- ایک کلائنٹ کے بارے میں ابتدائی انتباہی نظام جو خصوصیت کی بنیاد پر اس کے زمرے کو پہچانتا ہے۔
- روبوٹ میزبانوں اور روبوٹ بارٹینڈرز کے لیے کنٹرول سسٹم
- گودام اور ترسیل کے انتظام کا نظام فروخت کے مقام تک
- سپلائر ریلیشن شپ مینجمنٹ سسٹم (SURP)
عمل:
ابتدائی وارننگ سسٹم جہاز سے نکلنے والے لوگوں کو پہچانتا ہے۔ اگر کوئی شخص کلین شیون ہے تو وہ اسے ملاح کے طور پر شناخت کرتی ہے، اگر کوئی شخص داڑھی والا پایا جائے تو اس کی شناخت سمندری ڈاکو کے طور پر کی جاتی ہے۔
ہوٹل میں داخل ہوتے ہوئے، مہمان روبوٹ ہوسٹس سے اس کے زمرے کے مطابق ایک سلام سنتا ہے، مثال کے طور پر: "ہو-ہو-ہو، پیارے سمندری ڈاکو، ٹیبل نمبر پر جاؤ..."
مہمان مخصوص میز پر جاتا ہے، جہاں روبوٹ بارٹینڈر نے زمرے کے مطابق اس کے لیے سامان تیار کر رکھا ہوتا ہے۔ روبوٹ بارٹینڈر گودام کے نظام کو معلومات پہنچاتا ہے کہ ڈیلیوری کے اگلے حصے میں اضافہ کیا جانا چاہیے؛ گودام IS، اسٹوریج میں باقی ماندہ بیلنس کی بنیاد پر، مینجمنٹ سسٹم میں خریداری کی درخواست تیار کرتا ہے۔
اگرچہ ابتدائی انتباہی نظام آپ کے اندرونی IT کے ذریعے تیار کیا گیا ہو گا، ہو سکتا ہے بار روبوٹ مینجمنٹ پروگرام کسی بیرونی ٹھیکیدار نے خاص طور پر آپ کے کاروبار کے لیے بنایا ہو۔ اور گوداموں کے انتظام اور سپلائرز کے ساتھ تعلقات کے نظام مارکیٹ سے اپنی مرضی کے مطابق پیکڈ حل ہیں۔
5. ڈی نارملائزیشن کی مثالیں اور سافٹ ویئر کی ترقی پر اس کے اثرات
کاروباری عمل کو ڈیزائن کرتے وقت، انٹرویو کیے گئے مضامین کے ماہرین نے متفقہ طور پر بتایا کہ پوری دنیا میں قزاق رم پیتے ہیں اور ہڈیوں کے کنگھیوں سے اپنی داڑھی کو کنگھی کرتے ہیں، اور ملاح تھائم کے ساتھ چائے پیتے ہیں اور ہمیشہ کلین شیون رہتے ہیں۔
کلائنٹ کی اقسام کی ایک ڈائرکٹری دو قدروں کے ساتھ ظاہر ہوتی ہے: 1 - قزاق، 2 - ملاح، کمپنی کے پورے معلوماتی سرکٹ کے لیے عام۔
کلائنٹ نوٹیفکیشن سسٹم امیج پروسیسنگ کے نتیجے کو تسلیم شدہ کلائنٹ کے شناخت کنندہ (ID) کے طور پر اور اس کی قسم: نااخت یا سمندری ڈاکو کے طور پر فوری طور پر اسٹور کرتا ہے۔
شناخت شدہ آبجیکٹ ID
کلائنٹ کیٹیگری
100500
سمندری ڈاکو
100501
سمندری ڈاکو
100502
نااخت
آئیے ایک بار پھر اس بات کو نوٹ کریں۔
1. ہمارے ملاح اصل میں مونڈنے والے لوگ ہیں۔
2. ہمارے قزاق دراصل داڑھی والے لوگ ہیں۔
اس معاملے میں کن مسائل کو ختم کرنے کی ضرورت ہے تاکہ ہماری ساخت تیسری عام شکل کے لیے کوشش کرے:
- attribute atomicity violation - کلائنٹ کیٹیگری
- تجزیہ شدہ حقیقت اور نتیجہ کو ایک ٹیبل میں ملانا
- مختلف اداروں کی صفات کے درمیان فکسڈ فنکشنل رشتہ۔
عام شکل میں، ہمیں دو میزیں ملیں گی:
- شناخت کا نتیجہ قائم کردہ خصوصیات کے ایک سیٹ کی شکل میں،
شناخت شدہ آبجیکٹ ID
چہرے کے بال
100500
جی ہاں
100501
جی ہاں
100502
کوئی
- قائم کردہ خصوصیات کی تشریح کے لیے IS میں سرایت شدہ منطق کے اطلاق کے طور پر کلائنٹ کی قسم کا تعین کرنے کا نتیجہ
شناخت شدہ آبجیکٹ ID
شناختی ID
کلائنٹ کیٹیگری
100500
100001
سمندری ڈاکو
100501
100002
سمندری ڈاکو
100502
100003
نااخت
ڈیٹا سٹوریج کی ایک نارملائزڈ تنظیم آئی پی کمپلیکس کی ترقی میں کیسے سہولت فراہم کر سکتی ہے؟ ہم کہتے ہیں کہ آپ کو اچانک نئے کلائنٹ ملتے ہیں۔ یہ جاپانی بحری قزاق ہیں جن کی داڑھی نہیں ہے، لیکن وہ اپنے کندھے پر طوطے کے ساتھ چلتے ہیں، اور ماحولیاتی قزاقوں کو، آپ انہیں گریٹا کے بائیں سینے پر نیلے پروفائل سے آسانی سے پہچان سکتے ہیں۔
ماحولیاتی قزاق، قدرتی طور پر، ہڈیوں کی کنگھی کا استعمال نہیں کر سکتے اور انہیں ری سائیکل شدہ سمندری پلاسٹک سے تیار کردہ ینالاگ کی ضرورت ہوتی ہے۔
آپ کو پروگرام کے الگورتھم کو نئے ان پٹ کے مطابق دوبارہ کام کرنے کی ضرورت ہے۔ اگر نارملائزیشن کے اصولوں پر عمل کیا جاتا، تو آپ کو صرف کچھ سسٹمز میں کچھ پروسیس برانچز کے لیے ان پٹس کو اضافی کرنا پڑے گا اور صرف ان کیسز کے لیے نئی برانچیں بنانا ہوں گی اور ان IS میں جہاں چہرے کے بالوں کی اہمیت ہے۔ لیکن، چونکہ قواعد کی پیروی نہیں کی گئی تھی، اس لیے آپ کو پورے کوڈ کا تجزیہ کرنا پڑے گا، پورے سرکٹ میں، جہاں کلائنٹ ٹائپ ڈائرکٹری کی قدریں استعمال کی جاتی ہیں اور واضح طور پر یہ ثابت کریں کہ ایک صورت میں الگورتھم کو پیشہ ور کو مدنظر رکھنا چاہیے۔ کلائنٹ کی سرگرمی، اور دیگر جسمانی خصوصیات میں.
ایک شکل میں کہ تلاش کرتا ہے معمول پر لانے کے لیے، ہمیں آپریشنل ڈیٹا اور دو ڈائریکٹریز کے ساتھ دو میزیں ملیں گی۔
- شناخت کا نتیجہ قائم کردہ خصوصیات کے ایک سیٹ کی شکل میں،
شناخت شدہ آبجیکٹ ID
گریٹا بائیں سینے پر
کندھے پر پرندہ
چہرے کے بال
100510
1
1
1
100511
0
0
1
100512
1
0
- کلائنٹ کی قسم کا تعین کرنے کا نتیجہ (اسے اپنی مرضی کے مطابق نظر آنے دیں جس میں ڈائریکٹریز کی وضاحتیں دکھائی جاتی ہیں)
کیا پتہ چلنے والے غیر معمولی ہونے کا مطلب یہ ہے کہ نئی شرائط کو پورا کرنے کے لیے سسٹمز میں ترمیم نہیں کی جا سکتی؟ ہرگز نہیں۔ اگر ہم تصور کریں کہ تمام انفارمیشن سسٹمز ایک ٹیم نے صفر عملے کے ٹرن اوور کے ساتھ بنائے ہیں، پیشرفت اچھی طرح سے دستاویزی ہے اور معلومات کو بغیر کسی نقصان کے ٹیم کے اندر منتقل کیا جاتا ہے، تو مطلوبہ تبدیلیاں بہت کم کوشش کے ساتھ کی جا سکتی ہیں۔ لیکن اگر ہم مسئلے کی اصل حالتوں پر واپس آتے ہیں تو، 1,5 کی بورڈز صرف مشترکہ مباحثوں کے پروٹوکول پرنٹ کرنے کے لیے اور ایک اور 0,5 کو پروکیورمنٹ کے طریقہ کار پر کارروائی کے لیے مٹا دیا جائے گا۔
مندرجہ بالا مثال میں، تینوں عام شکلوں کی خلاف ورزی کی گئی ہے، آئیے الگ الگ ان کی خلاف ورزی کرنے کی کوشش کرتے ہیں.
پہلی عام شکل کی خلاف ورزی:
مان لیں کہ سامان آپ کے گودام میں سپلائی کرنے والوں کے گوداموں سے پک اپ کے ذریعے ایک 1.5 ٹن گزیل کا استعمال کرتے ہوئے پہنچایا جاتا ہے جو آپ کے ہوٹل سے تعلق رکھتا ہے۔ آپ کے آرڈرز کا سائز سپلائرز کے ٹرن اوور کی نسبت اتنا چھوٹا ہے کہ وہ ہمیشہ پیداوار کا انتظار کیے بغیر یکے بعد دیگرے مکمل ہو جاتے ہیں۔ کیا آپ کو اس طرح کے کاروباری عمل کے ساتھ علیحدہ ٹیبلز کی ضرورت ہے: گاڑیاں، گاڑیوں کی اقسام، کیا آپ کے آرڈر میں پلان اور حقیقت کو روانہ کرنے والے سپلائیرز کو الگ کرنا ضروری ہے؟
ذرا تصور کریں کہ اگر آپ پروگرام تیار کرنے کے لیے نیچے دیئے گئے ماڈل کو استعمال کرتے ہیں تو آپ کے پروگرامرز کو کتنے "اضافی" کنکشن لکھنے ہوں گے۔
ہم کہتے ہیں کہ ہم نے فیصلہ کیا ہے کہ مجوزہ ڈھانچہ غیر ضروری طور پر پیچیدہ ہے؛ ہمارے معاملے میں، آرڈر ریکارڈ میں پلان اور حقیقت کو الگ کرنا بے کار معلومات ہے، اور تیار کردہ آرڈر کی تفصیلات کو موصول ہونے والے سامان کی قبولیت کے نتائج کی بنیاد پر دوبارہ لکھا جاتا ہے، نایاب غلطیاں۔ ناقص معیار کے سامان کی درجہ بندی اور آمد آئی ایس کے باہر طے کی جاتی ہے۔
اور پھر ایک دن آپ دیکھیں گے کہ کس طرح پورا ہوٹل ہال مشتعل اور ناکارہ قزاقوں سے بھرا ہوا ہے۔ کیا ہوا؟
یہ پتہ چلتا ہے کہ جیسے جیسے آپ کا کاروبار بڑھتا گیا، اسی طرح آپ کی کھپت بھی بڑھی۔ ایک زمانے میں، ایک انتظامی فیصلہ کیا گیا تھا کہ اگر ایک غزیل حجم اور/یا وزن میں اوور لوڈ ہو، جو کہ انتہائی نایاب تھا، تو سپلائر مشروبات کے حق میں بوجھ کو ترجیح دے گا۔
غیر ڈیلیوری سامان اگلے آرڈر میں ختم ہوا اور ایک نئی فلائٹ پر چھوڑ دیا گیا؛ ہوٹل کے گودام میں کم از کم بیلنس کی موجودگی نے گمشدہ کیسز کو نوٹس نہ کرنا ممکن بنایا۔
آخری مدمقابل بندرگاہ پر بند ہوا، اور گزیل اوورلوڈ کا پنکچر کیس، کم از کم بیلنس کی کفایت اور گاڑی کے متواتر انڈر لوڈنگ کے مفروضے کی بنیاد پر ترجیحات کو نظر انداز کر کے، معمول بن گیا۔ بنایا ہوا نظام مثالی طور پر اس میں شامل الگورتھم کے مطابق کام کرے گا اور منصوبہ بند احکامات کو پورا کرنے میں منظم ناکامی کا سراغ لگانے کے کسی بھی موقع سے محروم رہے گا۔ صرف خراب ساکھ اور غیر مطمئن صارفین ہی اس مسئلے کا پتہ لگا سکیں گے۔
ایک دھیان رکھنے والے قاری نے محسوس کیا ہو گا کہ سیکشن 2 اور سیکشن 5 میں آرڈر کی تفصیلات (T_ORDER_SPEC) میں آرڈر کی گئی مقدار پہلی عام شکل کی ضرورت کو پورا کر سکتی ہے یا نہیں بھی۔ یہ سب اس بات پر منحصر ہے کہ آیا، اشیا کی منتخب کردہ درجہ بندی کو دیکھتے ہوئے، بنیادی طور پر پیمائش کی مختلف اکائیاں ایک ہی فیلڈ میں آ سکتی ہیں۔
دوسری عام شکل کی خلاف ورزی:
جیسے جیسے آپ کی ضروریات بڑھتی ہیں، آپ مختلف سائز کی کچھ اور گاڑیاں خریدتے ہیں۔ مندرجہ بالا سیاق و سباق میں، گاڑی کی ڈائرکٹری کی تخلیق کو بے کار سمجھا جاتا تھا؛ نتیجے کے طور پر، ڈیلیوری اور گودام کی ضروریات کو پورا کرنے والے تمام ڈیٹا پروسیسنگ الگورتھم سپلائی کرنے والے سے گودام تک کارگو کی نقل و حرکت کو خصوصی طور پر 1,5 ٹن کی پرواز کے طور پر سمجھتے ہیں۔ غزال لہٰذا، نئی گاڑیوں کی خریداری کے ساتھ ساتھ، آپ اب بھی گاڑیوں کی ایک ڈائرکٹری بناتے ہیں، لیکن اسے حتمی شکل دیتے وقت، آپ کو ان تمام کوڈ کا تجزیہ کرنا ہوگا جو کارگو کی نقل و حرکت کا حوالہ دیتے ہیں تاکہ یہ معلوم کیا جا سکے کہ آیا ہر مخصوص جگہ کے حوالہ جات کی خصوصیات پر منحصر ہیں۔ جس گاڑی سے کاروبار شروع ہوا تھا۔
تیسری عام شکل کی خلاف ورزی:
کسی وقت آپ ایک لائلٹی پروگرام بنانا شروع کرتے ہیں، ایک باقاعدہ کسٹمر کا ریکارڈ ظاہر ہوتا ہے۔ کیوں، مثال کے طور پر، مواد کے نظارے بنانے میں وقت گزارنا جو انفرادی کلائنٹ کو فروخت پر جمع شدہ ڈیٹا کو رپورٹنگ میں استعمال کرنے اور تجزیاتی نظاموں میں منتقل کرنے کے لیے ذخیرہ کرتا ہے، اگر لائلٹی پروگرام کے آغاز میں ہر وہ چیز جو گاہک کی دلچسپی ہو کلائنٹ کے ریکارڈ پر رکھی جائے۔ ? اور، واقعی، پہلی نظر میں، کوئی فائدہ نہیں ہے. لیکن جب بھی آپ کا کاروبار آپس میں جڑتا ہے، مثال کے طور پر، نئے سیلز چینلز، آپ کے تجزیہ کاروں میں سے کوئی ایسا ہونا چاہیے جو یاد رکھے کہ اس طرح کی جمع کرنے کی خصوصیت موجود ہے۔
ہر نئے عمل کو ڈیزائن کرتے وقت، مثال کے طور پر، انٹرنیٹ پر فروخت، ایک مشترکہ لائلٹی سسٹم سے منسلک تقسیم کاروں کے ذریعے فروخت، کسی کو یہ بات ذہن میں رکھنی چاہیے کہ تمام نئے عمل کو کوڈ کی سطح پر ڈیٹا کی سالمیت کو یقینی بنانا چاہیے۔ ایک ہزار میزوں والے صنعتی ڈیٹا بیس کے لیے، یہ ایک ناممکن کام لگتا ہے۔
یقیناً ایک تجربہ کار ڈویلپر جانتا ہے کہ مذکورہ بالا تمام مسائل کو کیسے ختم کرنا ہے، لیکن میری رائے میں، ایک تجربہ کار تجزیہ کار کا کام انہیں سامنے لانا نہیں ہے۔
میں اشاعت کی تیاری کے دوران ان کی قیمتی آراء کے لیے سرکردہ ڈویلپر Evgeniy Yarukhin کا شکریہ ادا کرنا چاہوں گا۔
ادب
کونولی تھامس، بیگ کیرولین۔ ڈیٹا بیس۔ ڈیزائن، نفاذ اور معاونت۔ تھیوری اور پریکٹس
ماخذ: www.habr.com