【DB設計】データベース(DB設計)は概念設計から開始するのが基本
データベースを設計する際に、いくつかの段階を経て、設計することが必要です。 いきなり、最終形の設計ができるわけではありません。(業務などで慣れている方はできてしまうかも知れませんが頭のなかでは、順を追って組み立てていると思います。) データベーススペシャリスト試験にもこのような設計の要素は重要です。 むしろ、これが際たる形で求められるのが、データベーススペシャリストと言っても良いかも知れません。
設計の段階
設計の順序ですが、主に3つの設計を行っていきます。
- 概念設計
- 論理設計
- 物理設計
この順序で設計を行っていくことで、無理なく間違いない設計ができるようになるはずです。いろいろと知っている人は物理設計から実施しているようにみえることもあるかもしれませんが、頭の中では概念設計を思い描いたうえで、論理設計をしていると思います。
ここでは概念設計について解説していきます。
概念設計とは
業務要件をデータ構造観点で分析をして、概念設計モデルを作り上げることを概念設計を呼びます。概念設計モデルとは、対象をエンティティとリレーションの二つの概念にて、表したものです。概念設計におけるインプット、アウトプット、工程での実施内容をいかにまとめてみました。
項目 | 必要なこと |
---|---|
インプットとなる情報 | 業務要件、ユーザービュー |
概念設計で実施する内容 | エンティティタイプの作成、エンティティタイプのリレーションの作成 |
アウトプットする情報例 | ER図 |
概念設計で基本となる言葉の解説
エンティティタイプ
まず、エンティティとは日本語で実体です。業務で管理されている事象の集合体で、永続的なものがエンティティタイプと言われます。これだと難しいようにも思いますが、データベースでいうなら、テーブルに相当するものと思えば、わかりやすいかもしれません。
インスタンス
これもその時々によって意味合いが異なることがあるかと思いますが、データベーススペシャリスト試験においては、主に集合のことを指します。簡単に言うとレコードのことと認識できれば大丈夫かと思います。また、インスタンスは同じものはないとされます。必ずどこかの属性とは異なっており、一意に識別されるものになっています。
なお、その内容によって、次のような言葉で表されることがあるので、覚えておいたほうがよいかと思います。
- 経営資源(組織や人、物)はマスタ
- 業務事象(日々の業務)はトランザクション
属性
テーブルにおける列と同義と捉えられます。インスタンスが保持できる値の定義が属性です。インスタンスは属性の値を個別に保持しています。
キー
インスタンスを識別するための属性(または属性集合)エンティティタイプは一つ以上のキーを持ちます。(その中で主たるものを主キーと言います。)
多重度
インスタンスの関係をカーディナリティ、オプショナリティについてリレーションの端に記載したものです。
カーディナリティ
相手のインスタンスが一つ特定された場合に自分が対応するインスタンスの最大値を示します。表記は基本的に1か多の2種類で、2以上はまとめて多と記載するのが一般的です。
オプショナリティ
相手のインスタンスが一つ特定された場合に自分が対応するインスタンスの最小値を示します。表記は0か1の2種類で、0は任意を示し、1は必須を示します。