Helló! A nevem Andrey Semenov, a Sportmaster vezető elemzője vagyok. Ebben a bejegyzésben az ERP rendszer adatbázisainak denormalizálásának kérdését szeretném felvetni. Megvizsgáljuk az általános feltételeket, valamint egy konkrét példát – mondjuk ez egy csodálatos monopolvendéglő lenne a kalózok és tengerészek számára. Amelyben másként kell szolgálni a kalózokat és a tengerészeket, mert ezeknek a jó uraknak a szépségről alkotott elképzelései és a fogyasztói minták jelentősen különböznek.
Hogyan lehet mindenkit boldoggá tenni? Hogyan kerülheti el, hogy megőrüljön egy ilyen rendszer tervezése és karbantartása? Mi a teendő, ha nem csak a szokásos kalózok és tengerészek kezdenek jönni a kocsmába?
Minden a vágás alatt van. De menjünk sorban.
1. Korlátozások és feltételezések
A fentiek mindegyike csak a relációs adatbázisokra vonatkozik. Nem vesszük figyelembe a denormalizáció következményeit a módosítások, törlések és beillesztési anomáliák formájában, amelyek jól le vannak fedve, beleértve az Internetet is. A kiadvány keretein kívül vannak olyan esetek, amikor a denormalizálás gyakori hely, klasszikus példákkal: útlevélsorozat és -szám, dátum és idő stb.
A poszt intuitív és gyakorlatilag alkalmazható definícióit használja a normálformákra, matematikai kifejezésekre való hivatkozás nélkül. Abban a formában, ahogyan alkalmazhatók valós üzleti folyamatok (BP) vizsgálatára és ipari szoftverek tervezésére.
Azzal érvelnek, hogy az adattárházak, a jelentéskészítő eszközök és az integrációs megállapodások (amelyek az információk táblázatos megjelenítését használják) kialakítása abban különbözik az ERP-rendszerek adatbázisainak kialakításától, hogy a fogyasztás egyszerűsége és a tudatos denormalizálás alkalmazása elsőbbséget élvezhet az integritással szemben. védelmi adatok. Osztom ezt a véleményt, és az alábbiakban leírtak kizárólag az ERP rendszerek törzsadataira és tranzakciós adatmodelljére vonatkoznak.
A normál formák magyarázatát a legtöbb olvasó számára hétköznapi szinten érthető példa segítségével adjuk meg. Vizuális szemléltetésként azonban a 4-5. bekezdésekben szándékosan „kitalált” feladatot használtak. Ha ezt nem teszi meg, és egy tankönyvi példát vesz át, például ugyanazt a rendeléstárolási modellt a 2. pontból, akkor olyan helyzetbe kerülhet, hogy az olvasó figyelme a folyamat javasolt lebontásáról egy modellre tolódik el, személyes tapasztalatra és felfogásra, hogyan kell felépíteni az IS-ben való adattárolás folyamatait és modelljeit. Vagyis vegyünk két képzett informatikai elemzőt, az egyik szolgáltasson utasokat szállító logisztikusokat, a másik pedig a mikrochipek gyártásához szükséges gépeket szállító logisztikusokat. Kérje meg őket anélkül, hogy előzetesen megbeszélnék az automatizált BP-ket, hogy hozzanak létre egy adatmodellt a vasúti utazással kapcsolatos információk tárolására.
Nem nulla a valószínűsége annak, hogy a javasolt modellekben nemcsak észrevehetően eltérő attribútumkészleteket talál, hanem eltérő entitáskészleteket is, mert minden elemző a számára ismert folyamatokra és feladatokra támaszkodik. Ilyen helyzetben pedig nem lehet megmondani, hogy melyik modell a „helyes”, mert nincs értékelési kritérium.
2. Normál formák
Az adatbázis első normál formája minden attribútum atomosságát igényli.
Különösen, ha az A objektum nem kulcsfontosságú a és b attribútumokkal rendelkezik, így c=f(a,b) és az A objektumot leíró táblázatban a c attribútum értékét tárolja, akkor az első normál forma sérül az adatbázisban. . Például, ha a rendelési specifikáció olyan mennyiséget jelez, amelynek mértékegységei a termék típusától függenek: az egyik esetben darab, a másikban liter, a harmadik esetben darabokból álló kiszerelés (a Good_count_WR fenti modellben) , akkor az attribútumok atomitása sérül az adatbázisban. Ebben az esetben ahhoz, hogy megmondjuk, hogy milyen legyen a rendelési specifikáció táblafürtje, szükség van a munkafolyamat célzott leírására az IS-ben, és mivel a folyamatok eltérőek lehetnek, sokféle „helyes” verzió lehet.
Az adatbázis második normál formája megköveteli az első űrlap betartását és saját táblázatát az IS-ben lévő munkafolyamattal kapcsolatos minden entitáshoz. Ha egy táblában vannak c=f1(a) és d=f2(b) függőségek, és nincs c=f3(b) függőség, akkor a második normálalakot sértjük a táblázatban. A fenti példában nincs függőség a rendelés és a Megrendelés táblázatban szereplő cím között. Változtassa meg az utca vagy város nevét, és nincs hatással a megrendelés lényeges tulajdonságaira.
Harmadik normál formátumú adatbázis megköveteli a második normálalak betartását és a funkcionális függőségek hiányát a különböző entitások attribútumai között. Ezt a szabályt a következőképpen lehet megfogalmazni: „mindent, ami kiszámítható, kiszámítani kell.” Más szóval, ha két A és B objektum van. Az A objektum attribútumait tároló táblázatban a C attribútum manifesztálódik, és B objektumnak b attribútuma van, így létezik c=f4(b), akkor a harmadik normálforma. megsértik. Az alábbi példában a Darabmennyiség attribútum (Total_count_WR) a rendelési rekordban egyértelműen azt állítja, hogy megsérti a harmadik normál formát.
3. Megközelítésem a normalizálás alkalmazásához
1. Csak egy megcélzott automatizált üzleti folyamat tud az elemző számára kritériumokat biztosítani az entitások és attribútumok azonosításához az adattárolási modell létrehozásakor. A folyamatmodell létrehozása a normál adatmodell létrehozásának előfeltétele.
2. A szigorú értelemben vett harmadik normálforma elérése nem feltétlenül praktikus az ERP-rendszerek létrehozásának tényleges gyakorlatában, ha az alábbi feltételek közül néhány vagy mindegyik teljesül:
- az automatizált folyamatok ritkán változnak,
- a kutatás-fejlesztés határideje szoros,
- az adatintegritás követelményei viszonylag alacsonyak (az ipari szoftverek lehetséges hibái nem vezetnek pénz- vagy ügyfélveszteséghez a szoftvervásárló által)
- stb
Az ismertetett feltételek mellett előfordulhat, hogy egyes objektumok, jellemzőik életciklusának azonosításának, leírásának költségei a gazdasági hatékonyság szempontjából nem indokoltak.
3. Az adatmodell denormalizálásának következményei egy már létrehozott IS-ben mérsékelhetők a kód alapos előzetes tanulmányozásával és teszteléssel.
4. A denormalizálás egy módja annak, hogy a munkaerőköltségeket az adatforrások kutatásának és az üzleti folyamat tervezésének szakaszából a fejlesztési szakaszba, a megvalósítás időszakából a rendszerfejlesztés időszakába vigyük át.
5. Célszerű az adatbázis harmadik normál formájára törekedni, ha:
- Az automatizált üzleti folyamatok változásának iránya nehezen megjósolható
- Gyenge a munkamegosztás a megvalósítási és/vagy fejlesztői csapaton belül
- Az integrációs áramkörbe tartozó rendszerek saját terveik szerint fejlődnek
- Az adatok következetlensége miatt a vállalat ügyfeleket vagy pénzt veszíthet
6. Az adatmodell tervezését elemző csak a cél üzleti folyamat és az IS-ben lévő folyamat modelljeivel összefüggésben végezheti el. Ha egy fejlesztő adatmodellt tervez, akkor olyan mértékben kell elmerülnie a témakörben, hogy különösen megértse az attribútumértékek közötti különbséget - ez az atomi attribútumok elkülönítésének szükséges feltétele. Így szokatlan funkciókat vállalva.
4 Szemléltetésképpen probléma
Tegyük fel, hogy van egy kis robotvendéglőd a kikötőben. Az Ön piaci szegmense: tengerészek és kalózok, akik kikötőbe érkeznek, és szünetre van szükségük. Kakukkfüves teát árulsz tengerészeknek, rum- és csontfésűt pedig szakállfésüléshez a kalózoknak. Magában a tavernában a szolgáltatást egy robot háziasszony és egy robotcsapos látja el. Magas minőségének és alacsony árainak köszönhetően kiszorítottad versenytársaidat, így mindenki a hajóról leszálló kocsmádba jön, ami a kikötőben egyedül van.
A taverna információs rendszer komplexum a következő szoftverekből áll:
- Korai figyelmeztető rendszer egy kliensről, amely a jellemzők alapján felismeri kategóriáját
- Vezérlőrendszer robot hostessek és robotcsaposok számára
- Raktári és szállítási rendszer az értékesítési pontig
- Szállítói kapcsolatkezelő rendszer (SURP)
folyamat:
A korai figyelmeztető rendszer felismeri a hajót elhagyó embereket. Ha egy személy tisztára borotvált, akkor tengerészként azonosítja, ha pedig szakállas, akkor kalózként azonosítják.
A kocsmába belépve a vendég kategóriájának megfelelő köszönést hall a robot háziasszonytól, például: „Ho-ho-ho, kedves kalóz, menj a No... asztalhoz”
A vendég a megadott asztalhoz megy, ahol a robotcsapos már elkészítette számára a kategóriának megfelelő árut. A robotcsapos információt továbbít a raktári rendszernek, hogy a kiszállítás következő részét növelni kell, a raktár IS a raktárban lévő fennmaradó egyenlegek alapján vásárlási kérelmet generál az irányítási rendszerben.
Míg a korai figyelmeztető rendszert az Ön belső IT-je fejlesztette ki, a bárrobot-kezelő programot egy külső vállalkozó készítette kifejezetten az Ön vállalkozása számára. A raktárak és a beszállítókkal fenntartott kapcsolatok menedzselésére szolgáló rendszerek pedig testreszabott csomagolt megoldások a piacról.
5. Példák a denormalizációra és annak szoftverfejlesztésre gyakorolt hatásaira
Egy üzleti folyamat megtervezésekor a megkérdezett témaszakértők egybehangzóan azt állították, hogy a kalózok világszerte rumot isznak, és csontfésűvel fésülik a szakállukat, a tengerészek pedig kakukkfűvel isszák a teát és mindig borotváltak.
Megjelenik a klienstípusok katalógusa két értékkel: 1 - kalózok, 2 - tengerészek, a vállalat teljes információs áramkörére jellemző.
Az ügyfélértesítő rendszer azonnal eltárolja a képfeldolgozás eredményét a felismert kliens azonosítójaként (ID) és típusaként: tengerész vagy kalóz.
Felismert objektumazonosító
Kliens kategória
100500
Kalóz
100501
Kalóz
100502
Tengerész
Jegyezzük meg még egyszer
1. A tengerészeink valójában borotvált emberek
2. Kalózaink valójában szakállas emberek
Milyen problémákat kell ebben az esetben kiküszöbölni, hogy struktúránk a harmadik normál formára törekedjen:
- attribútum atomossági megsértése – Ügyfélkategória
- az elemzett tény és a következtetés összekeverése egy táblázatban
- rögzített funkcionális kapcsolat a különböző entitások attribútumai között.
Normalizált formában két táblát kapunk:
- felismerési eredmény kialakult jellemzők halmaza formájában,
Felismert objektumazonosító
Arcszőrzet
100500
Igen
100501
Igen
100502
Nincs
- a kliens típus meghatározásának eredménye az IS-be ágyazott logika alkalmazása a megállapított jellemzők értelmezésére
Felismert objektumazonosító
Azonosító azonosító
Kliens kategória
100500
100001
Kalóz
100501
100002
Kalóz
100502
100003
Tengerész
Hogyan segítheti elő egy normalizált adattárolási szervezet egy IP komplexum kialakítását? Tegyük fel, hogy hirtelen új ügyfeleket szerez. Legyenek azok a japán kalózok, akiknek esetleg nincs szakálla, de papagájjal a vállukon járnak, és a környezetvédő kalózok, Greta bal mellkasán lévő kék profiljáról könnyen felismerhetőek.
A környezetvédelmi kalózok természetesen nem használhatnak csontfésűt, és újrahasznosított tengeri műanyagból készült analógot igényelnek.
Át kell dolgoznia a program algoritmusait az új bemeneteknek megfelelően. Ha betartanák a normalizálási szabályokat, akkor egyes rendszerekben csak egyes folyamatágak bemeneteit kellene kiegészíteni, és csak azokra az esetekre és IS-ekre kellene új ágakat létrehozni, ahol az arcszőrzet számít. De mivel a szabályokat nem tartották be, elemeznie kell a teljes kódot a teljes áramkörön keresztül, ahol a kliens típusú könyvtár értékeit használják, és egyértelműen meg kell állapítani, hogy egy esetben az algoritmusnak figyelembe kell vennie a szakmai a kliens aktivitásában és egyéb fizikai jellemzőiben.
Olyan formában, keresi A normalizáláshoz két táblát kapunk működési adatokkal és két könyvtárat:
- felismerési eredmény kialakult jellemzők halmaza formájában,
Felismert objektumazonosító
Greta a bal mellkason
Madár a vállán
Arcszőrzet
100510
1
1
1
100511
0
0
1
100512
1
0
- az ügyféltípus meghatározásának eredménye (legyen ez egy egyéni nézet, amelyben a könyvtárak leírásai jelennek meg)
Az észlelt denormalizáció azt jelenti, hogy a rendszereket nem lehet új feltételekhez igazítani? Természetesen nem. Ha úgy képzeljük el, hogy az összes információs rendszert egy csapat hozta létre nulla fluktuáció mellett, a fejlesztések jól dokumentáltak és a csapaton belül veszteség nélkül átadják az információkat, akkor a szükséges változtatások elhanyagolhatóan kis ráfordítással elvégezhetők. De ha visszatérünk a probléma eredeti feltételeihez, akkor 1,5 billentyűzet törlődik csak a közös megbeszélések protokolljainak kinyomtatásához és további 0,5 a beszerzési eljárások feldolgozásához.
A fenti példában mindhárom normálforma sérül, próbáljuk meg külön-külön megsérteni őket.
Az első normál forma megsértése:
Tegyük fel, hogy az árukat a beszállítók raktáraiból egy 1.5 tonnás gazellával, amely az Ön kocsmájához tartozik, átveszik a raktárba. Megrendeléseinek mérete a beszállítók forgalmához képest olyan kicsi, hogy azokat mindig egyenként teljesítik, anélkül, hogy megvárnák a gyártást. Egy ilyen üzleti folyamatnál szükség van-e külön táblázatokra: járművek, járműtípusok, szükséges-e elkülöníteni a tervet és a tényt a távozó beszállítóknak adott megrendeléseiben?
Képzeld csak el, hány „extra” kapcsolatot kell megírniuk a programozóidnak, ha az alábbi modellt használod egy program fejlesztéséhez.
Tegyük fel, hogy úgy döntöttünk, hogy a javasolt struktúra szükségtelenül bonyolult, esetünkben a terv és a tény elkülönítése a rendelési rekordban redundáns információ, és a generált rendelési specifikáció átírásra kerül a beérkezett áruk átvételének eredményei alapján, ritka hiba - a nem megfelelő minőségű áruk osztályozása és érkezése az IS-en kívül történik.
Aztán egy nap azt látod, hogy az egész kocsma terme tele van felháborodott és ápolatlan kalózokkal. Mi történt?
Kiderült, hogy ahogy nőtt a vállalkozásod, úgy nőtt a fogyasztásod is. Valamikor régen olyan vezetői döntés született, hogy ha egy gazellát térfogatban és/vagy tömegben túlterheltek, ami rendkívül ritka, akkor a szállító az italok javára helyezi előtérbe a rakományt.
A ki nem szállított áruk a következő rendelésbe kerültek és új járatra indultak, a kocsma raktárában a minimális egyenleg megléte lehetővé tette, hogy ne vegyék észre a hiányzó eseteket.
Az utolsó versenyző a kikötőben zárt, és általánossá vált a defektes gazella-túlterhelés, amelyet a jármű minimális egyenlegének és időszakos alulterhelésének feltételezése alapján történő elsőbbségadás megkerült. A létrehozott rendszer ideális esetben a benne beágyazott algoritmusok szerint fog működni, és megfosztja minden lehetőségétől, hogy nyomon kövesse a tervezett megrendelések teljesítésének szisztematikus meghiúsítását. Csak a sérült hírnév és az elégedetlen vásárlók tudják észlelni a problémát.
Egy figyelmes olvasó észrevehette, hogy a rendelési specifikációban (T_ORDER_SPEC) a 2. és az 5. pontban szereplő rendelt mennyiség megfelel, vagy nem felel meg az első normál forma követelményének. Minden attól függ, hogy a kiválasztott áruválaszték mellett lényegében különböző mértékegységek eshetnek-e ugyanabba a mezőbe.
A második normál forma megsértése:
Ahogy nőnek az igényei, vásárol még néhány különböző méretű járművet. A fenti összefüggésben a járműkatalógus létrehozását redundánsnak tekintettük, ennek következtében a kiszállítási és raktározási igényeket kiszolgáló összes adatfeldolgozó algoritmus a szállítótól a raktárba történő rakomány mozgását egy kizárólag 1,5 tonnás repülésként fogja fel. gazella. Tehát az új járművek vásárlásával együtt továbbra is létrehoz egy járműkönyvtárat, de annak véglegesítésekor elemeznie kell az összes kódot, amely a rakomány mozgására utal, hogy megtudja, az egyes helyeken utalnak-e a jellemzőkre. pont arról a járműről, amelyből az üzlet indult.
A harmadik normál forma megsértése:
Egy ponton elkezdi létrehozni a hűségprogramot, és megjelenik egy törzsvásárló rekordja. Miért kell például időt tölteni olyan anyagnézetek létrehozásával, amelyek aggregált adatokat tárolnak az egyes ügyfeleknek történő eladásokról jelentéskészítési és analitikai rendszerekbe történő átvitel céljából, ha egy hűségprogram indulásakor minden, ami a vevőt érdekli, elhelyezhető az ügyfél nyilvántartásában ? És valóban, első pillantásra semmi értelme. De valahányszor vállalkozása például új értékesítési csatornákat kapcsol össze, az elemzői között kell lennie valakinek, aki emlékezni fog arra, hogy létezik ilyen összesítési attribútum.
Minden új folyamat, például az internetes értékesítés, a közös hűségrendszerhez kapcsolódó forgalmazókon keresztül történő értékesítés megtervezésekor valakinek szem előtt kell tartania, hogy minden új folyamatnak biztosítania kell az adatok kódszintű integritását. Egy ezer táblás ipari adatbázis esetében ez lehetetlen feladatnak tűnik.
Egy tapasztalt fejlesztő természetesen tudja, hogyan lehet megállítani az összes fent említett problémát, de véleményem szerint egy tapasztalt elemző feladata nem az, hogy ezeket napvilágra hozza.
Szeretném kifejezni köszönetemet Jevgenyij Yarukhin vezető fejlesztőnek a kiadvány elkészítése során adott értékes visszajelzéseiért.
Irodalom
Connolly Thomas, Begg Caroline. Adatbázis. Tervezés, megvalósítás és támogatás. Elmélet és gyakorlat
Forrás: will.com