やさしくデータモデル解説

やさしくデータモデル解説 全ての人がデータを知る指針として copy right ©2024 Shintaro Fujimoto all rights reserved.

目次  データモデルの概要  データモデルとは何か?  データモデルを作成する意義  データモデルの構成要素  エンティティ  属性  リレーションシップ  キー  データモデルの実践!  正規化 copy right ©2024 Shintaro Fujimoto all rights reserved.

データモデルの概要 copy right ©2024 Shintaro Fujimoto all rights reserved.

データモデルとは何か? データモデルとは情報という地形における地図である copy right ©2024 Shintaro Fujimoto all rights reserved.

データモデルとは何か?  そもそも地図とは、複雑な地形を簡素な絵で描き表し、自分の居場所や目的地までの 道のりなどを把握するために利用する。 ○○ 病院 目的地 XX 駐車場 AA コンビニ 現在地 copy right ©2024 Shintaro Fujimoto all rights reserved. YY デパート

データモデルとは何か?  データモデルも同じように、企業内の情報やデータの地形を簡素な絵で表し、 現在自分たちが持つ情報（現在地）を把握し、将来どういった形で管理すると良いか （目的地）を表現できる。 copy right ©2024 Shintaro Fujimoto all rights reserved.

データモデルとは何か?  データモデルも同じように、企業内の情報やデータの地形を簡素な絵で表し、 現在自分たちが持つ情報（現在地）を把握し、将来どういった形で管理すると良いか （目的地）を表現できる。 データモデルを作成している企業は少ない。 自分たちの情報やデータを知らずして、 どうやってDXを実現できるのか? copy right ©2024 Shintaro Fujimoto all rights reserved.

補足:データモデルを体感してみよう!  あなたは居酒屋のオーナーです。 あなたのお店では、以下のようなドリンクメニューを揃えています。 copy right ©2024 Shintaro Fujimoto all rights reserved.

補足:データモデルを体感してみよう!  このメニューを基に、ドリンクが注文される場合、以下のような情報の分類に分けられます。 実際にお客さまに提供するもの →商品 商品を意味的に整理し、まとめたもの →商品分類 メニューからお客さまが商品を注文した結果 →注文 copy right ©2024 Shintaro Fujimoto all rights reserved.

補足:データモデルを体感してみよう!  分類分けしたそれぞれの情報の関係性をまとめると、以下のように表せます。 商品分類 copy right ©2024 Shintaro Fujimoto all rights reserved. 例）ハイボール 商品 例） ハイボール -ハイボール レモンハイボール -ハイボール 注文 例） レモンハイボール 2杯 XXX円 ジョッキ生 2杯 YYY円 レモンハイボール 1杯 ZZZ円

補足:データモデルを体感してみよう!  分類分けしたそれぞれの情報の関係性をまとめると、以下のように表せます。 商品分類 例）ハイボール 情報を細かく分解し、情報が持つ意味や情報間の 例） ハイボール -ハイボール 商品 関係性を表すのがデータモデルである! レモンハイボール -ハイボール 詳しくは後半で! 注文 copy right ©2024 Shintaro Fujimoto all rights reserved. 例） レモンハイボール 2杯 XXX円 ジョッキ生 2杯 YYY円 レモンハイボール 1杯 ZZZ円

データモデルを作成する意義  大きく以下3つが挙げられる。 ① コミュニケーションの向上 ② 現状理解の精度向上 ③ DX化貢献 copy right ©2024 Shintaro Fujimoto all rights reserved.

①コミュニケーションの向上  一見同じような言葉でも、部署や部門ごとに別の意味で捉えられていることがある。 • 例）取引先 A部門（取引先テーブル） 取引先CD 取引先名 住所 001 AA商事 東京都千代田区・・・ 002 BB重工 神奈川県横浜市・・・ 003 CC株式会社 東京都文京区・・・ B部門（取引先テーブル） 取引先CD 取引先名 住所 0001 DD自動車〇〇支 店 東京都品川区・・・ 0002 EE産業XX支社 東京都港区・・・ 0003 FF株式会社ZZ支 店 東京都千代田区・・・ 同じ“取引先”でも、部署や部門によって法人レベルの“取引先“を指すのか、 その下の支店や支社レベルを指すのかが違う。等 copy right ©2024 Shintaro Fujimoto all rights reserved.

①コミュニケーションの向上  他にも・・・ • 例）自動車 プリウス プリウスEグレード プリウスGグレード 調達部門 製品 製品分類 商品 製品 ?? 製造品 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ ・・・・・・・・・・・・・・・・・・・・・・・・ プリウスEグレードPHEV 製造番号XXXXX ・・・・・ copy right ©2024 Shintaro Fujimoto all rights reserved. 営業部門

①コミュニケーションの向上  他にも・・・ • 営業部門 調達部門 製品 製品分類 商品 製品 同じような言葉でも、 ?? 異音同義語・同音異義語が多数存在する! プリウスEグレードPHEV 製造番号XXXXX ・・・・・ 製造品 例）自動車 プリウス プリウスEグレード プリウスGグレード copy right ©2024 Shintaro Fujimoto all rights reserved. ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・ ・・・・・・・・・・・・・・・・・・・・・・・・

①コミュニケーションの向上  これを放置したままだとコミュニケーションロスが起こる。 • 例えば、全社横断でデータ分析を行いたいといった場合等 製品軸で全社レベルでの 収支の分析をすべし! 製品といってもよく調べると 部門ごとに意味が違うぞ・・・? 経営陣 DX担当（ITや経営企画部門） 製品や 売上データ 製品や 仕入データ 製品とは、プリウスの”Eグレード”とか “Gグレード”みたいなレベルです 製品とは、”プリウス”とか “レクサス”みたいな分類です 営業部門 copy right ©2024 Shintaro Fujimoto all rights reserved. 調達部門

①コミュニケーションの向上  この問題に対処するためには、データモデルを作成し・・・ 営業部門 調達部門 製品 製品分類 商品 製品 製造品 各部門の言葉の違いをデータモデルで 表すとこんな感じか・・・ copy right ©2024 Shintaro Fujimoto all rights reserved.

①コミュニケーションの向上  データモデルを用いながら、言葉の意味や定義を合わせて会話をするのが効果的。 製品軸って具体的にどれを指してますか? 営業部門 調達部門 製品 製品分類 商品 製品 製造品 DX担当（ITや経営企画部門） 営業部門で言う製品だな。 調達部門で言う製品分類だ。 経営陣 了解! 調達部門 営業部門 copy right ©2024 Shintaro Fujimoto all rights reserved.

②現状理解の精度向上  現状理解とは、大きく業務とIT（システム）の現状を指す。 Business copy right ©2024 Shintaro Fujimoto all rights reserved. IT

②現状理解の精度向上 業務理解  あらゆる業務の結果はデータとして記録される。 • つまり、データを知ることは組織がどんな業務を行っているかを俯瞰することにつながる。 営業 取引先 商品 見積 (確定) 1 見積明細 (確定) 1 受注契約 受注契約 明細 出荷 出荷明細 copy right ©2024 Shintaro Fujimoto all rights reserved. ・まず、取引先と見積をするんだな。 ・見積が確定したら受注契約を結んで、 ・契約に対し分割出荷を行えるのか。 ・見積～出荷までが営業の業務範囲なんだな。 などなど

②現状理解の精度向上 業務理解  あらゆる業務の結果はデータとして記録される。 • つまり、データを知ることは組織がどんな業務を行っているかを俯瞰することにつながる。 営業 取引先 見積 商品 ・まず、取引先と見積をするんだな。 ・見積が確定したら受注契約を結んで、 ・契約に対し分割出荷を行えるのか。 ・見積～出荷までが営業の業務範囲なんだな。 などなど 新入社員や、外部ベンダに対し、業務を説明する時にも (確定) 受注契約 役立つ!! 1 見積明細 (確定) 1 受注契約 明細 出荷 出荷明細 copy right ©2024 Shintaro Fujimoto all rights reserved.

②現状理解の精度向上 システム理解  また、データモデルにより、システムの構造が可視化できる。 • 老朽化したシステムを改修する時などに役立つ。 現行システム 移行先システム 取引先 仕入先 仕入先 顧客 copy right ©2024 Shintaro Fujimoto all rights reserved. 顧客 ・現行システムは、取引先テーブルで仕入先も顧客も管理している ・一方で移行先システムは仕入先と顧客のテーブルに分かれている ・このあたりは移行する時に考えないとな・・・ などなど

②現状理解の精度向上 システム理解  また、データモデルにより、システムの構造が可視化できる。 • 老朽化したシステムを改修する時などに役立つ。 現行システム 移行先システム 取引先 仕入先 仕入先 顧客 ・現行システムは、取引先テーブルで仕入先も顧客も管理している ・一方で移行先システムは仕入先と顧客のテーブルに分かれている ・このあたりは移行する時に考えないとな・・・ などなど 顧客 現行や新規システムの構造を理解することで、 システム移行などが効率的になる! copy right ©2024 Shintaro Fujimoto all rights reserved.

③DX化貢献  DXには大きく3つのフェーズが存在するといわれている。 デジタイゼーション デジタライゼーション デジタルトランスフォーメーション 業務のデジタル化 フロープロセスのデジタル化 デジタルによる新製品・サービス 出典:https://www.soumu.go.jp/hakusho-kids/use/live/live_06.html copy right ©2024 Shintaro Fujimoto all rights reserved. 総務省

• https://www.soumu.go.jp/hakusho-kids/use/live/live_06.html

③DX化貢献  データモデルは特に、前2つのフェーズで非常に役立つと考えている。 デジタイゼーション デジタライゼーション デジタルトランスフォーメーション 業務のデジタル化 フロープロセスのデジタル化 デジタルによる新製品・サービス copy right ©2024 Shintaro Fujimoto all rights reserved.

③DX化貢献 デジタイゼーション  デジタイゼーションを行うためには、現行アナログで行われている業務を分析し、 必要なデータをシステム上でどのように管理するかを検討する必要がある。 • データモデルを利用すると、この検討をより効率的に行える!! 業務フロー データモデル デジタイゼーション A部門 B部門 C部門 業務のデジタル化 copy right ©2024 Shintaro Fujimoto all rights reserved. 開始 XX業務 YY業務 ZZ業務 OO業務 終了

③DX化貢献 デジタライゼーション  デジタライゼーションの実現のためには、社内外のデータを把握し、どのように活用するか を検討する必要がある。 • 特に、社内外のデータを把握するという点においてデータモデルは有用である!! 社内システム 社外システム デジタライゼーション 生産 システム フロープロセスのデジタル化 copy right ©2024 Shintaro Fujimoto all rights reserved. 調達 システム 製品 品目 生産 受注 出荷 顧客 請求 システム DUNS 取引先 企業 請求

データモデルを作成する意義  ここまで述べたように、データモデルを作成する意義は非常に大きい。  さらに、ITの知識が無い業務側の方でもすぐに学ぶことが出来る。 copy right ©2024 Shintaro Fujimoto all rights reserved.

データモデルを作成する意義  にも関わらずデータモデルを読める/描ける人は非常に少ない。 データモデルを学ぶことは大きな希少価値につながる!! copy right ©2024 Shintaro Fujimoto all rights reserved.

データモデルの概要 番外編①  データモデルを作成する目的に応じて、いくつかのレベルに分かれる。 概念:ビジネス要件 論理:ビジネス詳細 取引先 取引先 取引先ID 取引先名 住所 電話番号 見積 見積ID 取引先ID（FK） 見積年月日 合計見積金額 見積 ・ビジネスの重要語句とその関係性や 定義などを表す。 ・概念モデルに属性を追加したもの。 →ビジネス視点でのデータ要件を詳細に 表現したもの。 ・システムやアプリの制約からは独立している。 （実装独立） copy right ©2024 Shintaro Fujimoto all各定義はData rights reserved.Modeling Made Simple, 2 nd Edition: A Practical Guide for Business and IT Professionals 物理:アプリ実装 VENDOR VENDOR_ID :CHAR(10) NotNull VENDOR_NM :CHAR(100) NotNull ADRESS :CHAR(255) Null TEL_NO :INT(11) Null QUOTATION QUOTATION_ID :CHAR(15) NotNull VENDOR_ID(FK) :CHAR(10) NotNull QUO_DATE :DATE Null SUM_QUO_AMT :CHAR(100) Null ・実際にシステムで実装するために作成する。 ・システムやアプリの性能等を考慮したもの。 より 著:Steve Hoberman 出版:Technics Publications LLC

データモデルの概要 番外編①  最終目的はデータベースに実装することだが、そのための業務要件を整理するために 概念・論理モデルを作成する。 ITではない人間（業務側）も作成に大いに関わる! 概念:ビジネス要件 論理:ビジネス詳細 取引先 取引先 取引先ID 取引先名 住所 電話番号 見積 見積ID 取引先ID（FK） 見積年月日 合計見積金額 見積 copy right ©2024 Shintaro Fujimoto all各定義はData rights reserved.Modeling Made Simple, 2 nd Edition: A Practical Guide for Business and IT Professionals 物理:アプリ実装 VENDOR VENDOR_ID :CHAR(10) NotNull VENDOR_NM :CHAR(100) NotNull ADRESS :CHAR(255) Null TEL_NO :INT(11) Null QUOTATION QUOTATION_ID :CHAR(15) NotNull VENDOR_ID(FK) :CHAR(10) NotNull QUO_DATE :DATE Null SUM_QUO_AMT :CHAR(100) Null より 著:Steve Hoberman 出版:Technics Publications LLC

データモデルの概要 番外編①  なお、本資料では下記赤枠の範囲を解説。 概念:ビジネス要件 論理:ビジネス詳細 取引先 取引先 取引先ID 取引先名 住所 電話番号 見積 copy right ©2024 Shintaro Fujimoto all rights reserved. 見積 見積ID 取引先ID（FK） 見積年月日 合計見積金額 物理:アプリ実装 VENDOR VENDOR_ID :CHAR(10) NotNull VENDOR_NM :CHAR(100) NotNull ADRESS :CHAR(255) Null TEL_NO :INT(11) Null QUOTATION QUOTATION_ID :CHAR(15) NotNull VENDOR_ID(FK) :CHAR(10) NotNull QUO_DATE :DATE Null SUM_QUO_AMT :CHAR(100) Null

データモデルの概要 番外編②  番外編①にもあるが、データモデルは最終的にデータベースに実装するために作成する。 • データベースにも以下のような種類が存在する点は覚えておいてほしい。 RDBMS NoSQL CREATE TABLE Book( bookTitleName VARCHAR2(50) NOT NULL, bookDescription VARCHAR2(255) NOT NULL, bookPageCount NUMBER(1,0) NOT NULL, ・・・ CONSTRAINT PK1 PRIMARY KEY (bookTitleName)) ・列と行から構成されるデータベース（巨大なExcelのイメージ） ・RDBMSの中にもリレーショナルやディメンショナルと呼ばれる 種類が存在する。 ・本資料では、リレーショナルデータモデルを想定している。 copy right ©2024 Shintaro Fujimoto all rights reserved. ・RDBMS以外のデータベース。 ・RDMBSのような列・行が無く、クエリも関係ない。 ・画像やテキストなど所謂非構造化データを管理するのに役立つ

データモデルの構成要素 copy right ©2024 Shintaro Fujimoto all rights reserved.

データモデルの構成要素とは? データモデルには以下の構成要素がある。 ① エンティティ ② 属性 ③ キー ④ リレーションシップ copy right ©2024 Shintaro Fujimoto all rights reserved.

①エンティティ  エンティティとは、ビジネス上重要もしくは価値ある情報を概念的にまとめたもの。 • 例）以下表の情報を概念的にまとめ、「従業員」というエンティティで表現する 営業部 田中太郎 copy right ©2024 Shintaro Fujimoto all rights reserved. 従業員No. 姓 名 所属部署CD 0000001 田中 太郎 01 0000002 鈴木 二郎 01 0000003 佐藤 三郎 02 ・・・ ・・・ ・・・ ・・・ 従業員

①エンティティ  概念的にまとめているので、テーブルやファイルが分かれていても一つのエンティティ と捉えることもある。 仕入先No. 取引先区分 仕入先名 住所 代表電話番号 1000001 01(仕入先) ABC商事 東京都・・・ 03xxxxxxxx 1000002 01(仕入先) XX工業 神奈川県・・・ 045xxxxxxx 1000003 01(仕入先) 〇〇株式会社 大阪府・・・ 06xxxxxxxx ・・・ ・・・ ・・・ ・・・ ・・・ 取引先 顧客No. 取引先区分 顧客名 住所 代表電話番号 2000001 02(顧客) ZZ重工 東京都・・・ 03yyyyyyyy 2000002 02(顧客) LA株式会社 神奈川県・・・ 045yyyyyyy 2000003 02(顧客) ABC商事 東京都・・・ 03xxxxxxxx ・・・ ・・・ ・・・ ・・・ ・・・ copy right ©2024 Shintaro Fujimoto all rights reserved. 仕入先 顧客

①エンティティ  エンティティには以下3つの種類が存在する。 マスタ トランザクション 組織内の経営資源（ヒト・モノ・カネなど） に関わるエンティティ 例）取引先、商品、勘定科目など 現実における出来事（業務取引など）に 関わるエンティティ 例）受注、生産、出荷、請求など copy right ©2024 Shintaro Fujimoto all rights reserved. サマリ 業務取引に対し加工した結果に関わる エンティティ 例）損益計算書、月次受注実績など

②属性  属性とは、エンティティを識別、説明、測定するもの。 従業員No. 姓 名 所属部署CD 0000001 田中 太郎 01 0000002 鈴木 二郎 01 0000003 佐藤 三郎 02 ・・・ ・・・ ・・・ ・・・ copy right ©2024 Shintaro Fujimoto all rights reserved. 従業員 従業員No. 姓 名 所属部署CD 属性

③キー  キーとは、属性のうちエンティティのデータを一意に識別できるものを指す。 従業員No. 姓 名 所属部署CD 0000001 田中 太郎 01 0000002 鈴木 二郎 01 0000003 佐藤 三郎 02 ・・・ ・・・ ・・・ ・・・ 従業員は従業員No.によって識別される。 →キー copy right ©2024 Shintaro Fujimoto all rights reserved. 従業員 従業員No. キー 姓 名 所属部署CD 非キー

③キー  キーにもいくつかの種類が存在する。 主キー（Primary Key）: データを一意に識別する属性 なお、複数の属性を組み合わせて主キーと する場合もある。 商品分類 商品分類区分 (PK) 商品分類区分名 商品 商品コード 外部キー（Foreign Key）: 参照先（リレーションシップ先）の主キー 関係性があるエンティティのデータを参照 するための属性 copy right ©2024 Shintaro Fujimoto all rights reserved. (PK) JANコード (AK) 商品分類区分 (FK) 代替キー（Alternative Key）: 主キーに代わってデータを一意に識別 できる属性

④リレーションシップ  リレーションシップとは、エンティティ同士の関係性を示すもの。 社内組織 組織 リレーションシップ ＝1つの組織に 複数の従業員が 所属する に属する 従業員 従業員 現実世界 copy right ©2024 Shintaro Fujimoto all rights reserved. データモデル

④リレーションシップ  リレーションシップのパターンは基本的に以下3つのみ。（多重度と呼ばれる） １:１ １:N 出荷 出荷 1 N:M 組織 従業員 請求 エンティティ同士の関係性が１対１を表す。 例えば、出荷伝票を1件作成すると、 その伝票に対応する請求伝票を必ず 1件作成する など。 copy right ©2024 Shintaro Fujimoto all rights reserved. 請求 従業員 所属組織 エンティティ同士の関係性が1対多を表す。 例えば、出荷伝票1件に対し、 請求伝票を複数回に分けて作成する 場合がある など。 エンティティ同士の関係性が多対多を表す。 例えば、1つの社内組織には複数の従業員 が所属し、従業員も複数の社内組織を兼務 することがある など。

④リレーションシップ  その他、覚えておくべき点として“再帰”と“サブタイプ”という考えがある。 copy right ©2024 Shintaro Fujimoto all rights reserved.

④リレーションシップ:再帰  再帰とは、自己エンティティを参照するリレーションシップを指す。 • 特に、組織などの階層構造を表す際に利用されることが多い。 組織 組織コード 組織名 親組織コード (FK) copy right ©2024 Shintaro Fujimoto all rights reserved. 組織コード 組織名 親組織コード 001 ○○事業部門 - 002 △△部 001 003 ■■課 002

④リレーションシップ:サブタイプ  サブタイプとは部分集合を表す。 • 取引先の中には顧客としての取引先と、仕入先としての取引先の2つが存在する。など 取引先 スーパータイプ（母集合） 顧客 XX工業 〇〇株式会社 仕入先 AA 商事 ZZ重工 LA株式会社 取引先 顧客 仕入先 サブタイプ copy right ©2024 Shintaro Fujimoto all rights reserved.

④リレーションシップ:サブタイプ  サブタイプも、共存型と排他型の2つに分かれる。 • 共存型 共存型の場合、 部分集合の数だけ玉が増える。 取引先 顧客 XX工業 〇〇株式会社 仕入先 AA 商事 ZZ重工 LA株式会社 取引先 顧客 取引先が、顧客と仕入先両方で 登録されることがあるような場合を 共存のサブタイプと呼ぶ。 copy right ©2024 Shintaro Fujimoto all rights reserved. 仕入先

④リレーションシップ:サブタイプ  サブタイプも、共存型と排他型の2つに分かれる。 • 排他型 共存型の場合、 部分集合がいくら増えても玉は1つ。 取引先 顧客 仕入先 XX工業 〇〇株式会社 AA商事 ZZ重工 LA株式会社 取引先 顧客 取引先が、顧客か仕入先の どちらかしか登録されないような 場合を排他のサブタイプと呼ぶ。 copy right ©2024 Shintaro Fujimoto all rights reserved. 仕入先

データモデルの構成要素:補足①  データモデルとは要するに、データを認知するための箱（エンティティ）と、 箱の中身（属性）、そして箱同士の関係性（リレーションシップ）の3つのみ で出来ている。 →簡単かつシンプル! エンティティ 商品分類 商品分類区分 (PK) 属性 商品分類区分名 リレーションシップ 商品 商品コード (PK) JANコード (AK) 商品分類区分 (FK) copy right ©2024 Shintaro Fujimoto all rights reserved.

データモデルの構成要素:補足②  リレーションシップとキーの補足 • リレーションシップの線が引けるかどうかは、外部キーの有無で決まる。 商品分類 商品分類区分 商品分類区分名 商品 商品コード 商品名 商品分類区分 (FK) copy right ©2024 Shintaro Fujimoto all rights reserved. 商品エンティティで、参照先エンティティの主キー“商品分類区分”を 外部キーとして保持している。 このことから、これら2つのエンティティには関係性があると言える。 →リレーションシップ線が引ける

データモデルの構成要素:補足②  なぜ関係性があると言えるのか・・・? 商品の外部キーで商品分類区分を持つということは、 この外部キーを基に、商品分類を参照し、該当するレコードの他属性まで 取得できるということ。 →商品分類区分は商品分類のキー（一意に識別する属性）であるため 商品分類 商品分類区分 商品分類区分名 01 チョコレート 02 ポテトチップス 03 グミ ・・・ ・・・ 商品  商品コード 商品名 商品分類区分 商品分類区分名 0001 ミルクチョコレート 01 チョコレート 0002 ホワイトチョコレート 01 チョコレート 0003 ポテトチップスうすしお 02 ポテトチップス ・・・ ・・・ ・・・ ・・・ このように、外部キーを持つことで、参照先エンティティの属性情報を取得できるよう になることから、関係性があると言える。 copy right ©2024 Shintaro Fujimoto all rights reserved.

データモデルの構成要素:補足②  このようにするメリットとは? 商品分類 商品 商品コード 商品名 商品分類区分 商品分類区分名 商品分類区分 商品分類区分名 0001 ミルクチョコレート 01 チョコレート 01 チョコレート 0002 ホワイトチョコレート 01 チョコ 02 ポテトチップス 0003 ポテトチップスうすしお 02 ポテチ 03 グミ ・・・ ・・・ ・・・ ・・・ ・・・ ・・・ 外部キーで参照しないということは、商品エンティティ側でも都度手入力をしないといけないことになる。 つまり、商品分類エンティティとのダブルメンテや入力内容の齟齬等が発生する。 →外部キーとして参照することで回避できる。 copy right ©2024 Shintaro Fujimoto all rights reserved.

データモデルの構成要素:補足②  これを突き詰めていくと、冗⾧的にならないよう、エンティティを徹底的に部品化（＝ IT用語で“正規化”）し、部品をリレーションシップでつなげることになる。  これにより、効率的なデータ管理が実現できる。 最初のこれも正規化! 商品分類 copy right ©2024 Shintaro Fujimoto all rights reserved. 例）ハイボール 商品 例） ハイボール -ハイボール レモンハイボール -ハイボール 注文 例） レモンハイボール 2杯 XXX円 ジョッキ生 2杯 YYY円 レモンハイボール 1杯 ZZZ円

データモデルの実践! copy right ©2024 Shintaro Fujimoto all rights reserved.

正規化  正規化をここでは実践してみよう! •  正規化はデータモデルの核となる概念、これが分かればデータモデルを習得したも同然! 正規化は大きく以下5つの手順で行います。 1. 該当データがどんなエンティティか?を特定する。 2. そのエンティティのキーを特定する。 3. 繰り返し出てくる属性のセットを特定する。 4. 3.の属性セットを別エンティティとして切り出しリレーションシップを引く。 5. 切り出したエンティティに対し1.～4.を繰り返す。 copy right ©2024 Shintaro Fujimoto all rights reserved.

正規化  下図の社員証をデータモデルで表現してみよう! 従業員を登録するシステムを考えてみましょう。 社員番号:000001 営業部門 第一営業課 佐藤 太郎 [email protected] 080-xxxx-xxxx copy right ©2024 Shintaro Fujimoto all rights reserved.

正規化 手順1:該当データがどんなエンティティか?を特定する。  この社員証がどんなエンティティか?保持する属性が何か?を考えてみましょう! 従業員を登録しているので、“従業員”エンティティ という名称が考えられます。 もしくは、社員証なので“社員”エンティティと考えて も良いでしょう。 社員番号:000001 001-01:営業部門 第一営業課 佐藤 太郎 [email protected] 080-xxxx-xxxx copy right ©2024 Shintaro Fujimoto all rights reserved.

正規化 手順1:該当データがどんなエンティティか?を特定する。  保持する属性のイメージはこのような感じです。 従業員 ① 社員番号:000001 ② 001-01:営業部門 第一営業課 ③ 佐藤 太郎 ④ [email protected] 080-xxxx-xxxx ⑤ copy right ©2024 Shintaro Fujimoto all rights reserved. ①社員番号 ②所属組織CD ②所属組織名 ③氏名 ④メールアドレス ⑤電話番号 0001 001-01 営業部門 第一営業課 佐藤 太郎 [email protected] 080-xxxx-xxxx 0002 002-01 開発部門 ○○開発課 鈴木 次郎 [email protected] 080-yyyy-yyyy 0003 001-02 営業部門 第二営業課 田中 三郎 [email protected] 080-zzzz-zzzz 0004 001-01 営業部門 第一営業課 山田 史郎 [email protected] 080-aaaa-aaaa ・・・ ・・・ ・・・ ・・・ ・・・ ・・・

正規化 手順2:そのエンティティのキーを特定する。  次にこのエンティティのデータを一意に特定するための項目が何かを考えてみましょう! 社員番号が、従業員(もしくは社員)を特定する番号だろう と想定できます。 従業員 ①社員番号 ②所属組織CD ②所属組織名 ③氏名 ④メールアドレス ⑤電話番号 0001 001-01 営業部門 第一営業課 佐藤 太郎 [email protected] 080-xxxx-xxxx 0002 002-01 開発部門 ○○開発課 鈴木 次郎 [email protected] 080-yyyy-yyyy 0003 001-02 営業部門 第二営業課 田中 三郎 [email protected] 080-zzzz-zzzz 0004 001-01 営業部門 第一営業課 山田 史郎 [email protected] 080-aaaa-aaaa ・・・ ・・・ ・・・ ・・・ ・・・ ・・・ copy right ©2024 Shintaro Fujimoto all rights reserved.

正規化 手順3:繰り返し出てくる属性のセットを特定する。  繰り返し出てくる属性とは、レコードを跨って何度も出てくる値を指します。 従業員 ①社員番号 ②所属組織CD ②所属組織名 ③氏名 ④メールアドレス ⑤電話番号 0001 001-01 営業部門 第一営業課 佐藤 太郎 [email protected] 080-xxxx-xxxx 0002 002-01 開発部門 ○○開発課 鈴木 次郎 [email protected] 080-yyyy-yyyy 0003 001-02 営業部門 第二営業課 田中 三郎 [email protected] 080-zzzz-zzzz 0004 001-01 営業部門 第一営業課 山田 史郎 [email protected] 080-aaaa-aaaa ・・・ ・・・ ・・・ ・・・ ・・・ ・・・ 複数のレコードに繰り返し“001-01”と“営業部門 第一営業課” が出てきている。→繰り返し属性のセットと考えられる。 繰り返し属性は部品化（正規化）する! copy right ©2024 Shintaro Fujimoto all rights reserved.

正規化 手順4:別エンティティとして切り出しリレーションシップを引く。  手順3で特定した属性のセット（主キー＋非キー属性）を別エンティティに切り出し、 切り出した主キーを外部キーとして参照させる。 組織 ②所属組織CD ②所属組織名 001-01 営業部門 第一営業課 002-01 開発部門 ○○開発課 001-02 営業部門 第二営業課 001-01 営業部門 第一営業課 ・・・ ・・・ 繰り返し属性は別エンティティとする。その際、主キーも特定する。 参照先（従業員エンティティ側）は別エンティティに切り出した 組織エンティティの主キーを外部キーとして保持する。 従業員 ①社員番号 ②所属組織CD(FK) ②所属組織名 ③氏名 ④メールアドレス ⑤電話番号 0001 001-01 営業部門 第一営業課 佐藤 太郎 [email protected] 080-xxxx-xxxx 0002 002-01 開発部門 ○○開発課 鈴木 次郎 [email protected] 080-yyyy-yyyy 0003 001-02 営業部門 第二営業課 田中 三郎 [email protected] 080-zzzz-zzzz 0004 001-01 営業部門 第一営業課 山田 史郎 [email protected] 080-aaaa-aaaa ・・・ ・・・ ・・・ ・・・ ・・・ ・・・ copy right ©2024 Shintaro Fujimoto all rights reserved.

正規化 手順5:切り出したエンティティに対し手順1～4を繰り返す。  この場合は組織エンティティの正規化を考える。 冗⾧項目は無さそうなので、これ以上正規化は行えない。 と考えることも出来る。 組織 ②所属組織CD ②所属組織名 001-01 営業部門 第一営業課 002-01 開発部門 ○○開発課 001-02 営業部門 第二営業課 001-01 営業部門 第一営業課 ・・・ ・・・ 従業員 ①社員番号 ②所属組織CD(FK) ②所属組織名 ③氏名 ④メールアドレス ⑤電話番号 0001 001-01 営業部門 第一営業課 佐藤 太郎 [email protected] 080-xxxx-xxxx 0002 002-01 開発部門 ○○開発課 鈴木 次郎 [email protected] 080-yyyy-yyyy 0003 001-02 営業部門 第二営業課 田中 三郎 [email protected] 080-zzzz-zzzz 0004 001-01 営業部門 第一営業課 山田 史郎 [email protected] 080-aaaa-aaaa ・・・ ・・・ ・・・ ・・・ ・・・ ・・・ copy right ©2024 Shintaro Fujimoto all rights reserved.

正規化 手順5（ご参考）  参考: よく見ると、所属組織CDと所属組織名の一部に繰り返しが発生 している。 組織 ②所属組織CD ②所属組織名 001-01 営業部門 第一営業課 002-01 開発部門 ○○開発課 001-02 営業部門 第二営業課 001-01 営業部門 第一営業課 ・・・ ・・・ 従業員 ①社員番号 ②所属組織CD(FK) ②所属組織名 ③氏名 ④メールアドレス ⑤電話番号 0001 001-01 営業部門 第一営業課 佐藤 太郎 [email protected] 080-xxxx-xxxx 0002 002-01 開発部門 ○○開発課 鈴木 次郎 [email protected] 080-yyyy-yyyy 0003 001-02 営業部門 第二営業課 田中 三郎 [email protected] 080-zzzz-zzzz 0004 001-01 営業部門 第一営業課 山田 史郎 [email protected] 080-aaaa-aaaa ・・・ ・・・ ・・・ ・・・ ・・・ ・・・ copy right ©2024 Shintaro Fujimoto all rights reserved.

正規化 手順5（ご参考）  参考: 部門 所属部門CD 所属部門名 001 営業部門 002 開発部門 ・・・ ・・・ 所属部門CD 所属課CD 所属部門名 所属課名 001 01 営業部門 第一営業課 001 02 営業部門 第二営業課 002 01 開発部門 ○○開発課 ・・・ ・・・ ・・・ ①社員番号 ②所属組織CD(FK) ②所属組織名 ③氏名 ④メールアドレス ⑤電話番号 0001 001-01 営業部門 第一営業課 佐藤 太郎 [email protected] 080-xxxx-xxxx 0002 002-01 開発部門 ○○開発課 鈴木 次郎 [email protected] 080-yyyy-yyyy 0003 001-02 営業部門 第二営業課 田中 三郎 [email protected] 080-zzzz-zzzz 0004 001-01 営業部門 第一営業課 山田 史郎 [email protected] 080-aaaa-aaaa ・・・ ・・・ ・・・ ・・・ ・・・ ・・・ もしかすると、部門と課という組織階層に応じてエンティティを切り 出せるかも?と考えることもできる。 →ここは業務がどうデータを扱っているかによる。 課 従業員 copy right ©2024 Shintaro Fujimoto all rights reserved.

正規化 補足  データモデルで表すとこのようになる。 組織 所属組織CD 所属組織名 従業員 従業員 社員番号 社員番号 氏名 所属組織CD 所属組織名 メールアドレス 電話番号 氏名 所属組織CD（FK） メールアドレス 電話番号 copy right ©2024 Shintaro Fujimoto all rights reserved.

正規化 補足  手順5の参考を考慮するとこのようなイメージ。 部門 所属部門CD 所属部門名 課 所属部門CD（FK） 所属課CD 所属課名 従業員 従業員 社員番号 社員番号 氏名 所属組織CD 所属組織名 メールアドレス 電話番号 氏名 所属部門CD（FK） 所属課CD（FK） メールアドレス 電話番号 copy right ©2024 Shintaro Fujimoto all rights reserved.

最後に!  これまでの内容を参考に、以下の画面帳票を正規化し、データモデルで表現してみて ください! copy right ©2024 Shintaro Fujimoto all rights reserved. https://www.isp21.co.jp/solution/library/

• https://www.isp21.co.jp/solution/library/

ご視聴ありがとうございました Blogs:https://note.com/shinfuji269 copy right ©2024 Shintaro Fujimoto all rights reserved.

• https://note.com/shinfuji269