データベースの設計についての質問です。

顧客リストの標準的な正規化モデルというのは存在しますでしょうか?
今一番苦慮しているのは、
部署名と役職名が階層構造を成している点です。
例:
○○事業部
  ○○企画部
   ○○課
○○課長
  ○○室長代理

どこまで正規化すれば良いのか、
落としどころみたいなものがありましたら、
アドバイス願います。

回答の条件
  • URL必須
  • 1人2回まで
  • 登録:2004/11/12 17:43:50
  • 終了:--

回答(1件)

id:taknt No.1

きゃづみぃ回答回数13539ベストアンサー獲得回数11982004/11/12 17:57:08

ポイント200pt

いくつか人事関連のソフトに関わったことがありますが、

たいてい 所属コードと所属名という組み合わせでしたね。

所属コードが 階層式になってて

たとえば

○○事業部 001

  ○○企画部 002

   ○○課 003

の場合

001002003

というふうに 桁数で 部署を分けるようにして用いてました。

これが

001002

だと

○○事業部 001

  ○○企画部 002

となります。

id:takasiym

ありがとうございます。

002001だと、

○○企画部

  ○○事業部

となるわけですか。

悪くない切り抜け方ですね。。。

するとデータベース構造は以下で宜しいでしょうか?

顧客マスタテーブル

==========================================

顧客コード(プライマリキー)

企業コード

氏名

Tel

Fax

E-mail

==========================================

企業テーブル

==========================================

企業コード(プライマリキー)

企業名

==========================================

企業所属テーブル

==========================================

ユニークID(プライマリキー)

所属コード

企業コード

所属名

==========================================

企業役職テーブル

==========================================

ユニークID(プライマリキー)

役職コード

企業コード

役職名

==========================================

顧客所属テーブル

==========================================

ネストレベル(プライマリキー)

顧客コード

所属コード

==========================================

顧客役職テーブル

==========================================

ネストレベル(プライマリキー)

顧客コード

役職コード

==========================================

問題なければこれでテーブルを作成しようと思います。

質問を終了します。

2004/11/12 19:04:36
  • id:upride
    一言

    更新年月日や更新ユーザ、場合によっては削除フラグ
    表示の並び順を考慮したフィールド
    これらを全テーブルに付け加えた方が宜しいですよ
  • id:takasiym
    Re:一言

    >更新年月日や更新ユーザ、場合によっては削除フラグ
    >表示の並び順を考慮したフィールド
    >これらを全テーブルに付け加えた方が宜しいですよ
    ご指摘ありがとうございます。
    それでは、
    last_updateフィールドをマスタテーブルに追加することに致します。
    それ以外のテーブルについては、
    今後必要となった時に追加するつもりです。
    削除フラグフィールドについては、
    今後必要となった時に追加するつもりです。
  • id:takasiym
    (投稿者削除)

  • id:taknt
    ネストレベルってのは 桁数かな?

    桁数でどのぐらいの 階層か 判断できます。
  • id:takasiym
    Re:ネストレベルってのは 桁数かな?

    >ネストレベルってのは 桁数かな?
    一つのフィールドに複数の値を格納して管理するのではなく、
    テーブルを別個に作り、
    マスタテーブルとリレーションを組んで、
    データを管理しようと目論んでいます。

    >桁数でどのぐらいの 階層か 判断できます。
    一つのフィールドに複数の値を格納して管理すると、
    コーディングの手間が増えますので、
    テーブル設計を工夫してなるべくsql文のみでデータを呼び出したいのです。

    では、、、
  • id:takasiym
    Re(2):ネストレベルってのは 桁数かな?

    所属コード:001002003
    ↓正規化
    所属テーブルの各レコード
    =================================
    ネストレベル:1
    所属コード:001
    =================================
    ネストレベル:2
    所属コード:002
    =================================
    ネストレベル:3
    所属コード:003
    =================================

    という具合にするつもりです。
  • id:takasiym
    Re(3):ネストレベルってのは 桁数かな?

    企業所属テーブルと企業役職テーブルはやめました。
    それに伴い、
    顧客所属テーブルの「所属コード」を「所属名」に、
    顧客役職テーブルの「役職コード」を「役職名」に、
    それぞれ変更しました。
    違う顧客で同一の「所属名」、「役職名」が入る場合があるので、
    この方法は正規化(一事実一箇所)の原則から外れています。
    しかし、
    大規模な組織再編成等が起きた場合、
    ガチガチに正規化していると柔軟に対応できない恐れがあるので、
    あえて重複を許すことにしました。
    その代わり冗長性をなるべく排除するために、
    同一企業で既登録済の別の顧客の部署や役職を値参照する入力支援機能を
    実装する予定です。
    では、、、
  • id:takasiym
    Re(4):ネストレベルってのは 桁数かな?

    というわけで、
    頭に「顧客」をつける必要がなくなったので、
    顧客所属テーブル→所属テーブル
    顧客役職テーブル→役職テーブル
    にそれぞれ名称変更しました。
    では、、、
  • id:takasiym
    Re(5):ネストレベルってのは 桁数かな?

    ネストレベルをプライマリキーにするのはまずいので、
    最終的な所属テーブル、役職テーブルの構造は以下のようになりました。

    所属テーブル
    ==========================================
    ユニークコード(プライマリキー)
    ネストレベル
    顧客コード
    所属名
    ==========================================

    役職テーブル
    ==========================================
    ユニークコード(プライマリキー)
    ネストレベル
    顧客コード
    役職名
    ==========================================
    但し、
    顧客コードが同一でかつネストレベルが同一なレコードは、
    複数存在できないものとします。
    # 複数の部署や役職にまたがっている顧客がいるかも知れないが、
    # そこまでデータベースに記録する必要はないと判断。

    では、、、

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません