Database management
• Antal Bejczy Center for Intelligent Robotics
• 82 Kiscelli str.
Requirements
•
•
•
•
•
Excercise for the semester
3 lab tests 50%
2 tests – suggested oral exam grade (if > 3)
Oral exam 50%
Moodle: elearning.uni-obuda.hu
Brief contents
•
•
•
•
•
•
•
Information processing
Database management systems
Relational data model
Basic terms
Designing a database
Normalization
Relation decomposition
Information processing
Difficulties
Advantages of computers
Structure of the DBMS
• The user has permission for the smaller part
of the DB: View
View1
View2
Conceptual model
Implementation model
Physical model
View3
Example: university DB
• Conceptual model:
– Student (sid: string, login: string, age: integer,
cumulative average: real)
– Subject (subid: string, sname: string, credit:
integer)
– Registration (sid: string, subid: string, mark:
integer)
Example: university DB
• Implementation model:
– Create table subject
(subid varchar(10) not null primary key,
sname varchar (50) not null,
credit int not null
)
• Physical model: files containing unsorted data
• View: Teachers can see info about their own
courses
Relational data model
• Relation:
table
+constraints
• Column headers:
attribute/domain
• Rows:
data records/tuples
• Database:
Set of tables
Relationship
• 1:1 (one to one) relationship
– Person&ID number
– Husband&wife
Rare in real world
Relationship
• 1:N (one to many) relationship:
– Biological Mother&Children
– Document&Paragraphs
Person
Owns
Car
Relationship
• M:N (many to many) relationship
– Actor&plays
– Teachers&Students
Actor
Acts
Play
Keys as frame
• Basic terms: Primary key (Person:ID), foreign
key(Owns:Owner’s ID), simple/composite
key(Person:ID/Owns:Owner ID+Car’s plate)
• System of keys=frame of database
Person
Owns
Car
Basic terms
• Elements: 𝑎, 𝑏, 𝑐
• Sets: 𝐴, 𝐵, 𝐶
• Defining a set:
– enumeration: 𝐴={𝑎, 𝑏, 𝑐}, thus 𝑎∈𝐴
– rules: 𝐵={𝑥|𝑥≥100∧𝑥≤1000}
• Subset: 𝐴⊂𝐵, ha ∀𝑎∈𝐴:𝑎∈𝐵
• Ordered set (vector): 𝑞=〈𝑎, 𝑏, 𝑐〉
• Descartes-multiplication: 𝐴×𝐵, e.g. 𝐴={0,1},
𝐵={𝑎,𝑏}, then 𝐴×𝐵={〈0,𝑎〉,〈0,𝑏〉,〈1,𝑎〉,〈1,𝑏〉}
Attributes, dependencies, keys
• Attributes: sets A, B, C
• Set of attributes: 𝑄 = 𝐴, 𝐵, 𝐶
• Dependency: function 𝑓 = 𝐴, 𝐵 → 𝐶, 𝐷, 𝐸
„others” {C,D,E} depend on the key {A,B}
• Key: A,B
– Simple
– Composite
• Secondary attributes: C, D, E
(De)composition - Example
•
•
•
•
•
fworker={name, institute}{salary, room}
Key: name, institute
Secondary: salary, room
fworker={name, institute}{salary}
fworker={name, institute}{room}
Operation with dependecies
• Unify: left hand side is equivalent
&
• Composition
fworker={name, institute}{salary, room}
fworker={name, institute}{salary}
fworker={name, institute}{room}
Anomalies - Example
• Relation={product_code, product_name,
product_description,price,supplyer,
supplyer_address}
• Update anomaly: change in the address,
modify it everywhere
• Insertion anomaly: new product without price
• Deletion anomaly: lost contact with supplyer.
Shall we delete the products also?
Example no. 2
• Teachers(ID, name,address,telephone,
course_name, semester/hours, requirements)
• Two entity sets in one relation
• Solution: divide into relations
– Teachers(ID,name,address,telephone)
– Courses(course_name,semester/hours,requireme
nts)
– Teach (teacher_id,course_name)
Example – 1 NF
Name
T. A. Várkonyi
Field of research
Mathematics,
Computer science
Name
Field of research
T. A. Várkonyi
Mathematics
T. A. Várkonyi
Computer science
2 NF
• Example: Order(date, buyer_ID, product_ID,
product_no,product_description, comments)
• key: date,buyer_ID,product_ID
• product_ID  product_description
• Solution: create a new table for the products
(product_ID,product_description)
3 NF
• Example: soft_drink(name,bottle_type,
manufacturer_name,manufacturer_address)
• Key: name,bottle_type
• Manufacturer_namemanufacturer_address
BCNF (Boyce-Codd NF)
• Example: let’s assume that every teacher has
only one course to teach
• Neptun(teacher,year,semester,course,headcou
nt)
• Keys:
– teacher,year,semester
– course,year,semester
Teacher
Teacher
Year
Semester
Course
Headcount
TA Varkonyi
2014/2015
1
Database m.
25
Zsolt Szabo
2014/2015
1
Database lab
25
TA Varkonyi
2014/2015
2
Database m.
25
Zsolt Szabo
2014/2015
2
Database lab
25
TA Varkonyi
2014/2015
3
Database m.
25
Solution
Year
Semester
Course
Headcount
2014/2015
1
Database m.
25
2014/2015
1
Database lab
25
2014/2015
2
Database m.
25
2014/2015
2
Database lab
25
2014/2015
3
Database m.
25
Teacher
Year
Course
TA Varkonyi
2014/2015
Database m.
Zsolt Szabo
2014/2015
Database lab
TA Varkonyi
2014/2015
Database m.
Zsolt Szabo
2014/2015
Database lab
TA Varkonyi
2014/2015
Database m.
Conclusions
• If a relation is in 0 NF (can be put in tables)
and does not contain multiple field then it is in
at least 1 NF
• If a relation is in 1 NF and does not contain
partial functional dependency then it is in at
least 2 NF
• If a relation is in 2 NF and does not contain
transitive functional dependency then it is in
at least 3 NF
Finding the key
• Attribute set {𝐴1 , 𝐴2 , … , 𝐴𝑛 } is key-candidate
of relation 𝑅 𝐴1 , 𝐴2 , … , 𝐴𝑛 , 𝐵1 , 𝐵2 , … , 𝐵𝑘 , if
– 𝐴1 , 𝐴2 , … , 𝐴𝑛 → 𝐵1 , 𝐵2 , … , 𝐵𝑘 functional
dependency stands
– There is no subset of {𝐴1 , 𝐴2 , … , 𝐴𝑛 } that could
determine the other attributes of relation R.
Closure of an attribute set
• To find new relationships
• Closure of attribute set 𝑋 = {𝐴1 , 𝐴2 , … , 𝐴𝑛 }
based on 𝑆 functional dependency set:
– 𝑋: = {𝐴1 , 𝐴2 , … , 𝐴𝑛 }
– Let’s find dependency 𝐵1 , 𝐵2 , … , 𝐵𝑚 → 𝐶 from 𝑆
so that 𝐵1 , 𝐵2 , … , 𝐵𝑚 ∈ 𝑋 but 𝐶 ∉ 𝑋. So let’s
extend: 𝑋 ≔ 𝑋 ∪ 𝐶
– Repeat this until there is no possibility to extend
X.
Armstrong axioms
• To find new dependencies in a relation.
• , , and  are attribute sets
• A functional dependency is reflexive:
If    then   (a key defines its own
attributes)
• A funtional dependency is transitive:
If  and  then 
• A funtional dependency is augmentive:
If  then {,}{,}
Dependency preservation
• After decomposition, the originial
dependencies can be infered from the new
relation’s dependencies.
• Def.: Decomposition 𝑅1 , 𝑅2 , … , 𝑅𝑘 of relation
R preserves dependency according to
dependency set F, if we can logically infer F
from the union of the dependencies of
𝑅1 , 𝑅2 , … , 𝑅𝑘 (e.g. by Armstrong axioms).
Preserve dependencies - check
Wrong example
• 𝑅 = (𝐴, 𝐵, 𝐶) , 𝐹 = {𝐴 → 𝐵, 𝐵 → 𝐶}
• Decomposition of 𝑅: 𝑅1 = 𝐴, 𝐶 , 𝑅2 = (𝐵, 𝐶)
• Non-trivial dependency in 𝑅1 : 𝐹1 = {𝐴 → 𝐶}
(transitive, see Amstrong axioms)
• Non-trivial dependency in 𝑅2 : 𝐹2 = {𝐵 → 𝐶}
• By uniting dependency sets 𝐹1 and 𝐹2 : {𝐵 →
𝐶, 𝐴 → 𝐶}. 𝐴 → 𝐵 cannot be infered!
Good example
•
•
•
•
•
𝑅 = (𝐴, 𝐵, 𝐶) , 𝐹 = {𝐴 → 𝐵, 𝐵 → 𝐶}
Decomposition of 𝑅: 𝑅1 = 𝐴, 𝐵 , 𝑅2 = (𝐵, 𝐶)
Non-trivial dependency in 𝑅1 : 𝐹1 = {𝐴 → 𝐵}
Non-trivial dependency in 𝑅2 : 𝐹2 = {𝐵 → 𝐶}
By uniting dependency sets 𝐹1 and 𝐹2 : {𝐴 →
𝐵, 𝐵 → 𝐶}, original is gained: 
Example - BCNF
• 𝑅(City,Street,Postal code)= 𝑅(𝐶, 𝑆, 𝑃)
• 𝐹 = {𝐶, 𝑆 → 𝑃; 𝑃 → 𝐶}
– not BCNF because key C depends on not-key P
•
•
•
•
•
Decomposition of 𝑅 to BCNF: 𝑅1 𝑆, 𝑃 , 𝑅2 (𝐶, 𝑃)
Lossless (see the proof later)
Non-trivial dependency in 𝑅1 : 𝐹1 = {}
Non-trivial dependency in 𝑅2 : 𝐹2 = {𝑃 → 𝐶}
First dependency is lost.
Lossless - check
Example – information loss
𝑅
Model Name
Price
Category
a11
100
Canon
s20
200
Nikon
a70
150
Canon
𝑅1
𝑅2
Model Name
Category
Price
Category
a11
Canon
100
Canon
s20
Nikon
200
Nikon
a70
Canon
150
Canon
Recomposition
𝑅1 ∪ 𝑅2
𝑅
Model Name
Price
Category
a11
100
Canon
a11
150
Canon
s20
200
Nikon
a70
100
Canon
a70
150
Canon
Model Name
Price
Category
a11
100
Canon
s20
200
Nikon
a70
150
Canon
• Red lines are not in
the original relation
• How could we
separate?
Solution
• Let the decomposition of relation 𝑅 be 𝐷 =
{𝑅1 , 𝑅2 , … , 𝑅𝑚 } and let 𝐹 be their dependeny set.
Let’s create table T:
– Number of rows:= number of relations in D (m). 1
row/1 relation.
– Number of columns:=number of attributes in the
original relation.
• 𝑇 𝑖, 𝑘 ≔ 𝑎(𝑘), if kth attribute exists in ith
relation
• 𝑇 𝑖, 𝑘 ≔ 𝑏(𝑖, 𝑘), otherwise.
Solution – cont.
• Iteration: Let’s apply the elements of dependency
set 𝐹: 𝑋 → 𝑌 ∈ 𝐹
– In table T, if there are two identical rows in the
columns of X, then let’s modify the columns of Y: for
each column, if one of the (two) values is a(i), then its
pair has to be modified to a(i). If both are b(i,k), then
modify one of them to be equal to its pair.
• Decision: Finally, if there is at least one row which
contains only 𝑎(𝑘)s, then the composition is
lossless. Otherwise, not.
Example
•
•
•
•
•
•
𝑅1 (𝐴1 , 𝐴2 , 𝐴3 , 𝐴5 )
𝑅2 (𝐴1 , 𝐴3 , 𝐴4 )
𝑅3 (𝐴4 , 𝐴5 )
𝐹1 : 𝐴1 → 𝐴3 𝐴5
𝐹2 : 𝐴5 → 𝐴1 𝐴4
𝐹3 : 𝐴3 𝐴4 → 𝐴2
Creating table T
𝑨𝟏
𝑨𝟐
𝑨𝟑
𝑨𝟒
𝑨𝟓
𝑅1
𝑎(1)
𝑎(2)
𝑎(3)
𝑏(1,4)
𝑎(5)
𝑅2
𝑎(1)
𝑏(2,2)
𝑎(3)
𝑎(4)
𝑏(2,5)
𝑅3
𝑏(3,1)
𝑏(3,2)
𝑏(3,3)
𝑎(4)
𝑎(5)
• 𝑅1 (𝐴1 , 𝐴2 , 𝐴3 , 𝐴5 )
• 𝑅2 (𝐴1 , 𝐴3 , 𝐴4 )
• 𝑅3 (𝐴4 , 𝐴5 )
First dependency
𝑨𝟏
𝑨𝟐
𝑨𝟑
𝑨𝟒
𝑨𝟓
𝑅1
𝑎(1)
𝑎(2)
𝑎(3)
𝑏(1,4)
𝑎(5)
𝑅2
𝑎(1)
𝑏(2,2)
𝑎(3)
𝑎(4)
𝑏(2,5)
𝑅3
𝑏(3,1)
𝑏(3,2)
𝑏(3,3)
𝑎(4)
𝑎(5)
𝑨𝟏
𝑨𝟐
𝑨𝟑
𝑨𝟒
𝑨𝟓
𝑅1
𝑎(1)
𝑎(2)
𝑎(3)
𝑏(1,4)
𝑎(5)
𝑅2
𝑎(1)
𝑏(2,2)
𝑎(3)
𝑎(4)
𝒂(𝟓)
𝑅3
𝑏(3,1)
𝑏(3,2)
𝑏(3,3)
𝑎(4)
𝑎(5)
• 𝐹1 : 𝐴1 → 𝐴3 𝐴5
Second dependency
𝑨𝟏
𝑨𝟐
𝑨𝟑
𝑨𝟒
𝑨𝟓
𝑅1
𝑎(1)
𝑎(2)
𝑎(3)
𝑏(1,4)
𝑎(5)
𝑅2
𝑎(1)
𝑏(2,2)
𝑎(3)
𝑎(4)
𝑎(5)
𝑅3
𝑏(3,1)
𝑏(3,2)
𝑏(3,3)
𝑎(4)
𝑎(5)
𝑨𝟏
𝑨𝟐
𝑨𝟑
𝑨𝟒
𝑨𝟓
𝑅1
𝑎(1)
𝑎(2)
𝑎(3)
𝑎(4)
𝑎(5)
𝑅2
𝑎(1)
𝑏(2,2)
𝑎(3)
𝑎(4)
𝑎(5)
𝑅3
𝑎(1)
𝑏(3,2)
𝑏(3,3)
𝑎(4)
𝑎(5)
• 𝐹1 : 𝐴5 → 𝐴1 𝐴4
Third dependency (unnecessary)
𝑨𝟏
𝑨𝟐
𝑨𝟑
𝑨𝟒
𝑨𝟓
𝑅1
𝑎(1)
𝑎(2)
𝑎(3)
𝑎(4)
𝑎(5)
𝑅2
𝑎(1)
𝑏(2,2)
𝑎(3)
𝑎(4)
𝑎(5)
𝑅3
𝑎(1)
𝑏(3,2)
𝑏(3,3)
𝑎(4)
𝑎(5)
𝑨𝟏
𝑨𝟐
𝑨𝟑
𝑨𝟒
𝑨𝟓
𝑅1
𝑎(1)
𝑎(2)
𝑎(3)
𝑎(4)
𝑎(5)
𝑅2
𝑎(1)
𝑎(2)
𝑎(3)
𝑎(4)
𝑎(5)
𝑅3
𝑎(1)
𝑏(3,2)
𝑏(3,3)
𝑎(4)
𝑎(5)
• 𝐹1 : 𝐴3 𝐴4 → 𝐴2
BCNF - example
ID Name Price VATtype VAT % OrderID Quant. Address
•
•
•
•
Fproduct: {ID}  {Name, Price, VATtype}
Forder: {OrderID} {Address}
Fquantities: {ID, OrderID} {Quantity}
FVAT: {VATtype}  {VAT %}
Example – cont.
ID
Name Price
VATtype
VAT % OrderID Quant. Addr.
B(1,1)
B(1,2)
B(1,3)
B(1,4)
B(1,5)
B(1,6)
B(1,7)
B(1,8)
B(2,1)
B(2,2)
B(2,3)
B(2,4)
B(2,5)
B(2,6)
B(2,7)
B(2,8)
B(3,1)
B(3,2)
B(3,3)
B(3,4)
B(3,5)
B(3,6)
B(3,7)
B(3,8)
B(4,1)
B(4,2)
B(4,3)
B(4,4)
B(4,5)
B(4,6)
B(4,7)
B(4,8)
ID
Name Price
VATtype
VAT % OrderID Quant. Addr.
A(1)
A(2)
A(3)
A(4)
B(1,5)
B(1,6)
B(1,7)
B(1,8)
B(2,1) B(2,2)
B(2,3)
B(2,4)
B(2,5)
A(6)
B(2,7)
A(8)
A(1)
B(3,2)
B(3,3)
B(3,4)
B(3,5)
A(6)
A(7)
B(3,8)
B(4,1) B(4,2)
B(4,3)
A(4)
A(5)
B(4,6)
B(4,7)
B(4,8)
Example – cont.
ID
Name Price VATtype
VAT % OrderID Quant. Addr.
A(1)
A(2)
A(3)
B(1,5)
B(1,6)
B(1,7)
B(1,8)
B(2,1)
B(2,2)
B(2,3) B(2,4)
B(2,5)
A(6)
B(2,7)
A(8)
A(1)
B(3,2)
B(3,3) B(3,4)
B(3,5)
A(6)
A(7)
B(3,8)
B(4,1)
B(4,2)
B(4,3) A(4)
A(5)
B(4,6)
B(4,7)
B(4,8)
A(4)
• Fproductk: {ID}  {Name, Price, VATtype}
ID
Name Price VATtype
VAT %
OrderID Quant. Addr.
A(1)
A(2)
A(3)
B(1,5)
B(1,6)
B(1,7)
B(1,8)
B(2,1)
B(2,2)
B(2,3) B(2,4)
B(2,5)
A(6)
B(2,7)
A(8)
A(1)
A(2)
A(3)
B(3,5)
A(6)
A(7)
B(3,8)
B(4,1)
B(4,2)
B(4,3) A(4)
A(5)
B(4,6)
B(4,7)
B(4,8)
A(4)
A(4)
Example – cont.
ID
Name Price
VATtype
VAT % OrderID Quant. Addr.
A(1)
A(2)
A(3)
A(4)
B(1,5)
B(1,6)
B(1,7)
B(1,8)
B(2,1) B(2,2)
B(2,3)
B(2,4)
B(2,5)
A(6)
B(2,7)
A(8)
A(1)
A(3)
A(4)
B(3,5)
A(6)
A(7)
B(3,8)
B(4,3)
A(4)
A(5)
B(4,6)
B(4,7)
B(4,8)
A(2)
B(4,1) B(4,2)
Forder: {OrderID} {Address}
ID
Name Price
VATtype
VAT % OrderID Quant. Addr.
A(1)
A(2)
A(3)
A(4)
B(1,5)
B(1,6)
B(1,7)
B(1,8)
B(2,1) B(2,2)
B(2,3)
B(2,4)
B(2,5)
A(6)
B(2,7)
A(8)
A(1)
A(3)
A(4)
B(3,5)
A(6)
A(7)
A(8)
B(4,3)
A(4)
A(5)
B(4,6)
B(4,7)
B(4,8)
A(2)
B(4,1) B(4,2)
Example – cont.
ID
Name Price VATtype
VAT % OrderID Quant. Addr.
A(1)
A(2)
B(1,5)
B(1,6)
B(1,7)
B(1,8)
A(3)
A(4)
B(2,1) B(2,2)
B(2,3) B(2,4)
B(2,5)
A(6)
B(2,7)
A(8)
A(1)
A(3)
B(3,5)
A(6)
A(7)
A(8)
A(5)
B(4,6)
B(4,7)
B(4,8)
A(2)
B(4,1) B(4,2)
A(4)
B(4,3) A(4)
• Fquantities: {ID, OrderID} {Quantity}
Example – cont.
ID
Name Price
VATtype
VAT % OrderID Quant. Addr.
A(1)
A(2)
A(3)
A(4)
B(1,5)
B(1,6)
B(1,7)
B(1,8)
B(2,1)
B(2,2)
B(2,3)
B(2,4)
B(2,5)
A(6)
B(2,7)
A(8)
A(1)
A(2)
A(3)
A(4)
B(3,5)
A(6)
A(7)
A(8)
B(4,1)
B(4,2)
B(4,3)
A(4)
A(5)
B(4,6)
B(4,7)
B(4,8)
• FVAT: {VATtype}  {VAT %}
ID
Name Price
VATtype
VAT % OrderID Quant. Addr.
A(1)
A(2)
A(3)
A(4)
A(5)
B(1,6)
B(1,7)
B(1,8)
B(2,1)
B(2,2)
B(2,3)
B(2,4)
B(2,5)
A(6)
B(2,7)
A(8)
A(1)
A(2)
A(3)
A(4)
A(5)
A(6)
A(7)
A(8)
B(4,1)
B(4,2)
B(4,3)
A(4)
A(5)
B(4,6)
B(4,7)
B(4,8)
Thank you for your attention!