Zdravo! Moje ime je Andrej Semenov, viši sam analitičar u Sportmasteru. U ovom postu želim da pokrenem pitanje denormalizacije baza podataka ERP sistema. Pogledaćemo opšte uslove, kao i konkretan primer – recimo da bi to bila divna monopol kafana za pirate i mornare. U kojoj se pirati i pomorci moraju drugačije služiti, jer se ideje ljepote i potrošački obrasci ovih dobrih džentlmena bitno razlikuju.
Kako učiniti sve srećnim? Kako možete izbjeći da poludite dizajnirajući i održavajući takav sistem? Što učiniti ako u tavernu ne počnu dolaziti samo uobičajeni pirati i mornari?
Sve je ispod reza. Ali idemo redom.
1. Ograničenja i pretpostavke
Sve gore 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 obima ove publikacije postoje slučajevi gdje je denormalizacija uobičajeno mjesto, uz klasične primjere: serija i broj pasoša, datum i vrijeme itd.
Post koristi intuitivne i praktično primjenjive definicije normalnih oblika, bez pozivanja na matematičke termine. 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štavanje i integracijskih sporazuma (koji koriste tabelarne prikaze informacija) razlikuje od dizajna baza podataka ERP sistema po tome što jednostavnost potrošnje i korištenje svjesne denormalizacije za postizanje toga može imati prednost nad integritetom. podaci o zaštiti. Dijelim ovo mišljenje, a ono što je opisano u nastavku odnosi se isključivo na modele matičnih podataka i transakcijskih podataka ERP sistema.
Objašnjenje normalnih oblika dato je na primjeru koji je razumljiv na svakodnevnom nivou većini čitalaca. Međutim, kao vizuelna ilustracija, u paragrafima 4-5, namerno je upotrebljen „fiktivni“ zadatak. Ako to ne učinite i uzmete neki primjer iz udžbenika, na primjer, isti model skladištenja narudžbi iz tačke 2, možete se naći u situaciji u kojoj će se fokus čitaoca pomjeriti sa predložene dekompozicije procesa na model, na lično iskustvo i percepciju kako procesi i modeli za pohranjivanje podataka u IS moraju biti izgrađeni. Drugim riječima, uzmite dva kvalifikovana IT analitičara, neka jedan pruža usluge logističarima koji prevoze putnike, drugi logističarima koji prevoze mašine za proizvodnju mikročipova. Zamolite ih da kreiraju model podataka za pohranjivanje informacija o putovanju željeznicom, bez prethodnog razmatranja automatiziranih BP-a.
Postoji vjerovatnoća različita od nule da ćete u predloženim modelima pronaći ne samo primjetno drugačiji skup atributa, već i divergentne skupove entiteta, jer će se svaki analitičar oslanjati na procese i zadatke koji su mu poznati. A u takvoj situaciji nemoguće je reći koji je model „ispravan“, jer ne postoji kriterij vrednovanja.
2. Normalni oblici
Prvi normalni oblik baze podataka zahtijeva atomičnost svih atributa.
Konkretno, ako objekat A ima ne-ključne atribute a i b, tako da je c=f(a,b) i u tabeli koja opisuje objekat A pohranjujete vrijednost atributa c, tada je prvi normalni oblik narušen u bazi podataka . Na primjer, ako je u specifikaciji narudžbe navedena količina, čije mjerne jedinice ovise o vrsti proizvoda: u jednom slučaju to mogu biti komadi, u drugom litre, u trećem pakovanja koja se sastoje od komada (u modelu iznad 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 postojati mnogo „ispravnih“ verzija.
Drugi normalni oblik baze podataka zahtijeva poštivanje prvog obrasca i vlastite tabele za svaki entitet koji se odnosi na proces rada u IS-u. Ako u jednoj tabeli postoje zavisnosti c=f1(a) i d=f2(b), a ne postoji zavisnost c=f3(b), onda je druga normalna forma narušena u tabeli. U gornjem primjeru, nema zavisnosti između narudžbe i adrese u tabeli Reda. Promijenite naziv ulice ili grada i nećete imati utjecaja na bitne atribute narudžbe.
Baza podataka trećeg normalnog oblika zahtijeva usklađenost s drugim normalnim oblikom i odsustvo 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 tabeli u kojoj se pohranjuju atributi objekta A manifestira se atribut C, a objekt B ima atribut b, tako da postoji c=f4(b), tada je treći normalni oblik je prekršena. U primjeru ispod, 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 prilikom kreiranja modela skladištenja podataka. Kreiranje modela procesa je preduvjet za kreiranje normalnog modela podataka.
2. Postizanje trećeg normalnog oblika u strogom smislu možda neće biti praktično u stvarnoj praksi kreiranja ERP sistema ako su ispunjeni neki ili svi od sljedećih uslova:
- automatizovani procesi su retko podložni promenama,
- rokovi za istraživanje i razvoj su kratki,
- zahtjevi za integritetom podataka su relativno niski (potencijalne greške u industrijskom softveru ne dovode do gubitka novca ili klijenata od strane korisnika softvera)
- i slično.
U opisanim uslovima, troškovi identifikacije i opisivanja životnog ciklusa pojedinih objekata i njihovih atributa možda nisu opravdani sa stanovišta ekonomske efikasnosti.
3. Sve posljedice denormalizacije modela podataka u već kreiranom IS-u mogu se ublažiti detaljnim preliminarnim proučavanjem koda i testiranjem.
4. Denormalizacija je način prenošenja troškova rada iz faze istraživanja izvora podataka i dizajniranja poslovnog procesa u fazu razvoja, iz perioda implementacije u period razvoja sistema.
5. Preporučljivo je težiti trećem normalnom obliku baze podataka ako:
- Smjer promjene u automatiziranim poslovnim procesima teško je predvidjeti
- Postoji slaba podjela rada unutar implementacionog i/ili razvojnog tima
- Sistemi uključeni u integraciono kolo razvijaju se prema sopstvenim planovima
- Nedosljednost podataka može dovesti do toga da kompanija izgubi kupce ili novac
6. Dizajn modela podataka analitičar treba da sprovodi samo u vezi sa modelima ciljnog poslovnog procesa i procesa u IS-u. Ako programer dizajnira model podataka, morat će se uroniti u predmetno područje do te mjere da, posebno, razumije razliku između vrijednosti atributa - neophodan uvjet za izolaciju atomskih atributa. Dakle, preuzima neobične funkcije.
4 Problem za ilustraciju
Recimo da imate malu robotsku tavernu u luci. Vaš tržišni segment: mornari i pirati koji dolaze u luku i trebaju odmor. Pomorcima prodajete čaj s timijanom, a gusarima češljeve od ruma i kostiju za češljanje brade. Uslugu u samoj kafani pružaju robot hostesa i robot barmen. Zahvaljujući visokom kvalitetu i niskim cijenama otjerali ste svoje konkurente, tako da svi koji silaze s broda dolaze u vašu konobu koja je jedina u luci.
Kompleks informacionih sistema kafane sastoji se od sledećeg softvera:
- Sistem ranog upozorenja o klijentu koji prepoznaje svoju kategoriju na osnovu karakterističnih karakteristika
- Kontrolni sistem za robote hostese i robote barmene
- Sistem upravljanja skladištem i isporukom do prodajnog mjesta
- Sistem upravljanja odnosima sa dobavljačima (SURP)
Proces:
Sistem ranog upozorenja prepoznaje ljude koji napuštaju brod. Ako je osoba obrijana, ona je identificira kao mornara; ako se otkrije da osoba ima bradu, onda je identificirana kao gusar.
Ulaskom u konobu gost čuje pozdrav od robota domaćice u skladu sa svojom kategorijom, na primjer: „Ho-ho-ho, dragi gusaru, idi za sto br...”
Gost odlazi do navedenog stola, gdje je robot-barmen već pripremio robu za njega u skladu sa kategorijom. Robot-barmen prenosi informaciju skladišnom sistemu da se sljedeći dio isporuke treba povećati; skladišni IS, na osnovu preostalih stanja u skladištu, generiše zahtjev za kupovinu u sistemu upravljanja.
Iako je sistem ranog upozorenja možda razvio vaš interni IT, program za upravljanje robotom šipkom je možda kreirao vanjski izvođač posebno za vaše poslovanje. A sistemi za upravljanje skladištima i odnosima sa dobavljačima su prilagođena upakovana rešenja sa tržišta.
5. Primjeri denormalizacije i njen utjecaj na razvoj softvera
Prilikom osmišljavanja poslovnog procesa, ispitani stručnjaci za temu jednoglasno su izjavili da širom svijeta pirati piju rum i češljaju bradu koštanim češljem, a mornari piju čaj s timijanom i uvijek su dobro obrijani.
Pojavljuje se imenik tipova klijenata sa dvije vrijednosti: 1 - pirati, 2 - mornari, zajednički za cijeli informacioni krug kompanije.
Sistem obavještavanja klijenta odmah pohranjuje rezultat obrade slike kao identifikator (ID) prepoznatog klijenta i njegov tip: mornar ili gusar.
Prepoznati ID objekta
Kategorija klijenata
100500
Gusar
100501
Gusar
100502
Sailor
Napomenimo još jednom
1. Naši mornari su zapravo obrijani ljudi
2. Naši pirati su zapravo bradati ljudi
Koje probleme u ovom slučaju treba otkloniti da 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 tabeli
- fiksni funkcionalni odnos između atributa različitih entiteta.
U normalizovanom obliku dobili bismo dve tabele:
- rezultat prepoznavanja u obliku skupa utvrđenih karakteristika,
Prepoznati ID objekta
Brada
100500
Da
100501
Da
100502
Nijedan
- rezultat određivanja tipa klijenta kao primjena logike ugrađene u IS za tumačenje utvrđenih karakteristika
Prepoznati ID objekta
Identifikacija ID
Kategorija klijenata
100500
100001
Gusar
100501
100002
Gusar
100502
100003
Sailor
Kako normalizovana organizacija skladištenja podataka može olakšati razvoj IP kompleksa? Recimo da iznenada dobijete nove klijente. Neka to budu japanski pirati koji možda nemaju bradu, ali hodaju s papagajem na ramenu, i ekolozi, lako ih možete prepoznati po Gretinom plavom profilu na lijevom grudima.
Pirati iz okoliša, naravno, ne mogu koristiti koštane češljeve i zahtijevaju analog od reciklirane morske plastike.
Morate preraditi algoritme programa u skladu sa novim ulazima. Ako bi se poštovala pravila normalizacije, onda biste morali samo dopuniti ulaze za neke grane procesa u nekim sistemima i kreirati nove grane samo za one slučajeve i u onim IS-ovima gdje su dlake na licu bitne. Ali, pošto pravila nisu poštovana, moraćete da analizirate ceo kod, kroz celo kolo, gde se koriste vrednosti direktorijuma tipa klijenta i jasno utvrdite da u jednom slučaju algoritam treba da uzme u obzir profesionalne aktivnosti klijenta, te u drugim fizičkim karakteristikama.
U obliku koji traži za normalizaciju, dobili bismo dvije tabele sa operativnim podacima i dva direktorija:
- rezultat prepoznavanja u obliku skupa utvrđenih karakteristika,
Prepoznati ID objekta
Greta na lijevim grudima
Ptica na ramenu
Brada
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 direktorija)
Da li otkrivena denormalizacija znači da se sistemi ne mogu modifikovati da bi ispunili nove uslove? Naravno da ne. Ako zamislimo da je sve informacione sisteme kreirao jedan tim sa nultom fluktuacijom osoblja, razvoj je dobro dokumentovan i informacije se unutar tima prenose bez gubitaka, onda se potrebne promene mogu izvršiti uz zanemarljivo malo truda. Ali ako se vratimo na prvobitne uslove problema, 1,5 tastature će biti izbrisano samo za štampanje protokola zajedničkih diskusija i još 0,5 za obradu procedura nabavke.
U gornjem primjeru, sva tri normalna oblika su povrijeđena, pokušajmo ih narušiti odvojeno.
Kršenje prvog normalnog oblika:
Recimo da se roba u vaše skladište dostavlja iz skladišta dobavljača preuzimanjem pomoću jedne gazele od 1.5 tone koja pripada vašoj kafani. Veličina vaših narudžbi je toliko mala u odnosu na promet dobavljača da se uvijek izvršavaju jedan na jedan bez čekanja na proizvodnju. Da li su vam potrebne posebne tabele sa ovakvim poslovnim procesom: vozila, vrste vozila, da li je potrebno odvojiti plan i činjenicu u narudžbama odustalim dobavljačima?
Zamislite samo koliko će "dodatnih" veza vaši programeri morati da napišu ako koristite model ispod za razvoj programa.
Recimo da smo odlučili da je predložena struktura nepotrebno složena; u našem slučaju, razdvajanje plana i činjenice u zapisu narudžbe je suvišna informacija, a generirana specifikacija narudžbe se prepisuje na osnovu rezultata prijema pristigle robe, rijetke greške -razvrstavanje i dolazak robe neodgovarajućeg kvaliteta namiruju se van IS.
A onda jednog dana vidite kako je cijela kafanska sala puna ogorčenih i neurednih gusara. Šta se desilo?
Ispostavilo se da je rast vašeg poslovanja rasla i potrošnja. Nekada je donesena odluka menadžmenta da ukoliko je gazela preopterećena zapreminom i/ili težinom, što je bila izuzetno retka pojava, dobavljač će dati prednost tovaru u korist pića.
Neisporučena roba je završila u sljedećoj narudžbi i otišla na novi let, a postojanje minimalnog stanja u skladištu u kafani omogućilo je da se ne primjećuju nedostajući predmeti.
Posljednji takmičar se zatvorio u luci, a probušeni slučaj preopterećenja gazele, zaobiđen prioritizacijom na osnovu pretpostavke o dovoljnosti minimalnog balansa i periodičnog podopterećenja vozila, postao je uobičajena praksa. Kreirani sistem će idealno raditi u skladu sa algoritmima koji su u njega ugrađeni i biće lišen svake mogućnosti da prati sistematski neispunjavanje planiranih narudžbi. Samo narušena reputacija i nezadovoljni kupci moći će otkriti problem.
Pažljivi čitalac je možda 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 ispuniti zahtjev prvog normalnog oblika. Sve zavisi od toga da li, s obzirom na odabrani asortiman robe, u isto polje mogu spadati suštinski različite merne jedinice.
Kršenje drugog normalnog oblika:
Kako vaše potrebe rastu, kupujete još nekoliko vozila različitih veličina. U navedenom kontekstu, pravljenje imenika vozila smatralo se suvišnim, zbog čega svi algoritmi obrade podataka koji služe za potrebe isporuke i skladišta percipiraju kretanje tereta od dobavljača do skladišta kao let isključivo 1,5 tona tereta. gazelle. Dakle, uz kupovinu novih vozila, još uvijek kreirate imenik vozila, ali kada ga finalizirate, morat ćete analizirati sav kod koji upućuje na kretanje tereta kako biste saznali da li se na svakom konkretnom mjestu podrazumijevaju reference na karakteristike samog vozila iz kojeg je posao krenuo.
Kršenje trećeg normalnog oblika:
U nekom trenutku kada počnete da kreirate program lojalnosti, pojavljuje se zapis redovnog kupca. Zašto, na primjer, trošiti vrijeme na kreiranje pregleda materijala koji pohranjuju agregirane podatke o prodaji pojedinačnom klijentu za korištenje u izvješćivanju i prijenosu u analitičke sisteme, ako se na početku programa lojalnosti sve što interesuje kupca može staviti u evidenciju klijenta ? I zaista, na prvi pogled, nema smisla. Ali svaki put kada vaše poslovanje poveže, na primjer, nove kanale prodaje, među vašim analitičarima bi trebao biti neko ko će se sjetiti da postoji takav agregacijski atribut.
Prilikom dizajniranja svakog novog procesa, na primjer, prodaje na Internetu, prodaje preko distributera povezanih na zajednički sistem lojalnosti, neko mora imati na umu da svi novi procesi moraju osigurati integritet podataka na nivou koda. Za industrijsku bazu podataka sa hiljadu tabela, ovo izgleda kao nemoguć zadatak.
Iskusan programer, naravno, zna kako da zaustavi sve gore navedene probleme, ali, po mom mišljenju, zadatak iskusnog analitičara nije da ih iznese na videlo.
Želio bih da izrazim svoju zahvalnost vodećem developeru Evgeniy Yarukhinu za njegove vrijedne povratne informacije tokom pripreme publikacije.
Literatura
Connolly Thomas, Begg Caroline. Baza podataka. Dizajn, implementacija i podrška. Teorija i praksa
izvor: www.habr.com