mirror of
https://github.com/janishutz/eth-summaries.git
synced 2026-07-27 21:29:09 +02:00
[DMDB] relational model, relational algebra, SQL very basics
This commit is contained in:
@@ -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.
|
||||
@@ -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}}).
|
||||
|
||||
@@ -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.
|
||||
@@ -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.
|
||||
@@ -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$
|
||||
@@ -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/}
|
||||
@@ -1 +0,0 @@
|
||||
\acrshort{sql} is a \gls{declarative} programming language, used to describe and operate on databases.
|
||||
@@ -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/}
|
||||
@@ -1,4 +0,0 @@
|
||||
\newsection
|
||||
\section{Relational Logic \& Algebra}
|
||||
\input{parts/01_relational-logic/00_intro.tex}
|
||||
% \input{parts/01_relational-logic/}
|
||||
@@ -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.
|
||||
@@ -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}
|
||||
+1
@@ -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) \\
|
||||
@@ -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/}
|
||||
Reference in New Issue
Block a user