SQL कैप्चरिंग का विस्तार

Question

इम्मेरमैन के अनुसार , एसक्यूएल प्रश्नों से जुड़ी जटिलता वर्ग बिल्कुल ही (फर्स्ट-ऑर्डर क्वेरीज़ प्लस काउंटिंग ऑपरेटर) में सुरक्षित क्वेरीज़ की क्लास है : एसक्यूएल सुरक्षित क्वेरीज़ को कैप्चर करता है। (दूसरे शब्दों में, सभी एसक्यूएल प्रश्नों में एक जटिलता है , और में सभी समस्याओं एक SQL क्वेरी के रूप में व्यक्त किया जा सकता है।)$\mathsf{Q(FO(COUNT))}$$\mathsf{Q(FO(COUNT))}$$\mathsf{Q(FO(COUNT))}$

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

क्या SQL ( उद्योग में कार्यान्वित और उपयोग किया जाता है ) का एक विस्तार है, जो कैप्चर करता है$\mathsf{P}$ (यानी सभी बहुपद-काल कम्प्यूटेशनल प्रश्नों और अन्य को व्यक्त नहीं कर सकता है)?

मुझे एक डेटाबेस क्वेरी भाषा चाहिए जो तीनों स्थितियों को पूरा करती है। एक विस्तार को परिभाषित करना आसान है जो एसक्यूएल का विस्तार करेगा और पर कब्जा करेगा $\mathsf{P}$। लेकिन मेरा प्रश्न यह है कि अगर ऐसी भाषा व्यावहारिक दृष्टिकोण से समझ में आती है, तो मैं एक ऐसी भाषा चाहता हूं जो व्यवहार में उपयोग की जा रही हो। यदि यह मामला नहीं है और ऐसी कोई भाषा नहीं है, तो मैं जानना चाहूंगा कि क्या कोई कारण है जो ऐसी भाषा को व्यावहारिक दृष्टिकोण से अप्रभावित बनाता है? उदाहरण के लिए, क्या ऐसी प्रथाएँ प्रचलित हैं जो आमतौर पर इतनी सरल होती हैं कि ऐसी भाषा की कोई आवश्यकता नहीं है?

Comments

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

— केव

@ शोग 9, मैंने पहले ही इसका जवाब दे दिया है। जेडी इस सवाल को नहीं समझता है, उसे यह भी नहीं पता था कि कैप्चर का क्या मतलब है और इस बात की जानकारी नहीं है कि पी कैप्चरिंग वाली भाषा को परिभाषा के अनुसार पूरा नहीं किया जा सकता है। वह अपेक्षा करता है कि इसे जिस तरह से वह पसंद करता है, उसमें कहा जाए, मैंने इसे सामान्य वर्णनात्मक जटिलता शब्दावली और क्वेरी भाषाओं की जटिलता में कहा है, और यहां तक ​​कि उन्हें ये समझाया भी है। यहाँ क्या स्पष्ट नहीं है?

— केव

@ शोग 9, प्रेरणा वर्णनात्मक जटिलता से आ रही है । मैं यह देखने की कोशिश कर रहा हूं कि क्या इंडस्ट्री में एसक्यूएल फैली हुई कोई भाषा है जो पी को कैप्चर करती है। मूल एसक्यूएल भाषा इमर्मन के रिजल्ट शो की तरह कमजोर है, सैद्धांतिक दृष्टिकोण से कई कुशल संगणनाएँ इसमें बताई गई हैं। दूसरी ओर हम भाषा को कुशल (यानी ) रखना चाहेंगे । क्या ऐसी कोई भाषा है? (मुझे लगता है कि ये वर्णनात्मक जटिलता से परिचित लोगों के लिए संभवतः स्पष्ट हैं)। $\mathsf{P}$

— केव

@ शोग 9: मैं यह देखने में विफल हूं कि इस प्रश्न के लिए मध्यस्थ के हस्तक्षेप की आवश्यकता क्यों थी और इसे बंद कर दिया गया था। मैं कहने के लिए वर्णनात्मक जटिलता के साथ काफी सहज हूं कि यह एक वास्तविक प्रश्न है (हालांकि संभवतः टीसीएस के लिए बेहतर अनुकूल है - यह थोड़ा कठिन सवाल है)।

— एलेक्स दस ब्रिंक

जैसा कि मैंने देखा कि एक और प्रश्न भी बंद हो गया (जिसमें करीबी वोट भी थे), मैंने इसके बारे में मेटा पर एक सवाल पूछा: meta.cs.stackexchange.com/questions/97/…

— एलेक्स टेन ब्रिंक

Answer 1

आपके मुख्य प्रश्न के रूप में, मैं मार्टिन ग्रहे के इस लघु सर्वेक्षण की सिफारिश करता हूं ।

---

क्या अभ्यास में जिन प्रश्नों की आवश्यकता होती है, वे आमतौर पर सरल होते हैं कि एक मजबूत भाषा की कोई आवश्यकता नहीं है?

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

दुर्लभ मामलों में एक अधिक शक्तिशाली भाषा की आवश्यकता हो सकती है, मेरा अनुमान है कि सॉफ्टवेयर डेवलपर्स उस भाषा का उपयोग करके उनके साथ व्यवहार करते हैं जिसमें वे एप्लिकेशन लिखते हैं, न कि प्रश्नों (जैसे C ++ या जावा)।

Answer 2

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

• लियोनिद लिब्किन। एसक्यूएल , टीसीएस 296 (3), 379404 की अभिव्यंजक शक्ति। doi: 10.1016 / S0304-3975 (02) 00736-3 ( प्रीप्रिंट )

इसका मतलब है कि PTIME पर कब्जा करने के लिए SQL-92 के लिए एक एक्सटेंशन की आवश्यकता है, और एक जो परिणामस्वरूप भाषा को "गैर-स्थानीय" होने की अनुमति देता है।

हालाँकि, आदेशित संरचनाओं की अनुमति देना और वास्तविक रूप से सीमित अंकगणित के साथ, यह साबित करना कि SQL-92 पुनर्संयकता को व्यक्त नहीं कर सकता है कि वर्दी और इसलिए काफी मुश्किल होने की संभावना है। (यह तर्क दिया जा सकता है कि SQL-92 में डेटा प्रकारों पर एक प्राकृतिक रैखिक क्रम हमेशा मौजूद होता है, और इसलिए कोई यह मान सकता है कि अंतर्निहित संरचनाएं आदेशित हैं।)$\text{TC}^0 \subsetneq \text{NLOGSPACE}$

तब परिदृश्य फिर से बदल गया, क्योंकि SQL: 1999 (SQL3) में पुनरावर्तन शामिल था। तो एसक्यूएल: 1999 कम से कम लगता है कि गिनती के साथ फिक्स्ड-पॉइंट लॉजिक के रूप में स्पष्ट है (हालांकि मुझे लगता है कि विवरण फिर से मुश्किल हो सकता है, जिसमें ऑर्डर का मुद्दा भी शामिल है)। चाहे नए निर्माणों ने तर्कशास्त्र को अधिक अभिव्यंजक बनाया हो, पीटीआईईएम को पकड़ने के लिए आवश्यक है, मुझे नहीं पता, और इसे स्थापित करने के लिए कुछ अध्ययन की आवश्यकता होगी। इस बीच, 2003 , 2006 , 2008 और 2011 में और संशोधन किए गए(आईएसओ दस्तावेज होने के नाते, केवल ड्राफ्ट स्वतंत्र रूप से उपलब्ध हैं)। इन संशोधनों में नई सुविधाओं का एक पूरा जोड़ा गया, जिसमें XQuery को SQL प्रश्नों का "भाग" के रूप में अनुमति दी गई। मेरा अनुमान है कि "SQL" अब PTIME पर कब्जा करने के लिए आवश्यकता से अधिक अभिव्यंजक है, लेकिन ऐसा करने के लिए आवश्यक एन्कोडिंग के लिए बड़े और बल्कि गैर-स्वाभाविक प्रश्नों की आवश्यकता हो सकती है जो वास्तविक सिस्टम में समर्थित नहीं हो सकते हैं।

इसलिए मुझे लगता है कि इस बात का सबूत है कि एसक्यूएल का कोई औद्योगिक विस्तार नहीं है जो पीटीईएम को ठीक से पकड़ लेता है , आपके प्रश्न का उत्तर फ़र्ज़ी तरीके से देता है। संक्षेप में, औद्योगिक विस्तार बल्कि शक्तिशाली हैं और पहले से ही पीटीटाइम की देखरेख कर सकते हैं। यदि यह सच है कि SQL: 1999 पहले से ही कम से कम PTIME को पकड़ने के लिए पर्याप्त शक्तिशाली है, तो यह भी स्पष्ट नहीं है कि आपके प्रश्न में "SQL" का वास्तव में क्या मतलब है, क्योंकि किसी को SQL से पूर्ववर्ती संस्करण के लिए "SQL" को परिभाषित करना होगा: 1999।

अंत में, पीटीआईईएम पर कब्जा करने वाले लॉजिक्स (जोनोमा द्वारा भी उल्लेख किया गया है) की खोज पर ग्रोह का सर्वेक्षण न केवल इंगित करता है कि पीटीआईएम पर कब्जा तब तक मुश्किल है जब तक कि हमारे पास भाषा के हिस्से के रूप में एक रैखिक आदेश नहीं है, लेकिन यह एक प्रमाण है कि ऐसा कोई तर्क भी नहीं हो सकता है। imply ।$\text{P} \ne \text{NP}$

• मार्टिन ग्रोह , पीटीआईईएम, LICS 2008, 267-271 पर कब्जा करने वाले एक तर्क की खोज । डोई: 10.1109 / LICS.2008.11 ( प्रीप्रिंट )

Comments

धन्यवाद एंड्रस, विशेष रूप से यह उल्लेख करने के लिए कि एसक्यू 3 "पुनरावृत्ति" का समर्थन करता है, मुझे यह देखना और देखना होगा कि इसके बारे में क्या ज्ञात है। :)

— केवह

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

— केवह

मेरे प्रश्न का उत्तर सकारात्मक (या नकारात्मक) हो सकता है और वे पी बनाम एनपी के सभी संभावित उत्तरों और पी। के लिए ऑर्डर-इनवेरियंट लॉजिक के अस्तित्व के अनुरूप होंगे

— केवह

Kaveh, यदि आप SQL को Immerman के रूप में परिभाषित करते हैं, तो मुझे लगता है कि इसका उत्तर "शायद नहीं" है, क्योंकि मौजूदा औद्योगिक एक्सटेंशन या तो बहुत कमजोर या बहुत शक्तिशाली प्रतीत होते हैं। लेकिन (AFAIK) हमारे पास इसके लिए कोई कठोर प्रमाण नहीं है। संभवतः एक्सटेंशन के कुछ सबसेट ठीक PTIME कैप्चर करता है, लेकिन मैं नहीं कर रहा हूँ यकीन है कि मैं ... यह अलग करने के लिए कोशिश कर रहा चश्मा के माध्यम से ट्राउल करना चाहते हैं

— एंड्रास सालेमन

Answer 3

$P$$P$$P$$P$$P$

$P = NP$$P = NP$$P$$P$$NPC$

$P \ne NP$

$P = NP$

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

Comments

$\mathsf{FO}$$\mathsf{AC^0}$

$\mathsf{NP}$$\mathsf{P}$$\mathsf{P}$$\mathsf{FO(LFP)}$$\mathsf{P}$