DBMS — MCQ Practice

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

📚 138 Questions 🌐 Hindi + English ✅ Free
भाषा / Language:
138 questions
91
EN + हिं Medium
GB What is the semantic difference between HasA and IsA relationships?
IN हासए और आईएसए संबंधों के बीच अर्थ संबंधी अंतर क्या है?
A
HasA always implies M:N cardinality; IsA implies 1:1 हासए का तात्पर्य हमेशा एम:एन कार्डिनैलिटी से है; ISA का तात्पर्य 1:1 है
B
IsA is for strong entities; HasA for weak entities आईएसए मजबूत संस्थाओं के लिए है; कमजोर संस्थाओं के लिए हासए
C
IsA represents inheritance/specialization (a Car IsA Vehicle); HasA represents composition/aggregation (a Car HasA Engine) - fundamentally different entity relationships आईएसए विरासत/विशेषज्ञता (एक कार आईएसए वाहन) का प्रतिनिधित्व करता है; हासए संरचना/एकत्रीकरण (एक कार हासए इंजन) का प्रतिनिधित्व करता है - मौलिक रूप से भिन्न इकाई संबंध
D
They are interchangeable वे विनिमेय हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) IsA (specialization): subtype inherits all supertype attributes - a Car IS a Vehicle. HasA (composition/aggregation): one entity contains/owns another - a Car HAS an Engine. Different semantics requiring different ER representations and relational mappings.
व्याख्या (हिन्दी) आईएसए (विशेषज्ञता): उपप्रकार सभी सुपरटाइप विशेषताओं को प्राप्त करता है - एक कार एक वाहन है। हैसा (संरचना/एकत्रीकरण): एक इकाई में दूसरी इकाई होती है/उसका स्वामित्व होता है - एक कार में एक इंजन होता है। अलग-अलग शब्दार्थों के लिए अलग-अलग ईआर अभ्यावेदन और संबंधपरक मानचित्रण की आवश्यकता होती है।
92
EN + हिं Medium
GB In ER-to-relational mapping how is a multi-valued attribute converted?
IN ईआर-टू-रिलेशनल मैपिंग में एक बहु-मूल्यवान विशेषता को कैसे परिवर्तित किया जाता है?
A
Stored as a serialized JSON array क्रमबद्ध JSON सरणी के रूप में संग्रहीत
B
Converted into multiple numbered columns (phone1, phone2, phone3) एकाधिक क्रमांकित स्तंभों में परिवर्तित (फ़ोन1, फ़ोन2, फ़ोन3)
C
Converted into a separate table with the parent entity PK as FK and the multi-valued attribute as part of the PK मूल इकाई PK को FK के रूप में और बहु-मूल्यवान विशेषता को PK के भाग के रूप में एक अलग तालिका में परिवर्तित किया गया
D
Added as a comma-separated list in one column एक कॉलम में अल्पविराम से अलग की गई सूची के रूप में जोड़ा गया
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Multi-valued attribute mapping: create a new table with the attribute values + FK to parent entity. The table PK = parent_PK + attribute_value. E.g., Employee_Phone(emp_id FK, phone_number) PK=(emp_id, phone_number).
व्याख्या (हिन्दी) बहु-मूल्यवान विशेषता मैपिंग: मूल इकाई के लिए विशेषता मान + FK के साथ एक नई तालिका बनाएं। तालिका पीके = पेरेंट_पीके + एट्रिब्यूट_वैल्यू। उदाहरण के लिए, कर्मचारी_फ़ोन(emp_id FK, फ़ोन_नंबर) PK=(emp_id, फ़ोन_नंबर)।
93
EN + हिं Easy
GB For the rule Every Department MUST have exactly one Manager what is the participation constraint?
IN नियम के अनुसार प्रत्येक विभाग में एक ही प्रबंधक होना चाहिए, भागीदारी की बाधा क्या है?
A
Partial participation of Department and partial participation of Employee in Manages relationship संबंध प्रबंधन में विभाग की आंशिक भागीदारी और कर्मचारी की आंशिक भागीदारी
B
Many-to-many cardinality with total participation of both entities दोनों संस्थाओं की कुल भागीदारी के साथ अनेक-से-अनेक कार्डिनैलिटी
C
Total participation of Department in Manages relationship with cardinality 1:1 where Department has total and Manager has partial participation प्रमुखता 1:1 के साथ संबंध प्रबंधन में विभाग की कुल भागीदारी, जहां विभाग की कुल और प्रबंधक की आंशिक भागीदारी होती है
D
Total participation of both entities दोनों संस्थाओं की कुल भागीदारी
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Every Department MUST have a manager (total participation of Department = double line). But an employee MAY or MAY NOT be a manager (partial participation). Cardinality: 1:1 (one manager per department, one department per manager at most).
व्याख्या (हिन्दी) प्रत्येक विभाग में एक प्रबंधक होना चाहिए (विभाग की कुल भागीदारी = डबल लाइन)। लेकिन एक कर्मचारी प्रबंधक हो भी सकता है और नहीं भी (आंशिक भागीदारी)। प्रमुखता: 1:1 (प्रति विभाग एक प्रबंधक, प्रति प्रबंधक अधिकतम एक विभाग)।
94
EN + हिं Medium
GB What is schema evolution in ER modeling and why is it challenging?
IN ईआर मॉडलिंग में स्कीमा विकास क्या है और यह चुनौतीपूर्ण क्यों है?
A
The process of modifying the ER schema over time as requirements change challenging because it requires updating existing data, queries, application code, and possibly complex data migrations समय के साथ आवश्यकताओं में बदलाव के साथ ईआर स्कीमा को संशोधित करने की प्रक्रिया चुनौतीपूर्ण है क्योंकि इसमें मौजूदा डेटा, क्वेरीज़, एप्लिकेशन कोड और संभवतः जटिल डेटा माइग्रेशन को अपडेट करने की आवश्यकता होती है।
B
Converting ER models between different notations विभिन्न नोटेशन के बीच ईआर मॉडल परिवर्तित करना
C
Adding new ER models to complement existing ones मौजूदा मॉडलों के पूरक के लिए नए ईआर मॉडल जोड़ना
D
Changing the ER diagram colors and notation ईआर आरेख के रंग और अंकन को बदलना
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Schema evolution: changing database schema over time (adding columns, changing types, restructuring relationships). Challenging because: existing data must be migrated, application queries must be updated, changes must be backward compatible, and migrations in production systems risk data loss.
व्याख्या (हिन्दी) स्कीमा विकास: समय के साथ डेटाबेस स्कीमा बदलना (कॉलम जोड़ना, प्रकार बदलना, रिश्तों का पुनर्गठन)। चुनौतीपूर्ण है क्योंकि: मौजूदा डेटा को माइग्रेट किया जाना चाहिए, एप्लिकेशन क्वेरीज़ को अपडेट किया जाना चाहिए, परिवर्तन पिछड़े संगत होने चाहिए, और उत्पादन प्रणालियों में माइग्रेशन से डेटा हानि का जोखिम होता है।
95
EN + हिं Medium
GB In Crow Foot notation how is zero or one relationship cardinality represented?
IN क्रो फ़ुट नोटेशन में शून्य या एक संबंध कार्डिनैलिटी को कैसे दर्शाया जाता है?
A
A double vertical line एक दोहरी ऊर्ध्वाधर रेखा
B
A single vertical line and a crow foot एक खड़ी रेखा और एक कौवा पैर
C
A circle (zero) and a vertical line (one) on the same end of the relationship line संबंध रेखा के एक ही छोर पर एक वृत्त (शून्य) और एक ऊर्ध्वाधर रेखा (एक)।
D
A circle and a crow foot एक वृत्त और एक कौवा पैर
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Crow Foot notation: mandatory one = ||, optional one (zero or one) = O| (circle + line), mandatory many = |<, optional many (zero or many) = O< (circle + crow foot). The notation is placed at the entity end it describes.
व्याख्या (हिन्दी) क्रो फ़ुट संकेतन: अनिवार्य एक = ||, वैकल्पिक एक (शून्य या एक) = ओ| (वृत्त + रेखा), अनिवार्य अनेक = |
96
EN + हिं Medium
GB What problem does fan trap represent in ER modeling and how is it resolved?
IN ईआर मॉडलिंग में फैन ट्रैप किस समस्या का प्रतिनिधित्व करता है और इसका समाधान कैसे किया जाता है?
A
A recursive relationship that creates an infinite loop एक पुनरावर्ती संबंध जो एक अनंत लूप बनाता है
B
A modeling error where a many-to-one and one-to-many relationship from a single entity incorrectly suggests a path between entities leading to incorrect query results - resolved by restructuring the relationships एक मॉडलिंग त्रुटि जहां एक ही इकाई से अनेक-से-एक और एक-से-अनेक संबंध गलत तरीके से इकाइयों के बीच एक पथ का सुझाव देते हैं जिससे गलत क्वेरी परिणाम प्राप्त होते हैं - संबंधों को पुनर्गठित करके हल किया जाता है
C
A trap caused by having too many multi-valued attributes बहुत अधिक बहु-मूल्यवान विशेषताएँ होने के कारण उत्पन्न हुआ जाल
D
A relationship where entities fan out to too many subtypes एक ऐसा रिश्ता जहां संस्थाएं बहुत सारे उपप्रकारों को बढ़ावा देती हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Fan trap: A has multiple Bs, each B has multiple Cs, but if we join A-C through B, we cannot determine which Cs belong to which As without going through B. Resolved by either restructuring relationships or adding a direct A-C relationship.
व्याख्या (हिन्दी) फैन ट्रैप: A में एकाधिक B हैं, प्रत्येक B में एकाधिक C हैं, लेकिन यदि हम A-C को B से जोड़ते हैं, तो हम B से गुजरे बिना यह निर्धारित नहीं कर सकते कि कौन सा C किस A से संबंधित है। या तो रिश्तों को पुनर्गठित करके या प्रत्यक्ष A-C संबंध जोड़कर हल किया जाता है।
97
EN + हिं Easy
GB What is a chasm trap in ER modeling?
IN ईआर मॉडलिंग में खाई जाल क्या है?
A
A recursive relationship with no termination condition कोई समाप्ति शर्त के साथ एक पुनरावर्ती संबंध
B
A relationship between more than four entity types चार से अधिक इकाई प्रकारों के बीच संबंध
C
A gap in a relationship path where a minimum cardinality of zero means some entities have no corresponding connected entities causing data to be missed in queries संबंध पथ में एक अंतराल जहां शून्य की न्यूनतम कार्डिनैलिटी का मतलब है कि कुछ संस्थाओं के पास कोई संबंधित कनेक्टेड संस्थाएं नहीं हैं, जिसके कारण प्रश्नों में डेटा छूट जाता है
D
A relationship where the depth of nesting is too deep एक ऐसा रिश्ता जहां रिश्ते की गहराई बहुत गहरी होती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Chasm trap: occurs when a path through relationships has a minimum cardinality of zero (optional relationship), meaning some entities have no connection through the path. This causes data to disappear in multi-table joins. Resolved by using outer joins or redesigning the relationship.
व्याख्या (हिन्दी) खाई का जाल: तब होता है जब रिश्तों के माध्यम से एक पथ में शून्य (वैकल्पिक संबंध) की न्यूनतम कार्डिनैलिटी होती है, जिसका अर्थ है कि कुछ संस्थाओं का पथ के माध्यम से कोई संबंध नहीं है। इसके कारण मल्टी-टेबल जॉइन में डेटा गायब हो जाता है। बाहरी जुड़ावों का उपयोग करके या रिश्ते को फिर से डिज़ाइन करके हल किया गया।
98
EN + हिं Medium
GB How should overlapping subtypes be handled in ER-to-relational mapping?
IN ईआर-टू-रिलेशनल मैपिंग में ओवरलैपिंग उपप्रकारों को कैसे संभाला जाना चाहिए?
A
Collapse all subtypes into one table with all attributes सभी उपप्रकारों को सभी विशेषताओं के साथ एक तालिका में संक्षिप्त करें
B
Always create separate independent tables हमेशा अलग स्वतंत्र तालिकाएँ बनाएँ
C
Use a separate discriminator table एक अलग विवेचक तालिका का उपयोग करें
D
Various strategies: single table with type indicators and nullable columns, separate subtype tables with FK to supertype, or a type membership table allowing multiple type memberships विभिन्न रणनीतियाँ: प्रकार संकेतकों और अशक्त स्तंभों के साथ एकल तालिका, सुपरटाइप के लिए एफके के साथ अलग उपप्रकार तालिकाएँ, या एक प्रकार की सदस्यता तालिका जो कई प्रकार की सदस्यता की अनुमति देती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Overlapping subtype mapping options: (1) Single table + nullable columns for subtype-specific attributes + boolean flags for type membership (denormalized). (2) Separate subtype tables each with FK to supertype + multiple type membership rows. Choice depends on overlap frequency and query patterns.
व्याख्या (हिन्दी) ओवरलैपिंग उपप्रकार मैपिंग विकल्प: (1) एकल तालिका + उपप्रकार-विशिष्ट विशेषताओं के लिए अशक्त कॉलम + प्रकार सदस्यता के लिए बूलियन झंडे (असामान्यीकृत)। (2) एफके से सुपरटाइप + एकाधिक प्रकार की सदस्यता पंक्तियों के साथ प्रत्येक उपप्रकार तालिका को अलग करें। चयन ओवरलैप आवृत्ति और क्वेरी पैटर्न पर निर्भर करता है।
99
EN + हिं Easy
GB In an ER diagram for Student ENROLLS_IN Course with attribute grade - what does placing grade on the relationship signify?
IN विशेषता ग्रेड के साथ छात्र ENROLLS_IN पाठ्यक्रम के लिए ईआर आरेख में - संबंध पर ग्रेड रखने का क्या मतलब है?
A
Grade is a derived attribute of the Student entity ग्रेड छात्र इकाई का एक व्युत्पन्न गुण है
B
Grade is a property of the specific enrollment instance (the combination of a particular student in a particular course) not of Student alone or Course alone ग्रेड विशिष्ट नामांकन उदाहरण (किसी विशेष पाठ्यक्रम में किसी विशेष छात्र का संयोजन) की संपत्ति है, अकेले छात्र या अकेले पाठ्यक्रम की नहीं
C
Grade is a property of the Course only ग्रेड केवल पाठ्यक्रम की संपत्ति है
D
Grade is a property of the Student only ग्रेड केवल छात्र की संपत्ति है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Grade is a relationship attribute: it does not belong to Student (the student has different grades in different courses) or to Course (different students have different grades). It belongs to the specific ENROLLMENT instance = the combination of (Student, Course).
व्याख्या (हिन्दी) ग्रेड एक संबंध विशेषता है: यह छात्र (अलग-अलग पाठ्यक्रमों में छात्र के अलग-अलग ग्रेड हैं) या पाठ्यक्रम (अलग-अलग छात्रों के अलग-अलग ग्रेड) से संबंधित नहीं है। यह विशिष्ट नामांकन उदाहरण = (छात्र, पाठ्यक्रम) के संयोजन से संबंधित है।
100
EN + हिं Medium
GB When is a direct ternary relationship better than decomposed binary relationships?
IN विघटित बाइनरी संबंधों की तुलना में प्रत्यक्ष त्रिक संबंध कब बेहतर होता है?
A
A relationship between three instances of the same entity एक ही इकाई के तीन उदाहरणों के बीच संबंध
B
A relationship simultaneously associating three entity types used when decomposition into binary relationships would lose information about the three-way association एक संबंध जो एक साथ तीन इकाई प्रकारों को जोड़ता है, जिसका उपयोग द्विआधारी संबंधों में विघटित होने पर किया जाता है, तीन-तरफा एसोसिएशन के बारे में जानकारी खो देगा
C
A ternary relationship with three attributes per entity प्रति इकाई तीन विशेषताओं के साथ एक त्रिक संबंध
D
A relationship with three participation constraints तीन भागीदारी बाधाओं वाला संबंध
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Ternary relationship involves three entity types simultaneously. Necessary when a three-way association cannot be represented by multiple binary relationships without losing meaning. E.g., Supplier supplies Part for Project - the combination of all three matters.
व्याख्या (हिन्दी) त्रिक संबंध में एक साथ तीन इकाई प्रकार शामिल होते हैं। यह आवश्यक है जब तीन-तरफा एसोसिएशन को अर्थ खोए बिना कई बाइनरी रिश्तों द्वारा प्रस्तुत नहीं किया जा सकता है। उदाहरण के लिए, आपूर्तिकर्ता परियोजना के लिए हिस्से की आपूर्ति करता है - तीनों मामलों का संयोजन।
101
EN + हिं Easy
GB What is the entity resolution problem in ER modeling?
IN ईआर मॉडलिंग में इकाई समाधान समस्या क्या है?
A
Determining which entities should be weak entities यह निर्धारित करना कि कौन सी संस्थाएँ कमजोर संस्थाएँ होनी चाहिए
B
Resolving the cardinality of entity relationships इकाई संबंधों की प्रमुखता का समाधान करना
C
Resolving conflicts between two entity types दो इकाई प्रकारों के बीच विवादों का समाधान करना
D
The challenge of determining whether two references to entities represent the same real-world entity (deduplication/record linkage) crucial in data integration and federated database design यह निर्धारित करने की चुनौती कि क्या संस्थाओं के दो संदर्भ एक ही वास्तविक दुनिया इकाई (डीडुप्लीकेशन/रिकॉर्ड लिंकेज) का प्रतिनिधित्व करते हैं, डेटा एकीकरण और फ़ेडरेटेड डेटाबेस डिज़ाइन में महत्वपूर्ण है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Entity resolution (record linkage/deduplication): determining if two database records refer to the same real-world entity. Critical in data integration: the same person may appear as John Smith in one DB and J. Smith in another. Solved with similarity functions, blocking strategies, and machine learning classifiers.
व्याख्या (हिन्दी) इकाई रिज़ॉल्यूशन (रिकॉर्ड लिंकेज/डीडुप्लीकेशन): यह निर्धारित करना कि क्या दो डेटाबेस रिकॉर्ड एक ही वास्तविक दुनिया इकाई को संदर्भित करते हैं। डेटा एकीकरण में महत्वपूर्ण: एक ही व्यक्ति एक डीबी में जॉन स्मिथ और दूसरे में जे. स्मिथ के रूप में दिखाई दे सकता है। समानता कार्यों, अवरुद्ध रणनीतियों और मशीन लर्निंग क्लासिफायर के साथ हल किया गया।
102
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 वर्कबेंच।
103
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|, कई =
104
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 ढाँचे इन तीनों का समर्थन करते हैं।
105
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। यदि ग्राहक ईमेल बदलता है (जो प्राकृतिक कुंजी थी), तो किसी कैस्केड अपडेट की आवश्यकता नहीं है। यूयूआईडी: विश्व स्तर पर अद्वितीय, वितरित आवेषण के लिए किसी समन्वय की आवश्यकता नहीं है। प्राकृतिक कुंजी: सरोगेट पीके के साथ अद्वितीय (एसएसएन) बाधा जोड़ी गई। अद्वितीय बाधा व्यवसाय की विशिष्टता सुनिश्चित करती है जबकि सरोगेट कुंजी स्थिर जुड़ाव प्रदान करती है।
91–105 of 138