Acest articol se va concentra pe arhitectura depozitului de date. Ce trebuie să urmați atunci când îl construiți, ce abordări funcționează - și de ce.

„Basmul este o minciună, dar există un indiciu în el...”

Bunicul a plantat... un depozit. Și a crescut un depozit mare, foarte mare. Pur și simplu nu știam cum funcționează. Și bunicul meu a început o recenzie. Bunicul a chemat-o pe bunica, nepoata, pisica și șoarecele la un consiliu de familie. Și spune următorul subiect: „Unitatea noastră de depozitare a crescut. Datele din toate sistemele curg împreună, tabelele sunt vizibile și invizibile. Utilizatorii își pregătesc propriile rapoarte. Totul pare să fie bine - trăiți și trăiți. Există o singură tristețe - nimeni nu știe cum funcționează. Necesită discuri, aparent sau invizibil - nu te poți sătura! Și atunci utilizatorii s-au obișnuit să vină la mine cu diverse reclamații: uneori raportul îngheață, alteori datele sunt depășite. În caz contrar, este un dezastru complet - venim cu rapoarte către Părintele-Țar, dar cifrele nu sunt de acord între ele. Ora nu este niciodată sigură – regele va fi supărat – atunci nici eu, nici tu nu ne vom pierde capul. Așa că am decis să vă adun și să vă consult: ce vom face?”

S-a uitat în jurul întâlnirii și a întrebat:
- Tu, bunico, știi cum este aranjat depozitul nostru?
- Nu, bunicule, nu știu. Și de unde să știu? Sunt niște băieți curajoși care îl păzesc! Ce mustață! Nu te vei apropia. Am fost într-o zi să-i vizitez și am copt niște plăcinte. Și au mâncat plăcintele, și-au șters mustața și au spus: „De ce ai venit, bunico? Ce fel de depozitare ai nevoie? Spune-ne doar ce fel de raport ai nevoie și îl vom face pentru tine! Principalul lucru este să aduci plăcinte mai des! Sunt prea gustoase.”
- Și tu, nepoată iubită, știi cum funcționează depozitul nostru?
- Nu, bunicule, nu știu. Mi-au dat cumva acces la el. M-am conectat, m-am uitat - și erau mese - aparent și invizibil. Și altele diferite sunt ascunse în diagrame. Ochii fug... Am fost confuz la început. Și apoi m-am uitat mai atent - unele dintre ele erau goale, altele erau pline, dar doar pe jumătate. Și datele par să se repete. Nu e de mirare că nu poți obține suficiente discuri, cu o asemenea redundanță!
- Păi, pisică, ce poți spune despre depozitul nostru? Este ceva bun în asta?
- Cum să nu o spun, bunicule, o voi spune. La cererea nepoatei mele, am încercat să fac un pilot într-un model separat – o vitrină mică. Pentru a înțelege ce comerț este profitabil pentru statul nostru - ce produse sunt bune pentru comercianți, plătesc tribut - vistieria este completată. Și care sunt cu adevărat rele. Și am început să selectez date pentru mine din acest depozit. Am adunat fapte. Și a început să încerce să le compare cu produsele. Și ce, bunicule, am văzut - produsele par să fie la fel, dar când te uiți la semne, sunt diferite! Apoi am început să le pieptăn cu pieptene nepoatei mele. Zgâriat și zgâriat - și a dus la o anumită uniformitate, mângâind ochiul. Dar devreme m-am bucurat - a doua zi mi-am lansat scripturile pentru a actualiza datele minunate din fereastra de afișare - și totul a mers prost pentru mine! "Cum așa?" - Cred că - nepoata mea va fi supărată - astăzi ar trebui să-i arătăm ministrului pilotului nostru. Cum putem merge cu astfel de date?
- Da, spui povești triste, pisică. Ei bine, șoricelule, chiar nu ai încercat să afli despre depozitul? Ești o fată plină de viață, agilă, sociabilă! Ce ne vei spune?
- De ce, bunicule, de ce să nu încerci? Desigur, sunt un șoarece tăcut, dar agil. Odată, nepoata pisicii mi-a cerut să obțin un model de date din depozitul nostru de stat. Și pisica, desigur, a venit la mine - toată speranța mea este în tine, spune el, șoarece! Ei bine, de ce să nu faci o faptă bună pentru oameni buni (și pisici)? Am mers la castel, unde șeful depozitului ascunde modelul de date într-un seif. Și ea s-a ascuns. Am așteptat până când a scos modelul acela din seif. Imediat ce a ieșit să ia o cafea, am sărit pe masă. Ma uit la model si nu inteleg nimic! Cum așa? Nu recunosc depozitul nostru! Avem mii de nenumărate tabele, fluxuri nesfârșite de date! Și aici - totul este armonios și frumos... S-a uitat la acest model și l-a pus înapoi în seif.
- Da, ne-ai spus lucruri foarte ciudate, șoarece.
Bunicul se gândi profund.
- Ce vom face, prieteni? La urma urmei, nu veți trăi mult timp cu așa și așa stocare... Utilizatorii își vor pierde în curând răbdarea complet.

Indiferent ce decide bunicul nostru din basm - să construiască o nouă unitate de depozitare sau să încerce să reînvie una existentă - trebuie să tragem concluzii înainte de a „sufleca mânecile” din nou.
Să lăsăm deoparte aspectele organizatorice – precum pericolul concentrării expertizei într-un anumit îngust grup închis, lipsa proceselor de control și asigurarea transparenței arhitecturii sistemelor utilizate în întreprindere etc.
Astăzi aș dori să mă concentrez pe construirea arhitecturii unui anumit sistem (sau grup de sisteme) - depozite de date. Ceea ce trebuie menținut în atenție în primul rând atunci când o organizație este pe cale să construiască un sistem atât de complex și costisitor precum stocarea.

Debriefing

Nici unul dintre noi, care lucrează la crearea și dezvoltarea vreunui sistem, nu vrea să se dovedească a fi o soluție „improvizată”, sau o soluție care „se va „stinge” într-un an sau doi, pentru că nu va putea îndeplini cerințele și așteptările Clienților și Afacerilor. Indiferent cât de puternică este observată astăzi o părtinire față de „metodologiile agile”, este mult mai plăcut pentru o persoană să se simtă un „maestru” care face viori decât un artizan care tăie bețe pentru tobe de unică folosință.
Intenția noastră sună naturală: să facem sisteme solide și de înaltă calitate, care să nu ne impună să „veghem de noapte cu dosar” în mod regulat, pentru care să nu ne fie rușine în fața utilizatorilor finali și care să nu arate ca un „cutie neagră” tuturor adepților „neinițiați”.

Mai întâi, să facem o listă probleme tipice, pe care îl întâlnim în mod regulat atunci când lucrăm cu spații de depozitare. Să scriem doar ce avem – deocamdată, fără a încerca să organizăm și să oficializăm.

În principiu, avem un depozit bun: dacă nu îl atingi, atunci totul funcționează. Adevărat, de îndată ce este necesară o schimbare, încep „colapsurile locale”.
Datele sunt încărcate zilnic, conform reglementărilor, într-un singur proces mare, în decurs de 8 ore. Și asta ni se potrivește. Dar dacă apare brusc o defecțiune, aceasta necesită intervenție manuală. Și apoi totul poate funcționa imprevizibil pentru o lungă perioadă de timp, pentru că... va fi necesară participarea umană la proces.
Lansarea a sosit - așteptați-vă la probleme.
O sursă nu a putut furniza date la timp - toate procesele sunt în așteptare.
Integritatea datelor este controlată de baza de date - astfel încât procesele noastre se blochează cu o eroare atunci când aceasta este încălcată.
Avem un depozit foarte mare - 2000 de mese într-una schema generala. Și încă 3000 în multe alte scheme. Deja avem prea puțină idee cum funcționează și din ce motiv au apărut. Prin urmare, ne poate fi dificil să reutilizam ceva. Și multe probleme trebuie rezolvate din nou. Pentru că este mai ușor și mai rapid (decât să înțelegi „codul altcuiva”). Ca urmare, avem discrepanțe și funcționalități duplicate.
Ne așteptăm ca sursa să furnizeze date de calitate. Dar se dovedește că nu este așa. Drept urmare, petrecem mult timp reconciliând rapoartele noastre finale. Și au avut mare succes în asta. Avem chiar și un proces simplificat. Adevărat, este nevoie de timp. Dar utilizatorii sunt obișnuiți să...
Utilizatorul nu are întotdeauna încredere în rapoartele noastre și necesită o justificare pentru aceasta sau aceea cifră. În unele cazuri are dreptate, iar în altele greșește. Dar ne este foarte greu să le justificăm, pentru că... Nu oferim instrumente de „analiza de la capăt la capăt” (sau linia datelor).
Am putea atrage dezvoltatori suplimentari. Dar avem o problemă - cum le putem include în munca noastră? Cum să paralelizezi cel mai eficient lucrul?
Cum să dezvoltăm sistemul treptat, fără a petrece un an întreg pentru a dezvolta „nucleul sistemului”?
Depozitul de date este asociat cu modelul de întreprindere. Dar știm sigur (am văzut-o în banca XYZ) că construirea unui model poate dura o perioadă infinită de timp (în banca XYZ au mers și au discutat despre entități de afaceri timp de șase luni, fără nicio mișcare). De ce are nevoie de el? Sau poate e mai bine fără ea, dacă sunt atâtea probleme cu ea? Poate poate fi generat cumva?
Am decis să rulăm modelul. Dar cum să dezvolte sistematic un model de date de depozit? Avem nevoie de „reguli ale jocului” și care ar putea fi acestea? Ce ne va oferi asta? Dacă facem o greșeală cu modelul?
Ar trebui să salvăm datele sau istoricul modificărilor acestora, dacă „afacerea nu are nevoie de ele”? Nu aș vrea să „stochez gunoiul” și să complic utilizarea acestor date pentru sarcini reale. Ar trebui ca depozitul să păstreze istoricul? Cum este? Cum funcționează stocarea în timp?
Ar trebui să încercăm să unificăm datele din stocare dacă avem un sistem de management al datelor master? Dacă există MDM, înseamnă că întreaga problemă a datelor master este acum rezolvată?
În curând se așteaptă să înlocuim sistemele de contabilitate cheie. Ar trebui să fie pregătit depozitul de date pentru modificările sursei? Cum să realizezi acest lucru?
Avem nevoie de metadate? Ce ne referim prin asta? Unde mai exact pot fi folosite? Cum poate fi implementat? Trebuie ținute „într-un singur loc”?
Clienții noștri sunt extrem de instabili în ceea ce privește cerințele și dorințele lor - ceva se schimbă în mod constant. În general, afacerea noastră este foarte dinamică. Atâta timp cât facem ceva, devine inutil. Cum ne putem asigura că oferim rezultate cât mai repede posibil – cum ar fi prăjiturile calde?
Utilizatorii cer eficiență. Dar nu putem rula procesele noastre principale de descărcare des, deoarece... aceasta încarcă sistemele sursă (afectează grav performanța) - prin urmare, adăugăm fluxuri de date suplimentare - care vor lua exact ceea ce avem nevoie. Adevărat, există o mulțime de fire. Și apoi vom arunca câteva dintre date. În plus, va exista o problemă de convergență. Dar nu există altă cale...

Au fost deja destul de multe. Dar nu este lista plina– este ușor de completat și dezvoltat. Nu îl vom ascunde în tabel, ci îl vom agăța într-un loc vizibil - păstrând aceste probleme în centrul atenției noastre pe măsură ce lucrăm.
Sarcina noastră este să dezvoltăm în cele din urmă o soluție cuprinzătoare.

Antifragilitate

Privind lista noastră, putem trage o concluzie. Nu este dificil să creezi un fel de „bază de date pentru raportare”, să adaugi date acolo sau chiar să construiești un fel de procese de reglementare pentru actualizarea datelor. Sistemul începe să trăiască cumva, apar utilizatorii, iar odată cu ei obligații și SLA-uri, apar noi cerințe, se conectează surse suplimentare, se schimbă metodologiile - toate acestea trebuie luate în considerare în procesul de dezvoltare.

După ceva timp imaginea arată așa:
„Aici este camera de depozitare. Și funcționează dacă nu îl atingi. Problemele apar atunci când trebuie să schimbăm ceva.”

Sosește la noi o schimbare, al cărei impact nu suntem în stare să-l evaluăm și să-l înțelegem (din moment ce nu am introdus astfel de instrumente în sistem inițial) - și pentru a nu ne asumăm riscuri, nu atingem ceea ce este acolo, ci facem altul. extensie pe lateral, și alta, și, de asemenea, - transformând soluția noastră în mahalale, sau, după cum se spune în America Latină, „favelas”, în care până și poliției le este frică să intre.
Există un sentiment de pierdere a controlului asupra propriului sistem, haos. Sunt necesare din ce în ce mai multe mâini pentru a sprijini procesele existente și pentru a rezolva probleme. Și a face schimbări devine din ce în ce mai dificil. Cu alte cuvinte, sistemul devine instabil la stres și neadaptabil la schimbare. Și, în plus, există o dependență puternică de personajele care „cunosc fairway-ul”, deoarece nimeni nu are o „hartă”.

Această proprietate a unui obiect este să se prăbușească sub influența haosului, a evenimentelor întâmplătoare și a șocurilor - sună Nassim Nicholas Taleb fragilitate . Și introduce, de asemenea, conceptul opus: antifragilitate – atunci când un obiect nu este distrus de stres și accidente, ci primește beneficii directe de pe urma acestuia. („Antifragil. Cum să beneficiezi de haos”)
Altfel se poate apela adaptabilitate sau rezistenta la schimbare .

Ce înseamnă asta în acest context? Care sunt „sursele haosului” pentru sistemele IT? Și ce înseamnă să „beneficiezi de haos” din perspectiva arhitecturii IT?
Primul gând care îmi vine în minte sunt schimbările care vin din exterior. Care este lumea exterioară pentru sistem? Pentru depozitare în special. Desigur, în primul rând, există modificări de la sursele de date pentru stocare:

modificarea formatelor datelor primite;
înlocuirea unui sistem sursă de date cu altul;
modificarea regulilor/platformelor de integrare a sistemului;
modificarea interpretărilor datelor (formatele sunt păstrate, logica lucrului cu datele se modifică);
modificarea modelului de date dacă integrarea se face la nivel de date (analizarea fișierelor jurnal de tranzacții ale bazei de date);
creșterea volumelor de date - în timp ce în sistemul sursă erau puține date și încărcarea era mică - o puteai prelua oricând, cu orice solicitare grea, datele și încărcarea creșteau - acum există restricții stricte;
etc.

Sistemele sursă în sine, compoziția informațiilor și structura acesteia, tipul de interacțiune de integrare, precum și însăși logica de lucru cu datele se pot schimba. Fiecare sistem implementează propriul model de date și abordări de lucru cu acestea, care îndeplinesc scopurile și obiectivele sistemului. Și oricât de mult se străduiește să unifice modelele industriale și practicile de referință, nuanțele vor apărea inevitabil. (În plus, procesul de unificare a industriei în sine nu face progrese prea mari din diverse motive.)
Cultura de lucru cu datele corporative - prezența și controlul arhitecturii informaționale, un model semantic unificat, sistemele de gestionare a datelor de bază (MDM) facilitează oarecum sarcina de consolidare a datelor într-un depozit, dar nu exclude necesitatea acesteia.

Nu sunt inițiate modificări mai puțin critice de către consumatorii de stocare (modificări ale cerințelor):

anterior existau date suficiente pentru a construi un raport - acum era necesar să se conecteze câmpuri suplimentare sau o nouă sursă de date;
Tehnicile de procesare a datelor implementate anterior sunt depășite - algoritmii și tot ceea ce este afectat trebuie reluat;
Anterior, toată lumea era mulțumită de valoarea actuală a atributului director de pe panoul de informații - acum este necesară o valoare care este relevantă la momentul apariției faptului/evenimentului analizat;
a apărut o cerință pentru profunzimea istoricului de stocare a datelor, care nu exista înainte - să stocați datele nu timp de 2 ani, ci timp de 10 ani;
Anterior, existau suficiente date de la „sfârșitul zilei/perioadei” - acum aveți nevoie de starea datelor „într-o zi”, sau la momentul unui anumit eveniment (de exemplu, luarea unei decizii cu privire la o cerere de împrumut - pentru Basel II);
Anterior, eram mulțumiți de raportarea datelor pentru ieri (T-1) sau mai târziu, acum avem nevoie de T0;
etc.

Atât interacțiunile de integrare cu sistemele sursă, cât și cerințele de la consumatorii de date din depozit sunt factori externi pentru depozitul de date: unele sisteme sursă le înlocuiesc pe altele, volumele de date cresc, formatele de date primite se modifică, cerințele utilizatorilor se modifică etc. Și toate acestea sunt schimbări externe tipice pentru care sistemul nostru - stocarea noastră - trebuie să fie pregătit. Cu arhitectura potrivită, nu ar trebui să distrugă sistemul.

Dar asta nu este tot.
Când vorbim despre variabilitate, ne amintim în primul rând factorii externi. La urma urmei, în interior putem controla totul, așa credem, nu? Da și nu. Da, majoritatea factorilor care se află în afara zonei de influență sunt externi. Dar există și „entropie internă”. Și tocmai din cauza prezenței sale trebuie uneori să ne întoarcem „la punctul 0”. Începe jocul de la capăt.
În viață, adesea avem tendința de a începe de la zero. De ce este aceasta caracteristică pentru noi? Și e așa de rău?
Aplicat la IT. Acesta poate fi un lucru foarte bun pentru sistemul în sine - posibilitatea de a reconsidera deciziile individuale. Mai ales când o putem face local. Refactorizarea este procesul de desfacere a „web-ului” care apare periodic în procesul de dezvoltare a sistemului. Revenirea la început poate fi de ajutor. Dar are un preț.
Cu o gestionare adecvată a arhitecturii, acest preț este redus - iar procesul de dezvoltare a sistemului în sine devine mai controlat și mai transparent. Un exemplu simplu: dacă se respectă principiul modularității, puteți rescrie un modul separat fără a afecta interfețe externe. Și acest lucru nu se poate face cu o structură monolitică.

Antifragilitatea unui sistem este determinată de arhitectura care este încorporată în acesta. Și tocmai această proprietate îl face adaptabil.
Când vorbim despre arhitectură adaptivă– ne referim la faptul că sistemul este capabil să se adapteze la schimbări și deloc că schimbăm constant arhitectura în sine. Dimpotrivă, cu cât arhitectura este mai stabilă și mai stabilă, cu atât mai puține cerințe care presupun revizuirea acesteia, cu atât sistemul este mai adaptabil.

Soluțiile care presupun revizuirea întregii arhitecturi vor avea un preț mult mai mare. Și pentru a le accepta trebuie să ai motive foarte bune. De exemplu, o astfel de bază ar putea fi o cerință care nu poate fi implementată în cadrul arhitecturii existente. Apoi se spune că a apărut o cerință care afectează arhitectura.
Prin urmare, trebuie să ne cunoaștem și „limitele de antifragilitate”. Arhitectura nu este dezvoltată „în vid” - se bazează pe cerințele și așteptările actuale. Și dacă situația se schimbă fundamental, trebuie să înțelegem că am depășit arhitectura actuală - și trebuie să o reconsiderăm, să dezvoltăm o soluție diferită - și să ne gândim la modalități de tranziție.
De exemplu, am presupus că vom avea întotdeauna nevoie de date în stocare la sfârșitul zilei; vom colecta date zilnic folosind interfețe standard de sistem (printr-un set de vizualizări). Apoi au venit solicitări din partea departamentului de management al riscului cu privire la necesitatea de a primi date nu la sfârșitul zilei, ci la momentul luării unei decizii privind creditarea. Nu este nevoie să încerci să „întinzi ceea ce nu este întins” - trebuie doar să recunoști acest fapt - cu cât mai devreme, cu atât mai bine. Și începeți să lucrați la o abordare care ne va permite să rezolvăm problema.
Există o linie foarte fină aici - dacă luăm în considerare doar „cerințele momentului” și nu privim câțiva pași înainte (și câțiva ani înainte), atunci creștem riscul de a întâlni și o cerință care are impact asupra arhitecturii târziu - iar costul schimbărilor noastre va fi foarte mare. Privind puțin înainte - în limitele orizontului nostru - nu a făcut niciodată rău nimănui.

Exemplul unui sistem din „basmul de stocare” este tocmai un exemplu de sistem foarte instabil construit pe abordări de design fragile. Și dacă se întâmplă acest lucru, distrugerea are loc destul de repede, tocmai pentru această clasă de sisteme.
De ce pot spune asta? Subiectul stocării nu este nou. Abordările și practicile de inginerie care au fost dezvoltate în acest timp au vizat tocmai acest lucru - păstrarea viabilității sistemului.
Un exemplu simplu: unul dintre cele mai frecvente motive pentru eșecul proiectelor de stocare „la decolare” este încercarea de a construi stocare pe deasupra sistemelor sursă care sunt în curs de dezvoltare, fără a fi de acord asupra interfețelor de integrare - o încercare de a prelua datele direct din Mese. Ca urmare, au intrat în dezvoltare - în acest timp baza de date sursă s-a schimbat - și fluxurile de încărcare în stocare au devenit inoperabile. E prea târziu să refac ceva. Și dacă încă nu v-ați asigurat făcând mai multe straturi de mese în interiorul depozitului, atunci puteți arunca totul și începe din nou. Acesta este doar un exemplu și unul dintre cele simple.

Criteriul lui Taleb pentru fragil și antifragil este simplu. Judecătorul principal este timpul. Dacă un sistem trece testul timpului și își arată „supraviețuirea” și „indestructibilitatea”, are proprietatea de antifragilitate.
Dacă, atunci când proiectăm un sistem, luăm în considerare antifragilitatea ca o cerință, atunci acest lucru ne va încuraja să folosim astfel de abordări pentru construirea arhitecturii sale care să facă sistemul mai adaptabil atât la „haos din exterior”, cât și „haos din interior”. .” Și în cele din urmă sistemul va avea o durată de viață mai lungă.
Niciunul dintre noi nu vrea să facă „cladiri temporare”. Și nu vă înșelați că este imposibil să faceți altfel astăzi. A privi cu câțiva pași înainte este normal pentru o persoană în orice moment, mai ales în timpul unei crize.

Ce este un depozit de date și de ce îl construim?

Un articol despre arhitectura de stocare presupune că cititorul nu numai că este conștient de ceea ce este, ci are și o anumită experiență cu sisteme similare. Cu toate acestea, am considerat că este necesar să fac asta - să mă întorc la origini, la începutul drumului, pentru că... Aici se află „fulcrul” dezvoltării.

Cum au ajuns oamenii la concluzia că sunt necesare depozite de date? Și cu ce diferă de doar „foarte baza mare date"?
Cu mult timp în urmă, când în lume existau pur și simplu „sisteme de procesare a datelor de afaceri”, nu exista o împărțire a sistemelor IT în clase precum sisteme oltp front-end, dss back-office, sisteme de procesare a datelor text, depozite de date etc. .
Acesta a fost momentul în care primul SGBD relațional, Ingres, a fost creat de Michael Stonebreaker.
Și acesta a fost momentul în care era computerelor personale a izbucnit în industria computerelor ca un vârtej și a schimbat pentru totdeauna toate ideile comunității IT din acea vreme.

Pe atunci, era ușor să găsești aplicații de întreprindere scrise pe baza SGB-urilor de tip desktop, cum ar fi Clipper, dBase și FoxPro. Iar piața aplicațiilor client-server și DBMS tocmai câștiga amploare. Unul după altul, au apărut servere de baze de date care își vor ocupa mult timp nișa în spațiul IT - Oracle, DB2 etc.
Iar termenul „aplicație de bază de date” era comun. Ce a inclus această aplicație? Simplificat - unele formulare de introducere prin care utilizatorii puteau introduce simultan informații, unele calcule care erau lansate „prin buton” sau „în program”, precum și unele rapoarte care puteau fi văzute pe ecran sau salvate ca fișiere și trimise pentru sigilare.
"Nimic special - aplicare normală, doar că există o bază de date”, așa cum a remarcat unul dintre mentorii mei într-un stadiu incipient al carierei mele. „Nu este nimic special?” - M-am gândit atunci.

Dacă te uiți cu atenție, există încă câteva caracteristici. Pe măsură ce utilizatorii cresc, volumul informațiilor primite crește, iar sarcina asupra sistemului crește, dezvoltatorii și designerii săi recurg la anumite „trucuri” pentru a menține performanța la un nivel acceptabil. Primul lucru este împărțirea unui „sistem de procesare a datelor de afaceri” monolitic într-o aplicație de contabilitate care sprijină munca utilizatorilor on-line și o aplicație separată pentru procesarea și raportarea datelor pe lot. Fiecare dintre aceste aplicații are propria sa bază de date și este chiar găzduită pe o instanță separată a serverului de baze de date, cu setări diferite pentru diferite tipuri de încărcare - OLTP și DSS. Și fluxurile de date sunt construite între ele.

Asta este tot? S-ar părea că problema este rezolvată. Ce se întâmplă în continuare?
Și apoi companiile cresc, nevoile lor de informații se înmulțesc. Numărul de interacțiuni cu lumea exterioară este, de asemenea, în creștere. Și, în cele din urmă, nu există o aplicație mare care automatizează complet toate procesele, ci mai multe dintre ele diferiți producători. Numărul de sisteme care generează informații – sisteme surse de date – într-o companie este în creștere. Și mai devreme sau mai târziu, va fi nevoie să vedem și să comparăm informațiile obținute din sisteme diferite. Așa apar depozitele de date în companie - o nouă clasă de sisteme.
Definiție general acceptată din această clasă sistemele sună așa.

Depozit de date (sau depozit de date)– o bază de date cu informații orientate pe subiecte special concepute și destinate întocmirii de rapoarte și analize de afaceri pentru a sprijini luarea deciziilor într-o organizație

Prin urmare, consolidare date din sisteme diferite, capacitatea de a le privi într-un anumit mod „unic” (unificat) este una dintre proprietățile cheie ale sistemelor de clasă de depozit de date. Acesta este motivul pentru care stocarea a apărut în timpul evoluției sistemelor IT.

Caracteristicile cheie ale depozitelor de date

Să aruncăm o privire mai atentă. Care caracteristici cheie au aceste sisteme? Ce diferențiază depozitele de date de alte sisteme IT de întreprindere?

În primul rând, acestea sunt volume mari. Foarte mare. VLDB – aceasta este ceea ce furnizorii de top numesc astfel de sisteme atunci când își fac recomandări cu privire la utilizarea produselor lor. Din toate sistemele companiei, datele curg în această mare bază de date și sunt stocate acolo „veșnic și imuabil”, așa cum se spune în manuale (în practică, viața se dovedește a fi mai complicată).

În al doilea rând, acestea sunt date istorice - „Memorie corporativă” – așa se numesc depozitele de date. În ceea ce privește lucrul cu timpul în spațiile de depozitare, totul este destul de interesant. În sistemele de contabilitate, datele sunt actuale în acest moment. Apoi utilizatorul efectuează o anumită operație și datele sunt actualizate. Cu toate acestea, istoricul modificărilor poate să nu fie păstrat - acest lucru depinde de practicile contabile. Luați soldul contului dvs. bancar, de exemplu. S-ar putea să fim interesați de soldul actual din „acum”, la sfârșitul zilei sau la momentul unui eveniment (de exemplu, la momentul calculării punctajului). Dacă primele două sunt rezolvate destul de simplu, atunci ultima va necesita cel mai probabil eforturi speciale. Utilizatorul, lucrând cu stocarea, poate accesa perioadele trecute, le poate compara cu cea actuală etc. Tocmai astfel de capabilități legate de timp sunt cele care disting semnificativ depozitele de date de sistemele contabile - obținând starea datelor în diferite puncte de pe axa timpului - până la o anumită profunzime în trecut.

În al treilea rând, aceasta consolidare Și unificarea datelor . Pentru ca analiza lor comună să devină posibilă, este necesar să le aducem la o formă comună - model de date unificat , comparați faptele cu cărți de referință unificate. Pot exista mai multe aspecte și dificultăți aici. În primul rând - conceptual – oameni diferiți din departamente diferite pot înțelege lucruri diferite sub același termen. Și invers - a numi ceva diferit, care este în esență același lucru. Cum să asigurăm o „vedere unică” și, în același timp, să menținem specificul viziunii unui anumit grup de utilizatori?

În al patrulea rând, acesta este lucrul cu calitatea datelor . În timpul procesului de încărcare a datelor în depozit, se efectuează curățarea datelor, transformări și transformări generale. Transformările generale trebuie făcute într-un singur loc - și apoi utilizate pentru a construi diverse rapoarte. Se vor evita astfel discrepanțele care provoacă atât de multă iritare pentru utilizatorii de business - în special pentru management, cărora li se prezintă numere de la diferite departamente care nu sunt de acord între ele. Calitatea slabă a datelor dă naștere la erori și discrepanțe în rapoarte, a căror consecință este o scădere a nivelului de încrederea utilizatorilor întregului sistem, întregului serviciu analitic în ansamblu.

Concept arhitectural

Oricine a întâlnit o instalație de depozitare a observat cel mai probabil un fel de „structură stratificată” - deoarece. Această paradigmă arhitecturală este cea care a prins rădăcini pentru sistemele din această clasă. Și nu întâmplător. Straturile de stocare pot fi percepute ca componente separate ale sistemului - cu propriile sarcini, domenii de responsabilitate și „reguli ale jocului”.
Arhitectura stratificată este un mijloc de a face față complexității sistemului - fiecare nivel ulterior este extras din complexitățile implementării interne a celui precedent. Această abordare vă permite să identificați probleme similare și să le rezolvați într-un mod uniform, fără a reinventa „bicicleta” de la zero de fiecare dată.
Diagrama arhitecturală conceptuală este prezentată schematic în figură. Aceasta este o diagramă simplificată care reflectă doar ideea cheie - conceptul, dar fără „detaliile anatomice” care vor apărea odată cu o elaborare mai profundă a detaliilor.

După cum se arată în diagramă, evidențiem conceptual următoarele straturi. Trei straturi principale care conțin zona de stocare a datelor (indicată printr-un dreptunghi umplut) și software de încărcare a datelor (indicat în mod convențional prin săgeți de aceeași culoare). Și, de asemenea, un nivel auxiliar - serviciu, care totuși joacă un rol de conectare foarte important - managementul încărcării datelor și controlul calității.

Primary Data Layer - stratul de date primar (sau punerea în scenă , sau stratul de operare ) - destinat încărcării din sistemele sursă și salvării informațiilor primare, fără transformare - în calitate originalași sprijin pentru o istorie completă a schimbărilor.
Scopul acestui strat– extrageți straturile ulterioare de stocare din structura fizică a surselor de date, metode de colectare a datelor și metode de izolare a modificărilor deltei.

Core Data Layer - nucleu de stocare – o componentă centrală a sistemului care diferențiază depozitul de doar o „platformă de integrare în loturi” sau un „bascul de date mari”, deoarece rolul său principal este consolidarea datelor din surse diferite, reducerea la structuri unificate, chei. La încărcarea în nucleu sunt efectuate principalele lucrări cu calitatea datelor și transformări generale, care pot fi destul de complexe.
Scopul acestui strat– abstragați-vă consumatorii de particularitățile structurii logice a surselor de date și de necesitatea de a compara datele din diferite sisteme, asigurați integritatea și calitatea datelor.

Data Mart Layer - vitrine analitice – o componentă a cărei funcție principală este transformarea datelor în structuri convenabile pentru analiză (dacă BI lucrează cu vitrine, atunci acesta este de obicei un model dimensional), sau conform cerințelor sistemului de consum.
De regulă, vitrinele preiau date din nucleu - ca sursă de încredere și verificată - de exemplu. utilizați serviciul acestei componente pentru a aduce datele într-un singur formular. Vom chema astfel de vitrine regulat . În unele cazuri, vitrinele pot prelua date direct din staging - folosind date primare (în cheile sursă). Această abordare este de obicei utilizată pentru sarcinile locale în care nu este necesară consolidarea datelor din diferite sisteme și în care eficiența este mai importantă decât calitatea datelor. Se numesc astfel de vitrine operațional . Unii indicatori analitici pot avea metode de calcul foarte complexe. Prin urmare, pentru astfel de calcule și transformări non-triviale, așa-numitele vitrine secundare .
Sarcină layer de prezentare– pregătirea datelor conform cerințelor unui anumit consumator - platformă BI, grup de utilizatori sau sistem extern.

Straturile descrise mai sus constau dintr-o zonă de stocare a datelor persistente, precum și un modul software pentru încărcarea și transformarea datelor. Această împărțire în straturi și zone este logică. Implementarea fizică a acestor componente poate fi diferită - puteți chiar să folosiți diferite platforme pentru a stoca sau transforma date pe diferite straturi, dacă acest lucru este mai eficient.
Zonele de stocare conțin elemente tehnice (tabele tampon) care sunt utilizate în procesul de transformare a datelor și tabele țintă, accesat de componenta consumatoare. Este o practică bună să „acoperiți” tabelele țintă cu vizualizări. Acest lucru facilitează întreținerea și dezvoltarea ulterioară a sistemului. Datele din tabelele țintă ale tuturor celor trei straturi sunt marcate cu câmpuri tehnice speciale (meta atribute), care servesc pentru a sprijini procesele de încărcare a datelor, precum și pentru a permite audit informativ datele circulă în stocare.

De asemenea, este identificată o componentă specială (sau un set de componente) care oferă funcții de serviciu pentru toate straturile. Una dintre sarcinile sale cheie este funcția de control - pentru a asigura „ reguli uniforme jocuri" pentru întregul sistem în ansamblu, rezervându-și dreptul de a utiliza diferite opțiuni de implementare pentru fiecare dintre straturile descrise mai sus - incl. utilizare tehnologii diferiteîncărcarea și prelucrarea datelor, diferite platforme de stocare etc. Să-l sunăm stratul de serviciu . Nu conține date de afaceri, dar are propriile structuri de stocare - conține o zonă de metadate, precum și o zonă de lucru cu calitatea datelor (și eventual alte structuri, în funcție de funcțiile care îi sunt atribuite).

O astfel de împărțire clară a sistemului în componente individuale crește semnificativ controlabilitatea dezvoltării sistemului:

complexitatea sarcinii care este atribuită dezvoltatorului funcționalității unei anumite componente este redusă (el nu trebuie să rezolve simultan problemele de integrare cu sisteme externe și să se gândească la procedurile de curățare a datelor și să se gândească la prezentarea optimă a datelor pentru consumatori) - sarcina este mai ușor de descompus, evaluat și efectuat o livrare mică;
poţi implica în muncă diverşi interpreţi (şi chiar echipe sau antreprenori) – pentru că Această abordare vă permite să paralelizați eficient sarcinile, reducând influența lor reciprocă unul asupra celuilalt;
prezența stagării persistente vă permite să conectați rapid sursele de date fără a proiecta întregul nucleu sau vitrine pentru întregul domeniu, apoi construiți treptat straturile rămase în funcție de priorități (și datele vor fi deja în stocare - accesibile sistemului analiști, ceea ce va facilita în mod semnificativ sarcinile dezvoltării ulterioare a stocării);
prezența nucleului permite ca toate lucrările cu calitatea datelor (precum și posibilele greșeli și erori) să fie ascunse de vitrine și de utilizatorul final și, cel mai important, prin utilizarea acestei componente ca o singură sursă de date pentru vitrine, problemele cu convergența datelor pot fi evitate datorită implementării algoritmilor comuni într-un singur loc;
evidențierea vitrinelor vă permite să luați în considerare diferențele și înțelegerea specifică a datelor pe care le pot avea utilizatorii diferitelor departamente, iar proiectarea acestora în conformitate cu cerințele BI vă permite nu numai să produceți cifre agregate, ci și să asigurați fiabilitatea datelor prin furnizarea capacitatea de a detalia indicatorii primari;
prezența unui nivel de serviciu vă permite să efectuați o analiză a datelor de la capăt la capăt (liniea datelor), să utilizați instrumente unificate de audit al datelor, abordări generale pentru identificarea modificărilor delta, lucrul cu calitatea datelor, gestionarea încărcării, instrumente de monitorizare și diagnosticare a erorilor și accelerează rezolvarea problemelor.

Această abordare a descompunerii face, de asemenea, sistemul mai rezistent la schimbare (comparativ cu o „structură monolitică”) și îi asigură antifragilitatea:

modificările de la sistemele sursă sunt procesate în staging - în nucleu sunt modificate doar acele fire care sunt influențate de aceste tabele de staging, impactul asupra vitrinelor este minim sau absent;
modificările în cerințele consumatorilor sunt procesate în cea mai mare parte în vitrine (cu excepția cazului în care sunt necesare informații suplimentare care nu sunt deja în depozit).

În continuare, vom parcurge fiecare dintre componentele prezentate mai sus și le vom privi mai detaliat.

Miezul sistemului

Să începem „de la mijloc” - nucleul sistemului sau stratul de mijloc. Nu este desemnat ca Strat de bază. Nucleul îndeplinește rolul de consolidare a datelor - reducerea la structuri unificate, directoare, chei. Aici se desfășoară activitatea principală cu calitatea datelor - curățare, transformare, unificare.

Prezența acestei componente vă permite să reutilizați fluxurile de date care transformă datele primare primite de la sistemele sursă într-un format unificat, urmând reguli și algoritmi generali, mai degrabă decât să repetați implementarea aceleiași funcționalități separat pentru fiecare vitrină de aplicație, care, pe lângă utilizarea ineficientă a resurselor, poate duce la Există, de asemenea, discrepanțe de date.
Nucleul de stocare este implementat într-un model de date care, în general, diferă atât de modelele sistemelor sursă, cât și de formatele și structurile consumatorilor.

Modelul de bază de stocare și modelul de date pentru întreprinderi

Sarcina principală a stratului mijlociu de stocare este stabilitatea. De aceea, aici se pune accentul principal pe modelul de date. Este denumit în mod obișnuit „modelul de date corporative”. Din păcate, în jurul lui s-a dezvoltat un anumit halo de mituri și absurdități, care uneori duc la abandonarea completă a construcției sale, dar în zadar.

Mitul 1. Modelul de date al întreprinderii este un model uriaș format din mii de entități (tabele).
De fapt. În orice domeniu, în orice domeniu de afaceri, în datele oricărei companii, chiar și cele mai complexe, există puține entități principale - 20-30.

Mitul 2. Nu este nevoie să dezvoltăm niciun „model propriu” - cumpărăm un model de referință în industrie și facem totul în conformitate cu acesta. Cheltuim bani, dar obținem rezultate garantate.
De fapt. Modelele de referință pot fi de fapt foarte utile deoarece... conțin experiență în industrie în modelarea acestui domeniu. Din ele puteți strânge idei, abordări și practici de numire. Verificați „adâncimea de acoperire” a zonei pentru a nu rata ceva important. Dar este puțin probabil să putem folosi un astfel de model „din cutie” - așa cum este. Acesta este același mit ca, de exemplu, achiziționarea unui sistem ERP (sau CRM) și implementarea lui fără nicio „personalizare”. Valoarea unor astfel de modele se naște în adaptarea lor la realitățile acestei afaceri, a acestei companii.

Mitul 3. Dezvoltarea unui model de bază de stocare poate dura multe luni, timp în care proiectul va fi efectiv înghețat. De asemenea, necesită o cantitate nebună de întâlniri și o mulțime de oameni implicați.
De fapt. Modelul de depozit poate fi dezvoltat împreună cu depozitul în mod iterativ, fragmentat. Pentru zonele neacoperite, sunt amplasate „puncte de prelungire” sau „cioturi” - de exemplu. Sunt folosite unele „desene universale”. În același timp, trebuie să știi când să te oprești pentru a nu ajunge la o chestie super-universală constând din 4 tabele, în care este greu atât să „introduci date”, cât și (și mai greu) să ajungi. ea afară. Și care funcționează extrem de suboptim în ceea ce privește performanța.

Va dura într-adevăr timp pentru a dezvolta modelul. Dar acesta nu este timpul petrecut pentru „desenarea entităților” - acesta este timpul necesar pentru a analiza tematica, înțelegerea modului în care sunt structurate datele. De aceea, analiștii sunt foarte strâns implicați în acest proces și sunt implicați și diverși experți în afaceri. Și acest lucru se face punctual, selectiv. Și nu prin organizarea de întâlniri cu participarea unui număr nebun de oameni, trimițând chestionare uriașe etc.
Analiza calitativă a afacerilor și a sistemului sunt esențiale atunci când se construiește un model de bază de stocare. Trebuie să înțelegeți o mulțime de lucruri: unde (în ce sisteme) sunt generate datele, cum sunt organizate, în ce procese de afaceri circulă etc. Analiza calitativă nu a dăunat niciodată unui singur sistem. Mai degrabă, dimpotrivă, problemele apar din „punctele oarbe” ale înțelegerii noastre.

Dezvoltarea unui model de date nu este un proces de a inventa și de a veni cu ceva nou. De fapt, modelul de date al companiei există deja. Iar procesul de proiectare seamănă mai degrabă cu „excavare”. Modelul este scos la lumină cu atenție și cu grijă din „solul” datelor corporative și pus într-o formă structurată.

Mitul 4. În compania noastră, afacerea este atât de dinamică și totul se schimbă atât de repede încât ne este inutil să creăm un model - acesta va deveni depășit înainte de a pune această parte a sistemului în funcțiune.
De fapt. Să ne amintim că factorul cheie al miezului este stabilitatea. Și mai presus de toate, topologia modelului. De ce? Pentru că această componentă este centrală și influențează orice altceva. Stabilitatea este, de asemenea, o cerință pentru modelul nucleului. Dacă un model devine depășit prea repede, înseamnă că a fost proiectat incorect. Pentru dezvoltarea sa au fost alese abordări greșite și „reguli ale jocului”. Și aceasta este și o chestiune de analiză calitativă. Esența de bază a modelului corporativ se schimbă extrem de rar.
Dar dacă ne trece prin minte să facem pentru o companie care vinde, să zicem, produse de cofetărie, în loc de directorul „Produse”, faceți „Boomoane”, „Prăjituri” și „Plăcinte”. Când pizza apare în lista de produse, da, va trebui să introduceți multe tabele noi. Și aceasta este doar o chestiune de abordare.

Mitul 5. Crearea unui model corporativ este o chestiune foarte serioasă, complexă și responsabilă. Și e înfricoșător să faci o greșeală.
De fapt. Deși modelul de bază ar trebui să fie stabil, încă nu este „turnat în metal”. Ca orice altă decizie de proiectare, structura sa poate fi revizuită și modificată. Pur și simplu nu ar trebui să uiți de această calitate a ei. Dar asta nu înseamnă deloc că „nu poți respira” pe el. Și asta nu înseamnă că soluțiile temporare și „stub-urile” care ar trebui planificate pentru procesare sunt inacceptabile.

Mitul 6. Dacă sursa noastră de date este, de exemplu, un sistem de management al datelor de bază (sau un sistem de management al datelor de bază - MDM), atunci ar trebui să corespundă deja bine modelului corporativ (mai ales dacă a fost proiectat recent și nu a avut timp să achiziționeze „ efecte secundare”, „tradiții” „și clădiri temporare). Se pare că pentru acest caz nu avem nevoie de un model de kernel?
De fapt. Da, în acest caz, construirea unui model de nucleu de stocare este foarte simplificată - deoarece urmărim un model conceptual de nivel superior gata făcut. Dar nu este complet exclus. De ce? Pentru că atunci când construiești un model al unui anumit sistem, se aplică anumite reguli - ce tipuri de tabele să folosești (pentru fiecare entitate), cum să versezi datele, cu ce granularitate să păstrezi istoricul, ce meta-atribute (domenii tehnice să folosești), etc. .

În plus, oricât de minunat și de cuprinzător este sistemul de management al datelor de bază și al datelor pe care îl avem, de regulă, vor exista nuanțe asociate cu existența directoarelor locale „aproape același lucru” în alte sisteme de contabilitate. Și această problemă, fie că vrem sau nu, va trebui rezolvată la depozitul - până la urmă, aici se colectează rapoarte și analize.

Stratul de date primar (sau stratul de punere în scenă istoricizat sau operațional)

Este desemnat ca Strat de date primar. Rolul acestei componente: integrarea cu sistemele sursă, încărcarea și stocarea datelor primare, precum și curățarea preliminară a datelor - verificarea respectării regulilor de format și control logic stabilite în „acordul de interfață de interacțiune” cu sursa.
În plus, această componentă rezolvă o sarcină foarte importantă pentru depozit - izolarea „adevărata deltă a modificărilor” - indiferent dacă sursa vă permite să urmăriți sau nu modificările în date și cum (după ce criteriu pot fi „prinse” ). De îndată ce datele au intrat în staging, pentru toate celelalte straturi problema alocării deltei este deja clară - datorită marcajului cu atribute meta.

Datele din acest strat sunt stocate în structuri cât mai apropiate de sistemul sursă - pentru a păstra datele primare cât mai aproape de forma inițială. Un alt nume pentru această componentă este „stratul operațional”.
De ce să nu folosiți pur și simplu termenul consacrat „înscenare”? Faptul este că mai devreme, înainte de „era datelor mari și a VLDB”, spațiul pe disc era foarte scump - și adesea datele primare, dacă erau salvate, erau stocate pentru o perioadă limitată de timp. Și adesea se numește „înscenare”. curatabil tampon.
Acum tehnologia a făcut un pas înainte - și ne putem permite nu numai să stocăm toate datele primare, ci și să le istoricizăm cu gradul de granularitate posibil. Acest lucru nu înseamnă că nu ar trebui să controlăm creșterea datelor și nu elimină nevoia de a gestiona ciclul de viață al informațiilor, optimizând costul stocării datelor, în funcție de „temperatura” de utilizare - i.e. mutarea „datelor reci”, care sunt mai puțin solicitate, către platforme media și de stocare mai ieftine.

Ce ne oferă prezența „montării istoricizate”:

posibilitatea de a greși (în structuri, în algoritmi de transformare, în granularitatea istoriei) - având date primare complet istoricizate în zona de stocare, putem oricând să ne reîncărcăm tabelele;
o oportunitate de a gândi - ne putem lua timpul dezvoltării unui fragment mare al nucleului în această iterație specială a dezvoltării depozitului, deoarece în montarea noastră, în orice caz, vor fi, și cu un orizont de timp uniform („punctul de referință al istoriei” va fi unul);
posibilitate de analiză - vom salva chiar și acele date care nu se mai află în sursă - s-ar fi putut pierde acolo, s-ar fi putut intra în arhivă etc. – la noi rămân disponibile pentru analiză;
posibilitatea unui audit al informațiilor - datorită celor mai detaliate informații primare, putem apoi să ne dăm seama cum a funcționat descărcarea pentru noi, că în cele din urmă am obținut astfel de numere (pentru aceasta trebuie să avem, de asemenea, marcaje meta-atribute și metadatele corespunzătoare pe care funcționează descărcarea - aceasta se decide pe nivelul de serviciu).

Ce dificultăți pot apărea la construirea unei „montări istoricizate”:

Ar fi convenabil să se stabilească cerințe pentru integritatea tranzacțională a acestui strat, dar practica arată că acest lucru este dificil de realizat (aceasta înseamnă că în acest domeniu nu garantăm integritate referenţială tabele părinte și copil) – alinierea integrității are loc pe straturile ulterioare;
acest strat conține volume foarte mari (cel mai voluminos de pe stocare - în ciuda întregii redundanțe a structurilor analitice) - și trebuie să poți gestiona astfel de volume - atât din punct de vedere al încărcării, cât și din punct de vedere al interogărilor (altfel puteți degrada grav performanța întregii stocări).

Ce mai interesant se poate spune despre acest strat.
În primul rând, dacă ne îndepărtăm de paradigma „proceselor de încărcare end-to-end”, atunci regula „caravana se mișcă cu viteza ultimei cămile” nu mai funcționează pentru noi; mai exact, abandonăm „caravana” principiu și treceți la principiul „conveior”: am preluat datele de la sursă - puneți-le în stratul dvs. - gata să luăm următoarea porțiune. Înseamnă că
1) nu așteptăm ca procesarea să aibă loc pe alte straturi;
2) nu suntem dependenți de programul de furnizare a datelor din alte sisteme.
Mai simplu spus, programăm un proces de încărcare care preia datele dintr-o sursă printr-un anumit mod de conectare la ea, le verifică, alocă o deltă - și plasează datele în tabelele de staging țintă. Asta e tot.

În al doilea rând, aceste procese, după cum puteți vedea, sunt structurate foarte simplu - s-ar putea spune trivial, din punct de vedere logic. Aceasta înseamnă că acestea pot fi foarte bine optimizate și parametrizate, reducând sarcina sistemului nostru și grăbind procesul de conectare a surselor (timp de dezvoltare).
Pentru ca acest lucru să se întâmple, trebuie să cunoașteți foarte bine caracteristicile tehnologice ale platformei pe care rulează această componentă - și apoi puteți face un instrument foarte eficient.

Strat de vitrină analitică

Layer Showcases (Data Mart Layer) este responsabil pentru pregătirea și furnizarea de date utilizatorilor finali - oameni sau sisteme. La acest nivel, cerințele consumatorului sunt luate în considerare cât mai mult posibil - atât logice (conceptuale), cât și fizice. Serviciul ar trebui să ofere exact ceea ce este necesar – nici mai mult, nici mai puțin.

Dacă consumatorul este un sistem extern, atunci, de regulă, acesta dictează structurile de date de care are nevoie și reglementările pentru colectarea informațiilor. O abordare bună este aceea în care consumatorul însuși este responsabil pentru colectarea corectă a datelor. Depozitul de date a pregătit datele, a creat vitrina, a oferit posibilitatea de colectare incrementală a datelor (marcarea cu meta-atribute pentru identificarea ulterioară a deltei modificărilor), iar apoi sistemul de consum gestionează și este responsabil de modul în care utilizează această vitrină. Dar există unele particularități: atunci când sistemul nu are o componentă activă pentru colectarea datelor, fie este nevoie de o componentă externă care va îndeplini funcția de integrare, fie stocarea va acționa ca o „platformă de integrare” - și va asigura o încărcare incrementală corectă. de date mai departe de stocare. Există multe nuanțe care apar aici, iar regulile de interacțiune a interfeței trebuie gândite și de înțeles de ambele părți (totuși, ca întotdeauna, când vine vorba de integrare). De regulă, astfel de vitrine sunt supuse curățării/arhivării de rutină a datelor (rar este necesar ca aceste „date de tranzit” să fie stocate pentru o perioadă lungă de timp).

Cea mai mare valoare din punct de vedere al sarcinilor analitice sunt vitrinele „pentru oameni” - mai precis pentru instrumentele BI cu care lucrează.
Cu toate acestea, există o categorie de „utilizatori deosebit de avansați” - analiști, oameni de știință a datelor - care nu au nevoie nici de instrumente BI, nici de procese de reglementare pentru completarea sistemelor externe specializate. Au nevoie de un fel de „vitrină comună” și „proprie cutie de nisip” unde pot crea tabele și transformări la discreția lor. În acest caz, responsabilitatea depozitului este să se asigure că aceste vitrine comune sunt umplute cu date în conformitate cu reglementările.
Separat, putem evidenția astfel de consumatori precum instrumentele Data Mining - analiză profundă a datelor. Astfel de instrumente au propriile cerințe pentru pregătirea anterioară a datelor, iar experții în data mining lucrează și cu ele. Pentru depozit, sarcina se reduce, din nou, la sprijinirea unui serviciu de încărcare a anumitor vitrine cu un format agreat.

Să revenim însă la vitrinele analitice. Sunt de interes din punctul de vedere al dezvoltatorilor de stocare în acest strat de date.
După părerea mea, cea mai bună abordare testată în timp pentru proiectarea martelor de date, pentru care aproape toate platformele BI sunt acum „adaptate”, este abordarea lui Ralph Kimball. Este cunoscut ca modelare dimensională – modelare multidimensională. Există o mulțime de publicații pe această temă. De exemplu, regulile de bază pot fi găsite în publicația lui Marga Ross. Și, desigur, îl puteți recomanda de la un guru al modelării multidimensionale. O altă resursă utilă este Kimball's Tips
Abordarea multidimensională a creării vitrinelor este descrisă și elaborată atât de bine - atât de către „evangheliștii metodei”, cât și de către principalii furnizori de software, încât nu are rost să ne oprim aici în detaliu - sursa originală este întotdeauna de preferat.

Aș dori să subliniez doar un singur accent. „Raportare și analiză” pot fi diferite. Există „raportare grea” - rapoarte precomandate care sunt generate sub formă de fișiere și livrate utilizatorilor prin canalele de livrare furnizate. Și există panouri de informații - tablouri de bord BI. În esență, acestea sunt aplicații web. Iar timpul de răspuns al acestor aplicații este supus acelorași cerințe ca și pentru orice altă aplicație web. Aceasta înseamnă că timpul normal de reîmprospătare a tabloului de bord BI este de secunde, nu de minute. Este important să rețineți acest lucru atunci când dezvoltați o soluție. Cum să realizezi acest lucru? Metoda standard de optimizare: uitați-vă la ce formează timpul de răspuns și ce putem influența. Ce vă pierde timpul cel mai mult? Pentru citirile de baze de date fizice (disc), pentru transferul de date prin rețea. Cum se reduce cantitatea de date citite și transmise pe cerere? Răspunsul este evident și simplu: trebuie fie să agregați datele, fie să aplicați un filtru pe tabelele mari la tabelele de fapte care participă la interogare și să excludeți conectarea tabelelor mari (referințele la tabelele de fapte ar trebui să treacă doar prin dimensiuni).

De ce ai nevoie de BI? Cum este convenabil? De ce este eficient un model multidimensional?
BI permite utilizatorului să efectueze așa-numitele „interogări ad-hoc”. Ce înseamnă? Aceasta înseamnă că nu știm în prealabil solicitarea exactă, dar știm ce indicatori în ce secțiuni poate solicita utilizatorul. Utilizatorul generează o astfel de interogare selectând filtrele BI adecvate. Iar sarcina dezvoltatorului BI și a designerului de vitrine este să asigure o astfel de logică a aplicației, astfel încât datele să fie fie filtrate, fie agregate, evitând situația în care sunt solicitate prea multe date și aplicația se blochează. De obicei, încep cu numere agregate, apoi merg mai adânc în date mai detaliate, dar pe parcurs, instalează filtrele necesare.

Nu este întotdeauna suficient să construiești „steaua potrivită” și să obții o structură convenabilă pentru BI. Uneori va trebui să aplicați denormalizarea undeva (în timp ce vă uitați la modul în care aceasta va afecta sarcina), iar undeva va trebui să creați vitrine și agregate secundare. Adăugați indecși sau proiecții undeva (în funcție de SGBD).

Astfel, prin „încercare și eroare” se poate obține o structură optimă pentru BI - care va ține cont atât de caracteristicile DBMS, cât și ale platformei BI, precum și de cerințele utilizatorului pentru prezentarea datelor.
Dacă luăm date din „nucleu”, atunci o astfel de prelucrare a vitrinelor va fi de natură locală, fără a afecta în niciun fel procesarea complexă a datelor primare obținute direct din sistemele sursă - doar „transferăm” datele într-un format convenabil pentru BI. Și ne putem permite să facem acest lucru de multe ori, în moduri diferite, în conformitate cu cerințe diferite. Folosind datele kernelului, este mult mai ușor și mai rapid decât colectarea de la „primar” (a căror structură și reguli, după cum știm, pot, de asemenea, „pluti”).

Stratul de serviciu

Stratul de servicii ( - Service Layer) este responsabil pentru implementarea funcțiilor comune (servicii) care pot fi utilizate pentru a procesa date în diferite straturi de stocare - managementul încărcării, managementul calității datelor, instrumente de diagnosticare și monitorizare a problemelor etc.
Disponibilitate acest nivel oferă transparență și fluxuri de date structurate în stocare.

Acest strat include două zone de stocare a datelor:

zona de metadate – folosită pentru mecanismul de control al încărcării datelor;
zona de calitate a datelor - pentru implementarea verificărilor off-line ale calității datelor (adică cele care nu sunt integrate direct în procesele ETL).

Puteți structura procesul de gestionare a descărcărilor în diferite moduri. Una dintre abordările posibile este aceasta: împărțim întregul set de mese de depozitare în module. Un modul poate include numai tabele dintr-un singur strat. Tabelele incluse în fiecare modul sunt încărcate într-un proces separat. Să-l sunăm proces de control . Lansarea procesului de control este programată. Procesul principal orchestrează apeluri către procese atomice, fiecare dintre ele încarcă un tabel țintă și conține, de asemenea, câțiva pași comuni.
Evident, este suficient să împărțim pur și simplu tabelele de staging în module - în funcție de sistemele sursă, sau mai exact, de punctele lor de conectare. Dar pentru nucleu este deja mai dificil să faci asta, pentru că acolo trebuie să asigurăm integritatea datelor, ceea ce înseamnă că trebuie să ținem cont de dependențe. Acestea. vor apărea conflicte care trebuie rezolvate. Și există diferite metode pentru a le rezolva.

Un punct important în gestionarea sarcinii este dezvoltarea unei abordări unificate a gestionării erorilor. Erorile sunt clasificate după nivelul de gravitate. Dacă apare o eroare critică, procesul trebuie să se oprească, și cât mai repede posibil, pentru că apariția acesteia indică o problemă semnificativă care poate duce la coruperea datelor în stocare. Astfel, managementul încărcării nu se referă doar la pornirea proceselor, ci și la oprirea acestora, precum și la prevenirea pornirii premature (din greșeală).

Pentru a opera nivelul de serviciu, este creată o structură specială de metadate. Această zonă va stoca informații despre procesele de încărcare, seturile de date încărcate, punctele de control care sunt utilizate pentru incrementare (care proces a citit până la ce punct) și alte informații de serviciu necesare funcționării sistemului.
Este important de reținut că toate tabelele țintă din toate straturile sunt marcate cu un set special de meta câmpuri, dintre care unul este identificatorul procesului care a actualizat acest rând. Pentru tabelele din depozit, această etichetare a procesului permite o modalitate unificată de a evidenția ulterior delta modificării. La încărcarea datelor în stratul de date primar, situația este mai complicată - algoritmul de alocare delta pentru diferite obiecte încărcate poate fi diferit. Dar logica procesării modificărilor acceptate și a plasării lor pe tabelele țintă pentru nucleu și vitrine este mult mai complicată decât pentru punere în scenă, unde totul este destul de banal - este ușor să parametrizi și să te gândești la pași standard reutilizabili (proceduri).

Nu îmi propun aici să acopăr pe deplin acest subiect - organizarea de încărcare - evidențiez doar puncte cărora merită să le acordăm atenție.
Abordarea de mai sus este doar o opțiune. Este destul de adaptativ. Și „prototipul său conceptual” a fost transportorul Toyota și sistemul just-in-time. Acestea. Aici ne îndepărtăm de paradigma larg răspândită a exclusiv „încărcării de date nocturne” și a descărcării în porțiuni mici în timpul zilei - deoarece datele sunt gata în diverse surse: ceea ce a venit a fost descărcat. În același timp, avem multe procese paralele care rulează. Și „coada fierbinte” a datelor proaspete va „clipi” în mod constant - și după ceva timp se va echilibra. Trebuie să luăm în considerare această caracteristică. Și, dacă este necesar, creați vitrine personalizate în „slice”, unde totul este deja complet. Acestea. Este imposibil să se obțină atât eficiența, cât și consistența (integritatea) în același timp. Avem nevoie de echilibru - în unele locuri un lucru este important, în altele altul.

Este esențial să oferiți capabilități de înregistrare și monitorizare. O bună practică este să folosiți evenimente tipizate, unde puteți seta parametri diferițiși configurați un sistem de notificare - abonament la anumite evenimente. Deoarece Este foarte important ca atunci când este necesară intervenția administratorului de sistem, acesta să afle despre asta cât mai curând posibil și să primească toate informațiile de diagnosticare necesare. Jurnalele pot fi, de asemenea, folosite pentru a analiza problemele ulterioare, precum și pentru a investiga incidente de defecțiuni ale sistemului, inclusiv. calitatea datelor.

Proiectarea si intretinerea modelelor de date de depozit

De ce este important să acordați atenție proiectării modelelor de date atunci când dezvoltați orice sistem care implică o bază de date (și mai ales un depozit)? De ce nu aruncați un set de tabele oriunde - chiar și într-un editor de text? De ce avem nevoie de „aceste imagini”?
În mod ciudat, chiar și dezvoltatorii experimentați pun întrebări similare.
De fapt, da, nimic nu te împiedică să schițezi mesele și să începi să le folosești. Dacă... dacă în același timp în cap (!) dezvoltatorul are o imagine de ansamblu coerentă a structurii pe care o sculptează. Ce se întâmplă dacă există mai mulți dezvoltatori? Ce se întâmplă dacă altcineva folosește aceste tabele? Ce se întâmplă dacă timpul trece - o persoană părăsește această zonă și apoi se întoarce din nou la ea?

Este posibil să-ți dai seama fără model? În principiu, este posibil. Și dă-ți seama și „găsește imagini pe o bucată de hârtie” și „scură și selectează” datele. Dar este mult mai ușor, mai clar și mai rapid să folosești un artefact gata făcut - un model de date. Și înțelegeți, de asemenea, „logica structurii sale” - adică. Ar fi bine să existe reguli generale ale jocului.

Și cel mai important lucru nu este nici măcar acesta. Cel mai important lucru este că atunci când proiectăm un model, suntem forțați (pur și simplu fără opțiuni!) să studiem mai îndeaproape și mai profund tematica, caracteristicile structurii de date și utilizarea acesteia în diverse cazuri de afaceri. Și acele întrebări pe care le-am putea „împinge deoparte” cu ușurință ca fiind dificile, le-am „încețoșat” aruncând semnele noastre, fără să încercăm efectiv proiecta model - vom fi forțați să instalăm și să decidem acum, în timpul analizei și proiectării, și nu mai târziu - când construim rapoarte și ne gândim la „cum să aducem împreună incompatibilul” și să „reinventăm roata” de fiecare dată.

Această abordare este una dintre acele practici de inginerie care ne permite să creăm sisteme antifragile. Deoarece sunt proiectate în mod clar, transparente, ușor de dezvoltat, iar „limitele fragilității” lor sunt imediat vizibile, puteți evalua mai precis „amploarea dezastrului” atunci când apar noi cerințe și timpul necesar pentru o reproiectare (dacă este necesar) .
Astfel, modelul de date este unul dintre principalele artefacte care trebuie menținute în timpul dezvoltării sistemului. Într-un sens bun, ar trebui să fie „pe masa” fiecărui analist, dezvoltator etc. – toți cei care participă la proiecte de dezvoltare a sistemului.

Proiectarea modelelor de date este un subiect separat, foarte larg. La proiectarea spațiilor de depozitare, sunt utilizate două abordări principale.
Abordarea funcționează bine pentru nucleu „relație-entitate” - atunci când se construiește un model normalizat (3NF) bazat în mod specific pe studiul domeniului subiectului, sau mai precis pe zona sa selectată. Același „model corporativ” discutat mai sus este în joc aici.

Potrivit pentru proiectarea vitrinelor analitice model multidimensional . Această abordare se potrivește bine cu înțelegerea utilizatorilor de afaceri - deoarece... Acesta este un model simplu și convenabil pentru percepția umană - oamenii operează cu concepte înțelese și familiare de metrici (indicatori) și secțiunile prin care sunt analizate. Și acest lucru ne permite să structurem simplu și clar procesul de colectare a cerințelor - desenăm un set de „matrici de secțiuni și indicatori”, comunicând cu reprezentanții diferitelor departamente. Și apoi le combinăm într-o singură structură - un „model de analiză”: formăm un „autobuz de măsurare” și determinăm faptele care sunt definite pe ele. Pe parcurs, lucrăm la ierarhii și reguli de agregare.

Apoi este foarte ușor să treceți la modelul fizic, adăugând elemente de optimizare ținând cont de caracteristicile SGBD. De exemplu, pentru Oracle, aceasta va fi partiționarea, un set de indecși etc. Pentru Vertica se vor folosi și alte tehnici - sortare, segmentare, partiționare.
Poate fi necesară și o denormalizare specială - atunci când introducem în mod deliberat redundanță în date, datorită căreia îmbunătățim performanța interogărilor, dar în același timp complicăm actualizarea datelor (deoarece redundanța va trebui să fie luată în considerare și menținută în timpul procesul de încărcare a datelor). Poate că, pentru a îmbunătăți performanța, va trebui să creăm și tabele agregate suplimentare sau să folosim astfel de tabele caracteristici suplimentare DBMS ca proiecții în Vertica.

Deci, atunci când modelăm datele din depozit, rezolvăm de fapt mai multe probleme:

sarcina de a construi un model conceptual (logic) al nucleului - analiza sistemului și a afacerii - cercetarea domeniului subiectului, aprofundarea în detalii și luând în considerare nuanțele „datelor în direct” și utilizarea lor în afaceri;
sarcina de a construi un model de analiză - și apoi un model conceptual (logic) al vitrinelor;
Sarcina construirii modelelor fizice este de a gestiona redundanța datelor, optimizarea ținând cont de caracteristicile SGBD pentru interogări și încărcare a datelor.

Atunci când dezvoltăm modele conceptuale, este posibil să nu luăm în considerare caracteristicile SGBD-ului specific pentru care proiectăm structura bazei de date. Mai mult, putem folosi un model conceptual pentru a crea mai multe modele fizice - pentru diferite SGBD.

Să rezumam.

Un model de date nu este un set de " imagini frumoase”, iar procesul de proiectare nu este procesul de desenare a acestora. Modelul reflectă înțelegerea noastră asupra domeniului subiectului. Iar procesul de compilare este un proces de studiu și cercetare. Aici se pierde timpul. Și deloc să „desenez și pictezi”.
Un model de date este un artefact de proiect, o modalitate de a face schimb de informații într-o formă structurată între membrii echipei. Pentru a face acest lucru, trebuie să fie înțeles de toată lumea (acest lucru este furnizat prin notație și explicație) și accesibil (publicat).
Modelul de date nu este creat o singură dată și înghețat, ci este creat și dezvoltat în timpul dezvoltării sistemului. Noi înșine am stabilit regulile dezvoltării sale. Și le putem schimba dacă vedem cum să le facem mai bune, mai simple, mai eficiente.
Modelul de date (fizic) vă permite să consolidați și să utilizați un set de bune practici care vizează optimizare - i.e. utilizați tehnicile care au funcționat deja pentru acest SGBD.

Caracteristicile proiectelor de depozit de date

Să ne oprim asupra caracteristicilor proiectelor în cadrul cărora compania construiește și dezvoltă depozite de date. Și să le privim din punctul de vedere al influenței aspectului arhitectural. De ce este important să construim arhitectură pentru astfel de proiecte, și de la bun început. Și prezența unei arhitecturi bine gândite este cea care oferă flexibilitate unui proiect de depozit de date, vă permite să distribuiți eficient munca între interpreți și, de asemenea, facilitează prezicerea rezultatului și face procesul mai previzibil.

Depozitul de date este un software personalizat

Un depozit de date este întotdeauna o „dezvoltare personalizată” și nu o soluție ambalată. Da, există aplicații BI specifice industriei care includ un model de date de referință, procese ETL preconfigurate din surse comune (de exemplu, sisteme ERP) și un set de tablouri de bord și rapoarte BI standard. Dar, în practică, stocarea este extrem de rar implementată - ca o „cutie”. Lucrez cu spații de depozitare de aproximativ 10 ani și nu am văzut niciodată o astfel de poveste. Există întotdeauna nuanțe asociate cu caracteristicile unice ale companiei - atât peisajul de afaceri, cât și pe cel IT. Prin urmare, speranța că arhitectura va fi furnizată de un „vânzător” care furnizează soluția este oarecum nesăbuită. Arhitectura unor astfel de sisteme se „maturează” adesea în cadrul organizației în sine. Sau este format din specialiști de la firma contractantă, care este antreprenorul principal al proiectului.

Depozitul de date este un proiect de integrare

Depozitul de date încarcă și procesează informații din multe sisteme sursă. Și pentru a menține „relații de prietenie” cu ei, trebuie să fii extrem de atent cu ei. Printre altele, este necesar să se minimizeze încărcarea sistemelor sursă, să se țină cont de ferestrele „disponibilitate și indisponibilitate”, să selecteze interfețele de interacțiune ținând cont de arhitectura acestora etc. Apoi stocarea va avea posibilitatea de a prelua datele cât mai curând posibil și cu frecvența necesară. În caz contrar, veți fi „transferat” la un circuit de rezervă, care nu este actualizat cu cea mai eficientă frecvență.
În plus, trebuie luat în considerare „factorul uman”. Integrarea nu se referă doar la interacțiunea mașinilor. Este, de asemenea, comunicare între oameni.

Depozitul de date este un proiect de echipă

Într-o companie mare, un astfel de sistem rareori poate fi implementat doar de o singură echipă. De regulă, aici lucrează mai multe echipe, fiecare dintre ele rezolvă o problemă specifică.

Arhitectura trebuie să ofere capacitatea de a-și organiza munca paralelă și, în același timp, să-și mențină integritatea și să evite duplicarea aceleiași funcționalități în locuri diferite, de către oameni diferiți. În plus față de costurile inutile cu forța de muncă, o astfel de duplicare poate duce ulterior la discrepanțe de date.

În plus, atunci când atât de mulți oameni și echipe, adesea disparate, sunt implicați în procesul de dezvoltare a sistemului, inevitabil se pune întrebarea: cum să construim comunicații și interacțiunea informațională între ei. Cu cât sunt utilizate abordări și practici mai standard și mai ușor de înțeles, cu atât o astfel de activitate poate fi mai simplă, mai convenabilă și mai eficientă. Și merită să ne gândim și la compoziția „artefactelor de lucru”, printre care numărul 1 pentru depozitele de date este modelele de date (a se vedea secțiunea anterioară).

Depozitul de date are o durată de viață mai lungă în comparație cu alte sisteme

Permiteți-mi să clarific - afirmația este adevărată pentru un depozit „în direct”, funcțional, integrat cu surse cheie, care deține date istorice și oferă informații și servicii analitice multor divizii ale companiei.

Ce motiv am să cred asta?
În primul rând, construirea unei facilități de depozitare este un proces care consumă foarte mult resurse: pe lângă costurile reale ale echipamentelor, licențe pentru software-ul tehnologic necesar și dezvoltarea, aproape toate sistemele și diviziile companiei sunt implicate în acest lucru. Repetarea întregului proces de la zero este o întreprindere foarte îndrăzneață.

În al doilea rând, dacă stocarea are arhitectura potrivită, atunci poate supraviețui cu ușurință schimbărilor în sistemele sursă, apariției de noi cerințe de la utilizatorii finali și creșterii volumelor de date.
Dacă arhitectura este corectă și fluxurile de informații sunt transparente, atunci un astfel de sistem poate fi dezvoltat pentru o perioadă destul de lungă de timp, fără riscul de a ajunge într-o situație de stupoare la efectuarea modificărilor din cauza dificultăților de evaluare a impactului.

Dezvoltare iterativă graduală

Ultimul lucru pe care l-ar dori Clientul atunci când se implică într-o situație de stocare este să-și înghețe cerințele timp de un an sau doi în timp ce este proiectat un model de date corporative complet, toate sursele sunt complet conectate etc.

În ochii Clienților, depozitul de date arată adesea ca un monstru absolut - sarcinile, obiectivele și orizontul de dezvoltare ale sistemului sunt atât de voluminoase. Și de multe ori Clientul se teme că „în detrimentul bugetului său” departamentul IT va rezolva unele „probleme proprii”. Și din nou ne confruntăm cu problema interacțiunii dintre oameni și a capacității de a-și exprima cu calm poziția și de a negocia.

Abordările arhitecturale competente vă permit să dezvoltați sistemul în mod iterativ, crescând funcționalitatea treptat, fără a intra în „dezvoltare” timp de câțiva ani înainte de a începe să producă rezultate.

Deși trebuie menționat că „miracolele nu se întâmplă” - iar „începutul” necesită și timp. Pentru stocări, poate fi destul de mare - deoarece acestea sunt volume mari de date, acestea sunt date istorice - pentru perioade vechi, când regulile de prelucrare a informațiilor ar putea diferi de cele actuale. Prin urmare, este nevoie de suficient timp pentru munca analitică, interacțiunea cu sistemele sursă și o serie de „încercări și erori”, inclusiv teste de încărcare pe date reale.

Depozite de date - „istoric multi-proiect”

Este dificil să identifici un singur client de afaceri pentru un depozit de date. Și se crede (nu fără motiv) că factorul cheie în succesul unui proiect de clădire de depozitare este sprijinul conducerii companiei - prima persoană în mod direct.
Stocarea este rareori construită și dezvoltată în cadrul aceluiași proiect. De regulă, există nevoi diferite pentru consolidarea și analiza datelor, în spatele cărora se află diferiți Clienți și grupuri de utilizatori. Prin urmare, depozitul este adesea dezvoltat în cadrul mai multor proiecte paralele.

Echilibrul de inovație și soluții dovedite

În ciuda faptului că subiectul stocării este foarte „vechi” (dacă un astfel de cuvânt este aplicabil pentru o industrie atât de tânără precum IT) și destul de conservator. Cu toate acestea, progresul nu stă pe loc - și limitările care existau anterior din cauza discurilor scumpe și lente, a memoriei scumpe etc. – au fost acum eliminate. Totodată, a sosit momentul reconsiderării unor abordări arhitecturale. Mai mult, acest lucru se aplică atât platformelor tehnologice, cât și arhitecturii sistemelor de aplicații care se bazează pe acestea.

Este important să mențineți un echilibru aici – și să mențineți o abordare destul de „ecologică” atât a resurselor, cât și a informațiilor stocate. În caz contrar, puteți transforma foarte rapid depozitul într-o „haldă de gunoi” slab structurată, care, dacă poate fi rezolvată, se va face printr-un efort destul de mare.
Da, avem mai multe oportunități, dar asta nu înseamnă că trebuie să negăm toate practicile consacrate și testate în timp, care sunt clare cum și de ce să le folosim, și să „mergem până la greu” doar ghidați de spectrul cețos al „inovației. ”
Menținerea echilibrului înseamnă folosirea de noi metode și abordări în care acestea deschid noi oportunități, dar în același timp folosirea celor vechi dovedite pentru a rezolva probleme stringente care nu au fost anulate.
Ce putem face noi ca dezvoltatori și designeri? solutii aplicative? În primul rând, cunoașteți și înțelegeți schimbările tehnologice din platformele pe care lucrăm, capacitățile, caracteristicile și limitele aplicațiilor acestora.

Să ne uităm la DBMS - ca cea mai critică și importantă platformă tehnologică pentru stocare.
Recent, a existat o deriva clară a bazelor de date relaționale, create inițial ca „universale”, către specializare. De mult timp, furnizorii de top au lansat diverse opțiuni pentru aplicații de diferite clase (OLTP, DSS și DWH). În plus, apar oportunități suplimentare de lucru cu text, date geografice etc.

Dar problema nu s-a limitat la asta - au început să apară produse care au fost concentrate inițial pe o anumită clasă de sarcini - de exemplu. SGBD specializat. Ei pot folosi sau nu modelul relațional. Important este că acestea sunt inițial „create” nu doar pentru stocarea și procesarea „informațiilor de afaceri” în general, ci și pentru sarcini specifice.

Aparent, centralizarea și specializarea sunt două tendințe complementare care se înlocuiesc periodic, asigurând dezvoltarea și echilibrul. Precum și dezvoltarea treptată evolutivă (gradată) și schimbări dramatice. Așadar, în anii 90, Michael Stonebraker a fost unul dintre autorii Manifestului generației a III-a a bazelor de date, care exprima clar ideea că lumea nu are nevoie de o altă revoluție în lumea bazelor de date. Cu toate acestea, 10 ani mai târziu, publică lucrări în care anunță premisele pentru începutul unei noi ere în lumea DBMS - tocmai pe baza specializării acestora.
El se concentrează asupra faptului că SGBD-urile universale comune sunt construite pe o arhitectură „fără dimensiuni” (one-size-fits-all), care nu ține cont nici de schimbările în platformele hardware, nici de împărțirea aplicațiilor în clase pentru care este posibil. pentru a veni cu o soluție mai optimă decât prin implementarea cerințelor universale.
Și începe să dezvolte o serie de proiecte în conformitate cu această idee. Unul dintre acestea este C-Store - un DBMS în coloană proiectat în arhitectura shared nothing (SN), creat inițial special pentru sistemele de clasă de depozit de date. Acest produs a fost dezvoltat ulterior comercial ca HP Vertica.

Se pare că acum subiectul dezvoltării depozitului de date a alunecat într-o nouă etapă de dezvoltare. Apar noi tehnologii, abordări și instrumente. Studiul, testarea și aplicarea lor rezonabilă ne permit să creăm soluții cu adevărat interesante și utile. Și aduceți-le la implementare, bucurându-vă de faptul că dezvoltările dvs. sunt folosite în munca reală și aduc beneficii.

Epilog

În pregătirea acestui articol, am încercat să mă concentrez în primul rând pe arhitecții, analiștii și dezvoltatorii care lucrează direct cu depozitele de date. Dar s-a dovedit că inevitabil „a luat subiectul puțin mai larg” - și au apărut alte categorii de cititori. Unele puncte vor părea controversate, altele nu sunt clare, altele sunt evidente. Oamenii sunt diferiți - cu experiențe, medii și poziții diferite.
De exemplu, întrebările tipice ale managerilor sunt „când să implici arhitecții?”, „când ar trebui să faci arhitectură?”, „arhitectură – nu va fi prea scump?” Ele sună destul de ciudat pentru noi (dezvoltatori, designeri), pentru că pentru noi arhitectura unui sistem apare odată cu nașterea sa - nu contează dacă ne dăm seama sau nu. Și chiar dacă nu există un rol formal al arhitectului în proiect, un dezvoltator normal „se întoarce întotdeauna pe arhitectul său interior”.

În general, nu contează cine îndeplinește exact rolul unui arhitect - ceea ce este important este ca cineva să pună astfel de întrebări și să exploreze răspunsurile la acestea. Dacă arhitectul este identificat în mod clar, aceasta înseamnă doar că el este în primul rând responsabil pentru sistem și dezvoltarea acestuia.
De ce am găsit subiectul „antifragilității” relevant pentru acest subiect?

„Lucrul unic despre antifragilitate este că ne permite să lucrăm cu necunoscutul, să facem ceva în condiții în care nu înțelegem ce facem și să obținem succes.”/Nassim N. Taleb/

Prin urmare, criza și un grad ridicat de incertitudine nu sunt o scuză pentru lipsa arhitecturii, ci factori care întăresc nevoia acesteia.

Modele de date industriale

Scopul principal al modelelor este de a facilita orientarea în spațiul de date și de a ajuta la identificarea detaliilor care sunt importante pentru dezvoltarea afacerii. În mediul actual, pentru a conduce o afacere de succes, este absolut necesar să avem o înțelegere clară a conexiunilor dintre diversele componente și o bună înțelegere a imaginii de ansamblu a organizației. Identificarea tuturor detaliilor și conexiunilor folosind modele permite utilizarea cât mai eficientă a timpului și a instrumentelor de organizare a muncii companiei.

Modelele de date sunt modele abstracte care descriu modul în care datele sunt reprezentate și accesate. Modelele de date definesc elementele de date și relațiile dintre ele într-o anumită zonă. Un model de date este un instrument de navigare atât pentru profesioniști în afaceri, cât și pentru IT, care utilizează un set specific de simboluri și cuvinte pentru a explica cu acuratețe o anumită clasă de informații din lumea reală. Acest lucru permite o mai bună înțelegere în cadrul organizației și, astfel, creează un mediu de aplicație mai flexibil și mai stabil.

Modelul de date definește în mod unic sensul datelor, care în acest caz sunt date structurate (spre deosebire de datele nestructurate, cum ar fi o imagine, un fișier binar sau un text, unde semnificația poate fi ambiguă).

De regulă, există modele de nivel superior (și mai general ca conținut) și mai jos (respectiv, mai detaliate). Nivelul superior al modelării este așa-numitul modele conceptuale de date(modele de date conceptuale), care oferă imaginea cea mai generală a funcționării unei întreprinderi sau organizații. Modelul conceptual include conceptele de bază sau domeniile critice pentru funcționarea organizației; de obicei numărul lor nu depășește 12-15. Un astfel de model descrie clase de entități importante pentru o organizație (obiecte de afaceri), caracteristicile lor (atribute) și asocierile dintre perechile acestor clase (adică, relații). Întrucât terminologia în modelarea afacerilor nu a fost încă pe deplin stabilită, în diverse surse în limba engleză, modelele de date conceptuale pot fi numite și modele de subiecte (care pot fi traduse ca modele de domenii) sau modele de date ale întreprinderii (modele de date corporative). .

Următorul nivel ierarhic este modele de date logice(modele de date logice). Ele pot fi, de asemenea, numite modele de date de întreprindere sau modele de afaceri. Aceste modele conțin structuri de date, atributele și regulile lor de afaceri și reprezintă informațiile utilizate de întreprindere din perspectiva afacerii. Într-un astfel de model, datele sunt organizate sub formă de entități și relații dintre acestea. Modelul logic reprezintă datele într-un mod ușor de înțeles de către utilizatorii de afaceri. Un model logic poate conține un dicționar de date - o listă a tuturor entităților cu definițiile lor precise, care permite diferitelor categorii de utilizatori să aibă o înțelegere comună a tuturor fluxurilor de intrare și de ieșire de informații ale modelului. În continuare, mai multe nivel scăzut modelarea este deja o implementare fizică a unui model logic folosind software și platforme tehnice specifice.

Un model logic conține o soluție de afaceri detaliată, care ia de obicei forma unui model normalizat. Normalizarea este un proces care asigură că fiecare element de date dintr-un model are o singură valoare și este complet și unic dependent de cheia primară. Elementele de date sunt organizate în grupuri în funcție de identificarea lor unică. Regulile de afaceri care guvernează elementele de date trebuie incluse pe deplin în modelul normalizat, validitatea și corectitudinea acestora fiind verificate mai întâi. De exemplu, un element de date, cum ar fi Numele Clientului, ar fi probabil împărțit în Prenume și Nume și grupat cu alte elemente de date corespunzătoare într-o entitate Client cu o cheie primară a ID-ului Clientului.

Modelul de date logic este independent de tehnologiile aplicației, cum ar fi bazele de date, tehnologiile de rețea sau instrumentele de raportare, și de mijloacele de implementare fizică a acestora. O organizație poate avea un singur model de date de întreprindere. Modelele logice includ de obicei mii de entități, relații și atribute. De exemplu, un model de date pentru o organizație financiară sau o companie de telecomunicații poate conține aproximativ 3.000 de concepte industriale.

Este important să se facă distincția între un model de date logic și unul semantic. Modelul de date logic reprezintă soluția de afaceri de întreprindere, iar modelul de date semantice reprezintă soluția de afaceri a aplicației. Același model de date logice de întreprindere poate fi implementat folosind modele semantice diferite, de ex. Modelele semantice pot fi considerate drept următorul nivel de modelare, abordând modelele fizice. Mai mult, fiecare dintre aceste modele va reprezenta o „slice” separată a modelului de date corporative în conformitate cu cerințele diferitelor aplicații. De exemplu, într-un model de date logic corporativ, entitatea Client va fi complet normalizată, iar într-un model semantic pentru un data mart poate fi reprezentată ca o structură multidimensională.

O companie poate avea două moduri de a crea un model de date logic corporativ: să-l construiască independent sau să folosească unul gata făcut model de industrie(model de date logice pentru industrie). În acest caz, diferențele în termeni reflectă doar abordări diferite pentru construirea aceluiași model logic. Dacă o companie își dezvoltă și implementează în mod independent propriul model de date logice, atunci un astfel de model, de regulă, se numește pur și simplu model logic corporativ. Dacă o organizație decide să folosească un produs gata făcut de la un furnizor profesionist, atunci putem vorbi despre un model de date logic specific industriei. Acesta din urmă este un model de date logice gata făcute, care reflectă cu exactitate funcționarea unei anumite industrii. Un model logic al industriei este o vedere integrată și specifică domeniului a tuturor informațiilor care trebuie să se afle într-un depozit de date al întreprinderii pentru a răspunde atât la întrebările strategice, cât și la cele tactice de afaceri. Ca orice alt model de date logice, modelul industrial este independent de soluțiile aplicației. De asemenea, nu include derivate sau alte calcule pentru a face recuperarea datelor mai rapidă. De regulă, majoritatea structurilor logice ale unui astfel de model sunt bine traduse în implementarea sa fizică eficientă. Astfel de modele sunt dezvoltate de mulți furnizori pentru o mare varietate de domenii: servicii financiare, producție, turism, sănătate, asigurări etc.

Modelul de date logic al industriei conține informații care sunt comune unei industrie și, prin urmare, nu poate fi o soluție completă pentru o companie. Majoritatea companiilor trebuie să-și crească modelul cu o medie de 25% prin adăugarea de elemente de date și extinderea definițiilor. Modelele prefabricate conțin doar elementele de date cheie, iar elementele rămase trebuie adăugate la obiectele de business corespunzătoare în timpul procesului de instalare a modelului în companie.

Modelele de date logice ale industriei conțin un număr semnificativ de abstracții. Abstracțiile se referă la gruparea de concepte similare sub denumiri comune, cum ar fi Eveniment sau Participant. Acest lucru adaugă flexibilitate modelelor industriale și le face mai uniforme. Astfel, conceptul de Evenimente este aplicabil tuturor industriilor.

Expertul în Business Intelligence Steve Hoberman identifică cinci factori de luat în considerare atunci când decideți dacă să achiziționați un model de date din industrie. Primul este timpul și banii necesari pentru a construi modelul. Dacă o organizație trebuie să obțină rapid rezultate, atunci un model industrial va oferi un avantaj. Utilizarea unui model industrial poate să nu ofere imediat o imagine de ansamblu asupra întregii organizații, dar poate economisi o cantitate semnificativă de timp. În loc de modelare efectivă, se va petrece timp legând structurile existente la modelul industriei și discutând cum să-l personalizeze cel mai bine la nevoile organizației (de exemplu, ce definiții ar trebui modificate și ce elemente de date ar trebui adăugate).

Al doilea factor este timpul și banii necesari pentru a menține modelul în stare de funcționare. Dacă modelul de date al întreprinderii nu face parte dintr-o metodologie care să îi asigure acuratețea și conformitatea standarde moderne, atunci un astfel de model devine foarte repede depășit. Modelul de date din industrie poate preveni riscul ca acest lucru să se întâmple, deoarece este ținut la zi de resurse externe. Desigur, schimbările care apar în cadrul organizației trebuie să fie reflectate în model de către compania însăși, dar schimbările din industrie vor fi reproduse în model de către furnizorul său.

Al treilea factor este experiența în evaluarea și modelarea riscurilor. Crearea unui model de date de întreprindere necesită resurse calificate atât din partea personalului de afaceri, cât și din partea IT. De regulă, managerii au o bună cunoaștere fie a activității organizației în ansamblu, fie a activităților unui anumit departament. Doar câțiva dintre ei au cunoștințe ample (la nivelul întregii companii) și profunde (în cadrul departamentelor) despre afacerea lor. Majoritatea managerilor tind să cunoască bine un singur domeniu. Prin urmare, obținerea unei perspective la nivelul întregii întreprinderi necesită resurse semnificative de afaceri. Acest lucru crește, de asemenea, cerințele pentru personalul IT. Cu cât sunt necesare mai multe resurse de afaceri pentru a crea și testa un model, cu atât analiștii trebuie să fie mai experimentați. Ei trebuie să știe nu numai să obțină informații de la personalul de afaceri, ci și să poată găsi un teren comun în zone controversate și să poată prezenta toate aceste informații într-o manieră integrată. Persoana care creează modelul (în multe cazuri același analist) trebuie să aibă bune abilități de modelare. Crearea modelelor logice de întreprindere necesită modelare „pentru viitor” și capacitatea de a traduce afaceri complexe în literal „pătrate și linii”.

Pe de altă parte, modelul industriei vă permite să folosiți experiența specialiștilor terți. Modelele logice specifice industriei folosesc metodologii de modelare dovedite și echipe de profesioniști cu experiență pentru a evita problemele comune și costisitoare care pot apărea la dezvoltarea modelelor de date ale întreprinderii în cadrul unei organizații.

Al patrulea factor este infrastructura de aplicații existentă și relațiile cu furnizorii. Dacă o organizație folosește deja multe instrumente de la același furnizor și a stabilit relații cu acesta, atunci are sens să comanzi un model de industrie de la același furnizor. Un astfel de model va putea lucra liber cu alte produse de la același furnizor.

Al cincilea factor este schimbul de informații intra-industrie. Dacă o companie trebuie să facă schimb de date cu alte organizații care lucrează în același domeniu, atunci un model de industrie poate fi foarte util în această situație. Organizațiile din aceeași industrie folosesc componente structurale și terminologie similare. În zilele noastre, în majoritatea industriilor, companiile sunt forțate să partajeze date pentru a conduce o afacere de succes.

Cele mai eficiente modele din industrie sunt cele oferite de furnizorii profesionisti. Eficiența ridicată a utilizării lor este atinsă datorită nivelului semnificativ de detaliu și acuratețe al acestor modele. Acestea conțin de obicei multe atribute de date. În plus, creatorii acestor modele nu numai că au o experiență vastă de modelare, dar sunt și bine versați în construirea de modele specifice industriei.

Modelele de date din industrie oferă companiilor o vizualizare unică și integrată a informațiilor lor de afaceri. Multe companii consideră că este dificil să-și integreze datele, deși aceasta este o condiție prealabilă pentru majoritatea proiectelor la nivel de întreprindere. Potrivit unui studiu realizat de The Data Warehousing Institute (TDWI), peste 69% dintre organizațiile chestionate au descoperit că integrarea a fost o barieră semnificativă în adoptarea de noi aplicații. Dimpotrivă, integrarea datelor aduce venituri semnificative companiei.

Modelul de date din industrie, pe lângă conexiunile sale la sistemele existente, oferă avantaje mari pentru proiecte la nivel de întreprindere, cum ar fi Enterprise Resource Planning (ERP), managementul datelor de bază, business intelligence, îmbunătățirea calității datelor și dezvoltarea angajaților.

Astfel, modelele de date logice ale industriei sunt un instrument eficient pentru integrarea datelor și obținerea unei imagini holistice a afacerii. Utilizarea modelelor logice pare a fi un pas necesar către crearea depozitelor de date ale întreprinderii.

Publicaţii

Steve Hoberman. Utilizarea modelului de date logice ale industriei ca model de date de întreprindere.
Claudia Imhoff. Crearea rapidă de depozite de date și execuția proiectelor de Business Intelligence folosind modelarea datelor (Fast-Tracking Data Warehousing & Business Intelligence Projects via Intelligent Data Modeling)

Epilog

„Lucrul unic despre antifragilitate este că ne permite să lucrăm cu necunoscutul, să facem ceva în condiții în care nu înțelegem ce facem și să obținem succes.”/Nassim N. Taleb/

Prin urmare, criza și un grad ridicat de incertitudine nu sunt o scuză pentru lipsa arhitecturii, ci factori care întăresc nevoia acesteia.

Etichete: Adăugați etichete

5.1. Organizarea datelor în sistemele informaționale corporative.

Avand in vedere CIS-ul la cel mai simplificat nivel, putem spune ca acesta contine o retea de calculatoare corporative (de calcul) si un pachet software de aplicatii specializate (APP) pentru rezolvarea problemelor din domeniu. La rândul lor, atât PPP, cât și o rețea de calculatoare implică în mod fundamental utilizarea datelor informaționale despre starea și dezvoltarea sistemelor controlate și gestionate de acestea. Din punct de vedere istoric, SIC constă din subsisteme ramificate separate ale întreprinderilor individuale, interconectate și adesea reprezentative sistem ierarhic. Este firesc să presupunem că astfel de subsisteme au atât propriile surse, cât și propriile lor locații de stocare pentru datele aferente. Prin combinarea într-un singur sistem, apar întrebări cu privire la utilizarea corectă în comun a datelor situate geografic în diferite locații de stocare. Prin urmare, pentru a gestiona cu succes o asociație de producție dotată cu un CIS, este nevoie de un sistem fiabil de colectare, stocare și procesare a datelor. Cu alte cuvinte, este nevoie de o infrastructură informațională unificată care să satisfacă proiecte strategice de BI (Business Intelligence) sau o bază integrată pentru stocarea și utilizarea datelor. Scopul principal al integrării datelor este de a obține o imagine unificată și completă a stării datelor de afaceri corporative. Integrarea în sine este un proces complex, pe baza căruia este indicat să evidențiem:

tehnologii,

Produse,

Aplicații.

Metode sunt abordări ale integrării datelor.

Tehnologii– acestea sunt procese care implementează anumite metode de integrare a datelor.

Produse– acestea sunt soluții comerciale care acceptă una sau alta tehnologie de integrare a datelor.

Aplicații– sunt soluții tehnice gata făcute furnizate de dezvoltatori în conformitate cu dorințele clienților - clienți.

În funcție de complexitatea sistemelor informaționale corporative și de sarcinile pe care acestea sunt proiectate să le rezolve, organizarea datelor din acestea variază oarecum. În special, în CSI, conceput pentru a asigura gestionarea eficientă a proceselor de afaceri atât a sucursalelor individuale, cât și a corporației în ansamblu, se obișnuiește să se vorbească despre prezența bazelor de date corporative. În sistemele informaționale corporative utilizate la cele mai înalte niveluri de management și asociate mai ales cu procesele de analiză operațională și de luare a deciziilor, depozitul de date terminologice este utilizat în procesul de planificare, proiectare și prognozare a diferitelor tipuri de activități de management. Este oportun să rețineți că sintagma stocare integrată a datelor inerente ambelor.

5.2. Baze de date corporative și cerințe pentru acestea

Fiind o stocare de date integrată la nivelul întregului sistem, baza de date corporativă este concepută pentru a oferi informații pentru gestionarea eficientă a tuturor proceselor și diviziilor de afaceri ale corporației. Integrarea datelor implică crearea unei noi structuri care include organic date din bazele de date ale departamentelor separate individuale, prin urmare o astfel de structură trebuie să îndeplinească anumite cerințe:

· Introducerea de date simplă și ușor de utilizat în baza de date,

· Stocarea datelor într-o formă care nu va duce la creșterea excesivă a datelor,

· Disponibilitate pentru Informații generale angajații tuturor diviziilor corporației, sub rezerva condiției obligatorii de diferențiere drepturi de acces,

· Găsiți și preluați rapid informațiile necesare,

· Sortarea și filtrarea datelor necesare,

· Gruparea datelor cu același nume,

· Calcule intermediare și finale pe câmpuri,

· Transformarea și claritatea datelor de ieșire,

· Scalabilitate,

· Protecție împotriva defecțiunilor accidentale, pierderea irecuperabilă a datelor și accesul neautorizat.

În plus, atunci când se integrează baze de date separate (distribuite) într-o singură bază de date corporativă, este important să se asigure capacitatea de a lucra cu baza de date în așa fel încât utilizatorul să lucreze cu ea ca și cu una nedistribuită.

Crearea unei baze de date corporative integrate este posibilă folosind diverse metode, principalele fiind:

· Consolidare,

· Federalizare,

· Răspândire.

5.3. Caracteristicile soluțiilor de integrare pentru baze de date corporative

Consolidare. Sub consolidare de obicei se referă la adăugarea de date cu același nume. Un termen similar este utilizat pe scară largă în industria bancară, unde se formează un bilanț anual consolidat, care face posibilă prezentarea tuturor activelor și pasivelor băncii-mamă împreună cu sucursalele acesteia.

În raport cu o corporație, atunci când se utilizează această metodă, datele sunt copiate și colectate din bazele de date primare (DB - Slave) prin integrarea într-o singură locație de stocare (DB - Master). De regulă, serverul sediului central (central) este ales ca atare locație de stocare (Fig. 5.1).

Fig.5.1. Metoda de consolidare a datelor

Datele din baza de date Master sunt folosite pentru raportare, analiză, dezvoltare și luare a deciziilor, precum și ca sursă de date pentru alte ramuri ale corporației.

Cele mai comune tehnologii pentru a susține astfel de soluții în timpul consolidării sunt următoarele tehnologii:

· Extragere, transformare și încărcare - ETL (Extract Transform Load);

· Managementul conținutului corporației - ECM (Enterprise Content Management).

Avantajele metodei de consolidare sunt:

1. Abilitatea de a se transforma(restructurare, reconciliere, curățare și/sau agregare) a unor volume semnificative de date în procesul de transfer al acestora de la sistemele primare la locațiile finale de stocare prin tehnologia ETL;

2. Abilitatea de a gestiona date nestructurate, cum ar fi documente, rapoarte și pagini datorită soluțiilor tehnologice ECM.

Pentru a lucra cu baza de date consolidată CIS, special aplicații de afaceri, care vă permit să creați interogări la datele bazei de date, rapoarte și, pe baza acestora, să efectuați analiza datelor.

Dezavantajul integrării prin consolidare este că datele consolidate din locația de stocare integrată nu pot fi actualizate sincron cu actualizările datelor din sistemele primare din cauza conflictelor de sincronizare.

Există o întârziere între momentele actualizării datelor în sistemele primare și în locația finală de stocare.

Acest întârziere poate varia de la câteva secunde la câteva ore sau chiar zile.

Federalizare. Sub federalizare de obicei se referă la un sindicat. Un termen similar este adesea folosit în politică atunci când se aranjează granițele unui stat (de exemplu, Germania, Federația Rusă, SUA).

Procesul de federalizare a datelor într-o bază de date corporativă este crearea unei imagini virtuale (aparente) care combină mai multe fișiere de date primare într-un singur întreg virtual (vezi Fig. 5.2). De fapt, federalizarea datelor constă în extragerea datelor din sistemele primare pe baza cerințelor externe. Gestionarea bazei de date corporative integrată conform metodei federale este realizată de procesor de federalizare.

Fig.2. Metoda federalizării datelor

La accesarea datelor dintr-o bază de date virtuală, orice aplicație de afaceri generează o solicitare către imaginea virtuală. Pe baza acestei solicitări, procesorul de federație preia datele din sistemele primare corespunzătoare, le integrează în conformitate cu imaginea virtuală și furnizează rezultatul aplicației de afaceri care a generat cererea. În acest caz, toate transformările necesare ale datelor sunt efectuate atunci când sunt extrase din sistemele primare.

Suportul pentru abordarea federalizată a integrării datelor este oferit de tehnologia de integrare a informațiilor întreprinderii (E I I), care înseamnă Integrarea informațiilor corporative.

O caracteristică specială a soluției de federație este că procesorul de federalizare folosește metadate(cunoștințe), care conține date despre compoziția și caracteristicile imaginii virtuale, cantitatea de date, conexiunile semantice dintre acestea și modalitățile de accesare a acestora, ajutând să ajute soluția federativă să optimizeze accesul la sistemele primare.

Principalele avantaje ale abordării federale sunt:

· capacitatea de a accesa datele curente fără a crea o nouă bază de date suplimentară,

fezabilitatea aplicării după achiziționarea sau fuziunea de companii,

· indispensabilitate în cazurile în care, din motive de securitate, există restricții de licențiere privind copierea datelor din sistemele primare,

· utilizarea, dacă este necesar, a autonomiei ridicate a diviziilor locale ale corporației și a flexibilității controlului centralizat al activităților acestora;

· grad ridicat de utilitate pentru marile corporații transnaționale.

Dezavantajele abordării includ:

· Productivitate redusă datorită costurilor suplimentare de accesare a mai multor surse de date,

federalizarea este cea mai potrivită pentru extragerea micilor seturi de date,

· cerințe ridicate pentru calitatea datelor primare.

Răspândirea. Sub diseminare de obicei se referă la transferul teritorial al obiectelor multiplicate. Distribuția datelor se referă la înmulțirea bazelor de date primare și la mutarea acestora dintr-un loc în altul. La implementare aceasta metoda aplicatii de afaceri operați online și mutați datele către destinații în funcție de anumite evenimente care au loc. Pentru această soluție tehnică devine importantă problema actualizării datelor care este posibilă în modurile sincrone sau asincrone.Modul sincron presupune că actualizările atât în sistemul primar, cât și în sistemul țintă au loc în timpul aceleiași tranzacții fizice.

Exemple de tehnologii care sprijină implementarea metodei de diseminare a datelor sunt:

· Integrarea aplicațiilor enterprise EAI - Enterprise Application Integration,

· Replicarea datelor corporative EDR – Enterprise Data Replication.

Structura generalizată a implementării metodei de diseminare a datelor arată ca în Fig. 5.3.

Fig.5.3. Metoda de difuzare a datelor

O caracteristică distinctivă a metodei de distribuție a datelor este livrarea garantată a datelor către sistemul de destinație cu o latență minimă, aproape de timp real.

Combinația de tehnologii de integrare (EAI) și replicare (EDR) în metodă oferă multiple avantaje, sub forma următoarelor avantaje:

· Performanta ridicata,

· Posibilitatea de restructurare și curățare a datelor,

· Echilibrarea sarcinii prin crearea de copii de rezervă și restaurarea datelor.

Abordare hibridă. Realitățile activității economice sunt de așa natură încât nu există două întreprinderi identice, cu atât mai puțin două corporații identice. Această împrejurare își lasă amprenta asupra procesului de creare și completare a CSI. Acest lucru se aplică pe deplin metodelor de integrare a datelor în baze de date. Din acest motiv, multe CSI folosesc așa-numita hibrid o abordare care include simultan mai multe metode de integrare. Exemple de această abordare sunt tehnologiile care oferă o imagine consecventă a informațiilor despre clienți:

· Integrarea datelor clienților în sistemele CDI - Customer Data Integration,

· Integrarea datelor clienților în modulele CRM – Customer Relations Management.

În special, implementarea CDI poate fi abordată în diferite moduri.

Cea mai simplă modalitate este de a crea o bază de date consolidată pentru clienți care să conțină date din sistemele primare. În acest caz, decalajul informațional poate fi reglat prin utilizarea diferitelor moduri de consolidare: operațional sau batch, în funcție de frecvența actualizării acestor informații.

A doua metodă este federalizarea datelor, atunci când este virtuală prezentări de afaceri datele clienților conținute în sistemele primare. Și fișierul de metadate poate conține elemente cheie comune care pot fi utilizate pentru a lega informațiile despre clienți.

Astfel, datele generale (de exemplu, detalii) despre clienți pot fi consolidate ca date cele mai statice. Și date mai dinamice (de exemplu, informații despre comenzi) pot fi federalizate.

Mai mult, abordarea hibridă poate fi extinsă prin utilizarea unei metode de diseminare a datelor. De exemplu, un client care folosește serviciile unui magazin online își schimbă detaliile în timpul serviciului. Aceste modificări pot fi trimise în partea consolidată a bazei de date și de acolo distribuite către toate sistemele primare care conțin date despre clienții magazinului.

Ținând cont de avantajele și dezavantajele fiecărei metode, este recomandabil să se adopte o abordare creativă a aplicării și utilizării lor în comun.

De exemplu, este recomandabil să folosiți federalizarea datelor în cazurile în care costurile consolidării datelor depășesc beneficiile de afaceri pe care le oferă consolidarea. În special, procesarea promptă a cererilor și pregătirea rapoartelor este exact o astfel de situație.

Aplicarea practică a metodei de distribuție a datelor este foarte diversă, atât din punct de vedere al performanței, cât și din punct de vedere al posibilităților de restructurare și curățare a datelor.

5.4. Concept și soluții structurale ale depozitelor de date

Magazin de date - este un dispozitiv integrat de stocare a informațiilor, orientat spre subiect, care acumulează date externe și operaționale, precum și date din alte sisteme, pe baza cărora se construiesc procesele decizionale și de analiză a datelor.

Spre deosebire de bazele de date și băncile de date, baza depozitelor de date nu este internă, ci surse de date externe: diverse Sisteme de informare, arhive electronice, cataloage electronice accesibile publicului, cărți de referință și colecții.

Conceptul de depozit de date se bazează pe două idei principale:

1. Integrarea datelor detaliate separate (care descriu fapte specifice, proprietăți, evenimente etc.) într-un singur depozit.

2. Separarea seturilor de date și a aplicațiilor utilizate pentru prelucrare și analiză.

Un depozit de date este organizat în cazurile în care este necesar să se obțină:

· Integrarea actualului și istoricului valorile datelor,

· Combinarea datelor din surse disparate,

· Crearea unei platforme de date fiabile în scopuri analitice,

· Asigurarea omogenității datelor în organizație,

· Facilitează implementarea standardelor de date corporative fără a schimba sistemele de operare existente,

· Oferirea unei perspective istorice ample și oportunități de analiza a tendințelor de dezvoltare.

Din punct de vedere istoric, depozitele de date au fost construite pe unul, două și trei niveluri.

Scheme cu un singur nivel au fost inițial destinate celor mai simple arhitecturi, care includ DSS funcțional, cu o infrastructură informațională insuficient dezvoltată, atunci când analiza se realizează folosind date din sisteme operaționale, după principiul: date - forme de prezentare.

Avantajele unor astfel de scheme sunt:

· Transfer rapid de date de la sisteme operaționale la un sistem specializat fără legături intermediare,

· Costuri minime prin utilizarea unei singure platforme.

Defecte:

· Gamă restrânsă de probleme care trebuie rezolvate datorită unei singure surse de date,

· Calitatea scăzută a datelor din cauza lipsei unui pas de curățare.

Scheme pe două niveluri furnizați un lanț: date – data marts – formulare de prezentare. Ele sunt utilizate în corporații cu un număr mare de divizii independente care folosesc propriile tehnologii informaționale.

Avantaje:

· Vitrinele folosite sunt concepute pentru a răspunde la un anumit număr de întrebări,

· Este posibilă optimizarea datelor în vitrine, ceea ce îmbunătățește productivitatea.

Defecte:

· Dificultate în asigurarea consecvenței datelor din cauza repetării acestora în vitrine,

· Complexitatea potențială a umplerii vitrinelor cu un număr mare de surse de date,

· Din cauza lipsei de consolidare a datelor la nivel corporativ, nu există o imagine unică a afacerii.

Evoluția dezvoltării a dus la faptul că construirea unui depozit de date cu drepturi depline pentru sistemele corporative moderne a început să fie realizată folosind arhitectura pe trei niveluri (vezi Fig. 5.4).

Pe primul nivel există diverse sisteme de înregistrare care sunt surse de date. Astfel de sisteme pot fi sisteme de planificare a resurselor întreprinderii (ERP - Enterprise Resource Planning), sisteme de referință (operaționale), surse externe sau sisteme care furnizează date de la agențiile de informare etc.

Pe al doilea level conține o stocare centrală, care colectează date din toate sursele de la primul nivel, precum și un depozit de date operațional, care este conceput pentru a îndeplini două funcții:

· Depozitul este o sursă de informații analitice utilizată pentru managementul operațional,

· În depozitul operațional, datele sunt pregătite pentru încărcarea ulterioară în depozitul central. Pregătirea datelor înseamnă efectuarea de verificări și transformarea datelor în legătură cu diverse reglementări pentru primirea datelor de la primul nivel.

Al treilea nivelul este o colecție de magazine de date orientate pe subiect.

magazine de date - Acestea sunt unități relativ mici, orientate spre funcție, al căror conținut ajută la rezolvarea problemelor analitice ale diviziilor individuale ale corporației. Data mart-urile sunt în esență subseturi de date dintr-un depozit. În același timp, utilizatorii finali au posibilitatea de a accesa date detaliate din depozit în cazul în care nu există date suficiente în vitrina, precum și de a obține o imagine mai completă a stării afacerii.

Fig.5.4. Arhitectura depozitului de date

Principalele operațiuni tehnologice ale depozitelor de date organizate astfel sunt:

· Extracţie datele reprezintă procesul de transfer de date din surse eterogene către un depozit operațional,

· Conversie datele reprezintă modificarea datelor pe baza unor reguli speciale, cu transferul lor ulterior într-o stocare centrală,

· Curatenie datele reprezintă eliminarea dublării datelor care provin din diferite surse,

· Actualizați data este propagarea actualizărilor de date către datele sursă ale tabelelor de bază și datele derivate aflate în depozit.

Avantaje:

· Umplerea vitrinelor este simplificată datorită utilizării unei singure surse de date șterse,

· Magazinele de date sunt sincronizate cu imaginea afacerii corporative, ceea ce facilitează extinderea stocării centrale și adăugarea de magazine de date,

· Performanță garantată.

Defecte:

· Prezența redundanței datelor, ceea ce duce la cerințe crescute pentru tehnologia de stocare a datelor,

5. 5.Sisteme de management al bazelor de date și tehnologii de acces la date în CSI

Sistemul de gestionare a bazelor de date(DBMS) este un complex de limbaj și software, destinat creării, întreținerii și partajării unei baze de date de către unul sau mai mulți utilizatori.

În prezent, cele mai utilizate SGBD-uri sunt cele construite pe baza unui model de date relaționale, descris de un aparat matematic strict. teorii relaționale.

O caracteristică a SGBD-urilor care lucrează într-un CIS este faptul că trebuie să gestioneze bazele de date situate pe medii distribuite în spațiu.

În interesul eliminării dublării suplimentare sau copierii datelor în CSI, accentul principal este pus pe principiul prelucrării datelor la distanță. Bazele de date din CIS conțin date necesare multor utilizatori. Obținerea accesului simultan al mai multor utilizatori la o bază de date este posibilă la instalarea unui SGBD pe o rețea locală de calculatoare care funcționează cu utilizatori și cu o singură bază de date.

Principalele soluții tehnologice pentru lucrul multi-utilizator cu baze de date sunt tehnologiile fișier/server și client/server. Preluând varianta cea mai potrivită din aceste tehnologii, clientul/serverul din CSI organizează sisteme specializate de procesare a bazelor de date distribuite. În același timp, bazele de date distribuite sunt gestionate în așa fel încât datele să fie distribuite nu la nivel logic, ci la nivel fizic, iar baza de date în sine este considerată o singură „superschemă”. Într-o bază de date distribuită, funcțiile administrative sunt distribuite între administratorul bazei de date integrate și administratorii bazei de date locale. Administratorul bazei de date integrate monitorizează delimitarea accesului diferiților utilizatori la baza de date și asigură integritatea și siguranța datelor, precum și protecția datelor împotriva corectării simultane de către mai mulți utilizatori. Controlul accesului se realizează în conformitate cu drepturile acordate utilizatorilor individuali în sistemul de operare al rețelei.

O caracteristică caracteristică a programelor create folosind un DBMS pentru lucrul cu baze de date corporative la distanță și distribuite este utilizarea unei interfețe deschise de acces la date - ODBC (Open Data Base Connectivity). Toate funcțiile de transfer de date sunt alocate interfeței ODBC, care este o punte de legătură între baza de date integrată DBMS și aplicația client DBMS. În același timp, SGBD-ul clientului poate interacționa nu numai cu bazele de date locale, ci și cu datele aflate în baza de date integrată. Clientul are capacitatea de a trimite interogări către baza de date integrată DBMS, de a primi date de la acestea și de a trimite propriile date actualizate.

Modele de date industriale

Următorul nivel ierarhic este modele de date logice(modele de date logice). Ele pot fi, de asemenea, numite modele de date de întreprindere sau modele de afaceri. Aceste modele conțin structuri de date, atributele și regulile lor de afaceri și reprezintă informațiile utilizate de întreprindere din perspectiva afacerii. Într-un astfel de model, datele sunt organizate sub formă de entități și relații dintre acestea. Modelul logic reprezintă datele într-un mod ușor de înțeles de către utilizatorii de afaceri. Un model logic poate conține un dicționar de date - o listă a tuturor entităților cu definițiile lor precise, care permite diferitelor categorii de utilizatori să aibă o înțelegere comună a tuturor fluxurilor de intrare și de ieșire de informații ale modelului. Următorul nivel inferior de modelare este implementarea fizică a modelului logic folosind software-ul și platformele tehnice specifice.

Al doilea factor este timpul și banii necesari pentru a menține modelul în stare de funcționare. Dacă modelul de date al întreprinderii nu face parte dintr-o metodologie care să asigure că este exact și actualizat, modelul va deveni rapid depășit. Modelul de date din industrie poate preveni riscul ca acest lucru să se întâmple, deoarece este ținut la zi de resurse externe. Desigur, schimbările care apar în cadrul organizației trebuie să fie reflectate în model de către compania însăși, dar schimbările din industrie vor fi reproduse în model de către furnizorul său.

Publicaţii

Steve Hoberman. Utilizarea modelului de date logice ale industriei ca model de date de întreprindere.
Claudia Imhoff. Crearea rapidă de depozite de date și execuția proiectelor de Business Intelligence folosind modelarea datelor (Fast-Tracking Data Warehousing & Business Intelligence Projects via Intelligent Data Modeling)

Baza de date corporativă este legătura centrală a sistemului informațional corporativ și vă permite să creați un singur spațiu informațional corporatii. Baze de date corporative

Distribuiți-vă munca pe rețelele sociale

Dacă această lucrare nu vă convine, în partea de jos a paginii există o listă cu lucrări similare. De asemenea, puteți utiliza butonul de căutare

TEMA V. BAZELE DE DATE CORPORATE

V .1. Organizarea datelor în sistemele corporative. Baze de date corporative.

V .2. SGBD și soluții structurale în sistemele corporative.

V.3. Tehnologii Internet/Intranet și soluții de acces la baze de date pentru întreprinderi.

V .1. ORGANIZAREA DATELOR ÎN SISTEME CORPORATIVE. BAZELE DE DATE CORPORATE

Baza corporativă datele reprezintă legătura centrală a sistemului informațional corporativ și vă permit să creați un spațiu informațional unificat al corporației. Baze de date corporative (Fig. 1.1).

Există diferite definiții ale bazelor de date.

În baza de date (DB) înțelege un set de informații legate logic în așa fel încât să constituie un singur set de date stocate în dispozitivele de stocare ale unui computer. Acest set actioneaza ca date initiale ale problemelor rezolvate in procesul de functionare a sistemelor automate de control, sistemelor de prelucrare a datelor, sistemelor informatice si de calcul.

Termenul bază de date poate fi formulat pe scurt ca o colecție de date legate logic, destinate a fi partajate.

Sub baza de date se referă la o colecție de date stocate împreună cu o astfel de redundanță minimă încât poate fi utilizată în mod optim pentru una sau mai multe aplicații.

Scopul creării bazelor de date ca forme de stocare a datelor construirea unui sistem de date care nu depinde de algoritmii adoptați ( software), mijloacele tehnice utilizate, locația fizică a datelor în computer. Baza de date presupune o utilizare multifuncțională (mai mulți utilizatori, multe forme de documente și interogări ale unui singur utilizator).

Cerințe de bază pentru baze de date:

Completitudinea prezentării datelor. Datele din baza de date trebuie să reprezinte în mod adecvat toate informațiile despre obiect și ar trebui să fie suficiente pentru ODS.
Integritatea bazei de date. Datele trebuie păstrate în timpul procesării SOD-ului lor și în orice situații apărute în timpul procesului de lucru.
Flexibilitatea structurii datelor. Baza de date ar trebui să permită modificarea structurilor de date fără a-i încălca integritatea și integralitatea atunci când condițiile externe se schimbă.
Fezabilitate. Aceasta înseamnă că trebuie să existe o reprezentare obiectivă a diferitelor obiecte, proprietățile și relațiile acestora.
Disponibilitate. Este necesar să se asigure diferențierea accesului la date.
Redundanţă. Baza de date trebuie să aibă redundanță minimă în reprezentarea datelor despre orice obiect.

Cunoașterea este înțeleasă ca un set de fapte, modele și reguli euristice cu ajutorul cărora puteți rezolva o anumită problemă.

Baza de cunoștințe (KB)  un set de baze de date și reguli utilizate, obținute de la factorii de decizie. Baza de cunoștințe este un element al sistemelor expert.

Este necesar să distingem moduri diferite de prezentare a datelor.

Date fizice Acestea sunt date stocate în memoria computerului.

Reprezentarea logică a datelor corespunde reprezentării datelor fizice de către utilizator. Diferența dintre reprezentarea fizică și cea logică corespunzătoare a datelor este că aceasta din urmă reflectă unele relații importante între datele fizice.

Sub baza de date corporativă să înțeleagă o bază de date care combină, într-o formă sau alta, toate datele și cunoștințele necesare despre organizația care este automatizată. În sistemele informaționale corporative, cea mai concentrată expresie a găsit conceptul debaze de date integrate, care implementează principiul introducerii unice și utilizării repetate a informațiilor.

Orez. 1.1. Structura de interacțiune a departamentelor cu resursele informaționale ale corporației.

Există baze de date corporative concentrat (centralizat) și distribuite.

Baza de date focalizată (centralizată). este o bază de date ale cărei date sunt stocate fizic în dispozitivele de stocare ale unui computer. În fig. Figura 1.2 prezintă o diagramă a unei aplicații server pentru accesarea bazelor de date pe diverse platforme.

Fig.1.2. Schemă eterogenă baza de date centralizata

Centralizarea procesării informațiilor a făcut posibilă eliminarea unor astfel de dezavantaje ale tradiționale sisteme de fișiere, cum ar fi incoerența, inconsecvența și redundanța datelor. Cu toate acestea, pe măsură ce bazele de date cresc și, mai ales atunci când sunt utilizate în organizații separate geografic, apar probleme. De exemplu, pentru bazele de date concentrate situate la nodul unei rețele de telecomunicații, prin care diferite departamente ale organizației accesează date, apar următoarele dificultăți pe măsură ce volumul de informații și numărul de tranzacții cresc:

Flux mare de schimb de date;
Trafic ridicat în rețea;
Fiabilitate scăzută;
Performanță generală scăzută.

Deși este mai ușor să se asigure securitatea, integritatea și consistența informațiilor în timpul actualizărilor într-o bază de date concentrată, aceste probleme creează anumite dificultăți. Descentralizarea datelor este propusă ca o posibilă soluție la aceste probleme. Prin descentralizare se realizează următoarele:

Grad mai mare de simultaneitate a procesării datorită distribuției sarcinii;
Îmbunătățirea utilizării datelor la fața locului atunci când se efectuează interogări de la distanță (la distanță);
Costuri mai mici;
Ușurință în gestionarea bazelor de date locale.

Costurile creării unei rețele ale cărei noduri conțin stații de lucru (calculatoare mici) sunt mult mai mici decât costurile creării unui sistem similar folosind un computer mare. Figura 1.3 prezintă diagrama logică a unei baze de date distribuite.

Fig.1.3. Baza de date corporativă distribuită.

Să dăm următoarea definiție a unei baze de date distribuite.

Baza de date distribuita - aceasta este o colecție de informații, fișiere (relații) stocate în diferite noduri reteaua de informatiiși legate logic în așa fel încât să constituie un singur corp de date (linkul poate fi funcțional sau prin copii ale aceluiași fișier). Astfel, acesta este un set de baze de date care sunt interconectate logic, dar situate fizic pe mai multe mașini care fac parte din aceeași rețea de calculatoare.

Cele mai importante cerințe pentru caracteristicile unei baze de date distribuite sunt:

Scalabilitate;
Compatibilitate;
Suport pentru diverse modele de date;
Portabilitate;
Transparența locației;
Autonomia nodurilor bazei de date distribuite (Site Autonomy);
Procesarea cererilor distribuite;
Executarea tranzacțiilor distribuite.
Sprijin pentru un sistem de securitate omogen.

Transparența locației permite utilizatorilor să lucreze cu baze de date fără să știe nimic despre locația lor. Autonomia nodurilor bazei de date distribuite înseamnă că fiecare bază de date poate fi menținută independent de celelalte. O interogare distribuită este o interogare (instrucțiune SQL) în timpul execuției căreia sunt accesate obiecte (tabele sau vederi) din diferite baze de date. La executarea tranzacțiilor distribuite, există un control al concurenței între toate bazele de date implicate. Oracle7 folosește tehnologia de transfer de informații în două faze pentru a efectua tranzacții distribuite.

Bazele de date care alcătuiesc o bază de date distribuită nu trebuie neapărat să fie omogene (adică întreținute de același SGBD) sau procesate în același mediu de sistem de operare și/sau pe același tip de computere. De exemplu, o bază de date poate fi o bază de date Oracle pe un computer SUN cu sistemul de operare SUN OS (UNIX), a doua bază de date poate fi întreținută de un DBMS DB2 pe un mainframe IBM 3090 cu sistemul de operare MVS, iar a treia bază de date poate să fie întreținut de un DBMS SQL/DS tot pe mainframe IBM, dar cu un sistem de operare VM. Este necesară o singură condiție - toate mașinile cu baze de date trebuie să fie accesibile prin rețeaua căreia îi aparțin.

Sarcina principală a unei baze de date distribuite distribuirea datelor prin rețea și asigurarea accesului la aceasta. Există următoarele moduri de a rezolva această problemă:

Fiecare nod stochează și utilizează propriul set de date, care este disponibil pentru interogări de la distanță. Această distribuție este împărțită.
Unele date care sunt utilizate frecvent pe site-uri la distanță pot fi duplicate. Această distribuție se numește parțial duplicat.
Toate datele sunt duplicate în fiecare nod. Această distribuție se numește complet duplicat.
Unele fișiere pot fi împărțite orizontal (se alocă un subset de înregistrări) sau vertical (se alocă un subset de câmpuri de atribute), cu subseturile alocate stocate în diferite noduri împreună cu datele nedivizate. Această distribuție se numește split (fragmentat).

Când creați o bază de date distribuită la nivel conceptual, trebuie să decideți sarcinile următoare:

Este necesar să existe o singură diagramă conceptuală a întregii rețele. Acest lucru va asigura transparența logică a datelor pentru utilizator, în urma căreia acesta va putea să formeze o cerere către întreaga bază de date în timp ce se află la un terminal separat (parcă ar lucra cu o bază de date centralizată).
Este necesară o schemă care să definească locul în care se află datele în rețea. Acest lucru va asigura transparența plasării datelor, astfel încât utilizatorul să nu fie nevoit să specifice unde să trimită cererea pentru a obține datele necesare.
Este necesar să se rezolve problema eterogenității bazelor de date distribuite. Bazele de date distribuite pot fi omogene sau eterogene din punct de vedere hardware și software. Problema eterogenității se rezolvă relativ ușor dacă baza de date distribuită este eterogenă din punct de vedere hardware, dar omogenă din punct de vedere software (DBMS identic în noduri). Dacă sunt utilizate diferite SGBD-uri în nodurile unui sistem distribuit, sunt necesare instrumente pentru conversia structurilor de date și a limbilor. Acest lucru ar trebui să asigure o conversie transparentă între nodurile bazei de date distribuite.
Problema managementului dicționarului trebuie rezolvată. Pentru a oferi toate tipurile de transparență într-o bază de date distribuită, sunt necesare programe care să gestioneze numeroase dicționare și cărți de referință.
Este necesar să se definească metode de executare a interogărilor într-o bază de date distribuită. Metodele de executare a interogărilor într-o bază de date distribuită diferă de metodele similare din bazele de date centralizate, deoarece părțile individuale ale interogărilor trebuie executate la locația datelor relevante și rezultatele parțiale trebuie transmise către alte noduri; În același timp, trebuie asigurată coordonarea tuturor proceselor.
Este necesar să se rezolve problema executării paralele a interogărilor. O bază de date distribuită necesită un mecanism complex de gestionare a prelucrărilor concurente, care, în special, trebuie să asigure sincronizarea la actualizarea informațiilor, ceea ce garantează consistența datelor.
Este necesară o metodologie dezvoltată pentru distribuirea și plasarea datelor, inclusiv împărțirea, care este una dintre cerințele principale pentru o bază de date distribuită.

Una dintre noile domenii în curs de dezvoltare ale arhitecturii sistemelor informatice, care este un mijloc puternic de procesare a informațiilor nenumerice, este mașini de baze de date. Motoarele de baze de date sunt folosite pentru a rezolva probleme nenumerice, cum ar fi stocarea, căutarea și transformarea documentelor și faptelor și lucrul cu obiecte. În urma definirii datelor ca informații digitale și grafice despre obiectele din lumea înconjurătoare, conceptul de date în timpul prelucrării numerice și nenumerice are conținut diferit. Procesarea numerică utilizează obiecte precum variabile, vectori, matrici, tablouri multidimensionale, constante și așa mai departe, în timp ce în procesarea non-numerică, obiectele pot fi fișiere, înregistrări, câmpuri, ierarhii, rețele, relații etc. În procesarea non-numerică, informațiile despre obiecte sunt direct de interes (de exemplu, un anumit angajat sau grup de angajați) , nu dosarul angajatului în sine. Aceasta nu indexează fișierul angajatului pentru a selecta o anumită persoană; aici ești mai interesat de conținutul înregistrării pe care o cauți. Cantități uriașe de informații sunt de obicei supuse unei prelucrări non-numerice. În diverse aplicații, puteți efectua următoarele operații asupra acestor date, de exemplu:

cresterea salariilor pentru toti angajatii companiei;
calculează dobânda bancară pe conturile tuturor clienților;
efectuați modificări în lista tuturor mărfurilor din stoc;
găsiți rezumatul necesar din toate textele stocate în bibliotecă sau în sistemul de regăsire a informațiilor bibliografice;
găsiți o descriere a contractului dorit într-un dosar care conține documente legale;
examinați toate fișierele care conțin descrieri de brevet și găsiți un brevet (dacă există) similar cu cel propus din nou.

Pentru a implementa o mașină de bază de date, paralelă și asociativă arhitectura ca alternativă la un singur procesorvon Neumannstructuri care vă permit să lucrați cu cantități mari de informații în timp real.

Sunt achiziționate mașini cu baze de date importantîn legătură cu studiul și aplicarea conceptelor de inteligență artificială precum reprezentarea cunoștințelor, sistemele expert, inferența, recunoașterea modelelor etc.

Depozitele de informații. Astăzi, mulți admit că majoritatea companiilor operează deja mai multe baze de date și, pentru a lucra cu succes cu informații, au nevoie nu doar de diferite tipuri de baze de date, ci de diferite generații de SGBD. Conform statisticilor, fiecare organizație folosește în medie 2,5 SGBD-uri diferite. A devenit evidentă nevoia de a „izola” afacerile companiilor, sau mai bine zis, a persoanelor implicate în această afacere, de caracteristicile tehnologice ale bazelor de date, de a oferi utilizatorilor o imagine unică a informațiilor corporative, indiferent de locul în care sunt stocate fizic. Acest lucru a stimulat apariția tehnologiei de stocare a informațiilor ( Data Warehousing, DW).

Scopul principal al DW este crearea unei reprezentări logice unificate a datelor conținute în diferite tipuri de baze de date sau, cu alte cuvinte, un model de date corporative unificat.

O nouă rundă de dezvoltare DW a devenit posibilă datorită îmbunătățirii tehnologia Informatieiîn general, în special apariția unor noi tipuri de baze de date bazate pe procesarea interogărilor paralele, care la rândul lor s-au bazat pe progresele din domeniul calculatoarelor paralele. Au fost create constructori de interogăricu o interfață grafică intuitivă care a făcut ușoară construirea de interogări complexe de baze de date. Varietate de softwaremiddlewarefurnizat comunicareîntre diferite tipuri de baze de date, și în cele din urmă a scăzut brusc în prețdispozitive de stocare.

Structura unei corporații poate include o bancă de date.

Bază de date componentă funcțională și organizatorică în sistemele automate de control și sisteme informatice și de calcul, oferind suport informațional centralizat pentru un grup de utilizatori sau un set de sarcini rezolvate în sistem.

Bază de date este considerat un sistem de informare și referință, al cărui scop principal este:

în acumularea şi menţinerea în stare de funcţionare a totalităţii informaţiilor care alcătuiesc baza de informatiiîntregul sistem automatizat sau un anumit set de sarcini rezolvate în acesta;
în emiterea datelor solicitate de sarcină sau utilizator;
în asigurarea accesului colectiv la informațiile stocate;
în asigurarea managementului necesar al utilizării informaţiilor cuprinse în baza de informaţii.

Astfel, o bancă de date modernă este un complex software și hardware complex, care include tehnică, sistem și instrumente de rețea, baze de date și DBMS, sisteme de recuperare a informațiilor pentru diverse scopuri.

V .2. SGBD ȘI SOLUȚII STRUCTURALE ÎN SISTEME CORPORATE

Baze de date și sisteme de management al cunoștințelor

O componentă importantă a sistemelor informatice moderne sunt sistemele de management al bazelor de date (DBMS).

SGBD un set de instrumente software și limbaj concepute pentru crearea, întreținerea și utilizarea bazelor de date.

Un sistem de gestionare a bazelor de date oferă acces la bazele de date pentru sistemele de procesare a datelor. După cum sa menționat deja, SGBD-urile joacă un rol important atunci când creează sisteme informaționale corporative și, mai ales important, atunci când creează sisteme informaționale folosind sisteme distribuite. resurse informaționale, bazat pe tehnologiile moderne de calcul de rețea.

Principala caracteristică a SGBD-urilor moderne este că SGBD-urile moderne suportă tehnologii precum:

Tehnologia client/server.
Suport pentru limbile baze de date. Acestlimbaj de definire a schemei DB (SDL - Schema Definition Language),limbaj de manipulare a datelor (DML - Data Manipulation Language), limbaje integrate SQL (Structured Queue Language), QDB (Query - By - Exemplu) și QMF (Query Management Facility) ) instrument periferic avansat pentru specificarea interogărilor și generarea de rapoarte pentru DB 2 etc.;
Gestionarea directă a datelor în memoria externă.
Gestionarea bufferelor RAM.
Managementul tranzacțiilor. Tehnologia OLTP (Procesarea tranzacțiilor on-line), OLAP tehnologie (Procesare de analiză on-line) pentru DW.
Asigurați protecția și integritatea datelor. Utilizarea sistemului este permisă numai utilizatorilor autorizați să acceseze datele. Atunci când utilizatorii efectuează operațiuni asupra datelor, consecvența datelor stocate (integritatea) este menținută. Acest lucru este important în sistemele de informații corporative cu mai mulți utilizatori.
Jurnalizarea.

SGBD-urile moderne trebuie să se asigure că cerințele bazei de date enumerate mai sus sunt îndeplinite. În plus, acestea trebuie să îndeplinească următoarele principii:

Independența datelor.
Versatilitate. SGBD-ul trebuie să aibă suport puternic pentru modelele de date conceptuale pentru afișarea vederilor logice personalizate.
Compatibilitate. SGBD-ul trebuie să rămână operațional pe măsură ce software-ul și hardware-ul evoluează.
Neredundanța datelor. Spre deosebire de sistemele de fișiere, o bază de date trebuie să fie o singură colecție de date integrate.
Protejarea datelor. SGBD-ul trebuie să ofere protecție împotriva accesului neautorizat.
Integritatea datelor. SGBD-ul trebuie să împiedice utilizatorii să încalce baza de date.
Managementul muncii concomitent. SGBD-ul trebuie să protejeze baza de date de inconsecvențe în modul de acces partajat. Pentru a asigura o stare consecventă a bazei de date, toate cererile utilizatorului (tranzacțiile) trebuie executate într-o anumită ordine.
SGBD-ul trebuie să fie universal. Ea trebuie să sprijine diferite modele date pe o singură bază logică și fizică.
SGBD-ul trebuie să suporte atât baze de date centralizate, cât și distribuite și, astfel, să devină o legătură importantă în rețelele de calculatoare.

Considerând un SGBD ca o clasă de produse software care vizează menținerea bazelor de date în sisteme automate, putem identifica două caracteristici cele mai semnificative care definesc tipurile de SGBD. Potrivit acestora, un SGBD poate fi privit din două puncte de vedere:

capacitățile lor în legătură cu bazele de date distribuite (corporate);
relația lor cu tipul de model de date implementat în SGBD.

În ceea ce privește bazele de date corporative (distribuite), se pot distinge aproximativ următoarele tipuri de SGBD:

SGBD desktop. Aceste produse se concentrează în primul rând pe lucrul cu date personale (date de pe desktop). Au seturi de comenzi pentru partajarea bazelor de date comune, dar de dimensiuni reduse (cum ar fi un birou mic). În primul rând, acestea sunt SGBD-uri precum Access, dBASE, Paradox, EcoxPro. De ce Access, dBASE, Paradox, EcoxPro au acces nesatisfăcător la datele corporative. Faptul este că nu există o modalitate ușoară de a depăși bariera dintre datele personale și cele corporative. Și nici măcar ideea nu este că mecanismul SGBD-ului de date personale (sau biroul mic) este axat pe accesarea datelor prin multe gateway-uri, produse de internetwork etc. Problema este că aceste mecanisme implică în mod obișnuit transferuri complete de fișiere și nici un suport extins pentru indexuri, ceea ce face ca cozile de server să se oprească practic pe sistemele mari.
SGBD specializat de înaltă performanță multi-utilizator. Astfel de SGBD-uri se caracterizează prin prezența unui nucleu de sistem multi-utilizator, a unui limbaj de manipulare a datelor și a următoarelor funcții caracteristice SGBD-urilor multi-utilizator dezvoltate:
organizarea unui pool tampon;
prezența unui sistem de procesare a cozii de tranzacții;
prezența mecanismelor de blocare a datelor multi-utilizator;
menținerea unui jurnal de tranzacții;
prezența mecanismelor de control al accesului.

Aceste SGBD-uri precum Oracle, DB2, SQL/Server, Informix, Sybase, ADABAS, Titanium și altele oferă o gamă largă de servicii pentru procesarea bazelor de date corporative.

Când lucrați cu baze de date, este utilizat un mecanism de tranzacție.

Tranzacţie este o unitate logică de lucru.

Tranzacţie este o secvență de operatori de manipulare a datelor executațica un întreg(totul sau nimic) și baza de date de traducerede la o stare integrală la alta stare integrală.

O tranzacție are patru proprietăți importante, cunoscute sub numele de proprietăți ACID:

(A) Atomicitate . O tranzacție este executată ca o operațiune atomică - fie întreaga tranzacție este executată, fie întreaga tranzacție nu este executată.
(C) Consecvență. O tranzacție mută baza de date dintr-o stare consecventă (integrală) într-o altă stare consecventă (integrală). În cadrul unei tranzacții, consecvența bazei de date se poate deteriora.
(I) Izolație . Tranzacțiile efectuate de diferiți utilizatori nu ar trebui să interfereze între ele (de exemplu, ca și cum ar fi executate în ordine strictă).
(D) Durabilitate. Dacă o tranzacție este finalizată, atunci rezultatele muncii acesteia trebuie salvate în baza de date, chiar dacă sistemul se blochează în momentul următor.

Tranzacția începe de obicei automat când utilizatorul se alătură SGBD și continuă până când apare unul dintre următoarele evenimente:

Comanda COMMIT WORK a fost emisă (comitați tranzacția).
Comanda ROLLBACK WORK a fost emisă.
Utilizatorul a fost deconectat de la SGBD.
A avut loc o defecțiune a sistemului.

Pentru utilizator îl poartă de obicei caracter atomic. De fapt, acesta este un mecanism complex de interacțiune între utilizator (aplicație) și baza de date. Software-ul pentru sistemele de întreprindere utilizează un mecanism de procesare a tranzacțiilor în timp real (Sisteme de procesare a tranzacțiilor on-line, OLTP), în special programele de contabilitate, software-ul pentru primirea și procesarea cererilor clienților, aplicațiile financiare, produc o mulțime de informații. Aceste sisteme sunt proiectate (și optimizate în consecință) pentru a gestiona volume mari de date, tranzacții complexe și operațiuni intensive de citire/scriere.

Din păcate, informațiile plasate în bazele de date ale sistemelor OLTP nu sunt foarte potrivite pentru utilizarea de către utilizatorii obișnuiți (din cauza gradului ridicat de normalizare a tabelelor, a formatelor specifice de prezentare a datelor și a altor factori). Prin urmare, datele de la diferite transportoare de informații sunt trimise (în sensul de copiat) către depozit de depozitare, sortarea și livrarea ulterioară către consumator. În tehnologia informației, rolul depozitelor îl joacădepozite de informații.

Sistemele de procesare a datelor analitice în timp real furnizează informații utilizatorului final (Procesare analitică on-line, OLAP), care oferă acces excepțional de simplu la date prin mijloace convenabile de a genera interogări și de a analiza rezultate. În sistemele OLAP, valoarea unui produs informațional crește prin utilizarea diferitelor metode de analiză și prelucrare statistică. În plus, aceste sisteme sunt optimizate în ceea ce privește viteza de regăsire a datelor, colectarea de informații generalizate și sunt destinate utilizatorilor obișnuiți (au o interfață intuitivă). Dacă sistem OLTP oferă răspunsuri la întrebări simple precum „care a fost nivelul vânzărilor produsului N în regiunea M în ianuarie 199x?”, apoi sisteme OLAP pregătit pentru solicitări mai complexe ale utilizatorilor, de exemplu: „Oferiți o analiză a vânzărilor produsului N în toate regiunile conform planului pentru trimestrul al doilea în comparație cu cei doi ani anteriori.”

Arhitectura client/server

În sistemele moderne procesarea distribuită a informațiilor, tehnologia ocupă centrul atenției client server. În sistem arhitectura client-serverprelucrarea datelor este împărțită între computerul client și computerul server, comunicarea între care are loc prin rețea. Această împărțire a proceselor de prelucrare a datelor se bazează pe gruparea funcțiilor. În mod obișnuit, un computer server de baze de date este dedicat efectuării operațiunilor de bază de date, iar un computer client efectuează programe de aplicație. Figura 2.1 prezintă un sistem simplu de arhitectură client-server care constă dintr-un computer care acționează ca server și un alt computer care acționează ca client. Fiecare mașină îndeplinește funcții diferite și are propriile sale resurse.

		Bază de date
Computer server
Net
PC compatibil IBM	PC compatibil IBM	PC compatibil IBM
		Aplicații

Orez. 2.1. Sistem arhitectural client-server

Funcția principală a unui computer client este de a executa aplicația (interfață cu utilizatorul și logica de prezentare) și de a comunica cu serverul atunci când este solicitat de aplicație.

Server acesta este un obiect (calculator) care oferă servicii altor obiecte la cererea acestora.

După cum sugerează termenul însuși, funcția principală a unui computer server este de a servi nevoile clientului. Termenul „Server” este folosit pentru a face referire la două grupuri diferite de funcții: un server de fișiere și un server de baze de date (în continuare, acești termeni înseamnă, în funcție de context, fie software care implementează aceste grupuri de funcții, fie computere cu acest software). Serverele de fișiere nu sunt proiectate pentru a efectua operațiuni cu baze de date; funcția lor principală este de a partaja fișiere între mai mulți utilizatori, de exemplu. asigurarea accesului simultan al multor utilizatori la fișierele de pe un computer – server de fișiere. Un exemplu de server de fișiere este sistemul de operare NetWare de la Novell. Serverul de baze de date poate fi instalat și activat pe un computer - un server de fișiere. Oracle DBMS sub formă de NLM (Network Loadable Module) rulează în mediul NetWare pe un server de fișiere.

Server retea locala trebuie să aibă resurse corespunzătoare scopului său funcțional și nevoilor rețelei. Rețineți că, datorită concentrării pe abordarea sistemelor deschise, este mai corect să vorbim despre servere logice (adică un set de resurse și software care oferă servicii peste aceste resurse), care nu sunt neapărat amplasate pe computere diferite. O caracteristică a unui server logic într-un sistem deschis este că, dacă, din motive de eficiență, este recomandabil să mutați serverul pe un computer separat, atunci acest lucru se poate face fără a fi nevoie de nicio modificare, fie pentru el însuși, fie pentru aplicație. programele care îl folosesc.

Una dintre cerințele importante pentru server este ca sistemul de operare în care se află serverul de baze de date să fie multitasking (și, de preferință, dar nu neapărat, multi-utilizator). De exemplu, un SGBD Oracle instalat pe un computer personal cu un sistem de operare MS-DOS (sau PC-DOS) care nu îndeplinește cerința de multitasking nu poate fi utilizat ca server de bază de date. Și același DBMS Oracle, instalat pe un computer cu un sistem de operare OS/2 multitasking (deși nu multi-utilizator), poate fi un server de baze de date. Multe varietăți de sisteme UNIX, MVS, VM și alte sisteme de operare sunt atât multitasking, cât și multi-utilizator.

Calcul distribuit

Termenul „calculator distribuit” este adesea folosit pentru a se referi la două concepte diferite, deși complementare:

Baza de date distribuită;
Prelucrare distribuită a datelor.

Aplicarea acestor concepte face posibilă organizarea accesului la informațiile stocate pe mai multe mașini de către utilizatorii finali folosind diferite instrumente.

Există mai multe tipuri de servere:

Server de baze de date;
Server de imprimare;
Server de acces la distanță;
server de fax;
server web, etc.

Bazat pe tehnologia de bază Client/Server Există tehnologii de bază precum:

Tehnologii ale sistemelor de operare, conceptul de interacțiune a sistemelor deschise, crearea de medii orientate pe obiecte pentru funcționarea programelor;
Tehnologii de telecomunicații;
Tehnologii de rețea;
Tehnologii grafice interfața cu utilizatorul ( GUI);
etc.

Avantajele tehnologiei client-server:

Tehnologia client/server permite calcularea în medii de calcul eterogene. Independenta platformei: Accesați medii de rețea eterogene care includ diferite tipuri de computere cu sisteme de operare diferite.
Independența surselor de date: acces la informații din baze de date eterogene. Exemple de astfel de sisteme sunt DB2, SQL/DS, Oracle, Sybase.
Echilibru de încărcare client și server.
Efectuați calcule acolo unde se întâmplă cel mai eficient;
Oferă capacitatea de a scala în mod eficient;
Calcul multiplatform. Calcularea multiplatformă este definită pur și simplu ca implementarea tehnologiilor în medii de calcul eterogene. Următoarele capabilități ar trebui furnizate aici:
Aplicația trebuie să ruleze pe mai multe platforme;
Pe toate platformele trebuie să aibă aceeași interfață și aceeași logică de operare;
Aplicația trebuie să se integreze cu mediul de operare nativ;
Ar trebui să se comporte la fel pe toate platformele;
Ar trebui să aibă un suport simplu și consistent.

 Calcul distribuit. Calculul distribuit implică distribuirea muncii între mai multe computere (deși calculul distribuit este un concept mai larg).

 Dezagregarea. Separarea transferului de aplicații pentru computere mari pe platforme de calculatoare mici.

Costuri reduse de infrastructură și hardware. Eficient din punct de vedere al costurilor: disponibilitatea echipamentelor informatice ieftine și prevalența tot mai mare a rețelelor locale fac ca tehnologia client-server să fie mai rentabilă decât alte tehnologii de procesare a datelor. Echipamentul poate fi modernizat de îndată ce este nevoie.

 Reducerea timpului general de execuție a aplicației;

 Reducerea utilizării memoriei clientului;

 Reducerea traficului de rețea.

Abilitatea de a lucra cu multimedia: până în prezent, multe programe multimedia au fost create pentru computere. Fie nu există programe similare pentru configurarea terminal-gazdă, fie sunt foarte scumpe.
Posibilitatea de a atrage resurse de calcul mari pentru operațiunile bazei de date: deoarece aplicațiile rulează pe computerele client, computerul server eliberează resurse suplimentare (comparativ cu configurația terminal-gazdă) pentru operațiunile bazei de date, cum ar fi CPU și resursele operaționale.
Productivitate crescută a programatorului: productivitatea programatorului crește cu instrumente precum SQL*Forms și CASE, care vă permit să dezvoltați aplicații mai rapid decât limbajele de programare precum C, PL1 sau COBOL.
Productivitate crescută a utilizatorilor finali: în prezent, mulți utilizatori finali au stăpânit sisteme precum Lotus, Paradox, Word Perfect, Harvard Graphics etc.

Interfața de backend este definită și fixată. Prin urmare, este posibil să se creeze noi părți client ale unui sistem existent (un exemplu de interoperabilitate la nivel de sistem).

Orez. 2.2. Ilustrație a accesului clientului la o resursă partajată de server.

Cum se implementează tehnologia client-server

Instalarea unui sistem bazat pe tehnologie client-server și capabil de prelucrare distribuită a datelor este discutată mai jos. Următoarele componente hardware și software sunt necesare:

computer server de baze de date;
calculatoare client;
rețea de comunicații;
software de rețea;
software de aplicație.

Limbajul SQL . Limbajul de interogare la nivel înalt - SQL (Structured Query Language ) este folosit pentru a implementa interogări în baze de date, cum ar fi NMD, DML și PYAD și este acceptat ca standard. Limba SQL a fost adoptat inițial ca limbaj de date al produselor software ale companiei IBM și SGBD relațional YaMD SYSTEM R de la IBM . O caracteristică importantă a limbii SQL este că același limbaj este reprezentat prin două interfețe diferite și anume: printr-o interfață interactivă și printr-o interfață de programare a aplicațiilor (dinamică). SQL). SQL dinamic constă din multe capacități lingvistice încorporate SQL , furnizat special pentru construirea de aplicații interactive, în care o aplicație interactivă este definită ca un program care este scris pentru a sprijini accesul la baza de date de către un utilizator final care rulează pe un terminal interactiv. Limba SQL oferă funcțiile de definire, manipulare și gestionare a datelor bazei de date și este transparent pentru utilizator din punctul de vedere al SGBD implementat.

Orez. 2.3. Schemă pentru executarea interogărilor utilizatorilor către baze de date distribuite.

Structura internă a bazelor de date este determinată de modelele de date utilizate. Modelul conceptual are capacități de abstractizare mai mari și o semantică mai bogată în comparație cu modelele externe. Modele externe adesea numite modele sintactice sau operaționale, referindu-se la natura sintactică a controlului și aplicării ca mijloc de interacțiune a utilizatorului cu baza de date. În modelarea informației, există diferite niveluri de abstractizare, de la nivelul modelului conceptual până la nivelul modelului fizic de date, afectând arhitectura SGBD.

Modelul de date este format din trei componente:

Structura de date pentru a reprezenta baza de date din perspectiva utilizatorului.
Operații valide efectuate asupra structurii de date. Este necesar să se poată lucra cu această structură folosind diverse operațiuni DML și NMD. O structură bogată nu are valoare dacă nu există nicio modalitate de a opera asupra conținutului ei.
Constrângeri pentru controlul integrității. Modelul de date trebuie să fie prevăzut cu mijloace pentru a-și menține integritatea și a-l proteja. Ca exemplu, luați în considerare următoarele două restricții:
Fiecare subarbore trebuie să aibă un nod sursă. Bazele de date ierarhice nu pot stoca noduri copil fără nodul părinte.
În raport cu o bază de date relațională, nu pot exista tupluri identice. Pentru un fișier, această cerință necesită ca toate înregistrările să fie unice.

Unul dintre cele mai importante caracteristici Munca unui SGBD este capacitatea de a lega obiecte.

Există următoarele tipuri de conexiuni între obiecte:

Unu la unu (1:1). Un obiect dintr-un set poate fi asociat cu un obiect al altui set.
Unu-la-Mulți (1:M). Un obiect dintr-un set poate fi asociat cu mai multe obiecte dintr-un alt set.
Multi-la-Multe (M:N). Un obiect dintr-un set poate fi asociat cu multe obiecte dintr-un alt set, dar un obiect dintr-un alt set poate fi asociat cu multe obiecte din primul set.
Ramificată . Un obiect dintr-un set poate fi asociat cu obiecte din mai multe seturi.
Recursiv . Un singur obiect set dat poate fi conectat printr-un obiect din aceeași mulțime.

Există următoarele modele de date de bază:

Model de date relaționale.
Model ierarhic de date.
Model de date de rețea incomplet.
Model de date CODASYL.
Model extins de date de rețea.

V.3. TEHNOLOGII INTERNET / INTRANET ȘI SOLUȚII CORPORATE PENTRU ACCES LA BAZĂ DE DATE

Principala problemă a sistemelor bazate pe o arhitectură client-server este că, în conformitate cu conceptul de sisteme deschise, acestea trebuie să fie mobile în cea mai largă clasă posibilă de soluții hardware și software de sistem deschis. Chiar dacă ne limităm la rețelele locale bazate pe UNIX, diferite rețele folosesc hardware și protocoale de comunicație diferite. Încercările de a crea sisteme care să suporte toate protocoalele posibile duc la supraîncărcarea acestora cu detalii de rețea în detrimentul funcționalității.

Un aspect și mai complex al acestei probleme este asociat cu posibilitatea utilizării diferitelor reprezentări de date în diferite noduri ale unei rețele locale eterogene. Diferite computere pot avea diferite adrese, reprezentare a numerelor, codificare a caracterelor etc. Acest lucru este deosebit de important pentru serverele de nivel înalt: telecomunicații, calcul, baze de date.

Soluție generală Problema mobilității sistemelor bazate pe arhitectura client-server este dependența de pachete software care implementează protocoale de apel de procedură la distanță (RPC - Remote Procedure Call). Când utilizați astfel de instrumente, apelarea unui serviciu pe un nod la distanță arată ca o procedură obișnuită. Instrumentele RPC, care, desigur, conțin toate informațiile despre specificul echipamentului rețelei locale și al protocoalelor de rețea, traduc apelul într-o succesiune de interacțiuni de rețea. Astfel, specificul mediului de rețea și protocoalele sunt ascunse de programatorul aplicației.

Când este apelată o procedură de la distanță, programele RPC convertesc formatele de date client în formate intermediare independente de mașină și apoi convertesc în formate de date de server. La transmiterea parametrilor de răspuns se efectuează transformări similare.

Alte lucrări similare care vă pot interesa.vshm>
6914.		Conceptul bazei de date	11,56 KB
	O bază de date este o colecție de materiale independente prezentate într-o formă obiectivă, articole de calcul ale actelor normative ale hotărârilor judecătorești și alte materiale similare, sistematizate în așa fel încât aceste materiale să poată fi găsite și prelucrate folosind un computer electronic Codul civil al Rusiei Federația Art. O bază de date organizată în conformitate cu anumite reguli și menținută în memoria computerului este un set de date care caracterizează starea actuală a unor...
8064.		Baze de date distribuite	43,66 KB
	Baze de date distribuite Sub bază distribuită Datele RDB sunt înțelese ca un set de date partajate interconectate logic, care sunt distribuite fizic în diferite noduri ale unei rețele de calculatoare. Accesul la date nu ar trebui să depindă de prezența sau absența replicilor de date. Sistemul trebuie să determine automat metode de realizare a conexiunilor de fuziune a datelor: un canal de rețea capabil să facă față volumului de informații transmise și un nod care are suficientă putere de calcul pentru a conecta tabele. RDBMS trebuie să poată...
20319.		BAZELE DE DATE ȘI PROTECȚIA LOR	102,86 KB
	Bazele de date operaționale online au apărut la mijlocul anilor 1960. Operațiunile pe baze de date operaționale au fost procesate interactiv folosind terminale. Organizațiile simple de înregistrări indexate secvențiale au evoluat rapid către un model de înregistrare mai puternic, orientat spre set. Charles Bachman a primit Premiul Turing pentru conducerea grupului de activitate pentru baze de date (DBTG), care a dezvoltat un limbaj standard pentru descrierea și manipularea datelor.
5031.		Biblioteca de dezvoltare a bazelor de date	11,72 MB
	Tehnologia de proiectare a bazelor de date. Definiți relațiile dintre entități și creați un model de date. Principalele idei ale tehnologiei informaționale moderne se bazează pe conceptul că datele ar trebui organizate în baze de date pentru a afișa în mod adecvat lumea reală în schimbare și pentru a satisface nevoile de informații ale utilizatorilor. Aceste baze de date sunt create și funcționează sub controlul special sisteme software numite sisteme de gestionare a bazelor de date DBMS.
13815.		MODEL BAZĂ DE DATE IERARHICĂ	81,62 KB
	Principalele idei ale tehnologiei informaționale moderne se bazează pe conceptul de baze de date, conform căruia baza tehnologiei informației sunt date organizate în baze de date care reflectă în mod adecvat starea unui anumit domeniu și oferă utilizatorului informații actualizate în acest domeniu de subiect. Este necesar să recunoaștem faptul că datele sunt...
14095.		Dezvoltarea bazei de date a bibliotecii	11,72 MB
	Creșterea volumului și complexității structurale a datelor stocate și extinderea cercului de utilizatori ai sistemelor informaționale au condus la utilizarea pe scară largă a celui mai convenabil și relativ ușor de înțeles SGBD relațional (tabelar).
5061.		Crearea unei baze de date clinice	2,4 MB
	Dezvoltarea tehnologiei informatice și a tehnologiei informației a oferit oportunități pentru crearea și utilizarea pe scară largă a sistemelor informatice automatizate (AIS) în diverse scopuri. Sunt în curs de dezvoltare și implementare sisteme informatice pentru gestionarea instalațiilor economice și tehnice
13542.		Baze de date cu informații geologice	20,73 KB
	Recent, implementarea tehnologia calculatoarelorși, în special, baze de date, în domeniul științific. Acest proces nu ocolește geologia, deoarece în științele naturii este nevoie de stocarea și procesarea unor volume mari de informații.
9100.		Bază de date. Noțiuni de bază	26,28 KB
	O bază de date este o colecție de informații despre obiecte specifice ale lumii reale din orice domeniu, economie, management, chimie etc. Scopul unui sistem informațional nu este doar acela de a stoca date despre obiecte, ci și de a manipula aceste date, luând ţinând cont de legăturile dintre obiecte. Fiecare obiect este caracterizat de un set de proprietăți de date, care în baza de date sunt numite atribute.
5240.		Crearea bazei de date „Decanatul Universității”.	1,57 MB
	O bază de date (DB) este o colecție de date interconectate stocate împreună pe medii de memorie externe ale computerului, cu o astfel de organizare și redundanță minimă care le permite să fie utilizate în mod optim pentru una sau mai multe aplicații

Scopul prelegerii

După ce ați studiat materialul din această prelegere, veți ști:

ce s-a întâmplat model de date de întreprindere ;
cum se convertesc model de date corporative la modelul de depozit de date;
elemente esentiale model de date corporative ;
nivelurile de prezentare a modelului de date al întreprinderii ;
algoritm pentru conversia unui model de date corporative într-un model de depozit de date multidimensional ;

si invata:

dezvolta modele de depozit de date bazate pe model de date corporative organizații;
dezvoltarea unei scheme stea folosind instrumentele CASE;
tabele de partiții model multidimensional folosind instrumentele CASE.

Model de date de întreprindere

Introducere

Miezul oricărui depozit de date este modelul său de date. Fără un model de date, va fi foarte dificil să organizați datele într-un depozit de date. Prin urmare, dezvoltatorii HD trebuie să petreacă timp și efort pentru a dezvolta un astfel de model. Dezvoltarea modelului HD cade pe umerii designerului HD.

În comparație cu proiectarea sistemelor OLTP, metodologia de proiectare a depozitului de date are o serie de caracteristici distinctive legate de orientarea structurilor de stocare a datelor pentru rezolvarea problemelor de analiză și suport informațional pentru procesul decizional. Modelul de date al depozitului de date trebuie să ofere o soluție eficientă tocmai la aceste probleme.

Punctul de plecare în proiectarea unui depozit de date poate fi așa-numitul model de date de întreprindere(model de date corporative sau model de date de întreprindere, EDM), care este creat în timpul procesului de proiectare a sistemelor OLTP ale unei organizații. La proiectare model de date corporative De obicei, se încearcă crearea, pe baza tranzacțiilor comerciale, a unei structuri de date care să colecteze și să sintetizeze toate nevoile de informații ale organizației.

Prin urmare, model de date de întreprindere conţine informatie necesara pentru a construi un model de depozit de date. Prin urmare, în prima etapă, dacă un astfel de model există în organizație, un designer de depozit de date poate începe să proiecteze un depozit de date rezolvând problema transformării model de date corporative la modelul HD.

Model de date de întreprindere

Cum se rezolvă problema transformării model de date corporative la modelul HD? Pentru a rezolva această problemă, trebuie să aveți acest model, adică. model de date de întreprindere trebuie construită şi documentat. Și trebuie să înțelegi Ce din acest model și Cum ar trebui transformat într-un model de stocare a datelor.

Să clarificăm conceptul din perspectiva unui designer HD model de date corporative. Sub model de date corporative să înțeleagă o descriere structurată, pe mai multe niveluri, a domeniilor organizației, a structurilor de date ale domeniilor, a proceselor de afaceri și a procedurilor de afaceri, a fluxurilor de date acceptate în organizație, a diagramelor de stare, a matricelor de proces de date și a altor reprezentări model care sunt utilizate în activitățile organizației. . Astfel, în sensul larg al cuvântului, model de date de întreprindere este un ansamblu de modele la diferite niveluri care caracterizează (modelează la un anumit nivel abstract) activitățile unei organizații, i.e. conţinut model corporativ depinde direct de ce structuri model au fost incluse în el într-o organizație dată.

Elemente principale model de date corporative sunt:

descrierea domeniilor tematice ale organizației (definirea domeniilor de activitate);
relațiile dintre domeniile definite mai sus;
model de date informaționale (model ERD sau model entitate-relație);
pentru fiecare descriere a disciplinei:
- chei de entitate;
- atributele entității;
- subtipuri și supertipuri;
- legături între entități;
- grupări de atribute;
- relațiile dintre domeniile de studiu;
model funcțional sau model de proces de afaceri;
diagrame de flux de date;
diagrame de stare;
alte modele.

Prin urmare, model de date de întreprindere conține entități, atribute și relații care reprezintă nevoile de informații ale unei organizații. În fig. 16.1 prezintă elementele principale model de date corporative.

Straturi de reprezentare a modelului de date pentru întreprinderi

Modelul de date al întreprinderii este subdivizat pe domenii, care reprezintă grupuri de entități relevante pentru susținerea nevoilor specifice de afaceri. Unele domenii pot acoperi funcții specifice de afaceri, cum ar fi managementul contractelor, în timp ce altele pot combina entități care descriu produse sau servicii.

Fiecare model logic trebuie să corespundă unui domeniu de problemă existent model de date corporative. Dacă modelul logic nu îndeplinește această cerință, trebuie adăugat un model de definire a domeniului.

Un model de date de întreprindere are de obicei mai multe niveluri de prezentare. De fapt nivel inalt(nivel inalt) model de date corporative există o descriere a principalelor domenii ale organizației și a relațiilor lor la nivel de entitate. În fig. 16.2 prezintă un fragment model de date corporative nivel superior.

Orez. 16.2.

Diagrama prezentată în figură prezintă patru domenii: „Cumpărător” ( Client), "Verifica" ( cont), "Ordin" ( Ordin) și „Produs” ( Produs). De obicei, la nivelul superior, vizualizările modelului specifică doar conexiuni directeîntre domeniile de subiect, care, de exemplu, înregistrează următorul fapt: cumpărătorul plătește o factură pentru comanda de mărfuri. Informații detaliate și relații indirecte la acest nivel model corporativ nu sunt date.

Pe următorul nivel mediu(nivel mediu) model de date corporative afișează informații detaliate despre obiectele de domeniu, adică chei și atributele entității, relațiile lor, subtipurile și supertipurile, etc. Pentru fiecare domeniu al modelului de nivel superior, există un model de nivel mediu. În fig. 16.3 este prezentat nivel mediu reprezentare model corporativ pentru un fragment din tematica „Comanda”.

Din fig. 16.3 puteți vedea că zona de subiect „Comandă” ( Ordin) include mai multe entități, definite prin atributele lor și relațiile dintre ele. Modelul prezentat vă permite să răspundeți la întrebări precum data comenzii, cine a plasat comanda, cine a trimis comanda, cine primește comanda și altele. Din diagrama de mai sus este clar că în această organizație există două tipuri de comenzi - comenzi pentru o promoție ( Comercial) și comenzi cu amănuntul ( Cu amănuntul).

observa asta model de date de întreprindere poate reprezenta diferite aspecte ale activităților unei organizații și cu diferite grade de detaliu și completitudine. Dacă model corporativ reprezintă toate aspectele activităților organizației, se mai numește model de date de organizare(model de date de întreprindere).

Din punctul de vedere al proiectării unui depozit de date, un factor important în deciderea creării unui model de depozit de date din model de date corporative este statul completitudine model de date corporative.

Modelul de date corporative al unei organizații are caracteristica evoluției, adică. se dezvoltă și se îmbunătățește constant. Unele domenii tematice model de date corporative poate fi bine pus la punct, pentru unii lucrul poate să nu fi început încă. Dacă un fragment din domeniul subiectului nu este elaborat în model de date corporative, atunci nu este posibil să folosiți acest model ca punct de plecare pentru proiectarea unui depozit de date.

Gradul de finalizare model corporativ poate fi nivelat în proiectarea depozitului după cum urmează. Deoarece procesul de dezvoltare a unui depozit de date este de obicei împărțit în timp într-o succesiune de etape, procesul de proiectare a acestuia poate fi sincronizat cu proces de finalizare dezvoltarea fragmentelor individuale model de date corporative organizatii.

La cel mai jos nivelul de prezentare a modelului de date corporative afișează informații despre caracteristicile fizice ale obiectelor bazei de date corespunzătoare model de date logic in medie stratul de prezentare al modelului de date corporative.

Din ce în ce mai mult, profesioniștii IT își îndreaptă atenția către soluții de gestionare a datelor bazate pe modele de date standard din industrie și șabloane de decizii de afaceri. Modelele de date fizice complexe și rapoartele de analiză de afaceri gata de descărcat pentru anumite domenii de activitate vă permit să unificați componenta informațională a activităților unei întreprinderi și să accelerați semnificativ execuția proceselor de afaceri. Șabloanele de soluții permit furnizorilor de servicii să valorifice puterea informațiilor non-standard ascunse în sistemele existente, reducând astfel termenele, costurile și riscurile proiectului. De exemplu, proiectele din lumea reală arată că modelul de date și șabloanele de decizie de afaceri pot reduce efortul de dezvoltare cu 50%.

Un model logic al industriei este o reprezentare specifică domeniului, integrată și structurată logic a tuturor informațiilor care trebuie să se afle într-un depozit de date al întreprinderii pentru a răspunde atât întrebărilor strategice, cât și tactice de afaceri. Scopul principal al modelelor este de a facilita orientarea în spațiul de date și de a ajuta la identificarea detaliilor care sunt importante pentru dezvoltarea afacerii. În condiții moderne, pentru a conduce cu succes o afacere, este absolut necesar să aveți o înțelegere clară a legăturilor dintre diversele componente și o bună înțelegere a imaginii de ansamblu a organizației. Identificarea tuturor detaliilor și conexiunilor folosind modele permite utilizarea cât mai eficientă a timpului și a instrumentelor de organizare a muncii companiei.

Un exemplu de model „GIS pentru guvern și administrație locală”.

Astăzi, este important din punct de vedere strategic pentru furnizorii de software și servicii să poată răspunde rapid la schimbările din industrie asociate cu inovațiile tehnologice, ridicarea restricțiilor guvernamentale și complexitatea lanțurilor de aprovizionare. Odată cu schimbările în modelul de afaceri, complexitatea și costul tehnologiilor informaționale necesare susținerii activităților companiei sunt în creștere. Gestionarea datelor este deosebit de dificilă într-un mediu în care sistemele de informații corporative, precum și cerințele funcționale și de afaceri pentru acestea, sunt în continuă schimbare.

Modelele de date din industrie sunt concepute pentru a ajuta la facilitarea și optimizarea acestui proces și pentru a aduce abordarea IT la un nivel modern.

Modele de date industriale de la companieEsri

Modelele de date pentru platforma Esri ArcGIS oferă șabloane de lucru pentru utilizare în proiecte GIS și crearea de structuri de date pentru diferite domenii de aplicație. Construirea unui model de date implică crearea unui design conceptual, a unei structuri logice și a unei structuri fizice care pot fi apoi utilizate pentru a construi o bază de date geografică personală sau de întreprindere. ArcGIS oferă instrumente pentru crearea și gestionarea schemei bazei de date, iar șabloanele de model de date sunt folosite pentru a începe rapid un proiect GIS într-o varietate de aplicații și industrii. Esri și comunitatea de utilizatori au petrecut o perioadă semnificativă de timp dezvoltând o serie de șabloane care pot oferi o modalitate rapidă de a începe cu proiectarea geodatabaselor pentru întreprinderi. Aceste proiecte sunt descrise și documentate la support.esri.com/datamodels. Mai jos, în ordinea în care sunt menționate pe acest site, este traducerea semantică a numelor modelelor industriale Esri:

Registrul de adrese
Agricultură
Meteorologie
Date spațiale de bază
Biodiversitatea
Interiorul clădirilor
Contabilitatea gazelor cu efect de seră
Menținerea limitelor administrative
Forte armate. Serviciul de informații
Energie (inclusiv noul protocol ArcGIS MultiSpeak)
Structuri ecologice
Ministerul Situațiilor de Urgență. Protecție împotriva incendiilor
Cadastru forestier
Silvicultură
Geologie
GIS național (e-gov)
Ape subterane și ape uzate
Sănătate
Arheologia și protecția monumentelor
securitate naționala
Hidrologie
Organizația Hidrografică Internațională (OHI). Format S-57 pentru ENC
Irigare
carte funciara
Guvernul municipal
Navigație maritimă
Cadastrul de stat
Structuri de petrol și gaze
Conducte
Stocare raster
Batimetrie, topografia fundului mării
Telecomunicatii
Transport
Alimentare cu apă, canalizare, locuințe și servicii comunale

Aceste modele conțin toate caracteristicile necesare standardului industrial, și anume:

sunt disponibile gratuit;
nu sunt legate de tehnologia producătorului „selectat”;
create ca urmare a implementării unor proiecte reale;
creat cu participarea experților din industrie;
concepute pentru a asigura interacțiunea informațională între diverse produse și tehnologii;
nu contrazice alte standarde și documente de reglementare;
utilizat în proiecte finalizate din întreaga lume;
sunt concepute pentru a lucra cu informații despre orice ciclu de viață sistemul care se creează, și nu proiectul în sine;
extensibil pentru a satisface nevoile clienților fără pierderea compatibilității cu alte proiecte și/sau modele;
însoțit de materiale și exemple suplimentare;
utilizate în ghidurile și materialele tehnice ale diferitelor companii industriale;
o comunitate mare de participanți, cu acces la comunitate deschis tuturor;
un număr mare de referințe la modele de date în publicațiile din ultimii ani.

Experții Esri fac parte dintr-un grup de experți format din organisme independente care recomandă diferite modele industriale pentru utilizare, cum ar fi PODS (Standarde de date deschise pentru conducte - un standard deschis pentru industria petrolului și gazelor; în prezent există o implementare a PODS ca bază de geodatabase Esri PODS Esri Spatial 5.1.1) sau geodatabase (GD) de la ArcGIS for Aviation, care ia în considerare recomandările ICAO și FAA, precum și standardul de schimb de date de navigație AIXM 5.0. În plus, există modele recomandate care respectă strict standardele existente ale industriei, cum ar fi S-57 și ArcGIS for Maritime (marin și de coastă), precum și modele create din munca serviciilor profesionale Esri care sunt standardele „de facto”. în domeniile lor respective.zone. De exemplu, GIS pentru Națiune și Guvernul Local au influențat standardele NSDI și INSPIRE, iar Hydro și Apele Subterane sunt utilizate pe scară largă în pachetele profesionale disponibile gratuit și produsele comerciale ale companiilor terțe ale ArcHydro. Trebuie remarcat faptul că Esri acceptă și standarde „de facto”, precum NHDI. Toate modelele de date propuse sunt documentate și gata de utilizare în procesele IT ale întreprinderii. Materialele însoțitoare pentru modele includ:

diagrame de relații de entități UML;
structuri de date, domenii, directoare;
șabloane de geodatabase gata făcute în format ArcGIS GDB;
eșantion de date și eșantion de aplicații;
exemple de scripturi de încărcare a datelor, exemple de utilitare de analiză;
cărți de referință privind structura de date propusă.

Esri își rezumă experiența în modelele din industria construcțiilor sub formă de cărți și localizează materialele publicate. Esri CIS a localizat și publicat următoarele cărți:

Arhitectură orientată pe servicii geospațiale (SOA);
Proiectare de baze geodate pentru transport;
Sisteme informaționale geografice corporative;
GIS: energie nouă a întreprinderilor electrice și gaze;
Petrol și gaze pe o hartă digitală;
Modelând lumea noastră. Ghid de proiectare a bazei de date geodate Esri;
Mă gândesc la GIS. Planificarea GIS: un ghid pentru manageri;
Sisteme informatice geografice. Bazele;
GIS pentru management administrativ și economic;
Web GIS. Principii și aplicare;
Strategii de proiectare a sistemelor, ediția a 26-a;
68 de numere ale revistei ArcReview cu publicații de la companii și utilizatori de sisteme GIS;
... și multe alte note și publicații tematice.

De exemplu, cartea Modelând lumea noastră...„ (traducere) este un ghid cuprinzător și de referință pentru modelarea datelor în GIS în general, și modele de date geodate în special. Cartea arată cum să dezvolte deciziile corecte de modelare a datelor, decizii care sunt implicate în fiecare aspect al unui proiect GIS, de la proiectarea bazei de date la date și colectarea datelor până la analiza și vizualizarea spațială. Descrie în detaliu cum să proiectați o bază de date geografică adecvată unui proiect, să configurați funcționalitatea bazei de date fără programare, să gestionați fluxul de lucru în proiecte complexe, să modelați o varietate de structuri de rețea, cum ar fi râul, rețelele de transport sau electrice, să integreze datele sondajului spațial în procesul de analiză și afișare geografică, precum și să creeze modele 3D de date GIS. Proiectarea bazelor de geodate pentru transport„conține abordări metodologice testate pe un număr mare de proiecte și respectă pe deplin cerințele legislative din Europa și SUA, precum și standardele internaționale. Și în carte” GIS: energie nouă a întreprinderilor electrice și gaze„ folosește exemple din viața reală pentru a arăta beneficiile pe care un GIS de întreprindere le poate aduce unui furnizor de energie, inclusiv aspecte precum serviciul pentru clienți, operațiunile de rețea și alte procese de afaceri.

Unele dintre cărți, traduse și originale, publicate în limba rusă de Esri CIS și DATA+. Acestea abordează atât problemele conceptuale legate de tehnologia GIS, cât și multe aspecte aplicate ale modelării și implementării GIS de diferite scări și scopuri.

Să luăm în considerare utilizarea modelelor industriale folosind exemplul BISDM (Building Interior Space Data Model, model informațional al spațiului intern al unei clădiri) versiunea 3.0. BISDM este o dezvoltare a modelului BIM mai general (Building Information Model) și este destinat utilizării în proiectarea, construcția, operarea și dezafectarea clădirilor și structurilor. Folosit în software-ul GIS, vă permite să schimbați în mod eficient geodate cu alte platforme și să interacționați cu acestea. Aparține grupului general de sarcini FM (gestionarea infrastructurii organizaționale). Să enumerăm principalele avantaje ale modelului BISDM, a cărui utilizare permite:

organizează schimbul de informații într-un mediu eterogen după reguli uniforme;
obține o întruchipare „fizică” a conceptului BIM și reguli recomandate pentru managementul proiectelor de construcții;
menținerea unui singur depozit folosind GIS pe parcursul întregului ciclu de viață al unei clădiri (de la proiectare până la dezafectare);
coordonează activitatea diverșilor specialiști în proiect;
vizualizați programul stabilit și etapele de construcție pentru toți participanții;
dați o estimare preliminară a costului și a timpului de construcție (date 4D și 5D);
monitorizează progresul proiectului;
să asigure funcționarea de înaltă calitate a clădirii, inclusiv întreținerea și reparațiile;
să devină parte a sistemului de management al activelor, inclusiv funcții de analiză a eficienței utilizării spațiului (închiriere, spațiu depozit, management al angajaților);
efectuează calcule și gestionează sarcinile de eficiență energetică a clădirii;
simulează mișcarea fluxurilor umane.

BISDM definește regulile de lucru cu date spațiale la nivelul spațiilor interne dintr-o clădire, inclusiv scopul și tipurile de utilizare, comunicațiile stabilite, echipamente instalate, contabilizarea reparațiilor și întreținerii, înregistrarea incidentelor, relațiile cu alte active ale companiei. Modelul ajută la crearea unui depozit unificat de date geografice și non-geografice. Experiența celor mai importante companii din lume a fost folosită pentru a identifica entitățile și modela la nivelul bazei de geodate relațiile spațiale și logice ale tuturor elementelor fizice care formează atât clădirea în sine, cât și interiorul acesteia. Urmărirea principiilor BISDM poate simplifica semnificativ sarcinile de integrare cu alte sisteme. Prima etapă este de obicei integrarea CAD. Apoi, în timpul funcționării clădirii, se folosește schimbul de date cu sistemele ERP și EAM (SAP, TRIRIGA, Maximo etc.).

Vizualizarea elementelor structurale BISDM folosind ArcGIS.

În cazul utilizării BISDM, clientul/proprietarul unității primește un schimb de informații end-to-end de la ideea de a crea unitatea până la dezvoltarea unui proiect complet, controlul construcției cu primirea de up- informații la zi până la momentul punerii în funcțiune a instalației, controlul parametrilor în timpul funcționării și chiar în timpul reconstrucției sau dezafectării instalației. Urmând paradigma BISDM, GIS și geodatabase create cu ajutorul acesteia devin un depozit comun de date pentru sistemele conectate. Adesea, geodatabase conține date create și exploatate sisteme de la terți. Acest lucru trebuie luat în considerare la proiectarea arhitecturii sistemului creat.

La o anumită etapă, „masa critică” de informații acumulată vă permite să treceți la un nou nivel calitativ. De exemplu, la finalizarea etapei de proiectare a unei clădiri noi, în GIS este posibil să vizualizați automat modele 3D de ansamblu, să compilați o listă de echipamente instalate, să calculați kilometrii rețelelor de utilități instalate, să efectuați o serie de verificări și chiar să dați un evaluare financiară preliminară a costului proiectului.

Să remarcăm încă o dată că atunci când BISDM și ArcGIS sunt utilizate împreună, devine posibilă construirea automată a modelelor 3D folosind date acumulate, deoarece geodatabase conține o descriere completă a obiectului, inclusiv coordonatele z, aparținând etajului, tipuri de conexiuni. a elementelor, metodele de instalare a echipamentelor, materialelor, căilor accesibile deplasarea personalului, scopul funcțional al fiecărui element etc. și așa mai departe. Trebuie luat în considerare faptul că, după importul inițial al tuturor materialelor de proiectare în geodatabase BISDM, este nevoie de conținut de informații suplimentare pentru:

plasarea modelelor 3D de obiecte și echipamente în locații desemnate;
colectarea de informații despre costul materialelor și procedura de așezare și instalare a acestora;
controlul traficului pe baza dimensiunilor echipamentelor nestandard instalate.

Utilizarea ArcGIS simplifică importul de obiecte 3D suplimentare și cărți de referință din surse externe, deoarece Modulul ArcGIS Data Interoperability vă permite să creați proceduri pentru importarea unor astfel de date și plasarea lor corectă în model. Sunt acceptate toate formatele utilizate în industrie, inclusiv IFC, AutoCAD Revit, Bentlye Microstation.

Modele de date industriale de la IBM

IBM oferă un set de instrumente și modele de gestionare a stocării pentru diverse domenii de activitate:

IBM Banking and Financial Markets Data Warehouse (finanțare)
IBM Banking Data Warehouse
Modele de servicii și procese bancare IBM
IBM Health Plan Data Model (asistență medicală)
IBM Insurance Information Warehouse (asigurare)
Modele de servicii și procese de asigurare IBM
IBM Retail Data Warehouse (comerț cu amănuntul)
IBM Telecommunications Data Warehouse (telecomunicații)
Pachetul InfoSphere Warehouse:
- pentru Customer Insight (pentru a înțelege clienții)
- pentru Market and Campaign Insight (pentru a înțelege compania și piața)
- pentru Supply Chain Insight (pentru a înțelege furnizorii).

De exemplu, modelul IBMBancarșiFinanciarPiețeleDateDepozit este conceput pentru a rezolva probleme specifice industriei bancare din perspectiva datelor și IBMBancarProcesșiServiciuModele- din punct de vedere al proceselor și SOA (arhitectură orientată pe servicii). Modele prezentate pentru industria telecomunicațiilor IBMinformațieCadru (IFW)Și IBMTelecomunicatiiDateDepozit (TDW). Ele ajută la accelerarea semnificativă a procesului de creație. sisteme analitice, precum și reducerea riscurilor asociate cu dezvoltarea aplicațiilor de analiză a afacerii, managementul datelor corporative și organizarea depozitelor de date, ținând cont de specificul industriei de telecomunicații. Capacitățile IBM TDW acoperă întregul spectru al pieței serviciilor de telecomunicații - de la furnizori de internet și operatori de rețele de cablu care oferă servicii de telefonie cu fir și fără fir, transmisie de date și conținut multimedia, până la companii multinaționale care furnizează servicii de telefonie, satelit, distanțe lungi și comunicatii internationale, precum și organizații rețele globale. Astăzi, TDW este utilizat de liniile mari și mici și comunicații fără fir La nivel mondial.

Un instrument numit InfoSphere Warehouse Pack pentru cunoștințe despre clienți oferă conținut de afaceri structurat, ușor de implementat pentru un număr tot mai mare de proiecte și industrii de afaceri, inclusiv bancar, asigurări, finanțe, planuri de sănătate, telecomunicații, retail și distribuție. Pentru utilizatorii business Pachetul InfoSphere Warehouse pentru perspectivă privind piața și campania ajută la maximizarea eficacității activităților de analiză a pieței și a campaniilor de marketing printr-un proces de dezvoltare pas cu pas și ținând cont de specificul afacerii. Prin utilizarea InfoSphere Warehouse Pack pentru Supply Chain Insight organizațiile pot obține informații actuale despre operațiunile lanțului de aprovizionare.

Poziția Esri în cadrul arhitecturii soluțiilor IBM.

Abordarea IBM față de companiile de energie electrică și de utilități merită o atenție specială. Pentru a satisface cerințele tot mai mari ale clienților, utilitățile necesită o arhitectură mai flexibilă decât cea utilizată în prezent, precum și un model de obiect standard pentru industrie pentru a facilita fluxul liber al informațiilor. Acest lucru va îmbunătăți capacitățile de comunicații ale companiilor energetice, permițându-le să colaboreze mai rentabil și să ofere noilor sisteme o mai mare vizibilitate asupra tuturor resurselor de care au nevoie, indiferent de locul în care se află în cadrul organizației. La baza acestei abordări se află SOA (arhitectura orientată pe servicii), un model component care stabilește o corespondență între funcțiile departamentelor și serviciile diverselor aplicații care pot fi refolosite. „Serviciile” unor astfel de componente fac schimb de date prin interfețe fără obligații rigide, ascunzând utilizatorului întreaga complexitate a sistemelor din spatele lor. În acest mod, întreprinderile pot adăuga cu ușurință noi aplicații, indiferent de furnizorul de software, sistemul de operare, limbajul de programare sau altele caracteristici interne DE. Bazat pe SOA, conceptul este implementat SIGUR ( Arhitectura soluției pentru energie permite utilităților să obțină o viziune holistică, bazată pe standarde, asupra infrastructurii lor.

Esri ArcGIS® este o platformă software recunoscută la nivel internațional pentru sistemele de informații geografice (GIS), care oferă crearea și gestionarea activelor digitale ale rețelelor de energie electrică, transport gaz, distribuție și telecomunicații. ArcGIS vă permite să efectuați cel mai complet inventar al componentelor rețelei de distribuție electrică, ținând cont de locația lor spațială. ArcGIS extinde semnificativ arhitectura IBM SAFE prin furnizarea de instrumente, aplicații, fluxuri de lucru, analize și capabilități de integrare a informațiilor necesare pentru a gestiona un utilitar inteligent. ArcGIS din cadrul IBM SAFE vă permite să obțineți informații din diverse surse despre infrastructura, active, clienți și angajați cu date exacte despre locația lor, precum și să creați, stocați și procesați informații geo-referințe despre activele întreprinderii (suporturi, conducte, fire, transformatoare, canale de cablu etc.). ArcGIS în cadrul infrastructurii SAFE vă permite să integrați în mod dinamic aplicațiile de bază de afaceri prin combinarea datelor din sistemele GIS, SCADA și de servicii pentru clienți cu informatii externe, cum ar fi volumul traficului, condițiile meteorologice sau imaginile din satelit. Utilitățile folosesc astfel de informații combinate într-o varietate de scopuri, de la S.O.R. (imagine generală a situației operaționale) înainte de inspectarea instalațiilor, întreținere, analiza și planificarea rețelei.

Componentele informaționale ale unei întreprinderi de furnizare a energiei pot fi modelate folosind mai multe niveluri, care sunt clasificate de la cel mai scăzut - fizic - până la cel mai înalt, cel mai complex nivel al logicii procesului de afaceri. Aceste straturi pot fi integrate pentru a îndeplini cerințele tipice ale industriei, cum ar fi înregistrarea automată a măsurătorilor și controlul de supraveghere și controlul achiziției de date (SCADA). Prin construirea arhitecturii SAFE, utilitățile fac pași semnificativi în direcția promovării unui model de obiect deschis la nivelul întregii industrie, numit Common Information Model (CIM) pentru energie și utilități. Acest model oferă fundația necesară pentru multe întreprinderi pentru a trece către o arhitectură orientată spre servicii, deoarece încurajează utilizarea standardelor deschise pentru structurarea datelor și a obiectelor. Asigurându-vă că toate sistemele folosesc aceleași obiecte, confuzia și inelasticitatea asociate cu diferite implementări ale acelorași obiecte vor fi reduse la minimum. În acest fel, definiția entității client și a altor entități importante de afaceri va fi unificată în toate sistemele de utilități. Cu CIM, furnizorii de servicii și consumatorii pot împărtăși acum o structură de date comună, facilitând externalizarea componentelor de afaceri costisitoare, deoarece CIM stabilește o bază comună pe care se poate construi schimbul de informații.

Concluzie

Modelele cuprinzătoare de date din industrie oferă companiilor o vizualizare unică și integrată a informațiilor lor de afaceri. Multe companii consideră că este dificil să-și integreze datele, deși aceasta este o condiție prealabilă pentru majoritatea proiectelor la nivel de întreprindere. Potrivit unui studiu realizat de The Data Warehousing Institute (TDWI), peste 69% dintre organizațiile chestionate au descoperit că integrarea a fost o barieră semnificativă în adoptarea de noi aplicații. Dimpotrivă, integrarea datelor aduce companiei venituri tangibile și eficiență sporită.

Un model construit corect definește fără ambiguitate semnificația datelor, care în acest caz sunt date structurate (spre deosebire de datele nestructurate, cum ar fi o imagine, un fișier binar sau un text, unde semnificația poate fi ambiguă). Cele mai eficiente modele din industrie sunt cele oferite de furnizori profesioniști, care includ Esri și IBM. Rentabilitatea ridicată din utilizarea modelelor lor este obținută datorită nivelului lor semnificativ de detaliu și acuratețe. Acestea conțin de obicei multe atribute de date. În plus, Esri și IBM nu numai că au o experiență vastă în modelare, dar sunt și bine versați în construirea de modele specifice industriei.

Model de date de întreprindere. Baze de date corporative. Modelul de date al întreprinderii include: Model de date relaționale. Sisteme informatice corporative. sisteme informatice de birou Principiile creării unui depozit corporativ unificat

„Basmul este o minciună, dar există un indiciu în el...”

Debriefing

Antifragilitate

Ce este un depozit de date și de ce îl construim?

Caracteristicile cheie ale depozitelor de date

Concept arhitectural

Miezul sistemului

Modelul de bază de stocare și modelul de date pentru întreprinderi

Stratul de date primar (sau stratul de punere în scenă istoricizat sau operațional)

Strat de vitrină analitică

Stratul de serviciu

Proiectarea si intretinerea modelelor de date de depozit

Caracteristicile proiectelor de depozit de date

Depozitul de date este un software personalizat

Depozitul de date este un proiect de integrare

Depozitul de date este un proiect de echipă

Depozitul de date are o durată de viață mai lungă în comparație cu alte sisteme

Dezvoltare iterativă graduală

Depozite de date - „istoric multi-proiect”

Echilibrul de inovație și soluții dovedite

Epilog

Modele de date industriale

Publicaţii

Epilog

Modele de date industriale

Publicaţii

TEMA V. BAZELE DE DATE CORPORATE

Model de date de întreprindere

Introducere

Model de date de întreprindere

Straturi de reprezentare a modelului de date pentru întreprinderi