modeling-how-to-learn.connpass.com
こちらのイベントに参加してきたので、会の様子と感想を書いていきます。
会の概要
以下、connpassのイベントページから引用です。
入門者に向けて、テーブルを設計する上でモデリングすると良いよという話をします。（熟練者は、そうだよねーっておさらいするか、そこは別の考え方があるんじゃないなどを呟いて貰えればといった内容です）
モデリングして設計する際に、色々なモデルがあります。その中で、データモデルは静的な要素が強いモデルなので、モデリング全般を考えた際に、入門者にとって捉えやすいのではと考えています。
テーブルを設計する上で、データモデリングをしてデータモデルを作ることで、より良いテーブル構造を考えやすくなります
会の様子
超入門！テーブル設計をデータモデリングから考えよう
まずは高崎さんからこちらのテーマでお話がありました。
テーブル設計をどこから考えるか？
元々超入門だった時は、データという側面からテーブル設計を考えていたというお話でした。*1
ただ、データと一口に言っても分かりやすいデータ(変わりにくいデータ)があるよねということで、画面や帳票からデータを拾っていくのがやりやすいと考えていたそうです。
やりがちなまずいテーブル設計と改善点
まずいテーブル設計として、Excelに記載されているようなデータをそのままDBに突っ込んでしまう(Excelと同じようにカラムを作り、中にExcelのデータを入れてしまう)という例が挙がっていました。
このようなことをしてしまうと、同じデータを何回も入力してしまうことで後々修正が入る時に全置換しないといけなくなってしまうなど、保守が厳しくなるという話でした。
この改善として、データの分類(マスタデータ/トランザクションデータに分ける)や情報を種類ごとに整理するやり方が挙がっていました。
巨人ファンなので説明が頭に入りやすかったですw
RDRAやユースケースから考えるデータ構造の考え方
上記に書いた対策などで多少はデータが要件を捉えてきたもののまだよくできる余地が当然あるということで、次のステップとしてRDRAが紹介されました。
具体的にユースケース複合図を使った考え方や、ユースケースごとにデータを眺めることでデータに必要な情報がより精緻になったり*2するということです。
ただ、ユースケースを複数考えてなんでもかんでも情報をデータ構造に加えてしまうと、どんどん肥大化してしまうので、一度俯瞰をして必要に応じてデータ分割する必要性があるということでした。
また、多重度もデータ構造を考えるキーワードになるということでした。
概念モデル・論理モデル・物理モデル
概念モデル・論理モデル・物理モデルについて説明があった後、一番馴染みが薄い(書いて効果あるの？と思えてしまうモデル)であろう概念モデルについて説明がありました。
高崎さん自身もそうだったように、情報を整理する上では論理モデルさえあればいいように思えてしまうけれど、まずは概念モデルくらいの抽象度で理解を合わせることが重要だというお話でした。(よくあるのは、皆が使っている語彙が統一されていない、同じ語彙で人によって理解が違う)
ドメインモデル
ここまで紹介されてきたような概念モデル・論理モデル・物理モデルについては、データ構造をボトムアップで考えていく上では重要ですが、実際のビジネスフローを考えてRDRAに記載されているようなステップで、ドメインモデルも考えていく必要もあるということでした。
ただ、まずは取っ掛かりとしてデータモデルやデータ構造から考える方が分かりやすいので、いきなりRDRAに書いてあるようなステップに入るのではなく、ここまで述べてきたようなボトムアップでデータ構造を考えていくやり方を考えて欲しいということです。
具体化と俯瞰のフィードバックを回す
最後に今日のまとめとして、具体化と俯瞰を行ったり来たりしていく重要性が紹介されていきました。
この力を養う作業がデータモデリングであるということです！
テーブル設計の考え方とやり方【入門編】
次に、増田さんから講演がありました。なお、このタイトルの入門≠簡単だということで、基礎をしっかりやるならこのパターンは抑えておこうという趣旨だということです。
また、時間の関係上、パターンはかなり抽象的な説明が多いということでした。
データベースを利用する目的
発生した事実を記録する、記録した事実を利用するという2点がデータベースを利用する目的として紹介されていました。
追記型/更新型
設計アプローチとして、発生した事実を追記するようなイミュータブルなアプローチと、発生した事実を使って最新の状態にするミュータブルなアプローチの2種類があるということでした。
以降の内容(今日の講演)は、追記型のアプローチについてのお話だとういうことです。
中核テーブル/周辺テーブル
NN制約があり正しく記録をする(INSERTだけでUPDATEはない)中核テーブルと、中核テーブルの支援をする周辺テーブルという分類が紹介されていました。
理論的には中核テーブルさえあればいいものの、周辺テーブルがないとSQLの複雑化など実際のアプリケーションで必要になるため、周辺テーブルは実務的な存在だというお話でした。
データベースに何を記録するか？
当事者(ヒト)・規定(キメ)・当事者活動(コト)・資源(モノ)を記録するんだという分類がありました。
事実の記録
事実は全て過去形で記録されるという話や、起きたこと/約束したこと/もくろんだことを記録するというお話がありました。
起きたこと/約束したこと/もくろんだことが守れなかったり間違っていた場合も含め、データの改ざんはやってはいけないということです。
こうして記録された事実は、計算や判断のインプットとして使われたり、TODO, doinig, doneを基に処理を催促することに使われたり、予定, 実績, 差異を基に処理で発生した問題を検知するために使われるということでした。
値の記録を具体的にやる方法については、値をグルーピングして登録したり値と値の関係を考慮して記録したり、値のグルーピングを合成して決めたりするということです。
テーブル設計の基本
一意性制約と外部キー制約を組み合わせて論理的にどのようにデータを構成するかを考えるのがテーブル設計の基本ということで、その基本をどのような視点で考えていくかということが紹介されていきました。
具体的には、識別番号はなにか？・データの発生時点はいつか？・記録の目的がなにか？・データはどういう意味を持っているか？の4つの視点で考えていくということです。
こうした視点を基にして、意味を明確にすることや正確に記録をすること、テーブルとテーブルを関連づけしていくことで、テーブルの質が上がっていくということです。
なお、アンチパターンとして以下の設計の例が挙がっていました。
- 識別番号が同じだからデータを全て同じテーブルにまとめる
- 名前と実際のデータが不一致
- NN制約やUnique制約が使われていない
- データの型が適当
- データの最大値最小値が適当*3
制約を有効活用することも、良いテーブル設計には必須だということで、積極的に制約を宣言することでデータの構造が整理され、ビジネスの特徴が見えてくるということです。
設計準備
ここまで色々話してきたものの実際に手を動かさないと意味がないということで、準備として以下の準備が必要だということでした
- PostgreSQL
- IntelliJ
- schema.sqlにCREATE TABLE文を書く
- data.sqlにINSERT文を書く
逆に、テーブルを自動生成するようなスクリプトの使用は、いつまでたってもテーブル設計が上手くならない(手を動かせない)のでアンチパターンだということでした。
スキーマ名・テーブル名・列名
スキーマ名・テーブル名・列名は増田さんの場合日本語で書いているということで、SQL文自体が設計ドキュメントになることを意識されているようです。
テーブル設計における「規定」
過去だと、テーブル上にビジネスロジックとなるようなデータ構造を置いてコードがテーブルを参照するパターンもありましたが、これはコードを書いてからデプロイするまでのスピードが遅い過去の産物に近い印象を増田さんは持っているということでした。
参考情報
- PostgreSQL文書(5.データ定義, 8.データ型)
- データベース実践入門(第一章, 第7章)
- 現場で役立つシステ設計の原則(第6章)
- 楽々ERDレッスン(第2章, 付録:SQLのからくり)
座談会
外部キー制約やチェック制約など、制約をどこまでがちがちにやると現実はいいか？というお話を聴いていきました。
外部キーは高崎さんも増田さんも積極的に活用しているということですが、チェック制約は実際の現場ではそこまで活用していないということでした(ただ、データ制約をがんがん利用していくというのは増田さんの最近のアイデアだということで、今後はどんどん書いていきたいということでした)
また、追記型にすることでデータ量が増えてしまう(パフォーマンスに懸念がある)問題に対しては、ディスクはAWS S3をはじめとした技術変革のお陰で全く問題ないしその他DB結合で起きるような問題も増田さんの肌感覚では特に性能劣化につながらないということです。*4
最後に、増田さんがなぜイベントなどで継続的に学び直しをしているのか？どのように学び直しのモチベーションを保っているか？という質問が高崎さんから増田さんにありました。
増田さんは、現場で必要になった知識を、イベント登壇を通して整理し直すサイクルを回しているということで、今回のイベントも実際に現場でテーブル設計が必要になったことが理由で立ち上げたというお話でした。
全体を通した感想
Youtubeなどで何度でも見返せるように動画化して、新人やこれからテーブル設計を始める人のエントリーポイントとできるようにしたいイベントでした。(コメントも大盛り上がりでした)
現場と理想の差分を見直したり、継続的に勉強を続けていくためのロードマップが見えたりと。学びが多かったです。
