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

DB概論
スポンサーリンク

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

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

テーブル名の命名規則

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

AB001XNG
PO_HEADERS_01NG
PO_HEADERSOK

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

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

日本語NG

注文NG
TYUMONNG
PURCHASE_ORDERSOK

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

日本語の名称を使っても問題のおきないデータベースも多いです。
ですが、問題は外部のソフトです。

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

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

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

大文字で統一

purchase_orderNG
PURCHASE_ORDERSOK

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

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

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

PurchaseOrdersNG
PURCHASE-ORDERSNG
PURCHASE_ORDERSOK


慣習的に_を使っているデータベースが多いです。

データベースの関数に書式をあわせるというのも明確でいいでしょう。
Oracleでは例えば、文字列に変換する関数は「TO_CHAR」です。
その書式に合わせるという考え方です。

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

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

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

PURCHASE_ORDER_HEADERSNG
PO_HEADERSOK

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

テーブル名を見るだけでどこの業務で使われているのか見当がつき便利です。
この業務単位の分類はスキーマを使うのもいいです。
例えば 「PO.PURCHASE_HEADERS」というふうに書きます。

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

PO_REQ_HEADERSNG
PO_REQUEST_HEADERSOK

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

「モジュールの略称」をつけると矛盾しているのでは?
と感じる人は多いと思います。
一番大きな業務単位は数も少なく、よく業務で使う単語のため略しても意味が通じやすいためです。

第2カテゴリは数も多くなり、業務イメージもつかみにくくなります。
そのため、REQという風に略すると何の言葉の省略形かわからなくなってしまうためです。

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

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)項目名(OK)内容
IDPO_LINE_ID注文明細の一連番号
PO_HEADER_IDPO_HEADER_ID注文ヘッダーの明細番号
PO_LINE_NUMBERPO_LINE_NUMBER注文の明細番号

項目名(NG)を見ると、ヘッダーテーブルのIDは明細テーブルではPO_HEADER_IDという項目名になっています。
これはIDの名前が明細テーブルの主キーとして使われてしまっているからです。

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

またテーブル同士の関係性を表すER図を作成するときに、項目名が違うと自動作成できません。
そういった意味でもIDは使わないようにします。

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

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

DATE_OF_PONG
PO_DATEOK

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

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

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

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

日付のTIME型とDATE型はトラブルになりやすいので、項目名で区別できるといいです。

例えば発注日が2022年1月31日の注文があるとします。
このときプログラムで <= 2022年1月31日 として抽出したらこの注文は含まれるでしょうか?

答えはTIME型かDATE型かで結果は異なります。
TIME型の場合2022年1月31日10時23分と入っていた場合、2022年1月31日0時0分より大きいので、抽出されません。

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

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

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

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

上記の項目はデフォルトで全部のテーブルに追加します。

まとめ

項目定義書のような形でまとめると次のようになります。
規模が大きいシステムになるほど命名規則はたいせつになるので是非参考にしてください。

テーブルの命名規則

[第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

命名規則に興味がある方は「リーダブルコード」の書籍がおすすめです。

テーブルの命名規則に関係する記述は少ないですが、プロシージャなどプログラムを書くときの変数名の付け方やプログラムコードの書くときに参考になります。

プログラム全般に共通する書き方の本で、プログラマー必須と呼ばれる名著なので、興味があるかたはお読みください。

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