[DMDB] Improved concurrency control section

semester4/dmdb/parts/05_concurrency-control-recovery/02_transaction-model.tex

@@ -31,7 +31,6 @@ Below a list of very important syntax for the exam (where the subscript $i$ deno
 Conflicting operations are two operations on the same item with at least one of them being a write operation, such as $r_1[x] w_2[x]$ or $w_1[y] w_2[y]$.
 
 \subsubsection{History}
-\label{sec:tm-history}
 A history $H$ is a partially ordered $<_H$ sequence of operations from a set of transactions.
 If two operations are ordered within a transaction, they are equally ordered in the history.
 If two operations $p$ and $q$ conflict, then they are ordered with respect to each other ($p <_H q$ or $q <_H p$)

semester4/dmdb/parts/05_concurrency-control-recovery/03_concurrency-control.tex

@@ -1,5 +1,6 @@
 \newpage
 \subsection{Concurrency Control (CC)}
+\label{sec:concurrency-control}
 The goal of concurrency control is to ensure the correct executions of concurrent transactions.
 The baseline for correctness is, as previously mentioned, serial execution.
 
@@ -19,7 +20,7 @@ and leaves the DB in a consistent state.
 A history is guaranteed to \textit{not} be CS if there are conflicting operations as defined on the previous page.
 
 \inlinetheorem[Serializability] A history is serializable if and only if its serializability graph is acyclic.
-The seerializabililty graph is constructed from the history graph as follows:
+The serializabililty graph is constructed from the history graph as follows:
 \begin{enumerate}
     \item The start node is the transaction the first operation.
     \item Then, follow the operations, adding any new transaction to the tree and connect any further dependencies.
@@ -39,3 +40,16 @@ More visually, see the below graphics
     \end{center}
     \caption{Building a serializability graph (Figure from lecture slides 19, slide 37 and 38)}
 \end{figure}
+
+\subsubsection{Building a serializability graph}
+Since the above guide may not be very easy to understand, a more intuitive approach\footnote{Adapted from \url{https://www.siemens.blog/posts/serializability-theory/}}:
+\begin{enumerate}
+    \item Write down in rows the operations of each thread, such that on the horizontal axis they still align in the way they did when written down in a line
+    \item Add edges horizontally (as the operations of each thread depend on each other implicitly)
+    \item Add edges between successive write operations to the same field
+    \item Add edges between writes and successive reads of the same field (for all threads, doesn't have to be the next operation)
+    \item Add edges between reads and successive writes that happen before the reading thread commits
+\end{enumerate}
+Then, from this history graph notation, derive the serializability graph by only considering the edges between the threads.
+The serialization order is then determined by the topological ordering and the graph is not serializable if there exists a cycle
+(as there doesn't exist a topological ordering)

semester4/dmdb/parts/05_concurrency-control-recovery/06_recovery.tex

@@ -32,7 +32,7 @@ Databases typically log transactions by keeping before and after images of their
 \subsubsection{Recovery on histories}
 \label{sec:recovery-of-histories}
 \begin{examdetails}
-    They like to ask about these, so be sure to understand this properly. Same goes for Conflict Serializability for histories (see \ref{sec:tm-history})
+    They like to ask about these, so be sure to understand this properly. Same goes for Conflict Serializability for histories (see \ref{sec:concurrency-control})
 \end{examdetails}
 A transaction $T_1$ reads from another transaction $T_2$ if $T_1$ reads a value written by $T_2$ at a time when $T_2$ was not aborted.
 

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

@@ -2,16 +2,16 @@
 \subsection{Checklist}
 The following things are typically important to know very well (not exhaustive)
 \begin{todolist}
-    \item SQL (syntax, some concepts, such as using \texttt{WITH} statements often to make the task more approachable), see Section~\ref{sec:sql-query-language}
     \item Relational Algebra notation, see Section~\ref{sec:relational-model-logic-algebra}
+    \item SQL (syntax, some concepts, such as using \texttt{WITH} statements often to make the task more approachable), see Section~\ref{sec:sql-query-language}
     \item Functional Dependencies (including Candidate Keys, Super Keys, Closures and minimal covers), see Section~\ref{sec:functional-dependency}
     \item Normal Forms (and their Decomposition / Synthesis Algorithms), see Section~\ref{sec:normal-forms}
+    \item Rewriting rules, see Section~\ref{sec:rewriting-rules}
     \item Time complexities, I/Os and sorted runs for Query Processing, see summarized above, or Section~\ref{sec:query-processing}
     \item Concepts behind the query processing operators, see Section~\ref{sec:query-processing}
-    \item Conflict Serializability, see Section~\ref{sec:tm-history}
-    \item Core concepts of Vector Search, see Section~\ref{sec:vector-search}, especially quantization costs, see Section~\ref{sec:vector-search-quantization}
+    \item Conflict Serializability, see Section~\ref{sec:concurrency-control}
     \item Recoverability (both the normal techniques, plus Snapshot Isolation and 2-Phase Locking (and strict variant thereof)), see Section~\ref{sec:recovery-of-histories}
-    \item Rewriting rules, see Section~\ref{sec:rewriting-rules}
+    \item Core concepts of Vector Search, see Section~\ref{sec:vector-search}, especially quantization costs, see Section~\ref{sec:vector-search-quantization}
 \end{todolist}
 
 Note that since this course is taught (quite) poorly, there may be wrong questions or possibly even questions that are somewhat outside the scope of this course