List of commits:
Subject Hash Author Date (UTC)
Adding bib entry, adding quiz #3 8e815dfcb23757a336d0ec995900515b085faa23 aubert@math.cnrs.fr 2019-10-03 16:11:54
Fixing links to solutions. a3d24834b7dfd2f721bbee4ee3964e05635fce16 aubert@math.cnrs.fr 2019-09-25 18:58:20
Added the first exam of Fall 2019 694ee6905435d3ace98fac02a1d9a158ec0dc205 aubert@math.cnrs.fr 2019-09-24 19:00:32
Adding a link to the Known_Bugs for an example of TOC that follows the scrolling d48fae1dfe47f40ea7fe93c283d424741b694303 aubert@math.cnrs.fr 2019-09-19 19:30:11
Fixing css and bug descrition. 7af0904a2d3356988d3661aef8b4f8b61d84660a aubert@math.cnrs.fr 2019-09-17 17:04:38
Some notes about the bugs with css. a68fe8d8974ee19a585e9c9b77519a918d3795ee aubert@math.cnrs.fr 2019-09-17 16:58:10
Adding some bugs to the report. 50e2dc7eca8e2dcd20e8f9e06eba76e54bd52114 aubert@math.cnrs.fr 2019-09-17 16:20:58
Added quizz 2 a57781924233353363e5cc9b8d6b7d88a0a735b6 aubert@math.cnrs.fr 2019-09-17 12:45:36
Adding quiz #2, correcting a few typo in SQL chapter. 16e6aee0be154245b472c77fb2d6a486dd07ef38 aubert@math.cnrs.fr 2019-09-16 19:58:53
Quick changes in the first SQL part: check is actually taken into account! b62ed769ef0ebd96ea91e3053246e142b73d524c aubert@math.cnrs.fr 2019-09-09 16:26:17
Added quiz #1 of Fall 2019, plus minor corrections. a5498523b05cb246ce58b05a8951b833a0b0e699 aubert@math.cnrs.fr 2019-08-29 16:23:07
Adding a figure for a quizz, and a possible bug to the list. 6e83297ccb9678296993e605b2f35d0b13a97523 aubert@math.cnrs.fr 2019-08-27 16:20:35
Changed the monospace font, updated instructions to install mariaDB. 3dc6162733e0a373205012869c1ee068ef3e5c91 aubert@math.cnrs.fr 2019-08-16 18:56:37
Few patches to prepare for Fall 2019. 545561b3d47dfe9bff2436f8f2b7e32572cd808a aubert@math.cnrs.fr 2019-08-07 17:12:26
Editing the cycle of design picture 9bd1c3190a71202b88011b831161cf9d6a365237 aubert@math.cnrs.fr 2019-08-07 16:13:03
Test c742ba7590d59e2941f9fa197c9d009d5c642e76 au 2019-07-31 23:56:14
Minor fix in Known bugs and contrib. 19f3adfa1f88e6d12e94868f4eab0b5838d05eb6 aubert@math.cnrs.fr 2019-07-29 20:51:14
Commit 2ed1a8532cbdae46d3feb99cf52f23f2afa144ec aubert@math.cnrs.fr 2019-07-29 19:01:36
Adding the final to the notes. 0e8848a3e67ec49bab5b767e25d6099fd218e417 aubert@math.cnrs.fr 2019-05-20 14:44:54
Added the solution to one of the problem from Exam #2. 625545a335c5dc7b7303355088a3abba999fdf40 aubert@math.cnrs.fr 2019-05-06 16:59:50
Commit 8e815dfcb23757a336d0ec995900515b085faa23 - Adding bib entry, adding quiz #3
Author: aubert@math.cnrs.fr
Author date (UTC): 2019-10-03 16:11
Committer name: aubert@math.cnrs.fr
Committer date (UTC): 2019-10-03 16:11
Parent(s): a3d24834b7dfd2f721bbee4ee3964e05635fce16
Signing key:
Tree: 228c9c614c7b16b2a2c559133ba01e335d2b2646
File Lines added Lines deleted
notes/bib/entry.bib 11 0
notes/bib/test_entry.tex 8 0
notes/fig/er/Alt_Not1.tex 1 1
notes/fig/er/CompOS.tex 10 0
notes/fig/er/Membership.tex 11 0
notes/fig/er/Song.tex 22 0
notes/fig/rel_mod/COMPUTER_USER.tex 2 2
notes/fig/rel_mod/DESK.tex 1 1
notes/lectures_notes.md 72 23
File notes/bib/entry.bib added (mode: 100644) (index 0000000..05badf0)
1 @report{AubertCSCI3410-DatabaseSystems,
2 author={Aubert, Clément},
3 title={CSCI 3410 - Database Systems},
4 url={http://spots.augusta.edu/caubert/db/ln/},
5 urldate={2019-11-03},
6 year={2019},
7 institution={{School of Computer and Cyber Sciences, Augusta University}},
8 location={Augusta, Georgia, USA},
9 langid={en},
10 type={Lecture notes}
11 }
File notes/bib/test_entry.tex added (mode: 100644) (index 0000000..53a3b2a)
1 \documentclass{article}
2 \usepackage[backend=bibtex8]{biblatex}
3 \bibliography{entry}
4
5 \begin{document}
6 \nocite{*}
7 \printbibliography
8 \end{document}
File notes/fig/er/Alt_Not1.tex changed (mode: 100644) (index 4500951..5b640e2)
4 4 \begin{tikzpicture}[node distance=5em] \begin{tikzpicture}[node distance=5em]
5 5 \node [entity] (CAR) {CAR}; \node [entity] (CAR) {CAR};
6 6 \node [relationship] (CARPOOLING) [right=of CAR] {CARPOOLING} edge[total] node[above]{$\cN$} (CAR); \node [relationship] (CARPOOLING) [right=of CAR] {CARPOOLING} edge[total] node[above]{$\cN$} (CAR);
7 \node [entity] (PERSON) [right = of CARPOOLING] {PERSON} edge node[above]{$1$} (CARPOOLING);
7 \node [entity] (PERSON) [right = of CARPOOLING] {PERSON} edge node[above]{$\cM$} (CARPOOLING);
8 8 \end{tikzpicture} \end{tikzpicture}
9 9
10 10 \end{document} \end{document}
File notes/fig/er/CompOS.tex added (mode: 100644) (index 0000000..cb96fd5)
1 \documentclass[border=20pt]{standalone}
2 \input{template.def}
3
4 \begin{tikzpicture}[node distance=5em]
5 \node [entity] (os) {O.S.};
6 \node [relationship] (installed) [right=of os] {IS SUPPORTED BY} edge node[above]{$\cN$} (os);
7 \node [entity] (comp) [right = of installed] {COMPUTER} edge[total] node[above]{$\cM$} (installed);
8 \end{tikzpicture}
9
10 \end{document}
File notes/fig/er/Membership.tex added (mode: 100644) (index 0000000..52c2169)
1 \documentclass[border=20pt]{standalone}
2 \input{template.def}
3
4 \begin{tikzpicture}[node distance=5em]
5 \node [entity] (PERSON) {PERSON};
6 \node [relationship] (MEMBERSHIP) [right=of PERSON] {MEMBERSHIP} edge node[above]{$\cM$} (PERSON);
7 \node [entity] (CLUB) [right = of MEMBERSHIP] {CLUB} edge node[above]{$1$} (MEMBERSHIP);
8 \node[attribute] [above of=PERSON] {CLUB\_MEMBERSHIP\_LEVEL} edge (PERSON);
9 \end{tikzpicture}
10
11 \end{document}
File notes/fig/er/Song.tex added (mode: 100644) (index 0000000..def4a5b)
1 \documentclass[border=20pt]{standalone}
2 \input{template.def}
3
4 \begin{tikzpicture}[node distance=5em]
5 \node[entity] (ALBUM) {ALBUM};
6 \node[attribute] [left = .5cm of ALBUM] {\key{Name}} edge (ALBUM);
7 \node[attribute] (Date) [above of=ALBUM] {Release Date} edge (ALBUM);
8 \node[attribute] [above right of=Date] {Day} edge (Date);
9 \node[attribute] [above = 1.2cm of Date] {Month} edge (Date);
10 \node[attribute] [above left of=Date] {Year} edge (Date);
11
12 \node[ident relationship] (CONTAINS) [right = 1cm of ALBUM] {CONTAINS} edge node[above, pos=0.3] {$1$} (ALBUM);
13 \node[weak entity] (SONG) [right = 1cm of CONTAINS] {SONG} edge[total] node[above, pos=0.7] {$N$} (CONTAINS);
14 \node[attribute] [right = .5cm of SONG] {\pkey{Track Number}} edge (SONG);
15
16 \node[attribute] (Length) [above of =SONG] {Length} edge (SONG);
17 \node[attribute] [above left of =Length] {Hours} edge (Length);
18 \node[attribute] [above =1.3cm of Length] {Minutes} edge (Length);
19 \node[attribute] [above right of =Length] {Seconds} edge (Length);
20 \end{tikzpicture}
21
22 \end{document}
File notes/fig/rel_mod/COMPUTER_USER.tex changed (mode: 100644) (index be4d792..5c9b582)
9 9
10 10 \Frame(5, 0){2}[COMPUTER\_USER]{ \Frame(5, 0){2}[COMPUTER\_USER]{
11 11 Computer/PK, Computer/PK,
12 Name/A,
13 Email/A};
12 Name/PK,
13 Email/PK};
14 14
15 15 \draw[FK] % From COMPUTER_COLOR.Desk to COMPUTER.MAC \draw[FK] % From COMPUTER_COLOR.Desk to COMPUTER.MAC
16 16 (MAC1)++(0,0) -- ++(0,-.5) -- ++(-0,0) coordinate (inter) (MAC1)++(0,0) -- ++(0,-.5) -- ++(-0,0) coordinate (inter)
File notes/fig/rel_mod/DESK.tex changed (mode: 100644) (index 96caeb3..cf81cda)
11 11
12 12 \Frame(5, 0){2}[DESK\_COLOR]{ \Frame(5, 0){2}[DESK\_COLOR]{
13 13 Desk/PK, Desk/PK,
14 Color/A};
14 Color/PK};
15 15
16 16 \draw[FK] % From DESK_COLOR.Desk to DESK.Serial \draw[FK] % From DESK_COLOR.Desk to DESK.Serial
17 17 (Serial1)++(0,0) -- ++(0,-.5) -- ++(-0,0) coordinate (inter) (Serial1)++(0,0) -- ++(0,-.5) -- ++(-0,0) coordinate (inter)
File notes/lectures_notes.md changed (mode: 100644) (index 0cb155d..1a9c3c1)
... ... author: Clément Aubert
6 6 institute: Augusta University institute: Augusta University
7 7 papersize: letter papersize: letter
8 8 geometry: "vmargin=2cm" geometry: "vmargin=2cm"
9 bibliography: [ bib/bib.bib ]
9 bibliography: [ bib/bib.bib, bib/entry.bib ]
10 10 link-citations: true link-citations: true
11 11 lang: en lang: en
12 12 numbersections: true numbersections: true
 
... ... Any feedback is greatly appreciated.
55 55 Please refer to <http://spots.augusta.edu/caubert/db/ln/README.html#contributing> for how to contribute to those notes. Please refer to <http://spots.augusta.edu/caubert/db/ln/README.html#contributing> for how to contribute to those notes.
56 56
57 57 The syllabus is at <http://spots.augusta.edu/caubert/db/>, and the webpage for this notes is at <http://spots.augusta.edu/caubert/db/ln/>. The syllabus is at <http://spots.augusta.edu/caubert/db/>, and the webpage for this notes is at <http://spots.augusta.edu/caubert/db/ln/>.
58 Please, refer to those notes using this entry [@AubertCSCI3410-DatabaseSystems]:
59
60 ```{.bibtex include=bib/entry.bib}
61 ```
58 62
59 63 ## Planned Schedule {-} ## Planned Schedule {-}
60 64
 
... ... They are detailled and illustrated after the algorithm, which goes as follows:
4410 4414 4 | Binary $1:N$ Relationship Types | Foreign Key or Cross-Reference approach 4 | Binary $1:N$ Relationship Types | Foreign Key or Cross-Reference approach
4411 4415 5 | Binary $M:N$ Relationship Types | Cross-Reference approach 5 | Binary $M:N$ Relationship Types | Cross-Reference approach
4412 4416 6 | $n$-ary Relationship Types | Cross-Reference approach 6 | $n$-ary Relationship Types | Cross-Reference approach
4413 7 | Multivalued Attributes | Create a new relation, whose primary key is the foreign key to the relation corresponding to the entity.
4417 7 | Multivalued Attributes | Create a new relation, add as a foreign key the primary key of the relation corresponding to the original strong entity type. Make all the attributes be the primary key.
4418
4419
4420
4421 whose primary key is the foreign key to the relation corresponding to the entity.
4414 4422
4415 4423 #. 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.
4416 #. 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.
4424 #. Merged Relation Approach: If both participations are total, just merge them. Primary key = just pick one (or take both). If we were working on the implementation, we would add a `NOT NULL` constraint on the attribute that is not part of the primary key anymore.
4417 4425 #. 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. #. 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.
4418 4426
4419 Every time a relationships have attributes, they are mapped to the resultiong relation.
4427 Every time a relationships have attributes, they are mapped to the resulting relation.
4420 4428
4421 4429 Let us look in more details at some of those steps. Let us look in more details at some of those steps.
4422 4430 For strong entities, using steps 1 and 7, the following: For strong entities, using steps 1 and 7, the following:
 
... ... The arity constraints here can be rephrased as:
4518 4526
4519 4527 And note that there is no total participation constraint. And note that there is no total participation constraint.
4520 4528
4521 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.
4529 To reprent the RESERVES 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.
4522 4530 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. 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.
4523 4531 To improve this situation, we can either To improve this situation, we can either
4524 4532
 
... ... Exercise +.#
5012 5020
5013 5021 Exercise +.# Exercise +.#
5014 5022
5015 : Under what condition(s) can an attribute of a binary relationship type be migrated to become an attribute of one of the participating entity type?
5016
5017 Exercise +.#
5018
5019 : Suppose a "PRODUCES" relationship with an attribute "Amount" exists between a "PRODUCER" entity type and a "MOVIE" entity type, with ratio $1:M$.
5020 Migrate the "Amount" attribute to one of the entity and draw the resulting diagram.
5023 : Express the constraints represented in the following diagram in plain English.
5024 ![](fig/er/KeyOpensDoor)
5021 5025
5022 5026 Exercise +.# Exercise +.#
5023 5027
5024 5028 : Express the constraints represented in the following diagram in plain English. : Express the constraints represented in the following diagram in plain English.
5025 ![](fig/er/KeyOpensDoor)
5029 ![](fig/er/CompOS)
5026 5030
5027 5031 Exercise +.# Exercise +.#
5028 5032
 
... ... Exercise +.#
5054 5058 : Draw an ER diagram expressing the total participation of an entity type "BURGER" in a binary relation "CONTAINS" between "BURGER" and "INGREDIENT". : Draw an ER diagram expressing the total participation of an entity type "BURGER" in a binary relation "CONTAINS" between "BURGER" and "INGREDIENT".
5055 5059 What would be the ratio of such a relation? What would be the ratio of such a relation?
5056 5060
5061
5062 Exercise +.#
5063
5064 : Under what condition(s) can an attribute of a binary relationship type be migrated to become an attribute of one of the participating entity type?
5065
5066 Exercise +.#
5067
5068 : Suppose a "PRODUCES" relationship with an attribute "Amount" exists between a "PRODUCER" entity type and a "MOVIE" entity type, with ratio $1:M$.
5069 Migrate the "Amount" attribute to one of the entity type and draw the resulting diagram.
5070
5071 Exercise +.#
5072
5073 : Suppose a "MEMBERSHIP relationship with an attribute "Level" (e.g., "silver", "platinium", etc.) exists between a "PERSON" entity type and a "CLUB" entity type, with ratio $M:1$.
5074 Migrate the "Level" attribute to one of the entity type and draw the resulting diagram.
5075
5057 5076 Exercise +.# Exercise +.#
5058 5077
5059 5078 : What is the difference between an entity type and a weak entity type? : What is the difference between an entity type and a weak entity type?
 
... ... Exercise +.#
5066 5085
5067 5086 : Why do weak entity type have a total participation constraint? : Why do weak entity type have a total participation constraint?
5068 5087
5088 Exercise +.#
5089
5090 : Invent a weak entity type, its identifying (owner) entity type and the identifiying (or supporting) relationship.
5091 Both entities should have (partial) key, and each should have at least one composite attribute.
5092
5069 5093 Exercise +.# Exercise +.#
5070 5094 ~ ~
5071 5095 Convert the following ER diagram into a relational model: Convert the following ER diagram into a relational model:
 
... ... Solution +.#
5278 5302
5279 5303 : Cardinality ration and participation constraints. : Cardinality ration and participation constraints.
5280 5304
5281 Solution +.#
5282
5283 : When the cardinality is $1:N$, $1:1$ or $N:1$.
5284 5305
5285 5306 Solution +.# Solution +.#
5286 ~
5287
5288 We could have the following:
5289
5290 ![](fig/er/Produces)
5291 5307
5308 : A key opens only one door, and every key must open at least one door.
5309 A door can be opened by multiple key, and some doors may not be opened by keys (think of doors that cannot be locked).
5292 5310
5293 5311 Solution +.# Solution +.#
5294 5312
5295 : A key opens only one door, and every key must open at least one door.
5296 A door can be opened by multiple key, and some doors may not be opened by keys (think of doors that cannot be locked).
5313 : An operating system may be supported by many computers, but it is also possible that no computer supports it (think of an operating system in development, or developed for embeded devices).
5314 A computer must support at least one operating system, and can support multiple operating systems.
5297 5315
5298 5316 Solution +.# Solution +.#
5299 5317 ~ ~
 
... ... Solution +.#
5326 5344
5327 5345 Solution +.# Solution +.#
5328 5346
5347 : When the cardinality is $1:N$, $1:1$ or $N:1$, the attribute on the relationship can be migrated "to the $N$ side", or to either side, if there is none.
5348 Note that for $n$-ary relationships, at most all but one ratio needs to be $1$ for the attribute to be allowed to migrate (and, again, "to the $N$ side", or to any side, if there is none).
5349
5350
5351 Solution +.#
5352 ~
5353
5354 We could have the following:
5355
5356 ![](fig/er/Produces)
5357
5358 Solution +.#
5359 ~
5360
5361 We could have the following:
5362
5363 ![](fig/er/Membership)
5364
5365 Solution +.#
5366
5329 5367 : The weak entity type doesn't have a key attribute, it cannot be distinguised from the other weak entities based on a single attribute, for that we also need to know its relationship to some other entity type. : The weak entity type doesn't have a key attribute, it cannot be distinguised from the other weak entities based on a single attribute, for that we also need to know its relationship to some other entity type.
5330 5368
5331 5369 Solution +.# Solution +.#
 
... ... Solution +.#
5334 5372
5335 5373 Solution +.# Solution +.#
5336 5374
5337 : Otherwise, we couldn't identify entities in it without owner entity.
5375 : Otherwise, we could not identify entities in it without owner entity.
5376
5377 Solution +.#
5378
5379 ~
5380
5381 A possible solution is:
5382
5383 ![](fig/er/Song)
5384
5385 Note that the two composite attributes are "generic", in the sense that you can re-use those examples easily.
5386
5338 5387
5339 5388 Solution +.# Solution +.#
5340 5389
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