UNIT – II

 INTRODUCTION TO THE RELATIONAL MODEL

• The main construct for representing data in the relational model is

a relation.
• Relation: A relation consists of a relation schema and a relation
instance.
• Relation instance: The relation instance is a table, and the relation
schema describes the column heads for the table.
• Relation schema: The schema specifies the relation's name, the
name of each field (or column, or attribute), and the domain of
each field.
• Domain: A domain is referred to in a relation schema by the
domain name and has a set of associated values.
sid name Login
• Domain constraints the set of rules which defines what kind of attributes can
be stored in an entity, therefore, relation instance means instance that satisfies
the domain constraints in the relation schema.
• Degree: The degree, also called arity
(The number of arguments or operands taken by a function or operator), of a
relation is the number of fields. (parameters)
• Cardinality : The cardinality of a relation instance is the number of tuples in it.
In Figure 3.1, the degree of the relation (the number of columns) is five, and
the cardinality of this instance is six.
• Relational database : A relational database is a collection of relations with
distinct relation names.
• Relational database schema : The relational database schema is the collection
of schemas for the relations in the database.
 Data Definition Language (DDL)
• Data Definition Language (DDL) statements are used to define the
database structure or schema.
• Data Definition Language understanding with database schemas and
describes how the data should consist in the database. DDL is about
"metadata".
• The result of compilation of Data Definition Language statements is a
set of tables that is stored in a special file called Data Dictionary or
Data Directory
• A Data Dictionary is a file that contains metadata(data about data).
This file is consulted before actual data is read or modified in the
database.
DDL includes commands such as CREATE, ALTER and
DROP statements.
DDL Commands:
1. CREATE - to create objects in the database
2. ALTER - alters the structure of the database
3. DROP - delete objects from the database
4. TRUNCATE - remove all records from a table, including
all spaces allocated for the records are removed
5. COMMENT - add comments to the data dictionary
6. RENAME - rename an object
DML Commands:

1.INSERT : It inserts data in a database.

2.SELECT : It retrieves data from a table.
3.UPDATE : It updates existing data within a table.
4.DELETE : It deletes all records from a table, the space
for the records remain.
 Creating and Modifying Relations Using SQL

-The SQL Language uses the word table to denote relation.

-The subset of SQL that supports the creation , deletion and modification
of tables is called DDL.
-The CREATE TABLE statement is used to define a new table.
-To create the Students relation, we can use the following statement:
CREATE TABLE Students ( sid CHAR(20) ,
name CHAR(30) ,
Login CHAR(20) ,
Age INTEGER,
Gpa REAL);
• Tuples are inserted ,using the INSERT command.
• We can insert a single tuple into the Students table as follows:

INSERT
INTO Students (sid, name, login, age, gpa)
VALUES (53688, 'Smith', 'smith@ee', 18, 3.2);
Or
INSERT INTO table-name VALUES (“val1”, val2, val3,…, “valK”);

We can delete tuples using the DELETE command.

We can delete all Students tuples with name equal to Smith using the command:
DELETE
FROM Students S
WHERE S.name = 'Smith'
• We can modify the column values in an existing row using the
UPDATE command.
• For example, we can increment the age and decrement the gpa of
the student with sid 53688:
UPDATE Students S
SET S.age = S.age + 1, S.gpa = S.gpa - 1
WHERE S.sid = 53688
(or)
UPDATE Students S
SET S.gpa = S.gpa - 0.1
WHERE S.gpa >= 3.3
  INTEGRITY CONSTRAINTS OVER RELATIONS
• An integrity constraint (IC) is a condition specified on a database
schema and restricts the data that can be stored in an instance of the
database.
• If a database instance satisfies all the integrity constraints specified
on the database schema, it is a legal instance.
• A DBMS enforces integrity constraints, in that it permits only legal
instances to be stored in the database.
• Integrity constraints are specified and enforced at different times:
1. When the DBA or end user defines a database schema, he or she
specifies the ICs that must hold on any instance of this database.
2. When a database application is run, the DBMS checks for violations
and disallows changes to the data that violate the specified ICs.
WHAT ARE DBMS KEYS ? WHY WE NEED THEM ? WHAT ARE DIFFERENT TYPES OF KEYS ?
Here, If I need to find out the email address of a student named “Adam “ . It’s not possible because we
have 2 Adams. OR If you need to find out student of C.S branch, again there will be many students of
C.S branch
We can choose any one of these as a
candidate key
ALTERNATE KEY :
This way while making a new student entry a wrong branch name cannot be
entered
 Specifying candidate Key Constraints in SQL
• In SQL, we can declare that a subset of the columns of a table
constitute a key by using the UNIQUE constraint.
• example table
CREATE TABLE Students ( sid CHAR(20) ,
name CHAR (30) ,
login CHAR(20) ,
age INTEGER,
gpa REAL,
Unique(sid),UNIQUE (name, age))
 Specifying Primary Key Constraints in SQL
• One of the candidate key which has no Null values is selected as
Primary Key.
• example table
CREATE TABLE Students ( sid CHAR(20) ,
name CHAR (30) ,
login CHAR(20) ,
age INTEGER,
gpa REAL,
constraint studentkey primary key (sid));
• we can name a constraint by preceding it with CONSTRAINT constraint-name. If the
constraint is violated, the constraint name is returned and can be used to identify the error.
 Foreign Key Constraints
• Sometimes the information stored in a relation is linked to the
information stored in another relation.
• If one of the relations is modified, the other must be checked, and
perhaps modified, to keep the data consistent.
• An IC involving both relations must be specified if a DBMS is to
make such checks.
• The most common IC involving two relations is a foreign key
constraint.
• Suppose that, in addition to Students, we have a second relation:

Enrolled(studid: string, cid: string, grade: string)

• To ensure that only bonafide students can enroll in courses, any
value that appears in the studid field of an instance of the Enrolled
relation should also appear in the sid field of some tuple in the
Students relation.
• The st'udid field of Enrolled is called a foreign key and refers to
Students.
• The foreign key in the referencing relation must match the primary
key of the referenced relation that is it must have the same
compatible data types, although the column names can be
different.
 Specifying Foreign Key Constraints in SQL

Let us define Enrolled(studid: string, cid: string, grade: string):

CREATE TABLE Enrolled ( studid CHAR(20) ,

cid CHAR(20),
grade CHAR(10),
PRIMARY KEY (studid, cid),
FOREIGN KEY (studid) REFERENCES
Students(sid));
 General Constraints
• Domain, primary key, and foreign key constraints are considered to be a
fundamental part of the relational data model and are given special attention in
most commercial systems.
• Sometimes, however, it is necessary to specify more general constraints.
• For example, we may require that student ages be within a certain range of
values; given such an IC specification, the DBMS rejects inserts and updates
that violate the constraint.
• This is very useful in preventing data entry errors.
• Current relational database systems support such general constraints in the form
of table constraints and assertions.
• Table constraints are associated with a single table and checked whenever that
table is modified.
• In contrast, assertions involve several tables and are checked whenever any of
these tables is modified.
SQL Constraints
• SQL constraints are used to specify rules for the data in a table.
• Constraints are used to limit the type of data that can go into a table.
This ensures the accuracy and reliability of the data in the table. If
there is any violation between the constraint and the data action, the
action is aborted.
• Constraints can be column level or table level. Column level
constraints apply to a column, and table level constraints apply to the
whole table.
The following constraints are commonly used in SQL:
•NOT NULL - Ensures that a column cannot have a NULL value
•UNIQUE - Ensures that all values in a column are different
•PRIMARY KEY - A combination of a NOT NULL and UNIQUE. Uniquely identifies
each row in a table
•FOREIGN KEY - Prevents actions that would destroy links between tables
•CHECK - Ensures that the values in a column satisfies a specific condition
•DEFAULT - Sets a default value for a column if no value is specified
•CREATE INDEX - Used to create and retrieve data from the database very
quickly

•Example Query :
• create table employee(sno int(3), empno varchar(5) primary key, empname
char(10) unique, branch char(5), salary INT(10) not null, designation
varchar(20), place char(10) default ‘Hyderabad’, age varchar(2) check (age
>=18));
  ENFORCING INTEGRITY CONSTRAINTS
• ICs are specified when a relation is created and enforced when a
relation is modified.
• The impact of domain, PRIMARY KEY, and UNIQUE
constraints is straightforward:
• If an insert, delete, or update command causes a violation, it is
rejected.
• Every potential IC violation is generally checked at the end of
each SQL statement execution, although it can be deferred until
the end of the transaction executing the statement.
• PRIMARY KEY CONSTRAINTS:
• The following insertion violates the primary key constraint because there is already a tuple
with the sid 53688, and it will be rejected by the DBMS:
INSERT
INTO Students (sid, name, login, age, gpa)
VALUES (53688, 'Mike', 'mike@ee', 17,3.4);
• The following insertion violates the constraint that the primary key cannot contain null:
INSERT
INTO Students (sid, name, login, age, gpa)
VALUES (null, 'Mike', 'mike@ee', 17,3.4);
• UPDATE Students S
SET S.sid = 50000

WHERE S.sid = 53688

• This update violates the primary key constraint because there is already a tuple with sid
50000.
Integrity Rule 1 (Entity Integrity Rule or Constraint)
➢ The Integrity Rule 1 is also called Entity Integrity Rule or
Constraint.
➢ This rule states that no attribute of primary key will contain a null
value.
➢ If a relation have a null value in the primary key attribute, then
uniqueness property of the primary key cannot be maintained.
➢ Consider the example below-
DOMAIN COMSTRAINTS:
• Of course, a similar problem arises whenever we try to insert a tuple with a value in a
field that is not in the domain associated with that field, that is, whenever we violate a
domain constraint.
• Deletion does not cause a violation of domain, primary key or unique constraints.
• However, an update can cause violations, similar to an insertion:
• Domain Constraints specifies that what set of values an attribute can take.
• Value of each attribute X must be an atomic value from the domain of X.
• The data type associated with domains include integer, character, string, date, time,
currency etc.
• An attribute value must be available in the corresponding domain.
• Consider the example below –
Difference between Primary Key and
Unique Key
• Examples of Candidate Key/Primary Key
Constraint Checking
 CANDIDATE KEY CONSTRAINT:

create table student(sid int(4),sname varchar(10), marks int(4), unique(sid));

• Query OK, 0 rows affected (0.03 sec)

• insert into student values(1,'abc',60);

Query OK, 1 row affected (0.02 sec)

• insert into student values(2,'abc',60);

Query OK, 1 row affected (0.02 sec)

insert into student values(1,'pqr',80);

• ERROR 1062 (23000): Duplicate entry '1' for key 'sid'
create table student1(sid int(4),sname varchar(10), marks int(4), unique(sid,sname));
Query OK, 0 rows affected (0.06 sec)

mysql> insert into student1 values(1,'pqr',80);

• Query OK, 1 row affected (0.01 sec)

• mysql> insert into student1 values(1,'pqr',80);

• ERROR 1062 (23000): Duplicate entry '1-pqr' for key 'sid’

• mysql> insert into student1 values(1,'lmn',80);

• Query OK, 1 row affected (0.02 sec)

• mysql> insert into student1 values(2,'pqr',80);

• Query OK, 1 row affected (0.03 sec)
• mysql> create table student3(sid int(4),sname varchar(10), smarks int(4), unique(sid),unique(sname,smarks));
• Query OK, 0 rows affected (0.03 sec)

• mysql> insert into student3 values(1,'pqr',80);

• Query OK, 1 row affected (0.01 sec)

• mysql> insert into student3 values(1,'lmn',80);

• ERROR 1062 (23000): Duplicate entry '1' for key 'sid’

• mysql> insert into student3 values(2,'xyz',90);

• Query OK, 1 row affected (0.03 sec)

• mysql> insert into student3 values(3,'xyz',90);

• ERROR 1062 (23000): Duplicate entry 'xyz-90' for key 'sname’

• mysql> insert into student3 values(3,'xyz',100);

• Query OK, 1 row affected (0.05 sec)

• mysql> insert into student3 values(4,’aaa’,80);

• Query OK, 1 row affected (0.02 sec)
• PRIMARY KEY CONSTRAINT:

• mysql> create table student5(sid int(10), name varchar(10), age int(3), primary key(sid));
• Query OK, 0 rows affected (0.03 sec)

• mysql> insert into student5 values(1,'abc',23);

• Query OK, 1 row affected (0.03 sec)

• mysql> insert into student5 values(1,'pqr',23);

• ERROR 1062 (23000): Duplicate entry '1' for key 'PRIMARY’

• mysql> insert into student5 values(2,'abc',23);

• Query OK, 1 row affected (0.03 sec)

• mysql> insert into student5 values(null,'xyz',25);

• ERROR 1048 (23000): Column 'sid' cannot be null
 • FOREIGN KEY CONSTRAINTS
• It is an attribute or set of attributes that references to primary key of
same table or other table(relation)
• It maintains referential Integrity
Primary Key Foreign Key

Roll_no Name Address Course_ID C_name Roll_No

1 A HYD C1 DBMS 1
2 B Delhi
C2 OS 2
3 A Chennai

Course relation
Student Relation
referencing table
referenced table
• What is Integrity ?
• One value every where throughout the database.
• As the students get added in student table course table will also be
updated according to roll no.
• Course table cannot have a roll no “5” as the roll no “5” is not present in
students table. Here the insertion of “5” in course table will be violated.
• First roll no “5” should be in students table inorder to be in course table.
As Course table is taking a reference from student table’s primary key .
• Course table is called as “referencing table” and student table is called
as “referenced table”
• To create a foreign key :
• Create table course(course_id varchar(10), c_name varchar(20), roll_no
int(10) references student(roll_no));
Constraints for referenced table.
• If anything is inserted in referenced table NO violation.

4 D Goa

• If anything is deleted in referenced table then there occurs a Violation

• Ex: If roll_no 1 is to be deleted from student relation , but roll no 1 is
studying a course in course table. This loses Integrity. So, Deletion
may cause violation.
• Solution : Manually delete the roll_no 1 from student table and
course table too. But, if this has to be done automatically ?
REFERENCED RELATION :
SQL allows to choose any of the 4 options:

1) ON DELETE CASCADE:
• The cascade keyword says that if a student row was deleted all the
course rows that refer to it are also deleted.
• If roll_no 1 is deleted from student relation, automatically row holding
roll_no 1 in course table will also be deleted.
• To create such a foreign key :
• Create table course(course_id varchar(10), c_name varchar(20),
roll_no int(10) references student(roll_no) on delete cascade);
2) ON DELETE SET NULL:
When primary key is deleted each of the referenced foreign key is set to NULL.
• To create such a foreign key :
• Create table course(course_id varchar(10), c_name varchar(20), roll_no
int(10) references student(roll_no) on delete set NULL);

NULL

• But at times a scenario can arise, the referencing table’s foreign key can also
be the primary key of that table. In that case, this solution cannot be
adopted as primary key CANNOT be NULL.
3) ON DELETE NO ACTION:
This states that when the primary key is deleted from the referenced
relation NO ACTION is being performed. When the deletion is done this
gives an error and the deletion is strictly violated here. No change is
done in either of the tables.
4) ON UPDATE CASCADE:
If any updation is to be done in the referenced relation , then that
change should be reflected in referencing relation too. If the roll no in
students table is updated then the course table roll no should also be
updated.
• REFERENCING TABLE :
• INSERT : Inserting any data in referencing table which is not in
referenced table may cause violation
• DELETE: Deleting any data in referencing table will NOT cause
violation
• UPDATE : Updating foreign key data in referencing table which is not
in referenced table may cause violation

• THIS IS HOW REFERENTIAL INTEGRITY IS MAINTAINED IN FOREIGN

KEY
Referential integrity enforcement steps taken by the DBMS
• Deletions of Enrolled tuples do not violate referential integrity, but
insertions of Enrolled tuples could.
• The following insertion is illegal because there is no Students tuple
with sid 51111:
INSERT INTO Enrolled (cid, grade, studid) VALUES ('Hindi101', 'B’, 51111)
• On the other hand, insertions of Students tuples do not violate
referential integrity, and deletions of Students tuples could cause
violations.
• Further, updates on either Enrolled or Students that change the
studid (respectively, sid) value could potentially violate referential
integrity.
SQL provides several alternative ways to handle foreign key violations. We
must consider three basic questions:
1. What should we do if an Enrolled row is inserted, with a studid column
value that does not appear in any row of the Students table?
In this case, the INSERT command is simply rejected.

2. What should we do if a Students row is deleted?

The options are:
• Delete all Enrolled rows that refer to the deleted Students row.
• Disallow the deletion of the Students row if an Enrolled row refers to it.
Integrity Rule 2(Referential Integrity Rule / Constraint)
➢ The integrity Rule 2 is also called the Referential Integrity
Constraints.
➢ This rule states that if a foreign key in Table 1 refers to the
Primary Key of Table 2, then every value of the Foreign Key in
Table 1 must be null or be available in Table 2. For example,
 Transactions and Constraints

• A program that runs against a database is called a transaction,

and it can contain several statements (queries, inserts,
updates, etc.) that access the database.
• If (the execution of) a statement in a transaction violates an
integrity constraint, should the DBMS detect this right away
or should all constraints be checked together just before the
transaction completes?
• By default, a constraint is checked at the end of every SQL
statement that could lead to a violation, and if there is a
violation, the statement is rejected.
• Sometimes this approach is too inflexible. Consider the
following variants of the Students and Courses relations; every
student is required to have an honors course, and every course
is required to have a grader, who is some student.
CREATE TABLE Students ( sid CHAR(20) ,
name CHAR(30),
login CHAR (20) ,
age INTEGER,
honors CHAR(10) NOT NULL,
gpa REAL)
PRIMARY KEY (sid),
FOREIGN KEY (honors) REFERENCES Courses (cid))
CREATE TABLE Courses (cid CHAR(10),
cname CHAR ( 10) ,
credits INTEGER,
grader CHAR(20) NOT NULL,
PRIMARY KEY (cid)
FOREIGN KEY (grader) REFERENCES Students (sid))
• Whenever a Students tuple is inserted, a check is made to see if the
honors course is in the Courses relation, and whenever a Courses
tuple is inserted, a check is made to see that the grader is in the
Students relation.
• How we are going to insert the very first course or student tuple?
One cannot be inserted without the other.
• The only way to accomplish this insertion is to defer the constraint
checking that would normally be carried out at the end of an
INSERT statement.
• SQL allows a constraint to be in DEFERRED or IMMEDIATE
mode.
• SET CONSTRAINT ConstraintFoo DEFERRED
• A constraint in deferred mode is checked at commit time.
• In our example, the foreign key constraints on honors and graders can
both be declared to be in deferred mode. We can then insert? honors
with a nonexistent grader (temporarily making the database
inconsistent), insert the honors (restoring consistency), then commit
and check that both constraints are satisfied.
(N)-tuple a set of (n) attribute-value pairs representing a single instance of a relation’s
mapping between its domains.
Degree the number of attributes a relation has.
Cardinality a number of tuples a relation has.
Roles several attributes can have the same domain; the attributes indicate different roles in the
relation.
Key (SuperKey) a set of attributes whose values together uniquely identify every tuple in a
relation. Let t1 and t2 be two tuples on relation r of relation schema R, and sk be a set of
attributes whose values are the key for the relation schema R, then t1[sk]  t2[sk].
(Candidate) Key a (super)key that is minimal, i.e. has no proper subsets that still uniquely
identify every tuple in a relation. There can be several for one relation.
Primary Key a candidate key chosen to be the main key for the relation. There is only one for
each relation.
Foreign Key a candidate key of relation A situated in relation B.
Database a set of relations.
 QUERYING RELATIONAL DATA
• A relational database query (query, for short) is a question about
the data, and the answer consists of a new relation containing the
result.
• A query language is a specialized language for writing queries.
• SQL is the most popular commercial query language for a
relational DBMS.
SELECT *
FROM Students S
WHERE S.age < 18
SELECT S.name, S.login
FROM Students S
WHERE S.age < 18
LOGICAL DATABASE DESIGN: ER TO RELATIONAL
• The ER model is convenient for representing an initial, high-level database
design.
 Entity Sets to Tables

CREATE TABLE Employees

( ssn CHAR(11),
name CHAR(30),
lot INTEGER,
PRIMARY KEY (ssn));
 Relationship Sets (without Constraints) to Tables
• A relationship set, like an entity set, is mapped to a relation in the
relational model.
• To represent a relationship, we must be able to identify each
participating entity and give values to the descriptive attributes of
the relationship.
• Thus, the attributes of the relation include:
 The primary key attributes of each participating entity set, as
foreign key fields.
 The descriptive attributes of the relationship set.
CREATE TABLE Works_In2
( ssn CHAR(11),
did INTEGER,
address CHAR(20) ,
since DATE,
PRIMARY KEY (ssn, did,
address),
FOREIGN KEY (ssn)
REFERENCES Employees
FOREIGN KEY (address)
REFERENCES Locations,
FOREIGN KEY (did) REFERENCES
Departments)
 Translating Relationship Sets with Key Constraints
• If a relationship set involves n entity sets and some of them are linked
via arrows in the ER diagram, the key for anyone of these m entity
sets constitutes a key for the relation to which the relationship set is
mapped.
• Hence we have m candidate keys, and one of these should be
designated as the primary key.

Key Constraint on
Manages
CREATE TABLE Manages (ssn CHAR (11) ,
did INTEGER,
since DATE,
PRIMARY KEY (did),
FOREIGN KEY (ssn) REFERENCES Employees,
FOREIGN KEY (did) REFERENCES Departments)
second approach to translating a relationship set with key constraints is
often superior because it avoids creating a distinct table for the relationship
set. The idea is to include the information about the relationship set in the
table corresponding to the entity set with the key, taking advantage of the
key constraint. In the Manages example, because a department has at most
one manager, we can add the key fields of the Employees tuple denoting the
manager and the since attribute to the Departments tuple.

CREATE TABLE Departments ( did INTEGER,

dname CHAR(20),
budget REAL,
ssn CHAR (11) ,
since DATE,
PRIMARY KEY (did),
FOREIGN KEY (ssn) REFERENCES Employees)
This approach eliminates the need for a separate Manages relation, and
queries asking for a department's manager can be answered without
combining information from two relations. The only drawback to this
approach is that space could be wasted if several departments have no
managers. In this case the added fields would have to be filled with null
values. The first translation (using a separate table for Manages) avoids
this inefficiency, but some important queries require us to combine
information from two relations, which can be a slow operation. Note
that ssn can take on null values.
 Translating Relationship Sets with Participation Constraints
• Every department is required to have a manager, due to the participation
constraint, and at most one manager, due to the key constraint.
• The NO ACTION specification, which is the default and need not be
explicitly specified, ensures that an Employees tuple cannot be
deleted while it is pointed to by a Dept-Mgr tuple. If we wish to delete
such an Employees tuple, we must first change the DeptMgr tuple to
have a new employee as manager.
 Translating Weak Entity Sets
• A weak entity set always participates in a one-to-many binary
relationship and has a key constraint and total participation.
CREATE TABLE Dep_Policy (pname CHAR(20) ,
age INTEGER,
cost REAL,
ssn CHAR (11) ,
PRIMARY KEY (pname, ssn),
FOREIGN KEY (ssn) REFERENCES Employees
ON DELETE CASCADE )
Observe that the primary key is (pname, ssn) , since Dependents is a weak
entity. We have to ensure that every Dependents entity is associated
with an Employees entity (the owner), as per the total participation constraint
on Dependents. That is, ssn cannot be null. This is ensured because SSN, is
part of the primary key. The CASCADE option ensures that information about
an employee's policy and dependents is deleted if the corresponding Employees
tuple is deleted.
 Translating Class Hierarchies
1. We can map each of the entity sets Employees, Hourly_Emps, and ContractEmps
to a distinct relation.
The Employees relation is created as Hourlyemps here;
ContractEmps is handled similarly.
The relation for Hourly_Emps includes the hourly_wages
and hours_worked attributes of Hourly_Emps. It also contains the key attributes
of the superclass (ssn, in this example), which serve as the primary
key for Hourly_Emps, as well as a foreign key referencing the superclass
(Employees). For each Hourly_Emps entity, the value of the name and
lot attributes are stored in the corresponding row of the superclass (Employees).
Note that if the superclass tuple is deleted, the delete must be
cascaded to HourlyEmps.
2. Alternatively, we can create just two relations, corresponding to Hourly_Emps
and ContractEmps. The relation for Hourlyemps includes all the attributes
of Hourly_Emps as well as all the attributes of Employees (i.e.,
ssn, name, lot, hOurly_ wages, hours_worked.
 Translating ER Diagrams with Aggregation

monitors
• The Employees, Projects, and Departments entity sets and the
Sponsors relationship set are mapped as described in previous
sections. For the Monitors relationship set, we create a relation with
the following attributes: the key attributes of Employees (ssn), the key
attributes of Sponsors (did, pid), and the descriptive attributes of
Monitors until.
 ER to Relational: Additional Examples
CREATE TABLE Policies
( policyid INTEGER,
cost REAL,
ssn CHAR (11) NOT NULL,
PRIMARY KEY (policyid), CREATE TABLE Dependents (pname
FOREIGN KEY (ssn) CHAR(20) ,
REFERENCES Employees ssn CHAR (11) ,
ON DELETE CASCADE ) age INTEGER,
policyid INTEGER NOT NULL,
PRIMARY KEY (pname, policyid, ssn),
FOREIGN KEY (policyid, ssn)
REFERENCES Policies
ON DELETE CASCADE )
• We can use the key constraints to combine Purchaser information
with Policies and Beneficiary information with Dependents, and
translate it into the relational model.
• Notice how the deletion of an employee leads to the deletion of all
policies owned by the employee and all dependents who are
beneficiaries of those policies.
 INTRODUCTION TO VIEWS IN SQL:
• Views are derived or virtual tables, they derive their data from the
original relation.
• A view also contains rows and columns and to create the view, we can
select the fields from one or more tables present in the database.
• A view rows are not explicitly stored in the database but are computed
as needed from a view definition.
• A view can either have specific rows based on certain condition or all
the rows of a table.
• Views allows the user to see only the part of data but not all data.
• Views are dynamic in nature i.e. the changes made to the views are
reflected back to the original table and vice versa.
Creation of Views

Syntax:
CREATE VIEW View-name (field1,field2….fieldn)
AS SELECT (attribute1,attribute2….attributen)
FROM table1,table2…tablen
WHERE <condition>;
Student
Marks
 Creating view from single table
create view details as
select name, address from student
where S_ID<5;
-Just like table query we can query the view to display the data stored in the
views.
Select * from details;

CREATE
VIEW
• CREATE VIEW StudentNames AS
SELECT S_ID, NAME FROM Student
ORDER BY NAME;

• SELECT * FROM StudentNames;

 Creating view from multiple tables
• Create view marksview as
• select student.name, student.address, marks.marks from student, marks
where student.name=marks. name
• SELECT * FROM marksView;
student marks
marksview
  Views, Data Independence, Security
• The physical schema for a relational database describes how the relations in the
conceptual schema are stored, in terms of the file organizations and indexes
used.
• The conceptual schema is the collection of schemas of the relations stored in
the database.
• Additional relations in the external schema can be defined using the view
mechanism.
• The view mechanism thus provides the support for logical data independence
in the relational model.
• That is, it can be used to define relations in the external schema that mask
changes in the conceptual schema of the database from applications.
• For example, if the schema of a stored relation is changed, we can define a
view with the old schema and applications that expect to see the old schema
can now use this view.
• Views are also valuable in the context of security: We can define
views that give a group of users access to just the information they
are allowed to see.
• For example, we can define a view that allows students to see the
other students names, age but not gpa, & allows all students to
access this VIEW but not the underlying students table.
 UPDATING VIEWS
• There are certain conditions needed to be satisfied to update a view.
• If any one of these conditions is not met, then we will not be allowed to
update the view.
The SELECT statement which is used to create the view should not have
the DISTINCT keyword.
The View should have all NOT NULL values.
The view should not be created using nested queries or complex
queries.
All NOT NULL columns from the base table must be included in the view
in order for the INSERT query to function.
mysql> select * from faculty;
+------+-------+--------+
| fid | fname | salary |
+------+-------+--------+
| 1 | abc | 20000 |
| 2 | lmn | 25000 |
| 3 | xyz | 50000 |
| 4 | fgh | 40000 |
| 5 | aaa | 45000 |
+------+-------+--------+
5 rows in set (0.00 sec)

mysql> create view f1 as select fid,fname from faculty order by fname;

Query OK, 0 rows affected (0.02 sec)
mysql> select * from f1; mysql> insert into f1 values(6,'rrr‘);
Query OK, 1 row affected (0.00 sec)
+------+-------+
| fid | fname | mysql> select * from faculty;
+------+-------+ +------+-------+
| fid | fname |
| 5 | aaa | +------+-------+
| 1 | abc | | 1 | abc |
| 2 | lmn |
| 4 | fgh |
| 3 | xyz |
| 2 | lmn | | 4 | fgh |
| 3 | xyz | | 5 | aaa |
| 6 | rrr |
+------+-------+
+------+-------+
5 rows in set (0.02 sec) 6 rows in set (0.00 sec)
mysql> delete from f1 where fid=6;
Query OK, 1 row affected (0.00 sec)

mysql> select * from faculty;

+------+-------+--------+
| fid | fname | salary |
+------+-------+--------+
| 1 | abc | 20000 |
| 2 | lmn | 25000 |
| 3 | xyz | 50000 |
| 4 | fgh | 40000 |
| 5 | aaa | 45000 |
+------+-------+--------+
5 rows in set (0.00 sec)
mysql> update f1 set fname='bbb' where fid=5;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0

mysql> select * from faculty;

+------+-------+--------+
| fid | fname | salary |
+------+-------+--------+
| 1 | abc | 20000 |
| 2 | lmn | 25000 |
| 3 | xyz | 50000 |
| 4 | fgh | 40000 |
| 5 | bbb | 45000 |
+------+-------+--------+
5 rows in set (0.00 sec)

mysql>
  DESTROYING/ALTERING TABLES AND VIEWS
• If we decide that we no longer need a base table and want to
destroy it (i.e., delete all the rows and remove the table
definition information), we can use the DROP TABLE
command.
• For example, DROP TABLE Faculty RESTRICT destroys the
Faculty table unless some view or integrity constraint refers to
Faculty; if so, the command fails.
• If the keyword RESTRICT is replaced by CASCADE,
Faculty is dropped and any referencing views or integrity
constraints
• ALTER TABLE modifies the structure of an existing table. To
add a column called maiden-name to Students, for example, we
would use the following command.

ALTER TABLE Students

ADD COLUMN maiden-name CHAR(10)
Dropping Views
• Obviously, where you have a view, you need a way to drop the view if
it is no longer needed.
• The syntax is very simple and is given below −
DROP VIEW view_name;