Ovaj će se članak usredotočiti na arhitekturu skladišta podataka. Čime se treba voditi pri izradi, koji pristupi funkcioniraju - i zašto.

"Priča je laž - ali u njoj postoji nagovještaj..."

Djed je zasadio ... skladište. I skladište je naraslo, super, super. Jednostavno nisam znao kako to funkcionira. I djed je počeo pregled. Djed je na obiteljsko vijeće pozvao baku, unuku, mačku i miša. I kaže sljedeće: “Naraslo nam je skladište. Podaci iz svih sustava teku prema dolje, tablice su vidljive i nevidljive. Korisnici smišljaju svoja izvješća. Čini se da je sve dobro – živjeti i živjeti. Da, samo jedna tuga – nitko ne zna kako to funkcionira. Zahtijeva diskove naizgled nevidljivo - ne možete uštedjeti dovoljno! A onda su korisnici stekli naviku da mi se javljaju s različitim pritužbama: ili se izvješće zamrzne, ili su podaci zastarjeli. A onda je to prava katastrofa - dolazimo s izvješćima caru-ocu, ali brojke se ne slažu jedna s drugom. Nije ni čas - ljuti se kralj - onda ne skidaj glave - ni meni, ni tebi. Stoga sam vas odlučio okupiti i posavjetovati se: što ćemo učiniti?"

Baci pogled na sastanak i pita:
- Ti, babo, znaš li kako je uređeno naše skladište?
- Ne, djede, ne znam. A kako bih ja znao? Tamo, kakvi ga hrabri momci č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? Kakvo ste skladište? Recite mi kakav izvještaj trebate - mi ćemo to učiniti za vas! Trebali biste češće donositi pite! Bolno, ukusni su."
- A ti, ljubljena unuče, znaš li kako je uređeno naše skladište?
- Ne, dide, ne znam. Nekako su mi dali pristup tome. Povezao sam se, gledam - a tu su i stolovi - naizgled nevidljivi. I različite sheme su skrivene. Oči se dižu.... U početku sam bio zbunjen. A onda sam dobro pogledao – neke su prazne, druge pune, ali samo napola. I čini se da se podaci ponavljaju. Nije ni čudo da vam neće biti dovoljno diskova, s takvom zališkom!
- Pa ti, maco, što kažeš na naše skladište? Ima li nešto dobro u tome?
- Da, kako da ne kažem, dide - hoću. Na zahtjev svoje unuke pokušao sam napraviti pilot u zasebnom krugu – maloj vitrini. Kako bi razumjeli kakva je trgovina profitabilna za našu državu - koji su proizvodi dobri za trgovce, plaćaju danak - nadopunjuju riznicu. I koje su jako loše. I počeo sam birati podatke za sebe iz ovog spremišta. Prikupljene činjenice. I počeo ih je pokušavati uspoređivati ​​s proizvodima. I što sam, dide, vidio - proizvodi su kao da su isti, ali pogledaš li tanjure - različiti su! Tada sam ih počela češljati češljem svoje unuke. Chesal-izgreban - i doveo do određene uniformnosti, milujući oči. Ali rano sam se obradovao - sljedeći dan sam pokrenuo svoje skripte za ažuriranje prekrasnih podataka u prozoru - i sve je nestalo za mene! "Kako to?" - Mislim - uzrujat će se unuka - danas bi bilo potrebno ministru pokazati našeg pilota. Kako ćemo s takvim podacima?
- Da, tužne priče, mačka, ti pričaj. Pa, ti, mali mišu, stvarno nisi pokušao saznati za skladište? Kod nas si živahna, okretna, druželjubiva djevojka! Što ćeš nam reći?
- Da, kako, djede, ne pokušavaj - naravno, ja sam tihi miš, da okretan. Jednom me je mačja unuka zamolila da dobijem model podataka našeg državnog skladišta. I mačak mi je, naravno, došao - za tebe, kaže, miš, sva nada! Pa, koje je dobro djelo dobrim ljudima (i mačkama) ne učiniti? 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 kavu, skočila sam na stol. Gledam model - ništa ne mogu razumjeti! Kako to? Ne prepoznajem naše skladište! Imamo bezbroj tisuća tablica, tokovi podataka su nezaustavljivi! I ovdje - sve je skladno i lijepo... Pogledao je upravo ovaj model - i vratio ga u sef.
- Da, vrlo čudne stvari, rekao si nam, mišu.
Djed se dobro zamisli.
- Što ćemo, prijatelji moji? Uostalom, s takvim i takvim spremištem nećete dugo živjeti ... Korisnici će uskoro izgubiti strpljenje.

Što god naš djed odlučio iz bajke - izgraditi novo skladište ili pokušati reanimirati postojeće - potrebno je donijeti zaključke prije nego što ponovno "zasučemo rukave".
Ostavimo po strani organizacijske aspekte – kao što su opasnost koncentracije stručnosti u određenoj uskoj zatvorenoj skupini, izostanak kontrolnih procesa i osiguranje transparentnosti arhitekture sustava koji se koriste u poduzeću itd.
Danas bih se želio usredotočiti na izgradnju arhitekture određenog sustava (ili grupe sustava) – skladišta podataka. Ono što prije svega treba biti u fokusu, kada organizacija počne graditi tako složen i skup sustav kao što je skladište.

Ispitivanje

Nitko od nas, radeći na stvaranju i razvoju bilo kojeg sustava, ne želi da ovo bude „privremena kuća“, ili rješenje koje će „odvenuti“ za godinu-dvije, jer neće moći ispuniti zahtjeve i očekivanja kupaca i poslovanja. Koliko god se danas uočavala pristranost prema "fleksibilnim metodologijama", čovjeku je puno ugodnije osjećati se kao "majstor" koji izrađuje violine nego zanatlija koji blanja palice za jednokratne bubnjeve.
Naša namjera zvuči prirodno: napraviti sustave koji su čvrsti i kvalitetni, koji neće zahtijevati od nas redovita "noćna bdjenja s kartotekom", za koje se nećemo sramiti pred krajnjim korisnicima i koji neće izgledati kao "crna kutija" za sve "neupućene" sljedbenike.

Za početak, bacimo popis tipičnih problema s kojima se redovito susrećemo pri radu sa spremištima. Zapišimo samo što imamo – do sada bez pokušaja racionalizacije i formalizacije.

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, prema propisima, unutar jednog velikog procesa, u roku od 8 sati. I odgovara nam. Ali ako se iznenada dogodi kvar, zahtijeva ručnu intervenciju. A onda sve može raditi nepredvidivo dugo vremena, tk. zahtijevat će ljudsko sudjelovanje u procesu.
3. Zamotali izdanje - očekujte probleme.
4. Neki izvor nije mogao poslati podatke na vrijeme - svi procesi čekaju.
5. Integritet podataka kontrolira baza podataka – tako da se naši procesi ruše kada se pokvare.
6. Imamo vrlo veliku pohranu - 2000 tablica u jednoj zajedničkoj shemi. I još 3000 u mnogim drugim shemama. Već imamo malo pojma kako su raspoređeni i iz kojeg razloga su se pojavili. Stoga nam može biti teško ponovno upotrijebiti nešto. A mnoge zadatke treba iznova rješavati. Jer, ovo je lakše i brže (nego razumjeti "tuđu šifru"). Kao rezultat toga, imamo nepodudarnosti i duplicirane funkcionalnosti.
7. Očekujemo da će izvor pružiti podatke dobre kvalitete. No, pokazalo se da to nije tako. Kao rezultat toga, trošimo puno vremena na usklađivanje naših konačnih izvješća. I u tome su bili vrlo uspješni. Imamo čak i pojednostavljen proces. Istina, treba vremena. No korisnici su navikli...
8. Korisnik ne vjeruje uvijek našim izvješćima i zahtijeva opravdanje jedne ili druge brojke. U nekim slučajevima ima pravo, a u drugima nije. Ali vrlo nam je teško opravdati ih, budući da 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 najučinkovitiji način paralelizacije poslova?
10. Kako razvijati sustav postupno, ne ulazeći u razvoj "jezgre sustava" cijelu godinu?
11. Skladište podataka povezano je 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 na šest mjeseci i razgovarali o poslovnim subjektima, bez ikakvih pomaka). Zašto je uopće? Ili je možda bolje bez nje, ako je s njom toliko problema? Možda ga možemo nekako generirati?
12. Odlučili smo voziti model. Ali kako sustavno razvijati model podataka skladišta? Trebaju li nam “pravila igre” i koja bi ona mogla biti? Što će nam to dati? Što ako griješimo s modelom?
13. Trebamo li spremati podatke, odnosno povijest njihovih promjena, ako "poduzeću ne trebaju"? Ne bih želio "spremati smeće" i komplicirati korištenje ovih podataka za stvarne zadatke. Treba li trezor čuvati povijest? Kako je? Kako pohrana funkcionira tijekom vremena?
14. Trebamo li pokušati objediniti podatke na skladištu ako imamo sustav 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 sustave. Treba li spremište podataka biti spremno za promjenu izvora? Kako se to može postići?
16. Trebaju li nam metapodaci? Što mislimo pod ovim? Gdje se točno mogu koristiti? Kako ga možete implementirati? Trebam li ih pohraniti "na jedno mjesto"?
17. Naši kupci su izrazito nestabilni u svojim zahtjevima i željama – nešto se stalno mijenja. Općenito, naše poslovanje je vrlo 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 odaziv. Ali ne možemo često pokretati naše glavne procese pokretanja, jer ovo učitava izvorne sustave (loš utječe na performanse) - stoga, spuštamo dodatne tokove podataka - koji će pokupiti u točki - ono što nam treba. Istina, ima mnogo potoka. A onda ćemo neke podatke odbaciti. Štoviše, pojavit će se problem konvergencije. Ali nema drugog načina...

Dosta toga se već dogodilo. Ali ovo nije potpuni popis - lako ga je nadopuniti i razviti. Nećemo ga skrivati ​​u stolu, već ga objesiti na vidljivo mjesto – držeći ova pitanja u fokusu naše pažnje u procesu rada.
Naš je zadatak kao rezultat doći do sveobuhvatnog rješenja.

Antifragilnost

Gledajući naš popis, može se izvući jedan zaključak. Nije teško stvoriti svojevrsnu "bazu podataka za izvješćivanje", učitati podatke u nju ili čak izgraditi neku vrstu rutinskih procesa ažuriranja podataka. Sustav nekako počinje živjeti, pojavljuju se korisnici, a s njima obveze i SLA, nastaju novi zahtjevi, povezuju se dodatni izvori, mijenjaju se metodologije - sve se to mora uzeti u obzir u procesu razvoja.

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

Dolazi nam promjena čiji utjecaj nismo u stanju procijeniti i shvatiti (budući da takve alate nismo ugradili u sustav od samog početka) – a da ne bismo riskirali, ne diramo ono što jest, ali napravimo još jedan produžetak sa strane, i još jedan, i također - pretvaramo našu odluku u sirotinjske četvrti, ili, kako kažu u Latinskoj Americi, "favele", u koje se čak i policija boji ući.
Osjeća se gubitak kontrole nad vlastitim sustavom, kaos. Potrebno je sve više ruku za održavanje postojećih procesa i rješavanje problema. A promjene je sve teže napraviti. Drugim riječima, sustav postaje nestabilan na stres, neprilagođen promjenama. A osim toga, postoji jaka ovisnost o likovima koji "znaju ferway", budući da nitko nema "kartu".

Ovo svojstvo objekta - da se uruši pod utjecajem kaosa, 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 nesreća, već od toga ima izravnu korist... ("Antifragility. Kako imati koristi od kaosa")
Inače se može nazvati prilagodljivost ili otpornost na promjene .

Što to znači u ovom kontekstu? Koji su “izvori kaosa” za IT sustave? A što znači "kapitalizirati kaos" u smislu IT arhitekture?
Prva misao koja vam pada na pamet su promjene koje dolaze izvana. Što je vanjski svijet za sustav? Posebno za skladištenje. Naravno, prije svega - promjene sa strane izvora podataka za trgovinu:

• mijenjanje formata dolaznih podataka;
• zamjena nekih sustava izvora podataka drugima;
• promjena pravila/platforme za integraciju sustava;
• promjena interpretacije podataka (formati se spremaju, mijenja se logika rada s podacima);
• promjena modela podataka ako se integracija vrši na razini podataka (parsiranje datoteka dnevnika transakcija baze podataka);
• rast količine podataka - dok u izvornom sustavu nije bilo puno podataka, a opterećenje nije bilo veliko - bilo je moguće dohvatiti ih u bilo kojem trenutku, uz proizvoljno težak zahtjev, podaci i opterećenje su se povećavali - sada postoje stroga ograničenja ;
• itd.

Sami izvorni sustavi, sastav informacija i njihova struktura, vrsta integracijske interakcije, kao i sama logika rada s podacima mogu se promijeniti. Svaki sustav implementira vlastiti model podataka i pristupe radu s njima, koji zadovoljavaju ciljeve i zadatke sustava. I koliko god se trudili objediniti 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 s korporativnim podacima - prisutnost i kontrola informacijske arhitekture, jedinstveni semantički model, sustavi upravljanja 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):

• prije je bilo dovoljno podataka za izradu izvješća - sada je bilo potrebno povezati dodatna polja ili novi izvor podataka;
• prethodno implementirane tehnike obrade podataka su zastarjele - potrebno je preraditi algoritme i sve što utječe na to;
• Prije su svi bili zadovoljni trenutnom vrijednošću atributa rječnika na informacijskoj ploči - sada se traži vrijednost koja je relevantna u trenutku analizirane činjenice/događaja;
• postojao je zahtjev za dubinom povijesti pohrane podataka, koji prije nije postojao - pohranjivanje podataka ne 2 godine, već 10 godina;
• ranije je bilo dovoljno podataka na "kraj dana/razdoblja" - sada vam je potrebno stanje podataka "unutar dana" ili u vrijeme određenog događaja (na primjer, odluka o zahtjevu za kredit - za Basel II);
• ranije smo bili zadovoljni izvještavanjem o podacima za jučer (T-1) ili kasnije, sada nam treba T0;
• itd.

I integracijske interakcije s izvornim sustavima i zahtjevi korisnika podataka iz skladišta vanjski su čimbenici za skladište podataka: neki izvorni sustavi zamjenjuju druge, raste količina podataka, mijenjaju se formati dolaznih podataka, mijenjaju se zahtjevi korisnika itd. A sve su to tipične vanjske promjene za koje naš sustav – naše spremište – mora biti spreman. Uz pravu arhitekturu, ne bi trebali ubiti sustav.

Ali to nije sve.
Govoreći o varijabilnosti, prije svega se sjećamo vanjskih čimbenika. Uostalom, iznutra možemo sve kontrolirati, tako nam se čini, zar ne? Da i ne. Da, većina čimbenika koji su izvan zone utjecaja su vanjski. Ali postoji i "unutarnja entropija". I upravo zbog njegove prisutnosti ponekad se trebamo vratiti “na točku 0”. Počnite igru ​​ispočetka.
U životu smo često skloni krenuti od nule. Zašto je ovo svojstveno nama? I je li stvarno tako loše?
Primijenjeno na IT. Za sam sustav – to može biti vrlo dobro – sposobnost preispitivanja pojedinačnih odluka. Pogotovo kada to možemo učiniti lokalno. Refaktoring je proces razotkrivanja “weba” koji se povremeno pojavljuje u procesu razvoja sustava. Povratak na početak može biti od pomoći. Ali ima cijenu.
Uz kompetentno upravljanje arhitekturom, ova cijena se smanjuje - a sam proces razvoja sustava postaje upravljiviji i transparentniji. Jednostavan primjer: ako se poštuje princip modularnosti, možete prepisati zasebni modul bez utjecaja na vanjska sučelja. A to se ne može učiniti s monolitnom strukturom.

Antifragilnost sustava određena je arhitekturom koja je u njega ugrađena. I upravo to svojstvo čini ga prilagodljivim.
Kad govorimo o adaptivna arhitektura- mislimo da je sustav u stanju prilagoditi se promjenama, a nikako da stalno mijenjamo samu arhitekturu. Naprotiv, što je arhitektura stabilnija i stabilnija, što je manje zahtjeva koji zahtijevaju njezinu reviziju, to je sustav prilagodljiviji.

Rješenja koja uključuju reviziju cjelokupne arhitekture imat će puno veću cijenu. I morate imati jako 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 utječe na arhitekturu.
Stoga također moramo poznavati naše “granice antikrhkosti”. Arhitektura se ne razvija "u vakuumu" - temelji se na trenutnim zahtjevima i očekivanjima. A ako se situacija iz temelja promijeni - moramo shvatiti da smo otišli dalje od postojeće arhitekture - i moramo je revidirati, izraditi drugačije rješenje - i razmisliti o putovima tranzicije.
Na primjer, pretpostavili smo da ćemo uvijek trebati podatke u pohrani na kraju dana, podatke ćemo uzimati svaki dan koristeći standardna sučelja sustava (kroz skup pogleda). Zatim je iz odjela za upravljanje rizicima stigao zahtjev za primanjem podataka ne na kraju dana, već u trenutku donošenja odluke o kreditiranju. Ne morate pokušavati "povući nenapeto" - samo trebate priznati tu činjenicu - što prije, 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 prekasno suočimo sa zahtjevom koji utječe na arhitekturu - i cijena naše promjene bit će vrlo visoka. Pogled malo unaprijed – unutar granica našeg horizonta – još nikome nije naškodio.

Primjer sustava iz "priče o pohrani" samo je jedan primjer vrlo klimavog sustava izgrađenog na krhkim pristupima dizajnu. A ako se to dogodi, uništenje se događa prilično brzo, za ovu klasu sustava.
Zašto mogu tako reći? Tema repozitorija nije nova. Pristupi i inženjerske prakse koje su razvijene tijekom tog vremena bile su usmjerene upravo na to – održavanje održivosti sustava.
Jednostavan primjer: jedan od najčešćih razloga za neuspjeh početnih projekata pohrane je pokušaj izgradnje pohrane preko razvojnih izvornih sustava bez dogovora o integracijskim sučeljima – pokušaj dohvaćanja podataka izravno iz tablica. Kao rezultat toga, krenuli smo u razvoj - tijekom tog vremena izvorna baza podataka se promijenila - i tokovi učitavanja u spremištu postali su neoperativni. Prekasno je da se nešto ponovi. A ako se još niste osigurali tako što ste napravili nekoliko slojeva stolova unutar spremišta, onda možete sve izbaciti i krenuti ispočetka. Ovo je samo jedan primjer, i to jedan od jednostavnih.

Talebov kriterij za krhko i antifragilno je jednostavan. Glavni sudac je vrijeme. Ako sustav izdrži test vremena, te pokaže svoju "vitalnost" i "neuništivost" - ima svojstvo antifragilnosti.
Ako pri projektiranju sustava uzmemo u obzir antifragilnost kao uvjet, to će nas potaknuti da koristimo takve pristupe izgradnji njegove arhitekture koji će sustav učiniti prilagodljivijim i na “kaos izvana” i na “kaos iznutra”. . I u konačnici sustav će imati dulji vijek trajanja.
Nitko od nas ne želi praviti “provizorne kućice”. I nemojte se zavaravati, što danas nije drugačije. Normalno je da osoba u bilo kojem trenutku gleda nekoliko koraka naprijed, a pogotovo u krizi.

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

Članak o arhitekturi pohrane pretpostavlja da čitatelj ne samo da zna što je to, već ima i određeno iskustvo s takvim sustavima. Ipak, smatrao sam potrebnim to 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 samo "vrlo velike baze podataka"?
Davno, kada su u svijetu postojali jednostavno "sustavi za obradu poslovnih podataka", nije bilo podjele IT sustava na klase kao što su front-end oltp sustavi, back-office dss, sustavi za obradu teksta, skladišta podataka itd.
U to vrijeme Michael Stonebreaker je stvorio prvi motor relacijske baze podataka, Ingres.
A to je vrijeme kada je era osobnih računala poput vihora uletjela u računalnu industriju i zauvijek promijenila sve ideje tadašnje informatičke zajednice.

U to vrijeme bilo je lako pronaći poslovne aplikacije napisane na temelju DBMS-a desktop klase, kao što su Clipper, dBase i FoxPro. A tržište za klijent-poslužitelj aplikacije i DBMS samo je dobivalo zamah. Poslužitelji baza podataka su se pojavljivali jedan za drugim, koji će još dugo zauzeti svoju nišu u IT prostoru - Oracle, DB2 itd.
I izraz "aplikacija baze podataka" bio je uobičajen. Što je uključivala takva prijava? Pojednostavljeno - neki obrasci za unos putem kojih su korisnici mogli istovremeno unositi podatke, neki izračuni koji su se pokretali "po gumbu" ili "po rasporedu", kao i neka izvješća koja su se mogla vidjeti na ekranu ili spremati kao datoteke i slati na pečat.
"Ništa posebno - samo normalna aplikacija, samo baza podataka", primijetio je jedan od mojih mentora na početku moje karijere. "Znači ništa posebno?" - pomislio sam tada.

Ako pažljivo pogledate, još uvijek postoje neke osobitosti. Kako korisnici rastu, volumen dolaznih informacija se povećava, kako se povećava opterećenje sustava, njegovi programeri, dizajneri, kako bi održali performanse na prihvatljivoj razini, idu na neke "trikove". Prva je podjela monolitnog "sustava za obradu poslovnih podataka" na računovodstvenu aplikaciju koja podržava on-line rad korisnika, a posebno je dodijeljena aplikacija za paketnu obradu podataka i izvješćivanje. Svaka od ovih aplikacija ima svoju bazu podataka i čak se nalazi na zasebnoj instanci poslužitelja baze podataka, s različitim postavkama za različite vrste opterećenja - OLTP i DSS. A tokovi podataka nižu se između njih.

to je sve? Čini se da je problem riješen. Što je slijedeće?
A onda tvrtke rastu, njihove potrebe za informacijama se množe. Raste i broj interakcija s 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 sustava koji generiraju informacijsko – izvorne sustave u poduzeću. I prije ili kasnije, bit će potrebno vidjeti i usporediti informacije primljene iz različitih sustava. Tako se u tvrtki pojavljuju skladišta podataka – nova klasa sustava.
Općeprihvaćena definicija ove klase sustava je sljedeća.

Skladište podataka (ili skladište podataka)- podatkovnu bazu podataka specifičnu za domenu posebno dizajniranu i dizajniranu za pripremu izvješća i poslovne analize kako bi se podržalo donošenje odluka u organizaciji

Tako, konsolidacija podaci iz različitih sustava, mogućnost gledanja na njih na određeni „uniforman“ (unificiran) način – to je jedno od ključnih svojstava sustava iz klase skladišta podataka. To je razlog zašto su se spremišta pojavila tijekom evolucije IT sustava.

Ključne značajke skladišta podataka

Pogledajmo pobliže. Koje su ključne značajke ovih sustava? Po čemu se skladišta podataka razlikuju od drugih IT sustava poduzeća?

Prvo, to su velike količine. Jako veliko. VLDB - tako vodeći dobavljači nazivaju takve sustave kada daju svoje preporuke o korištenju svojih proizvoda. Iz svih sustava tvrtke 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 život ispostavlja kompliciranijim).

Drugo, ovo su povijesni podaci - "Korporativna memorija" - tzv. skladišta podataka. Što se tiče rada s vremenom u repozitorijumima, sve je prilično zanimljivo. U računovodstvenim sustavima podaci su trenutno ažurni. Tada korisnik izvodi neku vrstu operacije - i podaci se ažuriraju. Istodobno, povijest promjena možda neće biti spremljena - ovisi o računovodstvenoj praksi. Uzmimo, na primjer, stanje na bankovnom računu. Može nas zanimati trenutni saldo u "sada", na kraju dana ili u vrijeme nekog događaja (na primjer, u vrijeme izračunavanja bodovnog rezultata). Dok je prva dva prilično lako riješiti, potonji će najvjerojatnije zahtijevati posebne napore. Korisnik se, radeći sa pohranom, može pozvati na prošla razdoblja, usporediti ih s trenutnim itd. Upravo te mogućnosti vezane uz vrijeme značajno razlikuju skladišta podataka od računovodstvenih sustava – dobivanje stanja podataka u različitim točkama na vremenskoj osi – do određene dubine u prošlosti.

Treće, jest konsolidacija i objedinjavanje podataka ... Da bi njihova zajednička analiza postala moguća, potrebno ih je dovesti u zajednički oblik - unificirani model podataka , usporedite činjenice s 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 biti ista stvar. Kako osigurati "jedinstveni pogled" uz zadržavanje specifične vizije određene grupe korisnika?

Četvrto, ovo je rad s kvaliteta podataka ... U procesu učitavanja podataka u pohranu, oni se čiste, izvode opće transformacije i transformacije. Opće transformacije moraju se obaviti na jednom mjestu - a zatim koristiti za izradu raznih izvješća. Time će se izbjeći nedosljednosti koje smetaju poslovnim korisnicima — posebice rukovoditeljima koji se za stol stavljaju s brojevima iz različitih odjela koji se međusobno ne slažu. Loša kvaliteta podataka stvara pogreške i odstupanja u izvješćima, a posljedica toga je smanjenje razine povjerenje korisnika na cijeli sustav, na cijelu analitičku službu u cjelini.

Arhitektonski koncept

Svatko tko je naišao na spremište najvjerojatnije je uočio nekakvu "slojevitu strukturu" - od upravo je ova arhitektonska paradigma zaživjela za sustave ove klase. I nije slučajno. Slojevi za pohranu mogu se percipirati kao zasebne komponente sustava - s vlastitim zadacima, područjem odgovornosti, "pravilima igre".
Slojevita arhitektura je sredstvo za suočavanje sa složenošću sustava – svaka sljedeća razina apstrahirana je od složenosti interne implementacije prethodne. Ovaj pristup vam omogućuje da izdvojite zadatke iste vrste i riješite ih na ujednačen način, bez ponovnog izmišljanja "kotača" od nule svaki put.
Idejni arhitektonski dijagram shematski je 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 kvalitete.

Primarni podatkovni sloj - primarni podatkovni sloj (ili uprizorenje , ili operativni sloj ) - dizajniran za učitavanje iz izvornih sustava i spremanje primarnih informacija, bez transformacija - u izvornoj kvaliteti i podržava potpunu povijest promjena.
Zadatak ovog sloja- apstrahirati sljedeće slojeve pohrane iz fizičke strukture izvora podataka, metoda prikupljanja podataka i metoda odvajanja delte promjena.

Core Data Layer - jezgrena pohrana - središnja komponenta sustava koja razlikuje pohranu od samo "platforme batch integracije" ili "big data dump", 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 se posao obavlja s kvalitetom podataka i općim transformacijama, koje mogu biti prilično složene.
Zadatak ovog sloja- apstrahirati svoje potrošače od značajki logičkog uređaja izvora podataka i potrebe za usporedbom podataka iz različitih sustava, kako bi se osigurala cjelovitost i kvaliteta podataka.

Data Mart Layer - analitički vitrine - komponenta čija je glavna funkcija pretvaranje podataka u strukture koje su prikladne za analizu (ako BI radi s izlozima, onda je to, u pravilu, dimenzionalni model), ili prema zahtjevima potrošačkog sustava.
Podatkovne vitrine u pravilu preuzimaju podatke iz jezgre – kao pouzdan i provjereni izvor – t.j. koristite uslugu ove komponente za dovođenje podataka u jedan oblik. Takve ćemo vitrine nazvati redovito ... U nekim slučajevima, izlozi mogu preuzimati podatke izravno iz faze pripreme - radeći s primarnim podacima (u izvornim ključevima). Ovaj se pristup obično koristi za lokalne zadatke gdje nije potrebna konsolidacija podataka iz različitih sustava i gdje je učinkovitost potrebna više od kvalitete podataka. Takve vitrine nazivaju se operativni ... Neki analitički pokazatelji mogu imati vrlo složene metode izračuna. Stoga se za takve netrivijalne izračune i transformacije koristi tzv sekundarne vitrine .
Zadatak sloja Showcase- priprema podataka prema zahtjevima konkretnog potrošača - BI platforme, grupe korisnika ili vanjskog sustava.

Gore opisani slojevi sastoje se od trajnog prostora za pohranu 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 pohranu ili transformaciju podataka na različitim slojevima, ako je to učinkovitije.
Područja pohrane sadrže tehničke (tablice međuspremnika) koje se koriste u procesu transformacije podataka i ciljne tablice na koju se odnosi potrošačka komponenta. Dobra je praksa ciljne tablice "pokriti" pogledima. To olakšava naknadno održavanje i razvoj sustava. Podaci u ciljnim tablicama sva tri sloja označeni su posebnim tehničkim poljima (meta-atributima), koja služe za podršku procesima učitavanja podataka, kao i za omogućavanje informacijske revizije tokova podataka u skladištu.

Također, izdvaja se posebna komponenta (ili skup komponenti) koja pruža servisne funkcije za sve slojeve. Jedna od njegovih ključnih zadaća je kontrolna funkcija - osigurati "jedinstvena pravila igre" za cijeli sustav u cjelini, ostavljajući pravo korištenja različitih opcija za implementaciju svakog od gore opisanih slojeva - uklj. koristiti različite tehnologije za učitavanje i obradu podataka, različite platforme za pohranu itd. nazovimo to servisni sloj ... Ne sadrži poslovne podatke, ali ima svoje strukture za pohranu - 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).

Takva jasna podjela sustava na zasebne komponente značajno povećava upravljivost razvoja sustava:

• smanjena je složenost zadatka koji se postavlja programeru funkcionalnosti jedne ili druge komponente (ne bi trebao istovremeno rješavati pitanja integracije s vanjskim sustavima, razmišljati o postupcima čišćenja podataka i razmišljati o optimalnoj prezentaciji podataka za potrošače) - zadatak je lakše razložiti, procijeniti i izvesti malu isporuku;
• možete se povezati s radom raznih izvođača (pa čak i timova, odnosno izvođača) – jer ovaj vam pristup omogućuje učinkovito paraleliziranje zadataka, smanjujući njihov međusobni utjecaj jedni na druge;
• prisutnost trajne faze omogućuje vam brzo povezivanje izvora podataka bez dizajniranja cijele jezgre ili izloga za cijelo predmetno područje, a zatim postupno dovršavanje izgradnje preostalih slojeva prema prioritetima (štoviše, podaci će već biti u pohrani - dostupni za analitičari sustava, što će uvelike olakšati zadatke naknadnog razvoja pohrane);
• prisutnost jezgre omogućuje da se sav rad s kvalitetom podataka (kao i moguće pogreške i pogreš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 marketa omogućuje vam da uzmete u obzir razlike i specifičnosti razumijevanja podataka koje korisnici različitih odjela mogu imati, a njihov dizajn za BI zahtjeve omogućuje ne samo izdavanje agregiranih brojki, već i osiguranje valjanosti podataka pružanjem mogućnosti za proučiti do primarnih pokazatelja;
• prisutnost servisnog sloja omogućuje vam obavljanje analize podataka od kraja do kraja (podataka), korištenje objedinjenih alata za reviziju podataka, općenite pristupe naglašavanju delta promjena, rad s kvalitetom podataka, upravljanje opterećenjem, praćenje i alate za dijagnostiku pogrešaka i ubrzava rješavanje problema.

Ovaj pristup razgradnji također čini sustav otpornijim na promjene (u usporedbi s "monolitnom strukturom") - osigurava njegovu antikrhkost:

• promjene na dijelu izvornih sustava se obrađuju pri stagingu - u kernelu se modificiraju samo oni streamovi na koje utječu te scenske tablice, učinak na izloge je minimalan ili ga nema;
• promjene zahtjeva potrošača obrađuju se najvećim dijelom na izlozima (ako to ne zahtijeva dodatne informacije kojih još nema u trgovini).

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

Jezgra sustava

Krenimo od sredine – jezgre sustava ili srednjeg sloja. Označen je kao Core Layer. Kernel igra ulogu konsolidacije podataka - dovođenje u uniformne strukture, priručnike, ključeve. Tu se obavlja glavni posao s kvalitetom podataka - čišćenje, transformacija, objedinjavanje.

Prisutnost ove komponente omogućuje vam ponovno korištenje tokova podataka koji pretvaraju primarne podatke primljene iz izvornih sustava u određeni unificirani format, slijedeći opća pravila i algoritme, a ne ponavljate implementaciju iste funkcionalnosti zasebno za svaki izlog aplikacije, koji u uz neučinkovito korištenje resursa, može dovesti i do odstupanja u podacima.
Jezgra repozitorija implementirana je u model podataka, u općem slučaju različit kako od modela izvornih sustava, tako i od formata i struktura potrošača.

Osnovni model skladišta i model podataka poduzeća

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

Mit 1. Model podataka poduzeća je ogroman model s tisućama entiteta (tablica).
Zapravo. U bilo kojem predmetnom području, u bilo kojoj poslovnoj domeni, u podacima bilo koje tvrtke, pa i najsloženije, malo je osnovnih entiteta - 20-30.

Mit 2. Nema potrebe razvijati nikakav "vlastiti model" - kupujemo industrijski referentni model - i radimo sve u skladu s njim. Trošimo novac - ali dobivamo zajamčeni rezultat.
Zapravo. Referentni modeli doista mogu biti vrlo korisni jer sadrže industrijsko iskustvo u modeliranju ovog područja. Iz njih možete izvući ideje, pristupe, prakse imenovanja. Provjerite "dubinu pokrivenosti" područja kako se nešto važno ne bi previdjelo. No, malo je vjerojatno da ćemo takav model moći koristiti iz kutije – takav kakav jest. To je isti mit kao, na primjer, kupnja ERP sustava (ili CRM) i njegova implementacija bez ikakvog "zatezanja za sebe". Vrijednost takvih modela rađa se u njihovoj prilagodbi stvarnosti ovog konkretnog posla, ove konkretne tvrtke.

Mit 3. Razvoj modela jezgrenog spremišta može potrajati mnogo mjeseci, a tijekom tog vremena projekt će zapravo biti zamrznut. Osim toga, zahtijeva suludu količinu sastanaka i puno ljudi.
Zapravo. Model repozitorija može se razvijati sa spremištem iterativno, dio po dio. Za nepokrivena područja postavljaju se "točke ekspanzije" ili "stubovi". primjenjuju se neki "univerzalni dizajni". Pritom morate znati kada stati kako ne biste dobili super-univerzalnu stvar od 4 tablice, u koju je teško i "ubaciti podatke" i (još teže) doći do njih. I što je izrazito suboptimalno u smislu izvedbe.

Stvarno je potrebno vrijeme za razvoj modela. Ali ovo nije vrijeme utrošeno na "crtanje entiteta" - to je vrijeme potrebno za analizu predmetnog područja, razumijevanje kako su podaci raspoređeni. Zato su u ovaj proces vrlo usko uključeni analitičari, a uključeni su i razni poslovni stručnjaci. I to se radi točkasto, selektivno. A ne organiziranjem sastanaka sa suludim brojem ljudi, slanjem ogromnih upitnika itd.
Dobra analiza poslovanja i sustava ključna je u izgradnji temeljnog modela skladišta. Treba puno razumjeti: gdje (u kojim sustavima) nastaju podaci, kako rade, u kojim poslovnim procesima kruže itd. Kvalitativna analiza nikada nije štetila niti jednom sustavu. Dapače, naprotiv, problemi proizlaze 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 tvrtki. A proces dizajna je više poput "iskopa". Model se pažljivo i pažljivo izdvaja iz "tla" korporativnih podataka i stavlja u strukturiranu formu.

Mit 4. Naše poslovanje je toliko dinamično u našoj tvrtki, a sve se mijenja tako brzo da nam je beskorisno praviti model – zastarjet će prije nego što ovaj dio sustava pustimo u rad.
Zapravo. Podsjetimo da je temeljni čimbenik stabilnost. I iznad svega, topologija modela. Zašto? Jer upravo je ta komponenta središnja i utječe na sve ostalo. Stabilnost je također uvjet za model kernela. Ako model prebrzo zastari, onda je pogrešno dizajniran. Za njegov razvoj odabrani su krivi pristupi i “pravila igre”. A to je i stvar kvalitativne analize. Ključni entiteti korporativnog modela rijetko se mijenjaju.
Ali ako nam padne na pamet da za tvrtku koja se bavi prodajom, recimo, slastica, umjesto imenika “Proizvodi” pravimo “Slatkiše”, “Kolače” i “Pite”. Zatim kada se pizza pojavi na popisu robe - da, morat ćete unijeti puno novih tablica. A ovo je samo pitanje pristupa.

Mit 5. Stvaranje korporativnog modela vrlo je 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 se struktura može revidirati i modificirati. Samo ne trebate zaboraviti na ovu njegovu kvalitetu. Ali to uopće 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, sustav referentnih podataka (ili sustav upravljanja glavnim podacima - MDM), onda bi on već trebao odgovarati korporativnom modelu na prijateljski način (pogotovo ako je nedavno osmišljen i nije imao vremena za steći "stranu", "tradicije "I privremene kolibe). Ispada da za ovaj slučaj - ne trebamo model kernela?
Zapravo. Da, u ovom slučaju je izgradnja temeljnog modela spremišta uvelike olakšana – budući da slijedimo gotov konceptualni model najviše razine. Ali to uopće nije isključeno. Zašto? Jer pri izgradnji modela određenog sustava vrijede neka njegova vlastita pravila - koje vrste tablica koristiti (za svaki entitet), kako inačiti podatke, s kojom granularnošću zadržati povijest, koje meta-atribute (tehnička polja) koristiti) itd.

Osim toga, koliko god divan i sveobuhvatan sustav referentnih podataka i MDM imamo, u pravilu će postojati nijanse povezane s postojanjem lokalnih imenika "otprilike isto" u drugim računovodstvenim sustavima. I ovaj problem, htjeli mi to ili ne, morat će se riješiti u repozitoriju – uostalom, ovdje se prikupljaju izvješćivanje i analitika.

Primarni podatkovni sloj (ili povijesni scenski ili operativni sloj)

Na njemu je označen kao primarni podatkovni sloj. Uloga ove komponente: integracija s izvornim sustavima, učitavanje i pohranjivanje primarnih podataka, kao i preliminarno čišćenje podataka - provjera usklađenosti s pravilima formatno-logičke kontrole, fiksiranom u "sporazumu o sučelju interakcije" s izvorom.
Osim toga, ova komponenta rješava vrlo važan problem za spremište - dodjeljivanje "prave delte promjena" - bez obzira na to dozvoljava li vam izvor praćenje promjena u podacima ili ne i kako (po kojem kriteriju se mogu "uloviti" ). Č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 pohranjeni su u strukturama što bliže izvornom sustavu – 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 "uprizorenje"? Činjenica je da je ranije, prije "ere velikih podataka i VLDB", prostor na disku bio vrlo skup - a često su primarni podaci, ako su se sačuvali, bili samo u ograničenom vremenskom razdoblju. A često se naziva i naziv "uprizorenje". čistiti pufer.
Sada su tehnologije iskoračile - i možemo si priuštiti ne samo pohranjivanje svih primarnih podataka, već i njihovo historiziranje uz mogući stupanj granularnosti. To ne znači da ne bismo trebali kontrolirati rast podataka i ne eliminira potrebu za upravljanjem životnim ciklusom informacija, optimizirajući cijenu pohrane podataka, ovisno o „temperaturi“ korištenja – tj. preuzimanje "hladnih podataka" koji su manje traženi na jeftinije medije i platforme za pohranu.

Što nam daje prisutnost "historiciziranog uprizorenja":

• mogućnost pogreške (u strukturama, u algoritmima transformacije, u granularnosti povijesti) - nakon što smo u potpunosti historizirali primarne podatke u zoni dostupnosti za pohranu, uvijek možemo ponovno učitati naše tablice;
• prilika za razmišljanje - možemo uzeti svoje vrijeme da razradimo veliki fragment kernela u ovoj posebnoj iteraciji razvoja pohrane, budući da u našoj će inscenaciji, u svakom slučaju, postojati, i to s ravnomjernim vremenskim horizontom (postojat će jedna točka "povijesne reference");
• mogućnost analize - spremit ćemo i one podatke kojih više nema u izvoru - mogli bi se tamo prebrisati, otići u arhivu itd. - kod nas ostaju dostupni za analizu;
• mogućnost revizije informacija - zahvaljujući najdetaljnijim primarnim informacijama, tada možemo shvatiti kako je preuzimanje funkcioniralo za nas, da smo završili s takvim brojkama (za to također trebamo imati oznake meta atributima i odgovarajućim metapodacima na kojoj radi preuzimanje - o tome odlučuje sloj usluge).

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

• bilo bi zgodno postaviti zahtjeve za transakcijski integritet ovog sloja, ali praksa pokazuje da je to teško postići (to znači da u ovom području ne jamčimo referentni integritet nadređenih i podređenih tablica) - usklađivanje integriteta događa se na sljedećim slojevi;
• ovaj sloj sadrži vrlo velike količine (najopsežnije na skladištu - unatoč svoj zalihosti analitičkih struktura) - i morate biti u stanju nositi se s takvim volumenima - i u smislu opterećenja i u smislu zahtjeva (inače, možete ozbiljno pogoršavaju performanse cijelog skladišta).

Što je još zanimljivo reći o ovom sloju.
Prvo, ako se odmaknemo od paradigme „procesa utovara od kraja do kraja“, onda nam pravilo „karavan se kreće brzinom posljednje deve“ više ne funkcionira, točnije, napuštamo „karavan“ princip i prijeđite na princip “transportne trake”: uzeli smo podatke iz izvora - stavili u vaš sloj - spremni za preuzimanje sljedećeg dijela. Znači da
1) ne čekamo da se obrada dogodi na drugim slojevima;
2) nismo ovisni o rasporedu za pružanje podataka od strane drugih sustava.
Jednostavno rečeno, planiramo proces učitavanja koji uzima podatke iz jednog izvora putem specifičnog načina povezivanja s njim, provjerava, dodjeljuje delta - i stavlja podatke u ciljne scenske tablice. I to je sve.

Drugo, ti su procesi, kao što vidite, vrlo jednostavni - moglo bi se reći trivijalno, s gledišta logike. To znači da se mogu vrlo dobro optimizirati i parametrirati, smanjujući opterećenje našeg sustava i ubrzavajući proces povezivanja izvora (vrijeme razvoja).
Da bi se to dogodilo, morate vrlo dobro poznavati osobitosti tehnoloških značajki platforme na kojoj ova komponenta radi – i tada možete napraviti vrlo učinkovit alat.

Sloj vitrine

Data Mart Layer je odgovoran za pripremu i pružanje podataka krajnjim korisnicima – ljudima ili sustavima. Na ovoj se razini u najvećoj mogućoj mjeri uzimaju u obzir zahtjevi potrošača – i logički (konceptualni) i fizički. Usluga bi trebala pružiti točno ono što je potrebno - ni više, ni manje.

Ako je potrošač vanjski sustav, tada, u 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 pripremilo, formiralo izlog, dalo mogućnost inkrementalnog prikupljanja podataka (označavanje meta-atributima za naknadno isticanje delte promjena), a potrošački sustav potom sam kontrolira i odgovoran je za to kako koristi ovaj izlog. Ali postoje neke posebnosti: kada sustav nema aktivnu komponentu za prikupljanje podataka - ili je potrebna vanjska komponenta koja će obavljati integracijsku funkciju, ili će pohrana djelovati kao "integracijska platforma" - te će osigurati ispravan inkrementalni prijenos podataka dalje - izvan skladišta. Ovdje se pojavljuju mnoge nijanse, a pravila interakcije sučelja moraju biti osmišljena i razumjeti obje strane (međutim, kao i uvijek, kada je u pitanju integracija). U pravilu, rutinsko čišćenje/arhiviranje podataka primjenjuje se na takve baze podataka (rijetko je potrebno da se ti "tranzitni podaci" pohranjuju dulje vrijeme).

Najvažniji sa stajališta analitičkih zadataka su vitrine "za ljude" - točnije, za BI alate s kojima rade.
Međutim, postoji kategorija "posebno naprednih korisnika" - analitičara, istraživača podataka - koji ne trebaju BI alate ili regulatorne procese za popunjavanje vanjskih specijaliziranih sustava. Potrebni su im nekakvi "zajednički izlozi" i "vlastiti sandbox", gdje mogu kreirati tablice i transformacije prema vlastitom nahođenju. U tom slučaju, odgovornost spremišta je osigurati da ti zajednički izlozi budu ispunjeni podacima u skladu s propisima.
Zasebno, možemo istaknuti takve potrošače kao Data Mining alati - duboka analiza podataka. Ovi alati imaju svoje zahtjeve za pripremu podataka, a s njima rade i znanstvenici. Za pohranu, zadatak se svodi na - opet, podržati uslugu za učitavanje nekih izloga dogovorenog formata.

No, da se vratimo na analitičke vitrine. To su oni koji su od interesa sa stajališta dizajnera pohrane u ovom podatkovnom sloju.
Po meni, najbolji vremenski provjereni pristup dizajniranju podatkovnih prodajnih mjesta, na koji su sada „naoštrene“ gotovo sve BI platforme, jest pristup Ralpha Kimballa. Poznato je kao dimenzionalno modeliranje - višedimenzionalno modeliranje. Postoji mnogo publikacija na ovu temu. Primjerice, osnovna pravila mogu se pronaći u publikaciji Marge Ross. I naravno, možete preporučiti od gurua za višedimenzionalno modeliranje. Još jedan koristan izvor su Kimballovi savjeti
Višedimenzionalni pristup kreiranju izloga tako je dobro opisan i razrađen - kako od strane "evanđelista metoda" tako i od strane vodećih dobavljača softvera, da nema smisla ovdje se detaljnije zadržavati na njemu - izvorni izvor je uvijek poželjniji .

Htio bih staviti samo jedan naglasak. "Izvještavanje i analitika" je drugačije. Postoji “teško izvješćivanje” – unaprijed naručena izvješća koja se generiraju u obliku datoteka i isporučuju korisnicima putem predviđenih kanala isporuke. A tu su i nadzorne ploče - BI nadzorne ploče. U svojoj srži 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 što možemo utjecati. Što je najviše izgubljenog vremena? Za fizička (disk) očitanja baze podataka, za prijenos podataka preko mreže. Kako smanjiti količinu očitanih i prenesenih podataka u jednom zahtjevu? Odgovor je očit i jednostavan: trebate ili agregirati podatke, ili primijeniti filtar na velike tablice stvarnih tablica koje sudjeluju u upitu i isključiti spajanje velikih tablica (reference na tablice činjenica trebale bi proći samo kroz dimenzije).

Čemu služi BI? Kako je to zgodno? Zašto je višedimenzionalni model učinkovit?
BI omogućuje korisniku pokretanje takozvanih ad hoc upita. Što to znači? To znači da ne znamo točan zahtjev unaprijed, ali znamo koje pokazatelje u kojim aspektima korisnik može zatražiti. Korisnik generira takav upit odabirom odgovarajućih BI filtara. A zadatak BI developera i dizajnera izloga je osigurati takvu logiku aplikacije da se podaci ili filtriraju ili agregiraju, sprječavajući situaciju kada se traži previše podataka – i aplikacija “visi”. Obično započinju s agregiranim brojevima, zatim dublje prodiru u detaljnije podatke, ali usput instaliraju potrebne filtre.

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

Tako se "pokušajem i pogreš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 podatke uzmemo iz "jezgre", tada će takva obrada izloga biti lokalne prirode, a da ni na koji način ne utječe na složenu obradu primarnih podataka dobivenih izravno iz izvornih sustava - samo "prebacujemo" podatke u format pogodan za BI. A to si možemo priuštiti mnogo puta, na različite načine, u skladu s 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 odgovoran je za implementaciju općih (servisnih) funkcija koje se mogu koristiti za obradu podataka u različitim slojevima pohrane - upravljanje opterećenjem, upravljanje kvalitetom podataka, alati za dijagnostiku problema i praćenje itd.
Prisutnost ove razine osigurava transparentnost i strukturirane tokove podataka u pohrani.

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

• područje metapodataka - koristi se za mehanizam kontrole učitavanja podataka;
• područje kvalitete podataka - za provedbu izvanmrežnih provjera kvalitete podataka (tj. onih koje nisu izravno ugrađene u ETL procese).

Proces upravljanja preuzimanjem možete organizirati na različite načine. Jedan mogući pristup je sljedeći: cijeli skup tablica za pohranu dijelimo u module. Modul može uključivati ​​tablice samo jednog sloja. Tablice uključene u svaki modul učitavaju se u zasebnom procesu. nazovimo to kontrolni proces ... Početak procesa kontrole postavlja se prema vlastitom rasporedu. Kontrolni proces orkestrira pozive atomskim procesima, od kojih svaki učitava jednu ciljnu tablicu, a također sadrži neke opće korake.
Očito, dovoljno je jednostavno podijeliti scenske tablice u module - po izvornim sustavima, odnosno po njihovim spojnim točkama. Ali za kernel, to je već teže učiniti. tu moramo osigurati integritet podataka, što znači da trebamo uzeti u obzir ovisnosti. Oni. doći će do kolizija koje treba riješiti. I postoje različite metode za njihovo rješavanje.

Važna točka u upravljanju opterećenjem je razviti dosljedan pristup rukovanju pogreškama. Pogreške se klasificiraju 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 pohrani. Dakle, upravljanje opterećenjem nije samo pokretanje procesa, već i njihovo zaustavljanje, kao i sprječavanje nepravovremenog (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 točkama koje se koriste za održavanje inkrementa (koji je proces pročitao do koje točke) i druge informacije o uslugama koje su potrebne za funkcioniranje sustava.
Važno je napomenuti da su sve ciljne tablice u svim slojevima označene posebnim skupom meta-polja, od kojih je jedno identifikator procesa koji je ažurirao ovaj redak. Za tablice unutar spremišta, ovo označavanje procesa omogućuje dosljedan način naknadnog isticanja delte promjena. Prilikom učitavanja podataka u primarni podatkovni sloj, situacija je složenija - algoritam raspodjele delta za različite učitane objekte može biti različit. No, logika obrade prihvaćenih promjena i njihova uvrštavanja u ciljne tablice za jezgru i izloge puno je kompliciranija nego za staging, gdje je sve sasvim trivijalno - lako je parametrirati i razmišljati o standardnim koracima (procedurama) koje se mogu ponovno koristiti.

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 sustav točno na vrijeme. Oni. ovdje se udaljavamo od raširene paradigme isključivo "noćnog preuzimanja podataka", te preuzimamo u malim obrocima tijekom dana - čim su podaci gotovi u raznim izvorima: što je došlo - to je skinuto. U isto vrijeme imamo mnogo paralelnih procesa. A "vrući rep" svježih podataka stalno će "treptati" - i s vremenom se izjednačiti. Moramo uzeti u obzir takvu značajku. I, ako je potrebno, formirajte prilagođene vitrine s "kriškama", gdje je sve već holistički. Oni. nemoguće je istovremeno postići i učinkovitost i dosljednost (cjelovitost). Trebamo balans – negdje je jedno važno, negdje drugo.

Neophodno je osigurati objekte za snimanje i praćenje. Dobra je praksa koristiti upisane događaje, gdje možete postaviti različite parametre i prilagoditi sustav obavijesti - pretplatiti se na određene događaje. Jer vrlo je važno da kada je potrebna intervencija administratora sustava, on to što prije sazna i dobije sve potrebne dijagnostičke informacije. Dnevnici se također mogu koristiti za analizu post-fakto problema, kao i za istraživanje incidenata kvarova sustava, uklj. kvaliteta podataka.

Projektiranje i održavanje modela podataka skladišta

Zašto je važno obratiti pažnju na dizajn modela podataka pri razvoju bilo kojeg sustava u kojem je uključena baza podataka (a posebno u skladištu)? Zašto jednostavno ne bacite skup tablica 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 sprječava da skicirate tablice - i počnete ih koristiti. Ako ... ako u isto vrijeme u glavi (!) Programer ima koherentnu opću sliku strukture koju oblikuje. Što ako postoji nekoliko programera? Što ako netko drugi koristi ove tablice? A što 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 to shvatiti, i "odgonetnuti slike na komadu papira", i "obrisati - srediti" podatke. No, puno je lakše, jasnije i brže koristiti gotov artefakt – podatkovni model. I također razumjeti "logiku njegovog uređaja" - tj. bilo bi lijepo imati opća pravila igre.

A najvažnije nije ni to. Najvažnije je da smo pri projektiranju modela prisiljeni (samo bez opcija!) pobliže i dublje proučiti predmetno područje, značajke podatkovnog uređaja i njihovu upotrebu u raznim poslovnim slučajevima. A ona pitanja koja bismo lako "odgurnuli" kao složena, "zamagljeni" bacanjem naših znakova, ne pokušavajući precizno oblikovati model - bit ćemo prisiljeni isporučiti i odlučiti sada, prilikom analize i projektiranja, a ne kasnije - kada ćemo graditi izvještaje i razmišljati o tome “kako smanjiti nespojivo” i “izmisliti kotač” svaki put.

Ovaj pristup je jedna od onih inženjerskih praksi koja vam omogućuje stvaranje antikrhkih sustava. Budući da su jasno raspoređeni, transparentni, prikladni za razvoj, a i njihove "granice krhkosti" su odmah vidljive - možete točnije procijeniti "razmjere katastrofe" kada se pojave novi zahtjevi i vrijeme potrebno za redizajn (ako je potrebno).
Dakle, model podataka jedan je od glavnih artefakata koji se moraju održavati tijekom razvoja sustava. Na prijateljski način, trebao bi biti "na stolu" svakog analitičara, programera itd. - svi koji sudjeluju u projektima razvoja sustava.

Dizajniranje modela podataka velika je i zasebna tema. Postoje dva glavna pristupa dizajnu skladišta.
Pristup dobro funkcionira za kernel Entitet-odnos - kada se na temelju proučavanja predmetnog područja, točnije njegovog odabranog područja, gradi normalizirani (3NF) model. Ovdje je u igri isti "korporativni model" o kojem smo gore govorili.

Prilikom oblikovanja vitrina prikladan je višedimenzionalni model ... Ovaj pristup dobro se uklapa u razumijevanje poslovnih korisnika – jer to je model koji je jednostavan i prikladan za ljudsku percepciju – ljudi operiraju s razumljivim i poznatim konceptima metrike (pokazatelja) i odjeljaka po kojima se analiziraju. A to vam omogućuje da jednostavno i jasno izgradite proces prikupljanja zahtjeva - crtamo skup "matrica odjeljaka i pokazatelja", 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 agregiranja.

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

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

• zadatak izgradnje konceptualnog (logičkog) modela kernela - analiza sustava i poslovanja - istraživanje predmetnog područja, ulazak u detalje i uzimanje u obzir nijansi "živih podataka" i njihove upotrebe u poslovanju;
• zadatak izgradnje modela analize – a zatim i konceptualnog (logičkog) modela izloga;
• zadatak izgradnje fizičkih modela - upravljanje redundantnošću podataka, optimizacija uzimajući u obzir osobitosti DBMS-a za upite i učitavanje podataka.

Prilikom izrade konceptualnih modela možda nećemo uzeti u obzir osobitosti pojedinog DBMS-a za koji projektiramo strukturu baze podataka. Štoviše, možemo koristiti jedan konceptualni model za izradu nekoliko fizičkih - za različite DBMS.

Hajde da rezimiramo.

• Model podataka nije skup "lijepih slika", a proces njegovog dizajna nije proces njihovog crtanja. Model odražava naše razumijevanje domene. A proces sastavljanja je proces njegovog proučavanja i istraživanja. Ovo je izgubljeno vrijeme. I uopće ne "crtati i slikati".
• Model podataka je artefakt dizajna, način razmjene informacija na strukturiran način između članova tima. Da bi se to učinilo, mora biti svima jasno (to je predviđeno zapisom i objašnjenjem) i dostupno (objavljeno).
• Model podataka se ne stvara jednom i zamrzava, već se stvara i razvija u procesu razvoja sustava. Pravila za njegov razvoj postavljamo sami. A možemo ih promijeniti ako vidimo – kako to učiniti bolje, lakše, učinkovitije.
• Model podataka (fizički) omogućuje vam da konsolidirate i iskoristite skup najboljih praksi usmjerenih na optimizaciju – t.j. koristiti tehnike koje su već funkcionirale za ovaj DBMS.

Značajke projekata skladišta podataka

Zadržimo se na specifičnostima projekata u okviru kojih tvrtka gradi i razvija skladišta podataka. A pogledajmo ih s gledišta utjecaja arhitektonskog aspekta. Zašto je za takve 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ćuje vam učinkovitu distribuciju posla 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 "razvoj po narudžbi", 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 sustavi), skup standardnih BI panela i izvješća. Ali u praksi se skladištenje rijetko implementira - kao "kutija". Radim sa repozitorijumima oko 10 godina i nikada nisam vidio takvu priču. Uvijek postoje neke nijanse povezane s jedinstvenim značajkama tvrtke - i poslovnim i IT krajolikom. Stoga je pomalo nepromišljeno nadati se da će arhitekturu osigurati "dobavljač" koji isporučuje rješenje. Arhitektura takvih sustava često "sazrijeva" unutar same organizacije. Ili ga formiraju stručnjaci tvrtke izvođača, koja je glavni izvršitelj projekta.

Skladište podataka je integracijski projekt

Skladište podataka učitava i obrađuje informacije iz mnogih izvornih sustava. A kako biste s njima održali "prijateljske odnose", s njima morate biti izuzetno oprezni. Posebno je potrebno minimizirati opterećenje izvornih sustava, uzeti u obzir prozore "dostupnost i nedostupnost", odabrati interakcijska sučelja uzimajući u obzir njihovu arhitekturu itd. Tada će pohrana moći pokupiti podatke što je prije moguće i potrebnom učestalošću. U suprotnom ćete biti "presađeni" u rezervni krug, koji se ne ažurira najoperativnom frekvencijom.
Uz to, potrebno je uzeti u obzir i „ljudski faktor“. Integracija se ne odnosi samo na interakciju strojeva. To je i komunikacija među ljudima.

Skladište podataka je zajednički projekt

U velikoj tvrtki takav sustav rijetko može napraviti samo jedan tim. Ovdje u pravilu radi nekoliko timova, od kojih svaki rješava određeni problem.

Arhitektura bi trebala osigurati mogućnost organiziranja njihova paralelnog rada, uz zadržavanje integriteta i izbjegavanje dupliciranja iste funkcionalnosti na različitim mjestima, od strane različitih ljudi. Osim nepotrebnog truda, takvo umnožavanje može kasnije dovesti do neslaganja podataka.

Osim toga, kada je toliko ljudi i timova, često raštrkanih, uključeno u razvoj sustava, neizbježno se postavlja pitanje: kako izgraditi međusobnu komunikaciju i informacijsku interakciju. Što se više koriste standardni i razumljiviji pristupi i prakse, to je lakše, praktičnije i učinkovitije organizirati 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 sustava

Da pojasnimo - izjava vrijedi za "živu", radnu pohranu, integriranu s ključnim izvorima, koja posjeduje povijesne podatke i pruža informacijske i analitičke usluge mnogim odjelima tvrtke.

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

Drugo, ako pohrana ima ispravnu arhitekturu, onda vrlo lako može preživjeti promjene izvornih sustava, i pojavu novih zahtjeva krajnjih korisnika, te rast volumena podataka.
Ako je arhitektura ispravna, tokovi informacija transparentni, onda se takav sustav može razvijati dugo vremena bez rizika da se zaglavi u situaciji prilikom izmjena zbog poteškoća u procjeni utjecaja.

Postupni iterativni razvoj

Posljednje što bi Kupac želio, upuštajući se u priču s repozitorijem, jest zamrznuti svoje zahtjeve na godinu-dvije, dok se ne osmisli potpuni korporativni model podataka, svi izvori budu u potpunosti povezani itd.

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

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

Iako treba napomenuti da se “čuda ne događaju” – a za “početak” također treba vremena. Za pohrane može biti prilično velik - budući da se radi o velikim količinama podataka, to su povijesni 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 s izvornim sustavima i niz "pokušaja i pogrešaka", uključujući testove opterećenja na stvarnim podacima.

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

Teško je izdvojiti jednog poslovnog kupca za skladište podataka. I vjeruje se (ne bez razloga) da je ključni čimbenik uspjeha projekta izgradnje skladišta podrška menadžmenta tvrtke - izravno 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 skupine. Stoga se repozitorij često razvija u okviru nekoliko paralelnih projekata.

Balans inovativnosti i provjerenih rješenja

Unatoč činjenici da je tema pohrane 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 prije postojala zbog skupih i sporih diskova, skupe memorije itd. - sada su uklonjeni. Ujedno je došlo vrijeme za reviziju nekih arhitektonskih pristupa. Štoviše, to se odnosi i na tehnološke platforme i na arhitekturu primijenjenih sustava koji se na njima temelje.

Ovdje je važno uspostaviti ravnotežu - i održavati prilično „zeleni“ pristup resursima i pohranjenim informacijama. Inače, skladište možete vrlo brzo pretvoriti u polustrukturirano "smetlište", u kojem, ako će se to moći shvatiti, onda uz dosta truda.
Da, imamo više mogućnosti, ali to ne znači da trebamo negirati 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žavati ravnotežu znači koristiti nove metode i pristupe gdje otvaraju nove mogućnosti, ali istovremeno koristiti stare provjerene - za rješavanje hitnih problema koji nisu otkazani.
Što možemo učiniti kao programeri i dizajneri aplikacijskih rješenja? Prije svega, upoznati i razumjeti tehnološke promjene platformi na kojima radimo, njihove mogućnosti, značajke i granice primjene.

Pogledajmo DBMS kao najkritičniju i najvažniju tehnološku platformu za pohranu 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 dobavljači objavljuju razne opcije - za aplikacije različitih klasa (OLTP, DSS & DWH). Osim toga, pojavljuju se dodatne mogućnosti za rad s tekstom, geopodacima itd.

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

Očigledno, centralizacija i specijalizacija su dva komplementarna trenda koji se povremeno zamjenjuju, osiguravajući razvoj i ravnotežu. Kao i evolucijski (postupni) postupni razvoj i kardinalne promjene. Primjerice, 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. No, 10 godina kasnije objavljuje radove u kojima najavljuje preduvjete za početak nove ere u svijetu DBMS-a – na temelju njihove specijalizacije.
On se usredotočuje 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 podjelu aplikacija u 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), izvorno kreiran posebno za sustave klase skladišta podataka. Ovaj je proizvod 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ćuje nam stvaranje zaista zanimljivih i korisnih rješenja. I dovedite ih u implementaciju, uživajući u činjenici da se vaši razvoji koriste u stvarnom radu i da su korisni.

Epilog

U pripremi ovog članka pokušao sam se prvenstveno usredotočiti na arhitekte, analitičare i programere koji izravno rade sa skladištima podataka. No, pokazalo se da je neminovno “malo proširila temu” – i ostale kategorije čitatelja su pale u vidno polje. Neke će se točke činiti kontroverznima, neke nisu jasne, neke su očite. Ljudi su različiti – različitog porijekla, podrijetla i položaja.
Na primjer, tipična menadžerska pitanja su "kada zaposliti arhitekte?", "Kada raditi arhitekturu?" zvuči za nas (programere, dizajnere) prilično čudno, jer za nas se arhitektura sustava pojavljuje s njegovim rođenjem - nije važno jesmo li toga svjesni ili ne. Čak i ako ne postoji formalna uloga arhitekta u projektu, normalni programer uvijek "uključuje svog vlastitog internog arhitekta".

Uglavnom, nije važno tko točno obavlja ulogu arhitekta - važno je da netko postavlja slična pitanja i istražuje odgovore. Ako je arhitekt jasno izdvojen, to samo znači da je on prvenstveno odgovoran za sustav i njegov razvoj.
Zašto sam smatrao da je tema "antifragilnosti" relevantna za ovu temu?

"Jedinstvenost antifragilnosti je u tome što nam omogućuje da radimo s nepoznatim, da radimo nešto u uvjetima kada ne razumijemo što točno radimo i da postignemo uspjeh."/ Nassim N. Talb /

Stoga kriza i visok stupanj neizvjesnosti nisu izgovor u prilog izostanku arhitekture, već čimbenici koji pojačavaju njezinu potrebu.

Zaitsev S.L., dr. sc.

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 razinu vještina za svaku, a svaka osoba može imati samo dvije vještine, možemo stvoriti entitet prikazan na Sl. 1.6. Ovdje je entitet OSOBA s dva atributa za pohranjivanje vještina i razinom vještina za svaki.

Riža. 1.6. Ovaj primjer koristi grupe koje se ponavljaju.

Problem s ponavljajućim skupinama je taj što ne možemo točno znati koliko vještina osoba može imati. U stvarnom životu, neki ljudi imaju jednu vještinu, neki imaju nekoliko, a neki još nemaju nijednu. Slika 1.7 prikazuje model sveden na prvi normalni oblik. Obratite pažnju na dodano ID vještine koje svaki jedinstveno identificira VJEŠTINA.

Riža. 1.7. Model sveden na prvi normalni oblik.

Jedna činjenica na jednom mjestu

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

Redundantnost zahtijeva dodatni prostor, ali iako je učinkovitost memorije važna, pravi problem leži negdje drugdje. Osiguravanje sinkronizacije redundantnih podataka je pretjerano i uvijek riskirate sukob vrijednosti.

U prethodnom primjeru VJEŠTINA ovisi o ID osobe i od ID vještine. To znači da nećete imati VJEŠTINA dok se ne pojavi OSOBA, posjedujući ovu vještinu. To također otežava promjenu naziva vještine. Potrebno je pronaći svaki unos s 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 dodani entitet VJEŠTINA, i atribut TITULA vještina se prenosi na ovaj entitet. Razina vještine ostala je, odnosno, na raskrižju OSOBE i VJEŠTINA.

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

Svaki atribut ovisi o ključu

Svaki atribut entiteta mora ovisiti o primarnom ključu tog entiteta. U prethodnom primjeru Skolsko ime i Geografsko područje prisutna u tablici 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.

Riža. 1.9. U trećem normalnom obliku Skolsko ime i Geografska regija prenijeti na entitet, gdje njihove vrijednosti ovise o ključu.

Odnosi mnogo-prema-mnogima

Odnos mnogo-prema-mnogima odražavaju stvarnost okolnog svijeta. Imajte na umu da na slici 1.9 postoji odnos više prema mnogo između OSOBNO i ŠKOLA... Stav točno odražava činjenicu da OSOBA može studirati u mnogim ŠKOLE i u ŠKOLA može puno naučiti OSOBA. Da bi se postigao četvrti normalni oblik, stvara se asocijativni entitet koji eliminira odnos monogija prema mnogima generiranjem zasebnog unosa za svaku jedinstvenu kombinaciju škole i osobe. Slika 1.10 prikazuje model u četvrtom normalnom obliku.

Riža. 1.10. U četvrtom normalnom obliku, odnos monogo-prema-mnogo između OSOBNO 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 se činiti zastrašujućim. Zamislite ih jednostavno kao formule za postizanje normalizacije. Normalni oblici temelje se na relacijskoj algebri i mogu se tumačiti kao matematičke transformacije. Iako ova knjiga nije posvećena detaljnoj raspravi o normalnim oblicima, modelarima se potiče da dublje pogledaju tu temu.

U danoj relaciji R, atribut Y 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 točno jednom Y vrijednost u R (u bilo kojem trenutku). Atributi X i Y mogu biti složeni (Datum CJ. Uvod u sustave baza podataka. 6. izdanje. Ed. Williams: 1999., 848 str.).

Relacija R odgovara prvom normalnom obliku (1NF) ako i samo ako sve domene koje 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č potpuno je ovisan o primarnom ključu (Datum, ibid.).

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

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

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

MVD (viševrijedna ovisnost) je ovisnost s više vrijednosti. Koristi se samo za entitete s tri ili više atributa. U ovisnosti s više vrijednosti, vrijednost atributa ovisi samo o dijelu primarnog ključa.

FD (funkcionalna ovisnost) - funkcionalna ovisnost. Uz funkcionalnu ovisnost, vrijednost atributa ovisi o vrijednosti drugog atributa koji nije dio primarnog ključa.

JD (join dependency) je ovisnost o pridruživanju. Uz ovisnost o uniji, primarni ključ roditeljskog entiteta prati se barem do potomaka treće razine, uz zadržavanje mogućnosti korištenja u uniji od strane izvornog ključa.

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 ovise o A. Drugim riječima, u R postoje samo ovisnosti (FD ili MVD) oblika K®X (tj. funkcionalna ovisnost atributa X o kandidatu za korištenje kao ključ K). Sukladno tome, R ispunjava zahtjeve 4NF ako je u skladu s BCNF-om i svi MVD-ovi su zapravo FD-ovi (Datum, ibid.).

Za peti normalni oblik, relacija R zadovoljava ovisnost 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 mnogi drugi normalni oblici za složene tipove podataka i specifične situacije koje su izvan dosega ove rasprave. Svaki zaljubljenik u razvoj modela želio bi naučiti i druge normalne oblike.

Poslovni normalni oblici

U svojoj knjizi, Clive Finklestein (Uvod u informacijsko inženjerstvo: od strateškog planiranja do informacijskih sustava. Reading, Massachusetts: Addison-Wesley, 1989.) zauzeo je drugačiji pristup normalizaciji. On definira poslovne normalne oblike u smislu prisile na te oblike. Mnogi modelari smatraju ovaj pristup intuitivnijim i pragmatičnijim.

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

Drugi poslovni normalni oblik (2BNF) uklanja atribute koji su djelomično ovisni o primarnom ključu drugom entitetu. Primarni (kompozitni) ključ ovog entiteta je primarni ključ entiteta u kojem se izvorno nalazio, zajedno s dodatnim ključevima o kojima atribut u potpunosti ovisi.

Treći poslovni normalni oblik (3BNF) preuzima atribute koji su neovisni o primarnom ključu u drugi entitet, gdje su potpuno ovisni o primarnom ključu tog entiteta.

Četvrti poslovni normalni oblik (4BNF) uzima atribute koji ovise o vrijednosti primarnog ključa ili su opcijski za sekundarni entitet, gdje u potpunosti ovise o 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 ovisnost između instanci sekundarnog entiteta, ili ako postoji rekurzivna ovisnost između instanci njegovog primarnog entiteta.

Dovršeni logički model podataka

Dovrš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 pokriva početni skup 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 naziv koji odražava njegovo značenje, Booleov tip podataka i jasan, kratak, potpun opis ili definiciju. U budućem blog postu pogledat ćemo početni skup smjernica za pravilno oblikovanje naziva i opisa atributa.

Odnosi trebaju uključivati ​​glagolsku konstrukciju koja opisuje odnos između entiteta, zajedno s karakteristikama kao što su množina, nužnost postojanja ili mogućnost odsutnosti veze.

BILJEŠKA Množina odnos opisuje maksimalni broj sekundarnih instanci entiteta koji se mogu povezati s instancom izvornog entiteta.Nužnost postojanja ilimogućnost odsutnosti odnos se koristi za određivanje minimalnog broja instanci sekundarnog entiteta koji se može povezati s instancom izvornog entiteta.

Fizički model podataka

Nakon što ste izradili cjelovit i adekvatan logički model, spremni ste donijeti odluku o odabiru platforme za implementaciju. Izbor platforme ovisi o zahtjevima za korištenjem podataka i strateškim načelima oblikovanja arhitekture korporacije. Odabir platforme složeno je pitanje izvan dosega ove knjige.

U ERwinu, fizički model je grafički prikaz baze podataka iz stvarnog svijeta. Fizička baza podataka bit će sastavljena od tablica, stupaca i relacija. Fizički model ovisi o platformi odabranoj za implementaciju i zahtjevima za korištenje podataka. Fizički model za IMS bit će vrlo drugačiji od onog za Sybase. Fizički model za OLAP izvješća izgledat će drugačije od modela za OLTP (online obrada transakcija).

Modelar podataka i administrator baze podataka (DBA) koriste logički model, zahtjeve korištenja 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 ta su pitanja detaljnije obrađena.

Zahtjevi za prikupljanje podataka

Zahtjeve za korištenje podataka obično prikupljate rano tijekom intervjua i radnih sesija. Istodobno, 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 provedbi projekta. Zahtjevi za korištenje uključuju:

Zahtjevi za pristup i performanse

Volumetrijske karakteristike (procjena količine podataka za pohranu) koje omogućuju 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, zaokreti i drugi izračunati ili izvedeni podaci koji se mogu smatrati kandidatima za pohranu u trajnim strukturama podataka

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

Pogledi (trajni ili virtualni) koji će pomoći korisniku pri izvođenju operacija agregiranja podataka ili filtriranja.

Osim predsjednika, tajnika i korisnika, modelar, administrator baze podataka i arhitekt baze podataka moraju sudjelovati u sesiji zahtjeva za korištenje. Trebalo bi razgovarati o zahtjevima za povijesne podatke korisnika. Duljina vremena u kojem se podaci čuvaju ima značajan utjecaj 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šća sa sobom na sesiju. Izvješća moraju biti strogo definirana 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 tablice, stupci i odnosi. Entiteti logičkog modela vjerojatno će postati tablice u fizičkom modelu. Booleovi atributi postaju stupci. Logički odnosi postat će ograničenja integriteta odnosa. Neki logički odnosi ne mogu se implementirati u fizičku bazu podataka.

Obrnuti inženjering

Kada logički model nije dostupan, postaje potrebno ponovno kreirati model iz postojeće baze podataka. U ERwinu se ovaj proces naziva obrnutim inženjeringom. Obrnuti inženjering može se izvesti na nekoliko načina. Modelar može istraživati ​​strukture podataka u bazi podataka i ponovno kreirati tablice u okruženju vizualnog 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 s postojećom bazom podataka za stvaranje modela izravnim čitanjem struktura podataka. O obrnutom inženjeringu s ERwin-om će se detaljno raspravljati u budućem 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 prezentirani na holistički način, bez obzira na poslovnu domenu koju podržava. Entiteti, atributi i odnosi moraju definirati poslovna pravila na razini korporacije.

BILJEŠKA Neki od mojih kolega nazivaju te korporativne funkcionalne granice modeliranjem u stvarnom svijetu. Modeliranje u stvarnom svijetu potiče modelara da promatra informacije u smislu zapravo 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 korporaciji omogućuje učinkovitije iskorištavanje jedne od svojih najvrjednijih sredstava - informacija.

Što je model podataka poduzeća?

Podatkovni model poduzeća (EDM) sadrži entitete, atribute i odnose koji predstavljaju informacijske potrebe korporacije. EDM se obično kategorizira prema predmetnim područjima, koja predstavljaju skupine 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 korporativnog modela podataka. Ako logički model ne zadovoljava ovaj zahtjev, mora mu se dodati model domene. Ova usporedba osigurava da se korporativni model poboljša ili prilagodi te da se svi napori logičkog modeliranja koordiniraju unutar korporacije.

EDM također uključuje specifične entitete koji definiraju opseg vrijednosti za ključne atribute. Ovi entiteti nemaju roditelje i definirani su kao nezavisni. Neovisni entiteti se često koriste za održavanje integriteta odnosa. Ti su entiteti identificirani s nekoliko različitih naziva kao što su tablice kodova, referentne tablice, tablice tipova ili tablice klasifikacije. Koristit ćemo izraz „korporativni poslovni objekt“. Poslovni objekt poduzeća je entitet koji sadrži skup vrijednosti atributa koji su neovisni o bilo kojem drugom entitetu. Korporativni poslovni objekti trebaju se dosljedno koristiti 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 cjelovite korporativne modele povećanjem veličine.

Graditi znači graditi nešto uzastopno, sloj po sloj, baš kao što kamenica raste biser. Svaki stvoreni 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. To omogućuje izgradnju poslovnog modela podataka povećanjem, iterativnim dodavanjem razina detalja i preciziranja.

Koncept metodologije modeliranja

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

IDEF1X (Integration Definition for Information Modeling – integrirani opis informacijskih modela).

IE (Informacijski inženjering).

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

Integrirani opis informacijskih modela

IDEF1X je visoko strukturirana metodologija modeliranja podataka koja proširuje IDEF1 metodologiju usvojenu kao FIPS (Federal Information Processing Standards) 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 dodjeljuje 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.

Informacijski inženjering

Clive Finklestein se često naziva ocem informacijskog inženjeringa, iako je slične koncepte s njim dijelio James Martin (Martin, James. Managing the Database Environment. Upper Saddle River, New Jersey: Prentice Hall, 1983.). Informacijski 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 temeljnih koncepata ER metodologije koju je predložio Peter Chen.

IE pruža infrastrukturu za podršku informacijskim zahtjevima integracijom korporativnog strateškog planiranja s informacijskim sustavima koji se razvijaju. Ova integracija omogućuje da upravljanje informacijskim resursima bude bliže usklađeno s dugoročnim strateškim izgledima korporacije. Ovaj poslovni pristup doveo je mnoge modele da izaberu IE u odnosu na druge metodologije koje se usredotočuju na kratkoročne razvojne izazove.

IE predlaže slijed radnji koje navode korporaciju da identificira sve svoje potrebe za informacijama za prikupljanje i upravljanje podacima i identificiranje odnosa između informacijskih objekata. Kao rezultat toga, zahtjevi za informacijama jasno su artikulirani na temelju upravljačkih direktiva i mogu se izravno prevesti u upravljački informacijski sustav 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 domene, korisnike i stručnjake za informacijsku tehnologiju.

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 sastoji se od logičkih i fizičkih modela koji predstavljaju informacijske zahtjeve 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 usporediti 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 ERwinu model podataka uključuje i logičke i fizičke modele. ERwin implementira ER pristup i omogućuje vam stvaranje logičkih i fizičkih objekata modela koji će predstavljati zahtjeve za informacijama i poslovna pravila. Objekti logičkog modela uključuju entitete, atribute i odnose. Objekti fizičkog modela uključuju tablice, stupce i ograničenja integriteta odnosa.

Jedna od sljedećih publikacija pokrivat će pitanja identificiranja entiteta, definiranja tipova entiteta, odabira naziva i opisa entiteta, kao i neke tehnike za izbjegavanje najčešćih pogreš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 naziv koji odražava njegovo značenje, Booleov tip podataka i jasan, kratak, potpun opis ili definiciju. U budućem blog postu pogledat ćemo početni skup smjernica za pravilno oblikovanje naziva i opisa atributa. Odnosi trebaju uključivati ​​glagolsku konstrukciju koja opisuje odnos između entiteta, zajedno s karakteristikama kao što su množina, nužnost postojanja ili mogućnost odsutnosti veze.

BILJEŠKA Množina odnos opisuje maksimalni broj sekundarnih instanci entiteta koji se mogu povezati s instancom izvornog entiteta.Nužnost postojanja ili mogućnost odsutnosti odnos služi za određivanje minimalnog broja instanci sekundarnog entiteta koji se može povezati s instancom izvornog

Pošaljite svoj dobar rad u bazu znanja je jednostavno. Upotrijebite obrazac u nastavku

Studenti, diplomanti, mladi znanstvenici koji koriste bazu znanja u svom studiju i radu bit će vam jako zahvalni.

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

• 1. Relacijski model podataka
• 1.1 Relacijski model podataka. Osnovne definicije
• 1.2 Operacije na odnosima
• 2. Korporativni informacijski sustavi
• Bibliografija

1. Relacijski model podataka

1.1 Relacijski model podataka. Osnovne definicije

U matematičkim disciplinama koncept "tablice" odgovara pojmu "relacije" (relacije). Tablica odražava objekt stvarnog svijeta - entitet, a svaki njegov redak odražava određenu instancu entiteta. Svaki stupac ima naziv jedinstven za tablicu. Nizovi nemaju imena, njihov redoslijed nije definiran, a broj je logički neograničen. Jedna od glavnih prednosti relacijskog modela podataka je homogenost (svaki red u tablici ima isti format). Na korisniku je da odluči jesu li dotični entiteti homogeni. Time se rješava problem prikladnosti modela.

Osnovni koncepti:

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

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

* Stupanj povezanosti je broj stupaca.

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

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

* Tuple je red tablice.

* Kardinalnost (kardinalnost) - broj redaka u tablici.

* Primarni ključ je atribut koji jedinstveno identificira retke odnosa. Primarni ključ s više atributa naziva se složeni 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 (atributi) jedne tablice koji može poslužiti kao primarni ključ druge tablice. Referira na primarni ključ druge tablice.

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

Nenormalizirana baza podataka sadrži informacije u jednoj ili više različitih tablica; to ostavlja dojam da uključivanje podataka u određenu tablicu nije bilo zbog očitih razloga. Ovakvo stanje može negativno utjecati na sigurnost podataka, racionalno korištenje prostora na disku, brzinu upita, učinkovitost ažuriranja baze podataka i, što je možda najvažnije, integritet pohranjenih informacija. Baza podataka prije normalizacije je struktura koja još nije logično raščlanjena na manje upravljive tablice.

Normalni oblik je vrsta pokazatelja razine ili dubine normalizacije baze podataka. Razina normalizacije baze podataka odgovara normalnom obliku u kojem se nalazi.

1.2 Operacije na odnosima

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

1. Atomičnost ili nedjeljivost. Svaki stupac mora sadržavati jednu nedjeljivu vrijednost.

2. Tablica ne smije sadržavati duple stupce ili grupe podataka.

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

Normalizacija bi trebala započeti provjerom kompatibilnosti strukture baze podataka s 1NF. Svi stupci koji nisu atomski moraju se podijeliti na sastavne stupce. Ako u tablici postoje duplicirani stupci, tada moraju odabrati zasebnu tablicu.

Da biste tablicu doveli 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 zasebna polja.

* Premjestite duple podatke u zasebnu tablicu.

* Provjerite odgovaraju li sve tablice uvjetima prvog normalnog oblika.

Za dovođenje tablica u drugi normalni oblik (2NF), tablice bi već trebale biti u 1NF. Normalizacija bi se trebala odvijati po redu.

Sada, u drugom normalnom obliku, uvjet mora biti zadovoljen - svaki stupac koji nije ključ (uključujući strani) mora ovisiti o primarnom ključu. Obično je ove stupce, koji imaju vrijednosti koje su neovisne o ključu, lako identificirati. Ako podaci sadržani u stupcu nisu povezani s ključem koji opisuje redak, onda ih treba odvojiti u vlastitu zasebnu tablicu. Primarni ključ se mora vratiti u staru tablicu.

Da biste bazu doveli u drugi normalni oblik, trebate:

* Identificirajte sve stupce koji nisu izravno ovisni o primarnom ključu ove tablice.

* Napravite potrebna polja u tablicama korisnika i foruma, odaberite iz postojećih polja ili stvorite primarne ključeve iz novih.

* Svaka tablica treba svoj primarni ključ

* Kreirajte strane ključeve i odredite njihove odnose između tablica. Posljednji korak normalizacije na 2NF bit će dodjela stranih ključeva za komunikaciju s pridruženim tablicama. Primarni ključ jedne tablice mora biti strani ključ u drugoj.

Savjeti:

Drugi način pretvaranja sheme u 2NF je promatranje odnosa između tablica. U idealnom slučaju, stvorite sve odnose jedan-prema-više. Odnosi "mnogo prema mnogo" trebaju restrukturiranje.

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

Baza podataka će biti u trećem normalnom obliku ako se pretvori u drugi normalni oblik i svaki stupac koji nije ključ je neovisan jedan o drugom. Ako do ove točke ispravno slijedite proces normalizacije, možda neće biti pitanja o pretvorbi u 3NF. Trebali biste biti svjesni da je 3NF prekršen ako promjena vrijednosti u jednom stupcu zahtijeva promjenu u drugom stupcu.

Da biste bazu doveli u treći normalni oblik, trebate:

* Odredite koja polja od kojih tablica imaju međuovisnosti, t.j. polja koja više ovise jedno o drugom nego o redu u cjelini.

* Napravite odgovarajuće tablice. Ako postoji problematičan stupac u koraku 1, izradite podijeljene tablice za njega.

* Stvorite ili dodijelite primarne ključeve. Svaka tablica mora imati primarni ključ.

* Izradite potrebne strane ključeve koji čine bilo koji od odnosa.

U četvrtom normalnom obliku dodatno je pravilo da je potrebno isključiti viševrijedne ovisnosti. Drugim riječima, svi redovi u tablici moraju biti neovisni jedan o drugom. Prisutnost nekog retka X ne bi trebala značiti da se red Y također nalazi negdje u ovoj tablici.

2. Korporativni informacijski sustavi

relacijski model podatkovni sustav

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

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

2. Organizacija sustava - unutarnja uređenost, dosljednost interakcije elemenata sustava, koja se očituje, posebice, u ograničavanju raznolikosti stanja elemenata unutar sustava.

3. Struktura sustava – sastav, red i principi interakcije elemenata sustava, koji određuju osnovna svojstva sustava. Ako su pojedini elementi sustava raspoređeni na različitim razinama, a unutarnje veze između elemenata organizirane samo od viših prema nižim razinama i obrnuto, onda govorimo o hijerarhijskoj strukturi sustava. Čisto hijerarhijske strukture su praktički rijetke, pa se, donekle proširujući ovaj koncept, pod hijerarhijskom strukturom obično podrazumijevaju takve strukture, gdje su, između ostalih veza, hijerarhijski odnosi od najveće važnosti.

4. Arhitektura sustava – skup svojstava sustava koja su bitna za korisnika.

5. Integritet sustava - temeljna nesvodljivost svojstava sustava na zbroj svojstava njegovih pojedinih elemenata (nastanak svojstava) i, istovremeno, ovisnost svojstava svakog elementa o njegovom mjestu i funkcionirati unutar sustava.

Informacijski sustav je međusobno povezan skup sredstava, metoda i osoblja koji se koriste za pohranjivanje, obradu i izdavanje informacija radi postizanja zadanog cilja.

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

"Informacijski sustav je organizacijski uređen skup dokumenata (nizova dokumenata) i informacijskih tehnologija, uključujući korištenje računalne tehnologije i komunikacija koje provode informacijske procese"

Klasifikacija ljestvice

U smislu razmjera, informacijski sustavi se dijele u sljedeće skupine:

* samac;

* grupa;

* korporativni.

Korporativni informacijski sustav je skalabilan sustav dizajniran za integriranu automatizaciju svih vrsta gospodarskih aktivnosti velikih i srednjih poduzeća, uključujući korporacije koje se sastoje od grupe poduzeća koja zahtijevaju jedinstveno upravljanje.

Korporativni informacijski sustav može se smatrati sustavom koji automatizira više od 80% odjela poduzeća.

U posljednje vrijeme u mnogim publikacijama posvećenim korištenju informacijske tehnologije u upravljanju gospodarskim objektima često se koristi izraz "korporativni informacijski sustavi", koji u njima označava stvarne automatizirane informacijske sustave gospodarskih objekata.

Automatizirani informacijski sustav (AIS) kombinacija je različitih vrsta podrške, kao i stručnjaka dizajniranih za automatizaciju obrade računovodstvenih i analitičkih informacija. Vrste potpore su u pravilu homogene za različite sustave po sastavu, što omogućuje provedbu načela kompatibilnosti sustava tijekom njihovog rada. U procesu proučavanja AIS-a kao složenog sustava potrebno je izdvojiti pojedine dijelove i elemente te razmotriti značajke njihove uporabe u fazama stvaranja i rada.

Korporativni informacijski sustavi su evolucija sustava za radne skupine, fokusirani su na velike tvrtke i mogu podržati zemljopisno raspršene čvorove ili mreže. U osnovi, imaju hijerarhijsku strukturu od nekoliko razina. Takve sustave karakterizira arhitektura klijent-poslužitelj sa specijalizacijom poslužitelja ili višeslojna arhitektura. Prilikom razvoja takvih sustava mogu se koristiti isti poslužitelji baze podataka kao i kod razvoja grupnih informacijskih sustava. Međutim, u velikim informacijskim sustavima najčešći poslužitelji su Oracle, DB2 i Microsoft SQL Server.

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

Klasifikacija po opsegu

Prema opsegu primjene, informacijski sustavi se obično dijele u četiri skupine:

* sustavi za obradu transakcija;

* sustavi donošenja odluka;

* informacijski i referentni sustavi;

* uredski informacijski sustavi.

Bibliografija

1. Agaltsov, V.P. Baza podataka. U 2 sveska V. 2. Distribuirane i udaljene baze podataka: Udžbenik / V.P. Agalcov. - 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. Informacijski sustavi i baze podataka: organizacija i dizajn: Udžbenik / V.Yu. Pirogov. - SPb .: BHV-Peterburg, 2009.

6. G.N. Fedorov. Informacijski sustavi. - M .: Akademija, 2013.

7. A.E. Satunina, L.A. Sysoeva. Upravljanje projektima korporativnog informacijskog sustava poduzeća. - M .: Financije i statistika, Infra-M, 2009.

Objavljeno na Allbest.ru

...

Slični dokumenti

Bit i karakteristike tipova modela podataka: hijerarhijski, mrežni i relacijski. Osnovni koncepti relacijskog modela podataka. Atributi, shema odnosa baze podataka. Uvjeti integriteta podataka. Odnosi između tablica. Opće razumijevanje modela podataka.

seminarski rad, dodan 29.01.2011


Korporativni informacijski sustavi i baze podataka, njihova upotreba za poboljšanje i otklanjanje pogrešaka u poslovanju. Klasifikacija korporativnih informacijskih sustava. Informacijski sustavi klase OLTP. Promptna analitička obrada.

seminarski rad dodan 19.01.2011


Baze podataka s dvodimenzionalnim datotekama i sustavi upravljanja relacijskim bazama podataka (DBMS). Izrada baze podataka i obrada upita prema njima pomoću DBMS-a. Glavne vrste baza podataka. Osnovni koncepti relacijskih baza podataka. Temeljna svojstva odnosa.

sažetak, dodan 20.12.2010


Koncept sustava baze podataka. Relacijski model i njegove karakteristike. Integritet u relacijskom modelu. Relacijska algebra. Problemi dizajna baze podataka. Normalni oblici odnosa. Projektiranje baze podataka metodom entitet-odnos. ER dijagrami. SQL jezik.

tečaj predavanja dodan 03.10.2008


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

prezentacija dodana 14.10.2013


Baze podataka i njihova uporaba u računalstvu. Značajke i osnovna konstruktivna jedinica mrežnog podatkovnog modela. Hijerarhijski model, objekti predmetnog područja. Relacijski model, njegova vidljivost, prikaz podataka u tabličnom obliku.

sažetak, dodan 19.12.2011


Vrste i funkcije sustava upravljanja bazama podataka Microsoft Access. Hijerarhijski, mrežni, relacijski model za opisivanje baza podataka. Osnovni pojmovi tablice baze podataka. Značajke izrade objekata baze podataka, osnovni oblici. Pristup internetu u Accessu.

test, dodano 01.08.2011


Suvremeni sustavi upravljanja bazama podataka (DBMS). Analiza hijerarhijskog modela podataka. Relacijski model podataka. Postrelacijski model podataka kao prošireni relacijski model koji uklanja ograničenje na nedjeljivost podataka pohranjenih u tabličnim zapisima.

znanstveni rad, dodan 08.06.2010


Modeli podataka u upravljanju bazama podataka. Konceptualni modeli podataka. Uloga baza podataka u informacijskim sustavima. Relacijski model podataka. Definicija predmetnog područja. Izgradnja modela baze podataka za informacijski sustav "Kućni ljubimci".

seminarski rad, dodan 19.04.2011


Informacijski model u Accessu kao svojevrsna pojednostavljena zamjena za stvarni objekt ili sustav. Osnovne strukture koje određuju organizaciju podataka i odnose među njima; relacijski tip organizacije podataka. Primjer baze podataka u oporezivanju.

Modeli podataka o industriji

Glavna svrha modela je olakšati orijentaciju u podatkovnom prostoru i pomoći u isticanju detalja važnih za razvoj poslovanja. U današnjem okruženju, za uspješno poslovanje, imperativ je imati jasno razumijevanje veza između različitih komponenti i imati dobru predodžbu o cjelokupnoj slici organizacije. Identifikacija svih detalja i odnosa pomoću modela omogućuje najučinkovitije korištenje vremena i alata za organizaciju rada tvrtke.

Modeli podataka su apstraktni modeli koji opisuju kako se podaci prezentiraju 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 stručnjake koji koristi određeni skup simbola i riječi za točno objašnjenje određene klase informacija iz stvarnog svijeta. To omogućuje bolju komunikaciju unutar organizacije i tako stvara fleksibilnije i stabilnije aplikacijsko okruženje.

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

U pravilu se razlikuju modeli više razine (i sadržajno općenitije) i niže (odnosno, detaljnije). Gornja razina modeliranja je tzv konceptualni modeli podataka(konceptualni modeli podataka), koji daju najopćenitiju sliku funkcioniranja poduzeća ili organizacije. Konceptualni model uključuje glavne koncepte ili predmetna područja koja su kritična za funkcioniranje 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 tih klasa (odnosno 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 predmetnog područja (što se može prevesti kao modeli domene) ili predmetnim modelom podataka poduzeća (predmetni korporativni modeli podataka ).

Sljedeća hijerarhijska razina je logičkih modela podataka(logički modeli podataka). Također se mogu nazvati poslovnim modelima podataka ili poslovnim modelima. Ovi modeli sadrže strukture podataka, njihove atribute i poslovna pravila te predstavljaju informacije koje poduzeće koristi iz poslovne perspektive. U takvom modelu podaci su organizirani u obliku entiteta i odnosa među njima. Logički model predstavlja podatke na način koji poslovnim korisnicima olakšava razumijevanje. U logičkom modelu može se razlikovati rječnik podataka - popis svih entiteta s njihovim preciznim definicijama, što omogućuje različitim kategorijama korisnika da imaju zajedničko razumijevanje svih ulaznih i izlaznih tokova podataka modela. Sljedeća, niža razina 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 normaliziranog 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 organizirane su u grupe prema njihovoj jedinstvenoj identifikaciji. Poslovna pravila koja uređuju stavke podataka moraju biti u potpunosti ugrađena u normalizirani model uz prethodnu provjeru valjanosti i valjanosti. Na primjer, stavka podataka kao što je ime korisnika vjerojatno će biti podijeljena na ime i prezime i grupirana s drugim povezanim stavkama podataka u entitet klijenta s primarnim ključem ID-a korisnika.

Logički model podataka neovisan je o aplikacijskim tehnologijama kao što su baze podataka, mrežne tehnologije ili alati za izvješćivanje, te o sredstvima njihove fizičke implementacije. U organizaciji može postojati samo jedan model podataka poduzeća. Logički modeli obično uključuju tisuće entiteta, odnosa i atributa. Na primjer, model podataka za financijsku instituciju ili telekomunikacijsku tvrtku 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 mogu se promatrati kao sljedeća razina modeliranja koja se približava fizičkim modelima. Štoviše, svaki od ovih modela predstavljat će zaseban "slice" 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 podatkovno tržište može se predstaviti kao višedimenzionalna struktura.

Tvrtka može imati dva načina za stvaranje 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 tvrtka 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, tada možemo govoriti o industrijskom logičkom modelu podataka. Potonji je gotov logički model podataka koji s visokim stupnjem točnosti odražava funkcioniranje određene industrije. Industrijski logički model je domenski specifičan i integrirani pogled na sve informacije koje se moraju nalaziti u skladištu podataka poduzeća kako 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đer ne uključuje izvedene podatke ili druge izračune za brže dohvat podataka. U pravilu, većina logičkih struktura takvog modela dobro je utjelovljena u njegovoj učinkovitoj fizičkoj implementaciji. Takve modele razvijaju mnogi dobavljači za širok raspon područja djelatnosti: financije, proizvodnja, turizam, zdravstvo, osiguranje itd.

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

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

Stručnjak za poslovnu inteligenciju Steve Hoberman identificira pet čimbenika koje treba uzeti u obzir kada odlučujete hoćete li nabaviti industrijski model podataka. Prvi su vrijeme i novac potrebni za izradu modela. Ako organizacija treba brzo postići rezultate, tada će industrijski model biti koristan. 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 se potrošiti na povezivanje postojećih struktura s 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 čimbenik je vrijeme i novac potrebni za održavanje modela u dobrom radnom stanju. Ako model podataka poduzeća nije dio metodologije koja vam omogućuje praćenje usklađenosti s njegovom točnošću i usklađenošću sa modernim standardima, tada takav model vrlo brzo zastari. Industrijski podatkovni model može spriječiti pojavu ovog rizika jer se ažurira vanjskim resursima. Naravno, promjene koje se događaju unutar organizacije trebale bi se odraziti u modelu od strane same tvrtke, ali promjene u industriji će reproducirati u modelu njezin dobavljač.

Treći čimbenik je iskustvo u procjeni rizika i modeliranju. Stvaranje modela korporativnih podataka zahtijeva kvalificirane resurse i poslovnog i IT osoblja. Menadžeri su u pravilu dobro upoznati ili s radom organizacije u cjelini, ili s aktivnostima pojedinog odjela. Malo njih ima široko (za cijelu tvrtku) i duboko (unutar odjela) znanje o svom poslovanju. Većina menadžera obično dobro poznaje samo jedno područje. Stoga su za dobivanje opće korporativne slike potrebni značajni poslovni resursi. To također povećava zahtjeve za IT osoblje. Što je više poslovnih resursa potrebno za stvaranje i testiranje modela, to analitičari moraju biti iskusniji. Ne samo da moraju znati dobiti informacije od poslovnog osoblja, već i biti u stanju pronaći zajedničku točku gledišta u spornim područjima i biti sposobni sve te informacije prezentirati na integriran način. Osoba koja kreira model (u mnogim slučajevima isti analitičar) mora imati dobre vještine modeliranja. Izgradnja modela poslovne logike zahtijeva modeliranje “za budućnost” i sposobnost doslovnog pretvaranja složenog poslovanja “u kvadrate i linije”.

S druge strane, industrijski model omogućuje korištenje vanjske stručnosti. Logički modeli specifični za industriju izgrađeni su korištenjem dokazanih metodologija modeliranja i timova iskusnih stručnjaka kako bi se izbjegli uobičajeni i skupi problemi koji se mogu pojaviti pri razvoju poslovnih modela podataka unutar organizacije.

Četvrti čimbenik je postojeća aplikacijska infrastruktura i odnosi s dobavljačima. Ako organizacija već koristi mnoge alate istog dobavljača i ima uspostavljene odnose s njim, onda ima smisla i model industrije naručiti od njega. Ovaj model će moći slobodno raditi s drugim proizvodima istog dobavljača.

Peti faktor je razmjena informacija unutar industrije. Ako tvrtka treba komunicirati s drugim organizacijama koje rade na istom području, tada industrijski model može biti vrlo koristan u ovoj situaciji. Organizacije unutar iste industrije koriste slične strukturne komponente i terminologiju. Danas su u većini industrija tvrtke prisiljene razmjenjivati ​​podatke kako bi uspješno poslovale.

Najučinkovitiji su industrijski modeli koje nude profesionalni dobavljači. Visoka učinkovitost njihove uporabe postiže se zahvaljujući značajnoj razini detalja i toč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 također dobro upućeni u izradu modela za određenu industriju.

Modeli podataka u industriji pružaju tvrtkama jedinstven, integrirani pogled na njihove poslovne informacije. Mnogim tvrtkama je teško integrirati svoje podatke, iako je to preduvjet za većinu projekata u cijelom poduzeć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 generira opipljiv prihod za tvrtku.

Industrijski podatkovni model, osim povezivanja s postojećim sustavima, pruža velike prednosti za projekte na razini poduzeća kao što su planiranje resursa poduzeća (ERP), upravljanje glavnim podacima, poslovna inteligencija, poboljšanje kvalitete podataka i razvoj zaposlenika.

Stoga su industrijski logički modeli podataka učinkovit alat za integraciju podataka i dobivanje holističkog pogleda na poslovanje. Čini se da je korištenje logičkih modela nužan korak prema stvaranju korporativnih skladišta podataka.

Publikacije

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

Svrha predavanja

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

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

i naučite:

• razviti modele skladišta podataka na temelju korporativni model podataka organizacije;
• dizajnirati zvjezdastu shemu pomoću CASE alata;
• pregradni stolovi višedimenzionalni model pomoću CASE alata.

Model podataka poduzeća

Uvod

Jezgra svakog HD-a je njegov podatkovni model. Bez podatkovnog modela bit će vrlo teško organizirati 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 usporedbi s projektiranjem OLTP-sustava, metodologija dizajna CD-a ima niz karakterističnih značajki povezanih s orijentacijom struktura podataka pohrane na rješavanje problema analize i informacijske podrške procesu donošenja odluka. HD podatkovni model trebao bi pružiti učinkovito rješenje upravo za ove probleme.

Polazna točka u dizajnu CD-a može biti tzv model podataka poduzeća(corporate data model ili enterprise data model, EDM), koji nastaje u procesu projektiranja OLTP sustava organizacije. Prilikom projektiranja korporativni model podataka obično se pokušava stvoriti struktura podataka temeljena na poslovnim operacijama koja bi prikupila i sintetizirala sve informacijske potrebe organizacije.

Tako, model podataka poduzeća sadrži potrebne informacije za izradu CD modela. Stoga, 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 poduzeća

Kako riješiti problem transformacije korporativni model podataka u HD model? Da biste riješili ovaj problem, morate imati ovaj model, tj. korporativni model podataka treba izgraditi i dokumentirano... I trebaš razumjeti što od ovog modela i kako treba transformirati u HD model.

Pojasnimo sa stajališta CD dizajnera koncept korporativni model podataka. Pod, ispod korporativni model podataka razumjeti višerazinski, strukturirani opis predmetnih područja organizacije, strukture podataka predmetnog područja, poslovnih procesa i poslovnih procedura, organizacijskih tokova podataka, dijagrama stanja, matrica procesa podataka i drugih modela prikaza koji se koriste u aktivnostima organizacije. Dakle, u najširem smislu riječi, model podataka poduzeća je skup modela različitih razina koji karakteriziraju (model na nekoj apstraktnoj razini) aktivnosti organizacije, t.j. sadržaj korporativni model izravno ovisi o tome koje su modelne konstrukcije bile uključene u njega u danoj organizaciji.

Glavni elementi korporativni model podataka su:

• opis predmetnih područja organizacije (definicija područja djelovanja);
• odnose između gore definiranih predmetnih područja;
• informacijski podatkovni model (ERD -model ili model entitet-odnos);
• opis za svako predmetno područje:
  • ključevi entiteta;
  • atributi entiteta;
  • podtipovi i supertipovi;
  • odnosi između entiteta;
  • atributi grupiranja;
  • odnosi između predmetnih područja;
• funkcionalni ili model poslovnog procesa;
• dijagrami toka podataka;
• dijagrami stanja;
• drugi modeli.

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

Razine prezentacije modela podataka poduzeća

Model podataka poduzeća podijeljeni prema predmetnim područjima, koja predstavljaju skupine 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 zadovoljava ovaj zahtjev, mora mu se dodati model domene.

Model podataka poduzeća obično ima nekoliko razina prezentacije. Zapravo visoka razina(visoka razina) korporativni model podataka postoji opis glavnih predmetnih područja organizacije i njihovih odnosa na razini entiteta. Na sl. 16.2 je isječak korporativni model podataka vrhunska razina.

Riža. 16.2.

Dijagram prikazan na slici prikazuje četiri predmetna područja: "Kupac" ( kupac), "Ček" ( račun), "Narudžba" ( Narudžba) i "Proizvod" ( Proizvod). U pravilu samo izravne veze između predmetnih područja, koji npr. bilježe sljedeću činjenicu: kupac plaća račun za narudžbu robe. Pojedinosti i neizravni odnosi na ovoj razini korporativni model nije prikazan.

Na sljedećem, srednja razina(srednja razina) korporativni model podataka prikazane su detaljne informacije o objektima predmetnih područja, odnosno ključevi i atributi entiteta, njihovi odnosi, podtipovi i supertipovi, itd. Za svaku domenu modela najviše razine postoji jedan model srednje razine. Na sl. 16.3 prikazuje srednju razinu prezentacije korporativni model za ulomak predmetnog područja "Red".

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

primijeti da model podataka poduzeća mogu predstavljati različite aspekte aktivnosti organizacije i s različitim stupnjevima pojedinosti i potpunosti. Ako korporativni model predstavlja sve aspekte aktivnosti organizacije, također se naziva organizacijski podatkovni model(model podataka poduzeća).

Sa stajališta dizajna CD-a, važan čimbenik u odlučivanju o izradi CD modela iz korporativni model podataka je država potpunost korporativni model podataka.

Model podataka poduzeća organizacija ima obilježje evolucijske, t.j. neprestano se razvija i poboljšava. 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 polazište za dizajn CD-a.

Stupanj završetka korporativni model može se izravnati 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 sinkronizirati s proces završetka razvoj pojedinih fragmenata korporativni model podataka organizacijama.

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