บทช่วยสอนการออกแบบฐานข้อมูลสำหรับ Google Calendar

 (kb.databasedesignbook.com)
13 คะแนน โดย GN⁺ 2024-07-25 | ยังไม่มีความคิดเห็น | แชร์ทาง WhatsApp

บทนำ

บทช่วยสอนการออกแบบฐานข้อมูลนี้จะแสดงวิธีออกแบบตารางฐานข้อมูลสำหรับโปรเจ็กต์จริงที่มีความซับซ้อน โดยจะออกแบบโคลนของ Google Calendar ซีรีส์นี้อธิบายแนวทางจากหนังสือ "Database Design using Minimal Modeling" โดยจะเริ่มจากสร้างแบบจำลองเชิงตรรกะที่สมบูรณ์สำหรับอธิบายข้อมูลปฏิทิน จากนั้นจึงออกแบบตารางโดยอิงจากแบบจำลองเชิงตรรกะ

ผู้อ่านเป้าหมาย

เป้าหมายของหนังสือเล่มนี้คือช่วยให้ขยับจากไอเดียที่คลุมเครือไปสู่คำจำกัดความที่สมบูรณ์ของตารางฐานข้อมูลได้ ข้อความช่วง 3/4 แรกต้องการเพียงความเข้าใจทั่วไปเกี่ยวกับฐานข้อมูล และอธิบายเรื่องแบบจำลองเชิงตรรกะ ส่วน 1/4 ท้ายอธิบายวิธีย้ายจากแบบจำลองเชิงตรรกะไปสู่โครงสร้างตารางจริง

สารบัญ

  • บทนำ
  • แนวทางของหนังสือเล่มนี้
  • คำอธิบายปัญหา
  • Part 1: อีเวนต์พื้นฐานแบบทั้งวัน
  • Part 2: อีเวนต์แบบอิงเวลา
  • Part 3: อีเวนต์แบบทั้งวันที่เกิดซ้ำ
  • Part 4: การเรนเดอร์หน้าปฏิทิน
  • Part 5: การเรนเดอร์หน้าปฏิทินของอีเวนต์แบบอิงเวลา
  • Part 6: แบบจำลองเชิงตรรกะฉบับสมบูรณ์จนถึงตอนนี้
  • Part 7: การสร้างตาราง SQL
  • บทสรุป
  • ขั้นตอนถัดไป

แนวทางของหนังสือเล่มนี้

ผู้คนมักเริ่มจากการออกแบบตารางก่อน แต่เราจะใช้แนวทางที่ต่างออกไป โดยเขียนแบบจำลองเชิงตรรกะก่อน และกำหนดคุณลักษณะของข้อมูลกับความสัมพันธ์ระหว่างเอนทิตี เมื่อแบบจำลองเชิงตรรกะชัดเจนแล้วจึงค่อยออกแบบตารางจริง

คำอธิบายปัญหา

เราจะสร้างฟังก์ชันหลักของ Google Calendar โดยจะทำข้อมูลที่เกี่ยวข้องกับผู้ใช้ให้น้อยที่สุด อีเวนต์มีคุณลักษณะอย่างชื่อ คำอธิบาย สถานที่ เป็นต้น ส่วนที่ซับซ้อนที่สุดคือเรื่องเวลาและวันที่

Part 1: อีเวนต์พื้นฐานแบบทั้งวัน

แองเคอร์

ก่อนอื่นต้องหาแองเคอร์ก่อน แองเคอร์คือเอนทิตี เช่น ผู้ใช้ (User) และอีเวนต์ (Event) แองเคอร์ทำหน้าที่จัดการ ID และการนับ

คุณลักษณะของผู้ใช้

เราจะสร้างแบบจำลองข้อมูลของผู้ใช้ให้น้อยที่สุด เช่น อีเมล

คุณลักษณะของอีเวนต์แบบทั้งวัน

ต้องเก็บชื่ออีเวนต์ วันที่เริ่มต้น และวันที่สิ้นสุด

ลิงก์

ต้องตัดสินใจว่าจะเก็บข้อมูลว่าผู้ใช้คนใดสร้างอีเวนต์ใดไว้ที่ไหน สิ่งนี้จะจัดการในรูปแบบลิงก์ ไม่ใช่คุณลักษณะ

Part 2: อีเวนต์แบบอิงเวลา

เขตเวลา

เขตเวลาถูกใช้งานในหลายประเทศและหลายภูมิภาค คำจำกัดความของเขตเวลามีการเปลี่ยนแปลงเป็นครั้งคราว เราจะสร้างแบบจำลองขั้นต่ำที่เกี่ยวข้องกับเขตเวลา

คุณลักษณะของเขตเวลา

เราจะเก็บชื่อเขตเวลาที่มนุษย์อ่านเข้าใจได้

คุณลักษณะของอีเวนต์แบบอิงเวลา

จะเก็บชื่ออีเวนต์ เวลาเริ่มต้น และเวลาสิ้นสุด โดยใช้เวลาในท้องถิ่น

ลิงก์

กำหนดลิงก์ระหว่างเขตเวลากับอีเวนต์แบบอิงเวลา

ความคล้ายกันของอีเวนต์แบบวันที่และอีเวนต์แบบเวลา

เราจะพิจารณาความคล้ายกันระหว่างอีเวนต์สองประเภทนี้ โดยการทำ logical modeling ช่วยให้สามารถเลื่อนการตัดสินใจออกไปก่อนได้

Part 3: อีเวนต์แบบทั้งวันที่เกิดซ้ำ

คุณลักษณะ #1, คาบการเกิดซ้ำ

กำหนดคุณลักษณะที่บอกว่าอีเวนต์เกิดซ้ำบ่อยแค่ไหน

คุณลักษณะ #2, คุณลักษณะที่พัวพันกัน

กำหนดคาบของอีเวนต์ที่เกิดซ้ำ

คุณลักษณะ #3

สำหรับอีเวนต์รายเดือน ให้กำหนดว่าจะเกิดซ้ำในวันเดิมหรือในวันในสัปดาห์เดิม

วันในสัปดาห์: ไมโครแองเคอร์

ตัดสินใจว่าจะเก็บข้อมูลวันในสัปดาห์ไว้ที่ไหน และเพิ่มแองเคอร์ใหม่

ลิงก์

กำหนดลิงก์ระหว่างวันในสัปดาห์กับอีเวนต์

ตรวจสอบความสมบูรณ์

ทบทวนข้อกำหนดดั้งเดิมอีกครั้งเพื่อตรวจสอบว่าการทำโมเดลเสร็จสมบูรณ์แล้วหรือไม่

ข้อจำกัดของการเกิดซ้ำ: คุณลักษณะที่พัวพันกันมากขึ้น

กำหนดคุณลักษณะที่บอกว่าอีเวนต์จะเกิดซ้ำไปจนถึงเมื่อใด

Part 4: การเรนเดอร์หน้าปฏิทิน

จนถึงตอนนี้เราได้พูดถึงส่วนที่เป็นการบันทึกข้อมูลของปฏิทิน ตอนนี้จำเป็นต้องแสดงมุมมองปฏิทินรายสัปดาห์ของผู้ใช้

สรุปโดย GN⁺

บทช่วยสอนนี้อธิบายการออกแบบฐานข้อมูลที่ซับซ้อนแบบทีละขั้น ทำให้แม้แต่มือใหม่ก็เข้าใจได้ง่าย โดยจำลองฟังก์ชันหลักของ Google Calendar เพื่อมอบตัวอย่างที่มีประโยชน์และนำไปใช้กับโปรเจ็กต์จริงได้ อธิบายว่าการทำ logical modeling ช่วยป้องกันข้อผิดพลาดในการออกแบบฐานข้อมูล และเชื่อมต่อไปสู่การออกแบบตารางจริงได้อย่างเป็นธรรมชาติ โปรเจ็กต์ที่มีฟังก์ชันคล้ายกันได้แก่ Microsoft Outlook Calendar เป็นต้น

บทความที่เกี่ยวข้อง

ยังไม่มีความคิดเห็น

ยังไม่มีความคิดเห็น