inflearn logo
知識共有
inflearn logo

やさしく学ぶデータモデリング:基本から実践テーブル設計まで (DASP/DAP)

テーブル設計で、もどかしさを感じたことはありませんか? 「このテーブルで合っているのかな?」、「どのカラムをPKにすべきだろう?」、「リレーションをこのように繋いでも大丈夫かな?」 「機能を追加する時に、テーブルを作り直さなければならないのではないか?」といった悩みをお持ちの方のための講座です。

難易度 初級

受講期間 無制限

SQL
SQL
DBMS/RDBMS
DBMS/RDBMS
ERD
ERD
database-modeling
database-modeling
Data Architecture Semi-Professional
Data Architecture Semi-Professional
SQL
SQL
DBMS/RDBMS
DBMS/RDBMS
ERD
ERD
database-modeling
database-modeling
Data Architecture Semi-Professional
Data Architecture Semi-Professional

受講後に得られること

  • 要件を分析し、テーブルを設計する方法

  • エンティティ、属性、識別子、リレーションシップに関する「論理データモデリング」の必須概念

  • DASP、DAP資格取得のための知識

  • パフォーマンスを考慮したテーブル設計方法

  • ERDを描くための表記法 (IE, Barker)

皆さんのテーブル設計、大丈夫ですか?

  • 設計するたびに確信が持てない不安感 every time you design.

  • 修正しようとしたらすでに絡まってしまった複雑な構造 that is already tangled when you try to modify it đã bị rối tung lên rồi

  • 機能追加 = テーブル再設計の繰り返し

  • 体系的に学んだことのないデータモデリング


この講義では、単に「動くだけ」のテーブルではなく、
拡張可能でメンテナンスしやすいテーブル設計の方法を学びます。

実務で誰もが経験する悩み

顧客の要件を適切に反映したテーブルを作るのは容易ではありません。
どのような構造が適切か、修正しやすい設計か、拡張可能な構造か…一人で判断するのは難しいものです。

検索してみても置かれた状況は人それぞれ異なり、結局「これが正しい方法なのだろうか?」という不安ばかりが募ります。

設計の問題は、時間が経つにつれて大きくなります。

最初は大丈夫そうに見えたのですが…

多くの開発者が似たような経験をします。
プロジェクトの序盤にはテーブルを素早く作成し、開発機能を実装することに集中します。
データも少なく要件もそれほど大きくないため、すべてが順調に感じられます。

しかし、時間が経つにつれてプロジェクトが成長し、複雑さが増すと
初期に「速さだけ」を求めて作ったテーブル構造が、次第に大きな足かせとなります。

簡単な機能追加でも複数のテーブルを修正しなければならず、データの整合性の問題でバグが繰り返され、
結局、「あの時ちゃんと設計しておけば…」と後悔することになります。


初期段階

😊

  • 「とりあえずデータさえ入れられればいい!」

  • 深く考えずに設計

    迅速な開発のために必要な属性を一つのテーブルに詰め込む

  • データ量が少ない時は何の問題もないように見える


6ヶ月後

📉

  • 機能を追加するたびにテーブル構造の修正が必要

  • 同じデータが複数のテーブルに重複し、整合性の問題が発生

  • クエリが徐々に複雑になり、パフォーマンスが低下し始める

1~2年後

🚨

  • 機能一つ追加するのに修正すべき箇所が多すぎる

  • 必要なデータをどのテーブルから持ってくるか毎回悩む

  • データの不整合が頻繁に発生し、修正多くの時間を費やす


解決策:適切なデータモデリング(テーブル設計)

同じ要求事項、異なる設計

同じ機能を実装する場合でも、どのように設計するかによって結果は完全に異なります。
拡張性を考慮して設計されたテーブルは、要件が変わっても柔軟に対応できます。

一方、深く考えずに作成したテーブルは、小さな変更でも多くの修正が必要になり、予期せぬ問題が次々と発生します。

序盤ではこのような違いはあまり目立ちません。どちらも正常に動作しているように見えるからです。
しかし、時間が経つにつれて、その差は開発スピードやメンテナンスの難易度として現れます。

この講義では、拡張可能なテーブルを設計する方法を扱います。
「後で直せばいい」ではなく、「最初から正しく」作る方法を学びます。
講義を終える頃には、要件を見て拡張可能な構造で設計できるようになります。


📌顧客の要件📌

  1. 社内食堂では、毎週の献立表を確認することができる。

  2. 献立は月曜日から金曜日まで昼食/夕食を提供し、献立ごとに

    該当する献立を提供した栄養士の情報を確認できる。

  3. 献立メニューにはご飯と汁物が必須で含まれ、おかずは複数含まれる場合がある。

    カロリーも管理されなければならない。

  4. ヨーグルト、アイスクリーム、果物のような副食が出る場合もある。

👎深く考えずに設計したモデル

👍十分に検討されたモデル

この講義の特徴

1. 実践中心の学習

単なる理論ではなく、実務ですぐに使える内容で構成

  • 実務でよく直面する悩みと解決策の提示

  • 図書貸出システム、ショッピングモールなど実務に近い例題を活用

  • データモデリングの段階を直接追いながら学習

2. 体系的な講義資料

700ページに及ぶPPT資料で完璧な復習

  • 要点だけをまとめた内容で概念を把握しやすい

  • いつでも見返せるリファレンス

3. 誰でも簡単に実習

特別な準備なしですぐに開始可能

  • 紙とペンさえあれば十分、ツールは選択事項

  • WebベースのERD Cloudで、別途インストールなしで実習

  • Barker表記法とIE表記法の両方を説明

講義構成(詳細目次)

1. データモデリング基礎講座を開始します

講義紹介:テーブル設計の過程で、もどかしさを感じたことはありませんか?

  • 講義で扱う内容

  • 誰のための講義か? (Feat. DB設計を必要とする開発者と初心者モデラー)

  • 講義の構成

  • 講義を受講するための事前知識


業務効率と開発生産性の向上方法

  • データモデリングとは?

  • 私たちはERDを管理していません

  • このように設計すると、後で苦労することになります

私のデータモデリング理解度のチェック

  • クイズ1:○/×問題

  • クイズ2:テーブルの数を当てる

2. データモデリングのための第一歩

要件分析からテーブル作成までの段階

  • トイプロジェクトで説明するデータモデリングの段階

  • 要求事項の分析・定義

  • 主題領域の設定

  • 概念データモデリング

  • 論理データモデリング

  • 物理データモデリング

  • データモデリングの段階を簡素化できるだろうか?

データモデリング表記法 (Barker, IE)

  • データモデリングのためのBarker/IE表記法

  • エンティティ表記

  • 属性の表記

  • 識別子の表記

  • リレーションシップの表記

  • サブタイプ表記

データモデリングツール (ERwin DA# ERDCloud)

  • ERwin DA# ERDCloud

  • ERDCloud 実習

3. エンティティ[テーブル]:どのような情報をテーブルとして抽出するべきでしょうか?

エンティティとは

  • エンティティの概念

  • テーブル?エンティティ?何が違うんだろう

要件からエンティティを抽出する方法

  • エンティティはどうやって導出するのか?

  • データモデリングの核心「エンティティ抽出」

  • 【実習】エンティティ抽出をやってみる

エンティティが「適切に」抽出されたか確認する

  • エンティティの意味を明確に付与したか

  • 管理が必要な対象であるか

  • 集合を成しているか

  • 業務プロセスに依存していないか

  • 独立性を持っているか

  • 画面ごとにエンティティを抽出していないか

エンティティを分類すると、どのようなデータが保存されるのかを知ることができます

  • エンティティにも性格がある

  • テーブル設計を上手に行う秘訣:性格別のエンティティ分類

  • エンティティ分類のメリット

4. 属性[カラム]:要件にあるすべてのカラムを追加するわけではありません。

属性とは

  • 属性の概念

  • 属性の構成要素

クエリ開発が容易になる属性分類

  • 属性を分類する理由

  • 基礎属性

  • 関係属性

  • 抽出属性/重複属性

  • システム属性

多くの開発者が見落としがちな特別な属性設計

  • 特別な属性

  • 多値属性

  • 複合属性

  • 排他的属性

  • コード属性

属性の導出方法

  • 本当に必要な属性を見つけ出す秘訣

  • 【実習】属性抽出の進め方

5. 識別子[PK]:このようなカラムをPKに選定してください。

識別子とは

  • 識別子の概念

  • 識別子の特徴

  • 識別子の分類

「〇〇番号」としてよく使われる人工識別子

  • 本質識別子と人工識別子(feat.真主語と仮主語)

  • エンティティの性質別に主に使われる識別子

  • 本質識別子を使おうか?人工識別子を使おうか?

識別子の選定方法

  • [実習] 識別子の選定手順に従ってみる

  • 識別子選定時の注意事項

識別子に関する様々な話

  • 無条件に人工識別子で作るとしたら?

  • 商品番号属性の形式 (000000121 vs GOD000121 vs 121)

  • 事例データを考える習慣

6. 関係[FK]:テーブル間の連結 - Join

関係とは

  • 関係の概念

  • 関係とJoin

関係の構成要素(関係次数、関係選択性、関係名)

  • 関係の構成要素

  • 関係次数(1:1 / 1:M / M:N)

  • 関係選択性(選択 / 必須)

  • 関係名

関係を簡単に繋ぐための秘訣

  • 関係線が持っている隠された意味

  • 従属関係

  • 参照関係

  • 識別関係と非識別関係

  • 従属/参照 識別/非識別関係のまとめ

実務で直面する厄介なリレーション(多重、再帰、排他、BOM)

  • 様々な関係

  • 多重関係

  • 再帰関係(=循環関係)

  • 排他的関係(=アーク関係)

  • BOM関係

関係導出方法

  • [実習]リレーションシップ導出に挑戦1

  • [実習]リレーションシップ導出の進め方2

関係に関する様々な話

  • 外部キー(FK)制約は必要か?(feat. うちの会社はFKを作成しません)

  • リレーションシップ(関係)線を結ばなくてもよい場合

  • 性能向上のためのリレーションシップ接続

7. サブタイプ:類似したエンティティを戦略的に管理する方法

サブタイプとスーパータイプ

  • サブタイプ/スーパータイプの概念

  • サブタイプ/スーパータイプの特性

どのような状況でサブタイプを使用するのか?

  • サブタイプを使用する理由

  • サブタイプを導出すべき状況

サブタイプの導出方法

  • 【実習】サブタイプの導出をやってみる

  • サブタイプ導出時の注意事項

サブタイプが含まれるエンティティのテーブル作成

  • サブタイプが含まれるエンティティのテーブル作成タイプ3選

  • タイプ1. サブタイプ構造

  • 유형2. 통합 테이블 구조

  • タイプ3. 個別テーブル構造

  • テーブル作成タイプの選択基準

8. 正規化と反(非)正規化:完璧な構造 vs 速いパフォーマンス

正規化とは

  • 正規化の概念

  • 正規化、なぜ?すべきなのか

  • 正規化のメリットとデメリット

第1正規化 - 重複するものを分離しよう!

  • 第1正規形の定義

  • 第1正規化を行わなかった時の問題点

  • [実習]改善してみましょうか?

第2正規化 - 識別子の全属性に完全従属するように!

  • 第2正規化の定義

  • 第2正規化を行わなかった時の問題点

  • 【実習】改善してみましょうか?

第3正規化 - 非識別子属性同士に従属関係がある?

  • 第3正規形の定義

  • 第3正規化を行わなかった時の問題点

  • [実習]改善してみましょうか?

反(非)正規化とは

  • 反正規化の概念

  • 反正規化を行う前の必須確認事項

  • 反正規化のメリットとデメリット

性能改善のための逆正規化(非正規化)の3つの方法

  • 重複カラムの生成

  • 重複テーブルの生成

  • テーブル分割

9. 共通コードと履歴管理

共通コード

  • 共通コードとは?

  • コードを使用する理由

  • 共通コード設計時の注意事項

共通コードの設計方法

  • [実習]共通コード設計方法 1

  • [実習]共通コード設計方法 2

  • 共通コード VS 個別コード

履歴管理

  • 履歴とは?

  • OOの状況では履歴管理が必須です。

  • [実習]履歴設計方法 1

  • [実習]履歴設計方法 2

こんな方に
おすすめです

学習対象は
誰でしょう?

  • 業務領域別のDBテーブル設計を必要とする「開発者」

  • 全体構造について悩みながらデータモデリングを行うべき「初心者モデラー」

  • DASP、DAP資格の取得を目指している方!

前提知識、
必要でしょうか?

  • SQLにおける結合(Join)の概念

  • Select ~ From ~ Where クエリに関する基礎知識

こんにちは
Archixです。

こんにちは 👋

外資系企業でData Architectとして働いているArchixです。

バックエンド開発者としてスタートし、SQLP 🎖、DAP 🎖 の資格を取得してデータ専門家の道を歩むことになりました。現在は開発者の方々のデータモデル効率化やクエリチューニングを支援し、より良いデータ管理のために働いています。

多くのプロジェクトや運用を経験する中で、一つ確信したことがあります。それは、設計がしっかりしているシステムは揺るがないということです。一方で、設計が不十分なシステムは小さな問題が繰り返され、結局は不必要なリソースの浪費につながってしまいます。

開発者として働いた経験があるからこそ、このような状況を間近で経験してきました。その経験を講義に反映させ、実務ですぐに活用できる内容をお伝えしたいと考えています。

これからもデータモデリングの重要性を多方面で伝えるために、継続的に活動していく予定です。

講義をすべて受講された後、DA(データアナリスト)職務やキャリアについて気になることがあれば、「完講」の認証とともに、以下のメールアドレスまでお気軽にご連絡ください。可能な範囲でお力添えさせていただきます。

📩cherish1058@naver.com

ありがとうございます。

もっと見る

カリキュラム

全体

37件 ∙ (9時間 42分)

講座資料(こうぎしりょう):

授業資料
講座掲載日: 
最終更新日: 

受講レビュー

全体

2件

5.0

2件の受講レビュー

  • bbyyydd님의 프로필 이미지
    bbyyydd

    受講レビュー 5

    平均評価 4.6

    5

    100% 受講後に作成

    開発中にテーブルを設計することがありますが、講義を受けて曖昧だった部分がかなり解消された気がします。 何より、間違ったテーブル設計のせいでクエリを書くのが大変だったのですが、「自分のクエリ作成能力が足りないわけではない」という言葉に救われました(泣)

    • cherish10588578
      知識共有者

      曖昧だった部分が解消されて良かったです。 設計が不十分なテーブルのクエリは、特にインラインビューを多用することになり、似たようなデータが多いため、どこからデータを持ってくるべきか非常に悩みますよね。 これからは、十分に検討された、優れた設計の構造を作り上げていけるはずです! ありがとうございます。

  • cherish10588578님의 프로필 이미지
    cherish10588578

    受講レビュー 2

    平均評価 4.0

    5

    100% 受講後に作成

    似ている講座

    同じ分野の他の講座を見てみましょう!

    期間限定セール、あと8日日で終了

    ¥51,480

    35%

    ¥10,111