ちょろっと進捗：概要設計「論理データ設計」ちょろっと進捗：概要設計「論理データ設計」

これは、ちょろっと進捗管理の開発日記です。

ちょろっと進捗：導入
ちょろっと進捗：要求定義
ちょろっと進捗：概要設計「システム分割」
ちょろっと進捗：概要設計「入出力概要設計１」
ちょろっと進捗：概要設計「入出力概要設計２」

「入出力概要設計３」でフロー制御の定義を書こうかと思いましたが、めんどくさい１，２の内容でフローは把握できると思うので、書かないことにしました。
今回は論理データ設計です。

本来、入出力概要設計の次の手順は「コード設計」にあたります。
コード設計ってのは、
「システムが扱うデータに一意的な（重複の無い）記号名をつけること。」らしいですが、ぶっちゃけよくわかりません。

各エンティティの関連の為に、一意なコードを割り当てるなんて、データベース設計時に一緒にやってしまえばいいと思うんだけど・・・。
ってこどで、「コード設計」をすっ飛ばして「論理データ設計」にて、データベースの設計とコードの設計を一緒にやってしまうことにします。

データベース設計ってのは、経験をつまない事には中々きれいな物ができません。
設計手順は色々思考しながら紙に関連を表す図なんかを書き加えていって、最終的にテーブルの形にします。
主な流れとしては、データ項目を洗い出して、関連を考えた上でテーブルにする。
後はそれを正規化していく。

データベースの正規化については、書かれたページも書籍もいっぱいあるので、割愛する。
授業でもやったしね。

今回のシステムで、関連の強いいくつかのエンティティ(要素)は以下の４つ。
・メンバ
・プロジェクト
・タスク
・ジョブ

ここで、ほぼ新たに出てきたジョブについて。
ジョブとはその名のとおり役割を表す。

プロジェクトは複数のメンバを持つ、同様にメンバは複数のぷロジェクトに参加しうる。
つまり多対多の関係になるわけだが、これを表現するには間にもうひとつテーブルが必要になる。
これを「結合テーブル」もしくは「中間テーブル」と呼ぶ。
なぜもうひとつテーブルが必要かはここでは、深く説明はしません。
適当にググってくれ。

んで、ジョブエンティティはその中間テーブルなわけだけど、なんでジョブかっつーと・・・。
プロジェクトとメンバの関係は、デザイナーだとかプログラマだとかの役割で結びついています。
よって、ジョブテーブルにプロジェクトのIDとメンバのIDと役割名を入れておく。
プログラマでありながらサウンド担当とかだったら、このテーブルの行が2つあることになりますね。

役割によって纏めやすくするならば、ジョブ名テーブルを作って、ジョブIDでジョブテーブルと関連させると後々楽。
文章じゃ何かとわかりにくいので、とりあえず図にしてみる。

クリックして拡大

余計わからなくなった人が居そうで切ない(´･ω･`)
あくまでも関連を重視した図なので、各テーブル内の項目については明らかに不足してます。

後はそこまで関連の強くないテーブルがいくつかある。これを列挙していこう。
・BBS用のテーブル(スレッド・レスポンス・ボード)
・バグ管理用のテーブル(バグ・バグ進捗)
・スケジューラ(イベント)
・ファイラ(ファイル・ファイルリレーション)
・備品管理(備品・借り出し・予約)

こんなところかな？
意外と少ないね。
つっても、たぶんバグ管理だけでテーブル数は5を超える気がするけど・・・。

バグ管理の情報を参照してどうこうする部分は今のところ無いので、バグ管理機能は後で着ける方向で今はあまり触れない。
バグ管理機能だけで、1つのアプリケーションとして扱うべきくらい複雑だしね。

それはそうと、全部図にすると大変なことになった。

クリックして拡大

いちおうデータベース定義はこれをベースとします。
ただ決定稿ってわけじゃなくてベースだっつー理由は、どうせ実装中にいろいろ追加されていくだろうっつー事です。

そもそも1時間そこらで綺麗なデータベースなんて作れません。
一日かけてもそうそうまとまったデータベースになりません。
一番いいのは、プロトタイプとして同機能を持つものを作って、全体を把握してから再度設計するのが一番だけど・・・。
そんな無駄な時間つかえるわけねぇので( ´-`)ｺﾚﾃﾞ

とりあえずデータベース定義はこれで完成。
ほんとはここまでの細かい設計は内部設計の「物理データ設計」の段階でやるんだけど、分けてやるのもめんどいので( ´-`)

良い子はまねしないように。

さて、次回は内部設計「詳細設計」に入りますよ。
たぶん。