[DMDB] Completed normal forms, start query optimization

semester4/dmdb/parts/03_systems/00_query-optimization/00_intro.tex

@@ -0,0 +1,8 @@
+A lot of performance can be gained in a database system by executing the query in the correct order.
+For that, a query optimizer exists, which uses a quite large amount of metadata to speed up query execution.
+
+A query optimizer very broadly works as follows:
+\begin{enumerate}
+    \item It searches the space of equivalent execution plans. This space tends to be huge, so efficient exploration is needed.
+    \item Of all the discovered plans, the best is chosen using a cost model, which describes the most efficient plan
+\end{enumerate}

semester4/dmdb/parts/03_systems/00_query-optimization/01_search-space/00_basics.tex

@@ -0,0 +1,32 @@
+\subsubsection{Search Space}
+To create the search space, the optimizer splits a query into a collection of query blocks,
+where each query block has one \texttt{SELECT} and \texttt{FROM} clause and \textit{at most} one \texttt{WHERE}, \texttt{GROUP BY} and \texttt{HAVING} clause.
+
+Query plans are typically drawn up as trees, as they are typically easier to understand that way than as both SQL query or in relational algebra notation.
+In addition, the query parser commonly transforms it into a tree-like data structure, so thinking about query plans in this way is a good habit.
+For the symbols used here, see section \ref{sec:relational-algebra}.
+
+
+\begin{center}
+    \begin{forest}
+        for tree={
+        ellipse,
+        inner sep=1mm,
+        s sep=10mm,
+        l sep=3mm
+        }
+        [$\Pi_{\texttt{s.PersNr}, \texttt{t.Grade}}$
+        [$\bowtie_{\texttt{t.LectureID = l.LectureID}}$
+        [$\bowtie_{\texttt{s.PersNr = t.PersNr}}$
+        [$\Sigma_{\texttt{s.semester < 5}}$
+        [\texttt{Student}]
+        ]
+        [\texttt{Test}]
+        ]
+        [$\Sigma_{\texttt{l.Name = 'Databases'}}$
+        [\texttt{Lecture}]
+        ]
+        ]
+        ]
+    \end{forest}
+\end{center}

semester4/dmdb/parts/03_systems/00_query-optimization/01_search-space/01_rewriting-rules.tex

@@ -0,0 +1,21 @@
+\paragraph{Rewriting Rules}
+Given a logical plan as above, there are multiple ways in which we can construct a physical plan.
+We can use different join orders, decide when selection happens and specific implementations of operators.
+
+The following rules were discussed in the lectures:
+\begin{enumerate}[label=\textbf{R\arabic*}]
+    \item Conjunctive selection operators can be deconstructed into a sequence of individual selections:
+          \[
+              \sigma_{\theta_1 \land \theta_2} = \sigma_{\theta_1}(\sigma_{\theta_2}(E))
+          \]
+          This is useful to split selections to push them earlier in the execution plan (reduces the number of elements to process subsequently)
+    \item Selection operators are commutative:
+          \[
+              \sigma_{\theta_1}(\sigma_{\theta_2}(E)) = \sigma_{\theta_2}(\sigma_{\theta_1}(E))
+          \]
+          This is useful to allow to first put the one that e.g. has an index.
+    \item Only the last in a sequence of projections is needed, others can be omitted
+          \[
+              \Pi_{t_1}(\Pi_{t_2}(E)) = \Pi_{t_1}(E)
+          \]
+\end{enumerate}

semester4/dmdb/parts/03_systems/main.tex

@@ -0,0 +1,8 @@
+\newsection
+\section{Systems}
+\subsection{Query Optimization}
+\input{parts/03_systems/00_query-optimization/00_intro.tex}
+\input{parts/03_systems/00_query-optimization/01_search-space/00_basics.tex}
+\input{parts/03_systems/00_query-optimization/01_search-space/01_rewriting-rules.tex}
+% \input{parts/03_systems/00_query-optimization/01_search-space/}
+% \input{parts/03_systems/00_query-optimization/}