28

डेटाबेस प्रोग्रामिंग में "सामान्यीकरण" नामक एक तकनीक है जिसे आप उस डेटा पर संग्रहीत करते हैं जिसे आप स्टोर करना चाहते हैं।

क्या किसी ने इस अवधारणा को ऑब्जेक्ट डिज़ाइन पर लागू करने की कोशिश की है? तुमने कैसे किया? काम कैसे बना?

संपादित करें: विस्तार / स्पष्ट करने के लिए, डेटाबेस सामान्यीकरण अतिरेक को कम करने के लिए सिद्धांतों के एक सेट से अधिक है। वास्तव में ऐसे चरण और चरण हैं जिनसे आप गुजरते हैं और कम से कम मध्यम उद्देश्य वाले उपाय हैं जो आपको बताते हैं कि आप किस चरण में हैं। ऑब्जेक्ट डिज़ाइन के अपने सिद्धांत हैं, और गंध की अवधारणा है, लेकिन क्या ऐसा कुछ करने का कोई तरीका है जो आपको बताएगा। कि आप XX-form0,1,2 में हैं ... आदि ... और तरीकों को अगले सबसे "सामान्यीकृत" स्तर पर ले जाने के लिए?

design

— एडवर्ड स्ट्रेंज
स्रोत

2

... आपका मतलब है कि हमने अपनी कक्षाओं में कई निरर्थक चर नहीं होने की कोशिश की है, और हमारी परियोजनाओं में कई निरर्थक वर्ग नहीं हैं? क्या वह भी काम करेगा?

— शैतानिकपुपी

2

@Steven A. Lowe: जब आप पांच साल पहले मेरे मास्टर थीसिस के विषय पर निर्णय ले रहे थे तो आप कहां थे? ;)

मैंने कभी इसकी कोशिश नहीं की है (यही कारण है कि मैं एक टिप्पणी के रूप में जवाब दे रहा हूं) लेकिन मैं अनुमान लगा रहा हूं कि आप ऐसा साझा डेटा के कैश के साथ कर सकते हैं, ऑब्जेक्ट से कैश्ड साझा डेटा तक पॉइंटर्स, और किसी प्रकार की निर्भरता इंजेक्शन तंत्र साझा डेटा के उदाहरणों को इंगित करने के लिए ...

— FrustratedWithFormsDesigner

एक बहुत ही दिलचस्प सवाल मुझे लगता है।

5

मुझे लगता है कि रिफैक्टिंग बहुत अधिक कवर करता है जो ओओपी और अन्य प्रोग्रामिंग विधियों के लिए है।

— JohnFx

27

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

दूसरे शब्दों में, क्या किसी ने OOP के लिए डेटाबेस सामान्यीकरण तकनीकों को लागू करने की कोशिश की है? नहीं, क्योंकि OOP में पहले से ही साझा समस्याओं के समाधान हैं जो सामान्यीकरण रिलेशनल डेटाबेस के लिए हल करता है।

— रीन हेनरिक्स
स्रोत

+1 जो मैं लिखना चाह रहा था, उससे कहीं बेहतर!

— K पर माइकल के

वे सिद्धांत हैं, हालांकि तकनीक नहीं। आप ऑब्जेक्ट डिज़ाइन को "सामान्यीकृत" करने के लिए उन सिद्धांतों का उपयोग कैसे करेंगे?

— एडवर्ड स्ट्रेंज

3

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

— रीन हेनरिच्स

5

@ क्रेजी एडी: आप इसे रिलेशनल डेटाबेस के साथ कैसे करते हैं? आप ऐसे उदाहरणों की तलाश करते हैं जहां एक प्रिंसिपल का उल्लंघन किया जाता है और इसे सही करता है। यदि आप एक वर्ग को तीन नौकरियों के साथ देखते हैं, तो आप इसे तीन वर्गों के रूप में लिखते हैं। यदि आप "सामान्यीकरण" जैसी क्रिया की तलाश कर रहे हैं, तो शायद इसका "रिफ्लेक्टर" हालांकि यह उतना विशिष्ट नहीं है जितना कि यह समावेशी है।

— जेरेमी

1

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

— स्टीवन ए। लोव

18

हाँ, हाँ मेरे पास है

मैं इस विषय पर लंबे समय तक चुप रहा हूं; यह बोलने का समय है।

क्या किसी ने इस अवधारणा को ऑब्जेक्ट डिज़ाइन पर लागू करने की कोशिश की है?

हाँ। मैं 20 वर्षों से वस्तु सामान्यीकरण (और इसलिए अंतर्निहित वस्तु उन्मुख सिद्धांत) को औपचारिक रूप देने पर काम कर रहा हूं।

तुमने कैसे किया?

यह महसूस करके कि डेटा और कोड विनिमेय हैं, कम से कम सिद्धांत में। इसका मतलब है कि सामान्यीकरण और संबंधपरक संचालन के सिद्धांत कोड के साथ-साथ डेटा पर भी लागू हो सकते हैं।

काम कैसे बना?

यह अब तक बहुत अच्छी तरह से काम किया - मेरा मानना है कि प्राप्त अंतर्दृष्टि मेरे डिजाइन, विश्लेषण, और रीफैक्टरिंग क्षमताओं के "गुप्त हथियार" हैं।

मैंने इससे पहले सार्वजनिक रूप से इसके बारे में कुछ नहीं कहा है क्योंकि मुझे लगा कि अंततः मेरे पास शोध को समाप्त करने का समय होगा - और निहित उपकरणों का उत्पादन करूंगा।

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

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

इस क्षेत्र में कुछ दिलचस्प शोध हुए हैं, लेकिन यह सब - कि मैं इससे अवगत हूँ - निशान से कम हो गया है। या तो यह गलत तरीके से माना जाता है कि क्योंकि सामान्यीकरण एक संबंधपरक पृष्ठभूमि से आता है जो वस्तु-उन्मुख मॉडल पर लागू नहीं होता है, या यह मानता है कि सामान्यीकरण केवल वस्तुओं द्वारा परिभाषित डेटा पर लागू होता है। हालांकि, कुछ बहुत ही नज़दीकी मिस प्रोजेक्ट हैं ...

वास्तव में दिलचस्प सामान तब होता है जब आप कोड के लिए सामान्यीकरण लागू करते हैं - जो मैं तर्क देता हूं कि सभी रिफैक्टिंग की नींव है ।

तो अब मैं सोच रहा हूं कि सबसे अच्छी बात यह है कि इस शब्द को बाहर निकालने के लिए, शायद डीसी में देवदास 2011 में बोलने के लिए कहें, और पता करें कि क्या कोई समुदाय इस सामान से उत्साहित है जैसे मैं हूं।

यहां एक चुपके झलक है: सामान्यीकरण कुछ न्यूनतम और गैर-अनावश्यक बनाने की प्रक्रिया है। ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग का डोंट रिपीट योरसेल्फ (DRY) सिद्धांत इसलिए सामान्यीकरण के लक्ष्यों की स्पष्ट अभिव्यक्ति है। मेरा मानना है कि मैं यह दिखा सकता हूं कि सभी प्रसिद्ध वस्तु उन्मुख डिजाइन / प्रोग्रामिंग / रीफैक्टरिंग सिद्धांत ऑब्जेक्ट सामान्यीकरण के तार्किक परिणाम हैं। मुझे लगता है कि मैं यह भी दिखा सकता हूं कि केवल रीफैक्टरिंग की तुलना में ऑब्जेक्ट नॉर्मल फॉर्म (ONF) में अधिक दिलचस्प चीजें हैं जो सिस्टम के साथ की जा सकती हैं।

— स्टीवन ए लोव
स्रोत

1

कोई और पर्याप्त दस्तावेज?

— स्टीव 314

4

प्रकाशित! (कृपया?) (सुंदर कृपया?) यदि आपको डॉक्स प्राप्त करने में कोई मदद चाहिए, आदि।

— एजे 01

1

@ChrisCirefice: steven.lowe@nov8r.com पर, मुझे गोली मार एक ईमेल के लिए खुश हो

— स्टीवन ए लोव

1

@ क्रिसहाइरिसफाइस: सिर्फ एफवाईआई, पीएचडी उम्मीदवार एक अलग विश्वविद्यालय में चले गए; बैक-बर्नर पर फिर से प्रोजेक्ट करें (लेकिन मैं DDD पर एक किताब लिख रहा हूं)

— स्टीवन ए। लोवे

1

हाय @ StevenA.Lowe मैं वास्तव में अपने अनुसंधान में दिलचस्पी रहा हूँ। मैंने एक छोटा पेपर एन्क्रिप्ट किया हुआ पाया है। क्या आपके पास इस पर कोई टिप्पणी है? BTW, हो सकता है कि आप पहले एक ब्लॉग पोस्ट लिखकर अपने विचार को थोड़ा और समझ सकें? धन्यवाद।

— वी किउ

5

यह रेन हेनरिक के उत्कृष्ट उत्तर पर एक टिप्पणी के रूप में शुरू हुआ , लेकिन बहुत लंबा हो गया ...

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

ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग डेटा पर संचालन पर लागू होता है। यह डेटा में हेरफेर करने के तरीकों को एक साथ समूहित करने के लिए है। आप डुप्लिकेट तरीकों को खत्म करने के लिए कक्षाओं में अनुकरणीय तकनीकों को लागू कर सकते हैं, शायद यह देखकर कि ऑपरेशन किस डेटा में हेरफेर करता है या निर्भर करता है। उदाहरण के लिए, OO के परिप्रेक्ष्य में 1NF में किसी वर्ग के भीतर कोई डुप्लिकेट कार्रवाई नहीं होगी। 3NF एक अच्छी विरासत संरचना के साथ मेल खा सकता है जिसमें आमतौर पर इस्तेमाल किया जाने वाला कोड सुपरक्लास में होता है। मुझे यकीन है कि आपको वहां भी निर्भरता इंजेक्शन फिट करने के लिए जगह मिल सकती है। आप अच्छे डिज़ाइन सिद्धांतों के उल्लंघन का पता लगाने और फिर से तैयार करने के द्वारा एक बेहतर डिज़ाइन तक पहुँचते हैं (हालाँकि सामान्य रूपों जैसा कुछ भी अभी तक खोजा नहीं गया है)।

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

— माइकल के
स्रोत

2

मेरा विचार है कि सिद्धांत तनाव के एक समूह को हल करने के आदर्श तरीके के बारे में एक बयान है। एक सिद्धांत को लागू करने के लिए पैटर्न एक अनुमानी है। IOW सिद्धांत समस्या स्थान की संरचना के बारे में एक बयान है और पैटर्न उन्हें समाधान स्थान में बदलने के लिए नियम हैं। लेकिन मैं एक गणित अखरोट की तरह हूं, इसलिए मुझे अजीब लगता है :)

— रीन हेनरिक्स

2

व्यवसाय मॉडल वस्तुओं को डिजाइन करने के लिए एक बहुत अच्छा तरीका जो सामान्यीकरण के समान है, वह है यूएमएल मॉडलिंग इन कलर ।

यह पीटर कॉड द्वारा पाया गया एक डिजाइन रणनीति है जो व्यापार मॉडल वस्तुओं को अमूर्त करने में मदद करता है।

दुर्भाग्य से पुस्तक - जावा मॉडलिंग इन कलर विद यूएमएल: एंटरप्राइज कंपोनेंट्स एंड प्रोसेस - बेची गई है और आप केवल उपयोग किए गए खरीद सकते हैं।

इस तकनीक के बारे में इंटरनेट पर कुछ लेख हैं।

यदि आप संबंधपरक डिज़ाइन से परिचित हैं, तो आपको गाइड करने के लिए यूएमएल मॉडलिंग इन कलर उपयोगी होगा:

पीटर कोएड की 'मॉडलिंग इन कलर' - नोट्स स्टीफन आर पामर द्वारा

— लुकास मचाडो
स्रोत

0

क्या आपने क्लास डायग्राम बनाते समय अपने कोड में ORM जावा एनोटेशन का उपयोग करने के लिए जांच की है? एक बार मॉडलिंग चरण समाप्त होने के बाद हाइबरनेट डेटाबेस उत्पन्न करेगा। आरेख इस उदाहरण में केवल कोड का एक दर्शक है।

— UML_GURU
स्रोत

0

ऑब्जेक्ट संदर्भ या संकेत विदेशी कुंजियों के समान हैं। यह उतना ही गहरा है जितना मैं इस पर सोचने को तैयार हूं। :)

वास्तव में मैं गहराई से सोचूंगा। यदि आप अपनी वस्तुओं को 0 डेटा दोहराव के साथ मॉडल करते हैं और अपनी वस्तुओं को "क्वेरी" कर सकते हैं और उन पर सेट आधारित अपडेट कर सकते हैं तो कोई डिस्कनेक्ट नहीं होगा। वास्तव में आप एक वस्तु उपभोक्ता पुस्तकालय बनाकर ऐसा कर सकते हैं। Microsoft पहले से ही इस के बावजूद पहले से ही एक "क्वेरी लाइब्रेरी" पर C # के सेट-आधारित LINQ सिंटैक्स भाग बनाने की दिशा में चला गया।

— जोजो
स्रोत

ऑब्जेक्ट ओरिएंटेड "सामान्यीकरण"

हाँ, हाँ मेरे पास है