Q&A
言語が違った場合、同じ商品でどこがどう変わるのでしょうか
お世話になります。
この度、自身初めてLaravelを使用してWEBシステムを構築しております。
Laravelでは、DBのキー項目は常にシーケンスで自動採番するサロゲートキーの使用が推奨されているため、
初めてサロゲートキーを用いたDBを構築しております。
そのなかで、通常の複合キーを用いて正規化する設計と考え方が異なると感じている部分が多々あり、
どのような構成がベストなのかわからず疑問がでてきました。
サロゲートキーでのDB設計、多言語対応(i18n/l10n)の経験がある方のご意見をお聞かせ願います。
(また、このような悩みを解決できるようなDB設計の技術書があればぜひ教えてください！)
以下が悩みのもととなったER設計です。
ER
1【言語マスタ】 2id integer - ID 3name varchar - 名称 4 5【商品マスタ】 6id integer - ID 7language_id integer - 言語ID 8name varchar - 名称 9spec varchar - 仕様 10price integer - 価格 11maker_id integer - メーカーID 12 13【メーカーマスタ】 14id integer - ID 15name varchar - 名称 16 17・言語についてはブラウザのLocaleで初期設定、その後画面から選択できるような仕様をイメージしています 18・価格情報について、DB上は日本円の情報のみ保持します
①マスタでもサロゲートキー？
マスタのキーをサロゲートキーで持つ必要性はあるのでしょうか？
また、上記の例でいうと、商品マスタの外部キーである言語IDが代理キーだと、
マスタ定義上紐付けて登録することが難しくなると感じていますが、どのように登録するのが良いでしょうか？
②言語に依存しない項目は別テーブル化するべき？
上記の例でいうと、商品マスタの価格やメーカーIDがこれにあたりますが、これらの項目は別テーブルで管理した方が良いのでしょうか？
あと特定の言語にしかない商品はあるのでしょうか
不備があり、申し訳ありません。概ね解決はしましたが、後から見る人のためにも後程修正させていただきます。ご指摘ありがとうございます。
回答1件
0
ベストアンサー
サロゲートキーに対するのはナチュラルキーです。
何れも複合項目であるかどうかは本来関係はありません。
①マスタでもサロゲートキー？
②言語に依存しない項目は別テーブル化するべき？
要件次第です。
備考やメモ的な扱いなら、別テーブルでの管理の必要はないでしょう。
ただ、体系的に管理出来そうなものは、別テーブルでサロゲートキーでの管理とした方が、後々の拡張性はあります。
ですが、管理しないよりは、作りこみにコストが掛かりますので、これも要件次第でしょう。
追記
質問にある【商品マスタ】はサロゲートキーでの管理とはなっていない様に見えます。
サロゲートキーをIDとすると、一般的なナチュラルキーは、メーカーID+商品コード+言語IDになると思われます。
また、質問にある【商品マスタ】はm17nでの、表示する言語に対応するものに思え、別途、メーカーID+商品コードで管理される別テーブルが必要に思えます。
追記２
ナチュラルキーとしては、製品メーカーとそのメーカーで管理される商品コードが良いと思います。
【商品マスタ】サロゲートキー：商品ID、ナチュラルキー：メーカーID＋商品コード id integer - 商品ID maker_id integer - メーカーID product_code --商品コード price integer - 価格 【商品言語別マスタ】サロゲートキー：ID、ナチュラルキー：商品ID+言語ID id integer - ID product_id integer - 商品ID language_id integer - 言語ID name varchar - 名称 spec varchar - 仕様
※過去の情報まで管理するようなシステムの場合は、履歴情報として日付をキーの一部にする事が多いですね。その場合に、その日付をサロゲートキーに含めるかどうかは悩ましいところですが。
商品マスタの外部キーである言語IDが代理キーだと、
マスタ定義上紐付けて登録することが難しくなると感じていますが、どのように登録するのが良いでしょうか？
画面でメンテナンスする要件があるとの事なので、プルダウンで選択などの方法や、チェックなどにも使用できるので、言語はマスタ化されていた方が良いでしょう。
前提としてそのデータが既に存在するものを外部キーとするのですから、一緒に登録するという事を考えるものではありません。
投稿2018/11/05 01:14
編集2018/11/05 03:53
総合スコア25188
> サロゲートキーに対するのはナチュラルキーです。
> 何れも複合項目であるかどうかは本来関係はありません。
申し訳ありません、上記については勝手に解釈し、誤った表現で記述してしまいました。
おっしゃる通りナチュラルキーが正しい表現ですね。
> 要件次第です。
> 備考やメモ的な扱いなら、別テーブルでの管理の必要はないでしょう。
> ただ、体系的に管理出来そうなものは、別テーブルでサロゲートキーでの管理とした方が、後々の拡張性はあります。
> ですが、管理しないよりは、作りこみにコストが掛かりますので、これも要件次第でしょう。
ナチュラルキーで設計したときは、あまり商品テーブルを複数に分けることがないので、イメージしずらかったですが、
そもそも、言語に依存しない商品情報と、言語に依存する商品説明は1:多となるはずなので、
おっしゃるとおり別テーブルでサロゲート管理するのが正しいですね…。
初めてのことで少し混乱してしまいました。
ただ、今回は画面でマスタメンテしたいというなんとも恐ろしい要件があり、なるべくメンテ項目は減らしたいので、
例であげていただいた、「備考やメモ的な」ものについては1本で管理できる設計にするつもりです。
> 質問にある【商品マスタ】はサロゲートキーでの管理とはなっていない様に見えます。
> サロゲートキーをIDとすると、一般的なナチュラルキーは、メーカーID+商品コード+言語IDになると思われます。
> また、質問にある【商品マスタ】はm17nでの、表示する言語に対応するものに思え、別途、メーカーID+商品コードで管理される別テーブルが必要に思えます。
おっしゃる通りです、大変失礼いたしました。
そもそもナチュラルキーでの設計ができていませんでした。
あと、言語を選択させる対応はm17nと表現するのが正しいのですね。
i18n/l10nしか知らず、区別も良くついていなかったので大変勉強になりました。
まとめると…商品マスタは、以下のようになりました。
あやまりがありましたら再度ご指摘いただけると幸いです。
(一般的な命名規則はわからないので、適当な命名です…)
'''ER
【商品言語別マスタ】ナチュラルキー：言語ID + 商品ID
id integer - ID
language_id integer - 言語ID
product_id integer - 商品ID
name varchar - 名称
spec varchar - 仕様
【商品マスタ】ナチュラルキー：商品ID + メーカーID(?)
id integer - 商品ID
maker_id integer - メーカーID
price integer - 価格
'''
以下の部分が私の中で解決していないので、もう少し回答クローズせずに待たせていただきたいと思います。
> 上記の例でいうと、商品マスタの外部キーである言語IDが代理キーだと、
> マスタ定義上紐付けて登録することが難しくなると感じていますが、どのように登録するのが良いでしょうか？
すみません、コメントはマークダウン記法使用できないんですね…
追記２について回答いただきありがとうございます。
すみません、また何点か気になってしまったので、
質問ばかりで申し訳ありませんが、可能な範囲でご回答いただけると幸いです。
> ナチュラルキーとしては、製品メーカーとそのメーカーで管理される商品コードが良いと思います。
こちらからだした要件が不十分な為に、メーカーをナチュラルキーとする理由がわからなかったのですが、ナチュラルキーで設計する場合と同様の考え方であってますか？
⇒メーカーをまたいで商品コードが重複する可能性を考慮している？
これを考慮しない場合は、商品コードのみがナチュラルキーでOK？
商品コードをナチュラルキーとして追加していただいていますが、
サロゲートキーはそもそもナチュラルキーに含めないで考えたほうが良い場合もあるのですね。
商品コードは画面上で人間が識別するうえで必要だが、言語idの場合は、サロゲートキー＝ナチュラルキーとして管理する今のままの形で正しい解釈しました。
誤っていればご指摘ください。
> 画面でメンテナンスする要件があるとの事なので、プルダウンで選択などの方法や、チェックなどにも使用できるので、言語はマスタ化されていた方が良いでしょう。
> 前提としてそのデータが既に存在するものを外部キーとするのですから、一緒に登録するという事を考えるものではありません。
たしかに、外部キー制約に則れば、左記に子テーブルがINSERTされているはずなので、画面からのメンテナンスは容易ですね。
今まで業務では、ナチュラルキーで設計していたため、マスタのリリースはExcelなどに一覧でキー項目含めて起こして、各テーブルのINSERTクエリを発行する形で行っていました。
(そもそも正しい方法か分かりませんが、子テーブル→親テーブルの順でINSERTしてもらっていました。)
サロゲートキー設計でDBのマスタを客先へリリースする場合、一般的にどのような方法がとられるのでしょうか？
>メーカーをまたいで商品コードが重複する可能性を考慮している？
そうです。
>これを考慮しない場合は、商品コードのみがナチュラルキーでOK？
OKです。
>言語idの場合は、サロゲートキー＝ナチュラルキーとして管理する今のままの形で正しい解釈しました。
ナチュラルキーとして、言語コード（ISO 639）などを使用するのであれば問題ないと思います。
>サロゲートキー設計でDBのマスタを客先へリリースする場合、一般的にどのような方法がとられるのでしょうか？
環境に依存します。
ユーザーがメンテナンスするものではなく、システムの定義情報としてという解釈したとして、プログラムの配布の一部がDBのテーブル内容という事ですから。
サロゲートキーを採用するということは、ナチュラルキーをサロゲートキーに対するメタ情報にすると言う事です。
システム的な定義情報でない限り、サロゲートキーを採用して、情報の変更による影響を受けないようにする方が良いのではないかと思います。
ただ、サロゲートキーの場合、それが外部キーとして使用されているような場合には、データ補正等の際に容易に復元できなかったりする側面もありますが。
> >言語idの場合は、サロゲートキー＝ナチュラルキーとして管理する今のままの形で正しい解釈しました。
> ナチュラルキーとして、言語コード（ISO 639）などを使用するのであれば問題ないと思います。
確認してよかった、ちゃんと理解できていなかったです。
あくまでも言語マスタには、ID(言語ID)と言語コードのように、サロゲートキーとナチュラルキーの両方を持つのが普通なんですね。
ありがとうございます。
慣れるまでは、ナチュラルキーのみで設計したあとに、主キーと外部キーをサロゲートキーに置き換えるように考えてみようと思います。
マスタのリリースについて、今回の言語マスタと商品言語別マスタの関係をどう登録していこうかな～とまだもやもやしてはいますが、あとは環境に合わせて自分なりに最善の案を考えてみようと思います。
長々とありがとうございました。
あなたの回答
tips
プレビュー
