diff --git a/semester4/dmdb/data-modelling-databases-summary.pdf b/semester4/dmdb/data-modelling-databases-summary.pdf index d010977..93f4a91 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/01_algebra/00_operators.tex b/semester4/dmdb/parts/00_relational-model_logic/01_algebra/00_operators.tex index adc1d0b..c88b5c4 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 @@ -26,7 +26,7 @@ (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)$ + \item \bi{Semi-Join} $\ltimes_C$: $R_1 \ltimes_C R_2 = \Pi_{A_1, \ldots, A_n}(R_1 \bowtie_C R_2)$, 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$. diff --git a/semester4/dmdb/parts/01_sql/03_query-language/03_aggregation.tex b/semester4/dmdb/parts/01_sql/03_query-language/03_aggregation.tex index cc48899..4022590 100644 --- a/semester4/dmdb/parts/01_sql/03_query-language/03_aggregation.tex +++ b/semester4/dmdb/parts/01_sql/03_query-language/03_aggregation.tex @@ -5,7 +5,7 @@ whose output should be evident. Please note that you cannot use the aggregation functions and still output another column, -as they produce a single value. +as they produce a single value. (Except you are grouping on that value) For each of the functions, you can optionally specify \texttt{DISTINCT}. diff --git a/semester4/dmdb/parts/02_theory-background/01_normal-forms/00_intro.tex b/semester4/dmdb/parts/02_theory-background/01_normal-forms/00_intro.tex index 8ca9f0a..49270a5 100644 --- a/semester4/dmdb/parts/02_theory-background/01_normal-forms/00_intro.tex +++ b/semester4/dmdb/parts/02_theory-background/01_normal-forms/00_intro.tex @@ -2,9 +2,9 @@ \subsection{Normal Forms} \inlinedefinition[Normal forms] describe the properties of concrete schemas based on functional dependencies in terms of data redundancy and data integrity. -For each of the normal forms, we need to be able to decide: +For each of the normal forms, we need to be able to decide (for $R$ the relation and $F$ the functional dependencies of it): \begin{itemize} \item whether $\{ R, F \}$ satisfies the NF \item given $\{ R, F \}$ that satisfies the NF, what are the properties? - \item how can we generate new schema $R'$, such that $\{ R', F \}$ satisfies the given normal form + \item how we can generate a new schema $R'$, such that $\{ R', F \}$ satisfies the given normal form \end{itemize} diff --git a/semester4/dmdb/parts/02_theory-background/01_normal-forms/02_second-nf.tex b/semester4/dmdb/parts/02_theory-background/01_normal-forms/02_second-nf.tex index 1a3eea7..203060f 100644 --- a/semester4/dmdb/parts/02_theory-background/01_normal-forms/02_second-nf.tex +++ b/semester4/dmdb/parts/02_theory-background/01_normal-forms/02_second-nf.tex @@ -14,3 +14,6 @@ If relations are not in 2NF, they may experience insert, update and delete anoma which can lead to incorrect, redundant or inconsistent updates of the relations. However, some relations can still suffer from update and / or delete anomalies. One such example is a non-key Functional Dependency. + +\inlineintuition In other words, for a relation to be in 2NF, there cannot exist any \textit{prime attributes} (i.e. non-key attributes) +that have a functional dependency on only \textit{parts} of a candidate key. diff --git a/semester4/dmdb/parts/02_theory-background/01_normal-forms/03_third-nf.tex b/semester4/dmdb/parts/02_theory-background/01_normal-forms/03_third-nf.tex index bf409e6..b4dddcf 100644 --- a/semester4/dmdb/parts/02_theory-background/01_normal-forms/03_third-nf.tex +++ b/semester4/dmdb/parts/02_theory-background/01_normal-forms/03_third-nf.tex @@ -9,3 +9,7 @@ A relation $R$ is in 3NF if and only if for all $\alpha \rightarrow B$, at least thus, the 3NF tries to get rid of ``transitive dependencies'' (e.g. $A \rightarrow B, B \rightarrow C$) The 3NF can still experience update and delete anomalies. + +\inlineintuition Some more intuition for the decomposition: We want to decompose the table into multiple tables such that each transitive dependency +is in its own table, thus removing transitive dependencies in each table, and an intuitive take on this is that each table shall not contain ``anything but the key'', +which however is not entirely correct, because it only mentions a single key, not all