डेटाबेस डिजाइनरों को क्या कौशल और ज्ञान की आवश्यकता है?

डेटाबेस डिज़ाइनर बनने में आपको जितना समय लगेगा, उससे अभिभूत महसूस कर रहे हैं? आवश्यक कौशल और प्रतिभाओं के बारे में पढ़ें जिनकी आपको आवश्यकता होगी - यह इतना भयानक नहीं है!

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

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

यहां उन आवश्यक ज्ञान और कौशल का सारांश दिया गया है जो प्रत्येक डेटाबेस डिजाइनर के पास होना चाहिए।

कठिन कौशल डेटाबेस डिजाइनरों की आवश्यकता है

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

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

डेटाबेस सिद्धांत

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

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

रिलेशनल मॉडल

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

संबंधपरक मॉडल की मूलभूत अवधारणाएं।

सभी संबंधों में एक या अधिक उत्कृष्ट विशेषताएँ होनी चाहिए जो प्रत्येक टपल के लिए एक विशिष्ट पहचानकर्ता का प्रतिनिधित्व करती हैं। डेटाबेस स्लैंग में, यह तालिका की कुंजी है। गैर-कुंजी विशेषताएँ इस अर्थ में कुंजी-निर्भर हैं कि प्रत्येक कुंजी मान प्रत्येक विशेषता के लिए एकल संभावित मान निर्धारित करता है।

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

रिलेशनल डेटाबेस

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

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

डेटाबेस स्कीमा को आमतौर पर इकाई-संबंध आरेख (ईआरडी) द्वारा दर्शाया जाता है, जो किसी भी डेटाबेस डिज़ाइनर के लिए एक सामान्य उपकरण है।

एक ग्राहक डेटा मॉडल का प्रतिनिधित्व करने वाला एक ईआरडी।

विसंगतियां और सामान्यीकरण

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

विसंगतियाँ तब होती हैं जब कोई सम्मिलित करें, अद्यतन करें, या हटाएं कार्रवाई डेटा में विसंगतियां उत्पन्न करती है। उदाहरण के लिए, मान लें कि आपके पास बिक्री डेटा संग्रहीत करने के लिए एक तालिका है। प्रत्येक बिक्री के लिए (अर्थात तालिका के प्रत्येक रिकॉर्ड में), ग्राहकों का नाम और पता दर्ज किया जाता है। विसंगति इस प्रकार है:

1. यदि ग्राहक का पता किसी बिक्री में संशोधित किया गया है, और
2. उसी ग्राहक की अन्य बिक्री होती है,
3. अन्य बिक्री का पता पुराना होगा।

विसंगतियों से बचने के लिए, आप डेटाबेस सामान्यीकरण नामक एक डिज़ाइन तकनीक लागू कर सकते हैं। इसमें डिज़ाइन की खामियों से बचने के लिए टेबल और कॉलम (यानी उन्हें छोटे भागों में तोड़ना) को विघटित करना शामिल है:

• एक से अधिक जानकारी रखने वाले कॉलम (जैसे किसी आइटम का आईडी नंबर और साथ ही उसका नाम)।
• एक ही तालिका में एक ही जानकारी को एक से अधिक बार संग्रहीत करना।
• वे फ़ील्ड जो अन्य गैर-कुंजी फ़ील्ड पर निर्भर करते हैं।

गैर-सामान्यीकृत तालिका (बाएं) बनाम सामान्यीकृत स्कीमा (दाएं)।

डेटा वेयरहाउस और डीनॉर्मलाइज़ेशन

कुछ डेटाबेस का उपयोग ऑनलाइन लेनदेन प्रसंस्करण (OLTP) के बजाय बड़ी मात्रा में जानकारी को क्वेरी करने के लिए किया जाता है। इन डेटाबेस को डेटा वेयरहाउस कहा जाता है।

डेटा वेयरहाउस में जानकारी उपयोगकर्ता इंटरफेस से नहीं आती है (उदाहरण के लिए सीधे ई-कॉमर्स ऑर्डरिंग सिस्टम से दर्ज की गई)। यह बैच प्रक्रियाओं से आता है जो विभिन्न स्रोतों से जानकारी एकत्र करता है, इसे संसाधित करता है, इसे साफ करता है और इसे तालिकाओं में संग्रहीत करता है। इस कारण से, हम मान सकते हैं कि डेटा वेयरहाउस पारंपरिक डेटाबेस के समान विसंगतियों के संपर्क में नहीं हैं।

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

एक सामान्य डेटा वेयरहाउस स्कीमा.

बड़ा डेटा

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

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

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

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

डेटाबेस व्यवस्थापन

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

जिस व्यक्ति के पास इन कार्यों की देखभाल करने के लिए डेटाबेस कौशल है, वह डेटाबेस व्यवस्थापक या डीबीए है - जब कोई हो। बहुत छोटे संगठनों में - या विकास के वातावरण में जहां डेटाबेस का संचालन व्यवसाय के लिए महत्वपूर्ण नहीं है - डेटाबेस रखरखाव की जिम्मेदारी डेटाबेस मॉडलर पर पड़ सकती है। इसलिए, आपके पास कुछ ज्ञान होना चाहिए जो आपको कुछ स्थितियों में डीबीए से कार्यभार संभालने की अनुमति देगा। हालांकि, किसी भी परिस्थिति में आपको किसी ऐसे उत्पादन वातावरण में डेटाबेस को प्रशासित करने की जिम्मेदारी स्वीकार नहीं करनी चाहिए जो व्यवसाय या मिशन-महत्वपूर्ण अनुप्रयोगों का समर्थन करता हो ।

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

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

Concurrency and Transaction Management

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

हालांकि, डिजाइनर संभावित समवर्ती समस्याओं को कम करने के लिए उन योजनाओं को डिजाइन करके अपनी भूमिका निभा सकते हैं जो उनसे बचती हैं।

कई समवर्ती समस्याएं तब होती हैं जब डेटाबेस पर लंबे और जटिल लेनदेन निष्पादित किए जाते हैं; जबकि लेन-देन संसाधित किया जा रहा है, इसमें शामिल तालिकाओं को अन्य प्रक्रियाओं के लिए अवरुद्ध कर दिया जाता है जिनके लिए उन्हें जानकारी पढ़ने या लिखने की आवश्यकता होती है। इस तरह की समस्या से बचने के लिए, आप जो सबसे अच्छा काम कर सकते हैं, वह यह सुनिश्चित करना है कि आपके डिजाइन कम से कम तीसरे सामान्य फॉर्म का अनुपालन करते हैं। फिर गतिरोध से बचने के लिए लेन-देन के बारे में सही ढंग से सोचने की जिम्मेदारी प्रोग्रामर की होगी।

लेकिन आप उन रणनीतियों का भी उपयोग कर सकते हैं जो समवर्ती से बचती हैं, जैसे कि विभाजन स्कीमा या प्रत्येक द्वारा पूर्ण किए जाने वाले फ़ंक्शन के अनुसार तालिकाओं को समूहित करना।

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

डेटाबेस डिज़ाइन टूल

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

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

एसक्यूएल और प्रोग्रामिंग

हम सभी एक डेटाबेस डिज़ाइन देने में सक्षम होना चाहते हैं, गर्व से कहें "मेरा काम यहाँ हो गया है" और एक अच्छी तरह से योग्य छुट्टी के लिए छोड़ दें। लेकिन आमतौर पर, वह आदर्श स्थिति कभी नहीं होती। एक बार जब आप अपना डिज़ाइन पूरा कर लेते हैं, तो एप्लिकेशन प्रोग्रामर को इसका उपयोग करने की आवश्यकता होगी, और उन्हें आपकी मदद करने के लिए आपके साथ रहने की आवश्यकता होगी।

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

ORM का उद्देश्य किसी विशेष RDBMS से डेटा एक्सेस को अमूर्त करना है। इसका अच्छा पक्ष यह है कि प्रोग्रामर को डेटाबेस की बारीकियों के बारे में चिंता करने की ज़रूरत नहीं है - दूसरे शब्दों में, उन्हें परवाह करने की ज़रूरत नहीं है कि क्या RDBMS MySQL, Oracle, IBM DB2, MS SQL सर्वर है। , या कुछ और।

ORMs का नकारात्मक पक्ष यह है कि डेटाबेस डिज़ाइन ऑब्जेक्ट - टेबल, विशेषताएँ और संबंध - जावा, पायथन, R, या C# जैसी उच्च-स्तरीय प्रोग्रामिंग भाषा के कोड में परिभाषित किए गए हैं। दूसरे शब्दों में, वे वहीं हैं जहाँ हम डेटाबेस डिज़ाइनर उन्हें नहीं देख सकते हैं।

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

सॉफ्ट स्किल्स डेटाबेस डिज़ाइनर के पास होना चाहिए

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

व्यावसायिक दृष्टि

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

व्यावसायिक दृष्टिकोण को समझने से आप प्रत्येक आवश्यकता के महत्व को बेहतर ढंग से समझ पाएंगे और अपने निर्णयों का मार्गदर्शन कर पाएंगे ताकि आपके डिजाइन संगठन के उद्देश्यों के साथ बेहतर ढंग से संरेखित हों।

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

संचार कौशल

यह महान डिजाइन बनाने के लिए पर्याप्त नहीं है। आपको यह भी समझाने में सक्षम होना चाहिए कि आपका डिज़ाइन क्यों काम करता है। ऐसा करने का तरीका यह जानना है कि इसे कैसे प्रस्तुत किया जाए, दोनों तरह से (बोली जाने वाली या लिखित) और नेत्रहीन।

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

लेकिन आपको रचनात्मक आलोचना को स्वीकार करने और उन दृष्टिकोणों पर विचार करने के लिए भी तैयार रहना चाहिए जो आपके अपने से अलग हैं। कभी-कभी एक प्रोग्रामर ऐसी समस्या का पता लगा सकता है जिसे आपने नहीं देखा और आपको अच्छी सलाह दे सकता है। अपने सहकर्मियों को यह सोचकर बर्खास्त न करें कि उन्हें डेटाबेस का ज्ञान नहीं है।

पारस्परिक कौशल

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

ऐसा हो सकता है कि आप विकास दल में एकमात्र डेटाबेस डिज़ाइनर नहीं हैं। हो सकता है कि आपको अपने सहयोगियों के एक उपसमूह का नेतृत्व करना चाहिए। ऐसा करने के लिए, आपको नेतृत्व कौशल का प्रदर्शन करना चाहिए और एक परियोजना प्रबंधक के रूप में कार्य करना चाहिए, यह सुनिश्चित करना कि डेटाबेस डिजाइनरों की टीम अपने उद्देश्यों को पूरा करती है और प्रेरित रहती है।

डेटाबेस डिज़ाइन कौशल कैसे सीखें

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

यदि आप पुस्तकों और लेखों को पढ़कर स्वयं सीखना पसंद करते हैं, तो आप समय और धन की बचत करेंगे - लेकिन आपको आवश्यक विषयों के माध्यम से मार्गदर्शन करने और अपने ज्ञान का मूल्यांकन करने के लिए एक मार्गदर्शक की आवश्यकता होगी। और आपको अपने ज्ञान को व्यावहारिक रूप से प्रदर्शित करना होगा, क्योंकि आपके पास इसका समर्थन करने के लिए कोई डिग्री नहीं होगी।

किसी भी मामले में, चाहे आप पाठ्यक्रम लेकर या पढ़कर सीखें, वह ज्ञान केवल एक नींव के रूप में काम करेगा। आप मॉडल बनाकर, वास्तविक समस्याओं का सामना करके और अपने सहकर्मियों और सहकर्मियों के कार्यों को देखकर सबसे अधिक सीखेंगे।