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 |
|
|