忘備録とマイルストーン

WEBエンジニアを目指す20代男性の奮闘記

プログラミング初心者がWEBサービスを作ってみる―サイト設計編②

目下迷走を続けるサイト設計。しかしRubyコミュニティへの参加が僕(とサイト設計)の運命を大きく変える。現役のRubyistの方々のアドバイスを受けたことで、先の見えないER図作成に一筋の光が差し込んだのだった。

 

 

まずはサービスの内容を確認 

全てはこの会話から始まった。(エ=エンジニアの方々)

エ「これって何をするサービスなの?」

僕「サッカーの選手採点ができるサービスですね」

 「用意された試合情報を選択すれば出場選手の採点ができるようになってます」

エ「じゃあgamesテーブルが必要なんじゃない?」

僕「あっ…(いろいろ悟る)」

もう一度よくこのデータベース図を見て欲しい。 

ごちゃごちゃしていて非常に見づらいとは思うが、お分かりいただけただろうか。試合情報と登録選手情報がごちゃごちゃなのである。

さらに1つのline_ups間違えて_を入れているのは秘密)に総勢25ものplayerカラムが並ぶというカオスさ。

そして何よりも見づらい。各テーブルで何を管理するのかがよく整理できていないのがバレバレである。

 

MVPを考えよう

とりあえず何から手を付けていいか途方に暮れてしまった僕に、またまた助け舟が差し出される。

エ「まずはMVPから考えてみようか。MVPって知ってる?」

僕「Most Victorious Playerですよね、今回はMOTMにしてます(噛み合ってない)」

uxmilk.jp

Minimum Viable Productのことである。もう一度言おう、Minimum Viable Productである。要は必要最小限の機能から作りましょう、残りは+α(Out of MVP)としておきましょう、ということだ。

今回のWEBサービスの場合、①チーム・選手の情報を入力する機能・②試合情報を入力する機能・③選手採点をする機能、の3つさえあればサービスは稼働する。さらにいえば、あらかじめ対象試合を限定することで、①・②の機能を制限して稼働することもできる。

(今回は日本代表の直近の2試合{vsコロンビア・vsボリビア}に限り、初期データとして実装することにした)

 

テーブル設計のやり直し

MVPを考えたところで、①②③の機能に必要なテーブルを考えていく。

①チーム・選手の情報を入力する機能→teams ⊃ playersテーブル

②試合情報を入力する機能→matchesテーブル

③選手採点をする機能→ratingsテーブル

そして各テーブルの関係を考えていく。

  • teams(親), players(子)の親子関係
  • matchesテーブルにhome, awayのカラムを作ってteam_idを対応させる
  • ratingsテーブルにはplayer_idのカラムを加え、選手一人一人の採点情報を保存

ここで全てのチーム所属選手が出場登録選手ではないことに気付き(いわゆるベンチ外の選手が存在する)、試合ごとの出場登録選手を保存するlineupsテーブルも作成することにする。

試合そのものに関する情報はmatchesテーブル、出場登録選手に関する情報はlineupsテーブルと役割分担もはっきりさせる。 

 

正規化はとても大事

アドバイスの中で何度か耳にしたのが”正規化”というワード。本来は第1~5正規系まであるらしいが、理解が及ぶ and 実際にできるのは第3正規系までだろうか。

 

qiita.com

  • 第2正規系=部分関数従属が無い:テーブル内で他のカラムと従属関係にあるカラムものがないかチェック→あればテーブルを分割
  • 第3正規系=推移関数従属性が無い:テーブル内で他のカラムから情報を得られるカラムがないかチェック→あればテーブルを分割

もう一度チェックしてみる。今の所問題はなさそうかな…?

 

次回予告

数多の試練を乗り越え、何とか突破したサイト設計。しかし次に待ち受けるのはほとんど忘れかけているRuby on Rails。かすかな記憶(とgoogle)を頼りに、次回忘却のアプリ開発編①に続く。

((毎回やるのかこれ…))