문제

데이터베이스를 설계 할 때 하위 유형 테이블에 대해 많이 듣고 있으며 그 뒤에있는 이론을 완전히 알고 있습니다. 그러나 나는 실제로 테이블 서브 타이핑을 본 적이 없다. 테이블의 하위 유형을 어떻게 만들 수 있습니까? MS Access를 사용하고 있으며 GUI (Access 2003)를 통해 SQL에서도 수행하는 방법을 찾고 있습니다.

건배!

도움이 되었습니까?

해결책

쉬운 예는 기본 키가있는 사람 테이블과 해당 테이블에 일부 열이있는 것입니다. 이제 사람 테이블 (슈퍼 타입)에 대한 외국 키가있는 학생이라는 다른 테이블을 만들 수 있습니다. 이제 Student Table에는 SuperType에 GPA, Major 등이없는 일부 열이 있지만 이름, 성 등은 부모 테이블에 있습니다. 학생 테이블의 외국 키를 통해 항상 개인 이름으로 학생 이름에 액세스 할 수 있습니다.

어쨌든 다음을 기억하십시오.

  • 계층 구조는 초형과 하위 유형 사이의 관계를 나타냅니다
  • 슈퍼 타입에는 일반적인 속성이 있습니다
  • 하위 유형에는 고유 속성이 있습니다

다른 팁

테이블의 하위 유형은 EER 다이어그램에서 개념적 인 것입니다. 직접 지원하는 RDBMS (객체 관련 DBMS 제외)를 보지 못했습니다. 그들은 일반적으로 어느 쪽이든 구현됩니다

  1. 단일 테이블에서 하위 유형의 각 속성에 대한 무효 열 세트
  2. 기본 유형 특성 용 테이블과 하위 유형 특성이 포함 된 기본 테이블 당 최대 1 행이있는 다른 테이블이 있습니다.

테이블 하위 유형의 개념은 ORM 맵퍼를 사용하여 도메인을 정확하게 모델링하는 클래스 하위 유형 상속인을 생성 할 때 유용합니다.

하위 유형 테이블은 부모에게 외국 키를 다시 갖추고 있으며,이 키는 하위 유형 테이블의 기본 키이기도합니다.

액세스 애플리케이션과 마찬가지로 바운드 애플리케이션을 설계 할 때 하위 유형은 조인 측면에서 많은 비용을 부과합니다.

예를 들어, 3 개의 하위 유형 테이블이있는 SuperType 테이블이 있고 한 번에 단일 양식으로 세 가지를 모두 표시 해야하는 경우 (SuperType 날짜뿐만 아니라 표시가 필요하지 않으면) 세 개의 외부 조인 조인을 사용하는 선택으로 끝납니다. 및 NZ () 또는 3 개의 상호 독점적 인 선택 설명 (각 하위 유형 당 하나)이 모두 조합이 필요합니다. 이들 중 어느 것도 편집 할 수 없습니다.

Super/Subtype 테이블로 작업 한 첫 번째 주요 앱에서 SQL을 붙여 넣으려고했지만 SQL은 너무 복잡하여 사람들을 혼동 할 수 있습니다. 내 앱이 복잡했기 때문에 그다지 많지는 않지만 문제의 특성이 복잡하기 때문입니다. 슈퍼 유형과 하위 유형 모두 사용자에게 전체 데이터 세트를 제시하는 것은 본질적으로 복잡합니다. 그것과 함께 일한 나의 결론은 하나의 하위 유형 테이블만으로 더 나아 졌다는 것이었다.

그것은 어떤 상황에서는 유용하지 않다고 말하는 것은 아닙니다. 액세스의 바운드 양식 만으로도이 데이터를 사용자에게 쉽게 제시 할 수는 없습니다.

나는 내가 작업 한 비슷한 문제가 있습니다.

반복 가능한 패턴을 찾는 동안, 나는 참조 무결성을 포기하지 않았는지 확인하고 싶었습니다. 이는 (table_name, pk_id) 솔루션을 사용하지 않을 것입니다.

나는 마침내 정착했다 :

기본 유형 테이블 : 고객

서브 유형 테이블 : 사람, 비즈니스, Govt_entity

나는 nullable prerson_id, business_id 및 govt_entity_id 필드를 고객에게, 외국 키가 각각에, 그리고 하나만 무효가되지 않는 점검 제약 조건을 넣습니다. 새 하위 유형을 추가하기가 쉽습니다. 무효화 가능한 외래 키를 추가하고 점검 제약 조건을 수정하면됩니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top