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
Relational Operators
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
179 Silva 7857 Perera 4342 Dias 7
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
179 Silva 7857 Perera 4342 Dias 7
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
4 Finance 857 7 Sales 179
DepartmentEmployeeE-No E-Name D-No
179 Silva 7857 Perera 4342 Dias 7
Emp-Info = Employee E.D-No=D.D-No Department
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
4 Finance 857 7 Sales 179
DepartmentEmployeeE-No E-Name D-No
179 Silva 7857 Perera 4342 Dias 7
Emp-InfoE-No E-Name D-No D-Name M-No
179 Silva 7 Sales 179857 Perera 4 Finance 857342 Dias 7 Sales 179
Emp-Info = Employee E.D-No=D.D-No Department
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
KapilaNimalAjithRohan
Lname
DiasPereraSilvaMendis
Student
FN
SunilKamalSamanKapilaNimal
LN
De SilvaSoysaSilvaDiasPerera
Instructor Fname
KapilaNimal
Lname
DiasPerera
Stu-Inst
Stu-Inst = Student Instructor
Intersection
16
Set Operators
Stu-Inst = Student - InstructorInst-Stu = Instructor - Student
DifferenceFname
KapilaNimalAjithRohan
Lname
DiasPereraSilvaMendis
Student
FN
SunilKamalSamanKapilaNimal
LN
De SilvaSoysaSilvaDiasPerera
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
Relational Operators
+
CourseEmployee Kodi_courses
Select + Project + N-Join
Get course names thought by lecturer ‘Dr Kodikara’ course(cno, cname, lecturer)employee(empno, ename, designation)
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
Purchase Order Relation in 0NF
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
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
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
P1P2P3P5P2P5P1P3P6P7P8
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
P1P2P3P5P2P5P1P3P6P7P8
PART-
DESC
NutBoltNailScrewBoltScrewNutNailPlugPinFuse
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
2NF - Actions Required
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
P1P2P3P5P2P5P1P3P6P7P8
PART
-QTY
105362134582
PART
-NO
P1P2P3P5P6P7P8
PART-
DESC
NutBoltNailScrewPlugPinFuse
PART
47
Purchase Order Relations in 2NF
PO-NO111112113114115116
PO-DATE
010120010101200102012001020120010301200104012001
EMP-CODE
M2S3S1M2S1S1
SUPP-NO222105111150222100
SUPP-NAME
AC StoresI HardwareBC TradingDO ServiceAC StoresLM Centre
PO
PO-NO111111111111112112113113114115116
PART-NO
P1P2P3P5P2P5P1P3P6P7P8
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
3NF - Actions Required
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
Purchase Order Relations in 3NF
PO-NO111112113114115116
PO-DATE
010120010101200102012001020120010301200104012001
EMP-CODE
M2S3S1M2S1S1
SUPP-NO222105111150222100
SUPP-NAME
AC StoresI HardwareBC TradingDO ServiceAC StoresLM CentrePO
PO-NO111111111111112112113113114115116
PART-NO
P1P2P3P5P2P5P1P3P6P7P8
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.