質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.50%
MySQL

MySQL(マイエスキューエル)は、TCX DataKonsultAB社などが開発するRDBMS(リレーショナルデータベースの管理システム)です。世界で最も人気の高いシステムで、オープンソースで開発されています。MySQLデータベースサーバは、高速性と信頼性があり、Linux、UNIX、Windowsなどの複数のプラットフォームで動作することができます。

Q&A

解決済

3回答

3708閲覧

MySQL属性が多い商品の正規化はどうするとよいのか

oyatsu8

総合スコア97

MySQL

MySQL(マイエスキューエル)は、TCX DataKonsultAB社などが開発するRDBMS(リレーショナルデータベースの管理システム)です。世界で最も人気の高いシステムで、オープンソースで開発されています。MySQLデータベースサーバは、高速性と信頼性があり、Linux、UNIX、Windowsなどの複数のプラットフォームで動作することができます。

0グッド

0クリップ

投稿2017/11/13 11:17

編集2017/11/13 11:44

前回の質問を参考にさせて頂きデータベースの正規化やどのデータベースを使用するべきかがわからない>都道府県、市町村、複数人入力
大変親切で分かりやすい回答を頂き、
属性が多い場合はタグにするといいかもしれないというアドバイスもあったのですが、
下記のような設定の場合は、同じ属性内で複数を選択する場合もあると考え、下記のようにしてみましたが、やはり理解できていないと思われるため、
再度質問させて頂きました。

例えば、衣類のように、属性が多いものをデータベースで正規化したら、と具体的に考えようとしてみたのですが、これでいいのかがわかりません。もし、アドバイスを頂けたら幸いです。

このデータベースでは、
属性が被っているものを見る時に使いたいと考えます。
例えば

  • リスト商品(服)名前の商品はシャツが多く、メーカーはどこで作られている
  • 赤いシャツはチェックが多く、日常着が多い

などのつながりを正規化で表現出来ないかと思います。

[商品テーブル]

  • 商品(服)名前
  • 商品ID プライマリーキー

[商品属性テーブル]

  • 季節、月
  • 用途(日常着、礼装)複数
  • 模様
  • 部品(レース、金属など)複数
  • 色 複数
  • 製法
  • 生地の素材(木綿、絹)複数
  • 生地が分厚い、薄い
  • 人気がある、ない

[メーカーテーブル]

  • 商品メーカー
  • 商品メーカー所在地(都道府県ID、市町村ID)

[都道府県テーブル]

  • 都道府県名
  • 都道府県ID

[市区町村テーブル]

  • 市区町村名
  • 市区町村ID

[売上げテーブル]

  • 価格
  • 1年間の売上げ個数

[商品テーブル]

item_id(PK)item_name
1シャツ
2パンツ
3ジャケット
item_id(PK)month
11月
22月
----月
1212月

属性:用途

item_id(PK)用途
1日常着
2礼装
3運動着

属性:模様

item_id(PK)模様
1無地
2チェック
3ドット

属性:部品

item_id(PK)部品
1レース
2スパンコール

属性:色

item_id(PK)
1
2

属性:製法

item_id(PK)製法
1手縫い
2ミシン
3機械

属性:生地の素材

item_id(PK)生地の素材
1
2木綿

属性:生地の厚みテーブル

item_id(PK)生地の厚み
1厚い
2薄い

属性:人気テーブル

item_id(PK)人気
1ある
2ない

*下記は前回の回答で頂いたアドバイスをそのまま使わせて頂いています。

都道府県テーブル

pref_id(PK)都道府県名
1北海道
2青森県

市区町村テーブル

city_id(PK)pref_id(FK)市区町村名緯度経度
0110021札幌市43.06141.35
0220392八戸市40.52141.50

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答3

0

別テーブルで管理するのは、レコードが増えるものにしたほうが良いです。
たとえば、人気のある/なしは2つの値しかとらないなら、別テーブルにするメリットは少ないです。
しいて言うなら、DBの使用量が"ある"より"1"を格納するほがサイズが小さいぐらいですかね。

あと、誤記だと思いますが各属性テーブルのPKは、属性(色)_IDみたいな感じですよね?
通常、色は商品コードに含まれていそうな気もしますが・・・
※実際に生地の素材は、PKがitemなので、複数指定できないです

あと、月のテーブルも、そのまま数値を保存しておけばよいのでは?

複数選択できるものは別テーブルで管理するのが一般的ですが、そもそも検索とかで使わないなら
普通にテキストとして管理するのもひとつの方法かと。
※いわゆる正規化を崩すというやつです。

あとは、実際の想定する商品を格納するイメージでテーブル設計をして、検索できるか?
の観点で確認したほうがよいです。
現時点で、JOINが大変そうなわりにメリット少ないだろうなぁという気がします。

投稿2017/11/13 12:22

momon-ga

総合スコア4820

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

oyatsu8

2017/11/14 13:50

ありがとうございます、具体的に使っていなくて概念だけで考えようとしたのですが、知識が足りなさ過ぎてよくわからず、、言われたように分割してもメリットが少なそうな感じがしました。
guest

0

属性の追加変更が頻繁に発生する場合は変更に対して強いタグやラベルと呼ばれるパターンをお勧めします。
ちなみに汎用属性テーブルは "SQLアンチパターン EAV" に該当してしまいます。
"SQLアンチパターン EAV"の欠点は検索して調べてください。

商品  半袖開襟ワイシャツ       / | \ タグ   夏  木綿 縦縞      |  |   | タグ種  季節 素材  柄

投稿2017/11/14 04:45

hihijiji

総合スコア4150

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

oyatsu8

2017/11/14 14:26

ありがとうございます。記事を探して読んでみました https://qiita.com/deme0607/items/a89319014bc007f09f5c が、理解しきれませんでした、、基礎が無さ過ぎで申し訳ないのですが、 属性を5つ作っていて、その後更に属性が4つ増えるような場合にタグやラベルがいいということですよね。まだそのタグやラベルについてもわかっていないため、勉強してみます。
guest

0

ベストアンサー

前の質問でのmiyahanさんの回答のポイントは商品属性テーブルです。
商品の基本的な情報(商品名や価格)だけを商品テーブルのカラムに持たせ、商品属性テーブルで複数の属性を定義しています。
今回は具体的な属性をテーブルで定義したのですから、商品属性テーブルはそれらと商品テーブルを結び付ける関係テーブルとします。
miyahanさんはitem_idとタグの2カラムでPKとしていますが、複数属性に対応するためにPKは1カラムで定義し直します。

商品属性テーブル

id int autoincrement primary key
item_id int //=商品テーブル.item_id
attribute varchar(128) //対象属性
value int //属性id

たとえばこんなシャツ(item_id=1)があるとしたら、

  • 北海道
  • 札幌市
  • 礼装、運動着
  • チェック
  • スパンコール

商品属性テーブル(関係テーブル)はこうなります。

|id|item_id|attribute|value|
|:--|:--:|--:|
|1|1|都道府県|1|
|2|1|市区町村|011002|
|3|1|用途|2|
|4|1|用途|3|
|5|1|模様|2|
|6|1|部品|2|
|7|1|色|2|

この商品属性テーブルをselectすれば、都道府県、市町村、属性で検索できます。
属性が多くなった場合、関係テーブルを作ってやることでデータが扱いやすくなります。

投稿2017/11/13 13:10

ooeok

総合スコア469

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

oyatsu8

2017/11/14 13:52

ありがとうございます。イメージ的に商品の詳細情報というか、1つの商品の情報を1枚の紙にまとめていて、商品IDから呼び出せるような感じだと理解しました。
ooeok

2017/11/14 14:18

関係テーブルは便利なんですが、hihijijiさんが指摘されているように属性テーブルを持つことはEntity Attribute Valueです。 違う属性を比較したい場面でかったるいSQLを書くはめになるでしょう。 属性が減ったときなんか、関係テーブルを更新しなければならなくなっちゃいます。 たぶん今の段階ではEAVと言われてもよく分からないと思いますが、実際にSQLを書く段階になったら「そんなことも指摘されてたなあ」と思い出してみて下さい。
oyatsu8

2017/11/14 14:28

ありがとうございます。心に留めておきます。 ただ、もしデータベースに入れる属性に変更が無い場合は最適な方法ということなのでしょうか?
ooeok

2017/11/14 14:48

最適ではないです。 ただ、今の段階でEAVまで考えなくてもいいんじゃないかと私は思います。 Bill Karwinの『SQLアンチパターン』を読むのは試行錯誤してからの方がいいでしょう。
oyatsu8

2017/11/14 15:06

ありがとうございます。まず基本を理解しようと思います。
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問