Upgrade to Pro — share decks privately, control downloads, hide ads and more …

実践データベース設計サブ資料:➁論理データモデリング

Recruit
August 09, 2024

 実践データベース設計サブ資料:➁論理データモデリング

2024年度リクルート エンジニアコース新人研修の講義資料です

Recruit

August 09, 2024
Tweet

More Decks by Recruit

Other Decks in Technology

Transcript

  1. サブ資料②:論理データモデリング(R書店) 論理データモデルとは 概念データモデルで作成したエンティティに属性を定義していくことで業務要件上必要なデータと ビジネスルールを詳細に定義したモデル また、属性定義とともに、「正規化」と具体的なデータやその関係性を「抽象化」していくことに より、データ構造を確定していく 論理データモデルの作成手順 ・Step1 リソース系エンティティの抽出 ・Step2

    エンティティの定義と属性登録 ・Step3 リレーションシップの線を引く ・Step4 整合性の確認 ・Step5 正規化の確認 ・Step6 属性定義 ・Step7 ドメイン定義 ・Step8 データモデルパターン等を用いた抽象化 ・Step9 エンティティとリレーションの確定 ・Step10 サブジェクトエリアの確定 Step1 リソース系エンティティの抽出 業務ルールや概念データモデル等から、リソース系エンティティを抽出し、登録する 併せて、エンティティの概要を定義する 概念データモデル(『サブ資料①概念データモデリング』より)において定義された内容を見直す 形で、定義していく(概念データモデルで登録したエンティティを基本とし、追加もしくは削除し ていくイメージ) 1 ページ
  2. Step2 エンティティの定義と属性登録 詳細な業務フロー図や、画面・帳票概要定義書等から、リソース系とイベント系の両方のエンティ ティを抽出し登録する。また、併せて属性登録を行う。なお、 画面入力仕様→論理データ設計→画面・帳票出力仕様→論理データ設計という行き来を繰り返すこ とで、モデルの完成度を高めていく 上記のstep1及び詳細業務フロー図でリソース系エンティティを抽出したら、業務フロー上の マスター管理系画面と照合しながら、概要の定義を記述していく。トランザクション系画面から は、イベント系エンティティを抽出し登録する。概要定義も忘れずに行う。属性については、画面 設計から項目を洗い出し、エンティティに貼り付けていく。

    属性登録の詳細 属性登録について、もう少し詳細に作業を説明すると、まず、画面の入力項目をエンティティの属 性とするために、以下の作業を実施する ・エンティティの主キーとなる項目を設定する ・繰り返し項目のグループを別エンティティとして切り出していく ・主キーに対して従属する項目を、エンティティの属性として登録する ※エンティティに属性を定義する際には「第三正規形」を意識すること ※この段階では物理目的のものは定義しない(XXコード、更新日など)。 次に、画面上の出力項目を、エンティティの属性として登録していくが、このときの注意事項には 以下がある ・画面上の該当項目が、エンティティの属性として未登録の場合(または導出できない場合)、 リソース系エンティティに対しては、そのまま属性として登録・定義することができる ・イベント系エンティティの場合は、画面の入力仕様(業務フローの業務プロセス)から再検討す る ※画面の入力仕様を分析する順序は、業務フローの時系列発生順とする ※イベント系エンティティの検討も、同様に時系列発生順に行う ※単純に導出できない集計値や残高(加工データ)を画面上で更新している場合、エンティティと して管理することを検討するが、その場合、該当エンティティを登録し、併せて集計値や残高を属 性として登録する 主キーは、エンティティのインスタンスを一意に識別する値を持った、1つまたは複数の属 性のこと 主キーとは 「属性」とは各エンティティに格納される「項目」(フィールド)を意味する 例えば、「顧客エンティティ」の属性として「顧客名」や「顧客住所」等が考えられる 属性とは 2 ページ
  3. 第一正規化:繰り返しの排除 繰り返し属性を別エンティティに切り出す。 Step3 リレーションシップの線を引く ビジネスルール、概念データモデル等を参考にして、エンティティ間にリレーションシップの線を 引き、その線の意味を定義する(このときも、概念データモデルに登録済みのリレーションシップ を基本とし、追加・削除を行うイメージ) ※画面・帳票から、該当エンティティの属性項目と一緒に他のエンティティの属性項目も参照して いる場合、リレーションシップがつながっているかを確認し、必要があればリレーションシップの 線を引き、その線の意味を定義する

    Step4 整合性の確認 エンティティ関連図全体の整合性を確認する ・エンティティ間のリレーションシップ(従属関係、参照関係)を確認する ・汎化及び特化(汎化関係)を検討する(スーパータイプ、サブタイプ) Step5 正規化の確認 エンティティ間の正規化を確認する ・主キーが同一であるエンティティを統合していくが、その際、例外があり、依存型のリレーショ ンシップが存在し、親エンティティと子エンティティが1対0、または1対1の場合が該当。 リレーションシップ(の種類)では、この関係を「拡張関係にある」という場合がある ビジネス上の必要に迫られてリレーションシップの関係にある場合がほとんどだが、この場合、何 も考慮せずにエンティティを統合してはいけない ・同一エンティティ内の重複属性があれば、どちらか一方の属性を排除する ・キー以外の属性が複数エンティティに所属しているような場合、どちらかの属性を排除する ・導出項目を排除する 第一正規化から第三正規化まで 3 ページ
  4. 補足:システム要件の整理:ボトムアップアプローチでの確認 UIや画面遷移等からもしっかりとボトムアップ観点で設計をチェックする Step8 データモデルパターン等を用いた抽象化 データモデルパターン等のパターンやフレームワーク等を参照して抽象化する。 論理データモデルにおいては、抽象化を行う目的でデータモデルパターンを使用する。 例えば受注と発注の両方を扱うような場合、「受注」エンティティと「発注」エンティティを「取 引」エンティティに統合するか否かの検討に用いる等 Step9 エンティティとリレーションの確定

    今回の開発プロジェクトにおいて、管理対象となるエンティティ及びリレーションシップの登録と 意味定義を一旦確定する。 今後追加する際には、画面や帳票等への影響度を検討した上で反映させた後、論理データモデルへ 追加登録する Step10 サブジェクトエリアの確定 「概念データ設計」において分割したサブジェクトエリアの見直しを行う。 画面やUIを検討するうちに、必須項目として属性を登録したり、業務フローから新たなイベント系 エンティティの必要性が発覚したりする場合がある。そうした場合、あくまでビジネス上の観点か ら最適になるようサブジェクトエリアを見直す。そして、今回の開発プロジェクトで管理対象とな るサブジェクトエリアを一旦確定する (次ページへ続く) 6 ページ
  5. 顧客エンティティの設計 システムの運用上顧客のステータスを管理する必要が出てくることがある(不正にログインされた り、規約違反を起こす顧客も出てくるため、そうした顧客への対応等)※ボトムアップ・実装観点 たとえば管理用ユーザを追加する場合(その場合、ユーザ種別も追加)、またエンティティ名が顧客 (Customer)じゃない方がしっくりくるケースもある。一方で一般のカスタマだけに限定したい場合 は、"顧客"エンティティ、”顧客”テーブルにしても良いケースもある(仮にカスタマ以外のユーザが 含まれていても、ユーザ種別で除外して集計する等も可能) ・ログイン時の想定 → ログインID(もしくはユーザ名やEメールアドレス等)とパスワードが必要

    ・ユーザのステータス管理も必要 ・複数の種類のユーザが利用(顧客、運営側)する場合→ ユーザ種別必要 ・社内管理者も考慮する場合、R書店の顧客テーブルに含める以外に、R書店本体とは別でR書店を管 理するツール作成し、そのユーザ(顧客とは別テーブル)を管理者とするとR書店の顧客テーブルと 分けられる ・分析などの観点からは顧客と社内ユーザはテーブル分けた方が望ましいが、挙動の確認をしやすい ように特定のユーザに特権を与える場合もある(特定の条件下でないと見れないページの確認等)※ 但しセキュリティ上の考慮も必要 ER図 ステータス管理の必要性 顧客情報を扱うエンティティ ユーザの種別が増える場合の対応 その他必要な属性を考える 9 ページ
  6. 商品エンティティの設計 1. Single Table Inheritance Pattern 2. Class Table Inheritance

    Pattern 3. Concrete Table Inheritance Pattern 1. Single Table Inheritance Pattern 概要:属性を全て単一のテーブルに持たせるパターン Pros: 属性を単一のテーブル内で揃って保持することができるので、シンプルなうちは管理しやすい Cons: テーブルの属性が少ないうちは管理がしやすいが、特定の商品固有の属性が多くなると管理 がしづらくなる ※但し今回のR書店ではこちらを採用 設計方法のパターン 商品情報を扱うエンティティ 商品エンティティに関して、書籍以外の商品も取り扱う場合、エンティティを表現するのに複 数の方法がある 商品関連エンティティの設計 商品、商品在庫、出版社、著者の各エンティティ 単一のテーブルに全属性を持たせる 11 ページ
  7. 2. Class Table Inheritance Pattern 3. Concrete Table Inheritance Pattern

    概要:スーパークラス、サブクラス毎にそれぞれにテーブルを定義するパターン Pros: サブクラス毎に持つ固有の属性が多くなり、複雑になってくる場合、このパターンで管理がしやす い。Axxxzonや楽〇等の大規模ECサービスでは恐らく単一テーブルではなく、分けていると思われる Cons: ・サブクラス単位でモデルを作成すると、例えばユーザに見せる商品ページでも、単一のページで 全ての商品を表現しようとする場合、View(画面)の処理が分岐等で複雑になりやすいため、同じ 商品ページでも商品別にフォーマットを別々で用意する等の手間や工夫も必要になってくる場合が ある(ボトムアップ観点(実装観点)) ・サブクラス間で項目の矛盾が生じる等、アプリケーションの処理の設計に影響を与える可能性が ある ・各モデルの登録・更新処理が大変で、パフォーマンスや障害時の考慮も必要になる 概要:サブクラス毎にテーブルを作成するパターン Pros: 商品毎にテーブルが完全に独立するので各テーブルを個別で完結した管理ができる Cons: テーブルが分かれていると両者の共通項目の整合性が取れなくなるリスクがある 商品”種別”と”カテゴリ”の違い 商品種別はより厳密(商品と種類が1対1)で、カテゴリは同一商品でも複数のカテゴリにまたがる ※今回のR書店ではカテゴリは使用しないこととする 書籍以外の商品の考慮 書籍以外にCDやDVD等を扱う想定の場合は商品種別等の属性を持たせることになる スーパークラスとサブクラスごとにテーブルを作成 サブクラスのみテーブルを作成する 12 ページ
  8. 出版社エンティティ 書籍エンティティから切り離す 商品情報から切り出し 著者エンティティ 正規化で商品情報から切り離す 商品情報からの切り出し 店舗(カート)関連エンティティの設計 カート、カート内商品の各エンティティ ER図 著者情報を扱うエンティティ

    出版社情報を扱うエンティティ ER図 姓と名の間に・が付いたり、空白で氏名を分けたり、どちらかが欠けているケース(ペンネーム 等)もあるため、今回著者テーブルでは氏名は分けずに1つのカラムで管理する 著者氏名について(ボトムアップ観点) 14 ページ
  9. カートエンティティの設計 商品を追加する"ショッピングカート"を扱うエンティティ 未登録ユーザへの配慮 今回は購入を促すため、カートは顧客がユーザ登録前の未登録状態で追加可能ものとする そのためユーザとカートを直接結び付ける以外に、他の値とも結びつけることとする(ボトムアッ プ・実装観点) ER図 実現方法(一案) 今回は未登録ユーザ(未登録の顧客)のCookieに値を仕込んで、サーバ側で突き合わせる セッションとCookieの違い

    Cookieはユーザのブラウザに保存(正確にはローカルのファイルに保存)される値で、セッションは Cookieを利用してサーバ側で特定のユーザを認識するための仕組み Cookieセットのタイミング Cookieのセットは来訪したユーザ全員に付与していると、管理コストが膨大になるため、例えばカー トボタンを押した際に付与する等見込みのあるユーザに絞る等の考慮が必要 今回の想定フロー 今回の想定フローは以下 15 ページ