Halló! Ég heiti Andrey Semenov, ég er háttsettur sérfræðingur hjá Sportmaster. Í þessari færslu vil ég vekja máls á afeðlun ERP kerfisgagnagrunna. Við munum skoða almenn skilyrði, sem og sérstakt dæmi - við skulum segja að það væri dásamlegt einokunarhús fyrir sjóræningja og sjómenn. Þar sem sjóræningjum og sjómönnum verður að þjóna öðruvísi, því fegurðarhugmyndir og neyslumynstur þessara góðu herramanna eru verulega ólíkar.
Hvernig á að gera alla ánægða? Hvernig geturðu forðast að verða brjálaður að hanna og viðhalda slíku kerfi? Hvað á að gera ef ekki aðeins venjulegir sjóræningjar og sjómenn byrja að koma á krána?
Allt er undir högg að sækja. En förum í röð.
1. Takmarkanir og forsendur
Allt ofangreint á aðeins við um venslagagnagrunna. Ekki er tekið tillit til afleiðinga afeðlunar í formi breytinga, eyðingar og innsetningarfrávika, sem farið er vel yfir, þar á meðal á netinu. Utan gildissviðs þessa rits eru tilfelli þar sem afeðlun er algengur staður, með klassískum dæmum: vegabréfaröð og númer, dagsetningu og tíma o.s.frv.
Færslan notar innsæi og nánast viðeigandi skilgreiningar á venjulegum formum, án tilvísunar í stærðfræðileg hugtök. Í því formi sem hægt er að beita þeim við athugun á raunverulegum viðskiptaferlum (BP) og hönnun iðnaðarhugbúnaðar.
Því er haldið fram að hönnun gagnavöruhúsa, skýrslutækja og samþættingarsamninga (sem nota framsetningu upplýsinga í töfluformi) sé frábrugðin hönnun gagnagrunna ERP kerfisins að því leyti að auðveld neysla og notkun meðvitaðrar afeðlunar til að ná því fram geti tekið forgang fram yfir heilleika. verndargögn. Ég deili þessari skoðun og það sem lýst er hér að neðan á eingöngu við um aðalgögn og viðskiptagagnalíkön ERP kerfa.
Útskýring á venjulegum formum er gefin með dæmi sem er skiljanlegt á hversdagsleikastigi fyrir flesta lesendur. Hins vegar, sem sjónræn lýsing, í liðum 4-5, var vísvitandi „skáldað“ verkefni notað vísvitandi. Ef þú gerir þetta ekki og tekur eitthvert kennslubókardæmi, til dæmis sama pöntunargeymslulíkan frá lið 2, gætirðu lent í aðstæðum þar sem fókus lesandans færist frá fyrirhugaðri niðurbroti ferlisins í líkan, til persónulegrar upplifunar og skynjunar á því hvernig ferli og líkön til að geyma gögn í IS verða að vera byggð upp. Með öðrum orðum, taktu tvo hæfa upplýsingatæknifræðinga, láttu annan veita þjónustu við flutningamenn sem flytja farþega, hinn til flutningamenn sem flytja vélar til framleiðslu á örflögum. Biddu þá, án þess að ræða sjálfvirkar BPs fyrirfram, að búa til gagnalíkan til að geyma upplýsingar um járnbrautarferð.
Það eru engar líkur á því að í fyrirhuguðum líkönum finnurðu ekki aðeins áberandi mismunandi eiginleika eiginleika, heldur einnig mismunandi mengi eininga, vegna þess að hver sérfræðingur mun treysta á ferla og verkefni sem hann kannast við. Og í slíkum aðstæðum er ómögulegt að segja hvaða líkan er „rétt“, því það er engin matsviðmiðun.
2. Venjuleg form
Fyrsta eðlilega form gagnagrunnsins krefst atómvirkni allra eiginleika.
Sérstaklega ef hlutur A hefur ekki lykileiginleika a og b, þannig að c=f(a,b) og í töflunni sem lýsir hlut A geymir þú gildi eigindarinnar c, þá er fyrsta eðlilega formið brotið í gagnagrunninum . Til dæmis, ef pöntunarforskriftin gefur til kynna magn, þar sem mælieiningarnar eru háðar tegund vörunnar: í einu tilviki getur það verið stykki, í öðru lítra, í þriðja pakka sem samanstendur af stykki (í líkaninu hér að ofan Good_count_WR) , þá er brotið gegn atómvirkni eiginda í gagnagrunninum. Í þessu tilviki, til þess að segja til um hver töfluklasinn pöntunarforskriftarinnar á að vera, þarf markvissa lýsingu á vinnuferlinu í IS og þar sem ferlarnir geta verið mismunandi geta verið margar „réttar“ útgáfur.
Annað eðlilegt form gagnagrunnsins krefst samræmis við fyrsta eyðublaðið og eigin töflu fyrir hverja einingu sem tengist vinnuferlinu í IS. Ef í einni töflu eru háðir c=f1(a) og d=f2(b) og það er engin háð c=f3(b), þá er annað eðlilegt form brotið í töflunni. Í dæminu hér að ofan er ekkert háð milli pöntunar og heimilisfangs í pöntunartöflunni. Breyttu götu- eða borgarnafni og þú hefur engin áhrif á nauðsynlega eiginleika pöntunarinnar.
Þriðja venjulegt form gagnagrunnur krefst samræmis við annað eðlilegt form og fjarveru starfrænna ósjálfstæðis milli eiginleika mismunandi eininga. Þessa reglu má móta á eftirfarandi hátt: „allt sem hægt er að reikna verður að reikna út“. Með öðrum orðum, ef það eru tveir hlutir A og B. Í töflunni sem geymir eiginleika hlutar A birtist eiginleiki C og hlutur B hefur eiginleika b, þannig að c=f4(b) er til, þá er þriðja eðlilega formið er brotið. Í dæminu hér að neðan segist eigindin Magn stykki (Total_count_WR) á pöntunarskránni greinilega brjóta í bága við þriðja eðlilega mynd
3. Mín nálgun við að beita normalization
1. Aðeins sjálfvirkt viðskiptaferli getur veitt sérfræðingnum viðmið til að auðkenna einingar og eiginleika þegar gagnageymslulíkan er búið til. Að búa til ferlilíkan er forsenda þess að hægt sé að búa til eðlilegt gagnalíkan.
2. Að ná þriðja eðlilegu formi í ströngum skilningi gæti ekki verið raunhæft í raunverulegri framkvæmd við að búa til ERP kerfi ef sum eða öll eftirfarandi skilyrði eru uppfyllt:
- sjálfvirkir ferlar eru sjaldan háðir breytingum,
- frestir til rannsókna og þróunar eru þröngir,
- kröfur um gagnaheilleika eru tiltölulega lágar (hugsanlegar villur í iðnaðarhugbúnaði leiða ekki til þess að hugbúnaðarviðskiptavinur tapi peningum eða viðskiptavinum)
- o.fl.
Við lýstar aðstæður er ekki víst að kostnaður við að greina og lýsa líftíma sumra hluta og eiginleika þeirra sé ekki réttlætanlegur út frá hagkvæmni.
3. Allar afleiðingar afeðlunar á gagnalíkaninu í þegar búið til IS er hægt að draga úr með ítarlegri forrannsókn á kóðanum og prófunum.
4. Afeðlun er leið til að flytja launakostnað frá því stigi að rannsaka gagnaheimildir og hanna viðskiptaferli yfir á þróunarstig, frá innleiðingartímabili til kerfisþróunartímabils.
5. Ráðlegt er að leitast við þriðja eðlilega gerð gagnagrunns ef:
- Erfitt er að spá fyrir um stefnu breytinga í sjálfvirkum viðskiptaferlum
- Veik verkaskipting er innan innleiðingar- og/eða þróunarteymis
- Kerfi sem eru með í samþættingarrásinni þróast samkvæmt eigin áætlunum
- Gagnaósamræmi getur leitt til þess að fyrirtæki tapi viðskiptavinum eða peningum
6. Hönnun gagnalíkans ætti aðeins að vera framkvæmd af sérfræðingur í tengslum við líkönin af markmiðsviðskiptaferlinu og ferlinu í IS. Ef verktaki er að hanna gagnalíkan verður hann að sökkva sér niður í viðfangsefnið að því marki að hann skilur sérstaklega muninn á eigindagildum - nauðsynlegt skilyrði til að einangra atómeiginleika. Þannig að taka að sér óvenjulegar aðgerðir.
4 Vandamál til skýringar
Segjum að þú sért með lítinn vélfærakrá í höfninni. Markaðshlutinn þinn: sjómenn og sjóræningjar sem koma í höfn og þurfa hlé. Þú selur sjómönnum te með blóðbergi og romm- og beinakambur til að greiða skegg til sjóræningja. Þjónustan í kránni sjálfri er veitt af vélmennaverði og vélmennabarþjóni. Þökk sé háum gæðum og lágu verði hefurðu hrakið keppinauta þína út, þannig að allir sem koma af skipinu koma í krána þína, sem er sá eini í höfninni.
Tavern upplýsingakerfissamstæðan samanstendur af eftirfarandi hugbúnaði:
- Snemma viðvörunarkerfi um viðskiptavin sem viðurkennir flokk sinn út frá einkennandi eiginleikum
- Stjórnkerfi fyrir vélmenni húsfreyjur og vélmenni barþjóna
- Vöru- og afhendingarstjórnunarkerfi á sölustað
- Birgjatengslastjórnunarkerfi (SURP)
Aðferð:
Snemma viðvörunarkerfið viðurkennir fólk sem yfirgefur skipið. Ef maður er sléttrakaður, skilgreinir hún hann sem sjómann, ef maður reynist vera með skegg, þá er hann auðkenndur sem sjóræningi.
Þegar komið er inn í krána heyrir gesturinn kveðju frá vélmenni í samræmi við flokk hans, til dæmis: „Hó-hó-hó, kæri sjóræningi, farðu að borði nr...“
Gestur fer að tilgreindu borði þar sem vélmennabarþjónninn hefur þegar útbúið vörur fyrir hann í samræmi við flokkinn. Vélmennabarþjónninn sendir upplýsingar til vöruhúsakerfisins um að næsta hluta af afhendingu ætti að aukast; vöruhúsið IS, byggt á eftirstöðvum í geymslu, býr til innkaupabeiðni í stjórnunarkerfinu.
Þó að viðvörunarkerfið hafi verið þróað af innri upplýsingatækninni þinni, gæti stjórnunaráætlun fyrir barvélmenni hafa verið búið til af utanaðkomandi verktaka sérstaklega fyrir fyrirtæki þitt. Og kerfi til að stjórna vöruhúsum og samskiptum við birgja eru sérsniðnar pakkaðar lausnir frá markaðnum.
5. Dæmi um afeðlun og áhrif hennar á hugbúnaðarþróun
Við hönnun viðskiptaferlis sögðu efnissérfræðingarnir sem rætt var við samhljóða að um allan heim drekka sjóræningjar romm og greiða skeggið með beinakambum og sjómenn drekka te með timjan og eru alltaf hreinrakaðir.
Skrá yfir tegundir viðskiptavina birtist með tveimur gildum: 1 - sjóræningjar, 2 - sjómenn, sameiginlegt fyrir alla upplýsingarás fyrirtækisins.
Tilkynningarkerfi viðskiptavinarins geymir strax niðurstöðu myndvinnslu sem auðkenni (auðkenni) viðurkennda viðskiptavinar og tegund hans: sjómaður eða sjóræningi.
Viðurkennt hlutauðkenni
Viðskiptavinaflokkur
100500
Pirate
100501
Pirate
100502
Sjómaður
Við skulum enn og aftur athuga það
1. Sjómenn okkar eru í raun rakað fólk
2. Sjóræningjar okkar eru í raun og veru skeggjaðir
Hvaða vandamál þarf að útrýma í þessu tilfelli svo að uppbygging okkar leitist eftir þriðja eðlilega formi:
- brot á eiginleikum atomicity - Viðskiptavinaflokkur
- blanda saman greindu staðreyndinni og niðurstöðunni í eina töflu
- fast starfrænt samband milli eiginleika mismunandi aðila.
Í eðlilegu formi myndum við fá tvær töflur:
- niðurstöður viðurkenningar í formi safns af staðfestum eiginleikum,
Viðurkennt hlutauðkenni
Andlitshár
100500
Já
100501
Já
100502
No
- afleiðing þess að ákvarða tegund viðskiptavinar sem beitingu rökfræðinnar sem er innbyggð í IS til að túlka staðfest einkenni
Viðurkennt hlutauðkenni
Auðkenni
Viðskiptavinaflokkur
100500
100001
Pirate
100501
100002
Pirate
100502
100003
Sjómaður
Hvernig getur staðlað gagnageymslufyrirtæki auðveldað þróun IP flókins? Segjum að þú færð allt í einu nýja viðskiptavini. Látum það vera japanska sjóræningja sem eru kannski ekki með skegg, en þeir ganga með páfagauk á öxlinni, og umhverfisverndarsinnar, þú getur auðveldlega þekkt þá á bláu sniði Gretu á vinstri brjósti.
Umhverfissjóræningjar geta náttúrulega ekki notað beinakambur og krefjast hliðstæðu úr endurunnu sjávarplasti.
Þú þarft að endurvinna reiknirit forritsins í samræmi við nýju inntakið. Ef eðlilegum reglum væri fylgt, þá þyrfti aðeins að bæta við aðföngin fyrir sumar vinnslugreinar í sumum kerfum og búa til nýjar greinar eingöngu fyrir þau tilvik og í þeim IS þar sem andlitshár skipta máli. En þar sem reglunum var ekki fylgt, verður þú að greina allan kóðann, í gegnum alla hringrásina, þar sem gildi viðskiptavinategundaskrárinnar eru notuð og koma greinilega á framfæri að í einu tilviki ætti reikniritið að taka tillit til fagmannsins virkni viðskiptavinarins og í öðrum líkamlegum eiginleikum.
Í því formi sem leitar til að staðla þá myndum við fá tvær töflur með rekstrargögnum og tvær möppur:
- niðurstöður viðurkenningar í formi safns af staðfestum eiginleikum,
Viðurkennt hlutauðkenni
Greta á vinstri bringu
Fugl á öxl
Andlitshár
100510
1
1
1
100511
0
0
1
100512
1
0
- niðurstaðan af því að ákvarða tegund biðlara (láta það vera sérsniðið útsýni þar sem lýsingar úr möppum eru birtar)
Þýðir afeðlunin sem greinist að ekki sé hægt að breyta kerfunum til að uppfylla nýjar aðstæður? Auðvitað ekki. Ef við ímyndum okkur að öll upplýsingakerfin hafi verið búin til af einu teymi með núll starfsmannaveltu, þróunin er vel skjalfest og upplýsingar fluttar innan teymisins án taps, þá er hægt að gera nauðsynlegar breytingar með hverfandi lítilli fyrirhöfn. En ef við snúum aftur til upprunalegra aðstæðna vandans verður 1,5 lyklaborðum eytt bara til að prenta samskiptareglur sameiginlegra viðræðna og önnur 0,5 til að vinna úr innkaupaferli.
Í dæminu hér að ofan eru öll þrjú eðlileg form brotin, við skulum reyna að brjóta þau sérstaklega.
Brot á fyrstu eðlilegu mynd:
Segjum að vörur séu afhentar á vöruhús þitt frá vöruhúsum birgja með því að sækja með einni 1.5 tonna gasellu sem tilheyrir kránni þinni. Stærð pantana þinna er svo lítil miðað við veltu birgjanna að þær eru alltaf gerðar einn á einn án þess að bíða eftir framleiðslu. Þarftu sérstakar töflur með slíku viðskiptaferli: farartæki, tegundir farartækja, er nauðsynlegt að aðgreina áætlun og staðreyndir í pöntunum þínum til brottfarar birgja?
Ímyndaðu þér hversu margar „auka“ tengingar forritarar þínir þurfa að skrifa ef þú notar líkanið hér að neðan til að þróa forrit.
Segjum að við ákváðum að fyrirhuguð uppbygging sé óþarflega flókin; í okkar tilviki, að aðskilja áætlunina og staðreyndina í pöntunarskránni eru óþarfar upplýsingar, og pöntunarforskriftin sem myndast er endurskrifuð út frá niðurstöðum við móttöku á komnum vörum, sjaldgæft misskilningur -flokkun og komu vöru af ófullnægjandi gæðum er gert upp utan IS.
Og svo einn daginn sérðu hvernig allur kráarsalurinn er fullur af reiðilegum og ósnortnum sjóræningjum. Hvað gerðist?
Það kemur í ljós að eftir því sem fyrirtæki þitt stækkaði þá jókst neyslan líka. Einu sinni var tekin sú ákvörðun stjórnenda að ef gasella væri ofhlaðin í rúmmáli og/eða þyngd, sem var afar sjaldgæft, myndi birgir forgangsraða álaginu í þágu drykkja.
Óafhentar vörur enduðu í næstu pöntun og fóru í nýtt flug, tilvist lágmarksupphæðar í vörugeymslunni á kránni gerði það að verkum að ekki var hægt að taka eftir málum sem vantaði.
Síðasti keppandinn lokaði í höfninni og götótt tilfelli af ofhleðslu gasellu, framhjá með forgangsröðun á grundvelli forsendu um nægjanlegt lágmarksjafnvægi og reglubundið vanhleðslu ökutækisins, varð algeng venja. Kerfið sem búið er til mun helst vinna í samræmi við reiknirit sem eru felld inn í það og verður svipt öllum tækifærum til að fylgjast með kerfisbundinni bilun í að uppfylla fyrirhugaðar pantanir. Aðeins skaðað orðspor og óánægðir viðskiptavinir munu geta greint vandamálið.
Athugull lesandi gæti hafa tekið eftir því að pantað magn í pöntunarlýsingunni (T_ORDER_SPEC) í hluta 2 og kafla 5 gæti eða gæti ekki uppfyllt kröfuna um fyrsta eðlilega form. Það veltur allt á því hvort, miðað við valið vöruúrval, geta í raun mismunandi mælieiningar fallið á sama sviði.
Brot á annarri eðlilegri mynd:
Eftir því sem þarfir þínar vaxa, kaupir þú nokkra bíla í viðbót af mismunandi stærðum. Í ofangreindu samhengi var gerð ökutækjaskrá talin óþörf; þar af leiðandi skynja öll gagnavinnslu reiknirit sem þjóna þörfum afhendingar og vörugeymslu flutning á farmi frá birgi til vöruhúss sem flug á eingöngu 1,5 tonna gasellu. Svo, ásamt kaupum á nýjum ökutækjum, býrðu samt til ökutækjaskrá, en þegar þú klárar hana þarftu að greina allan kóðann sem vísar til hreyfingar farms til að komast að því hvort á hverjum tilteknum stað sé gefið í skyn tilvísanir í eiginleika af ökutækinu sem viðskipti hófust úr.
Brot á þriðju eðlilegu formi:
Á einhverjum tímapunkti byrjar þú að búa til vildarkerfi, skrá yfir venjulegan viðskiptavin birtist. Hvers vegna til dæmis að eyða tíma í að búa til efnislegar skoðanir sem geyma uppsöfnuð gögn um sölu til einstaks viðskiptavinar til notkunar við skýrslugerð og flutning yfir í greiningarkerfi, ef við upphaf vildarkerfis er hægt að setja allt sem vekur áhuga viðskiptavinarins á skrá viðskiptavinarins ? Og reyndar, við fyrstu sýn, er ekkert vit í því. En í hvert skipti sem fyrirtækið þitt tengir, til dæmis, nýjar sölurásir, ætti að vera einhver meðal greinenda þinna sem mun muna að slík samsöfnunareiginleiki er til.
Við hönnun á hverju nýju ferli, til dæmis sölu á Netinu, sölu í gegnum dreifingaraðila sem tengjast sameiginlegu vildarkerfi, verður einhver að hafa í huga að öll ný ferli verða að tryggja gagnaheilleika á kóðastigi. Fyrir iðnaðargagnagrunn með þúsund töflum virðist þetta vera ómögulegt verkefni.
Reyndur verktaki veit auðvitað hvernig á að stöðva öll vandamálin sem nefnd eru hér að ofan, en að mínu mati er verkefni reyndra sérfræðings ekki að draga þau fram í dagsljósið.
Ég vil koma á framfæri þakklæti mínu til leiðandi verktaki Evgeniy Yarukhin fyrir dýrmæt endurgjöf hans við undirbúning útgáfunnar.
Bókmenntir
Connolly Thomas, Begg Caroline. Gagnagrunnur. Hönnun, innleiðing og stuðningur. Fræði og framkvæmd
Heimild: www.habr.com