Ovaj članak će se fokusirati na arhitekturu skladišta podataka. Čime se treba voditi prilikom njegove izgradnje, koji pristupi funkcionišu - i zašto.

"Priča je laž - ali u njoj ima nagoveštaja..."

Djed je zasadio ... skladište. I magacin je narastao, super, super. Jednostavno nisam znao kako to funkcionira. I djed je počeo pregled. Djed je pozvao baku, unuku, mačku i miša na porodično vijeće. I kaže sljedeće: „Naše skladište je poraslo. Podaci iz svih sistema teku prema dolje, tabele su vidljive i nevidljive. Korisnici smišljaju svoje izvještaje. Čini se da je sve dobro - živeti i živeti. Da, samo jedna tuga - niko ne zna kako to funkcioniše. Zahtijeva diskove naizgled-nevidljivo - ne možete uštedjeti dovoljno! A onda su korisnici stekli naviku da mi se obraćaju sa različitim pritužbama: ili se izvještaj zamrzne, ili su podaci zastarjeli. A onda je to prava katastrofa - dolazimo s izvještajima caru-ocu, ali brojke se međusobno ne slažu. Nije ni čas - ljuti se kralj - onda ne skidaj glavu - ni meni, ni tebi. Zato sam odlučio da vas okupim i posavjetujem se: šta ćemo?"

Baci pogled na sastanak i pita:
- Ti, babo, znaš li kako je uređeno naše skladište?
- Ne, deda, ne znam. A kako bih ja znao? Tamo, kakvi hrabri momci ga čuvaju! Neki od njih! Nećete prići. Išla sam ih nekako vidjeti, pečene pite. I pojeli su pite, obrisali brkove i rekli: „Zašto si došla, babo? Koja si ti vrsta skladišta? Recite mi kakav izvještaj vam treba - mi ćemo to uraditi umjesto vas! Trebalo bi češće donositi pite! Bolno, ukusni su."
- A ti, voljena unuče, znaš li kako je uređeno naše skladište?
- Ne, deda, ne znam. Nekako su mi dali pristup tome. Povezao sam se, gledam - a tu su i stolovi - naizgled nevidljivi. I različite šeme su skrivene. Oči pokreću…. U početku sam bio zbunjen. A onda sam dobro pogledao - neke su prazne, druge pune, ali samo pola. I čini se da se podaci ponavljaju. Nije ni čudo da vam neće biti dovoljno diskova, sa takvom redundantnošću!
- Pa ti, maco, šta kažeš na naše skladište? Ima li nečeg dobrog u tome?
- Da, kako da ne kažem, deda - hoću. Na zahtjev moje unuke, pokušao sam napraviti pilot u posebnom krugu - maloj izlozi. Da bi shvatili kakva je trgovina profitabilna za našu državu - koji su proizvodi dobri za trgovce, plaćaju danak - nadopunjuju riznicu. I koje su veoma loše. I počeo sam da biram podatke za sebe iz ovog spremišta. Prikupljene činjenice. I počeo je da pokušava da ih uporedi sa proizvodima. I šta sam, dede, video - proizvodi su izgleda isti, ali pogledate tanjire - drugačiji su! Tada sam počela da ih češljam češljem svoje unuke. Chesal-izgreban - i doveo do određene uniformnosti, milujući oči. Ali rano sam se obradovao - sledećeg dana sam pokrenuo svoje skripte da ažuriram divne podatke u prozoru - i sve je nestalo za mene! "Kako to?" - Mislim - uznemiriće se unuka - danas bi trebalo našeg pilota pokazati ministru. Kako ćemo sa takvim podacima?
- Da, tužne priče, mačka, ti pričaj. Pa ti, mali mišu, stvarno nisi pokušao da saznaš za skladište? Sa nama si živahna, okretna, druželjubiva djevojka! Šta ćeš nam reći?
- Da, kako, deda, ne pokušavaj - naravno, ja sam tih miš, da okretan. Jednom me je mačja unuka zamolila da dobijem model podataka našeg državnog skladišta. I mačka mi je, naravno, došla - za tebe, kaže, miš, sva nada! Pa, šta je dobro djelo za dobre ljude (i mačke) da ne urade? Otišao sam u dvorac, gdje šef skladišta skriva model podataka u sefu. I sakrila se. Čekao sam da izvadi taj model iz sefa. Čim je izašao na kafu, ja sam skočila na sto. Gledam model - ništa ne mogu da razumem! Kako to? Ne prepoznajem naše skladište! Imamo bezbrojne hiljade tabela, tokovi podataka su nezaustavljivi! I ovdje - sve je skladno i lijepo... Pogledao je baš ovaj model - i vratio ga u sef.
- Da, vrlo čudne stvari, rekao si nam, mišu.
Djed je dobro razmislio.
- Šta ćemo, prijatelji moji? Uostalom, s takvim i takvim spremištem nećete dugo živjeti... Korisnici će uskoro izgubiti strpljenje.

Šta god da je naš djed odlučio iz bajke - izgraditi novo skladište ili pokušati reanimirati postojeće - potrebno je izvući zaključke prije nego što ponovo "zasučemo rukave".
Ostavimo po strani organizacione aspekte – kao što su opasnost koncentracije stručnosti u određenoj uskoj zatvorenoj grupi, odsustvo procesa kontrole i osiguranje transparentnosti arhitekture sistema koji se koriste u preduzeću itd.
Danas bih želeo da se fokusiram na izgradnju arhitekture specifičnog sistema (ili grupe sistema) - skladišta podataka. Ono što prije svega treba imati u fokusu, kada organizacija počne da gradi tako složen i skup sistem kao što je skladište.

Debrifing

Niko od nas, radeći na stvaranju i razvoju bilo kog sistema, ne želi da ovo bude „privremena kuća“, ili rešenje koje će „uvenuti“ za godinu-dve, jer neće moći ispuniti zahtjeve i očekivanja kupaca i poslovanja. Koliko god da se danas uočava jaka pristrasnost prema „fleksibilnim metodologijama“, čoveku je mnogo prijatnije da se oseća kao „majstor“ koji pravi violine nego zanatlija koji blanja štapove za jednokratne bubnjeve.
Naša namjera zvuči prirodno: da napravimo sisteme koji su čvrsti i kvalitetni, koji neće zahtijevati od nas redovno „noćno bdjenje sa kartotekom“, zbog čega se nećemo stidjeti pred krajnjim korisnicima i koji neće izgledati kao "crna kutija" za sve "neupućene" pratioce.

Za početak, hajde da navedemo listu tipičnih problema sa kojima se redovno susrećemo kada radimo sa spremištima. Hajde da samo zapišemo šta imamo – do sada bez pokušaja da ga pojednostavimo i formalizujemo.

1. U principu, imamo dobro skladište: ako ga ostavite na miru, onda sve radi. Istina, čim je potrebna promjena, počinju "lokalni kolapsi".
2. Podaci se učitavaju dnevno, po propisima, u jednom velikom procesu, u roku od 8 sati. I odgovara nam. Ali ako iznenada dođe do kvara, potrebna je ručna intervencija. A onda sve može raditi nepredvidivo dugo vremena, tk. će zahtijevati ljudsko učešće u procesu.
3. Zamotali izdanje - očekujte probleme.
4. Neki izvor nije mogao poslati podatke na vrijeme - svi procesi čekaju.
5. Integritet podataka kontroliše baza podataka - tako da naši procesi padaju kada se pokvare.
6. Imamo veoma veliko skladište - 2000 tabela u jednoj zajedničkoj šemi. I još 3000 u mnogim drugim shemama. Već imamo malo pojma kako su raspoređeni i iz kog razloga su se pojavili. Stoga nam može biti teško da nešto ponovo iskoristimo. A mnogi zadaci moraju biti riješeni iznova. Jer, ovo je lakše i brže (nego razumjeti "tuđu šifru"). Kao rezultat toga, imamo odstupanja i duplirane funkcionalnosti.
7. Očekujemo da izvor pruži kvalitetne podatke. Ali ispostavilo se da to nije slučaj. Kao rezultat toga, trošimo mnogo vremena na usaglašavanje naših konačnih izvještaja. I u tome su bili veoma uspješni. Imamo čak i pojednostavljen proces. Istina, potrebno je vrijeme. Ali korisnici su navikli da...
8. Korisnik ne vjeruje uvijek našim izvještajima i zahtijeva opravdanje jedne ili druge brojke. U nekim slučajevima je u pravu, au drugima nije. Ali vrlo nam je teško da ih opravdamo, jer nemamo sredstva za "end-to-end analizu" (ili lozu podataka).
9. Mogli bismo dovesti dodatne programere. Ali imamo problem – kako ih uključiti u rad? Koji je najefikasniji način paralelizacije poslova?
10. Kako postepeno razvijati sistem, ne ulazeći u razvoj "jezgra sistema" čitavu godinu?
11. Skladište podataka je povezano s korporativnim modelom. Ali znamo pouzdano (vidjeli smo to u banci XYZ) da izgradnja modela može biti beskonačno duga (išli smo u banku XYZ šest mjeseci i razgovarali o privrednim subjektima, bez ikakvog pomaka). Zašto je ona uopšte? Ili je možda bolje bez nje, ako ima toliko problema sa njom? Možda ga nekako možemo generirati?
12. Odlučili smo da vozimo model. Ali kako sistematski razvijati model podataka skladišta? Da li su nam potrebna “pravila igre” i koja bi ona mogla biti? Šta će nam to dati? Šta ako nismo u pravu s modelom?
13. Da li da čuvamo podatke, odnosno istoriju njihovih promena, ako "poslu ne trebaju"? Ne bih želio da "skladištim smeće" i kompliciram korištenje ovih podataka za stvarne zadatke. Da li trezor treba da čuva istoriju? kakav je? Kako skladištenje funkcioniše tokom vremena?
14. Da li da pokušamo da objedinimo podatke na skladištu ako imamo sistem upravljanja glavnim podacima? Ako postoji MDM, znači li to da je cijeli problem s glavnim podacima sada riješen?
15. Očekuje se da ćemo uskoro zamijeniti ključne računovodstvene sisteme. Da li skladište podataka mora biti spremno za promjenu izvora? Kako se to može postići?
16. Da li su nam potrebni metapodaci? Šta mislimo pod ovim? Gdje se tačno mogu koristiti? Kako to možete implementirati? Trebam li ih čuvati "na jednom mjestu"?
17. Naši kupci su krajnje nestabilni u svojim zahtjevima i željama – nešto se stalno mijenja. Generalno, naše poslovanje je veoma dinamično. Dok nešto radimo, to već postaje nepotrebno. Kako to učiniti na način da rezultat dobijemo što je brže moguće – poput vrućih kolača?
18. Korisnici zahtijevaju brzu reakciju. Ali ne možemo često pokretati naše glavne procese pokretanja, jer ovo učitava izvorne sisteme (ima loš uticaj na performanse) - stoga, spuštamo dodatne tokove podataka - koji će pokupiti u tački - ono što nam treba. Istina, ima mnogo tokova. A onda ćemo odbaciti neke podatke. Štaviše, postojaće problem konvergencije. Ali nema drugog načina...

Dosta toga se već dogodilo. Ali ovo nije potpuna lista - lako je dopuniti i razviti. Nećemo ga skrivati ​​u stolu, već ga okačiti na vidno mjesto – držeći ove probleme u fokusu naše pažnje u procesu rada.
Naš zadatak je da kao rezultat dođemo do sveobuhvatnog rješenja.

Antifragility

Gledajući našu listu, može se izvući jedan zaključak. Nije teško napraviti neku vrstu "baze podataka za izvještavanje", učitati podatke u nju, ili čak izgraditi neku vrstu rutinskih procesa ažuriranja podataka. Sistem nekako počinje da živi, ​​pojavljuju se korisnici, a sa njima obaveze i SLA, nastaju novi zahtjevi, povezuju se dodatni izvori, mijenjaju se metodologije - sve to mora biti uzeto u obzir u procesu razvoja.

Nakon nekog vremena, slika je sljedeća:
“Ovdje je trezor. I radi ako ga ne dodirnete. Problemi nastaju kada moramo nešto promijeniti."

Stiže nam promena čiji uticaj nismo u stanju da procenimo i shvatimo (pošto takve alate nismo ubacili u sistem od samog početka) – a da ne bismo rizikovali, ne diramo ono što jeste, ali pravimo još jedan produžetak sa strane, pa još jedan, i takođe - pretvaramo našu odluku u sirotinjske četvrti, ili, kako kažu u Latinskoj Americi, "favele", u koje se čak i policija plaši da uđe.
Javlja se osjećaj gubitka kontrole nad vlastitim sistemom, haosa. Potrebno je sve više ruku za održavanje postojećih procesa i rješavanje problema. A promjene je sve teže i teže napraviti. Drugim riječima, sistem postaje nestabilan na stres, neprilagođen promjenama. Osim toga, postoji jaka ovisnost o likovima koji "poznaju fervej", jer niko nema "mapu".

Ovo svojstvo objekta - da se uruši pod uticajem haosa, slučajnih događaja i šokova - naziva Nassim Nicholas Taleb krhkost ... I također uvodi suprotan koncept: antifragilnost – kada se objekt ne urušava od stresa i nezgoda, već ima direktnu korist od toga... ("Antifragilnost. Kako imati koristi od haosa")
Inače se može nazvati prilagodljivost ili otpornost na promjene .

Šta to znači u ovom kontekstu? Koji su „izvori haosa“ za IT sisteme? A šta znači "kapitalizirati haos" u smislu IT arhitekture?
Prva misao koja vam pada na pamet su promjene koje dolaze izvana. Šta je vanjski svijet za sistem? Za skladištenje posebno. Naravno, prije svega - promjene sa strane izvora podataka za trgovinu:

• promjena formata dolaznih podataka;
• zamjena nekih sistema izvora podataka drugim;
• promjena pravila/platforme za integraciju sistema;
• promena interpretacije podataka (formati se čuvaju, menja se logika rada sa podacima);
• promjena modela podataka ako se integracija vrši na razini podataka (parsiranje log fajlova transakcija baze podataka);
• rast obima podataka - dok u izvornom sistemu nije bilo mnogo podataka, a opterećenje nije bilo veliko - bilo je moguće dohvatiti ih bilo kada, uz proizvoljno težak zahtjev, podaci i opterećenje su se povećavali - sada postoje stroga ograničenja ;
• itd.

Sami izvorni sistemi, sastav informacija i njihova struktura, tip integracijske interakcije, kao i sama logika rada sa podacima mogu se promijeniti. Svaki sistem implementira sopstveni model podataka i pristupe radu sa njima, koji ispunjavaju ciljeve i zadatke sistema. I koliko god se trudili da objedine industrijske modele i referentne prakse, nijanse će se neizbježno pojaviti. (A osim toga, sam proces objedinjavanja industrije, iz raznih razloga, ne napreduje mnogo.)
Kultura rada sa korporativnim podacima - prisustvo i kontrola informacione arhitekture, jedinstveni semantički model, sistemi za upravljanje glavnim podacima (MDM) donekle olakšavaju zadatak konsolidacije podataka u skladištu, ali ne isključuju njegovu potrebu.

Ništa manje kritične promjene iniciraju potrošači skladišta (promijene se zahtjevi):

• ranije je bilo dovoljno podataka za izradu izvještaja - sada je bilo potrebno povezati dodatna polja ili novi izvor podataka;
• ranije implementirane tehnike obrade podataka su zastarjele - potrebno je preraditi algoritme i sve što na to utiče;
• Ranije su svi bili zadovoljni trenutnom vrijednošću atributa rječnika na informativnoj tabli - sada se traži vrijednost koja je relevantna u trenutku analizirane činjenice/događaja;
• postojao je zahtev za dubinom istorije skladištenja podataka, koji ranije nije postojao - da se podaci čuvaju ne 2 godine, već 10 godina;
• ranije je bilo dovoljno podataka na “kraj dana/perioda” - sada vam je potrebno stanje podataka “unutar dana”, ili u vrijeme određenog događaja (na primjer, donošenje odluke o zahtjevu za kredit - za Bazel II);
• ranije smo bili zadovoljni izvještavanjem o podacima za jučer (T-1) ili kasnije, sada nam treba T0;
• itd.

I integracijske interakcije sa izvornim sistemima i zahtjevi potrošača podataka iz skladišta su vanjski faktori za skladište podataka: neki izvorni sistemi zamjenjuju druge, količina podataka raste, formati ulaznih podataka se mijenjaju, zahtjevi korisnika se mijenjaju, itd. A sve su to tipične vanjske promjene za koje naš sistem – naše spremište – mora biti spreman. Uz odgovarajuću arhitekturu, ne bi trebali ubiti sistem.

Ali to nije sve.
Govoreći o varijabilnosti, prije svega se sjećamo vanjskih faktora. Uostalom, iznutra možemo sve kontrolisati, tako nam se čini, zar ne? Da i ne. Da, većina faktora koji su izvan zone uticaja su eksterni. Ali postoji i „unutrašnja entropija“. I upravo zbog njegovog prisustva, ponekad se trebamo vratiti „na tačku 0“. Počnite igru ​​ispočetka.
U životu smo često skloni da počnemo od nule. Zašto je ovo svojstveno nama? I da li je zaista tako loše?
Primijenjeno na IT. Za sam sistem – to može biti jako dobro – sposobnost da se preispitaju pojedinačne odluke. Pogotovo kada to možemo učiniti lokalno. Refaktoring je proces razotkrivanja “weba” koji se periodično pojavljuje u procesu razvoja sistema. Vraćanje na početak može biti od pomoći. Ali to ima cijenu.
Uz kompetentno upravljanje arhitekturom, ova cijena se smanjuje - a sam proces razvoja sistema postaje kontrolisaniji i transparentniji. Jednostavan primjer: ako se poštuje princip modularnosti, možete prepisati poseban modul bez utjecaja na vanjska sučelja. A to se ne može učiniti s monolitnom strukturom.

Antifragilnost sistema određena je arhitekturom koja je u njega ugrađena. I upravo to svojstvo čini ga prilagodljivim.
Kada pričamo o adaptivna arhitektura- mislimo da je sistem u stanju da se prilagođava promenama, a ne da mi stalno menjamo samu arhitekturu. Naprotiv, što je arhitektura stabilnija i stabilnija, što je manje zahtjeva koji zahtijevaju njenu reviziju, to je sistem prilagodljiviji.

Rešenja koja podrazumevaju reviziju celokupne arhitekture imaće mnogo veću cenu. I morate imati vrlo dobre razloge za njihovo usvajanje. Na primjer, takvo obrazloženje može biti zahtjev koji se ne može implementirati unutar postojeće arhitekture. Onda kažu - pojavio se zahtjev koji utiče na arhitekturu.
Stoga, također moramo znati naše „granice antifragilnosti“. Arhitektura se ne razvija "u vakuumu" - ona se zasniva na trenutnim zahtjevima i očekivanjima. A ako se situacija iz temelja promijeni – moramo shvatiti da smo otišli dalje od trenutne arhitekture – i moramo je revidirati, izraditi drugačije rješenje – i razmisliti o putevima tranzicije.
Na primjer, pretpostavili smo da će nam u skladištu uvijek biti potrebni podaci na kraju dana, podatke ćemo uzimati svaki dan koristeći standardna sistemska sučelja (kroz skup pogleda). Tada je iz odjela za upravljanje rizicima stigao zahtjev da se podaci ne primaju na kraju dana, već u trenutku donošenja odluke o kreditiranju. Nema potrebe da pokušavate da „izvučete nenapeto“ – samo treba da priznate ovu činjenicu – što pre to bolje. I počnite raditi na pristupu koji će nam omogućiti da riješimo problem.
Ovdje je vrlo tanka linija - ako uzmemo u obzir samo "zahtjeve u trenutku" i ne gledamo nekoliko koraka unaprijed (i nekoliko godina unaprijed), onda povećavamo rizik da se suočimo sa zahtjevom koji utiče na arhitekturu prekasno - i cijena naše promjene će biti vrlo visoka. Pogled malo unaprijed - unutar granica našeg horizonta - još nikome nije naškodio.

Primjer sistema iz "priče o skladištenju" samo je jedan primjer vrlo klimavog sistema izgrađenog na krhkim pristupima dizajnu. A ako se to dogodi, uništenje se dešava prilično brzo, za ovu klasu sistema.
Zašto mogu tako reći? Tema repozitorija nije nova. Pristupi i inženjerske prakse koji su razvijeni tokom ovog vremena bili su usmjereni upravo na to - održavanje održivosti sistema.
Jednostavan primjer: Jedan od najčešćih razloga za neuspjeh početnih skladišnih projekata je pokušaj izgradnje skladišta preko razvojnih izvornih sistema bez dogovora o integracijskim interfejsima — pokušaj dohvaćanja podataka direktno iz tabela. Kao rezultat toga, krenuli smo u razvoj - tokom tog vremena se promijenila izvorna baza podataka - i tokovi učitavanja u spremištu su postali neoperativni. Prekasno je da se nešto ponovi. A ako se još niste osigurali tako što ste napravili nekoliko slojeva stolova unutar skladišta, onda možete sve izbaciti i početi ispočetka. Ovo je samo jedan primjer, i to jedan od jednostavnih.

Talebov kriterij za krhko i antifragilno je jednostavan. Glavni sudija je vreme. Ako sistem izdrži test vremena, i pokaže svoju "vitalnost" i "neuništivost" - ima svojstvo antikrhkosti.
Ako pri projektovanju sistema uzmemo u obzir antifragilnost kao uslov, to će nas ohrabriti da koristimo takve pristupe u izgradnji njegove arhitekture koji će sistem učiniti prilagodljivijim i „haosu izvana“ i „haosu iznutra“. . I na kraju, sistem će imati duži vek trajanja.
Niko od nas ne želi da pravi "provizorne kuće". I nemojte se zavaravati, što danas nije drugačije. Normalno je da osoba u svakom trenutku gleda nekoliko koraka ispred sebe, posebno tokom krize.

Šta je skladište podataka i zašto ga gradimo

Članak o arhitekturi skladištenja pretpostavlja da čitalac ne samo da zna šta je to, već ima i određeno iskustvo sa takvim sistemima. Ipak, smatrao sam da je to neophodno učiniti – vratiti se iskonima, na početak puta, jer tu se nalazi "uporište" razvoja.

Kako su ljudi došli na ideju da su skladišta podataka potrebna? I po čemu se razlikuju od "veoma velike baze podataka"?
Davno, kada su u svijetu postojali jednostavno "sistemi za obradu poslovnih podataka", nije bilo podjele IT sistema na klase kao što su front-end oltp sistemi, back-office dss, sistemi za obradu teksta, skladišta podataka itd.
U to vrijeme je Michael Stonebreaker kreirao prvi mehanizam za relacijske baze podataka, Ingres.
A to je bilo vrijeme kada je era personalnih računara uletjela u kompjutersku industriju kao vrtlog i zauvijek promijenila sve ideje tadašnje IT zajednice.

U to vrijeme bilo je lako pronaći poslovne aplikacije napisane na bazi DBMS-a desktop klase, kao što su Clipper, dBase i FoxPro. A tržište za klijent-server aplikacije i DBMS samo je dobijalo zamah. Serveri baza podataka su se pojavljivali jedan za drugim, koji će još dugo zauzimati svoju nišu u IT prostoru - Oracle, DB2 itd.
I termin "aplikacija baze podataka" je bio uobičajen. Šta je uključivala takva aplikacija? Pojednostavljeno - neki obrasci za unos preko kojih su korisnici mogli istovremeno unositi informacije, neki proračuni koji su pokretani "po dugmetu" ili "po rasporedu", kao i neki izvještaji koji su se mogli vidjeti na ekranu ili sačuvati kao fajlovi i poslati na pečat.
„Ništa posebno – samo obična aplikacija, samo baza podataka“, primetio je jedan od mojih mentora na početku moje karijere. "Znači ništa posebno?" - Mislio sam tada.

Ako bolje pogledate, još uvijek postoje neke posebnosti. Kako korisnici rastu, povećava se i obim dolaznih informacija, kako se povećava opterećenje sistema, njegovi programeri, dizajneri, kako bi održali performanse na prihvatljivom nivou, idu na neke "trikove". Prva je podjela monolitnog "sistema za obradu poslovnih podataka" na računovodstvenu aplikaciju koja podržava rad korisnika na mreži, a posebno je izdvojena aplikacija za grupnu obradu podataka i izvještavanje. Svaka od ovih aplikacija ima svoju bazu podataka i čak se nalazi na zasebnoj instanci servera baze podataka, sa različitim postavkama za različite vrste opterećenja - OLTP i DSS. A tokovi podataka se nižu između njih.

To je sve? Čini se da je problem riješen. Šta se dalje događa?
A onda kompanije rastu, njihove potrebe za informacijama se množe. Raste i broj interakcija sa vanjskim svijetom. I kao rezultat toga, ne postoji jedna velika aplikacija koja u potpunosti automatizira sve procese, već nekoliko različitih različitih proizvođača. Povećava se broj sistema koji generišu informacije – sisteme izvora podataka u kompaniji. I prije ili kasnije, pojavit će se potreba da se vide i uporede informacije primljene iz različitih sistema. Tako se u kompaniji pojavljuju skladišta podataka - nova klasa sistema.
Općeprihvaćena definicija ove klase sistema je sljedeća.

Skladište podataka (ili skladište podataka)- predmetno orijentisana informaciona baza podataka posebno dizajnirana i dizajnirana za pripremu izveštaja i poslovnih analiza u cilju podrške donošenju odluka u organizaciji

dakle, konsolidacija podaci iz različitih sistema, mogućnost sagledavanja na određeni "uniformisan" (unificiran) način - ovo je jedno od ključnih svojstava sistema klase skladišta podataka. To je razlog zašto su se spremišta pojavila tokom evolucije IT sistema.

Ključne karakteristike skladišta podataka

Pogledajmo izbliza. Koje su ključne karakteristike ovih sistema? Po čemu se skladišta podataka razlikuju od drugih IT sistema preduzeća?

Prvo, to su velike količine. Veoma veliki. VLDB - tako vodeći proizvođači nazivaju takve sisteme kada daju svoje preporuke o upotrebi svojih proizvoda. Iz svih sistema kompanije podaci se slijevaju u ovu veliku bazu podataka i tamo se pohranjuju "zauvijek i nepromijenjeni", kako se kaže u udžbenicima (u praksi se ispostavlja da je život složeniji).

Drugo, ovo su istorijski podaci - "Korporativna memorija" - tzv. skladišta podataka. Što se tiče rada sa vremenom u repozitorijumima, sve je prilično zanimljivo. U računovodstvenim sistemima podaci su trenutno ažurni. Tada korisnik izvodi neku vrstu operacije - i podaci se ažuriraju. U isto vrijeme, historija promjena možda neće biti sačuvana - ovisi o računovodstvenoj praksi. Uzmite, na primjer, stanje na bankovnom računu. Možda nas zanima trenutno stanje u "sada", na kraju dana ili u vrijeme nekog događaja (na primjer, u vrijeme izračunavanja rezultata). Dok je prva dva prilično lako riješiti, ovo drugo će najvjerovatnije zahtijevati posebne napore. Korisnik, radeći sa skladištem, može se osvrnuti na prošle periode, uporediti ih sa trenutnim itd. Upravo te mogućnosti vezane za vrijeme značajno razlikuju skladišta podataka od računovodstvenih sistema - dobijanje stanja podataka u različitim tačkama na vremenskoj osi - do određene dubine u prošlosti.

Treće, jeste konsolidacija i objedinjavanje podataka ... Da bi njihova zajednička analiza bila moguća, potrebno ih je dovesti u zajednički oblik - unificirani model podataka , uporedite činjenice sa jedinstvenim referentnim knjigama. Ovdje može postojati nekoliko aspekata i poteškoća. Kao prvo - konceptualni - pod istim pojmom, različiti ljudi iz različitih odjela mogu razumjeti različite stvari. I obrnuto – nazvati nešto drugačije, što je u suštini ista stvar. Kako pružiti „jedinstveni pogled“ uz zadržavanje specifične vizije određene grupe korisnika?

Četvrto, ovo je rad sa kvalitet podataka ... U procesu učitavanja podataka u skladište, oni se čiste, izvode generalne transformacije i transformacije. Generalne transformacije se moraju obaviti na jednom mjestu - a zatim koristiti za izradu različitih izvještaja. Time će se izbjeći nedosljednosti koje nerviraju poslovne korisnike — posebno rukovodioce koji su dovedeni za stol s brojevima iz različitih odjela koji se međusobno ne slažu. Loš kvalitet podataka stvara greške i neslaganja u izvještajima, a posljedica je smanjenje nivoa povjerenje korisnika na cijeli sistem, na cijelu analitičku službu u cjelini.

Arhitektonski koncept

Svako ko je naišao na spremište najvjerovatnije je uočio neku vrstu "slojevite strukture" - od tada upravo je ova arhitektonska paradigma zaživjela za sisteme ove klase. I to nije slučajnost. Slojevi pohrane mogu se percipirati kao zasebne komponente sistema - sa svojim zadacima, područjem odgovornosti, "pravilima igre".
Slojevita arhitektura je sredstvo za suočavanje sa složenošću sistema – svaki naredni nivo je apstrahovan od složenosti unutrašnje implementacije prethodnog. Ovaj pristup vam omogućava da izdvojite zadatke iste vrste i riješite ih na ujednačen način, bez ponovnog izmišljanja "točka" od nule svaki put.
Idejni arhitektonski dijagram je shematski prikazan na slici. Ovo je pojednostavljeni dijagram koji odražava samo ključnu ideju - koncept, ali bez "anatomskih detalja" koji bi nastali dubljom razradom detalja.

Kao što je prikazano na dijagramu, konceptualno odaberite sljedeće slojeve. Tri glavna sloja koji sadrže područje za pohranu podataka (označeno popunjenim pravokutnikom) i softver za učitavanje podataka (konvencionalno označen strelicama iste boje). A također i pomoćni - servisni sloj, koji, međutim, igra vrlo važnu povezujuću ulogu - upravljanje opterećenjem podataka i kontrolu kvaliteta.

Primarni sloj podataka - primarni sloj podataka (ili inscenacija , ili operativni sloj ) - dizajniran za učitavanje iz izvornih sistema i spremanje primarnih informacija, bez transformacija - u originalnom kvalitetu i podržava kompletnu istoriju promjena.
Zadatak ovog sloja- da se apstrahuju naredni slojevi skladištenja od fizičke strukture izvora podataka, metoda prikupljanja podataka i metoda odvajanja delte promena.

Core Data Layer - jezgro skladištenja - centralna komponenta sistema koja razlikuje skladište od samo "platforme batch integracije" ili "velikog deponija podataka", budući da je njegova glavna uloga konsolidacija podataka iz različitih izvora, redukcija na uniformne strukture, ključevi. Prilikom učitavanja u kernel glavni posao se obavlja s kvalitetom podataka i općim transformacijama, koje mogu biti prilično složene.
Zadatak ovog sloja- da apstrahuju svoje potrošače od karakteristika logičkog uređaja izvora podataka i potrebe za poređenjem podataka iz različitih sistema, kako bi se osigurao integritet i kvalitet podataka.

Data Mart Layer - analitički vitrine - komponenta čija je glavna funkcija pretvaranje podataka u strukture koje su pogodne za analizu (ako BI radi sa vitrinama, onda je to, po pravilu, dimenzionalni model), ili prema zahtjevima potrošačkog sistema.
Po pravilu, data vitrine preuzimaju podatke iz jezgra - kao pouzdan i provjereni izvor - tj. koristite uslugu ove komponente da dovedete podatke u jedan oblik. Takve ćemo vitrine nazvati redovno ... U nekim slučajevima, izlozi mogu uzimati podatke direktno iz stadijuma - radeći sa primarnim podacima (u izvornim ključevima). Ovaj pristup se obično koristi za lokalne zadatke gdje nije potrebna konsolidacija podataka iz različitih sistema i gdje je efikasnost potrebna više od kvaliteta podataka. Takve vitrine se nazivaju operativni ... Neki analitički indikatori mogu imati vrlo složene metode izračunavanja. Stoga se za takve netrivijalne proračune i transformacije koriste tzv sekundarne vitrine .
Showcase Layer Zadatak- priprema podataka prema zahtjevima konkretnog potrošača - BI platforme, grupe korisnika ili eksternog sistema.

Gore opisani slojevi se sastoje od trajnog prostora za skladištenje podataka, kao i softverskog modula za učitavanje i transformaciju podataka. Ova podjela na slojeve i regije je logična. Fizički, implementacija ovih komponenti može biti različita - čak možete koristiti različite platforme za skladištenje ili transformaciju podataka na različitim slojevima, ako je to efikasnije.
Područja skladištenja sadrže tehničke (tabele bafera) koje se koriste u procesu transformacije podataka i ciljne tabele na koju se odnosi potrošačka komponenta. Dobra je praksa "pokriti" ciljne tabele pogledima. Ovo olakšava naknadno održavanje i razvoj sistema. Podaci u ciljnim tabelama sva tri sloja označeni su posebnim tehničkim poljima (meta-atributima), koja služe za podršku procesa učitavanja podataka, kao i za omogućavanje informatičke revizije tokova podataka u skladištu.

Također, izdvaja se posebna komponenta (ili skup komponenti) koja pruža servisne funkcije za sve slojeve. Jedan od njegovih ključnih zadataka je kontrolna funkcija - da obezbijedi "jedinstvena pravila igre" za cijeli sistem u cjelini, ostavljajući pravo korištenja različitih opcija za implementaciju svakog od gore opisanih slojeva - uklj. koriste različite tehnologije za učitavanje i obradu podataka, različite platforme za skladištenje itd. Nazovimo to servisni sloj ... Ne sadrži poslovne podatke, ali ima svoje strukture skladištenja - sadrži područje metapodataka, kao i područje za rad s kvalitetom podataka (i eventualno druge strukture, ovisno o funkcijama koje su mu dodijeljene).

Ovakva jasna podjela sistema na zasebne komponente značajno povećava upravljivost razvoja sistema:

• smanjena je složenost zadatka koji se postavlja programeru funkcionalnosti jedne ili druge komponente (ne bi trebao istovremeno rješavati pitanja integracije sa vanjskim sistemima, razmišljati o procedurama čišćenja podataka i razmišljati o optimalnoj prezentaciji podataka za potrošače) - zadatak je lakše razložiti, procijeniti i izvršiti malu isporuku;
• možete se povezati s radom raznih izvođača (pa čak i timova, odnosno izvođača) - jer ovaj pristup vam omogućava da efikasno paralelizirate zadatke, smanjujući njihov međusobni uticaj;
• Prisutnost trajnog staginga omogućava vam da brzo povežete izvore podataka bez dizajniranja cijele jezgre ili izloga za cijelo predmetno područje, a zatim postepeno dovršite preostale slojeve prema prioritetima (štaviše, podaci će već biti u skladištu - dostupni sistemu analitičari, što će uvelike olakšati zadatke naknadnog razvoja skladišta);
• prisutnost jezgre omogućava da se sav rad s kvalitetom podataka (kao i moguće greške i greške) sakrije od izloga i od krajnjeg korisnika, a što je najvažnije - korištenjem ove komponente kao jedinstvenog izvora podataka za izloge možete izbjeći podatke problemi konvergencije zbog implementacije uobičajenih algoritama na jednom mjestu;
• odabir tržišta vam omogućava da uzmete u obzir razlike i specifičnosti razumijevanja podataka koje korisnici različitih odjela mogu imati, a njihov dizajn za BI zahtjeve omogućava ne samo izdavanje agregiranih brojki, već i osiguravanje valjanosti podataka pružanjem mogućnosti za proučiti do primarnih indikatora;
• prisutnost servisnog sloja omogućava vam da izvršite analizu podataka od kraja do kraja (podaci), koristite objedinjene alate za reviziju podataka, opći pristup isticanja delta promjena, rad s kvalitetom podataka, upravljanje opterećenjem, praćenje i alate za dijagnostiku grešaka i ubrzava rješavanje problema.

Ovaj pristup razgradnji takođe čini sistem otpornijim na promene (u poređenju sa "monolitnom strukturom") - obezbeđuje njegovu antikrhkost:

• promjene na dijelu izvornih sistema se obrađuju na staging-u - u kernelu se modificiraju samo oni tokovi koji su pod utjecajem ovih staging tablica, efekat na izloge je minimalan ili ga nema;
• promjene zahtjeva potrošača obrađuju se najvećim dijelom na izlozima (ako za to nisu potrebne dodatne informacije kojih još nema u radnji).

Zatim ćemo proći kroz svaku od gore predstavljenih komponenti i pogledati ih malo detaljnije.

Sistemsko jezgro

Počnimo od sredine - jezgra sistema ili srednjeg sloja. Označen je kao Core Layer. Kernel igra ulogu konsolidacije podataka - dovodeći do uniformnih struktura, priručnika, ključeva. Tu se obavlja glavni posao sa kvalitetom podataka - čišćenje, transformacija, unifikacija.

Prisutnost ove komponente vam omogućava da ponovo koristite tokove podataka koji transformišu primarne podatke primljene iz izvornih sistema u određeni unificirani format, slijedeći opća pravila i algoritme, a ne ponavljate implementaciju iste funkcionalnosti posebno za svaki izlog aplikacije, koji osim toga neefikasnom korišćenju resursa, može dovesti i do neslaganja u podacima.
Jezgro repozitorija je implementirano u model podataka, u opštem slučaju, različit kako od modela izvornih sistema, tako i od formata i struktura potrošača.

Osnovni model skladišta i model podataka preduzeća

Glavna briga srednjeg skladišnog sloja je stabilnost. Zato je glavni fokus ovdje na modelu podataka. Obično se naziva "model korporativnih podataka". Nažalost, oko njega se stvorila neka vrsta aure mitova i apsurda, koji ponekad dovode do odbijanja da se potpuno izgradi, ali uzalud.

Mit 1. Model podataka preduzeća je ogroman model sa hiljadama entiteta (tabela).
Zapravo. U bilo kojoj predmetnoj oblasti, u bilo kojoj oblasti poslovanja, u podacima bilo koje kompanije, pa i najsloženije, postoji nekoliko osnovnih entiteta - 20-30.

Mit 2. Nema potrebe za razvojem "vlastitog modela" - kupujemo industrijski referentni model - i radimo sve u skladu s njim. Trošimo novac - ali dobijamo zagarantovan rezultat.
Zapravo. Referentni modeli zaista mogu biti vrlo korisni jer sadrže industrijsko iskustvo u modeliranju ove oblasti. Iz njih možete izvući ideje, pristupe, prakse imenovanja. Provjerite "dubinu pokrivenosti" područja kako se nešto važno ne bi previdjelo. Ali malo je vjerovatno da ćemo moći koristiti takav model iz kutije - takav kakav je. Ovo je isti mit kao, na primjer, kupovina ERP sistema (ili CRM) i njegova implementacija bez ikakvog "zatezanja za sebe". Vrijednost ovakvih modela se rađa u njihovom prilagođavanju realnosti ovog konkretnog posla, ove konkretne kompanije.

Mit 3. Razvoj osnovnog modela repozitorija može potrajati mnogo mjeseci, a za to vrijeme će projekat zapravo biti zamrznut. Osim toga, za to je potrebna suluda količina sastanaka i puno ljudi.
Zapravo. Model spremišta može se razvijati sa spremištem iterativno, dio po dio. Za nepokrivena područja postavljaju se "tačke ekspanzije" ili "stubovi". primjenjuju se neki "univerzalni dizajni". Istovremeno, morate znati kada stati kako ne biste dobili super-univerzalnu stvar od 4 tabele, u koju je teško i "ubaciti podatke" i (još teže) doći do njih. I što je izuzetno suboptimalno u smislu performansi.

Za razvoj modela je zaista potrebno vrijeme. Ali ovo nije vrijeme utrošeno na "crtanje entiteta" - ovo je vrijeme potrebno za analizu predmetne oblasti, razumijevanje kako su podaci raspoređeni. Zbog toga su analitičari veoma blisko uključeni u ovaj proces, a uključeni su i različiti poslovni stručnjaci. I to se radi tački, selektivno. A ne organizovanjem sastanaka sa suludim brojem ljudi, slanjem ogromnih upitnika itd.
Dobra poslovna i sistemska analiza ključna je u izgradnji osnovnog modela skladišta. Mnogo toga treba razumjeti: gdje (u kojim sistemima) se generiraju podaci, kako funkcioniraju, u kojim poslovnim procesima kruže, itd. Kvalitativna analiza nikada nije naštetila jednom sistemu. Naprotiv, problemi nastaju iz “bijelih mrlja” u našem razumijevanju.

Razvoj modela podataka nije proces izmišljanja i izmišljanja nečeg novog. Zapravo, model podataka već postoji u kompaniji. A proces dizajna više liči na "iskopavanje". Model je pažljivo i pažljivo izvučen iz "tla" korporativnih podataka i stavljen u strukturiranu formu.

Mit 4. Naše poslovanje je toliko dinamično u našoj kompaniji, a sve se tako brzo mijenja da nam je beskorisno praviti model – zastarjet će prije nego što ovaj dio sistema pustimo u rad.
Zapravo. Podsjetimo da je ključni faktor stabilnost. I iznad svega, topologija modela. Zašto? Zato što je ova komponenta centralna i utiče na sve ostalo. Stabilnost je takođe uslov za model kernela. Ako model prebrzo zastari, onda je pogrešno dizajniran. Za njen razvoj izabrani su pogrešni pristupi i „pravila igre“. I to je takođe stvar kvalitativne analize. Ključni entiteti korporativnog modela se rijetko mijenjaju.
Ali ako nam padne na pamet da za firmu koja se bavi prodajom, recimo, konditorskih proizvoda, umjesto imenika “Proizvodi” pravimo “Slatkise”, “Torte” i “Pite”. Onda kada se pizza pojavi na listi robe - da, moraćete da unesete mnogo novih tabela. A ovo je samo pitanje pristupa.

Mit 5. Kreiranje korporativnog modela je veoma ozbiljan, složen i odgovoran posao. I strašno je pogriješiti.
Zapravo. Osnovni model, iako bi trebao biti stabilan, još uvijek nije “liven u metalu”. Kao i svako drugo dizajnersko rješenje, njegova struktura se može revidirati i modificirati. Samo ne morate zaboraviti na ovu njegovu kvalitetu. Ali to uopšte ne znači da „ne možete disati na to“. A to ne znači da su neprihvatljiva privremena rješenja i "stubovi" koje treba planirati za reciklažu.

Mit 6. Ako je naš izvor podataka, na primjer, sistem referentnih podataka (ili sistem upravljanja glavnim podacima - MDM), onda bi on već trebao odgovarati korporativnom modelu na prijateljski način (posebno ako je nedavno dizajniran i nije imao vremena za steći "stranu", "tradiciju "I privremene kolibe). Ispada da za ovaj slučaj - ne trebamo model kernela?
Zapravo. Da, u ovom slučaju je izgradnja osnovnog modela spremišta uvelike olakšana - pošto pratimo gotov konceptualni model najvišeg nivoa. Ali to uopće nije isključeno. Zašto? Jer prilikom izgradnje modela određenog sistema važe neka njegova vlastita pravila – koje tipove tabela koristiti (za svaki entitet), kako verzirati podatke, sa kojom granularnošću zadržati istoriju, koje meta-atribute (tehnička polja) koristiti) itd.

Osim toga, bez obzira koliko divan i sveobuhvatan sistem referentnih podataka i MDM imamo, po pravilu će postojati nijanse povezane s postojanjem lokalnih imenika „otprilike istih“ u drugim računovodstvenim sistemima. A ovaj problem, htjeli mi to ili ne, morat će se riješiti u repozitoriju – uostalom, ovdje se prikupljaju izvještaji i analitika.

Primarni sloj podataka (ili historijski scenski ili operativni sloj)

Na njemu je označen kao primarni sloj podataka. Uloga ove komponente: integracija sa izvornim sistemima, učitavanje i pohranjivanje primarnih podataka, kao i preliminarno čišćenje podataka - provjera usklađenosti sa pravilima formatno-logičke kontrole, fiksiranom u "interakcionom interfejsu ugovoru" sa izvorom.
Osim toga, ova komponenta rješava vrlo važan problem za spremište - dodjeljivanje "prave delte promjena" - bez obzira na to da li izvor omogućava praćenje promjena u podacima ili ne i kako (po kom kriteriju se one mogu "uhvatiti" ). Čim su podaci ušli u fazu - za sve ostale slojeve, pitanje delta alokacije je već jasno - zahvaljujući označavanju meta-atributima.

Podaci u ovom sloju se pohranjuju u strukture što je moguće bliže izvornom sistemu – kako bi se primarni podaci sačuvali što bliže njihovom izvornom obliku. Drugi naziv za ovu komponentu je "operativni sloj".
Zašto jednostavno ne upotrijebite uvriježeni izraz „inscenacija“? Činjenica je da je ranije, prije "ere velikih podataka i VLDB", prostor na disku bio vrlo skup - i često su primarni podaci, ako su sačuvani, bili samo u ograničenom vremenskom periodu. I često se naziva "inscenacija". cleanable tampon.
Sada su tehnologije iskoračile - i možemo sebi priuštiti ne samo da pohranimo sve primarne podatke, već i da ih historiziramo uz mogući stepen granularnosti. To ne znači da ne treba da kontrolišemo rast podataka i ne eliminišemo potrebu za upravljanjem životnim ciklusom informacija, optimizujući troškove skladištenja podataka, u zavisnosti od „temperature“ korišćenja – tj. preuzimanje "hladnih podataka" koji su manje traženi na jeftinije medije i platforme za skladištenje.

Šta nam daje prisustvo "historiciziranog uprizorenja":

• mogućnost pravljenja grešaka (u strukturama, u algoritmima transformacije, u granularnosti istorije) - nakon što smo potpuno historizovali primarne podatke u zoni dostupnosti za skladište, uvek možemo ponovo učitati naše tabele;
• prilika za razmišljanje - možemo odvojiti vrijeme da razradimo veliki fragment kernela u ovoj konkretnoj iteraciji razvoja skladišta, jer u našoj inscenaciji će, u svakom slučaju, postojati, i to sa ravnomjernim vremenskim horizontom (postojaće jedna tačka "istorijske reference");
• mogućnost analize - sačuvaćemo čak i one podatke kojih više nema u izvoru - mogli bi se tamo prepisati, otići u arhivu itd. - kod nas ostaju dostupni za analizu;
• mogućnost revizije informacija - zahvaljujući najdetaljnijim početnim informacijama, tada možemo shvatiti kako je preuzimanje funkcioniralo za nas, da smo na kraju dobili takve brojke (za to također trebamo imati oznake meta-atributima i odgovarajućim metapodaci na kojima preuzimanje radi - o tome odlučuje sloj usluge).

Koje poteškoće mogu nastati pri izgradnji "historicizirane inscenacije":

• bilo bi zgodno postaviti zahtjeve za transakcioni integritet ovog sloja, ali praksa pokazuje da je to teško postići (to znači da u ovoj oblasti ne garantujemo referentni integritet nadređenih i podređenih tabela) - usklađivanje integriteta se dešava na naknadnom slojevi;
• ovaj sloj sadrži vrlo velike količine (najobimnije na skladištu - uprkos svoj redundanciji analitičkih struktura) - i morate biti u stanju da rukujete takvim volumenima - i u smislu opterećenja i u smislu zahtjeva (inače, možete ozbiljno pogoršavaju performanse čitavog skladišta).

Šta je još zanimljivo reći o ovom sloju.
Prvo, ako se odmaknemo od paradigme „procesa utovara od kraja do kraja“, onda pravilo „karavan se kreće brzinom poslednje deve“ za nas više ne funkcioniše, tačnije, napuštamo „karavan“ princip i pređite na princip “transporter”: uzeli smo podatke iz izvora - stavili u vaš sloj - spremni za preuzimanje sljedećeg dijela. To znači da
1) ne čekamo da se obrada desi na drugim slojevima;
2) ne zavisimo od rasporeda za pružanje podataka od strane drugih sistema.
Jednostavno rečeno, planiramo proces učitavanja koji uzima podatke iz jednog izvora putem specifičnog načina povezivanja s njim, provjerava, izdvaja delta - i stavlja podatke u ciljne scenske tabele. I to je sve.

Drugo, ovi procesi su, kao što vidite, vrlo jednostavni - moglo bi se reći trivijalno, sa stanovišta logike. To znači da se mogu vrlo dobro optimizirati i parametrizovati, smanjujući opterećenje našeg sistema i ubrzavajući proces povezivanja izvora (vrijeme razvoja).
Da bi se to dogodilo, morate vrlo dobro poznavati posebnosti tehnoloških karakteristika platforme na kojoj ova komponenta radi - i tada možete napraviti vrlo efikasan alat.

Sloj za izlog

Data Mart Layer je odgovoran za pripremu i pružanje podataka krajnjim korisnicima - ljudima ili sistemima. Na ovom nivou se u najvećoj mogućoj meri uzimaju u obzir zahtevi potrošača – i logički (konceptualni) i fizički. Usluga treba da pruži tačno ono što je potrebno - ni više, ni manje.

Ako je potrošač eksterni sistem, onda, po pravilu, diktira strukture podataka koje su mu potrebne i pravila za prikupljanje informacija. Dobar pristup je onaj u kojem je potrošač odgovoran za ispravno prikupljanje podataka. Skladište podataka je pripremljeno, formirano izlog, omogućilo je inkrementalno prikupljanje podataka (označavanje meta-atributima za naknadno isticanje delte promjena), a potrošački sistem potom sam kontroliše i odgovoran je za to kako koristi ovaj izlog. Ali postoje posebnosti: kada sistem nema aktivnu komponentu za prikupljanje podataka - ili je potrebna eksterna komponenta koja će obavljati integracijsku funkciju, ili će skladište djelovati kao "integraciona platforma" - i osigurava ispravne inkrementalne podatke otpremajte dalje - izvan skladišta. Ovdje se pojavljuju mnoge nijanse, a pravila interakcije interfejsa moraju biti osmišljena i shvaćena od obje strane (međutim, kao i uvijek, kada je u pitanju integracija). U pravilu, rutinsko čišćenje/arhiviranje podataka se primjenjuje na takve baze podataka (rijetko je potrebno da se ovi "tranzitni podaci" čuvaju duže vrijeme).

Najvažniji sa stanovišta analitičkih zadataka su vitrine „za ljude“ – tačnije za BI alate sa kojima rade.
Međutim, postoji kategorija "posebno naprednih korisnika" - analitičara, naučnika podataka - kojima nisu potrebni BI alati ili regulatorni procesi za popunjavanje eksternih specijalizovanih sistema. Potrebni su im neka vrsta "zajedničkih izloga" i "njihov pješčanik", gdje mogu kreirati tabele i transformacije po svom nahođenju. U ovom slučaju, odgovornost repozitorija je da osigura da ovi zajednički izlozi budu ispunjeni podacima u skladu sa propisima.
Zasebno, možemo istaći takve potrošače kao Data Mining alati - duboka analiza podataka. Ovi alati imaju svoje zahtjeve za pripremu podataka, a sa njima rade i naučnici podataka. Za skladištenje, zadatak se svodi na - opet, da podrži servis za učitavanje nekih izloga dogovorenog formata.

Međutim, da se vratimo na analitičke vitrine. To su oni koji su od interesa sa stanovišta dizajnera skladišta u ovom sloju podataka.
Po mom mišljenju, najbolji vremenski testiran pristup dizajniranju data marta, na koji su sada "naoštrene" skoro sve BI platforme, jeste pristup Ralpha Kimballa. Poznato je kao dimenzionalno modeliranje - višedimenzionalno modeliranje. Postoji mnogo publikacija na ovu temu. Na primjer, osnovna pravila mogu se naći u publikaciji Marge Ross. I naravno, možete preporučiti od gurua multidimenzionalnog modeliranja. Još jedan koristan izvor su Kimballovi savjeti
Višedimenzionalni pristup kreiranju izloga je tako dobro opisan i razrađen - kako od strane "evanđelista metoda" tako i od strane vodećih proizvođača softvera, da nema smisla zadržavati se na njemu detaljnije - izvorni izvor je uvijek poželjniji .

Želeo bih da stavim samo jedan naglasak. "Izvještavanje i analitika" je drugačije. Postoji “teško izvještavanje” – unaprijed naručeni izvještaji koji se generišu u obliku fajlova i isporučuju korisnicima putem predviđenih kanala isporuke. A tu su i kontrolne table - BI kontrolne table. U svojoj osnovi, to su web aplikacije. A vrijeme odziva ovih aplikacija je isto kao i za bilo koju drugu web aplikaciju. To znači da je normalno vrijeme za osvježavanje BI panela sekunde, a ne minute. Važno je to imati na umu kada dizajnirate svoje rješenje. Kako se to može postići? Standardna metoda optimizacije: gledamo od čega se sastoji vrijeme odziva i na šta možemo utjecati. Šta je najviše izgubljenog vremena? Za fizička (disk) očitavanja baze podataka, za prijenos podataka preko mreže. Kako smanjiti količinu podataka koji se čitaju i prenose u jednom zahtjevu? Odgovor je očigledan i jednostavan: trebate ili agregirati podatke, ili primijeniti filter na velike tabele stvarnih tabela koje učestvuju u upitu i isključiti spajanje velikih tabela (reference na tabele činjenica treba da prolaze samo kroz dimenzije).

Čemu služi BI? Kako je to zgodno? Zašto je multidimenzionalni model efikasan?
BI omogućava korisniku da pokrene ono što se naziva ad hoc upitima. Šta to znači? To znači da ne znamo tačan zahtjev unaprijed, ali znamo koje pokazatelje u kojim aspektima korisnik može zatražiti. Korisnik generira takav upit odabirom odgovarajućih BI filtera. A zadatak BI programera i dizajnera izloga je da obezbede takvu logiku aplikacije tako da se podaci ili filtriraju ili agregiraju, sprečavajući situaciju kada se traži previše podataka - i aplikacija "visi". Obično započinju sa agregiranim brojevima, zatim se zadubljuju u detaljnije podatke, ali usput instaliraju potrebne filtere.

Nije uvijek dovoljno samo izgraditi “pravu zvijezdu” i dobiti zgodnu strukturu za BI. Ponekad ćete morati negdje primijeniti denormalizaciju (dok se osvrćete na to kako će to utjecati na opterećenje), a negdje napraviti sekundarne izloge i agregate. Dodajte indekse ili projekcije negdje (ovisno o DBMS-u).

Tako se „pokušajem i greškom“ može dobiti struktura koja je optimalna za BI – koja će uzeti u obzir posebnosti kako DBMS-a tako i BI platforme, kao i zahtjeve korisnika za prezentacijom podataka.
Ako uzmemo podatke iz „jezgra“, onda će takva obrada izloga biti lokalne prirode, a da ni na koji način ne utiče na složenu obradu primarnih podataka dobijenih direktno iz izvornih sistema – mi samo „prebacujemo“ podatke u format pogodan za BI. I to možemo sebi priuštiti mnogo puta, na različite načine, u skladu sa različitim zahtjevima. Mnogo je lakše i brže to učiniti na podacima kernela nego prikupljati od "primarnih" (čija struktura i pravila, kao što znamo, također mogu "plutati").

Servisni sloj

Servisni sloj je odgovoran za implementaciju općih (servisnih) funkcija koje se mogu koristiti za obradu podataka u različitim slojevima skladištenja - upravljanje opterećenjem, upravljanje kvalitetom podataka, alati za dijagnostiku problema i praćenje itd.
Prisustvo ovog nivoa obezbeđuje transparentnost i strukturirane tokove podataka u skladištu.

Ovaj sloj uključuje dva područja za pohranu podataka:

• oblast metapodataka - koristi se za mehanizam kontrole učitavanja podataka;
• oblast kvaliteta podataka - za implementaciju off-line provjera kvaliteta podataka (tj. onih koji nisu direktno ugrađeni u ETL procese).

Možete organizirati proces upravljanja preuzimanjem na različite načine. Jedan od mogućih pristupa je sljedeći: cijeli skup tablica za skladištenje dijelimo na module. Modul može uključivati ​​tabele samo jednog sloja. Tabele uključene u svaki modul se učitavaju u posebnom procesu. Nazovimo to proces kontrole ... Početak kontrolnog procesa je postavljen prema vlastitom rasporedu. Kontrolni proces orkestrira pozive atomskim procesima, od kojih svaki učitava jednu ciljnu tabelu, a sadrži i neke opšte korake.
Očigledno, dovoljno je jednostavno podijeliti scenske tabele u module - po izvornim sistemima, odnosno po njihovim tačkama povezivanja. Ali za kernel, ovo je već teže izvodljivo. tu moramo osigurati integritet podataka, što znači da moramo uzeti u obzir zavisnosti. One. doći će do sukoba koje treba riješiti. I postoje različite metode za njihovo rješavanje.

Važna tačka u upravljanju opterećenjem je razviti konzistentan pristup rukovanju greškama. Greške se klasifikuju prema njihovoj ozbiljnosti. Kada dođe do kritične greške, proces se mora zaustaviti, i to što je prije moguće, jer njegova pojava ukazuje na značajan problem koji može dovesti do oštećenja podataka u skladištu. Dakle, upravljanje opterećenjem nije samo pokretanje procesa, već i njihovo zaustavljanje, kao i sprečavanje neblagovremenog (greškom) pokretanja.

Za rad uslužnog sloja kreira se posebna struktura metapodataka. Ovo područje će pohraniti informacije o procesima učitavanja, učitanim skupovima podataka, kontrolnim tačkama koje se koriste za održavanje inkrementa (koji je proces pročitao do koje tačke) i druge informacije o uslugama koje su potrebne za funkcionisanje sistema.
Važno je napomenuti da su sve ciljne tabele u svim slojevima označene posebnim skupom meta-polja, od kojih je jedno identifikator procesa koji je ažurirao ovaj red. Za tabele unutar spremišta, ovo označavanje procesa omogućava dosljedan način naknadnog isticanja delte promjena. Prilikom učitavanja podataka u primarni sloj podataka, situacija je složenija - algoritam delta alokacije za različite učitane objekte može biti drugačiji. Ali logika obrade prihvaćenih izmjena i njihovog prebacivanja na ciljne tablice za jezgro i izloge je mnogo složenija nego za staging, gdje je sve prilično trivijalno - lako je parametrirati i razmišljati o standardnim koracima (procedurama) za višekratnu upotrebu.

Ovdje ne postavljam zadatak da u potpunosti pokrijem ovu temu - organiziranje preuzimanja - samo ističem naglaske na koje vrijedi obratiti pažnju.
Ovaj pristup je samo jedna od opcija. Prilično je osjetljiv. A njegov "konceptualni prototip" bio je Toyotin transporter i sistem "baš na vrijeme". One. ovdje se udaljavamo od raširene paradigme isključivo "noćnog preuzimanja podataka", a preuzimamo u malim porcijama tokom dana - čim podaci budu gotovi u raznim izvorima: što je došlo - to je skinuto. Istovremeno, imamo mnogo paralelnih procesa. A "vrući rep" svježih podataka će stalno "treptati" - i vremenom će se izjednačiti. Moramo uzeti u obzir takvu osobinu. I, ako je potrebno, formirajte prilagođene vitrine sa "kriškama", gdje je sve već holistički. One. nemoguće je istovremeno postići i efikasnost i konzistentnost (integritet). Potreban nam je balans – negde je jedna stvar važna, negde drugde.

Imperativ je osigurati objekte za sječu i nadzor. Dobra je praksa koristiti otkucane događaje, gdje možete podesiti različite parametre i prilagoditi sistem obavještavanja - pretplatiti se na određene događaje. Jer vrlo je važno da kada je potrebna intervencija sistem administratora, on to što prije sazna i dobije sve potrebne dijagnostičke informacije. Dnevnici se takođe mogu koristiti za analizu post-fakto problema, kao i za istraživanje incidenata kvarova u sistemu, uklj. kvalitet podataka.

Dizajniranje i održavanje modela podataka skladišta

Zašto je važno obratiti pažnju na dizajn modela podataka kada se razvija bilo koji sistem u kojem je uključena baza podataka (a posebno u skladištu)? Zašto jednostavno ne bacite skup tabela bilo gdje - čak i u uređivač teksta? Zašto su nam potrebne "ove slike"?
Čudno, čak i iskusni programeri postavljaju takva pitanja.
Zapravo, da, ništa vas ne sprečava da skicirate tabele - i počnete da ih koristite. Ako ... ako u isto vrijeme u glavi (!) Programer ima koherentnu opću sliku strukture koju vaja. Šta ako postoji nekoliko programera? Šta ako neko drugi koristi ove tabele? A šta ako vrijeme prođe - čovjek napusti ovo područje, pa se opet vrati u njega?

Možete li to shvatiti bez modela? U principu, možete. I da to shvatite, i "odlučite slike na komadu papira", i "obrišite - sredite" podatke. Ali mnogo je lakše, jasnije i brže koristiti gotov artefakt – model podataka. I također razumjeti "logiku njegovog uređaja" - tj. bilo bi dobro imati opšta pravila igre.

A najvažnije nije ni to. Najvažnije je da smo pri dizajniranju modela prinuđeni (samo bez opcija!) da pobliže i dublje proučimo predmetnu oblast, karakteristike uređaja za prenos podataka i njihovu upotrebu u različitim poslovnim slučajevima. A ona pitanja koja bismo lako „odgurnuli“ u stranu kao složena, „zamagljeni“ bacanjem naših znakova, ne pokušavajući da precizno dizajn model – bićemo primorani da isporučimo i odlučimo sada, prilikom analize i dizajna, a ne kasnije – kada budemo pravili izveštaje i razmišljali o tome „kako da smanjimo nespojivo” i „izmislimo točak” svaki put.

Ovaj pristup je jedna od onih inženjerskih praksi koja vam omogućava da kreirate anti-lomljive sisteme. Pošto su jasno raspoređeni, transparentni, pogodni za razvoj, a i njihove "granice krhkosti" su odmah vidljive - možete preciznije procijeniti "razmjere katastrofe" kada se pojave novi zahtjevi i vrijeme potrebno za redizajn (ako je potrebno).
Dakle, model podataka je jedan od glavnih artefakata koji se moraju održavati tokom razvoja sistema. Na prijateljski način, trebalo bi da bude "na stolu" svakog analitičara, programera itd. - svi koji učestvuju u projektima razvoja sistema.

Dizajniranje modela podataka je velika i zasebna tema. Postoje dva glavna pristupa dizajnu skladišta.
Pristup dobro funkcionira za kernel Entitet-odnos - kada se normalizovani (3NF) model gradi na osnovu proučavanja predmetne oblasti, tačnije, njene odabrane oblasti. Ovdje je u igri isti "korporativni model" o kojem smo gore govorili.

Pri dizajniranju vitrina je prikladan multidimenzionalni model ... Ovaj pristup se dobro uklapa u razumijevanje poslovnih korisnika – jer to je model koji je jednostavan i pogodan za ljudsku percepciju - ljudi operišu sa razumljivim i poznatim konceptima metrike (indikatora) i sekcija po kojima se analiziraju. A to vam omogućava da jednostavno i jasno izgradite proces prikupljanja zahtjeva - crtamo skup "matrica odjeljaka i indikatora", komunicirajući s predstavnicima različitih odjela. A onda to dovodimo u jednu strukturu - "model analize": formiramo "sabirnicu mjerenja" i definiramo činjenice koje su na njima definirane. Usput, radimo na hijerarhijama i pravilima agregacije.

Tada je vrlo lako prijeći na fizički model, dodajući elemente optimizacije uzimajući u obzir posebnosti DBMS-a. Na primjer, za Oracle bi to bilo particioniranje, skup indeksa, itd. Za Verticu će se koristiti i druge tehnike - sortiranje, segmentacija, sekcija.
Također, može biti potrebna posebna denormalizacija - kada namjerno unosimo redundantnost u podatke, zahvaljujući čemu poboljšavamo performanse upita, ali istovremeno komplikujemo ažuriranje podataka (pošto će se redundantnost morati uzeti u obzir i održavati tokom učitavanja podataka proces). Možda ćemo, da bismo poboljšali performanse, također morati kreirati dodatne agregatne tabele, ili koristiti takve dodatne DBMS karakteristike kao što su projekcije u Vertici.

Dakle, prilikom modeliranja skladišnih podataka, zapravo rješavamo nekoliko problema:

• zadatak izgradnje konceptualnog (logičkog) modela kernela – sistemske i poslovne analize – istraživanje predmetne oblasti, ulazak u detalje i uzimanje u obzir nijansi „živih podataka“ i njihove upotrebe u poslovanju;
• zadatak izgradnje modela analize - a zatim konceptualnog (logičkog) modela izloga;
• zadatak izgradnje fizičkih modela - upravljanje redundantnošću podataka, optimizacija uzimajući u obzir specifičnosti DBMS-a za upite i učitavanje podataka.

Prilikom razvoja konceptualnih modela, možda nećemo uzeti u obzir posebnosti određenog DBMS-a za koji dizajniramo strukturu baze podataka. Štaviše, možemo koristiti jedan konceptualni model za kreiranje nekoliko fizičkih - za različite DBMS.

Hajde da sumiramo.

• Model podataka nije skup "lijepih slika", a proces njegovog dizajniranja nije proces njihovog crtanja. Model odražava naše razumijevanje domena. A proces sastavljanja je proces njegovog proučavanja i istraživanja. Ovo je izgubljeno vrijeme. I nikako da "crtate i slikate".
• Model podataka je artefakt dizajna, način razmjene informacija na strukturiran način između članova tima. Da bi se to postiglo, mora biti svima jasno (ovo je dato notacijom i objašnjenjem) i dostupno (objavljeno).
• Model podataka se ne kreira jednom i zamrzava, već se kreira i razvija u procesu razvoja sistema. Pravila njegovog razvoja sami postavljamo. A možemo ih promijeniti ako vidimo – kako to učiniti bolje, lakše, efikasnije.
• Model podataka (fizički) vam omogućava da konsolidirate i iskoristite skup najboljih praksi usmjerenih na optimizaciju – tj. koristiti tehnike koje su već radile za ovaj DBMS.

Karakteristike projekata skladišta podataka

Hajde da se zadržimo na specifičnostima projekata u okviru kojih kompanija gradi i razvija skladišta podataka. A pogledajmo ih sa stanovišta uticaja arhitektonskog aspekta. Zašto je za ovakve projekte važno graditi arhitekturu, i to od samog početka? A upravo prisutnost dobro osmišljene arhitekture daje fleksibilnost projektu skladišta podataka, omogućava vam da efikasno distribuirate posao između izvođača, a također olakšava predviđanje rezultata i čini proces predvidljivijim.

Skladište podataka je prilagođeni softver

Skladište podataka je uvijek "prilagođeni razvoj", a ne upakirano rješenje. Da, postoje BI aplikacije specifične za industriju koje uključuju referentni model podataka, unaprijed konfigurirane ETL procese iz uobičajenih izvora (na primjer, ERP sistemi), skup standardnih BI panela i izvještaja. Ali u praksi, skladištenje se rijetko implementira - kao "kutija". Radim sa repozitorijumima oko 10 godina i nikada nisam video takvu priču. Uvijek postoje neke nijanse povezane s jedinstvenim karakteristikama kompanije - i poslovnom i IT okruženjem. Stoga je pomalo nepromišljeno nadati se da će arhitekturu obezbijediti "prodavac" koji isporučuje rješenje. Arhitektura takvih sistema često „sazreva“ unutar same organizacije. Ili ga formiraju stručnjaci kompanije izvođača, koja je glavni izvođač projekta.

Skladište podataka je integracijski projekat

Skladište podataka učitava i obrađuje informacije iz mnogih izvornih sistema. A da biste održali "prijateljske odnose" s njima, morate biti izuzetno oprezni s njima. Konkretno, potrebno je minimizirati opterećenje izvornih sistema, uzeti u obzir prozore "dostupnost i nedostupnost", odabrati interfejse za interakciju uzimajući u obzir njihovu arhitekturu itd. Tada će skladište moći da preuzme podatke što je prije moguće i potrebnom frekvencijom. U suprotnom ćete biti "transplantirani" u rezervno kolo, koje se ne ažurira na najoperativnijoj frekvenciji.
Osim toga, potrebno je uzeti u obzir i "ljudski faktor". Integracija se ne odnosi samo na interakciju mašina. To je i komunikacija među ljudima.

Skladište podataka je zajednički projekat

U velikoj kompaniji ovakav sistem retko može da uradi samo jedan tim. U pravilu ovdje radi nekoliko timova, od kojih svaki rješava određeni problem.

Arhitektura treba da obezbedi mogućnost organizovanja njihovog paralelnog rada, uz zadržavanje integriteta i izbegavanje dupliranja iste funkcionalnosti na različitim mestima, od strane različitih ljudi. Pored nepotrebnog napora, takvo dupliranje može kasnije dovesti do neslaganja podataka.

Osim toga, kada je toliko ljudi i timova, često raštrkanih, uključeno u razvoj sistema, neminovno se postavlja pitanje: kako izgraditi komunikaciju i informacijsku interakciju između njih. Što se više standardnih i razumljivih pristupa i praksi koristi, to je lakše, praktičnije i efikasnije organizovati takav rad. I, između ostalog, vrijedi razmisliti o sastavu "radnih artefakata", među kojima su za skladišta podataka broj 1 modeli podataka (vidi prethodni odjeljak).

Skladište podataka ima duži vijek trajanja od ostalih sistema

Da pojasnimo - izjava je tačna za "živo", radno skladište, integrisano sa ključnim izvorima, koje poseduje istorijske podatke i pruža informacije i analitičke usluge mnogim divizijama kompanije.

Šta ja imam razloga da tako vjerujem?
Prvo, izgradnja skladišta je proces koji zahtijeva velike resurse: osim stvarnih troškova opreme, licenci za neophodan tehnološki softver i razvoj, u to su uključeni i gotovo svi sistemi i odjeli kompanije. Ponoviti cijeli ovaj proces od nule još jednom je vrlo odvažna ideja.

Drugo, ako skladište ima ispravnu arhitekturu, onda prilično lako može preživjeti promjene izvornih sistema, i pojavu novih zahtjeva krajnjih korisnika, i rast volumena podataka.
Ako je arhitektura ispravna, tokovi informacija transparentni, onda se takav sistem može razvijati dugo vremena bez rizika da se zaglavi u situaciji prilikom unošenja promjena zbog poteškoća u procjeni uticaja.

Postepeni iterativni razvoj

Posljednje što bi Kupac želio, upuštajući se u priču sa repozitorijumom, jeste da zamrzne svoje zahtjeve na godinu-dvije, dok se ne osmisli kompletan korporativni model podataka, ne povežu svi izvori u potpunosti itd.

U očima kupaca, skladište podataka često izgleda kao apsolutno čudovište - zadaci, ciljevi i horizont razvoja sistema su tako obimni. I često se kupac boji da će "na račun svog budžeta" IT odjel riješiti neke "njihove probleme". I opet se suočavamo sa pitanjem interakcije među ljudima i sposobnosti da mirno iznesemo svoj stav i pregovaramo.

Kompetentni arhitektonski pristupi omogućavaju vam da razvijate sistem iterativno, postepeno povećavajući funkcionalnost, bez odlaska u "razvoj" nekoliko godina prije nego što počnete davati rezultat.

Iako treba napomenuti da se "čuda ne dešavaju" - a za "početak" takođe treba vremena. Što se tiče skladišta, to može biti prilično veliko – pošto se radi o velikim količinama podataka, to su istorijski podaci – za stara razdoblja, kada su se pravila obrade informacija mogla razlikovati od sadašnjih. Stoga je potrebno dovoljno vremena za analitički rad, interakciju sa izvornim sistemima i niz "pokušaja i grešaka", uključujući testove opterećenja na stvarnim podacima.

Skladišta podataka - "višeprojektna priča"

Teško je izdvojiti jednog poslovnog korisnika za skladište podataka. I vjeruje se (ne bez razloga) da je ključni faktor uspjeha projekta izgradnje skladišta podrška menadžmenta kompanije – direktno prve osobe.
Repozitorij se rijetko gradi i razvija kao dio jednog projekta. Obično postoje različite potrebe za konsolidacijom podataka i analitikom, iza njih stoje različiti kupci i korisničke grupe. Stoga se repozitorijum često razvija u okviru nekoliko paralelnih projekata.

Balans inovacija i dokazanih rješenja

Unatoč činjenici da je tema skladištenja vrlo "drevna" (ako je takva riječ primjenjiva za tako mladu industriju kao što je IT) i prilično konzervativna. Ipak, napredak ne miruje - i ona ograničenja koja su ranije postojala zbog skupih i sporih diskova, skupe memorije itd. - su sada uklonjeni. Istovremeno, došlo je vrijeme da se revidiraju neki od arhitektonskih pristupa. Štaviše, ovo se odnosi i na tehnološke platforme i na arhitekturu primenjenih sistema koji se na njima zasnivaju.

Ovdje je važno uspostaviti ravnotežu - i održavati prilično „zeleni“ pristup i resursima i pohranjenim informacijama. Inače, skladište možete vrlo brzo pretvoriti u polustrukturiranu "deponiju", u kojoj će, ako će se to moći shvatiti, onda uz dosta truda.
Da, imamo više mogućnosti, ali to ne znači da treba da negiramo sve nagomilane i vremenski provjerene prakse, koje je jasno kako i zašto koristiti, i "poći sve loše" samo vođene maglovitim duhom " inovacije“.
Održavanje ravnoteže znači korištenje novih metoda i pristupa gdje otvaraju nove mogućnosti, ali istovremeno korištenje starih dokazanih - za rješavanje hitnih problema koji nisu otkazani.
Šta možemo učiniti kao programeri i dizajneri aplikativnih rješenja? Prije svega, da poznajemo i razumijemo tehnološke promjene platformi na kojima radimo, njihove mogućnosti, karakteristike i granice primjene.

Pogledajmo DBMS kao najkritičniju i najvažniju tehnološku platformu za skladištenje podataka.
Nedavno je došlo do jasnog pomjeranja relacijskih baza podataka, stvorenih u početku kao "univerzalne", prema specijalizaciji. Već duže vrijeme vodeći proizvođači objavljuju različite opcije - za aplikacije različitih klasa (OLTP, DSS & DWH). Osim toga, pojavljuju se dodatne mogućnosti za rad s tekstom, geo-podacima itd.

Ali to nije bio kraj - počeli su se pojavljivati ​​proizvodi koji su u početku bili usmjereni na određenu klasu zadataka, tj. specijalizovani DBMS. Oni mogu ili ne moraju koristiti relacijski model. Važno je da su u početku "naoštreni" ne samo za pohranjivanje i obradu "poslovnih informacija" općenito, već i za specifične zadatke.

Očigledno, centralizacija i specijalizacija su dva komplementarna trenda koji povremeno zamjenjuju jedan drugog, osiguravajući razvoj i ravnotežu. Kao i evolucijski (postepeni) postepeni razvoj i kardinalne promjene. Na primjer, 90-ih je Michael Stonebreaker bio jedan od autora Manifesta baza podataka generacije III, koji je jasno izrazio ideju da svijetu ne treba još jedna revolucija u svijetu baza podataka. Međutim, 10 godina kasnije objavljuje radove u kojima najavljuje preduslove za početak nove ere u svijetu DBMS-a – na osnovu njihove specijalizacije.
Fokusira se na činjenicu da su uobičajeni univerzalni DBMS-ovi izgrađeni na arhitekturi "jedna veličina za sve", koja ne uzima u obzir ni promjene hardverskih platformi ni podelu aplikacija na klase za koje možete smisliti više optimalno rješenje od implementacije univerzalnih zahtjeva.
I počinje razvijati niz projekata u skladu s tom idejom. Jedan od njih - C-Store - je stupasti DBMS dizajniran u arhitekturi shared nothing (SN), originalno kreiran posebno za sisteme klase skladišta podataka. Ovaj proizvod je tada bio na tržištu kao HP Vertica.

Čini se da je sada tema razvoja skladišta podataka skliznula u novu fazu razvoja. Pojavljuju se nove tehnologije, pristupi i alati. Njihovo proučavanje, testiranje i inteligentna primjena omogućavaju nam da kreiramo zaista zanimljiva i korisna rješenja. I dovedite ih do implementacije, uživajući u činjenici da se vaši razvoji koriste u stvarnom radu i da su korisni.

Epilog

Pripremajući ovaj članak, pokušao sam da se fokusiram prvenstveno na arhitekte, analitičare i programere koji direktno rade sa skladištima podataka. No, pokazalo se da je neizbježno "malo proširila temu" - a u vidno polje su pale i druge kategorije čitatelja. Neke stvari će izgledati kontroverzne, neke nisu jasne, neke su očigledne. Ljudi su različiti – različitog porijekla, porijekla i položaja.
Na primjer, tipična menadžerska pitanja su "kada zaposliti arhitekte?", "Kada se baviti arhitekturom?" zvuči za nas (programere, dizajnere) prilično čudno, jer za nas se arhitektura sistema pojavljuje sa njegovim rođenjem – nije bitno da li smo toga svjesni ili ne. Čak i ako ne postoji formalna uloga arhitekte u projektu, normalni programer uvijek „uključuje svog internog arhitektu“.

Uglavnom, nije bitno ko tačno obavlja ulogu arhitekte – važno je da neko postavlja slična pitanja i istražuje odgovore. Ako je arhitekta jasno izdvojen, to samo znači da je on prvenstveno odgovoran za sistem i njegov razvoj.
Zašto sam smatrao da je tema "antifragilnosti" relevantna za ovu temu?

"Jedinstvenost antifragilnosti je u tome što nam omogućava da radimo sa nepoznatim, da uradimo nešto u uslovima kada ne razumemo šta tačno radimo i da postignemo uspeh."/ Nassim N. Talb /

Dakle, kriza i visok stepen neizvjesnosti nisu izgovor za odsustvo arhitekture, već faktori koji pojačavaju njenu potrebu.

Zaitsev S.L., Ph.D.

Grupe koje se ponavljaju

Duplicirane grupe su atributi za koje jedna instanca entiteta može imati više od jedne vrijednosti. Na primjer, osoba može imati više od jedne vještine. Ako, u smislu poslovnih zahtjeva, moramo znati nivo vještina za svaku, a svaka osoba može imati samo dvije vještine, možemo kreirati entitet prikazan na Sl. 1.6. Evo entiteta OSOBA sa dva atributa za pohranjivanje vještina i nivoom vještina za svaki.

Rice. 1.6. Ovaj primjer koristi grupe koje se ponavljaju.

Problem sa ponavljanjem grupa je taj što ne možemo tačno znati koliko vještina osoba može imati. U stvarnom životu, neki ljudi imaju jednu vještinu, neki nekoliko, a neki još nemaju nijednu. Na slici 1.7 prikazan je model svedeni na prvi normalni oblik. Obratite pažnju na dodano ID vještine koje svaki jedinstveno identifikuje VJEŠTINA.

Rice. 1.7. Model je reduciran na prvu normalnu formu.

Jedna činjenica na jednom mestu

Ako je isti atribut prisutan u više od jednog entiteta i nije strani ključ, onda se ovaj atribut smatra redundantnim. Logički model ne bi trebao sadržavati suvišne podatke.

Redundantnost zahtijeva dodatni prostor, ali iako je efikasnost memorije važna, pravi problem leži negdje drugdje. Osiguravanje da su redundantni podaci sinhronizirani je prekomjerno, i uvijek riskirate konfliktne vrijednosti.

U prethodnom primjeru VJEŠTINA zavisi od ID osobe i od ID vještine. To znači da nećete imati VJEŠTINA dok se ne pojavi OSOBA, posedovanje ove veštine. Ovo također otežava promjenu naziva vještine. Potrebno je pronaći svaki unos sa Nazivom vještine i promijeniti ga za svaku osobu koja posjeduje ovu vještinu.

Slika 1.8 prikazuje model u drugom normalnom obliku. Imajte na umu da je dodani entitet VJEŠTINA, i atribut TITLE vještina se prenosi na ovaj entitet. Nivo vještina ostao je, odnosno, na raskrsnici OSOBE i VJEŠTINA.

Rice. 1.8. U drugom normalnom obliku, ponavljajuća grupa se premješta u drugi entitet. Ovo pruža fleksibilnost za dodavanje potrebnog broja vještina i promjenu naziva vještine ili opisa vještine na jednom mjestu.

Svaki atribut zavisi od ključa

Svaki atribut entiteta mora zavisiti od primarnog ključa tog entiteta. U prethodnom primjeru Ime škole i Geografsko područje prisutna u tabeli OSOBA ali ne opisivati ​​osobu. Da biste postigli treći normalni oblik, trebate premjestiti atribute u entitet, gdje će ovisiti o ključu. Slika 1.9. prikazuje model u trećem normalnom obliku.

Rice. 1.9. U trećem normalnom obliku Ime škole i Geografska regija prenijeti na entitet, gdje njihove vrijednosti zavise od ključa.

Odnosi mnogo-na-mnogo

Veza mnogo-prema-mnogima odražavaju stvarnost okolnog svijeta. Imajte na umu da na slici 1.9 postoji odnos više prema mnogo PERSONOUS i ŠKOLA... Stav tačno odražava činjenicu da OSOBA mogu studirati na mnogim ŠKOLE i u ŠKOLA može mnogo naučiti OSOBA. Da bi se postigla četvrta normalna forma, kreira se asocijativni entitet koji eliminiše odnos monogija prema mnogima generisanjem posebnog unosa za svaku jedinstvenu kombinaciju škole i osobe. Slika 1.10 prikazuje model u četvrtom normalnom obliku.

Rice. 1.10. U četvrtom normalnom obliku, odnos monogo-prema-mnogo između PERSONOUS i ŠKOLA riješeno uvođenjem asocijativnog entiteta, u kojem se za svaku jedinstvenu kombinaciju dodjeljuje poseban unos ŠKOLE i OSOBE.

Formalne definicije normalnih oblika

Sljedeće definicije normalnih oblika mogu izgledati zastrašujuće. Zamislite ih jednostavno kao formule za postizanje normalizacije. Normalni oblici su zasnovani na relacionoj algebri i mogu se tumačiti kao matematičke transformacije. Iako ova knjiga nije posvećena detaljnoj raspravi o normalnim oblicima, modeleri se ohrabruju da dublje pogledaju tu temu.

U datoj relaciji R, Y atribut funkcionalno ovisi o atributu X. U simboličkom obliku, RX -> RY (čita se kao "RX funkcionalno definira RY") - ako i samo ako je svaka vrijednost X u R pridružena tačno jednoj vrijednost Y u R (u bilo kojem trenutku). Atributi X i Y mogu biti složeni (Datum CJ. Uvod u sisteme baza podataka. 6. izdanje. Ed. Williams: 1999, 848 str.).

Relacija R odgovara prvom normalnom obliku (1NF) ako i samo ako svi domeni koji joj pripadaju sadrže samo atomske vrijednosti (Datum, ibid.).

Relacija R odgovara drugom normalnom obliku (2NF) ako i samo ako odgovara 1NF, a svaki atribut koji nije ključ u potpunosti zavisi od primarnog ključa (Datum, ibid.).

Relacija R odgovara trećem normalnom obliku (3NF) ako i samo ako odgovara 2NF, a svaki neključni atribut ne zavisi tranzitivno od primarnog ključa (Datum, ibid.).

Relacija R odgovara Boyes-Codd normalnom obliku (BCNF) ako i samo ako je svaka determinanta kandidat za upotrebu kao ključ.

BILJEŠKA Ispod je kratko objašnjenje nekih skraćenica korištenih u Dateovim definicijama.

MVD (viševrednosna zavisnost) je zavisnost sa više vrednosti. Koristi se samo za entitete sa tri ili više atributa. U zavisnosti od više vrijednosti, vrijednost atributa ovisi samo o dijelu primarnog ključa.

FD (funkcionalna zavisnost) - funkcionalna zavisnost. Kod funkcionalne ovisnosti, vrijednost atributa ovisi o vrijednosti drugog atributa koji nije dio primarnog ključa.

JD (zavisnost spajanja) je zavisnost spajanja. Sa zavisnošću od unije, primarni ključ roditeljskog entiteta se prati do najmanje potomaka trećeg nivoa, uz zadržavanje mogućnosti da ga originalni ključ koristi u uniji.

Omjer odgovara četvrtom normalnom obliku (4NF) ako i samo ako postoji MVD u R, na primjer A®®B. U ovom slučaju, svi atributi R funkcionalno zavise od A. Drugim riječima, u R postoje samo ovisnosti (FD ili MVD) oblika K®X (tj. funkcionalna ovisnost atributa X od kandidata za upotrebu kao ključ K). Shodno tome, R ispunjava zahtjeve 4NF ako je u skladu sa BCNF-om i svi MVD-ovi su zapravo FD-ovi (Datum, ibid.).

Za peti normalni oblik, relacija R zadovoljava zavisnost unije (JD) * (X, Y,…, Z) ako i samo ako je R ekvivalentan svojim projekcijama na X, Y, ..., Z, gdje je X, Y , .., Z je podskup skupa atributa R.

Postoje mnoge druge normalne forme za složene tipove podataka i specifične situacije koje su izvan okvira ove rasprave. Svaki entuzijasta za razvoj modela želio bi naučiti i druge normalne forme.

Normalni oblici poslovanja

U svojoj knjizi, Clive Finklestein (An Introduction to Information Engineering: From Strategic Planning to Information Systems. Reading, Massachusetts: Addison-Wesley, 1989) je zauzeo drugačiji pristup normalizaciji. On definiše normalne poslovne forme u smislu prinude na te forme. Mnogi modelari smatraju ovaj pristup intuitivnijim i pragmatičnijim.

Prvi poslovni normalni oblik (1BNF) prenosi ponavljajuće grupe u drugi entitet. Ovaj entitet dobija svoje ime i atribute primarnog (kompozitnog) ključa od originalnog entiteta i njegove ponavljajuće grupe.

Drugi poslovni normalni oblik (2BNF) uklanja atribute koji su djelomično zavisni od primarnog ključa drugom entitetu. Primarni (kompozitni) ključ ovog entiteta je primarni ključ entiteta u kojem se prvobitno nalazio, zajedno sa dodatnim ključevima od kojih atribut u potpunosti zavisi.

Treći poslovni normalni oblik (3BNF) preuzima atribute koji su nezavisni od primarnog ključa u drugi entitet, gdje su potpuno zavisni od primarnog ključa tog entiteta.

Četvrti poslovni normalni oblik (4BNF) uzima atribute koji zavise od vrijednosti primarnog ključa ili su opcioni za sekundarni entitet, gdje u potpunosti zavise od vrijednosti primarnog ključa, ili gdje moraju (nužno) biti prisutni u tom entiteta.

Peti poslovni normalni oblik (5BNF) pojavljuje se kao strukturni entitet ako postoji rekurzivna ili druga zavisnost između instanci sekundarnog entiteta, ili ako postoji rekurzivna zavisnost između instanci njegovog primarnog entiteta.

Završen logički model podataka

Završeni logički model mora zadovoljiti zahtjeve trećeg poslovnog normalnog oblika i uključivati ​​sve entitete, atribute i odnose potrebne za podršku zahtjevima podataka i poslovnim pravilima povezanim s podacima.

Svi entiteti moraju imati nazive koji opisuju njihov sadržaj i imaju jasan, sažet, potpun opis ili definiciju. Buduća objava će pokriti početni set smjernica za ispravno formiranje naziva i opisa entiteta.

Entiteti moraju imati kompletan skup atributa, tako da svaka činjenica o svakom entitetu može biti predstavljena njegovim atributima. Svaki atribut mora imati ime koje odražava njegovo značenje, Boolean tip podataka i jasan, kratak, potpun opis ili definiciju. U budućem blog postu ćemo pogledati početni skup smjernica za pravilno formatiranje imena i opisa atributa.

Odnosi treba da sadrže glagolsku konstrukciju koja opisuje odnos između entiteta, zajedno sa karakteristikama kao što su množina, neophodnost postojanja ili mogućnost odsustva veze.

BILJEŠKA Pluralitet odnos opisuje maksimalni broj sekundarnih instanci entiteta koji se mogu pridružiti instanci originalnog entiteta.Nužnost postojanja ilimogućnost odsustva odnos se koristi za određivanje minimalnog broja instanci sekundarnog entiteta koji se može povezati sa instancom originalnog entiteta.

Fizički model podataka

Kada kreirate kompletan i adekvatan logički model, spremni ste da donesete odluku o izboru platforme za implementaciju. Izbor platforme zavisi od zahteva za korišćenjem podataka i strateških principa oblikovanja arhitekture korporacije. Odabir platforme je složeno pitanje izvan okvira ove knjige.

U ERwin-u, fizički model je grafički prikaz baze podataka iz stvarnog svijeta. Fizička baza podataka će se sastojati od tabela, kolona i relacija. Fizički model ovisi o odabranoj platformi za implementaciju i zahtjevima za korištenje podataka. Fizički model za IMS će se veoma razlikovati od onog za Sybase. Fizički model za OLAP izvještaje će izgledati drugačije od modela za OLTP (online obrada transakcija).

Modelar podataka i administrator baze podataka (DBA) koriste logički model, zahtjeve za korištenje i politiku korporativne arhitekture za razvoj fizičkog modela podataka. Možete denormalizirati fizički model kako biste poboljšali performanse i kreirali poglede koji podržavaju zahtjeve za korištenje. Sljedeći odjeljci detaljno opisuju proces denormalizacije i kreiranja pogleda.

Ovaj odjeljak pruža pregled procesa izgradnje fizičkog modela, prikupljanja zahtjeva za korištenjem podataka, definiranja komponenti fizičkog modela i pružanja obrnutog inženjeringa. U sljedećim publikacijama ova pitanja su detaljnije obrađena.

Zahtjevi za prikupljanje podataka

Obično prikupljate zahtjeve za korištenje podataka rano tokom intervjua i radnih sesija. Istovremeno, zahtjevi bi trebali što potpunije odrediti korištenje podataka od strane korisnika. Površni stav i praznine u fizičkom modelu mogu dovesti do neplaniranih troškova i kašnjenja u implementaciji projekta. Zahtjevi za korištenje uključuju:

Zahtjevi za pristup i performanse

Volumetrijske karakteristike (procjena količine podataka koje treba pohraniti) koje omogućavaju administratoru da predstavi fizički volumen baze podataka

Procjena broja korisnika kojima je potreban istovremeni pristup podacima koji će vam pomoći da dizajnirate svoju bazu podataka za prihvatljive razine performansi

Agregati, pivotovi i drugi izračunati ili izvedeni podaci koji se mogu smatrati kandidatima za pohranu u trajnim strukturama podataka

Zahtjevi za izvještavanje i standardni upiti koji pomažu administratoru baze podataka da izgradi indekse

Pogledi (trajni ili virtuelni) koji će pomoći korisniku prilikom izvođenja operacija agregiranja podataka ili filtriranja.

Pored predsjedavajućeg, sekretara i korisnika, modelar, administrator baze podataka i arhitekta baze podataka moraju učestvovati u sesiji zahtjeva za korištenje. Trebalo bi razgovarati o korisničkim zahtjevima za historijskim podacima. Dužina vremena zadržavanja podataka ima značajan uticaj na veličinu baze podataka. Često se stariji podaci pohranjuju u generaliziranom obliku, a atomski podaci se arhiviraju ili brišu.

Korisnici bi trebali donijeti primjere zahtjeva i izvještaja sa sobom na sesiju. Izvještaji moraju biti striktno definirani i moraju uključivati ​​atomske vrijednosti koje se koriste za sva polja sažetka i sažetka.

Komponente modela fizičkih podataka

Komponente fizičkog modela podataka su tabele, kolone i relacije. Entiteti logičkog modela će vjerovatno postati tabele u fizičkom modelu. Logički atributi postaju kolone. Logički odnosi će postati ograničenja integriteta odnosa. Neki logički odnosi se ne mogu implementirati u fizičku bazu podataka.

Obrnuti inženjering

Kada logički model nije dostupan, postaje potrebno ponovo kreirati model iz postojeće baze podataka. U ERwin-u se ovaj proces naziva obrnuti inženjering. Obrnuti inženjering se može izvesti na nekoliko načina. Modelar može istražiti strukture podataka u bazi podataka i ponovo kreirati tabele u okruženju vizuelnog modeliranja. Možete uvesti jezik definicija podataka (DDL) u alat koji podržava obrnuti inženjering (kao što je Erwin). Napredni alati kao što je ERwin uključuju funkcije koje pružaju ODBC komunikaciju sa postojećom bazom podataka za kreiranje modela direktnim čitanjem struktura podataka. O obrnutom inženjeringu sa ERwin-om će se detaljno raspravljati u narednom postu.

Korištenje korporativnih funkcionalnih granica

Prilikom izgradnje logičkog modela za modelara, važno je osigurati da je novi model konzistentan s korporativnim modelom. Korištenje korporativnih funkcionalnih granica znači modeliranje podataka u terminima koji se koriste unutar korporacije. Način na koji se podaci koriste u korporaciji mijenja se brže od samih podataka. U svakom logičkom modelu podaci moraju biti predstavljeni na holistički način, bez obzira na poslovnu domenu koju podržava. Entiteti, atributi i odnosi moraju definirati poslovna pravila na nivou korporacije.

BILJEŠKA Neke od mojih kolega ove korporativne funkcionalne granice nazivaju modeliranjem u stvarnom svijetu. Modeliranje u stvarnom svijetu ohrabruje modelara da sagleda informacije u smislu njihovih stvarno inherentnih odnosa i odnosa.

Korištenje korporativnih funkcionalnih granica za model podataka koji je na odgovarajući način konstruiran daje osnovu za podršku informacijskim potrebama bilo kojeg broja procesa i aplikacija, što omogućava korporaciji da efikasnije eksploatiše jednu od svojih najvrednijih sredstava – informacije.

Šta je model podataka preduzeća?

Model podataka preduzeća (EDM) sadrži entitete, atribute i odnose koji predstavljaju informacijske potrebe korporacije. EDM se obično kategorizira prema predmetnim oblastima, koje predstavljaju grupe subjekata vezanih za podršku specifičnim poslovnim potrebama. Neka predmetna područja mogu pokrivati ​​specifične poslovne funkcije kao što je upravljanje ugovorima, dok druga mogu uključivati ​​entitete koji opisuju proizvode ili usluge.

Svaki logički model mora odgovarati postojećoj domeni korporativnog modela podataka. Ako logički model ne ispunjava ovaj zahtjev, mora mu se dodati model domene. Ovo poređenje osigurava da je korporativni model poboljšan ili prilagođen i da su svi napori logičkog modeliranja koordinirani unutar korporacije.

EDM također uključuje specifične entitete koji definiraju opseg vrijednosti za ključne atribute. Ovi entiteti nemaju roditelje i definisani su kao nezavisni. Nezavisni entiteti se često koriste za održavanje integriteta odnosa. Ovi entiteti su identificirani s nekoliko različitih imena kao što su tablice kodova, referentne tablice, tablice tipova ili tablice klasifikacije. Koristićemo termin „korporativni poslovni objekat“. Poslovni objekat preduzeća je entitet koji sadrži skup vrednosti atributa koji su nezavisni od bilo kog drugog entiteta. Korporativni poslovni objekti treba da se koriste dosljedno unutar korporacije.

Izgradnja korporativnog modela podataka povećanjem

Postoje organizacije u kojima je korporativni model izgrađen od početka do kraja kao rezultat jednog zajedničkog napora. S druge strane, većina organizacija gradi prilično potpune korporativne modele tako što se povećava.

Graditi znači graditi nešto uzastopno, sloj po sloj, baš kao što kamenica raste biser. Svaki kreirani model podataka daje doprinos formiranju EDM-a. Izgradnja EDM-a na ovaj način zahtijeva dodatne korake modeliranja za dodavanje novih struktura podataka i domena ili povećanje postojećih struktura podataka. Ovo omogućava izgradnju poslovnog modela podataka povećanjem, iterativnim dodavanjem nivoa detalja i prefinjenosti.

Koncept metodologije modeliranja

Postoji nekoliko metodologija vizualnog modeliranja podataka. ERwin podržava dva:

IDEF1X (Definicija integracije za informaciono modeliranje – integrisani opis informacionih modela).

IE (Informacioni inženjering).

IDEF1X je dobra metodologija i upotreba njene notacije je široko rasprostranjena

Integrirani opis informacionih modela

IDEF1X je visoko strukturirana metodologija modeliranja podataka koja proširuje IDEF1 metodologiju usvojenu kao FIPS (Federalni standardi za obradu informacija) standard. IDEF1X koristi visoko strukturirani skup tipova konstrukcija za modeliranje i rezultira modelom podataka koji zahtijeva razumijevanje fizičke prirode podataka prije nego što takve informacije mogu biti dostupne.

Kruta struktura IDEF1X prisiljava modelara da dodijeli karakteristike entitetima koji možda ne odgovaraju stvarnosti okolnog svijeta. Na primjer, IDEF1X zahtijeva da svi podtipovi entiteta budu isključivi. To dovodi do činjenice da osoba ne može biti i klijent i zaposlenik. Dok nam prava praksa govori drugačije.

Informacioni inženjering

Clive Finklestein se često naziva ocem informatičkog inženjeringa, iako je slične koncepte s njim dijelio i James Martin (Martin, James. Managing the Database Environment. Upper Saddle River, New Jersey: Prentice Hall, 1983.). Informacioni inženjering koristi poslovni pristup upravljanju informacijama i koristi drugačiju notaciju za predstavljanje poslovnih pravila. IE služi kao proširenje i razvoj notacije i osnovnih koncepata ER metodologije koju je predložio Peter Chen.

IE obezbeđuje infrastrukturu za podršku zahtevima za informacijama integracijom korporativnog strateškog planiranja sa informacionim sistemima koji se razvijaju. Ova integracija omogućava da upravljanje informacionim resursima bude bliže usklađeno sa dugoročnim strateškim izgledima korporacije. Ovaj poslovni pristup doveo je mnoge modelere da izaberu IE u odnosu na druge metodologije koje se fokusiraju na kratkoročne razvojne izazove.

IE predlaže niz radnji koje vode korporaciju da identifikuje sve njene potrebe za informacijama za prikupljanje i upravljanje podacima i identifikaciju odnosa između informacionih objekata. Kao rezultat, zahtjevi za informacijama su jasno artikulisani na osnovu direktiva upravljanja i mogu se direktno prevesti u upravljački informacioni sistem koji će podržati potrebe za strateškim informacijama.

Zaključak

Razumijevanje kako koristiti alat za modeliranje podataka kao što je ERwin samo je dio problema. Osim toga, morate razumjeti kada se rješavaju zadaci modeliranja podataka i kako se prikupljaju zahtjevi za informacijama i poslovna pravila koja bi trebala biti predstavljena u modelu podataka. Provođenje radnih sesija pruža najpovoljnije okruženje za prikupljanje zahtjeva za informacijama u okruženju koje uključuje stručnjake iz domena, korisnike i profesionalce za informacione tehnologije.

Izgradnja dobrog modela podataka zahtijeva analizu i istraživanje zahtjeva za informacijama i poslovnih pravila prikupljenih kroz radne sesije i intervjue. Rezultirajući model podataka treba usporediti s modelom poduzeća, ako je moguće, kako bi se osiguralo da nije u sukobu s postojećim modelima objekata i da uključuje sve potrebne objekte.

Model podataka se sastoji od logičkih i fizičkih modela koji predstavljaju zahtjeve za informacijama i poslovna pravila. Logički model treba svesti na treći normalni oblik. Treći normalni oblik ograničava, dodaje, ažurira i uklanja anomalije strukture podataka kako bi podržao princip "jedna činjenica na jednom mjestu". Zahtjeve prikupljenih informacija i poslovna pravila treba analizirati i istražiti. Treba ih uporediti s modelom poduzeća kako bi se osiguralo da nisu u sukobu s postojećim objektnim modelima i da uključuju sve potrebne objekte.

U ERwin-u, model podataka uključuje i logičke i fizičke modele. ERwin implementira ER pristup i omogućava vam da kreirate logičke i fizičke objekte modela koji predstavljaju zahtjeve informacija i poslovna pravila. Objekti logičkog modela uključuju entitete, atribute i odnose. Objekti fizičkog modela uključuju tabele, stupce i ograničenja integriteta odnosa.

Jedna od sljedećih publikacija će pokriti pitanja identifikacije entiteta, definiranja tipova entiteta, odabira naziva entiteta i opisa, kao i neke tehnike za izbjegavanje najčešćih grešaka modeliranja povezanih s korištenjem entiteta.

Entiteti moraju imati kompletan skup atributa, tako da svaka činjenica o svakom entitetu može biti predstavljena njegovim atributima. Svaki atribut mora imati ime koje odražava njegovo značenje, Boolean tip podataka i jasan, kratak, potpun opis ili definiciju. U budućem blog postu ćemo pogledati početni skup smjernica za pravilno formatiranje imena i opisa atributa. Odnosi treba da sadrže glagolsku konstrukciju koja opisuje odnos između entiteta, zajedno sa karakteristikama kao što su množina, neophodnost postojanja ili mogućnost odsustva veze.

BILJEŠKA Pluralitet odnos opisuje maksimalni broj sekundarnih instanci entiteta koji se mogu pridružiti instanci originalnog entiteta.Nužnost postojanja ili mogućnost odsustva odnos služi za određivanje minimalnog broja instanci sekundarnog entiteta koji se može povezati s instancom originalnog entiteta

Pošaljite svoj dobar rad u bazu znanja je jednostavno. Koristite obrazac ispod

Studenti, postdiplomci, mladi naučnici koji koriste bazu znanja u svom studiranju i radu biće vam veoma zahvalni.

Objavljeno na http://www.allbest.ru/

• 1. Relacioni model podataka
• 1.1 Relacioni model podataka. Osnovne definicije
• 1.2 Operacije na odnosima
• 2. Korporativni informacioni sistemi
• Bibliografija

1. Relacioni model podataka

1.1 Relacioni model podataka. Osnovne definicije

U matematičkim disciplinama, koncept "tablice" odgovara konceptu "relacije" (relacije). Tabela odražava objekat stvarnog svijeta - entitet, a svaki njegov red odražava određenu instancu entiteta. Svaka kolona ima ime jedinstveno za tabelu. Stringovi nemaju imena, njihov redoslijed nije definiran, a broj je logički neograničen. Jedna od glavnih prednosti relacionog modela podataka je homogenost (svaki red u tabeli ima isti format). Na korisniku je da odluči da li su odgovarajući entiteti homogeni. Time se rješava problem prikladnosti modela.

Osnovni koncepti:

* Odnos je dvodimenzionalna tabela koja sadrži neke podatke.

* Entitet - objekat bilo koje prirode, podaci o kojem se pohranjuju u bazi podataka. Atributi su svojstva koja karakteriziraju entitet (kolone).

* Stepen povezanosti je broj kolona.

* Šema odnosa - lista imena atributa, na primjer, ZAPOSLENI (br., puno ime, godina rođenja, pozicija, odjel).

* Domena - skup vrijednosti atributa relacije (tip podataka).

* Tuple je red tabele.

* Kardinalnost (kardinalnost) - broj redova u tabeli.

* Primarni ključ je atribut koji jedinstveno identificira redove veze. Primarni ključ sa više atributa naziva se kompozitni primarni ključ. Primarni ključ ne može biti potpuno ili djelomično prazan (null). Ključevi koji se mogu koristiti kao primarni ključevi nazivaju se potencijalnim ili alternativnim ključevima.

* Strani ključ je atribut(i) jedne tabele koji može poslužiti kao primarni ključ druge tabele. Referira primarni ključ druge tabele.

Normalizacija je proces koji ima za cilj smanjenje suvišnosti informacija u bazi podataka. Osim samih podataka, u bazi se mogu normalizirati i različita imena, nazivi objekata i izrazi.

Nenormalizirana baza podataka sadrži informacije u jednoj ili više različitih tabela; ovo ostavlja utisak da uključivanje podataka u određenu tabelu nije posledica bilo kakvih očiglednih razloga. Ovakvo stanje može negativno uticati na sigurnost podataka, racionalno korištenje prostora na disku, brzinu upita, efikasnost ažuriranja baze podataka i, što je možda najvažnije, integritet pohranjenih informacija. Baza podataka prije normalizacije je struktura koja još uvijek nije logično raščlanjena na manje upravljive tabele.

Normalni oblik je vrsta indikatora nivoa ili dubine normalizacije baze podataka. Nivo normalizacije baze podataka odgovara normalnom obliku u kojem se nalazi.

1.2 Operacije na odnosima

Da bi se tabela dovela u prvi normalni oblik (1NF), moraju se poštovati dva pravila:

1. Atomičnost ili nedjeljivost. Svaka kolona mora sadržavati jednu nedjeljivu vrijednost.

2. Tabela ne bi trebala sadržavati duple kolone ili grupe podataka.

Na primjer, ako tabela u jednom polju sadrži punu adresu osobe (ulica, grad, poštanski broj), neće zadovoljiti 1NF pravila, jer će sadržavati različite vrijednosti u jednoj koloni, što bi predstavljalo kršenje pravila atomicnosti. Ili ako baza podataka sadrži podatke o filmovima i sadrži kolone Glumac1, Glumac2, Glumac3, ona također neće biti u skladu s pravilima, jer će se podaci ponavljati.

Normalizacija bi trebala početi provjerom strukture baze podataka za kompatibilnost sa 1NF. Sve kolone koje nisu atomske moraju se podijeliti na kolone koje su sastavljene. Ako postoje duple kolone u tabeli, onda treba da izaberu zasebnu tabelu.

Da biste doveli tabelu u prvi normalan oblik, trebali biste:

* Pronađite sva polja koja sadrže višedijelne informacije.

* Podaci koji se mogu raščlaniti na sastavne dijelove moraju se staviti u posebna polja.

* Premjestite duple podatke u zasebnu tabelu.

* Provjerite da li sve tabele odgovaraju uvjetima prvog normalnog oblika.

Da bi se tablice dovele u drugi normalni oblik (2NF), tabele bi trebale biti već u 1NF. Normalizacija treba da se odvija po redu.

Sada, u drugom normalnom obliku, uslov mora biti ispunjen - svaka kolona koja nije ključ (uključujući strani) mora zavisiti od primarnog ključa. Obično je ove kolone, koje imaju vrijednosti koje su nezavisne od ključa, lako identificirati. Ako podaci sadržani u koloni nisu povezani sa ključem koji opisuje red, onda ih treba razdvojiti u svoju zasebnu tabelu. Primarni ključ se mora vratiti u staru tabelu.

Da biste bazu doveli u drugi normalni oblik, potrebno vam je:

* Identifikujte sve kolone koje nisu direktno zavisne od primarnog ključa ove tabele.

* Kreirajte potrebna polja u tabelama korisnika i foruma, izaberite iz postojećih polja ili kreirajte primarne ključeve od novih.

* Svaka tabela treba svoj primarni ključ

* Kreirajte strane ključeve i odredite njihove odnose između tabela. Poslednji korak normalizacije na 2NF će biti dodela stranih ključeva za komunikaciju sa pridruženim tabelama. Primarni ključ jedne tabele mora biti strani ključ u drugoj.

Savjeti:

Drugi način pretvaranja šeme u 2NF je da se pogledaju odnosi između tabela. U idealnom slučaju, kreirajte sve odnose jedan-prema-više. Odnosi "mnogo-na-mnogo" trebaju restrukturiranje.

Pravilno normalizirana tablica nikada neće imati duple redove (dva ili više reda čije vrijednosti nisu ključevi i sadrže iste podatke).

Baza podataka će biti u trećem normalnom obliku ako se konvertuje u drugi normalni oblik i svaki stupac koji nije ključ je nezavisan jedan od drugog. Ako pravilno pratite proces normalizacije do ove tačke, možda neće biti pitanja o pretvaranju u 3NF. Trebali biste biti svjesni da je 3NF prekršen ako promjena vrijednosti u jednoj koloni zahtijeva promjenu u drugoj koloni.

Da biste bazu doveli u treći normalni oblik, potrebno vam je:

* Odredite koja polja od kojih tabela imaju međuzavisnosti, tj. polja koja više ovise jedno o drugom nego o redu u cjelini.

* Kreirajte odgovarajuće tablice. Ako postoji problematična kolona u koraku 1, kreirajte podijeljene tablice za nju.

* Kreirajte ili dodijelite primarne ključeve. Svaka tabela mora imati primarni ključ.

* Kreirajte potrebne strane ključeve koji formiraju bilo koju relaciju.

U četvrtom normalnom obliku, dodatno pravilo je da je potrebno isključiti viševrijedne zavisnosti. Drugim riječima, svi redovi u tabeli moraju biti nezavisni jedan od drugog. Prisustvo nekog reda X ne bi trebalo da znači da se i red Y nalazi negdje u ovoj tabeli.

2. Korporativni informacioni sistemi

relacioni model sistema podataka

Sistem (od grčkog systema - cjelina, spoj sastavljen od dijelova) je skup elemenata koji međusobno djeluju, tvoreći određeni integritet, jedinstvo. Evo nekih koncepata koji se često koriste za karakterizaciju sistema.

1. Element sistema je dio sistema koji ima određenu funkcionalnu svrhu. Složeni elementi sistema, pak, koji se sastoje od jednostavnijih međusobno povezanih elemenata, često se nazivaju podsistemima.

2. Organizacija sistema – unutrašnja uređenost, konzistentnost interakcije elemenata sistema, koja se manifestuje, posebno, u ograničavanju raznolikosti stanja elemenata unutar sistema.

3. Struktura sistema - sastav, red i principi interakcije elemenata sistema, koji određuju osnovna svojstva sistema. Ako su pojedinačni elementi sistema raspoređeni po različitim nivoima, a unutrašnje veze između elemenata organizovane samo od viših ka nižim nivoima i obrnuto, onda govorimo o hijerarhijskoj strukturi sistema. Čisto hijerarhijske strukture su praktički rijetke, pa se, donekle proširujući ovaj koncept, pod hijerarhijskom strukturom obično podrazumijevaju takve strukture u kojima su, između ostalih veza, od primarnog značaja hijerarhijski odnosi.

4. Arhitektura sistema – skup sistemskih svojstava koja su bitna za korisnika.

5. Integritet sistema - fundamentalna nesvodljivost svojstava sistema na zbir svojstava njegovih pojedinačnih elemenata (nastanak svojstava) i, istovremeno, zavisnost svojstava svakog elementa od njegovog mesta i funkcija unutar sistema.

Informacioni sistem je međusobno povezan skup sredstava, metoda i kadrova koji se koriste za skladištenje, obradu i izdavanje informacija u cilju postizanja postavljenog cilja.

Savezni zakon "O informisanju, informatizaciji i zaštiti informacija" daje sljedeću definiciju:

„Informacioni sistem je organizaciono uređen skup dokumenata (nizova dokumenata) i informacionih tehnologija, uključujući upotrebu računarske tehnologije i komunikacija koje implementiraju informacione procese“

Klasifikacija na skali

U pogledu obima, informacioni sistemi se dele u sledeće grupe:

* single;

* grupa;

* korporativni.

Korporativni informacioni sistem je skalabilan sistem dizajniran za integrisanu automatizaciju svih vrsta ekonomskih aktivnosti velikih i srednjih preduzeća, uključujući korporacije koje se sastoje od grupe kompanija koje zahtevaju jedinstveno upravljanje.

Korporativnim informacionim sistemom se može smatrati sistem koji automatizuje više od 80% divizija preduzeća.

U posljednje vrijeme, u mnogim publikacijama posvećenim korištenju informacionih tehnologija u upravljanju privrednim objektima, često se koristi termin „korporativni informacioni sistemi“, koji u njima označava stvarne automatizovane informacione sisteme privrednih objekata.

Automatizovani informacioni sistem (AIS) je kombinacija različitih vrsta podrške, kao i stručnjaka dizajniranih da automatizuju obradu računovodstvenih i analitičkih informacija. Tipovi nosača su po pravilu homogeni za različite sisteme po sastavu, što omogućava implementaciju principa kompatibilnosti sistema u toku njihovog rada. U procesu proučavanja AIS-a kao složenog sistema potrebno je izdvojiti pojedine dijelove i elemente i razmotriti karakteristike njihove upotrebe u fazama stvaranja i rada.

Korporativni informacioni sistemi su evolucija sistema za radne grupe, fokusirani su na velike kompanije i mogu podržati geografski disperzovane čvorove ili mreže. U osnovi, imaju hijerarhijsku strukturu od nekoliko nivoa. Takve sisteme karakteriše klijent-server arhitektura sa specijalizacijom servera ili višeslojna arhitektura. Prilikom razvoja takvih sistema mogu se koristiti isti serveri baze podataka kao i kod razvoja grupnih informacionih sistema. Međutim, u velikim informacionim sistemima, najčešći serveri su Oracle, DB2 i Microsoft SQL Server.

Za grupne i korporativne sisteme, zahtjevi za pouzdanost rada i sigurnost podataka su značajno povećani. Ova svojstva se održavaju održavanjem podataka, referenci i transakcijskog integriteta u poslužiteljima baze podataka.

Klasifikacija po obimu

Prema obimu primene, informacioni sistemi se obično dele u četiri grupe:

* sistemi za obradu transakcija;

* sistemi donošenja odluka;

* informacioni i referentni sistemi;

* kancelarijski informacioni sistemi.

Bibliografija

1. Agalcov, V.P. Baza podataka. U 2 toma V. 2. Distribuirane i udaljene baze podataka: Udžbenik / V.P. Agaltsov. - M.: ID FORUM, NITs INFRA-M, 2013.

2. Golitsyna, O. L. Baze podataka: Udžbenik / O.L. Golitsyna, N.V. Maksimov, I.I. Popov. - M.: Forum, 2012.

3. Karpova, I.P. Baze podataka: Udžbenik / I.P. Karpov. - SPb.: Petar, 2013.

4. Kirillov, V.V. Uvod u relacijske baze podataka Uvod u relacijske baze podataka. Kirillov, G.Yu. Gromov. - SPb.: BHV-Peterburg, 2012.

5. Pirogov, V.Yu. Informacioni sistemi i baze podataka: organizacija i dizajn: Udžbenik / V.Yu. Pirogov. - SPb.: BHV-Peterburg, 2009.

6. G.N. Fedorov. informacioni sistemi. - M.: Akademija, 2013.

7. A.E. Satunina, L.A. Sysoeva. Upravljanje projektima korporativnog informacionog sistema preduzeća. - M.: Finansije i statistika, Infra-M, 2009.

Objavljeno na Allbest.ru

...

Slični dokumenti

Suština i karakteristike tipova modela podataka: hijerarhijski, mrežni i relacioni. Osnovni koncepti relacionog modela podataka. Atributi, shema odnosa baze podataka. Uslovi integriteta podataka. Relacije između tabela. Opće razumijevanje modela podataka.

seminarski rad, dodan 29.01.2011


Korporativni informacioni sistemi i baze podataka, njihova upotreba za poboljšanje i otklanjanje grešaka u poslovanju. Klasifikacija korporativnih informacionih sistema. OLTP klasa informacionih sistema. Promptna analitička obrada.

seminarski rad dodan 19.01.2011


Baze podataka sa dvodimenzionalnim fajlovima i sistemi za upravljanje relacionim bazama podataka (DBMS). Kreiranje baze podataka i obrada upita prema njima pomoću DBMS-a. Glavne vrste baza podataka. Osnovni koncepti relacionih baza podataka. Osnovna svojstva odnosa.

sažetak, dodan 20.12.2010


Koncept sistema baze podataka. Relacioni model i njegove karakteristike. Integritet u relacionom modelu. Relaciona algebra. Problemi dizajna baze podataka. Normalni oblici odnosa. Dizajniranje baze podataka metodom entitet-odnos. ER dijagrami. SQL jezik.

predavanje dodato 10.03.2008


Definirana logička struktura podataka koja se pohranjuje u bazi podataka. Osnovni modeli podataka. Elementi relacionog modela podataka. Primjer korištenja stranih ključeva. Osnovni zahtjevi za odnos relacionog modela podataka.

prezentacija dodata 14.10.2013


Baze podataka i njihova upotreba u računarstvu. Osobine i osnovna konstruktivna jedinica mrežnog modela podataka. Hijerarhijski model, objekti predmetne oblasti. Relacioni model, njegova vidljivost, prikaz podataka u tabelarnom obliku.

sažetak, dodan 19.12.2011


Vrste i funkcije sistema za upravljanje bazama podataka Microsoft Access. Hijerarhijski, mrežni, relacioni model za opisivanje baza podataka. Osnovni koncepti tabele baze podataka. Osobine kreiranja objekata baze podataka, osnovne forme. Pristup internetu u Access.

test, dodano 01.08.2011


Savremeni sistemi za upravljanje bazama podataka (DBMS). Analiza hijerarhijskog modela podataka. Relacioni model podataka. Postrelacijski model podataka kao prošireni relacijski model koji uklanja ograničenje nedjeljivosti podataka pohranjenih u zapisima tablice.

naučni rad, dodato 08.06.2010


Modeli podataka u upravljanju bazama podataka. Konceptualni modeli podataka. Uloga baza podataka u informacionim sistemima. Relacioni model podataka. Definicija predmetne oblasti. Izgradnja modela baze podataka za informacioni sistem "Kućni ljubimci".

seminarski rad, dodan 19.04.2011


Informacijski model u Accessu kao neka vrsta pojednostavljene zamjene za stvarni objekt ili sistem. Osnovne strukture koje određuju organizaciju podataka i odnose između njih; relacijski tip organizacije podataka. Primjer baze podataka u oporezivanju.

Modeli podataka o industriji

Osnovna svrha modela je da olakšaju orijentaciju u prostoru podataka i pomognu u isticanju detalja koji su važni za razvoj poslovanja. U današnjem okruženju, za uspješno poslovanje, neophodno je imati jasno razumijevanje veza između različitih komponenti i imati dobru predstavu o cjelokupnoj slici organizacije. Identifikacija svih detalja i odnosa pomoću modela omogućava najefikasnije korištenje vremena i alata za organizaciju rada kompanije.

Modeli podataka su apstraktni modeli koji opisuju kako su podaci predstavljeni i kako im se pristupa. Modeli podataka definiraju stavke podataka i odnose između njih u određenom području. Model podataka je navigacijski alat za poslovne i IT profesionalce koji koristi određeni skup simbola i riječi za precizno objašnjenje određene klase informacija iz stvarnog svijeta. Ovo omogućava bolju komunikaciju unutar organizacije i na taj način stvara fleksibilnije i stabilnije okruženje aplikacije.

Model podataka na jedinstven način definira značenje podataka, koji su u ovom slučaju strukturirani podaci (za razliku od nestrukturiranih podataka kao što su, na primjer, slika, binarni fajl ili tekst, gdje značenje može biti dvosmisleno).

U pravilu se razlikuju modeli višeg nivoa (i sadržajno općenitijeg) i nižeg (odnosno, detaljnijeg). Gornji nivo modeliranja je tzv konceptualni modeli podataka(konceptualni modeli podataka), koji daju najopštiju sliku funkcionisanja preduzeća ili organizacije. Konceptualni model uključuje glavne koncepte ili predmetna područja koja su kritična za funkcionisanje organizacije; obično njihov broj ne prelazi 12-15. Takav model opisuje klase entiteta koji su važni za organizaciju (poslovni objekti), njihove karakteristike (atribute) i asocijacije između parova ovih klasa (tj. relacije). Budući da se terminologija u poslovnom modeliranju još nije konačno ustalila, u različitim izvorima na engleskom jeziku konceptualni modeli podataka mogu se nazvati i modelom predmetne oblasti (što se može prevesti kao modeli domene) ili predmetnim modelom podataka preduzeća (predmetni korporativni modeli podataka). ).

Sljedeći hijerarhijski nivo je logičkih modela podataka(logički modeli podataka). Oni se također mogu nazvati poslovnim modelima podataka ili poslovnim modelima. Ovi modeli sadrže strukture podataka, njihove atribute i poslovna pravila i predstavljaju informacije koje preduzeće koristi iz poslovne perspektive. U takvom modelu podaci su organizirani u obliku entiteta i odnosa između njih. Logički model predstavlja podatke na način koji poslovnim korisnicima olakšava razumijevanje. U logičkom modelu može se razlikovati rečnik podataka – lista svih entiteta sa njihovim preciznim definicijama, što omogućava različitim kategorijama korisnika da imaju zajedničko razumevanje svih ulaznih i izlaznih tokova podataka modela. Sljedeći, niži nivo modeliranja je fizička implementacija logičkog modela korištenjem specifičnih softverskih i tehničkih platformi.

Logički model sadrži detaljnu korporativnu poslovnu odluku, koja obično ima oblik normalizovanog modela. Normalizacija je proces koji osigurava da svaka stavka podataka u modelu ima samo jednu vrijednost i potpuno i jedinstveno ovisi o primarnom ključu. Stavke podataka su organizovane u grupe prema njihovoj jedinstvenoj identifikaciji. Poslovna pravila koja regulišu stavke podataka moraju biti u potpunosti ugrađena u normalizovani model uz prethodnu validaciju i validaciju. Na primjer, stavka podataka kao što je Ime kupca vjerovatno će biti podijeljena na Ime i Prezime i grupirana sa drugim povezanim stavkama podataka u entitet Klijenta sa primarnim ključem ID-a kupca.

Logički model podataka je neovisan o aplikativnim tehnologijama kao što su baze podataka, mrežne tehnologije ili alati za izvještavanje i sredstva njihove fizičke implementacije. U organizaciji može postojati samo jedan model podataka preduzeća. Logički modeli obično uključuju hiljade entiteta, odnosa i atributa. Na primjer, model podataka za finansijsku instituciju ili telekomunikacijsku kompaniju može sadržavati oko 3000 industrijskih koncepata.

Važno je razlikovati logički i semantički model podataka. Logički model podataka predstavlja poslovno rješenje poduzeća, a semantički model podataka primijenjeno poslovno rješenje. Isti korporativni logički model podataka može se implementirati korištenjem različitih semantičkih modela, tj. semantički modeli se mogu posmatrati kao sljedeći nivo modeliranja koji se približava fizičkim modelima. Štaviše, svaki od ovih modela će predstavljati zaseban „odsječak“ korporativnog modela podataka u skladu sa zahtjevima različitih aplikacija. Na primjer, u korporativnom logičkom modelu podataka entitet Klijent će biti potpuno normaliziran, au semantičkom modelu za tržište podataka može se predstaviti kao višedimenzionalna struktura.

Kompanija može imati dva načina za kreiranje korporativnog logičkog modela podataka: samostalno ga izgraditi ili koristiti gotov. industrijski model(industrijski logički model podataka). U ovom slučaju, razlike u terminima odražavaju samo različite pristupe izgradnji istog logičkog modela. U slučaju da kompanija samostalno razvija i implementira vlastiti logički model podataka, tada se takav model, u pravilu, naziva jednostavno korporativnim logičkim modelom. Ako organizacija odluči koristiti gotov proizvod od profesionalnog dobavljača, onda možemo govoriti o industrijskom logičkom modelu podataka. Potonji je gotov logički model podataka koji odražava funkcioniranje određene industrije s visokim stupnjem tačnosti. Industrijski logički model je domen-specifičan i integrisani pogled na sve informacije koje se moraju nalaziti u skladištu podataka preduzeća da bi se odgovorilo na strateška i taktička poslovna pitanja. Kao i svaki logički model podataka, industrijski model je neovisan o odlukama aplikacije. Takođe ne uključuje izvedene podatke ili druge proračune za brže pronalaženje podataka. Po pravilu, većina logičkih struktura takvog modela je dobro oličena u njegovoj efektivnoj fizičkoj implementaciji. Takve modele razvijaju mnogi dobavljači za širok raspon područja djelatnosti: finansije, proizvodnja, turizam, zdravstvo, osiguranje itd.

Industrijski logički model podataka sadrži informacije koje su zajedničke za industriju i stoga ne mogu biti sveobuhvatno rješenje za kompaniju. Većina kompanija mora povećati model u prosjeku za 25% dodavanjem stavki podataka i proširenjem definicija. Out-of-the-box modeli sadrže samo ključne elemente podataka, a ostali elementi se moraju dodati odgovarajućim poslovnim objektima tokom instalacije modela u kompaniji.

Industrijski logički modeli podataka sadrže značajnu količinu apstrakcije. Apstrakcije znače ujedinjenje sličnih koncepata pod zajedničkim nazivima kao što su Događaj ili Učesnik. Ovo dodaje fleksibilnost i uniformnost industrijskim modelima. Dakle, koncept događaja je primjenjiv na sve industrije.

Stručnjak za poslovnu inteligenciju Stiv Hoberman identifikuje pet faktora koje treba uzeti u obzir kada odlučujete da li ćete nabaviti industrijski model podataka. Prvi su vrijeme i novac potrebni za izradu modela. Ako organizacija treba brzo da postigne rezultate, tada će industrijski model biti od koristi. Korištenje industrijskog modela možda neće odmah dati sliku cijele organizacije, ali može uštedjeti značajnu količinu vremena. Umjesto samog modeliranja, vrijeme će biti utrošeno na povezivanje postojećih struktura sa industrijskim modelom i raspravljanje o tome kako ga najbolje prilagoditi potrebama organizacije (na primjer, koje definicije treba promijeniti i koje stavke podataka treba dodati).

Drugi faktor je vrijeme i novac potrebni da se model održi u dobrom radnom stanju. Ako model podataka preduzeća nije dio metodologije koja vam omogućava da pratite usklađenost s njegovom preciznošću i usklađenost sa savremenim standardima, onda takav model vrlo brzo zastari. Industrijski model podataka može spriječiti da se ovaj rizik dogodi jer se ažurira eksternim resursima. Naravno, promene koje se dešavaju unutar organizacije treba da se odraze u modelu od strane same kompanije, ali promene u industriji će se reprodukovati u modelu od strane njenog dobavljača.

Treći faktor je iskustvo u procjeni rizika i modeliranju. Kreiranje korporativnog modela podataka zahtijeva kvalifikovane resurse i poslovnog i IT osoblja. U pravilu, menadžeri su dobro upoznati ili sa radom organizacije u cjelini, ili sa aktivnostima određenog odjela. Malo njih ima široko (u cijeloj kompaniji) i duboko (unutar odjela) znanje o svom poslovanju. Većina menadžera obično dobro poznaje samo jednu oblast. Stoga, da bi se stekla opšta korporativna slika, potrebni su značajni poslovni resursi. Ovo također povećava zahtjeve za IT osoblje. Što je više poslovnih resursa potrebno za kreiranje i testiranje modela, to iskusniji analitičari moraju biti. Oni ne samo da moraju znati kako doći do informacija od poslovnog osoblja, već i biti u stanju da pronađu zajedničku tačku gledišta u spornim oblastima i da sve te informacije prezentiraju na integrisan način. Osoba koja kreira model (u mnogim slučajevima isti analitičar) mora imati dobre vještine modeliranja. Izgradnja logičkih modela preduzeća zahtijeva modeliranje „za budućnost“ i sposobnost doslovnog pretvaranja složenog poslovanja „u kvadrate i linije“.

S druge strane, industrijski model dozvoljava eksternu ekspertizu. Logički modeli specifični za industriju izgrađeni su korištenjem dokazanih metodologija modeliranja i timova iskusnih profesionalaca kako bi se izbjegli uobičajeni i skupi problemi koji mogu nastati prilikom razvoja poslovnih modela podataka unutar organizacije.

Četvrti faktor je postojeća infrastruktura aplikacija i odnosi sa dobavljačima. Ako organizacija već koristi mnoge alate istog dobavljača i ima uspostavljene odnose s njim, onda ima smisla i industrijski model naručiti od njega. Ovaj model će moći slobodno da radi sa drugim proizvodima istog dobavljača.

Peti faktor je razmjena informacija unutar industrije. Ako kompanija treba da komunicira sa drugim organizacijama koje rade u istoj oblasti, onda industrijski model može biti veoma koristan u ovoj situaciji. Organizacije unutar iste industrije koriste slične strukturne komponente i terminologiju. Danas su u većini industrija kompanije prinuđene da razmjenjuju podatke kako bi uspješno poslovale.

Najefikasniji su industrijski modeli koje nude profesionalni dobavljači. Visoka efikasnost njihove upotrebe postiže se zahvaljujući značajnom nivou detalja i tačnosti ovih modela. Obično sadrže mnogo atributa podataka. Osim toga, kreatori ovih modela ne samo da imaju veliko iskustvo u modeliranju, već su i dobro upućeni u izradu modela za određenu industriju.

Industrijski modeli podataka pružaju kompanijama jedinstven, integrisani pogled na njihove poslovne informacije. Mnogim kompanijama je teško da integrišu svoje podatke, iako je to preduslov za većinu projekata u celom preduzeću. Prema studiji The Data Warehousing Institute (TDWI), više od 69% anketiranih organizacija smatra da je integracija značajna prepreka usvajanju novih aplikacija. Naprotiv, implementacija integracije podataka stvara opipljiv prihod za kompaniju.

Model podataka u industriji, pored povezivanja sa postojećim sistemima, pruža velike prednosti za projekte širom preduzeća kao što su planiranje resursa preduzeća (ERP), upravljanje glavnim podacima, poslovna inteligencija, poboljšanje kvaliteta podataka i razvoj zaposlenih.

Stoga su industrijski logički modeli podataka efikasan alat za integraciju podataka i dobijanje holističkog pogleda na poslovanje. Čini se da je upotreba logičkih modela neophodan korak ka stvaranju korporativnih skladišta podataka.

Publikacije

1. Steve Hoberman. Iskorištavanje industrijskog logičkog modela podataka kao vašeg modela podataka preduzeća.
2. Claudia Imhoff. Brzi projekti skladištenja podataka i poslovne inteligencije putem inteligentnog modeliranja podataka

Svrha predavanja

Nakon proučavanja materijala ovog predavanja, znaćete:

• šta model podataka preduzeća ;
• kako pretvoriti model podataka preduzeća u model skladišta podataka;
• glavni elementi korporativni model podataka ;
• slojevi prezentacije korporativnog modela podataka ;
• algoritam za transformaciju modela podataka preduzeća u model višedimenzionalnog skladišta podataka ;

i nauči da:

• razviti modele skladišta podataka na osnovu korporativni model podataka organizacije;
• dizajnirati zvjezdastu shemu koristeći CASE alate;
• particioni stolovi multidimenzionalni model koristeći CASE alate.

Model podataka preduzeća

Uvod

Srž svakog HD-a je njegov model podataka. Bez modela podataka, biće veoma teško organizovati podatke u HD-u. Stoga bi programeri CD-a trebali potrošiti vrijeme i trud na razvoj takvog modela. Razvoj HD modela pada na ramena HD dizajnera.

U poređenju sa projektovanjem OLTP-sistema, metodologija projektovanja CD-a ima niz karakterističnih karakteristika povezanih sa orijentacijom struktura podataka za skladištenje na rešavanje problema analize i informacione podrške u procesu donošenja odluka. HD model podataka treba da pruži efikasno rešenje upravo za ove probleme.

Polazna tačka u dizajnu CD-a može biti tzv model podataka preduzeća(corporate data model ili enterprise data model, EDM), koji se kreira u procesu dizajniranja OLTP sistema organizacije. Prilikom projektovanja korporativni model podataka obično se pokušava kreirati struktura podataka zasnovana na poslovnim operacijama koja bi prikupila i sintetizovala sve potrebe za informacijama organizacije.

dakle, model podataka preduzeća sadrži potrebne informacije za izradu CD modela. Dakle, u prvoj fazi, ako takav model postoji u organizaciji, HD dizajner može započeti HD dizajn rješavanjem problema transformacije korporativni model podataka u HD model.

Model podataka preduzeća

Kako riješiti problem transformacije korporativni model podataka u HD model? Za rješavanje ovog problema potrebno je imati ovaj model, tj. korporativni model podataka treba izgraditi i dokumentovano... I treba da razumete šta od ovog modela i kako treba transformisati u HD model.

Razjasnimo koncept sa stanovišta CD dizajnera korporativni model podataka. Ispod korporativni model podataka razumiju višeslojni, strukturirani opis predmetnih područja organizacije, strukture podataka predmetne oblasti, poslovne procese i poslovne procedure, organizacione tokove podataka, dijagrame stanja, matrice procesa podataka i druge modelske reprezentacije koje se koriste u aktivnostima organizacije. Dakle, u najširem smislu riječi, model podataka preduzeća je skup modela različitih nivoa koji karakterišu (model na nekom apstraktnom nivou) aktivnosti organizacije, tj. sadržaja korporativni model direktno zavisi od toga koje su modelske konstrukcije uključene u to u datoj organizaciji.

Glavni elementi korporativni model podataka su:

• opis predmetnih oblasti organizacije (definicija oblasti delatnosti);
• odnose između gore definisanih predmetnih oblasti;
• informacioni model podataka (ERD -model ili model entitet-odnos);
• opis za svaku predmetnu oblast:
  • ključevi entiteta;
  • atributi entiteta;
  • podtipovi i supertipovi;
  • odnosi između entiteta;
  • atributi grupisanja;
  • odnosi između predmetnih oblasti;
• funkcionalni ili model poslovnog procesa;
• dijagrami toka podataka;
• dijagrami stanja;
• ostali modeli.

dakle, model podataka preduzeća sadrži entitete, atribute i odnose koji predstavljaju informacijske potrebe organizacije. Na sl. 16.1 prikazuje glavne elemente korporativni model podataka.

Nivoi prezentacije modela podataka preduzeća

Model podataka preduzeća podijeljeni prema predmetnim oblastima, koje predstavljaju grupe subjekata koji se odnose na podršku specifičnim poslovnim potrebama. Neka predmetna područja mogu pokrivati ​​specifične poslovne funkcije kao što je upravljanje ugovorima, dok druga mogu uključivati ​​entitete koji opisuju proizvode ili usluge.

Svaki logički model mora odgovarati postojećoj domeni korporativni model podataka... Ako logički model ne ispunjava ovaj zahtjev, mora mu se dodati model domene.

Model podataka preduzeća obično ima nekoliko nivoa prezentacije. Zapravo visoki nivo(visoki nivo) korporativni model podataka postoji opis glavnih predmetnih oblasti organizacije i njihovih odnosa na entitetskom nivou. Na sl. 16.2 je isječak korporativni model podataka vrhunski nivo.

Rice. 16.2.

Dijagram prikazan na slici predstavlja četiri predmetna područja: "Kupac" ( Kupac), "Provjeri" ( račun), "Naruči" ( Red) i "Proizvod" ( Proizvod). Po pravilu samo direktne veze između predmetnih oblasti, koje, na primjer, evidentiraju sljedeću činjenicu: kupac plaća račun za narudžbu robe. Detalji i indirektni odnosi na ovom nivou korporativni model nije prikazano.

na sljedećem, srednji nivo(srednji nivo) korporativni model podataka prikazane su detaljne informacije o objektima predmetnih oblasti, odnosno ključevi i atributi entiteta, njihovi odnosi, podtipovi i supertipovi, itd. Za svaku domenu modela najvišeg nivoa postoji jedan model srednjeg nivoa. Na sl. 16.3 prikazuje srednji nivo prezentacije korporativni model za fragment predmetne oblasti "Narudžba".

Od sl. 16.3 vidi se da je predmetna oblast "Nalog" ( Red) uključuje nekoliko entiteta, definiranih kroz njihove atribute, i odnose između njih. Predstavljeni model vam omogućava da odgovorite na pitanja kao što su datum narudžbe, ko je napravio narudžbu, ko je poslao narudžbu, ko prima narudžbu i niz drugih. Iz gornjeg dijagrama se može vidjeti da u ovoj organizaciji postoje dvije vrste naloga - narudžbe za unapređenje ( Komercijalni) i maloprodajne narudžbe ( Maloprodaja).

primeti, to model podataka preduzeća može predstavljati različite aspekte aktivnosti organizacije i sa različitim stepenom detalja i potpunosti. Ako korporativni model predstavlja sve aspekte aktivnosti organizacije, tzv organizacioni model podataka(model podataka preduzeća).

Sa stanovišta dizajna CD-a, važan faktor u odluci da se kreira CD model od korporativni model podataka je država potpunost korporativni model podataka.

Model podataka preduzeća organizacija ima karakteristiku evolutivnosti, tj. stalno se razvija i unapređuje. Neka predmetna područja korporativni model podataka može biti dobro razvijena, za neke posao možda još nije počeo. Ako fragment predmetnog područja nije razrađen u korporativni model podataka, onda ne postoji način da se ovaj model koristi kao polazna tačka za dizajn CD-a.

Stepen završetka korporativni model može se nivelirati u dizajnu CD-a na sljedeći način. Budući da je proces razvoja HD obično vremenski podijeljen u niz faza, proces njegovog dizajna može se sinhronizirati sa proces završetka razvoj pojedinačnih fragmenata korporativni model podataka organizacije.

Najniže prezentacijski sloj korporativnog modela podataka informacije o fizičkim karakteristikama objekata baze podataka koji odgovaraju logički model podataka srednji prezentacijski sloj korporativnog modela podataka.