diff --git a/semester4/dmdb/data-modelling-databases-summary.pdf b/semester4/dmdb/data-modelling-databases-summary.pdf index 85b56aa..795a792 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/00_relational-model_logic/00_model/01_keys.tex b/semester4/dmdb/parts/00_relational-model_logic/00_model/01_keys.tex index 42c8c54..78e9f6b 100644 --- a/semester4/dmdb/parts/00_relational-model_logic/00_model/01_keys.tex +++ b/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}. diff --git a/semester4/dmdb/parts/00_relational-model_logic/01_algebra/00_operators.tex b/semester4/dmdb/parts/00_relational-model_logic/01_algebra/00_operators.tex index bbd7104..adc1d0b 100644 --- a/semester4/dmdb/parts/00_relational-model_logic/01_algebra/00_operators.tex +++ b/semester4/dmdb/parts/00_relational-model_logic/01_algebra/00_operators.tex @@ -1,38 +1,41 @@ \label{sec:relational-algebra} \subsubsection{Operators} \begin{itemize} - \item \bi{Union} $\cup$: $x \in R_1 \cup R_2 \Leftrightarrow x \in R_1 \lor x \in R_2$ - (All tuples from both sets (Only valid for same schemas)) - \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) - \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)$ - (Keep only a subset of the columns, e.g. for columns \texttt{name}, \texttt{pid}, $\Pi_{\texttt{name}}(R)$ returns only the column \texttt{name}) - \item \bi{Cartesian Product} $\times$: $(x, y) \in R_1 \times R_2 \Leftrightarrow x \in R_1 \land y \in R_2$ - (Primarily used to express join operations. This however simply joins together the two tables (i.e. similar to expanding terms in maths)) - \item \bi{Renaming} $\rho$: $\rho_{B_1, \ldots, B_n}(R)$ - (Change the name of the attributes of $R$ to $B_i$) - \item \bi{Natural Join} $\bowtie$: $R_1(A, B) \bowtie R_2(B, C) = \Pi_{A, B, C} (\sigma_{R_1.B = R_2.B}(R_1 \times R_2))$. - (Join two relations into a table on a column. Natural join joins on columns with same name in both (or all) relations) - Edge cases: - \begin{itemize} - \item No shared attributes $R(A, B, C)$, $S(D, E)$: $R \bowtie S = R \times S$ - \item All attributes shared $R(A, B, C)$, $S(A, B, C)$: $R \bowtie S = R \cap S$ - \end{itemize} - \item \bi{Theta Join} $\bowtie_\theta$: $R_1 \bowtie_\theta R_2 = \sigma_\theta(R_1 \times R_2)$ - (Join with custom predicate $\theta$) - \item \bi{Equi-Join} $\bowtie_{A = B}$: $R_1 \bowtie_{A = B} = \sigma_{A = B}(R_1 \times R_2)$ - (Join column A with column B) - \item \bi{Semi-Join} $\ltimes_C$: $R_1 \ltimes_C R_2 = \Pi_{A_1, \ldots, A_n}(R_1 \bowtie_C$, with $R_1(A_1, \ldots, A_n)$ and $R_2(B_1, \ldots, B_m)$ - (Returns columns only from one side if there is a match in the join) - \item \bi{Relational division} $\div$: $R \div S = \Pi_{R - S} R - \Pi_{R - S}((\Pi_{R - S} R) \times S - R)$. - In other words, $R \div S = T$, with $T$ being the \textit{largest} relation such that $S \times T \subseteq R$. - (Find all rows that do not fulfil a condition) + \item \bi{Union} $\cup$: $x \in R_1 \cup R_2 \Leftrightarrow x \in R_1 \lor x \in R_2$ + (All tuples from both sets (Only valid for same schemas)) + \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 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)$ + (Keep only a subset of the columns, e.g. for columns \texttt{name}, \texttt{pid}, $\Pi_{\texttt{name}}(R)$ returns only the column \texttt{name}) + \item \bi{Cartesian Product} $\times$: $(x, y) \in R_1 \times R_2 \Leftrightarrow x \in R_1 \land y \in R_2$ + (Primarily used to express join operations. This however simply joins together the two tables (i.e. similar to expanding terms in maths)) + \item \bi{Renaming} $\rho$: $\rho_{B_1, \ldots, B_n}(R)$ + (Change the name of the attributes of $R$ to $B_i$) + \item \bi{Natural Join} $\bowtie$: $R_1(A, B) \bowtie R_2(B, C) = \Pi_{A, B, C} (\sigma_{R_1.B = R_2.B}(R_1 \times R_2))$. + (Join two relations into a table on a column. Natural join joins on columns with same name in both (or all) relations) + Edge cases: + \begin{itemize} + \item No shared attributes $R(A, B, C)$, $S(D, E)$: $R \bowtie S = R \times S$ + \item All attributes shared $R(A, B, C)$, $S(A, B, C)$: $R \bowtie S = R \cap S$ + \end{itemize} + \item \bi{Theta Join} $\bowtie_\theta$: $R_1 \bowtie_\theta R_2 = \sigma_\theta(R_1 \times R_2)$ + (Join with custom predicate $\theta$) + \item \bi{Equi-Join} $\bowtie_{A = B}$: $R_1 \bowtie_{A = B} = \sigma_{A = B}(R_1 \times R_2)$ + (Join column A with column B) + \item \bi{Semi-Join} $\ltimes_C$: $R_1 \ltimes_C R_2 = \Pi_{A_1, \ldots, A_n}(R_1 \bowtie_C$, with $R_1(A_1, \ldots, A_n)$ and $R_2(B_1, \ldots, B_m)$ + (Returns columns only from one side if there is a match in the join) + \item \bi{Relational division} $\div$: $R \div S = \Pi_{R - S} R - \Pi_{R - S}((\Pi_{R - S} R) \times S - R)$. + In other words, $R \div S = T$, with $T$ being the \textit{largest} relation such that $S \times T \subseteq R$. + (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. + + diff --git a/semester4/dmdb/parts/01_sql/01_ddl.tex b/semester4/dmdb/parts/01_sql/01_ddl.tex index ef9d8cd..5d0626c 100644 --- a/semester4/dmdb/parts/01_sql/01_ddl.tex +++ b/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. diff --git a/semester4/dmdb/parts/03_systems/02_indexing/01_b-trees/01_basics.tex b/semester4/dmdb/parts/03_systems/02_indexing/01_b-trees/01_basics.tex index 0d5e47d..27c3460 100644 --- a/semester4/dmdb/parts/03_systems/02_indexing/01_b-trees/01_basics.tex +++ b/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. diff --git a/semester4/dmdb/parts/04_query-processing/04_join/01_nested-loops.tex b/semester4/dmdb/parts/04_query-processing/04_join/01_nested-loops.tex index e4ed545..b785fdd 100644 --- a/semester4/dmdb/parts/04_query-processing/04_join/01_nested-loops.tex +++ b/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) diff --git a/semester4/dmdb/parts/08_quick-overview/04_checklist.tex b/semester4/dmdb/parts/08_quick-overview/04_checklist.tex new file mode 100644 index 0000000..1502f5a --- /dev/null +++ b/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} diff --git a/semester4/dmdb/parts/08_quick-overview/main.tex b/semester4/dmdb/parts/08_quick-overview/main.tex index f012a83..3aa4ccf 100644 --- a/semester4/dmdb/parts/08_quick-overview/main.tex +++ b/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}