mirror of
https://github.com/janishutz/eth-summaries.git
synced 2026-07-27 21:29:09 +02:00
93 lines
2.9 KiB
TeX
93 lines
2.9 KiB
TeX
\documentclass{article}
|
|
|
|
\input{~/projects/latex/janishutz-helpers.tex}
|
|
|
|
|
|
\setupGlossary
|
|
\input{glossary/main.tex}
|
|
\setGlossaryMarkup
|
|
|
|
\usepackage{lmodern}
|
|
\setFontType{sans}
|
|
|
|
\newcommand{\sql}{\acrshort{sql}}
|
|
\renewcommand{\descriptorNameDisplay}[1]{\textbf{#1}}
|
|
|
|
\setup{Data Modelling \& Databases}
|
|
|
|
\begin{document}
|
|
\startDocument
|
|
|
|
\mediumverticalspacing
|
|
|
|
\vspace{1cm}
|
|
\begin{center}
|
|
\includegraphics[width=0.5\linewidth]{~/projects/latex/assets/logo.jpg}
|
|
\end{center}
|
|
|
|
|
|
\vspace{2cm}
|
|
\begin{center}
|
|
\begin{Large}
|
|
\quote{A curry can be written in many different ways}
|
|
\end{Large}
|
|
|
|
\hspace{3cm} - Prof. Dr. Gustavo Alonso, 2026
|
|
\end{center}
|
|
|
|
\vspace{1.5cm}
|
|
\begin{center}
|
|
FS2026, ETHZ
|
|
|
|
\begin{Large}
|
|
Summary of the Lecture Slides
|
|
\end{Large}
|
|
|
|
\url{https://systems.ethz.ch/education/courses/2026-spring/dmdb.html}
|
|
\end{center}
|
|
|
|
\newpage
|
|
|
|
\printtoc{Aquamarine}
|
|
|
|
\newpage
|
|
|
|
\section{Introduction}
|
|
A note on the quote on the title page: He did not \textit{actually} mean ``curry'', but of course ``query'', but he just pronounced it that way.
|
|
|
|
This summary assumes some basic knowledge about databases.
|
|
All words written in \textbf{bold} should be clickable and should link you to the corresponding term in the glossary.
|
|
If I did not forget a term that is, of course.
|
|
|
|
\subsection{IMS}
|
|
Early databases were not relational and they also required the user of the system to know \textit{how the data was stored}.
|
|
This of course is not ideal, as any update to the data structure also required an update to the code interacting with it.
|
|
In addition, manual query optimization has to be done.
|
|
|
|
Non-relational databases commonly have data redundancy, due to non-hierarchical applications being forced into a tree-based model.
|
|
This causes issues when updating the data, as one needs to update the data in all places where a copy of the data exists.
|
|
|
|
\subsection{Network Model}
|
|
In a network model, one \gls{record} is fetched at a time, so it essentially traverses the network.
|
|
However, we again do not have data independence, thus the application again needs to change when the physical data representation changes.
|
|
In addition, manual query optimization has to happen again, thus, any change to the physical data representation may cause the need to redo the optimization.
|
|
|
|
\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_relational-model_logic/main.tex}
|
|
\include{parts/01_sql/main.tex}
|
|
\include{parts/02_theory-background/main.tex}
|
|
\include{parts/03_systems/main.tex}
|
|
\include{parts/04_query-processing/main.tex}
|
|
|
|
|
|
\printGlossary
|
|
|
|
|
|
\end{document}
|