Normal forms ทฤษฎีของการทำ Normalization เป็นเรื่องเกี่ยวกับการพิจารณาว่า relation ที่กำหนดให้ อยู่ในรูปแบบ Normal form ใด คือ มีความถูกต้องตรงกับกฎเกณฑ์ข้อบังคับ.

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 PROJECTS PARTS JOBS PART-USE DEP-NO MANAGER
DATE-ESTABLISHED PROJECTS PARTS PROJECT-NO DEP-NO BUDGET PART-NO COLOR WEIGHT JOBS PART-USE JOB-NO PROJECT-NO COST PART-NO PROJECT-NO QTY-USED

นิยาม 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
P2 200 P3 400 P4 P5 100 P6 S2 10 Paris S3 S4

Normalized (1 NF) S# STATUS CITY P# QTY S1 20 London P1 300 P2 200 P3
400 P4 P5 100 P6 S2 10 Paris S3 S4

S# STATUS QTY P# CITY FD diagram in relation FIRST S# P# STATUS CITY QTY

Relation ใดๆ อยู่ใน 2 NF ก็ต่อเมื่อ Relation นั้นอยู่ใน 1 NF
นิยาม 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# P# QTY S# STATUS CITY S1 P1 300 P2 200 P3 400 P4 P5 100
London S2 10 Paris S3 S4 S5 30 Athens

Relation ใดๆ อยู่ใน 3 NF ก็ต่อเมื่อ Relation นั้นอยู่ใน 2 NF
นิยาม Relation ใดๆ อยู่ใน 3 NF ก็ต่อเมื่อ Relation นั้นอยู่ใน 2 NF และทุกๆ Nonkey attribute นั้น ต้องไม่มี transitive กับ Primary key SECOND (S#,STATUS,CITY)  SC (S#,CITY) CS (CITY,STATUS) CITY STATUS S# CITY FD in the relation SC and CS SC S# CITY S1 London S2 Paris S3 S4 S5 Athens CS CITY STATUS Athens 30 London 20 Paris 10 Rome 50

Relation ใดๆ อยู่ใน 3 NF ก็ต่อเมื่อ Nonkey attribute
นิยาม 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 COLOR S# P# S# ADDRESS QTY WEIGHT P# STATUS CITY

ORDERS ORDER-NO ORDER-DATE ORDER-LINE Ord1 Ord2 6 June 1996 3 May 1996
Ord2 6 June 1996 3 May 1996 PART-NO QTY-ORDERED P P PART-NO QTY-ORDERED P P P ORDERS ORDER-NO ORDER-DATE PART-NO QTY-ORDERED Ord1 Ord2 6 June 1996 3 May 1996 P1 P6 P5 P2 10 30 50

ORDERS ORDER-NO ORDER-DATE Ord1 Ord2 6 June 1996 3 May 1996 ORDERS-CONTENTS ORDER-NO PART-NO QTY-ORDERED Ord1 Ord2 P1 P6 P5 P2 10 30 50 ORDER-NO ORDER-DATE QTY-ORDERS PART-NO

ORDER-NO QTY-ORDERED PART-NO ORDER-NO ORDER-DATE

PROJECT-ID PERSON-ID MANAGER TIME-SPENT
PROJECTS PROJECT-ID PERSON-ID MANAGER TIME-SPENT Proj1 Proj2 Proj3 J1 J2 J3 Vichi Joe Brown 30 12 11 79 17 3

WORK PROJECTS Proj1 Proj2 Proj3 J1 J2 J3 30 12 11 79 17 3 Proj1 Proj2
PROJECT-ID PERSON-ID TIME-SPENT Proj1 Proj2 Proj3 J1 J2 J3 30 12 11 79 17 3 PROJECT-ID MANAGER Proj1 Proj2 Proj3 Vichi Joe Brown PROJECT-ID MANAGER TIME-SPENT PERSON-ID

PROJECT-ID TIME-SPENT PERSON-ID PROJECT-ID MANAGER

VEHICLES YX-01 YJ-77 YW-30 YJ-37 YJ-83 George Mary Andrew Laser Falcon
REGISTRATION OWNER MODEL MANUFACTOR NO-CYLINDER YX-01 YJ-77 YW-30 YJ-37 YJ-83 George Mary Andrew Laser Falcon Corolla Ford Toyota 4 6

OWNER MODEL REGISTRATION-NO MANUFACTOR NO-CYLINDER

OWNER MODEL REGISTRATION-NO MANUFACTOR MODEL NO-CYLINDERS MANUFACTOR

REGISTRATION VEHICLES1 REGISTRATION-NO OWNER MODEL MANUFACTOR YX-01
YJ-77 YW-30 YJ-37 YJ-83 George Mary Andrew Laser Falcon Corolla Ford Toyota VEHICLES1 MODEL MANUFACTOR NO-CYLINDER Laser Falcon Corolla Ford Toyota 4 6

2. Each Loan application-no has one LOAN-TYPE.
LOAN-APPLICTION-NO APPLICANT APPLICANT-ADDRESS LOAN-TYPE 1 Jill Canberra Home 2 Joe Sydney Mortgage 3 Personal 4 Max Melbourne Each Loan application has APPLICANT and is identified by unique value of LOAN-APPLICATION –NO 2. Each Loan application-no has one LOAN-TYPE. 3. Each Loan application-no has one APPLICANT-ADDRESS. 4. An applicant can make many applications.

Rules for CUSTOMER –INVOICES:
NAME INVOICE-NO ADDRESS SERVICE COST DATE Joe 6 Sydney Repair 120 June,1992 Course 320 July,1992 Jill 3 Canberra 80 August,1992 150 October1992 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.

Rules for MACHINE-USE:
OPERATOR MACHNE DATE QTY-PARTS PRODUCTS TIME-SPENT ON-MACHNE Joe Mach 1 1 June 1992 15 10 Mach 2 20 12 Bill 6 2 June 1992 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 CITY SNAME Relation S(S#,SNAME,STATUS,CITY) Candidate key มี S#, SNAME Determinant มี S#, SNAME STATUS, CITY นั้น Mutually independent กัน คือ FD S.CITY ----- S.STATUS

Example 2 relation SSP (S#,SNAME,P#,QTY) S# P# QTY SNAME S# SNAME P#
Smith P1 P2 P3 P4 300 200 400 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)

S = Student, J = Subject, T = Teacher
Example 3 S J T Smith Jones Math Physics Prof.White Prof.Green Prof.Brown relation SJT (S,J,T) S = Student, J = Subject, T = Teacher วิชาใดๆ แต่ละ Student จะถูกสอนโดย Teacher เพียงคนเดียว (S,J) ---- T แต่ละ Teacher นั้นจะสอนได้เพียง Subject เดียว (แต่ Subject หนึ่ง อาจสอนโดยหลายๆ Teacher ได้) 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

S = Student, J = Subject, P = Position
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 S J P Candidate key มี (S,J), (J,P) Determinant มี (S,J), (J,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 Physics Maths Prof.Gran Prof.Brown Basic mechanics
COURSE TEACHER TEXT Physics Maths Prof.Gran Prof.Brown Basic mechanics Principles of optics Vector analysis Trigonometry CTX มี 2 MVD 1. CTX.COURSE ----- CTX.TEACHER 2. CTX.COURSE --- CTX.TEXT

แยกเป็น 2 relation ย่อย (Projection)
COURSE TEACHER TEXT Physics Math Prof.Gran Prof.Brown Basic mechanics Principles of optics Vector analysis Trigonometry CTX แยกเป็น 2 relation ย่อย (Projection) CT(COURSE,TEACHER) และ CX(COURSE,TEXT) CT CX COURSE TEXT Physics Math Basic mechanics Principles of optics Vector analysis Trigonometry COURSE TEACHER Physics Math Prof.Gran Prof.Brown Prof.White

นิยาม 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

Relation S (S#,SNAME,STATUS,CITY) Candidate key มี 2 ตัว : S#, SNAME
Example 1 Relation S (S#,SNAME,STATUS,CITY) Candidate key มี 2 ตัว : S#, SNAME Relation นี้มี 2 JD * ((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

หมายถึง Supplier คนหนึ่ง ส่ง Part หนึ่งไปใช้ใน Project หนึ่ง
Example 2 Relation SPJ (S#,P#,J#) หมายถึง Supplier คนหนึ่ง ส่ง Part หนึ่งไปใช้ใน Project หนึ่ง S P J S1 S2 P1 P2 J2 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 S1 S2 P1 P2 P1 P2 J2 J1 SPJ Join Over P# JS J2 J1 S1 S2 S P J S1
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

FD diagram BAL ADDRESS CUST CREDLIM DISCOUNT QTYORD ORD# DATE LINE#
QTYOUT ITEM# DESCN QTYOH PLANT# DANGER FD diagram

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 Project Office Phone Job Salary History

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

FD diagram DBUDGET AREA DEP# MGR# OFF# PHONE# PROJ# PBUDGET EMP# DATE
SALARY JOBTITLE FD diagram

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
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 4 NF - Relation R อยู่ใน 4 NF ก็ต่อเมื่อ ทุกๆ MVD ใน R เป็น consequence ของ Candidate ของ R 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 ไม่ได้แก้ไขปัญหาได้ทุกสิ่งทุกอย่าง

งานนำเสนอที่คล้ายกัน

งานนำเสนอที่คล้ายกัน

เรื่องโครงการ

การติดต่อกลับ

เข้าสู่ระบบ

ลงทะเบียนผ่านเครือข่ายสังคม:

งานนำเสนอที่คล้ายกัน

งานนำเสนอที่คล้ายกัน

เรื่องโครงการ

การติดต่อกลับ