Прывітанне! Мяне клічуць Андрэй Сямёнаў, я старэйшы аналітык у Спортмайстар. У гэтым пасце я жадаю падняць пытанне дэнармалізацыі баз дадзеных ERP-сістэм. Мы разгледзім агульныя ўмовы, а таксама канкрэтны прыклад - скажам, гэта будзе выдатная карчма-манапаліст для піратаў і маракоў. У якой піратаў і маракоў трэба абслугоўваць па-рознаму, бо ўяўленні аб выдатным і спажывецкія патэрны ў гэтых добрых спадароў істотна адрозніваюцца.
Як зрабіць так, каб усе былі задаволены? Як не звар'яцець, праектуючы і падтрымліваючы такую сістэму? Што рабіць, калі ў карчму пачынаюць прыходзіць не толькі звыклыя піраты і маракі?
Усё пад катом. Але пойдзем па парадку.
1. Абмежаванні і дапушчэнні
Усё выкладзенае адносіцца толькі да рэляцыйных баз дадзеных. Добра асветленыя, у тым ліку ў сетцы Інтэрнэт, наступствы дэнармалізацыі ў выглядзе анамалій мадыфікацыі, выдаленні і ўстаўкі не разглядаюцца. За рамкамі публікацыі застаюцца выпадкі, калі дэнармалізацыя з'яўляецца агульным месцам, з класічнымі прыкладамі: серыя і нумар пашпарта, дата і час і іншае.
У пасце выкарыстоўваюцца інтуітыўна зразумелыя і практычна дастасавальныя вызначэнні нармальных формаў, без дасылак да матэматычных тэрмінаў. У тым выглядзе, як яны могуць быць ужытыя да абследавання рэальных бізнес-працэсаў (БП) і праектавання прамысловага ПЗ.
Існуе меркаванне, што праектаванне сховішчаў дадзеных, прылад для стварэння справаздачнасці і інтэграцыйных пагадненняў (у якіх выкарыстоўваецца таблічнае прадстаўленне інфармацыі), адрозніваецца ад праектавання баз дадзеных ERP-сістэм тым, што выгода спажывання і ўжыванне для яго дасягнення ўсвядомленай дэнармалізацыі можа мець прыярытэт над абаронай цэласнасці дадзеных. Я падзяляю гэтае меркаванне, і апісанае ніжэй ставіцца выключна да мадэляў майстар-дадзеных і транзакцыйных дадзеных ERP-сістэм.
Тлумачэнне нармальных форм прыведзена на прыкладзе зразумелым на бытавым узроўні большасці чытачоў. Аднак у якасці нагляднай ілюстрацыі ў пунктах 4-5 свядома выкарыстана падкрэслена "выдуманая" задача. Калі гэтага не зрабіць і ўзяць нейкі хрэстаматыйны прыклад, напрыклад, тую ж мадэль захоўвання замовы з п. 2, можна апынуцца ў сітуацыі, калі фокус увагі чытача будзе зрушаны з прапанаванага раскладання працэсу ў мадэль, на асабісты досвед і ўспрыманне таго, як павінны будавацца працэсы і мадэлі захоўвання дадзеных у ІС. Іншымі словамі, вазьміце двух кваліфікаваных ІТ-аналітыкаў, хай адзін аказвае сэрвіс лагістам, якія перавозяць пасажыраў, іншы - лагістам, якія перавозяць станкі для вытворчасці мікрачыпаў. Папытаеце іх, не абгаворваючы загадзя аўтаматызуемыя БП, скласці мадэль дадзеных для захоўвання інфармацыі аб ЖД-рэйсе.
Існуе ненулявая верагоднасць, што ў прапанаваных мадэлях вы знойдзеце не толькі прыкметна розны набор атрыбутаў, але і несупадальныя наборы сутнасцяў, таму што кожны аналітык будзе абапірацца на звыклыя яму працэсы і задачы. І сказаць у такой сітуацыі, якая мадэль "правільная", немагчыма, таму што няма крытэра ацэнкі.
2. Нармальныя формы
Першая нармальная форма БД патрабуе атамарнасці ўсіх атрыбутаў.
У прыватнасці, калі ў аб'екта A існуюць неключавыя атрыбуты a і b, такія што c=f(a,b) і ў табліцы апісваючай аб'ект A вы захоўваеце значэнне атрыбута с, то ў БД парушана першая нармальная форма. Напрыклад, калі ў спецыфікацыі замовы паказваецца колькасць, адзінкі вымярэння якога залежаць ад тыпу тавара: у адным выпадку гэта могуць быць штукі, у іншым літры, у трэцім пакаванні, якія складаюцца з штук (у мадэлі вышэй Good_count_WR), то ў БД парушаная атамарнасць атрыбутаў. У дадзеным выпадку, каб сказаць, якім павінен быць куст табліц у спецыфікацыі замовы, трэба мэтавае апісанне працэсу працы ў ІС, а бо працэсы могуць быць рознымі, то і "правільных" версій можа быць шмат.
Другая нармальная форма БД патрабуе захавання першай формы і ўласнай табліцы для кожнай сутнасці, якая адносіцца да працэсу працы ў ІС. Калі ў адной табліцы існуюць залежнасці з = f1 (a) і d = f2 (b) і не існуе залежнасці з = f3 (b), то ў табліцы парушана другая нармальная форма. У прыкладзе вышэй у табліцы "Заказ" не існуе залежнасці паміж замовай і адрасам. Зменіце назву вуліцы ці горада, і вы не атрымаеце ніякага ўплыву на істотныя атрыбуты замовы.
Трэцяя нармальная формы БД патрабуе захавання другой нармальнай формы і адсутнасці функцыянальных залежнасцяў паміж атрыбутамі розных сутнасцяў. Гэтае правіла можна сфармуляваць так: "усё, што можа быць разлічана, павінна быць разлічана". Іншымі словамі, калі існуюць два аб'екта A і B. У табліцы, якая захоўвае атрыбуты аб'екта A, праяўлены атрыбут З, у аб'екта B існуе атрыбут b, такі, што існуе c=f4(b), то парушана трэцяя нармальная форма. У прыведзеным ніжэй прыкладзе атрыбут "Колькасць штук" (Total_count_WR) у запісе заказу відавочна прэтэндуе на парушэнне трэцяй нармальнай формы.
3. Мой падыход да прымянення нармалізацыі
1. Толькі мэтавы аўтаматызаваны бізнэс-працэс можа забяспечыць аналітыка крытэрамі для ідэнтыфікацыі сутнасцяў і атрыбутаў пры стварэнні мадэлі захоўвання дадзеных. Стварэнне мадэлі працэсу - абавязковая ўмова стварэнне нармальнай мадэлі дадзеных.
2. Дасягненне трэцяй нармальнай формы ў строгім сэнсе можа быць немэтазгодна ў рэальнай практыцы стварэння ERP-сістэм пры выкананні часткі ці ўсіх наступных умоў:
- аўтаматызуемыя працэсы рэдка схільныя зменам,
- тэрміны на даследаванне і распрацоўку сціснутыя,
- патрабаванні да цэласнасці дадзеных умоўна невысокія (патэнцыйныя памылкі ў прамысловым праграмным забеспячэнні не вядуць да страты грошай ці кліентаў замоўцам ПА)
- і да т.п.
Пры апісаных умовах выдаткі на ідэнтыфікацыю, апісанне жыццёвага цыклу некаторых аб'ектаў і іх атрыбутаў могуць быць не апраўданы з пункта гледжання эканамічнай эфектыўнасці.
3. Любыя наступствы дэнармалізацыі мадэлі дадзеных ва ўжо створанай ІС могуць быць купіраваны дбайным папярэднім даследаваннем кода і тэставаннем.
4. Дэнармалізацыя - спосаб перанесці працавыдаткі з этапу даследавання крыніц дадзеных і праектавання бізнес-працэсу на этап распрацоўкі, з перыяду ўкаранення на перыяд развіцця сістэмы.
5. Да трэцяй нармальнай форме БД мэтазгодна імкнуцца, калі:
- Кірунак змены аўтаматызаваных бізнэс-працэсаў складана прагназуема
- Унутры каманды ўкаранення і/або развіцця ў наяўнасці слабапранікальны падзел працы
- Сістэмы, якія ўваходзяць у інтэграцыйны контур, развіваюцца па ўласных планах
- Няўзгодненасць дадзеных можа прывесці да страты кліентаў або грошай кампаніяй
6. Праектаванне мадэлі даных павінна ажыццяўляцца аналітыкам толькі ў сувязі з мадэлямі мэтавага бізнес-працэсу і працэсу ў ІС. Калі праектаваннем мадэлі дадзеных займаецца распрацоўшчык, яму давядзецца пагрузіцца ў прадметную вобласць да такой ступені, каб, у прыватнасці, разумець розніцу паміж значэннямі атрыбутаў - неабходнае ўмовы выдзялення атамарных атрыбутаў. Такім чынам узяўшы на сябе неўласцівыя функцыі.
4 Задача для ілюстрацыі
Дапушчальны, у вас ёсць невялікая рабатызаваных карчма ў порце. Ваш сегмент рынка: маракі і піраты, якія заходзяць у порт і маюць патрэбу ў адпачынку. Маракам вы прадаеце гарбату з чаборам, а піратам ром і касцяныя грабяні для расчэсваннем барады. Сэрвіс у самой карчме аказваецца робатам-хостэс і робатам-бармэнам. Дзякуючы высокай якасці і нізкіх коштах вы выцеснілі ўсіх канкурэнтам, так што кожны сыходзячы з карабля прыходзіць у вашу карчму, якая з'яўляецца адзінай у порце.
Комплекс інфармацыйных сістэм карчмы складаецца з наступнага ПЗ:
- Сістэма ранняй абвесткі аб кліенце, якая распазнае яго катэгорыю па характэрных прыкметах.
- Сістэма кіравання робатамі-хостэс і робатамі-бармэнамі
- Сістэма кіравання складам і дастаўкай у кропку продажаў
- Сістэма кіравання адносінамі з пастаўшчыкамі (СУАП)
працэс:
Сістэма ранняй абвесткі распазнае якія сыходзяць з карабля людзей. Калі чалавек гладка паголены, яна вызначае яго як марака, калі ў чалавека выяўлена барада, то ён вызначаецца як пірат.
Уваходзячы ў карчму, госць чуе ад робата-хостэс прывітанне ў адпаведнасці са сваёй катэгорыяй, напрыклад: «Хо-хо-хо, шаноўны пірат, прайдзіце за стол №…»
Госць праходзіць за ўказаны стол, дзе робат-бармэн ужо падрыхтаваў для яго тавары ў адпаведнасці з катэгорыяй. Робат-бармэн перадае інфармацыю ў складскую сістэму аб тым, што наступная порцыя дастаўкі павінна быць павялічана, складская ІС зыходзячы з рэштак у захоўванні фармуе заяўку на закуп у СУОП.
Няхай сістэму ранняй абвесткі распрацавала ваша ўнутранае ІТ, праграму кіравання барнымі робатамі стварыў знешні падрадчык спецыяльна пад ваш бізнэс. А сістэмы для кіравання складам і адносінамі з пастаўшчыкамі з'яўляюцца кастамізаваны скрыначнымі рашэннямі з рынку.
5. Прыклады дэнармалізацыі і яе ўплыў на развіццё ПЗ
Пры праектаванні бізнес-працэсу апытаныя эксперты прадметнай вобласці ў адзін голас заявілі, што ва ўсім свеце піраты п'юць ром і расчэсваюць бароды касцянымі грабянямі, а маракі п'юць гарбату з чаборам і заўсёды гладка паголены.
З'яўляецца даведнік тыпаў кліентаў з двух значэнняў: 1 – піраты, 2 – маракі, агульны для ўсяго інфармацыйнага контуру кампаніі.
Сістэма абвесткі аб кліенце адразу захоўвае вынік апрацоўкі выявы як ідэнтыфікатар (ВД) распазнанага кліента і яго тып: марака ці пірата.
ВД Распазнанага аб'екта
катэгорыя кліента
100500
Пірат
100501
Пірат
100502
марак
Яшчэ раз звернем увагу, што
1. Нашы маракі на самой справе голеныя людзі
2. Нашы піраты на самой справе барадатыя людзі
Якія ў дадзеным выпадку праблемы неабходна ўхіліць, каб наша структура імкнулася да трэцяй звычайнай формы:
- парушэнне атамарнасці атрыбуту — Катэгорыя кліента
- змешванне аналізуемага факта і вываду ў адной табліцы
- зафіксаваная функцыянальная залежнасць паміж атрыбутамі розных сутнасцяў.
У нармалізаваным выглядзе мы атрымалі б дзве табліцы:
- вынік распазнання ў выглядзе набору ўсталяваных прыкмет,
ВД Распазнанага аб'екта
Валасяны полаг на твары
100500
Так
100501
Так
100502
Няма
- вынік вызначэння тыпу кліента як дадатак закладзенай у ІС логікі для інтэрпрэтацыі устаноўленых прыкмет
ВД распазнанага аб'екта
ВД ідэнтыфікацыі
катэгорыя кліента
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-тоннай газэлі. Такім чынам, разам з пакупкай новых транспартных сродкаў вы ўсё-такі ствараеце даведнік транспартных сродкаў, але пры дапрацоўцы вам давядзецца прааналізаваць увесь код, які спасылаецца на перамяшчэнне грузу, каб высветліць, ці не маюцца на ўвазе ў кожным канкрэтным месцы спасылкі на характарыстыкі таго самага аўтамабіля, з якога пачынаўся бізнэс.
Парушэнне трэцяй нармальнай формы:
У нейкі момант вы пачынаеце ствараць праграму лаяльнасці, з'яўляецца запіс сталага кліента. Навошта, напрыклад, марнаваць час на стварэнне матэрыяльных уяўленняў, якія захоўваюць агрэгаваныя дадзеныя па продажах асобнаму кліенту для выкарыстання ў справаздачнасці і перадачы ў аналітычныя сістэмы, калі на этапе старту праграмы лаяльнасці ўсё, што цікавіць замоўца, можна размясціць на запісы самога кліента? І, сапраўды, сэнсу, на першы погляд, няма. Але кожны раз, калі ваш бізнэс будзе падключаць, напрыклад, новыя каналы продажаў, сярод вашых аналітыкаў павінен быць нехта, хто ўспомніць, што існуе такі агрэгацыйны атрыбут.
Праектуючы кожны новы працэс, дапусцім, продажы ў сетцы Інтэрнэт, продажы праз дыстрыбутараў падлучаных да агульнай сістэмы лаяльнасці, хтосьці павінен памятаць, што ўсе новыя працэсы павінны забяспечваць на ўзроўні кода цэласнасць дадзеных. Для прамысловай БД з тысячай табліц гэта здаецца малавыканальнай задачай.
Вопытны распрацоўшчык, вядома ж, ведае, як купіраваць усе азначаныя вышэй праблемы, але, на мой погляд, задача вопытнага аналітыка – да іх не даводзіць.
Жадаю выказаць падзяку за каштоўную зваротную сувязь пры падрыхтоўцы публікацыі вядучаму распрацоўніку Яўгену Ярухіну.
Літаратура
Коналі Томас, Бег Каралін. Базы даных. Праектаванне, рэалізацыя і суправаджэнне. Тэорыя і практыка
Крыніца: habr.com