Koncept skladišta podataka
"Skladište podataka" je domenski specifična, vremenski ograničena i nepromjenjiva kolekcija podataka za podršku procesu donošenja upravljačkih odluka.
Podaci u skladištu dolaze iz operativnih sistema (OLTP sistemi), koji su dizajnirani za automatizaciju poslovnih procesa. Osim toga, skladište se može dopuniti iz vanjskih izvora, na primjer, statističkih izvještaja, raznih referentnih knjiga itd. Pored detaljnih informacija, skladište podataka sadrži agregate, tj. sumiranje informacija kao što su iznosi prodaje, količine, ukupni troškovi, itd.
Skladište poreznih podataka treba posmatrati kao informativni centar u kojem se automatizira obračun odgođenih poreza, primaju i pohranjuju informacije iz vanjskih izvora, a podaci se pretvaraju u format prilagođen korisniku. Takav repozitorij pruža platformu za pohranjivanje tačnih i pravovremenih poreznih podataka koji se mogu dohvatiti i prenijeti na eksterne aplikacije za potrebe analize, revizije, planiranja i predviđanja.
Skladište podataka je repozitorijum informacionih resursa i obezbeđuje konsolidaciju podataka preduzeća za potrebe izveštavanja i analize. Podaci i informacije, kako operativni tako i neoperativni, unose se u skladište, obično pomoću ETL alata iz izvora, podataka kako postanu dostupni ili redovno. Transformacija podataka vam omogućava da zahtjeve obrađujete i analizirate na vrijeme, što pojednostavljuje i ubrzava proces ispunjavanja zahtjeva za informacijama koje su izvorno primljene iz drugih izvora.
Prednosti skladištenja uključuju mogućnost transformacije podataka u kvalitetne informacije potrebne za pripremu poresko izvještavanje i usklađenost sa porezom, za korisnike svih nivoa. Bilo koji dionik - kupci, partneri, zaposleni, menadžeri i rukovodioci - mogu primiti interaktivni sadržaj bilo kada i bilo gdje.
Samo postojanje jedinstvenog izvora informacija za pripremu poreskih izvještaja i poštivanje poreskih obaveza veliki je korak naprijed za mnoge porezne organe.
Zašto trebate graditi skladišta podataka - na kraju krajeva, oni sadrže očigledno suvišne informacije, koje se već nalaze u bazama podataka ili datotekama operativnih sistema? Nemoguće je ili veoma teško direktno analizirati podatke operativnih sistema. To je zbog različitih razloga, uključujući fragmentaciju podataka i njihovo skladištenje u formatima različitih DBMS-a. Ali čak i ako su u preduzeću svi podaci pohranjeni na centralnom serveru baze podataka, analitičar gotovo sigurno neće razumjeti njihove složene, ponekad zbunjujuće strukture.
Dakle, zadatak repozitorija je da na jednom mjestu iu jednostavnoj, razumljivoj strukturi obezbijedi "sirovine" za analizu.
Postoji još jedan razlog koji opravdava pojavu zasebnog skladišta - složeni analitički upiti za operativne informacije usporavaju trenutni rad kompanije, dugo blokirajući tabele i oduzimajući serverske resurse.
Skladištenje nije nužno ogromna akumulacija podataka - najvažnije je da je pogodno za analizu.
Koncept skladišta podataka
Autor koncepta skladišta podataka ( Skladište podataka) je B. Inmon, koji je definirao skladišta podataka kao: "specifični za domen, integrirani, nepromjenjivi, historijski skupovi podataka organizirani u svrhu podrške menadžmentu" dizajnirani da djeluju kao "jedan i jedini izvor istine" koji menadžerima i analitičarima pruža pouzdane informacije neophodna za operativnu analizu i donošenje odluka. Šema skladišta podataka može se predstaviti na sljedeći način:
Fizička implementacija ove šeme može biti vrlo raznolika. Razmotrimo prvu opciju - virtuelno skladište podataka, ovo je sistem koji omogućava pristup konvencionalnom sistemu za snimanje koji emulira rad sa skladištem podataka. Virtuelna pohrana se može organizirati na dva načina. Možete kreirati niz "pogleda" u bazi podataka ili koristiti specijalnim sredstvima pristup bazi podataka (na primjer, desktop OLAP proizvodi).
Budući da je izgradnja skladišta podataka složen proces koji može potrajati nekoliko godina, neke organizacije umjesto toga grade podatkovne vitrine koje sadrže informacije za određene odjele. Na primjer, baza marketinških podataka može sadržavati samo informacije o kupcima, proizvodu i prodaji, a ne uključivati planove nabavke. Više odeljenskih baza podataka može koegzistirati sa osnovnim skladištem podataka, pružajući delimičan prikaz sadržaja skladišta. Vitrine podataka se grade znatno brže od skladišta, ali kasnije mogu uzrokovati ozbiljne probleme integracije ako početno planiranje nije obavljeno s punim poslovnim modelom na umu. Ovo je drugi način.
Izgradnja potpunog skladišta podataka preduzeća obično se radi u troslojnoj arhitekturi. Na prvom nivou nalaze se različiti izvori podataka - sistemi internog snimanja, sistemi pomoći, eksterni izvori (podaci novinske agencije, makroekonomski pokazatelji). Drugi nivo sadrži centralni repozitorij, gde se prikupljaju informacije iz svih izvora sa prvog nivoa, i, eventualno, operativno skladište podataka koje ne sadrži istorijske podatke i obavlja dve glavne funkcije.
Koncept skladišta podataka zasniva se na dvije osnovne ideje:
1) integraciju prethodno nepovezanih detaljnih podataka u jedinstveno skladište podataka, njihovo usklađivanje i, eventualno, agregaciju:
· Istorijski arhivi;
· Podaci iz tradicionalnih ODS;
· Podaci iz eksternih izvora.
2) razdvajanje skupova podataka koji se koriste za operativnu obradu i skupova podataka koji se koriste za rješavanje problema analize.
Svrha koncepta skladišta podataka je da se saznaju zahtjevi za podacima koji se nalaze u ciljnoj bazi podataka skladišta podataka (Tabela 1), da se utvrde opći principi i faze njegove izgradnje, glavni izvori podataka, da se daju preporuke. o tome kako riješiti potencijalne probleme koji nastaju prilikom njihovog istovara, čišćenja, koordinacije, transporta i utovara u ciljnu bazu podataka.
Tabela 1. Osnovni zahtjevi za podatke u skladištu podataka.
| Predmetna orijentacija | Svi podaci o određenom subjektu (poslovnom objektu) se prikupljaju (obično iz skupa). raznih izvora), očišćeni, usaglašeni, dopunjeni, agregirani i predstavljeni u jednom, prikladnom obliku za njihovu upotrebu u poslovnoj analizi. |
| Integracija | Svi podaci o različitim poslovnim objektima međusobno su konzistentni i pohranjeni u jednom korporativnom skladištu. |
| Nepromenljivost | Originalni (istorijski) podaci, nakon što su dogovoreni, verificirani i uneseni u korporativno skladište, ostaju nepromijenjeni i koriste se isključivo u načinu čitanja. |
| Podrška za vremensku liniju | Podaci su hronološki strukturirani i odražavaju istoriju tokom dovoljnog vremenskog perioda da se dovrše zadaci poslovne analize i predviđanja. |
Koncept skladišta podataka su sami podaci. Nakon što se tradicionalni sistem za obradu podataka (DDS) implementira i počne funkcionirati, on postaje potpuno isti nezavisni objekt stvarnog svijeta, kao i svaki proces proizvodnje... A podaci, koji su jedan od finalnih proizvoda takve proizvodnje, imaju potpuno ista svojstva i karakteristike kao i svaki industrijski proizvod: rok trajanja, mjesto skladištenja (skladištenja), kompatibilnost sa podacima iz drugih industrija (ODS), tržišnu vrijednost, prenosivost , kompletnost, održivost itd.
Sa ove tačke gledišta se razmatraju podaci u skladištima podataka. Odnosno, cilj ovdje nisu načini opisivanja i prikazivanja objekata. predmetna oblast, već sami podaci, kao samostalni objekt predmetne oblasti, nastali kao rezultat funkcionisanja prethodno kreiranih informacionih sistema.
Za ispravno razumevanje Ovaj koncept zahtijeva razumijevanje sljedećih osnovnih tačaka:
· Koncept skladišta podataka nije koncept analize podataka, već je koncept pripreme podataka za analizu.
· Koncept skladišta podataka ne predodređuje arhitekturu ciljnog analitičkog sistema. Govori o tome koji procesi treba da se obavljaju na sistemu, ali ne i o tome gde tačno i kako se ti procesi trebaju izvoditi.
· Koncept skladišta podataka ne uključuje samo jedan logički pogled na podatke organizacije, već implementaciju jednog integrisanog izvora podataka.
Osim toga objedinjeni priručnik metapodaci, sredstva za istovar, agregaciju i usaglašavanje podataka, koncept skladišta podataka podrazumijeva: integraciju, nepromjenjivost, podršku povijesti i konzistentnost podataka. A ako prva dva svojstva (integracija i nepromjenjivost) utiču na načine analize podataka, onda posljednja dva (podrška povijesti i konzistentnost) značajno sužavaju listu analitičkih zadataka koje treba riješiti.
Bez podrške hronologije (prisustva istorijskih podataka), nemoguće je govoriti o rješavanju problema predviđanja i analize trendova. Ali najkritičnija i najbolnija pitanja su ona koja se odnose na usklađivanje podataka.
Glavni zahtjev analitičara nije toliko efikasnost koliko pouzdanost odgovora. Ali kredibilitet je na kraju određen dosljednošću. Dok se ne radi na međusobnom usaglašavanju vrijednosti podataka iz različitih izvora, teško je govoriti o njihovoj pouzdanosti.
Često se menadžer suočava sa situacijom u kojoj različiti sistemi mogu dati i obično dati različite odgovore na isto pitanje. To može biti zbog asinhrone prirode momenata modifikacije podataka, razlika u interpretaciji istih događaja, pojmova i podataka, promjena u semantici podataka u procesu razvoja predmetne oblasti, elementarnih grešaka prilikom unosa i obrade podataka. , djelomični gubitak pojedinačnih fragmenata arhive i sl. Očigledno nije realno uzeti u obzir i unaprijed odrediti algoritme za rješavanje svih mogućih kolizija. Štaviše, nerealno je to učiniti unutra režim rada, dinamički, direktno u procesu formiranja odgovora na zahtjev.
Slične informacije.
Imajte na umu da je skladištenje podataka tehnologija koja se razvija. Što se tiče bilo kojeg razvoj tehnologije, određen stepen opreza treba biti prisutan kada se procjenjuju postupci proizvođača HD softvera koji pokušavaju da se pozicioniraju među konkurentima. Na primjer, rasprave o veličini HD-a - od koje veličine skladište podataka može li se smatrati samim skladišnim objektom? Sa 50 GB? Imajte na umu da u nekim područjima istraživanja veličina analiziranog niza može biti vrlo mala. Jednostavno nema podataka. I analiza takvog niza je moguća.
Razmotrimo glavne elemente koncepta skladištenja podataka.
Ekstrahovanje podataka iz operativnih sistema
Osnovni element koncepta skladištenja podataka je da se najefikasniji pristup podacima koji se čuvaju za analizu može obezbijediti samo ako su odvojeni od operativnog (transakcionog) sistema, tj. podaci iz operativnog sistema moraju se premjestiti u poseban sistem za skladištenje podataka... Ovaj pristup je historijske prirode. Zbog ograničenja u hardveru i tehnologiji, kako bi se osigurale performanse transakcionog sistema, podaci su arhivirani na magnetne trake ili medije van takvog sistema. Problem pristupa njima zahtijevao je određena tehnološka rješenja.
Treba napomenuti da je razvojem koncepta pozicija odvajanja podataka za analizu od podataka u OLTP sistemu pretrpjela nekoliko promjena. Postala je formalnija i obogaćena korištenjem sredstava multivarijantna analiza podaci. Trenutno se HD može graditi na postojećem OLTP sistemu, a iznad njega i kao samostalan objekat. O tome treba odlučiti menadžer IT projekta kao dio izbora HD arhitekture.
Potreba za integracijom podataka iz više OLTP sistema
Sistemi za skladištenje podataka najkorisniji kada se podaci mogu preuzeti iz više od jednog OLTP sistema. Kada se podaci prikupljaju iz više poslovnih aplikacija, prirodno je pretpostaviti da bi to trebalo biti učinjeno na drugoj lokaciji od one na kojoj su originalne aplikacije lokalizirane. Čak i prije stvaranja strukturiranog HD-a, analitičari su u mnogim slučajevima kombinovali podatke izvučene iz različiti sistemi, u jednu tabelu ili bazu podataka. HD može vrlo efikasno objediniti podatke iz specifičnih aplikacija kao što su prodaja, marketing, finansije, proizvodnja, uzimajući u obzir njihovu akumulaciju, tj. sačuvati vremensku seriju ključnih poslovnih indikatora - takozvane istorijske podatke.
Imajte na umu da je jedno od svojstava podataka prikupljenih iz različitih aplikacija i koje koriste analitičari mogućnost unakrsnog ispitivanja tih podataka. U mnogim CD-ovima, atribut "vrijeme" je prirodni kriterij za filtriranje podataka. Analitičare zanima ponašanje vremenskih serija podataka koji karakteriziraju poslovne procese.
Cilj mnogih sistemi za skladištenje je pregled aktivnosti tipa "godina za godinom". Na primjer, možete uporediti prodaju u prvom kvartalu ove godine sa prodajom u prvom kvartalu prethodnih godina. Vrijeme u HD je osnovni atribut unakrsni upiti... Na primjer, analitičar bi mogao pokušati procijeniti uticaj nove marketinške kampanje kroz koju prolazi određenim periodima kada se razmatraju prodaja za iste periode. Sposobnost uspostavljanja i razumijevanja korelacije između aktivnosti različitih odjela u organizaciji često se navodi kao jedan od najvažnijih argumenata o koristima. sistemi za skladištenje.
Sistem za skladištenje podataka ne samo da može raditi kao efikasna platforma za konsolidaciju podataka iz različitih izvora, već može i prikupljati više verzija podataka iz jedne aplikacije. Na primjer, ako je organizacija prešla na novi softver, tada će CD sačuvati potrebne podatke sa prethodni sistem... U tom pogledu sistem za skladištenje podataka može poslužiti kao sredstvo za integraciju naslijeđenih podataka, uz održavanje kontinuiteta analize prilikom promjene softverske i hardverske platforme OLTP sistema.
Razlike između transakcijske i analitičke obrade podataka
Jedan od najvažnijih razloga za odvajanje podataka za analizu od OLTP podataka bila je potencijalna degradacija performansi upita prilikom izvođenja procesa analize podataka. Visoke performanse i kratko vrijeme odziva su kritični parametri OLTP sistema. Gubitak performansi i dodatni troškovi povezani s obradom unaprijed definiranih upita obično je lako procijeniti. S druge strane, upite za analizu podataka u DW-u je teško predvidjeti, a samim tim i procijeniti vrijeme izvršenja upita.
OLTP sistemi su dizajnirani da optimalno izvršavaju unapred definisane upite u skoro realnom vremenu. Za takve sisteme obično možete odrediti distribuciju opterećenja tokom vremena, odrediti vrijeme vršnog opterećenja, procijeniti kritične upite i primijeniti na njih procedure optimizacije koje podržavaju moderni DBMS-ovi. Takođe je relativno lako odrediti maksimum dozvoljeno vreme odgovoriti na konkretan zahtjev u sistemu. Trošak vremena odgovora na takav zahtjev može se procijeniti na osnovu omjera cijene izvođenja I/O operacija/troška cijene mrežnog prometa. Na primjer, za sistem obrade narudžbi, možete odrediti broj aktivnih menadžera naplata i prosječan broj narudžbi za svaki sat rada.
Iako su mnogi upiti i izvještaji u sistem za skladištenje podataka su unapred definisani, gotovo je nemoguće tačno predvideti ponašanje sistemskih indikatora (vreme odziva, mrežni saobraćaj, itd.) kada se izvrše. Proces istraživanja podataka u HD-u često je nepredvidiv. Lideri svih rangova su vješti u postavljanju neočekivanih pitanja. U toku analize mogu se javiti ad hoc upiti, koji su uzrokovani neočekivanim rezultatima ili nerazumijevanjem korišćenog modela podataka od strane krajnjeg korisnika. Nadalje, mnogi procesi analize imaju tendenciju da uzmu u obzir mnoge aspekte poslovanja organizacije, dok su OLTP sistemi dobro segmentirani prema aktivnostima. Korisniku će možda trebati više detaljne informacije od onoga što je pohranjeno u sažetim tabelama. To može dovesti do spajanja dvije ili više ogromnih tablica, što rezultira privremenom tablicom jednakom proizvodu broja redova u svakoj tabeli i dramatično degradirajući performanse sistema.
Podaci u sistemima za skladištenje podataka ostaju nepromijenjeni
Još jedno ključno svojstvo podataka u sistem za skladištenje podataka sastoji se u tome da podaci na CD-u ostaju nepromijenjeni. To znači da nakon što se podaci stave na CD, ne mogu se mijenjati. Na primjer, status naloga se ne mijenja, veličina naloga se ne mijenja itd. Ova karakteristika CD-a je od velikog značaja za odabir tipova podataka prilikom njihovog postavljanja na CD, kao i izbor trenutka kada bi podaci trebali biti uneseni na CD. Posljednje svojstvo se zove granularnost podataka.
Razmotrite šta znači da podaci budu nepromjenjivi. U OLTP sistemu, objekti podataka prolaze kroz stalne promjene svojih atributa. Na primjer, narudžba može promijeniti svoj status mnogo puta prije nego što bude poslata. Ili, kada se proizvod sastavlja na montažnoj traci, na njega se primjenjuju mnogi proizvodni koraci. Uopšteno govoreći, podatke iz OLTP sistema potrebno je učitati u sistem za skladištenje podataka tek kada je njihova obrada u okviru poslovnih procesa u potpunosti završena. To može značiti završetak narudžbe ili ciklusa proizvoda. Kada se narudžba završi i pošalje, malo je vjerovatno da će promijeniti njen status. Ili, kada se proizvod sklopi i preda u skladište, malo je vjerovatno da će završiti u prvoj fazi ciklusa sklapanja.
Drugi dobar primjer na CD-u može postojati smještaj snimka podataka koji se stalno mijenjaju u određenim vremenskim trenucima. OLTP modul za kontrolu inventara može promijeniti inventar u gotovo svakoj transakciji; nemoguće je sve ove promjene snimiti na CD. Možete odrediti da se takav snimak stanja zaliha unosi u CD svake sedmice ili dnevno, na način koji bi bio prikladan za analizu u određenoj organizaciji. Podaci takvog snimka su, naravno, nepromjenjivi.
Nakon unosa podataka u CD, njihova izmjena je moguća u izuzetno rijetkim slučajevima. Vrlo je teško (iako ima takvih pokušaja) održavati dinamičke podatke na CD-u. Zadatak sinhronizaciječesto mijenjani podaci u OLTP sistemima i još uvijek je daleko od prihvatljivog rješenja. Ovdje također treba napomenuti da je smještaj dinamički promjenjivih podataka na CD-u trenutno predmet intenzivnog istraživanja. Na primjer, razvoj procedura za podršku sporo promjenjivim tablicama dimenzija u HD je zadatak koji već nalazi svoje rješenje na softverskom nivou proizvođača rješenja iz oblasti HD.
Podaci u skladištu podataka se čuvaju mnogo duže nego u OLTP sistemima
Većina OLTP sistema arhivira podatke čim postanu neaktivni. Na primjer, nalog može postati neaktivan nakon što je završen; bankovni račun može postati neaktivan nakon što je zatvoren. Glavni razlog za arhiviranje neaktivnih podataka je performanse OLTP sistema (zašto čuvati podatke ako im se ne pristupa). Velike količine takvih podataka mogu značajno smanjiti performanse upita, pod pretpostavkom da se obrađuju samo aktivni podaci. Za obradu takvih podataka, DBMS nudi različite procedure za podelu osnovnih tabela na sekcije. S druge strane, budući da su CD-ovi namijenjeni, posebno, da budu arhiva za OLTP podatke, podaci se na njima pohranjuju veoma dugo.
U stvari, projekat sistemi za skladištenje može započeti bez ikakvog specifičnog plana za arhiviranje podataka sa CD-a. Troškovi održavanja podataka nakon što se učitaju u pohranu su niski. Najveći trošak kreiranja repozitorija pada transformacija podataka(prijenos podataka) i njihovo čišćenje (pročišćavanje podataka). Zadržavanje podataka pet godina ili više je tipično za sistemi za skladištenje... Stoga se procedurama arhiviranja podataka sa CD-a u fazama njihovog stvaranja i rada na početku perioda ne može posvetiti mnogo vremena. Pogotovo kada se uzme u obzir pad cijena kompjuterskog hardvera.
Drugim riječima, odvajanje OLTP podataka od podataka analize je fundamentalni koncept u skladištu podataka. Danas je poslovanje nemoguće bez donošenja informiranih odluka. Ovakva rješenja mogu se izgraditi na osnovu sveobuhvatne analize rezultata implementacije poslovnih procesa u organizaciji i aktivnosti organizacije na tržištu roba i usluga. Vrijeme donošenja odluka u savremenim uslovima i tokovima informacija se smanjuje. Uloga kreiranja i održavanja sistemi za analizu podataka baziran na novom informacione tehnologije povećava. HD je jedna od glavnih karika u primjeni ovakvih tehnologija.
Može se razlikovati sledećih razloga za dijeljenje podataka sistemi za skladištenje i operativni sistemi za obradu podataka(sl. 1.5).
- Razlika u ciljnim zahtjevima za i OLTP sisteme.
- Potreba za prikupljanjem podataka na CD-u iz različitih izvora informacija, tj. ako se podaci generiraju u samom OLTP sistemu, onda za sistemi za skladištenje u većini slučajeva podaci se generiraju izvan njega.
- Kada podaci dođu na CD, u većini slučajeva ostaju nepromijenjeni.
- Podaci na CD-u se pohranjuju dugo vremena.
Rice. 1.5.
OLTP logička transformacija podataka i modeliranje podataka
Podaci na CD-u se logički transformišu kada se na njega prenesu iz OLTP sistema ili drugog eksternog izvora. Problemi povezani sa logičkom transformacijom podataka prilikom njihovog prenošenja u skladište podataka mogu zahtevati značajnu analizu i napore dizajnera. Arhitektura sistemi za skladištenje i HD modeli su ključni za uspjeh takvih projekata. U nastavku ćemo razmotriti neke fundamentalne koncepte relacijske teorije baza podataka, koji nisu u potpunosti primjenjivi na sistemi za skladištenje... Iako je većina CD-ova postavljena na relacijske baze podataka, neki od osnovnih principa relacijskih baza podataka se namjerno krše prilikom kreiranja logičkog i fizičkog modela CD-ova.
HD model podataka definira njegovu logičku i fizičku strukturu. Za razliku od jednostavno arhiviranih podataka, u ovom slučaju nemoguće je bez detaljnih procedura modeliranja. Takvo modeliranje u ranim fazama projektovanja skladišnog sistema neophodno je za stvaranje efikasnog sistema koji obuhvata podatke iz svih poslovnih procesa i procedura organizacije.
Proces modeliranja podataka treba strukturirati podatke na CD-u u obliku koji je nezavisan od relacioni model podatke sistema koji dostavlja podatke. Kao što je objašnjeno u nastavku, HD model će vjerovatno biti manje normalizovan od OLTP modela izvora podataka.
U OLTP sistemima, podaci u različitim podsistemima mogu se značajno preklapati. Na primjer, informacije o razvoju proizvoda koriste se u različitim oblicima u mnogim podsistemima OLTP sistema. Sistem za skladištenje podataka treba kombinovati sve takve podatke u jedan sistem. Neki od atributa objekta koji su bitni za OLTP sistem bit će nepotrebni za HD. Novi atributi se mogu pojaviti kako entitet na CD-u mijenja svoj kvalitet. Glavni uslov je da svi podaci na CD-u moraju učestvovati u procesu analize.
HD model podataka treba proširiti i strukturirati tako da se mogu dodati podaci iz različitih aplikacija. HD projekat u većini slučajeva ne može uključiti podatke iz svih mogućih poslovnih aplikacija organizacije. Obično se količina podataka na CD-u povećava postepeno: podaci se izvlače iz OLTP sistema i dodaju na CD u određenim dijelovima. Počinju pohranjivanjem posebno važnih podataka, a zatim po potrebi sistematski povećavaju njihov volumen.
Model skladišta podataka prilagođava se poslovnoj strukturi
Sljedeći važna tačka sastoji se u tome da je logički model HD prilagođen poslovnoj strukturi (fokusiran na predmetnu oblast), a ne agregaciji logičkih modela specifičnih aplikacija. Entiteti (objekti) podržani na CD-u slični su entitetima (objektima) poslovanja - kao što su kupci, proizvodi (roba), narudžbe i distributeri. Unutar specifičnih odjela organizacije može postojati vrlo uzak pogled na objekte poslovanja organizacije, na primjer, o kupcima. Na primjer, tim za servisiranje bankarskih kredita može znati nešto o klijentu samo u kontekstu jednog ili više izdatih kredita. Drugi odjel iste banke može znati za istog klijenta u kontekstu depozitni račun... Prezentacija podataka o klijentima na CD-u je mnogo veća nego u pojedinoj jedinici banke. Klijent u CD-u predstavlja klijenta banke u svim njegovim odnosima sa bankom. Sa stanovišta relacione teorije, osnovni skup funkcionalnih zavisnosti podržanih u bazi podataka se menja.
CD treba da bude izgrađen na atributima poslovnih subjekata (predmetno orijentisan), prikupljajući podatke o tim subjektima iz različitih izvora. Struktura podataka bilo kojeg pojedinačnog izvora podataka vjerovatno neće biti adekvatna za HD. O strukturi podataka specifičnu primjenu faktori kao što su:
- vrsta specifičnog poslovnog procesa. Dakle, unutra automatizovani podsistem struktura podataka o nabavkama može biti diktirana prirodom poslovnih procedura nabavke u datom tržišnom sektoru;
- uticaj modela operativni sistemi... Na primjer, izvorna aplikacija može biti prilično stara i uzeti u obzir razvoj modela podataka promjenom strukture baze podataka aplikacije. Mnoge od ovih promjena mogu biti loše dokumentirane;
- ograničenja softverske i hardverske platforme. Logička struktura podataka možda neće podržavati neke od logičkih odnosa između podataka ili može imati ograničenja zbog ograničenja hardverske i softverske platforme.
HD model nije vezan ograničenjima modela izvornih podataka. Za to treba razviti model koji odražava strukturu poslovanja organizacije, a ne strukturu poslovnog procesa. Takve prošireni model podaci moraju biti razumljivi i analitičarima i menadžerima. Dakle, CD dizajner mora prilagoditi CD objekte poslovnoj strukturi organizacije, uzimajući u obzir njene poslovne procese i poslovne procedure.
Konverzija informacija koje opisuju stanje objekata u OLTP sistemu
Sljedeća važna stvar je da prije stavljanja podataka na HDD, oni moraju biti transformirani. Većina podataka iz OLTP sistema ili drugog eksternog izvora ne može biti podržana u HD-u. Mnogi atributi objekata u OLTP sistemu su vrlo dinamični i stalno se mijenjaju. Mnogi od ovih atributa se ne učitavaju na CD, dok su drugi atributi statični u vremenu i učitavaju se na CD. CD ne bi trebao sadržavati informacije o objektima koji su dinamični i stalno u stanju modifikacije.
Da biste razumjeli šta znači izgubiti informacije koje opisuju Trenutna drzava objekta, razmotrite primjer sistema upravljanja narudžbama koji prati status zaliha kako je narudžba ispunjena. Prvo, pogledajmo entitet Order u OLTP sistemu. Narudžba može proći kroz mnogo različitih statusa ili uvjeta prije nego što bude dovršena i stečena završen status... Status narudžbe može ukazivati da je spreman za ispunjavanje, da se narudžba ispunjava, vraća na reviziju, da je spremna za isporuku itd. Konkretna narudžba može proći kroz mnoga stanja, koja se odražavaju u statusu narudžbe i određena su poslovnim procesima koji su na njega primijenjeni. Praktično je nemoguće prenijeti sve atribute takvog objekta na CD. Sistem za skladištenje podataka vjerovatno bi trebao sadržavati samo jedan konačni snimak objekta kao što je narudžba. Dakle, objekat "Order" mora biti transformisan za postavljanje na CD. Zatim, na CD-u se mogu prikupiti informacije o mnogim objektima tipa "narudžba" i može se izgraditi konačni CD objekat, "Narudžba".
Pogledajmo složeniji primjer transformacija podataka prilikom upravljanja zalihama robe u OLTP sistemu. Zalihe se mogu mijenjati sa svakom transakcijom. Količina određenog proizvoda u skladištu može se smanjiti transakcijom podsistema za popunjavanje narudžbi ili povećati kada kupljeni proizvod stigne. Ako sistem za obradu narudžbi obavlja desetine hiljada transakcija dnevno, onda će stvarni nivo inventara u bazi podataka vjerovatno imati mnogo stanja i biće uhvaćen u mnogim snimcima tokom tog dana. Nemoguće je urezati sve ove trajne promjene u bazu podataka i prenijeti ih na CD. Prikaz takvog ponašanja objekta u sistemu – izvor podataka je još uvijek jedan od neriješenih problema u sistemi za skladištenje... Postoji nekoliko pristupa rješavanju ovog problema. Na primjer, možete povremeno snimati snimke nivoa zaliha na CD-u.
Ovaj pristup se može primijeniti na vrlo veliki dio podataka u OLTP sistemima. Zauzvrat, takvo rješenje će podrazumijevati niz zadataka koji se odnose na izbor vremenskog perioda, količinu podataka koje treba uzeti itd. Dakle, većina podataka o stanju objekata u OLTP sistemu ne može se direktno prenijeti na CD. Moraju se konvertovati na logičkom nivou.
Denormalizacija modela podataka
Sljedeća tačka u dizajnu relacijskih HD-ova je odlučiti koliko je važno u HD-u slijediti principe relacijske teorije, naime: omogućiti denormalizaciju modela, posebno, za povećanje performansi upita. Prije nego što pogledamo denormalizaciju modela podataka u kontekstu skladištenja podataka, prisjetimo se ukratko glavnih tačaka teorije relacijske baze podataka i proces normalizacije... E.F. Codd je razvio teoriju relacijske baze podataka kasnih 1960-ih dok je radio u IBM-ovom istraživačkom centru. Najpopularnije platforme baza podataka danas u potpunosti prate ovaj model. Model relacijske baze podataka je zbirka dvodimenzionalnih tabela koje se sastoje od redova i stupaca. U terminologiji relacionog modela, ove tabele, redovi i kolone se respektivno nazivaju relacije ili entiteti, tuple, atributi i domeni. Model identifikuje jedinstvene ključeve (Key) za sve tabele i opisuje odnos između tabela kroz vrednosti atributa (ključeva).
Normalizacija je proces modeliranja relacijske baze podataka u kojem se odnosi ili tabele razbijaju sve dok svi atributi u odnosu nisu potpuno određeni njegovim primarnim ključem. Većina dizajnera pokušava postići treći normalni oblik (3NF) u svim aspektima prije nego što budu denormalizirani iz jednog ili drugog razloga. Tri uzastopna koraka normalizacije relacionih baza podataka su ukratko opisana u nastavku.
- Prvi normalni oblik je 1NF (1NF). Za odnos se kaže da je u prvom normalnom obliku ako opisuje jedan jedini entitet i ne sadrži nizove ili ponavljajuće grupe vrijednosti kao atribute. Na primjer, tablica narudžbi koja uključuje stavke narudžbe neće biti u prvom normalnom obliku jer sadrži duple atribute za svaku stavku narudžbe.
- Drugi normalni oblik 2NF (2NF). Kažu da je stav in drugi normalni oblik ako je u prvom normalnom obliku i svi ne-ključni atributi su funkcionalno u potpunosti zavisni primarni ključ veze.
- Treći normalni oblik 3NF (3NF). Kažu da je stav in treći normalni oblik ako je unutra drugi normalni oblik a njegovi ne-ključni atributi su potpuno nezavisni jedan od drugog.
Proces normalizacije rezultira cijepanjem originalnog odnosa na nekoliko nezavisnih odnosa. Svaka relacija u bazi podataka odgovara najmanje jedan sto. Iako je relacijski model fleksibilniji u predstavljanju podataka, može biti složeniji i teže razumljiv. Takođe, potpuno normalizovan model može biti veoma neefikasan za implementaciju. Stoga dizajneri baze podataka pri pretvaranju normaliziraju logički model u fizičkom modelu omogućavaju značajnu denormalizaciju. Glavna svrha denormalizacije je ograničavanje spajanja među tabelama u upitima.
Drugi razlog za denormalizaciju HD modela su, kao i kod operativnih sistema, performanse i jednostavnost. Svaki upit u relacijskoj bazi podataka ima performanse troškova. Troškovi izvršenja upita su veoma visoki u DW-u zbog količine podataka obrađenih u upitu (i spajanja tabela, koja rastu proporcionalno veličini modela). Spajanje tri male tabele u OLTP sistem može imati prihvatljivu cenu za izvršenje upita, ali u sistem za skladištenje podataka može potrajati jako dugo da se uspostavi takva veza.
Statički odnosi u istorijskim podacima
Denormalizacija je važan proces u HD modeliranju: odnos između atributa se ne mijenja za historijske podatke. Na primjer, u OLTP sistemima, stavka može biti dio drugog "A" proizvoda ovog mjeseca i dio "B" proizvoda sljedećeg mjeseca. U normaliziranom modelu podataka, da biste prikazali ovu činjenicu, morate uključiti atribut "grupa proizvoda" u odnos (entitet) "proizvod", ali ne i u odnos (entitet) "narudžba", koji generiše narudžbe za ovaj proizvod. Entitet narudžbe uključuje samo identifikator artikla. Relaciona teorija bi zahtijevala spajanje između tablica Narudžba i Stavka kako bi se definirala grupa stavki i drugi atributi za tu stavku. Ova činjenica ( funkcionalna zavisnost) je irelevantno za CD, jer se sačuvani podaci odnose na već izvršene narudžbe, tj. pripadnost proizvoda grupi je već fiksirana (u stvari, navedena funkcionalna zavisnost nije podržana). Čak i ako je predmet pripadao različite grupe u različito vrijeme, odnos između grupe proizvoda i proizvoda svake pojedinačne narudžbe je statičan. Dakle, ovo nije denormalizacija za HD. U ovom slučaju, funkcionalna zavisnost OLTP sistema se ne koristi u HD.
Uzmite cijenu artikla kao još jedan primjer. OLTP cijene su podložne stalnim promjenama. Neke promjene ovih cijena mogu se prenijeti na CD, kao periodični snimci tabele "Cijena proizvoda". U CD-u je istorija cjenovnika robe fiksna i već je vezana za narudžbe, tj. ne morate dinamički određivati cjenik prilikom obrade narudžbe, jer je već primijenjen na spremljenu narudžbu. U relacionim bazama podataka lakše je održavati dinamičke odnose između poslovnih subjekata, dok CD sadrži odnose između subjekti u predmetu u datom trenutku.
Koncept logička transformacija aplikacije izvora podataka, o kojima smo gore govorili, zahtijevaju određeni napor u implementaciji i vrlo su korisni u razvoju HD-a.
Fizička transformacija izvornih podataka aplikacije
Važna tačka u sistemi za skladištenje je fizička transformacija podataka. Ove procedure u skladištu podataka poznate su kao procesi čišćenja podataka, stadijuma podataka ili čišćenja podataka. Proces čišćenja podataka je najintenzivniji i najzahtjevniji u bilo kojem projektu kreiranja CD-a. Fizička transformacija uključuje korištenje standardnih termina HD domena i standarda podataka. Tokom procesa fizičke transformacije, podaci se nalaze u nekom međufajlu prije nego što se unesu u CD. Kada se podaci prikupljaju iz mnogih aplikacija, njihov integritet se može provjeriti tokom procesa generiranja transformiranih podataka prije nego što se učitaju u HD.
Uslovi i nazivi atributi entiteta koji se koriste u OLTP sistemima, u procesu konverzije podataka za CD, pretvaraju se u univerzalne, standardni uslovi prihvaćeno za ovu poslovnu oblast. Aplikacije mogu koristiti skraćenice ili teško razumljive termine iz mnogo različitih razloga. Platforma uređaja može ograničiti dužinu i format imena, a poslovne aplikacije mogu koristiti generičke termine u različitim domenima. U HD-u je potrebno koristiti standardne poslovne pojmove koji su sami po sebi razumljivi većini korisnika.
Identifikator kupca (kupca) u OLTP sistemu može biti nazvan "Kupiti.", "Kupiti_id" ili "Kupiti_ne". Nadalje, različite aplikacije takvih sistema mogu koristiti različita imena (sinonime) kada se odnose na isti atribut entiteta. HD dizajner bira jednostavan, standardni poslovni termin kao što je ID korisnika. Dakle, imena atributi entiteta iz sistema napajanja moraju biti objedinjeni za upotrebu u CD-u.
Različiti podsistemi OLTP sistema i eksterni izvori podataka mogu koristiti različite definicije domena atributa na fizičkom prezentacijski sloj... Dakle, atribut tipa "identifikator proizvoda" u jednom sistemu ima dužinu od 12 znakova ili više, au drugom - 18 znakova. S druge strane, softver nekih postojećih sistema može imati ograničenja u definiciji dužine imena atributa i loš skup tipova za definiranje domena, dok u drugima takva ograničenja mogu izostati i može biti širok izbor tipova atributa. obezbeđeno.
Prilikom definisanja atributa u fizičkom modelu podataka potrebno je u definiciji domena atributa koristiti takve dužine i tipove podataka, koji bi uzeli u obzir kako zahtjeve domena, tako i mogućnosti sistema - izvora podataka. Definiranje standarda domena za CD-ove jedan je od važnih zadataka CD dizajnera. Pravila za transformaciju domena atributa sistema - izvora podataka u domene atributa CD-a treba da budu zabeležena u metapodacima CD-a.
Svi atributi na CD-u trebaju dosljedno koristiti unaprijed definirane vrijednosti. Različite aplikacije mogu imati različite konvencije za unaprijed definirane vrijednosti atributa. Ove unaprijed definirane vrijednosti uključuju zadane vrijednosti, null-zamjenske vrijednosti i tako dalje. Na primjer, spol u različiti sistemi mogu imati različita značenja: u nekima su to simboličke vrijednosti "M" i "F", u drugima - digitalne vrijednosti 0 i 1. Neprijatniji primjer je slučaj kada se jedna vrijednost podataka koristi u aplikacija za više namjena, tj. atribut zapravo predstavlja množinu vrijednost. Na primjer, kada je u atributu "vrsta metode mjerenja", prve dvije cifre označavaju metodu mjerenja, a druge dvije - fizičku kontrolu mjerenja. Takve različite vrijednosti moraju se pretvoriti u unaprijed definiranu vrijednost prihvaćenu na CD-u prije nego što se učitaju na CD.
Neki sistemi izvora podataka mogu imati vrijednosti koje nedostaju (nedostaju podaci) ili se ne mogu konvertirati (oštećeni podaci). Važno je da tokom procesa konverzije takvi podaci poprime vrijednosti u podatkovnom listu koje bi omogućile korisnicima da ih pravilno interpretiraju. Nekim atributima se jednostavno može dodijeliti razumna zadana vrijednost u nedostatku vrijednosti ili u sukobima konverzije, a drugi atributi se mogu zaključiti iz vrijednosti drugih atributa. Na primjer, u entitetu Narudžbe pretpostavimo da je vrijednost atributa jedinice mjere izostavljena. Ova vrijednost se može dobiti iz odgovarajućeg atributa entiteta "Proizvod" ovog izvornog sistema. Neki atributi nemaju odgovarajuće zadane vrijednosti kada nedostaju vrijednosti. Za takve vrijednosti koje nedostaju, DD bi također trebao definirati zadanu vrijednost, na primjer, kao nultu vrijednost.
Glavne razlike u korištenju podataka u
Želja da se kombinuju mogućnosti OLTP sistema i sistema analize u jednoj DSS arhitekturi dovela je do pojave koncepta XraniltražimdannasX (HD).
O konceptu HD-a su na ovaj ili onaj način raspravljali stručnjaci iz oblasti informacija
macionim sistemima dugo vremena. Pojavili su se prvi članci posebno posvećeni HD-u
1988. od B. Devlina i P. Murphyja. 1992. W. Inmon je detaljno opisao ovaj koncept u svojoj monografiji "Izgradnja skladišta podataka" (drugo izdanje - QED Publishing Group, 1996).
Koncept CD-a zasniva se na ideji razdvajanja podataka za koje se koriste
operativnu obradu i za rješavanje problema analize. Ovo vam omogućava da primijenite strukture podataka koje ispunjavaju zahtjeve za skladištenje za korištenje u OLTP sistemima i sistemima za analizu. Ovo razdvajanje vam omogućava da optimizujete i strukture podataka onlajn skladištenja (online baze podataka, datoteke, tabele, itd.) za obavljanje operacija unosa, modifikacije, brisanja i pretraživanja, kao i strukture podataka koje se koriste za analizu (za izvođenje analitičkih upita). U DSS-u se ove dvije vrste podataka nazivaju shodno tome. O P e R a T i v n s m i i With T O h n i To a m i d a nna X (OID) i XRanitiliSCHemdannsX.
Inmon je u svom radu dao sljedeću definiciju HD.
X ra niti l i SCH e d a n n s X -predmetno orijentisan, integrisan,
Nepromjenjivi istorijski skup podataka organiziran u svrhu podrške odlučivanju.
Razmotrimo svojstva HD-a detaljnije.
PRjedinicemeTnoh ohrienTaqiJa sam. Ovo je fundamentalna razlika između HD-a i OID-a.
Različiti OID-ovi mogu sadržavati podatke koji opisuju istu predmetnu oblast sa različitih stajališta (na primjer, sa stanovišta računovodstva, računovodstva skladišta, odjela za planiranje, itd.). Odluka donesena na osnovu samo jednog gledišta može biti neefikasna ili čak pogrešna. HD omogućava integraciju informacija koje odražavaju različite tačke gledišta na jednu predmetnu oblast.
Objektna orijentacija vam također omogućava da na CD pohranite samo one podatke koji
potrebni su za njihovu analizu (npr. za analizu nema smisla pohranjivati podatke o brojevima kupoprodajnih dokumenata, dok je njihov sadržaj – količina, cijena prodatog proizvoda – neophodan). Ovo značajno smanjuje troškove medija za skladištenje i povećava sigurnost pristupa podacima.
InTegraqija sam. OID-ove, po pravilu, razvija nekoliko timova u različito vrijeme sa vlastitim alatima. To dovodi do činjenice da podaci koji odražavaju isti objekt stvarnog svijeta u različitim sistemima ga različito opisuju. Obavezna integracija podataka u CD omogućava vam da riješite ovaj problem dovođenjem podataka u jedan format. ByddeRfToaXROnologii. Podaci u OID-u su potrebni za obavljanje operacija nad njima u trenutnom trenutku. Stoga možda nisu vremenski ograničeni. Za analizu podataka, često je važno biti u mogućnosti pratiti istoriju promjena u metrikama domene. Stoga, svi podaci pohranjeni na CD-u moraju odgovarati uzastopnim vremenskim intervalima. Neigmenja samemoWithTb. OID zahtjevi nameću vremenska ograničenjapohranjivanje podataka u njih. Oni podaci koji nisu potrebni za operativnu obradu, po pravilu se uklanjaju iz OID-a kako bi se smanjili utrošeni resursi. S druge strane, analiza zahtijeva podatke za najveći mogući vremenski period. Stoga, za razliku od OID-a, podaci na CD-u se čitaju tek nakon učitavanja. Ovo vam omogućava da značajno povećate brzinu pristupa podacima, kako zbog moguće redundantnosti pohranjenih informacija, tako i zbog isključenja operacija modifikacije.
Kada se koncept CD-a implementira u DSS, podaci iz različitih OID-ova se kopiraju u centralnu memoriju. Prikupljeni podaci se svode na jedan format, koordiniraju i generaliziraju, a analitički zahtjevi se upućuju na CD (Sl. 1).
Ovaj model neizbježno dovodi do dupliciranja informacija u OID-u i na CD-u.
Međutim, Inmon u svom radu tvrdi da je redundantnost podataka pohranjenih u
DSS, ne prelazi 1%! Ovo se može objasniti sljedećim razlozima.
Prilikom učitavanja informacija sa OID-a na CD, podaci se filtriraju. Mnogi od njih ne spadaju u HD, jer su besmisleni sa stanovišta njihove upotrebe u postupcima analize.
Informacije u OID-u su po pravilu operativne prirode, a podaci su izgubljeni
relevantnost se briše. Nasuprot tome, CD pohranjuje istorijske informacije. Sa ove tačke gledišta, dupliranje sadržaja CD-a podacima OID-a ispada sasvim beznačajno. CD sadrži generalizovane informacije kojih nema u OID-u.
Tokom učitavanja na CD, podaci se brišu (brišu se nepotrebne informacije), i
nakon takve obrade zauzimaju mnogo manji volumen.
Ulazni podsistem (OLTP)
P o d s i s t e m
Analitički upiti
P o d s i s t e m
O
Ulazni podsistem (OLTP)
i analize
RiWithatnOTo7. DSS struktura sa fizičkim CD-om
Redundantnost informacija može se svesti na nulu korištenjem virtualnog CD-a. U ovom slučaju, za razliku od klasičnog (fizičkog) CD-a, podaci iz OID-a se ne kopiraju u jednu memoriju. Oni se preuzimaju, transformišu i integrišu direktno prilikom izvođenja analitičkih upita u RAM-u računara. U stvari, takvi zahtjevi se direktno upućuju OID-u (slika 2). Glavne prednosti virtuelnog HD-a su:
minimiziranje količine memorije koju zauzimaju informacije na nosaču; raditi o t i sa t e s u u m i, d e t l is i r o v i d d d d.Ulazni podsistem (OLTP)
Ulazni podsistem (OLTP)
Ulazni podsistemi
Podsistem za skladištenje informacija
Analitički upiti
podsistem analize (OLAP,
O
V i rt u a ln o e
R i With at n O To 8. P r u c t u ra S PP R s v i rt u al n y m X D
Međutim, ovaj pristup ima mnogo nedostataka.
Vrijeme obrade zahtjeva za virtualni disk je mnogo veće od odgovarajućeg
Odgovarajući indikatori za fizičko skladištenje Pored toga, strukture onlajn baza podataka, dizajnirane za intenzivno ažuriranje pojedinačnih zapisa, su visoko normalizovane. Da bi se izvršio analitički upit, veliki broj tabela mora biti spojen, što također dovodi do degradacije performansi.
Integrisani prikaz virtuelne memorije moguć je samo ako je ispunjen uslov stalne dostupnosti svih OID-ova. Dakle, privremena nedostupnost barem jednog od izvora može dovesti ili do neuspjeha analitičkog upita ili do netačnih rezultata.
Izvođenje složenih analitičkih upita na OID-ovima zahtijeva značajne računarske resurse. To dovodi do smanjenja performansi OLTP sistema, što je neprihvatljivo, jer je vrijeme izvršenja operacija u takvim sistemima često vrlo kritično.
Različiti OID-ovi mogu podržavati različite formate podataka i kodiranja. Često
može se dobiti više odgovora na isto pitanje. Ovo može biti zbog:
asinhroni momenti ažuriranja podataka u različitim OID-ovima; razlike u opisu identičnih objekata i događaja predmetnog područja; greške u kucanju; gubitak fragmenata arhivske građe itd.U ovom slučaju, cilj - formiranje jedinstvenog konzistentnog pogleda na kontrolni objekt - možda neće biti postignut.
Glavni nedostatak virtuelnog skladištenja je praktičan
nemogućnost dobijanja podataka u dužem vremenskom periodu. U nedostatku fizičke memorije, dostupni su samo podaci koji se nalaze u OID-u u trenutku zahtjeva. Osnovna namena OLTP sistema je onlajn obrada aktuelnih podataka, tako da nisu fokusirani na skladištenje podataka na duži vremenski period. Čim zastare, podaci se učitavaju u arhivu i brišu iz operativne baze podataka.
Uprkos prednostima fizičkog CD-a u odnosu na virtuelni, on je neophodan
priznati da je njegova implementacija prilično naporan proces.
Hajde da se zadržimo na glavnim problemima stvaranja CD-a:
potreba za integracijom podataka iz heterogenih izvora uzatvoreno okruženje;
potreba za efikasnim skladištenjem i obradom veoma velikih količina informacija; potreba za višerazinskim direktorijumima metapodataka; Opovećani zahtjevi za sigurnost podataka. Razmotrite ova pitanja više
detaljno.
NeoXOdimoWithTbinTegraqiidannupsisneOdnOROdnupsiWithTOhNickovvRaWith- itdhranalennOhWithRhrana. CD-ovi su kreirani da integrišu podatke koji mogu doći iz heterogenih OID-ova koji se fizički nalaze na različitim računarima: baze podataka, elektronske arhive, javni i komercijalni elektronski katalozi, referentne knjige, statističke zbirke. Prilikom kreiranja CD-a potrebno je riješiti problem konstruiranja sistema koji funkcionira u skladu sa heterogenim softverskim alatima i rješenjima. Prilikom odabira alata za implementaciju CD-a potrebno je uzeti u obzir mnoge faktore, uključujući nivo kompatibilnosti različitih softverskih komponenti, jednostavnost njihovog razvoja i upotrebe, efikasnost funkcionisanja itd.
ByTRebnOWithTbvehffeToTivnohmXRanenitiiiObRaboTToeOštanbbolbwiXobemovinfORmacii. Svojstvo nepromjenjivosti CD-a pretpostavlja akumulaciju informacija na njemu u dužem vremenskom periodu, što bi trebalo biti podržano stalnim povećanjem volumena disk memorije. Orijentacija ka izvršavanju analitičkih upita i pridružena normalizacija podataka dovode do nelinearnog povećanja količine memorije koju zauzima CD sa povećanjem količine podataka. Istraživanje pomoću TPC-D benchmark-a pokazalo je da baze podataka veličine 100 GB zahtijevaju memoriju 4,87 puta veću od količine potrebne za pohranjivanje podataka o korisnom teretu.
NeoXOdimoWithTb mnOGOURovnevanWithitdavohNickov meTadannsX. Za analizu sistema, dostupnost razvijenih metapodataka (podataka o podacima) i načina njihovog dostavljanja krajnjim korisnicima jedan je od osnovnih uslova za uspješnu implementaciju CDM-a.Metapodaci su neophodni kako bi korisnici DSS-a razumjeli strukturu informacija, o na osnovu kojih se donosi odluka. Na primjer, prije nego što korporativni menadžer postavi sistemu svoje pitanje, on mora razumjeti koje su informacije dostupne, koliko su relevantne, može li im se vjerovati, koliko dugo može biti potrebno da se formira odgovor, itd. Prilikom kreiranja CD-a potrebno je riješiti problem pohranjivanja i praktičnog predstavljanja metapodataka korisnicima.
PovswenitieTRebobanitithTobezoPaWithnOWithTidannsX. Okupljeni i sa-
Konzistentne informacije o istoriji razvoja korporacije, njenim uspesima i neuspesima, odnosima sa dobavljačima i kupcima, istoriji i stanju tržišta omogućavaju analizu prošlih i sadašnjih aktivnosti korporacije i izradu prognoza za budućnost. Očigledno je da su takve informacije povjerljive i pristup im je ograničen unutar same kompanije, a da ne govorimo o nekim drugim kompanijama. Da bi se osigurala sigurnost podataka, potrebno je riješiti pitanja autentifikacije korisnika, zaštite podataka prilikom premještanja u skladište
podaci iz operativnih baza podataka i eksternih izvora, zaštita podataka prilikom njihovog prenosa preko mreže itd.
Smanjenje troškova izrade CD-a može se postići kreiranjem pojednostavljenog
opcija - data mart.
V i T R in a d a n nas X (VD) - ovo je pojednostavljena verzija CD-a koja sadrži samo temu
spojeni podaci.
VD je što bliže krajnjem korisniku i sadrži podatke,
tematski usmjeren na to (na primjer, VD za zaposlene u odjelu marketinga može sadržavati podatke potrebne za marketinšku analizu). VD je znatno manje zapremine od HD, a njegova implementacija ne zahtijeva velike troškove. Mogu se implementirati kako samostalno, tako i zajedno sa CD-om.
Nezavisni VD (Slika 3) se često pojavljuju u organizaciji istorijski i nalaze se u velikim organizacijama sa velikim brojem nezavisnih odeljenja koje rešavaju sopstvene analitičke zadatke.
VD dizajn za odgovaranje na određeni niz pitanja; brza implementacija autonomnog vazdušnog saobraćaja i dobijanje povratka; pojednostavljenje procedura za popunjavanje VD i povećanje njihove produktivnosti uzimajući u obzir potrebe određenog kruga korisnika.Ulazni podsistem (OLTP)
Ulazni podsistem (OLTP)
Podsistem za skladištenje informacija
Analitički upiti
Analitički upiti
podsistem analize (OLAP,
P o d s i s t e m
O
Ulazni podsistem (OLTP)
i analize
RiWithatnOTo9. DSS struktura sa nezavisnim VD
Nedostaci autonomnih VD-a su:
višestruko skladištenje podataka u različitim VD-ovima, što dovodi do povećanja troškova skladištenja i potencijalnih problema povezanih s potrebom održavanja konzistentnosti podataka; nedostatak konsolidacije podataka na nivou predmetne oblasti, ali,dakle - odsustvo jedne slike.
Nedavno se pojavila ideja o kombinovanju HD i VD in
jedan sistem. U ovom slučaju, CD se koristi kao jedini izvor integrisanih podataka za sve VD (slika 4).
HD je jedinstven centralizirani izvor informacija za cijelo predmetno područje,
organizirano da pruži informacije o tematskim dijelovima date oblasti. Krajnji korisnici imaju mogućnost da pristupe detaljnim podacima u skladištu ukoliko nema dovoljno podataka u marketu, kao i da dobiju potpuniju informacijsku sliku.
Prednosti ovog pristupa su:
jednostavnost kreiranja i popunjavanja VD-a, budući da se popunjavanje odvija iz jednog standardizovanog pouzdanog izvora očišćenih podataka - sa CD-a; jednostavnost proširenja DSS-a dodavanjem novih VD-ova; OPTEREĆENJE SMANJENJE OPTEREĆENJA H DUlazni podsistem (OLTP)
Podsistem za skladištenje informacija
Analitički upiti
P o d s i s t e m
O
Ulazni podsistem (OLTP)
Ulazni podsistem (OLTP)
ANALITIČKA
HD zahtjevi
VD
i analize
podsistem analize (OLAP,
RiWithatnOTo10. DSS struktura sa HD i VD
Nedostaci uključuju:
redundantnost (podaci se pohranjuju i na CD i na VD); dodatni troškovi za razvoj DSS-a sa HD i VD.Sumirajući analizu načina implementacije DSS-a koristeći koncept CD-a, mogu se razlikovati sljedeće arhitekture takvih sistema:
DSS sa fizičkim (klasičnim) HD (vidi sliku 1); DSS sa virtuelnim CD-om (vidi sliku 2); DSS sa VD (vidi sliku 3); DSS sa fizičkim HD i sa VD (slika 4).U slučaju arhitektura sa fizičkim CD-om i/ili VD-om, treba obratiti pažnju
organizacija (arhitektura) CD-a i prijenos podataka sa OID-a na WCD.
Forrester Research je uočio da se većina velikih kompanija suočava sljedeći problem: akumuliraju se velika količina informacije koje se nikada ne koriste. U gotovo svakoj organizaciji zapravo funkcionira mnogo transakcionih sistema, fokusiranih na operativnu obradu podataka (svaki za određenu klasu zadataka) i kontinuirano dopunjavanje brojnih Baza podataka... Osim toga, preduzeća često posjeduju ogromne količine informacija pohranjenih u tzv. naslijeđenih sistema. Svi ovi podaci se distribuiraju preko mreža personalni računari pohranjeni su na glavnim računarima, radnim stanicama i serverima. Dakle, informacija ima, ali je disperzirana, nedosljedna, nestrukturirana, često suvišna i ne uvijek pouzdana. Stoga se u većini organizacija ovi podaci još uvijek ne mogu koristiti za donošenje kritičnih poslovnih odluka. Koncept skladišta podataka je usmjeren na rješavanje ove kontradikcije.
Autor koncepta Bill Inmon, u svom klasičnom članku Šta su skladišta podataka (D2K Incorporated, 1996.), definiše skladišta podataka kao „specifične za domen, integrisane, nepromenljive, istorijske skupove podataka organizovane da podrže upravljanje“. On posmatra repozitorije kao "jedan i jedini izvor istine", "centar univerzuma" sistema za podršku odlučivanju (DSS). „Iz skladišta podataka“, piše on, „informacije teku u različite odjele, filtrirajući se u skladu sa specificiranim DSS postavkama. Ove odvojene baze podataka za donošenje odluka se nazivaju vitrine podaci“.
Koncept skladišta podataka zasniva se na ideji kombinovanja korporativnih podataka rasutih po operativnim sistemima za obradu podataka, istorijskim arhivama i drugim eksternim izvorima. Ovi izvori mogu sadržavati podatke koji se ne koriste direktno u ODS-u, ali su od vitalnog značaja za DSS: zakonodavni okvir(uključujući poreske projekcije), razvojni planovi industrije, statistički podaci, elektronski imenici. Kao što praksa pokazuje, odluka donesena samo na osnovu internih podataka često se pokaže netačnom.
Svrha koncepta skladišta podataka je da se razjasne razlike u karakteristikama podataka u operativnim i analitičkim sistemima, da se utvrde zahtevi za podacima smeštenim u skladište, da se utvrde opšti principi i faze njegove izgradnje, glavni izvori podataka. , dati preporuke za rješavanje potencijalnih problema koji nastanu prilikom njihovog istovara, čišćenja, koordinacije, transporta i utovara u ciljnu bazu skladišta.
Poređenje karakteristika podataka u informacioni sistemi fokusiran na operativnu i analitičku obradu podataka
Karakteristično | Operating | Analitički |
Učestalost ažuriranja | Visoka frekvencija, u malim porcijama | Niska frekvencija, velike porcije |
Izvori podataka | Uglavnom interni | Uglavnom eksterno |
Pohranjene količine podataka | Stotine megabajta, gigabajta | Gigabajti i terabajti |
Data age | Aktuelno (za period od nekoliko mjeseci do jedne godine) | Aktuelni i istorijski (u periodu od nekoliko godina, desetina godina) |
Imenovanje | Fiksiranje, online pretraga i transformacija podataka | Čuvanje detaljnih i agregiranih istorijskih podataka, analitička obrada, predviđanje i modeliranje |
Osnovni zahtjevi za podatke u skladištu podataka
Predmetna orijentacija | Svi podaci o određenom subjektu (poslovnom objektu) se prikupljaju (obično iz više različitih izvora), čiste, usaglašavaju, dopunjuju, agregiraju i predstavljaju u jedinstvenom, prikladnom obliku za njihovu upotrebu u poslovnoj analizi. |
Integracija | Svi podaci o različitim poslovnim objektima međusobno su konzistentni i pohranjeni u jednom korporativnom skladištu |
Nepromenljivost | Početni (istorijski) podaci, nakon što su usaglašeni, provjereni i uneseni u generalni korporativno skladište, ostaju nepromijenjeni i koriste se isključivo u načinu čitanja |
Podrška za vremensku liniju | Podaci su hronološki strukturirani i odražavaju historiju u dovoljnom vremenskom periodu da se završe zadaci poslovne analize i predviđanja. |
Predmet koncepta skladišta podataka nije analiza podataka, već sami podaci, odnosno koncept njihove pripreme za dalju analizu. Istovremeno, koncept skladišta podataka ne definiše samo jedan logički pogled na korporativne podatke, već implementaciju jednog integrisanog izvora podataka.
Modeli analize podataka
Uprkos činjenici da je u konceptu skladišta podataka koji je formulisao B. Inmon, naglasak je na samim podacima i identifikaciji njihovih naj opšta svojstva, karakteristikama i odnosima, jasno je da ove podatke treba koristiti u procesu donošenja poslovnih odluka na svim nivoima, do korporativnog i interkorporativnog. Do danas su se istorijski formirala dva glavna modela analize podataka na kojima se zasnivaju postojeći analitički DSS:
1. Statička analiza(DSS). Sam koncept DSS (Decision Support Systems) zapravo je preveden kao DSS. To je donedavno bio jedini analitički koncept. Rezultat rada ovakvih sistema bili su strogo regulisani višestrani izveštaji, za čije su formiranje vršeni dugoročni upiti, obrađujući kolosalne količine podataka. Takvi zahtjevi mogu potrajati nekoliko sati, ponekad desetine sati ili čak dani.
2. Operativna analiza podataka (OLAP). Autor koncepta OLAP-a (On-Line Analytical Processing) je dr. E. Codd, koji je 1993. godine formulisao 12 osnovnih zahtjeva za sredstva implementacije OLAP-a. Osnovna razlika ovaj model iz tradicionalnog statičkog DSS-a je konceptualni prikaz podataka kao višedimenzionalne kocke. Istovremeno, E. Codd je pokazao potencijalne nedostatke relacionog pristupa u sistemima fokusiranim na analizu podataka. Svrha kreiranja ovog koncepta bila je fundamentalna mogućnost da se krajnjem korisniku obezbede sredstva za formiranje, obradu i izvršavanje ad hoc analitičkih upita sa minimalnim vremenom odziva sistema. Potreba za nastankom ovog novog koncepta bila je predodređena činjenicom da je analitičar često nakon dobijanja standardnog izveštaja putem DSS-a imao novo pitanje ili saznanje da je samo pitanje pogrešno formulisano. Kao rezultat toga, morao je ponovo dugo vremena sačekajte sljedeći rezultat da biste se onda, eventualno, vratili na sljedeću iteraciju ovog procesa.
Poređenje karakteristika statičke i dinamičke analize
Karakteristično | Statička analiza | Dinamička analiza |
Vrste pitanja | Koliko? Kako? Kada? | Zašto? Šta ako?.. |
Vrijeme odziva | Nije regulisano | |
Tipične operacije | Regulisani izvještaj, dijagram | Niz interaktivnih izvještaja, dijagrama, ekranske forme... Dinamički promijenite nivoe agregacije i isječke podataka. |
Nivo analitičkih zahtjeva | ||
Tip ekrana | Uglavnom unaprijed određeno, regulirano | Definisano od strane korisnika |
Nivo agregacije podataka | Detaljno i sažeto | Uglavnom kumulativno |
Data age | Istorijski i aktuelni | Istorijski, aktuelni i projektovani |
Vrste zahtjeva | Uglavnom predvidljivo | Nepredvidivo, povremeno |
Imenovanje | Regulisana analitička obrada | Multifunkcionalna analiza, modeliranje i predviđanje |
Danas je OLAP pravac, možda, najperspektivniji za rješavanje problema analitičkog upravljanja. Uz pomoć posebno kreiranog OLAP Report servisa, 12 zahtjeva koje je prvobitno formulirao dr. Codd djelimično su revidirani i značajno dopunjeni kako osnovnim tako i posebne prilike, kao što je odabir i obrada podataka koji nedostaju, itd. Ali ipak srž OLAP koncepta je multidimenzionalni prikaz podataka na konceptualnom nivou.
Data marts
Prema klasičnoj definiciji, Data Mart je podskup skladišta podataka koji odražava specifičnosti odjela (poslovnog objekta) i pruža povećana produktivnost... Dakle, izlog je karika na kojoj se nalazi specifično analitički sistem da riješe svoj niz zadataka. Ipak, moguće je da određeno područje aktivnosti poduzeća praktički ne korelira s drugim, te je moguće samostalno izgraditi odgovarajuću bazu podataka, bez vezivanja za korporativno skladište. Tada će se izlog puniti podacima direktno iz operativnih sistema za obradu transakcija. Takva tržišta podataka nazivaju se nezavisnim, za razliku od klasičnih baza podataka zavisnih od skladišta podataka i nadopunjavanja iz njega.
U nekim slučajevima, čini se preporučljivim da se postavi baza podataka umjesto potpuno formiranog skladišta. Satovi podataka su manje zahtjevni, jeftiniji i lakši za izgradnju, a temelje se na jeftinijim serverima, a ne na višeprocesorskim sistemima. Uz ovaj pristup, nema potrebe da se koristi cjelina informacioni sistem korporacije i podržavaju složene procedure za sinhrono ažuriranje baze podataka prilikom ažuriranja skladišta. Istovremeno, potrebno je shvatiti da se ovim pristupom, vitrine podataka mogu umnožiti u čitave komplekse nezavisnih informacionih baza podataka, i naravno da će se postaviti zadatak upravljanja pojedinačnim strategijama pretraživanja, održavanja i oporavka. S druge strane, izgradnja jedinstvenog korporativnog skladišta zasnovanog na mnogim nezavisnim bazama podataka je mnogo isplativija od oslanjanja na podatke razbacane po sistemima za obradu transakcija.
Dakle, šta je prikladno koristiti: objedinjena pohrana, nezavisna tržišta podataka, pohrana sa zavisnim bazama podataka ili druge opcije? Ne postoji univerzalni odgovor na pitanje o potrebi primjene ove ili one opcije. U svakom slučaju najbolja opcija je određena poslovnim zahtjevima, intenzitetom potražnje, mrežnom arhitekturom, potrebnim odzivom i drugim uslovima.
Tehnologija implementacije skladišta podataka
Prilikom kreiranja skladišta podataka, prirodno je držati se faznog razvoja. Unatoč činjenici da nijedan opis procesa izgradnje skladišta podataka u obliku niza faza ne može pokriti sve aspekte povratne informacije sa svojim potencijalnim korisnicima, menadžerima i analitičarima, međutim, postoje neki osnovni koraci koji se primjenjuju na proces izgradnje poslovne arhitekture:
1. Utvrđivanje potreba krajnjih korisnika i izgradnja modela poslovnih pitanja na koja je potrebno odgovoriti.
2. Identifikacija podataka iz korporativnih i eksternih izvora koji će napajati skladište ili baza podataka.
3. Analiza izvora podataka i modeliranje funkcija i procesa koje ti izvori pokrivaju. Učenje pravila po kojima posluje jedno je od njih bitni uslovi izgradnju skladišta podataka ili data marts, jer se na osnovu toga uspostavlja nivo detaljnosti elemenata u skladištu podataka.
4. Utvrđivanje procedura za transformaciju, čišćenje i logičku integraciju izvornih podataka prije njihovog stavljanja u skladište podataka ili baza podataka, kao i regulisanje implementacije ovih procedura kojima se ažurira skladište podataka.
5. Kreiranje metapodataka koji opisuju izvore i metode transformacije podataka i logiku skladišta podataka. Repozitorijum metapodataka treba da sadrži definicije podataka, poslovna pravila i detaljnu logiku za modeliranje razvoja analitičkih sistema.
6. Formiranje fizičkih tabela skladišta podataka i njegovo popunjavanje. Ovaj proces može trajati nekoliko iteracija, uzimajući u obzir mogući redizajn struktura podataka prilikom analize šeme podataka skladišta.
7. Izgradnja repozitorija baza podataka, koji će uključivati podskupove podataka iz skladišta i prethodno agregirane podatke. Neki od metapodataka će opisati kako se primarni podaci skladišta transformiraju, agregiraju i keširaju u prodajnim mjestima.
8. Instaliranje OLAP alata, aplikacijskih sistema, Web servera i svega neophodni alati i serverski programi potrebno za pristup podacima, analizu i izvještavanje.
9. Instalacija na radnim stanicama krajnjih korisnika klijenta softvera(Debeli klijent) ili pretraživači koji podržavaju standardne formate podataka i Java aplete, i potrebne ekstenzije plug-in ("tanki" klijent) za korisnički pristup podacima.
Nakon završetka procesa kreiranja skladišta podataka, može se činiti da je sve već urađeno. Naime, formiranje skladišta je proces koji uključuje i neophodne faze stalnog nadzora i održavanja skladišta podataka. Dobar nadzor uključuje ne samo održavanje ispravnosti podataka, već i osiguranje njihove tajnosti, posebno ako se podacima u spremištu pristupa putem weba. „Budući da skladište podataka sadrži jednu od najvećih sredstava u preduzeću“, kaže R. Tenler, predsednik Information Advantage-a, „podaci moraju biti sigurni. Ali da bi shvatila potencijalnu vrijednost skladišta podataka, organizacija će ga morati ponuditi potencijalnim kupcima.”
Održavanje skladišta podataka u dobrom stanju na duži rok je još jedan veliki izazov. Ovaj faktor postaje posebno važan kada broj korisnika koji pristupaju sistemu počne da raste. Štaviše, ako je u procesu dizajniranja skladišta podataka informacione usluge a temeljno pomirenje podaci, vremenom, pažnja ljudi obično slabi, a skladište podataka se može pretvoriti u smetlište. Da se to ne bi dogodilo, potrebno je imenovati odgovorne osobe za održavanje kvaliteta podataka, koje će kontinuirano provoditi verifikacija informacije primljene iz sistema za obradu transakcija, sa podacima u skladištu ili izlogu.
U zaključku, može se napomenuti da je proces projektovanja skladišta podataka korišten za pružanje potrebnih informacija u odlučivanje korporativni i međukorporativni nivo, ključan je za život preduzeća. U fazi njegove implementacije, morate obratiti pažnju ne samo na rješenje tehnička pitanja, ali i o problemima vezanim za ljudski faktor. Također ne smijemo zaboraviti na potrebu stalnog procjenjivanja izvodljivosti napora koji se ulažu. Pored pravilnog lanca upravljanja projektom, potrebno je u svakoj fazi voditi računa kako o potrebama korisnika, tako io prisutnosti političkih aspekata koji mogu usporiti projekat. Uz pravi pristup rješavanju ovog problema, skladište podataka bi uskoro moglo postati dio komercijalni sistem preduzeća dajući dijelu trećih korisnika uz određenu naknadu mogućnost korištenja podataka iz određenog podskupa skladišta. Ovaj pristup ne samo da će omogućiti da se nadoknadi rad na formiranju skladišta podataka, već će i osigurati novi kanal primanja prihoda.
