Денормализация на ERP бази данни и нейното въздействие върху разработката на софтуер: отваряне на таверна в Тортуга

Здравейте! Казвам се Андрей Семенов, аз съм старши анализатор в Sportmaster. В тази публикация искам да повдигна въпроса за денормализирането на базите данни на ERP системата. Ще разгледаме общи условия, както и конкретен пример - да кажем, че това би било чудесна монополна таверна за пирати и моряци. В който пиратите и моряците трябва да бъдат обслужвани по различен начин, защото представите за красота и потребителските модели на тези добри господа са значително различни.

Как да направим всички щастливи? Как можете да избегнете полудяване при проектиране и поддръжка на такава система? Какво да направите, ако не само обичайните пирати и моряци започнат да идват в таверната?

Всичко е под разфасовката. Но да вървим по ред.

1. Ограничения и предположения

Всичко по-горе се отнася само за релационни бази данни. Последствията от денормализацията под формата на аномалии на модификация, изтриване и вмъкване, които са добре обхванати, включително в Интернет, не се разглеждат. Извън обхвата на тази публикация има случаи, в които денормализирането е обичайно място, с класически примери: серия и номер на паспорт, дата и час и др.

Публикацията използва интуитивни и практически приложими дефиниции на нормални форми, без препратка към математически термини. Във вида, в който могат да се прилагат при изследване на реални бизнес процеси (БП) и проектиране на индустриален софтуер.

Твърди се, че дизайнът на складове за данни, инструменти за отчитане и споразумения за интегриране (които използват таблично представяне на информация) се различава от дизайна на бази данни на ERP система по това, че лекотата на потребление и използването на съзнателна денормализация за постигането му може да има предимство пред целостта данни за защита. Споделям това мнение и описаното по-долу се отнася единствено за моделите на основни данни и транзакционни данни на ERP системите.

Обяснение на нормалните форми е дадено с помощта на пример, който е разбираем на ежедневно ниво за повечето читатели. Въпреки това, като визуална илюстрация, в параграфи 4-5 умишлено е използвана „измислена“ задача. Ако не направите това и вземете пример от учебник, например същия модел за съхранение на поръчки от точка 2, може да се окажете в ситуация, в която фокусът на читателя ще бъде изместен от предложеното разлагане на процеса в модел, до личен опит и възприятие как трябва да се изграждат процеси и модели за съхранение на данни в ИС. С други думи, вземете двама квалифицирани ИТ анализатори, нека единият да предоставя услуги на логистици, превозващи пътници, а другият на логистици, транспортиращи машини за производство на микрочипове. Помолете ги, без да обсъждате автоматизираните BP предварително, да създадат модел на данни за съхраняване на информация за пътуване с железопътен транспорт.

Има ненулева вероятност в предложените модели да намерите не само забележимо различен набор от атрибути, но и различни набори от обекти, тъй като всеки анализатор ще разчита на процеси и задачи, които са му познати. И в такава ситуация е невъзможно да се каже кой модел е „правилен“, защото няма критерий за оценка.

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), тогава третата нормална форма се нарушава. В примера по-долу атрибутът Quantity of Pieces (Total_count_WR) в записа на поръчката ясно твърди, че нарушава третата нормална форма

3. Моят подход за прилагане на нормализиране

1. Само целеви автоматизиран бизнес процес може да предостави на анализатора критерии за идентифициране на обекти и атрибути при създаване на модел за съхранение на данни. Създаването на модел на процес е предпоставка за създаване на нормален модел на данни.

2. Постигането на трета нормална форма в строгия смисъл може да не е практично в действителната практика на създаване на ERP системи, ако са изпълнени някои или всички от следните условия:

• автоматизираните процеси рядко подлежат на промяна,
• сроковете за изследване и развитие са кратки,
• изискванията за цялост на данните са сравнително ниски (потенциалните грешки в индустриалния софтуер не водят до загуба на пари или клиенти от клиента на софтуера)
• и т.н.

При описаните условия разходите за идентифициране и описание на жизнения цикъл на някои обекти и техните атрибути може да не са оправдани от гледна точка на икономическа ефективност.

3. Всякакви последствия от денормализиране на модела на данни във вече създадена ИС могат да бъдат смекчени чрез задълбочено предварително проучване на кода и тестване.

4. Денормализацията е начин за прехвърляне на разходите за труд от етапа на проучване на източници на данни и проектиране на бизнес процес към етапа на разработка, от периода на внедряване към периода на развитие на системата.

5. Препоръчително е да се стремите към третата нормална форма на база данни, ако:

• Посоката на промяна в автоматизираните бизнес процеси е трудна за прогнозиране
• Има слабо разделение на труда в екипа за внедряване и/или разработка
• Системите, включени в интеграционната верига, се развиват според собствените си планове
• Несъответствието в данните може да доведе до загуба на клиенти или пари на компанията

6. Проектирането на модел на данни трябва да се извършва от анализатор само във връзка с моделите на целевия бизнес процес и процеса в ИС. Ако разработчикът проектира модел на данни, той ще трябва да се потопи в предметната област до такава степен, че по-специално да разбере разликата между стойностите на атрибутите - необходимо условие за изолиране на атомарни атрибути. По този начин, поемайки необичайни функции.

4 Задача за илюстрация

Да приемем, че имате малка роботизирана таверна на пристанището. Вашият пазарен сегмент: моряци и пирати, които идват в пристанището и имат нужда от почивка. На моряците продаваш чай с мащерка, а на пиратите - ром и костени гребени за сресване на бради. Обслужването в самата механа се осъществява от робот хостеса и робот барман. Благодарение на вашето високо качество и ниски цени, вие изгонихте конкурентите си, така че всеки, който слиза от кораба, идва във вашата таверна, която е единствената в пристанището.

Комплексът информационни системи на механата се състои от следния софтуер:

• Система за ранно предупреждение за клиент, която разпознава неговата категория по характерни признаци
• Система за управление на роботи хостеси и роботи бармани
• Система за управление на склад и доставка до точка на продажба
• Система за управление на взаимоотношенията с доставчици (SURP)

процес:

Системата за ранно предупреждение разпознава хората, напускащи кораба. Ако човек е гладко избръснат, тя го идентифицира като моряк; ако се установи, че човек има брада, тогава той се идентифицира като пират.

Влизайки в механата, гостът чува поздрав от домакинята-робот в съответствие с неговата категория, например: „Хо-хо-хо, скъпи пират, отидете на маса №...“

Гостът отива на посочената маса, където робот-барманът вече е подготвил стоки за него в съответствие с категорията. Роботът барман предава информация на складовата система, че следващата порция доставка трябва да бъде увеличена; ИС на склада, въз основа на оставащите салда в склада, генерира заявка за покупка в системата за управление.

Докато системата за ранно предупреждение може да е разработена от вашия вътрешен ИТ, програмата за управление на бар роботи може да е създадена от външен изпълнител специално за вашия бизнес. А системите за управление на складове и взаимоотношения с доставчици са персонализирани пакетирани решения от пазара.

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-тонна газела, която принадлежи на вашата таверна. Размерът на вашите поръчки е толкова малък спрямо оборота на доставчиците, че те винаги се изпълняват една по една, без да се чака производството. Имате ли нужда от отделни таблици с такъв бизнес процес: превозни средства, видове превозни средства, необходимо ли е да отделяте план и факт в поръчките си към напуснали доставчици?

Само си представете колко „допълнителни“ връзки ще трябва да напишат вашите програмисти, ако използвате модела по-долу, за да разработите програма.

Да кажем, че решихме, че предложената структура е ненужно сложна; в нашия случай разделянето на плана и факта в записа на поръчката е излишна информация и генерираната спецификация на поръчката се пренаписва въз основа на резултатите от приемането на пристигналите стоки, редки грешки -класирането и пристигането на стоки с неподходящо качество се уреждат извън ИС.
И тогава един ден виждате как цялата зала на таверната е пълна с възмутени и недодялани пирати. Какво стана?

Оказва се, че с разрастването на бизнеса ви нараства и потреблението ви. Някога беше взето управленско решение, че ако една газела е претоварена като обем и/или тегло, което беше изключително рядко, доставчикът ще даде приоритет на товара в полза на напитките.

Недоставените стоки се озоваха в следващата поръчка и тръгнаха на нов полет; наличието на минимален баланс в склада на механата направи възможно да не се забележат липсващи каси.

Последният конкурент затвори на пристанището и пробитият случай на претоварване на газела, заобиколен от приоритизиране въз основа на предположението за достатъчността на минималния баланс и периодичното недостатъчно натоварване на превозното средство, стана обичайна практика. Създадената система идеално ще работи в съответствие с вградените в нея алгоритми и ще бъде лишена от всякаква възможност за проследяване на системното неизпълнение на планираните поръчки. Само повредена репутация и недоволни клиенти ще могат да открият проблема.

Внимателен читател може да е забелязал, че поръчаното количество в спецификацията на поръчката (T_ORDER_SPEC) в раздел 2 и раздел 5 може или не може да отговаря на изискването за първа нормална форма. Всичко зависи от това дали, предвид избрания асортимент от стоки, различни по същество мерни единици могат да попаднат в едно и също поле.

Нарушаване на втората нормална форма:

С нарастването на нуждите ви купувате още няколко превозни средства с различни размери. В горния контекст създаването на директория за превозни средства се счита за излишно; в резултат на това всички алгоритми за обработка на данни, обслужващи нуждите на доставката и склада, възприемат движението на товара от доставчика до склада като полет на изключително 1,5-тонен полет газела. Така че, заедно със закупуването на нови превозни средства, вие все още създавате директория за превозни средства, но когато я финализирате, ще трябва да анализирате целия код, който препраща към движението на товара, за да разберете дали във всяко конкретно място се подразбират препратки към характеристиките на самото превозно средство, от което стартира бизнесът.

Нарушаване на третата нормална форма:

В един момент започвате да създавате програма за лоялност, появява се запис на редовен клиент. Защо, например, да отделяте време за създаване на материални изгледи, които съхраняват обобщени данни за продажбите на отделен клиент за използване при отчитане и прехвърляне към аналитични системи, ако в началото на програмата за лоялност всичко, което интересува клиента, може да бъде поставено в записа на клиента ? И наистина, на пръв поглед няма смисъл. Но всеки път, когато вашият бизнес свързва, например, нови канали за продажба, трябва да има някой сред вашите анализатори, който ще запомни, че съществува такъв атрибут за агрегиране.

При проектирането на всеки нов процес, например продажби в Интернет, продажби чрез дистрибутори, свързани с обща система за лоялност, някой трябва да има предвид, че всички нови процеси трябва да гарантират целостта на данните на ниво код. За индустриална база данни с хиляда таблици това изглежда като невъзможна задача.

Един опитен разработчик, разбира се, знае как да спре всички проблеми, споменати по-горе, но според мен задачата на опитен анализатор не е да ги извади наяве.

Бих искал да изразя своята благодарност на водещия разработчик Евгений Ярухин за ценната му обратна връзка по време на подготовката на публикацията.

Литература

https://habr.com/en/post/254773/
Конъли Томас, Бег Каролайн. База данни. Проектиране, изпълнение и поддръжка. Теория и практика

Източник: www.habr.com