RocketGit

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

Material for Database Class.

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

master

List of commits:

Subject	Hash	Author	Date (UTC)
updated	a080901830e9ef778e099d2cbf06d37af41e880e	Poonam Veeral	2020-04-08 13:15:26
er updated	69bb6e5cfd8f31c5347d8b6b6e9e3a4e5ef6580c	Poonam Veeral	2020-04-08 12:51:37
er deleted	3543da66bdd8adff409cf79707fb11584b490f67	Poonam Veeral	2020-04-08 12:41:23
fd updated	0a92b326fdc2fea4cd908c6ca4d14b2d635e1728	Poonam Veeral	2020-04-08 12:40:47
fd deleted	8ba0a92ca38f25f6bb10b68d27e0cfb5b8719a3f	Poonam Veeral	2020-04-08 12:36:42
misc updated	37bac44c663e91e07d28a76031aef855907e097d	Poonam Veeral	2020-04-08 12:36:01
misc deleted	3a5c7e6b44694169109a1fb71e2f23508708dd67	Poonam Veeral	2020-04-08 12:35:23
rel_mod updated	d20af615ee586d57e85b873f28174870cf33d574	Poonam Veeral	2020-04-08 12:34:37
deleted	dc4debbc6caa6857438051f3591b692186878392	Poonam Veeral	2020-04-08 12:33:42
rel_mod updated	e75e40028412899276f36b55ddf8856d47e1b1dc	Poonam Veeral	2020-04-08 12:31:58
uml updated	66ee8ea267cb09112b0eae2b106936f81caa1d79	Poonam Veeral	2020-04-08 12:25:06
uml folder deleted	219c795f28525733c62e7cfffecc9339295c492e	Poonam Veeral	2020-04-08 12:22:59
uml folder updated	f1a1e6532efb36ac4df1e20ebe6fc7dc21f3d70c	Poonam Veeral	2020-04-07 19:55:02
img folder updated	57c7ea4b6eebae552a5ca1667ccdba7c16f18a9d	Poonam Veeral	2020-04-07 19:42:45
img folder deleted	79804ff5740d2a8256dd42bfe909e9abd079bd01	Poonam Veeral	2020-04-07 19:41:58
Update lectures_notes.md	764f19778c397d6b592b88945e6c803ea9e33b75	poonamveeral	2020-04-07 19:23:21
Update lectures_notes.md	75ce1301b80c1f8a23dc88b9033c581b7c287de5	poonamveeral	2020-04-07 19:14:57
Update lectures_notes.md	c568007f7cecde6171535a30b15f97bc6b561db0	Poonam Veeral	2020-04-07 19:06:47
img Folder Naming Convention Updated	76e82959772152908a87a52a0645783eb6afc0ed	Poonam Veeral	2020-04-07 18:54:54
Rename Shiporder.xml to shipOrder.xml	5bc4b056c197102d04eedaac06272a344de7d63b	poonamveeral	2020-04-07 18:33:27

Commit a080901830e9ef778e099d2cbf06d37af41e880e - updated
Author: Poonam Veeral
Author date (UTC): 2020-04-08 13:15
Committer name: Poonam Veeral
Committer date (UTC): 2020-04-08 13:15
Parent(s): 69bb6e5cfd8f31c5347d8b6b6e9e3a4e5ef6580c
Signer:
Signing key:
Signing status: N
Tree: 8dc1c61d36e19d3010236c112d05d18b6ffe6dc2

File	Lines added	Lines deleted
notes/fig/uml/flight_01.tex	0	0
notes/lectures_notes.md	97	97

File notes/fig/uml/flight_01.tex renamed from notes/fig/uml/flight.tex (similarity 100%)

File notes/lectures_notes.md changed (mode: 100644) (index 0c32f72..5ca0025)
...	...	CAR(VIN (PK), Make, Model, Year)
851	851	DRIVER(State (PK), Licence\_number (PK), Name, Address)	DRIVER(State (PK), Licence\_number (PK), Name, Address)
852	852	INSURANCE(Policy\_Number (PK), Insured\_Car (FK to CAR.VIN), Insured\_Driver\_State (FK to DRIVER.State), Insured\_Driver\_Num (FK to DRIVER.Licence\_number), Rate)	INSURANCE(Policy\_Number (PK), Insured\_Car (FK to CAR.VIN), Insured\_Driver\_State (FK to DRIVER.State), Insured\_Driver\_Num (FK to DRIVER.Licence\_number), Rate)
853	853	PRICE(Stock\_number (PK), Car\_Vin (FK to CAR.VIN), Price, Margin)	PRICE(Stock\_number (PK), Car\_Vin (FK to CAR.VIN), Price, Margin)
854		](fig/rel_mod/CAR1)
	854		](fig/rel_mod/car_01)
855	855	\	\
856	856
857	857	(Yes, we do need the state and the licence number to uniquely identify a driver's licence, since [many states use the same licence format](https://ntsi.com/drivers-license-format/).	(Yes, we do need the state and the licence number to uniquely identify a driver's licence, since [many states use the same licence format](https://ntsi.com/drivers-license-format/).

...	...	Exercise +.#
1006	1006	AUTHOR(Ref, Name, Address)	AUTHOR(Ref, Name, Address)
1007	1007	BOOK(ISSN, AuthorRef, Title)	BOOK(ISSN, AuthorRef, Title)
1008	1008	GAINED-AWARD(Ref, Name, BookISSN, Year)	GAINED-AWARD(Ref, Name, BookISSN, Year)
1009		](fig/rel_mod/BOOK_Exo)
	1009		](fig/rel_mod/book_exo)
1010	1010	\	\
1011	1011
1012	1012	For each relation, answer the following:	For each relation, answer the following:

...	...	Exercise +.#
1022	1022	TRAIN(Ref (PK), Model, Year)	TRAIN(Ref (PK), Model, Year)
1023	1023	CONDUCTOR(CompanyID (PK), Name, ExperienceLevel)	CONDUCTOR(CompanyID (PK), Name, ExperienceLevel)
1024	1024	ASSIGNED-TO(TrainRef (PK, FK to TRAIN.Ref), ConductorID (PK, FK to CONDUCTOR.CompanyID), Date (PK))	ASSIGNED-TO(TrainRef (PK, FK to TRAIN.Ref), ConductorID (PK, FK to CONDUCTOR.CompanyID), Date (PK))
1025		](fig/rel_mod/TRAIN_Exo)
	1025		](fig/rel_mod/train_exo)
1026	1026	\	\
1027	1027
1028	1028	#. What are the foreign keys in the ASSIGNED-TO relation? What are they refering?	#. What are the foreign keys in the ASSIGNED-TO relation? What are they refering?

...	...	Exercise +.#
1078	1078	![	![
1079	1079	BUILDING(Name (PK), Address)	BUILDING(Name (PK), Address)
1080	1080	ROOM(Code (PK), Building (FK to BUILDING.Name))	ROOM(Code (PK), Building (FK to BUILDING.Name))
1081		](fig/rel_mod/BUILDING_ROOM)
	1081		](fig/rel_mod/building_room)
1082	1082	\	\
1083	1083
1084	1084	#. Give two possible tuples for the BUILDING relation, and two possible tuples for the ROOM relation such that the state is consistent.	#. Give two possible tuples for the BUILDING relation, and two possible tuples for the ROOM relation such that the state is consistent.

...	...	Solution +.#
1170	1170	AUTHOR(Ref (PK), Name, Address)	AUTHOR(Ref (PK), Name, Address)
1171	1171	BOOK(ISSN (PK), AuthorRef (FK to AUTHOR.REF), Title)	BOOK(ISSN (PK), AuthorRef (FK to AUTHOR.REF), Title)
1172	1172	GAINED-AWARD(Ref (PK), Name, BookISSN (FK to BOOK.ISSN), Year)	GAINED-AWARD(Ref (PK), Name, BookISSN (FK to BOOK.ISSN), Year)
1173		](fig/rel_mod/BOOK_Sol)
	1173		](fig/rel_mod/book_sol)
1174	1174	\	\
1175	1175
1176	1176	For the last question, the answer is yes: based on the ISSN of the book, we can retrieve the author of the book. Hence, knowing which book was awarded which year, by looking in the GAINED-AWARD table, gives us the answer to that question.	For the last question, the answer is yes: based on the ISSN of the book, we can retrieve the author of the book. Hence, knowing which book was awarded which year, by looking in the GAINED-AWARD table, gives us the answer to that question.

...	...	Solution +.#
1212	1212	![	![
1213	1213	MOVIE(Title (PK), Year)	MOVIE(Title (PK), Year)
1214	1214	CHARACTER(Name(PK), First_Appearance (FK referencing MOVIE.Title))	CHARACTER(Name(PK), First_Appearance (FK referencing MOVIE.Title))
1215		](fig/rel_mod/CHARACTER)
	1215		](fig/rel_mod/character)
1216	1216	\	\
1217	1217
1218	1218	#. Inserting <"Ash", "Evil Dead"> into the CHARACTER relation would cause an error if the database was empty, since no movie with the primary key "Evil Dead" has been introduced yet: this would be a referential integrity constraint violation.	#. Inserting <"Ash", "Evil Dead"> into the CHARACTER relation would cause an error if the database was empty, since no movie with the primary key "Evil Dead" has been introduced yet: this would be a referential integrity constraint violation.

...	...	Solution to [%D %n (%T)](#problem:cinema)
1301	1301	AUDITORIUM(ID (PK), Capacity, Theater (FK to THEATER.ID))	AUDITORIUM(ID (PK), Capacity, Theater (FK to THEATER.ID))
1302	1302	SHOWTIME(ID (PK), MovieId (FK to MOVIE.ID), AuditoriumId (FK to AUDITORIUM.ID), StartTime)	SHOWTIME(ID (PK), MovieId (FK to MOVIE.ID), AuditoriumId (FK to AUDITORIUM.ID), StartTime)
1303	1303	TICKETS(ID (PK), ShowTimeId (FK to SHOWTIME.ID), Price)	TICKETS(ID (PK), ShowTimeId (FK to SHOWTIME.ID), Price)
1304		](fig/rel_mod/CINEMA)
	1304		](fig/rel_mod/cinema)
1305	1305	\	\
1306	1306
1307	1307	---	---

...	...	Solution to [%D %n (%T)](#problem:rel_model_bills)
1316	1316	MEMBER(Name, Political Group, BTerm, ETerm, ID (PK))	MEMBER(Name, Political Group, BTerm, ETerm, ID (PK))
1317	1317	REPRESENTATIVE(Role (PK), Member (FK to MEMBER.ID))	REPRESENTATIVE(Role (PK), Member (FK to MEMBER.ID))
1318	1318	VOTE(Bill (PK, FK to BILL.ID), Member (PK, FK to MEMBER.ID))	VOTE(Bill (PK, FK to BILL.ID), Member (PK, FK to MEMBER.ID))
1319		](fig/rel_mod/BILL)
	1319		](fig/rel_mod/bill)
1320	1320	\	\
1321	1321
1322	1322	For simplicity, we added an `ID` to our `MEMBER` and `BILL` relations. Note that having a "role" in the `MEMBER` relation to store the information about speaker, etc., would be extremely inefficient, since we would add an attribute to the ~435 members that would be `NULL`{.sqlmysql} in ~430 of them.	For simplicity, we added an `ID` to our `MEMBER` and `BILL` relations. Note that having a "role" in the `MEMBER` relation to store the information about speaker, etc., would be extremely inefficient, since we would add an attribute to the ~435 members that would be `NULL`{.sqlmysql} in ~430 of them.

...	...	CAMPUS (Address (PK), University (FK to UNIVERSITY.Name))
1337	1337	DEPARTMENT (Code (PK), Contact, CreationDate, University (FK to UNIVERSITY.Name))	DEPARTMENT (Code (PK), Contact, CreationDate, University (FK to UNIVERSITY.Name))
1338	1338	COURSE (Name (PK), CreditHours)	COURSE (Name (PK), CreditHours)
1339	1339	OFFERING (Department (PK, FK to DEPARTMENT.Name), Course (PK, FK to COURSE.Name), Code)	OFFERING (Department (PK, FK to DEPARTMENT.Name), Course (PK, FK to COURSE.Name), Code)
1340		](fig/rel_mod/UNIVERSITIES)
	1340		](fig/rel_mod/universities)
1341	1341	\	\
1342	1342
1343	1343

...	...	MariaDB [HW_CONSTRAINTS_PART3]> SELECT FROM Table_set_null;*
1923	1923	![	![
1924	1924	PROF(Login (PK), Name, Department (FK to DEPARTMENT.Code))	PROF(Login (PK), Name, Department (FK to DEPARTMENT.Code))
1925	1925	DEPARTMENT(Code (PK), Name, Head (FK to PROF.Login))	DEPARTMENT(Code (PK), Name, Head (FK to PROF.Login))
1926		](fig/rel_mod/PROF_DEPARTMENT)
	1926		](fig/rel_mod/prof_department)
1927	1927	\	\
1928	1928
1929	1929	~~~{.sqlmysql}	~~~{.sqlmysql}

...	...	Solution to [%D %n (%T)](#problem:address)
4124	4124	![	![
4125	4125	NAME(FName, LName, ID(PK))	NAME(FName, LName, ID(PK))
4126	4126	ADDRESS(StreetName (PK), Number (PK), Habitants (FK referencing NAME.ID))	ADDRESS(StreetName (PK), Number (PK), Habitants (FK referencing NAME.ID))
4127		](fig/rel_mod/ADDRESS)
	4127		](fig/rel_mod/address)
4128	4128	\	\
4129	4129
4130	4130	@problem:address -- Solution to Q. -.#	@problem:address -- Solution to Q. -.#

...	...	Solution to [%D %n (%T)](#problem:profrevisited)
4326	4326	LECTURE (Code (PK), Year (PK), Name, Instructor (FK to PROF.Login)	LECTURE (Code (PK), Year (PK), Name, Instructor (FK to PROF.Login)
4327	4327	STUDENT(Login (PK), Name, Registered, Major (FK to DEPARTMENT.Code))	STUDENT(Login (PK), Name, Registered, Major (FK to DEPARTMENT.Code))
4328	4328	GRADE (Login (PK, FK to STUDENT.Login), Grade (PK), LectureCode (FK to LECTURE.Code), LectureYear (FK to LECTURE.Year))	GRADE (Login (PK, FK to STUDENT.Login), Grade (PK), LectureCode (FK to LECTURE.Code), LectureYear (FK to LECTURE.Year))
4329		](fig/rel_mod/PROF_DEPARTMENT_EXTENDED)
	4329		](fig/rel_mod/prof_department_extended)
4330	4330	\	\
4331	4331
4332	4332	For the other questions, refer to this code.	For the other questions, refer to this code.

...	...	Solution to [%D %n (%T)](#problem:coffee)
4356	4356	CUSTOMER (CardNo (PK), Name, Email, FavCoffee (FK to COFFEE.Ref))	CUSTOMER (CardNo (PK), Name, Email, FavCoffee (FK to COFFEE.Ref))
4357	4357	SUPPLY (Provider (PK, FK to PROVIDEV.ID), Coffee (PK, FK to COFEE.Ref))	SUPPLY (Provider (PK, FK to PROVIDEV.ID), Coffee (PK, FK to COFEE.Ref))
4358	4358	PROVIDER (Name (PK), Email)	PROVIDER (Name (PK), Email)
4359		](fig/rel_mod/COFFEE)
	4359		](fig/rel_mod/coffee)
4360	4360	\	\
4361	4361
4362	4362

...	...	Solution to [%D %n (%T)](#problem:roleplaying)
4434	4434	QUEST(Name (PK), XP)	QUEST(Name (PK), XP)
4435	4435	COMPLETED-BY(Character (PK, FK to CHARACTER.Name), Quest (PK, FK to QUEST.Name))	COMPLETED-BY(Character (PK, FK to CHARACTER.Name), Quest (PK, FK to QUEST.Name))
4436	4436	SPECIAL-ITEM(Name (P), Quest (FK to QUEST.Name))	SPECIAL-ITEM(Name (P), Quest (FK to QUEST.Name))
4437		](fig/rel_mod/RPG)
	4437		](fig/rel_mod/rpg)
4438	4438	\	\
4439	4439
4440	4440	---	---

...	...	Solution to [%D %n (%T)](#problem:sqlWorks)
4575	4575	AUTHOR(Name (PK), Email)	AUTHOR(Name (PK), Email)
4576	4576	BOOK(ISBN (PK), Work (FK to WORK.Title), Published, Price)	BOOK(ISBN (PK), Work (FK to WORK.Title), Published, Price)
4577	4577	EBOOK(ISBN (PK), Work (FK to WORK.Title), Published, Price)	EBOOK(ISBN (PK), Work (FK to WORK.Title), Published, Price)
4578		](fig/rel_mod/WORK)
	4578		](fig/rel_mod/work)
4579	4579	\	\
4580	4580
4581	4581	The solution to the next questions can be read from the following code:	The solution to the next questions can be read from the following code:

...	...	multivalued \| the box have double lines \|
4704	4704	derived \| the box have dotted lines \|	derived \| the box have dotted lines \|
4705	4705	a key \| the name of the attribute is underlined \|	a key \| the name of the attribute is underlined \|
4706	4706
4707		![](fig/er/Naming)
	4707		![](fig/er/naming)
4708	4708	\	\
4709	4709
4710		![](fig/er/Entity_Instructor)
	4710		![](fig/er/entity_instructor)
4711	4711	\	\
4712	4712
4713	4713	In the following, we'll focus on the relationship between the entities more than on the attributes of particular entities, so we'll sometimes simply draw	In the following, we'll focus on the relationship between the entities more than on the attributes of particular entities, so we'll sometimes simply draw
4714	4714
4715		![](fig/er/Naming_short1)
	4715		![](fig/er/naming_short_01)
4716	4716	\	\
4717	4717
4718	4718	leaving the attributes un-specified (but that does not mean that they all have to be atomic) or even just	leaving the attributes un-specified (but that does not mean that they all have to be atomic) or even just
4719	4719
4720	4720
4721		![](fig/er/Naming_short2)
	4721		![](fig/er/naming_short_02)
4722	4722	\	\
4723	4723
4724	4724	but that does not mean that the entity type have no attribute!	but that does not mean that the entity type have no attribute!

...	...	but that does not mean that the entity type have no attribute!
4736	4736
4737	4737	$E_1$, … $E_n$ participate in R, $e_1$, …, $e_n$ participate in $r_1$, $n$ is the degree.	$E_1$, … $E_n$ participate in R, $e_1$, …, $e_n$ participate in $r_1$, $n$ is the degree.
4738	4738
4739		![](fig/er/Rel_Instance)
	4739		![](fig/er/rel_instance)
4740	4740	\	\
4741	4741
4742	4742	Note that we can have Entity Set 1 = Entity Set 2, in which case we say the relation is recursive.	Note that we can have Entity Set 1 = Entity Set 2, in which case we say the relation is recursive.

...	...	Naming convention:
4749	4749	- Drawing usually reads right to left, and up to down.	- Drawing usually reads right to left, and up to down.
4750	4750
4751	4751
4752		![](fig/er/Bad_Design)
	4752		![](fig/er/bad_design)
4753	4753	\	\
4754	4754
4755	4755

...	...	Convenient, and sometimes mandatory, to give role names.
4759	4759
4760	4760	If we want to stress that we are considering only one aspect of an entity (that is, a person is not only an employee, a company is not only an employer, but this aspect is crucial for the "EMPLOYS" relation):	If we want to stress that we are considering only one aspect of an entity (that is, a person is not only an employee, a company is not only an employer, but this aspect is crucial for the "EMPLOYS" relation):
4761	4761
4762		![](fig/er/Role_Name1)
	4762		![](fig/er/role_name_01)
4763	4763
4764	4764	We can also use it to make the "right-side" and the "left-side" of a recursive relationship explicit:	We can also use it to make the "right-side" and the "left-side" of a recursive relationship explicit:
4765	4765
4766		![](fig/er/Role_Name2)
4767		![](fig/er/Role_Name3)
	4766		![](fig/er/role_name_02)
	4767		![](fig/er/role_name_03)
4768	4768
4769	4769	Finally, we will sometimes use "Role Name of Entity 1 : Role Name of Entity 2" as a notation for the relation between them.	Finally, we will sometimes use "Role Name of Entity 1 : Role Name of Entity 2" as a notation for the relation between them.
4770	4770	For instance, we can write "Employer:Employee" to denote the "EMPLOYS" relation, and we will also use this notation when the relationship is between different entities, and write e.g. "PERSON:POSITION" for the "OCCUPIES" relation.	For instance, we can write "Employer:Employee" to denote the "EMPLOYS" relation, and we will also use this notation when the relationship is between different entities, and write e.g. "PERSON:POSITION" for the "OCCUPIES" relation.

...	...	STUDENT : TEAM \| $M:N$ \| "A student can participate in multiple team, a team can
4793	4793
4794	4794	We indicate the ratio on the edges:	We indicate the ratio on the edges:
4795	4795
4796		![](fig/er/Constraint1)
	4796		![](fig/er/constraint_01)
4797	4797
4798	4798	Note that reflexive relations can have any ratio as well.	Note that reflexive relations can have any ratio as well.
4799	4799	An example of $M:N$ recursive relation could be:	An example of $M:N$ recursive relation could be:
4800	4800
4801		![](fig/er/Software_Dep)
	4801		![](fig/er/software_dep)
4802	4802
4803	4803	##### Participation Constraint	##### Participation Constraint
4804	4804

...	...	The participation can be total (a.k.a. existence dependency, the entity must
4808	4808
4809	4809	Total is drawn with a double line, partial is drawn with a single line:	Total is drawn with a double line, partial is drawn with a single line:
4810	4810
4811		![](fig/er/Constraint2)
	4811		![](fig/er/constraint_02)
4812	4812
4813	4813	This reads "a course must be offered by a department, but a department may or may not offer courses".	This reads "a course must be offered by a department, but a department may or may not offer courses".
4814	4814

...	...	We are dealing with moving aspects here: atributes on $1:1$, $1:N$, $N:1$ relati
4825	4825
4826	4826	For instance, imagine that every phone uses exactly (= "at most and at least") one carrier, that a carrier can provide network to multiple phones, and that the average quality of the network is an attribute in this relationship:	For instance, imagine that every phone uses exactly (= "at most and at least") one carrier, that a carrier can provide network to multiple phones, and that the average quality of the network is an attribute in this relationship:
4827	4827
4828		![](fig/er/Phone_Carrier1)
	4828		![](fig/er/phone_carrier_01)
4829	4829
4830	4830	Then each instance of the relation would be of the form ("Phone X", "Carrier Y", "$9/10$") for some way of ranking the average quality from $0$ to $10$.	Then each instance of the relation would be of the form ("Phone X", "Carrier Y", "$9/10$") for some way of ranking the average quality from $0$ to $10$.
4831	4831	Note that, from the fact that the relationship is $N:1$, this means that there is only one tuple involving "Phone X": this means that the average quality could actually be seen as a property of _the phone_, and hence be migrated as an attribute to the phone side:	Note that, from the fact that the relationship is $N:1$, this means that there is only one tuple involving "Phone X": this means that the average quality could actually be seen as a property of _the phone_, and hence be migrated as an attribute to the phone side:
4832	4832
4833		![](fig/er/Phone_Carrier2)
	4833		![](fig/er/phone_carrier_02)
4834	4834
4835	4835	Note that we could not migrate the "average phone quality" to the "Carrier" side: imagine if we had the instances ("Phone X", "Carrier Y", "$9/10$") and ("Phone Z", "Carrier Y", "$3/10$"), then should the attribute of "Carrier Y" be "$9/10$" or "$3/10$": we have no way of deciding based on this model.	Note that we could not migrate the "average phone quality" to the "Carrier" side: imagine if we had the instances ("Phone X", "Carrier Y", "$9/10$") and ("Phone Z", "Carrier Y", "$3/10$"), then should the attribute of "Carrier Y" be "$9/10$" or "$3/10$": we have no way of deciding based on this model.
4836	4836

...	...	As an exercise, you can look at the relationships TEACHING, MENTORING and EMITED
4842	4842	Of course, relationships can have a degree higher than two.	Of course, relationships can have a degree higher than two.
4843	4843	An example of a ternary relation could be:	An example of a ternary relation could be:
4844	4844
4845		![](fig/er/Account)
	4845		![](fig/er/account)
4846	4846
4847	4847	To determine cardinality ratio, one should fix all but one parameters, and wonder how many values of the remaining parameter can be in that relationship.	To determine cardinality ratio, one should fix all but one parameters, and wonder how many values of the remaining parameter can be in that relationship.
4848	4848

...	...	On the oppsite, Customer Y and Account K would be in relationship with only $1$
4852	4852	It is sometimes impossible to do without relations with arity greater than $2$.	It is sometimes impossible to do without relations with arity greater than $2$.
4853	4853	For instance, consider the following two diagrams:	For instance, consider the following two diagrams:
4854	4854
4855		![](fig/er/Book)
	4855		![](fig/er/book_01)
4856	4856
4857		![](fig/er/Book2)
	4857		![](fig/er/book_02)
4858	4858
4859	4859	You should realize that they convey different information.	You should realize that they convey different information.
4860	4860	For instance, you can know for a fact that a person visit a library only if they bought something in it, while the second diagram de-correlate the act of buying with the visit to a library.	For instance, you can know for a fact that a person visit a library only if they bought something in it, while the second diagram de-correlate the act of buying with the visit to a library.

...	...	Similarly, the second diagram could give you a hint that a person that owns a co
4862	4862
4863	4863	An example of recursive ternary relation could be:	An example of recursive ternary relation could be:
4864	4864
4865		![](fig/er/Parents)
	4865		![](fig/er/parents)
4866	4866
4867	4867	An example of relation of degree $4$ could be:	An example of relation of degree $4$ could be:
4868	4868
4869		![](fig/er/Teaches)
	4869		![](fig/er/teaches)
4870	4870
4871	4871
4872	4872	---	---

...	...	The partial key* is an attribute, that, _when paired with an entity with whic*
4885	4885
4886	4886	Weak entities and identifying relationships have a double border, and partial key have a dotted underline, as follows:	Weak entities and identifying relationships have a double border, and partial key have a dotted underline, as follows:
4887	4887
4888		![](fig/er/Dependent)
	4888		![](fig/er/dependent)
4889	4889
4890	4890	The idea here is that we do not need to gather data about all the dependent in the world, or in isolation, but are interrested in dependent only if they are related to en employee in our database.	The idea here is that we do not need to gather data about all the dependent in the world, or in isolation, but are interrested in dependent only if they are related to en employee in our database.
4891	4891	Just having the name of a dependent is not enough to identify them, but having their name _and_ the SSN of the employee they are related to is enough.	Just having the name of a dependent is not enough to identify them, but having their name _and_ the SSN of the employee they are related to is enough.

...	...	If you need to have, for instance, a dependant connected to multiple employees,
4895	4895	You may wonder why we do not represent weak entities simply as (composite, multi-valued) attributes of their owner type.	You may wonder why we do not represent weak entities simply as (composite, multi-valued) attributes of their owner type.
4896	4896	For instance, why would we use	For instance, why would we use
4897	4897
4898		![](fig/er/Pet1)
	4898		![](fig/er/pet_01)
4899	4899
4900	4900	instead of	instead of
4901	4901
4902		![](fig/er/Pet2)
	4902		![](fig/er/pet_02)
4903	4903
4904	4904	?	?
4905	4905	The answer depends whenever we need to have the ability to represent our weak entities (here, PET) as being in relationship with other entities (that can themselves be weak!), as follows:	The answer depends whenever we need to have the ability to represent our weak entities (here, PET) as being in relationship with other entities (that can themselves be weak!), as follows:
4906	4906
4907		![](fig/er/Pet3)
	4907		![](fig/er/pet_03)
4908	4908
4909	4909	This would be impossible if PET was an attribute of FRIEND!	This would be impossible if PET was an attribute of FRIEND!
4910	4910	Whenever the pet entity type is involved in other relationships or not should help you in deciding which representation to chose.	Whenever the pet entity type is involved in other relationships or not should help you in deciding which representation to chose.

...	...	Whenever the pet entity type is involved in other relationships or not should he
4915	4915
4916	4916	Another example of weak entity whose owner is weak as well could be:	Another example of weak entity whose owner is weak as well could be:
4917	4917
4918		![](fig/er/Doula)
	4918		![](fig/er/doula)
4919	4919
4920	4920	The idea being that the Health care provider cares about an insuree only if they are covered by them, and that they care about the doula only if they are currently helping one of their insuree.	The idea being that the Health care provider cares about an insuree only if they are covered by them, and that they care about the doula only if they are currently helping one of their insuree.
4921	4921

...	...	The two constraints can be written on the same side, and the $N$, $M$, $P$ ratio
4933	4933
4934	4934	For instance,	For instance,
4935	4935
4936		![](fig/er/Alt_Not1)
	4936		![](fig/er/alt_not_01)
4937	4937
4938	4938	could be drawn as	could be drawn as
4939	4939
4940		![](fig/er/Alt_Not2)
	4940		![](fig/er/alt_not_02)
4941	4941
4942	4942	meaning that	meaning that
4943	4943

...	...	meaning that
4946	4946
4947	4947	More generally, we have the following:	More generally, we have the following:
4948	4948
4949		![](fig/er/Alt_Not3)
	4949		![](fig/er/alt_not_03)
4950	4950
4951	4951	#### Crow's Foot Notation {#sec:Crow_foot}	#### Crow's Foot Notation {#sec:Crow_foot}
4952	4952

...	...	Every time a relationships have attributes, they are mapped to the resulting rel
5029	5029	Let us look in more details at some of those steps.	Let us look in more details at some of those steps.
5030	5030	For strong entities, using steps 1 and 7, the following:	For strong entities, using steps 1 and 7, the following:
5031	5031
5032		![](fig/er/Desk)
	5032		![](fig/er/desk)
5033	5033
5034	5034	would give:	would give:
5035	5035
5036	5036	![	![
5037	5037	DESK(Serial(PK), Building, Room)	DESK(Serial(PK), Building, Room)
5038	5038	DESK_COLOR(Desk (PK, FK referencing DESK.Serial))	DESK_COLOR(Desk (PK, FK referencing DESK.Serial))
5039		](fig/rel_mod/DESK)
	5039		](fig/rel_mod/desk)
5040	5040	\	\
5041	5041
5042	5042
5043	5043	And note that if Serial was a complex attribute, we would just "unfold" it, or decompose it, and make all the resulting attributes the primary key of the relation.	And note that if Serial was a complex attribute, we would just "unfold" it, or decompose it, and make all the resulting attributes the primary key of the relation.
5044	5044	If one of the attribute was at the same time multi-valued and composite, as follows:	If one of the attribute was at the same time multi-valued and composite, as follows:
5045	5045
5046		![](fig/er/Computer_User)
	5046		![](fig/er/computer_user)
5047	5047
5048	5048	Then we would obtain:	Then we would obtain:
5049	5049
5050	5050	![	![
5051	5051	COMPUTER(MAC(PK))	COMPUTER(MAC(PK))
5052	5052	COMPUTER_COLOR(Compter (PK, FK referencing COMPUTER.MAC), Name, Email)	COMPUTER_COLOR(Compter (PK, FK referencing COMPUTER.MAC), Name, Email)
5053		](fig/rel_mod/COMPUTER_USER)
	5053		](fig/rel_mod/computer_user)
5054	5054	\	\
5055	5055
5056	5056	For relationships, things are a bit more complicated.	For relationships, things are a bit more complicated.
5057	5057	Consider the following:	Consider the following:
5058	5058
5059		![](fig/er/MappingRelationships1)
	5059		![](fig/er/mapping_relationships_01)
5060	5060
5061	5061	Since it is a $1:1$ relationship where one of the side has a partial constraint, we have the choice between two approaches.	Since it is a $1:1$ relationship where one of the side has a partial constraint, we have the choice between two approaches.
5062	5062	The foreign key approach would give:	The foreign key approach would give:

...	...	The foreign key approach would give:
5064	5064	![	![
5065	5065	ENT.A(KeyA (PK), FK (FK to ENT.B.KeyB))	ENT.A(KeyA (PK), FK (FK to ENT.B.KeyB))
5066	5066	ENT.B(KeyB (PK))	ENT.B(KeyB (PK))
5067		](fig/rel_mod/MappingRelationships1)
	5067		](fig/rel_mod/mapping_relationships_01)
5068	5068	\	\
5069	5069
5070	5070	Note that we could also have added the foreign key on the side of ENT.B, referencing the key of ENT.A.	Note that we could also have added the foreign key on the side of ENT.B, referencing the key of ENT.A.

...	...	For the same diagram, the cross-reference approach would give:
5076	5076	ENT.A(KeyA (PK))	ENT.A(KeyA (PK))
5077	5077	ENT.B(KeyB (PK))	ENT.B(KeyB (PK))
5078	5078	MAPPING(KeyA (PK, FK referencing ENT.A.KeyA), KeyB(FK referencing ENT.B.KeyB))	MAPPING(KeyA (PK, FK referencing ENT.A.KeyA), KeyB(FK referencing ENT.B.KeyB))
5079		](fig/rel_mod/MappingRelationships2)
	5079		](fig/rel_mod/mapping_relationships_02)
5080	5080	\	\
5081	5081
5082	5082	Similarly, note that, in MAPPING, KeyB, or KeyA and KeyB, would also be valid primary keys, but that it makes more sense to have KeyA being the primary key, since we know that ENT.A has a total participation constraint, but ENT.B does not.	Similarly, note that, in MAPPING, KeyB, or KeyA and KeyB, would also be valid primary keys, but that it makes more sense to have KeyA being the primary key, since we know that ENT.A has a total participation constraint, but ENT.B does not.
5083	5083
5084	5084	If both participation constraints were total, as follows:	If both participation constraints were total, as follows:
5085	5085
5086		![](fig/er/MappingRelationships2)
	5086		![](fig/er/mapping_relationships_02)
5087	5087
5088	5088	Then we could use the merged relations approach, and get:	Then we could use the merged relations approach, and get:
5089	5089
5090	5090	![	![
5091	5091	ENT.A.AND.B.(KeyA (PK), KeyB)	ENT.A.AND.B.(KeyA (PK), KeyB)
5092		](fig/rel_mod/MappingRelationships3)
	5092		](fig/rel_mod/mapping_relationships_03)
5093	5093	\	\
5094	5094
5095	5095	We picked KeyA to be the primary key for the same reason as before.	We picked KeyA to be the primary key for the same reason as before.

...	...	Of course, if ENT.A and ENT.B are the same entity (that is, REL is recursive), w
5099	5099
5100	5100	![	![
5101	5101	ENT.A(KeyA (PK), Rel(FK referencing Ent.A.KeyA))	ENT.A(KeyA (PK), Rel(FK referencing Ent.A.KeyA))
5102		](fig/rel_mod/MappingRelationships4)
	5102		](fig/rel_mod/mapping_relationships_04)
5103	5103	\	\
5104	5104
5105	5105	or	or

...	...	or
5107	5107	![	![
5108	5108	ENT.A(KeyA (PK))	ENT.A(KeyA (PK))
5109	5109	REL(KeyA1 (PK, FK referencing Ent.A.KeyA), KeyA2 (FK referencing Ent.A.KeyA))	REL(KeyA1 (PK, FK referencing Ent.A.KeyA), KeyA2 (FK referencing Ent.A.KeyA))
5110		](fig/rel_mod/MappingRelationships5)
	5110		](fig/rel_mod/mapping_relationships_05)
5111	5111	\	\
5112	5112
5113	5113	depending on the approach we chose.	depending on the approach we chose.

...	...	Binary $1:N$ and binary $M:N$ relationships are dealt with in a similar way, usi
5116	5116	The most difficult part of the mapping is with $n$-ary relationships: we have to use cross-reference approaches, but determining the primary key is not an easy task.	The most difficult part of the mapping is with $n$-ary relationships: we have to use cross-reference approaches, but determining the primary key is not an easy task.
5117	5117	Consider the following^[This developement was actually asked at <https://dba.stackexchange.com/q/232068/>.]:	Consider the following^[This developement was actually asked at <https://dba.stackexchange.com/q/232068/>.]:
5118	5118
5119		![](fig/er/Gym)
	5119		![](fig/er/gym)
5120	5120
5121	5121	The arity constraints here can be rephrased as:	The arity constraints here can be rephrased as:
5122	5122

...	...	Att. 1 → Att. 3 \| Att. 2 → Att. 1
5290	5290
5291	5291	#### Notations	#### Notations
5292	5292
5293		![](fig/fd/Notation1)
	5293		![](fig/fd/notation_01)
5294	5294
5295	5295	Or, more conveniently:	Or, more conveniently:
5296	5296
5297		![](fig/fd/Notation2)
	5297		![](fig/fd/notation_02)
5298	5298
5299	5299	If an attribute is a foreign key to another, we will draw an arrow between relations:	If an attribute is a foreign key to another, we will draw an arrow between relations:
5300	5300
5301		![](fig/fd/Notation3)
	5301		![](fig/fd/notation_03)
5302	5302
5303	5303	Note that:	Note that:
5304	5304

...	...	For each attribute $A$ of the relation whose primary key is $A_1, …, A_n$:
5386	5386	- Remove $A$ from the original relation, and all the functional dependencies that implied it,	- Remove $A$ from the original relation, and all the functional dependencies that implied it,
5387	5387	- 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.
5388	5388
5389		![](fig/fd/Course)
	5389		![](fig/fd/course)
5390	5390
5391	5391	becomes	becomes
5392	5392
5393		![](fig/fd/Course_Norm1)
	5393		![](fig/fd/course_norm_01)
5394	5394
5395	5395
5396	5396	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.
5397	5397	For instance, considering	For instance, considering
5398	5398
5399		![](fig/fd/Example2NF1)
	5399		![](fig/fd/example_2NF_01)
5400	5400
5401	5401	applying the algorithm would give	applying the algorithm would give
5402	5402
5403		![](fig/fd/Example2NF2)
	5403		![](fig/fd/example_2NF_02)
5404	5404
5405	5405	whereas a more subtle algorithm would give	whereas a more subtle algorithm would give
5406	5406
5407		![](fig/fd/Example2NF3)
	5407		![](fig/fd/example_2NF_03)
5408	5408
5409	5409	Note that in both cases, all the relations are in Second Normal Form, though.	Note that in both cases, all the relations are in Second Normal Form, though.
5410	5410

...	...	For each attribute $A$ of the relation whose primary key is $A_1, …, A_n$:
5435	5435
5436	5436	We can have a look at another example:	We can have a look at another example:
5437	5437
5438		![](fig/fd/DriverExample1)
	5438		![](fig/fd/driver_example_01)
5439	5439
5440	5440	Note that \{State, Driver\_Licence\_Num\}, would be a valid primary key for this relation, and that adding it would make it a relation in 1NF.	Note that \{State, Driver\_Licence\_Num\}, would be a valid primary key for this relation, and that adding it would make it a relation in 1NF.
5441	5441

...	...	As we can see, the name "Driver" is somehow counter-intuitive, since the relatio
5443	5443	This relation is actually not in 2NF, because the FD \{State, Driver\_Licence\_Num\} → Governor is not fully functional.	This relation is actually not in 2NF, because the FD \{State, Driver\_Licence\_Num\} → Governor is not fully functional.
5444	5444	A possible way to fix it is to get:	A possible way to fix it is to get:
5445	5445
5446		![](fig/fd/DriverExample2)
	5446		![](fig/fd/driver_example_02)
5447	5447
5448	5448	As you can see, the 2NF helped us in separating properly the entities.	As you can see, the 2NF helped us in separating properly the entities.
5449	5449
5450	5450	An example of a relation that is in 2NF but not in 3NF could be:	An example of a relation that is in 2NF but not in 3NF could be:
5451	5451
5452		![](fig/fd/StudentExample1)
	5452		![](fig/fd/student_example_01)
5453	5453
5454	5454	As we can see, all the non-prime attributes are fully functionaly dependent from Login, which is our primary key.	As we can see, all the non-prime attributes are fully functionaly dependent from Login, which is our primary key.
5455	5455	But, obviously, one of this dependecy is transitive, and breaks the 3NF.	But, obviously, one of this dependecy is transitive, and breaks the 3NF.
5456	5456	A way to fix it is:	A way to fix it is:
5457	5457
5458		![](fig/fd/StudentExample2)
	5458		![](fig/fd/student_example_02)
5459	5459
5460	5460	As we can see, 3NF also helped us in separating properly the entities, in a slightly different way.	As we can see, 3NF also helped us in separating properly the entities, in a slightly different way.
5461	5461

...	...	Would it make sense to be have a total participation constraint on one side, and
5651	5651	Exercise +.#	Exercise +.#
5652	5652
5653	5653	: Express the constraints represented in the following diagram in plain English.	: Express the constraints represented in the following diagram in plain English.
5654		![](fig/er/CompOS)
	5654		![](fig/er/comp_os)
5655	5655
5656	5656	Exercise +.#	Exercise +.#
5657	5657

...	...	Exercise +.#
5726	5726	~	~
5727	5727	Convert the following ER diagram into a relational model:	Convert the following ER diagram into a relational model:
5728	5728
5729		![](fig/er/Stays_At)
	5729		![](fig/er/stays_at)
5730	5730
5731	5731	Exercise +.#	Exercise +.#
5732	5732

...	...	Exercise +.#
5877	5877	~	~
5878	5878	Consider the following diagram:	Consider the following diagram:
5879	5879
5880		![](fig/uml/flight)
	5880		![](fig/uml/flight_01)
5881	5881
5882	5882	Give the number of attributes for both classes, and suggest two operations for the class that does not have any. Discuss the multiplicities: why did the designer picked those values?	Give the number of attributes for both classes, and suggest two operations for the class that does not have any. Discuss the multiplicities: why did the designer picked those values?
5883	5883

...	...	Exercise +.#
5885	5885	~	~
5886	5886	Convert the following E.R. diagram to a U.M.L. class diagram.	Convert the following E.R. diagram to a U.M.L. class diagram.
5887	5887
5888		: ![](fig/er/Belongs)
	5888		: ![](fig/er/belongs)
5889	5889
5890	5890	Exercise +.#	Exercise +.#
5891	5891

...	...	Exercise +.#
5901	5901
5902	5902	Convert the following E.R. diagram into a U.M.L. class diagram:	Convert the following E.R. diagram into a U.M.L. class diagram:
5903	5903
5904		![](fig/er/Pilot)
	5904		![](fig/er/pilot)
5905	5905
5906	5906
5907	5907	## Solution to Exercises {-}	## Solution to Exercises {-}

...	...	To have statistics about the extensions, to sort the username by length, etc.
5917	5917
5918	5918	Solution +.#	Solution +.#
5919	5919
5920		: ![](fig/er/Computer)
	5920		: ![](fig/er/computer)
5921	5921
5922	5922	Solution +.#	Solution +.#
5923	5923
5924		: ![](fig/er/Cellphone)
	5924		: ![](fig/er/cell_phone)
5925	5925
5926	5926	Solution +.#	Solution +.#
5927	5927

...	...	Solution +.#
5929	5929
5930	5930	Solution +.#	Solution +.#
5931	5931
5932		: ![](fig/er/Printer)
	5932		: ![](fig/er/printer)
5933	5933
5934	5934	Solution +.#	Solution +.#
5935	5935

...	...	Solution +.#
5983	5983
5984	5984	Solution +.#	Solution +.#
5985	5985
5986		: ![](fig/er/Belongs)
	5986		: ![](fig/er/belongs)
5987	5987
5988	5988	Solution +.#	Solution +.#
5989	5989

...	...	Solution +.#
5992	5992
5993	5993	Solution +.#	Solution +.#
5994	5994
5995		: ![](fig/er/Example_of_Derived)
	5995		: ![](fig/er/example_of_derived)
5996	5996
5997	5997	Solution +.#	Solution +.#
5998	5998
5999		: ![](fig/er/Contains)
	5999		: ![](fig/er/contains)
6000	6000
6001	6001	Solution +.#	Solution +.#
6002	6002

...	...	Solution +.#
6009	6009
6010	6010	We could have the following:	We could have the following:
6011	6011
6012		![](fig/er/Produces)
	6012		![](fig/er/produces)
6013	6013
6014	6014	Solution +.#	Solution +.#
6015	6015	~	~
6016	6016
6017	6017	We could have the following:	We could have the following:
6018	6018
6019		![](fig/er/Membership)
	6019		![](fig/er/membership)
6020	6020
6021	6021	Solution +.#	Solution +.#
6022	6022

...	...	Solution +.#
6041	6041
6042	6042	A possible solution is:	A possible solution is:
6043	6043
6044		![](fig/er/Song)
	6044		![](fig/er/song)
6045	6045
6046	6046	Note that the two composite attributes are "generic", in the sense that you can re-use those examples easily.	Note that the two composite attributes are "generic", in the sense that you can re-use those examples easily.
6047	6047

...	...	Solution +.#
6055	6055	![	![
6056	6056	PERSON(SSN (PK), DOB, Stays_At (FK to PLACE.Address)	PERSON(SSN (PK), DOB, Stays_At (FK to PLACE.Address)
6057	6057	ADDRESS(Address (PK), Rooms)	ADDRESS(Address (PK), Rooms)
6058		](fig/rel_mod/PERSON)
	6058		](fig/rel_mod/person)
6059	6059	\	\
6060	6060
6061	6061	Note that "Stays_At" could also be a separate relation, with two attributes, "Address" and "Person", linked to respectively PLACE.Address and PERSON.SSN, and both being the primary key of the relation.	Note that "Stays_At" could also be a separate relation, with two attributes, "Address" and "Person", linked to respectively PLACE.Address and PERSON.SSN, and both being the primary key of the relation.

...	...	Problem (Reverse engineering by hand) +.#Reverse-Engineering-ACTOR
6293	6293
6294	6294	Look at the following relational model, and "reverse-engineer" it to obtain an E.R. diagram:	Look at the following relational model, and "reverse-engineer" it to obtain an E.R. diagram:
6295	6295
6296		![](fig/rel_mod/ACTOR)
	6296		![](fig/rel_mod/actor)
6297	6297
6298	6298	---	---
6299	6299

...	...	Problem (From E.R. diagram to Relational model -- BIKE) +.#ERtoRELBike
6330	6330
6331	6331	Consider the following E.R. diagram:	Consider the following E.R. diagram:
6332	6332
6333		![](fig/er/Bike)
	6333		![](fig/er/bike)
6334	6334	\	\
6335	6335
6336	6336	_Based on this diagram_, answer the following: "Is it true that …"	_Based on this diagram_, answer the following: "Is it true that …"

...	...	Problem (From E.R. diagram to Relational model -- RECORD) +.#ERtoRELRecord
6356	6356
6357	6357	Consider the following E.R. diagram:	Consider the following E.R. diagram:
6358	6358
6359		![](fig/er/Record)
	6359		![](fig/er/record)
6360	6360	\	\
6361	6361
6362	6362	_Based on this diagram_, is it true that …	_Based on this diagram_, is it true that …

...	...	Problem (ER-to-Relation mapping for Country) +.#ERtoRELCountry
6382	6382
6383	6383	Consider the following E.R. schema:	Consider the following E.R. schema:
6384	6384
6385		![](fig/er/Country)
	6385		![](fig/er/country)
6386	6386	\	\
6387	6387
6388	6388	where	where

...	...	Problem (PRINT relation in third normal form) +.#print
6657	6657
6658	6658	Normalize the following relation to the third normal form.	Normalize the following relation to the third normal form.
6659	6659
6660		![](fig/fd/Print){width=90%}
	6660		![](fig/fd/print){width=90%}
6661	6661
6662	6662	Do not forget to indicate all the primary keys in your relations.	Do not forget to indicate all the primary keys in your relations.
6663	6663

...	...	Problem (From E.R. to relational schema and UML class diagram -- CAR\_INFO) +.#c
6732	6732
6733	6733	Consider the following E.R. schema for the CAR\_INFO database:	Consider the following E.R. schema for the CAR\_INFO database:
6734	6734
6735		![](fig/er/car_Info)
	6735		![](fig/er/car_info)
6736	6736
6737	6737	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").
6738	6738

...	...	Solution to [%D %n (%T)](#problem:car-insurance)
6833	6833
6834	6834	and	and
6835	6835
6836		![](fig/er/Accident)
	6836		![](fig/er/accident)
6837	6837	\	\
6838	6838
6839	6839	---	---

...	...	Solution to [%D %n (%T)](#problem:job-offers)
6843	6843
6844	6844	A possible solution is:	A possible solution is:
6845	6845
6846		![](fig/er/Job)
	6846		![](fig/er/job)
6847	6847	\	\
6848	6848
6849	6849	Note that CONTACT could be a weak entity, with the identifying relationship being either DISCUSSED_BY or EMPLOYS, but both have disadvantages, since they would disallow a CONTACT to discuss more than one offer, or to be hired by more than one company.	Note that CONTACT could be a weak entity, with the identifying relationship being either DISCUSSED_BY or EMPLOYS, but both have disadvantages, since they would disallow a CONTACT to discuss more than one offer, or to be hired by more than one company.

...	...	Solution to [%D %n (%T)](#problem:ERtoRELBike)
6869	6869	For the $1:M$ relationships that are not identifying, we can chose between the foreign key and the cross-reference approaches.	For the $1:M$ relationships that are not identifying, we can chose between the foreign key and the cross-reference approaches.
6870	6870	If we use the former, we obtain:	If we use the former, we obtain:
6871	6871
6872		![](fig/rel_mod/BIKE_FK)
	6872		![](fig/rel_mod/bike_fk)
6873	6873
6874	6874	We could also have used a combination of both!	We could also have used a combination of both!
6875	6875

...	...	SHOP(Name (PK), StreetName, Citiy, Zip)
6902	6902	LABEL(Name (PK), Phone, LogoName, LogoColor)	LABEL(Name (PK), Phone, LogoName, LogoColor)
6903	6903	SELL(Recording (FK, PK to RECORDING.Title), Shop (PK, FK to SHOP.Name), NumberOfCopies)	SELL(Recording (FK, PK to RECORDING.Title), Shop (PK, FK to SHOP.Name), NumberOfCopies)
6904	6904	LABELGENRE(Label (PK, FK to LABEL.Name), Genre (PK))	LABELGENRE(Label (PK, FK to LABEL.Name), Genre (PK))
6905		](fig/rel_mod/RECORD)\
	6905		](fig/rel_mod/record)\
6906	6906
6907	6907	---	---
6908	6908

...	...	Solution to [%D %n (%T)](#problem:schedule)
6968	6968
6969	6969	Once normalized to the third normal form, we get:	Once normalized to the third normal form, we get:
6970	6970
6971		![](fig/fd/Schedule){width=90%}
	6971		![](fig/fd/schedule){width=90%}
6972	6972
6973	6973
6974	6974	---	---

...	...	Solution to [%D %n (%T)](#problem:carinfo)
7123	7123	PERSON(ID (PK), Name, Street, City, Seat (FK to CAR.Vin), Position)	PERSON(ID (PK), Name, Street, City, Seat (FK to CAR.Vin), Position)
7124	7124	CAR(Vin (PK), Make, Year, Brand, Driver (FK to PERSON.ID))	CAR(Vin (PK), Make, Year, Brand, Driver (FK to PERSON.ID))
7125	7125	CAR INSURANCE(Insured Car (PK, FK to CAR.Vin), Policy Number (PK), Covered Amount, Company Name)	CAR INSURANCE(Insured Car (PK, FK to CAR.Vin), Policy Number (PK), Covered Amount, Company Name)
7126		](fig/rel_mod/CAR_INFO)
	7126		](fig/rel_mod/car_info)
7127	7127	\	\
7128	7128
7129	7129	Note that, during the coversion, we had to make "Insured Car" part of the primary key of CAR INSURANCE.	Note that, during the coversion, we had to make "Insured Car" part of the primary key of CAR INSURANCE.

...	...	Solution to [%D %n (%T)](#problem:library_network)
7137	7137
7138	7138	For the ER diagram, we could get something like:	For the ER diagram, we could get something like:
7139	7139
7140		![](fig/er/Library)
	7140		![](fig/er/library)
7141	7141
7142	7142	Note that:	Note that:
7143	7143

...	...	Solution to [%D %n (%T)](#problem:library_network)
7157	7157	BORROWING(Copy (PK, FK to COPY.Code), Patron (PK, FK to PATRON.CardNumber), ReturnDate)	BORROWING(Copy (PK, FK to COPY.Code), Patron (PK, FK to PATRON.CardNumber), ReturnDate)
7158	7158	PATRON(CardNumber (PK), Name, Email)	PATRON(CardNumber (PK), Name, Email)
7159	7159	HOLD(Copy (PK, FK to COPY.Code), Patron (PK, FK to PATRON.CardNumber), ExpirationDate)	HOLD(Copy (PK, FK to COPY.Code), Patron (PK, FK to PATRON.CardNumber), ExpirationDate)
7160		](fig/rel_mod/NETWORK_LIBRARY)
	7160		](fig/rel_mod/network_library)
7161	7161	\	\
7162	7162
7163	7163	Note that:	Note that:

...	...	Solution to [%D %n (%T)](#problem:xmltoercustomer)
8635	8635
8636	8636	Put together, this gives the following diagram:	Put together, this gives the following diagram:
8637	8637
8638		![](fig/er/Customers)
	8638		![](fig/er/customers)
8639	8639	\	\
8640	8640
8641	8641	We made further assumptions: an order cannot be empty (transcribed by the total constraint on CONTAINS), an order does not exist if it was not passed by a customer (transcribed by the fact that ORDER is a weak entity), which also implies that an order cannot be passed by more than one customer.	We made further assumptions: an order cannot be empty (transcribed by the total constraint on CONTAINS), an order does not exist if it was not passed by a customer (transcribed by the fact that ORDER is a weak entity), which also implies that an order cannot be passed by more than one customer.

...	...	Solution to [%D %n (%T)](#problem:xmltoeraward)
8669	8669
8670	8670	All together, this gives the following diagram:	All together, this gives the following diagram:
8671	8671
8672		![](fig/er/Award)
	8672		![](fig/er/award)
8673	8673	\	\
8674	8674
8675	8675

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