diff --git a/semester4/dmdb/data-modelling-databases-summary.pdf b/semester4/dmdb/data-modelling-databases-summary.pdf index 8e4bc34..8a3a17a 100644 Binary files a/semester4/dmdb/data-modelling-databases-summary.pdf and b/semester4/dmdb/data-modelling-databases-summary.pdf differ diff --git a/semester4/dmdb/parts/05_concurrency-control-recovery/02_transaction-model.tex b/semester4/dmdb/parts/05_concurrency-control-recovery/02_transaction-model.tex index 113db6c..0e8da37 100644 --- a/semester4/dmdb/parts/05_concurrency-control-recovery/02_transaction-model.tex +++ b/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$) diff --git a/semester4/dmdb/parts/05_concurrency-control-recovery/03_concurrency-control.tex b/semester4/dmdb/parts/05_concurrency-control-recovery/03_concurrency-control.tex index aa9aa33..dc923af 100644 --- a/semester4/dmdb/parts/05_concurrency-control-recovery/03_concurrency-control.tex +++ b/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) diff --git a/semester4/dmdb/parts/05_concurrency-control-recovery/06_recovery.tex b/semester4/dmdb/parts/05_concurrency-control-recovery/06_recovery.tex index 639b3d0..872481f 100644 --- a/semester4/dmdb/parts/05_concurrency-control-recovery/06_recovery.tex +++ b/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. diff --git a/semester4/dmdb/parts/08_quick-overview/04_checklist.tex b/semester4/dmdb/parts/08_quick-overview/04_checklist.tex index 407386d..f3fbf85 100644 --- a/semester4/dmdb/parts/08_quick-overview/04_checklist.tex +++ b/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