SQL MORE 에 나온 음원 판매 사이트의 스키마를 구현해보자.
필요한 TABLE
: tracks, playlists, invoices, customers, employees, albums, artists, genres, media_types...
TABLE 구현,
tracks TABLE.
TABLE tracks를 구성하게될 각각의 칼럼들이다.
이제 각각의 칼럼들의 관계를 구현해 주어야한다.
각 칼럼들의 relation Id를 설정하기 전에
각 테이블 레코드간의 관계들을 먼저 정립해보자.
tracks에 칼럼들 중에서, 다른 테이블의 레코드를 참조 해야하는 레코드는
Album, MeidaType, GENRE가 되겠다.
하나의 track 에 Album이 많을 수 없고, 하나의 track에 MediaType이 많을 수 없으며, 하나의 track에 Genre가 다양할 수 없기 때문에 그렇다.
Name, Composer, Milliseconds, Bytes, Price는 TrackId 칼럼에 대한 고유한 값이기 때문에, 관계를 설정 할 필요가 없음. 그러면 이 칼럼들을 제외한 나머지엔 Id 값을 설정을 해주어, 다른 테이블의 레코드와 관계를 설정해준다.
tracks 칼럼들에 관계가 필요한 레코드를 visualization 해보았고, playlist 와 invoices, customers, employees TABLE 을 만들어보자. 기본적으로 음원 판매 사이트니, invoices 를 받는 customer와 보내는 employees들이 있어야하고, playlist 또한 음원 판매 사이트에 존재하기 때문에 TABLE 설정을 해주어야한다.
위 그림과 같이 각 table들의 칼럼들을 설정해 주었고, 칼럼들의 레코드들의 관계를 설정해 주어야 한다.
주목해야할 점은 관계의 정립이다.
playlist는 하나의 플레이 리스트에서 여러개의 Tracks를 포함 할 수 있고, 하나의 tracks 또한 여러개의 playlist에 포함될 수 있다. N:N 관계
invoices또한 하나의 tracks에서 여러개의 invoices가 발생할 수 있고, 하나의 Invoics에서 여러개의 tracks를 포함시킬 수 있다. N:N 관계
N:N 관게는 JOIN TABLE 을 따로 만들어 줘야한다. playlist_track, invoice_track 이름의 TABLE
한명의 Customers가 여러개의 invoices를 받을 순 있지만, invoices의 칼럼들의 내용이 같은 여러명의 customers은 존재할 수없다. 1:N 관계
한명의 Customer가 여러명의 employees에게 도움을 받을 수 없고, 한명의 employee가 여러명의 Customer을 도와줄 수 있다. 1:N관계
그러면 각 레코드들의 관계에 맞게 칼럼들을 이어주면
이런식으로 음원을 판매하는 사이트의 스키마를 작성 할 수 있다.
