Converting ER-Diagrams to Table Definitions

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.

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

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

Student id name address name address student id

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

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

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

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

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

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

Translating relationships (key constraints): Option 1 id 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);

Translating relationships (key constraints): Option 2 id 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

Translating relationships (key constraints): Option 2 id 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?

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

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?

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

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

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(...)

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(...)

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

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

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

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