作って学ぶはじめてのテーブル設計 に参加してみた

Learning Topics 編集部

今回の研修参加レポートは 作って学ぶはじめてのテーブル設計 です！

データベース設計というと、正規化ガガー、モデルを書いてー、と敷居が高く感じられますが、坂井さんらしいとても馴染みやすい言葉で設計のステップを解説いただけました!

またよくある、論理設計/概念設計といったフェーズで分けた解説ではなく、テーブルというなじみのある題材にしたことも、直感的に学べたように思います。

これからアプリケーションエンジニアとしてDB設計をはじめようという方には、進め方やスキルの鍛え方がわかる内容になっています!

では、どんな内容だったのかレポートします！

コース情報

講師紹介

講師は以前にレポートした「データベース超入門」でも登壇された 坂井 恵 さんです。

坂井 恵

たとえ話を交えながら、本質となる部分をしっかりと理解してもらうスタイルが特徴。本業では、データベース技術を中心にした社内システムの提案やコンサルティングを手掛ける。データベーススペシャリスト。
有限会社アートライ代表取締役。日本MySQLユーザ会副代表。

「笑顔にしたい」という思いが、こういった研修コースにも表れていますね。

今日の目標

• データベースとは何かを、もっかい復習
• テーブル設計ってどうやって進めるの?
• 様々なケースで体験してみましょう

テーブル設計ってなに?

つまり正解がないため、 10 人いれば 10 通りの設計が出来てしまいます。
例えば、原理主義と現実主義の食い違いなどはよく起こりがちです。

なので、なぜこの設計にしたのか、というのを説明できるように、自分で考えることが重要です。

RDBMS 上に “要件” を実現できるテーブルを作る、ということがテーブル設計の目的です。
ということは、この要件をしっかりと把握するということが、まず必要です。

なので要件が変われば、もちろんテーブルも変わります。

要件、つまり現実世界のルールはこのコースでは扱わないけど、とても密接なので、勉強しましょう。
坂井さんもはじめての業務･業種をやるときは、漫画のような本、教科書のような本、わかりやすい本の3冊は読んでいるとのことでした。

RDBMS の復習

前回「データベース超入門」でも出てきたスキル一覧ですが、テーブル設計をするには ↓ の 2 つが必要です。

• SQL は必須
• ( 1 テーブル何億レコードといった大規模なシステムを扱う場合は) パフォーマンス

特に SQL が重要で、このあと講義で身をもって知ることになりました。

また補足として、このすべての知識を理解できれば、トラブル対応が出来るようになるとのことでした。
確かにトラブル発生時に症状やログから何が起こっていて、どう切り分けて、どう復旧するのか、判断のスピードと正確さが求められるので、すべての知識が必要ですね。

テーブル設計の目的

「つかいやすい」を明確に定義されたので、わかりやすく、また SQL が分かってないと出来ないことが多いことに気付けました。

当たり前ですが、出来上がったデーブルをもとに SQL で操作するので、データの取り出しやすさや更新のしやすさ、またパフォーマンスもクエリによっては時間がかかってしまうので、 SQL を十分に知らずして、テーブル設計は出来ないというのが理解できます。

また、テーブルを作っているうちに正解が無いために迷ったり悩んだりするので、まず「データが壊れない」という RDBMS の原点に立ち返ると良いとのアドバイスも頂きました。

どうやって設計するのか

どのようなテーブルを作るべきなのか理解したところで、設計の進め方を解説していただきました。

情報を整理する「洗い出す」

• ユーザーが考える要件は漏れるので、想像力は重要
• 何を洗い出すのか
  • “注文内容” のような大きなデータのカタマリ。商品マスタなどは後で考える
  • どういうシーンで使われるデータなのか考える ex. ‘商品検索’ ‘注文確認’
• 100 % の完成度は目指さず、ユーザーに何回も確認しながら進めることが重要

洗い出した情報を「整理する」

• データのカタマリに名前をつけて、おおざっぱに型を考えておく
• 文字列なのか数字なのか日付なのか、その他
• ここでも厳密に使用する RDBMS を意識せず、あくまで大雑把に整理する

テーブルのイメージができたら「シミュレーションする」

• 実際に書く SQL をイメージして、追加、更新、削除、検索で考えてみる

テーブルを作りながら「ブラッシュアップする」

• パフォーマンスを検討する
• データ件数や増加率がどれぐらいか
• 更新頻度はどれぐらいか

実際にテーブル設計を体験してみよう

設計の進め方がわかったところで、ゼロからどのようにテーブル設計を考えるのか、通販システム を例に進めます。

また、予め坂井さんが用意した SUMO (相撲力士データベース) をもとに SQL 操作して、必要な SQL 操作や現状の設計の問題点を考えます。

必要な SQL の基礎知識を確認

用意いただいた SUMO のデータベースをもとに、幾つかのテーブルを結合する JOIN をやってみました。

なぜ JOIN からやったのかというと、テーブル設計ではテーブルを分割することが多く、それをどう分割前に戻すのか必要だからです。

また、ここでググってやるのでは遅く、テーブルを見たらスグに実行できるほどに SQL に習熟している必要があるとのことでした。なお、私はググって Qiita を見ていました。。 まだ設計レベルにありません。

通販システム を題材にテーブル設計する

洗い出す

ざっと登場するものを 大きく 考えることがポイントです。
洗い出しのコツは、

• アウトプットに注目する
  • 帳票や画面を見る
• ユーザーがいるならどんどん聞いたほうがよい

その上で、洗い出したテーブルをザッと書いてみます。(それが上のスライドです)

整理する

洗い出したテーブルをもとに、問題点を考えて、テーブルを分割します。また、そのテーブルに名前をつけ、カラムの型をざっくり決めます。

このテーブルの問題を考えながら、解決していきます。

1. (問題) 注文テーブルをみると、1回の注文で1個しか注文できない
2. (解決) 注文番号を複数にして、商品を注文できるようにする
3. (問題) 複数の注文番号に対して、送付先住所が2つある
4. (解決) 注文テーブルを 注文ヘッダ と 注文明細 でテーブルを分けてみる

このように実際のデータを想定して、整理を繰り返します。

この整理の段階で、テーブル名をつけるのですが、その注意点も教えてもらいました。

• RDBMSは海外製がほとんどマルチバイト文字に対応していない
  • とはいえ、いま RDBMS でマルチバイト対応が進んでいて、 emoji が使われるようになって復権している
  • - (ハイフン) はマイナスと判断されちゃうのでダメ
• ホモニム: 同じものには同じ名前をつけるんだよ
  • 商品 items というテーブルを作ったら、他のテーブルで商品のカラムを使うときに product とか使わない
• シノニム: 複数のテーブルには同じカラム名はつけない
  • 商品と顧客というテーブルを考えたときに、 name というカラムを双方のテーブルにあるとややこしい
  • client_name とか product_name とかにしよう

ちなみに、エンジニアに聞くと、 Web アプリケーションフレームワークの OR マッパーでもお作法があるので、この注意点がハマらないときもあるそうです。

シミュレーション and ブラッシュアップする

実際に作ったテーブルをもとに、シミュレーションとブラッシュアップを繰り返します。

また忘れがちなポイントとして ↓ を注意点として挙げていただきました。

• 時間の流れがあるデータもある
  • 例えば、150円の商品が160円に変わった場合、過去の注文明細が変わってしまう
• NULL は慎重に扱うようにする
  • JOINしたときに NULL があると予期せぬ結果を招くことがある

null は難しいポイントですね。

現実世界では入力フォームの全項目にユーザーが入力する、ということは難しいので、とっても工夫をしないと大変です。

テーブル設計の経験数を増やすコツ

最後に、テーブル設計は経験によってスキルが磨かれるので、その経験数を増やすコツを教えてもらいました。

• いろいろなレシートや伝票から設計する
  • 実はコンビニエンスストアごとに出力項目が違う
  • ドラッグストアとコンビニエンスストアでも、もちろん項目が違う

普段の生活の中で、とっても馴染みやすい思考訓練ですね。

最後に、実際に坂井さんが最近経験された失敗事例を教えてもらいました。

その失敗とは、設計そのものではなく、要件を真に受けすぎ、 100 回やって 1 回ぐらいしか検索しない要件をそのまま実装してしまい、パフォーマンスが落ちてしまったそうです。
坂井さんでもお客様の要件を理解する、ということは難しいものなので、とにかく要件を想像する、確認するというのは重要なことなのですね。

まとめ

テーブル設計とは何を目的に、どのように進めるのか、サンプルのシステムをもとに演習して理解しました。

モデルや正規化といった言葉は使わず、テーブルという馴染みのあるもので、データベース設計を学びました。

また設計の進め方も、「洗い出す」「整理する」など、とてもわかりやすい言葉で表現されていたので、どう進めるのか、とてもイメージしやすくなりました。

私自身、まだまだSQL操作に慣れる必要があるので、まずこれからですが、普段の生活でもレシートを見るということでも鍛えていきたいと思います。

データベース設計やアプリケーション設計にこれから携わるという方には、必要なスキルや見通しがとても良くなるのでオススメです!

label SE カレッジの無料見学、資料請求などお問い合わせはこちらから!!

Learning Topics 編集部

SEプラスにしかないコンテンツや、研修サービスの運営情報を発信しています。