Download table1.column

DATABASE MANAGEMENT SYSTEM

Sub Code: 6654
T
P
C
2
6
4
Fouzia Huque
Instructor(STEP)
Computer Technology
OBJECTIVES:
To be able to acquire the
knowledge and skill in
Entity-Relationship model
of a database.
E-R DIAGRAM
E-R WvqvMÖvg - WvUv‡e‡m
mvwe©K jwRK¨vj ÷ªvKPvi‡K KZ¸‡jv
MÖvwdK¨vj wm¤^j Gi mvnv‡h¨ eY©bv
Kiv hvq| G‡`i‡K E-R WvqvMÖvg e‡j|
E-R DIAGRAM SYMBOL
Line
Ellipses
Rectangle

One to one relationship

One to many relationship

Many to one relationship

Many to Many relationship
SUMMARY OF SYMBOLS USED IN E-R
NOTATION
SUMMARY OF SYMBOLS (CONT.)
Question:
 1. What is E-R diagram
 2. Why we use E-R diagram in database?

Sub:Database Management System
Sub Code: 6654
T
P C
2
6

4
Fouzia Huque
Instructor(STEP)
Computer
Technology
CHAPTER-4
Understand the Relational
Database, Query Language
OBJECTIVES:
i) Acquire knowledge about procedural query
language.
ii) Develop skill to produce a new relation of the
relational algebra.
FUNCTIONAL OPERATION OF RELATIONAL
ALGEBRA
wi‡jkbvj Gj‡Reiv GK‡mU Acv‡ik‡bi mgš^‡q ˆZix|G Acv‡ikbmg~n GK ev `yBwU wi‡jkb‡K
BbcyU wnmv‡e MÖnY K‡i _v‡K Ges GKwU bZzb wi‡jkb‡K djvdj wnmv‡e AvDUcyU w`‡q
_v‡K|
WI‡JKBVJ GJ‡REIVI †GŠWJK ACV‡IKB¸‡JV NJ-BDbvwi Acv‡ikb
-evBbvwi Acv‡ikb
-

BDbvwi Acv‡ikb- wi‡jkbvj Gj‡Reivi †h Acv‡ikb¸‡jv GKwU gvÎ wi‡jk‡bi Dci Acv‡iU nq Zv‡K
BDbvwi Acv‡ikb e‡j| †hgb-select, project, rename
evBbvwi Acv‡ikb- `yBwU wi‡jk‡bi g‡a¨ Kz‡qwi wWRvBb Kiv n‡j Zv‡K Zv‡K
evBbvwi Acv‡ikb e‡j| G‡K †mU w_Iixii U wPý Øviv wW‡bvU Kiv nq| | †hgbUnion operation, Set Difference operation,
Cartesian product operation
AGGREGATE FUNCTIONS
Presenter: Fouzia Huque
Instructor(STEP)
Computer Technology
Mymensingh Polytechnic Institute
Aggregate Function:
GwMÖ‡MU dvskb GKvwaK gv‡bi Dci Kvh©Ki nq
Ges djvdj‡K mgwš^Z AvKv‡i ev wm‡½j AvKv‡i cÖKvk
K‡i|
 Behavior of Aggregate Functions:
Operates - on a single column
Return
- a single value.
Used only in the SELECT list and in the HAVING
clause.
BEHAVIOR OF AGGREGATE
FUNCTION CONTINUED…
Accepts:
 DISTINCT : consider only distinct values of the
argument expression.
 ALL
: consider all values including all
duplicates.
Example: SELECT COUNT( DISTINCT column_name)
TYPES OF SQL AGGREGATE
FUNCTIONS
SUM
 AVG
 MIN
 MAX
 COUNT

SUM()
Returns: The sum of the values in a specified column.
Example: Find the total/sum of the Managers salary
Query:
SELECT SUM( salary) AS sum_salary
FROM Staff
WHERE Staff.position = ‘Manager’;
Result:
sum_salary
54000.00
AVG()
Returns: The average of the values in a specified column.
Example: Find the average of the Project Managers salary .
Query:
SELECT AVG( DISTINCT salary) AS avg_salary
FROM Staff
WHERE Staff.position = ‘Project Manager’;
Result:
avg_salary
10500.00
// Error in Result
// avg_salary = 11000.00
// What is wrong?
REVISED QUERY FOR AVG()
Query:
SELECT AVG(ALL salary) AS avg_salary
FROM Staff
WHERE Staff.position = ‘Project Manager’;
Result :
avg_salary
11000.00
CAUTION: Using DISTINCT and ALL in SUM() and AVG()
MIN() AND MAX()
Returns: MIN() returns the smallest value of a column.
MAX() returns the largest value of a column.
Example: Find the minimum and maximum staff salary.
Query:
SELECT MIN( salary) AS min_salary, MAX (salary) AS
max_salary
FROM Staff;
Result: min_salary
9000.00
max_salary
30000.00
COUNT()
Returns: The number of values in the specified column.
Example: Count number of staffs who are Manager.
Query: SELECT COUNT(sno) AS sno_count
FROM Staff
WHERE Staff.position = ‘Manager’;
Result:
sno_count
2
USE OF COUNT() AND SUM()
Example: Find the total number of Managers and the sum of there
salary.
Query: SELECT COUNT( sno) AS sno_count , SUM(salary) AS
sum_salary
From Staff
WHERE Staff.position = ‘Manager’;
sno
fname
lname
salary
SL100
John
White
30000.00 Manager
SL101
Susan
Brand
24000.00 Manager
COUNT
position
SUM
COUNT() AND SUM() CONTINUED
 Result:
sno_count
sum_salary
2
54000.00
USAGE OF AGGREGATION FUNCTIONS

Use of GROUP BY

Use of HAVING
REFERENCES
Database Systems : A practical approach to
Design, Implementation, and Management by
Thomas Connolly and Carolyn Begg.
 Database System Concepts by Silbaerschatz,
Korth and Sudarshan.
 Database Modeling and Design by Toby J.
Teorey.
 http://en.wikipedia.org/wiki/Aggregate_function

CHAPTER 3: ENTITY-RELATIONSHIP
MODEL
 Entity
Sets
 Relationship Sets
 Mapping Constraints
 E-R Diagram
ENTITY SETS
A
database can be modeled as:
 a collection of entities,
 relationship among entities.
GbwUwU †mU nj Kgb KZ¸‡jv Ae‡R‡±i MÖæc
,hviv GKB ai‡Yi †cÖvcvwU© ev GUwUªweDU
†kqvi K‡i _v‡K|
Example:
specific person,
company, event, plant
KVÓGVIcustomer-id
GES †JVB GcustomerBWUWU †customerMU
name street
customercity
loan- amount
number
GbwUwU †m‡Ui †h Dcv`vb Zvi GKK ¸Yv¸Y ev ‰ewkó¨ cÖ`vb K‡i Zv‡K
ATTRIBUTES
GwUªweDU e‡j|
Example:
customer = (customer-id, customer-name,
customer-street, customer-city)
loan = (loan-number, amount)

Attribute types:
Simple and composite attributes.
 Single-valued and multi-valued attributes
 E.g. multivalued attribute: phone-numbers
 Derived attributes
 Can be computed from other attributes
 E.g. age, given date of birth

RELATIONSHIP
SETS
wewfbœ cÖKvi GbwUwU
Gi g‡a¨ m„ó G‡mvwm‡qkb‡KB wi‡jkbkxc ejv nq|
GKB RvZxq KZ¸‡jv wi‡jk‡bi †mU‡K GK‡Î wi‡jkbkxc †mU ejv nq|
Example:
Hayes
depositor
A-102
customer entityrelationship setaccount entity
 A relationship set is a mathematical relation among
n  2 entities, each taken from entity sets
{(e1, e2, … en) | e1  E1, e2  E2, …, en 
En}

where (e1, e2, …, en) is a relationship

Example:
(Hayes, A-102)  depositor
RELATIONSHIP SET BORROWER
An attribute can also be property of a relationship set.
RELATIONSHIP
SETS (CONT.)
 For instance, the depositor relationship set between
entity sets customer and account may have the attribute
access-date

MAPPING
ARDINALITIES
 WvUv‡emCg¨v‡bR‡g›U
wm‡÷‡g GKwU wi‡jkbkxc †mU Gi
gva¨‡g ‡Kvb GKwU GbwUwU †m‡Ui GKwU GbwUwU Aci
GKwU GbwUwU †m‡Ui KZ¸‡jv GbwUwUi mv‡_ G‡mvwm‡qkb
m„wó Ki‡Z cv‡i Zv †h cÖwµqvq cÖKvk Kiv nq, Zv‡K g¨vwcs
KviwWbvwjwU e‡j|
mapping cardinality must be one of the following types:
-One to one
-One to many
-Many to one
-Many to many
MAPPING CARDINALITIES
One to one
One to many
Note: Some elements in A and B may not be mapped to any
elements in the other set
MAPPING CARDINALITIES
Many to one
Many to many
Note: Some elements in A and B may not be mapped to any
elements in the other set
 Can make access-date an attribute of account, instead of a
MAPPING
CARDINALITIES
ER
DESIGN
relationship
attribute, if each AFFECT
account can
have
only one customer
 I.e., the relationship from account to customer is many to one,
or equivalently, customer to account is one to many
E-R DIAGRAMS
RELATIONSHIP SETS WITH ATTRIBUTES
We express cardinality
constraints by drawing
CARDINALITY
CONSTRAINTS
either a directed line (), signifying “one,” or an
undirected line (—), signifying “many,” between the
relationship set and the entity set.
 E.g.: One-to-one relationship:
A customer is associated with at most one loan via the
relationship borrower
 A loan is associated with at most one customer via borrower

ONE-TO-MANY RELATIONSHIP

In the one-to-many relationship a loan is associated
with at most one customer via borrower, a customer
is associated with several (including 0) loans via
borrower
MANY-TO-ONE RELATIONSHIPS

In a many-to-one relationship a loan is associated
with several (including 0) customers via borrower, a
customer is associated with at most one loan via
borrower
MANY-TO-MANY RELATIONSHIP
A customer is associated with several
(possibly 0) loans via borrower
 A loan is associated with several (possibly 0)
customers via borrower

HOW ABOUT DOING AN ER DESIGN
INTERACTIVELY ON THE BOARD?
SUGGEST AN APPLICATION TO BE
MODELED.
 A strong entity set reduces to a table with the same
REPRESENTING
ENTITY SETS AS TABLES
attributes.
Sub:Database Management System
Sub Code: 6654
T P C

2 6
4
Fouzia Huque
Instructor(STEP)
Computer
Technology
CHAPTER-4
Understand the Relational
Database, Query Language
OBJECTIVES:
i) Acquire knowledge about procedural query
language.
ii) Develop skill to produce a new relation of the
relational algebra.

BDbvwi Acv‡ikb- wi‡jkbvj Gj‡Reivi †h Acv‡ikb¸‡jv GKwU gvÎ wi‡jk‡bi Dci Acv‡iU nq Zv‡K
BDbvwi Acv‡ikb e‡j| †hgb-select, project, rename
SELECT OPERATION- ‡KVB GKWU G·‡CÖK‡BI
WCÖWW‡KB‡U CÖ`Ë KZ©‡K MG_©B K‡I GGB GKWU
UZCJ‡K WBE©VPB KIVI †Ÿ‡Î SELECT ACV‡IKB E¨ENVI KIV
NQ|
Ó
(account)
Branch_name = mirpur
G G·‡cÖkbwU wgicyi eªv‡Âi mKj GKvD›U b¤^‡ii ZvwjKv †`Lv‡e|
G·‡CÖK‡BI DJVDJWU N‡EBranch Name
Account_name
Balance
Mirpur
Mirpur
Mirpur
A-400
A-500
A-100
500
800
700
Fig: Output of Select Operation
PROJECT OPERATION- HW` †KVB WI‡JKB EV
†UWEJ N‡Z †KVB A¨VWUªWEDU‡K EV` W`‡Q CÖ‡QVRBXQ
AB¨VB¨ A¨VWUªWEDU‡K CÖ`K©B KIVI CÖ‡QVRB NQ , ZLB
CÖ‡R± ACV‡IKBWU E¨ENVI KIV NQ|
π
(account)
Account_number, balance
G·‡CÖK‡BI DJVDJWU N‡EAccount_numb
er
A-100
Balance
A-200
4000
A-505
3000
A-250
1000
A-300
2000
A-310
700
A-400
800
5000
Fig: Account_number & Balance
RENAME OPERATION- WI‡JKBVJ GK‡RE&ªV
G·‡CªK‡BI †KVB BVG _V‡K BV WEAVQ WI‡BG ACV‡IK‡BI GVA¨‡G
ZV‡`I
BVGKIY KIV NQ|
ᵨ
x
(E)
G G·‡CÖKBWU X BV‡G E G·‡CÖK‡BI DJVDJ CÖ`VB
KI‡E|
Sub:Database Management System
Sub Code: 6654
T P C

2 6
4
Fouzia Huque
Instructor(STEP)
Computer
Technology
CHAPTER-4
Understand the Relational
Database, Query Language
OBJECTIVES:
i) Acquire knowledge about procedural query
language.
ii) Develop skill to produce a new relation of the
relational algebra.
BINARY OPERATION OF
RELATIONAL ALGEBRAwi‡jkbvj Gj‡Reªvi †gŠwjK Acv‡ikb‡K `ywU fv‡M fvM
Kiv hvqK) Binary Operation L) Unary Operation
evBbvwi Acv‡ikb- `yBwU wi‡jk‡bi g‡a¨ Kz‡qwi
wWRvBb Kiv n‡j Zv‡K Zv‡K evBbvwi Acv‡ikb
e‡j| †hgb-Union operation, Set
Difference operation,
Cartesian product operation
UNION OPERATION- `YWU WI‡JK‡BI
G‡A¨ KZ‡QIX KIVI RB¨ BDWBQB ACV‡IKB E¨ENVI
KIV NQ|
π
cust_name (borrower)
U π
cust_name (depositor)
‡hme Kvógvi e¨vsK †_‡K UvKv D‡Ëvjb K‡i‡Q Ges
e¨vs‡K UvKv Rgv †i‡L‡Q Zv‡`i bvg cÖwWDm Kivi
Rb¨ Kz‡qix wWRvBb Kivi †ÿ‡Î G Acv‡ikbwU n‡q‡Q|
G KZ‡QIX‡Z BDWBQB ACV‡IKB ÒUÓ GI GVA¨‡G
`YWU WI‡JKB‡K GKWÎZ KIV N‡Q‡Q|
WW‡CVWRUI WI‡JKB, E‡IVQVI WI‡JKB GES G `YWU WI‡JK‡BI
G‡A¨ DC‡IV³ KZ‡QWI WBE©VN KI‡J CÖVß DJVDJWU N‡E
WB¤ŒIÆC -
Customer_nam Account_numb
e
er
Jasim
A-100
Yaseen
A-102
Kalam
A-105
Kader
A-205
Zafar
A-308
Alam
A-209
Fig: Depositor Relation
Customer_name
Loan_number
Joly
Poly
Mintu
Alam
Zafar
L-17
L-17
L-109
L-50
L-100
Fig: Borrower Relation
Customer_name
Jasim
Yaseen
Kalam
Kader
Zafar
Alam
Mintu
Alam
Zafar
Fig: Both Borrower customer_name &
Depositor customer_name
SET DIFFERENCE OPERATION- G
ACV‡IK‡BI GVA¨‡G AVGIV GGB UZCJ‡K LUY‡R †EI KI‡Z
CVWI HVIV GKWU WI‡JK‡B AV‡Q WKŠ‘ AB¨ WI‡JK‡B †BB|
π cust_name (depositor) -π cust_name
(borrower)
Customer_na Account_nu
me
mber
Jasim
A-100
Yaseen
A-102
Kalam
A-105
Kader
A-205
Zafar
A-308
Alam
A-209
Fig: Depositor
Relation
Customer_name
Jasim
Yaseen
Kalam
Kader
Zafar
Alam
Mintu
Alam
Zafar
Fig: Both Borrower customer_name &
Depositor
customer_name
DC‡IV³ `YWU †UWEJ ABYMV‡I HVIV ÏAY UVKV RGV †I‡L‡Q WKŠ‘
†JVB †BQWB ZV‡`I BVG LUY‡R †EI KIVI RB¨ KZ‡QWII DJVDJ N‡E
WB¤ŒIÆC-
Customer_name
Jasmin
Yaseen
Kalam
Kader
Fig: hviv ïay UvKv Rgv †i‡L‡Q wKš‘ †jvb †bqwb Zv‡`i bvg
ó branch_name= ÒDhanmondiÓ (borrower X loan)
G KZ‡QWIWU WBE©VN KIV N‡J AVBGWÛ EªVÂ
N‡Z †HME KVÓGVI †JVB WB‡Q‡Q ZV‡`I BVG
CÖWWDM N‡E|
CARTESIAN PRODUCT
OPERATION- `YWU WI‡JK‡BI N‡Z CÖVß
BBDI‡GKB‡K HY³ KIVI RB¨ KV‡Z©MXQ †CÖVWV±
ACV‡IKB E¨ENVI KIV NQ|
OBJECTIVES

In this chapter, the student will learn:
About distributed database management systems
(DDBMSs) and their components
 How database implementation is affected by different
levels of data and process distribution
 How transactions are managed in a distributed
database environment

82
FIGURE 12.1 - CENTRALIZED DATABASE
MANAGEMENT SYSTEM
83
CENTRALIZED DATABASE SYSTEMS
†h WvUv‡em wm‡¯§ GKwUgvÎ Kw¤úDUv‡i Pj‡Z mÿg Ges GKB mg‡q ïay
GKRb e¨enviKvwi wm‡÷g‡K e¨envi Ki‡Z cv‡i , Ab¨ †Kvb Kw¤úDUvi
wm‡÷‡gi mv‡_ B›Uv‡i± Ki‡Z cv‡i bv Zv‡K Centralized
Database Systems e‡j|
84
DISTRIBUTED PROCESSING AND
DISTRIBUTED DATABASES

•
Distributed processing: Database’s logical
processing is shared among two or more
physically independent sites via network
Distributed database: Stores logically
related database over two or more
physically independent sites via computer
network

Database fragments: Database composed of many
parts in distributed database system
85
CHARACTERISTICS OF DISTRIBUTED
MANAGEMENT SYSTEMS
Application
interface
Validation
Transformation
Query
optimization
Mapping
I/O interface
Formatting
Security
Backup and
recovery
DB
administration
Concurrency
control
Transaction
management
86
FIGURE 12.4 - A FULLY DISTRIBUTED
DATABASE MANAGEMENT SYSTEM
87
FIGURE 12.6 - SINGLE-SITE PROCESSING,
SINGLE-SITE DATA (CENTRALIZED)
88
FIGURE 12.7 - MULTIPLE-SITE
PROCESSING, SINGLE-SITE DATA
DISTRIBUTED DATABASE DESIGN
Data fragmentation
• How to partition database into fragments
Data replication
• Which fragments to replicate
Data allocation
• Where to locate those fragments and replicas
90
DISPLAYING DATA
FROM MULTIPLE
TABLES
OBJECTIVES

After completing this lesson, you should be able
to do the following:
Write SELECT statements to access data from more
than one table using equality and nonequality joins
 View data that generally does not meet a join
condition by using outer joins
 Join a table to itself

OBTAINING
DATA FROMDEPT
MULTIPLE TABLES
EMP
EMPNO
-----7839
7698
...
7934
ENAME
----KING
BLAKE
... DEPTNO
... -----...
10
...
30
MILLER ...
10
DEPTNO
-----10
20
30
40
EMPNO DEPTNO LOC
----- ------- -------7839
10 NEW YORK
7698
30 CHICAGO
7782
10 NEW YORK
7566
20 DALLAS
7654
30 CHICAGO
7499
30 CHICAGO
...
14 rows selected.
DNAME
---------ACCOUNTING
RESEARCH
SALES
OPERATIONS
LOC
-------NEW YORK
DALLAS
CHICAGO
BOSTON
WHAT IS A JOIN?

Use a join to query data from more than one
table.
SELECT
FROM
WHERE
table1.column, table2.column
table1, table2
table1.column1 = table2.column2;
Write the join condition in the WHERE clause.
 Prefix the column name with the table name when
the same column name appears in more than one
table.

CARTESIAN PRODUCT

A Cartesian product is formed when:
A join condition is omitted
 A join condition is invalid
 All rows in the first table are joined to all rows in the
second table


To avoid a Cartesian product, always include a valid
join condition in a WHERE clause.
GENERATING
EMP (14 rows) A CARTESIAN
DEPT P
(4 RODUCT
rows)
EMPNO
-----7839
7698
...
7934
ENAME
----KING
BLAKE
... DEPTNO
... -----...
10
...
30
MILLER ...
“Cartesian
product:
14*4=56 rows”
10
DEPTNO
-----10
20
30
40
DNAME
---------ACCOUNTING
RESEARCH
SALES
OPERATIONS
ENAME
DNAME
--------------KING
ACCOUNTING
BLAKE
ACCOUNTING
...
KING
RESEARCH
BLAKE
RESEARCH
...
56 rows selected.
LOC
-------NEW YORK
DALLAS
CHICAGO
BOSTON
TYPES OF JOINS
Equijoin
Non-equijoin
Outer join
Self join
WHAT IS AN EQUIJOIN?
EMP
DEPT
EMPNO ENAME
DEPTNO
------ ------- ------7839 KING
10
7698 BLAKE
30
7782 CLARK
10
7566 JONES
20
7654 MARTIN
30
7499 ALLEN
30
7844 TURNER
30
7900 JAMES
30
7521 WARD
30
7902 FORD
20
7369 SMITH
20
...
14 rows selected.
Foreign key
DEPTNO
------10
30
10
20
30
30
30
30
30
20
20
...
14 rows
DNAME
---------ACCOUNTING
SALES
ACCOUNTING
RESEARCH
SALES
SALES
SALES
SALES
SALES
RESEARCH
RESEARCH
selected.
Primary key
LOC
-------NEW YORK
CHICAGO
NEW YORK
DALLAS
CHICAGO
CHICAGO
CHICAGO
CHICAGO
CHICAGO
DALLAS
DALLAS
RETRIEVING RECORDS
WITH EQUIJOINS
SQL> SELECT
2
3 FROM
4 WHERE
emp.empno, emp.ename, emp.deptno,
dept.deptno, dept.loc
emp, dept
emp.deptno=dept.deptno;
EMPNO ENAME DEPTNO DEPTNO LOC
----- ------ ------ ------ --------7839 KING
10
10 NEW YORK
7698 BLAKE
30
30 CHICAGO
7782 CLARK
10
10 NEW YORK
7566 JONES
20
20 DALLAS
...
14 rows selected.
QUALIFYING AMBIGUOUS
COLUMN NAMES
Use table prefixes to qualify column names that are
in multiple tables.
 Improve performance by using table prefixes.
 Distinguish columns that have identical names but
reside in different tables by using column aliases.

ADDITIONAL SEARCH CONDITIONS
USING THE AND OPERATOR
EMP
EMPNO ENAME
DEPTNO
------ ------- ------7839 KING
10
7698 BLAKE
30
7782 CLARK
10
7566 JONES
20
7654 MARTIN
30
7499 ALLEN
30
7844 TURNER
30
7900 JAMES
30
7521 WARD
30
7902 FORD
20
7369 SMITH
20
...
14 rows selected.
DEPT
DEPTNO DNAME
------ --------10 ACCOUNTING
30 SALES
10 ACCOUNTING
20 RESEARCH
30 SALES
30 SALES
30 SALES
30 SALES
30 SALES
20 RESEARCH
20 RESEARCH
...
14 rows selected.
LOC
-------NEW YORK
CHICAGO
NEW YORK
DALLAS
CHICAGO
CHICAGO
CHICAGO
CHICAGO
CHICAGO
DALLAS
DALLAS
USING TABLE ALIASES

Simplify queries by using table aliases.
SQL> SELECT emp.empno, emp.ename, emp.deptno,
2
dept.deptno, dept.loc
3 FROM
emp, dept
4 WHERE emp.deptno=dept.deptno;
SQL> SELECT e.empno, e.ename, e.deptno,
2
d.deptno, d.loc
3 FROM
emp e, dept d
4 WHERE e.deptno=d.deptno;
JOINING MORE THAN TWO TABLES
CUSTOMER
NAME
CUSTID
---------------JOCKSPORTS
100
TKB SPORT SHOP
101
VOLLYRITE
102
JUST TENNIS
103
K+T SPORTS
105
SHAPE UP
106
WOMENS SPORTS
107
...
...
9 rows selected.
ORD
CUSTID
ORDID
------- ------101
610
102
611
104
612
106
601
102
602
ITEM
106
604
ORDID ITEMID
106
605
------ ------...
610
3
21 rows selected.
611
1
612
1
601
1
602
1
...
64 rows selected.
NON-EQUIJOINS
EMP
EMPNO ENAME
SAL
------ ------- -----7839 KING
5000
7698 BLAKE
2850
7782 CLARK
2450
7566 JONES
2975
7654 MARTIN
1250
7499 ALLEN
1600
7844 TURNER
1500
7900 JAMES
950
...
14 rows selected.
SALGRADE
GRADE LOSAL HISAL
----- ----- -----1
700
1200
2
1201
1400
3
1401
2000
4
2001
3000
5
3001
9999
“salary in the EMP
table is between
low salary and high
salary in the SALGRADE
table”
RETRIEVING RECORDS
WITH NON-EQUIJOINS
SQL>
2
3
4
SELECT
FROM
WHERE
BETWEEN
e.ename, e.sal, s.grade
emp e, salgrade s
e.sal
s.losal AND s.hisal;
ENAME
SAL
GRADE
---------- --------- --------JAMES
950
1
SMITH
800
1
ADAMS
1100
1
...
14 rows selected.
OUTER JOINS
EMP
ENAME
----KING
BLAKE
CLARK
JONES
...
DEPT
DEPTNO
-----10
30
10
20
DEPTNO
-----10
30
10
20
...
40
DNAME
---------ACCOUNTING
SALES
ACCOUNTING
RESEARCH
OPERATIONS
No employee in the
OPERATIONS department
OUTER JOINS
You use an outer join to also see rows that do not
usually meet the join condition.
 Outer join operator is the plus sign (+).

SELECT table1.column, table2.column
FROM
table1, table2
WHERE table1.column(+) = table2.column;
SELECT table1.column, table2.column
FROM
table1, table2
WHERE table1.column = table2.column(+);
USING OUTER JOINS
SQL>
2
3
4
SELECT
FROM
WHERE
ORDER BY
e.ename, d.deptno, d.dname
emp e, dept d
e.deptno(+) = d.deptno
e.deptno;
ENAME
DEPTNO DNAME
---------- --------- ------------KING
10 ACCOUNTING
CLARK
10 ACCOUNTING
...
40 OPERATIONS
15 rows selected.
SELF JOINS
EMP (WORKER)
EMPNO
----7839
7698
7782
7566
7654
7499
ENAME
-----KING
BLAKE
CLARK
JONES
MARTIN
ALLEN
MGR
---7839
7839
7839
7698
7698
EMP (MANAGER)
EMPNO ENAME
----- -------7839
7839
7839
7698
7698
KING
KING
KING
BLAKE
BLAKE
“MGR in the WORKER table is equal to EMPNO in the
MANAGER table”
JOINING A TABLE TO ITSELF
SQL> SELECT worker.ename||' works for '||manager.ename
2 FROM
emp worker, emp manager
3 WHERE worker.mgr = manager.empno;
WORKER.ENAME||'WORKSFOR'||MANAG
------------------------------BLAKE works for KING
CLARK works for KING
JONES works for KING
MARTIN works for BLAKE
...
13 rows selected.
SUMMARY
SELECT
FROM
WHERE
Equijoin
table1.column, table2.column
table1, table2
table1.column1 = table2.column2;
Non-equijoin
Outer join
Self join
PRACTICE OVERVIEW



Joining tables using an equijoin
Performing outer and self joins
Adding conditions