ในท้ายที่สุดปัญหาการวิเคราะห์จะย้อนกลับไปที่ข้อมูลที่อยู่เบื้องหลัง บันทึกของลูกค้าที่ซ้ำซ้อน ตัวเลขรายรับที่ไม่ตรงกันในรายงานต่างๆ และแดชบอร์ดที่ขัดแย้งกันไม่ใช่ปัญหาด้านการแสดงภาพหรือคำขอ แต่เป็นปัญหาด้านสคีมา และ Data Normalization คือวิธีที่ทีมแก้ไขปัญหาดังกล่าวที่แหล่งที่มา

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

ประเด็นสำคัญ

• Data Normalization จะจัดโครงสร้างฐานข้อมูลเชิงสัมพันธ์เพื่อให้ข้อมูลแต่ละส่วนอยู่ตรงตามที่อยู่ ซึ่งจะช่วยขจัดค่าที่ซ้ำซ้อนและขัดแย้งกัน

• ทีมวิเคราะห์ใช้ Normalization ข้ามไปป์ไลน์ได้ โดยสร้างตารางเอนทิตีหลักแบบ Normalization ก่อน จากนั้นจึงสร้างเลเยอร์การรายงานแบบไม่ได้ทำ Normalization ซ้อนไว้ด้านบน

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

Data Normalization คืออะไร

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

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

เหตุใด Data Normalization จึงมีความสำคัญต่อความแม่นยำและการกำกับดูแลการวิเคราะห์

ข้อมูลที่ไม่ได้ทำ Normalization อาจทำให้เกิดปัญหาหลายประเภทที่จะทวีความรุนแรงขึ้นเมื่อข้อมูลมีขนาดใหญ่ขึ้น

แต่ละข้อต่อไปนี้ถือเป็นข้อบกพร่องทางโครงสร้างในตัวสคีมาเอง:

• ความผิดปกติในการอัปเดต: สิ่งเหล่านี้จะเกิดขึ้นเมื่อข้อเท็จจริงเดียวกันปรากฏในหลายแถว หากมีการเก็บชื่อแพ็กเกจการสมัครใช้งานไว้โดยตรงในทุกแถวของใบแจ้งหนี้ การเปลี่ยนชื่อแพ็กเกจหมายถึงการอัปเดตบันทึกหลายพันรายการ และหากพลาดไปเพียงรายการเดียวก็จะเกิดความคลาดเคลื่อน ในสคีมาแบบ Normalization ชื่อแพ็กเกจจะอยู่ในตารางแพ็กเกจ ส่วนใบแจ้งหนี้จะเก็บเฉพาะ plan_id เท่านั้น

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

• ความผิดปกติในการลบ: สิ่งเหล่านี้จะเกิดขึ้นเมื่อการลบบันทึกที่ระบุจะลบข้อมูลสำคัญที่ไม่เกี่ยวข้องออกไปโดยไม่ได้ตั้งใจ ลบคำสั่งซื้อล่าสุดของลูกค้าจากตารางแบบแบน แล้วข้อมูลติดต่อก็จะสูญหายไปด้วยเนื่องจากไม่มีที่อยู่เป็นของตัวเอง

รูปแบบหลักของ Normalization มีอะไรบ้าง

รูปแบบ Normalization คือลำดับของกฎที่เข้มงวดมากขึ้นเรื่อยๆ สำหรับวิธีการจัดโครงสร้างข้อมูล

ทีมที่ใช้ Data Normalization จำเป็นต้องเข้าใจรูปแบบจนถึง Third Normal Form (3NF) เพื่อตัดสินใจเกี่ยวกับสคีมาได้ดี ฐานข้อมูลมักจะอธิบายว่าเป็น "แบบ Normalization" หากเป็นไปตาม 3NF

• First Normal Form (1NF): รูปแบบนี้กำหนดให้ทุกคอลัมน์เก็บค่าอะตอมิกโดยไม่มีรายการ สตริงที่คั่นด้วยเครื่องหมายจุลภาค และอาร์เรย์ที่รวมอยู่ในฟิลด์เดียว คอลัมน์ผลิตภัณฑ์ที่มี "shirt, pants, jacket" จะไม่ผ่าน 1NF แถว 3 แถวที่มี product_id และ product_name จะผ่าน

• Second Normal Form (2NF): รูปแบบนี้สร้างขึ้นจาก 1NF โดยกำหนดให้ทุกคอลัมน์ที่ไม่ใช่คีย์ต้องอิงตามคีย์หลักทั้งหมด ไม่ใช่เพียงบางส่วนเท่านั้น หากตารางบรรทัดรายการใช้ "(order_id, product_id)" เป็นคีย์แต่จัดเก็บเมืองของลูกค้าด้วย ซึ่งอิงตาม order_id เท่านั้น นั่นถือเป็นการพึ่งพาบางส่วนและการละเมิด 2NF เมืองของลูกค้าจัดอยู่ในตารางคำสั่งซื้อ

• Third Normal Form (3NF): รูปแบบนี้กำจัดการพึ่งพาเชิงกรรม ซึ่งหมายถึงคอลัมน์ที่ไม่ใช่คีย์ที่ขึ้นอยู่กับคอลัมน์ที่ไม่ใช่คีย์อื่นๆ แทนที่จะอิงตามตัวคีย์เอง หากตารางคำสั่งซื้อเก็บทั้ง zip_code และ city และระบบจะระบุเมืองตามรหัสไปรษณีย์แทนที่จะเป็นคำสั่งซื้อ ฟิลด์เหล่านั้นจะจัดอยู่ในตารางภูมิศาสตร์แยกต่างหาก

• Boyce-Codd Normal Form (BCNF): นี่เป็นเวอร์ชันที่เข้มงวดกว่าของ 3NF ซึ่งจัดการกับกรณีขอบเขตที่เกี่ยวข้องกับคีย์ตัวเลือกที่ทับซ้อนกัน สำหรับสคีมาวิเคราะห์ การเข้าถึง 3NF ก็เพียงพอแล้ว

การทำ Data Normalization ทำงานอย่างไรในทางปฏิบัติ

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

ตารางคำสั่งซื้อที่ไม่ได้ทำ Normalization

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

หลังจากการทำ Normalization จะมี 3 ตารางดังนี้

• ลูกค้า: customer_id, name, email
  
• ผลิตภัณฑ์: product_id, name, category
  
• คำสั่งซื้อ: order_id, customer_id, product_id, qty, unit_price
  

อีเมลของ Ana มีอยู่ครั้งเดียว หมวดหมู่ของหูฟังมีอยู่ครั้งเดียว คำสั่งซื้ออ้างอิงถึงทั้งสองตารางด้วยรหัส คำสั่ง SELECT แบบ Two-Join ของ Structured Query Language (SQL) จะรวมข้อมูลจากหลายตารางตามเงื่อนไขร่วมกันได้ ซึ่งเป็นต้นทุนเล็กน้อยที่คงที่ สำหรับสคีมาที่จะไม่สะสมข้อผิดพลาดเมื่อขนาดข้อมูลเพิ่มขึ้น

ข้อดีข้อเสียทั่วไปของ Data Normalization มีอะไรบ้าง

แม้ว่า Normalization จะมีประโยชน์อย่างมาก แต่ก็อาจทำให้เกิดต้นทุนจริงสำหรับทีมได้เช่นกัน

ข้อดีข้อเสียแบ่งเป็น 3 ด้านดังนี้

• ความซับซ้อนของคำขอ: ทุกความสัมพันธ์ที่คุณทำ Normalization ในตารางของตัวเองจะเป็น Join ที่จะเขียนในภายหลัง รายงานที่อ่านได้จากตารางเดียวตอนนี้ต้องใช้ 3 Join และภาระความรู้ความเข้าใจก็เพิ่มขึ้นทั่วทั้งทีมของนักวิเคราะห์ที่ทำงานโดยตรงใน SQL

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

• ประสิทธิภาพในการอ่าน: ในตารางขนาดใหญ่มากๆ Join จะช้ากว่าการสแกน คลังข้อมูลสมัยใหม่ (เช่น BigQuery, Snowflake, Redshift) มีตัวปรับแต่งคำขอที่จัดการกับ Join ได้ค่อนข้างดี แต่โครงสร้างที่ไม่ได้ทำ Normalization มักจะชนะในด้านความเร็วคำขอดิบสำหรับเวิร์กโหลดวิเคราะห์เมื่อเทียบกับแถวหลายพันล้านแถว

ทีมวิเคราะห์และคลังข้อมูลใช้ Data Normalization ในเวิร์กโฟลว์อย่างไร

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

วิธีการมีดังนี้

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

• เลเยอร์หลักแบบ Normalization: เครื่องมือการแปลงข้อมูลจะสร้างตารางเอนทิตีแบบ Normalization จากเลเยอร์การจัดเตรียม หนึ่งรายการสำหรับลูกค้า หนึ่งรายการสำหรับการชำระเงินตามรอบบิล และหนึ่งรายการสำหรับธุรกรรม ข้อมูลเหล่านี้จะอยู่ที่ประมาณ 3NF และทำหน้าที่เป็นแหล่งข้อมูลอ้างอิงสำหรับโมเดลดาวน์สตรีม

• เลเยอร์การรายงาน: ที่ด้านบนสุดของเลเยอร์หลักแบบ Normalization ทีมจะสร้างตารางแบบแบนที่กว้างและไม่ได้ทำ Normalization ซึ่งออกแบบมาเพื่อให้ใช้งานได้รวดเร็วและง่ายดายในเครื่องมือระบบธุรกิจอัจฉริยะ (BI) เช่น Tableau หรือ Looker โมเดลแดชบอร์ดรายรับอาจรวมตารางแบบ Normalization 5 ตารางเป็นตารางข้อเท็จจริงแบบกว้าง 1 ตารางที่เครื่องมือ BI อ่านได้โดยตรง

วิธีที่ Stripe รองรับข้อมูลที่สะอาดยิ่งขึ้นและเชื่อถือได้มากขึ้นสำหรับการทำ Data Normalization ในขั้นตอนถัดไป

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

สิ่งที่ผู้ให้บริการชำระเงินมีให้มีดังนี้

• การซิงค์ข้อมูล: Stripe Data Pipeline จะย้ายข้อมูล Stripe (เช่น การเรียกเก็บเงิน ลูกค้า การสมัครใช้งาน การคืนเงิน การโต้แย้ง การเบิกจ่าย) ไปยังคลังข้อมูลหรือปลายทางพื้นที่จัดเก็บข้อมูลบนคลาวด์โดยตรง โดยไม่ต้องมีตัวเชื่อมต่อของบุคคลที่สามคั่นกลางหรือมีขีดจำกัดอัตราของอินเทอร์เฟซการเขียนโปรแกรมแอปพลิเคชัน (API)

• ความสมบูรณ์ของข้อมูล: Stripe รับประกันความสมบูรณ์ของข้อมูลด้วยการซิงค์ข้อมูล Stripe ทั้งหมด รายงานทางการเงินที่สร้างไว้ล่วงหน้า และชุดข้อมูลที่คัดสรรมาแล้ว

• ความปลอดภัย: เมื่อทีมกำหนดเส้นทางข้อมูล Stripe ผ่านตัวเชื่อมต่อ extract, transform, and load (ETL) ของบุคคลที่สาม ทีมจะต้องส่งข้อมูลทางการเงินที่ละเอียดอ่อนไปยังโครงสร้างพื้นฐานของผู้ค้าเพิ่มเติม Data Pipeline จะดำเนินการขนส่งข้อมูลโดยตรง ซึ่งช่วยนำตัวกลางดังกล่าวออกและกำจัดผู้ค้าหนึ่งรายออกจากรายการตรวจสอบความปลอดภัยของข้อมูล

Data Pipeline ไม่ได้แทนที่แพลตฟอร์ม ETL แบบเต็มรูปแบบ หากกำลังรวมข้อมูล Stripe เข้ากับข้อมูลจากแหล่งที่มาอื่นๆ อีกนับสิบแห่ง ก็ยังต้องใช้เครื่องมือแปลงข้อมูล แต่โซลูชันนี้ออกแบบมาโดยเฉพาะสำหรับการซิงค์ข้อมูล Stripe ให้ดีกว่าตัวเชื่อมต่อของบุคคลที่สาม เพื่อให้แน่ใจว่าข้อมูลทางการเงินจะซิงค์ได้อย่างน่าเชื่อถือ ปลอดภัย และแม่นยำ