How to Define Second Normal Form? It’s not too typical.

Define Second Normal Form: First Normal Form की Insertion, Deletion व Update जैसी विभिन्न Anomalies को हटाने का समाधान ये है कि First Normal Form वाली Relation से सभी Entities को एक अलग Relation के रूप में Define किया जाए।

उदाहरण के लिए Music Store के इस Orders Relation में से हम चार स्वतंत्र Entities (Customers, Items, Orders व Line Items ) को अलग कर सकते हैं। एसा करने पर Music Store Organization का ये Relation Second Normal Form में आ जाता है। Theoretical शब्दों में Second Normal Form को निम्नानुसार परिभाषित किया जा सकता हैः

जब Relation First Normal Form में हो और सभी Non-Key Attributes, Functionally सिर्फ Primary Key पर Dependent हों।

यदि कोई Non-Key Attribute Functionally केवल Primary Key पर Depend ना होकर किसी Non-Key Attribute पर Depend हो, तो उस Non-Key Attribute और उस पर Depend सभी अन्य Non-Key Attributes को उस Relation से हटाकर एक नए Relation में Define करना चाहिए और इस नए Relation में उस Key को Primary Key बना देना चाहिए, जिस पर अन्य Attributes Depend हों।

Functional Dependency दो Attributes के बीच की एक One-Way Relationship होती है। जैसे किसी Relation में किसी भी समय एक Attribute A से किसी दूसरे Attribute B की केवल एक ही Value Associated होनी चाहिए। उदाहरण के लिए मानलो कि Orders Relation में A एक Customer का Customer Number या CustID है। अब हर Customer का Customer Number एक First Name, एक Last Name, एक Street Address, एक City, एक State, एक Pincode व एक Telephone Number से Associated होता है।

हालांकि इन Attributes की Values को किसी भी समय Change किया जा सकता है, लेकिन किसी भी समय हर Attribute में केवल एक ही मान होता है। इस स्थिति में हम कह सकते हैं कि First Name, Last Name, Street Address, City State, Pincode व Telephone Numbers ये सभी Functionally Customer Number पर Dependent हैं। Attributes के बीच की इस Relationship को अक्सर निम्नानुसार Represent किया जाता हैः

CustID -> FName, LName, Street Address, City, State, Pincode, Telephone

और इसे इस तरह Read किया जाता है कि “Customer Number Determines First Name, Last Name, Street Address, City State, Pincode and Telephone Numbers”. इस Relationship में Customer Number यानी CustID को Determinant के रूप के जाना जाता है, जो कि एक एसा Attribute होता है, जो अन्य Attributes की Values को Determine करता है।

ध्यान रखें कि Functional Dependency को Reverse Direction में Represent नहीं किया जा सकता है। उदाहरण के लिए किसी भी First Name या Last Name को एक से ज्यादा Customer Numbers के साथ Associate किया जा सकता है। Orders Table में निम्न Functional Dependencies हैं:

CustID -> FName, LName, Street Address, City, State, Pincode, Telephone
ItemID ->  Title, Price
OrderID-> CustID, OrderDate
ItemID + OrderID       ->   HasShipped

ध्यान दें कि Relation में हर Entity के लिए एक Determinant है और Determinant वही है, जिसे हमने Entity Identifier के रूप में Choose किया है। जब किसी Entity में Composite Identifier होता है, तब Determinate भी Composite होता है, जैसाकि चौथे Representation में ItemID+OrderID का Group एक Composite Identifier है। इस Example में कोई Order Ship किया जा चुका है अथवा नहीं, ये ItemID व OrderID के Combination पर Depend करता है।

जब हम किसी Database Environment में किसी Relation के विभिन्न Attributes के बीच की Functional Dependencies को Correctly Identify कर लेते हैं, उसके बाद हम इनका प्रयोग Relations को Second Normal Form में Transform करने के लिए कर सकते हैं। इस स्थिति में हर Determinant Relation का Primary Key बन जाता है और जितने भी Attributes इस Determinant पर Depend होते हैं, वे सभी Attributes Relation के Non-Key Attributes बन जाते हैं। इस Concept के आधार पर Music Store Organization के Original Relation में से जिन चार Entities को स्वतंत्र रूप से Identify करके अलग किया जाता है, उन्हें निम्नानुसार Represent किया जा सकता हैः

Customer (CustID, FName, LName, Street Address, City, State, Pincode, Telephone)
Items (ItemID, Title, Price)
Orders (OrderID, CustID, OrderDate)
LineItems (ItemID, OrderID, HasShipped )

ये चारों ही Relations ER-Diagram के एक Single Entity से सम्बंधित होते हैं। ध्यान दें कि Database Design को Functional Dependencies व Entities दोनों में से किसके आधार पर Derive किया जाए, इसका कोई निश्चित नियम नहीं होता है। महत्वपूर्ण बात ये होती है कि ER Diagram व अपने Relation में Identify की गई Functions Dependency दोनों के बीच Consistency होनी चाहिए। इस बात से Database के Design पर कोई प्रभाव नहीं पडता है कि हम अपने Relation को Functional Dependency के आधार पर Design करते हैं या Entities के आधार पर।

ज्यादातर स्थितियों में Database Design एक Interactive Process होता है, जिसमें हम Database का Initial Design Create करते हैं, उसे Check करते हैं, Modify करते हैं और फिर से Check करते हैं। हम Design Process के किसी भी Stage में Function Dependency और/या Entities को देख सकते हैं और एक दूसरे के Against Check कर सकते हैं। क्योंकि हमेंशा ये जरूरी नहीं होता है कि हमने जिस Relation को First Normal Form में मान लिया है, वह वास्तव में First Normal Form में हो। Design Process के किसी भी Stage में हमें एसा महसूस हो सकता है, कि Relation पूरी तरह से First Normal Form में नहीं है और उसे फिर से First Normal Form में लाने की जरूरत है। जब हम Relation पर Second Normal Form के Criteria Rules को Apply करते हैं, तब Original Relation में Present Anomalies Eliminate हो जाती हैं और हम निम्न काम कर सकते हैं:

• Customer के Order Place करने से पहले ही हम उस Customer के Data को Database Relation में Store कर सकते हैं।
• हम किसी Order के Data को बिना Items की Information के भी Database Relation में Store कर सकते हैं।
• किसी Customer द्वारा किसी Particular Item का Order दिए जाने से पहले भी हम Item के Data को Database Relation में Store कर सकते हैं।
• अब Line Items को किसी भी Order से Delete किया जा सकता है। एसा करने पर Item को Describe करने वाले Data, स्वयं Order या किसी Item की Information पर इसका कोई प्रभाव नहीं पडता है।
• Customer से सम्बंधित Data को केवल एक ही बार Store किया जाता है, इसलिए यदि Customer के Data में किसी प्रकार का Change करना पडे, तो ये Change केवल एक ही बार करना पडता है। इसमें Modification Anomaly का प्रभाव नहीं पडता है, क्योंकि Customer के Data को Database Relation में कई बार Store नहीं किया जाता है।

हालांकि Second Normal Form विभिन्न Relations में से ज्यादातर समस्याओं को समाप्त कर देता है। बहुत कम बार ही ऐसी स्थितियां होती हैं, जब हमारा Relation Second Normal Form में होता है, फिर भी उसमें Anomalies होती है। उदाहरण के मानलो कि Music Store जिन Distributors से Titles लेता है, उन सभी Distributors के पास केवल एक ही Store Room है, जहां पर सिर्फ एक Telephone है। इस स्थिति में निम्न Relation Second Form में होगाः

Items (ItemID, Title, Distributor, WareHousePhoneNo)

हर ItemID के लिए इस Relation में केवल एक Title, एक Distributor व एक Warehouse Telephone Number है। इसलिए इस Relation में एक Insertion Anomaly है। हम तब तक किसी Distributor का Data Music Store Database में Store नहीं कर सकते हैं, जब तक कि हमें उस Distributor से कोई Item प्राप्त नहीं होता है। साथ ही इस Relation में एक Deletion Anomaly भी है, क्योंकि यदि हम किसी Distributor द्वारा भेजे गए Only Item की Details को Delete कर देते हैं, तो हम Distributor की Information को भी खो देंगे। इस Relation में हर Item के Record के साथ Distributor के Warehouse के Phone Number को भी Store किया जाता है, जिससे इसका बार-बार Duplication भी होता है, इसलिए इस Relation में Modification Anomaly भी है। इस स्थिति में ये Relation Second Normal Form में तो है, लेकिन Third Normal Form में नहीं है। (Define Second Normal Form)