Koncepti i një depoje të dhënash
Një "magazinë e të dhënave" është një koleksion i të dhënave specifike për domenin, i kufizuar në kohë dhe i pandryshueshëm për të mbështetur vendimmarrjen e menaxhimit.
Të dhënat në ruajtje vijnë nga sistemet operative (Sistemet OLTP), të cilat janë krijuar për të automatizuar proceset e biznesit. Për më tepër, depoja mund të plotësohet nga burime të jashtme, siç janë raportet statistikore, drejtoritë e ndryshme, etj. Magazina e të dhënave, përveç informacionit të detajuar, përmban agregate, d.m.th. duke përmbledhur informacione, si shumat e shitjeve, sasitë, shpenzimet totale, etj.
Një depo e të dhënave tatimore duhet të shihet si një qendër informacioni që automatizon llogaritjen e taksave të shtyra, pranon dhe ruan informacione nga burime të jashtme dhe i transformon të dhënat në një format të përshtatshëm për përdoruesit. Një depo e tillë është një platformë për ruajtjen e të dhënave tatimore të sakta dhe të përditësuara që mund të merren dhe transferohen në aplikacionet e jashtme për qëllime të analizës, auditimit, planifikimit dhe parashikimit.
Magazina e të dhënave është një depo burimet e informacionit dhe siguron konsolidimin e të dhënave të ndërmarrjes për qëllime raportimi dhe analize. Të dhënat dhe informacioni, si operacional ashtu edhe jo-operativ, futen në magazinë, zakonisht duke përdorur mjetet ETL, nga burimet, të dhënat kur bëhen të disponueshme ose në baza të rregullta. Transformimi i të dhënave ju lejon të përpunoni kërkesat dhe t'i analizoni ato në kohën e duhur, gjë që thjeshton dhe shpejton procesin e përmbushjes së kërkesave për informacionin e marrë fillimisht nga burime të tjera.
Përfitimet e një depoje përfshijnë aftësinë për të transformuar të dhënat në informacion cilësor të nevojshëm për t'u përgatitur raportimi tatimor dhe respektimin e ligjeve tatimore, për përdoruesit e të gjitha niveleve. Çdo palë e interesuar - klientë, partnerë, punonjës, menaxherë dhe drejtues - mund të marrë përmbajtje interaktive në çdo kohë dhe kudo.
Vetë ekzistenca e një burimi të vetëm informacioni për raportimin tatimor dhe pajtueshmërinë tatimore është një hap i madh përpara për shumë autoritete tatimore.
Pse është e nevojshme të ndërtohen depo të dhënash - në fund të fundit, ato përmbajnë informacione dukshëm të tepërta që janë tashmë në bazat e të dhënave ose skedarët e sistemeve operative? Është e pamundur ose shumë e vështirë të analizohen drejtpërdrejt të dhënat nga sistemet operative. Kjo është për arsye të ndryshme, duke përfshirë fragmentimin e të dhënave dhe ruajtjen e tyre në formate të ndryshme DBMS. Por edhe nëse të gjitha të dhënat në ndërmarrje ruhen në një server qendror të bazës së të dhënave, analisti pothuajse me siguri nuk do të kuptojë strukturat e tyre komplekse, ndonjëherë konfuze.
Kështu, detyra e magazinës është të sigurojë "lëndën e parë" për analizë në një vend dhe në një strukturë të thjeshtë e të kuptueshme.
Ekziston një arsye tjetër që justifikon shfaqjen e një ruajtjeje të veçantë - pyetjet komplekse analitike për informacionin operacional ngadalësojnë punën aktuale të kompanisë, bllokojnë tabelat për një kohë të gjatë dhe kapin burimet e serverit.
Nën ruajtje mund të kuptohet jo domosdoshmërisht një grumbullim gjigant i të dhënave - gjëja kryesore është që të jetë i përshtatshëm për analizë.
Koncepti i magazinës së të dhënave
Autori i konceptit të depove të të dhënave ( Depo e te dhenave) është B. Inmon, i cili i përkufizoi magazinat e të dhënave si: “grupe të dhënash historike të orientuara nga domeni, të integruara, të pandryshueshme, të organizuara për qëllime të mbështetjes së menaxhmentit”, të dizajnuara për të vepruar si një “burim i vetëm dhe i vetëm i së vërtetës”, duke u ofruar menaxherëve dhe analistëve informacion të besueshëm të nevojshëm për analizën operacionale dhe vendimmarrje. Skema e magazinës së të dhënave mund të përfaqësohet si më poshtë:
Zbatimi fizik i kësaj skeme mund të jetë shumë i larmishëm. Le të shqyrtojmë opsionin e parë - një depo virtuale të të dhënave, ky është një sistem që siguron qasje në një sistem konvencional të regjistrimit që imiton punën me një depo të dhënash. Ruajtja virtuale mund të organizohet në dy mënyra. Ju mund të krijoni një seri "pamjesh" (pamje) në bazën e të dhënave ose përdorni mjete të veçanta aksesi në bazën e të dhënave (për shembull, produktet e klasës OLAP të desktopit).
Për shkak se ndërtimi i një magazine të dhënash është një proces kompleks që mund të zgjasë me vite, disa organizata në vend të kësaj ndërtojnë marte të dhënash që përmbajnë informacione për departamente specifike. Për shembull, një treg i të dhënave të marketingut mund të përmbajë vetëm informacione për klientët, produktin dhe shitjet dhe të mos përfshijë planet e furnizimit. Marte të shumta të të dhënave për departamentet mund të bashkëjetojnë me magazinën kryesore të të dhënave, duke dhënë një pamje të pjesshme të përmbajtjes së magazinës. Martet e të dhënave ndërtohen shumë më shpejt sesa ruajtja, por mund të ketë probleme të rëndësishme të integrimit më vonë nëse planifikimi fillestar është bërë pa marrë parasysh modelin e plotë të biznesit. Kjo është mënyra e dytë.
Ndërtimi i një depoje të plotë të të dhënave të ndërmarrjes zakonisht bëhet në një arkitekturë me tre nivele. 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, ku rrjedhin informacion nga të gjitha burimet nga niveli i parë, dhe, ndoshta, një depo të dhënash operacionale që nuk përmban të dhëna historike dhe kryen dy funksione kryesore.
Koncepti i depove të të dhënave bazohet në dy ide themelore:
1) integrimi i të dhënave të detajuara të ndara më parë në një depo të vetme të të dhënave, koordinimi i tyre dhe, ndoshta, grumbullimi:
arkivat historike;
të dhëna nga ODS tradicionale;
të dhëna nga burime të jashtme.
2) ndarja e grupeve të të dhënave të përdorura për përpunimin operacional dhe grupeve të të dhënave të përdorura për zgjidhjen e problemeve të analizës.
Qëllimi i konceptit të depove të të dhënave është të zbulojë kërkesat për të dhënat e vendosura në bazën e të dhënave të synuar të magazinës së të dhënave (Tabela 1), të përcaktojë parimet e përgjithshme dhe fazat e ndërtimit të saj, burimet kryesore të të dhënave, për të dhënë rekomandime. për zgjidhjen e problemeve të mundshme që lindin kur ato shkarkohen, pastrohen, koordinohen, transportohen dhe ngarkohen në bazën e të dhënave të synuar.
Tabela 1. Kërkesat themelore për të dhënat në Depon e të Dhënave.
| Orientimi i lëndës | Të gjitha të dhënat për një subjekt të caktuar (objekt biznesi) mblidhen (zakonisht nga një grup burime të ndryshme), pastrohen, koordinohen, plotësohen, grumbullohen dhe paraqiten në një formë të vetme të përshtatshme për përdorimin e tyre në analizën e biznesit. |
| Integrimi | Të gjitha të dhënat për objekte të ndryshme biznesi koordinohen dhe ruhen reciprokisht në një hapësirë ruajtëse të vetme në të gjithë korporatën. |
| pandryshueshmëria | Të dhënat fillestare (historike), pasi të jenë rënë dakord, verifikuar dhe futur në Magazinimin e të gjithë korporatës, mbeten të pandryshuara dhe përdoren ekskluzivisht në modalitetin e leximit. |
| Mbështetja e afatit kohor | Të dhënat janë të strukturuara në mënyrë kronologjike dhe pasqyrojnë historinë, për një periudhë të mjaftueshme kohore për të përfunduar detyrat e analizës dhe parashikimit të biznesit. |
Subjekti i konceptit të magazinës së të dhënave është vetë të dhënat. Pasi sistemi tradicional i përpunimit të të dhënave (DPS) zbatohet dhe fillon të funksionojë, ai bëhet saktësisht i njëjti objekt i pavarur i botës reale si çdo tjetër. procesi i prodhimit. Dhe të dhënat, e cila është një nga produktet përfundimtare të një prodhimi të tillë, ka saktësisht të njëjtat veti dhe karakteristika si çdo produkt industrial: jetëgjatësia, vendi i ruajtjes (magazinimit), përputhshmëria me të dhënat nga industritë e tjera (SOD), vlera e tregut, transportueshmëria. , plotësia, mirëmbajtja, etj.
Nga ky këndvështrim merren parasysh të dhënat në magazinat e të dhënave. Kjo do të thotë, qëllimi këtu nuk është mënyra për të përshkruar dhe shfaqur objekte fusha lëndore, por vetë të dhënat, si objekt i pavarur i fushës lëndore të krijuara si rezultat i funksionimit të sistemeve të informacionit të krijuara më parë.
Për të kuptuarit e saktë Ky koncept kërkon sqarimin e pikave themelore të mëposhtme:
· Koncepti i ruajtjes së të dhënave nuk është koncept i analizës së të dhënave, por është koncept i përgatitjes së të dhënave për analizë.
· Koncepti i magazinës së të dhënave nuk paracakton arkitekturën e sistemit analitik të synuar. Ai flet se cilat procese duhet të ekzekutohen në sistem, por jo saktësisht se ku dhe si duhet të zhvillohen këto procese.
· Koncepti i magazinave të të dhënave nuk përfshin vetëm një pamje të vetme logjike të të dhënave të organizatës, por zbatimin e një burimi të vetëm të integruar të të dhënave.
Përveç kësaj drejtoria e vetme meta të dhënat, mjetet e ngarkimit, grumbullimit dhe rakordimit të të dhënave, koncepti i depove të të dhënave nënkupton: integrimin, pandryshueshmërinë, mbështetjen kronologjike dhe konsistencën e të dhënave. Dhe nëse dy vetitë e para (integrimi dhe pandryshueshmëria) ndikojnë në mënyrat e analizës së të dhënave, atëherë dy të fundit (mbështetja kronologjike dhe konsistenca) ngushtojnë ndjeshëm listën e detyrave analitike që duhen zgjidhur.
Pa mbështetjen e kronologjisë (disponueshmëria e të dhënave historike), është e pamundur të flitet për zgjidhjen e problemeve të parashikimit dhe analizës së trendit. Por më kritike dhe më e dhimbshme janë çështjet që lidhen me rakordimin e të dhënave.
Kërkesa kryesore e analistit nuk është aq efikasiteti sa besueshmëria e përgjigjes. Por besueshmëria në fund të fundit përcaktohet nga qëndrueshmëria. Derisa të punohet për të rënë dakord reciprokisht për vlerat e të dhënave nga burime të ndryshme, është e vështirë të flitet për besueshmërinë e tyre.
Shpesh, një menaxher përballet me një situatë ku sisteme të ndryshme mund dhe zakonisht japin një përgjigje të ndryshme për të njëjtën pyetje. Kjo mund të jetë si për shkak të mossinkronizmit të momenteve të modifikimit të të dhënave, ndryshimeve në interpretimin e të njëjtave ngjarje, koncepte dhe të dhëna, ndryshime në semantikën e të dhënave në procesin e zhvillimit të fushës lëndore, gabime elementare gjatë futjes dhe përpunimi, humbja e pjesshme e fragmenteve individuale të arkivave, etj. Është e qartë se nuk është realiste të merren parasysh dhe të përcaktohen paraprakisht algoritmet për zgjidhjen e të gjitha përplasjeve të mundshme. Për më tepër, është e pamundur të bëhet brenda mënyra e funksionimit, në mënyrë dinamike, drejtpërdrejt në procesin e gjenerimit të një përgjigjeje ndaj një kërkese.
Informacione të ngjashme.
Vini re se ruajtja e të dhënave është një teknologji në zhvillim. Si për çdo zhvillimin e teknologjisë, duhet pasur njëfarë kujdesi kur vlerësohen veprimet e shitësve të softuerëve HD që përpiqen të pozicionohen mes konkurrentëve. Për shembull, diskutimet rreth madhësisë së HD - nga çfarë madhësie ruajtja e të dhënave mund të konsiderohet si një depo? Me 50 GB? Vini re se në disa fusha të kërkimit, madhësia e grupit të analizuar mund të jetë shumë e vogël. Thjesht nuk ka të dhëna. Dhe analiza e një grupi të tillë është e mundur.
Konsideroni elementet kryesore të konceptit të ruajtjes së të dhënave.
Nxjerrja e të dhënave nga sistemet operative
Elementi kryesor i konceptit të ruajtjes së të dhënave është se qasja më efikase në të dhënat e ruajtura për analizë mund të sigurohet vetëm nëse ato ndahen nga sistemi operativ (transaksional), d.m.th. të dhënat nga sistemi operativ duhet të zhvendosen në një të veçantë sistemi i ruajtjes së të dhënave. Kjo qasje është historike. Për shkak të kufizimeve në harduer dhe teknologji, për të siguruar performancën e një sistemi transaksional, të dhënat u arkivuan në kaseta ose media jashtë një sistemi të tillë. Problemi i aksesit në to kërkonte zgjidhje të caktuara teknologjike.
Duhet theksuar se me zhvillimin e konceptit, pozicioni i ndarjes së të dhënave për analizë nga të dhënat në sistemin OLTP ka pësuar pak ndryshime. Ajo u bë më formale dhe e pasuruar nga përdorimi i fondeve analiza multivariate të dhëna. Aktualisht, një depo e të dhënave mund të ndërtohet si në një sistem ekzistues OLTP, ashtu edhe mbi të, dhe si një objekt i pavarur. Kjo duhet të vendoset nga menaxheri i projektit të TI-së si pjesë e zgjedhjes së arkitekturës DW.
Nevoja për të integruar të dhëna nga sisteme të shumta OLTP
Sistemet e ruajtjes së të dhënave janë më të dobishme kur të dhënat mund të merren nga më shumë se një sistem OLTP. Kur të dhënat duhet të mblidhen nga shumë aplikacione biznesi, është e natyrshme të supozohet se kjo duhet të bëhet në një vend tjetër nga vendi ku janë lokalizuar aplikacionet origjinale. Edhe para krijimit të depove të strukturuara të të dhënave, analistët në shumë raste kombinonin të dhënat e nxjerra nga sisteme të ndryshme, në një spreadsheet ose bazë të dhënash. Një magazinë të dhënash mund të bashkojë në mënyrë shumë efektive të dhëna nga aplikacione specifike si shitjet, marketingu, financat, prodhimi, duke marrë parasysh akumulimin e tyre, d.m.th. kurseni seritë kohore të treguesve kryesorë të biznesit - të ashtuquajturat të dhëna historike.
Vini re se një nga vetitë e të dhënave të mbledhura nga aplikacione të ndryshme dhe të përdorura nga analistët është aftësia për të kërkuar të dhëna të tilla. Në shumë depo të dhënash, atributi "kohë" është një kriter natyror për filtrimin e të dhënave. Analistët janë të interesuar për sjelljen e serive kohore të të dhënave që karakterizojnë proceset e biznesit.
Qëllimi i shumë njerëzve sistemet e ruajtjes së të dhënaveështë një rishikim vit pas viti i aktiviteteve. Për shembull, ju mund të krahasoni shitjet gjatë tremujorit të parë të këtij viti me shitjet gjatë tremujorit të parë të viteve të mëparshme. Koha në HD është një atribut themelor pyetje të kryqëzuara. Për shembull, një analist mund të përpiqet të vlerësojë ndikimin e një fushate të re marketingu që po zhvillohet gjatë periudha të caktuara duke marrë parasysh shitjet gjatë të njëjtave periudha. Aftësia për të vendosur dhe kuptuar korrelacionin midis aktiviteteve të departamenteve të ndryshme në një organizatë përmendet shpesh si një nga argumentet më të rëndësishme në lidhje me përfitimet e sistemet e ruajtjes së të dhënave.
Sistemi i ruajtjes së të dhënave jo vetëm që mund të funksionojë si një platformë efikase për konsolidimin e të dhënave nga burime të ndryshme, por gjithashtu mund të mbledhë versione të shumta të të dhënave nga një aplikacion i vetëm. Për shembull, nëse organizata ka kaluar në softuer të ri, atëherë depoja e të dhënave do të ruajë të dhënat e nevojshme nga sistemi i mëparshëm. Në këtë aspekt sistemi i ruajtjes së të dhënave mund të shërbejë si një mjet për integrimin e të dhënave të trashëguara, duke ruajtur vazhdimësinë e analizave gjatë ndryshimit të platformës harduerike dhe softuerike të sistemit OLTP.
Dallimet midis përpunimit të të dhënave transaksionale dhe analitike
Një nga arsyet më të rëndësishme për ndarjen e të dhënave për analizë nga të dhënat për sistemet OLTP ishte rënia e mundshme e performancës së përpunimit të pyetjeve gjatë ekzekutimit të proceseve të analizës së të dhënave. Performancë e lartë dhe kohët e shkurtra të përgjigjes janë parametra kritikë të sistemeve OLTP. Dënimi i performancës dhe shpenzimet e përgjithshme të lidhura me përpunimin e pyetjeve të paracaktuara zakonisht janë të lehta për t'u vlerësuar. Nga ana tjetër, pyetjet për analizimin e të dhënave në një magazinë të dhënash janë të vështira për t'u parashikuar, dhe për këtë arsye, është e vështirë për ta të vlerësojnë kohën e ekzekutimit të pyetjes.
Sistemet OLTP janë të dizajnuara për të ekzekutuar në mënyrë optimale pyetjet e paracaktuara në një mënyrë funksionimi pothuajse në kohë reale. Për sisteme të tilla, zakonisht është e mundur të përcaktohet shpërndarja e ngarkesës me kalimin e kohës, të përcaktohet koha e ngarkesave të pikut, të vlerësohen pyetjet kritike dhe të zbatohen procedurat e optimizimit të mbështetura nga DBMS moderne për to. Është gjithashtu relativisht e lehtë të përcaktohet maksimumi koha e lejuar përgjigje ndaj kërkesë specifike në sistem. Kostoja e kohës së përgjigjes për një kërkesë të tillë mund të vlerësohet në bazë të raportit të kostos së kryerjes së operacioneve I / O / kostos së trafikut në rrjet. Për shembull, për një sistem të përpunimit të porosive, mund të specifikoni numrin e menaxherëve aktivë të porosive dhe numrin mesatar të porosive gjatë çdo ore funksionimi.
Edhe pse shumë nga pyetjet dhe raportet në sistemi i ruajtjes së të dhënave janë të paracaktuara, është pothuajse e pamundur të parashikohet me saktësi sjellja e metrikës së sistemit (koha e reagimit, trafiku i rrjetit, etj.) kur ato ekzekutohen. Procesi i kërkimit të të dhënave në një magazinë të dhënash shpesh ndodh në një mënyrë të paparashikueshme. Drejtuesit e të gjitha gradave dinë të bëjnë pyetje të papritura. Gjatë procesit të analizimit, mund të ndodhin pyetje ad hoc, të cilat shkaktohen nga rezultate të papritura ose nga mungesa e të kuptuarit nga përdoruesi përfundimtar i modelit të të dhënave që përdoret. Më tej, shumë nga proceset e analizës priren të marrin parasysh shumë aspekte të aktiviteteve të organizatës, ndërsa sistemet OLTP janë të segmentuara mirë sipas aktivitetit. Përdoruesi mund të ketë nevojë për më shumë informacion i detajuar se sa ruhet në tabelat përmbledhëse. Kjo mund të çojë në bashkimin e dy ose më shumë tabelave të mëdha, gjë që do të rezultojë në krijimin e një tabele të përkohshme të barabartë me produktin e numrit të rreshtave në secilën tabelë dhe do të zvogëlojë në mënyrë drastike performancën e sistemit.
Të dhënat në sistemet e magazinave të të dhënave mbeten të pandryshuara
Një tjetër veçori kryesore e të dhënave në sistemi i ruajtjes së të dhënaveështë se të dhënat në HD mbeten të pandryshuara. Kjo do të thotë që pasi të dhënat janë në depon e të dhënave, ato nuk mund të ndryshohen. Për shembull, statusi i porosisë nuk ndryshon, madhësia e porosisë nuk ndryshon, etj. Kjo karakteristikë e magazinës së të dhënave ka një rëndësi të madhe për zgjedhjen e llojeve të të dhënave gjatë vendosjes së tyre në magazinën e të dhënave, si dhe zgjedhjen e koha kur të dhënat duhet të futen në depon e të dhënave. Vetia e fundit quhet granulariteti i të dhënave.
Konsideroni se çfarë do të thotë që të dhënat të jenë të pandryshueshme. Në një sistem OLTP, objektet e të dhënave kalojnë nëpër ndryshime të vazhdueshme në atributet e tyre. Për shembull, një porosi mund të ndryshojë statusin e tij shumë herë përpara se të vendoset. Ose, kur një produkt është montuar në një linjë montimi, shumë hapa prodhimi zbatohen në të. Në përgjithësi, të dhënat nga një sistem OLTP duhet të ngarkohen në magazinën e të dhënave vetëm kur përpunimi i tyre brenda kuadrit të proceseve të biznesit ka përfunduar plotësisht. Kjo mund të nënkuptojë përfundimin e një porosie ose një cikli produkti. Pasi një porosi të jetë përfunduar dhe dërguar, nuk ka gjasa të ndryshojë statusin e saj. Ose, pasi një produkt të montohet dhe të vendoset në ruajtje, nuk ka gjasa të arrijë në fazën e parë të ciklit të montimit.
Të tjera shembull i mirë mund të ketë një fotografi të ndryshimit të vazhdueshëm të të dhënave në momente të caktuara në kohë në HD. Moduli i menaxhimit të inventarit në një sistem OLTP mund të ndryshojë inventarin pothuajse në çdo transaksion; është e pamundur të sjellësh të gjitha këto ndryshime në HD. Ju mund të specifikoni që një fotografi e tillë e statusit të inventarit duhet të futet në magazinë çdo javë ose çdo ditë, pasi do të pranohet për analizë në një organizatë të veçantë. Të dhënat e një fotografie të tillë, natyrisht, janë të pandryshueshme.
Pas futjes së të dhënave në magazinën e të dhënave, modifikimi i tyre është i mundur në raste jashtëzakonisht të rralla. Është shumë e vështirë (edhe pse ka përpjekje të tilla) të ruash të dhëna dinamike në një magazinë të dhënash. Detyrë sinkronizimi të dhënat e ndryshuara shpesh në sistemet OLTP dhe është ende larg nga një zgjidhje e pranueshme. Këtu duhet përmendur gjithashtu se vendosja e të dhënave në ndryshim dinamik në një magazinë të dhënash është aktualisht objekt i një kërkimi intensiv. Për shembull, zhvillimi i procedurave për mbështetjen e tabelave të dimensioneve që ndryshojnë ngadalë në një magazinë të dhënash është një detyrë që tashmë po zgjidhet në nivelin e softuerit të prodhuesve të zgjidhjeve në fushën e ruajtjes së të dhënave.
Të dhënat në depon e të dhënave ruhen për një kohë shumë më të gjatë sesa në sistemet OLTP
Të dhënat në shumicën e sistemeve OLTP arkivohen sapo të bëhen joaktive. Për shembull, një porosi mund të bëhet joaktive pasi të përfundojë; një llogari bankare mund të bëhet joaktive pasi të jetë mbyllur. Arsyeja kryesore për arkivimin e të dhënave në qetësi është performanca e sistemit OLTP (pse të ruhen të dhënat nëse nuk aksesohen). Sasi të mëdha të të dhënave të tilla mund të degradojnë ndjeshëm performancën e pyetjes, duke supozuar se vetëm të dhënat aktive po përpunohen. Për të përpunuar të dhëna të tilla në DBMS, ofrohen procedura të ndryshme për ndarjen e tabelave bazë në seksione. Nga ana tjetër, duke qenë se magazinat e të dhënave synohen, në veçanti, të jenë një arkiv për të dhënat OLTP, të dhënat ruhen në to për një periudhë shumë të gjatë.
Në fakt, projekti sistemet e ruajtjes së të dhënave mund të fillojë pa ndonjë plan specifik për arkivimin e të dhënave nga DW. Kostoja e ruajtjes së të dhënave pasi ato të jenë ngarkuar në magazinë është e ulët. Kostoja më e madhe e krijimit të një depoje bie mbi transformimi i të dhënave(transferimi i të dhënave) dhe pastrimi i tyre (pastrimi i të dhënave). Ruajtja e të dhënave prej pesë ose më shumë vitesh është tipike për sistemet e ruajtjes së të dhënave. Prandaj, procedurave për arkivimin e të dhënave nga depoja e të dhënave në fazat e krijimit dhe funksionimit të tyre në fillim të periudhës nuk mund t'u jepet shumë kohë. Sidomos kur merret parasysh rënia e çmimeve për pajisjet kompjuterike.
Me fjalë të tjera, ndarja e të dhënave të sistemit OLTP nga të dhënat e sistemit të analizës është një koncept themelor i ruajtjes së të dhënave. Biznesi sot është i pamundur pa marrë vendime të informuara. Zgjidhje të tilla mund të ndërtohen në bazë të një analize gjithëpërfshirëse të rezultateve të proceseve të biznesit në organizatë dhe aktiviteteve të organizatës në tregun e mallrave dhe shërbimeve. Koha e vendimmarrjes në kushtet moderne dhe flukset e informacionit është zvogëluar. Roli i krijimit dhe i mbështetjes sistemet e analizës së të dhënave bazuar në të reja teknologjitë e informacionit rritet. HD është një nga hallkat kryesore në aplikimin e teknologjive të tilla.
Mund të dallohen arsyet e mëposhtme për të ndarë të dhënat sistemet e ruajtjes së të dhënave dhe sistemet operacionale të përpunimit të të dhënave(Fig. 1.5).
- Dallimi në kërkesat e synuara për sistemet dhe OLTP.
- Nevoja për mbledhjen e të dhënave në magazinë e të dhënave nga burime të ndryshme informacioni, d.m.th. nëse të dhënat gjenerohen në vetë sistemin OLTP, atëherë për sistemet e ruajtjes së të dhënave në shumicën e rasteve të dhënat gjenerohen jashtë saj.
- Të dhënat, duke hyrë në depon e të dhënave, në shumicën e rasteve mbeten të pandryshuara.
- Të dhënat në HD ruhen për një kohë të gjatë.
Oriz. 1.5.
Transformimi logjik i të dhënave OLTP dhe modelimi i të dhënave
Të dhënat në një magazinë të dhënash transformohen logjikisht kur transferohen në të nga një sistem OLTP ose një burim tjetër i jashtëm. Problemet që lidhen me transformimin logjik të të dhënave gjatë transferimit të tyre në një magazinë të dhënash mund të kërkojnë analiza dhe përpjekje të konsiderueshme nga projektuesit. Arkitekturë sistemet e ruajtjes së të dhënave dhe modelet HD janë kritike për suksesin e projekteve të tilla. Më poshtë, do të shqyrtohen disa koncepte themelore të teorisë së bazës së të dhënave relacionale, të cilat nuk janë plotësisht të zbatueshme sistemet e ruajtjes së të dhënave. Edhe pse shumica e depove të të dhënave janë të vendosura në bazat e të dhënave relacionale, disa parime bazë të bazave të të dhënave relacionale shkelen qëllimisht kur krijohet një model logjik dhe fizik i një magazine të dhënash.
Modeli i të dhënave të një magazine të dhënash përcakton strukturën e saj logjike dhe fizike. Ndryshe nga të dhënat thjesht të arkivuara, këtë rastështë e pamundur të bëhet pa procedura të detajuara modelimi. Një modelim i tillë në fazat e hershme të dizajnit të një sistemi ruajtjeje është i nevojshëm për të krijuar një sistem efektiv që kap të dhëna nga të gjitha proceset dhe procedurat e biznesit të një organizate.
Procesi i modelimit të të dhënave duhet të strukturojë të dhënat në magazinë e të dhënave në një formë të pavarur nga modeli relacional të dhënat e sistemit që furnizon këto të dhëna. Siç do të tregohet më poshtë, modeli i magazinës së të dhënave ka të ngjarë të jetë më pak i normalizuar sesa modeli i sistemit të burimit të të dhënave OLTP.
Në sistemet OLTP, të dhënat për nënsisteme të ndryshme mund të mbivendosen ndjeshëm. Për shembull, informacioni i zhvillimit të produktit përdoret në forma të ndryshme në shumë nënsisteme të një sistemi OLTP. Sistemi i ruajtjes së të dhënave duhet të konsolidojë të gjitha këto të dhëna në një sistem. Disa atribute objektesh që janë thelbësore për një sistem OLTP do të jenë të panevojshme për një depo të dhënash. Atribute të reja mund të shfaqen ndërsa entiteti në DW ndryshon cilësinë e tij. Kërkesa kryesore është që të gjitha të dhënat në depon e të dhënave duhet të marrin pjesë në procesin e analizës.
Modeli i të dhënave të DW duhet të zgjerohet dhe strukturohet në mënyrë që të mund të shtohen të dhëna nga aplikacione të ndryshme. Një projekt i depove të të dhënave në shumicën e rasteve nuk mund të përfshijë të dhëna nga të gjitha aplikacionet e mundshme të biznesit të një organizate. Zakonisht, sasia e të dhënave në magazinën e të dhënave rritet sipas parimit të rritjes: të dhënat nxirren nga sistemet OLTP dhe shtohen në depon e të dhënave në pjesë të caktuara. Ata fillojnë duke kursyer të dhëna veçanërisht të rëndësishme, pastaj rritin sistematikisht volumin e tyre sipas nevojës.
Modeli i magazinës së të dhënave përshtatet me strukturën e biznesit
Tjetra pikë e rëndësishme qëndron në faktin se modeli logjik i magazinës së të dhënave është i akorduar me strukturën e biznesit (të fokusuar në fushën e temës), dhe jo me agregimin e modeleve logjike të aplikacioneve specifike. Subjektet (objektet) të mbështetura në magazinën e të dhënave janë të ngjashme me entitetet (objektet) e një biznesi - si klientët, produktet (mallrat), porositë dhe shpërndarësit. Brenda njësive të veçanta organizative, mund të ketë një pamje shumë të ngushtë të subjekteve afariste të organizatës, siç janë klientët. Për shembull, një ekip shërbimi kredie në një bankë mund të dijë diçka për një klient vetëm në kontekstin e një ose më shumë kredive. Një divizion tjetër i së njëjtës bankë mund të dijë për të njëjtin klient në kontekst llogaria e depozitave. Paraqitja e të dhënave të klientëve në magazinën e të dhënave është shumë më e madhe se ajo e një njësie specifike bankare. Klienti në CD përfaqëson klientin e bankës në të gjitha marrëdhëniet e tij me bankën. Nga pikëpamja e teorisë relacionale, grupi bazë i varësive funksionale të mbështetura në bazën e të dhënave po ndryshon.
Magazina e të dhënave duhet të ndërtohet mbi atributet e subjekteve afariste (të orientuara nga subjekti), duke mbledhur të dhëna për këto subjekte nga burime të ndryshme. Struktura e të dhënave e çdo burimi të vetëm të të dhënave ka të ngjarë të jetë e pamjaftueshme për një DW. sipas strukturës së të dhënave aplikim specifik ndikuar nga faktorë të tillë si:
- lloji i procesit specifik të biznesit. Po, në nënsistem i automatizuar Struktura e të dhënave të prokurimit mund të diktohet nga natyra e procedurave të biznesit të prokurimit në një sektor të caktuar tregu;
- ndikimi i modelit sistemet operative. Për shembull, aplikim origjinal mund të jetë mjaft i vjetër dhe të marrë parasysh zhvillimin e modelit të të dhënave duke ndryshuar strukturën e bazës së të dhënave të aplikacionit. Shumë ndryshime të tilla mund të dokumentohen dobët;
- kufizimet e platformës së softuerit dhe harduerit. Struktura logjike e të dhënave mund të mos mbështesë disa marrëdhënie logjike midis të dhënave ose mund të ketë kufizime të lidhura me kufizimet e platformës së softuerit dhe harduerit.
Modeli DW nuk është i kufizuar nga kufizimet e modeleve të të dhënave burimore. Për të, duhet të zhvillohet një model që pasqyron strukturën e biznesit të organizatës, dhe jo strukturën e procesit të biznesit. Të tillë model i zgjeruar të dhënat duhet të jenë të kuptueshme si për analistët ashtu edhe për menaxherët. Kështu, projektuesi i magazinës së të dhënave duhet të konfigurojë objektet e magazinës së të dhënave në strukturën e biznesit të organizatës, duke marrë parasysh proceset e saj të biznesit dhe procedurat e biznesit.
Transformimi i informacionit që përshkruan gjendjen e objekteve në një sistem OLTP
Pika tjetër e rëndësishme është se para se të vendosni të dhënat në depon e të dhënave, ato duhet të konvertohen. Shumica e të dhënave nga një sistem OLTP ose një burim tjetër i jashtëm nuk mund të mbahen në një depo të dhënash. Shumë nga atributet e objekteve në një sistem OLTP janë shumë dinamike dhe vazhdimisht ndryshojnë. Shumë nga këto atribute nuk ngarkohen në DW, ndërsa të tjerat janë statike në kohë dhe ngarkohen në DW. Magazina e të dhënave nuk duhet të përmbajë informacione për objektet që janë dinamike dhe janë vazhdimisht në gjendje modifikimi.
Për të kuptuar se çfarë do të thotë të humbasësh informacionin e përshkrimit Gjendja e tanishme objekt, merrni parasysh një shembull të një sistemi të menaxhimit të porosive që gjurmon statusin e aksioneve gjatë plotësimit të një porosie. Së pari, merrni parasysh entitetin "Order" në sistemin OLTP. Një porosi mund të kalojë nëpër shumë statuse ose gjendje të ndryshme përpara se të përfundojë dhe statusi i përfunduar. Statusi i një porosie mund të tregojë se është gati për t'u plotësuar, se porosia po plotësohet, se është kthyer për rishikim, se është gati për dërgesë, e kështu me radhë. Një porosi e veçantë mund të kalojë nëpër shumë gjendje, të cilat pasqyrohen në statusin e porosisë dhe përcaktohen nga proceset e biznesit që janë zbatuar për të. Është praktikisht e pamundur të transferohen të gjitha atributet e një objekti të tillë në depon e të dhënave. Sistemi i ruajtjes së të dhënave, ndoshta duhet të përmbajë vetëm një fotografi fundore të një objekti të tillë si një porosi. Kështu, objekti "Urdhër" duhet të konvertohet për t'u vendosur në magazinën e të dhënave. Më pas mund të mblidhen informacione për shumë objekte të llojit "porosi" në magazinën e të dhënave dhe mund të ndërtohet objekti përfundimtar i magazinës së të dhënave, "Order".
Konsideroni një shembull më kompleks transformimi i të dhënave kur menaxhoni një stok mallrash në një sistem OLTP. Stoku mund të ndryshojë në çdo transaksion. Sasia e një produkti të caktuar në magazinë mund të zvogëlohet me transaksionin e nënsistemit të plotësimit të porosisë ose të rritet kur produkti i blerë të mbërrijë. Nëse sistemi i përpunimit të porosive kryen dhjetëra mijëra transaksione në ditë, atëherë ka të ngjarë që niveli aktual i inventarit në bazën e të dhënave të ketë shumë gjendje dhe të kapet në shumë fotografi gjatë asaj dite. Është e pamundur të kryhen të gjitha këto ndryshime të përhershme në bazën e të dhënave dhe t'i transferohen ato në depon e të dhënave. Shfaqja e kësaj sjelljeje të një objekti në sistem - burimi i të dhënave është ende një nga problemet e pazgjidhura në sistemet e ruajtjes së të dhënave. Ka një sërë qasjesh për zgjidhjen e këtij problemi. Për shembull, mund të kapni periodikisht fotografi të nivelit të inventarit në magazinë.
Kjo qasje mund të aplikohet në një pjesë shumë të madhe të të dhënave në sistemet OLTP. Nga ana tjetër, një vendim i tillë do të sjellë një sërë detyrash që lidhen me zgjedhjen e periudhës kohore, sasinë e të dhënave që do të kapen, etj. Kështu, shumica e të dhënave për gjendjen e objekteve në sistemin OLTP nuk mund të transferohen drejtpërdrejt në depon e të dhënave. Ato duhet të konvertohen në nivelin logjik.
Denormalizimi i modelit të të dhënave
Pika tjetër në hartimin e magazinave të të dhënave relacionale është të vendosni se sa e rëndësishme është në një magazinë të dhënash të përputhet me parimet e teorisë relacionale, përkatësisht: të lejojë denormalizimin e modelit, në veçanti, për të rritur performancën e pyetjes. Përpara se të shikojmë denormalizimin e një modeli të dhënash në kontekstin e ruajtjes së të dhënave, le të shqyrtojmë shkurtimisht pikat kryesore të teorisë së bazës së të dhënave relacionale dhe procesi i normalizimit. E.F. Codd zhvilloi teorinë e bazës së të dhënave relacionale në fund të viteve 1960 ndërsa punonte në një qendër kërkimore të IBM. Sot, platformat më të njohura të bazës së të dhënave ndjekin plotësisht këtë model. Modeli i bazës së të dhënave relacionale është një koleksion tabelash dydimensionale të përbërë nga rreshta dhe kolona. Në terminologjinë e modelit relacional, këto tabela, rreshta dhe kolona quhen përkatësisht relacione ose entitete, tuples, atribute (atribut) dhe domene (domain). Modeli identifikon çelësat unikë (Key) për të gjitha tabelat dhe përshkruan marrëdhëniet ndërmjet tabelave përmes vlerave të atributeve (çelës).
Normalizimi është një proces modelimi i bazës së të dhënave relacionale ku marrëdhëniet ose tabelat ndahen derisa të gjitha atributet në një relacion të përcaktohen plotësisht nga çelësi i tij primar. Shumica e stilistëve përpiqen të arrijnë formën e tretë normale (3NF) në të gjitha marrëdhëniet përpara se të çnormalizohen për një arsye ose një tjetër. Tre fazat e njëpasnjëshme të normalizimit të bazës së të dhënave relacionale janë përshkruar shkurtimisht më poshtë.
- Forma e parë normale 1NF (1NF). Një lidhje thuhet se është në formën e parë normale nëse përshkruan një entitet të vetëm dhe nuk përmban vargje ose grupe vlerash që përsëriten si atribute. Për shembull, një tabelë porosie që përfshin artikuj porosie nuk do të jetë në formën e parë normale sepse përmban atribute të kopjuara për çdo artikull porosie.
- Forma e dytë normale 2NF (2NF). Thuhet se marrëdhënia është në forma e dytë normale nëse është në formën e parë normale dhe të gjitha atributet jo kyçe varen plotësisht nga funksioni çelësi kryesor i marrëdhënies.
- forma e tretë normale 3NF (3NF). Thuhet se marrëdhënia është në forma e tretë normale nëse është në forma e dytë normale dhe atributet e tij jo kyçe janë plotësisht të pavarura nga njëra-tjetra.
Procesi i normalizimit rezulton në ndarjen e marrëdhënies origjinale në disa marrëdhënie të pavarura. Çdo relacion në bazën e të dhënave përgjigjet nga të paktën një tavolinë. Ndërsa modeli relacional është më fleksibël në paraqitjen e të dhënave, ai mund të jetë më kompleks dhe i vështirë për t'u kuptuar. Gjithashtu, një model plotësisht i normalizuar mund të jetë shumë joefikas për t'u zbatuar. Prandaj, projektuesit e bazës së të dhënave, kur konvertojnë një normalizuar modeli logjik në modelin fizik lejojnë denormalizim të konsiderueshëm. Qëllimi kryesor i denormalizimit është të kufizojë lidhjet ndërmjet tabelave në pyetje.
Një arsye tjetër për denormalizimin e modelit HD është, ashtu si për sistemet operative, performanca dhe thjeshtësia. Çdo pyetje në një bazë të dhënash relacionale ka performancën e vet të kostos. Kostoja e ekzekutimit të pyetjeve është shumë e lartë në magazinën e të dhënave për shkak të sasisë së të dhënave të përpunuara në pyetje (dhe bashkimeve ndër-tabelore, numri i të cilave rritet në raport me dimensionin e modelit). Bashkimi i tre tabelave të vogla në një sistem OLTP mund të ketë një kosto të pranueshme kërkimi, por sistemi i ruajtjes së të dhënave krijimi i një lidhjeje të tillë mund të marrë një kohë shumë të gjatë.
Marrëdhëniet statike në të dhënat historike
Denormalizimi është proces i rëndësishëm në modelimin e magazinës së të dhënave: marrëdhënia midis atributeve nuk ndryshon për të dhënat historike. Për shembull, në sistemet OLTP, një produkt mund të jetë pjesë e një produkti tjetër në grupin "A" këtë muaj dhe pjesë e një produkti në grupin "B" muajin tjetër. Në një model të normalizuar të dhënash, për të shfaqur këtë fakt, është e nevojshme të përfshihet atributi "grup mallrash" në relacionin (entitet) "produkt", por jo në relacionin (entitet) "porosi", i cili gjeneron porosi për këtë. produkt. Vetëm identifikuesi i produktit përfshihet në entitetin "porosi". Teoria relacionale do të kërkonte një bashkim midis tabelave "Rendi" dhe "Artikulli" për të përcaktuar grupin e produkteve dhe atributet e tjera të atij produkti. Ky fakt ( varësia funksionale) nuk ka rëndësi për magazinën e të dhënave, pasi të dhënat e ruajtura u referohen porosive tashmë të përfunduara, d.m.th. përkatësia e produktit në grup tashmë është fiksuar (në fakt, varësia funksionale e specifikuar nuk mbështetet). Edhe nëse sendi i përkiste grupe të ndryshme në periudha të ndryshme, marrëdhënia midis grupit të produkteve dhe produktit të çdo porosie individuale është statike. Pra, ky nuk është një denormalizim për një DW. Në këtë rast, varësia funksionale e sistemit OLTP nuk përdoret në depon e të dhënave.
Si shembull tjetër, merrni çmimin e një malli. Çmimet në sistemin OLTP mund të ndryshojnë vazhdimisht. Disa nga këto ndryshime çmimesh mund të transferohen në magazinën e të dhënave si pamje periodike të tabelës "Çmimi i produktit". Në magazinën e të dhënave, historiku i listës së çmimeve të produktit është i fiksuar dhe tashmë është i lidhur me porositë, d.m.th. nuk ka nevojë të përcaktohet në mënyrë dinamike lista e çmimeve gjatë përpunimit të porosisë, pasi ajo tashmë është aplikuar në porosinë e ruajtur. Në bazat e të dhënave relacionale, është më e lehtë të mbahen marrëdhënie dinamike ndërmjet subjekteve të biznesit, ndërsa një depo e të dhënave përmban marrëdhënie ndërmjet entitete domeni në kohën e dhënë.
Koncepti konvertim logjik të dhënat e aplikacionit burimor, të diskutuara më sipër, kërkojnë disa përpjekje për t'u zbatuar dhe janë shumë të dobishme kur zhvillohet një magazinë të dhënash.
Transformimi fizik i të dhënave të aplikacionit burimor
Një pikë e rëndësishme në sistemet e ruajtjes së të dhënaveështë transformimi fizik i të dhënave. Këto procedura në magazinimin e të dhënave njihen si procese "pastrimi i të dhënave", "stabilizimi i të dhënave" ose "pastrimi i të dhënave". Procesi i pastrimit të të dhënave është më intensivi dhe kërkon kohë në çdo projekt të depove të të dhënave. Transformimi fizik përfshin përdorimin e termave standarde të domenit të të dhënave dhe standardeve të të dhënave. Gjatë procesit të transformimit fizik, të dhënat janë në një skedar të ndërmjetëm përpara se të futen në depon e të dhënave. Kur të dhënat mblidhen nga shumë aplikacione, integriteti i tyre mund të kontrollohet gjatë procesit të transformimit përpara se të ngarkohen në depon e të dhënave.
Termat dhe emrat atributet e entitetit, të përdorura në sistemet OLTP, në procesin e konvertimit të të dhënave për magazinat e të dhënave shndërrohen në universale, termat standarde pranuar për këtë fushë të biznesit. Aplikacionet mund të përdorin shkurtesa ose terma të vështirë për t'u kuptuar për shumë arsye të ndryshme. Platforma e softuerit dhe harduerit mund të kufizojë gjatësinë dhe formatin e emrave, dhe aplikacionet e biznesit mund të përdorin terma të përbashkëta në fusha të ndryshme lëndore. Në një depo të dhënash, ju duhet të përdorni terma standardë të biznesit që janë vetë-shpjeguese për shumicën e përdoruesve.
Identifikuesi i klientit (klientit) në sistemin OLTP mund të emërtohet "Blerje", "idr_blerëse" ose "blerje_për". Më tej, aplikacione të ndryshme të sistemeve të tilla mund të përdorin emra (sinonime) të ndryshëm kur i referohen të njëjtit atribut entiteti. Projektuesi i magazinës së të dhënave zgjedh një term të thjeshtë standard biznesi si "ID-ja e klientit". Pra, emrat atributet e entitetit nga sistemet e furnizimit duhet të unifikohen për përdorim në CD.
Nënsistemet e ndryshme të sistemeve OLTP dhe burimet e jashtme të të dhënave mund të përdorin përkufizime të ndryshme të domeneve të atributeve në shtresa e prezantimit. Kështu, një atribut i tipit "identifikues i produktit" në një sistem ka një gjatësi prej 12 karakteresh, dhe në një tjetër - 18 karaktere. Nga ana tjetër, disa sisteme softuerike ekzistuese mund të kenë kufizime në përcaktimin e gjatësisë së emrave të atributeve dhe një grup të dobët llojesh për përcaktimin e domeneve, ndërsa të tjerët mund të mos kenë kufizime të tilla dhe mund të ofrojnë një përzgjedhje të gjerë të llojeve të atributeve.
Kur përcaktohen atributet në një model fizik të një magazine të dhënash, është e nevojshme të përdoren gjatësi dhe lloje të tilla të dhënash në përcaktimin e një domeni atributi që do të lejonte marrjen parasysh si kërkesat e fushës së temës ashtu edhe aftësitë e sistemeve të burimit të të dhënave. Përcaktimi i standardeve të domenit për DW-të është një nga detyrat e rëndësishme të projektuesve të DW. Rregullat për konvertimin e domeneve të atributeve të sistemeve të burimit të të dhënave në domene të atributeve të magazinës së të dhënave duhet të regjistrohen në meta të dhënat e magazinës së të dhënave.
Të gjitha atributet në një magazinë të dhënash duhet të përdorin vazhdimisht vlera të paracaktuara. Aplikacione të ndryshme mund të miratojnë konventa të ndryshme për vlerat e paracaktuara të atributeve. Këto vlera të paracaktuara përfshijnë vlerat e paracaktuara, vlerat që zëvendësojnë vlerat null etj. Për shembull, gjinia në sisteme të ndryshme mund të kenë vlera të ndryshme: në disa, këto janë vlerat e karaktereve "M" dhe "F", në të tjera, vlerat numerike 0 dhe 1. Një shembull më i pakëndshëm është rasti kur një vlerë e të dhënave përdoret në një aplikim për disa qëllime, dmth atributi në fakt përfaqëson një vlerë shumësi. Për shembull, kur në atributin "lloji i metodës së matjes" dy shifrat e para nënkuptojnë metodën e matjes, dhe dy të dytat - metodën e kontrollit fizik të matjes. Vlera të tilla të ndryshme duhet të konvertohen në një vlerë të paracaktuar të pranuar nga DW përpara se të ngarkohen në DW.
Në disa sisteme të burimit të të dhënave, vlerat mund të mungojnë (problemi i vlerës së munguar, "të dhënat që mungojnë") ose transformimi për to nuk mund të kryhet ("të dhëna të korruptuara" - të dhëna për të cilat transformimi nuk mund të kryhet). Është e rëndësishme që gjatë procesit të transformimit të dhëna të tilla të marrin vlera në magazinën e të dhënave që do t'i lejojnë përdoruesit t'i interpretojnë ato në mënyrë korrekte. Disa atributeve thjesht mund t'u caktohet një vlerë e arsyeshme e paracaktuar në rast të mungesës së vlerave ose konflikteve në konvertim, dhe atributeve të tjera mund t'u caktohen vlera nga vlerat e atributeve të tjera. Për shembull, le të themi se në entitetin "Order", vlera e atributit të njësisë matëse të artikullit është hequr. Kjo vlerë mund të merret nga atributi përkatës i entitetit Mall të këtij sistemi burimor. Për disa atribute, nuk ka vlera të përshtatshme të paracaktuara kur vlerat e tyre mungojnë. Për vlera të tilla që mungojnë në depon e të dhënave, duhet të përcaktoni gjithashtu një vlerë të paracaktuar, për shembull, si vlerë null.
Dallimet kryesore në përdorimin e të dhënave në
Dëshira për të kombinuar aftësitë e sistemeve OLTP dhe sistemeve të analizës në një arkitekturë DSS ka çuar në shfaqjen e konceptit XrandhelkerkojdanneX (HD).
Koncepti i HD-së u diskutua në një mënyrë apo tjetër nga specialistë të fushës së informacionit
sistemet e bashkimit për një kohë të gjatë. U shfaqën artikujt e parë kushtuar posaçërisht HD-së
në 1988, autorët e tyre ishin B. Devlin dhe P. Murphy. Në vitin 1992, W. Inmon e përshkroi këtë koncept në detaje në monografinë e tij "Building the Data Warehouse", botimi i dytë - QED Publishing Group, 1996.
Koncepti i ruajtjes së të dhënave bazohet në idenë e ndarjes së të dhënave të përdorura për të
përpunimi operacional dhe për zgjidhjen e problemeve të analizës. Kjo ju lejon të aplikoni struktura të dhënash që plotësojnë kërkesat për ruajtjen e tyre, duke marrë parasysh përdorimin në sistemet OLTP dhe sistemet e analizës. Kjo ndarje ju lejon të optimizoni të dyja strukturat e të dhënave të ruajtjes në internet (bazat e të dhënave on-line, skedarët, tabelat, etj.) për kryerjen e operacioneve të hyrjes, modifikimit, fshirjes dhe kërkimit, dhe strukturat e të dhënave të përdorura për analiza (për kryerjen e pyetjeve analitike). Në DSS, këto dy lloje të dhënash quhen përkatësisht O P e R a T dhe v n s m dhe dhe Me T O h n dhe për të a m dhe d a tani X (OID) dhe XRaasldheSCHemdannsX.
Në punën e tij, Inmon dha përkufizimin e mëposhtëm të HD.
X ra as l dhe SCH e d a n n s X - specifike për domenin, të integruar,
grup i pandryshueshëm, i ruajtur kronologjikisht i të dhënave të organizuara për qëllime të mbështetjes së vendimeve.
Le të shqyrtojmë vetitë e HD në më shumë detaje.
PRnjësimeTnoh ohrienTaqiUnë jam. Ky është ndryshimi themelor midis HD dhe OID.
OID të ndryshëm mund të përmbajnë të dhëna që përshkruajnë të njëjtën fushë lëndore nga këndvështrime të ndryshme (për shembull, nga pikëpamja e kontabilitetit, menaxhimit të magazinës, departamentit të planifikimit, etj.). Një vendim i marrë në bazë të vetëm një këndvështrimi mund të jetë i paefektshëm apo edhe i gabuar. Depot e të dhënave ju lejojnë të integroni informacione që pasqyrojnë këndvështrime të ndryshme për të njëjtën fushë lëndore.
Orientimi i subjektit gjithashtu ju lejon të ruani në depon e të dhënave vetëm ato të dhëna që
nevojiten për analizën e tyre (për shembull, nuk ka kuptim që analizat të ruajnë informacione për numrin e dokumenteve të shitjes, ndërsa përmbajtja e tyre - sasia, çmimi i mallrave të shitura - janë të nevojshme). Kjo ul ndjeshëm koston e mediave të ruajtjes dhe rrit sigurinë e aksesit të të dhënave.
DHEnTegraqiunë jam. OID, si rregull, zhvillohen në periudha të ndryshme nga disa ekipe me mjetet e tyre. Kjo çon në faktin se të dhënat që pasqyrojnë të njëjtin objekt të botës reale në sisteme të ndryshme e përshkruajnë atë ndryshe. Integrimi i detyrueshëm i të dhënave në depon e të dhënave ju lejon të zgjidhni këtë problem duke i sjellë të dhënat në një format të vetëm. NgaddeRmirëpër tëaXROnologee. Të dhënat në OID janë të nevojshme për të kryer operacione në to në kohën aktuale. Prandaj, ato mund të mos jenë të lidhura me kohën. Për analizën e të dhënave, shpesh është e rëndësishme të jeni në gjendje të gjurmoni kronologjinë e ndryshimeve në metrikat e domenit. Prandaj, të gjitha të dhënat e ruajtura në depon e të dhënave duhet të korrespondojnë me intervale kohore të njëpasnjëshme. Hedhegpenunë jamemoMeTb. Kërkesat OID vendosin kufij kohorëruajtjen e të dhënave në to. Ato të dhëna që nuk nevojiten për përpunimin në internet, si rregull, hiqen nga OID për të zvogëluar burimet e zëna. Për analizë, përkundrazi, kërkohen të dhëna për periudhën më të madhe të mundshme. Prandaj, ndryshe nga OID, të dhënat në HD pas ngarkimit lexohen vetëm. Kjo ju lejon të rrisni ndjeshëm shpejtësinë e aksesit në të dhëna, si për shkak të tepricës së mundshme të informacionit të ruajtur, ashtu edhe për shkak të eliminimit të operacioneve të modifikimit.
Kur zbatohet koncepti DSS në DSS, të dhënat nga OID të ndryshme kopjohen në një memorie të vetme. Të dhënat e mbledhura sillen në një format të vetëm, të koordinuara dhe të përmbledhura.Kërkesat analitike i drejtohen magazinës së të dhënave (Fig. 1).
Një model i tillë çon në mënyrë të pashmangshme në dyfishimin e informacionit në OID dhe në magazinën e të dhënave.
Sidoqoftë, Inmon argumenton në punën e tij se teprica e të dhënave të ruajtura në
DSS nuk kalon 1%! Kjo mund të shpjegohet me arsyet e mëposhtme.
Kur ngarkoni informacionin nga OID në depon e të dhënave, të dhënat filtrohen. Shumë prej tyre nuk hyjnë në CD, sepse janë të pakuptimta nga pikëpamja e përdorimit të tyre në procedurat e analizës.
Informacioni në OID është, si rregull, në natyrë operacionale, dhe të dhënat kanë humbur
rëndësia janë hequr. Në të kundërt, informacioni historik ruhet në një depo të dhënash. Nga ky këndvështrim, dyfishimi i përmbajtjes së CD-së nga të dhënat e OID rezulton të jetë shumë i parëndësishëm. Depoja e të dhënave ruan informacione të përgjithësuara që nuk janë në OID.
Gjatë ngarkimit në depon e të dhënave, të dhënat pastrohen (hiqen informacionet e panevojshme) dhe
pas një përpunimi të tillë, ato zënë një vëllim shumë më të vogël.
Nënsistemi i hyrjes (OLTP)
P o d s i s t e m
Pyetje analitike
P o d s i s t e m
O p e r a t o
Nënsistemi i hyrjes (OLTP)
dhe analiza
RdheMenënOpër të7. Struktura DSS me një depo fizike të të dhënave
Teprica e informacionit mund të reduktohet në zero duke përdorur një magazinë virtuale të të dhënave. Në këtë rast, ndryshe nga depoja e të dhënave klasike (fizike), të dhënat nga OID nuk kopjohen në një ruajtje të vetme. Ato nxirren, transformohen dhe integrohen drejtpërdrejt gjatë ekzekutimit të pyetjeve analitike në RAM-in e kompjuterit. Në fakt, këto kërkesa i drejtohen drejtpërdrejt OID-it (Fig. 2). Përparësitë kryesore të ruajtjes virtuale janë:
minimizimi i sasisë së memories së zënë nga informacioni në media; duke punuar me të dhëna aktuale, të detajuara.Nënsistemi i hyrjes (OLTP)
Nënsistemi i hyrjes (OLTP)
Nënsistemi hyrës
Nënsistemi i ruajtjes së informacionit
Pyetje analitike
Nënsistemi i analizës (OLAP,
O p e r a t o
V i r t u a l n o e
R dhe Me në n O për të 8. S p r u c t u r e
Sidoqoftë, kjo qasje ka shumë disavantazhe.
Koha e përpunimit të kërkesave në sistemin e ruajtjes virtuale tejkalon ndjeshëm atë përkatëse
Treguesit përkatës për ruajtjen fizike.Përveç kësaj, strukturat e bazave të të dhënave operative, të krijuara për përditësimin intensiv të të dhënave të vetme, janë shumë të normalizuara. Për të ekzekutuar një pyetje analitike, duhet të bashkohen një numër i madh tabelash, gjë që gjithashtu çon në një ulje të performancës.
Një pamje e integruar e ruajtjes virtuale është e mundur vetëm nëse plotësohet kushti i disponueshmërisë së vazhdueshme të të gjitha OID-ve. Kështu, mosdisponueshmëria e përkohshme e të paktën një prej burimeve mund të çojë ose në dështimin e pyetjes analitike ose në rezultate të pasakta.
Ekzekutimi i pyetjeve komplekse analitike në OID kërkon burime të rëndësishme kompjuterike. Kjo çon në një ulje të performancës së sistemeve OLTP, gjë që është e papranueshme, pasi koha e ekzekutimit të operacioneve në sisteme të tilla është shpesh shumë kritike.
DID të ndryshëm mund të mbështesin formate dhe kodime të ndryshme të të dhënave. shpeshherë
E njëjta pyetje mund të ketë përgjigje të shumta. Kjo mund të lidhet me:
mossinkronizimi i momenteve të përditësimit të të dhënave në OID të ndryshëm; dallimet në përshkrimin e objekteve dhe ngjarjeve identike të fushës lëndore; gabime në hyrje; humbja e fragmenteve të arkivit etj.Në këtë rast, qëllimi - formimi i një pamje të vetme të qëndrueshme të objektit të kontrollit - mund të mos arrihet.
Disavantazhi kryesor i ruajtjes virtuale duhet të njihet si praktik
pamundësia për të marrë të dhëna për një periudhë të gjatë kohore. Në mungesë të ruajtjes fizike, janë të disponueshme vetëm të dhënat që janë në DID në momentin e kërkesës. Qëllimi kryesor i sistemeve OLTP është përpunimi operacional i të dhënave aktuale, kështu që ato nuk janë të fokusuara në ruajtjen e të dhënave për një periudhë të gjatë kohore. Ndërsa të dhënat bëhen të vjetruara, ato ngarkohen në arkiv dhe hiqen nga baza e të dhënave operative.
Megjithë avantazhet e një HD fizik ndaj atij virtual, është e nevojshme
pranojnë se zbatimi i tij është një proces mjaft i mundimshëm.
Le të ndalemi në problemet kryesore të krijimit të një depoje të të dhënave:
nevoja për të integruar të dhënat nga burime heterogjene në dis-mjedis i kufizuar;
nevoja për ruajtjen dhe përpunimin efikas të sasive shumë të mëdha të informacionit; nevoja për drejtori të meta të dhënave me shumë nivele; Okërkesat e rritura për sigurinë e të dhënave. Le t'i hedhim një vështrim më të afërt këtyre çështjeve.
hollësisht.
HerrethXOddhemoMeTbnëTegraqidhedannsdhehneOdnOROdnsdheMeTOhNickovvRaMe- etjushqimlennOhMeRushqim. Depot e të dhënave janë krijuar për të integruar të dhëna që mund të vijnë nga OID heterogjene të vendosura fizikisht në kompjuterë të ndryshëm: bazat e të dhënave, arkivat elektronike, katalogët elektronikë publikë dhe komercialë, drejtoritë, koleksionet statistikore. Kur krijoni një depo të dhënash, duhet të zgjidhet problemi i ndërtimit të një sistemi që funksionon në bashkëpunim me mjete dhe zgjidhje heterogjene softuerike. Kur zgjidhni një mjet për zbatimin e një depoje të dhënash, duhet të merren parasysh shumë faktorë, duke përfshirë nivelin e përputhshmërisë së komponentëve të ndryshëm të softuerit, lehtësinë e zhvillimit dhe përdorimit të tyre, efikasitetin e funksionimit, etj.
NgaTRebnOMeTbvuhffepër tëTdhevnohmXRaneasdhedheObRoseTpër tëeOChenbbolbshdheXrrethbelëvizjenëfORmacdhedhe. Vetia e pandryshueshmërisë së HD nënkupton akumulimin e informacionit në të për një periudhë të gjatë kohore, e cila duhet të mbështetet nga një rritje e vazhdueshme e vëllimit të memories së diskut. Orientimi në ekzekutimin e pyetjeve analitike dhe denormalizimi përkatës i të dhënave çojnë në një rritje jolineare të sasisë së memories së zënë nga HD me një rritje të sasisë së të dhënave. Studimet e bazuara në grupin e testeve TPC-D kanë treguar se një bazë të dhënash 100 GB kërkon 4,87 herë më shumë sasinë e memories që nevojitet për të ruajtur të dhënat e dobishme.
HerrethXOddhemoMeTb mnOGOURovnedaljeMeetjavohNickov meTadannsX. Për sistemet e analizës, disponueshmëria e meta të dhënave të avancuara (të dhëna për të dhënat) dhe mjetet e ofrimit të tyre për përdoruesit përfundimtarë është një nga kushtet kryesore për zbatimin e suksesshëm të një magazine të dhënash. Metadatat janë të nevojshme që përdoruesit e DSS të kuptojnë strukturën e informacionit në bazë të së cilës merret vendimi. Për shembull, përpara se një menaxher i korporatës t'i bëjë sistemit pyetjen e tij, ai duhet të kuptojë se çfarë informacioni është i disponueshëm, sa i përditësuar është, nëse mund t'i besohet, sa kohë mund të marrë për të gjeneruar një përgjigje, etj. Kur krijoni një depo të dhënash, është e nevojshme të zgjidhni problemet e ruajtjes dhe paraqitjes së përshtatshme të meta të dhënave për përdoruesit.
PovysheaseTRebovaasthpër tëbezoPaMenOMeTdhedannsX. U mblodhën së bashku dhe
informacioni i publikuar për historinë e korporatës, sukseset dhe dështimet e saj, për marrëdhëniet me furnitorët dhe klientët, për historinë dhe gjendjen e tregut, bën të mundur analizimin e aktiviteteve të kaluara dhe aktuale të korporatës dhe ndërtimin e parashikimeve për të ardhmen. Natyrisht, një informacion i tillë është konfidencial dhe aksesi në të është i kufizuar brenda vetë kompanisë, për të mos përmendur kompanitë e tjera. Për të siguruar sigurinë e të dhënave, është e nevojshme të zgjidhen çështjet e vërtetimit të përdoruesit, mbrojtjen e të dhënave kur ato zhvendosen në ruajtje
të dhënat nga bazat e të dhënave operative dhe burimet e jashtme, mbrojtja e të dhënave gjatë transmetimit të tyre në rrjet etj.
Ju mund të ulni koston e krijimit të një magazine të dhënash duke krijuar të thjeshtuar
opsioni - data mart (Data Mart).
V dhe T R në a d a n ne X (VD) - ky është një version i thjeshtuar i HD, që përmban vetëm temën-
të dhëna të kombinuara në mënyrë tike.
VD është sa më afër përdoruesit përfundimtar dhe përmban të dhëna,
fokusuar tematikisht në të (për shembull, një PD për punonjësit e departamentit të marketingut mund të përmbajë të dhënat e nevojshme për analizën e marketingut). AB është shumë më i vogël në vëllim se AK dhe zbatimi i tij nuk kërkon shpenzime të mëdha. Ato mund të zbatohen si në mënyrë të pavarur ashtu edhe së bashku me HD.
IA-të e pavarura (Figura 3) shpesh shfaqen në një organizatë historikisht dhe gjenden në organizata të mëdha me një numër të madh departamentesh të pavarura që zgjidhin problemet e tyre analitike.
dizenjimi i VD për përgjigjet e një game të caktuar pyetjesh; futja e shpejtë e trafikut ajror autonom dhe marrja e kthimeve; thjeshtimi i procedurave për plotësimin e VD dhe rritja e produktivitetit të tyre duke marrë parasysh nevojat e një game të caktuar përdoruesish.Nënsistemi i hyrjes (OLTP)
Nënsistemi i hyrjes (OLTP)
Nënsistemi i ruajtjes së informacionit
Pyetje analitike
Pyetje analitike
Nënsistemi i analizës (OLAP,
P o d s i s t e m
O p e r a t o
Nënsistemi i hyrjes (OLTP)
dhe analiza
RdheMenënOpër të9. Struktura e DSS me VD të pavarura
Disavantazhet e VD autonome janë:
ruajtja e shumëfishtë e të dhënave në VD të ndryshme, gjë që çon në një rritje të kostove të ruajtjes dhe probleme të mundshme që lidhen me nevojën për të ruajtur konsistencën e të dhënave; mungesa e konsolidimit të të dhënave në nivel të fushës lëndore dhe,pra - mungesa e një fotografie të vetme.
Kohët e fundit, ideja e kombinimit të HD dhe VD në
një sistem. Në këtë rast, CD-ja përdoret si burimi i vetëm i të dhënave të integruara për të gjitha IA-të (Fig. 4).
Magazina e të dhënave është një burim i vetëm i centralizuar informacioni për të gjithë fushën e lëndës, dhe VD janë nënbashkësi të të dhënave nga depoja,
organizuar për të paraqitur informacion mbi seksionet tematike të një zone të caktuar. Përdoruesit e fundit kanë mundësinë për të aksesuar të dhënat e detajuara të magazinës nëse nuk ka të dhëna të mjaftueshme në vitrinë, si dhe për të marrë një pamje më të plotë informacioni.
Përparësitë e kësaj qasjeje janë:
lehtësia e krijimit dhe mbushjes së VD, pasi mbushja vjen nga një burim i vetëm i besueshëm i standardizuar i të dhënave të pastruara - nga depoja e të dhënave; lehtësia e zgjerimit të DSS duke shtuar VD të reja; REDUKSIMI I NGARKESËS NË KRYESORE X D.Nënsistemi i hyrjes (OLTP)
Nënsistemi i ruajtjes së informacionit
Pyetje analitike
P o d s i s t e m
O p e r a t o
Nënsistemi i hyrjes (OLTP)
Nënsistemi i hyrjes (OLTP)
A n a l dhe t dhe che me k dhe e
Kërkesat HD
VD
dhe analiza
Nënsistemi i analizës (OLAP,
RdheMenënOpër të10. Struktura e DSS me CD dhe IA
Disavantazhet përfshijnë:
tepricë (të dhënat ruhen si në depon e të dhënave ashtu edhe në VD); kosto shtesë për zhvillimin e DSS me HD dhe WD.Duke përmbledhur analizën e mënyrave për të zbatuar DSS duke përdorur konceptin e ruajtjes së të dhënave, ne mund të dallojmë arkitekturat e mëposhtme të sistemeve të tilla:
DSS me HD fizike (klasike) (shih Fig. 1); DSS me magazinë virtuale të të dhënave (shih Fig. 2); DSS me VD (shih Fig. 3); DSS me HD fizik dhe me VD (Fig. 4).Në rastin e arkitekturave me HD fizik dhe/ose VD, duhet t'i kushtohet vëmendje
pyetjet e organizimit (arkitekturës) të magazinës së të dhënave dhe transferimit të të dhënave nga OID në depo të të dhënave.
Sipas Forrester Research, shumica e kompanive të mëdha po përballen problemi i radhës: grumbullohen sasi e madhe informacion që nuk përdoret kurrë. Praktikisht në çdo organizatë, ka shumë sisteme transaksionale që janë të përqendruara në përpunimin e të dhënave në internet (secila për një klasë të caktuar detyrash) dhe plotësojnë vazhdimisht shumë Baza e të dhënave. Përveç kësaj, ndërmarrjet shpesh zotërojnë sasi të mëdha informacioni të ruajtura në të ashtuquajturat. sistemet e trashëgimisë. Të gjitha këto të dhëna shpërndahen nëpër rrjete kompjuterët personalë, ruhen në mainframe, stacione pune dhe serverë. Pra, ka informacion, por ai është i shpërndarë, i paqëndrueshëm, i pastrukturuar, shpesh i tepërt dhe jo gjithmonë i besueshëm. Prandaj, në shumicën e organizatave, këto të dhëna ende nuk mund të përdoren për të marrë vendime kritike të biznesit. Koncepti i depove të të dhënave (Data Warehouse) synon të zgjidhë këtë kontradiktë.
Bill Inmon, krijuesi i konceptit, në artikullin e tij klasik "Çfarë janë dyqanet e të dhënave" (D2K Incorporated, 1996) i përkufizon dyqanet e të dhënave si "të dhëna historike specifike, të integruara, të pandryshueshme, të organizuara për të mbështetur qeverisjen". Ai e sheh ruajtjen si "burimin e vetëm dhe të vetëm të së vërtetës", "qendrën e universit" të sistemeve të mbështetjes së vendimeve (DSS). "Nga magazinat e të dhënave," shkruan ai, "informacionet rrjedhin në departamente të ndryshme, të filtruara në përputhje me cilësimet e dhëna DSS. Këto baza të veçanta të të dhënave vendimmarrëse quhen vitrinat e dyqaneve të dhëna".
Koncepti i depove të të dhënave bazohet në idenë e kombinimit të të dhënave të korporatës të shpërndara nëpër sistemet e përpunimit të të dhënave në internet, arkivat historike dhe burime të tjera të jashtme. Këto burime mund të përmbajnë të dhëna që nuk përdoren drejtpërdrejt në ODS, por janë jetike për DSS: kuadri legjislativ(përfshirë parashikimet tatimore), planet e zhvillimit degët, të dhënat statistikore, drejtoritë elektronike. Siç tregon praktika, një vendim i marrë vetëm në bazë të të dhënave të brendshme më së shpeshti rezulton i pasaktë.
Qëllimi i konceptit të magazinave të të dhënave është të sqarojë dallimet në karakteristikat e të dhënave në sistemet operative dhe analitike, të përcaktojë kërkesat për të dhënat e vendosura në magazinë, të përcaktojë parimet e përgjithshme dhe fazat e ndërtimit të saj, burimet kryesore të të dhëna, për të dhënë rekomandime për zgjidhjen e problemeve të mundshme që lindin gjatë shkarkimit, pastrimit, rakordimit, transportit dhe ngarkimit të tyre në bazën e të dhënave të ruajtjes së synuar.
Krahasimi i karakteristikave të të dhënave në sistemet e informacionit orientuar në përpunimin operacional dhe analitik të të dhënave
Karakteristike | Operative | analitike |
Frekuenca e përditësimit | Frekuencë e lartë, ne porcione te vogla | Frekuencë e ulët, pjesë të mëdha |
Burimet e të dhënave | Kryesisht e brendshme | Kryesisht e jashtme |
Vëllimet e të dhënave të ruajtura | Qindra megabajt, gigabajt | gigabajt dhe terabajt |
Mosha e të dhënave | Aktuale (për një periudhë prej disa muajsh deri në një vit) | Aktuale dhe historike (për një periudhë disavjeçare, dekadash) |
Qëllimi | Fiksimi, kërkimi në internet dhe transformimi i të dhënave | Ruajtja e të dhënave historike të detajuara dhe të grumbulluara, përpunimi analitik, parashikimi dhe modelimi |
Kërkesat themelore për të dhënat në një magazinë të dhënash
Orientimi i lëndës | Të gjitha të dhënat për një subjekt të caktuar (objekt biznesi) mblidhen (zakonisht nga shumë burime të ndryshme), pastrohen, koordinohen, plotësohen, grumbullohen dhe paraqiten në një formë të vetme të përshtatshme për përdorimin e tyre në analizën e biznesit. |
Integrimi | Të gjitha të dhënat për objekte të ndryshme biznesi bien dakord reciprokisht dhe ruhen në një ruajtje të vetme të gjerë të korporatës |
pandryshueshmëria | Të dhënat fillestare (historike), pasi janë rënë dakord, verifikuar dhe përfshirë në të përgjithshme ruajtjen e korporatës, mbeten të pandryshuara dhe përdoren ekskluzivisht në modalitetin e leximit |
Mbështetja e afatit kohor | Të dhënat janë të strukturuara në mënyrë kronologjike dhe pasqyrojnë historinë për një periudhë të mjaftueshme kohore për të përfunduar detyrat e analizës dhe parashikimit të biznesit. |
Subjekti i konceptit të depove të të dhënave nuk është analiza e të dhënave, por vetë të dhënat, pra koncepti i përgatitjes së tyre për analiza të mëtejshme. Në të njëjtën kohë, koncepti i një depoje të dhënash përcakton jo vetëm një pamje të vetme logjike të të dhënave të korporatës, por zbatimin e një burimi të vetëm të integruar të të dhënave.
Modelet e analizës së të dhënave
Pavarësisht se në konceptin e magazinës së të dhënave të formuluar nga B. Inmon, theksi vihet në vetë të dhënat dhe identifikimin më të madh të tyre. vetitë e përbashkëta, karakteristikat dhe marrëdhëniet, është e qartë se këto të dhëna duhet të përdoren në procesin e marrjes së vendimeve të biznesit në të gjitha nivelet, deri në korporata dhe ndërkorporative. Deri më sot, historikisht janë formuar dy modele kryesore të analizës së të dhënave, mbi të cilat bazohen DSS analitike ekzistuese:
1. Analiza Statike(DSS). Vetë koncepti i DSS (Sistemet e Mbështetjes së Vendimeve) në fakt përkthehet si DSS. Deri vonë, ky ishte i vetmi koncept analitik. Rezultati i funksionimit të sistemeve të tilla ishin raportet me shumë faqe të rregulluara rreptësisht, për formimin e të cilave u kryen pyetje të gjata që përpunonin sasi të mëdha të dhënash. Kërkesa të tilla mund të ekzekutoheshin për disa orë, ndonjëherë dhjetëra orë dhe madje ditë.
2. Analiza e të dhënave operative (OLAP). Autori i konceptit të OLAP (Përpunimi analitik në linjë) është Dr. E. Codd, i cili në vitin 1993 formuloi 12 kërkesa bazë për mjetet e zbatimit të OLAP. Dallimi themelor Ky model nga DSS statike tradicionale është një paraqitje konceptuale e të dhënave në formën e një kubi shumëdimensional. Në të njëjtën kohë, E. Codd tregoi të metat e mundshme të qasjes relacionale në sistemet e orientuara nga analiza e të dhënave. Qëllimi i krijimit të këtij koncepti ishte mundësia themelore për t'i ofruar përdoruesit fundor mjetet e gjenerimit, përpunimit dhe ekzekutimit të kërkesave analitike ad hoc me një kohë minimale të përgjigjes së sistemit. Nevoja për këtë koncept të ri ishte e paracaktuar nga fakti se shpesh pas marrjes së një raporti standard duke përdorur DSS, analistit kishte një pyetje të re ose duke kuptuar se vetë pyetja ishte formuluar gabimisht. Si rezultat, ai duhej për një kohë të gjatë prisni për rezultatin tjetër në mënyrë që më pas, ndoshta, të ktheheni në përsëritjen tjetër të këtij procesi.
Krahasimi i karakteristikave të analizës statike dhe dinamike
Karakteristike | Analiza Statike | Analiza dinamike |
Llojet e pyetjeve | Sa shume? Si? Kur? | Pse? Po nese?.. |
Koha e përgjigjes | I parregulluar | |
Operacione tipike | Raporti i rregulluar, diagrami | Një sekuencë e raporteve interaktive, grafikët, format e ekranit. Ndryshimi dinamik i niveleve të grumbullimit dhe pjesëve të të dhënave. |
Niveli i kërkesave analitike | ||
Lloji i ekranit | Në thelb i paracaktuar, i rregulluar | Perdorues i percaktuar |
Niveli i grumbullimit të të dhënave | Të detajuara dhe të përmbledhura | Në thelb total |
Mosha e të dhënave | Historike dhe aktuale | Historike, aktuale dhe parashikuese |
Llojet e kërkesave | Kryesisht e parashikueshme | E paparashikueshme, rast pas rasti |
Qëllimi | Përpunimi analitik i planifikuar | Analiza, modelimi dhe parashikimi multifunksional |
Sot, drejtimi OLAP është ndoshta më premtuesi për zgjidhjen e problemeve të menaxhimit analitik. Me anë të një shërbimi të krijuar posaçërisht OLAP Report, 12 kërkesat e formuluara fillimisht nga Dr. Codd u rishikuan pjesërisht dhe u plotësuan në mënyrë të konsiderueshme si me bazë ashtu edhe me aksesueshmërisë, të tilla si përzgjedhja dhe përpunimi i të dhënave që mungojnë, etj. Por thelbi i konceptit OLAP është ende paraqitje shumëdimensionale të dhëna në nivel konceptual.
Mars të dhënave
Sipas përkufizimit klasik, një Data Mart është një nëngrup i një magazine të dhënash që pasqyron specifikat e një departamenti (objekt biznesi) dhe ofron rritjen e produktivitetit. Kështu, vitrinë është lidhja në të cilën një specifik sistemi analitik për të zgjidhur gamën e problemeve të tyre. Sidoqoftë, një situatë është e mundur kur një fushë e veprimtarisë së ndërmarrjes praktikisht nuk lidhet me të tjerat, dhe është e mundur të ndërtohet tregu përkatës i të dhënave në mënyrë autonome, pa u lidhur me një ruajtje të korporatës. Pastaj vitrina do të plotësohet me të dhëna direkt nga sistemet e përpunimit të transaksioneve në internet. Marte të tilla të dhënash quhen të pavarura, në kontrast me depo klasike të të dhënave të varura dhe të rimbushura prej saj.
Në disa raste, duket e përshtatshme të vendoset një treg të dhënash në vend të një magazine të formuar plotësisht. Martet e të dhënave janë më pak kërkuese, më të lira dhe më të lehta për t'u ndërtuar, dhe bazohen në serverë më të lirë sesa në sisteme me shumë procesor. Me këtë qasje, nuk ka nevojë të përdoret e tëra sistemi i informacionit korporatat dhe mbështesin procedurat komplekse për përditësimin sinkron të të dhënave mart kur përditësohet magazina. Në të njëjtën kohë, është e nevojshme të kuptohet se me këtë qasje, mars të dhënave mund të shumohen në komplekse të tëra të bazave të të dhënave të pavarura të informacionit, dhe natyrisht do të vendoset detyra e menaxhimit të strategjive individuale të kërkimit, mirëmbajtjes dhe rikuperimit. Nga ana tjetër, ndërtimi i një magazine të vetme të korporatës bazuar në shumë tregje të pavarura të të dhënave është shumë më fitimprurëse sesa mbështetja në të dhënat e shpërndara nëpër sistemet e përpunimit të transaksioneve.
Pra, çfarë ka kuptim të përdoret: një depo e vetme, marte të dhënash të pavarura, një depo me marte të varura ose opsione të tjera? Nuk ka asnjë përgjigje universale për pyetjen e nevojës për të përdorur një ose një opsion tjetër. Në çdo rast opsioni më i mirë të përcaktuara nga kërkesat e biznesit, intensiteti i kërkesës, arkitektura e rrjetit, reagimi i kërkuar dhe kushte të tjera.
Teknologjia e zbatimit të magazinës së të dhënave
Kur ndërtoni një magazinë të dhënash, është e natyrshme të ndiqni një qasje të zhvillimit me faza. Megjithëse asnjë përshkrim i procesit të ndërtimit të një magazine të dhënash si një sekuencë fazash nuk mund të mbulojë të gjitha aspektet reagime me përdoruesit, menaxherët dhe analistët e saj të mundshëm, megjithatë, ka disa hapa bazë që zbatohen në procesin e ndërtimit të një arkitekture të ndërmarrjes:
1. Përcaktimi i nevojave të përdoruesve fundorë dhe ndërtimi i një modeli të pyetjeve të biznesit që duhet të përgjigjen.
2. Identifikimi i të dhënave nga burime të korporatave dhe të jashtme që do të fuqizojnë magazinën e të dhënave ose tregun e të dhënave.
3. Analiza e burimeve të të dhënave dhe modelimi i funksioneve dhe proceseve që mbulojnë këto burime. Mësimi i rregullave me të cilat funksionon një biznes është një nga kushtet thelbësore ndërtimi i depove ose i të dhënave marts, pasi në bazë të tij vendoset niveli i detajimit të elementeve në magazinë e të dhënave.
4. Përcaktimi i procedurave për transformimin, pastrimin dhe integrimin logjik të të dhënave burimore përpara se ato të vendosen në një magazinë të dhënash ose data mart, si dhe rregullimi i zbatimit të këtyre procedurave që përditësojnë magazinën e të dhënave.
5. Krijimi i meta të dhënave që përshkruajnë burimet dhe metodat e transformimit të të dhënave dhe logjikën e magazinës së të dhënave. Depoja e meta të dhënave duhet të përfshijë përkufizimet e të dhënave, rregullat e biznesit dhe logjikën e detajuar për të modeluar zhvillimin e sistemeve analitike.
6. Formimi i tabelave fizike të magazinës së të dhënave dhe plotësimi i saj. Ky proces mund të kërkojë disa përsëritje, duke marrë parasysh ridizajnimin e mundshëm të strukturave të të dhënave kur analizohet skema e ruajtjes së të dhënave.
7. Ndërtimi i një depoje të të dhënave marte, e cila do të përfshijë nëngrupe të dhënash nga magazina dhe të dhëna të para-agreguara. Pjesa e meta të dhënave do të përshkruajë se si të dhënat e papërpunuara të magazinës transformohen, grumbullohen dhe ruhen në të dhënat e të dhënave.
8. Instalimi i veglave OLAP, sistemeve të aplikimit, serverëve në internet dhe të gjitha mjetet e nevojshme dhe programet e serverit të nevojshme për aksesin, analizën dhe raportimin e të dhënave.
9. Instalimi në stacionet e punës së përdoruesit fundor të klientit software(klient "i trashë") ose shfletues që mbështesin formatet standarde të të dhënave dhe aplikacionet Java, si dhe zgjerimet e nevojshme plug-in (klient "i hollë") për aksesin e përdoruesit në të dhëna.
Pas përfundimit të procesit të krijimit të një depoje të dhënash, mund të duket se gjithçka është bërë tashmë. Në fakt, formimi i një magazine është një proces që përfshin edhe fazat e nevojshme të mbikëqyrjes dhe mirëmbajtjes së vazhdueshme të magazinës së të dhënave. Mbikëqyrja e duhur nënkupton jo vetëm ruajtjen e korrektësisë së të dhënave, por edhe sigurimin e fshehtësisë së tyre, veçanërisht nëse qasja në ruajtjen e të dhënave kryhet nëpërmjet Uebit. “Për shkak se depoja e të dhënave përmban një nga asetet më të mëdha të një ndërmarrjeje,” thotë R. Tenler, kryetar i Information Advantage, “të dhënat duhet të jenë të sigurta. Por për të realizuar vlerën e mundshme të një magazine të dhënash, një organizatë do t'i duhet t'ua ofrojë atë blerësve potencialë.
Mbajtja e një depoje të dhënash në gjendje të mirë për një kohë të gjatë është një detyrë tjetër kritike. Ky faktor bëhet veçanërisht i rëndësishëm kur numri i përdoruesve që hyjnë në sistem fillon të rritet. Në të njëjtën kohë, nëse është në procesin e projektimit të një magazine të dhënash shërbimet e informacionit zakonisht një i plotë pajtimi të dhënat, me kalimin e kohës, vëmendja e njerëzve zakonisht zbehet dhe depoja e të dhënave mund të kthehet në një hale. Për të parandaluar që kjo të ndodhë, është e nevojshme të caktohen persona përgjegjës për ruajtjen e cilësisë së të dhënave, të cilët do të kryejnë vazhdimisht verifikimi informacion që vjen nga sistemet e përpunimit të transaksioneve me të dhëna në një magazinë ose treg.
Si përfundim, mund të vërehet se procesi i projektimit të një magazine të dhënash përdoret për të siguruar informacionin e nevojshëm në procesi i vendimmarrjes niveli korporativ dhe ndërkorporativ, është kritik për jetën e ndërmarrjes. Në fazën e zbatimit të tij, duhet t'i kushtohet vëmendje jo vetëm zgjidhjes probleme teknike por edhe ndaj problemeve që lidhen me faktorin njerëzor. Gjithashtu nuk duhet të harrojmë nevojën për vlerësim të vazhdueshëm të përshtatshmërisë së përpjekjeve që po bëhen. Përveç zinxhirit të duhur të menaxhimit të projektit, është e nevojshme që në çdo fazë të merren parasysh nevojat e përdoruesve dhe prania e aspekteve politike që mund të ngadalësojnë projektin. Me një qasje kompetente për zgjidhjen e këtij problemi, magazina e të dhënave së shpejti mund të bëhet pjesë e saj sistemi tregtar sipërmarrjes duke i siguruar një pjese të përdoruesve të palëve të treta për një tarifë mundësinë për të përdorur të dhëna nga një nëngrup i depove. Kjo qasje do të lejojë jo vetëm të rikuperojë punën për formimin e një magazine të dhënash, por edhe të sigurojë kanal i ri marrja e të ardhurave.
