Estensione della cattura SQL


20

Secondo Immerman , la classe di complessità associata alle query SQL è esattamente la classe delle query sicure in Q(FO(COUNT)) (query del primo ordine più operatore di conteggio): SQL acquisisce query sicure. (In altre parole, tutte le query SQL presentano una complessità in Q(FO(COUNT)) e tutti i problemi in Q(FO(COUNT)) può essere espresso come una query SQL.)

Sulla base di questo risultato, dal punto di vista teorico, ci sono molti problemi interessanti che possono essere risolti in modo efficiente ma non sono esprimibili in SQL. Pertanto un'estensione di SQL che è ancora efficiente sembra interessante. Quindi questa è la mia domanda:

Esiste un'estensione di SQL (implementata e utilizzata nel settore ) che acquisisce P (ovvero può esprimere tutte le query calcolabili in tempo polinomiale e nessun altro)?

Voglio un linguaggio di query del database che risolva tutte e tre le condizioni. È semplice definire un prolungamento che estenderebbe SQL e catturerà P . Ma la mia domanda è se un tale linguaggio ha senso dal punto di vista pratico, quindi voglio un linguaggio che viene utilizzato nella pratica. Se questo non è il caso e non esiste un linguaggio del genere, allora vorrei sapere se esiste una ragione che rende tale linguaggio poco interessante dal punto di vista pratico? Ad esempio, le domande che sorgono nella pratica di solito sono abbastanza semplici da non rendere necessaria una lingua simile?


1
@JD, scusa, ma in base al tuo commento penso che tu non capisca la domanda. La domanda è ben definita. Catturare una classe di complessità da una lingua è una terminologia standard. (Ciò che non è ben definito è la mia preferenza che la lingua dovrebbe essere una lingua di query, ma questa è solo una preferenza e ti ho detto che starei bene con uno che non lo è se non ce n'è uno con quella preferenza.)
Kaveh,

1
@ Shog9, ho già risposto a questo. JD non capisce la domanda, non sapeva nemmeno cosa significhi catturare e non è consapevole del fatto che un linguaggio che cattura P non può essere Turing completo per definizione. Si aspetta che sia affermato nel modo in cui gli piace, l'ho affermato nella solita terminologia descrittiva della complessità e nella complessità dei linguaggi di query, e gliel'ho persino spiegato. Cosa non è chiaro qui?
Kaveh,

1
@ Shog9, la motivazione deriva dalla complessità descrittiva . Sto cercando di vedere se esiste un linguaggio che estende SQL utilizzato nel settore che cattura P. Il linguaggio SQL originale è piuttosto debole, come mostrano i risultati di Immermann, dal punto di vista teorico è impossibile stabilire molti calcoli efficienti. D'altra parte vorremmo mantenere il linguaggio efficiente (ad es. ). Esiste una lingua simile? (Penso che questi siano probabilmente chiari per le persone che hanno familiarità con la complessità descrittiva). P
Kaveh,

4
@ Shog9: non riesco a capire perché questa domanda necessitasse di un intervento da moderatore ed è stata chiusa. Sono abbastanza a mio agio con la complessità descrittiva da dire che questa è una vera domanda (anche se forse più adatta per TCS - è un po 'una domanda difficile).
Alex ten Brink,

1
Come ho notato anche un'altra domanda chiusa (che aveva anche voti stretti), ho fatto una domanda su meta al riguardo: meta.cs.stackexchange.com/questions/97/…
Alex ten Brink

Risposte:


5

Per quanto riguarda la tua domanda principale, ti consiglio questo breve sondaggio di Martin Grohe.


Le domande che sono necessarie nella pratica di solito sono abbastanza semplici da non richiedere un linguaggio più forte?

Direi che questo vale la maggior parte del tempo, data la giusta quantità di estensioni aggiunte ai linguaggi di query comuni (chiusura transitiva, operatori aritmetici, conteggio, ecc.). Questo deriva dal punto di vista di qualcuno che ha svolto un lavoro come sviluppatore freelance di siti Web e altre applicazioni relativamente semplici, quindi non sono sicuro degli usi reali di SQL in settori più grandi / database più grandi.

In rari casi potrebbe essere necessario un linguaggio più potente, suppongo che gli sviluppatori di software li gestiscano utilizzando il linguaggio in cui scrivono l'applicazione, non le query (come C ++ o Java).


3

Innanzitutto, la potenza espressiva di SQL è meno chiara di quanto sembri. Le caratteristiche aggregate, di raggruppamento e aritmetiche di SQL risultano avere effetti piuttosto sottili. A priori, sembra fattibile che con una certa codifica di operatori algebrici che utilizzano queste funzionalità, si possa effettivamente esprimere la raggiungibilità in SQL. Si scopre che questo non è in realtà il caso di SQL-92 , che è "locale".

Ciò significa che è necessaria un'estensione per l'acquisizione di PTIME da parte di SQL-92 e una che consente alla lingua risultante di essere "non locale".

TC0NLOGSPACE

Quindi il panorama è cambiato di nuovo, dal momento che SQL: 1999 (SQL3) includeva la ricorsione. Quindi SQL: 1999 sembra essere almeno espressivo quanto la logica a virgola fissa con il conteggio (anche se penso che i dettagli potrebbero di nuovo essere piuttosto complicati, incluso il problema dell'ordine). Non so se i nuovi costrutti rendessero la logica più espressiva di quanto sia necessario per catturare PTIME, e per stabilire questo sarebbe necessario uno studio. Nel frattempo, nel 2003 , 2006 , 2008 e 2011 sono state apportate ulteriori revisioni(essendo documenti ISO, solo le bozze sono disponibili gratuitamente). Queste revisioni hanno aggiunto tutta una serie di nuove funzionalità, incluso il consentire a XQuery di essere "parte" delle query SQL. La mia ipotesi è che "SQL" ora sia più espressivo di quanto sia necessario per acquisire PTIME, ma che la codifica richiesta per fare ciò potrebbe richiedere query grandi e piuttosto non naturali che potrebbero non essere supportate nei sistemi reali.

Quindi penso che ci siano prove che non esiste un'estensione industriale di SQL che catturi precisamente PTIME , rispondendo alla tua domanda in modo confuso. In breve, le estensioni industriali sono piuttosto potenti e potrebbero già aver superato il PTIME. Se è vero che SQL: 1999 è già abbastanza potente da catturare almeno PTIME, allora non è anche chiaro cosa significhi veramente "SQL" nella tua domanda, dal momento che si dovrebbe definire "SQL" per indicare una versione precedente a SQL: 1999.

Infine, l'indagine di Grohe sulla ricerca di logiche che catturano PTIME (menzionata anche da Janoma) indica non solo che catturare PTIME è complicato a meno che non abbiamo un ordine lineare come parte del linguaggio, ma che una prova che non potrebbe esserci una tale logica sarebbe anche implica .PNP


Grazie András, soprattutto per aver menzionato il fatto che SQL3 supporta la "ricorsione", devo controllare e vedere cosa si sa al riguardo. :)
Kaveh,

ps: suppongo che tu abbia incluso la discussione sulla relazione con la teoria della complessità e la logica catturando P per i lettori, tuttavia lasciami aggiungere come nota a margine e per chiarimenti: sto usando SQL nel senso che Immerman lo ha usato nel risultato e che risultato utilizza una definizione precisa di SQL. Conosco le relazioni con le separazioni delle classi di complessità e la domanda di una logica che cattura P, tuttavia non credo che abbiano effetto sulla risposta alla mia domanda,
Kaveh,

la risposta alla mia domanda può essere positiva (o negativa) e sarebbero coerenti con tutte le possibili risposte a P vs. NP e l'esistenza di una logica invariante ordine per P.
Kaveh,

Kaveh, se definisci SQL come ha fatto Immerman, allora penso che la risposta sia "probabilmente no", dal momento che le estensioni industriali esistenti sembrano essere troppo deboli o troppo potenti. Ma (AFAIK) non abbiamo prove rigorose per questo. Forse un sottoinsieme delle estensioni cattura esattamente il PTIME, ma non sono sicuro di voler esplorare le specifiche cercando di isolarlo ...
András Salamon,

-1

La tua domanda non è abbastanza chiaro, se si desidera un'estensione che cattura e solo o se si catturano e possibilmente cose al di fuori . Sembra che tu sia interessante solo nella classe esatta , dal momento che vuoi query sicure e, in caso contrario, qualsiasi estensione di SQL completa di Turing farebbe.P P P PPPPPP

Non sappiamo se . Se , un'estensione SQL in grado di catturare e solo dovrebbe essere in grado di calcolare se una formula booleana è soddisfacente in tempo polinomiale o risolvere qualsiasi altro problema in tempo polinomiale.P = N P P P N P CP=NPP=NPPPNPC

Ma, se , il linguaggio con estensione SQL non sarà in grado di calcolare se una determinata formula booleana è soddisfacente.PNP

Quindi, abbiamo una domanda: esistono e algoritmi (o query, o altro) scritti in un linguaggio del genere in grado di decidere se una formula booleana è soddisfacente? Non posso rispondere a questo (e probabilmente nessuno qui può, poiché rispondere a questo è rispondere se ). Questa domanda mi fa credere che è molto improbabile che questo linguaggio esista per scopi reali.P=NP

Sebbene probabilmente non esista per scopi reali, esiste sicuramente ed è costruibile e implementabile. Potresti definire quel linguaggio con qualcosa in grado di simulare una macchina di Turing fino a un dato numero unario di passi. IE, in grado di risolvere un problema P-complete . Tuttavia, se costruisci una cosa del genere, è quasi completo di Turing, tranne per la restrizione "dato un numero unario di passaggi", che in un linguaggio simile a SQL sarebbe un modo molto strano di limitarlo solo a query sicure. Potresti farlo se i passaggi sono record di una tabella, ma questo non sembra ancora prezioso per scopi pratici.


2
quando diciamo che cattura una classe di complessità intendiamo esattamente quella classe di complessità. Ad esempio diciamo che language cattura la classe di complessità . A C 0FOAC0
Kaveh

1
Inoltre non vedo la relazione di contro alla mia domanda. Sappiamo già che ci sono lingue che catturano , ad esempio (che comunque non è completo di Turing). Quello che sto chiedendo è se esiste un linguaggio che estende SQL catturando che viene utilizzato nel settore e voglio che tutti questi siano soddisfatti (o una spiegazione del perché tale linguaggio non è interessante dal punto di vista industriale) . P P F O ( L F P ) PNPPPFO(LFP)P
Kaveh,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.