เมื่อใดที่เราควรใช้เอนทิตีอ่อนเมื่อสร้างโมเดลฐานข้อมูล

นี่เป็นคำถามพื้นฐานเกี่ยวกับองค์กรที่อ่อนแอ เมื่อใดที่เราควรใช้พวกเขา พวกเขาควรทำตัวอย่างไร

อะไรคือความแตกต่างที่สำคัญระหว่างเอนทิตี้ปกติและเอนทิตีที่อ่อนแอ เอนทิตีที่อ่อนแอนั้นสอดคล้องกับวัตถุที่มีค่าเมื่อทำการออกแบบโดเมนขับเคลื่อนหรือไม่

เพื่อช่วยให้คำถามในหัวข้อที่นี่เป็นตัวอย่างที่นำมาจากWikipediaที่ผู้คนสามารถใช้เพื่อตอบคำถามเหล่านี้:

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

นิติบุคคล "อ่อนแอ" อย่างเป็นทางการมีลักษณะดังต่อไปนี้

1.  It is existence-dependent on another entity, i.e., 
    it cannot exist without the entity with which it has a relationship.

2.  It inherits at least part of it's primary key from the entity to which 
    it is related. 


    i.e. -> A weak entity's primary key must be a composite key that includes 
       the primary key of the entity on which it is existence-dependent.

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

OrderItemไม่สามารถอยู่ได้โดยไม่ต้องมีการสั่งซื้อหรือสินค้า ดังนั้นมันจึงอ่อนแอเนื่องจากมันขึ้นอยู่กับการควบคุมมัน

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

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

แผนภาพ ER นั้นจะได้รับการออกแบบตามความต้องการทางธุรกิจ

ดูการสั่งซื้อมีหลายรายการการสั่งซื้อ (แอตทริบิวต์แบบหลายค่า) ดังนั้นตามกฎเราสร้างตารางแยกต่างหาก

ตอนนี้สมมติว่าลูกค้า 2 คนมีคำสั่งซื้อเหมือนกันทั้งซื้อ iPhone ในราคาเดียวกันส่วนลดวันเดียวกัน ฯลฯ ดังนั้นควรมีสองสิ่งอันดับที่แน่นอนสำหรับการสั่งซื้อของ iPhone ในการสั่งซื้อสินค้า แต่ตามข้อ จำกัด ของความสัมพันธ์ tuples ทั้งหมดควรจะไม่ซ้ำกัน ดังนั้นให้เชื่อมโยงคำสั่งซื้อสองรายการกับปัญหา item_line_number.no เดียวกันจนถึงตอนนี้ พิจารณาหนึ่งในลูกค้าที่ยกเลิก คือคำสั่งซื้อ iPhone นอกจากนี้ item_line_number tuple จะถูกลบ ตอนนี้ลูกค้ารายอื่นที่ซื้อ iPhone ก็จะถูกลบเนื่องจากการติดต่อ M: 1 ดังนั้นฐานข้อมูลจึงไม่สอดคล้องกัน นั่นเป็นเหตุผลที่เราใช้คีย์ตัวบอกคำสั่งซึ่งจะเป็นระเบียบเรียบร้อยดังนั้นการลบหนึ่ง iPhone ที่สั่งซื้อจะไม่ทำให้ฐานข้อมูลเสียหาย