|
 |
| |
รบกวนดูการออกแบบฐานข้อมูลตามทฤษฎี Normalization ค่ะ แอบงงว่า ออกแบบถูกต้องหรือไม่ค่ะ |
| |
 |
|
|
 |
 |
|
สมมติว่าตารางรวม(Table A)ซึ่ง PK(Composite key)=รหัสนิสิต,รหัสโครงการ,ลำดับคำถาม
(รหัสนิสิต,ชื่อ,นามสกุล,รหัสโครงการ,ชื่อโครงการ,ลำดับคำถาม,รายละเอียดคำถาม,คะแนนความพึงพอใจ,รหัสผู้ใช้ระบบ,Username, Password,สถานะผู้ใช้ระบบ,คำถามกันลืม Password,คำตอบกันลืมPassword)
แล้วทำการทำ Normalization ระดับที่ 2 แยกตารางใหม่ที่ non-key ขึ้นกับบางส่วนของคีย์ผสม
ได้ตารางดังนี้
Table B ***** PK = รหัสนิสิต
(รหัสนิสิต,ชื่อ,นามสกุล)
Table C PK = รหัสโครงการ
(รหัสโครงการ,ชื่อโครงการ)
Table D PK = ลำดับคำถาม
(ลำดับคำถาม,รายละเอียดคำถาม)
Table A -> Table E PK(Composite key)=รหัสนิสิต,รหัสโครงการ,ลำดับคำถาม
(รหัสนิสิต,รหัสโครงการ,ลำดับคำถาม,คะแนนความพึงพอใจ, รหัสผู้ใช้ระบบ,Username, Password
,สถานะผู้ใช้ระบบ,คำถามกันลืม Password,คำตอบกันลืมPassword)
แล้วทำการทำ Normalization ระดับที่ 3 แยกตารางใหม่ที่ non-key ขึ้นกับ non-key
ได้ตารางดังนี้
Table F
(รหัสผู้ใช้ระบบ,Username, Password,สถานะผู้ใช้ระบบ,คำถามกันลืม Password,คำตอบกันลืมPassword)
Table E -> Table G
(รหัสนิสิต,รหัสโครงการ,ลำดับคำถาม,คะแนนความพึงพอใจ,***รหัสผู้ใช้ระบบ***)
สิ่งที่จะถามคือ
1.จำเป็นไหมค่ะว่าต้องมีฟิวด์***รหัสผู้ใช้ระบบ***อยู่ใน Table G
คือในชีสที่เรียน จะมีการทิ้งฟิวด์ที่ถูกนำไปตั้งเป็น pkของตารางใหม่(Table F)ไว้ แต่ดูแล้วหน้าตาตารางมันแปล่งๆ หน่ะค่ะ
2.และ ใน Table B สามารถเขียนได้เป็น (รหัสนิสิต,ชื่อ,นามสกุล,รหัสผู้ใช้ระบบ) ซึ่งต้องการให้รหัสผู้ใช้ระบบเป็นFK ไปยัง Table F
ได้ไหมค่ะ ตามทฤษฎีแล้วสามารถทำได้ไหมค่ะ คือต้องเขียนการออกแบบฐานข้อมูลแบบ NF ให้อาจารย์ดูหน่ะค่ะ
3.หากทำไม่ได้ ตารางไหนควรแก้ให้มีหรือไม่มีฟิวด์ไหนค่ะ ขอบคุณค่ะ
Tag : PHP
|
|
|
 |
 |
 |
 |
| Date :
2010-08-08 23:37:19 |
By :
nuie |
View :
1968 |
Reply :
1 |
|
 |
 |
 |
 |
|
|
|
|
 |
 |
|
 |
 |
| |
|
|
|
| |
|
สวัสดีครับ
บอกก่อนว่า ตัวผมเองก็ลืมไปแล้ว Normalization(แล้วเข้ามาตอบทำไม ใช่มะ)
ผมเดา ๆ ว่าน่าจะเป็นงานที่อาจารย์ให้ทำรึเปล่าครับ หากใช่ แล้วต้องทำแบบ Normalization เท่านั้นก็พยายามละกันครับ
แต่ถ้าหากไม่ใช่งานที่อาจารย์ให้ทำ หรือเป็นงานที่ไม่มีการจำเพาะแจะจงว่าต้องทำแบบ Normalization ละก็ แนะนำว่า ถ้าไม่จำเป็นก็ไม่ต้องทำแบบ Normalization ครับ
ตั้งแต่รู้เรื่อง Normalization จนถึงทุกวันนี้ ยังไม่เคยได้ใช้จริง ๆ เลย ขนาดไปถาม Programmer เกี่ยวกับ Database ของบริษัทว่าจะทำ Normalization มั้ย เค้าก็บอกว่าควรทำ แต่ก็ยังไม่ได้ทำ(เดาได้เลยว่า งานล้น และขนาด Database มันใหญ่มากแล้ว มีการใช้งานตลอดเวลา จะทำก็เสียเวลาเยอะมาก แล้วต้องมานั่ง Test อีก ไม่คุ้ม)
ผมว่าจริง ๆ แล้วสิ่งที่น่าสนใจของ Normalization คือ Concept(แนวความคิด) ทำให้มีข้อดีต่าง ๆ ในการจัดการกับ Database แต่ต้องแลกกับ
- การ Design ที่ต้องรู้โครงสร้าง และรายละเอียดทั้งหมด (ต้องไปเค้นจาก End User ซึ่งส่วนใหญ่บอกไม่หมด ตอนนั้นนึกไม่ออกจนกว่าจะได้ทำ)
- Requirement ต่าง ๆ
- ระยะเวลาที่เหมาะสม ไม่ว่าจะเป็นการสร้าง แก้ไขต่าง ๆ (ส่วนใหญ่ งานมีแต่เอาเร็ว ๆ เอาเดี๋ยวนั้น)
หากเป็น Database เล็ก ๆ จะมีข้อเสียเพียบ
- เสียเวลาการวางโครงสร้าง และ Design เกินความจำเป็น
- ทำให้ Database ใหญ่กว่าที่ควร (ทั้ง ๆ ที่ระบบเล็ก ๆ เก็บข้อมูลไม่เท่าไหร่ แต่มี Table แตกออก ต้องใช้คำสั่ง Query ที่ยุ่งยากกว่าที่ควร)
- เวลาจะแก้ไขอะไร ต้องมานั่งดูโครงสร้าง (ทั่วไป Add ฟิลด์ก็เสร็จแล้ว)
ดังนั้น จะเห็นได้ว่ามีความยุ่งยาก ซับซ้อน และต้องใช้ระยะเวลาพอสมควร หากไม่มีความจำเป็นจริง ๆ ไม่แนะนำให้ทำครับ
|
| |
|
|
| |
| Date :
2010-08-09 10:16:47 |
By :
winphp |
|
|
| |
|
|
|
|
|
| |
|
|
|
|
|
| |
|
 Load balance : Server 00
|
