좋아, 나는 SQL 등을 처음 접했기 때문에 이것이 완전히 잘못된 경우 사과드립니다 ..
나는 내가 옳다고 생각하는 ER 모델을 디자인했고 그것을 관계형 모델로 변환하려고 노력하고 있으며 그것을 변환 할 때 내가 어디에서 잘못되었는지에 대한 조언을 원합니다. 내 머리를 찢어.
내가 믿는대로 ..
1-1 관계 엔터티는 결합되거나 한 엔터티 유형의 기본 키가 다른 관계의 외래 키로 배치됩니다.
1-m 관계 '한 쪽'의 기본 키는 다 쪽에서 외래 키로 배치됩니다.
mn 관계 복합 키를 형성하는 각 엔터티의 기본 키를 사용하여 새 관계가 생성됩니다.
다중 값 속성 은 새 테이블이 생성되고, 첫 번째 테이블에서 사용되는 기본 키와 두 번째 테이블 alognside 기본 키에서 사용되는 속성입니다.
이제 관계형 모델, PK는 굵게, FK는 이탤릭체로 가겠습니다.
USER : USERID FNAME LNAME USERNAME PASSWORD USERTYPE EMAIL
CUSTOMER : USERID , CUST_ID , BIO
관리자 : USERID ADMIN_ID
ARTIST USERID , ARTIST_ID , BIO REC_ID
PRODUCER : PROD_ID , 이름, 이메일
레코드 레이블 : RECORD_ID , NAME, DESCRIPTION
앨범 : ALBUMID NAME, COST, TITLE, NOOFSONGS
트랙 : 트랙 ID , NAME, COST, TITLE, DESCRIPTION
TRACK REVIEW : TRACK에 따라 TRACK ID가이 테이블에 들어옴 = REVIEW_ID (PK) , TRK_ID (PK) NAME
TRACK PURCHASE TABLE (사용자 ID가이 테이블에 외래 키로 들어옴 ) TrackPuchaseID user_id , date
ALBUM PURCHASE TABLE AlbumPuchaseID user_id , 날짜, 수량
GENRE TABLE ?: 확실하지 않습니까 ??
BPM : 다중 값 속성이므로 별도의 테이블이므로 GenreID BPM
이 모든 것이 잘못되었을 수 있음을 알고 있습니다. 그러나 어떤 도움이 될 것입니다 .. FK 또는 복합 PK 등의 설명 또는 내가 놓친 테이블 ..
album purchase당신이해야합니다 user_id, date, album_id.track purchase왜 당신이에 관심 quantity이 있고 track_id.review, track, album, user모두를 포함해야합니다 date. 뿐만 아니라 흥미로운를 추가 할 수 있습니다 last_update_date받는 사람 artist과 customer.review을 포함해야한다 user_id.다른 것이 남아있는 것 같아요. "customer xyz buy the items 1,2,3,4 ..."라고 말할 수 있는 Invoice/ Invoice_Purchase테이블 이 필요 합니다. 다음과 같아야합니다.
표 Invoice
표 Invoice_Purchase
status알번과 트랙 에 a 를 추가해야 할 수도 있습니다. 이렇게하면 항목을 구입할 수 있는지 여부를 설정할 수 있습니다. 그리고 예, 이전 인보이스가 릴레이되므로 삭제해서는 안됩니다.
어쨌든 관계 부분을 그리고 DB를 배포하는 것과 같은 소프트웨어 사용을 나중에 고려해야 Navicat합니다.
이 기사는 인터넷에서 수집됩니다. 재 인쇄 할 때 출처를 알려주십시오.
침해가 발생한 경우 연락 주시기 바랍니다[email protected] 삭제
몇 마디 만하겠습니다