สร้างโมเดลเชิงตรรกะ

🌐 มีให้อ่านอีก 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 ในบท การสร้างโมเดลข้อมูลเพื่อความหมาย บทที่ 2 ของหลักสูตร Data Architect แต่ละโมดูลอ่านแยกกันได้ ก่อนหน้า: วาดความสัมพันธ์ · ถัดไป: วางข้อมูลในที่ที่ควรอยู่

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

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

นั่ง คอย โมเดล

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

อะไรอธิบายมัน? สุนัขมีชื่อและวันเกิด เจ้าของมีชื่อ หมายเลขโทรศัพท์ และที่อยู่ ท่ามีชื่อและระดับความยาก ข้อเท็จจริงแต่ละข้ออยู่บนกล่องที่มันอธิบาย

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

ตัวไหนคือตัวไหน? ลองใช้ชื่อก่อน มีสุนัขชื่อ Max อยู่เยอะมาก ชื่อจึงซ้ำกันได้ หมายเลขโทรศัพท์ของเจ้าของล่ะ? Marcus มีสุนัขสองตัวที่ใช้เบอร์เดียวกัน คนเปลี่ยนเบอร์ได้ และมันเป็นข้อมูลส่วนบุคคลของใครบางคน ซึ่งจะถูกคัดลอกไปยังทุกระบบที่เคยชี้มาที่สุนัข หมายเลขไมโครชิปดูดีกว่า: มันไม่ซ้ำ และไม่เปลี่ยน แต่ลูกสุนัขตัวใหม่อาจยังไม่ได้ฝังชิป และคีย์จะว่างไม่ได้ ไมโครชิปจึงยังอยู่ ในฐานะสิ่งที่ใช้ระบุสุนัขได้อีกทางหนึ่ง (also known by) และสุนัขได้ ID สุนัข (Dog ID) ของตัวเอง: ตัวเลขที่ทำงานน่าเบื่ออยู่อย่างเดียว คือแยกสุนัขตัวหนึ่งออกจากอีกตัว

Click to enlarge

นั่นคือคำถามเดียวกับที่เราจะถามกับ Steve Trucking ต่อไป และเหตุผลที่ชื่อ เบอร์โทรศัพท์ และไมโครชิปต่างก็ไม่ดีพอ กลายเป็นกฎที่ผมยึดมาหลายปี

เชิงแนวคิดบอกว่ามีอะไรอยู่ เชิงตรรกะบอกว่ามันหมายถึงอะไรในฐานะข้อมูล

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

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

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

Click to enlarge

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

แอตทริบิวต์ควรอธิบายเอนทิตี

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

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

แล้วเราก็ต้องคุยเรื่อง ID ที่ไม่ซ้ำ

แอตทริบิวต์อธิบายสิ่งต่างๆ แต่มีอีกปัญหาที่ต้องแก้: ฉันจะรู้ได้อย่างไรว่าสิ่งไหนเป็นสิ่งไหน?

ผู้รับสองคนชื่อ John Smith พวกเขาเป็นคนเดียวกันไหม? อาจใช่ อาจไม่ใช่ ชื่อไม่พอ ที่อยู่? คนย้ายบ้าน หมายเลขโทรศัพท์เปลี่ยน อีเมลเปลี่ยน แม้แต่ชื่อของพันธมิตรค้าปลีกก็เปลี่ยนได้

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

ไม่ซ้ำ ไม่เปลี่ยน ไม่มีความหมาย ไม่ใช่ข้อมูลส่วนบุคคล

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

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

ไม่มีความหมาย ข้อนี้ฟังดูแปลกเมื่อได้ยินครั้งแรก ทำไมผมถึงอยากให้ตัวระบุไม่มีความหมาย? เพราะความหมายเปลี่ยน ลองนึกว่ามีคนสร้าง ID การจัดส่งที่เข้ารหัส DC พันธมิตรค้าปลีก วันที่จัดส่ง และหมายเลขลำดับไว้: PHX-KEY-20261002-0042 ดูฉลาดดี แล้วผู้รับก็เลื่อนนัดเป็นวันศุกร์ เราเปลี่ยนตัวระบุไหม? ถ้าไม่เปลี่ยน มันก็โกหกเรา ถ้าเปลี่ยน เราก็เปลี่ยน ID ที่ไม่ซ้ำของการจัดส่งเพราะแอตทริบิวต์หนึ่งของมันเปลี่ยน และทุกระบบที่เก็บ ID เก่าไว้ก็เพิ่งตามมันไม่เจอ ตัวระบุนั้นพยายามทำสองหน้าที่: ระบุการจัดส่งและอธิบายมัน ผมยอมให้แอตทริบิวต์อธิบายมัน และให้ตัวระบุทำหน้าที่น่าเบื่อเพียงอย่างเดียว: ระบุมัน ตัวระบุที่น่าเบื่อคือตัวระบุที่ดี

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

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

ดังนั้นกฎของผมคือ: ไม่ซ้ำ ไม่เปลี่ยน ไม่มีความหมาย ไม่ใช่ข้อมูลส่วนบุคคล

คีย์ธรรมชาติและคีย์ตัวแทน

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

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

สิ่งหนึ่งมีตัวระบุที่มีประโยชน์ได้หลายตัว

ID ภายในของเรกคอร์ดไม่จำเป็นต้องเป็นตัวระบุที่ทุกระบบอื่นใช้ Steve Trucking อาจระบุการจัดส่งภายในด้วย ID ที่สร้างขึ้น พันธมิตรค้าปลีกแต่ละรายรู้จักการจัดส่งเดียวกันด้วยหมายเลขคำสั่งซื้อของตัวเอง: Keystone ในใบรายการสินค้าแบบ CSV, Redrock ใน API, Brightwave ในข้อความ EDI และประวัติแปดปีใน RouteDesk เครื่องมือจัดการการเดินรถรุ่นเก่า ก็ใช้ ID การจัดส่งของ RouteDesk เอง

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

ความสัมพันธ์พึ่งพา ID ที่ไม่ซ้ำ

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

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

Click to enlarge

ถึงตรงนี้คุณอาจคิดว่า “Salesforce ให้ ID กับทุกเรกคอร์ดอยู่แล้ว” ถูกต้อง และเราจะไปถึง ถ้าข้อมูลอยู่ใน Salesforce ทุกเรกคอร์ดจะได้ ID ที่ Salesforce สร้างขึ้น มันอ่านยากและเข้าใจยาก เราจึงมักเปิดเผยฟิลด์ ID ที่คนใช้ได้ด้วย เช่น หมายเลขการจัดส่ง D-000184227 ซึ่งเป็นฟิลด์ Auto Number คนมักคิดว่าหมายเลขนั้นคือ ID ของเรกคอร์ด แต่ไม่ใช่: Salesforce ID ยังอยู่ข้างใต้ ระบบหรือฐานข้อมูลภายนอก เช่น Oracle หรือ SQL Server ก็มี ID ที่ไม่ซ้ำของตัวเองเช่นกัน แต่สถาปัตยกรรมอาจรวม Salesforce, ERP ด้านการเงิน, Snowflake, Data 360, ระบบของพันธมิตร และระบบที่ยังไม่มีอยู่ในที่สุด โมเดลเชิงตรรกะอธิบายข้อมูลธุรกิจโดยไม่ทำให้ทุกการตัดสินใจขึ้นกับเทคโนโลยีเดียว การที่ Salesforce จะ implement มันในเชิงกายภาพอย่างไรเป็นขั้นตอนภายหลัง

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

เมื่อผมเปลี่ยนโมเดลเชิงแนวคิดให้เป็นโมเดลเชิงตรรกะ ผมกำลังตัดสินใจว่า:

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

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

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

• Custom Field Types (opens in a new tab), Salesforce Help (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-09): Auto Number กำหนดหมายเลขที่ไม่ซ้ำให้แต่ละเรกคอร์ดตามรูปแบบการแสดงผล เช่น คำนำหน้าและเลขศูนย์นำหน้า มันไม่ใช่ Salesforce ID ของเรกคอร์ด ดูเพิ่มเติมที่ Auto-Number Fields Are Not Always Sequential (opens in a new tab) (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-09)