業務用 Web システムの設計・開発手法

ユーザーマスターの作り方は?

ユーザーマスターの作り方は?

業務用 Web システムにおけるユーザーを登録するためのユーザーマスターの作り方(設計・構築手法)をご紹介いたします。

※参考サイトは最下部にまとめております。

要件定義

業務用 Web システムの1つの機能を設計する際には、まず要件定義から始めます。
ユーザーマスターを設計する際の要件定義は(ざっくりとですが)以下の通りです。

  • ユーザー情報を登録できること
  • 登録したユーザー情報を一覧表示できること
  • 登録したユーザーのうち、不要になったユーザー情報を削除できること

データベース定義

次にデータベースを定義します。
データベースにユーザーマスターデータを登録できるようにするためには、ユーザーマスター登録用のテーブルを1つ作成/用意する必要があります。

名前付け規約

当社では、データベースのテーブルにはすべてプレフィックスをつけるようにしています。

マスターテーブルのプレフィックスは “Mst” トランザクションテーブルのプリフィックスは “Trn” を付けるとすると、ユーザーマスターのテーブル名は “MstUser” となります。

なぜプレフィックスを付けるのか?という理由についてですが、いくつかの理由がありますが、最も大きい理由としては、もしプレフィックスを付けずに テーブル名を “User” と定義してしまうと … 仮にユーザマスターを改修しようと ユーザーマスターを操作しているソースコードを検索・抽出しようとした場合に、ユーザーマスターテーブル以外のテーブルに定義された(例えば inner join のために定義されたトランザクションテーブルの “UserID” など)”User” という単語をすべて検索・抽出してしまい … 結果として、目的のソースコードの抽出が非常にしづらくなってしまい、、、プログラムの改修作業が困難を極めてしまいます、、(こういった設計/改修を繰り返すと…おそらくプロジェクトは頓挫し 炎上してしまうと思われます)。

従って、わざわざプレフィックスを付けてテーブル名を定義することは、一見遠回りなようですが、ユーザマスターにアクセスしているソースコードを一発で検索・抽出することができ、バグの削減と 長期のシステム運用/機能改修に 非常に効力を発揮してきます。

フィールド定義

次にユーザマスターテーブルに必要なフィールドを定義していきます。

当社ではフィールドを定義する際の名前付け規約として「テーブル名」+「意味」のルールで「フィールド名」を定義しております。

例えば、ユーザー名を定義するときは「テーブル名 : User」+「意味 : Name」=「UserName」となります。

すべてのフィールド名の先頭に「テーブル名 : User」を付けていくことも面倒なように感じられるかもしれませんが、その理由としては ソースコード内(システム内)で重複することのない一意に求められるフィールド名を定義することができるからです。

これについてもテーブル名のプレフィックスを付けるのと ほぼ同じ意味で、例えば 任意のテーブルの特定の1フィールドのデータ処理が どのプログラムソースで処理されているか?を一発で検索することができます。これに関しても、不具合の数を減らすことに役立ってきます。

(逆に言えば、同一フィールド名がシステム内(データベース内)にいくつも定義されているとすると…なんらかの障害が発生したときに、どのソースを修正すれば良いか?!ただ混乱して時間が過ぎてしまう…ようなことになりかねません。このあたりを手間暇かけて丁寧に設計し構築していくことは、一つのシステムを長期に渡って安定的に運用させるために非常に大切な考え方です。もちろん、バージョンアップ/改修する際にも シンプルに作業を進め システムを積み上げていくことも可能になります。)

UserID

1つのテーブルを作成すると、必ずプライマリーキーとして「テーブル名 + ID」の名前を付けたフィールドを最初に用意します。このフィールドは、ID で特定のレコードを検索する場合や inner join でテーブル間を結びつける時に必ず必要になり、絶対必須の 最も重要なフィールドです。

UserIsTrash

UserIsTrash と言うのは、日本語で言うと「ゴミ箱フラグ」と言う意味のフィールドです。つまり、そのレコードが削除された(ゴミ箱に入れられた)場合にフラグを立てて管理するためのフィールドです。
データ型は tinyint(1) / bit 型で定義しておけば十分ですが、当社では tinyint(1) 型のデータ型は「テーブル名 Is 〇〇◯」と「Is」でつないだ名前を付ける事にしているので、このような名前になります。

※例. UserIsCorp … 法人フラグ

UserAddTime, UserUpdateTime

UserAddTime は “追加日時”、UserUpdateTime は “更新日時” を保存するために用意しておきます。

UserAddTime はデータを新規登録順に並べ変える場合に、UserUpdateTime はデータを更新順に並べ変える場合に必要となる他、システムを管理運営する中で、なんらかのトラブルが生じた場合などに そのデータがいつ登録されたのか/誰かが更新したのではないか?などのチェック時にも非常に効力を発揮します。

UserName 他

その他には「名前」を保存するための “UserName” や、ステータスを保存するための “UserStatus” など、システムの要件定義に対して 必要なフィールドを用意していきます。

まとめ

ユーザーマスターを作るには、上記のような要件定義、データベース定義をしたあとで 実際のプログラムのコーディング作業にうつることになります。

参考サイト

業務用 Web システムの設計・開発手法は?
https://blog.soln-sns.net/how-to-develop-a-web-erp-system/

COMMENT

メールアドレスが公開されることはありません。