## Lecture 1 (13:00)

### Candidate Key

- Attribute / Set of attributes that are:
	- Irreducible
	- A **Unique ID** for the rows in the table
- If every attribute in the key is required to uniquely identify every row in the relation, it **is irreducible**.
- If there is a subset of this set that uniquely identifies every row in the table, it **is reducible**.
- **Primary Key** is the candidate key chosen to be the identifier.

#### Primary Key

- Many attributes may be required to form.

### Transforming ER to Relational

- Each entity transforms into a table with same attributes and primary key.
- Each relationship transforms into either:
	- A foreign key in existing table.
	- New table, linked by foreign keys.
- Constraints transform into attribute constraints or table constraints.

#### Transforming ER Model into Tables

![](Pasted%20image%2020231024131832.png)

#### Representing a Relationship Using Foreign Key

![](Pasted%20image%2020231024131915.png)

### Principles of Choosing Foreign Keys

- Should not be null
- Should not have multiple values
- Keep it simple
- Ex.
![](Pasted%20image%2020231024132127.png)
- All Many to Many relationships are transformed the same way.

### \[1:1] \[o:m] Relationships

![](Pasted%20image%2020231024132309.png)

- Since a professor does not have to have a department, we should not add `dep#` as a foreign key to the professors table, as values may be null.
- As a department must have exclusively one professor, the logical choice is to add `p#` as the foreign key in the departments table.

### \[1:1] \[o:o] Relationships

![](Pasted%20image%2020231024132524.png)

- As neither table can fulfil its purpose as a foreign key, we cannot add either relation to either table, as it would break the principles of foreign keys.
- Instead we should create a third table, containing both primary keys, as seen below.
![](Pasted%20image%2020231024132759.png)
- The primary key for this table may be `p#`, `dep#`, but never both.
- There will never be more than one professor to one department, as seen by the lack of crows foot in the diagram.

### \[1:1] \[m:m] Relationships

![](Pasted%20image%2020231024133014.png)

- Since there must be 1 professor to 1 department, there would never be a null value, and never have multiple values in the foreign key. This way we can add either primary key as the foreign key in the other table.
- If we know the query types that would be most common, we can choose the foreign key that would be most applicable.

### Exercise 1

A person must have exactly one birth certificate.
Each birth certificate is for just for one person.

\[Person] -|---|- \[Certificate]

- This is a \[1:1] \[m:m] relationship, meaning we can have either primary key as the foreign key in the other table.

#### Answer

![](Pasted%20image%2020231024133449.png)

### Exercise 2

Each birth certificate is for just for one person.
A person may have a birth certificate, or may have lost it!

\[Person] -o---|- \[Certificate]

- This is a \[1:1] \[o:m] relationship. The person table primary key should be the foreign key in the certificate table.

#### Answer

![](Pasted%20image%2020231024133750.png)

### \[M:1] \[m:o] Relationships

![](Pasted%20image%2020231024134155.png)

- A team can include none, one or many junior doctors, but a junior cannot be part of multiple teams.
- Each junior is in exactly one team, so adding the team primary key to the juniors table is the most acceptable in this scenario.

### \[M:1] \[o:o] Relationships

![](Pasted%20image%2020231024134452.png)

- Since in this example, a junior may not be in a team, we must have to make a third table, since any solution would lead to multiple or null values, which would violate foreign key principles.

### Exercise 3

#### Part 1

A person must own one or more cars.
A car must have exactly one owner.

\[Person] \-|---|-/\\ \[Car]

- This is a \[1:M] \[m:m] Relationship
- person(person#, name…)
- car(car#, …, person#\*)
- The person candidate key would be the foreign key in the car table.

#### Part 2

A person may own none, one or more cars.
A car must have exactly one owner.

\[Person] -o---|-/\\ \[Car]

- This is a \[1:M] \[o:m] Relationship
- person(person#, name, …)
- car(car#, …, person#\*)

## Lecture 2 (15:00)

### Many to Many Relationships

![](Pasted%20image%2020231024150834.png)

- Since we cannot have either primary key be a foreign key, as we would have multiple values, we would have to make a composite 3rd table.
![](Pasted%20image%2020231024151000.png)

### Transforming Complex ER Diagrams

![](Pasted%20image%2020231024151321.png)

### Flow Chart

![](Pasted%20image%2020231024152031.png)

## Tutorial 1 (15:00)

### Exercise 1

#### Part 1

Project -o---|-/\\- Order
\[1:M] \[o:m] Relationship

project(proj#, name, start-date, end-date)
order(order#, date, inquiry, proj#\*)

#### Part 2

Supplier -/\\-o---o-/\\- Part
\[M:M] \[o:o] Relationship

supplier(supplier#, name, tel-no)
part(part#, name, price)
orderList(supplier#\*, part#\*)

- We must create a new composite table to contain the relation, since we cannot sustain the principles of foreign keys.

#### Part 3

Staff -/\\-|---|- Department
\[M:1] \[m:m] Relationship

staff(staff-id, name, address, phone-no, dept-id*)
department(dept-id, name, location)

- We would create dept-id as a foreign key in the staff table, as multiple values wont occur, and staff must be a part of a department in this scenario.

#### Part 4

Manager -|---|- Project
\[1:1] \[m:m] Relationship

manager(man-id, name, address, tel-no, proj-id*)
project(proj-id, name, start-date, end-date)

- We could use either primary key for the alternate table's foreign key, since they are both mandatory and 1:1, so there would be no multiple values nor would there be null values.

#### Part 5

Manager -|---|-/\\- Team -|---|-/\\- Player
\[1:M] \[m:m] (Both) Relationship

manager(man-id, name, address, tel-no)
team(team-name, date-founded, address, man-id*)
player(player-id, name, address, tel-no, team-name*)

## Tutorial 2 (14:00)

#### Entities & Attributes

| Entities | Attributes |
|----------|------------|
| Regional Office | *regioncode*, name, location |
| Branch | *branch_no*, institution |
| Member | *mem_no*, name, age, type |
| Role | *role_id*, level, role |

#### Relations

Role - \[1:M]\[m:o] - Member
Member - \[M:1]\[o:m] - Branch
Branch - \[M:1]\[m:m] - Region