DBMS — MCQ Practice

Hindi aur English dono mein practice karo — click karo answer check karne ke liye

📚 131 Questions 🌐 Hindi + English ✅ Free
भाषा / Language:
131 questions
76
EN + हिं Medium
GB What is the difference between a simple view and a complex view in terms of DML support?
IN डीएमएल समर्थन के संदर्भ में सरल दृश्य और जटिल दृश्य के बीच क्या अंतर है?
A
Simple views are slower; complex views are faster साधारण दृश्य धीमे होते हैं; जटिल दृश्य तेज़ होते हैं
B
Simple views are stored; complex views are virtual सरल दृश्य संग्रहीत हैं; जटिल दृश्य आभासी हैं
C
Complex views have WITH CHECK OPTION; simple views do not जटिल दृश्यों में चेक विकल्प के साथ है; साधारण दृश्य नहीं होते
D
Simple view (single table no aggregates no DISTINCT): typically supports DML (INSERT/UPDATE/DELETE) through the view. Complex view (multiple tables aggregates GROUP BY DISTINCT UNION): generally NOT directly updatable since the DBMS cannot unambiguously translate DML to base tables सरल दृश्य (एकल तालिका, कोई समुच्चय नहीं, कोई DISTINCT नहीं): आम तौर पर दृश्य के माध्यम से डीएमएल (INSERT/UPDATE/DELETE) का समर्थन करता है। जटिल दृश्य (मल्टीपल टेबल्स ग्रुप बाय डिस्टिंक्ट यूनियन): आम तौर पर सीधे अपडेट करने योग्य नहीं है क्योंकि डीबीएमएस स्पष्ट रूप से डीएमएल को बेस टेबल में अनुवाद नहीं कर सकता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Simple updatable view: single table, no DISTINCT/GROUP BY/aggregates. UPDATE through view maps directly to base table. Complex view: JOIN of two tables - INSERT through view is ambiguous (which table gets the data?). Aggregate view: UPDATE is meaningless (which base rows to change?). These require INSTEAD OF triggers.
व्याख्या (हिन्दी) सरल अद्यतन करने योग्य दृश्य: एकल तालिका, कोई अलग/समूह BY/समुच्चय नहीं। दृश्य मानचित्रों के माध्यम से सीधे आधार तालिका में अद्यतन करें। जटिल दृश्य: दो तालिकाओं का जुड़ाव - दृश्य के माध्यम से सम्मिलित करना अस्पष्ट है (कौन सी तालिका डेटा प्राप्त करती है?)। समग्र दृश्य: अद्यतन अर्थहीन है (कौन सी आधार पंक्तियाँ बदलनी हैं?)। इन्हें ट्रिगर्स के बजाय आवश्यकता होती है।
77
EN + हिं Medium
GB What is view staleness in the context of materialized views and how is it managed?
IN भौतिक विचारों के संदर्भ में दृश्य बासीपन क्या है और इसे कैसे प्रबंधित किया जाता है?
A
Views becoming inaccessible due to permission changes अनुमति परिवर्तन के कारण दृश्य अप्राप्य हो रहे हैं
B
The state where a materialized view no longer reflects the current state of its base tables due to subsequent changes; managed by: immediate refresh (on commit) deferred refresh (on demand/scheduled) or fast/incremental refresh (log-based only propagate changes) वह स्थिति जहां एक भौतिक दृश्य बाद के परिवर्तनों के कारण अपनी आधार तालिकाओं की वर्तमान स्थिति को प्रतिबिंबित नहीं करता है; द्वारा प्रबंधित: तत्काल ताज़ा (प्रतिबद्धता पर) विलंबित ताज़ा (मांग/अनुसूचित पर) या तेज़/वृद्धिशील ताज़ा (लॉग-आधारित केवल प्रचारित परिवर्तन)
C
Views becoming outdated in terms of SQL syntax SQL सिंटैक्स के संदर्भ में दृश्य पुराने होते जा रहे हैं
D
Views that reference dropped tables देखें कि संदर्भ तालिकाएँ गिरा दी गईं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Materialized view refresh strategies: COMPLETE: recompute entire result (slow for large views, always current). FAST/INCREMENTAL: use materialized view logs to apply only changes since last refresh (much faster, requires MV logs). ON COMMIT: refresh after each transaction (expensive). ON DEMAND/SCHEDULED: refresh periodically (may serve stale data).
व्याख्या (हिन्दी) भौतिक दृश्य ताज़ा रणनीतियाँ: पूर्ण: संपूर्ण परिणाम की पुनः गणना करें (बड़े दृश्यों के लिए धीमी, हमेशा चालू)। तेज़/वृद्धिशील: अंतिम रीफ्रेश के बाद से केवल परिवर्तन लागू करने के लिए भौतिकीकृत दृश्य लॉग का उपयोग करें (बहुत तेज़, एमवी लॉग की आवश्यकता है)। प्रतिबद्धता पर: प्रत्येक लेनदेन (महंगा) के बाद ताज़ा करें। मांग पर/अनुसूचित: समय-समय पर ताज़ा करें (पुराना डेटा पेश कर सकता है)।
78
EN + हिं Easy
GB What is the view cascade problem in schema management?
IN स्कीमा प्रबंधन में व्यू कैस्केड समस्या क्या है?
A
Too many views causing performance issues बहुत अधिक दृश्य प्रदर्शन समस्याओं का कारण बन रहे हैं
B
When modifying or dropping a base table affects (invalidates or drops) all views and views-on-views that depend on it - requiring careful dependency tracking and potentially cascading updates to multiple view definitions जब आधार तालिका को संशोधित या हटाया जाता है, तो उस पर निर्भर सभी दृश्य और दृश्य-पर-दृश्य प्रभावित होते हैं (अमान्य हो जाते हैं या हट जाते हैं) - इसके लिए सावधानीपूर्वक निर्भरता ट्रैकिंग और एकाधिक दृश्य परिभाषाओं के लिए संभावित रूप से कैस्केडिंग अपडेट की आवश्यकता होती है।
C
Views creating recursive loops पुनरावर्ती लूप बनाने वाले दृश्य
D
Too many nested views causing stack overflow बहुत सारे नेस्टेड दृश्य स्टैक ओवरफ़्लो का कारण बन रहे हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) View cascade: if table T has 10 views, and each view has 3 views-on-views, dropping T affects 40+ objects. Dependency graph must be maintained (system catalog). DROP TABLE t RESTRICT prevents dropping if views exist. DROP TABLE t CASCADE drops table AND all dependent views. Schema change impact analysis is critical.
व्याख्या (हिन्दी) दृश्य कैस्केड: यदि तालिका T में 10 दृश्य हैं, और प्रत्येक दृश्य में 3 दृश्य-पर-दृश्य हैं, तो T छोड़ने से 40+ ऑब्जेक्ट प्रभावित होते हैं। निर्भरता ग्राफ़ बनाए रखा जाना चाहिए (सिस्टम कैटलॉग)। यदि दृश्य मौजूद हैं तो ड्रॉप टेबल टी रिस्ट्रिक्ट ड्रॉपिंग को रोकता है। ड्रॉप टेबल टी कैस्केड ड्रॉप टेबल और सभी आश्रित दृश्य। स्कीमा परिवर्तन प्रभाव विश्लेषण महत्वपूर्ण है।
79
EN + हिं Medium
GB How does a database ensure security using views?
IN डेटाबेस दृश्यों का उपयोग करके सुरक्षा कैसे सुनिश्चित करता है?
A
Views encrypt data automatically एन्क्रिप्टेड डेटा को स्वचालित रूप से देखता है
B
Views authenticate users automatically दृश्य स्वचालित रूप से उपयोगकर्ताओं को प्रमाणित करते हैं
C
Views apply row-level encryption दृश्य पंक्ति-स्तरीय एन्क्रिप्शन लागू करते हैं
D
Views restrict what data a user can see/modify: create view restricted_emp AS SELECT name dept FROM employee WHERE dept=accounting; grant SELECT on restricted_emp to accounting_user. User cannot access salary other departments or the base table directly - view provides a security perimeter दृश्य प्रतिबंधित करते हैं कि उपयोगकर्ता किस डेटा को देख/संशोधित कर सकता है: दृश्य प्रतिबंधित_एएमपी बनाएं, कर्मचारी से विभाग का नाम चुनें, जहां विभाग = लेखांकन; अकाउंटिंग_यूजर को प्रतिबंधित_ईएमपी पर चयन प्रदान करें। उपयोगकर्ता वेतन अन्य विभागों या आधार तालिका तक सीधे नहीं पहुंच सकता - दृश्य एक सुरक्षा परिधि प्रदान करता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) View-based security: (1) Create view exposing only permitted rows/columns. (2) GRANT permissions only on the view, REVOKE from base table. (3) Users can only query through the view filter. This provides: column-level security (hide sensitive columns), row-level security (filter by user/dept), and abstraction of base table structure.
व्याख्या (हिन्दी) दृश्य-आधारित सुरक्षा: (1) केवल अनुमत पंक्तियों/स्तंभों को उजागर करते हुए दृश्य बनाएं। (2) केवल दृश्य पर अनुमति दें, आधार तालिका से रद्द करें। (3) उपयोगकर्ता केवल व्यू फ़िल्टर के माध्यम से क्वेरी कर सकते हैं। यह प्रदान करता है: कॉलम-स्तरीय सुरक्षा (संवेदनशील कॉलम छिपाएँ), पंक्ति-स्तरीय सुरक्षा (उपयोगकर्ता/विभाग द्वारा फ़िल्टर), और आधार तालिका संरचना का अमूर्तन।
80
EN + हिं Easy
GB What is query rewriting through views in materialized view-based optimization?
IN भौतिक दृश्य-आधारित अनुकूलन में दृश्यों के माध्यम से क्वेरी पुनर्लेखन क्या है?
A
The query optimizer automatically recognizes when a user query can be answered using a pre-computed materialized view (even if the query does not reference the view directly) and rewrites the query to use the materialized view for improved performance क्वेरी ऑप्टिमाइज़र स्वचालित रूप से पहचानता है कि उपयोगकर्ता क्वेरी का उत्तर पूर्व-गणना किए गए भौतिक दृश्य का उपयोग करके दिया जा सकता है (भले ही क्वेरी सीधे दृश्य को संदर्भित न करे) और बेहतर प्रदर्शन के लिए भौतिक दृश्य का उपयोग करने के लिए क्वेरी को फिर से लिखता है
B
Manually rewriting queries to avoid using views दृश्यों के उपयोग से बचने के लिए प्रश्नों को मैन्युअल रूप से दोबारा लिखना
C
Rewriting view definitions to improve their performance उनके प्रदर्शन को बेहतर बनाने के लिए दृश्य परिभाषाओं को फिर से लिखना
D
Converting views into stored procedures दृश्यों को संग्रहित प्रक्रियाओं में परिवर्तित करना
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) View-based query rewriting: user queries SELECT dept, SUM(sales) FROM orders GROUP BY dept. Optimizer detects that a materialized view mv_dept_sales already stores this result. Optimizer rewrites the query to SELECT * FROM mv_dept_sales - avoiding the expensive aggregation on large orders table.
व्याख्या (हिन्दी) दृश्य-आधारित क्वेरी पुनर्लेखन: उपयोगकर्ता क्वेरी विभाग द्वारा समूह, ऑर्डर से विभाग, एसयूएम (बिक्री) का चयन करें। ऑप्टिमाइज़र पता लगाता है कि एक भौतिक दृश्य mv_dept_sales पहले से ही इस परिणाम को संग्रहीत करता है। ऑप्टिमाइज़र SELECT * FROM mv_dept_sales के लिए क्वेरी को फिर से लिखता है - बड़े ऑर्डर टेबल पर महंगे एकत्रीकरण से बचता है।
81
EN + हिं Easy
GB What are indexed views (SQL Server) or materialized views with indexes and what advantage do they provide?
IN अनुक्रमित दृश्य (एसक्यूएल सर्वर) या अनुक्रमित के साथ भौतिक दृश्य क्या हैं और वे क्या लाभ प्रदान करते हैं?
A
Indexed views have a unique clustered index built on top of the stored result allowing the optimizer to use the view like a regular indexed table for lookups range scans and sort operations - not just aggregations अनुक्रमित दृश्यों में संग्रहीत परिणाम के शीर्ष पर निर्मित एक अद्वितीय क्लस्टर इंडेक्स होता है जो ऑप्टिमाइज़र को लुकअप रेंज स्कैन और सॉर्ट ऑपरेशंस के लिए नियमित अनुक्रमित तालिका की तरह दृश्य का उपयोग करने की अनुमति देता है - न कि केवल एकत्रीकरण के लिए
B
They only work with OLAP queries वे केवल OLAP प्रश्नों के साथ काम करते हैं
C
They are faster to create but slower to query वे बनाने में तेज़ हैं लेकिन क्वेरी करने में धीमे हैं
D
They are identical to regular materialized views वे नियमित भौतिक विचारों के समान हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) SQL Server indexed view: CREATE VIEW v WITH SCHEMABINDING AS ...; CREATE UNIQUE CLUSTERED INDEX ix_v ON v(key). Now the view is stored like a base table with B-tree indexes. Optimizer can use it for: equality lookups, range scans, merge joins - beyond just covering pre-aggregated data.
व्याख्या (हिन्दी) एसक्यूएल सर्वर अनुक्रमित दृश्य: स्कीमाबाइंडिंग के साथ व्यू वी बनाएं ...; v(कुंजी) पर अद्वितीय क्लस्टर इंडेक्स ix_v बनाएं। अब दृश्य को बी-ट्री इंडेक्स के साथ बेस टेबल की तरह संग्रहीत किया जाता है। ऑप्टिमाइज़र इसका उपयोग इसके लिए कर सकता है: समानता लुकअप, रेंज स्कैन, मर्ज जॉइन - केवल पूर्व-एकत्रित डेटा को कवर करने के अलावा।
82
EN + हिं Easy
GB What does WITH SCHEMABINDING option on a view definition do in SQL Server?
IN SQL सर्वर में दृश्य परिभाषा पर with SCHEMABINDING विकल्प क्या करता है?
A
It encrypts the view definition यह दृश्य परिभाषा को एन्क्रिप्ट करता है
B
It allows the view to span multiple schemas यह दृश्य को कई स्कीमा को विस्तारित करने की अनुमति देता है
C
It binds the view to the schema of its base tables preventing changes to base tables (DROP column DROP table ALTER type) that would invalidate the view - required for creating indexed views यह दृश्य को उसके आधार तालिकाओं के स्कीमा से बांधता है, जिससे आधार तालिकाओं (DROP कॉलम DROP तालिका ALTER प्रकार) में परिवर्तन को रोका जा सकता है, जो दृश्य को अमान्य कर देगा - अनुक्रमित दृश्य बनाने के लिए आवश्यक है
D
It compresses the view schema यह दृश्य स्कीमा को संपीड़ित करता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) WITH SCHEMABINDING: the view is bound to its base tables schema. Prevents: DROP COLUMN of a column used in the view, DROP TABLE of a base table, ALTER TABLE changing referenced columns. Required for indexed views in SQL Server. Also prevents accidental breaking schema changes.
व्याख्या (हिन्दी) स्कीमाबाइंडिंग के साथ: दृश्य इसकी बेस टेबल स्कीमा से जुड़ा हुआ है। रोकता है: दृश्य में उपयोग किए गए कॉलम का ड्रॉप कॉलम, बेस टेबल का ड्रॉप टेबल, संदर्भित कॉलम बदलने वाली टेबल बदलें। SQL सर्वर में अनुक्रमित दृश्यों के लिए आवश्यक। स्कीम परिवर्तनों को आकस्मिक रूप से तोड़ने से भी रोकता है।
83
EN + हिं Easy
GB What is the view freshness trade-off in data warehousing?
IN डेटा वेयरहाउसिंग में व्यू फ्रेशनेस ट्रेड-ऑफ क्या है?
A
Batch views are always more accurate बैच दृश्य हमेशा अधिक सटीक होते हैं
B
They provide identical freshness guarantees वे समान ताजगी की गारंटी प्रदान करते हैं
C
Real-time views: always current but require resources for each base table change (incremental refresh triggers on every write - adds write overhead); Batch/periodic views: may be stale (hours/days old) but no write overhead refreshed efficiently on schedule वास्तविक समय दृश्य: हमेशा चालू लेकिन प्रत्येक आधार तालिका परिवर्तन के लिए संसाधनों की आवश्यकता होती है (प्रत्येक लेखन पर वृद्धिशील ताज़ा ट्रिगर - लेखन ओवरहेड जोड़ता है); बैच/आवधिक दृश्य: बासी हो सकते हैं (घंटे/दिन पुराने) लेकिन शेड्यूल पर कुशलतापूर्वक ताज़ा किया गया कोई लेखन ओवरहेड नहीं
D
Real-time views are always better वास्तविक समय के दृश्य हमेशा बेहतर होते हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Freshness trade-off: real-time MV refresh adds latency and overhead to every base table write (triggers/log replay). For OLAP workloads where slight staleness is acceptable, batch refresh (nightly rebuild or frequent incremental) is far more efficient. Business requirements determine acceptable lag.
व्याख्या (हिन्दी) ताजगी का व्यापार-बंद: वास्तविक समय एमवी रिफ्रेश प्रत्येक बेस टेबल राइट (ट्रिगर/लॉग रीप्ले) में विलंबता और ओवरहेड जोड़ता है। ओएलएपी वर्कलोड के लिए जहां थोड़ी सी स्थिरता स्वीकार्य है, बैच रिफ्रेश (रात में पुनर्निर्माण या लगातार वृद्धिशील) कहीं अधिक कुशल है। व्यावसायिक आवश्यकताएँ स्वीकार्य अंतराल निर्धारित करती हैं।
84
EN + हिं Easy
GB Can a view reference another view (view-on-view nesting) and what is the practical implication?
IN क्या एक दृश्य दूसरे दृश्य का संदर्भ दे सकता है (व्यू-ऑन-व्यू नेस्टिंग) और व्यावहारिक निहितार्थ क्या है?
A
Yes views can reference other views creating nested hierarchies; the query processor must resolve all view definitions recursively before execution which can cause: deep dependency chains difficulty debugging and cascading failures if intermediate views change हाँ, दृश्य नेस्टेड पदानुक्रम बनाते हुए अन्य विचारों को संदर्भित कर सकते हैं; क्वेरी प्रोसेसर को निष्पादन से पहले सभी दृश्य परिभाषाओं को पुनरावर्ती रूप से हल करना होगा, जिसके कारण हो सकता है: यदि मध्यवर्ती दृश्य बदलते हैं तो गहरी निर्भरता श्रृंखलाओं में डिबगिंग और कैस्केडिंग विफलताओं में कठिनाई होती है
B
Views cannot reference other views दृश्य अन्य विचारों का संदर्भ नहीं दे सकते
C
Views can only reference base tables दृश्य केवल आधार तालिकाओं का संदर्भ दे सकते हैं
D
Nested views are automatically flattened नेस्टेड दृश्य स्वचालित रूप से समतल हो जाते हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) View nesting: CREATE VIEW v3 AS SELECT * FROM v2 JOIN ... where v2 references v1 which references base tables. The query processor resolves v3->v2->v1->base tables. Issues: complex dependency trees, difficult debugging, dropping v1 cascades to v2 and v3, deep nesting can confuse the optimizer.
व्याख्या (हिन्दी) नेस्टिंग देखें: चयन के रूप में दृश्य v3 बनाएं * v2 से जुड़ें... जहां v2 संदर्भ v1 है जो आधार तालिकाओं को संदर्भित करता है। क्वेरी प्रोसेसर v3->v2->v1->बेस टेबल का समाधान करता है। मुद्दे: जटिल निर्भरता वृक्ष, कठिन डिबगिंग, v1 कैस्केड को v2 और v3 पर छोड़ना, गहरी नेस्टिंग ऑप्टिमाइज़र को भ्रमित कर सकती है।
85
EN + हिं Easy
GB What is horizontal vs vertical view partitioning concept in database design using views?
IN दृश्यों का उपयोग करके डेटाबेस डिज़ाइन में क्षैतिज बनाम ऊर्ध्वाधर दृश्य विभाजन अवधारणा क्या है?
A
Horizontal view: restricts ROWS (WHERE clause on base table) exposing a subset of rows to a user group. Vertical view: restricts COLUMNS (SELECT only certain columns) limiting which attributes are visible - both used for security and interface simplification क्षैतिज दृश्य: उपयोगकर्ता समूह में पंक्तियों के सबसेट को उजागर करने वाली पंक्तियों (आधार तालिका पर WHERE खंड) को प्रतिबंधित करता है। लंबवत दृश्य: कॉलम को प्रतिबंधित करता है (केवल कुछ कॉलम चुनें) यह सीमित करता है कि कौन सी विशेषताएँ दिखाई दे रही हैं - दोनों का उपयोग सुरक्षा और इंटरफ़ेस सरलीकरण के लिए किया जाता है
B
Splitting view processing into parallel steps दृश्य प्रसंस्करण को समानांतर चरणों में विभाजित करना
C
Partitioning materialized views across servers सर्वरों में विचारों को भौतिक रूप से विभाजित करना
D
Physical partitioning of view storage दृश्य भंडारण का भौतिक विभाजन
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Horizontal partition view: CREATE VIEW accounting_emp AS SELECT * FROM employee WHERE dept=Accounting (subset of rows). Vertical partition view: CREATE VIEW emp_public AS SELECT id, name, title FROM employee (subset of columns, hides salary, SSN). Combine both for fine-grained access control.
व्याख्या (हिन्दी) क्षैतिज विभाजन दृश्य: चयन के रूप में अकाउंटिंग_एम्प देखें * कर्मचारी से बनाएं जहां विभाग = अकाउंटिंग (पंक्तियों का सबसेट)। लंबवत विभाजन दृश्य: कर्मचारी से चयन आईडी, नाम, शीर्षक के रूप में एम्प_पब्लिक देखें (स्तंभों का सबसेट, वेतन छुपाता है, एसएसएन)। सुक्ष्म अभिगम नियंत्रण के लिए दोनों को मिलाएं।
86
EN + हिं Medium
GB What is the SQL CREATE OR REPLACE VIEW statement and how does it differ from DROP+CREATE?
IN SQL क्रिएट या रिप्लेस व्यू स्टेटमेंट क्या है और यह DROP+CREATE से कैसे भिन्न है?
A
CREATE OR REPLACE is faster than DROP+CREATE ड्रॉप+क्रिएट की तुलना में क्रिएट या रिप्लेस तेज़ है
B
CREATE OR REPLACE is not standard SQL बनाएं या बदलें मानक SQL नहीं है
C
They are identical operations वे समान परिचालन हैं
D
CREATE OR REPLACE VIEW atomically replaces an existing view definition without dropping it first preserving dependent object permissions and grants (GRANT/REVOKE on the view survive the replace); DROP+CREATE loses all grants requiring them to be re-applied दृश्य बनाएं या बदलें, किसी मौजूदा दृश्य परिभाषा को पहले आश्रित ऑब्जेक्ट अनुमतियों और अनुदानों को संरक्षित किए बिना परमाणु रूप से प्रतिस्थापित करता है (दृश्य पर अनुदान/निरस्तीकरण प्रतिस्थापन से बच जाता है); DROP+CREATE उन सभी अनुदानों को खो देता है जिन्हें दोबारा लागू करने की आवश्यकता होती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) CREATE OR REPLACE VIEW: updates view definition in-place. Key benefit: all previously granted permissions on the view are preserved (no need to re-GRANT). DROP VIEW + CREATE VIEW: removes all grants on the view, requiring manual re-granting to all users/roles that had access.
व्याख्या (हिन्दी) दृश्य बनाएं या बदलें: अद्यतन दृश्य परिभाषा को यथास्थान अपडेट करता है। मुख्य लाभ: दृश्य पर पहले दी गई सभी अनुमतियाँ संरक्षित हैं (पुनः प्रदान करने की कोई आवश्यकता नहीं है)। दृश्य ड्रॉप करें + दृश्य बनाएं: दृश्य पर सभी अनुदान हटा देता है, जिसके लिए उन सभी उपयोगकर्ताओं/भूमिकाओं को मैन्युअल रूप से पुनः अनुदान की आवश्यकता होती है जिनके पास पहुंच थी।
87
EN + हिं Easy
GB In the context of views what is view serializability in data warehouses?
IN विचारों के संदर्भ में डेटा वेयरहाउस में दृश्य क्रमबद्धता क्या है?
A
Ensuring views execute in a serial order यह सुनिश्चित करना कि दृश्य क्रमिक क्रम में निष्पादित हों
B
Preventing concurrent access to view definitions परिभाषाओं को देखने के लिए समवर्ती पहुंच को रोकना
C
Serializing view refresh operations दृश्य ताज़ा संचालन को क्रमबद्ध करना
D
Ensuring that a snapshot of data used to compute a materialized view is consistent (taken at one point in time) so that the view does not contain data from different points in time - achieved through snapshot isolation or table locking during refresh यह सुनिश्चित करना कि भौतिक दृश्य की गणना करने के लिए उपयोग किए गए डेटा का स्नैपशॉट सुसंगत है (एक समय में एक बिंदु पर लिया गया) ताकि दृश्य में समय के विभिन्न बिंदुओं से डेटा शामिल न हो - ताज़ा करने के दौरान स्नैपशॉट अलगाव या टेबल लॉकिंग के माध्यम से प्राप्त किया गया
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) View consistency: if a materialized view refresh spans hours and base data changes during refresh, the view may contain data from different points in time (some rows from T1, others from T2). Solution: SNAPSHOT isolation (read consistent snapshot throughout refresh) or lock tables during refresh.
व्याख्या (हिन्दी) स्थिरता देखें: यदि कोई भौतिक दृश्य ताज़ा घंटों तक चलता है और ताज़ा होने के दौरान आधार डेटा बदलता है, तो दृश्य में समय के विभिन्न बिंदुओं से डेटा शामिल हो सकता है (टी 1 से कुछ पंक्तियाँ, टी 2 से अन्य)। समाधान: स्नैपशॉट अलगाव (रीफ्रेश के दौरान लगातार स्नैपशॉट पढ़ें) या रीफ्रेश के दौरान तालिकाओं को लॉक करें।
88
EN + हिं Easy
GB What are the restrictions on creating an indexed view in SQL Server (WITH SCHEMABINDING unique clustered index)?
IN SQL सर्वर (SCHEMABINDING अद्वितीय क्लस्टर इंडेक्स के साथ) में अनुक्रमित दृश्य बनाने पर क्या प्रतिबंध हैं?
A
Multiple restrictions including: SCHEMABINDING required no non-deterministic functions no SELECT * no outer joins no subqueries no DISTINCT (in some cases) and base tables must be referenced with 2-part names कई प्रतिबंध जिनमें शामिल हैं: SCHEMABINDING के लिए कोई गैर-नियतात्मक फ़ंक्शन की आवश्यकता नहीं है, कोई चयन नहीं है * कोई बाहरी जोड़ नहीं है, कोई सबक्वेरी नहीं है, कोई DISTINCT नहीं है (कुछ मामलों में) और आधार तालिकाओं को 2-भाग वाले नामों के साथ संदर्भित किया जाना चाहिए
B
Only restriction is unique clustered index केवल प्रतिबंध अद्वितीय संकुल सूचकांक है
C
No restrictions beyond standard index restrictions मानक सूचकांक प्रतिबंधों से परे कोई प्रतिबंध नहीं
D
Only restriction is SCHEMABINDING केवल प्रतिबंध योजनाबद्ध है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) SQL Server indexed view restrictions: WITH SCHEMABINDING required. No: non-deterministic functions (GETDATE, NEWID), outer joins, self-joins, subqueries, SELECT *, DISTINCT, TOP, UNION, EXCEPT, INTERSECT. If GROUP BY used: must include COUNT_BIG(*). 2-part table names required (schema.table).
व्याख्या (हिन्दी) SQL सर्वर अनुक्रमित दृश्य प्रतिबंध: SCHEMABINDING के साथ आवश्यक। नहीं: गैर-नियतात्मक कार्य (GETDATE, NEWID), बाहरी जुड़ाव, स्व-जोड़, उपश्रेणी, चयन *, अलग, शीर्ष, संघ, छोड़कर, प्रतिच्छेद। यदि GROUP BY का उपयोग किया जाता है: COUNT_BIG(*) शामिल होना चाहिए। 2-भाग तालिका नाम आवश्यक (स्कीमा.टेबल)।
89
EN + हिं Easy
GB What is the view over partitioned table optimization in databases like PostgreSQL?
IN PostgreSQL जैसे डेटाबेस में विभाजित तालिका अनुकूलन पर क्या विचार है?
A
Views that span multiple table partitions are not supported एकाधिक तालिका विभाजनों को फैलाने वाले दृश्य समर्थित नहीं हैं
B
Views must be partitioned the same way as base tables दृश्यों को आधार तालिकाओं की तरह ही विभाजित किया जाना चाहिए
C
When a view is defined over a partitioned table queries through the view can benefit from partition pruning - the optimizer eliminates irrelevant partitions based on query predicates even when querying through the view abstraction जब एक दृश्य को विभाजित तालिका पर परिभाषित किया जाता है, तो दृश्य के माध्यम से क्वेरीज़ को विभाजन छंटाई से लाभ हो सकता है - ऑप्टिमाइज़र दृश्य अमूर्त के माध्यम से क्वेरी करने पर भी क्वेरी विधेय के आधार पर अप्रासंगिक विभाजन को समाप्त कर देता है।
D
Views that can only reference partitioned tables वे दृश्य जो केवल विभाजित तालिकाओं का संदर्भ दे सकते हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Partition pruning through views: CREATE VIEW orders_view AS SELECT * FROM orders (partitioned by year). Query: SELECT * FROM orders_view WHERE year=2024. Optimizer sees the partitioning key in WHERE clause, prunes all partitions except 2024, even though the user queries the view (not the base table directly).
व्याख्या (हिन्दी) दृश्यों के माध्यम से विभाजन की छँटाई: ऑर्डर से दृश्य ऑर्डर_व्यू को चयन के रूप में बनाएं * ऑर्डर से (वर्ष के अनुसार विभाजित)। प्रश्न: ऑर्डर_व्यू से चुनें * जहां वर्ष=2024। ऑप्टिमाइज़र WHERE क्लॉज़ में विभाजन कुंजी देखता है, 2024 को छोड़कर सभी विभाजनों को काटता है, भले ही उपयोगकर्ता दृश्य पर प्रश्न पूछता है (सीधे आधार तालिका नहीं)।
90
EN + हिं Easy
GB What is view merging in Oracle query optimization?
IN Oracle क्वेरी ऑप्टिमाइज़ेशन में व्यू मर्जिंग क्या है?
A
Merging two view definitions into one दो दृश्य परिभाषाओं को एक में विलय करना
B
An operation that physically merges materialized view data एक ऑपरेशन जो भौतिक दृश्य डेटा को भौतिक रूप से मर्ज करता है
C
An optimization where Oracle replaces a reference to a view in a query with the underlying view definition (merges view into the main query) allowing the optimizer to optimize the combined query holistically and apply transformations like predicate pushdown into the view एक अनुकूलन जहां ओरेकल एक क्वेरी में एक दृश्य के संदर्भ को अंतर्निहित दृश्य परिभाषा के साथ बदल देता है (दृश्य को मुख्य क्वेरी में विलय कर देता है) ऑप्टिमाइज़र को संयुक्त क्वेरी को समग्र रूप से अनुकूलित करने और दृश्य में विधेय पुशडाउन जैसे परिवर्तनों को लागू करने की अनुमति देता है
D
Merging overlapping views to reduce redundancy अतिरेक को कम करने के लिए अतिव्यापी विचारों को विलय करना
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Oracle view merging: transforms SELECT * FROM (SELECT * FROM t WHERE dept=5) v WHERE v.salary>1000 into SELECT * FROM t WHERE dept=5 AND salary>1000. Allows optimizer to choose better execution plan. Cannot always merge (aggregates, DISTINCT, ROWNUM prevent merging - view then materialized as subquery).
व्याख्या (हिन्दी) ओरेकल व्यू मर्जिंग: SELECT * FROM (SELECT * FROM t WHERE dept=5) v WHERE v.salary>1000 को SELECT * FROM t WHERE dept=5 और सैलरी>1000 में बदल देता है। अनुकूलक को बेहतर निष्पादन योजना चुनने की अनुमति देता है। हमेशा विलय नहीं किया जा सकता (एग्रीगेट्स, DISTINCT, ROWNUM विलय को रोकते हैं - फिर सबक्वेरी के रूप में देखें)।
76–90 of 131