डेटा सामान्यीकरण किस बिंदु पर लुभावना हो जाता है?

मैं अक्सर खुद से पूछताछ करता हूं कि क्या मैं डेटाबेस और संबंध बनाने के दौरान भविष्य की विस्तार के लिए योजना बनाने का प्रयास करने में सही दृष्टिकोण ले रहा हूं।डेटा सामान्यीकरण किस बिंदु पर लुभावना हो जाता है?

मैं एक Donor मेज और एक Recipient तालिका है:

मैं निम्नलिखित स्थिति है। दोनों टेबल first_name, last_name, email_address, date_of_birth इत्यादि जैसी सामान्य जानकारी साझा करते हैं। दोनों प्रतीत होता है कि यदि आप मेरी ऑब्जेक्ट उन्मुख भाषा को क्षमा करेंगे, तो Person का एक सामान्य सार प्रकार साझा करें। यह संभव है कि कोई भी व्यक्ति जो Recipient पर दान दे रहा है, बाद में दान देने के माध्यम से Donor बन सकता है, इसलिए यह महत्वपूर्ण है कि जानकारी तालिकाओं में डुप्लिकेट न हो। क्या मुझे विरासत पैटर्न का चयन करना चाहिए, या क्या मुझे सिर्फ Donor एस और Recipient एस Person तालिका में विदेशी कुंजी चाहिए?
प्रारंभ में, मैं email_address और सड़क पता गुणों को सीधे उन चीजों में मैप करने की सोच रहा था, जिनकी आवश्यकता है, लेकिन फिर संभावना उत्पन्न हो सकती है कि एक व्यक्ति के पास कई ईमेल पते या मेलिंग पते होंगे (यानी: घर, काम, आदि)। इसका मतलब यह है कि हमारे पास कुछ हद तक मॉडल है:
```
create table person(id int primary key auto increment, ..., 
    default_email_address); 

create table email_address(id int primary key auto increment, 
    email varchar(255), name varchar(255), is_default bool, person_id int); 
```
इससे चीजें थोड़ा जटिल हो जाती हैं, जैसा कि आप कल्पना कर सकते हैं। name फ़ील्ड में डिफ़ॉल्ट मानों की एक सूची भी शामिल है साथ ही कस्टम इनपुट की अनुमति भी शामिल है। मैं इसे सिर्फ एक enum फ़ील्ड नहीं बना सकता, क्योंकि संभावना मौजूद है कि किसी के पास जोड़ने के लिए बहुत सारे ईमेल होंगे जो सभी अलग हो सकते हैं ... (यह वह बिंदु है जिस पर मैं चिल्लाता हूं "क्या यह सब भी काम करता है !?!? "और परियोजना के साथ निराश हो)

मुझे लगता है कि क्या यह वास्तव में करने पर निर्भर करता निम्नलिखित है: क्या बिंदु पर डेटा सामान्य ऊटपटांग बन जाता है? मेरा लक्ष्य यहां वास्तव में एक अच्छा-आगे-अनुकूल-अनुकूल डेटा मॉडल बनाना है जिसे मैं बाद में बनाने के लिए खुद को लात नहीं दूंगा।

स्रोत

2012-03-29 Naftuli Kay

अपने # 2 में, कौन-सा डेटा सामान्य करने के लिए वैकल्पिक हो सकता है? आप लगभग एक पंक्ति में एक ही फ़ील्ड के लिए निश्चित रूप से एकाधिक मान नहीं चाहते हैं, इसलिए मुझे किसी अन्य तालिका में विभाजित करने का विकल्प नहीं दिख रहा है। –

डेटा सामान्यीकरण किस बिंदु पर लुभावना हो जाता है?

इस बिंदु पर कि यह वास्तविक आवश्यकताओं को मॉडलिंग करना बंद कर देता है।

अपने उदाहरण लेने के लिए:

Donor और Recipient तालिकाओं के साथ
, अगर यह काफी संभावना है कि किसी एक व्यक्ति दोनों हो जाएगा है, तो यह समझ बनाने के एक Person संस्था को अलग करने से करता है। यदि यह दुर्लभ है, तो यह नहीं है।
email_address और street_address स्थितियों के साथ, यह निर्भर करता है कि आपको गुणकों को स्टोर करने की आवश्यकता है या नहीं (उम्मीद क्या है?)। आप प्रति व्यवसाय इकाई के अलग-अलग संस्करणों को स्टोर करना चाहते हैं (shipping_address बनाम billing_address) कहें।

स्रोत

2012-03-29 18:23:32 Oded

+1 "जब यह वास्तविक आवश्यकताओं को मॉडलिंग करना बंद कर देता है"। डेटा मॉडलिंग पर बहुत दूर जाकर एक ओओ कक्षा संरचना का निर्माण करते समय दूर तक जा रहा है। –

मुख्य समस्या जो मैं अनुमान लगाने की कोशिश कर रहा हूं वह भविष्य में परिवर्तन है। क्या होगा यदि ग्राहक आता है और मुझे बताता है कि वे एकाधिक पते या ईमेल पते चाहते हैं? जिस तरह से मैं इसे देखता हूं, मैं या तो समस्या से निपटने के लिए समस्या का सामना करता हूं, या बाद में एसक्यूएल माइग्रेशन का सामना करता हूं। –

@ टीकेकोचेरन - यही समस्या है: 'मैं भविष्य में बदलाव की उम्मीद कर रहा हूं'। मत करो। एक क्लीन सिस्टम बनाएं जो _current_ आवश्यकताओं के लिए काम करता है। जब वे बदलते हैं, तो सिस्टम को बदलें। आप भविष्य की भविष्यवाणी नहीं कर सकते - इसे स्वीकार करें। – Oded

मुझे लगता है कि समस्या आपके कार्यान्वयन में नहीं है, बल्कि समस्या के आपके विश्लेषण में है।Donor और Recipient प्रथम श्रेणी के अभिनेता नहीं हैं, वे अभिनेताओं के भूमिका हैं।

आपके पास पते वाला एक व्यक्ति मेज होगा और इतने
पर आप भी लोगों के पते के साथ कोई पता तालिका होगा: आप इस तरह के रूप में उन्हें मॉडल हैं, तो आप कुछ हद तक एक क्लीनर मॉडल मिल चाहते हैं
आपके पास भूमिका कोड (दाता, प्राप्तकर्ता) और अन्य प्रासंगिक जानकारी के साथ एक व्यक्ति_रोएल तालिका भी होगी। आप person तालिका में एक विदेशी कुंजी के साथ, फैंसी प्राप्त करना चाहते हैं, और person_donor और person_recipient जोड़ें।

स्रोत

2012-03-29 18:25:54 dasblinkenlight

मैं सभी साझा डेटा को Person तालिका में डाल दूंगा। Donor और Recipient तालिकाओं में केवल उस डेटा को होना चाहिए जो प्रत्येक के लिए विशिष्ट हो, और Person की प्राथमिक कुंजी पर इंगित करने वाली विदेशी कुंजी होनी चाहिए।

यह बिल्कुल लुभावना सामान्यीकरण नहीं है; यह वास्तव में बहुत आम अभ्यास है।

स्रोत

2012-03-31 02:56:12 FtDRbwLXw6

संक्षिप्त उत्तर: सामान्यीकरण कभी हास्यास्पद नहीं होता है। आप जो कुछ भी कर रहे हैं वह सामान्यीकरण नहीं है।

लंबे समय तक जवाब देने

"सबसे बुरी" (सच में, "सबसे अच्छा) सबसे डिजाइनरों करना व्यावहारिक रूप से कर सकते हैं 5NF में सभी तालिकाओं के साथ पहुंचते हैं। 5NF बिल्कुल हास्यास्पद नहीं है। (हाँ, मैं 6NF के बारे में पता है। मैं उपदेशात्मक कारणों के लिए यह अनदेखी कर रहा हूँ।)

सवाल है कि क्या मैं भविष्य तानना के लिए की योजना की कोशिश में सही दृष्टिकोण ले रहा हूँ

गु अपने आप से पूछने के लिए एक अच्छा सवाल है। हालांकि, सामान्यीकरण के साथ इसका कोई लेना-देना नहीं है। वैचारिक स्तर पर, सामान्यीकरण कुछ है जो आप के बाद करते हैं, आपने तय किया है कि आपके डेटाबेस में कौन से गुण (कॉलम) और डेटा को जाने की आवश्यकता है। अनुभवी डेटाबेस डिजाइनर अक्सर "3 एनएफ में सोचते हैं", विशेषताओं को चुनने, डेटा, और सामान्य रूप से एक ही समय में सामान्यीकृत करने के लिए, कम या ज्यादा।

क्या मुझे विरासत पैटर्न का चयन करना चाहिए, या क्या मुझे सिर्फ विदेशी कुंजी किसी व्यक्ति को दाताओं और प्राप्तकर्ताओं को चाहिए?

दाताओं और प्राप्तकर्ता विभिन्न प्रकार के लोग नहीं हैं। दाताओं वे लोग हैं जिन्होंने दान किया है। प्राप्तकर्ता वे लोग हैं जिन्हें कुछ प्राप्त हुआ है।

id fullname  don_date don_amt recip_date recip_amt 
-- 
1 Jamie Hubbert 2012-01-13 $20.00 
1 Jamie Hubbert 2012-02-13 $17.00 
2 Kelly Hawkin 2012-01-13 $50.00 
2 Kelly Hawkin 2012-01-13 $20.00 
3 Neva Papke       2012-01-13 $15.00 
3 Neva Papke       2012-02-13 $15.00 
2 Kelly Hawkin      2012-01-13 $10.00 
4 Jamie Hubbert 2012-01-13 $10.00 
4 Jamie Hubbert      2012-02-13 $10.00

सामान्यीकरण के दौरान, आप इन निर्भरताओं की पहचान करेंगे। (सादगी के लिए प्रति व्यक्ति प्रति व्यक्ति एक दान मानता है।)

person_id -> PERSON_NAME
person_id -> ईमेल
person_id, donation_date -> donation_amount
person_id, recip_date -> recip_amount

मानक के अनुसार 5NF के लिए, और आप चाहते इन तीन टेबल प्राप्त करें।

Persons 
-- 
1 Jamie Hubbert 
2 Kelly Hawkin 
3 Neva Papke 
4 Jamie Hubbert 

Donations 
-- 
1 2012-01-13 $20.00 
1 2012-02-13 $17.00 
2 2012-01-13 $50.00 
2 2012-01-13 $20.00 
4 2012-01-13 $10.00 

Receipts (?) 
-- 
3 2012-01-13 $15.00 
3 2012-02-13 $15.00 
2 2012-01-13 $10.00 
4 2012-02-13 $10.00

प्रारंभ में, मैं सीधे बातें कि उन्हें जरूरत में तरह EMAIL_ADDRESS और सड़क का पता गुण बस मानचित्रण गुण के बारे में सोच रहा था, लेकिन उसके बाद संभावना उत्पन्न हो सकती है कि एक व्यक्ति एकाधिक ईमेल पते के लिए होता है या मेलिंग पते (यानी: घर, काम, आदि)।

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

Set A 
1 Jamie Hubbert [email protected] 
4 Jamie Hubbert [email protected] 

Set B 
1 Jamie Hubbert [email protected] 
1 Jamie Hubbert [email protected] 
4 Jamie Hubbert [email protected]

सेट ए, person_id-> ईमेल में। सेट बी में, यह नहीं है। सेट ए में डेटा का समर्थन करने का चयन करना या सेट बी में डेटा बड़ा निर्णय है, और के साथ 5NF के सामान्यीकरण के बाद यह दृढ़ता से प्रभावित करता है। लेकिन यह निर्धारित करने के लिए कि किस सेट का समर्थन करना सामान्यीकरण के साथ कुछ लेना देना नहीं है।

एक तरफ, गैर-अद्वितीय ईमेल पते पर आईडी नंबर असाइन करना चुनना एक और बड़ा (और संदिग्ध) डिज़ाइन निर्णय है। दूसरों की तरह, इस निर्णय के सामान्यीकरण के साथ कुछ लेना देना नहीं है।

(The Random Name generator की रैंडम नाम सौजन्य से।)

स्रोत

2012-04-15 12:40:00

डेटा सामान्यीकरण किस बिंदु पर लुभावना हो जाता है?

उत्तर

संबंधित मुद्दे