Oracle® 非公式 SQL, PL/SQL & DBA's リファレンス

ネーミングルールとネーム辞書

オブジェクト名、カラム名は英語だったりローマ字だったり, その混在だったりして精神衛生上に悪いことがある。 そこでいくつかのルールを設けて運用すれば、少しでも改善することができる。

注意 ここに書いてあるルールは、独自に決めたマイルールです。Oracle に関連ドキュメントがある、あるいは書籍で紹介されているなどのように、一般的に定着している、知れ渡っている類のものではありません。よって強要するような正当性もありません。 ( 何より、このドキュメントに対して他人への説得材料や根拠としてのバリューを求めてはいけません。 )

Oracle 12c R2 から識別子に使用できる文字列長が 30 バイトから 128 バイトに拡張されているので無償で使える環境にまで広がれば柔軟に対応。

スキーマオブジェクトのネーミングルール(※ マイルール)

• 完全に一意のオブジェクト名とする

異なるネームスペースにおいても同じ名前のオブジェクトは作成しない。

同じネームスペースでは同一名のオブジェクトを作成できないが
異なるネームスペースにおいて可能(テーブル名とプライマリキーなど)

• オラクルの予約語は使用しない。*1(予約語を含む名前は問題なし)

日本語名称の使用

原則的にスキーマの名称に日本語は使用しない。日本語を使用したい場合にはビューで局所的に対応する。
参考: スキーマやカラム名に日本語をお勧めしない主な理由

ビューで日本語を使用する場合でも、アルファベットと数字には全角文字を使用しない。

"カラム名ABC01"       (OK)
"カラム名ＡＢＣ０１"  (NG)

• ローマ字表記の日本語

  原則、カラム名は英語の単語で組み立てる。ローマ字表記の日本語は消極的に採用(※)する。
  エンティティのメタデータの管理の位置付けにおいて、用語の正規化(≠DBの正規化)をおこないエンドーユーザと調整する。 この作業で多くの用語はローマ字表記しなくてよい状態になる。
  しかし、会社固有のネーミングが残り、それを無理に英単語で構成すると、業務担当者も聞きなれない新用語の登場になってしまう。
  

(※) 無理矢理、すべてを英単語化するのは、自然な? ローマ字を付けることより好ましくない。

• 関連事項
  ⇒ 引用符と引用識別子

インスタンス名

• SIDは 4 CHAR以内*2(Oracleの上限は 8 CHAR:引用識別子の使用不可)

データファイル

• データファイル名は拡張子を含め 30 バイト以内*3

テーブル

• テーブル名は アルファベット、アンダーバー、アンダースコア(_)と数字。
  ドルマーク($)、番号記号(#)を含む表はシステムの内部表を連想させるので通常使用しない。
• テーブル名は 25 CHAR以内*4
  

キー

• プライマリキー名は テーブル名 + '_PK'
• キー名は 30 CHAR 以内

インデックス

• インデックス名は テーブル名 + '_' + 第1インデックスカラム名の最初の1CHAR + '_IX[n]'
• インデックス名は テーブル名 + '_' + 第1インデックスカラム名 + '_IX[n]'
• インデックス名は テーブル名 + '_' + 'IXnn' *5

  状況にあわせて「いずれか1つ」を全体に適用する

• インデックス名は 30 CHAR 以内

カラム

• カラム名は アルファベット、アンダーバー、アンダースコア(_)と数字
• カラム名は 30 CHAR以内 (Oracleの上限は 30 バイト (※))

(※) マニュアルに識別子は 30 文字以内と書かれているが SJIS、EUC 環境においては上限は 30 バイトである。
Oracle 12c R2 から 識別子に使用できる文字列長が 30 バイトから 128 バイトに拡張されている。（再）

注意 このあたりからはコーディングに対する規約にも影響するため、内部でも意見が分かれることがあるかもしれないので強引だと思われないことが重要です。…プロジェクトの雰囲気を見つつ適切に処理する。(持論を展開して譲らない人がいる場合には、以下のリスク内容を伝えるだけにしておきましょう)

• カラム名の大文字、小文字

大文字(または、引用符なしの小文字)のみを使用し、区切りはアンダーバー、アンダースコア(_)を使用する
但し、小文字に慣れて運用していると、オブジェクト名を文字列として扱うプロシージャもあるため注意する。*6

例) 取引先コード  VENDOR_CD, vendor_cd

• 大文字小文字による意味づけ(区切り)は使用しない

大文字小文字による意味づけにはカラム名を短くできる、開発言語と規約が一致して見た目が美しいなどのメリットがある。 しかし、ディクショナリには通常、大文字に変換された結果が格納されるので、(DESC コマンドなどで)定義を取り出すと大文字小文字の意味がない。組み合わせによっては単語の区切りを見失ってしまうため非常に見難くなる。 さらに SQL ではプログラマ毎に大文字小文字の扱いに誤解*7があっても、それをプログラマに気付かせて修正させることもできない*8などのデメリットがある。

例) 取引先コード  "VendorCode" , VendorCode 

注意 10gのオプティマイザでも、SQLの大文字小文字でも異なると同一アプリケーションコードと見なされない
タブ数、空白の数、コメントの違いによっても異なるハッシュ値をもつ。

• 関連事項 CURSOR_SHARING 初期化パラメータ

• ドメイン(データドメイン)による使い分け

異なるドメインに同じ名称は使用しない
また一般的なカラム名の修飾になるものは、それ単独で使用しない(ID/CODE/NAME/etc)

例) 商品コード(異なるドメイン)
    自社用商品コード ITEM_CD
    取引先商品コード VENDOR_ITEM_CD

• 前置詞(後置詞)を使用した形で使用する

例) 作成者  CREATED_BY (わざと CREATOR などにしない )
    作成日  CREATED_ON
    完了済  IS_COMPLETED { YES(1) / NO(0) }

注意 これは、強引に変換を行うものではなく、
CREATOR,VISITOR,〜OR などは 業務上の「予約語」として使われていることがあるので、それと混同させないためのもの。

• ネーミングに属性を反映しない(する/しないは自由、一貫性が必要)

反映する例)
    作成日  D_CREATED   (先頭の'D' = DATE型)
    注文数  N_ORDER_NUM (NUMBER 型)

反映しない例)
    作成日  CREATED_ON
    注文数  ORDER_NUM

---

ネーミング辞書

ネーミング 辞書(問題があるかもしれないので一般的な名称のみ)

• 修飾語
• ネーミング辞書/あ行
• ネーミング辞書/か行
• ネーミング辞書/さ行
• ネーミング辞書/た、な行
• ネーミング辞書/は、ま、や行
• ネーミング辞書/ら行
• オラクルの予約語