การออกแบบฐานข้อมูลในระดับตรรกะ Logical Database Design สัปดาห์ที่ 2 การออกแบบฐานข้อมูลระดับตรรกะ

วัตถุประสงค์ อธิบายความแตกต่างระหว่างระบบแฟ้มข้อมูล (file processing systems) และระบบจัดการฐานข้อมูล (database systems) ได้ อธิบายถึงองค์ประกอบของระบบการจัดการฐานข้อมูล (database management system- DBMS) ได้ เข้าใจแนวความคิดของแบบจำลองข้อมูลเชิงสัมพันธ์ ซึ่งประกอบด้วย entities, fields, records, files, tables, และ key fields ออกแบบความสัมพันธ์ของข้อมูลและเขียนเป็น แผนภาพแสดงความสัมพันธ์ระหว่างข้อมูล entity-relationship diagram : E-R Diagram) ทราบความหมายของ cardinality, cardinality notation, และ crow’s foot notation สามารถเขียนสามารถแปลงแผนภาพแสดงความสัมพันธ์ให้อยู่ในรูปของตารางในแบบจำลองข้อมูลเชิงสัมพันธ์ได้ สามารถใช้ทฤษฏี normalization โดยปรับให้ตารางอยู่ในรูปแบบของ first, second และ third normal form สัปดาห์ที่ 2 การออกแบบฐานข้อมูลระดับตรรกะ

System development life cycle with logical design phase highlighted สัปดาห์ที่ 2 การออกแบบฐานข้อมูลระดับตรรกะ

แนวความคิดเกี่ยวกับฐานข้อมูล การจัดการกับข้อมูลใช้เดิมใช้ ระบบแฟ้มข้อมูล (file processing systems) แต่มีข้อเสียมากเนื่องมาจากขาดความยืดหยุ่นในการแก้ไข และมีความซ้ำซ้อนของข้อมูล ระบบแฟ้มข้อมูลนั้นต้องอาศัยโปรแกรมเมอร์ที่มีความชำนาญเพื่อพัฒนาโปรแกรมในการอ่านข้อมูลจากแฟ้มข้อมูลนำมาประมวลผล โดยทั่วไปภาษาคอมพิวเตอร์ที่ใช้ในการพัฒนาโปรแกรมเป็นภาษาคอมพิวเตอร์ในยุคที่ 3 เช่นภาษาโคบอล (COBOL) ภาษาฟอร์แทน(FORTAN) และภาษาเบสิก (BASIC) ภาษาซี ( C ) สัปดาห์ที่ 2 การออกแบบฐานข้อมูลระดับตรรกะ

file processing systems Duplicate Data สัปดาห์ที่ 2 การออกแบบฐานข้อมูลระดับตรรกะ

การเขียนโปรแกรมรับข้อมูลทางแป้นพิมพ์และเขียนข้อมูลลงแฟ้มข้อมูล ในภาษา Pascal Program File_write; TYPE Student = RECORD ID : String[8]; Name : String[40]; GPA : Real; End; VAR f : FILE OF Student; s : Student; count : integer; Begin Assign(f,’student.dat’) Rewrite(f); Count := 1; While count <= 5 Do Readln(s.ID,s.Name); Readln(s.GPA); Write(f,s); count := count+1; Close(f); End. การนิยามโครงสร้างของข้อมูลในแฟ้มข้อมูล ได้แก่ ชื่อฟิลด์ และขนาดของฟิลด์ไว้ ในส่วนนิยามข้อมูล ด้วยเหตุนี้ทำให้การพัฒนาโปรแกรมแต่ละโปรแกรมขึ้นใช้งานนั้นผูกติดกับแฟ้มข้อมูลต่าง ๆ ซึ่งเป็นปัญหาเรื่องโครงสร้างข้อมูลและตัวโปรแกรมไม่เป็นอิสระต่อกัน ดังนั้นเมื่อมีการเปลี่ยนแปลงโครงสร้างของแฟ้มข้อมูลใดแฟ้มข้อมูลหนึ่งจำเป็นต้องแก้ไขโปรแกรมต่าง ๆ ที่มีการเรียกใช้ข้อมูลจากแฟ้มข้อมูลนั้นด้วย สัปดาห์ที่ 2 การออกแบบฐานข้อมูลระดับตรรกะ

ปัญหาในการจัดการข้อมูลด้วยแฟ้มข้อมูล ปัญหาความซ้ำซ้อนกันของข้อมูลและความขัดแย้งกันของข้อมูล ( Data redundancy and inconsistency ) ความยากในการเข้าถึงข้อมูล (Difficulty in accessing data) ความไม่เป็นอันหนึ่งอันเดียวกันของข้อมูล (Data Isolation) การกำหนดความถูกต้องของข้อมูล (Integrity problem) ปัญหาที่เกิดจากการ Update ข้อมูลที่อยู่อย่างกระจัดกระจาย (Atomicity of Update ) ปัญหาการใช้ข้อมูลตัวเดียวพร้อมกันจากผู้ใช้หลายคน (Concurrent access by multiple users) ความปลอดภัยของข้อมูล (Security problem) สัปดาห์ที่ 2 การออกแบบฐานข้อมูลระดับตรรกะ

ระบบฐานข้อมูล (Database System) แนวคิดของระบบฐานข้อมูล คือ การเก็บรวบรวมข้อมูลที่มีความสัมพันธ์ไว้ในที่เดียวกัน ซึ่งจากเดิมการจัดเก็บอยู่ในแฟ้มข้อมูลที่ถูกจัดเก็บแบบกระจายไปตามหน่วยงาน โดยการจัดเก็บในรูปของฐานข้อมูลจะเป็นแหล่งศูนย์รวมของข้อมูลจากแผนกต่างๆ ผู้ใช้งานแต่ละแผนกสามารถใช้ข้อมูลจากส่วนกลางนี้ได้ ลดความซ้ำซ้อนกันของข้อมูล สัปดาห์ที่ 2 การออกแบบฐานข้อมูลระดับตรรกะ

ระบบการจัดการฐานข้อมูล (Database Management System: DBMS) ระบบจัดการฐานข้อมูล หรือมักเรียกสั้น ๆ ว่า DBMS คือ โปรแกรมที่ใช้เป็นเครื่องมือในการจัดการฐานข้อมูล ซึ่ง DBMS จะประกอบด้วยฟังก์ชันหน้าที่ต่าง ๆ ในการจัดการกับข้อมูล รวมทั้งภาษาที่ใช้ทำงานกับข้อมูล DBMS จะเป็นตัวกลางระหว่าง ฐานข้อมูล กับ ผู้ใช้ โดยจะทำหน้าที่ในการสร้าง เรียกใช้ และการปรับปรุงข้อมูล สัปดาห์ที่ 2 การออกแบบฐานข้อมูลระดับตรรกะ

Database System DBMS สัปดาห์ที่ 2 การออกแบบฐานข้อมูลระดับตรรกะ containing centralized shared data Application #1 #2 #3 สัปดาห์ที่ 2 การออกแบบฐานข้อมูลระดับตรรกะ

ความสำคัญของระบบฐานข้อมูล ลดการเก็บข้อมูลที่ซ้ำซ้อน รักษาความถูกต้องของข้อมูล การป้องกันและการรักษาความปลอดภัยให้กับข้อมูล ทำได้สะดวก สามารถใช้ข้อมูลร่วมกันได้ มีความเป็นอิสระของข้อมูล สามารถขยายงานได้ง่าย ทำให้ข้อมูลบูรณะกลับสู่สภาพปกติได้อย่างรวดเร็วและมีมาตรฐาน สัปดาห์ที่ 2 การออกแบบฐานข้อมูลระดับตรรกะ

สถาปัตยกรรมของฐานข้อมูล (Database Architecture) สัปดาห์ที่ 2 การออกแบบฐานข้อมูลระดับตรรกะ

ขั้นตอนการออกแบบฐานข้อมูล แบ่งออกเป็น 3 ระดับ คือ Conceptual Design Logical Design Physical Design สัปดาห์ที่ 2 การออกแบบฐานข้อมูลระดับตรรกะ

ขั้นตอนการออกแบบฐานข้อมูล Conceptual Design : การอธิบายถึงข้อมูลและความสัมพันธ์กันของข้อมูลในระบบที่เราวิเคราะห์มา โดยกำหนดว่าจากความต้องการของผู้ใช้ จะต้องมีข้อมูลอะไรบ้าง และข้อมูลแต่ละตัวมีความสัมพันธ์กันอย่างไร และมีข้อจำกัดอะไรบ้าง แสดงโดยใช้ High-level conceptual data model ในที่นี้เราใช้ E-R Model Logical Design : จากโครงสร้างของฐานข้อมูลที่ได้จากการออกแบบฐานข้อมูลในระดับ Conceptual แล้วนำโครงสร้างนั้นมาอิงกับ Data Model เพื่อแปลงเป็นตาราง (Relational Data Model) หรือความสัมพันธ์ตามแนวคิดของ Data Model จากนั้นต้องมีการปรับปรุงโครงสร้างของฐานข้อมูลให้มีความซ้ำซ้อนกันน้อยที่สุด โดยใช้ทฤษฎีการทำ Normalization Physical Design : จากนั้นเป็นขั้นตอนการ implement โดยนำ DBMS มาใช้ implement ผลลัพธ์ที่ได้ คือ database schema และขั้นตอนสุดท้าย คือการออกแบบการจัดเก็บข้อมูลลงใน disk เป็นเรื่องของ internal storage structure การเข้าถึงข้อมูลจะทำอย่างไร สัปดาห์ที่ 2 การออกแบบฐานข้อมูลระดับตรรกะ

แบบจำลองฐานข้อมูล (Database Model) แบบจำลองฐานข้อมูล คือ เทคนิคที่ใช้ในการจัดโครงสร้างและรูปแบบในการนำเสนอความสัมพันธ์ของข้อมูล สัปดาห์ที่ 2 การออกแบบฐานข้อมูลระดับตรรกะ

แบบจำลองฐานข้อมูลเชิงสัมพันธ์ (Relational Database) Relational Model ถูก introduced โดย Ted Codd ในปี 1970 ซึ่ง Relational Model represent ข้อมูลอยู่ในรูปตาราง 2 มิติ เรียกตารางนี้ว่า Relation แต่ละคอลัมน์ของตารางความสัมพันธ์ เรียกว่า แอททริบิว(attribute) ของความสัมพันธ์ ค่าและขอบเขตของข้อมูลของแอททริบิวเรียกว่า โดเมน(Domain) แต่ละแถวของตารางความสัมพันธ์ เรียกว่า แถว (Row) หรือ ทูเพิล(tuple) ของความสัมพันธ์ แต่ละแถว (Row) จะต้องไม่ซ้ำกัน ไม่มีลำดับของแถว (Row) ข้อมูลในแต่ละคอลัมน์จะต้องเป็นหนึ่งเดียว customer-name Main North Park customer-street Harrison Rye Pittsfield customer-city attributes (or columns) tuples (or rows) Jones Smith Curry Lindsay สัปดาห์ที่ 2 การออกแบบฐานข้อมูลระดับตรรกะ

ตัวอย่างของฐานข้อมูลเชิงสัมพันธ์ สัปดาห์ที่ 2 การออกแบบฐานข้อมูลระดับตรรกะ

Relational Integrity Constraint Constraint คือ เงื่อนไข, ข้อจำกัด ที่ทุก ๆ Relation instances ต้องยึดถือ Three main type of constraint 1. Key constraint 2. Entity integrity constraint 3. Referential integrity constraint สัปดาห์ที่ 2 การออกแบบฐานข้อมูลระดับตรรกะ

Key constraint ฐานข้อมูลเชิงสัมพันธ์จะจัดเก็บข้อมูลในตาราง 2 มิติ ที่ประกอบด้วยจำนวนแถวและคอลัมน์ซึ่งจำเป็นต้องมีการกำหนดคอลัมน์หรือกลุ่มของคอลัมน์เพื่อใช้ในการระบุแถวต่าง ๆ เพื่อทำให้แต่ละแถวมีความแตกต่างกันหรือมีความเป็นเอกลักษณ์ (Uniqueness property) ซึ่งเรียกว่า คีย์ Superkey คือ แอททริบิวต์หรือกลุ่มของแอททริบิวต์ที่บ่งบอกถึงความเป็นเอกลักษณ์ (uniquely) ของแต่ละ Row ใน Relation Candidate key คือ คีย์คู่แข่ง ซึ่งก็คือ Superkey โดยจะไม่มีสับเซต ของคีย์ใดในคีย์คู่แข่งที่สามารถกำหนดเป็น superkey ได้อีก Primary Key (PK) คือ Candidate key นั่นเอง แต่เป็น Candidate key ที่ผ่านการคัดเลือกเพื่อให้คีย์หลัก และใช้ในการอ้างอิงความเป็นเอกลักษณ์ของ Relationนั้น ๆ Alternate Key คือ Candidate Key อื่นๆ ที่ไม่ได้เป็น Primary Key Foreign key (FK) คือคีย์นอก Primary Key (PK) ของ Relationหนึ่งและไปปรากฏเป็น Attribute ในอีกรีเลชั่นหนึ่ง ซึ่ง Foreign key (FK) จัดเป็นคีย์ที่สำคัญมากในฐานข้อมูลเชิงสัมพันธ์เพราะว่าเป็นตัวชี้ในการเชื่อมความสัมพันธ์ระหว่าง Table สัปดาห์ที่ 2 การออกแบบฐานข้อมูลระดับตรรกะ

Entity integrity constraint “Primary Key ของแต่ละ Table ไม่สามารถมีค่าเป็น Null ได้” ** Null คือ ไม่ทราบค่าหรือ ไม่มีค่า Referential Integrity “ค่าของ foreign key จะต้องมาจากค่าของ primary key หรือไม่ก็มีค่าเป็น Null” สัปดาห์ที่ 2 การออกแบบฐานข้อมูลระดับตรรกะ

แผนภาพแสดงความสัมพันธ์ระหว่างข้อมูล (Entity-Relationship Diagram) องค์ประกอบที่สำคัญของ E-R Diagram Entity, Associative Entity Attribute Relationship Relationship Degree Relationship Cardinality สัปดาห์ที่ 2 การออกแบบฐานข้อมูลระดับตรรกะ

สัญลักษณ์ที่ใช้ใน E-R Diagram สัปดาห์ที่ 2 การออกแบบฐานข้อมูลระดับตรรกะ

ตัวอย่าง E-R Diagram สัปดาห์ที่ 2 การออกแบบฐานข้อมูลระดับตรรกะ

Transforming ER Diagrams into Relations 1.สำหรับ Regular Entities ให้สร้างเป็น 1 Relationโดย Simple attributes: จะกลายเป็น attributes ของ Table Composite attributes: เอา ส่วนประกอบย่อยของ Composite attribute มาเป็น attributes ของ Table Multi-valued Attribute – สร้าง Relationขึ้นมาใหม่ประกอบด้วย Attribute ที่เป็น Multivalues และใช้ Primary Key จาก Entity หลักร่วมกับ attributes ใน Relationนั้น สัปดาห์ที่ 2 การออกแบบฐานข้อมูลระดับตรรกะ

Mapping a regular entity (a) CUSTOMER entity type with simple attributes (b) CUSTOMER relation สัปดาห์ที่ 2 การออกแบบฐานข้อมูลระดับตรรกะ

Mapping a composite attribute (a) CUSTOMER entity type with composite attribute (b) CUSTOMER relation with address detail สัปดาห์ที่ 2 การออกแบบฐานข้อมูลระดับตรรกะ

Multivalued attribute becomes a separate relation with foreign key Mapping a multivalued attribute (a) Multivalued attribute becomes a separate relation with foreign key (b) 1 – to – many relationship between original entity and new relation สัปดาห์ที่ 2 การออกแบบฐานข้อมูลระดับตรรกะ

Transforming ER Diagrams into Relations 2. สำหรับ Weak Entities ให้สร้าง Relationขึ้นมาใหม่ โดย Attribute คือ Attribute ของ Weak Entities รวมกับ Primary Key ของ Strong Entity สัปดาห์ที่ 2 การออกแบบฐานข้อมูลระดับตรรกะ

Example of mapping a weak entity (a) Weak entity DEPENDENT สัปดาห์ที่ 2 การออกแบบฐานข้อมูลระดับตรรกะ

Relations resulting from weak entity NOTE: the domain constraint for the foreign key should NOT allow null value if DEPENDENT is a weak entity Foreign key Composite primary key สัปดาห์ที่ 2 การออกแบบฐานข้อมูลระดับตรรกะ

Transforming ER Diagrams into Relations 3. สำหรับความสัมพันธ์ แบบ Binary Relationships One-to-Many – เอา Primary key ของ Entity ฝั่ง One มาเป็น foreign key ให้ Relationของ Entity ฝั่ง many Many-to-Many – สร้าง Relationขึ้นมาใหม่ โดยเอา primary keys ของทั้งสอง Entity มาเป็น primary key ร่วมกัน One-to-One – เอา Primary key ของ Entity ที่มีความสัมพันธ์ แบบ mandatory (บังคับให้ทุกสมาชิกใน Entity เข้าร่วมในความสัมพันธ์) มาเป็น foreign key ใน Relationของ Entity ฝั่งที่เป็น optional สัปดาห์ที่ 2 การออกแบบฐานข้อมูลระดับตรรกะ

Example of mapping a 1:M relationship (a) Relationship between customers and orders Note the mandatory one สัปดาห์ที่ 2 การออกแบบฐานข้อมูลระดับตรรกะ

Mapping the relationship Again, no null value in the foreign key…this is because of the mandatory minimum cardinality Foreign key สัปดาห์ที่ 2 การออกแบบฐานข้อมูลระดับตรรกะ

Example of mapping an M:N relationship (a) ER diagram (M:N) The Supplies relationship will need to become a separate relation สัปดาห์ที่ 2 การออกแบบฐานข้อมูลระดับตรรกะ

New intersection relation Three resulting relations Composite primary key New intersection relation Foreign key สัปดาห์ที่ 2 การออกแบบฐานข้อมูลระดับตรรกะ

Mapping a binary 1:1 relationship สัปดาห์ที่ 2 การออกแบบฐานข้อมูลระดับตรรกะ

Resulting relations สัปดาห์ที่ 2 การออกแบบฐานข้อมูลระดับตรรกะ

Transforming ER Diagrams into Relations 4. สำหรับความสัมพันธ์ แบบ Unary Relationships One-to-Many – เอา Primary Key ของ Entity ของตัวเองมาเป็น foreign key อีกครั้งหนึ่ง Many-to-Many – สร้าง Relationขึ้นมาใหม่ โดยTwo relations: สร้างขึ้นมาใหม่อีก 1 Relationแล้วเอา Primary Key ของ Entity ตัวเองมาเป็น Primary Key ร่วมกับ Attribute ใหม่ที่สร้างขึ้นมาให้ร่วมกันแล้วมีคุณสมบัติ Unique สัปดาห์ที่ 2 การออกแบบฐานข้อมูลระดับตรรกะ

Mapping a unary 1:N relationship (a) EMPLOYEE entity with Manages relationship (b) EMPLOYEE relation with recursive foreign key สัปดาห์ที่ 2 การออกแบบฐานข้อมูลระดับตรรกะ

Figure 5-18: Mapping a unary M:N relationship (a) Bill-of-materials relationships (M:N) (b) ITEM and COMPONENT relations สัปดาห์ที่ 2 การออกแบบฐานข้อมูลระดับตรรกะ

แบบฝึกหัด Mapping E-R Diagram เป็น Relation (Table) สัปดาห์ที่ 2 การออกแบบฐานข้อมูลระดับตรรกะ

สัปดาห์ที่ 2 การออกแบบฐานข้อมูลระดับตรรกะ

Normalization Normalization คือ กระบวนการปรับปรุงโครงสร้างข้อมูลของฐานข้อมูลที่มีความซ้ำซ้อนให้อยู่ในรูปแบบที่เป็นบรรทัดฐาน Normal Form มีอยู่ 3 ระดับด้วยกัน คือ 1. Normal Form ระดับที่ 1 หรือเรียกว่า 1NF 2. Normal Form ระดับที่ 2 หรือเรียกว่า 2NF 3. Normal Form ระดับที่ 3 หรือเรียกว่า 3NF นอกจากนี้ยังมีระดับที่ทำให้ Normal Form ระดับที่ 3 มีความแข็งแกร่งขึ้นกว่าเดิม เรียกว่า BCNF ( Boyce-Codd Normal Form) ซึ่งพัฒนาขึ้นโดย R.Boyce และ E.F.Codd โดย Normal Form ทุกระดับตั้งอยู่บนพื้นฐานของฟังก์ชันการขึ้นต่อกันระหว่างแอททริบิวต์ของ Relation ( Functional Dependency ) Normal Form ในระดับที่สูงขึ้นไปอีกที่อยู่ถัดจาก BCNF ก็ได้ถูกพัฒนาขึ้น คือ Normal Form ระดับที่ 4 ( 4NF) และระดับที่ 5 (5NF) ซึ่งพัฒนาโดย Fagin(1977,1979) อย่างไรก็ตามรูปแบบ 4NF และ 5NF ในทางปฏิบัติถือว่าเกิดขึ้นได้ยากมาก สัปดาห์ที่ 2 การออกแบบฐานข้อมูลระดับตรรกะ

วัตถุประสงค์ในการทำให้เป็นรูปแบบบรรทัดฐาน เพื่อลดความซ้ำซ้อนของข้อมูลที่จัดเก็บในแต่ละรีเลชัน ทำให้เกิดประโยชน์ดังนี้ ประหยัดเนื้อที่ในการจัดเก็บข้อมูล ลดปัญหาขาดความถูกต้องของข้อมูล ลดปัญหาที่เกิดจากการปรับปรุง เพิ่มเติม และลบข้อมูล สัปดาห์ที่ 2 การออกแบบฐานข้อมูลระดับตรรกะ

กระบวนการ Normalization Steps in normalization สัปดาห์ที่ 2 การออกแบบฐานข้อมูลระดับตรรกะ

First Normal Form (1NF) “Relation ที่อยู่ในรูป 1NF ถ้า ค่าของ Attribute เป็น atomic นั่นคือ มีค่าเพียงค่าเดียวเท่านั้น ไม่สามารถแบ่งแยกได้” สัปดาห์ที่ 2 การออกแบบฐานข้อมูลระดับตรรกะ

Normalization into 1 NF Dname Dnumber Dmgrssn Dlocation Research 5 33344 {Bellaire,sugarland,houston} Administration 5 98765 stafford Headquarter 1 88866 Houston Relation schema that is not in 1NF 1NF relaton with redundancy Dname Dnumber Dmgrssn Dlocation Research 5 33344 Bellaire Research 5 33344 sugarland Research 5 33344 houston Administration 5 98765 stafford Headquarter 1 88866 Houston สัปดาห์ที่ 2 การออกแบบฐานข้อมูลระดับตรรกะ

ฟังก์ชันการขึ้นตรงต่อกัน (Functionally Dependent :FD) ใน Relation ใดๆ Attribute Y เป็น FD กับ Attribute X ก็ต่อเมื่อ ถ้าทราบค่า X จะต้องทราบค่าของ Y สัญลักษณ์ S.SID  S.SName S.SID  S.City S.SID  S.(SName,City) สัปดาห์ที่ 2 การออกแบบฐานข้อมูลระดับตรรกะ

2st Normal Form (2NF) Relation ใดๆจะเป็น 2NF ก็ต่อเมื่อ ทุกๆ Non-key Attribute ต้องเป็น Fully FD กับ Primary Key เท่านั้นนั่นคือ ไม่มี Non-key Attribute ตัวใดที่เป็น Partially FD กับ Primary key สัปดาห์ที่ 2 การออกแบบฐานข้อมูลระดับตรรกะ

ไม่อยู่ใน 2 NF เนื่องจาก FD2,FD3 Key Attribute SSN PNUMBER HOURS ENAME PNAME PLOCATION FD1 Non-Key Attribute FD2 FD3 ไม่อยู่ใน 2 NF เนื่องจาก FD2,FD3 สัปดาห์ที่ 2 การออกแบบฐานข้อมูลระดับตรรกะ

Second Normal Form SSN PNUMBER HOURS ENAME PNAME PLOCATION Emp_Proj SSN PNUMBER HOURS ENAME PNAME PLOCATION FD1 Ssn,Pnumber  Hours FD2 Ssn  Ename FD3 Pnumber  Pname,Plocation SSN PNUMBER HOURS Emp_Proj1 แตกให้อยู่ใน รูป2 NF SSN ENAME Emp_Proj2 PNUMBER PNAME PLOCATION Emp_Proj3 สัปดาห์ที่ 2 การออกแบบฐานข้อมูลระดับตรรกะ

Functional Dependencies in EMPLOYEE EmpID CourseTitle DateCompleted Salary DeptName Name Dependency on entire primary key EmpID, CourseTitle  DateCompleted EmpID  Name, DeptName, Salary Dependency on only part of the key Therefore, NOT in 2nd Normal Form!! สัปดาห์ที่ 2 การออกแบบฐานข้อมูลระดับตรรกะ

Getting it into 2nd Normal Form decomposed into two separate relations Both are full functional dependencies EmpID Salary DeptName Name CourseTitle DateCompleted EmpID สัปดาห์ที่ 2 การออกแบบฐานข้อมูลระดับตรรกะ

“Relation ที่อยู่ในรูปของ 3NF ก็ต่อเมื่อ Third Normal Form : 3NF “Relation ที่อยู่ในรูปของ 3NF ก็ต่อเมื่อ 1.Relation ที่อยู่ในรูป 2 NF 2.ต้องไม่มี FD ระหว่าง Non-key Attribute หรือไม่มี Transitively FD on Primary Key” สัปดาห์ที่ 2 การออกแบบฐานข้อมูลระดับตรรกะ

Relation with transitive dependency (a) SALES relation with simple data สัปดาห์ที่ 2 การออกแบบฐานข้อมูลระดับตรรกะ

BUT Salesperson  Region Relation with transitive dependency CustID  Name CustID  Salesperson CustID  Region All this is OK (2nd NF) BUT Salesperson  Region FD ระหว่าง Non-key Attribute สัปดาห์ที่ 2 การออกแบบฐานข้อมูลระดับตรรกะ

Removing a transitive dependency (a) Decomposing the SALES relation สัปดาห์ที่ 2 การออกแบบฐานข้อมูลระดับตรรกะ

Relations in 3NF Now, there are no transitive dependencies… Salesperson  Region CustID  Name CustID  Salesperson Now, there are no transitive dependencies… Both relations are in 3rd NF สัปดาห์ที่ 2 การออกแบบฐานข้อมูลระดับตรรกะ