[DMDB] relational model, relational algebra, SQL very basics

semester4/dmdb/code/sql/ddl/create.sql

@@ -0,0 +1,6 @@
+CREATE TABLE TableName (
+    Attribute integer,
+    OtherAttribute varchar (30),
+    NextAttribute character (2) default "AP",
+    PRIMARY KEY (Attribute)
+);

semester4/dmdb/data-modelling-databases-summary.tex

@@ -2,18 +2,24 @@
 
 \input{~/projects/latex/janishutz-helpers.tex}
 
+
 \setupGlossary
 \input{glossary/main.tex}
 \setGlossaryMarkup
 
+
 \usepackage{lmodern}
 \setFontType{sans}
 
+\newcommand{\sql}{\acrshort{sql}}
+
 \setup{Data Modelling \& Databases}
 
 \begin{document}
 \startDocument
 
+\mediumverticalspacing
+
 \vspace{1cm}
 \begin{center}
 	\includegraphics[width=0.5\linewidth]{~/projects/latex/assets/logo.jpg}
@@ -69,9 +75,12 @@ In addition, manual query optimization has to happen again, thus, any change to
 \subsection{Relational Model}
 \bi{This is the focus of this course}
 
+The relational model has the benefit of having data independence: The application doesn't know how the data is stored and represented.
+The queries stay the same, even if the data representation changes.
+In addition, the end user does not have to worry about optimization too much. This, of course, only applies to a limited extent.
 
-\include{parts/00_sql/main.tex}
-\include{parts/01_relational-logic/main.tex}
+\include{parts/00_relational-model_logic/main.tex}
+\include{parts/01_sql/main.tex}
 
 
 \printGlossary

semester4/dmdb/glossary/basics.tex

@@ -1,12 +1,16 @@
 \newglossaryentry{declarative}{
-    name={declarative},
-    description={Describes \textit{what} to achieve, but not how}
+	name={declarative},
+	description={Describes \textit{what} to achieve, but not how}
 }
 \newglossaryentry{imperative}{
-    name={imperative},
-    description={Describes how to achieve something}
+	name={imperative},
+	description={Describes how to achieve something}
 }
 \newglossaryentry{record}{
-    name={record},
-    description={}
+	name={record},
+	description={}
+}
+\newglossaryentry{schema}{
+	name={schema},
+	description={A set of relations}
 }

semester4/dmdb/parts/00_relational-model_logic/00_model/00_intro.tex

@@ -0,0 +1,8 @@
+In the relational model, relations are sets of tuples (similar to \glspl{record}). They are denoted $R(f_1: D_1, \ldots, f_n: D_n)$,
+or sometimes simply $R(D_1, \ldots, D_n)$.
+An \bi{instance} is a \bi{set} of tuples $I_R \subseteq D_1 \times \ldots \times D_n$.
+
+\inlineintuition You can think of the instance to be the rows in the table.
+
+\shade{orange}{Important} We define relations as \bi{mathematical sets}. This means that they cannot contain duplicates and the order does not matter.
+Database engines may elect to do this differently, but this course assumes set semantics for the relational model.

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

@@ -0,0 +1,11 @@
+\subsubsection{Keys}
+\inlinedefinition[Candidate Key] The minimal set of fields that identify each tuple uniquely
+
+\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}.
+Formally, we write $R(\underline{k : D_k}, a:D_a, b:D_b)$ for a given relation, with all valid instances fulfilling
+\[
+	I \subseteq D_k \times D_a \times D_b \land \forall (k, a, b), (k', a', b') \in I : k = k' \rightarrow (a, b) = (a', b')
+\]
+i.e. if the key is equal, so is the rest of the tuple (thus they are one and the same\footnote{\hlhref{https://www.youtube.com/watch?v=tGeSEbYzhBU}{Heidrun is her name}}).
+

semester4/dmdb/parts/00_relational-model_logic/00_model/02_queries.tex

@@ -0,0 +1,6 @@
+\subsubsection{Queries}
+We write queries in a relational model using the following set notation (using \acrshort{sql} for an actual DB):
+\[
+    \{ (r, p) \divider r \in \texttt{Supplies} \land p \in \texttt{Parts} \land \texttt{r.pid = p.pid} \land \texttt{p.name = "A"} \}
+\]
+The query language thus processes an entire set at a time and applies set operations over the relations.

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

@@ -0,0 +1,44 @@
+\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)
+\end{itemize}
+% TODO: Add other join operations
+
+\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$.
+
+The idea is to send the column on which the relations are to be joined from the second system to the first,
+there execute a semi-join (thus only returning the contents of $R$ that matched with contents of $S$),
+then sending only that data to the second machine to finish the full join operation.
+
+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/00_relational-model_logic/01_algebra/01_shortcomings.tex

@@ -0,0 +1,4 @@
+\subsubsection{Shortcomings}
+Of course, the Relational Algebra (RA) is not perfect. For example, there are no for-loops.
+
+It is also possible to extend RA to be suitable to bags, but then we also need new operators such as a duplicate elimination operator $\delta$

semester4/dmdb/parts/00_relational-model_logic/main.tex

@@ -0,0 +1,11 @@
+\newsection
+\section{Relational Model, Logic \& Algebra}
+\subsection{Relational Model}
+\input{parts/00_relational-model_logic/00_model/00_intro.tex}
+\input{parts/00_relational-model_logic/00_model/01_keys.tex}
+\input{parts/00_relational-model_logic/00_model/02_queries.tex}
+
+\newpage
+\subsection{Relational Algebra}
+\input{parts/00_relational-model_logic/01_algebra/00_operators.tex}
+% \input{parts/00_relational-model_logic/}

semester4/dmdb/parts/00_sql/00_intro.tex

@@ -1 +0,0 @@
-\acrshort{sql} is a \gls{declarative} programming language, used to describe and operate on databases.

semester4/dmdb/parts/00_sql/main.tex

@@ -1,5 +0,0 @@
-\newsection
-\section{SQL}
-\input{parts/00_sql/00_intro.tex}
-\input{parts/00_sql/01_operations.tex}
-% \input{parts/00_sql/}

semester4/dmdb/parts/01_relational-logic/main.tex

@@ -1,4 +0,0 @@
-\newsection
-\section{Relational Logic \& Algebra}
-\input{parts/01_relational-logic/00_intro.tex}
-% \input{parts/01_relational-logic/}

semester4/dmdb/parts/01_sql/00_intro.tex

@@ -0,0 +1,9 @@
+\acrshort{sql}, or unabbreviated, \acrlong{sql}, is a \gls{declarative} programming language, used to describe and operate on databases.
+
+This is is the point to mention \hlhref{https://xkcd.com/927/}{xkcd standards comic}, because, as is the case with almost any standard,
+people deviate from it and new standards form.
+
+Even though \textit{most} \acrshort{sql} databases support the standard SQL operations, many have added a lot of features on top.
+
+\sql\ is split up into the query language itself, used to operate on data, as well as the Data Definition Language,
+used to create, modify and delete schemas.

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

@@ -0,0 +1,30 @@
+\subsection{Data Definition Language (DDL)}
+The DDL is used to describe the schema of relations, in \sql\ called tables.
+For that, we provide a table name, the columns and their data types.
+
+\sql\ supports the following data types (plus more):
+\begin{multicols}{2}
+    \begin{itemize}[itemsep=-2pt]
+		\item \texttt{char(n)}
+		\item \texttt{varchar(n)}
+		\item \texttt{integer}
+		\item \texttt{blob} or \texttt{raw} (for large binaries)
+		\item \texttt{date}
+	\end{itemize}
+\end{multicols}
+
+
+\subsubsection{Creating Tables}
+Use the DDL \texttt{CREATE TABLE} keyword to create a table. We can set default values for certain attributes,
+or can add constraints to them
+
+% TODO: Constraints (such as NOT NULL)
+
+\inputcodewithfilename{sql}{}{code/sql/ddl/create.sql}
+
+
+
+\subsubsection{Updating / Altering Tables}
+
+
+\subsubsection{Deleting Tables}

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

@@ -1,3 +1,4 @@
+\subsection{Operations}
 \begin{tables}{ll}{Keyword                    & Description}
               \texttt{SELECT val, val2}       & returns the columns \texttt{val} and \texttt{val2}                      \\
               \texttt{FROM table d, table2 c} & selects the target tables. Can use range variables (\texttt{d, c} here) \\

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

@@ -0,0 +1,6 @@
+\newsection
+\section{SQL}
+\input{parts/01_sql/00_intro.tex}
+\input{parts/01_sql/01_ddl.tex}
+\input{parts/01_sql/01_operations.tex}
+% \input{parts/00_sql/}