サブ資料②：論理データモデリング（R書店） 論理データモデルとは 概念データモデルで作成したエンティティに属性を定義していくことで業務要件上必要なデータと ビジネスルールを詳細に定義したモデル また、属性定義とともに、「正規化」と具体的なデータやその関係性を「抽象化」していくことに より、データ構造を確定していく 論理データモデルの作成手順 ・Step1 リソース系エンティティの抽出 ・Step2 エンティティの定義と属性登録 ・Step3 リレーションシップの線を引く ・Step4 整合性の確認 ・Step5 正規化の確認 ・Step6 属性定義 ・Step7 ドメイン定義 ・Step8 データモデルパターン等を用いた抽象化 ・Step9 エンティティとリレーションの確定 ・Step10 サブジェクトエリアの確定 Step1 リソース系エンティティの抽出 業務ルールや概念データモデル等から、リソース系エンティティを抽出し、登録する 併せて、エンティティの概要を定義する 概念データモデル（『サブ資料①概念データモデリング』より）において定義された内容を見直す 形で、定義していく（概念データモデルで登録したエンティティを基本とし、追加もしくは削除し ていくイメージ） 1 ページ

Step2 エンティティの定義と属性登録 詳細な業務フロー図や、画面・帳票概要定義書等から、リソース系とイベント系の両方のエンティ ティを抽出し登録する。また、併せて属性登録を行う。なお、 画面入力仕様→論理データ設計→画面・帳票出力仕様→論理データ設計という行き来を繰り返すこ とで、モデルの完成度を高めていく 上記のstep1及び詳細業務フロー図でリソース系エンティティを抽出したら、業務フロー上の マスター管理系画面と照合しながら、概要の定義を記述していく。トランザクション系画面から は、イベント系エンティティを抽出し登録する。概要定義も忘れずに行う。属性については、画面 設計から項目を洗い出し、エンティティに貼り付けていく。 属性登録の詳細 属性登録について、もう少し詳細に作業を説明すると、まず、画面の入力項目をエンティティの属 性とするために、以下の作業を実施する ・エンティティの主キーとなる項目を設定する ・繰り返し項目のグループを別エンティティとして切り出していく ・主キーに対して従属する項目を、エンティティの属性として登録する ※エンティティに属性を定義する際には「第三正規形」を意識すること ※この段階では物理目的のものは定義しない（XXコード、更新日など）。 次に、画面上の出力項目を、エンティティの属性として登録していくが、このときの注意事項には 以下がある ・画面上の該当項目が、エンティティの属性として未登録の場合（または導出できない場合）、 リソース系エンティティに対しては、そのまま属性として登録・定義することができる ・イベント系エンティティの場合は、画面の入力仕様（業務フローの業務プロセス）から再検討す る ※画面の入力仕様を分析する順序は、業務フローの時系列発生順とする ※イベント系エンティティの検討も、同様に時系列発生順に行う ※単純に導出できない集計値や残高（加工データ）を画面上で更新している場合、エンティティと して管理することを検討するが、その場合、該当エンティティを登録し、併せて集計値や残高を属 性として登録する 主キーは、エンティティのインスタンスを一意に識別する値を持った、1つまたは複数の属 性のこと 主キーとは 「属性」とは各エンティティに格納される「項目」（フィールド）を意味する 例えば、「顧客エンティティ」の属性として「顧客名」や「顧客住所」等が考えられる 属性とは 2 ページ

第一正規化：繰り返しの排除 繰り返し属性を別エンティティに切り出す。 Step3 リレーションシップの線を引く ビジネスルール、概念データモデル等を参考にして、エンティティ間にリレーションシップの線を 引き、その線の意味を定義する（このときも、概念データモデルに登録済みのリレーションシップ を基本とし、追加・削除を行うイメージ） ※画面・帳票から、該当エンティティの属性項目と一緒に他のエンティティの属性項目も参照して いる場合、リレーションシップがつながっているかを確認し、必要があればリレーションシップの 線を引き、その線の意味を定義する Step4 整合性の確認 エンティティ関連図全体の整合性を確認する ・エンティティ間のリレーションシップ（従属関係、参照関係）を確認する ・汎化及び特化（汎化関係）を検討する（スーパータイプ、サブタイプ） Step5 正規化の確認 エンティティ間の正規化を確認する ・主キーが同一であるエンティティを統合していくが、その際、例外があり、依存型のリレーショ ンシップが存在し、親エンティティと子エンティティが1対0、または1対1の場合が該当。 リレーションシップ（の種類）では、この関係を「拡張関係にある」という場合がある ビジネス上の必要に迫られてリレーションシップの関係にある場合がほとんどだが、この場合、何 も考慮せずにエンティティを統合してはいけない ・同一エンティティ内の重複属性があれば、どちらか一方の属性を排除する ・キー以外の属性が複数エンティティに所属しているような場合、どちらかの属性を排除する ・導出項目を排除する 第一正規化から第三正規化まで 3 ページ

第二正規化：部分従属の排除 主キーの一部に従属する属性を別エンティティに切り出す 第三正規化：推移従属の排除 主キーに従属しない属性を、別エンティティに切り出す 正規化：顧客エンティティ （次ページへ続く） 4 ページ

Step7 ドメイン定義 データ項目の共通的な性質を抽出し、ドメイン（ドメイン駆動設計の"ドメイン"とは異なる）とし て登録するが、その際に忘れずにドメイン自体の意味の定義を行うこと。併せて「コンディション 定義」を行う。 コンディション定義とは、値の意味を定義したり、値のとりうる範囲を具体的に明示すること。 例えば、最大値や最小値を規定したり、「1:見積中」、「2:受注」といった意味内容を定義する。 そして定義したドメインを各属性に再度割り当てていく。 例えば、属性「試験年月日」にドメイン「入学年月日」を割り当てる、といった具合 Step6 属性定義 属性の定義を行う ・説明（意味）を定義し、文章で記述する ・データの桁数、正式名称、編集形式等を定義する ・エンティティ名称、エンティティ属性名称の標準化作業を実施する 正規化：商品エンティティ 5 ページ

補足：システム要件の整理：ボトムアップアプローチでの確認 UIや画面遷移等からもしっかりとボトムアップ観点で設計をチェックする Step8 データモデルパターン等を用いた抽象化 データモデルパターン等のパターンやフレームワーク等を参照して抽象化する。 論理データモデルにおいては、抽象化を行う目的でデータモデルパターンを使用する。 例えば受注と発注の両方を扱うような場合、「受注」エンティティと「発注」エンティティを「取 引」エンティティに統合するか否かの検討に用いる等 Step9 エンティティとリレーションの確定 今回の開発プロジェクトにおいて、管理対象となるエンティティ及びリレーションシップの登録と 意味定義を一旦確定する。 今後追加する際には、画面や帳票等への影響度を検討した上で反映させた後、論理データモデルへ 追加登録する Step10 サブジェクトエリアの確定 「概念データ設計」において分割したサブジェクトエリアの見直しを行う。 画面やUIを検討するうちに、必須項目として属性を登録したり、業務フローから新たなイベント系 エンティティの必要性が発覚したりする場合がある。そうした場合、あくまでビジネス上の観点か ら最適になるようサブジェクトエリアを見直す。そして、今回の開発プロジェクトで管理対象とな るサブジェクトエリアを一旦確定する （次ページへ続く） 6 ページ

R書店の画面の一部（詳細はFigmaを参照） 補足：中間テーブルについて オブジェクトで構成されるアプリケーションの世界と行と列のデータベースの世界とのギャップを埋 める必要がある 「多対多」と関連エンティティ 多対多の問題への対応方法 例えば注文と商品の多対多の関係を概念モデルではそのまま表現できるのに対し、論理モデル（リ レーショナル・モデル）では両者のエンティティが共通のキーを持たないため、両エンティティを直 接結合した情報を得ることができない（→ インピーダンスミスマッチ） 注文 商品 多対多 概念データモデル 先ほどの注文と商品の多対多の問題へは中間テーブル（注文商品テーブル）で対応する （次ページへ続く） 7 ページ

論理データモデルの全体像（E-R図） 今回の論理データモデルのER図（詳細はFigmaを参照） 顧客関連エンティティの設計 顧客エンティティと住所エンティティ 中間テーブル（注文商品） 8 ページ

顧客エンティティの設計 システムの運用上顧客のステータスを管理する必要が出てくることがある（不正にログインされた り、規約違反を起こす顧客も出てくるため、そうした顧客への対応等）※ボトムアップ・実装観点 たとえば管理用ユーザを追加する場合（その場合、ユーザ種別も追加）、またエンティティ名が顧客 （Customer）じゃない方がしっくりくるケースもある。一方で一般のカスタマだけに限定したい場合 は、"顧客"エンティティ、”顧客”テーブルにしても良いケースもある（仮にカスタマ以外のユーザが 含まれていても、ユーザ種別で除外して集計する等も可能） ・ログイン時の想定 → ログインID（もしくはユーザ名やEメールアドレス等）とパスワードが必要 ・ユーザのステータス管理も必要 ・複数の種類のユーザが利用（顧客、運営側）する場合→ ユーザ種別必要 ・社内管理者も考慮する場合、R書店の顧客テーブルに含める以外に、R書店本体とは別でR書店を管 理するツール作成し、そのユーザ（顧客とは別テーブル）を管理者とするとR書店の顧客テーブルと 分けられる ・分析などの観点からは顧客と社内ユーザはテーブル分けた方が望ましいが、挙動の確認をしやすい ように特定のユーザに特権を与える場合もある（特定の条件下でないと見れないページの確認等）※ 但しセキュリティ上の考慮も必要 ER図 ステータス管理の必要性 顧客情報を扱うエンティティ ユーザの種別が増える場合の対応 その他必要な属性を考える 9 ページ

住所エンティティの設計 顧客の住所を管理するエンティティ（複数登録可にする） 宛名の変更可能性を考慮する場合 都道府県エンティティの設計 【ボトムアップ視点】レコード数が47で固定であり、コード上で管理可能な範囲であるため、今回 実装上はDBではなく列挙型（Enum）で管理することする 実装視点での考慮 基本顧客IDで顧客と紐づくが、ギフト等、顧客自身以外の住所へも配送できるようにする場合、宛名の氏名 カラムも追加する（ボトムアップ観点） 住所の中の都道府県のデータを保持したエンティティ ER図 ER図 10 ページ

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

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

商品在庫エンティティ（従属エンティティ） 在庫は物理的な情報を扱うため、商品情報から切り離すのが望ましい 商品情報と在庫情報の区別 商品情報の中に在庫情報を含める場合 但し、商品情報と在庫情報のテーブル結合によるパフォーマンスへの影響を考慮する場合もある 商品情報と在庫が混在してしまうが、カラムが比較的少ない小さなサービスであれば選択する場合 もある 商品IDに関する考慮 システムで管理する商品IDをそのまま出すのは基本NG。商品番号や代替ID使うことも考慮する必要 がある（ボトムアップ観点） その他考慮 画面表示用にISBN番号も追加（ボトムアップ観点） 物理的な商品在庫を扱うエンティティ ER図 ER図 13 ページ

出版社エンティティ 書籍エンティティから切り離す 商品情報から切り出し 著者エンティティ 正規化で商品情報から切り離す 商品情報からの切り出し 店舗（カート）関連エンティティの設計 カート、カート内商品の各エンティティ ER図 著者情報を扱うエンティティ 出版社情報を扱うエンティティ ER図 姓と名の間に・が付いたり、空白で氏名を分けたり、どちらかが欠けているケース（ペンネーム 等）もあるため、今回著者テーブルでは氏名は分けずに1つのカラムで管理する 著者氏名について（ボトムアップ観点） 14 ページ

カートエンティティの設計 商品を追加する"ショッピングカート"を扱うエンティティ 未登録ユーザへの配慮 今回は購入を促すため、カートは顧客がユーザ登録前の未登録状態で追加可能ものとする そのためユーザとカートを直接結び付ける以外に、他の値とも結びつけることとする（ボトムアッ プ・実装観点） ER図 実現方法（一案） 今回は未登録ユーザ（未登録の顧客）のCookieに値を仕込んで、サーバ側で突き合わせる セッションとCookieの違い Cookieはユーザのブラウザに保存（正確にはローカルのファイルに保存）される値で、セッションは Cookieを利用してサーバ側で特定のユーザを認識するための仕組み Cookieセットのタイミング Cookieのセットは来訪したユーザ全員に付与していると、管理コストが膨大になるため、例えばカー トボタンを押した際に付与する等見込みのあるユーザに絞る等の考慮が必要 今回の想定フロー 今回の想定フローは以下 15 ページ

カート内商品エンティティの設計 カートと商品を結び付けるためのエンティティ（※中間テーブル） ER図 カート内Cookieデータエンティティの設計 上記のユーザのCookieとカートを結びつけるためのテーブル 管理用に最終アクセス日時や有効期限も追加 ER図 16 ページ

注文関連エンティティの設計 注文、注文商品の各エンティティ 注文エンティティの設計 注文情報を扱うエンティティ 主キーは注文IDだが、システム管理用のIDとは別に外部への表示用に「注文番号」を設けた（ボトム アップ観点） 注文商品エンティティの設計 注文した個々の商品を表すエンティティ 主キーは注文IDと商品IDの複合キーで設定 ※注文詳細や注文明細とするケースも多いが、個々の商品に結びつく中間テーブルのため、今回は注 文商品とした ER図 ER図 17 ページ

決済エンティティの設計 注意点 R書店内の決済情報とともに、決済代行会社のゲートウェイからレスポンスも本来保存するのが望 ましいが今回は便宜上省略した 金融系システムはトレーサービリティ確保やレギュレーションの一環として、保存していることが 多い 引用元：https://www.gmo-pg.com/blog/articles/images/article-096_thumb07.jpg 決済情報を表すエンティティ 決済関連エンティティの設計 決済、クレジットカードの各エンティティ ER図 （次ページへ続く） 18 ページ

配送（情報）エンティティの設計 配送情報に該当するエンティティ 注文情報と紐づいた配送（情報）エンティティを作成する（ここではで配送会社エンティティとリ レーションを貼る） なお、概念データモデリングで記した通り、今回は出荷（Shipping）情報を配送情報に含める （次ページへ続く） 決済のステータス管理 オーソリと与信チェック等、クジレットカード会社や決済代行会社の外部システムに依存する形で 決済の状況が変化するため、管理する仕組みが必要 今回はオーソリの情報も決済モデルに含める（ステータスで管理）かたちとする クレジットカードエンティティの設計 顧客のクレジットカード情報に該当するエンティティ カード選択画面で表示させるために、クレジットカードブランドも追加（ボトムアップ観点） 配送関連エンティティの設計 配送（情報）、配送会社の各エンティティ ER図 19 ページ

配送会社エンティティ 配送会社を管理するエンティティ ※今回は住所や連絡先等は省略 ER図 ER図 20 ページ