غیر عادی سازی پایگاه داده های ERP و تأثیر آن بر توسعه نرم افزار: افتتاح یک میخانه در تورتوگا

سلام! نام من آندری سمنوف است، من یک تحلیلگر ارشد در Sportmaster هستم. در این پست می خواهم موضوع غیرعادی سازی پایگاه داده های سیستم ERP را مطرح کنم. ما به شرایط عمومی و همچنین یک مثال خاص نگاه خواهیم کرد - بیایید بگوییم که یک میخانه انحصاری فوق العاده برای دزدان دریایی و ملوانان خواهد بود. که در آن باید به دزدان دریایی و ملوانان خدمات متفاوتی داده شود، زیرا ایده های زیبایی و الگوهای مصرفی این آقایان خوب به طور قابل توجهی متفاوت است.

چگونه همه را خوشحال کنیم؟ چگونه می توانید از طراحی و نگهداری چنین سیستمی دیوانه نشوید؟ اگر نه تنها دزدان دریایی و ملوانان معمولی شروع به آمدن به میخانه کنند چه باید کرد؟

همه چیز زیر برش است. اما به ترتیب برویم.

1. محدودیت ها و مفروضات

تمام موارد فوق فقط برای پایگاه های داده رابطه ای اعمال می شود. عواقب غیرعادی سازی در قالب اصلاح، حذف و ناهنجاری های درج که به خوبی پوشش داده شده است، از جمله در اینترنت، در نظر گرفته نمی شود. خارج از محدوده این نشریه مواردی وجود دارد که غیرعادی سازی یک مکان رایج است، با نمونه های کلاسیک: سری و شماره گذرنامه، تاریخ و زمان و غیره.

در این پست از تعاریف بصری و کاربردی از فرم های عادی، بدون اشاره به اصطلاحات ریاضی استفاده شده است. به شکلی که می توان آنها را برای بررسی فرآیندهای کسب و کار واقعی (BP) و طراحی نرم افزارهای صنعتی به کار برد.

استدلال می‌شود که طراحی انبارهای داده، ابزارهای گزارش‌دهی و قراردادهای یکپارچه‌سازی (که از نمایش‌های جدولی اطلاعات استفاده می‌کنند) با طراحی پایگاه‌های اطلاعاتی سیستم ERP از این جهت که سهولت مصرف و استفاده از غیرعادی‌سازی آگاهانه برای دستیابی به آن ممکن است بر یکپارچگی اولویت داشته باشد، متفاوت است. داده های حفاظتی من با این نظر موافقم و آنچه در زیر توضیح داده شده است صرفاً در مورد مدل های داده اصلی و داده های تراکنشی سیستم های ERP صدق می کند.

توضیح اشکال عادی با استفاده از مثالی ارائه شده است که در سطح روزمره برای اکثر خوانندگان قابل درک است. با این حال، به عنوان یک تصویر بصری، در پاراگراف های 4-5، یک کار عمدا "تخیلی" به عمد استفاده شد. اگر این کار را انجام ندهید و نمونه کتاب درسی را مثال بزنید، برای مثال، همان مدل ذخیره سفارش از نقطه 2، ممکن است در موقعیتی قرار بگیرید که تمرکز خواننده از تجزیه پیشنهادی فرآیند به یک مدل تغییر کند. به تجربه شخصی و درک نحوه ساخت فرآیندها و مدل‌های ذخیره داده در IS. به عبارت دیگر، دو تحلیلگر IT واجد شرایط را انتخاب کنید، اجازه دهید یکی به تدارکاتی که مسافران را حمل می کند خدمات ارائه دهد، دیگری به تدارکاتی که ماشین های حمل و نقل را برای تولید ریزتراشه ها انجام می دهد. از آنها بخواهید، بدون اینکه از قبل درباره BP های خودکار صحبت کنند، یک مدل داده برای ذخیره اطلاعات در مورد یک سفر راه آهن ایجاد کنند.

یک احتمال غیر صفر وجود دارد که در مدل‌های پیشنهادی نه تنها مجموعه‌ای متفاوت از ویژگی‌ها، بلکه مجموعه‌های متفاوتی از موجودیت‌ها را نیز پیدا کنید، زیرا هر تحلیل‌گر به فرآیندها و وظایف آشنای خود تکیه می‌کند. و در چنین شرایطی نمی توان گفت که کدام مدل "درست" است، زیرا هیچ معیار ارزیابی وجود ندارد.

2. اشکال عادی

اولین فرم عادی پایگاه داده به اتمی بودن همه صفات نیاز دارد.
به ویژه، اگر شی A دارای ویژگی های غیرکلیدی a و b باشد، به طوری که c=f(a,b) و در جدول توصیف شی A مقدار ویژگی c را ذخیره کنید، اولین شکل عادی در پایگاه داده نقض می شود. . به عنوان مثال، اگر مشخصات سفارش مقداری را نشان می دهد که واحدهای اندازه گیری آن به نوع محصول بستگی دارد: در یک مورد می تواند قطعه باشد، در دیگری لیتر، در بسته بندی سوم شامل قطعات (در مدل بالا Good_count_WR) ، سپس اتمی بودن ویژگی ها در پایگاه داده نقض می شود. در این مورد، برای اینکه بگوییم خوشه جدول مشخصات سفارش چگونه باید باشد، به شرح هدفمندی از فرآیند کار در IS نیاز دارید، و از آنجایی که فرآیندها می توانند متفاوت باشند، می تواند نسخه های "درست" زیادی وجود داشته باشد.

دومین شکل عادی پایگاه داده مستلزم رعایت فرم اول و جدول خاص خود برای هر نهاد مربوط به فرآیند کار در IS است. اگر در یک جدول وابستگی های c=f1(a) و d=f2(b) وجود داشته باشد و هیچ وابستگی c=f3(b) وجود نداشته باشد، شکل نرمال دوم در جدول نقض می شود. در مثال بالا، هیچ وابستگی بین سفارش و آدرس در جدول Order وجود ندارد. نام خیابان یا شهر را تغییر دهید و هیچ تاثیری بر ویژگی های ضروری سفارش نخواهید داشت.

پایگاه داده فرم عادی سوم مستلزم انطباق با شکل عادی دوم و عدم وجود وابستگی های عملکردی بین ویژگی های موجودیت های مختلف است. این قانون را می توان به صورت زیر فرموله کرد: "هر چیزی که قابل محاسبه است باید محاسبه شود." به عبارت دیگر، اگر دو شی A و B وجود داشته باشد. در جدول ذخیره ویژگی های شی A، ویژگی C نشان داده می شود و شی B دارای ویژگی b است، به طوری که c=f4(b) وجود داشته باشد، شکل عادی سوم نقض می شود. در مثال زیر، ویژگی Quantity of Pieces (Total_count_WR) در رکورد سفارش به وضوح ادعا می کند که فرم سوم عادی را نقض می کند.

3. رویکرد من به استفاده از نرمال سازی

1. فقط یک فرآیند تجاری خودکار هدف می تواند معیارهایی را برای شناسایی موجودیت ها و ویژگی ها در هنگام ایجاد یک مدل ذخیره سازی داده در اختیار تحلیلگر قرار دهد. ایجاد یک مدل فرآیند پیش نیاز ایجاد یک مدل داده معمولی است.

2. دستیابی به شکل عادی سوم به معنای دقیق ممکن است در عمل واقعی ایجاد سیستم های ERP عملی نباشد، اگر برخی یا همه شرایط زیر برآورده شوند:

• فرآیندهای خودکار به ندرت در معرض تغییر هستند،
• ضرب الاجل های تحقیق و توسعه محدود است،
• الزامات یکپارچگی داده ها نسبتاً کم است (خطاهای احتمالی در نرم افزارهای صنعتی منجر به از دست دادن پول یا مشتریان توسط مشتری نرم افزار نمی شود)
• غیره

تحت شرایط توصیف شده، هزینه های شناسایی و توصیف چرخه عمر برخی از اشیاء و ویژگی های آنها ممکن است از نقطه نظر کارایی اقتصادی قابل توجیه نباشد.

3. هر گونه پیامدهای غیرعادی سازی مدل داده در یک IS از قبل ایجاد شده را می توان با مطالعه مقدماتی کامل کد و آزمایش کاهش داد.

4. غیر عادی سازی راهی برای انتقال هزینه های نیروی کار از مرحله تحقیق منابع داده و طراحی فرآیند تجاری به مرحله توسعه، از دوره اجرا تا دوره توسعه سیستم است.

5. توصیه می شود برای سومین شکل عادی پایگاه داده تلاش کنید اگر:

• پیش بینی جهت تغییر در فرآیندهای کسب و کار خودکار دشوار است
• تقسیم کار ضعیفی در تیم اجرا و/یا توسعه وجود دارد
• سیستم های موجود در مدار یکپارچه سازی طبق برنامه های خود توسعه می یابند
• ناهماهنگی داده ها می تواند منجر به از دست دادن مشتریان یا پول شرکت شود

6. طراحی یک مدل داده باید توسط یک تحلیلگر فقط در ارتباط با مدل های فرآیند تجاری هدف و فرآیند در IS انجام شود. اگر یک توسعه دهنده در حال طراحی یک مدل داده باشد، باید خود را به حدی در حوزه موضوع غوطه ور کند که، به ویژه، تفاوت بین مقادیر ویژگی ها را درک کند - شرط لازم برای جداسازی ویژگی های اتمی. بنابراین، عملکردهای غیرمعمولی به خود می گیرد.

4 مشکل برای مثال

فرض کنید یک میخانه رباتیک کوچک در بندر دارید. بخش بازار شما: ملوانان و دزدان دریایی که به بندر می آیند و نیاز به استراحت دارند. به ملوانان چای با آویشن می فروشید و به دزدان دریایی رم و شانه استخوانی برای شانه زدن ریش می فروشید. خدمات در خود میخانه توسط یک مهماندار ربات و یک بارمن ربات ارائه می شود. به لطف کیفیت بالا و قیمت های پایین خود، شما رقبای خود را بیرون کرده اید، به طوری که هرکس از کشتی خارج می شود به میخانه شما که تنها میخانه در بندر است می آید.

مجموعه سیستم های اطلاعات میخانه از نرم افزارهای زیر تشکیل شده است:

• یک سیستم هشدار اولیه در مورد مشتری که دسته بندی خود را بر اساس ویژگی های مشخصه تشخیص می دهد
• سیستم کنترل برای مهمانداران ربات و بارمن ربات
• سیستم مدیریت انبار و تحویل به محل فروش
• سیستم مدیریت ارتباط با تامین کننده (SURP)

فرآیند:

سیستم هشدار اولیه افرادی را که کشتی را ترک می کنند شناسایی می کند. اگر فردی تراشیده شده باشد، او را ملوان معرفی می کند و اگر فردی ریش داشته باشد، دزد دریایی شناخته می شود.

با ورود به میخانه، مهمان با توجه به دسته بندی خود از مهماندار ربات احوالپرسی می شنود، به عنوان مثال: "هو هو هو، دزد دریایی عزیز، برو سر میز شماره..."

مهمان به سمت میز مشخص شده می رود، جایی که ربات بارمن از قبل کالاهایی را مطابق با دسته برای او آماده کرده است. بارمن ربات اطلاعاتی را به سیستم انبار ارسال می کند که بخش بعدی تحویل باید افزایش یابد؛ انبار IS، بر اساس موجودی باقیمانده در انبار، درخواست خرید را در سیستم مدیریت ایجاد می کند.

در حالی که سیستم هشدار اولیه ممکن است توسط IT داخلی شما ایجاد شده باشد، برنامه مدیریت ربات نوار ممکن است توسط یک پیمانکار خارجی به طور خاص برای تجارت شما ایجاد شده باشد. و سیستم های مدیریت انبارها و روابط با تامین کنندگان راه حل های بسته بندی شده سفارشی از بازار هستند.

5. نمونه هایی از غیر عادی سازی و تاثیر آن بر توسعه نرم افزار

هنگام طراحی یک فرآیند تجاری، کارشناسان موضوع مصاحبه به اتفاق آرا اظهار داشتند که دزدان دریایی در سراسر جهان رام می نوشند و ریش خود را با شانه های استخوانی شانه می کنند و ملوانان چای با آویشن می نوشند و همیشه تراشیده شده اند.

فهرستی از انواع مشتری با دو مقدار ظاهر می شود: 1 - دزدان دریایی، 2 - ملوان، مشترک برای کل مدار اطلاعات شرکت.

سیستم اطلاع رسانی مشتری بلافاصله نتیجه پردازش تصویر را به عنوان شناسه (ID) مشتری شناسایی شده و نوع آن: ملوان یا دزد دریایی ذخیره می کند.

شناسه شی شناسایی شده
دسته مشتری

100500
دزد دریایی

100501
دزد دریایی

100502
ملوان

اجازه دهید یک بار دیگر به این نکته توجه کنیم

1. ملوانان ما در واقع افراد تراشیده هستند
2. دزدان دریایی ما در واقع افراد ریشو هستند

در این مورد چه مشکلاتی باید حذف شوند تا ساختار ما برای سومین شکل عادی تلاش کند:

• نقض ویژگی اتمی - دسته مشتری
• ترکیب واقعیت تحلیل شده و نتیجه گیری در یک جدول
• رابطه عملکردی ثابت بین ویژگی های موجودیت های مختلف.

در فرم نرمال شده، دو جدول دریافت می کنیم:

• نتیجه شناخت در قالب مجموعه ای از ویژگی های تثبیت شده،

شناسه شی شناسایی شده
موی صورت

100500
بله

100501
بله

100502
بدون

• نتیجه تعیین نوع مشتری به عنوان کاربرد منطق تعبیه شده در IS برای تفسیر ویژگی های ایجاد شده

شناسه شی شناسایی شده
شناسه شناسایی
دسته مشتری

100500
100001
دزد دریایی

100501
100002
دزد دریایی

100502
100003
ملوان

چگونه یک سازمان ذخیره سازی عادی داده می تواند توسعه یک مجتمع IP را تسهیل کند؟ فرض کنید به طور ناگهانی مشتریان جدیدی پیدا می کنید. بگذارید دزدان دریایی ژاپنی باشند که ممکن است ریش نداشته باشند، اما با طوطی روی شانه راه می روند، و دزدان دریایی دوستدار محیط زیست، به راحتی می توانید آنها را با نمایه آبی گرتا در سمت چپ سینه تشخیص دهید.

دزدان دریایی محیط زیست، به طور طبیعی، نمی توانند از شانه های استخوانی استفاده کنند و نیاز به یک آنالوگ ساخته شده از پلاستیک بازیافتی دریا دارند.

باید الگوریتم های برنامه را مطابق با ورودی های جدید دوباره کار کنید. اگر از قوانین نرمال سازی پیروی می شد، در آن صورت فقط باید ورودی های برخی از شاخه های فرآیندی را در برخی سیستم ها تکمیل کنید و شاخه های جدید را فقط برای مواردی و در آن IS هایی که موهای صورت اهمیت دارد ایجاد کنید. اما، از آنجایی که قوانین رعایت نشده است، باید کل کد را در سراسر مدار، جایی که از مقادیر دایرکتوری نوع مشتری استفاده می شود، تجزیه و تحلیل کنید و به وضوح مشخص کنید که در یک مورد الگوریتم باید حرفه ای را در نظر بگیرد. فعالیت مشتری و سایر ویژگی های فیزیکی.

به شکلی که به دنبال برای عادی سازی، دو جدول با داده های عملیاتی و دو دایرکتوری دریافت خواهیم کرد:

• نتیجه شناخت در قالب مجموعه ای از ویژگی های تثبیت شده،

شناسه شی شناسایی شده
گرتا روی سینه چپ
پرنده روی شانه
موی صورت

100510
1
1
1

100511
0
0
1

100512

1
0

• نتیجه تعیین نوع مشتری (اجازه دهید یک نمای سفارشی باشد که در آن توضیحات از دایرکتوری ها نمایش داده می شود)

آیا غیرعادی سازی تشخیص داده شده به این معنی است که سیستم ها را نمی توان تغییر داد تا شرایط جدید را برآورده کنند؟ البته که نه. اگر تصور کنیم که تمام سیستم های اطلاعاتی توسط یک تیم با جابجایی کارکنان صفر ایجاد شده است، تحولات به خوبی مستند شده و اطلاعات بدون ضرر در داخل تیم منتقل می شود، در این صورت تغییرات مورد نیاز را می توان با تلاش ناچیز انجام داد. اما اگر به شرایط اولیه مشکل برگردیم، 1,5 صفحه کلید فقط برای چاپ پروتکل های بحث های مشترک و 0,5 دیگر برای پردازش مراحل خرید پاک می شود.

در مثال بالا، هر سه شکل عادی نقض شده اند، سعی می کنیم آنها را جداگانه نقض کنیم.

نقض اولین فرم نرمال:

فرض کنید کالاها با استفاده از یک غزال 1.5 تنی که متعلق به میخانه شما است، از انبارهای تامین کنندگان به انبار شما تحویل داده می شود. اندازه سفارشات شما نسبت به گردش مالی تامین کنندگان آنقدر کوچک است که همیشه بدون انتظار برای تولید به صورت تک به تک تکمیل می شوند. آیا به جداول جداگانه با چنین فرآیند تجاری نیاز دارید: وسایل نقلیه، انواع وسایل نقلیه، آیا لازم است برنامه و واقعیت را در سفارشات خود به تامین کنندگان خارج شده جدا کنید؟

فقط تصور کنید اگر از مدل زیر برای توسعه یک برنامه استفاده کنید، برنامه نویسان شما باید چند اتصال "اضافی" بنویسند.

فرض کنید ما تصمیم گرفتیم که ساختار پیشنهادی غیر ضروری پیچیده است؛ در مورد ما، جدا کردن طرح و واقعیت در ثبت سفارش، اطلاعات اضافی است، و مشخصات سفارش تولید شده بر اساس نتایج پذیرش کالای رسیده بازنویسی می شود، اشتباه نادر است. - درجه بندی و ورود کالاهای با کیفیت نامناسب در خارج از IS حل و فصل می شود.
و سپس یک روز می بینید که چگونه کل سالن میخانه پر از دزدان دریایی خشمگین و نامرتب است. چی شد؟

معلوم می شود که با رشد کسب و کار شما، مصرف شما نیز افزایش یافته است. روزی روزگاری، تصمیم مدیریتی گرفته شد که اگر غزال از نظر حجم و/یا وزن بیش از حد بارگیری شود، که بسیار نادر است، تامین کننده بار را به نفع نوشیدنی ها در اولویت قرار دهد.

کالاهای تحویل‌نگرفته در سفارش بعدی به پایان رسید و با یک پرواز جدید ترک شد؛ وجود حداقل موجودی در انبار در میخانه باعث شد که موارد گمشده متوجه نشوید.

آخرین رقیب در بندر بسته شد و مورد سوراخ شده اضافه بار غزال، دور زدن اولویت بندی بر اساس فرض کفایت حداقل تعادل و بارگیری زیر بار دوره ای وسیله نقلیه، به یک روش معمول تبدیل شد. سیستم ایجاد شده به طور ایده آل مطابق با الگوریتم های تعبیه شده در آن کار خواهد کرد و از هر فرصتی برای ردیابی شکست سیستماتیک در انجام سفارشات برنامه ریزی شده محروم خواهد شد. فقط یک شهرت آسیب دیده و مشتریان ناراضی می توانند مشکل را تشخیص دهند.

یک خواننده با دقت ممکن است متوجه شده باشد که مقدار سفارش در مشخصات سفارش (T_ORDER_SPEC) در بخش 2 و بخش 5 ممکن است الزامات اولین فرم معمولی را برآورده کند یا نباشد. همه چیز به این بستگی دارد که با توجه به مجموعه انتخابی کالاها، اساساً واحدهای اندازه گیری مختلف می توانند در یک زمینه قرار گیرند یا خیر.

نقض فرم عادی دوم:

با افزایش نیازهای شما، چند وسیله نقلیه دیگر با اندازه های مختلف خریداری می کنید. در زمینه فوق، ایجاد یک فهرست خودرو اضافی در نظر گرفته شد؛ در نتیجه، تمام الگوریتم‌های پردازش داده که نیازهای تحویل و انبار را برآورده می‌کنند، جابجایی محموله از تامین‌کننده به انبار را به‌عنوان پرواز منحصراً 1,5 تنی درک می‌کنند. غزال بنابراین، همراه با خرید وسایل نقلیه جدید، شما هنوز یک فهرست راهنمای خودرو ایجاد می کنید، اما هنگام نهایی کردن آن، باید تمام کدهایی را که به حرکت محموله اشاره می کند تجزیه و تحلیل کنید تا بفهمید که آیا در هر مکان خاص به ویژگی ها اشاره شده است یا خیر. همان وسیله نقلیه ای که تجارت از آن شروع شد.

نقض فرم سوم عادی:

زمانی که شروع به ایجاد یک برنامه وفاداری می کنید، سابقه یک مشتری معمولی ظاهر می شود. به عنوان مثال، چرا زمانی را صرف ایجاد نماهای مادی می کنیم که داده های جمع آوری شده در مورد فروش به یک مشتری را برای استفاده در گزارش گیری و انتقال به سیستم های تحلیلی ذخیره می کند، اگر در شروع یک برنامه وفاداری می توان همه چیزهایی را که مشتری علاقه مند است در سوابق مشتری قرار داد. ? و در واقع، در نگاه اول، هیچ نکته ای وجود ندارد. اما هر بار که کسب‌وکار شما، به عنوان مثال، کانال‌های فروش جدید را به هم متصل می‌کند، باید فردی در میان تحلیلگران شما وجود داشته باشد که به یاد داشته باشد که چنین ویژگی تجمعی وجود دارد.

هنگام طراحی هر فرآیند جدید، به عنوان مثال، فروش در اینترنت، فروش از طریق توزیع کنندگان متصل به یک سیستم وفاداری مشترک، کسی باید در نظر داشته باشد که تمام فرآیندهای جدید باید یکپارچگی داده ها را در سطح کد تضمین کنند. برای یک پایگاه داده صنعتی با هزار جدول، این کار غیرممکن به نظر می رسد.

یک توسعه دهنده باتجربه، البته، می داند که چگونه تمام مشکلات ذکر شده در بالا را متوقف کند، اما، به نظر من، وظیفه یک تحلیلگر با تجربه این نیست که آنها را آشکار کند.

من می خواهم از توسعه دهنده برجسته Evgeniy Yarukhin برای بازخورد ارزشمندش در طول آماده سازی انتشار تشکر کنم.

ادبیات

https://habr.com/en/post/254773/
کانولی توماس، بگ کارولین. پایگاه داده. طراحی، اجرا و پشتیبانی. تئوری و عمل

منبع: www.habr.com