Normal forms
ทฤษฎีของการทา Normalization เป็ นเรื่ องเกี่ยวกับการพิจารณาว่า relation ที่
กาหนดให้ อยูใ่ นรู ปแบบ Normal form ใด คือ มีความถูกต้องตรงกับกฎเกณฑ์ขอ้ บังคับ
หรื อเงื่อนไขบางอย่างที่กาหนดไว้
Universe of Relations (normalized and unnormalized)
1 NF relations (normalized relations)
2 NF relations
3 NF relations
BCNF relations
4NF relations
PJ/NF (5 NF) relations
Further Normalization
การทา Normalization เป็ นหลักสาคัญของการทา Database design ซึ่ งเรี ยก
ว่า Logical database design
ส่ วนของ Physical database design เกี่ยวกับ Internal level เช่น
จัดการเกี่ยวกับ File เพื่อให้ access เร็ วที่สุด, I/O access น้อยที่สุด
Normalization คือ วิธีการซึ่ ง
- บอกให้ทราบว่า relation นั้น มีปัญหาเกิดขึ้นหรื อไม่
- ถ้ามีปัญหาเกิดขึ้น จะขจัดปั ญหานั้นออกอย่างไร
คือ เครื่ องมือ (Tool) ที่ช่วยให้ design database ในลักษณะเป็ น
Conceptual Schema design ได้โดยที่มีปัญหาน้อยที่สุด หรื ออาจไม่มีเลย
Functional dependency (FD)
“Functional dependence” หรื อ “Functional dependency”
Relation R มี attribute x, y
attribute y เป็ น “Functional dependence” กับ attribute x
เขียนเป็ นสัญลักษณ์ R.x --> R.y หรื อ x  y
เรี ยกว่า
y functional dependent on x (y ขึ้นกับ x อย่าง function
หรื อ
x functional determines y (x เป็ นตัวกาหนด y)
ก็ต่อเมื่อ แต่ละค่าของ x ใน R จะมีค่า y ของ R ที่สอดคล้องกับ x เพียงค่าเดียวเท่านั้น
(attribute x,y อาจเป็ น Composite attribute)
DEPARTMENT
DEP-NO
MANAGER
DATE-ESTABLISHED
PROJECTS
PROJECT-NO
PARTS
DEP-NO
BUDGET
COLOR
WEIGHT
JOBS
PART-USE
PART-NO
PART-NO
PROJECT-NO
QTY-USED
JOB-NO
PROJECT-NO
COST
นิยาม A relation R is in first normal form (1 NF) if and only if
All underlying domains contain atomic values only
Relation ใดๆ อยูใ่ น 1 NF ก็ต่อเมื่อ Simple domains ทั้งหมดมีแต่ Atomic
Values (ไม่มี repeating group)
Unnormalized
S#
STATUS
CITY
P#
QTY
S1
20
London
P1
300
P2
200
P3
400
P4
200
P5
100
P6
100
P1
300
P2
400
S2
10
Paris
S3
10
Paris
P2
200
S4
20
London
P2
200
P4
300
P5
400
Normalized (1 NF)
S#
STATUS
CITY
P#
QTY
S1
20
London
P1
300
S1
20
London
P2
200
S1
20
London
P3
400
S1
20
London
P4
200
S1
20
London
P5
100
S1
20
London
P6
100
S2
10
Paris
P1
300
S2
10
Paris
P2
400
S3
10
Paris
P2
200
S4
20
London
P2
200
S4
20
London
P4
300
S4
20
London
P5
400
S#
STATUS
P#
CITY
QTY
FD diagram in relation FIRST
S#
P#
STATUS
CITY
QTY
นิยาม
Relation ใดๆ อยูใ่ น 2 NF ก็ต่อเมื่อ Relation นั้นอยูใ่ น 1 NF
และทุกๆ Nonkey attribute นั้น Fully FD กับ Primary key
จาก FIRST  SECOND (S#,STATUS,CITY)
SP (S#,P#,QTY)
STATUS
S#
S#
QTY
CITY
P#
FD in the relation SECOND and SP
SECOND
SP
S#
STATUS
CITY
S#
P#
QTY
S1
20
London
S1
P1
300
S2
10
Paris
S1
P2
200
S3
10
Paris
S1
P3
400
S4
20
London
S1
P4
200
S5
30
Athens
S1
P5
100
S1
P6
100
S2
P1
300
S2
P2
400
S3
P2
200
S4
P2
200
S4
P4
300
S4
P5
400
นิยาม
Relation ใดๆ อยูใ่ น 3 NF ก็ต่อเมื่อ Relation นั้นอยูใ่ น 2 NF
และทุกๆ Nonkey attribute นั้น ต้องไม่มี transitive กับ
Primary key
SECOND (S#,STATUS,CITY)  SC (S#,CITY)
CS (CITY,STATUS)
S#
CITY
CITY
STATUS
FD in the relation SC and CS
SC
S#
CITY
CITY
STATUS
S1
London
Athens
30
S2
Paris
London
20
S3
Paris
Paris
10
S4
London
Rome
50
S5
Athens
CS
นิยาม
Relation ใดๆ อยูใ่ น 3 NF ก็ต่อเมื่อ Nonkey attribute
มีคุณสมบัติ 2 ข้อ ดังนี้
1. Mutually independent
2. Fully dependent on the primary key
Nonkey attribute คือ attribute ใดๆ ที่ไม่ใช่ส่วนหนึ่ งส่ วนใดของ primary key
ใน relation
Mutually independent คือ attribute ตั้งแต่ 2 attributes ขึ้นไป ไม่มี FD
กับ attribute อื่นใดเลย คือ Nonkey ทั้งหมดจะต้องเป็ นอิสระต่อกันอย่างเด็ดขาดไม่เกี่ยวข้องกัน
PNAME
SNAME
S#
ADDRESS
P#
COLOR
QTY
WEIGHT
STATUS
S#
CITY
P#
ORDERS
ORDER-NO
ORDER-DATE
Ord1
6 June 1996
Ord2
3 May 1996
ORDER-LINE
PART-NO
P1
P6
PART-NO
P5
P6
P2
QTY-ORDERED
10
30
QTY-ORDERED
10
50
20
ORDERS
ORDER-NO
ORDER-DATE
PART-NO
QTY-ORDERED
Ord1
Ord1
Ord2
Ord2
Ord2
6 June 1996
6 June 1996
3 May 1996
3 May 1996
3 May 1996
P1
P6
P5
P6
P2
10
30
10
50
30
ORDERS
ORDER-NO
ORDER-DATE
Ord1
Ord2
6 June 1996
3 May 1996
ORDERS-CONTENTS
ORDER-NO
PART-NO
QTY-ORDERED
Ord1
Ord1
Ord2
Ord2
Ord2
P1
P6
P5
P6
P2
10
30
10
50
30
ORDER-NO
QTY-ORDERS
PART-NO
ORDER-DATE
ORDER-NO
QTY-ORDERED
PART-NO
ORDER-NO
ORDER-DATE
PROJECTS
PROJECT-ID
PERSON-ID
MANAGER
TIME-SPENT
Proj1
J1
Vichi
30
Proj2
J1
Joe
12
Proj1
J2
Vichi
11
Proj2
J2
Joe
79
Proj3
J2
Brown
17
Proj1
J3
Vichi
3
WORK
PROJECTS
PROJECT-ID
MANAGER
Proj1
Vichi
Proj2
Joe
Proj3
Brown
PROJECT-ID
PERSON-ID
TIME-SPENT
Proj1
Proj2
Proj1
Proj2
Proj3
Proj1
J1
J1
J2
J2
J2
J3
30
12
11
79
17
3
PROJECT-ID
TIME-SPENT
PERSON-ID
MANAGER
PROJECT-ID
TIME-SPENT
PERSON-ID
PROJECT-ID
MANAGER
VEHICLES
REGISTRATION
OWNER
MODEL
MANUFACTOR
NO-CYLINDER
YX-01
George
Laser
Ford
4
YJ-77
Mary
Falcon
Ford
6
YW-30
George
Corolla
Toyota
4
YJ-37
Mary
Laser
Ford
4
YJ-83
Andrew
Corolla
Toyota
4
OWNER
REGISTRATION-NO
MODEL
MANUFACTOR
NO-CYLINDER
OWNER
REGISTRATION-NO
MODEL
MANUFACTOR
MODEL
NO-CYLINDERS
MANUFACTOR
REGISTRATION
REGISTRATION-NO
OWNER
MODEL
MANUFACTOR
YX-01
YJ-77
YW-30
YJ-37
YJ-83
George
Mary
George
Mary
Andrew
Laser
Falcon
Corolla
Laser
Corolla
Ford
Ford
Toyota
Ford
Toyota
VEHICLES1
MODEL
MANUFACTOR
NO-CYLINDER
Laser
Falcon
Corolla
Ford
Ford
Toyota
4
6
4
1. LOAN APPLICATION
1.
2.
3.
4.
LOAN-APPLICTIONNO
APPLICANT
APPLICANT-ADDRESS
LOAN-TYPE
1
Jill
Canberra
Home
2
Joe
Sydney
Mortgage
3
Jill
Canberra
Personal
4
Max
Melbourne
Home
Each Loan application has APPLICANT and is identified by unique value of
LOAN-APPLICATION –NO
Each Loan application-no has one LOAN-TYPE.
Each Loan application-no has one APPLICANT-ADDRESS.
An applicant can make many applications.
2. CUSTOMER –INVOICES
CUSTOMER
NAME
INVOICENO
CUSTOMER
ADDRESS
CUSTOMER
SERVICE
SERVICE
COST
SERVICE
DATE
Joe
6
Sydney
Repair
120
June,1992
Joe
6
Sydney
Course
320
July,1992
Jill
3
Canberra
Repair
80
August,1992
Joe
6
Sydney
Repair
150
October199
2
Rules for CUSTOMER –INVOICES:
1. Each invoice is to one customer and is identified by a unique value of INVOIC-NO
2. A number of CUSTOMER –INVOICES can be included on one invoice.
3.
There is a separate SERVICE-COST for each CUSTOMER – INVOICES on an
invoice.
4. MACHINE-USE
OPERATOR
MACHNE
DATE
QTY-PARTS
PRODUCTS
TIME-SPENT
ON-MACHNE
Joe
Mach 1
1 June 1992
15
10
Joe
Mach 2
1 June 1992
20
12
Bill
Mach 1
1 June 1992
12
6
Bill
Mach 2
2 June 1992
20
14
Rules for MACHINE-USE:
1. A machine only bused one operator on a given date.
2. An operator can use any number of machines the one day.
T3. TIME-SPEN-ON –MACHHINE is the time spent by an operator on the machine on
given DATE, QTY-PARTS-PRODUCES is quantity of parts produced on that machine by
the operator on the given date
Boyce/Codd Normal form (BCNF)
นิยาม
Relation ใดๆ อยูใ่ น BCNF ก็ต่อเมื่อ ทุกๆ Determinant ที่มีอยู่
เป็ น Candidate key ด้วย
S#
STATUS
SNAME
CITY
Relation S(S#,SNAME,STATUS,CITY)
Candidate key มี S#, SNAME
Determinant มี S#, SNAME
STATUS, CITY นั้น Mutually independent กัน
คือ FD S.CITY ----- S.STATUS
Example 2
S#
S1
SNAME
Smith
P#
P1
QTY
300
S1
Smith
P2
200
S1
Smith
P3
400
S1
Smith
P4
200
relation SSP (S#,SNAME,P#,QTY)
S#
P#
QTY
SNAME
Candidate key มี (S#,P#), (SNAME,P#)
Determinant มี (S#,P#), (SNAME,P#), S#, SNAME
การแก้ปัญหา คือ แยก SSP เป็ น 2 projection
SS (S#, SNAME) กับ SP (S#, P#, QTY)
หรื อ SS (S#, SNAME) กับ SP (SNAME,P#, QTY)
Example 3
S
J
T
Smith
Smith
Jones
Jones
Math
Physics
Math
Physics
Prof.White
Prof.Green
Prof.White
Prof.Brown
relation SJT (S,J,T)
S = Student, J = Subject, T = Teacher
วิชาใดๆ แต่ละ Student จะถูกสอนโดย Teacher เพียงคนเดียว
(S,J) ---- T
แต่ละ Teacher นั้นจะสอนได้เพียง Subject เดียว
(แต่ Subject หนึ่ง อาจสอนโดยหลายๆ Teacher ได้)
T --- J
S
T
J
Candidate key มี (S,J), (S,T)
Determinant มี (S,J), (S,T), T
แก้ปัญหาโดย ST(S,T) และ TJ(T,J)
ST มี Candidate key คือ (S,T) ไม่มี determinant
TJ มี Candidate key คือ T determinant คือ T
Example 4
relation EXAM(S,J,P)
S = Student, J = Subject, P = Position
ความหมายของ Exam tuple (S,J,P) คือ
Student S สอบ Subject J และได้ Position P ใน class
ข้อบังคับ
- ไม่มีโอกาสที่ 2 student จะได้ Position เดียวกัน ใน Subject เดียวกัน
S
J
P
J
Candidate key มี (S,J), (J,P)
Determinant มี (S,J), (J,P)
S
P
นิยาม ของ MVD (Multi Value dependency)
Relation R ใดๆ ที่มี Attribute A, B, C (อาจเป็ น Composite attribute)
แล้วมี MVD R.A -> R.B เกิดขึ้น ก็ต่อเมื่อ
Set ของค่า B จะขึ้นกับค่า A เท่านั้น และเป็ นอิสระกับค่า C
(R.A - R.B อ่านว่า R.B “Multi dependent” กับ R.A
หรื อ R.A “Multi determine” กับ R.B
ทุกๆครั้งที่ relation R ใดๆ R(A,B,C) มี MVD R.A --> R.B
สรุ ปได้วา่ มี MVD R.A ---> R.C ด้วย
เพราะ B, C เป็ นอิสระต่อกัน
เขียนแทนด้วย R.A ---> R.B / R.C
MVD เป็ น general case (กรณี ทวั่ ไป) ของ FD
FD เป็ น special case (กรณี ทวั่ ไป) ของ MVD
นิยามของ 4 NF
Relation R อยูใ่ น 4 NF ก็ต่อเมื่อ
เมื่อไรก็ตามที่มี MVD ใน R เช่น A ---> B แล้ว
ทุกๆ attribute ของ R มี FD กับ A ด้วย
นัน่ คือ ถ้ามี MVD A ---> B แล้ว MVD นั้นเป็ น FD A -- B ด้วย
หรื อ ถ้า R อยูใ่ น 4 NF แล้ว R นั้นอยูใ่ น BCNF และทุกๆ MVD ใน R
จริ งๆ เป็ น FD
Example
COURSE
TEACHER
TEXT
Physics
Prof.Gran
Prof.Brown
Prof.Gran
Basic mechanics
Principles of optics
Basic mechanics
Vector analysis
Trigonometry
Maths
CTX มี 2 MVD
1. CTX.COURSE ----- CTX.TEACHER
2. CTX.COURSE --- CTX.TEXT
CTX
COURSE
TEACHER
TEXT
Physics
Physics
Physics
Physics
Math
Math
Math
Prof.Gran
Prof.Gran
Prof.Brown
Prof.Brown
Prof.Gran
Prof.Gran
Prof.Gran
Basic mechanics
Principles of optics
Basic mechanics
Principles of optics
Basic mechanics
Vector analysis
Trigonometry
แยกเป็ น 2 relation ย่อย (Projection)
CT
CT(COURSE,TEACHER) และ CX(COURSE,TEXT)
COURSE
TEACHER
Physics
Physics
Math
Prof.Gran
Prof.Brown
Prof.White
CX
COURSE
TEXT
Physics
Physics
Math
Math
Math
Basic mechanics
Principles of optics
Basic mechanics
Vector analysis
Trigonometry
นิยาม 5 NF
Relation R อยูใ่ น 5 NF หรื อ “Projection-join normal form” (PJ/NF)
ก็ต่อเมื่อ ทุกๆ JD ที่มีอยูใ่ น R เป็ นผลสื บเนื่องมาจาก หรื อ เป็ นผลสรุ ปมาจาก
(consequence / imply) Candidate key ของ R
Relation R ใดๆ มีคุณสมบัติ “Join dependency” (JD)
* (X,Y,….,Z)
ก็ต่อเมื่อ R = join ของ Projection X,Y,…,Z
โดยที่ X,Y,…,Z คือ subset ใดๆของ set ของ attribute ของ R
Example 1
Relation S (S#,SNAME,STATUS,CITY)
Candidate key มี 2 ตัว : S#, SNAME
Relation นี้มี 2 JD
1. * ((S#,SNAME,STATUS), (S#,STATUS))
S = Join ของ (S#,SNAME,STATUS) กับ (S#,CITY) ด้วย S#
JD เป็ น consequence จาก S# ซึ่ งเป็ น Candidate key
2. * ((S#,SNAME), (S#,STATUS), (SNAME,CITY))
(S#,SNAME)
(S#,STATUS)
Join over S#
(S#,SNAME,STATUS)
(SNAME,CITY)
Join Over SNAME
มี JD ทั้งหมด 2 ตัว และ JD ทั้งสองเป็ น consequence ของ Candidate key
ดังนั้น S อยูใ่ น 5 NF
Example 2
Relation SPJ (S#,P#,J#)
หมายถึง Supplier คนหนึ่ง ส่ ง Part หนึ่งไปใช้ใน Project หนึ่ง
S
P
J
S1
S1
S2
S1
P1
P2
P1
P1
J2
J1
J1
J1
Relation SPJ เป็ น All key และไม่มี FD หรื อ MVD --- 4 NF
แยกได้ 3 projections SP, PJ, JS
SP(S#,P#), PJ(P#,J#), JS(J#,S#)
Join ของ SP กับ PJ ด้วย P# ได้ SPJ เดิม กับอีก 1 tuple เพิ่มมา
และเมื่อ join กับ JS ด้วย (J#,S#) จะได้ SPJ ดังเดิม
SP
PJ
S#
P#
P#
J#
S1
S1
S2
P1
P2
P1
P1
P2
P1
J2
J1
J1
SPJ
Join Over P#
S
P
J
S1
S1
S1
S2
S2
P1
P1
P2
P1
P1
J2
J1
J1
J2
J1
JS
J#
S#
J2
J1
J1
S1
S1
S2
Join
Over(J#,S#)
Original SPJ
ตัวอย่ างของการทา Normalize
Order-Entry System ประกอบด้วยข้อมูลเกี่ยวกับ
Customers, Item และ orders
CUSTOMER – Customer number (unique)
- Ship to address (several per customer)
- Balance
- Credit Limit
- Discount
ORDER
- Order number (unique)
- Customer number
- Ship to address
- Date of order
- Detail lines (several per customer)
- item number
- quantity ordered
- quantity out
ITEM
- Item number (unique)
- Manufacturing plants
- Quantity on hand at each plant
- Stock danger level for each plant
- Item description
BAL
ADDRESS
CUST
CREDLIM
DISCOUNT
QTYORD
ORD#
QTYOUT
LINE#
DESCN
ITEM#
PLANT#
FD diagram
DATE
QTYOH
DANGER
CUST (CUST#, BAL,CREDIT,DISCOUNT)
SHIPTO (ADDRESS, CUST#)
ORDHEAD (ORD#, ADDRESS, DATE)
ORDLINE (ORD#, LINE#, ITEM#, QTYORD, QTYOUT)
ITEM (ITEM#, DESCN)
IP (ITEM#, PLANT#, QTYOH, DANGER)
Department
Employee
Job
Salary History
Project
Office
Phone
-The Company ประกอบด้วยหลายๆแผนก (department)
- แต่ละแผนก (department) ประกอบด้วยกลุ่มพนักงาน (employee)
กลุ่มของ Project และกลุ่มของ office
- แต่ละ employee มีประวัติการทางานที่ผา่ นมา (job history) และแต่ละ job
มีเงินเดือน(salary) ที่เคยได้รับมา
- แต่ละ office ประกอบด้วยกลุ่มของโทรศัพท์ (phone)
Department ประกอบด้วย department number(unique),
งบประมาณ (budget) และ manager (unique)
Employee ประกอบด้วย employee number (unique), current
project number, office number, phone number,
แต่ละ job ในอดีตที่เคยทา (plus date and salary)
Project ประกอบด้วย project number (unique), budget
Office
ประกอบด้วย office number (unique), area in square feet
และ number (unique) of all phones in that office
DBUDGET
AREA
DEP#
OFF#
PHONE#
JOBTITLE
EMP#
PROJ#
DATE
SALARY
FD diagram
MGR#
PBUDGET
DEPARTMENT (DEPT#, DBUDGET,MGR#)
EMPLOYEE (EMP#,DEP# PROJ#,PHONE#)
SALHIST (EMP#, DATE, JOBTITLE, SALARY)
PROJECT (PROJ#, DEPT#, PBUDGET)
OFFICE (OFF#, DEPT#, AREA)
PHONE (PHONE#, OFF#)
Process ในการทา Normalization
1. 0 NF ------ 1 NF
- Examine for reports
ถ้ามี repeating group ให้เขียนเป็ น flat file
- Remove from relation
remove repeating group ออกจาก relation
- Create new relation
แยก relation ออกเป็ นหลายๆ Projection
- Include key
relation ใหม่ ต้องมี key จาก relation เดิมรวมอยูด่ ว้ ย
2. 1 NF ------ 2 NF
ถ้ามี Concatinated key ให้พิจารณา (ถ้าเป็ น Simple key จะเป็ น 2 NF)
- Check each attribute against the whole key
ตรวจสอบแต่ละ attribute กับ key ว่า attribute ใด ที่ข้ ึนกับเพียงบางส่ วนของ
Key ถ้ามีให้พิจารณาขั้นต่อไป
- Remove attribute and copy partial key to new relation
remove attribute ที่ข้ ึนกับเพียงบางส่ วนของ key กับ Partial key นั้นมา
สร้าง relation ใหม่
- Optimizing
กรณี ที่มีหลายๆ relation เมื่อทาถึงขั้นตอนนี้แล้ว ปรากฏว่ามีบาง relation ที่มี
Primary key เหมือนกัน จะนา relation ดังกล่าวรวมเข้าด้วยกัน
3. 2 NF -------- 3 NF
- Examine each attribute
พิจารณาแต่ละ attribute ว่ามี transitive FD หรื อไม่
- พิจารณาว่า Nonkey ใด ขึ้นกับ Nonkey อื่นบ้าง
- remove Nonkey ที่ข้ ึนกับ Nonkey ด้วยกัน ออกมาสร้าง relation ใหม่
- หา key ของ relation ใหม่
- optimizing
นา relation ที่มี Primary key เหมือนกันมารวมกัน เช่น Primary key
เป็ น (x1,x2,x3) หรื อ (x3,x1,x2) ก็ได้
4. BCNF
- Relation R อยูใ่ น BCNF ก็ต่อเมื่อทุกๆ FD ใน R เป็ น consequenceของ
Candidate keys ของ R
5. 4 NF
- Relation R อยูใ่ น 4 NF ก็ต่อเมื่อ ทุกๆ MVD ใน R เป็ น consequence
ของ Candidate ของ R
6. 5 NF
- Relation R อยูใ่ น 5 NF ก็ต่อเมื่อ ทุกๆ JD ใน R เป็ น consequence
ของ Candidate keys ของ R
1. จุดประสงค์ท้ งั หมดของ Normalization process
- ขจัด Redundancy
- หลีกเลี่ยง Update anomaly
- สร้างการ design ที่ represent real world ได้ดี
- บังคับให้มี Integrity constraint ได้ง่าย
2. Normalization guidelines เป็ นเพียงแนวทางเท่านั้น บางครั้งมีเหตุผลที่จะไม่ทา
normalizing เลย
เช่น Name and Address relation
NADDR (NAME,STREET,CITY,STATE,ZIP)
มี FD NAME ---- (STREET,CITY,STATE,ZIP)
ZIP ---- (CITY,STATE)
STREET,CITY,STATE ใช้บ่อย และ ZIP ไม่มีการเปลี่ยนแปลงบ่อย
3. Dependency และ Futhur Normalization เป็ น “Semantic” โดย
ธรรมชาติ นัน่ คือ เกี่ยวกับความหมายของ Data
4. Normalization เป็ นประโยชน์สาหรับ Database design แต่
Normalization ไม่ได้แก้ไขปั ญหาได้ทุกสิ่ งทุกอย่าง