Helló! A nevem Andrej Szemenov, a Sportmaster vezető elemzője vagyok. Ebben a posztban a randi adatbázisok denormalizálásának kérdését szeretném felvetni. Áttekintjük az általános feltételeket, valamint egy konkrét példát - mondjuk, ez egy csodás, monopóliumot képező taverna lesz a kalózok és tengerészek számára. ahol a kalózokat és tengerészeket különböző módon kell kiszolgálni, mert a szép dolgokról való elképzeléseik és a fogyasztási szokásaik jelentősen eltérnek.
Hogyan tegyük, hogy mindenki elégedett legyen? Hogyan ne őrüljünk meg, miközben egy ilyen rendszert tervezünk és fenntartunk? Mi a teendő, ha a tavernába nemcsak a megszokott kalózok és tengerészek érkeznek?
Minden benne van a részletekben. De haladjunk lépésről lépésre.
1. Korlátozások és feltevések
Mindez kizárólag relációs adatbázisokra vonatkozik. Az interneten jól dokumentált, a denormalizálás következményeit, mint például a módosítási, törlési és beszúrási anomáliákat nem veszik figyelembe. Az írás keretein kívül maradnak azok az esetek, amikor a denormalizálás általános helyzetté válik, klasszikus példákkal: a sorozat- és sorszám, a dátum és az idő, és egyebek.
A posztban intuitív és gyakorlatban alkalmazható definíciókat használunk a normálformákra vonatkozóan, anélkül, hogy matematikai fogalmakra hivatkoznánk. Olyan módon, ahogyan ezek alkalmazhatók a valós üzleti folyamatok (BPs) vizsgálatára és ipari szoftverek tervezésére.
Egyes vélemények szerint az adattárházak, a jelentéskészítő eszközök és az integrációs megállapodások tervezése (amelyek táblázatos formában jelenítik meg az információt) eltér az ERP-rendszerek adatbázisainak tervezésétől, mivel a fogyasztás kényelme és a céltudatos denormalizálás érdekében való alkalmazás prioritást élvezhet az adatok integritásának védelme felett. Ezt a véleményt osztom, és az alább leírtak kizárólag az ERP-rendszerek mesteradat- és tranzakciós adatmódjaira vonatkoznak.
A normák magyarázata közérthető példán keresztül van bemutatva, amely a legtöbb olvasónak ismerős. Azonban a 4-5. pontokban tudatosan „kitalált” feladatot használtunk szemléltetésre. Ha ezt nem tesszük, és például egy klasszikus példát, mint az 2. pontban szereplő rendelés tárolási modell, veszünk, könnyen abba a helyzetbe kerülhetünk, hogy az olvasó figyelme a folyamat felbontásáról a személyes tapasztalataira és arra terelődik, hogy hogyan kellene felépíteni az információs rendszerek folyamatokat és adatmodelljeit. Más szavakkal, vegyük két szakképzett IT-elemzőt; az egyik logisztikai szolgáltatást nyújt utasszállítóknak, a másik pedig logisztikai feladatokat végez mikrochip gyártó gépek szállítói számára. Kérjük őket, hogy előzetes egyeztetés nélkül készítsenek adatmodellt a vasúti szállítmányozás információinak tárolására.
Van egy nem elhanyagolható esély arra, hogy a bemutatott modellekben nemcsak jelentősen eltérő attribútumhalmazokat, hanem eltérő entitásokat is találunk, mert minden elemző a megszokott folyamataira és feladataira fog támaszkodni. Ilyen helyzetben lehetetlen megmondani, hogy melyik modell a „helyes”, mert nincs értékelési kritérium.
2. Normál formák
Az első normálforma a DB számára megköveteli az összes attribútum atomizáltságát.
Például, ha A objektum nem kulcs attribútumai a és b, melyekre c=f(a,b) és az A objektumot leíró táblázatban a c attribútum értékét tárolják, akkor a DB megsérti az első normálformát. Például, ha a rendelés specifikációban a mennyiség olyan mértékegységektől függ, amelyek a termék típusától függenek: az egyik esetben darabok, a másikban liter, a harmadikban csomagok, amelyek darabokból állnak (a fenti modellben Good_count_WR), akkor az attribútumok atomizáltsága a DB-ben megsérül. Ebben az esetben ahhoz, hogy megmondjuk, milyen táblakészletre van szükség a rendelés specifikációhoz, szükséges a célzott munka folyamatának leírása az IS-ben, és mivel a folyamatok eltérőek lehetnek, ezért sok „helyes” változat is létezhet.
A második normálforma a DB számára megköveteli az első norma és a saját táblázat betartását minden egyes entitásra vonatkozóan, amely a rendszerinformatikai folyamatban részt vesz. Ha egy táblázatban vannak függőségek, mint például f1(a) és d=f2(b), és nincs függőség f3(b), akkor a táblázat megsérti a második normát. A fent említett példában a "Megrendelés" táblázatban nincs függőség a megrendelés és a cím között. Ha módosítja az utca nevét vagy a várost, az nem befolyásolja a megrendelés lényeges attribútumait.
A harmadik norma a DB-ben megköveteli a második norma betartását és a funkcionális függőségek hiányát különböző entitások attribútumai között. Ezt a szabályt úgy fogalmazhatjuk meg, hogy "minden, ami kiszámítható, az legyen kiszámítva". Más szóval, ha van két objektum, A és B. Az A objektumot tároló táblázatban megjelenik a C attribútum, míg a B objektum rendelkezik egy b attribútummal, amelynek létezik egy c=f4(b) kifejezése, akkor a harmadik normát megsértettük. Az alábbi példában a "Darabszám" (Total_count_WR) attribútum a megrendelésben nyilvánvalóan magában foglalja a harmadik norma megsértését.
3. Az én megközelítésem a normalizálás alkalmazásához
1. Csak a célzott automatizálható üzleti folyamatok adhatják meg az elemzők számára azokat a kritériumokat, amelyek alapján az entitások és attribútumok az adattárolási modell létrehozásakor azonosíthatók. A folyamatmodell létrehozása kötelező feltétel a normál adatmodell létrehozásához.
2. A harmadik norma elérése szigorú értelemben gyakorlati szempontból nem mindig célravezető az ERP rendszerek létrehozásakor, ha a következő valamennyi feltétel teljesül:
- az automatizálható folyamatok ritkán változnak,
- a kutatásra és fejlesztésre fordított idő korlátozott,
- az adatintegritásra vonatkozó követelmények viszonylag alacsonyak (a potenciális hibák az ipari szoftverekben nem vezetnek a szoftvermegrendelők pénz- vagy ügyfélvesztéséhez)
- és így tovább.
A fent említett körülmények között a bizonyos objektumok és attribútumaik életciklusának azonosítására és leírására fordított költségek gazdasági hatékonysága szempontjából lehet, hogy nem indokoltak.
3. Bármilyen adatmodell denormalizálásának következményei egy már létrehozott rendszerben gondos, előzetes kódvizsgálattal és teszteléssel elkerülhetők.
4. A denormalizálás módszer a munkaerő terheinek áthelyezése az adatok forrásának kutatási és az üzleti folyamatok tervezési szakaszából a fejlesztési szakaszra, a bevezetési időszakból a rendszer fejlesztési időszakába.
5. A harmadik normál forma elérése akkor indokolt, ha:
- Az automatizálható üzleti folyamatok változása nehezen előrejelezhető.
- A bevezetési és/vagy fejlesztési csapaton belül gyenge átjárás van a munkamegosztásban.
- Az integrációs körbe tartozó rendszerek saját terveik szerint fejlődnek.
- Az adatok összehangolatlansága ügyfél- vagy pénzveszteséghez vezethet a cég számára.
6. Az adatmodell kialakítását az elemzőnek csak a célzott üzleti folyamatok és az informatikai rendszer folyamataihoz kapcsolódóan szabad végeznie. Ha az adatmodell kidolgozását a fejlesztő végzi, akkor a témakörbe olyan mértékben kell belemerülnie, hogy különösen megértse az attribútumok értékeinek eltérését – ami elengedhetetlen az atomikus attribútumok kiemeléséhez. Így magára vállalja a nem jellemző funkciókat.
4. Feladat illusztrációra
Tegyük fel, hogy van egy kis robotizált kocsma a kikötőben. A piaci szegmense: tengerészek és kalózok, akik beérkeznek a kikötőbe és pihenésre vágynak. A tengerészeknek tárnivalót kínál, míg a kalózoknak rumot és csontfésűt a szakálluk fésüléséhez. A kocsmában a szervizt egy robot-hostess és egy robot-bárpultos biztosítja. A magas minőségnek és alacsony áraknak köszönhetően kiütötte a versenytársakat, így minden hajórólpartra lépő vendég az Ön kocsmájába érkezik, amely a kikötő egyetlen kocsmája.
A kocsma információs rendszere az alábbi szoftverekből áll:
- Korai figyelmeztető rendszer, amely felismeri az ügyfél kategóriáját jellemző tulajdonságok alapján.
- Robot-hostess és robot-bárpultos irányító rendszer.
- Raktározási és értékesítési ponti szállítási rendszer.
- Szállítói kapcsolatok kezelési rendszere (SRM).
Folyamat:
A korai figyelmeztető rendszer az aljáról leszálló embereket észlel. Ha a személy simára borotvált, tengerészként azonosítja, ha szakállt talál, akkor kalózként határozza meg.
Belépve a kocsmába, a vendég a robot-hostesstől köszöntést hall a kategóriája szerint, például: „Ho-ho-ho, kedves kalóz, kérjük, foglaljon helyet a... számú asztalnál.”
A vendég a megadott asztalhoz lép, ahol a robotpincér már elkészítette számára a termékeket a kategória szerint. A robotpincér információt küld a raktári rendszerbe arról, hogy a következő szállítmányt növelni kell, a raktári információs rendszer pedig a készletek alapján beszerzési igényt alakít ki a Raktári Operatív Rendszerhez.
Legyen a korai figyelmeztető rendszert a belső IT csapat készítette, a robotpincér-irányító programot egy külső szállító fejlesztette kifejezetten az ön üzletéhez. Az ellátási lánc és a beszállítókkal való kapcsolattartás menedzsment rendszerei pedig testreszabott dobozos megoldások a piacon.
5. A denormalizálás példái és hatásai a szoftverfejlesztésre
Az üzleti folyamat megtervezésekor a megkérdezett szakértők egyhangúlag kijelentették, hogy világszerte a kalózok rummal itatják magukat és csontfésűkkel fésülik a szakállukat, míg a tengerészek kakukkfűs teát isznak és mindig simára borotválkoznak.
Megjelenik a kliens típusok szótára két értékkel: 1- kalóz, 2 - tengerész, amely közös az egész vállalat információs rendszerén.
A kliensről szóló értesítési rendszer azonnal elmenti a képfeldolgozás eredményét, mint az azonosított kliens azonosítóját (ID) és annak típusát: tengerész vagy kalóz.
Az Azonosított objektum ID-je
Kliens kategória
100500
Kalóz
100501
Kalóz
100502
Tengerész
Még egyszer felhívjuk a figyelmet arra, hogy
1. A mi tengerészeink valójában borotvált emberek
2. A mi kalózaink valójában szakállas emberek
Milyen problémákat kell ebben az esetben megoldani, hogy struktúránk a harmadik normálformához törekedjen:
- az attribútum atomaritásának megsértése - Kliens kategória
- az elemzett tény és a következtetés keveredése egy táblázatban
- a különböző entitások attribútumai közötti rögzített funkcionális függőség.
Normalizált formában két táblázatot kapnánk:
- a felismert eredmény egy sor rögzített jellemzőként,
Az Azonosított objektum ID-je
Az arcszőrzet
100500
Igen
100501
Igen
100502
Nem
- a kliens típusának megállapítása, mint az információs rendszerbe beépített logika alkalmazása az rögzített jellemzők értelmezésére
Az azonosított objektum ID-je
Az azonosítás ID-je
Kliens kategória
100500
100001
Kalóz
100501
100002
Kalóz
100502
100003
Tengerész
Hogyan könnyíti meg az adatok strukturált tárolása az informatikai rendszerek fejlesztését? Tegyük fel, hogy hirtelen új ügyfelek érkeznek. Legyenek ők japán kalózok, akiknek lehet, hogy nincs szakálluk, de egy papagájjal járnak a vállukon, és ökológiai kalózok, akiket könnyen felismerhetsz a bal mellkasukon lévő Greta kék profiljáról.
Az ökológiai kalózok természetesen nem használhatnak csontfésűt, és egy újrahasznosított tengeri műanyag alternatívát követelnek.
Újra kell dolgoznod a programok működési algoritmusait az új bevezetett szabályoknak megfelelően. Ha a normalizálás szabályait betartották volna, akkor csak egyes rendszerekhez kellett volna kiegészítened a belépéseket néhány folyamatág számára és új ágakat létrehoznod csak azokban az esetekben és azokon a rendszereken, ahol fontos a szakáll borítása. De mivel a szabályokat nem tartották be, az egész kódot át kell elemezned, az összes ponton, ahol az ügyféltípusok értékeivel dolgoznak, és egyértelműen meg kell határoznod, hogy egy esetben az algoritmusnak figyelembe kell vennie az ügyfél szakmai tevékenységét, míg a másik esetben a fizikai sajátosságait.
A formájában, amely célra irányulóan, két táblázatot kapnánk műveleti adatokkal, valamint két adattárat:
- a felismert eredmény egy sor rögzített jellemzőként,
Az azonosított objektum ID-je
Greta a bal mellkason
Madár a vállon
Az 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 felhasználói megjelenítés, amelyben a könyvtárak leírásai jelennek meg)
Jelent-e a felfedezett deznormalizációt, hogy a rendszereket nem lehet új körülményekhez igazítani? Természetesen nem. Ha feltételezzük, hogy minden informatikai rendszert egy csapat alkotott, minimális fluktuációval, a fejlesztések jól dokumentáltak, és a csapaton belüli információátadás zökkenőmentes, akkor a szükséges változtatások elvégzéséhez elhanyagolható erőfeszítések szükségesek. De ha visszatérünk a feladat kiindulási feltételeihez, már csak a közös megbeszélések protokolljainak kinyomtatásához 1,5 billentyűzetet használunk el, és még 0,5-t az előkészítési folyamatok lebonyolítására.
A fent említett példában mindhárom normálforma megszegésre került, próbáljuk meg őket külön-külön megszegni.
Az első normálforma megszegése:
Tegyük fel, hogy a termékek a raktárába a beszállítók raktáraiból érkeznek, önálló szállítással, egy 1,5 tonnás furgon használatával, amely a kocsmájáé. A rendelései olyan kicsik a beszállítók forgalmához képest, hogy mindig pontosan teljesítik őket, anélkül, hogy várakozni kellene a gyártásra. Szükséges-e ilyen BP esetén külön táblák létrehozása: járművek, járműtípusok, szükséges-e különválasztani a tervezett és a tényleges adatokat a beszállítóknak küldött rendelésein?
Csak képzelje el, mennyi „felesleges” kapcsolatot kellene létrehoznia a programozóinak, ha az alábbi modellt használná a program fejlesztéséhez.
Tegyük fel, hogy úgy döntöttünk, hogy a javasolt struktúra túl bonyolult, az általunk nevezet rendelések esetén a tervek és a tények szétválasztása felesleges információ, és a rendelés specifikációt a beérkező áruk átvétele után frissítjük, a ritka tévesztések és a nem megfelelő minőségű termékek kezelése a rendszeren kívül történik.
És egy nap azt tapasztalja, hogy a kocsma teljes terme tele van felháborodott és borostás kalózokkal. Mi történt?
Kiderült, hogy a vállalkozása növekedésével együtt nőtt a fogyasztás is. Valaha úgy döntöttek, hogy ha a furgon túltöltöttség miatt a térfogatot és/vagy a súlyt eléri, ami nagyon ritkán fordult elő, a beszállító az italok terhelésének prioritását választja.
A hiányzó termék a következő rendelésbe került, és egy új útra indult, a kocsmában meglévő minimális készlet pedig lehetővé tette, hogy figyelmen kívül hagyják a gödrös eseteket.
A kikötőben bezárta az utolsó versenytársa, és a túltöltött furgon esete, amelyet a minimális készlet elegendőségéneken és az eszkünk időszakos alacsonyabb terheltsége alapján történő prioritizálással megkerültek, a szokásos gyakorlattá vált. Az elkészített rendszer tökéletesen végrehajtja a benne beprogramozott algoritmusokat, és minden lehetőséget kizár az előírásos rendelések rendszeres végrehajtásának nyomon követésére. Csak a megsérült hírnév és a csalódott ügyfelek képesek felfedni a problémát.
A figyelmes olvasó biztosan észrevette, hogy a rendelés specifikációjában (T_ORDER_SPEC) a 2. és 5. részben megadott mennyiség megfelelhet, vagy nem felelhet meg az első normál formának. Ez attól függ, hogy a kiválasztott termékek assortimentjánál különböző alapmértékegységek kerülnek-e egy mezőbe.
A második normál forma megsértése:
Ahogy nőnek az igényei, vásárol még pár különböző méretű szállítóeszközt. A fent ismertetett kontextusban a közlekedési eszközök nyilvántartásának létrehozása túlzottan bonyolultnak bizonyult, ezért minden olyan adatkezelési algoritmus, amely a szállítási és raktári igények kiszolgálására szolgál, úgy érzékeli a teherszállítást a beszállítótól a raktárba, mint egy kizárólag 1,5 tonnás furgon járatát. Így a új szállítóeszközök vásárlásával mégis létrehozza a szállítóeszközök nyilvántartását, de a módosítás során elemeznie kell az összes kódot, amely a teheráthelyezésre vonatkozik, hogy kiderítse, minden egyes helyen jelent-e a bizonyos jármű tulajdonságaira hivatkozást, amellyel a vállalkozás indult.
A harmadik normál forma megsértése:
Valamikor elkezdi létrehozni a hűségprogramját, megjelenik egy állandó ügyfél nyilvántartása. Miért, például, pazarolja az időt olyan anyagi reprezentációk létrehozására, amelyek aggregált adatokat tárolnak az egyes ügyfelek eladásaival kapcsolatban jelentések és analitikai rendszerek átadása számára, amikor a hűségprogram kezdeti szakaszában minden, amit az ügyfél tudni szeretne, közvetlenül az ügyfél nyilvántartásában is elhelyezheti? Valójában első ránézésre nincs értelme. De valahányszor a vállalkozása új értékesítési csatornákat kapcsol be, az elemzői között lennie kell valakinek, aki emlékezik arra, hogy létezik egy ilyen aggregációs attribútum.
Minden új folyamat tervezésekor, például online értékesítés, a közös hűségprogramhoz csatlakozó forgalmazók értékesítésekor valakinek észben kell tartania, hogy minden új folyamatnak biztosítania kell az adatok integritását a kód szintjén. Ezer táblázattal rendelkező ipari adatbázis esetén ez megvalósíthatatlannak tűnik.
A tapasztalt fejlesztő természetesen tudja, hogyan lehet megoldani az említett problémákat, de véleményem szerint egy tapasztalt elemző feladata, hogy elkerülje azok kialakulását.
Szeretném kifejezni hálámat a hasznos visszajelzésért a publikáció előkészítése során a vezető fejlesztő, Evgeny Yaruhin részéről.
Irodalom
Connolly Thomas, Begg Caroline. Adatbázisok. Tervezés, megvalósítás és karbantartás. Elmélet és gyakorlat.
Forrás: habr.com
