まだ、全部のデータがインポートされていませんが、現状の ER 図(属性は省略)は以下のような感じ。
先々週に示したように、STI で設計する Device には、Album(アルバム)、Single(シングル)、Video(ビデオ/LD/DVD)、Youtube(YouTube) という小クラスが存在しています。当時は CD だけでなく、カセットなどが併売されていたこともあり、 対多関連で Medium(媒体) というクラスを用意しています。今回、YouTube のために URI も書けるように拡張しています。また、カセットだけはカラオケが収録されていたりして、曲リストが異なることもあったため、SongList(曲リスト)も対多関連で用意しています。最近は、The Singles のように複数枚収録の CD もあるので、それにも対応できています。
SongList と Song(曲) は多対多の関連になるため、中間テーブルとして、SongListSong という中間クラスを用意しています。 SongList からは、 has_many:through という仕組みにより、直接 songs という曲一覧を取得することができます。ただし、今回は中間クラスに SongIndividual という Individual(個人)への関連を用意したので、直接 songs を使うことはありませんでした。SongIndividual は、収録曲と演奏者の関連を保つクラスで、個人と楽器への関連を持ちます。同じ曲でもアルバムが違えば演奏者が異なるので、 SongListSong への関連付けになりました。一方、作詞・作曲は曲に対して一意に確定するので、Song から SongLyricMusic という形で関連付けをしています。
Concert はツアーごとのくくり、ConcertHall が各公演のクラスになります。Concert からはバンドへの関連があり、バンドと個人・楽器の間に中間クラスであるBandIndividual クラスがあります。ConcertHall からは発売されたライブビデオのために、Device への関連を持ちます。実質、Video クラスへの関連だけです。コンサートのセットリスト用にクラスを用意しようと思いましたが、実質 SongList と機能があまり変わらないので、使い回しをします。ただし、SongList から Device へは一意の関連ですが、ConcertHall へは対他の関連になる(同じセットリストが複数の公演で演奏される)ため、ConcertHall 側に外部キーを持つ関連になります。ConcertHall は Hall への関連も持ちます．Hall は所在する Prefecture(都道府県)への関連を持ちます．
今回の設計にあたって，正規化処理を追加したものの大学の頃に作っていたデータ構造はほぼそのままでした．当時はあまりデータベースの知識はなかったものの，それなりに考えて作っていたんだと感心しました．
