ទិដ្ឋភាពទូទៅនៃវិធីសាស្ត្ររចនា Agile DWH

ការអភិវឌ្ឍន៍កន្លែងស្តុកទុក គឺជាកិច្ចការដ៏យូរ និងធ្ងន់ធ្ងរ។

ភាគច្រើននៅក្នុងជីវិតរបស់គម្រោងគឺអាស្រ័យទៅលើថាតើគំរូវត្ថុ និងរចនាសម្ព័ន្ធមូលដ្ឋានត្រូវបានគិតយ៉ាងល្អយ៉ាងណានៅពេលចាប់ផ្តើម។

វិធីសាស្រ្តដែលទទួលយកជាទូទៅបាននិងនៅតែជាវ៉ារ្យ៉ង់ផ្សេងៗគ្នានៃការបញ្ចូលគ្នានូវគ្រោងការណ៍ផ្កាយជាមួយនឹងទម្រង់ធម្មតាទីបី។ តាមក្បួនមួយយោងទៅតាមគោលការណ៍: ទិន្នន័យដំបូង - 3NF ការបង្ហាញ - ផ្កាយ។ វិធីសាស្រ្តនេះត្រូវបានសាកល្បងដោយពេលវេលា និងគាំទ្រដោយការស្រាវជ្រាវមួយចំនួនធំ គឺជារឿងដំបូង (ហើយពេលខ្លះតែមួយគត់) ដែលចូលមកក្នុងគំនិតរបស់អ្នកឯកទេស DWH ដែលមានបទពិសោធន៍នៅពេលគិតអំពីអ្វីដែលឃ្លាំងវិភាគគួរមានរូបរាង។

ម្យ៉ាងវិញទៀត អាជីវកម្មជាទូទៅ និងតម្រូវការអតិថិជន ជាពិសេសមាននិន្នាការផ្លាស់ប្តូរយ៉ាងឆាប់រហ័ស ហើយទិន្នន័យមាននិន្នាការកើនឡើងទាំង "នៅក្នុងជម្រៅ" និង "នៅក្នុងទទឹង" ។ ហើយនេះគឺជាកន្លែងដែលគុណវិបត្តិចម្បងនៃផ្កាយមួយលេចឡើង - មានកំណត់ ភាពបត់បែន.

ហើយប្រសិនបើនៅក្នុងជីវិតស្ងប់ស្ងាត់ និងកក់ក្ដៅរបស់អ្នកជាអ្នកអភិវឌ្ឍន៍ DWH ភ្លាមៗនោះ៖

• កិច្ចការ​បាន​កើត​ឡើង “ធ្វើ​យ៉ាង​ហោច​ណាស់​អ្វី​មួយ​ឲ្យ​បាន​លឿន ហើយ​បន្ទាប់​មក​យើង​នឹង​ឃើញ”;
• គម្រោងដែលកំពុងអភិវឌ្ឍយ៉ាងឆាប់រហ័សបានបង្ហាញខ្លួន ជាមួយនឹងការភ្ជាប់ប្រភពថ្មី និងការដំណើរការឡើងវិញនៃគំរូអាជីវកម្មយ៉ាងហោចណាស់ម្តងក្នុងមួយសប្តាហ៍។
• អតិថិជនបានបង្ហាញខ្លួន ដែលមិនដឹងថាប្រព័ន្ធគួរមានរូបរាងបែបណា និងមុខងារអ្វីដែលវាគួរអនុវត្តនៅទីបំផុត ប៉ុន្តែបានត្រៀមខ្លួនរួចជាស្រេចក្នុងការពិសោធន៍ និងកែលម្អលទ្ធផលដែលចង់បាន ខណៈពេលដែលកាន់តែខិតទៅជិតវាជានិច្ច។
• អ្នក​គ្រប់​គ្រង​គម្រោង​បាន​និយាយ​ប្រាប់​ដំណឹង​ល្អ​ថា៖ «ហើយ​ឥឡូវ​យើង​មាន​ភាព​រហ័សរហួន​ហើយ!»។

ឬប្រសិនបើអ្នកគ្រាន់តែចាប់អារម្មណ៍ក្នុងការស្វែងយល់ពីរបៀបផ្សេងទៀតដែលអ្នកអាចសាងសង់កន្លែងផ្ទុក - សូមស្វាគមន៍មកកាន់ការកាត់!

តើ "ភាពបត់បែន" មានន័យដូចម្តេច?

ជាដំបូង ចូរយើងកំណត់នូវលក្ខណៈសម្បត្តិដែលប្រព័ន្ធត្រូវតែមាន ដើម្បីឱ្យត្រូវបានគេហៅថា "បត់បែន" ។

ដោយឡែកពីគ្នា វាមានតម្លៃក្នុងការនិយាយថា លក្ខណៈសម្បត្តិដែលបានពិពណ៌នាគួរទាក់ទងជាពិសេស ប្រព័ន្ធមិនមែនទេ។ ដំណើរការ ការអភិវឌ្ឍន៍របស់វា។ ដូច្នេះប្រសិនបើអ្នកចង់អាន Agile ជាវិធីសាស្រ្តអភិវឌ្ឍន៍ វាជាការប្រសើរក្នុងការអានអត្ថបទផ្សេងទៀត។ ជាឧទាហរណ៍ នៅទីនោះនៅលើ Habre មានសម្ភារៈគួរឱ្យចាប់អារម្មណ៍ជាច្រើន (ដូចជា ពិនិត្យ и ជាក់ស្តែង, និង មានបញ្ហា).

នេះមិនមានន័យថាដំណើរការអភិវឌ្ឍន៍ និងរចនាសម្ព័ន្ធនៃឃ្លាំងទិន្នន័យមិនទាក់ទងគ្នាទាំងស្រុងនោះទេ។ សរុបមក វាគួរតែមានភាពងាយស្រួលក្នុងការអភិវឌ្ឍន៍ឃ្លាំង Agile សម្រាប់ស្ថាបត្យកម្ម agile ។ ទោះជាយ៉ាងណាក៏ដោយនៅក្នុងការអនុវត្ត ជាញឹកញាប់មានជម្រើសជាមួយនឹងការអភិវឌ្ឍន៍ Agile នៃ DWH បុរាណយោងទៅតាម Kimbal និង DataVault - យោងតាម ​​Waterfall ជាងភាពចៃដន្យនៃភាពបត់បែនក្នុងទម្រង់ពីររបស់វានៅលើគម្រោងមួយ។

ដូច្នេះ តើទំហំផ្ទុកដែលអាចបត់បែនបានគួរមានសមត្ថភាពអ្វីខ្លះ? មានបីចំណុចនៅទីនេះ៖

1. ការដឹកជញ្ជូនលឿន និងឆាប់រហ័ស - នេះមានន័យថាតាមឧត្ដមគតិ លទ្ធផលអាជីវកម្មដំបូង (ឧទាហរណ៍ របាយការណ៍ការងារដំបូង) គួរតែត្រូវបានទទួលបានឱ្យបានឆាប់តាមដែលអាចធ្វើទៅបាន ពោលគឺ មុនពេលដែលប្រព័ន្ធទាំងមូលត្រូវបានរៀបចំ និងអនុវត្តយ៉ាងពេញលេញ។ ជាងនេះទៅទៀត ការកែប្រែជាបន្តបន្ទាប់នីមួយៗគួរតែចំណាយពេលតិចបំផុតតាមដែលអាចធ្វើបាន។
2. ការកែលម្អឡើងវិញ - នេះមានន័យថាការកែលម្អជាបន្តបន្ទាប់នីមួយៗមិនគួរប៉ះពាល់ដល់មុខងារដែលកំពុងដំណើរការនោះទេ។ វាជាពេលវេលានេះ ដែលជារឿយៗក្លាយជាសុបិន្តអាក្រក់បំផុតលើគម្រោងធំៗ - មិនយូរមិនឆាប់ វត្ថុនីមួយៗចាប់ផ្តើមទទួលបានការតភ្ជាប់ជាច្រើន ដែលវាកាន់តែងាយស្រួលក្នុងការធ្វើឡើងវិញនូវតក្កវិជ្ជាទាំងស្រុងនៅក្នុងច្បាប់ចម្លងក្បែរនោះ ជាជាងការបន្ថែមវាលទៅក្នុងតារាងដែលមានស្រាប់។ ហើយប្រសិនបើអ្នកមានការភ្ញាក់ផ្អើលដែលថាការវិភាគផលប៉ះពាល់នៃការកែលម្អលើវត្ថុដែលមានស្រាប់អាចចំណាយពេលច្រើនជាងការកែលម្អខ្លួនឯង អ្នកទំនងជាមិនទាន់បានធ្វើការជាមួយឃ្លាំងទិន្នន័យធំនៅក្នុងធនាគារ ឬទូរគមនាគមន៍ទេ។
3. សម្របខ្លួនជានិច្ចទៅនឹងការផ្លាស់ប្តូរតម្រូវការអាជីវកម្ម - រចនាសម្ព័នវត្ថុទាំងមូលគួរតែត្រូវបានរចនាឡើងមិនត្រឹមតែគិតគូរពីការពង្រីកដែលអាចធ្វើទៅបានប៉ុណ្ណោះទេ ប៉ុន្តែជាមួយនឹងការរំពឹងទុកថាទិសដៅនៃការពង្រីកបន្ទាប់នេះមិនអាចស្រមៃសូម្បីតែនៅដំណាក់កាលរចនា។

ហើយបាទ ការបំពេញតម្រូវការទាំងអស់នេះនៅក្នុងប្រព័ន្ធមួយគឺអាចធ្វើទៅបាន (ជាការពិតណាស់ ក្នុងករណីជាក់លាក់ និងជាមួយនឹងការកក់មួយចំនួន)។

ខាងក្រោមនេះខ្ញុំនឹងពិចារណាវិធីសាស្រ្តរចនាដ៏ពេញនិយមបំផុតចំនួនពីរសម្រាប់ឃ្លាំងទិន្នន័យ - ម៉ូដែលយុថ្កា и ឃ្លាំងទិន្នន័យ. នៅសល់ពីតង្កៀបគឺជាបច្ចេកទេសដ៏ល្អឥតខ្ចោះដូចជាឧទាហរណ៍ EAV, 6NF (ក្នុងទម្រង់ដ៏បរិសុទ្ធរបស់វា) និងអ្វីគ្រប់យ៉ាងដែលទាក់ទងនឹងដំណោះស្រាយ NoSQL - មិនមែនដោយសារតែពួកគេអាក្រក់ជាងនេះទេ ហើយមិនមែនដោយសារតែក្នុងករណីនេះអត្ថបទនឹងគំរាមកំហែងដើម្បីទទួលបាន។ បរិមាណនៃ disser មធ្យម។ វាគ្រាន់តែថាទាំងអស់នេះទាក់ទងនឹងដំណោះស្រាយនៃថ្នាក់ខុសគ្នាបន្តិចបន្តួច - ទាំងបច្ចេកទេសដែលអ្នកអាចប្រើក្នុងករណីជាក់លាក់ដោយមិនគិតពីស្ថាបត្យកម្មទាំងមូលនៃគម្រោងរបស់អ្នក (ដូចជា EAV) ឬគំរូនៃការផ្ទុកព័ត៌មានជាសកលផ្សេងទៀត (ដូចជា មូលដ្ឋានទិន្នន័យក្រាហ្វ។ និងជម្រើសផ្សេងទៀត NoSQL) ។

បញ្ហានៃវិធីសាស្រ្ត "បុរាណ" និងដំណោះស្រាយរបស់ពួកគេនៅក្នុងវិធីសាស្រ្តដែលអាចបត់បែនបាន។

តាមវិធីសាស្រ្ត "បុរាណ" ខ្ញុំមានន័យថា តារាចាស់ដ៏ល្អ (ដោយមិនគិតពីការអនុវត្តជាក់លាក់នៃស្រទាប់ខាងក្រោម សូមអ្នកដើរតាម Kimball, Inmon និង CDM អត់ទោសឱ្យខ្ញុំ)។

1. ភាពរឹងប៉ឹងនៃការតភ្ជាប់

គំរូនេះគឺផ្អែកលើការបែងចែកទិន្នន័យច្បាស់លាស់ទៅក្នុង វិមាត្រ и អង្គហេតុ. ហើយនេះ, damn វាគឺឡូជីខល - បន្ទាប់ពីទាំងអស់, ការវិភាគទិន្នន័យនៅក្នុងករណីភាគច្រើនលើសលប់បានចុះទៅការវិភាគនៃសូចនាករលេខជាក់លាក់ (ការពិត) នៅក្នុងផ្នែកជាក់លាក់ (វិមាត្រ) ។

ក្នុងករណីនេះការតភ្ជាប់រវាងវត្ថុត្រូវបានបង្កើតឡើងក្នុងទម្រង់នៃទំនាក់ទំនងរវាងតារាងដោយប្រើសោបរទេស។ នេះ​មើល​ទៅ​ជា​ធម្មជាតិ ប៉ុន្តែ​ភ្លាមៗ​នាំ​ឱ្យ​មាន​ការ​កំណត់​ដំបូង​នៃ​ភាព​បត់បែន - និយមន័យតឹងរឹងនៃ cardinality នៃការតភ្ជាប់.

នេះមានន័យថា នៅដំណាក់កាលរចនាតារាង អ្នកត្រូវតែកំណត់យ៉ាងត្រឹមត្រូវសម្រាប់គូនៃវត្ថុដែលទាក់ទងគ្នាថាតើពួកគេអាចទាក់ទងច្រើនទៅច្រើន ឬត្រឹមតែ 1 ទៅច្រើន និង "ក្នុងទិសដៅមួយណា"។ វាកំណត់ដោយផ្ទាល់ថាតើតារាងមួយណានឹងមានសោចម្បង ហើយមួយណានឹងមានសោបរទេស។ ការផ្លាស់ប្តូរអាកប្បកិរិយានេះនៅពេលដែលតម្រូវការថ្មីត្រូវបានទទួល ទំនងជានឹងនាំទៅដល់ការដំណើរការឡើងវិញនូវមូលដ្ឋាន។

ឧទាហរណ៍ នៅពេលរចនាវត្ថុ "បង្កាន់ដៃសាច់ប្រាក់" អ្នកពឹងផ្អែកលើពាក្យសម្បថរបស់ផ្នែកលក់ បានដាក់ចេញនូវលទ្ធភាពនៃសកម្មភាព។ ការផ្សព្វផ្សាយមួយសម្រាប់មុខតំណែងត្រួតពិនិត្យជាច្រើន។ (ប៉ុន្តែមិនផ្ទុយមកវិញ)៖

ហើយបន្ទាប់ពីពេលខ្លះ សហសេវិកបានណែនាំយុទ្ធសាស្ត្រទីផ្សារថ្មីមួយ ដែលពួកគេអាចធ្វើសកម្មភាពលើមុខតំណែងដូចគ្នា។ ការផ្សព្វផ្សាយជាច្រើនក្នុងពេលតែមួយ. ហើយឥឡូវនេះអ្នកត្រូវកែប្រែតារាងដោយបំបែកទំនាក់ទំនងទៅជាវត្ថុដាច់ដោយឡែកមួយ។

(វត្ថុដែលបានមកពីទាំងអស់ដែលការត្រួតពិនិត្យការផ្សព្វផ្សាយត្រូវបានចូលរួមឥឡូវនេះក៏ត្រូវកែលម្អផងដែរ)។

ទំនាក់ទំនងនៅក្នុង Data Vault និង Anchor Model

ការជៀសវាងស្ថានភាពនេះប្រែទៅជាសាមញ្ញណាស់៖ អ្នកមិនចាំបាច់ទុកចិត្តផ្នែកលក់ដើម្បីធ្វើរឿងនេះទេ។ ការភ្ជាប់ទាំងអស់ត្រូវបានទុកដំបូងក្នុងតារាងដាច់ដោយឡែក ហើយដំណើរការវាជាច្រើនទៅច្រើន។

វិធីសាស្រ្តនេះត្រូវបានស្នើឡើង លោក Dan Linstedt ជាផ្នែកមួយនៃគំរូ ឃ្លាំងទិន្នន័យ និងគាំទ្រយ៉ាងពេញលេញ លោក Lars Rönnbäck в គំរូយុថ្កា.

ជាលទ្ធផល យើងទទួលបានលក្ខណៈពិសេសប្លែកដំបូងនៃវិធីសាស្រ្តដែលអាចបត់បែនបាន៖

ទំនាក់ទំនងរវាងវត្ថុមិនត្រូវបានរក្សាទុកក្នុងគុណលក្ខណៈរបស់អង្គភាពមេទេ ប៉ុន្តែជាប្រភេទវត្ថុដាច់ដោយឡែក។

В ឃ្លាំងទិន្នន័យ តារាងតភ្ជាប់បែបនេះត្រូវបានគេហៅថា តំណភ្ជាប់និងក្នុង។ គំរូយុថ្កា - ស្មើ. នៅ glance ដំបូង, ពួកគេគឺស្រដៀងគ្នាខ្លាំងណាស់, ទោះបីជាភាពខុសគ្នារបស់ពួកគេមិនបញ្ចប់ដោយឈ្មោះ (ដែលនឹងត្រូវបានពិភាក្សាខាងក្រោម) ។ នៅក្នុងស្ថាបត្យកម្មទាំងពីរ តារាងតំណអាចភ្ជាប់ ចំនួនអង្គភាពណាមួយ។ (មិនចាំបាច់ ២) ។

ភាពលែងត្រូវការតទៅទៀតនេះ ផ្តល់នូវភាពបត់បែនយ៉ាងសំខាន់សម្រាប់ការកែប្រែ។ រចនាសម្ព័នបែបនេះមានភាពអត់ឱនមិនត្រឹមតែចំពោះការផ្លាស់ប្តូរនៅក្នុង cardinality នៃតំណភ្ជាប់ដែលមានស្រាប់ប៉ុណ្ណោះទេប៉ុន្តែថែមទាំងការបន្ថែមថ្មីផងដែរ - ប្រសិនបើឥឡូវនេះទីតាំងមូលប្បទានប័ត្រក៏មានតំណភ្ជាប់ទៅអ្នកគិតលុយដែលបានបំបែកវានោះរូបរាងនៃតំណភ្ជាប់បែបនេះនឹងសាមញ្ញ។ ក្លាយជាកម្មវិធីបន្ថែមលើតារាងដែលមានស្រាប់ដោយមិនប៉ះពាល់ដល់វត្ថុ និងដំណើរការដែលមានស្រាប់។

2. ការចម្លងទិន្នន័យ

បញ្ហាទី XNUMX ដែលត្រូវបានដោះស្រាយដោយស្ថាបត្យកម្មដែលអាចបត់បែនបានគឺមិនសូវច្បាស់ទេហើយមាននៅក្នុងកន្លែងដំបូង។ ការវាស់វែងប្រភេទ SCD2 (ផ្លាស់ប្តូរទំហំយឺតនៃប្រភេទទីពីរ) ទោះបីជាមិនត្រឹមតែពួកវាក៏ដោយ។

នៅក្នុងឃ្លាំងបុរាណ វិមាត្រជាធម្មតាជាតារាងដែលមានកូនសោជំនួស (ជា PK) និងសំណុំនៃសោអាជីវកម្ម និងគុណលក្ខណៈនៅក្នុងជួរឈរដាច់ដោយឡែក។

ប្រសិនបើវិមាត្រគាំទ្រការបង្កើតកំណែ ព្រំដែនសុពលភាពកំណែត្រូវបានបន្ថែមទៅសំណុំស្តង់ដារនៃវាល ហើយកំណែជាច្រើនបង្ហាញនៅក្នុងឃ្លាំងសម្រាប់ជួរមួយក្នុងប្រភព (មួយសម្រាប់ការផ្លាស់ប្តូរនីមួយៗនៅក្នុងគុណលក្ខណៈកំណែ)។

ប្រសិនបើវិមាត្រមានគុណលក្ខណៈកំណែដែលបានផ្លាស់ប្តូរញឹកញាប់យ៉ាងហោចណាស់មួយ ចំនួនកំណែនៃវិមាត្របែបនេះនឹងគួរឱ្យចាប់អារម្មណ៍ (ទោះបីជាគុណលក្ខណៈដែលនៅសល់មិនត្រូវបានកំណែ ឬមិនផ្លាស់ប្តូរក៏ដោយ) ហើយប្រសិនបើមានគុណលក្ខណៈបែបនេះជាច្រើន ចំនួនកំណែអាច កើនឡើងជានិទស្សន្តពីចំនួនរបស់ពួកគេ។ វិមាត្រនេះអាចយកទំហំថាសយ៉ាងច្រើន បើទោះបីជាទិន្នន័យភាគច្រើនដែលវារក្សាទុកគឺគ្រាន់តែស្ទួននៃតម្លៃគុណលក្ខណៈដែលមិនអាចផ្លាស់ប្តូរបានពីជួរផ្សេងទៀតក៏ដោយ។

ក្នុងពេលជាមួយគ្នានេះវាក៏ត្រូវបានគេប្រើញឹកញាប់ផងដែរ។ ភាពមិនធម្មតា - គុណលក្ខណៈមួយចំនួនត្រូវបានរក្សាទុកដោយចេតនាជាតម្លៃមួយ ហើយមិនមែនជាតំណភ្ជាប់ទៅកាន់សៀវភៅយោង ឬវិមាត្រផ្សេងទៀត។ វិធីសាស្រ្តនេះបង្កើនល្បឿនការចូលប្រើទិន្នន័យ ដោយកាត់បន្ថយចំនួននៃការចូលរួមនៅពេលចូលប្រើវិមាត្រ។

ជាធម្មតាវានាំឱ្យមាន ព័ត៌មានដូចគ្នាត្រូវបានរក្សាទុកក្នុងពេលដំណាលគ្នានៅកន្លែងជាច្រើន។. ឧទាហរណ៍ ព័ត៌មានអំពីតំបន់នៃលំនៅដ្ឋាន និងប្រភេទរបស់អតិថិជនអាចត្រូវបានរក្សាទុកក្នុងពេលដំណាលគ្នានៅក្នុងវិមាត្រ "អតិថិជន" និងការពិត "ការទិញ" "ការដឹកជញ្ជូន" និង "ការហៅទៅកាន់មជ្ឈមណ្ឌលហៅទូរស័ព្ទ" ក៏ដូចជានៅក្នុង "អតិថិជន - អ្នកគ្រប់គ្រងអតិថិជន។ "តារាងតំណ។

ជាទូទៅ ការពិពណ៌នាខាងលើអនុវត្តចំពោះវិមាត្រធម្មតា (មិនមែនកំណែ) ប៉ុន្តែនៅក្នុងកំណែដែលពួកគេអាចមានមាត្រដ្ឋានផ្សេងគ្នា៖ ការលេចចេញនូវកំណែថ្មីនៃវត្ថុមួយ (ជាពិសេសនៅក្នុងការរំលឹកឡើងវិញ) នាំឱ្យមិនត្រឹមតែការធ្វើបច្ចុប្បន្នភាពនៃអ្វីដែលពាក់ព័ន្ធទាំងអស់នោះទេ។ តារាង ប៉ុន្តែចំពោះរូបរាងល្បាក់នៃកំណែថ្មីនៃវត្ថុដែលពាក់ព័ន្ធ - នៅពេលដែលតារាងទី 1 ត្រូវបានប្រើដើម្បីសាងសង់តារាងទី 2 និងតារាងទី 2 ត្រូវបានប្រើដើម្បីសាងសង់តារាងទី 3 ។ល។ ទោះបីជាមិនមានគុណលក្ខណៈតែមួយនៃតារាងទី 1 ពាក់ព័ន្ធនឹងការសាងសង់តារាងទី 3 (និងគុណលក្ខណៈផ្សេងទៀតនៃតារាងទី 2 ដែលទទួលបានពីប្រភពផ្សេងទៀតត្រូវបានចូលរួម) កំណែសំណង់នេះនឹងនៅអប្បបរមានាំទៅដល់ការចំណាយបន្ថែម និងអតិបរមារហូតដល់បន្ថែម កំណែនៅក្នុងតារាងទី 3. ដែលមិនមានអ្វីដែលត្រូវធ្វើជាមួយវាទាល់តែសោះ ហើយបន្តចុះក្រោមខ្សែសង្វាក់។

3. ភាពស្មុគស្មាញមិនមែនលីនេអ៊ែរនៃការងារឡើងវិញ

ក្នុងពេលជាមួយគ្នានោះ មុខហាងថ្មីនីមួយៗដែលបង្កើតឡើងនៅលើមូលដ្ឋាននៃកន្លែងផ្សេងទៀតបង្កើនចំនួនកន្លែងដែលទិន្នន័យអាច "បំបែក" នៅពេលដែលការផ្លាស់ប្តូរត្រូវបានធ្វើឡើងចំពោះ ETL ។ នេះនាំឱ្យមានការកើនឡើងនូវភាពស្មុគស្មាញ (និងរយៈពេល) នៃការកែប្រែជាបន្តបន្ទាប់នីមួយៗ។

ប្រសិនបើខាងលើពិពណ៌នាអំពីប្រព័ន្ធដែលមានដំណើរការ ETL កម្រកែប្រែ អ្នកអាចរស់នៅក្នុងគំរូបែបនេះ - អ្នកគ្រាន់តែត្រូវប្រាកដថាការកែប្រែថ្មីត្រូវបានធ្វើឡើងយ៉ាងត្រឹមត្រូវចំពោះវត្ថុដែលពាក់ព័ន្ធទាំងអស់។ ប្រសិនបើការកែប្រែកើតឡើងញឹកញាប់ លទ្ធភាពនៃការតភ្ជាប់ "បាត់" ដោយចៃដន្យ កើនឡើងយ៉ាងខ្លាំង។

លើសពីនេះទៀត ប្រសិនបើយើងពិចារណាថា ETL "កំណែ" មានភាពស្មុគស្មាញជាង "មិនកំណែ" នោះ វាពិតជាលំបាកណាស់ក្នុងការជៀសវាងកំហុសនៅពេលធ្វើបច្ចុប្បន្នភាពជាញឹកញាប់នូវឧបករណ៍ទាំងមូលនេះ។

ការរក្សាទុកវត្ថុ និងគុណលក្ខណៈនៅក្នុង Data Vault និង Anchor Model

វិធីសាស្រ្តដែលស្នើឡើងដោយអ្នកនិពន្ធនៃស្ថាបត្យកម្មដែលអាចបត់បែនបានអាចត្រូវបានបង្កើតដូចខាងក្រោម:

វាចាំបាច់ក្នុងការបែងចែកអ្វីដែលផ្លាស់ប្តូរពីអ្វីដែលនៅដដែល។ នោះគឺរក្សាទុកសោដាច់ដោយឡែកពីគុណលក្ខណៈ។

ទោះយ៉ាងណាក៏ដោយមនុស្សម្នាក់មិនគួរច្រឡំទេ។ មិន​មាន​កំណែ គុណលក្ខណៈជាមួយ មិនផ្លាស់ប្តូរ៖ ទីមួយមិនរក្សាទុកប្រវត្តិនៃការផ្លាស់ប្តូររបស់វាទេ ប៉ុន្តែអាចផ្លាស់ប្តូរ (ឧទាហរណ៍ នៅពេលកែកំហុសបញ្ចូល ឬទទួលទិន្នន័យថ្មី) ទីពីរមិនផ្លាស់ប្តូរទេ។

ទស្សនៈខុសគ្នាលើអ្វីដែលអាចចាត់ទុកថាមិនអាចផ្លាស់ប្តូរបាននៅក្នុង Data Vault និង Anchor Model។

តាមទស្សនៈស្ថាបត្យកម្ម ឃ្លាំងទិន្នន័យអាចត្រូវបានចាត់ទុកថាមិនផ្លាស់ប្តូរ សំណុំនៃសោទាំងមូល - ធម្មជាតិ (TIN របស់អង្គការ កូដផលិតផលក្នុងប្រព័ន្ធប្រភព។ល។) និងពពោះជំនួស។ ក្នុងករណីនេះ គុណលក្ខណៈដែលនៅសល់អាចបែងចែកជាក្រុមតាមប្រភព និង/ឬភាពញឹកញាប់នៃការផ្លាស់ប្តូរ និង រក្សាតារាងដាច់ដោយឡែកសម្រាប់ក្រុមនីមួយៗ ជាមួយនឹងសំណុំឯករាជ្យនៃកំណែ។

នៅក្នុងគំរូ គំរូយុថ្កា ចាត់ទុកថាមិនផ្លាស់ប្តូរ កូនសោជំនួសប៉ុណ្ណោះ។ ខ្លឹមសារ។ អ្វីផ្សេងទៀត (រួមទាំងសោធម្មជាតិ) គ្រាន់តែជាករណីពិសេសនៃគុណលក្ខណៈរបស់វា។ ឯណា គុណលក្ខណៈទាំងអស់គឺឯករាជ្យពីគ្នាទៅវិញទៅមកតាមលំនាំដើមដូច្នេះសម្រាប់គុណលក្ខណៈនីមួយៗ a តារាងដាច់ដោយឡែក.

В ឃ្លាំងទិន្នន័យ តារាងដែលមានកូនសោអង្គភាពត្រូវបានហៅ ហ៊ូបាមី. Hubs តែងតែមានសំណុំនៃវាលថេរ៖

• សោ ធាតុធម្មជាតិ
• កូនសោជំនួស
• ភ្ជាប់ទៅប្រភព
• កត់ត្រាពេលវេលាបន្ថែម

ប្រកាសនៅក្នុង Hubs មិនដែលផ្លាស់ប្តូរ និងមិនមានកំណែ. ខាងក្រៅ hubs គឺស្រដៀងទៅនឹងតារាងប្រភេទ ID-map ដែលប្រើក្នុងប្រព័ន្ធមួយចំនួនដើម្បីបង្កើត surrogates ទោះជាយ៉ាងណាក៏ដោយ វាត្រូវបានណែនាំឱ្យប្រើ hash ពីសំណុំនៃ business keys ជាអ្នកជំនួសនៅក្នុង Data Vault។ វិធីសាស្រ្តនេះជួយសម្រួលដល់ការផ្ទុកទំនាក់ទំនង និងគុណលក្ខណៈពីប្រភព (មិនចាំបាច់ចូលរួមមជ្ឈមណ្ឌលដើម្បីទទួលបានពពោះជំនួសទេ គ្រាន់តែគណនាសញ្ញានៃសោធម្មជាតិ) ប៉ុន្តែអាចបណ្តាលឱ្យមានបញ្ហាផ្សេងទៀត (ដែលពាក់ព័ន្ធ ឧទាហរណ៍ ការប៉ះទង្គិច ករណី និងមិនអាចបោះពុម្ពបាន។ តួអក្សរនៅក្នុង string keys ។ល។ .p.) ដូច្នេះហើយ វាមិនត្រូវបានទទួលយកជាទូទៅទេ។

គុណលក្ខណៈអង្គភាពផ្សេងទៀតទាំងអស់ត្រូវបានរក្សាទុកក្នុងតារាងពិសេសហៅថា ផ្កាយរណប. មជ្ឈមណ្ឌលមួយអាចមានផ្កាយរណបជាច្រើនដែលផ្ទុកសំណុំលក្ខណៈផ្សេងៗគ្នា។

ការចែកចាយគុណលក្ខណៈក្នុងចំណោមផ្កាយរណបកើតឡើងតាមគោលការណ៍ ការផ្លាស់ប្តូររួមគ្នា — ក្នុង​លក្ខណៈ​មិន​កំណែ​របស់​ផ្កាយរណប​មួយ​អាច​ត្រូវ​បាន​រក្សា​ទុក (ឧទាហរណ៍ ថ្ងៃ​ខែ​ឆ្នាំ​កំណើត និង SNILS សម្រាប់​បុគ្គល​ម្នាក់) ក្នុង​មួយ​ទៀត​ដែល​កម្រ​នឹង​ផ្លាស់​ប្តូរ​កំណែ (ឧទាហរណ៍ នាមត្រកូល និង​លេខ​លិខិតឆ្លងដែន) នៅ​ទី​បី​ការ​ផ្លាស់​ប្តូរ​ញឹកញាប់ (ឧទាហរណ៍ អាសយដ្ឋានដឹកជញ្ជូន ប្រភេទ កាលបរិច្ឆេទនៃការបញ្ជាទិញចុងក្រោយ។ល។) ក្នុងករណីនេះ កំណែត្រូវបានអនុវត្តនៅកម្រិតនៃផ្កាយរណបនីមួយៗ ហើយមិនមែនអង្គភាពទាំងមូលទេ ដូច្នេះគួរចែកចាយគុណលក្ខណៈ ដូច្នេះចំនុចប្រសព្វនៃកំណែនៅក្នុងផ្កាយរណបមួយគឺតិចតួចបំផុត (ដែលកាត់បន្ថយចំនួនសរុបនៃកំណែដែលបានរក្សាទុក។ )

ដូចគ្នានេះផងដែរ ដើម្បីបង្កើនប្រសិទ្ធភាពដំណើរការផ្ទុកទិន្នន័យ គុណលក្ខណៈដែលទទួលបានពីប្រភពផ្សេងៗជារឿយៗត្រូវបានបញ្ចូលក្នុងផ្កាយរណបនីមួយៗ។

ផ្កាយរណបទាក់ទងជាមួយ Hub តាមរយៈ សោបរទេស (ដែលត្រូវនឹង cardinality ពី 1 ទៅច្រើន) ។ នេះមានន័យថាតម្លៃគុណលក្ខណៈច្រើន (ឧទាហរណ៍ លេខទូរស័ព្ទទំនាក់ទំនងច្រើនសម្រាប់អតិថិជនម្នាក់) ត្រូវបានគាំទ្រដោយស្ថាបត្យកម្ម "លំនាំដើម" នេះ។

В ម៉ូដែលយុថ្កា តារាងដែលរក្សាទុកកូនសោត្រូវបានគេហៅថា យុថ្កា. ហើយពួកគេរក្សា៖

• មានតែកូនសោជំនួសប៉ុណ្ណោះ។
• ភ្ជាប់ទៅប្រភព
• កត់ត្រាពេលវេលាបន្ថែម

គន្លឹះធម្មជាតិពីចំណុចនៃទិដ្ឋភាពនៃគំរូយុថ្កាត្រូវបានពិចារណា គុណលក្ខណៈធម្មតា។. ជម្រើសនេះហាក់ដូចជាពិបាកយល់ជាង ប៉ុន្តែវាផ្តល់វិសាលភាពកាន់តែច្រើនសម្រាប់ការកំណត់អត្តសញ្ញាណវត្ថុ។

ឧទាហរណ៍ ប្រសិនបើទិន្នន័យអំពីអង្គភាពដូចគ្នាអាចមកពីប្រព័ន្ធផ្សេងៗគ្នា ដែលនីមួយៗប្រើសោធម្មជាតិផ្ទាល់ខ្លួនរបស់វា។ នៅក្នុង Data Vault វាអាចនាំឱ្យមានរចនាសម្ព័ន្ធស្មុគស្មាញនៃ hubs ជាច្រើន (មួយក្នុងមួយប្រភព + កំណែមេបង្រួបបង្រួម) ខណៈពេលដែលនៅក្នុងគំរូ Anchor គន្លឹះធម្មជាតិនៃប្រភពនីមួយៗធ្លាក់ចូលទៅក្នុងគុណលក្ខណៈរបស់វា ហើយអាចប្រើនៅពេលផ្ទុកដោយឯករាជ្យ។ អ្នកផ្សេងទៀតទាំងអស់។

ប៉ុន្តែក៏មានចំណុចមួយដែលមិនគួរឱ្យជឿនៅទីនេះផងដែរ៖ ប្រសិនបើគុណលក្ខណៈពីប្រព័ន្ធផ្សេងៗត្រូវបានបញ្ចូលគ្នានៅក្នុងអង្គភាពមួយ ភាគច្រើនទំនងជាមានមួយចំនួន។ ច្បាប់នៃការ "ស្អិតជាប់"ដែលប្រព័ន្ធត្រូវតែយល់ថាកំណត់ត្រាពីប្រភពផ្សេងៗគ្នាត្រូវគ្នាទៅនឹងឧទាហរណ៍មួយនៃអង្គភាព។

В ឃ្លាំងទិន្នន័យ ច្បាប់ទាំងនេះទំនងជាកំណត់ការបង្កើត "មជ្ឈមណ្ឌលជំនួស" នៃអង្គភាពមេ ហើយមិនមានឥទ្ធិពលលើ Hubs ដែលរក្សាទុកសោប្រភពធម្មជាតិ និងគុណលក្ខណៈដើមរបស់វានោះទេ។ ប្រសិនបើនៅចំណុចមួយចំនួន ច្បាប់នៃការច្របាច់បញ្ចូលគ្នាបានផ្លាស់ប្តូរ (ឬគុណលក្ខណៈដែលវាត្រូវបានធ្វើបច្ចុប្បន្នភាព) វានឹងគ្រប់គ្រាន់ដើម្បីធ្វើកំណែទម្រង់មជ្ឈមណ្ឌលជំនួស។

В ម៉ូដែលយុថ្កា អង្គភាពបែបនេះទំនងជាត្រូវបានរក្សាទុកនៅក្នុង យុថ្កាតែមួយគត់. នេះមានន័យថា គុណលក្ខណៈទាំងអស់ មិនថាមានប្រភពមកពីណាក៏ដោយ នឹងត្រូវចងភ្ជាប់ជាមួយការពពោះជំនួសដូចគ្នា។ ការបំបែកកំណត់ត្រាដែលបានបញ្ចូលគ្នាដោយខុសឆ្គង ហើយជាទូទៅ ការត្រួតពិនិត្យភាពពាក់ព័ន្ធនៃការរួមបញ្ចូលគ្នានៅក្នុងប្រព័ន្ធបែបនេះអាចពិបាកជាង ជាពិសេសប្រសិនបើច្បាប់មានភាពស្មុគស្មាញ និងផ្លាស់ប្តូរញឹកញាប់ ហើយគុណលក្ខណៈដូចគ្នាអាចទទួលបានពីប្រភពផ្សេងៗគ្នា (ទោះបីជាវាប្រាកដ អាចធ្វើទៅបាន ចាប់តាំងពីកំណែគុណលក្ខណៈនីមួយៗរក្សាតំណភ្ជាប់ទៅកាន់ប្រភពរបស់វា)។

ក្នុងករណីណាក៏ដោយប្រសិនបើប្រព័ន្ធរបស់អ្នកត្រូវបានគេសន្មត់ថាអនុវត្តមុខងារ ការដកស្ទួន ការបញ្ចូលគ្នានៃកំណត់ត្រា និងធាតុ MDM ផ្សេងទៀត។វាគួរអោយយកចិត្តទុកដាក់ជាពិសេសចំពោះទិដ្ឋភាពនៃការរក្សាទុកសោធម្មជាតិនៅក្នុងវិធីសាស្រ្តរហ័សរហួន។ វាទំនងជាថាការរចនា Data Vault កាន់តែធំនឹងមានសុវត្ថិភាពជាងនៅក្នុងលក្ខខណ្ឌនៃកំហុសក្នុងការបញ្ចូលគ្នា។

ម៉ូដែលយុថ្កា ក៏ផ្តល់នូវប្រភេទវត្ថុបន្ថែមដែលហៅថា Knot វាពិតជាពិសេស degenerate ប្រភេទនៃយុថ្កាដែលអាចមានគុណលក្ខណៈតែមួយ។ ថ្នាំង​ត្រូវ​បាន​គេ​សន្មត់​ថា​ត្រូវ​បាន​ប្រើ​ដើម្បី​ទុក​ថត​ផ្ទះល្វែង (ឧទាហរណ៍ ភេទ ស្ថានភាព​អាពាហ៍ពិពាហ៍ ប្រភេទ​សេវា​អតិថិជន ។ល។)។ មិនដូច Anchor, Knot មិនមានតារាងគុណលក្ខណៈដែលពាក់ព័ន្ធទេ។ហើយគុណលក្ខណៈតែមួយគត់របស់វា (ឈ្មោះ) តែងតែត្រូវបានរក្សាទុកក្នុងតារាងតែមួយជាមួយនឹងសោ។ ថ្នាំងត្រូវបានភ្ជាប់ទៅយុថ្កាដោយតារាងស្មើ (Tie) តាមរបៀបដូចគ្នានឹងយុថ្កាត្រូវបានភ្ជាប់ទៅគ្នាទៅវិញទៅមក។

មិនមានមតិច្បាស់លាស់ទាក់ទងនឹងការប្រើប្រាស់ Nodes ទេ។ ឧទាហរណ៍, Nikolay Golovដែលជំរុញយ៉ាងសកម្មនូវការប្រើប្រាស់ Anchor Model នៅក្នុងប្រទេសរុស្ស៊ី ជឿ (មិនសមហេតុផល) ថាសម្រាប់សៀវភៅឯកសារយោងតែមួយទេ វាអាចត្រូវបានបញ្ជាក់ដោយប្រាកដថាវា តែងតែ នឹងមានលក្ខណៈឋិតិវន្ត និងកម្រិតតែមួយ ដូច្នេះវាជាការប្រសើរក្នុងការប្រើប្រាស់ភ្លាមៗនូវយុថ្កាពេញលេញសម្រាប់វត្ថុទាំងអស់។

ភាពខុសគ្នាដ៏សំខាន់មួយទៀតរវាង Data Vault និង Anchor model គឺភាពអាចរកបាន លក្ខណៈនៃការតភ្ជាប់:

В ឃ្លាំងទិន្នន័យ តំណភ្ជាប់គឺជាវត្ថុដែលមានលក្ខណៈពេញលេញដូចគ្នានឹង Hubs ហើយអាចមាន លក្ខណៈផ្ទាល់ខ្លួន។ នេះ ម៉ូដែលយុថ្កា តំណភ្ជាប់ត្រូវបានប្រើដើម្បីភ្ជាប់យុថ្កានិង មិន​អាច​មាន​លក្ខណៈ​ផ្ទាល់ខ្លួន​របស់​ពួកគេ​. ភាពខុសប្លែកគ្នានេះនាំឱ្យវិធីសាស្រ្តធ្វើគំរូខុសគ្នាយ៉ាងខ្លាំង អង្គហេតុដែលនឹងពិភាក្សាបន្ថែមទៀត។

ការផ្ទុកការពិត

មុននេះ យើងបានពិភាក្សាជាចំបងអំពីការវាស់វែងគំរូ។ ការពិតមិនសូវច្បាស់ទេ។

В ឃ្លាំងទិន្នន័យ វត្ថុធម្មតាសម្រាប់រក្សាទុកការពិតគឺ តំណភ្ជាប់សូចនាករពិតប្រាកដរបស់ផ្កាយរណបត្រូវបានបន្ថែម។

វិធីសាស្រ្តនេះហាក់ដូចជាវិចារណញាណ។ វាផ្តល់នូវភាពងាយស្រួលក្នុងការចូលទៅកាន់សូចនាករដែលបានវិភាគ ហើយជាទូទៅស្រដៀងទៅនឹងតារាងការពិតបែបប្រពៃណី (មានតែសូចនាករប៉ុណ្ណោះដែលត្រូវបានរក្សាទុកមិននៅក្នុងតារាងខ្លួនឯង ប៉ុន្តែនៅក្នុង "ប្រទេសជិតខាង" មួយ)។ ប៉ុន្តែក៏មានគុណវិបត្តិផងដែរ៖ ការកែប្រែធម្មតាមួយនៃគំរូ - ការពង្រីកគន្លឹះការពិត - ចាំបាច់ ការបន្ថែមកូនសោបរទេសថ្មីទៅតំណ. ហើយនេះ, នៅក្នុងវេន, "បំបែក" ម៉ូឌុលនិងសក្តានុពលបណ្តាលឱ្យតម្រូវការសម្រាប់ការកែប្រែទៅវត្ថុផ្សេងទៀត។

В ម៉ូដែលយុថ្កា ការតភ្ជាប់មិនអាចមានគុណលក្ខណៈផ្ទាល់ខ្លួនរបស់វាទេ ដូច្នេះវិធីសាស្រ្តនេះនឹងមិនដំណើរការទេ - រាល់លក្ខណៈ និងសូចនាករទាំងអស់ត្រូវតែភ្ជាប់ទៅយុថ្កាជាក់លាក់មួយ។ ការសន្និដ្ឋាននេះគឺសាមញ្ញ - ការពិតនីមួយៗក៏ត្រូវការយុថ្កាផ្ទាល់ខ្លួនផងដែរ។. សម្រាប់​អ្វី​ដែល​យើង​ធ្លាប់​យល់​ឃើញ​ថា​ជា​ការ​ពិត នេះ​អាច​មើល​ទៅ​ជា​ធម្មជាតិ - ឧទាហរណ៍ ការពិត​នៃ​ការ​ទិញ​អាច​ត្រូវ​បាន​កាត់​បន្ថយ​យ៉ាង​ល្អឥតខ្ចោះ​ទៅ​នឹង​វត្ថុ "បញ្ជាទិញ" ឬ "បង្កាន់ដៃ" ការ​ចូល​មើល​គេហទំព័រ​ទៅ​វគ្គ​មួយ ។ល។ ប៉ុន្តែក៏មានការពិតផងដែរដែលវាមិនងាយស្រួលទេក្នុងការស្វែងរក "វត្ថុដឹកជញ្ជូន" ធម្មជាតិបែបនេះ - ឧទាហរណ៍ សំណល់នៃទំនិញនៅក្នុងឃ្លាំងនៅដើមថ្ងៃនីមួយៗ។

ដូច្នោះហើយ បញ្ហាជាមួយម៉ូឌុលនៅពេលពង្រីកគន្លឹះការពិតនៅក្នុងគំរូយុថ្កាមិនកើតឡើងទេ (វាគ្រប់គ្រាន់ដើម្បីគ្រាន់តែបន្ថែមទំនាក់ទំនងថ្មីទៅយុថ្កាដែលត្រូវគ្នា) ប៉ុន្តែការរចនាគំរូដើម្បីបង្ហាញការពិតគឺមិនសូវច្បាស់ទេ "សិប្បនិម្មិត" យុថ្កាអាចលេចឡើង។ ដែលបង្ហាញគំរូវត្ថុអាជីវកម្មតាមរបៀបមិនច្បាស់លាស់។

របៀបដែលភាពបត់បែនត្រូវបានសម្រេច

ការស្ថាបនាលទ្ធផលនៅក្នុងករណីទាំងពីរមាន តារាងច្រើនទៀតគួរឱ្យកត់សម្គាល់ជាងការវាស់វែងបែបប្រពៃណី។ ប៉ុន្តែវាប្រហែលជាត្រូវការ ទំហំថាសតិចគួរឱ្យកត់សម្គាល់ ជាមួយនឹងសំណុំនៃគុណលក្ខណៈកំណែដូចគ្នានឹងវិមាត្រប្រពៃណី។ ជាធម្មតាមិនមានវេទមន្តនៅទីនេះទេ - វាគឺអំពីការធ្វើឱ្យមានលក្ខណៈធម្មតា។ តាមរយៈការចែកចាយគុណលក្ខណៈតាមផ្កាយរណប (នៅក្នុង Data Vault) ឬតារាងបុគ្គល (Anchor Model) យើងកាត់បន្ថយ (ឬលុបចោលទាំងស្រុង) ការចម្លងតម្លៃនៃគុណលក្ខណៈមួយចំនួននៅពេលផ្លាស់ប្តូរអ្នកដទៃ.

សម្រាប់ ឃ្លាំងទិន្នន័យ ការឈ្នះនឹងអាស្រ័យលើការចែកចាយគុណលក្ខណៈក្នុងចំណោមផ្កាយរណប និងសម្រាប់ ម៉ូដែលយុថ្កា — គឺស្ទើរតែសមាមាត្រដោយផ្ទាល់ទៅនឹងចំនួនមធ្យមនៃកំណែក្នុងមួយវត្ថុរង្វាស់។

ទោះជាយ៉ាងណាក៏ដោយ ការសន្សំទំហំគឺជាអត្ថប្រយោជន៍ដ៏សំខាន់ ប៉ុន្តែមិនមែនជាអត្ថប្រយោជន៍សំខាន់នៃការរក្សាទុកគុណលក្ខណៈដាច់ដោយឡែកនោះទេ។ រួមគ្នាជាមួយនឹងការផ្ទុកដាច់ដោយឡែកនៃទំនាក់ទំនងវិធីសាស្រ្តនេះធ្វើឱ្យហាង ការរចនាម៉ូឌុល. នេះមានន័យថាការបន្ថែមទាំងលក្ខណៈបុគ្គល និងប្រធានបទថ្មីទាំងមូលនៅក្នុងគំរូបែបនេះមើលទៅដូច រចនាសម្ព័ន្ធទំនើប លើសំណុំវត្ថុដែលមានស្រាប់ដោយមិនផ្លាស់ប្តូរពួកវា។ ហើយនេះគឺជាអ្វីដែលធ្វើឱ្យវិធីសាស្រ្តដែលបានពិពណ៌នាមានភាពបត់បែន។

នេះក៏ប្រហាក់ប្រហែលនឹងការផ្លាស់ប្តូរពីការផលិតដុំទៅជាផលិតកម្មទ្រង់ទ្រាយធំផងដែរ - ប្រសិនបើនៅក្នុងវិធីសាស្រ្តបែបប្រពៃណីតារាងនីមួយៗនៃម៉ូដែលគឺមានតែមួយគត់ និងទាមទារការយកចិត្តទុកដាក់ពិសេស នោះនៅក្នុងវិធីសាស្រ្តដែលអាចបត់បែនបាន វាគឺជាសំណុំនៃ "ផ្នែក" ស្តង់ដាររួចទៅហើយ។ នៅលើដៃម្ខាង មានតារាងច្រើនទៀត ហើយដំណើរការនៃការផ្ទុក និងទាញយកទិន្នន័យគួរតែមើលទៅស្មុគស្មាញជាង។ ម៉្យាងទៀតពួកគេក្លាយជា ធម្មតា. ដែលមានន័យថាអាចមាន ស្វ័យប្រវត្តិ និងទិន្នន័យមេតាត្រូវបានជំរុញ. សំណួរ "តើយើងនឹងដាក់វាដោយរបៀបណា?" ចម្លើយដែលអាចយកផ្នែកសំខាន់នៃការងារលើការកែលម្អការរចនា ឥឡូវនេះគឺមិនមានតម្លៃទេ (ក៏ដូចជាសំណួរអំពីផលប៉ះពាល់នៃការផ្លាស់ប្តូរគំរូលើដំណើរការការងារ។ )

នេះមិនមានន័យថាអ្នកវិភាគមិនត្រូវការនៅក្នុងប្រព័ន្ធបែបនេះទាល់តែសោះ - នរណាម្នាក់នៅតែត្រូវការធ្វើការតាមរយៈសំណុំនៃវត្ថុដែលមានគុណលក្ខណៈ និងស្វែងរកកន្លែង និងរបៀបផ្ទុកវាទាំងអស់។ ប៉ុន្តែបរិមាណការងារក៏ដូចជាលទ្ធភាពនិងការចំណាយនៃកំហុសត្រូវបានកាត់បន្ថយយ៉ាងខ្លាំង។ ទាំងនៅដំណាក់កាលវិភាគ និងកំឡុងពេលបង្កើត ETL ដែលផ្នែកសំខាន់មួយអាចត្រូវបានកាត់បន្ថយចំពោះការកែសម្រួលទិន្នន័យមេតា។

ផ្នែកងងឹត

ទាំងអស់ខាងលើធ្វើឱ្យវិធីសាស្រ្តទាំងពីរពិតជាអាចបត់បែនបាន បច្ចេកវិទ្យាជឿនលឿន និងសមរម្យសម្រាប់ការកែលម្អដដែលៗ។ ជាការពិតណាស់ វាក៏មាន "ធុងនៅក្នុងមួន" ដែលខ្ញុំគិតថាអ្នកអាចទាយបានរួចទៅហើយ។

ការខូចទ្រង់ទ្រាយទិន្នន័យ ដែលបង្កប់នូវម៉ូឌុលនៃស្ថាបត្យកម្មដែលអាចបត់បែនបាន នាំឱ្យមានការកើនឡើងនៃចំនួនតារាង ហើយតាមនោះ លើស ដើម្បីចូលរួមនៅពេលយកគំរូ។ ដើម្បីទទួលបានលក្ខណៈសាមញ្ញទាំងអស់នៃវិមាត្រ ការជ្រើសរើសមួយនៅក្នុងហាងបុរាណគឺគ្រប់គ្រាន់ ប៉ុន្តែស្ថាបត្យកម្មដែលអាចបត់បែនបាននឹងតម្រូវឱ្យមានការភ្ជាប់ស៊េរីទាំងមូល។ លើសពីនេះទៅទៀត ប្រសិនបើការភ្ជាប់ទាំងអស់នេះសម្រាប់របាយការណ៍អាចត្រូវបានសរសេរជាមុន នោះអ្នកវិភាគដែលទម្លាប់ក្នុងការសរសេរ SQL ដោយដៃនឹងរងទុក្ខទ្វេដង។

មានការពិតមួយចំនួនដែលធ្វើឱ្យស្ថានភាពនេះកាន់តែងាយស្រួល៖

នៅពេលធ្វើការជាមួយវិមាត្រធំ លក្ខណៈទាំងអស់របស់វាស្ទើរតែមិនដែលប្រើក្នុងពេលដំណាលគ្នា។ នេះមានន័យថាអាចមានការចូលរួមតិចជាងវាហាក់ដូចជានៅ glance ដំបូងនៅម៉ូដែល។ Data Vault ក៏អាចគិតគូរពីភាពញឹកញាប់នៃការចែករំលែកដែលរំពឹងទុកនៅពេលបែងចែកគុណលក្ខណៈទៅផ្កាយរណប។ ក្នុងពេលជាមួយគ្នានេះ Hubs ឬ Anchors ខ្លួនគេគឺត្រូវការជាចម្បងសម្រាប់ការបង្កើត និងគូសផែនទីពពោះជំនួសនៅដំណាក់កាលនៃការផ្ទុក ហើយកម្រនឹងត្រូវបានប្រើក្នុងសំណួរ (នេះជាការពិតជាពិសេសសម្រាប់ Anchors)។

ការចូលរួមទាំងអស់គឺដោយគន្លឹះ។ លើសពីនេះទៀត វិធី "បង្ហាប់" បន្ថែមទៀតក្នុងការរក្សាទុកទិន្នន័យកាត់បន្ថយការចំណាយលើតារាងស្កេនដែលវាត្រូវការ (ឧទាហរណ៍ នៅពេលត្រងតាមតម្លៃគុណលក្ខណៈ)។ នេះអាចនាំឱ្យការពិតដែលថាការយកគំរូពីមូលដ្ឋានទិន្នន័យធម្មតាជាមួយនឹងការភ្ជាប់ជាច្រើននឹងលឿនជាងការស្កែនទំហំធ្ងន់មួយជាមួយនឹងកំណែជាច្រើនក្នុងមួយជួរ។

ឧទាហរណ៍នៅទីនេះក្នុង នេះ អត្ថបទនេះមានការធ្វើតេស្តប្រៀបធៀបលម្អិតនៃដំណើរការនៃគំរូ Anchor ជាមួយនឹងគំរូពីតារាងមួយ។

ភាគច្រើនអាស្រ័យលើម៉ាស៊ីន។ វេទិកាទំនើបជាច្រើនមានយន្តការបង្កើនប្រសិទ្ធភាពចូលរួមផ្ទៃក្នុង។ ឧទាហរណ៍ MS SQL និង Oracle អាច "រំលង" ចូលរួមជាមួយតារាង ប្រសិនបើទិន្នន័យរបស់ពួកគេមិនត្រូវបានប្រើនៅកន្លែងណាមួយ លើកលែងតែការភ្ជាប់ផ្សេងទៀត ហើយមិនប៉ះពាល់ដល់ការជ្រើសរើសចុងក្រោយ (ការលុបតារាង/ចូលរួម) និង MPP Vertica បទពិសោធន៍របស់សហសេវិកពី Avitoបានបង្ហាញថាជាម៉ាស៊ីនដ៏ល្អសម្រាប់ Anchor Model ដែលបានផ្តល់ការបង្កើនប្រសិទ្ធភាពដោយដៃមួយចំនួននៃផែនការសំណួរ។ ម៉្យាងវិញទៀត ការរក្សាទុក Anchor Model ជាឧទាហរណ៍នៅលើ Click House ដែលមានការគាំទ្រចូលរួមមានកម្រិត មិនទាន់មើលទៅហាក់ដូចជាគំនិតល្អណាស់។

លើសពីនេះទៀតសម្រាប់ស្ថាបត្យកម្មទាំងពីរមាន ចលនាពិសេសធ្វើឱ្យការចូលប្រើទិន្នន័យកាន់តែងាយស្រួល (ទាំងពីទស្សនៈនៃការអនុវត្តសំណួរ និងសម្រាប់អ្នកប្រើប្រាស់ចុងក្រោយ)។ ឧទាហរណ៍, តារាងពិន្ទុតាមពេលវេលា នៅក្នុង Data Vault ឬ មុខងារតារាងពិសេស នៅក្នុងគំរូ Anchor ។

សរុប

ខ្លឹមសារសំខាន់នៃស្ថាបត្យកម្មដែលអាចបត់បែនបានចាត់ទុកថាជាម៉ូឌុលនៃ "ការរចនា" របស់ពួកគេ។

វាគឺជាទ្រព្យសម្បត្តិនេះដែលអនុញ្ញាតឱ្យ៖

• បន្ទាប់​ពី​ការ​រៀបចំ​ដំបូង​មួយ​ចំនួន​ទាក់ទង​នឹង​ការ​ដាក់​ពង្រាយ​ទិន្នន័យ​មេតា និង​ការ​សរសេរ​ក្បួន​ដោះស្រាយ ETL មូលដ្ឋាន ផ្តល់ឱ្យអតិថិជននូវលទ្ធផលដំបូងយ៉ាងឆាប់រហ័ស នៅក្នុងទម្រង់នៃរបាយការណ៍ពីរបីដែលមានទិន្នន័យពីវត្ថុប្រភពមួយចំនួនប៉ុណ្ណោះ។ វាមិនចាំបាច់ក្នុងការគិតទាំងស្រុង (សូម្បីតែនៅកម្រិតកំពូល) គំរូវត្ថុទាំងមូល។
• គំរូទិន្នន័យអាចចាប់ផ្តើមដំណើរការ (និងមានប្រយោជន៍) ដោយគ្រាន់តែវត្ថុ 2-3 ហើយបន្ទាប់មក លូតលាស់បន្តិចម្តងៗ (ទាក់ទងនឹងម៉ូដែល Anchor Nikolai បានអនុវត្ត ការប្រៀបធៀបដ៏ល្អជាមួយ mycelium) ។
• ការកែលម្អភាគច្រើន រួមទាំងការពង្រីកប្រធានបទ និងការបន្ថែមប្រភពថ្មី។ មិនប៉ះពាល់ដល់មុខងារដែលមានស្រាប់ និងមិនបង្កហានិភ័យនៃការបំបែកអ្វីមួយដែលកំពុងដំណើរការ.
• សូមអរគុណដល់ការបំបែកទៅជាធាតុស្តង់ដារ ដំណើរការ ETL នៅក្នុងប្រព័ន្ធបែបនេះមើលទៅដូចគ្នា ការសរសេររបស់ពួកគេផ្តល់ប្រាក់កម្ចីដល់ក្បួនដោះស្រាយ ហើយទីបំផុត ស្វ័យប្រវត្តិកម្ម.

តម្លៃនៃភាពបត់បែននេះគឺ ការសម្តែង. នេះមិនមានន័យថាវាមិនអាចទៅរួចទេក្នុងការសម្រេចបាននូវការអនុវត្តដែលអាចទទួលយកបាននៅលើម៉ូដែលបែបនេះ។ ជាញឹកញាប់ជាងនេះទៅទៀត អ្នកប្រហែលជាត្រូវការការខិតខំប្រឹងប្រែង និងការយកចិត្តទុកដាក់បន្ថែមទៀតចំពោះព័ត៌មានលម្អិត ដើម្បីសម្រេចបាននូវម៉ែត្រដែលអ្នកចង់បាន។

កម្មវិធី

ប្រភេទអង្គភាព ឃ្លាំងទិន្នន័យ

ព័ត៌មានបន្ថែមអំពី Data Vault៖
គេហទំព័ររបស់ Dan Lystadt
ទាំងអស់អំពី Data Vault ជាភាសារុស្សី
អំពី Data Vault នៅលើ Habre

ប្រភេទអង្គភាព គំរូយុថ្កា

ព័ត៌មានលម្អិតបន្ថែមអំពី Anchor Model៖

គេហទំព័ររបស់អ្នកបង្កើត Anchor Model
អត្ថបទអំពីបទពិសោធន៍នៃការអនុវត្ត Anchor Model នៅក្នុង Avito

តារាងសង្ខេបជាមួយនឹងលក្ខណៈទូទៅ និងភាពខុសគ្នានៃវិធីសាស្រ្តដែលបានពិចារណា៖

ប្រភព: www.habr.com