ચપળ DWH ડિઝાઇન પદ્ધતિઓની ઝાંખી

સ્ટોરેજ સુવિધા વિકસાવવી એ એક લાંબી અને ગંભીર કામગીરી છે.

પ્રોજેક્ટના જીવનમાં મોટાભાગનો આધાર ઑબ્જેક્ટ મોડલ અને બેઝ સ્ટ્રક્ચર શરૂઆતમાં કેટલી સારી રીતે વિચારવામાં આવે છે તેના પર રહેલો છે.

સામાન્ય રીતે સ્વીકૃત અભિગમ સ્ટાર સ્કીમને ત્રીજા સામાન્ય સ્વરૂપ સાથે સંયોજિત કરવાના વિવિધ પ્રકારો રહ્યો છે અને રહે છે. એક નિયમ તરીકે, સિદ્ધાંત અનુસાર: પ્રારંભિક ડેટા - 3NF, શોકેસ - સ્ટાર. વિશ્લેષણાત્મક ભંડાર કેવો હોવો જોઈએ તે વિશે વિચારતી વખતે અનુભવી DWH નિષ્ણાતના ધ્યાનમાં આ અભિગમ, સમય-ચકાસાયેલ અને મોટા પ્રમાણમાં સંશોધન દ્વારા સમર્થિત, પ્રથમ (અને ક્યારેક એકમાત્ર) વસ્તુ છે.

બીજી બાજુ, સામાન્ય રીતે વ્યાપાર અને ખાસ કરીને ગ્રાહકની જરૂરિયાતો ઝડપથી બદલાતી રહે છે, અને ડેટા "ઊંડાણમાં" અને "પહોળાઈમાં" બંને રીતે વૃદ્ધિ પામે છે. અને આ તે છે જ્યાં તારાનો મુખ્ય ગેરલાભ દેખાય છે - મર્યાદિત સુગમતા.

અને જો DWH વિકાસકર્તા તરીકે તમારા શાંત અને હૂંફાળું જીવનમાં અચાનક:

• કાર્ય "ઓછામાં ઓછું કંઈક ઝડપથી કરવા માટે, અને પછી આપણે જોઈશું" ઉભું થયું;
• અઠવાડિયામાં ઓછામાં ઓછા એક વખત નવા સ્ત્રોતોના જોડાણ અને બિઝનેસ મોડલના પુનઃકાર્ય સાથે ઝડપથી વિકાસશીલ પ્રોજેક્ટ દેખાયો;
• એક ગ્રાહક દેખાયો કે જેને કોઈ ખ્યાલ નથી કે સિસ્ટમ કેવી હોવી જોઈએ અને આખરે તેણે કયા કાર્યો કરવા જોઈએ, પરંતુ તે પ્રયોગ કરવા માટે તૈયાર છે અને સતત તેની નજીક જઈને ઇચ્છિત પરિણામને સતત શુદ્ધ કરે છે;
• પ્રોજેક્ટ મેનેજર સારા સમાચાર સાથે આવ્યા: "અને હવે અમારી પાસે ચપળ છે!"

અથવા જો તમને માત્ર એ જાણવામાં જ રસ હોય કે તમે સ્ટોરેજ સુવિધાઓ કેવી રીતે બનાવી શકો છો - કટમાં આપનું સ્વાગત છે!

"સુગમતા" નો અર્થ શું છે?

પ્રથમ, ચાલો વ્યાખ્યાયિત કરીએ કે "લવચીક" કહેવા માટે સિસ્ટમમાં કયા ગુણધર્મો હોવા જોઈએ.

અલગથી, તે ઉલ્લેખનીય છે કે વર્ણવેલ ગુણધર્મો ખાસ કરીને સંબંધિત હોવા જોઈએ સિસ્ટમ, માટે નહીં પ્રક્રિયા તેનો વિકાસ. તેથી, જો તમે વિકાસ પદ્ધતિ તરીકે ચપળતા વિશે વાંચવા માંગતા હો, તો અન્ય લેખો વાંચવું વધુ સારું છે. ઉદાહરણ તરીકે, ત્યાં જ, હેબ્રે પર, ઘણી બધી રસપ્રદ સામગ્રી છે (જેમ કે સમીક્ષા и વ્યવહારુ, અને સમસ્યારૂપ).

આનો અર્થ એ નથી કે વિકાસ પ્રક્રિયા અને ડેટા વેરહાઉસનું માળખું સંપૂર્ણપણે અસંબંધિત છે. એકંદરે, ચપળ આર્કિટેક્ચર માટે ચપળ રીપોઝીટરી વિકસાવવા માટે તે નોંધપાત્ર રીતે સરળ હોવું જોઈએ. જો કે, વ્યવહારમાં, કિમ્બલ અને ડેટાવોલ્ટ અનુસાર ક્લાસિક ડીડબ્લ્યુએચના ચપળ વિકાસ સાથે વધુ વખત વિકલ્પો છે - વોટરફોલ અનુસાર, એક પ્રોજેક્ટ પર તેના બે સ્વરૂપોમાં લવચીકતાના સુખદ સંયોગો કરતાં.

તો, લવચીક સ્ટોરેજમાં કઈ ક્ષમતાઓ હોવી જોઈએ? અહીં ત્રણ મુદ્દા છે:

1. વહેલી ડિલિવરી અને ઝડપી ટર્નઅરાઉન્ડ - આનો અર્થ એ છે કે આદર્શ રીતે પ્રથમ વ્યવસાય પરિણામ (ઉદાહરણ તરીકે, પ્રથમ કાર્યકારી અહેવાલો) શક્ય તેટલું વહેલું પ્રાપ્ત થવું જોઈએ, એટલે કે, સમગ્ર સિસ્ટમ સંપૂર્ણપણે ડિઝાઇન અને અમલમાં આવે તે પહેલાં જ. વધુમાં, દરેક અનુગામી પુનરાવર્તન પણ શક્ય તેટલો ઓછો સમય લેવો જોઈએ.
2. પુનરાવર્તિત સંસ્કારિતા - આનો અર્થ એ છે કે દરેક અનુગામી સુધારણા પહેલાથી કાર્યરત કાર્યક્ષમતાને આદર્શ રીતે અસર કરતી નથી. આ તે ક્ષણ છે જે મોટા પ્રોજેક્ટ્સ પર મોટાભાગે સૌથી મોટું દુઃસ્વપ્ન બની જાય છે - વહેલા અથવા પછીના સમયમાં, વ્યક્તિગત વસ્તુઓ એટલા બધા જોડાણો પ્રાપ્ત કરવાનું શરૂ કરે છે કે અસ્તિત્વમાંના કોષ્ટકમાં ક્ષેત્ર ઉમેરવા કરતાં નજીકની નકલમાં તર્કનું પુનરાવર્તન કરવું સરળ બને છે. અને જો તમને આશ્ચર્ય થાય છે કે હાલના ઑબ્જેક્ટ્સ પરના સુધારાની અસરનું વિશ્લેષણ કરવામાં પોતાને સુધારણા કરતાં વધુ સમય લાગી શકે છે, તો તમે સંભવતઃ હજુ સુધી બેંકિંગ અથવા ટેલિકોમ્સમાં મોટા ડેટા વેરહાઉસ સાથે કામ કર્યું નથી.
3. બદલાતી વ્યવસાયની આવશ્યકતાઓને સતત અનુકૂલન - એકંદર ઑબ્જેક્ટ માળખું ફક્ત સંભવિત વિસ્તરણને ધ્યાનમાં રાખીને જ નહીં, પરંતુ આ આગામી વિસ્તરણની દિશા ડિઝાઇનના તબક્કે કલ્પના પણ ન કરી શકાય તેવી અપેક્ષા સાથે ડિઝાઇન કરવી જોઈએ.

અને હા, આ બધી આવશ્યકતાઓને એક સિસ્ટમમાં પૂરી કરવી શક્ય છે (અલબત્ત, અમુક કિસ્સાઓમાં અને અમુક રિઝર્વેશન સાથે).

નીચે હું ડેટા વેરહાઉસ માટે બે સૌથી લોકપ્રિય ચપળ ડિઝાઇન પદ્ધતિઓનો વિચાર કરીશ - એન્કર મોડેલ и ડેટા વૉલ્ટ. કૌંસની બહાર બાકીની ઉત્તમ તકનીકો છે જેમ કે, ઉદાહરણ તરીકે, EAV, 6NF (તેના શુદ્ધ સ્વરૂપમાં) અને NoSQL સોલ્યુશન્સથી સંબંધિત દરેક વસ્તુ - એટલા માટે નહીં કે તે કોઈક રીતે ખરાબ છે, અને એટલા માટે પણ નહીં કે આ કિસ્સામાં લેખ હસ્તગત કરવાની ધમકી આપશે. સરેરાશ ડિસરનું વોલ્યુમ. તે માત્ર એટલું જ છે કે આ બધું થોડા અલગ વર્ગના ઉકેલો સાથે સંબંધિત છે - કાં તો તમારા પ્રોજેક્ટના એકંદર આર્કિટેક્ચર (જેમ કે EAV) ને ધ્યાનમાં લીધા વિના, તમે વિશિષ્ટ કેસોમાં ઉપયોગ કરી શકો તેવી તકનીકો સાથે અથવા વૈશ્વિક સ્તરે અન્ય માહિતી સંગ્રહ નમૂનાઓ (જેમ કે ગ્રાફ ડેટાબેસેસ) સાથે. અને અન્ય વિકલ્પો NoSQL).

"શાસ્ત્રીય" અભિગમની સમસ્યાઓ અને લવચીક પદ્ધતિઓમાં તેમના ઉકેલો

"શાસ્ત્રીય" અભિગમ દ્વારા મારો મતલબ સારો જૂનો તારો છે (અંતર્ગત સ્તરોના ચોક્કસ અમલીકરણને ધ્યાનમાં લીધા વિના, કિમબોલ, ઇનમોન અને સીડીએમના અનુયાયીઓ મને માફ કરે).

1. કનેક્શન્સની સખત મુખ્યતા

આ મોડેલ ડેટાના સ્પષ્ટ વિભાજન પર આધારિત છે પરિમાણ и તથ્યો. અને આ, ખરેખર, તે તાર્કિક છે - છેવટે, મોટાભાગના કેસોમાં ડેટા વિશ્લેષણ ચોક્કસ વિભાગો (પરિમાણો) માં ચોક્કસ સંખ્યાત્મક સૂચકાંકો (તથ્યો) ના વિશ્લેષણમાં આવે છે.

આ કિસ્સામાં, ઑબ્જેક્ટ્સ વચ્ચેના જોડાણો વિદેશી કીનો ઉપયોગ કરીને કોષ્ટકો વચ્ચેના સંબંધોના સ્વરૂપમાં સ્થાપિત થાય છે. આ તદ્દન સ્વાભાવિક લાગે છે, પરંતુ તરત જ સુગમતાની પ્રથમ મર્યાદા તરફ દોરી જાય છે - જોડાણોની મુખ્યતાની કડક વ્યાખ્યા.

આનો અર્થ એ છે કે ટેબલ ડિઝાઇન સ્ટેજ પર, તમારે સંબંધિત ઑબ્જેક્ટ્સની દરેક જોડી માટે ચોક્કસ રીતે નિર્ધારિત કરવું આવશ્યક છે કે શું તેઓ ઘણા-થી-ઘણા, અથવા માત્ર 1-થી-ઘણા, અને "કઇ દિશામાં" સંબંધિત છે. આ સીધું નક્કી કરે છે કે કઈ કોષ્ટકમાં પ્રાથમિક કી હશે અને કઈ પાસે વિદેશી કી હશે. જ્યારે નવી આવશ્યકતાઓ પ્રાપ્ત થાય ત્યારે આ વલણ બદલવાથી મોટાભાગે પાયાના પુન: કાર્ય તરફ દોરી જશે.

ઉદાહરણ તરીકે, "રોકડ રસીદ" ઑબ્જેક્ટને ડિઝાઇન કરતી વખતે, તમે, વેચાણ વિભાગના શપથ પર આધાર રાખીને, કાર્યવાહીની શક્યતા નક્કી કરી. અનેક ચેક પોઝિશન માટે એક પ્રમોશન (પરંતુ ઊલટું નહીં):

અને થોડા સમય પછી, સહકાર્યકરોએ એક નવી માર્કેટિંગ વ્યૂહરચના રજૂ કરી જેમાં તેઓ સમાન પદ પર કાર્ય કરી શકે એક જ સમયે અનેક પ્રમોશન. અને હવે તમારે સંબંધને અલગ ઑબ્જેક્ટમાં અલગ કરીને કોષ્ટકોને સંશોધિત કરવાની જરૂર છે.

(બધા વ્યુત્પન્ન ઑબ્જેક્ટ્સ કે જેમાં પ્રમોશન ચેક જોડાયા છે તે પણ હવે સુધારવાની જરૂર છે).

ડેટા વૉલ્ટ અને એન્કર મોડલમાં સંબંધો

આ પરિસ્થિતિને ટાળવી એકદમ સરળ હોવાનું બહાર આવ્યું: તમારે આ કરવા માટે વેચાણ વિભાગ પર વિશ્વાસ કરવાની જરૂર નથી. બધા જોડાણો શરૂઆતમાં અલગ કોષ્ટકોમાં સંગ્રહિત થાય છે અને તેને ઘણા-થી-ઘણા તરીકે પ્રક્રિયા કરો.

આ અભિગમ પ્રસ્તાવિત કરવામાં આવ્યો હતો ડેન લિન્સ્ટેડ દૃષ્ટાંતના ભાગ રૂપે ડેટા વૉલ્ટ અને સંપૂર્ણપણે આધારભૂત લાર્સ રોનબેક в એન્કર મોડલ.

પરિણામે, અમને લવચીક પદ્ધતિઓની પ્રથમ વિશિષ્ટ સુવિધા મળે છે:

ઑબ્જેક્ટ્સ વચ્ચેના સંબંધો પિતૃ એન્ટિટીના લક્ષણોમાં સંગ્રહિત નથી, પરંતુ ઑબ્જેક્ટનો એક અલગ પ્રકાર છે.

В ડેટા વૉલ્ટ આવા લિંકિંગ કોષ્ટકો કહેવામાં આવે છે લિંક, અને માં એન્કર મોડલ - ટાઇ. પ્રથમ નજરમાં, તેઓ ખૂબ સમાન છે, જો કે તેમના તફાવતો નામ સાથે સમાપ્ત થતા નથી (જેની નીચે ચર્ચા કરવામાં આવશે). બંને આર્કિટેક્ચરમાં, લિંક કોષ્ટકો લિંક કરી શકે છે કોઈપણ સંખ્યાની સંસ્થાઓ (2 જરૂરી નથી).

આ નિરર્થકતા, પ્રથમ નજરમાં, ફેરફારો માટે નોંધપાત્ર સુગમતા પ્રદાન કરે છે. આવી રચના ફક્ત હાલની લિંક્સની મુખ્યતામાં ફેરફાર માટે જ નહીં, પણ નવા ઉમેરવા માટે પણ સહનશીલ બને છે - જો હવે ચેક પોઝિશનમાં કેશિયરની લિંક છે જેણે તેને તોડ્યો હતો, તો આવી લિંકનો દેખાવ સરળ રીતે થશે. કોઈપણ અસ્તિત્વમાં રહેલા ઑબ્જેક્ટ્સ અને પ્રક્રિયાઓને અસર કર્યા વિના વર્તમાન કોષ્ટકો પર ઍડ-ઑન બનો.

2. ડેટા ડુપ્લિકેશન

લવચીક આર્કિટેક્ચર દ્વારા હલ કરવામાં આવેલ બીજી સમસ્યા ઓછી સ્પષ્ટ છે અને તે પ્રથમ સ્થાને સહજ છે. SCD2 પ્રકાર માપન (બીજા પ્રકારનાં પરિમાણો ધીમે ધીમે બદલાતાં), જો કે માત્ર તે જ નહીં.

ક્લાસિક વેરહાઉસમાં, એક પરિમાણ સામાન્ય રીતે એક ટેબલ હોય છે જેમાં સરોગેટ કી (PK તરીકે) અને અલગ કૉલમમાં બિઝનેસ કી અને વિશેષતાઓનો સમૂહ હોય છે.

જો કોઈ પરિમાણ સંસ્કરણને સમર્થન આપે છે, તો ફીલ્ડના માનક સમૂહમાં સંસ્કરણની માન્યતાની સીમાઓ ઉમેરવામાં આવે છે, અને સ્ત્રોતમાં એક પંક્તિ માટે રીપોઝીટરીમાં ઘણી આવૃત્તિઓ દેખાય છે (આવૃત્તિકૃત વિશેષતાઓમાં દરેક ફેરફાર માટે એક).

જો કોઈ પરિમાણમાં ઓછામાં ઓછી એક વારંવાર બદલાતી આવૃત્તિની વિશેષતા હોય, તો આવા પરિમાણના સંસ્કરણોની સંખ્યા પ્રભાવશાળી હશે (બાકીના લક્ષણો સંસ્કરણિત ન હોય અથવા ક્યારેય બદલાતા ન હોય તો પણ), અને જો આવી ઘણી વિશેષતાઓ હોય, તો સંસ્કરણોની સંખ્યા તેમની સંખ્યાથી ઝડપથી વૃદ્ધિ પામે છે. આ પરિમાણ ડિસ્ક સ્પેસનો નોંધપાત્ર જથ્થો લઈ શકે છે, જો કે તે સંગ્રહિત કરેલો મોટાભાગનો ડેટા અન્ય પંક્તિઓમાંથી અપરિવર્તનશીલ વિશેષતા મૂલ્યોની ડુપ્લિકેટ છે.

તે જ સમયે, તેનો ઉપયોગ ઘણી વાર થાય છે વિકૃતિકરણ - કેટલીક વિશેષતાઓ ઈરાદાપૂર્વક મૂલ્ય તરીકે સંગ્રહિત કરવામાં આવે છે, અને સંદર્ભ પુસ્તક અથવા અન્ય પરિમાણની લિંક તરીકે નહીં. આ અભિગમ ડેટા એક્સેસને ઝડપી બનાવે છે, પરિમાણને ઍક્સેસ કરતી વખતે જોડાવાની સંખ્યા ઘટાડે છે.

સામાન્ય રીતે આ તરફ દોરી જાય છે સમાન માહિતી એકસાથે ઘણી જગ્યાએ સંગ્રહિત થાય છે. ઉદાહરણ તરીકે, રહેઠાણના ક્ષેત્ર અને ક્લાયંટની કેટેગરી વિશેની માહિતી એકસાથે "ક્લાયન્ટ" પરિમાણો અને "ખરીદી", "ડિલિવરી" અને "કૉલ સેન્ટર કૉલ્સ" હકીકતો તેમજ "ક્લાયન્ટ - ક્લાયન્ટ મેનેજર" માં સંગ્રહિત કરી શકાય છે. "લિંક ટેબલ.

સામાન્ય રીતે, ઉપરોક્ત વર્ણવેલ નિયમિત (બિન-આવૃત્તિ વિનાના) પરિમાણોને લાગુ પડે છે, પરંતુ સંસ્કરણવાળામાં તેઓનું પ્રમાણ અલગ હોઈ શકે છે: ઑબ્જેક્ટના નવા સંસ્કરણનો ઉદભવ (ખાસ કરીને પૂર્વાવલોકનમાં) માત્ર સંબંધિત તમામ અપડેટ્સ તરફ દોરી જાય છે. કોષ્ટકો, પરંતુ સંબંધિત ઑબ્જેક્ટ્સના નવા સંસ્કરણોના કેસ્કેડિંગ દેખાવ માટે - જ્યારે કોષ્ટક 1 નો ઉપયોગ કોષ્ટક 2 બનાવવા માટે થાય છે, અને કોષ્ટક 2 નો ઉપયોગ કોષ્ટક 3 વગેરે બનાવવા માટે થાય છે. કોષ્ટક 1 ના નિર્માણમાં કોષ્ટક 3 ની એક પણ વિશેષતા સામેલ ન હોય તો પણ (અને અન્ય સ્રોતોમાંથી મેળવેલ કોષ્ટક 2 ની અન્ય વિશેષતાઓ સામેલ છે), આ બાંધકામનું સંસ્કરણ ઓછામાં ઓછું વધારાના ઓવરહેડ તરફ દોરી જશે અને વધુમાં વધુ કોષ્ટક 3 માં આવૃત્તિઓ. જેને તેની સાથે કોઈ લેવાદેવા નથી, અને આગળ સાંકળ નીચે.

3. પુનઃકાર્યની બિનરેખીય જટિલતા

તે જ સમયે, દરેક નવા સ્ટોરફ્રન્ટ બીજાના આધારે બનાવવામાં આવે છે તે સ્થાનોની સંખ્યામાં વધારો કરે છે જ્યાં ETL માં ફેરફારો કરવામાં આવે ત્યારે ડેટા "ડાઇવર્જ" થઈ શકે છે. આ, બદલામાં, દરેક અનુગામી પુનરાવર્તનની જટિલતા (અને અવધિ) માં વધારો તરફ દોરી જાય છે.

જો ઉપરોક્ત ભાગ્યે જ સંશોધિત ETL પ્રક્રિયાઓ સાથે સિસ્ટમોનું વર્ણન કરે છે, તો તમે આવા દાખલામાં જીવી શકો છો - તમારે ફક્ત ખાતરી કરવાની જરૂર છે કે તમામ સંબંધિત ઑબ્જેક્ટ્સમાં નવા ફેરફારો યોગ્ય રીતે કરવામાં આવ્યા છે. જો પુનરાવર્તનો વારંવાર થાય છે, તો આકસ્મિક રીતે ઘણા જોડાણો "ગુમ" થવાની સંભાવના નોંધપાત્ર રીતે વધે છે.

જો, વધુમાં, અમે ધ્યાનમાં લઈએ કે "સંસ્કરણિત" ETL "બિન-આવૃત્તિ" કરતાં નોંધપાત્ર રીતે વધુ જટિલ છે, તો આ સમગ્ર સુવિધાને વારંવાર અપડેટ કરતી વખતે ભૂલો ટાળવી ખૂબ મુશ્કેલ બની જાય છે.

ડેટા વૉલ્ટ અને એન્કર મૉડલમાં ઑબ્જેક્ટ્સ અને એટ્રિબ્યુટ્સનો સંગ્રહ કરવો

લવચીક આર્કિટેક્ચરના લેખકો દ્વારા પ્રસ્તાવિત અભિગમ નીચે પ્રમાણે ઘડી શકાય છે:

જે સમાન રહે છે તેનાથી શું ફેરફારો થાય છે તેને અલગ કરવું જરૂરી છે. એટલે કે, વિશેષતાઓથી અલગ કી સ્ટોર કરો.

જો કે, કોઈએ મૂંઝવણ ન કરવી જોઈએ આવૃત્તિ નથી સાથે લક્ષણ અપરિવર્તિત: પ્રથમ તેના ફેરફારોનો ઇતિહાસ સંગ્રહિત કરતું નથી, પરંતુ બદલી શકે છે (ઉદાહરણ તરીકે, ઇનપુટ ભૂલ સુધારતી વખતે અથવા નવો ડેટા પ્રાપ્ત કરતી વખતે); બીજો ક્યારેય બદલાતો નથી.

ડેટા વૉલ્ટ અને એન્કર મૉડલમાં બરાબર શું અપરિવર્તનશીલ ગણી શકાય તેના પર દૃષ્ટિકોણ અલગ છે.

આર્કિટેક્ચરલ દૃષ્ટિકોણથી ડેટા વૉલ્ટ, અપરિવર્તિત ગણી શકાય ચાવીઓનો સંપૂર્ણ સેટ - કુદરતી (સંસ્થાનો TIN, સ્ત્રોત સિસ્ટમમાં ઉત્પાદન કોડ વગેરે) અને સરોગેટ. આ કિસ્સામાં, બાકીના લક્ષણોને સ્ત્રોત અને/અથવા ફેરફારોની આવર્તન અનુસાર જૂથોમાં વિભાજિત કરી શકાય છે અને દરેક જૂથ માટે અલગ ટેબલ જાળવો આવૃત્તિઓના સ્વતંત્ર સમૂહ સાથે.

દૃષ્ટાંતમાં એન્કર મોડલ અપરિવર્તિત ગણવામાં આવે છે માત્ર સરોગેટ કી સાર. બાકીનું બધું (કુદરતી ચાવીઓ સહિત) તેના લક્ષણોનો માત્ર એક વિશિષ્ટ કેસ છે. જેમાં બધા લક્ષણો મૂળભૂત રીતે એકબીજાથી સ્વતંત્ર છે, તેથી દરેક લક્ષણ માટે a અલગ ટેબલ.

В ડેટા વૉલ્ટ એન્ટિટી કી ધરાવતી કોષ્ટકો કહેવામાં આવે છે હુબામી. હબમાં હંમેશા ફિલ્ડનો નિશ્ચિત સમૂહ હોય છે:

• નેચરલ એન્ટિટી કી
• સરોગેટ કી
• સ્ત્રોતની લિંક
• સમય ઉમેરવાનો રેકોર્ડ કરો

હબમાં પોસ્ટ ક્યારેય બદલાતું નથી અને તેની પાસે કોઈ સંસ્કરણ નથી. બાહ્ય રીતે, હબ સરોગેટ્સ જનરેટ કરવા માટે કેટલીક સિસ્ટમમાં ઉપયોગમાં લેવાતા ID-નકશા પ્રકારના કોષ્ટકો જેવા જ છે, જો કે, ડેટા વૉલ્ટમાં સરોગેટ તરીકે બિઝનેસ કીના સમૂહમાંથી હેશનો ઉપયોગ કરવાની ભલામણ કરવામાં આવે છે. આ અભિગમ સ્રોતોમાંથી સંબંધો અને વિશેષતાઓને લોડ કરવાનું સરળ બનાવે છે (સરોગેટ મેળવવા માટે તમારે હબમાં જોડાવાની જરૂર નથી, તમારે ફક્ત કુદરતી કીના હેશની ગણતરી કરવાની જરૂર છે), પરંતુ અન્ય સમસ્યાઓનું કારણ બની શકે છે (ઉદાહરણ તરીકે, અથડામણને સંબંધિત , કેસ અને સ્ટ્રિંગ કીમાં છાપવા યોગ્ય ન હોય તેવા અક્ષરો વગેરે. પી.), તેથી તે સામાન્ય રીતે સ્વીકારવામાં આવતું નથી.

અન્ય તમામ એન્ટિટી એટ્રિબ્યુટ્સ નામના વિશિષ્ટ કોષ્ટકોમાં સંગ્રહિત થાય છે ઉપગ્રહો. એક હબમાં અનેક ઉપગ્રહો હોઈ શકે છે જે લક્ષણોના અલગ-અલગ સેટ સ્ટોર કરી શકે છે.

ઉપગ્રહો વચ્ચે વિશેષતાઓનું વિતરણ સિદ્ધાંત અનુસાર થાય છે સંયુક્ત ફેરફાર - એક સેટેલાઇટમાં બિન-આવૃત્તિવાળા લક્ષણો સંગ્રહિત કરી શકાય છે (ઉદાહરણ તરીકે, વ્યક્તિ માટે જન્મ તારીખ અને SNILS), બીજામાં - ભાગ્યે જ બદલાતી આવૃત્તિઓ (ઉદાહરણ તરીકે, છેલ્લું નામ અને પાસપોર્ટ નંબર), ત્રીજામાં - વારંવાર બદલાતી (ઉદાહરણ તરીકે, વિતરણ સરનામું, શ્રેણી, છેલ્લા ઓર્ડરની તારીખ, વગેરે). આ કિસ્સામાં, વર્ઝનિંગ વ્યક્તિગત ઉપગ્રહોના સ્તરે હાથ ધરવામાં આવે છે, અને સમગ્ર એન્ટિટીના સ્તરે નહીં, તેથી વિશેષતાઓનું વિતરણ કરવાની સલાહ આપવામાં આવે છે જેથી એક ઉપગ્રહની અંદરના સંસ્કરણોનું આંતરછેદ ન્યૂનતમ હોય (જે સંગ્રહિત સંસ્કરણોની કુલ સંખ્યાને ઘટાડે છે. ).

ઉપરાંત, ડેટા લોડિંગ પ્રક્રિયાને ઑપ્ટિમાઇઝ કરવા માટે, વિવિધ સ્રોતોમાંથી મેળવેલ વિશેષતાઓ ઘણીવાર વ્યક્તિગત ઉપગ્રહોમાં શામેલ કરવામાં આવે છે.

ઉપગ્રહો દ્વારા હબ સાથે વાતચીત થાય છે બહાર ની ચાવી (જે 1-થી-ઘણા કાર્ડિનલિટીને અનુરૂપ છે). આનો અર્થ એ છે કે બહુવિધ વિશેષતા મૂલ્યો (ઉદાહરણ તરીકે, એક ક્લાયંટ માટે બહુવિધ સંપર્ક ફોન નંબરો) આ "ડિફોલ્ટ" આર્કિટેક્ચર દ્વારા સમર્થિત છે.

В એન્કર મોડલ કોષ્ટકો કે જે કી સ્ટોર કરે છે તે કહેવામાં આવે છે એન્કર. અને તેઓ રાખે છે:

• માત્ર સરોગેટ કીઓ
• સ્ત્રોતની લિંક
• સમય ઉમેરવાનો રેકોર્ડ કરો

એન્કર મોડલના દૃષ્ટિકોણથી કુદરતી કીઓ ગણવામાં આવે છે સામાન્ય લક્ષણો. આ વિકલ્પ સમજવામાં વધુ મુશ્કેલ લાગે છે, પરંતુ તે ઑબ્જેક્ટને ઓળખવા માટે વધુ અવકાશ આપે છે.

ઉદાહરણ તરીકે, જો સમાન એન્ટિટી વિશેનો ડેટા વિવિધ સિસ્ટમોમાંથી આવી શકે છે, જેમાંથી દરેક તેની પોતાની કુદરતી કીનો ઉપયોગ કરે છે. ડેટા વૉલ્ટમાં, આનાથી કેટલાક હબ (સ્રોત દીઠ એક + એકીકૃત મુખ્ય સંસ્કરણ) ની જગ્યાએ બોજારૂપ માળખું થઈ શકે છે, જ્યારે એન્કર મોડેલમાં, દરેક સ્રોતની કુદરતી કી તેના પોતાના લક્ષણમાં આવે છે અને સ્વતંત્ર રીતે લોડ કરતી વખતે તેનો ઉપયોગ કરી શકાય છે. બીજા બધા.

પરંતુ અહીં એક કપટી મુદ્દો પણ છે: જો વિવિધ સિસ્ટમોના લક્ષણો એક એન્ટિટીમાં જોડવામાં આવે, તો સંભવતઃ ત્યાં કેટલાક છે. "ગ્લુઇંગ" ના નિયમો, જેના દ્વારા સિસ્ટમે સમજવું જોઈએ કે વિવિધ સ્ત્રોતોમાંથી રેકોર્ડ્સ એન્ટિટીના એક ઉદાહરણને અનુરૂપ છે.

В ડેટા વૉલ્ટ આ નિયમો મોટે ભાગે રચના નક્કી કરશે મુખ્ય એન્ટિટીનું "સરોગેટ હબ". અને કુદરતી સ્ત્રોત કી અને તેમની મૂળ વિશેષતાઓને સંગ્રહિત કરતા હબને કોઈપણ રીતે પ્રભાવિત કરતા નથી. જો કોઈ સમયે મર્જિંગ નિયમો બદલાય છે (અથવા તે વિશેષતાઓ કે જેના દ્વારા તે કરવામાં આવે છે તે અપડેટ કરવામાં આવે છે), તે સરોગેટ હબને ફરીથી ફોર્મેટ કરવા માટે પૂરતું હશે.

В એન્કર મોડેલ આવી એન્ટિટી મોટે ભાગે સંગ્રહિત કરવામાં આવશે એકમાત્ર એન્કર. આનો અર્થ એ છે કે તમામ વિશેષતાઓ, પછી ભલે તે ગમે તે સ્ત્રોતમાંથી આવે, સમાન સરોગેટ સાથે બંધાયેલ હશે. ભૂલથી મર્જ કરેલા રેકોર્ડ્સને અલગ કરવા અને, સામાન્ય રીતે, આવી સિસ્ટમમાં મર્જ કરવાની સુસંગતતાનું નિરીક્ષણ કરવું વધુ મુશ્કેલ હોઈ શકે છે, ખાસ કરીને જો નિયમો ખૂબ જટિલ હોય અને વારંવાર બદલાતા હોય, અને સમાન લક્ષણ વિવિધ સ્રોતોમાંથી મેળવી શકાય છે (જોકે તે ચોક્કસપણે છે. શક્ય છે, કારણ કે દરેક એટ્રિબ્યુટ વર્ઝન તેના સ્ત્રોતની લિંક જાળવી રાખે છે).

કોઈપણ કિસ્સામાં, જો તમારી સિસ્ટમ કાર્યક્ષમતાને અમલમાં મૂકવાનું માનવામાં આવે છે ડુપ્લિકેશન, મર્જિંગ રેકોર્ડ્સ અને અન્ય MDM તત્વો, ચપળ પદ્ધતિઓમાં કુદરતી ચાવીઓ સંગ્રહિત કરવાના પાસાઓ પર વિશેષ ધ્યાન આપવું યોગ્ય છે. સંભવ છે કે બલ્કિયર ડેટા વૉલ્ટ ડિઝાઇન અચાનક મર્જ ભૂલોના સંદર્ભમાં વધુ સુરક્ષિત હશે.

એન્કર મોડેલ નામનો વધારાનો ઑબ્જેક્ટ પ્રકાર પણ પૂરો પાડે છે ગાંઠ તે અનિવાર્યપણે ખાસ છે ડિજનરેટ પ્રકારનો એન્કર, જેમાં માત્ર એક વિશેષતા હોઈ શકે છે. નોડ્સનો ઉપયોગ ફ્લેટ ડિરેક્ટરીઓ (ઉદાહરણ તરીકે, લિંગ, વૈવાહિક સ્થિતિ, ગ્રાહક સેવા શ્રેણી, વગેરે) સ્ટોર કરવા માટે કરવામાં આવે છે. એન્કરથી વિપરીત, ગાંઠ કોઈ સંકળાયેલ વિશેષતા કોષ્ટકો નથી, અને તેની એકમાત્ર વિશેષતા (નામ) હંમેશા કી સાથે સમાન કોષ્ટકમાં સંગ્રહિત થાય છે. નોડ્સ ટાઈ ટેબલ (ટાઈ) દ્વારા એન્કર સાથે એ જ રીતે જોડાયેલા હોય છે જે રીતે એન્કર એકબીજા સાથે જોડાયેલા હોય છે.

નોડ્સના ઉપયોગ અંગે કોઈ સ્પષ્ટ અભિપ્રાય નથી. દાખ્લા તરીકે, નિકોલે ગોલોવ, જે રશિયામાં એન્કર મોડલના ઉપયોગને સક્રિયપણે પ્રોત્સાહન આપે છે, તે માને છે (ગેરવાજબી રીતે નહીં) કે એક પણ સંદર્ભ પુસ્તક માટે તે નિશ્ચિતપણે કહી શકાય નહીં કે તે હંમેશાં સ્થિર અને સિંગલ-લેવલ હશે, તેથી તમામ ઑબ્જેક્ટ્સ માટે તરત જ સંપૂર્ણ સુવિધાયુક્ત એન્કરનો ઉપયોગ કરવો વધુ સારું છે.

ડેટા વૉલ્ટ અને એન્કર મોડલ વચ્ચેનો બીજો મહત્વનો તફાવત એ ઉપલબ્ધતા છે જોડાણના લક્ષણો:

В ડેટા વૉલ્ટ લિંક્સ એ હબ જેવી જ સંપૂર્ણ સુવિધાયુક્ત વસ્તુઓ છે અને હોઈ શકે છે પોતાના લક્ષણો. આ એન્કર મોડેલ લિંક્સનો ઉપયોગ ફક્ત એન્કર્સને કનેક્ટ કરવા માટે થાય છે અને તેમના પોતાના લક્ષણો હોઈ શકતા નથી. આ તફાવત નોંધપાત્ર રીતે અલગ મોડેલિંગ અભિગમમાં પરિણમે છે તથ્યો, જેની આગળ ચર્ચા કરવામાં આવશે.

હકીકત સંગ્રહ

આ પહેલાં, અમે મુખ્યત્વે માપન મોડેલિંગ વિશે વાત કરી હતી. હકીકતો થોડી ઓછી સ્પષ્ટ છે.

В ડેટા વૉલ્ટ તથ્યો સંગ્રહિત કરવા માટેની એક લાક્ષણિક વસ્તુ છે લિંક, જેના ઉપગ્રહોમાં વાસ્તવિક સૂચકાંકો ઉમેરવામાં આવે છે.

આ અભિગમ સાહજિક લાગે છે. તે વિશ્લેષિત સૂચકાંકોની સરળ ઍક્સેસ પ્રદાન કરે છે અને સામાન્ય રીતે પરંપરાગત તથ્ય કોષ્ટક જેવું જ હોય ​​છે (ફક્ત સૂચકાંકો કોષ્ટકમાં જ સંગ્રહિત નથી, પરંતુ "પડોશીમાં" એકમાં). પરંતુ ત્યાં મુશ્કેલીઓ પણ છે: મોડેલના લાક્ષણિક ફેરફારોમાંથી એક - હકીકત કીનું વિસ્તરણ - જરૂરી છે લિંક પર નવી વિદેશી કી ઉમેરી રહ્યા છીએ. અને આ, બદલામાં, મોડ્યુલારિટીને "તોડે છે" અને સંભવિતપણે અન્ય ઑબ્જેક્ટ્સમાં ફેરફારોની જરૂરિયાતનું કારણ બને છે.

В એન્કર મોડેલ કનેક્શનની પોતાની વિશેષતાઓ હોઈ શકતી નથી, તેથી આ અભિગમ કામ કરશે નહીં - સંપૂર્ણપણે બધા લક્ષણો અને સૂચકો એક વિશિષ્ટ એન્કર સાથે જોડાયેલા હોવા જોઈએ. આમાંથી નિષ્કર્ષ સરળ છે - દરેક હકીકતને તેના પોતાના એન્કરની પણ જરૂર હોય છે. આપણે જેને હકીકતો તરીકે સમજવા માટે ટેવાયેલા છીએ તેમાંથી કેટલાક માટે, આ કુદરતી લાગે છે - ઉદાહરણ તરીકે, ખરીદીની હકીકતને "ઓર્ડર" અથવા "રસીદ", સત્રમાં સાઇટની મુલાકાત વગેરેમાં સંપૂર્ણપણે ઘટાડી શકાય છે. પરંતુ એવા તથ્યો પણ છે કે જેના માટે આવા કુદરતી "વાહક પદાર્થ" શોધવાનું એટલું સરળ નથી - ઉદાહરણ તરીકે, દરેક દિવસની શરૂઆતમાં વેરહાઉસમાં માલના અવશેષો.

તદનુસાર, એન્કર મોડેલમાં ફેક્ટ કીને વિસ્તૃત કરતી વખતે મોડ્યુલારિટી સાથે સમસ્યાઓ ઊભી થતી નથી (તે ફક્ત અનુરૂપ એન્કર સાથે એક નવો સંબંધ ઉમેરવા માટે પૂરતો છે), પરંતુ તથ્યો દર્શાવવા માટે મોડેલની રચના ઓછી અસ્પષ્ટ છે; "કૃત્રિમ" એન્કર દેખાઈ શકે છે. જે બિઝનેસ ઑબ્જેક્ટ મોડલને અસ્પષ્ટ રીતે પ્રદર્શિત કરે છે.

કેવી રીતે સુગમતા પ્રાપ્ત થાય છે

બંને કિસ્સાઓમાં પરિણામી બાંધકામ સમાવે છે નોંધપાત્ર રીતે વધુ કોષ્ટકોપરંપરાગત માપ કરતાં. પરંતુ તે લાગી શકે છે નોંધપાત્ર રીતે ઓછી ડિસ્ક જગ્યા પરંપરાગત પરિમાણ તરીકે વર્ઝન કરેલ વિશેષતાઓના સમાન સમૂહ સાથે. સ્વાભાવિક રીતે, અહીં કોઈ જાદુ નથી - તે બધું સામાન્યકરણ વિશે છે. ઉપગ્રહો (ડેટા વૉલ્ટમાં) અથવા વ્યક્તિગત કોષ્ટકો (એન્કર મોડલ) પર વિશેષતાઓનું વિતરણ કરીને, અમે ઘટાડીએ છીએ (અથવા સંપૂર્ણપણે દૂર કરીએ છીએ) જ્યારે અન્યને બદલતી વખતે કેટલીક વિશેષતાઓના મૂલ્યોનું ડુપ્લિકેશન.

માટે ડેટા વૉલ્ટ જીતનો આધાર ઉપગ્રહો વચ્ચે વિશેષતાઓના વિતરણ પર રહેશે અને તેના માટે એન્કર મોડેલ — માપન ઑબ્જેક્ટ દીઠ સંસ્કરણોની સરેરાશ સંખ્યાના લગભગ સીધા પ્રમાણસર છે.

જો કે, જગ્યાની બચત એ એક મહત્વપૂર્ણ છે, પરંતુ મુખ્ય નથી, વિશેષતાઓને અલગથી સ્ટોર કરવાનો ફાયદો. સંબંધોના અલગ સંગ્રહ સાથે, આ અભિગમ સ્ટોર બનાવે છે મોડ્યુલર ડિઝાઇન. આનો અર્થ એ છે કે આવા મોડેલમાં વ્યક્તિગત વિશેષતાઓ અને સંપૂર્ણ નવા વિષય વિસ્તારો બંને ઉમેરવાથી એવું લાગે છે સુપરસ્ટ્રક્ચર ઑબ્જેક્ટ્સના અસ્તિત્વમાંના સેટ પર તેમને બદલ્યા વિના. અને આ બરાબર તે છે જે વર્ણવેલ પદ્ધતિઓને લવચીક બનાવે છે.

આ પીસ પ્રોડક્શનથી સામૂહિક ઉત્પાદનમાં સંક્રમણ જેવું પણ છે - જો પરંપરાગત અભિગમમાં મોડેલનું દરેક ટેબલ અનન્ય છે અને તેને વિશેષ ધ્યાન આપવાની જરૂર છે, તો પછી લવચીક પદ્ધતિઓમાં તે પહેલાથી જ પ્રમાણભૂત "ભાગો" નો સમૂહ છે. એક તરફ, ત્યાં વધુ કોષ્ટકો છે, અને ડેટા લોડ કરવાની અને પુનઃપ્રાપ્ત કરવાની પ્રક્રિયાઓ વધુ જટિલ દેખાવી જોઈએ. બીજી બાજુ, તેઓ બની જાય છે લાક્ષણિક. જેનો અર્થ છે કે ત્યાં હોઈ શકે છે સ્વચાલિત અને મેટાડેટા સંચાલિત. પ્રશ્ન "આપણે તેને કેવી રીતે મૂકીશું?", જેનો જવાબ ડિઝાઇન સુધારણા પરના કાર્યનો નોંધપાત્ર ભાગ લઈ શકે છે, તે હવે તે મૂલ્યવાન નથી (તેમજ કાર્ય પ્રક્રિયાઓ પર મોડેલને બદલવાની અસર વિશેનો પ્રશ્ન. ).

આનો અર્થ એ નથી કે આવી સિસ્ટમમાં વિશ્લેષકોની બિલકુલ જરૂર નથી - કોઈએ હજી પણ લક્ષણોવાળા ઑબ્જેક્ટ્સના સમૂહ દ્વારા કામ કરવું પડશે અને તે બધું ક્યાં અને કેવી રીતે લોડ કરવું તે નક્કી કરવું પડશે. પરંતુ કાર્યની માત્રા, તેમજ ભૂલની સંભાવના અને કિંમત, નોંધપાત્ર રીતે ઘટાડેલી છે. વિશ્લેષણના તબક્કે અને ETL ના વિકાસ દરમિયાન, જે નોંધપાત્ર રીતે મેટાડેટાના સંપાદન માટે ઘટાડી શકાય છે.

ઘાટા બાજુ

ઉપરોક્ત તમામ બંને અભિગમોને સાચા અર્થમાં લવચીક, તકનીકી રીતે અદ્યતન અને પુનરાવર્તિત સુધારણા માટે યોગ્ય બનાવે છે. અલબત્ત, ત્યાં "મલમમાં બેરલ" પણ છે, જે મને લાગે છે કે તમે પહેલેથી જ અનુમાન કરી શકો છો.

ડેટાનું વિઘટન, જે લવચીક આર્કિટેક્ચરની મોડ્યુલારિટીને નીચે આપે છે, તે કોષ્ટકોની સંખ્યામાં વધારો તરફ દોરી જાય છે અને તે મુજબ, ઓવરહેડ નમૂના લેતી વખતે જોડાવા માટે. પરિમાણની તમામ વિશેષતાઓ મેળવવા માટે, ક્લાસિક સ્ટોરમાં એક પસંદગી પૂરતી છે, પરંતુ લવચીક આર્કિટેક્ચરને જોડાવાની સંપૂર્ણ શ્રેણીની જરૂર પડશે. તદુપરાંત, જો અહેવાલો માટે આ બધા જોડાઓ અગાઉથી લખી શકાય, તો વિશ્લેષકો કે જેઓ હાથથી એસક્યુએલ લખવા ટેવાયેલા છે તેઓને બમણું નુકસાન થશે.

ત્યાં ઘણા તથ્યો છે જે આ પરિસ્થિતિને સરળ બનાવે છે:

મોટા પરિમાણો સાથે કામ કરતી વખતે, તેના તમામ લક્ષણો લગભગ ક્યારેય એકસાથે ઉપયોગમાં લેવાતા નથી. આનો અર્થ એ છે કે મોડેલ પર પ્રથમ નજરમાં લાગે છે તેના કરતાં ઓછા જોડા હોઈ શકે છે. ઉપગ્રહોને વિશેષતાઓ ફાળવતી વખતે ડેટા વૉલ્ટ શેરિંગની અપેક્ષિત આવર્તનને પણ ધ્યાનમાં લઈ શકે છે. તે જ સમયે, હબ અથવા એન્કર પોતે જ લોડિંગ સ્ટેજ પર સરોગેટ્સ બનાવવા અને મેપ કરવા માટે મુખ્યત્વે જરૂરી છે અને ભાગ્યે જ પ્રશ્નોમાં ઉપયોગમાં લેવાય છે (આ ખાસ કરીને એન્કર માટે સાચું છે).

બધા જોડાઓ કી દ્વારા છે. વધુમાં, ડેટા સ્ટોર કરવાની વધુ "સંકુચિત" રીત જ્યાં જરૂર હોય ત્યાં સ્કેનિંગ કોષ્ટકોના ઓવરહેડને ઘટાડે છે (ઉદાહરણ તરીકે, જ્યારે વિશેષતા મૂલ્ય દ્વારા ફિલ્ટર કરતી વખતે). આ એ હકીકત તરફ દોરી શકે છે કે જોડાવાના સમૂહ સાથે સામાન્ય ડેટાબેઝમાંથી નમૂના લેવું એ પંક્તિ દીઠ ઘણા સંસ્કરણો સાથે એક ભારે પરિમાણને સ્કેન કરવા કરતાં પણ વધુ ઝડપી હશે.

ઉદાહરણ તરીકે, અહીં માં આ લેખમાં એક ટેબલમાંથી નમૂના સાથે એન્કર મોડેલની કામગીરીનું વિગતવાર તુલનાત્મક પરીક્ષણ છે.

એન્જિન પર ઘણું નિર્ભર છે. ઘણા આધુનિક પ્લેટફોર્મમાં આંતરિક જોડાવાની ઑપ્ટિમાઇઝેશન મિકેનિઝમ્સ હોય છે. ઉદાહરણ તરીકે, એમએસ એસક્યુએલ અને ઓરેકલ જો અન્ય જોઇન સિવાય ક્યાંય પણ તેમના ડેટાનો ઉપયોગ કરવામાં આવતો ન હોય અને અંતિમ પસંદગી (ટેબલ/જોઇન એલિમિનેશન) અને MPP વર્ટીકાને અસર કરતું ન હોય તો કોષ્ટકો સાથે જોડાવાનું "છોડી" શકે છે. એવિટોના સાથીદારોનો અનુભવ, ક્વેરી પ્લાનના કેટલાક મેન્યુઅલ ઓપ્ટિમાઇઝેશનને જોતાં, એન્કર મોડલ માટે ઉત્તમ એન્જિન સાબિત થયું છે. બીજી તરફ, એન્કર મોડલને સંગ્રહિત કરવું, ઉદાહરણ તરીકે, ક્લિક હાઉસ પર, જેમાં મર્યાદિત જોડાવા માટે સપોર્ટ છે, તે હજુ સુધી ખૂબ સારો વિચાર નથી લાગતો.

વધુમાં, બંને આર્કિટેક્ચર માટે ત્યાં છે ખાસ ચાલ, ડેટા એક્સેસને સરળ બનાવે છે (ક્વેરી કામગીરીના દૃષ્ટિકોણથી અને અંતિમ વપરાશકર્તાઓ માટે બંને). દાખ્લા તરીકે, પોઇન્ટ-ઇન-ટાઇમ કોષ્ટકો ડેટા વૉલ્ટમાં અથવા ખાસ ટેબલ કાર્યો એન્કર મોડેલમાં.

કુલ

માનવામાં આવતા લવચીક આર્કિટેક્ચરનો મુખ્ય સાર એ તેમની "ડિઝાઇન" ની મોડ્યુલારિટી છે.

તે આ મિલકત છે જે પરવાનગી આપે છે:

• મેટાડેટા જમાવટ અને મૂળભૂત ETL અલ્ગોરિધમ્સ લખવા સંબંધિત કેટલીક પ્રારંભિક તૈયારી પછી, પ્રથમ પરિણામ સાથે ગ્રાહકને ઝડપથી પ્રદાન કરો માત્ર થોડા સ્રોત ઑબ્જેક્ટ્સમાંથી ડેટા ધરાવતા કેટલાક અહેવાલોના સ્વરૂપમાં. સમગ્ર ઑબ્જેક્ટ મૉડલને (ઉચ્ચ સ્તરે પણ) સંપૂર્ણપણે વિચારવું જરૂરી નથી.
• ડેટા મૉડલ માત્ર 2-3 ઑબ્જેક્ટ્સ સાથે કામ કરવાનું શરૂ કરી શકે છે (અને ઉપયોગી થઈ શકે છે), અને પછી ધીમે ધીમે વધવું (એન્કર મોડેલ નિકોલાઈ વિશે લાગુ માયસેલિયમ સાથે સરસ સરખામણી).
• વિષય વિસ્તારને વિસ્તારવા અને નવા સ્ત્રોતો ઉમેરવા સહિત મોટાભાગના સુધારા હાલની કાર્યક્ષમતાને અસર કરતું નથી અને જે પહેલેથી કામ કરી રહ્યું છે તેને તોડવાનું જોખમ ઊભું કરતું નથી.
• પ્રમાણભૂત તત્વોમાં વિઘટન કરવા બદલ આભાર, આવી સિસ્ટમોમાં ETL પ્રક્રિયાઓ સમાન દેખાય છે, તેમનું લેખન અલ્ગોરિધમાઇઝેશન અને છેવટે, ઓટોમેશન.

આ સુગમતાની કિંમત છે કામગીરી. આનો અર્થ એ નથી કે આવા મોડેલ્સ પર સ્વીકાર્ય પ્રદર્શન પ્રાપ્ત કરવું અશક્ય છે. વધુ વખત નહીં, તમે ઇચ્છો તે મેટ્રિક્સ પ્રાપ્ત કરવા માટે તમારે વધુ પ્રયત્નો અને વિગતવાર ધ્યાનની જરૂર પડી શકે છે.

Приложения

એન્ટિટી પ્રકારો ડેટા વૉલ્ટ

ડેટા વૉલ્ટ વિશે વધુ માહિતી:
ડેન Lystadt વેબસાઇટ
રશિયનમાં ડેટા વૉલ્ટ વિશે બધું
Habré પર ડેટા વૉલ્ટ વિશે

એન્ટિટી પ્રકારો એન્કર મોડલ

એન્કર મોડલ વિશે વધુ વિગતો:

એન્કર મોડલના નિર્માતાઓની વેબસાઇટ
એવિટોમાં એન્કર મોડલના અમલીકરણના અનુભવ વિશેનો લેખ

સામાન્ય લક્ષણો અને માનવામાં આવેલા અભિગમોના તફાવતો સાથેનો સારાંશ કોષ્ટક:

સોર્સ: www.habr.com