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
121
EN + हिं Medium
GB What is the purpose of the role name in an ER diagram relationship?
IN ईआर आरेख संबंध में भूमिका नाम का उद्देश्य क्या है?
A
To clarify the role/function each entity plays in a relationship especially important in recursive (self-referential) relationships किसी रिश्ते में प्रत्येक इकाई द्वारा निभाई जाने वाली भूमिका/कार्य को स्पष्ट करना, विशेष रूप से पुनरावर्ती (स्व-संदर्भित) रिश्तों में महत्वपूर्ण है
B
To specify the cardinality of the relationship रिश्ते की प्रमुखता निर्दिष्ट करने के लिए
C
To specify which entity is stronger यह निर्दिष्ट करने के लिए कि कौन सी इकाई अधिक मजबूत है
D
To indicate the participation constraint type भागीदारी बाधा प्रकार को इंगित करने के लिए
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Role names label what each entity plays in a relationship. Critical for recursive relationships: Employee manages Employee - one instance is SUPERVISOR and the other is SUBORDINATE. Adds semantic clarity to relationship semantics.
व्याख्या (हिन्दी) भूमिका नाम लेबल करते हैं कि प्रत्येक इकाई किसी रिश्ते में क्या निभाती है। पुनरावर्ती संबंधों के लिए महत्वपूर्ण: कर्मचारी कर्मचारी का प्रबंधन करता है - एक उदाहरण पर्यवेक्षक है और दूसरा अधीनस्थ है। संबंध शब्दार्थ में अर्थ संबंधी स्पष्टता जोड़ता है।
122
EN + हिं Easy
GB What is total specialization constraint in EER modeling?
IN ईईआर मॉडलिंग में कुल विशेषज्ञता बाधा क्या है?
A
Every supertype instance MUST be a member of at least one subtype contrasted with partial where supertype instances need not belong to any subtype प्रत्येक सुपरटाइप उदाहरण को आंशिक के विपरीत कम से कम एक उपप्रकार का सदस्य होना चाहिए, जहां सुपरटाइप उदाहरणों को किसी भी उपप्रकार से संबंधित होने की आवश्यकता नहीं है
B
All subtypes must have the same attributes सभी उपप्रकारों में समान गुण होने चाहिए
C
All supertype attributes must be inherited by all subtypes सभी सुपरटाइप विशेषताएँ सभी उपप्रकारों से विरासत में मिलनी चाहिए
D
The supertype must have a total participation constraint सुपरटाइप में कुल भागीदारी बाधा होनी चाहिए
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Total specialization: every entity in the supertype MUST belong to at least one subtype. E.g., every Person must be either Employee or Student. Partial specialization: some persons may not fit any defined subtype.
व्याख्या (हिन्दी) कुल विशेषज्ञता: सुपरटाइप में प्रत्येक इकाई कम से कम एक उपप्रकार से संबंधित होनी चाहिए। उदाहरण के लिए, प्रत्येक व्यक्ति को या तो कर्मचारी होना चाहिए या छात्र होना चाहिए। आंशिक विशेषज्ञता: कुछ व्यक्ति किसी भी परिभाषित उपप्रकार में फिट नहीं हो सकते हैं।
123
EN + हिं Medium
GB How would you represent a category (UNION type) in EER modeling?
IN आप ईईआर मॉडलिंग में एक श्रेणी (यूनियन प्रकार) का प्रतिनिधित्व कैसे करेंगे?
A
As a weak entity with multiple identifying relationships एकाधिक पहचान वाले रिश्तों वाली एक कमजोर इकाई के रूप में
B
As a union of supertype entities where a subtype can be associated with instances from different supertype entity sets shown with a U symbol in EER diagrams सुपरटाइप इकाइयों के एक संघ के रूप में जहां एक उपप्रकार को ईईआर आरेखों में यू प्रतीक के साथ दिखाए गए विभिन्न सुपरटाइप इकाई सेटों के उदाहरणों से जोड़ा जा सकता है
C
As a many-to-many relationship between two entity types दो इकाई प्रकारों के बीच अनेक-से-अनेक संबंध के रूप में
D
As a regular entity with multiple parents एकाधिक माता-पिता वाली एक नियमित इकाई के रूप में
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Category/UNION type: a subtype that is a subset of the UNION of two or more supertype entity types. E.g., Account_Owner can be either a Person OR an Organization. Denoted with U symbol. Contrasts with regular specialization.
व्याख्या (हिन्दी) श्रेणी/यूनियन प्रकार: एक उपप्रकार जो दो या दो से अधिक सुपरटाइप इकाई प्रकारों के यूनियन का एक उपसमूह है। उदाहरण के लिए, खाता_स्वामी या तो एक व्यक्ति या एक संगठन हो सकता है। यू चिन्ह से दर्शाया गया है। नियमित विशेषज्ञता के साथ विरोधाभास।
124
EN + हिं Medium
GB When converting an ER model to relational schema a weak entity is mapped by:
IN ईआर मॉडल को रिलेशनल स्कीमा में परिवर्तित करते समय एक कमजोर इकाई को मैप किया जाता है:
A
Creating a table with its own independent primary key अपनी स्वयं की स्वतंत्र प्राथमिक कुंजी के साथ एक तालिका बनाना
B
Creating a merged table with the strong entity मजबूत इकाई के साथ एक मर्ज की गई तालिका बनाना
C
Creating a separate lookup table एक अलग लुकअप टेबल बनाना
D
Creating a table whose primary key is the combination of its partial key (discriminator) and the primary key of its identifying strong entity with a foreign key to the owner table एक तालिका बनाना जिसकी प्राथमिक कुंजी इसकी आंशिक कुंजी (विभेदक) का संयोजन है और मालिक तालिका के लिए एक विदेशी कुंजी के साथ इसकी पहचान करने वाली मजबूत इकाई की प्राथमिक कुंजी है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Weak entity mapping: table with columns for all its attributes + FK column(s) referencing the owner strong entity. Primary key = discriminator + owner_PK. FK to owner must be part of the ON DELETE CASCADE relationship.
व्याख्या (हिन्दी) कमजोर इकाई मैपिंग: इसकी सभी विशेषताओं के लिए कॉलम वाली तालिका + मालिक की मजबूत इकाई को संदर्भित करने वाले एफके कॉलम। प्राथमिक कुंजी = विवेचक + स्वामी_पीके। मालिक को FK ऑन डिलीट कैस्केड संबंध का हिस्सा होना चाहिए।
125
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.
व्याख्या (हिन्दी) आईएसए (विशेषज्ञता): उपप्रकार सभी सुपरटाइप विशेषताओं को प्राप्त करता है - एक कार एक वाहन है। हैसा (संरचना/एकत्रीकरण): एक इकाई में दूसरी इकाई होती है/उसका स्वामित्व होता है - एक कार में एक इंजन होता है। अलग-अलग शब्दार्थों के लिए अलग-अलग ईआर अभ्यावेदन और संबंधपरक मानचित्रण की आवश्यकता होती है।
126
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, फ़ोन_नंबर)।
127
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 (प्रति विभाग एक प्रबंधक, प्रति प्रबंधक अधिकतम एक विभाग)।
128
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.
व्याख्या (हिन्दी) स्कीमा विकास: समय के साथ डेटाबेस स्कीमा बदलना (कॉलम जोड़ना, प्रकार बदलना, रिश्तों का पुनर्गठन)। चुनौतीपूर्ण है क्योंकि: मौजूदा डेटा को माइग्रेट किया जाना चाहिए, एप्लिकेशन क्वेरीज़ को अपडेट किया जाना चाहिए, परिवर्तन पिछड़े संगत होने चाहिए, और उत्पादन प्रणालियों में माइग्रेशन से डेटा हानि का जोखिम होता है।
129
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.
व्याख्या (हिन्दी) क्रो फ़ुट संकेतन: अनिवार्य एक = ||, वैकल्पिक एक (शून्य या एक) = ओ| (वृत्त + रेखा), अनिवार्य अनेक = |
130
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 संबंध जोड़कर हल किया जाता है।
131
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.
व्याख्या (हिन्दी) खाई का जाल: तब होता है जब रिश्तों के माध्यम से एक पथ में शून्य (वैकल्पिक संबंध) की न्यूनतम कार्डिनैलिटी होती है, जिसका अर्थ है कि कुछ संस्थाओं का पथ के माध्यम से कोई संबंध नहीं है। इसके कारण मल्टी-टेबल जॉइन में डेटा गायब हो जाता है। बाहरी जुड़ावों का उपयोग करके या रिश्ते को फिर से डिज़ाइन करके हल किया गया।
132
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) एफके से सुपरटाइप + एकाधिक प्रकार की सदस्यता पंक्तियों के साथ प्रत्येक उपप्रकार तालिका को अलग करें। चयन ओवरलैप आवृत्ति और क्वेरी पैटर्न पर निर्भर करता है।
133
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).
व्याख्या (हिन्दी) ग्रेड एक संबंध विशेषता है: यह छात्र (अलग-अलग पाठ्यक्रमों में छात्र के अलग-अलग ग्रेड हैं) या पाठ्यक्रम (अलग-अलग छात्रों के अलग-अलग ग्रेड) से संबंधित नहीं है। यह विशिष्ट नामांकन उदाहरण = (छात्र, पाठ्यक्रम) के संयोजन से संबंधित है।
134
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.
व्याख्या (हिन्दी) त्रिक संबंध में एक साथ तीन इकाई प्रकार शामिल होते हैं। यह आवश्यक है जब तीन-तरफा एसोसिएशन को अर्थ खोए बिना कई बाइनरी रिश्तों द्वारा प्रस्तुत नहीं किया जा सकता है। उदाहरण के लिए, आपूर्तिकर्ता परियोजना के लिए हिस्से की आपूर्ति करता है - तीनों मामलों का संयोजन।
135
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.
व्याख्या (हिन्दी) इकाई रिज़ॉल्यूशन (रिकॉर्ड लिंकेज/डीडुप्लीकेशन): यह निर्धारित करना कि क्या दो डेटाबेस रिकॉर्ड एक ही वास्तविक दुनिया इकाई को संदर्भित करते हैं। डेटा एकीकरण में महत्वपूर्ण: एक ही व्यक्ति एक डीबी में जॉन स्मिथ और दूसरे में जे. स्मिथ के रूप में दिखाई दे सकता है। समानता कार्यों, अवरुद्ध रणनीतियों और मशीन लर्निंग क्लासिफायर के साथ हल किया गया।
121–135 of 138