Бұл мақала деректер қоймасының архитектурасына назар аударады. Оны салу кезінде нені басшылыққа алу керек, жұмысқа қай көзқарас - және неге.

«Ертегі өтірік, бірақ оның ішінде түсінік бар ...»

Атамыз ертегіден қандай шешім қабылдаса да – жаңа қойма салу немесе бұрыннан барын қайта жандандыру – қайта «жеңді түрмек» алдында қорытынды жасау керек.
Ұйымдастырушылық аспектілерді былай қояйық - мысалы, белгілі бір тар жабық топқа сараптаманың шоғырлану қаупі, басқару процестерінің болмауы және кәсіпорында қолданылатын жүйелер архитектурасының ашықтығын қамтамасыз ету және т.б.
Бүгін мен белгілі бір жүйенің (немесе жүйелер тобының) – деректер қоймасының архитектурасын құруға тоқталғым келеді. Ұйым қойма сияқты күрделі және қымбат жүйені құра бастағанда, ең алдымен, нені назарда ұстау керек.

Дебрифинг

Бастау үшін репозиторийлермен жұмыс істеу кезінде жиі кездесетін типтік мәселелердің тізімін берейік. Бізде бар нәрсені жазып алайық – әзірге ретке келтіріп, рәсімдеуге тырыспай-ақ.

1. Негізінде, бізде жақсы сақтау орны бар: егер сіз оны жалғыз қалдырсаңыз, онда бәрі жұмыс істейді. Рас, өзгерту қажет болған кезде «жергілікті күйреулер» басталады.
2. Деректер күн сайын, ережелерге сәйкес, бір үлкен процесте, 8 сағат ішінде жүктеледі. Және ол бізге жарасады. Бірақ кенеттен сәтсіздік орын алса, ол қолмен араласуды қажет етеді. Содан кейін бәрі ұзақ уақыт бойы күтпеген жерден жұмыс істей алады, tk. процеске адамның қатысуын талап етеді.
3. Шығарылымды жинадық - проблемаларды күтіңіз.
4. Кейбір бір дереккөз деректерді уақытында жібере алмады - барлық процестер күтуде.
5. Деректердің тұтастығын дерекқор басқарады, сондықтан ол бұзылған кезде біздің процестеріміз бұзылады.
6. Бізде өте үлкен сақтау орны бар - бір жалпы схемадағы 2000 кесте. Көптеген басқа схемаларда тағы 3000. Бізде олардың қалай орналасқаны және қандай себеппен пайда болғаны туралы аз түсінік бар. Сондықтан бір нәрсені қайта пайдалану бізге қиын болуы мүмкін. Және көптеген міндеттерді жаңадан шешуге тура келеді. Өйткені, бұл оңай және жылдамырақ («біреудің кодын» түсінуге қарағанда). Нәтижесінде бізде сәйкессіздіктер және қайталанатын функциялар бар.
7. Біз дереккөздің сапалы деректер береді деп күтеміз. Бірақ олай емес екені белгілі болды. Нәтижесінде біз қорытынды есептерді салыстыруға көп уақыт жұмсаймыз. Және олар бұл істе өте сәтті болды. Бізде тіпті жеңілдетілген процесс бар. Рас, уақыт керек. Бірақ пайдаланушылар әдеттенген ...
8. Пайдаланушы біздің есептерімізге әрқашан сенбейді және бір немесе басқа цифрдың негіздемесін талап етеді. Кейбір жағдайларда ол дұрыс, ал басқаларында олай емес. Бірақ біз үшін оларды ақтау өте қиын, өйткені бізде «соңғы талдау» (немесе деректер желісі) құралдары жоқ.
9. Біз қосымша әзірлеушілерді тарта аламыз. Бірақ бізде бір мәселе бар – оларды жұмысқа қалай қосамыз? Жұмыстарды параллельдеудің ең тиімді жолы қандай?
10. Бір жыл бойы «жүйенің өзегін» дамытуға бармай-ақ, жүйені қалай біртіндеп дамытуға болады?
11. Деректер қоймасы корпоративтік үлгімен байланысты. Бірақ біз нақты білеміз (біз оны XYZ банкінде көрдік) модель құру шексіз ұзаққа созылуы мүмкін (біз алты ай бойы XYZ банкіне бардық және ешқандай қозғалыссыз кәсіпкерлік субъектілерін талқыладық). Неге ол мүлде? Немесе онымен проблемалар көп болса, онсыз жақсы ма? Мүмкін біз оны қандай да бір жолмен жасай аламыз ба?
12. Біз модельді жүргізуді шештік. Бірақ қойма деректерінің үлгісін жүйелі түрде қалай дамытасыз? Бізге «ойын ережелері» керек пе және олар не болуы мүмкін? Ол бізге не береді? Үлгіде қателессек ше?
13. «Бизнеске қажет болмаса» деректерді немесе оның өзгеру тарихын сақтау керек пе? Мен «қоқыстарды сақтауды» және бұл деректерді нақты тапсырмалар үшін пайдалануды қиындатуды қаламас едім. Қойма тарихты сақтауы керек пе? Ол қандай? Уақыт бойынша сақтау қалай жұмыс істейді?
14. Бізде деректерді басқарудың негізгі жүйесі болса, жадтағы деректерді бір жүйеге келтіруге тырысуымыз керек пе? Егер MDM болса, бұл негізгі деректерге қатысты барлық мәселе қазір шешілді дегенді білдіре ме?
15. Жақын арада негізгі есеп жүйелерін ауыстырамыз деп күтілуде. Деректер қоймасы дереккөзді өзгертуге дайын болуы керек пе? Бұған қалай қол жеткізуге болады?
16. Бізге метадеректер керек пе? Мұнымен не айтқымыз келеді? Оларды нақты қай жерде қолдануға болады? Оны қалай жүзеге асыруға болады? Мен оларды «бір жерде» сақтауым керек пе?
17. Біздің тұтынушылар өз талаптары мен тілектері бойынша өте тұрақсыз - бір нәрсе үнемі өзгеріп отырады. Жалпы, біздің бизнес өте қарқынды. Біз бірдеңе істеп жатқанда, ол қажетсіз болып қалады. Нәтижені мүмкіндігінше тез беретіндей етіп қалай жасай аламыз - ыстық пирожныйлар сияқты?
18. Пайдаланушылар жауап беруді талап етеді. Бірақ біз негізгі жүктеу процестерін жиі іске қоса алмаймыз, өйткені бұл бастапқы жүйелерді жүктейді (өнімділікке нашар әсер етеді) - сондықтан біз қосымша деректер ағындарын іліп қоямыз - олар бізге қажет нәрсені нүктелік түрде қабылдайды. Рас, ағындар көп. Содан кейін біз кейбір деректерден бас тартамыз. Оның үстіне конвергенция мәселесі туындайды. Бірақ басқа амал жоқ...

Қатты сынғыштық

Біраз уақыттан кейін сурет келесідей:
«Міне, қойма. Ал қол тигізбесеңіз жұмыс істейді. Біз бір нәрсені өзгертуіміз керек болғанда проблемалар туындайды ».

Бізге өзгеріс келеді, оның әсерін біз бағалай алмаймыз және түсіне алмаймыз (өйткені біз мұндай құралдарды басынан бастап жүйеге енгізбегенбіз) - және тәуекелге бармау үшін біз бар нәрсеге қол тигізбейміз, бірақ біз бүйір жағына тағы бір кеңейту жасаймыз, екіншісін жасаймыз, сонымен қатар - шешімімізді қараңғы жерлерге немесе Латын Америкасында айтқандай, полицияның кіруге қорқатын «фавелаларға» айналдырамыз.
Өз жүйесіне бақылауды жоғалту, хаос сезімі бар. Бар процестерді қолдау және мәселелерді шешу үшін көбірек қол қажет. Ал өзгерістер жасау барған сайын қиындап барады. Басқаша айтқанда, жүйе стресске тұрақсыз, өзгерістерге бейімделмейтін болады. Оның үстіне, ешкімде «карта» болмағандықтан, «фарвейді» білетін кейіпкерлерге қатты тәуелділік бар.

Нысанның бұл қасиеті – хаос, кездейсоқ оқиғалар мен күйзелістердің әсерінен құлау – Нассим Николас Талеб шақырады. сынғыштық ... Және де қарама-қарсы ұғымды енгізеді: сынғыштық – объект күйзеліс пен апаттан құламай, одан тікелей пайда көргенде... («Қарсылық. Хаостан қалай пайда табуға болады»)
Әйтпесе, оны шақыруға болады бейімделушілік немесе өзгерістерге төзімділік .

Бұл контексте бұл нені білдіреді? АТ жүйелерінің «хаос көздері» қандай? Ал IT архитектурасы тұрғысынан «хаосқа капиталдандыру» нені білдіреді?
Ойға бірінші келетін ой – сырттан келетін өзгерістер. Жүйе үшін сыртқы әлем дегеніміз не? Әсіресе сақтау үшін. Әрине, ең алдымен - дүкенге арналған деректер көздері жағынан өзгерістер:

• кіріс деректердің форматтарын өзгерту;
• деректер көздерінің кейбір жүйелерін басқаларымен ауыстыру;
• жүйелерді біріктіру үшін ережелерді/платформаларды өзгерту;
• мәліметтерді интерпретациялауды өзгерту (форматтар сақталады, деректермен жұмыс істеу логикасы өзгереді);
• егер интеграция деректер деңгейінде орындалса, деректер үлгісін өзгерту (деректер базасындағы транзакциялар журналының файлдарын талдау);
• деректер көлемінің өсуі - бастапқы жүйеде деректер аз болған кезде және жүктеме жоғары болмаса - оны кез келген уақытта алуға болатын, ерікті түрде ауыр сұраумен, деректер мен жүктеме өсті - қазір қатаң шектеулер бар ;
• және т.б.

Қойма тұтынушыларының бастамасымен маңызды өзгерістер (талаптардың өзгеруі):

• бұрын есепті құру үшін деректер жеткілікті болды - енді қосымша өрістерді немесе жаңа деректер көзін қосу қажет болды;
• бұрын енгізілген деректерді өңдеу әдістері ескірген - алгоритмдерді және оған әсер ететін барлық нәрсені қайта өңдеу керек;
• Бұрын ақпарат тақтасындағы сөздік атрибутының ағымдағы мәніне барлығы қанағаттанған - енді талданатын факт/оқиға сәтінде өзекті мән талап етіледі;
• бұрын болмаған деректерді сақтау тарихының тереңдігі туралы талап болды - деректерді 2 жыл емес, 10 жыл бойы сақтау;
• бұрын «күннің/кезеңнің» соңы бойынша деректер жеткілікті болды - енді сізге «күн ішінде» немесе белгілі бір оқиға кезінде (мысалы, несиелік өтінім бойынша шешім қабылдау үшін) деректер күйі қажет. Базель II);
• бұрын біз кешегі (Т-1) немесе одан кейінгі деректер бойынша есеп берумен қанағаттанатынбыз, енді бізге T0 қажет;
• және т.б.

Бірақ бұл бәрі емес.
Өзгергіштік туралы айтатын болсақ, біз, ең алдымен, сыртқы факторларды еске түсіреміз. Өйткені, біз іштей бәрін басқара аламыз, бізге солай көрінеді, солай ма? Иә және жоқ. Иә, әсер ету аймағынан тыс факторлардың көпшілігі сыртқы. Бірақ «ішкі энтропия» да бар. Дәл оның болуына байланысты біз кейде «0 нүктесіне» оралуымыз керек. Ойынды басынан бастаңыз.
Өмірде біз көбінесе нөлден бастаймыз. Неліктен бұл бізге ерекше? Және бұл шынымен де жаман ба?
IT-ға қолданылады. Жүйенің өзі үшін - бұл өте жақсы болуы мүмкін - жеке шешімдерді қайта қарау мүмкіндігі. Әсіресе, біз мұны жергілікті жерде жасай алатын болсақ. Рефакторинг – жүйені дамыту процесінде мезгіл-мезгіл пайда болатын «вебті» ашу процесі. Басына оралу пайдалы болуы мүмкін. Бірақ оның бағасы бар.
Құзыретті архитектураны басқару кезінде бұл баға төмендейді - жүйені әзірлеу процесінің өзі басқарылатын және ашық болады. Қарапайым мысал: модульдік принцип сақталса, әсер етпестен бөлек модульді қайта жазуға болады сыртқы интерфейстер... Және бұл монолитті құрылыммен жасалмайды.

Жүйенің сынғыштығы оған енгізілген архитектурамен анықталады. Және дәл осы қасиеті оны бейімделгіш етеді.
Біз сөйлескен кезде адаптивті архитектура- бұл жүйенің өзгерістерге бейімделе алатынын айтамыз, бірақ біз архитектураның өзін үнемі өзгертіп отырамыз дегенді білдірмейміз. Керісінше, архитектура неғұрлым тұрақты және тұрақты болса, оны қайта қарауды талап ететін талаптар аз болса, жүйе соғұрлым бейімделеді.

Бүкіл архитектураны қайта қарауды қамтитын шешімдер әлдеқайда жоғары бағаға ие болады. Және оларды қабылдау үшін сізде өте жақсы себептер болуы керек. Мысалы, мұндай негіздеме бар архитектурада жүзеге асырылмайтын талап болуы мүмкін. Содан кейін олар айтады - архитектураға әсер ететін талап пайда болды.
Сонымен, біз өзіміздің «қызғыштыққа қарсы шектеулерді» білуіміз керек. Архитектура «вакуумда» дамымайды – ол қазіргі талаптар мен күтуге негізделген. Ал егер жағдай түбегейлі өзгерсе - біз қазіргі архитектурадан шығып кеткенімізді түсінуіміз керек - және біз оны қайта қарап, басқа шешімді әзірлеуіміз керек - және өтпелі жолдарды ойластыруымыз керек.
Мысалы, біз сақтауда бізге күннің соңында деректер әрқашан қажет болады деп ойладық, біз күн сайын деректерді жинаймыз стандартты интерфейстержүйелер (көріністер жиыны арқылы). Содан кейін тәуекелдерді басқару бөлімінен мәліметтерді күннің соңында емес, несие беру туралы шешім қабылданған кезде алу қажеттілігі туралы сұраныс келді. «Қарсылмағанды ​​тартуға» тырысудың қажеті жоқ - сіз бұл фактіні мойындауыңыз керек - соғұрлым тезірек жақсы. Мәселені шешуге мүмкіндік беретін тәсілмен жұмыс істей бастаңыз.
Бұл жерде өте нәзік сызық бар - егер біз тек «қазіргі уақыттағы талаптарды» ескерсек және бірнеше қадам алға (және бірнеше жыл алға) қарамасақ, онда біз архитектураға әсер ететін талапты кешіктіру қаупін арттырамыз - және біздің өзгерістің бағасы өте жоғары болады. Кішкене алға қарай - біздің көкжиегіміздің шекарасында - әлі ешкімге зиян тигізген жоқ.

«Сақтау ертегісіндегі» жүйенің мысалы нәзік дизайн тәсілдеріне негізделген өте дірілдеген жүйенің бір мысалы ғана. Ал егер бұл орын алса, жүйенің дәл осы класы үшін жойылу өте тез жүреді.
Неге олай айта аламын? Репозиторийлер тақырыбы жаңа емес. Осы уақыт ішінде жасалған тәсілдер мен инженерлік тәжірибелер дәл осы мақсатқа бағытталған - жүйенің өміршеңдігін сақтауға.
Қарапайым мысал: ең бірі жалпы себептер«Ұшу кезінде» сақтау жобаларының сәтсіздігі - интеграциялық интерфейстер туралы келіспеусіз әзірлену үстіндегі бастапқы жүйелердің үстіне қойма құру әрекеті - деректерді кестелерден тікелей алу әрекеті. Нәтижесінде біз әзірлеуге кірістік - осы уақыт ішінде бастапқы дерекқор өзгерді - және репозиторийдегі жүктеу ағындары жұмыс істемейтін болды. Бір нәрсені қайта жасауға тым кеш. Егер сіз қойманың ішінде бірнеше қабат кестелер жасау арқылы өзіңізді әлі қорғамаған болсаңыз, онда бәрін тастап, басынан бастауға болады. Бұл бір ғана мысал және қарапайым мысалдардың бірі.

Талебтің сынғыш және сынғыштық критерийі қарапайым. Басты төреші – уақыт. Жүйе уақыт сынына төтеп беріп, өзінің «өміршеңдігін» және «бұзылмайтындығын» көрсетсе – оның сынғыштық қасиеті бар.
Егер жүйені жобалау кезінде біз талап ретінде сынғыштықты ескерсек, бұл жүйені «сырттан келген хаосқа» да, «іштен келген хаосқа» да бейімделгіш ететін оның архитектурасын құрудың осындай тәсілдерін қолдануға итермелейді. . Ал, сайып келгенде, жүйенің қызмет ету мерзімі ұзағырақ болады.
Ешқайсымыз «қайтадан үй» салғымыз келмейді. Және өзіңізді алдамаңыз, бұл бүгінде басқа жол емес. Адамның кез келген уақытта, әсіресе дағдарыс кезінде бірнеше қадам алға қарауы қалыпты жағдай.

Деректер қоймасы дегеніміз не және оны не үшін жасап жатырмыз

Деректер қоймасы қажет деген ойға адамдар қалай келді? Және олардың жай ғана «өте үлкен дерекқордан» айырмашылығы неде?
Ұзақ уақыт бұрын, әлемде жай ғана «бизнес-мәліметтерді өңдеу жүйелері» болған кезде, АТ жүйелерін front-end oltp жүйелері, бэк-офис dss, мәтінді өңдеу жүйелері, деректер қоймалары және т.б. сияқты сыныптарға бөлу болған жоқ.
Дәл осы уақытта Майкл Стоунбрейкер бірінші реляциялық дерекқор қозғалтқышы Ingres-ті жасады.
Ал ол заман сол кез еді дербес компьютерлерсоққан дауыл сияқты компьютерлік индустрияжәне сол кездегі IT қауымдастығының барлық идеяларын мәңгілікке өзгертті.

Ол кезде Clipper, dBase және FoxPro сияқты жұмыс үстелі класындағы ДҚБЖ негізінде жазылған кәсіпорын қолданбаларын табу оңай болды. Және нарық клиент-сервер қолданбаларыжәне ДҚБЖ енді ғана қарқын ала бастады. Деректер базасының серверлері бірінен соң бірі пайда болды, олар АТ кеңістігінде өз орнын ұзақ уақыт алады - Oracle, DB2 және т.б.
Ал «деректер базасының қосымшасы» термині кең таралған. Мұндай өтініш нені қамтиды? Жеңілдетілген – пайдаланушылар бір уақытта ақпаратты енгізе алатын кейбір енгізу пішіндері, «батырма арқылы» немесе «кесте бойынша» іске қосылған кейбір есептеулер, сондай-ақ экранда көруге болатын немесе файл ретінде сақталатын және мөрге жіберілетін кейбір есептер.
«Ештеңе ерекше емес - қалыпты қолдану, тек мәліметтер базасы бар», - деп менің тәлімгерлерімнің бірі мансап жолының бастапқы кезеңінде осылай атап өтті. - Демек, ерекше ештеңе жоқ па? – Мен сонда ойладым.

Мұқият қарасаңыз, әлі де кейбір ерекшеліктер бар. Пайдаланушылар өскен сайын кіріс ақпарат көлемі артады, жүйеге жүктеме артқан сайын оны әзірлеушілер, дизайнерлер өнімділікті қолайлы деңгейде ұстау үшін кейбір «трюктерге» барады. Біріншісі – монолитті «бизнес деректерін өңдеу жүйесін» пайдаланушыларды on-line режимінде қолдайтын бухгалтерлік қосымшаға және деректерді пакеттік өңдеуге және есеп беруге арналған жеке қосымшаға бөлу. Бұл қолданбалардың әрқайсысының өз дерекқоры бар және тіпті дерекқор серверінің бөлек данасында орналастырылған әртүрлі параметрлерәртүрлі жүктеме түрлері үшін - OLTP және DSS. Және деректер ағындары олардың арасында түзетіледі.

Барлығы ма? Мәселе шешілген сияқты. Әрі қарай не болады?
Содан кейін компаниялар өседі, олардың ақпараттық қажеттіліктері көбейеді. Сыртқы әлеммен қарым-қатынастар саны да артып келеді. Ал соңында біреуден көп тамаша қолданба, ол барлық процестерді толығымен автоматтандырады, бірақ әртүрлі өндірушілердің бірнеше әртүрлі. Компанияда ақпарат – деректер көзі жүйелерін генерациялайтын жүйелердің саны артып келеді. Ал ерте ме, кеш пе, әртүрлі жүйелерден алынған ақпаратты көру және салыстыру қажеттілігі туындайды. Компанияда деректер қоймалары осылай пайда болады - жүйелердің жаңа класы.
Бұл жүйелер класының жалпы қабылданған анықтамасы келесідей.

Деректер қоймасы (немесе деректер қоймасы)- ұйымда шешім қабылдауды қолдау мақсатында есептерді дайындау және бизнесті талдау үшін арнайы әзірленген және әзірленген пәнге бағытталған ақпараттық деректер базасы

Мәліметтер қоймасының негізгі ерекшеліктері

Біріншіден, бұл үлкен көлемдер. Өте үлкен. VLDB - жетекші жеткізушілер өз өнімдерін пайдалану бойынша ұсыныстарын бергенде мұндай жүйелерді осылай атайды. Компанияның барлық жүйелерінен деректер осы үлкен дерекқорға түседі және оқулықтарда айтылғандай «мәңгі және өзгеріссіз» сақталады (тәжірибеде өмір күрделірек болып шығады).

Екіншіден, бұл тарихи деректер – «Корпоративтік жады» - деректер қоймалары деп аталады. Репозиторийлерде уақытпен жұмыс істеу тұрғысынан бәрі өте қызықты. Бухгалтерлік есеп жүйелерінде деректер қазіргі уақытта өзекті болып табылады. Содан кейін пайдаланушы операцияның қандай да бір түрін орындайды - және деректер жаңартылады. Сонымен қатар, өзгерістер тарихы сақталмауы мүмкін - бұл бухгалтерлік есеп тәжірибесіне байланысты. Мысалы, банк шотындағы теңгерімді алайық. Бізді «қазір», күннің соңында немесе қандай да бір оқиға кезінде (мысалы, ұпайды есептеу кезінде) ағымдағы теңгерім қызықтыруы мүмкін. Алғашқы екеуін шешу оңай болғанымен, соңғысы ерекше күш-жігерді қажет етеді. Жадпен жұмыс істейтін пайдаланушы өткен кезеңдерге сілтеме жасай алады, оларды ағымдағы кезеңмен салыстыра алады және т.б. Дәл осы уақытқа байланысты мүмкіндіктер деректер қоймаларын есеп жүйесінен айтарлықтай ажыратады - уақыт осінің әртүрлі нүктелеріндегі деректердің күйін бұрынғы белгілі бір тереңдікке дейін алу.

Үшіншіден, солай шоғырландыру және деректерді унификациялау ... Олардың бірлескен талдауы мүмкін болуы үшін оларды ортақ формаға келтіру керек - деректердің бірыңғай моделі , фактілерді бірыңғай анықтамалықтармен салыстыру. Мұнда бірнеше аспектілер мен қиындықтар болуы мүмкін. Ең алдымен - тұжырымдамалық - бір термин бойынша әр бөлімдегі әр түрлі адамдар әртүрлі нәрсені түсінеді. Және керісінше - мәні бойынша бір нәрсені басқаша атау. Белгілі бір пайдаланушы тобының нақты көзқарасын сақтай отырып, «бір көзқарасты» қалай қамтамасыз етуге болады?

Төртіншіден, бұл жұмыс деректер сапасы ... Деректерді қоймаға жүктеу процесінде олар тазартылады, жалпы түрлендірулер мен түрлендірулер орындалады. Жалпы түрлендірулер бір жерде жасалуы керек - содан кейін әртүрлі есептерді құру үшін пайдаланылады. Бұл бизнес пайдаланушыларды, әсіресе бір-бірімен келіспейтін әртүрлі бөлімдердің нөмірлерімен үстелге әкелінетін басшыларды тітіркендіретін сәйкессіздіктерді болдырмайды. Деректер сапасының нашарлығы есептердегі қателер мен сәйкессіздіктерді тудырады, оның салдары деңгейдің төмендеуі болып табылады пайдаланушы сенімі бүкіл жүйеге, тұтастай алғанда бүкіл аналитикалық қызметке.

Архитектуралық концепция

Диаграммада көрсетілгендей, тұжырымдамалық түрде келесі қабаттарды таңдаңыз. Деректерді сақтау аймағын (толтырылған тіктөртбұрышпен көрсетілген) және деректерді жүктеу бағдарламалық құралын (шартты түрде бірдей түсті көрсеткілермен көрсетілген) қамтитын үш негізгі қабат. Сондай-ақ көмекші – сервистік деңгей, дегенмен, ол өте маңызды байланыстырушы рөл атқарады – деректер жүктемесін басқару және сапаны бақылау.

Бастапқы деректер деңгейі – бастапқы деректер деңгейі (немесе сахналау , немесе операциялық қабат ) - бастапқы жүйелерден жүктеуге және бастапқы ақпаратты түрлендірусіз сақтауға арналған - түпнұсқа сапада және өзгерістердің толық тарихын қолдау.
Бұл қабаттың міндеті- репозиторийдің келесі қабаттарын абстракциялау физикалық құрылғыдеректер көздері, мәліметтерді жинау әдістері және дельта өзгерістерін бөлу әдістері.

Core Data Layer – негізгі жады - сақтауды жай «пакеттік интеграция платформасынан» немесе «үлкен деректер қоқысынан» ерекшелендіретін жүйенің орталық құрамдас бөлігі, өйткені оның негізгі рөлі деректерді консолидациялауәртүрлі көздерден, біркелкі құрылымдарға дейін қысқарту, кілттер. Дәл ядроға жүктеу кезінде негізгі жұмыс деректер сапасы мен жалпы түрлендірулермен орындалады, бұл өте күрделі болуы мүмкін.
Бұл қабаттың міндеті- өз тұтынушыларын деректер көздерінің логикалық құрылғысының ерекшеліктерінен және әртүрлі жүйелердің мәліметтерін салыстыру қажеттілігінен абстракциялау, деректердің тұтастығы мен сапасын қамтамасыз ету.

Data Mart Layer – аналитикалық витриналар - негізгі функциясы деректерді талдауға ыңғайлы құрылымдарға түрлендіру болып табылатын құрамдас бөлік (егер BI витриналармен жұмыс істесе, бұл, әдетте, өлшемді модель) немесе тұтынушы жүйесінің талаптарына сәйкес.
Әдетте, деректер марттары деректерді ядродан алады - сенімді және тексерілген көз ретінде - яғни. деректерді бір пішінге келтіру үшін осы құрамдастың қызметін пайдаланыңыз. Біз мұндай көрмелерді шақырамыз тұрақты ... Кейбір жағдайларда, дүкен сөрелері бастапқы деректермен (бастапқы кілттерде) жұмыс істейтін кезеңнен тікелей деректерді ала алады. Бұл тәсіл әдетте әртүрлі жүйелерден деректерді біріктіру талап етілмейтін және деректер сапасынан гөрі тиімділік қажет болатын жергілікті тапсырмалар үшін қолданылады. Мұндай дисплей жағдайлары деп аталады жұмыс істейді ... Кейбір аналитикалық көрсеткіштер өте күрделі есептеу әдістеріне ие болуы мүмкін. Сондықтан мұндай тривиальды емес есептеулер мен түрлендірулер үшін деп аталатын қосалқы дисплей жағдайлары .
Қабат тапсырмасын көрсету- нақты тұтынушының – BI платформасының, пайдаланушылар тобының немесе сыртқы жүйенің талаптарына сәйкес деректерді дайындау.

Жоғарыда сипатталған қабаттар тұрақты деректерді сақтау аймағынан, сондай-ақ деректерді жүктеуге және түрлендіруге арналған бағдарламалық модульден тұрады. Бұл қабаттар мен аймақтарға бөлу қисынды. Физикалық тұрғыдан алғанда, бұл құрамдастардың орындалуы әртүрлі болуы мүмкін - егер бұл тиімдірек болса, әртүрлі қабаттарда деректерді сақтау немесе түрлендіру үшін әртүрлі платформаларды пайдалануға болады.
Сақтау аймақтарында деректерді түрлендіру процесінде қолданылатын техникалық (буферлік кестелер) және мақсатты кестелертұтынушы құрамдас бөлікке сілтеме жасайтын. Мақсатты кестелерді көріністермен «жабу» жақсы тәжірибе. Бұл жүйенің кейінгі қызмет көрсетуі мен дамуын жеңілдетеді. Барлық үш қабаттың мақсатты кестелеріндегі деректер арнайы техникалық өрістермен (мета-атрибуттармен) белгіленген, олар деректерді жүктеу процестерін қолдау үшін, сонымен қатар қоймадағы деректер ағындарының ақпараттық аудитін қамтамасыз ету үшін қолданылады.

Сондай-ақ, барлық қабаттар үшін қызмет көрсету функцияларын қамтамасыз ететін арнайы компонент (немесе компоненттер жиынтығы) ерекшеленеді. Оның негізгі міндеттерінің бірі басқару функциясы болып табылады - жоғарыда сипатталған қабаттардың әрқайсысын іске асырудың әртүрлі нұсқаларын пайдалану құқығын қалдырып, тұтастай алғанда бүкіл жүйе үшін «ойынның біркелкі ережелерін» қамтамасыз ету. деректерді жүктеу және өңдеу үшін әртүрлі технологияларды, әртүрлі сақтау платформаларын және т.б. Оны шақырайық қызмет көрсету деңгейі ... Ол бизнес деректерін қамтымайды, бірақ оның өзіндік сақтау құрылымдары бар – оның құрамында метадеректер аймағы, сондай-ақ деректер сапасымен жұмыс істеу аймағы (және оған тағайындалған функцияларға байланысты басқа құрылымдар болуы мүмкін).

Жүйені жеке құрамдас бөліктерге мұндай нақты бөлу жүйенің дамуын басқару мүмкіндігін айтарлықтай арттырады:

• сол немесе басқа компоненттің функционалдығын әзірлеушіге қойылатын тапсырманың күрделілігі төмендейді (ол бір уақытта сыртқы жүйелермен интеграция мәселелерін шешпеуі керек, сонымен қатар деректерді тазарту процедуралары туралы ойлануы керек және деректерді оңтайлы ұсыну туралы ойлануы керек); тұтынушылар үшін) - тапсырманы бөлшектеу, бағалау және шағын жеткізуді орындау оңайырақ;
• Сіз әртүрлі орындаушылардың (тіпті командалардың немесе мердігерлердің) жұмысына қосыла аласыз - өйткені бұл тәсіл бір-біріне өзара ықпалын азайта отырып, тапсырмаларды тиімді параллельдеуге мүмкіндік береді;
• тұрақты кезеңнің болуы бүкіл тақырып аймағы үшін бүкіл өзегін немесе дүкен сөрелерін жобаламай-ақ деректер көздерін жылдам қосуға мүмкіндік береді, содан кейін басымдықтарға сәйкес қалған қабаттарды құруды біртіндеп аяқтауға мүмкіндік береді (сонымен қатар, деректер қазірдің өзінде сақтауда болады - қол жетімді жүйелік талдаушылар, бұл сақтауды кейінгі дамыту міндеттерін айтарлықтай жеңілдетеді);
• ядроның болуы деректер сапасымен барлық жұмыстарды (сонымен қатар мүмкін болатын қателер мен қателерді) дүкен сөрелерінен және соңғы пайдаланушыдан жасыруға мүмкіндік береді, ең бастысы – бұл компонентті дүкен сөрелері үшін бір деректер көзі ретінде пайдалану арқылы деректерден аулақ бола аласыз. ортақ алгоритмдерді бір жерде орындауға байланысты конвергенция есептері;
• Марттарды бөлектеу әртүрлі бөлімдердің пайдаланушыларында болуы мүмкін деректерді түсінудің айырмашылықтары мен ерекшеліктерін ескеруге мүмкіндік береді және олардың BI талаптарына арналған дизайны жинақталған сандарды шығаруға ғана емес, сонымен қатар егжей-тегжейлі мүмкіндіктер беру арқылы деректерді тексеруді қамтамасыз етуге мүмкіндік береді. бастапқы көрсеткіштерге;
• қызмет көрсету деңгейінің болуы деректерді түпкілікті талдауды (деректер линиясы) орындауға, деректер аудитінің бірыңғай құралдарын пайдалануға, өзгерістердің дельтасын бөлектеуге жалпы тәсілдерге, деректер сапасымен жұмыс істеуге, жүктемені басқаруға, бақылау және қателерді диагностикалауға мүмкіндік береді. , және мәселені шешуді жылдамдатады.

• бастапқы жүйелер тарапынан өзгерістер сахналау кезінде өңделеді - ядрода осы кезеңдік кестелер әсер ететін ағындар ғана өзгертіледі, дүкен сөрелеріне әсері аз немесе жоқ;
• тұтынушылар тарапынан талаптардың өзгеруі көбінесе дүкен сөрелерінен өңделеді (егер бұл дүкенде әлі жоқ қосымша ақпаратты қажет етпесе).

Жүйе өзегі

Бұл компоненттің болуы бастапқы жүйелерден алынған бастапқы деректерді белгілі бір бірыңғай пішімге түрлендіретін деректер ағындарын қайта пайдалануға мүмкіндік береді: жалпы ережелерресурстарды тиімсіз пайдаланудан басқа деректердің сәйкессіздігіне әкелуі мүмкін әрбір қолданбалар қоймасы үшін бірдей функционалдылықты жүзеге асыруды жеке қайталаудың орнына және алгоритмдер.
Репозиторийдің өзегі деректер үлгісінде жүзеге асырылады, жалпы жағдайда бастапқы жүйелердің үлгілерінен де, тұтынушылардың форматтары мен құрылымдарынан да ерекшеленеді.

Қойма негізгі үлгісі және кәсіпорын деректер үлгісі

Миф 1. Кәсіпорын деректерінің үлгісі мыңдаған нысандардан (кестелерден) тұратын үлкен үлгі болып табылады.
Шын мәнінде. Кез келген пәндік салада, кез келген бизнес доменінде, кез келген компанияның деректерінде, тіпті ең күрделі, базалық субъектілер аз - 20-30.

Миф 2. Ешқандай «меншікті үлгіні» әзірлеудің қажеті жоқ - біз салалық анықтамалық үлгіні сатып аламыз - және біз бәрін соған сәйкес жасаймыз. Біз ақша жұмсаймыз - бірақ біз кепілдендірілген нәтиже аламыз.
Шын мәнінде. Анықтамалық үлгілер өте пайдалы болуы мүмкін, себебі осы саланы модельдеудегі салалық тәжірибені қамтиды. Олардан сіз идеяларды, тәсілдер, ат қою тәжірибесін алуға болады. Маңызды нәрсені назардан тыс қалдырмау үшін аймақтың «жабу тереңдігін» тексеріңіз. Бірақ біз мұндай модельді қораптан тыс пайдалана алатынымыз екіталай - дәл солай. Бұл, мысалы, ERP жүйесін (немесе CRM) сатып алу және оны «өзіңе қатайтпай» жүзеге асыру сияқты миф. Мұндай модельдердің құндылығы олардың осы нақты бизнестің, нақты компанияның шынайылығына бейімделуінде туады.

Миф 3. Негізгі репозиторий үлгісін әзірлеу бірнеше айға созылуы мүмкін, осы уақыт ішінде жоба іс жүзінде тоқтатылады. Бұған қоса, бұл ақылсыз кездесулер мен көптеген адамдарды қажет етеді.
Шын мәнінде. Репозиторий үлгісін репозиториймен бірге итеративті түрде, бөлшектеп әзірлеуге болады. Ашық аумақтар үшін «кеңейту нүктелері» немесе «түтіктер» орнатылады. кейбір «әмбебап конструкциялар» қолданылады. Сонымен қатар, сіз 4 кестеден тұратын суперәмбебап нәрсені алмас үшін қашан тоқтату керектігін білуіңіз керек, оған «деректерді қою» да, оны алу да қиын (одан да қиын). Және бұл өнімділік тұрғысынан өте оңтайлы емес.

Модельді әзірлеуге шынымен уақыт қажет. Бірақ бұл «субъектілерді сызу» үшін жұмсалған уақыт емес - бұл деректердің қалай орналасатынын түсіну, пәндік аймақты талдау үшін қажет уақыт. Сондықтан да бұл процеске сарапшылар өте тығыз араласып, түрлі бизнес мамандары да тартылады. Және бұл нүктелік, таңдамалы түрде жасалады. Ал ессіз адамдардың қатысуымен жиналыстар ұйымдастыру, үлкен сауалнамалар жіберу және т.б. арқылы емес.
Жақсы бизнес және жүйелік талдау негізгі қойма үлгісін құрудың кілті болып табылады. Түсінетін нәрсе көп: деректер қай жерде (қандай жүйелерде) жасалады, ол қалай жұмыс істейді, қандай бизнес-процестерде айналады және т.б. Сапалық талдау ешқашан бір жүйеге зиян келтірген емес. Керісінше, біздің түсінігіміздегі «ақ дақтардан» проблемалар туындайды.

Деректер моделін әзірлеу жаңа нәрсені ойлап табу және ойлап табу процесі емес. Іс жүзінде деректер моделі компанияда бұрыннан бар. Ал жобалау процесі «қазбаға» көбірек ұқсайды. Модель корпоративтік деректердің «топырағынан» мұқият және мұқият алынып, құрылымдық пішінге қойылады.

Миф 4. Біздің компанияда біздің бизнесіміз соншалықты серпінді, және бәрі соншалықты тез өзгереді, сондықтан модель жасау бізге пайдасыз - жүйенің осы бөлігін іске қосқанға дейін ол ескіреді.
Шын мәнінде. Еске салайық, негізгі фактор тұрақтылық болып табылады. Ең бастысы, модельдің топологиясы. Неліктен? Өйткені дәл осы құрамдас орталық болып табылады және қалғанның бәріне әсер етеді. Тұрақтылық сонымен қатар ядро ​​моделіне қойылатын талап болып табылады. Модель тым тез ескірсе, ол дұрыс құрастырылмаған. Оны дамыту үшін қате тәсілдер мен «ойын ережелері» таңдалды. Және бұл да сапалы талдау мәселесі. Корпоративтік модельдің негізгі субъектілері сирек өзгереді.
Бірақ егер біздің ойымызға кондитерлік өнімдерді сататын компания үшін «Өнім» анықтамалығының орнына «Тәттілер», «Торттар» және «Бәліштер» дайындаңыз. Содан кейін тауарлар тізімінде пицца пайда болған кезде - иә, сізге көптеген жаңа кестелерді енгізу қажет болады. Және бұл тек көзқарас мәселесі.

Миф 5. Корпоративтік үлгіні құру – өте күрделі, күрделі және жауапты іс. Ал қателесу қорқынышты.
Шын мәнінде. Негізгі модель, ол тұрақты болуы керек болса да, әлі де «металлға құйылған» емес. Кез келген басқа дизайн шешімдері сияқты, оның құрылымын қайта қарауға және өзгертуге болады. Оның бұл қасиетін ұмытпау керек. Бірақ бұл «сен онымен дем ала алмайсың» дегенді білдірмейді. Және бұл қайта өңдеуге жоспарланған уақытша шешімдер мен «түтіктер» қолайсыз дегенді білдірмейді.

Миф 6. Егер біздің деректер көзіміз, мысалы, анықтамалық деректер жүйесі (немесе деректерді басқарудың негізгі жүйесі - MDM) болса, онда ол корпоративтік үлгіге ыңғайлы түрде сәйкес болуы керек (әсіресе егер ол жақында жобаланған болса және оны жасауға уақыт болмаса) сатып алу «жақ», «дәстүрлер» Және уақытша саятшылықтар). Бұл жағдайда бізге ядро ​​моделі қажет емес екен?
Шын мәнінде. Иә, бұл жағдайда репозиторийдің негізгі моделін құру айтарлықтай жеңілдетілді - бері біз дайын жоғары деңгейлі концептуалды үлгіні ұстанамыз. Бірақ бұл мүлдем жоққа шығарылмайды. Неліктен? Өйткені белгілі бір жүйенің моделін құру кезінде оның кейбір өзіндік ережелері қолданылады - кестелердің қандай түрлерін пайдалану керек (әр нысан үшін), деректерді қалай нұсқалау керек, тарихты қандай түйіршіктілікпен сақтау керек, қандай мета-атрибуттар (техникалық өрістер) пайдалану) т.б.

Сонымен қатар, бізде анықтамалық деректер мен МДМ қаншалықты тамаша және жан-жақты жүйесі болса да, әдетте, басқа есеп жүйелерінде «шамамен бірдей» жергілікті анықтамалықтардың болуымен байланысты нюанстар болады. Ал бұл мәселе, біз қаласақ та, қаламасақ та, репозиторийде шешілуі керек - бұл жерде есептер мен талдаулар жиналады.

Негізгі деректер деңгейі (немесе тарихи кезең немесе операциялық деңгей)

Бұл қабаттағы деректер бастапқы жүйеге мүмкіндігінше жақын құрылымдарда сақталады - бастапқы деректерді мүмкіндігінше бастапқы пішініне жақын сақтау үшін. Бұл компоненттің тағы бір атауы «операциялық деңгей».
Неліктен «сахналау» деген жақсы қалыптасқан терминді қолданбасқа? Өйткені, бұрын, «үлкен деректер және VLDB дәуіріне» дейін дискілік кеңістік өте қымбат болды - және көбінесе бастапқы деректер, егер сақталған болса, шектеулі уақыт кезеңі үшін ғана болды. Және көбінесе «сценировка» атауын атайды тазалауға боладыбуфер.
Қазір технологиялар алға жылжыды - және біз барлық бастапқы деректерді сақтап қана қоймай, оларды мүмкін болатын түйіршіктілік дәрежесімен тарихтауға мүмкіндік аламыз. Бұл деректердің өсуін бақыламау керек дегенді білдірмейді және пайдалану «температурасына» байланысты деректерді сақтау құнын оңтайландыру, ақпараттың өмірлік циклін басқару қажеттілігін жоймайды - т. арзанырақ медиа және сақтау платформаларына сұраныс аз болатын «суық деректерді» алу.

«Тарихи қойылымның» болуы бізге не береді:

• қателер жасау мүмкіндігі (құрылымдарда, түрлендіру алгоритмдерінде, тарихтың түйіршіктілігінде) - сақтауға арналған қолжетімділік аймағында бастапқы деректерді толығымен тарихтандырғаннан кейін біз әрқашан кестелерімізді қайта жүктей аламыз;
• ойлау мүмкіндігі - біз сақтауды дамытудың осы нақты итерациясында ядроның үлкен фрагментін әзірлеуге уақыт бөле аламыз, өйткені біздің қойылымымызда кез келген жағдайда болады және біркелкі уақыт көкжиегі бар («тарих анықтамасының» бір нүктесі болады);
• талдау мүмкіндігі - біз тіпті бастапқыда жоқ деректерді де сақтаймыз - олар сол жерде қайта жазылуы мүмкін, мұрағатқа барады және т.б. - бізде олар талдау үшін қолжетімді болып қалады;
• ақпараттық аудит мүмкіндігі - ең егжей-тегжейлі бастапқы ақпараттың арқасында біз жүктеп алудың біз үшін қалай жұмыс істегенін, ақырында мұндай сандарға қол жеткізгенін анықтай аламыз (ол үшін бізде мета-атрибуттармен таңбалау керек және сәйкес жүктеу жұмыс істейтін метадеректер - бұл қызмет деңгейімен шешіледі).

• бұл қабаттың транзакциялық тұтастығына талаптар қою ыңғайлы болар еді, бірақ тәжірибе көрсеткендей, бұған қол жеткізу қиын (бұл бұл салада біз ата-аналық және еншілес кестелердің анықтамалық тұтастығына кепілдік бермейтінімізді білдіреді) - тұтастықты теңестіру келесіде орын алады қабаттар;
• бұл қабат өте үлкен көлемдерді қамтиды (сақтаудағы ең көлемді - аналитикалық құрылымдардың барлық артықтығына қарамастан) - және сіз мұндай көлемдерді - жүктеме тұрғысынан да, сұраныстар бойынша да өңдей білуіңіз керек (әйтпесе, сіз байыпты түрде жасай аласыз). бүкіл жадтың өнімділігін нашарлатады).

Екіншіден, бұл процестер, көріп отырғаныңыздай, өте қарапайым - логика тұрғысынан тривиальды деп айтуға болады. Бұл олардың өте жақсы оңтайландырылған және параметрленген болуы мүмкін екенін білдіреді, бұл біздің жүйеге жүктемені азайтады және көздерді қосу процесін жылдамдатады (әзірлеу уақыты).
Бұл үшін сіз осы компонент жұмыс істейтін платформаның технологиялық ерекшеліктерінің ерекшеліктерін өте жақсы білуіңіз керек - содан кейін сіз өте тиімді құрал жасай аласыз.

Көрсеткіш қабаты

Егер тұтынушы сыртқы жүйе болса, әдетте ол өзіне қажет деректер құрылымдарын және ақпаратты жинау ережелерін белгілейді. Жақсы тәсіл - бұл тұтынушы деректерді дұрыс жинауға жауапты. Деректер қоймасы дайындалды, көрмені құрады, қосымша деректерді жинау мүмкіндігін қамтамасыз етті (өзгерістердің дельтасын кейіннен бөлектеу үшін мета-атрибуттармен белгілеу), содан кейін тұтынушы жүйесі осы көрмені қалай пайдаланатынын бақылайды және оған жауап береді. Бірақ ерекшеліктер бар: жүйеде деректерді жинауға арналған белсенді компонент болмаған кезде - интеграциялау функциясын орындайтын сыртқы компонент қажет, немесе сақтау орны "интеграциялау платформасы" ретінде әрекет етеді - және дұрыс қосымша мәліметтерді қамтамасыз етеді. әрі қарай жүктеп салу – жадтан тыс. Мұнда көптеген нюанстар пайда болады және интерфейстің өзара әрекеттесу ережелерін екі тарап ойластырып, түсінуі керек (бірақ, интеграцияға келгенде, әдеттегідей). Әдетте, мұндай деректер қоймаларына әдеттегі деректерді тазалау/мұрағаттау қолданылады (бұл «транзиттік деректердің» ұзақ уақыт сақталуы сирек қажет).

Аналитикалық тапсырмалар тұрғысынан ең маңыздысы «адамдарға арналған» витриналар, дәлірек айтқанда, олар жұмыс істейтін BI құралдары үшін.
Дегенмен, сыртқы мамандандырылған жүйелерді толтыру үшін BI құралдарын немесе реттеу процестерін қажет етпейтін «ерекше озық пайдаланушылар» санаты бар - талдаушылар, деректерді зерттеушілер. Оларға өз қалауы бойынша кестелер мен түрлендірулер жасай алатын қандай да бір «жалпы дүкендер» және «өз құмсалғыштары» қажет. Бұл жағдайда репозиторийдің жауапкершілігі осы жалпы дүкен сөрелерінің ережелерге сәйкес деректермен толтырылуын қамтамасыз ету болып табылады.
Біз Data Mining құралдары - деректерді терең талдау сияқты тұтынушыларды бөлек атап өтуге болады. Бұл құралдардың деректерді дайындаудың өзіндік талаптары бар және деректер ғалымдары да олармен жұмыс істейді. Сақтау үшін тапсырма - келісілген пішімдегі кейбір дүкен сөрелерін жүктеу қызметін қолдау үшін қайтадан келеді.

Дегенмен, аналитикалық витриналарға оралу. Бұл деректер қабатындағы сақтау дизайнерлері тұрғысынан қызығушылық тудыратындар.
Менің ойымша, қазір барлық дерлік BI платформалары «ұшталған» деректер марттарын жобалаудың ең жақсы уақытпен тексерілген тәсілі - бұл Ральф Кимбаллдың тәсілі. ретінде белгілі өлшемді модельдеу - көпөлшемді модельдеу. Бұл тақырып бойынша көптеген басылымдар бар. Мысалы, негізгі ережелерді басылымнан табуға болады. Және, әрине, көп өлшемді модельдеу гурусынан кеңес бере аласыз. Тағы бір пайдалы ресурс - Кимбалдың кеңестері
Дүкен сөрелерін құрудың көпөлшемді тәсілін «әдіс евангелистері» де, бағдарламалық қамтамасыз етудің жетекші жеткізушілері де жақсы сипаттап, әзірлегені сонша, бұл жерде оған егжей-тегжейлі тоқталудың мағынасы жоқ - бастапқы дереккөз әрқашан жақсырақ. .

Мен бір ғана екпін айтқым келеді. «Есеп беру және талдау» басқаша. «Ауыр есеп беру» бар - файлдар түрінде жасалған және ұсынылған жеткізу арналары арқылы пайдаланушыларға жеткізілетін алдын ала тапсырыс берілген есептер. Содан кейін бақылау тақталары бар - BI бақылау тақталары. Негізінде бұл веб-қосымшалар. Және бұл қолданбалардың жауап беру уақыты кез келген басқа веб-қосымшалармен бірдей. Бұл BI тақтасын жаңартудың қалыпты уақыты минуттар емес, секундтар екенін білдіреді. Шешімді жобалау кезінде мұны есте сақтау маңызды. Бұған қалай қол жеткізуге болады? Стандартты оңтайландыру әдісі: біз жауап беру уақыты неден тұратынын және біз не әсер ете алатынымызды қарастырамыз. Ең көп уақыт нені босқа өткізеді? Дерекқордың физикалық (дискілік) оқулары үшін, деректерді желі арқылы тасымалдау үшін. Бір сұраныста оқылатын және жіберілетін деректер көлемін қалай азайтуға болады? Жауап анық және қарапайым: деректерді біріктіру керек немесе сұрауға қатысатын нақты кестелердің үлкен кестелеріне сүзгіні қолдану керек және үлкен кестелерді біріктіруді болдыртпау керек (факті кестелерге сілтеме тек өлшемдер арқылы өтуі керек).

BI не үшін қажет? Бұл қалай ыңғайлы? Неліктен көпөлшемді модель тиімді?
BI пайдаланушыға арнайы сұраулар деп аталатындарды орындауға мүмкіндік береді. Бұл нені білдіреді? Бұл дегеніміз, біз нақты сұрауды алдын ала білмейміз, бірақ пайдаланушы қандай аспектілерде қандай көрсеткіштерді сұрай алатынын білеміз. Пайдаланушы сәйкес BI сүзгілерін таңдау арқылы мұндай сұрауды жасайды. Ал BI әзірлеушісі мен дүкен сөресі дизайнерінің міндеті - деректер сүзгіден өткізілетін немесе жинақталған, тым көп деректер сұралған жағдайды болдырмайтын және қолданба «ілулі тұрған» етіп қолданбаның логикасын қамтамасыз ету. Әдетте, олар жинақталған сандардан басталады, содан кейін егжей-тегжейлі деректерді тереңірек зерттейді, бірақ жол бойына қажетті сүзгілерді орнатыңыз.

Тек «дұрыс жұлдызды» құру және BI үшін ыңғайлы құрылымды алу әрқашан жеткіліксіз. Кейде бір жерде денормализацияны қолдану керек болады (бұл жүктемеге қалай әсер ететінін еске түсіру кезінде) және бір жерде қосалқы дүкендер мен агрегаттарды жасау үшін. Бір жерде индекстерді немесе проекцияларды қосыңыз (ДҚБЖ-ға байланысты).

Осылайша, «сынау және қателік» арқылы сіз BI үшін оңтайлы құрылымды ала аласыз - ол ДҚБЖ және BI платформасының ерекшеліктерін, сондай-ақ пайдаланушының деректерді ұсыну талаптарын ескереді.
Егер біз деректерді «өзегінен» алсақ, онда дүкен сөрелерін мұндай өңдеу бастапқы жүйелерден тікелей алынған бастапқы деректерді кешенді өңдеуге ешқандай әсер етпей, жергілікті сипатта болады - біз деректерді тек «ауыстырамыз». BI үшін ыңғайлы пішім. Ал біз мұны бірнеше рет жасауға шамамыз жетеді әртүрлі жолдар, әртүрлі талаптарға сәйкес. Мұны «бастапқыдан» (құрылымы мен ережелері, біз білетіндей, «қалқымалы» да болуы мүмкін) жинауға қарағанда, ядро ​​деректерінде жасау әлдеқайда оңай және жылдамырақ.

Қызмет көрсету деңгейі

Бұл қабат екі деректерді сақтау аймағын қамтиды:

• метадеректер аймағы – деректерді жүктеуді басқару механизмі үшін пайдаланылады;
• деректер сапасы аймағы - деректер сапасын желіден тыс тексерулерді жүзеге асыру үшін (яғни, ETL процестеріне тікелей кірмейтіндер).

Жүктемені басқарудағы маңызды сәт қателерді өңдеудің дәйекті тәсілін әзірлеу болып табылады. Қателер олардың ауырлық деңгейіне қарай жіктеледі. Критикалық қате орын алған кезде, процесс тоқтауы керек және мүмкіндігінше тезірек, өйткені оның пайда болуы жадтағы деректердің бұзылуына әкелетін маңызды мәселені көрсетеді. Осылайша, жүктемені басқару процестерді бастау ғана емес, сонымен қатар оларды тоқтату, сондай-ақ уақтылы (қате) іске қосылудың алдын алу болып табылады.

Қызметтік деңгейдің жұмыс істеуі үшін арнайы метадеректер құрылымы жасалады. Бұл аймақта жүктеу процестері, жүктелген деректер жинақтары, қадамды сақтау үшін пайдаланылатын бақылау нүктелері (қай процесс қай нүктеге дейін оқылды) және жүйенің жұмыс істеуі үшін қажетті басқа да қызмет ақпараты туралы ақпаратты сақтайды.
Барлық қабаттардағы барлық мақсатты кестелер мета-өрістердің арнайы жиынтығымен белгіленгенін атап өту маңызды, олардың бірі осы жолды жаңартқан процестің идентификаторы болып табылады. Репозиторийдегі кестелер үшін бұл процесті белгілеу кейіннен өзгерістердің дельтасын бөлектеудің дәйекті жолына мүмкіндік береді. Деректерді бастапқы деректер деңгейіне жүктегенде, жағдай күрделене түседі - әртүрлі жүктелген нысандар үшін дельтаны бөлу алгоритмі әртүрлі болуы мүмкін. Бірақ қабылданған өзгерістерді өңдеу логикасы және оларды негізгі және дүкен сөрелеріне арналған мақсатты кестелерге жылжыту сахнаға қарағанда әлдеқайда күрделі, мұнда бәрі өте тривиальды - қайта пайдалануға болатын стандартты қадамдарды (рәсімдер) параметрлеу және ойластыру оңай.

Мен мұнда осы тақырыпты толығымен қамту міндетін қойған жоқпын - жүктеп алуды ұйымдастыру - мен жай ғана назар аударуға тұрарлық екпіндерді бөлектеймін.
Бұл тәсіл нұсқалардың бірі ғана. Бұл өте жауапты. Ал оның «концептуалды прототипі» Toyota конвейері және дәл уақытында жұмыс істейтін жүйе болды. Анау. мұнда біз тек «түнгі деректерді жүктеу» кең таралған парадигмасынан алшақтап жатырмыз және біз күндізгі уақытта шағын бөліктерде жүктейміз - деректер әртүрлі көздерде дайын болған кезде: не келді - ол жүктелді. Сонымен қатар бізде көптеген параллель процестер жүріп жатыр. Ал жаңа деректердің «ыстық құйрығы» үнемі «жыпылықтайды» - тіпті уақыт өте келе. Біз мұндай ерекшелікті ескеруіміз керек. Қажет болса, барлығы біртұтас болып табылатын «кесектер» бар арнайы витриналарды жасаңыз. Анау. бір мезгілде тиімділікке де, жүйелілікке де (тұтастыққа) жету мүмкін емес. Бізге тепе-теңдік керек - бір жерде бір нәрсе маңызды, басқа жерде.

Ағаш кесу және бақылау құралдарын қамтамасыз ету міндетті болып табылады. Түрлі параметрлерді орнатуға және хабарландыру жүйесін теңшеуге болатын терілген оқиғаларды пайдалану жақсы тәжірибе - белгілі бір оқиғаларға жазылу. Өйткені Жүйе әкімшісінің араласуы қажет болған кезде ол бұл туралы мүмкіндігінше ерте біліп, барлық қажетті диагностикалық ақпаратты алуы өте маңызды. Журналдар сонымен қатар постфакто мәселелерді талдау үшін, сондай-ақ жүйе ақауларының оқиғаларын, соның ішінде. деректер сапасы.

Қойма деректерінің үлгілерін жобалау және жүргізу

Сіз оны үлгісіз анықтай аласыз ба? Негізінде, сіз аласыз. Оны анықтау және «қағаздағы суреттерді анықтау» және деректерді «сұрып алу - реттеу». Бірақ дайын артефакт – деректер үлгісін пайдалану әлдеқайда оңай, түсінікті және жылдамырақ. Және де «оның құрылғысының логикасын» түсініңіз - яғни. ойынның жалпы ережелері болса жақсы болар еді.

Ең бастысы, бұл тіпті емес. Ең бастысы, модельді жобалау кезінде біз (тек нұсқаларсыз!) Пәндік аймақты, деректер құрылғысының мүмкіндіктерін және оларды әртүрлі бизнес жағдайларда пайдалануды тереңірек және тереңірек зерттеуге мәжбүр боламыз. Ал біз оңай «жақсы итеріп жіберетін» сұрақтарды күрделі, «бұлыңғыр» деп өз белгілерімізді лақтыру арқылы дәл анықтауға тырыспай-ақ қоямыз. дизайнүлгі - біз есептерді құрастыру және «үйлесімсізді қалай азайту» және «дөңгелекті қайта ойлап табу» туралы ойлануды кейінірек емес, талдау және жобалау кезінде қазір жеткізуге және шешуге мәжбүр боламыз.

Бұл тәсіл сынғыш жүйелерді жасауға мүмкіндік беретін инженерлік тәжірибелердің бірі болып табылады. Олар анық реттелген, мөлдір, әзірлеуге ыңғайлы болғандықтан, сонымен қатар олардың «нәзіктік шегі» бірден көрінеді - жаңа талаптар пайда болған кезде «апат ауқымын» және қайта жобалауға қажетті уақытты (қажет болса) дәлірек бағалауға болады.
Осылайша, деректер моделі жүйені әзірлеу кезінде сақталуы керек негізгі артефакттардың бірі болып табылады. Ынтымақтастықта ол әрбір аналитиктің, әзірлеушінің және т.б. «үстелінде» болуы керек. - жүйені дамыту жобаларына қатысатын әрбір адам.

Деректер үлгілерін жобалау - бұл үлкен және бөлек тақырып. Сақтауды жобалаудың екі негізгі тәсілі бар.
Тәсіл ядро ​​үшін жақсы жұмыс істейді Субъект-қатынас - пәндік облысты, дәлірек айтқанда оның таңдалған аймағын зерттеу негізінде нормаланған (3NF) модель салынғанда. Жоғарыда талқыланған «корпоративтік модель» осы жерде ойнайды.

Витриналарды жобалау кезінде ол қолайлы көпөлшемді модель ... Бұл тәсіл бизнес пайдаланушылардың түсінігіне жақсы сәйкес келеді - өйткені бұл қарапайым және адамның қабылдауына ыңғайлы модель - адамдар метриканың (көрсеткіштердің) және олар талданатын бөлімдердің түсінікті және таныс тұжырымдамаларымен жұмыс істейді. Және бұл талаптарды жинау процесін қарапайым және анық құруға мүмкіндік береді - біз әртүрлі бөлімдердің өкілдерімен байланыса отырып, «бөлімдер мен көрсеткіштер матрицаларының» жинағын саламыз. Содан кейін біз оны бір құрылымға – «талдау үлгісіне» келтіреміз: біз «өлшеу шинасын» қалыптастырамыз және оларда анықталған фактілерді анықтаймыз. Осы жолда біз иерархиялар мен біріктіру ережелерімен жұмыс істейміз.

Сонда бару өте оңай физикалық модельДҚБЖ ерекшеліктерін ескере отырып, оңтайландыру элементтерін қосу арқылы. Мысалы, Oracle үшін бұл бөлу, индекстер жинағы және т.б. Vertica үшін басқа әдістер қолданылады - сұрыптау, сегменттеу, секциялау.
Сондай-ақ, арнайы нормадан шығару талап етілуі мүмкін - біз деректерге әдейі резервтеуді енгізген кезде, соның арқасында біз сұрау өнімділігін жақсартамыз, бірақ сонымен бірге деректерді жаңартуды қиындатамыз (өйткені артықшылықты деректерді жүктеу кезінде ескеру және қолдау қажет болады) процесс). Мүмкін, өнімділікті жақсарту үшін бізге қосымша жиынтық кестелер жасауға немесе Vertica бағдарламасындағы проекциялар сияқты қосымша ДҚБЖ мүмкіндіктерін пайдалануға тура келуі мүмкін.

Сонымен, қойма деректерін модельдеу кезінде біз бірнеше мәселені шешеміз:

• ядроның концептуалды (логикалық) моделін құру міндеті – жүйелік және бизнес-талдау – пәндік аумақты зерттеу, егжей-тегжейлерге өту және «тірі деректердің» нюанстарын есепке алу және оларды бизнесте пайдалану;
• талдау үлгісін құру міндеті - содан кейін концептуалды (логикалық) дүкен сөресі үлгісі;
• физикалық модельдерді құру міндеті – деректердің артықтығын басқару, сұраулар мен деректерді жүктеу үшін ДҚБЖ ерекшеліктерін ескере отырып оңтайландыру.

Қорытындылайық.

• Деректер моделі жиынтық емес» әдемі суреттер”, Ал оны жобалау процесі оларды сызу процесі емес. Модель біздің домен туралы түсінігімізді көрсетеді. Ал оны құрастыру – оны зерттеу, зерттеу процесі. Бұл босқа кеткен уақыт. Және мүлде «сызу және бояу» емес.
• Деректер моделі – дизайн артефакті, команда мүшелері арасында құрылымдық түрде ақпарат алмасу тәсілі. Ол үшін ол барлығына түсінікті болуы керек (бұл белгілер мен түсініктемелер арқылы беріледі) және қолжетімді (жарияланған).
• Мәліметтер моделі бір рет құрылып, қатып қалмайды, жүйенің даму процесінде құрылады және дамиды. Оны дамытудың ережелерін өзіміз белгіледік. Және біз оларды қалай жақсырақ, оңайырақ, тиімдірек жасауға болатынын көрсек, өзгерте аламыз.
• Деректер моделі (физикалық) оңтайландыруға бағытталған озық тәжірибелер жиынтығын біріктіруге және пайдалануға мүмкіндік береді - яғни. осы ДҚБЖ үшін бұрыннан жұмыс істеген әдістерді пайдаланыңыз.

Мәліметтер қоймасы жобаларының ерекшеліктері

Деректер қоймасы – арнайы бағдарламалық құрал

Деректер қоймасы – интеграциялық жоба

Деректер қоймасы – бірлескен жоба

Архитектура оның тұтастығын сақтай отырып және әртүрлі жерлерде, әртүрлі адамдарда бір функцияның қайталануын болдырмай, олардың параллель жұмысын ұйымдастыру мүмкіндігін қамтамасыз етуі керек. Қажетсіз күш салудан басқа, мұндай қайталау кейінірек деректердің сәйкессіздігіне әкелуі мүмкін.

Сонымен қатар, жүйені әзірлеуге жиі шашыраңқы орналасқан көптеген адамдар мен командалар тартылған кезде, олардың арасындағы коммуникациялар мен ақпараттық өзара әрекеттесуді қалай құру керек деген сұрақ сөзсіз туындайды. Неғұрлым стандартты және түсінікті тәсілдер мен тәжірибелер қолданылса, мұндай жұмысты ұйымдастыру соғұрлым оңай, ыңғайлы және тиімді болады. Сонымен қатар, «жұмыс артефактілерінің» құрамы туралы ойлану керек, олардың арасында №1 деректер қоймалары үшін деректер үлгілері бар (алдыңғы бөлімді қараңыз).

Деректер қоймасының қызмет ету мерзімі басқа жүйелерге қарағанда ұзағырақ

Менде бұлай деп сенуге қандай негіздер бар?
Біріншіден, қойма салу - бұл өте ресурсты қажет ететін процесс: жабдықтың нақты шығындарынан, қажетті технологиялық бағдарламалық қамтамасыз ету мен әзірлеуге арналған лицензиялардан басқа, бұл компанияның барлық дерлік жүйелері мен бөлімшелерімен айналысады. Бұл процесті нөлден тағы бір рет қайталау - өте батыл идея.

Екіншіден, егер жад дұрыс архитектураға ие болса, онда ол бастапқы жүйелердің өзгеруіне және соңғы пайдаланушылардан жаңа талаптардың пайда болуына және деректер көлемінің өсуіне оңай төтеп бере алады.
Архитектура дұрыс болса, ақпарат ағындары мөлдір болса, онда мұндай жүйе әсерді бағалаудағы қиындықтарға байланысты өзгерістер енгізу кезінде жағдайға кептелу қаупінсіз ұзақ уақыт бойы жасалуы мүмкін.

Біртіндеп қайталанатын даму

Клиенттердің көз алдында деректер қоймасы жиі абсолютті құбыжық сияқты көрінеді - жүйенің міндеттері, мақсаттары және даму көкжиегі соншалықты көлемді. Көбінесе тапсырыс беруші «бюджет есебінен» IT бөлімі кейбір «өз мәселелерін» шешеді деп қорқады. Біз тағы да адамдар арасындағы өзара әрекеттесу және өз позициямызды байсалды түрде білдіру және келіссөздер жүргізу мүмкіндігі мәселесіне тап болдық.

Құзыретті архитектуралық тәсілдер нәтиже бере бастағанға дейін бірнеше жыл бойы «дамытуға» бармай, функционалдылықты біртіндеп арттыра отырып, жүйені итеративті түрде дамытуға мүмкіндік береді.

Айта кету керек, «ғажайыптар болмайды» - және «бастау» да уақытты қажет етеді. Сақтау орындары үшін ол айтарлықтай үлкен болуы мүмкін - бұл деректердің үлкен көлемі болғандықтан, бұл тарихи деректер - ақпаратты өңдеу ережелері қазіргіден өзгеше болуы мүмкін ескі кезеңдерге арналған. Сондықтан, аналитикалық жұмыс, бастапқы жүйелермен өзара әрекеттесу және бірқатар «сынау және қателер», соның ішінде жүктеме сынақтарынақты деректер бойынша.

Деректер қоймалары - «көп жобалық оқиға»

Инновациялар мен дәлелденген шешімдер балансы

ДҚБЖ-ны сақтаудың ең маңызды және маңызды технологиялық платформасы ретінде қарастырайық.
Жақында бастапқыда «әмбебап» ретінде құрылған реляциялық деректер қорының мамандандыруға қарай анық ауытқуы байқалды. Ұзақ уақыт бойы жетекші жеткізушілер әртүрлі класстардың (OLTP, DSS & DWH) қосымшалары үшін әртүрлі опцияларды шығаруда. Сонымен қатар, мәтінмен, геодеректермен және т.б. жұмыс істеу үшін қосымша мүмкіндіктер пайда болады.

Бірақ бұл мұның соңы емес - бастапқыда белгілі бір тапсырмалар класына бағытталған өнімдер пайда бола бастады, яғни. мамандандырылған ДҚБЖ. Олар реляциялық модельді пайдалана алады немесе қолданбауы мүмкін. Олардың бастапқыда жалпы «іскерлік ақпаратты» сақтау және өңдеу үшін ғана емес, нақты тапсырмалар үшін «ұшталғаны» маңызды.

Шамасы, орталықтандыру мен мамандандыру бір-бірін мезгіл-мезгіл алмастыратын, даму мен тепе-теңдікті қамтамасыз ететін бір-бірін толықтыратын екі тенденция болып табылады. Сондай-ақ эволюциялық (біртіндеп) бірте-бірте даму және түбегейлі өзгерістер. Мысалы, 90-шы жылдары Майкл Стоунбрейкер «Деректер қоры әлемінде әлемге тағы бір революция қажет емес» деген идеяны анық білдірген III ұрпақ деректер базасы манифестінің авторларының бірі болды. Алайда, 10 жылдан кейін ол жұмыстарды жариялайды, онда ол бастаудың алғышарттарын жариялайды. жаңа дәуірМҚБЖ әлемінде – олардың мамандануына негізделген.
Ол жалпыға ортақ әмбебап ДҚБЖ аппараттық платформалардағы өзгерістерді де, қосымшалардың қосымшасын ойлап табуға болатын сыныптарға бөлінуін де ескермейтін «бір өлшемді» архитектураға құрылғанына назар аударады. әмбебап талаптарды жүзеге асыруға қарағанда оңтайлы шешім.
Және осы ойына сай бірқатар жобаларды әзірлеуге кіріседі. Олардың бірі - C-Store - бұл бастапқыда деректер қоймалары класының жүйелері үшін арнайы жасалған, ортақ ештеңе (SN) архитектурасында жасалған бағаналы ДҚБЖ. Бұл өнім кейін HP Vertica ретінде сатылды.

Қазір деректер қоймасын дамыту тақырыбы дамудың жаңа кезеңіне сырғып кеткен сияқты. Жаңа технологиялар, тәсілдер мен құралдар пайда болады. Оларды зерттеу, тестілеу және интеллектуалды қолдану бізге шынымен қызықты және пайдалы шешімдерді жасауға мүмкіндік береді. Сіздің әзірлемелеріңіз пайдаланылғандығынан ләззат ала отырып, оларды іске асыруға әкеліңіз нақты жұмысжәне пайдалы.

Эпилог

Жалпы алғанда, сәулетші рөлін нақты кім орындайтыны маңызды емес - біреудің ұқсас сұрақтар қойып, жауаптарды зерттегені маңызды. Егер сәулетші нақты бөлектелсе, бұл оның жүйе мен оның дамуына ең алдымен жауапты екенін білдіреді.
Неліктен мен бұл тақырыпқа «қарсы сынғыштық» тақырыбын қатысты деп таптым?

«Антифрагильділіктің бірегейлігі ол бізге белгісізмен жұмыс істеуге, нақты не істеп жатқанымызды түсінбейтін жағдайда бірдеңе жасауға және табысқа жетуге мүмкіндік береді»./ Насим Н. Талб /

Өнеркәсіптік деректер үлгілері

Модельдердің негізгі мақсаты деректер кеңістігінде бағдарлауды жеңілдету және бизнесті дамыту үшін маңызды бөлшектерді бөлектеуге көмектесу болып табылады. Қазіргі жағдайда табысты бизнес үшін әртүрлі құрамдас бөліктер арасындағы байланыстарды нақты түсіну және ұйымның жалпы бейнесі туралы жақсы түсінік болуы өте маңызды. Модельдерді пайдалана отырып, барлық бөлшектер мен қатынастарды анықтау компания жұмысын ұйымдастыру үшін уақыт пен құралдарды барынша тиімді пайдалануға мүмкіндік береді.

Деректер үлгілері деректердің қалай ұсынылатынын және оларға қол жеткізуді сипаттайтын дерексіз үлгілер болып табылады. Деректер үлгілері деректер элементтерін және олардың арасындағы белгілі бір аймақтағы қатынастарды анықтайды. Деректер моделі нақты дүниедегі ақпараттың белгілі бір класын дәл түсіндіру үшін белгілі бір белгілер мен сөздер жинағын пайдаланатын бизнес пен АТ мамандарына арналған навигация құралы болып табылады. Бұл ұйым ішінде жақсырақ байланыс орнатуға мүмкіндік береді және осылайша икемді және тұрақты қолданба ортасын жасайды.

Деректер моделі деректердің мағынасын бірегей түрде анықтайды, бұл жағдайда құрылымдық деректер (мағынасы анық емес болуы мүмкін сурет, екілік файл немесе мәтін сияқты құрылымдалмаған деректерге қарағанда).

Әдетте, жоғары деңгейдегі (және мазмұны бойынша жалпы) және төменгі (тиісінше, егжей-тегжейлі) модельдер ерекшеленеді. Модельдеудің жоғарғы деңгейі деп аталады концептуалды деректер модельдері(концептуалды деректер үлгілері), олар кәсіпорынның немесе ұйымның жұмыс істеуінің ең жалпы көрінісін береді. Концептуалды модель ұйымның жұмыс істеуі үшін маңызды болып табылатын негізгі ұғымдарды немесе пәндік аймақтарды қамтиды; әдетте олардың саны 12-15-тен аспайды. Мұндай модель ұйым үшін маңызды субъектілердің сыныптарын (бизнес объектілерін), олардың сипаттамаларын (атрибуттарын) және осы сыныптардың жұптары арасындағы байланыстарды (яғни, қатынастар) сипаттайды. Бизнес-модельдеудегі терминология әлі түпкілікті реттелмегендіктен, әртүрлі ағылшын тіліндегі дереккөздерде концептуалды деректер үлгілерін пәндік аймақ моделі (домендік үлгілер ретінде аударуға болады) немесе субъектілік кәсіпорын деректер үлгісі (пәндік корпоративтік деректер үлгілері) деп те атауға болады. ).

Келесі иерархиялық деңгей логикалық деректер модельдері(логикалық деректер үлгілері). Оларды кәсіпорын деректер үлгілері немесе бизнес үлгілері деп те атауға болады. Бұл үлгілер деректер құрылымдарын, олардың атрибуттары мен бизнес ережелерін қамтиды және бизнес тұрғысынан кәсіпорын пайдаланатын ақпаратты көрсетеді. Мұндай модельде деректер субъектілер және олардың арасындағы қатынастар түрінде ұйымдастырылады. Логикалық модель деректерді іскери пайдаланушыларға түсінуді жеңілдететін етіп ұсынады. Логикалық модельде деректер сөздігін ажыратуға болады – олардың нақты анықтамалары бар барлық нысандардың тізімі, бұл пайдаланушылардың әртүрлі категорияларына модельдің барлық кіріс және ақпарат шығыс ағындары туралы ортақ түсінікке ие болуға мүмкіндік береді. Модельдеудің келесі, төменгі деңгейі нақты бағдарламалық және техникалық платформаларды пайдалана отырып, логикалық модельді физикалық іске асыру болып табылады.

Логикалық модель әдетте қалыпқа келтірілген үлгі түрін қабылдайтын егжей-тегжейлі корпоративтік бизнес шешімін қамтиды. Қалыпқа келтіру - үлгідегі әрбір деректер элементінің тек бір мәнге ие болуын және бастапқы кілтке толығымен және бірегей түрде тәуелді болуын қамтамасыз ететін процесс. Деректер элементтері бірегей сәйкестендіруге сәйкес топтарға ұйымдастырылған. Деректер элементтерін реттейтін бизнес ережелері алдын ала тексеру және тексеру арқылы қалыпқа келтірілген үлгіге толығымен енгізілуі керек. Мысалы, Тұтынушының аты сияқты деректер элементі Аты мен Тегіне бөлініп, Тұтынушыдағы басқа сәйкес деректер элементтерімен топтастырылуы мүмкін. бастапқы кілтКлиент идентификаторы.

Логикалық деректер моделі дерекқорлар, желілік технологиялар немесе есеп беру құралдары сияқты қолданбалы технологиялардан және оларды физикалық іске асыру құралдарынан тәуелсіз. Ұйымда тек бір ғана кәсіпорын деректер үлгісі болуы мүмкін. Логикалық үлгілер әдетте мыңдаған нысандарды, қатынастарды және атрибуттарды қамтиды. Мысалы, қаржы институтының немесе телекоммуникациялық компанияның деректер үлгісі шамамен 3000 салалық тұжырымдаманы қамтуы мүмкін.

Логикалық және семантикалық деректер моделін ажырата білу маңызды. Логикалық деректер үлгісі кәсіпорынның бизнес шешімін, ал семантикалық деректер үлгісі қолданбалы бизнес шешімін көрсетеді. Бірдей корпоративтік логикалық деректер моделі әртүрлі семантикалық модельдерді қолдану арқылы жүзеге асырылуы мүмкін, т.б. семантикалық модельдерді физикалық модельдерге жақындайтын модельдеудің келесі деңгейі ретінде қарастыруға болады. Сонымен қатар, осы үлгілердің әрқайсысы әртүрлі қолданбалардың талаптарына сәйкес корпоративтік деректер моделінің жеке «бөлігін» көрсететін болады. Мысалы, корпоративтік логикалық деректер үлгісінде Клиент нысаны толығымен қалыпқа келтіріледі, ал data mart үшін семантикалық үлгіде ол көп өлшемді құрылым ретінде ұсынылуы мүмкін.

Компанияда корпоративтік логикалық деректер моделін құрудың екі жолы болуы мүмкін: оны дербес құру немесе дайын үлгісін пайдалану. салалық үлгі(салалық логикалық деректер моделі). Бұл жағдайда терминдердегі айырмашылықтар бір логикалық модельді құрудың әртүрлі тәсілдерін ғана көрсетеді. Егер компания өзінің логикалық деректер моделін дербес әзірлеп, жүзеге асырса, онда мұндай модель, әдетте, жай корпоративтік логикалық модель деп аталады. Егер ұйым кәсіби жеткізушінің дайын өнімді пайдалануды шешсе, онда салалық логикалық деректер моделі туралы айтуға болады. Соңғысы жоғары дәлдікпен белгілі бір саланың қызметін көрсететін дайын логикалық деректер моделі болып табылады. Салалық логикалық модель – стратегиялық және тактикалық бизнес сұрақтарына жауап беру үшін кәсіпорын деректер қоймасында болуы керек барлық ақпараттың доменге тән және біріктірілген көрінісі. Кез келген логикалық деректер үлгісі сияқты салалық үлгі қолданбалы шешімдерге тәуелсіз. Сондай-ақ ол алынған деректерді немесе деректерді жылдамырақ шығарып алу үшін басқа есептеулерді қамтымайды. Әдетте, мұндай модельдің логикалық құрылымдарының көпшілігі оның тиімді физикалық орындалуында жақсы бейнеленген. Мұндай модельдерді көптеген жеткізушілер қызметтің кең спектрі үшін әзірлейді: қаржы, өндіріс, туризм, денсаулық сақтау, сақтандыру және т.б.

Салалық логикалық деректер үлгісі салаға ортақ ақпаратты қамтиды, сондықтан компания үшін кешенді шешім бола алмайды. Көптеген компаниялар деректер элементтерін қосу және анықтамаларды кеңейту арқылы үлгіні орта есеппен 25%-ға өсіруі керек. Қолданбалы үлгілер тек негізгі деректер элементтерін қамтиды, ал қалған элементтер модельді компанияда орнату кезінде сәйкес бизнес нысандарына қосылуы керек.

Салалық логикалық деректер үлгілері абстракцияның маңызды көлемін қамтиды. Абстракциялар Оқиға немесе Қатысушы сияқты жалпы атаулармен ұқсас ұғымдардың бірігуін білдіреді. Бұл салалық үлгілерге икемділік пен біркелкілік қосады. Осылайша, Оқиға тұжырымдамасы барлық салаларға қолданылады.

Іскерлік барлау маманы Стив Хоберман салалық деректер үлгісін алу-алмау туралы шешім қабылдағанда ескерілетін бес факторды анықтайды. Біріншісі - модельді құру үшін қажет уақыт пен ақша. Егер ұйым нәтижеге тез жету керек болса, онда салалық модель тиімді болады. Салалық үлгіні пайдалану бүкіл ұйымның суретін бірден қамтамасыз етпеуі мүмкін, бірақ ол уақытты айтарлықтай үнемдеуі мүмкін. Өзін модельдеудің орнына, уақыт бұрыннан бар құрылымдарды салалық үлгімен байланыстыруға және оны ұйымның қажеттіліктеріне қалай жақсырақ теңшеуге болатынын талқылауға жұмсалады (мысалы, қандай анықтамаларды өзгерту керек және қандай деректер элементтерін қосу керек).

Екінші фактор - модельді жақсы жұмыс тәртібінде ұстау үшін қажет уақыт пен ақша. Егер кәсіпорын деректерінің моделі оның дәлдігі мен заманауи стандарттарға сәйкестігін бақылауға мүмкіндік беретін әдістеменің бөлігі болмаса, онда мұндай модель өте тез ескіреді. Өнеркәсіптік деректер үлгісі сыртқы ресурстармен жаңартылғандықтан, бұл тәуекелдің орын алуын болдырмайды. Әрине, ұйым ішінде болып жатқан өзгерістер модельде компанияның өзі көрсетуі керек, бірақ салалық өзгерістерді үлгіде оның жеткізушісі қайта шығарады.

Үшінші фактор – тәуекелді бағалау және модельдеу тәжірибесі. Корпоративтік деректер үлгісін жасау бизнестен де, АТ қызметкерлерінен де білікті ресурстарды талап етеді. Әдетте, менеджерлер жалпы ұйымның жұмысын немесе белгілі бір бөлімнің қызметін жақсы біледі. Олардың кейбіреулері өз бизнесі бойынша кең (компания бойынша) және терең (бөлімшелер ішінде) білімге ие. Көптеген менеджерлер әдетте бір саланы жақсы біледі. Сондықтан жалпы корпоративтік көріністі алу үшін айтарлықтай бизнес ресурстары қажет. Бұл да IT қызметкерлеріне қойылатын талаптарды арттырады. Үлгіні жасау және сынау үшін неғұрлым көп бизнес ресурстары қажет болса, аналитиктер соғұрлым тәжірибелі болуы керек. Олар бизнес қызметкерлерінен ақпарат алуды біліп қана қоймай, сонымен қатар даулы салаларда ортақ көзқарасты таба білуі және осы ақпаратты кешенді түрде көрсете білуі керек. Модельді жасайтын адам (көп жағдайда бір аналитик) жақсы модельдеу дағдыларына ие болуы керек. Кәсіпорынның логикалық үлгілерін құру «болашақ үшін» модельдеуді және күрделі бизнесті «шаршы және сызықтарға» сөзбе-сөз түрлендіру мүмкіндігін талап етеді.

Екінші жағынан, салалық модель сыртқы сараптамаға мүмкіндік береді. Салаға тән логикалық модельдер ұйымдағы кәсіпорын деректер үлгілерін әзірлеу кезінде туындауы мүмкін жалпы және қымбат мәселелерді болдырмау үшін дәлелденген модельдеу әдістемелері мен тәжірибелі мамандар топтары арқылы құрастырылады.

Төртінші фактор - қолданыстағы қолданбалы инфрақұрылым және жеткізушілер арасындағы қарым-қатынас. Егер ұйым бір жеткізушінің көптеген құралдарын пайдаланса және онымен қарым-қатынас орнатқан болса, онда оған тапсырыс берудің мағынасы және салалық үлгісі бар. Бұл модель бір жеткізушінің басқа өнімдерімен еркін жұмыс істей алады.

Бесінші фактор – салаішілік ақпарат алмасу. Егер компания бір салада жұмыс істейтін басқа ұйымдармен байланысуы қажет болса, онда салалық модель бұл жағдайда өте пайдалы болуы мүмкін. Бір саладағы ұйымдар ұқсас құрылымдық компоненттер мен терминологияны пайдаланады. Қазіргі уақытта көптеген салаларда компаниялар бизнесті табысты жүргізу үшін деректермен алмасуға мәжбүр.

Кәсіби жеткізушілер ұсынатын салалық үлгілер ең тиімді болып табылады. Оларды пайдаланудың жоғары тиімділігі осы модельдердің егжей-тегжейлілігі мен дәлдігінің айтарлықтай деңгейінің арқасында қол жеткізіледі. Олар әдетте көптеген деректер атрибуттарын қамтиды. Сонымен қатар, бұл модельдерді жасаушылардың үлкен модельдеу тәжірибесі ғана емес, сонымен қатар белгілі бір салаға арналған үлгілерді құруда жақсы біледі.

Өнеркәсіптік деректер үлгілері компанияларға бизнес ақпаратының бірыңғай, біріктірілген көрінісін береді. Көптеген компаниялар өз деректерін біріктіру қиынға соғады, бірақ бұл солай қажетті жағдайкөптеген корпоративтік жобалар үшін. The Data Warehousing Institute (TDWI) зерттеуіне сәйкес, сауалнамаға қатысқан ұйымдардың 69%-дан астамы интеграцияны жаңа қосымшаларды қабылдауға айтарлықтай кедергі деп тапты. Керісінше, деректерді біріктіруді жүзеге асыру компанияға нақты табыс әкеледі.

Салалық деректер үлгісі, бар жүйелермен байланыстырудан басқа, кәсіпорынның ресурстарын жоспарлау (ERP), негізгі деректерді басқару, іскерлік сараптау, деректер сапасын жақсарту және қызметкерлерді дамыту сияқты жалпы кәсіпорын жобалары үшін үлкен артықшылықтар береді.

Осылайша, салалық логикалық деректер үлгілері деректерді біріктірудің және бизнестің тұтас көрінісін алудың тиімді құралы болып табылады. Логикалық үлгілерді пайдалану корпоративтік деректер қоймаларын құру жолындағы қажетті қадам болып көрінеді.

Жарияланымдар

1. Стив Хоберман. Кәсіпорын деректер үлгісі ретінде салалық логикалық деректер үлгісін пайдалану.
2. Клаудия Имхофф. Интеллектуалды деректерді модельдеу арқылы жылдам бақылау деректер қоймасы және іскери интеллект жобалары

Корпоративтік деректер қоры корпоративтік ақпараттық жүйенің орталық буыны болып табылады және бірыңғай жүйені құруға мүмкіндік береді ақпараттық кеңістіккорпорациялар. Корпоративтік мәліметтер базасы

Егер бұл жұмыс сізге сәйкес келмесе, беттің төменгі жағында ұқсас жұмыстардың тізімі бар. Сондай-ақ іздеу түймесін пайдалануға болады

15 БЕТ

V ТАҚЫРЫП. КОРПОРАТИВТІК ДЕРЕКТЕР ҚОРЫ

ДӘРІС 8

В .бір. Корпоративтік жүйелердегі мәліметтерді ұйымдастыру. Корпоративтік мәліметтер базасы.

В .2. ДҚБЖ және корпоративтік жүйелердегі құрылымдық шешімдер.

V .3. Интернет/интранет технологиялары және деректер қорына кіруге арналған корпоративтік шешімдер.

В .бір. КОРПОРАТИВТІК ЖҮЙЕЛЕРДЕ ДЕРЕКТЕРДІ ҰЙЫМДАСТЫРУ. КОРПОРАТИВТІК ДЕРЕКТЕР ҚОРЫ

Корпоративтік базадеректер корпоративтік ақпараттық жүйенің орталық буыны болып табылады және корпорацияның бірыңғай ақпараттық кеңістігін құруға мүмкіндік береді. Корпоративтік деректер қоры (1.1-сурет).

Мәліметтер қорының әртүрлі анықтамалары бар.

Мәліметтер базасының астында (ДҚ)компьютердің жад құрылғыларында сақталған деректердің біртұтас жиынын құрайтындай логикалық байланысқан ақпарат жиынтығын түсіну. Бұл жиынтық басқарудың автоматтандырылған жүйелерінің, мәліметтерді өңдеу жүйелерінің, ақпаратты және есептеу жүйелері.

Деректер базасы терминін ортақ пайдалануға арналған логикалық байланысты деректер жинағы ретінде қорытындылауға болады.

Деректер базасының астындаоларды бір немесе бірнеше қолданбалар үшін оңтайлы түрде пайдалануға мүмкіндік беретін осындай ең аз артықшылықпен бірге сақталған деректер жиынтығы ретінде түсініледі.

Мәліметтер қорын құру мақсатыдеректерді сақтау нысандары ретінде қабылданған алгоритмдерге (бағдарламалық қамтамасыз етуге), қолданылатын техникалық құралдарға тәуелді емес деректер жүйесін құру, физикалық орналасуыкомпьютердегі деректер. Деректер базасы көп мақсатты пайдалануды болжайды (бірнеше пайдаланушылар, құжаттардың көптеген нысандары және бір пайдаланушының сұраулары).

Мәліметтер қорына қойылатын негізгі талаптар:

• Мәліметтерді ұсынудың толықтығы. Мәліметтер қорындағы деректер объект туралы барлық ақпаратты адекватты түрде көрсетуі керек және олар ODS үшін жеткілікті болуы керек.
• Мәліметтер қорының тұтастығы. Деректерді ОБЖ өңдеу кезінде және жұмыс барысында туындайтын кез келген жағдайларда сақтау керек.
• Деректер құрылымының икемділігі. Деректер базасы сыртқы жағдайлар өзгерген кезде деректер құрылымын оның тұтастығы мен толықтығын бұзбай өзгертуге мүмкіндік беруі керек.
• Мүмкіндік. Бұл әртүрлі объектілердің, олардың қасиеттері мен қатынастарының объективті көрінісі болуы керек дегенді білдіреді.
• Қол жетімділік. Деректерге қол жеткізуді шектеуді қамтамасыз ету қажет.
• Артықшылық. Дерекқорда кез келген объект туралы мәліметтерді көрсетуде ең аз артық болуы керек.

Білім дегенді білдіредімәселені шешу үшін қолданылатын фактілер, заңдылықтар және эвристикалық ережелер жиынтығы.

Білім қоры (КБ)  шешім қабылдаушылардан алынған мәліметтер базасы мен қолданылатын ережелер жиынтығы. Білім базасы сараптамалық жүйелердің элементі болып табылады.

Айырмаумәліметтерді ұсынудың әртүрлі тәсілдері.

Физикалық деректер -бұл компьютер жадында сақталған деректер.

Логикалық мәліметтерді ұсынуфизикалық деректердің теңшелетін көрінісіне сәйкес келеді. Деректердің физикалық және сәйкес логикалық көріністерінің арасындағы айырмашылық соңғысының физикалық деректер арасындағы кейбір маңызды қатынастарды бейнелеуінде.

Корпоративтік деректер базасындаавтоматтандырылатын ұйым туралы барлық қажетті деректер мен білімді бір немесе басқа түрде біріктіретін мәліметтер базасын түсіну. Корпоративтік ақпараттық жүйелерде мұндай ұғымбіріктірілген мәліметтер қоры, онда ақпаратты бір рет енгізу және қайталап пайдалану принципі жүзеге асырылады.

Күріш. 1.1. Бөлімшелердің корпорацияның ақпараттық ресурстарымен өзара әрекеттесу құрылымы.

Корпоративтік мәліметтер базасы болып табыладыбағытталған (орталықтандырылған) және таратылады.

Фокусталған (орталықтандырылған)мәліметтер базасы деректер базасы, оның деректері бір компьютердің сақтау құрылғыларында физикалық түрде сақталады. күріште. 1.2 - диаграмма сервер қолданбасыәртүрлі платформалардағы дерекқорларға қол жеткізу.

1.2-сурет. Схема гетерогенді орталықтандырылған мәліметтер базасы

Ақпаратты өңдеуді орталықтандыру дәстүрлі әдістеменің осындай кемшіліктерін жоюға мүмкіндік берді файлдық жүйелер, деректердің сәйкессіздігі, сәйкессіздігі және артықтығы ретінде. Дегенмен, деректер базасы өскен сайын, әсіресе географиялық шашыраңқы ұйымдарда пайдаланылғанда, мәселелер туындайды. Мысалы, телекоммуникациялық желінің түйінінде орналасқан шоғырландырылған мәліметтер базасы үшін, олардың көмегімен ұйымның әртүрлі бөлімдері деректерге қол жеткізе алады, ақпарат көлемі мен транзакциялар санының өсуімен келесі қиындықтар туындайды:

• Мәліметтер алмасудың үлкен ағыны;
• Желідегі жоғары трафик;
• Төмен сенімділік;
• Нашар жалпы өнімділік.

Шоғырландырылған дерекқордағы жаңартулар кезінде ақпараттың қауіпсіздігін, тұтастығын және дәйектілігін қамтамасыз ету оңайырақ болғанымен, бұл мәселелер белгілі бір қиындықтарды тудырады. Бұл мәселелердің ықтимал шешімі ретінде деректерді орталықсыздандыру ұсынылады. Орталықсыздандыру мыналарға қол жеткізеді:

• Жүктемені теңестіру есебінен өңдеудің бір мезгілдегі жоғары дәрежесі;
• Қашықтан (қашықтан) сұраныстарды орындау кезінде өрістегі деректерді пайдалануды жақсарту;
• Төмен шығындар;
• Жергілікті деректер қорын басқарудың қарапайымдылығы.

Тораптарында жұмыс станциялары (шағын компьютерлер) орналасқан желіні құру шығындары үлкен компьютерді пайдаланып ұқсас жүйені құруға кететін шығындардан әлдеқайда төмен. 1.3-суретте таратылған мәліметтер қорының логикалық диаграммасы көрсетілген.

1.3-сурет. Таратылған корпорация деректер базасы.

Бөлінген мәліметтер қорының келесі анықтамасын берейік.

Бөлінген мәліметтер базасы -бұл әртүрлі түйіндерде сақталатын ақпараттың, файлдардың (қатынастардың) жиынтығы ақпараттық желіжәне деректердің бір жинағын құрайтындай логикалық түрде байланысты (байланыс функционалды немесе бір файлдың көшірмелері арқылы болуы мүмкін). Осылайша, бұл логикалық түрде өзара байланысқан, бірақ физикалық түрде бір компьютерлік желінің бөлігі болып табылатын бірнеше машиналарда орналасқан мәліметтер қорының жиынтығы.

Бөлінген дерекқорға қойылатын ең маңызды өнімділік талаптары:

• Масштабтау мүмкіндігі;
• Үйлесімділік;
• Әр түрлі деректер үлгілерін қолдау;
• Тасымалдау;
• Орналасқан жердің ашықтығы;
• Бөлінген деректер қоры түйіндерінің автономиясы (Site Autonomy);
• Таратылған сұранысты өңдеу;
• Бөлінген операцияларды орындау.
• Біртекті қауіпсіздік жүйесін қолдау.

Орынның мөлдірлігі пайдаланушыларға олардың орналасқан жері туралы ештеңе білмей-ақ дерекқорлармен өзара әрекеттесуге мүмкіндік береді. Бөлінген дерекқор түйіндерінің автономиясы әрбір дерекқорды басқаларына тәуелсіз жүргізуге болатындығын білдіреді. Бөлінген сұраныс – орындалу барысында әртүрлі деректер қорының объектілеріне (кестелер немесе көріністер) қатынасатын сұрау (SQL операторы). Бөлінген транзакцияларды орындау кезінде барлық тартылған деректер қорларының параллельділігін бақылау жүзеге асырылады. Oracle7 таратылған транзакцияларды орындау үшін екі фазалы ақпаратты тасымалдау технологиясын пайдаланады.

Бөлінген деректер қорын құрайтын деректер базалары біртекті болуы (яғни, бір ДҚБЖ қолдауы) немесе бір операциялық жүйе ортасында және/немесе бір типті компьютерлерде өңделуі міндетті емес. Мысалы, бір дерекқор SUN OS (UNIX) жұмыс істейтін SUN құрылғысындағы Oracle дерекқоры болуы мүмкін, екінші дерекқор MVS операциялық жүйесі бар IBM 3090 негізгі фрейміндегі DB2 дерекқорында орналастырылуы мүмкін және үшінші дерекқорды келесілер жүргізуі мүмкін: SQL / DS сонымен қатар IBM негізгі компьютерінде, бірақ VM операциялық жүйесімен. Тек бір шарт қажет – деректер базасы бар барлық машиналар олар бөлігі болып табылатын желі арқылы қол жетімді болуы керек.

Бөлінген мәліметтер қорының негізгі міндеті- желі бойынша мәліметтерді тарату және оған қолжетімділікті қамтамасыз ету. Бұл мәселені шешудің келесі жолдары бар:

• Әрбір түйін қашықтағы сұраулар үшін қол жетімді өзінің деректер жиынын сақтайды және пайдаланады. Бұл бөлу бөлінген.
• Қашықтағы тораптарда жиі пайдаланылатын кейбір деректер қайталануы мүмкін. Бұл бөлу ішінара қайталанатын деп аталады.
• Барлық деректер әрбір түйінде қайталанады. Бұл бөлу толық қайталанатын деп аталады.
• Кейбір файлдарды көлденең (жазбалардың ішкі жиыны таңдалған) немесе тігінен (атрибут өрістерінің ішкі жиыны таңдалған) бөлуге болады, ал таңдалған ішкі жиындар бөлінбеген деректермен бірге әртүрлі түйіндерде сақталады. Бұл бөлу бөлінген (фрагментті) деп аталады.

Бөлінген мәліметтер қорын құру кезінде тұжырымдамалық деңгейде келесі міндеттерді шешу керек:

• Бүкіл желінің бірыңғай концептуалды диаграммасы болуы қажет. Бұл пайдаланушы үшін деректердің логикалық ашықтығын қамтамасыз етеді, соның нәтижесінде ол бөлек терминалдың артында (орталықтандырылған деректер базасымен жұмыс істейтін сияқты) бола отырып, бүкіл деректер базасына сұранысты қалыптастыра алады.
• Желідегі деректерді табу үшін схема қажет. Бұл деректерді орналастырудың ашықтығын қамтамасыз етеді, соның арқасында пайдаланушы қажетті деректерді алу үшін сұрауды қайда жіберу керектігін көрсетудің қажеті жоқ.
• Бөлінген мәліметтер қорының гетерогенділігі мәселесін шешу қажет. Бөлінген деректер қоры аппараттық және бағдарламалық қамтамасыз ету жағынан біртекті немесе гетерогенді болуы мүмкін. Біртектілік мәселесі салыстырмалы түрде оңай шешіледі, егер таратылған мәліметтер базасы аппараттық құрал мағынасында гетерогенді, бірақ бағдарламалық қамтамасыз ету мағынасында біртекті болса (түйіндердегі бірдей ДҚБЖ). Егер таратылған жүйенің түйіндерінде әртүрлі ДҚБЖ пайдаланылса, деректер құрылымдары мен тілдерін түрлендіру құралдары қажет. Бұл таратылған дерекқордың түйіндері бойынша мөлдір түрлендіруді қамтамасыз етуі керек.
• Сөздік басқару мәселесін шешу қажет. Бөлінген дерекқорда барлық ашықтықты қамтамасыз ету үшін көптеген сөздіктер мен анықтамалық кітаптарды басқаратын бағдарламалар қажет.
• Бөлінген дерекқордағы сұрауларды орындау әдістерін анықтау керек. Бөлінген деректер қорындағы сұрауларды орындау әдістері орталықтандырылған деректер қорларындағылардан ерекшеленеді, өйткені сұраулардың жеке бөліктері тиісті деректер орналасқан жерде орындалуы қажет және ішінара нәтижелер басқа түйіндерге берілуі керек; сонымен бірге барлық процестерді үйлестіруді қамтамасыз ету қажет.
• Параллельді сұранысты орындау мәселесін шешу қажет. Бөлінген деректер базасы күрделі параллельді басқару механизмін қажет етеді, ол, атап айтқанда, ақпарат жаңартылған кезде синхрондауды қамтамасыз етуі керек, бұл деректердің сәйкестігін қамтамасыз етеді.
• Деректерді тарату мен орналастырудың әзірленген әдістемесі қажет, оның ішінде бөлу таратылған деректер қорына қойылатын негізгі талаптардың бірі болып табылады.

Ақпаратты сандық емес өңдеудің қуатты құралы болып табылатын есептеуіш жүйелер архитектурасының белсенді дамып келе жатқан жаңа бағыттарының бірі болып табылады.мәліметтер базасының машиналары... Мәліметтер базасының машиналары құжаттар мен фактілерді сақтау, іздеу және түрлендіру, объектілермен жұмыс істеу сияқты сандық емес тапсырмаларды шешу үшін қолданылады. Деректерді қоршаған әлем объектілері туралы цифрлық және графикалық ақпарат ретінде анықтағаннан кейін сандық және сандық емес өңдеудегі деректер түсінігіне әртүрлі мазмұн енгізілген. Сандық өңдеу айнымалылар, векторлар, матрицалар, көп өлшемді массивтер, тұрақтылар және т.б. сияқты объектілерді пайдаланады, ал сандық емес өңдеу файлдар, жазбалар, өрістер, иерархиялар, желілер, қатынастар және т.б. сияқты объектілерді пайдаланады. Сандық емес өңдеу қызықтырады тікелей объектілер туралы ақпаратта (мысалы, белгілі бір қызметкер немесе қызметкерлер тобы), қызметкерлердің файлында емес. Мұнда белгілі бір адамды таңдау үшін қызметкерлердің файлы индекстелмейді; мұнда қалаған жазбаның мазмұны қызықтырақ. Ақпараттың үлкен көлемі әдетте сандық емес өңдеуге ұшырайды. Әртүрлі қолданбаларда, мысалы, осы деректермен келесі әрекеттерді орындауға болады:

• компанияның барлық қызметкерлерінің жалақысын көтеру;
• барлық клиенттердің шоттары бойынша банк сыйақысын есептеу;
• қоймадағы барлық тауарлардың тізіміне өзгерістер енгізу;
• кітапханада немесе библиографиялық ақпараттық-іздестіру жүйесінде сақталған барлық мәтіндерден қажетті рефератты табу;
• заңды құжаттары бар файлдан талап етілетін шарттың сипаттамасын табу;
• патенттердің сипаттамасы бар барлық файлдарды қарап шығыңыз және ұсынылғанға ұқсас патентті (бар болса) табыңыз.

Деректер базасының қозғалтқышын іске асыру үшін,параллельді және ассоциативті архитектура бірпроцессорға балама ретіндефон Нейманнақты уақыт режимінде үлкен көлемдегі ақпаратпен жұмыс істеуге мүмкіндік беретін құрылым.

Мәліметтер базасының машиналары жасанды интеллект концепцияларын зерттеу және қолданумен байланысты маңыздылыққа ие болуда, мысалы, білімді ұсыну, сараптамалық жүйелер, қорытынды жасау, үлгіні тану және т.б.

Ақпарат қоймалары.Бүгінгі таңда көптеген компаниялар қазірдің өзінде бірнеше деректер базасымен жұмыс істейтінін мойындайды және ақпаратпен сәтті жұмыс істеу үшін әртүрлі деректер базалары ғана емес, сонымен қатар ДҚБЖ әртүрлі буындары қажет. Статистикаға сәйкес, әрбір ұйым орта есеппен 2,5 түрлі ДҚБЖ пайдаланады. Компаниялардың бизнесін, дәлірек айтсақ, осы бизнеспен айналысатын адамдарды деректер базаларының технологиялық ерекшеліктерінен «оқшаулау» қажеттілігі, оның физикалық сақталғанына қарамастан, пайдаланушыларға корпоративтік ақпараттың бір көрінісін ұсыну қажеттілігі айқын болды. Бұл технологияның пайда болуына түрткі болды ақпарат қоймалары (Деректер қоймасы, DW).

DW негізгі мақсаты болып табыладыәртүрлі типтегі деректер қорларында қамтылған деректердің біртұтас логикалық көрінісін немесе басқаша айтқанда, деректердің бірыңғай корпоративтік моделін құру.

Жақсартудың арқасында DW дамуының жаңа кезеңі мүмкін болды ақпараттық технологияларжалпы алғанда, атап айтқанда, сұраныстарды параллельді өңдеуге негізделген мәліметтер қорының жаңа түрлерінің пайда болуы, бұл өз кезегінде параллельді компьютерлердегі жетістіктерге сүйенді. Құрылдықұрастырушыларды сұрауинтуитивтікпен графикалық интерфейс, бұл дерекқорға күрделі сұрауларды құруды жеңілдетеді. Әртүрлі бағдарламалық қамтамасыз етуортаңғы қабат (ортаңғы бағдарлама)байланысын қамтамасыз еттігетерогенді мәліметтер базасы арасында, ақыры күрт төмендедісақтау құрылғылары.

Корпорацияның құрылымы болуы мүмкіндерекқор.

Дерекқор - автоматтандырылған басқару жүйелеріндегі және орталықтандырылған орындайтын ақпараттық-есептеу жүйелеріндегі функционалдық және ұйымдастырушылық құрамдас бөлік Ақпараттық қолдаупайдаланушылар ұжымы немесе жүйеде шешілетін міндеттер жиынтығы.

Дерекқор ақпараттық-анықтамалық жүйе ретінде қарастырылады, оның негізгі мақсаты:

• бүкіл автоматтандырылған жүйенің ақпараттық базасын немесе онда шешілетін міндеттердің белгілі бір кешенін құрайтын ақпарат жиынтығын жинақтау және жұмыс тәртібінде ұстауда;
• тапсырма немесе пайдаланушы талап ететін деректерді шығаруда;
• сақталған ақпаратқа ұжымдық қол жеткізуді қамтамасыз етуде;
• ақпараттық базада қамтылған ақпаратты пайдалануды қажетті басқаруды қамтамасыз етуде.

Сонымен, қазіргі деректер банкі – бұл күрделі бағдарламалық-аппараттық кешен, оның құрамына техникалық, жүйелік және желілік құралдар, мәліметтер қоры мен ДҚБЖ, әртүрлі мақсаттағы ақпаратты іздеу жүйелері кіреді.

В .2. ДҚБЖ ЖӘНЕ КОРПОРАТИВТІК ЖҮЙЕЛЕРДЕГІ ҚҰРЫЛЫМДЫҚ ШЕШІМДЕР

Мәліметтер қоры мен білімді басқару жүйелері

Қазіргі ақпараттық жүйелердің маңызды құрамдас бөлігі мәліметтер қорын басқару жүйелері (МҚБЖ) болып табылады.

ДҚБЖ - мәліметтер қорын құруға, жүргізуге және пайдалануға арналған бағдарламалық және тілдік құралдардың жиынтығы.

Мәліметтер базасын басқару жүйесі мәліметтерді өңдеу жүйелерінің мәліметтер базасына қол жеткізуін қамтамасыз етеді. Жоғарыда айтылғандай, ДҚБЖ корпоративтік ақпараттық жүйелерді құруда маңызды рөлге ие және қазіргі заманғы желілік компьютерлік технологиялар негізінде таратылған ақпараттық ресурстарды пайдалана отырып, ақпараттық жүйелерді құруда ерекше маңызды рөл атқарады.

Қазіргі ДҚБЖ-ның басты ерекшелігі - қазіргі ДҚБЖ осындайларды қолдайдысияқты технологиялар:

• Клиент/сервер технологиясы.
• Деректер қоры тілдерін қолдайды. Бұлсхеманы анықтау тіліДБ (SDL - схемаларды анықтау тілі),деректерді өңдеу тілі (DML), біріктірілген тілдер SQL (Structured Queue Language), QDB (Query - By - Example) және QMF (Сұрауларды басқару құралы) ) Қосымша перифериялық сұрау спецификациясы және есеп беру құралы болып табылады DB 2 және т.б.;
• Сыртқы жадтағы деректерді тікелей басқару.
• ЖЖҚ буферлерін басқару.
• Транзакцияны басқару. OLTP – технология (On-Line Transaction Processing), OLAP -технология (Онлайн талдауды өңдеу) DW үшін.
• Деректердің қорғалуын және тұтастығын қамтамасыз ету. Жүйені пайдалану деректерге қол жеткізуге құқығы бар пайдаланушыларға ғана рұқсат етіледі. Пайдаланушылар деректермен операцияларды орындаған кезде сақталған деректердің сәйкестігі (тұтастығы) сақталады. Бұл корпоративтік көп пайдаланушы ақпараттық жүйелерде маңызды.
• Журналистика.

Заманауи ДҚБЖ жоғарыда аталған дерекқор талаптарына сәйкестікті қамтамасыз етуі керек. Сонымен қатар, олар келесі принциптерге сәйкес келуі керек:

• Деректер тәуелсіздігі.
• Жан-жақтылық. ДҚБЖ теңшелетін логикалық көріністерді көрсету үшін қуатты тұжырымдамалық деректер үлгісінің қолдауына ие болуы керек.
• Үйлесімділік. ДҚБЖ бағдарламалық және аппараттық құралдарды әзірлеу кезінде жұмыс істеп тұруы керек.
• Мәліметтердің артық болуы. Файлдық жүйелерден айырмашылығы, деректер базасы біріктірілген деректердің бір жиынтығы болуы керек.
• Деректерді қорғау. ДҚБЖ рұқсатсыз кіруден қорғауды қамтамасыз етуі керек.
• Деректер тұтастығы. ДҚБЖ пайдаланушылардың дерекқорды бұзуына жол бермеуі керек.
• Бір мезгілде жұмысты басқару. ДҚБЖ деректер қорын ортақ қол жеткізу режиміндегі сәйкессіздіктерден қорғауы керек. Мәліметтер қорының тұрақты күйін қамтамасыз ету үшін пайдаланушының барлық сұраулары (транзакциялары) белгілі бір тәртіпте орындалуы керек.
• ДҚБЖ әмбебап болуы керек. Ол қолдау көрсетуі керек әртүрлі модельдербір логикалық және физикалық негізде деректер.
• ДҚБЖ орталықтандырылған және таратылған мәліметтер қорын қолдауы керек және осылайша компьютерлік желілердегі маңызды сілтеме болуы керек.

ДҚБЖ класс ретінде қарастыру бағдарламалық өнімдердеректер қорының автоматтандырылған жүйелерінде техникалық қызмет көрсетуге бағытталған, ДҚБЖ түрлерін анықтайтын ең маңызды екі мүмкіндік бар. Олардың пікірінше, ДҚБЖ екі тұрғыдан қарастырылуы мүмкін:

• таратылған (корпоративтік) деректер қорларына қатысты олардың мүмкіндіктері;
• олардың ДҚБЖ іске асырылатын деректер үлгісінің түріне қатынасы.

Корпоративтік (таратылған) деректер қорларына қатысты МҚБЖ келесі түрлерін шартты түрде ажыратуға болады:

• «Жұмыс үстелі» ДҚБЖ. Бұл өнімдер бірінші кезекте жеке деректермен («жұмыс үстелі» деректері) жұмыс істеуге бағытталған. Олардың жалпы деректер қорын ортақ пайдалану үшін пәрмен жиындары бар, бірақ өлшемі шағын (шағын кеңсе сияқты). Ең алдымен, бұл Assess, dBASE, Paradox, EohPgo сияқты ДҚБЖ. Неліктен Assess, dBASE, Paradox, EohPgo корпоративтік деректерге нашар қол жеткізе алады. Мәселе мынада, жеке және корпоративтік деректер арасындағы кедергіні жеңудің оңай жолы жоқ. Мәселе тіпті ДҚБЖ (немесе шағын кеңсе) дербес деректерінің механизмі көптеген шлюздер, интернет-жұмыс өнімдері және т.б. арқылы деректерге қол жеткізуге бағытталғанында емес. Мәселе мынада, бұл механизмдер әдетте толық файлдарды тасымалдаумен және айырықша индексті қолдаудың жоқтығымен байланысты, бұл үлкен жүйелерде серверлік кезектердің іс жүзінде тоқтап қалуына әкеледі.
• Мамандандырылған өнімділігі жоғары көп пайдаланушылық ДҚБЖ. Мұндай ДҚБЖ көп пайдаланушылық жүйе ядросының болуымен, деректермен жұмыс істеу тілімен және келесі функцияларәзірленген көппайдаланушы ДҚБЖ үшін тән:
• буферлік пулды ұйымдастыру;
• транзакциялардың кезектерін өңдеу жүйесінің болуы;
• көп пайдаланушы деректерін құлыптау механизмдерінің болуы;
• транзакцияларды тіркеу;
• қол жеткізуді басқару тетіктерінің болуы.

Бұл ДҚБЖ Oracle сияқты, DB2, SQL / Server, Informix, Sybase, ADABAS, Titanium және т.б. корпоративтік деректер қорын өңдеуге кең қызмет көрсетеді.

Мәліметтер қорымен жұмыс істегенде транзакция механизмі қолданылады.

Мәміле Жұмыстың логикалық бірлігі болып табылады.

Мәміле орындалатын деректерді өңдеу мәлімдемелерінің тізбегі болып табыладытұтастай алғанда(бәрі немесе ештеңе) және дерекқорды аударубір тұтас күйден екінші тұтас күйге.

Транзакцияның төрт маңызды қасиеті бар ASID қасиеттері:

• А) Атомдық ... Транзакция атомдық операция ретінде орындалады - не бүкіл транзакция орындалады, не ол толығымен орындалмайды.
• (C) Жүйелілік... Транзакция дерекқорды бір тұрақты (дәйекті) күйден басқа дәйекті (дәйекті) күйге жылжытады. Транзакцияда дерекқордың жүйелілігі бұзылуы мүмкін.
• (I) Оқшаулау ... Әртүрлі пайдаланушылардың транзакциялары бір-біріне кедергі жасамауы керек (мысалы, олар қатаң түрде кезекпен орындалғандай).
• (E) Төзімділік... Егер транзакция аяқталса, оның жұмысының нәтижелері келесі сәтте жүйе бұзылса да, деректер базасында сақталуы керек.

Транзакция әдетте пайдаланушы ДҚБЖ-ға қосылған сәттен бастап автоматты түрде басталады және келесі оқиғалардың бірі орын алғанша жалғасады:

• COMMINT WORK командасы шығарылды.
• ROLLACK WORK пәрмені шығарылды.
• Пайдаланушы ДҚБЖ-дан ажыратылды.
• Жүйеде ақау болды.

Пайдаланушы үшін ол әдетте киедіатомдық сипаты... Іс жүзінде бұл күрделі қолданушы (қосымша) – деректер базасының өзара әрекеттесу механизмі. Кәсіпорын жүйелерінің бағдарламалық жасақтамасы нақты уақыттағы транзакцияларды өңдеу механизмін пайдаланады (On-lineTransaction Processing Systems, OLTP), атап айтқанда бухгалтерлік бағдарламалық қамтамасыз ету, бағдарламалық қамтамасыз етуКлиент тапсырыстарын, қаржылық қосымшаларды қабылдау және өңдеу, көптеген ақпаратты шығарады. Бұл жүйелер деректердің үлкен көлемін, күрделі транзакцияларды және қарқынды оқу/жазу операцияларын өңдеуге арналған (және тиісінше оңтайландырылған).

Өкінішке орай, OLTP жүйелерінің деректер базасында орналастырылған ақпарат қарапайым пайдаланушылар үшін өте қолайлы емес (кестелерді қалыпқа келтірудің жоғары дәрежесіне, деректерді ұсынудың нақты форматтарына және басқа факторларға байланысты). Сондықтан әртүрлі ақпараттық конвейерлерден деректер жіберіледі (мағынасында, көшіріледі).сақтау қоймасы, сұрыптау және тұтынушыға кейіннен жеткізу. Ақпараттық технологияда қоймалардың рөлін атқарадыақпарат қоймалары.

Ақпаратты соңғы пайдаланушыға жеткізу – нақты уақыт режимінде деректерді өңдеудің аналитикалық жүйелері(Онлайн аналитикалық өңдеу, OLAP)бұл сұрауларды жасаудың және нәтижелерді талдаудың ыңғайлы құралдары арқылы деректерге өте оңай қол жеткізуді қамтамасыз етеді. OLAP жүйелерінде ақпараттық өнімнің құны талдаудың және статистикалық өңдеудің әртүрлі әдістерін қолдану есебінен өседі. Сонымен қатар, бұл жүйелер деректерді шығару жылдамдығы, жалпылама ақпаратты жинау тұрғысынан оңтайландырылған және қарапайым пайдаланушыларға бағытталған (олардың интуитивті интерфейсі бар). Егер OLTP жүйесі «199x жылдың қаңтарында М аймағындағы N өнімінің сатылу деңгейі қандай болды?» деген қарапайым сұрақтарға жауап береді, содан кейін. OLAP жүйелері көбірек дайын күрделі сұрауларпайдаланушылар, мысалы: «Екінші тоқсанның жоспары бойынша барлық өңірлер бойынша өткен екі жылмен салыстырғанда N өнімін өткізуге талдау жасау».

Клиент/сервер архитектурасы

Қазіргі жүйелердетаратылған ақпаратты өңдеу, технология орталық орын аладыклиент/сервер. Жүйеде клиент-сервер архитектурасымәліметтерді өңдеу клиенттік компьютер мен серверлік компьютер арасында бөлінеді, олардың арасындағы байланыс желі арқылы жүзеге асады. Мәліметтерді өңдеудің бұлайша бөлінуі функцияларды топтастыруға негізделген. Әдетте дерекқор серверінің компьютері дерекқор операцияларын орындауға арналған, ал клиенттік компьютер қолданбалы бағдарламаларды іске қосады. 2.1-суретте көрсетілген қарапайым жүйесервер ретінде әрекет ететін компьютерді және оның клиенті ретінде әрекет ететін басқа компьютерді қамтитын клиент-сервер архитектурасы. Әрбір машина әртүрлі функцияларды орындайды және өз ресурстарына ие.

Күріш. 2.1. Клиент-сервер архитектуралық жүйесі

Клиенттік компьютердің негізгі қызметі қолданбаны орындау (пайдаланушы интерфейсі және презентация логикасы) және қолданба талап еткенде сервермен байланысу болып табылады.

Сервер Басқа объектілерге олардың сұранысы бойынша қызмет көрсететін объект (компьютер) болып табылады.

Терминнің өзінен шығатындай, серверлік компьютердің негізгі қызметі клиенттің қажеттіліктерін қанағаттандыру болып табылады. «Сервер» термині екі түрлі функциялар тобын белгілеу үшін пайдаланылады: файлдық сервер және дерекқор сервері (бұдан әрі бұл терминдер контекстке байланысты функциялардың көрсетілген топтарын жүзеге асыратын бағдарламалық жасақтаманы немесе осы бағдарламалық жасақтамасы бар компьютерлерді білдіреді) . Файлдық серверлер дерекқор операцияларын орындауға арналмаған, олардың негізгі қызметі бірнеше пайдаланушылар арасында файлдарды ортақ пайдалану, яғни. көптеген пайдаланушылардың компьютердегі файлдарға – файлдық серверге бір уақытта қол жеткізуін қамтамасыз ету. Файлдық сервердің мысалы ретінде Novell компаниясының NetWare операциялық жүйесі болып табылады. Дерекқор серверін файлдық сервер компьютерінде орнатуға және басқаруға болады. NLM (Network Loadable Module) түріндегі Oracle ДҚБЖ файлдық сервердегі NetWare ортасында орындалады.

Сервер жергілікті желіоның функционалдығы мен желі қажеттіліктеріне сәйкес келетін ресурстар болуы керек. Ашық жүйелер тәсіліне назар аударуға байланысты әртүрлі компьютерлерде міндетті түрде орналаспаған логикалық серверлер (осы ресурстар бойынша қызметтерді ұсынатын ресурстар мен бағдарламалық қамтамасыз ету жиынтығы дегенді білдіреді) туралы айту дұрысырақ екенін ескеріңіз. Ашық жүйедегі логикалық сервердің ерекшелігі, егер тиімділік себептері бойынша серверді бөлек компьютерге көшірген жөн болса, онда мұны өздігінен де, қолданбаларды да өзгертуді қажет етпей-ақ жасауға болады. оны пайдаланатын.

Маңызды сервер талаптарының бірі дерекқор серверін орналастыратын операциялық жүйе көп тапсырмалы болуы керек (және жақсырақ, бірақ міндетті түрде көп пайдаланушы емес). Мысалы, MS-DOS (немесе PC-DOS) операциялық жүйесі бар дербес компьютерде орнатылған Oracle ДҚБЖ көп тапсырма талаптарына сай келмейтін дерекқор сервері ретінде пайдаланыла алмайды. Ал көп тапсырмалы (бірақ көп пайдаланушы емес) OS/2 операциялық жүйесі бар компьютерде орнатылған сол Oracle дерекқоры деректер қорының сервері бола алады. Көптеген сорттар UNIX жүйелері, MVS, VM және басқалары ОЖолар көп тапсырмалы және көп пайдаланушы болып табылады.

Бөлінген есептеулер

«Таратылған есептеулер» термині көбінесе бір-бірін толықтыратын екі түрлі ұғымға сілтеме жасау үшін қолданылады:

• Бөлінген мәліметтер базасы;
• Бөлінген деректерді өңдеу.

Бұл тұжырымдамаларды қолдану соңғы пайдаланушылар үшін әртүрлі құралдарды пайдалана отырып, бірнеше машиналарда сақталған ақпаратқа қол жеткізуді ұйымдастыруға мүмкіндік береді.

Серверлердің көптеген түрлері бар:

• Мәліметтер базасының сервері;
• басып шығару сервері;
• Қашықтан қол жеткізу сервері;
• факс сервері;
• Веб-сервер және т.б.

Негізгі технологияның негізінде Клиент/Сервер табыладынегізгі технологиялар болып табылады:

• Операциялық жүйе технологиялары, ашық жүйелердің өзара әрекеттесу тұжырымдамасы, бағдарламалардың жұмыс істеуі үшін объектілі-бағытталған орталарды құру;
• телекоммуникациялық технологиялар;
• Желілік технологиялар;
• Графикалық технология пайдаланушы интерфейсі ( GUI);
• Және т.б.

Клиент-сервер технологиясының артықшылықтары:

• Клиент/сервер технологиясы гетерогенді есептеу орталарында есептеуге мүмкіндік береді. Платформаның тәуелсіздігі: әртүрлі операциялық жүйелері бар компьютерлердің әртүрлі типтерін қамтитын гетерогенді желілік орталарға қол жеткізу.
• Деректер көздерінен тәуелсіздік: гетерогенді деректер қорынан ақпаратқа қол жеткізу. Мұндай жүйелердің мысалдары DB2, SQL/DS, Oracle, Sybase.
• Клиент пен сервер арасындағы жүктеме балансы.
• Есептеуді ең тиімді жерде орындаңыз;
• Тиімді масштабтау мүмкіндігін қамтамасыз ету;
• Кросс-платформалық есептеулер... Кросс-платформалық есептеулер гетерогенді есептеу орталарында технологияларды енгізу ретінде ғана анықталады. Мұнда келесі мүмкіндіктер қамтамасыз етілуі керек:
• Қолданба бірнеше платформаларда жұмыс істеуі керек;
• Барлық платформаларда оның интерфейсі мен жұмыс логикасы бірдей болуы керек;
• Қолданба жергілікті бағдарламамен біріктірілуі керек операциялық орта;
• Ол барлық платформаларда бірдей әрекет етуі керек;
• Ол үшін қарапайым және дәйекті қолдау көрсетілуі керек.

 Бөлінген есептеулер. Бөлінген есептеулер жұмысты бірнеше компьютерлер арасында бөлуді қамтиды (бірақ бөлінген есептеулер кеңірек ұғым).

 Кішірейту. Кішірейту – бұл негізгі компьютерлік қосымшаларды шағын компьютерлік платформаларға тасымалдау.

• Инфрақұрылымға және аппараттық құралдарға шығындар төмендетілді. Тиімді: арзан есептеуіш жабдықтардың болуы және жергілікті желілердің көбеюі клиент-сервер технологиясын басқа деректерді өңдеу технологияларына қарағанда үнемді етеді. Жабдықты қажет болған кезде жаңартуға болады.

 Өтінімнің жалпы орындалу уақытын қысқарту;

 Клиент жадын пайдалануды азайту;

 Желілік трафикті азайту.

• Мультимедиамен жұмыс істей білу: бүгінгі күні ДК үшін көптеген мультимедиялық бағдарламалар жасалған. Ұқсас бағдарламалартерминалдан хостқа конфигурация үшін олар жоқ немесе олар өте қымбат.
• Мәліметтер базасының операциялары үшін үлкен есептеу ресурстарын тарту мүмкіндігі: қолданбалар клиенттік компьютерлерде орындалатындықтан, орталық процессордың есептеу ресурстары және компьютерлік серверлер сияқты дерекқор операциялары үшін серверлік компьютерде қосымша (терминал-хост конфигурациясымен салыстырғанда) ресурстар босатылады. операциялық жады.
• Бағдарламалаушының өнімділігі жақсырақ: Бағдарламалаушының өнімділігі C, PL1 немесе COBOL сияқты бағдарламалау тілдеріне қарағанда қосымшаларды жылдам әзірлеуге мүмкіндік беретін SQL * Forms және CASE сияқты құралдарды пайдалану арқылы артады.
• Соңғы пайдаланушы өнімділігінің артуы: Қазіргі уақытта көптеген соңғы пайдаланушылар Lotus, Paradox, Word Perfect, Harvard Graphics және т.б. сияқты жүйелерді игерді.

Сервер интерфейсі анықталған және бекітілген. Сондықтан жаңа клиент бөліктерін жасауға болады. бар жүйе(жүйе деңгейіндегі өзара әрекеттестіктің мысалы).

Күріш. 2.2. Клиенттің серверлік ортақ пайдалану рұқсатының иллюстрациясы.

Клиент-сервер технологиясын енгізу жолы

Клиент-сервер технологиясына негізделген және таратылған деректерді өңдеуді орындауға қабілетті жүйені орнату төменде талқыланады. Келесі компьютерлік жабдық пен бағдарламалық құрал қажет:

• мәліметтер қоры серверінің компьютері;
• клиенттік компьютерлер;
• байланыс желісі;
• желілік бағдарламалық қамтамасыз ету;
• қолданбалы бағдарламалық қамтамасыз ету.

SQL тілі ... Жоғары деңгейлі сұрау тілі - SQL (құрылымдық сұраныс тілі ) YAMD, YOD және PNP сияқты дерекқорларға сұраныстарды орындау үшін қызмет етеді және стандарт ретінде қабылданған. Тіл SQL бастапқыда компанияның бағдарламалық өнімдерінің деректер тілі ретінде қабылданған IBM және YAMD реляциялық ДҚБЖ IBM компаниясынан SYSTEM R ... Тілдің маңызды қасиеті SQL бір тілдің екі түрлі интерфейс арқылы, атап айтқанда: интерактивті интерфейс арқылы және қолданбалы бағдарламалау интерфейсі (динамикалық) арқылы ұсынылатынында жатыр. SQL). Динамикалық SQL көптеген кіріктірілген тіл мүмкіндіктерінен тұрады SQL , интерактивті қосымшаларды құру үшін арнайы қарастырылған, мұнда интерактивті қолданба интерактивті терминалда жұмыс істейтін соңғы пайдаланушының дерекқорына қол жеткізуді қолдау үшін жазылған бағдарлама ретінде түсініледі. Тіл SQL ДҚ деректерін анықтау, манипуляциялау және басқару функцияларын қамтамасыз етеді және енгізілген ДҚБЖ тұрғысынан пайдаланушыға ашық болады.

Күріш. 2.3. Бөлінген деректер қорларына пайдаланушы сұраныстарын орындау схемасы.

Ішкі құрылымдерекқорлар пайдаланылатын деректер үлгілерін анықтайды. Концептуалды модельде сыртқы модельдерге қарағанда абстракциялық мүмкіндіктер мен бай семантика бар. Сыртқы модельдер көбінесе синтаксистік немесе операциялық модельдер деп аталады, бұл басқарудың синтаксистік сипатына және пайдаланушының деректер қорымен әрекеттесу құралы ретінде пайдалануына сілтеме жасайды. Ақпараттық модельдеуде ДҚБЖ архитектурасына әсер ететін концептуалды модельден физикалық деректер үлгісіне дейінгі абстракцияның әртүрлі деңгейлері бар.

Деректер моделі үш компоненттен тұрады:

• Дерекқордың пайдаланушы көзқарасы бойынша ұсынылатын деректер құрылымы.
• Деректер құрылымында орындалатын жарамды операциялар. Бұл құрылыммен NOD және NAM әртүрлі операцияларын қолдана отырып жұмыс істей білу қажет. Егер оның мазмұнын басқаруға мүмкіндік болмаса, бай құрылым түкке тұрғысыз.
• Тұтастықты бақылау шектеулері. Деректер моделі оның тұтастығын сақтау және оны қорғау құралдарымен қамтамасыз етілуі керек. Мысал ретінде келесі екі шектеуді қарастырыңыз:
• Әрбір ішкі ағаштың бастапқы түйіні болуы керек. Иерархиялық дерекқорлар еншілес түйіндерді бастапқы түйінсіз сақтай алмайды.
• Реляциялық дерекқорға қатысты бірдей кортеждер болуы мүмкін емес. Файл үшін бұл талап барлық жазбалардың бірегей болуын талап етеді.

ДҚБЖ маңызды сипаттамаларының бірі объектілерді байланыстыру мүмкіндігі болып табылады.

Объектілер арасындағы байланыстардың келесі түрлері бар:

• Бірден-бір (1:1)... Бір жиынның бір объектісі басқа жиынның бір объектісімен байланысты болуы мүмкін.
• Бірден көпке (1: М)... Бір жиынның бір объектісі басқа жиынның көптеген объектілерімен байланысты болуы мүмкін.
• Көптен көпке (M: N)... Бір жиынның бір объектісі басқа жиынның көптеген объектілерімен байланысты болуы мүмкін, бірақ сонымен бірге басқа жиынның бір объектісі бірінші жиынның көптеген объектілерімен байланысты болуы мүмкін.
• Рамификацияланған ... Бір жиынның бір объектісі көптеген жиындардың объектілерімен байланыстырылуы мүмкін.
• Рекурсивті ... Бір нысан бұл жиынтықбір жиынның объектісі арқылы байланыстыруға болады.

Келесі негізгі деректер үлгілері бар:

• Реляциялық модельдеректер.
• Иерархиялық деректер моделі.
• Толық емес желі деректер үлгісі.
• CODASYL деректер үлгісі.
• Кеңейтілген желі деректерінің үлгісі.

V .3. ИНТЕРНЕТ/ИНТРАНЕТ ТЕХНОЛОГИЯЛАРЫ ЖӘНЕ КОРПОРАТИВТІК ДЕРЕКТЕР ҚОРЫНЫН ҚОЛДАНУ ШЕШІМДЕРІ

Клиент-сервер архитектурасына негізделген жүйелердің негізгі мәселесі ашық жүйелер концепциясына сәйкес олардан ашық жүйелердің аппараттық және бағдарламалық шешімдерінің барынша кең класында мобильді болуы талап етіледі. Біз UNIX негізіндегі жергілікті желілермен шектелсек те, әртүрлі желілер әртүрлі жабдықты және байланыс протоколдарын пайдаланады. Барлық мүмкін болатын хаттамаларды қолдайтын жүйелерді құру әрекеттері олардың функционалдылыққа зиянын тигізетін желі мәліметтерімен шамадан тыс жүктелуіне әкеледі.

Бұл мәселенің одан да күрделі аспектісі гетерогенді жергілікті желінің әртүрлі түйіндерінде деректердің әртүрлі көрсетілімдерін пайдалану мүмкіндігімен байланысты. Әртүрлі компьютерлерде әртүрлі адресация, сандарды көрсету, таңбаларды кодтау және т.б. болуы мүмкін. Бұл әсіресе жоғары деңгейлі серверлер үшін маңызды: телекоммуникациялар, есептеулер, мәліметтер базасы.

Клиент-сервер архитектурасына негізделген жүйелердегі ұтқырлық мәселесінің жалпы шешімі қашықтағы процедураларды шақыру (RPC) протоколдарын жүзеге асыратын бағдарламалық пакеттерге сүйену болып табылады. Осы құралдардың көмегімен қашықтағы тораптағы қызметке шақыру қалыпты процедура шақыруына ұқсайды. Жергілікті желі аппараттық құралдарының және желілік протоколдардың ерекшеліктері туралы барлық ақпаратты табиғи түрде қамтитын RPC құралдары қоңырауды желілік өзара әрекеттесу тізбегіне айналдырады. Осылайша, желілік ортаның және хаттамалардың ерекшеліктері қолданбалы бағдарламашыдан жасырылады.

Қашықтағы процедура шақырылғанда, RPC бағдарламалары клиент деректерінің пішімдерін аралық машинадан тәуелсіз пішімдерге түрлендіреді, содан кейін сервер деректер пішіміне түрлендіреді. Жауап параметрлерін беру кезінде ұқсас түрлендірулер орындалады.

Бұл мақала деректер қоймасының архитектурасына назар аударады. Оны салу кезінде нені басшылыққа алу керек, жұмысқа қай көзқарас - және неге.

«Ертегі өтірік, бірақ оның ішінде түсінік бар ...»

Атамыз ертегіден қандай шешім қабылдаса да – жаңа қойма салу немесе бұрыннан барын қайта жандандыру – қайта «жеңді түрмек» алдында қорытынды жасау керек.
Ұйымдастырушылық аспектілерді былай қояйық - мысалы, белгілі бір тар жабық топқа сараптаманың шоғырлану қаупі, басқару процестерінің болмауы және кәсіпорында қолданылатын жүйелер архитектурасының ашықтығын қамтамасыз ету және т.б.
Бүгін мен белгілі бір жүйенің (немесе жүйелер тобының) – деректер қоймасының архитектурасын құруға тоқталғым келеді. Ұйым қойма сияқты күрделі және қымбат жүйені құра бастағанда, ең алдымен, нені назарда ұстау керек.

Дебрифинг

Бастау үшін репозиторийлермен жұмыс істеу кезінде жиі кездесетін типтік мәселелердің тізімін берейік. Бізде бар нәрсені жазып алайық – әзірге ретке келтіріп, рәсімдеуге тырыспай-ақ.

1. Негізінде, бізде жақсы сақтау орны бар: егер сіз оны жалғыз қалдырсаңыз, онда бәрі жұмыс істейді. Рас, өзгерту қажет болған кезде «жергілікті күйреулер» басталады.
2. Деректер күн сайын, ережелерге сәйкес, бір үлкен процесте, 8 сағат ішінде жүктеледі. Және ол бізге жарасады. Бірақ кенеттен сәтсіздік орын алса, ол қолмен араласуды қажет етеді. Содан кейін бәрі ұзақ уақыт бойы күтпеген жерден жұмыс істей алады, tk. процеске адамның қатысуын талап етеді.
3. Шығарылымды жинадық - проблемаларды күтіңіз.
4. Кейбір бір дереккөз деректерді уақытында жібере алмады - барлық процестер күтуде.
5. Деректердің тұтастығын дерекқор басқарады, сондықтан ол бұзылған кезде біздің процестеріміз бұзылады.
6. Бізде өте үлкен сақтау орны бар - бір жалпы схемадағы 2000 кесте. Көптеген басқа схемаларда тағы 3000. Бізде олардың қалай орналасқаны және қандай себеппен пайда болғаны туралы аз түсінік бар. Сондықтан бір нәрсені қайта пайдалану бізге қиын болуы мүмкін. Және көптеген міндеттерді жаңадан шешуге тура келеді. Өйткені, бұл оңай және жылдамырақ («біреудің кодын» түсінуге қарағанда). Нәтижесінде бізде сәйкессіздіктер және қайталанатын функциялар бар.
7. Біз дереккөздің сапалы деректер береді деп күтеміз. Бірақ олай емес екені белгілі болды. Нәтижесінде біз қорытынды есептерді салыстыруға көп уақыт жұмсаймыз. Және олар бұл істе өте сәтті болды. Бізде тіпті жеңілдетілген процесс бар. Рас, уақыт керек. Бірақ пайдаланушылар әдеттенген ...
8. Пайдаланушы біздің есептерімізге әрқашан сенбейді және бір немесе басқа цифрдың негіздемесін талап етеді. Кейбір жағдайларда ол дұрыс, ал басқаларында олай емес. Бірақ біз үшін оларды ақтау өте қиын, өйткені бізде «соңғы талдау» (немесе деректер желісі) құралдары жоқ.
9. Біз қосымша әзірлеушілерді тарта аламыз. Бірақ бізде бір мәселе бар – оларды жұмысқа қалай қосамыз? Жұмыстарды параллельдеудің ең тиімді жолы қандай?
10. Бір жыл бойы «жүйенің өзегін» дамытуға бармай-ақ, жүйені қалай біртіндеп дамытуға болады?
11. Деректер қоймасы корпоративтік үлгімен байланысты. Бірақ біз нақты білеміз (біз оны XYZ банкінде көрдік) модель құру шексіз ұзаққа созылуы мүмкін (біз алты ай бойы XYZ банкіне бардық және ешқандай қозғалыссыз кәсіпкерлік субъектілерін талқыладық). Неге ол мүлде? Немесе онымен проблемалар көп болса, онсыз жақсы ма? Мүмкін біз оны қандай да бір жолмен жасай аламыз ба?
12. Біз модельді жүргізуді шештік. Бірақ қойма деректерінің үлгісін жүйелі түрде қалай дамытасыз? Бізге «ойын ережелері» керек пе және олар не болуы мүмкін? Ол бізге не береді? Үлгіде қателессек ше?
13. «Бизнеске қажет болмаса» деректерді немесе оның өзгеру тарихын сақтау керек пе? Мен «қоқыстарды сақтауды» және бұл деректерді нақты тапсырмалар үшін пайдалануды қиындатуды қаламас едім. Қойма тарихты сақтауы керек пе? Ол қандай? Уақыт бойынша сақтау қалай жұмыс істейді?
14. Бізде деректерді басқарудың негізгі жүйесі болса, жадтағы деректерді бір жүйеге келтіруге тырысуымыз керек пе? Егер MDM болса, бұл негізгі деректерге қатысты барлық мәселе қазір шешілді дегенді білдіре ме?
15. Жақын арада негізгі есеп жүйелерін ауыстырамыз деп күтілуде. Деректер қоймасы дереккөзді өзгертуге дайын болуы керек пе? Бұған қалай қол жеткізуге болады?
16. Бізге метадеректер керек пе? Мұнымен не айтқымыз келеді? Оларды нақты қай жерде қолдануға болады? Оны қалай жүзеге асыруға болады? Мен оларды «бір жерде» сақтауым керек пе?
17. Біздің тұтынушылар өз талаптары мен тілектері бойынша өте тұрақсыз - бір нәрсе үнемі өзгеріп отырады. Жалпы, біздің бизнес өте қарқынды. Біз бірдеңе істеп жатқанда, ол қажетсіз болып қалады. Нәтижені мүмкіндігінше тез беретіндей етіп қалай жасай аламыз - ыстық пирожныйлар сияқты?
18. Пайдаланушылар жауап беруді талап етеді. Бірақ біз негізгі жүктеу процестерін жиі іске қоса алмаймыз, өйткені бұл бастапқы жүйелерді жүктейді (өнімділікке нашар әсер етеді) - сондықтан біз қосымша деректер ағындарын іліп қоямыз - олар бізге қажет нәрсені нүктелік түрде қабылдайды. Рас, ағындар көп. Содан кейін біз кейбір деректерден бас тартамыз. Оның үстіне конвергенция мәселесі туындайды. Бірақ басқа амал жоқ...

Қатты сынғыштық

Біраз уақыттан кейін сурет келесідей:
«Міне, қойма. Ал қол тигізбесеңіз жұмыс істейді. Біз бір нәрсені өзгертуіміз керек болғанда проблемалар туындайды ».

Бізге өзгеріс келеді, оның әсерін біз бағалай алмаймыз және түсіне алмаймыз (өйткені біз мұндай құралдарды басынан бастап жүйеге енгізбегенбіз) - және тәуекелге бармау үшін біз бар нәрсеге қол тигізбейміз, бірақ біз бүйір жағына тағы бір кеңейту жасаймыз, екіншісін жасаймыз, сонымен қатар - шешімімізді қараңғы жерлерге немесе Латын Америкасында айтқандай, полицияның кіруге қорқатын «фавелаларға» айналдырамыз.
Өз жүйесіне бақылауды жоғалту, хаос сезімі бар. Бар процестерді қолдау және мәселелерді шешу үшін көбірек қол қажет. Ал өзгерістер жасау барған сайын қиындап барады. Басқаша айтқанда, жүйе стресске тұрақсыз, өзгерістерге бейімделмейтін болады. Оның үстіне, ешкімде «карта» болмағандықтан, «фарвейді» білетін кейіпкерлерге қатты тәуелділік бар.

Нысанның бұл қасиеті – хаос, кездейсоқ оқиғалар мен күйзелістердің әсерінен құлау – Нассим Николас Талеб шақырады. сынғыштық ... Және де қарама-қарсы ұғымды енгізеді: сынғыштық – объект күйзеліс пен апаттан құламай, одан тікелей пайда көргенде... («Қарсылық. Хаостан қалай пайда табуға болады»)
Әйтпесе, оны шақыруға болады бейімделушілік немесе өзгерістерге төзімділік .

Бұл контексте бұл нені білдіреді? АТ жүйелерінің «хаос көздері» қандай? Ал IT архитектурасы тұрғысынан «хаосқа капиталдандыру» нені білдіреді?
Ойға бірінші келетін ой – сырттан келетін өзгерістер. Жүйе үшін сыртқы әлем дегеніміз не? Әсіресе сақтау үшін. Әрине, ең алдымен - дүкенге арналған деректер көздері жағынан өзгерістер:

• кіріс деректердің форматтарын өзгерту;
• деректер көздерінің кейбір жүйелерін басқаларымен ауыстыру;
• жүйелерді біріктіру үшін ережелерді/платформаларды өзгерту;
• мәліметтерді интерпретациялауды өзгерту (форматтар сақталады, деректермен жұмыс істеу логикасы өзгереді);
• егер интеграция деректер деңгейінде орындалса, деректер үлгісін өзгерту (деректер базасындағы транзакциялар журналының файлдарын талдау);
• деректер көлемінің өсуі - бастапқы жүйеде деректер аз болған кезде және жүктеме жоғары болмаса - оны кез келген уақытта алуға болатын, ерікті түрде ауыр сұраумен, деректер мен жүктеме өсті - қазір қатаң шектеулер бар ;
• және т.б.

Қойма тұтынушыларының бастамасымен маңызды өзгерістер (талаптардың өзгеруі):

• бұрын есепті құру үшін деректер жеткілікті болды - енді қосымша өрістерді немесе жаңа деректер көзін қосу қажет болды;
• бұрын енгізілген деректерді өңдеу әдістері ескірген - алгоритмдерді және оған әсер ететін барлық нәрсені қайта өңдеу керек;
• Бұрын ақпарат тақтасындағы сөздік атрибутының ағымдағы мәніне барлығы қанағаттанған - енді талданатын факт/оқиға сәтінде өзекті мән талап етіледі;
• бұрын болмаған деректерді сақтау тарихының тереңдігі туралы талап болды - деректерді 2 жыл емес, 10 жыл бойы сақтау;
• бұрын «күннің/кезеңнің» соңы бойынша деректер жеткілікті болды - енді сізге «күн ішінде» немесе белгілі бір оқиға кезінде (мысалы, несиелік өтінім бойынша шешім қабылдау үшін) деректер күйі қажет. Базель II);
• бұрын біз кешегі (Т-1) немесе одан кейінгі деректер бойынша есеп берумен қанағаттанатынбыз, енді бізге T0 қажет;
• және т.б.

Бірақ бұл бәрі емес.
Өзгергіштік туралы айтатын болсақ, біз, ең алдымен, сыртқы факторларды еске түсіреміз. Өйткені, біз іштей бәрін басқара аламыз, бізге солай көрінеді, солай ма? Иә және жоқ. Иә, әсер ету аймағынан тыс факторлардың көпшілігі сыртқы. Бірақ «ішкі энтропия» да бар. Дәл оның болуына байланысты біз кейде «0 нүктесіне» оралуымыз керек. Ойынды басынан бастаңыз.
Өмірде біз көбінесе нөлден бастаймыз. Неліктен бұл бізге ерекше? Және бұл шынымен де жаман ба?
IT-ға қолданылады. Жүйенің өзі үшін - бұл өте жақсы болуы мүмкін - жеке шешімдерді қайта қарау мүмкіндігі. Әсіресе, біз мұны жергілікті жерде жасай алатын болсақ. Рефакторинг – жүйені дамыту процесінде мезгіл-мезгіл пайда болатын «вебті» ашу процесі. Басына оралу пайдалы болуы мүмкін. Бірақ оның бағасы бар.
Құзыретті архитектураны басқару кезінде бұл баға төмендейді - жүйені әзірлеу процесінің өзі басқарылатын және ашық болады. Қарапайым мысал: модульдік принципі сақталса, сыртқы интерфейстерге әсер етпестен бөлек модульді қайта жазуға болады. Және бұл монолитті құрылыммен жасалмайды.

Жүйенің сынғыштығы оған енгізілген архитектурамен анықталады. Және дәл осы қасиеті оны бейімделгіш етеді.
Біз сөйлескен кезде адаптивті архитектура- бұл жүйенің өзгерістерге бейімделе алатынын айтамыз, бірақ біз архитектураның өзін үнемі өзгертіп отырамыз дегенді білдірмейміз. Керісінше, архитектура неғұрлым тұрақты және тұрақты болса, оны қайта қарауды талап ететін талаптар аз болса, жүйе соғұрлым бейімделеді.

Бүкіл архитектураны қайта қарауды қамтитын шешімдер әлдеқайда жоғары бағаға ие болады. Және оларды қабылдау үшін сізде өте жақсы себептер болуы керек. Мысалы, мұндай негіздеме бар архитектурада жүзеге асырылмайтын талап болуы мүмкін. Содан кейін олар айтады - архитектураға әсер ететін талап пайда болды.
Сонымен, біз өзіміздің «қызғыштыққа қарсы шектеулерді» білуіміз керек. Архитектура «вакуумда» дамымайды – ол қазіргі талаптар мен күтуге негізделген. Ал егер жағдай түбегейлі өзгерсе - біз қазіргі архитектурадан шығып кеткенімізді түсінуіміз керек - және біз оны қайта қарап, басқа шешімді әзірлеуіміз керек - және өтпелі жолдарды ойластыруымыз керек.
Мысалы, біз күннің соңында жадта деректер әрқашан қажет болады деп болжадық, стандартты жүйелік интерфейстерді (көріністер жиынтығы арқылы) пайдаланып күнделікті деректерді қабылдаймыз. Содан кейін тәуекелдерді басқару бөлімінен мәліметтерді күннің соңында емес, несие беру туралы шешім қабылданған кезде алу қажеттілігі туралы сұраныс келді. «Қарсылмағанды ​​тартуға» тырысудың қажеті жоқ - сіз бұл фактіні мойындауыңыз керек - соғұрлым тезірек жақсы. Мәселені шешуге мүмкіндік беретін тәсілмен жұмыс істей бастаңыз.
Бұл жерде өте нәзік сызық бар - егер біз тек «қазіргі уақыттағы талаптарды» ескерсек және бірнеше қадам алға (және бірнеше жыл алға) қарамасақ, онда біз архитектураға әсер ететін талапты кешіктіру қаупін арттырамыз - және біздің өзгерістің бағасы өте жоғары болады. Кішкене алға қарай - біздің көкжиегіміздің шекарасында - әлі ешкімге зиян тигізген жоқ.

«Сақтау ертегісіндегі» жүйенің мысалы нәзік дизайн тәсілдеріне негізделген өте дірілдеген жүйенің бір мысалы ғана. Ал егер бұл орын алса, жүйенің дәл осы класы үшін жойылу өте тез жүреді.
Неге олай айта аламын? Репозиторийлер тақырыбы жаңа емес. Осы уақыт ішінде жасалған тәсілдер мен инженерлік тәжірибелер дәл осы мақсатқа бағытталған - жүйенің өміршеңдігін сақтауға.
Қарапайым мысал: Ұшып-қону жобаларының сәтсіздігінің ең көп тараған себептерінің бірі интеграциялық интерфейстерді келіспестен әзірлеудің бастапқы жүйелеріне жадты құруға тырысу — деректерді кестелерден тікелей алуға әрекет жасау. Нәтижесінде біз әзірлеуге кірістік - осы уақыт ішінде бастапқы дерекқор өзгерді - және репозиторийдегі жүктеу ағындары жұмыс істемейтін болды. Бір нәрсені қайта жасауға тым кеш. Егер сіз қойманың ішінде бірнеше қабат кестелер жасау арқылы өзіңізді әлі қорғамаған болсаңыз, онда бәрін тастап, басынан бастауға болады. Бұл бір ғана мысал және қарапайым мысалдардың бірі.

Талебтің сынғыш және сынғыштық критерийі қарапайым. Басты төреші – уақыт. Жүйе уақыт сынына төтеп беріп, өзінің «өміршеңдігін» және «бұзылмайтындығын» көрсетсе – оның сынғыштық қасиеті бар.
Егер жүйені жобалау кезінде біз талап ретінде сынғыштықты ескерсек, бұл жүйені «сырттан келген хаосқа» да, «іштен келген хаосқа» да бейімделгіш ететін оның архитектурасын құрудың осындай тәсілдерін қолдануға итермелейді. . Ал, сайып келгенде, жүйенің қызмет ету мерзімі ұзағырақ болады.
Ешқайсымыз «қайтадан үй» салғымыз келмейді. Және өзіңізді алдамаңыз, бұл бүгінде басқа жол емес. Адамның кез келген уақытта, әсіресе дағдарыс кезінде бірнеше қадам алға қарауы қалыпты жағдай.

Деректер қоймасы дегеніміз не және оны не үшін жасап жатырмыз

Деректер қоймасы қажет деген ойға адамдар қалай келді? Және олардың жай ғана «өте үлкен дерекқордан» айырмашылығы неде?
Ұзақ уақыт бұрын, әлемде жай ғана «бизнес-мәліметтерді өңдеу жүйелері» болған кезде, АТ жүйелерін front-end oltp жүйелері, бэк-офис dss, мәтінді өңдеу жүйелері, деректер қоймалары және т.б. сияқты сыныптарға бөлу болған жоқ.
Дәл осы уақытта Майкл Стоунбрейкер бірінші реляциялық дерекқор қозғалтқышы Ingres-ті жасады.
Бұл дербес компьютерлер дәуірі компьютерлік индустрияға құйын сияқты еніп, сол кездегі IT қоғамдастықтың барлық идеяларын мәңгілікке өзгерткен уақыт болды.

Ол кезде Clipper, dBase және FoxPro сияқты жұмыс үстелі класындағы ДҚБЖ негізінде жазылған кәсіпорын қолданбаларын табу оңай болды. Ал клиент-сервер қосымшалары мен МҚБЖ нарығы тек қана қарқын алды. Деректер базасының серверлері бірінен соң бірі пайда болды, олар АТ кеңістігінде өз орнын ұзақ уақыт алады - Oracle, DB2 және т.б.
Ал «деректер базасының қосымшасы» термині кең таралған. Мұндай өтініш нені қамтиды? Жеңілдетілген – пайдаланушылар бір уақытта ақпаратты енгізе алатын кейбір енгізу пішіндері, «батырма арқылы» немесе «кесте бойынша» іске қосылған кейбір есептеулер, сондай-ақ экранда көруге болатын немесе файл ретінде сақталатын және мөрге жіберілетін кейбір есептер.
«Ешқандай ерекше ештеңе жоқ - жай ғана қосымша, жай ғана деректер базасы», - деп атап өтті менің тәлімгерлерімнің бірі мансабымның басында. - Демек, ерекше ештеңе жоқ па? – Мен сонда ойладым.

Мұқият қарасаңыз, әлі де кейбір ерекшеліктер бар. Пайдаланушылар өскен сайын кіріс ақпарат көлемі артады, жүйеге жүктеме артқан сайын оны әзірлеушілер, дизайнерлер өнімділікті қолайлы деңгейде ұстау үшін кейбір «трюктерге» барады. Біріншісі – монолитті «бизнес деректерін өңдеу жүйесін» пайдаланушыларды on-line режимінде қолдайтын бухгалтерлік қосымшаға және деректерді пакеттік өңдеуге және есеп беруге арналған жеке қосымшаға бөлу. Бұл қолданбалардың әрқайсысының өз дерекқоры бар және тіпті әртүрлі жүктеме түрлеріне арналған әртүрлі параметрлері бар дерекқор серверінің бөлек данасында орналастырылған - OLTP және DSS. Және деректер ағындары олардың арасында түзетіледі.

Барлығы ма? Мәселе шешілген сияқты. Әрі қарай не болады?
Содан кейін компаниялар өседі, олардың ақпараттық қажеттіліктері көбейеді. Сыртқы әлеммен қарым-қатынастар саны да артып келеді. Нәтижесінде, барлық процестерді толығымен автоматтандыратын бір үлкен қолданба емес, әртүрлі өндірушілердің бірнеше әртүрлі. Компанияда ақпарат – деректер көзі жүйелерін генерациялайтын жүйелердің саны артып келеді. Ал ерте ме, кеш пе, әртүрлі жүйелерден алынған ақпаратты көру және салыстыру қажеттілігі туындайды. Компанияда деректер қоймалары осылай пайда болады - жүйелердің жаңа класы.
Бұл жүйелер класының жалпы қабылданған анықтамасы келесідей.

Деректер қоймасы (немесе деректер қоймасы)- ұйымда шешім қабылдауды қолдау мақсатында есептерді дайындау және бизнесті талдау үшін арнайы әзірленген және әзірленген пәнге бағытталған ақпараттық деректер базасы

Мәліметтер қоймасының негізгі ерекшеліктері

Біріншіден, бұл үлкен көлемдер. Өте үлкен. VLDB - жетекші жеткізушілер өз өнімдерін пайдалану бойынша ұсыныстарын бергенде мұндай жүйелерді осылай атайды. Компанияның барлық жүйелерінен деректер осы үлкен дерекқорға түседі және оқулықтарда айтылғандай «мәңгі және өзгеріссіз» сақталады (тәжірибеде өмір күрделірек болып шығады).

Екіншіден, бұл тарихи деректер – «Корпоративтік жады» - деректер қоймалары деп аталады. Репозиторийлерде уақытпен жұмыс істеу тұрғысынан бәрі өте қызықты. Бухгалтерлік есеп жүйелерінде деректер қазіргі уақытта өзекті болып табылады. Содан кейін пайдаланушы операцияның қандай да бір түрін орындайды - және деректер жаңартылады. Сонымен қатар, өзгерістер тарихы сақталмауы мүмкін - бұл бухгалтерлік есеп тәжірибесіне байланысты. Мысалы, банк шотындағы теңгерімді алайық. Бізді «қазір», күннің соңында немесе қандай да бір оқиға кезінде (мысалы, ұпайды есептеу кезінде) ағымдағы теңгерім қызықтыруы мүмкін. Алғашқы екеуін шешу оңай болғанымен, соңғысы ерекше күш-жігерді қажет етеді. Жадпен жұмыс істейтін пайдаланушы өткен кезеңдерге сілтеме жасай алады, оларды ағымдағы кезеңмен салыстыра алады және т.б. Дәл осы уақытқа байланысты мүмкіндіктер деректер қоймаларын есеп жүйесінен айтарлықтай ажыратады - уақыт осінің әртүрлі нүктелеріндегі деректердің күйін бұрынғы белгілі бір тереңдікке дейін алу.

Үшіншіден, солай шоғырландыру және деректерді унификациялау ... Олардың бірлескен талдауы мүмкін болуы үшін оларды ортақ формаға келтіру керек - деректердің бірыңғай моделі , фактілерді бірыңғай анықтамалықтармен салыстыру. Мұнда бірнеше аспектілер мен қиындықтар болуы мүмкін. Ең алдымен - тұжырымдамалық - бір термин бойынша әр бөлімдегі әр түрлі адамдар әртүрлі нәрсені түсінеді. Және керісінше - мәні бойынша бір нәрсені басқаша атау. Белгілі бір пайдаланушы тобының нақты көзқарасын сақтай отырып, «бір көзқарасты» қалай қамтамасыз етуге болады?

Төртіншіден, бұл жұмыс деректер сапасы ... Деректерді қоймаға жүктеу процесінде олар тазартылады, жалпы түрлендірулер мен түрлендірулер орындалады. Жалпы түрлендірулер бір жерде жасалуы керек - содан кейін әртүрлі есептерді құру үшін пайдаланылады. Бұл бизнес пайдаланушыларды, әсіресе бір-бірімен келіспейтін әртүрлі бөлімдердің нөмірлерімен үстелге әкелінетін басшыларды тітіркендіретін сәйкессіздіктерді болдырмайды. Деректер сапасының нашарлығы есептердегі қателер мен сәйкессіздіктерді тудырады, оның салдары деңгейдің төмендеуі болып табылады пайдаланушы сенімі бүкіл жүйеге, тұтастай алғанда бүкіл аналитикалық қызметке.

Архитектуралық концепция

Диаграммада көрсетілгендей, тұжырымдамалық түрде келесі қабаттарды таңдаңыз. Деректерді сақтау аймағын (толтырылған тіктөртбұрышпен көрсетілген) және деректерді жүктеу бағдарламалық құралын (шартты түрде бірдей түсті көрсеткілермен көрсетілген) қамтитын үш негізгі қабат. Сондай-ақ көмекші – сервистік деңгей, дегенмен, ол өте маңызды байланыстырушы рөл атқарады – деректер жүктемесін басқару және сапаны бақылау.

Бастапқы деректер деңгейі – бастапқы деректер деңгейі (немесе сахналау , немесе операциялық қабат ) - бастапқы жүйелерден жүктеуге және бастапқы ақпаратты түрлендірусіз сақтауға арналған - түпнұсқа сапада және өзгерістердің толық тарихын қолдау.
Бұл қабаттың міндеті- деректер көздерінің физикалық құрылымынан сақтаудың кейінгі қабаттарын абстракциялау, деректерді жинау әдістері және өзгерістердің дельтасын бөлу әдістері.

Core Data Layer – негізгі жады - сақтауды жай «пакеттік интеграция платформасынан» немесе «үлкен деректер қоқысынан» ерекшелендіретін жүйенің орталық құрамдас бөлігі, өйткені оның негізгі рөлі деректерді консолидациялауәртүрлі көздерден, біркелкі құрылымдарға дейін қысқарту, кілттер. Дәл ядроға жүктеу кезінде негізгі жұмыс деректер сапасы мен жалпы түрлендірулермен орындалады, бұл өте күрделі болуы мүмкін.
Бұл қабаттың міндеті- өз тұтынушыларын деректер көздерінің логикалық құрылғысының ерекшеліктерінен және әртүрлі жүйелердің мәліметтерін салыстыру қажеттілігінен абстракциялау, деректердің тұтастығы мен сапасын қамтамасыз ету.

Data Mart Layer – аналитикалық витриналар - негізгі функциясы деректерді талдауға ыңғайлы құрылымдарға түрлендіру болып табылатын құрамдас бөлік (егер BI витриналармен жұмыс істесе, бұл, әдетте, өлшемді модель) немесе тұтынушы жүйесінің талаптарына сәйкес.
Әдетте, деректер марттары деректерді ядродан алады - сенімді және тексерілген көз ретінде - яғни. деректерді бір пішінге келтіру үшін осы құрамдастың қызметін пайдаланыңыз. Біз мұндай көрмелерді шақырамыз тұрақты ... Кейбір жағдайларда, дүкен сөрелері бастапқы деректермен (бастапқы кілттерде) жұмыс істейтін кезеңнен тікелей деректерді ала алады. Бұл тәсіл әдетте әртүрлі жүйелерден деректерді біріктіру талап етілмейтін және деректер сапасынан гөрі тиімділік қажет болатын жергілікті тапсырмалар үшін қолданылады. Мұндай дисплей жағдайлары деп аталады жұмыс істейді ... Кейбір аналитикалық көрсеткіштер өте күрделі есептеу әдістеріне ие болуы мүмкін. Сондықтан мұндай тривиальды емес есептеулер мен түрлендірулер үшін деп аталатын қосалқы дисплей жағдайлары .
Қабат тапсырмасын көрсету- нақты тұтынушының – BI платформасының, пайдаланушылар тобының немесе сыртқы жүйенің талаптарына сәйкес деректерді дайындау.

Жоғарыда сипатталған қабаттар тұрақты деректерді сақтау аймағынан, сондай-ақ деректерді жүктеуге және түрлендіруге арналған бағдарламалық модульден тұрады. Бұл қабаттар мен аймақтарға бөлу қисынды. Физикалық тұрғыдан алғанда, бұл құрамдастардың орындалуы әртүрлі болуы мүмкін - егер бұл тиімдірек болса, әртүрлі қабаттарда деректерді сақтау немесе түрлендіру үшін әртүрлі платформаларды пайдалануға болады.
Сақтау аймақтарында деректерді түрлендіру процесінде қолданылатын техникалық (буферлік кестелер) және мақсатты кестелертұтынушы құрамдас бөлікке сілтеме жасайтын. Мақсатты кестелерді көріністермен «жабу» жақсы тәжірибе. Бұл жүйенің кейінгі қызмет көрсетуі мен дамуын жеңілдетеді. Барлық үш қабаттың мақсатты кестелеріндегі деректер арнайы техникалық өрістермен (мета-атрибуттармен) белгіленген, олар деректерді жүктеу процестерін қолдау үшін, сонымен қатар қоймадағы деректер ағындарының ақпараттық аудитін қамтамасыз ету үшін қолданылады.

Сондай-ақ, барлық қабаттар үшін қызмет көрсету функцияларын қамтамасыз ететін арнайы компонент (немесе компоненттер жиынтығы) ерекшеленеді. Оның негізгі міндеттерінің бірі басқару функциясы болып табылады - жоғарыда сипатталған қабаттардың әрқайсысын іске асырудың әртүрлі нұсқаларын пайдалану құқығын қалдырып, тұтастай алғанда бүкіл жүйе үшін «ойынның біркелкі ережелерін» қамтамасыз ету. деректерді жүктеу және өңдеу үшін әртүрлі технологияларды, әртүрлі сақтау платформаларын және т.б. Оны шақырайық қызмет көрсету деңгейі ... Ол бизнес деректерін қамтымайды, бірақ оның өзіндік сақтау құрылымдары бар – оның құрамында метадеректер аймағы, сондай-ақ деректер сапасымен жұмыс істеу аймағы (және оған тағайындалған функцияларға байланысты басқа құрылымдар болуы мүмкін).

Жүйені жеке құрамдас бөліктерге мұндай нақты бөлу жүйенің дамуын басқару мүмкіндігін айтарлықтай арттырады:

• сол немесе басқа компоненттің функционалдығын әзірлеушіге қойылатын тапсырманың күрделілігі төмендейді (ол бір уақытта сыртқы жүйелермен интеграция мәселелерін шешпеуі керек, сонымен қатар деректерді тазарту процедуралары туралы ойлануы керек және деректерді оңтайлы ұсыну туралы ойлануы керек); тұтынушылар үшін) - тапсырманы бөлшектеу, бағалау және шағын жеткізуді орындау оңайырақ;
• Сіз әртүрлі орындаушылардың (тіпті командалардың немесе мердігерлердің) жұмысына қосыла аласыз - өйткені бұл тәсіл бір-біріне өзара ықпалын азайта отырып, тапсырмаларды тиімді параллельдеуге мүмкіндік береді;
• тұрақты кезеңнің болуы бүкіл тақырып аймағы үшін бүкіл өзегін немесе дүкен сөрелерін жобаламай-ақ деректер көздерін жылдам қосуға мүмкіндік береді, содан кейін басымдықтарға сәйкес қалған қабаттарды құруды біртіндеп аяқтауға мүмкіндік береді (сонымен қатар, деректер қазірдің өзінде сақтауда болады - қол жетімді жүйелік талдаушылар, бұл сақтауды кейінгі дамыту міндеттерін айтарлықтай жеңілдетеді);
• ядроның болуы деректер сапасымен барлық жұмыстарды (сонымен қатар мүмкін болатын қателер мен қателерді) дүкен сөрелерінен және соңғы пайдаланушыдан жасыруға мүмкіндік береді, ең бастысы – бұл компонентті дүкен сөрелері үшін бір деректер көзі ретінде пайдалану арқылы деректерден аулақ бола аласыз. ортақ алгоритмдерді бір жерде орындауға байланысты конвергенция есептері;
• Марттарды бөлектеу әртүрлі бөлімдердің пайдаланушыларында болуы мүмкін деректерді түсінудің айырмашылықтары мен ерекшеліктерін ескеруге мүмкіндік береді және олардың BI талаптарына арналған дизайны жинақталған сандарды шығаруға ғана емес, сонымен қатар егжей-тегжейлі мүмкіндіктер беру арқылы деректерді тексеруді қамтамасыз етуге мүмкіндік береді. бастапқы көрсеткіштерге;
• қызмет көрсету деңгейінің болуы деректерді түпкілікті талдауды (деректер линиясы) орындауға, деректер аудитінің бірыңғай құралдарын пайдалануға, өзгерістердің дельтасын бөлектеуге жалпы тәсілдерге, деректер сапасымен жұмыс істеуге, жүктемені басқаруға, бақылау және қателерді диагностикалауға мүмкіндік береді. , және мәселені шешуді жылдамдатады.

• бастапқы жүйелер тарапынан өзгерістер сахналау кезінде өңделеді - ядрода осы кезеңдік кестелер әсер ететін ағындар ғана өзгертіледі, дүкен сөрелеріне әсері аз немесе жоқ;
• тұтынушылар тарапынан талаптардың өзгеруі көбінесе дүкен сөрелерінен өңделеді (егер бұл дүкенде әлі жоқ қосымша ақпаратты қажет етпесе).

Жүйе өзегі

Бұл құрамдастың болуы бастапқы жүйелерден алынған бастапқы деректерді жалпы ережелер мен алгоритмдерді сақтай отырып, белгілі бір бірыңғай пішімге түрлендіретін деректер ағындарын қайта пайдалануға мүмкіндік береді және сол функционалдылықтың орындалуын әрбір қолданба дүкені үшін бөлек қайталамауға мүмкіндік береді. ресурстарды тиімсіз пайдаланудан басқа, деректердегі сәйкессіздіктерді де тудыруы мүмкін.
Репозиторийдің өзегі деректер үлгісінде жүзеге асырылады, жалпы жағдайда бастапқы жүйелердің үлгілерінен де, тұтынушылардың форматтары мен құрылымдарынан да ерекшеленеді.

Қойма негізгі үлгісі және кәсіпорын деректер үлгісі

Миф 1. Кәсіпорын деректерінің үлгісі мыңдаған нысандардан (кестелерден) тұратын үлкен үлгі болып табылады.
Шын мәнінде. Кез келген пәндік салада, кез келген бизнес доменінде, кез келген компанияның деректерінде, тіпті ең күрделі, базалық субъектілер аз - 20-30.

Миф 2. Ешқандай «меншікті үлгіні» әзірлеудің қажеті жоқ - біз салалық анықтамалық үлгіні сатып аламыз - және біз бәрін соған сәйкес жасаймыз. Біз ақша жұмсаймыз - бірақ біз кепілдендірілген нәтиже аламыз.
Шын мәнінде. Анықтамалық үлгілер өте пайдалы болуы мүмкін, себебі осы саланы модельдеудегі салалық тәжірибені қамтиды. Олардан сіз идеяларды, тәсілдер, ат қою тәжірибесін алуға болады. Маңызды нәрсені назардан тыс қалдырмау үшін аймақтың «жабу тереңдігін» тексеріңіз. Бірақ біз мұндай модельді қораптан тыс пайдалана алатынымыз екіталай - дәл солай. Бұл, мысалы, ERP жүйесін (немесе CRM) сатып алу және оны «өзіңе қатайтпай» жүзеге асыру сияқты миф. Мұндай модельдердің құндылығы олардың осы нақты бизнестің, нақты компанияның шынайылығына бейімделуінде туады.

Миф 3. Негізгі репозиторий үлгісін әзірлеу бірнеше айға созылуы мүмкін, осы уақыт ішінде жоба іс жүзінде тоқтатылады. Бұған қоса, бұл ақылсыз кездесулер мен көптеген адамдарды қажет етеді.
Шын мәнінде. Репозиторий үлгісін репозиториймен бірге итеративті түрде, бөлшектеп әзірлеуге болады. Ашық аумақтар үшін «кеңейту нүктелері» немесе «түтіктер» орнатылады. кейбір «әмбебап конструкциялар» қолданылады. Сонымен қатар, сіз 4 кестеден тұратын суперәмбебап нәрсені алмас үшін қашан тоқтату керектігін білуіңіз керек, оған «деректерді қою» да, оны алу да қиын (одан да қиын). Және бұл өнімділік тұрғысынан өте оңтайлы емес.

Модельді әзірлеуге шынымен уақыт қажет. Бірақ бұл «субъектілерді сызу» үшін жұмсалған уақыт емес - бұл деректердің қалай орналасатынын түсіну, пәндік аймақты талдау үшін қажет уақыт. Сондықтан да бұл процеске сарапшылар өте тығыз араласып, түрлі бизнес мамандары да тартылады. Және бұл нүктелік, таңдамалы түрде жасалады. Ал ессіз адамдардың қатысуымен жиналыстар ұйымдастыру, үлкен сауалнамалар жіберу және т.б. арқылы емес.
Жақсы бизнес және жүйелік талдау негізгі қойма үлгісін құрудың кілті болып табылады. Түсінетін нәрсе көп: деректер қай жерде (қандай жүйелерде) жасалады, ол қалай жұмыс істейді, қандай бизнес-процестерде айналады және т.б. Сапалық талдау ешқашан бір жүйеге зиян келтірген емес. Керісінше, біздің түсінігіміздегі «ақ дақтардан» проблемалар туындайды.

Деректер моделін әзірлеу жаңа нәрсені ойлап табу және ойлап табу процесі емес. Іс жүзінде деректер моделі компанияда бұрыннан бар. Ал жобалау процесі «қазбаға» көбірек ұқсайды. Модель корпоративтік деректердің «топырағынан» мұқият және мұқият алынып, құрылымдық пішінге қойылады.

Миф 4. Біздің компанияда біздің бизнесіміз соншалықты серпінді, және бәрі соншалықты тез өзгереді, сондықтан модель жасау бізге пайдасыз - жүйенің осы бөлігін іске қосқанға дейін ол ескіреді.
Шын мәнінде. Еске салайық, негізгі фактор тұрақтылық болып табылады. Ең бастысы, модельдің топологиясы. Неліктен? Өйткені дәл осы құрамдас орталық болып табылады және қалғанның бәріне әсер етеді. Тұрақтылық сонымен қатар ядро ​​моделіне қойылатын талап болып табылады. Модель тым тез ескірсе, ол дұрыс құрастырылмаған. Оны дамыту үшін қате тәсілдер мен «ойын ережелері» таңдалды. Және бұл да сапалы талдау мәселесі. Корпоративтік модельдің негізгі субъектілері сирек өзгереді.
Бірақ егер біздің ойымызға кондитерлік өнімдерді сататын компания үшін «Өнім» анықтамалығының орнына «Тәттілер», «Торттар» және «Бәліштер» дайындаңыз. Содан кейін тауарлар тізімінде пицца пайда болған кезде - иә, сізге көптеген жаңа кестелерді енгізу қажет болады. Және бұл тек көзқарас мәселесі.

Миф 5. Корпоративтік үлгіні құру – өте күрделі, күрделі және жауапты іс. Ал қателесу қорқынышты.
Шын мәнінде. Негізгі модель, ол тұрақты болуы керек болса да, әлі де «металлға құйылған» емес. Кез келген басқа дизайн шешімдері сияқты, оның құрылымын қайта қарауға және өзгертуге болады. Оның бұл қасиетін ұмытпау керек. Бірақ бұл «сен онымен дем ала алмайсың» дегенді білдірмейді. Және бұл қайта өңдеуге жоспарланған уақытша шешімдер мен «түтіктер» қолайсыз дегенді білдірмейді.

Миф 6. Егер біздің деректер көзіміз, мысалы, анықтамалық деректер жүйесі (немесе деректерді басқарудың негізгі жүйесі - MDM) болса, онда ол корпоративтік үлгіге ыңғайлы түрде сәйкес болуы керек (әсіресе егер ол жақында жобаланған болса және оны жасауға уақыт болмаса) сатып алу «жақ», «дәстүрлер» Және уақытша саятшылықтар). Бұл жағдайда бізге ядро ​​моделі қажет емес екен?
Шын мәнінде. Иә, бұл жағдайда репозиторийдің негізгі моделін құру айтарлықтай жеңілдетілді - бері біз дайын жоғары деңгейлі концептуалды үлгіні ұстанамыз. Бірақ бұл мүлдем жоққа шығарылмайды. Неліктен? Өйткені белгілі бір жүйенің моделін құру кезінде оның кейбір өзіндік ережелері қолданылады - кестелердің қандай түрлерін пайдалану керек (әр нысан үшін), деректерді қалай нұсқалау керек, тарихты қандай түйіршіктілікпен сақтау керек, қандай мета-атрибуттар (техникалық өрістер) пайдалану) т.б.

Сонымен қатар, бізде анықтамалық деректер мен МДМ қаншалықты тамаша және жан-жақты жүйесі болса да, әдетте, басқа есеп жүйелерінде «шамамен бірдей» жергілікті анықтамалықтардың болуымен байланысты нюанстар болады. Ал бұл мәселе, біз қаласақ та, қаламасақ та, репозиторийде шешілуі керек - бұл жерде есептер мен талдаулар жиналады.

Негізгі деректер деңгейі (немесе тарихи кезең немесе операциялық деңгей)

Бұл қабаттағы деректер бастапқы жүйеге мүмкіндігінше жақын құрылымдарда сақталады - бастапқы деректерді мүмкіндігінше бастапқы пішініне жақын сақтау үшін. Бұл компоненттің тағы бір атауы «операциялық деңгей».
Неліктен «сахналау» деген жақсы қалыптасқан терминді қолданбасқа? Өйткені, бұрын, «үлкен деректер және VLDB дәуіріне» дейін дискілік кеңістік өте қымбат болды - және көбінесе бастапқы деректер, егер сақталған болса, шектеулі уақыт кезеңі үшін ғана болды. Және көбінесе «сценировка» атауын атайды тазалауға боладыбуфер.
Қазір технологиялар алға жылжыды - және біз барлық бастапқы деректерді сақтап қана қоймай, оларды мүмкін болатын түйіршіктілік дәрежесімен тарихтауға мүмкіндік аламыз. Бұл деректердің өсуін бақыламау керек дегенді білдірмейді және пайдалану «температурасына» байланысты деректерді сақтау құнын оңтайландыру, ақпараттың өмірлік циклін басқару қажеттілігін жоймайды - т. арзанырақ медиа және сақтау платформаларына сұраныс аз болатын «суық деректерді» алу.

«Тарихи қойылымның» болуы бізге не береді:

• қателер жасау мүмкіндігі (құрылымдарда, түрлендіру алгоритмдерінде, тарихтың түйіршіктілігінде) - сақтауға арналған қолжетімділік аймағында бастапқы деректерді толығымен тарихтандырғаннан кейін біз әрқашан кестелерімізді қайта жүктей аламыз;
• ойлау мүмкіндігі - біз сақтауды дамытудың осы нақты итерациясында ядроның үлкен фрагментін әзірлеуге уақыт бөле аламыз, өйткені біздің қойылымымызда кез келген жағдайда болады және біркелкі уақыт көкжиегі бар («тарих анықтамасының» бір нүктесі болады);
• талдау мүмкіндігі - біз тіпті бастапқыда жоқ деректерді де сақтаймыз - олар сол жерде қайта жазылуы мүмкін, мұрағатқа барады және т.б. - бізде олар талдау үшін қолжетімді болып қалады;
• ақпараттық аудит мүмкіндігі - ең егжей-тегжейлі бастапқы ақпараттың арқасында біз жүктеп алудың біз үшін қалай жұмыс істегенін, ақырында мұндай сандарға қол жеткізгенін анықтай аламыз (ол үшін бізде мета-атрибуттармен таңбалау керек және сәйкес жүктеу жұмыс істейтін метадеректер - бұл қызмет деңгейімен шешіледі).

• бұл қабаттың транзакциялық тұтастығына талаптар қою ыңғайлы болар еді, бірақ тәжірибе көрсеткендей, бұған қол жеткізу қиын (бұл бұл салада біз ата-аналық және еншілес кестелердің анықтамалық тұтастығына кепілдік бермейтінімізді білдіреді) - тұтастықты теңестіру келесіде орын алады қабаттар;
• бұл қабат өте үлкен көлемдерді қамтиды (сақтаудағы ең көлемді - аналитикалық құрылымдардың барлық артықтығына қарамастан) - және сіз мұндай көлемдерді - жүктеме тұрғысынан да, сұраныстар бойынша да өңдей білуіңіз керек (әйтпесе, сіз байыпты түрде жасай аласыз). бүкіл жадтың өнімділігін нашарлатады).

Екіншіден, бұл процестер, көріп отырғаныңыздай, өте қарапайым - логика тұрғысынан тривиальды деп айтуға болады. Бұл олардың өте жақсы оңтайландырылған және параметрленген болуы мүмкін екенін білдіреді, бұл біздің жүйеге жүктемені азайтады және көздерді қосу процесін жылдамдатады (әзірлеу уақыты).
Бұл үшін сіз осы компонент жұмыс істейтін платформаның технологиялық ерекшеліктерінің ерекшеліктерін өте жақсы білуіңіз керек - содан кейін сіз өте тиімді құрал жасай аласыз.

Көрсеткіш қабаты

Егер тұтынушы сыртқы жүйе болса, әдетте ол өзіне қажет деректер құрылымдарын және ақпаратты жинау ережелерін белгілейді. Жақсы тәсіл - бұл тұтынушы деректерді дұрыс жинауға жауапты. Деректер қоймасы дайындалды, көрмені құрады, қосымша деректерді жинау мүмкіндігін қамтамасыз етті (өзгерістердің дельтасын кейіннен бөлектеу үшін мета-атрибуттармен белгілеу), содан кейін тұтынушы жүйесі осы көрмені қалай пайдаланатынын бақылайды және оған жауап береді. Бірақ ерекшеліктер бар: жүйеде деректерді жинауға арналған белсенді компонент болмаған кезде - интеграциялау функциясын орындайтын сыртқы компонент қажет, немесе сақтау орны "интеграциялау платформасы" ретінде әрекет етеді - және дұрыс қосымша мәліметтерді қамтамасыз етеді. әрі қарай жүктеп салу – жадтан тыс. Мұнда көптеген нюанстар пайда болады және интерфейстің өзара әрекеттесу ережелерін екі тарап ойластырып, түсінуі керек (бірақ, интеграцияға келгенде, әдеттегідей). Әдетте, мұндай деректер қоймаларына әдеттегі деректерді тазалау/мұрағаттау қолданылады (бұл «транзиттік деректердің» ұзақ уақыт сақталуы сирек қажет).

Аналитикалық тапсырмалар тұрғысынан ең маңыздысы «адамдарға арналған» витриналар, дәлірек айтқанда, олар жұмыс істейтін BI құралдары үшін.
Дегенмен, сыртқы мамандандырылған жүйелерді толтыру үшін BI құралдарын немесе реттеу процестерін қажет етпейтін «ерекше озық пайдаланушылар» санаты бар - талдаушылар, деректерді зерттеушілер. Оларға өз қалауы бойынша кестелер мен түрлендірулер жасай алатын қандай да бір «жалпы дүкендер» және «өз құмсалғыштары» қажет. Бұл жағдайда репозиторийдің жауапкершілігі осы жалпы дүкен сөрелерінің ережелерге сәйкес деректермен толтырылуын қамтамасыз ету болып табылады.
Біз Data Mining құралдары - деректерді терең талдау сияқты тұтынушыларды бөлек атап өтуге болады. Бұл құралдардың деректерді дайындаудың өзіндік талаптары бар және деректер ғалымдары да олармен жұмыс істейді. Сақтау үшін тапсырма - келісілген пішімдегі кейбір дүкен сөрелерін жүктеу қызметін қолдау үшін қайтадан келеді.

Дегенмен, аналитикалық витриналарға оралу. Бұл деректер қабатындағы сақтау дизайнерлері тұрғысынан қызығушылық тудыратындар.
Менің ойымша, қазір барлық дерлік BI платформалары «ұшталған» деректер марттарын жобалаудың ең жақсы уақытпен тексерілген тәсілі - бұл Ральф Кимбаллдың тәсілі. ретінде белгілі өлшемді модельдеу - көпөлшемді модельдеу. Бұл тақырып бойынша көптеген басылымдар бар. Мысалы, негізгі ережелерді Марга Росс басылымынан табуға болады. Және, әрине, көп өлшемді модельдеу гурусынан кеңес бере аласыз. Тағы бір пайдалы ресурс - Кимбалдың кеңестері
Дүкен сөрелерін құрудың көпөлшемді тәсілін «әдіс евангелистері» де, бағдарламалық қамтамасыз етудің жетекші жеткізушілері де жақсы сипаттап, әзірлегені сонша, бұл жерде оған егжей-тегжейлі тоқталудың мағынасы жоқ - бастапқы дереккөз әрқашан жақсырақ. .

Мен бір ғана екпін айтқым келеді. «Есеп беру және талдау» басқаша. «Ауыр есеп беру» бар - файлдар түрінде жасалған және ұсынылған жеткізу арналары арқылы пайдаланушыларға жеткізілетін алдын ала тапсырыс берілген есептер. Содан кейін бақылау тақталары бар - BI бақылау тақталары. Негізінде бұл веб-қосымшалар. Және бұл қолданбалардың жауап беру уақыты кез келген басқа веб-қосымшалармен бірдей. Бұл BI тақтасын жаңартудың қалыпты уақыты минуттар емес, секундтар екенін білдіреді. Шешімді жобалау кезінде мұны есте сақтау маңызды. Бұған қалай қол жеткізуге болады? Стандартты оңтайландыру әдісі: біз жауап беру уақыты неден тұратынын және біз не әсер ете алатынымызды қарастырамыз. Ең көп уақыт нені босқа өткізеді? Дерекқордың физикалық (дискілік) оқулары үшін, деректерді желі арқылы тасымалдау үшін. Бір сұраныста оқылатын және жіберілетін деректер көлемін қалай азайтуға болады? Жауап анық және қарапайым: деректерді біріктіру керек немесе сұрауға қатысатын нақты кестелердің үлкен кестелеріне сүзгіні қолдану керек және үлкен кестелерді біріктіруді болдыртпау керек (факті кестелерге сілтеме тек өлшемдер арқылы өтуі керек).

BI не үшін қажет? Бұл қалай ыңғайлы? Неліктен көпөлшемді модель тиімді?
BI пайдаланушыға арнайы сұраулар деп аталатындарды орындауға мүмкіндік береді. Бұл нені білдіреді? Бұл дегеніміз, біз нақты сұрауды алдын ала білмейміз, бірақ пайдаланушы қандай аспектілерде қандай көрсеткіштерді сұрай алатынын білеміз. Пайдаланушы сәйкес BI сүзгілерін таңдау арқылы мұндай сұрауды жасайды. Ал BI әзірлеушісі мен дүкен сөресі дизайнерінің міндеті - деректер сүзгіден өткізілетін немесе жинақталған, тым көп деректер сұралған жағдайды болдырмайтын және қолданба «ілулі тұрған» етіп қолданбаның логикасын қамтамасыз ету. Әдетте, олар жинақталған сандардан басталады, содан кейін егжей-тегжейлі деректерді тереңірек зерттейді, бірақ жол бойына қажетті сүзгілерді орнатыңыз.

Тек «дұрыс жұлдызды» құру және BI үшін ыңғайлы құрылымды алу әрқашан жеткіліксіз. Кейде бір жерде денормализацияны қолдану керек болады (бұл жүктемеге қалай әсер ететінін еске түсіру кезінде) және бір жерде қосалқы дүкендер мен агрегаттарды жасау үшін. Бір жерде индекстерді немесе проекцияларды қосыңыз (ДҚБЖ-ға байланысты).

Осылайша, «сынау және қателік» арқылы сіз BI үшін оңтайлы құрылымды ала аласыз - ол ДҚБЖ және BI платформасының ерекшеліктерін, сондай-ақ пайдаланушының деректерді ұсыну талаптарын ескереді.
Егер біз деректерді «өзегінен» алсақ, онда дүкен сөрелерін мұндай өңдеу бастапқы жүйелерден тікелей алынған бастапқы деректерді кешенді өңдеуге ешқандай әсер етпей, жергілікті сипатта болады - біз деректерді тек «ауыстырамыз». BI үшін ыңғайлы пішім. Ал біз мұны сан рет, әртүрлі тәсілдермен, әртүрлі талаптарға сай жасауға болады. Мұны «бастапқыдан» (құрылымы мен ережелері, біз білетіндей, «қалқымалы» да болуы мүмкін) жинауға қарағанда, ядро ​​деректерінде жасау әлдеқайда оңай және жылдамырақ.

Қызмет көрсету деңгейі

Бұл қабат екі деректерді сақтау аймағын қамтиды:

• метадеректер аймағы – деректерді жүктеуді басқару механизмі үшін пайдаланылады;
• деректер сапасы аймағы - деректер сапасын желіден тыс тексерулерді жүзеге асыру үшін (яғни, ETL процестеріне тікелей кірмейтіндер).

Жүктемені басқарудағы маңызды сәт қателерді өңдеудің дәйекті тәсілін әзірлеу болып табылады. Қателер олардың ауырлық деңгейіне қарай жіктеледі. Критикалық қате орын алған кезде, процесс тоқтауы керек және мүмкіндігінше тезірек, өйткені оның пайда болуы жадтағы деректердің бұзылуына әкелетін маңызды мәселені көрсетеді. Осылайша, жүктемені басқару процестерді бастау ғана емес, сонымен қатар оларды тоқтату, сондай-ақ уақтылы (қате) іске қосылудың алдын алу болып табылады.

Қызметтік деңгейдің жұмыс істеуі үшін арнайы метадеректер құрылымы жасалады. Бұл аймақта жүктеу процестері, жүктелген деректер жинақтары, қадамды сақтау үшін пайдаланылатын бақылау нүктелері (қай процесс қай нүктеге дейін оқылды) және жүйенің жұмыс істеуі үшін қажетті басқа да қызмет ақпараты туралы ақпаратты сақтайды.
Барлық қабаттардағы барлық мақсатты кестелер мета-өрістердің арнайы жиынтығымен белгіленгенін атап өту маңызды, олардың бірі осы жолды жаңартқан процестің идентификаторы болып табылады. Репозиторийдегі кестелер үшін бұл процесті белгілеу кейіннен өзгерістердің дельтасын бөлектеудің дәйекті жолына мүмкіндік береді. Деректерді бастапқы деректер деңгейіне жүктегенде, жағдай күрделене түседі - әртүрлі жүктелген нысандар үшін дельтаны бөлу алгоритмі әртүрлі болуы мүмкін. Бірақ қабылданған өзгерістерді өңдеу логикасы және оларды негізгі және дүкен сөрелеріне арналған мақсатты кестелерге жылжыту сахнаға қарағанда әлдеқайда күрделі, мұнда бәрі өте тривиальды - қайта пайдалануға болатын стандартты қадамдарды (рәсімдер) параметрлеу және ойластыру оңай.

Мен мұнда осы тақырыпты толығымен қамту міндетін қойған жоқпын - жүктеп алуды ұйымдастыру - мен жай ғана назар аударуға тұрарлық екпіндерді бөлектеймін.
Бұл тәсіл нұсқалардың бірі ғана. Бұл өте жауапты. Ал оның «концептуалды прототипі» Toyota конвейері және дәл уақытында жұмыс істейтін жүйе болды. Анау. мұнда біз тек «түнгі деректерді жүктеу» кең таралған парадигмасынан алшақтап жатырмыз және біз күндізгі уақытта шағын бөліктерде жүктейміз - деректер әртүрлі көздерде дайын болған кезде: не келді - ол жүктелді. Сонымен қатар бізде көптеген параллель процестер жүріп жатыр. Ал жаңа деректердің «ыстық құйрығы» үнемі «жыпылықтайды» - тіпті уақыт өте келе. Біз мұндай ерекшелікті ескеруіміз керек. Қажет болса, барлығы біртұтас болып табылатын «кесектер» бар арнайы витриналарды жасаңыз. Анау. бір мезгілде тиімділікке де, жүйелілікке де (тұтастыққа) жету мүмкін емес. Бізге тепе-теңдік керек - бір жерде бір нәрсе маңызды, басқа жерде.

Ағаш кесу және бақылау құралдарын қамтамасыз ету міндетті болып табылады. Түрлі параметрлерді орнатуға және хабарландыру жүйесін теңшеуге болатын терілген оқиғаларды пайдалану жақсы тәжірибе - белгілі бір оқиғаларға жазылу. Өйткені Жүйе әкімшісінің араласуы қажет болған кезде ол бұл туралы мүмкіндігінше ерте біліп, барлық қажетті диагностикалық ақпаратты алуы өте маңызды. Журналдар сонымен қатар постфакто мәселелерді талдау үшін, сондай-ақ жүйе ақауларының оқиғаларын, соның ішінде. деректер сапасы.

Қойма деректерінің үлгілерін жобалау және жүргізу

Сіз оны үлгісіз анықтай аласыз ба? Негізінде, сіз аласыз. Оны анықтау және «қағаздағы суреттерді анықтау» және деректерді «сұрып алу - реттеу». Бірақ дайын артефакт – деректер үлгісін пайдалану әлдеқайда оңай, түсінікті және жылдамырақ. Және де «оның құрылғысының логикасын» түсініңіз - яғни. ойынның жалпы ережелері болса жақсы болар еді.

Ең бастысы, бұл тіпті емес. Ең бастысы, модельді жобалау кезінде біз (тек нұсқаларсыз!) Пәндік аймақты, деректер құрылғысының мүмкіндіктерін және оларды әртүрлі бизнес жағдайларда пайдалануды тереңірек және тереңірек зерттеуге мәжбүр боламыз. Ал біз оңай «жақсы итеріп жіберетін» сұрақтарды күрделі, «бұлыңғыр» деп өз белгілерімізді лақтыру арқылы дәл анықтауға тырыспай-ақ қоямыз. дизайнүлгі - біз есептерді құрастыру және «үйлесімсізді қалай азайту» және «дөңгелекті қайта ойлап табу» туралы ойлануды кейінірек емес, талдау және жобалау кезінде қазір жеткізуге және шешуге мәжбүр боламыз.

Бұл тәсіл сынғыш жүйелерді жасауға мүмкіндік беретін инженерлік тәжірибелердің бірі болып табылады. Олар анық реттелген, мөлдір, әзірлеуге ыңғайлы болғандықтан, сонымен қатар олардың «нәзіктік шегі» бірден көрінеді - жаңа талаптар пайда болған кезде «апат ауқымын» және қайта жобалауға қажетті уақытты (қажет болса) дәлірек бағалауға болады.
Осылайша, деректер моделі жүйені әзірлеу кезінде сақталуы керек негізгі артефакттардың бірі болып табылады. Ынтымақтастықта ол әрбір аналитиктің, әзірлеушінің және т.б. «үстелінде» болуы керек. - жүйені дамыту жобаларына қатысатын әрбір адам.

Деректер үлгілерін жобалау - бұл үлкен және бөлек тақырып. Сақтауды жобалаудың екі негізгі тәсілі бар.
Тәсіл ядро ​​үшін жақсы жұмыс істейді Субъект-қатынас - пәндік облысты, дәлірек айтқанда оның таңдалған аймағын зерттеу негізінде нормаланған (3NF) модель салынғанда. Жоғарыда талқыланған «корпоративтік модель» осы жерде ойнайды.

Витриналарды жобалау кезінде ол қолайлы көпөлшемді модель ... Бұл тәсіл бизнес пайдаланушылардың түсінігіне жақсы сәйкес келеді - өйткені бұл қарапайым және адамның қабылдауына ыңғайлы модель - адамдар метриканың (көрсеткіштердің) және олар талданатын бөлімдердің түсінікті және таныс тұжырымдамаларымен жұмыс істейді. Және бұл талаптарды жинау процесін қарапайым және анық құруға мүмкіндік береді - біз әртүрлі бөлімдердің өкілдерімен байланыса отырып, «бөлімдер мен көрсеткіштер матрицаларының» жинағын саламыз. Содан кейін біз оны бір құрылымға – «талдау үлгісіне» келтіреміз: біз «өлшеу шинасын» қалыптастырамыз және оларда анықталған фактілерді анықтаймыз. Осы жолда біз иерархиялар мен біріктіру ережелерімен жұмыс істейміз.

Содан кейін ДҚБЖ ерекшеліктерін ескере отырып, оңтайландыру элементтерін қосып, физикалық модельге өту өте оңай. Мысалы, Oracle үшін бұл бөлу, индекстер жинағы және т.б. Vertica үшін басқа әдістер қолданылады - сұрыптау, сегменттеу, секциялау.
Сондай-ақ, арнайы нормадан шығару талап етілуі мүмкін - біз деректерге әдейі резервтеуді енгізген кезде, соның арқасында біз сұрау өнімділігін жақсартамыз, бірақ сонымен бірге деректерді жаңартуды қиындатамыз (өйткені артықшылықты деректерді жүктеу кезінде ескеру және қолдау қажет болады) процесс). Мүмкін, өнімділікті жақсарту үшін бізге қосымша жиынтық кестелер жасауға немесе Vertica бағдарламасындағы проекциялар сияқты қосымша ДҚБЖ мүмкіндіктерін пайдалануға тура келуі мүмкін.

Сонымен, қойма деректерін модельдеу кезінде біз бірнеше мәселені шешеміз:

• ядроның концептуалды (логикалық) моделін құру міндеті – жүйелік және бизнес-талдау – пәндік аумақты зерттеу, егжей-тегжейлерге өту және «тірі деректердің» нюанстарын есепке алу және оларды бизнесте пайдалану;
• талдау үлгісін құру міндеті - содан кейін концептуалды (логикалық) дүкен сөресі үлгісі;
• физикалық модельдерді құру міндеті – деректердің артықтығын басқару, сұраулар мен деректерді жүктеу үшін ДҚБЖ ерекшеліктерін ескере отырып оңтайландыру.

Қорытындылайық.

• Деректер моделі «әдемі суреттер» жинағы емес және оны жобалау процесі оларды салу процесі емес. Модель біздің домен туралы түсінігімізді көрсетеді. Ал оны құрастыру – оны зерттеу, зерттеу процесі. Бұл босқа кеткен уақыт. Және мүлде «сызу және бояу» емес.
• Деректер моделі – дизайн артефакті, команда мүшелері арасында құрылымдық түрде ақпарат алмасу тәсілі. Ол үшін ол барлығына түсінікті болуы керек (бұл белгілер мен түсініктемелер арқылы беріледі) және қолжетімді (жарияланған).
• Мәліметтер моделі бір рет құрылып, қатып қалмайды, жүйенің даму процесінде құрылады және дамиды. Оны дамытудың ережелерін өзіміз белгіледік. Және біз оларды қалай жақсырақ, оңайырақ, тиімдірек жасауға болатынын көрсек, өзгерте аламыз.
• Деректер моделі (физикалық) оңтайландыруға бағытталған озық тәжірибелер жиынтығын біріктіруге және пайдалануға мүмкіндік береді - яғни. осы ДҚБЖ үшін бұрыннан жұмыс істеген әдістерді пайдаланыңыз.

Мәліметтер қоймасы жобаларының ерекшеліктері

Деректер қоймасы – арнайы бағдарламалық құрал

Деректер қоймасы – интеграциялық жоба

Деректер қоймасы – бірлескен жоба

Архитектура оның тұтастығын сақтай отырып және әртүрлі жерлерде, әртүрлі адамдарда бір функцияның қайталануын болдырмай, олардың параллель жұмысын ұйымдастыру мүмкіндігін қамтамасыз етуі керек. Қажетсіз күш салудан басқа, мұндай қайталау кейінірек деректердің сәйкессіздігіне әкелуі мүмкін.

Сонымен қатар, жүйені әзірлеуге жиі шашыраңқы орналасқан көптеген адамдар мен командалар тартылған кезде, олардың арасындағы коммуникациялар мен ақпараттық өзара әрекеттесуді қалай құру керек деген сұрақ сөзсіз туындайды. Неғұрлым стандартты және түсінікті тәсілдер мен тәжірибелер қолданылса, мұндай жұмысты ұйымдастыру соғұрлым оңай, ыңғайлы және тиімді болады. Сонымен қатар, «жұмыс артефактілерінің» құрамы туралы ойлану керек, олардың арасында №1 деректер қоймалары үшін деректер үлгілері бар (алдыңғы бөлімді қараңыз).

Деректер қоймасының қызмет ету мерзімі басқа жүйелерге қарағанда ұзағырақ

Менде бұлай деп сенуге қандай негіздер бар?
Біріншіден, қойма салу - бұл өте ресурсты қажет ететін процесс: жабдықтың нақты шығындарынан, қажетті технологиялық бағдарламалық қамтамасыз ету мен әзірлеуге арналған лицензиялардан басқа, бұл компанияның барлық дерлік жүйелері мен бөлімшелерімен айналысады. Бұл процесті нөлден тағы бір рет қайталау - өте батыл идея.

Екіншіден, егер жад дұрыс архитектураға ие болса, онда ол бастапқы жүйелердің өзгеруіне және соңғы пайдаланушылардан жаңа талаптардың пайда болуына және деректер көлемінің өсуіне оңай төтеп бере алады.
Архитектура дұрыс болса, ақпарат ағындары мөлдір болса, онда мұндай жүйе әсерді бағалаудағы қиындықтарға байланысты өзгерістер енгізу кезінде жағдайға кептелу қаупінсіз ұзақ уақыт бойы жасалуы мүмкін.

Біртіндеп қайталанатын даму

Клиенттердің көз алдында деректер қоймасы жиі абсолютті құбыжық сияқты көрінеді - жүйенің міндеттері, мақсаттары және даму көкжиегі соншалықты көлемді. Көбінесе тапсырыс беруші «бюджет есебінен» IT бөлімі кейбір «өз мәселелерін» шешеді деп қорқады. Біз тағы да адамдар арасындағы өзара әрекеттесу және өз позициямызды байсалды түрде білдіру және келіссөздер жүргізу мүмкіндігі мәселесіне тап болдық.

Құзыретті архитектуралық тәсілдер нәтиже бере бастағанға дейін бірнеше жыл бойы «дамытуға» бармай, функционалдылықты біртіндеп арттыра отырып, жүйені итеративті түрде дамытуға мүмкіндік береді.

Айта кету керек, «ғажайыптар болмайды» - және «бастау» да уақытты қажет етеді. Сақтау орындары үшін ол айтарлықтай үлкен болуы мүмкін - бұл деректердің үлкен көлемі болғандықтан, бұл тарихи деректер - ақпаратты өңдеу ережелері қазіргіден өзгеше болуы мүмкін ескі кезеңдерге арналған. Сондықтан, аналитикалық жұмыс, бастапқы жүйелермен өзара әрекеттесу және бірқатар «сынау және қателік», соның ішінде нақты деректерге жүктеме сынақтары үшін жеткілікті уақыт қажет.

Деректер қоймалары - «көп жобалық оқиға»

Инновациялар мен дәлелденген шешімдер балансы

ДҚБЖ-ны сақтаудың ең маңызды және маңызды технологиялық платформасы ретінде қарастырайық.
Жақында бастапқыда «әмбебап» ретінде құрылған реляциялық деректер қорының мамандандыруға қарай анық ауытқуы байқалды. Ұзақ уақыт бойы жетекші жеткізушілер әртүрлі класстардың (OLTP, DSS & DWH) қосымшалары үшін әртүрлі опцияларды шығаруда. Сонымен қатар, мәтінмен, геодеректермен және т.б. жұмыс істеу үшін қосымша мүмкіндіктер пайда болады.

Бірақ бұл мұның соңы емес - бастапқыда белгілі бір тапсырмалар класына бағытталған өнімдер пайда бола бастады, яғни. мамандандырылған ДҚБЖ. Олар реляциялық модельді пайдалана алады немесе қолданбауы мүмкін. Олардың бастапқыда жалпы «іскерлік ақпаратты» сақтау және өңдеу үшін ғана емес, нақты тапсырмалар үшін «ұшталғаны» маңызды.

Шамасы, орталықтандыру мен мамандандыру бір-бірін мезгіл-мезгіл алмастыратын, даму мен тепе-теңдікті қамтамасыз ететін бір-бірін толықтыратын екі тенденция болып табылады. Сондай-ақ эволюциялық (біртіндеп) бірте-бірте даму және түбегейлі өзгерістер. Мысалы, 90-шы жылдары Майкл Стоунбрейкер «Деректер қоры әлемінде әлемге тағы бір революция қажет емес» деген идеяны анық білдірген III ұрпақ деректер базасы манифестінің авторларының бірі болды. Дегенмен, 10 жылдан кейін ол ДҚБЖ әлеміндегі жаңа дәуірдің басталуының алғышарттарын жариялайтын еңбектерін жариялайды - олардың мамандануына негізделген.
Ол жалпыға ортақ әмбебап ДҚБЖ аппараттық платформалардағы өзгерістерді де, қосымшалардың қосымшасын ойлап табуға болатын сыныптарға бөлінуін де ескермейтін «бір өлшемді» архитектураға құрылғанына назар аударады. әмбебап талаптарды жүзеге асыруға қарағанда оңтайлы шешім.
Және осы ойына сай бірқатар жобаларды әзірлеуге кіріседі. Олардың бірі - C-Store - бұл бастапқыда деректер қоймалары класының жүйелері үшін арнайы жасалған, ортақ ештеңе (SN) архитектурасында жасалған бағаналы ДҚБЖ. Бұл өнім кейін HP Vertica ретінде сатылды.

Қазір деректер қоймасын дамыту тақырыбы дамудың жаңа кезеңіне сырғып кеткен сияқты. Жаңа технологиялар, тәсілдер мен құралдар пайда болады. Оларды зерттеу, тестілеу және интеллектуалды қолдану бізге шынымен қызықты және пайдалы шешімдерді жасауға мүмкіндік береді. Сіздің әзірлемелеріңіз нақты жұмыста қолданылып, пайдалы болғанынан ләззат ала отырып, оларды іске асыруға әкеліңіз.

Эпилог

Жалпы алғанда, сәулетші рөлін нақты кім орындайтыны маңызды емес - біреудің ұқсас сұрақтар қойып, жауаптарды зерттегені маңызды. Егер сәулетші нақты бөлектелсе, бұл оның жүйе мен оның дамуына ең алдымен жауапты екенін білдіреді.
Неліктен мен бұл тақырыпқа «қарсы сынғыштық» тақырыбын қатысты деп таптым?

«Антифрагильділіктің бірегейлігі ол бізге белгісізмен жұмыс істеуге, нақты не істеп жатқанымызды түсінбейтін жағдайда бірдеңе жасауға және табысқа жетуге мүмкіндік береді»./ Насим Н. Талб /

Сату үшін сіз не сататынымызды түсінуіңіз керек

Терминология мен ұғымдарды анықтайық. ( Деректер қоймасы) Негізгі тиімділік көрсеткіштерінің жүйесі емес (KPI, KPI), олай емес үлкен негіздеректер, ол аналитикалық емес OLAP құралы, бұл жаңа деректерді шығаруға және статистикалық тәуелділіктерді алуға мүмкіндік беретін зияткерлік жүйе емес, бұл бір анықтамалық деректер жүйесі емес - мұның бәрі бір элемент контексінде айтатын болсақ, CD емес.

Кәсіпорын деректер қоймасы – бұл біртұтас аппараттық-бағдарламалық кешенде өңделетін және сақталатын кәсіпорынның (ұйымның) арнайы ұйымдастырылған деректер массиві, ол жылдам қол жеткізужедел және тарихи ақпаратқа, көпөлшемді деректерді талдауға (әртүрлі өлшемдер үшін KPI), келісілген анықтамалық ақпарат (SRI) тұрғысынан болжамдар мен статистиканы алу.

Корпоративтік деректер қоймасының әлеуетті тұтынушылары және олар не алады?

Потенциалды қалай анықтауға болады корпоративтік клиенттердеректер қоймасы кімге керек?

1. Біріншіден, компанияның күнделікті қызметінде көптеген ақпарат пайда болуы керек. Болуы мүмкін телефон қоңыраулары, қаржылық транзакциялар, тұтынушылардың шағымдары/пікірлері, тұтынушылардың жөнелтілім сұраулары, тыңшылық спутниктерден алынған ақпарат және т.б. Негізінде, кез келген нәрсе, ең бастысы - деректер көп.
2. Болашақта көруге және талдауға деген ұмтылыс болуы керек бұл ақпарат... Бұл жағдайда талдау кезеңі жеткілікті ауқымды болуы керек - бір күннен немесе тіпті бір сағаттан бірнеше жылға дейінгі талдауға дейін.
3. Клиенттің қалыпты жұмыс істейтін инфрақұрылымы болуы керек (бұралған жұп кабель немесе USB порты арқылы қосылған серверлер болмауы керек). Клиенттің инфрақұрылымы болмаса, оны сатуы керек.

Тұтынушы кәсіпорынның деректер қоймасын енгізуден қандай артықшылықтар алады?

1. Корпоративтік деректерді сақтаудың бірыңғай ақпараттық жүйесі пайда болады, онда бірыңғай анықтамалық ақпарат пайдаланылады.
2. Кәсіпкерлікке жан-жақты талдау жүргізуге болады. Мысалы: қандай клиенттер ең табысты және тиімді; қандай қызмет қай клиенттерге көбірек сұранысқа ие, қандай шағымдар жиі және қай аймақтарда және т.б.
3. Тарихи деректерді пайдалана отырып, талдау жүргізуге болады. Көбінесе операциялық (күнделікті бизнес-процестерді автоматтандыратын) жүйелер бұған мүмкіндік бермейді, оларда тарихты сақтауға және талдау мүмкіндігіне жеткілікті орын жоқ.
4. Әртүрлі ақпараттық жүйелерде бұрын сақталған ақпаратты қосу және талдау мүмкін болады. Мысалы, әртүрлі филиалдар үшін трафик деректері әртүрлі әзірлеушілердің есепшот жүйесінде сақталады. Компакт-дискілерді іске асырғаннан кейін оларды бір есепте, бірге талдауға болады.
5. Әр түрлі мәліметтерді талдау және қиылысу мүмкін болады. Мысалы, ақша мен трафик, қызметкерлер саны және бас тарту немесе шағымдар саны және т.б.
6. Қызметтердің құнын жақсырақ есептеу үшін негіз пайда болады - корпоративтік деректер қоймасынан алынған ақпарат негізінде табиғи тарату негіздері үшін неғұрлым барабар деректерді алуға болады.

Корпоративтік деректер қоймасы дегеніміз не

Техникалық тұрғыдан кәсіпорынның деректер қоймасы қандай құрамдастарды пайдаланады?

Құрамдас бөліктер корпоративтік деректер қоймасы кәсіпорындар

1. Клиентте әрқашан операциялық жүйелер бар - деректер көздерікорпоративтік деректер қоймасы үшін. Бұл, мысалы, бухгалтерлік есеп, есепшот, банктік және т.б. жүйелер.
2. Қолдану ETL қолданбасы(мәліметтерді шығаруға, түрлендіруге және жүктеуге мүмкіндік беретін бағдарламалық қамтамасыз ету), бастапқы жүйелердегі деректер деректер қоймасының деректер қорына түседі. Төмендегілерді ETL құралдары ретінде пайдалануға болады: Informatica Power Center, IBM DataStage, Oracle Data Integrator, Oracle WareHouse Builder. Басқа жеткізушілердің өнімдері де бар, бірақ олар ресейлік нарықта дерлік ұсынылмайды.
3. Өзі мәліметтер базасыкорпоративтік сақтау өз құрылымы бойынша абстрактілі емес (кестелер жиынтығы, олардағы өрістер және кестелер арасындағы қатынастар), бірақ негізінде құрылады деректер үлгілері. Көбінесе дерекқор ретінде Oracle немесе Teradata пайдаланылады.
4. Деректер моделікорпоративтік деректер қоймасының барлық субъектілерінің, деректер қоры объектілерінің сипаттамасы болып табылады және мыналарды қамтиды: концептуалды деректер моделі, логикалық деректер моделі және физикалық деректер базасының үлгісі ... Концептуалды модель деңгейінде субъектілер мен олардың арасындағы қатынастар анықталады. Логикалық модель деңгейінде субъектілер бизнес салаларына бөлінеді, оларға толық және толық сипаттама беріліп, қарым-қатынастар жазылады. Мәліметтер қорының физикалық моделін жасау кезінде деректер қорының барлық құрылымы анықталады – олардағы кестелер мен өрістерден бастап, бөлімдер мен индекстерге дейін. Деректер үлгілерібүгінде IBM, SAP және Oracle нарықты қамтамасыз етеді, бірақ деректер үлгісін сатып алу автоматты түрде дұрыс кәсіпорын қоймасын құру дегенді білдірмейді.Деректер моделіқораптағы өнім емес. Ол белгілі бір клиенттің қажеттіліктерін қанағаттандыру үшін өзгертілуі керек.
5. Әрі қарай, қазірдің өзінде корпоративтік деректер қоймасының деректерін пайдалану, талдау, есеп беру және деректер маркерлері... Кейіннен пайдаланушылар қажетті есептілікті дербес құра алады және көп өлшемді талдау жүргізе алады. Бизнес объектілері, Oracle Discoverer, IBM AlphaBlocks және басқа өнімдер негізінен талдау құралдары ретінде пайдаланылады.

Кәсіпорынның деректер қоймасының құрамдас бөліктері қандай көрінеді (деректер үлгісі, ETL процестері, деректер марттары)

Біз деректер үлгісінің көрнекі мысалдарын, ETL процесін жүзеге асыруды, бір анықтамалық деректерге қолдау көрсету формаларын, деректер маркерлерін береміз.

Логикалық модельдеректер.
Субъектілерді, олардың атрибуттарын және олардың арасындағы қатынастарды анықтайды.

ETL процесібастапқы деректердегі көшірмелерді жою

Бірыңғай анықтамалықты қалыптастыру үшін деректерді енгізу формасы

Деректер көрмесікестелік есеп түрінде

Деректер көрмесіграфикамен және түстермен
берілген шартқа сәйкес деректерді шығару

Деректер көрмесікестемен

Қатысты бағдарламалық және аппараттық құрал

Біріншіден, корпоративтік деректер қоймасын әзірлеуге арналған қызметтердің өзінен басқа, лицензиялар серверлік бағдарламалық қамтамасыз ету (ОС, деректер базасы, қолданбалы сервер және т.б.) үшін де, клиенттік орындар үшін де (құралдар) сатылады. антивирустық қорғаужәне қауіпсіздік).

Клиенттің бар серверлері деректер қоймасын орналастыруға арналмаған болуы мүмкін. Оларға талап қойып, әлеуетті клиентке техникалық құралдарды сату керек.

Серверлердің өзінен басқа, ақпараттың айтарлықтай көлемін сақтау үшін дискілік массивтер қажет.

Корпоративтік деректер қоймасын құруға ниет білдірген әлеуетті клиент сақтық көшірмені қалай қамтамасыз ететінін әрқашан түсінбейді. Көбінесе тұтынушылардың бар жүйелері Резервтік көшірме 20-30 ТБ деректер көлемін сақтық көшірмеге бір уақытта қосу мүмкін емес.

Әдетте, клиенттің мамандары мен пайдаланушылары оқу курстарынан өтуді талап етеді.

М.В.Ковтун 2010 жылдың тамызы