本日はER図のうち、リレーションの基本について書く。
概念データモデルについて
- 現実のデータをカンタンに表現したもの。データベースの種類や製品に依存しない。
- 試験の表記ルールは慣れておく。大きくはエンティティタイプとリレーション、スーパタイプとサブタイプ。
- ER図はエンティティ（テーブル）のリレーション（関係）。試験ではエンティティを「エンティティタイプ」と呼ぶが同じ意味。なお「インスタンス」はテーブルの要素と理解しておく。
リレーションの基本
- リレーションは1:1か1:多。1:1は両エンティティを直線で結ぶ。例は「見積●－○契約」など。契約側が○（０もあり得る）なのは、見積してすぐ契約するわけではない（タイムラグがある）のと、そもそも契約が成立しないかもしれないので。
- 最も数が多く基本なのは1:多。1:多は→で結ぶ（千鳥足の先が逆さになるイメージ）。例は「部署●→○社員」（社員は部署に属す。部署のうち社員がいないところもある）や、「受注●→●受注明細」（互いが存在しないと意味をなさない）など。なお、矢印は主キーから外部キーへ、と覚えると便利
- 多:多は通常ない。例えば「注文⇔商品」のように「一つの注文で複数の商品が発注できる。一つの商品は複数の注文で発注される。」という現実世界ではよくあるパターン。しかしこれを「注文テーブル（注文№、商品一つ目№、商品二つ目№…）」と管理すると商品が一つしかない時ムダ。こんなときは「注文→注文明細←商品」と1:多に変換する。この場合の「注文明細」を連関エンティティと呼ぶ（注文明細№（PK）、注文№（FK）、商品№（FK））。また、この場合の「注文」を強エンティティ、「注文明細」を弱エンティティとも言う。（注文がなければ注文明細は生まれないので）
中継ぎ
- ER図は現実の鏡像かつ基本の積み重ね。今後、一見複雑そうなパターンが増えるが、よく業務の流れを見て、一つ一つ解きほぐせば読解できる（そもそも簡単に整理するためのものなので）
- リレーションのその他パターン。自己参照（ソフト○→○ソフト。例えば人気ソフトシリーズでオリジナルを管理するなど。「ソフト№（PK）、ソフト名、オリジナルソフト№」とか。）、複数リレーション（品目（品目コード（PK）、品目名）と品目構成（親品目コード（PK）、子品目コード（PK）、必要数）など。）
- 次はスーパタイプとサブタイプ。大まかにはスーパクラスとサブクラスのイメージ。複数のエンティティ（テーブル）に共通する要素を抽出して、より上位の抽象概念として整理するイメージだろう。例えば「料理」をスーパタイプ、「単品」「単品立食」「コース」「セット」をサブタイプにする場合。「料理」はかなり上位の抽象概念だが、それ一つでテーブル管理するにはレストランでは困難だろう。なぜなら、例えば「コース」なら「どんな組み合わせで」の管理がいるが、「料理」テーブル１つだとこれは推移関数従属になるからだ。このようにスーパタイプとサブタイプは「現実世界の抽象概念を、業務の都合にあわせてもう少しわけたい場合」には非常に都合のよい考え方だとわかる。
考察
- ここまでの基本を公衆衛生などとどう結びつけるべきだろう。そもそも学びは何らか社会の役に立てるものだ。
- 例えば目の前の大量のデータが詰まったテーブルがある。この中には大量の相関があり、管理が一苦労だ。そこで「テーブルは集合であり関数」と「リレーションの基本は1:1か1:多」を使いテーブルを分け、ER図を書けば美しいテーブル群と一目で見やすい関係図が作れる。
- 業務を改善するときも、個人でデータを使い分析するときも、「センスのよいテーブル」は作業効率性の肝になるだろう。それは「頭を使ってより多くの命を救う」の土台になりそうだ。
- まとめると。データを使って分析するとき、長い目で見るなら必要なデータの整理・蓄積が必要だ。そのとき、データを意味のあるまとまり（テーブル）にまとめ、それらの関係を図で整理する「概念データモデル」の基礎を体得していれば、作業効率性は格段に良くなるだろう。
- データベーススペシャリストの試験は主に企業の業務改善にかかわるものだが、それら具体例が実務にそのまま役立つことも期待できる。また、それらを通じて「データベース設計・活用のセンス」という抽象概念を磨くことで、色々と応用が可能になるだろう。
参考書籍
- データベーススペシャリスト2022年版/三好康之/翔泳社 ※この記事は2章P202-P216を整理したもの
コメント