日常のことばを切り出しながら前に進んでいる。いくつかのフレーズを単語ごとに区切り、その意味を考え続けている。そうやって暮らしていくとこの日々の目的を参照できる気がしているが、まったくそんなことはない。職場のひとがひとりまたひとりと去っていくと、悲しい。と同時に羨ましい。私の人生はここで続く。
フィヨルドブートキャンプのプラクティスを粛々とこなしている。データベース設計の項目に入り、「楽々ERDレッスン」という書籍を購入した。今まで設計自体の本は買ってなかったのだが、わりと良い本だった。書かれたのはいまから十五年以上前だが、古さを感じさせない。技術の根底にあるものを記述しているからか。設計というのは根本の知識なのだろうね。
本の構成はDB設計とRDBMSについて論じた後、具体例を用いてDBを設計していく、というものだ。RDBMS総論の内容は私にはまだ早いもので、全てを理解するのは難しかった。これは実務で学んでから読み返すと、「あぁ！あのことねー」となるだろうから今は記憶にだけ留めておく。
データベース設計の要点となるのは、「One Fact in One Place」です。この「1つの事実は1つの場所のみ存在する」ということを徹底していくのが基本となります。
楽々ERDレッスン 羽生章洋 翔泳社 p8
この「One Fact in One Place」を体現するのが正規化である。そして正規化をやっていこう、と進めていく。だが、それだけではない。事実とはデータにあるのではなく、実務・実作業において存在する。だから単純に帳票の項目をデータに落とし込めばいいのではなく、業務理解が必要だ。ユーザーに聞け。「実際に要件と仕様をまとめてくれないと設計できません」じゃぁダメだ。
かくして業務要件とプログラム仕様とデータベース設計が三すくみの状態となってしまい、プロジェクトの進捗が硬直化していきかねなくなります。このような事態に陥らないために、データベース設計の担当者が業務要件やビジネスモデルを理解すべきです。
（中略）
積極的に業務要件を拾いに行ってください。楽々ERDレッスン 羽生章洋 翔泳社 p27
設計の段階でユーザーが使う単語の意味を理解し、ユースケースを打ち合わせ、データテーブルに落とし込む。そういった努力によって、後のプログラム作成がスムーズに進む。まさに後工程はお客様、である。
DB設計に正解はなく、方法もひとつではないかもしれない。でもスタンスとしては顧客に寄り添って設計するというのがいいのだろう。
