2011-01-26 8 views
0

사용자가 mp3를 구입하고 스트리밍 할 수있는 음악 스트리밍 사이트를 구축 중입니다.데이터베이스 디자인

ER DIAGRAM

내가 3NF에 데이터를 정상화 할 : I는 다음과 같이 설명 될 수있는 일부 개체도있다. 얼마나 많은 표가 필요합니까? 분명히 앨범, 아티스트, 노래 이외의 테이블을 더 필요로하는 부분적인 의존성을 피하고 싶습니다.하지만 추가 할 부분이 무엇인지 모르겠습니다. 경험에 대한 어떤 생각?

+0

노래가 하나의 앨범으로 발표되고 앨범에 포함 된 경우 다른 노래로 간주 되나요? 이 시나리오에서 – Quassnoi

+0

을 사용하면 이상적으로 두 목록이 모두 나타나길 원합니다. 앨범의 노래와 단일 – dr85

+0

으로 출시 된 노래가 여러 아티스트가 앨범을 제작할 수 있다면? – ThomasMcLeod

답변

1

아티스트, 노래, 앨범 및 AlbumSong이 4 개 필요합니다.
정확하게 동일한 노래 (= 동일한 편집/버전 ...)가 여러 앨범에 포함될 수 있으므로 마지막으로 필요하므로 m 대 m 관계가 있습니다.

0

iDevelop에 동의하지만 1 개의 추가 표가 있습니다. 여기 내가 어떻게 모델링 할 것인가.

테이블 : 아티스트, 노래, 앨범, AlbumSongMap, SingleInfo

노래가 다른 날짜에 싱글로 출시 된 경우

, 당신은 SingleInfo에서 해당를 얻을 수 있습니다. 싱글은 앨범 아트와 다른 커버 아트로 출시되었을 수도 있습니다. SingleInfo에 싱글 아트를 저장합니다. 노래는 새로운 커버 아트 등으로 여러 번 싱글로 출시 될 수 있으므로 1 - 많은 관계가 될 수 있습니다. 그렇지 않으면 1-1입니다.

Song을 SingleInfo와 결합 할 수 있으면 싱글로 출시되었음을 의미합니다. 노래를 앨범과 결합 할 수 있으면 (지도를 사용하여) 노래가 발표 된 모든 앨범을 찾을 수 있습니다.

오래된 노래에 대한 디지털 향상 기능은 새로운 노래입니다. (또는 적어도 다른 바이너리). SongName 등을 복제하지 않고도 디지털 향상 기능을 저장할 수 있도록 Song을 추가로 정규화 할 수 있습니다.

+0

albumsongmap은 노래 테이블과 앨범 테이블의 기본 키 (예 : catalogueNumber 또는 id)로 구성됩니다. – dr85

5

글쎄, ER 수준을 완료했습니다. 기능적 종속성을 찾기 전에 키와 속성을 식별해야합니다. 3NF에 오기 전에해야 할 일이 상당합니다. 예 : 노래 제목이 복제됩니다.

또한, 질문이 있습니다 :

  • 이다 앨범, 노래, 또는 둘 모두를 판매하는 사이트? (나는 둘 다 모델을 만들었습니다)
  • 두 경우 모두 판매 또는 다운로드를 어떻게 추적합니까?
  • 다른 아티스트가 녹음 한 동일한 노래 제목이 마음에 드십니까?

어쨌든 여기에 제공된 정보는 ▶Entity Relation Diagram◀입니다. 3NF보다 5NF에 더 가깝지만, 완전하지 않기 때문에이를 선언 할 수는 없습니다.

관계형 데이터베이스 모델링에 익숙하지 않은 독자는 ▶IDEF1X Notational◀이 유용 할 수 있습니다.

간단한 Supertype-Subtype 구조 인 Orthogonal Design의 원리를 사용합니다. 판매 된 품목 즉 앨범 xor 또는 노래.

명확한 질문을하는 것이 좋습니다.

+0

안녕하세요 - 정보를 제공해 주셔서 감사합니다. ER 다이어그램이 훨씬 좋습니다. 귀하의 q에 관해서 - 사이트는 싱글과 두 앨범을 판매합니다 (예 : iTunes) - 사용자는 앨범이나 전체 앨범에서 싱글을 구입할 수 있습니다. 판매를 추적하려면 (다운로드가 없음 - 순전히 스트리밍) 사용자가 구입 한 노래가 포함 된 테이블을 가지고있는 컬렉션 기능을 생각 중이었습니다. 같은 노래 제목은 정말 문제가되지 않습니까? 아티스트를 식별하고, 적절한 경우 해당 앨범을 직접 확인할 수있는 방법을 제공합니다. – dr85

+1

@ drb5. 천만에요. 나는 모든 것을 제공했다. '다운로드'는 판매 된 '항목', 즉 '노래'또는 '앨범'입니다. 'SongTitle' 등 모든 것이있다. 'User' 모델링을 원하십니까? 끝난. 수퍼/하위 유형을 이해하고 있습니까? – PerformanceDBA

+0

감사. 아니, 괜찮아. 벌써 충분히 했어. - 앨범 아티스트 곡을 모델링하는 방법과 다양한 아티스트를 포함시키는 방법에 대해 약간 혼란스러워서 사용자가 어떤 아티스트가 편집 CD에서 어떤 노래를 제작했는지 볼 수 있습니다. – dr85

0

ER 모델링에서 관계형 모델링 (테이블)으로 전환 할 때 각 엔티티에 대해 하나의 테이블이 필요합니다. 또한 일부 관계에 대한 테이블이 필요합니다.

우리가 제공 한 다이어그램에서 두 관계는 모두 1 대 1입니다. 다 대일 관계는 테이블을 필요로하지 않습니다. 엔티티 테이블에 외래 키를 추가 할 수 있습니다. 따라서 귀하의 질문에 대한 답변은 3 개의 테이블 : 아티스트, 앨범 및 노래입니다.

나는 ER 다이어그램에 질문을합니다. "내포하는"관계는 실제로 많은 것으로 나타납니다. 앨범에 명확하게 많은 노래가 포함되어 있습니다. 그러나 주어진 노래는 하나 이상의 앨범에 나타날 수 있습니다. 따라서 "포함"을 "앨범"에 연결하는 선에 화살촉이 있어야합니다.

ER 모델에이 개정판을 적용하면 표 수가 4 개 (아티스트, 앨범, 노래 및 포함) 증가합니다.

아티스트 및 노래에 대해 비슷한 인수가있을 수 있습니다. 두 명의 아티스트가 하나의 노래 (예 : Dolly Parton 및 Kenny Rogers가 "Islands in the Stream"을 함께 노래하는 경우)를 사용하면 "다품종"을 다 대다 관계로 모델링 할 수 있습니다. 아티스트, 앨범, 노래, 포함 및 생성합니다.

연예인, 앨범, 노래가. 해당 개체를 식별하는 PK를 요구하려고하는 엔티티 무결성 엔티티 인스턴스와 테이블 행 bewteen 대응은 일대일 할 것을 요구한다.

Contains 및 Produces 테이블은 별도의 ID 속성없이 만들 수 있습니다. 각 테이블에 FK 쌍이 필요하며 두 개의 FK로 구성된 각 테이블에 대해 복합 PK를 선언 할 수 있습니다.

참조 무결성은 프로그램에서 또는 DB에서 참조 제약 조건을 선언하여 FK 참조의 유효성을 확인해야합니다. DB에서 제약 조건을 선언하는 것을 강력히 선호합니다.