区分を整理する
Traditionalなデータベース設計を行う上でいわゆる区分と呼ばれるものがあるわけだが、ひとえに区分といっても一概に言えないのかもしれないなどと考えるにつれ、とりあえず整理してみるのが良いんじゃないかと思い始めた。
というわけで、とりあえず作ってみたのがこれ。
- 種類(type)：性質に従って分けること。変化しない。
- 分類(category)：基準に従って似たものどうしにまとめて分けること。中長期的には変化する。
- 継承(class)：性質に従って体系付けること(is-a)。変化しない。
- 属性(attribute)：所有する性質(has-a)。変化しない。
- 状態(state)：現在の状態。短期間で動的に変化する。
うーむ、微妙だ。英単語本来の意味で言えばclassは継承関係を表すものというよりは階級を表すものらしいのだが、ここではプログラミング言語的な解釈によった（おそらくclassificationに由来するのだろう。classificationは必ずしも階級を意味しない）。
こうして見ると、まず変化するかしないかで、大きく三つに分けられるわけだ（なお、ここでは間違ったので変更する場合は無視している）。それぞれの特徴を書いてみるとこうなる。
- 変化しない：種類や属性、継承関係のように性質を基礎としている
- 中長期的には変化する：政策的に利用しやすいよう外側から設定されている
- 短期間で動的に変化する：時系列的な情報である
三番目はBuriの出番なので議論の余地なし。二番目は外側から設定されている＝そのインスタンスそのものの情報ではないわけだから、外部テーブル化して交差エンティティで接続するのが正しい姿だろう。
あとは一番目だが、一番目の中でも先天的なものと後天的なものがありそうだ。継承関係はそのものが先天的だし多重継承もありえるからサブセットにするのが適当。逆に種類は後天的だし定義からして分割しているわけだから重なることはありえないので区分が適切なわけだ。
では、属性はと言えば、これがなかなか難しい。基本的には区分でよいはずだけど、場合によっては複数発生する可能性がある。OracleとかだとArray型があるのでそれを利用するのが一番きれいだけどDBMSによってはできない場合がある。じゃあ交差エンティティかということになるが、1個と複数の場合でデータベースの設計内容に影響が出るのがいまいちだ。それとも全部個別のフラグにしてしまうか（ただ、そうするとコンボボックスのデータをセットするのが面倒だ）。なんとなく、Array型が使えないDBMSは使わないのがいいんじゃなかろうか、とか思ったが今の実装状況はどんな感じなんだろう。
