Čini se da je sada ušla tema razvoja skladišta podataka nova runda razvoj. Pojavljuju se nove tehnologije, pristupi i alati. Njihovo proučavanje, testiranje i razumna primjena omogućava nam da kreiramo zaista zanimljive i korisna rješenja... I dovedite ih u implementaciju, uživajući u činjenici da se vaši razvojni programi koriste pravi posao i korisni su.

Epilog

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

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

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

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

Oznake: Dodaj oznake

Zaitsev S.L., Ph.D.

Grupe koje se ponavljaju

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

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

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

Rice. 1.7. Model sveden na prvi normalna forma.

Jedna činjenica na jednom mestu

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

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

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

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

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

Svaki atribut zavisi od ključa

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

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

Odnosi mnogo-na-mnogo

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

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

Formalne definicije normalnih oblika

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

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

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

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

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

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

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

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

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

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

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

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

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

Normalni oblici poslovanja

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

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

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

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

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

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

Završen logički model podataka

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

Svi subjekti moraju imati nazive koji opisuju njihov sadržaj i imaju jasan, koncizan, Puni opis ili definicija. Buduća objava će pokriti početni set smjernica za ispravno formiranje naziva i opisa entiteta.

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

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

BILJEŠKA Pluralitet komunikacija opisuje maksimalan broj Sekundarne instance entiteta koje se mogu povezati s originalnom instancom entiteta.Nužnost postojanja ilimogućnost odsustva odnos se koristi za određivanje minimalnog broja instanci sekundarnog entiteta koji se može povezati sa instancom originalnog entiteta.

Fizički model podataka

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

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

Modelar podataka i administrator baze podataka (DBA) koriste logički model, zahtjeve korištenja i strateške principe da oblikuju korporativnu arhitekturu za razvoj. fizički model podaci. Možete denormalizirati fizički model kako biste poboljšali performanse i kreirali poglede koji podržavaju zahtjeve za korištenje. Sljedeći odjeljci detaljno opisuju proces denormalizacije i kreiranja pogleda.

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

Zahtjevi za prikupljanje podataka

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

Zahtjevi za pristup i performanse

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

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

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

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

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

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

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

Komponente modela fizičkih podataka

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

Obrnuti inženjering

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

Korištenje korporativnih funkcionalnih granica

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

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

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

Šta je model podataka preduzeća?

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

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

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

Izgradnja korporativnog modela podataka povećanjem

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

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

Koncept metodologije modeliranja

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

IDEF1X (Definicija integracije za informaciju Modeliranje – integrisani opis informacionih modela).

IE (Informacioni inženjering).

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

Integrirani opis informacionih modela

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

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

Informacioni inženjering

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

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

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

Zaključak

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

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

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

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

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

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

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

Svrha predavanja

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

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

i nauči da:

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

Model podataka preduzeća

Uvod

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

U poređenju sa dizajnom OLTP sistema, metodologija projektovanja za HD ima niz karakteristične karakteristike vezano za orijentaciju struktura podataka skladišta za rješavanje problema analize i informatička podrška proces donošenja odluka. Model podataka CD-a treba da obezbedi efikasno rešenje upravo ove zadatke.

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

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

Model podataka preduzeća

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

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

Glavni elementi korporativni model podataka su:

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

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

Nivoi prezentacije modela podataka preduzeća

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

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

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

Rice. 16.2.

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

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

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

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

Sa stanovišta HD dizajna važan faktor u odluci da kreirate CD model od korporativni model podataka je država potpunost korporativni model podataka.

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

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

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

Članak opisuje glavne arhitekture skladišta podataka, razmatra neke opšti principi njihovu konstrukciju. Metode za predstavljanje hijerarhija u relacionoj strukturi podataka su detaljno opisane.

Uvod

Početkom osamdesetih godina prošlog veka, u periodu naglog razvoja snimanja informacioni sistemi, došlo je do razumijevanja ograničenih mogućnosti njihove primjene za potrebe analize podataka i izgradnje na njihovoj osnovi sistema podrške i odlučivanja. Sistemi registracije su kreirani za automatizaciju rutinske operacije o poslovanju - fakturisanje, sastavljanje ugovora, provjera stanja skladišta i sl., a glavni korisnici ovakvih sistema bili su linijsko osoblje. Glavni zahtjevi za takve sisteme bili su osigurati transakcionu prirodu promjena i maksimizirati brzinu njihovog izvršenja. Upravo su ovi zahtjevi odredili izbor relacionog DBMS-a i modela prezentacije podataka entitet-relacija kao glavnih korištenih. tehnička rješenja prilikom izgradnje sistema za snimanje.

Za menadžere i analitičare, pak, bili su potrebni sistemi koji bi omogućili:

Očigledno, sistemi za snimanje nisu ispunili nijedan od gore navedenih zahtjeva. U sistemu registracije informacije su relevantne samo u trenutku pristupa bazi, u narednom trenutku za isti zahtjev možete dobiti potpuno drugačiji rezultat. Interfejs sistema za snimanje je dizajniran za izvođenje strogo definisanih operacija i mogućnost dobijanja rezultata za ad-hoc zahtjev je vrlo ograničena. Mogućnost obrade velikih količina podataka je također niska zbog podešavanja DBMS-a za obavljanje kratkih transakcija i neizbježnog usporavanja rada drugih korisnika.

Odgovor na ovu potrebu bila je pojava nova tehnologija organizacija baze podataka - tehnologija skladišta podataka.

Definicija i tipične arhitekture HD

Koncept skladišta podataka zasniva se na dvije glavne ideje - integraciji raščlanjenih detaljnih podataka (detaljnih u smislu da opisuju neke specifične činjenice, svojstva, događaje, itd.) u jedno skladište i razdvajanje skupova podataka i korištenih aplikacija za operativnu obradu i koristi se za rješavanje problema analize. Definicija pojma" skladište podataka"prvi je dao William G. Inmon u svojoj monografiji. U njoj je definirao skladište podataka kao" predmetno orijentirani, integrirani, povijesni podaci, neuništivi skup podataka dizajniran da podrži upravljačke odluke."

Konceptualno, model skladišta podataka može se predstaviti u obliku dijagrama prikazanog na slici 1. Podaci iz različitih izvora se nalaze na CD-u, a opisi ovih podataka u repozitorijum metapodataka. Krajnji korisnik, koristeći različite alate (vizuelizacija, izvještavanje, statistička obrada itd.) i sadržaje repozitorija, analizira podatke u skladištu. Rezultat njegove aktivnosti su informacije u obliku gotovih izvještaja, pronađeni skriveni obrasci, bilo kakva predviđanja. Od sredstava za rad krajnji korisnik Budući da skladište podataka može biti vrlo raznoliko, teoretski njihov izbor ne bi trebao utjecati na njegovu strukturu i funkcije održavanja ažurnog.

Fizička implementacija date konceptualne sheme može biti vrlo raznolika. Najčešći pristupi navedeni su u nastavku.

Virtuelno skladištenje podataka To je sistem koji predstavlja interfejse i metode pristupa sistemu za snimanje koji emuliraju rad sa podacima u ovom sistemu, kao i sa skladištem podataka. Virtuelno skladište podataka može se organizirati kreiranjem niza pogleda u bazi podataka ili korištenjem specijalnim sredstvima pristup, na primjer, proizvodima OLAP klase desktop računara, koji uključuju, na primjer, BusinessObjects, Brio Enterprise i druge.

Glavne prednosti ovog pristupa su:

Međutim, ima mnogo više nedostataka nego prednosti. Kreiranjem virtuelna pohrana podataka, ne stvarate skladište kao takvo, već iluziju njegovog postojanja. Struktura pohrane podataka i sama pohrana podataka ne trpi promjene, a problemi ostaju:

	Performanse;
	Transformacije podataka;
	Integracija podataka s drugim izvorima;
	Nedostatak istorije;
	Čistoća podataka;
	Ovisnost o dostupnosti glavne baze podataka;
	Ovisnost o strukturi glavne baze podataka.

Dvoslojna arhitektura Skladište podataka podrazumijeva izgradnju data mart bez stvaranja centralne memorije, dok informacije dolaze iz malog broja sistema za snimanje i ograničene su na određenu predmetnu oblast. Prilikom izgradnje baza podataka koriste se osnovni principi izgradnje skladišta podataka o čemu biće govor ispod, tako da se mogu smatrati minijaturnim skladištima podataka. Prednosti data mart-a su:

Izgradnja potpunog korporativnog skladišta podataka obično se obavlja u troslojna arhitektura(Treba napomenuti da ovdje troslojna arhitektura ne znači strukturu "DB - Server aplikacija - Klijent"). 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 centralno skladište podataka, odakle dolaze informacije iz svih izvora prvi nivo, a moguće i operativno skladište podataka (OSD). Operativno skladište ne sadrži istorijske podatke i obavlja dvije glavne funkcije. Prvo, to je izvor analitičkih informacija za operativno upravljanje i, drugo, ovdje se pripremaju podaci za naknadno učitavanje u centralno spremište. Priprema podataka se podrazumijeva kao njihova transformacija i provođenje određenih provjera. Prisustvo OSD-a je jednostavno neophodno uz različite propise za prijem informacija iz izvora. Treći nivo u opisanoj arhitekturi je skup domensko-specifičnih mart podataka, čiji je izvor informacija centralno skladište podataka. Većina krajnjih korisnika radi sa bazama podataka.

Projektovanje strukture relacionog skladišta podataka

HD su izgrađeni na bazi višedimenzionalnog modela podataka. Višedimenzionalni model podataka podrazumijeva odabir posebnih dimenzija (vrijeme, geografija, kupac, račun) i činjenica (obim prodaje, prihod, količina robe), koje se analiziraju prema odabranim dimenzijama. Višedimenzionalni model podataka može se fizički implementirati kako u višedimenzionalni DBMS tako iu relacijski. V poslednji slučaj izvodi se po uzorku "zvijezda" ili "pahulja". Ove sheme pretpostavljaju dodjelu tablica činjenica i tablica dimenzija. Svaka tabela činjenica sadrži detaljne podatke i strane ključeve za tabele dimenzija. Teorija konstruisanja višedimenzionalnog modela podataka i njegova implementacija u relacionu strukturu široko je obrađena u stranoj i domaćoj literaturi.

Među slabo obrađenim temama je i problem predstavljanja hijerarhija. Kao primjer mjerenja koja se široko koristi u analizi preduzeća i ima hijerarhijsku strukturu, možemo navesti imenik troškovnih stavki. Razmotrite model troškovnog centra (centara troškova) prikazan na slici 2.

Klasična informatika rješava problem predstavljanja hijerarhija korištenjem rekurzivne komunikacije. Ovo jednostavno rješenje vam omogućava da u jednu tabelu postavite stablo bilo koje dubine i dimenzije. U našem slučaju, podaci koji se razmatraju biće predstavljeni u sledećem obliku:

ID roditelja 1 Kompanija 2 Kontrola 3 Infrastruktura 4 Proizvodnja 5 6 Servis 7 Polje A 8 Polje B

Tabela 1.

Međutim, njegov glavni nedostatak krije se u jednostavnosti ovog rješenja. Nažalost, standardni SQL ne podržava rekurzivne pokazivače, tako da se druge metode koriste za predstavljanje stabala u HD-u.

Metoda koju je predložio Joe Celko temelji se na teoriji skupova. U ovoj metodi svi čvorovi stabla se prelaze direktnim redosledom prelaska i za svaki čvor se popunjavaju dve vrednosti - leva i desna granica, a za svaki čvor grane stabla prvi i jedini se popunjava leva granica zatim desno - pri povratku od potomaka do roditelja. Dakle, u našem primjeru, numeriranje čvorova će biti kako slijedi:

Sa ovim numerisanjem čvorova, svaki roditelj sadrži potomke, čije leve i desne granice leže u intervalu između leve i desne ivice roditelja. Isto tako, imaju svi roditelji djeteta lijeva granica koja je manja od lijeve granice djeteta i desna koja je veća od desne granice djeteta. Stoga se jednim zahtjevom može dobiti zbir troškova za određeno mjesto troškova i sve njegove komponente. Na primjer, da dobijete troškove infrastrukture, možete pokrenuti sljedeći SQL upit:

odaberite zbroj (fakt_tablica.cijena)
iz tabele_činjenica, tabele_dimenzija D1, tabele_dimenzija D2
gdje je tabela činjenica.dimenzija_id = D2.id
i D2.lijevo> = D1.lijevo
i D2.desno<= D1.right
i D1.name = "Infrastruktura"

Radi lakšeg rada sa takvom referencom, pored lijevog i desnog polja, dodajte još dva polja: "Level" - nivo čvora u stablu, "Is_leaf" - zastavica koja pokazuje da li je čvor list u drvo ili ne. Tako dobijamo tabelu "dimension_table" (vidi tabelu 2), koja vam omogućava da pohranite stablo bilo koje dubine i dimenzije i omogućava vam da izaberete decu i roditelje sa jednim upitom.

1 Kompanija 2 Kontrola 3 Infrastruktura 4 Proizvodnja 5 6 Servis 7 Polje A 8 Polje B

Tabela 2. Predstavljanje hijerarhija korištenjem lijeve i desne granice

Drugi način, koji je opisao Ralph Kimball, zasniva se na uvođenju tabele pomoćnika preko koje je tabela činjenica povezana sa tabelom dimenzija. Ova pomoćna tabela odražava hijerarhijsku strukturu dimenzije i pridržava se sljedećeg zakona: pomoćna tabela sadrži cijeli skup parova roditelj-dijete, a dijete možda nije neposredno dijete roditelja. Struktura takve tabele i njen sadržaj prikazani su u tabeli 3.

ID roditelja ID djeteta Razdaljina 1 1 1 1 1 1 1 1 2 2 0 Y 3 3 0 N 3 5 1 N 3 6 1 N 4 4 0 N 4 7 1 N 4 8 1 N 5 5 0 Y 6 6 0 Y 7 7 0 Y 8 8 0 Y

Tabela 3. Struktura i sadržaj pomoćne tabele.

Sada, povezivanjem tabele činjenica (vidi sliku 4) sa ID-om deteta u pomoćnoj tabeli i tabele dimenzija sa ID-om roditelja, možemo izračunati zbir troškova za svako mesto troškova i sve njegove sastavne delove jednim upitom , kao iu prethodnom slučaju. Istovremeno, dodavanjem ograničenja u polja "Distance" i "Is Leaf", možemo lako izračunati troškove za bilo koji nivo u hijerarhiji.

odaberite zbroj (fakt_tablica.cijena)
iz tabele činjenica, tabele_dimenzija, tabele_pomoćnika
gdje je fact_table.dimension_id = helper_table.child_id
i dimension_table.dimension_id = helper_table.parent_id
and dimension_table.name = "Infrastruktura"
i helper_table.distance = 1

Problem dizajniranja hijerarhijskih referenci je još složeniji kada dimenzija može imati nekoliko alternativnih hijerarhija i postaje prilično teško riješiti kada je potrebno održavati povijest promjena u tabeli dimenzija.

Općenito, problem sporo mijenjanja dimenzija zanimljiv je sam po sebi, a da ga ne komplikuje hijerarhijom klasifikatora. U literaturi se u većini slučajeva razmatra u kontekstu „činjenice – dimenzija koja se polako mijenja“. Zaista, ovaj zadatak se može riješiti relativno jednostavno dodavanjem datuma početka i datuma isteka zapisa u tablicu dimenzija. Promjena unosa u imeniku dovodi do "zatvaranja" starog unosa i dodavanja novog. Sada, vraćajući se na primjer reference stavke reda, korisnik koji želi dobiti informacije o trenutnoj stavci za bilo koji određeni datum mora je uključiti u uvjet SQL upita.

Pretpostavimo da je referenca stavke povezana sa referencom računovodstvenog računa. Jedan ili više računovodstvenih računa predstavljaju troškovnu stavku. Kako bi se promjena u bilo kojem atributu stavke trebala odraziti u referentnoj knjizi računovodstvenih računa? S jedne strane, sa stanovišta kontnog plana, promjenom atributa se ne mijenja entitet stavke, a računovodstveni unosi kroz kontni plan moraju se odnositi na istu stavku. S druge strane, pojavio se novi unos u direktoriju stavki, koji mora na neki način biti povezan s direktorijem računa. Ovaj problem se može riješiti podjelom tabele dimenzija na dvije – koja sadrži ažurirane informacije i sadrži povijest promjena entiteta. Ovaj pristup vam takođe omogućava da rešite problem hijerarhijske dimenzije uz potrebu održavanja istorije promena u zapisima u njoj.

Razmotrimo ga detaljnije (vidi sliku 5). Tablica "dimension_actual" je tabela dimenzija s primarnim ključem dimension_id koji sadrži ispravne atribute za današnju dimenziju. Istorijska tabela "dimension_history" je povezana s njom preko stranog ključa dimension_id, koji sadrži historiju promjena zapisa određene datumima početka/završetka valjanosti zapisa (datum_start, date_end). U njemu je prisutan i akt koji je ažuran sa otvorenim datumom isteka. Fakt_tablica je povezana sa tabelom dimenzija preko helper_table, što odražava hijerarhijska struktura mjerenja.

Opisani pristup omogućava: prvo, pohranjivanje i rad sa dimenzijom kao sa neuravnoteženim stablom; drugo, brzo izvršavanje upita za koje istorija promene dimenzije nije važna (tabela koja sadrži istoriju nije uključena); treće, omogućava vam da pratite istoriju promena u dimenziji i, konačno, odvaja odraz istorije i hijerarhije, što uveliko pojednostavljuje održavanje dimenzije.

Treća važna tačka sa kojom se razvijač skladišta često mora suočiti je vezana za agregatne vrijednosti. Ova klasa zadataka može se uslovno podijeliti u dvije podklase. Prvi razmatra zadatke stvaranja i održavanja agregata prema dostupnim detaljnim podacima i široko je obrađen u literaturi. Drugi se odnosi na činjenicu da izvori podataka za skladište ne daju detaljne vrijednosti, već već određeni skup agregiranih podataka. Ova situacija je tipična kada se kreiraju skladišta podataka za kompanije za upravljanje i vladine regulatorne agencije, koje prikupljaju mnoge izvještajne obrasce.

Ekstremni slučaj ovog pristupa je model koji se konvencionalno može nazvati "vrijednost indikatora". Njegova suština leži u činjenici da se prikuplja veliki skup indikatora koji karakterišu finansijske i ekonomske aktivnosti preduzeća. Ovi indikatori mogu biti ili funkcionalno povezani ili ne, mogu odražavati iste vrijednosti, ali s različitim stepenom detalja, itd. Prilikom pokušaja da takve podatke predstavi u obliku višedimenzionalnog modela, programer se susreće sa značajnim problemima i vrlo često slijedi put stvaranja ne skladišta podataka, već skladišta obrazaca. Tipično skladištenje obrazaca izgrađeno je na osnovu tri dimenzije - ekonomski pokazatelji, vrijeme, izvještajni obrasci; tabele činjenica - vrijednosti ekonomskih pokazatelja i pomoćne tabele koje opisuju kako se indikatori i njihove vrijednosti nalaze u obrascima za izvještavanje. Prilikom analize takvih podataka, analitičar će imati značajne poteškoće, uglavnom zbog činjenice da se indikatori različitih oblika ne mogu međusobno porediti. Jedino što mu preostaje je da prati promjene pokazatelja jedne forme tokom vremena.

Zaključak

Prilikom realizacije projekata izgradnje skladišta podataka javlja se niz uobičajenih zadataka koji ne ovise o predmetnoj oblasti informacija koje se obrađuju. Ovi zadaci uključuju:

Ovaj članak govori o mogućim rješenjima ovih problema. Konkretno, date su metode implementacije hijerarhijskih dimenzija uvođenjem dodatnih atributa (lijeve i desne ivice), kao i uvođenjem dodatne tabele - "tablice pomoćnika". Međutim, u svim razmatranim problemima postoje neriješena pitanja koja zahtijevaju dalje istraživanje. Posebno je teško implementirati slučaj hijerarhijskih mjerenja uz potrebu održavanja historije promjena koje imaju veze sa nekim drugim direktorijumima. Ovaj članak ne uključuje pitanja vezana za metode čišćenja podataka i algoritme za učitavanje podataka u skladište. Ove teme zahtijevaju odvojeno razmatranje.

LITERATURA

1.	Joerg Reinschmidt, Allison Francoise. Vodič za certifikaciju poslovne inteligencije. IBM Crvene knjige;
2.	Inmon W. Izgradnja skladišta podataka. - New York: John Willey & Sons, 1992;
3.	Spirli, Erik. Skladišta korporativnih podataka. Planiranje, razvoj, implementacija. Volume. 1: Per. sa engleskog - M.: Izdavačka kuća "Williams", 2001;
4.	Joe Celko. Drveće u SQL-u: Intelligent Enterprise, 20. oktobar 2000.;
5.	Donald E. Knuth. Umetnost programiranja, tom 1. Osnovni algoritmi, 3. izd.: - M.: Izdavačka kuća "Williams", 2000.;
6.	Ralph Kimball. Pomoć za hijerarhije: DBMS septembar 1998;
7.	Ralph Kimball. Dimenzije koje se polako mijenjaju: DBMS april 1996.;
8.	Statistički rječnik: M. "Finansije i statistika", 1989;
9.	Duke V, Samoilenko A, Data mining: kurs za obuku. - SPb: Petar, 2001;
10.	Erhard Rahm, Hong Hai Do: Čišćenje podataka: problemi i trenutni pristupi. IEEE Data Engineering Bulletin 23 (4): 3-13 (2000);
11.	Ralph Kimball: Komplet alata za skladište podataka: praktične tehnike za izgradnju dimenzionalnih skladišta podataka. John Wiley 1996;
12.	Maria Sueli Almeida, Missao Ishikawa, Joerg Reinschmidt, Torsten Roeber, Početak rada sa skladištem podataka i poslovnom inteligencijom. IBM Crvene knjige;
13.	Nigel Pendse, OLAP arhitekture: OLAP izvještaj, http://www.olapreport.com/Architectures.htm#top.

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

Epilog

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

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

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

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

Tagovi:

• arhitektura
• skladište podataka

Dodaj oznake