はじめに
[Discogs]は音楽に関するデータベース＋マーケットプレイスサイトで、主にクラブDJやレコードコレクターがお目当てのレコードを掘るために構築された。これゆえ、クラブDJやレコードコレクターがレコードを掘る時のメンタルモデルを忠実にデータベースに落とし込んだと言える（創立者はプログラマー兼DJ）。
[Discogs]:https://www.discogs.com/
ユースケース
ざっと思いつく限り以下のユースケースがあげられる。
- レーベルの発表トラックを軸にレコードを掘る。
- 楽曲の別バージョンを軸に掘る。
- 楽曲に関わっているミュージシャンを軸にレコードを掘る。
- 楽曲に関わるコンピレーションを軸にレコードを掘る。
- アーティストの変名からレコードを掘る。
クラス図
[Rest API仕様]を元にクラス図として表現したものを示す。
- レコードにReleaseという概念を導入して表現している。また、一番最初に販売されたのをmain release、そこから各レーベルにライセンスされたり、CD等、別フォーマットで販売されたのをvariationsとして管理している。これにより、各音源の微妙な違いを表現している。
- Artistは集団とメンバーに分かれている。おそらく、集団としての活動とメンバーソロとしての活動を補足するためである。
- ArtistとReleaseはRoleを介して紐づいている。これは楽曲制作として関わったのか、リミキサーとして関わったのか、プロデューサーとして関わったのかを補足するためである。
- LabelはEntity Typeを介してReleaseと紐づいている。これはレーベルが著作権管理を行っているのか、販売を行っているのか、制作に関わっているのか明確するためである。また、companyというロール名でプレス会社まで補足できるようにしている。
- Genreの階層化は行ってなく、その下にStlyeという概念を持ち込んで細分化をおこなっている。おそらくジャンルの階層化を行うと混乱するため？
- クラブDJ(=ドメインエキスパート)では当たり前だが、GenreとReleaseは多対一で紐づいている。理由はジャンルはある視点でまとめたものに過ぎないため複数の解釈が存在するからである。
[Rest API仕様]:https://www.discogs.com/developers#page:database,header:database-release)
オブジェクト図
前述の説明を基にMiguel Migs – Take Me To Paradiseをオブジェクト図として表現したものを示す。クラブDJ/レコードコレクターがレコードを掘る時にはこのメンタルモデルを頭に浮かべている。
まとめ
- Release/Master Releaseという概念を持ち込んで、別バージョンやCDバージョン、ローカライズ等と上手にまとめ上げている(ここ重要)。
- 全体的に普通の楽曲管理をより詳細化している。
- 音源とレーベル/制作/プレス会社の関連を上手に表現している。
参考文献/スライド
[オブジェクト指向方法序説基盤編 - ジェームズ-マーチン] (https://www.amazon.co.jp/dp/4810185923/)
[モデルとプロセスをめぐる冒険 - 橋本 隆成] (https://www.amazon.co.jp/dp/4798110558/)
業務別データベース設計のためのデータモデリング入門
ストリームラインオブジェクトモデリング
アナリシスパターン―再利用可能なオブジェクトモデル
[UMLモデリングレッスン]
(https://www.amazon.co.jp/dp/4822283496)