วาดความสัมพันธ์
มีให้อ่านอีก 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)
โมดูลที่ 2 จาก 6 ในบท การสร้างโมเดลข้อมูลเพื่อความหมาย บทที่ 2 ของหลักสูตร Data Architect แต่ละโมดูลอ่านแยกกันได้ ก่อนหน้า: ฟังหาคำนาม · ถัดไป: สร้างโมเดลเชิงตรรกะ
คำถามที่โมดูลนี้ตอบ: จะเปลี่ยนเอนทิตีที่เป็นไปได้ให้เป็นโมเดลข้อมูลเชิงแนวคิดได้อย่างไร?
เรามีคำนามอยู่บนกระดานแล้ว ตอนนี้ผมอยากรู้เกี่ยวกับเส้นระหว่างกล่อง เพราะกลุ่มของเอนทิตียังไม่ใช่โมเดลข้อมูลจริงๆ ความหมายส่วนใหญ่อยู่ในความสัมพันธ์ พันธมิตรค้าปลีกดำเนินงานศูนย์กระจายสินค้า ใบรายการสินค้าระบุการจัดส่ง การจัดส่งไปถึงผู้รับ ทีมจัดส่งประจำรถบรรทุก ทุกประโยคเหล่านั้นบอกบางอย่างเกี่ยวกับธุรกิจ และทุกประโยคให้คำถามใหม่แก่ผม
เริ่มจากภาษาของธุรกิจ
หัวข้อที่มีชื่อว่า “เริ่มจากภาษาของธุรกิจ ”ผมยังไม่อยากพูดถึง Salesforce ผมไม่ได้ถามว่านี่ควรเป็นความสัมพันธ์แบบ lookup หรือ master-detail ไม่ได้คิดถึง Junction Object ของ Salesforce (ออบเจกต์ที่กำหนดเองที่มีความสัมพันธ์ master-detail สองชุด) หรือตัดสินใจว่าจะเกิดอะไรขึ้นเมื่อเรกคอร์ดแม่ถูกลบ ผมพยายามเข้าใจความสัมพันธ์ทางธุรกิจ
ลองดู “พันธมิตรค้าปลีกดำเนินงานศูนย์กระจายสินค้า” ฟังดูง่าย แต่พันธมิตรค้าปลีกมี DC แห่งเดียวหรือหลายแห่ง? ที่ Steve Trucking พันธมิตรค้าปลีกแต่ละรายดำเนินงานศูนย์กระจายสินค้าระดับภูมิภาคในทุกภูมิภาคที่ Steve Trucking ให้บริการ จึงเป็นหลายแห่ง DC หนึ่งแห่งเป็นของพันธมิตรค้าปลีกมากกว่าหนึ่งรายได้ไหม? DC มีความสำคัญในตัวเอง มีพนักงานและประวัติของตัวเอง หรือเป็นแค่ที่อยู่? ถ้าพันธมิตรค้าปลีกเลิกใช้บริการ เรายังสนใจ DC ของเขาไหม?
นั่นไม่ใช่คำถามเกี่ยวกับ Salesforce มันคือคำถามทางธุรกิจ และคำตอบอาจเปลี่ยนโมเดลไปโดยสิ้นเชิง
อ่านเส้น
หัวข้อที่มีชื่อว่า “อ่านเส้น ”ก่อนจะลงลึกกว่านี้ ผมอยากให้ภาษาที่เราจะใช้กับทุกไดอะแกรมจากนี้ไป มันเป็นภาษาเล็กๆ เส้นระหว่างสองกล่องบอกว่าสองสิ่งนั้นสัมพันธ์กัน และเครื่องหมายที่ปลายเส้นบอกว่ามีกี่อัน
เริ่มด้วยเส้นธรรมดา ไม่มีเครื่องหมายเลย นั่นคือจุดที่ผมเริ่มบนไวต์บอร์ด: ผมรู้ว่าคำนามสองคำนี้สัมพันธ์กัน แค่ยังไม่ได้ถามว่าอย่างไร แล้วปลายเส้นก็ได้เครื่องหมาย ขีดเดียวพาดขวางเส้นหมายถึงหนึ่ง ส่วนตีนกา (crow’s foot) ปลายที่แตกเป็นสามแฉกเหมือนเท้านก หมายถึงหลาย ภายหลังในโมดูลนี้ คุณจะเห็นเครื่องหมายตัวที่สองปรากฏข้างตัวแรก เป็นขีดหรือวงกลม และตัวนั้นตอบคำถามอีกข้อ: มีเป็นศูนย์ได้ไหม?
กฎข้อเดียวที่ต้องจำ: คุณอ่านแต่ละเครื่องหมายที่กล่องที่มันแตะ เครื่องหมายที่ใกล้กล่องที่สุดคือจำนวนมากที่สุดที่มีได้ เครื่องหมายถัดออกไปคือจำนวนน้อยที่สุด
นั่ง คอย โมเดล
หัวข้อที่มีชื่อว่า “นั่ง คอย โมเดล ”ก่อนไปที่ Steve Trucking กลับไปที่สุนัขจากโมดูลที่ 1 เรามีห้ากล่อง: เจ้าของ ผู้เพาะพันธุ์ สุนัข สายพันธุ์ และท่า ตอนนี้ผมถามเรื่องเส้นระหว่างพวกมัน
หนึ่งหรือหลาย? เจ้าของหนึ่งคนมีสุนัขได้มากกว่าหนึ่งตัว Ana มีสองตัว สุนัขหนึ่งตัวมีเจ้าของหนึ่งคน อย่างน้อยก็ในโมเดลของเรา นั่นคือหนึ่งต่อหลาย: ขีดที่ฝั่งเจ้าของ ตีนกาที่ฝั่งสุนัข ผู้เพาะพันธุ์ก็มีรูปแบบเดียวกัน: ผู้เพาะพันธุ์หนึ่งรายเพาะพันธุ์สุนัขหลายตัว
ไม่มีเลยได้ไหม? Max มาจากสถานพักพิงสัตว์ เขาจึงไม่มีผู้เพาะพันธุ์เลย ปลายฝั่งผู้เพาะพันธุ์จึงได้วงกลม: สุนัขหนึ่งตัวมีผู้เพาะพันธุ์ศูนย์หรือหนึ่งราย แต่สุนัขทุกตัวมีเจ้าของ ปลายฝั่งนั้นจึงได้ขีดที่สอง: หนึ่งพอดี
หลายต่อหลาย? สุนัขหนึ่งตัวทำได้หลายท่า และท่าหนึ่ง เช่น นั่ง ก็มีสุนัขหลายตัวทำได้ นั่นคือหลายต่อหลาย และนั่นคือจุดที่ผมไปมองหาแนวคิดที่ซ่อนอยู่ มีอะไรเกี่ยวกับการที่สุนัขตัวนี้ทำท่านี้ได้ไหม? เธอทำได้ดีแค่ไหน และเรียนมันเมื่อไร ความสัมพันธ์มีข้อเท็จจริงของตัวเอง มันจึงกลายเป็นสิ่งหนึ่งของตัวเอง: ท่าของสุนัข (Dog Trick) ในชื่อภาษาอังกฤษ สุนัขมาก่อน เพราะสุนัขคือตัวขับเคลื่อน
แต่ละเส้นหมายถึงอะไร? เจ้าของเป็นเจ้าของสุนัข ผู้เพาะพันธุ์เพาะพันธุ์มัน สุนัขทำท่าของมันได้ ตั้งชื่อเส้น แล้วใครก็อ่านโมเดลกลับให้คุณฟังได้
ตอนนี้ หรือตลอดเวลา? มีใครสนใจไหมว่าวันนี้ Bella ทำท่านั่งได้ดีแค่ไหน หรือเธอไปถึงจุดนั้นได้อย่างไร? ถ้าครูฝึกตรวจเธอทุกสองสามเดือน การตรวจแต่ละครั้งก็คือเรกคอร์ดของตัวเอง: การประเมินท่า (Trick Assessment) พร้อมวันที่ ระดับทักษะ และผู้ตรวจ อยู่ใต้ท่าของสุนัขที่มันสังกัด แม้แต่ความสัมพันธ์ที่กลายเป็นสิ่งหนึ่งแล้วก็มีประวัติของตัวเองได้
สายพันธุ์ผมยังปล่อยไว้โดยไม่เชื่อมก่อน มันยังเป็นคำถามจากโมดูลที่ 1 ว่าเป็นกล่องของตัวเองหรือเป็นคำบนสุนัข และโมดูลที่ 4 จะตัดสินเรื่องนี้
คำถามทุกข้อเหล่านั้นใช้ได้แบบเดียวกันกับธุรกิจจริง ทีนี้มาถามคำถามเหล่านั้นกับ Steve Trucking กัน
ถามว่า “หนึ่งหรือหลาย?”
หัวข้อที่มีชื่อว่า “ถามว่า “หนึ่งหรือหลาย?” ”หนึ่งในสิ่งแรกที่ผมอยากเข้าใจเกี่ยวกับความสัมพันธ์คือ cardinality นั่นเป็นศัพท์ทางฐานข้อมูล คำถามนั้นง่ายกว่ามาก: สิ่งนี้กี่อันสัมพันธ์กับสิ่งนั้นได้กี่อัน? ในระดับแนวคิดมีรูปแบบพื้นฐานสามแบบ
นี่เป็นขั้นตอนสำคัญในกระบวนการ: หยิบคำนามสองคำที่ต่างกันแล้วเข้าใจความสัมพันธ์ของมัน ในสถานการณ์ส่วนใหญ่จะเป็นหนึ่งต่อหลาย หรือหลายต่อหนึ่ง เฉพาะในกรณีที่หาได้ยากเท่านั้นที่คุณจะเจอแบบหนึ่งต่อหนึ่ง
หนึ่งต่อหลายมีอยู่ทุกที่ พันธมิตรค้าปลีกหนึ่งรายมีศูนย์กระจายสินค้าหลายแห่ง ใบรายการสินค้าหนึ่งใบระบุการจัดส่งหลายรายการ เส้นทางหนึ่งเส้นมีจุดแวะราวสิบจุด เมื่อผมได้ยินภาษาแบบนั้น ผมก็เริ่มวาดเส้น
และตอนนี้เส้นก็ได้เครื่องหมาย แต่ละปลายบอกจำนวนของกล่องที่มันแตะ: ขีดสำหรับหนึ่ง ตีนกาสำหรับหลาย อ่านจากแต่ละกล่อง: พันธมิตรค้าปลีกหนึ่งรายมีศูนย์กระจายสินค้าหลายแห่ง
ความสัมพันธ์หนึ่งต่อหนึ่งมีอยู่จริง แต่หาได้ยาก และเมื่อผมเจอ ผมจะถามคำถามบางข้อ นี่เป็นคำนามสองคำที่ต่างกันจริงๆ หรือเป็นคำเดียวกัน? ถ้าต่างกัน ความสัมพันธ์แบบหนึ่งต่อหนึ่งระหว่างมันคืออะไร? และมันจะเป็นหนึ่งต่อหนึ่งตลอดไป หรือแค่หนึ่งต่อหนึ่งตอนนี้? นี่คือคำถามสำคัญในการออกแบบโมเดลข้อมูล ทีมจัดส่งกับรถบรรทุกดูเหมือนหนึ่งต่อหนึ่งในเช้าวันใดวันหนึ่ง: สองคน รถหนึ่งคัน เส้นทางหนึ่งเส้น แต่ตลอดหนึ่งเดือนมันไม่ใช่ และนั่นคือที่ซ่อนของความสัมพันธ์ที่น่าสนใจที่สุดในโมเดลนี้
ความสัมพันธ์หลายต่อหลายน่าสนใจเป็นพิเศษ เพราะมันมักบอกเราว่ามีแนวคิดอีกอย่างหนึ่งในธุรกิจ ทีมจัดส่งหนึ่งทีมขับรถบรรทุกมากกว่าหนึ่งคันในช่วงเวลาต่างๆ ได้ไหม? ได้ รถบรรทุกหนึ่งคันถูกขับโดยทีมมากกว่าหนึ่งทีมได้ไหม? ตลอดอายุการใช้งานของมัน ได้แน่นอน ดังนั้นทีมจัดส่งกับรถบรรทุกจึงมีความสัมพันธ์แบบหลายต่อหลาย แต่ตอนนี้ผมอยากรู้มากขึ้น ธุรกิจสนใจว่าทีมหนึ่งใช้รถคันหนึ่งเมื่อไรหรือไม่? สำหรับเส้นทางไหน ในวันไหน? ใครเป็นคนมอบหมาย? ถ้าตัวความสัมพันธ์เองมีข้อมูลที่เราสนใจ เราก็ค้นพบแนวคิดทางธุรกิจอีกอย่างหนึ่ง: การมอบหมายทีม (Crew Assignment)
นั่นเป็นนิสัยการสร้างโมเดลที่สำคัญ บางครั้งสิ่งที่น่าสนใจที่สุดไม่ใช่คำนามที่เราได้ยินตอนแรก แต่มันซ่อนอยู่ในความสัมพันธ์ระหว่างคำนามสองคำ
ความสัมพันธ์กลายเป็นสิ่งหนึ่งได้
หัวข้อที่มีชื่อว่า “ความสัมพันธ์กลายเป็นสิ่งหนึ่งได้ ”นี่คือหนึ่งในจุดที่ผมอยากให้ผู้ดูแลระบบเริ่มคิดต่างออกไป ใน Salesforce เราคุ้นกับการพูดถึงออบเจกต์และฟิลด์ จึงง่ายที่จะถือว่ากล่องเป็นส่วนสำคัญ และเส้นเป็นแค่ท่อเชื่อม แต่ตัวความสัมพันธ์เองก็มีความหมายทางธุรกิจได้
ลองดูการจัดส่งกับสินค้าในนั้น การจัดส่งหนึ่งรายการขนสินค้าได้หลายชิ้น เช่น เครื่องซักผ้ากับเครื่องอบผ้า สินค้าหนึ่งชิ้น เช่น ตู้เย็นรุ่นเดียวกัน ปรากฏในการจัดส่งหลายพันรายการ ง่ายพอ แต่ถ้าผมต้องรู้ว่าสินค้านั้นมีกี่ชิ้นในการจัดส่งนี้ ต้องติดตั้งไหม หรือต้องขนของเก่าทิ้งไหมล่ะ? ผมไม่ได้สนใจแค่ความสัมพันธ์ระหว่างการจัดส่งกับสินค้าอีกต่อไป ผมสนใจรายการจัดส่ง (Delivery Item) และแนวคิดนั้นสมควรมีเอนทิตีของตัวเอง
ถ้าคุณมาจากสาย Salesforce คุณอาจกำลังคิดว่า “นั่นคือ junction object” คุณไม่ผิด แต่ผมไม่อยากเริ่มตรงนั้น รายการจัดส่งเป็นแนวคิดทางธุรกิจก่อนที่จะเป็น Junction Object ของ Salesforce ธุรกิจมาก่อน การ implement มาทีหลัง
นี่คือนิสัยบางอย่างของผมสำหรับเอนทิตีความสัมพันธ์เหล่านี้ ไม่ว่าสุดท้ายจะถูกสร้างไว้ที่ไหน
ตั้งชื่อมัน ถ้าธุรกิจมีคำเรียกอยู่แล้ว ให้ใช้คำของพวกเขา ถ้าไม่มี ให้เอาชื่อของแม่ทั้งสองมารวมกัน ลองนึกถึงคำสั่งซื้อกับสินค้า สิ่งที่อยู่ตรงกลางคือ Order Item: คำสั่งซื้อ และรายการในคำสั่งซื้อ มันเป็นลูกของแม่ทั้งสอง และใน Salesforce อาจลงเอยเป็น Junction Object ของ Salesforce แต่ชื่อไหนควรมาก่อน: Item Order หรือ Order Item? ดูว่าแม่แต่ละตัวเป็นข้อมูลประเภทไหน สินค้าเป็นข้อมูลอ้างอิง คำสั่งซื้อเป็นธุรกรรม และคำสั่งซื้อคือตัวขับเคลื่อน จึงเป็น Order Item หรือ Order Product แบบเดียวกับที่ Salesforce มี Opportunity Product ที่ Steve Trucking มันคือ Delivery Item (รายการจัดส่ง) ชื่อที่เป็นตัวขับเคลื่อนมาก่อน และเรกคอร์ดจะเรียงอยู่ข้างเจ้าของของมันในทุกรายการที่คุณจะเปิดดู
ให้คีย์ของมันเอง มันชวนให้พูดว่ารายการจัดส่งถูกระบุด้วยการจัดส่งบวกสินค้าแล้วจบตรงนั้น นั่นคือคีย์ผสม (compound key) และคีย์ผสมจัดการยากกว่ามาก: ทุกระบบที่ชี้มายังเรกคอร์ดต้องถือทั้งสองครึ่ง ให้เอนทิตีความสัมพันธ์มีตัวระบุของตัวเอง และเก็บการจัดส่งบวกสินค้าไว้เป็นกฎเรื่องความไม่ซ้ำ ไม่ใช่เป็นตัวตน
สังเกตสิ่งที่ไม่มีอยู่บนมัน: หมายเลขซีเรียล จำนวนกับหมายเลขซีเรียลไม่ควรอยู่บนเรกคอร์ดเดียวกัน จำนวนนับสิ่งของหลายชิ้น หมายเลขซีเรียลระบุสิ่งของชิ้นหนึ่งโดยเฉพาะ ถ้าธุรกิจต้องการหมายเลขซีเรียล แต่ละชิ้นก็จะเป็นเรกคอร์ดของตัวเอง ตู้เย็นห้าเครื่องคือห้าเรกคอร์ด ผมนึกไม่ออกว่าจะมีกรณีไหนที่ต้องมีรายการจัดส่งพร้อม Delivery Item Detail อยู่ข้างใต้ มันต้องเป็นอย่างใดอย่างหนึ่ง: แบบรวมยอดที่มีจำนวน หรือหนึ่งเรกคอร์ดต่อหนึ่งชิ้น ในที่นี้ คือจำนวน
จับตาแอตทริบิวต์ที่ต้องการประวัติ เอนทิตีความสัมพันธ์บางตัวลงตัวทันทีที่ถูกสร้าง: เครื่องซักผ้าในการจัดส่งนี้ก็ยังเป็นเครื่องซักผ้าในการจัดส่งนี้ ตัวอื่นเปลี่ยนไปเรื่อยๆ ทีมหนึ่งได้รถคันที่ 117 สัปดาห์นี้ และสัปดาห์หน้ารถคันนั้นไปอยู่กับทีมอื่น เมื่อความสัมพันธ์เปลี่ยนและธุรกิจสนใจว่ามันเคยเป็นอย่างไร เอนทิตีความสัมพันธ์ก็ต้องมีวันที่ และการมอบหมายทีมคือตัวที่ต้องจับตา ถามตั้งแต่เนิ่นๆ ว่าธุรกิจสนใจตอนนี้ หรือตลอดช่วงเวลา เดี๋ยวเราจะกลับมาเรื่องนี้
ความสัมพันธ์มีความหมายมากกว่า cardinality
หัวข้อที่มีชื่อว่า “ความสัมพันธ์มีความหมายมากกว่า cardinality ”“หนึ่งต่อหลาย” ไม่พอที่จะเข้าใจความสัมพันธ์ ผมยังอยากรู้ว่าความสัมพันธ์นั้นหมายถึงอะไร
การจัดส่งมีสถานที่ สถานที่ไหน? ศูนย์กระจายสินค้าที่ออกเดินทาง? บ้านของผู้รับที่ไปถึง? สองอย่างนั้นใช้แทนกันไม่ได้ สองโมเดลอาจมีกล่องเหมือนกันทุกกล่องและ cardinality เหมือนกัน แต่เส้นอาจมีความหมายต่างกันโดยสิ้นเชิง นั่นคือเหตุผลที่โมเดลที่ดีไม่ใช่แค่กล่องที่เชื่อมด้วยเส้น เส้นต้องมีชื่อ ถ้าผมส่งไดอะแกรมให้สถาปนิกอีกคน เขาไม่ควรต้องเดาว่าความสัมพันธ์หมายถึงอะไร และถ้าผมแสดงให้ฝ่ายธุรกิจดู มันควรใช้ภาษาที่พวกเขาคุ้นเคย
ความเป็นทางเลือกก็สำคัญ
หัวข้อที่มีชื่อว่า “ความเป็นทางเลือกก็สำคัญ ”มีอีกคำถามหนึ่งซ่อนอยู่ใน “มีกี่อัน?”: ความสัมพันธ์นี้บังคับหรือไม่? การจัดส่งมีอยู่ได้ก่อนถูกจัดลงเส้นทางไหม? ต้องมีได้: ใบรายการสินค้ามาถึงหนึ่งหรือสองวันก่อนการจัดส่ง และเส้นทางถูกสรุปในเย็นวันก่อน การจัดส่งมีอยู่ได้โดยไม่มีพันธมิตรค้าปลีกไหม? ไม่ได้ ทุกการจัดส่งมาจากใบรายการสินค้าของพันธมิตร นั่นคือความเป็นทางเลือก (optionality)
อีกครั้ง อย่ากระโดดไปที่ช่อง Required ของ Salesforce ทันที การพูดว่า “ทุกการจัดส่งต้องมีพันธมิตรค้าปลีก” ต่างจากการพูดว่า “Salesforce ควรบังคับฟิลด์พันธมิตรค้าปลีกเมื่อสร้างเรกคอร์ด” อาจลงเอยเป็นการ implement แบบเดียวกัน แต่ไม่ใช่ข้อความเดียวกัน ข้อแรกเป็นกฎทางธุรกิจ ข้อที่สองเป็นวิธีหนึ่งในการบังคับใช้ ในฐานะสถาปนิก เราอยากเข้าใจข้อแรกก่อนตัดสินใจข้อที่สอง
บนไดอะแกรม ความเป็นทางเลือกคือเครื่องหมายตัวที่สองที่แต่ละปลาย เครื่องหมายที่ใกล้กล่องที่สุดคือจำนวนมากที่สุดที่มีได้: ขีดสำหรับหนึ่ง ตีนกาสำหรับหลาย เครื่องหมายถัดออกไปคือจำนวนน้อยที่สุด: ขีดอีกขีดหมายถึงอย่างน้อยหนึ่ง วงกลมหมายถึงเป็นศูนย์ได้ ดังนั้นทุกการจัดส่งอยู่ในใบรายการสินค้าเพียงหนึ่งใบพอดี และใบรายการสินค้าหนึ่งใบระบุการจัดส่งหนึ่งหรือหลายรายการ การจัดส่งหนึ่งรายการอยู่ที่จุดแวะศูนย์หรือหนึ่งจุด ไม่มีเลยจนกว่าจะถูกจัดเส้นทาง และจุดแวะหนึ่งจุดส่งของการจัดส่งศูนย์หรือหลายรายการ
เวลาเปลี่ยนความสัมพันธ์
หัวข้อที่มีชื่อว่า “เวลาเปลี่ยนความสัมพันธ์ ”นี่คือคำถามที่ผมถามบ่อย: คุณหมายถึงตอนนี้ หรือตลอดช่วงเวลา?
ทีมจัดส่งประจำรถบรรทุก ตอนนี้? สำหรับเส้นทางวันนี้? ตราบเท่าที่สองคนนั้นทำงานด้วยกัน? สิ่งเหล่านั้นให้โมเดลที่ต่างกัน ถ้าธุรกิจสนใจแค่ว่าวันนี้ทีมมีรถคันไหน โมเดลก็เรียบง่ายได้ ถ้าต้องรู้ทุกคันที่ทีมเคยขับ เมื่อไร และบนเส้นทางไหน เราก็ต้องมีประวัติ และการมอบหมายทีมที่เราค้นพบก็กลายเป็นเรื่องสำคัญมากขึ้นมาทันที
นี่เป็นต้นเหตุทั่วไปของความผิดพลาดในการสร้างโมเดล เราสร้างโมเดลของสถานะปัจจุบันเพราะนั่นคือสิ่งที่เราเห็นบนหน้าจอ แล้วหลายสัปดาห์ต่อมา พันธมิตรค้าปลีกยื่นเรื่องเคลมความเสียหาย และมีคนถามว่า “ทีมไหนใช้รถคันที่ 117 ในวันที่ 17 มีนาคม?” แล้วเราก็พบว่าเราเขียนทับคำตอบทุกครั้งที่การมอบหมายเปลี่ยน
วิธีหนึ่งในการเก็บประวัตินั้นคือทำให้การมอบหมายเป็นเรกคอร์ดของตัวเอง เมื่อทีมได้รับมอบหมาย เราสร้างการมอบหมายทีมพร้อมวันที่เริ่มต้น เมื่อการมอบหมายเปลี่ยน เราใส่วันที่สิ้นสุดในเรกคอร์ดเก่าและสร้างเรกคอร์ดใหม่พร้อมวันที่เริ่มต้นของมันเอง ตอนนี้ “ใครได้รับการมอบหมายนั้นเมื่อหกเดือนก่อน?” ก็เป็นคำถามที่ตอบได้ง่าย แทนที่จะต้องขุดผ่าน field history หรือล็อกการเปลี่ยนแปลงข้อมูล และเมื่อทีมหนึ่งมีการมอบหมายมากมาย ก็จะมีคนถามว่าอันไหนคืออันปัจจุบัน ผมจึงเพิ่มแฟล็ก Active ด้วย
ดังนั้นเมื่อมีคนเล่าให้ผมฟังเรื่องความสัมพันธ์ ผมไม่ได้ถามแค่ว่าสิ่งต่างๆ สัมพันธ์กันอย่างไร ผมถามว่า: ความสัมพันธ์นั้นเปลี่ยนไหม และเราสนใจประวัติของมันหรือไม่?
วาดก่อนตั้งค่า
หัวข้อที่มีชื่อว่า “วาดก่อนตั้งค่า ”โมเดล Steve Trucking ของเราเริ่มมีประโยชน์ เรารู้ว่าความสัมพันธ์ไหนเป็นหนึ่งต่อหลาย ตรงไหนที่ความสัมพันธ์หลายต่อหลายซ่อนแนวคิดอีกอย่างไว้ ความสัมพันธ์ไหนเป็นทางเลือก และอันไหนเปลี่ยนไปตามเวลา และเรายังไม่ได้สร้างออบเจกต์ Salesforce สักตัว นั่นเป็นความตั้งใจ
ไดอะแกรมนี้ควรเป็นสิ่งที่ผมวางตรงหน้าฝ่ายธุรกิจได้ และพวกเขาไม่ควรต้องรู้จัก Salesforce เพื่อบอกผมว่ามันถูกหรือไม่ ถ้าพวกเขายืนยันมันไม่ได้เพราะเต็มไปด้วยศัพท์ Salesforce ผมก็ขยับเข้าสู่การออกแบบเชิงกายภาพเร็วเกินไป
สิ่งที่สถาปนิกต้องตัดสินใจในเรื่องนี้
หัวข้อที่มีชื่อว่า “สิ่งที่สถาปนิกต้องตัดสินใจในเรื่องนี้ ”เมื่อผมไล่ดูความสัมพันธ์ในโมเดลเชิงแนวคิด ผมกำลังตัดสินใจว่า:
- เอนทิตีทางธุรกิจหลักสัมพันธ์กันอย่างไร
- แต่ละความสัมพันธ์เป็นหนึ่งต่อหนึ่ง หนึ่งต่อหลาย หรือหลายต่อหลาย ทั้งตอนนี้และตลอดช่วงเวลา
- แต่ละความสัมพันธ์บังคับหรือเป็นทางเลือก
- ความสัมพันธ์แบบหลายต่อหลายซ่อนแนวคิดทางธุรกิจที่มีความหมายไว้หรือไม่
- ความสัมพันธ์เปลี่ยนไปตามเวลาหรือไม่ และเราต้องการประวัติของมันหรือไม่
lookup หรือ master-detail การตั้งค่า junction พฤติกรรมการลบต่อเนื่อง และการแชร์ เป็นการตัดสินใจเชิงกายภาพ เราจะไปถึง ตอนนี้เรายังตอบคำถามที่สำคัญกว่าอยู่: ธุรกิจนี้ทำงานอย่างไรจริงๆ? เมื่อเราเข้าใจเอนทิตีและความสัมพันธ์ระหว่างกันแล้ว เราก็เริ่มเพิ่มรายละเอียดที่อธิบายพวกมันได้ นั่นคือตอนที่โมเดลเชิงแนวคิดเริ่มกลายเป็นโมเดลข้อมูลเชิงตรรกะ