डेटा मॉडल वैश्वीकरण के बारे में याद रखने योग्य 7 प्रमुख बातें

बहुत कम डेटाबेस लेखक किसी भी सार्थक तरीके से वैश्वीकरण और स्थानीयकरण की चुनौतियों का उल्लेख करते हैं। डेटाबेस आर्किटेक्ट्स से दूरदर्शिता की समान कमी है। तथ्य यह है कि कई लेखक और डिजाइनर अक्सर बहुत 'स्व-केंद्रित' होते हैं:वे डेटा मॉडल बनाते हैं (या लिखते हैं) जो केवल उनके स्थानीय समय क्षेत्र, पते आदि को ठीक से संभालते हैं।

स्व-केंद्रित दृष्टिकोण में एक बड़ी समस्या है:परिणामी मॉडल केवल स्थानीय डेटा का समर्थन करेगा। आज की इंटरनेट-ईंधन वाली दुनिया में, एप्लिकेशन अक्सर दुनिया भर के उपयोगकर्ताओं द्वारा अप्रत्याशित रूप से एक्सेस किए जाते हैं। हमें इस अंतरराष्ट्रीय दर्शकों के लिए यथासंभव लचीलेपन का समर्थन करने की आवश्यकता है। इसलिए, हमें अपने डेटा मॉडल को वैश्वीकृत दृष्टिकोण के साथ डिजाइन करने की आवश्यकता है।

मैं बहुत भाग्यशाली हूं कि एक बहुत ही बहुराष्ट्रीय और बहुभाषी वातावरण में काम कर रहा हूं, इसलिए मैंने सीखा है कि परियोजना की शुरुआत में वैश्वीकरण के मुद्दों को कैसे संभाला जा सकता है। इसे ध्यान में रखते हुए, मैंने एक डेटा मॉडल बनाने के लिए सात महत्वपूर्ण बिंदुओं को एक साथ रखा है जो अंतर्राष्ट्रीय उपयोग का समर्थन करेगा।

जब आप संख्या स्वरूपण को देखते हैं तो दो बातों पर ध्यान देना चाहिए:वह आउटपुट जो उपयोगकर्ता देखते हैं (अर्थात प्रारूप), और अंतर्निहित डेटा प्रकार।

आपको इस बारे में चिंता करने की आवश्यकता नहीं है कि आपके डेटा मॉडल में नंबर कैसे प्रदर्शित होंगे - डेटाबेस सिस्टम दशमलव संख्याओं के भंडारण को संभालेगा और आपके एप्लिकेशन को दशमलव संख्याएँ प्रदर्शित होने के तरीके ("।" या "," को दशमलव के रूप में समायोजित करना चाहिए) बिंदु, उदाहरण के लिए)। इसी तरह, आपको इस बारे में चिंता करने की ज़रूरत नहीं है कि आपका डेटा मॉडल किस हज़ार विभाजक (जैसे कि एक अवधि या अल्पविराम) का उपयोग करेगा।

यह रही बात: मॉडलिंग करते समय अपने डेटा प्रकार सही ढंग से चुनें। आपके एप्लिकेशन को आउटपुट स्वरूपण को संभालना चाहिए।

उदाहरण के लिए, मौसम स्टेशन अनुप्रयोग के इस सरल मॉडल में, मौसम माप (तापमान, आर्द्रता, वर्षा) को फ्लोटिंग-पॉइंट नंबरों के रूप में संग्रहीत किया जाता है। लेकिन कीमत की जानकारी दशमलव में होती है, हर मौसम केंद्र के जीपीएस निर्देशांक के समान।

यदि आप मुद्राओं से संबंधित जानकारी संग्रहीत कर रहे हैं, तो आपको प्रत्येक मुद्रा के लिए दशमलव स्थानों की सही संख्या संग्रहीत करनी होगी। अधिकांश मुद्राओं में दो दशमलव स्थान होते हैं, लेकिन कुछ में कोई नहीं होता है (यानी चिली पेसो), एक (मालागासी एरीरी), तीन (ट्यूनीशियाई दिनार) या चार दशमलव स्थान (चिली का यूनिडाड डी फ़ोमेंटो, खाते की एक इकाई जिसका उपयोग किसी को व्यक्त करने के लिए किया जाता है। मूल्य मूल्यों की श्रेणी।)

इसलिए, सुनिश्चित करें कि डेटा मॉडल में आपके "राशि" फ़ील्ड दो से अधिक दशमलव स्थानों का समर्थन करते हैं - जबकि चार दशमलव स्थान बहुत दुर्लभ हैं, ऐसा होता है। तीन दशमलव स्थान अधिक सामान्य हैं। उदाहरण के लिए, छह अलग-अलग देशों (बहरीन, इराक, जॉर्डन, कुवैत, लीबिया, ट्यूनीशिया) में दीनार और एक देश (ओमान) में रियाल को तीन दशमलव स्थानों की आवश्यकता होती है।

प्वाइंट नंबर 1: मॉडलिंग करते समय अपना डेटा प्रकार सही ढंग से चुनें।

मुद्राओं से संबंधित एक अन्य महत्वपूर्ण बिंदु विनिमय दर है। ये और भी अधिक सटीकता की मांग करते हैं। कई प्रणालियाँ विनिमय दरों में केवल 4-6 महत्वपूर्ण अंक प्रदान करती हैं; कभी-कभी मुद्राओं के बीच एक स्केलिंग कारक होता है जिसमें काफी भिन्न मूल्य होते हैं। हालांकि, चार या छह महत्वपूर्ण अंकों का मतलब यह नहीं है कि छह दशमलव स्थान होंगे। इंडोनेशियाई रुपिया और यूरो के बीच विनिमय दर की जाँच करें:0.0000668755। यह आपके विनिमय-दर क्षेत्र में संग्रहीत करने के लिए बहुत से दशमलव स्थान हैं।

प्वाइंट नंबर 2: जब विनिमय दरों की बात आती है तो आपके मॉडल को उच्च स्तर की सटीकता - बहुत सारे दशमलव स्थानों - को संभालने की आवश्यकता हो सकती है।

नीचे हमने कीमतों के साथ एक ऑनलाइन स्टोर का एक उदाहरण बनाया है। हमने एक साधारण तालिका भी जोड़ी है (एक्वा में हाइलाइट की गई) जो ऐतिहासिक विनिमय दरों सहित मुद्रा विनिमय दरों को संग्रहीत करती है। exchange_rate तालिका एक मुद्रा से जुड़ी हुई है (currency_id , जो आईएसओ 4217 मुद्रा कोड है)। हम एक विशेष दिन पर प्रत्येक मुद्रा के लिए एक विनिमय दर संग्रहीत करने की अनुमति देते हैं (rate_date ), और प्रत्येक मुद्रा के लिए एक सक्रिय विनिमय दर है।

जाहिर है, इस दर तालिका का उपयोग करने के लिए आपको कुछ अतिरिक्त जानकारी की आवश्यकता होगी। उदाहरण के लिए, इन विनिमय दरों को किस आधार मुद्रा के विरुद्ध परिभाषित किया गया है? यूरो या यूएस डॉलर विशिष्ट हो सकते हैं, लेकिन आपके आवेदन को यहां सटीक जानकारी की आवश्यकता होगी।

वैकल्पिक रूप से, एक अधिक जटिल मॉडल मुद्रा-जोड़े, मध्य-दर (या बैंक दर) और उन मुद्रा जोड़े के बीच 'खरीद' और 'बिक्री' दरों को संग्रहीत कर सकता है।

प्वाइंट नंबर 3: आपके मॉडल में पर्याप्त जानकारी होनी चाहिए ताकि एप्लिकेशन डेटा का ठीक से उपयोग कर सके।

मैंने अक्सर ऐसे सिस्टम देखे हैं जो केवल तीन-अंकीय क्षेत्र कोड, तीन-अंकीय विनिमय, और चार-अंकीय ग्राहक संख्या (यानी 012-345-6789) के साथ उत्तर अमेरिकी दस-अंकीय फ़ोन नंबर का समर्थन करते हैं। यह पूर्वाग्रह कुछ हद तक समझ में आता है; लोग ऐसे सिस्टम बनाते हैं जो उनके स्थानीय उपयोगकर्ताओं का समर्थन करते हैं। हालांकि, डेटा मॉडलिंग को इस संभावना की अनदेखी नहीं करनी चाहिए कि वैश्विक उपयोगकर्ता आपके सिस्टम तक पहुंच सकते हैं। (नोट:दस अंकों की लंबाई का उपयोग अन्य नंबरों के लिए भी किया जा सकता है, जैसे कि फ्रेंच मोबाइल फोन, लेकिन प्रारूप अलग है (अर्थात 06 12 34 56 78)।)

आइए इसे एक उदाहरण के रूप में लेते हैं:मान लीजिए कि मैं फ्रांस की सीमा के ठीक बाहर रहता हूं, लेकिन मैं फ्रांस में काम करता हूं। इसलिए, जबकि मुझे फ्रेंच एप्लिकेशन और सेवा प्रदाताओं का उपयोग करने की आवश्यकता हो सकती है, मेरा मोबाइल फोन नंबर फ्रेंच नंबर नहीं है। जिन सिस्टमों में 06 या 07 से शुरू होने वाले दस अंकों के मोबाइल नंबर की आवश्यकता होती है, वे मेरे काम नहीं आएंगे। फ्रांसीसी रेलवे टिकट प्राप्त करने के लिए, फ्रांस (आदि, आदि) में एक संगीत कार्यक्रम के लिए टिकट खरीदने के लिए, मुझे एक फ्रांसीसी फोन नंबर प्राप्त करने के लिए मजबूर किया जाएगा। कष्टप्रद, कम से कम कहने के लिए।

यह रही बात: जब डेटा मॉडल में फ़ोन नंबर की कमी होती है, तो डेटा मॉडल संशोधनों की आवश्यकता होगी गैर-स्थानीय उपयोगकर्ताओं का समर्थन करने के लिए। आदर्श रूप से, सभी घटनाओं को संभालने के लिए मॉडल में पर्याप्त लचीलापन शामिल किया जाना चाहिए।

एक अधिक तार्किक डेटा मॉडल विभिन्न लंबाई (कुछ क्षेत्रों में 16 अंकों तक) और गैर-संख्यात्मक वर्णों (जैसे अंतरराष्ट्रीय फोन नंबर के लिए सार्वभौमिक "+" प्रतीक) के फोन नंबरों का समर्थन करेगा। निश्चित रूप से, कुछ एप्लिकेशन "स्थानीय नियमों" को लागू करके अधिक सत्यापन कर सकते हैं जिससे स्थानीय डेवलपर्स अधिक परिचित होंगे। अन्य ऐप्स अन्य डेटा स्रोतों तक पहुंचने के लिए स्थानीय फ़ोन नंबरों का उपयोग कर सकते हैं, जैसे किसी फ़ोन नंबर के आधार पर किसी पते को सत्यापित करना या पुनर्प्राप्त करना।

डेटा मॉडल को जानकारी संग्रहीत करने में लचीलेपन का समर्थन करना चाहिए। एप्लिकेशन या उसका UI अधिक प्रतिबंधात्मक हो सकता है या अतिरिक्त सत्यापन कर सकता है।

विदेश में रहने वाले एक अमेरिकी के रूप में, मुझे अक्सर डेटा मॉडल के उदाहरण और पैटर्न मिलते हैं जो बहुत अधिक अमेरो-केंद्रित होते हैं। उदाहरण के लिए, एक गैर-अमेरिकी यह नहीं समझ सकता कि Zip+4 . क्या है है और इसलिए उसे इस बात की कोई समझ नहीं होगी कि एक लेखक यह क्यों कहता है कि इस डोमेन में NOT NULL विशेषता होनी चाहिए।

यह अमेरो-केंद्रित दृश्य किताबों में भी मौजूद है। उदाहरण के लिए, काफी व्यापक पुस्तक "डेटा मॉडल पैटर्न" लें। विचार के सम्मेलन" डेविड सी. हे द्वारा। श्री हे के पते, साइटों, भौगोलिक स्थानों, भूमि पार्सल और भौगोलिक संरचना तत्वों की बहुत जटिल व्याख्या में कनाडा के उदाहरण शामिल हैं, लेकिन फिर भी, यह जानकारी सभी को आसानी से समझ में नहीं आ सकती है।

श्री हे के पैटर्न का कहना है कि पता विशेषताओं में शामिल होंगे:

पते का "पाठ", साथ ही कम से कम "शहर", "राज्य", और "डाक (ज़िप) कोड"।

अब, श्री हे तुरंत एक फुटनोट में समझाते हैं कि:

मॉडल का संदर्भ निर्धारित करेगा कि यह विशेषता "ज़िप कोड" है या "डाक कोड"। यदि ग्राहक संगठन निकट भविष्य के लिए पूरी तरह से संयुक्त राज्य अमेरिका के भीतर काम करेगा, तो नौ-अंकीय, दो-भाग वाले संख्यात्मक "ज़िप कोड" की धारणा बनाई जा सकती है। यदि नहीं, तो "ज़िप कोड" "डाक कोड" बन जाना चाहिए और कोई प्रारूपण धारणा संभव नहीं है।

हालांकि, वह यह उल्लेख करने में विफल रहता है कि "राज्य" अमेरिका में एक राज्य, कनाडा में एक प्रांत या लगभग किसी भी अन्य देश के लिए एक अशक्त विशेषता हो सकता है, क्योंकि देशों के भीतर "राज्य" शायद ही कभी अमेरिका, कनाडा के बाहर मौजूद होते हैं (जहां वे प्रांत कहलाते हैं लेकिन समान रूप से कार्य करते हैं) और ऑस्ट्रेलिया। निश्चित रूप से, अन्य देशों में प्रांत और क्षेत्र होते हैं, लेकिन इनका उपयोग शायद ही कभी किसी पते के हिस्से के रूप में किया जाता है।

यह स्पष्ट करने के लिए कि यह पता समस्या कितनी गंभीर हो सकती है, मैंने अमेरिकी और गैर-अमेरिकी दोनों पतों के लिए एक डेटा मॉडल बनाया। (नोट:यह पूरा मॉडल नहीं है।)

PrimaryPhone US_Customer तालिका केवल दस या उससे कम वर्णों वाले फ़ोन नंबर संग्रहीत करती है। Customer तालिका का PrimaryPhone विशेषता 15 अंकों के साथ "+" के फ़ोन नंबर की अनुमति देती है, जो कि E.164 द्वारा निर्दिष्ट अधिकतम है।

TimeOffset US_Customer तालिका केवल चार समय क्षेत्रों की अनुमति देती है:पूर्वी समय, मध्य समय, पर्वतीय समय और प्रशांत समय (डेटा मॉडल में इस रूप में संग्रहीत:0 =पूर्वी, 1 =मध्य, 2 =पर्वत, 3 =प्रशांत)। संयोग से, यह अमेरिका और उसके क्षेत्रों में सभी समय क्षेत्रों को भी कवर नहीं करता है। इसके विपरीत, Timezone Customer तालिका ग्राहक के समय क्षेत्र के लिए अंतर्राष्ट्रीय कोड संग्रहीत करती है, चाहे वह कहीं भी हो।

इसके बाद, पोस्टल/ज़िप कोड को देखें। अमेरिका को 5 अंकों के ज़िप कोड की आवश्यकता है (Zip US_Address टेबल) प्लस वैकल्पिक ZIP+4 (Zip4 US_Address टेबल)। Address तालिका में अधिक लचीला PostCode है खेत। लंबाई के अलावा, PostCode . में संग्रहीत की जा सकने वाली जानकारी पर कोई प्रतिबंध नहीं है; बेशक, आवेदन डाक कोड पर जांच लागू कर सकता है।

यह भी ध्यान दें कि यूएस और गैर-यूएस डिज़ाइन दोनों में एक देश के भीतर क्षेत्रों के लिए एक फ़ील्ड है (State US_Address तालिका और Region Address तालिका), लेकिन यूएस डिज़ाइन के लिए आवश्यक है कि 2-वर्णों का राज्य संक्षिप्त नाम शामिल किया जाए। साथ ही, ध्यान दें कि यूएस डिज़ाइन अंतरराष्ट्रीय पते स्वीकार नहीं करता है, जबकि अंतरराष्ट्रीय पता संस्करण करता है (इसलिए 2-वर्ण आईएसओ देश कोड Address टेबल)।

यह रही बात: पतों के अपने डेटा मॉडल को एक इलाके तक सीमित न रखें; विभिन्न शैलियों के लिए पर्याप्त जगह छोड़ दें।

5. दिनांक और समय स्वरूपण

डेटा मॉडल का संबंध एक से अधिक दिनांक और समय प्रारूपों से नहीं होना चाहिए; एप्लिकेशन वास्तविक प्रदर्शन को संभालता है। यह विभिन्न तरीकों से किया जा सकता है:

• महीने की पहली शैली, उत्तरी अमेरिका और अन्य जगहों में आम:mm-dd-yyyy
• पहले दिन की शैली, जो यूरोप में अधिक आम है:dd-mm-yyyy
• वर्ष-पहली शैली, जिसका उपयोग ISO 8601 दिनांक प्रारूप के रूप में किया जाता है:yyyy-mm-dd

यह रही बात: यह दोहराव हो सकता है, लेकिन हम इसे फिर से कहेंगे:मॉडलिंग करते समय अपने डेटा प्रकार को सही ढंग से चुनें। इससे एप्लिकेशन कोड के लिए संग्रहीत मानों की व्याख्या करना और प्रदर्शित करना आसान हो जाएगा।

इस श्रेणी में एक और आइटम थोड़ा अप्रत्याशित हो सकता है:सप्ताह किस दिन शुरू होता है। कुछ के लिए यह रविवार है; दूसरों के लिए, यह सोमवार है (और फिर फ़ारसी कैलेंडर है, जो सप्ताह शनिवार को शुरू होता है)।

टाइम्स को उपयोगकर्ता के अनुकूल तरीके से भी प्रदर्शित किया जाना चाहिए। याद रखें कि जबकि आपके डेटा मॉडल को एकाधिक समय प्रारूपों की आवश्यकता नहीं है, आप उपयोगकर्ता की समय वरीयता स्टोर कर सकते हैं , यानी 12- या 24 घंटे का प्रारूप।

यह हमें समय क्षेत्रों की ओर ले जाता है।

ऐसे ऐप्स ढूंढना असामान्य नहीं है जो उपयोगकर्ताओं को केवल कुछ समय क्षेत्र विकल्पों की अनुमति देते हैं:पूर्वी समय, मध्य समय, पर्वतीय समय और प्रशांत समय। जब मैं इसे देखता हूं, तो मुझे पता चलता है कि मैं एक अमेरो-केंद्रित एप्लिकेशन डिजाइनर के साथ काम कर रहा हूं। कुछ डिज़ाइनर एक समय क्षेत्र को (आमतौर पर) GMT या UTC से ऑफसेट के रूप में व्यक्त करने की अनुमति देते हैं। हालांकि, कई लोग केवल पूर्ण-संख्या वाले ऑफसेट की अनुमति देने की गलती करते हैं, यह महसूस नहीं करते कि कुछ देश (भारत, ईरान, पाकिस्तान, अफगानिस्तान और अन्य) पूर्णांक ऑफसेट नहीं हैं। वे आंशिक रूप से भिन्न हैं:भारत मानक समय UTC+5:30 है। कुछ स्थानों में एक छोटा आंशिक ऑफसेट भी होता है, जैसे नेपाल मानक समय - यह UTC+05:45 है।

कुछ समय पहले, मैंने एक ऑनलाइन सर्वेक्षण डेटाबेस के लिए एक मॉडल के बारे में लिखा था। यहां मैंने उपयोगकर्ता तालिका में एक समय क्षेत्र जोड़ा है ताकि हम उपयोगकर्ताओं के स्थानीय समय में दिनांक/समय प्रदर्शित कर सकें।

दिनांक, समय, समय क्षेत्र के बारे में अधिक जानकारी के लिए, आप दिनांक और समय के आईएसओ 8601 मानक प्रतिनिधित्व या इस विकिपीडिया लेख का संदर्भ ले सकते हैं।

यह रही बात: केवल स्थानीय स्तर पर ही नहीं, विश्व स्तर पर सोचना सीखें।

कई बार आपके आवेदन को बहुभाषी समर्थन प्रदान करने की आवश्यकता हो सकती है। डेटा मॉडल के दृष्टिकोण से, आपको कई भाषाओं में जानकारी संग्रहीत करने की आवश्यकता हो सकती है; हालांकि, अधिकांश भाषाई प्रबंधन को आपके आवेदन में शामिल किया जाना चाहिए। बहुभाषी समर्थन का कार्यान्वयन इस लेख के दायरे से बाहर है, लेकिन हम इस ब्लॉग में पहले ही इसकी चर्चा कर चुके हैं।

स्थानीयकरण बहुत महत्वपूर्ण है और इसे ठीक से संभालने की आवश्यकता है। जैसा कि हमने पहले ही बताया है, इसका अर्थ विविध भाषाओं का समर्थन करने से कहीं अधिक है; यह दिनांक, समय, मुद्राओं और यहां तक ​​कि दशमलव संकेतकों के लिए पसंदीदा प्रारूपों के बारे में भी है।

डेटा मॉडलिंग? वैश्विक रूप से सोचें

अपना डेटा मॉडल बनाते समय, अपने एप्लिकेशन और उसके डेटाबेस के संभावित अंतर्राष्ट्रीय उपयोग पर विचार करें। डिज़ाइन चरण के दौरान विश्व स्तर पर सोचें और आप बाद में कुछ समस्याओं से बचेंगे - एक फ़ोन नंबर फ़ील्ड जो केवल 3-अंक + 3-अंक + 4-अंक स्वीकार करता है, संयुक्त राज्य अमेरिका में ठीक काम करता है, लेकिन चीन या भारत में इतना अच्छा नहीं है।

क्या आपके डेटाबेस वैश्विक होने के लिए तैयार हैं? आपका लक्ष्य अत्यधिक जटिलता पैदा किए बिना लचीलेपन को सक्षम करना होना चाहिए।