• ベストアンサー
※ ChatGPTを利用し、要約された質問です(原文:Accessでのデータ管理)

Accessでのデータ管理のベストな方法

このQ&Aのポイント
  • Accessでのデータ管理において、商品(洋服)のリレーションを活用した複数テーブルの上手な使い方を探しています。
  • 商品(名)は同じだけど、サイズの違いや価格の違いがある場合、1つのマスターテーブルで管理する方法について教えてください。
  • 特に洋服など、1つの商品名でサイズ違いがあり、サイズ別に定価も違う場合の最適なリレーションの活用方法について知りたいです。

質問者が選んだベストアンサー

  • ベストアンサー
  • panacon
  • ベストアンサー率31% (214/679)
回答No.4

商品マスタは、商品IDと商品名、サイズと定価に法則性があるわけでもないでしょうから、正規化でこれ以上ちいさなテーブルにはならないと思います。これはこのまま使って良いと思います。この他に、顧客マスタと祝祭日マスタ、販売の積み上げ記録としてワークテーブル、天気の記録としてのワークテーブルがあると将来データが積み上げたときに、クエリで分析をすることができると思います。各テーブルには、下記のようにアイテムがあると良いと思います。 顧客マスタ 顧客ID|顧客名|連絡先|他 祝祭日マスタ 日付|祝祭日名 ワークテーブル(販売記録) 日付|曜日|時間|商品ID|顧客ID|販売価格|数量|小計|他 ワークテーブル天気と気温 日付|天気|最高気温

okwave00000000
質問者

お礼

分かりやすい回答、ありがとうございました。 このまま使ってよいとのことでスッキリしました。 天気と気温のデータを使っての分析、使ってみたいと思いました。

その他の回答 (5)

  • chayamati
  • ベストアンサー率41% (260/624)
回答No.6

回答No.4の追伸です。 商品テーブルと他のテーブル(例えば売上)とリレーションを組むためにユニークなフィールドを追加します。 ・商品  商品ID(テキスト型、重複なし)  商品種別ID(数値型、主キー、標題を商品名、商品種別をルックアップ設定)  サイズID(数値型、主キー、標題を、サイズをルックアップ設定)  登録日(日付/時刻型、既定値date())  更新日(日付/時刻型、既定値date())

okwave00000000
質問者

お礼

画像つきで分かりやすく回答いただき、ありがとうございました。m(_ _)m

  • chayamati
  • ベストアンサー率41% (260/624)
回答No.5

重複登録を避けるため添付のように次の3つのテーブルで構成します。 ・商品種別  ID(オートナンバー型、主キー)  商品名(テキスト型、インデックスで重複なし)  フリガナ(テキスト型、商品名でフリガナ機能を使用) ・サイズ  ID(オートナンバー型、主キー)  サイズ(テキスト型、インデックスで重複なし) ・商品  商品種別ID(数値型、主キー、標題を商品名、商品種別をルックアップ設定)  サイズID(数値型、主キー、標題を、サイズをルックアップ設定)  登録日(日付/時刻型、既定値date())  更新日(日付/時刻型、既定値date())

noname#231195
noname#231195
回答No.3

そのままでいいです。 無理に別のテーブルを作る必要はないです。 もちろんこういう風に構成することはできます。 商品マスターテーブル 商品ID|定価 1S | 1000 1M | 1200 1L | 1400 1XL|1600 2S |1000 2M | 1200 2L | 1400 2XL| 1600 商品種別 種別ID|種別名 1| スウェット 2 | パーカー 商品IDの一桁目が商品の種類を表し、二桁目以降がサイズを表すようですから、商品マスターテーブルに商品名とサイズのデータは不要といえば不要です。 そういう風に最適化して、「リレーションを活用した」いというご希望に合わせるとすれば、上に示したように2つに分けることはできます。 でもこのようにすると商品の種別名やサイズを呼び出す時に、いちいち特別の仕掛けが必要になりますから、私ならやらないです。 商品種別が10種を超えたら商品IDの頭の部分がどうなるのか知りませんが、桁が増えるたびにデータベースを直さなければならないとかいうことになりかねませんしね。 それにMS-Accessのリレーションシップの機能なんか無理して使う必要ないんですよ。 連鎖更新だとか連鎖削除なんかのオプションを使った場合、思いもかけないテーブルでレコードが勝手に更新・削除されます。それでデータベースを丸ごとおじゃんにしたことがあります。連鎖更新・連鎖削除を使わないのなら、リレーションシップをわざわざ別に設定する必要がないです。 参照整合性のチェックはもっと鬱陶しいです。親のテーブルに当該レコードがなくても、子のテーブルにとりあえずレコードを入力したい場面はいくらでもあります。

okwave00000000
質問者

お礼

ありがとうございました。m(_ _)m

回答No.2

>Access1日目の初心者です。 それじゃー、活用するのは無理。 1、最初は、MZ-80KでのFortran演習からスタート。 2、次に、UNIXでC/Sシステムを開発。 3、そのついでにC言語もマスター。 4、Windowsが登場した際には、まずQuick Basicを習得。 5、その後、Access2.0に挑戦。 5ではAccessのヘルプ文を全て印刷し、全例文をテストすること3回。それに要した日数は一日5時間の6ヶ月。で、ようやくAccessシステムの開発の目途が立ちました。 UNIXでのC/Sシステム開発経験があったのでSQL文とかテーブル設計は問題なし。また、C言語とQuick Basicを習得していたのでVBAもOK。が、AccessにマッチしたAccess流のアプリケーションを開発する手法を確立するのに半年を要しました。 Access1日目の初心者では、まーだ無理じゃーないかな。

okwave00000000
質問者

補足

ありがとうございます。 サイズ違いの商品をどのように対応すればいいのかの考え方のヒントでも教えていただきたいです。 引き続きよろしくお願いいたします。

  • catpow
  • ベストアンサー率24% (620/2527)
回答No.1

>>Access1日目の初心者です。 >>今は、商品(名)は同じだけど、サイズの違い、価格が違う商品を1つのマスターテーブルで管理しようとしています。 >>洋服など、1つの同一商品名でサイズ違いあり、サイズ別に定価も違う場合は、どのようにリレーション等を活用して、データ管理するのがベストなのでしょうか? リレーショナルDBの機能を使って、質問者さんの希望するテーブル設計を行います。 このあたりは、わりと難しいので、書店でデータベース設計の本を購入して勉強する必要があります。 ここで答えるような分量の話ではありません。 また、作り始めると、いろいろと疑問点が出てくる可能性もあります。 なので、ご希望のシステムの開発期間は、短くて3か月とか半年以上かかることもありえますね。 がんばってください。

okwave00000000
質問者

補足

ありがとうございます。 入門本を一冊読みました。 引き続き今後も勉強していきますが、一冊読み終えたので、やりながら覚えようと思って、サイズ違いにどう対応させるかで躓いています。 例えば 商品マスターテーブル 商品ID|商品名|Sサイズ定価|Mサイズ定価|Lサイズ定価|XLサイズ定価| 1S | スウェット | 1000|1200|1400|1600 のようにフィールドで対応しようとすると、この商品マスターテーブルはスッキリしますが、これだと後々、リレーションした販売データを管理したいトランザクションテーブルで、どのサイズが売れたか分からなくなってしまいます。 サイズと価格を別のマスターテーブルで管理してリレーションを使っても、テーブルが無駄に増えるだけであまり意味がないと思いまして… 最初の質問の例のテーブルのように、商品名は同じでもサイズ違いのものは、サイズごとにレコードを作るのがベストでしょうか? 初歩的な質問かもしれませんが、他の方々も、引き続きよろしくお願いいたします。 質問の意図がわからない等ありましたら、補足追加していきます。