List of commits:
Subject Hash Author Date (UTC)
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
Adding a problem and its solution, in the SQL chapter. d5bfcbb949a6acac68156a8b37d6f8d23375b1cb aubert@math.cnrs.fr 2019-02-19 19:53:27
Commit 7aa4b9a581daf7144dd485ba791b7707585088b8 - Fixing exercise and normalization in Chapter 4.
Author: aubert@math.cnrs.fr
Author date (UTC): 2019-03-20 18:55
Committer name: aubert@math.cnrs.fr
Committer date (UTC): 2019-03-20 18:55
Parent(s): 86a52b2f6ce92750bdb2c33eaa4dbc4497322e1c
Signer:
Signing key:
Signing status: N
Tree: bcc28acba2b39975014c655684cfcb00f57a0902
File Lines added Lines deleted
notes/fig/fd/Example2NF1.tex 3 3
notes/fig/fd/Example2NF2.tex 1 1
notes/fig/fd/Example2NF3.tex 1 1
notes/fig/uml/Flight_2.tex 18 0
notes/lectures_notes.md 97 85
File notes/fig/fd/Example2NF1.tex changed (mode: 100644) (index ba2b33b..3580f2f)
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=1]{2}{4}{}
8 \depedge[lvl=2]{2}{4}{}
9 9 \depedge[lvl=1]{3}{4}{} \depedge[lvl=1]{3}{4}{}
10 \depedge[lvl=1]{2}{5}{}
11 \depedge[lvl=1]{2}{6}{}
10 \depedge[lvl=3]{2}{5}{}
11 \depedge[lvl=4]{2}{6}{}
12 12 \end{dependency} \end{dependency}
13 13
14 14 \end{document} \end{document}
File notes/fig/fd/Example2NF2.tex changed (mode: 100644) (index c364a66..c70eced)
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=1]{3}{4}{}
9 \depedge[lvl=2]{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 be82209..da1b16a)
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=1]{3}{4}{}
9 \depedge[lvl=2]{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/uml/Flight_2.tex added (mode: 100644) (index 0000000..c4d7815)
1 \documentclass[border=20pt]{standalone}
2 \input{template.def}
3
4 \begin{tikzpicture}
5 \begin{class}[text width=7cm]{Pilot}{0,0}
6 \attribute{Id : Integer}
7 \attribute{Name : String}
8 \attribute{Experience : Level}
9 \end{class}
10 \begin{class}{Plane}{11, 0}
11 \attribute{tailId : Integer}
12 \attribute{MaxSpeed : MPH}
13 \attribute{AirPlaneType: Model}
14 \end{class}
15 \association{Plane}{}{1..*}{Pilot}{0..1}{}
16 \end{tikzpicture}
17
18 \end{document}
File notes/lectures_notes.md changed (mode: 100644) (index cda8733..28dac44)
... ... Refer to the ["A simplified database environment"](#fig:lab) figure , where
196 196
197 197 - The program can be written in any language, be a web interface, etc. - The program can be written in any language, be a web interface, etc.
198 198 - Most DBMS software include a Command-Line Interface (CLI), - Most DBMS software include a Command-Line Interface (CLI),
199 - Sometimes, meta-data and data are closer than pictured (you can have "self-describing meta-data", that is, they can't be distinguished).
199 - Sometimes, meta-data and data are closer than pictured (you can have "self-describing meta-data", that is, they cannot be distinguished).
200 200 Note also that "meta-data" has numerous definition ("data about the data"): we use it here to refer to the description of the organization of the data, and not e.g. statistical data about our data. Note also that "meta-data" has numerous definition ("data about the data"): we use it here to refer to the description of the organization of the data, and not e.g. statistical data about our data.
201 201
202 202 ## Database Management System (DBMS) ## Database Management System (DBMS)
 
... ... The relational data model (or relational database schema) is:
580 580 ### Types of constraints ### Types of constraints
581 581
582 582 We now study constraints *on the tuples*. We now study constraints *on the tuples*.
583 There are constraints on the scheme, for instance, "a relation can't have two attributes with the same name"
583 There are constraints on the scheme, for instance, "a relation cannot have two attributes with the same name"
584 584
585 585 #### Inherent model-based constraints (implicit) #### Inherent model-based constraints (implicit)
586 586
 
... ... Example: "the date of birth of an employee must be greater than xxx", "this year
606 606
607 607 ### Keys ### Keys
608 608
609 Tuples can't be equal, so a subset of values must distinguish them, we study the corresponding subset of attributes.
609 Tuples cannot be equal, so a subset of values must distinguish them, we study the corresponding subset of attributes.
610 610
611 611 - A **superkey** is the subset of attributes SK is a superkey for the relation R, if for all relation state r of R, all tuples t$_1$, t$_2$ in r are such that t$_1$[SK] $\neq$ t$_2$[SK]. - A **superkey** is the subset of attributes SK is a superkey for the relation R, if for all relation state r of R, all tuples t$_1$, t$_2$ in r are such that t$_1$[SK] $\neq$ t$_2$[SK].
612 612 - A **key** is a minimal superkey (i.e., removing any attribute from SK would break the uniqueness property). - A **key** is a minimal superkey (i.e., removing any attribute from SK would break the uniqueness property).
 
... ... Operations are of two kinds: retrievals and updates.
666 666 They are two constraints for updates: They are two constraints for updates:
667 667
668 668 #. The new relation state must be "valid" (i.e., comply with the state constraints). #. The new relation state must be "valid" (i.e., comply with the state constraints).
669 #. There might be transition constraints (your balance can't become negative, for instance).
669 #. There might be transition constraints (your balance cannot become negative, for instance).
670 670
671 671 A transaction is a series of retrievals and updates performed by an application program, that leaves the DB in a consistent state. A transaction is a series of retrievals and updates performed by an application program, that leaves the DB in a consistent state.
672 672
 
... ... Solution +.#
930 930 #. #. Yes, this instruction is valid. #. #. Yes, this instruction is valid.
931 931 #. No, it violates the entity integrity constraint: `NULL` can be given as a value to an attribute that is part of the PK. #. No, it violates the entity integrity constraint: `NULL` can be given as a value to an attribute that is part of the PK.
932 932 #. No, it violates the referential integrity constraint: `'XB-124` and `'GPalmer'` are not values in `TRAIN.Ref` and `CONDUCTOR.CompanyID`. #. No, it violates the referential integrity constraint: `'XB-124` and `'GPalmer'` are not values in `TRAIN.Ref` and `CONDUCTOR.CompanyID`.
933 #. No, it violates the key constraint: two tuples can't have the same value for the primary key.
933 #. No, it violates the key constraint: two tuples cannot have the same value for the primary key.
934 934
935 935 Solution +.# Solution +.#
936 936 ~ ~
 
... ... DESCRIBE <SQL command>; -- Gives explanations as to how the SQL command is proce
1132 1132 #. `DEFAULT`{.sqlmysql} #. `DEFAULT`{.sqlmysql}
1133 1133 #. `CHECK`{.sqlmysql} #. `CHECK`{.sqlmysql}
1134 1134
1135 We know 1. and 2. from the Relational Model, here comes new constraints that can't be describe in our relations.
1135 We know 1. and 2. from the Relational Model, here comes new constraints that cannot be describe in our relations.
1136 1136
1137 1137 ~~~{.sqlmysql .numberLines} ~~~{.sqlmysql .numberLines}
1138 1138 CREATE TABLE HURRICANE( CREATE TABLE HURRICANE(
 
... ... SELECT A.Name FROM PROF AS A, DEPARTMENT, STUDENT AS B
1845 1845 ~~~ ~~~
1846 1846
1847 1847 For those two, aliases were convenient, but not required to write the query. For those two, aliases were convenient, but not required to write the query.
1848 In some cases, we can't do without aliases, for instance if we want to compare two rows in the same table:
1848 In some cases, we cannot do without aliases, for instance if we want to compare two rows in the same table:
1849 1849
1850 1850 ~~~{.sqlmysql .numberLines} ~~~{.sqlmysql .numberLines}
1851 1851 SELECT Others.Login FROM GRADE AS Mine, GRADE AS Others SELECT Others.Login FROM GRADE AS Mine, GRADE AS Others
 
... ... WHERE DEPARTMENT IN ( SELECT Major
1890 1890 WHERE Login LIKE '%a'); WHERE Login LIKE '%a');
1891 1891 ~~~ ~~~
1892 1892
1893 Why can't we use `=`?
1893 Why cannot we use `=`?
1894 1894
1895 1895 Actually, nested query that uses `=` can often be rewritten without being nested: Actually, nested query that uses `=` can often be rewritten without being nested:
1896 1896
 
... ... Solution +.#
2530 2530
2531 2531 Solution +.# Solution +.#
2532 2532 ~ ~
2533 #. This operation is rejected: the row in the `DEPARTMENT`{.sqlmysql} table with primary key `Number`{.sqlmysql} set to `3`{.sqlmysql} can't be deleted if a row in the `WORKER`{.sqlmysql} table references it.
2533 #. This operation is rejected: the row in the `DEPARTMENT`{.sqlmysql} table with primary key `Number`{.sqlmysql} set to `3`{.sqlmysql} cannot be deleted if a row in the `WORKER`{.sqlmysql} table references it.
2534 2534 #. In the referencing rows, the department number is updated accordingly. #. In the referencing rows, the department number is updated accordingly.
2535 2535
2536 2536 Solution +.# Solution +.#
 
... ... Problem (Improving a role-playing game) +.#roleplaying
3152 3152 Your friend is not so sure why, but nothing else works. Your friend is not so sure why, but nothing else works.
3153 3153 Also it seems that a character can complete only one quest, but your friend is not so sure about that. Also it seems that a character can complete only one quest, but your friend is not so sure about that.
3154 3154 - It would be nice to be able to store features that are tied to the class, and not to the character, like the bonus they provide and the associated element (e.g., all bards use fire, all assassins use wind, etc.). - It would be nice to be able to store features that are tied to the class, and not to the character, like the bonus they provide and the associated element (e.g., all bards use fire, all assassins use wind, etc.).
3155 But you friend simply can't figure out how to do that.
3155 But you friend simply cannot figure out how to do that.
3156 3156
3157 3157 Can you provide a *relational model* (no need to write the `SQL` code, but remember to indicate the primary and foreign keys) that would solve all of your friend's troubles? Can you provide a *relational model* (no need to write the `SQL` code, but remember to indicate the primary and foreign keys) that would solve all of your friend's troubles?
3158 3158
 
... ... Solution to [%D %n (%T)](#problem:repetition)
3418 3418 @problem:repetition -- Solution to Q. -.# @problem:repetition -- Solution to Q. -.#
3419 3419 ~ ~
3420 3420
3421 We can't introduce the same value twice:
3421 We cannot introduce the same value twice:
3422 3422
3423 3423 ~~~{.sqlmysql} ~~~{.sqlmysql}
3424 3424 INSERT INTO EXAMPLE VALUES('Train', 4); INSERT INTO EXAMPLE VALUES('Train', 4);
 
... ... Goals:
4069 4069 : Loosing information inadvertently : Loosing information inadvertently
4070 4070
4071 4071 #. Modification Anomalies #. Modification Anomalies
4072 : Updated have to be consistent.
4072 : Updates have to be consistent.
4073 4073
4074 4074 (Bad!) Example: (Bad!) Example:
4075 4075
 
... ... Transform into "Emergency Contact in University" relation (bonus: allow multiple
4098 4098
4099 4099 #### Identical Attributes in Different Tables Should Be (Primary, Forgein) Key Pairs #### Identical Attributes in Different Tables Should Be (Primary, Forgein) Key Pairs
4100 4100
4101 Example with advisorOffice and Office: if we try to write a join to obtain the phone number of a student's advisor, we will obtain all the phone. (Not clear example, find a better one).
4101 Example with advisorOffice and Office: if we try to write a join to obtain the phone number of a student's advisor, we will obtain all the phone.
4102 <!-- (Not clear example, find a better one). -->
4102 4103
4103 4104 ### Example ### Example
4104 4105
 
... ... Think about their dependencies, and list them:
4154 4155 - Maybe `TEACHER.Office` → `TEACHER.Name` does not hold, because teachers share office? - Maybe `TEACHER.Office` → `TEACHER.Name` does not hold, because teachers share office?
4155 4156 - Maybe `TEACHER.Name` → `MARKER.Brand` and `MARKER.Color` hold? - Maybe `TEACHER.Name` → `MARKER.Brand` and `MARKER.Color` hold?
4156 4157
4157 A particular state can't enforce a FD, but it can negate one.
4158 A particular state cannot enforce a FD, but it can negate one.
4158 4159
4159 4160 Example: Example:
4160 4161
 
... ... We now have a formal definition.
4204 4205 In one particular relation $R(A_1, …, A_n)$, In one particular relation $R(A_1, …, A_n)$,
4205 4206
4206 4207 - If $\{A_1, …, A_n\} → Y$ for all attribute $Y$, then $\{A_1, …, A_n\}$ is a superkey. - If $\{A_1, …, A_n\} → Y$ for all attribute $Y$, then $\{A_1, …, A_n\}$ is a superkey.
4207 - If $\{A_1, …, A_n\} \ A_i$ is not a superkey anymore for all $A_i$, then $\{A_1, …, A_n\}$ is a key.
4208 - We will often discard candidate key and focus on one primary key. <!-- try to list all the candidates key, keep all the options open. -->
4208 - If $\{A_1, …, A_n\} \setminus A_i$ is not a superkey anymore for all $A_i$, then $\{A_1, …, A_n\}$ is a key.
4209 - We will often discard candidate keys and focus on one primary key. <!-- try to list all the candidates key, keep all the options open. -->
4209 4210 - If $A_i$ is a member of some candidate key of $R$, it is a **prime attribute** of $R$. - If $A_i$ is a member of some candidate key of $R$, it is a **prime attribute** of $R$.
4210 4211 It is a **non-prime attribute** otherwise. It is a **non-prime attribute** otherwise.
4211 4212
4212 4213 Given a FD $\{A_1, …, A_n\} → Y$, Given a FD $\{A_1, …, A_n\} → Y$,
4213 4214
4214 - It is a **full functional dependency** if for all $A_i$, \{A_1, …, A_n\} \ A_i → Y$, does not hold.
4215 - It is a **full functional dependency** if for all $A_i$, \{A_1, …, A_n\} \setminus A_i → Y$, does not hold.
4215 4216 - It is a **partial dependency** otherwise. - It is a **partial dependency** otherwise.
4216 4217
4217 4218 A FD : $X → Y$ is a **transivive dependency** if there exist a set of attribute $B$ s.t. A FD : $X → Y$ is a **transivive dependency** if there exist a set of attribute $B$ s.t.
 
... ... For each attribute $A$ of the relation whose primary key is $A_1, …, A_n$:
4263 4264 - No → Is it partially dependent on the primary key ? - No → Is it partially dependent on the primary key ?
4264 4265 - No, it is fully dependent on the primary key → Done - No, it is fully dependent on the primary key → Done
4265 4266 - Yes, it depends only of $\{A'_1, …, A'_k\}$ → Do the following: - Yes, it depends only of $\{A'_1, …, A'_k\}$ → Do the following:
4266 - Create a new relation with $A$ and $\{A'_1, …, A'_k\}$, make $\{A'_1, …, A'_k\}$ the primary key,
4267 - Remove $A$ from the original relation
4267 - Create a new relation with $A$ and $\{A'_1, …, A'_k\}$, make $\{A'_1, …, A'_k\}$ the primary key, and "import" all the functional dependencies,
4268 - Remove $A$ from the original relation, and all the functional dependencies that implied it,
4268 4269 - 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.
4269 4270
4270 4271 ![](fig/fd/Course) ![](fig/fd/Course)
 
... ... whereas a more subtle algorithm would give
4287 4288
4288 4289 ![](fig/fd/Example2NF3) ![](fig/fd/Example2NF3)
4289 4290
4290 Note that both are in Second Normal Form, though.
4291 Note that in both cases, all the relations are in Second Normal Form, though.
4291 4292
4292 4293 Note also that if our primary key is a singleton, then there is nothing to do, we are in 2NF as soon as we are in 1NF. Note also that if our primary key is a singleton, then there is nothing to do, we are in 2NF as soon as we are in 1NF.
4293
4294
4294 4295 #### Third normal form #### Third normal form
4295 4296
4296 4297 ##### Definition ##### Definition
 
... ... For each attribute $A$ of the relation whose primary key is $A_1, …, A_n$:
4306 4307 - No → Is it transitively dependent on the primary key ? - No → Is it transitively dependent on the primary key ?
4307 4308 - No, there is no $\{A'_1, …, A'_k\}$ such that $\{A_1, …, A_n\} → \{A'_1, …, A'_k\} → A$ and $\{A'_1, …, A'_k\} ⊈ \{A_1, …, A_n\}$ and $A ∉ \{A'_1, …, A'_k\}$ → Done - No, there is no $\{A'_1, …, A'_k\}$ such that $\{A_1, …, A_n\} → \{A'_1, …, A'_k\} → A$ and $\{A'_1, …, A'_k\} ⊈ \{A_1, …, A_n\}$ and $A ∉ \{A'_1, …, A'_k\}$ → Done
4308 4309 - Yes, there is such a $\{A'_1, …, A'_m\}$ → Do the following: - Yes, there is such a $\{A'_1, …, A'_m\}$ → Do the following:
4309 - Create a new relation with $A$ and $\{A'_1, …, A'_k\}$, make $\{A'_1, …, A'_k\}$ the primary key,
4310 - Remove $A$ from the original relation
4310 - Create a new relation with $A$ and $\{A'_1, …, A'_k\}$, make $\{A'_1, …, A'_k\}$ the primary key, and import all the functional dependencies,
4311 - Remove $A$ from the original relation, as well as all the functional dependencies involving it,
4311 4312 - 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.
4312 4313
4313
4314
4315 **ADD EXAMPLES**
4316
4317
4318 4314 #### Notes and examples #### Notes and examples
4319 4315
4320 CCL: every FD X → Y s.t. X is a proper subset of the primary key, or a non-prime attribute, is problematic.
4316 CCL: every FD $X → Y$ s.t. $X$ is a proper subset of the primary key, or a non-prime attribute, is problematic.
4317 2NF is a guarantee that every entity has its own relation, 3NF is a way to avoid data inconsistency.
4321 4318
4322 4319 --- ---
4323 4320
 
... ... Exercise +.#
4573 4570 ~ ~
4574 4571 Consider the following relational database schema: Consider the following relational database schema:
4575 4572
4576 STUDENT(L͟o͟g͟i͟n͟, Name, $…$, Major, Major\_Head)
4573 STUDENT(L͟o͟g͟i͟n͟, Name, $…$, Major, Major\_Head)
4577 4574 DEPARTMENT(C͟o͟d͟e͟, Name, Major\_Head) DEPARTMENT(C͟o͟d͟e͟, Name, Major\_Head)
4578 4575
4579 4576 Assuming that "Major" is a foreign key referencing "DEPARTMENT.Code", what is the problem with that schema? How could you address it? Assuming that "Major" is a foreign key referencing "DEPARTMENT.Code", what is the problem with that schema? How could you address it?
 
... ... Exercise +.#
4582 4579 ~ ~
4583 4580 Consider the relation $R(A , B, C, D, E, F)$ and the following functional dependencies: Consider the relation $R(A , B, C, D, E, F)$ and the following functional dependencies:
4584 4581
4585 #. $F \to \{D, C\}, D \to \{B, E\}, \{B, E\} \to A$
4586 #. $\{A, B\} \to \{C, D\}, \{B, E\} \to F$
4587 #. $A \to \{C, D\}, E \to F, D \to B$
4582 #. $F →\{D, C\}, D →\{B, E\}, \{B, E\} →A$
4583 #. $\{A, B\} →\{C, D\}, \{B, E\} →F$
4584 #. $A →\{C, D\}, E →F, D →B$
4588 4585
4589 4586 For each set of functional dependency, give a key for $R$. We want a key, so it has to be minimal. For each set of functional dependency, give a key for $R$. We want a key, so it has to be minimal.
4590 4587
4591 4588 Exercise +.# Exercise +.#
4592 4589 ~ ~
4593 4590 Consider the relation $R(A, B, C, D, E, F)$ and the following functional dependencies: Consider the relation $R(A, B, C, D, E, F)$ and the following functional dependencies:
4594 \[ A \to \{D, E\}, D \to \{B, F\}, \{B, E\} \to A, \{A,C\} \to \{B, D, F\}, A \to F\]
4591
4592 $A →\{D, E\}, D →\{B, F\}, \{B, E\} →A, \{A,C\} →\{B, D, F\}, A →F$
4593
4595 4594 Answer the following: Answer the following:
4596 4595
4597 4596 #. How many candidate keys is there? List them. #. How many candidate keys is there? List them.
 
... ... Exercise +.#
4601 4600 ~ ~
4602 4601 Consider the relation $R(A, B, C, D)$ and answer the following: Consider the relation $R(A, B, C, D)$ and answer the following:
4603 4602
4604 #. If $\{A, B\}$ is the only key, is $\{A, B\} \to \{C,D\}, \{B, C\} \to D$ a 2NF? List the nonprime attributes and justify.
4605 #. If $\{A, B, C\}$ is the only key, is $A \to \{B, D\}, \{A, B, C\} \to D$ a 2NF? List the nonprime attributes and justify.
4603 #. If $\{A, B\}$ is the only key, is $\{A, B\} →\{C,D\}, \{B, C\} →D$ a 2NF? List the nonprime attributes and justify.
4604 #. If $\{A, B, C\}$ is the only key, is $A →\{B, D\}, \{A, B, C\} →D$ a 2NF? List the nonprime attributes and justify.
4606 4605
4607 4606 Exercise +.# Exercise +.#
4608 4607 ~ ~
4609 Consider the relation $R(A, B, C, D, E, F)$ with candidate keys $\{A, B\}$ and $C$. Answer the following:
4608 Consider the relation $R(A, B, C, D, E, F)$ with candidate keys $\{A, B\}$ and $C$.
4609 Remember that, in all generality, to be a prime attribute, you just need to be part of _a possible_ candidate key.
4610 Answer the following:
4610 4611
4611 4612 #. What are the prime attributes in $R$? #. What are the prime attributes in $R$?
4612 #. Is $\{C,D\} \to E$ a fully functional dependency?
4613 #. Is $\{C,D\} →E$ a fully functional dependency?
4613 4614 #. Write a set of functional dependencies containing at least one transitive depency, and justify your answer. #. Write a set of functional dependencies containing at least one transitive depency, and justify your answer.
4614 4615
4615 4616 Exercise +.# Exercise +.#
4616 4617 ~ ~
4617 4618 Consider the relation $R(A , B, C, D, E)$ and the following functional dependencies: Consider the relation $R(A , B, C, D, E)$ and the following functional dependencies:
4618 4619
4619 #. $C \to D, \{C, B\} \to A, A \to \{B, C, D\}, B \to E$
4620 #. $\ A \to \{C, D\}, C \to B, D \to E, \{E, C\} \to A$
4621 #. $\{A, B\} \to D, D \to \{B, C\}, E \to C$
4620 #. $C →D, \{C, B\} →A, A →\{B, C, D\}, B →E$
4621 #. $\ A →\{C, D\}, C →B, D →E, \{E, C\} →A$
4622 #. $\{A, B\} →D, D →\{B, C\}, E →C$
4622 4623
4623 4624 For each one, give one candidate key for $R$. For each one, give one candidate key for $R$.
4624 4625
 
... ... Exercise +.#
4626 4627 ~ ~
4627 4628 Consider the relation $R(A, B, C, D, E)$ and answer the following: Consider the relation $R(A, B, C, D, E)$ and answer the following:
4628 4629
4629 #. If $\{A, B\}$ is the primary key, is $B \to E, C \to D$ a 2NF?% List the nonprime attributes and justify.
4630 #. If $\{A\}$ is the primary key, is $B \to C, B \to D$ a 2NF?% List the nonprime attributes and justify.
4630 #. If $\{A, B\}$ is the primary key, is $B →E, C →D$ a 2NF? List the nonprime attributes and justify.
4631 #. If $\{A\}$ is the primary key, is $B →C, B →D$ a 2NF? List the nonprime attributes and justify.
4631 4632
4632 4633 Exercise +.# Exercise +.#
4633 4634
4634 : Consider the relation $R(A, B, C, D, E, F)$, and let $\{B, D\}$ be the primary key, and have additionnaly the functional dependencies $\{A, D\} \to E, C \to F$.
4635 : Consider the relation $R(A, B, C, D, E, F)$, and let $\{B, D\}$ be the primary key, and have additionnaly the functional dependencies $\{A, D\} →E, C →F$.
4635 4636 This relation is not in 3NF, can you tell why? This relation is not in 3NF, can you tell why?
4636 4637
4637 4638 Exercise +.# Exercise +.#
4638 4639 ~ ~
4639 4640 Consider the relation $R(A, B, C, D)$ and answer the following: Consider the relation $R(A, B, C, D)$ and answer the following:
4640 4641
4641 #. If $A$ is the only key, is $A \to \{B,C,D\}, \{A, B\} \to C, \{B, C\} \to D$ a 3NF? List the nonprime attributes and justify.
4642 #. If $B$ is the only key, is $B \to \{A, C, D\}, A \to \{C, D\}, \{A, C\} \to D$ a 3NF? List the nonprime attributes and justify.
4642 #. If $A$ is the only key, is $A →\{B,C,D\}, \{A, B\} →C, \{B, C\} →D$ a 3NF? List the nonprime attributes and justify.
4643 #. If $B$ is the only key, is $B →\{A, C, D\}, A →\{C, D\}, \{A, C\} →D$ a 3NF? List the nonprime attributes and justify.
4643 4644
4644 4645 Exercise +.# Exercise +.#
4645 4646 ~ ~
4646 Consider the relation $R(A, B, C, D, E)$ and the functional dependencies $ \{A, B\} \to C, B \to D, C \to E$. Answer the following:
4647 Consider the relation $R(A, B, C, D, E)$ and the functional dependencies $\{A, B\} →C, B →D, C →E$. Answer the following:
4647 4648
4648 4649 #. $A$ by itself is not a primary key, but what is the only key that contains $A$? #. $A$ by itself is not a primary key, but what is the only key that contains $A$?
4649 4650 #. List the non-prime attributes. #. List the non-prime attributes.
 
... ... Solution +.#
4823 4824
4824 4825 Solution +.# Solution +.#
4825 4826
4826 : Because they waste space, and because they are ambiguous (N/A, or unknown, or not communicated?). No, it is necessary sometimes.
4827 : Because they waste space, they are ambiguous (N/A, or unknown, or not communicated?), and they make querries harder. No, it is necessary sometimes.
4827 4828
4828 4829 Solution +.# Solution +.#
4829 4830
4830 : Because it will be `NULL` most of the time. In a separate table.
4831 : Because it will be `NULL` most of the time. In a separate relation, e.g. a "BIKE" relation, with two attributes, "Owner" and "Brand", "Owner" being a foreign key referencing the SSN attribute of PROF.
4831 4832
4832 4833 Solution +.# Solution +.#
4833 4834
4834 : Because it will be `NULL` most of the time, and because students could have more than one sibling on campus. In a separate table.
4835 : Because it will be `NULL` most of the time, and because students could have more than one sibling on campus. In a separate relation, e.g. in a "EMERGENCY_CONTACT" relation, with two attributes, "Student" (refercing the SSN attribute of STUDENT), and "Contact". If the emergency contacts are not related to the student, or if we want to preserve the fact that one student is a sibling to another, we can create another relation to store that information.
4835 4836
4836 4837 Solution +.# Solution +.#
4837 4838
 
... ... Solution +.#
4847 4848 Solution +.# Solution +.#
4848 4849 ~ ~
4849 4850
4850 #. $\{A, C\}$,
4851 #. $A \to F$ by $A \to D, D\to F$.
4851 #. Only one: $\{A, C\}$,
4852 #. $A →F$ by $A →D, D→F$.
4852 4853
4853 4854 Solution +.# Solution +.#
4854 4855 ~ ~
 
... ... Solution +.#
4859 4860 Solution +.# Solution +.#
4860 4861 ~ ~
4861 4862
4862 #. $A,B,C$
4863 #. $A$, $B$ and $C$.
4863 4864 #. No, because we can remove $D$, #. No, because we can remove $D$,
4864 #. $A \to D$, $D \to E$ and $A \to E$
4865 #. $A →D$, $D →E$ and $A →E$
4865 4866
4866 4867 Solution +.# Solution +.#
4867 4868 ~ ~
 
... ... Solution +.#
4878 4879
4879 4880 Solution +.# Solution +.#
4880 4881
4881 : $\{B, D\} \to C \to F$ breaks the 3NF.
4882 : $\{B, D\} →C →F$ breaks the 3NF.
4882 4883
4883 4884 Solution +.# Solution +.#
4884 4885 ~ ~
4885 4886
4886 #. No. $B$, $C$ and $D$ are non prime, $A \to \{B,C\} \to D$ breaks the 3NF.
4887 #. No. $A$, $B$ and $D$ are non prime, $B \to \{A,C\} \to D$ breaks the 3NF.
4887 #. No. $B$, $C$ and $D$ are non prime, $A →\{B,C\} →D$ breaks the 3NF.
4888 #. No. $A$, $B$ and $D$ are non prime, $B →\{A,C\} →D$ breaks the 3NF.
4888 4889
4889 4890 Solution +.# Solution +.#
4890 4891 ~ ~
 
... ... Solution +.#
4896 4897
4897 4898 Solution +.# Solution +.#
4898 4899
4899 : Behaviour and structure
4900 : The two different categories of U.M.L. diagram are behaviour and structure.
4900 4901
4901 4902 Solution +.# Solution +.#
4902 4903
 
... ... For the concept of integration.
4917 4918 Solution +.# Solution +.#
4918 4919 ~ ~
4919 4920
4920 `Flight` has $5$ attributes, `Plane` has $4$. The `Plane` class could have the operations `getLastFlightNumber() : Integer` and `stMaximumSpeed(MPH) : void`.
4921 `Flight` has $5$ attributes, `Plane` has $4$. The `Plane` class could have the operations `getLastFlightNumber() : Integer` and `setMaximumSpeed(MPH) : void`.
4921 4922
4922 4923 For the multiplicities: A flight could not have a plane assigned, and a plane could not be assigned to a flight. For the multiplicities: A flight could not have a plane assigned, and a plane could not be assigned to a flight.
4923 4924 A plane can be assigned to multiple (or no) flights, but a flight must have at most one plane (and could have none). A plane can be assigned to multiple (or no) flights, but a flight must have at most one plane (and could have none).
 
... ... Solution +.#
4933 4934 ~ ![](fig/uml/Generalization) ~ ![](fig/uml/Generalization)
4934 4935 Because it avoids redundancy. Because it avoids redundancy.
4935 4936
4937
4938 Solution +.#
4939 ~ ![](fig/uml/Flight_2)
4940
4941
4936 4942 ## Problems {-} ## Problems {-}
4937 4943
4938 4944 Problem (Design for your professor) +.#designforprof Problem (Design for your professor) +.#designforprof
 
... ... Salesman\_no | →| Commission
5121 5127
5122 5128 and let \{Car\_no, Salesman\_no\} be the primary key of this relation. and let \{Car\_no, Salesman\_no\} be the primary key of this relation.
5123 5129
5124 Based on the given primary key, is this relation in 1NF, 2NF, or 3NF? Why or why not? Normalize it completely.
5130 Based on the given primary key, is this relation in 1NF, 2NF, or 3NF? Why or why not? Normalize it to its third normal form.
5125 5131
5126 5132 --- ---
5127 5133
 
... ... Problem (Normalizing the FLIGHT relation) +.#NormalizeFlight
5130 5136
5131 5137 Consider the following relation: Consider the following relation:
5132 5138
5133 FLIGHT(From, \qquad To, \qquad Airline, \qquad Flight\#, \qquad DateHour, \qquad HeadQuarter, \qquad Pilot, \qquad TZDifference)
5139 FLIGHT(From, To, Airline, Flight\#, DateHour, HeadQuarter, Pilot, TZDifference)
5134 5140
5135 5141 A tuple in the FLIGHT relation contains information about an airplane flight: the airports of departure and arrival, the airline carrier, the number of the flight, its time of departure, the headquarter of the company chartering the flight, the name of the pilot(s), and the time zone difference between the departure and afrrival airports. A tuple in the FLIGHT relation contains information about an airplane flight: the airports of departure and arrival, the airline carrier, the number of the flight, its time of departure, the headquarter of the company chartering the flight, the name of the pilot(s), and the time zone difference between the departure and afrrival airports.
5136 5142
 
... ... Problem (From business statement to dependencies) +.#bike
5156 5162
5157 5163 - Write each of the following dependencies as a functional dependency (the first one is given as an example): - Write each of the following dependencies as a functional dependency (the first one is given as an example):
5158 5164
5159 #. A retailer can't have two bikes of the same model from different batches.
5165 #. A retailer cannot have two bikes of the same model from different batches.
5160 5166 *solution:* \{Retailer, Model\} → Batch *solution:* \{Retailer, Model\} → Batch
5161 5167 #. The manufacturer and serial number uniquely identifies the bike and where it is sold. #. The manufacturer and serial number uniquely identifies the bike and where it is sold.
5162 #. A model number is registered by a manufacturer and therefore can't be used by another manufacturer.
5168 #. A model number is registered by a manufacturer and therefore cannot be used by another manufacturer.
5163 5169 #. All bikes in a particular batch are of the same model. #. All bikes in a particular batch are of the same model.
5164 5170 #. All bikes of a certain model have the same wheel size. #. All bikes of a certain model have the same wheel size.
5165 5171
 
... ... Problem (From E.R. to relational schema and UML class diagram -- CAR\_INFO) +.#c
5280 5286
5281 5287 Note that a car can have at most one driver, $N$ passengers, $N$ insurances, and that car insurances exist only if they are "tied up" to a car (i.e., they are weak entities, and their identifying relationship is called "Insured"). Note that a car can have at most one driver, $N$ passengers, $N$ insurances, and that car insurances exist only if they are "tied up" to a car (i.e., they are weak entities, and their identifying relationship is called "Insured").
5282 5288
5283 #. Find the key attribute for "Car", and the partial key for "Car Insurance". If you can't think of any, add a dummy attribute and make it be the key.
5289 #. Find the key attribute for "Car", and the partial key for "Car Insurance". If you cannot think of any, add a dummy attribute and make it be the key.
5284 5290 #. Convert that E.R. diagram to a relational database schema. #. Convert that E.R. diagram to a relational database schema.
5285 5291 #. Convert the E.R. diagram to a U.M.L. class diagram. Comparing Figure 7.16 with Figure 7.2 from your textbook should guide you. #. Convert the E.R. diagram to a U.M.L. class diagram. Comparing Figure 7.16 with Figure 7.2 from your textbook should guide you.
5286 5292
 
... ... Problem (From business statements to dependencies -- KEYBOARD) +.#BusinessToDepe
5312 5318 #. Write each of the following business statement as a functional dependency: #. Write each of the following business statement as a functional dependency:
5313 5319
5314 5320 #. A model has a fixed layout. #. A model has a fixed layout.
5315 #. A retail store can't have two different models produced by the same manufacturer.
5321 #. A retail store cannot have two different models produced by the same manufacturer.
5316 5322
5317 5323 #. Based on those statements, what could be a key for this relation? #. Based on those statements, what could be a key for this relation?
5318 5324 #. 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.
 
... ... Solution to [%D %n (%T)](#problem:carsale)
5383 5389
5384 5390 The CAR\_SALE relation is in 1st normal form, since it has a primary key, and by assuming that all the attributes are atomic. The CAR\_SALE relation is in 1st normal form, since it has a primary key, and by assuming that all the attributes are atomic.
5385 5391 This relation is not is 2nd Normal Form: since Date\_sold → Discount\_amount and Salesman\_no → Commission, then some attributes (namely Discount\_amount and Commission) are not fully functional dependent on the primary key. This relation is not is 2nd Normal Form: since Date\_sold → Discount\_amount and Salesman\_no → Commission, then some attributes (namely Discount\_amount and Commission) are not fully functional dependent on the primary key.
5386 Hence, this relation can't be in 3rd normal form either.
5392 Hence, this relation cannot be in 3rd normal form either.
5387 5393
5388 5394 To normalize, To normalize,
5389 5395
5390 5396 2NF: 2NF:
5391 Car\_Sale1(Car\_no, Date\_sold, Discount\_amt)
5392 Car\_Sale2(Car\_no, Salesman\_no)
5393 Car\_Sale3(Salesman\_no,Commission)
5394
5395 3NF:
5396 Car\_Sale1-1(Car\_no, Date\_sold)
5397 Car\_Sale1-2(Date\_sold, Discount\_amt)
5398 Car\_Sale2(Car\_no, Salesman\_no)
5399 Car\_Sale3(Salesman\_no,Commission)
5397
5398 Relations | Functional Dependencies
5399 ----- | -----
5400 Car\_Sale1(Car\_no, Date\_sold, Discount\_amt) | Car\_no → \{Date\_Sold, Discount\_amt\} and Date\_Sold → Discount\_amt
5401 Car\_Sale2(Car\_no, Salesman\_no) | Car\_no → Salesman\_no
5402 Car\_Sale3(Salesman\_no, Commission) | Salesman\_no → Commission
5403
5400 5404
5401 **bogue: indicate primary key.**
5405 3NF:
5406
5407 Relations | Functional Dependencies
5408 ----- | -----
5409 Car\_Sale1-1(Car\_no, Date\_sold) | Car\_no → Date\_Sold
5410 Car\_Sale1-2(Date\_sold, Discount\_amt) | Date\_Sold → Discount\_amt
5411 Car\_Sale2(Car\_no, Salesman\_no) | Car\_no → Salesman\_no
5412 Car\_Sale3(Salesman\_no,Commission) | Salesman\_no → Commission
5402 5413
5403 5414 --- ---
5404 5415
 
... ... Solution to [%D %n (%T)](#problem:bike)
5411 5422 #. Batch → Model #. Batch → Model
5412 5423 #. \{Model, Manufacturer\} → Wheel\_size #. \{Model, Manufacturer\} → Wheel\_size
5413 5424 - \{Manufacturer, Serial\_no \} - \{Manufacturer, Serial\_no \}
5414 - If every attribute is atomic, it is in second nf. \{ Manufacturer, Serial\_no \} → Batch →Model breaks the 3NF.
5425 - If every attribute is atomic, it is in second normal form. \{ Manufacturer, Serial\_no \} → Batch → Model breaks the 3NF.
5415 5426
5416 5427 --- ---
5417 5428
5418 5429 Solution to [%D %n (%T)](#problem:consultation) Solution to [%D %n (%T)](#problem:consultation)
5419 5430 ~ ~
5420 5431
5421 Because there are no partial dependencies, the given relation is in 2NF already. This however is not 3NF because the Charge is a nonkey attribute that is determined by another nonkey attribute, Treatment. We must decompose further:
5422
5423 R (Doctor\_no, Patient\_no, Date, Diagnosis, Treatment)
5432 #. The treatment for a particular disease can vary with the patient (for instance, his age can be a crucial parameter).
5433 #. $\{Doctor\_no, Patient\_no, Date\}$ is a primary key for this relation.
5434 #. Because there are no partial dependencies, the given relation is in 2NF already. This however is not 3NF because the Charge is a nonkey attribute that is determined by another nonkey attribute, Treatment. We must decompose further:
5424 5435
5425 R1 (Treatment, Charge)
5436 CONSULTATION (Doctor\_no, Patient\_no, Date, Diagnosis, Treatment)
5437 PRICE_LISTING (Treatment, Charge)
5426 5438
5427 We could further infer that the treatment for a given diagnosis is functionally dependant, but we should be sure to allow the doctor to have some flexibility when prescribing cures.
5439 <!-- We could further infer that the treatment for a given diagnosis is functionally dependant, but we should be sure to allow the doctor to have some flexibility when prescribing cures. -->
5428 5440
5429 5441 --- ---
5430 5442
 
... ... The records selected are:
5675 5687 `BOOLEAN` | `boolean` `BOOLEAN` | `boolean`
5676 5688 `BIT(1)` | `byte` `BIT(1)` | `byte`
5677 5689
5678 We can't always have that correspondance: what would correspond to a reference variable? To a private attribute?
5690 We cannot always have that correspondance: what would correspond to a reference variable? To a private attribute?
5679 5691 This series of problems is called "object-relational impedance mismatch", it can be overcomed, but at a cost. This series of problems is called "object-relational impedance mismatch", it can be overcomed, but at a cost.
5680 5692
5681 5693
 
... ... Solution to @problem:db_application
6001 6013 ### Control measures ### Control measures
6002 6014
6003 6015 - Access control (user account, passwords, restrictions) - Access control (user account, passwords, restrictions)
6004 - Inference control (can't access information about a particular "case")
6016 - Inference control (cannot access information about a particular "case")
6005 6017 - Flow control (prevent indirect access) - Flow control (prevent indirect access)
6006 6018 - Encryption (salting + encrypting, can be a legal obligation): password + salt -> hashed. - Encryption (salting + encrypting, can be a legal obligation): password + salt -> hashed.
6007 6019
 
... ... Exercise +.#denormalization
6474 6486
6475 6487 Exercise +.#mismatch Exercise +.#mismatch
6476 6488
6477 : What is the (object-relational) impedance mismatch? Is it an issue that can't be overcome?
6489 : What is the (object-relational) impedance mismatch? Is it an issue that cannot be overcome?
6478 6490
6479 6491 ## Solution to Exercises {-} ## Solution to Exercises {-}
6480 6492
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