5

मैं बेसबॉल आंकड़ों पर डेटा संग्रहीत कर रहा हूं और तीन तालिकाओं के साथ ऐसा करना चाहता हूं: खिलाड़ियों, बल्लेबाजीस्टैट्स और पिचिंगस्टैट्स। प्रश्न के प्रयोजन के लिए, प्रत्येक खिलाड़ी के बल्लेबाजी आंकड़े या पिचिंग आंकड़े होंगे, लेकिन दोनों नहीं।आप एक-से-एक-या-दूसरे संबंधों को कैसे सामान्यीकृत करते हैं?

मैं 3 एनएफ में इस तरह के रिश्ते को सामान्य कैसे करूं?

+0

आपके पास पहले से ही आपका समाधान है। स्टीवन ए लोवे द्वारा वर्णित कुंजी के साथ, अपने प्रश्न में वर्णित तीन तालिकाओं का उपयोग करें। आपके पास सामान्यीकरण समस्याएं _inside_ आपके आंकड़े तालिकाएं हो सकती हैं, लेकिन आपने खिलाड़ियों और आंकड़ों के बीच संबंधों का सही ढंग से मॉडल किया है। –

+0

@ स्टीवन, मैं मानता हूं कि पिचर्स बल्ले (एनएल में और इंटरलीग प्ले में), लेकिन यह एक फंतासी बेसबॉल ड्राफ्ट टूल के लिए है और पिचर्स के बल्लेबाजी आंकड़े गिनते नहीं हैं। –

उत्तर

6

PlayerId दोनों BattingStats और PitchingStats टेबल

में एक विदेशी कुंजी होगा [और कुछ समय के आयाम डाल करने के लिए याद (मौसम, साल, एट अल) आँकड़े तालिकाओं में]

और वैसे, यह एक बुरी धारणा है: जहां तक ​​मुझे पता है, पिचर्स को बल्लेबाजी करने की भी अनुमति है!

2

क्या आपको वास्तव में 3 से अधिक टेबल का उपयोग करने की आवश्यकता नहीं है। Normalization आमतौर पर कई सामान्यीकृत संबंधों में एक गैर-सामान्यीकृत मॉडल को तोड़ने का तात्पर्य है।

आप अधिक से अधिक 3 टेबल हो सकता है, तो आपको निम्न (3NF में) पर विचार करना चाहते हो सकता है:

[] में
Players:  ([player_id], name, date_of_birth, ...) 
Batters:  ([batter_id], player_id) 
Pitchers:  ([pitcher_id], player_id) 
Batting_Stats: ([batter_id, time_dimension], stat_1, stat_2, ...) 
Pitching_Stats: ([pitcher_id, time_dimension], stat_1, stat_2, ...) 

गुण प्राथमिक कुंजी को परिभाषित है, लेकिन अगर वरीय एक surrogate key इस्तेमाल किया जा सकता है। बैटर और पिचों में player_id विशेषता unique constraint होनी चाहिए, और यह खिलाड़ियों के संबंध में foreign key भी होना चाहिए। बैटिंग_स्टैट्स और पिचिंग_स्टैट्स क्रमशः बैटर और पिचिंग के लिए एक विदेशी कुंजी भी होनी चाहिए।

नोट तथापि ऊपर लागू नहीं करता है कि है कि एक खिलाड़ी केवल एक बल्लेबाज या केवल एक घड़ा हो सकता है।


अद्यतन:

एक विधि मैं, लागू करने के लिए है कि एक खिलाड़ी केवल एक बल्लेबाज या केवल एक घड़ा है के बारे में पता कर रहा हूँ इस मॉडल के माध्यम से है:

Players:  ([player_id], name, date_of_birth, ...) 
Roles:   ([role_id, role_type], player_id) 
Batting_Stats: ([role_id, role_type, time_dimension], stat_1, stat_2, ...) 
Pitching_Stats: ([role_id, role_type, time_dimension], stat_1, stat_2, ...) 

role_type चाहिए एक पिचर या बल्लेबाज को परिभाषित करें। Batting_Stats और Pitching_Stats में (role_id, role_type) का उपयोग करके भूमिकाओं के लिए एक समग्र विदेशी कुंजी होनी चाहिए। भूमिकाओं में player_id पर एक अनूठी बाधा यह सुनिश्चित करेगी कि एक खिलाड़ी के पास केवल एक ही हो, और केवल एक ही भूमिका हो। अंत में check constraints जोड़ें ताकि Batting_Stats.role_type = 'Batter' और Pitching_Stats.role_type = 'Pitcher'। ये चेक बाधा गारंटी है कि बैटिंग_स्टैट हमेशा बल्लेबाज का वर्णन कर रहा है, और एक पिचर नोट करें। पिचिंग_स्टैट्स के लिए भी यही लागू होता है।

+0

यह मेरे लिए तुरंत स्पष्ट नहीं है कि बैटर और पिचर्स टेबल के सम्मिलन में डेटा मॉडल में सुधार होता है या इसे अधिक सामान्य बनाता है। उन तालिकाओं में केवल उस डेटा को दोहराना प्रतीत होता है जो मौजूद होगा यदि प्लेयर_आईडी सीधे बैटिंग_स्टैट्स और पिचिंग_स्टैट टेबल में उपयोग किया गया था। –

+0

@ लैरी: वे टेबल बल्लेबाजों के सेट और "खिलाड़ियों पूल" से पिचर्स के सेट को परिभाषित करते हैं। वह * नई जानकारी है। फिर बल्लेबाजी आंकड़े केवल "बल्लेबाजी सेट" से एक खिलाड़ी को संदर्भित कर सकते हैं, और पिचिंग के लिए भी यही कर सकते हैं। –

+0

लेकिन यह वही सटीक जानकारी Batting_Stats और Pitching_Stats में player_id कॉलम की जांच करके उपलब्ध होगी। मुझे एक अतिरिक्त मामला दिखाई देता है जो आपके डिजाइन द्वारा संभाला जाता है, हालांकि - किसी भी आंकड़े की अनुपस्थिति में किसी खिलाड़ी की भूमिका को परिभाषित करना। यदि यह आवश्यक है तो अतिरिक्त टेबल उस आवश्यकता को पूरा करेंगे (जैसा कि खिलाड़ियों में एक अतिरिक्त भूमिका_ प्रकार कॉलम होगा)। –

1

मुझे पता है कि मैं इसे एक व्यावहारिक परिप्रेक्ष्य से कैसे कार्यान्वित करूंगा (मैं विवादित टेबल पर एक यूनियन दृश्य बनाउंगा और प्लेयर आईडी पर एक अद्वितीय अनुक्रमणिका डालूंगा - इसलिए, वे केवल एक तालिका में दिखाई दे सकते हैं)।

या खिलाड़ियों की मेज, रिकॉर्ड में आंकड़े वे है, और फिर शामिल है कि किस प्रकार आँकड़े तालिकाओं से FK संबंध में।

लेकिन इनमें से कोई भी संभवतः धातु की तुलना में धातु के करीब है।