Fügen Unterabfragen SQL-Abfragen Ausdruckskraft hinzu?

Benötigt SQL Unterabfragen?

Stellen Sie sich eine ausreichend verallgemeinerte Implementierung der strukturierten Abfragesprache für Beziehungsdatenbanken vor. Da die Struktur der kanonischen SQL- SELECTAnweisung eigentlich ziemlich wichtig ist, damit dies sinnvoll ist, appelliere ich nicht direkt an die relationale Algebra, aber Sie könnten dies in diesen Begriffen einrahmen, indem Sie die Form der Ausdrücke entsprechend einschränken.

Eine SQL - SELECTAbfrage besteht im allgemeinen aus einem Vorsprung (der SELECTTeil) eine bestimmte Anzahl von JOINOperationen (der JOINTeil), eine bestimmte Anzahl von SELECTION Operationen (in SQL, die WHEREKlauseln), und dann gesetzt weise Operationen ( UNION, EXCEPT, INTERSECT, etc.), gefolgt von einem anderen SQL- SELECTAbfrage.

Tabellen, die verknüpft werden, können die berechneten Ergebnisse von Ausdrücken sein. Mit anderen Worten, wir können eine Aussage haben wie:

SELECT t1.name, t2.address
  FROM table1 AS t1 
  JOIN (SELECT id, address 
          FROM table2 AS t3 
         WHERE t3.id = t1.id) AS t2
 WHERE t1.salary > 50,000;

Wir werden uns auf die Verwendung einer berechneten Tabelle als Teil einer SQL-Abfrage als Unterabfrage beziehen. Im obigen Beispiel ist die zweite (eingerückte) SELECTeine Unterabfrage.

Können alle SQL-Abfragen so geschrieben werden, dass keine Unterabfragen verwendet werden? Das obige Beispiel kann:

SELECT t1.name, t2.address
  FROM table1 AS t1 
  JOIN table2 AS t2
    ON t1.id = t2.id
 WHERE t1.salary > 50,000;

Dieses Beispiel ist etwas fälschlich oder trivial, aber man kann sich Fälle vorstellen, in denen erheblich mehr Aufwand erforderlich ist, um einen äquivalenten Ausdruck wiederherzustellen. Mit anderen Worten, gibt es für jede SQL-Abfrage mit Unterabfragen eine Abfrage ohne Unterabfragen, so dass und garantiert dieselben Ergebnisse für dieselben zugrunde liegenden Tabellen liefern? Beschränken wir SQL-Abfragen auf das folgende Formular:$q$$q'$$q$$q'$

SELECT <attribute>,
      ...,
      <attribute>
 FROM <a table, not a subquery>
 JOIN <a table, not a subquery>
  ...
 JOIN <a table, not a subquery>
WHERE <condition>
  AND <condition>
  ...
  AND <condition>

UNION
 -or-
EXCEPT
 -or-
<similar>

SELECT ...

Und so weiter. Ich denke, linke und rechte äußere Verknüpfungen tragen nicht viel dazu bei, aber wenn ich mich irre, können Sie gerne darauf hinweisen ... auf jeden Fall handelt es sich auch um faires Spiel. Was die Mengenoperationen angeht, sind wohl alle in Ordnung ... Vereinigung, Differenz, symmetrische Differenz, Schnittmenge usw. ... alles, was hilfreich ist. Gibt es bekannte Formen, auf die alle SQL-Abfragen reduziert werden können? Beseitigen diese Unterabfragen? Oder gibt es Fälle, in denen keine äquivalente Abfrage ohne Unterabfrage vorhanden ist? Referenzen sind erwünscht ... oder eine Demonstration (durch Nachweis), dass sie erforderlich sind oder nicht, wäre fantastisch. Danke, und tut mir leid, wenn dies ein gefeiertes (oder triviales) Ergebnis ist, von dem ich schmerzlich nichts weiß.

Es gibt einige terminologische Verwirrungen. der Abfrageblock in Klammern

SELECT t1.name, t2.address
  FROM table1 
  JOIN (SELECT id, address 
          FROM table2 AS t3 
         WHERE t3.id = t1.id) 

heißt innere Sicht . Eine Unterabfrage ist ein Abfrageblock innerhalb der WHERE- oder SELECT-Klausel, z

select deptno from dept
where 3 < (select count(1) from emp 
           where dept.deptno=emp.deptno)

In beiden Fällen kann die innere Ansicht oder Unterabfrage nicht in die "flache" Projekteinschränkungsverknüpfung eingebunden werden. Korrelierte Unterabfrage mit Aggregation verschachtelt sich in innere Ansichten mit Gruppierung, die sich dann in flache Abfragen verschachtelt.

select deptno from dept d
    where 3 < (select avg(sal) from emp e
               where d.deptno=e.deptno)

select d.deptno from dept d, ( 
    select deptno from emp e
    group by deptno
    having avg(sal) > 3
) where d.deptno=e.deptno

select d.deptno from dept d, emp e
where d.deptno=e.deptno 
group by d.deptno
having avg(sal) > 3

Bezüglich der algebraischen Regeln für die Abfrageoptimierung ist bekannt, dass die relationale Algebra in ein relationales Gitter axiomatisiert wird, was die hier und da gezeigten Abfragetransformationen vereinfacht .

Um Ihre Aussage in die relationale Algebra zu übersetzen, fragt sie meiner Meinung nach:

$\sigma_A(A)\bowtie \sigma_B(B)$$\sigma_A(\sigma_B(A\bowtie B))$

$\sigma$$\bowtie$

Die Antwort lautet "Ja" und es handelt sich um eine Standard-Abfrageoptimierung. Um ehrlich zu sein, ich bin mir nicht sicher, wie ich das ohne Fragen beweisen kann - es ist nur eine Eigenschaft der Auswahl und des Beitritts. Sie können induktiv argumentieren, um beliebig viele Ebenen verschachtelter Abfragen hinzuzufügen.

Zusätzlich könnten Sie fragen:

$A\bowtie B\bowtie C\bowtie\dots$$(A\bowtie B)\bowtie(C\bowtie D)$

Wieder ist die Antwort ja, weil verbinden assoziativ ist. Ähnliche Aussagen können auch zur Projektion gemacht werden.

Eine bemerkenswerte Art von "Unterabfrage", von der ich denke, dass sie nicht "abgeflacht" werden kann, ist with. Eine Möglichkeit, dies zu erkennen, besteht darin, zu beachten, dass Sie, wenn Sie eine withAnweisung haben, eine rekursive Funktion haben können, die nicht ohne die Verwendung von Unterabfragen geschrieben werden kann.

Zusammenfassend lässt sich sagen, dass SQL in dem von Ihnen erwähnten speziellen Fall keine Unterabfragen benötigt und dass Sie dies induktiv beweisen können. Im Allgemeinen gibt es jedoch Funktionen, für die Unterabfragen erforderlich sind.

Msgstr "Fügen Unterabfragen SQL - Abfragen Ausdruckskraft hinzu?"

Sie taten es zumindest vor der Einführung von EXCEPT in der SQL-Sprache.

Vor der Einführung von EXCEPT gab es keine Möglichkeit, einen relationalen Unterschied oder eine Halbdifferenz in SQL auszudrücken, ohne auf Unterabfragen zurückzugreifen.

Heutzutage können alle "typischen" primitiven Operatoren der "relationalen Algebra" ohne Unterabfragen ausgedrückt werden:

NATURAL JOIN kann über NATURAL JOIN oder JOIN ON
UNION über UNION
MINUS über EXCEPT
PROJECT / RENAME / EXTEND über SELECT
RESTRICT über VALUES durchgeführt werden, wobei
relationale Literale über
Transitive Closures durchgeführt werden können erfolgt durch rekursives WITH