1 Relational Operators. 2 Relational operations are specified using Structured Query Language (SQL) -- a standard for relational database access

1

Relational Operators

2

Relational Operators Relational operations are specified using

Structured Query Language (SQL) -- a standard for relational database access.

Relational operations are set level, meaning that they operate on multiple rows, rather than one record at a time.

SQL is non-procedural, meaning that the user specifies what data is to be retrieved rather than how to retrieve the data.

Properties

3


Each operator takes one or more tables as it operand(s) and produces a table as its result.

Any column value in a table can be referenced, not just keys.

Operations can be combined to form complex operations.

Properties

4

Operations on a DBMSCan be specified using Relational Algebra operations (what we learn

now) Are usually divided into two groups

• Set theory operations• Operations specifically developed for relational

databases

But are considered too technical for ordinary users, hence the birth of SQL

They are written as a sequence of steps, when executed produce the results

Hence the user must give say ”how” and not “what” is needed

5

Operations on a DBMSCan be specified using Relational calculus

• Another formal query language which gives ‘what’ is required, and not how.

• Eg:- {t.FNAME,t.LNAME|EMPLOYEE(t) and t.SALARY>500}

SELECT T.FNAME, T.LNAMEFROM EMPLOYEE AS TWHERE T.SALARY>500

SQL

6

Relational OperatorsSelection: horizontal subset of a table

EmployeeE-No E-Name D-No

179 Silva 7857 Perera 4342 Dias 7

Sales EmployeeE-No E-Name D-No

179 Silva 7342 Dias 7

Sales-Emp = D-No=7 (Employee)

7

Projection: vertical subset of a table

EmployeeE-No E-Name D-No


Employee NamesE-No E-Name

179 Silva 857 Perera342 Dias

Emp-Names = E-No, E-Name (Employee)

8

Cartesian Product: Creates a single table from two tables.

D-No D-Name M-No

4 Finance 857 7 Sales 179

DepartmentEmployeeE-No E-Name D-No


Emp-InfoE-No E-Name D-No D-No D-Name M-No

179 Silva 7 4 Finance 857857 Perera 4 4 Finance 857342 Dias 7 4 Finance 857 179 Silva 7 7 Sales 179857 Perera 4 7 Sales 179342 Dias 7 7 Sales 179

Emp-Info = Employee E.D-No=D.D-No Department

9

Join: Creates a single table from two tables.

D-No D-Name M-No





EquiJoinEmp-Info

E-No E-Name D-No D-No D-Name M-No

179 Silva 7 7 Sales 179857 Perera 4 4 Finance 857342 Dias 7 7 Sales 179

10

Joins…

The most common join is where we only use the ‘equal’ operator , and is known as equijoin.

We can use other operator (=,<,>,<=, etc…) for the join condition also

The natural join (*) can be used to get rid of the additional attribute in an equijoin condition.

11

Joins…

In a natural join only the matching tuples are displayed. The ‘left outer join’ and ‘right outer join’ and ‘full outer join’can be used to find even non matching tuples

12

Natural Join: Creates a single table from two tables.

D-No D-Name M-No




Emp-InfoE-No E-Name D-No D-Name M-No

179 Silva 7 Sales 179857 Perera 4 Finance 857342 Dias 7 Sales 179


13

Relational OperatorsOther operators

UnionIntersection

Difference

Set operations from mathematical set theory

14

Set Operators

Union

Fname

KapilaNimalAjithRohan

Lname

DiasPereraSilvaMendis

Student

FN

SunilKamalSamanKapilaNimal

LN

De SilvaSoysaSilvaDiasPerera

Instructor

Fname

KapilaNimalAjithRohanSunilKamalSaman

Lname

DiasPereraSilvaMendisDe SilvaSoysaSilva

Stu-Inst

Stu-Inst = Student Instructor

15

Set OperatorsFname


Lname


Student

FN


LN


Instructor Fname

KapilaNimal

Lname

DiasPerera

Stu-Inst

Stu-Inst = Student Instructor

Intersection

16

Set Operators

Stu-Inst = Student - InstructorInst-Stu = Instructor - Student

DifferenceFname


Lname


Student

FN


LN


Instructor

Fname

AjithRohan

Lname

SilvaMendis

Stu-Inst

Fname

SunilKamalSaman

Lname

De SilvaSoysaSilva

Inst-Stu

17

Complete Set of Relational Algebra Operations

It has been proved that {, , , , } is a complete set.

Any other relational algebra operator can be expressed in terms of the above operators.

E.g. R S = (R S) ( ( R S) (S R) )

18

Division operator

Rename operator

R(FirstName,LastName,Salary) = Fname,Lname,Sal (Employee)

Can be useful for set related operations.

19

Relational OperatorsBecause the result of every relational operation is a table, operators can be combined to create complex operations. For example:

Select + Project

+

A B A B

Project + Select + Join

20

Emp_Kodi eneme=’Dr. Kodikara’ Employee

Courses cname, lecturer Course

Kodi_courses Emp_Kodi * empno = lecture Courses


+

CourseEmployee Kodi_courses

Select + Project + N-Join

Get course names thought by lecturer ‘Dr Kodikara’ course(cno, cname, lecturer)employee(empno, ename, designation)

21

Logical Database Design - Normalisation

22

Normalisation

Is derivation of data as a set of

Non-Redundant,

Consistent and

Inter-Dependent Relations

23

Normalisation

Normalisation is a set of data design standards.

It is a process of decomposing unsatisfactory relations into smaller relations.

Like entity–relationship modelling were developed as part of database theory.

24

Normalisation - Advantages

Reduction of data redundancy within tables:

- Reduce data storage space- Reduce inconsistency of data- Reduce update cost- Remove many-to-many relationship- Improve flexibility of the system

25

Normalisation - Disadvantages

Reduction in efficiency of certain data retrieval as relations may be joined during retrieval.

- Increase join- Increase use of indexes: storage

(keys)- Increase complexity of the system

26

Normal Forms

A state of a relation that results from applying simple rules regarding functional dependencies (or relationships between attributes) to that relation.

0NF multi-valued attributes exists1NF any multi-valued attributes have been removed2NF any partial functional dependencies have been

removed3NF any transitive dependencies have been removed

27

Functional Dependencies and Keys

Functional dependency:A constraint between two attributes or two sets of attributesThe functional dependency of B on A is represented by an arrow: A Be.g.

NID (SSN) Name, Address, Birth date

VID Make, Model, Colour

ISBN Title, First Author

28

Functional Dependencies and Keys

Functional dependency (definition)

For any relation R (e.g. book), attribute B (e.g. title) is functionally dependent on attributes A (e.g. ISBN), if for every valid instance of A (e.g. 981-235-996-6), that value of A uniquely determines the value of B (e.g. Modern Database Management)

29

Input for the Normalisation Process

Database Design process (phase 1)

data requirements and data analysis

entity types (e.g. Supplier, Order)

attributes describing each entity type with its meaning (e.g. supplier name and part name)

attributes relationships to other attributes. (e.g.supplier no of Supplier to supplier no

of purchase Order)

30

Purchase Order - Attribute Analysis

ATTRIBUTE

PO-NO

PO-DATEEMP-CODE

SUPP-NOSUPP-NAMEPART-NOPART-DESCPART-QTY

TYPE

N

DC

NCNCN

LEN-GTH

3

82

3202

102

DESCRIPTION

Unique purchase order (PO) number. Many parts can be ordered in one PODDMMYYYY date when PO writtenUnique code of employee who wrote the POUnique number assigned to supplierSupplier nameUnique number assigned to each partPart descriptionQuantity of parts ordered in given PO

Key PO-NO

31

Purchase Order Relation in 0NF

PO-NO

111

112

113

114115116

PO-DATE

01012001

01012001

02012001

020120010301200104012001

EMP-

CODE

M2

S3

S1

M2S1S1

SUPP

-NO

222

105

111

150222100

SUPP-

NAME

AC Stores

I Hardware

BC Trading

DO ServiceAC StoresLM Centre

PART

-NO

P1P2P3P5P2P5P1P3P6P7P8

PART-

DESC

NutBoltNailScrewBoltScrewNutNailPlugPinFuse

PART

-QTY

105362134582

32

Normalisation Process

0NF Relations

1NF Relations

2NF Relations

3NF RelationsOptimised Relations

Apply a set of normalisation rules to all the attributes of the entity types identified in the data requirement step.

33

Output of the Normalisation Process

A list of normalised entity types in at least third normal form (3NF), such that all non-key attributes of each entity type fully depend on the whole key and nothing but the key

34

First Normal Form - 1NF

A relation is in First Normal Form (1NF) if ALL its attributes are ATOMIC.

ie. If there are no repeating groups.

If each attribute is a primitive.

e.g. integer, real number, character string,

but not lists or sets

non-decomposable data item

single-value

35


PO( PO-NO, PO-DATE, EMP-CODE, SUPP-NO, SUPP-NAME, PARTS-ORDERED{PART-NO, PART-DESC, PART-QTY})

Within a single purchase order we could find several part numbers, part descriptions and part quantities. Hence, parts ordered can be decomposed.

36


PO-NO

111

112

113

114115116

PO-DATE

01012001

01012001

02012001

020120010301200104012001

EMP-

CODE

M2

S3

S1

M2S1S1

SUPP

-NO

222

105

111

150222100

SUPP-

NAME

AC Stores

I Hardware

BC Trading

DO ServiceAC StoresLM Centre

PART

-NO


PART-

DESC


PART

-QTY

105362134582

37

First Normal Form - 1NF

1NF deals with the shape of a record type

All occurrences of a record type must contain the same number of fields

A relational schema is at least in 1NF

38

1NF - Actions Required

1) Examine for repeat groups of data

2) Remove repeat groups from relation

3) Create new relation(s) to include repeated data

4) Include key of the 0NF to the new relation(s)

5) Determine key of the new relation(s)

39

Purchase Order Relations in 1NF

PO-NO111112113114115116

PO-DATE

010120010101200102012001020120010301200104012001

EMP-CODE

M2S3S1M2S1S1

SUPP-NO222105111150222100

SUPP-NAME

AC StoresI HardwareBC TradingDO ServiceAC StoresLM Centre

PO

PO-NO111111111111112112113113114115116

PART-NO


PART-DESCNutBoltNailScrewBoltScrewNutNailPlugPinFuse

PART-QTY

105362134582

PO-PART

40

1. INSERT PROBLEMcannot know available parts until an order is placed (e.g. P4 is bush)

2. DELETE PROBLEMloose information of part P7 if we cancel purchase order 115 (i.e. Delete PO-PART for Part No P7)

3. UPDATE PROBLEM:to change description of Part P3 we need to change every tuple in PO-PART containing Part No P3

Problems - 1NF

41

Second Normal Form - 2NF

A relation is in 2NF if it is in 1NF and every non-key attribute is dependent on the whole key

i.e. Is not dependent on part of the key only.

42

PO-PART Relation (Parts Ordered)in 1NF

PO-PART( PO-NO, PART-NO, PART-DESC, PART-QTY)

Part Description is depended only on Part No, which is part of the key of PO-PART.

43

Parts Ordered Relation in 1NF

PO-NO

111111111111112112113113114115116

PART

-NO


PART-

DESC


PART

-QTY

105362134582

44

Second Normal Form - 2NF

Deals with the relationship between non-key and key fields

A non-key field cannot be a fact about a subset of a key

It is relevant when the key is composite, i.e. consists of several fields

45


If entity has a concatenated key

1) Check each attribute against the whole key

2) Remove attribute and partial key to new relation

3) Optimise relations

46

Parts Ordered Relations in 2NFPO-PART

PO-NO

111111111111112112113113114115116

PART

-NO


PART

-QTY

105362134582

PART

-NO

P1P2P3P5P6P7P8

PART-

DESC

NutBoltNailScrewPlugPinFuse

PART

47


PO-NO111112113114115116

PO-DATE

010120010101200102012001020120010301200104012001

EMP-CODE

M2S3S1M2S1S1

SUPP-NO222105111150222100

SUPP-NAME

AC StoresI HardwareBC TradingDO ServiceAC StoresLM Centre

PO

PO-NO111111111111112112113113114115116

PART-NO


PART-QTY

105362134582

PO-PARTPART PAR

T-NOP1P2P3P5P6P7P8

PART-DESCNutBoltNailScrewPlugPinFuse

48

1. INSERT PROBLEMcannot know available suppliers until an order is placed (e.g. 200 is hardware stores)

2.DELETE PROBLEMloose information of supplier 100 if we cancel purchase order 116 (i.e. Delete PO for Supplier No 100)

3.UPDATE PROBLEMto change name of Supplier 222 we need to change every tuple in PO containing Supplier No 222

Problems - 2NF

49

Third Normal Form - 3NF

A relation is in 3NF if it is in 2NF and each non-key attribute is only dependent on the whole key, and not dependent on any non-key attribute.

i.e. no transitive dependencies

50

PO Relation in 2NF

PO( PO-NO, PO-DATE, EMP-CODE, SUPP-NO, SUPP-NAME)

Supplier name is a non-key field depended on another non-key field (i.e. the supplier no) in addition to be depended on the key purchase order no

51

Third Normal Form - 3NF

Deals with the relationship between non-key fields

A non-key field cannot be a fact about another non-key field

52


1) Check each non-key attribute for dependency against other non-key fields

2) Remove attribute depended on another non-key attribute from relation

3) Create new relation comprising the attribute and non-key attribute which it depends on

4) Determine key of new relation

5) Optimise

53

PO and SUPPLIER Relations in 3NF

EMP-

CODE

M2S3S1M2S1S1

PO-NO

111112113114115116

PO-DATE

010120010101200102012001020120010301200104012001

SUPP

-NO

222105111150222100

PO

SUPP

-NO

100105111150222

SUPP-

NAME

LM CentreI HardwareBC TradingDO ServiceAC Stores

SUPPLIER

54


PO-NO111112113114115116

PO-DATE

010120010101200102012001020120010301200104012001

EMP-CODE

M2S3S1M2S1S1

SUPP-NO222105111150222100

SUPP-NAME

AC StoresI HardwareBC TradingDO ServiceAC StoresLM CentrePO

PO-NO111111111111112112113113114115116

PART-NO


PART-QTY

105362134582

PO-PARTPART

PART-NO

P1P2P3P5P6P7P8

PART-DESCNutBoltNailScrewPlugPinFuse

SUPP-NO222105111150222100

SUPPLIER

55

Further Normalization

BCNF or Boyce–Codd Normal form 4th Normal form 5th Normal form

In a normal situation normalization up-to 3NF is quite sufficient.Certain relations may even be de-normalized on account of efficiency. The Normalizations which are discussed next are not practically enforced most of the time.

But a relation in 3NF does not guarantee that all anomalies have been removed, hence the additional normalizations.

Documents

1 Relational Operators. 2 Relational operations are specified using Structured Query Language (SQL) -- a standard for relational database access