ในฐานข้อมูลการตรวจจับการเปลี่ยนแปลงข้อมูล (Change Data Capture หรือCDC ) คือชุดรูปแบบการออกแบบซอฟต์แวร์ที่ใช้ในการระบุและติดตามข้อมูลที่เปลี่ยนแปลงไป ("เดลต้า") เพื่อให้สามารถดำเนินการต่างๆ โดยใช้ข้อมูลที่เปลี่ยนแปลงไปได้ ผลลัพธ์ที่ได้คือ ชุด ข้อมูล ที่ขับเคลื่อนด้วยเดลต้า

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

CDC มักเกิดขึ้นใน สภาพแวดล้อม คลังข้อมูลเนื่องจาก1การบันทึกและรักษาสถานะของข้อมูลตลอดช่วงเวลาเป็นหนึ่งในหน้าที่หลักของคลังข้อมูล แต่ CDC สามารถนำไปใช้กับฐานข้อมูลหรือระบบจัดเก็บข้อมูลใดๆ ก็ได้

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

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

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

การประทับเวลาบนแถวมักถูกใช้สำหรับการล็อกแบบมองโลกในแง่ดี ดังนั้นคอลัมน์นี้จึงมักมีให้ใช้งาน

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

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

(อย่าสับสนเทคนิคนี้กับการกำหนดเวอร์ชันระดับแถวที่ใช้สำหรับการล็อกแบบมองโลกในแง่ดี สำหรับการล็อกแบบมองโลกในแง่ดี แต่ละแถวจะมีหมายเลขเวอร์ชันอิสระ ซึ่งโดยทั่วไปจะเป็นตัวนับแบบเรียงลำดับ วิธีนี้ช่วยให้กระบวนการสามารถอัปเดตแถวได้อย่างเป็นอะตอม และเพิ่มตัวนับได้ก็ต่อเมื่อกระบวนการอื่นยังไม่ได้เพิ่มตัวนับ แต่ CDC ไม่สามารถใช้เวอร์ชันระดับแถวเพื่อค้นหาการเปลี่ยนแปลงทั้งหมดได้ เว้นแต่จะทราบเวอร์ชัน "เริ่มต้น" ดั้งเดิมของทุกแถว ซึ่งไม่สามารถทำได้ในทางปฏิบัติเพื่อการบำรุงรักษา)

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

แนวทางนี้เป็นการผสมผสานวิธีการทั้งสามที่กล่าวถึงไปก่อนหน้านี้ ดังที่ได้กล่าวไว้แล้ว การใช้โซลูชัน CDC หลายตัวในระบบเดียวไม่ใช่เรื่องแปลก แต่การผสมผสานระหว่างเวลา เวอร์ชัน และสถานะ จะเป็นกลไกที่มีประสิทธิภาพอย่างยิ่ง และโปรแกรมเมอร์ควรใช้ทั้งสามอย่างนี้ร่วมกันทุกครั้งที่เป็นไปได้ องค์ประกอบทั้งสามนี้ไม่ได้ซ้ำซ้อนหรือฟุ่มเฟือย การใช้ร่วมกันทำให้สามารถใช้ตรรกะได้ เช่น "บันทึกข้อมูลทั้งหมดสำหรับเวอร์ชัน 2.1 ที่เปลี่ยนแปลงระหว่างวันที่ 1 มิถุนายน 2548 เวลา 00:00 น. และวันที่ 1 กรกฎาคม 2548 เวลา 00:00 น. โดยที่รหัสสถานะบ่งชี้ว่าพร้อมสำหรับการใช้งานจริง"

อาจรวมถึง รูปแบบ การเผยแพร่/สมัครรับข้อมูล (publish/subscribe)เพื่อสื่อสารข้อมูลที่เปลี่ยนแปลงไปยังเป้าหมายหลายแห่ง ในแนวทางนี้ ทริกเกอร์จะบันทึกเหตุการณ์ที่เกิดขึ้นกับตารางธุรกรรมลงในตารางคิวอื่น ซึ่งสามารถ "เล่นซ้ำ" ได้ในภายหลัง ตัวอย่างเช่น ลองนึกภาพตารางบัญชี เมื่อมีการทำธุรกรรมกับตารางนี้ ทริกเกอร์จะทำงานและบันทึกประวัติของเหตุการณ์หรือแม้แต่ส่วนที่เปลี่ยนแปลงลงในตารางคิวแยกต่างหาก ตารางคิวอาจมีโครงสร้างที่มีฟิลด์ต่อไปนี้: Id, TableName, RowId, Timestamp, Operation ข้อมูลที่แทรกสำหรับตัวอย่างบัญชีของเราอาจเป็น: 1, Accounts, 76, 2008-11-02 00:15, Update การออกแบบที่ซับซ้อนกว่าอาจบันทึกข้อมูลที่เปลี่ยนแปลงจริง ตารางคิวนี้สามารถ "เล่นซ้ำ" เพื่อจำลองข้อมูลจากระบบต้นทางไปยังเป้าหมายได้

การบันทึกข้อมูลมีความท้าทายตรงที่โครงสร้าง เนื้อหา และการใช้งานของบันทึกธุรกรรมนั้นมีความเฉพาะเจาะจงกับระบบจัดการฐานข้อมูลแต่ละระบบ ซึ่งแตกต่างจากการเข้าถึงข้อมูลตรงที่ไม่มีมาตรฐานสำหรับบันทึกธุรกรรม ระบบจัดการฐานข้อมูลส่วนใหญ่ไม่ได้จัดทำเอกสารเกี่ยวกับรูปแบบภายในของบันทึกธุรกรรม ถึงแม้ว่าบางระบบจะมีอินเทอร์เฟซสำหรับการเขียนโปรแกรมเพื่อเข้าถึงบันทึกธุรกรรม (เช่น Oracle, DB2, SQL/MP, SQL/MX และ SQL Server 2008) ก็ตาม

ความท้าทายอื่นๆ ในการใช้บันทึกธุรกรรมเพื่อบันทึกการเปลี่ยนแปลงข้อมูล ได้แก่:

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

โซลูชัน CDC ที่ใช้ไฟล์บันทึกธุรกรรมมีข้อดีที่โดดเด่นหลายประการ ได้แก่:

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

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

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

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

• การติดตามการเปลี่ยนแปลงโดยใช้ทริกเกอร์ฐานข้อมูล
• อ่านบันทึกธุรกรรมในขณะที่ถูกเขียน หรือหลังจากนั้นไม่นาน

หากข้อมูลไม่ได้อยู่ในฐานข้อมูลที่ทันสมัย ​​CDC จะกลายเป็นความท้าทายในการเขียนโปรแกรม

• Push : กระบวนการต้นทางจะสร้างภาพรวมของการเปลี่ยนแปลงภายในกระบวนการของตนเองและส่งข้อมูลไปยังกระบวนการปลายทาง กระบวนการปลายทางจะใช้ภาพรวมนั้น สร้างชุดข้อมูลย่อยของตนเอง และส่งข้อมูลไปยังกระบวนการถัดไป
• แบบดึง (Pull) : เป้าหมายที่อยู่ถัดจากแหล่งที่มาโดยตรง จะเตรียมคำขอข้อมูลจากแหล่งที่มา เป้าหมายปลายทางจะส่งภาพรวม (snapshot) ไปยังเป้าหมายถัดไป เช่นเดียวกับในรูปแบบผลักดัน (Push)

บางครั้งมิติที่เปลี่ยนแปลงช้าๆ จะถูกใช้เป็นวิธีการทางเลือก^{[ 1 ]} CDC และ SCD มีความคล้ายคลึงกันตรงที่ทั้งสองวิธีสามารถตรวจจับการเปลี่ยนแปลงในชุดข้อมูลได้ รูปแบบที่พบบ่อยที่สุดของ SCD คือ ประเภท 1 (เขียนทับ) ประเภท 2 (รักษาประวัติ) หรือ 3 (เฉพาะค่าก่อนหน้าและค่าปัจจุบัน) SCD 2 จะมีประโยชน์หากต้องการประวัติในระบบเป้าหมาย CDC จะเขียนทับในระบบเป้าหมาย (คล้ายกับ SCD1) และเหมาะอย่างยิ่งเมื่อต้องการส่งเฉพาะข้อมูลที่เปลี่ยนแปลงไปยังเป้าหมายเท่านั้น กล่าวคือชุด ข้อมูลที่ขับเคลื่อนด้วยเดลต้า

• ความสมบูรณ์ของการอ้างอิง
• มิติที่ค่อยๆ เปลี่ยนแปลง

• Oracle Data Integrator