Zdravo! Moje ime je Andrej Semenov, viši sam analitičar u Sportmasteru. U ovom postu želim pokrenuti pitanje denormalizacije baza podataka ERP sustava. Pogledat ćemo opće uvjete, kao i konkretan primjer - recimo da bi to bila prekrasna monopoly konoba za gusare i mornare. U kojoj se gusari i mornari moraju drugačije služiti, jer su predodžbe o ljepoti i potrošački obrasci ove dobre gospode bitno drugačiji.
Kako učiniti sve sretnima? Kako možete izbjeći da poludite projektirajući i održavajući takav sustav? Što učiniti ako u konobu ne počnu dolaziti samo uobičajeni gusari i mornari?
Sve je pod rezom. Ali krenimo redom.
1. Ograničenja i pretpostavke
Sve navedeno vrijedi samo za relacijske baze podataka. Posljedice denormalizacije u obliku anomalija modifikacije, brisanja i umetanja, koje su dobro pokrivene, uključujući i na Internetu, nisu razmatrane. Izvan opsega ove publikacije postoje slučajevi gdje je denormalizacija uobičajeno mjesto, s klasičnim primjerima: serija i broj putovnice, datum i vrijeme itd.
Post koristi intuitivne i praktično primjenjive definicije normalnih oblika, bez pozivanja na matematičke pojmove. U obliku u kojem se mogu primijeniti na ispitivanje realnih poslovnih procesa (BP) i dizajn industrijskog softvera.
Tvrdi se da se dizajn skladišta podataka, alata za izvješćivanje i integracijskih sporazuma (koji koriste tablične prikaze informacija) razlikuje od dizajna baza podataka ERP sustava po tome što jednostavnost upotrebe i upotreba svjesne denormalizacije da bi se to postiglo može imati prednost nad integritetom. podaci o zaštiti. Dijelim ovo mišljenje, a dolje opisano odnosi se isključivo na modele matičnih podataka i transakcijskih podataka ERP sustava.
Objašnjenje normalnih oblika dano je na primjeru koji je većini čitatelja razumljiv na svakodnevnoj razini. Međutim, kao vizualna ilustracija, u paragrafima 4-5, namjerno je korišten "izmišljen" zadatak. Ako to ne učinite i uzmete neki udžbenički primjer, na primjer, isti model pohranjivanja naloga iz točke 2, možete se naći u situaciji da će fokus čitatelja biti pomaknut s predložene dekompozicije procesa na model, tj. osobnom iskustvu i percepciji kako se moraju graditi procesi i modeli za pohranu podataka u IS. Drugim riječima, uzmite dva kvalificirana IT analitičara, jedan neka pruža usluge logističarima koji prevoze putnike, drugi logističarima koji transportiraju strojeve za proizvodnju mikročipova. Zamolite ih, bez prethodnog raspravljanja o automatiziranim BP-ovima, da naprave podatkovni model za pohranu informacija o putovanju željeznicom.
Postoji vjerojatnost različita od nule da ćete u predloženim modelima pronaći ne samo primjetno različit skup atributa, već i divergentne skupove entiteta, jer će se svaki analitičar oslanjati na njemu poznate procese i zadatke. I u takvoj situaciji nemoguće je reći koji je model “ispravan”, jer nema kriterija vrednovanja.
2. Normalni oblici
Prvi normalni oblik baze podataka zahtijeva atomičnost svih atributa.
Konkretno, ako objekt A ima ne-ključne atribute a i b, tako da je c=f(a,b) i u tablici koja opisuje objekt A pohranjujete vrijednost atributa c, tada je prvi normalni oblik narušen u bazi podataka . Na primjer, ako je u narudžbenici navedena količina, čije mjerne jedinice ovise o vrsti proizvoda: u jednom slučaju to mogu biti komadi, u drugom litre, u trećem paketi koji se sastoje od komada (u gornjem modelu Good_count_WR) , tada je atomičnost atributa narušena u bazi podataka. U ovom slučaju, da biste rekli kakav bi trebao biti klaster tablice specifikacije narudžbe, potreban vam je ciljani opis procesa rada u IS-u, a kako procesi mogu biti različiti, može biti mnogo „ispravnih“ verzija.
Drugi normalni oblik baze podataka zahtijeva usklađenost s prvim obrascem i vlastitom tablicom za svaki entitet vezan uz proces rada u IS-u. Ako u jednoj tablici postoje ovisnosti c=f1(a) i d=f2(b), a ne postoji ovisnost c=f3(b), tada je u tablici narušena druga normalna forma. U gornjem primjeru ne postoji ovisnost između narudžbe i adrese u tablici Narudžba. Promijenite naziv ulice ili grada i nećete imati utjecaja na bitne atribute naloga.
Treća baza podataka normalnog oblika zahtijeva usklađenost s drugom normalnom formom i odsutnost funkcionalnih ovisnosti između atributa različitih entiteta. Ovo pravilo se može formulirati na sljedeći način: "sve što se može izračunati mora se izračunati." Drugim riječima, ako postoje dva objekta A i B. U tablici koja pohranjuje atribute objekta A manifestira se atribut C, a objekt B ima atribut b, tako da c=f4(b) postoji, tada treći normalni oblik se krši. U donjem primjeru, atribut Količina komada (Total_count_WR) u zapisu narudžbe jasno tvrdi da krši treći normalni oblik
3. Moj pristup primjeni normalizacije
1. Samo ciljani automatizirani poslovni proces može analitičaru pružiti kriterije za identifikaciju entiteta i atributa pri izradi modela pohrane podataka. Stvaranje modela procesa je preduvjet za stvaranje normalnog modela podataka.
2. Postizanje trećeg normalnog oblika u strogom smislu možda neće biti praktično u stvarnoj praksi stvaranja ERP sustava ako su ispunjeni neki ili svi sljedeći uvjeti:
- automatizirani procesi rijetko su podložni promjenama,
- rokovi za istraživanje i razvoj su kratki,
- zahtjevi za integritetom podataka relativno su niski (potencijalne pogreške u industrijskom softveru ne dovode do gubitka novca ili klijenata od strane kupca softvera)
- itd.
Pod opisanim uvjetima, troškovi identifikacije i opisa životnog ciklusa nekih objekata i njihovih atributa možda neće biti opravdani sa stajališta ekonomske učinkovitosti.
3. Eventualne posljedice denormalizacije podatkovnog modela u već kreiranom IS-u mogu se ublažiti temeljitim preliminarnim proučavanjem koda i testiranjem.
4. Denormalizacija je način prijenosa troškova rada iz faze istraživanja izvora podataka i projektiranja poslovnog procesa u fazu razvoja, iz razdoblja implementacije u razdoblje razvoja sustava.
5. Preporučljivo je težiti trećem normalnom obliku baze podataka ako:
- Smjer promjena u automatiziranim poslovnim procesima teško je predvidjeti
- Postoji slaba podjela rada unutar implementacijskog i/ili razvojnog tima
- Sustavi uključeni u integracijski krug razvijaju se prema vlastitim planovima
- Nedosljednost podataka može rezultirati time da tvrtka izgubi klijente ili novac
6. Dizajn podatkovnog modela treba provoditi analitičar samo u vezi s modelima ciljnog poslovnog procesa i procesa u IS-u. Ako programer dizajnira podatkovni model, morat će se uroniti u predmetno područje do te mjere da, posebice, razumije razliku između vrijednosti atributa - nužan uvjet za izolaciju atomskih atributa. Dakle, preuzimajući neobične funkcije.
4 Problem za ilustraciju
Recimo da imate malu robotsku konobu u luci. Vaš segment tržišta: mornari i gusari koji dolaze u luku i trebaju odmor. Mornarima prodaješ čaj s majčinom dušicom, a piratima rum i koštane češljeve za češljanje brade. Uslugu u samoj konobi obavljaju robot hostesa i robot barmen. Zahvaljujući visokoj kvaliteti i niskim cijenama, potjerali ste konkurenciju, tako da svi koji izlaze s broda dolaze u vašu konobu, koja je jedina u luci.
Kompleks informacijskih sustava konobe sastoji se od sljedećeg softvera:
- Sustav ranog upozorenja o klijentu koji prepoznaje njegovu kategoriju na temelju karakterističnih karakteristika
- Kontrolni sustav za robote hostese i robote barmene
- Sustav upravljanja skladištem i dostavom do prodajnog mjesta
- Sustav upravljanja odnosima s dobavljačima (SURP)
proces:
Sustav ranog upozorenja prepoznaje ljude koji napuštaju brod. Ako je osoba glatko obrijana, identificira je kao mornara; ako se nađe da osoba ima bradu, identificira se kao gusar.
Ulazeći u konobu, gost čuje pozdrav robota domaćice u skladu s njegovom kategorijom, na primjer: “Ho-ho-ho, dragi gusare, idi do stola br...”
Gost odlazi do navedenog stola, gdje je robot barmen već pripremio robu za njega u skladu s kategorijom. Robot barmen šalje informaciju skladišnom sustavu da treba povećati sljedeći dio isporuke, skladišni IS na temelju preostalih stanja u skladištu generira zahtjev za kupnju u sustavu upravljanja.
Dok je sustav ranog upozoravanja možda razvio vaš interni IT, program za upravljanje barskim robotom možda je izradio vanjski izvođač posebno za vaše poslovanje. A sustavi za upravljanje skladištima i odnosima s dobavljačima prilagođena su pakirana rješenja s tržišta.
5. Primjeri denormalizacije i njezin utjecaj na razvoj softvera
Pri osmišljavanju poslovnog procesa ispitani stručnjaci jednoglasno su ustvrdili da pirati diljem svijeta piju rum i češljaju brade češljevima od kosti, a mornari piju čaj s majčinom dušicom i uvijek su obrijani.
Pojavljuje se imenik tipova klijenata s dvije vrijednosti: 1 - pirati, 2 - mornari, zajedničke za cijeli informacijski krug tvrtke.
Sustav obavijesti klijenta odmah pohranjuje rezultat obrade slike kao identifikator (ID) prepoznatog klijenta i njegovu vrstu: mornar ili gusar.
ID prepoznatog objekta
Kategorija klijenta
100500
Pirat
100501
Pirat
100502
Mornar
Napomenimo još jednom da
1. Naši mornari su zapravo obrijani ljudi
2. Naši pirati su zapravo bradati ljudi
Koje probleme u ovom slučaju treba eliminirati kako bi naša struktura težila trećem normalnom obliku:
- kršenje atomičnosti atributa - Kategorija klijenta
- miješanje analizirane činjenice i zaključka u jednoj tablici
- fiksni funkcionalni odnos između atributa različitih entiteta.
U normaliziranom obliku dobili bismo dvije tablice:
- rezultat prepoznavanja u obliku skupa utvrđenih obilježja,
ID prepoznatog objekta
Dlake na licu
100500
Da
100501
Da
100502
Ne
- rezultat određivanja tipa klijenta kao primjene logike ugrađene u IS za tumačenje utvrđenih karakteristika
ID prepoznatog objekta
Identifikacijski ID
Kategorija klijenta
100500
100001
Pirat
100501
100002
Pirat
100502
100003
Mornar
Kako normalizirana organizacija pohrane podataka može olakšati razvoj IP kompleksa? Recimo da iznenada dobijete nove klijente. Neka su to japanski gusari koji možda nemaju bradu, ali hodaju s papigom na ramenu, a pirati ekolozi, lako ih prepoznajete po Gretinom plavom profilu na prsima s lijeve strane.
Ekološki pirati, naravno, ne mogu koristiti koštane češljeve i zahtijevaju analog od reciklirane morske plastike.
Morate preraditi algoritme programa u skladu s novim ulazima. Ako su se pravila normalizacije slijedila, tada biste samo morali dopuniti ulaze za neke grane procesa u nekim sustavima i stvoriti nove grane samo za one slučajeve i u onim IS-ovima gdje su dlake na licu bitne. Ali, budući da se pravila nisu poštovala, morat ćete analizirati cijeli kod, kroz cijeli krug, gdje se koriste vrijednosti imenika tipa klijenta i jasno utvrditi da u jednom slučaju algoritam treba uzeti u obzir profesionalne aktivnosti klijenta, te u drugim fizičkim značajkama.
U obliku koji traži da se normalizira, dobili bismo dvije tablice s operativnim podacima i dva direktorija:
- rezultat prepoznavanja u obliku skupa utvrđenih obilježja,
ID prepoznatog objekta
Greta na lijevim prsima
Ptica na ramenu
Dlake na licu
100510
1
1
1
100511
0
0
1
100512
1
0
- rezultat određivanja tipa klijenta (neka to bude prilagođeni prikaz u kojem se prikazuju opisi iz imenika)
Znači li otkrivena denormalizacija da se sustavi ne mogu modificirati kako bi zadovoljili nove uvjete? Naravno da ne. Ako zamislimo da je sve informacijske sustave kreirao jedan tim bez fluktuacije osoblja, da su razvoji dobro dokumentirani i da se informacije unutar tima prenose bez gubitaka, tada se potrebne promjene mogu napraviti uz zanemarivo malo truda. Ali ako se vratimo na izvorne uvjete problema, obrisati će se 1,5 tipkovnica samo za ispis protokola zajedničkih razgovora i još 0,5 za obradu postupaka nabave.
U gornjem primjeru sva tri normalna oblika su prekršena, pokušajmo ih prekršiti zasebno.
Kršenje prvog normalnog oblika:
Recimo da se roba isporučuje u vaše skladište iz skladišta dobavljača preuzimanjem pomoću jedne gazele od 1.5 tone koja pripada vašoj konobi. Veličina vaših narudžbi toliko je mala u odnosu na promet dobavljača da se uvijek izvršavaju jedna na jedna bez čekanja na proizvodnju. Trebate li kod ovakvog poslovnog procesa odvojene tablice: vozila, vrste vozila, je li potrebno odvojiti plan i faktičko stanje u narudžbama prema dobavljačima koji su otišli?
Zamislite samo koliko će "dodatnih" veza vaši programeri morati napisati ako koristite model u nastavku za razvoj programa.
Recimo da smo odlučili da je predložena struktura nepotrebno složena; u našem slučaju, odvajanje plana i činjenica u zapisu narudžbe je suvišna informacija, a generirana specifikacija narudžbe prepisuje se na temelju rezultata preuzimanja pristigle robe, rijetkih grešaka. -klasiranje i dolazak robe neodgovarajuće kvalitete rješava se izvan IS-a.
A onda jednog dana vidite kako je cijela sala krčme puna ogorčenih i neurednih gusara. Što se dogodilo?
Ispada da kako je rastao vaš posao, rasla je i vaša potrošnja. Jednom davno donesena je odluka menadžmenta da u slučaju preopterećenja gazele volumenom i/ili težinom, što je bilo iznimno rijetko, dobavljač daje prednost tovaru u korist pića.
Neisporučena roba završila je u sljedećoj narudžbi i otišla na novi let; prisutnost minimalnog stanja u skladištu u konobi omogućila je da se ne primijete nestale kutije.
Posljednji natjecatelj zatvorio se u luci, a probušeni slučaj preopterećenja gazele, zaobiđen prioritizacijom temeljenom na pretpostavci dostatnosti minimalne bilance i periodičnog podopterećenja vozila, postao je uobičajena praksa. Stvoreni sustav idealno će raditi u skladu s algoritmima ugrađenim u njega i bit će lišen svake mogućnosti praćenja sustavnog neispunjavanja planiranih naloga. Samo narušeni ugled i nezadovoljni kupci moći će otkriti problem.
Pažljivi čitatelj možda je primijetio da naručena količina u specifikaciji narudžbe (T_ORDER_SPEC) u odjeljku 2 i odjeljku 5 može, ali i ne mora zadovoljiti zahtjev prvog normalnog oblika. Sve ovisi o tome mogu li, s obzirom na odabrani asortiman robe, u isto područje spadati bitno različite mjerne jedinice.
Kršenje drugog normalnog oblika:
Kako vaše potrebe rastu, kupujete još nekoliko vozila različitih veličina. U navedenom kontekstu, stvaranje imenika vozila smatralo se suvišnim, kao rezultat toga, svi algoritmi za obradu podataka koji služe potrebama dostave i skladišta percipiraju kretanje tereta od dobavljača do skladišta kao let isključivo 1,5 tone težine gazela. Dakle, uz kupnju novih vozila, i dalje kreirate imenik vozila, ali kada ga finalizirate, morat ćete analizirati sav kod koji referencira kretanje tereta kako biste saznali da li se na svakom konkretnom mjestu reference impliciraju na karakteristike samog vozila iz kojeg je posao krenuo.
Kršenje trećeg normalnog oblika:
U nekom trenutku počnete kreirati program vjernosti, pojavi se evidencija stalnog kupca. Zašto, primjerice, trošiti vrijeme na izradu materijalnih prikaza koji pohranjuju agregirane podatke o prodaji pojedinom klijentu za korištenje u izvješćivanju i prijenosu u analitičke sustave, ako se na početku programa vjernosti sve što zanima kupca može staviti u evidenciju klijenta ? I, doista, na prvi pogled nema svrhe. Ali svaki put kada vaša tvrtka poveže, na primjer, nove prodajne kanale, trebao bi postojati netko među vašim analitičarima tko će se sjetiti da takav atribut agregacije postoji.
Prilikom osmišljavanja svakog novog procesa, primjerice prodaje na Internetu, prodaje preko distributera povezanih u zajednički sustav lojalnosti, netko mora imati na umu da svi novi procesi moraju osigurati integritet podataka na razini koda. Za industrijsku bazu podataka s tisuću tablica to se čini nemogućim zadatkom.
Iskusni programer, naravno, zna kako zaustaviti sve gore navedene probleme, ali, po mom mišljenju, zadatak iskusnog analitičara nije iznijeti ih na vidjelo.
Želio bih izraziti svoju zahvalnost vodećem programeru Evgeniyu Yarukhinu na njegovim vrijednim povratnim informacijama tijekom pripreme publikacije.
Književnost
Connolly Thomas, Begg Caroline. Baza podataka. Dizajn, implementacija i podrška. Teorija i praksa
Izvor: www.habr.com