- ベストアンサー
ＡＣＣＥＳＳデータベース作成で正規化と言われました。 テーブルの作り方
ＡＣＣＥＳＳデータベース作成で正規化と言われました。 テーブルの作り方(項目分け)がわかりません。・申込日・氏名・性別・生年月日・郵便番号・住所・電番・職業・ＤＭ希望・メアド どうすればいいですか？
- retorogirl
- お礼率78% (85/108)
- オフィス系ソフト
- 回答数3
- ありがとう数4
- みんなの回答 （3）
- 専門家の回答
質問者が選んだベストアンサー
root_16 さんの意見に賛成です。 あまり正規化のメリットはないようにも思えますけど。 まぁ、主キーに相当するようなものが無いので、ID を主キーとして ID・申込日・氏名・性別・～ とするか、 個人が複数の値を持ちそうなのは 電話番号（固定電話や携帯電話） メールアドレス（勤務先・個人のプロバイダ・フリーメール） 住所（現住所・勤務先・） 位なので 顧客マスタ ID・申込日・氏名・性別・生年月日・職業・ＤＭ希望 顧客マスタ住所 ID・郵便番号・住所・備考（複数の場合どれを優先するか等） 顧客マスタ電話番号 ID・電番・備考 顧客マスタメアド ID・メアド・備考 でしょうか。 顧客マスタ住所から顧客マスタメアドには『番号』フィールド（オートナンバー型）が 有ったほうが良いかもしれない。 http://support.microsoft.com/kb/283878/ なお、root_16 さんも述べられていますが なにかの注文でしたら、トランザクションテーブルの方に 受注テーブル ID・申込日・商品ID・数量・～ のように 顧客マスタテーブルは ID・登録日・氏名・性別・生年月日・職業・ＤＭ希望 かな？ 全体像が見えませんのでこの辺にて。あとは上司にお伺いを。
その他の回答 (2)
- layy
- ベストアンサー率23% (292/1222)
指示されたことについて、正規化すればいい、と解釈の質問と思いますが、この状態からはやって欲しいのは正規化ではないと思います。 変わる値、あまり変わらない値、変わらない値、増えて行く値、等に分類して１つのテーブルで管理しないように、だと思います。 生年月日は変わりませんがＤＭ希望は随時変わります。画面があるとしてＤＭ希望を更新する場合、生年月日の項目は必要ないので別テーブルでも良い。 参照でよいもの 更新にするもの にわける。 正規化については学習しておいて下さい。
お礼
なんか全く違う方向で上司が考えてました。 考えろと言われてやってみたら方向性が違うということで再指示があり、無事に解決しました。 どうやら、職業を別テーブルにして正規化したかったみたいです。。。
- root_16
- ベストアンサー率32% (674/2096)
申込日だけを管理すれば良いのであれば、 全ての項目を含む顧客テーブルとし、 特に正規化してテーブル分けする必要を感じません。 この項目で正規化が必要になるケースは ある人物が複数の住所を持っている場合か 複数のメールアドレスを持つ場合 （項目増やすだけでも対応可能ですが） です。 ほか、同一人物が複数申込をしてくるケース がありますが、 「申込」が「会員登録」のようなものなら正規化不要。 登録者と申込日が1対1の関係なので。 「申込」が「注文」のようなものなら 「申込日」を他の項目とテーブルを分け、他の項目を顧客テーブルと するのが良いのではないでしょうか？
お礼
なんか全く違う方向で上司が考えてました。 考えろと言われてやってみたら方向性が違うということで再指示があり、無事に解決しました。 どうやら、職業を別テーブルにして正規化したかったみたいです。。。
関連するQ&A
- ACCESS2003でデータベースを作成します
Access2003でデータベースを作成します。 以下の入力項目があるのですが、どう正規化したらよいのかわかりません。 お助けください。 ・顧客ナンバー ・顧客名 ・生年月日 ・年齢 ・住所 ・電話番号 ・身長 ・体重 ・性別 ・来店日 ・購入物 ・購入金額 これが一つなのですが、もう一つテーブルで ・商品名 ・価格 のデータベースも作りたいのです。 購入物を入力するとこのテーブルから価格を引っ張ってきて、 購入金額合計を出すようにすることも予定しています。 また来店日、購入物などの履歴は来店の度に入力があるので、 顧客ナンバーとは別のテーブルにすべきなのはわかるのですが・・・ よろしくお願いします。 このほかに必要な情報がありましたらご指摘ください。
- ベストアンサー
- その他(データベース)
- テーブル設計につきまして(正規化)
顧客情報管理サイトを作ろうと思っています。 ・非正規化 {顧客コード , 氏名 , かな名 , 性別 , 郵便番号 , 都道府県 , 市区町村 , 建物名 , 電話番号 , FAX番号 , 携帯番号1, 携帯メール1 , 携帯番号2 , 携帯メール2 , 顧客ランク,備考} の列を考えております。 ・正規化テーブル 1.顧客情報テーブル {顧客コード , 氏名 , かな名 , 性別 ,郵便番号(外部キー) , 建物名 , 電話番号 , FAX番号 , 携帯番号1, 携帯メール1 , 携帯番号2 , 携帯メール2 , 顧客ランク,備考} 2.郵便情報 {郵便番号(主キー) , 都道府県 , 市区町村 これ以上、正規化できないと思っているのですが、顧客情報テーブルをもっと効率よく テーブルを設計し、正規化できるものでしょうか？ よろしくお願いします。
- ベストアンサー
- その他(データベース)
- データベース、テーブル設計についてです。
現在、ブランドサイズをインターナショナルサイズに変換するデータベース設計をしていて悩んでいることがあります。どうか知恵をお貸しください。 参考にしています書籍は、ミック著「達人に学ぶDB設計徹底指南書」です。 書籍には、正規化の次数が低いほど検索SQLのパフォーマンスは良いですが、データ整合性は低く、正規化していくほどパフォーマンスが低下する代わりにデータ整合性が高くなります。と書いています。 ですので、正規化した結果、５つのテーブルが出来上がりました。 これらを正規化したテーブルを中間テーブルで扱うには、どのように設計すればよろしいでしょうか？ 以上、よろしくお願いします。 下記は、正規化したテーブルです。 テーブル名 ：： ブランド 扱うデータ ：： （仮）A、その他ブランド.... テーブル名 ：： 性別 扱うデータ ：： メンズ、レディース、ユニセックス テーブル名 ：： カテゴリー 扱うデータ ：： ウェアー、ボトム、シューズ、その他カテゴリー.... テーブル名 ：： ブランドサイズ 扱うデータ ：： 1、2、3、その他ブランドサイズ.... テーブル名 ：： インターナショナル・サイズ 扱うデータ ：： S、M、L、その他サイズ....
- ベストアンサー
- MySQL
- エクセルデータをアクセステーブルにコピーするVBA
エクセルファイル E.xlsxにおいて セルA1＝ID A2＝氏名 A3＝性別 A4＝住所 というデータがあるとしまして これをアクセスファイル F.accdbにおける テーブルの table1 その項目が ID, 氏名, 性別, 住所, 卒業校, 旧住所 があります。 このエクセルファイル E.xlsxにおける セルA1＝ID A2＝氏名 A3＝性別 A4＝住所 というデータを上記F.accdbにおける テーブルの table1 その項目が ID, 氏名, 性別, 住所,に（卒業校, 旧住所は 新規入力はないこととなります） コピー 追加するVBAを御教示願えますか E.xlsxにおいては１行だけのデータですが、 table1には すでに数行のデータが入力済であり、 IDが新規の場合と、すでにtable1に登録済みのIDが存在する場合に 上書きする場合のそれぞれのVBAを 御教示くださりますと助かる次第です よろしくお願い致します win10 office365
- 締切済み
- Access（アクセス）
- ファイルメーカーでアクセスクエリーみたいな作成方法
データベースソフトのアクセスは多少知識があります。 ファイルメーカーでアクセスで言うところのクエリーはどの様に作成したらよろしいでしょうか。 例えば、従業員コードをキーとして テーブル１（従業員マスタ） 従業員コード 氏名 入社年月日 テーブル２（住所録） 従業員コード 住所 テーブル３（家族構成） 従業員コード 配偶者 扶養１ 上記テーブルを３つ作成し、アクセスで言うところのクエリーみたいな感じで 従業員コード 氏名 住所 配偶者 上記レコードをまとめたテーブルを作成したい。 何か参考になる資料（本）のご紹介、もしくは教えてもらえませんでしょうか。 よろしくお願い致します。
- 締切済み
- その他(ソフトウェア)
- Accessでの設計
次のようなデータの設計に困っています。 前回他の方に答えていただいたのですが、問題が生じたので再度投稿させていただきます。 例）受験者名簿テーブル 受験者番号 主キー 受験者氏名 受験者かな 郵便番号 住所 電話番号 例）申込者テーブル 申込者番号（主キー） 受験者番号 受験者との続柄 申込者氏名 申込者かな 郵便番号 住所 電話番号 上記のテーブルが２つあります。また、受験者と申込者テーブルの受験者番号はリレーションを設定してます。 まず、受験者との続柄が「本人」の場合、申込者名前や住所、その他の項目は全て、受験者テーブルのデータを元に入力できるようにしたいです。また、受験者との続柄が「本人」ではないときには、氏名などを直接入力できるようにしたいです。 その際、申込者に「主キー」は必要かどうか。 また、他にテーブルを作成する必要があるのか。など初心者にわかりやすいように教えていただきたいです。クエリで、試してみましたが「本人」以外のデータを入力できなくなってしまいました。 どなたか回答願います。
- 締切済み
- その他(ソフトウェア)
- テーブルの分散について
お世話になります。 個人情報を格納しているユーザーテーブルがあります。 項目は以下の通りです。 ------------------------------ 1.連番 2.ユーザーID 3.名前カナ(姓) 4.名前カナ(名) 5.名前(姓) 6.名前(名) 7.性別 8.生年月日 9.年齢 10.電話番号 11.携帯番号 12.メールアドレス 13.パスワード 14.職業 15.郵便番号 16.国 17.住所(都道府県) 18.住所(市区町村) 19.住所(町域(番地)) 20.住所(建物名) 21.備考1 22.備考2 23.備考3 24.備考4 25.備考5 ------------------------------ 上記のように個人情報を1つのテーブルにまとめてセキュリティ上、問題はありませんでしょうか。 もし上記のテーブルを分散するとしたらどのように管理するようにしたらいいのでしょうか。 くだらない質問で大変申し訳ありませんがご教授いただけたら幸いです。 何卒、アドバイスの方を宜しくお願いします。
- 締切済み
- MySQL
- 第３正規化について
第３正規化について いつもお世話になっております。 第３正規化についての質問なのですが、理解できないので質問させて頂きます。 "t_携帯"というテーブルがあり、 [社員CD](一意) [氏名] [性別] [台数CD] [製造番号](一意) [メーカー名] [型名] [記憶媒体] [認証ID](一意？) [PASS] というフィールドがそれぞれ存在し、 [台数CD]フィールドの扱いがよく理解できなくて困っています。 例えばAさんが携帯を１台所持している場合、Aさんは[台数CD]フィールド'1'を持ち、 ２台所持しているBさんは'1'と'2'を持ち、２台目以降の携帯情報が繰り返しとなるので 第１正規化するのは分かるのですが、それ以降の第３正規化までの手順と マスタ分けがよく分かりません。 ご教授の程、宜しくお願いします。
- ベストアンサー
- その他(データベース)
- リレーションで？
ACCESS 2003を使って作成中なのですが、どうしてもわからないところがありましたので教えてください。 現在テーブルで、 「世帯テーブル」 ○ 世帯ＩＤ ○ 郵便番号 ○ 住所 ○ 電話番号 「個人テーブル」 ○ 世帯ＩＤ ○ 個人ＩＤ ○ 氏名 ○ 生年月日 ○ 性別 「詳細テーブル」 ○ 世帯ＩＤ ○ 個人ＩＤ ○ その他 とし、フォームで 「世帯フォーム」 ○ 世帯ＩＤ ○ 郵便番号 ○ 住所 ○ 電話番号 「個人フォーム」 ○ 世帯ＩＤ ○ 個人ＩＤ ○ 郵便番号 ○ 住所 ○ 電話番号 ○ 氏名 ○ 生年月日 ○ 性別 「詳細フォーム」 ○ 世帯ＩＤ ○ 個人ＩＤ ○ 郵便番号 ○ 住所 ○ 電話番号 ○ 氏名 ○ 生年月日 ○ 性別 ○ その他 というようにして、世帯ＩＤでリレーションしてます。 入力の順番は、まず「世帯」に入力し、それから「個人」に入力し、最後に「詳細」に入力したいと思ってます。 そこで、個人フォームを入力するときに世帯ＩＤを入力すると自動的に郵便番号、住所、電話番号が入力され、詳細フォームで入力するときに世帯ＩＤと個人ＩＤを入力すると該当項目が全て自動的に入力されるようにしたいと思ってます。 その場合、テーブルとフォームは作って世帯ＩＤでリレーションするところまでいったのですが、ここから先どのようにしたらよいのかがわかりません。 どなたかお力を貸していただければと思います。 どうぞよろしくお願いいたします。
- 締切済み
- その他(データベース)
- ACCESSで作ったテーブルの値を検索し、ASPページに表示させるには？
HTMLページのtextboxで検索項目を入力し、 DBからそれに当てはまる列を全て表示させるにはどうしたらいいのでしょうか？ 例えば：社員NO,氏名,性別,生年月日の値の入力されているテーブルから、 氏名のみでその他の情報を引き出して表示させる方法。 よろしくお願いします。
- ベストアンサー
- Microsoft ASP
お礼
なんか全く違う方向で上司が考えてました。 考えろと言われてやってみたら方向性が違うということで再指示があり、無事に解決しました。 どうやら、職業を別テーブルにして正規化したかったみたいです。。。