Ovaj će se članak usredotočiti na arhitekturu skladišta podataka. Što slijediti pri izgradnji, koji pristupi radu - i zašto.

“Bajka je laž – ali ima naznaka u njoj...”

Djed je zasadio... skladište. I naraslo je veliko, vrlo veliko skladište. Samo nisam znao kako to funkcionira. I moj djed je započeo recenziju. Djed je pozvao baku, unuku, mačku i miša na obiteljsko vijeće. I kaže sljedeću temu: “Naše skladište je naraslo. Podaci iz svih sustava teku zajedno, tablice su vidljive i nevidljive. Korisnici sami pripremaju svoja izvješća. Čini se da je sve u redu - živi i živi. Postoji samo jedna tuga - nitko ne zna kako funkcionira. Zahtijeva diskove, prividno ili nevidljivo - ne možete se zasititi! A onda su korisnici stekli naviku dolaziti mi s raznim pritužbama: čas se zamrzne izvješće, čas su podaci zastarjeli. Inače, to je čista katastrofa - dolazimo s izvještajima Car-ocu, ali brojke se međusobno ne slažu. Čas nikad nije siguran - ljutito će kralj - tada ni ja ni ti nećemo izgubiti glavu. Pa sam odlučio okupiti vas i posavjetovati se: što ćemo učiniti?

Osvrnuo se po okupljenima i upitao:
- Znaš li ti, babo, kako je uređeno naše skladište?
- Ne, djede, ne znam. A kako bih ja trebao znati? Neki hrabri momci ga čuvaju! Kakvi brkovi! Nećeš prići. Jednog dana sam ih posjetio i ispekao pite. I jedu pite, brišu brkove i govore: “Što si došla, babo? Kakvu vrstu skladišta trebate? Samo nam recite kakvu vrstu izvješća trebate i mi ćemo to učiniti za vas! Glavno je češće donositi pite! Preukusne su."
- A ti, voljena unuko, znaš li kako radi naše skladište?
- Ne, djede, ne znam. Nekako su mi omogućili pristup tome. Spojio sam se, pogledao - a eto stolova - prividno i nevidljivo. A različiti su skriveni u dijagramima. Oči divljaju... Prvo sam bio zbunjen. A onda sam bolje pogledao - neki su bili prazni, drugi ispunjeni, ali samo do pola. A čini se da se podaci ponavljaju. Nije ni čudo što ne možete dobiti dovoljno diskova, s takvom redundancijom!
- Pa, mačko, što možeš reći o našem skladištu? Ima li što dobro u tome?
- Kako da ne kažem, djede, reći ću. Na zahtjev moje unuke, pokušao sam napraviti pilot u zasebnom uzorku - malu vitrinu. Da bismo razumjeli koja je trgovina isplativa za našu državu - koji su proizvodi dobri za trgovce, plaćaju danak - riznica se puni. A koje su stvarno loše. I počeo sam birati podatke za sebe iz ovog spremišta. Skupljao sam činjenice. I počeo ih je pokušavati usporediti s proizvodima. I što, djede, vidio sam - čini se da su proizvodi isti, ali kad pogledate znakove, drugačiji su! Zatim sam ih počela češljati češljem svoje unuke. Izgreban i izgreban - i doveo do određene uniformnosti, milujući oko. Ali rano sam se obradovao - sljedeći dan sam pokrenuo svoje skripte za ažuriranje prekrasnih podataka u prozoru za prikaz - i sve mi je pošlo po zlu! "Kako to?" - Mislim - uzrujano će moja unuka - danas bismo našeg pilota trebali pokazati ministru. Kako možemo ići s takvim podacima?
- Da, pričaš tužne priče, mačko. Pa, ti mali mali mišu, zar nisi stvarno pokušao saznati nešto o skladištu? Vi ste živahna, okretna, društvena djevojka! Što ćeš nam reći?
- Zašto, djede, zašto ne probati? Naravno, ja sam tihi miš, ali spretan. Jednom me unuka mačke zamolila da dobijem model podataka iz našeg državnog repozitorija. I mačak mi je, naravno, došao - sva mi je nada u tebe, kaže, mišu! Pa, zašto ne učiniti dobro djelo za dobre ljude (i mačke)? Otišao sam u dvorac, gdje šef skladišta skriva model podataka u sefu. I sakrila se. Čekala sam dok nije izvadio taj model iz sefa. Čim je izašao po kavu, skočila sam na stol. Gledam model i ništa mi nije jasno! Kako to? Ne prepoznajem naše skladište! Imamo tisuće bezbrojnih tablica, beskrajne tokove podataka! A ovdje - sve je skladno i lijepo... Pogledao je ovaj model i vratio ga u sef.
- Da, rekao si nam jako čudne stvari, mišu.
Djed se duboko zamislio.
- Što ćemo, prijatelji? Uostalom, nećete dugo živjeti s tim i takvim skladištenjem... Korisnici će uskoro potpuno izgubiti strpljenje.

Što god naš djed iz bajke odlučio - izgraditi novo skladište ili pokušati oživjeti postojeće - moramo izvući zaključke prije nego ponovno “zasučemo rukave”.
Ostavimo po strani organizacijske aspekte - kao što je opasnost od koncentriranja stručnosti u određenom uskom zatvorena grupa, nedostatak procesa kontrole i osiguravanja transparentnosti arhitekture sustava koji se koriste u poduzeću itd.
Danas bih se želio fokusirati na izgradnju arhitekture određenog sustava (ili grupe sustava) – skladišta podataka. Što prije svega treba imati u fokusu kada se organizacija sprema izgraditi tako složen i skup sustav kao što je skladištenje.

Ispitivanje

Nitko od nas, radeći na stvaranju i razvoju bilo kojeg sustava, ne želi da on ispadne „provizorno“ rješenje ili rješenje koje će „umrijeti“ za godinu-dvije, jer neće moći ispuniti zahtjeve i očekivanja kupaca i poslovanja. Koliko god jaka pristranost prema "agilnim metodologijama" danas postoji, čovjeku je puno ugodnije osjećati se kao "majstor" koji izrađuje violine nego kao majstor koji šiša štapiće za jednokratne bubnjeve.
Naša namjera zvuči prirodno: napraviti sustave koji su čvrsti i kvalitetni, koji od nas neće zahtijevati redovita “noćna bdijenja s turpijom”, kojih se nećemo sramiti pred krajnjim korisnicima i koji neće izgledati kao “crne kutije” svim “neupućenim” pratiteljima.

Prvo, napravimo popis tipični problemi, s kojima se redovito susrećemo pri radu sa skladišnim prostorima. Zapišimo samo ono što imamo - za sada, bez pokušaja da to organiziramo i formaliziramo.

1. U principu, imamo dobro skladište: ako ga ne dirate, onda sve radi. Istina, čim je potrebna promjena, počinju "lokalni kolapsi".
2. Podaci se učitavaju dnevno, prema propisima, u okviru jednog velikog procesa, unutar 8 sati. I to nam odgovara. Ali ako iznenada dođe do kvara, potrebna je ručna intervencija. A onda sve može dugo funkcionirati nepredvidivo, jer... bit će potrebno ljudsko sudjelovanje u procesu.
3. Stiglo izdanje - očekujte probleme.
4. Jedan izvor nije mogao dati podatke na vrijeme - svi procesi su na čekanju.
5. Integritet podataka kontrolira baza podataka - tako da se naši procesi ruše s pogreškom kada je on narušen.
6. Imamo jako veliko skladište - 2000 stolova u jednom opća shema. I još 3000 u mnogim drugim shemama. Već nemamo pojma kako djeluju i iz kojeg su se razloga pojavili. Stoga nam može biti teško ponovno upotrijebiti nešto. A mnoge probleme treba rješavati iznova. Zato što je lakše i brže (od razumijevanja "tuđeg koda"). Kao rezultat toga, imamo nedosljednosti i dvostruku funkcionalnost.
7. Od izvora očekujemo kvalitetne podatke. 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. Ali korisnici su navikli na...
8. Korisnik ne vjeruje uvijek našim izvješćima i traži opravdanje za ovu ili onu brojku. U nekim slučajevima je u pravu, au drugim u krivu. Ali jako nam je teško opravdati ih, jer... Ne pružamo alate za "end-to-end analizu" (ili lozu podataka).
9. Mogli bismo privući dodatne programere. Ali imamo problem - kako ih uključiti u naš rad? Kako najučinkovitije paralelizirati rad?
10. Kako sustav razvijati postupno, a da ne potrošite cijelu godinu na razvoj “jezgre sustava”?
11. Skladište podataka povezano je s modelom poduzeća. Ali sigurno znamo (vidjeli smo to u XYZ banci) da izgradnja modela može trajati beskonačno dugo (u XYZ banci su šest mjeseci hodali i raspravljali o poslovnim subjektima, bez ikakvih pokreta). Zašto joj to uopće treba? Ili je možda bolje bez nje, ako s njom ima toliko problema? Možda se može nekako generirati?
12. Odlučili smo pokrenuti model. Ali kako sustavno razviti podatkovni model skladišta? Trebaju li nam “pravila igre” i koja bi ona mogla biti? Što će nam to dati? Što ako pogriješimo s modelom?
13. Trebamo li spremati podatke, odnosno povijest njihovih promjena, ako “poslovno ne trebaju”? Ne bih želio "skladištiti smeće" i komplicirati korištenje ovih podataka za stvarne zadatke. Treba li repozitorij čuvati povijest? Kako je? Kako pohrana funkcionira tijekom vremena?
14. Trebamo li pokušati objediniti podatke u pohrani ako imamo sustav za upravljanje glavnim podacima? Ako postoji MDM, znači li to da je cijeli problem s glavnim podacima sada riješen?
15. Uskoro se očekuje zamjena ključnih računovodstvenih sustava. Treba li skladište podataka biti pripremljeno za promjene izvora? Kako to postići?
16. Trebamo li metapodatke? Što mislimo pod ovim? Gdje se točno mogu koristiti? Kako se to može provesti? Trebaju li ih držati "na jednom mjestu"?
17. Naši kupci su izrazito nestabilni u svojim zahtjevima i željama - stalno se nešto mijenja. Općenito, naše poslovanje je vrlo dinamično. Sve dok nešto radimo, to postaje nepotrebno. Kako se možemo pobrinuti za postizanje rezultata što je brže moguće – kao alva?
18. Korisnici zahtijevaju učinkovitost. Ali ne možemo često pokretati glavne procese preuzimanja jer... ovo učitava izvorne sustave (loše utječe na performanse) - stoga dodajemo dodatne tokove podataka - koji će uzeti točno ono što nam treba. Istina, ima puno niti. A onda ćemo izbaciti neke od podataka. Osim toga, postojat će problem konvergencije. Ali nema drugog načina...

Već je bilo dosta toga. Ali nije puni popis– lako se nadopunjuje i razvija. Nećemo ga sakriti u tablicu, već ćemo ga objesiti na vidljivo mjesto - držeći ove probleme u fokusu naše pažnje dok radimo.
Naš zadatak je u konačnici razviti sveobuhvatno rješenje.

Antifragilnost

Gledajući naš popis, možemo izvući jedan zaključak. Nije teško stvoriti neku vrstu "baze podataka za izvješćivanje", dodati podatke tamo ili čak izgraditi neku vrstu regulatornih procesa za ažuriranje podataka. Sustav počinje nekako živjeti, pojavljuju se korisnici, a s njima i obveze i SLA-ovi, pojavljuju se novi zahtjevi, spajaju se dodatni izvori, mijenjaju se metodologije - sve to treba uzeti u obzir u procesu razvoja.

Nakon nekog vremena slika izgleda ovako:
“Ovdje je skladište. I radi ako ga ne diraš. Problemi nastaju kada nešto moramo promijeniti.”

Stiže nam promjena čiji utjecaj ne možemo procijeniti i sagledati (budući da takve alate nismo inicijalno stavili u sustav) - i da ne bismo riskirali, ne diramo ono što je tu, već pravimo drugo proširenje sa strane, i još jedno, a također - pretvaranje našeg rješenja u sirotinjske četvrti, ili kako kažu u Latinskoj Americi, “favele”, u koje se čak i policija boji ući.
Javlja se osjećaj gubitka kontrole nad vlastitim sustavom, kaos. Potrebno je sve više ruku za podršku postojećim procesima i rješavanje problema. A unositi promjene postaje sve teže. Drugim riječima, sustav postaje nestabilan na stres i neprilagodljiv na promjene. Osim toga, postoji jaka ovisnost o likovima koji "znaju plovni put", jer nitko nema "kartu".

Ovo svojstvo objekta je da se uruši pod utjecajem kaosa, slučajnih događaja i šokova - poziva Nassim Nicholas Taleb krhkost . I također uvodi suprotan koncept: antifragilnost – kada objekt nije uništen stresom i nesrećama, već od toga ima izravnu korist. (“Antifragile. Kako izvući korist iz kaosa”)
Inače se može nazvati prilagodljivost ili otpor promjenama .

Što to znači u ovom kontekstu? Koji su "izvori kaosa" za IT sustave? I što znači "imati koristi od kaosa" iz perspektive IT arhitekture?
Prva misao koja pada na pamet su promjene koje dolaze izvana. Što je vanjski svijet za sustav? Posebno za skladištenje. Naravno, prije svega, postoje promjene u izvorima podataka za pohranu:

• mijenjanje formata dolaznih podataka;
• zamjena jednog sustava izvora podataka drugim;
• mijenjanje pravila/platformi integracije sustava;
• mijenjanje interpretacija podataka (očuvaju se formati, mijenja se logika rada s podacima);
• promjena podatkovnog modela ako se integracija vrši na razini podataka (parsiranje datoteka dnevnika transakcija baze podataka);
• rast količine podataka - dok je bilo malo podataka u izvornom sustavu, a opterećenje je bilo malo - mogli ste ga uzeti bilo kada, s bilo kojim teškim zahtjevom, podaci i opterećenje su rasli - sada postoje stroga ograničenja;
• itd.

Sami izvorni sustavi, sastav informacija i njihova struktura, tip integracijske interakcije, kao i sama logika rada s podacima mogu se mijenjati. Svaki sustav implementira vlastiti model podataka i pristupe radu s njima, koji zadovoljavaju ciljeve i ciljeve sustava. I koliko god se trudili ujediniti industrijske modele i referentne prakse, neizbježno će se pojaviti nijanse. (Osim toga, sam proces objedinjavanja industrije ne napreduje puno iz raznih razloga.)
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 nužnost.

Ništa manje kritične promjene pokreću potrošači pohrane (promjene u zahtjevima):

• prije je bilo dovoljno podataka za izradu izvješća - sada je bilo potrebno povezati dodatna polja ili novi izvor podataka;
• Prethodno primijenjene tehnike obrade podataka su zastarjele - potrebno je preraditi algoritme i sve što je zahvaćeno;
• Ranije su svi bili zadovoljni trenutnom vrijednošću atributa imenika na informacijskoj ploči - sada je potrebna vrijednost koja je relevantna u trenutku nastanka analizirane činjenice/događaja;
• pojavio se zahtjev za dubinu povijesti pohrane podataka, koji prije nije postojao - da se podaci pohranjuju ne 2 godine, već 10 godina;
• Ranije je bilo dovoljno podataka na “kraj dana/razdoblja” - sada vam je potrebno stanje podataka “unutar jednog dana”, ili na vrijeme određenog događaja (npr. donošenje odluke o zahtjevu za kredit - za Basel II);
• Ranije smo se zadovoljavali izvješćivanjem podataka za jučer (T-1) ili kasnije, sada nam treba T0;
• itd.

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

Ali to nije sve.
Kada govorimo o varijabilnosti, prije svega se sjetimo vanjskih čimbenika. Uostalom, iznutra možemo kontrolirati sve, tako mislimo, 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 moramo vratiti “na točku 0”. Započnite igru ​​ispočetka.
U životu smo često skloni krenuti od nule. Zašto je to karakteristično za nas? I je li to tako loše?
Primijenjeno na IT. To može biti jako dobra stvar za sam sustav - prilika za preispitivanje pojedinačnih odluka. Pogotovo kada to možemo učiniti lokalno. Refactoring je proces razotkrivanja "mreže" koja se povremeno pojavljuje u procesu razvoja sustava. Povratak na početak može biti od pomoći. Ali to ima cijenu.
Pravilnim upravljanjem arhitekturom ta se cijena smanjuje – a sam proces razvoja sustava postaje kontroliraniji i transparentniji. Jednostavan primjer: ako se poštuje načelo modularnosti, možete prepisati zasebni modul bez utjecaja 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.
Kada govorimo o adaptivna arhitektura– mislimo na to da se sustav može prilagoditi promjenama, a ne na to da stalno mijenjamo samu arhitekturu. Naprotiv, što je arhitektura stabilnija i stabilnija, što je manje zahtjeva koji povlače njezinu reviziju, to je sustav prilagodljiviji.

Rješenja koja uključuju reviziju cjelokupne arhitekture imat će znatno višu cijenu. A da biste ih prihvatili morate imati jako dobre razloge. Na primjer, takva osnova može biti zahtjev koji se ne može implementirati unutar postojeće arhitekture. Zatim kažu da se pojavio zahtjev koji utječe na arhitekturu.
Dakle, također moramo znati svoje "granice otpornosti na krhkost". Arhitektura se ne razvija “u vakuumu” – ona se temelji na trenutnim zahtjevima i očekivanjima. A ako se situacija temeljito promijeni, moramo shvatiti da smo otišli dalje od trenutne arhitekture - i moramo je ponovno razmotriti, razviti drugačije rješenje - i razmisliti o načinima tranzicije.
Na primjer, pretpostavili smo da će nam uvijek trebati podaci u pohrani na kraju dana; svakodnevno ćemo prikupljati podatke koristeći standardna sučelja sustava (putem skupa pogleda). Zatim su iz odjela za upravljanje rizicima stigli zahtjevi o potrebi primanja podataka ne na kraju dana, već u trenutku donošenja odluke o kreditiranju. Nema potrebe pokušavati “razvući neistegnuto” - samo trebate prepoznati ovu činjenicu - što prije to bolje. I počnite raditi na pristupu koji će nam omogućiti da riješimo problem.
Ovdje postoji vrlo tanka linija - ako uzmemo u obzir samo "trenutačne zahtjeve" i ne gledamo nekoliko koraka unaprijed (i nekoliko godina unaprijed), tada povećavamo rizik da se susrećemo i sa zahtjevima koji utječu na arhitekturu. kasno - i cijena naših promjena bit će vrlo visoka. Gledanje malo unaprijed – u granicama našeg horizonta – nikada nikome nije naškodilo.

Primjer sustava iz “skladišne ​​bajke” upravo je primjer vrlo klimavog sustava izgrađenog na krhkim dizajnerskim pristupima. I ako se to dogodi, uništenje se događa vrlo brzo, upravo za ovu klasu sustava.
Zašto mogu ovo reći? Tema skladištenja nije nova. Pristupi i inženjerske prakse koje su razvijene u to vrijeme bile su usmjerene upravo na to - očuvanje održivosti sustava.
Jednostavan primjer: jedan od najčešćih razloga za neuspjeh projekata pohrane "na uzletu" je pokušaj izgradnje pohrane na izvornim sustavima koji su u razvoju, bez dogovora o integracijskim sučeljima - pokušaj preuzimanja podataka izravno iz stolovi. Kao rezultat toga, krenuli su u razvoj - tijekom tog vremena promijenila se izvorna baza podataka - i tokovi prijenosa u pohranu postali su neoperativni. Prekasno je bilo što ponoviti. A ako se još niste osigurali izradom nekoliko slojeva stolova unutar spremišta, onda možete sve izbaciti i početi ispočetka. Ovo je samo jedan primjer, i to jedan od jednostavnih.

Talebov kriterij za fragile i antifragile je jednostavan. Glavni sudac je vrijeme. Ako sustav izdrži test vremena i pokaže svoju „sposobnost preživljavanja“ i „neuništivost“, on ima svojstvo antifragilnosti.
Ako pri projektiranju sustava uzmemo u obzir antifragilnost kao zahtjev, tada će nas to potaknuti da koristimo takve pristupe u izgradnji njegove arhitekture koji će sustav učiniti prilagodljivijim i "kaosu izvana" i "kaosu iznutra" .” I u konačnici sustav će imati dulji životni vijek.
Nitko od nas ne želi praviti “privremene zgrade”. I nemojte se zavaravati da je danas nemoguće drugačije. Gledati nekoliko koraka unaprijed normalno je za čovjeka u svakom trenutku, a pogotovo u krizi.

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

Članak o arhitekturi pohrane pretpostavlja da čitatelj ne samo da je svjestan što je to, već također ima određeno iskustvo s sličnih sustava. Ipak, smatrao sam potrebnim to učiniti - vratiti se na ishodište, na početak puta, jer... Tu se nalazi “uporišna točka” razvoja.

Kako su ljudi došli do zaključka da su skladišta podataka potrebna? I kako se razlikuju od samo “jako velika baza podaci"?
Nekada davno, dok su u svijetu postojali jednostavno "sustavi za obradu poslovnih podataka", nije postojala podjela IT sustava na klase kao što su front-end oltp sustavi, back-office dss, sustavi za obradu tekstualnih podataka, skladišta podataka itd. .
To je bilo vrijeme kada je prvi relacijski DBMS, Ingres, stvorio Michael Stonebreaker.
A to je bilo vrijeme kada je era osobnih računala uletjela u računalnu industriju kao vihor i zauvijek promijenila sve ideje IT zajednice tog vremena.

Tada je bilo lako pronaći poslovne aplikacije napisane na bazi DBMS-ova desktop klase, kao što su Clipper, dBase i FoxPro. A tržište za aplikacije klijent-poslužitelj i DBMS tek je dobivalo zamah. Jedan za drugim pojavili su se poslužitelji baza podataka koji će dugo zauzeti svoju nišu u IT prostoru - Oracle, DB2 itd.
I izraz "aplikacija baze podataka" bio je uobičajen. Što je uključivala ova aplikacija? Pojednostavljeno - neki obrasci za unos putem kojih su korisnici mogli istovremeno unositi informacije, neki izračuni koji su se pokretali "na gumb" ili "po rasporedu", kao i neka izvješća koja su se mogla vidjeti na ekranu ili spremiti kao datoteke i poslati na pečat.
"Ništa posebno - normalna primjena, postoji samo baza podataka,” kako je primijetio jedan od mojih mentora u ranoj fazi moje karijere. “Zar nije ništa posebno?” - pomislio sam tada.

Ako pažljivo pogledate, još uvijek postoje neke značajke. Kako korisnici rastu, količina dolaznih informacija raste, a opterećenje sustava raste, njegovi programeri i dizajneri pribjegavaju određenim "trikovima" kako bi održali performanse na prihvatljivoj razini. Prva stvar je podjela monolitnog “sustava za obradu poslovnih podataka” na računovodstvenu aplikaciju koja podržava rad korisnika on-line te zasebnu aplikaciju za skupnu obradu podataka i izvješćivanje. Svaka od ovih aplikacija ima vlastitu 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. Između njih se grade protok podataka.

Ovo je sve? Čini se da je problem riješen. Što je slijedeće?
A onda tvrtke rastu, njihove potrebe za informacijama se umnožavaju. Raste i broj interakcija s vanjskim svijetom. I na kraju, ne postoji jedna velika aplikacija koja potpuno automatizira sve procese, već nekoliko različitih, od različitih proizvođača. Broj sustava koji generiraju informacije—sustava izvora podataka—u poduzeću raste. I prije ili kasnije, bit će potrebno vidjeti i usporediti informacije dobivene iz različitim sustavima. Tako se u tvrtki pojavljuju skladišta podataka - nova klasa sustava.
Općeprihvaćena definicija ove klase sustava zvuči ovako.

Skladište podataka (ili skladište podataka)– predmetno orijentirana informacijska baza podataka posebno dizajnirana i namijenjena izradi izvješća i poslovnih analiza za podršku odlučivanju u organizaciji

Tako, konsolidacija podataka iz različitih sustava, mogućnost da se oni promatraju na određeni "jedinstven" (objedinjen) način jedno je od ključnih svojstava sustava klasa skladišta podataka. To je razlog zašto je pohrana nastala tijekom evolucije IT sustava.

Ključne značajke skladišta podataka

Pogledajmo pobliže. Koji glavne značajke imaju li ovi sustavi? Što razlikuje skladišta podataka od ostalih IT sustava poduzeća?

Prvo, to su velike količine. Jako veliko. VLDB – tako takve sustave nazivaju vodeći proizvođači kada daju svoje preporuke za korištenje svojih proizvoda. Podaci iz svih sustava tvrtke teku u ovu veliku bazu podataka i tamo se pohranjuju "vječno i nepromjenjivo", kako kažu udžbenici (u praksi se život pokazuje kompliciranijim).

Drugo, ovo su povijesni podaci - “Korporativna memorija” – tako se zovu skladišta podataka. Što se tiče rada s vremenom u skladištima, sve je vrlo zanimljivo. U računovodstvenim sustavima podaci su trenutni. Zatim korisnik izvrši određenu operaciju i podaci se ažuriraju. Međutim, povijest promjena možda neće biti sačuvana - to ovisi o računovodstvenim praksama. Uzmimo, na primjer, stanje vašeg bankovnog računa. Može nas zanimati trenutni saldo od "sada", na kraju dana ili u vrijeme nekog događaja (na primjer, u vrijeme izračuna bodovanja). Ako su prva dva riješena prilično jednostavno, onda će posljednji najvjerojatnije zahtijevati posebne napore. Korisnik, radeći s pohranom, može pristupiti prošlim razdobljima, usporediti ih s trenutnim, itd. Upravo takve 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, ovo konsolidacija I objedinjavanje podataka . Da bi njihova zajednička analiza postala moguća, potrebno ih je dovesti u zajednički oblik – jedinstveni model podataka , usporedite činjenice s objedinjenim referentnim knjigama. Ovdje može postojati nekoliko aspekata i poteškoća. Kao prvo - pojmovni – različiti ljudi iz različitih odjela mogu pod istim pojmom razumjeti različite stvari. I obrnuto – drugačije nazivati ​​nešto što je u biti isto. Kako osigurati „jedinstven pogled“, a pritom zadržati specifičnost vizije pojedine skupine korisnika?

Četvrto, ovo je rad sa kvaliteta podataka . Tijekom procesa učitavanja podataka u skladište vrši se čišćenje podataka, generalne 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 odstupanja koja izazivaju toliko iritacije kod poslovnih korisnika - posebno kod uprave, kojoj se prezentiraju brojevi iz različitih odjela koji se međusobno ne slažu. Loša kvaliteta podataka dovodi do pogrešaka i nepodudarnosti u izvješćima, što za posljedicu ima smanjenje razine povjerenje korisnika na cijeli sustav, na cjelokupnu analitičku službu u cjelini.

Arhitektonski koncept

Svatko tko je naišao na skladište najvjerojatnije je primijetio neku vrstu "slojevite strukture" - jer. Upravo je ova arhitektonska paradigma ukorijenjena za sustave ove klase. I to ne slučajno. Slojevi pohrane mogu se promatrati kao zasebne komponente sustava - sa svojim zadacima, područjima odgovornosti i "pravilima igre".
Slojevita arhitektura je sredstvo suočavanja sa složenošću sustava - svaka sljedeća razina apstrahirana je od složenosti unutarnje implementacije prethodne. Ovaj vam pristup omogućuje prepoznavanje sličnih problema i njihovo rješavanje na jednoobrazan način, bez ponovnog izmišljanja "bicikla" svaki put ispočetka.
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 će nastati dubljom razradom detalja.

Kao što je prikazano na dijagramu, konceptualno ističemo sljedeće slojeve. Tri glavna sloja koji sadrže područje pohrane podataka (označeno ispunjenim pravokutnikom) i softver za učitavanje podataka (uobičajeno prikazano strelicama iste boje). I također pomoćni - servisni sloj, koji ipak igra vrlo važnu ulogu povezivanja - upravljanje učitavanjem podataka i kontrola kvalitete.

Primary Data Layer - primarni podatkovni sloj (ili uprizorenje , ili operativni sloj ) - namijenjen za učitavanje iz izvornih sustava i spremanje primarnih informacija, bez transformacije - u izvorna kvaliteta i podrška za potpunu povijest promjena.
Svrha ovog sloja– apstrahirati naknadne slojeve pohrane iz fizičke strukture izvora podataka, metode prikupljanja podataka i metode za izolaciju delta promjena.

Core Data Layer - jezgra za pohranu – središnja komponenta sustava koja razlikuje repozitorij od samo „platforme za skupnu integraciju” ili „izbacivanja velikih podataka”, budući da je njegova glavna uloga konsolidacija podataka iz različitih izvora, svođenje na jedinstvene strukture, ključevi. Prilikom učitavanja u kernel obavlja se glavni posao s kvalitetom podataka i općim transformacijama, što može biti prilično složeno.
Svrha ovog sloja– apstrahirajte svoje potrošače od posebnosti logičke strukture izvora podataka i potrebe za usporedbom podataka iz različitih sustava, osigurajte cjelovitost i kvalitetu podataka.

Data Mart Layer - analitički prikazi – komponenta čija je glavna funkcija transformirati podatke u strukture pogodne za analizu (ako BI radi s izlozima, onda je to obično dimenzionalni model), ili prema zahtjevima potrošačkog sustava.
Izlozi u pravilu uzimaju podatke iz jezgre - kao pouzdanog i provjerenog izvora - tj. koristiti uslugu ove komponente za dovođenje podataka u jedan obrazac. Takve ćemo vitrine nazvati redovito . U nekim slučajevima izlozi mogu preuzeti podatke izravno iz prikazivanja - pomoću primarnih podataka (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 važnija od kvalitete podataka. Takve vitrine nazivaju se operativni . Neki analitički pokazatelji mogu imati vrlo složene metode izračuna. Stoga, za takve netrivijalne proračune i transformacije, tzv sekundarne vitrine .
Zadatak sloja prikaza– priprema podataka prema zahtjevima određenog potrošača – BI platforme, grupe korisnika ili vanjskog sustava.

Gore opisani slojevi sastoje se od područja trajne pohrane podataka, kao i softverskog modula za učitavanje i transformiranje podataka. Ova podjela na slojeve i područja je logična. Fizička 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.
Skladišni prostori sadrže tehničke (buffer tablice) koje se koriste u procesu transformacije podataka i ciljne tablice, kojemu pristupa komponenta koja troši. Dobra je praksa "pokriti" ciljane tablice 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 revizija informacija podaci teku u pohranu.

Također je identificirana posebna komponenta (ili skup komponenti) koja pruža servisne funkcije za sve slojeve. Jedna od njegovih ključnih zadaća je funkcija kontrole – osigurati “ jedinstvena pravila igre" za cijeli sustav u cjelini, zadržavajući pravo korištenja različitih mogućnosti implementacije za svaki od gore opisanih slojeva - uklj. koristiti različite tehnologije učitavanje i obrada podataka, različite platforme za pohranu itd. Nazovimo ga servisni sloj . Ne sadrži poslovne podatke, ali ima vlastite 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 pojedinačne komponente značajno povećava upravljivost razvoja sustava:

• smanjuje se složenost zadatka koji se postavlja razvojnom programeru funkcionalnosti pojedine komponente (on ne mora istovremeno rješavati pitanja integracije s vanjskim sustavima, promišljati procedure čišćenja podataka i razmišljati o optimalnoj prezentaciji podataka). za potrošače) - zadatak je lakše raščlaniti, ocijeniti i izvršiti malu isporuku;
• u posao možete uključiti razne izvođače (pa čak i timove ili izvođače) – jer Ovaj vam pristup omogućuje učinkovito paraleliziranje zadataka, smanjujući njihov međusobni utjecaj;
• prisutnost postojanog staginga omogućuje vam brzo povezivanje izvora podataka bez dizajniranja cijele jezgre ili prikaza za cijelo predmetno područje, a zatim postupnu izgradnju preostalih slojeva prema prioritetima (a podaci će već biti u pohrani - dostupni sustavu analitičari, što će značajno olakšati zadatke kasnijeg razvoja skladišta);
• prisutnost kernela omogućuje da se sav rad s kvalitetom podataka (kao i eventualne greške i greške) sakrije od izloga i od krajnjeg korisnika, a što je najvažnije, korištenjem ove komponente kao jedinstvenog izvora podataka za izloge, problemi s konvergencijom podataka mogu se izbjeći zahvaljujući implementaciji zajedničkih algoritama na jednom mjestu;
• isticanje vitrina omogućuje vam da uzmete u obzir razlike i specifično razumijevanje podataka koje korisnici različitih odjela mogu imati, a njihov dizajn prema BI zahtjevima omogućuje vam ne samo izradu agregiranih brojki, već i osiguranje pouzdanosti podataka pružanjem mogućnost bušenja do primarnih pokazatelja;
• prisutnost servisnog sloja omogućuje vam izvođenje end-to-end analize podataka (podatkovne linije), korištenje unificiranih alata za reviziju podataka, općenite pristupe identificiranju 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") i osigurava njegovu antifragilnost:

• promjene iz izvornih sustava obrađuju se u stagingu - u kernelu se mijenjaju samo one niti koje su pod utjecajem ovih staging tablica; utjecaj na izloge je minimalan ili ga nema;
• promjene u zahtjevima potrošača obrađuju se najvećim dijelom u izlozima (osim ako su potrebne dodatne informacije koje već nisu u repozitoriju).

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

Jezgra sustava

Počnimo “od sredine” – jezgre sustava ili srednjeg sloja. No je označen kao temeljni sloj. Kernel obavlja ulogu konsolidacije podataka - redukcije na jedinstvene strukture, direktorije, ključeve. Ovdje se odvija glavni posao s kvalitetom podataka - čišćenje, transformacija, unifikacija.

Prisutnost ove komponente omogućuje vam ponovnu upotrebu tokova podataka koji pretvaraju primarne podatke primljene iz izvornih sustava u objedinjeni format, slijedeći opća pravila i algoritme, umjesto da ponavljate implementaciju iste funkcionalnosti zasebno za svaki prikaz aplikacije, što, osim neučinkovito korištenje resursa, može dovesti do Postoje i razlike u podacima.
Jezgra za pohranu implementirana je u podatkovni model koji se općenito razlikuje kako od modela izvornih sustava tako i od formata i struktura potrošača.

Storage Core Model i Enterprise Data Model

Glavna zadaća srednjeg sloja za pohranu je stabilnost. Zato je ovdje glavni naglasak na modelu podataka. Obično se naziva "korporacijski podatkovni model". Nažalost, oko njega se stvorio određeni oreol mitova i apsurda koji ponekad dovode do potpunog odustajanja od njegove izgradnje, ali uzalud.

Mit 1. Podatkovni model poduzeća ogroman je model koji se sastoji od tisuća entiteta (tablica).
Zapravo. U bilo kojem predmetnom području, u bilo kojoj poslovnoj domeni, u podacima svake tvrtke, čak i one najsloženije, nekoliko je glavnih entiteta - 20-30.

Mit 2. Nema potrebe razvijati nikakav "vlastiti model" - kupujemo referentni model industrije i radimo sve u skladu s njim. Trošimo novac, ali dobivamo zajamčene rezultate.
Zapravo. Referentni modeli zapravo mogu biti vrlo korisni jer... sadrže industrijsko iskustvo u modeliranju ovog područja. Iz njih možete prikupiti ideje, pristupe i prakse imenovanja. Provjerite "dubinu pokrivenosti" područja kako ne biste propustili nešto važno. Ali malo je vjerojatno da ćemo moći koristiti takav model "iz kutije" - kakav jest. To je isti mit kao, na primjer, kupiti ERP sustav (ili CRM) i implementirati ga bez ikakvog "prilagođavanja". Vrijednost takvih modela rađa se u njihovoj prilagodbi realnosti ovog konkretnog posla, ove konkretne tvrtke.

Mit 3. Razvoj modela jezgre za pohranu može potrajati nekoliko mjeseci, a tijekom tog vremena projekt će zapravo biti zamrznut. Također zahtijeva suludu količinu sastanaka i mnogo uključenih ljudi.
Zapravo. Model repozitorija može se razvijati zajedno s repozitorijem iterativno, postupno. Za područja koja nisu pokrivena postavljaju se "točke produžetka" ili "izbočine" - tj. Koriste se neki "univerzalni dizajni". Istovremeno, morate znati kada stati kako ne biste završili sa superuniverzalnom stvari koja se sastoji od 4 tablice, u koje je teško i “staviti podatke” i (još teže) dobiti van. I koji radi izrazito suboptimalno što se tiče performansi.

Doista će trebati vremena za razvoj modela. Ali to nije vrijeme potrošeno na "crtanje entiteta" - ovo je vrijeme potrebno za analizu predmetnog područja, razumijevanje kako su podaci strukturirani. Zato su analitičari vrlo blisko uključeni u ovaj proces, a uključeni su i razni poslovni stručnjaci. I to se radi točkasto, selektivno. A ne organiziranjem skupova na kojima sudjeluje ludi broj ljudi, slanjem silnih upitnika itd.
Kvalitativna analiza poslovanja i sustava ključna je prilikom izgradnje modela jezgre pohrane. Morate razumjeti puno stvari: gdje (u kojim sustavima) se podaci generiraju, kako su organizirani, u kojim poslovnim procesima cirkuliraju itd. Kvalitativna analiza nikada nije naštetila niti jednom sustavu. Naprotiv, problemi proizlaze iz “slijepih pjega” u našem razumijevanju.

Razvoj podatkovnog modela nije proces izmišljanja i smišljanja nečeg novog. Zapravo, podatkovni model tvrtke već postoji. A proces dizajniranja više je poput "iskapanja". Model se pažljivo i brižno izvlači na svjetlo dana s “tla” korporativnih podataka i stavlja u strukturirani oblik.

Mit 4. U našoj tvrtki posao je toliko dinamičan i sve se tako brzo mijenja da nam je beskorisno stvarati model – zastarjet će prije nego što ovaj dio sustava stavimo u funkciju.
Zapravo. Podsjetimo se da je ključni faktor jezgre 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, to znači da je krivo dizajniran. Za njegov razvoj odabrani su pogrešni pristupi i “pravila igre”. I to je također pitanje kvalitativne analize. Suština korporativnog modela mijenja se iznimno rijetko.
Ali ako nam padne na pamet napraviti za tvrtku koja prodaje, recimo, slastičarske proizvode, umjesto imenika “Proizvodi” napraviti “Slatkiši”, “Kolači” i “Pite”. Kada se pizza pojavi na popisu robe, da, morat ćete unijeti mnogo novih tablica. A ovo je samo pitanje pristupa.

Mit 5. Stvaranje korporativnog modela vrlo je ozbiljna, složena i odgovorna stvar. I strašno je pogriješiti.
Zapravo. Iako bi osnovni model trebao biti stabilan, još uvijek nije "izliven u metal". Kao i svaka druga dizajnerska odluka, njegova se struktura može pregledavati i mijenjati. Samo ne treba zaboraviti ovu njezinu kvalitetu. Ali to uopće ne znači da na njemu "ne možete disati". A to ne znači da su privremena rješenja i „zaglavci“ koje treba planirati za obradu neprihvatljivi.

Mit 6. Ako je naš izvor podataka, na primjer, sustav za upravljanje glavnim podacima (ili sustav za upravljanje glavnim podacima - MDM), tada bi već trebao dobro odgovarati korporativnom modelu (osobito ako je nedavno dizajniran i nije imao vremena za nabavu “ nuspojave”, “tradicije” “i privremene zgrade). Ispada da nam za ovaj slučaj ne treba model kernela?
Zapravo. Da, u ovom je slučaju izgradnja modela kernela za pohranu uvelike pojednostavljena – jer slijedimo gotov konceptualni model najviše razine. Ali nije potpuno isključeno. Zašto? Jer kada se gradi model određenog sustava, vrijede određena pravila - koje vrste tablica koristiti (za svaki entitet), kako verzirati podatke, s kojom granularnošću čuvati povijest, koje meta-atribute (tehnička polja koristiti) itd. .

Osim toga, bez obzira na to koliko divan i sveobuhvatan sustav matičnih podataka i upravljanja podacima imamo, u pravilu će postojati nijanse povezane s postojanjem lokalnih imenika "o istoj stvari" u drugim računovodstvenim sustavima. A taj problem, htjeli mi to ili ne, morat ćemo riješiti u skladištu - uostalom, ovdje se prikupljaju izvještaji i analitika.

Primarni podatkovni sloj (ili historizirani inscenacijski ili operativni sloj)

Označen je 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 formata i logičke kontrole utvrđene u "ugovoru o sučelju interakcije" s izvorom.
Osim toga, ova komponenta rješava vrlo važan zadatak za repozitorij - izoliranje "prave delte promjena" - neovisno o tome omogućuje li izvor praćenje promjena u podacima ili ne i kako (po kojem kriteriju se mogu "uhvatiti" ). Čim podaci uđu u staging, za sve ostale slojeve pitanje delta dodjele je već jasno - zahvaljujući označavanju meta atributima.

Podaci u ovom sloju pohranjuju se u strukture koje su što bliže izvornom sustavu – kako bi primarni podaci bili što bliži izvornom obliku. Drugi naziv za ovu komponentu je "operacijski sloj".
Zašto jednostavno ne upotrijebiti uvriježeni izraz "uprizorenje"? Činjenica je da je prije, prije "ere velikih podataka i VLDB-a", prostor na disku bio vrlo skup - i često su primarni podaci, ako su uopće spremljeni, bili pohranjeni na ograničeno vremensko razdoblje. I često se naziva "uprizorenje". koji se može čistiti pufer.
Sada je tehnologija zakoračila naprijed - i možemo si priuštiti ne samo pohranjivanje svih primarnih podataka, već i njihovo historiziranje uz stupanj granularnosti koji je moguć. To ne znači da ne bismo trebali kontrolirati rast podataka i ne eliminira potrebu za upravljanjem životnim ciklusom informacija, optimizirajući troškove pohrane podataka, ovisno o "temperaturi" korištenja - tj. premještanje “hladnih podataka”, koji su manje traženi, na jeftinije medije i platforme za pohranu.

Što nam daje prisutnost “historizirane inscenacije”:

• mogućnost pravljenja pogrešaka (u strukturama, u algoritmima transformacije, u granularnosti povijesti) - s potpuno historiziranim primarnim podacima u prostoru za pohranu, uvijek možemo ponovno učitati naše tablice;
• prilika za razmišljanje - možemo odvojiti vrijeme za razvoj velikog fragmenta kernela u ovoj određenoj iteraciji razvoja repozitorija, jer u našoj će inscenaciji u svakom slučaju biti, i to s ravnomjernim vremenskim horizontom (“referentna točka povijesti” bit će jedna);
• mogućnost analize - sačuvat ćemo i one podatke koji više nisu u izvoru - mogli su se tamo izgubiti, otići u arhivu i sl. – 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 u konačnici dobili takve brojke (za to također moramo imati oznake metaatributa i odgovarajuće metapodatke na koje preuzimanje radi - o tome se odlučuje na sloju usluge).

Koje poteškoće mogu nastati pri konstruiranju “historizirane 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đene i podređene tablice) – poravnanje cjelovitosti događa se na sljedećim slojevima;
• ovaj sloj sadrži vrlo velike količine (najvoluminoznije na pohrani - usprkos svoj redundanciji analitičkih struktura) - i morate biti u mogućnosti rukovati takvim količinama - i sa gledišta učitavanja i sa gledišta upita (inače možete ozbiljno pogoršati performanse cijele pohrane).

Što se još zanimljivo može reći o ovom sloju.
Prvo, ako se odmaknemo od paradigme „procesa utovara s kraja na kraj“, onda kod nas više ne funkcionira pravilo „karavana se kreće brzinom posljednje deve“, točnije, napuštamo „karavanu“ načelo i prijeđite na načelo "konvejera": uzeli smo podatke iz izvora - stavili ih u vaš sloj - spremni preuzeti sljedeći dio. To znači da
1) ne čekamo da se obrada dogodi na drugim slojevima;
2) ne ovisimo o rasporedu pružanja podataka drugih sustava.
Jednostavno rečeno, planiramo proces učitavanja koji uzima podatke iz jednog izvora putem određenog načina povezivanja s njim, provjerava ih, dodjeljuje delta - i smješta podatke u ciljne tablice za postavljanje. To je sve.

Drugo, ti su procesi, kao što vidite, strukturirani vrlo jednostavno - moglo bi se reći trivijalno, s logičke točke gledišta. To znači da se mogu vrlo dobro optimizirati i parametrizirati, smanjujući opterećenje našeg sustava i ubrzavajući proces povezivanja izvora (vrijeme razvoja).
Da bi se to dogodilo, morate vrlo dobro poznavati tehnološke značajke platforme na kojoj se ova komponenta pokreće - i tada možete napraviti vrlo učinkovit alat.

Analitički prikazni sloj

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

Ako je potrošač vanjski sustav, onda on u pravilu diktira potrebne strukture podataka i propise za prikupljanje informacija. Dobar pristup je onaj u kojem je sam potrošač odgovoran za ispravno prikupljanje podataka. Skladište podataka pripremilo je podatke, izradilo izlog, omogućilo inkrementalno prikupljanje podataka (označavanje metaatributima za naknadnu identifikaciju delta promjena), a potrošački sustav zatim upravlja i odgovoran je za to kako koristi taj izlog. Ali postoje neke osobitosti: kada sustav nema aktivnu komponentu za prikupljanje podataka, ili je potrebna vanjska komponenta koja će obavljati integrirajuću funkciju, ili će pohrana djelovati kao "integracijska platforma" - i osigurat će ispravno inkrementalno učitavanje podataka dalje od pohrane. Ovdje se pojavljuju mnoge nijanse, a pravila interakcije sučelja moraju biti promišljena i razumljiva objema stranama (međutim, kao i uvijek, kada je u pitanju integracija). Takvi su izlozi u pravilu podložni rutinskom čišćenju/arhiviranju podataka (rijetko je potrebno da se ti “tranzitni podaci” čuvaju dulje vrijeme).

Najveću vrijednost sa stajališta analitičkih zadataka imaju vitrine “za ljude” - točnije za BI alate s kojima rade.
Međutim, postoji kategorija "posebno naprednih korisnika" - analitičari, podatkovni znanstvenici - koji ne trebaju niti BI alate niti regulatorne procese za punjenje vanjskih specijaliziranih sustava. Potrebna im je neka vrsta "zajedničke vitrine" i "vlastitog pješčanika" gdje mogu kreirati tablice i transformacije po vlastitom nahođenju. U ovom slučaju, odgovornost repozitorija je osigurati da se ti zajednički izlozi popune podacima u skladu s propisima.
Zasebno možemo istaknuti takve potrošače kao alate za rudarenje podataka - duboku analizu podataka. Takvi alati imaju svoje zahtjeve za pretpripremu podataka, a s njima rade i stručnjaci za rudarenje podataka. Za repozitorij, zadatak se opet svodi na podršku usluge za učitavanje određenih vitrina dogovorenog formata.

Ipak, vratimo se analitičkim vitrinama. Oni su od interesa sa stajališta razvijača pohrane u ovom podatkovnom sloju.
Po mom mišljenju, najbolji provjereni pristup dizajniranju podatkovnih martova, prema kojemu su sada “skrojene” gotovo sve BI platforme, je pristup Ralpha Kimballa. Poznato je kao dimenzionalno modeliranje – višedimenzionalno modeliranje. Postoji jako puno publikacija na ovu temu. Na primjer, osnovna pravila mogu se pronaći u publikaciji Marge Ross. I naravno, možete ga preporučiti od gurua multidimenzionalnog modeliranja. Još jedan koristan izvor su Kimballovi savjeti
Višedimenzionalni pristup stvaranju izloga toliko je dobro opisan i razrađen - kako od strane "evanđelista metode" tako i od strane vodećih dobavljača softvera da nema smisla ovdje se o tome detaljno zadržavati - izvorni izvor je uvijek poželjan.

Htio bih samo jedno naglasiti. “Izvješćivanje i analitika” mogu biti različiti. Postoji "teško izvješćivanje" - unaprijed naručena izvješća koja se generiraju u obliku datoteka i isporučuju korisnicima putem ponuđenih kanala isporuke. A tu su i informacijske ploče – BI nadzorne ploče. U svojoj srži, to su web aplikacije. A vrijeme odziva ovih aplikacija podliježe istim zahtjevima kao i za bilo koju drugu web aplikaciju. To znači da je normalno vrijeme osvježavanja BI nadzorne ploče sekunde, a ne minute. Važno je to zapamtiti kada razvijate rješenje. Kako to postići? Standardna metoda optimizacije: pogledajte što čini vrijeme odziva i na što možemo utjecati. Što vam najviše gubi vrijeme? Za fizičko (disk) čitanje baze podataka, za prijenos podataka preko mreže. Kako smanjiti količinu podataka koji se čitaju i prenose po zahtjevu? Odgovor je očigledan i jednostavan: trebate ili agregirati podatke ili primijeniti filtar na velikim tablicama na tablice činjenica koje sudjeluju u upitu i isključiti vezu velikih tablica (reference na tablice činjenica trebaju ići samo kroz dimenzije).

Zašto vam je potreban BI? Kako je to zgodno? Zašto je višedimenzionalni model učinkovit?
BI korisniku omogućuje izvršavanje takozvanih “ad hoc upita”. Što to znači? To znači da ne znamo unaprijed točan zahtjev, ali znamo koje pokazatelje u kojim odjeljcima korisnik može zatražiti. Korisnik generira takav upit odabirom odgovarajućih BI filtera. A zadatak BI programera i dizajnera prodajnog izloga je osigurati takvu logiku aplikacije tako da se podaci ili filtriraju ili agregiraju, izbjegavajući situaciju u kojoj se traži previše podataka i aplikacija visi. Obično počinju sa skupnim brojevima, zatim idu dublje 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 gledate kako će to utjecati na opterećenje), a negdje ćete morati stvoriti sekundarne vitrine i agregate. Dodajte negdje indekse ili projekcije (ovisno o DBMS-u).

Dakle, putem "pokušaja i pogrešaka" moguće je dobiti strukturu koja je optimalna za BI - koja će uzeti u obzir značajke i DBMS-a i BI platforme, kao i zahtjeve korisnika za prezentaciju podataka.
Ako uzmemo podatke iz "jezgre", tada će takva obrada izloga biti lokalne prirode, bez ikakvog utjecaja na složenu obradu primarnih podataka dobivenih izravno iz izvornih sustava - mi samo "prebacujemo" podatke u format pogodan za DVO. A to si možemo priuštiti puno puta, na različite načine, u skladu s različitim zahtjevima. Korištenjem kernel podataka, to je puno lakše i brže nego prikupljanje iz "primarnog" (čija struktura i pravila, kao što znamo, također mogu "plutati").

Servisni sloj

Servisni sloj (- Service Layer) odgovoran je za implementaciju uobičajenih (servisnih) funkcija koje se mogu koristiti za obradu podataka u različitim slojevima pohrane - upravljanje učitavanjem, upravljanje kvalitetom podataka, dijagnoza problema i alati za praćenje itd.
Dostupnost ovoj razini 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 off-line provjera kvalitete podataka (tj. onih koji nisu ugrađeni izravno u ETL procese).

Proces upravljanja preuzimanjem možete strukturirati na različite načine. Jedan od mogućih pristupa je sljedeći: cijeli skup skladišnih tablica podijelimo na module. Modul može sadržavati samo tablice iz jednog sloja. Tablice uključene u svaki modul učitavaju se unutar zasebnog procesa. Nazovimo ga proces kontrole . Zakazano je pokretanje procesa kontrole. Glavni proces orkestrira pozive atomskim procesima, od kojih svaki učitava jednu ciljnu tablicu, a također sadrži neke uobičajene korake.
Očigledno, dovoljno je jednostavno podijeliti scenske tablice na module - prema izvornim sustavima, točnije, njihovim spojnim točkama. Ali za kernel je to već teže učiniti, jer tu moramo osigurati integritet podataka, što znači da moramo uzeti u obzir ovisnosti. Oni. pojavit će se sukobi koje treba riješiti. I postoje različite metode za njihovo rješavanje.

Važna točka u upravljanju opterećenjem je razviti jedinstveni pristup rukovanju pogreškama. Pogreške su klasificirane prema razini ozbiljnosti. Ako dođe do kritične pogreške, proces se mora zaustaviti, i to što je brže 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 preranog pokretanja (greškom).

Za upravljanje slojem usluge kreirana je posebna struktura metapodataka. Ovo područje će pohraniti informacije o procesima učitavanja, učitanim skupovima podataka, kontrolnim točkama koje se koriste za inkrementiranje (koji je proces do koje točke pročitao) i druge servisne informacije 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 red. Za tablice unutar repozitorija, ovo procesno označavanje omogućuje unificirani način naknadnog isticanja promjene delta. Kod učitavanja podataka u primarni podatkovni sloj situacija je kompliciranija - algoritam delta dodjele za različite učitane objekte može biti različit. Ali logika obrade prihvaćenih promjena i njihovog uvođenja u ciljne tablice za kernel i izloge puno je kompliciranija nego za staging, gdje je sve prilično trivijalno - lako je parametrizirati i razmišljati kroz višekratne standardne korake (postupke).

Ne želim ovdje u potpunosti pokriti ovu temu - organizaciju učitavanja - samo ističem točke na koje vrijedi obratiti pozornost.
Gore navedeni pristup je samo jedna opcija. Prilično je prilagodljiv. A njegov "konceptualni prototip" bila je Toyotina pokretna traka i sustav točno na vrijeme. Oni. Ovdje se udaljavamo od široko rasprostranjene paradigme isključivo “noćnog učitavanja podataka” i učitavanja u malim obrocima tijekom dana - budući da su podaci spremni u raznim izvorima: ono što je stiglo preuzeto je. U isto vrijeme imamo mnogo paralelnih procesa koji se odvijaju. A "vrući rep" svježih podataka stalno će "treperiti" - i nakon nekog vremena će se izravnati. Ovu značajku moramo uzeti u obzir. I, ako je potrebno, izradite prilagođene vitrine u "kriškama", gdje je sve već dovršeno. Oni. Nemoguće je postići i učinkovitost i dosljednost (integritet) u isto vrijeme. Treba nam ravnoteža – negdje je važno jedno, negdje drugo.

Od ključne je važnosti osigurati mogućnosti zapisivanja i praćenja. Dobra praksa je koristiti tipizirane događaje, gdje možete postaviti različite parametre te postaviti sustav obavješćivanja – pretplatu na određene događaje. Jer Vrlo je važno da kada je potrebna intervencija administratora sustava, on to što ranije sazna i dobije sve potrebne dijagnostičke informacije. Dnevnici se također mogu koristiti za analizu problema nakon događaja, kao i za istraživanje incidenata kvarova sustava, uklj. kvaliteta podataka.

Projektiranje i održavanje modela skladišnih podataka

Zašto je važno obratiti pažnju na dizajn podatkovnih modela pri razvoju bilo kojeg sustava koji uključuje bazu podataka (a posebno skladište)? Zašto jednostavno ne bacite skup tablica bilo gdje - čak iu uređivaču teksta? Zašto su nam potrebne “ove slike”?
Čudno, čak i iskusni programeri postavljaju slična 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 cjelokupnu sliku strukture koju oblikuje. Što ako postoji nekoliko programera? Što ako netko drugi koristi ove tablice? Što ako vrijeme prođe - osoba napusti ovo područje, pa se opet u njega vrati?

Je li to moguće shvatiti bez modela? U principu je moguće. I shvatite to, i "odgonetnite slike na komadu papira", i "proribajte i odaberite" podatke. Ali puno je lakše, jasnije i brže koristiti gotov artefakt - podatkovni model. I također razumjeti "logiku njegove strukture" - tj. Bilo bi lijepo imati opća pravila igre.

A najvažnije nije ni ovo. Ono što je najvažnije je da smo pri projektiranju modela prisiljeni (jednostavno bez mogućnosti!) pomnije i dublje proučiti predmetno područje, značajke strukture podataka i njihovu upotrebu u različitim poslovnim slučajevima. A ona pitanja koja smo lako mogli "gurnuti u stranu" kao teška, "zamaglili" smo izbacujući svoje znakove, a da zapravo nismo ni pokušali oblikovati model - bit ćemo prisiljeni postaviti i odlučiti sada, tijekom analize i dizajna, a ne kasnije - kada budemo gradili izvješća i razmišljali o tome “kako spojiti nespojivo” i svaki put “izmisliti kotač”.

Ovaj je pristup jedan od onih inženjerskih postupaka koji nam omogućuju stvaranje protulomljivih sustava. Budući da su jasno dizajnirani, transparentni, lako se razvijaju, a 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) .
Stoga je podatkovni model jedan od glavnih artefakata koji se moraju održavati tijekom razvoja sustava. U dobrom smislu, trebao bi biti “na stolu” svakog analitičara, programera itd. – svi koji sudjeluju u projektima razvoja sustava.

Dizajn podatkovnih modela je posebna, vrlo široka tema. Pri projektiranju skladišnih objekata koriste se dva glavna pristupa.
Pristup dobro funkcionira za kernel "entitet-odnos" - kada se normalizirani (3NF) model gradi na temelju proučavanja predmetnog područja, točnije na njegovom odabranom području. Ovdje je u igri isti "korporacijski model" o kojem smo govorili gore.

Pogodno za projektiranje analitičkih vitrina višedimenzionalni model . Ovaj pristup dobro odgovara razumijevanju poslovnih korisnika - jer... Ovo je model koji je jednostavan i pogodan za ljudsku percepciju - ljudi rade s razumljivim i poznatim konceptima metrike (indikatora) i odjeljaka po kojima se oni analiziraju. A to nam omogućuje jednostavno i jasno strukturiranje procesa prikupljanja zahtjeva - crtamo skup "matrica odjeljaka i pokazatelja", komunicirajući s predstavnicima različitih odjela. A onda ih kombiniramo u jednu strukturu - “model analize”: formiramo “mjernu sabirnicu” i utvrđujemo činjenice koje su na njima definirane. Usput radimo na hijerarhijama i pravilima združivanja.

Zatim je vrlo lako prijeći na fizički model, dodajući elemente optimizacije uzimajući u obzir značajke DBMS-a. Na primjer, za Oracle to će biti particioniranje, skup indeksa itd. Za Verticu će se koristiti druge tehnike - sortiranje, segmentacija, particioniranje.
Može biti potrebna i posebna denormalizacija - kada namjerno unosimo redundanciju u podatke, zahvaljujući kojoj poboljšavamo izvedbu upita, ali istovremeno kompliciramo ažuriranje podataka (budući da će se redundancija morati uzeti u obzir i održavati tijekom proces učitavanja podataka). Možda ćemo, kako bismo poboljšali izvedbu, također morati izraditi dodatne zbirne tablice ili ih koristiti dodatne mogućnosti DBMS kao projekcije u Vertici.

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

• zadatak izgradnje konceptualnog (logičkog) modela kernela - analiza sustava i poslovanja - istraživanje predmetnog područja, ulaženje u detalje i uzimanje u obzir nijansi “živih podataka” i njihove upotrebe u poslovanju;
• zadatak konstruiranja modela analize - a potom i konceptualnog (logičkog) modela izloga;
• Zadatak izgradnje fizičkih modela je upravljanje redundancijom podataka, optimizacija uzimajući u obzir značajke DBMS-a za upite i učitavanje podataka.

Prilikom razvoja konceptualnih modela možda nećemo uzeti u obzir značajke specifičnog DBMS-a za koji dizajniramo strukturu baze podataka. Štoviše, možemo koristiti jedan konceptualni model za stvaranje nekoliko fizičkih - za različite DBMS-ove.

Sažmimo.

• Model podataka nije skup " lijepe slike“, a proces dizajniranja nije proces njihovog crtanja. Model odražava naše razumijevanje predmetnog područja. A proces sastavljanja je proces proučavanja i istraživanja. Ovdje se gubi vrijeme. I uopće ne "crtati i slikati".
• Podatkovni model je artefakt projekta, način razmjene informacija u strukturiranom obliku između članova tima. Da bi to učinili, mora biti svima razumljiv (to je predviđeno zapisom i objašnjenjem) i dostupan (objavljen).
• Podatkovni model se ne kreira jednom i zamrzne, već se kreira i razvija tijekom razvoja sustava. Sami postavljamo pravila za njegov razvoj. A možemo ih promijeniti ako vidimo kako ih učiniti boljim, jednostavnijim, učinkovitijim.
• Model podataka (fizički) omogućuje vam konsolidaciju i korištenje skupa najboljih praksi usmjerenih na optimizaciju - tj. koristiti tehnike koje su već radile za ovaj DBMS.

Značajke projekata skladišta podataka

Zadržimo se na značajkama projekata u okviru kojih tvrtka gradi i razvija skladišta podataka. I pogledajmo ih sa stajališta utjecaja arhitektonskog aspekta. Zašto je važno graditi arhitekturu za takve projekte, i to od samog početka. A prisutnost dobro promišljene arhitekture daje fleksibilnost projektu skladišta podataka, omogućuje vam učinkovitu raspodjelu rada 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 uvijek je "prilagođeni razvoj", a ne pakirano rješenje. Da, postoje BI aplikacije specifične za industriju koje uključuju model referentnih podataka, unaprijed konfigurirane ETL procese iz uobičajenih izvora (na primjer, ERP sustavi) i skup standardnih BI nadzornih ploča i izvješća. Ali u praksi se skladištenje izuzetno rijetko provodi - kao "kutija". Radim sa skladištima 10-ak godina i nikad nisam vidio takvu priču. Uvijek postoje nijanse povezane s jedinstvenim karakteristikama tvrtke - kako poslovnim tako 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 iz tvrtke izvođača, koja je glavni izvođač projekta.

Skladište podataka je integracijski projekt

Skladište podataka učitava i obrađuje informacije iz mnogih izvornih sustava. A da biste s njima održali "prijateljske odnose", prema njima morate biti izuzetno pažljivi. Između ostalog, potrebno je minimizirati opterećenje izvornih sustava, uzeti u obzir prozore „dostupnosti i nedostupnosti“, odabrati interakcijska sučelja uzimajući u obzir njihovu arhitekturu itd. Tada će pohrana imati priliku dohvatiti podatke što je ranije moguće i sa potrebnom učestalošću. Inače ćete biti "prebačeni" na rezervni krug koji se ne ažurira s najučinkovitijom učestalošću.
Osim toga, mora se uzeti u obzir i "ljudski faktor". Integracija nije samo interakcija strojeva. To je i komunikacija među ljudima.

Skladište podataka je timski projekt

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

Arhitektura mora osigurati mogućnost organiziranja njihovog paralelnog rada, au isto vrijeme zadržati svoj integritet i izbjeći dupliciranje iste funkcionalnosti na različitim mjestima, od strane različitih ljudi. Osim nepotrebnih troškova rada, takvo umnožavanje može naknadno dovesti do nepodudarnosti podataka.

Osim toga, kada je toliko ljudi i timova, često različitih, uključeno u proces razvoja sustava, neizbježno se postavlja pitanje kako izgraditi komunikacijsku i informacijsku interakciju među njima. Što se standardniji i razumljiviji pristupi i prakse koriste, takav rad može biti jednostavniji, praktičniji i učinkovitiji. Također je vrijedno razmisliti o sastavu "radnih artefakata", među kojima su br. 1 za skladišta podataka modeli podataka (pogledajte prethodni odjeljak).

Skladište podataka ima dulji vijek trajanja u odnosu na druge sustave

Dopustite mi da pojasnim - izjava je točna za "živo", radno skladište, integrirano s ključnim izvorima, koje posjeduje povijesne podatke i pruža informacije i analitičke usluge mnogim odjelima tvrtke.

Koji razlog imam da vjerujem u to?
Prvo, izgradnja skladišta vrlo je resursno intenzivan proces: osim stvarnih troškova opreme, licenci za potreban tehnološki softver i razvoj, gotovo svi sustavi i odjeli tvrtke također su uključeni u to. Ponavljanje cijelog ovog procesa od nule je vrlo hrabar pothvat.

Drugo, ako pohrana ima odgovarajuću arhitekturu, tada može lako preživjeti promjene u izvornim sustavima, pojavu novih zahtjeva krajnjih korisnika i rast količine podataka.
Ako je arhitektura ispravna i tokovi informacija transparentni, onda se takav sustav može razvijati dosta dugo bez opasnosti da dođete u situaciju stupora pri uvođenju promjena zbog poteškoća u procjeni učinka.

Postupni iterativni razvoj

Posljednje što bi kupac želio kada se uključi u situaciju skladištenja je zamrznuti svoje zahtjeve na godinu ili dvije dok se ne dizajnira potpuni korporativni podatkovni model, svi izvori budu u potpunosti povezani itd.

U očima kupaca, skladište podataka često izgleda kao apsolutno čudovište - toliko su obimni zadaci, ciljevi i razvojni horizont sustava. I često se Kupac boji da će “nauštrb njegovog budžeta” IT odjel riješiti neke “svoje probleme”. I opet se suočavamo s pitanjem interakcije među ljudima i sposobnosti mirnog izražavanja stava i pregovaranja.

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

Iako treba napomenuti da se "čuda ne događaju" - a za "početak" također treba vremena. Za pohrane, to može biti prilično veliko - 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 - “povijest više projekata”

Teško je identificirati jednog poslovnog korisnika za skladište podataka. I vjeruje se (ne bez razloga) da je ključni čimbenik uspjeha projekta izgradnje skladišta podrška uprave tvrtke - izravno prve osobe.
Skladište se rijetko gradi i razvija unutar istog projekta. U pravilu postoje različite potrebe za konsolidacijom podataka i analitikom iza kojih stoje različiti Kupci i korisničke skupine. Stoga se repozitorij često razvija u okviru nekoliko paralelnih projekata.

Ravnoteža inovacija i provjerenih rješenja

Unatoč činjenici da je tema skladištenja vrlo "drevna" (ako je takva riječ primjenjiva za tako mladu industriju kao što je IT) i prilično konzervativna. Međutim, napredak ne stoji - i ograničenja koja su prije postojala zbog skupih i sporih diskova, skupe memorije itd. – sada su uklonjeni. Istovremeno, došlo je vrijeme da se preispitaju neki arhitektonski pristupi. Štoviše, to se odnosi i na tehnološke platforme i na arhitekturu aplikativnih sustava koji se na njima temelje.

Ovdje je važno održavati ravnotežu - i održavati prilično "ekološki" pristup resursima i pohranjenim informacijama. U suprotnom, skladište vrlo brzo možete pretvoriti u slabo strukturirano „odlagalište smeća“, što će se, ako se i može srediti, učiniti uz dosta truda.
Da, imamo više mogućnosti, ali to ne znači da trebamo odbaciti sve uvriježene i provjerene prakse kojima je jasno kako i zašto koristiti, te se „namučiti“ samo vođeni maglovitom sablasti „inovativnosti“. ”
Održavati ravnotežu znači koristiti nove metode i pristupe koji 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? aplikativna rješenja? Prije svega, poznavati i razumjeti tehnološke promjene na platformama na kojima radimo, njihove mogućnosti, značajke i ograničenja primjene.

Pogledajmo DBMS - kao najkritičniju i najvažniju tehnološku platformu za pohranu.
Nedavno je došlo do jasnog pomaka relacijskih baza podataka, izvorno stvorenih kao "univerzalnih", prema specijalizaciji. Dugo vremena vodeći proizvođači izdaju različite opcije za aplikacije različitih klasa (OLTP, DSS & DWH). Osim toga, pojavljuju se dodatne mogućnosti za rad s tekstom, geopodacima itd.

Ali stvar nije bila ograničena na ovo - počeli su se pojavljivati ​​proizvodi koji su u početku bili usmjereni na određenu klasu zadataka - tj. specijalizirani DBMS. Oni mogu ili ne moraju koristiti relacijski model. Bitno je da su oni u početku "skrojeni" ne samo za pohranjivanje i obradu "poslovnih informacija" općenito, već za specifične zadatke.

Čini se da su centralizacija i specijalizacija dva komplementarna trenda koji se povremeno smjenjuju, osiguravajući razvoj i ravnotežu. Kao i evolucijski (postupni) postupni razvoj i dramatične promjene. Tako je 90-ih Michael Stonebraker bio jedan od autora Generation III Database Manifesta, koji je jasno izrazio ideju da svijetu nije potrebna 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 - upravo na temelju njihove specijalizacije.
On se usredotočuje na činjenicu da su uobičajeni univerzalni DBMS-ovi izgrađeni na "bezdimenzionalnoj" (jedna veličina za sve) arhitekturi, koja ne uzima u obzir niti promjene u hardverskim platformama niti podjelu aplikacija u klase za koje je to moguće doći do optimalnijeg rješenja nego implementacijom univerzalnih zahtjeva.
I on počinje razvijati niz projekata u skladu s tom idejom. Jedan od njih je C-Store - stupčasti DBMS dizajniran u arhitekturi dijeljenog ništa (SN), izvorno kreiran posebno za sustave klase skladišta podataka. Ovaj proizvod je dalje komercijalno razvijen 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 razumna primjena omogućuje nam stvaranje uistinu zanimljivih i korisnih rješenja. I dovedite ih u implementaciju, uživajući u činjenici da se vaš razvoj koristi u stvarnom radu i donosi koristi.

Epilog

U pripremi ovog članka pokušao sam se prvenstveno fokusirati na arhitekte, analitičare i programere koji izravno rade sa skladištima podataka. No, pokazalo se da je neizbježno "temu malo proširila" - a u vidokrug su ušle i druge kategorije čitatelja. Neke će se točke činiti kontroverznima, neke nisu jasne, neke su očite. Ljudi su različiti – s različitim iskustvima, pozadinama i pozicijama.
Na primjer, tipična pitanja menadžera su "kada angažirati arhitekte?", "kada se baviti arhitekturom?", "arhitektura - neće li biti preskupa?" Nama (programerima, dizajnerima) zvuče prilično čudno, jer za nas arhitektura sustava nastaje njegovim rođenjem – nije bitno da li to shvaćamo ili ne. Pa čak i ako nema formalne uloge arhitekta u projektu, normalan programer uvijek "uključuje svog unutarnjeg arhitekta".

Uglavnom, nije bitno tko točno obnaša ulogu arhitekta - bitno je da netko postavlja takva pitanja i traži odgovore na njih. Ako je arhitekt jasno identificiran, to samo znači da je on prvenstveno odgovoran za sustav i njegov razvoj.
Zašto sam smatrao da je tema "antilomkosti" relevantna za ovu temu?

“Jedinstvena stvar kod antifragilnosti je ta što nam omogućuje da radimo s nepoznatim, da radimo nešto u uvjetima u kojima ne razumijemo što radimo i da postignemo uspjeh.”/Nassim N. Taleb/

Dakle, kriza i visok stupanj neizvjesnosti nisu izgovor za nedostatak arhitekture, već čimbenici koji pojačavaju njezinu potrebu.

Industrijski podatkovni modeli

Osnovna namjena modela je olakšati snalaženje u podatkovnom prostoru i pomoći u prepoznavanju detalja koji su važni za razvoj poslovanja. U današnjem okruženju, za vođenje uspješnog poslovanja, apsolutno je potrebno imati jasno razumijevanje veza između različitih komponenti i dobro razumijevanje cjelokupne slike organizacije. Identifikacija svih detalja i veza pomoću modela omogućuje najučinkovitije korištenje vremena i alata za organizaciju rada tvrtke.

Podatkovni modeli su apstraktni modeli koji opisuju kako su podaci predstavljeni i kako im se pristupa. Modeli podataka definiraju elemente podataka i odnose između njih u određenom području. Podatkovni model je navigacijski alat za poslovne i IT profesionalce koji koristi određeni skup simbola i riječi za točno objašnjenje određene klase informacija iz stvarnog svijeta. To omogućuje bolje razumijevanje unutar organizacije i tako stvara fleksibilnije i stabilnije okruženje aplikacija.

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

U pravilu postoje modeli više razine (i sadržajno općenitiji) i niži (odnosno detaljniji). Vrhunska razina modeliranja je tzv konceptualni modeli podataka(konceptualni modeli podataka), koji daju najopćenitiju sliku funkcioniranja poduzeća ili organizacije. Konceptualni model uključuje temeljne koncepte ili predmetna područja ključna za funkcioniranje organizacije; obično njihov broj ne prelazi 12-15. Takav model opisuje klase entiteta važnih za organizaciju (poslovne objekte), njihove karakteristike (atribute) i asocijacije između parova tih klasa (tj. odnose). Budući da terminologija u poslovnom modeliranju još nije u potpunosti uspostavljena, u različitim izvorima na engleskom jeziku konceptualni modeli podataka mogu se nazivati ​​i predmetnim modelima (što se može prevesti kao modeli predmetnog područja) ili predmetnim poslovnim modelima podataka (predmetni korporativni modeli podataka). .

Sljedeća hijerarhijska razina je logički modeli 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 je lako razumljiv poslovnim korisnicima. Logički model može sadržavati rječnik podataka - popis svih entiteta s njihovim preciznim definicijama, što omogućuje različitim kategorijama korisnika zajedničko razumijevanje svih ulaznih i izlaznih tokova informacija modela. Dalje, više niska razina modeliranje je već fizička implementacija logičkog modela pomoću specifične programske i tehničke platforme.

Logički model sadrži detaljno poslovno rješenje poduzeća, koje obično ima oblik normaliziranog modela. Normalizacija je proces koji osigurava da svaki element podataka u modelu ima samo jednu vrijednost i potpuno i jedinstveno ovisi o primarnom ključu. Elementi podataka organizirani su u skupine prema njihovoj jedinstvenoj identifikaciji. Poslovna pravila koja upravljaju elementima podataka moraju biti u potpunosti uključena u normalizirani model, pri čemu se prvo provjerava njihova valjanost i ispravnost. Na primjer, podatkovni element kao što je Ime kupca vjerojatno bi se podijelio na ime i prezime i grupirao s drugim odgovarajućim podatkovnim elementima u entitet kupca s primarnim ključem ID-a kupca.

Logički podatkovni model neovisan je o aplikacijskim tehnologijama, kao što su baza podataka, mrežne tehnologije ili alati za izvješćivanje, te načinima njihove fizičke implementacije. Organizacija može imati samo jedan podatkovni model poduzeća. Logički modeli obično uključuju tisuće entiteta, odnosa i atributa. Na primjer, model podataka za financijsku organizaciju ili telekomunikacijsku tvrtku može sadržavati oko 3000 koncepata industrije.

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 predstavlja poslovno rješenje aplikacije. Isti poslovni logički model podataka može se implementirati korištenjem različitih semantičkih modela, tj. Semantički modeli mogu se smatrati sljedećom razinom modeliranja koja se približava fizičkim modelima. Štoviše, svaki od ovih modela predstavljat će zaseban „odsječak“ korporativnog podatkovnog modela u skladu sa zahtjevima različitih aplikacija. Na primjer, u korporativnom logičkom podatkovnom modelu, klijentski entitet će biti potpuno normaliziran, au semantičkom modelu za podatkovnu trgovinu može se predstaviti kao višedimenzionalna struktura.

Tvrtka može imati dva načina za stvaranje korporativnog logičkog podatkovnog modela: izgraditi ga samostalno ili koristiti već gotov industrijski model(industrijski logički model podataka). U ovom slučaju, razlike u terminima odražavaju samo različite pristupe konstruiranju istog logičkog modela. Ako tvrtka samostalno razvija i implementira vlastiti logički model podataka, onda se takav model, u pravilu, jednostavno naziva korporativni logički model. Ako organizacija odluči koristiti gotov proizvod od profesionalnog dobavljača, tada možemo govoriti o logičkom podatkovnom modelu specifičnom za industriju. Potonji je gotov logički model podataka koji točno odražava funkcioniranje određene industrije. Industrijski logički model je integrirani pogled specifičan za domenu svih informacija 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 drugi logički podatkovni model, industrijski model je neovisan o aplikacijskim rješenjima. Također ne uključuje izvedenice ili druge izračune za brže dohvaćanje podataka. U pravilu, većina logičkih struktura takvog modela dobro se prevodi u njegovu učinkovitu fizičku implementaciju. Takve modele razvijaju mnogi dobavljači za širok raspon područja: financijske usluge, proizvodnja, turizam, zdravstvo, osiguranje itd.

Industrijski logički podatkovni model sadrži informacije koje su zajedničke industriji i stoga ne mogu biti potpuno rješenje za tvrtku. Većina tvrtki mora povećati svoj model za prosječno 25% dodavanjem podatkovnih elemenata i proširivanjem definicija. Unaprijed izgrađeni modeli sadrže samo ključne podatkovne elemente, a ostale elemente potrebno je dodati odgovarajućim poslovnim objektima tijekom procesa instaliranja modela u tvrtku.

Industrijski logički modeli podataka sadrže značajan broj apstrakcija. Apstrakcije se odnose na grupiranje sličnih koncepata pod zajedničkim nazivima kao što su događaj ili sudionik. Ovo dodaje fleksibilnost industrijskim modelima i čini ih ujednačenijim. Stoga je koncept događaja primjenjiv na sve industrije.

Stručnjak za poslovnu inteligenciju Steve Hoberman identificira pet čimbenika koje treba uzeti u obzir kada odlučujete hoćete li kupiti industrijski podatkovni model. Prvi su vrijeme i novac potrebni za izradu modela. Ako organizacija treba brzo postići rezultate, tada će model industrije pružiti prednost. Korištenje industrijskog modela možda neće odmah pružiti pregled cijele organizacije, ali može uštedjeti značajnu količinu vremena. Umjesto stvarnog modeliranja, vrijeme će se potrošiti na povezivanje postojećih struktura s industrijskim modelom i na raspravu o tome kako ga najbolje prilagoditi potrebama organizacije (na primjer, koje definicije treba promijeniti i koje elemente podataka treba dodati).

Drugi faktor je vrijeme i novac potreban za održavanje modela u radnom stanju. Ako model podataka poduzeća nije dio metodologije koja osigurava njegovu točnost i usklađenost modernim standardima, onda takav model vrlo brzo zastarijeva. Industrijski podatkovni model može spriječiti rizik da se to dogodi jer ga ažuriraju vanjski resursi. Naravno, promjene koje se događaju unutar organizacije moraju se odraziti u modelu same tvrtke, ali će promjene u industriji reproducirati u modelu njezin dobavljač.

Treći faktor je iskustvo u procjeni i modeliranju rizika. Stvaranje podatkovnog modela poduzeća zahtijeva kvalificirane resurse i poslovnog i IT osoblja. Menadžeri u pravilu dobro poznaju rad organizacije u cjelini ili aktivnosti pojedinog odjela. Samo nekolicina njih ima široko (u cijeloj tvrtki) i duboko (unutar odjela) znanje o svom poslovanju. Većina menadžera ima tendenciju da dobro poznaje samo jedno područje. Stoga dobivanje pogleda na cijelo poduzeće zahtijeva značajne poslovne resurse. To također povećava zahtjeve za IT osoblje. Što je više poslovnih resursa potrebno za izradu i testiranje modela, analitičari moraju biti iskusniji. Oni ne samo da moraju znati kako dobiti informacije od poslovnog osoblja, već moraju biti u stanju pronaći zajednički jezik u kontroverznim područjima i biti u stanju predstaviti sve te informacije na integrirani način. Osoba koja stvara model (u mnogim slučajevima isti analitičar) mora imati dobre vještine modeliranja. Stvaranje logičkih modela poduzeća zahtijeva modeliranje "za budućnost" i sposobnost prevođenja složenog poslovanja u doslovno "kvadrate i linije".

S druge strane, industrijski model omogućuje korištenje iskustva stručnjaka trećih strana. Logički modeli specifični za industriju koriste dokazane metodologije modeliranja i timove iskusnih stručnjaka kako bi izbjegli uobičajene i skupe probleme koji mogu nastati prilikom razvoja poslovnih modela podataka unutar organizacije.

Četvrti faktor je postojeća aplikativna infrastruktura i odnosi s dobavljačima. Ako organizacija već koristi mnogo alata od istog dobavljača i ima uspostavljene odnose s njim, onda ima smisla naručiti industrijski model od istog dobavljača. Takav će model moći slobodno raditi s drugim proizvodima istog dobavljača.

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

Najučinkovitiji industrijski modeli su oni koje nude profesionalni dobavljači. Visoka učinkovitost njihove upotrebe 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 i dobro upućeni u izradu modela specifičnih za industriju.

Industrijski podatkovni modeli tvrtkama pružaju jedinstveni, integrirani pogled na njihove poslovne informacije. Mnogim tvrtkama je teško integrirati svoje podatke, iako je to preduvjet za većinu projekata na razini poduzeća. Prema studiji The Data Warehousing Institute (TDWI), više od 69% anketiranih organizacija otkrilo je da je integracija značajna prepreka za usvajanje novih aplikacija. Naprotiv, integracija podataka tvrtki donosi značajan prihod.

Industrijski podatkovni model, uz svoje veze 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čke slike poslovanja. Korištenje logičkih modela čini se nužnim korakom prema stvaranju skladišta podataka poduzeća.

Publikacije

1. Steve Hoberman. Iskorištavanje industrijskog logičkog podatkovnog modela kao vašeg poslovnog podatkovnog modela.
2. Claudia Imhoff. Brza izrada skladišta podataka i izvođenje projekata poslovne inteligencije pomoću modeliranja podataka (Fast-Tracking Data Warehousing & Business Intelligence Projects via Intelligent Data Modeling)

Č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 razumna primjena omogućuje nam stvaranje uistinu zanimljivih i korisnih rješenja. I dovedite ih u implementaciju, uživajući u činjenici da se vaš razvoj koristi u stvarnom radu i donosi koristi.

Epilog

U pripremi ovog članka pokušao sam se prvenstveno fokusirati na arhitekte, analitičare i programere koji izravno rade sa skladištima podataka. No, pokazalo se da je neizbježno "temu malo proširila" - a u vidokrug su ušle i druge kategorije čitatelja. Neke će se točke činiti kontroverznima, neke nisu jasne, neke su očite. Ljudi su različiti – s različitim iskustvima, pozadinama i pozicijama.
Na primjer, tipična pitanja menadžera su "kada angažirati arhitekte?", "kada se baviti arhitekturom?", "arhitektura - neće li biti preskupa?" Nama (programerima, dizajnerima) zvuče prilično čudno, jer za nas arhitektura sustava nastaje njegovim rođenjem – nije bitno da li to shvaćamo ili ne. Pa čak i ako nema formalne uloge arhitekta u projektu, normalan programer uvijek "uključuje svog unutarnjeg arhitekta".

Uglavnom, nije bitno tko točno obnaša ulogu arhitekta - bitno je da netko postavlja takva pitanja i traži odgovore na njih. Ako je arhitekt jasno identificiran, to samo znači da je on prvenstveno odgovoran za sustav i njegov razvoj.
Zašto sam smatrao da je tema "antilomkosti" relevantna za ovu temu?

“Jedinstvena stvar kod antifragilnosti je ta što nam omogućuje da radimo s nepoznatim, da radimo nešto u uvjetima u kojima ne razumijemo što radimo i da postignemo uspjeh.”/Nassim N. Taleb/

Dakle, kriza i visok stupanj neizvjesnosti nisu izgovor za nedostatak arhitekture, već čimbenici koji pojačavaju njezinu potrebu.

Oznake: Dodajte oznake

5.1. Organizacija podataka u korporativnim informacijskim sustavima.

Promatrajući CIS na najjednostavnijoj razini, možemo reći da sadrži korporativnu računalnu (računalnu) mrežu i specijalizirani aplikacijski programski paket (APP) za rješavanje problema iz predmetnog područja. S druge strane, i JPP i računalna mreža temeljno uključuju korištenje informacijskih podataka o stanju i razvoju sustava koje kontroliraju i upravljaju. Povijesno gledano, CIS se sastoji od zasebnih razgranatih podsustava pojedinačnih poduzeća, međusobno povezanih i često predstavljaju hijerarhijski sustav. Prirodno je pretpostaviti da takvi podsustavi imaju i vlastite izvore i vlastite lokacije za pohranu povezanih podataka. Spajanjem u jedinstveni sustav postavljaju se pitanja zajedničkog pravilnog korištenja podataka lociranih geografski na različitim lokacijama pohrane. Stoga je za uspješno upravljanje proizvodnim udruženjem opremljenim CIS-om potreban pouzdan sustav za prikupljanje, pohranu i obradu podataka. Drugim riječima, potrebna je jedinstvena informacijska infrastruktura koja zadovoljava strateške BI (Business Intelligence) projekte ili integrirana baza za pohranu i korištenje podataka. Glavni cilj integracije podataka je dobiti jedinstvenu i cjelovitu sliku stanja korporativnih poslovnih podataka. Sama integracija je složen proces, na temelju kojeg je preporučljivo istaknuti:

Tehnologije,

proizvodi,

Prijave.

Metode su pristupi integraciji podataka.

Tehnologije– to su procesi koji implementiraju određene metode integracije podataka.

Proizvodi– to su komercijalna rješenja koja podržavaju jednu ili drugu tehnologiju integracije podataka.

Prijave– to su gotova tehnička rješenja koja isporučuju programeri u skladu sa željama naručitelja – kupaca.

Ovisno o složenosti korporativnih informacijskih sustava i zadacima koje rješavaju, organizacija podataka u njima donekle varira. Konkretno, u CIS-u, dizajniranom da osigura učinkovito upravljanje poslovnim procesima kako pojedinačnih podružnica tako i korporacije u cjelini, uobičajeno je govoriti o prisutnosti korporativnih baza podataka. U korporativnim informacijskim sustavima koji se koriste na najvišim razinama upravljanja i većinom su povezani s procesima operativne analize i donošenja odluka, terminologija skladište podataka koristi se u procesu planiranja, projektiranja i predviđanja raznih vrsta upravljačkih aktivnosti. Prikladno je primijetiti da fraza integrirana pohrana podataka svojstveno i jednom i drugom.

5.2. Korporativne baze podataka i zahtjevi za njih

Budući da je integrirana pohrana podataka na cijelom sustavu, korporativna baza podataka dizajnirana je za pružanje informacija za učinkovito upravljanje svim poslovnim procesima i odjelima korporacije. Integracija podataka podrazumijeva stvaranje nove strukture koja organski uključuje podatke iz baza podataka pojedinih zasebnih odjela, stoga takva struktura mora ispunjavati određene zahtjeve:

· Jednostavan i user-friendly unos podataka u bazu podataka,

· Pohranjivanje podataka u obliku koji neće dovesti do pretjeranog rasta podataka,

· Dostupnost za opće informacije zaposlenici svih odjela korporacije, uz obavezni uvjet diferencijacije prava pristupa,

· Brzo pronađite i dohvatite potrebne informacije,

· Sortiranje i filtriranje potrebnih podataka,

· Grupiranje istoimenih podataka,

· Međuproračuni i završni obračuni po poljima,

· Transformacija i jasnoća izlaznih podataka,

· Skalabilnost,

· Zaštita od slučajnih kvarova, nepovratnog gubitka podataka i neovlaštenog pristupa.

Osim toga, pri integraciji zasebnih (distribuiranih) baza podataka u jedinstvenu korporativnu bazu podataka, važno je osigurati mogućnost rada s bazom podataka na način da korisnik s njom radi kao s nedistribuiranom.

Stvaranje integrirane korporativne baze podataka moguće je korištenjem različitih metoda, a glavne su:

· Konsolidacija,

· Federalizacija,

· Širenje.

5.3. Karakteristike integracijskih rješenja za korporativne baze podataka

Konsolidacija. Pod, ispod konsolidacija obično se odnosi na dodavanje podataka istog imena. Sličan izraz je u širokoj uporabi u bankarskoj industriji, gdje se formira godišnja konsolidirana bilanca, koja omogućuje prikaz cjelokupne imovine i obveza matične banke zajedno s njezinim podružnicama.

U odnosu na korporaciju, pri korištenju ove metode, podaci se kopiraju i prikupljaju iz primarnih baza podataka (DB - Slave) integracijom u jedinstveno mjesto pohrane (DB - Master). U pravilu se kao takvo mjesto za pohranu bira poslužitelj središnjeg (glavnog) ureda (slika 5.1).

sl.5.1. Metoda konsolidacije podataka

Podaci u Master bazi podataka služe za izvještavanje, analizu, razvoj i donošenje odluka, a također i kao izvor podataka za druge podružnice društva.

Najčešće tehnologije za podršku takvim rješenjima tijekom konsolidacije su sljedeće tehnologije:

· Ekstrakt, transformacija i učitavanje - ETL (Extract Transform Load);

· Korporacijsko upravljanje sadržajem - ECM (Enterprise Content Management).

Prednosti metode konsolidacije su:

1. Sposobnost transformacije(restrukturiranje, usklađivanje, čišćenje i/ili agregacija) značajnih količina podataka u procesu njihovog prijenosa od primarnih sustava do konačnih lokacija pohrane putem ETL tehnologije,

2. Sposobnost upravljanja nestrukturiranim podacima, kao što su dokumenti, izvješća i stranice zahvaljujući ECM tehnološkim rješenjima.

Za rad s konsolidiranom CIS bazom podataka, poseban poslovne aplikacije, koji vam omogućuju kreiranje upita za podatke baze podataka, izvješća i na temelju njih analizu podataka.

Nedostatak integracije putem konsolidacije je taj što se konsolidirani podaci na integriranoj lokaciji za pohranu ne mogu ažurirati sinkrono s ažuriranjima podataka u primarnim sustavima zbog sukoba sinkronizacije.

Između trenutka ažuriranja podataka u primarnim sustavima i na konačnoj lokaciji pohrane postoji vremenski odmak.

Ovo kašnjenje može biti u rasponu od nekoliko sekundi do nekoliko sati ili čak dana.

Federalizacija. Pod, ispod federalizacija obično se odnosi na sindikat. Sličan izraz često se koristi u politici pri uređivanju granica neke države (primjerice Njemačka, Ruska Federacija, SAD).

Proces federalizacije podataka u korporativnoj bazi podataka je stvaranje virtualne (prividne) slike koja kombinira nekoliko primarnih podatkovnih datoteka u jednu virtualnu cjelinu (vidi sl. 5.2). Zapravo, federalizacija podataka sastoji se od izdvajanja podataka iz primarnih sustava na temelju vanjskih zahtjeva. Upravljanje korporativnom bazom podataka integriranom prema federalnoj metodi provodi federalizacijski procesor.

sl.2. Metoda federalizacije podataka

Prilikom pristupa podacima iz virtualne baze podataka svaka poslovna aplikacija generira zahtjev prema virtualnoj slici. Na temelju tog zahtjeva federalni procesor dohvaća podatke iz odgovarajućih primarnih sustava, integrira ih u skladu s virtualnom slikom i daje rezultat poslovnoj aplikaciji koja je generirala zahtjev. U ovom slučaju, sve potrebne transformacije podataka se provode kada su ekstrahirani iz primarnih sustava.

Podršku za federalni pristup integraciji podataka pruža tehnologija Enterprise Information Integration (E I I), što znači Integracija korporativnih informacija.

Posebna značajka federalnog rješenja je da federalizacijski procesor koristi metapodaci(znanje), koji sadrži podatke o sastavu i karakteristikama virtualne slike, količini podataka, semantičkim vezama među njima i načinima pristupa, što pomaže federalnom rješenju da optimizira pristup primarnim sustavima.

Glavne prednosti federalnog pristupa su:

· mogućnost pristupa trenutnim podacima bez stvaranja dodatne nove baze podataka,

izvedivost primjene nakon akvizicije ili spajanja društava,

· neophodnost u slučajevima kada iz sigurnosnih razloga postoje licencna ograničenja za kopiranje podataka iz primarnih sustava,

· koristiti, ako je potrebno, visoku autonomiju lokalnih odjela korporacije i fleksibilnost centralizirane kontrole njihovih aktivnosti,

· visok stupanj korisnosti za velike transnacionalne korporacije.

Nedostaci pristupa uključuju:

· Smanjena produktivnost zbog dodatnih troškova pristupa više izvora podataka,

federalizacija je najprikladnija za izvlačenje malih skupovi podataka,

· visoki zahtjevi za kvalitetom primarnih podataka.

Širenje. Pod, ispod širenje obično se odnosi na teritorijalni prijenos umnoženih objekata. Distribucija podataka odnosi se na umnožavanje primarnih baza podataka i njihovo premještanje s jednog mjesta na drugo. Prilikom provedbe ovu metodu poslovne aplikacije rade online i premještaju podatke na odredišta ovisno o određenim događajima. Za ovo tehničko rješenje postaje važno pitanje ažuriranja podataka koje je moguće u sinkronom ili asinkronom načinu rada. Sinkroni način rada pretpostavlja da se ažuriranja i u primarnom sustavu i u ciljnom sustavu događaju tijekom iste fizičke transakcije.

Primjeri tehnologija koje podržavaju implementaciju metode diseminacije podataka su:

· Integracija poslovnih aplikacija EAI - Enterprise Application Integration,

· Replikacija korporativnih podataka EDR – Enterprise Data Replication.

Generalizirana struktura implementacije metode diseminacije podataka izgleda kao na slici 5.3.

sl.5.3. Metoda diseminacije podataka

Posebnost metode distribucije podataka je zajamčena isporuka podataka do odredišnog sustava s minimalnom latencijom, blizu stvarnog vremena.

Kombinacija tehnologije integracije (EAI) i replikacije (EDR) u metodi daje višestruke prednosti, u vidu sljedećih prednosti:

· Visoke performanse,

· Mogućnost restrukturiranja i čišćenja podataka,

· Balansiranje opterećenja stvaranjem sigurnosnih kopija i vraćanjem podataka.

Hibridni pristup. Realnost ekonomske aktivnosti je takva da ne postoje dva identična poduzeća, a još manje dvije identične korporacije. Ova okolnost ostavlja traga na procesu stvaranja i popunjavanja ZND-a. To se u potpunosti odnosi i na metode integracije podataka u baze podataka. Iz tog razloga mnogi CIS koriste tzv hibrid pristup koji istovremeno uključuje nekoliko integracijskih metoda. Primjeri ovog pristupa su tehnologije koje pružaju dosljednu sliku informacija o kupcima:

· Integracija podataka o kupcima u CDI sustave - Customer Data Integration,

· Integracija podataka o kupcima u module CRM – Customer Relations Management.

Konkretno, implementaciji CDI-a može se pristupiti na različite načine.

Najjednostavniji način je kreirati konsolidiranu bazu podataka korisnika koja sadrži podatke iz primarnih sustava. U ovom slučaju, kašnjenje informacija može se regulirati korištenjem različitih načina konsolidacije: operativnog ili paketnog, ovisno o učestalosti ažuriranja ovih informacija.

Druga metoda je federalizacija podataka, kada su virtualni poslovne prezentacije podaci o kupcima sadržani u primarnim sustavima. Datoteka metapodataka može sadržavati uobičajene ključne elemente koji se mogu koristiti za povezivanje informacija o kupcima.

Dakle, opći (na primjer, detalji) podaci o kupcima mogu se konsolidirati kao najstatičniji podaci. I dinamičniji podaci (na primjer, informacije o narudžbama) mogu se federalizirati.

Štoviše, hibridni pristup može se proširiti uporabom metode diseminacije podataka. Na primjer, klijent koji koristi usluge online trgovine mijenja svoje podatke tijekom usluge. Te se promjene mogu poslati u konsolidirani dio baze podataka, a odatle distribuirati u sve primarne sustave koji sadrže podatke o kupcima trgovine.

Imajući u vidu prednosti i nedostatke pojedine metode, preporučljivo je kreativno pristupiti njihovoj primjeni i zajedničkom korištenju.

Na primjer, preporučljivo je koristiti federalizaciju podataka u slučajevima kada troškovi konsolidacije podataka premašuju poslovne koristi koje konsolidacija pruža. Konkretno, ažurna obrada zahtjeva i izrada izvješća je upravo takva situacija.

Praktična primjena metode distribucije podataka vrlo je raznolika, kako u smislu izvedbe tako i u smislu mogućnosti restrukturiranja i čišćenja podataka.

5.4. Koncept i strukturna rješenja skladišta podataka

Pohrana podataka - to je predmetno orijentirani integrirani uređaj za pohranu informacija koji akumulira vanjske i operativne podatke, kao i podatke iz drugih sustava, na temelju kojih se grade procesi donošenja odluka i analize podataka.

Za razliku od baza podataka i banaka podataka, temelj skladišta podataka nisu unutarnji, već vanjski izvori podataka: razni Informacijski sustavi, elektroničke arhive, javno dostupni elektronički katalozi, priručnici i zbirke.

Koncept skladišta podataka temelji se na dvije glavne ideje:

1. Integracija odvojenih detaljnih podataka (koji opisuju specifične činjenice, svojstva, događaje itd.) u jednom repozitoriju.

2. Odvajanje skupova podataka i aplikacija koje se koriste za obradu i analizu.

Skladište podataka organizira se u slučajevima kada je potrebno pribaviti:

· Integracija aktualnog i povijesnog vrijednosti podataka,

· Kombiniranje podataka iz različitih izvora,

· Stvaranje pouzdane podatkovne platforme za analitičke svrhe,

· Osiguravanje homogenosti podataka u organizaciji,

· Olakšati implementaciju standarda korporativnih podataka bez mijenjanja postojećih operativnih sustava,

· Pružanje široke povijesne perspektive i mogućnosti za analizu razvojnih trendova.

Povijesno su se skladišta podataka gradila prema jednoj, dvije i tri razine.

Sheme s jednom razinom izvorno su bili namijenjeni najjednostavnijim arhitekturama koje uključuju funkcionalni DSS, s nedovoljno razvijenom informacijskom infrastrukturom, kada se analiza provodi pomoću podataka iz operativnih sustava, po principu: podaci - oblici prezentacije.

Prednosti takvih shema su:

· Brzi prijenos podataka iz operativnih sustava u specijalizirani sustav bez posredničkih veza,

· Minimalni troškovi korištenjem jedne platforme.

Mane:

· Uzak raspon problema koje treba riješiti zahvaljujući jednom izvoru podataka,

· Niska kvaliteta podataka zbog nedostatka koraka čišćenja.

Dvorazinske sheme osigurati lanac: podaci – marci podataka – prezentacijski oblici. Koriste se u korporacijama s velikim brojem neovisnih odjela koji koriste vlastite informacijske tehnologije.

Prednosti:

· Vitrine koje se koriste dizajnirane su da odgovore na određeni broj pitanja,

· Moguće je optimizirati podatke u izlozima, što poboljšava produktivnost.

Mane:

· Poteškoće u osiguravanju dosljednosti podataka zbog njihovog opetovanog ponavljanja u izlozima,

· Potencijalna složenost popunjavanja izloga s velikim brojem izvora podataka,

· Zbog nedostatka konsolidacije podataka na razini poduzeća, ne postoji jedinstvena slika poslovanja.

Evolucija razvoja dovela je do činjenice da se izgradnja punopravnog skladišta podataka za moderne korporativne sustave počela provoditi korištenjem troslojna arhitektura (vidi sliku 5.4).

Na prvi razini postoje razni sustavi snimanja koji su izvori podataka. Takvi sustavi mogu biti sustavi za planiranje resursa poduzeća (ERP - Enterprise Resource Planning), referentni (operativni) sustavi, vanjski izvori ili sustavi koji dostavljaju podatke od informacijskih agencija i sl.

Na drugi razina sadrži centralno skladište, koje prikuplja podatke iz svih izvora prve razine, kao i operativno skladište podataka, koje je dizajnirano za obavljanje dvije funkcije:

· Skladište je izvor analitičkih informacija koje se koriste za operativno upravljanje,

· U operativnom skladištu se pripremaju podaci za naknadni utovar u centralno skladište. Priprema podataka podrazumijeva provođenje provjera i transformaciju podataka u vezi s različitim propisima za primanje podataka s prve razine.

Treći razina je zbirka predmetno orijentiranih baza podataka.

Trgovine podacima – To su relativno mali, funkcionalno orijentirani pogoni, čiji sadržaji pomažu u rješavanju analitičkih problema pojedinih odjela korporacije. Podatkovne tržnice su u biti podskupovi podataka iz skladišta. Ujedno, krajnji korisnici imaju mogućnost pristupa detaljnim podacima iz skladišta u slučaju da u izlogu nema dovoljno podataka, kao i dobivanja cjelovitije slike stanja poslovanja.

sl.5.4. Arhitektura skladišta podataka

Glavne tehnološke operacije ovako organiziranih skladišta podataka su:

· Izvlačenje podaci su proces prijenosa podataka iz heterogenih izvora u operativno skladište,

· Pretvorba podatak je izmjena podataka na temelju posebnih pravila uz njihov naknadni prijenos u središnju pohranu,

· Čišćenje podaci su eliminacija dupliciranja podataka koji dolaze iz različitih izvora,

· Ažuriraj data je širenje ažuriranja podataka na izvorne podatke osnovnih tablica i izvedenih podataka koji se nalaze u skladištu.

Prednosti:

· Popunjavanje izloga je pojednostavljeno korištenjem jednog izvora obrisanih podataka,

· Podatkovne trgovine sinkronizirane su s korporativnom poslovnom slikom, što olakšava proširenje središnje pohrane i dodavanje podatkovnih trgovina,

· Zajamčena izvedba.

Mane:

· Prisutnost redundantnosti podataka, što dovodi do povećanih zahtjeva za tehnologijom pohrane podataka,

5. 5. Sustavi za upravljanje bazama podataka i tehnologije pristupa podacima u CIS-u

Sustav za upravljanje bazom podataka(DBMS) je kompleks jezika i softver, namijenjen stvaranju, održavanju i dijeljenju baze podataka od strane jednog ili više korisnika.

Trenutno su najrašireniji DBMS-ovi izgrađeni na temelju relacijskog modela podataka, opisanog strogim matematičkim aparatom. teorije odnosa.

Značajka DBMS-ova koji rade u CIS-u je činjenica da moraju upravljati bazama podataka smještenim na mediju raspoređenom u prostoru.

U interesu eliminacije dodatnog dupliciranja ili kopiranja podataka u CIS-u, glavni naglasak je na principu daljinske obrade podataka. Baze podataka u CIS-u sadrže podatke koji su potrebni mnogim korisnicima. Dobivanje istovremenog pristupa više korisnika bazi podataka moguće je kada se instalira DBMS na lokalnoj računalnoj mreži koja radi s korisnicima i s jednom bazom podataka.

Glavna tehnološka rješenja za višekorisnički rad s bazama podataka su tehnologije datoteka/poslužitelj i klijent/poslužitelj. Uzimajući najprikladniju opciju iz ovih tehnologija, klijent/poslužitelj u CIS-u organizira specijalizirane sustave za obradu distribuiranih baza podataka. U isto vrijeme, distribuiranim bazama podataka upravlja se na način da se podaci distribuiraju ne na logičkoj, već na fizičkoj razini, a sama baza podataka se smatra jednom "supershemom". U distribuiranoj bazi podataka, administrativne funkcije su raspoređene između administratora integrirane baze podataka i lokalnih administratora baze podataka. Administrator integrirane baze podataka nadzire razgraničenje pristupa različitih korisnika bazi podataka te osigurava cjelovitost i sigurnost podataka, kao i zaštitu podataka od istovremenih ispravaka od strane više korisnika. Kontrola pristupa provodi se sukladno pravima dodijeljenim pojedinim korisnicima u mrežnom operativnom sustavu.

Karakteristična značajka programa kreiranih pomoću DBMS-a za rad s udaljenim i distribuiranim korporativnim bazama podataka je korištenje otvorenog sučelja za pristup podacima - ODBC (Open Data Base Connectivity). Sve funkcije prijenosa podataka dodijeljene su ODBC sučelju, koje je spojni most između integrirane baze podataka DBMS i klijentske aplikacije DBMS. U isto vrijeme, klijentov DBMS može komunicirati ne samo s njihovim lokalnim bazama podataka, već i s podacima koji se nalaze u integriranoj bazi podataka. Klijent ima mogućnost slanja upita integriranoj bazi podataka DBMS, primanja podataka od njih i slanja vlastitih ažuriranih podataka.

Industrijski podatkovni modeli

Osnovna namjena modela je olakšati snalaženje u podatkovnom prostoru i pomoći u prepoznavanju detalja koji su važni za razvoj poslovanja. U današnjem okruženju, za vođenje uspješnog poslovanja, apsolutno je potrebno imati jasno razumijevanje veza između različitih komponenti i dobro razumijevanje cjelokupne slike organizacije. Identifikacija svih detalja i veza pomoću modela omogućuje najučinkovitije korištenje vremena i alata za organizaciju rada tvrtke.

Podatkovni modeli su apstraktni modeli koji opisuju kako su podaci predstavljeni i kako im se pristupa. Modeli podataka definiraju elemente podataka i odnose između njih u određenom području. Podatkovni model je navigacijski alat za poslovne i IT profesionalce koji koristi određeni skup simbola i riječi za točno objašnjenje određene klase informacija iz stvarnog svijeta. To omogućuje bolje razumijevanje unutar organizacije i tako stvara fleksibilnije i stabilnije okruženje aplikacija.

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

U pravilu postoje modeli više razine (i sadržajno općenitiji) i niži (odnosno detaljniji). Vrhunska razina modeliranja je tzv konceptualni modeli podataka(konceptualni modeli podataka), koji daju najopćenitiju sliku funkcioniranja poduzeća ili organizacije. Konceptualni model uključuje temeljne koncepte ili predmetna područja ključna za funkcioniranje organizacije; obično njihov broj ne prelazi 12-15. Takav model opisuje klase entiteta važnih za organizaciju (poslovne objekte), njihove karakteristike (atribute) i asocijacije između parova tih klasa (tj. odnose). Budući da terminologija u poslovnom modeliranju još nije u potpunosti uspostavljena, u različitim izvorima na engleskom jeziku konceptualni modeli podataka mogu se nazivati ​​i predmetnim modelima (što se može prevesti kao modeli predmetnog područja) ili predmetnim poslovnim modelima podataka (predmetni korporativni modeli podataka). .

Sljedeća hijerarhijska razina je logički modeli 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 je lako razumljiv poslovnim korisnicima. Logički model može sadržavati rječnik podataka - popis svih entiteta s njihovim preciznim definicijama, što omogućuje različitim kategorijama korisnika zajedničko razumijevanje svih ulaznih i izlaznih tokova informacija modela. Sljedeća, niža razina modeliranja je fizička implementacija logičkog modela pomoću specifičnih programskih i tehničkih platformi.

Logički model sadrži detaljno poslovno rješenje poduzeća, koje obično ima oblik normaliziranog modela. Normalizacija je proces koji osigurava da svaki element podataka u modelu ima samo jednu vrijednost i potpuno i jedinstveno ovisi o primarnom ključu. Elementi podataka organizirani su u skupine prema njihovoj jedinstvenoj identifikaciji. Poslovna pravila koja upravljaju elementima podataka moraju biti u potpunosti uključena u normalizirani model, pri čemu se prvo provjerava njihova valjanost i ispravnost. Na primjer, podatkovni element kao što je Ime kupca vjerojatno bi se podijelio na ime i prezime i grupirao s drugim odgovarajućim podatkovnim elementima u entitet kupca s primarnim ključem ID-a kupca.

Logički podatkovni model neovisan je o aplikacijskim tehnologijama, kao što su baza podataka, mrežne tehnologije ili alati za izvješćivanje, te načinima njihove fizičke implementacije. Organizacija može imati samo jedan podatkovni model poduzeća. Logički modeli obično uključuju tisuće entiteta, odnosa i atributa. Na primjer, model podataka za financijsku organizaciju ili telekomunikacijsku tvrtku može sadržavati oko 3000 koncepata industrije.

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 predstavlja poslovno rješenje aplikacije. Isti poslovni logički model podataka može se implementirati korištenjem različitih semantičkih modela, tj. Semantički modeli mogu se smatrati sljedećom razinom modeliranja koja se približava fizičkim modelima. Štoviše, svaki od ovih modela predstavljat će zaseban „odsječak“ korporativnog podatkovnog modela u skladu sa zahtjevima različitih aplikacija. Na primjer, u korporativnom logičkom podatkovnom modelu, klijentski entitet će biti potpuno normaliziran, au semantičkom modelu za podatkovnu trgovinu može se predstaviti kao višedimenzionalna struktura.

Tvrtka može imati dva načina za stvaranje korporativnog logičkog podatkovnog modela: izgraditi ga samostalno ili koristiti već gotov industrijski model(industrijski logički model podataka). U ovom slučaju, razlike u terminima odražavaju samo različite pristupe konstruiranju istog logičkog modela. Ako tvrtka samostalno razvija i implementira vlastiti logički model podataka, onda se takav model, u pravilu, jednostavno naziva korporativni logički model. Ako organizacija odluči koristiti gotov proizvod od profesionalnog dobavljača, tada možemo govoriti o logičkom podatkovnom modelu specifičnom za industriju. Potonji je gotov logički model podataka koji točno odražava funkcioniranje određene industrije. Industrijski logički model je integrirani pogled specifičan za domenu svih informacija 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 drugi logički podatkovni model, industrijski model je neovisan o aplikacijskim rješenjima. Također ne uključuje izvedenice ili druge izračune za brže dohvaćanje podataka. U pravilu, većina logičkih struktura takvog modela dobro se prevodi u njegovu učinkovitu fizičku implementaciju. Takve modele razvijaju mnogi dobavljači za širok raspon područja: financijske usluge, proizvodnja, turizam, zdravstvo, osiguranje itd.

Industrijski logički podatkovni model sadrži informacije koje su zajedničke industriji i stoga ne mogu biti potpuno rješenje za tvrtku. Većina tvrtki mora povećati svoj model za prosječno 25% dodavanjem podatkovnih elemenata i proširivanjem definicija. Unaprijed izgrađeni modeli sadrže samo ključne podatkovne elemente, a ostale elemente potrebno je dodati odgovarajućim poslovnim objektima tijekom procesa instaliranja modela u tvrtku.

Industrijski logički modeli podataka sadrže značajan broj apstrakcija. Apstrakcije se odnose na grupiranje sličnih koncepata pod zajedničkim nazivima kao što su događaj ili sudionik. Ovo dodaje fleksibilnost industrijskim modelima i čini ih ujednačenijim. Stoga je koncept događaja primjenjiv na sve industrije.

Stručnjak za poslovnu inteligenciju Steve Hoberman identificira pet čimbenika koje treba uzeti u obzir kada odlučujete hoćete li kupiti industrijski podatkovni model. Prvi su vrijeme i novac potrebni za izradu modela. Ako organizacija treba brzo postići rezultate, tada će model industrije pružiti prednost. Korištenje industrijskog modela možda neće odmah pružiti pregled cijele organizacije, ali može uštedjeti značajnu količinu vremena. Umjesto stvarnog modeliranja, vrijeme će se potrošiti na povezivanje postojećih struktura s industrijskim modelom i na raspravu o tome kako ga najbolje prilagoditi potrebama organizacije (na primjer, koje definicije treba promijeniti i koje elemente podataka treba dodati).

Drugi faktor je vrijeme i novac potreban za održavanje modela u radnom stanju. Ako model podataka poduzeća nije dio metodologije koja osigurava da je točan i ažuran, model će brzo zastarjeti. Industrijski podatkovni model može spriječiti rizik da se to dogodi jer ga ažuriraju vanjski resursi. Naravno, promjene koje se događaju unutar organizacije moraju se odraziti u modelu same tvrtke, ali će promjene u industriji reproducirati u modelu njezin dobavljač.

Treći faktor je iskustvo u procjeni i modeliranju rizika. Stvaranje podatkovnog modela poduzeća zahtijeva kvalificirane resurse i poslovnog i IT osoblja. Menadžeri u pravilu dobro poznaju rad organizacije u cjelini ili aktivnosti pojedinog odjela. Samo nekolicina njih ima široko (u cijeloj tvrtki) i duboko (unutar odjela) znanje o svom poslovanju. Većina menadžera ima tendenciju da dobro poznaje samo jedno područje. Stoga dobivanje pogleda na cijelo poduzeće zahtijeva značajne poslovne resurse. To također povećava zahtjeve za IT osoblje. Što je više poslovnih resursa potrebno za izradu i testiranje modela, analitičari moraju biti iskusniji. Oni ne samo da moraju znati kako dobiti informacije od poslovnog osoblja, već moraju biti u stanju pronaći zajednički jezik u kontroverznim područjima i biti u stanju predstaviti sve te informacije na integrirani način. Osoba koja stvara model (u mnogim slučajevima isti analitičar) mora imati dobre vještine modeliranja. Stvaranje logičkih modela poduzeća zahtijeva modeliranje "za budućnost" i sposobnost prevođenja složenog poslovanja u doslovno "kvadrate i linije".

S druge strane, industrijski model omogućuje korištenje iskustva stručnjaka trećih strana. Logički modeli specifični za industriju koriste dokazane metodologije modeliranja i timove iskusnih stručnjaka kako bi izbjegli uobičajene i skupe probleme koji mogu nastati prilikom razvoja poslovnih modela podataka unutar organizacije.

Četvrti faktor je postojeća aplikativna infrastruktura i odnosi s dobavljačima. Ako organizacija već koristi mnogo alata od istog dobavljača i ima uspostavljene odnose s njim, onda ima smisla naručiti industrijski model od istog dobavljača. Takav će model moći slobodno raditi s drugim proizvodima istog dobavljača.

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

Najučinkovitiji industrijski modeli su oni koje nude profesionalni dobavljači. Visoka učinkovitost njihove upotrebe 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 i dobro upućeni u izradu modela specifičnih za industriju.

Industrijski podatkovni modeli tvrtkama pružaju jedinstveni, integrirani pogled na njihove poslovne informacije. Mnogim tvrtkama je teško integrirati svoje podatke, iako je to preduvjet za većinu projekata na razini poduzeća. Prema studiji The Data Warehousing Institute (TDWI), više od 69% anketiranih organizacija otkrilo je da je integracija značajna prepreka za usvajanje novih aplikacija. Naprotiv, integracija podataka tvrtki donosi značajan prihod.

Industrijski podatkovni model, uz svoje veze 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čke slike poslovanja. Korištenje logičkih modela čini se nužnim korakom prema stvaranju skladišta podataka poduzeća.

Publikacije

1. Steve Hoberman. Iskorištavanje industrijskog logičkog podatkovnog modela kao vašeg poslovnog podatkovnog modela.
2. Claudia Imhoff. Brza izrada skladišta podataka i izvođenje projekata poslovne inteligencije pomoću modeliranja podataka (Fast-Tracking Data Warehousing & Business Intelligence Projects via Intelligent Data Modeling)

Korporativna baza podataka središnja je karika korporativnog informacijskog sustava i omogućuje vam stvaranje jedinstvene informacijski prostor korporacije. Korporativne baze podataka

Podijelite svoj rad na društvenim mrežama

Ako vam ovaj rad ne odgovara, na dnu stranice nalazi se popis sličnih radova. Također možete koristiti gumb za pretraživanje

TEMA V. KORPORATIVNE BAZE PODATAKA

V .1. Organiziranje podataka u korporativnim sustavima. Korporativne baze podataka.

V .2. DBMS i strukturna rješenja u korporativnim sustavima.

V.3. Internet / Intranet tehnologije i rješenja za pristup bazi podataka poduzeća.

V .1. ORGANIZACIJA PODATAKA U KORPORATIVNIM SUSTAVIMA. KORPORATIVNE BAZE PODATAKA

Korporativna baza podaci su središnja karika korporativnog informacijskog sustava i omogućuju vam stvaranje jedinstvenog informacijskog prostora korporacije. Korporativne baze podataka (slika 1.1).

Postoje različite definicije baza podataka.

Pod bazom podataka (DB) razumjeti skup informacija logički povezanih na takav način da čine jedan skup podataka pohranjenih u uređajima za pohranu računala. Ovaj skup služi kao početni podatak problema koji se rješavaju u procesu funkcioniranja automatiziranih sustava upravljanja, sustava za obradu podataka, informacijskih i računalnih sustava.

Pojam baze podataka može se ukratko formulirati kao zbirka logički povezanih podataka namijenjenih dijeljenju.

Ispod baze podataka odnosi se na zbirku podataka pohranjenih zajedno s takvom minimalnom redundancijom da se mogu optimalno koristiti za jednu ili više aplikacija.

Svrha izrade baza podataka kao oblici pohrane podataka izgradnja podatkovnog sustava koji ne ovisi o usvojenim algoritmima ( softver), tehnička sredstva koja se koriste, fizička lokacija podataka u računalu. Baza podataka podrazumijeva višenamjensko korištenje (više korisnika, više oblika dokumenata i upita jednog korisnika).

Osnovni zahtjevi za baze podataka:

• Cjelovitost prikaza podataka. Podaci u bazi moraju adekvatno predstavljati sve podatke o objektu i trebaju biti dostatni za ODS.
• Integritet baze podataka. Podaci moraju biti sačuvani tijekom obrade njihovog SOD-a iu svim situacijama koje nastanu tijekom procesa rada.
• Fleksibilnost strukture podataka. Baza podataka treba omogućiti promjenu strukture podataka bez narušavanja njezinog integriteta i potpunosti kada se promijene vanjski uvjeti.
• Izvedivost. To znači da mora postojati objektivan prikaz različitih objekata, njihovih svojstava i odnosa.
• Dostupnost. Potrebno je osigurati diferencijaciju pristupa podacima.
• Redundancija. Baza podataka mora imati minimalnu redundanciju u predstavljanju podataka o bilo kojem objektu.

Znanje se shvaća kao skup činjenica, obrazaca i heurističkih pravila uz pomoć kojih možete riješiti zadani problem.

Baza znanja (KB)  skup korištenih baza podataka i pravila, dobiven od donositelja odluka. Baza znanja je element ekspertnih sustava.

Potrebno je razlikovati različite načine prezentiranja podataka.

Fizički podaci To su podaci pohranjeni u memoriji računala.

Logički prikaz podataka odgovara korisničkom prikazu fizičkih podataka. Razlika između fizičkog i odgovarajućeg logičkog prikaza podataka je u tome što potonji odražava neke važne odnose između fizičkih podataka.

Pod korporativnom bazom podataka razumjeti bazu podataka koja kombinira, u ovom ili onom obliku, sve potrebne podatke i znanje o organizaciji koja se automatizira. U korporativnim informacijskim sustavima najkoncentriraniji izraz našao je konceptintegrirane baze podataka, koji provode načelo jednokratnog unosa i opetovane uporabe informacija.

Riža. 1.1. Struktura interakcije odjela s informacijskim resursima korporacije.

Postoje korporativne baze podataka koncentrirana (centralizirano) i distribuiran.

Fokusirana (centralizirana) baza podataka je baza podataka čiji su podaci fizički pohranjeni u uređajima za pohranu jednog računala. Na sl. Slika 1.2 prikazuje dijagram poslužiteljske aplikacije za pristup bazama podataka na različitim platformama.

sl.1.2. Heterogena shema centralizirana baza podataka

Centralizacija obrade informacija omogućila je uklanjanje takvih nedostataka tradicionalnih datotečni sustavi, kao što su nekoherentnost, nedosljednost i redundantnost podataka. Međutim, kako baze podataka rastu i, osobito kada se koriste u geografski odvojenim organizacijama, pojavljuju se problemi. Na primjer, za koncentrirane baze podataka smještene u čvorištu telekomunikacijske mreže, preko kojih različiti odjeli organizacije pristupaju podacima, sljedeće poteškoće nastaju kako raste količina informacija i broj transakcija:

• Veliki protok razmjene podataka;
• Veliki promet na mreži;
• Niska pouzdanost;
• Niska ukupna izvedba.

Iako je lakše osigurati sigurnost, cjelovitost i dosljednost informacija tijekom ažuriranja u koncentriranoj bazi podataka, ti problemi stvaraju određene poteškoće. Kao moguće rješenje ovih problema predlaže se decentralizacija podataka. Decentralizacijom se postiže sljedeće:

• Veći stupanj istovremenosti obrade zbog raspodjele opterećenja;
• Poboljšanje korištenja on-site podataka prilikom izvođenja udaljenih (udaljenih) upita;
• Niži troškovi;
• Lakoća upravljanja lokalnim bazama podataka.

Troškovi stvaranja mreže čiji čvorovi sadrže radne stanice (mala računala) mnogo su niži od troškova stvaranja sličnog sustava korištenjem velikog računala. Slika 1.3 prikazuje logički dijagram distribuirane baze podataka.

sl.1.3. Distribuirana korporativna baza podataka.

Dajmo sljedeću definiciju distribuirane baze podataka.

Distribuirana baza podataka - ovo je zbirka informacija, datoteka (odnosa) pohranjenih u različitim čvorovima informacijska mreža i logički povezani na takav način da čine jedno tijelo podataka (veza može biti funkcionalna ili preko kopija iste datoteke). Dakle, radi se o skupu baza podataka koje su međusobno logički povezane, ali se fizički nalaze na nekoliko strojeva koji su dio iste računalne mreže.

Najvažniji zahtjevi za karakteristike distribuirane baze podataka su:

• Skalabilnost;
• Kompatibilnost;
• Podrška za različite modele podataka;
• prenosivost;
• Transparentnost lokacije;
• Autonomija distribuiranih čvorova baze podataka (Site Autonomy);
• Obrada distribuiranih zahtjeva;
• Izvršavanje distribuiranih transakcija.
• Podrška za homogeni sigurnosni sustav.

Transparentnost lokacije omogućuje korisnicima rad s bazama podataka bez da znaju bilo što o svojoj lokaciji. Autonomija distribuiranih čvorova baze podataka znači da se svaka baza podataka može održavati neovisno o drugima. Distribuirani upit je upit (SQL naredba) tijekom čijeg se izvršavanja pristupa objektima (tablicama ili pogledima) različitih baza podataka. Prilikom izvođenja distribuiranih transakcija postoji kontrola istodobnosti između svih uključenih baza podataka. Oracle7 koristi dvofaznu tehnologiju prijenosa informacija za izvođenje distribuiranih transakcija.

Baze podataka koje čine distribuiranu bazu podataka ne moraju biti homogene (to jest, održavati ih isti DBMS) ili obrađivati ​​u istom okruženju operacijskog sustava i/ili na istoj vrsti računala. Na primjer, jedna baza podataka može biti Oracle baza podataka na SUN računalu s operativnim sustavom SUN OS (UNIX), drugu bazu podataka može održavati DB2 DBMS na glavnom računalu IBM 3090 s operativnim sustavom MVS, a treća baza podataka može održavati SQL/DS DBMS također na IBM glavnom računalu, ali s VM operativnim sustavom. Potreban je samo jedan uvjet - svi strojevi s bazama podataka moraju biti dostupni preko mreže kojoj pripadaju.

Glavna zadaća distribuirane baze podataka distribucija podataka preko mreže i omogućavanje pristupa istima. Postoje sljedeći načini rješavanja ovog problema:

• Svaki čvor pohranjuje i koristi vlastiti skup podataka koji je dostupan za udaljene upite. Ova distribucija je podijeljena.
• Neki podaci koji se često koriste na udaljenim mjestima mogu biti duplicirani. Ova distribucija se naziva djelomično udvostručena.
• Svi podaci se dupliciraju u svakom čvoru. Ova distribucija se naziva potpuno udvostručena.
• Neke datoteke mogu se podijeliti vodoravno (dodjeljuje se podskup zapisa) ili okomito (dodjeljuje se podskup polja atributa), pri čemu se dodijeljeni podskupovi pohranjuju u različitim čvorovima zajedno s nepodijeljenim podacima. Ova distribucija se naziva podijeljena (fragmentirana).

Kada kreirate distribuiranu bazu podataka na konceptualnoj razini, morate odlučiti sljedeći zadaci:

• Potrebno je imati jedinstven konceptualni dijagram cijele mreže. Ovo će korisniku osigurati logičku transparentnost podataka, zbog čega će moći formirati zahtjev prema cijeloj bazi dok se nalazi na zasebnom terminalu (to je kao da radi s centraliziranom bazom podataka).
• Potrebna je shema koja definira gdje se podaci nalaze na mreži. Time će se osigurati transparentnost postavljanja podataka, tako da korisnik ne mora navoditi gdje će proslijediti zahtjev kako bi dobio tražene podatke.
• Potrebno je riješiti problem heterogenosti distribuiranih baza podataka. Distribuirane baze podataka mogu biti homogene ili heterogene u smislu hardvera i softvera. Problem heterogenosti se relativno lako rješava ako je distribuirana baza podataka hardverski heterogena, a softverski homogena (identičan DBMS u čvorovima). Ako se u čvorovima distribuiranog sustava koriste različiti DBMS-ovi, potrebni su alati za pretvaranje struktura podataka i jezika. Ovo bi trebalo osigurati transparentnu konverziju preko čvorova distribuirane baze podataka.
• Potrebno je riješiti problem upravljanja rječnikom. Kako bi se osigurale sve vrste transparentnosti u distribuiranoj bazi podataka, potrebni su programi koji upravljaju brojnim rječnicima i priručnicima.
• Potrebno je definirati metode za izvršavanje upita u distribuiranoj bazi podataka. Metode za izvršavanje upita u distribuiranoj bazi podataka razlikuju se od sličnih metoda u centraliziranim bazama podataka, budući da se pojedini dijelovi upita moraju izvršavati na lokaciji relevantnih podataka, a djelomični rezultati moraju se prenijeti drugim čvorovima; Pritom se mora osigurati koordinacija svih procesa.
• Potrebno je riješiti problem paralelnog izvršavanja upita. Distribuirana baza podataka zahtijeva složeni mehanizam za upravljanje istodobnim procesiranjem, koji, posebice, mora osigurati sinkronizaciju prilikom ažuriranja informacija, što jamči konzistentnost podataka.
• Potrebna je razvijena metodologija za distribuciju i smještaj podataka, uključujući razdvajanje, što je jedan od glavnih zahtjeva za distribuiranu bazu podataka.

Jedno od novih područja arhitekture računalnog sustava koje se aktivno razvija, a koje je moćno sredstvo za obradu nenumeričkih informacija, je strojevi za baze podataka. Motori baze podataka koriste se za rješavanje nenumeričkih problema, kao što je pohranjivanje, pretraživanje i transformacija dokumenata i činjenica te rad s objektima. Slijedom definicije podatka kao digitalne i grafičke informacije o objektima u okolnom svijetu, pojam podataka tijekom numeričke i nenumeričke obrade ima različit sadržaj. Numerička obrada koristi objekte kao što su varijable, vektori, matrice, višedimenzionalni nizovi, konstante i tako dalje, dok u nenumeričkoj obradi objekti mogu biti datoteke, zapisi, polja, hijerarhije, mreže, odnosi itd. U nenumeričkoj obradi informacije o objektima izravno su od interesa (na primjer, određeni zaposlenik ili grupa zaposlenika), a ne sam dosje zaposlenika. Ovo ne indeksira datoteku zaposlenika za odabir određene osobe; ovdje vas više zanima sadržaj zapisa koji tražite. Ogromne količine informacija obično se podvrgavaju nenumeričkoj obradi. U različitim aplikacijama možete izvršiti sljedeće radnje s tim podacima, na primjer:

• povećati plaće za sve zaposlenike tvrtke;
• obračun bankovnih kamata na račune svih klijenata;
• izvršiti izmjene popisa sve robe na skladištu;
• pronaći traženi sažetak iz svih tekstova pohranjenih u knjižnici ili u sustavu za pretraživanje bibliografskih informacija;
• pronaći opis željenog ugovora u datoteci koja sadrži pravne dokumente;
• pregledajte sve datoteke koje sadrže opise patenata i pronađite patent (ako postoji) sličan onom koji se ponovno predlaže.

Implementirati stroj baze podataka, paralelan i asocijativan arhitektura kao alternativa jednoprocesorskomvon Neumannastrukture koje vam omogućuju rad s velikim količinama informacija u stvarnom vremenu.

Kupljeni su strojevi za baze podataka važno u vezi s proučavanjem i primjenom koncepata umjetne inteligencije kao što su reprezentacija znanja, ekspertni sustavi, zaključivanje, prepoznavanje uzoraka itd.

Spremišta informacija. Danas mnogi priznaju da većina tvrtki već upravlja s nekoliko baza podataka i da bi uspješno radile s informacijama, ne trebaju samo različite vrste baza podataka, već različite generacije DBMS-a. Prema statistici, svaka organizacija koristi prosječno 2,5 različitih DBMS-ova. Postala je očita potreba da se poslovanje tvrtki, odnosno ljudi koji se bave tim poslom „izolira“ od tehnoloških značajki baza podataka, kako bi se korisnicima omogućio jedinstveni pregled korporativnih informacija, bez obzira na to gdje se one fizički pohranjuju. To je potaknulo pojavu tehnologije pohrane informacija ( Skladištenje podataka, DW).

Glavni cilj DW-a je stvaranje jedinstvenog logičkog prikaza podataka sadržanih u različitim vrstama baza podataka, odnosno, drugim riječima, jedinstvenog korporativnog modela podataka.

Novi krug razvoja DW-a postao je moguć zahvaljujući poboljšanju informacijske tehnologije općenito, posebice pojava novih tipova baza podataka temeljenih na paralelnoj obradi upita, koja se pak oslanjala na napredak u području paralelnih računala. Stvoreni su graditelji upitas intuitivnim grafičkim sučeljem koje je olakšalo izradu složenih upita baze podataka. Raznolikost softverameđuprogramska opremaosigurana komunikacijaizmeđu različitih vrsta baza podataka, a na kraju je naglo pao u cijeniuređaji za pohranu.

Struktura korporacije može uključivati ​​banku podataka.

Baza podataka funkcionalna i organizacijska komponenta u automatiziranim sustavima upravljanja i informacijskim i računalnim sustavima, koja pruža centraliziranu informacijsku podršku grupi korisnika ili skupu zadataka koji se rješavaju u sustavu.

Baza podataka smatra se informacijsko-referentnim sustavom čija je glavna svrha:

• u akumulaciji i održavanju u radnom stanju ukupnosti informacija koje čine informacijska baza cijeli automatizirani sustav ili određeni skup zadataka koji se u njemu rješavaju;
• u izdavanju podataka koje zahtijeva zadatak ili korisnik;
• u osiguravanju kolektivnog pristupa pohranjenim informacijama;
• u osiguravanju potrebnog upravljanja korištenjem informacija sadržanih u informacijskoj bazi.

Dakle, moderna banka podataka je složen programski i hardverski kompleks koji uključuje tehničke, sustavne i mrežni alati, baze podataka i DBMS, sustavi za pretraživanje informacija za razne namjene.

V .2. DBMS I STRUKTURALNA RJEŠENJA U KORPORATIVNIM SUSTAVIMA

Sustavi upravljanja bazama podataka i znanjem

Važna komponenta suvremenih informacijskih sustava su sustavi za upravljanje bazama podataka (DBMS).

DBMS skup programskih i jezičnih alata dizajniranih za stvaranje, održavanje i korištenje baza podataka.

Sustav za upravljanje bazom podataka omogućuje pristup bazama podataka za sustave za obradu podataka. Kao što je već navedeno, DBMS igraju važnu ulogu pri stvaranju korporativnih informacijskih sustava i, posebno važno, pri stvaranju informacijskih sustava korištenjem distribuiranih informacijski resursi, temeljen na suvremenim mrežnim računalnim tehnologijama.

Glavna značajka modernih DBMS-ova je da moderni DBMS-ovi podržavaju tehnologije kao što su:

• Tehnologija klijent/poslužitelj.
• Podrška za jezike baza podataka. Ovajjezik definicije sheme DB (SDL - Schema Definition Language),jezik za manipulaciju podacima (DML - Data Manipulation Language), integrirani jezici SQL (Structured Queue Language), QDB (Query - By - Example) i QMF (Query Management Facility) ) napredni periferni alat za specifikaciju upita i generiranje izvješća za DB 2, itd.;
• Izravno upravljanje podacima u vanjskoj memoriji.
• Upravljanje RAM međuspremnicima.
• Upravljanje transakcijama. OLTP tehnologija (on-line obrada transakcija), OLAP tehnologija (On-line obrada analize) za DW.
• Osigurajte zaštitu i integritet podataka. Korištenje sustava dopušteno je samo korisnicima ovlaštenim za pristup podacima. Kada korisnici izvode operacije na podacima, održava se dosljednost pohranjenih podataka (integritet). Ovo je važno u korporativnim višekorisničkim informacijskim sustavima.
• Vođenje dnevnika.

Moderni DBMS-ovi moraju osigurati ispunjenje gore navedenih zahtjeva baze podataka. Osim toga, moraju zadovoljiti sljedeća načela:

• Neovisnost podataka.
• Svestranost. DBMS mora imati snažnu podršku za konceptualni model podataka za prikazivanje prilagođenih logičkih prikaza.
• Kompatibilnost. DBMS mora ostati operativan kako se softver i hardver razvijaju.
• Neredundantnost podataka. Za razliku od datotečnih sustava, baza podataka mora biti jedinstvena zbirka integriranih podataka.
• Zaštita podataka. DBMS mora osigurati zaštitu od neovlaštenog pristupa.
• Integritet podataka. DBMS mora spriječiti korisnike da krše bazu podataka.
• Konkurentno upravljanje radom. DBMS mora zaštititi bazu podataka od nedosljednosti u načinu zajedničkog pristupa. Kako bi se osiguralo dosljedno stanje baze podataka, svi korisnički zahtjevi (transakcije) moraju se izvršavati određenim redoslijedom.
• DBMS mora biti univerzalan. Ona mora podržati različiti modeli podataka na jednoj logičkoj i fizičkoj osnovi.
• DBMS mora podržavati i centralizirane i distribuirane baze podataka i na taj način postati važna karika u računalnim mrežama.

Razmatrajući DBMS kao klasu softverskih proizvoda namijenjenih održavanju baza podataka u automatiziranim sustavima, možemo identificirati dvije najznačajnije značajke koje definiraju tipove DBMS-a. Prema njima, DBMS se može promatrati s dvije točke gledišta:

• njihove mogućnosti u odnosu na distribuirane (korporativne) baze podataka;
• njihov odnos prema tipu podatkovnog modela implementiranog u DBMS.

U odnosu na korporativne (distribuirane) baze podataka, mogu se grubo razlikovati sljedeće vrste DBMS-a:

• DBMS za stolna računala. Ovi proizvodi prvenstveno su usmjereni na rad s osobnim podacima (desktop data). Imaju skupove naredbi za dijeljenje zajedničkih baza podataka, ali male veličine (kao što je mali ured). Prije svega, to su DBMS kao što su Access, dBASE, Paradox, EcoxPro. Zašto Access, dBASE, Paradox, EcoxPro imaju nezadovoljavajući pristup korporativnim podacima. Činjenica je da ne postoji jednostavan način za prevladavanje barijere između osobnih i korporativnih podataka. A poanta nije čak ni u tome da je mehanizam DBMS-a osobnih podataka (ili malog ureda) fokusiran na pristup podacima putem mnogih pristupnika, proizvoda za internetsku mrežu itd. Problem je u tome što ovi mehanizmi obično uključuju potpune prijenose datoteka i nemaju opsežnu podršku indeksa, uzrokujući gotovo zaustavljanje poslužiteljskih čekanja na velikim sustavima.
• Specijalizirani višekorisnički DBMS visokih performansi. Takve DBMS-ove karakterizira prisutnost višekorisničke jezgre sustava, jezika za manipulaciju podacima i sljedećih funkcija karakterističnih za razvijene višekorisničke DBMS-ove:
• organiziranje međuspremnika;
• prisutnost sustava za obradu čekanja transakcija;
• prisutnost mehanizama za blokiranje podataka za više korisnika;
• održavanje dnevnika transakcija;
• prisutnost mehanizama kontrole pristupa.

Ovi DBMS-ovi kao što su Oracle, DB2, SQL/Server, Informix, Sybase, ADABAS, Titanium i drugi pružaju širok raspon usluga za obradu korporativnih baza podataka.

Pri radu s bazama podataka koristi se mehanizam transakcija.

Transakcija je logična jedinica rada.

Transakcija je niz izvršenih operatora za manipulaciju podacimakao jednu cjelinu(sve ili ništa) i prevođenje baze podatakaiz jednog cjelovitog stanja u drugo cjelovito stanje.

Transakcija ima četiri važna svojstva, poznata kao ACID svojstva:

• (A) Atomičnost . Transakcija se izvršava kao atomska operacija - ili se cijela transakcija izvršava ili se cijela transakcija ne izvršava.
• (C) Dosljednost. Transakcija pomiče bazu podataka iz jednog dosljednog (integralnog) stanja u drugo dosljedno (integralno) stanje. Unutar transakcije, dosljednost baze podataka može se pokvariti.
• (I) Izolacija . Transakcije različitih korisnika ne bi trebale ometati jedna drugu (na primjer, kao da su izvršene striktnim redoslijedom).
• (D) Trajnost. Ako je transakcija završena, tada se rezultati njenog rada moraju spremiti u bazu podataka, čak i ako se sustav u sljedećem trenutku sruši.

Transakcija obično počinje automatski kada se korisnik pridruži DBMS-u i nastavlja se dok se ne dogodi jedan od sljedećih događaja:

• Izdana je naredba COMMIT WORK (potvrda transakcije).
• Izdana je naredba ROLLBACK WORK.
• Korisnik je isključen iz DBMS-a.
• Došlo je do kvara sustava.

Za korisnika obično nosi atomski karakter. Zapravo, radi se o složenom mehanizmu interakcije između korisnika (aplikacije) i baze podataka. Softver za poslovne sustave koristi mehanizam za obradu transakcija u stvarnom vremenu (On-line sustavi za obradu transakcija, OLTP), posebice računovodstveni programi, softver za primanje i obradu zahtjeva klijenata, financijske aplikacije, proizvode mnogo informacija. Ovi su sustavi dizajnirani (i optimizirani u skladu s tim) za rukovanje velikim količinama podataka, složenim transakcijama i intenzivnim operacijama čitanja/pisanja.

Nažalost, informacije koje se nalaze u bazama podataka OLTP sustava nisu baš prikladne za korištenje običnim korisnicima (zbog visokog stupnja normalizacije tablica, specifičnih formata prikaza podataka i drugih čimbenika). Stoga se podaci s različitih prijenosnika informacija šalju (u smislu kopiraju) na skladišno skladište, sortiranje i naknadnu isporuku potrošaču. U informacijskoj tehnologiji ulogu skladišta imajuspremišta informacija.

Sustavi analitičke obrade podataka u stvarnom vremenu dostavljaju informacije krajnjem korisniku (on-line analitička obrada, OLAP), koji omogućuju iznimno jednostavan pristup podacima kroz praktične načine generiranja upita i analize rezultata. U OLAP sustavima vrijednost informacijskog proizvoda raste korištenjem različitih metoda analize i statističke obrade. Osim toga, ovi sustavi su optimizirani u pogledu brzine dohvaćanja podataka, prikupljanja generaliziranih informacija i usmjereni su na obične korisnike (imaju intuitivno sučelje). Ako OLTP sustav daje odgovore na jednostavna pitanja poput "koja je bila razina prodaje proizvoda N u regiji M u siječnju 199x?", zatim OLAP sustavi spreman za složenije zahtjeve korisnika, npr.: “Dati analizu prodaje proizvoda N u svim regijama prema planu za drugi kvartal u usporedbi s dvije prethodne godine.”

Klijent/poslužitelj arhitektura

U modernim sustavima distribuirana obrada informacija, tehnologija zauzima središnje mjesto klijent/poslužitelj. U sustavu arhitektura klijent-poslužiteljobrada podataka podijeljena je između klijentskog računala i poslužiteljskog računala, komunikacija između kojih se odvija preko mreže. Ova podjela procesa obrade podataka temelji se na grupiranju funkcija. Obično je računalo poslužitelja baze podataka posvećeno izvođenju operacija baze podataka, a klijentsko računalo to obavlja aplikacijski programi. Slika 2.1 prikazuje jednostavan sustav klijent-poslužitelj arhitekture koji se sastoji od računala koje djeluje kao poslužitelj i drugog računala koje djeluje kao njegov klijent. Svaki stroj obavlja različite funkcije i ima vlastite resurse.

		Baza podataka
Poslužiteljsko računalo
Neto
IBM kompatibilno računalo	IBM kompatibilno računalo	IBM kompatibilno računalo
		Prijave

Riža. 2.1. Sustav arhitekture klijent-poslužitelj

Glavna funkcija klijentskog računala je izvršavanje aplikacije (korisničko sučelje i logika prezentacije) i komunikacija s poslužiteljem kada to aplikacija zahtijeva.

poslužitelj ovo je objekt (računalo) koji pruža usluge drugim objektima na njihov zahtjev.

Kao što sam izraz sugerira, glavna funkcija poslužiteljskog računala je služiti potrebama klijenta. Izraz "poslužitelj" koristi se za označavanje dvije različite skupine funkcija: poslužitelj datoteka i poslužitelj baze podataka (u daljnjem tekstu ovi izrazi označavaju, ovisno o kontekstu, ili softver koji implementira te skupine funkcija ili računala s tim softverom). Datotečni poslužitelji nisu dizajnirani za obavljanje operacija baze podataka; njihova glavna funkcija je dijeljenje datoteka između više korisnika, tj. osiguravanje istovremenog pristupa većeg broja korisnika datotekama na računalu – datotečni poslužitelj. Primjer poslužitelja datoteka je Novellov operativni sustav NetWare. Poslužitelj baze podataka može se instalirati i aktivirati na računalu – file serveru. Oracle DBMS u obliku NLM (Network Loadable Module) radi u NetWare okruženju na poslužitelju datoteka.

poslužitelj lokalna mreža mora imati resurse koji odgovaraju njegovoj funkcionalnoj namjeni i potrebama mreže. Imajte na umu da je zbog fokusa na pristup otvorenim sustavima ispravnije govoriti o logičkim poslužiteljima (što znači skup resursa i softvera koji pružaju usluge preko tih resursa), koji nisu nužno smješteni na različitim računalima. Značajka logičkog poslužitelja u otvorenom sustavu je da ako je, zbog učinkovitosti, preporučljivo premjestiti poslužitelj na zasebno računalo, tada se to može učiniti bez potrebe za bilo kakvim izmjenama, bilo na njemu samom ili na aplikaciji. programe koji ga koriste.

Jedan od važnih zahtjeva za poslužitelj je da operativni sustav u kojem se nalazi poslužitelj baze podataka mora biti multitasking (i, poželjno, ali ne nužno, višekorisnički). Na primjer, Oracle DBMS instaliran na osobnom računalu s MS-DOS (ili PC-DOS) operativnim sustavom koji ne ispunjava zahtjeve multitaskinga ne može se koristiti kao poslužitelj baze podataka. I isti Oracle DBMS, instaliran na računalu s višezadaćnim (iako ne višekorisničkim) OS/2 operativnim sustavom, može biti poslužitelj baze podataka. Mnoge varijante UNIX sustava, MVS, VM i nekih drugih operativnih sustava su i višezadaćni i višekorisnički.

Distribuirano računalstvo

Izraz "distribuirano računalstvo" često se koristi za označavanje dva različita, iako komplementarna koncepta:

• Distribuirana baza podataka;
• Distribuirana obrada podataka.

Primjena ovih koncepata omogućuje organiziranje pristupa informacijama pohranjenim na više strojeva od strane krajnjih korisnika korištenjem različitih alata.

Postoje mnoge vrste poslužitelja:

• Poslužitelj baze podataka;
• Ispisni poslužitelj;
• Poslužitelj za daljinski pristup;
• Fax poslužitelj;
• Web poslužitelj, itd.

Temeljeno na temeljnoj tehnologiji klijent/poslužitelj Postoje takve osnovne tehnologije kao što su:

• Tehnologije operacijskih sustava, koncept interakcije otvorenih sustava, kreiranje objektno orijentiranih okruženja za funkcioniranje programa;
• Telekomunikacijske tehnologije;
• Mrežne tehnologije;
• Grafičke tehnologije korisničko sučelje ( GUI);
• itd.

Prednosti klijent-poslužitelj tehnologije:

• Tehnologija klijent/poslužitelj omogućuje računalstvo u heterogenim računalnim okruženjima. Neovisnost o platformi: pristupite heterogenim mrežnim okruženjima koja uključuju različite vrste računala s različitim operativnim sustavima.
• Neovisnost izvora podataka: pristup informacijama iz heterogenih baza podataka. Primjeri takvih sustava su DB2, SQL/DS, Oracle, Sybase.
• Balans opterećenja klijenta i poslužitelja.
• Izvršite izračune tamo gdje su najučinkovitiji;
• Pružaju mogućnost učinkovitog skaliranja;
• Višeplatformsko računalstvo. Višeplatformsko računalstvo jednostavno se definira kao implementacija tehnologija u heterogenim računalnim okruženjima. Ovdje treba osigurati sljedeće mogućnosti:
• Aplikacija mora raditi na više platformi;
• Na svim platformama mora imati isto sučelje i radnu logiku;
• Aplikacija se mora integrirati s izvornim operativnim okruženjem;
• Trebao bi se ponašati jednako na svim platformama;
• Mora imati jednostavnu i dosljednu podršku.

 Distribuirano računalstvo. Distribuirano računalstvo uključuje raspodjelu rada između nekoliko računala (iako je distribuirano računalstvo širi koncept).

 Dezagregacija. Razdvojni prijenos aplikacija za velika računala na male računalne platforme.

• Smanjeni troškovi infrastrukture i hardvera. Isplativost: Dostupnost jeftine računalne opreme i sve veća rasprostranjenost lokalnih mreža čine tehnologiju klijent-poslužitelj isplativijom od ostalih tehnologija obrade podataka. Opremu je moguće nadograditi čim se ukaže potreba.

 Smanjenje ukupnog vremena izvršenja aplikacije;

 Smanjenje korištenja memorije klijenta;

 Smanjenje mrežnog prometa.

• Sposobnost rada s multimedijom: do danas je stvoreno mnogo multimedijskih programa za računala. Ili ne postoje slični programi za konfiguraciju terminal-host ili su vrlo skupi.
• Mogućnost privlačenja velikih računalnih resursa za operacije baze podataka: budući da se aplikacije izvode na klijentskim računalima, poslužiteljsko računalo oslobađa dodatne resurse (u usporedbi s konfiguracijom terminal-host) za operacije baze podataka, kao što su CPU i operativni resursi memorija.
• Povećana produktivnost programera: produktivnost programera se povećava s alatima kao što su SQL*Forms i CASE, koji vam omogućuju da razvijate aplikacije brže od programskih jezika kao što su C, PL1 ili COBOL.
• Povećana produktivnost krajnjeg korisnika: Danas su mnogi krajnji korisnici ovladali sustavima kao što su Lotus, Paradox, Word Perfect, Harvard Graphics itd.

Pozadinsko sučelje je definirano i fiksno. Stoga je moguće kreirati nove klijentske dijelove postojećeg sustava (primjer interoperabilnosti na razini sustava).

Riža. 2.2. Ilustracija pristupa klijenta dijeljenom resursu poslužitelja.

Kako implementirati tehnologiju klijent-poslužitelj

Instalacija sustava temeljenog na tehnologiji klijent-poslužitelj i sposobnog za distribuiranu obradu podataka razmatra se u nastavku. Potreban je sljedeći računalni hardver i softver:

• računalo poslužitelja baze podataka;
• klijentska računala;
• komunikacijska mreža;
• mrežni softver;
• aplikacijski softver.

SQL jezik . Jezik upita visoke razine - SQL (jezik strukturiranih upita ) koristi se za implementaciju upita bazama podataka, kao što su NMD, DML i PYAD i prihvaćen je kao standard. Jezik SQL je izvorno usvojen kao podatkovni jezik softverskih proizvoda tvrtke IBM i YaMD relacijski DBMS SYSTEM R iz IBM-a . Važna osobina jezika SQL je da je isti jezik predstavljen kroz dva različita sučelja, naime: kroz interaktivno sučelje i kroz sučelje za programiranje aplikacije (dinamičko SQL). Dinamički SQL sastoji se od mnogih ugrađenih jezičnih mogućnosti SQL , predviđeno posebno za izradu interaktivnih aplikacija, gdje je interaktivna aplikacija definirana kao program koji je napisan za podršku pristupu bazi podataka od strane krajnjeg korisnika koji radi na interaktivnom terminalu. Jezik SQL pruža funkcije definiranja, manipuliranja i upravljanja podacima baze podataka i transparentan je korisniku sa stajališta implementiranog DBMS-a.

Riža. 2.3. Shema za izvršavanje korisničkih upita prema distribuiranim bazama podataka.

Unutarnja struktura baza podataka određena je modelima podataka koji se koriste. Konceptualni model ima veće mogućnosti apstrakcije i bogatiju semantiku u usporedbi s vanjskim modelima. Vanjski modeličesto nazivani sintaktičkim ili operativnim modelima, koji se odnose na sintaktičku prirodu kontrole i primjene kao sredstva interakcije korisnika s bazom podataka. U informacijskom modeliranju postoje različite razine apstrakcije, od razine konceptualnog modela do razine fizičkog podatkovnog modela, koje utječu na arhitekturu DBMS-a.

Model podataka sastoji se od tri komponente:

• Struktura podataka koja predstavlja bazu podataka iz korisničke perspektive.
• Važeće operacije izvedene na strukturi podataka. Potrebno je znati raditi s ovom strukturom koristeći različite DML i NMD operacije. Bogata struktura je bezvrijedna ako ne postoji način da se operira njenim sadržajem.
• Ograničenja za kontrolu integriteta. Model podataka mora imati sredstva za održavanje integriteta i zaštitu. Kao primjer, razmotrite sljedeća dva ograničenja:
• Svako podstablo mora imati izvorni čvor. Hijerarhijske baze podataka ne mogu pohranjivati ​​podređene čvorove bez nadređenog čvora.
• U odnosu na relacijsku bazu podataka, ne mogu postojati identične torke. Za datoteku ovaj zahtjev zahtijeva da svi zapisi budu jedinstveni.

Jedan od najvažnije karakteristike Rad DBMS-a je sposobnost povezivanja objekata.

Postoje sljedeće vrste veza između objekata:

• Jedan na jedan (1:1). Jedan objekt jednog skupa može biti povezan s jednim objektom drugog skupa.
• Jedan prema više (1:M). Jedan objekt jednog skupa može biti povezan s mnogim objektima drugog skupa.
• Mnogi prema mnogima (M:N). Jedan objekt jednog skupa može biti pridružen mnogim objektima drugog skupa, ali jedan objekt drugog skupa može biti povezan s mnogim objektima prvog skupa.
• Razgranat . Jedan objekt jednog skupa može biti pridružen objektima mnogih skupova.
• Ponavljajući . Jedan objekt dati skup mogu biti povezani objektom istog skupa.

Postoje sljedeći osnovni modeli podataka:

• Relacijski model podataka.
• Hijerarhijski model podataka.
• Nepotpun mrežni podatkovni model.
• CODASYL model podataka.
• Prošireni mrežni podatkovni model.

V.3. INTERNET / INTRANET TEHNOLOGIJE I KORPORATIVNA RJEŠENJA ZA PRISTUP BAZAMA PODATAKA

Glavni problem sustava baziranih na arhitekturi klijent-poslužitelj je što se, u skladu s konceptom otvorenih sustava, od njih zahtijeva da budu mobilni u najširoj mogućoj klasi hardverskih i programskih rješenja otvorenih sustava. Čak i ako se ograničimo na lokalne mreže temeljene na UNIX-u, različite mreže koriste različite hardverske i komunikacijske protokole. Pokušaji stvaranja sustava koji podržavaju sve moguće protokole dovode do njihovog preopterećenja mrežnim detaljima nauštrb funkcionalnosti.

Još složeniji aspekt ovog problema povezan je s mogućnošću korištenja različitih prikaza podataka u različitim čvorovima heterogene lokalne mreže. Različita računala mogu imati različito adresiranje, reprezentaciju brojeva, kodiranje znakova itd. Ovo je posebno važno za poslužitelje visoke razine: telekomunikacije, računalstvo, baze podataka.

Općenito rješenje Problem mobilnosti sustava baziranih na arhitekturi klijent-poslužitelj je oslanjanje na programske pakete koji implementiraju protokole pozivanja udaljenih procedura (RPC - Remote Procedure Call). Kada koristite takve alate, pozivanje usluge na udaljenom čvoru izgleda kao uobičajeni poziv procedure. RPC alati, koji naravno sadrže sve informacije o specifičnostima lokalne mrežne opreme i mrežnih protokola, prevode poziv u niz mrežnih interakcija. Stoga su specifičnosti mrežnog okruženja i protokola skrivene od aplikacijskog programera.

Kada se pozove udaljena procedura, RPC programi pretvaraju formate podataka klijenta u posredne formate neovisne o stroju, a zatim pretvaraju u formate podataka poslužitelja. Pri prijenosu parametara odgovora provode se slične transformacije.

Drugi slični radovi koji bi vas mogli zanimati.vshm>
6914.		Koncept baze podataka	11,56 KB
	Baza podataka je zbirka neovisnih materijala predstavljenih u objektivnom obliku, članaka izračuna normativnih akata sudskih odluka i drugih sličnih materijala, sistematiziranih na takav način da se ti materijali mogu pronaći i obraditi pomoću elektroničkog računala Građanski zakonik Ruske Federacije Federacija čl. Baza podataka organizirana u skladu s određenim pravilima i održavana u memoriji računala skup je podataka koji karakterizira trenutno stanje neke...
8064.		Distribuirane baze podataka	43,66 KB
	Distribuirane baze podataka Pod distribuirana baza RDB podaci se shvaćaju kao skup logički međusobno povezanih zajedničkih podataka koji su fizički raspoređeni po različitim čvorovima računalne mreže. Pristup podacima ne bi trebao ovisiti o prisutnosti ili odsutnosti replika podataka. Sustav mora automatski odrediti metode za izvođenje veza fuzije podataka: mrežni kanal sposoban nositi se s količinom prenesenih informacija i čvor koji ima dovoljnu računalnu snagu za povezivanje tablica. RDBMS mora moći...
20319.		BAZE PODATAKA I NJIHOVA ZAŠTITA	102,86 KB
	Online operativne baze podataka pojavile su se sredinom 1960-ih. Operacije nad operativnim bazama podataka obrađene su interaktivno pomoću terminala. Jednostavne sekvencijalne organizacije zapisa indeksa brzo su se razvile u moćniji model zapisa orijentiran na skup. Charles Bachman dobio je Turingovu nagradu za svoje vodstvo nad Data Base Task Group (DBTG), koja je razvila standardni jezik za opisivanje i manipuliranje podacima.
5031.		Knjižnica za razvoj baze podataka	11,72 MB
	Tehnologija projektiranja baze podataka. Definirajte odnose između entiteta i izradite podatkovni model. Glavne ideje suvremene informacijske tehnologije temelje se na konceptu da podatke treba organizirati u baze podataka kako bi se adekvatno prikazao promjenjivi stvarni svijet i zadovoljile informacijske potrebe korisnika. Ove baze podataka izrađuju se i rade pod kontrolom posebnih programski sustavi nazvani DBMS sustavi za upravljanje bazama podataka.
13815.		MODEL HIJERARHIJSKE BAZE PODATAKA	81,62 KB
	Glavne ideje suvremene informacijske tehnologije temelje se na konceptu baza podataka, prema kojem su temelj informacijske tehnologije podaci organizirani u baze podataka koje na odgovarajući način odražavaju stanje određenog predmetnog područja i daju korisniku ažurne informacije u ovo predmetno područje. Potrebno je prepoznati činjenicu da su podaci...
14095.		Razvoj knjižnične baze podataka	11,72 MB
	Povećanje obujma i strukturne složenosti pohranjenih podataka te širenje kruga korisnika informacijskih sustava doveli su do široke uporabe najpovoljnijeg i relativno lako razumljivog relacijskog (tabularnog) DBMS-a.
5061.		Izrada kliničke baze podataka	2,4 MB
	Razvoj računalne tehnologije i informacijske tehnologije omogućio je stvaranje i široku primjenu automatiziranih informacijskih sustava (AIS) za različite namjene. Razvijaju se i implementiraju informacijski sustavi za upravljanje gospodarskim i tehničkim objektima
13542.		Geološke informacijske baze podataka	20,73 KB
	Nedavno je implementacija računalna tehnologija a posebno baze podataka u znanstveno područje. Ovaj proces ne zaobilazi geologiju, jer upravo u prirodnim znanostima postoji potreba za pohranjivanjem i obradom velikih količina informacija.
9100.		Baza podataka. Osnovni koncepti	26,28 KB
	Baza podataka je zbirka informacija o određenim objektima stvarnog svijeta u bilo kojem predmetnom području, ekonomiji, menadžmentu, kemiji itd. Svrha informacijskog sustava nije samo pohranjivanje podataka o objektima, već i manipuliranje tim podacima, uzimajući uzeti u obzir veze između objekata. Svaki objekt karakterizira neki skup svojstava podataka, koji se u bazi podataka nazivaju atributima.
5240.		Izrada baze podataka “Sveučilišni dekanat”.	1,57 MB
	Baza podataka (DB) je skup međusobno povezanih podataka pohranjenih zajedno na vanjskom memorijskom mediju računala, s takvom organizacijom i minimalnom redundancijom koja im omogućuje optimalnu upotrebu za jednu ili više aplikacija

Svrha predavanja

Nakon proučavanja gradiva na ovom predavanju znat ćete:

• što se dogodilo model podataka poduzeća ;
• kako pretvoriti korporativni podatkovni model na model skladišta podataka;
• bitni elementi korporativni podatkovni model ;
• razine prezentacije modela podataka poduzeća ;
• algoritam za pretvaranje korporativnog podatkovnog modela u višedimenzionalni model skladišta podataka ;

i nauči:

• razviti modele skladišta podataka na temelju korporativni podatkovni model organizacije;
• razviti shemu zvijezda koristeći CASE alate;
• pregradni stolovi višedimenzionalni model pomoću CASE alata.

Podatkovni model poduzeća

Uvod

Srž svakog skladišta podataka je njegov podatkovni model. Bez podatkovnog modela bit će vrlo teško organizirati podatke u skladištu podataka. Stoga, HD programeri moraju potrošiti vrijeme i trud na razvoj takvog modela. Razvoj HD modela pada na ramena HD dizajnera.

U usporedbi s projektiranjem OLTP sustava, metodologija projektiranja skladišta podataka ima niz karakterističnih značajki vezanih uz orijentaciju struktura podataka za pohranu za rješavanje problema analize i informacijske podrške procesu donošenja odluka. Podatkovni model skladišta podataka mora pružiti učinkovito rješenje upravo za te probleme.

Polazište u projektiranju skladišta podataka može biti tzv model podataka poduzeća(corporate data model ili enterprise data model, EDM), koji nastaje tijekom procesa projektiranja OLTP sustava organizacije. Prilikom projektiranja korporativni podatkovni model Obično se na temelju poslovnih transakcija pokušava stvoriti struktura podataka koja bi prikupila i sintetizirala sve informacijske potrebe organizacije.

Tako, model podataka poduzeća sadrži potrebne informacije izgraditi model skladišta podataka. Dakle, u prvoj fazi, ako takav model postoji u organizaciji, dizajner skladišta podataka može započeti s projektiranjem skladišta podataka rješavanjem problema transformacije korporativni podatkovni model na HD model.

Podatkovni model poduzeća

Kako riješiti problem transformacije korporativni podatkovni model na HD model? Da biste riješili ovaj problem, morate imati ovaj model, tj. model podataka poduzeća mora se graditi i dokumentirano. I trebate razumjeti Što od ovog modela i Kako treba transformirati u model pohrane podataka.

Pojasnimo koncept iz perspektive HD dizajnera korporativni podatkovni model. Pod, ispod korporativni podatkovni model razumjeti višerazinski, strukturirani opis predmetnih područja organizacije, strukture podataka predmetnih područja, poslovnih procesa i poslovnih procedura, tokova podataka prihvaćenih u organizaciji, dijagrama stanja, matrica procesa podataka i drugih prikaza modela koji se koriste u aktivnostima organizacije . Dakle, u širem smislu riječi, model podataka poduzeća je skup modela na različitim razinama koji karakteriziraju (model na nekoj apstraktnoj razini) aktivnosti organizacije, tj. sadržaj korporativni model izravno ovisi o tome koje su strukture modela bile uključene u nju u određenoj organizaciji.

Glavni elementi korporativni podatkovni model su:

• opis područja djelovanja organizacije (definicija područja djelovanja);
• odnosi između gore definiranih predmetnih područja;
• informacijski podatkovni model (ERD model ili model entitet-odnos);
• za svaki opis predmetnog područja:
  • ključevi entiteta;
  • atributi entiteta;
  • podtipovi i nadtipovi;
  • veze između entiteta;
  • grupiranje atributa;
  • odnosi između predmetnih područja;
• funkcionalni model ili model poslovnog procesa;
• dijagrami protoka 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 podatkovni model.

Slojevi prikaza modela podataka poduzeća

Podatkovni model poduzeća dodatno je podijeljen prema predmetnim područjima, koja predstavljaju skupine entiteta relevantnih za podršku specifičnim poslovnim potrebama. Neka predmetna područja mogu pokrivati ​​specifične poslovne funkcije kao što je upravljanje ugovorima, dok druga mogu kombinirati entitete koji opisuju proizvode ili usluge.

Svaki logički model mora odgovarati postojećoj domeni problema korporativni podatkovni model. Ako logički model ne ispunjava ovaj zahtjev, mora mu se dodati model koji definira domenu.

Podatkovni model poduzeća obično ima nekoliko razina prezentacije. Zapravo visoka razina(visoka razina) korporativni podatkovni model postoji opis glavnih predmetnih područja organizacije i njihovih odnosa na razini entiteta. Na sl. 16.2 prikazuje fragment korporativni podatkovni model vrhunska razina.

Riža. 16.2.

Dijagram prikazan na slici prikazuje četiri tematska područja: “Kupac” ( Kupac), "Ček" ( račun), "Narudžba" ( Narudžba) i "Proizvod" ( Proizvod). Tipično, na najvišoj razini, prikazi modela samo specificiraju izravne veze između predmetnih područja, koja npr. bilježe sljedeću činjenicu: kupac plaća račun za narudžbu robe. Detaljne informacije i neizravni odnosi na ovoj razini korporativni model nisu dani.

Na sljedećem prosječna razina(srednja razina) korporativni podatkovni model prikazuje detaljne informacije o objektima domene, tj. ključevima 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 prikazan je prosječna razina reprezentacija korporativni model za fragment predmetnog područja "Red".

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

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

Sa stajališta projektiranja skladišta podataka, važan čimbenik pri donošenju odluke o izradi modela skladišta podataka iz korporativni podatkovni model je država potpunost korporativni podatkovni model.

Korporativni podatkovni model organizacije ima svojstvo evolucije, tj. stalno se razvija i usavršava. Neka predmetna područja korporativni podatkovni model može biti dobro razrađen, za neke posao možda još nije započeo. Ako fragment predmetnog područja nije razrađen u korporativni podatkovni model, onda ovaj model nije moguće koristiti kao polazište za projektiranje skladišta podataka.

Stupanj dovršenosti korporativni model može se izravnati u projektu skladišnog objekta na sljedeći način. Budući da je proces razvoja skladišta podataka obično vremenski podijeljen u niz faza, proces njegovog dizajna može se sinkronizirati s proces završetka razvoj pojedinih fragmenata korporativni podatkovni model organizacije.

Na najnižem razina prezentacije modela korporativnih podataka prikazuje informacije o fizičkim karakteristikama objekata baze podataka koji odgovaraju logički model podataka prosjek prezentacijski sloj korporativnog podatkovnog modela.

IT stručnjaci sve više usmjeravaju pozornost na rješenja za upravljanje podacima temeljena na industrijskim standardnim modelima podataka i predlošcima poslovnih odluka. Spremni za preuzimanje složeni fizički modeli podataka i izvješća poslovne analitike za specifična područja djelovanja omogućuju vam objedinjavanje informacijske komponente aktivnosti poduzeća i značajno ubrzavanje izvršenja poslovnih procesa. Predlošci rješenja omogućuju pružateljima usluga da iskoriste snagu nestandardnih informacija skrivenih u postojećim sustavima, čime se smanjuju rokovi, troškovi i rizici projekta. Na primjer, projekti iz stvarnog svijeta pokazuju da model podataka i predlošci poslovnih odluka mogu smanjiti razvojni napor za 50%.

Industrijski logički model je specifičan za domenu, integriran i logički strukturiran prikaz svih informacija koje moraju postojati u skladištu podataka poduzeća kako bi se odgovorilo na strateška i taktička poslovna pitanja. Osnovna namjena modela je olakšati snalaženje u podatkovnom prostoru i pomoći u prepoznavanju detalja koji su važni za razvoj poslovanja. U suvremenim uvjetima za uspješno vođenje poslovanja prijeko je potrebno jasno razumijevanje povezanosti različitih komponenti i dobro razumijevanje ukupne slike organizacije. Identifikacija svih detalja i veza pomoću modela omogućuje najučinkovitije korištenje vremena i alata za organizaciju rada tvrtke.

Podatkovni modeli su apstraktni modeli koji opisuju kako su podaci predstavljeni i kako im se pristupa. Modeli podataka definiraju elemente podataka i odnose između njih u određenom području. Podatkovni model je navigacijski alat za poslovne i IT profesionalce koji koristi određeni skup simbola i riječi za točno objašnjenje određene klase informacija iz stvarnog svijeta. To omogućuje bolje razumijevanje unutar organizacije i tako stvara fleksibilnije i stabilnije okruženje aplikacija.

Primjer modela “GIS za državnu i lokalnu upravu”.

Danas je strateški važno za pružatelje softvera i usluga da mogu brzo odgovoriti na promjene u industriji povezane s tehnološkim inovacijama, ukidanjem državnih ograničenja i složenošću opskrbnih lanaca. Usporedo s promjenama u poslovnom modelu, povećava se složenost i cijena informacijskih tehnologija nužnih za podršku aktivnostima poduzeća. Upravljanje podacima posebno je teško u okruženju u kojem se korporativni informacijski sustavi, kao i funkcionalni i poslovni zahtjevi za njima, neprestano mijenjaju.

Industrijski podatkovni modeli osmišljeni su kako bi olakšali i optimizirali ovaj proces i doveli IT pristup na modernu razinu.

Modeli podataka o industriji iz tvrtkeEsri

Modeli podataka za Esri ArcGIS platformu pružaju radne predloške za korištenje u GIS projektima i stvaranje struktura podataka za različita područja primjene. Izgradnja podatkovnog modela uključuje stvaranje konceptualnog dizajna, logičke strukture i fizičke strukture koja se zatim može koristiti za izgradnju osobne ili poslovne baze geopodataka. ArcGIS pruža alate za kreiranje i upravljanje vašom shemom baze podataka, a predlošci modela podataka koriste se za brzo pokretanje GIS projekta u raznim aplikacijama i industrijama. Esri i zajednica korisnika proveli su dosta vremena razvijajući niz predložaka koji mogu pružiti brzi način za početak rada s dizajnom geobaze podataka poduzeća. Ovi su projekti opisani i dokumentirani na support.esri.com/datamodels. Ispod, redoslijedom kojim se spominju na ovoj stranici, nalazi se semantički prijevod imena modela industrije Esri:

• Adresni registar
• Poljoprivreda
• Meteorologija
• Osnovni prostorni podaci
• Bioraznolikost
• Unutrašnjost zgrada
• Računovodstvo stakleničkih plinova
• Održavanje administrativnih granica
• Oružane snage. Obavještajna služba
• Energija (uključujući novi ArcGIS MultiSpeak protokol)
• Ekološke strukture
• Ministarstvo za izvanredne situacije. Zaštita od požara
• Katastar šuma
• Šumarstvo
• Geologija
• Nacionalni GIS (e-gov)
• Podzemne i otpadne vode
• zdravstvo
• Arheologija i zaštita spomenika
• nacionalna sigurnost
• Hidrologija
• Međunarodna hidrografska organizacija (IHO). S-57 format za ENC
• Navodnjavanje
• Zemljišna knjiga
• Općinska vlast
• Pomorska navigacija
• Državni katastar
• Naftne i plinske strukture
• Cjevovodi
• Rasterska pohrana
• Batimetrija, topografija morskog dna
• Telekomunikacija
• Prijevoz
• Vodovod, kanalizacija, stambeno-komunalne usluge

Ovi modeli sadrže sve potrebne značajke industrijskog standarda, naime:

• su slobodno dostupni;
• nisu vezani uz tehnologiju "odabranog" proizvođača;
• nastali kao rezultat provedbe stvarnih projekata;
• stvoren uz sudjelovanje stručnjaka iz industrije;
• osmišljen kako bi osigurao informacijsku interakciju između različitih proizvoda i tehnologija;
• ne proturječe drugim standardima i regulatornim dokumentima;
• koristi se u završenim projektima diljem svijeta;
• dizajnirani su za rad s informacijama o svemu životni ciklus sustav koji se stvara, a ne sam projekt;
• proširiv kako bi zadovoljio potrebe kupaca bez gubitka kompatibilnosti s drugim projektima i/ili modelima;
• popraćeno dodatnim materijalima i primjerima;
• koristi se u smjernicama i tehničkim materijalima raznih industrijskih poduzeća;
• velika zajednica sudionika, s pristupom zajednici otvorenim svima;
• velik broj referenci na podatkovne modele u publikacijama tijekom posljednjih godina.

Stručnjaci Esrija dio su stručnog panela neovisnih tijela koja preporučuju različite industrijske modele za korištenje, poput PODS-a (Pipeline Open Data Standards – otvoreni standard za industriju nafte i plina; trenutno postoji implementacija PODS-a kao geobaze podataka Esri PODS Esri Spatial 5.1.1) ili baza geopodataka (GD) tvrtke ArcGIS for Aviation, koja uzima u obzir preporuke ICAO i FAA, kao i standard za razmjenu navigacijskih podataka AIXM 5.0. Osim toga, postoje preporučeni modeli koji se strogo pridržavaju postojećih industrijskih standarda, kao što su S-57 i ArcGIS za pomorstvo (pomorske i obalne), kao i modeli stvoreni radom Esri Professional Services koji su "de facto" standardi u svojim poljima. Na primjer, GIS za naciju i lokalnu upravu utjecao je na standarde NSDI i INSPIRE, a Hydro i Groundwater se intenzivno koriste u ArcHydro-ovom besplatno dostupnom profesionalnom paketu i komercijalnim proizvodima trećih tvrtki. Treba napomenuti da Esri također podržava "de facto" standarde, kao što je NHDI. Svi predloženi podatkovni modeli su dokumentirani i spremni za korištenje u IT procesima poduzeća. Popratni materijali za modele su:

• UML dijagrami odnosa entiteta;
• strukture podataka, domene, imenici;
• gotove predloške baza geopodataka u ArcGIS GDB formatu;
• ogledni podaci i ogledni zahtjevi;
• primjeri skripti za učitavanje podataka, primjeri uslužnih programa za analizu;
• referentne knjige o predloženoj strukturi podataka.

Esri sažima svoje iskustvo u izgradnji industrijskih modela u obliku knjiga i lokalizira objavljene materijale. Esri CIS je lokalizirao i objavio sljedeće knjige:

• Geoprostorna servisno orijentirana arhitektura (SOA);
• Dizajn geobaza podataka za transport;
• Korporativni geografski informacijski sustavi;
• GIS: nova energija elektro i plinskih poduzeća;
• Nafta i plin na digitalnoj karti;
• Modeliranje našeg svijeta. Esri Geodatabase Design Guide;
• Razmišljanje o GIS-u. GIS planiranje: Vodič za menadžere;
• Geografski informacijski sustavi. Osnove;
• GIS za administrativno i gospodarsko upravljanje;
• Web GIS. Načela i primjena;
• Strategije projektiranja sustava, 26. izdanje;
• 68 brojeva časopisa ArcReview s publikacijama tvrtki i korisnika GIS sustava;
• ... i mnoge druge tematske bilješke i publikacije.

Na primjer, knjiga Modeliranje našeg svijeta..." (prijevod) je opsežan vodič i referenca za modeliranje podataka u GIS-u općenito, a posebno modele podataka geobaze podataka. Knjiga pokazuje kako razviti ispravne odluke o modeliranju podataka, odluke koje su uključene u svaki aspekt GIS projekta, od dizajn baze podataka do podataka i prikupljanje podataka do prostorne analize i vizualizacije. Detaljno opisuje kako dizajnirati geografsku bazu podataka koja odgovara projektu, konfigurirati funkcionalnost baze podataka bez programiranja, upravljati tijek rada u složenim projektima, modelirati različite mrežne strukture kao što su rijeka, transportnih ili električnih mreža, integrirati podatke snimanja prostora u proces geografske analize i prikaza, kao i izraditi 3D modele GIS podataka. Projektiranje geobaza podataka za transport"sadrži metodološke pristupe testirane na velikom broju projekata iu potpunosti je u skladu sa zakonodavnim zahtjevima Europe i SAD-a, kao i međunarodnim standardima. A u knjizi " GIS: nova energija elektro i plinskih poduzeća" koristi primjere iz stvarnog života kako bi pokazao prednosti koje poslovni GIS može donijeti dobavljaču energije, uključujući aspekte kao što su korisnička služba, mrežne operacije i drugi poslovni procesi.

Neke od knjiga, prevedenih i izvornih, koje su na ruskom objavili Esri CIS i DATA+. Obrađuju i konceptualna pitanja vezana uz GIS tehnologiju i mnoge primijenjene aspekte modeliranja i implementacije GIS-a različitih razmjera i namjena.

Razmotrimo korištenje industrijskih modela na primjeru BISDM (Building Interior Space Data Model, informacijski model unutarnjeg prostora zgrade) verzije 3.0. BISDM je razvoj općenitijeg BIM modela (Informacijski model zgrade) i namijenjen je za korištenje u projektiranju, izgradnji, radu i stavljanju izvan pogona zgrada i građevina. Korišten u GIS softveru, omogućuje vam učinkovitu razmjenu geopodataka s drugim platformama i interakciju s njima. Pripada općoj skupini FM poslova (upravljanje organizacijskom infrastrukturom). Nabrojimo glavne prednosti BISDM modela čija uporaba omogućuje:

• organizirati razmjenu informacija u heterogenom okruženju prema jedinstvenim pravilima;
• dobiti “fizičko” utjelovljenje BIM koncepta i preporučenih pravila za upravljanje građevinskim projektom;
• održavati jedinstveni repozitorij korištenjem GIS-a tijekom cijelog životnog ciklusa zgrade (od projektiranja do razgradnje);
• koordinirati rad različitih stručnjaka na projektu;
• vizualizirati utvrđeni raspored i faze izgradnje za sve sudionike;
• dati preliminarnu procjenu troškova i vremena izgradnje (4D i 5D podaci);
• pratiti napredak projekta;
• osigurati visokokvalitetni rad zgrade, uključujući održavanje i popravke;
• postati dio sustava upravljanja imovinom, uključujući funkcije za analizu učinkovitosti korištenja prostora (zakup, skladišni prostor, upravljanje zaposlenicima);
• provoditi proračune i upravljati zadacima energetske učinkovitosti zgrade;
• simulirati kretanje ljudskih tokova.

BISDM definira pravila za rad s prostornim podacima na razini unutarnjih prostora u zgradi, uključujući namjenu i vrste korištenja, postavljene komunikacije, instaliranu opremu, računovodstvo za popravke i održavanje, slučajeve sječe, odnose s drugom imovinom tvrtke. Model pomaže u stvaranju jedinstvenog repozitorija geografskih i negeografskih podataka. Iskustva vodećih svjetskih tvrtki korištena su za identifikaciju entiteta i modeliranje na razini geobaze prostornih i logičkih odnosa svih fizičkih elemenata koji tvore kako samu zgradu tako i njen interijer. Slijeđenje načela BISDM-a može značajno pojednostaviti zadatke integracije s drugim sustavima. Prva faza je obično CAD integracija. Zatim se tijekom rada zgrade koristi razmjena podataka s ERP i EAM sustavima (SAP, TRIRIGA, Maximo i dr.).

Vizualizacija BISDM strukturnih elemenata korištenjem ArcGIS-a.

U slučaju korištenja BISDM-a, kupac/vlasnik objekta dobiva end-to-end razmjenu informacija od ideje o izradi objekta do izrade cjelovitog projekta, kontrolu izgradnje uz zaprimanje up- ažurne informacije do trenutka puštanja objekta u pogon, kontrolu parametara tijekom rada, pa čak i tijekom rekonstrukcije ili razgradnje objekta. Slijedeći BISDM paradigmu, GIS i geobaza stvorena uz njegovu pomoć postaju zajednički repozitorij podataka za povezani sustavi. Geobaza podataka često sadrži stvorene i iskorištene podatke sustavi trećih strana. To se mora uzeti u obzir pri projektiranju arhitekture sustava koji se stvara.

U određenoj fazi, akumulirana "kritična masa" informacija omogućuje vam prelazak na novu kvalitativnu razinu. Na primjer, po završetku faze projektiranja nove zgrade, u GIS-u je moguće automatski vizualizirati pregledne 3D modele, sastaviti popis ugrađene opreme, izračunati kilometre instalirane komunalne mreže, izvršiti niz provjera pa čak i dati preliminarna financijska procjena troškova projekta.

Napomenimo još jednom da kada se BISDM i ArcGIS koriste zajedno, postaje moguće automatski konstruirati 3D modele koristeći akumulirane podatke, budući da geobaza sadrži potpuni opis objekta, uključujući z-koordinate, pripadnost katu, vrste veza elemenata, načina ugradnje opreme, materijala, pristupačnih staza kretanja osoblja, funkcionalne namjene svakog elementa itd. i tako dalje. Treba uzeti u obzir da nakon početnog uvoza svih projektnih materijala u BISDM geobazu, postoji potreba za dodatnim informacijskim sadržajem za:

• postavljanje 3D modela objekata i opreme na za to predviđena mjesta;
• prikupljanje informacija o troškovima materijala i postupku njihovog polaganja i ugradnje;
• kontrola prometa na temelju dimenzija ugrađene nestandardne opreme.

Korištenje ArcGIS-a pojednostavljuje uvoz dodatnih 3D objekata i referentnih knjiga iz vanjski izvori, jer Modul ArcGIS Data Interoperability omogućuje vam stvaranje procedura za uvoz takvih podataka i njihovo ispravno postavljanje unutar modela. Podržani su svi formati koji se koriste u industriji, uključujući IFC, AutoCAD Revit, Bentlye Microstation.

IBM-ovi industrijski modeli podataka

IBM nudi skup alata i modela za upravljanje pohranom za različita područja aktivnosti:

• IBM Bankarstvo i skladište podataka financijskih tržišta (financije)
• IBM bankovno skladište podataka
• IBM bankovni proces i modeli usluga
• IBM Health Plan podatkovni model (zdravstvo)
• IBM Insurance Information Warehouse (osiguranje)
• IBM proces osiguranja i modeli usluga
• IBM Retail Data Warehouse (maloprodaja)
• IBM Telecommunications Data Warehouse (telekomunikacije)
• InfoSphere Warehouse Pack:
  - za Customer Insight (za razumijevanje kupaca)
  - za uvid u tržište i kampanju (za razumijevanje tvrtke i tržišta)
  - za Supply Chain Insight (za razumijevanje dobavljača).

Na primjer, model IBMBankarstvoiFinancijskiTržištaPodaciSkladište osmišljen je za rješavanje specifičnih problema bankarske industrije iz podatkovne perspektive i IBMBankarstvoPostupakiServisModeli- sa stajališta procesa i SOA (uslužno orijentirana arhitektura). Predstavljeni modeli za telekomunikacijsku industriju IBMInformacijaOkvir (IFW) I IBMTelekomunikacijaPodaciSkladište (TDW). Oni pomažu značajno ubrzati proces stvaranja. analitički sustavi, kao i smanjiti rizike povezane s razvojem aplikacija za poslovnu analizu, korporativnim upravljanjem podacima i organizacijom skladišta podataka, uzimajući u obzir specifičnosti telekomunikacijske industrije. Mogućnosti IBM-a TDW pokrivaju cijeli spektar tržišta telekomunikacijskih usluga - od pružatelja internetskih usluga i operatora kabelske mreže koji nude usluge žične i bežične telefonije, prijenosa podataka i multimedijskog sadržaja, do multinacionalnih kompanija koje pružaju telefonske, satelitske, međugradske i međunarodne komunikacije, kao i organizacije globalne mreže. Danas se TDW koristi za velike i male žičane i bežična komunikacijaŠirom svijeta.

Alat tzv InfoSphere Warehouse Pack za Customer Insight pruža strukturiran poslovni sadržaj jednostavan za implementaciju za sve veći broj poslovnih projekata i industrija, uključujući bankarstvo, osiguranje, financije, zdravstvene planove, telekomunikacije, maloprodaju i distribuciju. Za poslovne korisnike InfoSphere Warehouse Pack za uvid u tržište i kampanju pomaže u povećanju učinkovitosti aktivnosti analize tržišta i marketinških kampanja kroz proces razvoja korak po korak i uzimajući u obzir specifičnosti poslovanja. Pomoću InfoSphere Warehouse Pack za uvid u lanac opskrbe organizacije mogu dobiti aktualne informacije o operacijama opskrbnog lanca.

Položaj Esrija unutar IBM-ove arhitekture rješenja.

IBM-ov pristup elektroenergetskim i komunalnim tvrtkama zaslužuje posebnu pozornost. Kako bi zadovoljili rastuće zahtjeve kupaca, komunalne usluge zahtijevaju fleksibilniju arhitekturu od one koja je trenutno u upotrebi, kao i industrijski standardni objektni model za olakšavanje slobodnog protoka informacija. To će poboljšati komunikacijske sposobnosti energetskih tvrtki, dopuštajući im isplativiju suradnju i dati novim sustavima veću vidljivost svih resursa koji su im potrebni, bez obzira gdje se nalaze unutar organizacije. Temelj za ovaj pristup je SOA (service-oriented architecture), komponentni model koji uspostavlja korespondenciju između funkcija odjela i usluga različitih aplikacija koje se mogu ponovno koristiti. "Usluge" takvih komponenti razmjenjuju podatke putem sučelja bez krutog povezivanja, skrivajući od korisnika svu složenost sustava koji stoje iza njih. U ovom načinu rada poduzeća mogu jednostavno dodavati nove aplikacije bez obzira na dobavljača softvera, operativni sustav, programski jezik ili drugo unutarnje karakteristike PO. Koncept je implementiran na temelju SOA-e SIGURNO ( Arhitektura rješenja za energiju omogućuje komunalnim poduzećima da dobiju holistički pogled na svoju infrastrukturu temeljen na standardima.

Esri ArcGIS® je međunarodno priznata softverska platforma za geografske informacijske sustave (GIS), koja omogućuje stvaranje i upravljanje digitalnom imovinom električne energije, transporta plina, distribucije i telekomunikacijskih mreža. ArcGIS vam omogućuje provođenje najcjelovitijeg popisa komponenti elektrodistribucijske mreže, uzimajući u obzir njihov prostorni položaj. ArcGIS značajno proširuje IBM SAFE arhitekturu pružajući alate, aplikacije, tijekove rada, analitiku i mogućnosti integracije informacija potrebnih za upravljanje pametnim uslužnim programom. ArcGIS unutar IBM SAFE-a omogućuje vam dobivanje informacija iz različitih izvora o infrastrukturnim objektima, imovini, klijentima i zaposlenicima s točnim podacima o njihovoj lokaciji, kao i stvaranje, pohranjivanje i obradu geo-referenciranih informacija o imovini poduzeća (nosači, cjevovodi, žice, transformatori, kabelski kanali itd.). ArcGIS unutar SAFE infrastrukture omogućuje vam dinamičku integraciju osnovnih poslovnih aplikacija kombiniranjem podataka iz GIS-a, SCADA-e i sustava korisničke službe s vanjske informacije, poput količine prometa, vremenskih uvjeta ili satelitskih slika. Komunalna poduzeća koriste takve kombinirane informacije u razne svrhe, od S.O.R. (opća slika operativne situacije) prije pregleda objekata, Održavanje, mrežna analiza i planiranje.

Informacijske komponente poduzeća za opskrbu energijom mogu se modelirati pomoću nekoliko razina, koje su rangirane od najniže - fizičke - do najviše, najsloženije razine logike poslovnih procesa. Ovi se slojevi mogu integrirati kako bi zadovoljili tipične industrijske zahtjeve, kao što su automatizirano bilježenje mjerenja i nadzorna kontrola i kontrola prikupljanja podataka (SCADA). Izgradnjom SAFE arhitekture, komunalna poduzeća poduzimaju značajne korake prema unaprjeđenju otvorenog objektnog modela u cijeloj industriji koji se zove Zajednički informacijski model (CIM) za energetiku i komunalne usluge. Ovaj model pruža neophodan temelj mnogim poduzećima za prelazak na arhitekturu usmjerenu na usluge jer potiče korištenje otvorenih standarda za strukturiranje podataka i objekata. Osiguravanjem da svi sustavi koriste iste objekte, zbrka i neelastičnost povezana s različitim implementacijama istih objekata bit će svedeni na minimum. Na taj način definicija subjekta kupca i drugih važnih poslovnih subjekata bit će objedinjena u svim komunalnim sustavima. Uz CIM, pružatelji usluga i potrošači sada mogu dijeliti zajedničku strukturu podataka, što olakšava outsourcing skupih poslovnih komponenti jer CIM uspostavlja zajedničku bazu na kojoj se može graditi razmjena informacija.

Zaključak

Sveobuhvatni industrijski podatkovni modeli tvrtkama pružaju jedinstveni, integrirani pogled na njihove poslovne informacije. Mnogim tvrtkama je teško integrirati svoje podatke, iako je to preduvjet za većinu projekata na razini poduzeća. Prema studiji The Data Warehousing Institute (TDWI), više od 69% anketiranih organizacija otkrilo je da je integracija značajna prepreka za usvajanje novih aplikacija. Naprotiv, integracija podataka tvrtki donosi opipljive prihode i povećanu učinkovitost.

Pravilno izgrađen model nedvosmisleno definira značenje podataka, koji su u ovom slučaju strukturirani podaci (za razliku od nestrukturiranih podataka kao što su slika, binarna datoteka ili tekst, gdje značenje može biti dvosmisleno). Najučinkovitiji industrijski modeli su oni koje nude profesionalni dobavljači, uključujući Esri i IBM. Visoki povrati od korištenja njihovih modela postižu se zahvaljujući njihovoj značajnoj razini detalja i točnosti. Obično sadrže mnogo atributa podataka. Osim toga, Esri i IBM ne samo da imaju veliko iskustvo u modeliranju, već su i dobro upućeni u izradu modela specifičnih za industriju.