ER 데이터베이스의 OO 동작 (여러 테이블에 대한 일대 다 관계)

Question

학교용 문서 관리 시스템을 설계하고 있습니다 (SQL & .NET). 학교에는 인사, 학생, 금융 등과 같이 저장하고자하는 다양한 데이터가 있습니다. 시스템은 문서의 유형 (직원, 학생 ...)에 관계없이 시스템의 모든 기록에 문서를 첨부 할 수 있어야합니다.

이 작업을 수행하는 전형적인 ER 방법은 Tye 다른 유형 테이블 (personnel ...)과 Documents 테이블을 만드는 것입니다. 유형 테이블 레코드를. 서 레코드에 연관 시키려면, PersonnelID W DocumentID C 럼이있는 PersonnelDocuments와 같은 "링크 테이블"이 필요합니다.

이 접근 방식은 각각 미래의 시스템에서 연결 테이블이 필요한 100 개의 유형 테이블이있을 수 있기 때문에 약간 어색합니다. 적절한 ER DB 설계를 계속 수행하면서보다 일반적인 방법으로이를 수행 할 수 있습니까?

Answer 1

고유 한 식별자를 너무 크게 만들면 데이터베이스의 모든 개체가 테이블에 관계없이 고유 한 식별자를 갖게됩니다 (GUID는 종종 그렇습니다). 모든 객체에 대한 고유 식별자를 얻은 후에는 단일 링크 테이블 만 있으면됩니다. 이 접근 방식을 데이터베이스의 모든 개체에 주석을 달 수 있어야하는 응용 프로그램에 사용했고, 그랬던 것처럼 XXXXComments 및 YYYYComments라는 수십 개의 테이블을 잘라내지 않을 것입니다. 이 솔루션은 일을 훌륭하게 청소했습니다.

EDIT : 이전에 사용한 또 다른 접근법은 문서 링크가 필요한 모든 테이블을 동일한 기본 테이블에서 파생시키는 것입니다. 이 방법은 도메인 자체가 작거나 문서 링크가 필요한 섹션이 자체적으로 포함되어 있지 않는 한 종종 매우 혼란 스럽습니다. 올바르게 기억한다면 보고서 유형이 여러 가지 인 보고서 추적 응용 프로그램을 만들었습니다. 각 보고서는 회사의 다른 그룹으로 전달 된 다음 필요한 항목이 모두 수집 될 때까지 다른 그룹으로 전달 및 전달되었습니다. 처리. 보고서 기본 테이블을 만들었고 포워드에 대한 링크 테이블에서 각 유형의 보고서에 전달 테이블을 만드는 대신 해당 ID를 사용했습니다.

Answer 2

시스템을 문서 관리 시스템으로 설명합니다. 그런 다음 한 가지 해결책은 시스템에서 엔티티의 문서화 된 성격의 우선 성을 존중하는 것입니다. 다음 모델은 문서 테이블에 대한 부모 역할을하는 추상 엔티티와 여러 하위 유형 테이블에 대한 수퍼 유형을 정의합니다. 이 모델을 사용하면 여러 문서를 DocumentedThing과 연결할 수 있습니다.

DocumentedThing 
--------------- 
ThingId  Integer primary key 
ThingType String check (ThingType in ('PUPIL', 'STAFF')) 
      unique key (ThingId, ThingType) 

Document 
-------- 
ThingId  Integer foreign key references DocumentedThing (ThingId) 
DocumentId Integer primary key 
Text   Clob 

Pupil 
----- 
PupilId  Integer primary key 
ThingId  Integer unique key 
ThingType String check (ThingType = 'PUPIL') 
Name   String 
DateOfBirth Date 
      foreign key (ThingId, ThingType) 
       references DocumentedThing (ThingId, ThingType) 

Staff 
----- 
StaffId  Integer primary key 
ThingId  Integer unique key 
ThingType String check (ThingType = 'STAFF') 
Name   String 
HireDate  Date 
      foreign key (ThingId, ThingType) 
       references DocumentedThing (ThingId, ThingType) 

고유 키의 발판은 DocumentedThing가 Staff 또는 Pupil하지만 두 곳의 기록을 가지고 수 있도록합니다. 또한 모든 하위 유형 테이블에는 여러 레코드가있을 수 없습니다. Staff의 레코드는 에 'STAFF'값이있는 DocumentedThing의 레코드에만 매핑 할 수 있습니다. 시행하기 어려운 한 가지는 DocumentedThing은에 하위 유형 레코드가 있어야한다는 주장입니다. 이 작업은 수행 할 수 있지만 일반적으로 복잡하며 어느 정도까지는 DBMS 제품 선택에 따라 다릅니다.

새로운 하위 유형을 추가하면 영향을 최소화 할 수 있습니다. 정보를 보유 할 실제 테이블을 추가하는 것 외에 DocumentedThing.ThingType에 새 값을 추가하기 만하면됩니다. 하위 유형이 많은 경우 점검 제한 조건이 아닌 룩업 테이블로 외래 키를 사용하여이를 제한 할 수 있습니다.