76

EN + हिं Easy

GB What is a join condition pushed down optimization and why does the optimizer do it?

IN जॉइन कंडीशन पुश डाउन ऑप्टिमाइज़ेशन क्या है और ऑप्टिमाइज़र ऐसा क्यों करता है?

A

Moving join conditions from ON to WHERE clause जुड़ने की शर्तों को ON से WHERE क्लॉज पर ले जाना

B

The query optimizer moves filtering conditions (predicates) as early as possible in the execution plan - before joining - to reduce the number of rows that need to be joined dramatically reducing the join cost क्वेरी ऑप्टिमाइज़र निष्पादन योजना में जितनी जल्दी हो सके फ़िल्टरिंग स्थितियों (विधेय) को स्थानांतरित करता है - शामिल होने से पहले - उन पंक्तियों की संख्या को कम करने के लिए जिन्हें नाटकीय रूप से शामिल करने की लागत को कम करने की आवश्यकता होती है।

C

Pushing join conditions from SQL to the application layer SQL से एप्लिकेशन लेयर पर जुड़ने की शर्तों को पुश करना

D

Moving join conditions from WHERE to HAVING जुड़ने की स्थिति को WHERE से HAVING की ओर ले जाना

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Predicate pushdown: instead of joining 1M rows then filtering, filter first (e.g., WHERE status=active) reducing to 10K rows, then join those. The optimizer rewrites the logical plan to apply filters before joins. Critical for performance, especially in distributed/columnar databases.

व्याख्या (हिन्दी) पुशडाउन की भविष्यवाणी करें: 1M पंक्तियों को जोड़ने और फिर फ़िल्टर करने के बजाय, पहले फ़िल्टर करें (उदाहरण के लिए, WHERE स्थिति=सक्रिय) 10K पंक्तियों तक कम करें, फिर उनमें शामिल हों। ऑप्टिमाइज़र जुड़ने से पहले फ़िल्टर लागू करने की तार्किक योजना को फिर से लिखता है। प्रदर्शन के लिए महत्वपूर्ण, विशेष रूप से वितरित/स्तंभकार डेटाबेस में।

77

EN + हिं Medium

GB What causes a Cartesian product to accidentally occur in SQL and how is it detected?

IN SQL में कार्टेशियन उत्पाद के आकस्मिक रूप से उत्पन्न होने का क्या कारण है और इसका पता कैसे लगाया जाता है?

A

Using a FROM clause with multiple tables without specifying join conditions or using CROSS JOIN - detected by the absence of WHERE/ON conditions between tables and the result set size = product of table sizes जुड़ने की शर्तों को निर्दिष्ट किए बिना या क्रॉस जॉइन का उपयोग किए बिना कई तालिकाओं के साथ FROM क्लॉज का उपयोग करना - तालिकाओं और परिणाम सेट आकार के बीच WHERE/ON शर्तों की अनुपस्थिति से पता लगाया गया = तालिका आकार का उत्पाद

B

Using aggregate functions on joined tables सम्मिलित तालिकाओं पर समग्र कार्यों का उपयोग करना

C

Using INNER JOIN without ON clause ON क्लॉज के बिना INNER JOIN का उपयोग करना

D

Using outer joins incorrectly बाहरी जोड़ का गलत तरीके से उपयोग करना

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Accidental Cartesian: SELECT * FROM orders, customers (missing WHERE orders.cust_id=customers.id) produces orders times customers rows. Detected by: result row count = n times m (massive), EXPLAIN shows CROSS JOIN or no join condition. Always verify FROM clause joins when using comma-separated table list.

व्याख्या (हिन्दी) आकस्मिक कार्टेशियन: ऑर्डर से चुनें *, ग्राहक (जहां ऑर्डर.cust_id=customers.id गायब है) ग्राहकों की पंक्तियों से गुणा ऑर्डर उत्पन्न करता है। द्वारा पता लगाया गया: परिणाम पंक्ति गणना = n गुना m (विशाल), EXPLAIN क्रॉस जॉइन या कोई जॉइन स्थिति नहीं दिखाता है। अल्पविराम से अलग की गई तालिका सूची का उपयोग करते समय हमेशा FROM क्लॉज जॉइन को सत्यापित करें।

78

EN + हिं Easy

GB What is a non-equi join (theta join with non-equality condition) and give a practical example?

IN नॉन-इक्विटी जॉइन (थीटा जॉइन विद नॉन-इक्वलिटी कंडीशन) क्या है और एक व्यावहारिक उदाहरण दें?

A

A join using comparison operators other than equality (>, <, >=, <=, BETWEEN, LIKE) in the join condition - e.g. joining employee salary to a salary_grade table where salary BETWEEN grade_low AND grade_high समानता के अलावा अन्य तुलना ऑपरेटरों का उपयोग करते हुए एक जुड़ाव (>, =,

B

A join that returns NULL values only एक जुड़ाव जो केवल NULL मान लौटाता है

C

A join that does not work correctly ऐसा जुड़ाव जो ठीक से काम नहीं करता

D

A join between tables with different schemas विभिन्न स्कीमा वाली तालिकाओं के बीच एक जुड़ाव

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Non-equi join: SELECT e.name, g.grade FROM employee e JOIN salary_grade g ON e.salary BETWEEN g.low AND g.high. Other examples: self join for triangular queries, joining date ranges, finding records within a distance threshold. Cannot use hash join (hash works only with equi-conditions).

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

79

EN + हिं Easy

GB What is the lateral join (or CROSS JOIN LATERAL) in SQL and what problem does it solve?

IN SQL में लेटरल जॉइन (या CROSS JOIN LATERAL) क्या है और यह किस समस्या का समाधान करता है?

A

A join between geographically distributed databases भौगोलिक रूप से वितरित डेटाबेस के बीच एक जुड़ाव

B

A join that only works with parallel query execution एक जुड़ाव जो केवल समानांतर क्वेरी निष्पादन के साथ काम करता है

C

A join that works sideways (column to column) एक जोड़ जो बग़ल में काम करता है (कॉलम से कॉलम)

D

A join where the right side (subquery or function) can reference columns from tables to its left in the FROM clause - allowing correlation within the FROM clause useful for top-N per group queries एक जुड़ाव जहां दाईं ओर (सबक्वेरी या फ़ंक्शन) FROM क्लॉज में तालिकाओं से बाईं ओर के कॉलम को संदर्भित कर सकता है - FROM क्लॉज के भीतर सहसंबंध की अनुमति देता है जो प्रति समूह प्रश्नों के लिए शीर्ष-एन के लिए उपयोगी है।

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) LATERAL: SELECT c.id, top_orders.* FROM customers c JOIN LATERAL (SELECT * FROM orders WHERE cust_id=c.id ORDER BY total DESC LIMIT 3) AS top_orders ON true. References c.id from outer FROM. Solves: top-N per group, unnesting arrays, calling row-returning functions with per-row arguments.

व्याख्या (हिन्दी) लेटरल: सी.आईडी, टॉप_ऑर्डर का चयन करें। * ग्राहकों से सी जॉइन लैटरल (चुनें * उन ऑर्डरों से जहां cust_id=c.id ऑर्डर कुल DESC सीमा 3 के अनुसार) टॉप_ऑर्डर के रूप में सत्य पर। बाहरी FROM से संदर्भ c.id. Solves: top-N per group, unnesting arrays, calling row-returning functions with per-row arguments.

80

EN + हिं Easy

GB What is the join order problem in query optimization and why does it matter for performance?

IN क्वेरी ऑप्टिमाइज़ेशन में जॉइन ऑर्डर समस्या क्या है और यह प्रदर्शन के लिए क्यों मायने रखती है?

A

The order in which columns are listed in ON clause वह क्रम जिसमें कॉलम ON क्लॉज में सूचीबद्ध हैं

B

The order of joins in different user queries विभिन्न उपयोगकर्ता प्रश्नों में जुड़ने का क्रम

C

The alphabetical order of table names in FROM clause FROM खंड में तालिका नामों का वर्णमाला क्रम

D

The optimal sequence in which to join multiple tables; join order is critical because different orders produce dramatically different intermediate result set sizes and the optimizer must find the order minimizing total data processed एकाधिक तालिकाओं को जोड़ने का इष्टतम क्रम; जॉइन ऑर्डर महत्वपूर्ण है क्योंकि अलग-अलग ऑर्डर नाटकीय रूप से अलग-अलग मध्यवर्ती परिणाम सेट आकार उत्पन्न करते हैं और ऑप्टिमाइज़र को संसाधित किए गए कुल डेटा को कम करने वाला ऑर्डर ढूंढना होगा

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Join order optimization: with n tables, there are n!/2 possible join orders. A bad order (joining two large tables first) creates huge intermediates. Optimal order (smallest results first) minimizes I/O. Optimizers use dynamic programming or heuristics (join smaller tables first, use indexed joins first).

व्याख्या (हिन्दी) ज्वाइन ऑर्डर ऑप्टिमाइज़ेशन: n तालिकाओं के साथ, n!/2 संभावित ज्वाइन ऑर्डर हैं। एक ख़राब क्रम (पहले दो बड़ी तालिकाओं को जोड़ना) विशाल मध्यवर्ती बनाता है। इष्टतम क्रम (सबसे छोटे परिणाम पहले) I/O को न्यूनतम करता है। ऑप्टिमाइज़र डायनेमिक प्रोग्रामिंग या ह्यूरिस्टिक्स का उपयोग करते हैं (पहले छोटी तालिकाओं में शामिल हों, पहले अनुक्रमित जॉइन का उपयोग करें)।

81

EN + हिं Medium

GB What is the difference between ON and USING clauses in JOIN syntax?

IN JOIN सिंटैक्स में ON और USING क्लॉज के बीच क्या अंतर है?

A

USING is for outer joins; ON is for inner joins USING बाहरी जुड़ावों के लिए है; ON आंतरिक जुड़ाव के लिए है

B

ON: allows any join condition including different column names (ON a.dept_id = b.id); USING: shorthand for equality join on same-named columns in both tables (USING(dept_id)) - eliminates duplicate columns in result चालू: विभिन्न कॉलम नामों सहित किसी भी जुड़ने की स्थिति की अनुमति देता है (ON a.dept_id = b.id); उपयोग करना: समानता के लिए आशुलिपि दोनों तालिकाओं में समान-नाम वाले कॉलमों को जोड़ती है (USING(dept_id)) - परिणाम में डुप्लिकेट कॉलम को समाप्त करता है

C

USING works with non-equality conditions; ON does not USING गैर-समानता स्थितियों के साथ काम करता है; चालू नहीं है

D

They produce different results वे भिन्न-भिन्न परिणाम उत्पन्न करते हैं

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) ON: flexible, any condition, explicit, allows different column names, both columns appear in SELECT *. USING(col): implicit equality on same-named column, result has only one copy of that column in SELECT *. NATURAL JOIN: automatic USING on all common columns (risky if schema changes).

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

82

EN + हिं Easy

GB What is semi-join reduction in distributed query optimization?

IN वितरित क्वेरी अनुकूलन में सेमी-ज्वाइन रिडक्शन क्या है?

A

Semi-join as a replacement for anti-join एंटी-जॉइन के प्रतिस्थापन के रूप में सेमी-जॉइन

B

Using semi-joins to reduce data transferred in distributed joins वितरित जॉइन में स्थानांतरित डेटा को कम करने के लिए सेमी-जॉइन का उपयोग करना

C

A technique to reduce the number of join conditions जुड़ने की स्थितियों की संख्या को कम करने की एक तकनीक

D

A technique to reduce data transfer in distributed joins: instead of shipping all of relation R to the site of relation S first compute the semi-join S semi-join R (much smaller) ship that to R site compute the join there - reduces network traffic डिस्ट्रीब्यूटेड जॉइन में डेटा ट्रांसफर को कम करने की एक तकनीक: सभी रिलेशन R को रिलेशन S की साइट पर भेजने के बजाय पहले सेमी-जॉइन S सेमी-जॉइन R (बहुत छोटा) शिप की गणना करें जिसे R साइट पर भेजें, वहां जॉइन की गणना करें - नेटवर्क ट्रैफ़िक को कम करता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Distributed semi-join reduction: (1) At S site: project S onto join attributes -> Sj (small). (2) Ship Sj to R site. (3) At R site: filter R to only rows with matches (R semi-join Sj = Rr). (4) Ship Rr back to S site. (5) Compute final join. Effective when join attribute projection is much smaller than full relation.

व्याख्या (हिन्दी) वितरित सेमी-जॉइन रिडक्शन: (1) एस साइट पर: प्रोजेक्ट एस ऑन जॉइन एट्रिब्यूट्स -> एसजे (छोटा)। (2) एसजे को आर साइट पर शिप करें। (3) आर साइट पर: आर को केवल मिलान वाली पंक्तियों में फ़िल्टर करें (आर सेमी-जॉइन एसजे = आरआर)। (4) आरआर को एस साइट पर वापस भेजें। (5) अंतिम जुड़ाव की गणना करें। प्रभावी तब होता है जब सम्मिलित विशेषता प्रक्षेपण पूर्ण संबंध से बहुत छोटा होता है।

83

EN + हिं Easy

GB What is the bushy join tree vs left-deep join tree distinction in query optimization?

IN क्वेरी अनुकूलन में झाड़ीदार जुड़ाव वृक्ष बनाम बाएँ-गहरे जुड़ाव वृक्ष के बीच क्या अंतर है?

A

Left-deep: each inner side of a join is a base table (chain structure: ((A join B) join C) join D) - allows pipelining but limited join orders; Bushy: inner sides can be intermediate results ((A join B) join (C join D)) - more join orders can exploit parallelism लेफ्ट-डीप: जॉइन का प्रत्येक आंतरिक पक्ष एक आधार तालिका है (श्रृंखला संरचना: ((ए जॉइन बी) जॉइन सी) जॉइन डी) - पाइपलाइनिंग की अनुमति देता है लेकिन सीमित जॉइन ऑर्डर; जंगली: आंतरिक पक्ष मध्यवर्ती परिणाम हो सकते हैं ((ए जुड़ते हैं बी) जुड़ते हैं (सी जुड़ते हैं डी)) - अधिक जुड़ने वाले आदेश समानता का फायदा उठा सकते हैं

B

A classification of table shapes not join orders तालिका आकृतियों का वर्गीकरण आदेशों में शामिल नहीं होता है

C

Bushy trees are less efficient than left-deep trees झाड़ीदार पेड़ बाएं-गहरे पेड़ों की तुलना में कम कुशल होते हैं

D

They are different names for the same join structure वे एक ही जुड़ाव संरचना के लिए अलग-अलग नाम हैं

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Left-deep trees: enable pipeline execution (outer always a base table, inner always indexed - use nested-loop index join efficiently). Search space: O(n!). Bushy trees: allow any join order, enable parallel branches, larger search space O(2^n * n!). Most optimizers consider left-deep or zigzag trees for efficiency.

व्याख्या (हिन्दी) बाएं-गहरे पेड़: पाइपलाइन निष्पादन सक्षम करें (बाहरी हमेशा एक आधार तालिका, आंतरिक हमेशा अनुक्रमित - नेस्टेड-लूप इंडेक्स जॉइन का कुशलतापूर्वक उपयोग करें)। खोज स्थान: O(n!). जंगली पेड़: किसी भी जुड़ाव आदेश की अनुमति दें, समानांतर शाखाओं को सक्षम करें, बड़ा खोज स्थान O(2^n * n!)। अधिकांश अनुकूलक दक्षता के लिए बाएं-गहरे या टेढ़े-मेढ़े पेड़ों पर विचार करते हैं।

84

EN + हिं Medium

GB What is join selectivity and how does it affect query optimization?

IN सम्मिलित चयनात्मकता क्या है और यह क्वेरी अनुकूलन को कैसे प्रभावित करती है?

A

The number of join conditions in a query किसी क्वेरी में शामिल होने की शर्तों की संख्या

B

The number of tables that can be joined simultaneously एक साथ जोड़ी जा सकने वाली तालिकाओं की संख्या

C

The speed of different join algorithms विभिन्न जॉइन एल्गोरिदम की गति

D

The fraction of rows in the cross product that actually match the join condition (result_rows / (|R| times |S|)); low selectivity (few matches) is better; optimizer uses statistics to estimate selectivity and choose between join methods क्रॉस उत्पाद में पंक्तियों का अंश जो वास्तव में जुड़ने की स्थिति से मेल खाता है (result_rows / (|R| बार |S|)); कम चयनात्मकता (कुछ मिलान) बेहतर है; ऑप्टिमाइज़र चयनात्मकता का अनुमान लगाने और जुड़ने के तरीकों के बीच चयन करने के लिए आंकड़ों का उपयोग करता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Join selectivity = |R join S| / (|R| times |S|). Close to 0: few matches (selective), small result. Close to 1: most rows match (non-selective), large result. Estimated using column statistics (distinct values, histograms). Optimizer multiplies selectivities across predicates to estimate result size and choose join order/method.

व्याख्या (हिन्दी) चयनात्मकता से जुड़ें = |R, S से जुड़ें| / (|आर| गुना |एस|)। 0 के करीब: कुछ मिलान (चयनात्मक), छोटा परिणाम। 1 के करीब: अधिकांश पंक्तियाँ मेल खाती हैं (गैर-चयनात्मक), बड़ा परिणाम। स्तंभ आँकड़ों (विशिष्ट मान, हिस्टोग्राम) का उपयोग करके अनुमान लगाया गया। ऑप्टिमाइज़र परिणाम आकार का अनुमान लगाने और शामिल होने का क्रम/विधि चुनने के लिए विधेय में चयनात्मकता को गुणा करता है।

85

EN + हिं Easy

GB What is the index nested loop join and what conditions make it efficient?

IN इंडेक्स नेस्टेड लूप जॉइन क्या है और कौन सी स्थितियाँ इसे कुशल बनाती हैं?

A

A join algorithm that processes loops in parallel एक जॉइन एल्गोरिदम जो लूप को समानांतर में संसाधित करता है

B

An index join that works only with primary keys एक इंडेक्स जॉइन जो केवल प्राथमिक कुंजी के साथ काम करता है

C

A nested loop join that creates indexes during execution एक नेस्टेड लूप जॉइन जो निष्पादन के दौरान इंडेक्स बनाता है

D

A join where for each row in the outer table the DBMS uses an index on the inner tables join key to directly look up matching rows - efficient when: outer table is small inner table has an appropriate index on the join column and join selectivity is low एक ऐसा जुड़ाव जहां बाहरी तालिका में प्रत्येक पंक्ति के लिए डीबीएमएस आंतरिक तालिकाओं पर एक इंडेक्स का उपयोग करता है, सीधे मेल खाने वाली पंक्तियों को देखने के लिए कुंजी जोड़ता है - कुशल जब: बाहरी तालिका छोटी होती है, आंतरिक तालिका में शामिल होने वाले कॉलम पर एक उपयुक्त सूचकांक होता है और जुड़ने की चयनात्मकता कम होती है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Index NL join: for each outer row -> index lookup on inner table (O(log n) or O(1) for hash index). Total cost: |outer| times (index lookup cost). Efficient when outer is small (few lookups needed) and inner has index. Much better than full inner scan per outer row.

व्याख्या (हिन्दी) इंडेक्स एनएल जॉइन: प्रत्येक बाहरी पंक्ति के लिए -> आंतरिक तालिका पर इंडेक्स लुकअप (हैश इंडेक्स के लिए ओ (लॉग एन) या ओ (1)। कुल लागत: |बाहरी| समय (सूचकांक लुकअप लागत)। जब बाहरी छोटा होता है (कुछ लुकअप की आवश्यकता होती है) और आंतरिक में सूचकांक होता है तो कुशल होता है। प्रति बाहरी पंक्ति के पूर्ण आंतरिक स्कैन से कहीं बेहतर।

86

EN + हिं Easy

GB What is join elimination in query optimization?

IN क्वेरी ऑप्टिमाइज़ेशन में कनेक्ट एलिमिनेशन क्या है?

A

Removing joins that return no results उन जोड़ों को हटाना जिनसे कोई परिणाम नहीं मिलता

B

Removing unnecessary joins identified by the optimizer ऑप्टिमाइज़र द्वारा पहचाने गए अनावश्यक जोड़ों को हटाना

C

Eliminating one table from a join एक जॉइन से एक टेबल को हटाना

D

When the query optimizer removes a JOIN from the execution plan because it can prove the join does not affect the result (typically: joining to a unique FK parent table when only the child columns are selected) reducing unnecessary I/O जब क्वेरी ऑप्टिमाइज़र निष्पादन योजना से एक JOIN को हटा देता है क्योंकि यह साबित कर सकता है कि जुड़ाव परिणाम को प्रभावित नहीं करता है (आमतौर पर: जब केवल चाइल्ड कॉलम चुने जाते हैं तो एक अद्वितीय FK पैरेंट तालिका में शामिल होना) अनावश्यक I/O को कम करता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Join elimination: if you SELECT only columns from table A and JOIN table B on FK(A.b_id)=B.id where B.id is UNIQUE, and SELECT no B columns, the join is provably unnecessary (cannot filter A rows or produce duplicates). Optimizer removes the join to B entirely, reducing I/O dramatically.

व्याख्या (हिन्दी) उन्मूलन में शामिल हों: यदि आप तालिका ए से केवल कॉलम चुनते हैं और एफके (ए.बी_आईडी) = बी.आईडी पर तालिका बी में शामिल होते हैं जहां बी.आईडी अद्वितीय है, और कोई बी कॉलम नहीं चुनते हैं, तो जुड़ाव अनावश्यक साबित होता है (ए पंक्तियों को फ़िल्टर नहीं कर सकता या डुप्लिकेट उत्पन्न नहीं कर सकता)। ऑप्टिमाइज़र I/O को नाटकीय रूप से कम करते हुए, B से जुड़ाव को पूरी तरह से हटा देता है।

87

EN + हिं Medium

GB How does SQL handle duplicate rows when joining tables with repeated foreign key values?

IN बार-बार विदेशी कुंजी मानों वाली तालिकाओं में शामिल होने पर SQL डुप्लिकेट पंक्तियों को कैसे संभालता है?

A

Each matching combination of rows produces a row in the result - if table A has 3 rows with dept_id=5 and table B has 2 rows with id=5 the join produces 3 times 2=6 rows for dept_id=5 (multiplicative not additive) पंक्तियों का प्रत्येक मिलान संयोजन परिणाम में एक पंक्ति उत्पन्न करता है - यदि तालिका A में dept_id=5 के साथ 3 पंक्तियाँ हैं और तालिका B में id=5 के साथ 2 पंक्तियाँ हैं, तो जुड़ने से dept_id=5 के लिए 3 गुना 2=6 पंक्तियाँ उत्पन्न होती हैं (गुणक योगात्मक नहीं)

B

Duplicates are automatically removed डुप्लिकेट स्वचालित रूप से हटा दिए जाते हैं

C

Duplicates from the same table are removed but not across tables एक ही तालिका से डुप्लिकेट हटा दिए जाते हैं लेकिन सभी तालिकाओं से नहीं

D

Only the first matching pair is included in the result परिणाम में केवल पहली मिलान जोड़ी को शामिल किया गया है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Join cardinality multiplication: for each row in A with join key k, and each row in B with key k, one result row is produced. If A has m rows and B has n rows with key k, the join produces m times n rows for that key value. This is why M:N joins without aggregation produce large result sets.

व्याख्या (हिन्दी) कार्डिनैलिटी गुणन में शामिल हों: कुंजी k के साथ A में प्रत्येक पंक्ति के लिए, और कुंजी k के साथ B में प्रत्येक पंक्ति के लिए, एक परिणाम पंक्ति उत्पन्न होती है। यदि A में m पंक्तियाँ हैं और B में कुंजी k के साथ n पंक्तियाँ हैं, तो जुड़ाव उस कुंजी मान के लिए m गुना n पंक्तियाँ उत्पन्न करता है। यही कारण है कि M:N एकत्रीकरण के बिना जुड़ने से बड़े परिणाम सेट उत्पन्न होते हैं।

88

EN + हिं Easy

GB What is star join query optimization in data warehouse systems?

IN डेटा वेयरहाउस सिस्टम में स्टार जॉइन क्वेरी ऑप्टिमाइज़ेशन क्या है?

A

An optimization for queries against star schemas: filter dimension tables first (highly selective) then use bitmap indexes to intersect the fact table rows matching ALL dimension filters avoiding full fact table scans स्टार स्कीमा के विरुद्ध प्रश्नों के लिए एक अनुकूलन: पहले आयाम तालिकाओं को फ़िल्टर करें (अत्यधिक चयनात्मक) फिर पूर्ण तथ्य तालिका स्कैन से बचने के लिए सभी आयाम फ़िल्टर से मेल खाने वाली तथ्य तालिका पंक्तियों को काटने के लिए बिटमैप इंडेक्स का उपयोग करें

B

A join that requires star schema data model एक जुड़ाव जिसके लिए स्टार स्कीमा डेटा मॉडल की आवश्यकता होती है

C

Joining star schema tables inefficiently स्टार स्कीमा तालिकाओं को अकुशलतापूर्वक जोड़ना

D

A join between multiple fact tables एकाधिक तथ्य तालिकाओं के बीच एक जुड़ाव

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Star join optimization: (1) Apply each dimension filter separately on fact table using bitmap index. (2) AND the bitmaps together (bit intersection). (3) Only retrieve matching fact table rows. Extremely efficient for typical OLAP queries that filter on multiple dimension attributes.

व्याख्या (हिन्दी) स्टार जॉइन ऑप्टिमाइज़ेशन: (1) बिटमैप इंडेक्स का उपयोग करके तथ्य तालिका पर प्रत्येक आयाम फ़िल्टर को अलग से लागू करें। (2) और बिटमैप एक साथ (बिट प्रतिच्छेदन)। (3) केवल मेल खाने वाली तथ्य तालिका पंक्तियाँ ही पुनः प्राप्त करें। विशिष्ट OLAP क्वेरीज़ के लिए अत्यधिक कुशल जो एकाधिक आयाम विशेषताओं पर फ़िल्टर करती हैं।

89

EN + हिं Medium

GB What is the grace hash join algorithm and how does it handle tables larger than available memory?

IN ग्रेस हैश जॉइन एल्गोरिदम क्या है और यह उपलब्ध मेमोरी से बड़ी तालिकाओं को कैसे संभालता है?

A

A hash join that uses grace period before executing एक हैश जॉइन जो निष्पादित करने से पहले अनुग्रह अवधि का उपयोग करता है

B

A hash join variant that partitions BOTH relations into buckets based on hash of join key (partitioning phase) then independently hash-joins matching partition pairs that fit in memory (probing phase) - handles relations larger than RAM by avoiding the need to hold everything in memory at once एक हैश जॉइन वैरिएंट, जो जॉइन कुंजी (विभाजन चरण) के हैश के आधार पर दोनों संबंधों को बकेट में विभाजित करता है, फिर स्वतंत्र रूप से मेमोरी में फिट होने वाले विभाजन जोड़े से मेल खाता हैश-जॉइन करता है (जांच चरण) - एक ही बार में मेमोरी में सब कुछ रखने की आवश्यकता से बचकर रैम से बड़े संबंधों को संभालता है

C

An optimization for hash joins on indexed columns अनुक्रमित स्तंभों पर हैश जुड़ने के लिए एक अनुकूलन

D

A hash join variant for distributed databases वितरित डेटाबेस के लिए एक हैश जॉइन वैरिएंट

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Grace hash join: (1) Partition phase: hash both R and S on join key into k buckets (R1..Rk and S1..Sk). Matching rows hash to same bucket. (2) Build/probe phase: for each i, load Ri into hash table (fits in memory), probe with Si. Total I/O: 3(|R|+|S|) page reads/writes. Handles data larger than memory.

व्याख्या (हिन्दी) ग्रेस हैश जॉइन: (1) विभाजन चरण: जॉइन कुंजी पर आर और एस दोनों को के बकेट (आर1..आरके और एस1..एसके) में हैश करें। पंक्तियों का हैश एक ही बकेट से मेल खाता है। (2) निर्माण/जांच चरण: प्रत्येक i के लिए, Ri को हैश तालिका में लोड करें (मेमोरी में फिट बैठता है), Si के साथ जांच करें। कुल I/O: 3(|R|+|S|) पृष्ठ पढ़ता/लिखता है। मेमोरी से बड़े डेटा को संभालता है।

90

EN + हिं Medium

GB What happens to join performance when joining on columns with very low cardinality?

IN बहुत कम कार्डिनैलिटी वाले कॉलम पर जुड़ने पर प्रदर्शन में क्या होता है?

A

Low cardinality only affects sort-merge joins कम कार्डिनैलिटी केवल सॉर्ट-मर्ज जॉइन को प्रभावित करती है

B

Low cardinality always improves join performance कम कार्डिनैलिटी हमेशा जुड़ाव प्रदर्शन में सुधार करती है

C

Low cardinality join columns have poor index selectivity (index not beneficial for equality joins - will return many rows) cause data skew in hash joins (one bucket overloaded) and may require special handling like bitmap indexes or skew-aware hash distribution कम कार्डिनैलिटी जॉइन कॉलम में खराब इंडेक्स चयनात्मकता होती है (समानता जॉइन के लिए इंडेक्स फायदेमंद नहीं है - कई पंक्तियां लौटाएगा) हैश जॉइन में डेटा स्कू का कारण बनता है (एक बाल्टी अतिभारित) और बिटमैप इंडेक्स या स्क्यू-अवेयर हैश वितरण जैसे विशेष हैंडलिंग की आवश्यकता हो सकती है

D

Low cardinality is ideal for hash joins हैश जॉइन के लिए कम कार्डिनैलिटी आदर्श है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Low cardinality problems: (1) B-tree index useless for equality on low-cardinality column (full scan faster). (2) Hash join skew: status=active bucket gets most rows, causing memory overflow. Solutions: bitmap indexes (great for low cardinality OLAP), skew handling (separate processing for hot key values).

व्याख्या (हिन्दी) कम कार्डिनैलिटी समस्याएं: (1) बी-ट्री इंडेक्स कम-कार्डिनैलिटी कॉलम पर समानता के लिए बेकार है (पूर्ण स्कैन तेजी से)। (2) हैश जॉइन स्क्यू: स्थिति=सक्रिय बकेट को अधिकांश पंक्तियाँ मिलती हैं, जिससे मेमोरी ओवरफ्लो हो जाती है। समाधान: बिटमैप इंडेक्स (कम कार्डिनैलिटी ओएलएपी के लिए बढ़िया), स्क्यू हैंडलिंग (हॉट कुंजी मानों के लिए अलग प्रसंस्करण)।

DBMS — MCQ Practice