데이터베이스 설계시 서브 타이핑 테이블에 대해 많이 들었고, 나는 그 이론을 완전히 알고 있습니다. 그러나, 나는 실제적으로 테이블 subtyping을 실제로 본 적이 없다. 어떻게 테이블의 하위 유형을 만들 수 있습니까? 나는 MS Access를 사용하고 있으며, SQL과 GUI (Access 2003)를 통해이를 수행하는 방법을 찾고있다.서브 테이블 데이터베이스 테이블
건배!
간단한 예는 기본 키와 그 테이블의 일부 열이있는 Person 테이블을 갖는 것입니다. 이제 사용자 테이블 (해당 상위 유형)에 대한 외부 키가있는 Student라는 다른 테이블을 작성할 수 있습니다. 이제 학생 테이블에는 수퍼 유형이 GPA, Major 등과 같이 가지지 않는 열이 있습니다. 그러나 이름, 성 등은 부모 테이블에 있습니다. Student 테이블의 외래 키를 통해 Person 테이블에서 언제든지 학생 이름에 액세스 할 수 있습니다.
은 어쨌든, 단지 기억 다음
테이블의 하위 유형은 EER 다이어그램에서 개념적인 사항입니다. 나는 그것을 직접 지원하는 RDBMS (객체 - 관계형 DBMS 제외)를 보지 못했다. 그들은 일반적으로 기본 유형의 특성과 기본 테이블 당 최대 하나 개의 행이 다른 테이블에 대한 테이블이 단일 테이블
ORM 매퍼를 사용하여 도메인을 정확하게 모델링하는 클래스 하위 유형 계층을 생성 할 때 테이블 하위 유형 개념이 유용합니다.
하위 유형 테이블에는 하위 유형 테이블의 기본 키인 상위 키와 상위 키가 모두 있습니다.
하위 유형 테이블 레코드가 상위 테이블과 1 : 1 관계를 갖는 경우 왜 FK를 PK로만 사용하지 않을까요? –
염두에 두어야 속성을 가지고있는 그 바운드 애플리케이션을 설계 할 때 Access 애플리케이션과 마찬가지로 부속 유형은 조인 측면에서 많은 비용이 듭니다.
예를 들어 세 개의 하위 유형 테이블이있는 수퍼 유형 테이블이 있고 한 번에 하나의 단일 양식으로 세 개의 모든 유형을 표시해야하는 경우 (그리고 상위 유형 날짜 만 표시하면 안됨) 세 개의 외부 조인과 Nz()를 사용하거나 상호 배타적 인 세 개의 SELECT 문 (각 하위 유형마다 하나씩)의 UNION ALL이 필요합니다. 어느 것도 편집 할 수 없습니다.
슈퍼/서브 타입 테이블로 작업 한 첫 번째 주요 앱에서 일부 SQL을 붙여 넣으려고했지만 SQL을 보면 너무 복잡한 데 사람들을 혼란스럽게 만들뿐입니다. 내 응용 프로그램이 복잡하기 때문에 그렇게 많은 것이 아니지만 문제의 본질이 복잡하기 때문에 - 사용자에게 슈퍼 및 하위 유형의 전체 데이터 집합을 표시하는 것이 매우 자연스럽게 복잡합니다. 결론을 내릴 때 단 하나의 하위 유형 테이블 만 있으면 더 좋았을 것입니다.
일부 상황에서는 유용하지 않다고 말하는 것은 아니지만 Access의 바인딩 된 양식이 반드시이 데이터를 사용자에게 쉽게 제공하지는 못합니다.
저는 비슷한 문제를 겪고 있습니다.
반복 가능한 패턴을 찾고있는 동안 참조 무결성을 포기하지 않도록하고 싶었습니다. 즉, (TABLE_NAME, PK_ID) 솔루션을 사용하지 않을 것임을 의미했습니다.
자료 유형 테이블 : :
나는 마지막에 정착 고객
하위 유형 테이블 : 명, 사업, 외래 키와
내가 고객에 널 (NULL) PRERSON_ID, BUSINESS_ID 및 GOVT_ENTITY_ID 필드를 넣어 GOVT_ENTITY, 각각에 대해, 그리고 오직 하나만 널 (null)이 아닌지 점검 제한 조건. 새 하위 유형을 쉽게 추가 할 수 있으며 null 허용 가능 외래 키를 추가하고 점검 제한 조건을 수정하면됩니다.
미안하지만 나는 단지 당신이 참고를 기술하고 있다고 생각합니다. 소위 말하는 슈퍼 타입 테이블에는 타입 속성이 없습니다! 더 나은 IMO 예제를 보려면이 스레드에서 CREATE TABLE Vehicles 게시물을 참조하십시오. http://bytes.com/groups/ms-sql/808389-design-question-type-heirarchy-supertype-queries – onedaywhen
예, discriminator column, 같은 문제를 풀기위한 또 다른 접근 방법입니다. 나는 그 접근법을 잘 알고 있었다. 그렇다고 내 해결책이 잘못되었다는 의미는 아닙니다. 간단하고 간단한 예를 들어보고 싶었습니다. 게시 한 링크에는 해당 구조를 모델링하는 데 여러 가지 방법이 있다는 내용의 게시물이 명시되어 있습니다. 내가 게시 한 것과 비슷한 예가 "데이터베이스 시스템 : 설계, 구현 및 관리 제 6 판"이라는 책에서 언급됩니다. 피. 150, 151 및 159. – jasonco
위의 내용에 대해 필자는 Student 테이블의 PK에 Person 테이블의 대리 키에 대한 외래 키 제약 조건이 있음을 명시해야합니다. 이 가져 오기는 Student 관계의 튜플에 Person 테이블의 해당 튜플과 독립적 인 ID가없는 것입니다. 따라서 이것은 진정한 하위 유형 관계입니다. 클레임에 대한 언급이 아닙니다. – Recurse