Izdelava enotnega korporativnega podatkovnega skladišča. Izdelava modela podatkovnega skladišča na podlagi podatkovnega modela podjetja. Panožni podatkovni modeli

Zaitsev S.L., dr.

Ponavljajoče se skupine

Ponavljajoče se skupine so atributi, za katere ima lahko en primerek entitete več kot eno vrednost. Na primer, oseba ima lahko več kot eno spretnost. Če moramo glede na poslovne zahteve poznati raven spretnosti za vsakogar in ima vsaka oseba lahko samo dve veščini, lahko ustvarimo entiteto, prikazano na sl. 1.6. Tukaj je entiteta OSEBA z dvema atributoma za shranjevanje spretnosti in ravni spretnosti za vsakega.

riž. 1.6. Ta primer uporablja ponavljajoče se skupine.

Težava pri ponavljajočih se skupinah je v tem, da ne moremo natančno vedeti, koliko veščin bi lahko imela oseba. V resničnem življenju imajo nekateri ljudje eno spretnost, nekateri več, nekateri pa še nobene. Slika 1.7 prikazuje model, reduciran na prvo normalno obliko. Upoštevajte dodano ID spretnosti , ki vsakogar enolično definira SPREMNOST.

riž. 1.7. Model zmanjšan na prvo normalno obliko.

Eno dejstvo na enem mestu

Če je isti atribut prisoten v več kot eni entiteti in ni tuji ključ, se ta atribut šteje za odvečnega. Logični model ne sme vsebovati odvečnih podatkov.

Redundanca zahteva dodaten prostor, a čeprav je učinkovitost pomnilnika pomembna, je pravi problem drugje. Zajamčena sinhronizacija odvečnih podatkov je povezana z obremenitvami in vedno ste v nevarnosti, da bodo vrednosti v nasprotju.

V prejšnjem primeru SPREMNOST odvisno od ID osebe in od ID spretnosti. To pomeni, da ne boste imeli SPREMNOST dokler se ne pojavi OSEBA, imeti to veščino. Prav tako otežuje spreminjanje imena spretnosti. Treba je najti vsak vnos z imenom spretnosti in ga spremeniti za vsako osebo, ki je lastnik te veščine.

Slika 1.8 prikazuje model v drugi normalni obliki. Upoštevajte, da je bil subjekt dodan SPREMNOST, in atribut NASLOV spretnost prenesena na to entiteto. Raven spretnosti je ostala na križišču OSEBE in SPOSOBNOSTI.

riž. 1.8. V drugi normalni obliki se ponavljajoča skupina premakne v drugo entiteto. To zagotavlja prilagodljivost za dodajanje toliko spretnosti, kot je potrebno, in spreminjanje imena spretnosti ali opisa spretnosti na enem mestu.

Vsak atribut je odvisen od ključa

Vsak atribut entitete mora biti odvisen od primarnega ključa te entitete. V prejšnjem primeru Ime šole in Geografsko območje prisotno v tabeli OSEBA vendar ne opišite osebe. Če želite doseči tretjo normalno obliko, morate atribute premakniti v entiteto, kjer bodo odvisni od ključa. Slika 1.9. prikazuje model v tretji normalni obliki.

riž. 1.9. V tretji normalni obliki Ime šole in Geografska regija premaknjeni v entiteto, kjer so njihove vrednosti odvisne od ključa.

Razmerja veliko proti mnogim

Razmerje veliko proti mnogim odražajo realnost okolja. Upoštevajte, da je na sliki 1.9 razmerje veliko proti mnogim OSEBA in ŠOLA. Razmerje natančno odraža dejstvo, da OSEBA lahko študira v mnogih ŠOLE in v ŠOLA se lahko veliko nauči OSEBA. Da bi dosegli četrto normalno obliko, je ustvarjena asociativna entiteta, ki odpravlja razmerje monogie-to-many z ustvarjanjem ločenega vnosa za vsako edinstveno kombinacijo šole in osebe. Slika 1.10 prikazuje model v četrti normalni obliki.

riž. 1.10. V četrti normalni obliki je relacija monogie proti mnogim OSEBA in ŠOLA rešiti z uvedbo asociativne entitete, v kateri je za vsako edinstveno kombinacijo dodeljen ločen vnos ŠOLE in OSEBE.

Formalne definicije normalnih oblik

Naslednje definicije normalnih oblik se morda zdijo zastrašujoče. Pomislite nanje preprosto kot na formule za doseganje normalizacije. Normalne oblike temeljijo na relacijski algebri in jih je mogoče razlagati kot matematične transformacije. Čeprav ta knjiga ne zajema podrobne razprave o normalnih oblikah, se modelarji spodbujajo, da se poglobijo v to temo.

V dani relaciji R je atribut Y funkcionalno odvisen od atributa X. Simbolično, RX -> RY (bere se kot "RX funkcionalno definira RY"), če in samo če je vsaka vrednost X v R povezana z natanko eno vrednostjo Y v R ( kadarkoli). Atributa X in Y sta lahko sestavljena (Datum K.J. Introduction to Database Systems. 6. izdaja. Ed. Williams: 1999, 848 str.).

Relacija R je v prvi normalni obliki (1NF), če in samo če vse njene domene vsebujejo samo atomske vrednosti (Datum, ibid.).

Relacija R je v drugi normalni obliki (2NF), če in samo če je v 1NF in je vsak atribut, ki ni ključ, v celoti odvisen od primarnega ključa (Datum, ibid.).

Relacija R je v tretji normalni obliki (3NF), če in samo če je v 2NF in vsak atribut, ki ni ključ, ni prehodno odvisen od primarnega ključa (Datum, ibid.).

Relacija R je v Boyce-Codd normalni obliki (BCNF), če in samo če je vsaka determinanta kandidat za uporabo kot ključ.

OPOMBA Spodaj je kratka razlaga nekaterih okrajšav, uporabljenih v definicijah Date.

MVD (multi-valued dependency) - odvisnost z več vrednostmi. Uporablja se samo za entitete s tremi ali več atributi. V odvisnosti z več vrednostmi je vrednost atributa odvisna samo od dela primarnega ključa.

FD (funkcionalna odvisnost) - funkcionalna odvisnost. V funkcionalni odvisnosti je vrednost atributa odvisna od vrednosti drugega atributa, ki ni del primarnega ključa.

JD (pridruži se odvisnosti) - pridruži odvisnost. V odvisnosti pridružitve je primarni ključ nadrejene entitete sledljiv vsaj do tretje stopnje potomcev, hkrati pa ohrani možnost uporabe v izvirnem združitvi ključa.

Relacija je v četrti normalni obliki (4NF), če in samo če obstaja MVD v R, kot je A®®B. V tem primeru so vsi atributi R funkcionalno odvisni od A. Z drugimi besedami, v R obstajajo samo odvisnosti (FD ali MVD) v obliki K®X (tj. funkcionalna odvisnost atributa X od kandidata za uporabo kot ključ K). V skladu s tem R izpolnjuje zahteve 4NF, če je v skladu z BCNF in so vsi MVD dejansko FD (datum, ibid.).

Za peto normalno obliko relacija R izpolnjuje razmerje unije (JD)*(X, Y, …, Z), če in samo če je R enakovreden svojim projekcijam na X, Y,..., Z, kjer je X, Y, .., Z podmnožice niza atributov R.

Obstaja veliko drugih običajnih oblik za zapletene vrste podatkov in posebne situacije, ki so izven obsega naše razprave. Vsak navdušenec nad razvojem modelov bi rad raziskal druge normalne oblike.

Poslovni običajni obrazci

V svoji knjigi Clive Finklestein (Finklestein Cl. An Introduction to Information Engineering: From Strategic Planning to Information Systems. Reading, Massachusetts: Addison-Wesley, 1989) je uporabil drugačen pristop k normalizaciji. Opredeljuje običajne poslovne oblike v smislu zmanjšanja na te oblike. Mnogi oblikovalci modelov menijo, da je ta pristop bolj intuitiven in pragmatičen.

Prva poslovna normalna oblika (1BNF) preslika ponavljajoče se skupine v drugo entiteto. Ta entiteta dobi svoje ime in atribute primarnega (sestavljenega) ključa od prvotne entitete in njene ponavljajoče se skupine.

Druga poslovna normalna oblika (2BNF) preslika atribute, ki so delno odvisni od primarnega ključa, v drugo entiteto. Primarni (sestavljeni) ključ te entitete je primarni ključ entitete, v kateri se je prvotno nahajala, skupaj z dodatnimi ključi, od katerih je atribut v celoti odvisen.

Tretja poslovna normalna oblika (3BNF) premakne atribute, ki niso odvisni od primarnega ključa, v drugo entiteto, kjer so popolnoma odvisni od primarnega ključa te entitete.

Četrta poslovna normalna oblika (4BNF) preslika atribute, ki so odvisni od vrednosti primarnega ključa ali so neobvezni za sekundarno entiteto, kjer so v celoti odvisni od vrednosti primarnega ključa ali kjer morajo (obvezno) biti prisotni v tej entiteti .

Peta poslovna normalna oblika (5BNF) se pojavi kot strukturna entiteta, če obstaja rekurzivna ali druga odvisnost med primerki sekundarne entitete ali če obstaja rekurzivna odvisnost med primerki njene primarne entitete.

Dokončan logični podatkovni model

Izpolnjen logični model mora izpolnjevati zahteve tretje poslovne običajne oblike in vključevati vse entitete, atribute in relacije, potrebne za podporo podatkovnim zahtevam in poslovnim pravilom, povezanim s podatki.

Vse entitete morajo imeti imena, ki opisujejo vsebino in jasen, jedrnat, popoln opis ali definicijo. V eni od naslednjih publikacij bo obravnavan začetni sklop priporočil za pravilno oblikovanje imen in opisov subjektov.

Razmerja morajo vključevati glagolsko konstrukcijo, ki opisuje razmerje med entitetami, skupaj z značilnostmi, kot so množina, potreba po obstoju ali možnost neobstoja razmerja.

OPOMBA Množina razmerja opisuje največje število sekundarnih primerkov entitete, ki jih je mogoče povezati s primerkom prvotne entitete.Potreba po obstoju ozmožnost odsotnosti razmerje se uporablja za definiranje najmanjšega števila primerkov sekundarne entitete, ki se lahko poveže s primerkom prvotne entitete.

Fizični podatkovni model

Po izdelavi popolnega in ustreznega logičnega modela ste pripravljeni na odločitev o izbiri izvedbene platforme. Izbira platforme je odvisna od zahtev za uporabo podatkov in strateških načel arhitekture organizacije. Izbira platforme je zapleteno vprašanje, ki presega obseg te knjige.

V ERwinu je fizični model grafični prikaz dejanske baze podatkov. Fizična baza podatkov bo sestavljena iz tabel, stolpcev in razmerij. Fizični model je odvisen od platforme, izbrane za izvedbo, in zahtev glede uporabe podatkov. Fizični model za IMS se bo zelo razlikoval od istega modela za Sybase. Fizični model za poročila OLAP bo videti drugačen od modela za OLTP (spletna obdelava transakcij).

Modelar podatkov in skrbnik baze podatkov (DBA) uporabljata logični model, zahteve glede uporabe in strateška načela korporativne arhitekture za razvoj fizičnega podatkovnega modela. Fizični model lahko denormalizirate, da izboljšate zmogljivost, in ustvarite poglede, ki podpirajo zahteve glede uporabe. Naslednji razdelki podrobno opisujejo postopek denormalizacije in ustvarjanja pogleda.

Ta razdelek ponuja pregled postopka gradnje fizičnega modela, zbiranja zahtev za uporabo podatkov, definiranja komponent fizičnega modela in obratnega inženiringa. Ta vprašanja bodo podrobneje obravnavana v prihodnjih publikacijah.

Zbiranje zahtev za uporabo podatkov

Običajno zberete zahteve za uporabo podatkov že zgodaj med intervjuji in delovnimi sejami. Hkrati bi morale zahteve čim bolj natančno opredeliti uporabo podatkov s strani uporabnika. Površen odnos in vrzeli v fizičnem modelu lahko povzročijo nenačrtovane stroške in odložijo projekt. Zahteve za uporabo vključujejo:

Zahteve za dostop in zmogljivost

Volumetrične značilnosti (ocena količine podatkov, ki jih je treba shraniti), ki omogočajo skrbniku, da predstavi fizični obseg baze podatkov

Ocena števila uporabnikov, ki morajo hkrati dostopati do podatkov, kar vam pomaga oblikovati svojo bazo podatkov za sprejemljivo raven zmogljivosti

Povzetek, povzetek in drugi izračunani ali izpeljani podatki, ki se lahko štejejo za kandidate za shranjevanje v trajnih podatkovnih strukturah

Zahteve za generiranje poročil in standardnih poizvedb za pomoč skrbniku baze podatkov pri izdelavi indeksov

Pogledi (trajni ali virtualni), ki bodo uporabniku pomagali pri izvajanju operacij združevanja ali filtriranja podatkov.

Poleg predsednika, sekretarja in uporabnikov mora seja zahtev glede uporabe vključevati modelarja, skrbnika baze podatkov in arhitekta baze podatkov. Treba je razpravljati o zahtevah uporabnikov za pretekle podatke. Čas, v katerem so podatki shranjeni, pomembno vpliva na velikost baze podatkov. Pogosto so starejši podatki shranjeni v zbirni obliki, atomski podatki pa se arhivirajo ali izbrišejo.

Uporabniki naj v sejo prinesejo vzorčne poizvedbe in poročila. Poročila morajo biti strogo opredeljena in morajo vključevati atomske vrednosti, ki se uporabljajo za vsa polja povzetka in povzetka.

Komponente fizičnega podatkovnega modela

Komponente fizičnega podatkovnega modela so tabele, stolpci in relacije. Entitete v logičnem modelu bodo verjetno postale tabele v fizičnem modelu. Logični atributi bodo postali stolpci. Logični odnosi bodo postali omejitve integritete odnosov. Nekaterih logičnih razmerij ni mogoče implementirati v fizično bazo podatkov.

povratni inženiring

Ko logični model ni na voljo, je potrebno ponovno ustvariti model iz obstoječe baze podatkov. Pri ERwinu se ta proces imenuje obratni inženiring. Povratni inženiring je mogoče izvesti na več načinov. Modelar lahko razišče podatkovne strukture v bazi podatkov in ponovno ustvari tabele v okolju vizualnega modeliranja. Jezik definicije podatkov (DDL) lahko uvozite v orodje, ki podpira obratni inženiring (npr. Erwin). Napredna orodja, kot je ERwin, vključujejo funkcije, ki zagotavljajo komunikacijo ODBC z obstoječo bazo podatkov za ustvarjanje modela z neposrednim branjem podatkovnih struktur. Povratni inženiring z uporabo ERwin bo podrobno obravnavan v prihodnji publikaciji.

Uporaba funkcionalnih meja podjetja

Pri gradnji logičnega modela je pomembno, da modelar zagotovi, da se novi model ujema z modelom podjetja. Uporaba funkcionalnih meja podjetja pomeni modeliranje podatkov v terminih, ki se uporabljajo v korporaciji. Način uporabe podatkov v podjetju se spreminja hitreje kot podatki sami. V vsakem logičnem modelu morajo biti podatki predstavljeni celostno, ne glede na poslovno domeno, ki jo podpira. Entiteti, atributi in odnosi bi morali definirati poslovna pravila na ravni podjetja.

OPOMBA Nekateri moji kolegi označujejo te korporativne funkcionalne meje kot modeliranje v resničnem svetu. Modeliranje v resničnem svetu spodbuja modelarja, da si ogleda informacije v smislu odnosov in odnosov v resničnem življenju.

Uporaba korporativnih funkcionalnih meja za pravilno izdelan podatkovni model zagotavlja okvir za podporo informacijskim potrebam poljubnega števila procesov in aplikacij, kar podjetju omogoča učinkovitejše izkoriščanje enega svojih najbolj dragocenih sredstev, informacij.

Kaj je podatkovni model podjetja?

Podatkovni model podjetja (EDM) vsebuje entitete, atribute in odnose, ki predstavljajo informacijske potrebe korporacije. EDM je običajno razdeljen na tematska področja, ki predstavljajo skupine subjektov, povezanih s podporo specifičnim poslovnim potrebam. Nekatera predmetna področja lahko zajemajo posebne poslovne funkcije, kot je upravljanje pogodb, druga lahko združujejo subjekte, ki opisujejo izdelke ali storitve.

Vsak logični model mora ustrezati obstoječi domeni podatkovnega modela podjetja. Če logični model ne izpolnjuje te zahteve, mu je treba dodati model, ki definira predmetno področje. Ta primerjava zagotavlja, da je korporativni model izboljšan ali prilagojen in da so vsa prizadevanja za logično modeliranje usklajena znotraj korporacije.

EDM vključuje tudi posebne entitete, ki definirajo obseg vrednosti za ključne atribute. Ti subjekti nimajo staršev in so opredeljeni kot neodvisni. Neodvisni subjekti se pogosto uporabljajo za ohranjanje integritete odnosov. Te entitete so identificirane z več različnimi imeni, kot so kodne tabele, tabele povezav, tabele tipov ali klasifikacijske tabele. Uporabili bomo izraz "poslovni objekt podjetja". Poslovni objekt podjetja je entiteta, ki vsebuje niz vrednosti atributov, ki so neodvisni od katere koli druge entitete. Podjetniške poslovne objekte znotraj korporacije je treba uporabljati dosledno.

Izgradnja podatkovnega modela podjetja s skaliranjem

Obstajajo organizacije, kjer je bil korporativni model od začetka do konca zgrajen kot rezultat enega samega usklajenega prizadevanja. Po drugi strani pa večina organizacij zgradi dokaj popolne modele podjetij z nadgradnjo.

Rast pomeni graditi nekaj, plast za plastjo, tako kot ostriga raste biser. Vsak ustvarjen podatkovni model zagotavlja vhodne podatke za oblikovanje EDM. Izgradnja EDM na ta način zahteva dodatne korake modeliranja za dodajanje novih podatkovnih struktur in domen ali razširitev obstoječih podatkovnih struktur. To omogoča izgradnjo podatkovnega modela podjetja z nadgradnjo, iterativnim dodajanjem ravni podrobnosti in izpopolnjevanja.

Koncept metodologije modeliranja

Obstaja več metodologij za vizualno modeliranje podatkov. ERwin podpira dva:

IDEF1X (Integracijska definicija za informacijsko modeliranje - integriran opis informacijskih modelov).

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

IDEF1X je dobra metodologija in njen zapis se pogosto uporablja

Integriran opis informacijskih modelov

IDEF1X je visoko strukturirana metodologija modeliranja podatkov, ki razširja metodologijo IDEF1, sprejeto kot standard FIPS (Zvezni standardi za obdelavo informacij). IDEF1X uporablja visoko strukturiran nabor tipov modelirnih konstrukcij in ima za posledico podatkovni model, ki zahteva razumevanje fizične narave podatkov, preden so te informacije lahko na voljo.

Toga struktura IDEF1X prisili modelarja, da subjektom dodeli lastnosti, ki morda ne ustrezajo realnosti sveta okoli njih. IDEF1X na primer zahteva, da so vsi podtipi entitet izključni. To vodi v dejstvo, da oseba ne more biti hkrati stranka in zaposleni. Medtem ko nam prava praksa govori drugače.

Informacijski inženiring

Clive Finklestein se pogosto omenja kot oče informacijskega inženiringa, čeprav je James Martin z njim delil podobne koncepte (Martin, James. Managing the Database Environment. Upper Saddle River, New Jersey: Prentice Hall, 1983.). Informacijski inženiring uporablja poslovno usmerjen pristop za upravljanje informacij in uporablja drugačno notacijo za predstavitev poslovnih pravil. IE služi kot razširitev in razvoj zapisa in osnovnih konceptov metodologije ER, ki jo je predlagal Peter Chen.

IE zagotavlja infrastrukturo za podporo zahtevam po informacijah z integracijo korporativnega strateškega načrtovanja z informacijskimi sistemi, ki se razvijajo. Takšna integracija omogoča tesnejšo povezavo upravljanja informacijskih virov z dolgoročnimi strateškimi obeti korporacije. Ta pristop, ki temelji na poslu, pripelje mnoge oblikovalce modelov, da izberejo IE namesto drugih metodologij, ki se osredotočajo predvsem na reševanje takojšnjih razvojnih problemov.

IE zagotavlja potek dela, ki vodi korporacijo do prepoznavanja vseh svojih informacij, ki jih potrebuje za zbiranje in upravljanje podatkov ter ugotavljanje razmerij med informacijskimi objekti. Posledično so zahteve po informacijah artikulirane na podlagi upravljavskih direktiv in jih je mogoče neposredno prevesti v informacijski sistem upravljanja, ki bo podpiral potrebe po strateških informacijah.

Zaključek

Razumevanje uporabe orodja za modeliranje podatkov, kot je ERwin, je le del problema. Poleg tega morate razumeti, kdaj se izvajajo naloge modeliranja podatkov in kako se zbirajo zahteve po informacijah in poslovna pravila, da bodo predstavljena v podatkovnem modelu. Vodenje delovnih sej zagotavlja najugodnejše pogoje za zbiranje informacijskih zahtev v okolju, ki vključuje strokovnjake s področja, uporabnike in strokovnjake za informacijsko tehnologijo.

Izgradnja dobrega podatkovnega modela zahteva analizo in raziskavo informacijskih zahtev in poslovnih pravil, zbranih med delovnimi sestanki in intervjuji. Nastali podatkovni model je treba po možnosti primerjati z modelom podjetja, da zagotovite, da ni v nasprotju z obstoječimi objektnimi modeli in vključuje vse zahtevane predmete.

Podatkovni model je sestavljen iz logičnih in fizičnih modelov, ki predstavljajo informacijske zahteve in poslovna pravila. Logični model je treba reducirati na tretjo normalno obliko. Tretja normalna oblika omejuje, dodaja, posodablja in odstranjuje anomalije podatkovne strukture, da podpira načelo "eno dejstvo, eno mesto". Zbrane zahteve po informacijah in poslovna pravila je treba analizirati in raziskati. Treba jih je primerjati z modelom podjetja, da zagotovimo, da niso v nasprotju z obstoječimi objektnimi modeli in da vključujejo vse zahtevane predmete.

V ERwin podatkovni model vključuje tako logične kot fizične modele. ERwin izvaja pristop ER in vam omogoča ustvarjanje predmetov logičnega in fizičnega modela, ki predstavljajo zahteve po informacijah in poslovna pravila. Objekti logičnega modela vključujejo entitete, atribute in relacije. Objekti fizičnega modela vključujejo tabele, stolpce in omejitve celovitosti odnosov.

V eni od naslednjih publikacij bodo obravnavana vprašanja identifikacije entitet, določanja tipov entitet, izbire imen in opisov entitet ter nekaj trikov, s katerimi se izognemo najpogostejšim napakam pri modeliranju, povezanim z uporabo entitet.

Entitete morajo imeti celoten nabor atributov, tako da lahko vsako dejstvo o vsaki entiteti predstavimo z njenimi atributi. Vsak atribut mora imeti ime, ki odraža njegove vrednosti, boolov podatkovni tip in jasen, kratek, popoln opis ali definicijo. V eni od naslednjih publikacij bomo obravnavali začetni niz priporočil za pravilno oblikovanje imen in opisov atributov. Razmerja morajo vključevati glagolsko konstrukcijo, ki opisuje razmerje med entitetami, skupaj z značilnostmi, kot so množina, potreba po obstoju ali možnost neobstoja razmerja.

OPOMBA Množina razmerja opisuje največje število sekundarnih primerkov entitete, ki jih je mogoče povezati s primerkom prvotne entitete.Nujnost obstoja ali možnost odsotnosti razmerje se uporablja za določitev najmanjšega števila primerkov sekundarne entitete, ki se lahko poveže s primerkom izvirne

Če želite prodati, morate razumeti, kaj prodajate.

Opredelimo terminologijo in pojme. ( Podatkovno skladišče) ni sistem ključnih kazalnikov uspešnosti (KPI, KPI), to ni velika baza podatkov, to ni analitična Orodje OLAP, to ni inteligenten sistem, ki vam omogoča ekstrahiranje novih podatkov in pridobivanje statističnih odvisnosti, to ni sistem enega samega referenčnega podatka - to ni podatkovno skladišče, če o tem govorimo v okviru posamezne postavke.

Podjetniško skladišče podatkov – to je posebej organiziran podatkovni niz podjetja (organizacije), obdelan in shranjen v enem samem strojno-programskem kompleksu, ki omogoča hiter dostop do operativnih in zgodovinskih informacij, večdimenzionalno analizo podatkov (KPI za različne meritve), pridobivanje napovedi in statistike v okvir dogovorjenih regulativnih referenčnih informacij (NSI).

Potencialne stranke za korporativno podatkovno skladišče in kaj dobijo?

Kako prepoznati potencialne poslovne stranke, ki potrebujejo podatkovno skladišče?

Najprej naj bi se v vsakodnevnih dejavnostih podjetja pojavilo veliko informacij. To so lahko telefonski klici, finančne transakcije, pritožbe/recenzije strank, zahteve za pošiljanje strank, informacije iz vohunskih satelitov itd. Načeloma karkoli, glavna stvar je, da je veliko podatkov.
Potencialna stranka bi morala imeti željo videti in analizirati te informacije. Hkrati bi moralo biti obdobje analize precej obsežno - od dneva ali celo ure, do analize več let.
Odjemalec mora imeti normalno delujočo infrastrukturo (strežniki ne smejo biti povezani z zvitim parom ali USB vhodom). Če naročnik nima infrastrukture, jo mora prodati.

Kakšne koristi ima stranka od uvedbe podatkovnega skladišča podjetja?

Pojavi se enoten informacijski sistem za shranjevanje podatkov o podjetju, v katerem se uporablja enotna referenčna informacija.
Obstaja priložnost za izvedbo celovite analize poslovanja. Na primer: katere stranke so najbolj donosne in donosne; kakšna storitev, po katerih strankah je največ povpraševanja, kakšne škode so najpogostejše in v katerih regijah itd.
Možno je izvesti analizo z uporabo zgodovinskih podatkov. Pogosto operativni sistemi (avtomatizirajo dnevne poslovne procese) tega ne omogočajo, preprosto nimajo dovolj prostora za shranjevanje zgodovine in moči za izvajanje analize.
Možno je povezati in analizirati informacije, ki so bile prej shranjene v različnih informacijskih sistemih. Podatki o prometu različnih podružnic so na primer shranjeni v sistemih za obračunavanje različnih razvijalcev. Po implementaciji podatkovnega skladišča jih je mogoče analizirati skupaj, v enem samem poročilu.
Postane mogoče analizirati in križati različne vrste podatkov. Na primer denar in promet, število osebja in število zavrnitev ali zahtevkov itd.
Obstaja osnova za boljši izračun stroškov storitev - na podlagi informacij iz korporativnega podatkovnega skladišča je mogoče pridobiti ustreznejše podatke za naravne distribucijske baze.

Kaj je korporativno podatkovno skladišče

Katere komponente s tehničnega vidika gradi korporativno podatkovno skladišče?

Komponente korporativno podatkovno skladišče podjetja

Stranka ima vedno operacijske sisteme - viri podatkov za korporativno podatkovno skladišče. To so na primer računovodstvo, obračunavanje, bančništvo itd. sistemi.
Uporaba ETL aplikacija(programska oprema, ki omogoča ekstrahiranje, preoblikovanje in nalaganje podatkov), podatki iz izvornih sistemov vstopajo v bazo podatkovnega skladišča. Kot orodje ETL je mogoče uporabiti naslednje: Informatica Power Center, IBM DataStage, Oracle Data Integrator, Oracle WareHouse Builder. Obstajajo tudi izdelki drugih prodajalcev, vendar na ruskem trgu skoraj niso zastopani.
samega sebe bazo podatkov korporativna shramba po svoji strukturi ni abstraktna (nabor tabel, polj v njih in relacije med tabelami), ampak je ustvarjena na podlagi podatkovni modeli. Velika večina baz podatkov uporablja Oracle ali Teradata.
Podatkovni model je opis vseh entitet, objektov baze podatkov korporativnega podatkovnega skladišča in vključuje: konceptualni podatkovni model, logični podatkovni model in fizični model baze podatkov . Na ravni konceptualnega modela so definirane entitete in odnosi med njimi. Na ravni logičnega modela so subjekti razdeljeni na poslovna področja, podroben in popoln opis ter predpisani odnosi. Pri razvoju fizičnega modela baze podatkov se določi celotna struktura baze podatkov – od tabel in polj v njih, do particij in indeksov. Podatkovni modeliIBM, SAP in Oracle danes oskrbujejo trg, vendar nakup podatkovnega modela ne pomeni avtomatske izgradnje prave trgovine za podjetja.Podatkovni model To ni pakiran izdelek. Treba ga je prilagoditi, da bo ustrezal potrebam določene stranke.
Nadalje, že z uporabo podatkov iz korporativnega podatkovnega skladišča, področja analize, poročanja in podatkovne trgovine. Nato lahko uporabniki samostojno oblikujejo potrebno poročanje in izvajajo multivariatno analizo. Business Objects, Oracle Discoverer, IBM AlphaBlocks in drugi izdelki se uporabljajo predvsem kot orodja za analizo.

Kako izgledajo komponente podjetniškega podatkovnega skladišča (podatkovni model, ETL procesi, podatkovni trgovi)

Navedimo nazorne primere podatkovnega modela, implementacije ETL procesa, oblike podpore za enotne referenčne podatke, podatkovnih trgov.

Logični modelpodatkov.
Opredeljuje entitete, njihove atribute in odnose med njimi.

ETL postopekodprava dvojnikov v izvornih podatkih

Obrazec za vnos podatkov za oblikovanje enotnega imenika

podatkovni trgv obliki tabelarnega poročila

podatkovni trgz grafiko in barvami
izpis podatkov v skladu z danim pogojem

podatkovni trgz urnikom

Sorodna programska in strojna oprema

Najprej se poleg samih storitev za razvoj korporativnega podatkovnega skladišča prodajajo tudi licence tako za strežniško programsko opremo (OS, baze podatkov, aplikacijski strežnik itd.) kot za odjemalska mesta (protivirusna zaščita in varnostna orodja) .

Možno je, da obstoječi odjemalčevi strežniki niso zasnovani za uvajanje podatkovnega skladišča. Zanje je treba postaviti zahteve in potencialni stranki prodati strojno opremo.

Poleg samih strežnikov so za shranjevanje znatne količine informacij potrebni tudi diskovni nizi.

Ker namerava zgraditi korporativno podatkovno skladišče, potencialna stranka ne razume vedno, kako bo zagotovila redundanco. Obstoječi sistemi za varnostno kopiranje odjemalca pogosto ne morejo hkrati povezati podatkovnih količin od 20-30 TB na varnostno kopijo.

Strokovnjaki in uporabniki stranke praviloma potrebujejo tečaje usposabljanja.

Kovtun M.V. avgust 2010

Pošljite svoje dobro delo v bazo znanja je preprosto. Uporabite spodnji obrazec

Študentje, podiplomski študenti, mladi znanstveniki, ki uporabljajo bazo znanja pri študiju in delu, vam bodo zelo hvaležni.

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

1. Relacijski podatkovni model

1.1 Relacijski podatkovni model. Osnovne definicije
1.2 Operacije na odnosih

2. Korporativni informacijski sistemi
Bibliografija

1. Relacijski podatkovni model

1.1 Relacijski podatkovni model. Osnovne definicije

V matematičnih disciplinah pojem "tabela" ustreza konceptu "relacije" (relacije). Tabela odraža predmet iz resničnega sveta – entiteto, vsaka njena vrstica pa odraža določen primer entitete. Vsak stolpec ima edinstveno ime za tabelo. Nizi nimajo imen, njihov vrstni red ni definiran in njihovo število ni logično omejeno. Ena od glavnih prednosti relacijskega podatkovnega modela je homogenost (vsaka vrstica tabele ima en format). Uporabnik se sam odloči, ali so ustrezne entitete homogene. To rešuje problem primernosti modela.

Osnovni koncepti:

* Relacija je dvodimenzionalna tabela, ki vsebuje nekaj podatkov.

* Entiteta - predmet katere koli narave, podatki o katerem so shranjeni v bazi podatkov. Atributi - lastnosti, ki označujejo entiteto (stolpce).

* Stopnja relacije - število stolpcev.

* Shema razmerja - seznam imen atributov, na primer ZAPOSLENI (št., polno ime, leto rojstva, položaj, oddelek).

* Domena - niz vrednosti atributov relacije (tip podatkov).

* Tuple - vrstica tabele.

* Kardinalnost (moč) - število vrstic v tabeli.

* Primarni ključ je atribut, ki enolično identificira vrstice v odnosu. Primarni ključ z več atributi se imenuje sestavljeni ključ. Primarni ključ ne more biti popolnoma ali delno prazen (imati ničelno vrednost). Ključi, ki se lahko uporabljajo kot primarni ključi, se imenujejo kandidatni ali nadomestni ključi.

* Tuji ključ je atribut(i) ene tabele, ki lahko služi kot primarni ključ druge tabele. Je sklic na primarni ključ druge tabele.

Normalizacija je proces, katerega cilj je zmanjšati odvečnost informacij v bazi podatkov. Poleg samih podatkov je v bazi podatkov mogoče normalizirati tudi različna imena, imena objektov in izrazov.

Nenormalizirana baza podatkov vsebuje informacije v eni ali več različnih tabelah; to ustvarja vtis, da vključitev podatkov v določeno tabelo ni posledica kakršnih koli očitnih razlogov. To stanje lahko negativno vpliva na varnost podatkov, upravljanje prostora na disku, hitrost poizvedb, učinkovitost posodabljanja baze podatkov in, kar je morda najpomembnejše, celovitost shranjenih informacij. Baza podatkov pred normalizacijo je struktura, ki še ni bila logično razčlenjena na manjše tabele, ki jih je bolje upravljati.

Normalna oblika je neke vrste indikator ravni ali globine normalizacije baze podatkov. Raven normalizacije baze podatkov ustreza običajni obliki, v kateri je.

1.2 Operacije na odnosih

Za pretvorbo tabele v prvo normalno obliko (1NF) je treba upoštevati dve pravili:

1. Atomičnost ali nedeljivost. Vsak stolpec mora vsebovati eno nedeljivo vrednost.

2. Tabela ne sme vsebovati ponavljajočih se stolpcev ali podatkovnih skupin.

Na primer, če tabela vsebuje polni naslov osebe (ulica, mesto, poštna številka) v enem polju, ne bo v skladu s pravili 1NF, saj bo v enem stolpcu vsebovala različne vrednosti, ki bodo kršitev pravila atomicnosti. Če pa baza vsebuje podatke o filmih in ima stolpce igralec1, igralec2, igralec3, tudi ne bo izpolnjevala pravil, saj se bodo podatki ponavljali.

Normalizacija se mora začeti s preverjanjem združljivosti strukture baze podatkov z 1NF. Vse stolpce, ki niso atomski, je treba razčleniti na njihove sestavne stolpce. Če ima tabela podvojene stolpce, jim je treba dodeliti ločeno tabelo.

Za pretvorbo tabele v prvo normalno obliko:

* Poiščite vsa polja, ki vsebujejo več informacij.

* Tiste podatke, ki jih je mogoče razčleniti na sestavne dele, je treba umestiti v ločena polja.

* Premaknite podvojene podatke v ločeno tabelo.

* Preverite, ali vse tabele ustrezajo pogojem prve normalne oblike.

Za pretvorbo tabel v drugo normalno obliko (2NF), morajo nastale tabele že biti v 1NF. Normalizacijo je treba izvesti po vrstnem redu.

Zdaj, v drugi normalni obliki, mora biti izpolnjen pogoj - vsak stolpec, ki ni ključ (vključno s tujimi), mora biti odvisen od primarnega ključa. Običajno je te stolpce, ki imajo vrednosti, ki niso odvisne od ključa, enostavno prepoznati. Če podatki v stolpcu niso povezani s ključem, ki opisuje vrstico, jih je treba ločiti v svojo ločeno tabelo. Primarni ključ je treba vrniti v staro tabelo.

Za pretvorbo osnove v drugo normalno obliko:

* Identificirajte vse stolpce, ki niso neposredno odvisni od primarnega ključa te tabele.

* Ustvarite potrebna polja v tabelah uporabnikov in forumov, izberite iz obstoječih polj ali ustvarite primarne ključe iz novih.

* Vsaka tabela potrebuje svoj primarni ključ

* Ustvarite tuje ključe in označite njihove odnose med tabelami. Zadnji korak normalizacije na 2NF bo dodelitev tujih ključev za povezavo s povezanimi tabelami. Primarni ključ ene tabele mora biti tuji ključ v drugi.

Namigi:

Drug način za izdelavo sheme 2NF je, da si ogledate odnose med tabelami. Idealna možnost je ustvarjanje vseh odnosov ena proti več. Odnose veliko proti mnogim je treba prestrukturirati.

Pravilno normalizirana tabela nikoli ne bo imela podvojenih vrstic (dve ali več vrstic, katerih vrednosti niso ključi in vsebujejo iste podatke).

Baza podatkov bo v tretji normalni obliki, če je prestavljena v drugo normalno obliko in je vsak stolpec, ki ni ključ, neodvisen drug od drugega. Če se postopek normalizacije do te točke pravilno izvaja, morda ne bo težav z znižanjem na 3NF. Zavedati se morate, da je 3NF kršen, če sprememba vrednosti v enem stolpcu zahteva spremembo v drugem stolpcu.

Za pretvorbo osnove v tretjo normalno obliko:

* Ugotovite, v katerih poljih katerih tabel je soodvisnost, t.j. polja, ki so bolj odvisna drug od drugega kot od serije kot celote.

* Ustvarite ustrezne tabele. Če je v 1. koraku problematičen stolpec, zanj ustvarite ločene tabele.

* Ustvarite ali dodelite primarne ključe. Vsaka tabela mora imeti primarni ključ.

* Ustvarite potrebne tuje ključe, ki tvorijo katero koli relacijo.

V četrti normalni obliki je dodatno pravilo izključitev odvisnosti z več vrednostmi. Z drugimi besedami, vse vrstice tabele morajo biti neodvisne ena od druge. Prisotnost neke vrstice X ne bi smela pomeniti, da je tudi vrstica Y nekje v tej tabeli.

2. Korporativni informacijski sistemi

relacijski model podatkovni sistem

Sistem (iz grščine systema - celota, povezava, sestavljena iz delov) je niz elementov, ki medsebojno delujejo in tvorijo določeno celovitost, enotnost. Tukaj je nekaj konceptov, ki se pogosto uporabljajo za karakterizacijo sistema.

1. Element sistema -- del sistema, ki ima določen funkcionalni namen. Kompleksni elementi sistemov, ki so sestavljeni iz enostavnejših medsebojno povezanih elementov, se pogosto imenujejo podsistemi.

2. Organizacija sistema - notranji red, doslednost v interakciji elementov sistema, ki se kaže zlasti v omejevanju raznolikosti stanj elementov znotraj sistema.

3. Struktura sistema – sestava, vrstni red in principi interakcije elementov sistema, ki določajo osnovne lastnosti sistema. Če so posamezni elementi sistema ločeni po različnih ravneh in so notranje povezave med elementi organizirane le od višjih do nižjih ravni in obratno, potem govorijo o hierarhični strukturi sistema. Čisto hierarhične strukture so praktično redke, zato, če nekoliko razširimo ta koncept, se pod hierarhično strukturo običajno razumejo takšne strukture, pri katerih so med drugimi povezavami izjemnega pomena hierarhične povezave.

4. Arhitektura sistema – niz sistemskih lastnosti, ki so bistvene za uporabnika.

5. Celovitost sistema - temeljna nezvodljivost lastnosti sistema na vsoto lastnosti njegovih posameznih elementov (nastanek lastnosti) in hkrati odvisnost lastnosti vsakega elementa od njegove mesto in delovanje v sistemu.

Informacijski sistem je med seboj povezan sklop sredstev, metod in osebja, ki se uporablja za shranjevanje, obdelavo in izdajanje informacij za doseganje cilja."

Zvezni zakon "o informacijah, informatizaciji in zaščiti informacij" določa naslednjo definicijo:

"Informacijski sistem je organizacijsko urejen niz dokumentov (niz dokumentov) in informacijskih tehnologij, vključno z uporabo računalniške tehnologije in komunikacijskih orodij, ki izvajajo informacijske procese"

Razvrstitev po lestvici

Po obsegu so informacijski sistemi razdeljeni v naslednje skupine:

* samski;

* skupina;

* podjetja.

Korporativni informacijski sistem je razširljiv sistem, zasnovan za kompleksno avtomatizacijo vseh vrst gospodarskih dejavnosti velikih in srednje velikih podjetij, vključno s korporacijami, ki jih sestavlja skupina podjetij, ki zahtevajo enotno upravljanje.

Informacijski sistem podjetja lahko štejemo za sistem, ki avtomatizira več kot 80 % oddelkov podjetja.

V zadnjem času se v številnih publikacijah, posvečenih uporabi informacijskih tehnologij pri upravljanju gospodarskih objektov, pogosto uporablja izraz "korporativni informacijski sistemi", ki se nanaša na dejanske avtomatizirane informacijske sisteme gospodarskih objektov.

Avtomatizirani informacijski sistem (AIS) je kombinacija različnih vrst podpore, pa tudi strokovnjakov, zasnovanih za avtomatizacijo obdelave računovodskih in analitičnih informacij. Vrste podpore so glede na sestavo praviloma homogene za različne sisteme, kar omogoča izvajanje načela združljivosti sistemov pri njihovem delovanju. V procesu preučevanja AIS kot kompleksnega sistema je treba izpostaviti posamezne dele in elemente ter upoštevati značilnosti njihove uporabe v fazah nastanka in delovanja.

Podjetniški informacijski sistemi so evolucija sistemov za delovne skupine, osredotočeni so na velika podjetja in lahko podpirajo geografsko razpršena vozlišča ali omrežja. V bistvu imajo hierarhično strukturo več ravni. Za takšne sisteme je značilna arhitektura odjemalec-strežnik s specializacijo strežnikov ali večnivojska arhitektura. Pri razvoju takšnih sistemov se lahko uporabljajo enaki strežniki baz podatkov kot pri razvoju skupinskih informacijskih sistemov. Vendar pa so v velikih informacijskih sistemih najbolj razširjeni strežniki Oracle, DB2 in Microsoft SQL Server.

Za skupinske in korporativne sisteme so zahteve po zanesljivosti delovanja in varnosti podatkov bistveno povečane. Te lastnosti so zagotovljene z ohranjanjem celovitosti podatkov, povezav in transakcij v strežnikih baz podatkov.

Razvrstitev po obsegu

Glede na obseg informacijskih sistemov so običajno razdeljeni v štiri skupine:

* sistemi za obdelavo transakcij;

* sistemi odločanja;

* informacijski in referenčni sistemi;

* pisarniški informacijski sistemi.

Bibliografija

1. Agalcov, V.P. Zbirka podatkov. V 2 zvezkih V. 2. Porazdeljene in oddaljene baze podatkov: Učbenik / V.P. Agalcov. - M.: ID FORUM, SIC INFRA-M, 2013.

2. Golitsyna, O.L. Baze podatkov: Učbenik / O.L. Golitsyna, N.V. Maksimov, I.I. Popov. - M.: Forum, 2012.

3. Karpova, I.P. Baze podatkov: Učbenik / I.P. Karpov. - Sankt Peterburg: Peter, 2013.

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

5. Pirogov, V.Yu. Informacijski sistemi in baze podatkov: organizacija in oblikovanje: Učbenik / V.Yu. Pirogov. - Sankt Peterburg: BHV-Peterburg, 2009.

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

7. A.E. Satunina, L.A. Sysoev. Projektno vodenje korporativnega informacijskega sistema podjetja. - M.: Finance in statistika, Infra-M, 2009.

Gostuje na Allbest.ru

...

Podobni dokumenti

Bistvo in značilnosti tipov podatkovnih modelov: hierarhični, mrežni in relacijski. Osnovni koncepti relacijskega podatkovnega modela. Atributi, shema odnosov baze podatkov. Pogoji celovitosti podatkov. Odnosi med tabelami. Splošne ideje o podatkovnem modelu.

seminarska naloga, dodana 29.01.2011

Korporativni informacijski sistemi in baze podatkov, njihova uporaba za izboljšanje in odpravljanje napak poslovanja. Klasifikacija korporativnih informacijskih sistemov. Informacijski sistemi razreda OLTP. Operativno analitična obdelava.

seminarska naloga, dodana 19.01.2011

Podatkovne baze z dvodimenzionalnimi datotekami in sistemi za upravljanje relacijskih baz podatkov (DBMS). Ustvarjanje baze podatkov in obdelava poizvedb do njih s pomočjo DBMS. Osnovne vrste baz podatkov. Osnovni koncepti relacijskih baz podatkov. Temeljne lastnosti odnosov.

povzetek, dodan 20. 12. 2010

Koncept sistema baze podatkov. Relacijski model in njegove značilnosti. Integriteta v relacijskem modelu. Relacijska algebra. Težave pri oblikovanju baze podatkov. normalne oblike odnosa. Oblikovanje baze podatkov z metodo entiteta-razmerje. ER diagrami. jezik SQL.

tečaj predavanj, dodano 03.10.2008

Posebna logična struktura podatkov, ki je shranjena v bazi podatkov. Osnovni podatkovni modeli. Elementi relacijskega podatkovnega modela. Primer uporabe tujih ključev. Glavne zahteve za relacije relacijskega podatkovnega modela.

predstavitev, dodano 14.10.2013

Baze podatkov in njihova uporaba v računalništvo. Značilnosti in osnovna strukturna enota omrežnega podatkovnega modela. Hierarhični model, predmeti domene. Relacijski model, njegova vidnost, predstavitev podatkov v obliki tabele.

povzetek, dodan 19.12.2011

Vrste in funkcije sistema za upravljanje baz podatkov Microsoft Access. Hierarhični, omrežni, relacijski model opisa baze podatkov. Osnovni pojmi tabele baze podatkov. Značilnosti ustvarjanja objektov baze podatkov, osnovnih obrazcev. Dostop do interneta v Accessu.

kontrolno delo, dodano 08.01.2011

Sodobni sistemi za upravljanje baz podatkov (DBMS). Analiza hierarhičnega podatkovnega modela. Relacijski podatkovni model. Postrelacijski podatkovni model kot razširjen relacijski model, ki odstranjuje omejitev nedeljivosti podatkov, shranjenih v zapisih tabele.

znanstveno delo, dodano 08.06.2010

Podatkovni modeli pri upravljanju baz podatkov. Konceptualni podatkovni modeli. Vloga baz podatkov v informacijskih sistemih. Relacijski podatkovni model. Opredelitev predmetnega področja. Izdelava modela baze podatkov za informacijski sistem "Hišni ljubljenčki".

seminarska naloga, dodana 19.04.2011

Informacijski model v Accessu kot nekakšen poenostavljen nadomestek za resnični objekt ali sistem. Osnovne strukture, ki opredeljujejo organizacijo podatkov in odnose med njimi; relacijski tip organizacije podatkov. Primer baze podatkov v obdavčitvi.

Zaitsev S.L., dr.

Ponavljajoče se skupine

riž. 1.6. Ta primer uporablja ponavljajoče se skupine.

riž. 1.7. Model zmanjšan na prvo normalno obliko.

Eno dejstvo na enem mestu

Če je isti atribut prisoten v več kot eni entiteti in ni tuji ključ, se ta atribut šteje za odvečnega. Logični model ne sme vsebovati odvečnih podatkov.

Vsak atribut je odvisen od ključa

riž. 1.9. V tretji normalni obliki Ime šole in Geografska regija premaknjeni v entiteto, kjer so njihove vrednosti odvisne od ključa.

Razmerja veliko proti mnogim

Formalne definicije normalnih oblik

Relacija R je v prvi normalni obliki (1NF), če in samo če vse njene domene vsebujejo samo atomske vrednosti (Datum, ibid.).

Relacija R je v drugi normalni obliki (2NF), če in samo če je v 1NF in je vsak atribut, ki ni ključ, v celoti odvisen od primarnega ključa (Datum, ibid.).

Relacija R je v tretji normalni obliki (3NF), če in samo če je v 2NF in vsak atribut, ki ni ključ, ni prehodno odvisen od primarnega ključa (Datum, ibid.).

Relacija R je v Boyce-Codd normalni obliki (BCNF), če in samo če je vsaka determinanta kandidat za uporabo kot ključ.

OPOMBA Spodaj je kratka razlaga nekaterih okrajšav, uporabljenih v definicijah Date.

FD (funkcionalna odvisnost) - funkcionalna odvisnost. V funkcionalni odvisnosti je vrednost atributa odvisna od vrednosti drugega atributa, ki ni del primarnega ključa.

Za peto normalno obliko relacija R izpolnjuje razmerje unije (JD)*(X, Y, …, Z), če in samo če je R enakovreden svojim projekcijam na X, Y,..., Z, kjer je X, Y, .., Z podmnožice niza atributov R.

Poslovni običajni obrazci

Tretja poslovna normalna oblika (3BNF) premakne atribute, ki niso odvisni od primarnega ključa, v drugo entiteto, kjer so popolnoma odvisni od primarnega ključa te entitete.

Dokončan logični podatkovni model

Razmerja morajo vključevati glagolsko konstrukcijo, ki opisuje razmerje med entitetami, skupaj z značilnostmi, kot so množina, potreba po obstoju ali možnost neobstoja razmerja.

Fizični podatkovni model

Zbiranje zahtev za uporabo podatkov

Zahteve za dostop in zmogljivost

Volumetrične značilnosti (ocena količine podatkov, ki jih je treba shraniti), ki omogočajo skrbniku, da predstavi fizični obseg baze podatkov

Ocena števila uporabnikov, ki morajo hkrati dostopati do podatkov, kar vam pomaga oblikovati svojo bazo podatkov za sprejemljivo raven zmogljivosti

Povzetek, povzetek in drugi izračunani ali izpeljani podatki, ki se lahko štejejo za kandidate za shranjevanje v trajnih podatkovnih strukturah

Zahteve za generiranje poročil in standardnih poizvedb za pomoč skrbniku baze podatkov pri izdelavi indeksov

Pogledi (trajni ali virtualni), ki bodo uporabniku pomagali pri izvajanju operacij združevanja ali filtriranja podatkov.

Komponente fizičnega podatkovnega modela

povratni inženiring

Uporaba funkcionalnih meja podjetja

Kaj je podatkovni model podjetja?

Izgradnja podatkovnega modela podjetja s skaliranjem

Koncept metodologije modeliranja

Obstaja več metodologij za vizualno modeliranje podatkov. ERwin podpira dva:

IDEF1X (Integracijska definicija za informacijsko modeliranje - integriran opis informacijskih modelov).

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

IDEF1X je dobra metodologija in njen zapis se pogosto uporablja

Integriran opis informacijskih modelov

Informacijski inženiring

Zaključek

Strokovnjaki IT vedno bolj usmerjajo pozornost k rešitvam za upravljanje podatkov, ki temeljijo na industrijskih standardnih podatkovnih modelih in predlogah poslovnih odločitev. Kompleksni modeli fizičnih podatkov, pripravljeni za nalaganje, in poročila poslovne inteligence za določena področja dejavnosti vam omogočajo poenotenje informacijske komponente podjetja in znatno pospešite poslovne procese. Predloge rešitev omogočajo ponudnikom storitev, da izkoristijo moč nestandardnih informacij, skritih v obstoječih sistemih, s čimer se zmanjšajo roki, stroški in tveganja projekta. Na primer, resnični projekti kažejo, da lahko podatkovni model in predloge poslovnih odločitev zmanjšajo razvojni napor za 50 %.

Industrijski logični model je domensko specifičen, integriran in logično strukturiran pogled na vse informacije, ki morajo biti v podatkovnem skladišču podjetja, da odgovori tako na strateška kot taktična poslovna vprašanja. Glavni namen modelov je olajšati orientacijo v podatkovnem prostoru in pomagati pri poudarjanju podrobnosti, ki so pomembne za razvoj poslovanja. V današnjem poslovnem okolju je nujno jasno razumevanje odnosov med različnimi komponentami in dobro razumevanje celotne slike organizacije. Prepoznavanje vseh podrobnosti in odnosov z uporabo modelov omogoča najučinkovitejšo uporabo časa in orodij za organizacijo dela podjetja.

Podatkovni modeli so abstraktni modeli, ki opisujejo, kako so podatki predstavljeni in dostopni. Podatkovni modeli definirajo podatkovne elemente in odnose med njimi na danem območju. Podatkovni model je navigacijsko orodje za poslovne in IT strokovnjake, ki uporablja določen nabor simbolov in besed za natančno razlago določenega razreda resničnih informacij. To izboljša komunikacijo znotraj organizacije in tako ustvari bolj prilagodljivo in stabilno aplikacijsko okolje.

Primer modela "GIS za organe oblasti in lokalno samoupravo".

Danes je za ponudnike programske opreme in storitev strateško pomembno, da se lahko hitro odzovejo na spremembe v panogi, povezane s tehnološkimi inovacijami, odpravo vladnih omejitev in kompleksnostjo dobavne verige. Skupaj s spremembami v poslovnem modelu rasteta kompleksnost in stroški informacijske tehnologije, potrebne za podporo dejavnosti podjetja. Upravljanje podatkov je še posebej težko v okolju, kjer se korporativni informacijski sistemi ter njihove funkcionalne in poslovne zahteve nenehno spreminjajo.

Da bi olajšali in optimizirali ta proces, se pri prevajanju IT pristopa na sodobno raven uporabljajo industrijski podatkovni modeli.

Panožni podatkovni modeli podjetjaEsri

Podatkovni modeli za platformo Esri ArcGIS so delovne predloge za uporabo v GIS projektih in ustvarjanje podatkovnih struktur za različna področja uporabe. Izgradnja podatkovnega modela vključuje ustvarjanje konceptualne zasnove, logične strukture in fizične strukture, ki se nato lahko uporabi za izgradnjo osebne ali korporativne baze geopodatkov. ArcGIS ponuja orodja za ustvarjanje in upravljanje sheme baze podatkov, predloge podatkovnega modela pa se uporabljajo za hitro zagon projekta GIS v različnih aplikacijah in panogah. Esri je skupaj s skupnostjo uporabnikov porabil veliko časa za razvoj številnih predlog, ki vam lahko pomagajo hitro začeti načrtovati podjetniško zbirko geopodatkov. Ti projekti so opisani in dokumentirani na support.esri.com/datamodels. Spodaj, v vrstnem redu, v katerem se pojavljajo na tem spletnem mestu, so semantični prevodi imen Esrijevih industrijskih modelov:

Naslovni register
kmetijstvo
Meteorologija
Osnovni prostorski podatki
biotske raznovrstnosti
Notranji prostor stavb
Obračun toplogrednih plinov
Vzdrževanje upravnih meja
Vojaška ustanova. Obveščevalna služba
Energija (vključno z novim protokolom ArcGIS MultiSpeak)
Ekološke zgradbe
Ministrstvo za izredne razmere. požarno zaščito
Gozdni kataster
gozdarstvo
geologija
GIS na nacionalni ravni (e-gov)
Podtalnica in odpadna voda
skrb za zdravje
Arheologija in varstvo spominskih območij
državna varnost
Hidrologija
Mednarodna hidrografska organizacija (IHO). Format S-57 za ENC
Namakanje
Zemljiška knjiga
občinska oblast
Pomorska navigacija
Državni kataster
Naftne in plinske konstrukcije
Cevovodi
Trgovine z rastrji
Batimetrija, topografija morskega dna
Telekomunikacije
Prevoz
Vodovod, kanalizacija, komunale

Ti modeli vsebujejo vse potrebne lastnosti industrijskega standarda, in sicer:

so prosto dostopni;
niso vezani na tehnologijo »izbranega« proizvajalca;
nastala kot rezultat izvajanja resničnih projektov;
ustvarjen s sodelovanjem strokovnjakov iz industrije;
zasnovan za zagotavljanje informacijske interakcije med različnimi izdelki in tehnologijami;
niso v nasprotju z drugimi standardi in regulativnimi dokumenti;
uporabljajo pri izvedenih projektih po vsem svetu;
so zasnovani za delo z informacijami skozi celoten življenjski cikel ustvarjenega sistema in ne za sam projekt;
razširljiv glede na potrebe stranke brez izgube združljivosti z drugimi projekti in/ali modeli;
spremljajo dodatna gradiva in primeri;
uporablja se v smernicah in tehničnih materialih različnih industrijskih podjetij;
velika skupnost udeležencev, medtem ko je dostop do skupnosti odprt vsem;
veliko število sklicevanj na podatkovne modele v publikacijah v zadnjih letih.

Esri je del strokovne skupine neodvisnih organov, ki priporočajo različne industrijske modele za uporabo, kot je PODS (Pipeline Open Data Standards – odprti standard za naftno in plinsko industrijo; trenutno je PODS implementiran kot Esri PODS Esri Spatial 5.1.1 geodatabase) ali geodatabase (GDB) iz ArcGIS for Aviation, ki upošteva priporočila ICAO in FAA ter standard za izmenjavo navigacijskih podatkov AIXM 5.0. Poleg tega so priporočeni modeli, ki se strogo držijo obstoječih industrijskih standardov, kot sta S-57 in ArcGIS for Maritime (morske in obalne značilnosti), pa tudi modeli, ustvarjeni iz dela Esri Professional Services in so "de facto" standardi na ustreznih področjih. Na primer, GIS za državo in lokalno samoupravo je vplival na standarde NSDI in INSPIRE, medtem ko se Hydro in Podzemna voda močno uporabljata v brezplačno dostopnem profesionalnem paketu ArcHydro in komercialnih izdelkih tretjih podjetij. Treba je opozoriti, da Esri podpira tudi "de facto" standarde, kot je NHDI. Vsi predlagani podatkovni modeli so dokumentirani in pripravljeni za uporabo v IT procesih podjetja. Spremni materiali za modele vključujejo:

UML diagrami razmerij entitet;
podatkovne strukture, domene, imeniki;
že pripravljene predloge geopodatkovnih baz v formatu ArcGIS GDB;
vzorčni podatki in vzorčne aplikacije;
primeri skriptov za nalaganje podatkov, primeri pripomočkov za analizo;
referenčne knjige o predlagani strukturi podatkov.

Esri svoje izkušnje pri gradnji industrijskih modelov povzema v obliki knjig in lokalizira objavljena gradiva. Esri CIS je lokaliziral in izdal naslednje knjige:

Geospatial Service Oriented Architecture (SOA);
Oblikovanje geopodatkovnih baz za transport;
Korporativni geoinformacijski sistemi;
GIS: nova energija elektro in plinskih podjetij;
Nafta in plin na digitalnem zemljevidu;
Modeliranje našega sveta. Esri Geodatabase Design Guide;
Razmišljam o GIS. GIS načrtovanje: vodnik za menedžerje;
Geografski informacijski sistemi. Osnove;
GIS za administrativno in gospodarsko upravljanje;
Spletni GIS. Načela in uporaba;
Strategije načrtovanja sistemov, 26. izdaja;
68 številk revije ArcReview z objavami podjetij in uporabnikov GIS sistemov;
... in številne druge tematske zapiske in objave.

Na primer knjiga Modeliranje našega sveta ..."(prevod) je izčrpen vodnik in referenčni vodnik za modeliranje podatkov GIS na splošno in model podatkov geodatabase zlasti. Knjiga prikazuje, kako sprejemati prave odločitve glede modeliranja podatkov, odločitve, ki so vključene v vsak vidik projekta GIS: od podatkov o načrtovanju baze podatkov in zbiranja podatkov do prostorske analize in vizualizacije Podrobno opisuje, kako oblikovati geografsko bazo podatkov, primerno za projekt, nastaviti funkcionalnost baze podatkov brez programiranja, upravljati potek dela v kompleksnih projektih, modelirati različne omrežne strukture, kot so reka, promet ali električna omrežja, integrirajte podatke satelitskih posnetkov v geografsko analizo in kartiranje ter ustvarite 3D GIS podatkovne modele. Oblikovanje geopodatkovnih baz za transport" vsebuje metodološke pristope, ki so bili preizkušeni na velikem številu projektov in so v celoti skladni z zakonodajnimi zahtevami Evrope in ZDA ter mednarodnimi standardi. In v knjigi " GIS: nova energija elektro in plinskih podjetij S primeri iz resničnega sveta prikazuje prednosti, ki jih lahko GIS podjetja prinese dobavitelju energije, vključno z vidiki, kot so storitve za stranke, delovanje omrežja in drugi poslovni procesi.

Nekatere prevedene in izvirne knjige so v ruščini izdale Esri CIS in DATA+. Pokrivajo tako konceptualna vprašanja, povezana s tehnologijo GIS, kot tudi številne uporabne vidike modeliranja in uvajanja GIS različnih obsegov in namenov.

Razmislili bomo o uporabi industrijskih modelov z uporabo podatkovnega modela BISDM (Building Interior Space Data Model) različice 3.0 kot primer. BISDM je razvoj splošnejšega modela BIM (Building Information Model, stavbni informacijski model) in je namenjen uporabi pri projektiranju, gradnji, obratovanju in razgradnji stavb in objektov. Uporablja se v programski opremi GIS, vam omogoča učinkovito izmenjavo geopodatkov z drugimi platformami in interakcijo z njimi. Nanaša se na splošno skupino nalog FM (upravljanje infrastrukture organizacije). Navajamo glavne prednosti modela BISDM, katerih uporaba omogoča:

organizirati izmenjavo informacij v heterogenem okolju po enotnih pravilih;
pridobiti »fizično« utelešenje koncepta BIM in priporočena pravila za vodenje gradbenega projekta;
vzdrževati enotno skladišče z uporabo GIS orodij skozi celoten življenjski cikel stavbe (od načrtovanja do razgradnje);
koordinirati delo različnih strokovnjakov v projektu;
vizualizirati načrtovani urnik in faze gradnje za vse udeležence;
podati predhodno oceno stroškov in časa gradnje (4D in 5D podatki);
nadzorovati potek projekta;
zagotoviti kakovostno delovanje stavbe, vključno z vzdrževanjem in popravili;
postati del sistema upravljanja premoženja, vključno s funkcijami analize učinkovitosti rabe prostora (najem, skladiščne prostore, upravljanje zaposlenih);
izračunati in upravljati energetsko učinkovitost stavbe;
simulirati gibanje človeških tokov.

BISDM opredeljuje pravila za delo s prostorskimi podatki na nivoju notranjih prostorov v stavbi, vključno z namenom in vrstami rabe, položenimi komunikacijami, nameščeno opremo, računovodstvom popravil in vzdrževanja, evidentiranjem incidentov, razmerji z ostalim premoženjem podjetja. Model pomaga ustvariti enoten repozitorij geografskih in negeografskih podatkov. Izkušnje vodilnih svetovnih podjetij so bile uporabljene za izolacijo entitet in modeliranje na ravni GDB (geodatabase) prostorskih in logičnih razmerij vseh fizičnih elementov, ki tvorijo tako zgradbo samo kot njeno notranjost. Upoštevanje načel BISDM vam omogoča, da bistveno poenostavite naloge integracije z drugimi sistemi. Na prvi stopnji je to običajno integracija s CAD. Nato se med obratovanjem stavbe uporablja izmenjava podatkov s sistemi ERP in EAM (SAP, TRIRIGA, Maximo itd.).

Vizualizacija strukturnih elementov BISDM z uporabo ArcGIS.

V primeru uporabe BISDM kupec/lastnik objekta prejme od konca do konca izmenjavo informacij od ideje ustvarjanja objekta do razvoja celotnega projekta, nadzora gradnje s pridobivanjem do - podatke o datumu do začetka obratovanja objekta, nadzor parametrov med obratovanjem, pa tudi med rekonstrukcijo ali razgradnjo objekta. Po paradigmi BISDM postaneta GIS in GDB, ustvarjena z njegovo pomočjo, skupno skladišče podatkov za sorodne sisteme. V GDB so pogosto podatki, ki jih ustvarijo in upravljajo sistemi tretjih oseb. To je treba upoštevati pri načrtovanju arhitekture ustvarjenega sistema.

Na določeni stopnji vam nabrana "kritična masa" informacij omogoča prehod na novo kvalitativno raven. Na primer, po zaključku faze projektiranja nove stavbe je mogoče samodejno vizualizirati 3D modele geodetskih modelov v GIS, sestaviti seznam opreme, ki jo je treba vgraditi, izračunati kilometre inženirskih omrežij, ki jih je treba položiti, opraviti vrsto preverjanj. , in celo podati predhodno finančno oceno stroškov projekta.

Še enkrat, ko uporabljate BISDM in ArcGIS skupaj, je mogoče samodejno graditi 3D modele iz zbranih podatkov, saj GDB vsebuje popoln opis objekta, vključno z z-koordinatami, pripadajočimi nadstropji, vrstami povezav elementov, opremo načini namestitve, material, razpoložljive poti gibanja osebja, funkcionalni namen posameznega elementa itd. itd. Opozoriti je treba, da je po začetnem uvozu vseh oblikovalskih materialov v BISDM GDB potrebna dodatna vsebina za:

postavitev 3D modelov predmetov in opreme na določenih mestih;
zbiranje informacij o stroških materialov in postopku za njihovo polaganje in namestitev;
nadzor prehodnosti glede na dimenzije vgrajene nestandardne opreme.

Z uporabo ArcGIS-a je poenostavljen uvoz dodatnih 3D objektov in referenčnih knjig iz zunanjih virov. Modul ArcGIS Data Interoperability vam omogoča, da ustvarite postopke za uvoz takšnih podatkov in njihovo pravilno umestitev v model. Podprti so vsi formati, ki se uporabljajo v industriji, vključno z IFC, AutoCAD Revit, Bentlye Microstation.

IBM-ovi industrijski podatkovni modeli

IBM ponuja nabor orodij in modelov za upravljanje pomnilnika za različne panoge:

IBM Banking and Financial Markets Data Warehouse (finance)
IBM-ovo bančno podatkovno skladišče
IBM-ovi modeli bančnih procesov in storitev
Podatkovni model IBM-ovega zdravstvenega načrta (zdravje)
IBM Insurance Information Warehouse (zavarovanje)
IBM-ovi zavarovalni procesi in modeli storitev
IBM-ovo maloprodajno podatkovno skladišče (maloprodaja)
IBM Telecommunications Data Warehouse (telekomunikacije)
InfoSphere Warehouse Pack:
- za vpogled v stranke (za razumevanje strank)
- za vpogled v trg in kampanjo (za razumevanje podjetja in trga)
- za Supply Chain Insight (za razumevanje dobaviteljev).

Na primer, model IBMbančništvoinFinančnatrgiPodatkiSkladišče zasnovan za reševanje posebnih izzivov bančne industrije v smislu podatkov, in IBMbančništvoprocesinStoritevModeli- v smislu procesov in SOA (storitveno usmerjene arhitekture). Predstavljeni modeli za telekomunikacijsko industrijo IBMinformacijeFrameWork(IFW) in IBMTelekomunikacijePodatkiSkladišče (TDW). Pomagajo bistveno pospešiti proces ustvarjanja analitičnih sistemov ter zmanjšati tveganja, povezana z razvojem aplikacij za poslovno inteligenco, upravljanjem podatkov v podjetju in organizacijo podatkovnih skladišč, ob upoštevanju posebnosti telekomunikacijske industrije. Zmogljivosti IBM TDW pokrivajo celoten spekter telekomunikacijskega trga – od ponudnikov interneta in operaterjev kabelskih omrežij, ki ponujajo storitve žične in brezžične telefonije, prenosa podatkov in večpredstavnostnih vsebin, do multinacionalnih podjetij, ki ponujajo telefonske, satelitske, medkrajevne in mednarodne komunikacijske storitve, kot tudi kot globalne mreže organizacij. Danes TDW uporabljajo veliki in majhni ponudniki žičnih in brezžičnih storitev po vsem svetu.

Orodje je klicalo InfoSphere Warehouse Pack za vpogled v stranke je strukturirana in enostavno izvedljiva poslovna vsebina za vse večje število poslovnih projektov in panog, vključno z bančništvom, zavarovalništvom, financami, programi zdravstvenega zavarovanja, telekomunikacijami, maloprodajo in distribucijo. Za poslovne uporabnike InfoSphere Warehouse Pack za vpogled v trg in kampanjo vam pomaga povečati učinkovitost vaših tržnih obveščevalnih in marketinških kampanj s postopnim razvojnim in poslovnim procesom. Preko InfoSphere Warehouse Pack za Supply Chain Insight organizacije imajo možnost pridobiti aktualne informacije o delovanju dobavne verige.

Položaj Esrija v arhitekturi rešitev IBM.

Posebej velja omeniti IBM-ov pristop do javnih služb in komunalnih podjetij. Da bi izpolnila naraščajoče zahteve potrošnikov, komunalna podjetja potrebujejo bolj prilagodljivo arhitekturo, kot jo uporabljajo danes, pa tudi industrijski standardni objektni model, ki bo olajšal brezplačno izmenjavo informacij. To bo povečalo komunikacijske zmogljivosti energetskih podjetij, saj bo omogočilo stroškovno učinkovitejšo komunikacijo in bo novim sistemom omogočilo boljšo vidljivost vseh potrebnih virov, ne glede na to, kje se nahajajo v organizaciji. Osnova za ta pristop je SOA (Service Oriented Architecture), komponentni model, ki vzpostavlja korespondenco med funkcijami oddelkov in storitev različnih aplikacij, ki jih je mogoče ponovno uporabiti. "Storitve" takšnih komponent komunicirajo prek vmesnikov brez trde vezave, pri čemer uporabniku skrivajo celotno kompleksnost sistemov za njimi. V tem načinu lahko podjetja preprosto dodajajo nove aplikacije ne glede na prodajalca programske opreme, operacijski sistem, programski jezik ali druge notranje značilnosti programske opreme. Koncept se izvaja na podlagi SOA VARNO ( Arhitektura rešitev za energijo, omogoča komunalni industriji, da pridobi na standardih temelječ, celosten pogled na svojo infrastrukturo.

Esri ArcGIS® je svetovno priznana programska platforma za geografske informacijske sisteme (GIS), ki zagotavlja ustvarjanje in upravljanje digitalnih sredstev elektroenergetskih, prenosnih, distribucijskih in telekomunikacijskih omrežij. ArcGIS vam omogoča, da izvedete najbolj popoln popis komponent električnega distribucijskega omrežja ob upoštevanju njihove prostorske lokacije. ArcGIS znatno razširi arhitekturo IBM SAFE z zagotavljanjem orodij, aplikacij, delovnih tokov, analitike ter informacijskih in integracijskih zmogljivosti, potrebnih za upravljanje pametnega omrežja. ArcGIS znotraj IBM SAFE vam omogoča pridobivanje informacij iz različnih virov o infrastrukturnih objektih, sredstvih, strankah in zaposlenih s točnimi podatki o njihovi lokaciji ter ustvarjanje, shranjevanje in obdelava georeferenciranih informacij o sredstvih podjetja (stebri, cevovodi, žice, transformatorji, kabelski kanali itd.). ArcGIS znotraj VARNE infrastrukture vam omogoča dinamično povezovanje ključnih poslovnih aplikacij z združevanjem podatkov iz GIS, SCADA in sistemov za storitve za stranke z zunanjimi informacijami, kot so promet, vremenske razmere ali satelitski posnetki. Pripomočki uporabljajo te združene informacije za različne namene, od C.O.R. (velika slika obratovalnega okolja) do pregledov lokacije, vzdrževanja, analize omrežja in načrtovanja.

Informacijske komponente podjetja za oskrbo z električno energijo je mogoče modelirati z uporabo več ravni, ki segajo od najnižje - fizične - do najvišje, najbolj zapletene ravni logike poslovnih procesov. Te plasti je mogoče integrirati za izpolnjevanje tipičnih zahtev industrije, kot so avtomatizirano beleženje meritev in nadzorni nadzor ter nadzor pridobivanja podatkov (SCADA). Z gradnjo SAFE arhitekture komunalna podjetja močno napredujejo pri napredovanju modela odprtih objektov za celotno panogo, imenovanega Common Information Model (CIM) za energetiko in komunalne storitve. Ta model zagotavlja potrebno osnovo za premikanje številnih podjetij k storitveno usmerjeni arhitekturi, saj spodbuja uporabo odprtih standardov za strukturiranje podatkov in objektov. Če vsi sistemi uporabljajo iste objekte, se bosta zmeda in neelastičnost, povezana z različnimi izvedbami istih objektov, zmanjšala na minimum. Tako bo poenotena definicija objekta »odjemalec« in drugih pomembnih poslovnih objektov v vseh sistemih elektroenergetskega podjetja. S CIM si lahko ponudniki storitev in potrošniki storitev zdaj delijo skupno podatkovno strukturo, kar olajša oddajo dragih poslovnih komponent v zunanje izvajanje, saj CIM vzpostavi skupno bazo za gradnjo izmenjave informacij.

Zaključek

Celoviti industrijski podatkovni modeli zagotavljajo podjetjem enoten integriran pogled na njihove poslovne informacije. Številna podjetja težko integrirajo svoje podatke, čeprav je to predpogoj za večino projektov v celotnem podjetju. Glede na študijo The Data Warehousing Institute (TDWI) je več kot 69 % anketiranih organizacij ugotovilo, da je integracija pomembna ovira za sprejemanje novih aplikacij. Nasprotno, implementacija integracije podatkov podjetju prinaša oprijemljive prihodke in večjo učinkovitost.

Dobro zgrajen model enolično definira pomen podatkov, ki so v tem primeru strukturirani podatki (v nasprotju z nestrukturiranimi podatki, kot so slika, binarna datoteka ali besedilo, kjer je vrednost lahko dvoumna). Najučinkovitejše industrijske modele ponujajo profesionalni prodajalci, vključno z Esri in IBM. Visoka donosnost uporabe njihovih modelov je dosežena zaradi njihove znatne stopnje podrobnosti in natančnosti. Običajno vsebujejo veliko podatkovnih atributov. Poleg tega imajo strokovnjaki iz Esrija in IBM-a ne le bogate izkušnje z modeliranjem, ampak so tudi dobro seznanjeni z gradnjo modelov za določeno industrijo.

Arhitektura baze podatkov

CMD shema je opis strukture podatkovnega modela z vidika skrbnika.

Shema AMD je opis notranjega ali fizičnega modela. Shrani opis fizične lokacije podatkov na nosilcu. Shema shranjuje neposredne navedbe lokacije podatkov v pomnilniku (nosilci, diski).

Shema CMD opisuje strukturo podatkov, zapisov in polj.

Vsi DBMS podpirajo tri glavne vrste podatkovnih modelov:

1. Hierarhični model. Predpostavlja nekaj korenskega vnosa. Veje izvirajo iz korenin.

Vsi predmeti niso primerno opisani na ta način. V hierarhiji ni povezav, značilna je velika redundanca informacij.

2. Model omrežja. Omogoča vam, da pravilno prikažete vso zapletenost odnosov.

Model je priročen za predstavitev povezav s podatki iz zunanjega okolja, manj priročen pa za opisovanje v bazi podatkov, kar uporabniku pripelje do dodatnega dela pri preučevanju navigacije po povezavah.

3. Relacijski model. Temelji na matematičnem izrazu Relation – relacija, a preprosto – tabela. Na primer, pravokotni dvodimenzionalni.

Relacijsko podatkovno strukturo so v poznih 60. letih razvili številni raziskovalci, med katerimi je najpomembnejši prispevek IBM-ov uslužbenec Edgar Codd. Z relacijskim pristopom so podatki predstavljeni v obliki dvodimenzionalnih tabel, kar je za človeka najbolj naravno. Hkrati je Codd za obdelavo podatkov predlagal uporabo aparature teorije množic - unija, presečišče, razlika, kartezijev produkt.

Vrsta podatkov- ta koncept ima enak pomen kot v programskih jezikih (tj. tip podatkov opredeljuje notranjo predstavitev v računalniškem pomnilniku in način shranjevanja podatkovne instance, kot tudi nabor vrednosti, ki jih primerek podatkov lahko sprejme in nabor veljavnih podatkovnih operacij). Vse obstoječe sodobne baze podatkov podpirajo posebne vrste podatkov, namenjenih shranjevanju podatkov celega tipa, delne plavajoče vejice, znakov in nizov, koledarskih datumov. Številni strežniki baz podatkov izvajajo druge vrste, na primer strežnik Interbase ima poseben tip podatkov za shranjevanje velikih binarnih informacijskih nizov (BLOB).

domena je potencialni niz vrednosti enostavnega podatkovnega tipa, podoben je podtipu podatkov v nekaterih programskih jezikih. Domena je definirana z dvema elementoma – podatkovnim tipom in logičnim izrazom, ki se uporablja za podatke. Če se ta izraz oceni kot true, potem primerek podatkov pripada domeni.

Odnos je dvodimenzionalna tabela posebne vrste, sestavljena iz glave in telesa.

glavo je fiksen nabor atributov, od katerih je vsak definiran na neki domeni, med atributi in domenami, ki določajo, pa obstaja medsebojna korespondenca.

Vsak atribut je definiran na svoji domeni. Domena je celoštevilski podatkovni tip, logični pogoj pa je n>0. Naslov je brezčasen, za razliko od telesa relacije. Telo razmerja- je zbirka tuples, od katerih je vsak par atribut-vrednost.

Po moči odnosa je število njegovih naborkov in stopnja odnosa je število atributov.

Stopnja razmerja je konstantna vrednost za dano razmerje, medtem ko se moč razmerja s časom spreminja. Moč razmerja se imenuje tudi kardinalno število.

Zgornji koncepti so teoretični in se uporabljajo pri razvoju jezikovnih orodij in programskih sistemov za relacijske DBMS. Pri vsakdanjem delu se namesto njih uporabljajo njihovi neformalni ustrezniki:

odnos - miza;

atribut - stolpec ali polje;

tuple - zapis ali vrstico.

Tako je stopnja relacije število stolpcev v tabeli, kardinalno število pa število vrstic.

Ker je relacija množica in v klasični teoriji množic množica po definiciji ne more vsebovati ujemajočih se elementov, relacija ne more imeti dveh identičnih nizov. Zato za dano relacijo vedno obstaja nabor atributov, ki enolično identificirajo niz. Ta niz atributov se imenuje ključ.

Ključ mora izpolnjevati naslednje zahteve:

mora biti edinstven;

· mora biti minimalen, to pomeni, da odstranitev katerega koli atributa iz ključa vodi v kršitev edinstvenosti.

Praviloma je število atributov v ključu manjše od stopnje relacije, v skrajnih primerih pa lahko ključ vsebuje vse atribute, saj kombinacija vseh atributov izpolnjuje pogoj edinstvenosti. Običajno ima relacija več ključev. Od vseh ključev relacije (imenovanih tudi "možni ključi") je eden izbran kot primarni ključ. Pri izbiri primarni ključ prednost se običajno daje ključu z najmanjšim številom atributov. Prav tako je neprimerna uporaba ključev z vrednostmi dolgih nizov.

V praksi se kot primarni ključ pogosto uporablja poseben številski atribut – ničla, ki se samodejno poveča, katere vrednost lahko generira sprožilec (prožilec je poseben postopek, ki se pokliče ob spremembah baze podatkov) oz. s posebnimi sredstvi, opredeljenimi v mehanizmu DBMS.

Koncepti, opisani v tem poglavju, niso specifični za nobeno izvedbo baze podatkov, ampak so skupni vsem. Tako so ti koncepti osnova določenega splošnega modela, ki se imenuje relacijski podatkovni model.

Ustanovitelj relacijskega pristopa, Date, je ugotovil, da je relacijski model sestavljen iz treh delov:

strukturno;

· manipulativno;

celostno.

Relacije so fiksirane v strukturnem delu modela kot edina podatkovna struktura, ki se uporablja v relacijskem modelu.

V manipulacijskem delu sta določena dva osnovna mehanizma za manipulacijo relacijskih podatkovnih baz - relacijska algebra in relacijski račun.

Sestavni del se razume kot določen mehanizem za zagotavljanje neuničljivosti podatkov. Del integritete vključuje dve osnovni zahtevi za celovitost relacijskih baz podatkov – integriteto entitete in referenčno celovitost.

Zahteva integriteto entitete je, da se mora vsak množica katere koli relacije razlikovati od katerega koli drugega niza te relacije, to je, z drugimi besedami, vsaka relacija mora imeti primarni ključ. Ta zahteva mora biti izpolnjena, če so izpolnjene osnovne lastnosti razmerja.

V jeziku za obdelavo podatkov, pa tudi v jeziku poizvedb, se izvaja matematični aparat, imenovan algebra relacije, za katerega so opredeljena naslednja dejanja:

1. Standardne operacije: - presečišče, - združitev, \ - razlika, X - kartezijev produkt.

2. Specifično: projekcija, omejitev, povezava, delitev.

a. Združenje.

SD SHM EI HP

R 1 (šifra dela, šifra materiala, merske enote, stopnja porabe)

R 2 (SHD, SHM, EI, HP)

Treba je najti

Združeval naj bi niza R 1 in R 2 . Pri tej operaciji se ohrani stopnja in kardinalnost nastalega niza

b. križišče.

Označite ujemajoče se črte.

c. Razlika.

Izključi iz nizov R 1, ki se ujemajo z R 2 .

d. Kartezijanski produkt.

Tu so torki povezani.

Vsaka vrstica enega niza je povezana z vsako vrstico drugega.

Glede na dva sklopa:

Kartezijanski produkt ima naslednjo obliko:

V tem primeru je S-stopnja, a, t.j. dobite 12 vrstic in 5 stolpcev.

Podjetniška baza podatkov je osrednja povezava korporativnega informacijskega sistema in omogoča ustvarjanje enotnega informacijskega prostora podjetja. Podjetniške baze podatkov

Delite delo na družbenih omrežjih

Če vam to delo ne ustreza, je na dnu strani seznam podobnih del. Uporabite lahko tudi gumb za iskanje

TEMA V PODATKOVNE BAZE PODATKOV

V .ena. Organizacija podatkov v sistemih podjetja. Podjetniške baze podatkov.

V .2. DBMS in strukturne rešitve v korporativnih sistemih.

V.3. Internet / intranet tehnologije in rešitve za dostop do podatkovnih baz podjetij.

V .ena. ORGANIZACIJA PODATKOV V KORPORATIVNIH SISTEMIH. PODATKOVNE BAZE PODATKOV

Podjetniška baza podatki so osrednja povezava korporativnega informacijskega sistema in vam omogočajo ustvarjanje enotnega informacijskega prostora korporacije. Podjetniške baze podatkov (slika 1.1).

Obstajajo različne definicije baz podatkov.

Pod bazo podatkov (DB) razumeti nabor informacij, ki so logično povezane na način, da sestavljajo en sam niz podatkov, shranjenih v pomnilniških napravah računalnika. Ta sklop deluje kot začetni podatek nalog, ki se rešujejo v procesu delovanja avtomatiziranih krmilnih sistemov, sistemov za obdelavo podatkov, informacijskih in računalniških sistemov.

Izraz baze podatkov lahko na kratko formulirate kot zbirko logično povezanih podatkov, namenjenih za skupno rabo.

Pod bazo podatkov se nanaša na zbirko podatkov, shranjenih skupaj z minimalno redundanco, tako da se lahko optimalno uporablja za eno ali več aplikacij.

Namen ustvarjanja baz podatkov kot oblika shranjevanja podatkov gradnja podatkovnega sistema, ki ni odvisen od sprejetih algoritmov (programske opreme), uporabljenih tehničnih sredstev, fizične lokacije podatkov v računalniku. Baza podatkov predvideva večnamensko uporabo (več uporabnikov, številne oblike dokumentov in poizvedbe enega uporabnika).

Osnovne zahteve za bazo podatkov:

Popolnost predstavitve podatkov. Podatki v bazi morajo ustrezno predstavljati vse informacije o objektu in zadoščati za ODS.
Celovitost baze podatkov. Podatke je treba ohraniti med obdelavo njihovih ODS in v vseh situacijah, ki se pojavijo med delom.
Prilagodljivost podatkovne strukture. Baza podatkov mora omogočati spreminjanje podatkovnih struktur, ne da bi pri tem kršili njeno celovitost in popolnost, ko se spremenijo zunanji pogoji.
Uresničljivost. To pomeni, da mora obstajati objektivna predstavitev različnih predmetov, njihovih lastnosti in odnosov.
Razpoložljivost. Treba je zagotoviti diferenciacijo dostopa do podatkov.
odvečnost. Baza podatkov mora imeti minimalno redundanco pri predstavljanju podatkov o katerem koli objektu.

Znanje se razume niz dejstev, vzorcev in hevrističnih pravil, s katerimi lahko rešiš problem.

Baza znanja (KB)  zbirka podatkov in uporabljenih pravil, prejetih od odločevalcev. Baza znanja je element ekspertnih sistemov.

treba razlikovati različne načine predstavitve podatkov.

Fizični podatki - To so podatki, shranjeni v pomnilniku računalnika.

Logična predstavitev podatkov ustreza uporabniški predstavitvi fizičnih podatkov. Razlika med fizično in ustrezno logično predstavitvijo podatkov je v tem, da slednja odraža nekatera pomembna razmerja med fizičnimi podatki.

Pod korporativno bazo podatkov razumeti bazo podatkov, ki v takšni ali drugačni obliki združuje vse potrebne podatke in znanje o avtomatizirani organizaciji. V korporativnih informacijskih sistemih je tak koncept kotintegrirane baze podatkov, v katerem se izvaja načelo enkratnega vnosa in večkratne uporabe informacij.

riž. 1.1. Struktura interakcije oddelkov z informacijskimi viri korporacije.

Podjetniške baze podatkov so osredotočen (centralizirano) in razdeljena.

Koncentrirana (centralizirana) baza podatkov je baza podatkov, katere podatki so fizično shranjeni v pomnilniških napravah enega računalnika. Na sl. 1.2 prikazuje diagram strežniške aplikacije za dostop do baz podatkov na različnih platformah.

Slika 1.2. Diagram heterogenega centralizirana baza podatkov

Centralizacija obdelave informacij je omogočila odpravo takšnih pomanjkljivosti tradicionalnih datotečnih sistemov, kot so neskladnost, nedoslednost in redundanca podatkov. Vendar pa se z rastjo podatkovnih baz, zlasti če se uporabljajo v geografsko razpršenih organizacijah, pojavljajo težave. Na primer, za koncentrirane baze podatkov, ki se nahajajo v vozlišču telekomunikacijskega omrežja, prek katerih različni oddelki organizacije dostopajo do podatkov, se s povečanjem količine informacij in števila transakcij pojavijo naslednje težave:

Velik pretok izmenjave podatkov;
Visok omrežni promet;
Nizka zanesljivost;
Nizka splošna zmogljivost.

Čeprav je med posodabljanjem v koncentrirani bazi podatkov lažje zagotoviti varnost, celovitost in doslednost informacij, te težave povzročajo določene težave. Kot možna rešitev teh težav je predlagana decentralizacija podatkov. Decentralizacija doseže:

Višja stopnja hkratnosti obdelave zaradi delitve obremenitve;
Izboljšanje uporabe podatkov na terenu pri izvajanju oddaljenih (oddaljenih) poizvedb;
nižji stroški;
Enostavno upravljanje lokalnih baz podatkov.

Stroški ustvarjanja omrežja z delovnimi postajami (majhnimi računalniki) na vozliščih so veliko nižji od stroškov izdelave podobnega sistema z uporabo glavnega računalnika. Slika 1.3 prikazuje logični diagram porazdeljene baze podatkov.

Slika 1.3. Porazdeljena baza podatkov podjetja.

Podajamo naslednjo definicijo porazdeljene baze podatkov.

Porazdeljena baza podatkov - to je zbirka informacij, datotek (relacije), shranjenih v različnih vozliščih informacijskega omrežja in logično povezanih tako, da tvorijo en sam niz podatkov (povezava je lahko funkcionalna ali preko kopij iste datoteke). Gre torej za niz zbirk podatkov, ki so med seboj logično povezane, a se fizično nahajajo na več strojih, ki so del istega računalniškega omrežja.

Najpomembnejše zahteve za značilnosti porazdeljene baze podatkov so naslednje:

Razširljivost;
Kompatibilnost;
Podpora za različne modele podatkov;
prenosljivost;
preglednost lokacije;
Avtonomija vozlišč porazdeljene baze podatkov (Site Autonomy);
Obdelava porazdeljenih zahtevkov;
Izvajanje porazdeljenih transakcij.
Podpora za homogen varnostni sistem.

Preglednost lokacije omogoča uporabnikom, da delajo z bazami podatkov, ne da bi vedeli ničesar o svoji lokaciji. Avtonomija vozlišč porazdeljene baze podatkov pomeni, da je mogoče vsako bazo podatkov vzdrževati neodvisno od drugih. Porazdeljena poizvedba je poizvedba (izjava SQL), med katero pride do dostopa do objektov (tabel ali pogledov) različnih baz podatkov. Pri izvajanju porazdeljenih transakcij se izvaja nadzor sočasnosti nad vsemi vključenimi bazami podatkov. Oracle7 uporablja tehnologijo dvofaznega prenosa informacij za izvajanje porazdeljenih transakcij.

Baze podatkov, ki sestavljajo porazdeljeno bazo podatkov, ni nujno, da so homogene (tj. izvajajo jih isti DBMS) ali delujejo v istem okolju operacijskega sistema in/ali na isti vrsti računalnikov. Ena baza podatkov je lahko na primer baza podatkov Oracle na računalniku SUN z operacijskim sistemom SUN OS(UNIX), drugo bazo podatkov lahko izvaja DB2 DB2 na velikem računalniku IBM 3090 z operacijskim sistemom MVS, tretjo bazo podatkov pa lahko izvaja SQL/DS DBMS tudi na IBM-ovem velikem računalniku, vendar z operacijskim sistemom VM. Obvezen je le en pogoj – vsi stroji z bazami podatkov morajo biti dostopni prek omrežja, katerega del so.

Glavna naloga porazdeljene baze podatkov – distribucijo podatkov po omrežju in zagotavljanje dostopa do njih. Obstajajo naslednji načini za rešitev te težave:

Vsako vozlišče shranjuje in uporablja svoj nabor podatkov, ki so na voljo za oddaljene poizvedbe. Ta porazdelitev je razdeljena.
Nekateri podatki, ki se pogosto uporabljajo na oddaljenih mestih, se lahko podvojijo. Takšna distribucija se imenuje delno podvojena.
Vsi podatki se podvojijo v vsakem vozlišču. Takšna distribucija se imenuje popolnoma redundantna.
Nekatere datoteke je mogoče razdeliti vodoravno (izbran je podnabor zapisov) ali navpično (izbran je podnabor atributnih polj), medtem ko so razdeljeni podnabori shranjeni v različnih vozliščih skupaj z nerazdeljenimi podatki. Takšna porazdelitev se imenuje razcepljena (razdrobljena).

Pri ustvarjanju porazdeljene baze podatkov na konceptualni ravni morate rešiti naslednje naloge:

Za celotno omrežje je treba imeti enotno idejno shemo. To bo uporabniku zagotovilo logično preglednost podatkov, zaradi česar bo lahko oblikoval zahtevo za celotno bazo podatkov, ki bo na ločenem terminalu (deluje tako rekoč s centralizirano bazo podatkov).
Za lociranje podatkov v omrežju je potrebna shema. To bo zagotovilo preglednost pri umestitvi podatkov, tako da uporabniku ne bo treba določiti, kam naj posreduje zahtevo, da dobi zahtevane podatke.
Rešiti je treba problem heterogenosti porazdeljenih baz podatkov. Porazdeljene baze podatkov so lahko homogene ali heterogene glede na strojno in programsko opremo. Problem heterogenosti je relativno enostavno rešiti, če je porazdeljena baza podatkov strojno heterogena, programsko pa homogena (isti DBMS v vozliščih). Če se v vozliščih porazdeljenega sistema uporabljajo različni DBMS, so potrebna sredstva za pretvorbo podatkovnih struktur in jezikov. To bi moralo zagotoviti preglednost transformacije v vozliščih porazdeljene baze podatkov.
Treba je rešiti problem upravljanja slovarjev. Za zagotavljanje vseh vrst preglednosti v porazdeljeni bazi podatkov so potrebni programi, ki upravljajo številne slovarje in referenčne knjige.
Treba je definirati metode za izvajanje poizvedb v porazdeljeni bazi podatkov. Metode za izvajanje poizvedb v porazdeljeni bazi se razlikujejo od podobnih metod v centraliziranih bazah podatkov, saj se morajo posamezni deli poizvedb izvajati na lokaciji ustreznih podatkov in delne rezultate prenesti na druga vozlišča; hkrati je treba zagotoviti koordinacijo vseh procesov.
Treba je rešiti problem vzporednega izvajanja poizvedb. V porazdeljeni bazi podatkov je potreben kompleksen mehanizem za upravljanje sočasne obdelave, ki mora predvsem zagotavljati sinhronizacijo ob posodobitvi informacij, kar zagotavlja konsistentnost podatkov.
Potreba po razviti metodologiji za distribucijo in umestitev podatkov, vključno z delitvijo, je ena glavnih zahtev za porazdeljeno bazo podatkov.

Eno izmed aktivno razvijajočih se novih področij arhitekture računalniških sistemov, ki je zmogljivo orodje za obdelavo nenumeričnih informacij, so stroji za baze podatkov. Stroji za baze podatkov se uporabljajo za reševanje nenumeričnih nalog, kot so shranjevanje, iskanje in preoblikovanje dokumentov in dejstev, delo s predmeti. Po opredelitvi podatkov kot digitalnih in grafičnih informacij o predmetih okoliškega sveta se v pojem podatkov med numerično in nenumerično obdelavo vgrajujejo različne vsebine. Numerična obdelava uporablja predmete, kot so spremenljivke, vektorji, matrice, večdimenzionalne matrike, konstante itd., medtem ko neštevilčna obdelava uporablja predmete, kot so datoteke, zapisi, polja, hierarhije, omrežja, relacije itd. številčna obdelava se nanaša neposredno na informacije o predmetih (na primer o določenem zaposlenem ali skupini zaposlenih), in ne na datoteko zaposlenega. Ne indeksira datoteke zaposlenih za izbiro določene osebe; tukaj bolj zanima vsebina želenega zapisa. Ogromne količine informacij so običajno podvržene nenumerični obdelavi. V različnih aplikacijah se lahko takšne operacije izvajajo na teh podatkih, na primer:

povečati plačo vsem zaposlenim v podjetju;
izračunajte bančne obresti na račune vseh strank;
spremenite seznam vsega blaga na zalogi;
najti zahtevani izvleček iz vseh besedil, shranjenih v knjižnici ali v bibliografskem informacijskem sistemu za iskanje;
poiščite opis želene pogodbe v datoteki, ki vsebuje pravne dokumente;
oglejte si vse datoteke z opisi patentov in poiščite patent (če obstaja), podoben ponovno predlaganemu.

Za implementacijo motorja baze podatkov, vzporednega in asociativnega arhitekture kot alternativa enoprocesorskimvon Neumannastrukturo, ki vam omogoča delo z velikimi količinami informacij v realnem času.

Motorji baz podatkov postajajo vse pomembnejši v povezavi z raziskovanjem in uporabo konceptov umetne inteligence, kot so reprezentacija znanja, ekspertni sistemi, sklepanje, prepoznavanje vzorcev itd.

Shramba informacij. Danes se mnogi zavedajo, da večina podjetij že upravlja z več bazami podatkov in za uspešno delo z informacijami niso potrebne le različne vrste baz podatkov, temveč različne generacije DBMS. Po statističnih podatkih vsaka organizacija uporablja povprečno 2,5 različnih DBMS. Potreba po »izolaciji« poslovanja podjetij oziroma ljudi, ki se s tem poslom ukvarjajo, od tehnoloških značilnosti baz podatkov, da se uporabnikom zagotovi enoten pogled na korporativne informacije, ne glede na to, kje so fizično shranjeni, je postala očitna. . To je spodbudilo nastanek tehnologije skladiščenja informacij ( Skladišče podatkov, DW).

Glavni cilj DW je izdelava enotnega logičnega prikaza podatkov v različnih vrstah baz podatkov ali, z drugimi besedami, enotnega korporativnega podatkovnega modela.

Nov krog razvoja DW je postal mogoč zaradi izboljšanja informacijske tehnologije nasploh, zlasti s pojavom novih vrst baz podatkov, ki temeljijo na vzporedni obdelavi poizvedb, ki se je zanašala na napredek na področju vzporednih računalnikov. Ustvarjeni so bili graditelja poizvedbz intuitivnim grafičnim vmesnikom, ki je olajšal izdelavo zapletenih poizvedb v bazi podatkov. Razna programska opremavmesna programska opremazagotavljal komunikacijomed različnimi vrstami baz podatkov, in nazadnje močno padla cenanaprave za shranjevanje informacij.

Podatkovna banka je lahko prisotna v strukturi korporacije.

Zbirka podatkov - funkcionalna in organizacijska komponenta v avtomatiziranih sistemih vodenja in informacijsko-računalniških sistemih, ki zagotavlja centralizirano informacijsko podporo skupini uporabnikov ali nizu nalog, ki se rešujejo v sistemu.

Zbirka podatkov se obravnava kot informacijski in referenčni sistem, katerega glavni namen je:

pri kopičenju in vzdrževanju v delovnem stanju niza informacij, ki predstavljajo informacijsko bazo celotnega avtomatiziranega sistema ali določenega niza nalog, ki se v njem rešujejo;
pri izdaji podatkov, ki jih zahteva naloga ali uporabnik;
pri zagotavljanju skupnega dostopa do shranjenih informacij;
pri zagotavljanju potrebnega upravljanja uporabe informacij v informacijski bazi.

Tako je sodobna banka podatkov kompleksen programsko-strojni kompleks, ki vključuje tehnična, sistemska in omrežna orodja, baze podatkov in DBMS, sisteme za iskanje informacij za različne namene.

V .2. DBMS IN STRUKTURNE REŠITVE V KORPORATIVNIH SISTEMIH

Baze podatkov in sistemi za upravljanje znanja

Pomemben sestavni del sodobnih informacijskih sistemov so sistemi za upravljanje baz podatkov (DBMS).

DBMS - niz programske opreme in jezikovnih orodij, namenjenih ustvarjanju, vzdrževanju in uporabi baz podatkov.

Sistem za upravljanje baz podatkov omogoča sistemom za obdelavo podatkov dostop do baz podatkov. Kot smo že omenili, pridobiva pomembno vlogo DBMS pri ustvarjanju korporativnih informacijskih sistemov in še posebej pomembno vlogo pri ustvarjanju informacijskih sistemov z uporabo porazdeljenih informacijskih virov, ki temeljijo na sodobnih omrežnih računalniških tehnologijah.

Glavna značilnost sodobnega DBMS je, da sodobni DBMS podpira takšne tehnologije, kot so:

odjemalec/strežniška tehnologija.
Podpora za jezike baze podatkov. tolejezik definicije sheme DB (SDL - jezik definicije sheme),jezik za obdelavo podatkov (DML - Data Manipulation Language), integrirani jeziki SQL (Structured Queue Language), QDB (Query - By - Example) in QMF (Query Management Facility) ) je napredno periferno orodje za specifikacijo poizvedbe in ustvarjanje poročil za DB 2 itd.;
Neposredno upravljanje podatkov v zunanjem pomnilniku.
Upravljanje medpomnilnika.
Upravljanje transakcij. OLTP tehnologija (On-line obdelava transakcij), OLAP - tehnologijo (On-line obdelava analize) za DW.
Zagotovite zaščito in integriteto podatkov. Uporaba sistema je dovoljena le uporabnikom, ki imajo pravico do dostopa do podatkov. Ko uporabniki izvajajo operacije nad podatki, se ohrani doslednost shranjenih podatkov (celovitost). To je pomembno v korporativnih informacijskih sistemih za več uporabnikov.
Novinarjenje.

Sodobni DBMS mora izpolnjevati zgoraj navedene zahteve baze podatkov. Poleg tega morajo upoštevati naslednja načela:

Neodvisnost podatkov.
Vsestranskost. DBMS mora imeti močno podporo za konceptualni podatkovni model za prikaz logičnih pogledov po meri.
Kompatibilnost. DBMS mora ostati operativen z razvojem programske in strojne opreme.
Odvečnost podatkov. Za razliko od datotečnih sistemov mora biti baza podatkov en sam niz integriranih podatkov.
Varovanje podatkov. DBMS mora zagotavljati zaščito pred nepooblaščenim dostopom.
Celovitost podatkov. DBMS mora uporabnikom preprečiti poseganje v bazo podatkov.
Upravljanje sočasnega dela. DBMS mora zaščititi bazo podatkov pred nedoslednostmi v načinu skupnega dostopa. Da bi zagotovili dosledno stanje baze podatkov, je treba vse uporabniške zahteve (transakcije) izvajati v določenem vrstnem redu.
DBMS mora biti univerzalen. Podpirati mora različne podatkovne modele na eni logični in fizični podlagi.
DBMS bi moral podpirati tako centralizirane kot porazdeljene baze podatkov in tako postati pomemben člen v računalniških omrežjih.

Če upoštevamo DBMS kot razred programskih izdelkov, ki se osredotočajo na vzdrževanje baz podatkov v avtomatiziranih sistemih, lahko ločimo dve najpomembnejši lastnosti, ki določata vrste DBMS. Po njihovem mnenju je DBMS mogoče obravnavati z dveh vidikov:

njihove zmogljivosti v zvezi z distribuiranimi (korporativnimi) bazami podatkov;
njihov odnos do vrste podatkovnega modela, implementiranega v DBMS.

V zvezi s korporativnimi (distribuiranimi) bazami podatkov je mogoče konvencionalno razlikovati naslednje vrste DBMS:

DBMS "namizje". Ti izdelki so predvsem usmerjeni v delo z osebnimi podatki (namizni podatki). Imajo nabore ukazov za skupno rabo skupnih baz podatkov, vendar so majhni (tipa majhne pisarne). Najprej gre za DBMS, kot so Access, dBASE, Paradox, ExPro. Zakaj imajo Access, dBASE, Paradox, ExPro slab dostop do podatkov podjetja. Dejstvo je, da ni enostavnega načina za premagovanje ovire med osebnimi in poslovnimi podatki. In bistvo niti ni v tem, da je mehanizem DBMS osebnih podatkov (ali majhne pisarne) osredotočen na dostop do podatkov prek številnih prehodov, izdelkov prehodov itd. Težava je v tem, da ti mehanizmi običajno vključujejo popolne prenose datotek in pomanjkanje obsežne podpore za indekse, kar ima za posledico čakalne vrste do strežnika, ki so v velikih sistemih praktično zaustavitev.
Specializirana visoko zmogljiva večuporabniška DBMS. Za takšne DBMS je značilna prisotnost večuporabniškega sistemskega jedra, jezika za obdelavo podatkov in naslednjih funkcij, ki so značilne za razvite večuporabniške DBMS:
organizacija puferskega bazena;
prisotnost sistema za obdelavo čakalnih vrst transakcij;
prisotnost mehanizmov za blokiranje podatkov za več uporabnikov;
beleženje transakcij;
razpoložljivost mehanizmov za nadzor dostopa.

To so DBMS, kot so Oracle, DВ2, SQL/Server, Informix, Sybase, ADABAS, Titanium in drugi, ki zagotavljajo široko storitev za obdelavo korporativnih baz podatkov.

Pri delu z bazami podatkov se uporablja mehanizem transakcij.

transakcijo je logična enota dela.

transakcijo je zaporedje stavkov za manipulacijo podatkov, ki se izvajakot eno(vse ali nič) in prevajalsko bazo podatkoviz enega integralnega stanja v drugo integralno stanje.

Transakcija ima štiri pomembne lastnosti, znane kot lastnosti ASID:

(A) Atomičnost . Transakcija se izvede kot atomska operacija - bodisi se izvede celotna transakcija bodisi se celotna transakcija ne izvede.
(C) Doslednost. Transakcija premakne bazo podatkov iz enega doslednega (konsistentnega) stanja v drugo dosledno (konsistentno) stanje. Znotraj transakcije se lahko prekine doslednost baze podatkov.
(I) Izolacija . Transakcije različnih uporabnikov ne bi smele ovirati drug drugega (na primer, kot da bi se izvajale strogo po vrsti).
(D) Vzdržljivost. Če je transakcija zaključena, je treba rezultate njenega dela shraniti v bazo podatkov, tudi če se sistem v naslednjem trenutku zruši.

Transakcija se običajno začne samodejno od trenutka, ko se uporabnik pridruži DBMS in se nadaljuje, dokler se ne zgodi eden od naslednjih dogodkov:

Izdan je bil ukaz COMMIT WORK (za objavo transakcije).
Izdan je ukaz ROLLBACK WORK.
Uporabnik je prekinil povezavo z DBMS.
Prišlo je do okvare sistema.

Za uporabnika običajno nosi atomski značaj. Pravzaprav je to zapleten mehanizem interakcije med uporabnikom (aplikacijo) in bazo podatkov. Programska oprema podjetniških sistemov uporablja mehanizem za obdelavo transakcij v realnem času (Spletni sistemi za obdelavo transakcij, OLTP), predvsem računovodski programi, programska oprema za sprejemanje in obdelavo odjemalskih aplikacij, finančne aplikacije, dajejo veliko informacij. Ti sistemi so zasnovani (in ustrezno optimizirani) za obdelavo velikih količin podatkov, zapletene transakcije in intenzivne operacije branja/pisanja.

Žal informacije, ki se nahajajo v bazah podatkov sistemov OLTP, niso zelo primerne za uporabo navadnim uporabnikom (zaradi visoke stopnje normalizacije tabele, specifičnih formatov predstavitve podatkov in drugih dejavnikov). Zato se pošiljajo (v smislu kopiranja) podatki iz različnih informacijskih cevovodov skladiščno skladišče, sortiranje in naknadna dostava potrošniku. V informacijski tehnologiji igrajo vlogo skladiščshramba informacij.

Dostava informacij do končnega uporabnika - vključeni so sistemi analitične obdelave podatkov v realnem času (Spletna analitična obdelava, OLAP), ki zagotavljajo izjemno enostaven dostop do podatkov s pomočjo priročnih orodij za generiranje poizvedb in analizo rezultatov. V sistemih OLAP se vrednost informacijskega produkta povečuje z uporabo različnih metod analize in statistične obdelave. Poleg tega so ti sistemi optimizirani v smislu hitrosti pridobivanja podatkov, zbiranja posplošenih informacij in so osredotočeni na navadne uporabnike (imajo intuitiven vmesnik). Če OLTP sistem daje odgovore na preprosta vprašanja, kot je "kakšna je bila raven prodaje izdelka N v regiji M januarja 199x?", nato OLAP sistemi so pripravljeni na zahtevnejše zahteve uporabnikov, na primer: "Podajte analizo prodaje izdelka N za vse regije po načrtu za drugo četrtletje glede na prejšnji dve leti."

Arhitektura odjemalec/strežnik

V sodobnih sistemih porazdeljena obdelava informacijtehnologija je v središču pozornosti odjemalec/strežnik. V sistemu arhitekture odjemalec-strežnikobdelava podatkov je razdeljena med odjemalski računalnik in strežniški računalnik, med katerima komunikacija poteka prek omrežja. Ta ločitev procesov obdelave podatkov temelji na združevanju funkcij. Običajno je računalnik strežnika baz podatkov namenjen izvajanju operacij baze podatkov, medtem ko odjemalski računalnik izvaja aplikacijske programe. Slika 2.1 prikazuje preprost sistem arhitekture odjemalec-strežnik, ki vključuje računalnik, ki deluje kot strežnik, in drug računalnik, ki deluje kot njegov odjemalec. Vsak stroj opravlja različne funkcije in ima lastne vire.

		Zbirka podatkov
Strežniški računalnik
Mreža
IBM združljiv osebni računalnik	IBM združljiv osebni računalnik	IBM združljiv osebni računalnik
		Aplikacije

riž. 2.1. Arhitekturni sistem odjemalec-strežnik

Glavna funkcija odjemalskega računalnika je zagon aplikacije (uporabniški vmesnik in predstavitvena logika) in komunikacija s strežnikom, ko to zahteva aplikacija.

Strežnik - To je objekt (računalnik), ki zagotavlja storitve drugim objektom na njihovo zahtevo.

Kot pove že izraz, je glavna funkcija strežniškega računalnika služiti potrebam odjemalca. Izraz "strežnik" se uporablja za dve različni skupini funkcij: datotečni strežnik in strežnik baz podatkov (v nadaljevanju ti izrazi pomenijo, odvisno od konteksta, bodisi programsko opremo, ki izvaja te skupine funkcij, bodisi računalnike s to programsko opremo ). Datotečni strežniki niso zasnovani za izvajanje operacij baze podatkov, njihova glavna funkcija je deljenje datotek med več uporabniki, t.j. zagotavlja hkratni dostop več uporabnikov do datotek na računalniku – datotečnem strežniku. Primer datotečnega strežnika je Novellov operacijski sistem NetWare. Strežnik baz podatkov je mogoče namestiti in zagnati na računalniku z datotečnim strežnikom. Oracle DBMS v obliki NLM (Network Loadable Module) deluje v okolju NetWare na datotečnem strežniku.

Strežnik lokalnega omrežja mora imeti sredstva, ki ustrezajo njegovemu funkcionalnemu namenu in potrebam omrežja. Upoštevajte, da je zaradi usmerjenosti v pristop odprtih sistemov pravilneje govoriti o logičnih strežnikih (to pomeni nabor virov in programskih orodij, ki zagotavljajo storitve prek teh virov), ki niso nujno locirani na različnih računalnikih. Značilnost logičnega strežnika v odprtem sistemu je, da če je zaradi učinkovitosti smiselno strežnik premakniti na ločen računalnik, potem je to mogoče storiti brez potrebe po kakršnih koli spremembah, tako samega sebe kot aplikacije. programi, ki ga uporabljajo.

Ena od pomembnih zahtev strežnika je, da mora biti operacijski sistem, v katerem gostuje strežnik baz podatkov, večopravilen (in po možnosti, vendar ne nujno, večuporabniški). Na primer, DBMS Oracle, nameščen na osebnem računalniku z operacijskim sistemom MS-DOS (ali PC-DOS), ki ne izpolnjuje zahtev po večopravilnosti, ni mogoče uporabiti kot strežnik baz podatkov. In isti DBMS Oracle, nameščen v računalniku z večopravilnim (čeprav ne večuporabniškim) operacijskim sistemom OS / 2, je lahko strežnik baz podatkov. Številne različice operacijskih sistemov UNIX, MVS, VM in nekaterih drugih operacijskih sistemov so večopravilne in večuporabniške.

Porazdeljeno računalništvo

Izraz "distribuirano računalništvo" se pogosto uporablja za označevanje dveh različnih, čeprav komplementarnih konceptov:

Porazdeljena baza podatkov;
Porazdeljena obdelava podatkov.

Uporaba teh konceptov omogoča, da končnim uporabnikom z različnimi sredstvi organizirajo dostop do informacij, shranjenih na več računalnikih.

Obstaja veliko vrst strežnikov:

Strežnik baz podatkov;
Tiskalni strežnik;
Strežnik za oddaljeni dostop;
faks strežnik;
Spletni strežnik itd.

V jedru tehnologije odjemalec/strežnik Obstajajo takšne osnovne tehnologije, kot so:

Tehnologije operacijskih sistemov, koncept interakcije odprtih sistemov, ustvarjanje objektno usmerjenih okolij za delovanje programov;
Telekomunikacijske tehnologije;
Omrežne tehnologije;
Tehnologije grafičnega uporabniškega vmesnika ( GUI);
itd.

Prednosti tehnologije odjemalec-strežnik:

Tehnologija odjemalec/strežnik omogoča računanje v heterogenih računalniških okoljih. Neodvisnost od platforme: dostop do heterogenih omrežnih okolij, ki vključujejo različne vrste računalnikov z različnimi operacijskimi sistemi.
Neodvisnost od podatkovnih virov: dostop do informacij iz heterogenih baz podatkov. Primeri takšnih sistemov so DB2, SQL/DS, Oracle, Sybase.
Ravnotežje obremenitve med odjemalcem in strežnikom.
Izvajanje izračunov tam, kjer je to najbolj učinkovito;
Zagotavlja učinkovito zmožnost skaliranja;
Medplatformsko računalništvo. Večplatformsko računalništvo je preprosto definirano kot implementacija tehnologij v heterogenih računalniških okoljih. Tukaj je treba navesti naslednje možnosti:
Aplikacija mora delovati na več platformah;
Na vseh platformah mora imeti enak vmesnik in logiko dela;
Aplikacija se mora integrirati z domačim operacijskim okoljem;
Na vseh platformah bi se moral obnašati enako;
Imeti mora preprosto in dosledno podporo.

 Porazdeljeno računalništvo. Porazdeljeno računalništvo zagotavlja porazdelitev dela med več računalniki (čeprav je porazdeljeno računalništvo širši pojem).

 Zmanjšanje velikosti. Downscaling je prenos velikih računalniških aplikacij na majhne računalniške platforme.

Zmanjšajte stroške infrastrukture in strojne opreme. Stroškovno učinkovito: zaradi razpoložljivosti poceni računalniške strojne opreme in vse večje razširjenosti lokalnih omrežij je tehnologija odjemalec-strežnik stroškovno učinkovitejša od drugih tehnologij za obdelavo podatkov. Opremo je mogoče po potrebi nadgraditi.

 Zmanjšanje celotnega časa izvajanja aplikacije;

 Zmanjšana poraba pomnilnika odjemalca;

 Zmanjšanje omrežnega prometa.

Sposobnost dela z večpredstavnostjo: Do danes je bilo ustvarjenih veliko programov za delo z večpredstavnostjo za osebne računalnike. Takih programov za konfiguracijo terminal-gostitelj bodisi ni ali pa so zelo dragi.
Možnost uporabe več računalniških virov za operacije baze podatkov: ker se aplikacije izvajajo na odjemalskih računalnikih, se dodatni (v primerjavi s konfiguracijo terminal-gostitelj) sprostijo na strežniškem računalniku za operacije baze podatkov, kot so CPE in operativni viri.
Povečana produktivnost programerja: produktivnost programerja se poveča z uporabo orodij, kot sta SQL*Forms in CASE, za razvoj aplikacij hitreje kot programski jeziki, kot so C, PL1 ali COBOL.
Povečanje produktivnosti končnih uporabnikov: Dandanes je veliko končnih uporabnikov sprejelo sisteme, kot so Lotus, Paradox, Word Perfect, Harvard Graphics itd.

Zadnji vmesnik je definiran in popravljen. Zato je mogoče ustvariti nove odjemalske dele obstoječega sistema (primer interoperabilnosti na sistemski ravni).

riž. 2.2. Ilustracija dostopa odjemalca do skupne rabe strežnika.

Kako implementirati tehnologijo odjemalec-strežnik

Spodaj je obravnavana namestitev sistema, ki temelji na tehnologiji odjemalec-strežnik in je sposoben porazdeljene obdelave podatkov. Potrebna je naslednja računalniška strojna in programska oprema:

Računalnik strežnika baz podatkov;
odjemalski računalniki;
komunikacijsko omrežje;
omrežna programska oprema;
aplikacijska programska oprema.

jezik SQL . Jezik poizvedbe na visoki ravni - SQL (Structured Query Language ) se uporablja za izvajanje poizvedb v baze podatkov, kot so NMD, NDL in PJD, in je bil sprejet kot standard. Jezik SQL je bil prvotno sprejet kot podatkovni jezik programskih izdelkov podjetja IBM in YMD relacijskega DBMS SYSTEM R podjetja IBM . Pomembna lastnost jezika SQL je, da je isti jezik predstavljen prek dveh različnih vmesnikov, in sicer: prek interaktivnega vmesnika in prek aplikacijskega programskega vmesnika (dinamičnega SQL). Dinamični SQL je sestavljen iz številnih vgrajenih jezikovnih funkcij SQL , na voljo posebej za izdelavo interaktivnih aplikacij, kjer je interaktivna aplikacija program, ki je napisan tako, da podpira dostop do baze podatkov s strani končnega uporabnika, ki teče na interaktivnem terminalu. Jezik SQL zagotavlja funkcije definiranja, manipuliranja in upravljanja podatkov baze podatkov in je pregleden za uporabnika z vidika implementirane DBMS.

riž. 2.3. Shema za izvajanje zahtev uporabnikov do porazdeljenih baz podatkov.

Notranjo strukturo podatkovnih baz določajo uporabljeni podatkovni modeli. Konceptualni model ima več abstrakcijskih zmogljivosti in bogatejšo semantiko kot zunanji modeli. Zunanji modeli se pogosto imenujejo skladenjski ali operativni modeli, ki se nanašajo na sintaktično naravo upravljanja in aplikacije kot sredstva uporabniške interakcije z bazo podatkov. Pri informacijskem modeliranju obstajajo različne ravni abstrakcije, od ravni konceptualnega modela do ravni fizičnega podatkovnega modela, ki vplivajo na arhitekturo DBMS.

Podatkovni model je sestavljen iz treh komponent:

Podatkovna struktura, ki bo predstavljena v zbirki podatkov z vidika uporabnika.
Veljavne operacije, ki jih je treba izvesti na podatkovni strukturi. Treba je znati delati s to strukturo z uporabo različnih operacij DDL in NML. Bogata struktura je ničvredna, če ne morete manipulirati z njeno vsebino.
Omejitve za nadzor integritete. Podatkovnemu modelu je treba zagotoviti sredstva za ohranjanje njegove celovitosti in zaščito. Kot primer upoštevajte naslednji dve omejitvi:
Vsako poddrevo mora imeti izvorno vozlišče. Hierarhične baze podatkov ne morejo shraniti podrejenih vozlišč brez nadrejenega vozlišča.
V zvezi z relacijsko bazo podatkov ne more biti identičnih nizov. Za datoteko ta zahteva zahteva, da so vsi zapisi edinstveni.

Ena najpomembnejših značilnosti DBMS je zmožnost povezovanja objektov.

Obstajajo naslednje vrste povezav med predmeti:

ena proti ena (1:1). En predmet enega niza je lahko povezan z enim objektom drugega niza.
Eden proti več (1:M). En predmet enega niza je lahko povezan z več predmeti drugega niza.
Mnogi proti mnogim (M:N). En objekt enega niza je lahko povezan z več predmeti drugega niza, hkrati pa je lahko en objekt drugega niza povezan z mnogimi objekti prvega niza.
razvejano . En predmet enega niza je lahko povezan s predmeti iz več množic.
Rekurzivno . En predmet določenega niza je lahko povezan z objektom istega niza.

Obstajajo naslednji glavni podatkovni modeli:

Relacijski podatkovni model.
Hierarhični podatkovni model.
Nepopoln omrežni podatkovni model.
Podatkovni model CODASYL.
Razširjeni omrežni podatkovni model.

V.3. INTERNET/INTRANETNE TEHNOLOGIJE IN REŠITVE ZA DOSTOP BAZA PODATKOV PODATKOV PODATKOV PODJETJA

Glavna težava sistemov, ki temeljijo na arhitekturi odjemalec-strežnik, je v tem, da morajo biti v skladu s konceptom odprtih sistemov mobilni v najširšem možnem razredu strojnih in programskih rešitev odprtih sistemov. Tudi če se omejimo na lokalna omrežja, ki temeljijo na UNIX, različna omrežja uporabljajo različno opremo in komunikacijske protokole. Poskus ustvarjanja sistemov, ki podpirajo vse možne protokole, vodi do njihove preobremenjenosti s podrobnostmi omrežja na račun funkcionalnosti.

Še bolj zapleten vidik tega problema je povezan z možnostjo uporabe različnih predstavitev podatkov v različnih vozliščih heterogenega lokalnega omrežja. Različni računalniki imajo lahko različno naslavljanje, predstavitev številk, kodiranje znakov itd. To je še posebej pomembno za strežnike na visoki ravni: telekomunikacije, računalništvo, baze podatkov.

Pogosta rešitev problema mobilnosti sistemov, ki temeljijo na arhitekturi "odjemalec-strežnik", je zanašanje na programske pakete, ki izvajajo protokole za klic na daljavo (RPC - Remote Procedure Call). Z uporabo teh orodij je klicanje storitve na oddaljenem gostitelju videti kot običajen klic postopka. Orodja RPC, ki seveda vsebujejo vse informacije o posebnostih lokalne omrežne opreme in omrežnih protokolov, klic prevedejo v zaporedje omrežnih interakcij. Tako so posebnosti omrežnega okolja in protokolov skrite aplikacijskemu programerju.

Ko pokličete oddaljeno proceduro, programi RPC pretvorijo formate podatkov odjemalca v vmesne, strojno neodvisne formate in nato pretvorijo v formate strežniških podatkov. Pri posredovanju parametrov odziva se izvedejo podobne transformacije.

Druga sorodna dela, ki bi vas lahko zanimala.vshm>
6914.		Koncept baze podatkov	11,56 KB
	Baza podatkov je niz neodvisnih gradiv, predstavljenih v objektivni obliki členov za izračun normativnih aktov sodnih odločb in drugih podobnih materialov, sistematiziranih tako, da je ta gradiva mogoče najti in obdelati z uporabo elektronskega računalnika Civilnega zakonika Ruske federacije. Umetnost. Baza podatkov, organizirana v skladu z določenimi pravili in vzdrževana v pomnilniku računalnika, niz podatkov, ki označujejo trenutno stanje nekaterih ...
8064.		Porazdeljene baze podatkov	43,66 KB
	Porazdeljene baze podatkov Porazdeljena baza podatkov RDB je niz logično povezanih skupnih podatkov, ki so fizično porazdeljeni po različnih vozliščih računalniškega omrežja. Dostop do podatkov ne bi smel biti odvisen od prisotnosti ali odsotnosti replik podatkov. Sistem bi moral samodejno določiti metode za izvedbo združevanja podatkov, omrežno povezavo, ki je sposobna obdelati količino informacij, ki se prenašajo, in vozlišče z zadostno procesorsko močjo za združevanje tabel. RDBMS mora biti sposoben ...
20319.		BAZE PODATKOV IN NJIHOVA ZAŠČITA	102,86 KB
	Spletne spletne baze podatkov so se pojavile sredi šestdesetih let prejšnjega stoletja. Operacije z operativnimi bazami podatkov so bile obdelane interaktivno s pomočjo terminalov. Enostavna indeksno zaporedna organizacija zapisov se je hitro razvila v zmogljivejši model zapisov, usmerjen v niz. Charles Bachmann je prejel Turingovo nagrado za vodenje dela skupine Data Base Task Group (DBTG), ki je razvila standardni jezik za opisovanje podatkov in manipulacijo s podatki.
5031.		Knjižnica za razvoj baze podatkov	11,72 MB
	Tehnologija oblikovanja baz podatkov. Definiranje odnosov med entitetami in izdelava podatkovnega modela. Glavne ideje sodobne informacijske tehnologije temeljijo na konceptu, da je treba podatke organizirati v baze podatkov, da bi ustrezno odražali spreminjajoči se realni svet in zadostili informacijskim potrebam uporabnikov. Te baze podatkov se ustvarjajo in upravljajo pod nadzorom posebne programske opreme, imenovane sistemi za upravljanje baz podatkov DBMS.
13815.		HIERARHIČNI MODEL BAZE PODATKOV	81,62 KB
	Glavne ideje sodobne informacijske tehnologije temeljijo na konceptu baz podatkov, po katerem so osnova informacijske tehnologije podatki, organizirani v baze podatkov, ki ustrezno odražajo stanje posameznega predmetnega področja in uporabniku zagotavljajo relevantne informacije na tem predmetnem področju. Treba je priznati, da so podatki ...
14095.		Razvoj knjižnične baze podatkov	11,72 MB
	Povečanje obsega in strukturne kompleksnosti shranjenih podatkov, širitev kroga uporabnikov informacijskih sistemov so privedli do široke uporabe najbolj priročne in razmeroma lahko razumljive relacijske (tabelarne) DBMS.
5061.		Izdelava poliklinične baze podatkov	2,4 MB
	Razvoj računalniške in informacijske tehnologije je omogočil ustvarjanje in široko uporabo avtomatiziranih informacijskih sistemov (AIS) za različne namene. Razvijajo se in izvajajo informacijski sistemi za upravljanje gospodarskih in tehničnih objektov
13542.		Baze geoloških informacij	20,73 KB
	V zadnjem času se uvajanje računalniških tehnologij in zlasti podatkovnih zbirk v znanstveno sfero zelo hitro odvija. Ta proces ne zaobide niti geologije, saj je v naravoslovju potrebno shraniti in obdelati velike količine informacij.
9100.		Zbirka podatkov. Osnovni koncepti	26,28 KB
	Baza podatkov je zbirka informacij o določenih predmetih resničnega sveta na katerem koli predmetnem področju, ekonomiji, menedžmentu, kemiji itd. Namen informacijskega sistema ni samo shranjevanje podatkov o predmetih, temveč tudi manipuliranje s temi podatki, pri čemer upoštevati razmerja med predmeti. Za vsak objekt je značilen nabor podatkovnih lastnosti, ki se v bazi podatkov imenujejo atributi.
5240.		Izdelava baze podatkov "Dekanat univerze"	1,57 MB
	Baza podatkov (DB) je zbirka med seboj povezanih podatkov, shranjenih skupaj na zunanjih pomnilniških medijih računalnika s takšno organizacijo in minimalno redundanco, ki omogoča njihovo optimalno uporabo za eno ali več aplikacij.

Panožni podatkovni modeli

Glavni namen modelov je olajšati orientacijo v podatkovnem prostoru in pomagati pri poudarjanju podrobnosti, ki so pomembne za razvoj poslovanja. V današnjem poslovnem okolju je nujno jasno razumevanje odnosov med različnimi komponentami in dobro razumevanje celotne slike organizacije. Prepoznavanje vseh podrobnosti in odnosov z uporabo modelov omogoča najučinkovitejšo uporabo časa in orodij za organizacijo dela podjetja.

Podatkovni model enolično definira pomen podatkov, ki so v tem primeru strukturirani podatki (v nasprotju z nestrukturiranimi podatki, kot so slika, binarna datoteka ali besedilo, kjer je vrednost lahko dvoumna).

Praviloma se razlikujejo modeli višje ravni (in vsebinsko bolj splošne) in nižje ravni (oziroma bolj podrobni). Zgornja raven modeliranja je t.i konceptualni podatkovni modeli(konceptualni podatkovni modeli), ki dajejo najbolj splošno sliko delovanja podjetja ali organizacije. Konceptualni model vključuje glavne koncepte ali predmetna področja, ki so kritična za delovanje organizacije; običajno njihovo število ne presega 12-15. Tak model opisuje razrede entitet, pomembnih za organizacijo (poslovni objekti), njihove značilnosti (atribute) in povezave med pari teh razredov (tj. razmerja). Ker terminologija v poslovnem modeliranju še ni povsem ustaljena, lahko v različnih angleških virih konceptualne modele podatkov imenujemo tudi model predmetnega področja (ki ga lahko prevedemo kot modeli predmetnega področja) ali predmetni model podjetja (predmetni korporativni podatkovni modeli). ).

Naslednja hierarhična raven je logični podatkovni modeli(logični podatkovni modeli). Lahko jih imenujemo tudi modeli podatkov podjetja ali poslovni modeli. Ti modeli vsebujejo podatkovne strukture, njihove atribute in poslovna pravila ter predstavljajo informacije, ki jih podjetje uporablja s poslovnega vidika. V takem modelu so podatki organizirani v obliki entitet in odnosov med njimi. Logični model predstavlja podatke na način, ki ga poslovni uporabniki zlahka razumejo. V logičnem modelu je mogoče dodeliti podatkovni slovar – seznam vseh entitet z njihovimi natančnimi definicijami, kar omogoča različnim kategorijam uporabnikov, da imajo skupno razumevanje vseh vhodnih in informacijskih izhodnih tokov modela. Naslednja, nižja stopnja modeliranja je že fizična izvedba logičnega modela z uporabo specifičnih programskih orodij in tehničnih platform.

Logični model vsebuje podrobno poslovno odločitev podjetja, ki je običajno v obliki normaliziranega modela. Normalizacija je proces, ki zagotavlja, da ima vsak podatkovni element v modelu samo eno vrednost in je popolnoma in edinstveno odvisen od primarnega ključa. Podatkovni elementi so organizirani v skupine glede na njihovo edinstveno identifikacijo. Poslovna pravila, ki nadzorujejo podatkovne elemente, morajo biti v celoti vključena v normalizirani model s predhodnim preverjanjem njihove veljavnosti in pravilnosti. Na primer, podatkovni element, kot je ime stranke, bi bil najverjetneje razdeljen na ime in priimek ter združen z drugimi ustreznimi podatkovnimi elementi v entiteto stranke s primarnim ključem ID-ja stranke.

Logični podatkovni model je neodvisen od aplikacijskih tehnologij, kot so baze podatkov, omrežna orodja ali orodja za poročanje in njihova fizična implementacija. Organizacija ima lahko samo en podatkovni model podjetja. Logični modeli običajno vključujejo na tisoče entitet, odnosov in atributov. Na primer, podatkovni model za finančno institucijo ali telekomunikacijsko podjetje lahko vsebuje približno 3000 industrijskih konceptov.

Pomembno je razlikovati med logičnim in semantičnim podatkovnim modelom. Logični podatkovni model predstavlja korporativno poslovno rešitev, semantični podatkovni model pa uporabno poslovno rešitev. Isti korporativni logični podatkovni model je mogoče implementirati z uporabo različnih semantičnih modelov, t.j. semantične modele lahko obravnavamo kot naslednjo raven modeliranja, ki se približuje fizičnim modelom. Poleg tega bo vsak od teh modelov predstavljal ločeno »rezino« korporativnega podatkovnega modela v skladu z zahtevami različnih aplikacij. Na primer, v korporativnem logičnem podatkovnem modelu bo entiteta Client popolnoma normalizirana, v semantičnem modelu za podatkovni trg pa jo lahko predstavimo kot večdimenzionalno strukturo.

Podjetje ima lahko dva načina za ustvarjanje logičnega podatkovnega modela podjetja: ga zgradite sami ali uporabite že pripravljen industrijski model(industrijski logični podatkovni model). V tem primeru razlike v terminih odražajo le različne pristope k izgradnji istega logičnega modela. V primeru, da podjetje samostojno razvija in izvaja svoj logični podatkovni model, se tak model praviloma imenuje preprosto korporativni logični model. Če se organizacija odloči za uporabo končnega izdelka profesionalnega dobavitelja, potem lahko govorimo o industrijskem logičnem podatkovnem modelu. Slednji je že pripravljen logični podatkovni model, ki z visoko stopnjo natančnosti odraža delovanje določene panoge. Industrijski logični model je domensko specifičen in integriran pogled na vse informacije, ki morajo biti v podatkovnem skladišču podjetja, da se odgovori tako na strateška kot taktična poslovna vprašanja. Kot kateri koli drugi logični podatkovni model tudi industrijski model ni odvisen od aplikacijskih rešitev. Prav tako ne vključuje izpeljanih podatkov ali drugih izračunov za hitrejše pridobivanje podatkov. Praviloma večina logičnih struktur takšnega modela najde dobro utelešenje v njegovi učinkoviti fizični izvedbi. Takšne modele razvijajo številni prodajalci za najrazličnejša področja: finance, proizvodnja, turizem, zdravstvo, zavarovalništvo itd.

Panožni logični podatkovni model vsebuje informacije, ki so skupne industriji in zato ne more biti popolna rešitev za podjetje. Večina podjetij mora model povečati za povprečno 25 % z dodajanjem podatkovnih elementov in razširitvijo definicij. Končni modeli vsebujejo le ključne podatkovne elemente, ostale elemente pa je treba med vgradnjo modela v podjetje dodati ustreznim poslovnim objektom.

Industrijski logični podatkovni modeli vsebujejo veliko število abstrakcij. Abstrakcija se nanaša na združitev podobnih konceptov pod skupnimi imeni, kot sta dogodek ali udeleženec. To industrijskim modelom doda fleksibilnost in jih naredi bolj poenotene. Tako je koncept dogodka uporaben za vse panoge.

Strokovnjak za poslovno obveščanje Steve Hoberman opisuje pet dejavnikov, ki jih je treba upoštevati pri odločanju o nakupu industrijskega podatkovnega modela. Prvi je čas in sredstva, potrebna za izdelavo modela. Če mora organizacija hitro doseči rezultate, bo industrijski model dal prednost. Uporaba industrijskega modela morda ne bo takoj zagotovila slike celotne organizacije, vendar lahko prihrani precej časa. Namesto dejanskega modeliranja bo čas porabljen za povezovanje obstoječih struktur z industrijskim modelom, pa tudi za razpravo o tem, kako ga najbolje prilagoditi potrebam organizacije (na primer, katere definicije je treba spremeniti in katere podatkovne elemente je treba dodati).

Drugi dejavnik je čas in denar, ki sta potrebna za vzdrževanje modela. Če podatkovni model podjetja ni del metodologije, ki ga ohranja natančno in posodobljeno, model zelo hitro zastari. Panožni podatkovni model lahko prepreči to tveganje, saj ga posodabljajo zunanji viri. Seveda se mora spremembe, ki se dogajajo v organizaciji, v modelu odražati samo podjetje, vendar pa bo spremembe v panogi v modelu reproduciral njegov dobavitelj.

Tretji dejavnik so izkušnje pri ocenjevanju in modeliranju tveganja. Ustvarjanje podatkovnega modela podjetja zahteva usposobljene vire tako poslovnega kot IT osebja. Vodje praviloma dobro poznajo bodisi delo organizacije kot celote bodisi dejavnosti posameznega oddelka. Malo jih ima tako široko (v celotnem podjetju) kot globoko (v celotni enoti) znanje o svojem poslovanju. Večina menedžerjev običajno dobro pozna samo eno področje. Zato so za pridobitev celotne družbene slike potrebna znatna poslovna sredstva. S tem se povečajo tudi zahteve za osebje IT. Več poslovnih virov je potrebnih za ustvarjanje in testiranje modela, bolj izkušeni morajo biti analitiki. Ne samo, da morajo znati pridobiti informacije od poslovnega osebja, temveč morajo biti sposobni najti skupni jezik na spornih področjih in biti sposobni vse te informacije predstaviti na celosten način. Tisti, ki ustvarja model (v mnogih primerih je to isti analitik), mora imeti dobre veščine modeliranja. Ustvarjanje modelov korporativne logike zahteva modeliranje "za prihodnost" in sposobnost pretvorbe kompleksnega podjetja v dobesedno "kvadrate in črte".

Po drugi strani pa industrijski model omogoča uporabo izkušenj strokovnjakov tretjih oseb. Logični modeli, specifični za industrijo, uporabljajo preizkušene metodologije modeliranja in ekipe izkušenih strokovnjakov, da se izognejo pogostim in dragim težavam, ki se lahko pojavijo pri razvoju podatkovnih modelov podjetja v organizaciji.

Četrti dejavnik je obstoječa infrastruktura aplikacij in odnosi s prodajalci. Če organizacija že uporablja veliko orodij istega ponudnika in ima z njimi vzpostavljene odnose, je smiselno pri njih naročiti tudi industrijski model. Tak model bo lahko prosto deloval z drugimi izdelki istega dobavitelja.

Peti dejavnik je izmenjava informacij znotraj panoge. Če mora podjetje podatke deliti z drugimi organizacijami, ki delujejo na istem področju, je lahko industrijski model v tej situaciji zelo koristen. Organizacije znotraj iste panoge uporabljajo podobne strukturne komponente in terminologijo. Dandanes so podjetja v večini panog prisiljena deliti podatke za uspešno vodenje svojega poslovanja.

Industrijski modeli, ki jih ponujajo profesionalni prodajalci, so najučinkovitejši. Visoka učinkovitost njihove uporabe je dosežena zaradi znatne stopnje podrobnosti in natančnosti teh modelov. Običajno vsebujejo veliko podatkovnih atributov. Poleg tega imajo ustvarjalci teh modelov ne le bogate izkušnje z modeliranjem, ampak so tudi dobro seznanjeni z izdelavo modelov za določeno industrijo.

Panožni podatkovni modeli podjetjem zagotavljajo enoten integriran pogled na njihove poslovne informacije. Številna podjetja težko integrirajo svoje podatke, čeprav je to predpogoj za večino projektov v celotnem podjetju. Glede na študijo The Data Warehousing Institute (TDWI) je več kot 69 % anketiranih organizacij ugotovilo, da je integracija pomembna ovira za sprejemanje novih aplikacij. Nasprotno, implementacija integracije podatkov podjetju prinaša znaten dohodek.

Industrijski podatkovni model, poleg povezave z obstoječimi sistemi, zagotavlja velike prednosti za projekte v celotnem podjetju, kot so načrtovanje virov podjetja (ERP), upravljanje glavnih podatkov, poslovna inteligenca, izboljšanje kakovosti podatkov in razvoj zaposlenih.

Tako so industrijski logični podatkovni modeli učinkovito orodje za integracijo podatkov in pridobivanje celostne slike podjetja. Zdi se, da je uporaba logičnih modelov nujen korak k oblikovanju korporativnih podatkovnih skladišč.

Publikacije

Steve Hoberman. Izkoristite industrijski logični podatkovni model kot vaš podatkovni model podjetja
Claudia Imhoff. Projekti shranjevanja podatkov in poslovne inteligence s hitrim sledenjem prek inteligentnega modeliranja podatkov

Ta članek se bo osredotočil na arhitekturo podatkovnih skladišč. Na kaj se je treba ravnati pri gradnji, kateri pristopi delujejo - in zakaj.

"Pravljica je laž - vendar je v njej namig ..."

Dedek je posadil ... skladišče. In skladišče je postajalo veliko in veliko. Preprosto nisem vedela, kako je delovalo. In dedek je začel pregled. Dedek je poklical babico, vnukinjo, mačko in miško na družinski svet. In pove naslednjo temo: »Naše skladišče se je povečalo. Podatki iz vseh sistemov se kopičijo, tabele so vidne in nevidne. Uporabniki pripravljajo svoja poročila. Zdi se, da je vse v redu - živeti in živeti. Ja, samo ena žalost - nihče ne ve, kako deluje. Potrebuje diske navidezno-nevidno - ne boste dobili dovolj! In potem so uporabniki, ki prihajajo k meni z različnimi pritožbami: bodisi poročilo zamrzne, bodisi so podatki zastareli. In včasih je to kar katastrofa - prihajamo s poročili carju-očetu, vendar se številke med seboj ne ujemajo. Ura še ni - kralj se bo jezil - potem si ne ruši glave - ne meni ne tebi. Zato sem se odločil, da vas zberem in se posvetujem: kaj bomo naredili?

Pogledal je nad skupščino in vprašal:
- Tukaj si, babica, veš, kako je urejeno naše skladišče?
- Ne, dedek, ne vem. In kako naj vem? Tam, kakšni pogumni fantje ga čuvajo! Nekaj brkov! Ne stopi. Šla sem jih nekako obiskat, spekla pite. In pojedli so pite, si obrisali brke in rekli: »Zakaj si prišla, babica? Kakšna je vaša shramba? Povejte nam, kakšno poročilo potrebujete - mi ga bomo naredili za vas! Najpomembneje je, da pogosteje prinesete pite! Boleče, imajo slasten okus."
- In ti, moja ljubljena vnukinja, ali veš, kako je urejeno naše skladišče?
- Ne, dedek, ne vem. Omogočil mi je dostop do njega. Povezal sem se, pogledam - in tam so mize - očitno nevidne. In različne sheme so skrite. Oči se razširijo.... Sprva sem bil zmeden. In potem sem natančno pogledal - nekatere so prazne, druge so napolnjene, a le napol. Prav tako se zdi, da se podatki ponavljajo. Ni čudno, da se ne morete založiti z diski s tako redundanco!
- No, ti, mačka, kaj lahko rečeš o našem skladišču? Je v njem kaj dobrega?
- Ja, kako ne bi rekel, dedek - bom rekel. Na željo svoje vnukinje sem poskusil narediti pilotnega pilota v ločeni shemi - majhno vitrino. Da bi razumeli, kakšna trgovina je koristna za našo državo - kateri izdelki so dobri za trgovce, plačajo poklon - se zakladnica napolni. In kateri so slabi. In začel sem pobirati podatke iz tega skladišča. Zbrana dejstva. In začel jih je poskušati primerjati z izdelki. In kaj, dedek, sem videl - zdi se, da so izdelki enaki, a če pogledaš znake - so različni! Nato sem jih začela česati z glavnikom svoje vnukinje. Praskal je, praskal - in pripeljal do določene enotnosti, božal oko. Toda zgodaj sem se razveselil - naslednji dan sem zagnal svoje skripte za posodobitev čudovitih podatkov v oknu - in vse je minilo zame! "Kako to?" - Mislim, - se bo razburila vnukinja - danes bi bilo treba našega pilota pokazati ministru. Kako se tega lotimo – s takšnimi podatki?
- Ja, žalostne zgodbe, mačka, ti povej. No, ti, mala miška, ali res nisi poskušal izvedeti za trezor? Ti si živahna, okretna, družabna punca! Kaj nam boš povedal?
- Ja, kako, dedek, ne poskušaj - seveda sem tiha miška, a okretna. Mačka vnukinja je nekako zahtevala podatkovni model našega državnega repozitorija, da ga dobi. In mačka je seveda prišla k meni - nate, pravi miška, vse upanje! No, kaj dobrega dela dobri ljudje (in mačke) ne zmorejo? Šel sem na grad, kjer vodja odlagališča podatkovni model skriva v sefu. In skrila. Čakal sem, da vzame ta model iz sefa. Takoj, ko je šel ven na kavo - sem skočila na mizo. Pogledam model - ničesar ne razumem! Kako to? Ne prepoznam našega trezorja! Imamo nešteto na tisoče tabel, podatkov - neutrudnih tokov! In tukaj - vse je harmonično in lepo ... Pogledal je ta model - in ga dal nazaj v sef.
- Ja, zelo čudne stvari, si nam povedala, miška.
Dedek je močno razmišljal.
Kaj naj storimo, prijatelji? Konec koncev, s takšnim skladiščem ne boste dolgo živeli ... Uporabniki bodo kmalu popolnoma izgubili potrpljenje.

Karkoli se odloči naš dedek iz pravljice - zgraditi novo skladišče ali poskusiti reanimirati obstoječega - moramo narediti zaključke, preden spet "zavihamo rokave".
Pustimo ob strani organizacijske vidike – kot so nevarnost osredotočanja strokovnega znanja v neko ozko zaprto skupino, pomanjkanje nadzornih procesov in zagotavljanje preglednosti arhitekture sistemov, ki se uporabljajo v podjetju, itd.
Danes bi se rad osredotočil na gradnjo arhitekture določenega sistema (ali skupine sistemov) – podatkovnih skladišč. Na kaj je treba najprej osredotočiti pozornost, ko organizacija začne graditi tako zapleten in drag sistem, kot je shranjevanje.

Posvetovanje

Nihče od nas, ki delamo na ustvarjanju in razvoju katerega koli sistema, si ne želi, da bi bila to »začasna hiša« ali rešitev, ki bo v letu ali dveh »odmrla«, ker. ne bodo mogli izpolniti zahtev in pričakovanj strank in podjetij. Ne glede na to, kako močan je premik k »fleksibilnim metodologijam« danes, je človeku veliko bolj prijetno, da se počuti kot »mojster«, ki izdeluje violine, kot pa obrtnik, ki izrezuje palice za bobne za enkratno uporabo.
Naš namen se sliši naravno: izdelati sisteme, ki so trdni in kakovostni, ki od nas ne bodo zahtevali rednega "nočnega bdenja z datoteko", česar se ne bomo sramovali pred končnimi uporabniki in ki ne bo videti kot »črno skrinjico« vsem »neposvećenim« sledilcem.

Najprej naštejmo tipične težave, s katerimi se redno srečujemo pri delu s shrambami. Zapišimo, kaj imamo – do sedaj, ne da bi poskušali racionalizirati in formalizirati.

Načeloma imamo dobro shranjevanje: če se ga ne dotaknete, potem vse deluje. Res je, takoj ko je potrebna sprememba, se začnejo "lokalni kolapsi".
Podatki se nalagajo dnevno, po predpisih, v enem velikem procesu, v 8 urah. In to nam ustreza. Če pa nenadoma pride do okvare, je za to potrebno ročno posredovanje. In potem lahko vse dolgo deluje nepredvidljivo, ker. v procesu je potrebno človeško sodelovanje.
Zavila sprostitev - pričakujte težave.
Nek en vir podatkov ni mogel dati pravočasno - vsi procesi čakajo.
Celovitost podatkov je pod nadzorom baze podatkov – zato se naši procesi zrušijo, ko je pokvarjena.
Imamo zelo veliko shrambo - 2000 tabel v eni skupni shemi. In še 3000 v mnogih drugih shemah. Kako so urejene in iz kakšnega razloga so se pojavile, že nimamo pojma. Zato nam je lahko težko nekaj ponovno uporabiti. In veliko težav je treba ponovno rešiti. Ker, je lažje in hitreje (kot razumeti "v kodi nekoga drugega"). Posledično imamo neskladja in podvojene funkcionalnosti.
Pričakujemo, da bo vir zagotovil kakovostne podatke. A izkaže se, da temu ni tako. Posledično porabimo veliko časa za usklajevanje naših končnih poročil. In pri tem so bili zelo uspešni. Imamo celo poenostavljen postopek. Res je, potreben je čas. Toda uporabniki so navajeni ...
Uporabnik ne zaupa vedno našim poročilom in zahteva utemeljitev za določeno številko. V nekaterih primerih ima prav, v drugih pa se moti. Vendar jih je zelo težko utemeljiti, ker ne zagotavljamo sredstev za "analizo od konca do konca" (ali podatkovne linije).
Lahko bi pritegnili dodatne razvijalce. Imamo pa problem – kako jih spremeniti v delo? Kateri je najučinkovitejši način za vzporedno delo?
Kako razvijati sistem postopoma, ne da bi se celo leto spuščali v razvoj »jedra sistema«?
Podatkovno skladišče je povezano s korporativnim modelom. Zagotovo pa vemo (videli smo to v banki XYZ), da je mogoče graditi model v nedogled (v banki XYZ smo šest mesecev hodili naokoli in razpravljali o poslovnih subjektih, brez premika). Zakaj sploh je? Ali pa je morda bolje brez nje, če je z njo toliko težav? Mogoče ga nekako ustvarite?
Odločili smo se, da vodimo model. Toda kako sistematično razviti podatkovni model skladišča? Ali potrebujemo "pravila igre" in kakšna so lahko? Kaj nam bo dalo? Kaj pa, če se zmotimo z modelom?
Ali naj shranimo podatke ali zgodovino njihovih sprememb, če jih "podjetje ne potrebuje"? Ne bi rad "shranjeval smeti" in kompliciral pri uporabi teh podatkov za resnična opravila. Ali naj trezor hrani zgodovino? kakšen je? Kako shranjevanje sčasoma deluje?
Ali je treba poskušati poenotiti podatke v hrambi, če imamo sistem upravljanja NSI? Če obstaja MDM, ali to pomeni, da je zdaj rešen celoten problem z glavnimi podatki?
Kmalu naj bi zamenjali ključne računovodske sisteme. Ali bi morala biti shramba podatkov pripravljena na spremembo vira? Kako to doseči?
Ali potrebujemo metapodatke? Kaj naj razumemo s tem? Kje točno jih je mogoče uporabiti? Kako se lahko izvaja? Ali jih je treba hraniti "na enem mestu"?
Naše stranke so v svojih zahtevah in željah izjemno nestabilne – nekaj se nenehno spreminja. Na splošno je naše poslovanje zelo dinamično. Medtem ko nekaj počnemo, to že postane nepotrebno. Kako lahko poskrbimo, da bomo čim hitreje dosegli rezultate – kot vroče torte?
Uporabniki zahtevajo hitrost. Vendar ne moremo pogosto izvajati naših glavnih zagonskih procesov, ker to naloži izvorne sisteme (slabo vpliva na zmogljivost) - zato odložimo dodatne tokove podatkov - ki bodo vzeli točkovno - kar potrebujemo. Res je, izkaže se veliko tokov. Nato bomo nekaj podatkov zavrgli. Poleg tega bo problem konvergence. Ampak ni druge poti...

Kar veliko se je že zgodilo. Toda to ni popoln seznam - enostavno ga je dopolniti in razviti. Ne bomo ga skrivali v mizi, temveč ga obesili na vidno mesto - tako da bomo ta vprašanja v procesu dela ohranili v središču naše pozornosti.
Naša naloga je, da kot rezultat razvijemo celovito rešitev.

antifragilnost

Če pogledamo naš seznam, lahko naredimo en zaključek. Ni težko ustvariti nekakšne »baze podatkov za poročanje«, vanj vnesti podatke ali celo zgraditi nekakšne rutinske procese posodabljanja podatkov. Sistem nekako začne živeti, pojavljajo se uporabniki, z njimi pa obveznosti in SLA, nastajajo nove zahteve, povezujejo se dodatni viri, spreminjajo se metodologije - vse to je treba upoštevati v procesu razvoja.

Čez nekaj časa je slika naslednja:
"Tukaj je trezor. In deluje, če se ga ne dotakneš. Težave nastanejo, ko moramo nekaj spremeniti.«

Pride nam sprememba, katere vpliva ne moremo ovrednotiti in dojeti (ker takih orodij sprva nismo vgradili v sistem) - in da ne bi tvegali, se ne dotikamo tistega, kar je, ampak naredimo še eno podaljšek ob strani, pa še en in še več - spreminjanje naše odločitve v revske četrte ali kot pravijo v Latinski Ameriki, "favele", kamor se bojijo iti celo policija.
Pojavi se občutek izgube nadzora nad lastnim sistemom, kaos. Za vzdrževanje obstoječih procesov in reševanje težav je potrebnih vedno več rok. In vse težje je narediti spremembe. Z drugimi besedami, sistem postane nestabilen na obremenitve, neprilagodljiv na spremembe. Poleg tega je močna odvisnost od likov, ki "poznajo plovbo", saj nihče nima "karte".

Ta lastnost predmeta je, da se sesede pod vplivom kaosa, naključnih dogodkov in pretresov - poziva Nassim Nicholas Taleb krhkost . Uvaja tudi nasprotni koncept: antifragilnost – ko predmet ni uničen zaradi stresa in nesreč, ampak ima od tega neposredno korist. ("Antifragility. Kako izkoristiti kaos")
V nasprotnem primeru se lahko imenuje prilagodljivost oz odpornost na spremembe .

Kaj to pomeni v tem kontekstu? Kateri so "viri kaosa" za IT sisteme? In kaj pomeni "izkoristiti kaos" v smislu IT arhitekture?
Prva misel, ki pride na misel, so spremembe, ki prihajajo od zunaj. Kaj je zunanji svet za sistem? Predvsem za shranjevanje. Seveda, najprej - spremembe iz virov podatkov za skladišče:

spreminjanje formatov vhodnih podatkov;
zamenjava nekaterih sistemov virov podatkov z drugimi;
spreminjanje pravil/platform za sistemsko integracijo;
spreminjanje interpretacije podatkov (shranijo se formati, spremeni se logika dela s podatki);
sprememba podatkovnega modela, če se integracija izvede na podatkovni ravni (razčlenitev datotek dnevnika transakcij baze podatkov);
rast obsega podatkov - medtem ko je bilo podatkov v izvornem sistemu malo in obremenitev majhna - ste jih lahko vzeli kadar koli, s poljubno veliko zahtevo, so podatki in obremenitev narasli - zdaj obstajajo stroge omejitve;
itd.

Spremenijo se lahko sami izvorni sistemi, sestava informacij in njihova struktura, vrsta integracijske interakcije, pa tudi sama logika dela s podatki. Vsak sistem izvaja svoj podatkovni model in pristope k delu z njimi, ki ustrezajo ciljem in ciljem sistema. In ne glede na to, kako močno se trudijo poenotiti industrijske modele in referenčne prakse, se bodo odtenki neizogibno pojavili. (Poleg tega se sam proces združevanja industrije iz različnih razlogov ne premakne veliko naprej.)
Kultura dela s korporativnimi podatki - prisotnost in nadzor informacijske arhitekture, en sam semantični model, sistemi za upravljanje glavnih podatkov (MDM) nekoliko olajšajo nalogo konsolidacije podatkov v skladišču, vendar ne izključujejo njene potrebe.

Nič manj kritičnih sprememb sprožijo potrošniki za shranjevanje (spremembe zahtev):

prej je bilo podatkov dovolj za izdelavo poročila - zdaj je bilo treba povezati dodatna polja ali nov vir podatkov;
predhodno implementirane metode obdelave podatkov so zastarele - algoritme in vse, na kar vpliva, je treba predelati;
Prej so bili vsi zadovoljni s trenutno vrednostjo atributa slovarja na informacijski plošči - zdaj je potrebna vrednost, ki je relevantna v času nastanka analiziranega dejstva/dogodka;
obstajala je zahteva po globini zgodovine shranjevanja podatkov, ki je prej ni bilo - shranjevanje podatkov ne 2 leti, ampak 10 let;
Prej je bilo dovolj imeti podatke na "konec dneva/obdobja" - zdaj potrebujete stanje podatkov "znotraj dneva" ali v času določenega dogodka (na primer odločanje o vlogi za posojilo - za Basel II);
prej smo bili zadovoljni s poročanjem o podatkih za včeraj (T-1) ali pozneje, zdaj potrebujemo T0;
itd.

Tako integracijske interakcije z izvornimi sistemi kot zahteve potrošnikov podatkovnega skladišča so zunanji dejavniki za podatkovno skladišče: en izvorni sistem nadomesti drugega, količine podatkov rastejo, formati vhodnih podatkov se spreminjajo, zahteve uporabnikov se spreminjajo itd. In vse to so tipične zunanje spremembe, na katere mora biti naš sistem – naše skladišče – pripravljen. S pravo arhitekturo ne bi smeli uničiti sistema.

Ampak to še ni vse.
Ko govorimo o variabilnosti, se najprej spomnimo zunanjih dejavnikov. Konec koncev, znotraj lahko nadzorujemo vse, se nam zdi, kajne? Da in ne. Da, večina dejavnikov, ki so zunaj območja vpliva, je zunanjih. Obstaja pa tudi "notranja entropija". In prav zaradi njegove prisotnosti se moramo včasih vrniti "na točko 0". Začnite igro znova.
V življenju pogosto začnemo iz nič. Zakaj smo nagnjeni k temu? In ali je tako hudo?
Velja za IT. Za sam sistem – to je lahko zelo dobro – sposobnost ponovnega premisleka o posameznih odločitvah. Še posebej, če lahko to storimo lokalno. Refaktoring je proces razkrivanja "spleta", ki se občasno pojavlja v procesu razvoja sistema. Vrnitev "na začetek" je lahko koristna. Ampak ima svojo ceno.
S pravilnim upravljanjem arhitekture se ta cena zniža – sam proces razvoja sistema pa postane bolj nadzorovan in pregleden. Preprost primer: če upoštevamo načelo modularnosti, je mogoče prepisati ločen modul, ne da bi to vplivalo na zunanje vmesnike. In tega ni mogoče storiti z monolitno strukturo.

Antifragilnost sistema je določena z njegovo arhitekturo. In prav ta lastnost ga naredi prilagodljivega.
Ko govorimo o prilagodljiva arhitektura- mislimo, da se sistem lahko prilagaja spremembam, sploh pa ne, da nenehno spreminjamo samo arhitekturo. Nasprotno, bolj stabilna in stabilna je arhitektura, manj zahtev, ki zahtevajo njeno revizijo, bolj je sistem prilagodljiv.

Rešitve, ki zahtevajo revizijo celotne arhitekture, bodo imele veliko višjo ceno. In za njihovo posvojitev morate imeti zelo dobre razloge. Tak razlog je lahko na primer zahteva, ki je ni mogoče izvesti v okviru obstoječe arhitekture. Potem pravijo - obstajala je zahteva, ki vpliva na arhitekturo.
Tako moramo poznati tudi naše »meje protikrhkosti«. Arhitektura se ne razvija "v vakuumu" - temelji na trenutnih zahtevah in pričakovanjih. In če se stanje bistveno spremeni – moramo razumeti, da smo presegli trenutno arhitekturo – in jo moramo revidirati, razviti drugačno rešitev – in razmisliti o prehodnih poteh.
Predvidevali smo na primer, da bomo ob koncu dneva vedno potrebovali podatke v skladišču, podatke bomo zbirali dnevno s standardnimi sistemskimi vmesniki (prek niza pogledov). Nato so iz oddelka za upravljanje s tveganji prihajale zahteve, da je treba podatke prejeti ne ob koncu dneva, ampak v času sprejemanja odločitve o posojilu. Ni vam treba poskušati "raztegniti neraztegnjenega" - to dejstvo morate le prepoznati - čim prej, tem bolje. In začnite delati na pristopu, ki nam bo omogočil rešitev težave.
Tukaj je zelo tanka meja - če upoštevamo le "zahteve v trenutku" in ne gledamo nekaj korakov naprej (in nekaj let naprej), potem povečamo tveganje, da bomo prepozno naleteli na zahtevo, ki vpliva na arhitekturo - in stroški naše spremembe bodo zelo visoki. Pogled malo naprej – znotraj meja našega obzorja – še nikoli nikomur ni škodoval.

Primer sistema iz »skladiščne pravljice« je le primer zelo trhlega sistema, ki je zgrajen na krhkih oblikovalskih pristopih. In če se to zgodi, pride do uničenja za ta poseben razred sistemov precej hitro.
Zakaj lahko tako rečem? Tema shranjevanja ni nova. Pristopi in inženirske prakse, ki so se razvile v tem času, so bile usmerjene prav v to – ohranjanje sposobnosti preživetja sistema.
Če vzamemo preprost primer, je eden najpogostejših razlogov, zakaj projekti vzletnega shranjevanja neuspešni, poskušati zgraditi pomnilnik nad izvornimi sistemi v razvoju, ne da bi se ujemali z integracijskimi vmesniki – poskus pridobivanja podatkov neposredno iz tabel. Posledično so šli v razvoj – v tem času se je izvorna baza podatkov spremenila – in tokovi prenosa v shrambi so postali nedelujoči. Prepozno je, da bi nekaj naredili. In če se niste zavarovali z izdelavo več plasti miz znotraj skladišča, potem lahko vse zavržete in začnete znova. To je le en primer in eden najpreprostejših.

Talebov kriterij za krhko in antifragilno je preprosto. Glavni sodnik je čas. Če sistem vzdrži preizkus časa in pokaže svojo "preživetje" in "neuničljivost" - ima lastnost antifragilnosti.
Če pri načrtovanju sistema kot zahtevo upoštevamo antifragilnost, nas bo to spodbudilo k uporabi takih pristopov pri gradnji njegove arhitekture, ki bodo sistem naredili bolj prilagodljiv tako na "kaos od zunaj" kot "kaos od znotraj". ”. In na koncu bo imel sistem daljšo življenjsko dobo.
Nihče od nas ne želi delati "začasnih". In ne zavajajte se, da zdaj ni druge poti. Pogled nekaj korakov naprej je za človeka normalno v vsakem trenutku, še posebej v času krize.

Kaj je podatkovno skladišče in zakaj ga gradimo

Članek o arhitekturi shranjevanja predvideva, da bralec ne le ve, kaj je, ampak ima tudi nekaj izkušenj s takšnimi sistemi. Kljub temu se mi je zdelo potrebno to storiti - vrniti se k izvorom, na začetek poti, ker. tam se nahaja »točišče« razvoja.

Kako so ljudje prišli do zaključka, da so podatkovna skladišča potrebna? In kako se razlikujejo od "zelo velike baze podatkov"?
Že dolgo nazaj, ko so na svetu obstajali zgolj "sistemi za obdelavo poslovnih podatkov", IT sistemov ni bilo deliti na razrede, kot so front-end oltp sistemi, back-office dss, sistemi za obdelavo besedilnih podatkov, podatkovna skladišča itd. .
To je bil čas, ko je Michael Stonebreaker ustvaril prvi relacijski DBMS Ingres.
In to je bil čas, ko je doba osebnih računalnikov kot vrtinec vdrlo v računalniško industrijo in za vedno obrnilo vse zamisli takratne IT skupnosti.

Potem je bilo enostavno najti podjetniške aplikacije, napisane na osnovi DBMS namiznega razreda - kot so Clipper, dBase in FoxPro. In trg aplikacij odjemalec-strežnik in DBMS je le pridobival na zagonu. Drug za drugim so se pojavljali strežniki baz podatkov, ki bi dolgo časa zasedli svojo nišo v IT prostoru - Oracle, DB2 itd.
Razširjen je bil izraz "aplikacija baze podatkov". Kaj je vsebovala takšna prijava? Poenostavljeno - nekaj vnosnih obrazcev, prek katerih so lahko uporabniki hkrati vnašali informacije, nekaj izračunov, ki so bili zagnani "na gumb" ali "po urniku", pa tudi nekatera poročila, ki jih je mogoče videti na zaslonu ali shraniti kot datoteke in poslati v pečat .
»Nič posebnega – samo preprosta aplikacija, samo baza podatkov,« je pripomnil eden mojih zgodnjih mentorjev. "A ni nič posebnega?" - Takrat sem pomislil.

Če natančno pogledate, potem še vedno obstajajo funkcije. Ko uporabniki rastejo, se obseg dohodnih informacij povečuje, ko se obremenitev sistema povečuje, njegovi razvijalci-oblikovalci, da bi ohranili zmogljivost na sprejemljivi ravni, gredo na nekaj "trikov". Prva je razdelitev monolitnega "sistema za obdelavo poslovnih podatkov" na računovodsko aplikacijo, ki podpira delo uporabnikov v on-line načinu, in ločeno aplikacijo za paketno obdelavo in poročanje. Vsaka od teh aplikacij ima svojo bazo podatkov in celo gostuje na ločenem primerku strežnika baz podatkov, z različnimi nastavitvami za različne vrste obremenitve – OLTP in DSS. In med njimi se gradijo tokovi podatkov.

je vse? Zdi se, da je problem rešen. Kaj se zgodi potem?
In potem podjetja rastejo, njihove potrebe po informacijah se množijo. Raste tudi število interakcij z zunanjim svetom. In posledično ni ene velike aplikacije, ki v celoti avtomatizira vse procese, ampak več različnih, različnih proizvajalcev. Število sistemov, ki generirajo informacijsko – podatkovnih sistemov v podjetju, narašča. In prej ali slej bo treba videti in primerjati informacije, prejete iz različnih sistemov. Tako se v podjetju pojavi Data Warehousing, nov razred sistemov.
Splošno sprejeta definicija tega razreda sistemov je naslednja.

Podatkovno skladišče (ali podatkovno skladišče)- domensko specifično informacijsko bazo podatkov, posebej zasnovano in namenjeno za pripravo poročil in poslovnih analiz v podporo odločanju v organizaciji

V to smer, konsolidacijo podatkov iz različnih sistemov, je zmožnost pogleda nanje na določen »enoten« (enoten) način ena ključnih lastnosti sistemov razredov za shranjevanje podatkov. To je razlog, zakaj je shranjevanje nastalo med razvojem IT sistemov.

Ključne značilnosti podatkovnih skladišč

Oglejmo si podrobneje. Katere so ključne značilnosti teh sistemov? V čem se podatkovna skladišča razlikujejo od drugih IT sistemov podjetja?

Prvič, to so velike količine. Zelo velik. VLDB - tako imenujejo takšne sisteme vodilni prodajalci, ko dajejo priporočila o uporabi svojih izdelkov. Iz vseh sistemov podjetja se podatki stekajo v to veliko bazo podatkov in so tam shranjeni »za vedno in nespremenjeni«, kot pravijo v učbenikih (v praksi se življenje izkaže za bolj zapleteno).

Drugič, to so zgodovinski podatki − "Korporativni spomin" - tako imenovana podatkovna skladišča. V smislu dela s časom v skladišču je vse precej zanimivo. V računovodskih sistemih so podatki trenutno pomembni. Nato uporabnik izvede neko operacijo - in podatki se posodobijo. Hkrati se zgodovina sprememb morda ne bo ohranila - odvisno je od računovodske prakse. Vzemite na primer stanje na bančnem računu. Morda nas zanima trenutno stanje ob »zdaj«, na koncu dneva ali v času kakšnega dogodka (na primer v času izračunavanja rezultatov). Če sta prva dva rešena precej preprosto, bo slednja najverjetneje zahtevala posebne napore. Pri delu z repozitorij lahko uporabnik dostopa do preteklih obdobij, jih primerja s trenutnim itd. Prav te časovno povezane zmožnosti bistveno razlikujejo podatkovna skladišča od računovodskih sistemov – pridobivanje stanja podatkov na različnih točkah časovne osi – do določene globine v preteklosti.

Tretjič, to konsolidacijo in poenotenje podatkov . Da bi omogočili njihovo skupno analizo, jih je treba spraviti v skupno obliko - enoten podatkovni model , primerjaj dejstva z enotnimi referenčnimi knjigami. Tu je lahko več vidikov in težav. Predvsem - konceptualno – pod istim izrazom lahko različni ljudje iz različnih oddelkov razumejo različne stvari. In obratno – drugače imenovati nekaj, kar je v bistvu ista stvar. Kako zagotoviti »enoten pogled«, hkrati pa ohraniti posebnosti vizije določene skupine uporabnikov?

Četrtič, to je delo z kakovost podatkov . V procesu nalaganja podatkov v pomnilnik se le-ti očistijo, izvedejo splošne transformacije in transformacije. Splošne transformacije je treba opraviti na enem mestu – in nato uporabiti za sestavljanje različnih poročil. S tem se bomo izognili neskladjem, ki povzročajo toliko draženja pri poslovnih uporabnikih – še posebej pri vodstvu, ki ga na mizo pripeljejo številke iz različnih oddelkov, ki se med seboj ne strinjajo. Slaba kakovost podatkov povzroča napake in neskladja v poročilih, kar je posledica znižanja ravni zaupanje uporabnikov na celoten sistem, na celotno analitično službo kot celoto.

arhitekturni koncept

Vsi, ki so naleteli na skladišče, so najverjetneje opazili nekakšno "plastovito strukturo" - ker. prav ta arhitekturna paradigma se je uveljavila za sisteme tega razreda. In ne po naključju. Sloge shranjevanja lahko dojemamo kot ločene komponente sistema - s svojimi nalogami, območji odgovornosti, "pravili igre".
Večplastna arhitektura je sredstvo za obravnavo kompleksnosti sistema – vsaka naslednja plast je abstrahirana od kompleksnosti notranje izvedbe prejšnje. Ta pristop vam omogoča, da prepoznate naloge iste vrste in jih rešite na enoten način, ne da bi vsakič znova izumili »kolo« iz nič.
Shematski konceptualni arhitekturni diagram je prikazan na sliki. To je poenostavljen diagram, ki odraža samo ključno idejo – koncept, vendar brez »anatomskih podrobnosti«, ki se bodo pojavile s poglobljenim preučevanjem podrobnosti.

Kot je prikazano na diagramu, konceptualno izberite naslednje plasti. Tri glavne plasti, ki vsebujejo območje za shranjevanje podatkov (označeno z zapolnjenim pravokotnikom) in programsko opremo za nalaganje podatkov (pogojno prikazano s puščicami iste barve). Pa tudi pomožna – storitvena plast, ki pa ima zelo pomembno povezovalno vlogo – upravljanje nalaganja podatkov in nadzor kakovosti.

Primary Data Layer - primarni podatkovni sloj (oz uprizoritev , oz operacijski sloj ) - je zasnovan za nalaganje iz izvornih sistemov in shranjevanje primarnih informacij, brez transformacij - v izvirni kakovosti in s podporo za celotno zgodovino sprememb.
Naloga te plasti– abstrahirati naslednje plasti shranjevanja iz fizične naprave virov podatkov, metod zbiranja podatkov in metod za ekstrakcijo delte sprememb.

Core Data Layer - jedro za shranjevanje - osrednja komponenta sistema, ki loči shranjevanje od zgolj »platforme za paketno integracijo« ali »big data dump«, saj je njegova glavna vloga konsolidacija podatkov iz različnih virov, redukcija na enotne strukture, ključi. Pri nalaganju v jedro se izvaja glavno delo s kakovostjo podatkov in splošnimi transformacijami, ki so lahko precej zapletene.
Naloga te plasti- svoje potrošnike abstrahirati od posebnosti logične strukture podatkovnih virov in potrebe po primerjavi podatkov iz različnih sistemov, zagotoviti celovitost in kakovost podatkov.

Data Mart Layer - analitične vitrine - komponenta, katere glavna funkcija je pretvorba podatkov v strukture, primerne za analizo (če BI deluje z izložnicami, potem je to običajno dimenzijski model) ali glede na zahteve potrošniškega sistema.
Podatkovne trgovine praviloma jemljejo podatke iz jedra – kot zanesljiv in preverjen vir – t.j. uporabite storitev te komponente, da podatke združite v enotno obliko. Takšna okna bomo imenovali redno . V nekaterih primerih lahko prodajalne podatke prevzamejo neposredno iz uprizarjanja – delujejo s primarnimi podatki (v izvornih ključih). Ta pristop se praviloma uporablja za lokalne naloge, kjer ni potrebna konsolidacija podatkov iz različnih sistemov in kjer je bolj potrebna učinkovitost kot kakovost podatkov. Takšni prikazi se imenujejo delovanje . Nekateri analitični kazalniki imajo lahko zelo zapletene metode izračuna. Zato so za takšne netrivialne izračune in transformacije t.i sekundarne vitrine .
Naloga sloja trgovine– priprava podatkov glede na zahteve posameznega potrošnika – BI platforme, skupine uporabnikov ali zunanjega sistema.

Zgoraj opisani sloji so sestavljeni iz trajnega prostora za shranjevanje podatkov, pa tudi iz programskega modula za nalaganje in preoblikovanje podatkov. Ta delitev na plasti in regije je logična. Fizična izvedba teh komponent je lahko različna – lahko celo uporabite različne platforme za shranjevanje ali pretvorbo podatkov na različnih slojih, če je to učinkovitejše.
Območja shranjevanja vsebujejo tehnične (medpomnilniške tabele), ki se uporabljajo v procesu preoblikovanja podatkov in ciljne mize, do katerih dostopa potrošniška komponenta. Dobra praksa je "pokriti" ciljne tabele s pogledi. To olajša nadaljnje vzdrževanje in razvoj sistema. Podatki v ciljnih tabelah vseh treh slojev so označeni s posebnimi tehničnimi polji (metaatributi), ki zagotavljajo procese nalaganja podatkov ter omogočajo informacijsko revizijo tokov podatkov v shrambi.

Razlikuje se tudi posebna komponenta (ali nabor komponent), ki zagotavlja storitvene funkcije za vse plasti. Ena njegovih ključnih nalog - nadzorna funkcija - je zagotoviti "enotna pravila igre" za celoten sistem kot celoto, pri čemer pušča pravico do uporabe različnih možnosti za izvajanje vsake od zgoraj opisanih plasti - vklj. uporabljajo različne tehnologije za nalaganje in obdelavo podatkov, različne platforme za shranjevanje itd. Pokličimo ga storitveni sloj (Service Layer) . Ne vsebuje poslovnih podatkov, ima pa svoje strukture za shranjevanje – vsebuje območje metapodatkov, pa tudi področje za delo s kakovostjo podatkov (in morda tudi druge strukture, odvisno od funkcij, ki so mu dodeljene).

Tako jasna razdelitev sistema na ločene komponente bistveno poveča obvladljivost razvoja sistema:

zmanjša se kompleksnost naloge, ki je dodeljena razvijalcu funkcionalnosti posamezne komponente (ni mu treba hkrati reševati integracijskih vprašanj z zunanjimi sistemi, razmišljati o postopkih čiščenja podatkov in razmišljati o optimalni predstavitvi podatkov za potrošniki) - nalogo je lažje razgraditi, ovrednotiti in izvesti majhno dostavo;
v delo lahko vključite različne izvajalce (in celo ekipe ali izvajalce) – ker ta pristop vam omogoča, da učinkovito vzporedite naloge in zmanjšate njihov medsebojni vpliv drug na drugega;
Prisotnost trajnega uprizarjanja vam omogoča hitro povezavo virov podatkov brez oblikovanja celotnega jedra ali vitrin za celotno predmetno področje, nato pa postopoma zgradite preostale plasti glede na prioritete (poleg tega bodo podatki že v repozitoriju - na voljo sistemskim analitikom, kar bo močno olajšalo naloge nadaljnjega razvoja repozitorija);
prisotnost jedra omogoča, da se vse delo s kakovostjo podatkov (kot tudi morebitne napake in napake) skrije pred izložnicami in pred končnim uporabnikom, kar je najpomembneje, da se z uporabo te komponente kot enega vira podatkov za izložbe izognete težavam s konvergenco podatkov zaradi implementacije skupnih algoritmov na enem mestu;
poudarjanje izložb vam omogoča, da upoštevate razlike in posebnosti razumevanja podatkov, ki jih lahko imajo uporabniki različnih oddelkov, in njihovo oblikovanje za zahteve BI vam omogoča ne le izdajanje združenih številk, ampak tudi zagotavljanje zanesljivosti podatkov z zagotavljanjem možnosti za razčlenitev primarnim kazalnikom;
prisotnost storitvenega sloja vam omogoča izvajanje analize podatkov od konca do konca (podatkovne linije), uporabo enotnih orodij za revizijo podatkov, skupnih pristopov za poudarjanje delte sprememb, delo s kakovostjo podatkov, upravljanje obremenitve, spremljanje napak in diagnostična orodja in pospešuje reševanje težav.

Ta pristop k razgradnji naredi sistem tudi bolj odporen na spremembe (v primerjavi z "monolitno strukturo") - zagotavlja njegovo antikrhkost:

spremembe iz izvornih sistemov se obdelajo pri uprizarjanju - v jedru so spremenjene samo tiste niti, na katere te uprizarjevalne tabele vplivajo, učinek na izložbe je minimalen ali ga ni;
spremembe zahtev kupcev se večinoma obdelujejo v izložbenih prostorih (razen če zahtevajo dodatne informacije, ki jih še ni v skladišču).

Nato si bomo ogledali vsako od zgornjih komponent in si jih ogledali nekoliko podrobneje.

Sistemsko jedro

Začnimo »od sredine« – jedra sistema oziroma srednjega sloja. Ni označena kot jedrna plast. Jedro opravlja vlogo konsolidacije podatkov - redukcijo na posamezne strukture, imenike, ključe. Tu se izvaja glavno delo s kakovostjo podatkov - čiščenje, preoblikovanje, poenotenje.

Prisotnost te komponente vam omogoča ponovno uporabo podatkovnih tokov, ki pretvarjajo primarne podatke, prejete iz izvornih sistemov, v eno samo obliko, po skupnih pravilih in algoritmih, namesto da ponavljate izvajanje iste funkcionalnosti ločeno za vsako izložbo aplikacij, ki poleg neučinkovita poraba virov, lahko povzroči tudi neskladja v podatkih.
Shranjevalno jedro je implementirano v podatkovni model, v splošnem primeru drugačen tako od modelov izvornih sistemov kot od formatov in struktur porabnikov.

Model shranjevalnega mehanizma in podatkovni model podjetja

Glavna naloga srednjega skladiščnega sloja je stabilnost. Zato je tukaj glavni poudarek na podatkovnem modelu. Običajno se imenuje "podjetniški podatkovni model". Žal se je okoli njega razvil določen halo mitov in absurdov, ki včasih vodijo do popolne opustitve njegove gradnje, a zaman.

mit 1. Podatkovni model podjetja je ogromen model, sestavljen iz tisočih entitet (tabel).
Pravzaprav. Na katerem koli predmetnem področju, v kateri koli poslovni domeni, v podatkih katerega koli podjetja, tudi najbolj zapletenega, je malo osnovnih entitet - 20-30.

mit 2. Ni treba razvijati nobenega "lasnega modela" - kupimo panožni referenčni model - in naredimo vse v skladu z njim. Denar porabimo - vendar dobimo zagotovljen rezultat.
Pravzaprav. Referenčni modeli so lahko res zelo uporabni, ker. vsebujejo izkušnje iz industrije pri modeliranju tega področja. Iz njih lahko črpate ideje, pristope, prakse poimenovanja. Preverite "globino pokritosti" območja, da ne zamudite česa pomembnega. Toda malo verjetno je, da bomo takšnega modela lahko uporabili "iz škatle" - takšnega, kot je. To je isti mit kot na primer nakup sistema ERP (ali CRM) in njegova implementacija brez »zavijanja zase«. Vrednost takšnih modelov se rodi v njihovi prilagoditvi realnosti tega posebnega posla, tega posebnega podjetja.

mit 3. Razvoj modela shranjevalnega jedra lahko traja več mesecev, v tem času pa bo projekt dejansko zamrznjen. Poleg tega zahteva noro veliko srečanj in udeležbo številnih ljudi.
Pravzaprav. Model skladišča je mogoče razvijati iterativno, kos za kosom, skupaj z repozitorijom. Za nepokrita območja se postavijo "podaljške" ali "stubovi" - t.j. uporabljajo se nekatere "univerzalne konstrukcije". Hkrati morate poznati mero, da ne dobite super-univerzalne stvari 4 tabel, v katere je težko tako "vstaviti podatke" kot (še težje) jih dobiti. In kar je izredno neoptimalno glede na zmogljivost.

Za razvoj modela bo potreben čas. Toda to ni čas, porabljen za "risanje entitet" - to je čas, potreben za analizo predmetnega področja in razumevanje, kako so podatki strukturirani. Zato so v ta proces zelo tesno vključeni analitiki, pa tudi različni poslovni strokovnjaki. In to se naredi selektivno. In ne z organizacijo srečanj z norim številom ljudi, pošiljanjem ogromnih vprašalnikov itd.
Kakovostna poslovna in sistemska analiza je ključnega pomena za izgradnjo osnovnega modela shranjevanja. Razumeti morate marsikaj: kje (v katerih sistemih) nastajajo podatki, kako so urejeni, v katerih poslovnih procesih krožijo itd. Kvalitativna analiza nikoli ni škodila nobenemu sistemu. Nasprotno, težave izhajajo iz »praznih pik« v našem razumevanju.

Razvoj podatkovnega modela ni proces izumljanja in ustvarjanja nečesa novega. Pravzaprav podatkovni model v podjetju že obstaja. In proces njegovega oblikovanja je bolj podoben "izkopavanjima". Model je nežno in skrbno izpostavljen iz »tla« korporativnih podatkov in oblečen v strukturirano obliko.

mit 4. V našem podjetju je posel tako dinamičen in vse se tako hitro spreminja, da nam je neuporabno izdelovati model – zastarel bo, preden bomo ta del sistema dali v obratovanje.
Pravzaprav. Spomnimo se, da je ključni dejavnik v jedru stabilnost. In predvsem topologija modela. zakaj? Ker je ta komponenta osrednja in vpliva na vse ostalo. Stabilnost je tudi zahteva za model jedra. Če model prehitro zastari, je napačno oblikovan. Za njen razvoj so bili izbrani napačni pristopi in »pravila igre«. Gre tudi za vprašanje kvalitativne analize. Ključne entitete korporativnega modela se spreminjajo izjemno redko.
Če pa nam pride na misel, da bi za podjetje, ki prodaja recimo slaščice, namesto imenika »Izdelki« naredili »Sladkarije«, »torte« in »pite«. Potem, ko se pica pojavi na seznamu blaga - da, vnesti boste morali veliko novih tabel. In to je samo vprašanje pristopa.

mit 5. Ustvarjanje korporativnega modela je zelo resen, kompleksen in odgovoren posel. In strašljivo je narediti napako.
Pravzaprav. Osnovni model, čeprav bi moral biti stabilen, še vedno ni "ulit v kovino". Kot vse druge oblikovalske odločitve je tudi njegovo strukturo mogoče pregledati in spremeniti. Samo ne pozabite na to njeno kakovost. Toda to sploh ne pomeni, da na njem "ne morete dihati". In to ne pomeni, da so začasne rešitve in "šopke", ki bi jih bilo treba načrtovati za obdelavo, nesprejemljive.

mit 6. Če imamo vir podatkov - na primer sistem NSI (ali sistem za upravljanje glavnih podatkov - MDM), bi moral v dobrem smislu ustrezati korporativnemu modelu (še posebej, če je bil nedavno zasnovan in ni imel časa za pridobitev »neželeni učinki«, »tradicije« in začasne zgradbe). Izkazalo se je, da za ta primer - ne potrebujemo modela jedra?
Pravzaprav. Ja, v tem primeru je gradnja modela shranjevalnega jedra močno olajšana – ker sledimo vrhunskemu že pripravljenemu konceptualnemu modelu. A to sploh ni izključeno. zakaj? Ker pri gradnji modela določenega sistema veljajo določena pravila – katere vrste tabel uporabiti (za posamezno entiteto), kako različice podatkov, s kakšno granularnostjo voditi zgodovino, katere metaatribute (tehnična polja uporabiti) itd. .

Poleg tega, ne glede na to, kako čudovit in izčrpen sistem NSI in MDM, imamo, praviloma obstajajo odtenki, povezani z obstojem lokalnih imenikov "približno enakih" v drugih računovodskih sistemih. In to težavo, hočemo ali ne, bo treba rešiti v skladišču, saj se tukaj zbirajo poročanje in analitika.

Primarni podatkovni sloj (ali zgodovinski uprizoritveni ali operativni sloj)

Na njej je označena kot primarna podatkovna plast. Vloga te komponente: integracija z izvornimi sistemi, nalaganje in shranjevanje primarnih podatkov, pa tudi predhodno čiščenje podatkov - preverjanje skladnosti s pravili formatno-logičnega nadzora, določenimi v "dogovoru o interakcijskem vmesniku" z virom.
Poleg tega ta komponenta rešuje zelo pomembno nalogo za shranjevanje - poudarjanje "prave delte sprememb" - ne glede na to, ali vir omogoča sledenje spremembam podatkov ali ne in kako (po kakšnem kriteriju jih je mogoče "ujeti") . Takoj, ko so podatki prišli v uprizoritev, je vprašanje delta izbire že jasno za vse druge plasti, zahvaljujoč označevanju z meta-atributi.

Podatki v tej plasti so shranjeni v strukturah, ki so čim bližje izvornemu sistemu – da bi ohranili primarni podatki čim bližje njihovi izvirni obliki. Drugo ime za to komponento je "operativna plast".
Zakaj ne bi preprosto uporabili ustaljenega izraza »uprizoritev«? Dejstvo je, da je bil prej, pred "dobo velikih podatkov in VLDB", prostor na disku zelo drag - in pogosto so bili primarni podatki, če so bili shranjeni, le za omejeno časovno obdobje. In pogosto se imenuje ime "uprizoritev". očiščen pufer.
Zdaj je tehnologija stopila naprej – in si lahko privoščimo ne samo shranjevanje vseh primarnih podatkov, temveč tudi njihovo zgodovino s stopnjo razdrobljenosti, ki je le možna. To ne pomeni, da ne smemo nadzorovati rasti podatkov in ne odpravlja potrebe po upravljanju življenjskega cikla informacij z optimizacijo stroškov shranjevanja podatkov, odvisno od »temperature« uporabe – t.j. selitev »hladnih podatkov«, po katerih je manj povpraševanja, na cenejše medije in platforme za shranjevanje.

Kaj nam daje prisotnost "zgodovinske uprizoritve":

možnost napak (v strukturah, v algoritmih transformacije, v granularnosti vodenja zgodovine) - ob popolnoma historizirajočih primarnih podatkih v območju razpoložljivosti shranjevanja lahko vedno znova naložimo svoje tabele;
priložnost za razmišljanje - lahko si vzamemo čas za razvoj velikega fragmenta jedra v tej posebni ponovitvi razvoja repozitorija, ker v naši uprizoritvi v vsakem primeru bodo in z enakomernim časovnim horizontom (bo eno »izhodišče zgodovine«);
možnost analize - shranili bomo tudi tiste podatke, ki jih v viru ni več - tam bi jih lahko prepisali, šli v arhiv itd. – pri nas ostanejo na voljo za analizo;
možnost informacijske revizije - zahvaljujoč najbolj podrobnim primarnim informacijam bomo potem lahko ugotovili, kako je prenos deloval pri nas, da smo na koncu dobili takšne številke (za to morate imeti tudi oznake z metaatributi in ustrezni metapodatki, na katerih deluje prenos - to se odloči na ravni storitve).

Kakšne težave se lahko pojavijo pri gradnji "zgodovinske uprizoritve":

bilo bi priročno določiti zahteve za transakcijsko celovitost tega sloja, vendar praksa kaže, da je to težko doseči (to pomeni, da na tem področju ne zagotavljamo referenčne integritete nadrejenih in podrejenih tabel) - poravnava celovitosti se zgodi pri naslednjih plasti;
ta plast vsebuje zelo velike količine (največje v shrambi – kljub vsej redundanci analitičnih struktur) – in takšne količine morate biti sposobni obvladati – tako v smislu nalaganja kot glede poizvedb (v nasprotnem primeru lahko resno poslabšate zmogljivost celotnega skladišča).

Kaj še lahko rečemo o tej plasti.
Prvič, če se oddaljimo od paradigme »procesov nakladanja od konca do konca«, potem pravilo »karavana se giblje s hitrostjo zadnje kamele« za nas ne deluje več oziroma opustimo načelo »karavane«. in preklopite na princip "transporterja": podatke smo vzeli iz vira - vnesli v vaš sloj - pripravljeni za naslednji del. To pomeni, da
1) ne čakamo, da se obdelava zgodi na drugih slojih;
2) nismo odvisni od urnika posredovanja podatkov s strani drugih sistemov.
Preprosto povedano, načrtujemo postopek nalaganja, ki vzame podatke iz enega vira prek določene metode povezave do njega, preveri, ekstrahira delta - in podatke postavi v uprizoritvene ciljne tabele. In to je vse.

Drugič, ti procesi so očitno urejeni zelo preprosto - lahko bi rekli trivialno, z vidika logike. In to pomeni, da jih je mogoče zelo dobro optimizirati in parametrizirati, zmanjšati obremenitev našega sistema in pospešiti proces povezovanja virov (čas razvoja).
Da se to zgodi, morate zelo dobro poznati tehnološke značilnosti platforme, na kateri deluje ta komponenta - in potem lahko naredite zelo učinkovito orodje.

Plast analitičnih vitrin

Plast izložnice (Sloj podatkovnega trga) je odgovorna za pripravo in zagotavljanje podatkov končnim uporabnikom – ljudem ali sistemom. Na tej ravni se čim bolj upoštevajo zahteve potrošnika – tako logične (konceptualne) kot fizične. Storitev mora zagotoviti točno tisto, kar je potrebno - nič več, nič manj.

Če je potrošnik zunanji sistem, potem praviloma narekuje strukture podatkov, ki jih potrebuje, in pravila za zbiranje informacij. Dober pristop je tisti, pri katerem je potrošnik odgovoren za pravilno zbiranje podatkov. Podatkovno skladišče je pripravilo, oblikovalo izložbo, omogočilo inkrementalno zbiranje podatkov (označevanje z metaatributi za kasnejši izbor delta sprememb), nato pa potrošniški sistem upravlja in je odgovoren za to, kako to izložbo uporablja. Vendar pa obstajajo posebnosti: kadar sistem nima aktivne komponente za zbiranje podatkov, je potrebna zunanja komponenta, ki bo opravljala integracijsko funkcijo, ali pa bo shramba delovala kot »integracijska platforma« in zagotavljala pravilen postopni nalaganje podatkov. dalje – izven skladišča. Tu se pojavljajo številni odtenki, pravila interakcije vmesnikov pa bi morali premisliti in razumeti obe strani (vendar, kot vedno, ko gre za integracijo). Praviloma se za takšne izložbe uporablja rutinsko čiščenje/arhiviranje podatkov (redko je potrebno, da se ti »tranzitni podatki« shranijo dlje časa).

Največji pomen pri analitičnih opravilih so izložbe »za ljudi« – natančneje za BI orodja, s katerimi delajo.
Vendar pa obstaja kategorija "posebej naprednih uporabnikov" - analitikov, podatkovnih znanstvenikov -, ki ne potrebujejo niti BI orodij niti rutinskih procesov za polnjenje zunanjih specializiranih sistemov. Potrebujejo nekakšno "skupno izložbo" in "lastni peskovnik", kjer lahko po lastni presoji ustvarjajo tabele in transformacije. V tem primeru je odgovornost repozitorija zagotoviti, da so ti skupni podatkovni trgi napolnjeni v skladu s predpisi.
Ločeno lahko izpostavimo takšne potrošnike, kot so orodja za podatkovno rudarjenje - globoka analiza podatkov. Ta orodja imajo lastne zahteve za pripravo podatkov in jih uporabljajo tudi podatkovni znanstveniki. Za repozitorij je naloga zmanjšana - spet na podporo storitve za prenos določenih vitrin dogovorjene oblike.

Vendar pa se vrnimo k analitičnim prodajalnam. Prav oni so zanimivi z vidika oblikovalcev shranjevanja v tej podatkovni plasti.
Po mojem mnenju je najboljši časovno preizkušen pristop k oblikovanju podatkovnih trgov, za katerega so zdaj »izostrene« skoraj vse BI platforme, pristop Ralpha Kimballa. Poznan je po imenu dimenzijsko modeliranje – večdimenzionalno modeliranje. Obstaja veliko publikacij na to temo. Osnovna pravila so na primer v publikaciji. In seveda lahko priporočite od gurujev multivariatnega modeliranja. Drug koristen vir so Kimballovi nasveti.
Večdimenzionalni pristop k ustvarjanju izložb je bil tako dobro opisan in razvit – tako pri evangelisti metod kot pri vodilnih prodajalcih programske opreme –, da se na njem nima smisla zadrževati v podrobnostih – prvotni vir je vedno boljši.

Rad bi poudaril samo en poudarek. "Poročanje in analitika" je drugačna. Obstaja "težko poročanje" - prednaročena poročila, ki so generirana v obliki datotek in dostavljena uporabnikom preko predvidenih dostavnih kanalov. In tu so informacijske plošče - BI nadzorne plošče. V bistvu so spletne aplikacije. Zahteve glede odzivnega časa teh aplikacij so enake kot pri vseh drugih spletnih aplikacijah. To pomeni, da je običajni čas osveževanja za ploščo BI sekunde in ne minute. To je pomembno upoštevati pri načrtovanju rešitve. Kako to doseči? Standardna metoda optimizacije: pogledamo, iz česa je sestavljen odzivni čas in na kaj lahko vplivamo. Čemu porabiš največ časa? Za fizično (disk) branje baze podatkov, za prenos podatkov po omrežju. Kako zmanjšati količino prebranih in prenesenih podatkov na zahtevo? Odgovor je očiten in preprost: podatke morate združiti ali uporabiti filter za velike tabele dejstev, ki sodelujejo v poizvedbi, in izključiti združevanje velikih tabel (sklicevanja na tabele dejstev naj gredo samo skozi dimenzije).

Za kaj je BI? Kako je priročno? Zakaj je multivariatni model učinkovit?
BI omogoča uporabniku izvajanje tako imenovanih "ad hoc poizvedb". Kaj to pomeni? To pomeni, da zahteve ne poznamo natančno vnaprej, vemo pa, katere indikatorje, v katerih razdelkih lahko uporabnik zahteva. Uporabnik generira takšno poizvedbo z izbiro ustreznih BI filtrov. In naloga razvijalca BI in oblikovalca predstavitve je zagotoviti takšno logiko delovanja aplikacije, tako da se podatki filtrirajo ali združijo, pri čemer se izognemo situaciji, ko je zahtevanih preveč podatkov in aplikacija "visi". Običajno začnejo z agregiranimi številkami, nato se poglobijo v podrobnejše podatke, hkrati pa nastavijo potrebne filtre.

Ni vedno dovolj preprosto zgraditi "pravo zvezdo" - in dobiti priročno strukturo za BI. Včasih morate nekje uporabiti denormalizacijo (ob pogledu nazaj, kako bo vplivala na obremenitev) in nekje narediti sekundarne izložbe in agregate. Nekje za dodajanje indeksov ali projekcij (odvisno od DBMS).

Tako lahko s poskusi in napakami dobite strukturo, ki je optimalna za BI - ki bo upoštevala značilnosti tako DBMS kot platforme BI ter zahteve uporabnika za predstavitev podatkov.
Če vzamemo podatke iz "jedra", bo takšna obdelava izložb lokalne narave, ne da bi na noben način vplivala na kompleksno obdelavo primarnih podatkov, prejetih neposredno iz izvornih sistemov - podatke samo "prestavimo" v obliko, ki je priročna. za BI. In to si lahko privoščimo večkrat, na različne načine, v skladu z različnimi zahtevami. Veliko lažje in hitreje je to narediti na podlagi podatkov jedra kot pa sestaviti iz »primarnega« (katerega struktura in pravila, kot vemo, lahko tudi »plavajo«).

storitveni sloj

Storitveni sloj ( - Service Layer ) je odgovoren za implementacijo skupnih (storitvenih) funkcij, ki jih je mogoče uporabiti za obdelavo podatkov v različnih slojih shranjevanja - upravljanje obremenitve, upravljanje kakovosti podatkov, orodja za diagnosticiranje težav in spremljanje itd.
Prisotnost te ravni zagotavlja preglednost in strukturirane pretoke podatkov v shrambi.

Ta plast vključuje dve področji za shranjevanje podatkov:

območje metapodatkov - uporablja se za nadzorni mehanizem nalaganja podatkov;
področje kakovosti podatkov - za izvajanje preverjanj kakovosti podatkov brez povezave (tj. tistih, ki niso vgrajeni neposredno v procese ETL).

Proces upravljanja obremenitve lahko zgradite na različne načine. Eden od možnih pristopov je ta: celoten sklop shranjevalnih tabel razdelimo na module. V modul je mogoče vključiti samo tabele ene plasti. Tabele, vključene v vsak modul, se naložijo kot del ločenega procesa. Pokličimo ga nadzorni proces . Začetek postopka nadzora je postavljen po lastnem urniku. Nadzorni proces orkestrira klice atomskih procesov, od katerih vsak naloži eno ciljno tabelo, vsebuje pa tudi nekaj skupnih korakov.
Očitno je dovolj, da uprizoritvene tabele preprosto razdelite na module - glede na izvorne sisteme oziroma njihove priključne točke. Toda za jedro je to že težje izvedljivo – ker. tam moramo zagotoviti celovitost podatkov, kar pomeni, da moramo upoštevati odvisnosti. tiste. prihajalo bo do konfliktov, ki jih je treba rešiti. In obstajajo različni načini za njihovo reševanje.

Pomembna točka pri upravljanju obremenitve je razvoj enotnega pristopa k obravnavi napak. Napake so razvrščene glede na stopnjo kritičnosti. Ko pride do kritične napake, je treba postopek ustaviti, in to čim prej, ker. njegovo pojavljanje kaže na pomembno težavo, ki lahko povzroči poškodovanje podatkov v shrambi. Tako pri upravljanju obremenitve ne gre le za zagon procesov, temveč tudi za njihovo zaustavitev, pa tudi za preprečevanje nepravočasnega zagona (po pomoti).

Za delovanje storitvenega sloja je ustvarjena posebna struktura metapodatkov. To območje bo shranilo informacije o procesih nalaganja, naloženih nizih podatkov, kontrolnih točkah, ki se uporabljajo za vzdrževanje prirastka (kateri proces je prebral do katere točke) in druge storitvene informacije, potrebne za delovanje sistema.
Pomembno je omeniti, da so vse ciljne tabele v vseh slojih označene s posebnim naborom metapolj, od katerih je eno ID procesa, ki je posodobil ta niz. Za tabele v repozitoriju to označevanje postopka omogoča enoten način za naknadno ekstrahiranje delta sprememb. Pri nalaganju podatkov v primarni podatkovni sloj je situacija bolj zapletena - algoritem za ekstrakcijo delte za različne naložene objekte je lahko drugačen. Po drugi strani pa je logika obdelave sprejetih sprememb in njihovega rolliranja na ciljne tabele za jedro in izložnice veliko bolj zapletena kot pri uprizarjanju, kjer je vse precej trivialno - enostavno je parametrirati in razmišljati o tipičnih korakih, ki jih je mogoče ponovno uporabiti (postopke ).

Tukaj si ne postavljam naloge, da bi v celoti pokrival to temo - organizacijo nakladanja - postavljam le poudarke, na katere je vredno biti pozoren.
Zgornji pristop je le ena od možnosti. Je precej prilagodljiv. In njegov "konceptualni prototip" je bil Toyotin transporter in sistem "just-in-time". tiste. odmikamo se od razširjene paradigme izključno "nočnega nalaganja podatkov", čez dan pa nalagamo v majhnih porcijah - saj so podatki pripravljeni v različnih virih: kar je prišlo, je naloženo. Hkrati imamo v teku veliko vzporednih procesov. In "vroč rep" svežih podatkov bo nenehno "utripal" - in čez nekaj časa izenačil. To lastnost moramo upoštevati. In po potrebi oblikovati vitrine po meri "rezine", kjer je vse že sestavno. tiste. nemogoče je doseči tako učinkovitost kot doslednost (integriteto) hkrati. Potrebujemo ravnovesje – nekje je ena stvar pomembna, nekje drugje.

Izjemno pomembno je zagotoviti sredstva za beleženje in spremljanje. Dobra praksa je uporaba tipkanih dogodkov, kjer lahko nastavite različne parametre in nastavite sistem obveščanja – naročnino na določene dogodke. Ker zelo pomembno je, da ko je potrebno posredovanje sistemskega skrbnika, ta čim prej izvede za to in prejme vse potrebne diagnostične informacije. Dnevniki se lahko uporabljajo tudi za analizo problemov po dejstvu, pa tudi za preiskovanje incidentov okvar sistema, vklj. kakovost podatkov.

Oblikujte in vzdržujte podatkovne modele skladišč

Zakaj je pomembno, da smo pri razvoju katerega koli sistema, kjer je vključena baza podatkov (predvsem v skladišču), pozoren na načrtovanje podatkovnih modelov? Zakaj ne bi preprosto vstavili niza tabel, kjer koli - tudi v urejevalniku besedil? Zakaj potrebujemo te slike?
Nenavadno je, da tudi izkušeni razvijalci postavljajo taka vprašanja.
Pravzaprav da, nič vam ne preprečuje, da bi skicirali tabele - in jih začeli uporabljati. Če ... če hkrati v glavi (!) Razvijalec ima harmonično celotno sliko strukture, ki jo kipi. Kaj pa, če je razvijalcev več? Kaj pa, če bo te tabele uporabil kdo drug? Kaj pa, če čas mine - človek zapusti to območje in se nato spet vrne nanj?

Ali je to mogoče ugotoviti brez modela? V bistvu lahko. In da to ugotovite, in "ocenite slike na listu papirja" in "počistite - poravnajte" podatke. Je pa veliko lažje, jasneje in hitreje uporabiti že pripravljen artefakt – podatkovni model. In tudi razumeti "logiko njegove strukture" - t.j. Lepo bi bilo imeti skupna pravila igre.

In najpomembnejše niti to ni. Najpomembneje pa je, da smo pri oblikovanju modela prisiljeni (preprosto brez možnosti!) podrobneje in poglobljeno preučiti predmetno področje, značilnosti strukture podatkov in njihovo uporabo v različnih poslovnih primerih. In tista vprašanja, ki bi jih zlahka "odrinili" kot zapletena, "zabrisali" z metanjem naših znakov, ne da bi poskušali oblikovanje model - prisiljeni bomo določiti in odločiti zdaj, med analizo in načrtovanjem, in ne kasneje - ko bomo gradili poročila in razmišljali o tem, "kako zmanjšati nezdružljivo" in vsakič "iznajti kolo".

Ta pristop je ena tistih inženirskih praks, ki omogočajo ustvarjanje protilomljivih sistemov. Ker so razumljivi, pregledni, enostavni za razvoj in so njihove »meje krhkosti« vidne takoj, je mogoče natančneje oceniti »razsežnost katastrofe«, ko se pojavijo nove zahteve, in čas, potreben za prenovo (če je potrebno).
Tako je podatkovni model eden glavnih artefaktov, ki jih je treba vzdrževati med razvojem sistema. V dobrem smislu bi moral biti "na mizi" za vsakega analitika, razvijalca itd. – vsi, ki sodelujejo pri projektih razvoja sistema.

Oblikovanje podatkovnih modelov je ločena, zelo obsežna tema. Obstajata dva glavna pristopa k oblikovanju skladišča.
Pristop je dober za jedro "entiteta-razmerje" - ko se na podlagi študije predmetnega področja, natančneje njegovega izbranega področja, zgradi normaliziran (3NF) model. Tukaj igra isti "korporativni model", o katerem smo razpravljali zgoraj.

Pri oblikovanju analitičnih vitrin primeren večdimenzionalni model . Ta pristop je primeren za razumevanje poslovnih uporabnikov. to je model, ki je preprost in priročen za človeško zaznavanje - ljudje delujejo z razumljivimi in znanimi koncepti metrike (kazalnikov) in odsekov, po katerih jih analiziramo. In to nam omogoča, da preprosto in jasno zgradimo postopek zbiranja zahtev - narišemo nabor "matric rezov in indikatorjev", ki komunicirajo s predstavniki različnih oddelkov. Nato ga združimo v eno strukturo - "model analize": oblikujemo "merilno vodilo" in določimo dejstva, ki so na njih definirana. Ob tem delamo na hierarhijah in pravilih združevanja.

Nato je zelo enostavno preiti na fizični model in dodati elemente optimizacije ob upoštevanju značilnosti DBMS. Na primer, za Oracle bi to bilo particioniranje, niz indeksov itd. Za Vertico bodo uporabljene druge tehnike – razvrščanje, segmentacija, razrez.
Morda bo potrebna tudi posebna denormalizacija - kadar namerno vnesemo redundanco v podatke, s čimer izboljšamo učinkovitost poizvedb, a hkrati zapletemo posodobitev podatkov (ker bo treba redundanco upoštevati in podpreti med proces nalaganja podatkov). Morda bomo morali za izboljšanje učinkovitosti izdelati tudi dodatne agregatne tabele ali uporabiti takšne dodatne funkcije DBMS, kot so projekcije v Vertici.

Torej pri modeliranju podatkov skladišča dejansko rešujemo več težav:

naloga je zgraditi konceptualni (logični) model jedra – sistemska in poslovna analiza – študij predmetnega področja, poglabljanje v detajle in upoštevanje odtenkov »živih podatkov« in njihove uporabe v poslovanju;
naloga izdelave analiznega modela – nato pa še konceptualnega (logičnega) modela izložb;
naloga gradnje fizičnih modelov je upravljanje redundance podatkov, optimizacija ob upoštevanju značilnosti DBMS za poizvedbe in nalaganje podatkov.

Pri razvoju konceptualnih modelov morda ne upoštevamo značilnosti določenega DBMS, za katerega oblikujemo strukturo baze podatkov. Poleg tega lahko uporabimo en konceptualni model za izdelavo več fizičnih modelov - za različne DBMS.

Naj povzamemo.

Podatkovni model ni niz »lepih slik«, proces oblikovanja pa ni postopek njihovega risanja. Model odraža naše razumevanje predmetnega področja. In proces njegovega sestavljanja je proces njegovega preučevanja in raziskovanja. Tu se izgublja čas. In sploh ne "risati in barvati".
Podatkovni model je artefakt oblikovanja, način za strukturirano izmenjavo informacij med člani ekipe. Da bi to naredili, mora biti razumljiv vsem (to zagotavlja zapis in razlaga) in dostopen (objavljen).
Podatkovni model se ne ustvari enkrat in zamrzne, ampak se ustvari in razvije v procesu razvoja sistema. Pravila za njen razvoj smo postavili sami. In lahko jih spremenimo, če vidimo, kako jih narediti boljše, enostavnejše, učinkovitejše.
Podatkovni model (fizični) vam omogoča, da združite in uporabite nabor najboljših praks, namenjenih optimizaciji – t.j. uporabite tehnike, ki so že delovale za ta DBMS.

Značilnosti projektov podatkovnih skladišč

Podrobneje se osredotočimo na značilnosti projektov, v okviru katerih podjetje gradi in razvija podatkovna skladišča. Pa jih poglejmo z vidika vpliva arhitekturnega vidika. Zakaj je za takšne projekte pomembno graditi arhitekturo in to od samega začetka. In prav prisotnost dobro premišljene arhitekture daje fleksibilnost projektu skladišča podatkov, omogoča učinkovito porazdelitev dela med izvajalci in tudi olajša napovedovanje rezultata in naredi proces bolj predvidljiv.

Data Warehouse je programska oprema po meri

Podatkovno skladišče je vedno »razvoj po meri«, ne pa škatlasta rešitev. Da, obstajajo panogo specifične aplikacije BI, ki vključujejo referenčni podatkovni model, vnaprej konfigurirane ETL procese iz običajnih virov (na primer sistemi ERP), nabor tipičnih nadzornih plošč in poročil BI. Toda v praksi se shranjevanje le redko izvaja - kot "škatla". S shranjevanjem se ukvarjam približno 10 let in še nikoli nisem videl takšne zgodbe. Vedno obstajajo nianse, povezane z edinstvenimi lastnostmi podjetja - tako poslovno kot IT pokrajino. Zato je nekoliko nepremišljeno upati, da bo »prodajalec«, ki zagotavlja rešitev, zagotovil arhitekturo. Arhitektura takšnih sistemov pogosto dozori znotraj same organizacije. Ali pa ga oblikujejo strokovnjaki izvajalca, ki je glavni izvajalec projekta.

Podatkovno skladišče je integracijski projekt

Podatkovno skladišče nalaga in obdeluje informacije iz številnih izvornih sistemov. In da bi z njimi ohranili "prijateljske odnose", morate biti z njimi izjemno previdni. Med drugim je treba čim bolj zmanjšati obremenitev izvornih sistemov, upoštevati okna »razpoložljivost in nedostopnost«, izbrati interakcijske vmesnike ob upoštevanju njihove arhitekture itd. Potem bo shramba sposobna zbirati podatke čim prej in z zahtevano frekvenco. V nasprotnem primeru boste "preneseni" v rezervno vezje, ki se ne posodablja z najbolj operativno frekvenco.
Poleg tega je treba upoštevati "človeški faktor". Integracija ni le interakcija strojev. To je tudi komunikacija med ljudmi.

Data Warehouse je timski projekt

V velikem podjetju takšen sistem le redkokdaj naredi samo ena ekipa. Praviloma tukaj deluje več ekip, od katerih vsaka rešuje določen problem.

Arhitektura naj zagotavlja možnost organizacije vzporednega dela, hkrati pa ohranja njeno celovitost in se izogiba podvajanju iste funkcionalnosti na različnih mestih s strani različnih ljudi. Poleg nepotrebnih stroškov dela lahko takšno podvajanje privede do kasnejših neskladij v podatkih.

Poleg tega, ko je v proces razvoja sistema vključenih toliko ljudi in ekip, pogosto razpršenih, se neizogibno postavlja vprašanje: kako zgraditi komunikacijsko in informacijsko interakcijo med njimi. Bolj ko se uporabljajo standardni in razumljivi pristopi in prakse, lažje, bolj priročno in učinkoviteje je vzpostaviti takšno delo. Vključno s tem je vredno razmišljati o sestavi "delovnih artefaktov", med katerimi so za podatkovna skladišča št. 1 podatkovni modeli (glej prejšnji razdelek).

Podatkovno skladišče ima daljšo življenjsko dobo v primerjavi z drugimi sistemi

Naj pojasnim - trditev velja za "živo", delujoče skladišče, integrirano s ključnimi viri, ki ima zgodovinske podatke in zagotavlja informacijske in analitične storitve številnim oddelkom podjetja.

Kakšne razloge imam, da tako verjamem?
Prvič, gradnja skladišča je zelo zahteven proces: poleg dejanskih stroškov opreme, licenc za potrebno tehnološko programsko opremo in razvoja so v to vključeni tudi skoraj vsi sistemi in oddelki podjetja. Ponoviti celoten postopek iz nič je zelo drzen podvig.

Drugič, če ima pomnilnik pravo arhitekturo, potem zlahka preživi tako spremembo izvornih sistemov, pojav novih zahtev končnih uporabnikov kot rast količine podatkov.
Če je arhitektura pravilna, informacijski tokovi so pregledni, potem je tak sistem mogoče razvijati dolgo časa, ne da bi pri spremembah zaradi težav pri ocenjevanju vpliva prišli v stanje stuporja.

Postopni iterativni razvoj

Zadnja stvar, ki bi si jo naročnik želel, ko se vključi v zgodbo s shrambo, je zamrzniti svoje potrebe za leto ali dve, dokler ni oblikovan celoten korporativni podatkovni model, se vsi viri v celoti povežejo itd.

Podatkovno skladišče v očeh strank pogosto izgleda kot absolutna pošast - naloge, cilji in obzorje razvoja sistema so tako obsežni. In pogosto se naročnik boji, da bo IT oddelek "na račun njegovega proračuna" rešil nekatere "lastne naloge". In spet se soočamo z vprašanjem interakcije med ljudmi in zmožnosti mirnega izražanja svojega stališča in pogajanja.

Kompetentni arhitekturni pristopi vam omogočajo, da sistem razvijate iterativno, postopoma povečujete funkcionalnost, ne da bi se več let »razvijali«, preden začnete dajati rezultate.

Čeprav je treba opozoriti, da se "čudeži ne dogajajo" - in tudi "začetek" zahteva čas. Pri shrambah je lahko precej velik - saj gre za velike količine podatkov, to so zgodovinski podatki - za stara obdobja, ko bi se pravila za obdelavo informacij lahko razlikovala od trenutnih. Zato je potrebno dovolj časa za analitični razvoj, interakcijo z izvornimi sistemi in vrsto poskusov in napak, vključno s preizkusi obremenitve na resničnih podatkih.

Podatkovna skladišča - "večprojektna zgodba"

Težko je izpostaviti eno samo poslovno stranko za podatkovno skladišče. In verjame se (ne brez razloga), da je ključni dejavnik uspeha skladiščnega projekta podpora vodstva podjetja - neposredno prve osebe.
Repozitorij je redko zgrajen in razvit znotraj enega samega projekta. Praviloma obstajajo različne potrebe po konsolidaciji podatkov in analitiki, za njimi so različne stranke in skupine uporabnikov. Zato se repozitorij pogosto razvija v okviru več vzporednih projektov.

Ravnovesje inovativnosti in preizkušenih rešitev

Kljub temu, da je tema shranjevanja zelo "starodavna" (če je takšna beseda uporabna za tako mlado industrijo, kot je IT) in precej konzervativna. Kljub temu napredek ne miruje - in omejitve, ki so prej obstajale zaradi dragih in počasnih diskov, dragega pomnilnika itd. - so zdaj odstranjeni. Hkrati pa je čas, da ponovno razmislimo o nekaterih arhitekturnih pristopih. Poleg tega to velja tako za tehnološke platforme kot za arhitekturo uporabnih sistemov, ki temeljijo na njih.

Tukaj je pomembno vzpostaviti ravnovesje - in ohraniti dokaj "zelen" pristop tako do virov kot do shranjenih informacij. V nasprotnem primeru lahko skladišče zelo hitro spremenite v napol strukturirano "smetišče", za katerega se bo, če ga bo uspelo urediti, kar precej potruditi.
Da, imamo več priložnosti, vendar to ne pomeni, da moramo zanikati vse prakse, ki so bile razvite in preizkušene s časom, ki so jasni, kako in zakaj uporabljati, in se "vdajati vsem resnim" le na čelu z meglenimi duh "inovacije".
Ohranjati ravnovesje pomeni uporabljati nove metode in pristope, kjer odpirajo nove priložnosti, hkrati pa uporabljati stare preizkušene za reševanje nujnih problemov, ki jih nihče ni preklical.
Kaj lahko storimo kot razvijalci in oblikovalci aplikativnih rešitev? Najprej poznati in razumeti tehnološke spremembe platform, na katerih delamo, njihove zmožnosti, lastnosti in omejitve uporabe.

Poglejmo si DBMS – kot najbolj kritično in pomembno tehnološko platformo za shranjevanje.
V zadnjem času je prišlo do očitnega premika relacijskih baz podatkov, ki so bile prvotno ustvarjene kot "univerzalne", proti specializaciji. Vodilni prodajalci že dolgo izdajajo različne možnosti - za aplikacije različnih razredov (OLTP, DSS & DWH). Poleg tega obstajajo dodatne možnosti za delo z besedilom, geografskimi podatki itd.

A zadeva ni bila omejena le na to – pojavljati so se začeli izdelki, ki so bili sprva osredotočeni na določen razred nalog – t.j. specializirani DBMS. Lahko uporabljajo relacijski model ali pa tudi ne. Pomembno je, da so sprva »nabrušeni« ne le za shranjevanje in obdelavo »poslovnih informacij« na splošno, temveč za določene naloge.

Očitno sta centralizacija in specializacija dva komplementarna trenda, ki se občasno zamenjata in zagotavljata razvoj in ravnovesje. Pa tudi evolucijski (postopni) postopen razvoj in kardinalne spremembe. Tako je bil v 90. letih Michael Stonebreaker eden od avtorjev Manifesta baze podatkov generacije III, ki je jasno zvenel idejo, da svet ne potrebuje še ene revolucije v svetu baz podatkov. Vendar 10 let pozneje objavlja dela, v katerih napoveduje predpogoje za začetek nove dobe v svetu DBMS – prav na podlagi njihove specializacije.
Osredotoča se na dejstvo, da so razširjeni univerzalni DBMS zgrajeni na arhitekturi »ena velikost za vse«, ki ne upošteva sprememb v platformah strojne opreme ali delitve aplikacij na razrede, za katere lahko najdete boljšo rešitev kot izvajanje univerzalnih zahtev.
In v skladu s to idejo začne razvijati številne projekte. Eden od njih je C-Store, stolpčasti DBMS, zasnovan v arhitekturi nič v skupni rabi (SN), prvotno ustvarjen posebej za sisteme razredov za shranjevanje podatkov. Ta izdelek je bil nadalje komercializiran kot HP Vertica.

Zdi se, da je zdaj tema razvoja podatkovnih skladišč zdrsnila v nov krog razvoja. Pojavljajo se nove tehnologije, pristopi in orodja. Njihovo preučevanje, testiranje in razumna uporaba nam omogoča ustvarjanje res zanimivih in uporabnih rešitev. In jih spravite v izvedbo, uživajte v dejstvu, da se vaš razvoj uporablja v resničnem delu in prinaša koristi.

Epilog

Pri pripravi tega članka sem se skušal osredotočiti predvsem na arhitekte, analitike in razvijalce, ki neposredno delajo s podatkovnimi skladišči. A izkazalo se je, da sem neizogibno "temo vzel malo širše" - in druge kategorije bralcev so padle v vidno polje. Nekatere točke se bodo zdele sporne, nekatere niso jasne, nekatere so očitne. Ljudje smo različni – z različnimi izkušnjami, ozadjem in položaji.
Na primer, tipična vprašanja menedžerjev so "kdaj pritegniti arhitekte?", "Kdaj naj se ukvarjam z arhitekturo?", "Arhitektura – ali ne bo predrago?" za nas (razvijalce, oblikovalce) zveni precej čudno, saj se za nas arhitektura sistema pojavi z njegovim rojstvom - ni pomembno, ali se tega zavedamo ali ne. In tudi če v projektu ni formalne vloge arhitekta, običajni razvijalec vedno »vklopi svojega notranjega arhitekta«.

V veliki shemi stvari ni pomembno, kdo je arhitekt, pomembno je, da nekdo postavi ta vprašanja in razišče odgovore nanje. Če je arhitekt jasno izpostavljen, to pomeni le, da je on v prvi vrsti odgovoren za sistem in njegov razvoj.
Zakaj se mi je v zvezi s to temo zdela aktualna tema »antifragilnosti«?

"Edinstvenost antifragilnosti je v tem, da nam omogoča, da delamo z neznanim, naredimo nekaj v razmerah, ko ne razumemo, kaj točno počnemo - in uspemo"/Nassim N.Taleb/

Zato kriza in visoka stopnja negotovosti nista opravičilo za pomanjkanje arhitekture, ampak dejavnika, ki krepijo njeno potrebo.