ฉันมี 4 ตารางที่เกี่ยวข้องเช่นนี้ (เป็นตัวอย่าง):

Company:
ID
Name
CNPJ

Department:
ID
Name
Code
ID_Company 

Classification:
ID
Name
Code
ID_Company

Workers:
Id 
Name
Code
ID_Classification
ID_Department

สมมติว่าผมมีกับclassification id = 20, id_company = 1และdepartmentที่มีid_company = 2(ที่แสดงถึง บริษัท อื่น)

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

ปัญหาของคุณเกิดจากข้อเท็จจริงที่ว่ามีชนิดเอนทิตีหายไปจากแบบจำลองของคุณ พิจารณา ERD ต่อไปนี้:

โปรดทราบว่าฉันได้เพิ่มแยกประเภทนิติบุคคลระหว่างและDEPARTMENT CLASSIFICATIONเอนทิตีใหม่ประเภทนี้: POSITIONให้ข้อมูลซึ่งมีความหมายในแบบจำลองของคุณว่าแผนกใดแผนกหนึ่งมีชุดของการจำแนกประเภทที่หลากหลาย

การเพิ่มPOSITIONโมเดลของคุณเป็นเอนทิตีที่ชัดเจนมีข้อดีเล็กน้อย

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

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

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

ฉันไม่คิดว่าคุณมีปัญหากับความสัมพันธ์ ฉันคิดว่าปัญหาคือแทนที่ด้วยการใช้คีย์ตัวแทน (เช่นรหัส) สำหรับแต่ละตารางฐานข้อมูลที่เป็นผลลัพธ์ไม่สามารถป้องกันไม่ให้คนงานถูกแทรกแผนกของ บริษัท หนึ่ง บริษัท ในขณะที่การจำแนกประเภทเป็นอีกประเภทหนึ่งและในทางกลับกัน วิธีที่ดีในการทำความเข้าใจสิ่งนี้คือการมองเห็นสคีมาโดยใช้เครื่องมือสร้างไดอะแกรม ER ฉันจะใช้เครื่องมือOracle Data Modelerซึ่งเป็นการดาวน์โหลดฟรี

แผนผัง ER

มันยืน, คุณอาจมี 2 บริษัท - พูดและ IBM สามารถมีแผนกและ Microsoft สามารถมีแผนกได้ IBM สามารถมีการจัดประเภทและ Microsoft สามารถมีการจัดประเภท ตอนนี้เพราะคุณมีคีย์ตัวแทนและความจริงที่ว่าเป็นสรรพสินค้าและเป็นฝ่ายจะหายไปสำหรับความสัมพันธ์ของเด็กในอนาคต และนี่ก็เป็นกรณีที่มี ดังนั้นจึงเป็นเรื่องง่ายที่จะกำหนดโดยบังเอิญที่เป็นพนักงานในแผนกการจัดหมวดหมู่ของซึ่งเป็นMicrosoftIBMSoftware DevelopmentDesktop SoftwareSoftware EngineerSoftware DeveloperDepartmentClassificationSoftware DevelopmentIBMDesktop SoftwareMicrosoftClassificationHarlan MillsIBMSoftware DevelopmentSoftware DeveloperMicrosoftการจำแนกประเภท! ในทำนองเดียวกันคนงานอาจได้รับการจำแนกที่ถูกต้องและผิดแผนก! นี่คือแผนภาพแสดงตัวอย่างแรก:

หมายเลข 1 แทนIBMและ 2 Microsoftรหัสแทน ฉันได้เน้นสีแดงในสถานการณ์ที่Harlan MillsและBill Gatesกำหนดให้กับแผนกที่ไม่ถูกต้องซึ่งถูกมองเห็นได้จาก 10 แผนกรหัสที่เกี่ยวข้องกับรหัสการจำแนก 200 และในทางกลับกัน

ตัวเลือกเพื่อแก้ไข

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

ตัวเลือกที่สองคือไม่ใช้คีย์ตัวแทนสำหรับทุกตาราง ให้ใช้คีย์ตัวแทนแทนสำหรับCompanyตารางเท่านั้นซึ่งเป็นพื้นฐานและไม่มีพ่อแม่จากนั้นสร้างความสัมพันธ์ที่ระบุไปยังตารางDepartmentและClassificationตารางลูก DepartmentและClassificationตารางในขณะนี้มี PK ของการCompany Idบวกหมายเลขลำดับหรือชื่อจะแยกพวกเขา จากนั้นความสัมพันธ์จากDepartmentและClassificationไปWorkerยังเป็นidentifyingและทำให้ PK ของWorkerกลายเป็นCompany IdบวกDepartment Number(ฉันใช้หมายเลขลำดับในตัวอย่างนี้) Classification Numberบวก ผลลัพธ์คือมีเฉพาะone Company IdในWorkerตาราง ตอนนี้มันเป็นไปไม่ได้ที่จะกำหนดWorkerไปDepartmentในหนึ่งCompanyและไปอีกClassificationCompany

ทำไมเป็นไปไม่ได้ มันเป็นไปไม่ได้เพราะสคีมาดำเนินการอ้างอิงระหว่างWorkerและและDepartment Classificationหากมีการพยายามแทรก a WorkerสำหรับDepartmentหนึ่งCompanyและClassificationอีกหนึ่งชุดค่าผสมที่ไม่มีอยู่ในตารางหลักที่เกี่ยวข้องจะทำให้เกิดการละเมิดการอ้างอิงความสมบูรณ์และการแทรกจะไม่ทำงาน

นี่คือไดอะแกรมที่อัพเดตของการใช้งานตัวเลือกที่สอง:

ตัวเลือกที่ต้องการ

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

นี่เป็นคำถามที่ดีเพราะมันแสดงให้เห็นว่าทำไมการสมมติว่าทุกตารางต้องการคีย์ตัวแทนจึงเป็นความคิดที่ไม่ดี Fabian ปาสคาลมีโพสต์บล็อกที่ยอดเยี่ยมเพียงหัวข้อนี้แสดงให้เห็นว่าไม่เพียง แต่ที่สำคัญตัวแทนอาจจะเป็นความคิดที่ดีจากมุมมองความสมบูรณ์ของข้อมูลก็ยังสามารถส่งผลในการทำให้การสืบค้นบางช้าลงในระดับกายภาพอย่างแม่นยำเพราะการเข้าร่วมจำเป็นต้องมีการกดปุ่มอย่างถูกต้องจะไม่จำเป็น อีกหัวข้อที่น่าสนใจคำถามนี้แสดงให้เห็นว่าฐานข้อมูลไม่สามารถรับประกันได้ว่าข้อมูลทั้งหมดที่ใส่เข้าไปนั้นถูกต้องตามความเป็นจริง แต่สามารถมั่นใจได้ว่าข้อมูลที่ใส่เข้าไปนั้นสอดคล้องกับกฎที่ประกาศไว้เท่านั้น ในกรณีนี้เราสามารถทำสิ่งที่ดีที่สุดที่เป็นไปได้โดยใช้วิธีการที่สำคัญซ้อนเพื่อให้แน่ใจว่า DBMS สามารถเก็บข้อมูลที่สอดคล้องกันด้วยความเคารพในกฎที่ว่าWorkerของที่ได้รับCompanyความต้องการที่จะได้รับมอบหมายClassificationและการเดียวกันกับที่Department Companyแต่ถ้าในโลกแห่งความเป็นจริงMicrosoftมีแผนกที่เรียกว่าDesktop Softwareแต่ผู้ใช้ฐานข้อมูลยืนยันว่าเป็นแผนกแทนSoftware Development DBMS ไม่สามารถทำอะไรได้เลย แต่คิดว่ามันเป็นเรื่องจริง

วิธีที่ฉันเข้าใจคำถามคือฟิลด์ ID_Classification ของตาราง 'คนงาน' ควรอนุญาตเฉพาะการจำแนกประเภทที่กำหนดไว้สำหรับ บริษัท ของพนักงานที่เกี่ยวข้อง ดังนั้นการตรวจสอบ (โดยแนบ RULE หรือผ่าน TRIGGERS) ข้อมูลที่ถูกแทรก / ปรับปรุงเข้าไปในเขตข้อมูล Workers.ID_Classification เพียงพอที่จะตอบสนองความต้องการนี้

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

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

ทุกวันนี้มีมุมมองที่ฉลาดกว่าหรือเทคโนโลยีเช่นมุมมองที่เป็นรูปธรรมและเข้าร่วมดัชนีดังนั้นหากปัญหาของคุณคือประสิทธิภาพของแบบสอบถามให้ใช้มุมมองเหล่านั้น