डेटाबेस प्रबंधन एवं वेयरहाउसिंग

GATE आँकड़ा विज्ञान व कृत्रिम बुद्धिमत्ता (DA) पेपर का खंड 5: डेटा को कैसे मॉडल किया जाए, प्रश्न पूछा जाए, कुशलता से संग्रहित किया जाए, विश्लेषण हेतु पुनराकारित किया जाए, तथा अंततः उस पैमाने पर संगठित किया जाए जो एक वेयरहाउस माँगता है। यह खंड एक पाइपलाइन की तरह चलता है — कोई ER मॉडल संबंधों में बदला जाता है, संबंधों पर बीजगणित, कैलकुलस व SQL के ज़रिए अखंडता बाधाओं (integrity constraints) व सामान्य रूपों (normal forms) के अधीन प्रश्न पूछे जाते हैं, फ़ाइलें तेज़ पुनर्प्राप्ति हेतु संगठित व अनुक्रमित (indexed) की जाती हैं, मान आगे के विश्लेषण हेतु रूपांतरित किए जाते हैं, और अंततः एक वेयरहाउस स्कीमा में पुनर्संगठित किए जाते हैं जो एक बिलकुल भिन्न प्रश्न हेतु बना है जिसका वेयरहाउस उत्तर देता है: 'यह अभिलेख क्या है' नहीं, बल्कि 'यह माप हर आयाम पर एक साथ काटकर देखने पर कैसा दिखता है'।

1. ER मॉडल, तथा उसका संबंधात्मक मॉडल में मानचित्रण

Entity-Relationship (ER) मॉडल किसी डेटाबेस को डिज़ाइन-चरण पर तीन चीज़ों में वर्णित करता है: entities (एक 'Student' या एक 'Course', हर एक दर्ज करने योग्य वस्तु), attributes (किसी Student का नाम या रोल-नंबर), तथा entity सेटों को जोड़ने वाले relationships (एक Student किसी Course में 'enrols in' करता है)। इसे संबंधात्मक मॉडल में मानचित्रित करने पर हर strong entity सेट हेतु एक टेबल मिलती है, उसके attributes स्तंभों के रूप में व कोई कुंजी primary key के रूप में; एक weak entity सेट अतिरिक्त रूप से उस strong entity की कुंजी वहन करता है जिस पर वह निर्भर है।

कोई relationship सेट कैसे मानचित्रित होता है यह उसकी cardinality पर निर्भर है। एक one-to-many relationship को बिना किसी अलग टेबल के 'many' पक्ष में foreign key के रूप में समेटा जा सकता है। एक many-to-many relationship, हालाँकि, सूचना खोए बिना उस तरह प्रस्तुत नहीं की जा सकती — इसे अपनी टेबल चाहिए, जो हर सहभागी entity सेट तक एक foreign key वहन करे (साथ ही relationship के अपने कोई attributes), क्योंकि किसी भी entity पर एक अकेला foreign-key स्तंभ एक समय में केवल एक ही साथी दर्ज कर सकता है।

⚠️ किसी many-to-many relationship को किसी भी entity की टेबल में मत समेटें
Enrolment दर्ज करने हेतु Student टेबल में एक अकेला 'course_id' स्तंभ जोड़ना साफ़-सुथरा दिखता है पर उसी क्षण ग़लत हो जाता है जब कोई student दूसरे course में enrol करे — उस स्तंभ के पास दूसरा मान रखने की कोई जगह नहीं। यही ठीक वह redundancy व update anomaly है जिसे रोकने हेतु एक अलग junction (enrolment) टेबल का अस्तित्व है, और यह उन ठोस विफलताओं में से एक है जिन्हें रोकने हेतु सामान्य रूप (normal forms) बने हैं।

2. संबंधात्मक बीजगणित, टपल कैलकुलस एवं SQL

संबंधात्मक बीजगणित प्रक्रियात्मक है: कोई प्रश्न ऑपरेटरों का एक स्पष्ट क्रम है — σ (शर्त से पंक्तियाँ चुनें), π (स्तंभ project करें), ⋈ (दो संबंधों को किसी शर्त पर जोड़ें), ∪/∩/− (सेट संघ, प्रतिच्छेदन, अंतर), तथा ρ (नाम बदलें) — किसी बताए क्रम में लागू। Tuple relational calculus घोषणात्मक (declarative) है: कोई प्रश्न बताता है कि उत्तर को क्या संतुष्ट करना चाहिए ('वे सभी tuple t जिनके लिए...') यह बताए बिना कि उसकी गणना कैसे करें। SQL वह भाषा है जो वास्तव में उपयोग होती है, और यह टपल कैलकुलस जैसे ही अर्थ में घोषणात्मक है — कोई SELECT कथन वांछित परिणाम का वर्णन करता है, और डेटाबेस इंजन तय करता है कि उसे कैसे क्रियान्वित करे, सामान्यतः प्रश्न को किसी संबंधात्मक-बीजगणित अभिव्यक्ति के समतुल्य किसी चीज़ में संकलित करके।

  • हर टपल-कैलकुलस अभिव्यक्ति की एक समतुल्य संबंधात्मक-बीजगणित अभिव्यक्ति होती है और इसका विलोम भी — दोनों अभिव्यंजक शक्ति में औपचारिक रूप से समतुल्य हैं, यही ठीक कारण है कि किसी घोषणात्मक SQL प्रश्न को सदा किसी प्रक्रियात्मक बीजगणित योजना में संकलित किया जा सकता है।
  • कड़े अर्थ में join (⋈) कोई मौलिक ऑपरेटर नहीं है — इसे सदा किसी Cartesian गुणनफल पर एक selection के रूप में लिखा जा सकता है, पर इसे अपना प्रतीक इसलिए दिया गया है क्योंकि वह संयोजन अब तक का सबसे सामान्य प्रश्न-आकार है।
ℹ️ अखंडता बाधाएँ स्कीमा में एक बार घोषित होती हैं, हर प्रश्न में नहीं
Primary-key बाधा (uniqueness व not-null सहित) व foreign-key बाधा (हर संदर्भित मान वास्तव में संदर्भित टेबल में मौजूद होना चाहिए) डेटाबेस इंजन द्वारा हर insert व update पर लागू की जाती हैं, यह कोई चीज़ नहीं जिसे हर बार कोई प्रश्न फिर से जाँचे — उन्हें स्कीमा में घोषित करने का उद्देश्य यही है कि यह गारंटी निरपेक्ष रहे चाहे टेबल में कोई भी प्रश्न, या कोई भी एप्लिकेशन, लिख रहा हो।

3. सामान्य रूप (Normal Forms)

First Normal Form (1NF) में किसी संबंध के attribute मान केवल atomic (अविभाज्य) होते हैं — किसी एक सेल में कोई दुहराव-समूह या सूची नहीं। Second Normal Form (2NF) अतिरिक्त रूप से आंशिक निर्भरता (partial dependency) हटाता है: हर non-key attribute को किसी composite primary key के पूरे पर निर्भर होना चाहिए, केवल उसके एक भाग पर नहीं। Third Normal Form (3NF) अतिरिक्त रूप से पारगमन निर्भरता (transitive dependency) हटाता है: कोई non-key attribute किसी अन्य non-key attribute पर निर्भर नहीं हो सकता। Boyce-Codd Normal Form (BCNF) और भी कठोर है — हर determinant (किसी functional dependency का बायाँ पक्ष) एक candidate key होना चाहिए, बिना उस अपवाद के जो 3NF अब भी अनुमति देता है।

⚠️ BCNF तक विघटित करना dependency preservation खो सकता है
हर संबंध को हानि-रहित ढंग से BCNF में विघटित किया जा सकता है, पर वह विघटन हर मूल functional dependency को सुरक्षित रखने की गारंटी नहीं देता — कोई dependency विभाजन के बाद दो भिन्न टेबलों में फैल सकती है, अतः उसे फिर जाँचने हेतु एक महँगा join चाहिए जो विघटन से पहले कभी नहीं चाहिए था। 3NF जानबूझकर BCNF से कम कठोर रखा गया है ठीक इसलिए ताकि यह सदा lossless-join गुण व हर functional dependency दोनों को एक साथ सुरक्षित रखते हुए प्राप्त किया जा सके — यह व्यापार-बंद (trade-off) नाम देने योग्य है ठीक इसलिए क्योंकि यह ऐसा दिखता है मानो BCNF बिना किसी नुकसान के केवल 'अधिक सामान्यीकृत' है।

4. फ़ाइल संगठन, अनुक्रमण (indexing) एवं डेटा प्रकार

Heap (pile) फ़ाइल नए अभिलेखों को बिना किसी क्रम के केवल जोड़ती जाती है, अतः सम्मिलन सस्ता है पर कुंजी से कोई अभिलेख खोजने हेतु पूरी फ़ाइल स्कैन करनी पड़ती है, O(n)। क्रमबद्ध sequential फ़ाइल कुंजी पर binary search समर्थित करती है, O(log n), पर सम्मिलन का अर्थ है क्रम बनाए रखने हेतु अभिलेख खिसकाना, जो महँगा है। Hashed फ़ाइल किसी कुंजी को हैश फ़ंक्शन के ज़रिए सीधे भंडारण स्थान से मैप करती है, जो उस कुंजी से लगभग-O(1) खोज देती है, range query हेतु किसी उपयोगी क्रम को खोने की क़ीमत पर।

Index एक अलग, सहायक संरचना है जो डेटा फ़ाइल को स्वयं पुनर्संगठित किए बिना किसी स्तंभ पर खोज तेज़ करती है। Primary index उस फ़ील्ड पर बनता है जिस पर फ़ाइल भौतिक रूप से क्रमबद्ध है (प्रति फ़ाइल अधिकतम एक); secondary index किसी भी अन्य फ़ील्ड पर बनाया जा सकता है, और सामान्यतः प्रति ब्लॉक के बजाय प्रति अभिलेख एक प्रविष्टि चाहता है। B+ ट्री index — व्यवहार में मानक विकल्प — सभी वास्तविक डेटा पॉइंटर leaf स्तर पर रखता है जबकि आंतरिक नोड केवल routing कुंजियाँ रखते हैं, अतः कोई खोज, कोई क्रमबद्ध range स्कैन व कोई सम्मिलन सभी O(log n) रहते हैं चाहे ट्री जितना भी बढ़े।

5. डेटा रूपांतरण: normalization, discretization, sampling, compression

⚠️ यह 'normalization' तीन खंड पहले वाले normal-forms के 'normalization' से भिन्न है
पाठ्यक्रम एक ही अंग्रेज़ी शब्द को दो असंबद्ध विचारों हेतु दोहराता है। Schema normalization (खंड 3) सामान्य रूप लागू करके टेबलों को redundancy हटाने हेतु पुनर्संरचित करता है। यहाँ, data normalization किसी संख्यात्मक attribute के मानों को किसी साझा सीमा या बंटन पर पुनर्मापित करता है — min-max scaling मानों को, जैसे, [0, 1] पर मैप करता है, और z-score standardization शून्य माध्य व इकाई प्रसरण पर पुनर्मापित करता है — ताकि आगे के विश्लेषण (जैसे किसी दूरी-आधारित विधि) में कोई attribute केवल इसलिए हावी न हो जाए क्योंकि वह संयोगवश किसी बड़ी इकाई में मापा गया है। एक schema में redundancy हटाता है; दूसरा डेटा में ही किसी आकस्मिक स्केल-लाभ को हटाता है, और कोई भी संक्रिया दूसरे का काम नहीं करती।

Discretization किसी सतत (continuous) attribute के मानों को लेबल-युक्त सीमाओं या bins की एक छोटी संख्या से बदलता है (जैसे, age 'young', 'middle-aged', 'senior' बन जाता है), उन एल्गोरिथ्म हेतु उपयोगी जो categorical इनपुट अपेक्षित करते हैं या किसी प्रतिरूप को पढ़ने में आसान बनाने हेतु। Sampling तब डेटा का कोई प्रतिनिधि उपसमुच्चय चुनती है जब पूरा डेटासेट सीधे संसाधित करने हेतु बहुत बड़ा हो — किसी निष्कर्ष की सटीकता तब इस पर निर्भर करती है कि नमूना वास्तव में कितना प्रतिनिधि है। Compression डेटा को किसी छोटे निरूपण में पुनः-एन्कोड करता है, या तो हानि-रहित (मूल को यथावत पुनर्निर्मित किया जा सकता है) या हानि-सहित (कुछ विवरण छोटे आकार के बदले स्थायी रूप से त्याग दिया जाता है)।

6. डेटा वेयरहाउस मॉडलन

किसी normalized operational डेटाबेस के लिए बने transactional insert व update के बजाय, डेटा वेयरहाउस को कई आयामों में विश्लेषणात्मक प्रश्नों हेतु मॉडल किया जाता है। Star schema संख्यात्मक measures (जैसे बिकी मात्रा, राजस्व) को एक अकेली केंद्रीय fact टेबल में रखता है, जिसे denormalized dimension टेबल (product, store, time, customer) घेरे रहती हैं, जिनमें से हर एक उस अक्ष का वर्णन करती है जिस पर measure को काटा जा सकता है; snowflake schema उन dimension टेबलों को उप-टेबलों में और सामान्यीकृत करता है, कुछ query सरलता के बदले कम redundancy पाकर।

Concept hierarchy किसी dimension के मानों को बारीक से मोटी granularity तक क्रमबद्ध करता है — समय हेतु दिन → माह → तिमाही → वर्ष, या भूगोल हेतु शहर → राज्य → देश — और यही ठीक वह है जो किसी OLAP प्रश्न को उस dimension पर roll up (मोटे स्तर तक जोड़ना) या drill down (बारीक स्तर तक तोड़ना) करने देता है। Measures को स्वयं इस आधार पर वर्गीकृत किया जाता है कि वे aggregation के अंतर्गत कैसे व्यवहार करते हैं: additive measures (जैसे बिक्री-राजस्व) को हर dimension पर जोड़ा जा सकता है; semi-additive measures (जैसे किसी खाते का शेष) को कुछ dimension पर जोड़ा जा सकता है पर समय पर नहीं, क्योंकि किसी माह का शेष उसके दैनिक शेषों का योग नहीं होता; तथा non-additive measures (जैसे कोई अनुपात, उदाहरणतः लाभ-मार्जिन) को किसी भी dimension पर सार्थक ढंग से जोड़ा नहीं जा सकता और उन्हें जोड़े गए घटकों से फिर से गणित करना पड़ता है।

🎯 fact टेबल जानबूझकर denormalized क्यों रखी जाती है
Operational डेटाबेस को सामान्यीकृत रखा जाता है ताकि हर update तेज़ रहे व हर तथ्य ठीक एक बार संग्रहित हो, क्योंकि उसमें निरंतर लिखा जाता है। वेयरहाउस में निर्धारित बैचों में लिखा जाता है और विश्लेषणात्मक प्रश्नों द्वारा निरंतर पढ़ा जाता है जिन्हें अन्यथा केवल 'पिछली तिमाही क्षेत्र-वार कुल राजस्व' का उत्तर देने हेतु दर्जन भर सामान्यीकृत टेबलों को जोड़ना पड़ता — अतः यह जानबूझकर कुछ redundancy व update-लागत के बदले query-गति चुनता है, जो विपरीत कार्यभार हेतु विपरीत प्राथमिकता है।

मुख्य बिंदु

  • किसी many-to-many relationship को अपनी टेबल चाहिए जो हर सहभागी entity तक foreign key वहन करे; उसे किसी भी entity की टेबल में समेटना उसी क्षण सूचना खो देता है जब कोई पक्ष एक से अधिक बार सहभागी हो।
  • संबंधात्मक बीजगणित (प्रक्रियात्मक), टपल कैलकुलस (घोषणात्मक) व SQL (घोषणात्मक, किसी बीजगणित योजना में संकलित) एक ही प्रश्न-भाषा हेतु औपचारिक रूप से समतुल्य संकेतन हैं।
  • उच्चतर सामान्य रूप अधिक redundancy हटाते हैं; BCNF, 3NF से कठोर है, और BCNF तक पूरी तरह विघटित करना हर मूल functional dependency सुरक्षित रखने में विफल हो सकता है, जिसे 3NF जानबूझकर सदा सुरक्षित रखने हेतु डिज़ाइन किया गया है।
  • B+ ट्री index किसी रैखिक फ़ाइल-स्कैन को एक साथ O(log n) खोज, क्रमबद्ध range स्कैन व सम्मिलन में बदल देती है, यही कारण है कि यह व्यवहार में मानक अनुक्रमण संरचना है।
  • डेटा-पूर्वप्रसंस्करण 'normalization' (संख्यात्मक मानों की min-max/z-score स्केलिंग) व schema 'normalization' (सामान्य रूपों द्वारा redundancy हटाना) असंबद्ध संक्रियाएँ हैं जिनके लिए इस खंड की अपनी पाठ्यक्रम-पंक्ति संयोगवश एक ही शब्द साझा करती है।
  • वेयरहाउस का star schema measures को एक केंद्रीय, जानबूझकर denormalized fact टेबल में रखता है जिसे dimension टेबल घेरे रहती हैं, और किसी dimension पर concept hierarchy ही वह है जो किसी OLAP प्रश्न को उस पर roll up या drill down करने देता है।

अभ्यास प्रश्न (14)

उत्तर खोलने से पहले प्रत्येक प्रश्न हल करें। हर व्याख्या सही विकल्प के साथ लुभावना गलत विकल्प भी बताती है, क्योंकि अंक वहीं जाते हैं।

  1. दो entity सेटों के बीच किसी many-to-many relationship सेट का संबंधात्मक मॉडल में मानचित्रण किस टेबल में होता है जो वहन करती है

    1. केवल दो में से किसी एक entity की primary key
    2. दो सहभागी entities में से केवल एक तक foreign key
    3. दोनों सहभागी entities तक foreign key, साथ ही relationship के अपने कोई attributes
    4. बिलकुल कोई foreign key नहीं
    उत्तर देखें

    उत्तर: C — दोनों सहभागी entities तक foreign key, साथ ही relationship के अपने कोई attributes

    किसी भी entity की अपनी टेबल पर एक अकेला foreign key एक समय में केवल एक ही साथी दर्ज कर सकता है, अतः many-to-many relationship को अपनी टेबल चाहिए जो दोनों पक्षों को संदर्भित करे।

  2. कौन-सा जोड़ा किसी संबंधात्मक-बीजगणित ऑपरेटर को उसके काम से सही मिलाता है?

    1. σ किसी शर्त को संतुष्ट करने वाली पंक्तियाँ चुनता है
    2. π किसी शर्त पर दो संबंधों को जोड़ता है
    3. ⋈ किसी संबंध या उसके attributes का नाम बदलता है
    4. ρ परिणाम से दोहराई गई पंक्तियाँ हटाता है
    उत्तर देखें

    उत्तर: A — σ किसी शर्त को संतुष्ट करने वाली पंक्तियाँ चुनता है

    σ (select) किसी शर्त से पंक्तियाँ फ़िल्टर करता है; π स्तंभ project करता है; ⋈ join करता है; ρ नाम बदलता है — शेष तीन विकल्प हर एक वर्णित काम हेतु ग़लत ऑपरेटर बताते हैं।

  3. संबंधात्मक बीजगणित, टपल कैलकुलस व SQL के बारे में निम्न में से कौन-से सत्य हैं?

    1. Tuple relational calculus घोषणात्मक है — यह बताता है कि क्या पुनर्प्राप्त करना है, कैसे नहीं
    2. संबंधात्मक बीजगणित प्रक्रियात्मक है — चरण-दर-चरण लागू ऑपरेटरों का एक क्रमबद्ध अनुक्रम
    3. SQL पूर्णतः प्रक्रियात्मक है और इसे कभी घोषणात्मक नहीं कहा जा सकता
    4. हर संबंधात्मक-बीजगणित अभिव्यक्ति की एक समतुल्य टपल-कैलकुलस अभिव्यक्ति होती है
    उत्तर देखें

    उत्तर: A — Tuple relational calculus घोषणात्मक है — यह बताता है कि क्या पुनर्प्राप्त करना है, कैसे नहीं; B — संबंधात्मक बीजगणित प्रक्रियात्मक है — चरण-दर-चरण लागू ऑपरेटरों का एक क्रमबद्ध अनुक्रम; D — हर संबंधात्मक-बीजगणित अभिव्यक्ति की एक समतुल्य टपल-कैलकुलस अभिव्यक्ति होती है

    SQL के SELECT कथन गणना के चरणों के बजाय वांछित परिणाम का वर्णन करते हैं, जो SQL को टपल कैलकुलस की तरह घोषणात्मक बनाता है, प्रक्रियात्मक नहीं — तीसरा विकल्प यहाँ ग़लत है।

  4. एक संबंध जो Second Normal Form (2NF) में है पर Third Normal Form (3NF) में नहीं, उसमें है

    1. किसी composite key के भाग पर किसी non-key attribute की आंशिक निर्भरता
    2. एक non-key attribute की किसी अन्य non-key attribute पर पारगमन निर्भरता
    3. किसी अकेले सेल के भीतर दुहराव-समूह
    4. बिलकुल कोई candidate key नहीं
    उत्तर देखें

    उत्तर: B — एक non-key attribute की किसी अन्य non-key attribute पर पारगमन निर्भरता

    2NF पहले ही आंशिक निर्भरता (विकल्प 1) को रोक चुका है और 1NF पहले ही दुहराव-समूह (विकल्प 3) को रोक चुका है; 2NF से आगे 3NF जो अतिरिक्त हटाता है वह ठीक पारगमन निर्भरता है।

  5. किसी संबंध को Boyce-Codd Normal Form (BCNF) तक पूरी तरह विघटित करना क्या सुरक्षित रखने में विफल हो सकता है

    1. attribute मानों की atomicity
    2. lossless-join गुण
    3. हर मूल functional dependency
    4. विघटित टेबलों के बीच referential integrity
    उत्तर देखें

    उत्तर: C — हर मूल functional dependency

    BCNF विघटन सदा हानि-रहित ढंग से प्राप्त किया जा सकता है, पर यह dependency-preserving होने की गारंटी नहीं है; विभाजन के बाद कोई dependency दो टेबलों में फैल सकती है, जो ठीक वही व्यापार-बंद है जिसे टालने हेतु 3NF डिज़ाइन किया गया है।

  6. कोटि (अधिकतम fan-out) 4 की किसी B+ ट्री index में, एक आंतरिक नोड में अधिकतम कितने संतान पॉइंटर हो सकते हैं?

    संख्यात्मक उत्तर — मान टाइप करें।

    उत्तर देखें

    उत्तर: 4

    B+ ट्री की कोटि (order) किसी आंतरिक नोड के अधिकतम संतानों की संख्या के रूप में परिभाषित है, अतः कोटि 4 का अर्थ है प्रति आंतरिक नोड अधिकतम 4 संतान पॉइंटर।

  7. मान लीजिए अच्छा हैश फ़ंक्शन व कम collision दर है, कौन-सा फ़ाइल संगठन किसी अभिलेख की कुंजी दिए जाने पर सबसे तेज़ पहुँच देता है?

    1. Heap (pile) फ़ाइल
    2. अक्रमबद्ध sequential फ़ाइल
    3. Hashed फ़ाइल
    4. बिना index के क्रमबद्ध sequential फ़ाइल
    उत्तर देखें

    उत्तर: C — Hashed फ़ाइल

    Hashed फ़ाइल कुंजी को सीधे भंडारण स्थान से मैप करती है, जो लगभग-O(1) पहुँच देती है; शेष तीन संगठनों को या तो पूरा स्कैन चाहिए या अधिकतम एक लघुगणकीय खोज।

  8. इस खंड द्वारा उपयोग किए गए डेटा-रूपांतरण अर्थ में, min-max scaling व z-score standardization दोनों किसके उदाहरण हैं,

    1. Third Normal Form तक schema normalization
    2. data normalization, मानों को किसी साझा सीमा या बंटन पर पुनर्मापित करना
    3. किसी सतत attribute का discretization
    4. किसी डेटा वेयरहाउस हेतु concept-hierarchy निर्माण
    उत्तर देखें

    उत्तर: B — data normalization, मानों को किसी साझा सीमा या बंटन पर पुनर्मापित करना

    दोनों किसी संख्यात्मक attribute के मानों को पुनर्मापित करते हैं ([0,1] पर, या शून्य माध्य व इकाई प्रसरण पर) किसी schema को पुनर्संरचित करने के बजाय — यह पूर्वप्रसंस्करण अर्थ में data normalization है, सामान्य रूपों द्वारा schema normalization से भिन्न।

  9. किसी सतत attribute के मानों को 'low', 'medium' व 'high' जैसी लेबल-युक्त सीमाओं की एक छोटी संख्या से बदलना कहलाता है

    1. discretization
    2. sampling
    3. compression
    4. normalization
    उत्तर देखें

    उत्तर: A — discretization

    Discretization ठीक वही संक्रिया है जो किसी सतत attribute की सीमा को थोड़ी-सी लेबल-युक्त श्रेणियों में bin करती है।

  10. किसी खुदरा बिक्री डेटा वेयरहाउस के star schema में, बिकी मात्रा व राजस्व जैसे संख्यात्मक measures कहाँ संग्रहित होते हैं

    1. dimension टेबलों में
    2. fact टेबल में
    3. staging टेबल में
    4. concept hierarchy में
    उत्तर देखें

    उत्तर: B — fact टेबल में

    Fact टेबल वह केंद्रीय टेबल है जो संख्यात्मक measures रखती है, जिसे dimension टेबल घेरे रहती हैं जो उन अक्षों (समय, product, store) का वर्णन करती हैं जिन पर उन measures को काटा जा सकता है।

  11. दिन → माह → तिमाही → वर्ष जैसा concept hierarchy मुख्यतः किसी OLAP प्रश्न को क्या करने देता है

    1. schema को BCNF तक सामान्यीकृत करना
    2. उस dimension पर बारीक व मोटी granularity के बीच roll up या drill down करना
    3. किसी सतत attribute को पहली बार discretize करना
    4. fact व dimension टेबलों के बीच foreign-key बाधा लागू करना
    उत्तर देखें

    उत्तर: B — उस dimension पर बारीक व मोटी granularity के बीच roll up या drill down करना

    Concept hierarchy किसी dimension के मानों को बारीक से मोटा क्रमबद्ध करता है, और ठीक वही क्रम है जिस पर OLAP प्रश्न डेटा को जोड़ने (roll up) या तोड़ने (drill down) हेतु ऊपर या नीचे चलता है।

  12. कौन-सा सामान्य रूप हर determinant (किसी functional dependency का बायाँ पक्ष) को candidate key होने की माँग करता है, बिना किसी अपवाद के?

    1. प्रथम सामान्य रूप — First Normal Form (1NF)
    2. द्वितीय सामान्य रूप — Second Normal Form (2NF)
    3. तृतीय सामान्य रूप — Third Normal Form (3NF)
    4. Boyce-Codd सामान्य रूप (BCNF)
    उत्तर देखें

    उत्तर: D — Boyce-Codd सामान्य रूप (BCNF)

    BCNF, 3NF से कठोर ठीक इसलिए है क्योंकि यह उस अपवाद को हटा देता है जो 3NF अनुमति देता है (कोई determinant जो किसी candidate key का भाग हो पर स्वयं एक न हो), हर determinant को सीधे candidate key होने की माँग करते हुए।

  13. निम्न में से कौन-से लक्ष्य किसी संबंध के अच्छे विघटन से सुरक्षित रहने की अपेक्षा है?

    1. Lossless-join गुण
    2. हर मूल functional dependency
    3. परिणामी टेबलों में अधिकतम संभव redundancy
    4. हर attribute मान की atomicity
    उत्तर देखें

    उत्तर: A — Lossless-join गुण; B — हर मूल functional dependency; D — हर attribute मान की atomicity

    विघटन का उद्देश्य redundancy घटाना है, बढ़ाना नहीं — तीसरा विकल्प वही वर्णित करता है जो normalization के उद्देश्य के ठीक विपरीत है, जबकि शेष तीन वे वास्तविक लक्ष्य हैं जिन्हें अच्छा विघटन सुरक्षित रखता है।

  14. जब कोई सम्मिलन किसी B+ ट्री नोड को उसकी क्षमता से आगे overflow कर दे, तो मानक प्रतिक्रिया है

    1. ट्री को पूर्णतः त्याग देना व शून्य से पुनर्निर्मित करना
    2. नोड को दो में विभाजित करना व एक विभाजक कुंजी parent में ऊपर धकेलना (या copy करना)
    3. नई कुंजी को सम्मिलित करने के बजाय चुपचाप छोड़ देना
    4. पूरे index को hashed फ़ाइल संगठन में बदल देना
    उत्तर देखें

    उत्तर: B — नोड को दो में विभाजित करना व एक विभाजक कुंजी parent में ऊपर धकेलना (या copy करना)

    Overflow करता B+ ट्री नोड दो नोड में विभाजित होता है, एक कुंजी parent में ऊपर धकेली जाती है ताकि उनके बीच मार्ग बने — यदि parent स्वयं तब overflow करे तो ट्री में ऊपर तक दोहराया जाता है, यही वह है जो ट्री को संतुलित व खोज को O(log n) पर रखता है।