ออกแบบถึงรูปแบบบรรทัดฐานที่สาม แล้วถอยออกมา

🌐 มีให้อ่านอีก 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 ชุมชนยังไม่ได้ตรวจทาน อ่านเป็นภาษาอังกฤษ

โมดูลที่ 5 จาก 6 ในบท การสร้างโมเดลข้อมูลเพื่อความหมาย บทที่ 2 ของหลักสูตร Data Architect แต่ละโมดูลอ่านแยกกันได้ ก่อนหน้า: วางข้อมูลในที่ที่ควรอยู่ · ถัดไป: เปลี่ยนโมเดลให้เป็น Salesforce

คำถามที่โมดูลนี้ตอบ: เมื่อไรควรตั้งใจถอยออกจากโมเดลที่ทำ normalization อย่างสะอาด?

ในโมดูลที่แล้ว ผมบอกให้คุณออกแบบถึงรูปแบบบรรทัดฐานที่สาม

ตอนนี้ผมจะบอกให้คุณแหกมัน

บางครั้ง

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

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

ออกแบบถึงรูปแบบบรรทัดฐานที่สามเท่าที่ทำได้ แล้วถอยออกมาเมื่อจำเป็น

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

เริ่มจากสร้างโมเดลของความจริง แล้วตัดสินใจว่าความจริงนั้นต้องถูกส่งมอบอย่างไร

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

กลับไปที่สุนัข และคราวนี้เราจะตัดสินใจบางอย่างอย่างตั้งใจ

สายพันธุ์: picklist หรือตารางของตัวเอง? ลองไล่ผ่านคำถามที่ผมจะให้คุณทีหลังในโมดูลนี้ มีข้อมูลมากกว่าหนึ่งคอลัมน์ไหม? มี: อย่างน้อยก็ขนาด มีกี่ค่า? สมาคมสุนัขต่างๆ รับรองสายพันธุ์ไว้หลายร้อยสายพันธุ์ (American Kennel Club อย่างเดียวก็มี 205) เกินกฎง่ายๆ ของผมที่ประมาณ 20 ไปไกล สายพันธุ์จึงสมควรได้ตารางของตัวเอง และสุนัขแต่ละตัวชี้ไปที่สายพันธุ์ของมัน นั่นตอบคำถามที่เราถือติดตัวมาตั้งแต่โมดูลที่ 1: สายพันธุ์เป็นกล่องของตัวเอง

ระดับทักษะ: picklist กำลังเรียน ดี เชี่ยวชาญ ป้ายสามอัน ไม่มีอะไรจะพูดเกี่ยวกับพวกมันอีก และพวกมันจะไม่เปลี่ยน นั่นคือสิ่งที่ picklist มีไว้พอดี

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

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

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

Click to enlarge

ทีนี้มาดูการตัดสินใจแบบเดียวกันที่ Steve Trucking ซึ่งมีเดิมพันสูงกว่า

โมเดลที่สะอาดที่สุดไม่ได้เป็นระบบที่ดีที่สุดเสมอไป

ลองนึกภาพทีมจัดส่งที่จุดแวะ การจัดส่งมีรายการของมัน การติดตั้งมีเช็กลิสต์ แต่ละขั้นต้องมีรูปถ่าย ผู้รับเซ็นรับ

โมเดลที่ทำ normalization นั้นสวยงาม: การจัดส่ง → รายการจัดส่ง → เช็กลิสต์การติดตั้ง → รูปถ่าย แต่ละอย่างอยู่ในที่ที่ควรอยู่

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

โมเดลข้อมูลไม่ใช่สิ่งเดียวที่เรากำลังออกแบบ

เรากำลังออกแบบระบบ

บางครั้งประสบการณ์ผู้ใช้ชนะ

นี่คือหนึ่งในเหตุผลที่บางครั้งผมถอยออกจากโมเดลที่ทำ normalization อย่างสมบูรณ์: ประสบการณ์ผู้ใช้

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

นี่คือจุดที่ผมเลิกถามแค่ว่า “ข้อเท็จจริงนี้ควรอยู่ที่ไหนในทางทฤษฎี?” และเริ่มถามว่า “ระบบนี้จะถูกใช้จริงอย่างไร?”

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

บางครั้งการทำรายงานชนะ

การทำรายงานเป็นอีกเหตุผลที่พบบ่อย

พันธมิตรค้าปลีกแต่ละรายต้องการ scorecard: การจัดส่งตรงเวลาแยกตามภูมิภาค ตามเดือน ในโมเดลที่สะอาด การจัดส่งรู้ศูนย์กระจายสินค้าของมัน และ DC รู้ภูมิภาคของมัน ในทางเทคนิค เราไล่ตามได้

แต่เครื่องมือทำรายงานทำได้ไหม? คนที่สร้างรายงานเองทำได้ไหม? พวกเขาตอบคำถามได้โดยไม่ต้องใช้สถาปัตยกรรมการรายงานที่ซับซ้อนกว่าตัวคำถามไหม?

นั่นคือตอนที่ผมอาจคัดลอกหรือคำนวณภูมิภาคมาไว้บนการจัดส่ง ใกล้กับที่ที่มันถูกใช้

ตอนนี้ผมสร้างการทำซ้ำขึ้นมาแล้ว ผมจึงต้องถามอีกข้อ: ใครเป็นเจ้าของความจริง?

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

denormalization ไม่ได้กำจัดความซับซ้อน

มันย้ายความซับซ้อน

lookup หรือ picklist?

นี่คือตัวอย่างเล็กกว่าที่ผู้ดูแลระบบ Salesforce เจออยู่ตลอด ผู้ใช้ต้องเลือกจากชุดค่า ผมจะสร้างเอนทิตีอีกตัวแล้วเชื่อมไปหามัน หรือใช้ picklist?

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

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

ถ้าผมสร้างออบเจกต์ให้ทุกแนวคิดที่ทำ normalization ได้ในทางทฤษฎี ผมอาจสร้างระบบที่สวยงามทางเทคนิคที่ไม่มีใครสนุกกับการใช้ ถ้าผมเปลี่ยนทุกแนวคิดเป็น picklist เพราะมันง่าย ผมอาจทาสีจนตัวเองติดมุมห้องได้เร็วมาก

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

นี่คือคำถามที่ผมถามจริงในเซสชันออกแบบ

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

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

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

คนต้องกรองและทำรายงานจากมันไหม? picklist เหมาะมากสำหรับเรื่องนั้น lookup ไม่สะอาดเท่า ทุก lookup เพิ่มอีกหนึ่งทอด: report type ตามได้แค่สายออบเจกต์ที่สัมพันธ์กันสั้นๆ (custom report type รองรับความสัมพันธ์ระหว่างออบเจกต์ได้สูงสุดสี่ทอด) หน้าจอกลายเป็น related list ซ้อนอยู่ใน related list และโค้ดก็ซับซ้อนขึ้น

รายการค่ามักเริ่มต้นชีวิตเป็น picklist และเมื่อเวลาผ่านไป ก็พิสูจน์ตัวเองจนสมควรได้เป็นออบเจกต์อิสระ ปล่อยให้มันพิสูจน์ตัวเอง

Click to enlarge

บางครั้งขนาดเปลี่ยนคำตอบ

การออกแบบที่ทำงานได้สวยงามกับเรกคอร์ดไม่กี่พัน อาจทำงานต่างไปมากกับเรกคอร์ดหลายล้าน

ดังนั้นอย่าดูแค่ไดอะแกรม ให้รู้ตัวเลข

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

โมเดลเดิม สถาปัตยกรรมที่ต่างไปมาก

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

ผู้ใช้ต่างกลุ่มต้องการรูปที่ต่างกัน

จนถึงตอนนี้ เราคิดถึงระบบปฏิบัติการ ผู้ประสานงานจัดเส้นทางการจัดส่ง ทีมปิดจุดแวะ ระบบเปลี่ยนไปตามการดำเนินธุรกิจ

แต่ธุรกิจยังอยากวิเคราะห์ประวัติหลายปีด้วย พันธมิตรและภูมิภาคไหนล่าช้า? เวลาจัดส่งเปลี่ยนไปอย่างไร? การติดตั้งต้องไปซ้ำบ่อยแค่ไหน?

ระบบเชิงวิเคราะห์อาจต้องการข้อมูลเดียวกันที่จัดเรียงต่างออกไป คุณจะได้ยินคำอย่าง data warehouse, fact, dimension และ star schema เราจะยังไม่อธิบายมันที่นี่ ที่ Steve Trucking นั่นคือคลังข้อมูล Snowflake และเราจะกลับมาเรื่องนี้ภายหลังในหลักสูตร

สำหรับตอนนี้: ผู้ใช้ต่างกลุ่มอาจต้องการรูปที่ต่างกันของความจริงเดียวกัน

AI เพิ่มผู้ใช้อีกกลุ่ม

และตอนนี้ก็มีผู้ใช้อีกกลุ่มหนึ่ง: AI

ผู้รับส่งข้อความมาว่า “ของฉันอยู่ไหน?” ผู้ช่วย AI อาจค้นเจอสิ่งนี้:

Delivery 10427, Route 3312, Stop 7, Truck 117, Window 13:00–15:00

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

เครื่องล้างจานจาก Redrock ของคุณเป็นจุดแวะที่เจ็ดในเส้นทางวันนี้จากศูนย์กระจายสินค้า Phoenix รถอยู่ห่างออกไปสามจุดแวะ และคุณยังอยู่ในช่วงเวลา 13:00–15:00 ของคุณ

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

นั่นไม่ได้แปลว่าผมทำลายโมเดลที่ทำ normalization ของผม และแน่นอนว่าไม่ได้แปลว่า “AI ชอบข้อมูลแบน งั้นใส่ทุกอย่างไว้ในออบเจกต์ยักษ์ตัวเดียว” อย่าทำแบบนั้น

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

แหล่งความจริงเดียวรองรับรูปแบบการใช้งานได้หลายรูป

เราจะลงลึกเรื่อง grounding และการดึงข้อมูลมากขึ้นภายหลังในหลักสูตร

อย่าสร้างความจริงหลายชุด

มีอันตรายอยู่ตรงนี้

ถ้าผมคัดลอกภูมิภาคไว้บนการจัดส่งเพื่อการรายงาน ส่งเวอร์ชันแบนไปที่ Snowflake และสร้างเวอร์ชันที่มีบริบทครบให้ผู้ช่วย AI อันไหนถูกต้อง?

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

ที่นั่นคือระบบต้นทางหลัก (system of record) สำเนาที่ทำ denormalization อาจดีได้: หน้าจอจุดแวะ scorecard, Snowflake และบริบทของ AI ต่างทำงานได้ดีขึ้นด้วยรูปที่สร้างมาเพื่อมัน และการอ้างถึงพวกมันก็ไม่มีปัญหา แต่เมื่อมีบางอย่างเปลี่ยน การเปลี่ยนแปลงต้องเริ่มที่ระบบต้นทางหลัก ซึ่งปกติคือโมเดลเชิงสัมพันธ์ แล้วไหลออกไปยังทุกสำเนา ไม่มีใครแก้ภูมิภาคใน Snowflake หรือแก้บริบทของ AI ด้วยมือ แก้ที่ต้นทาง แล้วปล่อยให้การเปลี่ยนแปลงไหลไป

Click to enlarge

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

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

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

เมื่อผมพิจารณา denormalization ผมกำลังตัดสินใจว่า:

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

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

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

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

• Build Powerful Reports with Custom Report Types (opens in a new tab), Salesforce Admins, 24 มิถุนายน 2019 (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-12): ประเภทรายงานที่กำหนดเอง “ครอบคลุมความสัมพันธ์ของออบเจกต์ได้สูงสุด 4 ชั้น”
• Unleash the hounds, terriers and lapdogs: American Kennel Club recognizes 3 more breeds (opens in a new tab), PBS NewsHour, 2 มกราคม 2026 (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-12): “AKC รับรอง 205 สายพันธุ์ รวมถึงสามสายพันธุ์ใหม่นี้”
• สำหรับความสนุก: FCI Breeds Nomenclature (opens in a new tab), Fédération Cynologique Internationale (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-12): รายชื่อสายพันธุ์ของสหพันธ์ระดับนานาชาติ แบ่งเป็นสิบกลุ่ม ลองเลื่อนดู แล้วคุณจะเห็นว่าทำไมสายพันธุ์จึงสมควรได้ตารางของตัวเอง