คุณภาพและธรรมาภิบาลข้อมูล

มีให้อ่านอีก 28 ภาษา

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

An open sketchbook on a drafting table at dawn, a building sketched on one page and a data model on the other, with a pencil, an eraser, a cup and a lamp. — ภาพสร้างด้วย AI

คู่มือทบทวนสำหรับบทที่ 5 ของหลักสูตร Data Architect อ่านหกโมดูลก่อน หน้านี้ช่วยให้คุณตรวจสอบว่าอะไรติดอยู่ในหัวบ้าง

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

บทนี้ครอบคลุมส่วน Data Governance ของข้อสอบ (10%) และบางส่วนของ Data Modeling (เมทาดาทา) และ Salesforce Data Management (ความสอดคล้อง) มันยังเป็นจุดที่กฎหมายความเป็นส่วนตัวพบกับโมเดลข้อมูล นี่คือสถาปัตยกรรม ไม่ใช่คำแนะนำทางกฎหมาย: ฝ่ายกฎหมายตัดสินว่าอะไรใช้บังคับ และสถาปนิกทำให้มันบังคับใช้ได้ ตัวเลขของแพลตฟอร์มเปลี่ยนได้ จึงควรตรวจตัวเลขปัจจุบันก่อนพึ่งพามัน

สำหรับการสอบ

ทำเครื่องหมายไปทีละข้อ แต่ละข้อลิงก์ไปยังส่วนที่สอนเรื่องนั้น

GOV-2: การออกแบบโครงการธรรมาภิบาล

ฉันรู้ว่าเจ้าของเรกคอร์ด (กลไกของแพลตฟอร์มเพื่อการเข้าถึง) ไม่ใช่เจ้าของข้อมูล (ผู้รับผิดชอบข้อมูลในฐานะทรัพย์สินทางธุรกิจ) และแต่ละฟิลด์บันทึก Data Owner ได้ (เจ้าของเรกคอร์ดไม่ใช่เจ้าของข้อมูล)
ฉันแยกเจ้าของข้อมูล (กำหนดนโยบาย) ผู้ดูแลข้อมูล (ทำให้มันทำงานได้) และผู้ปฏิบัติการระบบ (ดูแลระบบ) ออกจากกันได้ (เจ้าของ ผู้ดูแลข้อมูล ผู้ปฏิบัติการระบบ)
ความรู้ที่ออกสอบ: ฉันรู้จักสามวิธีในการดำเนินโปรแกรมธรรมาภิบาล แบบรวมศูนย์ แบบกระจาย (federated หรือ decentralized) และแบบผสม และแต่ละแบบหมายถึงอะไรต่อคำถามว่าใครกำหนดนโยบาย และคำนิยามร่วมอยู่ที่ไหน (โปรแกรมดำเนินไปอย่างไร)
ฉันใช้ RACI ตอบได้ว่าข้อมูลถูกสร้าง แก้ไข และอ้างอิงที่ไหน (ทำให้ RACI คุ้มกับที่มันอยู่)
ฉันระบุจุดบังคับใช้ของนโยบายธรรมาภิบาลได้ (สิทธิ์ การตรวจสอบความถูกต้อง ฟิลด์ที่เขียนได้เฉพาะการผสานรวม ประวัติฟิลด์) ไม่ใช่แค่การอบรม (ธรรมาภิบาลต้องกลายเป็นกลไก)
ฉันรู้ว่าสัญญาณคุณภาพที่ควรวัดคือสัญญาณที่จะมีคนลงมือทำ (วัดสิ่งที่จะมีคนลงมือทำ)

SDM-2 และ MDM-4: กันข้อมูลไม่ดีออกไป

ฉันตัดสินได้ว่าการสร้างบัญชีควรเปิดหรือล็อก และรู้เส้นทางประเภทเรกคอร์ดชั่วคราวสำหรับบัญชีที่จัดการเป็นข้อมูลหลักใน ERP (เปิดหรือล็อก?, ทางสายกลาง)
ฉันปกป้องแอตทริบิวต์ที่มีธรรมาภิบาล (ID ของ ERP ชื่อตามกฎหมาย) ได้ โดยยังให้ฟิลด์ของ Salesforce เองแก้ไขได้: golden record แบบผสม และฉันรู้ว่าฟิลด์อ่านอย่างเดียวบนหน้า Dynamic Forms ไม่ใช่การบังคับใช้ ความปลอดภัยระดับฟิลด์หรือกฎการตรวจสอบความถูกต้องต่างหากที่ใช่ (ปกป้องเรกคอร์ดที่มีธรรมาภิบาล, ประเภทเรกคอร์ดสำหรับแต่ละโฟลว์)
ฉันรู้ว่าโฟลว์สองทางยากที่สุด: ถ้า ERP เป็นตัวหลักของฟิลด์ใด Salesforce กำลังขอเปลี่ยนมัน และการชนกันต้องมีกฎ (ERP ชนะ ปฏิเสธถ้าค่าเปลี่ยนไปแล้ว หรือให้คนเป็นผู้แก้) (ปกป้องเรกคอร์ดที่มีธรรมาภิบาล)
ฉันรู้ว่าฟิลด์ที่จำเป็นสร้างข้อมูลปลอมได้ (N/A, 999999) และรู้ทางเลือกอื่น (อย่าให้ฟิลด์ที่จำเป็นสร้างข้อมูลปลอม)
ฉันตัดสินได้ว่าจะเกิดอะไรขึ้นกับข้อมูลขาเข้าที่ไม่ผ่านการตรวจ: รับ ปฏิเสธ หรือกัก และใครเป็นเจ้าของข้อยกเว้น (ทุกขอบเขตข้อมูลต้องมีการตัดสินใจเรื่องคุณภาพ)
ฉันรู้ว่าข้อมูลอ้างอิงก็ต้องมีเมทาดาทา: คำนิยาม เจ้าของ แหล่งที่มา และการจับคู่ระหว่างระบบ (ข้อมูลอ้างอิงก็ต้องมีเมทาดาทา)

DM-3: เมทาดาทาทางธุรกิจและทางเทคนิค

ความรู้ที่ออกสอบ: ฉันแยกเมทาดาทาธุรกิจ (ความหมาย คำนิยาม เจ้าของ กฎ ความอ่อนไหว) ออกจากเมทาดาทาทางเทคนิค (ออบเจกต์ ฟิลด์ ชนิด ชื่อ API สคีมา การแมป สายที่มา) ได้ (เมทาดาทาสองประเภท)
ฉันรู้ความต่างระหว่างพจนานุกรมธุรกิจ (มันหมายถึงอะไร) สายที่มา (มันมาจากไหน) และการจัดประเภท (ต้องปฏิบัติต่อมันอย่างไร) (รู้จักข้อมูลของคุณ)
ฉันรู้ฟิลด์การจัดประเภทของ Salesforce: Data Owner, Field Usage, Data Sensitivity Level, Compliance Categorization บนฟิลด์มาตรฐานและที่กำหนดเอง (การจัดประเภทตอบคำถามที่ต่างออกไป)
ฉันรู้ว่าควรจัดประเภทฟิลด์ที่อ่อนไหว ไม่ใช่ทุกฟิลด์ และการจัดประเภทที่ไม่มีการบังคับใช้เป็นแค่ของตกแต่ง (การจัดประเภทที่ไม่มีการบังคับใช้เป็นแค่ของตกแต่ง)

GOV-1: ข้อมูลส่วนบุคคลและข้อมูลอ่อนไหว

นอกเหนือจากการสอบ

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

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

คำศัพท์ที่ควรรู้

คำศัพท์	ในหนึ่งบรรทัด
ธรรมาภิบาลข้อมูล	นโยบายสำหรับข้อมูล และสถาปัตยกรรมที่ทำให้มันเป็นจริง
เจ้าของข้อมูล	บุคคลหรือหน่วยงานที่รับผิดชอบข้อมูลประเภทหนึ่ง
ผู้ดูแลข้อมูล (data steward)	บุคคลที่รักษาสุขภาพของข้อมูลในแต่ละวัน
ผู้ปฏิบัติการระบบ (custodian)	ทีมที่ดำเนินการระบบที่เก็บข้อมูล
RACI	Responsible, Accountable, Consulted, Informed (ผู้ลงมือ ผู้รับผิดชอบ ผู้ให้คำปรึกษา ผู้รับทราบ)
เรกคอร์ดชั่วคราว	เรกคอร์ดที่ถูกสร้างก่อนที่ระบบที่มีอำนาจชี้ขาดจะยอมรับมัน
พจนานุกรมธุรกิจ	คำนิยามที่ตกลงกันของคำศัพท์สำคัญทางธุรกิจ
สายที่มาของข้อมูล (lineage)	ค่าหนึ่งมาจากไหน และเกิดอะไรขึ้นกับมันระหว่างทาง
การจัดประเภทข้อมูล	การติดป้ายข้อมูลตามความอ่อนไหวและหมวดการปฏิบัติตามกฎ เพื่อให้ได้การควบคุมที่เหมาะสม
อนุกรมวิธาน (taxonomy)	ชุดป้ายที่องค์กรใช้จัดประเภทข้อมูล
ข้อมูลส่วนบุคคล	ข้อมูลที่ระบุตัวบุคคล หรือเชื่อมโยงกลับไปหาบุคคลได้
การแฝงข้อมูล (pseudonymization)	การแทนที่ตัวระบุโดยยังมีทางกลับ ยังเป็นข้อมูลส่วนบุคคล
การทำให้เป็นข้อมูลนิรนาม (anonymization)	การลบความสามารถในการระบุตัวบุคคลอย่างสมเหตุสมผล
โมเดลข้อมูลความยินยอม	ออบเจกต์ของ Salesforce สำหรับความยินยอมตามบุคคล ช่องทาง จุดติดต่อ และจุดประสงค์
สิทธิที่จะถูกลืม	สิทธิของบุคคลที่จะให้ลบข้อมูลส่วนบุคคลของตน ในที่ที่กฎหมายให้สิทธินั้น
Golden record แบบผสม (hybrid golden record)	เรกคอร์ดเดียวที่มีทั้งฟิลด์ของระบบหลักและฟิลด์ของ Salesforce เอง แต่ละฟิลด์มีแหล่งเดียว
เมทาดาทาธุรกิจ / ทางเทคนิค	ข้อมูลหมายถึงอะไรและใครเป็นเจ้าของ / มันถูกสร้างและเคลื่อนย้ายอย่างไร
Field Audit Trail	ประวัติฟิลด์ที่ยาวขึ้น: สูงสุด 200 ฟิลด์ต่อออบเจกต์ เก็บจนกว่าจะลบ
Event Monitoring	ล็อกการล็อกอิน การส่งออก การเรียก API และการดู เก็บไว้ในระยะเวลาจำกัด
SIEM	ที่เก็บด้านความปลอดภัยที่เก็บและวิเคราะห์ล็อกเหตุการณ์

ทดสอบตัวเอง

สถานการณ์สั้นๆ ในแบบของหลักสูตร ตัดสินคำตอบของคุณก่อนเปิดดู

1. นโยบายบอกว่ามีแค่ฝ่ายการเงินที่เปลี่ยนชื่อตามกฎหมายของลูกค้าได้ ทีมวางแผนจะครอบคลุมเรื่องนี้ในการอบรม อะไรขาดไป?

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

2. ลูกค้าถูกจัดการเป็นข้อมูลหลักใน ERP พนักงานขายต้องเริ่มขายให้ลูกค้ามุ่งหวังรายใหม่ทันที คุณจะให้เขาทำได้อย่างไร โดยไม่ให้สองระบบสร้างเรกคอร์ดหลัก?

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

3. ฟิลด์ที่จำเป็นตัวใหม่เต็มไปด้วย "N/A" และ "999999" เกิดอะไรขึ้น และคุณจะทำอะไรแทน?

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

4. ทีมแทนชื่อด้วยโทเคนแล้วบอกว่าข้อมูลเป็นนิรนามแล้ว คำขอลบจึงเสร็จ จริงไหม?

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

5. ผู้รับยินยอมรับข้อความเรื่องการจัดส่งแต่ไม่รับการตลาด โมเดลควรเก็บสิ่งนั้นอย่างไร?

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

6. ฝ่ายการปฏิบัติตามกฎต้องกรองรายงานด้วยฟิลด์หมายเลขประกันสังคมที่เข้ารหัส ฟิลด์ใช้รูปแบบการเข้ารหัสค่าเริ่มต้น ปัญหาคืออะไร?

การเข้ารหัสแบบ probabilistic ไม่อนุญาตให้กรองในคำสั่ง SOQL WHERE หรือตัวกรองการจัดการข้อมูล การเข้ารหัสแบบ deterministic ให้กรองได้โดยแลกกับความแข็งแรงเล็กน้อย การเข้ารหัสคือการตัดสินใจออกแบบที่มีการแลกเปลี่ยนได้เสีย ไม่ใช่ช่องติ๊กตอนท้าย อ่านทวน การเข้ารหัสคือการควบคุม ไม่ใช่การปฏิบัติตามกฎ

7. หกเดือนหลังเกิดเหตุ มีคนถามว่าใครส่งออกเรกคอร์ดชุดหนึ่ง ไม่มีใครตั้งค่าการจัดเก็บ Event Monitoring ไว้ คุณบอกอะไรเขาได้?

น่าจะไม่ได้อะไรเลย: ล็อกเหตุการณ์ถูกเก็บไว้ในระยะเวลาจำกัด (สูงสุดหนึ่งปีแม้จะขยายแล้ว) อะไรที่เก่ากว่านั้นจึงหายไปเว้นแต่ถูกส่งออกไว้ ตั้งค่า Event Monitoring และส่งเหตุการณ์ไปยัง SIEM ก่อนที่คุณจะต้องใช้ อ่านทวน การตรวจสอบกับการเฝ้าระวังไม่ใช่สิ่งเดียวกัน

8. พนักงานขายขอให้ Salesforce เปลี่ยนชื่อตามกฎหมายของลูกค้า ซึ่ง ERP เป็นตัวหลัก ในไม่กี่นาทีเดียวกันนั้น ใครบางคนเปลี่ยนมันใน ERP การออกแบบควรบอกว่าอย่างไร?

ว่า Salesforce กำลังขอ ไม่ใช่กำลังเปลี่ยน: ERP เป็นตัวหลักของฟิลด์นั้น ตัดสินกฎการชนกันไว้ล่วงหน้า (ERP ชนะ ปฏิเสธถ้าค่าเปลี่ยนไปแล้ว หรือให้คนเป็นผู้แก้) และตัดสินว่าฟิลด์ที่เกี่ยวข้องจะเดินทางไปด้วยกันหรือไม่ อ่านทวน ปกป้องเรกคอร์ดที่มีธรรมาภิบาล

9. คำขอลบข้อมูลของบุคคลหนึ่งมาถึง ทีมวางแผนจะเริ่มทำแผนที่ว่าข้อมูลของเขาอยู่ที่ไหน ปัญหาคืออะไร?

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

ศึกษาเพิ่มเติม

Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), Salesforce Help (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-09-25): รายการวัตถุประสงค์อย่างเป็นทางการและน้ำหนักของแต่ละข้อ ตรวจสอบฉบับล่าสุดเสมอก่อนจองสอบ
ส่วนศึกษาเพิ่มเติมของแต่ละโมดูลแสดงรายการเอกสาร Salesforce และกฎหมายที่อยู่เบื้องหลังข้อเท็จจริงในโมดูลนั้น พร้อมวันที่ตรวจสอบ