สวัสดี! ฉันชื่อ Andrey Semenov เป็นนักวิเคราะห์อาวุโสของ Sportmaster ในโพสต์นี้ ฉันต้องการยกประเด็นเรื่องการดีนอร์มัลไลซ์ฐานข้อมูลระบบ ERP เราจะดูเงื่อนไขทั่วไปรวมถึงตัวอย่างเฉพาะ - สมมติว่ามันจะเป็นโรงเตี๊ยมผูกขาดที่ยอดเยี่ยมสำหรับโจรสลัดและกะลาสีเรือ ซึ่งโจรสลัดและกะลาสีเรือจะต้องรับใช้ต่างกันเพราะแนวคิดเรื่องความงามและรูปแบบการบริโภคของสุภาพบุรุษที่ดีเหล่านี้แตกต่างกันอย่างมาก
จะทำให้ทุกคนมีความสุขได้อย่างไร? คุณจะหลีกเลี่ยงการออกแบบและบำรุงรักษาระบบดังกล่าวอย่างบ้าคลั่งได้อย่างไร? จะทำอย่างไรถ้าไม่เพียงแต่โจรสลัดและกะลาสีเรือธรรมดาเท่านั้นที่เริ่มมาที่โรงเตี๊ยม?
ทุกอย่างอยู่ภายใต้การตัด แต่ไปตามลำดับกัน
1. ข้อจำกัดและสมมติฐาน
ทั้งหมดข้างต้นใช้กับฐานข้อมูลเชิงสัมพันธ์เท่านั้น ผลที่ตามมาจากการทำให้ปกติในรูปแบบของการดัดแปลง การลบ และการแทรกความผิดปกติ ซึ่งได้รับการครอบคลุมอย่างดี รวมถึงบนอินเทอร์เน็ต จะไม่ได้รับการพิจารณา นอกขอบเขตของเอกสารเผยแพร่นี้ มีหลายกรณีที่การทำให้ปกติเป็นเรื่องปกติ โดยมีตัวอย่างคลาสสิก: ชุดและหมายเลขหนังสือเดินทาง วันที่และเวลา ฯลฯ
โพสต์นี้ใช้คำจำกัดความที่ใช้งานง่ายและใช้งานได้จริงของรูปแบบปกติ โดยไม่มีการอ้างอิงถึงคำศัพท์ทางคณิตศาสตร์ ในรูปแบบที่สามารถนำไปประยุกต์ใช้กับการตรวจสอบกระบวนการทางธุรกิจจริง (BP) และการออกแบบซอฟต์แวร์อุตสาหกรรมได้
เป็นที่ถกเถียงกันอยู่ว่าการออกแบบคลังข้อมูล เครื่องมือการรายงาน และข้อตกลงบูรณาการ (ซึ่งใช้การแสดงข้อมูลแบบตาราง) แตกต่างจากการออกแบบฐานข้อมูลระบบ ERP ตรงที่ง่ายต่อการใช้งาน และการใช้การทำให้เป็นปกติอย่างมีสติเพื่อให้บรรลุผลอาจมีความสำคัญเหนือกว่าความสมบูรณ์ ข้อมูลการป้องกัน ฉันแบ่งปันความคิดเห็นนี้ และสิ่งที่อธิบายไว้ด้านล่างนี้ใช้กับข้อมูลหลักและโมเดลข้อมูลธุรกรรมของระบบ ERP เท่านั้น
คำอธิบายรูปแบบปกติจะได้รับโดยใช้ตัวอย่างที่สามารถเข้าใจได้ในชีวิตประจำวันสำหรับผู้อ่านส่วนใหญ่ อย่างไรก็ตาม ตามภาพประกอบในย่อหน้าที่ 4-5 มีการจงใจใช้งาน "เรื่องสมมุติ" อย่างจงใจ หากคุณไม่ทำเช่นนี้และยกตัวอย่างหนังสือเรียน เช่น โมเดลการจัดเก็บลำดับเดียวกันจากจุดที่ 2 คุณอาจพบว่าตัวเองอยู่ในสถานการณ์ที่การมุ่งเน้นของผู้อ่านจะถูกเปลี่ยนจากการสลายตัวของกระบวนการที่เสนอไปเป็นแบบจำลอง ประสบการณ์ส่วนตัวและการรับรู้ว่าจะต้องสร้างกระบวนการและแบบจำลองสำหรับการจัดเก็บข้อมูลใน IS อย่างไร กล่าวอีกนัยหนึ่ง ให้นำนักวิเคราะห์ไอทีที่มีคุณสมบัติเหมาะสมสองคน คนหนึ่งให้บริการแก่นักลอจิสติกส์ที่ขนส่งผู้โดยสาร และอีกคนให้นักลอจิสติกส์ที่ขนส่งเครื่องจักรสำหรับการผลิตไมโครชิป ขอให้พวกเขาสร้างแบบจำลองข้อมูลสำหรับจัดเก็บข้อมูลเกี่ยวกับการเดินทางด้วยรถไฟโดยไม่ต้องพูดถึง BP อัตโนมัติล่วงหน้า
มีความน่าจะเป็นที่ไม่เป็นศูนย์ที่ในรูปแบบที่นำเสนอคุณจะพบไม่เพียงแต่ชุดคุณลักษณะที่แตกต่างกันอย่างเห็นได้ชัด แต่ยังรวมถึงชุดของเอนทิตีที่แตกต่างกันด้วย เนื่องจากนักวิเคราะห์แต่ละคนจะต้องอาศัยกระบวนการและงานที่คุ้นเคยสำหรับเขา และในสถานการณ์เช่นนี้ก็เป็นไปไม่ได้ที่จะบอกว่าโมเดลใด "ถูกต้อง" เนื่องจากไม่มีเกณฑ์การประเมิน
2. แบบฟอร์มปกติ
รูปแบบปกติแรกของฐานข้อมูล ต้องการอะตอมมิกซิตีของคุณลักษณะทั้งหมด
โดยเฉพาะอย่างยิ่ง หากวัตถุ A มีคุณลักษณะที่ไม่ใช่คีย์ a และ b เช่น c=f(a,b) และในตารางที่อธิบายวัตถุ A คุณเก็บค่าของคุณลักษณะ c ดังนั้นรูปแบบปกติรูปแบบแรกจะถูกละเมิดในฐานข้อมูล . ตัวอย่างเช่น หากข้อกำหนดเฉพาะของคำสั่งซื้อระบุปริมาณ หน่วยการวัดจะขึ้นอยู่กับประเภทของผลิตภัณฑ์ ในกรณีหนึ่งสามารถเป็นชิ้น ๆ ในอีกลิตร ในบรรจุภัณฑ์ที่สามที่ประกอบด้วยชิ้น ๆ (ในโมเดลด้านบน Good_count_WR) จากนั้นอะตอมมิกซิตีของคุณลักษณะจะถูกละเมิดในฐานข้อมูล ในกรณีนี้ เพื่อบอกว่าคลัสเตอร์ตารางของข้อกำหนดเฉพาะของคำสั่งซื้อควรเป็นอย่างไร คุณต้องมีคำอธิบายที่เป็นเป้าหมายของกระบวนการทำงานใน IS และเนื่องจากกระบวนการอาจแตกต่างกัน จึงมีเวอร์ชันที่ "ถูกต้อง" ได้หลายเวอร์ชัน
รูปแบบปกติที่สองของฐานข้อมูล ต้องปฏิบัติตามแบบฟอร์มแรกและตารางของตัวเองสำหรับแต่ละเอนทิตีที่เกี่ยวข้องกับกระบวนการทำงานใน IS หากในตารางหนึ่งมีการขึ้นต่อกัน c=f1(a) และ d=f2(b) และไม่มีการขึ้นต่อกัน c=f3(b) ดังนั้นรูปแบบปกติที่สองจะถูกละเมิดในตาราง ในตัวอย่างข้างต้น ไม่มีการขึ้นต่อกันระหว่างคำสั่งซื้อและที่อยู่ในตารางคำสั่งซื้อ เปลี่ยนชื่อถนนหรือเมืองแล้วคุณจะไม่มีผลกระทบต่อคุณลักษณะที่สำคัญของคำสั่งซื้อ
ฐานข้อมูลรูปแบบปกติที่สาม ต้องปฏิบัติตามรูปแบบปกติที่สองและไม่มีการพึ่งพาการทำงานระหว่างคุณลักษณะของเอนทิตีที่แตกต่างกัน กฎนี้สามารถกำหนดได้ดังนี้: “ทุกสิ่งที่สามารถคำนวณได้จะต้องคำนวณ” กล่าวอีกนัยหนึ่ง หากมีวัตถุ A และ B สองชิ้น ในตารางที่จัดเก็บคุณลักษณะของวัตถุ A คุณลักษณะ C จะแสดงออกมา และวัตถุ B มีคุณลักษณะ b ในลักษณะที่ว่า c=f4(b) มีอยู่ ดังนั้นรูปแบบปกติที่สาม ถูกละเมิด ในตัวอย่างด้านล่าง แอตทริบิวต์จำนวนชิ้น (Total_count_WR) ในบันทึกคำสั่งซื้ออ้างว่าละเมิดรูปแบบปกติที่สามอย่างชัดเจน
3. แนวทางของฉันในการใช้การทำให้เป็นมาตรฐาน
1. เฉพาะกระบวนการทางธุรกิจแบบอัตโนมัติเป้าหมายเท่านั้นที่สามารถให้เกณฑ์แก่นักวิเคราะห์ในการระบุเอนทิตีและคุณลักษณะเมื่อสร้างแบบจำลองการจัดเก็บข้อมูล การสร้างแบบจำลองกระบวนการเป็นข้อกำหนดเบื้องต้นสำหรับการสร้างแบบจำลองข้อมูลปกติ
2. การบรรลุรูปแบบปกติที่สามในแง่ที่เข้มงวดอาจไม่สามารถทำได้ในทางปฏิบัติในการสร้างระบบ ERP หากตรงตามเงื่อนไขบางส่วนหรือทั้งหมดต่อไปนี้:
- กระบวนการอัตโนมัติมักไม่ค่อยมีการเปลี่ยนแปลง
- กำหนดเวลาสำหรับการวิจัยและพัฒนานั้นแน่น
- ข้อกำหนดด้านความสมบูรณ์ของข้อมูลค่อนข้างต่ำ (ข้อผิดพลาดที่อาจเกิดขึ้นในซอฟต์แวร์อุตสาหกรรมไม่ได้ทำให้ลูกค้าซอฟต์แวร์สูญเสียเงินหรือไคลเอ็นต์)
- เป็นต้น
ภายใต้เงื่อนไขที่อธิบายไว้ ค่าใช้จ่ายในการระบุและอธิบายวงจรชีวิตของวัตถุบางอย่างและคุณลักษณะอาจไม่สมเหตุสมผลจากมุมมองของประสิทธิภาพทางเศรษฐกิจ
3. ผลที่ตามมาของการทำให้แบบจำลองข้อมูลผิดปกติใน IS ที่สร้างไว้แล้วสามารถบรรเทาลงได้ด้วยการศึกษาโค้ดและการทดสอบเบื้องต้นอย่างละเอียด
4. Denormalization เป็นวิธีการถ่ายโอนต้นทุนค่าแรงจากขั้นตอนการวิจัยแหล่งข้อมูลและการออกแบบกระบวนการทางธุรกิจไปยังขั้นตอนการพัฒนา จากช่วงดำเนินการไปจนถึงช่วงของการพัฒนาระบบ
5. ขอแนะนำให้พยายามสร้างฐานข้อมูลรูปแบบปกติที่สามหาก:
- ทิศทางการเปลี่ยนแปลงในกระบวนการทางธุรกิจแบบอัตโนมัตินั้นยากต่อการคาดเดา
- มีการแบ่งแยกแรงงานที่อ่อนแอภายในทีมดำเนินการและ/หรือทีมพัฒนา
- ระบบที่รวมอยู่ในวงจรรวมจะพัฒนาตามแผนงานของตนเอง
- ความไม่สอดคล้องของข้อมูลอาจส่งผลให้บริษัทสูญเสียลูกค้าหรือเสียเงิน
6. การออกแบบแบบจำลองข้อมูลควรดำเนินการโดยนักวิเคราะห์เฉพาะที่เกี่ยวข้องกับแบบจำลองของกระบวนการทางธุรกิจเป้าหมายและกระบวนการใน IS เท่านั้น หากนักพัฒนากำลังออกแบบโมเดลข้อมูล เขาจะต้องดำดิ่งลงไปในสาขาวิชานั้น โดยเฉพาะอย่างยิ่งเขาเข้าใจความแตกต่างระหว่างค่าแอตทริบิวต์ ซึ่งเป็นเงื่อนไขที่จำเป็นสำหรับการแยกแอตทริบิวต์อะตอมมิก จึงทำหน้าที่ไม่ปกติ
4 ปัญหาสำหรับภาพประกอบ
สมมติว่าคุณมีโรงเตี๊ยมหุ่นยนต์เล็กๆ ในท่าเรือ ส่วนตลาดของคุณ: กะลาสีเรือและโจรสลัดที่เข้ามาในท่าเรือและต้องการหยุดพัก คุณขายชาใส่โหระพาให้กับกะลาสีเรือ และขายเหล้ารัมและหวีกระดูกสำหรับหวีเคราให้กับโจรสลัด การบริการในโรงเตี๊ยมนั้นให้บริการโดยหุ่นยนต์พนักงานต้อนรับและหุ่นยนต์บาร์เทนเดอร์ ด้วยคุณภาพและราคาที่ต่ำ คุณจึงสามารถขับไล่คู่แข่งของคุณออกไป เพื่อให้ทุกคนที่ลงจากเรือมาที่โรงเตี๊ยมของคุณ ซึ่งเป็นร้านเดียวในท่าเรือ
คอมเพล็กซ์ระบบข้อมูลโรงเตี๊ยมประกอบด้วยซอฟต์แวร์ต่อไปนี้:
- ระบบเตือนภัยล่วงหน้าเกี่ยวกับไคลเอนต์ที่จดจำหมวดหมู่ตามคุณลักษณะเฉพาะ
- ระบบควบคุมสำหรับหุ่นยนต์พนักงานต้อนรับและบาร์เทนเดอร์หุ่นยนต์
- ระบบการจัดการคลังสินค้าและการจัดส่งไปยังจุดขาย
- ระบบบริหารจัดการความสัมพันธ์คู่ค้า (SURP)
กระบวนการ:
ระบบเตือนภัยล่วงหน้าจดจำผู้คนที่ออกจากเรือ หากบุคคลใดมีหนวดเครา แสดงว่าเขาเป็นกะลาสีเรือ หากพบว่าบุคคลนั้นมีหนวดเครา แสดงว่าบุคคลนั้นเป็นโจรสลัด
เมื่อเข้าไปในโรงเตี๊ยม แขกจะได้ยินคำทักทายจากหุ่นยนต์พนักงานต้อนรับตามหมวดหมู่ของเขา เช่น “โฮ่โฮ่โฮ่ โจรสลัดที่รัก ไปที่โต๊ะหมายเลข...”
แขกไปที่โต๊ะที่ระบุ โดยหุ่นยนต์บาร์เทนเดอร์ได้เตรียมสินค้าให้เขาตามหมวดหมู่แล้ว หุ่นยนต์บาร์เทนเดอร์ส่งข้อมูลไปยังระบบคลังสินค้าว่าควรเพิ่มการจัดส่งส่วนถัดไป ส่วน IS ของคลังสินค้าจะสร้างคำขอซื้อในระบบการจัดการโดยอิงตามยอดคงเหลือในการจัดเก็บ
แม้ว่าระบบเตือนภัยล่วงหน้าอาจได้รับการพัฒนาโดยฝ่ายไอทีภายในของคุณ แต่โปรแกรมการจัดการหุ่นยนต์แท่งอาจถูกสร้างขึ้นโดยผู้รับเหมาภายนอกสำหรับธุรกิจของคุณโดยเฉพาะ และระบบการจัดการคลังสินค้าและความสัมพันธ์กับซัพพลายเออร์เป็นโซลูชันแบบแพ็คเกจที่ปรับแต่งเองจากตลาด
5. ตัวอย่างของการทำให้เป็นปกติและผลกระทบต่อการพัฒนาซอฟต์แวร์
เมื่อออกแบบกระบวนการทางธุรกิจ ผู้เชี่ยวชาญในหัวข้อที่ได้รับการสัมภาษณ์ระบุอย่างเป็นเอกฉันท์ว่าโจรสลัดทั่วโลกดื่มเหล้ารัมและหวีเคราด้วยหวีกระดูก ส่วนกะลาสีเรือดื่มชากับโหระพาและโกนให้เกลี้ยงเกลาอยู่เสมอ
ไดเร็กทอรีประเภทไคลเอนต์ปรากฏขึ้นพร้อมกับค่าสองค่า: 1 - โจรสลัด, 2 - กะลาสีเรือ ซึ่งเป็นเรื่องปกติสำหรับวงจรข้อมูลทั้งหมดของบริษัท
ระบบแจ้งเตือนลูกค้าจะจัดเก็บผลลัพธ์ของการประมวลผลภาพทันทีเพื่อเป็นตัวระบุ (ID) ของลูกค้าที่ได้รับการยอมรับและประเภท: กะลาสีเรือหรือโจรสลัด
ID วัตถุที่รู้จัก
หมวดหมู่ลูกค้า
100500
โจรสลัด
100501
โจรสลัด
100502
กะลาสี
ให้เราทราบอีกครั้งว่า
1. กะลาสีเรือของเราเป็นคนโกนขนจริงๆ
2. โจรสลัดของเราเป็นคนมีหนวดมีเคราจริงๆ
ปัญหาใดบ้างในกรณีนี้ที่ต้องกำจัดเพื่อให้โครงสร้างของเรามุ่งมั่นในรูปแบบปกติที่สาม:
- การละเมิด atomicity ของแอตทริบิวต์ - หมวดหมู่ไคลเอ็นต์
- ผสมผสานข้อเท็จจริงที่วิเคราะห์และข้อสรุปไว้ในตารางเดียว
- แก้ไขความสัมพันธ์ในการทำงานระหว่างคุณลักษณะของเอนทิตีต่างๆ
ในรูปแบบที่ทำให้เป็นมาตรฐาน เราจะได้ XNUMX ตาราง:
- ผลการรับรู้อยู่ในรูปแบบของชุดคุณสมบัติที่จัดตั้งขึ้น
ID วัตถุที่รู้จัก
ขนบนใบหน้า
100500
มี
100501
มี
100502
ไม่
- ผลลัพธ์ของการกำหนดประเภทของไคลเอนต์โดยใช้ตรรกะที่ฝังอยู่ใน IS เพื่อตีความลักษณะที่กำหนด
ID วัตถุที่รู้จัก
รหัสประจำตัว
หมวดหมู่ลูกค้า
100500
100001
โจรสลัด
100501
100002
โจรสลัด
100502
100003
กะลาสี
องค์กรจัดเก็บข้อมูลมาตรฐานสามารถอำนวยความสะดวกในการพัฒนา IP ที่ซับซ้อนได้อย่างไร สมมติว่าจู่ๆ คุณก็ได้รับลูกค้าใหม่ ปล่อยให้เป็นโจรสลัดญี่ปุ่นที่อาจไม่มีหนวดเครา แต่พวกเขาเดินโดยมีนกแก้วอยู่บนไหล่ และโจรสลัดนักอนุรักษ์สิ่งแวดล้อม คุณสามารถจดจำพวกเขาได้ง่ายๆ ด้วยโปรไฟล์สีน้ำเงินของ Greta ที่หน้าอกด้านซ้าย
โดยธรรมชาติแล้ว โจรสลัดด้านสิ่งแวดล้อมไม่สามารถใช้หวีกระดูกและเรียกร้องอะนาล็อกที่ทำจากพลาสติกในทะเลรีไซเคิลได้
คุณต้องทำอัลกอริธึมของโปรแกรมใหม่ตามอินพุตใหม่ หากปฏิบัติตามกฎการทำให้เป็นมาตรฐาน คุณจะต้องเสริมอินพุตสำหรับบางสาขากระบวนการในบางระบบ และสร้างสาขาใหม่สำหรับกรณีเหล่านั้นเท่านั้น และใน IS เหล่านั้นที่หนวดเครามีความสำคัญ แต่เนื่องจากไม่ปฏิบัติตามกฎ คุณจะต้องวิเคราะห์โค้ดทั้งหมด ตลอดทั้งวงจร โดยที่ค่าของไดเร็กทอรีประเภทไคลเอ็นต์ถูกใช้ และกำหนดไว้อย่างชัดเจนว่าในกรณีหนึ่งอัลกอริทึมควรคำนึงถึงมืออาชีพ กิจกรรมของลูกค้า และในลักษณะทางกายภาพอื่นๆ
ในรูปแบบที่ว่า แสวงหา เพื่อให้เป็นมาตรฐาน เราจะได้สองตารางที่มีข้อมูลการดำเนินงานและสองไดเร็กทอรี:
- ผลการรับรู้อยู่ในรูปแบบของชุดคุณสมบัติที่จัดตั้งขึ้น
ID วัตถุที่รู้จัก
เกรตาที่หน้าอกซ้าย
นกบนไหล่
ขนบนใบหน้า
100510
1
1
1
100511
0
0
1
100512
1
0
- ผลลัพธ์ของการกำหนดประเภทไคลเอนต์ (ปล่อยให้เป็นมุมมองที่กำหนดเองซึ่งแสดงคำอธิบายจากไดเร็กทอรี)
การดีนอร์มัลไลซ์ที่ตรวจพบหมายความว่าไม่สามารถแก้ไขระบบให้ตรงตามเงื่อนไขใหม่ได้หรือไม่ ไม่แน่นอน หากเราจินตนาการว่าระบบข้อมูลทั้งหมดถูกสร้างขึ้นโดยทีมเดียวโดยไม่มีการลาออกของพนักงาน การพัฒนาจะได้รับการบันทึกไว้อย่างดีและข้อมูลจะถูกถ่ายโอนภายในทีมโดยไม่สูญเสีย ดังนั้นการเปลี่ยนแปลงที่จำเป็นสามารถทำได้โดยใช้ความพยายามเพียงเล็กน้อย แต่ถ้าเรากลับสู่สภาพเดิมของปัญหา แป้นพิมพ์ 1,5 จะถูกลบเฉพาะสำหรับโปรโตคอลการพิมพ์ของการอภิปรายร่วมกัน และอีก 0,5 สำหรับการประมวลผลขั้นตอนการจัดซื้อจัดจ้าง
ในตัวอย่างข้างต้น มีการละเมิดรูปแบบปกติทั้งสามรูปแบบ ลองแยกกันดู
การละเมิดรูปแบบปกติครั้งแรก:
สมมติว่าสินค้าถูกส่งไปยังคลังสินค้าของคุณจากคลังสินค้าของซัพพลายเออร์โดยการรับสินค้าโดยใช้เนื้อทรายขนาด 1.5 ตันหนึ่งอันที่เป็นของโรงเตี๊ยมของคุณ ขนาดคำสั่งซื้อของคุณมีขนาดเล็กมากเมื่อเทียบกับการหมุนเวียนของซัพพลายเออร์ โดยที่จะดำเนินการแบบตัวต่อตัวเสมอโดยไม่ต้องรอการผลิต คุณต้องการตารางแยกต่างหากสำหรับกระบวนการทางธุรกิจ เช่น ยานพาหนะ ประเภทยานพาหนะ จำเป็นต้องแยกแผนและข้อเท็จจริงในคำสั่งซื้อของคุณไปยังซัพพลายเออร์ที่ลาออกหรือไม่?
ลองจินตนาการดูว่าโปรแกรมเมอร์ของคุณจะต้องเขียนการเชื่อมต่อ “พิเศษ” กี่ครั้ง หากคุณใช้แบบจำลองด้านล่างเพื่อพัฒนาโปรแกรม
สมมติว่าเราตัดสินใจว่าโครงสร้างที่เสนอนั้นซับซ้อนโดยไม่จำเป็น ในกรณีของเรา การแยกแผนและข้อเท็จจริงในบันทึกการสั่งซื้อนั้นเป็นข้อมูลที่ซ้ำซ้อน และข้อกำหนดการสั่งซื้อที่สร้างขึ้นจะถูกเขียนใหม่ตามผลลัพธ์ของการยอมรับสินค้าที่มาถึง ความผิดพลาดที่หายาก -การจัดระดับและการมาถึงของสินค้าที่มีคุณภาพไม่เพียงพอจะถูกตัดสินนอก IS
แล้ววันหนึ่งคุณจะเห็นว่าโรงเตี๊ยมทั้งหมดเต็มไปด้วยโจรสลัดที่ขุ่นเคืองและรุงรังอย่างไร เกิดอะไรขึ้น
ปรากฎว่าเมื่อธุรกิจของคุณเติบโตขึ้น การบริโภคของคุณก็เติบโตขึ้นด้วย กาลครั้งหนึ่ง มีการตัดสินใจของฝ่ายบริหารว่าหากเนื้อทรายมีปริมาณและ/หรือน้ำหนักมากเกินไป ซึ่งหาได้ยากมาก ซัพพลายเออร์จะจัดลำดับความสำคัญของน้ำหนักบรรทุกแทนเครื่องดื่ม
สินค้าที่ยังไม่ได้ส่งมอบจะจบลงในลำดับถัดไปและออกเดินทางในเที่ยวบินใหม่การมียอดคงเหลือขั้นต่ำในคลังสินค้าที่โรงเตี๊ยมทำให้ไม่สามารถสังเกตเห็นกรณีที่หายไปได้
ผู้แข่งขันคนสุดท้ายปิดที่ท่าเรือ และกรณีเนื้อทรายที่บรรทุกเกินพิกัดถูกเจาะทะลุโดยการจัดลำดับความสำคัญตามสมมติฐานของความเพียงพอของความสมดุลขั้นต่ำและการบรรทุกน้อยเกินไปของยานพาหนะเป็นระยะ ๆ กลายเป็นเรื่องธรรมดา ระบบที่สร้างขึ้นจะทำงานตามอัลกอริทึมที่ฝังอยู่ในนั้นและจะปราศจากโอกาสในการติดตามความล้มเหลวอย่างเป็นระบบในการปฏิบัติตามคำสั่งซื้อที่วางแผนไว้ เฉพาะชื่อเสียงที่เสียหายและลูกค้าที่ไม่พอใจเท่านั้นที่จะสามารถตรวจพบปัญหาได้
ผู้อ่านที่สนใจอาจสังเกตเห็นว่าปริมาณที่สั่งในข้อกำหนดเฉพาะของคำสั่งซื้อ (T_ORDER_SPEC) ในส่วนที่ 2 และส่วนที่ 5 อาจหรืออาจไม่ตรงตามข้อกำหนดของรูปแบบปกติแรกก็ได้ ทุกอย่างขึ้นอยู่กับว่าเมื่อพิจารณาจากประเภทสินค้าที่เลือก หน่วยการวัดที่แตกต่างกันสามารถจัดอยู่ในสาขาเดียวกันได้หรือไม่
การละเมิดรูปแบบปกติที่สอง:
เมื่อความต้องการของคุณเพิ่มมากขึ้น คุณจะซื้อยานพาหนะที่มีขนาดแตกต่างกันเพิ่มอีกสองสามคัน ในบริบทข้างต้น การสร้างไดเร็กทอรียานพาหนะถือว่าซ้ำซ้อน ด้วยเหตุนี้ อัลกอริธึมการประมวลผลข้อมูลทั้งหมดที่ตอบสนองความต้องการในการจัดส่งและคลังสินค้าจะรับรู้ถึงการเคลื่อนย้ายสินค้าจากซัพพลายเออร์ไปยังคลังสินค้าเป็นการบินที่มีน้ำหนักเพียง 1,5 ตัน ละมั่ง ดังนั้น ควบคู่ไปกับการซื้อยานพาหนะใหม่ คุณยังคงสร้างไดเร็กทอรียานพาหนะ แต่เมื่อสรุปแล้ว คุณจะต้องวิเคราะห์โค้ดทั้งหมดที่อ้างอิงถึงการเคลื่อนย้ายสินค้า เพื่อดูว่าการอ้างอิงในแต่ละสถานที่นั้นเกี่ยวข้องกับคุณลักษณะหรือไม่ ของยานพาหนะที่เริ่มธุรกิจนั้นเอง
การละเมิดรูปแบบปกติที่สาม:
เมื่อถึงจุดหนึ่งคุณเริ่มสร้างโปรแกรมสะสมคะแนน บันทึกของลูกค้าประจำจะปรากฏขึ้น เหตุใดจึงใช้เวลาสร้างมุมมองวัสดุที่จัดเก็บข้อมูลรวมเกี่ยวกับการขายให้กับลูกค้าแต่ละรายเพื่อใช้ในการรายงานและถ่ายโอนไปยังระบบการวิเคราะห์หากเมื่อเริ่มต้นโปรแกรมความภักดีทุกสิ่งที่ลูกค้าสนใจสามารถถูกวางไว้ในบันทึกของลูกค้า ? และแน่นอนว่าเมื่อมองแวบแรกก็ไม่มีประโยชน์ แต่ทุกครั้งที่ธุรกิจของคุณเชื่อมต่อ เช่น ช่องทางการขายใหม่ นักวิเคราะห์ของคุณควรมีคนที่จะจำได้ว่ามีคุณลักษณะการรวมกลุ่มดังกล่าวอยู่
เมื่อออกแบบกระบวนการใหม่แต่ละกระบวนการ เช่น การขายบนอินเทอร์เน็ต การขายผ่านผู้จัดจำหน่ายที่เชื่อมต่อกับระบบสมาชิกทั่วไป บุคคลต้องจำไว้ว่ากระบวนการใหม่ทั้งหมดจะต้องมั่นใจในความสมบูรณ์ของข้อมูลในระดับรหัส สำหรับฐานข้อมูลอุตสาหกรรมที่มีตารางนับพันตาราง ดูเหมือนว่าเป็นไปไม่ได้เลย
แน่นอนว่านักพัฒนาที่มีประสบการณ์รู้วิธีหยุดปัญหาทั้งหมดที่กล่าวมาข้างต้น แต่ในความคิดของฉัน งานของนักวิเคราะห์ที่มีประสบการณ์ไม่ใช่การทำให้ปัญหาเหล่านั้นกระจ่าง
ฉันอยากจะแสดงความขอบคุณต่อ Evgeniy Yarukhin ผู้พัฒนาชั้นนำสำหรับข้อเสนอแนะอันมีค่าของเขาในระหว่างการจัดทำสิ่งพิมพ์
วรรณกรรม
คอนนอลลี่ โธมัส, เบกก์ แคโรไลน์. ฐานข้อมูล การออกแบบ การใช้งาน และการสนับสนุน ทฤษฎีและการปฏิบัติ
ที่มา: will.com