[DMDB] Learnings from practice exams, plus some more tips and tricks

semester4/dmdb/parts/00_relational-model_logic/00_model/01_keys.tex

@@ -1,6 +1,7 @@
 \subsubsection{Keys}
 \label{sec:relations-keys}
-\inlinedefinition[Candidate Key] The minimal set of fields that identify each tuple uniquely (non-duplicate attributes (fields) typically)
+\inlinedefinition[Candidate Key] The \bi{minimal} set of fields that identify each tuple uniquely (non-duplicate attributes (fields) typically).
+In other words, it is the minimal set such that for its closure $F+$ and the relation $\cR$ that it belongs to, $\forall y \in F+ \implies y \in \cR$.
 
 \inlinedefinition[Primary Key] A single candidate key, i.e. just a single field.
 We mark the primary key using \underline{underlining} in visual \glspl{schema}.

semester4/dmdb/parts/00_relational-model_logic/01_algebra/00_operators.tex

@@ -6,7 +6,7 @@
     \item \bi{Difference} $-$: $x \in R_1 - R_2 \Leftrightarrow x \in R_1 \land x \notin R_2$
           (Tuples that appear in $R_1$, but not in $R_2$)
     \item \bi{Intersection} $\cap$: $x \in R_1 \cap R_2 = R_1 - (R_1 - R_2)$
-	      (Tuples that don't appear in both sets)
+          (Tuples that appear in both sets)
     \item \bi{Selection} $\sigma$: $x \in \sigma_c(R) \Leftrightarrow x \in R \land c(x) = \texttt{true}$, with $c$ a predicate on the passed in set.
           (Tuples that fulfil the predicate $c$)
     \item \bi{Projection} $\Pi$: $\Pi_{A_1, \ldots, A_n}(R)$
@@ -33,6 +33,9 @@
           (Find all rows that do not fulfil a condition)
 \end{itemize}
 % TODO: Add other join operations
+% TODO: Inequality joins (especially for SQL)
+
+If we apply set semantics generally, then each operator returns results that adhere to that concept, even Projections!
 
 \shade{purple}{Semi-Join Reduction} A useful trick with semi-joins. It is especially useful in distributed DB, where $R$ and $S$ are on different machines.
 Suppose we want to Join $R(A, B)$ with $S(B, C)$ on $B$, then we can do the following $R \bowtie S = (R \ltimes \Pi_B S) \bowtie S$.
@@ -43,3 +46,5 @@ then sending only that data to the second machine to finish the full join operat
 
 Of course, in the real world, users of DB systems don't write relational algebra, as in this case, the order of operations matters for performance,
 whereas we want database systems to figure this out by themselves.
+
+

semester4/dmdb/parts/01_sql/01_ddl.tex

@@ -27,7 +27,7 @@ Since the primary key must be unique for each entry, it may be useful to configu
 
 \inputcodewithfilename{sql}{}{code/sql/ddl/create.sql}
 
-Note that PostgreSQL doesn't support \texttt{AUTO\_INCREMENT} constraints, instead use the \texttt{SERIAL} (or \texttt{BIGSERIAL}) type
+Note that PostgreSQL doesn't support \texttt{AUTO\_INCREMENT} constraints, instead use the \texttt{SERIAL} (or \texttt{BIGSERIAL}) type.
 
 
 % TODO: Make sure all the sql statements actually execute in pgsql
@@ -54,17 +54,23 @@ Instead of a \texttt{ADD COLUMN} or \texttt{DROP COLUMN}, we can also use \textt
     \item \texttt{PRIMARY KEY}: Sets this column as the primary key. \texttt{NOT NULL} and \texttt{UNIQUE} is set on it implicitly.
           Contrary to common intuition, it can be set on multiple columns.
     \item \texttt{CHECK c}: Check that the values fulfil a condition.
-          This condition has the same syntax as for the \texttt{WHERE} clause (see \ref{sec:sql-basic-ops})
+          This condition \texttt{c} has the same syntax as for the \texttt{WHERE} clause (see \ref{sec:sql-basic-ops})
     \item \texttt{REFERENCES table}: A Foreign Key, used to refer to another tuple from a different relation.
           It is typically referencing the primary key of the other table.
 \end{itemize}
-For \texttt{REFERENCES}, there are many options for maintenance, which can be set on creating a reference:
+For \texttt{REFERENCES}, there are many options for maintenance, which can be set on creating a reference, using \texttt{ON UPDATE} and \texttt{ON DELETE}:
 \begin{itemize}
     \item \bi{Cascade}: Propagate \texttt{UPDATE} and \texttt{DELETE}
     \item \bi{Restrict}: Prevent deletion of the primary key before the change, causes error
     \item \bi{No Action}: Prevent modifications after attempting change, causes error
-    \item \bi{Set default, Set Default}: Set references to \texttt{NULL} or default value
+    \item \bi{Set default / Set null}: Set references to \texttt{NULL} or default value
 \end{itemize}
+The default for \texttt{ON DELETE} is \texttt{NO ACTION}.
 
 \inlineexample
 \mint{sql}|CREATE TABLE tab (id integer REFERENCES OtherTable ON DELETE cascade ON UPDATE cascade)|
+
+\inlineintuition For a deletion of a row with \texttt{NO ACTION} set (the default), if there exist any rows of tables with a Foreign key on this row,
+where the Foreign Key is equal to the to be delted primary key, an error is thrown.
+If \texttt{RESTRICT} is set, the error happens a earlier, as the check is performed \textit{before} the deletion is attempted.
+This has the downside of being possibly a bit slower, if large numbers of unreferenced rows are deleted.

semester4/dmdb/parts/03_systems/02_indexing/01_b-trees/01_basics.tex

@@ -10,6 +10,9 @@ There are some systems that allow storing the data directly on the leaves.
 
 Some systems create a B+ tree index by default for all tables and index the key. If there is no key, the engine assigns random keys and indexes them.
 
+The height of a B+ Tree is given by $1 + \ceil{\log_K(P)}$, with $K$ the number of keys per inner node and $P$ the number of pages in the relation.
+This comes from typical logarithmic height, plus the leaf node (or the root node, if you like).
+
 
 \paragraph{Clustered Indexes}
 An index orders the table by the attribute it is indexing, but the tuples in the table might not be ordered.

semester4/dmdb/parts/04_query-processing/04_join/01_nested-loops.tex

@@ -15,3 +15,5 @@
 
 The cost here is \cost{$P_R + P_R \cdot P_S$ I/Os}, where $P_X$ is the number of pages in the relation $X$.
 Furthermore, the DBMS should put the smaller relation on the outer loop to improve performance.
+
+For multiple joins, we want to start with the smallest table (on the inside) and move up to larger ones, processing the largest one \textit{last} (such that it is the outer loop)

semester4/dmdb/parts/08_quick-overview/04_checklist.tex

@@ -0,0 +1,10 @@
+\subsection{Checklist}
+The following things are typically important to know very well (not exhaustive)
+\begin{todolist}
+    \item SQL
+    \item Functional Dependencies (including Candidate Keys, Super Keys, Closures and minimal covers)
+    \item Normal Forms (and their Decomposition / Synthesis Algorithms)
+    \item Time complexities, I/Os and sorted runs for Query Processing
+    \item Conflict Serializability
+    \item Recoverability (both the normal techniques, plus Snapshot Isolation and 2-Phase Locking (and strict variant thereof))
+\end{todolist}

semester4/dmdb/parts/08_quick-overview/main.tex

@@ -5,3 +5,4 @@ This section aims to give you the most important things to remember in a very co
 \input{parts/08_quick-overview/01_theory.tex}
 \input{parts/08_quick-overview/02_system.tex}
 \input{parts/08_quick-overview/03_qp.tex}
+\input{parts/08_quick-overview/04_checklist.tex}