DBMS — MCQ Practice

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

📚 2982 Questions 🌐 Hindi + English ✅ Free
भाषा / Language:
2982 questions
1801
EN + हिं Easy
GB What is the active-active database cluster and what challenges does it present?
IN सक्रिय-सक्रिय डेटाबेस क्लस्टर क्या है और यह क्या चुनौतियाँ प्रस्तुत करता है?
A
A cluster that uses active replication for reads only एक क्लस्टर जो केवल पढ़ने के लिए सक्रिय प्रतिकृति का उपयोग करता है
B
A cluster where only one node is active at a time एक क्लस्टर जहां एक समय में केवल एक नोड सक्रिय होता है
C
A cluster with active monitoring and automated failover only केवल सक्रिय निगरानी और स्वचालित विफलता वाला क्लस्टर
D
A cluster where multiple nodes simultaneously accept read and write operations; challenges include write-write conflicts (two nodes update same row simultaneously), conflict resolution strategies, increased network overhead for synchronization, and consistency vs availability trade-offs एक क्लस्टर जहां एकाधिक नोड एक साथ पढ़ने और लिखने के संचालन को स्वीकार करते हैं; चुनौतियों में लिखना-लिखना संघर्ष (दो नोड एक ही पंक्ति को एक साथ अपडेट करते हैं), संघर्ष समाधान रणनीतियाँ, सिंक्रनाइज़ेशन के लिए नेटवर्क ओवरहेड में वृद्धि, और स्थिरता बनाम उपलब्धता ट्रेड-ऑफ शामिल हैं।
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Active-active implementations: Galera Cluster (MySQL): synchronous multi-master, write certification (rejects conflicting writes). CockroachDB: distributed consensus (Raft), serializable isolation across nodes. MongoDB: single primary per replica set (not true active-active). Conflict resolution in eventually-consistent active-active: vector clocks, CRDTs, application-level merge logic.
व्याख्या (हिन्दी) सक्रिय-सक्रिय कार्यान्वयन: गैलेरा क्लस्टर (MySQL): सिंक्रोनस मल्टी-मास्टर, प्रमाणन लिखें (परस्पर विरोधी लेखन को अस्वीकार करता है)। कॉकरोचडीबी: वितरित सर्वसम्मति (बेड़ा), नोड्स में क्रमबद्ध अलगाव। MongoDB: प्रति प्रतिकृति सेट एकल प्राथमिक (वास्तव में सक्रिय-सक्रिय नहीं)। अंततः-संगत सक्रिय-सक्रिय में संघर्ष समाधान: वेक्टर घड़ियां, सीआरडीटी, एप्लिकेशन-स्तरीय मर्ज तर्क।
1802
EN + हिं Easy
GB What is HTAP (Hybrid Transactional/Analytical Processing) database architecture?
IN HTAP (हाइब्रिड ट्रांजेक्शनल/एनालिटिकल प्रोसेसिंग) डेटाबेस आर्किटेक्चर क्या है?
A
A type of database that only supports hash-based partitioning एक प्रकार का डेटाबेस जो केवल हैश-आधारित विभाजन का समर्थन करता है
B
A database that handles only high-throughput transactions एक डेटाबेस जो केवल उच्च-थ्रूपुट लेनदेन को संभालता है
C
A high-availability architecture for transaction processing लेनदेन प्रसंस्करण के लिए एक उच्च उपलब्धता वास्तुकला
D
An architecture that combines OLTP and OLAP workloads in the same database system, eliminating the need for separate data warehouse ETL pipelines; achieves this through in-memory row store for OLTP plus columnar store for OLAP, or real-time replication from row store to column store एक आर्किटेक्चर जो ओएलटीपी और ओएलएपी वर्कलोड को एक ही डेटाबेस सिस्टम में जोड़ता है, जिससे अलग डेटा वेयरहाउस ईटीएल पाइपलाइनों की आवश्यकता समाप्त हो जाती है; ओएलटीपी के लिए इन-मेमोरी पंक्ति स्टोर और ओएलएपी के लिए कॉलमर स्टोर, या पंक्ति स्टोर से कॉलम स्टोर तक वास्तविक समय प्रतिकृति के माध्यम से इसे प्राप्त किया जाता है।
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) HTAP implementations: SAP HANA: pure in-memory, row + column stores. SQL Server HTAP: columnstore indexes on OLTP tables. TiDB (PingCAP): TiKV (row-store OLTP) + TiFlash (columnar OLAP replica updated in real-time). Snowflake: OLAP-focused but supports transactional workloads. Eliminates T+1 analytics lag from nightly ETL.
व्याख्या (हिन्दी) HTAP कार्यान्वयन: SAP हाना: शुद्ध इन-मेमोरी, पंक्ति + कॉलम स्टोर। SQL सर्वर HTAP: OLTP तालिकाओं पर कॉलमस्टोर इंडेक्स। TiDB (पिंगकैप): TiKV (रो-स्टोर OLTP) + TiFlash (स्तंभकार OLAP प्रतिकृति वास्तविक समय में अपडेट की गई)। स्नोफ्लेक: OLAP-केंद्रित लेकिन लेन-देन संबंधी कार्यभार का समर्थन करता है। रात्रिकालीन ईटीएल से टी+1 एनालिटिक्स अंतराल को समाप्त करता है।
1803
EN + हिं Medium
GB What is database sharding and what is the difference between range sharding and hash sharding?
IN डेटाबेस शार्डिंग क्या है और रेंज शार्डिंग और हैश शार्डिंग के बीच क्या अंतर है?
A
Sharding only applies to NoSQL databases not relational databases शेयरिंग केवल NoSQL डेटाबेस पर लागू होती है, रिलेशनल डेटाबेस पर नहीं
B
Sharding horizontally distributes data across multiple database servers; range sharding: assigns rows based on key value ranges enabling efficient range queries but risking hot spots; hash sharding: distributes rows using hash(key) mod num_shards providing even distribution but preventing efficient range scans शेयरिंग क्षैतिज रूप से कई डेटाबेस सर्वरों में डेटा वितरित करती है; रेंज शार्डिंग: प्रमुख मूल्य श्रेणियों के आधार पर पंक्तियों को निर्दिष्ट करता है जिससे कुशल रेंज क्वेरी सक्षम होती है लेकिन हॉट स्पॉट का जोखिम होता है; हैश शार्डिंग: हैश (कुंजी) मॉड num_shards का उपयोग करके पंक्तियों को वितरित करता है जो समान वितरण प्रदान करता है लेकिन कुशल रेंज स्कैन को रोकता है
C
Sharding and replication are the same concept with different names साझाकरण और प्रतिकृति अलग-अलग नामों से एक ही अवधारणा हैं
D
Sharding is identical to table partitioning within a single database शेयरिंग एकल डेटाबेस के भीतर तालिका विभाजन के समान है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Sharding trade-offs: Range sharding: good for time-series (partition by date), poor for sequential inserts (all writes go to last shard). Hash sharding: even distribution, but range queries require scatter-gather across all shards. Consistent hashing: minimizes resharding data movement when adding/removing shards. Used by: Cassandra, DynamoDB (consistent hashing), MongoDB (configurable).
व्याख्या (हिन्दी) शेयरिंग ट्रेड-ऑफ़: रेंज शेयरिंग: समय-श्रृंखला (तिथि के अनुसार विभाजन) के लिए अच्छा है, अनुक्रमिक प्रविष्टियों के लिए खराब है (सभी लेखन अंतिम शार्ड पर जाते हैं)। हैश शार्डिंग: समान वितरण, लेकिन श्रेणी के प्रश्नों के लिए सभी शार्डों में बिखराव-एकत्रीकरण की आवश्यकता होती है। लगातार हैशिंग: शार्ड जोड़ते/हटाते समय पुनः साझा करने वाले डेटा मूवमेंट को कम करता है। इनके द्वारा उपयोग किया जाता है: कैसेंड्रा, डायनेमोडीबी (लगातार हैशिंग), मोंगोडीबी (कॉन्फ़िगर करने योग्य)।
1804
EN + हिं Easy
GB What is the object-relational impedance mismatch and how do ORMs address it?
IN ऑब्जेक्ट-रिलेशनल प्रतिबाधा बेमेल क्या है और ओआरएम इसे कैसे संबोधित करते हैं?
A
A mismatch between database versions and programming language versions डेटाबेस संस्करणों और प्रोग्रामिंग भाषा संस्करणों के बीच एक बेमेल
B
A problem with slow object-oriented query execution in databases डेटाबेस में धीमी ऑब्जेक्ट-ओरिएंटेड क्वेरी निष्पादन के साथ एक समस्या
C
A performance issue caused by having too many objects in memory मेमोरी में बहुत अधिक ऑब्जेक्ट होने के कारण होने वाली प्रदर्शन समस्या
D
The conceptual gap between object-oriented programming (inheritance, associations, identity, encapsulation) and relational databases (tables, foreign keys, joins, set-based operations); ORMs address this by providing mapping configurations that translate between object graphs and table rows ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग (विरासत, एसोसिएशन, पहचान, एनकैप्सुलेशन) और रिलेशनल डेटाबेस (टेबल, विदेशी कुंजी, जॉइन, सेट-आधारित संचालन) के बीच वैचारिक अंतर; ओआरएम इसे मैपिंग कॉन्फ़िगरेशन प्रदान करके संबोधित करते हैं जो ऑब्जेक्ट ग्राफ़ और तालिका पंक्तियों के बीच अनुवाद करते हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) ORM solutions: Inheritance mapping (table-per-class, single-table, joined-table strategies). Identity management (primary key vs object identity). Association loading (lazy vs eager loading). Type conversion (date/time, enums). Examples: Hibernate (Java), SQLAlchemy (Python), ActiveRecord (Ruby), Entity Framework (.NET). Trade-off: ORM convenience vs SQL control.
व्याख्या (हिन्दी) ORM समाधान: इनहेरिटेंस मैपिंग (तालिका-प्रति-वर्ग, एकल-तालिका, सम्मिलित-तालिका रणनीतियाँ)। पहचान प्रबंधन (प्राथमिक कुंजी बनाम वस्तु पहचान)। एसोसिएशन लोडिंग (आलसी बनाम उत्सुक लोडिंग)। रूपांतरण टाइप करें (तिथि/समय, गणनाएँ)। उदाहरण: हाइबरनेट (जावा), SQLAlchemy (पायथन), ActiveRecord (रूबी), एंटिटी फ्रेमवर्क (.NET)। ट्रेड-ऑफ़: ORM सुविधा बनाम SQL नियंत्रण।
1805
EN + हिं Easy
GB What is the document embedding vs referencing decision in document data models?
IN दस्तावेज़ डेटा मॉडल में दस्तावेज़ एम्बेडिंग बनाम संदर्भ निर्णय क्या है?
A
In document databases: embedding stores related data as nested sub-documents within a parent document (denormalized, one read, no joins but large documents); referencing stores related data in separate collections with explicit references (normalized, requires multiple reads but smaller documents and shared data); the choice depends on access patterns and update frequency दस्तावेज़ डेटाबेस में: मूल दस्तावेज़ के भीतर नेस्टेड उप-दस्तावेज़ों के रूप में संबंधित डेटा को एम्बेड करना (असामान्यीकृत, एक पढ़ा हुआ, कोई जोड़ नहीं लेकिन बड़े दस्तावेज़); संदर्भित डेटा को स्पष्ट संदर्भों के साथ अलग-अलग संग्रहों में संग्रहीत करता है (सामान्यीकृत, एकाधिक पढ़ने की आवश्यकता होती है लेकिन छोटे दस्तावेज़ और साझा डेटा); चुनाव एक्सेस पैटर्न और अद्यतन आवृत्ति पर निर्भर करता है
B
A choice between storing documents in memory or on disk दस्तावेज़ों को मेमोरी या डिस्क पर संग्रहीत करने के बीच एक विकल्प
C
A choice between encrypted and unencrypted document storage एन्क्रिप्टेड और अनएन्क्रिप्टेड दस्तावेज़ भंडारण के बीच एक विकल्प
D
A choice between XML and JSON document storage formats XML और JSON दस्तावेज़ भंडारण प्रारूपों के बीच एक विकल्प
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Embed when: data is accessed together always, parent owns the sub-data (one-to-one or one-to-few). Reference when: data is shared across multiple documents, one-to-many with large many side, sub-data is frequently updated independently. MongoDB dollar-lookup (join) is available but expensive - schema design should minimize its use.
व्याख्या (हिन्दी) एम्बेड करें जब: डेटा हमेशा एक साथ एक्सेस किया जाता है, माता-पिता उप-डेटा (एक-से-एक या एक-से-कुछ) का मालिक होता है। संदर्भ जब: डेटा कई दस्तावेज़ों में साझा किया जाता है, एक-से-कई बड़े कई पक्षों के साथ, उप-डेटा अक्सर स्वतंत्र रूप से अपडेट किया जाता है। MongoDB डॉलर-लुकअप (जॉइन) उपलब्ध है लेकिन महंगा है - स्कीमा डिज़ाइन को इसका उपयोग कम से कम करना चाहिए।
1806
EN + हिं Medium
GB What is the columnar data model and how does Apache Parquet implement it?
IN स्तंभ डेटा मॉडल क्या है और Apache Parquet इसे कैसे कार्यान्वित करता है?
A
A data model where columns are indexed but rows are not organized एक डेटा मॉडल जहां कॉलम अनुक्रमित होते हैं लेकिन पंक्तियाँ व्यवस्थित नहीं होती हैं
B
A storage format where data for each column is stored contiguously rather than row-by-row; Apache Parquet implements this with row groups (horizontal partitions), column chunks (vertical partitions within a row group), nested encoding (Dremel levels for nested schemas), and column statistics enabling predicate pushdown एक भंडारण प्रारूप जहां प्रत्येक कॉलम का डेटा पंक्ति-दर-पंक्ति के बजाय क्रमिक रूप से संग्रहीत किया जाता है; Apache Parquet इसे पंक्ति समूहों (क्षैतिज विभाजन), स्तंभ खंडों (पंक्ति समूह के भीतर लंबवत विभाजन), नेस्टेड एन्कोडिंग (नेस्टेड स्कीमा के लिए ड्रेमेल स्तर), और स्तंभ आँकड़ों के साथ लागू करता है जो विधेय पुशडाउन को सक्षम करता है।
C
A data model specific to NoSQL databases that cannot use SQL NoSQL डेटाबेस के लिए विशिष्ट डेटा मॉडल जो SQL का उपयोग नहीं कर सकता
D
A data model where each column is a separate database instance एक डेटा मॉडल जहां प्रत्येक कॉलम एक अलग डेटाबेस उदाहरण है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Parquet: row group (128MB default) -> column chunks -> pages (compressed). Encodings: RLE (run-length), dictionary encoding, bit packing. Statistics: min/max/null count per row group -> predicate pushdown (skip entire row groups). Used by: Spark, Hive, Presto, BigQuery external tables.
व्याख्या (हिन्दी) लकड़ी की छत: पंक्ति समूह (128एमबी डिफ़ॉल्ट) -> स्तंभ खंड -> पृष्ठ (संपीड़ित)। एन्कोडिंग: आरएलई (रन-लेंथ), डिक्शनरी एन्कोडिंग, बिट पैकिंग। आँकड़े: प्रति पंक्ति समूह न्यूनतम/अधिकतम/शून्य गणना -> विधेय पुशडाउन (संपूर्ण पंक्ति समूह छोड़ें)। इनके द्वारा उपयोग किया जाता है: स्पार्क, हाइव, प्रेस्टो, बिगक्वेरी बाहरी टेबल।
1807
EN + हिं Easy
GB What is the time-series data model and what specific optimizations make it different from a general-purpose relational model?
IN समय-श्रृंखला डेटा मॉडल क्या है और कौन से विशिष्ट अनुकूलन इसे सामान्य-उद्देश्य संबंधपरक मॉडल से अलग बनाते हैं?
A
A data model optimized for append-only time-stamped measurements with automatic time-based partitioning, compressed columnar storage (delta encoding compresses well), downsampling of old data, and specialized time functions such as interpolation, moving averages, and gap filling एक डेटा मॉडल जो स्वचालित समय-आधारित विभाजन, संपीड़ित स्तंभ भंडारण (डेल्टा एन्कोडिंग अच्छी तरह से संपीड़ित होता है), पुराने डेटा की डाउनसैंपलिंग और इंटरपोलेशन, मूविंग एवरेज और गैप फिलिंग जैसे विशेष समय कार्यों के साथ केवल-समय-मुद्रांकित माप के लिए अनुकूलित है।
B
A data model used only for financial transaction processing एक डेटा मॉडल जिसका उपयोग केवल वित्तीय लेनदेन प्रसंस्करण के लिए किया जाता है
C
A data model that uses only Unix timestamps as primary keys एक डेटा मॉडल जो प्राथमिक कुंजी के रूप में केवल यूनिक्स टाइमस्टैम्प का उपयोग करता है
D
A data model that stores only timestamps without associated values एक डेटा मॉडल जो संबद्ध मानों के बिना केवल टाइमस्टैम्प संग्रहीत करता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Time-series DBMS: InfluxDB (line protocol: measurement,tags field=value timestamp), TimescaleDB (PostgreSQL extension: hypertables auto-partitioned by time), Prometheus (pull-based metrics, PromQL), ClickHouse (columnar, fast aggregations). Key optimizations: delta-of-delta compression (timestamps close together), Gorilla compression (floating point metrics), automatic data aging.
व्याख्या (हिन्दी) समय-श्रृंखला डीबीएमएस: इन्फ्लक्सडीबी (लाइन प्रोटोकॉल: माप, टैग फ़ील्ड = मूल्य टाइमस्टैम्प), टाइमस्केलडीबी (पोस्टग्रेएसक्यूएल एक्सटेंशन: समय के अनुसार हाइपरटेबल्स ऑटो-विभाजित), प्रोमेथियस (पुल-आधारित मेट्रिक्स, प्रोमक्यूएल), क्लिकहाउस (स्तंभकार, तेज़ एकत्रीकरण)। मुख्य अनुकूलन: डेल्टा-ऑफ-डेल्टा संपीड़न (टाइमस्टैम्प एक साथ बंद), गोरिल्ला संपीड़न (फ्लोटिंग पॉइंट मेट्रिक्स), स्वचालित डेटा एजिंग।
1808
EN + हिं Medium
GB What is the difference between schema-on-read and schema-on-write approaches in data modeling?
IN डेटा मॉडलिंग में स्कीमा-ऑन-रीड और स्कीमा-ऑन-राइट दृष्टिकोण के बीच क्या अंतर है?
A
They are identical approaches used in different database types वे विभिन्न डेटाबेस प्रकारों में उपयोग किए जाने वाले समान दृष्टिकोण हैं
B
Schema-on-read is always more efficient than schema-on-write स्कीमा-ऑन-रीड हमेशा स्कीमा-ऑन-राइट की तुलना में अधिक कुशल होता है
C
Schema-on-write (traditional RDBMS): schema is defined and enforced before data is written; data must conform to schema at write time (strict, consistent but less flexible). Schema-on-read (Hadoop/data lake): raw data is stored without enforcing schema; schema is applied when data is read (flexible, accepts any data format) स्कीमा-ऑन-राइट (पारंपरिक आरडीबीएमएस): डेटा लिखने से पहले स्कीमा को परिभाषित और लागू किया जाता है; डेटा को लिखने के समय स्कीमा के अनुरूप होना चाहिए (सख्त, सुसंगत लेकिन कम लचीला)। स्कीम-ऑन-रीड (Hadoop/डेटा लेक): स्कीमा लागू किए बिना कच्चा डेटा संग्रहीत किया जाता है; डेटा पढ़ते समय स्कीमा लागू किया जाता है (लचीला, किसी भी डेटा प्रारूप को स्वीकार करता है)
D
Schema-on-read is for SQL databases; schema-on-write is for NoSQL only स्कीमा-ऑन-रीड SQL डेटाबेस के लिए है; स्कीमा-ऑन-राइट केवल NoSQL के लिए है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Schema-on-write: CREATE TABLE enforces structure, rejects invalid data at insert time. Schema-on-read: store any JSON/CSV/Parquet files in S3/HDFS; apply schema when querying (Hive external tables, Spark DataFrames). Benefits of SOR: accept data before knowing its structure, multiple schemas on same data. Drawback: data quality issues only discovered at query time.
व्याख्या (हिन्दी) स्कीम-ऑन-राइट: CREATE TABLE संरचना को लागू करता है, सम्मिलित समय पर अमान्य डेटा को अस्वीकार करता है। स्कीम-ऑन-रीड: किसी भी JSON/CSV/Parquet फ़ाइलों को S3/HDFS में संग्रहीत करें; क्वेरी करते समय स्कीमा लागू करें (हाइव बाहरी तालिकाएँ, स्पार्क डेटाफ़्रेम)। एसओआर के लाभ: डेटा की संरचना जानने से पहले उसे स्वीकार करें, एक ही डेटा पर कई स्कीमा। दोष: डेटा गुणवत्ता संबंधी समस्याएं केवल क्वेरी के समय ही खोजी गईं।
1809
EN + हिं Easy
GB What is the outbox pattern in data modeling for distributed systems?
IN वितरित सिस्टम के लिए डेटा मॉडलिंग में आउटबॉक्स पैटर्न क्या है?
A
A pattern that ensures atomicity between database writes and message/event publishing: write the event to an outbox table in the same DB transaction as the business data, then have a separate process reliably publish from the outbox, ensuring events are never lost even if the broker is temporarily unavailable एक पैटर्न जो डेटाबेस लेखन और संदेश/ईवेंट प्रकाशन के बीच परमाणुता सुनिश्चित करता है: ईवेंट को व्यवसाय डेटा के समान डीबी लेनदेन में आउटबॉक्स तालिका में लिखें, फिर आउटबॉक्स से विश्वसनीय रूप से प्रकाशित करने के लिए एक अलग प्रक्रिया रखें, यह सुनिश्चित करते हुए कि ब्रोकर अस्थायी रूप से अनुपलब्ध होने पर भी ईवेंट कभी खो नहीं जाते हैं
B
A backup pattern that stores data outside the primary database एक बैकअप पैटर्न जो प्राथमिक डेटाबेस के बाहर डेटा संग्रहीत करता है
C
A pattern for storing outgoing emails in a database डेटाबेस में आउटगोइंग ईमेल संग्रहीत करने का एक पैटर्न
D
A pattern for archiving old database records to cold storage पुराने डेटाबेस रिकॉर्ड को कोल्ड स्टोरेज में संग्रहित करने का एक पैटर्न
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Outbox pattern: CREATE TABLE outbox (id, aggregate_type, aggregate_id, event_type, payload, created_at, processed_at). Business transaction: INSERT INTO orders...; INSERT INTO outbox(event_type=ORDER_CREATED, payload=...). Outbox relay: polls outbox, publishes to Kafka/RabbitMQ, marks as processed. Ensures at-least-once delivery. Debezium CDC can read outbox via binlog without polling.
व्याख्या (हिन्दी) आउटबॉक्स पैटर्न: टेबल आउटबॉक्स बनाएं (आईडी, एग्रीगेट_टाइप, एग्रीगेट_आईडी, इवेंट_टाइप, पेलोड, क्रिएट_एट, प्रोसेस्ड_एट)। व्यावसायिक लेनदेन: ऑर्डर में सम्मिलित करें...; आउटबॉक्स में डालें(event_type=ORDER_CREATED, पेलोड=...)। आउटबॉक्स रिले: पोल आउटबॉक्स, काफ्का/रैबिटएमक्यू पर प्रकाशित, संसाधित के रूप में चिह्नित। कम से कम एक बार डिलीवरी सुनिश्चित करता है। डेबेज़ियम सीडीसी बिना मतदान के बिनलॉग के माध्यम से आउटबॉक्स पढ़ सकता है।
1810
EN + हिं Easy
GB What is the data vault modeling approach and when is it preferred over star schema?
IN डेटा वॉल्ट मॉडलिंग दृष्टिकोण क्या है और इसे स्टार स्कीमा की तुलना में कब प्राथमिकता दी जाती है?
A
A data model used exclusively for financial institutions and banks एक डेटा मॉडल जिसका उपयोग विशेष रूप से वित्तीय संस्थानों और बैंकों के लिए किया जाता है
B
A data model that stores data in encrypted secure vaults एक डेटा मॉडल जो डेटा को एन्क्रिप्टेड सुरक्षित वॉल्ट में संग्रहीत करता है
C
A hybrid data modeling methodology for enterprise data warehouses that separates hubs (business keys), links (relationships between hubs), and satellites (descriptive attributes with history); preferred when requirements change frequently, full historical tracking is needed, or multiple source systems need to be integrated incrementally एंटरप्राइज़ डेटा वेयरहाउस के लिए एक हाइब्रिड डेटा मॉडलिंग पद्धति जो हब (व्यावसायिक कुंजी), लिंक (हब के बीच संबंध), और उपग्रह (इतिहास के साथ वर्णनात्मक विशेषताएँ) को अलग करती है; प्राथमिकता तब दी जाती है जब आवश्यकताएँ बार-बार बदलती हैं, पूर्ण ऐतिहासिक ट्रैकिंग की आवश्यकता होती है, या एकाधिक स्रोत प्रणालियों को क्रमिक रूप से एकीकृत करने की आवश्यकता होती है
D
A star schema with additional security layers for sensitive data संवेदनशील डेटा के लिए अतिरिक्त सुरक्षा परतों वाला एक स्टार स्कीमा
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Data Vault components: Hub(HUB_CUSTOMER: customer_key, load_date, record_source, business_key). Link(LNK_ORDER: link_key, hub_customer_key, hub_product_key, load_date). Satellite(SAT_CUSTOMER_DETAIL: hub_customer_key, load_date, name, email, hash_diff). Benefits: highly auditable, incremental loading, flexible to new sources. More complex than star schema but better for large enterprise DWs.
व्याख्या (हिन्दी) डेटा वॉल्ट घटक: हब (HUB_CUSTOMER: ग्राहक_कुंजी, लोड_दिनांक, रिकॉर्ड_स्रोत, व्यवसाय_कुंजी)। लिंक (LNK_ORDER: लिंक_की, हब_कस्टमर_की, हब_प्रोडक्ट_की, लोड_डेट)। सैटेलाइट(SAT_CUSTOMER_DETAIL: हब_कस्टमर_की, लोड_डेट, नाम, ईमेल, हैश_डिफ)। लाभ: अत्यधिक श्रव्य, वृद्धिशील लोडिंग, नए स्रोतों के लिए लचीला। स्टार स्कीमा से अधिक जटिल लेकिन बड़े उद्यम डीडब्ल्यू के लिए बेहतर।
1811
EN + हिं Medium
GB What is the difference between conceptual, logical, and physical ER models?
IN वैचारिक, तार्किक और भौतिक ईआर मॉडल के बीच क्या अंतर है?
A
Conceptual ER: high-level diagram with entities and relationships only (no attributes or keys), technology-agnostic, used for stakeholder communication. Logical ER: adds attributes, primary/foreign keys, cardinality, normalization, still DBMS-agnostic. Physical ER: DBMS-specific implementation (actual table names, data types, indexes, constraints, partitioning) वैचारिक ईआर: केवल संस्थाओं और रिश्तों के साथ उच्च स्तरीय आरेख (कोई विशेषता या कुंजी नहीं), प्रौद्योगिकी-अज्ञेयवादी, हितधारक संचार के लिए उपयोग किया जाता है। तार्किक ईआर: विशेषताएँ, प्राथमिक/विदेशी कुंजी, कार्डिनैलिटी, सामान्यीकरण, फिर भी डीबीएमएस-अज्ञेयवादी जोड़ता है। भौतिक ईआर: डीबीएमएस-विशिष्ट कार्यान्वयन (वास्तविक तालिका नाम, डेटा प्रकार, अनुक्रमित, बाधाएं, विभाजन)
B
Conceptual is for developers, logical for DBAs, physical for managers डेवलपर्स के लिए वैचारिक, डीबीए के लिए तार्किक, प्रबंधकों के लिए भौतिक है
C
They are three names for the same ER diagram at different zoom levels वे विभिन्न ज़ूम स्तरों पर एक ही ईआर आरेख के तीन नाम हैं
D
They represent three different database systems to choose from वे चुनने के लिए तीन अलग-अलग डेटाबेस सिस्टम का प्रतिनिधित्व करते हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Design phases: Conceptual (what? business entities like Customer, Order, Product - no PK/FK). Logical (how? normalized tables, keys, constraints, relationships - could be PostgreSQL or Oracle). Physical (exactly? VARCHAR(255), BIGINT UNSIGNED, ENGINE=InnoDB, PARTITION BY RANGE). Tools: Lucidchart for conceptual, ERDPlus for logical, MySQL Workbench for physical.
व्याख्या (हिन्दी) डिज़ाइन चरण: वैचारिक (क्या? ग्राहक, ऑर्डर, उत्पाद जैसी व्यावसायिक इकाइयाँ - कोई पीके/एफके नहीं)। तार्किक (कैसे? सामान्यीकृत तालिकाएँ, कुंजियाँ, बाधाएँ, रिश्ते - PostgreSQL या Oracle हो सकते हैं)। भौतिक (बिल्कुल? VARCHAR(255), BIGINT अहस्ताक्षरित, इंजन=InnoDB, रेंज द्वारा विभाजन)। उपकरण: वैचारिक के लिए ल्यूसिडचार्ट, तार्किक के लिए ईआरडीप्लस, भौतिक के लिए MySQL वर्कबेंच।
1812
EN + हिं Easy
GB What is cardinality notation in ER diagrams and what are the main notational systems used?
IN ईआर आरेखों में कार्डिनैलिटी नोटेशन क्या है और उपयोग की जाने वाली मुख्य नोटेशनल प्रणालियाँ क्या हैं?
A
Cardinality notation refers to the number of columns in a table कार्डिनैलिटी नोटेशन किसी तालिका में स्तंभों की संख्या को संदर्भित करता है
B
Cardinality notation is only used in object-oriented database design कार्डिनैलिटी नोटेशन का उपयोग केवल ऑब्जेक्ट-ओरिएंटेड डेटाबेस डिज़ाइन में किया जाता है
C
Cardinality notation is only used in database query languages कार्डिनैलिटी नोटेशन का उपयोग केवल डेटाबेस क्वेरी भाषाओं में किया जाता है
D
Symbols in ER diagrams that specify how many instances of one entity can be associated with instances of another entity; main systems: Chen notation (1, N, M near relationship diamonds), Crow Foot notation (symbols on relationship lines used in most modern tools), UML class diagram notation (1, 0..1, *, 1..*), and IDEF1X notation ईआर आरेखों में प्रतीक जो निर्दिष्ट करते हैं कि एक इकाई के कितने उदाहरण किसी अन्य इकाई के उदाहरण से जुड़े हो सकते हैं; मुख्य प्रणालियाँ: चेन नोटेशन (1, एन, एम नियर रिलेशनशिप डायमंड्स), क्रो फ़ुट नोटेशन (अधिकांश आधुनिक उपकरणों में उपयोग की जाने वाली रिलेशनशिप लाइनों पर प्रतीक), यूएमएल वर्ग आरेख नोटेशन (1, 0..1, *, 1..*), और आईडीईएफ1एक्स नोटेशन
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Crow Foot (most common in tools like MySQL Workbench, Lucidchart): one = |, zero-or-one = O|, many = <, zero-or-many = O<, one-or-many = |<. Example: Customer(one) to Orders(zero-or-many): Customer side has ||, Orders side has O<. Read as: one Customer has zero or many Orders. Chen: diamonds for relationships with 1 and N/M labels.
व्याख्या (हिन्दी) क्रो फ़ुट (MySQL वर्कबेंच, ल्यूसिडचार्ट जैसे टूल में सबसे आम): एक = |, शून्य-या-एक = O|, कई =
1813
EN + हिं Easy
GB What is entity subtyping and what are the three common implementation strategies in relational databases?
IN इकाई उपप्रकार क्या है और संबंधपरक डेटाबेस में तीन सामान्य कार्यान्वयन रणनीतियाँ क्या हैं?
A
Entity subtyping refers to creating sub-queries in SQL SELECT statements एंटिटी सबटाइपिंग का तात्पर्य SQL SELECT कथनों में उप-प्रश्नियाँ बनाना है
B
Entity subtyping is only possible in object-oriented databases इकाई उपप्रकार केवल ऑब्जेक्ट-ओरिएंटेड डेटाबेस में ही संभव है
C
A technique for partitioning large entity tables into smaller ones बड़ी इकाई तालिकाओं को छोटी तालिकाओं में विभाजित करने की एक तकनीक
D
Entity subtyping (specialization/generalization) maps a supertype-subtype hierarchy to relational tables using: Single Table Inheritance (one table, nulls for subtype-specific columns), Table Per Type (supertype table plus subtype tables with FK to supertype), or Table Per Concrete Type (one table per concrete subtype with no joins but redundant common columns) इकाई उपप्रकार (विशेषज्ञता/सामान्यीकरण) निम्नलिखित का उपयोग करके संबंधपरक तालिकाओं के लिए एक सुपरटाइप-उपप्रकार पदानुक्रम को मैप करता है: सिंगल टेबल इनहेरिटेंस (एक टेबल, उपप्रकार-विशिष्ट कॉलम के लिए नल), टेबल प्रति प्रकार (सुपरटाइप टेबल और सुपरटाइप के लिए एफके के साथ उपप्रकार टेबल), या टेबल प्रति कंक्रीट प्रकार (प्रति कंक्रीट उपप्रकार में एक टेबल जिसमें कोई जोड़ नहीं है लेकिन अनावश्यक सामान्य कॉलम हैं)
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) STI: Person(id, name, type, employee_salary, student_gpa) - nulls for non-applicable subtype columns. Simple SELECTs but many NULLs. TPT: Person(id,name) + Employee(person_id FK,salary) + Student(person_id FK,gpa) - fully normalized, requires JOIN for subtype attributes. TPC: Employee(id,name,salary) + Student(id,name,gpa) - no joins, but name is in both tables. ORM frameworks support all three.
व्याख्या (हिन्दी) एसटीआई: व्यक्ति (आईडी, नाम, प्रकार, कर्मचारी_वेतन, छात्र_जीपीए) - गैर-लागू उपप्रकार कॉलम के लिए शून्य। सरल चयन लेकिन कई शून्य। टीपीटी: व्यक्ति (आईडी, नाम) + कर्मचारी (व्यक्ति_आईडी एफके, वेतन) + छात्र (व्यक्ति_आईडी एफके, जीपीए) - पूरी तरह से सामान्यीकृत, उपप्रकार विशेषताओं के लिए जॉइन की आवश्यकता होती है। टीपीसी: कर्मचारी (आईडी, नाम, वेतन) + छात्र (आईडी, नाम, जीपीए) - कोई शामिल नहीं है, लेकिन नाम दोनों तालिकाओं में है। ORM ढाँचे इन तीनों का समर्थन करते हैं।
1814
EN + हिं Easy
GB What is the surrogate key vs natural key debate in ER/relational design?
IN ईआर/रिलेशनल डिज़ाइन में सरोगेट कुंजी बनाम प्राकृतिक कुंजी बहस क्या है?
A
Natural keys are always better because they carry more meaning प्राकृतिक कुंजियाँ हमेशा बेहतर होती हैं क्योंकि वे अधिक अर्थ रखती हैं
B
Surrogate key (system-generated integer/UUID): stable (never changes even if business data changes), simple (single column joins), private (no business meaning exposed); Natural key (business identifier like SSN, ISBN): meaningful, already unique, no extra column needed but may change, may be complex, may expose sensitive data. Best practice: surrogate PK with unique constraint on natural key सरोगेट कुंजी (सिस्टम-जनरेटेड पूर्णांक/यूयूआईडी): स्थिर (व्यावसायिक डेटा बदलने पर भी कभी नहीं बदलता), सरल (एकल कॉलम जुड़ता है), निजी (कोई व्यावसायिक अर्थ उजागर नहीं); प्राकृतिक कुंजी (एसएसएन, आईएसबीएन जैसे व्यावसायिक पहचानकर्ता): सार्थक, पहले से ही अद्वितीय, कोई अतिरिक्त कॉलम की आवश्यकता नहीं है लेकिन बदल सकता है, जटिल हो सकता है, संवेदनशील डेटा को उजागर कर सकता है। सर्वोत्तम अभ्यास: प्राकृतिक कुंजी पर अद्वितीय बाधा के साथ सरोगेट पीके
C
The choice only matters for very large databases with millions of rows यह विकल्प केवल लाखों पंक्तियों वाले बहुत बड़े डेटाबेस के लिए ही मायने रखता है
D
Surrogate keys are always better than natural keys in every scenario हर परिदृश्य में सरोगेट कुंजियाँ हमेशा प्राकृतिक कुंजियों से बेहतर होती हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Surrogate key benefits: customer.id INT AUTO_INCREMENT - simple FK in orders. If customer changes email (which was natural key), no cascade updates needed. UUID: globally unique, no coordination needed for distributed inserts. Natural key: UNIQUE(ssn) constraint added alongside surrogate PK. The unique constraint ensures business uniqueness while surrogate key provides stable joins.
व्याख्या (हिन्दी) सरोगेट प्रमुख लाभ: customer.id INT AUTO_INCREMENT - ऑर्डर में सरल FK। यदि ग्राहक ईमेल बदलता है (जो प्राकृतिक कुंजी थी), तो किसी कैस्केड अपडेट की आवश्यकता नहीं है। यूयूआईडी: विश्व स्तर पर अद्वितीय, वितरित आवेषण के लिए किसी समन्वय की आवश्यकता नहीं है। प्राकृतिक कुंजी: सरोगेट पीके के साथ अद्वितीय (एसएसएन) बाधा जोड़ी गई। अद्वितीय बाधा व्यवसाय की विशिष्टता सुनिश्चित करती है जबकि सरोगेट कुंजी स्थिर जुड़ाव प्रदान करती है।
1815
EN + हिं Medium
GB What is the concept of ontological commitment in ER modeling and how does it affect schema design?
IN ईआर मॉडलिंग में ऑन्टोलॉजिकल प्रतिबद्धता की अवधारणा क्या है और यह स्कीमा डिज़ाइन को कैसे प्रभावित करती है?
A
The number of entities committed to memory in the database डेटाबेस में मेमोरी के लिए प्रतिबद्ध इकाइयों की संख्या
B
A legal commitment to use a specific database vendor एक विशिष्ट डेटाबेस विक्रेता का उपयोग करने की कानूनी प्रतिबद्धता
C
The set of assumptions made about the nature and categories of entities in the domain; in ER design this means deciding what constitutes an entity vs an attribute vs a relationship - different ontological choices lead to fundamentally different schemas that are logically equivalent but have different query performance and flexibility trade-offs डोमेन में संस्थाओं की प्रकृति और श्रेणियों के बारे में बनाई गई धारणाओं का सेट; ईआर डिज़ाइन में इसका मतलब यह तय करना है कि एक इकाई बनाम एक विशेषता बनाम एक रिश्ता क्या बनता है - अलग-अलग ऑन्टोलॉजिकल विकल्प मौलिक रूप से अलग-अलग स्कीमा का कारण बनते हैं जो तार्किक रूप से समतुल्य होते हैं लेकिन अलग-अलग क्वेरी प्रदर्शन और लचीलेपन वाले ट्रेड-ऑफ होते हैं
D
A formal contract between database designers and stakeholders डेटाबेस डिजाइनरों और हितधारकों के बीच एक औपचारिक अनुबंध
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Example: Should Address be an entity or an attribute of Customer? As attribute: simpler, one table. As entity: reusable (Employee and Customer share addresses), but requires JOIN. Should Employment be a relationship or an entity? As entity: allows attributes (start_date, salary, role) and participation in other relationships. These ontological choices drive schema design.
व्याख्या (हिन्दी) उदाहरण: क्या पता ग्राहक की इकाई या विशेषता होना चाहिए? विशेषता के रूप में: सरल, एक तालिका। इकाई के रूप में: पुन: प्रयोज्य (कर्मचारी और ग्राहक पते साझा करते हैं), लेकिन शामिल होने की आवश्यकता है। क्या रोज़गार एक रिश्ता या इकाई होना चाहिए? इकाई के रूप में: विशेषताओं (प्रारंभ तिथि, वेतन, भूमिका) और अन्य संबंधों में भागीदारी की अनुमति देता है। ये ऑन्टोलॉजिकल विकल्प स्कीमा डिज़ाइन को संचालित करते हैं।
1801–1815 of 2982