나는 스스로 공부하고있다. 교재 < < 데이터베이스 관리 시스템, 3 판 >>. 3.5.4 장에서 저자는 번역 관계에 포착 된 참여 제약에 대해 이야기한다. 그는 모든 부서 관리자가 있어야 참여 제약 조건의 예는, 아래 그림은 그 후 첫 번째 방법과 번역의 관계는 모든 부서 관리자가 있어야 제약 조건을 캡처 할 수 없다고번역에 참여 제한이 있음
보여줍니다 , SQL 코드는 우리가 및사회 보장 번호 (SSN) 에 NOT NULL 제약 조건을 추가 한 경우가있을 것입니다 어떤 영향을 생각
translation relationship with first approach
저자 추가 요청 리더 이하은 필드를 나타냅니다. 그는 힌트를 제공합니다. 제약 조건은 관리자의 해고를 막을 수는 있지만 관리자가 각 부서에 대해 처음으로 임명되는 것을 보장하지는 않습니다.
내 첫 번째 질문은 첫 번째 번역의 관계는 우리가
사회 보장 번호 (SSN) 내 두 번째 자신의 추가 요구 사고 후 NULL NOT 있어도, 참여 제약 조건을 캡처 할 수없는 이유입니다.
아마도이 두 가지가 관련되어있을 수 있습니다. 어떤 제안이있어 주셔서 감사합니다.
내 질문에 답변 해 주셔서 감사합니다. 그러나 Example 3.5.3에서 "did"는 참여 제약을 포착하는 "관리"의 기본 키 및 외래 키입니다. 그리고 예제 3.5.3에서 ssn 다음에 NOT NULL을두면 모든 부서가 관리자를 참조하는 것으로 나타 납니까? @NLink – nwdsl
그것은 모두 다른 엔티티에 관한 것입니다. 3.5.3의 "관리"표는 실체 "부서와 직원 간 연결"을 설명합니다. 따라서 테이블에 대한 모든 제한 사항은 "링크"자체에만 영향을 미칩니다. 1) 모든 링크는 기존 부서를 가리켜 야합니다. 2) 모든 링크는 기존 직원을 가리켜 야합니다. 3) 동일한 부서를 가리키는 링크가 두 개 없을 수 있습니다. "링크"에 제한을 추가하여 "모든 부서에 관리자가 있어야 함"상태를 확인할 수 없습니다. – NLink
그러나 3.5.3의 두 번째 예 (3.5.4와 동일)에서는 테이블 "Departments"를 대체하는 테이블 "Dept_Mgr"에 제약 조건을 추가합니다. 따라서 테이블 "Dept_Mgr"은 엔티티 "부서"를 설명합니다. 그리고 그 테이블에 대한 제한은 약간 다른 규칙을 만든다. 1) 똑같은 두 부서가 없을 수도있다. 2) 모든 부서가 어떤 직원을 가리켜 야한다. 3) 그 직원이 있어야한다. 다시 말해, 엔티티 테이블에 링크를 만들 때 엔티티 매개 변수를 확인할 수있게됩니다. @nwdsl – NLink