Khi nào chúng ta nên sử dụng các thực thể yếu khi mô hình hóa cơ sở dữ liệu?

Đây cơ bản là một câu hỏi về các thực thể yếu là gì? Khi nào chúng ta nên sử dụng chúng? Chúng nên được mô hình hóa như thế nào?

Sự khác biệt chính giữa các thực thể bình thường và các thực thể yếu là gì? Các thực thể yếu có tương ứng với các đối tượng giá trị khi thực hiện Thiết kế hướng miền không?

Để giúp giữ câu hỏi về chủ đề ở đây là một ví dụ được lấy từ Wikipedia mà mọi người có thể sử dụng để trả lời những câu hỏi sau:

Trong ví dụ này OrderItemđược mô hình hóa như một thực thể yếu, nhưng tôi không thể hiểu tại sao nó không thể được mô hình hóa như một thực thể bình thường.
Một câu hỏi khác là nếu tôi muốn theo dõi lịch sử đặt hàng (tức là những thay đổi trong trạng thái của nó) thì đó sẽ là một thực thể bình thường hay yếu?

Chính thức một thực thể "yếu" có các đặc điểm sau.

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.

Tôi sẽ nói rằng trong thực tế, bạn sẽ không quyết định công khai biến một cái gì đó thành một thực thể "yếu" mỗi se; thay vào đó, bạn sẽ cấu trúc dữ liệu để trở thành đại diện cho bất cứ điều gì bạn đang cố gắng mô hình hóa. Nếu, sau khi bạn thực hiện điều này, bạn nhìn vào một thực thể cụ thể và nó có các đặc điểm của một thực thể "yếu", bạn có thể ghi lại hoặc lập sơ đồ cho phù hợp nếu vì lý do nào đó bạn cảm thấy cần phải gọi nó ra hoặc vì lý do về hình thức.

An OrderItemkhông thể tồn tại mà không có đơn đặt hàng hoặc sản phẩm. Do đó, nó yếu vì phụ thuộc vào nó.

Nếu bạn loại bỏ đơn đặt hàng, bạn không có cách nào để biết nơi hàng sẽ được vận chuyển. Hoặc nếu bạn loại bỏ sản phẩm, bạn không biết phải giao hàng gì.

Theo sự hiểu biết của tôi trong sơ đồ trên, họ đã bao gồm hai thực thể / bảng thay vì một đơn hàng tức là đơn hàng và đơn hàng để việc truy cập thông tin trở nên dễ dàng khi hai thực thể được thiết kế. Và mục đơn hàng phụ thuộc vào thực thể đơn hàng nên nó được coi là một thực thể yếu. bởi vì đặc tính của thực thể yếu là nó phụ thuộc vào thực thể khác. Giả sử nếu bạn không bao gồm thực thể mục đơn hàng, làm thế nào bạn có thể biết giá, chiết khấu của đơn hàng. và như jgauffin đã nói Nếu bạn loại bỏ đơn hàng, bạn không có cách nào để biết nơi nào sẽ được vận chuyển. Hoặc nếu bạn loại bỏ sản phẩm, bạn không biết phải giao hàng gì.

Sơ đồ ER sẽ được thiết kế theo yêu cầu kinh doanh.

Xem, một đơn đặt hàng có nhiều mục đơn hàng (thuộc tính đa trị). Do đó theo quy tắc, chúng tôi tạo bảng riêng biệt.

Bây giờ, giả sử 2 khách hàng có cùng đơn hàng. Cả hai đều mua iPhone với cùng giá, giảm giá, cùng ngày, v.v. Vì vậy, lý tưởng nên có hai bộ dữ liệu chính xác cho thứ tự iPhone trong mối quan hệ thứ tự. Nhưng theo sự ràng buộc của một mối quan hệ, tất cả các bộ dữ liệu phải là duy nhất. Vì vậy, cho phép liên kết hai đơn đặt hàng với cùng một item_line_number.no ngay bây giờ. Bây giờ hãy xem xét một trong những khách hàng hủy bỏ. Là thứ tự iPhone. Ngoài ra, tuple item_line_number sẽ bị xóa. Bây giờ các khách hàng khác đã mua iPhone cũng bị xóa vì thư từ M: 1. Vì vậy, cuối cùng cơ sở dữ liệu không nhất quán. Đó là lý do tại sao chúng tôi sử dụng khóa mô tả sẽ có trật tự. Vì vậy, việc xóa một iPhone đã ra lệnh không gây ra lỗi cơ sở dữ liệu.