Scribd
Upload
27 views4 pages

An Example of A Foreign Key Constraint Involving The Dept Relation Is The Managerid Attribute in The Dept Relation

Uploaded by

Felix Amable
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
27 views4 pages

An Example of A Foreign Key Constraint Involving The Dept Relation Is The Managerid Attribute in The Dept Relation

Uploaded by

Felix Amable
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 4

An example of a foreign key constraint involving the Dept relation is the managerid attribute in the

Dept relation, which references the eid attribute in the professor relation. When a user attempts to
delete a Dept tuple, the options for enforcing this constraint include: preventing the deletion of the
Dept tuple if there are still professors with the same managerid, cascading the deletion of all
professors with the same managerid as the Dept tuple, setting the managerid attribute to null for all
professors with the same managerid as the Dept tuple, or setting the managerid attribute to a
default value for all professors with the same managerid as the Dept tuple.

SQL statements to create the above relations with appropriate primary and foreign key constraints:

sql

Copy code

CREATE TABLE professor (

eid INTEGER PRIMARY KEY,

ename VARCHAR(255) NOT NULL,

age INTEGER,

salary REAL

);

CREATE TABLE Dept (

did INTEGER PRIMARY KEY,

dname VARCHAR(255) NOT NULL,

budget REAL,

managerid INTEGER,

FOREIGN KEY (managerid) REFERENCES professor(eid)

);

CREATE TABLE Course (

eid INTEGER,

did INTEGER,

pct_time INTEGER,

PRIMARY KEY (eid, did),

FOREIGN KEY (eid) REFERENCES professor(eid),


FOREIGN KEY (did) REFERENCES Dept(did)

);

To define the Dept relation in SQL so that every department is guaranteed to have a manager, we
can modify the definition of the Dept table to include a NOT NULL constraint on the managerid
attribute:

sql

Copy code

CREATE TABLE Dept (

did INTEGER PRIMARY KEY,

dname VARCHAR(255) NOT NULL,

budget REAL,

managerid INTEGER NOT NULL,

FOREIGN KEY (managerid) REFERENCES professor(eid)

);

SQL statement to add 'Emmanuel Kuseamo' as an employee with eid = 101, age = 32, and salary =
20000:

sql

Copy code

INSERT INTO professor (eid, ename, age, salary)

VALUES (101, 'Emmanuel Kuseamo', 32, 20000);

SQL statement to give every employee a 40% raise:

sql

Copy code

UPDATE professor SET salary = salary * 1.4;

SQL statement to delete the 'Toy' department:

sql

Copy code

DELETE FROM Dept WHERE dname = 'Toy';

If the referential integrity constraint was set to prevent deletion of a Dept tuple if there are still
professors with the same managerid, the deletion of the 'Toy' department will fail if there are still
professors with managerid referencing the 'Toy' department. If the constraint was set to cascade the
deletion of all professors with the same managerid as the Dept tuple, then all professors with
managerid referencing the 'Toy' department will also be deleted. If the constraint was set to set the
managerid attribute to null or a default value for all professors with the same managerid as the Dept
tuple, then the affected professors will have their managerid attribute updated accordingly.

S2

An example of a foreign key constraint that involves the Dept relation is the managerid attribute in
the Dept relation, which references the eid attribute in the professor relation. When a user attempts
to delete a Dept tuple, the options for enforcing this constraint are either to disallow the deletion if
there are professor tuples referencing the department or to cascade the deletion by deleting all
professor tuples referencing the department.

Here are the SQL statements required to create the above relations with appropriate versions of all
primary and foreign key integrity constraints:

CREATE TABLE professor (

eid INTEGER PRIMARY KEY,

ename VARCHAR(50),

age INTEGER,

salary REAL

);

CREATE TABLE Dept (

did INTEGER PRIMARY KEY,

dname VARCHAR(50),

budget REAL,

managerid INTEGER,

FOREIGN KEY (managerid) REFERENCES professor(eid)

);

CREATE TABLE Course (

eid INTEGER REFERENCES professor(eid),

did INTEGER REFERENCES Dept(did),

pct_time INTEGER,
PRIMARY KEY (eid, did)

);

To define the Dept relation in SQL so that every department is guaranteed to have a manager, you
can add a NOT NULL constraint to the managerid attribute:

CREATE TABLE Dept (

did INTEGER PRIMARY KEY,

dname VARCHAR(50),

budget REAL,

managerid INTEGER NOT NULL,

FOREIGN KEY (managerid) REFERENCES professor(eid)

);

The SQL statement to add ‘Emmanueal Kuseamo’ as an employee with eid = 101, age = 32 and salary
= 20,000 would be:

INSERT INTO professor (eid, ename, age, salary) VALUES (101, 'Emmanueal Kuseamo', 32, 20000);

The SQL statement to give every employee a 40% raise would be:

UPDATE professor SET salary = salary * 1.4;

The SQL statement to delete the ‘Toy’ department would be:

DELETE FROM Dept WHERE dname = 'Toy';

Given the referential integrity constraints I chose for this schema, when this statement is executed,
it will not be allowed if there are any Course tuples referencing the 'Toy' department. If there are no
such tuples, the deletion will be allowed and any professor tuples with a managerid of the deleted
department will have their managerid set to NULL.

You might also like