- 締切済み
DBが複雑すぎる
下記画像の社員出身マスタのようなDBがあるとします。 会社だとこれが非常に複雑になり、さらに専門家に結合してもらわないと誰も分かりません。大変な労力です。これが大型DBになると数百のコードマスタとなり、コードマスタとマスタの突合せはともあれ、コードマスタ同士の突合せもあり、重複や入力ミスや勘違いが多発しています。 「山田,青森,青森」と言った感じでは駄目でしょうか。 どうせプログラムで入力チェックしていますし、ラジオボタンで選択する等、入力ミスが起こるはずがありません。いざとなればそこにパキスタンと手入力しても問題なさそうですし、大掛かりなシステム改編作業が減ると思いますが。 何のためにどこの会社もこういう複雑な設計になっているのでしょうか。
- みんなの回答 (9)
- 専門家の回答
みんなの回答
- airhead-no1
- ベストアンサー率48% (45/92)
なんか、質問内容と回答に対する補足を見ていると... 設計側の物を、使用者側に、そのまま見せてる感じ? たとえば 「設計側」 コードマスター(ID,名称) 1,'北海道' ..... 20,'東京' ..... 47,'沖縄' 社員出身マスタ(社員コード,社員名,出身コード,方言) 1,'あ',1,1 1,'い',2,2 となっているとすると 「使用者側」 社員名を入力 or 選択(同姓同名がいる場合があるため、社員コード入力等が望ましい) 出身を選択(北海道, 東京, 沖縄 等から選択) 方言を選択(北海道, 東京, 沖縄 等から選択) 多くのシステムでは、こうなっています。 ですので、使用者側がコード入力する箇所は、社員コードぐらいですね。 ただし、昔から(汎用機)のシステムを使っていて、ずっと同じように使いたいという 会社もあります。 そのような場合、コード入力の方が、選択 or 漢字入力よりも慣れているため あえて、コード入力を使用者側がするということもあります。
- yoshika_jp
- ベストアンサー率48% (17/35)
一般的なシステムでは質問者様のおっしゃる通りの編集をするはずです。 参照先テーブルが存在する項目は参照先テーブルの一覧から選択する形で入力を求めます。 利用者側でデータベース構造を意識することは無いと思います。(マスタを編集する場合を除きます) 仮に「山田,1,1」と言った入力を求めるシステムであるならばDBではなくもっと上層のシステムの見直しを検討すべきです。 ではリストにない(マスタテーブルに無い)データを入力したい場合はどうするの?と聞かれそうですが、それも上層の仕事です。 「リストに存在しない」と言った内容の項目を選択できるようにしておき、それが選択されたら別途入力してもらいます。 一度入力されればマスタに登録されますので以降はリストに追加されているわけです。 ではその上層のシステムを作成するときにDBが簡単な方がいいのでは?と言った疑問にお答えします。 理由は単純で各項目は別のテーブルでも利用するからです。 たとえば社員名は社員名簿でも部署名簿でも給与明細でも利用します。 だから別に社員マスタで管理し、都度参照します。 もう一つ、編集労力が減ります。 山田花子さんが結婚し、鈴木花子さんになりました。 上記の例では社員名簿、部署名簿、給与明細の3カ所で編集する必要がありますが、複雑なDB設計であれば1カ所、社員マスタの編集で済みます。 制作側としてはデータを別管理しているにも関わらず同期させろと言われる方がDB構造を複雑化するよりも頭の痛い話です。
- wormhole
- ベストアンサー率28% (1626/5665)
もしかしてマスタの内容をそのまま編集してる状態なんじゃないですか?ふつうは編集用のプログラムを用意して入力としては「青森」「青森」とかでプログラム内でコードに変換するものだと思うんですが。
- Siegrune
- ベストアンサー率35% (316/895)
う~ん、画像のマスタだけで話をすると別に複雑とは思いませんが。 「コードマスタ1」、「コードマスタ2」という名称は、わりにくくする元なので、 素直に「出身マスタ」「方言マスタ」としたほうがいいとは思いますが。 まず、出身と方言は同じではない。 例えば、出身が大阪でも、方言は、少なくとも河内弁と泉州弁の2種類はあります。 (他にもありますけどね。また、いわゆる関西弁なるものもありますし。) また、出身が福岡でも、親が秋田出身だったために、秋田弁をしゃべる人がいるかもしれません。 したがって別のマスタとせざる得ない。 >「山田,青森,青森」といった風にマスタを使わないと については、「パキスタン」を例にすると、 「パキスタン」と入れる人もいれば「パキスタン共和国」と入れる人もいる、 「バキスタン」と間違えていれるもいるかもしれません (この間違い探しは一目見てわからないから大変です。) また、この例ではいいのですが、例えば、人事マスタなので所属部署名を入れるとします。 「山田,青森,青森,販売第一課」 と持ったとします。 販売第一課が1月4日付けでシステム販売第一課と変わったら ・・・対象の全員を修正する必要があります。 マスタにしていたら、販売第一課の1レコードをシステム販売第一課にするだけで済みます。 (但し、同じ部署名でもマスタに持ってはいけない場合もあります。例えば、契約管理。 5年契約の契約情報を登録するときに、担当者山田さん。課はマスタから参照。としてしまうと、 5年後に、山田さんは人事部に所属しているので、この契約の営業担当部署は人事部ですという ふざけたことになります。) といった感じで、マスタに持つことの長所、短所のイメージはつかめてもらえましたでしょうか。
- mitoneko
- ベストアンサー率58% (469/798)
この写真のコードマスターなら、明らかに何らかの無駄があると推測します。 ただ、DBが大型になり、管理する物が複雑になると、マスターテーブル群が多くなり複雑になるのは致し方のないことです。 でも、このマスターテーブル群の存在は、普通は、ユーザーは知らなくても良い又は、見えないように作るのが普通なんですけどねぇ。 プログラムで入力チェックして、入力はラジオボタンでなんて表現が出るように、マスター表を人間の目で参照して、そのコードを入力するなんてユーザーインターフェースは今時無いんじゃないでしょうか。(昔には、こんなユーザーインターフェースもありました。入力用のオフコン(それって何?と思う人も多いでしょうね(笑))の横には、マスターテーブルのコード表を印刷した分厚い紙のファイルがあって、何か入力する時には、そのファイルを一生懸命めくってコードを探して打つんです。古参の方は亜ある程度のコードを覚えていて、コードを探すのも早いですから入力が早いんですよ。そんな時代もありました。) 今では、「えくせるってなんですか~?」なんて言う人には、マスターテーブル群の存在どころか、データベースの存在さえ見えないし、見えなくってたって業務の遂行が出来るというのが、正しいユーザーインターフェースのあり方です。 マスターテーブル群の本当の意味は、プログラマーの側にあります。データのチェックと整合性の保証を、自分が作るプログラムで作り込まずに、データベースの基本機能で保証させるために・・・何らかの変更がある時にも、少しでも手間をかけずに変更が出来るように・・・そのために、データベースを使用し、テーブルを正規化し、コードテーブル群を作ります。 この設計に上手下手は、明らかに存在します。下手な人が作ると、変更にも保守にも恐ろしく手間がかかるようになり・・・その結果、変更作業などのコストが跳ね上がることになります。 ユーザーの直接的な利便には何の関係もない世界です。(間接的には、利益があります。変更作業を発注した時の見積書のお値段が下がり、納期が短くなりますから(笑))
- nora1962
- ベストアンサー率60% (431/717)
極端かもしれませんが、「東京」と入力する人と「東京都」と入力する人がいると困るのです。 というか、そういうところで入力する際にユーザーに判断を必要とするようなシステムは普通作りません。 ユーザーにコードを覚えさせて入力させるか、DBでコード管理するかは別問題です。 商品の受発注なんかでも今はバーコードなんかで発注できるようにして、ユーザーにコードを意識させませんよね。
- 山田 太郎(@testman199)
- ベストアンサー率17% (438/2463)
>設計側ではなく、使う側なので、シンプルがいいんです。さらにDBって何、エクセルできないバイトパートもいますので、お願いします。 DB設計と画面設計は別の話ですね わからないなら、DBなんか使用せずexcelで単純な表でも作って必要な項目だけ入力すればよいかと思いますけど >何のためにどこの会社もこういう複雑な設計になっているのでしょうか。 実現したい機能が複雑だからです 複雑な機能が不要な人には意味が分からないでしょう。 貴方は貴方に必要な機能だけチョイスしてください
- airhead-no1
- ベストアンサー率48% (45/92)
「山田,青森,青森」と言った感じでは駄目でしょうか。 それぞれをコードにした場合に比べ、データ量が増えるため、やりません。 (DB設計の基本ですね) で、画像で示された物ですと、 コードマスター1と2は統一できるし、id, code も統一できる。 無駄な物が多いから、管理が煩雑になる。 ちゃんと設計されたDBならば、くだらない改編作業なんて必要無い。 (No.1さんが書かれている基礎がしっかりできているかってのが鍵ですね)
- 山田 太郎(@testman199)
- ベストアンサー率17% (438/2463)
補足
ありがとうございます。正規化ではなくコードマスタの問題なんです。
補足
ありがとうございます。 >コードマスター1と2は統一できるし、id, code も統一できる。 idも連番のものが多く、何の意味があるのでしょうか。codeも要不要、未済、可否などのしょうもない物が多く、意味があるのでしょうか。 設計側ではなく、使う側なので、シンプルがいいんです。さらにDBって何、エクセルできないバイトパートもいますので、お願いします。