Ky artikull do të fokusohet në arkitekturën e magazinës së të dhënave. Nga çfarë duhet të udhëhiqet gjatë ndërtimit të tij, cila i afrohet punës - dhe pse.

"Përralla është një gënjeshtër - por ka një aluzion në të ..."

Gjyshi mbolli ... ruajtje. Dhe depoja është rritur, e madhe, e madhe. Unë thjesht nuk e dija se si funksiononte. Dhe gjyshi filloi një rishikim. Gjyshi thirri gjyshen, mbesën, macen dhe miun në këshillin familjar. Dhe ai thotë si më poshtë: “Magazinimi ynë është rritur. Të dhënat nga të gjitha sistemet rrjedhin poshtë, tabelat janë të dukshme dhe të padukshme. Përdoruesit sajojnë raportet e tyre. Gjithçka duket të jetë mirë - të jetosh dhe të jetosh. Po, vetëm një trishtim - askush nuk e di se si funksionon. Kërkon disqe në dukje të padukshme - nuk mund të kurseni sa duhet! Dhe më pas përdoruesit u bënë zakon të vinin tek unë me ankesa të ndryshme: ose raporti ngrin, ose të dhënat janë të vjetruara. Dhe atëherë është një fatkeqësi - ne vijmë me raporte te car-babai, por numrat nuk pajtohen me njëri-tjetrin. Ora nuk është as - mbreti është i zemëruar - atëherë mos e hiq kokën - as për mua, as për ty. Kështu që vendosa t'ju mbledh së bashku dhe të konsultohemi: çfarë do të bëjmë?"

Ai hodhi vështrimin mbi takimin dhe pyet:
- Ti, gjyshe, a e di si është rregulluar depoja jonë?
- Jo, gjysh, nuk e di. Dhe si do ta dija? Atje, sa djem trima po e ruajnë! Disa prej tyre! Nuk do të afroheni. Shkova t'i shikoja disi, të pjekura byrekë. Dhe hëngrën byrekët, fshinë mustaqet dhe thanë: “Pse erdhe gjyshe? Çfarë lloj ruajtjeje jeni? Ju më tregoni se çfarë lloj raporti keni nevojë - ne do ta bëjmë atë për ju! Duhet të sillni byrekët më shpesh! Për dhimbje, ato janë të shijshme."
- Dhe ju, mbesa e dashur, a e dini se si është rregulluar ruajtja jonë?
- Jo, gjysh, nuk e di. Ata më dhanë akses në të disi. U lidha, dukem - dhe ka tabela - me sa duket të padukshme. Dhe skema të ndryshme janë të fshehura. Sytë ngrihen lart…. Në fillim u hutova. Dhe pastaj pashë nga afër - disa prej tyre janë bosh, të tjerët janë plot, por vetëm gjysma. Dhe të dhënat duket se përsëriten. Nuk është çudi që nuk do të mjaftoheni me disqe, me një tepricë të tillë!
- Epo, ti mace, çfarë thua për magazinën tonë? A ka ndonjë gjë të mirë për të?
- Po, si të mos them, gjysh - do. Me kërkesën e mbesës sime, u përpoqa të bëja një pilot në një qark të veçantë - një vitrinë të vogël. Për të kuptuar se çfarë lloj tregtie është fitimprurëse për shtetin tonë - cilat produkte janë të mira për tregtarët, ata paguajnë haraç - ata rimbushin thesarin. Dhe cilat janë shumë të këqija. Dhe fillova të zgjedh të dhëna për veten time nga kjo depo. Fakte të mbledhura. Dhe ai filloi të përpiqej t'i krahasonte ato me produktet. Dhe çfarë, gjysh, pashë - produktet duken të njëjta, por ju shikoni pjatat - ato janë të ndryshme! Më pas fillova t'i krehja me krehërin e mbesës. Chesal-gërvishtur - dhe çoi në një uniformitet të caktuar, duke përkëdhelur sytë. Por herët u gëzova - të nesërmen nisa skriptet e mia për të përditësuar të dhënat e mrekullueshme në dritare - dhe gjithçka ishte zhdukur për mua! "Si keshtu?" - Unë mendoj - do të mërzitet mbesa - sot do të duhej t'i tregonim pilotit tonë ministrit. Si të shkojmë me të dhëna të tilla?
- Po, përralla të trishta, mace, tregoni. Epo, ju, miu i vogël, vërtet nuk u përpoqët të mësoni për ruajtjen? Ju jeni një vajzë e gjallë, e shkathët, e shoqërueshme me ne! Çfarë do të na thoni?
- Po, si, gjysh, mos u përpiq - sigurisht, unë jam një mi i qetë, po i shkathët. Një herë mbesa e maces më kërkoi të merrja modelin e të dhënave të ruajtjes sonë shtetërore. Dhe macja, natyrisht, erdhi tek unë - për ty, thotë ai, miu, gjithë shpresë! Epo, çfarë është një vepër e mirë që njerëzit e mirë (dhe macet) të mos bëjnë? Shkova në kala, ku kreu i magazinës fsheh modelin e të dhënave në kasafortë. Dhe ajo u fsheh. Prita që ai ta nxirrte atë model nga kasaforta. Sapo ai doli për kafe, unë u hodha mbi tavolinë. E shikoj modelin - nuk kuptoj asgjë! Si keshtu? Unë nuk e njoh ruajtjen tonë! Ne kemi mijëra tabela të panumërta, rrjedhat e të dhënave janë të papërmbajtshme! Dhe këtu - gjithçka është harmonike dhe e bukur ... Ai e shikoi pikërisht këtë model - dhe e vendosi përsëri në kasafortë.
- Po, gjëra shumë të çuditshme, na ke thënë, miu.
Gjyshi u mendua shumë.
- Çfarë do të bëjmë, miqtë e mi? Në fund të fundit, me një depo të tillë dhe të tillë nuk do të jetoni gjatë ... Përdoruesit së shpejti do të humbasin durimin e tyre.

Çfarëdo që gjyshi ynë vendosi nga një përrallë - të ndërtojë një objekt të ri magazinimi ose të përpiqet të ringjallë një ekzistues - është e nevojshme të nxjerrim përfundime përpara se të "përveshim mëngët" përsëri.
Le të lëmë mënjanë aspektet organizative - si rreziku i përqendrimit të ekspertizës në një grup të caktuar të ngushtë të mbyllur, mungesa e proceseve të kontrollit dhe sigurimi i transparencës së arkitekturës së sistemeve të përdorura në ndërmarrje, etj.
Sot do të doja të fokusohesha në ndërtimin e arkitekturës së një sistemi specifik (ose grup sistemesh) - magazinat e të dhënave. Ajo që duhet mbajtur në fokus para së gjithash, kur një organizatë fillon të ndërtojë një sistem kaq kompleks dhe të shtrenjtë si një depo.

Debriefing

Askush nga ne, duke punuar në krijimin dhe zhvillimin e ndonjë sistemi, nuk dëshiron që kjo të jetë një "shtëpi e përkohshme", apo një zgjidhje që "do të shuhet" brenda një apo dy vitesh, sepse nuk do të jetë në gjendje të përmbushë kërkesat dhe pritshmëritë e klientëve dhe biznesit. Pavarësisht se sa i fortë është njëanshmëria ndaj "metodologjive fleksibël" sot, është shumë më e këndshme për një person të ndihet si një "mjeshtër" që prodhon violina sesa një artizan që hedh shkopinj për bateritë e disponueshme.
Synimi ynë tingëllon i natyrshëm: të bëjmë sisteme solide dhe cilësore, të cilat nuk do të na kërkojnë të kemi rregullisht "vigjilje nate me skedar", për të cilat nuk do të kemi turp para përdoruesve të fundit dhe që nuk do të duken si një "kuti e zezë" për të gjithë ndjekësit "të pa iniciuar".

Për të filluar, le të hedhim një listë të problemeve tipike që hasim rregullisht kur punojmë me depo. Le të shkruajmë vetëm atë që kemi - deri më tani pa u përpjekur të thjeshtojmë dhe zyrtarizojmë.

1. Në parim, ne kemi një ruajtje të mirë: nëse e lini të qetë, atëherë gjithçka funksionon. Vërtetë, sapo kërkohet një ndryshim, fillojnë "kolapset lokale".
2. Të dhënat ngarkohen çdo ditë, sipas rregullores, brenda një procesi të madh, brenda 8 orëve. Dhe na përshtatet. Por nëse papritmas ndodh një dështim, ai kërkon ndërhyrje manuale. Dhe pastaj gjithçka mund të funksionojë në mënyrë të paparashikueshme për një kohë të gjatë, tk. do të kërkojë pjesëmarrjen njerëzore në proces.
3. Keni mbështjellë lëshimin - prisni probleme.
4. Një burim i vetëm nuk mund të dërgonte të dhëna në kohë - të gjitha proceset janë në pritje.
5. Integriteti i të dhënave kontrollohet nga baza e të dhënave - kështu që proceset tona rrëzohen kur prishen.
6. Ne kemi një ruajtje shumë të madhe - 2000 tabela në një skemë të përbashkët. Dhe 3000 të tjera në shumë skema të tjera. Tashmë kemi pak ide se si janë rregulluar dhe për çfarë arsye janë shfaqur. Prandaj, mund të jetë e vështirë për ne të ripërdorim diçka. Dhe shumë detyra duhet të zgjidhen përsëri. Sepse, kjo është më e lehtë dhe më e shpejtë (se të kuptosh "kodin e dikujt tjetër"). Si rezultat, kemi mospërputhje dhe funksionalitet të dyfishtë.
7. Ne presim që burimi të sigurojë të dhëna me cilësi të mirë. Por rezulton se nuk është kështu. Si rezultat, ne shpenzojmë shumë kohë për të harmonizuar raportet tona përfundimtare. Dhe ata ishin shumë të suksesshëm në këtë. Madje kemi një proces të thjeshtuar. E vërtetë, kërkon kohë. Por përdoruesit janë mësuar të...
8. Përdoruesi jo gjithmonë i beson raporteve tona dhe kërkon një justifikim të një figure ose një tjetër. Në disa raste ka të drejtë, e në të tjera jo. Por ne e kemi shumë të vështirë t'i justifikojmë, pasi ne nuk kemi asnjë mjet për "analizë nga fundi në fund" (ose linjë të dhënash).
9. Ne mund të sjellim zhvillues shtesë. Por ne kemi një problem - si t'i përfshijmë ato në punë? Cila është mënyra më efikase për të paralelizuar vendet e punës?
10. Si të zhvillohet sistemi gradualisht, pa hyrë në zhvillimin e "bërthamës së sistemit" për një vit të tërë?
11. Magazina e të dhënave është e lidhur me modelin e korporatës. Por ne e dimë me siguri (e kemi parë në bankën XYZ) që ndërtimi i një modeli mund të zgjasë pafundësisht (ne shkuam në bankën XYZ për gjashtë muaj dhe diskutuam për subjektet e biznesit, pa asnjë lëvizje). Pse është ajo fare? Apo ndoshta është më mirë pa të, nëse ka kaq shumë probleme me të? Ndoshta ne mund ta gjenerojmë atë disi?
12. Ne vendosëm të drejtonim modelin. Por si e evoluoni sistematikisht modelin e të dhënave të magazinës? A na duhen “rregullat e lojës” dhe cilat mund të jenë ato? Çfarë do të na japë? Po sikur të kemi gabim me modelin?
13. A duhet t'i ruajmë të dhënat, apo historikun e ndryshimeve të tyre, nëse "biznesi nuk ka nevojë për to"? Nuk do të doja të "ruaj mbeturina" dhe të ndërlikoj përdorimin e këtyre të dhënave për detyra reale. A duhet që kasaforta të mbajë historinë? Si është? Si funksionon ruajtja me kalimin e kohës?
14. A duhet të përpiqemi të unifikojmë të dhënat në ruajtje nëse kemi një sistem master të menaxhimit të të dhënave? Nëse ka MDM, a do të thotë kjo se i gjithë problemi me të dhënat kryesore tani është zgjidhur?
15. Së shpejti pritet të zëvendësojmë sistemet kryesore të kontabilitetit. A duhet që dyqani i të dhënave të jetë gati për të ndryshuar burimin? Si mund të arrihet kjo?
16. A kemi nevojë për meta të dhëna? Çfarë kuptojmë me këtë? Ku saktësisht mund të përdoren? Si mund ta zbatoni atë? A duhet t'i ruaj ato "në një vend"?
17. Klientët tanë janë jashtëzakonisht të paqëndrueshëm në kërkesat dhe dëshirat e tyre - diçka po ndryshon vazhdimisht. Në përgjithësi, biznesi ynë është shumë dinamik. Ndërsa ne jemi duke bërë diçka, ajo tashmë bëhet e panevojshme. Si mund ta bëjmë në atë mënyrë që të japim rezultatin sa më shpejt të jetë e mundur - si ëmbëlsira të nxehtë?
18. Përdoruesit kërkojnë përgjegjshmëri. Por ne nuk mund të kryejmë shpesh proceset tona kryesore të nisjes, sepse kjo ngarkon sistemet burimore (ka një efekt të keq në performancën) - prandaj, ne mbyllim rrjedhat shtesë të të dhënave - të cilat do të marrin në drejtim të pikës - atë që na nevojitet. Vërtetë, ka shumë rrjedha. Dhe pastaj ne do të hedhim poshtë disa nga të dhënat. Për më tepër, do të ketë një problem konvergjence. Por nuk ka rrugë tjetër...

Shumëçka ka ndodhur tashmë. Por kjo nuk është një listë e plotë - është e lehtë për ta plotësuar dhe zhvilluar atë. Nuk do ta fshehim në tabelë, por do ta varim në një vend të dukshëm – duke i mbajtur këto çështje në fokusin e vëmendjes sonë në procesin e punës.
Detyra jonë është të gjejmë një zgjidhje gjithëpërfshirëse si rezultat.

Antifragjiliteti

Duke parë listën tonë, mund të nxirret një përfundim. Nuk është e vështirë të krijosh një lloj "baze të dhënash për raportim", të ngarkosh të dhëna atje, apo edhe të ndërtosh një lloj procesi rutinë të përditësimit të të dhënave. Sistemi fillon disi të jetojë, përdoruesit shfaqen, dhe me ta detyrimet dhe SLA, lindin kërkesa të reja, lidhen burime shtesë, ndryshojnë metodologjitë - e gjithë kjo duhet të merret parasysh në procesin e zhvillimit.

Pas ca kohësh, fotografia është si më poshtë:
“Këtu është kasaforta. Dhe funksionon nëse nuk e prekni. Problemet lindin kur duhet të ndryshojmë diçka.”

Na vjen një ndryshim, ndikimin e të cilit nuk jemi në gjendje ta vlerësojmë dhe ta kuptojmë (pasi nuk kemi futur mjete të tilla në sistem që në fillim) - dhe për të mos marrë rreziqe, ne nuk prekim atë që është, por ne bëjmë një zgjatje më shumë nga ana, dhe një tjetër, dhe gjithashtu - duke e kthyer vendimin tonë në lagje të varfëra, ose, siç thonë në Amerikën Latine, "favela", ku edhe policia ka frikë të hyjë.
Ekziston një ndjenjë e humbjes së kontrollit mbi sistemin e vet, kaos. Duhen gjithnjë e më shumë duar për të ruajtur proceset ekzistuese dhe për të zgjidhur problemet. Dhe ndryshimet po bëhen gjithnjë e më të vështira për t'u bërë. Me fjalë të tjera, sistemi bëhet i paqëndrueshëm ndaj stresit, i keqpërshtatshëm ndaj ndryshimeve. Dhe përveç kësaj, ka një varësi të fortë nga personazhet që "e njohin rrugën e lirë", pasi askush nuk ka "hartë".

Kjo pronë e një objekti - të shembet nën ndikimin e kaosit, ngjarjeve të rastësishme dhe goditjeve - e quan Nassim Nicholas Taleb brishtësia ... Dhe gjithashtu prezanton konceptin e kundërt: antifragjiliteti – kur objekti nuk shembet nga stresi dhe aksidentet, por përfiton drejtpërdrejt prej tij... ("Antifragjiliteti. Si të përfitoni nga kaosi")
Ndryshe mund të quhet përshtatshmëria ose elasticiteti ndaj ndryshimit .

Çfarë do të thotë kjo në këtë kontekst? Cilat janë "burimet e kaosit" për sistemet e TI-së? Dhe çfarë do të thotë të "kapitalizosh kaosin" për sa i përket arkitekturës së IT-së?
Mendimi i parë që vjen në mendje janë ndryshimet që vijnë nga jashtë. Çfarë është bota e jashtme për sistemin? Për ruajtjen në veçanti. Sigurisht, para së gjithash - ndryshime nga ana e burimeve të të dhënave për dyqanin:

• ndryshimi i formateve të të dhënave hyrëse;
• zëvendësimi i disa sistemeve të burimeve të të dhënave me të tjerë;
• ndryshimi i rregullave/platformave për integrimin e sistemeve;
• ndryshimi i interpretimit të të dhënave (formatet ruhen, logjika e punës me të dhënat ndryshon);
• ndryshimi i modelit të të dhënave nëse integrimi bëhet në nivel të të dhënave (parimi i skedarëve të regjistrit të transaksioneve të bazës së të dhënave);
• rritja e vëllimeve të të dhënave - ndërsa nuk kishte shumë të dhëna në sistemin burimor, dhe ngarkesa nuk ishte e lartë - ishte e mundur të rikuperohej në çdo kohë, me një kërkesë arbitrare të rëndë, të dhënat dhe ngarkesa u rritën - tani ka kufizime të rrepta ;
• etj.

Vetë sistemet burimore, përbërja e informacionit dhe struktura e tij, lloji i ndërveprimit të integrimit, si dhe vetë logjika e punës me të dhënat mund të ndryshojnë. Çdo sistem zbaton modelin e vet të të dhënave dhe qasjet për të punuar me ta, të cilat përmbushin qëllimet dhe objektivat e sistemit. Dhe pa marrë parasysh se sa shumë përpiqen të unifikojnë modelet e industrisë dhe praktikat e referencës, nuancat do të shfaqen në mënyrë të pashmangshme. (Dhe përveç kësaj, vetë procesi i bashkimit të industrisë, për arsye të ndryshme, nuk po bën shumë përparim.)
Kultura e punës me të dhënat e korporatës - prania dhe kontrolli i arkitekturës së informacionit, një model i unifikuar semantik, sistemet master të menaxhimit të të dhënave (MDM) lehtësojnë disi detyrën e konsolidimit të të dhënave në depo, por nuk përjashtojnë nevojën e tij.

Jo më pak ndryshime kritike janë iniciuar nga konsumatorët e magazinës (ndryshojnë kërkesat):

• më parë, kishte të dhëna të mjaftueshme për të krijuar një raport - tani kërkohej të lidheshin fusha shtesë ose një burim i ri i të dhënave;
• Teknikat e përpunimit të të dhënave të zbatuara më parë janë të vjetruara - duhet të ripunoni algoritmet dhe gjithçka që ndikon në të;
• Më parë, të gjithë ishin të kënaqur me vlerën aktuale të atributit të fjalorit në panelin e informacionit - tani kërkohet vlera që është e rëndësishme në kohën e faktit / ngjarjes së analizuar;
• kishte një kërkesë për thellësinë e historisë së ruajtjes së të dhënave, e cila nuk ekzistonte më parë - të ruheshin të dhënat jo për 2 vjet, por për 10 vjet;
• më parë, kishte të dhëna të mjaftueshme që nga "fundi i ditës / periudhës" - tani ju duhet gjendja e të dhënave "brenda ditës", ose në kohën e një ngjarje të caktuar (për shembull, një vendim për një kërkesë kredie - për Bazel II);
• më herët ishim të kënaqur me raportimin e të dhënave për dje (T-1) ose më vonë, tani na duhet T0;
• etj.

Si ndërveprimet e integrimit me sistemet burimore ashtu edhe kërkesat nga konsumatorët e të dhënave të magazinës janë faktorë të jashtëm për magazinë e të dhënave: disa sisteme burimore zëvendësojnë të tjerët, vëllimet e të dhënave rriten, formatet e të dhënave hyrëse ndryshojnë, kërkesat e përdoruesve ndryshojnë, etj. Dhe të gjitha këto janë ndryshime tipike të jashtme për të cilat sistemi ynë - depoja jonë - duhet të jetë gati. Me arkitekturën e duhur, ata nuk duhet të vrasin sistemin.

Por kjo nuk është e gjitha.
Duke folur për ndryshueshmërinë, ne, para së gjithash, kujtojmë faktorët e jashtëm. Në fund të fundit, brenda ne mund të kontrollojmë gjithçka, na duket kështu, apo jo? Po dhe jo. Po, shumica e faktorëve që janë jashtë zonës së ndikimit janë të jashtëm. Por ka edhe "entropi të brendshme". Dhe pikërisht për shkak të pranisë së tij, ndonjëherë duhet të kthehemi "në pikën 0". Filloni lojën nga e para.
Në jetë, ne shpesh priremi të fillojmë nga e para. Pse është e veçantë kjo për ne? Dhe a është vërtet kaq e keqe?
Aplikuar në IT. Për vetë sistemin - kjo mund të jetë shumë e mirë - aftësia për të rimenduar vendimet individuale. Sidomos kur ne mund ta bëjmë atë në nivel lokal. Rifaktorimi është procesi i zbërthimit të "webit" që shfaqet periodikisht në procesin e zhvillimit të sistemit. Kthimi në fillim mund të jetë i dobishëm. Por ka një çmim.
Me menaxhimin kompetent të arkitekturës, ky çmim ulet - dhe vetë procesi i zhvillimit të sistemit bëhet më i kontrollueshëm dhe transparent. Një shembull i thjeshtë: nëse respektohet parimi i modularitetit, mund të rishkruani një modul të veçantë pa ndikuar në ndërfaqet e jashtme. Dhe kjo nuk mund të bëhet me një strukturë monolit.

Antifragjiliteti i një sistemi përcaktohet nga arkitektura që është ngulitur në të. Dhe është kjo veti që e bën atë të adaptueshëm.
Kur flasim për arkitekturë adaptive- do të thotë që sistemi është në gjendje të përshtatet me ndryshimet, dhe aspak se ne vazhdimisht po e ndryshojmë vetë arkitekturën. Përkundrazi, sa më e qëndrueshme dhe e qëndrueshme të jetë arkitektura, aq më pak kërkesa që sjellin rishikimin e saj, aq më i përshtatshëm është sistemi.

Zgjidhjet që përfshijnë një rishikim të të gjithë arkitekturës do të kenë një çmim shumë më të lartë. Dhe ju duhet të keni arsye shumë të mira për adoptimin e tyre. Për shembull, një arsyetim i tillë mund të jetë një kërkesë që nuk mund të zbatohet brenda arkitekturës ekzistuese. Pastaj thonë - është shfaqur një kërkesë që ndikon në arkitekturë.
Kështu, ne gjithashtu duhet të dimë "kufijtë tanë të antibrishtshmërisë". Arkitektura nuk zhvillohet "në vakum" - ajo bazohet në kërkesat dhe pritjet aktuale. Dhe nëse situata ndryshon rrënjësisht - duhet të kuptojmë se kemi shkuar përtej arkitekturës aktuale - dhe duhet ta rishikojmë atë, të gjejmë një zgjidhje tjetër - dhe të mendojmë për shtigjet e tranzicionit.
Për shembull, ne supozuam se do të na duhen gjithmonë të dhëna në ruajtje në fund të ditës, ne do të marrim të dhëna çdo ditë duke përdorur ndërfaqet standarde të sistemit (përmes një grupi pamjesh). Më pas nga departamenti i menaxhimit të riskut erdhi kërkesa për nevojën për të marrë të dhëna jo në fund të ditës, por në momentin e vendimit për kreditimin. Nuk ka nevojë të përpiqeni të "tërheqni të patensionuarin" - thjesht duhet ta pranoni këtë fakt - sa më shpejt, aq më mirë. Dhe filloni të punoni në një qasje që do të na lejojë të zgjidhim problemin.
Këtu ka një vijë shumë të hollë - nëse marrim parasysh vetëm "kërkesat e momentit" dhe nuk shikojmë disa hapa përpara (dhe disa vite përpara), atëherë rrisim rrezikun e përballjes me një kërkesë që prek arkitekturën shumë vonë - dhe çmimi i ndryshimit tonë do të jetë shumë i lartë. Të shikosh pak përpara - brenda kufijve të horizontit tonë - nuk ka lënduar ende askënd.

Shembulli i një sistemi nga "përralla e ruajtjes" është vetëm një shembull i një sistemi shumë të lëkundshëm të ndërtuar mbi qasje të brishta të projektimit. Dhe nëse kjo ndodh, shkatërrimi ndodh mjaft shpejt, për këtë klasë të veçantë sistemesh.
Pse mund të them kështu? Tema e depove nuk është e re. Qasjet dhe praktikat inxhinierike që janë zhvilluar gjatë kësaj kohe synonin pikërisht këtë - ruajtjen e qëndrueshmërisë së sistemit.
Një shembull i thjeshtë: Një nga arsyet më të zakonshme për dështimin e projekteve të ruajtjes së ngritjes është përpjekja për të ndërtuar memorie mbi sistemet burimore të zhvillimit pa rënë dakord për ndërfaqet e integrimit - duke u përpjekur të merrni të dhëna direkt nga tabelat. Si rezultat, ne shkuam në zhvillim - gjatë kësaj kohe baza e të dhënave burimore ndryshoi - dhe rrjedhat e ngarkimit në depo u bënë jofunksionale. Është tepër vonë për të ribërë diçka. Dhe nëse nuk e keni siguruar ende veten duke bërë disa shtresa tavolina brenda ruajtjes, atëherë mund të hidhni gjithçka jashtë dhe të filloni nga e para. Ky është vetëm një shembull dhe një nga më të thjeshtët.

Kriteri Taleb për të brishtë dhe antifragjil është i thjeshtë. Gjyqtari kryesor është koha. Nëse sistemi i reziston provës së kohës dhe tregon "vitalitetin" dhe "pashkatërrueshmërinë" e tij - ai ka vetinë e antifragjilitetit.
Nëse, kur hartojmë një sistem, marrim parasysh antifragjilitetin si kërkesë, kjo do të na inkurajojë të përdorim qasje të tilla për ndërtimin e arkitekturës së tij që do ta bëjnë sistemin më të adaptueshëm si ndaj "kaosit nga jashtë" dhe ndaj "kaosit nga brenda". . Dhe në fund të fundit sistemi do të ketë një jetëgjatësi më të gjatë.
Askush nga ne nuk dëshiron të bëjë “shtëpi të improvizuara”. Dhe mos e mashtroni veten, gjë që nuk është ndryshe sot. Është normale që një person të shikojë disa hapa përpara në çdo kohë, veçanërisht gjatë një krize.

Çfarë është një depo e të dhënave dhe pse po e ndërtojmë atë

Artikulli mbi arkitekturën e ruajtjes supozon që lexuesi jo vetëm që e di se çfarë është, por gjithashtu ka një përvojë me sisteme të tilla. Sidoqoftë, e konsiderova të nevojshme ta bëj këtë - të kthehem në origjinën, në fillimin e rrugës, sepse pikërisht aty ndodhet “pika mbështetëse” e zhvillimit.

Si erdhën njerëzit në idenë se nevojiten depot e të dhënave? Dhe si ndryshojnë ato nga thjesht një "bazë e të dhënave shumë e madhe"?
Shumë kohë më parë, kur në botë ekzistonin thjesht "sisteme të përpunimit të të dhënave të biznesit", nuk kishte ndarje të sistemeve të IT në klasa të tilla si sistemet oltp të përparme, dss-të e back-office, sistemet e përpunimit të tekstit, magazinat e të dhënave, etj.
Ishte gjatë kësaj kohe që motori i parë i bazës së të dhënave relacionale, Ingres, u krijua nga Michael Stonebreaker.
Dhe kjo ishte koha kur epoka e kompjuterëve personal shpërtheu në industrinë e kompjuterave si një vorbull dhe ndryshoi përgjithmonë të gjitha idetë e komunitetit të IT të asaj kohe.

Në atë kohë ishte e lehtë të gjeje aplikacione të ndërmarrjeve të shkruara në bazë të DBMS-ve të klasës desktop, si Clipper, dBase dhe FoxPro. Dhe tregu për aplikacionet klient-server dhe DBMS po fitonte vetëm vrull. Serverët e bazës së të dhënave u shfaqën njëri pas tjetrit, të cilët do të zënë vendin e tyre në hapësirën e IT për një kohë të gjatë - Oracle, DB2, etj.
Dhe termi "aplikacion i bazës së të dhënave" ka qenë i zakonshëm. Çfarë përfshinte një aplikim i tillë? Të thjeshtuara - disa forma hyrëse përmes të cilave përdoruesit mund të fusnin njëkohësisht informacione, disa llogaritje që u nisën "me buton" ose "në orar", si dhe disa raporte që mund të shiheshin në ekran ose të ruheshin si skedarë dhe të dërgoheshin për t'u vulosur.
"Asgjë e veçantë - vetëm një aplikacion i rregullt, vetëm një bazë të dhënash," tha një nga mentorët e mi në fillim të karrierës sime. "Pra, asgjë e veçantë?" - Mendova atëherë.

Nëse shikoni nga afër, ka ende disa veçori. Ndërsa përdoruesit rriten, vëllimi i informacionit hyrës rritet, ndërsa ngarkesa në sistem rritet, zhvilluesit, projektuesit e tij, për të ruajtur performancën në një nivel të pranueshëm, kalojnë në disa "mashtrime". E para është ndarja e një "sistemi të përpunimit të të dhënave të biznesit" monolit në një aplikacion kontabiliteti që mbështet punën në internet të përdoruesve, dhe një aplikacion për përpunimin grupor të të dhënave dhe raportimin ndahet veçmas. Secili prej këtyre aplikacioneve ka bazën e tij të të dhënave dhe madje është pritur në një shembull të veçantë të serverit të bazës së të dhënave, me cilësime të ndryshme për lloje të ndryshme ngarkese - OLTP dhe DSS. Dhe rrjedhat e të dhënave rreshtohen midis tyre.

Është e gjitha? Duket se problemi është zgjidhur. Çfarë ndodh më pas?
Dhe më pas kompanitë rriten, nevojat e tyre për informacion shumohen. Numri i ndërveprimeve me botën e jashtme është gjithashtu në rritje. Dhe si rezultat, nuk ka një aplikacion të madh që automatizon plotësisht të gjitha proceset, por disa të ndryshme nga prodhues të ndryshëm. Numri i sistemeve që gjenerojnë informacion - sistemet burimore të të dhënave në kompani po rritet. Dhe herët a vonë, do të ketë nevojë për të parë dhe krahasuar informacionin e marrë nga sisteme të ndryshme. Kështu shfaqen në kompani magazinat e të dhënave - një klasë e re sistemesh.
Përkufizimi i pranuar përgjithësisht i kësaj klase sistemesh është si më poshtë.

Magazina e të Dhënave (ose Magazina e të Dhënave)- një bazë të dhënash informacioni e orientuar nga lënda, e krijuar dhe projektuar posaçërisht për përgatitjen e raporteve dhe analizave të biznesit në mënyrë që të mbështesë vendimmarrjen në një organizatë

Në këtë mënyrë, konsolidimi të dhëna nga sisteme të ndryshme, aftësia për t'i parë ato në një mënyrë të caktuar "uniforme" (të unifikuar) - kjo është një nga vetitë kryesore të sistemeve të klasës së depove të të dhënave. Kjo është arsyeja pse depot janë shfaqur gjatë evolucionit të sistemeve të IT.

Karakteristikat kryesore të magazinës së të dhënave

Le të hedhim një vështrim më të afërt. Cilat janë veçoritë kryesore të këtyre sistemeve? Çfarë i bën magazinat e të dhënave të ndryshme nga sistemet e tjera të IT të ndërmarrjeve?

Së pari, këto janë vëllime të mëdha. Shume e madhe. VLDB - kështu i quajnë shitësit kryesorë sisteme të tilla kur japin rekomandimet e tyre për përdorimin e produkteve të tyre. Nga të gjitha sistemet e kompanisë, të dhënat derdhen në këtë bazë të dhënash të madhe dhe ruhen atje "përgjithmonë dhe të pandryshuara", siç thonë në tekstet shkollore (në praktikë, jeta rezulton të jetë më e ndërlikuar).

Së dyti, këto janë të dhëna historike - "Kujtesa e korporatës" - të ashtuquajturat depo të të dhënave. Për sa i përket punës me kohën në depo, gjithçka është mjaft interesante. Në sistemet e kontabilitetit, të dhënat janë të përditësuara për momentin. Pastaj përdoruesi kryen një operacion - dhe të dhënat përditësohen. Në të njëjtën kohë, historia e ndryshimeve mund të mos ruhet - kjo varet nga praktika e kontabilitetit. Merrni një gjendje të llogarisë bankare, për shembull. Ne mund të jemi të interesuar për bilancin aktual në "tani", në fund të ditës ose në kohën e ndonjë ngjarjeje (për shembull, në kohën e llogaritjes së rezultatit). Ndërsa dy të parat janë mjaft të lehta për t'u zgjidhur, kjo e fundit ka shumë të ngjarë të kërkojë përpjekje të veçanta. Përdoruesi, duke punuar me ruajtjen, mund t'i referohet periudhave të kaluara, t'i krahasojë ato me atë aktuale, etj. Janë këto aftësi të lidhura me kohën që dallojnë ndjeshëm magazinat e të dhënave nga sistemet e kontabilitetit - marrja e gjendjes së të dhënave në pika të ndryshme të boshtit kohor - në një thellësi të caktuar në të kaluarën.

Së treti, është konsolidimi dhe unifikimi i të dhënave ... Në mënyrë që analiza e tyre e përbashkët të bëhet e mundur, është e nevojshme që ato të sillen në një formë të përbashkët - modeli i unifikuar i të dhënave , krahasoni faktet me librat e unifikuar të referencës. Këtu mund të ketë disa aspekte dhe vështirësi. Kryesisht - konceptuale - nën të njëjtin term, njerëz të ndryshëm nga departamente të ndryshme mund të kuptojnë gjëra të ndryshme. Dhe anasjelltas - të quash diçka ndryshe, që në thelb është e njëjta gjë. Si të sigurohet një "pamje e vetme" duke ruajtur vizionin specifik të një grupi të caktuar përdoruesish?

Së katërti, kjo është punë me cilësinë e të dhënave ... Në procesin e ngarkimit të të dhënave në ruajtje, ato pastrohen, kryhen transformime dhe transformime të përgjithshme. Transformimet e përgjithshme duhet të bëhen në një vend - dhe më pas të përdoren për të ndërtuar raporte të ndryshme. Kjo do të shmangë mospërputhjet që shqetësojnë përdoruesit e biznesit - veçanërisht drejtuesit që sillen në tryezë me numra nga departamente të ndryshme që nuk pajtohen me njëri-tjetrin. Cilësia e dobët e të dhënave krijon gabime dhe mospërputhje në raporte, pasojë e të cilave është një ulje e nivelit besimi i përdoruesit për të gjithë sistemin, për të gjithë shërbimin analitik në tërësi.

Koncepti arkitektonik

Kushdo që ka hasur në një depo ka shumë të ngjarë të ketë vëzhguar një lloj "strukture me shtresa" - pasi është kjo paradigmë arkitekturore që ka zënë rrënjë për sistemet e kësaj klase. Dhe nuk është rastësi. Shtresat e ruajtjes mund të perceptohen si përbërës të veçantë të sistemit - me detyrat e tyre, fushën e përgjegjësisë, "rregullat e lojës".
Arkitektura me shtresa është një mjet për t'u marrë me kompleksitetin e sistemit - çdo nivel pasues është abstraguar nga kompleksiteti i zbatimit të brendshëm të atij të mëparshmi. Kjo qasje ju lejon të veçoni detyra të të njëjtit lloj dhe t'i zgjidhni ato në një mënyrë uniforme, pa e rishpikur "rrotën" nga e para çdo herë.
Diagrami konceptual arkitektonik është paraqitur në mënyrë skematike në figurë. Ky është një diagram i thjeshtuar që pasqyron vetëm idenë kryesore – konceptin, por pa “detajet anatomike” që do të lindnin me shtjellimin më të thellë të detajeve.

Siç tregohet në diagram, zgjidhni konceptualisht shtresat e mëposhtme. Tre shtresat kryesore që përmbajnë zonën e ruajtjes së të dhënave (treguar nga drejtkëndëshi i mbushur) dhe softueri i ngarkimit të të dhënave (i treguar në mënyrë konvencionale nga shigjetat me të njëjtën ngjyrë). Dhe gjithashtu një shtresë ndihmëse - shërbimi, e cila, megjithatë, luan një rol shumë të rëndësishëm lidhës - menaxhimi i ngarkesës së të dhënave dhe kontrolli i cilësisë.

Primary Data Layer - shtresa primare e të dhënave (ose vënien në skenë , ose shtresa operative ) - projektuar për të ngarkuar nga sistemet burimore dhe për të ruajtur informacionin parësor, pa transformime - në cilësinë origjinale dhe për të mbështetur një histori të plotë ndryshimesh.
Detyra e kësaj shtrese- të abstragojë shtresat pasuese të ruajtjes nga struktura fizike e burimeve të të dhënave, metodat e mbledhjes së të dhënave dhe metodat e ndarjes së deltës së ndryshimeve.

Shtresa kryesore e të dhënave - ruajtja thelbësore - komponenti qendror i sistemit që e dallon ruajtjen nga thjesht një "platformë e integrimit të grupeve" ose "depo e madhe e të dhënave", pasi roli i tij kryesor është konsolidimi i të dhënave nga burime të ndryshme, reduktim në struktura uniforme, çelësa. Është kur ngarkohet në kernel puna kryesore me cilësinë e të dhënave dhe transformimet e përgjithshme, të cilat mund të jenë mjaft komplekse.
Detyra e kësaj shtrese- të abstragojnë konsumatorët e tyre nga veçoritë e pajisjes logjike të burimeve të të dhënave dhe nevoja për të krahasuar të dhënat nga sisteme të ndryshme, për të siguruar integritetin dhe cilësinë e të dhënave.

Shtresa e të dhënave Mart - vitrina analitike - një komponent, funksioni kryesor i të cilit është shndërrimi i të dhënave në struktura që janë të përshtatshme për analizë (nëse BI punon me vitrina, atëherë ky është, si rregull, një model dimensional), ose sipas kërkesave të sistemit të konsumatorit.
Si rregull, data marts marrin të dhëna nga thelbi - si një burim i besueshëm dhe i verifikuar - d.m.th. përdorni shërbimin e këtij komponenti për të sjellë të dhënat në një formë të vetme. Ne do t'i quajmë vitrina të tilla e rregullt ... Në disa raste, vitrinat e dyqaneve mund të marrin të dhëna drejtpërdrejt nga skeda - duke funksionuar me të dhënat primare (në çelësat burimor). Kjo qasje zakonisht përdoret për detyra lokale ku nuk kërkohet konsolidimi i të dhënave nga sisteme të ndryshme dhe ku nevojitet efikasitet më shumë se cilësia e të dhënave. Vitrat e tilla quhen operativ ... Disa tregues analitikë mund të kenë metoda shumë komplekse llogaritjeje. Prandaj, për llogaritjet dhe transformimet e tilla jo të parëndësishme, të ashtuquajturat vitrinë dytësore .
Detyra e shtresës së vitrinës- përgatitja e të dhënave sipas kërkesave të një konsumatori specifik - një platformë BI, një grup përdoruesish ose një sistem të jashtëm.

Shtresat e përshkruara më sipër përbëhen nga një zonë e ruajtjes së vazhdueshme të të dhënave, si dhe një modul softuerësh për ngarkimin dhe transformimin e të dhënave. Kjo ndarje në shtresa dhe rajone është logjike. Fizikisht, zbatimi i këtyre komponentëve mund të jetë i ndryshëm - madje mund të përdorni platforma të ndryshme për ruajtjen ose transformimin e të dhënave në shtresa të ndryshme, nëse kjo është më efikase.
Zonat e ruajtjes përmbajnë teknikë (tabela buffer) që përdoren në procesin e transformimit të të dhënave dhe tabelat e synuara të cilit i referohet komponenti konsumues. Është praktikë e mirë të "mbulosh" tabelat e synuara me pamje. Kjo lehtëson mirëmbajtjen dhe zhvillimin e mëvonshëm të sistemit. Të dhënat në tabelat e synuara të të tre shtresave janë shënuar me fusha të veçanta teknike (meta-atribute), të cilat përdoren për të mbështetur proceset e ngarkimit të të dhënave, si dhe për të mundësuar auditimin informativ të flukseve të të dhënave në magazinë.

Gjithashtu, dallohet një komponent i veçantë (ose një grup përbërësish), i cili ofron funksione shërbimi për të gjitha shtresat. Një nga detyrat e tij kryesore është funksioni i kontrollit - të sigurojë "rregulla uniforme të lojës" për të gjithë sistemin në tërësi, duke lënë të drejtën për të përdorur opsione të ndryshme për zbatimin e secilës prej shtresave të përshkruara më sipër - përfshirë. përdorin teknologji të ndryshme për ngarkimin dhe përpunimin e të dhënave, platforma të ndryshme ruajtjeje etj. Le ta quajmë atë shtresa e shërbimit ... Ai nuk përmban të dhëna biznesi, por ka strukturat e veta të ruajtjes - përmban një zonë meta të dhënash, si dhe një zonë për të punuar me cilësinë e të dhënave (dhe ndoshta struktura të tjera, në varësi të funksioneve që i janë caktuar).

Një ndarje e tillë e qartë e sistemit në komponentë të veçantë rrit ndjeshëm kontrollueshmërinë e zhvillimit të sistemit:

• kompleksiteti i detyrës që i shtrohet zhvilluesit të funksionalitetit të këtij apo atij komponenti është zvogëluar (ai nuk duhet të zgjidhë njëkohësisht çështjet e integrimit me sistemet e jashtme, dhe të mendojë për procedurat e pastrimit të të dhënave dhe të mendojë për paraqitjen optimale të të dhënave për konsumatorët) - detyra është më e lehtë për t'u dekompozuar, vlerësuar dhe kryer një dërgesë të vogël;
• ju mund të lidheni me punën e interpretuesve të ndryshëm (dhe madje edhe ekipeve, ose kontraktorëve) - sepse kjo qasje ju lejon të paralelizoni në mënyrë efektive detyrat, duke zvogëluar ndikimin e tyre të ndërsjellë mbi njëri-tjetrin;
• prania e vendosjes së vazhdueshme në skenë ju lejon të lidhni shpejt burimet e të dhënave pa projektuar të gjithë bërthamën ose vitrinat për të gjithë zonën e temës, dhe më pas të përfundoni gradualisht ndërtimin e shtresave të mbetura sipas përparësive (për më tepër, të dhënat tashmë do të jenë në ruajtje - të disponueshme për analistët e sistemit, të cilët do të lehtësojnë shumë detyrat e zhvillimit të mëvonshëm të ruajtjes);
• prania e një bërthame lejon që e gjithë puna me cilësinë e të dhënave (si dhe gabimet dhe gabimet e mundshme) të fshihet nga vitrinat dhe nga përdoruesi përfundimtar, dhe më e rëndësishmja - duke përdorur këtë komponent si një burim të vetëm të dhënash për vitrinat e dyqaneve, mund të shmangni të dhënat problemet e konvergjencës për shkak të zbatimit të algoritmeve të zakonshme në një vend;
• theksimi i marsit ju lejon të merrni parasysh dallimet dhe specifikat e të kuptuarit të të dhënave që mund të kenë përdoruesit e departamenteve të ndryshme, dhe dizajni i tyre për kërkesat e BI-së lejon jo vetëm nxjerrjen e shifrave të përmbledhura, por sigurimin e vërtetimit të të dhënave duke ofruar mundësi për të zbuluar tek treguesit parësorë;
• prania e një shtrese shërbimi ju lejon të kryeni analiza të të dhënave nga skaji në fund (linja e të dhënave), të përdorni mjete të unifikuara të auditimit të të dhënave, qasje të përgjithshme për të theksuar ndryshimet e delta, të punoni me cilësinë e të dhënave, menaxhimin e ngarkesës, monitorimin dhe mjetet e diagnostikimit të gabimeve, dhe përshpejtoni zgjidhjen e problemit.

Kjo qasje ndaj dekompozimit gjithashtu e bën sistemin më rezistent ndaj ndryshimeve (në krahasim me "strukturën monolit") - siguron antifragjilitetin e tij:

• ndryshimet nga ana e sistemeve burimore përpunohen në skenë - në kernel, modifikohen vetëm ato flukse që ndikohen nga këto tabela skedimi, efekti në vitrinat e dyqaneve është minimal ose mungon;
• ndryshimet në kërkesat nga ana e konsumatorëve përpunohen në pjesën më të madhe në vitrina (nëse kjo nuk kërkon informacion shtesë që nuk është ende në dyqan).

Më tej, ne do të shqyrtojmë secilin nga komponentët e paraqitur më sipër dhe do t'i hedhim një vështrim pak më të detajuar.

Bërthama e sistemit

Le të fillojmë nga mesi - thelbi i sistemit ose shtresa e mesme. Ajo është etiketuar si shtresa kryesore. Kerneli luan rolin e konsolidimit të të dhënave - duke sjellë struktura uniforme, libra referimi, çelësa. Këtu kryhet puna kryesore me cilësinë e të dhënave - pastrimi, transformimi, unifikimi.

Prania e këtij komponenti ju lejon të ripërdorni rrjedhat e të dhënave që transformojnë të dhënat parësore të marra nga sistemet burimore në një format të caktuar të unifikuar, duke ndjekur rregulla dhe algoritme të përgjithshme, dhe të mos përsërisni zbatimin e të njëjtit funksionalitet veçmas për çdo vitrinë të aplikacionit, i cili, në Përveç përdorimit joefikas të burimeve, mund të sjellë edhe mospërputhje në të dhëna.
Thelbi i depove zbatohet në një model të dhënash, në rastin e përgjithshëm, i ndryshëm si nga modelet e sistemeve burimore, ashtu edhe nga formatet dhe strukturat e konsumatorëve.

Modeli kryesor i magazinës dhe modeli i të dhënave të ndërmarrjes

Shqetësimi kryesor i shtresës së mesme të ruajtjes është stabiliteti. Kjo është arsyeja pse fokusi kryesor këtu është në modelin e të dhënave. Zakonisht quhet "modeli i të dhënave të korporatës". Për fat të keq, rreth tij është krijuar një lloj atmosfere mitesh dhe absurditetesh, të cilat ndonjëherë çojnë në një refuzim për ta ndërtuar atë fare, por më kot.

Miti 1. Një model i të dhënave të ndërmarrjes është një model i madh me mijëra entitete (tabela).
Në fakt. Në çdo fushë lëndore, në çdo fushë biznesi, në të dhënat e çdo kompanie, madje edhe më komplekse, ka pak entitete bazë - 20-30.

Miti 2. Nuk ka nevojë të zhvillojmë ndonjë "model të vetin" - ne blejmë një model referimi të industrisë - dhe bëjmë gjithçka sipas tij. Ne shpenzojmë para - por marrim një rezultat të garantuar.
Në fakt. Modelet e referencës mund të jenë vërtet shumë të dobishme sepse përmbajnë përvojën e industrisë në modelimin e kësaj fushe. Prej tyre mund të grumbulloni ide, qasje, praktika emërtimi. Kontrolloni "thellësinë e mbulimit" të zonës në mënyrë që diçka e rëndësishme të mos anashkalohet. Por nuk ka gjasa të jemi në gjendje të përdorim një model të tillë jashtë kutisë - siç është. Ky është i njëjti mit si, për shembull, blerja e një sistemi ERP (ose CRM) dhe zbatimi i tij pa ndonjë "shtrëngim për veten tuaj". Vlera e modeleve të tilla lind në përshtatjen e tyre me realitetet e këtij biznesi të veçantë, kësaj kompanie të veçantë.

Miti 3. Zhvillimi i një modeli të depove bazë mund të zgjasë shumë muaj, kohë gjatë së cilës projekti në fakt do të ngrijë. Plus, kërkon një sasi të çmendur takimesh dhe shumë njerëz.
Në fakt. Modeli i depove mund të zhvillohet me depo në mënyrë të përsëritur, pjesë-pjesë. Për zonat e pambuluara, vendosen "pikat e zgjerimit" ose "cungët". aplikohen disa “dizajn universale”. Në të njëjtën kohë, duhet të dini se kur të ndaloni në mënyrë që të mos merrni një gjë super-universale prej 4 tabelash, në të cilat është e vështirë të "vendosësh të dhëna" dhe (edhe më e vështirë) t'i marrësh ato. Dhe e cila është jashtëzakonisht jooptimale për sa i përket performancës.

Duhet vërtet kohë për të zhvilluar modelin. Por kjo nuk është koha e shpenzuar për "vizatimin e subjekteve" - ​​kjo është koha e nevojshme për të analizuar fushën e temës, duke kuptuar se si janë rregulluar të dhënat. Prandaj në këtë proces janë përfshirë shumë analistët dhe janë përfshirë edhe ekspertë të ndryshëm të biznesit. Dhe kjo bëhet në mënyrë selektive. Dhe jo duke organizuar takime me pjesëmarrjen e një numri të çmendur njerëzish, duke dërguar pyetësorë të mëdhenj, etj.
Analiza e mirë e biznesit dhe e sistemeve është thelbësore në ndërtimin e një modeli kryesor të magazinës. Ka shumë për të kuptuar: ku (në çfarë sistemesh) gjenerohen të dhënat, si funksionojnë, në cilat procese biznesi qarkullojnë, etj. Analiza cilësore nuk ka dëmtuar kurrë një sistem të vetëm. Përkundrazi, përkundrazi, problemet lindin nga "njollat ​​e bardha" në kuptimin tonë.

Zhvillimi i një modeli të dhënash nuk është një proces i shpikjes dhe shpikjes së diçkaje të re. Në fakt, modeli i të dhënave tashmë ekziston në kompani. Dhe procesi i projektimit është më shumë si "gërmimi". Modeli nxirret me kujdes dhe kujdes nga "toka" e të dhënave të korporatës dhe vendoset në një formë të strukturuar.

Miti 4. Biznesi ynë është kaq dinamik në kompaninë tonë dhe gjithçka po ndryshon aq shpejt sa është e kotë për ne të bëjmë një model - ai do të bëhet i vjetëruar përpara se ta vëmë në funksion këtë pjesë të sistemit.
Në fakt. Kujtojmë se faktori kryesor është stabiliteti. Dhe mbi të gjitha, topologjia e modelit. Pse? Sepse është ky komponent që është qendror dhe ndikon në gjithçka tjetër. Stabiliteti është gjithashtu një kërkesë për modelin e kernelit. Nëse një model vjetërohet shumë shpejt, atëherë ai është projektuar gabimisht. Për zhvillimin e tij u zgjodhën qasjet dhe “rregullat e lojës” të gabuara. Dhe është gjithashtu një çështje e analizës cilësore. Subjektet kryesore të modelit të korporatës rrallë ndryshojnë.
Por nëse na shkon mendja të bëjmë për një kompani që shet, të themi, ëmbëlsira, në vend të drejtorisë “Produkte”, të bëjmë “Ëmbëlsirat”, “Tortat” dhe “Pitet”. Pastaj kur pica shfaqet në listën e mallrave - po, do t'ju duhet të futni shumë tabela të reja. Dhe kjo është vetëm çështje qasjeje.

Miti 5. Krijimi i një modeli korporativ është një biznes shumë serioz, kompleks dhe i përgjegjshëm. Dhe është e frikshme të bësh një gabim.
Në fakt. Modeli bërthamë, megjithëse duhet të jetë i qëndrueshëm, ende nuk është "i derdhur në metal". Ashtu si çdo zgjidhje tjetër e projektimit, struktura e saj mund të rishikohet dhe modifikohet. Ju thjesht nuk keni nevojë të harroni për këtë cilësi të tij. Por kjo nuk do të thotë aspak se "nuk mund të marrësh frymë mbi të". Dhe kjo nuk do të thotë se zgjidhjet e përkohshme dhe "cungët" që duhet të planifikohen për riciklim janë të papranueshme.

Miti 6. Nëse burimi ynë i të dhënave është, për shembull, një sistem i të dhënave referencë (ose një sistem master i menaxhimit të të dhënave - MDM), atëherë ai tashmë duhet të korrespondojë me modelin e korporatës në një mënyrë miqësore (veçanërisht nëse është projektuar kohët e fundit dhe nuk ka pasur kohë për të fitojnë një "anës", "traditat "Dhe kasolle të përkohshme). Rezulton se për këtë rast - nuk kemi nevojë për një model kernel?
Në fakt. Po, në këtë rast, ndërtimi i modelit bazë të depove lehtësohet shumë - pasi ne ndjekim një model konceptual të gatshëm të nivelit të lartë. Por nuk përjashtohet aspak. Pse? Sepse kur ndërtohet një model i një sistemi të caktuar, zbatohen disa nga rregullat e veta - çfarë lloje tabelash të përdoren (për secilin entitet), si të versiononi të dhënat, me çfarë granulariteti të mbani historinë, cilat meta-atribute (fusha teknike për t'u përdorur), etj.

Për më tepër, pa marrë parasysh se sa i mrekullueshëm dhe gjithëpërfshirës është sistemi i të dhënave të referencës dhe MDM që kemi, si rregull, do të ketë nuanca që lidhen me ekzistencën e drejtorive lokale "pothuajse të njëjta" në sistemet e tjera të kontabilitetit. Dhe ky problem, pavarësisht nëse duam apo jo, do të duhet të zgjidhet në depo - në fund të fundit, raportimi dhe analitika janë mbledhur këtu.

Shtresa primare e të dhënave (ose nivelimi historik ose shtresa operacionale)

Mbi të është caktuar si Shtresa e të Dhënave Primare. Roli i këtij komponenti: integrimi me sistemet burimore, ngarkimi dhe ruajtja e të dhënave parësore, si dhe pastrimi paraprak i të dhënave - kontrolli për pajtueshmërinë me rregullat e formatit dhe kontrollit logjik, të fiksuar në "marrëveshjen për ndërfaqen e ndërveprimit" me burimin. .
Për më tepër, ky komponent zgjidh një detyrë shumë të rëndësishme për depon - shpërndarjen e "deltës së vërtetë të ndryshimeve" - ​​pavarësisht nëse burimi ju lejon të gjurmoni ndryshimet në të dhëna apo jo dhe si (me çfarë kriteri ato mund të "kapen" ). Sapo të dhënat hynë në skenë - për të gjitha shtresat e tjera, çështja e alokimit të delta është tashmë e qartë - falë etiketimit me meta-atribute.

Të dhënat në këtë shtresë ruhen në struktura sa më afër sistemit burimor - me qëllim që të dhënat primare të ruhen sa më afër formës së tyre origjinale. Një emër tjetër për këtë komponent është "shtresa operative".
Pse të mos përdorni thjesht termin e mirëpërcaktuar "vënie në skenë"? Fakti është se më parë, para "epokës së të dhënave të mëdha dhe VLDB", hapësira në disk ishte shumë e shtrenjtë - dhe shpesh të dhënat primare, nëse ruheshin, ishin vetëm për një periudhë të kufizuar kohore. Dhe shpesh quhet emri "inskenim". e pastrueshme tampon.
Tani teknologjitë kanë ecur përpara - dhe ne mund të përballojmë jo vetëm që të ruajmë të gjitha të dhënat parësore, por t'i historizojmë ato me shkallën e grimcimit që është e mundur. Kjo nuk do të thotë që ne nuk duhet të kontrollojmë rritjen e të dhënave dhe nuk eliminon nevojën për të menaxhuar ciklin jetësor të informacionit, duke optimizuar koston e ruajtjes së të dhënave, në varësi të "temperaturës" së përdorimit - dmth. marrjen e "të dhënave të ftohta" që janë më pak të kërkuara për mediat më të lira dhe platformat e ruajtjes.

Çfarë na jep prania e “inskenimit të historizuar”:

• mundësia për të bërë gabime (në struktura, në algoritmet e transformimit, në granularitetin e historisë) - duke pasur të dhëna primare të historizuara plotësisht në zonën e disponueshmërisë për ruajtje, ne gjithmonë mund të ringarkojmë tabelat tona;
• një mundësi për të menduar - ne mund të marrim kohën tonë për të përpunuar një fragment të madh të kernelit në këtë përsëritje të veçantë të zhvillimit të ruajtjes, pasi në vënien tonë në skenë, gjithsesi, do të ketë dhe me një horizont kohor të barabartë (do të ketë një pikë "referencimi të historisë");
• mundësia e analizës - do të ruajmë edhe ato të dhëna që nuk janë më në burim - ato mund të mbishkruhen atje, të shkojnë në arkiv, etj. - tek ne, ato mbeten të disponueshme për analiza;
• mundësia e një auditimi informacioni - falë informacionit fillestar më të detajuar, më pas mund të kuptojmë se si ka funksionuar shkarkimi për ne, që përfundimisht kemi marrë shifra të tilla (për këtë, gjithashtu duhet të kemi shënime me meta-atribute dhe përkatëse meta të dhënat mbi të cilat funksionon shkarkimi - kjo vendoset nga shtresa e shërbimit).

Çfarë vështirësish mund të lindin kur ndërtohet një "vënë në skenë e historizuar":

• do të ishte e përshtatshme të vendoseshin kërkesa për integritetin transaksional të kësaj shtrese, por praktika tregon se kjo është e vështirë për t'u arritur (kjo do të thotë se në këtë fushë ne nuk garantojmë integritetin referues të tabelave të prindërve dhe fëmijëve) - rreshtimi i integritetit ndodh në vijim shtresa;
• kjo shtresë përmban vëllime shumë të mëdha (më voluminozët në ruajtje - pavarësisht nga teprica e strukturave analitike) - dhe ju duhet të jeni në gjendje të trajtoni vëllime të tilla - si për sa i përket ngarkesës ashtu edhe për sa i përket kërkesave (përndryshe, mundeni seriozisht degradojnë performancën e të gjithë ruajtjes).

Çfarë tjetër është interesante të thuhet për këtë shtresë.
Së pari, nëse largohemi nga paradigma e "proceseve të ngarkimit nga fundi në fund", atëherë rregulli "karvani lëviz me shpejtësinë e devesë së fundit" nuk funksionon më për ne, më saktë, ne braktisim "karvanin". parimi dhe kaloni në parimin "transportues": ne morëm të dhëna nga burimi - vendosëm në shtresën tuaj - gati për të marrë pjesën tjetër. Do të thotë se
1) nuk presim që përpunimi të ndodhë në shtresa të tjera;
2) nuk jemi të varur nga orari për sigurimin e të dhënave nga sisteme të tjera.
E thënë thjesht, ne planifikojmë një proces ngarkimi që merr të dhëna nga një burim përmes një mënyre specifike për t'u lidhur me të, kontrollon, nxjerr deltën - dhe vendos të dhënat në tabelat e vendosjes së synimeve. Dhe kjo eshte e gjitha.

Së dyti, këto procese, siç mund ta shihni, janë shumë të thjeshta - mund të thuhet në mënyrë të parëndësishme, nga pikëpamja e logjikës. Kjo do të thotë se ato mund të optimizohen dhe parametrizohen shumë mirë, duke ulur ngarkesën në sistemin tonë dhe duke përshpejtuar procesin e lidhjes së burimeve (koha e zhvillimit).
Që kjo të ndodhë, duhet të njihni shumë mirë veçoritë e veçorive teknologjike të platformës në të cilën funksionon ky komponent - dhe më pas mund të bëni një mjet shumë efektiv.

Shtresa e vitrinës

Shtresa e të dhënave Mart është përgjegjëse për përgatitjen dhe ofrimin e të dhënave për përdoruesit përfundimtarë - njerëzit ose sistemet. Në këtë nivel, kërkesat e konsumatorit merren parasysh sa më shumë që të jetë e mundur - si logjike (konceptuale) dhe fizike. Shërbimi duhet të ofrojë saktësisht atë që nevojitet - jo më shumë, as më pak.

Nëse konsumatori është një sistem i jashtëm, atëherë, si rregull, ai dikton strukturat e të dhënave që i nevojiten dhe rregullat për mbledhjen e informacionit. Një qasje e mirë është ajo në të cilën konsumatori është përgjegjës për mbledhjen e saktë të të dhënave. Magazina e të dhënave u përgatit, formoi një vitrinë, ofroi mundësinë e mbledhjes së të dhënave në rritje (shënjimi me meta-atribute për nënvizimin e mëvonshëm të deltës së ndryshimeve), dhe më pas vetë sistemi i konsumatorit kontrollon dhe është përgjegjës për mënyrën se si e përdor këtë vitrinë. Por ka veçori: kur sistemi nuk ka një komponent aktiv për mbledhjen e të dhënave - ose nevojitet një komponent i jashtëm që do të kryejë funksionin integrues, ose ruajtja do të veprojë si një "platformë integrimi" - dhe do të sigurojë të dhënat e sakta shtesë. ngarkoni më tej - jashtë hapësirës ruajtëse. Këtu shfaqen shumë nuanca dhe rregullat e ndërveprimit të ndërfaqes duhet të mendohen dhe kuptohen nga të dyja palët (megjithatë, si gjithmonë, kur bëhet fjalë për integrimin). Si rregull, pastrimi / arkivimi rutinë i të dhënave zbatohet në marte të tilla të dhënash (rrallë është e nevojshme që këto "të dhëna tranziti" të ruhen për një kohë të gjatë).

Më të rëndësishmet nga pikëpamja e detyrave analitike janë vitrinat "për njerëzit" - më saktë, për mjetet e BI me të cilat ata punojnë.
Sidoqoftë, ekziston një kategori "përdoruesish veçanërisht të avancuar" - analistë, studiues të të dhënave - të cilët nuk kanë nevojë për mjete BI ose procese rregullatore për plotësimin e sistemeve të specializuara të jashtme. Ata kanë nevojë për një lloj "vitrine të përbashkët" dhe "kutinë e tyre të rërës", ku mund të krijojnë tabela dhe transformime sipas gjykimit të tyre. Në këtë rast, përgjegjësia e depove është të sigurojë që këto vitrina të zakonshme të dyqaneve të jenë të mbushura me të dhëna në përputhje me rregulloret.
Më vete, ne mund të theksojmë konsumatorë të tillë si mjetet e Minierave të të Dhënave - analiza e thellë e të dhënave. Këto mjete kanë kërkesat e tyre për përgatitjen e të dhënave, dhe shkencëtarët e të dhënave gjithashtu punojnë me to. Për ruajtjen, detyra zbret në - përsëri, mbështetje për shërbimin për ngarkimin e disa vitrinave të formatit të rënë dakord.

Megjithatë, kthehemi te vitrinat analitike. Këto janë ato që janë me interes nga këndvështrimi i projektuesve të ruajtjes në këtë shtresë të të dhënave.
Sipas mendimit tim, qasja më e mirë e testuar me kohë për të hartuar marte të dhënash, tek e cila pothuajse të gjitha platformat e BI-së tani janë "mprehur", është qasja e Ralph Kimball. Njihet si modelimi dimensional - modelimi shumëdimensional. Ka shumë botime për këtë temë. Për shembull, rregullat bazë mund të gjenden në botimin e Marga Ross. Dhe sigurisht, ju mund të rekomandoni nga guru i modelimit shumëdimensional. Një burim tjetër i dobishëm janë Këshillat e Kimball
Qasja shumëdimensionale për krijimin e vitrinave është përshkruar dhe punuar aq mirë - si nga "ungjilltarët e metodës" dhe nga shitësit kryesorë të programeve kompjuterike, sa nuk ka kuptim të ndalemi në të në disa detaje këtu - burimi origjinal është gjithmonë i preferueshëm. .

Do të doja të bëja vetëm një theksim. "Raportimi dhe analitika" është ndryshe. Ekziston "raportim i rëndë" - raporte të porositura paraprakisht që krijohen në formën e skedarëve dhe u dorëzohen përdoruesve përmes kanaleve të ofruara të dorëzimit. Dhe pastaj ka panele - panele BI. Në thelbin e tyre, këto janë aplikacione në internet. Dhe koha e përgjigjes së këtyre aplikacioneve është e njëjtë si për çdo aplikacion tjetër në internet. Kjo do të thotë se koha normale për rifreskimin e një paneli BI është sekonda, jo minuta. Është e rëndësishme ta mbani parasysh këtë kur hartoni zgjidhjen tuaj. Si mund të arrihet kjo? Metoda standarde e optimizimit: ne shikojmë se nga përbëhet koha e përgjigjes dhe çfarë mund të ndikojmë. Cila është koha më e humbur? Për leximet fizike (disk) të bazës së të dhënave, për transmetimin e të dhënave përmes rrjetit. Si të zvogëloni sasinë e të dhënave të lexuara dhe të transmetuara në një kërkesë? Përgjigja është e qartë dhe e thjeshtë: ju duhet ose të grumbulloni të dhënat, ose të aplikoni një filtër në tabelat e mëdha të tabelave aktuale që marrin pjesë në pyetje dhe të përjashtoni bashkimin e tabelave të mëdha (referencat për tabelat e fakteve duhet të kalojnë vetëm përmes dimensioneve).

Për çfarë është BI? Si është i përshtatshëm? Pse është efektiv modeli shumëdimensional?
BI i lejon përdoruesit të ekzekutojë ato që quhen pyetje ad hoc. Çfarë do të thotë? Kjo do të thotë që ne nuk e dimë paraprakisht kërkesën e saktë, por dimë se cilët tregues në cilat aspekte mund të kërkojë përdoruesi. Përdoruesi gjeneron një pyetje të tillë duke zgjedhur filtrat e duhur të BI. Dhe detyra e zhvilluesit të BI dhe projektuesit të vitrinës është të ofrojnë një logjikë të tillë të aplikacionit në mënyrë që të dhënat ose të filtrohen ose të grumbullohen, duke parandaluar një situatë kur kërkohen shumë të dhëna - dhe aplikacioni "varet". Zakonisht, ata fillojnë me numra të përmbledhur, pastaj thellohen në të dhëna më të detajuara, por gjatë rrugës instaloni filtrat e nevojshëm.

Nuk mjafton gjithmonë thjesht të ndërtosh "yllin e duhur" dhe të marrësh një strukturë të përshtatshme për BI. Ndonjëherë do t'ju duhet të aplikoni denormalizimin diku (ndërsa shikoni se si kjo do të ndikojë në ngarkesë) dhe diku për të bërë vitrina dytësore dhe agregate. Shtoni indekse ose projeksione diku (në varësi të DBMS).

Kështu, përmes "provës dhe gabimit", mund të merrni një strukturë që është optimale për BI - e cila do të marrë parasysh veçoritë e DBMS dhe platformës BI, si dhe kërkesat e përdoruesit për prezantimin e të dhënave.
Nëse i marrim të dhënat nga "bërthama", atëherë përpunimi i tillë i vitrinave do të jetë i natyrës lokale, pa ndikuar në asnjë mënyrë në përpunimin kompleks të të dhënave primare të marra drejtpërdrejt nga sistemet burimore - ne vetëm "i zhvendosim" të dhënat në një format i përshtatshëm për BI. Dhe ne mund të përballojmë ta bëjmë këtë shumë herë, në mënyra të ndryshme, në përputhje me kërkesa të ndryshme. Është shumë më e lehtë dhe më e shpejtë për ta bërë këtë në të dhënat e kernelit sesa për të mbledhur nga "primare" (struktura dhe rregullat e së cilës, siç e dimë, gjithashtu mund të "lundrojnë").

Shtresa e shërbimit

Shtresa e Shërbimit është përgjegjës për zbatimin e funksioneve të përgjithshme (shërbimi) që mund të përdoren për përpunimin e të dhënave në shtresa të ndryshme të ruajtjes - menaxhimin e ngarkesës, menaxhimin e cilësisë së të dhënave, mjetet e diagnostikimit dhe monitorimit të problemeve, etj.
Prania e këtij niveli siguron transparencë dhe rrjedhje të strukturuara të të dhënave në ruajtje.

Kjo shtresë përfshin dy zona të ruajtjes së të dhënave:

• zona metadata - përdoret për mekanizmin e kontrollit të ngarkimit të të dhënave;
• Zona e cilësisë së të dhënave - për zbatimin e kontrolleve të cilësisë së të dhënave jashtë linjës (d.m.th. ato që nuk janë të integruara drejtpërdrejt në proceset ETL).

Ju mund ta organizoni procesin e menaxhimit të shkarkimit në mënyra të ndryshme. Një qasje e mundshme është kjo: ne ndajmë të gjithë grupin e tabelave të ruajtjes në module. Moduli mund të përfshijë tabela vetëm me një shtresë. Tabelat e përfshira në secilin modul ngarkohen në një proces të veçantë. Le ta quajmë atë procesi i kontrollit ... Fillimi i procesit të kontrollit është vendosur sipas planit të tij. Procesi i kontrollit orkestron thirrjet drejt proceseve atomike, secila prej të cilave ngarkon një tabelë të synuar dhe gjithashtu përmban disa hapa të përgjithshëm.
Natyrisht, mjafton thjesht të ndani tabelat e skenave në module - sipas sistemeve burimore, ose më saktë sipas pikave të tyre të lidhjes. Por për kernelin, kjo tashmë është më e vështirë për t'u bërë. atje duhet të sigurojmë integritetin e të dhënave, që do të thotë se duhet të marrim parasysh varësitë. ato. do të ketë përplasje që duhet të zgjidhen. Dhe ka mënyra të ndryshme për t'i zgjidhur ato.

Një pikë e rëndësishme në menaxhimin e ngarkesës është zhvillimi i një qasjeje të qëndrueshme për trajtimin e gabimeve. Gabimet klasifikohen sipas shkallës së ashpërsisë së tyre. Kur ndodh një gabim kritik, procesi duhet të ndalet, dhe sa më shpejt të jetë e mundur, sepse shfaqja e tij tregon një problem të rëndësishëm që mund të çojë në prishje të të dhënave në ruajtje. Kështu, menaxhimi i ngarkesës nuk ka të bëjë vetëm me fillimin e proceseve, por edhe me ndalimin e tyre, si dhe parandalimin e fillimit të parakohshëm (gabimisht).

Për funksionimin e shtresës së shërbimit, krijohet një strukturë e veçantë e meta të dhënave. Kjo zonë do të ruajë informacion në lidhje me proceset e ngarkimit, grupet e të dhënave të ngarkuara, pikat e kontrollit që përdoren për të mbajtur një rritje (cili proces ka lexuar deri në cilën pikë) dhe informacione të tjera shërbimi të nevojshme për funksionimin e sistemit.
Është e rëndësishme të theksohet se të gjitha tabelat e synuara në të gjitha shtresat janë shënuar me një grup të veçantë meta-fushash, njëra prej të cilave është identifikuesi i procesit që përditësoi këtë rresht. Për tabelat brenda një depoje, ky shënim procesi lejon një mënyrë të qëndrueshme për të theksuar më pas deltën e ndryshimeve. Kur ngarkoni të dhënat në shtresën primare të të dhënave, situata është më e ndërlikuar - algoritmi i shpërndarjes delta për objekte të ndryshme të ngarkuara mund të jetë i ndryshëm. Por logjika e përpunimit të ndryshimeve të pranuara dhe e rrotullimit të tyre në tabelat e synuara për thelbin dhe vitrinat e dyqaneve është shumë më e ndërlikuar sesa për skenën, ku gjithçka është mjaft e parëndësishme - është e lehtë të parametrizosh dhe të mendosh mbi hapat (procedurat) standarde të ripërdorshme.

Unë nuk po vendos detyrën këtu për të mbuluar plotësisht këtë temë - organizimi i shkarkimit - thjesht theksoj thekset që ia vlen t'u kushtohet vëmendje.
Kjo qasje është vetëm një nga opsionet. Është mjaft e përgjegjshme. Dhe "prototipi konceptual" i tij ishte transportuesi i Toyota-s dhe sistemi vetëm në kohë. ato. këtu po largohemi nga paradigma e përhapur e ekskluzivisht "shkarkimi i të dhënave gjatë natës", dhe shkarkojmë në pjesë të vogla gjatë ditës - sapo të dhënat të jenë gati në burime të ndryshme: çfarë erdhi - u shkarkua. Në të njëjtën kohë, ne kemi shumë procese paralele që funksionojnë. Dhe "bishti i nxehtë" i të dhënave të freskëta do të "pulsojë" vazhdimisht - dhe madje do të shuhet me kalimin e kohës. Duhet të kemi parasysh një veçori të tillë. Dhe, nëse është e nevojshme, formoni vitrina të personalizuara me "feta", ku gjithçka është tashmë holistike. ato. është e pamundur të arrihet në të njëjtën kohë edhe efikasiteti, edhe konsistenca (integriteti). Ne kemi nevojë për një ekuilibër - diku një gjë është e rëndësishme, diku tjetër.

Është e domosdoshme të sigurohen lehtësira për prerje dhe monitorim. Është praktikë e mirë të përdorni ngjarje të shtypura, ku mund të vendosni parametra të ndryshëm dhe të personalizoni sistemin e njoftimeve - duke u abonuar në ngjarje të caktuara. Sepse është shumë e rëndësishme që kur kërkohet ndërhyrja e administratorit të sistemit, ai të dijë sa më shpejt që të jetë e mundur dhe të marrë të gjithë informacionin e nevojshëm diagnostikues. Regjistrat mund të përdoren gjithashtu për të analizuar problemet post-fakto, si dhe për të hetuar incidentet e mosfunksionimeve të sistemit, përfshirë. cilësinë e të dhënave.

Projektimi dhe mirëmbajtja e modeleve të të dhënave të magazinës

Pse është e rëndësishme t'i kushtohet vëmendje dizajnit të modeleve të të dhënave kur zhvillohet çdo sistem ku përfshihet një bazë të dhënash (dhe veçanërisht në një depo)? Pse të mos hidhni një grup tabelash kudo - qoftë edhe në një redaktues teksti? Pse na duhen "këto fotografi"?
Mjaft e çuditshme, edhe zhvilluesit me përvojë bëjnë pyetje të tilla.
Në fakt, po, asgjë nuk ju pengon të skiconi tabelat - dhe të filloni t'i përdorni ato. Nëse ... nëse në të njëjtën kohë në kokë (!) Zhvilluesi ka një pamje të përgjithshme koherente të strukturës që po skulpturon. Po sikur të ketë disa zhvillues? Po sikur dikush tjetër të përdor këto tabela? Dhe çfarë nëse kalon koha - një person largohet nga kjo zonë dhe pastaj kthehet përsëri në të?

A mund ta kuptoni pa një model? Në parim, ju mundeni. Dhe për ta kuptuar atë, dhe "përcaktoni fotografitë në një copë letër", dhe "fshini - rregulloni" të dhënat. Por është shumë më e lehtë, më e qartë dhe më e shpejtë të përdorësh një objekt të gatshëm - një model të dhënash. Dhe gjithashtu kuptoni "logjikën e pajisjes së saj" - dmth. do të ishte mirë të kishim rregulla të përgjithshme të lojës.

Dhe gjëja më e rëndësishme nuk është as kjo. Gjëja më e rëndësishme është që kur hartojmë një model, jemi të detyruar (vetëm pa opsione!) të studiojmë më nga afër dhe më thellë fushën e temës, veçoritë e pajisjes së të dhënave dhe përdorimin e tyre në raste të ndryshme biznesi. Dhe ato pyetje që do t'i kishim "shtyrë mënjanë" lehtësisht si komplekse, "të mjegulluara" duke hedhur shenjat tona, pa u përpjekur saktësisht dizajni model - do të detyrohemi të dorëzojmë dhe të vendosim tani, kur analizojmë dhe dizajnojmë, dhe jo më vonë - kur do të ndërtojmë raporte dhe do të mendojmë "si të reduktojmë të papajtueshmen" dhe "të rishpikim timonin" çdo herë.

Kjo qasje është një nga ato praktika inxhinierike që ju lejon të krijoni sisteme antifragjile. Meqenëse ato janë të rregulluara qartë, transparente, të përshtatshme për zhvillim, dhe gjithashtu "kufijtë e brishtësisë" së tyre janë menjëherë të dukshme - mund të vlerësoni më saktë "shkallën e fatkeqësisë" kur shfaqen kërkesa të reja dhe kohën e nevojshme për ridizajnim (nëse është e nevojshme).
Kështu, modeli i të dhënave është një nga artefaktet kryesore që duhet të ruhet gjatë zhvillimit të sistemit. Në mënyrë miqësore, duhet të jetë "në tryezën" e çdo analisti, zhvilluesi, etj. - të gjithë ata që marrin pjesë në projektet e zhvillimit të sistemit.

Projektimi i modeleve të të dhënave është një temë e madhe dhe e veçantë. Ekzistojnë dy qasje kryesore për hartimin e ruajtjes.
Qasja funksionon mirë për kernelin Entitet-marrëdhënie - kur një model i normalizuar (3NF) ndërtohet mbi bazën e studimit të fushës lëndore, më saktë, zonës së zgjedhur të saj. I njëjti "model i korporatës" që u diskutua më lart është në lojë këtu.

Kur dizajnoni vitrina, është i përshtatshëm model shumëdimensional ... Kjo qasje përshtatet mirë me të kuptuarit e përdoruesve të biznesit - sepse është një model i thjeshtë dhe i përshtatshëm për perceptimin njerëzor - njerëzit veprojnë me koncepte të kuptueshme dhe të njohura të metrikës (treguesve) dhe seksioneve me të cilat ato analizohen. Dhe kjo ju lejon të ndërtoni thjesht dhe qartë procesin e mbledhjes së kërkesave - ne vizatojmë një grup "matricash të seksioneve dhe treguesve", duke komunikuar me përfaqësues të departamenteve të ndryshme. Dhe pastaj e sjellim atë në një strukturë - "modelin e analizës": ne formojmë "autobusin e matjes" dhe përcaktojmë faktet që përcaktohen në to. Gjatë rrugës, ne po punojmë për hierarkitë dhe rregullat e grumbullimit.

Pastaj është shumë e lehtë të shkosh te modeli fizik, duke shtuar elementë optimizimi duke marrë parasysh veçoritë e DBMS. Për shembull, për Oracle do të ishte ndarje, një grup indeksesh, etj. Për Vertica do të përdoren teknika të tjera - renditje, segmentim, seksionim.
Gjithashtu, mund të kërkohet denormalizim i veçantë - kur ne vendosim qëllimisht tepricë në të dhëna, falë të cilave përmirësojmë performancën e pyetjes, por në të njëjtën kohë ndërlikojmë përditësimin e të dhënave (pasi teprica do të duhet të merret parasysh dhe të ruhet gjatë ngarkimit të të dhënave proces). Ndoshta, për të përmirësuar performancën, do të na duhet gjithashtu të krijojmë tabela agregate shtesë, ose të përdorim veçori të tilla shtesë DBMS si parashikimet në Vertica.

Pra, kur modelojmë të dhënat e magazinës, ne në fakt zgjidhim disa probleme:

• detyra e ndërtimit të një modeli konceptual (logjik) të bërthamës - analiza e sistemit dhe e biznesit - hulumtimi i fushës së temës, hyrja në detaje dhe marrë parasysh nuancat e "të dhënave të drejtpërdrejta" dhe përdorimi i tyre në biznes;
• detyra e ndërtimit të një modeli analize - dhe më pas një modeli konceptual (logjik) i vitrinës;
• detyra e ndërtimit të modeleve fizike - menaxhimi i tepricës së të dhënave, optimizimi duke marrë parasysh veçoritë e DBMS për pyetjet dhe ngarkimin e të dhënave.

Kur zhvillojmë modele konceptuale, ne mund të mos marrim parasysh veçoritë e një DBMS të veçantë, për të cilën po hartojmë një strukturë bazë të dhënash. Për më tepër, ne mund të përdorim një model konceptual për të krijuar disa modele fizike - për DBMS të ndryshme.

Le të përmbledhim.

• Një model i të dhënave nuk është një koleksion i "fotografive të bukura" dhe procesi i dizajnimit të tij nuk është një proces i vizatimit të tyre. Modeli pasqyron të kuptuarit tonë për domenin. Dhe procesi i përpilimit të tij është procesi i studimit dhe hulumtimit të tij. Kjo është kohë e humbur. Dhe aspak për të "vizatuar dhe pikturuar".
• Një model i të dhënave është një objekt projektimi, një mënyrë për të shkëmbyer informacion në një mënyrë të strukturuar midis anëtarëve të ekipit. Për ta bërë këtë, duhet të jetë e qartë për të gjithë (kjo sigurohet nga shënimi dhe shpjegimi) dhe e disponueshme (publikuar).
• Modeli i të dhënave nuk krijohet një herë dhe ngrihet, por krijohet dhe zhvillohet në procesin e zhvillimit të sistemit. Rregullat për zhvillimin e tij i vendosim vetë. Dhe ne mund t'i ndryshojmë ato nëse shohim - si ta bëjmë më mirë, më lehtë, në mënyrë më efikase.
• Modeli i të dhënave (fizik) ju lejon të konsolidoni dhe përdorni një sërë praktikash më të mira që synojnë optimizimin - d.m.th. përdorni teknikat që kanë funksionuar tashmë për këtë DBMS.

Karakteristikat e projekteve të magazinës së të dhënave

Le të ndalemi në specifikat e projekteve në kuadrin e të cilave kompania ndërton dhe zhvillon depo të dhënash. Dhe le t'i shikojmë ato nga pikëpamja e ndikimit të aspektit arkitektonik. Pse është e rëndësishme që projekte të tilla të ndërtojnë një arkitekturë dhe që në fillim? Dhe është prania e një arkitekture të mirëmenduar që i jep fleksibilitet projektit të magazinës së të dhënave, ju lejon të shpërndani në mënyrë efikase punën midis interpretuesve, dhe gjithashtu ta bëni më të lehtë parashikimin e rezultatit dhe ta bëni procesin më të parashikueshëm.

Magazina e të dhënave është softuer me porosi

Një magazinë e të dhënave është gjithmonë një "zhvillim me porosi", jo një zgjidhje në kuti. Po, ka aplikacione BI specifike për industrinë që përfshijnë një model të dhënash referencë, procese ETL të para-konfiguruara nga burime të zakonshme (për shembull, sistemet ERP), një grup panelesh standarde të BI dhe raporte. Por në praktikë, ruajtja zbatohet rrallë - si një "kuti". Unë kam rreth 10 vjet që punoj me depo dhe nuk kam parë kurrë një histori të tillë. Gjithmonë ka disa nuanca që lidhen me veçoritë unike të kompanisë - si biznesi ashtu edhe peizazhi i IT. Prandaj, shpresa se arkitektura do të sigurohet nga "shitësi" që furnizon zgjidhjen është disi e pamatur. Arkitektura e sistemeve të tilla shpesh "pjekur" brenda vetë organizatës. Ose është formuar nga specialistët e kompanisë kontraktore, e cila është zbatuesi kryesor i projektit.

Magazina e të dhënave është një projekt integrues

Depoja e të dhënave ngarkon dhe përpunon informacionin nga shumë sisteme burimore. Dhe për të mbajtur “marrëdhënie miqësore” me ta, duhet të jeni jashtëzakonisht të kujdesshëm me ta. Në veçanti, është e nevojshme të minimizohet ngarkesa në sistemet burimore, të merren parasysh dritaret "disponueshmëria dhe mosdisponueshmëria", të zgjidhni ndërfaqet e ndërveprimit duke marrë parasysh arkitekturën e tyre, etj. Pastaj ruajtja do të jetë në gjendje të marrë të dhënat sa më shpejt që të jetë e mundur dhe me frekuencën e kërkuar. Përndryshe, do të "transplantohesh" në një qark rezervë, i cili nuk përditësohet në frekuencën më operative.
Përveç kësaj, është e nevojshme të merret parasysh "faktori njerëzor". Integrimi nuk ka të bëjë vetëm me ndërveprimin e makinave. Është gjithashtu komunikim mes njerëzve.

Data Warehouse është një projekt bashkëpunues

Në një kompani të madhe, një sistem i tillë rrallë mund të bëhet vetëm nga një ekip. Si rregull, disa ekipe punojnë këtu, secila prej të cilave zgjidh një problem specifik.

Arkitektura duhet të sigurojë aftësinë për të organizuar punën e tyre paralele, duke ruajtur integritetin e saj dhe duke shmangur dyfishimin e të njëjtit funksionalitet në vende të ndryshme, nga njerëz të ndryshëm. Përveç përpjekjeve të panevojshme, një dyfishim i tillë mund të çojë në mospërputhje të të dhënave më vonë.

Për më tepër, kur kaq shumë njerëz dhe ekipe, shpesh të shpërndara, janë të përfshirë në zhvillimin e sistemit, në mënyrë të pashmangshme lind pyetja: si të ndërtohen komunikimet dhe ndërveprimi i informacionit midis tyre. Sa më shumë të përdoren qasje dhe praktika standarde dhe të kuptueshme, aq më e lehtë, më e përshtatshme dhe efikase është organizimi i një pune të tillë. Dhe, ndër të tjera, ia vlen të mendohet për përbërjen e "artifakteve të punës", ndër të cilat për depot e të dhënave # 1 janë modelet e të dhënave (shiko seksionin e mëparshëm).

Magazina e të dhënave ka një jetëgjatësi më të gjatë se sistemet e tjera

Për të sqaruar - deklarata është e vërtetë për një ruajtje "live", funksionale, të integruar me burimet kryesore, zotërimin e të dhënave historike dhe ofrimin e informacionit dhe shërbimeve analitike për shumë divizione të kompanisë.

Çfarë arsye kam unë për të besuar kështu?
Së pari, ndërtimi i një ruajtjeje është një proces shumë intensiv i burimeve: përveç kostove aktuale të pajisjeve, licencave për softuerin dhe zhvillimin e nevojshëm teknologjik, pothuajse të gjitha sistemet dhe divizionet e kompanisë janë gjithashtu të përfshira në këtë. Përsëritja e gjithë këtij procesi nga e para edhe një herë është një ide shumë e guximshme.

Së dyti, nëse ruajtja ka arkitekturën e duhur, atëherë mund t'i mbijetojë lehtësisht ndryshimeve të sistemeve burimore, shfaqjes së kërkesave të reja nga përdoruesit përfundimtarë dhe rritjes së vëllimeve të të dhënave.
Nëse arkitektura është e saktë, rrjedhat e informacionit janë transparente, atëherë një sistem i tillë mund të zhvillohet për një kohë të gjatë pa rrezikun e ngecjes në një situatë kur bëhen ndryshime për shkak të vështirësive në vlerësimin e ndikimit.

Zhvillimi gradual përsëritës

Gjëja e fundit që klienti do të dëshironte, duke u përfshirë në histori me depo, është të ngrijë kërkesat e tij për një ose dy vjet, derisa të hartohet një model i plotë i të dhënave të korporatës, të gjitha burimet të lidhen plotësisht, etj.

Në sytë e klientëve, depoja e të dhënave shpesh duket si një përbindësh absolut - detyrat, qëllimet dhe horizonti i zhvillimit të sistemit janë kaq voluminoz. Dhe shpesh klienti ka frikë se "në kurriz të buxhetit të tij" departamenti i IT do të zgjidhë disa "probleme të tyre". Dhe përsëri ne përballemi me çështjen e ndërveprimit midis njerëzve dhe aftësisë për të shprehur me qetësi pozicionin tonë dhe për të negociuar.

Qasjet kompetente arkitekturore ju lejojnë të zhvilloni sistemin në mënyrë të përsëritur, duke rritur funksionalitetin gradualisht, pa kaluar në "zhvillim" për disa vite përpara se të filloni të jepni një rezultat.

Edhe pse duhet theksuar se "mrekullitë nuk ndodhin" - dhe "fillimi" kërkon gjithashtu kohë. Për ruajtje, mund të jetë mjaft i madh - pasi këto janë sasi të mëdha të dhënash, këto janë të dhëna historike - për periudhat e vjetra, kur rregullat për përpunimin e informacionit mund të ndryshojnë nga ato aktuale. Prandaj, kërkon kohë të mjaftueshme për punë analitike, ndërveprim me sistemet burimore dhe një numër "provash dhe gabimesh", duke përfshirë testet e ngarkesës në të dhëna reale.

Depot e të dhënave - "histori me shumë projekte"

Është e vështirë të veçosh një klient të vetëm biznesi për një depo të dhënash. Dhe besohet (jo pa arsye) se faktori kryesor në suksesin e projektit të ndërtimit të një depoje është mbështetja e menaxhmentit të kompanisë - drejtpërdrejt personi i parë.
Një depo ndërtohet dhe zhvillohet rrallë si pjesë e një projekti të vetëm. Në mënyrë tipike, ka nevoja të ndryshme për konsolidimin e të dhënave dhe analitikën, pas tyre janë klientë dhe grupe të ndryshme përdoruesish. Prandaj, depoja shpesh zhvillohet brenda kuadrit të disa projekteve paralele.

Bilanci i inovacionit dhe zgjidhjeve të provuara

Përkundër faktit se tema e ruajtjes është shumë "e lashtë" (nëse një fjalë e tillë është e zbatueshme për një industri kaq të re si IT) dhe mjaft konservatore. Sidoqoftë, përparimi nuk qëndron ende - dhe ato kufizime që ekzistonin më parë për shkak të disqeve të shtrenjta dhe të ngadalta, kujtesës së shtrenjtë, etj. - tani janë hequr. Në të njëjtën kohë, ka ardhur koha për të rishikuar disa nga qasjet arkitekturore. Për më tepër, kjo vlen si për platformat teknologjike ashtu edhe për arkitekturën e sistemeve të aplikuara që bazohen në to.

Është e rëndësishme të arrihet një ekuilibër këtu - dhe të ruhet një qasje mjaft e "gjelbër" si për burimet ashtu edhe për informacionin e ruajtur. Përndryshe, ju mund ta ktheni shumë shpejt depozitën në një "grumbullim" gjysmë të strukturuar, në të cilin, nëse do të jetë e mundur ta kuptoni, atëherë me shumë përpjekje.
Po, ne kemi më shumë mundësi, por kjo nuk do të thotë se duhet të mohojmë të gjitha praktikat e grumbulluara dhe të testuara me kohë, të cilat është e qartë se si dhe pse t'i përdorim, dhe "të shkojmë keq" vetëm të udhëhequr nga fantazma e mjegullt e ". risitë".
Mbajtja e një ekuilibri nënkupton përdorimin e metodave dhe qasjeve të reja ku ato hapin mundësi të reja, por në të njëjtën kohë duke përdorur ato të vjetra të provuara - për të zgjidhur problemet urgjente që nuk janë anuluar.
Çfarë mund të bëjmë ne si zhvillues dhe projektues të zgjidhjeve të aplikacioneve? Para së gjithash, të njohim dhe kuptojmë ndryshimet teknologjike të platformave në të cilat punojmë, aftësitë e tyre, veçoritë dhe kufijtë e aplikacioneve.

Le ta shohim DBMS-në si platformën teknologjike më kritike dhe më të rëndësishme për ruajtje.
Kohët e fundit, ka pasur një zhvendosje të qartë të bazave të të dhënave relacionale, të krijuara fillimisht si "universale", drejt specializimit. Për një kohë të gjatë, shitësit kryesorë kanë lëshuar opsione të ndryshme - për aplikacione të klasave të ndryshme (OLTP, DSS & DWH). Përveç kësaj, shfaqen mundësi shtesë për të punuar me tekst, gjeo-të dhëna etj.

Por ky nuk ishte fundi i tij - filluan të shfaqen produkte që fillimisht ishin të përqendruara në një klasë të caktuar detyrash, d.m.th. DBMS e specializuar. Ata mund të përdorin ose jo modelin relacional. Është e rëndësishme që ato fillimisht të "mprehen" jo vetëm për ruajtjen dhe përpunimin e "informacionit të biznesit" në përgjithësi, por për detyra specifike.

Me sa duket, centralizimi dhe specializimi janë dy prirje plotësuese që zëvendësojnë periodikisht njëra-tjetrën, duke siguruar zhvillim dhe ekuilibër. Si dhe zhvillim gradual evolucionar (gradual) dhe ndryshime kardinal. Për shembull, në vitet '90, Michael Stonebreaker ishte një nga autorët e Manifestit të Bazave të të Dhënave të Gjeneratës III, i cili shprehu qartë idenë se bota nuk ka nevojë për një revolucion tjetër në botën e bazave të të dhënave. Megjithatë, 10 vjet më vonë, ai boton vepra në të cilat shpall parakushtet për fillimin e një epoke të re në botën e DBMS - bazuar në specializimin e tyre.
Ai fokusohet në faktin se DBMS-të e zakonshme universale janë ndërtuar mbi një arkitekturë "një madhësie që i përshtatet të gjithëve", e cila nuk merr parasysh as ndryshimet në platformat harduerike dhe as ndarjen e aplikacioneve në klasa për të cilat mund të dilni me një zgjidhje optimale sesa zbatimi i kërkesave universale.
Dhe ai fillon të zhvillojë një numër projektesh në përputhje me këtë ide. Njëri prej tyre - C-Store - është një DBMS kolone e krijuar në arkitekturën e asgjës së përbashkët (SN), e krijuar fillimisht posaçërisht për sistemet e klasës së depove të të dhënave. Ky produkt më pas u tregtua si HP Vertica.

Duket se tani tema e zhvillimit të depove të të dhënave ka rrëshqitur në një fazë të re zhvillimi. Shfaqen teknologji, qasje dhe mjete të reja. Studimi, testimi dhe aplikimi i tyre inteligjent na lejon të krijojmë zgjidhje vërtet interesante dhe të dobishme. Dhe sillni ato në zbatim, duke shijuar faktin që zhvillimet tuaja përdoren në punë reale dhe janë të dobishme.

Epilogu

Në përgatitjen e këtij artikulli, u përpoqa të fokusohesha kryesisht tek arkitektët, analistët dhe zhvilluesit që punojnë drejtpërdrejt me depot e të dhënave. Por doli që ajo në mënyrë të pashmangshme "e mori temën pak më të gjerë" - dhe kategoritë e tjera të lexuesve ranë në fushën e vizionit. Disa pika do të duken të diskutueshme, disa nuk janë të qarta, disa janë të dukshme. Njerëzit janë të ndryshëm - me prejardhje, prejardhje dhe pozita të ndryshme.
Për shembull, pyetjet tipike menaxheriale janë "kur të punësohen arkitektë?", "Kur të bëjmë arkitekturë?" tingëllon për ne (zhvilluesit, projektuesit) mjaft i çuditshëm, sepse për ne arkitektura e sistemit shfaqet me lindjen e tij - nuk ka rëndësi nëse jemi të vetëdijshëm apo jo. Dhe edhe nëse nuk ka asnjë rol formal të një arkitekti në një projekt, një zhvillues normal gjithmonë "përfshin arkitektin e tij të brendshëm".

Në përgjithësi, nuk ka rëndësi se kush e kryen saktësisht rolin e arkitektit - është e rëndësishme që dikush të bëjë pyetje të ngjashme dhe të hetojë përgjigjet. Nëse arkitekti veçohet qartë, kjo do të thotë vetëm se ai është përgjegjës kryesor për sistemin dhe zhvillimin e tij.
Pse e gjeta temën e "antifragjilitetit" të rëndësishme për këtë temë?

"E veçanta e antifragjilitetit është se na lejon të punojmë me të panjohurën, të bëjmë diçka në kushte kur nuk kuptojmë se çfarë saktësisht po bëjmë dhe të arrijmë sukses."/ Nassim N. Talb /

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

Zaitsev S.L., Ph.D.

Grupe që përsëriten

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

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

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

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

Një fakt në një vend

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

Teprica kërkon hapësirë ​​shtesë, por ndërsa efikasiteti i kujtesës është i rëndësishëm, problemi i vërtetë qëndron diku tjetër. Sigurimi që të dhënat e tepërta janë të sinkronizuara është i ngarkuar dhe ju gjithmonë rrezikoni të konfliktoni vlerat.

Në shembullin e mëparshëm AFTËSI varet nga ID e personit dhe nga ID e aftësisë. Kjo do të thotë që ju nuk do të keni AFTËSI derisa të shfaqet NJË PERSON, zotërimi i kësaj aftësie. Kjo gjithashtu e bën të vështirë ndryshimin e emrit të aftësisë. Është e nevojshme të gjesh çdo hyrje me emrin e aftësisë dhe ta ndryshosh atë për secilin person që zotëron këtë aftësi.

Figura 1.8 tregon modelin në formën e dytë normale. Vini re se entiteti i shtuar AFTËSI, dhe atributin TITULLI aftësia i transferohet këtij entiteti. Niveli i aftësive mbeti, përkatësisht, në kryqëzim PERSONAT dhe AFTËSI.

Oriz. 1.8. Në formën e dytë normale, grupi përsëritës zhvendoset në një entitet tjetër. Kjo siguron fleksibilitetin për të shtuar numrin e kërkuar të Aftësive dhe për të ndryshuar Emrin e Aftësisë ose Përshkrimin e Aftësisë në një vend.

Çdo atribut varet nga çelësi

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

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

Shumë-për-shumë marrëdhënie

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

Oriz. 1.10. Në formën e katërt normale, një marrëdhënie monogo-me-shumë ndërmjet PERSONALE dhe SHKOLLA zgjidhet duke futur një entitet shoqërues, në të cilin ndahet një hyrje e veçantë për çdo kombinim unik SHKOLLAT dhe PERSONA.

Përkufizime formale të formave normale

Përkufizimet e mëposhtme të formave normale mund të duken të frikshme. Mendojini ato thjesht si formula për arritjen e normalizimit. Format normale bazohen në algjebër relacionale dhe mund të interpretohen si transformime matematikore. Edhe pse ky libër nuk i kushtohet një diskutimi të detajuar të formave normale, modelistët inkurajohen të hedhin një vështrim më të thellë në temë.

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

Lidhja R korrespondon me formën e parë normale (1NF) nëse dhe vetëm nëse të gjitha domenet që i përkasin asaj përmbajnë vetëm vlera atomike (Data, po aty).

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

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

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

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

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

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

JD (varësia e bashkimit) është një varësi e bashkimit. Me një varësi nga bashkimi, çelësi primar i njësisë ekonomike mëmë gjurmohet në të paktën pasardhësit e nivelit të tretë, duke ruajtur aftësinë për t'u përdorur në bashkim nga çelësi origjinal.

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

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

Ka shumë forma të tjera normale për lloje komplekse të dhënash dhe situata specifike që janë përtej qëllimit të këtij diskutimi. Çdo entuziast i zhvillimit të modelit do të donte të mësonte edhe forma të tjera normale.

Forma normale të biznesit

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

Forma e parë normale e biznesit (1BNF) nxjerr grupe përsëritëse te një njësi tjetër. Ky ent merr emrin e vet dhe atributet kryesore (të përbëra) kryesore nga entiteti origjinal dhe grupi i tij përsëritës.

Forma e dytë normale e biznesit (2BNF) nxjerr atributet që varen pjesërisht nga çelësi primar për një njësi tjetër ekonomike. Çelësi primar (i përbërë) i këtij entiteti është çelësi kryesor i entitetit në të cilin ishte vendosur fillimisht, së bashku me çelësat shtesë nga të cilët varet tërësisht atributi.

Forma e tretë normale e biznesit (3BNF) merr atribute që janë të pavarura nga një çelës primar në një njësi tjetër, ku ato varen plotësisht nga çelësi primar i atij entiteti.

Forma e katërt normale e biznesit (4BNF) merr atribute që varen nga vlera e çelësit primar ose janë opsionale për një njësi ekonomike dytësore, ku varen tërësisht nga vlera e çelësit primar, ose ku duhet (domosdoshmërisht) të jenë të pranishëm në atë entitet.

Forma e pestë normale e biznesit (5BNF) shfaqet si një njësi strukturore nëse ekziston një varësi rekursive ose një varësi tjetër midis shembujve të një njësie ekonomike dytësore, ose nëse ekziston një varësi rekursive midis shembujve të njësisë së saj parësore.

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

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

Të gjitha subjektet duhet të kenë emra që përshkruajnë përmbajtjen e tyre dhe të kenë një përshkrim ose përcaktim të qartë, konciz, të plotë. Një postim i ardhshëm do të mbulojë një grup fillestar udhëzimesh për formimin e saktë të emrave dhe përshkrimeve të njësive.

Subjektet duhet të kenë një grup të plotë atributesh, në mënyrë që çdo fakt për çdo entitet të mund të përfaqësohet nga atributet e tij. Çdo atribut duhet të ketë një emër që pasqyron kuptimin e tij, një lloj të dhënash Boolean dhe një përshkrim ose përkufizim të qartë, të shkurtër, të plotë. Në një postim të ardhshëm në blog, ne do të shikojmë një grup fillestar udhëzimesh për formatimin e duhur të emrave dhe përshkrimeve të atributeve.

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

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

Modeli i të dhënave fizike

Pasi të keni krijuar një model logjik të plotë dhe adekuat, jeni gati të merrni vendimin për të zgjedhur një platformë zbatimi. Zgjedhja e platformës varet nga kërkesat për përdorimin e të dhënave dhe parimet strategjike të formësimit të arkitekturës së korporatës. Zgjedhja e platformës është një çështje komplekse përtej qëllimit të këtij libri.

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

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

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

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

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

Kërkesat për akses dhe performancë

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

Vlerësimi i numrit të përdoruesve që kanë nevojë për qasje të njëkohshme në të dhëna për t'ju ndihmuar të dizajnoni bazën tuaj të të dhënave për nivele të pranueshme të performancës

Agregatet, strumbullarët dhe të dhënat e tjera të llogaritura ose të nxjerra që mund të konsiderohen kandidatë për ruajtje në strukturat e vazhdueshme të të dhënave

Kërkesat për raportim dhe pyetje standarde për të ndihmuar administratorin e bazës së të dhënave të ndërtojë indekse

Pamje (të vazhdueshme ose virtuale) që do të ndihmojnë përdoruesin gjatë kryerjes së operacioneve të grumbullimit ose filtrimit të të dhënave.

Përveç kryetarit, sekretarit dhe përdoruesve, modeluesi, administratori i bazës së të dhënave dhe arkitekti i bazës së të dhënave duhet të marrin pjesë në sesionin e kërkesave të përdorimit. Duhet të diskutohen kërkesat e të dhënave historike të përdoruesit. Kohëzgjatja e ruajtjes së të dhënave ka një ndikim të rëndësishëm në madhësinë e bazës së të dhënave. Shpesh, të dhënat e vjetra ruhen në një formë të përgjithësuar dhe të dhënat atomike arkivohen ose fshihen.

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

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

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

Inxhinieri e kundërt

Kur një model logjik nuk është i disponueshëm, bëhet e nevojshme të rikrijohet modeli nga baza e të dhënave ekzistuese. Në ERwin, ky proces quhet inxhinieri e kundërt. Inxhinieria e kundërt mund të bëhet në disa mënyra. Modeluesi mund të eksplorojë strukturat e të dhënave në bazën e të dhënave dhe të rikrijojë tabela në një mjedis modelimi vizual. Ju mund të importoni gjuhën e përkufizimeve të të dhënave (DDL) në një mjet që mbështet inxhinierinë e kundërt (siç është Erwin). Mjetet e avancuara si ERwin përfshijnë funksione që ofrojnë komunikim ODBC me një bazë të dhënash ekzistuese për të krijuar një model duke lexuar drejtpërdrejt strukturat e të dhënave. Inxhinieria e kundërt me ERwin do të diskutohet në detaje në një postim të ardhshëm.

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

Kur ndërtoni një model logjik për një modelues, është e rëndësishme të siguroheni që modeli i ri të jetë në përputhje me modelin e korporatës. Përdorimi i kufijve funksionalë të korporatës nënkupton modelimin e të dhënave në termat e përdorur brenda një korporate. Mënyra se si përdoren të dhënat në një korporatë po ndryshon më shpejt se vetë të dhënat. Në çdo model logjik, të dhënat duhet të paraqiten në një mënyrë holistike, pavarësisht nga fusha e biznesit që ai mbështet. Subjektet, atributet dhe marrëdhëniet duhet të përcaktojnë rregullat e biznesit në nivel korporate.

SHËNIM Disa nga kolegët e mi i referohen këtyre kufijve funksionalë të korporatës si modelim në botën reale. Modelimi i botës reale inkurajon modeluesin të shikojë informacionin në termat e marrëdhënieve dhe marrëdhënieve të tij të qenësishme në të vërtetë.

Përdorimi i kufijve funksionalë të korporatës për një model të dhënash që është ndërtuar në mënyrë të përshtatshme ofron bazën për mbështetjen e nevojave për informacion të çdo numri procesesh dhe aplikacionesh, gjë që i mundëson korporatës të shfrytëzojë në mënyrë më efikase një nga asetet e saj më të vlefshme - informacionin.

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

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

Çdo model logjik duhet të korrespondojë me domenin ekzistues të modelit të të dhënave të korporatës. Nëse modeli logjik nuk e plotëson këtë kërkesë, atij duhet t'i shtohet një model domeni. Ky krahasim siguron që modeli i korporatës është përmirësuar ose rregulluar dhe se të gjitha përpjekjet e modelimit logjik janë të koordinuara brenda korporatës.

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

Ndërtimi i një modeli të të dhënave të korporatës duke shtuar

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

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

Koncepti i metodologjisë së modelimit

Ekzistojnë disa metodologji të modelimit të të dhënave vizuale. ERwin mbështet dy:

IDEF1X (Përkufizimi i Integrimit për Modelimin e Informacionit - një përshkrim i integruar i modeleve të informacionit).

IE (Inxhinieri e Informacionit).

IDEF1X është një metodologji e mirë dhe përdorimi i shënimit të tij është i përhapur

Përshkrimi i integruar i modeleve të informacionit

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

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

Inxhinieri informacioni

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

IE ofron infrastrukturën për të mbështetur kërkesat e informacionit duke integruar planifikimin strategjik të korporatës me sistemet e informacionit që janë duke u zhvilluar. Ky integrim lejon menaxhimin e burimeve të informacionit të përafrohet më ngushtë me perspektivat strategjike afatgjata të korporatës. Kjo qasje e drejtuar nga biznesi ka bërë që shumë modelues të zgjedhin IE mbi metodologjitë e tjera që priren të fokusohen në sfidat e zhvillimit afatshkurtër.

IE propozon një sekuencë veprimesh që e çojnë një korporatë të identifikojë të gjitha nevojat e saj për informacion për mbledhjen dhe menaxhimin e të dhënave dhe identifikimin e marrëdhënieve ndërmjet objekteve të informacionit. Si rezultat, kërkesat për informacion artikulohen qartë bazuar në direktivat e menaxhimit dhe mund të përkthehen drejtpërdrejt në një sistem informacioni menaxherial që do të mbështesë nevojat strategjike të informacionit.

konkluzioni

Të kuptuarit se si të përdorni një mjet modelimi të të dhënave si ERwin është vetëm një pjesë e problemit. Përveç kësaj, ju duhet të kuptoni se kur zgjidhen detyrat e modelimit të të dhënave dhe si mblidhen kërkesat e informacionit dhe rregullat e biznesit që duhet të përfaqësohen në modelin e të dhënave. Kryerja e seancave të punës ofron mjedisin më të favorshëm për mbledhjen e kërkesave të informacionit në një mjedis që përfshin ekspertë të fushës, përdorues dhe profesionistë të teknologjisë së informacionit.

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

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

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

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

Subjektet duhet të kenë një grup të plotë atributesh, në mënyrë që çdo fakt për çdo entitet të mund të përfaqësohet nga atributet e tij. Çdo atribut duhet të ketë një emër që pasqyron kuptimin e tij, një lloj të dhënash Boolean dhe një përshkrim ose përkufizim të qartë, të shkurtër, të plotë. Në një postim të ardhshëm në blog, ne do të shikojmë një grup fillestar udhëzimesh për formatimin e duhur të emrave dhe përshkrimeve të atributeve. Marrëdhëniet duhet të përfshijnë një ndërtim foljesh që përshkruan marrëdhënien midis entiteteve, së bashku me karakteristika të tilla si shumësia, domosdoshmëria e ekzistencës ose mundësia e mungesës së një marrëdhënieje.

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

Dërgoni punën tuaj të mirë në bazën e njohurive është e thjeshtë. Përdorni formularin e mëposhtëm

Studentët, studentët e diplomuar, shkencëtarët e rinj që përdorin bazën e njohurive në studimet dhe punën e tyre do t'ju jenë shumë mirënjohës.

Postuar ne http://www.allbest.ru/

• 1. Modeli i të dhënave relacionale
• 1.1 Modeli i të dhënave relacionale. Përkufizimet bazë
• 1.2 Operacionet mbi marrëdhëniet
• 2. Sistemet e informacionit të korporatës
• Bibliografi

1. Modeli i të dhënave relacionale

1.1 Modeli i të dhënave relacionale. Përkufizimet bazë

Në disiplinat matematikore, koncepti "tabelë" korrespondon me konceptin "relacion" (relacion). Tabela pasqyron një objekt të botës reale - një entitet, dhe secila prej rreshtave të saj pasqyron një shembull specifik të entitetit. Çdo kolonë ka një emër unik për tabelën. Vargjet nuk kanë emra, rendi i tyre nuk është i përcaktuar dhe numri është logjikisht i pakufizuar. Një nga avantazhet kryesore të modelit të të dhënave relacionale është homogjeniteti (çdo rresht në një tabelë ka të njëjtin format). I takon përdoruesit të vendosë nëse entitetet përkatëse janë homogjene. Kjo zgjidh problemin e përshtatshmërisë së modelit.

Konceptet bazë:

* Një marrëdhënie është një tabelë dy-dimensionale që përmban disa të dhëna.

* Entitet - një objekt i çdo natyre, të dhënat për të cilat ruhen në bazën e të dhënave. Atributet janë veti që karakterizojnë një entitet (kolona).

* Shkalla e marrëdhënies është numri i kolonave.

* Skema e marrëdhënieve - një listë e emrave të atributeve, për shembull, PUNONJËS (Nr., emri i plotë, viti i lindjes, pozicioni, departamenti).

* Domain - një grup vlerash të atributeve të një relacioni (lloji i të dhënave).

* Një tufë është një rresht tavoline.

* Kardinaliteti (kardinaliteti) - numri i rreshtave në tabelë.

* Çelësi primar është një atribut që identifikon në mënyrë unike rreshtat e një marrëdhënieje. Një çelës primar me shumë atribute quhet çelës primar i përbërë. Çelësi primar nuk mund të jetë plotësisht ose pjesërisht bosh (null). Çelësat që mund të përdoren si çelësa primar quhen çelësa potencial ose alternativë.

* Një çelës i huaj është një atribut (a) i një tabele që mund të shërbejë si çelësi kryesor i një tabele tjetër. Referon çelësin kryesor të një tabele tjetër.

Normalizimi është një proces që synon reduktimin e tepricës së informacionit në një bazë të dhënash. Përveç vetë të dhënave, në bazën e të dhënave mund të normalizohen edhe emra të ndryshëm, emra objektesh dhe shprehjesh.

Një bazë të dhënash jo e normalizuar përmban informacion në një ose më shumë tabela të ndryshme; kjo të jep përshtypjen se përfshirja e të dhënave në një tabelë të caktuar nuk është për ndonjë arsye të dukshme. Kjo gjendje mund të ketë një ndikim negativ në sigurinë e të dhënave, përdorimin efikas të hapësirës në disk, shpejtësinë e pyetjeve, efikasitetin e përditësimit të bazës së të dhënave dhe, ndoshta më e rëndësishmja, integritetin e informacionit të ruajtur. Baza e të dhënave përpara normalizimit është një strukturë që ende nuk është zbërthyer logjikisht në tabela më të menaxhueshme dhe më të vogla.

Forma normale është një lloj treguesi i nivelit ose thellësisë së normalizimit të bazës së të dhënave. Niveli i normalizimit të bazës së të dhënave korrespondon me formën normale në të cilën ndodhet.

1.2 Operacionet mbi marrëdhëniet

Për ta sjellë tabelën në formën e parë normale (1NF), duhet të respektohen dy rregulla:

1. Atomiciteti ose pandashmëria. Çdo kolonë duhet të përmbajë një vlerë të pandashme.

2. Tabela nuk duhet të përmbajë kolona të dyfishta ose grupe të dhënash.

Për shembull, nëse një tabelë përmban në një fushë adresën e plotë të një personi (rruga, qyteti, kodi postar), ajo nuk do të përmbushë rregullat 1NF, pasi do të përmbajë vlera të ndryshme në një kolonë, gjë që do të ishte shkelje. të rregullit të atomicitetit. Ose nëse baza e të dhënave përmban të dhëna për filmat dhe përmban kolonat Actor1, Actor2, Actor3, ajo gjithashtu nuk do të përputhet me rregullat, pasi të dhënat do të përsëriten.

Normalizimi duhet të fillojë me kontrollimin e strukturës së bazës së të dhënave për pajtueshmërinë me 1NF. Të gjitha kolonat që nuk janë atomike duhet të ndahen në kolonat e tyre përbërëse. Nëse ka kolona të dyfishta në tabelë, atëherë ato duhet të zgjedhin një tabelë të veçantë.

Për ta sjellë tabelën në formën e parë normale, duhet:

* Gjeni të gjitha fushat që përmbajnë informacione shumëpjesëshe.

* Të dhënat që mund të ndahen në pjesë përbërëse duhet të vendosen në fusha të veçanta.

* Zhvendosni të dhënat e kopjuara në një tabelë të veçantë.

* Kontrolloni nëse të gjitha tabelat përputhen me kushtet e formës së parë normale.

Për të sjellë tabelat në formën e dytë normale (2NF), tabelat duhet të jenë tashmë në 1NF. Normalizimi duhet të vazhdojë në rregull.

Tani, në formën e dytë normale, kushti duhet të plotësohet - çdo kolonë që nuk është çelës (duke përfshirë të huaj) duhet të varet nga çelësi primar. Në mënyrë tipike, këto kolona, ​​të cilat kanë vlera që janë të pavarura nga çelësi, janë të lehta për t'u identifikuar. Nëse të dhënat e përfshira në kolonë nuk lidhen me çelësin që përshkruan rreshtin, atëherë ato duhet të ndahen në tabelën e tyre të veçantë. Çelësi primar duhet të kthehet në tabelën e vjetër.

Për ta sjellë bazën në formën e dytë normale, ju duhet:

* Identifikoni të gjitha kolonat që nuk varen drejtpërdrejt nga çelësi kryesor i kësaj tabele.

* Krijoni fushat e kërkuara në tabelat e përdoruesve dhe të forumeve, zgjidhni nga fushat ekzistuese ose krijoni çelësat kryesorë nga ato të reja.

* Çdo tabelë ka nevojë për çelësin e vet primar

* Krijoni çelësa të huaj dhe caktoni marrëdhëniet e tyre midis tabelave. Hapi i fundit i normalizimit në 2NF do të jetë shpërndarja e çelësave të huaj për komunikimin me tabelat përkatëse. Çelësi kryesor i një tabele duhet të jetë një çelës i huaj në një tjetër.

Këshilla:

Një mënyrë tjetër për të kthyer një skemë në 2NF është të shikoni marrëdhëniet midis tabelave. Idealisht, krijoni të gjitha marrëdhëniet një-me-shumë. Shumë-për-shumë marrëdhënie kanë nevojë për ristrukturim.

Një tabelë e normalizuar siç duhet nuk do të ketë kurrë rreshta të kopjuar (dy ose më shumë rreshta, vlerat e të cilave nuk janë çelësa dhe përmbajnë të njëjtat të dhëna).

Baza e të dhënave do të jetë në formën e tretë normale nëse konvertohet në formën e dytë normale dhe secila kolonë jo kyçe është e pavarur nga njëra-tjetra. Nëse e ndiqni saktë procesin e normalizimit deri në këtë pikë, mund të mos ketë pyetje në lidhje me konvertimin në 3NF. Duhet të jeni të vetëdijshëm se 3NF shkelet nëse ndryshimi i vlerës në një kolonë kërkon një ndryshim në kolonën tjetër.

Për ta sjellë bazën në formën e tretë normale, ju duhet:

* Përcaktoni se cilat fusha të cilat tabela kanë ndërvarësi, d.m.th. fusha që varen më shumë nga njëra-tjetra sesa nga rreshti në tërësi.

* Krijoni tabela që përputhen. Nëse ka një kolonë problematike në hapin 1, krijoni tabela të ndara për të.

* Krijoni ose shpërndani çelësat kryesorë. Çdo tabelë duhet të ketë një çelës primar.

* Krijoni çelësat e huaj të kërkuar që formojnë ndonjë nga marrëdhëniet.

Në formën e katërt normale, një rregull shtesë është se është e nevojshme të përjashtohen varësitë me shumë vlera. Me fjalë të tjera, të gjitha rreshtat në tabelë duhet të jenë të pavarura nga njëri-tjetri. Prania e disa rreshtave X nuk duhet të nënkuptojë se rreshti Y është gjithashtu diku në këtë tabelë.

2. Sistemet e informacionit të korporatës

sistemi i të dhënave të modelit relacional

Një sistem (nga greqishtja systema - një tërësi, një përbërje e përbërë nga pjesë) është një grup elementësh që ndërveprojnë me njëri-tjetrin, duke formuar një integritet, unitet të caktuar. Këtu janë disa koncepte që përdoren shpesh për të karakterizuar një sistem.

1. Një element sistemi është një pjesë e një sistemi që ka një qëllim funksional specifik. Elementet komplekse të sistemeve, nga ana tjetër, të përbërë nga elementë më të thjeshtë të ndërlidhur, shpesh quhen nënsisteme.

2. Organizimi i sistemit - rregullsia e brendshme, konsistenca e ndërveprimit të elementeve të sistemit, e manifestuar, veçanërisht, në kufizimin e shumëllojshmërisë së gjendjeve të elementeve brenda sistemit.

3. Struktura e sistemit - përbërja, rendi dhe parimet e ndërveprimit të elementeve të sistemit, të cilat përcaktojnë vetitë themelore të sistemit. Nëse elementet individuale të sistemit janë të ndarë në nivele të ndryshme dhe lidhjet e brendshme ndërmjet elementeve organizohen vetëm nga nivelet më të larta në ato më të ulëta dhe anasjelltas, atëherë flasim për strukturën hierarkike të sistemit. Strukturat thjesht hierarkike janë praktikisht të rralla, prandaj, duke e zgjeruar disi këtë koncept, struktura hierarkike zakonisht kuptohet si struktura të tilla, ku, përveç lidhjeve të tjera, marrëdhëniet hierarkike kanë një rëndësi të madhe.

4. Arkitektura e sistemit - një grup karakteristikash të sistemit që janë thelbësore për përdoruesin.

5. Integriteti i sistemit - pareduktueshmëria themelore e vetive të sistemit në shumën e vetive të elementeve të tij individuale (shfaqja e vetive) dhe, në të njëjtën kohë, varësia e vetive të secilit element nga vendi i tij dhe funksionojnë brenda sistemit.

Sistemi i informacionit është një grup i ndërlidhur i mjeteve, metodave dhe personelit të përdorur për të ruajtur, përpunuar dhe lëshuar informacion në mënyrë që të arrihet qëllimi i caktuar "

Ligji Federal "Për Informacionin, Informatizimin dhe Mbrojtjen e Informacionit" jep përkufizimin e mëposhtëm:

"Sistemi i informacionit është një grup dokumentesh (vargu dokumentesh) dhe teknologjish të informacionit të renditur në mënyrë organizative, duke përfshirë përdorimin e teknologjisë kompjuterike dhe komunikimeve që zbatojnë proceset e informacionit".

Klasifikimi i shkallës

Për sa i përket shkallës, sistemet e informacionit ndahen në grupet e mëposhtme:

* beqare;

* grup;

* korporative.

Një sistem informacioni i korporatës është një sistem i shkallëzuar i krijuar për automatizimin e integruar të të gjitha llojeve të aktiviteteve ekonomike të ndërmarrjeve të mëdha dhe të mesme, duke përfshirë korporatat që përbëhen nga një grup kompanish që kërkojnë menaxhim të unifikuar.

Një sistem informacioni i korporatës mund të konsiderohet një sistem që automatizon më shumë se 80% të divizioneve të një ndërmarrje.

Kohët e fundit, në shumë botime kushtuar përdorimit të teknologjisë së informacionit në menaxhimin e objekteve ekonomike, shpesh përdoret termi "sistemet e informacionit të korporatës", që në to nënkupton sistemet aktuale të automatizuara të informacionit të objekteve ekonomike.

Një sistem i automatizuar informacioni (AIS) është një kombinim i llojeve të ndryshme të mbështetjes, si dhe specialistëve të krijuar për të automatizuar përpunimin e kontabilitetit dhe informacionit analitik. Si rregull, llojet e mbështetjes janë homogjene për sisteme të ndryshme në përbërje, gjë që bën të mundur zbatimin e parimit të përputhshmërisë së sistemeve gjatë funksionimit të tyre. Në procesin e studimit të AIS si një sistem kompleks, është e nevojshme të veçohen pjesë dhe elementë individualë dhe të merren parasysh veçoritë e përdorimit të tyre në fazat e krijimit dhe funksionimit.

Sistemet e informacionit të korporatave janë një evolucion i sistemeve për grupet e punës, ato janë të përqendruara në kompani të mëdha dhe mund të mbështesin nyjet ose rrjetet gjeografikisht të shpërndara. Në thelb, ato kanë një strukturë hierarkike të disa niveleve. Sisteme të tilla karakterizohen nga një arkitekturë klient-server me specializim të serverëve ose një arkitekturë me shumë nivele. Gjatë zhvillimit të sistemeve të tilla, të njëjtët serverë të bazës së të dhënave mund të përdoren si kur zhvillohen sisteme informacioni në grup. Megjithatë, në sistemet e mëdha të informacionit, serverët më të zakonshëm janë Oracle, DB2 dhe Microsoft SQL Server.

Për sistemet e grupeve dhe të korporatave, kërkesat për besueshmërinë e funksionimit dhe sigurinë e të dhënave janë rritur ndjeshëm. Këto veti mbahen duke ruajtur të dhënat, referencën dhe integritetin e transaksioneve në serverët e bazës së të dhënave.

Klasifikimi sipas fushëveprimit

Sipas fushës së aplikimit, sistemet e informacionit zakonisht ndahen në katër grupe:

* sistemet e përpunimit të transaksioneve;

* sistemet e vendimmarrjes;

* sistemet e informacionit dhe referencës;

* Sistemet e informacionit të zyrës.

Bibliografi

1. Agaltsov, V.P. Baza e të dhënave. Në 2 vëllime V. 2. Bazat e të dhënave të shpërndara dhe të largëta: Teksti mësimor / V.P. Agaltsov. - M .: ID FORUM, NITs INFRA-M, 2013.

2. Golitsyna, O. L. Bazat e të dhënave: Teksti mësimor / O.L. Golitsyna, N.V. Maksimov, I.I. Popov. - M .: Forum, 2012.

3. Karpova, I.P. Bazat e të dhënave: Teksti mësimor / I.P. Karpov. - SPb .: Peter, 2013.

4. Kirillov, V.V. Hyrje në bazat e të dhënave relacionale Hyrje në bazat e të dhënave relacionale. Kirillov, G.Yu. Gromov. - SPb .: BHV-Petersburg, 2012.

5. Pirogov, V.Yu. Sistemet e informacionit dhe bazat e të dhënave: organizimi dhe dizajni: Teksti mësimor / V.Yu. Pirogov. - SPb .: BHV-Petersburg, 2009.

6. G.N. Fedorov. Sistemet e Informacionit. - M .: Akademia, 2013.

7. A.E. Satunina, L.A. Sysoeva. Menaxhimi i projektit të sistemit të informacionit të korporatës së ndërmarrjes. - M .: Financa dhe statistika, Infra-M, 2009.

Postuar në Allbest.ru

...

Dokumente të ngjashme

Thelbi dhe karakteristikat e llojeve të modeleve të të dhënave: hierarkike, rrjetore dhe relacionale. Konceptet bazë të modelit të të dhënave relacionale. Atributet, skema e marrëdhënieve të bazës së të dhënave. Kushtet e integritetit të të dhënave. Marrëdhëniet ndërmjet tabelave. Kuptimi i përgjithshëm i modelit të të dhënave.

punim afatshkurtër, shtuar 29.01.2011


Sistemet e informacionit të korporatës dhe bazat e të dhënave, përdorimi i tyre për të përmirësuar dhe korrigjuar biznesin. Klasifikimi i sistemeve të informacionit të korporatës. Sistemet e informacionit të klasës OLTP. Përpunimi i shpejtë analitik.

punim termik shtuar 19.01.2011


Bazat e të dhënave me skedarë dydimensionale dhe sisteme të menaxhimit të bazës së të dhënave relacionale (DBMS). Krijimi i një baze të dhënash dhe përpunimi i pyetjeve për ta duke përdorur një DBMS. Llojet kryesore të bazave të të dhënave. Konceptet bazë të bazave të të dhënave relacionale. Karakteristikat themelore të marrëdhënieve.

abstrakt, shtuar më 20.12.2010


Koncepti i sistemit të bazës së të dhënave. Modeli relacional dhe karakteristikat e tij. Integriteti në modelin relacional. Algjebër relacionale. Problemet e projektimit të bazës së të dhënave. Format normale të marrëdhënieve. Dizajnimi i një baze të dhënash duke përdorur metodën entitet-relacion. Diagramet ER. Gjuha SQL.

kurs leksioni shtuar më 10/03/2008


Një strukturë logjike e përcaktuar e të dhënave që ruhet në një bazë të dhënash. Modelet bazë të të dhënave. Elementet e modelit të të dhënave relacionale. Një shembull i përdorimit të çelësave të huaj. Kërkesat themelore për marrëdhënien e modelit të të dhënave relacionale.

prezantimi u shtua më 14.10.2013


Bazat e të dhënave dhe përdorimi i tyre në informatikë. Karakteristikat dhe njësia bazë konstruktive e modelit të të dhënave të rrjetit. Modeli hierarkik, objektet e fushës lëndore. Modeli relacional, dukshmëria e tij, paraqitja e të dhënave në formë tabelare.

abstrakt, shtuar më 19.12.2011


Llojet dhe funksionet e sistemit të menaxhimit të bazës së të dhënave Microsoft Access. Modeli hierarkik, rrjetor, relacional për përshkrimin e bazave të të dhënave. Konceptet bazë të tabelës së bazës së të dhënave. Veçoritë e krijimit të objekteve të bazës së të dhënave, format bazë. Qasja në internet në Access.

test, shtuar 01/08/2011


Sistemet moderne të menaxhimit të bazës së të dhënave (DBMS). Analiza e modelit të të dhënave hierarkike. Modeli i të dhënave relacionale. Modeli i të dhënave post-relacionale si një model i zgjeruar relacional që heq kufizimin në pandashmërinë e të dhënave të ruajtura në të dhënat e tabelave.

punë shkencore, shtuar 06/08/2010


Modelet e të dhënave në menaxhimin e bazës së të dhënave. Modelet konceptuale të të dhënave. Roli i bazave të të dhënave në sistemet e informacionit. Modeli i të dhënave relacionale. Përkufizimi i fushës lëndore. Ndërtimi i modelit të bazës së të dhënave për sistemin e informacionit "Pets".

punim afatshkurtër, shtuar 19.04.2011


Modeli i informacionit në Access si një lloj zëvendësuesi i thjeshtuar për një objekt ose sistem real. Strukturat bazë që përcaktojnë organizimin e të dhënave dhe marrëdhëniet ndërmjet tyre; një lloj relacional i organizimit të të dhënave. Një shembull i një baze të dhënash në tatimet.

Modelet e të dhënave të industrisë

Qëllimi kryesor i modeleve është të lehtësojnë orientimin në hapësirën e të dhënave dhe të ndihmojnë në nxjerrjen në pah të detajeve që janë të rëndësishme për zhvillimin e biznesit. Në mjedisin e sotëm, për një biznes të suksesshëm, është e domosdoshme të kesh një kuptim të qartë të lidhjeve midis komponentëve të ndryshëm dhe të kesh një ide të mirë të pamjes së përgjithshme të organizatës. Identifikimi i të gjitha detajeve dhe marrëdhënieve duke përdorur modele lejon përdorimin më efikas të kohës dhe mjeteve për organizimin e punës së kompanisë.

Modelet e të dhënave janë modele abstrakte që përshkruajnë se si paraqiten dhe aksesohen të dhënat. Modelet e të dhënave përcaktojnë artikujt e të dhënave dhe marrëdhëniet ndërmjet tyre në një zonë të caktuar. Një model i të dhënave është një mjet navigimi si për biznesin ashtu edhe për profesionistët e TI-së që përdor një grup specifik simbolesh dhe fjalësh për të shpjeguar me saktësi një klasë specifike informacioni të botës reale. Kjo mundëson komunikim më të mirë brenda organizatës dhe kështu krijon një mjedis aplikimi më fleksibël dhe të qëndrueshëm.

Modeli i të dhënave përcakton në mënyrë unike kuptimin e të dhënave, që në këtë rast janë të dhëna të strukturuara (në krahasim me të dhënat e pastrukturuara siç janë, për shembull, një imazh, skedar binar ose tekst, ku kuptimi mund të jetë i paqartë).

Si rregull, dallohen modele të një niveli më të lartë (dhe më të përgjithshëm në përmbajtje) dhe një më të ulët (përkatësisht, më të detajuar). Niveli i sipërm i modelimit është i ashtuquajturi modelet konceptuale të të dhënave(modele konceptuale të të dhënave), të cilat japin pamjen më të përgjithshme të funksionimit të një ndërmarrje apo organizate. Modeli konceptual përfshin konceptet kryesore ose fushat lëndore që janë kritike për funksionimin e organizatës; zakonisht numri i tyre nuk i kalon 12-15. Një model i tillë përshkruan klasat e entiteteve që janë të rëndësishme për organizatën (objektet e biznesit), karakteristikat e tyre (atributet) dhe lidhjet midis çifteve të këtyre klasave (d.m.th., marrëdhëniet). Meqenëse terminologjia në modelimin e biznesit nuk është vendosur ende përfundimisht, në burime të ndryshme në gjuhën angleze, modelet konceptuale të të dhënave mund të quhen gjithashtu modeli i zonës së subjektit (i cili mund të përkthehet si modele domeni) ose modeli i të dhënave të ndërmarrjes së subjektit (modelet e të dhënave të subjektit të korporatës ).

Niveli tjetër hierarkik është modelet logjike të të dhënave(modele të të dhënave logjike). Ato mund të quhen gjithashtu modele të të dhënave të ndërmarrjes ose modele biznesi. Këto modele përmbajnë strukturat e të dhënave, atributet e tyre dhe rregullat e biznesit, dhe përfaqësojnë informacionin e përdorur nga një ndërmarrje nga perspektiva e biznesit. Në një model të tillë, të dhënat organizohen në formën e entiteteve dhe marrëdhënieve ndërmjet tyre. Modeli logjik paraqet të dhënat në një mënyrë që e bën të lehtë për t'u kuptuar nga përdoruesit e biznesit. Në një model logjik, mund të dallohet një fjalor i të dhënave - një listë e të gjitha entiteteve me përkufizimet e tyre të sakta, që lejon kategori të ndryshme përdoruesish të kenë një kuptim të përbashkët të të gjitha rrjedhave hyrëse dhe dalëse të informacionit të modelit. Niveli tjetër, më i ulët i modelimit është zbatimi fizik i modelit logjik duke përdorur softuer specifik dhe platforma teknike.

Modeli logjik përmban një vendim të detajuar të biznesit të korporatës, i cili zakonisht merr formën e një modeli të normalizuar. Normalizimi është një proces që siguron që çdo element i të dhënave në një model të ketë vetëm një vlerë dhe të varet plotësisht dhe në mënyrë unike nga çelësi primar. Artikujt e të dhënave organizohen në grupe sipas identifikimit të tyre unik. Rregullat e biznesit që rregullojnë artikujt e të dhënave duhet të përfshihen plotësisht në modelin e normalizuar me vlefshmëri dhe vërtetim paraprak. Për shembull, një artikull i të dhënave si Emri i Klientit ka të ngjarë të ndahet në Emër dhe Mbiemër dhe të grupohet me artikuj të tjerë të të dhënave të lidhura në një entitet klienti me një ID të klientit të çelësit kryesor.

Modeli i të dhënave logjike është i pavarur nga teknologjitë e aplikimit si bazat e të dhënave, teknologjitë e rrjetit ose mjetet e raportimit dhe mjetet e zbatimit fizik të tyre. Mund të ketë vetëm një model të të dhënave të ndërmarrjes në një organizatë. Modelet logjike zakonisht përfshijnë mijëra entitete, marrëdhënie dhe atribute. Për shembull, një model i të dhënave për një institucion financiar ose kompani telekomunikacioni mund të përmbajë rreth 3000 koncepte të industrisë.

Është e rëndësishme të bëhet dallimi midis modelit të të dhënave logjike dhe semantike. Modeli i të dhënave logjike përfaqëson një zgjidhje biznesi të ndërmarrjes, dhe modeli i të dhënave semantike përfaqëson një zgjidhje të aplikuar biznesi. I njëjti model i të dhënave logjike të korporatës mund të zbatohet duke përdorur modele të ndryshme semantike, d.m.th. modelet semantike mund të shihen si niveli tjetër i modelimit që i afrohet modeleve fizike. Për më tepër, secili prej këtyre modeleve do të përfaqësojë një "pjesë" të veçantë të modelit të të dhënave të korporatës në përputhje me kërkesat e aplikacioneve të ndryshme. Për shembull, në modelin e të dhënave logjike të korporatës, entiteti Klient do të normalizohet plotësisht, dhe në modelin semantik për margjinën e të dhënave, ai mund të përfaqësohet si një strukturë shumëdimensionale.

Një kompani mund të ketë dy mënyra për të krijuar një model të të dhënave logjike të korporatës: ta ndërtojë atë në mënyrë të pavarur ose të përdorë një të gatshëm. modeli i industrisë(modeli i të dhënave logjike të industrisë). Në këtë rast, dallimet në terma pasqyrojnë vetëm qasje të ndryshme për ndërtimin e të njëjtit model logjik. Në rast se një kompani zhvillon dhe zbaton në mënyrë të pavarur modelin e vet logjik të të dhënave, atëherë një model i tillë, si rregull, quhet thjesht një model logjik i korporatës. Nëse një organizatë vendos të përdorë një produkt të gatshëm nga një furnizues profesionist, atëherë mund të flasim për një model të dhënash logjike të industrisë. Ky i fundit është një model i gatshëm i të dhënave logjike që pasqyron funksionimin e një industrie të caktuar me një shkallë të lartë saktësie. Një model logjik i industrisë është një pamje specifike e domenit dhe e integruar e të gjithë informacionit që duhet të qëndrojë në një depo të të dhënave të ndërmarrjes për t'iu përgjigjur pyetjeve strategjike dhe taktike të biznesit. Ashtu si çdo model i të dhënave logjike, modeli i industrisë është i pavarur nga vendimet e aplikimit. Ai gjithashtu nuk përfshin të dhëna të përftuara ose llogaritje të tjera për rikthim më të shpejtë të të dhënave. Si rregull, shumica e strukturave logjike të një modeli të tillë janë mishëruar mirë në zbatimin e tij efektiv fizik. Modele të tilla janë zhvilluar nga shumë furnitorë për një gamë të gjerë fushash të veprimtarisë: financa, prodhimi, turizmi, kujdesi shëndetësor, sigurimet, etj.

Një model i të dhënave logjike të industrisë përmban informacione që janë të zakonshme për industrinë dhe për këtë arsye nuk mund të jetë një zgjidhje gjithëpërfshirëse për një kompani. Shumica e kompanive duhet të rrisin modelin me një mesatare prej 25% duke shtuar artikujt e të dhënave dhe duke zgjeruar përkufizimet. Modelet jashtë kutisë përmbajnë vetëm elementë kryesorë të të dhënave, dhe pjesa tjetër e elementeve duhet t'u shtohen objekteve përkatëse të biznesit gjatë instalimit të modelit në kompani.

Modelet e të dhënave logjike të industrisë përmbajnë një sasi të konsiderueshme abstraksioni. Abstraksionet nënkuptojnë bashkimin e koncepteve të ngjashme nën emra të zakonshëm si Ngjarje ose Pjesëmarrës. Kjo shton fleksibilitet dhe uniformitet në modelet e industrisë. Kështu, koncepti i një ngjarjeje është i zbatueshëm për të gjitha industritë.

Specialisti i Inteligjencës së Biznesit, Steve Hoberman, identifikon pesë faktorë që duhen marrë parasysh kur vendosni nëse do të blini një model të dhënash të industrisë. E para është koha dhe paratë e nevojshme për të ndërtuar modelin. Nëse një organizatë duhet të arrijë rezultate shpejt, atëherë modeli i industrisë do të jetë i dobishëm. Përdorimi i një modeli të industrisë mund të mos sigurojë menjëherë një pamje të të gjithë organizatës, por mund të kursejë një sasi të konsiderueshme kohe. Në vend të modelimit të vetvetes, koha do të shpenzohet për të lidhur strukturat ekzistuese me modelin e industrisë dhe për të diskutuar mënyrën më të mirë për ta përshtatur atë me nevojat e organizatës (për shembull, cilat përkufizime duhet të ndryshohen dhe cilat artikuj të të dhënave duhet të shtohen).

Faktori i dytë është koha dhe paratë e nevojshme për të mbajtur modelin në gjendje të mirë pune. Nëse modeli i të dhënave të ndërmarrjes nuk është pjesë e një metodologjie që ju lejon të monitoroni pajtueshmërinë me saktësinë e tij dhe përputhjen me standardet moderne, atëherë një model i tillë bëhet shumë shpejt i vjetëruar. Modeli i të dhënave të industrisë mund të parandalojë që ky rrezik të ndodhë pasi mbahet i përditësuar me burimet e jashtme. Sigurisht, ndryshimet që ndodhin brenda organizatës duhet të pasqyrohen në model nga vetë kompania, por ndryshimet e industrisë do të riprodhohen në model nga furnizuesi i saj.

Faktori i tretë është përvoja në vlerësimin dhe modelimin e riskut. Krijimi i një modeli të të dhënave të korporatës kërkon burime të kualifikuara si nga biznesi ashtu edhe nga stafi i IT. Si rregull, menaxherët janë të vetëdijshëm ose për punën e organizatës në tërësi, ose për aktivitetet e një departamenti të caktuar. Pak prej tyre kanë njohuri të gjera (për të gjithë kompaninë) dhe të thellë (brenda departamenteve) për biznesin e tyre. Shumica e menaxherëve zakonisht njohin mirë vetëm një fushë. Prandaj, për të marrë pamjen e përgjithshme të korporatës, kërkohen burime të konsiderueshme të biznesit. Kjo gjithashtu rrit kërkesat për stafin e IT. Sa më shumë burime biznesi kërkohen për të krijuar dhe testuar një model, aq më shumë analistët duhet të jenë me përvojë. Ata jo vetëm që duhet të dinë të marrin informacion nga stafi i biznesit, por edhe të jenë në gjendje të gjejnë një këndvështrim të përbashkët në fushat e diskutueshme dhe të jenë në gjendje t'i paraqesin të gjitha këto informacione në mënyrë të integruar. Personi që krijon modelin (në shumë raste i njëjti analist) duhet të ketë aftësi të mira modeluese. Ndërtimi i modeleve logjike të ndërmarrjes kërkon modelim "për të ardhmen" dhe aftësinë për të kthyer fjalë për fjalë biznesin kompleks "në katrorë dhe vija".

Nga ana tjetër, modeli i industrisë lejon ekspertizë të jashtme. Modelet logjike specifike të industrisë janë ndërtuar duke përdorur metodologji të provuara modelimi dhe ekipe profesionistësh me përvojë për të shmangur problemet e zakonshme dhe të kushtueshme që mund të lindin kur zhvillohen modele të të dhënave të ndërmarrjes brenda një organizate.

Faktori i katërt është infrastruktura ekzistuese e aplikimit dhe marrëdhëniet me furnizuesit. Nëse një organizatë tashmë përdor shumë mjete nga i njëjti furnizues dhe ka krijuar marrëdhënie me të, atëherë ka kuptim dhe modeli i industrisë të porositet prej tij. Ky model do të jetë në gjendje të punojë lirshëm me produkte të tjera nga i njëjti furnizues.

Faktori i pestë është shkëmbimi i informacionit brenda industrisë. Nëse një kompani duhet të komunikojë me organizata të tjera që punojnë në të njëjtën fushë, atëherë modeli i industrisë mund të jetë shumë i dobishëm në këtë situatë. Organizatat brenda së njëjtës industri përdorin komponentë dhe terminologji të ngjashme strukturore. Në ditët e sotme, në shumicën e industrive, kompanitë janë të detyruara të shkëmbejnë të dhëna për të zhvilluar me sukses biznesin.

Më efektive janë modelet e industrisë të ofruara nga furnitorë profesionistë. Efikasiteti i lartë i përdorimit të tyre arrihet për shkak të nivelit të konsiderueshëm të detajeve dhe saktësisë së këtyre modeleve. Zakonisht ato përmbajnë shumë atribute të dhënash. Për më tepër, krijuesit e këtyre modeleve jo vetëm që kanë përvojë të gjerë modelimi, por janë gjithashtu të përgatitur mirë në ndërtimin e modeleve për një industri të caktuar.

Modelet e të dhënave të industrisë u ofrojnë kompanive një pamje të vetme dhe të integruar të informacionit të tyre të biznesit. Shumë kompani e kanë të vështirë të integrojnë të dhënat e tyre, megjithëse ky është një parakusht për shumicën e projekteve në mbarë ndërmarrjen. Sipas një studimi nga Instituti i Deponimit të të Dhënave (TDWI), më shumë se 69% e organizatave të anketuara gjetën se integrimi ishte një pengesë e rëndësishme për miratimin e aplikacioneve të reja. Përkundrazi, zbatimi i integrimit të të dhënave gjeneron të ardhura të prekshme për kompaninë.

Modeli i të dhënave të industrisë, përveç lidhjes me sistemet ekzistuese, ofron përfitime të mëdha për projektet në mbarë ndërmarrjen, si Planifikimi i Burimeve të Ndërmarrjeve (ERP), menaxhimi kryesor i të dhënave, inteligjenca e biznesit, përmirësimi i cilësisë së të dhënave dhe zhvillimi i punonjësve.

Kështu, modelet e të dhënave logjike të industrisë janë një mjet efektiv për integrimin e të dhënave dhe marrjen e një pamje holistik të biznesit. Përdorimi i modeleve logjike duket të jetë një hap i domosdoshëm drejt krijimit të depove të të dhënave të korporatave.

Publikimet

1. Steve Hoberman. Përdorimi i modelit të të dhënave logjike të industrisë si modeli juaj i të dhënave të ndërmarrjes.
2. Claudia Imhoff. Projektet e ruajtjes së të dhënave me ndjekje të shpejtë dhe inteligjencës biznesore nëpërmjet modelimit inteligjent të të dhënave

Qëllimi i ligjëratës

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

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

dhe mësoni të:

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

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

Prezantimi

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

Krahasuar me projektimin e sistemeve OLTP, metodologjia e projektimit të CD-ve ka një sërë veçorish dalluese që lidhen me orientimin e strukturave të të dhënave të ruajtjes për të zgjidhur problemet e analizës dhe mbështetjes së informacionit të procesit të vendimmarrjes. Modeli i të dhënave HD duhet të ofrojë një zgjidhje efektive pikërisht për këto probleme.

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

Në këtë mënyrë, modeli i të dhënave të ndërmarrjes përmban informacionin e nevojshëm për të ndërtuar një model CD. Prandaj, në fazën e parë, nëse një model i tillë ekziston në organizatë, projektuesi HD mund të fillojë dizajnin HD duke zgjidhur problemin e transformimit modeli i të dhënave të korporatës në modelin HD.

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

Si të zgjidhet problemi i transformimit modeli i të dhënave të korporatës në modelin HD? Për të zgjidhur këtë problem, duhet të keni këtë model, d.m.th. modeli i të dhënave të korporatës duhet të ndërtohet dhe të dokumentuara... Dhe ju duhet të kuptoni çfarë nga ky model dhe si duhet të transformohet në model HD.

Le të sqarojmë konceptin nga këndvështrimi i një projektuesi CD modeli i të dhënave të korporatës. Nën modeli i të dhënave të korporatës kuptojnë një përshkrim të strukturuar në shumë nivele të fushave lëndore të një organizate, strukturat e të dhënave të fushës lëndore, proceset e biznesit dhe procedurat e biznesit, flukset e të dhënave organizative, diagramet e gjendjes, matricat e procesit të të dhënave dhe paraqitjet e tjera të modeleve që përdoren në aktivitetet e organizatës. Kështu, në kuptimin më të gjerë të fjalës, modeli i të dhënave të ndërmarrjesështë një grup modelesh të niveleve të ndryshme që karakterizojnë (model në një nivel abstrakt) aktivitetet e një organizate, d.m.th. përmbajtjen modeli i korporatës varet drejtpërdrejt nga modeli i ndërtimeve të përfshira në të në një organizatë të caktuar.

Elementet kryesore modeli i të dhënave të korporatës janë:

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

Në këtë mënyrë, modeli i të dhënave të ndërmarrjes përmban entitete, atribute dhe marrëdhënie që përfaqësojnë nevojat e informacionit të një organizate. Në fig. 16.1 tregon elementet kryesore modeli i të dhënave të korporatës.

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

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

Çdo model logjik duhet të korrespondojë me domenin ekzistues modeli i të dhënave të korporatës... Nëse modeli logjik nuk e plotëson këtë kërkesë, atij duhet t'i shtohet një model domeni.

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

Oriz. 16.2.

Diagrami i paraqitur në figurë paraqet katër fusha lëndore: "Blerësi" ( Klienti), "Kontrollo" ( llogari), "Urdhri" ( Rendit) dhe "Produkt" ( Produkt). Si rregull, vetëm lidhjet e drejtpërdrejta ndërmjet fushave lëndore, të cilat, për shembull, regjistrojnë faktin e mëposhtëm: blerësi paguan faturën për porosinë e mallit. Detaje dhe marrëdhënie indirekte në këtë nivel modeli i korporatës nuk tregohet.

në tjetrën, niveli i mesëm(niveli i mesëm) modeli i të dhënave të korporatës tregohen informacione të hollësishme për objektet e fushave lëndore, d.m.th., çelësat dhe atributet e entitetit, marrëdhëniet e tyre, nëntipet dhe supertipet etj. Për çdo domen të modelit të nivelit të lartë, ekziston një model i nivelit të mesëm. Në fig. 16.3 tregon nivelin e mesëm të prezantimit modeli i korporatës për një fragment të fushës lëndore "Urdhëri".

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

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

Nga pikëpamja e dizenjimit të një CD, një faktor i rëndësishëm për të vendosur për të krijuar një model CD nga modeli i të dhënave të korporatësështë shteti plotësinë modeli i të dhënave të korporatës.

Modeli i të dhënave të ndërmarrjes organizata ka karakteristikën evolucionare, d.m.th. është duke u zhvilluar dhe përmirësuar vazhdimisht. Disa fusha lëndore modeli i të dhënave të korporatës mund të jetë i zhvilluar mirë, për disa puna mund të mos ketë filluar ende. Nëse një fragment i fushës së temës nuk është punuar në modeli i të dhënave të korporatës, atëherë nuk ka asnjë mënyrë për të përdorur këtë model si pikënisje për hartimin e CD-së.

Shkalla e përfundimit modeli i korporatës mund të nivelohet në dizajnin e CD-së si më poshtë. Meqenëse procesi i zhvillimit HD zakonisht ndahet në kohë në një sekuencë fazash, procesi i dizajnimit të tij mund të sinkronizohet me procesi i përfundimit zhvillimi i fragmenteve individuale modeli i të dhënave të korporatës organizatave.

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