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)
Cleaning latex dependencies: removed colors, fonts, etc., added header and footer. b4c1232d6091e12bc2cdf038529921143a55b758 aubert@math.cnrs.fr 2018-05-22 05:06:04
Putting all latex material aside, changing class. e43fb54e6ecb0ec4669ed16feba940b47ee3e35c aubert@math.cnrs.fr 2018-05-21 15:14:48
Gathering references, fixing many small typos, adding references in bib. 4f5281a0770f07d2f48f36462ab25f0a3945f4e0 aubert@math.cnrs.fr 2018-05-21 04:54:59
Finished merging exercises into lecture notes! 36e1f79080a8ac56837632bcac2c119fc3efa24f aubert@math.cnrs.fr 2018-05-20 18:50:54
Almost done with the homeworks! f82824a2ca9769a0ecf8fc75d6bf1cae1ef3c7a4 aubert@math.cnrs.fr 2018-05-20 05:23:43
Travail sur intégration des exos dans les notes. c5a6676f85953c7bec9bb2de99bed3552ecf52af aubert@math.cnrs.fr 2018-05-20 05:04:30
Les exercises compilent :-) d4230fce5210d1d8905a42d11634e49e82217541 aubert@math.cnrs.fr 2018-05-19 19:09:56
Progrès sur exercises. 40dd86cdc624209a2282d4437921f46325c2cfa1 aubert@math.cnrs.fr 2018-05-19 18:34:07
Working on exercises. 42549c8d28249f1ecf85dd21f6d004ae63c533ad aubert@math.cnrs.fr 2018-05-19 05:43:04
Working on incorporating the exercises. f32148faeb8b11425fe9a57770db9bc85ae02c34 aubert@math.cnrs.fr 2018-05-19 04:51:37
working on sum for exo. 5fb55d2c31b06161ade3a7cae707485d8c02447a aubert@math.cnrs.fr 2018-05-18 21:12:56
Adding various small notes. 5eac6e0b19441fca9a3f70f239d5cbbc4d769976 aubert@math.cnrs.fr 2018-05-17 20:37:14
First pass over! ea1e4f6ddabd91287d10384dc8f28565a762526b aubert@math.cnrs.fr 2018-05-17 19:26:28
Working on notes on normal forms. 58bfcedc6bd6336592a5f93a43ffc0aaf64fa8f6 aubert@math.cnrs.fr 2018-05-16 16:40:12
Initial commit, draft of lecture notes. 200d2739bca881d60c7c9381b16f5a4d6384ff29 aubert@math.cnrs.fr 2018-05-16 15:35:36
Commit b4c1232d6091e12bc2cdf038529921143a55b758 - Cleaning latex dependencies: removed colors, fonts, etc., added header and footer.
Author: aubert@math.cnrs.fr
Author date (UTC): 2018-05-22 05:06
Committer name: aubert@math.cnrs.fr
Committer date (UTC): 2018-05-22 05:06
Parent(s): e43fb54e6ecb0ec4669ed16feba940b47ee3e35c
Signer:
Signing key:
Signing status: N
Tree: e3dc9d6a82e191b9476715c6ad8a988dd6a05b7f
File Lines added Lines deleted
notes/00_Doc_Notes.md 0 29
notes/00_Questions_Notes.md 0 38
notes/00_sum.md 60 62
notes/bib/bib.bib 0 0
File notes/00_Doc_Notes.md deleted (index 18836d1..0000000)
1 Issues:
2 =======
3
4 Having one bib. per section: https://github.com/jgm/pandoc/issues/771
5 Attention, ce n’est pas la même chose que
6 --reference-location=block --reference-links
7 cf. https://pandoc.org/MANUAL.html
8
9 Class:
10 scrartcl?
11 use --top-level-division=chapter?
12
13
14 TO DO
15 =======
16
17 - Make nice drawing
18
19 - Organize scans (FunDep, ER, UML, Rel, Design, Misc?).
20
21 - Add title to problem, and solve their naming / referencing issue.
22
23 - Use https://github.com/lierdakil/pandoc-crossref ?
24
25 - Add example environment?
26
27 - Check odt and html output
28
29 - Problem in line ou pas?
File notes/00_Questions_Notes.md deleted (index ea7ea81..0000000)
1 Add triggers and stored procedures?
2 Pick names from https://www.hillelwayne.com/post/important-women-in-cs/
3
4 Can you make union of different datatypes?
5
6 When you count, do you count null?
7
8 Documents given to students needs to be updated.
9 The one with advanced SQL, for instance.
10
11 cf notes for Lecture 14: weak entity with identifying relation of degree more than 1. Joint filling.
12 Unclear.
13
14 Can an identifying relationship being of mutiplicity more than 1?
15 I.e., a pet is in my DB only if it belongs to a friend, but a pet can belong to more than 1 friend.
16
17
18 Regexp:
19 \\enquote\{([^}]+)?\}
20 "\1"
21
22 \\mint\{([^}]*)\}\|([^|]*)\|
23
24 ```\1
25 \2
26 ```
27
28 \mintinline{mySQL}|
29
30 \\mintinline\{([^}]*)\}\|([^|]*)\|
31
32
33 \begin{minted}{mySQL}
34
35 \\texttt\{([^}]*)\}
36 `\1`
37
38 Add "Example of exam includes the following questions and problems: bla balb bla ".
File notes/00_sum.md changed (mode: 100644) (index 9c11bc0..d4587ce)
1 1 --- ---
2 2 documentclass: scrreprt documentclass: scrreprt
3 3 papersize: letter papersize: letter
4 bibliography: [ bib.bib ]
4 bibliography: [ bib/bib.bib ]
5 5 link-citations: true link-citations: true
6 6 title: CSCI 3410 - Database Systems title: CSCI 3410 - Database Systems
7 7 subtitle: Lecture Notes (Draft) subtitle: Lecture Notes (Draft)
 
... ... b. Construct (= storing the data)
74 74 c. Manipulate (= query, update, etc.) c. Manipulate (= query, update, etc.)
75 75 d. Share (=among users, softwares.) d. Share (=among users, softwares.)
76 76
77 ![A simplified database environment](book_screen/fig1.1.jpeg)
77 ![A simplified database environment](before/book_screen/fig1.1.jpeg)
78 78
79 79 ## Subtasks ## Subtasks
80 80
 
... ... d. ( + Software engineer, web developer, to help users).
85 85
86 86 ## Design ## Design
87 87
88 ![The cycle of design](paper_screen/cycle_of_design.jpeg)
88 ![The cycle of design](before/paper_screen/cycle_of_design.jpeg)
89 89
90 90 --- ---
91 91
 
... ... d. ( + Software engineer, web developer, to help users).
93 93
94 94 **STUDENT** **STUDENT**
95 95
96 | \rowcolor{gray!30} Name | Student_number | Class | Major |
96 | Name | Student_number | Class | Major |
97 97 | :---: | :---: | :---: | :---: | | :---: | :---: | :---: | :---: |
98 98 | Morgan | 18 | 2 | IT | | Morgan | 18 | 2 | IT |
99 99 | Bob | 17 | 1 | CS | | Bob | 17 | 1 | CS |
100 100
101 101 **COURSE** **COURSE**
102 102
103 | \rowcolor{gray!30} Course_name | Course_number | Credit_hours | Department |
103 | Course_name | Course_number | Credit_hours | Department |
104 104 | :---: | :---: | :---: | :---: | | :---: | :---: | :---: | :---: |
105 105 | Intro. to CS | 1301 | 4 | CS | | Intro. to CS | 1301 | 4 | CS |
106 106 | DB Systems | 3401 | 3 | CS | | DB Systems | 3401 | 3 | CS |
107 107
108 108 **SECTION** **SECTION**
109 109
110 | \rowcolor{gray!30} Section_identifier | Course_num | Semster | Year | Instructor |
110 | Section_identifier | Course_num | Semster | Year | Instructor |
111 111 | :---: | :---: | :---: | :---: | :---: | | :---: | :---: | :---: | :---: | :---: |
112 112 | 2910 | 1301 | Fall | 2019 | Kate | | 2910 | 1301 | Fall | 2019 | Kate |
113 113 | 9230 | 2103 | Spring | 2020 | Todd | | 9230 | 2103 | Spring | 2020 | Todd |
114 114
115 115 **GRADE_REPORT** **GRADE_REPORT**
116 116
117 | \rowcolor{gray!30} Student_number | Section_identifier | Grade |
117 | Student_number | Section_identifier | Grade |
118 118 | :---: | :---: | :---: | | :---: | :---: | :---: |
119 119 | 17 | 2910 | A | | 17 | 2910 | A |
120 120 | 18 | 2910 | B | | 18 | 2910 | B |
121 121
122 122 **PREREQUISITE** **PREREQUISITE**
123 123
124 | \rowcolor{gray!30} Course_number | Prerequisite_number |
124 | Course_number | Prerequisite_number |
125 125 | :---: | :---: | | :---: | :---: |
126 126 | 2910 | 1301 | | 2910 | 1301 |
127 127 | 1302 | 1301 | | 1302 | 1301 |
 
... ... Question -.#
245 245
246 246 **RELATIONS** **RELATIONS**
247 247
248 | \rowcolor{gray!30} Relation\_name | No\_of\_columns |
248 | Relation\_name | No\_of\_columns |
249 249 --- | --- --- | ---
250 250 `BUILDING` | $2$ `BUILDING` | $2$
251 251 `ROOM` | $3$ `ROOM` | $3$
 
... ... Question -.#
255 255 **COLUMNS** **COLUMNS**
256 256
257 257
258 | \rowcolor{gray!30} Column\_name | Data\_type | Belongs\_to\_relation |
258 | Column\_name | Data\_type | Belongs\_to\_relation |
259 259 | --- | --- | --- | --- | --- | ---
260 260 Building\_Name | Character($30$) | `Building` Building\_Name | Character($30$) | `Building`
261 261 GPS | Double ($1$) | `Building` GPS | Double ($1$) | `Building`
 
... ... Mathematical relations, set-theory, first-order predicate logic!
299 299
300 300 ## Concepts ## Concepts
301 301
302 ![Terminology](paper_screen/termimology.jpeg)
302 ![Terminology](before/paper_screen/termimology.jpeg)
303 303
304 304 Relational data model: Relational data model:
305 305
 
... ... Tuples can't be equal, so a subset of values must distinguish them, we study the
374 374
375 375 Note: here we "retro-fit" those definitions, in DB design, they come first! Note: here we "retro-fit" those definitions, in DB design, they come first!
376 376
377 | \rowcolor{gray!30} A | B | C | D |
377 | A | B | C | D |
378 378 | :---: | :---: | :---: | :---: | | :---: | :---: | :---: | :---: |
379 379 | Yellow | Rectangle | 10 | (5, 3) | | Yellow | Rectangle | 10 | (5, 3) |
380 380 | Blue | Rectangle | 10 | (3, 9) | | Blue | Rectangle | 10 | (3, 9) |
381 381 | Blue | Circle | 9 | (4, 6) | | Blue | Circle | 9 | (4, 6) |
382 382
383 | \rowcolor{gray!30} | \{A, B, C, D\} | \{B, C\} | \{A\} | \{D\} |
383 | | \{A, B, C, D\} | \{B, C\} | \{A\} | \{D\} |
384 384 | ---: | :---: | :---: | :---: | :---: | | ---: | :---: | :---: | :---: | :---: |
385 385 | Superkey ? | ✔ | ✔ | ✘ | ✔ | | Superkey ? | ✔ | ✔ | ✘ | ✔ |
386 386 | Key ?| ✘ | ✔ | ✘ | ✔ | | Key ?| ✘ | ✔ | ✘ | ✔ |
 
... ... The three last sublanguages being dubbed "**D**ata **M**anipulation **L**anguage
660 660 #### Yet Another Vocabulary #### Yet Another Vocabulary
661 661
662 662
663 | **SQL** | **"Common"** / **Relational** |
663 | SQL | "Common" / Relational |
664 664 | :--: | :--: | | :--: | :--: |
665 665 | Schema | "Database" | | Schema | "Database" |
666 666 | Catalog (Collection of named Schema) | "Set of Database" | | Catalog (Collection of named Schema) | "Set of Database" |
 
... ... Suppose we have the relational model depicted below, with the indicated data in
2299 2299 **COFFEE** **COFFEE**
2300 2300
2301 2301
2302 \rowcolor{gray!50} \underline{**Ref**} | **Origin** | **TypeOfRoast** | **PricePerPound**
2302 \underline{Ref} | Origin | TypeOfRoast | PricePerPound
2303 2303 :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: |
2304 2304 \(001\) | Brazil | Light | 8.90 \(001\) | Brazil | Light | 8.90
2305 2305 \(121\) | Bolivia | Dark| 7.50 \(121\) | Bolivia | Dark| 7.50
 
... ... Suppose we have the relational model depicted below, with the indicated data in
2308 2308
2309 2309 **CUSTOMER** **CUSTOMER**
2310 2310
2311 \rowcolor{gray!50} \underline{**CardNo**} | **Name** | **Email** | **FavCoffee**
2311 \underline{CardNo} | Name | Email | FavCoffee
2312 2312 :---: | :---: | :---: | :---: | :---: | :---: |
2313 2313 \(001\) | Bob Hill | b.hill@isp.net | 221 \(001\) | Bob Hill | b.hill@isp.net | 221
2314 2314 \(002\) | Ana Swamp | swampa@nca.edu | 311 \(002\) | Ana Swamp | swampa@nca.edu | 311
 
... ... Suppose we have the relational model depicted below, with the indicated data in
2317 2317
2318 2318 **SUPPLY** **SUPPLY**
2319 2319
2320 \rowcolor{gray!50} \underline{**Provider**} | \underline{**Coffee**}
2320 \underline{Provider} | \underline{Coffee}
2321 2321 :---: | :---: | :---: | :---: |
2322 2322 Coffee Unl. | \(001\) Coffee Unl. | \(001\)
2323 2323 Coffee Unl. | \(121\) Coffee Unl. | \(121\)
 
... ... Johns \| Co. | \(221\)
2326 2326
2327 2327 **PROVIDER** **PROVIDER**
2328 2328
2329 \rowcolor{gray!50} \underline{**Name**} | **Email**
2329 \underline{Name} | Email
2330 2330 :---: | :---: | :---: | :---: |
2331 2331 Coffee Unl. | bob@cofunl.com Coffee Unl. | bob@cofunl.com
2332 2332 Coffee Exp. | pat@coffeex.dk Coffee Exp. | pat@coffeex.dk
 
... ... Remember that in Relational models, relations were representing entities and rel
2538 2538 Remember that this model and Relational models are DBMS independant, and the CS is at the border between humans and computers. Remember that this model and Relational models are DBMS independant, and the CS is at the border between humans and computers.
2539 2539 Cf. Figure 7.1 (3.1 in 7th Edition) for the "parrallel journey" of operations. Cf. Figure 7.1 (3.1 in 7th Edition) for the "parrallel journey" of operations.
2540 2540
2541 ![Main phases of database design](book_screen/fig3.1.jpeg)
2541 ![Main phases of database design](before/book_screen/fig3.1.jpeg)
2542 2542
2543 2543 Topics to come include: Topics to come include:
2544 2544
 
... ... A key attribute is an attribute whose value is distinct for each individual in t
2611 2611 - Multivalued = double lined rounded box connected to a square box - Multivalued = double lined rounded box connected to a square box
2612 2612 - Derived = dotted line - Derived = dotted line
2613 2613
2614 ![](paper_screen/Entity_diagram.jpeg){ width=100% }
2614 ![](before/paper_screen/Entity_diagram.jpeg){ width=100% }
2615 2615
2616 ![](paper_screen/Entity_Example.jpeg){ width=100% }
2616 ![](before/paper_screen/Entity_Example.jpeg){ width=100% }
2617 2617
2618 2618 --- ---
2619 2619
 
... ... Naming convention:
2635 2635 - Verb for relationship. Avoid blurry names (not "HAS") - Verb for relationship. Avoid blurry names (not "HAS")
2636 2636 - Drawing usually read right to left, and up to down. COMPANY WORKS_FOR CITIZEN: no, pick EMPLOYS). - Drawing usually read right to left, and up to down. COMPANY WORKS_FOR CITIZEN: no, pick EMPLOYS).
2637 2637
2638 ![](paper_screen/Relationship_instance.jpeg){ width=100% }
2638 ![](before/paper_screen/Relationship_instance.jpeg){ width=100% }
2639 2639
2640 2640
2641 2641 #### Recursive And Role Names #### Recursive And Role Names
2642 2642
2643 2643 Convenient, and sometimes mandatory, to give role names: Convenient, and sometimes mandatory, to give role names:
2644 2644
2645 ![](paper_screen/Role_names.jpeg){ width=100% }
2646 ![](paper_screen/Recursive_role_names.jpeg){ width=100% }
2645 ![](before/paper_screen/Role_names.jpeg){ width=100% }
2646 ![](before/paper_screen/Recursive_role_names.jpeg){ width=100% }
2647 2647
2648 2648 Stress one aspect of the relationship. Stress one aspect of the relationship.
2649 2649
 
... ... For binary relations, can be 1:1, N:1, M:N (1 is "at most", M, N is "no maximum"
2662 2662 - COURSE : DEPARTMENT is N:1 - COURSE : DEPARTMENT is N:1
2663 2663 - STUDENT : TEAM is M:N - STUDENT : TEAM is M:N
2664 2664
2665 ![](paper_screen/Cardinality_ratio.jpeg){ width=100% }
2665 ![](before/paper_screen/Cardinality_ratio.jpeg){ width=100% }
2666 2666
2667 2667
2668 2668 #### Participation Constraint #### Participation Constraint
 
... ... Attributes on 1:1, 1:N, N:1 can be migrated (to the N side).
2688 2688
2689 2689 To determine cardinality ratio: fix all but one, wonder how many can be in that relationship. To determine cardinality ratio: fix all but one, wonder how many can be in that relationship.
2690 2690
2691 ![](paper_screen/N_ary_relationship.jpeg){ width=100% }
2691 ![](before/paper_screen/N_ary_relationship.jpeg){ width=100% }
2692 2692
2693 ![](paper_screen/N_ary_relationship02.jpeg){ width=100% }
2693 ![](before/paper_screen/N_ary_relationship02.jpeg){ width=100% }
2694 2694
2695 2695 *Need to find a good 3-ary example* *Need to find a good 3-ary example*
2696 2696
 
... ... Two sorts of entity types:
2709 2709 Weak (child) entity types are identified by **identifying / owner** type that is related to it, in conjunction with one attribute (**the partial key**). Weak (child) entity types are identified by **identifying / owner** type that is related to it, in conjunction with one attribute (**the partial key**).
2710 2710 Relation is called identifiying relationship, and weak entities have a total participation constraint. Relation is called identifiying relationship, and weak entities have a total participation constraint.
2711 2711
2712 ![](paper_screen/Weak_Entity.jpeg){ width=100% }
2712 ![](before/paper_screen/Weak_Entity.jpeg){ width=100% }
2713 2713
2714 2714 Choice between two representation: if pet is involved in other relationships! Choice between two representation: if pet is involved in other relationships!
2715 2715
 
... ... Choice between two representation: if pet is involved in other relationships!
2721 2721
2722 2722 **Drawings** **Drawings**
2723 2723
2724 ![](paper_screen/Entity_Alt_notation01.jpeg){ width=100% }
2724 ![](before/paper_screen/Entity_Alt_notation01.jpeg){ width=100% }
2725 2725
2726 ![](paper_screen/Entity_Alt_notation02.jpeg){ width=100% }
2726 ![](before/paper_screen/Entity_Alt_notation02.jpeg){ width=100% }
2727 2727
2728 2728
2729 2729 Crow's foot notation: Crow's foot notation:
2730 2730
2731 ![](internet_screen/ERD-Notation.PNG)
2731 ![](before/internet_screen/ERD-Notation.PNG)
2732 2732
2733 2733 <https://www.lucidchart.com/pages/ER-diagram-symbols-and-meaning> <https://www.lucidchart.com/pages/ER-diagram-symbols-and-meaning>
2734 2734
2735 ![](internet_screen/ERD-artist-performs-song.svg)
2735 ![](before/internet_screen/ERD-artist-performs-song.svg)
2736 2736
2737 2737 <https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model#Crow%27s_foot_notation> <https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model#Crow%27s_foot_notation>
2738 2738
 
... ... Closer to OO programming.
2749 2749
2750 2750 From relational models to E.R. models (sometimes needed) From relational models to E.R. models (sometimes needed)
2751 2751
2752 ![](paper_screen/Reverse_Eng1.jpeg){ width=100% }
2752 ![](before/paper_screen/Reverse_Eng1.jpeg){ width=100% }
2753 2753
2754 ![](paper_screen/Reverse_Eng2.jpeg){ width=100% }
2754 ![](before/paper_screen/Reverse_Eng2.jpeg){ width=100% }
2755 2755
2756 ![](paper_screen/Reverse_Eng3.jpeg){ width=100% }
2756 ![](before/paper_screen/Reverse_Eng3.jpeg){ width=100% }
2757 2757
2758 2758 --- ---
2759 2759
 
... ... c. Cross-Reference or Relationship Relation Approach: Create a lookup table with
2791 2791
2792 2792 **Bogue: + Propagate option? Cascade, most of the time: weak entity type, lookup tables, etc.** **Bogue: + Propagate option? Cascade, most of the time: weak entity type, lookup tables, etc.**
2793 2793
2794 ![](paper_screen/ER_To_Rel1.jpeg){ width=100% }
2794 ![](before/paper_screen/ER_To_Rel1.jpeg){ width=100% }
2795 2795
2796 2796
2797 2797 ### Outro ### Outro
 
... ... Att. 1 → Att. 3 | Att. 2 → Att. 1
2954 2954 Functional dependencies list the constraints between two sets of attributes from the database. Functional dependencies list the constraints between two sets of attributes from the database.
2955 2955 X → Y reads "X fixes Y", and applier that values in Y are fixed by the value in X. X → Y reads "X fixes Y", and applier that values in Y are fixed by the value in X.
2956 2956
2957 ![](paper_screen/Fund_Dep.jpeg){ width=100% }
2957 ![](before/paper_screen/Fund_Dep.jpeg){ width=100% }
2958 2958
2959 2959
2960 2960 Note that: Note that:
 
... ... For each attribute $A$ of the relation whose primary key is $A_1, ..., A_n$:
3041 3041 - Remove $A$ from the original relation - Remove $A$ from the original relation
3042 3042 - 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.
3043 3043
3044 ![](paper_screen/2NF1.jpeg){ width=100% }
3044 ![](before/paper_screen/2NF1.jpeg){ width=100% }
3045 3045
3046 3046 Refinment: note that if more than one attribute depends of the same subset $\{A'_1, ..., A'_k\}$, we will create two relations: that is useless, we could have created just one. Refinment: note that if more than one attribute depends of the same subset $\{A'_1, ..., A'_k\}$, we will create two relations: that is useless, we could have created just one.
3047 3047
3048 ![](paper_screen/2NF2.jpeg){ width=100% }
3048 ![](before/paper_screen/2NF2.jpeg){ width=100% }
3049 3049
3050 3050 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.
3051 3051
 
... ... Wide, powerful, but also intimidating.
3102 3102
3103 3103 You know UML from object-oriented programming language: You know UML from object-oriented programming language:
3104 3104
3105 ![](paper_screen/Class_diag.png){ width=100% }
3105 ![](before/paper_screen/Class_diag.png){ width=100% }
3106 3106
3107 3107 That's a class diagram, there are other types of diagrams, they are not unrelated! That's a class diagram, there are other types of diagrams, they are not unrelated!
3108 3108 For instance, using communication diagrams, deployment diagrams, and state chart diagrams, you can collect the requirements needed to draw a class diagram! For instance, using communication diagrams, deployment diagrams, and state chart diagrams, you can collect the requirements needed to draw a class diagram!
 
... ... They each offer a viewpoint on a software that will help you in making sure the
3112 3112
3113 3113 There are 14 different types of diagrams, divided between two categories: structural and behavioral. There are 14 different types of diagrams, divided between two categories: structural and behavioral.
3114 3114
3115 ![](internet_screen/UML_Diagrammhierarchie.svg){ width=100% }
3115 ![](before/internet_screen/UML_Diagrammhierarchie.svg){ width=100% }
3116 3116
3117 3117 #### Structural UML diagrams #### Structural UML diagrams
3118 3118
 
... ... They describe the behavioral, or dynamic, relationship, between components.
3136 3136 - **State machine diagram**, a.k.a., state chart diagram, describes how a system react to external events. You can picture yourself a complex form of finite state automata diagram. - **State machine diagram**, a.k.a., state chart diagram, describes how a system react to external events. You can picture yourself a complex form of finite state automata diagram.
3137 3137 - **Activity diagram** is a flow of control between activities. You may have seen them already, they are supposedly easy to follow: - **Activity diagram** is a flow of control between activities. You may have seen them already, they are supposedly easy to follow:
3138 3138
3139 ![](paper_screen/Activity_diag.png){ width=80% }
3139 ![](before/paper_screen/Activity_diag.png){ width=80% }
3140 3140
3141 3141 Then there is the sub-category of "Interaction diagrams": Then there is the sub-category of "Interaction diagrams":
3142 3142
 
... ... Associations are, to some extend, more expressive than relationship types:
3170 3170 - **As for relationship types** they can have attributes: actually, a whole class can be connected to an association. - **As for relationship types** they can have attributes: actually, a whole class can be connected to an association.
3171 3171 - **As for relationship types**, they can express a cardinality constraint on the relation between classes. They are written as `min .. max`, with `*` for "no maximum", and the following shorthands: `*` stands for `0..*` and `1` stands for `1..1`. An association with `1` on one side and `*` on the other (resp. `1` and `1`, `*` and `1`, `*` and `*`) is sometimes called "one-to-many" (resp., "one-to-one", "many-to-one", "many-to-many"). The notation in partially inverted w.r.t. ER diagrams: - **As for relationship types**, they can express a cardinality constraint on the relation between classes. They are written as `min .. max`, with `*` for "no maximum", and the following shorthands: `*` stands for `0..*` and `1` stands for `1..1`. An association with `1` on one side and `*` on the other (resp. `1` and `1`, `*` and `1`, `*` and `*`) is sometimes called "one-to-many" (resp., "one-to-one", "many-to-one", "many-to-many"). The notation in partially inverted w.r.t. ER diagrams:
3172 3172
3173 ![](paper_screen/Multiplicities.png){ width=60% }
3173 ![](before/paper_screen/Multiplicities.png){ width=60% }
3174 3174
3175 3175 - **As opposed to the relationship types**, they can have a direction, indicating that the user should be able to navigate them only in one direction, or in two (which is the default). This is used for security or privacy purposes. - **As opposed to the relationship types**, they can have a direction, indicating that the user should be able to navigate them only in one direction, or in two (which is the default). This is used for security or privacy purposes.
3176 3176 - **As opposed to the relationship types**, they come in various flavors: - **As opposed to the relationship types**, they come in various flavors:
 
... ... Associations are, to some extend, more expressive than relationship types:
3181 3181
3182 3182 This last feature can be used for weak entities, but not only. This last feature can be used for weak entities, but not only.
3183 3183
3184 ![](internet_screen/Class-Diagram-Relationships.png){ width=80% }
3184 ![](before/internet_screen/Class-Diagram-Relationships.png){ width=80% }
3185 3185
3186 3186 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.
3187 3187
 
... ... Exercise +.#
3226 3226 Exercise +.# Exercise +.#
3227 3227 ~ For the following binary relationships, suggest cardinality ratios based on the common-sense meaning of the entity types. ~ For the following binary relationships, suggest cardinality ratios based on the common-sense meaning of the entity types.
3228 3228
3229 **Entity 1** | **Cardinality Ratio** | **Entity 2** |
3229 Entity 1 | Cardinality Ratio | Entity 2 |
3230 3230 | --- | :---: | --- | | --- | :---: | --- |
3231 3231 STUDENT | | MAJOR STUDENT | | MAJOR
3232 3232 CAR | | TAG CAR | | TAG
 
... ... Solution +.#
3484 3484
3485 3485 Solution +.# Solution +.#
3486 3486
3487 **Entity 1** | **Cardinality Ratio** | **Entity 2** | **Explanation** |
3487 Entity 1 | Cardinality Ratio | Entity 2 | Explanation |
3488 3488 | --- | :---: | --- | --------| | --- | :---: | --- | --------|
3489 3489 STUDENT | N:1 | MAJOR | "A student has one major, but multiple students can have the same major" STUDENT | N:1 | MAJOR | "A student has one major, but multiple students can have the same major"
3490 3490 CAR | 1:1 | TAG | "A car has exactly one tag, a tag belongs to one particular car." CAR | 1:1 | TAG | "A car has exactly one tag, a tag belongs to one particular car."
 
... ... Problem +.#movie
3659 3659 Consider the ER schema for the MOVIES database: Consider the ER schema for the MOVIES database:
3660 3660
3661 3661 \begin{tikzpicture} \begin{tikzpicture}
3662 \node (a) at (0,0) {\includegraphics[page=1,width=1\textwidth]{img/te.pdf}};
3662 \node (a) at (0,0) {\includegraphics[page=1,width=1\textwidth]{before/images/te.pdf}};
3663 3663 \fill[white] (-8.3, 6.5) rectangle (-3.5, 4); \fill[white] (-8.3, 6.5) rectangle (-3.5, 4);
3664 3664 \end{tikzpicture} \end{tikzpicture}
3665 3665
 
... ... A driver has an id, an age, a name, and an address.
3694 3694 One of the interesting choice is: should "accident" be an entity type or a relationship type? One of the interesting choice is: should "accident" be an entity type or a relationship type?
3695 3695
3696 3696 Solution +.# Solution +.#
3697 ~ \includegraphics[page=1,width=1\textwidth]{img/p.pdf}
3697 ~ \includegraphics[page=1,width=1\textwidth]{before/images/p.pdf}
3698 3698
3699 3699 OR OR
3700 3700
 
... ... Look at the following relational model, and "reverse-engineer" it to obtain an E
4080 4080
4081 4081 \node (actortitle) {**ACTOR**}; \node (actortitle) {**ACTOR**};
4082 4082
4083 \node [relation=3, rectangle split horizontal, rectangle split part fill={lightgray!50}, anchor=north west, below=0.6cm of actortitle.west, anchor=west] (actor)
4083 \node [relation=3, rectangle split horizontal, rectangle split part fill={gray!70}, anchor=north west, below=0.6cm of actortitle.west, anchor=west] (actor)
4084 4084 {\underline{Id}% {\underline{Id}%
4085 4085 \nodepart{two} Name \nodepart{two} Name
4086 4086 \nodepart{three} Birthdate \nodepart{three} Birthdate
 
... ... Look at the following relational model, and "reverse-engineer" it to obtain an E
4088 4088
4089 4089 \node [below=1.3cm of actor.west, anchor=west] (movietitle) {**MOVIE**}; \node [below=1.3cm of actor.west, anchor=west] (movietitle) {**MOVIE**};
4090 4090
4091 \node [relation=4, rectangle split horizontal, rectangle split part fill={lightgray!50}, below=0.6cm of movietitle.west, anchor=west] (movie)
4091 \node [relation=4, rectangle split horizontal, rectangle split part fill={gray!70}, below=0.6cm of movietitle.west, anchor=west] (movie)
4092 4092 {\underline{Title}% {\underline{Title}%
4093 4093 \nodepart{two} Year \nodepart{two} Year
4094 4094 \nodepart{three} Length \nodepart{three} Length
 
... ... Look at the following relational model, and "reverse-engineer" it to obtain an E
4098 4098
4099 4099 \node [right=8cm of actortitle.west, anchor=west] (actingtitle) {**ACTING**}; \node [right=8cm of actortitle.west, anchor=west] (actingtitle) {**ACTING**};
4100 4100
4101 \node [relation=2, rectangle split horizontal, rectangle split part fill={lightgray!50}, below=0.6cm of actingtitle.west, anchor=west] (acting)
4101 \node [relation=2, rectangle split horizontal, rectangle split part fill={gray!70}, below=0.6cm of actingtitle.west, anchor=west] (acting)
4102 4102 {\underline{ActorID}% {\underline{ActorID}%
4103 4103 \nodepart{two} \underline{MovieTitle}% \nodepart{two} \underline{MovieTitle}%
4104 4104 }; };
4105 4105
4106 4106 \node [below=1.3cm of movie.west, anchor=west] (theatretitle) {**THEATRE**}; \node [below=1.3cm of movie.west, anchor=west] (theatretitle) {**THEATRE**};
4107 4107
4108 \node [relation=5, rectangle split horizontal, rectangle split part fill={lightgray!50}, anchor=north west, below=0.6cm of theatretitle.west, anchor=west] (theatre)
4108 \node [relation=5, rectangle split horizontal, rectangle split part fill={gray!70}, anchor=north west, below=0.6cm of theatretitle.west, anchor=west] (theatre)
4109 4109 {\underline{Name}% {\underline{Name}%
4110 4110 \nodepart{two} Street \nodepart{two} Street
4111 4111 \nodepart{three} City \nodepart{three} City
 
... ... Look at the following relational model, and "reverse-engineer" it to obtain an E
4115 4115
4116 4116 \node [below=1.3cm of acting.west, anchor=west] (showingtitle) {**SHOWING**}; \node [below=1.3cm of acting.west, anchor=west] (showingtitle) {**SHOWING**};
4117 4117
4118 \node [relation=4, rectangle split horizontal, rectangle split part fill={lightgray!50}, anchor=north west, below=0.6cm of showingtitle.west, anchor=west] (showing)
4118 \node [relation=4, rectangle split horizontal, rectangle split part fill={gray!70}, anchor=north west, below=0.6cm of showingtitle.west, anchor=west] (showing)
4119 4119 {\underline{TheaterName}% {\underline{TheaterName}%
4120 4120 \nodepart{two} \underline{MovieTitle} \nodepart{two} \underline{MovieTitle}
4121 4121 \nodepart{three} \underline{Day} \nodepart{three} \underline{Day}
 
... ... Solution for @problem:mysqlw
4207 4207 ~ For "Car", we need to create an attribute, like "vin". ~ For "Car", we need to create an attribute, like "vin".
4208 4208 For "Car Insurance", "Policy Number" is perfect. For "Car Insurance", "Policy Number" is perfect.
4209 4209
4210 \colorlet{lightgray}{gray!20}
4211
4212 4210 \begin{tikzpicture}[relation/.style={rectangle split, rectangle split parts=#1, rectangle split part align=base, draw, anchor=center, align=center, text height=3mm, text centered}]\hspace*{-0.3cm} \begin{tikzpicture}[relation/.style={rectangle split, rectangle split parts=#1, rectangle split part align=base, draw, anchor=center, align=center, text height=3mm, text centered}]\hspace*{-0.3cm}
4213 4211
4214 4212 % RELATIONS % RELATIONS
4215 4213
4216 4214 \node (phonetitle) {**PHONE**}; \node (phonetitle) {**PHONE**};
4217 4215
4218 \node [relation=2, rectangle split horizontal, rectangle split part fill={lightgray!50}, anchor=north west, below=0.6cm of phonetitle.west, anchor=west] (phone)
4216 \node [relation=2, rectangle split horizontal, rectangle split part fill={gray!70}, anchor=north west, below=0.6cm of phonetitle.west, anchor=west] (phone)
4219 4217 {\underline{id}% {\underline{id}%
4220 4218 \nodepart{two} \underline{number} \nodepart{two} \underline{number}
4221 4219 }; };
4222 4220
4223 4221 \node [below=1.3cm of phone.west, anchor=west] (persontitle) {**PERSON**}; \node [below=1.3cm of phone.west, anchor=west] (persontitle) {**PERSON**};
4224 4222
4225 \node [relation=6, rectangle split horizontal, rectangle split part fill={lightgray!50}, below=0.6cm of persontitle.west, anchor=west] (person)
4223 \node [relation=6, rectangle split horizontal, rectangle split part fill={gray!70}, below=0.6cm of persontitle.west, anchor=west] (person)
4226 4224 {\underline{id}% {\underline{id}%
4227 4225 \nodepart{two} Name \nodepart{two} Name
4228 4226 \nodepart{three} Street \nodepart{three} Street
 
... ... For "Car Insurance", "Policy Number" is perfect.
4233 4231
4234 4232 \node [below=1.1cm of person.west, anchor=west] (cartitle) {**CAR**}; \node [below=1.1cm of person.west, anchor=west] (cartitle) {**CAR**};
4235 4233
4236 \node [relation=5, rectangle split horizontal, rectangle split part fill={lightgray!50}, anchor=north west, below=0.6cm of cartitle.west, anchor=west] (car)
4234 \node [relation=5, rectangle split horizontal, rectangle split part fill={gray!70}, anchor=north west, below=0.6cm of cartitle.west, anchor=west] (car)
4237 4235 {\underline{Vin}% {\underline{Vin}%
4238 4236 \nodepart{two} Make \nodepart{two} Make
4239 4237 \nodepart{three} Year \nodepart{three} Year
 
... ... For "Car Insurance", "Policy Number" is perfect.
4243 4241
4244 4242 \node [below=1.4cm of car.west, anchor=west] (carinsurancetitle) {**CAR INSURANCE**}; \node [below=1.4cm of car.west, anchor=west] (carinsurancetitle) {**CAR INSURANCE**};
4245 4243
4246 \node [relation=4, rectangle split horizontal, rectangle split part fill={lightgray!50}, anchor=north west, below=0.6cm of carinsurancetitle.west, anchor=west] (carinsurance)
4244 \node [relation=4, rectangle split horizontal, rectangle split part fill={gray!70}, anchor=north west, below=0.6cm of carinsurancetitle.west, anchor=west] (carinsurance)
4247 4245 {\underline{Policy Number}% {\underline{Policy Number}%
4248 4246 \nodepart{two} Covered Amount \nodepart{two} Covered Amount
4249 4247 \nodepart{three} Company Name \nodepart{three} Company Name
 
... ... include/sol.sql
4335 4333
4336 4334 **Code à inclure ici** **Code à inclure ici**
4337 4335
4338 ![](include/mysql_workbench_drawing-crop.pdf)
4336 ![](before/include/mysql_workbench_drawing-crop.pdf)
4339 4337
4340 4338 # Databases Applications # Databases Applications
4341 4339
 
... ... Java actually uses
4377 4375 - A **protocol** (the API, a class libarary), Java DataBase Connectivity (JDBC), common to all DBMS. Essentially, a collection of classes to send SQL statements, retriev and update the results of a query, handle exceptions, etc. - A **protocol** (the API, a class libarary), Java DataBase Connectivity (JDBC), common to all DBMS. Essentially, a collection of classes to send SQL statements, retriev and update the results of a query, handle exceptions, etc.
4378 4376 - A **subprotocol** (the driver, connector), Connector/J for MySQL. - A **subprotocol** (the driver, connector), Connector/J for MySQL.
4379 4377
4380 ![](paper_screen/Connector.png){ height=50% }
4378 ![](before/paper_screen/Connector.png){ height=50% }
4381 4379
4382 4380 And the routine is a bit more complex: And the routine is a bit more complex:
4383 4381
 
... ... An example of XML (Extensible Markup Languag) document (you can actually convert
5119 5117
5120 5118 ### General Organization of MongoDB Databases ### General Organization of MongoDB Databases
5121 5119
5122 **RDBMS** | **MongoDB** |
5120 RDBMS | MongoDB |
5123 5121 --- | --- --- | ---
5124 5122 database instance | MongoDB instance database instance | MongoDB instance
5125 5123 schema | database schema | database
File notes/bib/bib.bib renamed from notes/bib.bib (similarity 100%)
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