RocketGit

caubert / CSCI_3410 (public) (License: CC BY 4.0) (since 2018-05-16) (hash sha1)

Material for Database Class.

Clone URLs: https://rocketgit.com/user/caubert/CSCI_3410 ssh://rocketgit@ssh.rocketgit.com/user/caubert/CSCI_3410 git://git.rocketgit.com/user/caubert/CSCI_3410

master

List of commits:

Subject	Hash	Author	Date (UTC)
Working on Ch. 4, adding the content of the weekly announcements to the core of the document, added illustrations on the conversion E.R. -> Rel. model, fixed various typos.	1995837f41c1508ae809d5a91065bdefd5bd6c03	aubert@math.cnrs.fr	2019-03-22 17:27:51
Fixing exercise and normalization in Chapter 4.	7aa4b9a581daf7144dd485ba791b7707585088b8	aubert@math.cnrs.fr	2019-03-20 18:55:42
Quick fix on UML diagrams.	86a52b2f6ce92750bdb2c33eaa4dbc4497322e1c	aubert@math.cnrs.fr	2019-03-18 18:37:24
Adding some missing files.	0c090f6d43e84b71ca5e1f6d3e8d1aa0d733824d	aubert@math.cnrs.fr	2019-03-18 18:28:32
Fixing the style for line numbers, adding information for weak entities, drawing some figures (for crow's notation, for alternative notations), removing various images.	26ce9a96701649988cfdfcb3e61011f4e154896d	aubert@math.cnrs.fr	2019-03-18 18:25:09
Added solution to quiz #4.	db0de8ba5c6605d77fdbc076f3a9e5b3851d83e0	aubert@math.cnrs.fr	2019-03-15 20:57:13
Added questions for Quiz #4.	30d908601e9431ec0901d4001ddbf99bf14f75d0	aubert@math.cnrs.fr	2019-03-15 17:52:24
Worked on narrative in Chapter 4, mostly ER diagrams.	9e0cc5fc5a2b4087fe1191f1ba5926f87ad5a7bd	aubert@math.cnrs.fr	2019-03-12 18:57:16
Updated list of known bugs.	d51ff0a5bb73f09eb8d3eb7520ebb77555911e69	aubert@math.cnrs.fr	2019-03-12 17:09:22
Updating the README with the list of new files.	bb35e21746d958d649b226a5857150d975d85403	aubert@math.cnrs.fr	2019-03-07 15:20:04
Adding a list of bug, and the sketch of a guide to contribute.	3a94b1fa49aee97001a45325f3f10f09475bf388	aubert@math.cnrs.fr	2019-03-07 15:14:38
Fixed the size of the images, added mention of the support of Affordable Learning Georgia.	485cf486d8d2b08427e5d02eda56d5b7a9495b38	aubert@math.cnrs.fr	2019-03-05 19:37:39
Finishing homework #5.	e322bc945941083b0649557d9ad6bdbb8308c10c	aubert@math.cnrs.fr	2019-03-04 15:10:15
Preparing homework 5	2b9ba64d1d36ae9f413929947cac5e6cddceb3dc	aubert@math.cnrs.fr	2019-03-01 20:06:12
Some fixes and added quiz #3.	d73c356f1bec9679f7123bc508c1863f8de40aef	aubert@math.cnrs.fr	2019-02-28 20:34:04
Working on solutions for problems in Chapter 3.	0da378f97cea97fa2b3614f1b611a3b5bdf42632	aubert@math.cnrs.fr	2019-02-26 19:56:23
Forgot one exercise in exam.	611bbe4cc68f802bfffd7bdfc70c3433a70eceb5	aubert@math.cnrs.fr	2019-02-22 20:39:07
Quick fix	c22751b88c377a40dd2c037a706409aa29ef3ce2	aubert@math.cnrs.fr	2019-02-22 20:37:21
Various editing, fixing some of the solutions in Chapter 3 and some of the exercises in Chapter 4.	1e1d8dd576329b20aa3b7f9344aaecb9d11fc6f4	aubert@math.cnrs.fr	2019-02-22 20:22:09
Added the rest of the first exam for Fall 2019.	0d5a839282b1ae6e6c07e7b12a74ff2f0f2f3b86	aubert@math.cnrs.fr	2019-02-22 20:03:02

Commit 1995837f41c1508ae809d5a91065bdefd5bd6c03 - Working on Ch. 4, adding the content of the weekly announcements to the core of the document, added illustrations on the conversion E.R. -> Rel. model, fixed various typos.
Author: aubert@math.cnrs.fr
Author date (UTC): 2019-03-22 17:27
Committer name: aubert@math.cnrs.fr
Committer date (UTC): 2019-03-22 17:27
Parent(s): 7aa4b9a581daf7144dd485ba791b7707585088b8
Signer:
Signing key:
Signing status: N
Tree: b194f7f1a430e7355963c3f462d619cdf01ed6d9

File	Lines added	Lines deleted
KNOWN_BUGS.md	2	0
notes/code/sql/HW_FACULTY.sql	11	4
notes/fig/er/Book.tex	10	0
notes/fig/er/Book2.tex	12	0
notes/fig/er/Computer_User.tex	12	0
notes/fig/er/Desk.tex	13	0
notes/fig/er/Doula.tex	12	0
notes/fig/er/Gym.tex	3	3
notes/fig/er/MappingRelationships1.tex	12	0
notes/fig/er/MappingRelationships2.tex	12	0
notes/fig/er/Software_Dep.tex	14	0
notes/fig/fd/DriverExample1.tex	3	4
notes/fig/fd/DriverExample2.tex	16	0
notes/fig/fd/Example2NF1.tex	3	3
notes/fig/fd/Example2NF2.tex	1	1
notes/fig/fd/Example2NF3.tex	1	1
notes/fig/fd/StudentExample1.tex	4	4
notes/fig/fd/StudentExample2.tex	15	0
notes/fig/rel_mod/COMPUTER_USER.tex	19	0
notes/fig/rel_mod/DESK.tex	20	0
notes/fig/rel_mod/MappingRelationships2.tex	27	0
notes/fig/rel_mod/MappingRelationships3.tex	5	3
notes/fig/rel_mod/MappingRelationships4.tex	15	0
notes/fig/rel_mod/MappingRelationships5.tex	22	0
notes/img/ER_To_Rel1.jpeg	0	0
notes/lectures_notes.md	202	29

File KNOWN_BUGS.md changed (mode: 100644) (index f4a2f9e..60e12dd)
...	...	CONTENT TO ADD
4	4	- Add triggers and stored procedures?	- Add triggers and stored procedures?
5	5	- Add content on Security and "Recognize professional responsibilities and make informed judgments in computing practice based on legal and ethical principles."	- Add content on Security and "Recognize professional responsibilities and make informed judgments in computing practice based on legal and ethical principles."
6	6	- Add six first questions of Exam #2 Fall 2017	- Add six first questions of Exam #2 Fall 2017
	7		- Mention / discuss propagate options, and UNIQUE / NOT NULL, etc. options on particular attributes, during the discussion on how to map E.R. diagram to the relational model.
	8
7	9
8	10	TO FIX	TO FIX
9	11	=======	=======

File notes/code/sql/HW_FACULTY.sql changed (mode: 100644) (index 81becd9..8157e45)
...	...	CREATE DATABASE HW_FACUTLY;
8	8
9	9	CREATE TABLE HW_FACULTY.PROF(	CREATE TABLE HW_FACULTY.PROF(
10	10	Fname VARCHAR(15), -- No String!	Fname VARCHAR(15), -- No String!
11		Room INT, -- shorthad for INTEGER, are also available: SMALLINT, FLOAT, REAL, DEC
12		Title CHAR(3), -- fixed-length string, padded with blanks if needed
	11		Room INT, -- shorthad for INTEGER, are also available: SMALLINT, FLOAT, REAL, DEC
	12		-- The "REAL" datatype is like the "DOUBLE" datatype of C# (they are actually synonyms in SQL):
	13		-- more precise than the "FLOAT" datatype, but not as exact as the "NUMERIC" datatype.
	14		-- cf. https://dev.mysql.com/doc/refman/8.0/en/numeric-types.html
	15		Title CHAR(3), -- fixed-length string, padded with blanks if needed
13	16	Tenured BIT(1),	Tenured BIT(1),
14		Nice BOOLEAN, -- True / False (= 0) / Unknown
15		Hiring DATE,
	17		Nice BOOLEAN, -- True / False (= 0) / Unknown
	18		Hiring DATE, -- The DATE is always supposed to be entered in a YEAR/MONTH/DAY variation.
	19		-- To tune the way it will be displayed, you can use the "DATE_FORMAT" function
	20		-- (cf. https://dev.mysql.com/doc/refman/8.0/en/date-and-time-functions.html#function_date-format),
	21		-- but you can enter those values only using the "standard" literals
	22		-- (cf. https://dev.mysql.com/doc/refman/8.0/en/date-and-time-literals.html )
16	23	Last_seen TIME,	Last_seen TIME,
17	24	FavoriteFruit ENUM('apple','orange','pear'),	FavoriteFruit ENUM('apple','orange','pear'),
18	25	PRIMARY KEY(Fname, Hiring)	PRIMARY KEY(Fname, Hiring)

File notes/fig/er/Book.tex added (mode: 100644) (index 0000000..b227341)
	1	\documentclass[border=20pt]{standalone}
	2	\input{template.def}
	3
	4	\begin{tikzpicture}[node distance=5em]
	5	\node [entity] (PERSON) {PERSON};
	6	\node [relationship] (BOUGHT) [right=of PERSON] {BOUGHT} edge node[above]{$\cM$} (PERSON);
	7	\node [entity] [right = of BOUGHT] {BOOK} edge node[above]{$\cN$} (BOUGHT);
	8	\node [entity] [below = of BOUGHT] {LIBRARY} edge node[left]{$\cO$} (BOUGHT);
	9	\end{tikzpicture}
	10	\end{document}

File notes/fig/er/Book2.tex added (mode: 100644) (index 0000000..98c4cbb)
	1	\documentclass[border=20pt]{standalone}
	2	\input{template.def}
	3
	4	\begin{tikzpicture}[node distance=8em]
	5	\node [entity] (PERSON) {PERSON};
	6	\node [relationship] (POSSESSES) [right=of PERSON] {POSSESSES} edge node[above]{$1$} (PERSON);
	7	\node [entity] (BOOK) [right = of POSSESSES] {BOOK} edge node[above]{$\cN$} (POSSESSES);
	8	\node [relationship] (SELLS) [below left = 1cm of BOOK] {SOLD BY} edge node[below right]{$\cM$} (BOOK);
	9	\node [entity] (LIBRARY) [below = of POSSESSES] {LIBRARY} edge node[left]{$\cO$} (SELLS);
	10	\node [relationship] (VISITS) [below right = 1.8cm of PERSON] {VISITS} edge node[above right]{$\cN$} (LIBRARY) edge node[above right]{$\cO$} (PERSON);
	11	\end{tikzpicture}
	12	\end{document}

File notes/fig/er/Computer_User.tex added (mode: 100644) (index 0000000..da638ea)
	1	\documentclass[border=20pt]{standalone}
	2	\input{template.def}
	3
	4	\begin{tikzpicture}[node distance=7em]
	5	\node[entity] (COMPUTER) {COMPUTER};
	6	\node[attribute] (mid) [left of=COMPUTER] {\key{MAC}} edge (COMPUTER);
	7	\node[multi attribute] (User) [right of=COMPUTER] {User} edge (COMPUTER);
	8	\node[attribute] [above right of=User] {Name} edge (User);
	9	\node[attribute] [right of=User] {Email} edge (User);
	10	\end{tikzpicture}
	11
	12	\end{document}

File notes/fig/er/Desk.tex added (mode: 100644) (index 0000000..3e00be8)
	1	\documentclass[border=20pt]{standalone}
	2	\input{template.def}
	3
	4	\begin{tikzpicture}[node distance=7em]
	5	\node[entity] (DESK) {DESK};
	6	\node[attribute] (pid) [left of=DESK] {\key{Serial}} edge (DESK);
	7	\node[multi attribute] [above of=DESK] {Color} edge (DESK);
	8	\node[attribute] (Location) [right of=DESK] {Location} edge (DESK);
	9	\node[attribute] [above right of=Location] {Building} edge (Location);
	10	\node[attribute] [right of=Location] {Room} edge (Location);
	11	\end{tikzpicture}
	12
	13	\end{document}

File notes/fig/er/Doula.tex added (mode: 100644) (index 0000000..564a1cf)
	1	\documentclass[border=20pt]{standalone}
	2	\input{template.def}
	3
	4	\begin{tikzpicture}[node distance=8em]
	5	\node[entity] (HEALTHCAREPROVIDER) {HEALTH\_CARE\_PROVIDER};
	6	\node[ident relationship] (COVERS) [below right of=HEALTHCAREPROVIDER] {COVERS} edge node[above, pos=0.3] {$1$} (HEALTHCAREPROVIDER);
	7	\node[weak entity] (PERSON) [right = 1cm of COVERS] {INSUREE} edge[total] node[above, pos=0.7] {$\cN$} (COVERS);
	8	\node[ident relationship] (ISFOLLOWEDBY) [above right of =PERSON] {IS FOLLOWED BY} edge node[above, pos=0.7] {$1$} (PERSON);
	9	\node[weak entity] (DOULA) [right = 1cm of ISFOLLOWEDBY] {DOULA} edge[total] node[above, pos=0.3] {$\cM$} (ISFOLLOWEDBY);
	10	\end{tikzpicture}
	11
	12	\end{document}

File notes/fig/er/Gym.tex changed (mode: 100644) (index 86d3fbb..9470d04)
3	3
4	4	\begin{tikzpicture}[node distance=5em]	\begin{tikzpicture}[node distance=5em]
5	5	\node [entity] (MEMBER) {MEMBER};	\node [entity] (MEMBER) {MEMBER};
6		\node [relationship] (RESERVES) [right=of MEMBER] {RESERVES} edge node[above]{$(0,1)$} (MEMBER);
7		\node [entity] [right = of RESERVES] {EQUIPMENT} edge node[above]{$(0,1)$} (RESERVES);
8		\node [entity] [below = of RESERVES] {TIME\_SLOT} edge node[left]{$(0, \cN)$} (RESERVES);
	6		\node [relationship] (RESERVES) [right=of MEMBER] {RESERVES} edge node[above]{$1$} (MEMBER);
	7		\node [entity] [right = of RESERVES] {EQUIPMENT} edge node[above]{$1$} (RESERVES);
	8		\node [entity] [below = of RESERVES] {TIME\_SLOT} edge node[left]{$\cN$} (RESERVES);
9	9	\end{tikzpicture}	\end{tikzpicture}
10	10	\end{document}	\end{document}

File notes/fig/er/MappingRelationships1.tex added (mode: 100644) (index 0000000..adea4ed)
	1	\documentclass[border=20pt]{standalone}
	2	\input{template.def}
	3
	4	\begin{tikzpicture}[node distance=7em]
	5	\node[relationship] (contains){REL.};
	6	\node[entity] (ENTA) [left = 1cm of contains] {ENT. A} edge[total] node[above] {$1$} (contains);
	7	\node[attribute] [above of= ENTA] {\key{KeyA}} edge (ENTA);
	8	\node[entity] (ENTB) [right = 1cm of contains] {ENT. B} edge node[above]{$1$} (contains);
	9	\node[attribute] [above of= ENTB] {\key{KeyB}} edge (ENTB);
	10	\end{tikzpicture}
	11
	12	\end{document}

File notes/fig/er/MappingRelationships2.tex added (mode: 100644) (index 0000000..3f62bde)
	1	\documentclass[border=20pt]{standalone}
	2	\input{template.def}
	3
	4	\begin{tikzpicture}[node distance=7em]
	5	\node[relationship] (contains){REL.};
	6	\node[entity] (ENTA) [left = 1cm of contains] {ENT. A} edge[total] node[above] {$1$} (contains);
	7	\node[attribute] [above of= ENTA] {\key{KeyA}} edge (ENTA);
	8	\node[entity] (ENTB) [right = 1cm of contains] {ENT. B} edge[total] node[above]{$1$} (contains);
	9	\node[attribute] [above of= ENTB] {\key{KeyB}} edge (ENTB);
	10	\end{tikzpicture}
	11
	12	\end{document}

File notes/fig/er/Software_Dep.tex added (mode: 100644) (index 0000000..4006738)
	1	\documentclass[border=20pt]{standalone}
	2	\input{template.def}
	3
	4	\begin{tikzpicture}[node distance=5em]
	5	\node [entity] (SOFTWARE) {SOFTWARE};
	6	\node [relationship] (REQUIRES) [above=of SOFTWARE] {REQUIRES};
	7	\draw (REQUIRES.east) -- node[right]{Requirement} node[right, pos = 0.8]{$\cN$} (SOFTWARE);
	8	\draw (REQUIRES.west) -- node[left, pos = 0.8]{$\cM$}(SOFTWARE);
	9	\node [attribute] (id) [right= .5cm of SOFTWARE] {\key{Id}} edge (SOFTWARE);
	10	\node [attribute, above right of = id] {Version} edge (id);
	11	\node [attribute, below right of = id] {Name} edge (id);
	12	\end{tikzpicture}
	13
	14	\end{document}

File notes/fig/fd/DriverExample1.tex copied from file notes/fig/fd/Example2NF1.tex (similarity 52%) (mode: 100644) (index 3580f2f..4ad8c7d)
3	3
4	4	\begin{dependency}	\begin{dependency}
5	5	\begin{deptext}[TxtBook] % Applying the TxtBook style.	\begin{deptext}[TxtBook] % Applying the TxtBook style.
6		\|[none]\| $R \big($ \& \ul{$A_1$} \& \ul{$A_2$} \& $A_3$ \& $A_4$ \& $A_5$ \& \|[none]\| $\big)$\\
	6		\|[none]\| DRIVER $\big($ \& State \& Driver\_Licence\_Num \& Name \& Governor) \& \|[none]\| $\big)$\\
7	7	\end{deptext}	\end{deptext}
8		\depedge[lvl=2]{2}{4}{}
	8		\depedge[lvl=1]{2}{4}{}
9	9	\depedge[lvl=1]{3}{4}{}	\depedge[lvl=1]{3}{4}{}
10		\depedge[lvl=3]{2}{5}{}
11		\depedge[lvl=4]{2}{6}{}
	10		\depedge[lvl=1, edge above]{2}{5}{}
12	11	\end{dependency}	\end{dependency}
13	12
14	13	\end{document}	\end{document}

File notes/fig/fd/DriverExample2.tex added (mode: 100644) (index 0000000..696ae3c)
	1	\documentclass[margin=20pt]{standalone}
	2	\input{template.def}
	3
	4	\begin{dependency}
	5	\begin{deptext}[TxtBook] % Applying the TxtBook style.
	6	\|[none]\| DRIVER $\big($ \& \ul{State} \& \ul{Driver\_Licence\_Num} \& Name) \& \|[none]\| $\big)$ \& \|[none]\| GOVERNOR $\big($ \& \ul{State} \& Governor \& \|[none]\| $\big)$\\
	7	\end{deptext}
	8	\depedge[lvl=1]{2}{4}{}
	9	\depedge[lvl=1]{3}{4}{}
	10	\depedge[lvl=1]{7}{8}{}
	11	\depedge[lvl=1, FK, edge above]{7}{2}{}
	12	\end{dependency}
	13
	14
	15
	16	\end{document}

File notes/fig/fd/Example2NF1.tex changed (mode: 100644) (index 3580f2f..69e9586)
5	5	\begin{deptext}[TxtBook] % Applying the TxtBook style.	\begin{deptext}[TxtBook] % Applying the TxtBook style.
6	6	\|[none]\| $R \big($ \& \ul{$A_1$} \& \ul{$A_2$} \& $A_3$ \& $A_4$ \& $A_5$ \& \|[none]\| $\big)$\\	\|[none]\| $R \big($ \& \ul{$A_1$} \& \ul{$A_2$} \& $A_3$ \& $A_4$ \& $A_5$ \& \|[none]\| $\big)$\\
7	7	\end{deptext}	\end{deptext}
8		\depedge[lvl=2]{2}{4}{}
	8		\depedge[lvl=1, edge above]{2}{6}{}
	9		\depedge[lvl=1, edge above]{3}{6}{}
9	10	\depedge[lvl=1]{3}{4}{}	\depedge[lvl=1]{3}{4}{}
10		\depedge[lvl=3]{2}{5}{}
11		\depedge[lvl=4]{2}{6}{}
	11		\depedge[lvl=1]{3}{5}{}
12	12	\end{dependency}	\end{dependency}
13	13
14	14	\end{document}	\end{document}

File notes/fig/fd/Example2NF2.tex changed (mode: 100644) (index c70eced..c364a66)
6	6	\|[none]\| $R \big($ \& \ul{$A_1$} \& \ul{$A_2$} \& $A_5$ \& \|[none]\| $\big)$ \& \|[none]\| $R' \big($ \& \ul{$A_2$} \& $A_3$ \& \|[none]\| $\big)$ \& \|[none]\| $R'' \big($ \& \ul{$A_2$} \& $A_4$\& \|[none]\| $\big)$\\	\|[none]\| $R \big($ \& \ul{$A_1$} \& \ul{$A_2$} \& $A_5$ \& \|[none]\| $\big)$ \& \|[none]\| $R' \big($ \& \ul{$A_2$} \& $A_3$ \& \|[none]\| $\big)$ \& \|[none]\| $R'' \big($ \& \ul{$A_2$} \& $A_4$\& \|[none]\| $\big)$\\
7	7	\end{deptext}	\end{deptext}
8	8	\depedge[lvl=1]{2}{4}{}	\depedge[lvl=1]{2}{4}{}
9		\depedge[lvl=2]{3}{4}{}
	9		\depedge[lvl=1]{3}{4}{}
10	10	\depedge[lvl=1]{7}{8}{}	\depedge[lvl=1]{7}{8}{}
11	11	\depedge[lvl=1]{11}{12}{}	\depedge[lvl=1]{11}{12}{}
12	12	\depedge[lvl=1, FK, edge above]{7}{3}{}	\depedge[lvl=1, FK, edge above]{7}{3}{}

File notes/fig/fd/Example2NF3.tex changed (mode: 100644) (index da1b16a..be82209)
6	6	\|[none]\| $R \big($ \& \ul{$A_1$} \& \ul{$A_2$} \& $A_5$ \& \|[none]\| $\big)$ \& \|[none]\| $R' \big($ \& \ul{$A_2$} \& $A_3$ \& $A_4$ \& \|[none]\| $\big)$\\	\|[none]\| $R \big($ \& \ul{$A_1$} \& \ul{$A_2$} \& $A_5$ \& \|[none]\| $\big)$ \& \|[none]\| $R' \big($ \& \ul{$A_2$} \& $A_3$ \& $A_4$ \& \|[none]\| $\big)$\\
7	7	\end{deptext}	\end{deptext}
8	8	\depedge[lvl=1]{2}{4}{}	\depedge[lvl=1]{2}{4}{}
9		\depedge[lvl=2]{3}{4}{}
	9		\depedge[lvl=1]{3}{4}{}
10	10	\depedge[lvl=1]{7}{8}{}	\depedge[lvl=1]{7}{8}{}
11	11	\depedge[lvl=1]{7}{9}{}	\depedge[lvl=1]{7}{9}{}
12	12	\depedge[lvl=1, FK, edge above]{7}{3}{}	\depedge[lvl=1, FK, edge above]{7}{3}{}

File notes/fig/fd/StudentExample1.tex copied from file notes/fig/fd/Example2NF1.tex (similarity 52%) (mode: 100644) (index 3580f2f..5675e56)
3	3
4	4	\begin{dependency}	\begin{dependency}
5	5	\begin{deptext}[TxtBook] % Applying the TxtBook style.	\begin{deptext}[TxtBook] % Applying the TxtBook style.
6		\|[none]\| $R \big($ \& \ul{$A_1$} \& \ul{$A_2$} \& $A_3$ \& $A_4$ \& $A_5$ \& \|[none]\| $\big)$\\
	6		\|[none]\| STUDENT $\big($ \& \ul{Login} \& Name \& Major \& Major\_Head) \& \|[none]\| $\big)$\\
7	7	\end{deptext}	\end{deptext}
8		\depedge[lvl=2]{2}{4}{}
	8		\depedge[lvl=1]{2}{4}{}
9	9	\depedge[lvl=1]{3}{4}{}	\depedge[lvl=1]{3}{4}{}
10		\depedge[lvl=3]{2}{5}{}
11		\depedge[lvl=4]{2}{6}{}
	10		% \depedge[lvl=1]{2}{5}{}
	11		\depedge[lvl=1, edge above]{4}{5}{}
12	12	\end{dependency}	\end{dependency}
13	13
14	14	\end{document}	\end{document}

File notes/fig/fd/StudentExample2.tex added (mode: 100644) (index 0000000..4c64174)
	1	\documentclass[margin=20pt]{standalone}
	2	\input{template.def}
	3
	4	\begin{dependency}
	5	\begin{deptext}[TxtBook] % Applying the TxtBook style.
	6	\|[none]\| STUDENT $\big($ \& \ul{Login} \& Name \& Major ) \& \|[none]\| $\big)$ \& \|[none]\| HEAD $\big($ \& \ul{Major} \& Major\_Head \& \|[none]\| $\big)$\\
	7	\end{deptext}
	8	\depedge[lvl=1]{2}{4}{}
	9	\depedge[lvl=1]{3}{4}{}
	10	\depedge[lvl=1]{7}{8}{}
	11	% \depedge[lvl=1, edge above]{4}{5}{}
	12	\depedge[lvl=1, FK, edge above]{7}{4}{}
	13	\end{dependency}
	14
	15	\end{document}

File notes/fig/rel_mod/COMPUTER_USER.tex added (mode: 100644) (index 0000000..be4d792)
	1	\documentclass[border=20pt]{standalone}
	2	\input{template.def}
	3
	4	% COMPUTER(MAC(PK))
	5	% COMPUTER_COLOR(Compter (PK, FK referencing COMPUTER.MAC), Name, Email)
	6
	7	\Frame(0,0){1}[COMPUTER]{
	8	MAC/PK};
	9
	10	\Frame(5, 0){2}[COMPUTER\_USER]{
	11	Computer/PK,
	12	Name/A,
	13	Email/A};
	14
	15	\draw[FK] % From COMPUTER_COLOR.Desk to COMPUTER.MAC
	16	(MAC1)++(0,0) -- ++(0,-.5) -- ++(-0,0) coordinate (inter)
	17	-- (Computer2 \|- inter) --++(0,0.5);
	18	\end{tikzpicture}
	19	\end{document}

File notes/fig/rel_mod/DESK.tex added (mode: 100644) (index 0000000..96caeb3)
	1	\documentclass[border=20pt]{standalone}
	2	\input{template.def}
	3
	4	% DESK(Serial(PK), Building, Room)
	5	% DESK_COLOR(Desk (PK, FK referencing DESK.Serial))
	6
	7	\Frame(0,0){1}[DESK]{
	8	Serial/PK,
	9	Building/A,
	10	Room/A};
	11
	12	\Frame(5, 0){2}[DESK\_COLOR]{
	13	Desk/PK,
	14	Color/A};
	15
	16	\draw[FK] % From DESK_COLOR.Desk to DESK.Serial
	17	(Serial1)++(0,0) -- ++(0,-.5) -- ++(-0,0) coordinate (inter)
	18	-- (Desk2 \|- inter) --++(0,0.5);
	19	\end{tikzpicture}
	20	\end{document}

File notes/fig/rel_mod/MappingRelationships2.tex added (mode: 100644) (index 0000000..65409b4)
	1	\documentclass[border=20pt]{standalone}
	2	\input{template.def}
	3
	4	% ENT.A(KeyA (PK))
	5	% ENT.B(KeyB (PK))
	6	% MAPPING(KeyA (PK, FK referencing ENT.A.KeyA), KeyB(FK referencing ENT.B.KeyB))
	7
	8	\Frame(0,0){1}[ENT.A]{
	9	KeyA/PK};
	10
	11
	12	\Frame(4, 0){2}[MAPPING]{
	13	KeyA/PK,
	14	KeyB/A};
	15
	16	\Frame(8, 0){3}[ENT.B]{
	17	KeyB/PK};
	18
	19	\draw[FK] % From MAPPING.KeyA to ENT.A.KeyA
	20	(KeyA1)++(0,0) -- ++(0,-.5) -- ++(-0,0) coordinate (inter)
	21	-- (KeyA2 \|- inter) --++(0,0.5);
	22
	23	\draw[FK] % From MAPPING.KeyB to ENT.B.KeyB
	24	(KeyB3)++(0,0) -- ++(0,-.5) -- ++(-0,0) coordinate (inter)
	25	-- (KeyB2 \|- inter) --++(0,0.5);
	26	\end{tikzpicture}
	27	\end{document}

File notes/fig/rel_mod/MappingRelationships3.tex copied from file notes/fig/uml/Generalization.tex (similarity 53%) (mode: 100644) (index 08a00b4..7ed05a9)
1	1	\documentclass[border=20pt]{standalone}	\documentclass[border=20pt]{standalone}
2	2	\input{template.def}	\input{template.def}
3	3
4		\begin{tikzpicture}
5		\draw[>=open triangle 60,->] (0,0) to (1,0);
6		\end{tikzpicture}
	4		% ENT.A.AND.B.(KeyA (PK), KeyB)
7	5
	6		\Frame(0,0){1}[ENT.A.AND.B.]{
	7		KeyA/PK,
	8		KeyB/A};
	9		\end{tikzpicture}
8	10	\end{document}	\end{document}

File notes/fig/rel_mod/MappingRelationships4.tex added (mode: 100644) (index 0000000..5d4bbe9)
	1	\documentclass[border=20pt]{standalone}
	2	\input{template.def}
	3
	4	% ENT.A(KeyA (PK), Rel(FK referencing Ent.A.KeyA))
	5
	6	\Frame(0,0){1}[ENT.A]{
	7	KeyA/PK,
	8	Rel/A};
	9
	10	\draw[FK] % From MAPPING.KeyA to ENT.A.KeyA
	11	(KeyA1)++(0,0) -- ++(0,-.5) -- ++(-0,0) coordinate (inter)
	12	-- (Rel1 \|- inter) --++(0,0.5);
	13
	14	\end{tikzpicture}
	15	\end{document}

File notes/fig/rel_mod/MappingRelationships5.tex added (mode: 100644) (index 0000000..b512773)
	1	\documentclass[border=20pt]{standalone}
	2	\input{template.def}
	3
	4	% ENT.A(KeyA (PK))
	5	% REL(KeyA1 (PK, FK referencing Ent.A.KeyA), KeyA2 (FK referencing Ent.A.KeyA))
	6
	7	\Frame(0,0){1}[ENT.A]{
	8	KeyA/PK};
	9
	10	\Frame(4, 0){2}[REL]{
	11	KeyA1/PK,
	12	KeyA2/A};
	13
	14	\draw[FK] % From REL.KeyA to ENT.A.KeyA
	15	(KeyA1)++(.1,0) -- ++(0,-.5) -- ++(-0,0) coordinate (inter)
	16	-- (KeyA12 \|- inter) --++(0,0.5);
	17
	18	\draw[FK] % From REL.KeyA to ENT.A.KeyA
	19	(KeyA1)++(-.1,0) -- ++(0,-.8) -- ++(-0,0) coordinate (inter)
	20	-- (KeyA22 \|- inter) --++(0,0.8);
	21	\end{tikzpicture}
	22	\end{document}

File notes/img/ER_To_Rel1.jpeg deleted (index 808b4e5..0000000)

File notes/lectures_notes.md changed (mode: 100644) (index 28dac44..10f66bc)
...	...	The three last sublanguages being dubbed "Data Manipulation Language
1069	1069	\| "Common" / Relational \| SQL \|	\| "Common" / Relational \| SQL \|
1070	1070	\| :--: \| :--: \|	\| :--: \| :--: \|
1071	1071	\| "Database" \| Schema \|	\| "Database" \| Schema \|
1072		\| "Set of databases" \| Catalog (collection of named schema) \|
	1072		\| "Set of databases" \| Catalog (named collection of schema)^[For a clarification on the distinction between catalog and schemas, you can refer to e.g. <https://stackoverflow.com/q/7022755>.] \|
1073	1073	\| Relation \| Table \|	\| Relation \| Table \|
1074	1074	\| Tuple \| Row \|	\| Tuple \| Row \|
1075	1075	\| Attribute \| Column, or Field \|	\| Attribute \| Column, or Field \|

...	...	SELECT FROM DEPARTMENT WHERE Head IS NOT NULL;*
1681	1681	SELECT COUNT(*) FROM GRADE WHERE Grade IS NULL;	SELECT COUNT(*) FROM GRADE WHERE Grade IS NULL;
1682	1682	~~~	~~~
1683	1683
	1684		There are no `if…then…else` statements in `SQL`, but you can do something similar with `CASE` (cf. <https://dev.mysql.com/doc/refman/8.0/en/case.html>).
	1685		However, note that `SQL` is probably _not_ the right place to try to control the flow of execution.
	1686
	1687		Even with three times (!) the verbose option, MySQL does not give more insight as to whenever it drops comparing values once a NULL was encountered (cf. <https://dev.mysql.com/doc/refman/8.0/en/mysql-command-options.html#option_mysql_verbose>, you can log-in using `mysql -u testuser -p --password=password -v -v -v` to activate the most verbose mode).
	1688		Normally, `EXPLAIN` (<https://dev.mysql.com/doc/refman/8.0/en/explain.html>) should be useful in determining whenever MySQL uses some form of short-cut evaluation when comparing with `NULL`{.sqlmysql}, but I could not make it work.
	1689
1684	1690	## Various Tools	## Various Tools
1685	1691
1686	1692	For `DISTINCT`, `ALL` and `UNION`, cf. [@Textbook6, 4.3.4] or [@Textbook7, 6.3.4].	For `DISTINCT`, `ALL` and `UNION`, cf. [@Textbook6, 4.3.4] or [@Textbook7, 6.3.4].
1687	1693	For `ORDER BY` , cf. [@Textbook6, 4.3.6] or [@Textbook7, 6.3.6].	For `ORDER BY` , cf. [@Textbook6, 4.3.6] or [@Textbook7, 6.3.6].
1688	1694	For aggregate functions, cf. [@Textbook6, 5.1.7] or [@Textbook7, 7.1.7].	For aggregate functions, cf. [@Textbook6, 5.1.7] or [@Textbook7, 7.1.7].
1689	1695
	1696		## AUTO_INCREMENT
	1697
	1698		Something that is not exactly a constraint, but that can be used to "qualify" domains, is the `AUTO_INCREMENT`{.sqlmysql} feature of MySQL.
	1699		Cf. <https://dev.mysql.com/doc/refman/8.0/en/example-auto-increment.html>, you can have MySQL increment a particular attribute (most probably intended to be your primary key) for you.
	1700
1690	1701
1691	1702	### Transactions	### Transactions
1692	1703

...	...	We indicate the ratio on the edges:
3820	3831
3821	3832	![](fig/er/Constraint1)	![](fig/er/Constraint1)
3822	3833
	3834		Note that reflexive relations can have any ratio as well.
	3835		An example of $M:N$ recursive relation could be:
	3836
	3837		![](fig/er/Software_Dep)
	3838
3823	3839	##### Participation constraint	##### Participation constraint
3824	3840
3825	3841	Minimum number of relationships instances that an entity can participat it, a.k.a. "minimum cardinality constraint".	Minimum number of relationships instances that an entity can participat it, a.k.a. "minimum cardinality constraint".

...	...	As an exercise, you can look at the relationships TEACHING, MENTORING and EMITED
3859	3875
3860	3876	#### Relationships of degree higher than two	#### Relationships of degree higher than two
3861	3877
3862		To determine cardinality ratio: fix all but one, wonder how many can be in that relationship.
3863
	3878		Of course, relationships can have a degree higher than two.
3864	3879	An example of a ternary relation could be:	An example of a ternary relation could be:
3865	3880
3866	3881	![](fig/er/Account)	![](fig/er/Account)
3867	3882
3868		The idea is that Customer Y and Bank Z could be in relationship with more than $1$ account (hence the "N").
	3883		To determine cardinality ratio, one should fix all but one parameters, and wonder how many values of the remaining parameter can be in that relationship.
	3884
	3885		Four our example, Customer Y and Bank Z could be in relationship with more than $1$ account (hence the "N").
3869	3886	On the oppsite, Customer Y and Account K would be in relationship with only $1$ bank (hence the "1" on the bottom), and Bank Z and Account K would belong to only $1$ customer (hence the $1$ on the left).	On the oppsite, Customer Y and Account K would be in relationship with only $1$ bank (hence the "1" on the bottom), and Bank Z and Account K would belong to only $1$ customer (hence the $1$ on the left).
3870	3887
	3888		It is sometimes impossible to do without relations with arity greater than $2$.
	3889		For instance, consider the following two diagrams:
	3890
	3891		![](fig/er/Book)
	3892
	3893		![](fig/er/Book2)
	3894
	3895		You should realize that they convey different information.
	3896		For instance, you can know for a fact that a person visit a library only if they bought something in it, while the second diagram de-correlate the act of buying with the visit to a library.
	3897		Similarly, the second diagram could give you a hint that a person that owns a copy of a book Z and visits a library X that sells it could also visit it, but you won't know that for sure.
	3898
3871	3899	An example of recursive ternary relation could be:	An example of recursive ternary relation could be:
3872	3900
3873	3901	![](fig/er/Parents)	![](fig/er/Parents)

...	...	Whenever the pet entity type is involved in other relationships or not should he
3921	3949	- Owner can itself be weak!	- Owner can itself be weak!
3922	3950	- The degree of the identifying relationship can be more than 2 (cf. e.g., <https://stackoverflow.com/q/15393587/>).	- The degree of the identifying relationship can be more than 2 (cf. e.g., <https://stackoverflow.com/q/15393587/>).
3923	3951
	3952		Another example of weak entity whose owner is weak as well could be:
	3953
	3954		![](fig/er/Doula)
	3955
	3956		The idea being that the Health care provider cares about an insuree only if they are covered by them, and that they care about the doula only if they are currently helping one of their insuree.
	3957
3924	3958	### Alternative Notations {#sec:alternative-notation}	### Alternative Notations {#sec:alternative-notation}
3925	3959
3926	3960	Multiple notations have been used to represent the ratio and constraint on relationship.	Multiple notations have been used to represent the ratio and constraint on relationship.

...	...	Using four tools: Relations, Attributes, Primary Keys, Foreign Keys.
4005	4039
4006	4040	### Algorithm	### Algorithm
4007	4041
	4042		We will use three techniques to represent some of the relationships, the foreign key approach, the merged relations approach and the cross-reference approach.
	4043		They are detailled and illustrated after the algorithm, which goes as follows:
	4044
4008	4045	\# \| \| is mapped to \|	\# \| \| is mapped to \|
4009	4046	-- \| ---------- \| ----------------	-- \| ---------- \| ----------------
4010		1 \| Strong Entity \| Relation with all the simple attributes. Decompose complex attributes. Pick a key to be the PK, if it is composite, take its elements.
4011		2 \| Weak Entity \| Relation with all the simple attributes. Decompose complex attributes. Add as a foreign key the primary key of the relation corresponding to the owner entity type, and make it a primary key. If the owner entity type is itself weak, start with it.
	4047		1 \| Strong Entity \| Relation with all the simple attributes. Decompose complex (composite) attributes. Pick a key to be the PK, if it is composite, take its elements.
	4048		2 \| Weak Entity \| Relation with all the simple attributes. Decompose complex attributes. Add as a foreign key the primary key of the relation corresponding to the owner entity type, and make it a primary key, in addition to the partial key of the weak entity. If the owner entity type is itself weak, start with it.
4012	4049	3 \| Binary $1:1$ Relationship Types \| Foreign Key, Merge Relations or Cross-Reference approach	3 \| Binary $1:1$ Relationship Types \| Foreign Key, Merge Relations or Cross-Reference approach
4013	4050	4 \| Binary $1:N$ Relationship Types \| Foreign Key or Cross-Reference approach	4 \| Binary $1:N$ Relationship Types \| Foreign Key or Cross-Reference approach
4014	4051	5 \| Binary $M:N$ Relationship Types \| Cross-Reference approach	5 \| Binary $M:N$ Relationship Types \| Cross-Reference approach
4015	4052	6 \| $n$-ary Relationship Types \| Cross-Reference approach	6 \| $n$-ary Relationship Types \| Cross-Reference approach
4016		7 \| Multivalued Attributes \| Create a new relation, whose primary key is the foreign key to the entity.
	4053		7 \| Multivalued Attributes \| Create a new relation, whose primary key is the foreign key to the relation corresponding to the entity.
4017	4054
4018	4055	#. Foreign Key Approach: Chose one of the relation (preferably with total participation constraint, or on the N side), add a foreign key and all the attributes of the relationship.	#. Foreign Key Approach: Chose one of the relation (preferably with total participation constraint, or on the N side), add a foreign key and all the attributes of the relationship.
4019	4056	#. Merged Relation Approach: If both participations are total, just merge them. Primary key = just pick one, and add a `NOT NULL` constraint on the other.	#. Merged Relation Approach: If both participations are total, just merge them. Primary key = just pick one, and add a `NOT NULL` constraint on the other.
4020		#. Cross-Reference or Relationship Relation Approach: Create a lookup table with two (or more!) foreign keys, pick one of them (or the one on the N side, or both if $M:N$, or all if $n$-ary) as the primary key.
	4057		#. Cross-Reference or Relationship Relation Approach: Create a lookup table with an appropriate number of foreign keys, pick some of them (the one on the $N$ side, both if the ratio is $M:N$, for $n$-ary it is a bit more complex, cf. example below) as the primary key.
	4058
	4059		Every time a relationships have attributes, they are mapped to the resultiong relation.
	4060
	4061		Let us look in more details at some of those steps.
	4062		For strong entities, using steps 1 and 7, the following:
	4063
	4064		![](fig/er/Desk)
	4065
	4066		would give:
	4067
	4068		![
	4069		DESK(Serial(PK), Building, Room)
	4070		DESK_COLOR(Desk (PK, FK referencing DESK.Serial))
	4071		](fig/rel_mod/DESK)
	4072		\
	4073
	4074
	4075		And note that if Serial was a complex attribute, we would just "unfold" it, or decompose it, and make all the resulting attributes the primary key of the relation.
	4076		If one of the attribute was at the same time multi-valued and composite, as follows:
	4077
	4078		![](fig/er/Computer_User)
4021	4079
4022		Bug: + Propagate option? Cascade, most of the time: weak entity type, lookup tables, etc.
	4080		Then we would obtain:
4023	4081
4024		![](img/ER_To_Rel1.jpeg){width=90%}
	4082		![
	4083		COMPUTER(MAC(PK))
	4084		COMPUTER_COLOR(Compter (PK, FK referencing COMPUTER.MAC), Name, Email)
	4085		](fig/rel_mod/COMPUTER_USER)
	4086		\
	4087
	4088		For relationships, things are a bit more complicated.
	4089		Consider the following:
	4090
	4091		![](fig/er/MappingRelationships1)
	4092
	4093		Since it is a $1:1$ relationship where one of the side has a partial constraint, we have the choice between two approaches.
	4094		The foreign key approach would give:
	4095
	4096		![
	4097		ENT.A(KeyA (PK), FK (FK to ENT.B.KeyB))
	4098		ENT.B(KeyB (PK))
	4099		](fig/rel_mod/MappingRelationships1)
	4100		\
	4101
	4102		Note that we could also have added the foreign key on the side of ENT.B, referencing the key of ENT.A.
	4103		But since ENT.A has a total participation constraint, we know that the value of FK will always exist, whereas some entities in ENT.B may not be in relationship with an entity from ENT.A, creating the (nefast) need for `NULL`{.sqlmysql} values.
	4104
	4105		For the same diagram, the cross-reference approach would give:
	4106
	4107		![
	4108		ENT.A(KeyA (PK))
	4109		ENT.B(KeyB (PK))
	4110		MAPPING(KeyA (PK, FK referencing ENT.A.KeyA), KeyB(FK referencing ENT.B.KeyB))
	4111		](fig/rel_mod/MappingRelationships2)
	4112		\
	4113
	4114		Similarly, note that, in MAPPING, KeyB, or KeyA and KeyB, would also be valid primary keys, but that it makes more sense to have KeyA being the primary key, since we know that ENT.A has a total participation constraint, but ENT.B does not.
	4115
	4116		If both participation constraints were total, as follows:
	4117
	4118		![](fig/er/MappingRelationships2)
	4119
	4120		Then we could use the merged relations approach, and get:
	4121
	4122		![
	4123		ENT.A.AND.B.(KeyA (PK), KeyB)
	4124		](fig/rel_mod/MappingRelationships3)
	4125		\
	4126
	4127		We picked KeyA to be the primary key for the same reason as before.
	4128		Note that merging the two entities into one relation also means that you have eventually to do some work on the relations that were referring to them.
	4129
	4130		Of course, if ENT.A and ENT.B are the same entity (that is, REL is recursive), we would get:
	4131
	4132		![
	4133		ENT.A(KeyA (PK), Rel(FK referencing Ent.A.KeyA))
	4134		](fig/rel_mod/MappingRelationships4)
	4135		\
	4136
	4137		or
	4138
	4139		![
	4140		ENT.A(KeyA (PK))
	4141		REL(KeyA1 (PK, FK referencing Ent.A.KeyA), KeyA2 (FK referencing Ent.A.KeyA))
	4142		](fig/rel_mod/MappingRelationships5)
	4143		\
	4144
	4145		depending on the approach we chose.
	4146
	4147		Binary $1:N$ and binary $M:N$ relationships are dealt with in a similar way, using foreign key or cross-reference approaches.
	4148		The most difficult part of the mapping is with $n$-ary relationships: we have to use cross-reference approaches, but determining the primary key is not an easy task.
	4149		Consider the following^[This developement was actually asked at <https://dba.stackexchange.com/q/232068/>.]:
	4150
	4151		![](fig/er/Gym)
	4152
	4153		The arity constraints here can be rephrased as:
	4154
	4155		- A member can reserve a particular equipment at multiple time slots (the $N$),
	4156		- An equipment can be reserved at a particular time slot by only one member (the $1$ on the left),
	4157		- A member can reserve only one equipment per time slot (the $1$ on the right).
	4158
	4159		And note that there is no total participation constraint.
	4160
	4161		To reprent the RESRVES relationship, we need to create a relation with attributes referencing the primary key of MEMBER, the primary key of TIME\_SLOT, and the primary key of EQUIPMENT.
	4162		Making them all the primary key does not represent the fact that the same equipment cannot be booked twice during the same slot, nor that a member can book only one equipment per slot, but allows members to reserve a particular equipment at multiple time slots.
	4163		To improve this situation, we can either
	4164
	4165		#. take the foreign key to MEMBER and the foreign key to TIME\_SLOT to be the primary key of this relation,
	4166		#. or take the foreign key to EQUIPMENT and the foreign key to TIME\_SLOT to be the primary key of this relation.
	4167
	4168		Both solutions enforce only _some_ of the requirement expressed by the E.R. diagram.
4025	4169
4026	4170
4027	4171	### Outro	### Outro

...	...	Multivalued attribute \| Relation and foreign key
4038	4182	Value set \| Domain	Value set \| Domain
4039	4183	Key attribute \| Primary key	Key attribute \| Primary key
4040	4184
4041		Worked on PB 2 and 3 of HW4, that needs to be adapted. Needs to be written more properly. Cf. Drawing in Lecture 16's notes.
4042
4043		Need to work on a better example, includings $n$-ary relationship, and propagate options.
	4185		You can have a look at e.g. <http://holowczak.com/converting-e-r-models-to-relational-models/> to get a slightly different explanation of this conversion, and additional pointers.
4044	4186
4045	4187
4046	4188	## Guidelines and Normal Form	## Guidelines and Normal Form

...	...	Goals:
4054	4196	#. Minimum redundancy	#. Minimum redundancy
4055	4197	#. Make queries easy (avoid redundant work, make `select` / `join` easy)	#. Make queries easy (avoid redundant work, make `select` / `join` easy)
4056	4198
	4199		For E.R. diagrams, some of the usual techniques^[Cf. for instance <http://infolab.stanford.edu/~ullman/fcdb/aut07/slides/er.pdf>.] are:
	4200
	4201		- Limit the use of weak entity sets.
	4202		- Don't use an entity when an attribute will do.
	4203
4057	4204	### General rules	### General rules
4058	4205
4059	4206	#### Semantics	#### Semantics

...	...	Think about their dependencies, and list them:
4152	4299
4153	4300	"What is.", can disprove some of the assumptions made previously, but shouldn't add new dependencies based on it (they may be by chance!).	"What is.", can disprove some of the assumptions made previously, but shouldn't add new dependencies based on it (they may be by chance!).
4154	4301
4155		- Maybe `TEACHER.Office` → `TEACHER.Name` does not hold, because teachers share office?
4156		- Maybe `TEACHER.Name` → `MARKER.Brand` and `MARKER.Color` hold?
	4302		- Maybe `TEACHER.Office` → `TEACHER.Name` does not hold, because teachers share offices?
	4303		- Maybe `TEACHER.Name` → `MARKER.Brand` and `MARKER.Color` seemed to be enforced by the state, but we should not add a functional dependency based on that: there are no "requirement" that a Teacher must always buy the same brand and color, this could simply true be by chance so far and should not be imposed to the teachers.
4157	4304
4158	4305	A particular state cannot enforce a FD, but it can negate one.	A particular state cannot enforce a FD, but it can negate one.
4159	4306

...	...	For each attribute $A$ of the relation whose primary key is $A_1, …, A_n$:
4311	4458	- Remove $A$ from the original relation, as well as all the functional dependencies involving it,	- Remove $A$ from the original relation, as well as all the functional dependencies involving it,
4312	4459	- Add a foreign key from $\{A'_1, …, A'_k\}$ to their original counterparts in the original relation.	- Add a foreign key from $\{A'_1, …, A'_k\}$ to their original counterparts in the original relation.
4313	4460
4314		#### Notes and examples
	4461		#### Examples
	4462
	4463		We can have a look at another example:
	4464
	4465		![](fig/fd/DriverExample1)
	4466
	4467		Note that \{State, Driver\_Licence\_Num\}, would be a valid primary key for this relation, and that adding it would make it a relation in 1NF.
	4468
	4469		As we can see, the name "Driver" is somehow counter-intuitive, since the relation also carries information about Governors.
	4470		This relation is actually not in 2NF, because the FD \{State, Driver\_Licence\_Num\} → Governor is not fully functional.
	4471		A possible way to fix it is to get:
	4472
	4473		![](fig/fd/DriverExample2)
	4474
	4475		As you can see, the 2NF helped us in separating properly the entities.
	4476
	4477		An example of a relation that is in 2NF but not in 3NF could be:
	4478
	4479		![](fig/fd/StudentExample1)
	4480
	4481		As we can see, all the non-prime attributes are fully functionaly dependent from Login, which is our primary key.
	4482		But, obviously, one of this dependecy is transitive, and breaks the 3NF.
	4483		A way to fix it is:
	4484
	4485		![](fig/fd/StudentExample2)
4315	4486
4316		CCL: every FD $X → Y$ s.t. $X$ is a proper subset of the primary key, or a non-prime attribute, is problematic.
	4487		As we can see, 3NF also helped us in separating properly the entities, in a slightly different way.
	4488
	4489		In conclusion, we can observe that every FD $X → Y$ s.t. $X$ is a proper subset of the primary key, or a non-prime attribute, is problematic.
4317	4490	2NF is a guarantee that every entity has its own relation, 3NF is a way to avoid data inconsistency.	2NF is a guarantee that every entity has its own relation, 3NF is a way to avoid data inconsistency.
4318	4491
4319	4492	---	---

...	...	This last feature can be used for weak entities, but not only.
4420	4593
4421	4594	Some of those subtleties depend on your need, and are subjective, but are important tool to design properly a database, and relieving the programmer from the burden of figuring out many details.	Some of those subtleties depend on your need, and are subjective, but are important tool to design properly a database, and relieving the programmer from the burden of figuring out many details.
4422	4595
	4596		<!--
4423	4597	### Missing?	### Missing?
4424	4598
4425	4599	On Generalization	On Generalization

...	...	and
4429	4603	Example of Use Case	Example of Use Case
4430	4604
4431	4605	Example: cf. review session.	Example: cf. review session.
4432
	4606		-->
4433	4607
4434	4608	## Exercises {-}	## Exercises {-}
4435	4609

...	...	Author\_name \| → \| Author\_affil
5219	5393
5220	5394	---	---
5221	5395
5222
5223		Problem (From UML to relational model -- DRIVER) +.#UMLtoRELDriver
5224		~
5225
5226		Consider the UML diagram below, and convert it to the relational model.
5227		Don't forget to indicate primary and foreign keys.
5228
5229		![](fig/uml/Driver)
5230
5231		---
5232
5233	5396	Problem (Normal form of the CONTACT relation) +.#NormalizeContact	Problem (Normal form of the CONTACT relation) +.#NormalizeContact
5234	5397	~	~
5235	5398

...	...	Problem (From business statements to dependencies -- KEYBOARD) +.#BusinessToDepe
5323	5486	#. Based on those statements, what could be a key for this relation?	#. Based on those statements, what could be a key for this relation?
5324	5487	#. Assuming all those functional dependencies hold, and taking the primary key you identified at the previous step, what is the degree of normality of this relation? Justify your answer.	#. Assuming all those functional dependencies hold, and taking the primary key you identified at the previous step, what is the degree of normality of this relation? Justify your answer.
5325	5488
	5489		---
	5490
	5491		Problem (From UML to relational model -- DRIVER) +.#UMLtoRELDriver
	5492		~
	5493
	5494		Consider the UML diagram below, and convert it to the relational model.
	5495		Don't forget to indicate primary and foreign keys.
	5496
	5497		![](fig/uml/Driver)
	5498
5326	5499
5327	5500	## Solution to Selected Problems {-}	## Solution to Selected Problems {-}
5328	5501

Hints:
Before first commit, do not forget to setup your git environment:

git config --global user.name "your_name_here"
git config --global user.email "your@email_here"

Clone this repository using HTTP(S):

git clone https://rocketgit.com/user/caubert/CSCI_3410

Clone this repository using ssh (do not forget to upload a key first):

git clone ssh://rocketgit@ssh.rocketgit.com/user/caubert/CSCI_3410

Clone this repository using git:

git clone git://git.rocketgit.com/user/caubert/CSCI_3410

You are allowed to anonymously push to this repository.
This means that your pushed commits will automatically be transformed into a merge request:

... clone the repository ...
... make some changes and some commits ...
git push origin main

File notes/fig/fd/Example2NF2.tex changed (mode: 100644) (index c70eced..c364a66)
6	6	\|[none]\| \(R \big(\) \& \ul{\(A_1\)} \& \ul{\(A_2\)} \& \(A_5\) \& \|[none]\| \(\big)\) \& \|[none]\| \(R' \big(\) \& \ul{\(A_2\)} \& \(A_3\) \& \|[none]\| \(\big)\) \& \|[none]\| \(R'' \big(\) \& \ul{\(A_2\)} \& \(A_4\)\& \|[none]\| \(\big)\)\\	\|[none]\| \(R \big(\) \& \ul{\(A_1\)} \& \ul{\(A_2\)} \& \(A_5\) \& \|[none]\| \(\big)\) \& \|[none]\| \(R' \big(\) \& \ul{\(A_2\)} \& \(A_3\) \& \|[none]\| \(\big)\) \& \|[none]\| \(R'' \big(\) \& \ul{\(A_2\)} \& \(A_4\)\& \|[none]\| \(\big)\)\\
7	7	\end{deptext}	\end{deptext}
8	8	\depedge[lvl=1]{2}{4}{}	\depedge[lvl=1]{2}{4}{}
9		\depedge[lvl=2]{3}{4}{}
	9		\depedge[lvl=1]{3}{4}{}
10	10	\depedge[lvl=1]{7}{8}{}	\depedge[lvl=1]{7}{8}{}
11	11	\depedge[lvl=1]{11}{12}{}	\depedge[lvl=1]{11}{12}{}
12	12	\depedge[lvl=1, FK, edge above]{7}{3}{}	\depedge[lvl=1, FK, edge above]{7}{3}{}