blog.waterlow.work

Ruby, Rails, js, etc...

【DB設計】T字型ER入門

目的

T字型ER手法を勉強することになったので、概略とまとめ

データベース設計論 T字形ER―関係モデルとオジブェクト指向の統合をめざして

データベース設計論 T字形ER―関係モデルとオジブェクト指向の統合をめざして

設計の、特にデータベース設計について勉強しようと考えていた時にT字型ERというワードにたどり着きました。
前からデータベース設計の手順、手法についてはいろいろ模索してはいたのですが、あんまり体型だった手法がわからなかったので一度勉強してみることに。
概略と、現時点での思うことについてまとめます。

T字型ER手法とはなにか

データ正規形を作りながら、同時に、事業過程を分析して、かつ、プログラムのアルゴリズムを「I/O化」する技術。らしい。
mah_labさんのブログによると、Railsのテーブル設計と相性がいい、とのこと。 blog.mah-lab.com 以下のブログでは2000年ごろSIの一部で流行った、とされている。 ozamasa.hatenablog.jp

T字型ER手法の体型

以下のような体型で構成されている。

  1. エンティティを作る規準を示す
  2. エンティティを2つのクラス概念に分類する
  3. リレーションを作る規準を示す
  4. エンティティが正しい集合になっているかどうか、検証する
  5. 「多値のOR関係」と「多値のAND関係」を扱う規準を示す
  6. 「みなしエンティティ」と「概念的スーパーセット」を作る規準をしめす

これは追々記事でまとめていきましょう

最大の特徴

「関係」のモデリングのしかたに重きを置いているようです。R:リソース系、E:イベント系とすると、E-E,E-R,R-R,そして再帰的な関係と、それぞれのパターンに応じてどうテーブルを作っていけばいいのか細かに記載されています。
テーブル設計にまよったときに、やり過ぎにはなるかもしれないけれどとりあえず間違いではないテーブル設計ができるかもなとは思いました。

やり過ぎ禁物

カラムではなくテーブルで表現するというのは、時に複雑さを招いてしまうかもしれません。
例えば「都道府県」と「エリア(関東とか関西とか」というテーブルがあったとして、よくやるのは都道府県レコードにエリアidをもたせるのですが、この手法に従うと、「都道府県エリア関連テーブル」を作ってそこで関係を表す事になりそうです。(ER図書きたい)
これは、リソースの変更と関係の変更が区別できるため、関連の変更が多いテーブル(例えば会社組織とか)にかんしては有効かも知れませんが、そうでないケースもあるかなと思いました。
もう少し読んでみて、適切な場面で使っていければと思います。

まとめ

まだ全然読み切れていないのですが、T字型ER手法の現時点でのまとめでした。
しっかり理解して適切な場面で使いたいです。