พจนานุกรม สายที่มา และการจัดประเภท

🌐 มีให้อ่านอีก 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)

ภาพสร้างด้วย AI

แปลโดย AI ชุมชนยังไม่ได้ตรวจทาน อ่านเป็นภาษาอังกฤษ

โมดูลที่ 3 จาก 6 ในบท คุณภาพและธรรมาภิบาลข้อมูล บทที่ 5 ของหลักสูตร Data Architect แต่ละโมดูลอ่านแยกกันได้ ก่อนหน้า: กันข้อมูลไม่ดีออกไป · ถัดไป: กฎหมายความเป็นส่วนตัวกำหนดการออกแบบ

คำถามที่โมดูลนี้ตอบ: คุณบันทึกว่าข้อมูลหมายถึงอะไร มาจากไหน และอ่อนไหวแค่ไหนได้อย่างไร?

คุณรับช่วง org มา Account มี 900 ฟิลด์ ในนั้นมี Customer_Type__c, Customer_Class__c, Customer_Category__c, Customer_Status__c, ERP_Status__c และ Account_Status__c ฟิลด์ไหนบอกคุณว่าใครสักคนเป็นลูกค้าจริงๆ? คุณเปิดคำอธิบาย สามฟิลด์ว่างเปล่า หนึ่งฟิลด์เขียนว่า “Customer Type” ขอบคุณมาก หนึ่งฟิลด์บอกว่ามาจาก ERP อีกฟิลด์ถูกสร้างเมื่อหกปีก่อนโดยคนที่ลาออกไปนานแล้ว ทีนี้นึกภาพว่าคุณไม่ใช่สถาปนิก แต่เป็นการผสานรวม ทีมรายงาน หรือเอเจนต์ องค์กรมีข้อมูลเยอะ นั่นไม่ได้แปลว่ามันรู้ว่าข้อมูลหมายถึงอะไร

นั่นคือจุดที่เมทาดาทากลายเป็นสถาปัตยกรรม ผ่านคำถามสามข้อที่เกี่ยวข้องกันแต่ไม่เหมือนกัน:

• พจนานุกรม: ข้อมูลนี้หมายถึงอะไร?
• สายที่มา: มันมาจากไหน?
• การจัดประเภท: ต้องปฏิบัติต่อมันอย่างไร?

เมทาดาทาสองประเภท

เมทาดาทามีสองประเภท และคุณต้องการทั้งคู่ เมทาดาทาธุรกิจ (business metadata) คือสิ่งที่ข้อมูลหมายถึงสำหรับธุรกิจ: คำนิยาม เจ้าของ กฎการใช้งาน ระดับความอ่อนไหว เมทาดาทาทางเทคนิค (technical metadata) คือวิธีที่มันถูกสร้างและเคลื่อนย้าย: ออบเจกต์และฟิลด์ ชนิดและความยาว ชื่อ API สคีมา การแมปจากระบบหนึ่งไปอีกระบบ สายที่มาจากต้นทางถึงปลายทาง ชื่อ API และชนิดของฟิลด์บอกนักพัฒนาว่าจะใช้มันอย่างไร คำนิยามและเจ้าของบอกคนอื่นทุกคนว่าควรใช้หรือไม่ เมื่อสองอย่างนี้ขัดกัน หรือขาดไปอย่างหนึ่ง นั่นคือจุดที่การผสานรวมและรายงานผิดพลาด

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

เริ่มจากความหมาย

บทที่ 3 วางกฎไว้: ทุกฟิลด์ต้องมีคำอธิบาย ไม่ใช่ “Customer Status” สำหรับฟิลด์ชื่อ Customer Status แต่เป็นอะไรประมาณ “ความสัมพันธ์ทางการค้าปัจจุบันของพันธมิตรกับ Steve Trucking ตั้งค่าจาก ERP หลังเปิดใช้งาน อย่าใช้สำหรับคัดกรองลูกค้ามุ่งหวัง” ตอนนี้ผมรู้ว่ามันหมายถึงอะไร มาจากไหน และไม่ควรใช้ทำอะไร นั่นคือจุดเริ่มต้นของพจนานุกรมธุรกิจ: คำนิยามร่วมสำหรับข้อมูลที่สำคัญ ลูกค้าคืออะไร? ลูกค้าที่ใช้งานอยู่คืออะไร? Delivered หมายถึงอะไร? อะไรนับว่าตรงเวลา? สิ่งเหล่านี้ฟังดูชัดเจนจนกว่าคุณจะให้ห้าแผนกมาอยู่ในห้องเดียวกัน: ฝ่ายการเงินมีคำนิยามหนึ่ง ฝ่ายขายอีกแบบ ฝ่ายปฏิบัติการแบบที่สาม คลังข้อมูลแบบที่สี่ และมีคนสร้างแดชบอร์ดบนแบบที่ห้า ปัญหาไม่ใช่ว่าไม่มีใครพูดภาษาเดียวกัน แต่องค์กรยังไม่ได้ตกลงเรื่องความหมาย

พจนานุกรมอยู่ในสเปรดชีตหรือเครื่องมือเอกสารได้ แต่คำนิยามสำคัญต้องอยู่ใกล้กับที่ที่คนใช้ข้อมูล บนแพลตฟอร์ม นั่นคือคำอธิบายฟิลด์ ข้อความช่วยเหลือ และเมทาดาทาการจัดประเภท ในการวิเคราะห์มันยิ่งสำคัญ: “รายได้” จะหมายถึงอย่างหนึ่งบนแดชบอร์ดผู้บริหาร และอีกอย่างใน query ของนักวิเคราะห์ไม่ได้ นั่นคือสิ่งที่ semantic layer มีไว้ และ semantic model ของ Data 360 เก็บคำนิยามที่มีธรรมาภิบาล เช่น ตัวชี้วัด มิติ และความสัมพันธ์ ไว้เหนือข้อมูลเชิงกายภาพ (Create a Semantic Model in Data 360 (opens in a new tab) ภาษาอังกฤษ) เทคโนโลยีเปลี่ยน แต่ความต้องการไม่เปลี่ยน: ข้อมูลสำคัญต้องมีความหมายที่ตกลงกันแล้ว

และเริ่มจากความหมาย ไม่ใช่เทคโนโลยี พจนานุกรมที่เริ่มด้วยออบเจกต์ ฟิลด์ ประเภท และชื่อ API บันทึกการ implement พจนานุกรมที่เริ่มด้วยคำศัพท์ทางธุรกิจบันทึกองค์กร:

คำศัพท์ทางธุรกิจ	ความหมาย	แสดงอยู่ที่ไหน
พันธมิตรค้าปลีก	ผู้ค้าปลีกที่ Steve Trucking จัดส่งให้ภายใต้สัญญา	บัญชีใน Salesforce; ลูกค้าใน ERP ฝ่ายการเงิน
การจัดส่ง	การจัดส่งหนึ่งครั้งให้ผู้รับหนึ่งคน ที่ที่อยู่หนึ่งแห่ง ในวันหนึ่ง	RouteDesk ในวันนี้ และใบสั่งงานเมื่อการจัดส่งย้ายเข้ามาใน Salesforce
ผู้รับ	บุคคลที่รับการจัดส่ง	รายละเอียดผู้รับบนการจัดส่ง
Delivered	เสร็จสิ้นตามคำนิยามเชิงปฏิบัติการที่ตกลงกัน	สถานะการจัดส่ง
การจัดส่งตรงเวลา	เสร็จสิ้นภายในช่วงเวลาจัดส่งที่ตกลงกัน	ตัวชี้วัดที่คำนวณ

Click to enlarge

ความหมายเดียว หลายรูปแบบทางเทคนิค

แล้วถามว่ามันมาจากไหน

เมื่อผมรู้ว่าค่าหนึ่งหมายถึงอะไร ผมอยากรู้ว่ามันมาจากไหน นั่นคือสายที่มาของข้อมูล (lineage) ชื่อตามกฎหมายของพันธมิตรใน Salesforce: พนักงานขายพิมพ์เอง ERP ส่งมา การผสานรวมแปลงมัน Data 360 รวมมัน ถูกคำนวณ หรือ AI สร้างขึ้น? สิ่งเหล่านั้นมีผลต่อว่าผมเชื่อมันแค่ไหนและทำอะไรกับมันได้ จำเรกคอร์ดชั่วคราวของโมดูลที่ 2 ได้ไหม: สองบัญชีอาจเขียนว่า “Keystone” ทั้งคู่ บัญชีหนึ่งพนักงานขายสร้างเมื่อวาน อีกบัญชีมาจาก ERP พร้อมตัวระบุที่มีอำนาจชี้ขาด ข้อความเดียวกัน สายที่มาต่างกัน การปฏิบัติต่างกัน

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

สายที่มาบางส่วนได้มาฟรี: ID ของ ERP บนบัญชี Created By และ Last Modified By ล็อกของการผสานรวม เอกสารการจับคู่ Data 360 เพิ่มฟิลด์สายที่มาให้ data object ของมัน ซึ่งบันทึกแหล่งข้อมูลและออบเจกต์ต้นทางของแต่ละเรกคอร์ด (Data Lineage Fields (opens in a new tab) ภาษาอังกฤษ) แต่อย่าสมมติว่าสายที่มาจะปรากฏเพราะระบบผสานรวมกัน บางครั้งสายที่มาที่มีประโยชน์ที่สุดคือฟิลด์เดียว: Source System = Keystone และถ้าแหล่งที่มาสำคัญต่อธรรมาภิบาล ให้ทำให้มันเชื่อถือได้ในเชิงกลไก ตั้งค่าโดยการผสานรวม ไม่ใช่คนพิมพ์

ข้อมูลที่คำนวณได้ต้องการสายที่มามากที่สุด สมมติว่า Steve Trucking คำนวณความเสี่ยงการจัดส่งล่าช้าจากตำแหน่งรถ ช่วงเวลาจัดส่ง และประวัติเส้นทาง และฝ่ายจัดส่งใช้มันจัดลำดับความสำคัญ “สูง” มาจากไหน? เพิ่มเอเจนต์ที่บอกผู้รับว่า “การจัดส่งของคุณกำลังล่าช้า” แล้วคุณต้องรู้ว่าอะไรเป็นพื้นฐานของคำตอบนั้น และใหม่แค่ไหน ยิ่งคุณขยับจากค่าที่เก็บไว้ไปสู่ค่าที่คำนวณ รวม ทำนาย และสร้างขึ้น สายที่มาก็ยิ่งสำคัญ

การจัดประเภทตอบคำถามที่ต่างออกไป

ตอนนี้: ควรปฏิบัติต่อมันอย่างไร? ชื่อผู้รับ ที่อยู่จัดส่ง เบอร์โทรศัพท์ หมายเหตุการจัดส่ง สถานะการจัดส่ง หมายเลขรถบรรทุก ศูนย์กระจายสินค้า พันธมิตรค้าปลีก รูปถ่าย: อ่อนไหวไม่เท่ากัน “กำลังออกจัดส่ง” ไม่ใช่เบอร์โทรศัพท์ และรหัส DC ไม่ใช่รูปถ่ายภายในบ้านของใครสักคน Salesforce ให้คุณบันทึกสิ่งนี้บนแต่ละฟิลด์ ทั้งมาตรฐานและที่กำหนดเอง: Data Owner, Field Usage, Data Sensitivity Level และ Compliance Categorization (Data Classification Metadata Fields (opens in a new tab) ภาษาอังกฤษ) บทที่ 3 เรียกมันว่าฟิลด์อนุกรมวิธาน และอธิบายว่าทำไมมันสำคัญ: ติดแฟล็กฟิลด์ว่าเป็น PII หรือ GDPR แล้วกระบวนการต่างๆ ก็หามันเจอ ตั้งแต่เครื่องมือปิดบังข้อมูลไปจนถึง trust layer ด้าน AI ของ Salesforce ซึ่งกันไม่ให้ค่าที่ถูกติดแฟล็กไปถึงโมเดลภาษาขนาดใหญ่ได้ ข้อควรระวังหนึ่งข้อจากบทที่ 3: ตอนนี้ Salesforce ปิดการปิดบังข้อมูลสำหรับ LLM นั้นสำหรับเอเจนต์ เพราะมันอาจตัดบริบทที่เอเจนต์ต้องการออกไป (จัดประเภทสิ่งที่สำคัญ: ฟิลด์อนุกรมวิธาน) ดังนั้นการจัดประเภทยังคงต้องเป็นตัวขับเคลื่อนการควบคุมอื่นๆ

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

อนุกรมวิธานที่คนใช้ได้

การจัดประเภทต้องมีคำศัพท์ คืออนุกรมวิธาน (taxonomy) ค่าเริ่มต้นของ Salesforce คือ Public, Internal, Confidential, Restricted และ MissionCritical องค์กรของคุณอาจต้องการป้ายของตัวเอง ผมไม่ได้กำหนดให้ ทำให้มันเข้าใจได้: ถ้ามี 47 หมวด และไม่มีใครนอกทีมความเป็นส่วนตัวแยกหมวด 31 ออกจาก 32 ได้ มันก็ไม่ได้ช่วย อนุกรมวิธานที่ดีเชื่อมป้ายกับพฤติกรรม ถ้าฟิลด์หนึ่งเป็นข้อมูลส่วนบุคคลที่อ่อนไหว ใครเห็นได้ ไป sandbox ได้ไหม ออกนอกภูมิภาคได้ไหม ปรากฏในการวิเคราะห์ได้ไหม เก็บนานเท่าไร เอเจนต์ใช้ได้ไหม? ตอนนี้การจัดประเภทกำลังทำงาน

การจัดประเภทที่ไม่มีการบังคับใช้เป็นแค่ของตกแต่ง

ทำเครื่องหมายเบอร์โทรศัพท์ของผู้รับว่าอ่อนไหวแล้วไม่เปลี่ยนอะไรอื่น คุณก็แค่เขียนเอกสาร มีประโยชน์ แต่ธรรมาภิบาลไปไกลกว่านั้น: การจัดประเภทควรขับเคลื่อนสิทธิ์ การปิดบัง การเข้ารหัส การเก็บรักษา ความยินยอม การเคลื่อนย้ายข้อมูล การใช้ใน sandbox การตรวจสอบ และการเข้าถึงของ AI บางส่วนเป็นการตัดสินใจออกแบบของสถาปนิก บางแพลตฟอร์มตอนนี้ใช้แท็กและการจัดประเภทในนโยบายโดยตรง อย่างที่ธรรมาภิบาลของ Data 360 ทำ (Data Governance in Data 360 (opens in a new tab) ภาษาอังกฤษ) และการทำเครื่องหมายฟิลด์ว่า Restricted ไม่ได้หยุดใครจากการอ่านมัน การจัดประเภทบอกว่าฟิลด์ควรถูกปฏิบัติอย่างไร ความปลอดภัยทำให้เป็นแบบนั้น ลำดับคือ: ระบุข้อมูล เข้าใจมัน จัดประเภทสิ่งที่สำคัญ แล้วใช้การควบคุมที่การจัดประเภทนั้นเรียกร้อง

Click to enlarge

สามคำถามเกี่ยวกับข้อมูลของคุณ และคำถามที่สามต้องขับเคลื่อนอะไรบางอย่าง

ข้อมูลอ้างอิงก็ต้องมีเมทาดาทา

รหัสประเทศ สถานะการจัดส่ง รหัส DC ตัวระบุพันธมิตร เหตุผลการยกเลิก: ดูเรียบง่ายจนกว่าสองระบบจะไม่ตรงกัน ระบบหนึ่งบอก CANCELLED อีกระบบ CANCELED ระบบที่สาม CNCL ระบบที่สี่ 9 ข้อมูลอ้างอิงต้องมีคำนิยาม เจ้าของ แหล่งที่มา วงจรชีวิตเมื่อค่าเปลี่ยน และการจับคู่เมื่อระบบแสดงมันต่างกัน ค่าเล็กๆ ขับเคลื่อนกระบวนการที่ใหญ่มากได้ บทที่ 6 ไปไกลกว่านี้

ทั้งสามอย่างรวมกัน

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

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

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

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

สิ่งที่สถาปนิกต้องตัดสินใจในเรื่องนี้

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

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

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

• Salesforce Help, Data Classification Metadata Fields (opens in a new tab) (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-14)
• Salesforce Help, Data 360: Data Lineage Fields (opens in a new tab), Data Governance in Data 360 (opens in a new tab) และ Create a Semantic Model in Data 360 (opens in a new tab) (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-14)