다 대다 및 약한 엔티티


16

나는 다른 사람에 의해 정의되지 않고 존재할 수없는 엔티티를 가지고 있으며이 엔티티가 다 대다 관계에 참여하기를 원합니다.

예 : 아티스트에 앨범이 있으며 (아티스트없이 앨범을 존재할 수 없음) 앨범에도 많은 트랙이 있지만 동일한 트랙이 많은 앨범에 존재할 수 있습니다.

그래서 우리는 앨범과 트랙 사이에 다 대다 관계가 있습니다.

앨범이 약한 엔티티 인 경우 기본 키는 아티스트를 참조하는 외래 키이므로 다 대다 관계를 나타내는 다른 테이블의 외래 키일 수 없습니다.

문제는 SQL에서 이런 종류의 관계를 가질 수 있습니까? 그렇다면 어떻게 표현합니까?


아니요, 앨범 기본 키는 앨범을 고유하게 만드는 정수일뿐입니다. 그런 다음 artist_id아티스트를 참조 하는 외래 키가 있을 수 있습니다 . 단일 트랙을 여러 앨범에 매핑하려면을 사용하여 매핑 테이블을 사용하십시오 track_id, album_id. Easy :)
Philᵀᴹ

답변:


16

"다이아몬드"관계 다이어그램을 사용하여 할 수 있다고 생각합니다.

도표

CREATE TABLE Artist
( artistID INT NOT NULL
, name VARCHAR(100) NOT NULL
, PRIMARY KEY (artistID)
) ;

CREATE TABLE Album
( artistID INT NOT NULL
, albumID INT NOT NULL
, title VARCHAR(100) NOT NULL
, PRIMARY KEY (artistID, albumID)
, FOREIGN KEY (artistID)
    REFERENCES Artist (artistID)
) ;

CREATE TABLE Track
( artistID INT NOT NULL
, trackID INT NOT NULL
, title VARCHAR(100) NOT NULL
, PRIMARY KEY (artistID, trackID)
, FOREIGN KEY (artistID)
    REFERENCES Artist (artistID)
) ;

CREATE TABLE AlbumTrack
( artistID INT NOT NULL
, albumID INT NOT NULL
, trackID INT NOT NULL
, trackNo INT NOT NULL
, PRIMARY KEY (albumID, trackNo)
, FOREIGN KEY (artistID, albumID)
    REFERENCES Album (artistID, albumID)
, FOREIGN KEY (artistID, trackID)
    REFERENCES Track (artistID, trackID)
, UNIQUE (trackID, albumID)               -- this Unique constraint should be added
                                          -- if no track is allowed twice in an album
) ;

1
+1 AlbumTrack 테이블에 (trackID, albumID) 및 (albumID, trackNo)와 같은 고유 제약 조건을 추가하는 것이 합리적입니까?
AK

@AlexKuznetsov 네가 맞아. 제안한대로 PK를 "축소" (albumID, trackNo)하고 다른 고유 제한 조건도 추가합니다.
ypercubeᵀᴹ

1
"Various"또는 이와 유사한 더미 아티스트가 있거나 앨범 테이블의 아티스트 열을 Null 허용으로 설정하여 단일 명목 아티스트가없는 앨범을 허용해야합니다. 실제로 트랙 당 두 명 이상의 아티스트가있을 수 있으므로 다 대다 배열도 필요할 수 있습니다.
David Spillett

1
@DavidSpillett 예, 우리는 그렇게 할 수 있지만 문제를 복잡하게 만들고 질문에서 벗어날 수 있습니다. 이 질문은 모든 앨범에 한 명의 아티스트가 있다고 가정하고 지시합니다. 트랙 당 다른 아티스트를 가질 수 없으며 앨범 또는 트랙 당 많은 아티스트를 가질 수 없습니다. 실세계를 잘 표현한 것은 아닙니다.
ypercubeᵀᴹ

1
@TimAbell 나는 그것이 다이어그램이 생성 된 Workbench의 사고라고 생각합니다 (PK의 열 순서로 인해 앨범-앨범 트랙 연결과 동일하게 인식하지 못합니다)
ypercubeᵀᴹ

2

불행히도 나는 ypercubeᵀᴹ의 답변에 대한 충분한 답변 이 없으므로 대체 답변을 게시 할 것입니다-나는 일반적으로 그 답변에 동의하지만 AlbumTrack 앨범과 트랙이 모두 약한 경우 기본 키와 고유 한 제약 조건 이 잘못 되었다고 생각합니다 엔티티. 예를 들어, 규정 된 제약 조건이있는 다음과 같은 유효한 데이터는 허용되지 않습니다.

 artistID | albumID | trackID | trackNo 
----------+---------+---------+---------
        1 |       1 |       1 |       1
        2 |       1 |       1 |       1

대신 PRIMARY KEY (artistID, albumID, trackID)고유 제약 조건을 설정 하고 삭제하여 다음 과 같은 결과를 얻었습니다.

CREATE TABLE Artist
( artistID INT NOT NULL
, name VARCHAR(100) NOT NULL
, PRIMARY KEY (artistID)
) ;

CREATE TABLE Album
( artistID INT NOT NULL
, albumID INT NOT NULL
, title VARCHAR(100) NOT NULL
, PRIMARY KEY (artistID, albumID)
, FOREIGN KEY (artistID)
    REFERENCES Artist (artistID)
) ;

CREATE TABLE Track
( artistID INT NOT NULL
, trackID INT NOT NULL
, title VARCHAR(100) NOT NULL
, PRIMARY KEY (artistID, trackID)
, FOREIGN KEY (artistID)
    REFERENCES Artist (artistID)
) ;

CREATE TABLE AlbumTrack
( artistID INT NOT NULL
, albumID INT NOT NULL
, trackID INT NOT NULL
, trackNo INT NOT NULL
, PRIMARY KEY (artistID, albumID, trackID)
, FOREIGN KEY (artistID, albumID)
    REFERENCES Album (artistID, albumID)
, FOREIGN KEY (artistID, trackID)
    REFERENCES Track (artistID, trackID)
) ;

트랙은 여전히 ​​앨범 당 최대 한 번 발생하도록 제한되어 있습니다.

또한이 질문은 실제로 트랙이 약한 엔티티 (앨범 만 있음)임을 지정하지 않습니다. 실제로 트랙이 아티스트와 독립적으로 존재할 수 있으면 테이블 TrackAlbumTrack테이블은 약간 다르게 정의됩니다.

CREATE TABLE Track
( trackID INT NOT NULL
, artistID INT
, title VARCHAR(100) NOT NULL
, PRIMARY KEY trackID
, FOREIGN KEY (artistID)
    REFERENCES Artist (artistID)
) ;

CREATE TABLE AlbumTrack
( artistID INT NOT NULL
, albumID INT NOT NULL
, trackID INT NOT NULL
, trackNo INT NOT NULL
, PRIMARY KEY (artistID, albumID, trackID)
, FOREIGN KEY (artistID, albumID)
    REFERENCES Album (artistID, albumID)
, FOREIGN KEY (trackID)
    REFERENCES Track (trackID)
) ;
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.