งานนำเสนอกำลังจะดาวน์โหลด โปรดรอ

งานนำเสนอกำลังจะดาวน์โหลด โปรดรอ

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

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


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

1 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

2

3

4 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 ได้โดยที่มีปัญหาน้อยที่สุด หรืออาจไม่มีเลย

5 Functional dependency (FD) “ Functional dependence ” หรือ “ Functional dependency ” Relation R มี attribute x, y attribute y เป็น “ Functional dependence ” กับ attribute x เขียนเป็นสัญลักษณ์ R.x --> R.y หรือ x  y เรียกว่า หรือ x functional determines y (x เป็นตัวกำหนด y) ก็ต่อเมื่อ แต่ละค่าของ x ใน R จะมีค่า y ของ R ที่สอดคล้องกับ x เพียงค่าเดียวเท่านั้น (attribute x,y อาจเป็น Composite attribute) y functional dependent on x (y ขึ้นกับ x อย่าง function

6

7 DEP-NOMANAGERDATE-ESTABLISHED PROJECT-NODEP-NOBUDGETPART-NOCOLORWEIGHT PART-NOPROJECT-NOQTY-USED JOB-NOPROJECT-NOCOST DEPARTMENT PROJECTS PARTS PART-USE JOBS

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

9 S#STATUSCITYP#QTY S120LondonP1300 P2200 P3400 P4200 P5100 P6100 S210ParisP1300 P2400 S310ParisP2200 S420LondonP2200 P4300 P5400 Unnormalized

10 S#STATUSCITYP#QTY S120LondonP1300 S120LondonP2200 S120LondonP3400 S120LondonP4200 S120LondonP5100 S120LondonP6100 S210ParisP1300 S210ParisP2400 S310ParisP2200 S420LondonP2200 S420LondonP4300 S420LondonP5400 Normalized (1 NF)

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

12 นิยาม Relation ใดๆ อยู่ใน 2 NF ก็ต่อเมื่อ Relation นั้นอยู่ใน 1 NF และทุกๆ Nonkey attribute นั้น Fully FD กับ Primary key จาก FIRST  SECOND (S#,STATUS,CITY) SP (S#,P#,QTY) S# STATUS CITY S# P# QTY FD in the relation SECOND and SP

13 S#STATUSCITY S120London S210Paris S310Paris S420London S530Athens S#P#QTY S1P1300 S1P2200 S1P3400 S1P4200 S1P5100 S1P6100 S2P1300 S2P2400 S3P2200 S4P2200 S4P4300 S4P5400 SECONDSP

14 นิยาม Relation ใดๆ อยู่ใน 3 NF ก็ต่อเมื่อ Relation นั้นอยู่ใน 2 NF และทุกๆ Nonkey attribute นั้น ต้องไม่มี transitive กับ Primary key SECOND (S#,STATUS,CITY)  SC (S#,CITY) CS (CITY,STATUS ) S#CITY STATUS FD in the relation SC and CS S#CITY S1London S2Paris S3Paris S4London S5Athens CITYSTATUS Athens30 London20 Paris10 Rome50 SCCS

15 นิยาม Relation ใดๆ อยู่ใน 3 NF ก็ต่อเมื่อ Nonkey attribute มีคุณสมบัติ 2 ข้อ ดังนี้ 1. Mutually independent 2. Fully dependent on the primary key S# STATUS SNAME S# P# QTY ADDRESS P# CITY WEIGHT COLOR PNAME Nonkey attribute คือ attribute ใดๆ ที่ไม่ใช่ส่วนหนึ่งส่วนใดของ primary key ใน relation Mutually independent คือ attribute ตั้งแต่ 2 attributes ขึ้นไป ไม่มี FD กับ attribute อื่นใดเลย คือ Nonkey ทั้งหมดจะต้องเป็นอิสระต่อกันอย่างเด็ดขาดไม่เกี่ยวข้องกัน

16 ORDER-NOORDER-DATEORDER-LINE Ord1 Ord2 6 June May 1996 PART-NO QTY-ORDERED P1 10 P6 30 PART-NO QTY-ORDERED P5 10 P6 50 P2 20 ORDER-NOORDER-DATEPART-NOQTY-ORDERED Ord1 Ord2 6 June May 1996 P1 P6 P5 P6 P ORDERS

17 ORDER-NOORDER-DATE Ord1 Ord2 6 June May 1996 ORDER-NOPART-NOQTY-ORDERED Ord1 Ord2 P1 P6 P5 P6 P ORDERS ORDERS-CONTENTS ORDER-NO PART-NO ORDER-DATE QTY-ORDERS

18 ORDER-NOORDER-DATE ORDER-NO PART-NO QTY-ORDERED

19 PROJECT-IDPERSON-IDMANAGERTIME-SPENT Proj1 Proj2 Proj1 Proj2 Proj3 Proj1 J1 J2 J3 Vichi Joe Vichi Joe Brown Vichi PROJECTS

20 PROJECT-IDMANAGER Proj1 Proj2 Proj3 Vichi Joe Brown PROJECT- ID PERSON-IDTIME-SPENT Proj1 Proj2 Proj1 Proj2 Proj3 Proj1 J1 J2 J PROJECT-ID PERSON-ID MANAGER TIME-SPENT PROJECTS WORK

21 PROJECT-IDMANAGER PROJECT-ID PERSON-ID TIME-SPENT

22 REGISTRATIONOWNERMODELMANUFACTORNO-CYLINDER YX-01 YJ-77 YW-30 YJ-37 YJ-83 George Mary George Mary Andrew Laser Falcon Corolla Laser Corolla Ford Toyota Ford Toyota VEHICLES

23 NO-CYLINDER MANUFACTOR OWNER REGISTRATION-NO MODEL

24 MANUFACTOR OWNER REGISTRATION-NO MODEL MANUFACTOR NO-CYLINDERS

25 REGISTRATION-NOOWNERMODELMANUFACTOR YX-01 YJ-77 YW-30 YJ-37 YJ-83 George Mary George Mary Andrew Laser Falcon Corolla Laser Corolla Ford Toyota Ford Toyota MODELMANUFACTORNO-CYLINDER Laser Falcon Corolla Ford Toyota REGISTRATION VEHICLES1

26 1. LOAN APPLICATION LOAN-APPLICTION- NO APPLICANTAPPLICANT-ADDRESSLOAN-TYPE 1JillCanberraHome 2JoeSydneyMortgage 3JillCanberraPersonal 4MaxMelbourneHome 1. 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.

27 2. CUSTOMER –INVOICES CUSTOMER NAME INVOICE- NO CUSTOMER ADDRESS CUSTOMER SERVICE COST SERVICE DATE Joe6SydneyRepair120June,1992 Joe6SydneyCourse320July,1992 Jill3CanberraRepair80August,1992 Joe6SydneyRepair150October199 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.

28 4. MACHINE-USE OPERATORMACHNEDATEQTY-PARTS PRODUCTS TIME-SPENT ON-MACHNE JoeMach 11 June JoeMach 21 June BillMach 11 June BillMach 22 June 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

29 นิยาม Relation ใดๆ อยู่ใน BCNF ก็ต่อเมื่อ ทุกๆ Determinant ที่มีอยู่ เป็น Candidate key ด้วย S#STATUS CITY Relation S(S#,SNAME,STATUS,CITY) SNAME Candidate key มี S#, SNAME Determinant มี S#, SNAME STATUS, CITY นั้น Mutually independent กัน คือ FD S.CITY  S.STATUS Boyce/Codd Normal form (BCNF)

30 S#SNAMEP#QTY S1 Smith P1 P2 P3 P relation SSP (S#,SNAME,P#,QTY) S# QTY SNAME P# Example 2

31 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)

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

33 S J T 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

34 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 P S Candidate key มี (S,J), (J,P) Determinant มี (S,J), (J,P)

35 นิยาม ของ 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

36 นิยามของ 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

37 COURSETEACHERTEXT Physics Maths Prof.Gran Prof.Brown Prof.Gran Basic mechanics Principles of optics Basic mechanics Vector analysis Trigonometry Example CTX มี 2 MVD 1. CTX.COURSE  CTX.TEACHER 2. CTX.COURSE ---  CTX.TEXT

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

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

40 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

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

42 S#P# S1 S2 P1 P2 P1 P#J# P1 P2 P1 J2 J1 J#S# J2 J1 S1 S2 SPJ S1 S2 P1 P2 P1 J2 J1 J2 J1 Join Over P# Join Over(J#,S#) Original SPJ SP PJ SPJJS

43 ตัวอย่างของการทำ Normalize Order-Entry System ประกอบด้วยข้อมูลเกี่ยวกับ Customers, Item และ orders

44 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

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

46 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)

47 Department EmployeeProjectOffice Job Salary History Phone

48 -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

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

50 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#)

51 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 ถ้ามีให้พิจารณาขั้นต่อไป

52 - 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) ก็ได้

53 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 4. BCNF - Relation R อยู่ใน BCNF ก็ต่อเมื่อทุกๆ FD ใน R เป็น consequence ของ Candidate keys ของ R

54 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 ไม่ได้แก้ไขปัญหาได้ทุกสิ่งทุกอย่าง


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

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


Ads by Google