음악가 의 묘사가 포함 된 비즈니스 컨텍스트에 대한 엔티티 관계 다이어그램 (ERD)을 설계해야합니다.아래에서 자세히 설명 하듯 합니다.
아티스트 이 이름을 사용해야하며 하나 그룹 또는 솔로 출연자 (하지만 모두).
그룹은 하나 개 이상으로 구성되어 솔로 공연 과이 회원의 수 (의 수를 계산해야 솔로 공연 위로 만드는 그룹 ).
솔로 출연자는 수 있습니다 회원 다수의 그룹 또는 전혀의 그룹 과 하나 개 이상의 플레이 수 악기 .
그러한 시나리오를 나타 내기 위해 ERD를 구성하는 방법은 무엇입니까? 나는 그것의 '또는'부분과 혼동됩니다.
답변:
혼동되는 시나리오의 일부는 수퍼 타입-서브 타입 1 구조 라는 클래식 구성으로 모델링 될 수 있습니다 .
(1) 적절한 예비 아이디어를 소개하고, (2) 고려중인 비즈니스 컨텍스트를 개념 수준에서 설명하는 방법을 자세히 설명하고 (3) 추가 관련 자료 (예 : SQL을 통한 해당 논리 수준 표현)를 제공합니다. -DDL 선언 — 다음과 같습니다.
주어진 비즈니스 환경 에서 수퍼 타입 이 클러스터의 나머지 엔티티 유형 과 공유 되는 하나 이상의 특성 (또는 속성)을 갖는 엔티티 유형 의 클러스터가있을 때 이러한 특성의 구조가 발생 합니다. 의 하위 유형 . 모든 하위 유형 에는 그 자체에만 적용 할 수있는 특정 속성 집합이 있습니다.
수퍼 타입-서브 타입 클러스터는 두 종류가 될 수 있습니다 :
독점 . superentity 유형 의 인스턴스 에 항상 하나의 하위 유형 대응 항목이 있어야 하는 경우 가 발생합니다. 따라서 문제의 잠재적 인 아형 발생은 상호 배타적 입니다. 이것은 귀하의 시나리오와 관련된 종류입니다.
독점적 인 수퍼 유형 아형이 등장하는 전형적인 경우는 이 일련의 게시물 에서 고찰 된 상황에서와 같이 조직 과 개인 이 모두 법적 당사자 로 간주 되는 비즈니스 영역 입니다.
비 배타적 . 수퍼 타입 인스턴스 가 여러 서브 타입 어커런스 로 보완 될 수있는 경우를 표시합니다 . 각 서브 타입 은 다른 카테고리 여야합니다. 합니다.
이러한 유형의 수퍼 타입 하위 유형의 예는 이러한 게시물 에서 처리됩니다 .
참고 : 개념 문자의 요소 인 수퍼 타입 하위 유형 구조 는 특정 데이터 관리 이론적 프레임 워크에 속하지 않으며 관계형, 네트워크 또는 계층 구조 (각각 개념 요소를 나타내는 특정 구조를 제공함)에 속하지 않습니다 .
수퍼 타입-서브 타입 클러스터는 객체 지향 애플리케이션 프로그래밍 (OOP) 상속 및 다형성 과 특정 유사성을 갖지만 , 실제로는 서로 다른 목적을 수행하기 때문에 별개의 장치라는 점을 지적하는 것이 좋습니다. 실제 측면을 나타내야 하는 데이터베이스 개념 모델 에서 정보 요구 사항 을 설명하기 위해 구조적 특징을 다루는 반면, OOP 다형성 및 상속에서는 무엇보다도 (a) 스케치와 (b) 계산 및 행동 특성을 구현 합니다. 결정적으로 응용 프로그램 설계 및 프로그래밍에 속하는 측면.
그 외에도 , 응용 프로그램 구성 요소 인 개별 OOP 클래스 는 현재 데이터베이스의 개념적 수준에 속하는 개별 엔티티 유형의 구조를 반드시 "미러링"할 필요 는 없습니다 . 이와 관련하여, 애플리케이션 프로그래머는 전형적으로 예를 들어 2 개 이상의 상이한 개념 레벨 엔티티 유형의 모든 특성을 "결합"하는 하나의 단일 클래스를 생성 할 수 있으며, 이러한 클래스는 계산 된 특성을 포함 할 수있다.
엔터티 관계 구조를 사용하여 수퍼 타입 하위 유형 구조를 가진 개념적 모델 표현
당신은 요청 개체 - 관계 도표 특별한 모델링 플랫폼되고, 원래의 방법은 박사 피터 핀 샨 첸에 의해 도입 -as 있지만, (간결 ERD)하지만 2 - 정렬 존재의 시나리오를 대표 할 수있는 충분한 구조를 제공하지 않았다 적절한 데이터베이스 개념 모델에 필요한 정밀도로 논의했습니다.
결과적 으로, 새로운 방법으로 초기 다이어그램 작성 기술을 자연스럽게 강화하는 향상된 엔티티 관계 다이어그램 (EERD) 의 생성을 지원하는 접근법의 개발을 초래하는 상황, 상기 방법에 대한 일부 확장이 필요했습니다. . 이러한 특성 중 하나는 정확하게 수퍼 타입 서브 타입 구조를 묘사 할 수있는 가능성입니다.
그림 1에 나와있는 그림 은 EERD (라 메즈 A. 엘마 스리 및 Shamkant B. Navathe 3 ( 슈퍼 클래스 / 서브 클래스 와 같은 구조를 참조 하는 것과 유사한 기호 사용)를 사용하여 ) 명세서. Dropbox에서 다운로드 할 수있는 PDF 로도 제공됩니다 .
위에서 언급 한 다이어그램에서 볼 수 있듯이 Group및 SoloPerformer은 ( 는) superentity 유형 의 독점 하위 유형으로 표시됩니다 Artist.
EERD에 대한 설명을 시작하려면 문장을 지적하는 것이 중요합니다
수퍼 타입 서브 타입 클러스터 의 분리 및 완전성 측면 과 관련이있다 .
분리
그것이 바로 여기에 있기 때문에 당신이 언급하는 "또는 일부가"인해이 사실로, 활동하기 시작하는 곳 disjointness 기능은 특히 중요하다 Artist이어야 중 하나 개의 하위 유형 인스턴스 또는 나는 작은을 통해 EERD에 지정된 다른, 문자 "d"를 포함하는 원, 분리 된 규칙 의 이름을받는 구성 .
수퍼 타입이 하나 이상의 가능한 서브 타입으로 보충 될 수있는 경우,이 점은 겹침 규칙 이라고하는 기호 "o"가있는 레이블이있는 작은 원으로 표시되어야합니다 .
차별 속성
또한 이 수퍼 타입-서브 타입 연관 의 분리 요소의 범위 내에서 , Artist.Type이 배열에서 매우 관련성이 높은 작업을 수행하기 때문에 속성에 세심한주의를 기울일 가치가있다 : 서브 타입 판별 자 로서 기능한다 . 특정 인스턴스가 관련된 독점 유형 의 하위 유형을 나타내는 속성이므로 이러한 방식으로 이름이 지정 Artist됩니다.
비 독점 의 경우 클러스터 , 판별 자 특성의 사용은 불필요합니다. 특정 수퍼 타입은 여러 하위 유형을 보완 항목으로 가질 수 있습니다 (위에 설명).
전체 전문화 규칙 및 완성도
모든 사람 Artist이 항상 추가 하위 유형 인스턴스를 가져야 한다는 규정 은이 클러스터의 완성 특성과 관련이 있습니다. 이것은 (a) 수퍼 타입과 (b) 분리 된 규칙 구성을 연결하는 이중선 기호를 통해 입증 된 총 전문화 규칙 에 의해 설명됩니다 Artist.
솔로 연주자와 그룹 관계
문장 평가
과
두 하위 유형이 다 대다 (M : N) 연관 (또는 관계)에 관련되어 있음을 알 수 Group-SoloPerformer있습니다.
A의 구현 경우 관계형 A와 데이터베이스 기본 테이블이 구성 요소는 매우 유용 할 것이다 파생 총 (즉, 계산을 수행하는) Number의 SoloPerformers구체적인까지 확인을Group (당신이 지정하는 요구 사항 중 하나).
솔로 연주자와 악기의 연관성
규정
우리가 동시에
따라서 이것은 M : N 연관의 또 다른 예이며, SoloPerformer-Instrument그것을 드러내 기 위해 지정된 다이아몬드 모양의 그림을 사용 했습니다.
수퍼 타입-서브 타입 구조의 범위를 설명하기 위해 두 가지 추가 리소스, 즉
그림 2에 제시된 IDEF1X 4 다이어그램 ( 그리고 Dropbox에서 PDF로 다운로드 할 수도 있음 )은 문제의 비즈니스 도메인에 관한 이러한 종류의 다이어그램의 표현 기능을 보여줍니다. 과
SQL 데이터베이스 관리 시스템에 의해 논의중인 전체 시나리오를 관리하는 방법을 예시하는 각각의 설명 적 DDL 논리 구조.
IDEF1X 정보 모델링 기술은 확실히 수퍼 타입 하위 유형 구조를 묘사하는 기능을 제공하지만 한계는 있습니다 : 정확한 클러스터가 배타적이거나 배타적이지 않은지를 나타내는 시각적 메커니즘을 빌려주지 않습니다 (“네이티브”기호는 통신 만 가능합니다) 가능한 모든 하위 엔티티 유형의 중요성에 대한 완전 하거나 불완전한 식별). 다행히도 정보 기술 (IE) 표기법을 사용하여 IDEF1X 표준의 기술적 인 장점을 활용하면서이 가장 중요한 측면을보다 정확하게 보여줄 수 있습니다.
이 기법에서 질문의 주요 특징은 "범주 관계"로 표시되며, 여기서 수퍼 타입은 "일반 엔티티"라고하며 하위 유형은 "카테고리 엔티티"의 이름을받습니다. 그러나 나는 이 글에서 슈퍼 타입-아류 형 이라는 용어를 계속 적용 할 것이다. (1) 관계형 모델의 창시자 인 에드거 프랭크 코드 (Edgar Frank Codd) 박사가 사용했다. (2) 더 널리 알려져 있고 (3) IE 표기법은 다음과 같다. "네이티브"대신 사용됩니다.
외래 키 및 수퍼 타입 하위 유형 클러스터
입증 된 바와 같이, IDEF1X는 추가 장점을 제공한다 : 실무자가 관계형 데이터베이스 에서 수퍼 타입-서브 타입 연관을 나타낼 경우 가장 중요한 요소 인 FOREIGN KEY (FK) 정의를 나타내는 수단 .
협회 이러한 정렬 묘사하기 위하여, 퍼의 PRIMARY KEY (PK) 속성, 즉 Artist.ArtistNumber,에게 이전 에 Group및 SoloPerformer이 두 가지에 할당되었지만, 롤 이름 5, 6 , GroupNumber및를 SoloPerformerNumber강조 할 목적으로, 각각 의미 각 subentity 유형의 문장에 속성에 의해 전달.
PK로 특성화되는 것 외에, Group.GroupNumber및 SoloPerformer.SoloPerformerNumber특성은 동시에 Artist.ArtistNumber수퍼 타입 PK 특성을 참조하는 외래 키 (FK)로 묘사된다 .
모든 때문에 그래서, SoloPerformer그리고 Group발생은 존재에 의존하는 정확한에 Artist예,이 개체 유형은에 관여하는 식별 협회 전항에서 서술 약동학 특성 마이그레이션 프로세스의 방식으로 시행한다.
외래 키 및 연관 엔터티 유형
IDEF1X 다이어그램은 또한 두 개의 연관 엔티티 유형 관련성 의 PK를 구성하는 FK , 즉, GroupMember및 SoloPerformerInstrument; 첫 번째는 두 개의 하위 유형을 연결하고 두 번째는 하위 유형을 독립 엔티티 유형, 즉으로 연결 Instrument합니다.
앞서 설명한 바와 같이, 수퍼 타입-서브 타입 구조는 정보 요구 사항에 관한 특정 종류의 비즈니스 영역-특정 개념을 표현하는 수단이며, 이는 특정 요구 사항에 따라 제공되어야하는 특정 구성에 의해 데이터베이스에 표시 될 수있다. 이론적 패러다임 (관계형, 네트워크 또는 계층 적)과 디자이너가 사용하는 데이터베이스 관리 시스템이 뒤 따릅니다.
관계형 패러다임의 여러 장점 중 하나는 자연 구조로 정보를 표현할 수 있다는 것입니다. 관계형 이론에서 제안 된 시스템에 대한 가장 일반적인 근사치는 다양한 SQL 데이터베이스 관리 시스템입니다.
그럼, 마지막으로, 여기 (가) -including 일부 샘플 DDL 문이다 베이스 (B)와 함께 테이블 스키마를 일부 관련 constraints- 추상화의 논리 레벨에서, 표현 그이, 개념 모델링 운동이 위의 치료는 :
--
--
CREATE TABLE Artist ( -- Stands for the supertype.
ArtistNumber INT NOT NULL,
Name CHAR(30) NOT NULL,
Type CHAR(1) NOT NULL, -- Holds the discriminator values.
CreatedDateTime DATETIME NOT NULL,
--
CONSTRAINT Artist_PK PRIMARY KEY (ArtistNumber),
CONSTRAINT Artist_AK UNIQUE (Name), -- ALTERNATE KEY.
CONSTRAINT Artist_Type_CK CHECK (Type IN ('G', 'S')) -- Enforces retaining either ‘G’, for ‘Group’, or ‘S’, for ‘SoloPerformer’, only.
);
CREATE TABLE MyGroup ( -- Represents one subtype.
GroupNumber INT NOT NULL, -- To be constrained as PK and FK simultaneously.
FormationDate DATE NOT NULL,
--
CONSTRAINT MyGroup_PK PRIMARY KEY (GroupNumber),
CONSTRAINT MyGroupToArtist_FK FOREIGN KEY (GroupNumber)
REFERENCES Artist (ArtistNumber)
);
CREATE TABLE SoloPerformer ( -- Denotes the other subtype.
SoloPerformerNumber INT NOT NULL, -- To be constrained as PK and FK simultaneously.
BirthDate DATE NOT NULL,
--
CONSTRAINT SoloPerformer_PK PRIMARY KEY (SoloPerformerNumber),
CONSTRAINT SoloPerformerNumberToArtist_FK FOREIGN KEY (SoloPerformerNumber)
REFERENCES Artist (ArtistNumber)
);
CREATE TABLE GroupMember ( -- Stands for a M:N association involving the two subtypes.
MemberNumber INT NOT NULL,
GroupNumber INT NOT NULL,
JoinedDate DATE NOT NULL,
--
CONSTRAINT GroupMember_PK PRIMARY KEY (MemberNumber, GroupNumber), -- Composite PK.
CONSTRAINT GroupMemberToSoloPerformer_FK FOREIGN KEY (MemberNumber)
REFERENCES SoloPerformer (SoloPerformerNumber),
CONSTRAINT GroupMemberToMyGroup_FK FOREIGN KEY (GroupNumber)
REFERENCES MyGroup (GroupNumber)
);
CREATE TABLE Instrument ( -- Represents an independent entity type.
InstrumentNumber INT NOT NULL,
Name CHAR(30) NOT NULL,
--
CONSTRAINT Instrument_PK PRIMARY KEY (InstrumentNumber),
CONSTRAINT Instrument_AK UNIQUE (Name) -- ALTERNATE KEY.
);
CREATE TABLE SoloPerformerInstrument ( -- Denotes another M:N association, in this case between a subtype and an independent entity type.
SoloPerformerNumber INT NOT NULL,
InstrumentNumber INT NOT NULL,
CreatedDate DATE NOT NULL,
--
CONSTRAINT SoloPerformerInstrument_PK PRIMARY KEY (SoloPerformerNumber, InstrumentNumber), -- Composite PK.
CONSTRAINT SoloPerformerInstrumentToSoloPerformer_FK FOREIGN KEY (SoloPerformerNumber)
REFERENCES SoloPerformer (SoloPerformerNumber),
CONSTRAINT SoloPerformerInstrumentToInstrument_FK FOREIGN KEY (InstrumentNumber)
REFERENCES Instrument (InstrumentNumber)
);
--
--데이터 무결성 및 일관성 고려 사항
앞에서 설명한 모든 내용에 동의하여 설계자는 각 "슈퍼 타입"행이 항상 해당하는 "서브 타입"상대방에 의해 보완됨을 보장 하고, "서브 타입"행이 값과 호환되는지 확인해야합니다. 수퍼 타입“구별 자”열에 포함되어 있습니다.
(관계형 프레임 워크가 제안한대로) 언급 된 상황을 선언적 으로 적용하는 것은 매우 실용적이고 우아 하지만, 아쉽게도 주요 SQL 플랫폼 중 어느 것도 (내가 아는 한) 적절한 메커니즘을 제공하지 않았습니다. 따라서 이러한 조건이 항상 데이터베이스에서 충족되도록 ACID 트랜잭션 을 사용하는 것이 매우 편리 합니다 (다른 옵션은 TRIGGERS를 사용하는 것이지만 어수선한 것을 만드는 경향이 있습니다).
데이터 도출 고려 사항
관계형 모델의 주요 측면 중 하나는 데이터 파생 을 데이터 관리에서 가장 중요한 요소로 간주한다는 것 입니다. 따라서 (a) 위의 DDL 문에 표시된 기본 관계 또는 SQL의 기본 테이블 및 (b) 파생 관계 -SQL의 파생 테이블, 즉 SELECT 작업의 dint에 의해 선언 된 파생 테이블을 쉽게 만들 수 있습니다. 추가 착취를위한 견해로 수정 됨 —.
따라서 "전체" 그룹 데이터 포인트 를 수집하는 뷰를 선언 할 수 있습니다 .
CREATE VIEW FullGroup AS
SELECT G.GroupNumber,
A.Name,
A.CreatedDateTime,
G.FormationDate
FROM Artist A
JOIN MyGroup G
ON G.GroupNumber = A.ArtistNumber;그리고 "전체" SoloPerformer 정보 를 결합한 다른 견해 :
CREATE VIEW FullSoloPerformer AS
SELECT SP.SoloPerformerNumber,
A.Name,
A.CreatedDateTime,
SP.BirthDate
FROM Artist A
JOIN SoloPerformer SP
ON SP.SoloPerformerNumber = A.ArtistNumber;이러한 방식으로 매우 중요한 논리 수준 장치, 즉 관계 또는 테이블 (기본 또는 파생)을 통해 모든 중요한 데이터를 선언적으로 조작하는 것이 매우 쉽습니다. 관계형 데이터베이스에 표현 된 개념적 개체 유형이 더 많은 관심 속성을 가질 때 뷰 사용이 더 효과적 일 수 있지만, 현재 시나리오에서 설명 할 가치가 있습니다.
1 Codd, EF (1979 년 12 월). 데이터베이스 관계형 모델을 확장하는 것은 더 의미 캡처하는 , 데이터베이스 시스템에 ACM 거래 , 4 권 4 호 (PP. 397-434 참조). 뉴욕, 뉴욕, 미국.
2 Chen, PP (1976 년 3 월). 실체-관계 모델 — 데이터의 통일 된 관점 , 데이터베이스 시스템에 대한 ACM 거래-특별 이슈 : 초대형 데이터베이스에 관한 국제 회의 논문 : 1975 년 9 월 22 일 -24 일, MA , Framingham, MA , Volume 1 Issue 1 (pp 9-36). 뉴욕, 뉴욕, 미국.
3 Elmasri, R & Navathe, SB (2003). 데이터베이스 시스템의 기초 , 제 4 판. 애디슨-웨슬리 롱먼 출판사, 미국 매사추세츠 보스턴.
4 국립 표준 기술 연구소 (US) [NIST] (1993 년 12 월). 정보 모델링 (IDEF1X)에 대한 통합 정의, 연방 정보 처리 표준 간행물 , 184 권. 미국.
5 Edd Codd (1970 년 6 월). 대형 공유 데이터 은행에 대한 데이터의 관계형 모델 , ACM의 통신 , 13 권 제 6 호 (PP. 377-387). 뉴욕, 뉴욕, 미국.
6 참조 4
MDCCL 의 답변 은 흥미롭고 교육적이며 아마도 정확합니다 (내 급여 수준보다 높음).
대조적으로, 나는 질문을 다시 해석하고 가장 간단한 해결책을 위해 기본으로 돌아갔습니다. 어쩌면 나는 바람을 피우고 진정으로 질문에 대답하지는 않지만 ... 어쨌든 간다.
질문을 읽고 다시 읽을 때 혼란 스러웠습니다. "아티스트"라는 용어를 볼 때 나는 개별 사람들을 계속 생각했습니다. 그러나 음악 레코드 앨범에 제목과 아티스트가 Johnny Cash 와 같은 개인인지 또는 The Cure 와 같은 그룹 인지와 같은 "예술적 브랜드 라벨링"의 의미를 의미합니다 .
이제 Prince로 알려진 예술가를 예로 들어 봅시다 . 그는 다음과 같이 앨범을 출판했습니다.
그중 4 개는 모두 "아티스트"의 사례입니다. 특히, 웬디 멜 보인과 리사 콜먼이라는 두 명의 여성이 그의 밴드 The Revolution에 있었지만 New Power Generation 에는 없었습니다 . Wendy & Lisa 라는 브랜드로 경력을 계속했습니다 .
그래서 우리는 Wendy & Lisa 와 함께 또 다른 "아티스트"의 인스턴스를 가지게되지만 Melvoin과 Coleman 개인은 각각 "아티스트"가 아닌 공연 자일 것입니다. 그 개별 여성들은 두 명의 "아티스트"(1) 프린스 앤 더 레볼루션 , (2) 웬디 & 리사 )의 공연자로 임명 될 것 입니다.
다음 다이어그램은이 예제 데이터를 간결하게 표시하기위한 서투른 시도입니다. 우리는 두 개의 다른 밴드 (아티스트)에 속하는 두 개의 밑줄 친 여성 (공연자)을 보여줍니다. 그리고 우리는 네 개의 밴드 (예술가) 만에 속하는, 이탤릭체 사람, 왕자를 표시 하지 마지막 밴드 (작가)에 속하는.
그것이 비즈니스 도메인을 설명한다면, 나는 다음 테이블 디자인 (및 ERD)을 제안 할 것입니다.
기본적으로 우리는 다 대 다 관계 쌍을 가지고 있습니다 :
"그룹"및 "SoloPerformer"는 다음과 같습니다.
비즈니스 로직의 일부가 Solo 대 Group 인 Artist 항목을 구별하는 것이라면 SQL에서 행 멤버십 테이블이 하나 인 아티스트 행과 여러 개의 멤버 테이블이있는 아티스트 행에 대해 쿼리를 수행 할 수 있습니다. 그러나 실제로는 다음을 통해이 정보를 비정규 화하는 것이 좋습니다.
질문의 목표가 데이터베이스 구조 (또는 ERD) 내 에서이 솔로 대 그룹 구별을 시행하는 것이면 실패했습니다. 그러나 어쨌든이 답변이 흥미롭고 유용 할 수 있기를 바랍니다.
MDCCL의 답변은 EERD 수준에서 묘사 된 수퍼 클래스 / 서브 클래스 또는 일반화 / 전문화의 개념에 대한 훌륭한 요약입니다.
이 답변은 정의 된 열이있는 정의 된 테이블을 기반으로 EERD를 관계형 디자인으로 전환 할시기가되었을 때 알아야 할 세 가지 디자인 패턴 또는 기술을 지적하기위한 것입니다.
다음은 세 가지입니다.
처음 두 가지는 대안이며, 하나는 거의 모든 데이터가 수퍼 클래스와 관련된 간단한 경우에 좋습니다. 두 번째는 더 복잡하지만 많은 데이터가 여러 하위 클래스와 관련되어 있으면 더 잘 작동 할 수 있습니다. "상속"이라는 단어는 디자인이 상속이 객체 모델에서 제공하는 것과 동일한 표현력을 제공함을 나타내는 데 사용됩니다.
공유 기본 키는 서브 클래스 테이블의 항목이 수퍼 클래스 테이블의 해당 항목 ID를 "상속"하여 ID를 얻을 수있는 기술입니다.
SO에는 이러한 이름을 가진 3 개의 태그가 있습니다. 각 태그 아래의 정보 탭은 설명을 제공하며 태그 아래에 많은 질문이 그룹화되어 있습니다.
이러한 기술을 제공하는 많은 웹 사이트도 있습니다. 나는 Martin Fowler의 것을 추천합니다. 나는 그가 그것을 제시하는 방식을 좋아한다. 다음은 몇 가지 웹 페이지입니다.