データベース設計で絶対役に立つ命名規則

DB概論

命名規則は大切とわかっていてもおろそかになりがちです。
現場の人と要件ヒアリングで忙しい時に、
「この項目名は大文字にすべきか小文字にすべきか?」
という結論がでない議論をしたくないですよね。

そんな時に役に立つルールを紹介します。
命名ルールは開発時や運用時の開発コストに想像以上にかかわってきます。
命名規則はプロジェクトごとに1から作成する必要はないので、このルールをデフォルトとして、細かいところは実情にあわせて使うことをおすすめします。

テーブル名の命名規則

読んで意味のわかる名前をつける

AB001XNG
PO_HEADERS_01NG
PO_HEADERSOK

命名規則の一番大切な部分ですが、テーブル名を見て中のデータを想像できないといけません。
たまにあるのが採番台帳で番号をしてその番号を使うというものです。
これはひと目で内容がわからないのでNGです。

数字をいれてるのも内容を判別しにくいので避けてください。

日本語NG

注文NG
TYUMONNG
PURCHASE_ORDEROK

「注文書」といった日本語のテーブル名は使ってはいけません。

日本語の名称を使ってもデータベース内では問題は起きません。
ですが、問題は外部のソフトです。

データベースにアクセスするソフトに海外の製品を使うことはよくあります。
その時に日本語を使っていたら、文字コードを変換をしないといけなくいなど無用なトラブルを引き起こす可能性があります。

避けれるトラブルは事前に避けるためにも日本語は使わないでください。

ローマ字で書くのは少し恥ずかしいので、調べて英語にしましょう。

大文字で統一

purchase_orderNG
PURCHASE_ORDEROK

大文字か小文字で統一します。
「問題がでるか?」
と聞かれたら正直問題はでないです。

ですが人によって小文字だったり大文字だったりと違うと、もやもやしますよね。
ルールを決めとけば問題がでないので先に決めておきます。

単語のセパレータには_を使う

PurchaseOrderNG
PURCHASE-ORDERNG
PURCHASE_ORDEROK


慣習的に_を使う事が多いです。
関数では_を使っているためそれに合わせるのがおすすめです。

統一するのが大切で、セパレータが-だったか_だったかと考える必要がないように統一します。

PurchaseOrderという書き方は「大文字で統一」というルールに反するのでNGです。

初めにモジュールの略称をつける

PURCHASE_ORDER_HEADERSNG
PO_HEADERSOK

業務単位に大きく分類した時の、英字略称2文字をつけるのがおすすめです。
 Purchase Order(発注)の場合PO
 Account Payable(買掛)の場合AP
というように英字の頭を使った略称です。

テーブル名を見るだけでどこの業務で使われているのか見当がつき便利になります。
スキーマを分けるというのでもいいです。

第2カテゴリは単語を省略しないで書く

PO_REQ_HEADERSNG
PO_REQUEST_HEADERSOK

注文モジュール内に、発注依頼のテーブルを作成するとします。
この場合発注依頼を意味するREQUESTは略さないでそのまま使います。
省略すると意味がつかみにくくなるためです。

「モジュールの略称」をつけると矛盾しているのでは?
と感じる人は多いと思います。
ですが一番大きな業務単位はよく出て意味がつかみやすいため略したほうが効率的なためです

発注業務といったら多くの人はイメージがつくと思います。ですが発注業務の中の依頼処理と聞くとイメージできる人が少なくなります。その言葉をREQという風に略するとRequireかな?などさらにわからなくなってしまうためです。

末尾はテーブルの構造上の名前をつける

PO_INFORMATIONNG
PO_HEADERSOK
PO_LINESOK

末尾はテーブル構造の特性でつけます。

形で覚えるデータベースのテーブル設計の記事にあるようにヘッダーテーブルと明細テーブルに分けれることが多いです。
ヘッダーテーブルでしたら末尾に_HEADERS、明細テーブルでしたら末尾に_LINESをつけるとルールを決めます。

名称は複数形

PO_HEADERNG
PO_HEADERSOK

テーブル名称は複数形で書きます。ヘッダー情報が複数はいっているテーブルだからです。
海外のひとから見ると単数形だと違和感があるということなので複数形にしましょう。

項目名の命名規則

項目名の規則もテーブル名と同じです。
追加で必要なルールを書きます

IDは使わない

IDNG
PO_HEADER_IDOK

主キーで一連番号をテーブルに持たせる時にIDという名前にはしません。
PO_HEADER_IDという風に何のIDかを明確にします。

例えば注文ヘッダーと注文明細のテーブルを作るとします。

注文ヘッダテーブル

項目名(NG)項目名(OK)内容
IDPO_HEADER_ID注文の一連番号
PO_NUMBERPO_NUMBER注文番号

注文明細テーブル

項目名(NG)内容
IDPO_LINE_ID注文明細の一連番号
PO_HEADER_IDPO_HEADER_ID注文ヘッダーの明細番号
PO_LINE_NUMBERPO_LINE_NUMBER注文の明細番号

これを見てわかると思いますが、IDの項目名を使うと明細テーブルにヘッダーテーブルのIDを使う時に被ってしまうため違う名前をつけ直さないといけません。

ヘッダーテーブルではIDと呼ぶが明細テーブルではPO_HEADER_IDと呼ぶというと混乱します。
ですのでIDの名前は使わないでください。

IDはテーブル名にあわせるとわかりやすいです。
英字は単数形を使います。
NG: PO_HEADERS_ID

項目名の末尾のルールを決める

DATE_OF_PONG
PO_DATEOK

末尾のルールを決めます。
あまり細かく作ると不便になるので次の3つぐらいを基本にします。

例)
 ・_DATE : 日付型の場合はDATEを使う

 ・_TIME: 時間が必要な場合はTIMEを使う

 ・_ID:連番の意味を持たない一意の番号にはIDをつける

 

システム上の共有定義項目は名前を統一して使う

業務の項目とは違う、システム上の項目は統一の名前を使い区別します。

例えばデータを作成した日付や作成者の情報です。

CREATION_TIME作成日時
UPDATE_TIME更新日時
CREATED_BY作成者
UPDATED_BY更新者

上記の項目はデフォルトで全部のテーブルに追加します。
これらの項目は注文書の作成日といった業務上の定義の項目とかぶらないようにします。

注文書の作成日の項目にはCREATION_TIMEを使わないという意味です。

まとめ

項目定義書のような形でまとめると次のようになります。

規模が大きいシステムになるほど命名規則はたいせつになってきますので、是非参考にしてください。

テーブルの命名規則

[第1パラメータ] _ [第2パラメータ] _ [第3パラメータ]

パラメター定義サンプル
第1パラメータ業務上の分類の英字略称2文字を使うPO: 注文業務 Purchase Order
SO: 発注業務 Sales Order
AR: 売掛業務 Account Receivable
第2パラメータテーブルの内容がわかる英語名称を入力する
第3パラメータシステム上の分類を書くHEAERS: ヘッダー
LINES:明細

項目の命名規則

定義サンプル
文末文字の規則日付型:_DATE
時間型:_TIME
一意のシステム番号: _ID
予約項目名一覧CREATION_TIME
UPDATE_TIME
CREATED_BY
UPDATED_BY

BI技術者必見!! データベース概論

タイトルとURLをコピーしました
Close Bitnami banner
Bitnami