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

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ă ea inevitabil „a luat subiectul un pic mai larg” – iar alte categorii de cititori au căzut în câmpul vizual. Unele puncte vor părea controversate, altele nu sunt clare, altele sunt evidente. Oamenii sunt diferiți - cu medii, medii și poziții diferite.
De exemplu, întrebările tipice manageriale sunt „când să angajezi arhitecți?”, „Când să faci arhitectură?” sunet pentru noi (dezvoltatori, designeri) destul de ciudat, pentru că pentru noi arhitectura sistemului apare odată cu nașterea lui - nu contează dacă suntem conștienți sau nu de el. Și chiar dacă nu există un rol formal al unui arhitect într-un proiect, un dezvoltator normal „întotdeauna își include propriul arhitect intern”.

De cont mare, nu contează cine îndeplinește exact rolul arhitectului - este important ca cineva să pună întrebări similare și să investigheze răspunsurile la acestea. Dacă arhitectul este clar evidențiat, 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?

„Unicitatea antifragilității este că ne permite să lucrăm cu necunoscutul, să facem ceva în condiții în care nu înțelegem exact ce facem și să obținem succesul.”/ Nassim N. Talb /

Prin urmare, criza și un grad ridicat de incertitudine nu sunt o scuză în favoarea absenței arhitecturii, ci factori care întăresc nevoia acesteia.

Etichete: Adăugați etichete

Zaitsev S.L., Ph.D.

Grupuri repetate

Grupurile duplicate sunt atribute pentru care o singură instanță a unei entități poate avea mai multe valori. De exemplu, o persoană poate avea mai multe aptitudini. Dacă, în ceea ce privește cerințele de business, trebuie să cunoaștem nivelul de calificare pentru fiecare, iar fiecare persoană poate avea doar două aptitudini, putem crea entitatea prezentată în Fig. 1.6. Aici este entitatea O PERSOANA cu două atribute pentru stocarea abilităților și nivelul de abilități pentru fiecare.

Orez. 1.6. Acest exemplu folosește grupuri repetate.

Problema cu repetarea grupurilor este că nu putem ști exact câte abilități poate avea o persoană. În viața reală, unii oameni au o singură abilitate, alții au mai multe, iar alții nu au încă nici una. Figura 1.7 prezintă modelul redus la prima formă normală. Observați adăugarea ID abilitate pe care fiecare îl identifică în mod unic ABILITATE.

Orez. 1.7. Model redus la primul forma normala.

Un fapt într-un singur loc

Dacă același atribut este prezent în mai multe entități și nu este o cheie străină, atunci acest atribut este considerat redundant. Modelul logic nu trebuie să conțină date redundante.

Redundanța necesită spațiu suplimentar, dar în timp ce eficiența memoriei este importantă, adevărata problemă se află în altă parte. Asigurarea că datele redundante sunt sincronizate este o sarcină generală și riscați întotdeauna să creați valori conflictuale.

În exemplul anterior ABILITATE depinde de ID persoana iar din ID abilitate. Asta înseamnă că nu vei avea ABILITATE până când apare O PERSOANA, detinand aceasta pricepere. Acest lucru face, de asemenea, dificilă schimbarea numelui aptitudinii. Este necesar să găsiți fiecare intrare cu Numele abilității și să o schimbați pentru fiecare Persoană care deține această abilitate.

Figura 1.8 prezintă modelul în a doua formă normală. Rețineți că entitatea adăugată ABILITATE, și atributul TITLU competența este transferată acestei entități. Nivelul de calificare a rămas, respectiv, la intersecție PERSOANE și ABILITARE.

Orez. 1.8. În a doua formă normală, grupul care se repetă este mutat într-o altă entitate. Acest lucru oferă flexibilitatea de a adăuga numărul necesar de abilități și de a schimba numele abilității sau descrierea abilității într-un singur loc.

Fiecare atribut depinde de cheie

Fiecare atribut al unei entități trebuie să depindă de cheia primară a acelei entități. În exemplul anterior Numele scoliiși Zona geografica prezente în tabel O PERSOANA dar nu descrie persoana. Pentru a realiza a treia formă normală, trebuie să mutați atributele în entitate, unde acestea vor depinde de cheie. Figura 1.9. arată modelul în a treia formă normală.

Orez. 1.9. În a treia formă normală Numele scoliiși Regiunea geografică transferate la entitate, unde valorile lor depind de cheie.

Relații de la multe la multe

Relaţie multi-la-multi reflectă realitatea lumii înconjurătoare. Rețineți că în Figura 1.9, există o relație de la mulți la mulți între PERSONALĂși ŞCOALĂ... Atitudinea reflectă cu exactitate faptul că O PERSOANA pot studia în multe SCOALILE si in ŞCOALĂ poate invata multe PERSOANĂ. Pentru a realiza a patra formă normală, se creează o entitate asociativă care elimină relația monogie-la-mulți prin formarea intrare separată pentru fiecare combinație unică de școală și persoană. Figura 1.10 prezintă modelul în a patra formă normală.

Orez. 1.10. În a patra formă normală, o relație monogo-la-mulți între PERSONALĂși ŞCOALĂ rezolvată prin introducerea unei entități asociative, în care se alocă o intrare separată pentru fiecare combinație unică SCOALILEși PERSOANE.

Definiții formale ale formelor normale

Următoarele definiții ale formelor normale pot părea descurajante. Gândiți-vă la ele pur și simplu ca la formule pentru atingerea normalizării. Formele normale se bazează pe algebră relațională și pot fi interpretate ca transformări matematice. Deși această carte nu este dedicată unei discuții detaliate despre formele normale, modelatorii sunt încurajați să arunce o privire mai profundă asupra subiectului.

Într-o relație dată R, atributul Y depinde funcțional de atributul X. În formă simbolică, RX -> RY (a se citi „RX definește funcțional RY”) - dacă și numai dacă fiecare valoare a lui X din R este asociată cu exact una valoarea lui Y în R (la un moment dat). Atributele X și Y pot fi compuse (Date CJ. Introduction to Database Systems. Ediția a 6-a. Ed. Williams: 1999, 848 p.).

Relația R corespunde primei forme normale (1NF) dacă și numai dacă toate domeniile care îi aparțin conțin doar valori atomice (Data, ibid.).

O relație R corespunde formei normale a doua (2NF) dacă și numai dacă corespunde cu 1NF, iar fiecare atribut non-cheie este complet dependent de cheia primară (Data, ibid.).

Relația R corespunde formei normale a treia (3NF) dacă și numai dacă corespunde cu 2NF, iar fiecare atribut non-cheie nu depinde în mod tranzitiv de cheia primară (Data, ibid.).

Relația R corespunde formei normale Boyes-Codd (BCNF) dacă și numai dacă fiecare determinant este un candidat pentru utilizare ca cheie.

NOTĂ Mai jos este o scurtă explicație a unora dintre abrevierile utilizate în definițiile date.

MVD (dependența cu mai multe valori) este o dependență cu mai multe valori. Folosit numai pentru entitățile cu trei sau mai multe atribute. Într-o dependență cu mai multe valori, valoarea atributului depinde doar de o parte a cheii primare.

FD (dependență funcțională) - dependență funcțională. Cu dependența funcțională, valoarea unui atribut depinde de valoarea unui alt atribut care nu face parte din cheia primară.

JD (dependența de unire) este o dependență de unire. Cu o dependență de uniune, cheia primară a entității părinte este urmărită până la cel puțin descendenții de nivel al treilea, păstrând în același timp capacitatea de a fi utilizată în unire de către cheia originală.

Raportul corespunde celei de-a patra forme normale (4NF) dacă și numai dacă există un MVD în R, de exemplu A®®B. În acest caz, toate atributele lui R depind funcțional de A. Cu alte cuvinte, în R există doar dependențe (FD sau MVD) de forma K®X (adică dependența funcțională a atributului X de candidatul pentru utilizare ca cheie K). În consecință, R îndeplinește cerințele 4NF dacă respectă BCNF și toate MVD-urile sunt de fapt FD (Data, ibid.).

Pentru a cincea formă normală, relația R satisface dependența de unire (JD) * (X, Y,…, Z) dacă și numai dacă R este echivalent cu proiecțiile sale pe X, Y, ..., Z, unde X, Y,..., Z este o submulțime a setului de atribute R.

Există multe alte forme normale pentru tipuri de date complexe și situații specifice care depășesc scopul acestei discuții. Orice pasionat de dezvoltare a modelelor ar dori să învețe și alte forme normale.

Forme normale de afaceri

În cartea sa, Clive Finklestein (An Introduction to Information Engineering: From Strategic Planning to Information Systems. Reading, Massachusetts: Addison-Wesley, 1989) a adoptat o abordare diferită a normalizării. Ea definește formele normale de afaceri în termeni de constrângere asupra acestor forme. Mulți modelatori consideră această abordare mai intuitivă și mai pragmatică.

Prima formă normală de afaceri (1BNF) scoate grupuri repetate către o altă entitate. Această entitate primește propriul nume și atribute cheie primare (compozite) de la entitatea originală și de la grupul său care se repetă.

A doua formă normală de afaceri (2BNF) elimină atributele care sunt parțial dependente de cheia primară a unei alte entități. Cheia primară (compozită) a acestei entități este cheia primară a entității în care a fost localizată inițial, împreună cu chei suplimentare de care atributul este complet dependent.

A treia formă normală de afaceri (3BNF) preia atribute care sunt independente de o cheie primară într-o altă entitate, unde sunt complet dependente de cheia primară a acelei entități.

A patra formă normală de afaceri (4BNF) preia atribute care depind de valoarea cheii primare sau sunt opționale pentru o entitate secundară, unde depind în întregime de valoarea cheii primare sau unde trebuie (neapărat) să fie prezente în acea entitate. entitate.

A cincea formă normală de afaceri (5BNF) apare ca o entitate structurală dacă există o dependență recursivă sau de altă natură între instanțe ale unei entități secundare sau dacă există o dependență recursivă între instanțe ale entității sale primare.

Model de date logice finalizat

Modelul logic completat trebuie să satisfacă cerințele celei de-a treia forme normale de afaceri și să includă toate entitățile, atributele și relațiile necesare pentru a susține cerințele de date și regulile de afaceri asociate cu datele.

Toate entitățile trebuie să aibă nume care să descrie conținutul lor și să aibă un caracter clar, concis, Descriere completa sau definiție. O postare viitoare va acoperi un set inițial de linii directoare pentru formarea corectă a numelor și descrierilor entităților.

Entitățile trebuie să aibă un set complet de atribute, astfel încât fiecare fapt despre fiecare entitate să poată fi reprezentat prin atributele sale. Fiecare atribut trebuie să aibă un nume care să reflecte valorile sale, tip boolean date și o descriere sau definiție clară, scurtă și completă. Într-o postare viitoare pe blog, vom analiza un set inițial de linii directoare pentru formatarea corectă a numelor și descrierilor atributelor.

Relațiile ar trebui să includă o construcție a verbului care descrie relația dintre entități, împreună cu caracteristici precum pluralitatea, necesitatea existenței sau posibilitatea absenței unei relații.

NOTĂ Multitudine comunicarea descrie număr maxim Instanțele de entitate secundară care pot fi asociate cu instanța de entitate originală.Necesitatea existenței sauposibilitatea de absență relația este utilizată pentru a determina numărul minim de instanțe ale unei entități secundare care pot fi asociate cu o instanță a entității originale.

Model de date fizice

După crearea unui complet și adecvat model logic sunteți gata să luați decizia de a alege o platformă de implementare. Alegerea platformei depinde de cerințele de utilizare a datelor și de principiile strategice de modelare a arhitecturii corporației. Alegerea unei platforme este o problemă complexă dincolo de scopul acestei cărți.

În ERwin, un model fizic este o reprezentare grafică a unei baze de date din lumea reală. Baza de date fizică va fi formată din tabele, coloane și relații. Modelul fizic depinde de platforma aleasă pentru implementare și de cerințele de utilizare a datelor. Modelul fizic pentru IMS va fi foarte diferit de cel pentru Sybase. Modelul fizic pentru rapoartele OLAP va arăta diferit de modelul pentru OLTP (procesarea tranzacțiilor online).

Modelatorul de date și administratorul bazei de date (DBA) utilizează modelul logic, cerințele de utilizare și principiile strategice pentru a modela arhitectura corporativă pentru dezvoltare. model fizic date. Puteți denormaliza modelul fizic pentru a îmbunătăți performanța și puteți crea vizualizări pentru a susține cerințele de utilizare. Următoarele secțiuni detaliază procesul de denormalizare și creare a vederilor.

Această secțiune oferă o prezentare generală a procesului de construire a unui model fizic, de colectare a cerințelor de utilizare a datelor, de definire a componentelor unui model fizic și de furnizare de inginerie inversă. În următoarele publicații, aceste probleme sunt tratate mai detaliat.

Colectarea cerințelor de utilizare a datelor

De obicei, colectați cerințele de utilizare a datelor de la început în timpul interviurilor și sesiunilor de lucru. În același timp, cerințele ar trebui să determine cât mai complet posibil utilizarea datelor de către utilizator. Atitudinea superficială și lacunele din modelul fizic pot duce la costuri neplanificate și întârzieri în implementarea proiectului. Cerințele de utilizare includ:

Cerințe de acces și performanță

Caracteristici volumetrice (o estimare a cantității de date de stocat) care permit administratorului să reprezinte volumul fizic al bazei de date

Estimarea numărului de utilizatori care au nevoie de acces simultan la date pentru a vă ajuta să vă proiectați baza de date pentru niveluri de performanță acceptabile

Agregate, pivot și alte date calculate sau derivate care pot fi considerate candidați pentru stocarea în structuri de date persistente

Cerințe pentru raportare și interogări standard pentru a ajuta administratorul bazei de date să construiască indecși

Vizualizări (persistente sau virtuale) care vor ajuta utilizatorul atunci când efectuează operațiuni de agregare sau filtrare a datelor.

Pe lângă președinte, secretar și utilizatori, modelatorul, administratorul bazei de date și arhitectul bazei de date trebuie să participe la sesiunea de cerințe de utilizare. Trebuie discutate cerințele utilizatorului privind datele istorice. Perioada de timp în care datele sunt păstrate are un impact semnificativ asupra dimensiunii bazei de date. Adesea, datele mai vechi sunt stocate într-o formă generalizată, iar datele atomice sunt arhivate sau șterse.

Utilizatorii ar trebui să aducă la sesiune exemple de solicitări și rapoarte. Rapoartele trebuie să fie strict definite și trebuie să includă valori atomice utilizate pentru orice câmpuri de rezumat și rezumat.

Componentele modelului de date fizice

Componentele unui model de date fizice sunt tabele, coloanele și relațiile. Este posibil ca entitățile modelului logic să devină tabele în modelul fizic. Atributele booleene devin coloane. Relațiile logice vor deveni constrângeri asupra integrității relațiilor. Unele relații logice nu pot fi realizate în fizic Bază de date.

Inginerie inversă

Când modelul logic nu este disponibil, devine necesară recrearea modelului din baza existenta date. În ERwin, acest proces se numește inginerie inversă. Inginerie inversă se poate face în mai multe moduri. Modelatorul poate explora structurile de date din baza de date și poate recrea tabele într-un mediu de modelare vizuală. Puteți importa limbajul de definire a datelor (DDL) într-un instrument care acceptă inginerie inversă (cum ar fi Erwin). Instrumentele avansate precum ERwin includ funcții care asigură comunicarea ODBC cu o bază de date existentă pentru a crea un model citire directă structuri de date. Inginerie inversă cu ERwin va fi discutată în detaliu într-o postare viitoare.

Utilizarea limitelor funcționale corporative

Când construiți un model logic pentru modelator, este important să vă asigurați că model nou corespunde la model corporativ... Utilizarea limitelor funcționale ale corporației înseamnă modelarea datelor în termeni utilizați în cadrul unei corporații. Modul în care sunt utilizate datele într-o corporație se schimbă mai repede decât datele în sine. În fiecare model logic, datele trebuie prezentate holistic, indiferent de domeniul subiectului afacerea pe care ea o susține. Entitățile, atributele și relațiile trebuie să definească regulile de afaceri la nivel de corporație.

NOTĂ Unii dintre colegii mei se referă la aceste limite funcționale corporative ca modelare în lumea reală. Modelarea în lumea reală încurajează modelatorul să vadă informațiile în ceea ce privește relațiile și relațiile inerente ale acesteia.

Utilizarea limitelor funcționale corporative pentru un model de date care este construit în mod corespunzător oferă baza pentru susținerea nevoilor de informații ale oricărui număr de procese și aplicații, ceea ce permite corporației să exploateze mai eficient unul dintre activele sale cele mai valoroase - informațiile.

Ce este un model de date de întreprindere?

Model de date pentru întreprinderi (EDM) conține entități, atribute și relații care reprezintă nevoile de informații ale unei corporații. EDM este de obicei clasificat în funcție de domeniile subiectului, care reprezintă grupuri de entități legate de susținerea nevoilor specifice de afaceri. Unele domenii pot acoperi anumite funcții comerciale, cum ar fi managementul contractelor, în timp ce altele pot include entități care descriu produse sau servicii.

Fiecare model logic trebuie să corespundă domeniului existent al modelului de date corporative. Dacă modelul logic nu se potrivește această cerință, trebuie adăugat un model care definește domeniul subiectului. Această comparație asigură că modelul corporativ este îmbunătățit sau ajustat și că toate eforturile de modelare logică sunt coordonate în cadrul corporației.

EDM include, de asemenea, entități specifice care definesc domeniul de aplicare al valorilor pentru atributele cheie. Aceste entități nu au părinți și sunt definite ca independente. Entitățile independente sunt adesea folosite pentru a menține integritatea relațiilor. Aceste entități sunt identificate prin mai multe nume diferite, cum ar fi tabele de coduri, tabele de referință, tabele de tipuri sau tabele de clasificare. Vom folosi termenul „obiect corporativ de afaceri”. Un obiect de afaceri al întreprinderii este o entitate care conține un set de valori ale atributelor care sunt independente de orice altă entitate. Obiectele de afaceri corporative ar trebui utilizate în mod consecvent în cadrul unei corporații.

Construirea unui model de date corporative prin creștere

Există organizații în care modelul corporativ a fost construit de la început până la sfârșit ca urmare a unui singur efort concertat. Pe de altă parte, majoritatea organizațiilor construiesc modele corporative destul de complete prin extindere.

A construi înseamnă a construi ceva secvențial, strat cu strat, așa cum o stridie crește o perlă. Fiecare model de date creat oferă o contribuție la formarea EDM. Construirea unui EDM în acest mod necesită pași suplimentari de modelare pentru a adăuga noi structuri de date și domenii sau pentru a mări structurile de date existente. Acest lucru face posibilă construirea unui model de date de întreprindere prin creșterea, adăugarea iterativă a nivelurilor de detaliu și rafinament.

Conceptul de metodologie de modelare

Există mai multe metodologii de modelare a datelor vizuale. ERwin acceptă două:

IDEF1X (definiție de integrare pentru informații Modelare - o descriere integrată a modelelor informaționale).

IE (Ingineria Informației).

IDEF1X este o metodologie bună, iar utilizarea notației sale este larg răspândită

Descrierea integrată a modelelor informaționale

IDEF1X este o metodologie de modelare a datelor foarte structurată care extinde metodologia IDEF1 adoptată ca standard FIPS (Standarde federale de procesare a informațiilor). IDEF1X folosește un set foarte structurat de tipuri de constructe de modelare și are ca rezultat un model de date care necesită o înțelegere a naturii fizice a datelor înainte ca astfel de informații să poată fi disponibile.

Structura rigidă a IDEF1X forțează modelatorul să atribuie caracteristici unor entități care ar putea să nu corespundă realităților lumii înconjurătoare. De exemplu, IDEF1X necesită ca toate subtipurile de entități să fie exclusive. Acest lucru duce la faptul că o persoană nu poate fi atât client, cât și angajat. În timp ce practica reală ne spune altfel.

Ingineria informației

Clive Finklestein este adesea menționat ca părintele ingineriei informaționale, deși concepte similare i-au fost împărtășite de James Martin (Martin, James. Managing the Database Environment. Upper Saddle River, New Jersey: Prentice Hall, 1983.). Ingineria informației folosește o abordare bazată pe afaceri a managementului informațiilor și folosește o notație diferită pentru a reprezenta regulile de afaceri. IE servește ca extensie și dezvoltare a notării și conceptelor de bază ale metodologiei ER propuse de Peter Chen.

IE oferă infrastructura pentru a susține cerințele de informații prin integrarea planificării strategice corporative cu sistemele informaționale care sunt în curs de dezvoltare. Această integrare permite ca managementul resurselor informaționale să fie mai strâns aliniat cu perspectivele strategice pe termen lung ale corporației. Această abordare bazată pe afaceri i-a determinat pe mulți modelatori să aleagă IE în detrimentul altor metodologii care tind să se concentreze pe provocările de dezvoltare pe termen scurt.

IE propune o secvență de acțiuni care determină o corporație să identifice toate nevoile sale de informații pentru colectarea și gestionarea datelor și identificarea relațiilor dintre obiectele informaționale. Ca urmare, cerințele de informare sunt clar articulate pe baza directivelor de management și pot fi direct traduse într-un sistem de informații de management care va sprijini nevoile strategice de informații.

Concluzie

Înțelegerea modului de utilizare a unui instrument de modelare a datelor precum ERwin este doar o parte a problemei. În plus, trebuie să înțelegeți când sunt rezolvate sarcinile de modelare a datelor și cum sunt colectate cerințele de informații și regulile de afaceri care ar trebui să fie reprezentate în modelul de date. Desfășurarea sesiunilor de lucru oferă mediul cel mai propice pentru colectarea cerințelor de informații într-un mediu care include experți în domeniu, utilizatori și profesioniști în tehnologia informației.

Construirea unui model de date bun necesită analiza și cercetarea cerințelor de informații și a regulilor de afaceri colectate prin sesiuni de lucru și interviuri. Modelul de date rezultat ar trebui comparat cu modelul de întreprindere, dacă este posibil, pentru a se asigura că nu intră în conflict cu modelele de obiecte existente și include toate obiectele necesare.

Modelul de date constă din modele logice și fizice care reprezintă cerințele de informații și regulile de afaceri. Modelul logic ar trebui redus la a treia formă normală. A treia formă normală constrânge, adaugă, actualizează și elimină anomaliile structurii datelor pentru a sprijini principiul „un fapt într-un singur loc”. Cerințele de informații colectate și regulile de afaceri ar trebui analizate și cercetate. Ele trebuie comparate cu modelul de întreprindere pentru a se asigura că nu intră în conflict cu modelele de obiecte existente și includ toate obiectele necesare.

În ERwin, modelul de date include atât modele logice, cât și modele fizice. ERwin implementează abordarea ER și vă permite să creați obiecte model logic și fizic pentru a reprezenta cerințele de informații și regulile de afaceri. Obiectele modelului logic includ entități, atribute și relații. Obiectele modelului fizic includ tabele, coloane și constrângeri privind integritatea relațiilor.

Una dintre următoarele publicații va acoperi problemele de identificare a entităților, definirea tipurilor de entități, alegerea numelor și descrierilor entităților, precum și câteva tehnici pentru a evita cele mai frecvente erori de modelare asociate cu utilizarea entităților.

Entitățile trebuie să aibă un set complet de atribute, astfel încât fiecare fapt despre fiecare entitate să poată fi reprezentat prin atributele sale. Fiecare atribut trebuie să aibă un nume care să reflecte semnificația acestuia, un tip de date boolean și o descriere sau definiție clară, scurtă și completă. Într-o postare viitoare pe blog, vom analiza un set inițial de linii directoare pentru formatarea corectă a numelor și descrierilor atributelor. Relațiile ar trebui să includă o construcție a verbului care descrie relația dintre entități, împreună cu caracteristici precum pluralitatea, necesitatea existenței sau posibilitatea absenței unei relații.

NOTĂ Multitudine relația descrie numărul maxim de instanțe de entitate secundară care pot fi asociate cu o instanță a entității originale.Necesitatea existenței sau posibilitatea absenței relația servește la determinarea numărului minim de instanțe ale unei entități secundare care pot fi asociate cu o instanță a originalului

Scopul prelegerii

După ce ați studiat materialul acestei prelegeri, veți ști:

• ce s-a întâmplat model de date de întreprindere ;
• cum se convertesc model de date de întreprindereîn modelul de depozit de date;
• elemente esentiale model de date corporative ;
• straturile de prezentare ale modelului de date corporative ;
• un algoritm pentru transformarea unui model de date de întreprindere într-un model de depozit de date multidimensional ;

si invata sa:

• dezvolta modele de depozit de date bazate pe model de date corporative organizații;
• proiectați o schemă stea folosind instrumentele CASE;
• tabele de partiții model multidimensional folosind instrumentele CASE.

Model de date de întreprindere

Introducere

Miezul oricărui HD este modelul său de date. Fără un model de date, va fi foarte dificil să organizați datele în HD. Prin urmare, dezvoltatorii de CD-uri ar trebui să aloce timp și efort pentru dezvoltarea unui astfel de model. Dezvoltarea modelului HD cade pe umerii designerului HD.

În comparație cu proiectarea sistemelor OLTP, metodologia de proiectare pentru HD are un număr de trăsături distinctive legate de orientarea structurilor de date ale depozitului pentru rezolvarea problemelor de analiză şi suport informativ procesul de luare a deciziilor. Modelul de date al CD-ului ar trebui să ofere solutie eficienta exact aceste sarcini.

Punctul de plecare în proiectarea CD-ului 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 procesul de proiectare a sistemelor OLTP ale unei organizații. La proiectare model de date corporative de obicei, se încearcă crearea unei structuri de date bazate pe operațiuni de afaceri care să colecteze și să sintetizeze toate nevoile de informații ale unei organizații.

În acest fel, model de date de întreprindere conţine informatie necesara pentru a construi un model de CD. Prin urmare, în prima etapă, dacă un astfel de model există în organizație, designerul HD poate începe designul HD prin rezolvarea problemei transformării model de date corporative în modelul HD.

Model de date de întreprindere

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

Să clarificăm conceptul din punctul de vedere al unui designer de CD model de date corporative. Sub model de date corporative să înțeleagă o descriere structurată pe mai multe niveluri a disciplinelor unei organizații, a structurilor de date a domeniilor, a proceselor de afaceri și a procedurilor de afaceri, a fluxurilor de date organizaționale, 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 cel mai larg al cuvântului, model de date de întreprindere este un set de modele de 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 model de construcții au fost incluse în el într-o organizație dată.

Elementele 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 (ERD -model sau model entitate-relație);
• descriere pentru fiecare domeniu:
  • chei de entitate;
  • atributele entității;
  • subtipuri și supertipuri;
  • relațiile dintre entități;
  • atribute de grupare;
  • relațiile dintre domeniile de studiu;
• model funcțional sau de proces de afaceri;
• diagrame de flux de date;
• diagrame de stare;
• alte modele.

În acest fel, 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.

Niveluri de prezentare a modelului de date al întreprinderii

Model de date de întreprindere subdivizate pe domenii, care reprezintă grupuri de entități legate de susținerea nevoilor specifice de afaceri. Unele domenii pot acoperi anumite funcții comerciale, cum ar fi managementul contractelor, în timp ce altele pot include entități care descriu produse sau servicii.

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

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 este 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 regulă, numai conexiuni directeîntre domenii, care, de exemplu, consemnează următorul fapt: cumpărătorul plătește factura pentru comanda de mărfuri. Detalii și relații indirecte la acest nivel model corporativ nereprezentat.

Pe următorul, nivel mijlociu(nivel mediu) model de date corporative afișate informatii detaliate despre obiecte din domeniile subiectului, adică cheile ș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 descris nivel mediu reprezentare model corporativ pentru un fragment din tematica „Comanda”.

Din fig. 16.3 se poate observa că domeniul „Comanda” ( 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 făcut comanda, cine a trimis comanda, cine primește comanda și o serie de altele. Din diagrama de mai sus, se poate observa că în această organizație există două tipuri de comenzi - comenzi pentru promotii (Comercială) și comenzi cu amănuntul ( Cu amănuntul).

observa asta model de date de întreprindere poate reprezenta diverse aspecte ale activităților organizației ș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 punct de vedere al designului HD factor importantîn decizia de a crea un model de CD din model de date corporative este statul completitudine model de date corporative.

Model de date de întreprindere organizaţia are caracteristica evolutivă, adică. se dezvoltă și se îmbunătățește constant. Unele domenii tematice model de date corporative poate fi bine dezvoltat, pentru unii lucrul poate să nu fi început încă. Dacă un fragment din domeniul subiectului nu a fost elaborat în model de date corporative, atunci nu există nicio modalitate de a utiliza acest model ca punct de plecare pentru proiectarea CD-ului.

Gradul de absolvire model corporativ poate fi nivelat în designul CD-ului după cum urmează. Deoarece procesul de dezvoltare HD este de obicei împărțit în timp într-o secvență 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 stratul de prezentare al modelului de date corporative informații despre caracteristicile fizice ale obiectelor bazei de date corespunzătoare model de date logic mijloc stratul de prezentare al modelului de date corporative.

Articolul descrie principalele arhitecturi ale depozitelor de date, consideră unii principii generale construcția lor. Metodele de reprezentare a ierarhiilor într-o structură de date relaționale sunt descrise în detaliu.

Introducere

La începutul anilor optzeci ai secolului trecut, în perioada de dezvoltare rapidă a înregistrării sisteme de informare, a existat o înțelegere a posibilităților limitate de aplicare a acestora în scopul analizei datelor și construirea pe baza sistemelor lor de sprijin și de luare a deciziilor. Au fost create sisteme de înregistrare pentru automatizare operațiuni de rutină privind desfășurarea afacerilor - facturarea, întocmirea contractelor, verificarea stării depozitului etc., iar principalii utilizatori ai unor astfel de sisteme erau personalul de linie. Principalele cerințe pentru astfel de sisteme au fost să asigure caracterul tranzacțional al modificărilor și să maximizeze viteza de execuție a acestora. Aceste cerințe au determinat alegerea SGBD relațional și modelul de prezentare a datelor entitate-relație ca principalele utilizate. solutii tehnice la construirea sistemelor de înregistrare.

Pentru manageri și analiști, la rândul lor, erau necesare sisteme care să permită:

Evident, sistemele de înregistrare nu au îndeplinit niciuna dintre cerințele de mai sus. In sistemul de inregistrare informatia este relevanta doar in momentul accesarii bazei de date, in momentul urmator pentru aceeasi solicitare se poate obtine un cu totul alt rezultat. Interfața sistemelor de înregistrare este concepută pentru a efectua operațiuni rigid definite și posibilitatea de a obține rezultate pentru o solicitare ad-hoc este foarte limitată. Capacitatea de a procesa cantități mari de date este, de asemenea, scăzută din cauza reglajului DBMS pentru a efectua tranzacții scurte și încetinirii inevitabile în activitatea altor utilizatori.

Răspunsul la această nevoie a fost apariția tehnologie nouă organizarea bazei de date - tehnologie de depozit de date.

Definiție și arhitecturi tipice HD

Conceptul de depozit de date se bazează pe două idei principale - integrarea datelor detaliate dezagregate (detaliate în sensul că descriu unele fapte specifice, proprietăți, evenimente etc.) într-o singură stocare și separarea seturilor de date și a aplicațiilor utilizate. pentru prelucrare operaţională şi utilizată pentru rezolvarea problemelor de analiză. Definiția conceptului " depozit de date„a fost prezentată pentru prima dată de William G. Inmon în monografia sa. În aceasta, el a definit depozitul de date ca „un set de date istorice, integrate, orientate pe subiecte, nedistructibile, concepute pentru a sprijini deciziile de management”.

Conceptual, modelul de depozit de date poate fi reprezentat sub forma diagramei prezentate în Figura 1. Datele din diverse surse sunt plasate în CD, iar descrierile acestor date sunt plasate în depozitul de metadate. Utilizatorul final, folosind diverse instrumente (vizualizare, raportare, prelucrare statistică etc.) și conținutul depozitului, analizează datele din depozit. Rezultatul activității sale este informații sub formă de rapoarte gata făcute, modele ascunse găsite, orice predicții. Din moment ce mijloacele de muncă Utilizator final Deoarece depozitul de date poate fi foarte divers, teoretic alegerea lor nu ar trebui să îi afecteze structura și funcțiile de menținere la zi.

Implementarea fizică a schemei conceptuale date poate fi foarte diversă. Cele mai comune abordări sunt enumerate mai jos.

Stocare virtuală a datelor Este un sistem care reprezintă interfețe și metode de acces la sistemul de înregistrare care emulează lucrul cu datele din acest sistem, ca și în cazul unui depozit de date. Un depozit de date virtual poate fi organizat prin crearea unei serii de vederi în baza de date sau prin utilizarea mijloace speciale accesați, de exemplu, produse din clasa Desktop OLAP, care includ, de exemplu, BusinessObjects, Brio Enterprise și altele.

Principalele avantaje ale acestei abordări sunt:

Cu toate acestea, are mult mai multe dezavantaje decât avantaje. Prin crearea stocare virtuală date, nu creați o stocare ca atare, ci iluzia existenței sale. Structura de stocare a datelor și stocarea datelor în sine nu suferă modificări, iar problemele rămân:

	Performanţă;
	Transformări de date;
	Integrarea datelor cu alte surse;
	Lipsa de istorie;
	Puritatea datelor;
	Dependența de disponibilitatea bazei de date principale;
	Dependența de structura bazei de date principale.

Arhitectură cu două niveluri depozitul de date presupune construirea unui data mart fără a crea o stocare centrală, în timp ce informația provine dintr-un număr mic de sisteme de înregistrare și este limitată la un anumit domeniu. Atunci când se construiesc magazine de date, se folosesc principiile de bază ale construirii depozitelor de date, despre care va fi un discurs de mai jos, astfel încât acestea pot fi considerate ca depozite de date în miniatură. Avantajele data mart-urilor sunt:

Construirea unui depozit de date corporative cu drepturi depline se face de obicei în arhitectura pe trei niveluri(De remarcat că aici arhitectura pe trei niveluri nu înseamnă structura „DB - Application Server - Client”). La primul nivel sunt localizate diverse surse de date - sisteme interne de înregistrare, sisteme de ajutor, surse externe (date agentii de stiri, indicatori macroeconomici). Al doilea nivel conține depozitul central de date, de unde provin informații din toate sursele primul nivelși, eventual, un depozit de date operațional (OSD). Depozitul operațional nu conține date istorice și îndeplinește două funcții principale. În primul rând, este o sursă de informații analitice pentru managementul operațional și, în al doilea rând, datele sunt pregătite aici pentru încărcare ulterioară într-un depozit central. Pregătirea datelor este înțeleasă ca transformarea lor și implementarea anumitor verificări. Prezența unui OSD este pur și simplu necesară cu reglementări diferite pentru primirea informațiilor din surse. Al treilea nivel din arhitectura descrisă este un set de magazine de date specifice domeniului, sursa de informații pentru care este depozitul central de date. Majoritatea utilizatorilor finali lucrează cu platformele de date.

Proiectarea structurii unui depozit de date relaționale

HD sunt construite pe baza unui model de date multidimensional. Un model de date multidimensional presupune selectarea unor dimensiuni separate (timp, geografie, client, cont) și fapte (volum vânzări, venituri, cantitate de mărfuri), care sunt analizate în funcție de dimensiunile selectate. Un model de date multidimensional poate fi implementat fizic atât în ​​SGBD multidimensional, cât și în cele relaționale. V acest din urmă caz se realizează după modelul „stea” sau „fulg de zăpadă”. Aceste scheme presupun alocarea tabelelor de fapte și a tabelelor de dimensiuni. Fiecare tabel de fapte conține date detaliate și chei externe pentru tabelele de dimensiuni. Teoria construirii unui model de date multidimensionale și implementarea lui într-o structură relațională este acoperită pe larg atât în ​​literatura străină, cât și în cea locală.

Printre subiectele slab acoperite se numără problema reprezentării ierarhiilor. Ca exemplu de măsurare care este utilizată pe scară largă în analiza unei întreprinderi și are o structură ierarhică, putem cita un director de articole de cost. Luați în considerare modelul centrului de cost (centrul de cost) prezentat în Figura 2.

Informatica clasica rezolva problema reprezentarii ierarhiilor folosind comunicarea recursiva. Această soluție simplă vă permite să plasați un copac de orice adâncime și dimensiune într-un singur tabel. În cazul nostru, datele luate în considerare vor fi prezentate în următoarea formă:

ID de părinte 1 Companie 2 Control 3 Infrastructură 4 Productie 5 6 Serviciu 7 Câmpul A 8 Câmpul B

Tabelul 1.

Cu toate acestea, principalul său dezavantaj este ascuns în simplitatea acestei soluții. Din păcate, SQL standard nu acceptă pointeri recursivi, așa că sunt folosite alte metode pentru a reprezenta arbori în HD.

Metoda propusă de Joe Celko se bazează pe teoria mulțimilor. În această metodă, toate nodurile arborelui sunt parcurse într-o ordine de traversare directă și pentru fiecare nod sunt completate două valori - marginile din stânga și din dreapta, iar pentru fiecare nod al ramurilor arborelui, marginea din stânga este completată primul și numai apoi dreapta – la trecerea înapoi de la descendenți la părinți. Deci, în exemplul nostru, numerotarea nodurilor va fi după cum urmează:

Cu această numerotare a nodurilor, fiecare părinte conține copii, ale căror margini din stânga și din dreapta se află în intervalul dintre marginile din stânga și din dreapta ale părintelui. La fel, toți părinții unui copil au marginea stângă care este mai mică decât marginea stângă a copilului și cea dreaptă care este mai mare decât marginea dreaptă a copilului. Prin urmare, suma costurilor pentru un anumit centru de cost și toate componentele acestuia poate fi obținută cu o singură solicitare. De exemplu, pentru a obține costurile de infrastructură, puteți rula următoarea interogare SQL:

selectați suma (fact_table.cost)
din tabel_fact, tabel_dimensiuni D1, tabel_dimensiuni D2
unde fact_table.dimension_id = D2.id
iar D2.stânga> = D1.stânga
iar D2.dreapta<= D1.right
și D1.name = „Infrastructură”

Pentru ușurința de a lucra cu o astfel de referință, pe lângă câmpurile din stânga și din dreapta, adăugați încă două câmpuri: „Level” - nivelul unui nod din arbore, „Is_leaf” - un steag care arată dacă un nod este o frunză în copacul sau nu. Astfel, obținem un tabel „dimension_table” (vezi tabelul 2), care vă permite să stocați un arbore de orice adâncime și dimensiune de imbricare și vă permite să selectați copiii și părinții cu o singură interogare.

1 Companie 2 Control 3 Infrastructură 4 Productie 5 6 Serviciu 7 Câmpul A 8 Câmpul B

Tabelul 2. Reprezentarea ierarhiilor folosind marginile din stânga și din dreapta

O altă modalitate, descrisă de Ralph Kimball, se bazează pe introducerea unui tabel de ajutor prin care tabelul de fapte este legat de tabelul de dimensiuni. Acest tabel auxiliar reflectă structura ierarhică a dimensiunii și respectă următoarea lege: tabelul auxiliar conține întregul set de perechi părinte-copil, iar copilul poate să nu fie un copil imediat al părintelui. Structura unui astfel de tabel și conținutul acestuia sunt prezentate în Tabelul 3.

ID de părinte ID copilului Distanţă 1 1 1 1 1 1 1 1 2 2 0 Y 3 3 0 N 3 5 1 N 3 6 1 N 4 4 0 N 4 7 1 N 4 8 1 N 5 5 0 Y 6 6 0 Y 7 7 0 Y 8 8 0 Y

Tabelul 3. Structura și conținutul tabelului auxiliar.

Acum, legând tabelul de fapte (vezi Figura 4) cu ID-ul copilului din tabelul auxiliar și tabelul de dimensiuni cu ID-ul părinte, putem calcula suma costurilor pentru fiecare centru de cost și toate părțile sale constitutive cu o singură interogare. , ca în cazul precedent. În același timp, adăugând constrângeri la câmpurile „Distanță” și „Este frunză”, putem calcula cu ușurință costurile pentru orice nivel din ierarhie.

selectați suma (fact_table.cost)
din fact_table, dimension_table, helper_table
unde fact_table.dimension_id = helper_table.child_id
și dimension_table.dimension_id = helper_table.parent_id
și dimension_table.name = „Infrastructură”
și helper_table.distanță = 1

Problema proiectării referințelor ierarhice este și mai complicată atunci când o dimensiune poate avea mai multe ierarhii alternative și devine destul de dificil de rezolvat atunci când este necesară menținerea istoricului modificărilor în tabelul de dimensiuni.

În general, problema dimensiunilor în schimbare lent este interesantă în sine, fără a o complica cu ierarhia clasificatorilor. În literatura de specialitate, este în majoritatea cazurilor considerată în contextul „faptului – dimensiunea care se schimbă încet”. Într-adevăr, această sarcină poate fi rezolvată relativ simplu adăugând data de început și data de expirare a înregistrării la tabelul de dimensiuni. Modificarea unei intrări în director duce la „închiderea” vechii înregistrări și adăugarea uneia noi. Acum, revenind la exemplul referinței elementului rând, utilizatorul care dorește să obțină informații despre elementul rând curent pentru orice dată specifică trebuie să le includă în condiția de interogare SQL.

Să presupunem că o referință de articol rând este legată de o referință de cont contabil. Unul sau mai multe conturi contabile reprezintă un element de cost. Cum ar trebui să se reflecte o modificare a oricărui atribut al unui articol rând în cartea de referință a conturilor contabile? Pe de o parte, din punctul de vedere al planului de conturi, modificarea atributului nu modifică entitatea articolului rând, iar înregistrările contabile prin planul de conturi trebuie să se refere la același articol rând. Pe de altă parte, a apărut o nouă intrare în directorul elementelor rând, care trebuie să fie legată într-un fel la directorul contului. Această problemă poate fi rezolvată prin împărțirea tabelului de dimensiuni în două - care conține informații actualizate și care conține istoricul modificărilor entității. Această abordare vă permite, de asemenea, să rezolvați problema unei dimensiuni ierarhice cu necesitatea de a menține istoricul modificărilor în înregistrările din ea.

Să o luăm în considerare mai detaliat (vezi Fig. 5). Tabelul „dimension_actual” este un tabel de dimensiuni cu o cheie primară dimension_id care conține atributele corecte pentru dimensiunea actuală. Tabelul istoric „dimension_history” este conectat la acesta prin cheia externă dimension_id, care conține istoricul modificărilor înregistrărilor determinate de datele de început / sfârșit ale valabilității înregistrării (câmpurile date_start, date_end). Înregistrarea care este actualizată este prezentă și în ea cu o dată de expirare deschisă. Fact_table este legat de tabelul de dimensiuni prin helper_table, care reflectă structura ierarhica măsurători.

Abordarea descrisă permite: în primul rând, să stocați și să lucrați cu dimensiunea ca la un arbore dezechilibrat; în al doilea rând, executați rapid interogări pentru care istoricul modificării dimensiunii nu este important (tabelul care conține istoricul nu este implicat); în al treilea rând, vă permite să urmăriți istoricul modificărilor din dimensiune și, în cele din urmă, separă reflectarea istoriei și ierarhiei, ceea ce simplifică foarte mult întreținerea dimensiunii.

Al treilea punct important cu care trebuie să se ocupe adesea un dezvoltator de depozite este legat de valorile agregate. Această clasă de sarcini poate fi împărțită condiționat în două subclase. Primul ia în considerare sarcinile de creare și menținere a agregatelor în funcție de datele detaliate disponibile și este acoperit pe larg în literatura de specialitate. Al doilea este legat de faptul că sursele de date pentru depozit nu oferă valori detaliate, ci deja un anumit set de date agregate. Această situație este tipică atunci când se creează depozite de date pentru companiile de management și agențiile guvernamentale de reglementare, care colectează multe formulare de raportare.

Un caz extrem al acestei abordări este un model care poate fi numit convențional „valoare-indicator”. Esența sa constă în faptul că se colectează un set mare de indicatori care caracterizează activitățile financiare și economice ale întreprinderii. Acești indicatori pot fi fie legați funcțional, fie nu, pot reflecta aceleași valori, dar cu un grad diferit de detaliere etc. Când încearcă să reprezinte astfel de date sub forma unui model multidimensional, dezvoltatorul întâmpină probleme semnificative și de foarte multe ori urmează calea creării nu a unui depozit de date, ci a unui depozit de formulare. O stocare tipică a formularelor este construită pe baza a trei dimensiuni - indicatori economici, timp, formulare de raportare; tabele de fapte - valorile indicatorilor economici și tabele auxiliare care descriu modul în care indicatorii și valorile acestora sunt localizați în formularele de raportare. Atunci când analizează astfel de date, analistul va întâmpina dificultăți semnificative, în principal din cauza faptului că indicatorii de diferite forme nu pot fi comparați între ei. Singurul lucru care îi rămâne este să urmărească modificările indicatorilor unei forme în timp.

Concluzie

La implementarea proiectelor pentru construirea de depozite de date, apar o serie de sarcini comune care nu depind de domeniul de subiect al informațiilor care sunt prelucrate. Aceste sarcini includ:

Acest articol a discutat posibile soluții la aceste probleme. În special, metodele de implementare a dimensiunilor ierarhice au fost date prin introducerea de atribute suplimentare (chenarele din stânga și din dreapta), precum și prin introducerea unui tabel suplimentar - „helper-table”. Cu toate acestea, în toate problemele luate în considerare, există probleme nerezolvate care necesită cercetări suplimentare. În special, este dificil de implementat cazul măsurătorilor ierarhice cu necesitatea de a menține un istoric al modificărilor care au legături cu alte directoare. Acest articol nu include întrebări legate de metodele de curățare a datelor și algoritmii de încărcare a datelor în stocare. Aceste subiecte necesită o analiză separată.

LITERATURĂ

1.	Joerg Reinschmidt, Allison Francoise. Ghid de certificare Business Intelligence. Cărți roșii IBM;
2.	Inmon W. Construirea depozitului de date. - New York: John Willey & Sons, 1992;
3.	Spirley, Eric. Depozite de date corporative. Planificare, dezvoltare, implementare. Volum. 1: Per. din engleza - M .: Editura „Williams”, 2001;
4.	Joe Celko. Trees in SQL: Intelligent Enterprise, 20 octombrie 2000;
5.	Donald E. Knuth. Arta programarii, volumul 1. Algoritmi de baza, ed. a III-a: - M.: Editura „Williams”, 2000 .;
6.	Ralph Kimball. Ajutor pentru ierarhii: DBMS septembrie 1998;
7.	Ralph Kimball. Dimensiuni care se schimbă încet: DBMS aprilie 1996;
8.	Dicţionar statistic: M. „Finanţe şi statistică”, 1989;
9.	Duke V, Samoilenko A, Data mining: un curs de formare. - SPb: Peter, 2001;
10.	Erhard Rahm, Hong Hai Do: Curățarea datelor: probleme și abordări actuale. IEEE Data Engineering Bulletin 23 (4): 3-13 (2000);
11.	Ralph Kimball: Setul de instrumente pentru depozitul de date: tehnici practice pentru construirea de depozite de date dimensionale. John Wiley 1996;
12.	Maria Sueli Almeida, Missao Ishikawa, Joerg Reinschmidt, Torsten Roeber, Noțiuni introductive cu Data Warehouse și Business Intelligence. Cărți roșii IBM;
13.	Nigel Pendse, Arhitecturi OLAP: Raportul OLAP, http://www.olapreport.com/Architectures.htm#top.

Se pare că acum subiectul dezvoltării depozitelor de date a alunecat într-o nouă etapă de dezvoltare. Apar noi tehnologii, abordări și instrumente. Studiul, testarea și aplicarea lor inteligentă 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 sunt utile.

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ă ea inevitabil „a luat subiectul un pic mai larg” – iar alte categorii de cititori au căzut în câmpul vizual. Unele puncte vor părea controversate, altele nu sunt clare, altele sunt evidente. Oamenii sunt diferiți - cu medii, medii și poziții diferite.
De exemplu, întrebările tipice manageriale sunt „când să angajezi arhitecți?”, „Când să faci arhitectură?” sunet pentru noi (dezvoltatori, designeri) destul de ciudat, pentru că pentru noi arhitectura sistemului apare odată cu nașterea lui - nu contează dacă suntem conștienți sau nu de el. Și chiar dacă nu există un rol formal al unui arhitect într-un proiect, un dezvoltator normal „întotdeauna își include propriul arhitect intern”.

În general, nu contează cine îndeplinește exact rolul arhitectului - este important ca cineva să pună întrebări similare și să investigheze răspunsurile. Dacă arhitectul este clar evidențiat, 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?

„Unicitatea antifragilității este că ne permite să lucrăm cu necunoscutul, să facem ceva în condiții în care nu înțelegem exact ce facem și să obținem succesul.”/ Nassim N. Talb /

Prin urmare, criza și un grad ridicat de incertitudine nu sunt o scuză în favoarea absenței arhitecturii, ci factori care întăresc nevoia acesteia.

Etichete:

• arhitectură
• depozit de date

Adaugă etichete