데이터베이스를 모델링 할 때 약한 엔티티를 언제 사용해야합니까?

이것은 기본적으로 약한 엔티티가 무엇인지에 대한 질문입니까? 언제 사용해야합니까? 그것들은 어떻게 모델링되어야 하는가?

일반 엔티티와 약한 엔티티의 주요 차이점은 무엇입니까? 도메인 기반 디자인을 수행 할 때 약한 엔터티가 값 개체에 해당합니까?

이 주제에 대한 질문을 유지하는 데 도움을주기 위해 사람들이이 질문에 대답하기 위해 사용할 수있는 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.

나는 실제로 당신이 무언가를 "약한"실체로 만들기로 결심 하지 않을 것이라고 말했다. 대신 모델링하려는 모든 것을 대표하도록 데이터를 구성합니다. 이 작업을 수행 한 후 특정 엔티티를보고 "약한"엔티티의 특성을 가진 경우, 어떤 이유로 든 명시 적으로 호출해야 할 필요가 있다고 판단되면 그에 따라 문서화하거나 다이어그램을 작성할 수 있습니다. 형식의.

는 OrderItem주문 또는 제품없이 존재할 수 없습니다. 따라서 의존성이 제어하기 때문에 약합니다.

예를 들어 주문을 제거하는 경우 상품 배송 위치를 알 수 없습니다. 또는 제품을 제거하면 배송 할 제품을 모릅니다.

위의 다이어그램에서 내가 이해 한 바에 따르면 그들은 하나의 주문 및 주문 항목 대신 두 개의 엔티티 / 테이블을 포함하여 두 엔티티가 설계 될 때 정보에 쉽게 액세스 할 수 있습니다. 주문 항목은 주문 엔터티에 종속되므로 약한 엔터티로 간주됩니다. 약한 실체의 특성은 다른 실체에 의존하기 때문이다. 주문 항목 엔터티를 포함하지 않는 경우 주문 항목의 가격, 할인을 어떻게 알 수 있습니까? jgauffin이 말했듯이 예를 들어 주문을 제거하면 물품 배송 위치를 알 수있는 방법이 없습니다. 또는 제품을 제거하면 배송 할 제품을 모릅니다.

ER 다이어그램은 비즈니스 요구 사항에 따라 설계되어야합니다.

주문에 많은 주문 항목이 있습니다 (다중 값 속성). 따라서 규칙에 따라 별도의 테이블을 만듭니다.

이제 2 명의 고객이 동일한 주문을 가지고 있다고 가정 해보십시오. 예 : 둘 다 동일한 가격, 할인, 동일한 날짜 등으로 iPhone을 구입하십시오. 따라서 이상적으로는 관계에 관계없이 iPhone 주문에 대해 두 개의 정확한 튜플이 있어야합니다. 그러나 관계의 제약에 따라 모든 튜플은 고유해야합니다. 따라서 지금까지 두 개의 주문을 동일한 item_line_number.no 문제와 관련 시키십시오. 이제 고객 취소 중 하나를 고려하십시오. iPhone 주문입니다. item_line_number 튜플도 삭제됩니다. 이제 iPhone을 구입 한 다른 고객도 M : 1 통신으로 인해 삭제됩니다. 결국 데이터베이스가 일치하지 않습니다. 그래서 우리는 orderid가 될 기술자 키를 사용합니다. 따라서 주문한 iPhone 하나를 삭제해도 데이터베이스가 손상되지 않습니다.