이와 같은 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

classificationwith 가 있다고 가정합니다 id = 20, id_company = 1. 그리고 다른 회사를 대표 하는 department것이 있습니다 id_company = 2.

이것은 분류와 부서가 회사와 별도로 연결되어 있기 때문에 두 회사의 근로자를 만들 수 있습니다. 나는 그런 일이 일어나기를 원하지 않기 때문에 관계에 문제가 있다고 생각하고 그것을 해결하는 방법을 모른다.

모델에서 엔티티 유형이 누락되어 문제가 발생합니다. 다음 ERD를 고려하십시오.

와 사이에 교차 엔티티 유형을 추가했습니다 . 이 새로운 엔티티 유형 : 모델에 내재 된 정보를 제공합니다. 특정 부서에는 다양한 분류의 작업 세트가 있습니다.DEPARTMENTCLASSIFICATIONPOSITION

POSITION모델에 명시 적 엔터티로 추가 하면 몇 가지 장점이 있습니다.

1. WORKER다른 회사의 부서 및 분류에 할당 될 가능성이 있는 문제를 피할 수 있습니다 .
2. 급여 등급 등의 직책에 적용될 수있는 다른 술어에 대한 위치를 제공합니다.
3. 현재 위치에 위치가 없더라도 위치가 존재한다는 사실을 기록 할 수 있습니다 WORKER. 이는 아마도 유용한 정보 일 것입니다.

부서에 대한 직책과 다른 회사에 속하는 분류에 대한 문제를 피하기 위해 Todd Everett의 답변에서 길게 읽을 수있는 이유 DEPARTMENT와 두 가지 모두의 키를 확장했습니다 CLASSIFICATION.

주의 위의 모델은 단순화를 가정합니다. 특히 각 위치는 한 번만 기록된다고 가정합니다. 이것은 비즈니스 규칙에 적합하거나 적합하지 않을 수 있습니다. POSITION회사 내에서 동일한 부서 및 분류에 대해 여러 개의 레코드 가 필요한 경우 에 대리 키를 도입 할 수 있습니다 POSITION.

나는 당신이 관계에 문제가 있다고 생각하지 않습니다. 대신 문제는 각 테이블에 대리 키 (즉, ID)를 사용하여 결과 데이터베이스가 분류가 다른 회사의 부서 인 직원을 삽입하는 것을 막을 수 없으며 그 반대의 경우도 마찬가지입니다. 이를 이해하는 좋은 방법은 ER 다이어그램 도구를 사용하여 스키마를 시각화하는 것입니다. 무료로 다운로드 할 수있는 Oracle Data Modeler 도구를 사용하겠습니다 .

응급실 다이어그램

약자로, 당신은이 개 회사를 가질 수 - 말 IBM과 Microsoft. IBM수 있습니다 Software Development부서, 마이크로 소프트는 할 수 있습니다 Desktop Software부서. IBM은 Software Engineer분류를 가질 수 있으며 Microsoft는 Software Developer분류를 가질 수 있습니다 . 이제, 당신은 서로 게이트의 핵심이 있기 때문에 Department그리고 Classification, 사실 Software Development입니다 IBM부서와 Desktop SoftwareA는 Microsoft부서가 미래 자식 관계에 대한 손실됩니다. 의 경우도 마찬가지입니다 Classification. 따라서 부서 Harlan Mills의 IBM직원 인 실수를 쉽게 할당 할 수 있습니다.Software DevelopmentSoftware DeveloperMicrosoft분류! 마찬가지로 근로자에게 올바른 분류와 잘못된 부서가 주어질 수 있습니다! 다음은 첫 번째 예를 보여주는 다이어그램입니다.

1 IBM개의 ID는을 나타내고 2 개의 ID는을 나타냅니다 Microsoft. 나는 빨간색 시나리오에서 강조 표시 한 곳 Harlan Mills과 Bill Gates반대 (200) 분류 아이디 및 그와 연관된 10 부서 ID에 의해 가시화 잘못된 부서에 할당됩니다.

해결 옵션

그래서 그의 발생을 막을 수있는 옵션은 무엇입니까? 두 가지 즉각적인 옵션이 있습니다. 첫 번째는 모든 테이블에 대리 키를 사용하여이 문제가 존재 함을 확인하고 추가 프로그래밍을 도입하여 발생하지 않는지 확인하는 것입니다. 응용 프로그램에서이 작업을 수행 할 수 있지만 응용 프로그램 외부 에서 삽입 및 업데이트가 발생할 수 있으면 잘못된 연결이 계속 발생할 수 있습니다. 더 좋은 방법은 할당 된 부서가 할당 된 분류와 동일한 회사인지 확인하고 삽입 또는 업데이트에 실패하지 않으면 직원의 삽입 및 업데이트시 트리거되는 트리거를 만드는 것입니다.

두 번째 옵션은 모든 테이블에 서로 게이트 키를 사용하지 않는 것 입니다. 대신, Company기본적이고 부모가없는 테이블에 대해서만 서로 게이트 키를 사용한 다음 자식 테이블 과 식별 관계를 만듭니다 . 와 테이블은 현재의 PK가 그들을 구별하는 플러스 시퀀스 번호 또는 이름. 그런 다음 from 과 to 의 관계 또한 PK 가 + (이 예에서는 시퀀스 번호를 사용하고 있음)와 +가 됩니다. 결과는 단지 거기입니다 에 테이블. 그것은 지금 불가능 할당 A를DepartmentClassificationDepartmentClassificationCompany IdDepartmentClassificationWorkeridentifyingWorkerCompany IdDepartment NumberClassification Numberone Company IdWorkerWorkerA와 Department하나 Company와에 Classification또 다른의 Company.

왜 이것이 불가능합니까? 스키마 사이의 참조 무결성 구현 때문에 그것은 불가능 Worker하고 Department와 Classification. 시도가 삽입했을 경우 WorkerA에 대한을 Department하나 Company하고 그리고 Classification또 다른의는 해당 부모 테이블에 존재하지 않는 조합은 참조 무결성 위반을 트리거하고 삽입하지 않습니다 작동합니다.

다음은 두 번째 옵션의 구현에 대한 업데이트 된 다이어그램입니다.

선호하는 옵션

두 가지 옵션 중 두 가지 이유로 식별 관계와 계단식 키를 사용하는 두 번째 옵션을 선호합니다. 첫째,이 옵션은 추가 프로그래밍없이 원하는 규칙을 달성합니다. 방아쇠를 개발하는 것은 쉬운 일이 아닙니다. 코딩, 테스트 및 유지 관리해야합니다. 성능에 영향을 미치지 않도록 트리거 로직이 최적인지 확인하는 것도 쉽지 않습니다. 데이터베이스 전문가를위한 Applied Mathematics 책 은 그러한 솔루션의 복잡성에 대해 많은 세부 사항을 제공합니다. 둘째, 규칙은 부서 및 분류가 의 컨텍스트 외부에 존재할 수 없으므로Company 스키마가 실제 세계를보다 정확하게 반영 함을 의미합니다.

이것은 단순히 모든 테이블에 서로 게이트 키가 필요하다고 가정하는 것이 나쁜 생각 인 이유를 정확하게 보여주기 때문에 좋은 질문입니다. Fabian Pascal 은이 주제에 대한 훌륭한 블로그 게시물 을 보유하고 있으며, 데이터 무결성 관점에서 대리 키가 나쁜 아이디어 일뿐만 아니라 일부 검색이 느려질 수 있음을 보여줍니다.키가 올바르게 계단식으로 배열되어 있으면 필요하지 않은 결합이 필요하기 때문에 물리적 수준에서 정확하게. 이 질문에서 알 수있는 또 다른 흥미로운 주제는 데이터베이스가 데이터베이스에 삽입 된 모든 데이터가 실제 환경과 관련하여 정확한지 확인할 수 없다는 것입니다. 대신 데이터에 삽입 된 데이터가 선언 된 규칙과 일치하는지 확인할 수 있습니다. 이 경우 우리는 할 계단식 키 방식을 사용하여 최적의 작업을 수행 할 수 있도록 • 그래도 규칙에 대한 일관성있는 데이터를 보존 할 수있는 DBMS를 Worker특정의 Company요구에 할당 할 수 Classification와 Department같은의를 Company. 그러나 실제 세계 Microsoft에 부서가 Desktop Software있지만 데이터베이스 사용자가 부서를 대신한다고 주장하는 경우Software Development DBMS는 아무것도 할 수 없지만 사실이 있다고 가정합니다.

내가 질문을 이해하는 방식은 '노동자'테이블의 ID_Classification 필드는 각 근로자 회사에 대해 정의 된 분류 만 허용해야한다는 것입니다. 따라서 Workers.ID_Classification 필드에 삽입 / 업데이트 된 정보를 검증 (RULE 첨부 또는 TRIGGERS를 통해)하여이 요구 사항을 해결하는 데 적합합니다.

내 독서에서, 나는 여전히이 분류 가 무엇 이며 왜 ID_Company 가 필요한지 이해 하지 못합니다 . 누군가가 여기에 언급 한 것과 같은 위치라면 모든 위치를 포함하는 정적 테이블이 더 좋을 것이라고 생각합니다.

회사에서 분류 / 위치를 쉽게 찾기 위해이 작업을 수행하는 경우 간단한 쿼리 /보기를 추가하여 분류 작업자 부서 를 연결하고 분류 의 회사 ID를 검색하십시오.

요즘에는 구체화 된 뷰 및 조인 인덱스와 같은 더 스마트 한 뷰 또는 기술이 있으므로 문제가 쿼리 성능 인 경우이를 사용하십시오.