Čini se da je sada ušla tema razvoja skladišta podataka novi krug razvoj. Pojavljuju se nove tehnologije, pristupi i alati. Njihovo proučavanje, odobravanje i razumna primjena omogućuje nam stvaranje zaista zanimljivih i korisna rješenja. I dovedite ih u implementaciju, uživajući u činjenici da se vaši razvojni programi koriste pravi posao i korist.

Epilog

U pripremi ovog članka pokušao sam se prvenstveno fokusirati na arhitekte, analitičare i programere koji izravno rade sa skladištima podataka. Ali ispostavilo se da sam neizbježno "uzeo temu malo šire" - i druge kategorije čitatelja pale su u vidno polje. Neke će se točke činiti kontroverznima, neke nisu jasne, neke su očite. Ljudi su različiti – s različitim iskustvima, podrijetlom i pozicijama.
Na primjer, tipična pitanja menadžera su “kada privući arhitekte?”, “Kada se trebam baviti arhitekturom?”, “Arhitektura – neće li biti preskupo?” zvuči prilično čudno za nas (programere, dizajnere), jer za nas se arhitektura sustava pojavljuje s njegovim rođenjem - nije važno shvaćamo li je ili ne. Pa čak i ako u projektu nema formalne uloge arhitekta, normalni programer uvijek se "uključuje" svog internog arhitekta.

Po velika stvar Nije važno tko je arhitekt, važno je da netko postavi ta pitanja i istražuje odgovore. Ako je arhitekt jasno izdvojen, to samo znači da je on prvenstveno odgovoran za sustav i njegov razvoj.
Zašto mi se tema “antifragilnosti” učinila relevantnom u odnosu na ovu temu?

“Jedinstvenost antifragilnosti je u tome što nam omogućuje da radimo s nepoznatim, da radimo nešto u uvjetima u kojima ne razumijemo što točno radimo – i da uspijemo.”/Nassim N.Taleb/

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

Oznake: Dodajte oznake

Zaitsev S.L., dr. sc.

Grupe koje se ponavljaju

Grupe koje se ponavljaju su atributi za koje pojedinačna instanca entiteta može imati više od jedne vrijednosti. Na primjer, osoba može imati više od jedne vještine. Ako, u smislu poslovnih zahtjeva, moramo znati razinu vještina za svakoga, a svaka osoba može imati samo dvije vještine, možemo stvoriti entitet prikazan na Sl. 1.6. Ovdje je entitet OSOBA s dva atributa za pohranjivanje vještina i razina vještina za svaki.

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

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

Riža. 1.7. Model smanjen na prvi normalan oblik.

Jedna činjenica na jednom mjestu

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

Redundantnost zahtijeva dodatni prostor, ali iako je učinkovitost memorije važna, pravi problem leži negdje drugdje. Zajamčena sinkronizacija suvišnih podataka dolazi s dodatnim troškovima i uvijek riskirate sukob vrijednosti.

U prethodnom primjeru VJEŠTINA ovisi o ID osobe i od ID vještine. To znači da nećete imati VJEŠTINA dok se ne pojavi OSOBA, posjedovanje ove vještine. Također otežava promjenu naziva vještine. Morate pronaći svaki unos naziva vještine i promijeniti ga za svaku osobu koja posjeduje tu vještinu.

Slika 1.8 prikazuje model u drugom normalnom obliku. Imajte na umu da je entitet dodan VJEŠTINA, i atribut TITULA vještina prenesena na ovaj entitet. Razina vještine ostala je, odnosno, na raskrižju OSOBE i VJEŠTINE.

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

Svaki atribut ovisi o ključu

Svaki atribut entiteta mora ovisiti o primarnom ključu tog entiteta. U prethodnom primjeru Skolsko ime I Geografsko područje prisutna u tablici OSOBA ali ne opisivati ​​osobu. Da biste postigli treći normalni oblik, trebate premjestiti atribute u entitet, gdje će ovisiti o ključu. Slika 1.9. prikazuje model u trećem normalnom obliku.

Riža. 1.9. U trećem normalnom obliku Skolsko ime I Geografska regija premješteno u entitet, gdje njihove vrijednosti ovise o ključu.

Odnosi mnogo-prema-više

Odnosi mnogo-prema-mnogima odražavaju stvarnost okoliša. Imajte na umu da na slici 1.9 postoji odnos više prema mnogo između OSOBA I ŠKOLA. Omjer točno odražava činjenicu da OSOBA može studirati u mnogima ŠKOLE i u ŠKOLA može puno naučiti OSOBA. Da bi se postigao četvrti normalni oblik, stvara se asocijativni entitet koji eliminira odnos monogie-prema-mnogo formiranjem zaseban unos za svaku jedinstvenu kombinaciju škole i osobe. Slika 1.10 prikazuje model u četvrtom normalnom obliku.

Riža. 1.10. U četvrtom normalnom obliku, odnos monogie-prema-mnogo između OSOBA 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 temelje se na relacijskoj algebri i mogu se tumačiti kao matematičke transformacije. Iako ova knjiga ne pokriva detaljnu raspravu o normalnim oblicima, modelarima se potiče da dublje uđu u tu temu.

U danoj relaciji R, atribut Y funkcionalno ovisi o atributu X. Simbolično, RX -> RY (čita se kao "RX funkcionalno definira RY") ako i samo ako je svaka vrijednost X u R pridružena točno jednoj Y vrijednosti u R ( u bilo koje vrijeme). Atributi X i Y mogu biti složeni (Datum K.J. Uvod u sustave baza podataka. 6. izdanje. Ed. Williams: 1999., 848 str.).

Relacija R je u prvom normalnom obliku (1NF) ako i samo ako sve njezine domene sadrže samo atomske vrijednosti (Datum, ibid.).

Relacija R je u drugom normalnom obliku (2NF) ako i samo ako je u 1NF i svaki atribut koji nije ključ potpuno ovisi o primarnom ključu (Datum, ibid.).

Relacija R je u trećem normalnom obliku (3NF) ako i samo ako je u 2NF i svaki atribut koji nije ključ nije tranzitivno ovisan o primarnom ključu (Datum, ibid.).

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

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

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

FD (functional dependency) - funkcionalna ovisnost. U funkcionalnoj ovisnosti, vrijednost atributa ovisi o vrijednosti drugog atributa koji nije dio primarnog ključa.

JD (join dependency) - ovisnost o pridruživanju. U ovisnosti spajanja, primarni ključ roditeljskog entiteta može se pratiti do najmanje treće razine potomaka uz zadržavanje mogućnosti korištenja u izvornom spajanju ključa.

Relacija je u četvrtom normalnom obliku (4NF) ako i samo ako postoji MVD u R, kao što je A®®B. U ovom slučaju, svi atributi R su funkcionalno ovisni o A. Drugim riječima, u R postoje samo ovisnosti (FD ili MVD) oblika K®X (tj. funkcionalna ovisnost atributa X o kandidatu za upotrebu kao ključ K). Sukladno tome, R ispunjava zahtjeve 4NF ako je u skladu s BCNF-om i svi MVD-ovi su zapravo FD-ovi (Datum, ibid.).

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

Postoje mnogi drugi normalni oblici za složene tipove podataka i specifične situacije koje su izvan dosega naše rasprave. Svaki entuzijast razvoja modela želio bi istražiti druge normalne oblike.

Poslovni normalni oblici

U svojoj knjizi Clive Finklestein (Finklestein Cl. An Introduction to Information Engineering: From Strategic Planning to Information Systems. Reading, Massachusetts: Addison-Wesley, 1989) zauzeo je drugačiji pristup normalizaciji. Definira uobičajene poslovne oblike u smislu svođenja na te oblike. Mnogi modelari smatraju da je ovaj pristup intuitivniji i pragmatičniji.

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

Drugi poslovni normalni oblik (2BNF) preslikava atribute koji djelomično ovise o primarnom ključu u drugi entitet. Primarni (kompozitni) ključ ovog entiteta je primarni ključ entiteta u kojem se izvorno nalazio, zajedno s dodatni ključevi, o kojem atribut potpuno ovisi.

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

Četvrti poslovni normalni oblik (4BNF) preslikava atribute koji ovise o vrijednosti primarnog ključa ili su neobavezni za sekundarni entitet, gdje u potpunosti ovise o vrijednosti primarnog ključa ili gdje moraju (obavezno) biti prisutni u tom entitetu .

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

Dovršeni logički model podataka

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

Svi entiteti moraju imati nazive koji opisuju sadržaj i jasan, sažet, Potpuni opis ili definicija. U jednoj od sljedećih publikacija razmotrit će se početni skup preporuka za pravilno formiranje naziva i opisa entiteta.

Entiteti moraju imati kompletan skup atributa, tako da svaka činjenica o svakom entitetu može biti predstavljena njegovim atributima. Svaki atribut mora imati naziv koji odražava njegovu vrijednost, boolean tip podatke i jasan, kratak, potpun opis ili definiciju. U jednoj od sljedećih publikacija razmotrit ćemo početni skup preporuka za ispravno formiranje naziva i opisa atributa.

Odnosi trebaju uključivati ​​glagolsku konstrukciju koja opisuje odnos između entiteta, zajedno s karakteristikama kao što su množina, potreba za postojanjem ili mogućnost nepostojanja odnosa.

BILJEŠKA Množina komunikacija opisuje maksimalan broj instance sekundarnog entiteta koji se mogu povezati s instancom izvornog entiteta.Potreba za postojanjem ilimogućnost odsutnosti odnos se koristi za definiranje minimalnog broja instanci sekundarnog entiteta koji se može povezati s instancom izvornog entiteta.

Fizički model podataka

Nakon stvaranja cjelovite i adekvatne logički model spremni ste donijeti odluku o izboru platforme za implementaciju. Izbor platforme ovisi o zahtjevima za korištenje podataka i strateškim načelima arhitekture organizacije. Odabir platforme složeno je pitanje koje je izvan dosega ove knjige.

U ERwinu, fizički model je grafički prikaz stvarne baze podataka. Fizička baza podataka sastojat će se od tablica, stupaca i odnosa. Fizički model ovisi o platformi odabranoj za implementaciju i zahtjevima za korištenje podataka. Fizički model za IMS bit će vrlo drugačiji od istog modela za Sybase. Fizički model za OLAP izvješća izgledat će drugačije od modela za OLTP (Online Transaction Processing).

Modelar podataka i administrator baze podataka (DBA) koriste logički model, zahtjeve korištenja i strateška načela korporativne arhitekture 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štenje podataka i definiranja komponenti fizičkog modela i obrnutog inženjeringa. Ova pitanja će biti detaljnije obrađena u budućim publikacijama.

Prikupljanje zahtjeva za korištenje podataka

Zahtjeve za korištenje podataka obično prikupljate rano tijekom intervjua i radnih sesija. Istodobno, zahtjevi bi trebali što potpunije definirati korištenje podataka od strane korisnika. Površni stav i praznine u fizičkom modelu mogu dovesti do neplaniranih troškova i odgoditi projekt. Zahtjevi za korištenje uključuju:

Zahtjevi za pristup i performanse

Volumetrijske karakteristike (procjena količine podataka za pohranu), koje omogućuju administratoru da predstavi fizički volumen baze podataka

Procjena broja korisnika kojima je potreban istovremeni pristup podacima koji će vam pomoći da dizajnirate svoju bazu podataka za prihvatljivu razinu izvedbe

Sažetak, sažetak i drugi izračunati ili izvedeni podaci koji se mogu smatrati kandidatima za pohranu u trajne strukture podataka

Zahtjevi za generiranje izvješća i standardne upite koji pomažu administratoru baze podataka da izgradi indekse

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

Osim predsjedavajućeg, tajnika i korisnika, sesija zahtjeva za korištenje treba uključivati ​​modelara, administratora baze podataka i arhitekta baze podataka. Trebalo bi razgovarati o zahtjevima korisnika za povijesne podatke. Dužina vremena pohranjivanja podataka ima značajan utjecaj na veličinu baze podataka. Često se stariji podaci pohranjuju u zbirnom obliku, a atomski podaci se arhiviraju ili brišu.

Korisnici bi trebali donijeti uzorke upita i izvješća sa sobom na sesiju. Izvješća moraju biti strogo definirana i moraju uključivati ​​atomske vrijednosti koje se koriste za sva polja sažetka i sažetka.

Komponente fizičkog modela podataka

Komponente fizičkog modela podataka su tablice, stupci i relacije. Entiteti u logičkom modelu vjerojatno će postati tablice u fizičkom modelu. Booleovi atributi će postati stupci. Logički odnosi postat će ograničenja integriteta odnosa. Neki logički odnosi ne mogu se ostvariti u fizičkom baza podataka.

obrnuti inženjering

Kada logički model nije dostupan, postaje potrebno ponovno kreirati model iz postojeća baza podaci. U ERwinu se ovaj proces naziva obrnutim inženjeringom. Obrnuti inženjering može se izvesti na nekoliko načina. Modelar može istražiti strukture podataka u bazi podataka i ponovno kreirati tablice u okruženju vizualnog modeliranja. Možete uvesti jezik definicije podataka (DDL) u alat koji podržava obrnuti inženjering (npr. Erwin). Napredni alati kao što je ERwin uključuju značajke koje vam omogućuju komunikaciju putem ODBC-a s postojećom bazom podataka za stvaranje modela pomoću izravno čitanje strukture podataka. Obrnuti inženjering pomoću ERwina bit će detaljno razmotren u budućoj publikaciji.

Korištenje korporativnih funkcionalnih granica

Prilikom izgradnje logičkog modela važno je da modelar to osigura 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 prezentirani holistički, bez obzira na predmetno područje posao koji podržava. Entiteti, atributi i odnosi trebali bi definirati poslovna pravila na korporativnoj razini.

BILJEŠKA Neki od mojih kolega ove korporativne funkcionalne granice nazivaju modeliranjem u stvarnom svijetu. Modeliranje u stvarnom svijetu potiče modelara da promatra informacije u smislu njegovih odnosa i odnosa u stvarnom životu.

Korištenje korporativnih funkcionalnih granica za pravilno izgrađen model podataka pruža okvir za podršku informacijskim potrebama bilo kojeg broja procesa i aplikacija, omogućujući korporaciji da učinkovitije iskorištava jednu od svojih najvrjednijih sredstava, informacije.

Što je model podataka poduzeća?

Podatkovni model poduzeća (EDM) sadrži entitete, atribute i odnose koji predstavljaju informacijske potrebe korporacije. EDM se obično dijeli na predmetna područja, a to su grupe entiteta povezanih s pružanjem podrške specifičnim poslovnim potrebama. Neka predmetna područja mogu pokrivati ​​specifične poslovne funkcije kao što je upravljanje ugovorima, druga mogu grupirati entitete koji opisuju proizvode ili usluge.

Svaki logički model mora odgovarati postojećoj domeni poslovnog modela podataka. Ako se logički model ne podudara ovaj zahtjev, treba mu dodati model koji definira predmetno područje. Ova usporedba osigurava da se korporativni model poboljša ili prilagodi i da se svi napori logičkog modeliranja koordiniraju unutar korporacije.

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

Izgradnja modela podataka poduzeća skaliranjem

Postoje organizacije u kojima je korporativni model od početka do kraja izgrađen kao rezultat jednog zajedničkog napora. S druge strane, većina organizacija gradi prilično potpune modele poduzeća izgradnjom.

Rast znači graditi nešto, sloj po sloj, baš kao što kamenica raste biser. Svaki stvoreni model podataka daje input za formiranje EDM-a. Izgradnja EDM-a na ovaj način zahtijeva dodatne korake modeliranja za dodavanje novih struktura podataka i domena ili proširenje postojećih struktura podataka. To omogućuje izgradnju poslovnog modela podataka izgradnjom, iterativnim dodavanjem razina detalja i preciziranja.

Koncept metodologije modeliranja

Postoji nekoliko metodologija za vizualno modeliranje podataka. ERwin podržava dva:

IDEF1X (Definicija integracije za informaciju Modeliranje – integrirani opis informacijskih modela).

IE (Informacijski inženjering - informacijski inženjering).

IDEF1X je dobra metodologija i njezina se notacija naširoko koristi

Integrirani opis informacijskih modela

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

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

Informacijski inženjering

Clive Finklestein se često naziva ocem informacijskog inženjeringa, iako je James Martin s njim dijelio slične koncepte (Martin, James. Managing the Database Environment. Upper Saddle River, New Jersey: Prentice Hall, 1983.). Informacijski inženjering koristi poslovni pristup za upravljanje 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 pruža infrastrukturu za podršku informacijskim zahtjevima integracijom korporativnog strateškog planiranja s informacijskim sustavima koji se razvijaju. Takva integracija omogućuje bliže povezivanje upravljanja informacijskim resursima s dugoročnim strateškim izgledima korporacije. Ovaj poslovni pristup vodi mnoge modelatore da izaberu IE u odnosu na druge metodologije koje se prvenstveno usredotočuju na rješavanje neposrednih razvojnih problema.

IE pruža tijek rada koji navodi korporaciju da identificira sve svoje informacije koje su joj potrebne za prikupljanje i upravljanje podacima te identificiranje odnosa između informacijskih objekata. Kao rezultat toga, zahtjevi za informacijama artikulirani su na temelju upravljačkih direktiva i mogu se izravno prevesti u upravljački informacijski sustav koji će podržati potrebe za strateškim informacijama.

Zaključak

Razumijevanje kako koristiti alat za modeliranje podataka kao što je ERwin samo je dio problema. Osim toga, morate razumjeti kada se izvode zadaci modeliranja podataka i kako se prikupljaju zahtjevi za informacijama i poslovna pravila kako bi bili predstavljeni u modelu podataka. Provođenje radnih sesija pruža najpovoljnije uvjete za prikupljanje zahtjeva za informacijama u okruženju koje uključuje stručne stručnjake, korisnike i stručnjake za informacijske tehnologije.

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

Model podataka sastoji se od logičkih i fizičkih modela koji predstavljaju informacijske zahtjeve i poslovna pravila. Logički model se mora 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, jedno mjesto". Zahtjeve prikupljenih informacija i poslovna pravila treba analizirati i istražiti. Treba ih usporediti s modelom poduzeća kako bi se osiguralo da nisu u sukobu s postojećim objektnim modelima i da uključuju sve potrebne objekte.

U ERwinu model podataka uključuje i logičke i fizičke modele. ERwin implementira ER pristup i omogućuje vam stvaranje logičkih i fizičkih objekata modela koji predstavljaju zahtjeve za informacijama i poslovna pravila. Objekti logičkog modela uključuju entitete, atribute i odnose. Objekti fizičkog modela uključuju tablice, stupce i ograničenja integriteta odnosa.

U jednoj od sljedećih publikacija razmatrat će se pitanja identifikacije entiteta, određivanja tipova entiteta, odabira naziva i opisa entiteta, kao i neki trikovi za izbjegavanje najčešćih pogrešaka modeliranja povezanih s korištenjem entiteta.

Entiteti moraju imati kompletan skup atributa, tako da svaka činjenica o svakom entitetu može biti predstavljena njegovim atributima. Svaki atribut mora imati naziv koji odražava njegove vrijednosti, logički tip podataka i jasan, kratak, potpun opis ili definiciju. U jednoj od sljedećih publikacija razmotrit ćemo početni skup preporuka za ispravno formiranje naziva i opisa atributa. Odnosi trebaju uključivati ​​glagolsku konstrukciju koja opisuje odnos između entiteta, zajedno s karakteristikama kao što su množina, potreba za postojanjem ili mogućnost nepostojanja odnosa.

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

Svrha predavanja

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

• što se dogodilo model podataka poduzeća ;
• kako pretvoriti model podataka poduzeća u model skladišta podataka;
• bitne elemente model podataka poduzeća ;
• prezentacijski slojevi korporativnog modela podataka ;
• algoritam za pretvaranje modela podataka poduzeća u model višedimenzionalnog skladišta podataka ;

i nauči:

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

Podatkovni model poduzeća

Uvod

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

U usporedbi s projektiranjem OLTP sustava, metodologija za projektiranje skladišta podataka ima niz karakteristične značajke vezano uz orijentaciju struktura podataka pohrane za rješavanje problema analize i informacijska podrška proces odlučivanja. Model podataka skladišta podataka trebao bi osigurati učinkovito rješenje upravo ove zadaće.

Polazna točka u projektiranju skladišta podataka može biti tzv model podataka poduzeća(corporate data model ili enterprise data model, EDM), koji nastaje u procesu projektiranja OLTP sustava organizacije. Prilikom projektiranja model podataka poduzeća obično se pokušava na temelju poslovanja stvoriti takva struktura podataka koja bi prikupljala i sintetizirala sve informacijske potrebe organizacije.

Na ovaj način, model podataka poduzeća sadrži potrebne informacije za izradu HD modela. Dakle, u prvoj fazi, ako takav model postoji u organizaciji, dizajner skladišta podataka može započeti projektiranje skladišta podataka rješavanjem problema transformacije model podataka poduzeća u modelu HD.

Podatkovni model poduzeća

Kako riješiti problem konverzije model podataka poduzeća u HD modelu? Da biste riješili ovaj problem, morate imati ovaj model, tj. model podataka poduzeća treba izgraditi i dokumentirano. I trebate razumjeti što od ovog modela i kako treba transformirati u HD model.

Pojasnimo koncept model podataka poduzeća. Pod, ispod korporativni model podataka razumjeti višerazinski, strukturirani opis predmetnih područja organizacije, strukture podataka predmetnih područja, poslovne procese i poslovne procedure, tokove podataka usvojene u organizaciji, dijagrame stanja, matrice procesa podataka i druge prikaze modela koji se koriste u aktivnosti organizacije. Dakle, u širem smislu, model podataka poduzeća je skup modela različitih razina koji karakteriziraju (model na nekoj apstraktnoj razini) aktivnosti organizacije, t.j. sadržaj korporativni model izravno ovisi o tome koje su modelne strukture bile uključene u njega u danoj organizaciji.

Glavni elementi model podataka poduzeća su:

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

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

Prezentacijski slojevi modela podataka poduzeća

Podatkovni model poduzeća podijeljen je prema predmetnim područjima, koja predstavljaju skupine subjekata koji se odnose na potporu specifičnim poslovnim potrebama. Neka predmetna područja mogu pokrivati ​​specifične poslovne funkcije kao što je upravljanje ugovorima, druga mogu grupirati entitete koji opisuju proizvode ili usluge.

Svaki logički model mora odgovarati postojećem predmetnom području model podataka poduzeća. Ako logički model ne zadovoljava ovaj zahtjev, mora mu se dodati model koji definira predmetno područje.

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

Riža. 16.2.

Dijagram prikazan na slici prikazuje četiri predmetna područja: "Kupac" ( kupac), "Ček" ( račun), "Narudžba" ( Narudžba) i "Proizvod" ( proizvod). Obično samo na gornjoj razini prikaza modela izravne veze između predmetnih područja, koji npr. fiksiraju sljedeću činjenicu: kupac plaća račun za narudžbu robe. Detaljne informacije i neizravni odnosi na ovoj razini korporativni model nisu dati.

Na sljedećem srednja razina(srednja razina) model podataka poduzeća prikazano detaljne informacije o objektima domene, tj. ključevima i atributi entiteta, njihovi odnosi, podtipovi i supertipovi, itd. Za svaku domenu modela najviše razine postoji jedan model srednje razine. Na sl. 16.3 prikazano prosječna razina reprezentacija korporativni model za ulomak predmetnog područja "Red".

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

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

Sa stajališta dizajna važan čimbenik u odlučivanju o izradi modela skladišta podataka iz model podataka poduzeća je država potpunost model podataka poduzeća.

Podatkovni model poduzeća organizacija ima obilježje evolucije, t.j. neprestano se razvija i poboljšava. Neka predmetna područja model podataka poduzeća može biti dobro razvijena, za neke posao možda još nije započeo. Ako fragment predmetnog područja nije razrađen u model podataka poduzeća, onda ne postoji način da se ovaj model koristi kao polazna točka za projektiranje skladišta podataka.

Stupanj dovršenosti korporativni model može se izravnati u dizajnu HD-a na sljedeći način. Budući da se proces razvoja skladišta podataka obično dijeli na slijed faza u vremenu, proces njegovog dizajna može se sinkronizirati s proces završetka razvoj pojedinih fragmenata model podataka poduzeća organizacijama.

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

Članak opisuje glavne arhitekture skladišta podataka, neke generalni principi njihove konstrukcije. Detaljno su opisani načini predstavljanja hijerarhija u relacijskoj strukturi podataka.

Uvod

Početkom osamdesetih godina prošlog stoljeća, u razdoblju naglog razvoja registracije informacijski sustavi, došlo je do razumijevanja ograničene mogućnosti njihove primjene za potrebe analize podataka i izgradnje sustava podrške i donošenja odluka na njihovoj osnovi. Za automatizaciju su stvoreni sustavi snimanja rutinske operacije za poslovanje - izdavanje računa, obrada ugovora, provjera stanja skladišta i sl., a linijsko osoblje bili su glavni korisnici ovakvih sustava. Glavni zahtjevi za takve sustave bili su osigurati transacionalnost izvršenih promjena i maksimizirati brzinu njihove implementacije. Upravo su ti zahtjevi odredili izbor relacijskog DBMS-a i modela prezentacije podataka entitet-relacija kao glavnih korištenih. tehnička rješenja u izgradnji sustava snimanja.

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

Očito, sustavi za snimanje nisu zadovoljili niti jedan od gore navedenih zahtjeva. U sustavu registracije podaci su relevantni samo u trenutku pristupa bazi, u sljedećem trenutku za isti zahtjev možete dobiti potpuno drugačiji rezultat. Sučelje sustava registracije dizajnirano je za izvođenje strogo definiranih operacija, a mogućnost dobivanja rezultata za ad-hoc zahtjev je vrlo ograničena. Mogućnost obrade velikih količina podataka također je mala zbog postavke DBMS-a za obavljanje kratkih transakcija i neizbježnog usporavanja rada ostalih korisnika.

Odgovor na ovu potrebu bila je pojava nova tehnologija organizacija baze podataka – tehnologija skladištenja podataka.

Definicija i tipične arhitekture skladišta podataka

Koncept skladišta podataka temelji se na dvije glavne ideje - integraciji različitih detaljnih podataka (detaljnih u smislu da opisuju neke specifične činjenice, svojstva, događaje itd.) u jedno spremište i razdvajanje skupova podataka i aplikacija koje se koriste za online obrada i koristi se za rješavanje problema analize. Definicija od " spremište podataka" je prvi dao William G. Inmon u svojoj monografiji. U njoj je definirao skladište podataka kao "predmetno orijentirano, integrirano, koje sadrži povijesne podatke, neuništivi skup podataka dizajniran za podršku donošenju upravljačkih odluka."

Konceptualno, model skladišta podataka može se predstaviti kao dijagram prikazan na slici 1. Podaci iz različitih izvora smješteni su u skladište podataka, a opisi tih podataka smješteni su u spremište metapodataka. Krajnji korisnik, koristeći različite alate (alati za vizualizaciju, alati za izvješćivanje, statistička obrada i sl.) i sadržaje repozitorija, analizira podatke u spremištu. Rezultat njegove aktivnosti su informacije u obliku gotovih izvješća, pronađenih skrivenih obrazaca i bilo kakvih prognoza. Budući da sredstva za rad krajnji korisnik sa skladištem podataka može biti vrlo raznolik, te teoretski njihov izbor ne bi trebao utjecati na njegovu strukturu i funkcije održavanja ažurnosti.

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

Virtualna pohrana podataka je sustav koji predstavlja sučelja i metode pristupa sustavu za snimanje koji emulira rad s podacima u ovom sustavu, kao i kod skladišta podataka. Virtualno skladište podataka može se organizirati stvaranjem niza pogleda (view) u bazi podataka, ili primjenom posebna sredstva pristup, kao što su desktop OLAP proizvodi, kao što su BusinessObjects, Brio Enterprise i drugi.

Glavne prednosti ovog pristupa su:

Međutim, ima puno više nedostataka nego prednosti. Stvaranjem virtualna pohrana podataka, ne stvarate skladište kao takvo, već iluziju njegovog postojanja. Struktura pohrane podataka i sama pohrana podataka se ne mijenja, a problemi ostaju:

	izvođenje;
	Transformacije podataka;
	Integracija podataka s drugim izvorima;
	Nedostatak povijesti;
	Čistoća podataka;
	Ovisnost o dostupnosti glavne baze podataka;
	Ovisnost o strukturi glavne baze podataka.

Dvoslojna arhitektura Pohrana podataka podrazumijeva izgradnju podatkovnih prodajnih mjesta (data mart) bez stvaranja središnjeg repozitorija, dok informacije dolaze iz malog broja sustava za snimanje i ograničene su na određeno predmetno područje. Prilikom izgradnje podatkovnih prodajnih mjesta koriste se osnovni principi izgradnje skladišta podataka o čemu raspravljat će se ispod, pa se mogu smatrati minijaturnim spremištima podataka. Prednosti podatkovnih prodajnih mjesta su:

Izgradnja potpunog skladišta korporativnih podataka obično se obavlja u troslojna arhitektura(Treba napomenuti da se ovdje troslojna arhitektura ne razumije kao struktura "DB - Application Server - Client"). Na prvoj razini nalaze se različiti izvori podataka - interni sustavi snimanja, sustavi pomoći, vanjski izvori (podaci novinske agencije, makroekonomski pokazatelji). Druga razina sadrži središnje skladište podataka, gdje se nalaze informacije iz svih izvora s prva razina, a moguće i operativno skladište podataka (OSD). Operativno skladište ne sadrži povijesne podatke i obavlja dvije glavne funkcije. Prvo, to je izvor analitičkih informacija za operativno upravljanje, a drugo, ovdje se pripremaju podaci za naknadno učitavanje u središnji repozitorij. Pod pripremom podataka podrazumijeva se njihova transformacija i provedba određenih provjera. Prisutnost OSD-a jednostavno je neophodna uz različite propise za primanje informacija iz izvora. Treća razina u opisanoj arhitekturi je skup podatkovnih prodajnih mjesta specifičnih za domenu, čiji je izvor informacija središnje skladište podataka. Većina krajnjih korisnika radi s podatkovnim prodajnim mjestima.

Projektiranje strukture relacijskog spremišta podataka

Skladišta podataka grade se na temelju višedimenzionalnog modela podataka. Višedimenzionalni model podataka podrazumijeva odabir pojedinačnih dimenzija (vrijeme, geografija, kupac, račun) i činjenica (volumen prodaje, prihod, količina robe) koje se analiziraju prema odabranim dimenzijama. Višedimenzionalni model podataka može se fizički implementirati u višedimenzionalne i relacijske DBMS-ove. U posljednji slučaj izvodi se prema shemi "zvijezda" ili "pahulja". Ove sheme uključuju odabir tablica činjenica i tablica dimenzija. Svaka tablica činjenica sadrži detaljne podatke i strane ključeve za tablice dimenzija. Teorija izgradnje višedimenzionalnog modela podataka i njegova implementacija u relacijsku strukturu široko je obrađena u stranoj i domaćoj literaturi.

Problem zastupljenosti hijerarhija može se pripisati broju malo obrađenih tema. Kao primjer dimenzije koja se široko koristi u analizi djelatnosti poduzeća i ima hijerarhijsku strukturu, možemo navesti imenik troškovnih stavki. Razmotrimo model troškovnih mjesta (cost centre) prikazan na slici 2.

Klasična informatika rješava problem predstavljanja hijerarhija korištenjem rekurzivnog povezivanja. Ovo jednostavno rješenje omogućuje postavljanje stabla bilo koje dubine i dimenzije u jednu tablicu. U našem slučaju predmetni podaci bit će prikazani u sljedećem obliku:

ID roditelja 1 Društvo 2 Kontrolirati 3 Infrastruktura 4 Proizvodnja 5 6 Usluge 7 Polje A 8 Polje B

Stol 1.

Međutim, jednostavnost ovog rješenja krije i njegov glavni nedostatak. Nažalost, standardni SQL ne podržava rekurzivne pokazivače, pa se druge metode koriste za predstavljanje stabala u skladištu podataka.

Metoda koju je predložio Joe Celko temelji se na teoriji skupova. U ovoj metodi se svi čvorovi stabla prelaze izravnim redoslijedom prelaska i za svaki čvor se popunjavaju dvije vrijednosti - lijevi i desni rub, a za svaki čvor grane stabla prvo se popunjava lijevi rub pa tek onda desno - pri povratku od potomaka do roditelja. Dakle, u našem primjeru, numeriranje čvorova će biti kako slijedi:

S ovim numeriranjem čvorova, svaki roditelj sadrži djecu, čiji lijevi i desni rub leže u intervalu između lijeve i desne granice roditelja. Slično, svi roditelji potomstva imaju lijeva granica, što je manje od djetetove lijeve i desne, što je veće od djetetove desne granice. Stoga se iznos troškova za određeno mjesto troška i sve njegove komponente može dohvatiti jednim upitom. Na primjer, da biste dobili troškove infrastrukture, možete pokrenuti sljedeći SQL upit:

odaberite zbroj(tablica_činjenica.cijena)
iz tablice_činjenica, tablice_dimenzija D1, tablice_dimenzija D2
gdje je tablica činjenica.id_dimenzije = D2.id
i D2.lijevo >= D1.lijevo
i D2.desno<= D1.right
i D1.name = "Infrastruktura"

Da bi se olakšao rad s takvim imenikom, osim lijevog i desnog polja treba dodati još dva polja: "Level" - razina čvora u stablu, "Is_leaf" - zastavica koja pokazuje da li je čvor je li list na drvetu ili ne. Tako dobivamo tablicu "dimension_table" (vidi tablicu 2), koja vam omogućuje pohranjivanje stabla bilo koje dubine i dimenzije ugniježđenja i omogućuje odabir djece i roditelja s jednim upitom.

1 Društvo 2 Kontrolirati 3 Infrastruktura 4 Proizvodnja 5 6 Usluge 7 Polje A 8 Polje B

Tablica 2. Predstavljanje hijerarhija pomoću lijevog i desnog obruba

Druga metoda, koju je opisao Ralph Kimball, temelji se na uvođenju pomoćne tablice ("helper-table"), putem koje je tablica činjenica povezana s tablicom dimenzija. Ova pomoćna tablica odražava hijerarhijsku strukturu dimenzije i poštuje sljedeći zakon: pomoćna tablica sadrži cijeli skup parova roditelj-dijete, a dijete možda nije neposredno dijete roditelja. Struktura takve tablice i njezin sadržaj prikazani su u tablici 3.

ID roditelja ID djeteta Udaljenost 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

Tablica 3. Struktura i sadržaj pomoćne tablice.

Sada, povezujući tablicu činjenica (vidi sliku 4) s podređenim ID-om u pomoćnoj tablici, a dimenzijsku tablicu s roditeljskim ID-om, možemo izračunati zbroj troškova za svako troškovno mjesto i sve njegove komponente u jednom upitu, kao u prethodnom slučaju. Istodobno, dodavanjem ograničenja na polja "Udaljenost" i "Is Leaf", možemo jednostavno izračunati troškove za bilo koju razinu u hijerarhiji.

odaberite zbroj(tablica_činjenica.cijena)
iz tablice činjenica, tablice_dimenzija, tablice_pomoćnika
gdje je tablica činjenica.dimenzija_id = pomoćna_tablica.id_dijeteta
i dimension_table.dimension_id = helper_table.parent_id
and dimension_table.name = "Infrastruktura"
i tablica_pomoćnika.udaljenost = 1

Problem dizajniranja hijerarhijskih direktorija postaje još kompliciraniji kada dimenzija može imati nekoliko alternativnih hijerarhija i postaje prilično nerješiv ako je potrebno održavati povijest promjene tablice dimenzija.

Općenito, problem sporo mijenjanja mjerenja zanimljiv je sam po sebi, a da ga ne kompliciraju hijerarhijski klasifikatori. U literaturi se u većini slučajeva razmatra u kontekstu "dimenzije koja se polako mijenja". Takav se zadatak, doista, rješava relativno jednostavno dodavanjem datuma početka i datuma završetka unosa u tablicu dimenzija. Promjena unosa u imeniku rezultira "zatvaranjem" starog unosa i dodavanjem novog. Sada, vraćajući se na referentni primjer troškovne stavke, korisnik koji želi dobiti informacije o trenutnoj troškovnoj stavci za bilo koji određeni datum mora je uključiti u uvjet SQL upita.

Pretpostavimo da je referentna knjiga troškovnih stavki povezana s referentnom knjigom računovodstvenih računa. Jedan ili više računovodstvenih računa predstavljaju troškovnu stavku. Kako bi se promjena bilo kojeg atributa troškovne stavke trebala odraziti u imeniku računovodstvenih računa? S jedne strane, sa stajališta kontnog plana, promjena atributa ne dovodi do promjene suštine troškovne stavke, te se knjigovodstveni knjiženja kroz kontni plan moraju pripisati istoj troškovnici. S druge strane, pojavio se novi unos u imeniku troškovnih stavki, koji se mora nekako povezati s imenikom konta. Ovaj se problem može riješiti dijeljenjem tablice dimenzija na dvije – koja sadrži ažurirane informacije i sadrži povijest promjene entiteta. Ovaj pristup također rješava problem hijerarhijske dimenzije s potrebom održavanja povijesti promjena zapisa u njoj.

Razmotrimo ga detaljnije (vidi sliku 5). Tablica "dimension_actual" tablica je dimenzija s primarnim ključem dimension_id koji sadrži ispravne atribute dimenzije do danas. Povijesna tablica "dimension_history" povezana je s njom putem stranog ključa dimension_id, koji sadrži povijest promjena zapisa, određen datumima početka/završetka zapisa (datum_start, date_end). U njemu je također prisutan trenutni zapis s otvorenim datumom isteka. Tablica činjenica "tablica_činjenica" povezana je s tablicom dimenzija kroz pomoćnu tablicu "helper_table" koja odražava hijerarhijska struktura mjerenja.

Opisani pristup omogućuje: prvo, pohranjivanje i rad s dimenzijom kao s neuravnoteženim stablom; drugo, brzo izvršavanje upita za koje povijest promjena dimenzija nije važna (tablica koja sadrži povijest ne sudjeluje); treće, omogućuje vam praćenje povijesti promjena u dimenziji i, konačno, odvaja odraz povijesti i hijerarhije, što uvelike pojednostavljuje održavanje dimenzije.

Treća važna točka s kojom se razvijač skladišta često mora suočiti odnosi se na agregatne vrijednosti. Ova se klasa problema može uvjetno podijeliti u dvije podklase. Prvi se bavi problemima stvaranja i održavanja agregata prema dostupnim detaljnim podacima i dosta je obrađen u literaturi. Drugi je povezan s činjenicom da izvori podataka za skladište ne daju detaljne vrijednosti, nego već neki skup agregiranih podataka. Ova situacija je tipična kada se stvaraju skladišta podataka za društva za upravljanje i vladina regulatorna tijela koja prikupljaju mnoge izvještajne obrasce.

Ekstremni slučaj ovog pristupa je model koji se konvencionalno može nazvati "vrijednost indikatora". Njegova bit leži u činjenici da se prikuplja veliki skup pokazatelja koji karakteriziraju financijske i gospodarske aktivnosti poduzeća. Ovi pokazatelji mogu biti ili funkcionalno povezani ili ne, mogu odražavati iste vrijednosti, ali s različitim stupnjevima detalja, itd. Prilikom pokušaja predstavljanja takvih podataka u obliku višedimenzionalnog modela, programer se suočava sa značajnim problemima i vrlo često ide putem stvaranja ne pohrane podataka, već spremišta obrazaca. Tipični repozitorij obrazaca temelji se na tri dimenzije - ekonomski pokazatelji, vrijeme, obrasci za izvješćivanje; tablice činjenica - vrijednosti ekonomskih pokazatelja i pomoćne tablice koje opisuju kako se indikatori i njihove vrijednosti nalaze u izvještajnim obrascima. 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 uspoređivati. Jedino što mu preostaje jest pratiti promjene pokazatelja jednog oblika tijekom vremena.

Zaključak

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

U ovom članku razmatrana su moguća rješenja ovih problema. Konkretno, dani su načini implementacije hijerarhijskih dimenzija uvođenjem dodatnih atributa (lijevih i desnih granica), kao i uvođenjem dodatne tablice - "tablice pomoćnika". Međutim, u svim razmatranim problemima postoje neriješena pitanja koja zahtijevaju daljnja istraživanja. Posebno je teško implementirati slučaj hijerarhijskih dimenzija s potrebom održavanja povijesti promjena koje imaju veze s bilo kojim drugim imenicima. Ovaj članak ne uključuje pitanja o metodama čišćenja podataka i algoritmima za učitavanje podataka u pohranu. Ove teme zahtijevaju odvojeno razmatranje.

KNJIŽEVNOST

1.	Joerg Reinschmidt, Allison Francoise. Vodič za certifikaciju poslovne inteligencije. IBM Redbooks;
2.	Inmon W. Izgradnja skladišta podataka. – New York: John Willey & Sons, 1992.;
3.	Spearley, Eric. Skladišta korporativnih podataka. Planiranje, razvoj, implementacija. Volumen. 1: Per. s engleskog. - M .: Izdavačka kuća "Williams", 2001.;
4.	Joe Celco. Stabla u SQL-u: Intelligent Enterprise, 20. listopada 2000.;
5.	Donald E. Knuth. Umijeće programiranja, svezak 1. Osnovni algoritmi, 3. izd.: - M .: Izdavačka kuća "Williams", 2000.;
6.	Ralph Kimball. Pomoć za hijerarhije: DBMS rujan 1998.;
7.	Ralph Kimball. Dimenzije koje se polako mijenjaju: DBMS travanj 1996.;
8.	Statistički rječnik: M. "Financije i statistika", 1989.;
9.	Duke V, Samoylenko A, Data mining: tečaj obuke. - Sankt Peterburg: 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 Redbooks;
13.	Nigel Pendse, OLAP arhitekture: OLAP izvješće, http://www.olapreport.com/Architectures.htm#top.

Čini se da je sada tema razvoja skladišta podataka skliznula u novi krug razvoja. Pojavljuju se nove tehnologije, pristupi i alati. Njihovo proučavanje, testiranje i razumna primjena omogućuje nam stvaranje zaista zanimljivih i korisnih rješenja. I dovedite ih do implementacije, uživajući u činjenici da se vaši razvoji koriste u stvarnom radu i donose koristi.

Epilog

U pripremi ovog članka pokušao sam se prvenstveno fokusirati na arhitekte, analitičare i programere koji izravno rade sa skladištima podataka. Ali ispostavilo se da sam neizbježno "uzeo temu malo šire" - i druge kategorije čitatelja pale su u vidno polje. Neke će se točke činiti kontroverznima, neke nisu jasne, neke su očite. Ljudi su različiti – s različitim iskustvima, podrijetlom i pozicijama.
Na primjer, tipična pitanja menadžera su “kada privući arhitekte?”, “Kada se trebam baviti arhitekturom?”, “Arhitektura – neće li biti preskupo?” zvuči prilično čudno za nas (programere, dizajnere), jer za nas se arhitektura sustava pojavljuje s njegovim rođenjem - nije važno shvaćamo li je ili ne. Pa čak i ako u projektu nema formalne uloge arhitekta, normalni programer uvijek se "uključuje" svog internog arhitekta.

U velikoj shemi stvari, nije važno tko je arhitekt, važno je da netko postavi ova pitanja i istražuje odgovore na njih. Ako je arhitekt jasno izdvojen, to samo znači da je on prvenstveno odgovoran za sustav i njegov razvoj.
Zašto mi se tema “antifragilnosti” učinila relevantnom u odnosu na ovu temu?

“Jedinstvenost antifragilnosti je u tome što nam omogućuje da radimo s nepoznatim, da radimo nešto u uvjetima u kojima ne razumijemo što točno radimo – i da uspijemo.”/Nassim N.Taleb/

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

Oznake:

• arhitektura
• spremište podataka

Dodaj oznake