GKPAD.COM

ONLINE HINDI EDUCATION PORTAL

IGNOU BCS-092 Solved Question Paper PDF Download

The IGNOU BCS-092 Solved Question Paper PDF Download page is designed to help students access high-quality exam resources in one place. Here, you can find ignou solved question paper IGNOU Previous Year Question paper solved PDF that covers all important questions with detailed answers. This page provides IGNOU all Previous year Question Papers in one PDF format, making it easier for students to prepare effectively.

Whether you are looking for IGNOU Previous Year Question paper solved in English or ignou previous year question paper solved in hindi, this page offers both options to suit your learning needs. These solved papers help you understand exam patterns, improve answer writing skills, and boost confidence for upcoming exams.

IGNOU BCS-092 Solved Question Paper PDF

IGNOU Previous Year Solved Question Papers

This section provides IGNOU BCS-092 Solved Question Paper PDF in both Hindi and English. These ignou solved question paper IGNOU Previous Year Question paper solved PDF include detailed answers to help you understand exam patterns and improve your preparation. You can also access IGNOU all Previous year Question Papers in one PDF for quick and effective revision before exams.

IGNOU BCS-092 Previous Year Solved Question Paper in Hindi

Q1. (a) डेटा एब्स्ट्रैक्शन क्या है? डेटाबेस का उपयोग करके इसे कैसे प्राप्त किया जा सकता है? 5 (b) व्यू क्या है? जब आप व्यू का उपयोग करके डेटा इन्सर्ट, अपडेट या डिलीट करने का प्रयास करते हैं तो क्या बाधाएं आती हैं? 5 (c) XYZ पब्लिशिंग हाउस विभिन्न विषयों पर किताबें छापता है। पुस्तकों के लेखक अध्ययन के केवल एक क्षेत्र में विशेषज्ञता रखते हैं। कंपनी में पुस्तक संपादक हैं जो पुस्तक संपादन के लिए जिम्मेदार हैं। दुकान के मालिक कंपनी से कई किताबें खरीद सकते हैं। प्रकाशन गृह कई आपूर्तिकर्ताओं से प्रकाशन सामग्री खरीदता है। (i) सभी एंटिटीज और एट्रिब्यूट्स की सूची बनाएं। 2 (ii) संबंधों को पहचानें। 2 (iii) संबंधों में संभावित कीज (keys) खोजें। 3 (iv) E-R डायग्राम बनाएं। 3 (v) उदाहरणों के साथ वैकल्पिक और अनिवार्य संबंधों की व्याख्या करें। 5 (d) नॉर्मलाइजेशन की आवश्यकता की व्याख्या करें। 5

Ans.

(a) डेटा एब्स्ट्रैक्शन (Data Abstraction)

डेटा एब्स्ट्रैक्शन उपयोगकर्ताओं से डेटा के भंडारण और रखरखाव के जटिल आंतरिक विवरण को छिपाने की प्रक्रिया है। इसका मुख्य लक्ष्य उपयोगकर्ताओं को सिस्टम के साथ इंटरैक्ट करने के लिए एक सरल इंटरफ़ेस प्रदान करना है, बिना यह चिंता किए कि डेटा भौतिक रूप से कैसे संग्रहीत और प्रबंधित किया जाता है। डेटाबेस में, डेटा एब्स्ट्रैक्शन तीन स्तरों पर प्राप्त किया जाता है:

  • फिजिकल लेवल (Physical Level): यह एब्स्ट्रैक्शन का सबसे निचला स्तर है। यह बताता है कि डेटा वास्तव में स्टोरेज डिवाइस पर कैसे संग्रहीत होता है, जैसे कि फाइलों, रिकॉर्ड्स और डेटा स्ट्रक्चर्स में। डेटाबेस एडमिनिस्ट्रेटर (DBA) इस स्तर पर काम करते हैं।
  • लॉजिकल लेवल (Logical Level): यह एब्स्ट्रैक्शन का मध्यवर्ती स्तर है। यह बताता है कि डेटाबेस में कौन सा डेटा संग्रहीत है और उन डेटा के बीच क्या संबंध हैं। यह पूरे डेटाबेस की संरचना को सरल टेबल्स (रिलेशंस) के रूप में वर्णित करता है। एप्लिकेशन प्रोग्रामर और DBA इस स्तर पर काम करते हैं।
  • व्यू लेवल (View Level): यह एब्स्ट्रैक्शन का उच्चतम स्तर है। यह केवल डेटाबेस के एक हिस्से को वर्णित करता है जिसे एक विशेष उपयोगकर्ता देख सकता है। यह सुरक्षा उद्देश्यों के लिए और उपयोगकर्ता के लिए सिस्टम को सरल बनाने के लिए डेटा को छिपा सकता है। एक ही डेटाबेस के लिए कई अलग-अलग व्यू हो सकते हैं। एंड-यूज़र इस स्तर पर इंटरैक्ट करते हैं।

डेटाबेस मैनेजमेंट सिस्टम (DBMS) इन स्तरों के बीच मैपिंग प्रदान करके एब्स्ट्रैक्शन को संभव बनाता है, जिससे एक स्तर पर किए गए बदलावों से उच्च स्तर पर प्रभाव कम होता है।

(b) व्यू (View)

एक व्यू एक या एक से अधिक बेस टेबल्स पर आधारित एक वर्चुअल टेबल है। यह एक संग्रहीत SQL क्वेरी का परिणाम होता है। व्यू में भौतिक रूप से डेटा संग्रहीत नहीं होता है; जब भी व्यू को एक्सेस किया जाता है, तो DBMS संबंधित क्वेरी को चलाता है और परिणाम सेट उत्पन्न करता है। व्यू का उपयोग करने के लाभ:

  • सुरक्षा: उपयोगकर्ताओं को केवल उस डेटा तक पहुंच प्रदान करना जिसकी उन्हें आवश्यकता है।
  • सरलता: उपयोगकर्ताओं के लिए जटिल क्वेरी को सरल बनाना।
  • डेटा स्वतंत्रता: बेस टेबल्स की संरचना में बदलाव से एप्लिकेशन को बचाना।

इन्सर्ट, अपडेट या डिलीट करने में बाधाएं:

सभी व्यू अपडेट करने योग्य नहीं होते हैं। DML (INSERT, UPDATE, DELETE) ऑपरेशन करते समय निम्नलिखित बाधाएं आ सकती हैं:

  • एग्रीगेट फ़ंक्शंस: यदि व्यू में `SUM()`, `AVG()`, `COUNT()` जैसे एग्रीगेट फ़ंक्शंस का उपयोग किया गया है, तो उसे अपडेट नहीं किया जा सकता क्योंकि यह स्पष्ट नहीं है कि बेस टेबल के किस रो को बदलना है।
  • जॉइन्स (Joins): यदि व्यू एक से अधिक टेबल्स को जॉइन करके बनाया गया है, तो अपडेट या इन्सर्ट करना जटिल हो सकता है, खासकर यदि इसमें ऐसे कॉलम शामिल हैं जो कई टेबल्स में हैं।
  • GROUP BY क्लॉज: `GROUP BY` या `HAVING` क्लॉज वाले व्यू अपडेट करने योग्य नहीं होते हैं।
  • DISTINCT कीवर्ड: `DISTINCT` का उपयोग करने वाले व्यू को अपडेट नहीं किया जा सकता है।
  • NOT NULL बाधाएं: यदि आप एक व्यू के माध्यम से एक रो इन्सर्ट करने का प्रयास करते हैं और बेस टेबल में एक ऐसा कॉलम है जिसमें `NOT NULL` बाधा है और वह व्यू में शामिल नहीं है, तो इन्सर्ट विफल हो जाएगा।

(c) XYZ पब्लिशिंग हाउस E-R मॉडलिंग

(i) एंटिटीज और एट्रिब्यूट्स:

  • Author: { AuthorID , AuthorName, FieldOfStudy}
  • Book: { ISBN , Title, Subject, PublicationYear}
  • Editor: { EditorID , EditorName}
  • ShopOwner: { ShopID , ShopName, Location}
  • Supplier: { SupplierID , SupplierName, MaterialType}

(ii) संबंध (Relationships):

  • Writes: `Author` और `Book` के बीच (एक लेखक कई किताबें लिख सकता है, लेकिन एक किताब एक ही लेखक द्वारा लिखी जाती है – 1:N)।
  • Edits: `Editor` और `Book` के बीच (एक संपादक कई किताबों को संपादित कर सकता है – 1:N)।
  • Buys: `ShopOwner` और `Book` के बीच (एक दुकानदार कई किताबें खरीद सकता है, और एक किताब कई दुकानदारों द्वारा खरीदी जा सकती है – M:N)।
  • Supplies: `Supplier` और `PublishingHouse` के बीच (कई आपूर्तिकर्ता प्रकाशन गृह को सामग्री की आपूर्ति करते हैं)। इसे एक `Material` एंटिटी और `Supplier` के साथ M:N संबंध के रूप में भी मॉडल किया जा सकता है। सरलता के लिए, हम `Supplier` को एक एंटिटी मानेंगे जो सीधे हाउस से संबंधित है।

(iii) संभावित कीज (Keys):

  • Author: AuthorID (प्राइमरी की)
  • Book: ISBN (प्राइमरी की)
  • Editor: EditorID (प्राइमरी की)
  • ShopOwner: ShopID (प्राइमरी की)
  • Supplier: SupplierID (प्राइमरी की)
  • `Buys` (M:N संबंध) के लिए एक नई रिलेशन टेबल `Book_Purchase` की आवश्यकता होगी जिसमें { ShopID , ISBN , Quantity} जैसे एट्रिब्यूट्स होंगे, जहां {ShopID, ISBN} एक कंपोजिट प्राइमरी की होगी।

(iv) E-R डायग्राम का विवरण: E-R डायग्राम में, एंटिटीज (Author, Book, Editor, ShopOwner, Supplier) को रेक्टेंगल में दर्शाया जाएगा। उनके एट्रिब्यूट्स को ओवल में और प्राइमरी की को अंडरलाइन किया जाएगा। संबंधों (Writes, Edits, Buys) को डायमंड शेप में दर्शाया जाएगा।

  • `Author` (1) — — (N) `Book`
  • `Editor` (1) — — (N) `Book`
  • `ShopOwner` (M) — — (N) `Book` (यह एक जंक्शन टेबल में बदल जाएगा)

(v) वैकल्पिक और अनिवार्य संबंध (Optional and Mandatory Relationships): संबंधों में भागीदारी या तो अनिवार्य (mandatory) हो सकती है या वैकल्पिक (optional)।

  • अनिवार्य संबंध (Mandatory): इसे E-R डायग्राम में डबल लाइन से दर्शाया जाता है। इसका मतलब है कि एक एंटिटी सेट में प्रत्येक एंटिटी को संबंध में भाग लेना चाहिए । उदाहरण: `Book` और `Writes` संबंध में `Book` की भागीदारी अनिवार्य है। प्रत्येक पुस्तक का एक लेखक होना अनिवार्य है। एक किताब बिना लेखक के मौजूद नहीं हो सकती।
  • वैकल्पिक संबंध (Optional): इसे सिंगल लाइन से दर्शाया जाता है। इसका मतलब है कि एक एंटिटी सेट में एंटिटी के लिए संबंध में भाग लेना वैकल्पिक है। उदाहरण: `Author` और `Writes` संबंध में `Author` की भागीदारी वैकल्पिक हो सकती है। एक लेखक सिस्टम में मौजूद हो सकता है लेकिन उसने अभी तक कोई किताब नहीं लिखी है (या उसकी कोई किताब वर्तमान में प्रकाशित नहीं हुई है)। इसी तरह, एक संपादक को हर समय किसी पुस्तक के संपादन के लिए नियुक्त नहीं किया जा सकता है।

(e) नॉर्मलाइजेशन की आवश्यकता (Need of Normalization)

नॉर्मलाइजेशन डेटाबेस में डेटा रिडंडेंसी (redundancy) को कम करने और डेटा इंटीग्रिटी (integrity) में सुधार करने के लिए तालिकाओं (tables) और स्तंभों (columns) को व्यवस्थित करने की एक प्रक्रिया है। यह डेटाबेस को तथाकथित “असंगतियों” (anomalies) से बचाने के लिए आवश्यक है। मुख्य आवश्यकताएं हैं:

  1. डेटा रिडंडेंसी को कम करना: नॉर्मलाइजेशन यह सुनिश्चित करता है कि जानकारी केवल एक ही स्थान पर संग्रहीत हो। इससे स्टोरेज स्पेस की बचत होती है और डेटा को सुसंगत बनाए रखना आसान हो जाता है।
  2. इंसर्शन असंगति (Insertion Anomaly) से बचाव: यदि डेटा ठीक से नॉर्मलाइज्ड नहीं है, तो हो सकता है कि हम कुछ जानकारी तब तक दर्ज न कर पाएं जब तक कि कोई अन्य, असंबंधित जानकारी उपलब्ध न हो। उदाहरण के लिए, एक नॉन-नॉर्मलाइज्ड टेबल में, हम एक नए विभाग को तब तक नहीं जोड़ सकते जब तक कि उस विभाग में कम से कम एक कर्मचारी न हो।
  3. अपडेट असंगति (Update Anomaly) से बचाव: यदि एक ही जानकारी कई स्थानों पर संग्रहीत है, तो उसे अपडेट करने के लिए सभी स्थानों पर बदलाव करने की आवश्यकता होती है। यदि हम किसी एक स्थान पर अपडेट करना भूल जाते हैं, तो डेटाबेस असंगत हो जाएगा।
  4. डिलीशन असंगति (Deletion Anomaly) से बचाव: एक रो को हटाने से अनजाने में अन्य महत्वपूर्ण जानकारी भी हट सकती है। उदाहरण के लिए, यदि हम किसी कर्मचारी का रिकॉर्ड हटाते हैं, और वह उस विभाग का एकमात्र कर्मचारी है, तो हम उस विभाग के बारे में भी जानकारी खो सकते हैं।

नॉर्मलाइजेशन के विभिन्न स्तर होते हैं (1NF, 2NF, 3NF, BCNF, आदि), जो रिडंडेंसी और असंगतियों को उत्तरोत्तर कम करते हैं।

Q2. (a) निम्नलिखित तालिकाओं पर विचार करें: 8 MP (empno, ename, sal, job, mgr, hiredate, deptno, comm., birthdate). DEPT (deptno, dname, Loc) SALGRADE (grade, losal, hisal) निम्नलिखित के लिए SQL क्वेरी लिखें: (i) विभाग संख्या 0 के कर्मचारियों को दिया गया कुल वेतन प्रदर्शित करें। (ii) उन कर्मचारियों के नाम प्रदर्शित करें जिनके नाम में ‘a’ अक्षर है। (iii) विभाग 0 या 20 में काम करने वाले कर्मचारियों के कर्मचारी का नाम, उनके विभाग का नाम और वेतन ग्रेड प्रदर्शित करें। (iv) प्रत्येक विभाग में कर्मचारियों को दिया गया औसत वेतन प्रदर्शित करें। (b) SDLC और डेटाबेस लाइफ साइकिल में क्या अंतर है? 4 (c) डेटा स्वतंत्रता की अवधारणा की व्याख्या करें। 3

Ans.

(a) SQL क्वेरीज

(i) विभाग संख्या 0 के कर्मचारियों को दिया गया कुल वेतन प्रदर्शित करें।

SELECT SUM(sal) AS TotalSalary FROM MP WHERE deptno = 0;

व्याख्या: यह क्वेरी `MP` टेबल से उन सभी पंक्तियों का चयन करती है जहां `deptno` 0 है। फिर यह `SUM()` एग्रीगेट फ़ंक्शन का उपयोग करके उन चयनित पंक्तियों के `sal` कॉलम का योग करती है। (ii) उन कर्मचारियों के नाम प्रदर्शित करें जिनके नाम में ‘a’ अक्षर है।

SELECT ename FROM MP WHERE ename LIKE ‘%a%’;

व्याख्या: `LIKE` ऑपरेटर का उपयोग पैटर्न मैचिंग के लिए किया जाता है। `%` वाइल्डकार्ड किसी भी वर्णों के अनुक्रम (शून्य या अधिक) का प्रतिनिधित्व करता है। तो, `’%a%’` का अर्थ है कोई भी स्ट्रिंग जिसमें कहीं भी ‘a’ अक्षर हो। (iii) विभाग 0 या 20 में काम करने वाले कर्मचारियों के कर्मचारी का नाम, उनके विभाग का नाम और वेतन ग्रेड प्रदर्शित करें।

SELECT M.ename, D.dname, S.grade FROM MP M JOIN DEPT D ON M.deptno = D.deptno JOIN SALGRADE S ON M.sal BETWEEN S.losal AND S.hisal WHERE M.deptno IN (0, 20);

व्याख्या: इस क्वेरी में तीन तालिकाओं को जॉइन किया गया है:

  • `MP` और `DEPT` को `deptno` पर जॉइन किया गया है ताकि विभाग का नाम (`dname`) प्राप्त हो सके।
  • परिणाम को `SALGRADE` के साथ इस शर्त पर जॉइन किया गया है कि कर्मचारी का वेतन (`sal`) उस ग्रेड की निम्नतम (`losal`) और उच्चतम (`hisal`) सीमा के बीच हो।
  • `WHERE` क्लॉज परिणामों को केवल उन कर्मचारियों तक सीमित करता है जो विभाग 0 या 20 में हैं।

(iv) प्रत्येक विभाग में कर्मचारियों को दिया गया औसत वेतन प्रदर्शित करें।

SELECT deptno, AVG(sal) AS AverageSalary FROM MP GROUP BY deptno;

व्याख्या: `GROUP BY deptno` क्लॉज `MP` टेबल की पंक्तियों को उनके `deptno` के आधार पर समूहों में विभाजित करता है। फिर `AVG(sal)` फ़ंक्शन प्रत्येक समूह (प्रत्येक विभाग) के लिए औसत वेतन की गणना करता है।

(b) SDLC और डेटाबेस लाइफ साइकिल (DBLC) में अंतर

सिस्टम डेवलपमेंट लाइफ साइकिल (SDLC) और डेटाबेस लाइफ साइकिल (DBLC) दोनों एक सूचना प्रणाली को विकसित करने और बनाए रखने के लिए संरचित प्रक्रियाएं हैं, लेकिन उनके दायरे में अंतर है।

  • SDLC (System Development Life Cycle):
    • दायरा: SDLC का दायरा व्यापक है। यह पूरे सूचना प्रणाली के विकास को कवर करता है, जिसमें हार्डवेयर, सॉफ्टवेयर, नेटवर्क, डेटा, प्रक्रियाएं और लोग शामिल हैं।
    • चरण: इसके सामान्य चरण हैं – योजना (Planning), विश्लेषण (Analysis), डिजाइन (Design), कार्यान्वयन (Implementation), परीक्षण (Testing), परिनियोजन (Deployment), और रखरखाव (Maintenance)।
    • संबंध: DBLC, SDLC का एक हिस्सा है। SDLC के विश्लेषण, डिजाइन और कार्यान्वयन चरणों के दौरान DBLC होता है।
  • DBLC (Database Life Cycle):
    • दायरा: DBLC का दायरा संकीर्ण और विशिष्ट है। यह केवल सिस्टम के डेटाबेस घटक पर केंद्रित है।
    • चरण: इसके विशिष्ट चरण हैं – डेटाबेस प्रारंभिक अध्ययन (Database Initial Study), डेटाबेस डिजाइन (Database Design – जिसमें वैचारिक, तार्किक और भौतिक डिजाइन शामिल हैं), कार्यान्वयन और लोडिंग (Implementation and Loading), परीक्षण और मूल्यांकन (Testing and Evaluation), संचालन (Operation), और रखरखाव और विकास (Maintenance and Evolution)।
    • उद्देश्य: इसका मुख्य उद्देश्य एक कुशल, विश्वसनीय और सुरक्षित डेटाबेस डिजाइन और कार्यान्वित करना है जो सिस्टम की डेटा आवश्यकताओं को पूरा करता है।

संक्षेप में, SDLC पूरे घर के निर्माण की योजना बनाने जैसा है, जबकि DBLC उस घर के लिए प्लंबिंग सिस्टम को डिजाइन और स्थापित करने पर ध्यान केंद्रित करने जैसा है।

(c) डेटा स्वतंत्रता (Data Independence)

डेटा स्वतंत्रता एक डेटाबेस सिस्टम की वह क्षमता है जिसमें एप्लिकेशन प्रोग्राम और उपयोगकर्ताओं को प्रभावित किए बिना एक स्तर पर स्कीमा को संशोधित किया जा सकता है। यह डेटा एब्स्ट्रैक्शन का एक प्रमुख लाभ है। डेटा स्वतंत्रता दो प्रकार की होती है:

  1. फिजिकल डेटा स्वतंत्रता (Physical Data Independence):
    • यह लॉजिकल या वैचारिक स्कीमा को बदले बिना फिजिकल स्कीमा को बदलने की क्षमता है।
    • फिजिकल स्तर पर किए गए बदलावों (जैसे स्टोरेज डिवाइस बदलना, फ़ाइल संगठन तकनीक बदलना, या इंडेक्स बनाना/हटाना) से एप्लिकेशन प्रोग्राम प्रभावित नहीं होने चाहिए।
    • उदाहरण: यदि हम प्रदर्शन को बेहतर बनाने के लिए किसी टेबल पर एक नया इंडेक्स जोड़ते हैं, तो हमें उन एप्लिकेशन को बदलने की आवश्यकता नहीं है जो उस टेबल का उपयोग करते हैं।
  2. लॉजिकल डेटा स्वतंत्रता (Logical Data Independence):
    • यह एक्सटर्नल स्कीमा (उपयोगकर्ता व्यू) को बदले बिना लॉजिकल (वैचारिक) स्कीमा को बदलने की क्षमता है।
    • लॉजिकल स्तर पर किए गए बदलावों (जैसे टेबल में एक नया कॉलम जोड़ना या दो टेबलों को एक में मिलाना) से मौजूदा एप्लिकेशन प्रोग्राम प्रभावित नहीं होने चाहिए, जब तक कि वे सीधे उस डेटा का उपयोग न करें जिसे बदला गया है।
    • यह हासिल करना फिजिकल डेटा स्वतंत्रता से अधिक कठिन है।
    • उदाहरण: यदि हम `MP` टेबल में एक नया कॉलम `email_address` जोड़ते हैं, तो मौजूदा क्वेरीज जो इस कॉलम का उपयोग नहीं करती हैं, वे पहले की तरह काम करती रहेंगी।

Q3. (a) एक उदाहरण की सहायता से किसी भी संबंध पर परिभाषित किए जा सकने वाले TABLE बाधाओं (constraints) की व्याख्या करें। 10 (b) SQL में उपयोग किए जाने वाले किन्हीं पांच डेटा प्रकारों की व्याख्या करें। 5

Ans.

(a) टेबल बाधाएं (Table Constraints)

SQL में बाधाएं वे नियम हैं जो एक टेबल के कॉलम में डेटा पर लागू होते हैं। ये नियम डेटा की सटीकता और विश्वसनीयता सुनिश्चित करने के लिए उपयोग किए जाते हैं। यदि बाधा का उल्लंघन करने वाला कोई भी डेटा ऑपरेशन होता है, तो वह ऑपरेशन रद्द हो जाता है। बाधाएं कॉलम स्तर या टेबल स्तर पर परिभाषित की जा सकती हैं।

प्रमुख टेबल बाधाएं निम्नलिखित हैं:

  1. NOT NULL: यह सुनिश्चित करता है कि एक कॉलम में NULL मान नहीं हो सकता है। यानी, हर रिकॉर्ड के लिए उस कॉलम में एक मान होना चाहिए।
  2. UNIQUE: यह सुनिश्चित करता है कि एक कॉलम (या कॉलम का समूह) में सभी मान अद्वितीय हों। एक टेबल में कई `UNIQUE` बाधाएं हो सकती हैं, और यह NULL मानों की अनुमति देता है (आमतौर पर एक)।
  3. PRIMARY KEY: यह `NOT NULL` और `UNIQUE` बाधाओं का एक संयोजन है। यह टेबल में प्रत्येक रिकॉर्ड को विशिष्ट रूप से पहचानता है। एक टेबल में केवल एक `PRIMARY KEY` हो सकती है।
  4. FOREIGN KEY: यह एक टेबल में एक कॉलम (या कॉलम का समूह) है जो दूसरी टेबल की `PRIMARY KEY` को संदर्भित करता है। यह दो टेबलों के बीच एक लिंक है और इसका उपयोग रेफरेंशियल इंटीग्रिटी बनाए रखने के लिए किया जाता है। यह सुनिश्चित करता है कि फॉरेन की कॉलम में मान या तो संदर्भित प्राइमरी की कॉलम में मौजूद हो या `NULL` हो।
  5. CHECK: यह सुनिश्चित करता है कि एक कॉलम में सभी मान एक विशिष्ट शर्त को पूरा करते हैं। उदाहरण के लिए, यह सुनिश्चित करना कि ‘Age’ कॉलम में मान 18 से अधिक हो।
  6. DEFAULT: यह एक कॉलम के लिए एक डिफ़ॉल्ट मान निर्दिष्ट करता है जब कोई मान निर्दिष्ट नहीं किया जाता है। यह तकनीकी रूप से एक बाधा नहीं है, लेकिन अक्सर उनके साथ उपयोग किया जाता है।

उदाहरण:

आइए एक `Students` टेबल और एक `Courses` टेबल बनाते हैं जो इन बाधाओं का उपयोग करते हैं। CREATE TABLE Courses ( CourseID INT PRIMARY KEY, CourseName VARCHAR(100) NOT NULL, Credits INT CHECK (Credits > 0) ); CREATE TABLE Students ( StudentID INT PRIMARY KEY, FirstName VARCHAR(50) NOT NULL, LastName VARCHAR(50) NOT NULL, Email VARCHAR(100) UNIQUE, EnrollmentDate DATE, Age INT CHECK (Age >= 18), EnrolledCourseID INT, FOREIGN KEY (EnrolledCourseID) REFERENCES Courses(CourseID) ); इस उदाहरण में:

  • `Students` टेबल में, `StudentID` एक PRIMARY KEY है, जो प्रत्येक छात्र को विशिष्ट रूप से पहचानती है।
  • `FirstName` और `LastName` NOT NULL हैं, जिसका अर्थ है कि प्रत्येक छात्र का पहला और अंतिम नाम होना चाहिए।
  • `Email` UNIQUE है, यह सुनिश्चित करता है कि दो छात्रों का एक ही ईमेल पता न हो।
  • `Age` पर एक CHECK बाधा है, जो सुनिश्चित करती है कि केवल 18 वर्ष या उससे अधिक आयु के छात्र ही नामांकित हों।
  • `EnrolledCourseID` एक FOREIGN KEY है जो `Courses` टेबल के `CourseID` को संदर्भित करता है। यह सुनिश्चित करता है कि एक छात्र केवल एक ऐसे कोर्स में नामांकित हो सकता है जो `Courses` टेबल में मौजूद है।

(b) SQL डेटा प्रकार (SQL Data Types)

SQL में, प्रत्येक कॉलम के लिए एक डेटा प्रकार निर्दिष्ट करना आवश्यक होता है। यह DBMS को बताता है कि उस कॉलम में किस प्रकार का डेटा संग्रहीत किया जाएगा। यहां पांच सामान्य SQL डेटा प्रकार दिए गए हैं:

  1. INT या INTEGER:
    • विवरण: यह डेटा प्रकार पूर्णांक संख्याओं (बिना दशमलव के पूर्ण संख्याएं) को संग्रहीत करने के लिए उपयोग किया जाता है। इसका आकार DBMS पर निर्भर करता है, लेकिन यह आमतौर पर -2,147,483,648 से 2,147,483,647 तक की संख्याओं को संग्रहीत कर सकता है।
    • उदाहरण: `StudentID INT`, `Age INT`
  2. VARCHAR(n) या VARCHAR2(n):
    • विवरण: यह वेरिएबल-लेंथ कैरेक्टर स्ट्रिंग्स को संग्रहीत करने के लिए उपयोग किया जाता है। `n` स्ट्रिंग की अधिकतम लंबाई को निर्दिष्ट करता है। यह केवल उपयोग किए गए स्थान को संग्रहीत करता है, जिससे यह स्टोरेज के लिए कुशल होता है।
    • उदाहरण: `FirstName VARCHAR(50)` 50 अक्षरों तक के नामों को संग्रहीत करेगा।
  3. CHAR(n):
    • विवरण: यह फिक्स्ड-लेंथ कैरेक्टर स्ट्रिंग्स को संग्रहीत करने के लिए उपयोग किया जाता है। यदि संग्रहीत स्ट्रिंग `n` से छोटी है, तो इसे दाईं ओर रिक्त स्थान से भर दिया जाता है। यह उन डेटा के लिए उपयोगी है जिनकी लंबाई हमेशा समान होती है, जैसे देश कोड (‘US’, ‘IN’)।
    • उदाहरण: `StateCode CHAR(2)`
  4. DATE:
    • विवरण: यह डेटा प्रकार दिनांक मान (वर्ष, महीना और दिन) संग्रहीत करने के लिए उपयोग किया जाता है। DBMS के आधार पर प्रारूप भिन्न हो सकता है (जैसे ‘YYYY-MM-DD’)। कुछ सिस्टम समय की जानकारी भी संग्रहीत करते हैं।
    • उदाहरण: `birthdate DATE`
  5. FLOAT(p) या NUMBER(p,s):
    • विवरण: ये डेटा प्रकार दशमलव या फ्लोटिंग-पॉइंट संख्याओं को संग्रहीत करने के लिए उपयोग किए जाते हैं। `FLOAT` अनुमानित-मान संख्यात्मक प्रकार है, जबकि `NUMBER` (Oracle में) या `DECIMAL` (SQL Server, MySQL में) सटीक-मान संख्यात्मक प्रकार है। `p` कुल अंकों (परिशुद्धता) को संदर्भित करता है और `s` दशमलव बिंदु के बाद के अंकों (स्केल) को।
    • उदाहरण: `Salary DECIMAL(10, 2)` 2 दशमलव स्थानों के साथ कुल 10 अंकों तक का वेतन संग्रहीत कर सकता है। `pi FLOAT`

Q4. (a) निम्नलिखित निर्भरता आरेख पर विचार करें: 6 SSN -> Ename Proj_number -> pname, plocation {SSN, Proj_number} -> Hours (i) आरेख में दिखाए गए कार्यात्मक निर्भरताओं के प्रकारों की सूची बनाएं। (ii) 3NF तक नॉर्मलाइज करें। (b) उदाहरणों के साथ ALTER कमांड की व्याख्या करें। 4 (c) रिलेशनल मॉडल के पदानुक्रमित या नेटवर्क डेटा मॉडल पर लाभों की व्याख्या करें। 5

Ans.

(a) निर्भरता आरेख और नॉर्मलाइजेशन

दिए गए निर्भरता आरेख के आधार पर, हम मान सकते हैं कि हमारे पास एक रिलेशन `R(SSN, Ename, Proj_number, pname, plocation, Hours)` है। कंपोजिट की `{SSN, Proj_number}` पूरे रिलेशन को विशिष्ट रूप से पहचानती है, इसलिए यह प्राइमरी की है।

(i) कार्यात्मक निर्भरताओं के प्रकार:

  1. पूर्ण कार्यात्मक निर्भरता (Full Functional Dependency):
    • `{SSN, Proj_number} -> Hours`: `Hours` एट्रिब्यूट कंपोजिट प्राइमरी की `{SSN, Proj_number}` पर पूरी तरह से निर्भर है। यह प्राइमरी की के किसी भी हिस्से (न तो अकेले `SSN` पर और न ही अकेले `Proj_number` पर) पर निर्भर नहीं है।
  2. आंशिक कार्यात्मक निर्भरता (Partial Functional Dependency):
    • `SSN -> Ename`: `Ename` एट्रिब्यूट कंपोजिट प्राइमरी की के एक हिस्से (`SSN`) पर निर्भर है, न कि पूरी की पर। यह 2NF का उल्लंघन है।
    • `Proj_number -> pname, plocation`: `pname` और `plocation` एट्रिब्यूट्स कंपोजिट प्राइमरी की के दूसरे हिस्से (`Proj_number`) पर निर्भर हैं, न कि पूरी की पर। यह भी 2NF का उल्लंघन है।
  3. संक्रमणीय निर्भरता (Transitive Dependency):
    • दिए गए निर्भरताओं में, कोई संक्रमणीय निर्भरता नहीं है। संक्रमणीय निर्भरता तब होती है जब एक नॉन-प्राइम एट्रिब्यूट दूसरे नॉन-प्राइम एट्रिब्यूट पर निर्भर करता है। यहां, निर्भरताएं केवल प्राइमरी की (या उसके हिस्से) पर हैं।

(ii) 3NF तक नॉर्मलाइजेशन: हम नॉर्मलाइजेशन प्रक्रिया के माध्यम से आगे बढ़ेंगे। मूल रिलेशन (1NF में): `EMP_PROJ( SSN , Ename, Proj_number , pname, plocation, Hours)` (प्राइमरी की: {SSN, Proj_number}) 2NF में बदलना (आंशिक निर्भरताओं को हटाना): 2NF प्राप्त करने के लिए, हमें आंशिक निर्भरताओं को हटाना होगा। हम मूल रिलेशन को छोटी रिलेशंस में विघटित करते हैं, प्रत्येक अपने निर्धारक (determinant) के साथ।

  • `SSN -> Ename` निर्भरता के लिए, हम एक नई टेबल `EMPLOYEE` बनाते हैं। EMPLOYEE( SSN , Ename)
  • `Proj_number -> pname, plocation` निर्भरता के लिए, हम एक नई टेबल `PROJECT` बनाते हैं। PROJECT( Proj_number , pname, plocation)
  • शेष एट्रिब्यूट, जो पूरी की पर निर्भर है, मूल टेबल के एक संशोधित संस्करण में रहता है। WORK_ON( SSN , Proj_number , Hours)

अब हमारे पास तीन टेबल्स हैं जो 2NF में हैं: `EMPLOYEE`, `PROJECT`, और `WORK_ON`। 3NF में बदलना (संक्रमणीय निर्भरताओं को हटाना): 3NF की आवश्यकता है कि रिलेशन 2NF में हो और कोई संक्रमणीय निर्भरता न हो।

  • EMPLOYEE( SSN , Ename): इसमें कोई संक्रमणीय निर्भरता नहीं है क्योंकि केवल एक नॉन-प्राइम एट्रिब्यूट है। यह 3NF में है।
  • PROJECT( Proj_number , pname, plocation): इसमें कोई संक्रमणीय निर्भरता नहीं है। `pname` और `plocation` सीधे `Proj_number` पर निर्भर करते हैं। यह 3NF में है।
  • WORK_ON( SSN , Proj_number , Hours): इसमें कोई नॉन-प्राइम एट्रिब्यूट ही नहीं हैं, इसलिए कोई संक्रमणीय निर्भरता नहीं हो सकती। यह 3NF में है।

इस प्रकार, 3NF में विघटन के परिणामस्वरूप तीन टेबल्स हैं: `EMPLOYEE`, `PROJECT`, और `WORK_ON`।

(b) ALTER कमांड

SQL में `ALTER` कमांड एक डेटाबेस ऑब्जेक्ट, जैसे कि टेबल, की संरचना को संशोधित करने के लिए उपयोग किया जाता है। `ALTER TABLE` स्टेटमेंट का उपयोग किसी मौजूदा टेबल में कॉलम जोड़ने, हटाने, या संशोधित करने, या बाधाओं को जोड़ने या हटाने के लिए किया जाता है। उदाहरण: मान लीजिए हमारे पास एक टेबल `Students` है: `CREATE TABLE Students (ID INT, Name VARCHAR(50));`

  1. एक नया कॉलम जोड़ना (ADD): टेबल में एक नया कॉलम ‘Email’ जोड़ने के लिए: 
    ALTER TABLE Students ADD Email VARCHAR(100);
  2. एक कॉलम को हटाना (DROP COLUMN): यदि हम ‘Email’ कॉलम को हटाना चाहते हैं: 
    ALTER TABLE Students DROP COLUMN Email;
  3. एक कॉलम को संशोधित करना (MODIFY/ALTER COLUMN): ‘Name’ कॉलम के डेटा प्रकार को `VARCHAR(50)` से `VARCHAR(100)` में बदलने के लिए: (सिंटेक्स DBMS के अनुसार भिन्न हो सकता है) 
    -- MySQL / OracleALTER TABLE Students MODIFY Name VARCHAR(100);
    -- SQL ServerALTER TABLE Students ALTER COLUMN Name VARCHAR(100);
  4. एक बाधा जोड़ना (ADD CONSTRAINT): ‘ID’ कॉलम को प्राइमरी की बनाने के लिए: 
    ALTER TABLE Students ADD CONSTRAINT PK_StudentID PRIMARY KEY (ID);

`ALTER` कमांड शक्तिशाली है क्योंकि यह डेटा को खोए बिना टेबल संरचना को बदलने की अनुमति देता है (हालांकि कुछ संशोधनों में जोखिम हो सकते हैं)।

(c) रिलेशनल मॉडल बनाम पदानुक्रमित/नेटवर्क मॉडल

रिलेशनल डेटा मॉडल (1970 में E.F. Codd द्वारा प्रस्तावित) ने पदानुक्रमित (hierarchical) और नेटवर्क मॉडल पर कई महत्वपूर्ण लाभ प्रदान किए, जो उस समय प्रमुख थे।

  1. सरलता (Simplicity):
    • रिलेशनल: डेटा को टेबल्स (रिलेशंस) के सरल और सहज ज्ञान युक्त प्रारूप में प्रस्तुत किया जाता है, जिसे समझना और उपयोग करना आसान है।
    • पदानुक्रमित/नेटवर्क: ये मॉडल पॉइंटर्स और लिंक पर आधारित जटिल ट्री या ग्राफ संरचनाओं का उपयोग करते हैं, जिन्हें नेविगेट करना और समझना मुश्किल होता है।
  2. लचीलापन और शक्तिशाली क्वेरी क्षमता (Flexibility and Powerful Query Capability):
    • रिलेशनल: SQL (Structured Query Language) जैसी उच्च-स्तरीय, घोषणात्मक भाषाएं प्रदान करता है। उपयोगकर्ता को क्या डेटा चाहिए यह निर्दिष्ट करना होता है, न कि कैसे इसे प्राप्त करना है। यह एड-हॉक क्वेरीज (ad-hoc queries) के लिए बहुत लचीला है।
    • पदानुक्रमित/नेटवर्क: डेटा एक्सेस प्रक्रियात्मक (procedural) और रिकॉर्ड-एट-ए-टाइम होता है। प्रोग्रामर को पॉइंटर्स का पालन करके डेटा संरचनाओं के माध्यम से मैन्युअल रूप से नेविगेट करना पड़ता है, जो जटिल और थकाऊ है।
  3. डेटा स्वतंत्रता (Data Independence):
    • रिलेशनल: यह फिजिकल और लॉजिकल डेटा स्वतंत्रता दोनों का एक उच्च स्तर प्रदान करता है। एप्लिकेशन प्रोग्राम स्टोरेज संरचना या डेटाबेस स्कीमा में कुछ बदलावों से अछूते रहते हैं।
    • पदानुक्रमित/नेटवर्क: डेटा एक्सेस पथ एप्लिकेशन लॉजिक में अंतर्निहित होते हैं, इसलिए डेटा संरचना में किसी भी बदलाव के लिए एप्लिकेशन प्रोग्राम में महत्वपूर्ण संशोधन की आवश्यकता होती है।
  4. कम डेटा रिडंडेंसी (Reduced Data Redundancy):
    • रिलेशनल: नॉर्मलाइजेशन की प्रक्रिया के माध्यम से, रिलेशनल मॉडल डेटा रिडंडेंसी को व्यवस्थित रूप से कम करता है, जिससे डेटा इंटीग्रिटी में सुधार होता है और विसंगतियों से बचा जाता है।
    • पदानुक्रमित/नेटवर्क: ये मॉडल स्वाभाविक रूप से रिडंडेंसी की ओर ले जाते हैं, खासकर जब M:N संबंधों का प्रतिनिधित्व करते हैं, जिससे डेटा असंगतता की समस्याएं हो सकती हैं।
  5. ठोस सैद्धांतिक आधार (Solid Theoretical Foundation):
    • रिलेशनल: यह मॉडल गणित (सेट थ्योरी और प्रेडिकेट लॉजिक) पर आधारित है, जो इसे एक मजबूत सैद्धांतिक आधार प्रदान करता है और डेटाबेस डिजाइन और क्वेरी ऑप्टिमाइज़ेशन में स्थिरता और पूर्वानुमान की अनुमति देता है।

Q5. निम्नलिखित की उदाहरण/आरेख सहित व्याख्या करें: 5×5=25 (a) दोषरहित जॉइन (Lossless join) (b) आउटर जॉइन (Outer join) (c) व्युत्पन्न एट्रिब्यूट (Derived attribute) (d) एग्रीगेट फ़ंक्शंस (Aggregate functions) (e) GROUP BY क्लॉज

Ans.

(a) दोषरहित जॉइन (Lossless Join)

एक डीकंपोजिशन (decomposition) या विघटन को दोषरहित जॉइन (lossless join) या हानि रहित जॉइन कहा जाता है यदि मूल रिलेशन को विघटित रिलेशंस के नेचुरल जॉइन (natural join) के माध्यम से बिना किसी अतिरिक्त या नकली टपल्स (spurious tuples) के निर्माण के पुनर्प्राप्त किया जा सके। यह सुनिश्चित करना नॉर्मलाइजेशन में एक महत्वपूर्ण आवश्यकता है कि विघटन के दौरान कोई जानकारी खो न जाए।

एक रिलेशन `R` का दो रिलेशंस `R1` और `R2` में विघटन दोषरहित होता है यदि और केवल यदि निम्नलिखित दो शर्तें पूरी होती हैं:

  1. `R1` और `R2` के एट्रिब्यूट्स का यूनियन `R` के सभी एट्रिब्यूट्स के बराबर हो।
  2. `R1` और `R2` के एट्रिब्यूट्स का इंटरसेक्शन (common attributes) `R1` या `R2` के लिए एक सुपरकी (superkey) हो।

उदाहरण: मान लीजिए हमारे पास एक रिलेशन `R(A, B, C)` है और कार्यात्मक निर्भरता `B -> C` है। मूल रिलेशन: R | A | B | C | |—|—|—| | a1| b1| c1| | a1| b2| c2| | a2| b1| c1| हम इसे `R1(A, B)` और `R2(B, C)` में विघटित करते हैं। R1(A, B) | A | B | |—|—| | a1| b1| | a1| b2| | a2| b1| R2(B, C) | B | C | |—|—| | b1| c1| | b2| c2| अब, यदि हम `R1` और `R2` का नेचुरल जॉइन करते हैं (कॉमन एट्रिब्यूट `B` पर), तो हमें मूल रिलेशन `R` वापस मिल जाता है। इसलिए, यह एक दोषरहित जॉइन विघटन है।

(b) आउटर जॉइन (Outer Join)

एक आउटर जॉइन एक प्रकार का जॉइन है जो इनर जॉइन की तरह मैचिंग पंक्तियों को तो लौटाता ही है, साथ ही उस टेबल से भी पंक्तियाँ लौटाता है जिसमें दूसरी टेबल में कोई मैचिंग पंक्ति नहीं होती है। यह उन पंक्तियों को शामिल करके किया जाता है, जहां मैचिंग कॉलम के लिए `NULL` मानों का उपयोग किया जाता है। आउटर जॉइन तीन प्रकार के होते हैं:

  • LEFT OUTER JOIN (या LEFT JOIN): बाईं टेबल से सभी पंक्तियाँ और दाईं टेबल से केवल मैचिंग पंक्तियाँ लौटाता है। यदि दाईं टेबल में कोई मैच न हो, तो परिणाम में दाईं टेबल के कॉलम के लिए `NULL` होता है।
  • RIGHT OUTER JOIN (या RIGHT JOIN): दाईं टेबल से सभी पंक्तियाँ और बाईं टेबल से केवल मैचिंग पंक्तियाँ लौटाता है। यदि बाईं टेबल में कोई मैच न हो, तो परिणाम में बाईं टेबल के कॉलम के लिए `NULL` होता है।
  • FULL OUTER JOIN: जब किसी भी टेबल में मैच न हो, तो सभी पंक्तियाँ लौटाता है। यह अनिवार्य रूप से एक लेफ्ट और एक राइट आउटर जॉइन का संयोजन है।

उदाहरण: मान लीजिए हमारे पास दो टेबल्स हैं: `Customers` और `Orders`। Customers | CustID | Name | |——–|——-| | 1 | John | | 2 | Jane | | 3 | Mike | Orders | OrderID | CustID | Amount | |———|——–|——–| | 101 | 1 | 200 | | 102 | 3 | 150 | | 103 | 4 | 300 | `SELECT C.Name, O.OrderID FROM Customers C LEFT JOIN Orders O ON C.CustID = O.CustID;` का परिणाम होगा: | Name | OrderID | |——-|———| | John | 101 | | Jane | NULL | <– Jane का कोई ऑर्डर नहीं है, लेकिन वह परिणाम में है। | Mike | 102 |

(c) व्युत्पन्न एट्रिब्यूट (Derived Attribute)

एक व्युत्पन्न एट्रिब्यूट एक ऐसा एट्रिब्यूट है जिसका मान किसी अन्य एट्रिब्यूट या एट्रिब्यूट्स के सेट से गणना या व्युत्पन्न किया जा सकता है। इन एट्रिब्यूट्स को आमतौर पर डेटाबेस में भौतिक रूप से संग्रहीत नहीं किया जाता है ताकि रिडंडेंसी से बचा जा सके और डेटा को सुसंगत बनाए रखा जा सके। जब भी उनकी आवश्यकता होती है, उनकी गणना की जाती है। E-R डायग्राम में, एक व्युत्पन्न एट्रिब्यूट को एक बिंदुदार (dotted) ओवल द्वारा दर्शाया जाता है। उदाहरण: एक `Employee` एंटिटी में, `DateOfBirth` एक संग्रहीत (stored) एट्रिब्यूट हो सकता है। इस `DateOfBirth` से, हम कर्मचारी की `Age` की गणना कर सकते हैं।

  • संग्रहीत एट्रिब्यूट: `DateOfBirth`
  • व्युत्पन्न एट्रिब्यूट: `Age`

`Age` को संग्रहीत करने की आवश्यकता नहीं है क्योंकि यह हर दिन बदलता है और `DateOfBirth` और वर्तमान तिथि से हमेशा गणना की जा सकती है। इसे संग्रहीत करने से डेटा असंगत हो सकता है यदि इसे नियमित रूप से अपडेट नहीं किया जाता है। E-R डायग्राम निरूपण: (Employee)—-[DateOfBirth] | |—-( Age ) <– बिंदुदार ओवल में

(d) एग्रीगेट फ़ंक्शंस (Aggregate Functions)

SQL में एग्रीगेट फ़ंक्शंस वे फ़ंक्शंस हैं जो मानों के एक सेट (एक कॉलम) पर एक ऑपरेशन करते हैं और एक एकल मान लौटाते हैं। ये फ़ंक्शंस अक्सर `GROUP BY` क्लॉज के साथ डेटा के सबसेट पर सारांश जानकारी की गणना करने के लिए उपयोग किए जाते हैं। पांच मुख्य SQL एग्रीगेट फ़ंक्शंस हैं:

  • COUNT(): यह उन पंक्तियों की संख्या लौटाता है जो एक मानदंड से मेल खाती हैं। `COUNT(*)` सभी पंक्तियों को गिनता है, जबकि `COUNT(column_name)` उस कॉलम में गैर-NULL मानों को गिनता है।
  • SUM(): यह एक संख्यात्मक कॉलम में सभी मानों का योग लौटाता है।
  • AVG(): यह एक संख्यात्मक कॉलम में मानों का औसत लौटाता है।
  • MIN(): यह एक कॉलम से न्यूनतम मान लौटाता है।
  • MAX(): यह एक कॉलम से अधिकतम मान लौटाता है।

उदाहरण: `MP` टेबल का उपयोग करके:

  • `SELECT COUNT(*) FROM MP;` — कर्मचारियों की कुल संख्या लौटाता है।
  • `SELECT SUM(sal) FROM MP WHERE deptno = 10;` — विभाग 10 के लिए कुल वेतन लौटाता है।
  • `SELECT AVG(sal) FROM MP;` — सभी कर्मचारियों का औसत वेतन लौटाता है।
  • `SELECT MIN(hiredate) FROM MP;` — सबसे पहले नियुक्त किए गए कर्मचारी की नियुक्ति तिथि लौटाता है।
  • `SELECT MAX(sal) FROM MP;` — उच्चतम वेतन लौटाता है।

(e) GROUP BY क्लॉज

SQL में `GROUP BY` क्लॉज का उपयोग `SELECT` स्टेटमेंट के साथ उन पंक्तियों को समूहित करने के लिए किया जाता है जिनमें निर्दिष्ट कॉलम (या कॉलम) में समान मान होते हैं। यह प्रत्येक समूह के लिए एक सारांश पंक्ति लौटाता है। `GROUP BY` का उपयोग लगभग हमेशा एग्रीगेट फ़ंक्शंस (`COUNT`, `MAX`, `MIN`, `SUM`, `AVG`) के साथ किया जाता है ताकि प्रत्येक समूह पर एक ऑपरेशन किया जा सके। `SELECT` स्टेटमेंट में, `GROUP BY` क्लॉज `WHERE` क्लॉज के बाद और `ORDER BY` क्लॉज से पहले आता है। सिंटेक्स:

SELECT column_name1, aggregate_function(column_name2) FROM table_name WHERE condition GROUP BY column_name1; उदाहरण: मान लीजिए हम प्रत्येक विभाग में कर्मचारियों की संख्या और उनके औसत वेतन का पता लगाना चाहते हैं। SELECT deptno, COUNT(*) AS NumberOfEmployees, AVG(sal) AS AverageSalary FROM MP GROUP BY deptno ORDER BY deptno; यह क्वेरी:

  1. `MP` टेबल से पंक्तियाँ लेती है।
  2. उन्हें `deptno` द्वारा समूहों में विभाजित करती है (जैसे, सभी विभाग 10 के कर्मचारी एक समूह में, सभी विभाग 20 के दूसरे समूह में, आदि)।
  3. प्रत्येक समूह के लिए, यह `COUNT(*)` का उपयोग करके कर्मचारियों की संख्या और `AVG(sal)` का उपयोग करके औसत वेतन की गणना करती है।
  4. परिणाम में प्रत्येक विभाग के लिए एक पंक्ति होती है, जिसमें विभाग संख्या, कर्मचारियों की संख्या और औसत वेतन दिखाया जाता है।

IGNOU BCS-092 Previous Year Solved Question Paper in English

Q1. (a) What is Data Abstraction ? How can it be achieved using databases ? 5 (b) What is a view ? What are the constraints when you try to insert update or delete data using views ? 5 (c) XYZ Publishing House prints books on various subjects. Authors of books expertise in only one field of study. The company has book editors who are responsible for book editing. Shop owners can buy multiple books from the company. The publishing house purchases publishing material from several suppliers. (i) List all entities and attributes. 2 (ii) Identify relationships. 2 (iii) Find possible keys in relations. 3 (iv) Make E-R diagram. 3 (v) Explain optional and mandatory relationships with examples. 5 (e) Explain the need of normalization. 5

Ans. (a) Data Abstraction Data Abstraction is the process of hiding the complex internal details of data storage and maintenance from the users. The primary goal is to provide users with a simplified interface to interact with the system, without having to worry about how the data is physically stored and managed. In databases, data abstraction is achieved through three levels:

  • Physical Level: This is the lowest level of abstraction. It describes how the data is actually stored on storage devices, in terms of files, records, and data structures. Database Administrators (DBAs) work at this level.
  • Logical Level: This is the intermediate level of abstraction. It describes what data is stored in the database and what relationships exist among that data. It describes the entire database structure in terms of simple tables (relations). Application programmers and DBAs work at this level.
  • View Level: This is the highest level of abstraction. It describes only a part of the database that a particular user is interested in. It can hide data for security purposes and to simplify the system for the user. Multiple different views can exist for the same database. End-users interact at this level.

The Database Management System (DBMS) makes abstraction possible by providing mappings between these levels, thus reducing the impact of changes made at one level on the higher levels.

(b) View A view is a virtual table based on the result-set of a stored SQL query. A view does not physically store data; whenever the view is accessed, the DBMS executes the underlying query and generates the result set on the fly.

Benefits of using views:

  • Security: Granting users access to only the data they need to see.
  • Simplicity: Simplifying complex queries for users.
  • Data Independence: Shielding applications from changes in the structure of base tables.


Constraints on Inserting, Updating, or Deleting:

Not all views are updatable. The following constraints may apply when performing DML (INSERT, UPDATE, DELETE) operations:

  • Aggregate Functions: If the view uses aggregate functions like `SUM()`, `AVG()`, `COUNT()`, it cannot be updated because it’s ambiguous which row in the base table should be modified.
  • Joins: If the view is created by joining more than one table, updating or inserting can be complex or impossible, especially if it involves columns that are in multiple tables.
  • GROUP BY Clause: Views with `GROUP BY` or `HAVING` clauses are not updatable.
  • DISTINCT Keyword: Views that use `DISTINCT` cannot be updated.
  • NOT NULL Constraints: If you try to insert a row through a view and a column in the base table has a `NOT NULL` constraint and is not included in the view, the insert will fail.

(c) XYZ Publishing House E-R Modeling (i) Entities and Attributes:

  • Author: { AuthorID , AuthorName, FieldOfStudy}
  • Book: { ISBN , Title, Subject, PublicationYear}
  • Editor: { EditorID , EditorName}
  • ShopOwner: { ShopID , ShopName, Location}
  • Supplier: { SupplierID , SupplierName, MaterialType}

(ii) Relationships:

  • Writes: Between `Author` and `Book` (An author writes many books, but a book is written by one author – 1:N).
  • Edits: Between `Editor` and `Book` (An editor can edit multiple books – 1:N).
  • Buys: Between `ShopOwner` and `Book` (A shop owner can buy multiple books, and a book can be bought by multiple shop owners – M:N).
  • Supplies: Between `Supplier` and the `PublishingHouse` (Many suppliers supply material to the publishing house). This could also be modeled as an M:N relationship with a `Material` entity. For simplicity, we consider `Supplier` as an entity related to the house.

(iii) Possible Keys:

  • Author: AuthorID (Primary Key)
  • Book: ISBN (Primary Key)
  • Editor: EditorID (Primary Key)
  • ShopOwner: ShopID (Primary Key)
  • Supplier: SupplierID (Primary Key)
  • For the M:N `Buys` relationship, a new relation table `Book_Purchase` would be needed with attributes like { ShopID , ISBN , Quantity}, where {ShopID, ISBN} would be a composite primary key.

(iv) E-R Diagram Description: In an E-R diagram, the entities (Author, Book, Editor, ShopOwner, Supplier) would be represented by rectangles. Their attributes would be in ovals, with primary keys underlined. The relationships (Writes, Edits, Buys) would be shown in diamond shapes.

  • `Author` (1) — — (N) `Book`
  • `Editor` (1) — — (N) `Book`
  • `ShopOwner` (M) — — (N) `Book` (This would resolve into a junction table)

(v) Optional and Mandatory Relationships: Participation in a relationship can be either mandatory or optional.

  • Mandatory Relationship: Represented by a double line in an E-R diagram. It means that every entity in an entity set must participate in the relationship. Example: The participation of `Book` in the `Writes` relationship is mandatory. Every book must have an author. A book cannot exist without an author.
  • Optional Relationship: Represented by a single line. It means that an entity in the entity set has the option to participate in the relationship. Example: The participation of `Author` in the `Writes` relationship could be optional. An author might exist in the system but has not yet written any books (or has no books currently published). Similarly, an editor might not be assigned to edit a book at all times.

(e) Need of Normalization Normalization is a process of organizing the columns and tables in a database to minimize data redundancy and improve data integrity. It is necessary to protect the database from so-called “anomalies.”

The main needs are:

  1. To Minimize Data Redundancy: Normalization ensures that information is stored in only one place. This saves storage space and makes it easier to maintain data consistency.
  2. To Avoid Insertion Anomaly: If data is not properly normalized, we might not be able to insert some information until some other, unrelated information is available. For example, in a non-normalized table, we cannot add a new department until there is at least one employee in that department.
  3. To Avoid Update Anomaly: If the same piece of information is stored in multiple places, updating it requires making changes at all locations. If we forget to update one instance, the database becomes inconsistent.
  4. To Avoid Deletion Anomaly: Deleting a row might unintentionally cause other critical information to be deleted as well. For example, if we delete the record of an employee, and they are the only employee in a department, we might lose information about the department itself.

There are various levels of normalization (1NF, 2NF, 3NF, BCNF, etc.), which progressively reduce redundancy and anomalies.

Q2. (a) Consider the following tables : 8 MP (empno, ename, sal, job, mgr, hiredate, deptno, comm., birthdate). DEPT (deptno, dname, Loc) SALGRADE (grade, losal, hisal) Write SQL queries for the following : (i) Display total salary given to employees of department number 0. (ii) Display names of employees who have alphabet ‘a’ in their name. (iii) Display employee name, their department name along’ with salary grade of employees working in either department 0 or 20. (iv) Display average salary given to employees in every department. (b) What is the difference between SDLC and Database Life Cycle ? 4 (c) Explain the concept of data independence. 3

Ans. (a) SQL Queries

(i) Display total salary given to employees of department number 0. 

SELECT SUM(sal) AS TotalSalaryFROM MPWHERE deptno = 0;

Explanation: This query selects all rows from the `MP` table where the `deptno` is 0. It then uses the `SUM()` aggregate function to calculate the total of the `sal` column for those selected rows.

(ii) Display names of employees who have alphabet ‘a’ in their name. 

SELECT enameFROM MPWHERE ename LIKE '%a%';

Explanation: The `LIKE` operator is used for pattern matching. The `%` wildcard represents any sequence of characters (zero or more). So, `’%a%’` means any string that contains the letter ‘a’ anywhere within it.

(iii) Display employee name, their department name along with salary grade of employees working in either department 0 or 20. 

SELECT M.ename, D.dname, S.gradeFROM MP MJOIN DEPT D ON M.deptno = D.deptnoJOIN SALGRADE S ON M.sal BETWEEN S.losal AND S.hisalWHERE M.deptno IN (0, 20);

Explanation: This query joins three tables:

  • `MP` and `DEPT` are joined on `deptno` to get the department name (`dname`).
  • The result is then joined with `SALGRADE` on the condition that the employee’s salary (`sal`) falls between the lowest (`losal`) and highest (`hisal`) salary for that grade.
  • The `WHERE` clause filters the results to include only those employees who are in department 0 or 20.

(iv) Display average salary given to employees in every department. 

SELECT deptno, AVG(sal) AS AverageSalaryFROM MPGROUP BY deptno;

Explanation: The `GROUP BY deptno` clause divides the rows of the `MP` table into groups based on their `deptno`. The `AVG(sal)` function then calculates the average salary for each group (i.e., for each department).

(b) Difference between SDLC and Database Life Cycle (DBLC) The System Development Life Cycle (SDLC) and the Database Life Cycle (DBLC) are both structured processes for developing and maintaining an information system, but they differ in their scope.

  • SDLC (System Development Life Cycle):
    • Scope: The SDLC has a broad scope. It covers the development of the entire information system, including hardware, software, networks, data, processes, and people.
    • Phases: Its general phases are Planning, Analysis, Design, Implementation, Testing, Deployment, and Maintenance.
    • Relationship: The DBLC is a subset of the SDLC. The DBLC occurs during the analysis, design, and implementation phases of the SDLC.
  • DBLC (Database Life Cycle):
    • Scope: The DBLC has a narrow and specific scope. It focuses solely on the database component of the system.
    • Phases: Its specific phases are Database Initial Study, Database Design (which includes conceptual, logical, and physical design), Implementation and Loading, Testing and Evaluation, Operation, and Maintenance and Evolution.
    • Goal: Its primary goal is to design and implement an efficient, reliable, and secure database that meets the data requirements of the system.

In summary, SDLC is like planning the construction of an entire house, while DBLC is like focusing on designing and installing the plumbing system for that house.

(c) Concept of Data Independence Data independence is the ability of a database system to modify the schema at one level without affecting the schema at the next higher level. It is a key benefit of data abstraction. There are two types of data independence:

  1. Physical Data Independence:
    • This is the ability to change the physical schema without having to change the logical or conceptual schema.
    • Changes made at the physical level (e.g., switching storage devices, changing file organization techniques, or creating/deleting indexes) should not affect application programs.
    • Example: If we add a new index on a table to improve performance, we do not need to change the applications that use that table.
  2. Logical Data Independence:
    • This is the ability to change the logical (conceptual) schema without having to change the external schemas (user views).
    • Changes made at theλογικαλ level (e.g., adding a new column to a table, or merging two tables into one) should not affect existing application programs, as long as they don’t directly use the data that was changed.
    • This is more difficult to achieve than physical data independence.
    • Example: If we add a new column `email_address` to the `MP` table, existing queries that do not use this column will continue to work as before.

Q3. (a) Explain the TABLE constraints that can be defined on any relation with the help of an example. 10 (b) Explain any five data types used in SQL. 5

Ans. (a) Table Constraints In SQL, constraints are rules applied to the data in a table’s columns. These rules are used to ensure the accuracy and reliability of the data. If any data operation violates the constraint, the operation is aborted. Constraints can be defined at the column level or the table level.

The main table constraints are:

  1. NOT NULL: Ensures that a column cannot have a NULL value. That is, every record must have a value for that column.
  2. UNIQUE: Ensures that all values in a column (or a group of columns) are unique. A table can have multiple `UNIQUE` constraints, and it allows for NULL values (typically one).
  3. PRIMARY KEY: This is a combination of `NOT NULL` and `UNIQUE` constraints. It uniquely identifies each record in the table. A table can have only one `PRIMARY KEY`.
  4. FOREIGN KEY: This is a column (or group of columns) in one table that refers to the `PRIMARY KEY` of another table. It is a link between two tables and is used to maintain referential integrity. It ensures that a value in the foreign key column either exists in the referenced primary key column or is `NULL`.
  5. CHECK: Ensures that all values in a column satisfy a specific condition. For example, ensuring that the value in an ‘Age’ column is greater than 18.
  6. DEFAULT: Specifies a default value for a column when no value is specified. This is not technically a constraint but is often used along with them.

Example: Let’s create a `Students` table and a `Courses` table that use these constraints. 

CREATE TABLE Courses ( CourseID INT PRIMARY KEY, CourseName VARCHAR(100) NOT NULL, Credits INT CHECK (Credits > 0));
CREATE TABLE Students ( StudentID INT PRIMARY KEY, FirstName VARCHAR(50) NOT NULL, LastName VARCHAR(50) NOT NULL, Email VARCHAR(100) UNIQUE, EnrollmentDate DATE, Age INT CHECK (Age >= 18), EnrolledCourseID INT, FOREIGN KEY (EnrolledCourseID) REFERENCES Courses(CourseID));

In this example:

  • In the `Students` table, `StudentID` is the PRIMARY KEY , uniquely identifying each student.
  • `FirstName` and `LastName` are NOT NULL , meaning every student must have a first and last name.
  • `Email` is UNIQUE , ensuring no two students can have the same email address.
  • `Age` has a CHECK constraint, ensuring only students aged 18 or older are enrolled.
  • `EnrolledCourseID` is a FOREIGN KEY that references `CourseID` in the `Courses` table. This ensures that a student can only be enrolled in a course that exists in the `Courses` table.

(b) SQL Data Types In SQL, every column must be assigned a data type. This tells the DBMS what kind of data will be stored in that column. Here are five common SQL data types:

  1. INT or INTEGER:
    • Description: This data type is used to store integer numbers (whole numbers without decimals). Its size depends on the DBMS but typically can store numbers from -2,147,483,648 to 2,147,483,647.
    • Example: `StudentID INT`, `Age INT`
  2. VARCHAR(n) or VARCHAR2(n):
    • Description: This is used to store variable-length character strings. The `n` specifies the maximum length of the string. It only stores the space that is used, making it efficient for storage.
    • Example: `FirstName VARCHAR(50)` will store names up to 50 characters long.
  3. CHAR(n):
    • Description: This is used to store fixed-length character strings. If the string stored is shorter than `n`, it is padded with spaces on the right. It is useful for data that is always the same length, such as country codes (‘US’, ‘IN’).
    • Example: `StateCode CHAR(2)`
  4. DATE:
    • Description: This data type is used to store date values (year, month, and day). The format can vary depending on the DBMS (e.g., ‘YYYY-MM-DD’). Some systems also store time information.
    • Example: `birthdate DATE`
  5. FLOAT(p) or NUMBER(p,s):
    • Description: These data types are used to store decimal or floating-point numbers. `FLOAT` is an approximate-value numeric type, while `NUMBER` (in Oracle) or `DECIMAL` (in SQL Server, MySQL) is an exact-value numeric type. `p` refers to the total number of digits (precision) and `s` refers to the number of digits after the decimal point (scale).
    • Example: `Salary DECIMAL(10, 2)` can store a salary up to 10 digits in total with 2 decimal places. `pi FLOAT`

Q4. (a) Consider the following dependency diagram : 6 SSN -> Ename Proj_number -> pname, plocation {SSN, Proj_number} -> Hours (i) List the types of functional dependencies shown in diagram. (ii) Normalize till 3NF. (b) Explain ALTER command with examples. 4 (c) Explain the advantages of relational model over hierarchical or network data model. 5

Ans. (a) Dependency Diagram and Normalization Based on the given dependency diagram, we can assume we have a relation `R(SSN, Ename, Proj_number, pname, plocation, Hours)`. The composite key `{SSN, Proj_number}` uniquely identifies the whole relation, so it is the primary key.

(i) Types of Functional Dependencies:

  1. Full Functional Dependency:
    • `{SSN, Proj_number} -> Hours`: The attribute `Hours` is fully dependent on the composite primary key `{SSN, Proj_number}`. It is not dependent on any part of the primary key (neither `SSN` alone nor `Proj_number` alone).
  2. Partial Functional Dependency:
    • `SSN -> Ename`: The attribute `Ename` is dependent on a part of the composite primary key (`SSN`), not the whole key. This is a violation of 2NF.
    • `Proj_number -> pname, plocation`: The attributes `pname` and `plocation` are dependent on another part of the composite primary key (`Proj_number`), not the whole key. This is also a violation of 2NF.
  3. Transitive Dependency:
    • In the given dependencies, there is no transitive dependency. A transitive dependency exists when a non-prime attribute depends on another non-prime attribute. Here, the dependencies are only on the primary key (or its parts).

(ii) Normalize till 3NF: We will proceed through the normalization process.

Original Relation (in 1NF): `EMP_PROJ( SSN , Ename, Proj_number , pname, plocation, Hours)` (Primary Key: {SSN, Proj_number})

Converting to 2NF (Removing Partial Dependencies): To achieve 2NF, we must remove partial dependencies. We decompose the original relation into smaller relations, each with its determinant.

  • For the dependency `SSN -> Ename`, we create a new table `EMPLOYEE`. EMPLOYEE( SSN , Ename)
  • For the dependency `Proj_number -> pname, plocation`, we create a new table `PROJECT`. PROJECT( Proj_number , pname, plocation)
  • The remaining attribute, which depends on the full key, stays in a revised version of the original table. WORK_ON( SSN , Proj_number , Hours)

Now we have three tables that are in 2NF: `EMPLOYEE`, `PROJECT`, and `WORK_ON`.

Converting to 3NF (Removing Transitive Dependencies): 3NF requires that the relation is in 2NF and has no transitive dependencies.

  • EMPLOYEE( SSN , Ename): Has no transitive dependencies because there is only one non-prime attribute. It is in 3NF.
  • PROJECT( Proj_number , pname, plocation): Has no transitive dependencies. `pname` and `plocation` depend directly on `Proj_number`. It is in 3NF.
  • WORK_ON( SSN , Proj_number , Hours): Has no non-prime attributes at all, so no transitive dependencies can exist. It is in 3NF.

Thus, the decomposition into 3NF results in the three tables: `EMPLOYEE`, `PROJECT`, and `WORK_ON`.

(b) ALTER Command The `ALTER` command in SQL is used to modify the structure of a database object, such as a table. The `ALTER TABLE` statement is used to add, delete, or modify columns in an existing table, or to add or drop constraints.

Examples: Let’s assume we have a table `Students`: `CREATE TABLE Students (ID INT, Name VARCHAR(50));`

  1. Adding a new column (ADD): To add a new column ‘Email’ to the table: 
    ALTER TABLE Students ADD Email VARCHAR(100);
  2. Dropping a column (DROP COLUMN): If we want to remove the ‘Email’ column: 
    ALTER TABLE Students DROP COLUMN Email;
  3. Modifying a column (MODIFY/ALTER COLUMN): To change the data type of the ‘Name’ column from `VARCHAR(50)` to `VARCHAR(100)`: (Syntax may vary by DBMS) 
    -- MySQL / OracleALTER TABLE Students MODIFY Name VARCHAR(100);
    -- SQL ServerALTER TABLE Students ALTER COLUMN Name VARCHAR(100);
  4. Adding a constraint (ADD CONSTRAINT): To make the ‘ID’ column a primary key: 
    ALTER TABLE Students ADD CONSTRAINT PK_StudentID PRIMARY KEY (ID);

The `ALTER` command is powerful as it allows changes to table structure without losing data (though some modifications can be risky).

(c) Advantages of Relational Model over Hierarchical or Network Data Model The Relational Data Model (proposed by E.F. Codd in 1970) offered several significant advantages over the hierarchical and network models, which were dominant at the time.

  1. Simplicity:
    • Relational: Data is presented in a simple and intuitive format of tables (relations), which is easy to understand and use.
    • Hierarchical/Network: These models use complex tree or graph structures based on pointers and links, which are difficult to navigate and comprehend.
  2. Flexibility and Powerful Query Capability:
    • Relational: Provides high-level, declarative languages like SQL (Structured Query Language). The user specifies what data they want, not how to get it. This is very flexible for ad-hoc queries.
    • Hierarchical/Network: Data access is procedural and record-at-a-time. The programmer has to manually navigate through the data structures by following pointers, which is complex and tedious.
  3. Data Independence:
    • Relational: It offers a high degree of both physical and logical data independence. Application programs are insulated from changes to the storage structure or the database schema.
    • Hierarchical/Network: Data access paths are built into the application logic, so any change in the data structure requires significant modifications to the application programs.
  4. Reduced Data Redundancy:
    • Relational: Through the process of normalization, the relational model systematically reduces data redundancy, which improves data integrity and avoids anomalies.
    • Hierarchical/Network: These models inherently lead to redundancy, especially when representing M:N relationships, which can cause data inconsistency problems.
  5. Solid Theoretical Foundation:
    • Relational: The model is based on mathematics (set theory and predicate logic), which gives it a strong theoretical foundation and allows for consistency and predictability in database design and query optimization.

Q5. Explain the following with example/diagram : 5×5=25 (a) Lossless join (b) Outer join (c) Derived attribute (d) Aggregate functions (e) GROUP BY clause

Ans. (a) Lossless Join A decomposition is said to be a lossless join if the original relation can be recovered by performing a natural join on the decomposed relations without creating any extra or spurious tuples. This is a critical requirement in normalization to ensure no information is lost during decomposition.

A decomposition of a relation `R` into two relations `R1` and `R2` is lossless if and only if the following two conditions are met:

  1. The union of the attributes of `R1` and `R2` is equal to all the attributes of `R`.
  2. The intersection of the attributes of `R1` and `R2` (the common attributes) is a superkey for either `R1` or `R2`.

Example: Let’s say we have a relation `R(A, B, C)` with the functional dependency `B -> C`. Original Relation: R | A | B | C | |—|—|—| | a1| b1| c1| | a1| b2| c2| | a2| b1| c1|

We decompose it into `R1(A, B)` and `R2(B, C)`. R1(A, B) | A | B | |—|—| | a1| b1| | a1| b2| | a2| b1|

R2(B, C) | B | C | |—|—| | b1| c1| | b2| c2|

Now, if we perform a natural join on `R1` and `R2` (on the common attribute `B`), we get the original relation `R` back. Therefore, this is a lossless join decomposition.

(b) Outer Join An outer join is a type of join that returns the matching rows like an inner join, but also returns rows from one table that do not have a matching row in the other table. It does this by including the unmatched rows and using `NULL` values for the columns from the table where a match was not found.

There are three types of outer joins:

  • LEFT OUTER JOIN (or LEFT JOIN): Returns all rows from the left table and only the matching rows from the right table. If there is no match in the right table, the result is `NULL` for the columns from the right table.
  • RIGHT OUTER JOIN (or RIGHT JOIN): Returns all rows from the right table and only the matching rows from the left table. If there is no match in the left table, the result is `NULL` for the columns from the left table.
  • FULL OUTER JOIN: Returns all rows when there is a match in either table. It is essentially a combination of a left and a right outer join.

Example: Let’s say we have two tables: `Customers` and `Orders`. Customers | CustID | Name | |——–|——-| | 1 | John | | 2 | Jane | | 3 | Mike |

Orders | OrderID | CustID | Amount | |———|——–|——–| | 101 | 1 | 200 | | 102 | 3 | 150 | | 103 | 4 | 300 |

A `SELECT C.Name, O.OrderID FROM Customers C LEFT JOIN Orders O ON C.CustID = O.CustID;` would result in: | Name | OrderID | |——-|———| | John | 101 | | Jane | NULL | <– Jane has no orders, but is in the result. | Mike | 102 |

(c) Derived Attribute A derived attribute is an attribute whose value can be calculated or derived from another attribute or set of attributes. These attributes are not typically stored physically in the database to avoid redundancy and to maintain data consistency. They are calculated whenever they are needed.

In an E-R Diagram, a derived attribute is represented by a dotted oval .

Example: In an `Employee` entity, `DateOfBirth` can be a stored attribute. From this `DateOfBirth`, we can calculate the employee’s `Age`.

  • Stored Attribute: `DateOfBirth`
  • Derived Attribute: `Age`

There is no need to store `Age` because it changes every day and can always be calculated from `DateOfBirth` and the current date. Storing it could lead to inconsistent data if it’s not updated regularly.

E-R Diagram Representation: (Employee)—-[DateOfBirth] | |—-( Age ) <– in a dotted oval

(d) Aggregate Functions Aggregate functions in SQL are functions that perform an operation on a set of values (a column) and return a single value. These functions are often used with the `GROUP BY` clause to calculate summary information on subsets of data.

The five main SQL aggregate functions are:

  • COUNT(): Returns the number of rows that match a criterion. `COUNT(*)` counts all rows, while `COUNT(column_name)` counts non-NULL values in that column.
  • SUM(): Returns the total sum of all values in a numeric column.
  • AVG(): Returns the average of values in a numeric column.
  • MIN(): Returns the minimum value from a column.
  • MAX(): Returns the maximum value from a column.

Example: Using the `MP` table:

  • `SELECT COUNT(*) FROM MP;` — returns the total number of employees.
  • `SELECT SUM(sal) FROM MP WHERE deptno = 10;` — returns the total salary for department 10.
  • `SELECT AVG(sal) FROM MP;` — returns the average salary of all employees.
  • `SELECT MIN(hiredate) FROM MP;` — returns the hire date of the first-hired employee.
  • `SELECT MAX(sal) FROM MP;` — returns the highest salary.

(e) GROUP BY Clause The `GROUP BY` clause in SQL is used with the `SELECT` statement to group rows that have the same values in specified columns into summary rows. It returns one summary row for each group. `GROUP BY` is almost always used with aggregate functions (`COUNT`, `MAX`, `MIN`, `SUM`, `AVG`) to perform an operation on each group.

In a `SELECT` statement, the `GROUP BY` clause comes after the `WHERE` clause and before the `ORDER BY` clause.

Syntax: 

SELECT column_name1, aggregate_function(column_name2)FROM table_nameWHERE conditionGROUP BY column_name1;

Example: Let’s say we want to find the number of employees and their average salary in each department. 

SELECT deptno, COUNT(*) AS NumberOfEmployees, AVG(sal) AS AverageSalaryFROM MPGROUP BY deptnoORDER BY deptno;

This query:

  1. Takes rows from the `MP` table.
  2. Divides them into groups by `deptno` (e.g., all dept 10 employees in one group, all dept 20 in another, etc.).
  3. For each group, it calculates the number of employees using `COUNT(*)` and the average salary using `AVG(sal)`.
  4. The result will have one row for each department, showing the department number, the count of employees, and the average salary.

Download IGNOU previous Year Question paper download PDFs for BCS-092 to improve your preparation. These ignou solved question paper IGNOU Previous Year Question paper solved PDF in Hindi and English help you understand the exam pattern and score better.

Thanks!

Reader Interactions

Leave a Reply

Your email address will not be published. Required fields are marked *