Perché SQL è noto come linguaggio basato sulle relazioni / funzionale?


14

Stiamo imparando che la maggior parte delle lingue sono classificate come una delle due, "basata sulle relazioni" o "di alto livello". Non ho mai usato SQL prima, ma dalla lettura della sua sintassi sembra più una sintassi imperativa / di alto livello che funzionale / basata sulle relazioni (Lisp, Haskell) ??

O potrebbe essere solo che la mia interpretazione degli appunti delle lezioni del mio professore sia sbagliata ... ma elenca sicuramente SQL come uno dei linguaggi basati sulle relazioni (al contrario di alto livello), ed equivale alla relazione basata sul funzionale ... o forse è che non capisco perché il fatto che SQL si occupi di database relazionali rende un linguaggio funzionale il modo in cui dovrebbe essere implementato? (e perché "basato sulle relazioni" equivale a "funzionale" quando si classificano i linguaggi di programmazione?)

Grazie :)

Risposte:


14

Stiamo imparando che la maggior parte delle lingue sono classificate come una delle due, "basata sulle relazioni" o "di alto livello".

Quei concetti sono ortogonali. "Basato su relazioni" significa che la semantica del linguaggio si basa sul concetto di una relazione, ovvero un'associazione molti-a-molti tra due insiemi (le relazioni sono la base matematica dietro le tabelle SQL). "Alto livello" significa che la lingua contiene molte astrazioni che nascondono gran parte dei dettagli tecnici sottostanti (come posizioni di memoria, registri della CPU, accesso al disco, operazioni bit a bit, ecc.). SQL è sicuramente basato sulle relazioni, poiché il suo scopo principale è quello di descrivere i dati relazionali e le operazioni su di esso. SQL è anche abbastanza alto livello; non fornisce alcun mezzo per accedere direttamente ai byte sul disco e non fornisce alcun dettaglio su come memorizza i suoi dati (almeno non lo standard SQL;

In effetti, ci sono molti più assi lungo i quali i linguaggi di programmazione (e dati) possono essere classificati; uno particolarmente interessante è dichiarativo contro imperativo . Linguaggi dichiarativi descrivono ciò che qualcosa è ; le lingue imperative descrivono come fare qualcosa. La parte DDL di SQL è in gran parte dichiarativa, nonostante le parole chiave imperativi di aspetto (" CREATE TABLE", ' DROP DATABASE', ecc), e anche la parte manipolazione dei dati ( SELECT, UPDATE, INSERT, DELETE) è ancora piuttosto dichiarativa. Una proprietà molto interessante di SQL è che non è Turing completo: non è possibile scrivere un ciclo illimitato in un normale ANSI SQL standard.

La programmazione funzionale è incentrata su alcune idee fondamentali:

  • le funzioni sono cittadini di prima classe (ovvero possono essere utilizzate come valori, come input per altre funzioni e come output da altre funzioni)
  • funzioni di ordine superiore (funzioni che operano su funzioni o funzioni che restituiscono funzioni)
  • purezza (una funzione pura è una che non ha effetti collaterali; una funzione pura non può fare alcun I / O, non può leggere né modificare alcuno stato globale e non può accettare argomenti di riferimento non costanti. Le funzioni pure sono particolarmente interessanti perché lo faranno produce sempre lo stesso output dati gli stessi input)

L'SQL certamente non ruota attorno alle funzioni come lo strumento principale per modellare le cose, ma abbraccia in qualche modo l'idea di purezza: la stessa query eseguita sullo stesso database produrrà lo stesso risultato ogni volta (tranne che per l'ordinamento). Chiamare SQL un linguaggio 'funzionale' è un po 'complicato attraverso IMO.


ANSI SQL è Turing completo. È possibile incorporare un sistema di tag ciclico utilizzando CTE (introdotto in SQL: 1999) e Windowing (SQL: 2003).
Jörg W Mittag,

@ JörgWMittag: potrebbe essere in grado di fare qualcosa di simile con i trigger ...
jmoreno

"Basato su relazioni significa che la semantica del linguaggio si basa sul concetto di una relazione, ovvero un'associazione molti-a-molti tra due insiemi (le relazioni sono la base matematica dietro le tabelle SQL)" - Una relazione, in un RDBMS , non è il "rapporto" set di dati beteen, è un insieme di tuple. Una tabella, una vista o il risultato di una query sono tutte "relazioni".
David Aldridge,

12

SQL non è indispensabile perché il processo di risoluzione delle query e delle relazioni non è definito dal programmatore, ma piuttosto dal compilatore / ottimizzatore / interprete. SQL è un linguaggio dichiarativo - In SQL, dichiari le relazioni. Questo crea una struttura di dati (che di nuovo non è definita fisicamente con la lingua ma dalla sua implementazione) usando inserimenti, aggiornamenti ed eliminazioni.

L'utilizzo delle relazioni viene quindi eseguito utilizzando query (istruzioni SELECT), che sono funzionali in quanto non hanno effetti collaterali.

Il tutto è avvolto attorno al modello relazionale .


Penso che tu possa fare un caso più forte. Le query sono insiemi, ma sono anche funzioni su insiemi. Le query sono oggetti di prima classe in sql (in particolare, è possibile nidificarli o denominarli)
nomen

5

SQL non è un linguaggio tanto funzionale quanto dichiarativo. I linguaggi funzionali, in generale, enfatizzano lo stile dichiarativo sull'imperativo per ridurre al minimo gli effetti collaterali. Questo potrebbe portare alcune persone a riferirsi a SQL come funzionale, ma non è preciso. È dichiarativo con elementi procedurali.


1
Ma le query (istruzioni selezionate) sono funzioni (matematiche pure) e oggetti di prima classe nella lingua. Questo rende il linguaggio funzionale.
nomen

3

È possibile che i tuoi appunti siano confusi?

Non ho mai sentito parlare di linguaggi di programmazione come divisi tra "basato sulle relazioni" e "alto livello". Il livello basso / alto viene solitamente utilizzato per distinguere assemblatore e C dai linguaggi che forniscono supporto diretto per strutture più astratte. Le relazioni sono una struttura piuttosto astratta, quindi direi che tutto ciò che supporta le relazioni è di alto livello per definizione.

Pure SQL viene generalmente descritto come un linguaggio dichiarativo, con alcuni bit procedurali applicati dai vari fornitori. Il fatto che SQL non supporti le funzioni come variabili mi sembra immediatamente squalificarlo dall'essere un linguaggio funzionale.


Le query sono funzioni pure su insiemi / relazioni e sono oggetti di prima classe nella lingua. Ipso facto funzionale.
nomen

1

SQL è un linguaggio relazionale basato su set a cui è stata applicata la funzionalità procedurale.

Non so se considererei SQL funzionale, tuttavia ha alcuni aspetti dei linguaggi funzionali. Le moderne varianti di SQL (con i bit procedurali) non sono assolutamente funzionali.


-1

Penso che SQL sia uno zucchero sintattico attorno all'algebra relazionale + qualcosa in più. L'algebra relazionale ha un grande potere di linguaggi funzionali, sfrutta infatti funzioni di altissimo potere espressivo (selezione, proiezione, rinomina, unione, unione, intersezione ...). Ma per quanto ne so, il trattamento di base dell'algebra relazionale di solito non ha un equivalente dell'operatore lambda, sebbene possa essere esteso con un operatore di ricorsione in modo continuo.

Penso che l'algebra relazionale sia piuttosto un linguaggio algebrico. SQL, con le sue sottoquery, è passato dalla pura algebra relazionale a uno stile più funzionale, ma senza un operatore lambda, penso che non sia un linguaggio completamente funzionale. Non so se potrebbe essere esteso a un linguaggio completamente funzionale in modo continuo, non sono esperto in questo campo. Haskell ha alcune librerie con l'obiettivo di linguaggi di database di altissimo livello.


-1

Non conosco tutte le sottigliezze di ciò che serve affinché una lingua sia qualificata come funzionale, ma Sql Server ha introdotto un modo molto interessante di lavorare con le funzioni. Una clausola speciale rende le funzioni in grado di interagire insieme in una query. Si chiama Applica. Quando l'ho spiegato a un ex programmatore APL, mi ha detto che esisteva una clausola simile in APL per un obiettivo simile. La clausola Apply consente di passare un set di attributi dalla riga di una tabella o dalla riga della funzione di tabella come input a un'altra funzione. Detto questo, ho imposto una restrizione sul tipo di funzione tabella da scrivere per essere considerato funzionale. Deve essere dichiarato come in linea, il che significa che viene espresso come una singola istruzione select. Questo impone di non avere variabili. Tali query con molta logica possono essere scritte a condizione che si utilizzino espressioni di tabella comuni che consentano quindi di trasformare espressioni in colonna, una sorta di variabile non modificabile che può essere riutilizzata in altri CTE. Alla fine la funzione diventa una macro molto grande che rende l'ottimizzatore libero di ottimizzare il modo in cui deve farlo. L'unica cosa che manca alle persone sono alcuni semplici trucchi per scrivere la logica condizionale e dichiarare alcuni dati che supportano la logica nella query. Infine, alcune funzioni che utilizzano la clausola over sono necessarie come modo per portare avanti i risultati come valore utilizzabile in una riga da altre righe, ma sarebbe un po 'lungo da elaborare qui. L'unica cosa che manca alle persone sono alcuni semplici trucchi per scrivere la logica condizionale e dichiarare alcuni dati che supportano la logica nella query. Infine, alcune funzioni che utilizzano la clausola over sono necessarie come modo per portare avanti i risultati come valore utilizzabile in una riga da altre righe, ma sarebbe un po 'lungo da elaborare qui. L'unica cosa che manca alle persone sono alcuni semplici trucchi per scrivere la logica condizionale e dichiarare alcuni dati che supportano la logica nella query. Infine, alcune funzioni che utilizzano la clausola over sono necessarie come modo per portare avanti i risultati come valore utilizzabile in una riga da altre righe, ma sarebbe un po 'lungo da elaborare qui.

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.