Izrada jedinstvenog skladišta korporativnih podataka. Izradite model skladišta podataka na temelju modela podataka poduzeća. Modeli podataka o industriji

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 sveden na prvi normalni oblik.

Jedna činjenica na jednom mjestu

Ako je isti atribut prisutan u više od jednog entiteta i nije strani ključ, tada se 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

Odnos 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 generiranjem zasebnog unosa za svaku jedinstvenu kombinaciju škole i osobe. Slika 1.10 prikazuje model u četvrtom normalnom obliku.

Riža. 1.10. U četvrtom normalnom obliku, odnos 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 (čitaj "RX funkcionalno određuje RY") ako i samo ako je svaka vrijednost X u R pridružena točno jednoj Y vrijednosti u R (na 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č u potpunosti 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 potomaka treće razine 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 dodatnim ključevima o kojima atribut u potpunosti ovisi.

Treći poslovni normalni oblik (3BNF) premješta atribute koji ne ovise o primarnom ključu u drugi entitet, gdje su potpuno ovisni o primarnom ključu ovog 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, potpun opis ili definiciju. U jednoj od sljedećih publikacija razmotrit će se početni skup preporuka za pravilno formiranje naziva i opisa entiteta.

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.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 izrade cjelovitog i adekvatnog logičkog modela, spremni ste za donošenje odluke 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 za korištenje i strateška načela korporativne arhitekture za razvoj fizičkog modela podataka. Možete denormalizirati fizički model kako biste poboljšali performanse i kreirali poglede koji podržavaju zahtjeve za korištenje. Sljedeći odjeljci detaljno opisuju proces denormalizacije i kreiranja pogleda.

Ovaj odjeljak daje pregled procesa izgradnje fizičkog modela, prikupljanja zahtjeva za korištenje podataka, 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 koji istodobno trebaju pristupiti podacima, što vam pomaže 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 predsjednika, tajnika i korisnika, sesija zahtjeva za korištenje trebala bi 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 implementirati u fizičku bazu podataka.

obrnuti inženjering

Kada logički model nije dostupan, postaje potrebno ponovno kreirati model iz postojeće baze podataka. U ERwinu se ovaj proces naziva obrnutim inženjeringom. Obrnuti inženjering može se izvesti na nekoliko načina. Modelar može istraž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 funkcije koje pružaju ODBC komunikaciju s postojećom bazom podataka za stvaranje modela izravnim čitanjem struktura 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 osigura da novi model odgovara modelu poduzeća. 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 poslovnu domenu koju podržava. Entiteti, atributi i odnosi trebali bi definirati poslovna pravila na korporativnoj razini.

BILJEŠKA Neki od mojih kolega nazivaju te korporativne funkcionalne granice modeliranjem u stvarnom svijetu. Modeliranje u stvarnom svijetu potiče modelara da promatra informacije u smislu 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 tematska područja, koja predstavljaju skupine 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 logički model ne zadovoljava ovaj zahtjev, mora mu se 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 imena, kao što su tablice kodova, tablice veza, 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 (Integration Definition for Information Modeling – 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 (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 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 i identificiranje odnosa između informacijskih objekata. Kao rezultat toga, zahtjevi za informacijama artikulirani su na temelju direktiva upravljanja 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

Da biste prodali, morate razumjeti što prodajete.

Definirajmo terminologiju i pojmove. ( Skladište podataka) nije sustav ključnih pokazatelja uspješnosti (KPI, KPI), ovo nije velika baza podataka, ovo nije analitička OLAP alat, ovo nije inteligentni sustav koji vam omogućuje izdvajanje novih podataka i dobivanje statističkih ovisnosti, ovo nije sustav jedinstvenog NSI - ovo nije CD, ako o njemu govorimo u kontekstu jedne stavke.

Poduzetničko skladište podataka – ovo je posebno organizirani niz podataka poduzeća (organizacije), obrađen i pohranjen u jednom hardverskom i softverskom kompleksu, koji omogućuje brz pristup operativnim i povijesnim informacijama, višedimenzionalnu analizu podataka (KPI za različita mjerenja), dobivanje prognoza i statistika u kontekst dogovorenih regulatornih referentnih informacija (NSI).

Potencijalni kupci za korporativno skladište podataka i što dobivaju?

Kako prepoznati potencijalne korporativne klijente kojima je potrebno skladište podataka?

Prije svega, puno informacija treba nastati u svakodnevnim aktivnostima tvrtke. To mogu biti telefonski pozivi, financijske transakcije, pritužbe/recenzije kupaca, zahtjevi za dostavu kupaca, informacije sa špijunskih satelita itd. U principu, bilo što, glavna stvar je da ima puno podataka.
Potencijalni klijent bi trebao imati želju vidjeti i analizirati te informacije. Istodobno, razdoblje analize treba biti prilično opsežno - od jednog dana ili čak sat vremena, do analize od nekoliko godina.
Klijent mora imati infrastrukturu koja normalno radi (ne bi smjeli postojati poslužitelji povezani upredenom paricom ili USB priključkom). Ako klijent nema infrastrukturu, treba je prodati.

Koje koristi klijent ima od implementacije poslovnog skladišta podataka?

Pojavljuje se jedinstveni sustav za pohranu podataka za korporativne podatke u kojem se koristi jedna referentna informacija.
Postoji mogućnost provođenja sveobuhvatne analize poslovanja. Na primjer: koji su klijenti najprofitabilniji i najprofitabilniji; koja usluga, koji klijenti su najtraženiji, koje vrste potraživanja su najčešće iu kojim regijama itd.
Postaje moguće provesti analizu koristeći povijesne podatke. Često operativni (automatizirajući svakodnevne poslovne procese) sustavi to ne dopuštaju, jednostavno nemaju dovoljno prostora za pohranu povijesti i moć za provođenje analize.
Postaje moguće povezati i analizirati informacije koje su prethodno bile pohranjene u različitim informacijskim sustavima. Na primjer, podaci o prometu različitih grana pohranjeni su u sustavima naplate različitih programera. Nakon implementacije skladišta podataka, postaje moguće analizirati ih zajedno, u jednom izvješću.
Postaje moguće analizirati i križati različite vrste podataka. Na primjer, novac i promet, broj osoblja i broj odbijenica ili zahtjeva itd.
Postoji osnova za bolji obračun cijene usluga – na temelju informacija iz korporativnog skladišta podataka moguće je dobiti adekvatnije podatke za prirodne baze distribucije.

Što je korporativno skladište podataka

Koje komponente gradi korporativno skladište podataka s tehničke točke gledišta?

Komponente korporativno skladište podataka poduzeća

Klijent uvijek ima operacijske sustave - izvori podataka za korporativno skladište podataka. To su npr. računovodstvo, naplata, bankarstvo itd. sustava.
Korištenje ETL aplikacija(softver koji vam omogućuje ekstrahiranje, transformaciju i učitavanje podataka), podaci iz izvornih sustava ulaze u bazu podataka skladišta podataka. Sljedeće se može koristiti kao ETL alat: Informatica Power Center, IBM DataStage, Oracle Data Integrator, Oracle WareHouse Builder. Postoje i proizvodi drugih dobavljača, ali oni gotovo nisu zastupljeni na ruskom tržištu.
Sebe baza podataka korporativna pohrana nije apstraktna po svojoj strukturi (skup tablica, polja u njima i odnosi među tablicama), već se stvara na temelju modeli podataka. Velika većina baza podataka koristi ili Oracle ili Teradata.
Model podataka je opis svih entiteta, objekata baze podataka korporativnog skladišta podataka i uključuje: konceptualni model podataka, logički model podataka i fizički model baze podataka . Na razini konceptualnog modela definiraju se entiteti i odnosi među njima. Na razini logičkog modela subjekti su podijeljeni na poslovna područja, daju im se detaljan i cjelovit opis, te propisuju odnosi. Prilikom razvoja fizičkog modela baze podataka utvrđuje se cjelokupna struktura baze podataka – od tablica i polja u njima, do particija i indeksa. Modeli podatakaIBM, SAP i Oracle danas opskrbljuju tržište, ali kupnja podatkovnog modela ne znači automatsku izgradnju odgovarajuće poslovne trgovine.Model podataka Ovo nije proizvod u kutiji. Potrebno ga je modificirati kako bi odgovarao potrebama određenog klijenta.
Nadalje, već koristeći podatke iz korporativnog skladišta podataka, područja analize, izvješćivanja i trgovišta podataka. Nakon toga, korisnici mogu samostalno izgraditi potrebno izvješćivanje i provesti multivarijantnu analizu. Business Objects, Oracle Discoverer, IBM AlphaBlocks i drugi proizvodi uglavnom se koriste kao alati za analizu.

Kako izgledaju komponente poslovnog skladišta podataka (model podataka, ETL procesi, podatkovne vitrine)

Navedimo ilustrativne primjere modela podataka, implementacije ETL procesa, oblika podrške za jedan referentni podatak, podatkovnih prodajnih mjesta.

Logički modelpodaci.
Definira entitete, njihove atribute i odnose među njima.

ETL procesuklanjanje duplikata u izvornim podacima

Obrazac za unos podataka za formiranje jedinstvenog imenika

baza podatakau obliku tabelarnog izvješća

baza podatakasa grafikom i bojom
izlaz podataka prema zadanom uvjetu

baza podatakas rasporedom

Povezani softver i hardver

Prije svega, osim samih usluga za razvoj korporativnog skladišta podataka, prodaju se i licence kako za poslužiteljski softver (OS, baza podataka, aplikacijski poslužitelj itd.) tako i za klijentske stranice (antivirusna zaštita i sigurnosni alati) .

Moguće je da postojeći poslužitelji klijenta nisu dizajnirani za implementaciju skladišta podataka. Za njih je potrebno postaviti zahtjeve i prodati hardver potencijalnom klijentu.

Osim samih poslužitelja, za pohranu značajne količine informacija potrebni su i diskovni nizovi.

Namjeravajući izgraditi korporativno skladište podataka, potencijalni klijent ne razumije uvijek kako će osigurati redundanciju. Često postojeći sustavi sigurnosnog kopiranja klijenta nisu u mogućnosti istovremeno povezati količine podataka od 20-30 TB na sigurnosnu kopiju.

Stručnjaci i korisnici klijenta u pravilu zahtijevaju tečajeve obuke.

Kovtun M.V. kolovoza 2010

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

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

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

1. Relacijski model podataka

1.1 Relacijski model podataka. Osnovne definicije
1.2 Operacije na odnosima

2. Korporativni informacijski sustavi
Bibliografija

1. Relacijski model podataka

1.1 Relacijski model podataka. Osnovne definicije

U matematičkim disciplinama koncept "tablice" odgovara pojmu "relacije" (relacije). Tablica odražava objekt stvarnog svijeta - entitet, a svaki njezin redak odražava određenu instancu entiteta. Svaki stupac ima jedinstveno ime za tablicu. Nizovi nemaju imena, njihov redoslijed nije definiran, a njihov broj nije logički ograničen. Jedna od glavnih prednosti relacijskog modela podataka je homogenost (svaki red tablice ima jedan format). Korisnik sam odlučuje da li odgovarajući entiteti imaju homogenost. Time se rješava problem prikladnosti modela.

Osnovni koncepti:

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

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

* Stupanj odnosa - broj stupaca.

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

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

* Tuple - red tablice.

* Kardinalnost (snaga) - broj redaka u tablici.

* Primarni ključ je atribut koji jedinstveno identificira retke u odnosu. Primarni ključ s više atributa naziva se složeni ključ. Primarni ključ ne može biti potpuno ili djelomično prazan (imati nultu vrijednost). Ključevi koji se mogu koristiti kao primarni ključevi nazivaju se kandidatskim ili alternativnim ključevima.

* Strani ključ je atribut(i) jedne tablice koji može poslužiti kao primarni ključ druge tablice. Je referenca na primarni ključ druge tablice.

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

Nenormalizirana baza podataka sadrži informacije u jednoj ili više različitih tablica; to stvara dojam da uvrštavanje podataka u određenu tablicu nije uzrokovano nekim očitim razlozima. Ovakvo stanje stvari može imati negativan utjecaj na sigurnost podataka, upravljanje prostorom na disku, brzinu upita, učinkovitost ažuriranja baze podataka i, što je možda najvažnije, integritet pohranjenih informacija. Baza podataka prije normalizacije je struktura koja još nije logično razbijena na manje tablice kojima je lakše upravljati.

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

1.2 Operacije na odnosima

Za pretvaranje tablice u prvi normalni oblik (1NF), moraju se poštovati dva pravila:

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

2. Tablica ne smije sadržavati ponavljajuće stupce ili grupe podataka.

Na primjer, ako tablica sadrži punu adresu osobe (ulica, grad, poštanski broj) u jednom polju, neće biti u skladu s pravilima 1NF, jer će sadržavati različite vrijednosti u jednom stupcu, koji će biti kršenje pravila atomicnosti. Ili ako baza podataka sadrži podatke o filmovima i ima stupce glumac1, glumac2, glumac3, također neće zadovoljiti pravila, jer će doći do ponavljanja podataka.

Normalizacija bi trebala započeti provjerom kompatibilnosti strukture baze podataka s 1NF. Svi stupci koji nisu atomski moraju se raščlaniti na sastavne stupce. Ako tablica ima duplicirane stupce, tada im je potrebno dodijeliti zasebnu tablicu.

Za pretvaranje tablice u prvi normalni oblik:

* Pronađite sva polja koja sadrže više informacija.

* Oni podaci koji se mogu raščlaniti na sastavne dijelove moraju se staviti u zasebna polja.

* Premjestite duple podatke u zasebnu tablicu.

* Provjerite odgovaraju li sve tablice uvjetima prvog normalnog oblika.

Za pretvaranje tablica u drugi normalni oblik (2NF), rezultirajuće tablice moraju već biti u 1NF. Normalizacija se mora obaviti redom.

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

Za pretvaranje baze u drugi normalni oblik:

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

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

* Svaka tablica treba svoj primarni ključ

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

Savjeti:

Drugi način da se shema napravi 2NF je da se pogledaju odnosi između tablica. Idealna opcija je stvaranje svih odnosa jedan-prema-više. Odnose mnogo prema mnogo potrebno je restrukturirati.

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

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

Za pretvaranje baze u treći normalni oblik:

* Odrediti u kojim poljima kojih tablica postoji međuovisnost, t.j. polja koja više ovise jedno o drugom nego o nizu u cjelini.

* Napravite relevantne tablice. Ako postoji problematičan stupac u koraku 1, izradite zasebne tablice za njega.

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

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

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

2. Korporativni informacijski sustavi

relacijski model podatkovni sustav

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

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

2. Organizacija sustava - unutarnji poredak, dosljednost u interakciji elemenata sustava, što se očituje, posebice, u ograničavanju raznolikosti stanja elemenata unutar sustava.

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

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

5. Integritet sustava - temeljna nesvodljivost svojstava sustava na zbroj svojstava njegovih pojedinačnih elemenata (nastanak svojstava) i, u isto vrijeme, ovisnost svojstava svakog elementa o njegovoj mjesto i funkcija unutar sustava.

Informacijski sustav je međusobno povezani skup sredstava, metoda i osoblja koji se koriste za pohranu, obradu i izdavanje informacija u svrhu postizanja cilja.

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

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

Klasifikacija ljestvice

Prema mjerilu, informacijski sustavi su podijeljeni u sljedeće skupine:

* samac;

* grupa;

* korporativni.

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

Korporativnim informacijskim sustavom možemo smatrati sustav koji automatizira više od 80% odjela tvrtke.

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

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

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

Za grupne i korporativne sustave značajno su povećani zahtjevi za pouzdanošću rada i sigurnošću podataka. Ova svojstva osiguravaju se održavanjem integriteta podataka, veza i transakcija u poslužiteljima baze podataka.

Klasifikacija po opsegu

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

* sustavi za obradu transakcija;

* sustavi donošenja odluka;

* informacijski i referentni sustavi;

* uredski informacijski sustavi.

Bibliografija

1. Agaltsov, V.P. Baza podataka. U 2 sveska V. 2. Distribuirane i udaljene baze podataka: Udžbenik / V.P. Agalcov. - M.: ID FORUM, SIC INFRA-M, 2013.

2. Golitsyna, O.L. Baze podataka: Udžbenik / O.L. Golitsyna, N.V. Maksimov, I.I. Popov. - M.: Forum, 2012.

3. Karpova, I.P. Baze podataka: Udžbenik / I.P. Karpov. - Sankt Peterburg: Petar, 2013.

4. Kirillov, V.V. Uvod u relacijske baze podataka Uvod u relacijske baze podataka / V.V. Kirillov, G.Yu. Gromov. - Sankt Peterburg: BHV-Peterburg, 2012.

5. Pirogov, V.Yu. Informacijski sustavi i baze podataka: organizacija i dizajn: Udžbenik / V.Yu. Pirogov. - Sankt Peterburg: BHV-Peterburg, 2009.

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

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

Hostirano na Allbest.ru

...

Slični dokumenti

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

seminarski rad, dodan 29.01.2011

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

seminarski rad, dodan 19.01.2011

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

sažetak, dodan 20.12.2010

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

tečaj predavanja, dodano 03.10.2008

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

prezentacija, dodano 14.10.2013

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

sažetak, dodan 19.12.2011

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

kontrolni rad, dodano 08.01.2011

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

znanstveni rad, dodan 08.06.2010

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

seminarski rad, dodan 19.04.2011

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

Zaitsev S.L., dr. sc.

Grupe koje se ponavljaju

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

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

Jedna činjenica na jednom mjestu

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

Svaki atribut ovisi o ključu

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

Formalne definicije normalnih oblika

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č u potpunosti 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.

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

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.

Poslovni normalni oblici

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

Dovršeni logički model podataka

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.

Fizički model podataka

Prikupljanje zahtjeva za korištenje podataka

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 koji istodobno trebaju pristupiti podacima, što vam pomaže 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.

Komponente fizičkog modela podataka

obrnuti inženjering

Korištenje korporativnih funkcionalnih granica

Što je model podataka poduzeća?

Izgradnja modela podataka poduzeća skaliranjem

Koncept metodologije modeliranja

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

IDEF1X (Integration Definition for Information Modeling – 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

Informacijski inženjering

Zaključak

IT profesionalci sve više usmjeravaju svoju pozornost na rješenja za upravljanje podacima temeljena na industrijskim standardnim modelima podataka i predlošcima poslovnih odluka. Složeni modeli fizičkih podataka spremni za učitavanje i izvješća poslovne inteligencije za određena područja aktivnosti omogućuju vam da objedinite informacijsku komponentu poduzeća i značajno ubrzate izvođenje poslovnih procesa. Predlošci rješenja omogućuju pružateljima usluga da iskoriste moć nestandardnih informacija skrivenih u postojećim sustavima, čime se smanjuju rokovi projekta, troškovi i rizici. Na primjer, stvarni projekti pokazuju da model podataka i predlošci poslovnih odluka mogu smanjiti razvojni napor za 50%.

Logički model industrije je domenski specifičan, integriran i logički strukturiran pogled na sve informacije koje moraju biti u korporativnom skladištu podataka kako bi se odgovorilo na strateška i taktička poslovna pitanja. Glavna svrha modela je olakšati orijentaciju u podatkovnom prostoru i pomoći u isticanju detalja važnih za razvoj poslovanja. U današnjem poslovnom okruženju apsolutno je bitno imati jasno razumijevanje odnosa između različitih komponenti i dobro razumijevanje opće slike organizacije. Identifikacija svih detalja i odnosa pomoću modela omogućuje najučinkovitije korištenje vremena i alata za organizaciju rada tvrtke.

Modeli podataka su apstraktni modeli koji opisuju kako su podaci predstavljeni i kako im se pristupa. Modeli podataka definiraju elemente podataka i odnose među njima u danom području. Model podataka je navigacijski alat za poslovne i IT stručnjake koji koristi određeni skup simbola i riječi za točno objašnjenje određene klase stvarnih informacija. To poboljšava komunikaciju unutar organizacije i tako stvara fleksibilnije i stabilnije okruženje aplikacije.

Primjer modela GIS-a za vlast i lokalnu samoupravu.

Danas je strateški važno da davatelji softvera i usluga mogu brzo odgovoriti na promjene u industriji povezane s tehnološkim inovacijama, uklanjanjem državnih ograničenja i složenošću lanaca opskrbe. Usporedo s promjenama u poslovnom modelu raste složenost i cijena informacijske tehnologije nužne za potporu aktivnosti tvrtke. Upravljanje podacima posebno je teško u okruženju u kojem se korporativni informacijski sustavi i njihovi funkcionalni i poslovni zahtjevi neprestano mijenjaju.

Kako bi se olakšao i optimizirao ovaj proces, u prevođenju IT pristupa na modernu razinu, koriste se industrijski modeli podataka.

Modeli podataka o industriji iz tvrtkeEsri

Modeli podataka za platformu Esri ArcGIS su radni predlošci za korištenje u GIS projektima i kreiranje struktura podataka za različita područja primjene. Izgradnja modela podataka uključuje stvaranje konceptualnog dizajna, logičke strukture i fizičke strukture koje se zatim mogu koristiti za izgradnju osobne ili korporativne baze geopodataka. ArcGIS pruža alate za kreiranje i upravljanje shemom baze podataka, a predlošci modela podataka se koriste za brzo pokretanje GIS projekta u različitim aplikacijama i industrijama. Esri je, zajedno sa zajednicom korisnika, proveo značajnu količinu vremena razvijajući niz predložaka koji vam mogu pomoći da brzo počnete dizajnirati poduzetničku bazu geopodataka. Ovi projekti su opisani i dokumentirani na support.esri.com/datamodels. U nastavku, redoslijedom kojim se pojavljuju na ovoj stranici, nalaze se semantički prijevodi naziva Esrijevih industrijskih modela:

Adresni registar
Poljoprivreda
Meteorologija
Osnovni prostorni podaci
bioraznolikost
Unutarnji prostor zgrada
Računovodstvo stakleničkih plinova
Održavanje administrativnih granica
Vojni establišment. Obavještajna služba
Energija (uključujući novi ArcGIS MultiSpeak protokol)
Ekološke zgrade
Ministarstvo za izvanredne situacije. zaštita od požara
Katastar šuma
Šumarstvo
Geologija
GIS na nacionalnoj razini (e-gov)
Podzemne i otpadne vode
zdravstvo
Arheologija i zaštita spomen-područja
nacionalna sigurnost
Hidrologija
Međunarodna hidrografska organizacija (IHO). S-57 format za ENC
Navodnjavanje
Zemljišne knjige
općinska vlast
Pomorska plovidba
Državni katastar
Naftne i plinske konstrukcije
Cjevovodi
Prodavaonice rastera
Batimetrija, topografija morskog dna
Telekomunikacija
Prijevoz
Vodovod, kanalizacija, komunalije

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

su slobodno dostupni;
nisu vezani uz tehnologiju "odabranog" proizvođača;
nastala kao rezultat provedbe stvarnih projekata;
stvoreno uz sudjelovanje stručnjaka iz industrije;
dizajniran za pružanje informacijske interakcije između različitih proizvoda i tehnologija;
ne proturječe drugim standardima i regulatornim dokumentima;
koristi se u implementiranim projektima diljem svijeta;
dizajnirani su za rad s informacijama tijekom životnog ciklusa sustava koji se stvara, a ne samog projekta;
proširivo prema potrebama kupca bez gubitka kompatibilnosti s drugim projektima i/ili modelima;
popraćeno dodatnim materijalima i primjerima;
koristi se u smjernicama i tehničkim materijalima raznih industrijskih poduzeća;
velika zajednica sudionika, dok je pristup zajednici otvoren svima;
veliki broj referenci na modele podataka u publikacijama posljednjih godina.

Esri je dio stručne skupine neovisnih tijela koja preporučuju različite industrijske modele za korištenje, kao što je PODS (Pipeline Open Data Standards - otvoreni standard za industriju nafte i plina; trenutno postoji implementacija PODS-a kao Esri PODS Esri Spatial 5.1.1 geodatabase) ili baza geopodataka (GDB) iz ArcGIS for Aviation koja uzima u obzir preporuke ICAO-a i FAA-e, kao i AIXM 5.0 standard za razmjenu navigacijskih podataka. Osim toga, postoje preporučeni modeli koji se strogo pridržavaju postojećih industrijskih standarda, kao što su S-57 i ArcGIS for Maritime (pomorske i obalne značajke), kao i modeli izrađeni iz rada Esri Professional Services, koji su "de facto" standardima u relevantnim područjima. Na primjer, GIS za državu i lokalnu samoupravu utjecao je na standarde NSDI i INSPIRE, dok se Hydro i podzemne vode uvelike koriste u besplatno dostupnom profesionalnom paketu ArcHydro i komercijalnim proizvodima trećih tvrtki. Treba napomenuti da Esri također podržava "de facto" standarde kao što je NHDI. Svi predloženi modeli podataka dokumentirani su i spremni za korištenje u IT procesima poduzeća. Prateći materijali za modele uključuju:

UML dijagrami odnosa entiteta;
strukture podataka, domene, imenici;
gotovi predlošci geopodataka u ArcGIS GDB formatu;
uzorci podataka i uzorci aplikacija;
primjeri skripti za učitavanje podataka, primjeri alata za analizu;
priručnike o predloženoj strukturi podataka.

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

Arhitektura orijentirana na geoprostorne usluge (SOA);
Projektiranje baza geopodataka za transport;
Korporativni geoinformacijski sustavi;
GIS: nova energija elektro i plinskih poduzeća;
Nafta i plin na digitalnoj karti;
Modeliranje našeg svijeta. Vodič za dizajn Esri baze geodata;
Razmišljam o GIS-u. GIS planiranje: vodič za menadžere;
Geografski informacijski sustavi. Osnove;
GIS za administrativno i gospodarsko upravljanje;
Web GIS. Načela i primjena;
Strategije dizajna sustava, 26. izdanje;
68 brojeva časopisa ArcReview s publikacijama tvrtki i korisnika GIS sustava;
... i mnoge druge tematske bilješke i publikacije.

Na primjer, knjiga Modeliranje našeg svijeta..."(prijevod) je sveobuhvatan vodič i referentni vodič za GIS modeliranje podataka općenito, a posebno model podataka geobaze podataka. Knjiga pokazuje kako donijeti ispravne odluke o modeliranju podataka, odluke koje su uključene u svaki aspekt GIS projekta: od podataka dizajna baze podataka i prikupljanja podataka do prostorne analize i vizualizacije Detaljno opisuje kako dizajnirati geografsku bazu podataka prikladnu za projekt, postaviti funkcionalnost baze podataka bez programiranja, upravljati tijekom rada u složenim projektima, modelirati različite mrežne strukture kao što su rijeka, promet ili električne mreže, integrirati podatke satelitskih snimaka u geografsku analizu i mapiranje te izraditi 3D GIS modele podataka. Projektiranje baza geopodataka za transport"sadrži metodološke pristupe koji su testirani na velikom broju projekata i u potpunosti su u skladu sa zakonskim zahtjevima Europe i Sjedinjenih Država, kao i međunarodnim standardima. I u knjizi " GIS: nova energija elektro i plinskih poduzeća Koristeći primjere iz stvarnog svijeta, pokazuje prednosti koje GIS poduzeća može donijeti dobavljaču energije, uključujući aspekte kao što su korisnička usluga, rad mreže i drugi poslovni procesi.

Neke od knjiga, prevedene i originalne, na ruskom su izdale Esri CIS i DATA+. Oni pokrivaju konceptualna pitanja vezana uz GIS tehnologiju i mnoge primijenjene aspekte modeliranja i implementacije GIS-a različitih razmjera i namjena.

Razmotrit ćemo korištenje industrijskih modela koristeći podatkovni model BISDM (Building Interior Space Data Model) verzije 3.0 kao primjer. BISDM je razvoj općenitijeg BIM modela (Building Information Model, zgrada informacijski model) i namijenjen je za korištenje u projektiranju, izgradnji, radu i razgradnji zgrada i građevina. Koristi se u GIS softveru, omogućuje vam učinkovitu razmjenu geopodataka s drugim platformama i interakciju s njima. Odnosi se na opću radnu grupu FM (upravljanje infrastrukturom organizacije). Navodimo glavne prednosti BISDM modela, čija upotreba omogućuje:

organizirati razmjenu informacija u heterogenom okruženju prema jedinstvenim pravilima;
dobiti "fizičko" utjelovljenje BIM koncepta i preporučena pravila za upravljanje građevinskim projektom;
održavati jedno spremište koristeći GIS alate tijekom cijelog životnog ciklusa zgrade (od projektiranja do stavljanja izvan pogona);
koordinirati rad različitih stručnjaka na projektu;
vizualizirati planirani raspored i faze izgradnje za sve sudionike;
dati preliminarnu procjenu troškova i vremena izgradnje (4D i 5D podaci);
kontrolirati napredak projekta;
osigurati kvalitetan rad zgrade, uključujući održavanje i popravke;
postati dio sustava upravljanja imovinom, uključujući funkcije analize učinkovitosti korištenja prostora (iznajmljivanje, skladišta, upravljanje zaposlenicima);
izračunati i upravljati energetskom učinkovitošću zgrade;
simulirati kretanje ljudskih tokova.

BISDM definira pravila za rad s prostornim podacima na razini unutarnjih prostorija u zgradi, uključujući namjenu i vrste korištenja, položene komunikacije, instaliranu opremu, računovodstvo popravaka i održavanja, evidentiranje incidenata, odnose s ostalom imovinom tvrtke. Model pomaže u stvaranju jedinstvenog repozitorija geografskih i negeografskih podataka. Iskustva vodećih svjetskih tvrtki korištena su za izolaciju entiteta i modeliranje na razini GDB (geodatabaze) prostornih i logičkih odnosa svih fizičkih elemenata koji čine kako samu zgradu tako i njezin interijer. Slijeđenje načela BISDM-a omogućuje vam da značajno pojednostavite zadatke integracije s drugim sustavima. U prvoj fazi to je obično integracija s CAD-om. Zatim se tijekom rada zgrade koristi razmjena podataka s ERP i EAM sustavima (SAP, TRIRIGA, Maximo i dr.).

Vizualizacija BISDM strukturnih elemenata korištenjem ArcGIS-a.

U slučaju korištenja BISDM-a, kupac/vlasnik objekta dobiva end-to-end razmjenu informacija od ideje stvaranja objekta do izrade cjelovitog projekta, kontrole izgradnje uz dobivanje do - podatke o datumu do puštanja objekta u pogon, kontrolu parametara tijekom rada, pa čak i tijekom rekonstrukcije ili stavljanja objekta iz pogona. Slijedeći BISDM paradigmu, GIS i GDB stvoreni uz njegovu pomoć postaju zajedničko spremište podataka za povezane sustave. Često se u GDB-u nalaze podaci stvoreni i kojima upravljaju sustavi trećih strana. To se mora uzeti u obzir pri projektiranju arhitekture sustava koji se stvara.

U određenoj fazi, akumulirana "kritična masa" informacija omogućuje vam prelazak na novu kvalitativnu razinu. Na primjer, po završetku faze projektiranja nove zgrade moguće je automatski vizualizirati 3D modele snimanja u GIS-u, sastaviti popis opreme za ugradnju, izračunati kilometre inženjerskih mreža koje treba postaviti, izvršiti niz provjera , pa čak i dati preliminarnu financijsku procjenu troškova projekta.

Još jednom, kada se zajedno koriste BISDM i ArcGIS, postaje moguće automatski graditi 3D modele iz akumuliranih podataka, budući da GDB sadrži potpuni opis objekta, uključujući z-koordinate, pripadnost katu, vrste veza elemenata, opremu način ugradnje, materijal, raspoloživi putovi kretanja osoblja, funkcionalna namjena svakog elementa itd. itd. Treba napomenuti da se nakon početnog uvoza svih dizajnerskih materijala u BISDM GDB javlja potreba za dodatnim sadržajem za:

postavljanje 3D modela predmeta i opreme na za to predviđena mjesta;
prikupljanje informacija o cijeni materijala i postupku njihova polaganja i ugradnje;
kontrola prohodnosti prema dimenzijama ugrađene nestandardne opreme.

Korištenjem ArcGIS-a pojednostavljen je uvoz dodatnih 3D objekata i priručnika iz vanjskih izvora. Modul ArcGIS Data Interoperability vam omogućuje stvaranje postupaka za uvoz takvih podataka i njihovo ispravno postavljanje unutar modela. Podržani su svi formati koji se koriste u industriji, uključujući IFC, AutoCAD Revit, Bentlye Microstation.

Industrijski podatkovni modeli iz IBM-a

IBM nudi skup alata i modela za upravljanje pohranom za različite industrije:

IBM bankarstvo i skladište podataka o financijskim tržištima (financije)
IBM bankovno skladište podataka
IBM bankarski procesi i modeli usluga
IBM Health Plan Data Model (zdravlje)
IBM-ovo skladište informacija o osiguranju (osiguranje)
IBM procesi i modeli usluga osiguranja
IBM maloprodajno skladište podataka (maloprodaja)
IBM telekomunikacijsko skladište podataka (telekomunikacije)
InfoSphere Warehouse Pack:
- za uvid u klijente (za razumijevanje kupaca)
- za uvid u tržište i kampanju (za razumijevanje tvrtke i tržišta)
- za Supply Chain Insight (za razumijevanje dobavljača).

Na primjer, model IBMbankarstvoiFinancijskitržištaPodaciSkladište dizajniran za rješavanje specifičnih izazova bankarske industrije u smislu podataka, i IBMbankarstvopostupakiServisModeli- u smislu procesa i SOA (uslužno orijentirana arhitektura). Predstavljeni modeli za telekomunikacijsku industriju IBMinformacijaOkvir(IFW) i IBMTelekomunikacijaPodaciskladište (TDW). Oni pomažu značajno ubrzati proces izrade analitičkih sustava, kao i smanjiti rizike povezane s razvojem aplikacija poslovne inteligencije, upravljanjem korporativnim podacima i organizacijom skladišta podataka, uzimajući u obzir specifičnosti telekomunikacijske industrije. IBM TDW mogućnosti pokrivaju cijeli spektar telekomunikacijskog tržišta - od internetskih davatelja i operatera kabelske mreže koji nude usluge žične i bežične telefonije, prijenosa podataka i multimedijskih sadržaja, do multinacionalnih kompanija koje pružaju telefonske, satelitske, međugradske i međunarodne komunikacijske usluge, kao i kao organizacije globalne mreže. Danas TDW koriste veliki i mali pružatelji žičanih i bežičnih usluga diljem svijeta.

Alat se zove InfoSphere Warehouse Pack za uvid u kupca je strukturiran i lako implementiran poslovni sadržaj za sve veći broj poslovnih projekata i industrija, uključujući bankarstvo, osiguranje, financije, programe zdravstvenog osiguranja, telekomunikacije, maloprodaju i distribuciju. Za poslovne korisnike InfoSphere Warehouse Pack za uvid u tržište i kampanju pomaže vam maksimalno povećati učinkovitost tržišne inteligencije i marketinških kampanja kroz razvojni proces korak po korak i proces specifičan za poslovanje. Preko InfoSphere Warehouse Pack za uvid u lanac opskrbe organizacije imaju mogućnost dobivanja trenutnih informacija o operacijama lanca opskrbe.

Esrijeva pozicija unutar arhitekture IBM rješenja.

Posebno treba istaknuti IBM-ov pristup komunalnim i komunalnim poduzećima. Kako bi zadovoljile rastuće zahtjeve kupaca, komunalna poduzeća trebaju fleksibilniju arhitekturu nego što je danas koriste, kao i industrijski standardni objektni model koji olakšava slobodnu razmjenu informacija. To će poboljšati komunikacijske sposobnosti energetskih tvrtki, omogućiti im isplativiju komunikaciju, a novim sustavima dati bolju vidljivost svih potrebnih resursa, bez obzira na to gdje se nalaze unutar organizacije. Osnova za ovaj pristup je SOA (Service Oriented Architecture), komponentni model koji uspostavlja korespondenciju između funkcija odjela i usluga različitih aplikacija koje se mogu ponovno koristiti. "Usluge" ovih komponenti komuniciraju putem sučelja bez tvrdog povezivanja, skrivajući od korisnika svu složenost sustava iza njih. U ovom načinu rada poduzeća mogu jednostavno dodavati nove aplikacije bez obzira na dobavljača softvera, operativni sustav, programski jezik ili druge intrinzične karakteristike softvera. Koncept je implementiran na temelju SOA-e SIGURNO ( Arhitektura rješenja za energiju, omogućuje komunalnoj industriji da stekne holistički pogled na svoju infrastrukturu utemeljen na standardima.

Esri ArcGIS® je globalno priznata softverska platforma za geografske informacijske sustave (GIS), koja omogućuje kreiranje i upravljanje digitalnom imovinom električne energije, plina za prijenos, distribuciju i telekomunikacijske mreže. ArcGIS vam omogućuje provođenje najpotpunijeg popisa komponenti električne distribucijske mreže, uzimajući u obzir njihov prostorni položaj. ArcGIS uvelike proširuje IBM SAFE arhitekturu pružajući alate, aplikacije, tijekove rada, analitiku te informacije i integracijske mogućnosti potrebne za upravljanje pametnom mrežom. ArcGIS unutar IBM SAFE omogućuje vam primanje informacija iz različitih izvora o infrastrukturnim objektima, imovini, kupcima i zaposlenicima s točnim podacima o njihovoj lokaciji, kao i stvaranje, pohranjivanje i obradu georeferenciranih informacija o imovini poduzeća (stupovi, cjevovodi, žice, transformatori, kabelski kanali itd.). ArcGIS unutar SIGURNE infrastrukture omogućuje vam dinamičko kombiniranje ključnih poslovnih aplikacija kombiniranjem podataka iz GIS-a, SCADA-e i sustava za korisničku podršku s vanjskim informacijama kao što su promet, vremenski uvjeti ili satelitske slike. Komunalne usluge koriste ove kombinirane informacije u razne svrhe, od C.O.R. (velika slika operativnog okruženja) do inspekcija mjesta, održavanja, analize i planiranja mreže.

Informacijske komponente poduzeća za opskrbu električnom energijom mogu se modelirati korištenjem nekoliko razina, koje se kreću od najniže - fizičke - do najviše, najsloženije razine logike poslovnog procesa. Ovi slojevi se mogu integrirati kako bi se zadovoljili tipični zahtjevi industrije kao što su automatizirano bilježenje mjerenja i nadzorna kontrola i kontrola prikupljanja podataka (SCADA). Izgradnjom SAFE arhitekture, komunalna poduzeća čine značajan napredak u unapređenju modela otvorenog objekta u cijeloj industriji pod nazivom Common Information Model (CIM) za energetiku i komunalne usluge. Ovaj model pruža potrebnu osnovu za pomicanje mnogih poduzeća prema uslužno orijentiranoj arhitekturi, budući da potiče korištenje otvorenih standarda za strukturiranje podataka i objekata. Ako svi sustavi koriste iste objekte, zbrka i neelastičnost povezana s različitim implementacijama istih objekata bit će svedena na minimum. Tako će se definicija objekta "kupac" i drugih važnih poslovnih objekata ujediniti u svim sustavima elektroenergetske tvrtke. Uz CIM, davatelji usluga i korisnici usluga sada mogu dijeliti zajedničku strukturu podataka, što olakšava outsource skupih poslovnih komponenti jer CIM uspostavlja zajedničku bazu na kojoj se može izgraditi dijeljenje informacija.

Zaključak

Sveobuhvatni industrijski modeli podataka pružaju tvrtkama jedinstven, integrirani prikaz njihovih poslovnih informacija. Mnogim tvrtkama je teško integrirati svoje podatke, iako je to preduvjet za većinu projekata u cijelom poduzeću. Prema studiji The Data Warehousing Institute (TDWI), više od 69% anketiranih organizacija smatra da je integracija značajna prepreka usvajanju novih aplikacija. Naprotiv, implementacija integracije podataka donosi tvrtki opipljiv prihod i povećanu učinkovitost.

Dobro izgrađen model na jedinstven način definira značenje podataka, koji su u ovom slučaju strukturirani podaci (za razliku od nestrukturiranih podataka kao što su slika, binarna datoteka ili tekst, gdje vrijednost može biti dvosmislena). Najučinkovitije industrijske modele nude profesionalni dobavljači, uključujući Esri i IBM. Visoki povrati od korištenja njihovih modela postižu se zahvaljujući njihovoj značajnoj razini detalja i točnosti. Obično sadrže mnogo atributa podataka. Osim toga, stručnjaci iz Esrija i IBM-a ne samo da imaju veliko iskustvo u modeliranju, već su također dobro upućeni u izgradnju modela za određenu industriju.

Arhitektura baze podataka

CMD shema je opis strukture modela podataka sa stajališta administratora.

AMD shema je opis internog ili fizičkog modela. Pohranjuje opis fizičke lokacije podataka na mediju. Shema pohranjuje izravne naznake lokacije podataka u memoriji (volumen, diskovi).

CMD shema opisuje strukturu podataka, zapisa i polja.

Svi DBMS podržavaju tri glavne vrste modela podataka:

1. Hijerarhijski model. Pretpostavlja neki root unos. Grane dolaze iz korijena.

Nisu svi objekti prikladno opisani na ovaj način. U hijerarhiji nema veza, a karakteristična je velika redundantnost informacija.

2. Mrežni model. Omogućuje vam da ispravno prikažete svu složenost odnosa.

Model je prikladan za predstavljanje poveznica s podacima iz vanjskog okruženja, ali manje zgodan za opisivanje u bazi, što dovodi do dodatnog rada korisnika na proučavanju navigacije kroz poveznice.

3. Relacijski model. Temelji se na matematičkom terminu Relation – relacija, ali jednostavno – tablica. Na primjer, pravokutni dvodimenzionalni.

Relacijsku strukturu podataka razvili su kasnih 60-ih godina brojni istraživači, od kojih je najznačajniji doprinos dao zaposlenik IBM-a Edgar Codd. Relacijskim pristupom podaci se prikazuju u obliku dvodimenzionalnih tablica – najprirodnije za osobu. Istodobno, za obradu podataka Codd je predložio korištenje aparata teorije skupova - unija, presjek, razlika, kartezijanski proizvod.

Vrsta podataka- ovaj koncept ima isto značenje kao u programskim jezicima (tj. tip podataka određuje interni prikaz u memoriji računala i način na koji se instanca podataka pohranjuje, kao i skup vrijednosti koje instanca podataka može uzeti i skup valjanih podatkovnih operacija). Sve postojeće moderne baze podataka podržavaju posebne vrste podataka dizajnirane za pohranu podataka cjelobrojnog tipa, razlomka s pomičnim zarezom, znakova i nizova, kalendarskih datuma. Mnogi poslužitelji baza podataka implementiraju druge tipove, na primjer, Interbase poslužitelj ima poseban tip podataka za pohranu velikih binarnih informacijskih nizova (BLOB-ova).

Domena je potencijalni skup vrijednosti jednostavnog tipa podataka, sličan je podtipu podataka u nekim programskim jezicima. Domena je definirana s dva elementa - tipom podataka i booleovim izrazom koji se primjenjuje na podatke. Ako ovaj izraz ima vrijednost true, tada instanca podataka pripada domeni.

Stav je dvodimenzionalna tablica posebne vrste, koja se sastoji od zaglavlja i tijela.

Zaglavlje je fiksni skup atributa, od kojih je svaki definiran na nekoj domeni, a između atributa i definirajućih domena postoji korespondencija jedan na jedan.

Svaki atribut je definiran na vlastitoj domeni. Domena je cjelobrojni tip podataka, a booleov uvjet je n>0. Naslov je bezvremenski, za razliku od tijela relacije. Tijelo veze- je zbirka torke, od kojih je svaki par atribut-vrijednost.

Snagom odnosa je broj njegovih torki, i stupanj stava je broj atributa.

Stupanj omjera je konstantna vrijednost za dati omjer, dok snaga omjera varira s vremenom. Snaga omjera naziva se i kardinalni broj.

Navedeni koncepti su teoretski i koriste se u razvoju jezičnih alata i softverskih sustava za relacijske DBMS. U svakodnevnom radu umjesto njih koriste se njihovi neformalni ekvivalenti:

stav - stol;

atribut - stupac ili polje;

tuple - zapis ili linija.

Dakle, stupanj relacije je broj stupaca u tablici, a kardinalni broj je broj redaka.

Budući da je relacija skup, a u klasičnoj teoriji skupova, po definiciji, skup ne može sadržavati podudarne elemente, relacija ne može imati dvije identične torke. Stoga, za danu relaciju, uvijek postoji skup atributa koji jedinstveno identificiraju tuple. Ovaj skup atributa se zove ključ.

Ključ mora ispunjavati sljedeće zahtjeve:

mora biti jedinstven;

· mora biti minimalan, odnosno uklanjanje bilo kojeg atributa iz ključa dovodi do kršenja jedinstvenosti.

U pravilu je broj atributa u ključu manji od stupnja relacije, ali u ekstremnim slučajevima ključ može sadržavati sve atribute, budući da kombinacija svih atributa zadovoljava uvjet jedinstvenosti. Tipično, relacija ima više ključeva. Od svih ključeva relacije (koji se nazivaju i "mogući ključevi"), jedan se bira kao glavni ključ. Prilikom odabira glavni ključ prednost se obično daje ključu s najmanjim brojem atributa. Također je neprikladno koristiti ključeve s dugim nizovima vrijednosti.

U praksi se kao primarni ključ često koristi poseban numerički atribut - nula s automatskim povećanjem, čiju vrijednost može generirati okidač (okidač je posebna procedura koja se poziva kada se izvrše promjene u bazi podataka) ili posebnim sredstvima definiranim u mehanizmu DBMS.

Koncepti opisani u ovom poglavlju nisu specifični za bilo koju implementaciju baze podataka, ali su zajednički za sve njih. Dakle, ovi koncepti su osnova određenog općeg modela, koji se naziva relacijski model podataka.

Utemeljitelj relacijskog pristupa, Date, ustanovio je da se relacijski model sastoji od tri dijela:

strukturni;

· manipulativno;

holistički.

Relacije su fiksne u strukturnom dijelu modela kao jedina struktura podataka koja se koristi u relacijskom modelu.

U manipulacijskom dijelu fiksirana su dva osnovna mehanizma za manipulaciju relacijskim bazama podataka – relacijska algebra i relacijski račun.

Sastavni dio shvaća se kao određeni mehanizam za osiguranje neuništivosti podataka. Dio integriteta uključuje dva osnovna zahtjeva integriteta za relacijske baze podataka - integritet entiteta i referentni integritet.

Zahtjev integritet entiteta je da se bilo koja torka bilo koje relacije mora razlikovati od bilo koje druge torke ove relacije, to jest, drugim riječima, svaka relacija mora imati primarni ključ. Ovaj zahtjev mora biti zadovoljen ako su zadovoljena osnovna svojstva odnosa.

U jeziku za manipulaciju podacima, kao iu jeziku upita, izvodi se matematički aparat nazvan algebra relacija za koji su definirane sljedeće radnje:

1. Standardne operacije: - presjek, - unija, \ - razlika, X - Dekartov proizvod.

2. Specifično: projekcija, ograničenje, veza, podjela.

a. Udruga.

SD SHM EI HP

R 1 (šifra dijela, šifra materijala, mjerne jedinice, stopa potrošnje)

R 2 (SHD, SHM, EI, HP)

Treba pronaći

Trebalo bi spojiti skupove R 1 i R 2 . U ovoj operaciji, stupanj je sačuvan, a kardinalnost rezultirajućeg skupa

b. križanje.

Istaknite odgovarajuće linije.

c. Razlika.

Isključi iz R 1 torki koji odgovaraju R 2 .

d. Kartezijanski proizvod.

Ovdje se tuple spajaju.

Svaki red jednog skupa povezan je sa svakim redom drugog.

S obzirom na dva seta:

Kartezijanski proizvod ima sljedeći oblik:

U ovom slučaju, S-stupanj je, a, t.j. dobijete 12 redaka i 5 stupaca.

Korporativna baza podataka središnja je poveznica korporativnog informacijskog sustava i omogućuje stvaranje jedinstvenog korporativnog informacijskog prostora. Korporativne baze podataka

Podijelite rad na društvenim mrežama

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

TEMA V KORPORATIVNE BAZE PODATAKA

V .jedan. Organizacija podataka u korporativnim sustavima. Korporativne baze podataka.

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

V.3. Internet / Intranet tehnologije i rješenja za pristup korporativnim bazama podataka.

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

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

Postoje različite definicije baza podataka.

Pod bazom podataka (DB) razumjeti skup informacija logički povezanih na način da čine jedan skup podataka pohranjenih u uređajima za pohranu računala. Ovaj skup djeluje kao početni podaci zadataka rješavanih u procesu funkcioniranja automatiziranih upravljačkih sustava, sustava za obradu podataka, informacijskih i računalnih sustava.

Pojam baze podataka možete ukratko formulirati kao zbirku logički povezanih podataka namijenjenih dijeljenju.

Pod bazom podataka odnosi se na zbirku podataka pohranjenih zajedno s minimalnom redundantnošću tako da se može optimalno koristiti za jednu ili više aplikacija.

Svrha izrade baza podataka kao oblik pohrane podataka izgradnja podatkovnog sustava koji ne ovisi o usvojenim algoritmima (softveru), korištenim tehničkim sredstvima, fizičkom položaju podataka u računalu. Baza podataka pretpostavlja višenamjensko korištenje (više korisnika, više oblika dokumenata i upiti jednog korisnika).

Osnovni zahtjevi baze podataka:

Potpunost prikaza podataka. Podaci u bazi podataka trebaju adekvatno predstavljati sve informacije o objektu i trebaju biti dovoljni za ODS.
Integritet baze podataka. Podaci se moraju čuvati tijekom obrade njihovih ODS-a iu svim situacijama koje nastanu tijekom rada.
Fleksibilnost strukture podataka. Baza podataka treba omogućiti promjenu strukture podataka bez narušavanja njezinog integriteta i cjelovitosti kada se vanjski uvjeti promijene.
Realizabilnost. To znači da mora postojati objektivan prikaz različitih objekata, njihovih svojstava i odnosa.
Dostupnost. Potrebno je osigurati diferencijaciju pristupa podacima.
redundancija. Baza podataka treba imati minimalnu redundantnost u predstavljanju podataka o bilo kojem objektu.

Znanje se razumije skup činjenica, obrazaca i heurističkih pravila pomoću kojih možete riješiti problem.

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

treba razlikovati različiti načini prezentiranja podataka.

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

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

Pod korporativnom bazom podataka razumjeti bazu podataka koja u jednom ili drugom obliku objedinjuje sve potrebne podatke i znanja o automatiziranoj organizaciji. U korporativnim informacijskim sustavima takav koncept kaointegrirane baze podataka, u kojem se provodi načelo jednokratnog unosa i višestruke upotrebe informacija.

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

Korporativne baze podataka su usredotočeno (centralizirana) i distribuiran.

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

sl.1.2. Dijagram heterogenog centralizirana baza podataka

Centralizacija obrade informacija omogućila je uklanjanje takvih nedostataka tradicionalnih datotečnih sustava kao što su nekoherentnost, nedosljednost i redundantnost podataka. Međutim, kako baze podataka rastu, a posebno kada se koriste u geografski raspršenim organizacijama, pojavljuju se problemi. Na primjer, za koncentrirane baze podataka smještene u čvoru telekomunikacijske mreže, preko kojih različiti odjeli organizacije pristupaju podacima, s povećanjem količine informacija i broja transakcija, javljaju se sljedeće poteškoće:

Veliki protok razmjene podataka;
Visok mrežni promet;
Niska pouzdanost;
Niska ukupna izvedba.

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

Veći stupanj simultanosti obrade zbog dijeljenja opterećenja;
Poboljšanje korištenja podataka na terenu pri izvođenju udaljenih (udaljenih) upita;
niži troškovi;
Jednostavan za upravljanje lokalnim bazama podataka.

Troškovi stvaranja mreže s radnim stanicama (malim računalima) na svojim čvorovima puno su niži od troškova stvaranja sličnog sustava pomoću glavnog računala. Slika 1.3 prikazuje logički dijagram distribuirane baze podataka.

sl.1.3. Distribuirana korporativna baza podataka.

Dajemo sljedeću definiciju distribuirane baze podataka.

Distribuirana baza podataka - ovo je zbirka informacija, datoteka (relacija) pohranjenih u različitim čvorovima informacijske mreže i logički povezanih na način da čine jedan skup podataka (veza može biti funkcionalna ili preko kopija iste datoteke). Dakle, radi se o skupu baza podataka koje su logički međusobno povezane, ali fizički smještene na više strojeva koji su dio iste računalne mreže.

Najvažniji zahtjevi za karakteristike distribuirane baze podataka su sljedeći:

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

Transparentnost lokacije omogućuje korisnicima da rade s bazama podataka bez da znaju ništa o svojoj lokaciji. Autonomija čvorova distribuirane baze podataka znači da se svaka baza podataka može održavati neovisno o drugima. Distribuirani upit je upit (SQL izraz) tijekom kojeg dolazi do pristupa objektima (tablicama ili pogledima) različitih baza podataka. Prilikom izvršavanja distribuiranih transakcija, kontrola konkurentnosti se provodi nad svim uključenim bazama podataka. Oracle7 koristi dvofaznu tehnologiju prijenosa informacija za obavljanje distribuiranih transakcija.

Baze podataka koje čine distribuiranu bazu podataka ne moraju biti homogene (tj. pokretane od strane istog DBMS-a) ili se izvoditi u istom okruženju operacijskog sustava i/ili na istoj vrsti računala. Na primjer, jedna baza podataka može biti Oracle baza podataka na SUN računalu sa SUN OS(UNIX), drugu bazu podataka može pokrenuti DB2 DBMS na IBM 3090 glavnom računalu s MVS operativnim sustavom, a treću bazu podataka može pokrenuti SQL/DS DBMS također na IBM glavnom računalu, ali s VM operativnim sustavom. Samo jedan uvjet je obavezan - svi strojevi s bazama podataka moraju biti dostupni preko mreže čiji su dio.

Glavni zadatak distribuirane baze podataka – distribucija podataka preko mreže i omogućavanje pristupa njima. Postoje sljedeći načini rješavanja ovog problema:

Svaki čvor pohranjuje i koristi vlastiti skup podataka koji je dostupan za udaljene upite. Ova distribucija je podijeljena.
Neki podaci koji se često koriste na udaljenim mjestima mogu biti duplicirani. Takva distribucija naziva se djelomično duplicirana.
Svi podaci se dupliciraju u svakom čvoru. Takva se distribucija naziva potpuno redundantnom.
Neke datoteke mogu se podijeliti vodoravno (odabran je podskup zapisa) ili okomito (odabran je podskup atributnih polja), dok su podijeljeni podskupovi pohranjeni u različitim čvorovima zajedno s nepodijeljenim podacima. Takva se raspodjela naziva podijeljena (fragmentirana).

Prilikom izrade distribuirane baze podataka na konceptualnoj razini morate riješiti sljedeće zadatke:

Potrebno je imati jedinstvenu idejnu shemu za cijelu mrežu. To će korisniku osigurati logičku transparentnost podataka, zbog čega će moći formirati zahtjev za cijelu bazu podataka, nalazeći se na zasebnom terminalu (radi, takoreći, s centraliziranom bazom podataka).
Za lociranje podataka na mreži potrebna je shema. To će osigurati transparentnost u postavljanju podataka tako da korisnik ne mora specificirati kamo će proslijediti zahtjev kako bi dobio tražene podatke.
Potrebno je riješiti problem heterogenosti distribuiranih baza podataka. Distribuirane baze podataka mogu biti homogene ili heterogene u smislu hardvera i softvera. Problem heterogenosti relativno je lako riješiti ako je distribuirana baza podataka hardverski heterogena, ali softverski homogena (isti DBMS u čvorovima). Ako se u čvorovima distribuiranog sustava koriste različiti DBMS, potrebna su sredstva za pretvaranje struktura podataka i jezika. To bi trebalo osigurati transparentnost transformacije u čvorovima distribuirane baze podataka.
Potrebno je riješiti problem upravljanja rječnicima. Za pružanje svih vrsta transparentnosti u distribuiranoj bazi podataka, potrebni su programi koji upravljaju brojnim rječnicima i referentnim knjigama.
Potrebno je definirati metode za izvršavanje upita u distribuiranoj bazi podataka. Metode za izvršavanje upita u distribuiranoj bazi podataka razlikuju se od sličnih metoda u centraliziranim bazama podataka, budući da se pojedini dijelovi upita moraju izvršiti na mjestu odgovarajućih podataka i prenijeti djelomične rezultate na druge čvorove; istodobno treba osigurati koordinaciju svih procesa.
Potrebno je riješiti problem paralelnog izvršavanja upita. U distribuiranoj bazi podataka potreban je složen mehanizam za upravljanje istodobnom obradom, koji posebno mora osigurati sinkronizaciju prilikom ažuriranja informacija, što jamči konzistentnost podataka.
Potreba za razvijenom metodologijom za distribuciju i smještaj podataka, uključujući dijeljenje, jedan je od glavnih zahtjeva za distribuiranu bazu podataka.

Jedno od aktivno razvijajućih novih područja arhitekture računalnih sustava, koje je moćan alat za nenumeričku obradu informacija, su strojevi za baze podataka. Strojevi za baze podataka koriste se za rješavanje nenumeričkih zadataka, kao što su pohranjivanje, pretraživanje i transformacija dokumenata i činjenica, rad s objektima. Slijedom definicije podataka kao digitalnih i grafičkih informacija o objektima okolnog svijeta, u pojam podataka u numeričkoj i nenumeričkoj obradi ugrađuju se različiti sadržaji. Numerička obrada koristi objekte kao što su varijable, vektori, matrice, višedimenzionalni nizovi, konstante i tako dalje, dok nenumerička obrada koristi objekte kao što su datoteke, zapisi, polja, hijerarhije, mreže, odnosi i tako dalje. numerička obrada bavi se izravno informacijama o objektima (na primjer, određenom zaposleniku ili skupini zaposlenika), a ne samom datotekom zaposlenika. Ne indeksira datoteku zaposlenika za odabir određene osobe; ovdje više zanima sadržaj željenog zapisa. Ogromne količine informacija obično se podvrgavaju nenumeričkoj obradi. U raznim aplikacijama takve se operacije mogu izvesti na ovim podacima, na primjer:

povećati plaću svim zaposlenicima tvrtke;
obračunati bankovne kamate na račune svih klijenata;
izvršiti izmjene popisa sve robe na zalihama;
pronaći traženi sažetak iz svih tekstova pohranjenih u knjižnici ili u bibliografskom sustavu za pronalaženje informacija;
pronaći opis željenog ugovora u datoteci koja sadrži pravne dokumente;
pregledajte sve datoteke koje sadrže opise patenata i pronađite patent (ako postoji) sličan onom ponovno predloženom.

Za implementaciju motora baze podataka, paralelnog i asocijativnog arhitekture kao alternativa jednoprocesoruvon Neumannastrukturu, koja vam omogućuje rad s velikim količinama informacija u stvarnom vremenu.

Motori baza podataka dobivaju na značaju u vezi s istraživanjem i primjenom koncepata umjetne inteligencije kao što su reprezentacija znanja, ekspertni sustavi, zaključivanje, prepoznavanje uzoraka itd.

Skladišta informacija. Danas mnogi shvaćaju da većina tvrtki već ima nekoliko baza podataka i za uspješan rad s informacijama nisu potrebne samo različite vrste baza podataka, već različite generacije DBMS-a. Prema statistikama, svaka organizacija koristi u prosjeku 2,5 različitih DBMS-a. Postala je očigledna potreba da se poslovanje tvrtki, odnosno ljudi koji se bave ovim poslom "izoliraju" od tehnoloških značajki baza podataka, kako bi se korisnicima omogućio jedinstven pogled na korporativne informacije, bez obzira na to gdje su fizički pohranjene. . To je potaknulo pojavu tehnologije skladištenja informacija ( Skladište podataka, DW).

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

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

Banka podataka može biti prisutna u strukturi korporacije.

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

Baza podataka smatra se informacijskim i referentnim sustavom čija je glavna namjena:

u akumulaciji i održavanju u radnom stanju skupa informacija koje čine informacijsku bazu cjelokupnog automatiziranog sustava ili određenog skupa zadataka koji se rješavaju u njemu;
u izdavanju podataka koje zahtijeva zadatak ili korisnik;
u pružanju kolektivnog pristupa pohranjenim informacijama;
u osiguravanju potrebnog upravljanja korištenjem informacija sadržanih u infobazi.

Dakle, moderna banka podataka je složeni softversko-hardverski kompleks, koji uključuje tehničke, sistemske i mrežne alate, baze podataka i DBMS, sustave za pronalaženje informacija različite namjene.

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

Sustavi upravljanja bazama podataka i znanjem

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

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

Sustav upravljanja bazom podataka omogućuje sustavima za obradu podataka pristup bazama podataka. Kao što je već navedeno, važnu ulogu DBMS stječe u stvaranju korporativnih informacijskih sustava, a posebno važnu ulogu u stvaranju informacijskih sustava korištenjem distribuiranih informacijskih resursa temeljenih na suvremenim mrežnim računalnim tehnologijama.

Glavna značajka modernog DBMS-a je da moderni DBMS podržava takve tehnologije kao što su:

klijent/poslužitelj tehnologija.
Podrška za jezike baze podataka. Ovajjezik definicije sheme DB (SDL - jezik definicije sheme),jezik manipulacije podacima (DML - Data Manipulation Language), integrirani jezici SQL (Structured Queue Language), QDB (Upit - By - Primjer) i QMF (Query Management Facility) ) je napredni periferni alat za specifikaciju upita i generiranje izvješća za DB 2 itd.;
Izravno upravljanje podacima u vanjskoj memoriji.
Upravljanje memorijskim međuspremnikom.
Upravljanje transakcijama. OLTP tehnologija (on-line obrada transakcija), OLAP - tehnologija (On-line obrada analize) za DW.
Osigurati zaštitu i integritet podataka. Korištenje sustava dopušteno je samo korisnicima koji imaju pravo pristupa podacima. Kada korisnici izvode operacije nad podacima, održava se konzistentnost pohranjenih podataka (integritet). To je važno u korporativnim višekorisničkim informacijskim sustavima.
Novinarenje.

Moderni DBMS mora zadovoljiti zahtjeve baze podataka gore navedene. Osim toga, moraju se pridržavati sljedećih načela:

Neovisnost podataka.
Svestranost. DBMS mora imati snažnu podršku za konceptualni model podataka za prikaz prilagođenih logičkih pogleda.
Kompatibilnost. DBMS mora ostati operativan s razvojem softvera i hardvera.
Redundantnost podataka. Za razliku od datotečnih sustava, baza podataka mora biti jedan skup integriranih podataka.
Zaštita podataka. DBMS mora osigurati zaštitu od neovlaštenog pristupa.
Integritet podataka. DBMS mora spriječiti korisnike da diraju u bazu podataka.
Upravljanje istovremenim radom. DBMS mora zaštititi bazu podataka od nedosljednosti u načinu zajedničkog pristupa. Kako bi se osiguralo dosljedno stanje baze podataka, svi korisnički zahtjevi (transakcije) moraju se izvoditi određenim redoslijedom.
DBMS mora biti univerzalan. Trebao bi podržavati različite modele podataka na jednoj logičkoj i fizičkoj osnovi.
DBMS bi trebao podržavati i centralizirane i distribuirane baze podataka i tako postati važna karika u računalnim mrežama.

Razmatrajući DBMS kao klasu softverskih proizvoda usmjerenih na održavanje baza podataka u automatiziranim sustavima, možemo izdvojiti dvije najznačajnije značajke koje određuju vrste DBMS-a. Prema njima, DBMS se može promatrati s dvije točke gledišta:

njihove sposobnosti u odnosu na distribuirane (korporativne) baze podataka;
njihov odnos prema vrsti podatkovnog modela implementiranog u DBMS.

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

DBMS "desktop". Ovi proizvodi su prvenstveno usmjereni na rad s osobnim podacima (desktop podaci). Imaju skupove naredbi za dijeljenje zajedničkih baza podataka, ali su male veličine (tip malog ureda). Prije svega, to je DBMS poput Access, dBASE, Paradox, ExPro. Zašto Access, dBASE, Paradox, ExPro imaju loš pristup korporativnim podacima. Činjenica je da ne postoji jednostavan način za prevladavanje barijere između osobnih i korporativnih podataka. A poanta nije čak ni u tome da je mehanizam DBMS-a osobnih podataka (ili malog ureda) usmjeren na pristup podacima putem mnogih pristupnika, gateway proizvoda itd. Problem je u tome što ti mehanizmi obično uključuju potpuni prijenos datoteka i nedostatak opsežne podrške za indekse, što rezultira redovima na poslužitelju koji su praktički zastoj u velikim sustavima.
Specijalizirani višekorisnički DBMS visokih performansi. Takve DBMS-ove karakterizira prisutnost jezgre sustava za više korisnika, jezika za manipulaciju podacima i sljedećih funkcija koje su tipične za razvijene višekorisničke DBMS-ove:
organiziranje pufera;
prisutnost sustava za obradu redova transakcija;
prisutnost mehanizama za blokiranje podataka za više korisnika;
evidentiranje transakcija;
dostupnost mehanizama kontrole pristupa.

To su DBMS kao što su Oracle, DV2, SQL/Server, Informix, Sybase, ADABAS, Titanium i drugi pružaju široku uslugu obrade korporativnih baza podataka.

Pri radu s bazama podataka koristi se mehanizam transakcija.

transakcija je logička jedinica rada.

transakcija je slijed naredbi za manipulaciju podacima koji se izvršavajukao jedan(sve ili ništa) i prevođenje baze podatakaiz jednog integralnog stanja u drugo integralno stanje.

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

(A) Atomičnost . Transakcija se izvršava kao atomska operacija - ili se izvršava cijela transakcija ili se cijela transakcija ne izvršava.
(C) Dosljednost. Transakcija premješta bazu podataka iz jednog dosljednog (dosljednog) stanja u drugo dosljedno (dosljedno) stanje. Unutar transakcije, konzistentnost baze podataka može biti narušena.
(I) Izolacija . Transakcije različitih korisnika ne bi trebale ometati jedna drugu (na primjer, kao da se izvršavaju strogo redom).
(D) Trajnost. Ako je transakcija dovršena, tada bi se rezultati njezina rada trebali spremiti u bazu podataka, čak i ako se sustav sruši u sljedećem trenutku.

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

Izdana je naredba COMMIT WORK (za predaju transakcije).
Izdana je naredba ROLLBACK WORK.
Korisnik je prekinuo vezu s DBMS-om.
Došlo je do kvara sustava.

Za korisnika, ona obično nosi atomski karakter. Zapravo se radi o složenom mehanizmu interakcije između korisnika (aplikacije) i baze podataka. Softver poslovnih sustava koristi mehanizam za obradu transakcija u stvarnom vremenu (Online sustavi za obradu transakcija, OLTP), posebice računovodstveni programi, softver za primanje i obradu klijentskih aplikacija, financijske aplikacije, daju mnogo informacija. Ovi su sustavi dizajnirani (i prikladno optimizirani) za obradu velikih količina podataka, složene transakcije i intenzivne operacije čitanja/pisanja.

Nažalost, informacije koje se nalaze u bazama podataka OLTP sustava nisu baš prikladne za korištenje običnim korisnicima (zbog visokog stupnja normalizacije tablice, specifičnih formata prikaza podataka i drugih čimbenika). Stoga se podaci iz različitih informacijskih cjevovoda šalju (u smislu da su kopirani). skladište skladište, sortiranje i naknadna isporuka potrošaču. U informacijskoj tehnologiji ulogu skladišta imajuskladišta informacija.

Dostava informacija do krajnjeg korisnika - angažirani su sustavi analitičke obrade podataka u stvarnom vremenu (On-line analitička obrada, OLAP), koji omogućuju iznimno jednostavan pristup podacima putem praktičnih alata za generiranje upita i analizu rezultata. U OLAP sustavima vrijednost informacijskog proizvoda povećava se korištenjem različitih metoda analize i statističke obrade. Osim toga, ovi su sustavi optimizirani u smislu brzine ekstrakcije podataka, prikupljanja generaliziranih informacija i usmjereni su na obične korisnike (imaju intuitivno sučelje). Ako OLTP sustav daje odgovore na jednostavna pitanja poput "koja je bila razina prodaje proizvoda N u regiji M u siječnju 199x?", zatim OLAP sustavi spremni su za složenije zahtjeve korisnika, na primjer: "Dati analizu prodaje proizvoda N za sve regije prema planu za drugi kvartal u odnosu na prethodne dvije godine."

Arhitektura klijent/poslužitelj

U modernim sustavima distribuirana obrada informacijatehnologija zauzima središnje mjesto klijent/poslužitelj. U sustavu klijent-poslužitelj arhitektureobrada podataka podijeljena je između računala klijenta i računala poslužitelja, komunikacija između kojih se odvija putem mreže. Ovo razdvajanje procesa obrade podataka temelji se na grupiranju funkcija. Obično je računalo poslužitelja baze podataka namijenjeno za obavljanje operacija baze podataka, dok klijentsko računalo pokreće aplikacijske programe. Slika 2.1 prikazuje jednostavan sustav arhitekture klijent-poslužitelj koji uključuje računalo koje djeluje kao poslužitelj i drugo računalo koje djeluje kao njegov klijent. Svaki stroj obavlja različite funkcije i ima svoje resurse.

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

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

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

Poslužitelj - Ovo je objekt (računalo) koje pruža usluge drugim objektima na njihov zahtjev.

Kao što pojam implicira, glavna funkcija poslužiteljskog računala je služiti potrebama klijenta. Pojam "poslužitelj" koristi se za označavanje dvije različite skupine funkcija: poslužitelj datoteka i poslužitelj baze podataka (u daljnjem tekstu ovi pojmovi znače, ovisno o kontekstu, ili softver koji implementira te grupe funkcija ili računala s ovim softverom ). Datotečni poslužitelji nisu dizajnirani za obavljanje operacija baze podataka, njihova je glavna funkcija dijeljenje datoteka između nekoliko korisnika, t.j. osiguravajući istovremeni pristup više korisnika datotekama na računalu – datotečnom poslužitelju. Primjer datotečnog poslužitelja je Novellov NetWare operativni sustav. Poslužitelj baze podataka može se instalirati i izvoditi na računalu s datotečnim poslužiteljem. Oracle DBMS u obliku NLM-a (Network Loadable Module) radi u NetWare okruženju na poslužitelju datoteka.

Poslužitelj lokalne mreže mora imati resurse koji odgovaraju njegovoj funkcionalnoj namjeni i potrebama mreže. Napominjemo da je zbog orijentacije na pristup otvorenim sustavima ispravnije govoriti o logičkim poslužiteljima (misli se na skup resursa i softverskih alata koji pružaju usluge preko tih resursa) koji se ne moraju nužno nalaziti na različitim računalima. Značajka logičkog poslužitelja u otvorenom sustavu je da ako je, iz razloga učinkovitosti, svrsishodno premjestiti poslužitelj na zasebno računalo, onda se to može učiniti bez potrebe za ikakvim modifikacijama, kako same tako i aplikacije. programa koji ga koriste.

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

Distribuirano računalstvo

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

Distribuirana baza podataka;
Distribuirana obrada podataka.

Primjena ovih koncepata omogućuje krajnjim korisnicima organiziranje pristupa informacijama pohranjenim na nekoliko strojeva korištenjem različitih sredstava.

Postoji mnogo vrsta poslužitelja:

Poslužitelj baze podataka;
Ispisni poslužitelj;
Poslužitelj za daljinski pristup;
Faks poslužitelj;
Web server itd.

U srži tehnologije klijent/poslužitelj Postoje takve osnovne tehnologije kao što su:

Tehnologije operacijskih sustava, koncept interakcije otvorenih sustava, stvaranje objektno orijentiranih okruženja za funkcioniranje programa;
Telekomunikacijske tehnologije;
Mrežne tehnologije;
Tehnologije grafičkog korisničkog sučelja ( GUI);
itd.

Prednosti klijent-poslužitelj tehnologije:

Tehnologija klijent/poslužitelj omogućuje računanje u heterogenim računalnim okruženjima. Neovisnost od platforme: Pristup heterogenim mrežnim okruženjima koja uključuju različite vrste računala s različitim operativnim sustavima.
Neovisnost od izvora podataka: pristup informacijama iz heterogenih baza podataka. Primjeri takvih sustava su DB2, SQL/DS, Oracle, Sybase.
Balans opterećenja između klijenta i poslužitelja.
Izvođenje izračuna tamo gdje je to najučinkovitije;
Pruža učinkovitu sposobnost skaliranja;
Višeplatformsko računanje. Cross-platform computing definira se jednostavno kao implementacija tehnologija u heterogenim računalnim okruženjima. Ovdje bi trebale biti navedene sljedeće opcije:
Aplikacija mora raditi na više platformi;
Na svim platformama trebao bi imati isto sučelje i logiku rada;
Aplikacija se mora integrirati s izvornim operativnim okruženjem;
Trebao bi se ponašati isto na svim platformama;
Trebao bi imati jednostavnu i dosljednu podršku.

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

 Smanjenje. Downscaling je prijenos aplikacija glavnog računala na male računalne platforme.

Smanjite troškove infrastrukture i hardvera. Isplativo: dostupnost jeftinog računalnog hardvera i rastuća zastupljenost lokalnih mreža čine klijent-poslužitelj tehnologiju isplativijom od ostalih tehnologija obrade podataka. Oprema se može nadograditi po potrebi.

 Smanjenje ukupnog vremena izvršavanja aplikacije;

 Smanjena upotreba memorije klijenta;

 Smanjenje mrežnog prometa.

Sposobnost rada s multimedijom: Do danas je stvoreno puno programa za rad s multimedijom za računala. Ili ne postoje takvi programi za konfiguraciju terminal-host, ili su vrlo skupi.
Mogućnost korištenja više računalnih resursa za operacije baze podataka: budući da se aplikacije pokreću na klijentskim računalima, dodatni (u usporedbi s konfiguracijom terminal-host) resursi se oslobađaju na poslužiteljskom računalu za operacije baze podataka, kao što su CPU i operativni resursi.Memorija.
Povećana produktivnost programera: Produktivnost programera povećava se korištenjem alata kao što su SQL*Forms i CASE za razvoj aplikacija brže od programskih jezika kao što su C, PL1 ili COBOL.
Povećanje produktivnosti krajnjih korisnika: Danas su mnogi krajnji korisnici prihvatili sustave kao što su Lotus, Paradox, Word Perfect, Harvard Graphics, itd.

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

Riža. 2.2. Ilustracija pristupa klijenta dijeljenom poslužitelju.

Kako implementirati tehnologiju klijent-poslužitelj

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

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

SQL jezik . Jezik upita visoke razine - SQL (Strukturirani jezik upita ) koristi se za implementaciju upita bazama podataka, kao što su NMD, NDL i PJD, te je usvojen kao standard. Jezik SQL je izvorno prihvaćen kao jezik podataka softverskih proizvoda tvrtke IBM i YMD relacijskog DBMS-a SYSTEM R od IBM-a . Važna karakteristika jezika SQL je da je isti jezik predstavljen kroz dva različita sučelja, i to: kroz interaktivno sučelje i kroz sučelje za programiranje aplikacije (dinamičko SQL). Dinamički SQL sastoji se od mnogih ugrađenih jezičnih značajki SQL , predviđen posebno za izradu interaktivnih aplikacija, gdje je interaktivna aplikacija program koji je napisan da podrži pristup bazi podataka od strane krajnjeg korisnika koji radi na interaktivnom terminalu. Jezik SQL pruža funkcije definiranja, manipuliranja i upravljanja podacima baze podataka i transparentan je korisniku sa stajališta implementiranog DBMS-a.

Riža. 2.3. Shema za izvršavanje zahtjeva korisnika prema distribuiranim bazama podataka.

Interna struktura baza podataka određena je korištenim modelima podataka. Konceptualni model ima više mogućnosti apstrakcije i bogatiju semantiku od vanjskih modela. Vanjski modeli se često nazivaju sintaktičkim ili operativnim modelima, upućujući na sintaktičku prirodu upravljanja i aplikacije kao sredstva interakcije korisnika s bazom podataka. U informacijskom modeliranju postoje različite razine apstrakcije, od razine konceptualnog modela do razine modela fizičkih podataka, koje utječu na arhitekturu DBMS-a.

Model podataka sastoji se od tri komponente:

Struktura podataka za predstavljanje iz perspektive korisnika u bazi podataka.
Valjane operacije koje se trebaju izvesti nad strukturom podataka. Potrebno je znati raditi s ovom strukturom koristeći različite DDL i NML operacije. Bogata struktura je bezvrijedna ako ne možete manipulirati njenim sadržajem.
Ograničenja za kontrolu integriteta. Model podataka mora imati sredstva za očuvanje njegova integriteta i zaštitu. Kao primjer, razmotrite sljedeća dva ograničenja:
Svako podstablo mora imati izvorni čvor. Hijerarhijske baze podataka ne mogu pohraniti podređene čvorove bez roditeljskog čvora.
U odnosu na relacijsku bazu podataka, ne mogu postojati identični torovi. Za datoteku, ovaj zahtjev zahtijeva da svi zapisi budu jedinstveni.

Jedna od najvažnijih karakteristika DBMS-a je sposobnost povezivanja objekata.

Postoje sljedeće vrste veza između objekata:

Jedan na jedan (1:1). Jedan objekt jednog skupa može se povezati s jednim objektom drugog skupa.
Jedan prema više (1:M). Jedan objekt jednog skupa može se povezati s mnogim objektima drugog skupa.
Mnogi prema mnogo (M:N). Jedan objekt jednog skupa može biti pridružen mnogim objektima drugog skupa, ali u isto vrijeme jedan objekt drugog skupa može biti pridružen mnogim objektima iz prvog skupa.
razgranati . Jedan objekt jednog skupa može se povezati s objektima iz više skupova.
Ponavljajući . Jedan objekt danog skupa može biti povezan s objektom istog skupa.

Postoje sljedeći glavni modeli podataka:

Relacijski model podataka.
Hijerarhijski model podataka.
Nepotpuni mrežni podatkovni model.
Model podataka CODASYL.
Model proširenih mrežnih podataka.

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

Osnovni problem sustava baziranih na arhitekturi "klijent-poslužitelj" je u tome što se, u skladu s konceptom otvorenih sustava, od njih traži da budu mobilni u najširoj mogućoj klasi hardverskih i softverskih rješenja otvorenog sustava. Čak i ako se ograničimo na UNIX-temeljene lokalne mreže, različite mreže koriste različitu opremu i komunikacijske protokole. Pokušaj stvaranja sustava koji podržavaju sve moguće protokole dovodi do njihovog preopterećenja mrežnim detaljima na štetu funkcionalnosti.

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

Uobičajeno rješenje problema mobilnosti sustava baziranih na arhitekturi "klijent-poslužitelj" je oslanjanje na softverske pakete koji implementiraju protokole udaljenog poziva procedura (RPC - Remote Procedure Call). Koristeći ove alate, pozivanje usluge na udaljenom hostu izgleda kao normalan poziv procedure. RPC alati, koji, naravno, sadrže sve informacije o specifičnostima opreme lokalne mreže i mrežnih protokola, prevode poziv u slijed mrežnih interakcija. Dakle, specifičnosti mrežnog okruženja i protokola su skrivene od programera aplikacija.

Kada se pozove udaljena procedura, RPC programi pretvaraju formate podataka klijenta u srednje strojno neovisne formate, a zatim pretvaraju u formate podataka poslužitelja. Prilikom prosljeđivanja parametara odgovora izvode se slične transformacije.

Ostali povezani radovi koji bi vas mogli zanimati.vshm>
6914.		Koncept baze podataka	11,56 KB
	Baza podataka je skup neovisnih materijala predstavljenih u objektivnom obliku članaka za izračun normativnih akata sudskih odluka i drugih sličnih materijala sistematiziranih na način da se ti materijali mogu pronaći i obraditi pomoću elektroničkog računala Građanski zakonik Ruske Federacije Umjetnost. Baza podataka organizirana u skladu s određenim pravilima i održavana u memoriji računala, skup podataka koji karakteriziraju trenutno stanje nekog ...
8064.		Distribuirane baze podataka	43,66 KB
	Distribuirane baze podataka Distribuirana RDB baza podataka je skup logički međusobno povezanih zajedničkih podataka koji se fizički distribuiraju na različitim čvorovima računalne mreže. Pristup podacima ne bi trebao ovisiti o prisutnosti ili odsutnosti replika podataka. Sustav bi trebao automatski odrediti metode za izvođenje spajanja podataka, mrežnu vezu sposobnu za rukovanje količinom informacija koje se prenose i čvor koji ima dovoljnu snagu obrade za spajanje tablica. RDBMS mora biti sposoban za...
20319.		BAZE PODATAKA I NJIHOVA ZAŠTITA	102,86 KB
	Online online baze podataka pojavile su se sredinom 1960-ih. Operacije na operativnim bazama podataka obrađene su interaktivno pomoću terminala. Jednostavna indeksno sekvencijalna organizacija zapisa brzo je evoluirala u moćniji model zapisa orijentiran na skup. Charles Bachmann dobio je Turingovu nagradu za vođenje rada Data Base Task Group (DBTG), koja je razvila standardni jezik za opisivanje podataka i manipulaciju podacima.
5031.		Knjižnica za razvoj baze podataka	11,72 MB
	Tehnologija dizajna baze podataka. Definiranje odnosa između entiteta i stvaranje modela podataka. Glavne ideje suvremene informacijske tehnologije temelje se na konceptu da se podaci trebaju organizirati u baze podataka kako bi na odgovarajući način odražavali promjenjivi stvarni svijet i zadovoljili informacijske potrebe korisnika. Te se baze podataka stvaraju i rade pod kontrolom posebnih softverskih sustava koji se nazivaju DBMS sustavi za upravljanje bazama podataka.
13815.		HIJERARHIJSKI MODEL BAZE PODATAKA	81,62 KB
	Glavne ideje suvremene informacijske tehnologije temelje se na konceptu baza podataka, prema kojemu osnovu informacijske tehnologije čine podaci organizirani u baze podataka koje na odgovarajući način odražavaju stanje pojedinog predmetnog područja i pružaju korisniku relevantne informacije u tom predmetnom području. Mora se priznati da su podaci...
14095.		Razvoj knjižnične baze podataka	11,72 MB
	Povećanje volumena i strukturne složenosti pohranjenih podataka, širenje kruga korisnika informacijskih sustava doveli su do raširene uporabe najprikladnijeg i relativno lako razumljivog relacijskog (tabelarnog) DBMS-a.
5061.		Izrada polikliničke baze podataka	2,4 MB
	Razvoj računalne tehnologije i informacijske tehnologije pružio je mogućnosti za stvaranje i široku upotrebu automatiziranih informacijskih sustava (AIS) za različite namjene. Razvijaju se i implementiraju informacijski sustavi za upravljanje gospodarskim i tehničkim objektima
13542.		Baze geoloških podataka	20,73 KB
	U posljednje vrijeme ubrzano se odvija uvođenje računalnih tehnologija, a posebno baza podataka, u znanstvenu sferu. Ovaj proces ne zaobilazi ni geologiju, jer upravo u prirodnim znanostima postoji potreba za pohranjivanjem i obradom velikih količina informacija.
9100.		Baza podataka. Osnovni koncepti	26,28 KB
	Baza podataka je zbirka informacija o određenim objektima stvarnog svijeta iz bilo kojeg predmetnog područja, ekonomije, menadžmenta, kemije itd. Svrha informacijskog sustava nije samo pohranjivanje podataka o objektima, već i manipulacija tim podacima, uzimajući uzeti u obzir odnose između objekata. Svaki objekt karakterizira neki skup svojstava podataka, koji se u bazi podataka nazivaju atributi.
5240.		Izrada baze podataka "Dekanat sveučilišta"	1,57 MB
	Baza podataka (DB) je zbirka međusobno povezanih podataka pohranjenih zajedno na vanjskim medijima za pohranu računala, s takvom organizacijom i minimalnom redundantnošću koja omogućuje njihovu optimalnu upotrebu za jednu ili više aplikacija.

Modeli podataka o industriji

Glavna svrha modela je olakšati orijentaciju u podatkovnom prostoru i pomoći u isticanju detalja važnih za razvoj poslovanja. U današnjem poslovnom okruženju apsolutno je bitno imati jasno razumijevanje odnosa između različitih komponenti i dobro razumijevanje opće slike organizacije. Identifikacija svih detalja i odnosa pomoću modela omogućuje najučinkovitije korištenje vremena i alata za organizaciju rada tvrtke.

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

U pravilu se razlikuju modeli više razine (i sadržajno općenitije) i niže razine (odnosno, detaljnije). Gornja razina modeliranja je tzv konceptualni modeli podataka(konceptualni modeli podataka), koji daju najopćenitiju sliku funkcioniranja poduzeća ili organizacije. Konceptualni model uključuje glavne koncepte ili predmetna područja koja su kritična za funkcioniranje organizacije; obično njihov broj ne prelazi 12-15. Takav model opisuje klase entiteta važnih za organizaciju (poslovni objekti), njihove karakteristike (atribute) i asocijacije između parova tih klasa (tj. relacije). Budući da terminologija u poslovnom modeliranju još nije u potpunosti sređena, u različitim izvorima na engleskom jeziku konceptualni modeli podataka mogu se nazvati i modelom predmetnog područja (što se može prevesti kao modeli predmetnog područja) ili predmetnim modelom podataka poduzeća (predmetni korporativni modeli podataka). ).

Sljedeća hijerarhijska razina je logičkih modela podataka(logički modeli podataka). Oni se također mogu nazvati poslovnim modelima podataka ili poslovnim modelima. Ovi modeli sadrže strukture podataka, njihove atribute i poslovna pravila te predstavljaju informacije koje poduzeće koristi iz poslovne perspektive. U takvom modelu podaci su organizirani u obliku entiteta i odnosa među njima. Logički model predstavlja podatke na način koji je lako razumljiv poslovnim korisnicima. U logičkom modelu može se dodijeliti rječnik podataka - popis svih entiteta s njihovim točnim definicijama, što omogućuje različitim kategorijama korisnika da imaju zajedničko razumijevanje svih ulaznih i izlaznih tokova podataka modela. Sljedeća, niža razina modeliranja je već fizička implementacija logičkog modela korištenjem specifičnih softverskih alata i tehničkih platformi.

Logički model sadrži detaljnu poslovnu odluku poduzeća, koja obično ima oblik normaliziranog modela. Normalizacija je proces koji osigurava da svaki element podataka u modelu ima samo jednu vrijednost i da potpuno i jedinstveno ovisi o primarnom ključu. Elementi podataka organizirani su u skupine prema njihovoj jedinstvenoj identifikaciji. Poslovna pravila koja kontroliraju elemente podataka moraju biti u potpunosti uključena u normalizirani model uz preliminarnu provjeru njihove valjanosti i ispravnosti. Na primjer, element podataka kao što je ime klijenta najvjerojatnije bi bio podijeljen na ime i prezime i grupiran s drugim relevantnim elementima podataka u entitet klijenta s primarnim ključem ID-a korisnika.

Logički model podataka neovisan je o aplikacijskim tehnologijama kao što su baze podataka, umrežavanje ili alati za izvješćivanje i njihova fizička implementacija. Organizacija može imati samo jedan model podataka poduzeća. Logički modeli obično uključuju tisuće entiteta, odnosa i atributa. Na primjer, model podataka za financijsku instituciju ili telekomunikacijsku tvrtku može sadržavati oko 3000 industrijskih koncepata.

Važno je razlikovati logički i semantički model podataka. Logički model podataka predstavlja korporativno poslovno rješenje, dok semantički model podataka predstavlja primijenjeno poslovno rješenje. Isti korporativni logički model podataka može se implementirati korištenjem različitih semantičkih modela, tj. semantički modeli mogu se smatrati sljedećom razinom modeliranja koja se približava fizičkim modelima. Osim toga, svaki od ovih modela predstavljat će zaseban “slice” korporativnog modela podataka u skladu sa zahtjevima različitih aplikacija. Na primjer, u korporativnom logičkom modelu podataka, entitet Klijent će biti potpuno normaliziran, au semantičkom modelu za podatkovno tržište može se predstaviti kao višedimenzionalna struktura.

Tvrtka može imati dva načina za stvaranje poslovnog logičkog modela podataka: izraditi ga sama ili koristiti gotov industrijski model(industrijski logički model podataka). U ovom slučaju, razlike u terminima odražavaju samo različite pristupe izgradnji istog logičkog modela. U slučaju da tvrtka samostalno razvija i implementira vlastiti logički model podataka, tada se takav model u pravilu jednostavno naziva korporativnim logičkim modelom. Ako organizacija odluči koristiti gotov proizvod profesionalnog dobavljača, tada možemo govoriti o industrijskom logičkom modelu podataka. Potonji je gotov logički model podataka koji odražava funkcioniranje određene industrije s visokim stupnjem točnosti. Industrijski logički model je domenski specifičan i integrirani pogled na sve informacije koje moraju biti u skladištu podataka poduzeća kako bi se odgovorilo na strateška i taktička poslovna pitanja. Kao i svaki drugi logički model podataka, industrijski model ne ovisi o aplikacijskim rješenjima. Također ne uključuje izvedene podatke ili druge izračune za brže dohvat podataka. U pravilu, većina logičkih struktura takvog modela nalazi dobro utjelovljenje u njegovoj učinkovitoj fizičkoj implementaciji. Takve modele razvijaju mnogi dobavljači za širok raspon područja: financije, proizvodnja, turizam, zdravstvo, osiguranje itd.

Industrijski logički model podataka sadrži informacije koje su zajedničke za industriju i stoga ne mogu biti cjelovito rješenje za tvrtku. Većina tvrtki mora povećati model za prosječno 25% dodavanjem elemenata podataka i proširenjem definicija. Gotovi modeli sadrže samo ključne elemente podataka, a ostale elemente potrebno je dodati odgovarajućim poslovnim objektima tijekom instalacije modela u poduzeću.

Industrijski logički modeli podataka sadrže značajan broj apstrakcija. Apstrakcija se odnosi na ujedinjenje sličnih koncepata pod zajedničkim nazivima kao što su događaj ili sudionik. To dodaje fleksibilnost industrijskim modelima i čini ih ujedinjenijima. Dakle, koncept događaja primjenjiv je na sve industrije.

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

Drugi čimbenik su vrijeme i novac potrebni za održavanje modela. Ako model podataka poduzeća nije dio metodologije koja ga održava točnim i ažuriranim, tada će model vrlo brzo zastarjeti. Industrijski podatkovni model može spriječiti ovaj rizik jer ga vanjski resursi održavaju ažurnim. Naravno, promjene koje se događaju unutar organizacije moraju se odraziti u modelu od strane same tvrtke, ali će promjene u industriji biti reproducirane u modelu od strane njenog dobavljača.

Treći čimbenik je iskustvo u procjeni rizika i modeliranju. Stvaranje poslovnog modela podataka zahtijeva kvalificirane resurse i poslovnog i IT osoblja. Menadžeri u pravilu dobro poznaju ili rad organizacije u cjelini, ili aktivnosti pojedinog odjela. Malo njih ima široko (za cijelu tvrtku) i duboko (u cijeloj jedinici) znanje o svom poslovanju. Većina menadžera obično dobro poznaje samo jedno područje. Stoga, kako bi se dobila slika cijele tvrtke, potrebni su značajni poslovni resursi. To također povećava zahtjeve za IT osoblje. Što je više poslovnih resursa potrebno za izradu i testiranje modela, analitičari moraju biti iskusniji. Ne samo da moraju znati kako dobiti informacije od poslovnog osoblja, već i biti u stanju pronaći zajednički jezik u kontroverznim područjima i biti u stanju sve te informacije prezentirati na integriran način. Onaj tko kreira model (u mnogim slučajevima to je isti analitičar) mora imati dobre vještine modeliranja. Stvaranje modela korporativne logike zahtijeva modeliranje “za budućnost” i sposobnost pretvaranja složenog poslovanja u doslovno “kvadrate i linije”.

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

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

Peti faktor je razmjena informacija unutar industrije. Ako tvrtka treba dijeliti podatke s drugim organizacijama koje djeluju u istom području, tada industrijski model može biti od velike pomoći u ovoj situaciji. Organizacije unutar iste industrije koriste slične strukturne komponente i terminologiju. Danas su u većini industrija tvrtke prisiljene dijeliti podatke kako bi uspješno vodile svoje poslovanje.

Industrijski modeli koje nude profesionalni dobavljači su najučinkovitiji. Visoka učinkovitost njihove uporabe postiže se zahvaljujući značajnoj razini detalja i točnosti ovih modela. Obično sadrže mnogo atributa podataka. Osim toga, kreatori ovih modela ne samo da imaju veliko iskustvo u modeliranju, već su također dobro upućeni u izradu modela za određenu industriju.

Modeli podataka u industriji pružaju tvrtkama jedinstven, integrirani pogled na njihove poslovne informacije. Mnogim tvrtkama je teško integrirati svoje podatke, iako je to preduvjet za većinu projekata u cijelom poduzeću. Prema studiji The Data Warehousing Institute (TDWI), više od 69% anketiranih organizacija smatra da je integracija značajna prepreka usvajanju novih aplikacija. Naprotiv, implementacija integracije podataka donosi značajan prihod tvrtki.

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

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

Publikacije

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

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

"Bajka je laž - ali u njoj ima nagovještaja..."

Djed je zasadio ... skladište. A skladište je postajalo veliko i veliko. Jednostavno nisam znao kako to funkcionira. I djed je počeo pregled. Djed je zvao baku, unuku, mačku i miša na obiteljsko vijeće. I kaže sljedeću temu: „Naše skladište je poraslo. Podaci iz svih sustava se skupljaju, tablice su vidljive i nevidljive. Korisnici pripremaju svoja izvješća. Čini se da je sve u redu - živjeti i živjeti. Da, samo jedna tuga - nitko ne zna kako to funkcionira. Zahtijeva diskove naizgled nevidljivo - nećete se zasititi! A tu su i korisnici koji mi se obraćaju s različitim pritužbama: ili se izvješće zamrzava, ili su podaci zastarjeli. A ponekad je to prava katastrofa - dolazimo s izvješćima caru-ocu, ali brojke se međusobno ne slažu. Nije ni čas - ljutit će se kralj - onda ne ruši glavu - ni meni, ni tebi. Zato sam vas odlučio okupiti i posavjetovati se: što ćemo?

Baci pogled na skupštinu i upita:
- Evo ti, babo, znaš li kako je uređeno naše skladište?
- Ne, djede, ne znam. A kako da znam? Tamo, kakvi ga hrabri momci čuvaju! Neki brkovi! Ne pojačaj se. Išla sam im nekako u posjet, pekla pite. I pojeli su pite, obrisali brkove i rekli: „Što si došla, babo? Koja je vaša pohrana? Recite nam kakvo izvješće trebate - mi ćemo to učiniti umjesto vas! Što je najvažnije, češće donosite pite! Bolno, ukusnog su okusa.”
- A ti, draga moja unuče, znaš li kako je uređeno naše skladište?
- Ne, djede, ne znam. Dao mi je pristup tome. Povezao sam se, gledam - a tu su i stolovi - naizgled nevidljivi. I različite sheme su skrivene. Oči se rašire.... Prvo sam bio zbunjen. A onda sam dobro pogledao - neke su prazne, druge popunjene, ali samo napola. Također, čini se da se podaci ponavljaju. Nije ni čudo što se ne možete opskrbiti diskovima s takvom zališkom!
- Pa ti, maco, što možeš reći o našem skladištu? Ima li nešto dobro u tome?
- Da, kako da ne kažem, dide - reći ću. Na zahtjev moje unuke, pokušao sam napraviti pilot pilota u zasebnoj shemi - maloj vitrini. Da bismo razumjeli kakva je trgovina korisna za našu državu - koji su proizvodi dobri za trgovce, plaćaju danak - riznica se puni. I koje su loše. I počeo sam pokupiti podatke iz ovog spremišta. Prikupljene činjenice. I počeo ih je pokušavati uspoređivati s proizvodima. I što sam, djede, vidio - proizvodi su kao da su isti, ali pogledate znakove - različiti su! Tada sam ih počela češljati češljem svoje unuke. Grebao je, grebao - i doveo do određene jednoličnosti, milujući oko. Ali rano sam se obradovao - sljedeći dan sam pokrenuo svoje skripte za ažuriranje prekrasnih podataka u prozoru - i sve je nestalo za mene! "Kako to?" - Mislim, - uzrujat će se unuka - danas bi bilo potrebno pokazati našeg pilota ministru. Kako ćemo to učiniti - s takvim podacima?
- Da, tužne priče, mačka, ti pričaj. Pa ti, mali mišu, nisi li baš pokušao saznati za trezor? Vi ste živahna, okretna, druželjubiva djevojka! Što ćeš nam reći?
- Da, kako, djede, ne pokušavaj - naravno, ja sam tihi miš, ali okretan. Nekako je unuka mačke tražila model podataka našeg državnog repozitorija da ga dobije. I mačak mi je, naravno, došao - na tebe, kaže miš, sva nada! Pa, koje dobro djelo dobri ljudi (i mačke) ne mogu učiniti? Otišao sam u dvorac, gdje voditelj spremišta skriva model podataka u sefu. I sakrio se. Čekao sam da izvadi taj model iz sefa. Čim je izašao na kavu – skočila sam na stol. Gledam model - ništa ne mogu razumjeti! Kako to? Ne prepoznajem naš trezor! Imamo bezbroj tisuća tablica, podataka – neumornih tokova! I ovdje - sve je skladno i lijepo... Pogledao je ovaj model - i vratio ga u sef.
- Da, vrlo čudne stvari, rekao si nam, mišu.
Djed je teško razmišljao.
Što ćemo, prijatelji moji? Uostalom, nećete dugo živjeti s takvim spremištem ... Korisnici će uskoro potpuno izgubiti strpljenje.

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

Ispitivanje

Nitko od nas, radeći na stvaranju i razvoju bilo kojeg sustava, ne želi da to bude “privremena kuća”, ili rješenje koje će “odvenuti” za godinu-dvije, jer. neće moći ispuniti zahtjeve i očekivanja kupaca i poduzeća. Bez obzira koliko je danas snažan pomak prema “fleksibilnim metodologijama”, čovjeku je puno ugodnije osjećati se kao “majstor” koji izrađuje violine nego kao zanatlija koji rezbari štapove za jednokratne bubnjeve.
Naša namjera zvuči prirodno: napraviti sustave koji su čvrsti i kvalitetni, koji neće zahtijevati od nas redovito “noćno bdjenje s kartotekom”, kojeg se nećemo sramiti pred krajnjim korisnicima i koji neće izgledati kao “crna kutija” svim “neupućenim” pratiteljima.

Najprije nabrojimo tipične probleme s kojima se redovito susrećemo pri radu s skladištima. Zapišimo samo što imamo – do sada bez pokušaja racionalizacije i formalizacije.

U principu, imamo dobro skladište: ako ga ne dodirnete, sve radi. Istina, čim je potrebna promjena, počinju "lokalni kolapsi".
Podaci se učitavaju dnevno, prema propisima, unutar jednog velikog procesa, u roku od 8 sati. I odgovara nam. Ali ako se iznenada dogodi kvar, to zahtijeva ručnu intervenciju. I onda sve može raditi nepredvidivo dugo vremena, jer. potrebno je ljudsko sudjelovanje u procesu.
Pokrenuto oslobađanje - očekujte probleme.
Neki izvor nije mogao dati podatke na vrijeme - svi procesi čekaju.
Integritet podataka kontrolira baza podataka - tako da se naši procesi ruše kada se pokvare.
Imamo vrlo veliku pohranu - 2000 tablica u jednoj zajedničkoj shemi. I još 3000 u mnogim drugim shemama. Već sada nemamo pojma kako su raspoređeni i iz kojeg razloga su se pojavili. Stoga nam može biti teško ponovno upotrijebiti nešto. I mnoge probleme treba ponovno riješiti. Jer, lakše je i brže (nego razumjeti "u tuđem kodu"). Kao rezultat toga, imamo odstupanja i duple funkcionalnosti.
Očekujemo da će izvor pružiti kvalitetne podatke. No, pokazalo se da to nije tako. Kao rezultat toga, trošimo puno vremena na usklađivanje naših konačnih izvješća. I bili su u tome vrlo uspješni. Imamo čak i pojednostavljen proces. Istina, treba vremena. No korisnici su navikli na...
Korisnik ne vjeruje uvijek našim izvješćima i traži opravdanje za određenu brojku. U nekim slučajevima on je u pravu, au drugim je u krivu. No, vrlo nam je teško da ih potkrijepimo, jer ne pružamo sredstva za "end-to-end analizu" (ili lozu podataka).
Mogli bismo dovesti dodatne programere. Ali imamo problem – kako ih pretvoriti u posao? Koji je najučinkovitiji način paralelizacije rada?
Kako razvijati sustav postupno, ne ulazeći u razvoj “jezgre sustava” cijelu godinu?
Skladište podataka povezano je s korporativnim modelom. Ali znamo pouzdano (vidjeli smo to u XYZ banci) da je moguće graditi model na neodređeno vrijeme (u XYZ banci smo šest mjeseci obilazili i razgovarali o poslovnim subjektima, bez ikakvog pomaka). Zašto je uopće? Ili je možda bolje bez nje, ako ima toliko problema s njom? Možda ga nekako generirati?
Odlučili smo voditi model. Ali kako sustavno razvijati model podataka skladišta? Trebaju li nam "pravila igre" i koja ona mogu biti? Što će nam to dati? Što ako pogriješimo s modelom?
Trebamo li spremati podatke, odnosno povijest njihovih promjena, ako ih "poduzeće ne treba"? Ne bih želio "spremati smeće" i komplicirati korištenje ovih podataka za stvarne zadatke. Treba li trezor čuvati povijest? Kako je? Kako pohrana funkcionira tijekom vremena?
Je li potrebno pokušati objediniti podatke u pohrani ako imamo sustav upravljanja NSI? Ako postoji MDM, znači li to da je sada cijeli problem s glavnim podacima riješen?
Očekuje se da ćemo uskoro zamijeniti ključne računovodstvene sustave. Treba li pohrana podataka biti spremna za promjenu izvora? Kako to postići?
Trebaju li nam metapodaci? Što ćemo pod tim razumjeti? Gdje se točno mogu koristiti? Kako se može provesti? Treba li ih držati "na jednom mjestu"?
Naši kupci su izrazito nestabilni u svojim zahtjevima i željama – nešto se stalno mijenja. Općenito, naše poslovanje je vrlo dinamično. Dok nešto radimo, to već postaje nepotrebno. Kako se možemo pobrinuti da postignemo rezultate što je brže moguće - poput vrućih kolača?
Korisnici zahtijevaju brzinu. Ali ne možemo često pokretati naše glavne procese pokretanja, jer ovo učitava izvorne sustave (loš utječe na performanse) - stoga, spuštamo dodatne tokove podataka - koji će točki uzeti - ono što nam treba. Istina, ispada puno tokova. A onda ćemo izbaciti neke podatke. Osim toga, pojavit će se problem konvergencije. Ali nema drugog načina...

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

antifragilnost

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

Nakon nekog vremena, slika je sljedeća:
„Evo trezora. I radi ako ga ne diraš. Problemi nastaju kada nešto moramo promijeniti.”

Dolazi nam promjena čiji utjecaj ne možemo procijeniti i shvatiti (jer takve alate nismo inicijalno ubacili u sustav) - i da ne bismo riskirali, ne diramo ono što jest, nego napravimo još jedan proširenje sa strane, i još jedno, i više - pretvaranje naše odluke u sirotinjske četvrti, ili kako kažu u Latinskoj Americi, "favele", u koje se čak i policija boji ići.
Osjeća se gubitak kontrole nad vlastitim sustavom, kaos. Za održavanje postojećih procesa i rješavanje problema potrebno je sve više ruku. I sve je teže napraviti promjene. Drugim riječima, sustav postaje nestabilan na naprezanja, neprilagodljiv na promjene. A osim toga, postoji jaka ovisnost o likovima koji "znaju ferway", budući da nitko nema "kartu".

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

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

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

Sami izvorni sustavi, sastav informacija i njihova struktura, vrsta integracijske interakcije, kao i sama logika rada s podacima mogu se mijenjati. Svaki sustav implementira vlastiti model podataka i pristupe radu s njima koji zadovoljavaju ciljeve i ciljeve sustava. I koliko god se trudili objediniti industrijske modele i referentne prakse, nijanse će se ionako neizbježno pojaviti. (A osim toga, sam proces objedinjavanja industrije, iz raznih razloga, ne napreduje puno naprijed.)
Kultura rada s korporativnim podacima - prisutnost i kontrola informacijske arhitekture, jedinstveni semantički model, sustavi upravljanja glavnim podacima (MDM) donekle olakšavaju zadatak konsolidacije podataka u skladištu, ali ne isključuju njegovu nužnost.

Ništa manje kritične promjene iniciraju potrošači pohrane (promjene zahtjeva):

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

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

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

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

Rješenja koja zahtijevaju reviziju cjelokupne arhitekture imat će puno veću cijenu. A za njihovo usvajanje morate imati jako dobre razloge. Na primjer, takav razlog može biti zahtjev koji se ne može implementirati unutar trenutne arhitekture. Onda kažu - postojao je zahtjev koji utječe na arhitekturu.
Stoga također trebamo poznavati naše "granice protiv krhkosti". Arhitektura se ne razvija "u vakuumu" - temelji se na trenutnim zahtjevima i očekivanjima. A ako se situacija iz temelja promijeni - moramo shvatiti da smo izašli iz okvira postojeće arhitekture - i moramo je revidirati, razviti drugačije rješenje - i razmišljati o tranzicijskim putovima.
Na primjer, obećali smo da će nam uvijek na kraju dana biti potrebni podaci u skladištu, svakodnevno ćemo prikupljati podatke koristeći standardna sučelja sustava (kroz skup pogleda). Zatim su iz odjela za upravljanje rizicima dolazili zahtjevi da se podaci zaprime ne na kraju dana, već u trenutku donošenja odluke o kreditiranju. Ne trebate pokušavati "razvući neispruženo" - samo trebate prepoznati tu činjenicu - što prije to bolje. I počnite raditi na pristupu koji će nam omogućiti da riješimo problem.
Ovdje je vrlo tanka linija - ako uzmemo u obzir samo "zahtjeve u trenutku" i ne gledamo nekoliko koraka unaprijed (i nekoliko godina unaprijed), onda povećavamo rizik da prekasno naletimo na zahtjeve koji utječu na arhitekturu - i cijena naše promjene bit će vrlo visoka. Pogled malo unaprijed – unutar granica našeg horizonta – nikada nikome nije naštetio.

Primjer sustava iz “skladišne bajke” samo je primjer vrlo klimavog sustava izgrađenog na krhkim pristupima dizajnu. A ako se to dogodi, uništenje se događa prilično brzo, za ovu klasu sustava.
Zašto mogu tako reći? Tema skladištenja nije nova. Pristupi i inženjerske prakse koje su razvijene tijekom tog vremena bile su usmjerene upravo na to - održavanje održivosti sustava.
Uzmimo jednostavan primjer, jedan od najčešćih razloga zašto projekti za pohranu ne uspijevaju je pokušaj izgradnje pohrane na izvornim sustavima u razvoju bez podudaranja integracijskih sučelja – pokušaj izvlačenja podataka izravno iz tablica. Kao rezultat toga, krenuli su u razvoj - tijekom tog vremena izvorna baza podataka se promijenila - i tokovi preuzimanja u pohrani postali su neoperativni. Prekasno je da se nešto ponovi. A ako se niste osigurali tako što ste napravili nekoliko slojeva stolova unutar skladišta, onda možete sve baciti i početi ispočetka. Ovo je samo jedan primjer, i to jedan od najjednostavnijih.

Talebov kriterij za krhko i antifragilno je jednostavan. Glavni sudac je vrijeme. Ako sustav izdrži test vremena i pokaže svoju "preživljivost" i "neuništivost" - ima svojstvo antikrhkosti.
Ako pri projektiranju sustava uzmemo u obzir antifragilnost kao uvjet, onda će nas to potaknuti da koristimo takve pristupe u izgradnji njegove arhitekture koji će sustav učiniti prilagodljivijim i "kaosu izvana" i "kaosu iznutra". ”. I na kraju će sustav imati duži vijek trajanja.
Nitko od nas ne želi praviti "privremene". I nemojte se zavaravati da sada nema drugog puta. Gledanje nekoliko koraka unaprijed je normalno za čovjeka u bilo kojem trenutku, a posebno u vrijeme krize.

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

Članak o arhitekturi pohrane pretpostavlja da čitatelj ne samo da zna što je to, već ima i određeno iskustvo s takvim sustavima. Ipak, smatrao sam potrebnim to učiniti – vratiti se iskonima, na početak puta, jer. tu se nalazi “uporište” razvoja.

Kako su ljudi došli do zaključka da su skladišta podataka potrebna? I po čemu se razlikuju od samo "vrlo velike baze podataka"?
Davno, kada su u svijetu postojali jednostavno “sustavi za obradu poslovnih podataka”, nije bilo podjele IT sustava na klase kao što su front-end oltp sustavi, back-office dss, sustavi za obradu tekstualnih podataka, skladišta podataka itd. .
To je bilo vrijeme kada je Michael Stonebreaker stvorio prvi relacijski DBMS Ingres.
A to je bilo vrijeme kada je era osobnih računala poput vihora uletjela u računalnu industriju i zauvijek preokrenula sve ideje tadašnje IT zajednice.

Tada je bilo lako pronaći poslovne aplikacije napisane na bazi DBMS-a desktop klase - kao što su Clipper, dBase i FoxPro. A tržište za klijent-poslužitelj aplikacije i DBMS samo je dobivalo zamah. Jedan za drugim pojavili su se poslužitelji baza podataka koji bi dugo zauzeli svoju nišu u IT prostoru - Oracle, DB2 itd.
I kružio je izraz "aplikacija baze podataka". Što je uključivala takva prijava? Pojednostavljeno - neki obrasci za unos putem kojih su korisnici mogli istovremeno unositi informacije, neki izračuni koji su pokrenuti "na gumb" ili "po rasporedu", kao i neka izvješća koja su se mogla vidjeti na ekranu ili pohraniti kao datoteke i poslati na pečat .
"Ništa posebno - samo jednostavna aplikacija, samo baza podataka", primijetio je jedan od mojih prvih mentora. "Zar nije ništa posebno?" - pomislio sam tada.

Ako pažljivo pogledate, još uvijek postoje značajke. Kako korisnici rastu, količina dolaznih informacija se povećava, kako se povećava opterećenje sustava, njegovi programeri-dizajneri, kako bi održali performanse na prihvatljivoj razini, idu na neke "trikove". Prva je podjela monolitnog “sustava za obradu poslovnih podataka” na računovodstvenu aplikaciju koja podržava rad korisnika u on-line načinu rada i zasebnu aplikaciju za paketnu obradu i izvještavanje. Svaka od ovih aplikacija ima svoju bazu podataka i čak se nalazi na zasebnoj instanci poslužitelja baze podataka, s različitim postavkama za različite vrste opterećenja - OLTP i DSS. I među njima se grade tokovi podataka.

to je sve? Čini se da je problem riješen. Što je slijedeće?
A onda tvrtke rastu, njihove potrebe za informacijama se množe. Raste i broj interakcija s vanjskim svijetom. I kao rezultat toga, ne postoji jedna velika aplikacija koja u potpunosti automatizira sve procese, već nekoliko različitih, različitih proizvođača. Povećava se broj sustava koji generiraju informacijsko – izvorne sustave u poduzeću. I prije ili kasnije, pojavit će se potreba za pregledom i usporedbom informacija primljenih iz različitih sustava. Tako se u tvrtki pojavljuje Data Warehousing, nova klasa sustava.
Općeprihvaćena definicija ove klase sustava je sljedeća.

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

Na ovaj način, konsolidacija podataka iz različitih sustava, mogućnost da ih se promatra na određeni “jedinstven” (unificirani) način jedno je od ključnih svojstava sustava klasa za pohranu podataka. To je razlog zašto je pohrana nastala tijekom evolucije IT sustava.

Ključne značajke skladišta podataka

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

Prvo, to su velike količine. Jako veliko. VLDB - tako vodeći dobavljači nazivaju takve sustave kada daju svoje preporuke o korištenju svojih proizvoda. Iz svih sustava tvrtke podaci se slijevaju u ovu veliku bazu podataka i tamo se pohranjuju "zauvijek i nepromijenjeni", kako kažu u udžbenicima (u praksi se život ispostavi kompliciranijim).

Drugo, to su povijesni podaci − "Korporativna memorija" - tzv. skladišta podataka. Što se tiče rada s vremenom u skladištu, sve je prilično zanimljivo. U računovodstvenim sustavima podaci su trenutno relevantni. Zatim korisnik izvrši neku operaciju - i podaci se ažuriraju. Istodobno, povijest promjena možda neće biti sačuvana - ovisi o računovodstvenoj praksi. Uzmimo, na primjer, stanje bankovnog računa. Možda će nas zanimati trenutni saldo u "sada", na kraju dana ili u vrijeme nekog događaja (na primjer, u trenutku izračunavanja rezultata). Ako se prva dva riješe prilično jednostavno, onda će potonji najvjerojatnije zahtijevati posebne napore. Kada radi sa spremištem, korisnik može pristupiti prošlim razdobljima, usporediti ih s trenutnim i tako dalje. Upravo te mogućnosti vezane uz vrijeme značajno razlikuju skladišta podataka od računovodstvenih sustava - dobivanje stanja podataka u različitim točkama na vremenskoj osi - do određene dubine u prošlosti.

Treće, ovo konsolidacija i objedinjavanje podataka . Kako bi njihova zajednička analiza bila moguća, potrebno ih je dovesti u zajednički oblik - unificirani model podataka , usporediti činjenice s jedinstvenim referencama. Ovdje može postojati nekoliko aspekata i poteškoća. prvenstveno - konceptualni – pod istim pojmom različiti ljudi iz različitih odjela mogu razumjeti različite stvari. I obrnuto – drugačije nazvati nešto što je u biti ista stvar. Kako osigurati "jedinstveni pogled", a pritom očuvati specifičnosti vizije određene skupine korisnika?

Četvrto, to je rad s kvaliteta podataka . U procesu učitavanja podataka u pohranu oni se čiste, izvode opće transformacije i transformacije. Opće transformacije moraju se obaviti na jednom mjestu - a zatim koristiti za izradu različitih izvješća. Time će se izbjeći nesuglasice koje izazivaju toliku iritaciju kod poslovnih korisnika – posebice kod menadžmenta, koji se za stol stavljaju s brojevima iz različitih odjela koji se međusobno ne slažu. Loša kvaliteta podataka dovodi do pogrešaka i odstupanja u izvješćima, a posljedica toga je smanjenje razine povjerenje korisnika na cijeli sustav, na cijelu analitičku službu u cjelini.

arhitektonski koncept

Svi koji su naišli na spremište, najvjerojatnije su uočili nekakvu "slojevitu strukturu" - jer. upravo je ova arhitektonska paradigma zaživjela za sustave ove klase. I to ne slučajno. Slojevi pohrane mogu se percipirati kao zasebne komponente sustava - sa svojim zadacima, područjima odgovornosti, "pravilima igre".
Slojevita arhitektura sredstvo je rješavanja složenosti sustava – svaki sljedeći sloj apstrahira se od složenosti interne implementacije prethodnog. Ovaj pristup vam omogućuje da identificirate zadatke iste vrste i riješite ih na ujednačen način, bez ponovnog izmišljanja "bicikla" svaki put od nule.
Shematski idejni arhitektonski dijagram prikazan je na slici. Ovo je pojednostavljeni dijagram koji odražava samo ključnu ideju - koncept, ali bez "anatomskih detalja" koji će nastati dubljim proučavanjem detalja.

Kao što je prikazano na dijagramu, konceptualno odaberite sljedeće slojeve. Tri glavna sloja koji sadrže područje za pohranu podataka (označeno popunjenim pravokutnikom) i softver za učitavanje podataka (uvjetno prikazan strelicama iste boje). Kao i pomoćni - servisni sloj, koji, međutim, igra vrlo važnu povezujuću ulogu - upravljanje učitavanjem podataka i kontrolu kvalitete.

Primary Data Layer - primarni sloj podataka (ili uprizorenje , ili operativni sloj ) - dizajniran je za učitavanje iz izvornih sustava i spremanje primarnih informacija, bez transformacija - u izvornoj kvaliteti i uz podršku za cjelovitu povijest promjena.
Zadatak ovog sloja– apstrahirati sljedeće slojeve pohrane iz fizičkog uređaja izvora podataka, metode prikupljanja podataka i metode za izdvajanje delte promjena.

Core Data Layer - jezgra za pohranu - središnja komponenta sustava, koja razlikuje pohranu od samo “platforme batch integracije” ili “velikog deponija podataka”, budući da je njegova glavna uloga konsolidacija podataka iz različitih izvora, redukcija na uniformne strukture, ključevi. Prilikom učitavanja u jezgru obavlja se glavni posao s kvalitetom podataka i općim transformacijama, što može biti prilično složeno.
Zadatak ovog sloja- apstrahirati svoje potrošače od osobitosti logičke strukture izvora podataka i potrebe za usporedbom podataka iz različitih sustava, osigurati integritet i kvalitetu podataka.

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

Gore opisani slojevi sastoje se od trajnog prostora za pohranu podataka, kao i softverskog modula za učitavanje i transformaciju podataka. Ova podjela na slojeve i regije je logična. Fizička implementacija ovih komponenti može biti različita - čak možete koristiti različite platforme za pohranu ili transformaciju podataka na različitim slojevima, ako je to učinkovitije.
Područja pohrane sadrže tehničke (tablice međuspremnika) koje se koriste u procesu transformacije podataka i ciljne tablice, kojima pristupa potrošačka komponenta. Dobra je praksa "pokriti" ciljne tablice pogledima. To olakšava naknadno održavanje i razvoj sustava. Podaci u ciljnim tablicama sva tri sloja označeni su posebnim tehničkim poljima (meta-atributima), koja služe za osiguravanje procesa učitavanja podataka, kao i za informacijsku reviziju tokova podataka u pohrani.

Također se izdvaja posebna komponenta (ili skup komponenti) koja pruža servisne funkcije za sve slojeve. Jedna od njegovih ključnih zadaća - kontrolna funkcija - je osigurati "jedna pravila igre" za cijeli sustav kao cjelinu, ostavljajući pravo korištenja različitih opcija za implementaciju svakog od gore opisanih slojeva - uklj. koristiti različite tehnologije za učitavanje i obradu podataka, različite platforme za pohranu itd. nazovimo ga servisni sloj (Sloj usluge) . Ne sadrži poslovne podatke, ali ima svoje strukture za pohranu - sadrži područje metapodataka, kao i područje za rad s kvalitetom podataka (i eventualno druge strukture, ovisno o funkcijama koje su mu dodijeljene).

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

smanjena je složenost zadatka koji se dodijeljuje programeru funkcionalnosti određene komponente (ne mora istovremeno rješavati probleme integracije s vanjskim sustavima, promišljati postupke čišćenja podataka i razmišljati o optimalnom prikazu podataka za potrošači) - zadatak je lakše razložiti, procijeniti i izvesti malu isporuku;
u posao možete uključiti razne izvođače (pa čak i timove ili izvođače) – jer ovaj pristup vam omogućuje da učinkovito paralelizirate zadatke, smanjujući njihov međusobni utjecaj;
Prisutnost trajnog uprizorenja omogućuje vam brzo povezivanje izvora podataka bez dizajniranja cijele jezgre ili vitrina za cijelo predmetno područje, a zatim postupno izgraditi ostale slojeve prema prioritetima (štoviše, podaci će već biti u spremištu - dostupni analitičarima sustava, što će uvelike olakšati zadatke naknadnog razvoja repozitorija);
prisutnost jezgre omogućuje da se sav rad s kvalitetom podataka (kao i mogući promašaji i pogreške) sakrije od izloga i od krajnjeg korisnika, a što je najvažnije, korištenjem ove komponente kao jedinstvenog izvora podataka za izloge možete izbjeći probleme s konvergencijom podataka zbog implementacije uobičajenih algoritama na jednom mjestu;
isticanje prodajnih izloga omogućuje vam da uzmete u obzir razlike i specifičnosti razumijevanja podataka koje korisnici različitih odjela mogu imati, a njihovo dizajniranje za BI zahtjeve omogućuje vam ne samo izdavanje agregiranih podataka, već i osiguravanje pouzdanosti podataka pružanjem mogućnosti za detaljnu analizu primarnim pokazateljima;
Prisutnost sloja usluge omogućuje vam da izvršite analizu podataka od kraja do kraja (podatke), koristite jedinstvene alate za reviziju podataka, uobičajene pristupe naglašavanju delta promjena, rad s kvalitetom podataka, upravljanje opterećenjem, praćenje pogrešaka i dijagnostičke alate , i ubrzava rješavanje problema.

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

promjene iz izvornih sustava se obrađuju na stažiranju - u kernelu se modificiraju samo one niti na koje utječu te tablice za provođenje, učinak na izloge je minimalan ili ga nema;
promjene zahtjeva kupaca obrađuju se uglavnom u izlozima (osim ako to zahtijeva dodatne informacije koje već nisu u skladištu).

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

Jezgra sustava

Krenimo "od sredine" - jezgre sustava ili srednjeg sloja. Nije označeno kao temeljni sloj. Jezgra obavlja ulogu konsolidacije podataka - svođenje na pojedinačne strukture, imenike, ključeve. Ovdje se obavlja glavni posao s kvalitetom podataka - čišćenje, transformacija, objedinjavanje.

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

Model motora za pohranu i model podataka poduzeća

Glavni zadatak srednjeg skladišnog sloja je stabilnost. Zato je ovdje glavni fokus na modelu podataka. Obično se naziva "poduzetnički model podataka". Nažalost, oko njega se stvorio određeni oreol mitova i apsurda koji ponekad dovode do potpunog odustajanja od njegove konstrukcije, ali uzalud.

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

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

Mit 3. Razvoj modela jezgre pohrane može potrajati mnogo mjeseci, a tijekom tog vremena projekt će zapravo biti zamrznut. Osim toga, to zahtijeva suludu količinu sastanaka i sudjelovanje mnogih ljudi.
Zapravo. Model repozitorija može se razvijati iterativno, dio po dio, zajedno sa spremištem. Za nepokrivena područja postavljaju se "točke proširenja" ili "stubovi" - t.j. primjenjuju se neke "univerzalne konstrukcije". Istovremeno, morate znati kada stati kako ne biste dobili super-univerzalnu stvar od 4 tablice, u koju je teško i "ubaciti podatke" i (još teže) doći do njih. I što je izrazito neoptimalno u smislu izvedbe.

Trebat će vremena za razvoj modela. Ali ovo nije vrijeme utrošeno na "crtanje entiteta" - ovo je vrijeme potrebno za analizu predmetnog područja, razumijevanje kako su podaci strukturirani. Zato su analitičari vrlo usko uključeni u ovaj proces, kao i različiti poslovni stručnjaci. I to se radi selektivno. A ne organiziranjem sastanaka s suludim brojem ljudi, slanjem ogromnih upitnika, itd.
Kvalitetna analiza poslovanja i sustava ključ je za izgradnju temeljnog modela pohrane. Morate razumjeti puno stvari: gdje (u kojim sustavima) nastaju podaci, kako su raspoređeni, u kojim poslovnim procesima kruže itd. Kvalitativna analiza nikada nije štetila niti jednom sustavu. Dapače, naprotiv, problemi nastaju iz "praznih točaka" u našem razumijevanju.

Razvoj modela podataka nije proces izmišljanja i smišljanja nečeg novog. Zapravo, model podataka u tvrtki već postoji. A proces njegovog dizajna više liči na "iskapanja". Model je nježno i pažljivo izvučen na vidjelo s "tla" korporativnih podataka i odjeven u strukturiran oblik.

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

Mit 5. Izrada korporativnog modela vrlo je ozbiljan, složen i odgovoran posao. I strašno je pogriješiti.
Zapravo. Osnovni model, iako bi trebao biti stabilan, još uvijek nije “liven u metalu”. Kao i sve druge odluke o dizajnu, njegova se struktura može pregledati i modificirati. Samo ne zaboravite na ovu njezinu kvalitetu. Ali to uopće ne znači da na njemu "ne možete disati". A to ne znači da su neprihvatljiva privremena rješenja i "stubovi" koje treba planirati za obradu.

Mit 6. Ako imamo izvor podataka - na primjer, NSI sustav (ili sustav upravljanja glavnim podacima - MDM), onda bi trebao na dobar način odgovarati korporativnom modelu (posebno ako je nedavno dizajniran i nije imao vremena za nabavu “nuspojave”, “tradicije” i privremene zgrade). Ispada da za ovaj slučaj - ne trebamo model kernela?
Zapravo. Da, u ovom slučaju je konstrukcija modela jezgre pohrane uvelike olakšana – jer slijedimo vrhunski gotov konceptualni model. Ali to uopće nije isključeno. Zašto? Jer prilikom izgradnje modela određenog sustava vrijede određena pravila - koje vrste tablica koristiti (za svaki entitet), kako inacirati podatke, s kojom granularnošću čuvati povijest, koje meta-atribute (tehnička polja koristiti) itd. .

Osim toga, bez obzira na prekrasan i sveobuhvatan sustav NSI i MDM koji imamo, u pravilu će postojati nijanse povezane s postojanjem lokalnih imenika „otprilike istih“ u drugim računovodstvenim sustavima. I taj problem, htjeli mi to ili ne, morat će se riješiti u skladištu, jer se ovdje prikupljaju izvještaji i analitika.

Primarni podatkovni sloj (ili scenski ili operativni sloj koji se može historijati)

Na njemu je označen kao primarni podatkovni sloj. Uloga ove komponente: integracija s izvornim sustavima, učitavanje i pohranjivanje primarnih podataka, kao i preliminarno čišćenje podataka - provjera usklađenosti s pravilima formatno-logičke kontrole, fiksiranom u "sporazumu o sučelju interakcije" s izvorom.
Osim toga, ova komponenta rješava vrlo važan zadatak za pohranu - isticanje "prave promjene delte" - bez obzira na to dozvoljava li vam izvor praćenje promjena u podacima ili ne i kako (po kojem kriteriju se one mogu "uloviti") . Čim su podaci ušli u fazu, problem delta selekcije je već jasan za sve ostale slojeve, zahvaljujući označavanju meta-atributima.

Podaci u ovom sloju pohranjeni su u strukturama koje su što bliže izvornom sustavu – kako bi primarni podaci bili što bliže njihovom izvornom obliku. Drugi naziv za ovu komponentu je "operativni sloj".
Zašto jednostavno ne upotrijebite ustaljeni izraz "uprizorenje"? Činjenica je da je ranije, prije "ere velikih podataka i VLDB", prostor na disku bio vrlo skup - a često su primarni podaci, ako su se pohranjivali, bili samo u ograničenom vremenskom razdoblju. A često se naziva i naziv "uprizorenje". čistiti pufer.
Sada je tehnologija iskoračila naprijed – i možemo si priuštiti ne samo pohranjivanje svih primarnih podataka, već i njihovo historiziranje uz stupanj granularnosti koji je jedino moguć. To ne znači da ne bismo trebali kontrolirati rast podataka i ne eliminira potrebu upravljanja životnim ciklusom informacija optimiziranjem troškova pohrane podataka, ovisno o „temperaturi“ korištenja – t.j. premještanje "hladnih podataka", koji su manje traženi, na jeftinije medije i platforme za pohranu podataka.

Što nam daje prisutnost "povijesnog uprizorenja":

mogućnost pogreške (u strukturama, u algoritmima transformacije, u granularnosti čuvanja povijesti) - nakon što smo u potpunosti historizirali primarne podatke u zoni dostupnosti pohrane, uvijek možemo ponovno učitati naše tablice;
prilika za razmišljanje - možemo uzeti vremena s razvojem velikog fragmenta jezgre u ovoj iteraciji razvoja spremišta, jer u našem uprizorenju, u svakom slučaju, bit će, i to s ravnomjernim vremenskim horizontom (postojat će jedna “polazišna točka povijesti”);
mogućnost analize - spremit ćemo i one podatke kojih više nema u izvoru - mogli bi se tamo prepisati, otići u arhivu itd. – kod nas ostaju dostupni za analizu;
mogućnost informacijske revizije - zahvaljujući najdetaljnijim primarnim informacijama, tada ćemo moći shvatiti kako je preuzimanje funkcioniralo za nas, da smo na kraju dobili takve brojke (za to morate imati i oznaku meta-atributima i odgovarajući metapodaci na kojima preuzimanje radi - to se odlučuje na sloju usluge).

Koje poteškoće mogu nastati u izgradnji "povijesnog uprizorenja":

bilo bi zgodno postaviti zahtjeve za transakcijski integritet ovog sloja, ali praksa pokazuje da je to teško postići (to znači da u ovom području ne jamčimo referentni integritet nadređenih i podređenih tablica) - usklađivanje integriteta događa se na naknadnom slojevi;
ovaj sloj sadrži vrlo velike količine (najveće u skladištu - unatoč svoj zalihosti analitičkih struktura) - i morate biti u mogućnosti rukovati takvim volumenima - i u smislu učitavanja i u smislu upita (inače možete ozbiljno degradirati performanse cjelokupnog skladišta).

Što još reći o ovom sloju.
Prvo, ako se odmaknemo od paradigme “procesa utovara od kraja do kraja”, onda pravilo “karavan se kreće brzinom posljednje deve” više ne funkcionira za nas, odnosno napuštamo princip “karavana” i prijeđite na princip “transportne trake”: uzeli smo podatke iz izvora - stavili u vaš sloj - spremni za preuzimanje sljedećeg dijela. To znači da
1) ne čekamo da se obrada dogodi na drugim slojevima;
2) ne ovisimo o rasporedu dostavljanja podataka od strane drugih sustava.
Jednostavno rečeno, planiramo proces učitavanja koji uzima podatke iz jednog izvora putem određene metode povezivanja do njega, provjerava, izdvaja delta - i stavlja podatke u etablirane ciljne tablice. I to je to.

Drugo, ti su procesi, očito, raspoređeni vrlo jednostavno - moglo bi se reći trivijalno, s gledišta logike. A to znači da se mogu vrlo dobro optimizirati i parametrirati, smanjujući opterećenje našeg sustava i ubrzavajući proces povezivanja izvora (vrijeme razvoja).
Da bi se to dogodilo, morate jako dobro poznavati tehnološke značajke platforme na kojoj ova komponenta radi – i tada možete napraviti vrlo učinkovit alat.

Sloj analitičkih vitrina

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

Ako je potrošač vanjski sustav, tada, u pravilu, diktira strukture podataka koje su mu potrebne i pravila za prikupljanje informacija. Dobar pristup je onaj u kojem je potrošač odgovoran za ispravno prikupljanje podataka. Skladište podataka je pripremilo, formiralo izlog, dalo mogućnost inkrementalnog prikupljanja podataka (označavanje meta-atributima za naknadni odabir delta promjena), a potrošački sustav potom upravlja i odgovoran je za način na koji koristi ovaj izlog. Ali postoje posebnosti: kada sustav nema aktivnu komponentu za prikupljanje podataka, ili je potrebna vanjska komponenta koja će obavljati integracijsku funkciju, ili će pohrana djelovati kao "integracijska platforma" i osiguravati daljnji ispravan inkrementalni prijenos podataka - izvan skladišta. Ovdje se pojavljuju mnoge nijanse, a pravila interakcije sučelja trebale bi promisliti i razumjeti obje strane (međutim, kao i uvijek, kada je u pitanju integracija). U pravilu se na takve izloge primjenjuje rutinsko čišćenje/arhiviranje podataka (rijetko je potrebno da se ti „podaci o tranzitu” pohranjuju dulje vrijeme).

Najveću važnost u smislu analitičkih zadataka imaju vitrine "za ljude" - točnije, za BI alate s kojima rade.
Međutim, postoji kategorija "posebno naprednih korisnika" - analitičara, znanstvenika s podacima - koji ne trebaju niti BI alate niti rutinske procese za popunjavanje vanjskih specijaliziranih sustava. Potrebna im je neka vrsta "zajedničkog izloga" i "vlastitog sandboxa", gdje mogu kreirati tablice i transformacije prema vlastitom nahođenju. U ovom slučaju, odgovornost repozitorija je osigurati da se ova zajednička baza podataka popune u skladu s propisima.
Zasebno možemo izdvojiti takve potrošače kao Data Mining alati - duboka analiza podataka. Ovi alati imaju svoje zahtjeve za pripremu podataka, a koriste ih i znanstvenici. Za repozitorij se zadatak svodi - opet na podršku servisu za preuzimanje određenih vitrina dogovorenog formata.

No, vratimo se analitičkim izlozima. Upravo su oni od interesa sa stajališta dizajnera pohrane u ovom podatkovnom sloju.
Po mom mišljenju, najbolji vremenski testiran pristup dizajniranju podatkovnih prodajnih mjesta, za koji su sada “naoštrene” gotovo sve BI platforme, jest pristup Ralpha Kimballa. Poznat je po imenu dimenzionalno modeliranje – višedimenzionalno modeliranje. Postoji jako puno publikacija na ovu temu. Na primjer, osnovna pravila mogu se pronaći u publikaciji. I naravno, možete preporučiti od gurua multivarijantnog modeliranja. Još jedan koristan izvor su Kimballovi savjeti.
Višedimenzionalni pristup stvaranju izloga tako je dobro opisan i razrađen - kako evanđelisti metoda, tako i vodeći dobavljači softvera - da nema smisla ovdje se zadržavati na njemu detaljnije - izvorni izvor je uvijek poželjniji.

Htio bih staviti samo jedan naglasak. “Izvještavanje i analitika” je drugačije. Postoji "teško izvješćivanje" - unaprijed naručena izvješća koja se generiraju u obliku datoteka i dostavljaju korisnicima putem predviđenih kanala isporuke. A tu su i informacijske ploče - BI nadzorne ploče. U osnovi, to su web aplikacije. A zahtjevi za vrijeme odziva ovih aplikacija isti su kao i za bilo koju drugu web aplikaciju. To znači da je normalno vrijeme osvježavanja za BI ploču sekunde, a ne minute. Važno je to imati na umu pri osmišljavanju rješenja. Kako to postići? Standardna metoda optimizacije: gledamo od čega se sastoji vrijeme odziva i na što možemo utjecati. Na što trošiš najviše vremena? Za fizičko (disk) čitanje baze podataka, za prijenos podataka preko mreže. Kako smanjiti količinu pročitanih i prenesenih podataka po zahtjevu? Odgovor je očit i jednostavan: trebate ili agregirati podatke ili primijeniti filtar na velike tablice činjenica koje sudjeluju u upitu i isključiti spajanje velikih tablica (reference na tablice činjenica trebale bi proći samo kroz dimenzije).

Čemu služi BI? Kako je to zgodno? Zašto je multivarijantni model učinkovit?
BI omogućuje korisniku obavljanje takozvanih "ad hoc upita". Što to znači? To znači da ne znamo točno zahtjev unaprijed, ali znamo koje pokazatelje u kojim odjeljcima korisnik može zatražiti. Korisnik generira takav upit odabirom odgovarajućih BI filtara. A zadatak BI developera i dizajnera izložbenog prostora je osigurati takvu logiku rada aplikacije tako da se podaci ili filtriraju ili agregiraju, izbjegavajući situaciju u kojoj se traži previše podataka i aplikacija "visi". Obično počinju s agregiranim brojkama, zatim se udubljuju u detaljnije podatke, ali usput postavljaju potrebne filtre.

Nije uvijek dovoljno jednostavno izgraditi "pravu zvijezdu" - i dobiti prikladnu strukturu za BI. Ponekad morate negdje primijeniti denormalizaciju (dok gledate unatrag kako će to utjecati na opterećenje), a negdje napraviti sekundarne izloge i agregate. Negdje za dodavanje indeksa ili projekcija (ovisno o DBMS-u).

Dakle, putem “pokušaja i pogrešaka” možete dobiti strukturu koja je optimalna za BI – koja će uzeti u obzir značajke i DBMS-a i BI platforme, kao i zahtjeve korisnika za prezentacijom podataka.
Ako uzmemo podatke iz „jezgre“, tada će takva obrada izloga biti lokalne prirode, bez utjecaja na složenu obradu primarnih podataka primljenih izravno iz izvornih sustava – podatke samo „prebacujemo“ u format prikladan za BI. A možemo si to priuštiti mnogo puta, na različite načine, u skladu s različitim zahtjevima. Mnogo je lakše i brže to učiniti na temelju podataka kernela nego sastaviti iz "primarnog" (čija struktura i pravila, kao što znamo, također mogu "plutati").

servisni sloj

Sloj usluge ( - Service Layer) odgovoran je za implementaciju uobičajenih (servisnih) funkcija koje se mogu koristiti za obradu podataka u različitim slojevima pohrane - upravljanje opterećenjem, upravljanje kvalitetom podataka, alati za dijagnostiku problema i praćenje itd.
Prisutnost ove razine osigurava transparentnost i strukturirane tokove podataka u pohrani.

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

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

Proces upravljanja opterećenjem možete izgraditi na različite načine. Jedan od mogućih pristupa je sljedeći: cijeli skup tablica za pohranu podijelimo u module. U modul se mogu uključiti samo tablice jednog sloja. Tablice uključene u svaki modul učitavaju se kao dio zasebnog procesa. nazovimo to kontrolni proces . Pokretanje procesa kontrole postavlja se na vlastiti raspored. Kontrolni proces orkestrira pozive atomskim procesima, od kojih svaki učitava jednu ciljnu tablicu, a također sadrži neke uobičajene korake.
Očito, dovoljno je jednostavno podijeliti scenske tablice u module - prema izvornim sustavima, odnosno njihovim spojnim točkama. Ali za kernel je to već teže izvedivo – jer. tu moramo osigurati integritet podataka, što znači da moramo uzeti u obzir ovisnosti. Oni. doći će do sukoba koje treba riješiti. I postoje različiti načini za njihovo rješavanje.

Važna točka u upravljanju opterećenjem je razvoj jedinstvenog pristupa rukovanju pogreškama. Pogreške se klasificiraju prema stupnju kritičnosti. Kada dođe do kritične greške, proces treba zaustaviti, i to što je prije moguće, jer. njegova pojava ukazuje na značajan problem koji može dovesti do oštećenja podataka u pohrani. Dakle, upravljanje opterećenjem nije samo pokretanje procesa, već i njihovo zaustavljanje, kao i sprječavanje nepravovremenog pokretanja (greškom).

Za rad sloja usluge stvorena je posebna struktura metapodataka. Ovo područje će pohraniti informacije o procesima učitavanja, učitanim skupovima podataka, kontrolnim točkama koje se koriste za održavanje inkrementa (koji je proces pročitao do koje točke) i druge informacije o uslugama koje su potrebne za funkcioniranje sustava.
Važno je napomenuti da su sve ciljne tablice u svim slojevima označene posebnim skupom meta-polja, od kojih je jedno ID procesa koji je ažurirao ovaj niz. Za tablice unutar spremišta, ovo označavanje procesa omogućuje jedinstven način naknadnog izdvajanja delta promjena. Kod učitavanja podataka u primarni podatkovni sloj situacija je kompliciranija - algoritam za izdvajanje delta za različite učitane objekte može biti različit. S druge strane, logika obrade prihvaćenih izmjena i njihova valjanja na ciljne tablice za jezgru i izloge puno je kompliciranija nego za staging, gdje je sve prilično trivijalno - lako je parametrirati i razmišljati o tipičnim koracima koji se mogu ponovno koristiti (procedure ).

Ovdje ne postavljam zadatak da u potpunosti pokrijem ovu temu - organizaciju utovara - stavljam samo naglaske na koje vrijedi obratiti pažnju.
Gore navedeni pristup samo je jedna od opcija. Prilično je prilagodljiv. A njegov "konceptualni prototip" bio je Toyotin transporter i sustav "baš na vrijeme". Oni. odmičemo se od raširene paradigme isključivo “noćnog učitavanja podataka”, a učitavamo se u malim obrocima tijekom dana – kako su podaci spremni u raznim izvorima: što je došlo, to je učitano. U isto vrijeme imamo mnogo paralelnih procesa. A "vrući rep" svježih podataka stalno će "treptati" - i nakon nekog vremena izjednačiti. Moramo uzeti u obzir ovu značajku. I, ako je potrebno, oblikovati prilagođene vitrine "kriške", gdje je sve već integralno. Oni. nemoguće je istovremeno postići i učinkovitost i dosljednost (cjelovitost). Trebamo balans – negdje je jedno važno, negdje drugo.

Izuzetno je važno osigurati sredstva za evidentiranje i praćenje. Dobra praksa je korištenje utipkanih događaja, gdje možete postaviti različite parametre i postaviti sustav obavijesti – pretplatu na određene događaje. Jer vrlo je važno da kada je potrebna intervencija administratora sustava, on to što prije sazna i dobije sve potrebne dijagnostičke informacije. Dnevnici se također mogu koristiti za post-faktum analizu problema, kao i za istraživanje incidenata kvarova u sustavu, uklj. kvaliteta podataka.

Dizajnirati i održavati modele podataka skladišta

Zašto je važno obratiti pažnju na dizajn modela podataka pri razvoju bilo kojeg sustava u kojem je uključena baza podataka (a posebno u skladištu)? Zašto jednostavno ne ubacite skup tablica, bilo gdje - čak i u uređivaču teksta? Zašto su nam potrebne ove slike?
Čudno je da čak i iskusni programeri postavljaju takva pitanja.
Zapravo, da, ništa vas ne sprječava da skicirate tablice - i počnete ih koristiti. Ako ... ako u isto vrijeme u glavi (!) Programer ima skladnu cjelokupnu sliku strukture koju oblikuje. Što ako postoji više programera? Ali što ako će netko drugi koristiti ove tablice? Ali što ako vrijeme prođe - osoba napusti ovo područje, a zatim se opet vrati u njega?

Je li to moguće shvatiti bez modela? Uglavnom, možete. I da to shvatite, i "procijenite slike na komadu papira", i "počistite - riješite" podatke. No, puno je lakše, jasnije i brže koristiti gotov artefakt – podatkovni model. I također razumjeti "logiku njegove strukture" - t.j. Bilo bi lijepo imati zajednička pravila igre.

A najvažnije nije ni to. Ono što je najvažnije, pri dizajniranju modela prisiljeni smo (jednostavno bez opcija!) pobliže i dublje proučiti predmetno područje, značajke strukture podataka i njihovu upotrebu u raznim poslovnim slučajevima. I ona pitanja koja bismo lako "odgurnuli" kao složena, "zamagljena" bacanjem naših znakova, bez pokušaja oblikovati model - bit ćemo prisiljeni postaviti i odlučiti sada, tijekom analize i dizajna, a ne kasnije - kada gradimo izvješća i svaki put razmišljamo o tome "kako smanjiti nespojivo" i "izmisliti kotač".

Ovaj pristup je jedna od onih inženjerskih praksi koje omogućuju stvaranje antilomljivih sustava. Budući da su jasno raspoređeni, transparentni, lako se razvijaju, a njihove "granice krhkosti" su odmah vidljive, moguće je točnije procijeniti "razmjere katastrofe" kada se pojave novi zahtjevi i vrijeme potrebno za redizajn (ako je potrebno) .
Dakle, model podataka jedan je od glavnih artefakata koji se moraju održavati tijekom razvoja sustava. Na dobar način, trebao bi biti "na stolu" za svakog analitičara, programera itd. – svi oni koji su uključeni u projekte razvoja sustava.

Dizajniranje modela podataka je posebna, vrlo opsežna tema. Postoje dva glavna pristupa dizajnu skladišta.
Pristup je dobar za kernel "entitet-odnos" - kada se na temelju proučavanja predmetnog područja, točnije njegovog odabranog područja, gradi normalizirani (3NF) model. Ovdje igra isti “korporativni model” o kojem smo gore govorili.

Prilikom oblikovanja analitičkih vitrina prikladan višedimenzionalni model . Ovaj pristup je dobro za razumijevanje poslovnih korisnika. ovo je model koji je jednostavan i prikladan za ljudsku percepciju - ljudi operiraju s razumljivim i poznatim konceptima metrike (indikatora) i odjeljcima po kojima se analiziraju. A to nam omogućuje da jednostavno i jasno izgradimo proces prikupljanja zahtjeva - crtamo skup "matrica rezova i indikatora", komunicirajući s predstavnicima različitih odjela. A onda ga dovodimo u jednu strukturu - "model analize": formiramo "sabirnicu mjerenja" i utvrđujemo činjenice koje su na njima definirane. Usput radimo na hijerarhijama i pravilima agregiranja.

Nadalje, vrlo je lako prijeći na fizički model, dodajući elemente optimizacije uzimajući u obzir značajke DBMS-a. Na primjer, za Oracle bi to bilo particioniranje, skup indeksa i tako dalje. Za Verticu će se koristiti druge tehnike - sortiranje, segmentacija, sekcija.
Može biti potrebna i posebna denormalizacija - kada namjerno unosimo redundantnost u podatke, zahvaljujući čemu poboljšavamo performanse upita, ali istovremeno kompliciramo ažuriranje podataka (jer će se redundantnost morati uzeti u obzir i podržati u procesu učitavanje podataka). Možda ćemo, kako bismo poboljšali performanse, također morati kreirati dodatne agregatne tablice ili koristiti takve dodatne značajke DBMS-a kao što su projekcije u Vertici.

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

zadatak je izgraditi konceptualni (logički) model jezgre – analiza sustava i poslovanja – proučavanje predmetnog područja, produbljivanje u detalje i uvažavanje nijansi „živih podataka“ i njihove uporabe u poslovanju;
zadatak izgradnje modela analize – a potom i konceptualnog (logičkog) modela izloga;
zadatak izgradnje fizičkih modela je upravljanje redundantnošću podataka, optimizacija uzimajući u obzir značajke DBMS-a za upite i učitavanje podataka.

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

Hajde da rezimiramo.

Model podataka nije skup "lijepih slika", a proces njegovog dizajna nije proces njihovog crtanja. Model odražava naše razumijevanje predmetnog područja. A proces njegovog sastavljanja je proces njegovog proučavanja i istraživanja. Ovdje se gubi vrijeme. I uopće ne "crtati i bojati".
Model podataka je artefakt dizajna, način dijeljenja informacija na strukturiran način između članova tima. Da bi se to postiglo, mora biti svima razumljivo (to je predviđeno zapisom i objašnjenjem) i dostupno (objavljeno).
Model podataka se ne stvara jednom i zamrzava, već se stvara i razvija u procesu razvoja sustava. Mi sami postavljamo pravila za njegov razvoj. A možemo ih promijeniti ako vidimo kako ih učiniti boljim, jednostavnijim, učinkovitijim.
Model podataka (fizički) omogućuje vam da konsolidirate i koristite skup najboljih praksi usmjerenih na optimizaciju – t.j. koristiti tehnike koje su već radile za ovaj DBMS.

Značajke projekata skladišta podataka

Zadržimo se na značajkama projekata unutar kojih tvrtka gradi i razvija skladišta podataka. A pogledajmo ih s gledišta utjecaja arhitektonskog aspekta. Zašto je važno graditi arhitekturu za takve projekte, i to od samog početka. A upravo prisutnost dobro osmišljene arhitekture daje fleksibilnost projektu skladišta podataka, omogućuje vam učinkovitu raspodjelu posla između izvođača, a također olakšava predviđanje rezultata i čini proces predvidljivijim.

Skladište podataka je prilagođeni softver

Skladište podataka je uvijek "razvoj po narudžbi", a ne upakirano rješenje. Da, postoje BI aplikacije specifične za industriju koje uključuju referentni model podataka, unaprijed konfigurirane ETL procese iz uobičajenih izvora (na primjer, ERP sustavi), skup tipičnih BI nadzornih ploča i izvješća. Ali u praksi se skladište rijetko implementira - kao "kutija". Radim sa skladištem oko 10 godina i nikada nisam vidio takvu priču. Uvijek postoje nijanse povezane s jedinstvenim značajkama tvrtke - poslovnim i IT krajolikom. Stoga je pomalo nepromišljeno nadati se da će "dobavljač" koji pruža rješenje osigurati arhitekturu. Arhitektura takvih sustava često sazrijeva unutar same organizacije. Ili ga formiraju stručnjaci tvrtke izvođača, koja je glavni izvođač projekta.

Skladište podataka je integracijski projekt

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

Skladište podataka je timski projekt

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

Arhitektura bi trebala pružiti mogućnost organiziranja njihova paralelnog rada, uz zadržavanje integriteta i izbjegavanje dupliciranja iste funkcionalnosti na različitim mjestima, od strane različitih ljudi. Osim nepotrebnih troškova rada, takvo dupliciranje može kasnije dovesti do odstupanja u podacima.

Osim toga, kada je toliko ljudi i timova, često raštrkanih, uključeno u proces razvoja sustava, neminovno se postavlja pitanje: kako između njih izgraditi komunikacijsku i informacijsku interakciju. Što se više standardnih i razumljivih pristupa i praksi koristi, to je lakše, praktičnije i učinkovitije postaviti takav rad. Uključujući, vrijedi razmisliti o sastavu "radnih artefakata", među kojima su za skladišta podataka broj 1 modeli podataka (vidi prethodni odjeljak).

Skladište podataka ima duži vijek trajanja u odnosu na druge sustave

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

Što ja imam razloga da tako vjerujem?
Prvo, izgradnja skladišta je proces koji zahtijeva puno resursa: osim stvarnih troškova opreme, licenci za potreban tehnološki softver i razvoja, u to su uključeni i gotovo svi sustavi i odjeli tvrtke. Ponoviti cijeli ovaj proces iznova je vrlo hrabar pothvat.

Drugo, ako skladište ima ispravnu arhitekturu, onda može lako preživjeti i promjenu izvornih sustava, pojavu novih zahtjeva krajnjih korisnika i rast volumena podataka.
Ako je arhitektura ispravna, tokovi informacija transparentni, onda se takav sustav može razvijati dovoljno dugo bez rizika da budete u situaciji stupora pri uvođenju promjena zbog poteškoća u procjeni utjecaja.

Postupni iterativni razvoj

Zadnje što bi Kupac želio, upuštajući se u priču sa pohranom, je zamrznuti svoje zahtjeve na godinu-dvije, dok se ne osmisli potpuni korporativni model podataka, ne povežu svi izvori u potpunosti itd.

Skladište podataka u očima kupaca često izgleda kao apsolutno čudovište - zadaci, ciljevi i horizont razvoja sustava su tako opsežni. I često se Kupac boji da će IT odjel “na račun svog budžeta” riješiti neke “vlastite zadatke”. I opet smo suočeni s pitanjem interakcije među ljudima i sposobnosti mirnog iznošenja stajališta i pregovaranja.

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

Iako treba napomenuti da se “čuda ne događaju” – a za “početak” također treba vremena. Za pohrane može biti prilično velik - budući da se radi o velikim količinama podataka, to su povijesni podaci - za stara razdoblja, kada su se pravila obrade informacija mogla razlikovati od trenutnih. Stoga je potrebno dovoljno vremena za analitički razvoj, interakciju s izvornim sustavima i niz "pokušaja i pogrešaka", uključujući testove opterećenja na stvarnim podacima.

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

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

Balans inovativnosti i provjerenih rješenja

Unatoč činjenici da je tema pohrane vrlo "drevna" (ako je takva riječ primjenjiva na tako mladu industriju kao što je IT) i prilično konzervativna. Ipak, napredak ne miruje - i ograničenja koja su prije postojala zbog skupih i sporih diskova, skupe memorije itd. - sada su uklonjeni. A ujedno je vrijeme da se preispitaju neki arhitektonski pristupi. Štoviše, to se odnosi i na tehnološke platforme i na arhitekturu primijenjenih sustava koji se na njima temelje.

Ovdje je važno uspostaviti ravnotežu - i održavati prilično "zeleni" pristup resursima i pohranjenim informacijama. Inače, spremište možete vrlo brzo pretvoriti u polustrukturirano "smeće", što će, ako se može srediti, biti kroz dosta truda.
Da, imamo više mogućnosti, ali to ne znači da trebamo negirati sve prakse koje je vrijeme razvilo i provjeravalo, a koje su jasni kako i zašto koristiti, i „upuštati se u sve ozbiljno“ samo vođene maglovitim duh “inovacije”.
Održavati ravnotežu znači koristiti nove metode i pristupe gdje otvaraju nove mogućnosti, ali istovremeno koristiti stare provjerene za rješavanje hitnih problema koje nitko nije otkazao.
Što možemo učiniti kao programeri i dizajneri primijenjenih rješenja? Prije svega, upoznati i razumjeti tehnološke promjene platformi na kojima radimo, njihove mogućnosti, značajke i granice primjene.

Pogledajmo DBMS – kao najkritičniju i najvažniju tehnološku platformu za pohranu podataka.
Nedavno je došlo do jasnog pomjeranja relacijskih baza podataka, izvorno stvorenih kao "univerzalne", prema specijalizaciji. Već duže vrijeme vodeći dobavljači objavljuju razne opcije - za aplikacije različitih klasa (OLTP, DSS & DWH). Osim toga, postoje dodatne mogućnosti za rad s tekstom, geopodacima itd.

Ali stvar nije bila ograničena na to - počeli su se pojavljivati proizvodi koji su u početku bili usmjereni na određenu klasu zadataka - t.j. specijalizirani DBMS. Mogu ili ne moraju koristiti relacijski model. Važno je da su u početku "naoštreni" ne samo za pohranu i obradu "poslovnih informacija" općenito, već za određene zadatke.

Očigledno, centralizacija i specijalizacija su dva komplementarna trenda koji se povremeno zamjenjuju, osiguravajući razvoj i ravnotežu. Kao i evolucijski (postupni) postupni razvoj i kardinalne promjene. Tako je 90-ih Michael Stonebreaker bio jedan od autora Generation III Database Manifesta, koji je jasno zvučao ideju da svijetu ne treba još jedna revolucija u svijetu baza podataka. No, 10 godina kasnije objavljuje radove u kojima najavljuje preduvjete za početak nove ere u svijetu DBMS-a – upravo na temelju njihove specijalizacije.
On se usredotočuje na činjenicu da su rašireni univerzalni DBMS-ovi izgrađeni na arhitekturi „jedna veličina za sve“ koja ne uzima u obzir promjene hardverskih platformi ili podjelu aplikacija u klase za koje možete doći do boljeg rješenja od provedbu univerzalnih zahtjeva.
I počinje razvijati niz projekata u skladu s tom idejom. Jedan od njih je C-Store, stupni DBMS dizajniran u arhitekturi shared nothing (SN), izvorno kreiran posebno za sustave klasa pohrane podataka. Ovaj proizvod je dalje komercijaliziran kao HP Vertica.

Č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 u implementaciju, 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 ta 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.