JPA (ORM) 開発者向け 高性能SQL (High-Performance SQL)
Vlad Mihalcea
リレーショナルデータベースシステムを最大限に活用しましょう!
中級以上
SQL, performance-tuning, sql-query
テーブル設計で、もどかしさを感じたことはありませんか? 「このテーブルで合っているのかな?」、「どのカラムをPKにすべきだろう?」、「リレーションをこのように繋いでも大丈夫かな?」 「機能を追加する時に、テーブルを作り直さなければならないのではないか?」といった悩みをお持ちの方のための講座です。
受講生 92名
難易度 初級
受講期間 無制限
学習した受講者のレビュー
5.0
준영
分かりやすく基礎を固めるのに最適です
5.0
Rootree
開発者ですが、DBモデリングに興味があり受講することにしました。 就職準備の時に難解で理解できなかった概念を、分かりやすい例えと共に整理することができて良かったです。 一歩ずつ理論に続いて例を挙げてくださる説明のおかげで、理解しにくい部分も明確に理解できました :) 経験者の方々にとっては基礎的な内容かもしれませんが、一度整理するという気持ちで気楽に聞ける講義だと思います。講義のトーン自体も、落ち着いて説明してくれる親しみやすい先輩のような感じがして良かったです。 今後、先生の新しい講義が出たら、期待を持って次の講義も受講すると思います :) あ、それと完走(最後まで受講)すればキャリアの悩みも先生に相談できるのですが、私にとってはそこが完走する大きなモチベーションになりました(笑) 近いうちにメールで問い合わせさせていただきます〜!!良い講義を作ってくださりありがとうございました!
5.0
yooonuu
開発中にテーブルを設計することがありますが、講義を受けて曖昧だった部分がかなり解消された気がします。 何より、間違ったテーブル設計のせいでクエリを書くのが大変だったのですが、「自分のクエリ作成能力が足りないわけではない」という言葉に救われました(泣)
要件を分析し、テーブルを設計する方法
エンティティ、属性、識別子、リレーションシップに関する「論理データモデリング」の必須概念
DASP、DAP資格取得のための知識
パフォーマンスを考慮したテーブル設計方法
ERDを描くための表記法 (IE, Barker)
設計するたびに確信が持てない不安感
修正しようとすると、すでに絡み合ってしまった複雑な構造
機能追加 = テーブル再設計の繰り返し
体系的に学んだことのないデータモデリング
この講義では、単に「動くだけ」のテーブルではなく、
拡張可能でメンテナンスしやすいテーブル設計の方法を学びます。
顧客の要件を適切に反映したテーブルを作成するのは容易ではありません。
どのような構造が適切か、修正しやすい設計か、拡張可能な構造か…一人で判断するのは難しいものです。
検索してみても与えられた状況はすべて異なり、結局「これが正しい方法なのだろうか?」という不安ばかりが募ります。
多くの開発者の方が似たような経験をします。
プロジェクトの序盤にはテーブルを素早く作成し、開発機能を実装することに集中します。
データも少なく要件も大きくないため、すべてが順調に感じられます。
しかし、時間が経つにつれてプロジェクトが成長し、複雑さが増すと
初期に「速さだけ」を求めて作ったテーブル構造が、次第に大きな足かせとなります。
簡単な機能追加でも複数のテーブルを修正しなければならず、データの整合性の問題でバグが繰り返され
結局、「あの時ちゃんと設計していれば…」と後悔することになります。
😊
"とりあえずデータさえ入れられればいい!"
深く悩まずに設計
迅速な開発のために、必要な属性を一つのテーブルに詰め込む
データ量が少ない時は何の問題もないように見える
📉
機能を追加するたびにテーブル構造の修正が必要
同じデータが複数のテーブルに重複し、整合性の問題が発生
クエリが徐々に複雑になり、パフォーマンスが低下し始める
🚨
機能一つ追加するのに修正すべき箇所が多すぎる
必要なデータをどのテーブルから持ってくるか毎回悩む
データ不整合が頻繁に発生し、修正に多くの時間を要する
同じ機能を実装する場合でも、どのように設計するかによって結果は完全に異なります。
拡張性を考慮して設計されたテーブルは、要件が変わっても柔軟に対応できます。
反面、深く考えずに作成したテーブルは、小さな変更でも多くの修正が必要になり、予期せぬ問題が次々と発生します。
序盤ではこのような違いはあまり目立ちません。どちらも正常に動作しているように見えるからです。
しかし、時間が経つにつれて、その差は開発スピードやメンテナンスの難易度として現れます。
⭐ この講義では、拡張可能なテーブルを設計する方法を扱います。
"後で直せばいい"ではなく、"最初から正しく"作る方法を学びます。
講義を終えると、要件を見て拡張可能な構造で設計できるようになります。
📌顧客の要件📌
社内食堂では毎週の献立表を確認することができる。
献立は月曜日から金曜日まで昼食/夕食を提供し、献立ごとに
該当する献立を提供した栄養士の情報を確認できる。
献立メニューにはご飯と汁物が必須で含まれ、おかずは複数含まれる場合がある。
カロリーも管理されなければならない。
ヨーグルト、アイスクリーム、果物のような副食が出る場合もある。
👎悩みなく設計されたモデル
👍十分に検討されたモデル
単なる理論ではなく、実務ですぐに使える内容で構成
実務でよく直面する悩みと解決策の提示
図書貸出システム、ショッピングモールなど実務に近い例題を活用
データモデリングの段階を直接実践しながら学習
700ページに及ぶPPT資料で完璧な復習
要点だけをまとめた内容で概念を把握しやすい
いつでも見返せるリファレンス
特別な準備なしですぐに開始可能
紙とペンさえあれば十分、ツールは選択事項
WebベースのERD Cloudで別途インストールなしに実習
Barker表記法とIE表記法の両方を説明
講義紹介:テーブル設計の過程で、もどかしさを感じたことはありませんか?
講義で扱う内容
誰のための講義か? (Feat. DB設計を必要とする開発者と初心者モデラー)
講義の構成
講義を受講するための事前知識
業務効率と開発生産性の向上方法
データモデリングとは?
私たちはERDを管理していません
このように設計すると、後で苦労することになります
私のデータモデリング理解度の点検
クイズ1:O/X問題
クイズ2:テーブルの数を当てる
要求分析からテーブル作成までの段階
トイプロジェクトで説明するデータモデリングの段階
要求事項の分析/定義
主領域の設定
概念データモデリング
論理データモデリング
物理データモデリング
データモデリングの段階を簡素化できるだろうか?
データモデリング表記法 (Barker, IE)
データモデリングのためのBarker/IE表記法
エンティティ表記
属性の表記
識別子の表記
リレーションシップの表記
サブタイプ表記
データモデリングツール (ERwin DA# ERDCloud)
ERwin DA# ERDCloud
ERDCloud実習
エンティティとは
エンティティの概念
テーブル?エンティティ?何が違うんだろう
要件からエンティティを抽出する方法
エンティティはどうやって導出するのか?
データモデリングの核心「エンティティ抽出」
【実習】エンティティ抽出の実践
エンティティが「適切に」抽出されたか確認する
エンティティの意味を明確に付与したか
管理が必要な対象であるか
集合を成しているか
業務プロセスに依存していないか
独立性を持っているか
画面ごとにエンティティを抽出していないか
エンティティを分類すれば、どのようなデータが保存されるのかを知ることができます
エンティティにも性格がある
テーブル設計を上手に行う秘訣:性格別のエンティティ分類
エンティティ分類のメリット
属性とは
属性の概念
属性の構成要素
クエリ開発が容易になる属性分類
属性を分類する理由
基礎属性
関係属性
抽出属性/重複属性
システム属性
多くの開発者が見落としがちな特別な属性設計
特別な属性
多値属性
複合属性
排他属性
コード属性
属性の導出方法
本当に必要な属性を見つけ出す秘訣
【実習】属性導出の進め方
識別子とは
識別子の概念
識別子の特徴
識別子の分類
'OO番号'としてよく使われる人工識別子
本質識別子と人工識別子(feat.真主語と仮主語)
エンティティの性質別に主に使用される識別子
本質識別子を使おうか?人工識別子を使おうか?
識別子の選定方法
[実習] 識別子の選定手順に沿って進める
識別子選定時の注意事項
識別子に関する様々な話
何でもかんでも人工識別子にするなら?
商品番号属性の形式 (000000121 vs GOD000121 vs 121)
事例データを考える習慣
関係とは
関係の概念
関係とJoin
関係の構成要素(関係次数、関係選択性、関係名)
関係の構成要素
関係次数(1:1 / 1:M / M:N)
関係選択性(選択 / 必須)
関係名
関係を簡単に繋ぐことができる秘訣
関係線が持っている隠れた意味
従属関係
参照関係
識別関係と非識別関係
従属/参照 識別/非識別関係のまとめ
実務で直面する厄介なリレーション(多重、再帰、排他、BOM)
様々な関係
多重関係
再帰関係(=循環関係)
排他的関係(=アーク関係)
BOM関係
関係の導出方法
[実習]関係導出の実践1
[実習]リレーションシップ導出の進め方2
関係に関する様々な話
外来キー(FK)制約は必要か?(feat. うちの会社はFKを生成しません)
関係線を結ばなくてもよい場合
性能向上のためのリレーションシップ接続
サブタイプとスーパータイプ
サブタイプ/スーパータイプの概念
サブタイプ/スーパータイプの特性
どのような状況でサブタイプを使用するのか?
サブタイプを使用する理由
サブタイプを導出すべき状況
サブタイプの導出方法
[実習]サブタイプの導出をやってみる
サブタイプ導出時の注意事項
サブタイプが含まれるエンティティのテーブル作成
サブタイプが含まれるエンティティのテーブル作成パターンの3種類
タイプ1. サブタイプ構造
タイプ2. 統合テーブル構造
タイプ3. 個別テーブル構造
テーブル生成タイプの選択基準
正規化とは
正規化の概念
正規化、なぜ?すべきなのか
正規化のメリットとデメリット
第1正規化 - 重複するものを分離しよう!
第1正規形の定義
第1正規化を行わなかった時の問題点
[実習]改善してみましょうか?
第2正規化 - 識別子の全属性に完全従属するように!
第2正規化の定義
第2正規化を行わなかった時の問題点
【実習】改善してみましょうか?
第3正規化 - 非識別子属性同士に従属関係がある?
第3正規化の定義
第3正規化を行わなかった時の問題点
[実習]改善してみましょうか?
反(非)正規化とは
反正規化の概念
反正規化を行う前の必須確認事項
反正規化の長所と短所
性能改善のための反(非)正規化の方法3選
重複カラムの生成
重複テーブルの生成
テーブル分割
共通コード
共通コードとは?
コードを使用する理由
共通コード設計時の注意事項
共通コードの設計方法
[実習]共通コード設計方法 1
[実習]共通コード設計方法 2
共通コード VS 個別コード
履歴管理
履歴とは?
OOの状況では履歴管理が必須です。
[実習]履歴設計方法 1
[実習]履歴設計方法 2
学習対象は
誰でしょう?
業務領域別のDBテーブル設計を必要とする「開発者」
全体構造について悩みながらデータモデリングを行うべき「初心者モデラー」
DASP、DAP資格の取得を目指している方!
前提知識、
必要でしょうか?
SQLにおける結合(Join)の概念
Select ~ From ~ Where クエリに関する基礎知識
キャリア認証
92
受講生
9
受講レビュー
1
回答
4.8
講座評価
1
講座
こんにちは 👋
外資系企業でData Architectとして働いているArchixです。
バックエンド開発者としてスタートし、SQLP 🎖、DAP 🎖 の資格を取得してデータ専門家の道を歩むことになりました。現在は開発者の方々のデータモデル効率化やクエリチューニングを支援し、より良いデータ管理のために働いています。
多くのプロジェクトや運用を経験する中で、一つ確信したことがあります。それは、設計がしっかりしているシステムは揺るがないということです。一方で、設計が不十分なシステムは小さな問題が繰り返され、結局は不必要なリソースの浪費につながってしまいます。
開発者として働いた経験があるからこそ、このような状況を間近で経験してきました。その経験を講義に反映させ、実務ですぐに活用できる内容をお伝えしたいと考えています。
これからもデータモデリングの重要性を多方面で伝えるために、継続的に活動していく予定です。
講義をすべて受講された後、DA(データアナリスト)職務やキャリアについて気になることがあれば、「完講」の認証とともに、以下のメールアドレスまでお気軽にご連絡ください。可能な範囲でお力添えさせていただきます。
ありがとうございます。
全体
37件 ∙ (9時間 42分)
講座資料(こうぎしりょう):
全体
9件
4.8
9件の受講レビュー
受講レビュー 9
∙
平均評価 5.0
5
分かりやすく基礎を固めるのに最適です
준永さん、受講の感想をいただきありがとうございます。 モデリングの基礎概念を固めるのにお役に立てれば幸いです。 気になる内容があれば、お気軽にご質問ください。 ありがとうございます!
受講レビュー 4
∙
平均評価 5.0
5
開発者ですが、DBモデリングに興味があり受講することにしました。 就職準備の時に難解で理解できなかった概念を、分かりやすい例えと共に整理することができて良かったです。 一歩ずつ理論に続いて例を挙げてくださる説明のおかげで、理解しにくい部分も明確に理解できました :) 経験者の方々にとっては基礎的な内容かもしれませんが、一度整理するという気持ちで気楽に聞ける講義だと思います。講義のトーン自体も、落ち着いて説明してくれる親しみやすい先輩のような感じがして良かったです。 今後、先生の新しい講義が出たら、期待を持って次の講義も受講すると思います :) あ、それと完走(最後まで受講)すればキャリアの悩みも先生に相談できるのですが、私にとってはそこが完走する大きなモチベーションになりました(笑) 近いうちにメールで問い合わせさせていただきます〜!!良い講義を作ってくださりありがとうございました!
Rootree様、受講レビューありがとうございます。 おっしゃる通り、難解で理解しにくかった概念が、実務において予期せぬ変数になることがよくあります。 こうした基礎概念を明確に理解していれば、様々な状況でより正確な判断ができるようになるはずです。 詳細なレビュー、本当にありがとうございます。 追記ですが、キャリアに関するお問い合わせはメールでいただければ返信いたします。 ありがとうございます。
受講レビュー 5
∙
平均評価 4.6
5
開発中にテーブルを設計することがありますが、講義を受けて曖昧だった部分がかなり解消された気がします。 何より、間違ったテーブル設計のせいでクエリを書くのが大変だったのですが、「自分のクエリ作成能力が足りないわけではない」という言葉に救われました(泣)
曖昧だった部分が解消されて良かったです。 設計が不十分なテーブルのクエリは、特にインラインビューを多用することになり、似たようなデータが多いため、どこからデータを持ってくるべきか非常に悩みますよね。 これからは、十分に検討された、優れた設計の構造を作り上げていけるはずです! ありがとうございます。
受講レビュー 1
∙
平均評価 5.0
受講レビュー 12
∙
平均評価 5.0
同じ分野の他の講座を見てみましょう!