Duket se tani tema e zhvillimit të depove të të dhënave ka rrëshqitur raundi i ri zhvillimin. Teknologjitë, qasjet dhe mjetet e reja po shfaqen. Studimi, miratimi dhe zbatimi i arsyeshëm i tyre na lejon të krijojmë vërtet interesante dhe zgjidhje të dobishme. Dhe sillni ato në zbatim, duke shijuar faktin që zhvillimet tuaja përdoren në punë e vërtetë dhe përfitojnë.

Epilogu

Në përgatitjen e këtij artikulli, u përpoqa të fokusohesha kryesisht tek arkitektët, analistët dhe zhvilluesit që punojnë drejtpërdrejt me depot e të dhënave. Por doli që në mënyrë të pashmangshme "e mora temën pak më gjerë" - dhe kategoritë e tjera të lexuesve ranë në fushën e vizionit. Disa pika do të duken të diskutueshme, disa nuk janë të qarta, disa janë të dukshme. Njerëzit janë të ndryshëm - me përvoja, prejardhje dhe pozicione të ndryshme.
Për shembull, pyetjet tipike të menaxherëve janë "kur të tërheqim arkitektë?", "Kur duhet të bëj arkitekturë?", "Arkitektura - a nuk do të jetë shumë e shtrenjtë?" tingëllon mjaft e çuditshme për ne (zhvilluesit, projektuesit), sepse për ne arkitektura e sistemit shfaqet me lindjen e tij - nuk ka rëndësi nëse e kuptojmë apo jo. Dhe edhe nëse nuk ka asnjë rol zyrtar të një arkitekti në projekt, një zhvillues normal gjithmonë "ndiz arkitektin e tij të brendshëm".

Nga punë e madhe Nuk ka rëndësi kush është arkitekti, ajo që ka rëndësi është që dikush t'i bëjë këto pyetje dhe të hulumtojë përgjigjet. Nëse arkitekti veçohet qartë, kjo do të thotë vetëm se ai është përgjegjës kryesor për sistemin dhe zhvillimin e tij.
Pse tema e "antifragjilitetit" më dukej e rëndësishme në lidhje me këtë temë?

“E veçanta e antifragjilitetit është se na lejon të punojmë me të panjohurën, të bëjmë diçka në kushte ku nuk kuptojmë se çfarë po bëjmë saktësisht – dhe të kemi sukses”./Nassim N.Taleb/

Prandaj, kriza dhe shkalla e lartë e pasigurisë nuk janë justifikim për mungesën e arkitekturës, por faktorë që përforcojnë nevojën e saj.

Etiketa: Shtoni etiketa

Zaitsev S.L., Ph.D.

Grupe që përsëriten

Grupet përsëritëse janë atribute për të cilat një shembull i vetëm entiteti mund të ketë më shumë se një vlerë. Për shembull, një person mund të ketë më shumë se një aftësi. Nëse, për sa i përket kërkesave të biznesit, duhet të dimë nivelin e aftësive për të gjithë, dhe secili person mund të ketë vetëm dy aftësi, ne mund të krijojmë entitetin e paraqitur në Fig. 1.6. Këtu është entiteti NJË PERSON me dy atribute për të ruajtur aftësitë dhe nivelet e aftësive për secilin.

Oriz. 1.6. Ky shembull përdor grupe përsëritëse.

Problemi me përsëritjen e grupeve është se ne nuk mund të dimë saktësisht se sa aftësi mund të ketë një person. Në jetën reale, disa njerëz kanë një aftësi, disa kanë disa, dhe disa nuk kanë ende asnjë. Figura 1.7 tregon modelin e reduktuar në formën e parë normale. Vini re shtimin ID e aftësisë , e cila përcakton në mënyrë unike secilën AFTËSI.

Oriz. 1.7. Modeli i reduktuar në të parën formë normale.

Një fakt në një vend

Nëse i njëjti atribut është i pranishëm në më shumë se një entitet dhe nuk është një çelës i huaj, atëherë ai atribut konsiderohet i tepërt. Modeli logjik nuk duhet të përmbajë të dhëna të tepërta.

Teprica kërkon hapësirë ​​shtesë, por ndërsa efikasiteti i kujtesës është i rëndësishëm, problemi i vërtetë qëndron diku tjetër. Sinkronizimi i garantuar i të dhënave të tepërta vjen me një kosto të lartë dhe ju gjithmonë rrezikoni të konfliktoni vlerat.

Në shembullin e mëparshëm AFTËSI varet nga ID e personit dhe nga ID e aftësisë. Kjo do të thotë që ju nuk do të keni AFTËSI derisa të shfaqet NJË PERSON, duke pasur këtë aftësi. Gjithashtu e bën më të vështirë ndryshimin e emrit të aftësisë. Ju duhet të gjeni çdo hyrje të emrit të aftësisë dhe ta ndryshoni atë për çdo person që e zotëron atë aftësi.

Figura 1.8 tregon modelin në formën e dytë normale. Vini re se entiteti është shtuar AFTËSI, dhe atribut TITULLI aftësi të transferuara në këtë ent. Niveli i aftësive mbeti, përkatësisht, në kryqëzim PERSONAT dhe AFTËSITË.

Oriz. 1.8. Në formën e dytë normale, grupi përsëritës zhvendoset në një entitet tjetër. Kjo siguron fleksibilitetin për të shtuar sa më shumë aftësi që nevojiten dhe për të ndryshuar emrin e aftësisë ose përshkrimin e aftësive në një vend.

Çdo atribut varet nga një çelës

Çdo atribut i një entiteti duhet të varet nga çelësi primar i atij entiteti. Në shembullin e mëparshëm Emri i shkollës dhe Zona gjeografike të pranishme në tabelë NJË PERSON por mos përshkruani një person. Për të arritur formën e tretë normale, duhet të zhvendosni atributet në entitet, ku ato do të varen nga çelësi. Figura 1.9. tregon modelin në formën e tretë normale.

Oriz. 1.9. Në formën e tretë normale Emri i shkollës dhe Rajoni gjeografik zhvendosur në entitet, ku vlerat e tyre varen nga çelësi.

Marrëdhënie shumë-për-shumë

Marrëdhënia shumë-me-shumë pasqyrojnë realitetin e mjedisit. Vini re se në figurën 1.9 ekziston një lidhje shumë-me-shumë ndërmjet PERSON dhe SHKOLLA. Raporti pasqyron me saktësi faktin se NJË PERSON mund të studiojë në shumë SHKOLLAT dhe ne SHKOLLA mund të mësojë shumë PERSON. Për të arritur formën e katërt normale, krijohet një ent shoqërues që eliminon marrëdhënien monogie-to-shumë duke formuar hyrje e veçantë për çdo kombinim unik të shkollës dhe personit. Figura 1.10 tregon modelin në formën e katërt normale.

Oriz. 1.10. Në formën e katërt normale, lidhja monogie-to-shumë ndërmjet PERSON dhe SHKOLLA zgjidhet duke futur një entitet shoqërues, në të cilin caktohet një hyrje e veçantë për çdo kombinim unik SHKOLLAT dhe PERSONA.

Përkufizime formale të formave normale

Përkufizimet e mëposhtme të formave normale mund të duken frikësuese. Mendojini ato thjesht si formula për arritjen e normalizimit. Format normale bazohen në algjebër relacionale dhe mund të interpretohen si transformime matematikore. Edhe pse ky libër nuk mbulon një diskutim të detajuar të formave normale, modelistët inkurajohen të thellohen më thellë në këtë temë.

Në një relacion të caktuar R, atributi Y është funksionalisht i varur nga atributi X. Simbolikisht, RX -> RY (lexohet si "RX përcakton funksionalisht RY") nëse dhe vetëm nëse çdo vlerë X në R lidhet saktësisht me një vlerë Y në R ( në çdo kohë të caktuar). Atributet X dhe Y mund të jenë të përbëra (Date K.J. Introduction to Database Systems. 6th edition. Ed. Williams: 1999, 848 pp.).

Një lidhje R është në formën e parë normale (1NF) nëse dhe vetëm nëse të gjitha domenet e saj përmbajnë vetëm vlera atomike (Data, po aty).

Një lidhje R është në formën e dytë normale (2NF) nëse dhe vetëm nëse është në 1NF dhe çdo atribut jo kyç është plotësisht i varur nga çelësi primar (Data, po aty).

Një relacion R është në formën e tretë normale (3NF) nëse dhe vetëm nëse është në 2NF dhe çdo atribut jo kyç nuk varet në mënyrë kalimtare nga çelësi primar (Data, po aty).

Lidhja R është në formën normale Boyce-Codd (BCNF) nëse dhe vetëm nëse çdo përcaktues është kandidat për t'u përdorur si çelës.

SHËNIM Më poshtë është një shpjegim i shkurtër i disa prej shkurtimeve të përdorura në përkufizimet e Date.

MVD (varësi me shumë vlera) - varësi me shumë vlera. Përdoret vetëm për entitetet me tre ose më shumë atribute. Në një varësi me shumë vlera, vlera e një atributi varet vetëm nga një pjesë e çelësit primar.

FD (varësi funksionale) - varësi funksionale. Në një varësi funksionale, vlera e një atributi varet nga vlera e një atributi tjetër që nuk është pjesë e çelësit primar.

JD (varësia e bashkimit) - varësia e bashkimit. Në një varësi bashkimi, çelësi primar i njësisë ekonomike mëmë është i gjurmueshëm te të paktën pasardhësit e nivelit të tretë, ndërkohë që ruan aftësinë për t'u përdorur në bashkimin e çelësit origjinal.

Një lidhje është në formën e katërt normale (4NF) nëse dhe vetëm nëse ka një MVD në R, si A®®B. Në këtë rast, të gjitha atributet e R janë funksionalisht të varura nga A. Me fjalë të tjera, vetëm varësitë (FD ose MVD) të formës K®X janë të pranishme në R (d.m.th., varësia funksionale e atributit X nga kandidati për përdorim si një çelës K). Prandaj, R plotëson kërkesat e 4NF nëse përputhet me BCNF dhe të gjitha MVD-të janë në fakt FD (Data, po aty).

Për formën e pestë normale, relacioni R plotëson relacionin e bashkimit (JD)*(X, Y, …, Z) nëse dhe vetëm nëse R është ekuivalent me projeksionet e tij në X, Y,..., Z, ku X, Y,. .., Z nënbashkësi të grupit të atributeve R.

Ka shumë forma të tjera normale për lloje komplekse të dhënash dhe situata specifike që janë përtej qëllimit të diskutimit tonë. Çdo entuziast i zhvillimit të modelit do të donte të eksploronte forma të tjera normale.

Format Normale të Biznesit

Në librin e tij Clive Finklestein (Finklestein Cl. An Introduction to Information Engineering: From Strategic Planning to Information Systems. Reading, Massachusetts: Addison-Wesley, 1989) mori një qasje të ndryshme ndaj normalizimit. Ai përcakton format normale të biznesit në terma të reduktimeve në ato forma. Shumë modelues e shohin këtë qasje si më intuitive dhe pragmatike.

Forma e Parë Normale e Biznesit (1BNF) paraqet hartat e grupeve të përsëritura në një njësi tjetër. Ky ent merr emrin e vet dhe atributet kryesore (të përbëra) kryesore nga entiteti origjinal dhe grupi i tij përsëritës.

Forma e dytë normale e biznesit (2BNF) harton atributet që varen pjesërisht nga një çelës primar për një njësi tjetër. Çelësi primar (i përbërë) i këtij entiteti është çelësi kryesor i njësisë ekonomike në të cilën ai ka banuar fillimisht, së bashku me çelësat shtesë, nga i cili atributi është plotësisht i varur.

Forma e tretë normale e biznesit (3BNF) zhvendos atributet që nuk varen nga çelësi primar në një njësi tjetër, ku varen plotësisht nga çelësi primar i këtij entiteti.

Forma e Katërt Normale e Biznesit (4BNF) harton atributet që varen nga vlera e çelësit primar ose janë opsionale për një njësi dytësore, ku varen tërësisht nga vlera e çelësit primar, ose ku duhet (të detyrueshme) të jenë të pranishme në atë entitet .

Forma e Pestë Normale e Biznesit (5BNF) shfaqet si një entitet strukturor nëse ka një varësi rekursive ose një varësi tjetër midis shembujve të një njësie ekonomike dytësore, ose nëse ekziston një varësi rekursive midis shembujve të njësisë së tij parësore.

Modeli i plotësuar i të dhënave logjike

Modeli logjik i plotësuar duhet të plotësojë kërkesat e formës së tretë normale të biznesit dhe të përfshijë të gjitha entitetet, atributet dhe marrëdhëniet e nevojshme për të mbështetur kërkesat e të dhënave dhe rregullat e biznesit që lidhen me të dhënat.

Të gjitha subjektet duhet të kenë emra që përshkruajnë përmbajtjen dhe një të qartë, konciz, Përshkrimi i plotë ose përkufizim. Në një nga publikimet e mëposhtme, do të shqyrtohet një grup fillestar rekomandimesh për formimin e saktë të emrave dhe përshkrimeve të subjekteve.

Subjektet duhet të kenë një grup të plotë atributesh, në mënyrë që çdo fakt për çdo entitet të mund të përfaqësohet nga atributet e tij. Çdo atribut duhet të ketë një emër që pasqyron vlerën e tij, tip boolean të dhëna dhe një përshkrim ose përkufizim të qartë, të shkurtër, të plotë. Në një nga botimet e mëposhtme, ne do të shqyrtojmë grupin fillestar të rekomandimeve për formimin e saktë të emrave dhe përshkrimet e atributeve.

Marrëdhëniet duhet të përfshijnë një ndërtim foljesh që përshkruan marrëdhënien midis entiteteve, së bashku me karakteristika të tilla si shumësia, nevoja për ekzistencë ose mundësia e mosekzistencës së marrëdhënies.

SHËNIM Pluraliteti komunikimi përshkruan numri maksimal raste të një entiteti dytësor që mund të shoqërohet me një shembull të njësisë ekonomike origjinale.Nevoja për ekzistencë osemundësia e mungesës marrëdhënia përdoret për të përcaktuar numrin minimal të rasteve të një entiteti dytësor që mund të shoqërohet me një shembull të entitetit origjinal.

Modeli i të dhënave fizike

Pas krijimit të një të plotë dhe adekuate modeli logjik ju jeni gati të merrni një vendim për zgjedhjen e platformës së zbatimit. Zgjedhja e platformës varet nga kërkesat për përdorimin e të dhënave dhe nga parimet strategjike të arkitekturës së organizatës. Zgjedhja e platformës është një çështje komplekse që është përtej qëllimit të këtij libri.

Në ERwin, modeli fizik është një paraqitje grafike e bazës së të dhënave aktuale. Baza e të dhënave fizike do të përbëhet nga tabela, kolona dhe marrëdhënie. Modeli fizik varet nga platforma e zgjedhur për zbatim dhe kërkesat e përdorimit të të dhënave. Modeli fizik për IMS do të jetë shumë i ndryshëm nga i njëjti model për Sybase. Modeli fizik për raportet OLAP do të duket i ndryshëm nga modeli për OLTP (Përpunimi i transaksioneve në internet).

Modeluesi i të dhënave dhe administratori i bazës së të dhënave (DBA) përdorin modelin logjik, kërkesat e përdorimit dhe parimet strategjike të arkitekturës së korporatës për të zhvilluar modeli fizik të dhëna. Mund ta çnormalizoni modelin e fizikës për të përmirësuar performancën dhe për të krijuar pamje për të mbështetur kërkesat e përdorimit. Seksionet e mëposhtme detajojnë procesin e denormalizimit dhe krijimit të pamjes.

Ky seksion ofron një pasqyrë të procesit të ndërtimit të një modeli fizik, mbledhjes së kërkesave për përdorimin e të dhënave, përcaktimit të komponentëve të një modeli fizik dhe inxhinierisë së kundërt. Këto çështje do të trajtohen më në detaje në botimet e ardhshme.

Mbledhja e kërkesave për përdorimin e të dhënave

Në mënyrë tipike, ju mbledhni kërkesat e përdorimit të të dhënave herët gjatë intervistave dhe seancave të punës. Në të njëjtën kohë, kërkesat duhet të përcaktojnë përdorimin e të dhënave nga përdoruesi sa më plotësisht të jetë e mundur. Qëndrimi sipërfaqësor dhe boshllëqet në modelin fizik mund të çojnë në kosto të paplanifikuara dhe të vonojnë projektin. Kërkesat e përdorimit përfshijnë:

Kërkesat për akses dhe performancë

Karakteristikat vëllimore (një vlerësim i sasisë së të dhënave që do të ruhen), të cilat lejojnë administratorin të përfaqësojë vëllimin fizik të bazës së të dhënave

Një përllogaritje e numrit të përdoruesve që duhet të kenë qasje në të dhëna në të njëjtën kohë, gjë që ju ndihmon të dizajnoni bazën tuaj të të dhënave për një nivel të pranueshëm të performancës

Përmbledhje, përmbledhje dhe të dhëna të tjera të llogaritura ose të nxjerra që mund të konsiderohen si kandidatë për ruajtje në struktura të qëndrueshme të të dhënave

Kërkesat për gjenerimin e raporteve dhe pyetjeve standarde për të ndihmuar administratorin e bazës së të dhënave të ndërtojë indekse

Pamje (të përhershme ose virtuale) që do të ndihmojnë përdoruesin në kryerjen e operacioneve të bashkimit ose filtrimit të të dhënave.

Përveç kryetarit, sekretarit dhe përdoruesve, sesioni i kërkesave të përdorimit duhet të përfshijë modeluesin, administratorin e bazës së të dhënave dhe arkitektin e bazës së të dhënave. Kërkesat e përdoruesve për të dhënat historike duhet të diskutohen. Kohëzgjatja e ruajtjes së të dhënave ka një ndikim të rëndësishëm në madhësinë e bazës së të dhënave. Shpesh, të dhënat e vjetra ruhen në formë të përmbledhur dhe të dhënat atomike arkivohen ose fshihen.

Përdoruesit duhet të sjellin me vete pyetje dhe raporte në seancë. Raportet duhet të përcaktohen rreptësisht dhe duhet të përfshijnë vlerat atomike të përdorura për çdo fushë përmbledhëse dhe përmbledhëse.

Komponentët e modelit të të dhënave fizike

Komponentët e modelit të të dhënave fizike janë tabelat, kolonat dhe marrëdhëniet. Subjektet në modelin logjik ka të ngjarë të bëhen tabela në modelin fizik. Atributet Boolean do të bëhen kolona. Marrëdhëniet logjike do të bëhen kufizime në integritetin e marrëdhënieve. Disa marrëdhënie logjike nuk mund të realizohen në fizik bazën e të dhënave.

inxhinieri e kundërt

Kur modeli logjik nuk është i disponueshëm, bëhet e nevojshme të rikrijohet modeli nga bazë ekzistuese të dhëna. Në ERwin, ky proces quhet inxhinieri e kundërt. Inxhinieria e kundërt mund të bëhet në disa mënyra. Modeluesi mund të eksplorojë strukturat e të dhënave në bazën e të dhënave dhe të rikrijojë tabelat në një mjedis modelimi vizual. Ju mund të importoni një gjuhë të përkufizimit të të dhënave (DDL) në një mjet që mbështet inxhinierinë e kundërt (p.sh. Erwin). Mjetet e avancuara si ERwin përfshijnë veçori që ju lejojnë të komunikoni nëpërmjet ODBC me një bazë të dhënash ekzistuese për të krijuar një model nga lexim i drejtpërdrejtë strukturat e të dhënave. Inxhinieria e kundërt duke përdorur ERwin do të diskutohet në detaje në një botim të ardhshëm.

Përdorimi i kufijve funksionalë të korporatës

Kur ndërton një model logjik, është e rëndësishme që modeluesi ta sigurojë këtë model i ri korrespondon modeli i korporatës. Përdorimi i kufijve funksionalë të korporatës nënkupton modelimin e të dhënave në termat e përdorur brenda një korporate. Mënyra se si përdoren të dhënat në një korporatë po ndryshon më shpejt se vetë të dhënat. Në çdo model logjik, të dhënat duhet të paraqiten në mënyrë holistike, pavarësisht nga fusha lëndore biznesin që ajo mbështet. Subjektet, atributet dhe marrëdhëniet duhet të përcaktojnë rregullat e biznesit në nivelin e korporatës.

SHËNIM Disa nga kolegët e mi i referohen këtyre kufijve funksionalë të korporatës si modelim në botën reale. Modelimi i botës reale inkurajon modeluesin të shikojë informacionin në lidhje me marrëdhëniet dhe marrëdhëniet e tij në jetën reale.

Përdorimi i kufijve funksionalë të korporatës për një model të dhënash të ndërtuar siç duhet ofron një kornizë për të mbështetur nevojat e informacionit të çdo numri procesesh dhe aplikacionesh, duke i mundësuar një korporate të shfrytëzojë në mënyrë më efektive një nga asetet e saj më të vlefshme, informacionin.

Çfarë është një model i të dhënave të ndërmarrjes?

Modeli i të dhënave të ndërmarrjes (EDM) përmban entitete, atribute dhe marrëdhënie që përfaqësojnë nevojat e informacionit të një korporate. EDM zakonisht ndahet në fusha lëndore, të cilat përfaqësojnë grupe subjektesh që lidhen me mbështetjen e nevojave specifike të biznesit. Disa fusha lëndore mund të mbulojnë funksione specifike biznesi si menaxhimi i kontratave, të tjera mund të grupojnë entitete që përshkruajnë produkte ose shërbime.

Çdo model logjik duhet të korrespondojë me një domen ekzistues të modelit të të dhënave të ndërmarrjes. Nëse modeli logjik nuk përputhet këtë kërkesë, atij duhet t'i shtohet një model që përcakton fushën e lëndës. Ky krahasim siguron që modeli i korporatës është përmirësuar ose rregulluar dhe të gjitha përpjekjet e modelimit logjik janë të koordinuara brenda korporatës.

EDM përfshin gjithashtu entitete specifike që përcaktojnë shtrirjen e vlerave për atributet kryesore. Këto subjekte nuk kanë prindër dhe përkufizohen si të pavarura. Njësitë e pavarura përdoren shpesh për të ruajtur integritetin e marrëdhënieve. Këto entitete identifikohen me disa emra të ndryshëm, të tillë si tabelat e kodeve, tabelat e lidhjeve, tabelat e tipeve ose tabelat e klasifikimit. Do të përdorim termin “objekt biznesi i korporatës”. Një objekt biznesi i ndërmarrjes është një ent që përmban një grup vlerash atributesh që janë të pavarura nga çdo entitet tjetër. Objektet e biznesit të ndërmarrjes brenda një korporate duhet të përdoren vazhdimisht.

Ndërtimi i një modeli të të dhënave të ndërmarrjes duke shkallëzuar

Ka organizata ku modeli i korporatës nga fillimi në fund është ndërtuar si rezultat i një përpjekjeje të përbashkët të përbashkët. Nga ana tjetër, shumica e organizatave ndërtojnë modele mjaft të plota të ndërmarrjes duke ndërtuar.

Rritje do të thotë të ndërtosh diçka, shtresë pas shtrese, ashtu si një perle rrit një perlë. Çdo model i krijuar i të dhënave siguron të dhëna për formimin e EDM. Ndërtimi i një EDM në këtë mënyrë kërkon hapa shtesë modelimi për të shtuar struktura dhe domene të reja të dhënash ose për të zgjeruar strukturat ekzistuese të të dhënave. Kjo bën të mundur ndërtimin e një modeli të të dhënave të ndërmarrjes duke ndërtuar, duke shtuar në mënyrë të përsëritur nivele detajesh dhe përsosjeje.

Koncepti i metodologjisë së modelimit

Ekzistojnë disa metodologji për modelimin e të dhënave vizuale. ERwin mbështet dy:

IDEF1X (Përkufizimi i Integrimit për informacion Modelimi - një përshkrim i integruar i modeleve të informacionit).

IE (Information Engineering – Information Engineering).

IDEF1X është një metodologji e mirë dhe shënimi i saj përdoret gjerësisht

Përshkrimi i integruar i modeleve të informacionit

IDEF1X është një metodologji shumë e strukturuar e modelimit të të dhënave që zgjeron metodologjinë IDEF1 të miratuar si standard FIPS (Standardet Federale të Përpunimit të Informacionit). IDEF1X përdor një grup shumë të strukturuar të llojeve të konstruksionit të modelimit dhe rezulton në një model të dhënash që kërkon një kuptim të natyrës fizike të të dhënave përpara se një informacion i tillë të vihet në dispozicion.

Struktura e ngurtë e IDEF1X e detyron modeluesin t'u caktojë karakteristika entiteteve që mund të mos korrespondojnë me realitetet e botës përreth tyre. Për shembull, IDEF1X kërkon që të gjitha nëntipet e entiteteve të jenë ekskluzive. Kjo çon në faktin se një person nuk mund të jetë njëkohësisht klient dhe punonjës. Ndërsa praktika reale na thotë të kundërtën.

Inxhinieri informacioni

Clive Finklestein shpesh përmendet si babai i inxhinierisë së informacionit, megjithëse James Martin ndante koncepte të ngjashme me të (Martin, James. Managing the Database Environment. Upper Saddle River, New Jersey: Prentice Hall, 1983.). Inxhinieria e informacionit përdor një qasje të drejtuar nga biznesi për të menaxhuar informacionin dhe përdor një shënim tjetër për të përfaqësuar rregullat e biznesit. IE shërben si një zgjerim dhe zhvillim i shënimit dhe koncepteve bazë të metodologjisë ER të propozuar nga Peter Chen.

IE ofron infrastrukturën për të mbështetur kërkesat e informacionit duke integruar planifikimin strategjik të korporatës me sistemet e informacionit që po zhvillohen. Një integrim i tillë bën të mundur lidhjen më të ngushtë të menaxhimit të burimeve të informacionit me perspektivat strategjike afatgjata të korporatës. Kjo qasje e drejtuar nga biznesi bën që shumë modelues të zgjedhin IE mbi metodologjitë e tjera që kryesisht fokusohen në zgjidhjen e problemeve të menjëhershme të zhvillimit.

IE ofron një rrjedhë pune që e çon një korporatë të identifikojë të gjitha nevojat e saj për informacion për të mbledhur dhe menaxhuar të dhënat dhe për të identifikuar marrëdhëniet midis objekteve të informacionit. Si rezultat, kërkesat për informacion artikulohen bazuar në direktivat e menaxhimit dhe mund të përkthehen drejtpërdrejt në një sistem informacioni menaxherial që do të mbështesë nevojat strategjike të informacionit.

konkluzioni

Të kuptuarit se si të përdorni një mjet modelimi të të dhënave si ERwin është vetëm një pjesë e problemit. Përveç kësaj, duhet të kuptoni se kur kryhen detyrat e modelimit të të dhënave dhe si mblidhen kërkesat e informacionit dhe rregullat e biznesit për t'u përfaqësuar në modelin e të dhënave. Kryerja e seancave të punës ofron kushtet më të favorshme për mbledhjen e kërkesave të informacionit në një mjedis që përfshin ekspertë të çështjeve, përdorues dhe specialistë të teknologjisë së informacionit.

Ndërtimi i një modeli të mirë të dhënash kërkon analizën dhe hulumtimin e kërkesave të informacionit dhe rregullave të biznesit të mbledhura gjatë seancave të punës dhe intervistave. Modeli i të dhënave që rezulton duhet të krahasohet me modelin e ndërmarrjes, nëse është e mundur, për t'u siguruar që nuk bie ndesh me modelet ekzistuese të objekteve dhe përfshin të gjitha objektet e kërkuara.

Modeli i të dhënave përbëhet nga modele logjike dhe fizike që përfaqësojnë kërkesat e informacionit dhe rregullat e biznesit. Modeli logjik duhet të reduktohet në formën e tretë normale. Forma e tretë normale kufizon, shton, përditëson dhe heq anomalitë e strukturës së të dhënave për të mbështetur parimin "një fakt, një vend". Kërkesat e mbledhura të informacionit dhe rregullat e biznesit duhet të analizohen dhe hulumtohen. Ato duhet të krahasohen me modelin e ndërmarrjes për t'u siguruar që nuk bien ndesh me modelet ekzistuese të objekteve dhe që përfshijnë të gjitha objektet e kërkuara.

Në ERwin, modeli i të dhënave përfshin modele logjike dhe fizike. ERwin zbaton qasjen ER dhe ju lejon të krijoni objekte të modelit logjik dhe fizik për të përfaqësuar kërkesat e informacionit dhe rregullat e biznesit. Objektet e modelit logjik përfshijnë entitete, atribute dhe marrëdhënie. Objektet e modelit fizik përfshijnë tabela, kolona dhe kufizime të integritetit të marrëdhënieve.

Në një nga botimet e mëposhtme, do të shqyrtohen çështjet e identifikimit të subjekteve, përcaktimit të llojeve të subjekteve, zgjedhjes së emrave dhe përshkrimeve të subjekteve, si dhe disa truke për të shmangur gabimet më të zakonshme të modelimit që lidhen me përdorimin e entiteteve.

Subjektet duhet të kenë një grup të plotë atributesh, në mënyrë që çdo fakt për çdo entitet të mund të përfaqësohet nga atributet e tij. Çdo atribut duhet të ketë një emër që pasqyron vlerat e tij, një lloj të dhënash boolean dhe një përshkrim ose përkufizim të qartë, të shkurtër, të plotë. Në një nga botimet e mëposhtme, ne do të shqyrtojmë grupin fillestar të rekomandimeve për formimin e saktë të emrave dhe përshkrimet e atributeve. Marrëdhëniet duhet të përfshijnë një ndërtim foljesh që përshkruan marrëdhënien midis entiteteve, së bashku me karakteristika të tilla si shumësia, nevoja për ekzistencë ose mundësia e mosekzistencës së marrëdhënies.

SHËNIM Pluraliteti marrëdhëniet përshkruan numrin maksimal të rasteve të njësisë ekonomike dytësore që mund të shoqërohen me një shembull të entitetit origjinal.Domosdoshmëria e ekzistencës ose mundësia e mungesës marrëdhënia përdoret për të përcaktuar numrin minimal të rasteve të një entiteti dytësor që mund të shoqërohet me një shembull të origjinalit

Qëllimi i ligjëratës

Pasi të keni studiuar materialin e kësaj ligjërate, do të dini:

• cfare ndodhi modeli i të dhënave të ndërmarrjes ;
• si të konvertohet modeli i të dhënave të ndërmarrjes në modelin e magazinës së të dhënave;
• elementet thelbësore modeli i të dhënave të ndërmarrjes ;
• shtresat e prezantimit të modelit të të dhënave të korporatës ;
• algoritmi për konvertimin e një modeli të të dhënave të ndërmarrjes në një model shumëdimensional të depove të të dhënave ;

dhe mësoni:

• zhvillimi i modeleve të magazinës së të dhënave bazuar në modeli i të dhënave të ndërmarrjes organizatat;
• zhvilloni një skemë ylli duke përdorur mjetet CASE;
• tabelat e ndarjeve model shumëdimensional duke përdorur mjetet CASE.

Modeli i të dhënave të ndërmarrjes

Prezantimi

Thelbi i çdo magazine të dhënash është modeli i tij i të dhënave. Pa një model të dhënash, do të jetë shumë e vështirë të organizohen të dhënat në një depo të dhënash. Prandaj, zhvilluesit e DW duhet të shpenzojnë kohë dhe përpjekje për të zhvilluar një model të tillë. Zhvillimi i modelit HD bie mbi supet e projektuesit të CD-ve.

Krahasuar me projektimin e sistemeve OLTP, metodologjia për projektimin e një magazine të dhënash ka një numër të tipare dalluese lidhur me orientimin e strukturave të të dhënave të ruajtjes për të zgjidhur problemet e analizës dhe mbështetje informacioni procesi i vendimmarrjes. Modeli i të dhënave të magazinës së të dhënave duhet të ofrojë zgjidhje efektive pikërisht këto detyra.

Pika fillestare në projektimin e një magazine të dhënash mund të jetë e ashtuquajtura modeli i të dhënave të ndërmarrjes(modeli i të dhënave të korporatës ose modeli i të dhënave të ndërmarrjes, EDM), i cili krijohet në procesin e projektimit të sistemeve OLTP të një organizate. Gjatë projektimit modeli i të dhënave të ndërmarrjes zakonisht bëhet një përpjekje për të krijuar në bazë të operacioneve të biznesit një strukturë të tillë të dhënash që do të mblidhte dhe sintetizonte të gjitha nevojat për informacion të organizatës.

Në këtë mënyrë, modeli i të dhënave të ndërmarrjes përmban informacionin e nevojshëm për të ndërtuar një model HD. Prandaj, në fazën e parë, nëse një model i tillë ekziston në organizatë, një projektues i depove të të dhënave mund të fillojë të projektojë një magazinë të dhënash duke zgjidhur një problem transformimi modeli i të dhënave të ndërmarrjes në modelin HD.

Modeli i të dhënave të ndërmarrjes

Si të zgjidhni problemin e konvertimit modeli i të dhënave të ndërmarrjes në modelin HD? Për të zgjidhur këtë problem, duhet të keni këtë model, d.m.th. modeli i të dhënave të ndërmarrjes duhet të ndërtohet dhe të dokumentuara. Dhe ju duhet të kuptoni çfarë nga ky model dhe si duhet të transformohet në një model HD.

Le të sqarojmë konceptin modeli i të dhënave të ndërmarrjes. Nën modeli i të dhënave të korporatës të kuptojë përshkrimin në shumë nivele dhe të strukturuar të fushave lëndore të organizatës, strukturat e të dhënave të fushave lëndore, proceset e biznesit dhe procedurat e biznesit, flukset e të dhënave të miratuara në organizatë, diagramet e gjendjes, matricat e procesit të të dhënave dhe paraqitjet e tjera të modeleve që përdoren në aktivitetet e organizatës. Kështu, në një kuptim të gjerë, modeli i të dhënave të ndërmarrjesështë një grup modelesh të niveleve të ndryshme që karakterizojnë (model në një nivel abstrakt) aktivitetet e organizatës, d.m.th. përmbajtjen modeli i korporatës varet drejtpërdrejt nga strukturat modele të përfshira në të në një organizatë të caktuar.

Elementet kryesore modeli i të dhënave të ndërmarrjes janë:

• përshkrimi i fushave lëndore të organizatës (përcaktimi i fushave të veprimtarisë);
• marrëdhëniet ndërmjet fushave lëndore të përcaktuara më sipër;
• modeli i të dhënave të informacionit (modeli ERD ose modeli i marrëdhënies me entitet);
• për çdo përshkrim të fushës lëndore:
  • çelësat e entitetit;
  • atributet e entitetit;
  • nëntipet dhe supertipet;
  • marrëdhëniet ndërmjet subjekteve;
  • grupimet e atributeve;
  • marrëdhëniet ndërmjet fushave lëndore;
• modeli funksional ose modeli i procesit të biznesit;
• diagramet e rrjedhës së të dhënave;
• diagramet e gjendjes;
• modele të tjera.

Në këtë mënyrë, modeli i të dhënave të ndërmarrjes përmban entitete, atribute dhe marrëdhënie që përfaqësojnë nevojat për informacion të organizatës. Në fig. 16.1 tregon elementet kryesore modeli i të dhënave të ndërmarrjes.

Shtresat e prezantimit të modelit të të dhënave të ndërmarrjes

Modeli i të dhënave të ndërmarrjes ndahet sipas fushave lëndore, të cilat përfaqësojnë grupe subjektesh që lidhen me mbështetjen e nevojave specifike të biznesit. Disa fusha lëndore mund të mbulojnë funksione specifike biznesi si menaxhimi i kontratave, të tjera mund të grupojnë entitete që përshkruajnë produkte ose shërbime.

Çdo model logjik duhet të korrespondojë me një fushë ekzistuese lëndore modeli i të dhënave të ndërmarrjes. Nëse modeli logjik nuk e plotëson këtë kërkesë, atij duhet t'i shtohet një model që përcakton fushën e lëndës.

Modeli i të dhënave të ndërmarrjes zakonisht ka disa nivele të paraqitjes. Në fakt nivel të lartë (nivel i lartë) modeli i të dhënave të ndërmarrjes gjendet një përshkrim i fushave kryesore lëndore të organizatës dhe marrëdhënieve të tyre në nivel entiteti. Në fig. 16.2 është një fragment modeli i të dhënave të ndërmarrjes niveli më i lartë.

Oriz. 16.2.

Diagrami i paraqitur në figurë tregon katër fusha lëndore: "Klienti" ( klient), "Kontrollo" ( llogari), "Urdhri" ( urdhëroj) dhe "Produkt" ( produkt). Në mënyrë tipike, vetëm në nivelin e lartë të pamjes së modelit lidhjet e drejtpërdrejta ndërmjet fushave lëndore, të cilat, për shembull, rregullojnë faktin e mëposhtëm: blerësi paguan faturën për porosinë e mallit. Informacion i detajuar dhe marrëdhënie indirekte në këtë nivel modeli i korporatës nuk jepen.

Në tjetrën niveli i mesëm(niveli i mesëm) modeli i të dhënave të ndërmarrjes treguar informacion i detajuar rreth objekteve të domenit, d.m.th. çelësat dhe atributet e entitetit, marrëdhëniet e tyre, nëntipet dhe supertipet etj. Për çdo domen të modelit të nivelit të lartë, ekziston një model i nivelit të mesëm. Në fig. 16.3 e paraqitur niveli mesatar përfaqësimi modeli i korporatës për një fragment të fushës lëndore "Urdhri".

Nga fig. 16.3 mund të shihet se fusha lëndore "Urdhri" ( urdhëroj) përfshin disa entitete, të përcaktuara nëpërmjet atributeve të tyre dhe marrëdhënieve ndërmjet tyre. Modeli i paraqitur ju lejon t'u përgjigjeni pyetjeve të tilla si data e porosisë, kush e bëri porosinë, kush e dërgoi porosinë, kush e merr porosinë dhe një sërë të tjerash. Nga diagrami i mësipërm shihet se në këtë organizatë ekzistojnë dy lloje porosish - porosi për promovimin (Komerciale) dhe porositë me pakicë ( Shitje me pakicë).

vini re, se modeli i të dhënave të ndërmarrjes mund të përfaqësojë aspekte të ndryshme të aktiviteteve të organizatës dhe me shkallë të ndryshme detajesh dhe plotësie. Nëse modeli i korporatës përfaqëson të gjitha aspektet e organizatës, quhet edhe modeli i të dhënave të organizatës(modeli i të dhënave të ndërmarrjes).

Nga pikëpamja e projektimit një faktor i rëndësishëm në vendosjen për të krijuar një model të magazinës së të dhënave nga modeli i të dhënave të ndërmarrjesështë shteti plotësinë modeli i të dhënave të ndërmarrjes.

Modeli i të dhënave të ndërmarrjes organizimi ka karakteristikën e evolucionit, d.m.th. është vazhdimisht në zhvillim dhe përmirësim. Disa fusha lëndore modeli i të dhënave të ndërmarrjes mund të jetë i zhvilluar mirë, për disa puna mund të mos ketë filluar ende. Nëse një fragment i fushës së lëndës nuk është përpunuar në modeli i të dhënave të ndërmarrjes, atëherë nuk ka asnjë mënyrë për të përdorur këtë model si pikënisje për projektimin e një magazine të dhënash.

Shkalla e përfundimit modeli i korporatës mund të nivelizohet në dizajnin e HD si më poshtë. Meqenëse procesi i zhvillimit të një magazine të dhënash zakonisht ndahet në një sekuencë fazash në kohë, procesi i projektimit të tij mund të sinkronizohet me procesi i përfundimit zhvillimi i fragmenteve individuale modeli i të dhënave të ndërmarrjes organizatave.

Në nivelin më të ulët shtresa e prezantimit të modelit të të dhënave të korporatës shfaq informacion në lidhje me karakteristikat fizike të objekteve të bazës së të dhënave që korrespondojnë modeli logjik i të dhënave e mesme shtresa e prezantimit të modelit të të dhënave të ndërmarrjes.

Artikulli përshkruan arkitekturat kryesore të depove të të dhënave, disa parimet e përgjithshme ndërtimet e tyre. Mënyrat e paraqitjes së hierarkive në një strukturë të dhënash relacionale janë përshkruar në detaje.

Prezantimi

Në fillim të viteve tetëdhjetë të shekullit të kaluar, gjatë periudhës së zhvillimit të shpejtë të regjistrimit sistemet e informacionit, u kuptua mundësia e kufizuar e aplikimit të tyre për qëllime të analizës së të dhënave dhe ndërtimit të mbështetjes dhe sistemeve vendimmarrëse mbi bazën e tyre. Sistemet e regjistrimit u krijuan për automatizim operacionet rutinë për të bërë biznes - lëshimi i faturave, përpunimi i kontratave, kontrolli i statusit të magazinës etj., dhe personeli i linjës ishin përdoruesit kryesorë të sistemeve të tilla. Kërkesat kryesore për sisteme të tilla ishin sigurimi i transaksionalitetit të ndryshimeve të bëra dhe maksimizimi i shpejtësisë së zbatimit të tyre. Janë këto kërkesa që përcaktuan zgjedhjen e DBMS-së relacionale dhe modelin e paraqitjes së të dhënave entitet-marrëdhënie si ato kryesore të përdorura. zgjidhje teknike në ndërtimin e sistemeve të regjistrimit.

Për menaxherët dhe analistët, nga ana tjetër, kërkoheshin sisteme që do të lejonin:

Natyrisht, sistemet e regjistrimit nuk plotësonin asnjë nga kërkesat e mësipërme. Në sistemin e regjistrimit, informacioni është i rëndësishëm vetëm në momentin e hyrjes në bazën e të dhënave; në momentin tjetër, për të njëjtën kërkesë, mund të merrni një rezultat krejtësisht të ndryshëm. Ndërfaqja e sistemeve të regjistrimit është krijuar për të kryer operacione të përcaktuara rreptësisht dhe mundësia e marrjes së rezultateve për një kërkesë ad-hoc është shumë e kufizuar. Aftësia për të përpunuar sasi të mëdha të dhënash është gjithashtu e vogël për shkak të cilësimit të DBMS për të kryer transaksione të shkurtra dhe ngadalësimit të pashmangshëm të punës së përdoruesve të tjerë.

Përgjigja ndaj kësaj nevoje ishte shfaqja Teknologji e re Organizimi i bazës së të dhënave - teknologjia e ruajtjes së të dhënave.

Përkufizimi dhe arkitekturat tipike të magazinës së të dhënave

Koncepti i depove të të dhënave bazohet në dy ide kryesore - integrimin e të dhënave të detajuara të ndryshme (të detajuara në kuptimin që ato përshkruajnë disa fakte specifike, veti, ngjarje, etj.) në një depo të vetme dhe ndarja e grupeve të të dhënave dhe aplikacioneve të përdorura për përpunimi online dhe përdoret për të zgjidhur problemet e analizës. Definicioni i " ruajtja e të dhënave" u dha për herë të parë nga William G. Inmon në monografinë e tij. Në të, ai përcaktoi një magazinë të dhënash si "një subjekt i orientuar, i integruar, që përmban të dhëna historike, një grup të dhënash të pashkatërrueshme të krijuara për të mbështetur vendimmarrjen e menaxhimit."

Konceptualisht, modeli i magazinës së të dhënave mund të paraqitet si një diagram i paraqitur në Figurën 1. Të dhënat nga burime të ndryshme vendosen në magazinën e të dhënave dhe përshkrimet e këtyre të dhënave vendosen në depon e meta të dhënave. Përdoruesi përfundimtar, duke përdorur mjete të ndryshme (mjete vizualizimi, mjete raportimi, përpunim statistikor, etj.) dhe përmbajtjen e depove, analizon të dhënat në depo. Rezultati i veprimtarisë së tij është informacioni në formën e raporteve të gatshme, modeleve të fshehura të gjetura dhe çdo parashikimi. Që nga mjetet e punës përdoruesi përfundimtar me një magazinë të dhënash mund të jetë shumë e larmishme, atëherë teorikisht zgjedhja e tyre nuk duhet të ndikojë në strukturën e saj dhe funksionet e mbajtjes së saj të përditësuar.

Zbatimi fizik i skemës konceptuale të mësipërme mund të jetë shumë i larmishëm. Qasjet më të zakonshme janë renditur më poshtë.

Ruajtja virtuale e të dhënaveështë një sistem që përfaqëson ndërfaqet dhe metodat e aksesit në sistemin e regjistrimit që emulon punën me të dhënat në këtë sistem, si me një depo të dhënash. Një depo virtuale e të dhënave mund të organizohet duke krijuar një seri pamjesh (pamje) në bazën e të dhënave, ose duke aplikuar mjete të veçanta akses, si p.sh. produktet OLAP të desktopit, si BusinessObjects, Brio Enterprise dhe të tjerë.

Përparësitë kryesore të kësaj qasjeje janë:

Megjithatë, ajo ka shumë më tepër disavantazhe sesa avantazhe. Duke krijuar ruajtje virtuale të dhënat, ju nuk krijoni një ruajtje si të tillë, por iluzionin e ekzistencës së tij. Struktura e ruajtjes së të dhënave dhe vetë ruajtjes së të dhënave nuk ndryshon, dhe problemet mbeten:

	performanca;
	Transformimet e të dhënave;
	Integrimi i të dhënave me burime të tjera;
	Mungesa e historisë;
	Pastërtia e të dhënave;
	Varësia nga disponueshmëria e bazës së të dhënave kryesore;
	Varësia nga struktura e bazës kryesore të të dhënave.

Arkitektura me dy nivele Ruajtja e të dhënave përfshin ndërtimin e të dhënave mars (data mart) pa krijuar një depo qendrore, ndërsa informacioni vjen nga një numër i vogël sistemesh regjistrimi dhe kufizohet në një fushë specifike lëndore. Kur ndërtoni mars të të dhënave, përdoren parimet themelore të ndërtimit të depove të të dhënave, për të cilat do të diskutohet më poshtë, kështu që ato mund të konsiderohen si depo të dhënash në miniaturë. Përparësitë e marsit të të dhënave janë:

Ndërtimi i një magazine të plotë të të dhënave të korporatës zakonisht bëhet në arkitekturë me tre nivele(Duhet theksuar se këtu arkitektura me tre nivele nuk kuptohet si struktura "DB - Application Server - Client"). Në nivelin e parë, gjenden burime të ndryshme të të dhënave - sistemet e brendshme të regjistrimit, sistemet e ndihmës, burime të jashtme (të dhëna agjencitë e lajmeve, treguesit makroekonomikë). Niveli i dytë përmban një depo qendrore të të dhënave, ku informacionet nga të gjitha burimet me niveli i parë, dhe ndoshta një depo të dhënash operacionale (OSD). Magazina operative nuk përmban të dhëna historike dhe kryen dy funksione kryesore. Së pari, ai është një burim informacioni analitik për menaxhimin operacional dhe, së dyti, të dhënat përgatiten këtu për ngarkim të mëvonshëm në depon qendrore. Nën përgatitjen e të dhënave kuptohet transformimi i tyre dhe zbatimi i kontrolleve të caktuara. Prania e OSD është thjesht e nevojshme me rregullore të ndryshme për marrjen e informacionit nga burimet. Niveli i tretë në arkitekturën e përshkruar është një grup martesh të dhënash specifike për domenin, burimi i informacionit për të cilin është depoja qendrore e të dhënave. Është me mars të dhënave që shumica e përdoruesve fundorë punojnë.

Dizajnimi i strukturës së një dyqani të të dhënave relacionale

Depot e të dhënave janë ndërtuar mbi bazën e një modeli shumëdimensional të të dhënave. Një model shumëdimensional i të dhënave nënkupton zgjedhjen e dimensioneve individuale (koha, gjeografia, klienti, llogaria) dhe faktet (vëllimi i shitjeve, të ardhurat, sasia e mallrave), të cilat analizohen sipas dimensioneve të përzgjedhura. Një model shumëdimensional i të dhënave mund të zbatohet fizikisht si në DBMS shumëdimensionale ashtu edhe në ato relacionale. V rasti i fundit kryhet sipas skemës "yll" ose "flokë bore". Këto skema përfshijnë përzgjedhjen e tabelave të fakteve dhe tabelave të dimensioneve. Çdo tabelë faktesh përmban të dhëna të detajuara dhe çelësa të huaj për tabelat e dimensioneve. Teoria e ndërtimit të një modeli shumëdimensional të të dhënave dhe zbatimi i tij në një strukturë relacionale është mbuluar gjerësisht si në literaturën e huaj ashtu edhe atë vendase.

Problemi i përfaqësimit të hierarkive mund t'i atribuohet numrit të temave të pakta të mbuluara. Si shembull i një matjeje që përdoret gjerësisht në analizën e aktiviteteve të një ndërmarrje dhe ka një strukturë hierarkike, mund të citojmë një drejtori të artikujve të kostos. Merrni parasysh modelin e qendrave të kostos (qendrave të kostos) të paraqitur në Figurën 2.

Shkenca klasike e kompjuterave zgjidh problemin e përfaqësimit të hierarkive duke përdorur lidhjen rekursive. Kjo zgjidhje e thjeshtë ju lejon të vendosni një pemë të çdo thellësie dhe dimensioni në një tabelë. Në rastin tonë, të dhënat në fjalë do të paraqiten në formën e mëposhtme:

ID e prindit 1 Kompania 2 Kontrolli 3 Infrastruktura 4 Prodhimi 5 6 Shërbimet 7 Fusha A 8 Fusha B

Tabela 1.

Sidoqoftë, thjeshtësia e kësaj zgjidhjeje fsheh edhe pengesën e saj kryesore. Fatkeqësisht, SQL standarde nuk mbështet tregues rekurzivë, kështu që përdoren metoda të tjera për të përfaqësuar pemët në një magazinë të dhënash.

Metoda e propozuar nga Joe Celko bazohet në teorinë e grupeve. Në këtë metodë, të gjitha nyjet e pemës përshkohen në rend të përshkimit të drejtpërdrejtë dhe për secilën nyje plotësohen dy vlera - kufiri i majtë dhe i djathtë, dhe për secilën nyje të degës së pemës, kufiri i majtë plotësohet së pari dhe vetëm më pas. e drejta - kur ktheheni nga pasardhësit te prindërit. Pra, në shembullin tonë, numërimi i nyjeve do të jetë si më poshtë:

Me këtë numërim të nyjeve, çdo prind përmban fëmijë, kufiri i majtë dhe i djathtë i të cilëve shtrihen në intervalin midis kufirit të majtë dhe të djathtë të prindit. Në mënyrë të ngjashme, të gjithë prindërit e pasardhësve kanë kufiri i majtë, i cili është më i vogël se kufiri i majtë i fëmijës dhe ai i djathtë, që është më i madh se kufiri i djathtë i fëmijës. Prandaj, shuma e kostos për një qendër të veçantë kostoje dhe të gjithë përbërësit e saj mund të merren me një pyetje të vetme. Për shembull, për të marrë kostot e infrastrukturës, mund të ekzekutoni pyetjen e mëposhtme SQL:

zgjidhni shumën (tabela_faktesh.kosto)
nga tabela_fakte, tabela_dimensionale D1, tabela_dimensionale D2
ku fakt_tabela.dimension_id = D2.id
dhe D2.majtas >= D1.majtas
dhe D2.djathtas<= D1.right
dhe D1.emri = "Infrastruktura"

Për ta bërë më të lehtë punën me një drejtori të tillë, përveç fushave majtas dhe djathtas, duhet të shtohen edhe dy fusha të tjera: "Niveli" - niveli i nyjës në pemë, "Is_leaf" - një flamur që tregon nëse nyja është një gjethe në pemë apo jo. Kështu, marrim një tabelë "dimension_table" (shih tabelën 2), e cila ju lejon të ruani një pemë me çdo thellësi dhe dimension foleje dhe ju lejon të zgjidhni fëmijët dhe prindërit me një pyetje të vetme.

1 Kompania 2 Kontrolli 3 Infrastruktura 4 Prodhimi 5 6 Shërbimet 7 Fusha A 8 Fusha B

Tabela 2. Paraqitja e hierarkive duke përdorur kufijtë e majtë dhe të djathtë

Një metodë tjetër, e përshkruar nga Ralph Kimball, bazohet në prezantimin e një tabele ndihmëse ("tabelë ndihmëse"), përmes së cilës tabela e fakteve lidhet me tabelën e dimensioneve. Kjo tabelë ndihmëse pasqyron strukturën hierarkike të dimensionit dhe i bindet ligjit të mëposhtëm: tabela ndihmëse përmban të gjithë grupin e çifteve prind-fëmijë dhe fëmija mund të mos jetë një fëmijë i menjëhershëm i prindit. Struktura e një tabele të tillë dhe përmbajtja e saj janë paraqitur në tabelën 3.

ID e prindit ID e fëmijës Largësia 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

Tabela 3. Struktura dhe përmbajtja e tabelës ndihmëse.

Tani duke e lidhur tabelën e fakteve (shih Figurën 4) me ID-në e fëmijës në tabelën ndihmëse dhe tabelën e dimensioneve me ID-në e prindit, ne mund të llogarisim shumën e kostove për çdo qendër kostoje dhe të gjithë përbërësit e saj në një pyetje, si në rastin e mëparshëm. Në të njëjtën kohë, duke shtuar kufizime në fushat "Distanca" dhe "Is Leaf", ne mund të llogarisim lehtësisht kostot për çdo nivel në hierarki.

zgjidhni shumën (tabela_faktesh.kosto)
nga tabela_fakte, tabela_dimensionale, tabela_ndihmuese
ku fact_table.dimension_id = helper_table.child_id
dhe dimension_table.dimension_id = helper_table.parent_id
dhe dimension_table.name = "Infrastruktura"
dhe helper_table.distanca = 1

Problemi i dizajnimit të drejtorive hierarkike bëhet edhe më i ndërlikuar kur një dimension mund të ketë disa hierarki alternative dhe bëhet mjaft i vështirë nëse është e nevojshme të ruhet një histori e ndryshimit të tabelës së dimensioneve.

Në përgjithësi, problemi i ndryshimit të ngadalshëm të matjeve është interesant në vetvete, pa e ndërlikuar atë nga klasifikuesit hierarkikë. Në literaturë, në shumicën e rasteve konsiderohet në kontekstin e "faktit - dimensioni që ndryshon ngadalë". Një detyrë e tillë, në të vërtetë, zgjidhet relativisht thjesht duke shtuar datën e fillimit dhe datën e përfundimit të hyrjes në tabelën e dimensioneve. Ndryshimi i një hyrjeje në drejtori rezulton në "mbylljen" e hyrjes së vjetër dhe shtimin e një të reje. Tani, duke u kthyer në shembullin e referencës së artikullit të kostos, një përdorues që dëshiron të marrë informacion mbi artikullin aktual të kostos për çdo datë të caktuar duhet ta përfshijë atë në kushtin e pyetjes SQL.

Le të supozojmë se libri i referencës së zërave të kostos është i lidhur me librin e referencës së llogarive të kontabilitetit. Një ose më shumë llogari kontabël përfaqësojnë një zë kostoje. Si duhet të pasqyrohet një ndryshim në çdo atribut të një zëri kostoje në drejtorinë e llogarive të kontabilitetit? Nga njëra anë, nga pikëpamja e grafikut të llogarive, ndryshimi i atributit nuk çon në një ndryshim në thelbin e zërit të kostos, dhe hyrjet kontabël përmes skemës së llogarive duhet t'i atribuohen të njëjtit artikull të kostos. Nga ana tjetër, në drejtorinë e artikujve të kostos është shfaqur një hyrje e re, e cila duhet të jetë disi e lidhur me drejtorinë e llogarive. Ky problem mund të zgjidhet duke e ndarë tabelën e dimensioneve në dysh - që përmban informacione të përditësuara dhe që përmban historikun e ndryshimit të entitetit. Kjo qasje zgjidh gjithashtu problemin e një dimensioni hierarkik me nevojën për të mbajtur një histori të ndryshimeve në të dhënat në të.

Le ta shqyrtojmë më në detaje (shih Fig. 5). Tabela "dimension_actual" është një tabelë dimensionesh me çelësin kryesor dimension_id që përmban atributet e sakta të dimensionit deri më sot. Tabela historike "dimension_history" lidhet me të nëpërmjet çelësit të huaj dimension_id, në të cilin ndodhet historiku i ndryshimeve në regjistrime, i përcaktuar nga datat e fillimit/mbarimit të regjistrimit (fushat data_fillimi, data_fund). Rekordi aktual është gjithashtu i pranishëm në të me një datë të hapur skadimi. Tabela e fakteve "fact_table" është e lidhur me tabelën e dimensioneve përmes një tabele ndihmëse "helper_table" e cila pasqyron struktura hierarkike matjet.

Qasja e përshkruar lejon: së pari, të ruhet dhe të punohet me dimensionin si me një pemë të pabalancuar; së dyti, për të ekzekutuar shpejt pyetjet për të cilat historia e ndryshimeve të dimensionit nuk është e rëndësishme (tabela që përmban historikun nuk merr pjesë); së treti, ju lejon të gjurmoni historinë e ndryshimeve në dimension dhe, së fundi, ndan pasqyrimin e historisë dhe hierarkisë, gjë që thjeshton shumë mirëmbajtjen e dimensionit.

Pika e tretë e rëndësishme me të cilën shpesh duhet të merret një zhvillues i magazinës lidhet me vlerat agregate. Kjo klasë problemesh mund të ndahet me kusht në dy nënklasa. E para merr në konsideratë detyrat e krijimit dhe mirëmbajtjes së agregateve sipas të dhënave të detajuara në dispozicion dhe është mjaft e mbuluar në literaturë. E dyta lidhet me faktin se burimet e të dhënave për magazinë nuk japin vlera të detajuara, por tashmë një grup të dhënash të grumbulluara. Kjo situatë është tipike kur krijohen depo të dhënash për kompanitë e menaxhimit dhe organet rregullatore qeveritare që mbledhin shumë forma raportimi.

Një rast ekstrem i kësaj qasjeje është një model që mund të quhet në mënyrë konvencionale "vlera treguese". Thelbi i saj qëndron në faktin se kalimi në një grup të madh treguesish që karakterizojnë aktivitetet financiare dhe ekonomike të ndërmarrjes. Këta tregues mund të jenë ose jo funksionalisht të lidhur me njëri-tjetrin, mund të pasqyrojnë të njëjtat vlera, por me nivele të ndryshme detajesh, etj. Kur përpiqet të përfaqësojë të dhëna të tilla në formën e një modeli shumëdimensional, zhvilluesi ndeshet me probleme të rëndësishme dhe shumë shpesh shkon në rrugën e krijimit të jo një ruajtjeje të dhënash, por një dyqan formash. Një depo tipike formularësh bazohet në tre dimensione - treguesit ekonomikë, koha, formularët e raportimit; tabelat e fakteve - vlerat e treguesve ekonomikë dhe tabelat ndihmëse që përshkruajnë se si janë vendosur treguesit dhe vlerat e tyre në formularët e raportimit. Gjatë analizimit të të dhënave të tilla, analisti do të përjetojë vështirësi të konsiderueshme, kryesisht për faktin se treguesit e formave të ndryshme nuk mund të krahasohen me njëri-tjetrin. E vetmja gjë që i mbetet është të gjurmojë ndryshimet në treguesit e një forme me kalimin e kohës.

konkluzioni

Gjatë zbatimit të projekteve për ndërtimin e depove të të dhënave, lindin një sërë detyrash të zakonshme që janë të pavarura nga fusha lëndore e informacionit që përpunohet. Këto detyra përfshijnë:

Në këtë artikull, u shqyrtuan zgjidhjet e mundshme për këto probleme. Në veçanti, mënyrat për të zbatuar dimensionet hierarkike janë dhënë duke futur atribute shtesë (kufijtë majtas dhe djathtas), si dhe duke futur një tabelë shtesë - "tabelë ndihmëse". Megjithatë, në të gjitha problemet e shqyrtuara, ka çështje të pazgjidhura që kërkojnë kërkime të mëtejshme. Në veçanti, rasti i dimensioneve hierarkike me nevojën për të mbajtur një histori ndryshimesh që kanë lidhje me ndonjë drejtori tjetër është i vështirë për t'u zbatuar. Ky artikull nuk përfshin pyetje në lidhje me metodat e pastrimit të të dhënave dhe algoritmet për ngarkimin e të dhënave në ruajtje. Këto tema kërkojnë shqyrtim të veçantë.

LITERATURA

1.	Joerg Reinschmidt, Allison Francoise. Udhëzues për certifikimin e inteligjencës së biznesit. IBM Redbooks;
2.	Inmon W. Ndërtimi i Magazinës së të Dhënave. – Nju Jork: John Willey & Sons, 1992;
3.	Spearley, Eric. Depot e të dhënave të korporatës. Planifikimi, zhvillimi, zbatimi. Vëllimi. 1: Per. nga anglishtja. - M .: Shtëpia botuese "Williams", 2001;
4.	Joe Celco. Pemët në SQL: Intelligent Enterprise, 20 tetor 2000;
5.	Donald E. Knuth. Arti i Programimit, Vëllimi 1. Algoritmet bazë, botimi i 3-të: - M .: Shtëpia Botuese "Williams", 2000 .;
6.	Ralph Kimball. Ndihmë për Hierarkitë: DBMS shtator 1998;
7.	Ralph Kimball. Dimensionet që ndryshojnë ngadalë: DBMS Prill 1996;
8.	Fjalor Statistikor: M. "Financa dhe Statistika", 1989;
9.	Duka V, Samoylenko A, Minierat e të dhënave: një kurs trajnimi. - Shën Petersburg: Peter, 2001;
10.	Erhard Rahm, Hong Hai Do: Pastrimi i të dhënave: Problemet dhe qasjet aktuale. Buletini i Inxhinierisë së të Dhënave IEEE 23(4): 3-13 (2000);
11.	Ralph Kimball: Paketa e veglave të depove të të dhënave: Teknika praktike për ndërtimin e depove dimensionale të të dhënave. John Wiley 1996
12.	Maria Sueli Almeida, Missao Ishikawa, Joerg Reinschmidt, Torsten Roeber, Fillimi me Deponimin e të Dhënave dhe Inteligjencën e Biznesit. IBM Redbooks;
13.	Nigel Pendse, OLAP Architectures: The OLAP Report, http://www.olapreport.com/Architectures.htm#top.

Duket se tani tema e zhvillimit të depove të të dhënave ka rrëshqitur në një raund të ri zhvillimi. Teknologjitë, qasjet dhe mjetet e reja po shfaqen. Studimi, testimi dhe aplikimi i arsyeshëm i tyre na lejon të krijojmë zgjidhje vërtet interesante dhe të dobishme. Dhe sillni ato në zbatim, duke shijuar faktin që zhvillimet tuaja përdoren në punë reale dhe sjellin përfitime.

Epilogu

Në përgatitjen e këtij artikulli, u përpoqa të fokusohesha kryesisht tek arkitektët, analistët dhe zhvilluesit që punojnë drejtpërdrejt me depot e të dhënave. Por doli që në mënyrë të pashmangshme "e mora temën pak më gjerë" - dhe kategoritë e tjera të lexuesve ranë në fushën e vizionit. Disa pika do të duken të diskutueshme, disa nuk janë të qarta, disa janë të dukshme. Njerëzit janë të ndryshëm - me përvoja, prejardhje dhe pozicione të ndryshme.
Për shembull, pyetjet tipike të menaxherëve janë "kur të tërheqim arkitektë?", "Kur duhet të bëj arkitekturë?", "Arkitektura - a nuk do të jetë shumë e shtrenjtë?" tingëllon mjaft e çuditshme për ne (zhvilluesit, projektuesit), sepse për ne arkitektura e sistemit shfaqet me lindjen e tij - nuk ka rëndësi nëse e kuptojmë apo jo. Dhe edhe nëse nuk ka asnjë rol zyrtar të një arkitekti në projekt, një zhvillues normal gjithmonë "ndiz arkitektin e tij të brendshëm".

Në skemën e madhe të gjërave, nuk ka rëndësi se kush është arkitekti, ajo që ka rëndësi është që dikush t'i bëjë këto pyetje dhe t'i hulumtojë përgjigjet e tyre. Nëse arkitekti veçohet qartë, kjo do të thotë vetëm se ai është përgjegjës kryesor për sistemin dhe zhvillimin e tij.
Pse tema e "antifragjilitetit" më dukej e rëndësishme në lidhje me këtë temë?

“E veçanta e antifragjilitetit është se na lejon të punojmë me të panjohurën, të bëjmë diçka në kushte ku nuk kuptojmë se çfarë po bëjmë saktësisht – dhe të kemi sukses”./Nassim N.Taleb/

Prandaj, kriza dhe shkalla e lartë e pasigurisë nuk janë justifikim për mungesën e arkitekturës, por faktorë që përforcojnë nevojën e saj.

Etiketa:

• arkitekturës
• ruajtja e të dhënave

Shto etiketa