What is Database Normalization and Why is it Important: विभिन्न प्रकार के Entities व उनके Attributes को कई तरीकों से किसी Relation के रूप में Represent किया जा सकता है। अब हम Normalization के Process को समझेंगे। जब हम इस Process के आधार पर विभिन्न Relations Create करते हैं, तब एक खराब Database Design से पैदा होने वाली विभिन्न प्रकार की समस्याएं Avoid हो जाती हैं।
Database के Normalization के दो तरीके प्रचलित हैं। पहले तरीके में एक ER-Diagram के आधार पर Normalization किया जाता है। इस तरीके में यदि ER Diagram को Correctly Draw किया गया है, तो हम कुछ Simple Rules को Follow करते हुए उस ER Diagram को एसे Relations में Translate कर सकते हैं, जो ज्यादातर Relational Design Problems को Avoid हो जाता है।
इस Normalization Process की समस्या ये है कि इस तरीके के आधार पर जो Database Design बनता है, वह Design सही है या नहीं, इस बात को निश्चित करने का कोई तरीका नहीं होता है। दूसरे तरीके में हम विभिन्न Relations Create करने के लिए Theoretical Concept को Use करते हैं। ये तरीका पहले तरीके की तुलना में थोडा अधिक जटिल है, लेकिन इससे बनने वाला Design एक Better Design होता है।
Practically इन दोनों तरीकों के Combination को Use करके, ज्यादा आसानी से एक अच्छा Design Create कर सकते हैं। सबसे पहले हम ER Diagram Create करते हैं और इसका प्रयोग करके Relations Create करते हैं। उसके बाद दूसरे तरीके के Theoretical Rules को उन Relations पर Apply करके Design को Check करते हैं।
Translating an ER Diagram into Relations
एक एसा ER Diagram, जिसके सभी Many To Many Relationships को Composite Entities का प्रयोग करके One To Many Relationships में Convert कर लिया गया हो, को Directly Database Relations में Translate कर सकते हैं। एसा करने के लिए हमें निम्न Steps को Follow करने होते हैं:
- हर Entity के लिए एक Table Create करते हैं।
- हर वह Entity जो किसी एक या एक से ज्यादा Relationships के केवल “One” End की तरफ हो और “Many” End की तरफ ना हो, एसे Entity की Table में केवल एक Single-Column Primary Key को Define करना होता है।
- हर वह Entity जो किसी एक या एक से अधिक Relationship के “Many” End की तरफ हो, एसे Entity की Table में उसके Parent Table, जो कि “One” End की तरफ होता है, की Primary Key को अपनी Table में Foreign Key की तरह Use करना चाहिए।
यदि एक Entity जो किसी एक या एक से ज्यादा Relationships के “Many” End की तरफ हो और उसमें कोई Natural Primary Key हो, जैसे कि Invoice Number या Order Number, तो इस Single-Column Primary Key को Use करना चाहिए। लेकिन यदि एसा ना हो, तो इस Table की Parent Table के Primary Key को किसी अन्य Column या Columns के Group के साथ Composite Primary Key के रूप में Use करना चाहिए।
इन Guidelines को Follow करके हम “Music Store” Database के Design को निम्नानुसार Theoretically Represent कर सकते हैं:
Customer (CustID, FName, LName, Street, City, State, Pincode, Telephone, CreditCardNo, CardExpiryDate)
Item (ItemID, Title, DistID, RetailPrice, ReleaseDate, Genre)
Order (OrderID, CustID, OrderDate, OrderFilled)
OrderLines (OrderID, ItemID, Quantity, DiscountApplied, SellingPrice, LineCost, Shipped)
Distributor (DistID, Name, Street, City, State, Pincode, Telephone, ContactPerson, ContactPersonExt)
Actor (ActorID, Name)
Performance (ActorID, ItemID, Role)
Producer (ProducerID, Studio)
Production (ProductionID, ItemID)
इन Relations को थोडा सा Modify किया गया है, लेकिन इन Modifications का ER Diagram या Database के काम करने के तरीके पर कोई अन्तर नहीं पडा है। (What is Database Normalization and Why is it Important)
ये Article इस वेबसाईट पर Selling हेतु उपलब्ध EBook Oracle 8i/9i SQL/PLSQL in Hindi से लिया गया है। इसलिए यदि ये Article आपके लिए उपयोगी रहा, तो निश्चित रूप से ये पुस्तक भी आपके लिए काफी उपयोगी साबित होगी।
Oracle 8i/9i SQL/PLSQL in Hindi | Page: 587 | Format: PDF