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

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

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

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

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

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

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

日本語名称の使用

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

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

"カラム名ABC01"       (OK)
"カラム名ABC01"  (NG)
  • ローマ字表記の日本語

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

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

インスタンス名

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

データファイル

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

テーブル

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

キー

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

インデックス

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

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

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

カラム

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

(※) マニュアルに識別子は 30 文字以内と書かれているが SJIS、EUC 環境においては上限は 30 バイトである。 UFT8 環境は未確認

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

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

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


ネーミング辞書

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

日本オラクル
■ 日本オラクル 株式会社
■ オラクルマスター資格 (オラクルマスターとは
■ Oracle のライセンスがわからない…
Oracle Direct (ネットで聞いても最後はここで要確認)

*1 二重引用符(")を付けると"ROWID"以外なら使用できる
*2 旧 Windows 互換での制限の名残り
*3 Solaris2.6時代のDNLC問題の名残り
*4 インデックス名にテーブル名を含んでいるため、少し短めに設定
*5 テーブル名およびカラム名が長い場合
*6 小文字で記述していると思ったように動作しない。
*7 Databaseは DB と略される。これを変数名に見立てた場合、DataBase 、Database という 2つの変数名がでてくる危険性がある。特に長い名称では起こりやすい。
*8 アンダースコア(_)使用時はエラーになるので自然に改修させることができる。