diff --git a/semester4/dmdb/data-modelling-databases-summary.pdf b/semester4/dmdb/data-modelling-databases-summary.pdf
index 2324121..de22bca 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/02_theory-background/01_normal-forms/01_first-nf.tex b/semester4/dmdb/parts/02_theory-background/01_normal-forms/01_first-nf.tex
index d4f3c63..bd13c64 100644
--- a/semester4/dmdb/parts/02_theory-background/01_normal-forms/01_first-nf.tex
+++ b/semester4/dmdb/parts/02_theory-background/01_normal-forms/01_first-nf.tex
@@ -3,9 +3,8 @@ In the first normal form, only atomic domains are allowed, i.e. keys are not all
 
 \inlineintuition This makes the concept of a key easier to define, or well defined
 
-Some \sql\ flavours support arrays. However, the semantics and the support varies
-
 This can come in handy to solve one to many relationships, but what if many different persons have the same elements there?
 This can cause some issues when updating.
 
+However, some \sql\ flavours support arrays. However, the semantics and the support varies.
 Arrays are very tempting to use if we have an unknown and variable number of different data points for a field.
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 ccb0e8b..1a3eea7 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
@@ -13,4 +13,4 @@ For a relation to be in 2NF, every non-key attribute needs to minimally dependen
 If relations are not in 2NF, they may experience insert, update and delete anomalies,
 which can lead to incorrect, redundant or inconsistent updates of the relations.
 
-However, some relations can still suffer from update and / or delete anomalies
+However, some relations can still suffer from update and / or delete anomalies. One such example is a non-key Functional Dependency.
diff --git a/semester4/dmdb/parts/02_theory-background/01_normal-forms/07_overview.tex b/semester4/dmdb/parts/02_theory-background/01_normal-forms/07_overview.tex
index 8663da5..266661d 100644
--- a/semester4/dmdb/parts/02_theory-background/01_normal-forms/07_overview.tex
+++ b/semester4/dmdb/parts/02_theory-background/01_normal-forms/07_overview.tex
@@ -1,4 +1,5 @@
 \subsubsection{Overview}
+\label{sec:nf-overview}
 This overview is adapted from \hlhref{https://en.wikipedia.org/wiki/Database_normalization\#Normal_forms}{this Wikipedia article}.
 All constraint definitions in {\scriptsize smaller font} are informal. Note that \textit{prime attributes} are the attributes that make up a candidate key,
 also known as \textit{key attributes}
@@ -17,3 +18,6 @@ also known as \textit{key attributes}
                                         & \cross     & \cross     & \cross     & \cross     & \checkmark \\
 \end{tables}
 This means that a relation in BNCF is free of redundancies based on functional dependencies.
+
+Note that the above table needs to be read vertically, i.e. for UNF only Unique Rows needs to be satisfied,
+thus it doesn't mean that if we have Scalar Columns that this isn't allowed in UNF. In fact, it is allowed, as it is a more strict property.