Unit Reading Assignment

Lecture 5

1Dr. Nawaz Khan, School of Computing ScienceE-mail: [email protected]

BIS4435 – Data Management for Decision Support

Lecture 3: Normalization and Database Query

Dr. Nawaz KhanSchool of Computing ScienceE-mail: [email protected]

Lecture 5


Unit Reading Assignment

Unit 5: Entity Relationship Modelling: A Traditional vs. Object Oriented Approach

Reading Suggestion:

Connolly, T.M., and Begg, C.E., Database Systems: A Practical Approach to Design, Implementation and Management, Addison-Wesley, 4th Edition, ISBN: 0321210255(chapters 6)

Global campus materials on OASIS: http://oasis.mdx.ac.uk/ (unit 5)

More Reading:

Fundamentals of Database Systems. R. Elmasri and S. B. Navathe,

4th Edition, 2004, Addison-Wesley, ISBN 0-321-12226-7 (Chapters 10)

Lecture 5


Unit Learning Outcome

At the end of this unit you should be able to: Describe the process, strengths and weaknesses of Data

Normalisation, and so demonstrate an understanding of when and to what extent the technique should be applied in practice

Explain and apply the concepts of Functional Dependency and Determinant through the understanding and construction of Determinacy Diagrams

Describe and apply understanding of three Normal Forms for relations: Convert Un-normalised data into First Normal Form relations, so

that data items contain only single, simple values derive Second Normal Form relations by eliminating part-key

dependencies derive Third Normal Form relations by removing transitive

dependencies Convert a set of relations to Boyce-Codd Normal form

Lecture 5


Functional Dependencies and Normalization for Relational Databases

Outline Introduction Functional dependency

Direct dependency Indirect dependency Partial dependency

Normalization 1NF and dependency problems 2NF – solves partial dependency 3NF – solves indirect dependency BCNF – well-normalized relations

Notes and suggestions Summary

Lecture 5



Introduction

Each relation schema consists of a number of attributes and the relational database schema consists of a number of relation schemas

Attributes are grouped to form a relation schema Need some formal measure of why one grouping of attributes

into a relation schema may be better than another

Lecture 5



Introduction

Top-down database design:

Mini-world

Requirements

Conceptual schema

E1

E2

R

Relation schemas?

Lecture 5



Introduction

“Goodness” measures: Redundant information in tuples Update anomalies: modification, deletion, insertion Reducing the NULL values in tuples Disallowing the possibility of generating spurious tuples

Lecture 5



Introduction

Redundant information in tuples In EMP_DEPT, the attribute values pertaining to a particular

department (DNUMBER, DNAME, DMGRSSN) are repeated for every employee who works for that department

Update anomalies: modification, deletion, insertion Modification

As the manager of a dept. changes we have to update many values according to employees working for that dept.

Easy to make the DB inconsistent

Lecture 5



Introduction

Update anomalies: modification, deletion, insertion (cont.) Deletion:

If Borg James E. leaves, we delete his tuple and lose:– the existing of dept. 1

– the name of dept. 1

– who is the manager of dept. 1

Insertion: How can we create a department before any employees are assigned

to it ??

Lecture 5



Introduction

Reducing the NULL values in tuples Employees not assigned to any dept.: waste the storage space Other difficulties: aggregation operations (e.g., COUNT) and joins

Disallowing the possibility of generating spurious tuples

EMP_PROJ(SSN, PNUMBER, HOURS, ENAME, PNAME, PLOCATION)

EMP_LOCS(ENAME, PLOCATION)EMP_PROJ1(SSN, PNUMBER, HOURS, PNAME, PLOCATION)

Generation of invalid and spurious data during JOINS: PLOCATION is the attribute that relates EMP_LOCS and EMP_PROJ1, and PLOCATION is neither a primary key nor a foreign key in either EMP_LOCS or EMP_PROJ1 (cf. chapter 10 [1] for more details)

Lecture 5



Introduction “Goodness” measures:

Redundant information in tuples Update anomalies: modification, deletion, insertion Reducing the NULL values in tuples Disallowing the possibility of generating spurious tuples

Normalization It helps DB designers determine the best relation schemas

A formal framework for analyzing relation schemas based on their keys and on the functional dependencies among their attributes

A series of normal form tests that can be carried out on individual relation schemas so that the relational database can be normalized to any desired degree

It is based on the concept of normal form 1NF, 2NF, 3NF, BCNF, 4NF, 5 NF

It is a process which ensures that the data is structured in such a way that attributes are grouped with the PK. Attributes that do not directly depend on PK may be extracted to form a new relation

Lecture 5



Functional dependency

Dependencies between different ATTRIBUTES - determinant


Relation schemas

?

Conceptual schema

E1

E2

R

Lecture 5


Determinant: X is a determinant of Y if each value of X has precisely one

(possibly NULL) associated value of Y Another way: X is a determinant of Y if and only if whenever

two tuples agree on their X value they agree on their Y value X determines Y or Y is functionally dependent on X Formal definition:

A functional dependency, denoted by X -> Y, between two sets of attributes X and Y that are subsets of R specifies a constraint on the possible tuples that can form a relation state r of R. The constraint is that, for any two tuples t1 and t2 in r that have t1[X] = t2[X], we must also have t1[Y] = t2[Y]

Functional determinancy diagram shows the dependencies in a visual format



X Y

Lecture 5




An example:

Direct dependency (fully functional dependency) All attributes in a R must be fully functionally dependent on the

primary key (or the PK is a determinant of all attributes in R)

Performer-id Performer-name

Performer-type

Performer-location

Lecture 5




Indirect dependency (transitive dependency) Value of an attribute is not determined directly by the primary key

Performer-id

Performer-name

Performer-type

Performer-location

Fee

Lecture 5




Partial dependency Composite determinant - more than one value is required to

determine the value of another attribute, the combination of values is called a composite determinantEMP_PROJ(SSN, PNUMBER, HOURS, ENAME, PNAME, PLOCATION)

{SSN, PNUMBER} -> HOURS

Partial dependency - if the value of an attribute does not depend on an entire composite determinant, but only part of it, the relationship is known as the partial dependency

SSN -> ENAME

PNUMBER -> {PNAME, PLOCATION}

Lecture 5




Partial dependency Another example using functional determinancy diagram:


Performer-type

Performer-location

Fee

Agent-id Agent-name

Agent-location

Lecture 5


BIS4229 – Industrial Data Management Technologies


Outline Introduction Functional dependency


Normalization 1NF and dependency problems 2NF – solves partial dependency 3NF – solves indirect dependency BCNF – well-normalized relations

Notes and suggestions Summary

Lecture 5



Normalization – 1NF

First normal form (1NF) - there is only one value at the intersection of each row and column of a relation - no set valued attributes in 1 NF

To be part of the formal definition of a relation in the basic (flat) relational model

Problem with 1NF - no primary key for the relation

Lecture 5




Agent-id

Venue-id

Event-id

Booking-date

Performer-location

Agent-name

Agent-location

Venue-name

Venue-location

Event-name

Event-type

Performer-id

Performer-name

Performer-type Fee

1NF determinancy diagram

Lecture 5




Second normal form (2NF) - all attributes must be fully functionally dependent on the primary key

2NF solves partial dependency problem in 1NF Method: identify primary keys and group attributes that relate to

the key together to form separate new relations Benefit of 2NF Problem with 2NF

Lecture 5





Performer-type

Performer-location

Fee

Relation in 2NF

P-id P-name P- type Fee P-loc’n101 Baron Singer 75 York105 Steed Dancer 60 Berlin108 Jones Actor 85 Bombay

112 Eagles Actor 85 Leeds118 Markov Dancer 60 Moscow126 Stokes Comedian 90 Athens129 Chong Actor 85 Beijing134 Brass Singer 75 London138 Ng Singer 75 Penang140 Strong Magician 72 Rome141 Gomez Musician 92 Lisbon143 Tan Singer 75 Chicago

147 Qureshi Actor 85 London

149 Tan Actor 85 Taipei

150 Pointer Magician 72 Paris

152 Peel Dancer 60 London


Lecture 5




Agent-idAgent-name

Agent-location

Venue-idVenue-name

Venue-location


Relation in 2NF

A-id A-name A-loc’n1295 Burton Lonton1435 Nunn Boston

1504 Lee Taipei

1682 Tsang Beijing

1460 Stritch Rome1522 Ellis Madrid

1509 Patel York1478 Burns Leeds1377 Webb Sydney1478 Burns Leeds1190 Patel Hue1802 Chapel Bristol1076 Eccles Oxford

1409 Arkley York

1428 Vemon Cairo

V-id V-name V-loc’n59 Atlas Tokyo35 Polis Athens54 Nation Lisbon

17 Silbury Tunis

46 Royale Cairo

75 Vostok Kiev

79 Festive Rome28 Gratton Boston84 State Kiev82 Tower Lima92 Palace Milan62 Shaw Oxford

Lecture 5





Relation in 2NF

Event-idEvent-type

Event-name

E-id E-name E-type959 Show Time Musical907 Elgar 1 Concert921 Silver Shoe Ballet942 White Lace Ballet

901 The Dark Drama913 What Now Drama926 Next Year Drama952 Gold Days Drama

934 Angels Opera945 Trick-Treat Variety show938 New Dawn Drama981 Birdsong Musical957 Quicktime Musical963 Vanish Magic show941 Mahler 1 Concert964 The Friends Drama927 Chanson Opera971 Card Trick Magic show988 Secret Tape Drama

978 Swift Step Dance

Lecture 5




2NF determinancy diagram Relation in 2NF

Performer-id

Agent-id

Venue-id

Event-id

Booking-date

P-id A-id V-id E-id Booking-date

101 1295 59 959 25-Nov-99105 1435 35 921 07-Jan-02105 1504 54 942 10-Feb-02108 1682 79 901 29-Jul-03112 1460 17 926 13-Aug-00112 1522 46 952 05-May-99112 1504 75 952 16-Mar-99126 1509 59 945 02-Sept-01129 1478 79 926 22-Jun-00134 1504 28 981 18-Sept-01138 1509 84 957 18-Aug-99140 1478 17 963 18-Aug-99141 1478 84 941 21-Jul-00143 1504 79 927 21-Nov-02

147 1076 17 952 30-Apr-00

147 1409 79 988 17-Apr-00

152 1428 59 978 01-Oct-01

Lecture 5





Performer-location

Performer-type

Fee

Relation in 2NF

P-id P-name P- type Fee P-loc’n101 Baron Singer 75 York105 Steed Dancer 60 Berlin108 Jones Actor 85 Bombay

112 Eagles Actor 85 Leeds118 Markov Dancer 60 Moscow126 Stokes Comedian 90 Athens129 Chong Actor 85 Beijing134 Brass Singer 75 London138 Ng Singer 75 Penang140 Strong Magician 72 Rome141 Gomez Musician 92 Lisbon143 Tan Singer 75 Chicago

147 Qureshi Actor 85 London

149 Tan Actor 85 Taipei

150 Pointer Magician 72 Paris

152 Peel Dancer 60 London


Problem with 2NF:

- Insertion

- Modification

- Deletion

Lecture 5




Third normal form (3NF) - all attributes must be directly dependent on primary key

3NF solves indirect (transitive) dependencies problem in 1NF and 2NF

Method: identify all transitive dependencies and each transitive dependency will form a new relation, with non-prime attributes participating in the transitive dependency and the attribute which determines others as the attributes for the new relation

Lecture 5




3NF determinancy diagram Relation in 3NF

Performer-type

Fee

Performer-name

Performer-type

Performer-location

Performer-id

P-id P-name P- type P-loc’n101 Baron Singer York105 Steed Dancer Berlin108 Jones Actor Bombay112 Eagles Actor Leeds118 Markov Dancer Moscow126 Stokes Comedian Athens129 Chong Actor Beijing134 Brass Singer London138 Ng Singer Penang140 Strong Magician Rome141 Gomez Musician Lisbon143 Tan Singer Chicago147 Qureshi Actor London149 Tan Actor Taipei150 Pointer Magician Paris152 Peel Dancer London

P- type FeeSinger 75Dancer 60Actor 85Comedian 90Magician 72Musician 92

Lecture 5



Normalization


Agent-location

Agent-idAgent-name

Agent-location

Event-idEvent-type

Event-name

Venue-idVenue-name

Venue-location

Performer-id

Agent-id

Venue-id

Event-id

Booking-date

Lecture 5



Normalization - BCNF

Boyce-Codd normal form (BCNF) was proposed as a simpler form of 3NF, but it was found to be stricter than 3NF, because every relation in BCNF is also in 3NF; however, a relation in 3NF is not necessarily in BCNF

BCNF: well-normalized relations The formal definition of 3NF: A relation schema R is in

third normal form (3NF) if, whenever a nontrivial functional dependency X -> A holds in R, either (a) X is a superkey of R, or (b) A is a prime attribute of R

The formal definition of BCNF differs slightly from the definition of 3NF: A relation schema R is in BCNF if whenever a nontrivial functional dependency X -> A holds in R, then X is a superkey of R

More details: chapter 10 [1]

Lecture 5



Activity

Lecture 5


Solution

Proj_num proj_name

Emp_num emp_name job_class

Emp_num proj_num assign_hours

Job_class chg_hours

Lecture 5


Lecture 4: Introduction to SQL and OQL

Dr. Nawaz KhanSchool of Computing ScienceE-mail: [email protected]

Lecture 5


Unit Reading Assignment

Unit 4: Introduction to SQL and OQL: Relational and

Object oriented Approach

Reading Suggestion:

Global campus materials on OASIS: http://oasis.mdx.ac.uk/ (unit 4)

Connolly, T.M., and Begg, C.E., Database Systems: A Practical Approach to Design, Implementation and Management, Addison-Wesley, 4th Edition, ISBN: 0321210255(chapters 5 and 6)

Lecture 5


Unit Learning Outcomes

Apply SQL statements in Oracle to perform database query transactions and various calculations

Apply SQL commands in Oracle (CREATE) to define table structure in a relational database and to manipulate rows in a table

Apply SQL statements in Oracle (GRANT and REVOKE) to control data access

Apply Object Definition Language (ODL) to create data objects for data abstraction and nested tables

Apply OQL statements in Oracle to execute queries on data objects

Lecture 5


Introduction to SQL and OQL

Outline Introduction to SQL Data Definition Language (DDL)

Create table Alter table Drop table

Data Manipulation Language (DML) Retrieval

– SELECT-FROM-WHERE (the S-F-W structure)

– Aggregate functions and grouping

Update operations: insert, delete, update

More complex features of SQL queries/commands Object Query in Oracle

Lecture 5


Structured Query Language (SQL) Introduction to SQL

Two formal languages for the relational model: The relational algebra

Provides a formal foundation for relational model operations Is used as a basis for implementing and optimizing queries in

RDBMSs (relational database management systems) Some of its concepts are incorporated into the SQL standard

query language for RDBMSs The user must specify HOW- that is, in what order-to execute

the query operations The relational calculus:

Provides a higher-level declarative notation for specifying relational queries

In relational calculus, we write one declarative expression to specify a retrieval request, and hence there is no description of how to evaluate a query

A calculus expression specifies WHAT is to be retrieved rather than HOW to retrieve it -> nonprocedural language

Lecture 5



SQL: although it includes some features from relational algebra, it is based to a greater extent on the (tuple) relational calculus. However the SQL syntax is more user-friendly than either of the two formal languages

SQL: Structured Query Language The standard language for commercial relational DBMSs ANSI 1986: SQL1, or SQL-86 SQL2, or SQL-92 (revised version of SQL1) SQL3, or SQL-99: core specification + optional specialized

packages (for specific database applications such as data mining, spatial data, temporal data, data warehousing, OLAP, multimedia data, etc.)

Lecture 5



SQL is very good for querying and manipulating data in database systems.

SQL lacks some features commonly found in general programming languages, such as LOOP and IF-THEN-ELSE statements

SQL consists of three major components: DDL (data definition language) to define the way in which

data is stored DML (data manipulation language) to allow retrieval,

insertion of data etc. (this is sometimes called the 'query ' language)

DCL (data control language) to define activities that do not fit with the other two activities

Lecture 5



SQL consists of three major components (cont.): The Data Manipulation Language (DML) of SQL allows the

retrieval, insertion, update and removal of rows stored in relational tables. As mentioned above, numbers of rows can be altered in any one statement, and so DML is a very powerful tool

The Data Definition Language (DDL) is used to create, change the structure or remove whole tables and other relational structures. So whereas you would use the INSERT statement of the DML to insert new rows into an existing table, you would use the DDL CREATE TABLE statement to establish a new table in the first place

The Data Control Language (DCL) define activities that are not in the categories of those for the DDL and DML, such as granting privileges to users, and defining when proposed changes to a databases should be irrevocably made

Lecture 5



Our concerns during this lecture: The Data Manipulation Language (DML) The Data Definition Language (DDL) The Data Control Language (DCL)The Data Control Language (DCL)

Objective: How SQL is capable of: Creating, changing the structure or removing whole tables

and other relational structures Allowing the retrieval, insertion, update and removal of

rows/tuples stored in relational tables

Lecture 5



The following example is used throughout this lecture to illustrate SQL operations: Suppose we have a university database containing the

following relations:STUDENT (SNO, SNAME, SLEVEL)

COURSE (CNO, TITLE, LNAME)

REPORT (SNO, CNO, MARK)

LECTURER (LNAME, ROOM_NO)

Remember: A relation schema may be viewed as a table. An instance of a relation may be viewed as a set consisting

of tuples

Lecture 5


Structured Query Language (SQL) Data Definition Language (DDL)

Create table In terms of SQL statements, a relation is implemented as a table.

Subsequently, a tuple is a row in a table and an attribute is a column of a table

The CREATE TABLE command is used to set up a new table (i.e. to implement a relation) in the database. The table must be given a name (corresponding to the name of the relation) and its attributes must be named and given data types

Example: To create the table (i.e. relation) STUDENT with the attributes SNO of type INTEGER, SNAME of type VARCHAR, and SLEVEL of type INTEGER, the following SQL statement is used:

CREATE TABLE STUDENT

(SNO INTEGER,

SNAME VARCHAR(20),

SLEVEL INTEGER); Note: The data types used in the above example are those allowed in

Oracle SQL. Data types in different implementations of SQL may vary slightly in that they may use different names for a particular type

Lecture 5



A number of important constraints can be defined on attributes during table creation: NOT NULL: which means that the value of the attribute must not be NULL.

This can be specified for any attribute as required DEFAULT: which is used to specify a default value for the attribute. If there

is no default value specified, the system default value is NULL Example: In the above example, if assume SNO is a key attribute

whose value cannot be null, and a default value for SLEVEL is 0, we have the following SQL statement:

CREATE TABLE STUDENT(SNO INTEGER NOT NULL, SNAME VARCHAR(20),SLEVEL INTEGER DEFAULT 0);

Note: If no default value is specified and NULL value is not allowed, then a value must be supplied by the user. Otherwise, an error occurs

Similarly, write SQL commands to create COURSE, REPORT, and LECTURER tables

Lecture 5



Create table (Implementation of Primary Key and Foreign Key)CREATE TABLE ARTIST (ARTIST_ID NUMBER(2), ARTIST_NAME TEXT(30), COUNTRY_OF_ORIGIN TEXT(25), DATE_OF_BIRTH DATE, PRIMARY KEY (ARTIST_ID));

CREATE TABLE MUSIC_COLLECTION (ITEM_ID NUMBER(4), TITLE VARCHAR(40), ARTIST_ID NUMBER(2), ITEM_TYPE TEXT(1), DATE_PURCHASED DATE, PRIMARY KEY (ITEM_ID), CONSTRAINT FK_ARTIST FOREIGN KEY (ARTIST_ID) REFERENCES ARTIST (ARTIST_ID)); ON DELETE SET NULL and ON DELETE CASCADE to retain data

integrity

Lecture 5



Alter table The ALTER statement in SQL, like the CREATE statement, can be

used to change a number of different types of data object, including tables, access privileges, constraints etc. Here we shall concentrate on its use to change the structure of tables.

You can use the ALTER TABLE statement to modify a table's definition. This statement changes the structure of a table, not its contents. You can use the ALTER TABLE statement to:

Add a new column to an existing table: For example, to add a department head attribute to the DEPT table we could specify:

ALTER TABLE DEPT ADD DEPT_HEAD NUMBER(4); Increase or decrease the width of an existing column: to change an

EMP table so that the DEPTNO attribute can contain 3 digit values:

ALTER TABLE EMP MODIFY DEPTNO NUMBER(3); Change an existing column from mandatory to optional (i.e. specify

that it may contain nulls), etc. (homework !!)

Lecture 5



Drop table To remove a table, the DDL statement is:

DROP TABLE <TABLE NAME> It is deceptively easy to issue this command, and unlike most

systems one encounters today, there is no prompt at all about whether you wish to proceed with the process. Dropping a table involves the removal of all the data and constraints on the table, and finally removal of the table structure itself

Example to remove our copy of the EMP table:

DROP TABLE EMP; Using the DROP TABLE statement when creating tables

Lecture 5


Structured Query Language (SQL) Data Manipulation Language (DML)

Basic SQL queries: The basic SQL query statement takes the so-called S-F-W form:

SELECT <attribute list>

FROM <table list>

WHERE <condition>;where:

<attribute list> is a list of attribute names whose values are to be retrieved by the query.

<table list> is a list of the relation names from which the attributes to be retrieved.

<condition> is a Boolean expression to specify the condition that the tuples to be retrieved have to satisfy

Lecture 5



STUDENT (SNO, SNAME, SLEVEL)




Query 1: Retrieve the numbers and names of all students at level 1:

SELECT SNO, SNAME

FROM STUDENT

WHERE SLEVEL = 1; Note: The result of this query is a "relation" containing the

numbers and names of the level 1 students

Lecture 5



Qualifying attribute names: If two or more tables (i.e. relations) are involved in the query, the attribute names must be qualified by prefixing the relation names to the attribute names

Query 2: Retrieve the numbers and names of students who take course 101.

SELECT STUDENT.SNO, STUDENT.SNAME

FROM STUDENT, REPORT

WHERE STUDENT.SNO = REPORT.SNO

AND REPORT.CNO = 101; Note: Query 2 performs a join operation between STUDENT

and REPORT on SNO

Lecture 5



Query 3: Retrieve the numbers and names of students who take at least one of the courses given by the lecturer named John

SELECT STUDENT.SNO, STUDENT.SNAME

FROM STUDENT, REPORT, COURSE

WHERE STUDENT.SNO = REPORT.SNO

AND REPORT.CNO = COURSE.CNO

AND COURSE.LNAME = “John"; Note that we have the following tables:





Lecture 5



Retrieval SELECT-FROM-WHERE Aggregate functions and grouping

Update operations

Lecture 5



Unspecified WHERE clause and the use of “*” Unconditional queries: If the WHERE clause is not specified, no

condition is imposed on the selection of tuples. As a result, all tuples of the relation specified in the FROM clause are selected. If there are two or more relations in the FROM clause, then all possible tuple combinations of the relations are returned as the query results

Query 4: Retrieve all student numbers.

SELECT SNO

FROM STUDENT; Query 5: Retrieve all student numbers and course numbers.

SELECT STUDENT.SNO, COURSE.CNO

FROM STUDENT, COURSE;

Lecture 5



The “ * ” notation: The asterisk (*) indicates that all the attributes of the relation(s) specified in the FROM clause are to be retrieved



Query 6: Retrieve all the details of lecturers

SELECT *

FROM LECTURER; Query 7: Retrieve all the details of level 1 students

SELECT *

FROM STUDENT

WHERE SLEVEL = 1;

Lecture 5



The query result is a “Bag” of tuples: The query result in SQL is also a "relation". However, such a relation is not a set of tuples. Instead it is a bag of tuples. The reason is that duplicate tuples are allowed in the result of a query

Note: If the key of a relation is not retrieved by a query, then it is possible that the query results contain duplicate tuples

SELECT SNAMEFROM STUDENTWHERE SLEVEL = 1;

In SQL, the duplicates are not automatically removed from the resulting relation. However, the key word DISTINCT can be used to eliminate any duplicate tuples

Query 8: Retrieve all the different names of the students at level 1SELECT DISTINCT SNAMEFROM STUDENTWHERE SLEVEL = 1;

Lecture 5



Ordering tuples in query results: The ORDER BY clause can be used to order tuples in the query result. The order can either be ascending by using the key word ASC, or descending by using the key word DESC. If no key word is specified, the default order is ascending

Query 11: Retrieve the numbers and names of all level 1 students ordered in an ascending alphabetical order according to their names.

SELECT SNO, SNAMEFROM STUDENTWHERE SLEVEL = 1ORDER BY SNAME ASC;

Query 12: Retrieve the numbers and names of students, and the numbers of the courses that the students are taking, ordered by the course number, and related to each course by students' names.

SELECT STUDENT.SNO, STUDENT.SNAME, COURSE.CNO

FROM STUDENT, COURSEWHERE STUDENT.SNO = COURSE.SNOORDER BY COURSE.CNO DESC, STUDENT.SNAME ASC;

Lecture 5




Update operations

Lecture 5



Aggregate functions and grouping Five built-in functions:

COUNT: counts the number of values in a specified column (i.e. an attribute)

SUM: totals the values in a specified column with a numeric type AVG: calculates the average of the values in a specified column with a

numeric type MIN: returns the minimum value in a specified column MAX: returns the maximum value in a specified column

Note: The above built-in functions can operate on the values of a single attribute of a permanent relation or the resulting relation of a query

Lecture 5



Query 13: Find the highest, the lowest, and the average marks in course 101

SELECT MAX(MARK), MIN(MARK), AVG(MARK)FROM REPORTWHERE CNO = 101;

Query 14: Find out how many courses the lecturer John is teachingSELECT COUNT(*)FROM COURSEWHERE LNAME = “John";

Note: COUNT(*) returns the number of rows in the resulting table (i.e. relation) of the query. “*” refers to all the tuples (i.e. rows)

Query 15: Find out how many different names are used by level 1 students

SELECT COUNT(DISTINCT SNAME)FROM STUDENTWHERE SLEVEL = 1;

Lecture 5




Update operations: in SQL, there are three commands to modify data in a database: INSERT: to insert a new tuple into a table that has already been

created DELETE: to remove an existing tuple(s) from a table UPDATE: to change the value of a specified data item in an

existing tuple

Lecture 5



Insert: Example: Insert into the relation STUDENT (previously created) a new tuple

with following attribute values:SNO = 2020,SNAME = "James Bond",SLEVEL = 0

Two forms of the INSERT statement:(1) INSERT INTO STUDENT

VALUES (2020, "James Bond", 0);

(2) INSERT INTO STUDENT(SNO, SNAME)VALUES (2020, "James Bond");

Note: In the first case, the values listed in the VALUES clause must be corresponding

to the attributes specified in the table creation operation. The order of values is crucial: STUDENT (SNO, SNAME, SLEVEL)

In the second case, the values in the VALUES clause are corresponding to the attributes specified in the INSERT INTO clause. Those attributes that are not included in the INSERT INTO clause will take either the default values (if there are any) or the NULL value

Lecture 5



Delete: Example: Delete all level 3 students.

DELETE FROM STUDENT

WHERE SLEVEL = 3; Note:

The DELETE command operates on only one table at a time If the condition specified in the WHERE clause is FALSE, no tuple is

deleted If the condition evaluates to TRUE, one or more tuples may be

removed If no condition is specified (i.e. no WHERE clause), all tuples in the

table are removed Even if all tuples of a table are deleted, the table still exists in the

database. The DROP TABLE command may be used to remove a table completely from the database

Lecture 5




Update: Example: Change the lecturer on course 251 from “John” (or

whoever) to Anderson.

UPDATE COURSE

SET LNAME = “Anderson”

WHERE CNO = 251;

Lecture 5




Update operations: in SQL, there are three commands to modify data in a database: INSERT: to insert a new tuple into a table that has already been

created DELETE: to remove an existing tuple(s) from a table UPDATE: to change the value of a specified data item in an

existing tuple

Lecture 5


Structured Query Language (SQL)

Outline Introduction to SQL Data Definition Language (DDL)

Create table Alter table Drop table

Data Manipulation Language (DML) Retrieval

– SELECT-FROM-WHERE (the S-F-W structure)

– Aggregate functions and grouping

Update operations: insert, delete, update

More complex features of SQL queries/commands Summary

Lecture 5


Structured Query Language (SQL) More complex features of SQL queries/commands

Nested queries and set membership testing Nested queries: A database query may consist of a number of sub-

queries when the result of a sub-query form the condition (or part of the condition) of another query. Such a complex query is called nested query. A special operator IN is introduced to examine whether a tuple is a member of the resulting relation of a sub-query

Query 9: Retrieve the numbers and names of students who take course 101 (same as query 2)

SELECT SNO, SNAME

FROM STUDENT

WHERE SNO IN

(SELECT SNO FROM REPORT

WHERE CNO = 101);

Lecture 5



Nested queries and set membership testing (cont.) Query 10: Retrieve the numbers and names of students who take at

least one of the courses given by lecturer John (same as query 3)

SELECT SNO, SNAME FROM STUDENT

WHERE SNO IN

(SELECT SNO FROM REPORT

WHERE CNO IN

(SELECT CNO FROM COURSE

WHERE LNAME = “John")); Note:

Generally a nested query using the IN operator can always be expressed as a simple (i.e. unnested) query. For example, query 9 and 2, and query 10 and 3

Theoretically a query can be nested to any depth

Lecture 5



Other clauses: Group By Having Union Minus Intersect etc.

Group By:SELECT DEPTNO,COUNT(EMPNO)FROM EMPGROUP BY DEPTNO;

This gives the following results: DEPTNO COUNT(EMPNO)

--------- ------------

10 3

20 5

30 6

Having Clause:

SELECT DEPTNO,COUNT(EMPNO)FROM EMPGROUP BY DEPTNOHAVING COUNT(EMPNO) > 4;

Giving the results:DEPTNO COUNT(EMPNO) --------- ------------ 20 5 30 6

Lecture 5


Object Query in Oracle

Oracle provides the facilities to create objects. The classes are implemented in oracle using extended version of DDL. These classes in oracle are called object types. The object types are also known as Abstract Data Types (ADT). There are three different kinds of objects types that can be implemented by using DDL. These are:

Column type Collection type

Lecture 5


Column Type: Example

Create or replace type EmpAddress as object

( Street Varchar2(30),Town Varchar2 (30),City Varchar2(30),PostCode Varchar2(7));

Create or replace type Employee as object

( EmployeeID number(2), Name varchar2 (30),DOB date,Address EmpAddress);

Create or replace type Employee as object( EmployeeID number(2), Name varchar2 (30),DOB date,Address EmpAddress,

Member Function EmpAge Return Number);

Create or replace type body Employee asMember Function EmpAge Return Number IsBegin Return Trunc(((SYSDATE – Self.DOB)/365),1);

End;End;

Lecture 5


Collection Type

Oracle supports for storing of multiple values in a single row. This can be implemented in oracle by applying the following approaches:

Varying arrays or VARRAY Nested tables

Lecture 5


Collection type: VARRAY

Create or replace type Skill_VA as varray(5) of varchar2(20);

Creates a varray, named Skill_VA, which can store maximum 5 values. The newly created varray is of datatype varchar2. The varray Skill_VA can also be used as a datatype in other tables.

Create or replace type Employee as object

( EmployeeID number(2),

Name varchar2 (30),

DOB date,

Address EmpAddress,

Skills Skill_VA

);

Insert into Employee

Values(12, ‘Amer Jahed’, ’12-JAN-1972’, EmpAddress(’12 Big Lane’, ‘Croydon’, ‘London’, ‘CR1 2TD’), Skill_VA(‘Leadership’, ‘Communication’, ‘Computing’, ‘language’, ‘Management’));

Lecture 5


Inserting values in VARRAY

Insert into Employee

Values(12, ‘Amer Jahed’, ’12-JAN-1972’, EmpAddress(’12 Big Lane’, ‘Croydon’, ‘London’, ‘CR1 2TD’), Skill_VA(‘Leadership’, ‘Communication’, ‘Computing’, ‘language’, ‘Management’));

Lecture 5


Collection type: Nested Table

Step 1: Create a type for dependantsCreate or replace type EmpDependants as object(DependantName varchar2(20),DependantDOB Date); Step2: Create a table of type EmpDependants datatypeCreate or replace type EmpDependants_NT as table of

EmpDependants; Step3: Create a table Employee that uses dependant nested

tableCreate table Employee( EmployeeID number(2), Name varchar2 (30),DOB date,Dependants EmpDependants_NT)Nested table Dependants store as EmpDependants_NT_TAB;

Unit Reading Assignment

Documents

Transcript of Unit Reading Assignment