ERP ડેટાબેસેસનું સામાન્યીકરણ અને સોફ્ટવેર ડેવલપમેન્ટ પર તેની અસર: ટોર્ટુગામાં ટેવર્ન ખોલવું

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

દરેક જણ ખુશ છે તેની ખાતરી કેવી રીતે કરવી? તમે આવી સિસ્ટમની ડિઝાઇન અને જાળવણી માટે ઉન્મત્ત થવાનું કેવી રીતે ટાળી શકો? જો સામાન્ય ચાંચિયાઓ અને ખલાસીઓ જ વીશીમાં આવવાનું શરૂ ન કરે તો શું કરવું?

બધું કટ હેઠળ છે. પરંતુ ચાલો ક્રમમાં જઈએ.

1. મર્યાદાઓ અને ધારણાઓ

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

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

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

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

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

2. સામાન્ય સ્વરૂપો

ડેટાબેઝનું પ્રથમ સામાન્ય સ્વરૂપ તમામ વિશેષતાઓની અણુશક્તિ જરૂરી છે.
ખાસ કરીને, જો ઑબ્જેક્ટ Aમાં નોન-કી એટ્રિબ્યુટ a અને b હોય, જેમ કે c=f(a,b) અને ઑબ્જેક્ટ Aનું વર્ણન કરતા કોષ્ટકમાં તમે c એટ્રિબ્યુટનું મૂલ્ય સંગ્રહિત કરો છો, તો ડેટાબેઝમાં પ્રથમ સામાન્ય સ્વરૂપનું ઉલ્લંઘન થાય છે. . ઉદાહરણ તરીકે, જો ઓર્ડર સ્પષ્ટીકરણ જથ્થાને સૂચવે છે, તો માપનના એકમો જે ઉત્પાદનના પ્રકાર પર આધારિત છે: એક કિસ્સામાં તે ટુકડાઓ હોઈ શકે છે, બીજા લિટરમાં, ટુકડાઓ ધરાવતા ત્રીજા પેકેજમાં (Good_count_WR ઉપરના મોડેલમાં) , પછી ડેટાબેઝમાં લક્ષણોની અણુતાનું ઉલ્લંઘન થાય છે. આ કિસ્સામાં, ઓર્ડર સ્પષ્ટીકરણનું ટેબલ ક્લસ્ટર શું હોવું જોઈએ તે કહેવા માટે, તમારે IS માં કાર્ય પ્રક્રિયાના લક્ષિત વર્ણનની જરૂર છે, અને પ્રક્રિયાઓ અલગ હોઈ શકે છે, ત્યાં ઘણા "સાચા" સંસ્કરણો હોઈ શકે છે.

ડેટાબેઝનું બીજું સામાન્ય સ્વરૂપ IS માં કાર્ય પ્રક્રિયાથી સંબંધિત દરેક એન્ટિટી માટે પ્રથમ ફોર્મ અને તેના પોતાના ટેબલનું પાલન જરૂરી છે. જો એક કોષ્ટકમાં c=f1(a) અને d=f2(b) અવલંબન હોય અને ત્યાં કોઈ નિર્ભરતા c=f3(b) ન હોય, તો કોષ્ટકમાં બીજા સામાન્ય સ્વરૂપનું ઉલ્લંઘન થાય છે. ઉપરના ઉદાહરણમાં, ઓર્ડર કોષ્ટકમાં ઓર્ડર અને સરનામા વચ્ચે કોઈ નિર્ભરતા નથી. શેરી અથવા શહેરનું નામ બદલો અને તમને ઓર્ડરની આવશ્યક વિશેષતાઓ પર કોઈ અસર થશે નહીં.

ત્રીજા સામાન્ય ફોર્મ ડેટાબેઝ બીજા સામાન્ય સ્વરૂપનું પાલન અને વિવિધ એન્ટિટીના લક્ષણો વચ્ચે કાર્યાત્મક અવલંબનની ગેરહાજરી જરૂરી છે. આ નિયમ નીચે પ્રમાણે ઘડી શકાય છે: "જેની ગણતરી કરી શકાય છે તે દરેક વસ્તુની ગણતરી કરવી આવશ્યક છે." બીજા શબ્દોમાં કહીએ તો, જો બે ઑબ્જેક્ટ A અને B હોય. ઑબ્જેક્ટ A ના લક્ષણો સંગ્રહિત કરતા કોષ્ટકમાં, લક્ષણ C પ્રગટ થાય છે, અને ઑબ્જેક્ટ B પાસે લક્ષણ b છે, જેમ કે c=f4(b) અસ્તિત્વમાં છે, તો ત્રીજું સામાન્ય સ્વરૂપ ઉલ્લંઘન કરવામાં આવે છે. નીચેના ઉદાહરણમાં, ઓર્ડર રેકોર્ડ પરના ટુકડાઓનું પ્રમાણ (Total_count_WR) સ્પષ્ટપણે ત્રીજા સામાન્ય સ્વરૂપનું ઉલ્લંઘન કરવાનો દાવો કરે છે

3. નોર્મલાઇઝેશન લાગુ કરવા માટેનો મારો અભિગમ

1. માત્ર એક લક્ષ્ય સ્વચાલિત વ્યવસાય પ્રક્રિયા જ વિશ્લેષકને ડેટા સ્ટોરેજ મોડેલ બનાવતી વખતે એન્ટિટી અને વિશેષતાઓ ઓળખવા માટેના માપદંડ પ્રદાન કરી શકે છે. સામાન્ય ડેટા મોડલ બનાવવા માટે પ્રોસેસ મોડલ બનાવવું એ પૂર્વશરત છે.

2. જો નીચેની કેટલીક અથવા બધી શરતો પૂરી થાય તો ERP સિસ્ટમ બનાવવાની વાસ્તવિક પ્રેક્ટિસમાં કડક અર્થમાં ત્રીજું સામાન્ય સ્વરૂપ હાંસલ કરવું વ્યવહારુ ન હોઈ શકે:

• સ્વયંસંચાલિત પ્રક્રિયાઓ ભાગ્યે જ ફેરફારને પાત્ર હોય છે,
• સંશોધન અને વિકાસ માટેની સમયમર્યાદા કડક છે,
• ડેટા અખંડિતતા માટેની આવશ્યકતાઓ પ્રમાણમાં ઓછી છે (ઔદ્યોગિક સૉફ્ટવેરમાં સંભવિત ભૂલો સોફ્ટવેર ગ્રાહક દ્વારા નાણાં અથવા ક્લાયંટની ખોટ તરફ દોરી જતી નથી)
• અને જેમ

વર્ણવેલ શરતો હેઠળ, કેટલીક વસ્તુઓ અને તેમના લક્ષણોના જીવન ચક્રને ઓળખવા અને તેનું વર્ણન કરવાનો ખર્ચ આર્થિક કાર્યક્ષમતાના દૃષ્ટિકોણથી ન્યાયી ન હોઈ શકે.

3. પહેલાથી જ બનાવેલ ISમાં ડેટા મોડલના ડિનોર્મલાઇઝેશનના કોઈપણ પરિણામોને કોડના સંપૂર્ણ પ્રારંભિક અભ્યાસ અને પરીક્ષણ દ્વારા ઘટાડી શકાય છે.

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

5. ડેટાબેઝના ત્રીજા સામાન્ય સ્વરૂપ માટે પ્રયત્ન કરવાની સલાહ આપવામાં આવે છે જો:

• સ્વયંસંચાલિત વ્યવસાય પ્રક્રિયાઓમાં પરિવર્તનની દિશાનું અનુમાન કરવું મુશ્કેલ છે
• અમલીકરણ અને/અથવા વિકાસ ટીમમાં શ્રમનું નબળું વિભાજન છે
• એકીકરણ સર્કિટમાં સમાવિષ્ટ સિસ્ટમો તેમની પોતાની યોજનાઓ અનુસાર વિકસિત થાય છે
• ડેટાની અસંગતતાના પરિણામે કંપની ગ્રાહકો અથવા પૈસા ગુમાવી શકે છે

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

4 ઉદાહરણ માટે સમસ્યા

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

ટેવર્ન ઇન્ફર્મેશન સિસ્ટમ્સ સંકુલમાં નીચેના સોફ્ટવેરનો સમાવેશ થાય છે:

• ક્લાયન્ટ વિશે પ્રારંભિક ચેતવણી પ્રણાલી કે જે લાક્ષણિક લક્ષણોના આધારે તેની શ્રેણીને ઓળખે છે
• રોબોટ પરિચારિકાઓ અને રોબોટ બારટેન્ડર્સ માટે નિયંત્રણ સિસ્ટમ
• વેરહાઉસ અને ડિલિવરી મેનેજમેન્ટ સિસ્ટમ વેચાણ બિંદુ સુધી
• સપ્લાયર રિલેશનશિપ મેનેજમેન્ટ સિસ્ટમ (SURP)

પ્રક્રિયા:

પ્રારંભિક ચેતવણી પ્રણાલી વહાણમાંથી બહાર નીકળતા લોકોને ઓળખે છે. જો કોઈ વ્યક્તિ ક્લીન-શેવ હોય, તો તે તેને નાવિક તરીકે ઓળખાવે છે, જો કોઈ વ્યક્તિ દાઢી ધરાવે છે, તો તેની ઓળખ ચાંચિયા તરીકે થાય છે.

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

મહેમાન નિર્દિષ્ટ ટેબલ પર જાય છે, જ્યાં રોબોટ બારટેન્ડરે તેના માટે કેટેગરી અનુસાર સામાન તૈયાર કર્યો છે. રોબોટ બારટેન્ડર વેરહાઉસ સિસ્ટમને માહિતી પ્રસારિત કરે છે કે ડિલિવરીનો આગળનો ભાગ વધારવો જોઈએ; વેરહાઉસ IS, સ્ટોરેજમાં બાકી રહેલા બેલેન્સના આધારે, મેનેજમેન્ટ સિસ્ટમમાં ખરીદીની વિનંતી જનરેટ કરે છે.

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

5. ડીનોર્મલાઈઝેશનના ઉદાહરણો અને સોફ્ટવેર ડેવલપમેન્ટ પર તેની અસર

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

ક્લાયંટ પ્રકારોની ડિરેક્ટરી બે મૂલ્યો સાથે દેખાય છે: 1 - ચાંચિયાઓ, 2 - નાવિક, કંપનીના સમગ્ર માહિતી સર્કિટ માટે સામાન્ય.

ક્લાયંટ નોટિફિકેશન સિસ્ટમ ઇમેજ પ્રોસેસિંગના પરિણામને માન્ય ક્લાયંટના ઓળખકર્તા (ID) અને તેના પ્રકાર: નાવિક અથવા ચાંચિયા તરીકે તરત જ સંગ્રહિત કરે છે.

ઓળખાયેલ ઑબ્જેક્ટ ID
ગ્રાહક શ્રેણી

100500
ચાંચિયો

100501
ચાંચિયો

100502
નાવિક

ચાલો ફરી એકવાર એ નોંધીએ

1. અમારા ખલાસીઓ વાસ્તવમાં મુંડન કરનારા લોકો છે
2. અમારા ચાંચિયાઓ ખરેખર દાઢીવાળા લોકો છે

આ કિસ્સામાં કઈ સમસ્યાઓ દૂર કરવાની જરૂર છે જેથી અમારી રચના ત્રીજા સામાન્ય સ્વરૂપ માટે પ્રયત્ન કરે:

• એટ્રિબ્યુટ એટોમિસિટી ઉલ્લંઘન - ક્લાયન્ટ કેટેગરી
• વિશ્લેષણ કરેલ હકીકત અને નિષ્કર્ષને એક કોષ્ટકમાં મિશ્રિત કરવું
• વિવિધ સંસ્થાઓના લક્ષણો વચ્ચે નિશ્ચિત કાર્યાત્મક સંબંધ.

સામાન્ય સ્વરૂપમાં, અમને બે કોષ્ટકો મળશે:

• સ્થાપિત લક્ષણોના સમૂહના સ્વરૂપમાં માન્યતા પરિણામ,

ઓળખાયેલ ઑબ્જેક્ટ ID
ચહેરાના વાળ

100500
હા

100501
હા

100502
કોઈ

• સ્થાપિત લાક્ષણિકતાઓનું અર્થઘટન કરવા માટે IS માં એમ્બેડ કરેલા તર્કની એપ્લિકેશન તરીકે ક્લાયંટનો પ્રકાર નક્કી કરવાનું પરિણામ

ઓળખાયેલ ઑબ્જેક્ટ ID
ઓળખ ID
ગ્રાહક શ્રેણી

100500
100001
ચાંચિયો

100501
100002
ચાંચિયો

100502
100003
નાવિક

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

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

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

એક સ્વરૂપમાં કે શોધે છે સામાન્ય કરવા માટે, અમને ઓપરેશનલ ડેટા અને બે ડિરેક્ટરીઓ સાથે બે કોષ્ટકો મળશે:

• સ્થાપિત લક્ષણોના સમૂહના સ્વરૂપમાં માન્યતા પરિણામ,

ઓળખાયેલ ઑબ્જેક્ટ ID
ગ્રેટા ડાબી છાતી પર
ખભા પર પક્ષી
ચહેરાના વાળ

100510
1
1
1

100511
0
0
1

100512

1
0

• ક્લાયંટનો પ્રકાર નક્કી કરવાનું પરિણામ (તેને એક કસ્ટમ દૃશ્ય રહેવા દો જેમાં ડિરેક્ટરીઓમાંથી વર્ણનો પ્રદર્શિત થાય છે)

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

ઉપરોક્ત ઉદાહરણમાં, ત્રણેય સામાન્ય સ્વરૂપોનું ઉલ્લંઘન થાય છે, ચાલો તેમને અલગથી ઉલ્લંઘન કરવાનો પ્રયાસ કરીએ.

પ્રથમ સામાન્ય સ્વરૂપનું ઉલ્લંઘન:

ચાલો કહીએ કે તમારા ટેવર્નની એક 1.5-ટન ગઝેલનો ઉપયોગ કરીને સપ્લાયર્સનાં વેરહાઉસમાંથી માલ તમારા વેરહાઉસમાં પહોંચાડવામાં આવે છે. તમારા ઓર્ડરનું કદ સપ્લાયર્સના ટર્નઓવરની તુલનામાં એટલું નાનું છે કે તેઓ હંમેશા ઉત્પાદનની રાહ જોયા વિના એક પછી એક પૂર્ણ થાય છે. શું તમારે આવી વ્યવસાયિક પ્રક્રિયા સાથે અલગ કોષ્ટકોની જરૂર છે: વાહનો, વાહનોના પ્રકારો, શું તમારા ઓર્ડરમાં પ્રસ્થાન કરાયેલા સપ્લાયરો માટે યોજના અને હકીકત અલગ કરવી જરૂરી છે?

જસ્ટ કલ્પના કરો કે જો તમે પ્રોગ્રામ વિકસાવવા માટે નીચેના મોડેલનો ઉપયોગ કરો છો તો તમારા પ્રોગ્રામરોને કેટલા "વધારાના" કનેક્શન્સ લખવા પડશે.

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

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

ડિલિવરી ન કરાયેલ માલ આગલા ક્રમમાં સમાપ્ત થયો અને નવી ફ્લાઇટમાં રવાના થયો; ટેવર્ન ખાતેના વેરહાઉસમાં લઘુત્તમ બેલેન્સની હાજરીએ ગુમ થયેલા કેસોની નોંધ ન લેવાનું શક્ય બનાવ્યું.

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

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

બીજા સામાન્ય સ્વરૂપનું ઉલ્લંઘન:

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

ત્રીજા સામાન્ય સ્વરૂપનું ઉલ્લંઘન:

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

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

એક અનુભવી વિકાસકર્તા, અલબત્ત, ઉપર જણાવેલ બધી સમસ્યાઓને કેવી રીતે રોકવી તે જાણે છે, પરંતુ, મારા મતે, અનુભવી વિશ્લેષકનું કાર્ય તેમને પ્રકાશમાં લાવવાનું નથી.

હું પ્રકાશનની તૈયારી દરમિયાન તેમના મૂલ્યવાન પ્રતિસાદ માટે અગ્રણી વિકાસકર્તા એવજેની યારુખિનનો આભાર વ્યક્ત કરવા માંગુ છું.

સાહિત્ય

https://habr.com/en/post/254773/
કોનોલી થોમસ, બેગ કેરોલિન. ડેટાબેઝ. ડિઝાઇન, અમલીકરણ અને સમર્થન. સિદ્ધાંત અને વ્યવહાર

સોર્સ: www.habr.com