こんにちは、かっつです。
今回は、2024年2月10日(土)に開催しました『SQLスキルアップ勉強会（DB設計編）』について、
色々と語りたいと思います。
懲りずに２回目
前回は１１月に『初めて』勉強会を開催しました。
↓↓↓その模様はこちら↓↓↓
『SQLスキルアップ勉強会』開催レポ（※最後に告知あり）【Agent Grow Advent Calendar 2023：8日目】
『SQL』をテーマにしたはずなのに、気付けば『設計』『要件定義』に話がそれてしまいました。
そして『結局、最終的には業務要件！』の迷言で終わらせるという、散々な結果となりました。
今回はタイトルを『ＤＢ設計編』とし、初めから上流工程寄りの話をするつもりで開催しました。
内容紹介
実際の資料を一部ご紹介します。
ここまでは、まだ『業務要件！』とは言っていないです。
そして、以下のスライドは私の経験に基づく『DB設計って楽しいよ（？！）』を表現したものです。
参加者の皆様が、様々な分野のエンジニアであることを想定し『開発でもインフラでも、少なからず関係はある』というアプローチをしたかったのです。
そして『難しさ』のところで『業務要件！』と言いたそうな感じがしています。
さて、私はどこまで業務要件に逸れず話が出来るのでしょうか？ｗ
テーマ１：ER図
基礎的なところから、クイズ形式にしました。
また、似ているものとしてUMLのクラス図との違いについても、クイズ形式の後に解説しました。
テーマ２：多重度
この辺からもう、嫌な予感がします。
ただ、そうは言っても設計に重要なことを説明しています。
以下のスライドでは、ちょっと意地の悪いクイズが入っています。
『〇〇が〇〇しない。その理由は何か？』分かりますか？
解答例はこちら↓↓↓（※色を反転させると見えます）
◆『〇〇が〇〇しない』の解答例
・『業務が成立しない。』
◆理由
・解答例１：販売明細に同一の品目を複数件登録することができないから。
・解答例２：品目マスタの品目コードに一意制約が設定されていない場合、品目マスタの品目コード１つに対して複数件登録された場合、販売明細１件に対して品目マスタが複数件結び付くことで、SQL実行時にレコード重複（販売金額の多重計上）が発生するから。
如何でしたでしょうか？
ただ、ここではクイズを当てることが目的ではありません。
『このER図はダメだよね』と、一瞬で判断出来る目を養って欲しいという想いで作っています。
テーマ３：正規化
このパートでは、出だしから『業務要件！』が出てしまいました。
とはいえ、実際の業務ではよくあるボトムアップアプローチの開発案件を例にしています。
まずは『何正規形』か、そして問題点は何かを考えてもらいました。
そして、段階的に正規化する手順を説明しました。
ただ、用意したデータがあまりよろしくなく、完成した第３正規形のテーブル群は実際の業務には使えないものになってしまったのですが、正規化の説明としては辛うじて成立したと思います。
今回は、非正規形～第３正規形について『現場目線』で説明しました。
教科書通りの説明であれば、書籍やネットでいくらでも調べられるので『だから、こうなんだよ』というのが伝われば良いなと思い、敢えて教科書通りの表現を避けました。
それに加えてアンチテーゼ的な観点についても考えてもらいました。
ここでは『逆正規化』『データマート』について説明しました。
ずっと論理的な設計の話をしていたのに、ここで急にメモリとかUIのレスポンス、バッチウィンドウなど物理面の話が出たので『するい！』と思った方もいるかもしれません。
そして例によって、私の口癖『業務要件！！業務要件！！』全開でした。
※参加者の皆様、ごめんなさいm(_ _)m
所感・反省
結局、私は皆さんに何を伝えたいのか？
それがまだ明確でないのではないかと思います。
SQLと言いながらDB設計、そしてDB設計と言いながら基本設計や要件定義へと脱線するパターンが多いです。
もしかしたら『業務システムの上流工程』という括りで開催した方が良いのかもしれません。
ただ、脱線が癖になってしまっているので、そうしたらそうしたでどこかに脱線しそうです。
どなたか『勉強会を上手く開催するための勉強会』を開催して頂けたら、是非参加させて頂きたいです。
まだまだ自分自身が勉強させて頂く身なのだと、改めて実感しました。
今後も懲りずに開催しますので、皆様も懲りずにご協力頂けたら、とても有難いです。
よろしくお願いしますm(_ _)m
今回は以上です。
ここまでお付き合い頂き、ありがとうございましたm(_ _)m
