#はじめに
はじめまして。
w_shimizuといいます。絶賛風邪ひきで寝込んでいます。皆さんは体調にお気をつけて年末年始過ごして下さい。
さて、今回は急遽テーマを変更してこんな話題で、「Tech Do Advent Calendar 2018」の16日目の記事を書いてみたいと思います。
モデリングっておもしろいですよね！
アプリケーションが出来上がった後に、モデルを変えると色々な修正をしなくてはいけなくなってしまったり、一旦モデルが決まってしまうと、出来る事と出来ない事が出て来たりして、モデルが決まる事はとても影響力のある事なのだなと感じる事が多いです。
重要視されていないですが、縁の下の力持ちのような役割で、実は陰ながら作業を支配している！そんなモデリングという分野が私はとても大好きです。
一方で、これだけ大事な分野でありながら、モデリングが出来る人とアプリケーションを作れる人が並んだ時、アプリケーションを作れる人を褒めたり、お礼を言ったりする機会は多くありますが、モデリングの分野で作業をしている人が褒められたりお礼を言われたりする機会はとても少なく、軽視されがちな印象ですよね。
やった事の無い人に説明するのも中々難しい！なので、評価しようがなく、出来上がっているアプリケーションに目が向きがちなのが現実です。
かくいう私もモデリングが出来るといえるレベルではないのですが、今回は、こんな私なりにモデルが変わるとどうなっていくのか少しでも書いてモデリングの重要性をお伝えできたらと思いました。
※間違った事等を書いているかもしれません。あたたかくご指摘頂けると幸いです。
※この記事の中では、多重度の表現が出てきます。多重度についての理解がある方ではないと読む事が難しいかもしれません。予めご承知おきください。
#モデリングを説明する題材について
今回は、「会社員」というモデルについて考えてみる事にします。
#いざ、モデリング
##ステップ1
まずは、会社員というテーブル1つだけ作成して全ての要素を詰め込んで見る事にします。
ステップ1では、1つのテーブルの中に沢山の要素を詰め込んだ結果変更に弱いモデルが出来ました。
少しだけこのモデルの問題を上げると、
・データの変更に弱い
・重複したデータがとても沢山増えてしまう
などなど問題が沢山ありそうですね。
そこで、次のステップでは、「正規化」を意識してモデリングしてみたいと思います。
##ステップ2
ステップ2では、ステップ１で作成したモデルを正規化してみましょう。
ステップ2では、正規化する事でステップ１で抱えていた沢山の問題を解決する事が出来るようになりましたね。
例えば、部署名を「開発企画部 から 企画部」へと変更したいというケースを想像した場合に、ステップ１では、全ての会社員の中で、開発企画部に所属する人の部署名を企画部にする必要がありましたが、ステップ2のように正規化しておくことで、部署テーブルの開発企画部を企画部へと変更するだけで変更作業は終わりとなります。
具体的な数字を交えますが、社員が1000万人いるような会社でこんな作業が起きたという事を想像してみてください。
ステップ１の場合は、対象の部署の社員が100万人いたとすると100万人分の情報を書き換える必要がありますが、ステップ2のように管理しておけば１か所の修正で終わりですね。
モデルを正規化すると、柔軟にデータ変更に対応出来たり、重複レコードがなくなるなどとてもメリットが大きいです。
さて、ステップ2を少し変更してみるとモデルの表す意味合いが変わっていきます。
ステップ3では、モデルを少しだけ変えて大きくモデルが変わる様子を見てみましょう。
##ステップ3
ステップ2と少しだけ変えてモデルの持つ意味を変えてみましょう。
ステップ2との違いが分かりますか？
・
・・
・・・
・・・・
・・・・・
パッと見ですと分からないですが、会社員と部署の多重度が変わっていますね。多重度の説明については、少し複雑になりますので、「多重度」のキーワードで検索をしてみて下さい。
こうなるとステップ2とはまるで違うモデルになっています。
ステップ2では、会社員は1つの部署にしか所属出来ませんでしたが、ステップ3では、会社員は2つ以上の部署に所属する事が出来るようになりました。
ステップ2のモデルを活かしたまま、複数の部署に所属出来るようにする為にはどうすれば良いでしょうか？
モデルは苦しいですが、以下のようにすれば1人の会社員が複数の部署に所属する事を表現出来るかもしれません。
但し、このモデルを選択した場合は、更に追加で対応要望があった場合に柔軟に対応できるのかどうかとても考えさせられる部分があると思います。
どちらもやりたい事は実現できますね。
モデリングでは、正解が1つではない事がまた面白いなとこんな時に感じます。
人によってやり方や解決方法が変わるのがモデリングだと思います。
ベテランの人から新人の人までみんなが違うモデルをもって色々な解決方法を提案し、色々な正解が導き出される事がすごく楽しい分野ですね。
#終わりに
さて、今回は簡単にモデリングという分野について触り部分をまとめてみました。
今回書かせて頂いた内容は、私が学んだモデリングでもほんの一部でしかないですし、
私はモデリングを覚えて沢山の状況においてモデリングを実践できたわけではありません。
例えばこんな事業を想定してモデリングを行うとどうなるのか、また10年後まで動くシステムを作る為にはこのモデルで行くしかないよねとか
そんなケースでモデリングをしてみると違った視点でモデルを作る事が出来て、面白いかもしれません。
そして、今回はご紹介できませんでしたが、モデルの抽象化を利用すればアプリケーションの修正をなるべく軽微に抑える事が出来たりしますので、ぜひ試してみてください。
こんな記事でも、皆さんが少しでも興味がもてましたらぜひモデリングをしてみてはいかがでしょうか？
#お詫び
書き終わって、改めて見なおすと最初と最後にかけてのレベル差がとてもある事に気づき、とても反省しています。すみませんでした！
次回機会があれば、ちゃんと時間をかけてゆっくりと丁寧に解説出来る記事をまとめてみたいと思います。
そして、あくまで私個人の意見として書いている記事ですので、賛同出来る・出来ないなどのご意見もあるかと思いますが、個人的にご意見頂けると幸いです。
簡単では御座いますが、最後までご一読下さりありがとうございました。