Biltegiratze-instalazioak garatzea konpromiso luzea eta serioa da.
Proiektu baten bizitzan askoz ere objektu-eredua eta oinarrizko egitura hasieran pentsatutakoaren araberakoa da.
Orokorrean onartutako ikuspegia izar-eskema hirugarren forma normalarekin konbinatzeko hainbat aldaera izan da eta izaten jarraitzen du. Oro har, printzipioaren arabera: hasierako datuak - 3NF, erakusleihoak - izarra. Ikuspegi hau, denboran frogatua eta ikerketa ugariren laguntzarekin, DWH espezialista esperientziadun bati burura etortzen zaion lehenengo gauza (eta batzuetan bakarra) da biltegi analitiko batek nolakoa izan behar duen pentsatzean.
Bestalde, negozioak, oro har, eta bezeroen eskakizunak bereziki, azkar aldatu ohi dira, eta datuak hazi ohi dira bai "sakonean" eta "zabalean". Eta hor agertzen da izar baten desabantaila nagusia - mugatua malgutasuna.
Eta zure bizitza lasai eta erosoan DWH garatzaile gisa bat-batean:
- zeregina sortu zen βgutxienez zerbait azkar egitea, eta gero ikusiko duguβ;
- azkar garatzen ari den proiektu bat agertu zen, iturri berriak lotuz eta negozio eredua berraztertuz gutxienez astean behin;
- sistemak nolakoa izan behar duen eta azken finean zer funtzio bete behar dituen ideiarik ez duen bezero bat agertu da, baina prest dago nahi den emaitza esperimentatzeko eta etengabe fintzeko, etengabe bertara hurbiltzen den bitartean;
- Proiektuaren kudeatzaileak berri onarekin esan zuen: "Eta orain bizkorra dugu!"
Edo biltegiratze-instalazioak nola eraiki ditzakezun jakitea interesatzen bazaizu, ongi etorri ebakidura!
Zer esan nahi du "malgutasuna"?
Lehenik eta behin, defini ditzagun zein propietate izan behar dituen sistema batek βmalguaβ deitzeko.
Bereizita, aipatzekoa da deskribatutako propietateak bereziki lotu behar direla sistema, ez prozesua bere garapena. Horregatik, Agile-ri buruz garapen-metodologia gisa irakurri nahi bazenu, hobe da beste artikulu batzuk irakurtzea. Adibidez, han bertan, HabrΓ©-n, material interesgarri asko dago (adibidez ΠΈ Eta ).
Horrek ez du esan nahi garapen prozesuak eta datu biltegiaren egiturak guztiz zerikusirik ez dutenik. Orokorrean, nabarmen errazagoa izan beharko litzateke arkitektura arin baterako biltegi Agile bat garatzea. Hala ere, praktikan, Kimbal-en eta DataVault-en arabera DWH klasikoaren garapen Agilearekin aukera gehiago dago - Waterfall-en arabera, proiektu bakarrean bere bi formetako malgutasun-kointzidentzia zoriontsuak baino.
Beraz, zer gaitasun izan beharko lituzke biltegiratze malguak? Hiru puntu daude hemen:
- Entrega goiztiarra eta buelta azkarra - horrek esan nahi du hobekien lehen negozioaren emaitza (adibidez, lehen lan-txostenak) ahalik eta lasterren lortu behar dela, hau da, sistema osoa guztiz diseinatu eta ezarri baino lehen ere. Gainera, ondorengo berrikuspen bakoitzak ahalik eta denbora gutxien behar du.
- Fintasun iteratiboa - horrek esan nahi du ondorengo hobekuntza bakoitzak lehendik funtzionatzen duen funtzionalitateari ez diola eragin behar. Une hau da askotan proiektu handietan amesgaiztorik handiena bilakatzen dena - lehenago edo beranduago, objektu indibidualak hainbeste konexio lortzen hasten dira, non errazago bihurtzen da logika guztiz errepikatzea gertuko kopian dagoen taula batean eremu bat gehitzea baino. Eta lehendik dauden objektuetan hobekuntzak duten eragina aztertzeak hobekuntzak beraiek baino denbora gehiago behar izateak harritzen bazaitu, ziurrenik ez duzu oraindik banku edo telekomunikazioetako datu biltegi handiekin lan egin.
- Negozioen eskakizun aldakorretara etengabe egokitzea - Objektu-egitura orokorra hedapen posiblea kontuan hartuz ez ezik, hurrengo hedapen honen norabidea diseinu-fasean ere amestu ezingo den itxaropenarekin diseinatu behar da.
Eta bai, baldintza hauek guztiak sistema bakarrean betetzea posible da (noski, zenbait kasutan eta erreserba batzuekin).
Jarraian, datu biltegietarako diseinu arin-metodologia ezagunenetako bi kontuan hartuko ditut: Aingura eredua ΠΈ Datuen ganga. Parentesietatik kanpo geratzen dira teknika bikainak, adibidez, EAV, 6NF (bere forma hutsean) eta NoSQL soluzioekin lotutako guztia - ez nolabait okerragoak direlako, eta ezta kasu honetan artikuluak eskuratzea mehatxatuko lukeelako ere. batez besteko disertatzailearen bolumena. Hau guztia apur bat desberdineko klase bateko soluzioei dagokie, bai kasu zehatzetan erabil ditzakezun teknikekin, zure proiektuaren arkitektura orokorra edozein dela ere (EAV bezala), edo globalki beste informazio biltegiratze paradigmekin (adibidez, grafikoen datu-baseekin). eta beste aukera batzuk NoSQL).
Ikuspegi βklasikoarenβ arazoak eta haien konponbideak metodologia malguetan
Ikuspegi "klasiko"arekin izar zahar ona esan nahi dut (azpiko geruzen ezarpen zehatza edozein dela ere, Kimball, Inmon eta CDM-ren jarraitzaileek barka nazatela).
1. Konexioen kardinaltasun zurruna
Eredu hau datuen banaketa argi batean oinarritzen da Dimentsioa ΠΈ egitateak. Eta hori, madarikatua, logikoa da: azken finean, kasu gehienetan datuen analisia zenbait atal (dimentsio) zenbakizko adierazle (gertakari) aztertzera dator.
Kasu honetan, objektuen arteko konexioak taulen arteko erlazioen forman ezartzen dira gako arrotz bat erabiliz. Honek nahiko naturala dirudi, baina berehala malgutasunaren lehen mugara eramaten du - konexioen kardinalitatearen definizio zorrotza.
Horrek esan nahi du mahaiaren diseinu-etapan, erlazionatutako objektu pare bakoitzeko zehatz-mehatz zehaztu behar duzula asko eta askorekin erlazionatu daitezkeen ala ez 1etik askorekin eta "norantzan". Honek zuzenean zehazten du zein taula izango duen gako nagusia eta zeinek izango duen gako arrotza. Eskakizun berriak jasotzen direnean jarrera hori aldatzeak oinarriaren birmoldaketa ekarriko du ziurrenik.
Adibidez, "diruaren ordainagiria" objektua diseinatzean, zuk, salmenta-sailaren zinetan oinarrituz, ekintza-aukera ezarri zenuen. promozio bat hainbat txeke postutarako (baina ez alderantziz):
Eta denbora pixka bat igaro ondoren, lankideek marketin estrategia berri bat aurkeztu zuten, posizio berean jarduteko hainbat promozio aldi berean. Eta orain taulak aldatu behar dituzu erlazioa objektu bereizi batean bereiziz.
(Orain sustapen-egiaztapena batzen diren objektu eratorri guztiak ere hobetu behar dira).
Harremanak Data Vault eta Aingura Ereduan
Egoera hori saihestea nahiko erraza izan zen: ez duzu salmenta-sailean fidatu behar hori egiteko. konexio guztiak taula bereizietan gordetzen dira hasieran eta asko-to-asko bezala prozesatu.
Planteamendu hori proposatu zen Dan Linstedt paradigmaren parte gisa Datuen ganga eta guztiz lagunduta Lars RΓΆnnbΓ€ck Π² Aingura eredua.
Ondorioz, metodologia malguen lehen ezaugarri bereizgarria lortzen dugu:
Objektuen arteko erlazioak ez dira entitate nagusien atributuetan gordetzen, objektu mota bereiziak dira.
Π Datuen ganga lotze-taulei deitzen zaie Linketa Aingura eredua - Tie. Lehen begiratuan, oso antzekoak dira, nahiz eta haien ezberdintasunak izenarekin amaitzen ez diren (beherago aztertuko dena). Bi arkitekturetan, esteka-taulak lotu daitezke edozein entitate (ez derrigorrez 2).
Erredundantzia horrek, lehen begiratuan, aldaketetarako malgutasun handia ematen du. Egitura hori tolerante bihurtzen da lehendik dauden esteken kardinalitatearen aldaketekin ez ezik, berriak gehitzearekin ere - orain txeke-posizio batek hautsi duen kutxazainarekin esteka bat badu, esteka hori agertzea besterik ez da egingo. bihurtu lehendik dauden taulen gaineko gehigarri bat lehendik dauden objektu eta prozesuei eragin gabe.
2. Datuen bikoizketa
Arkitektura malguek ebatzitako bigarren arazoa ez da hain agerikoa eta berezkoa da lehenik. SCD2 motako neurketak (bigarren motako neurriak poliki-poliki aldatzen), nahiz eta ez horiek bakarrik.
Biltegi klasiko batean, dimentsio bat, normalean, ordezko gako bat (PK gisa) eta zutabe ezberdinetan negozio-gako eta atributu multzo bat dituen taula bat da.
Dimentsio batek bertsioa onartzen badu, bertsio-baliotasun-mugak gehitzen dira eremu-multzo estandarrera, eta hainbat bertsio agertzen dira biltegian iturriko errenkada baterako (bertsiodun atributuen aldaketa bakoitzeko bat).
Dimentsio batek gutxienez maiz aldatzen den bertsiodun atributu bat badu, dimentsio horren bertsio kopurua ikusgarria izango da (nahiz eta gainerako atributuak bertsionatu ez diren edo inoiz aldatzen ez diren), eta halako atributu batzuk badaude, bertsio-kopurua izan daiteke. beren kopurutik esponentzialki hazten dira. Dimentsio honek diskoko espazio kopuru handia har dezake, nahiz eta gordetzen dituen datu asko beste errenkada batzuetako atributu aldaezinen balioen bikoiztuak besterik ez diren.
Aldi berean, oso maiz erabiltzen da desnormalizazioa β atributu batzuk nahita gordetzen dira balio gisa, eta ez erreferentzia-liburu baterako edo beste dimentsio baterako esteka gisa. Planteamendu honek datuen sarbidea bizkortzen du, dimentsio batera sartzean elkartze-kopurua murriztuz.
Normalean honek eramaten du informazio bera aldi berean hainbat lekutan gordetzen da. Adibidez, bizilekuari eta bezeroaren kategoriari buruzko informazioa aldi berean gorde daiteke "Bezeroa" dimentsioetan eta "Erosketa", "Bidalketa" eta "Call Center Deiak" datuetan, baita "Bezeroa - Bezeroaren Kudeatzailea" atalean. β esteka taula.
Oro har, goian deskribatutakoa dimentsio arruntei (bertsiorik gabekoei) aplikatzen zaie, baina bertsiodunetan beste eskala bat izan dezakete: objektu baten bertsio berri baten agerpenak (batez ere atzera begira) erlazionatutako guztiak eguneratzeaz gain. taulak, baina erlazionatutako objektuen bertsio berrien kaskaka itxurara - 1. taula 2. taula eraikitzeko eta 2. taula 3. taula eraikitzeko erabiltzen denean, etab. Nahiz eta 1. Taularen atributu bakar batek ere parte hartzen ez duen 3. Taularen eraikuntzan (eta beste iturri batzuetatik lortutako 2. Taularen beste atributu batzuk ere badaude), eraikuntza hori bertsiotzeak kostu gehigarria ekarriko du gutxienez, eta gehienez ere gehigarria. 3. taulako bertsioak horrekin batere zerikusirik ez duena, eta katean beherago.
3. Berrikuntzaren konplexutasun ez-lineala
Aldi berean, beste batean oinarrituta eraikitako erakusleiho berri bakoitzak datuak "desberdin" daitezkeen leku kopurua handitzen du ETLan aldaketak egiten direnean. Horrek, aldi berean, ondorengo berrikuspen bakoitzaren konplexutasuna (eta iraupena) areagotzea dakar.
Goian gutxitan aldatzen diren ETL prozesuak dituzten sistemak deskribatzen baditu, paradigma horretan bizi zaitezke; erlazionatutako objektu guztietan aldaketa berriak behar bezala egiten direla ziurtatu besterik ez duzu behar. Berrikuspenak maiz gertatzen badira, hainbat konexio nahi gabe "galtzeko" probabilitatea nabarmen handitzen da.
Gainera, kontuan hartzen badugu "bertsiodun" ETL "bertsiorik gabekoa" baino nabarmen korapilatsuagoa dela, nahiko zaila da akatsak saihestea instalazio hau osoa maiz eguneratzean.
Objektuak eta atributuak Data Vault eta Anchor Model-en gordetzea
Arkitektura malguen egileek proposatutako ikuspegia honela formula daiteke:
Aldatzen dena eta berdin geratzen dena bereiztea beharrezkoa da. Hau da, gorde gakoak atributuetatik bereizita.
Hala ere, ez da nahastu behar ez bertsionatu atributuarekin aldatu gabe: lehenengoak ez du bere aldaketen historia gordetzen, baina alda daiteke (adibidez, sarrerako errore bat zuzentzean edo datu berriak jasotzean); bigarrena ez da inoiz aldatzen.
Ikuspegiak desberdinak dira datuen gangan eta aingura ereduan aldaezintzat jo daitekeenari buruz.
Arkitekturaren ikuspuntutik Datuen ganga, aldatu gabe kontsidera daiteke giltza multzo osoa - naturala (erakundearen TIN, iturburu-sistemako produktuaren kodea, etab.) eta ordezkoa. Kasu honetan, gainerako atributuak taldetan bana daitezke aldaketen jatorriaren eta/edo maiztasunaren arabera eta Mantendu mahai bana talde bakoitzerako bertsio multzo independente batekin.
Paradigman Aingura eredua aldatu gabekotzat jotzen da ordezko gako bakarra esentzia. Gainerako guztia (gako naturalak barne) bere atributuen kasu berezi bat besterik ez da. Non atributu guztiak elkarrengandik independenteak dira lehenespenez, beraz, atributu bakoitzeko a mahai bereizia.
Π Datuen ganga entitate-gakoak dituzten taulei deitzen zaie Hubami. Hubek eremu finko bat dute beti:
- Entitate naturalaren gakoak
- Ordezko giltza
- Esteka iturrira
- Grabatu denbora gehitzeko
Mezuak Hubs-en inoiz aldatu eta ez dute bertsiorik. Kanpotik, zentroak sistema batzuetan ordezkoak sortzeko erabiltzen diren ID-map motako taulen oso antzekoak dira; hala ere, gomendatzen da negozio-gako multzo bateko hash bat erabiltzea Data Vault-en ordezko gisa. Ikuspegi honek iturrietatik erlazioak eta atributuak kargatzea errazten du (ez duzu hub-ean sartu behar ordezko bat lortzeko, gako natural baten hash-a kalkulatu besterik ez duzu behar), baina beste arazo batzuk sor ditzake (talkekin erlazionatuta, adibidez). , maiuskulak eta inprimagarriak ez diren karaktereak kate teklatan, etab. .p.), beraz, ez da orokorrean onartzen.
Beste entitate-atributu guztiak izeneko taula berezietan gordetzen dira Sateliteak. Hub batek hainbat satelite izan ditzake atributu multzo desberdinak gordetzen dituztenak.
Sateliteen artean atributuen banaketa printzipioaren arabera gertatzen da baterako aldaketa - satelite batean bertsiorik gabeko atributuak gorde daitezke (adibidez, jaiotze-data eta SNILS pertsona baten kasuan), beste batean - gutxitan aldatzen diren bertsioak (adibidez, abizena eta pasaporte-zenbakia), hirugarrenean - maiz aldatzen direnak. (adibidez, entrega helbidea, kategoria, azken eskaeraren data, etab.). Kasu honetan, bertsioak satelite indibidualen mailan egiten dira, eta ez entitate osoan, beraz, komeni da atributuak banatzea satelite baten barruan bertsioen elkargunea minimoa izan dadin (horrek biltegiratutako bertsioen guztizko kopurua murrizten du). ).
Gainera, datuak kargatzeko prozesua optimizatzeko, hainbat iturritatik lortutako atributuak sarritan sartzen dira satelite indibidualetan.
Sateliteak Hub-arekin komunikatzen dira kanpoko giltza (1-askoren kardinalitateari dagokiona). Horrek esan nahi du hainbat atributu-balioak (adibidez, bezero bakarreko hainbat kontaktu telefono-zenbakiak) "lehenetsitako" arkitektura honek onartzen dituela.
Π Aingura eredua gakoak gordetzen dituzten taulei deitzen zaie Aingurak. Eta mantentzen dute:
- Ordezko gakoak bakarrik
- Esteka iturrira
- Grabatu denbora gehitzeko
Aingura Ereduaren ikuspuntutik gako naturalak hartzen dira kontuan atributu arruntak. Aukera hau ulertzea zailagoa dirudi, baina objektua identifikatzeko askoz aukera gehiago ematen du.
Adibidez, entitate berari buruzko datuak sistema ezberdinetatik etor daitezke, bakoitzak bere gako naturala erabiltzen du. Data Vault-en, horrek hainbat zentroren egitura astun samarrak ekar ditzake (bat iturri bakoitzeko + bertsio maisu bateratzailea), Anchor ereduan, berriz, iturri bakoitzaren gako naturala bere atributuan sartzen da eta independentean kargatzean erabil daiteke. beste guztiak.
Baina puntu maltzur bat ere badago hemen: sistema ezberdinetako atributuak entitate batean konbinatzen badira, ziurrenik batzuk egongo dira. "Itsatsi" arauak, horren bidez, sistemak ulertu behar du iturri ezberdinetako erregistroak entitatearen instantzia bati dagozkiola.
Π Datuen ganga arau horiek erabakiko dute ziurrenik eraketa entitate nagusiaren "ordezko hub". eta ez du inola ere eragin iturri naturalaren gakoak eta haien jatorrizko atributuak gordetzen dituzten Hubetan. Uneren batean bateratze-arauak aldatzen badira (edo egiten den atributuak eguneratzen badira), nahikoa izango da gune ordezkoen formateatzea.
Π Aingura eredua entitate hori ziurrenik bertan gordeko da aingura bakarra. Horrek esan nahi du atributu guztiak, edozein iturritatik datozen, ordezko berari lotuta egongo direla. Oker batu diren erregistroak bereiztea eta, oro har, sistema horretan bat egitearen garrantzia kontrolatzea askoz zailagoa izan daiteke, batez ere arauak nahiko konplexuak badira eta maiz aldatzen badira, eta atributu bera iturri ezberdinetatik lor daiteke (nahiz eta zalantzarik gabe). posible, atributu bertsio bakoitzak bere iturrirako esteka gordetzen baitu).
Nolanahi ere, zure sistemak funtzionalitatea ezarri behar badu desduplikatzea, erregistroak eta beste MDM elementu batzuk bateratzea, merezi du arreta berezia jartzea metodologia arinetan gako naturalak gordetzearen alderdiei. Litekeena da Data Vault diseinu masiboa bat-batean seguruagoa izatea bateratze-erroreei dagokienez.
Aingura eredua izeneko objektu mota gehigarri bat ere eskaintzen du Korapilo funtsean berezia da aingura mota degeneratua, atributu bakarra izan dezakeena. Nodoak direktorio lauak gordetzeko erabili behar dira (adibidez, sexua, egoera zibila, bezeroarentzako arretaren kategoria, etab.). Aingura ez bezala, Korapiloa ez dauka erlazionatutako atributu-taularik, eta bere atributu bakarra (izena) beti gordetzen da gakoarekin taula berean. Nodoak ainguretara konektatzen dira lotura-taulen bidez (Tie) aingurak elkarren artean konektatzen diren moduan.
Ez dago iritzi argirik Nodoen erabilerari buruz. Adibidez, Errusian Aingura Ereduaren erabilera aktiboki sustatzen duenak, uste du (ez arrazoirik gabe) erreferentzia-liburu bakar batentzat ez dela ziur esan daitekeela. beti estatikoa eta maila bakarrekoa izango da, beraz, hobe da berehala objektu guztietarako aingura osoa erabiltzea.
Data Vault eta Anchor ereduaren arteko beste desberdintasun garrantzitsu bat erabilgarritasuna da konexioen atributuak:
Π Datuen ganga Estekak Hubs-en erabateko objektu berberak dira, eta izan ditzakete berezko atributuak. Urtean Aingura eredua Estekak Aingurak eta konektatzeko soilik erabiltzen dira ezin dituzte bere ezaugarri propioak izan. Desberdintasun horrek modelizazio-ikuspegiak nabarmen desberdinak ditu egitateak, gehiago eztabaidatuko dena.
Datuak gordetzea
Honen aurretik, batez ere neurketa-modelizazioari buruz hitz egin dugu. Gertaerak apur bat gutxiago argi daude.
Π Datuen ganga gertakariak gordetzeko ohiko objektu bat da Esteka, zeinen sateliteetan benetako adierazleak gehitzen dira.
Ikuspegi honek intuitiboa dirudi. Aztertutako adierazleetara sarbide erraza eskaintzen du eta, oro har, gertakarien taula tradizional baten antzekoa da (adierazleak bakarrik gordetzen dira ez taulan bertan, "alboko" batean baizik). Baina badaude hutsuneak ere: ereduaren aldaketa tipikoetako bat -egiazko gakoaren hedapena- beharrezkoa da atzerriko gako berri bat gehitzea Link-en. Eta horrek, aldi berean, modulartasuna "hausten" du eta potentzialki beste objektu batzuetan aldaketak egiteko beharra eragiten du.
Π Aingura eredua Konexio batek ezin ditu bere atributuak izan, beraz, ikuspegi honek ez du funtzionatuko - erabat atributu eta adierazle guztiak aingura zehatz batekin lotu behar dira. Honen ondorioa sinplea da - Gertaera bakoitzak bere aingura ere behar du. Gertakari gisa hautematen ohituta gauden batzuentzat, hau naturala izan daiteke; adibidez, erosketa bat ezin hobeto murriztu daiteke objektura "eskaera" edo "ordainagiria", gune bat saio batera bisitatzea, etab. Baina badaude "eramaile-objektu" natural bat aurkitzea hain erraza ez den gertakariak ere; adibidez, egun bakoitzaren hasieran biltegietan dauden salgaien hondakinak.
Horren arabera, modularitate-arazoak ez dira sortzen aingura-ereduan gertakari-gako bat zabaltzean (nahikoa da dagokion aingurari Erlazio berri bat gehitzea besterik ez), baina gertakariak bistaratzeko eredu bat diseinatzea ez da anbiguotasunik gabea; aingura "artifizialak" ager daitezke. negozio-objektu-eredua modu argirik gabe erakusten dutenak.
Nola lortzen den malgutasuna
Ondorioz egindako eraikuntzak bi kasuetan dauka taula nabarmen gehiagoneurketa tradizionala baino. Baina behar da disko espazioa nabarmen gutxiago dimentsio tradizionalaren bertsiodun atributu multzo berarekin. Jakina, hemen ez dago magiarik - normalizazioari buruzkoa da guztia. Atributuak sateliteetan (Datu-gangelan) edo banakako tauletan banatuz (Anchor Model), murrizten dugu (edo erabat ezabatzen dugu) Atributu batzuen balioak bikoiztea beste batzuk aldatzean.
For Datuen ganga irabaziak Sateliteen arteko atributuen banaketaren araberakoak izango dira, eta Aingura eredua β Ia zuzenean proportzionala da neurketa-objektu bakoitzeko bertsioen batez besteko kopuruarekin.
Hala ere, espazioa aurreztea ezaugarriak bereizita gordetzeko abantaila garrantzitsu bat da, baina ez nagusia. Harremanen biltegiratze bereiziarekin batera, ikuspegi honek denda egiten du diseinu modularra. Horrek esan nahi du eredu batean ezaugarri indibidualak eta gai-arlo berri osoak gehitzeak itxura duela gainegitura lehendik dagoen objektu multzo baten gainean, horiek aldatu gabe. Eta horixe da deskribatutako metodologiak malgutzen dituena.
Piezen ekoizpenetik masa-ekoizpenerako trantsizioa ere antza du - ikuspegi tradizionalean ereduaren taula bakoitza bakarra bada eta arreta berezia eskatzen badu, metodologia malguetan dagoeneko "pieza" estandar multzoa da. Alde batetik, taula gehiago daude, eta datuak kargatzeko eta berreskuratzeko prozesuek korapilatsuagoak izan beharko lukete. Bestetik, bihurtzen dira tipikoa. Horrek esan nahi du egon daitekeela automatizatua eta metadatuak bultzatuta. "Nola ezarriko dugu?" galderak, zeinaren erantzunak hobekuntzak diseinatzeko lanaren zati garrantzitsu bat har dezakeen, orain ez du merezi (baita eredua aldatzeak lan prozesuetan duen eraginari buruzko galderak ere. ).
Horrek ez du esan nahi analistak halako sistema batean behar ez direnik; oraindik norbaitek atributuak dituzten objektuen multzoa landu behar du eta dena non eta nola kargatu jakin behar du. Baina lan-kopurua, baita errore baten probabilitatea eta kostua ere, nabarmen murrizten dira. Bai analisi-fasean, bai ETL-ren garapenean, zati esanguratsu batean metadatuak editatzera murriztu daitezkeenak.
Alde iluna
Aurreko guztiari esker bi ikuspegiak benetan malguak, teknologikoki aurreratuak eta hobekuntza errepikakorrak egokiak dira. Noski, βukenduan upel batβ ere badago, uste dut dagoeneko asma dezakezula.
Datuen deskonposizioak, arkitektura malguen modularitatearen azpian dagoena, taula kopurua handitzea dakar eta, horren ondorioz, gainetik laginketa egiterakoan elkartzeak. Dimentsio baten atributu guztiak lortzeko, denda klasiko batean aukeraketa bat nahikoa da, baina arkitektura malgu batek juntura sorta bat beharko du. Gainera, txostenetarako elkartze hauek guztiak aldez aurretik idatzi badira, orduan SQL eskuz idaztera ohituta dauden analistek bikoiztu egingo dute.
Egoera hau errazten duten hainbat datu daude:
Dimentsio handiekin lan egiten denean, bere atributu guztiak ez dira ia inoiz aldi berean erabiltzen. Horrek esan nahi du ereduari lehen begiratuan badirudi baino elkartze gutxiago egon daitezkeela. Data Vault-ek partekatzeko espero den maiztasuna ere kontuan har dezake sateliteei atributuak esleitzerakoan. Aldi berean, Hubak edo Aingurak beraiek beharrezkoak dira batez ere karga-fasean ordezkoak sortzeko eta mapatzeko eta oso gutxitan erabiltzen dira kontsultetan (hau bereziki egia da Ainguretarako).
Elkarketa guztiak giltza bidezkoak dira. Gainera, datuak gordetzeko modu "konprimituago" batek eskaneatzeko taulen gainkostua murrizten du behar den tokian (adibidez, atributu-balioaren arabera iragazten denean). Horrek ekar dezake datu-base normalizatu batetik laginketa batuketa mordoa dituena are azkarragoa izango dela errenkada bakoitzeko bertsio asko dituen dimentsio astun bat eskaneatzea baino.
Adibidez, hemen Artikuluak Anchor ereduaren errendimenduaren proba konparatibo zehatza dauka taula bateko lagin batekin.
Asko motorraren araberakoa da. Plataforma moderno askok barne-juntura optimizatzeko mekanismoak dituzte. Esate baterako, MS SQL eta Oracle-k tauletan elkarketak "saltatu" ditzakete haien datuak inon erabiltzen ez badira beste batuketetan izan ezik eta azken hautapenari eragiten ez badiote (taularen/joinen ezabapena), eta MPP Vertica. , Aingura Eredurako motor bikaina dela frogatu du, kontsulta-planaren eskuzko optimizazio batzuk emanda. Bestalde, Aingura Eredua gordetzea, adibidez, Klik Etxean, batzeko laguntza mugatua duena, oraindik ez dirudi oso ideia ona dela.
Horrez gain, bi arkitekturarentzat badaude mugimendu bereziak, datuen sarbidea erraztuz (bai kontsulten errendimenduaren ikuspuntutik, bai azken erabiltzaileentzat). Adibidez, Point-in-Time taulak Data Vault-en edo taularen funtzio bereziak Aingura ereduan.
Guztira
Hartutako arkitektura malguen funtsa nagusia haien "diseinuaren" modulartasuna da.
Jabetza hau da:
- Metadatuen inplementazioari eta oinarrizko ETL algoritmoak idazteari lotutako hasierako prestaketa egin ondoren, azkar eman bezeroari lehen emaitza iturburu-objektu gutxi batzuen datuak dituzten txosten pare baten moduan. Ez da beharrezkoa objektu-eredu osoa guztiz pentsatzea (goiko mailan ere).
- Datu-eredu bat lanean has daiteke (eta erabilgarria izan daiteke) 2-3 objekturekin soilik, eta gero pixkanaka hazten (Nikolai Aingura modeloari dagokionez mizelioarekin alderaketa polita).
- Hobekuntza gehienak, gai-eremua zabaltzea eta iturri berriak gehitzea barne ez du lehendik dagoen funtzionalitateari eragiten eta ez du funtzionatzen ari den zerbait hausteko arriskurik sortzen.
- Elementu estandarretan deskonposatzeari esker, horrelako sistemetan ETL prozesuek itxura berdina dute, haien idazkerak algoritmorako errazten du eta, azken batean, automatizazioa.
Malgutasun horren prezioa da produktibitatea. Horrek ez du esan nahi horrelako ereduetan errendimendu onargarria lortzea ezinezkoa denik. Gehienetan, baliteke ahalegin eta arreta gehiago behar izatea xehetasunei nahi dituzun neurriak lortzeko.
aplikazioak
Entitate motak Datuen ganga
Data Vault-i buruzko informazio gehiago:
Entitate motak Aingura eredua
Aingura ereduari buruzko xehetasun gehiago:
Laburpen-taula kontuan hartutako planteamenduen ezaugarri komunak eta desberdintasunak:
Iturria: www.habr.com