1. Converting ER-Diagrams to Table Definitions

2. General Principals
When converting ER diagrams to Relations, we should try to:
Reduce duplicate information
Constrain as tightly as possible
Note:
Some scenarios can be represented in different ways.
Sometimes we will not be able to fully represent constraints, or will be forced to represent information more than once.

3. Relations vs. Tables
We show how to translate ER-Diagrams to table definitions
Sometimes, people translate ER-Diagrams to relation definition, which is more abstract than table definitions.
e.g., Employee(SSN, Fname, Lname, Gender, Salary, Dept);
table definitions contain, in addition, constraints and datatypes

4. Simple entity translation
birthday id
Actor
name
address
General Rule:
Create a table with the name of the Entity.
There is a column for each attribute
The key in the diagram is the primary key of the table

5. Student id
name
address
name
address
student id

6. Simple entity translation
birthday id
Actor
name
address
Relation: Actor (id, name, birthday, address)
create table Actor(id varchar2(20) primary key,
name varchar2(40),
birthday date,
address varchar2(100));

7. Translating Entities with Relationships (without constraints)
birthday
title id
Actor
Film
Acted In
year
name
salary
address
type
Create tables for the entities as before
Create a table with the name of the relationship
Relationship table attributes: its own attributes (salary) + all keys of the relating entities (title, id).
Q: What is the primary key of the table?
A: A composite of both entity keys
Q: What foreign keys are needed?
A: From the relationship table to the entities

8. How would we represent this diagram in tables?
תאריך
שם קורס שם
מס' זהות
סטודנט
נבחן
קורס
מס' קורס
בחינה
מס' בחינה

9. Answer קורס בחינה סטודנט נבחן מס' קורס שם קורס מס' בחינה מס' זהות שם
תאריך

10. Translating Recursive Relationships (without constraints)
manager id
Employee
Manages
worker
name
address
Relation: Manages (Wid, Mid)
What would be the table definition?
create table Manages(
Eid varchar2(20), Mid varchar2(20),
Foreign key Eid references Employee(id),
Foreign key Mid references Employee(id),
Primary key(Eid, Mid));
If we want to make sure an employee is not his own manager we can express it with Check

11. Translating relationships (key constraints): Option 1id
Director
Film
Directed
title
name
salary
year
Option 1:
Same as without key constraints (3 tables), except that the relationship primary key is…?
title.

12. Translating relationships (key constraints): Option 1id
Director
Film
Directed
title
name
salary
year
create table Directed(
id varchar2(20),
title varchar2(40),
salary integer,
primary key (title),
foreign key id references Director,
foreign key title references Film);

13. Translating relationships (key constraints): Option 2id
Director
Film
Directed
title
name
salary
year
Option 2:
Do not create a table for the relationship
Add information columns that would have been in the relationship's table to the table of the entity with the key constraint

14. Translating relationships (key constraints): Option 2id
Director
Film
Directed
title
name
salary
year
create table Film(
title varchar2(40),
year integer,
primary key (title),
id varchar2(20),
salary integer,
foreign key(id) references Director);
Why couldn’t we do this when there were no constraints?

15. Translating relationships (participation constraints)id
Director
Film
Directed
title
name
salary
year
General Rule:
If both participation and key constraint exist, use Option 2 from before (only 2 tables), and:
Add the not null constraint on the referncing attribute to ensure that there will always be values for the key of the other entity

16. Translating relationships (participation constraints)id
Director
Film
Directed
title
name
salary
year
create table Film(
title varchar2(40),
year integer,
id varchar2(20),
salary integer,
foreign key (id) references Director,
primary key (title));
Where should we add NOT NULL?

17. Translating relationships (participation constraints)id
Actor
Film
Acted In
title
name
salary
year
How would we translate this?

18. Translating Weak Entity Sets
A regular table for Organization, and..
phone
number
name
create table award(
name varchar2(40),
year integer,
money number(6,2),
o_name varchar2(40),
primary key(name, year, o_name),
foreign key (o_name) references Organization(name)
on delete cascade )
Organization
Gives
Award
money
year
name

19. Translating ISA: Option 1
address
Translating ISA: Option 1 id
Movie Person
name
ISA
picture
Actor
Director
create table MoviePerson( ... )
create table Actor(id varchar2(20),
picture bfile,
primary key(id),
foreign key (id) references MoviePerson))
create table Director(...)

20. Translating ISA: Option 2
address
Translating ISA: Option 2 id
Movie Person
name
ISA
picture
Actor
Director
No table for MoviePerson!
create table Actor(id varchar2(20),
address varchar2(100),
name varchar2(20),
picture blob,
primary key(id));
create table Director(...)

21. Which Option To Choose?
We use option 2 only if the lower-level entity sets (Actor and Director):
Cover the high-level entity set
Are disjoint

22. Translating Aggregation
phone
number
Oname
Translating Aggregation
Organization
picture
Director ID
Gives
salary
Acted In
Won
year
Award
Film
Broad-
casted
year
name
title
type
Won(title, year, name, Oname, Broadcasted);

23. Summary Tables Primary key Remarks Simple Entity Single table
The entity key
a column for each attr.
Simple Relationship
3 (2 entities +relationship)
For the relation: Both entity keys
Foreign keys from rel. Table
Key constraint
3 as before or
2 (one for each entity)
Key of constrained ent.
Foreign key from constr. Entity
Key and Participation constr. 2
Regular
Constrained entity has a non-null f. key

24. Tables
Primary key
Remarks
Weak Entity
2: parent and weak entities
Weak: its own and parent keys
Foreign keys from weak ent.
ISA: covers and disjoint
2: only child entities
Parent key
ISA: otherwise
3: parent and child entities
Foreign keys from child ent.
Aggregation
3: 2 aggregates and relationship
For relationship: keys of both aggregates
Foreign keys from relationship table