ベストアンサー ※ ChatGPTを利用し、要約された質問です(原文:第1正規形→第2正規形) 第1正規形→第2正規形とは?質問あります。 2008/07/27 20:38 このQ&Aのポイント 大学図書館の本の貸し借りのデータベースで初めに第1正規形に正規化したテーブルが作成されています。このテーブルを第2正規形に正規化するために、テーブルを3つに分割します。また、第2正規形から第3正規形への方法についても教えてください。 第1正規形→第2正規形 正規化についてお聞きしたいです。 大学の図書館の本の貸し借りのデータベースで 現在第1正規化した↓のテーブルがあるのですが 図書ID|書名|配架場所|学生証番号 | 氏名|学部|在籍期限|返却期限|貸出日 (図書IDは重複がないものとする。主キーは図書ID、学生証番号である) これを第2正規形に正規化した場合 学生証番号(主キー)|氏名|学部|在籍期限 図書ID(主キー)|書名|配架場所 学生証番号(主キー)|図書ID(主キー)|返却期限|貸出日 ↑のように3つの表に分ければ良いのでしょうか? あとこれを第3正規形にするにはどうすればいいでしょうか? 第2から第3への方法がよくわからないので、わかる方ご指導下さい。 質問の原文を閉じる 質問の原文を表示する みんなの回答 (1) 専門家の回答 質問者が選んだベストアンサー ベストアンサー jamshid6 ベストアンサー率88% (591/669) 2008/07/27 22:02 回答No.1 すべてのケースで第2正規形、第3正規形が異なるわけではありません。今回のケースでは第2正規化を行った結果は、いわゆる「推移的関数従属」もないので、第3正規形にもなっているといえます。 ただし、もともとの項目に書名に従属する著者名、出版社名なども含まれていれば話は別ですが。 広告を見て全文表示する ログインすると、全ての回答が全文表示されます。 通報する ありがとう 0 カテゴリ [技術者向] コンピューターデータベースその他(データベース) 関連するQ&A 第1正規形から第2正規形へ 正規化についてお聞きしたいです。 大学の図書館の本の貸し借りのデータベースで 現在第1正規化した↓のテーブルがあるのですが 本の貸借 学生ID|学生氏名|学部|学部棟 | 図書番号|出版社|本のタイトル 111 山田花子 経済 102B 100122 A社 経済白書 222 小林武 理学 201C 200021 D社 人間失格 555 鈴木一郎 文学 301D 103455 D社 走れメロス 555 鈴木一郎 文学 301D 204333 B社 バカの壁 666 沢井竹子 経済 102B 104444 C社 雑学無駄知識 (図書番号は重複がないものとする。) これを第2正規形に正規化した場合 学生ID(主キー)|学生氏名|学部|学部棟 学生ID(主キー)|図書番号(主キー)|出版社|本のタイトル ↑のように2つの表に分ければ良いのでしょうか? まだ完全に第2正規化を理解できていないので みなさんもし宜しければ力を貸してください。 学生ID(主キー)|学生氏名|学部|学部棟 学生ID(主キー)|図書番号(主キー)|出版社|本のタイトル 正規化の問題 http://www.techscore.com/tech/sql/16_02.html のサイトを参考に正規化の仕方を勉強しています。 そこで質問なのですが、上のURLの一番最後の実習課題の問題の第一正規化からつまずいています。 図書館貸し出しカードにて、 固定部分が (発行日、貸出日、返却予定日、会員番号、会員名) 繰り返し部分が (書籍番号、書籍名、著書) なので、 とりあえず1つヘッダ的な表は (発行日、貸出日、返却予定日、会員番号、会員名) として、分離する表の主キーは何にすべきなのか迷います。 (発行日、書籍番号、書籍名、著書) として主キーは(発行日、書籍番号)とすべきか (会員番号、書籍番号、書籍名、著書) として主キーは(発行日、書籍番号)とすべきか (発行日、会員番号、書籍番号、書籍名、著書) として主キーを(発行日、会員番号、書籍番号)とするのかです。 どれも間違っているかもしれませんが、固定ヘッダ部分の表と繰り返し部分の表を結びつける属性が「発行日」だけじゃ同じ発行日で借りる人はたくさんいるだろうし、、でも「会員番号」だけじゃ他の日に発行した本の情報はどうなってしまうのだろうかとか、色々考えてしまって困惑しています^^; どなたかお助けください。 リンク先が、それぞれ第何正規化に該当するか教えて 正規化が分かりません。 冗長性を排除したい、という意図だけは分かるのですが… 例えば、リンク先で回答されているケースは、それぞれ第何正規化に該当するのでしょうか? >個人IDがあり、住所情報を正規化するとしましょう >項目は「郵便番号」「都道府県」「市区町村」「番地」「電話番号」「メールアドレス」としますよ >個人IDを主キーとする「郵便番号テーブル」を作る >個人IDを主キーとする「都道府県テーブル」を作る >個人IDを主キーとする「市区町村テーブル」を作る ・これは第1正規化ですか? >個人IDを主キーとする「番地テーブル」を作る >個人IDを主キーとする「電話番号テーブル」を作る >個人IDを主キーとする「メールアドレステーブル」を作る ・この内容は重複しないと思うのですが、分けると、正規化したことになるのでしょうか? ・また、その場合は、第何正規化に該当するのでしょうか? ▽DBの「非正規化」について http://okwave.jp/qa/q5776795.html ネットワークエンジニアとは?技術職の未来を考える OKWAVE コラム ドメインモデルの作成 図書館の図書貸し出しシステム 要求仕様) 初めて図書館を利用する人は図書カードを作成する。 図書カード作成のための必要な情報は、氏名、住所、電話番号、電子メー ル・アドレスである。 図書カードごとに ID ナンバーとパスワードが発行さ れる。 図書カードの発行を受けた人は、次のサービスを受けることができる。 ① 利用者用コンピュータで借りたい図書の検索(書名、著者等を検索キー にして)ができる (探している図書が貸し出し中か、どこの棚にあるかが 確認できる)。 (2) 8冊までの図書を最大15日間借りることができる (返却期間を印字した シールが発行されるので、それまでに返却すること)。 (3 借りたい本が無い場合には、 貸し出し予約カードに必要事項を記入して おくと、その本が貸し出し可能になったときに連絡を受ける。 4 自分の借りている本の一覧と、あと何冊借りることができるかの確認が できる。 (5 自分の借りている本の一覧には、 書名 著者名、 貸し出し期限が表示される。 返却期間を大幅に過ぎ、督促にも返事が無い場合には、 図書カードの発 行を取り消すことがある。 これってここからどうしたらいいですか? Access テーブルのデータをフォーム上で、検索したい こんにちは。Access で簡単な貸出管理データを作っています。 現在、貸出フォームは作ったのですが、 返却フォームを作る際、 今度は、一度テーブルに保存した貸出記録データを 返却フォームで検索して、表示したい場合、どのように したらよろしいでしょうか? 貸出フォームでは、 テーブル1、社員ID、氏名、電話番号 テーブル2、備品ID、備品名、貸出日、返却予定日、 社員ID、氏名、電話番号 これをサブフォームを使ってつくりました。 このテーブル2のデータを返却フォームで検索して、 (備品IDか社員IDで) 表示させたいと思っています。 よろしくお願い致します。 テーブル設計につきまして(正規化) 顧客情報管理サイトを作ろうと思っています。 ・非正規化 {顧客コード , 氏名 , かな名 , 性別 , 郵便番号 , 都道府県 , 市区町村 , 建物名 , 電話番号 , FAX番号 , 携帯番号1, 携帯メール1 , 携帯番号2 , 携帯メール2 , 顧客ランク,備考} の列を考えております。 ・正規化テーブル 1.顧客情報テーブル {顧客コード , 氏名 , かな名 , 性別 ,郵便番号(外部キー) , 建物名 , 電話番号 , FAX番号 , 携帯番号1, 携帯メール1 , 携帯番号2 , 携帯メール2 , 顧客ランク,備考} 2.郵便情報 {郵便番号(主キー) , 都道府県 , 市区町村 これ以上、正規化できないと思っているのですが、顧客情報テーブルをもっと効率よく テーブルを設計し、正規化できるものでしょうか? よろしくお願いします。 DBの主キーについての質問です。 日本の国公立中学校で児童達・生徒達の情報を管理する為に、 もしデータベースを設計するのでしたら、 どんな正規化が望ましいのかを知りたいですので、 過去に私が伺いました内容を踏まえまして、再度の質問を致します。 そこで、一先ず、下記の通りに3つのテーブルを考えました。 (1)学生ID/氏名/緊急連絡先/現住所/保護者氏名 (2)学校ID/学校名/所在地/代表電話番号/創立時期 (3)学校ID/教師ID/教師名/担当役職名 そして、更に纏める為に、次の3テーブルを追加しました。 (4)年度/学年/クラス/教師ID/性別/出席番号/学生ID (5)学生ID/試験実施日/教科番号/取得点数/平均点 (6)教科番号/教科名/教師ID でも、いざ纏めてみますと、残念乍ら、 (4)~(6)のテーブルの主キーがどれなのかが私には分からなくなりました。 従いまして、非常に恰好が悪いのですが、 それぞれの主キーを教えて頂けませんでしょうか? 基本情報技術者試験のデータベースの正規化について 主キーになる、ならないの質問です。 添付ファイルの顧客IDはなぜ主キーとならず、第3正規化で分割してるのでしょうか。 判断基準を教えてもらいたいです。 正規化があっているのかどうか見てください。 最近自作サイトを作っているのですが、DBの設計がちゃんと正規化されているか自信がありません。 そこで今考えているDBのテーブル設計を書かかせていただきますので、あっているかどうかチェックしていただきたいと思って投稿しました。 例えば電子書籍のDBを設計するとして、 ・漫画ID タイトル タグ ページ数 アクセス数 Upload日 Update日 こんなテーブルがあったとして、タグには複数の項目が入るので、第一正規化を適用して ・漫画ID タイトル タグID ページ数 アクセス数 Upload日 Update日 ・タグID タグ の2つにわけました。ここで2つ疑問があります。 まずタグIDとタグからなるテーブルですが、これの主キーはタグIDとタグですよね? これは主キー以外にレコードは無いんですが、こういう設計はまちがっていませんか? 次に、もう一個のテーブルがやけに長いというか第2正規化できるような気がするのですが、 部分関数従属するカラムは見当たりません。(例:ページ数が決まったかといって、アクセス数が決まるわけではない。 つまり全て漫画IDに完全関数従属している)。これであっているでしょうか? ご回答お待ちしております。 リレーショナル型データベースについて このような問題についてです。 以下に示す学生の成績表をリレーショナル型データベースで管理することとした。第3正規化の結果できあがるリレーションのスキーマを表の下に示した「スキーマの表現例」に倣って記述しなさい(1つとは限らない)。正規化されたリレーションスキーマの名称は適切なものを指定すること。また、主キーには○を施すこと。なお、学籍番号、科目番号は、それぞれ学生と科目を一意に識別する値である。学生は1つの学部に所属している。学部名は一意であり、所在地も学部によって一意に決まっているものとする。担当科目教員も課目によって一意に決まっているものとする。 成績表 (学籍番号、学生氏名、所属学部名、学部所在地、科目番号、科目名、担当教員名、成績) ※スキーマ表現例 商品を表すリレーションが3つの属性、商品コード、商品名、価格から構成されているとき、「商品(商品コード、商品名、価格)」と表す。ここで、商品コードが主キーである。 自分なりに考えた答えがこれです。 学生(○学籍番号、学生指名、所属学部名) 学部(○所属学部名、学部所在地) 科目(○科目番号、科目名、担当教員名) 成績(○学籍番号、○科目番号、成績) になりました。これでよいでしょうか。よろしくお願いします。 ボイスコッド正規形 http://www.techscore.com/tech/sql/16_02.html を参考に勉強しているのですが、ここのサイトでの疑問点です。 ボイスコッド正規形の説明の一番最後のほうに、 --引用-- 受注番号を主キーとし、下のテーブルでは納入業者を主キーとします。それぞれ、受注番号→商品番号、納入業者→商品番号という完全関数従属関係が成立しています。これらのテーブルは、ボイスコッド正規形の条件を満たしています。 --引用終わり-- ココの点で、受注番号→商品番号の関数従属はなりたっているのでしょうか?? 12345は商品番号001,002の二つを指している気がするのですが。 また正規形について。 http://www.techscore.com/tech/sql/16_02.html のURLの下の方の表 受注番号、商品番号、納入業者 12345 001 業者 A 12345 002 業者 B 12346 001 業者 A 12347 001 業者 D において、 ****以下引用**** このとき、非主キー列「納入業者」は「受注番号」と「商品番号」から決まりますので、(受注番号、商品番号) →納入業者は関数従属の関係が成立しています。よって、このテーブルは第二正規形の条件を満たしていると言えます。(中略) ****引用終わり**** とありますが、私には 商品番号→納入業者 という関数従属関係があるきがするのですが違うのでしょうか?なので第二正規形の時点で、 (商品番号、納入業者)という表が新たに分離される気がするのですが… さらに、 http://www.st.rim.or.jp/~ryoma/tips/seikika.htm のURLの同じくボイスコッド正規形で扱われ表、 商品コード、仕入先コード、担当者コード 000120001 111 401 000120001 112 402 000120002 111 401 000120002 150 403 仕入先コード、仕入先名 001 東京商店 002 大阪商会 003 名古屋流通 で、 *引用* 商品コード、仕入先コード、担当者コードを属性とする上の表は、繰り返し部分を持たず、また商品コード+仕入先コード、あるいは商品コード+担当者コードをキーとすることができ、かつ推移従属の関係が存在しないため、第三正規形です。 *終* とありますが、主キーを【商品コード、仕入先コード】と決めたとき、非候補キーである担当者コードは仕入先コードに関数従属している気が(私は)してしまうので第二正規形へ変形した時点で(仕入先コード、担当者コード)という表が分離されていると思うのですが。 以上の解釈で間違っている考えがあればご指摘ください。 AIは使う人の年齢や市場にも影響する?人工知能の可能性 OKWAVE コラム データベースと正規化とINSERT文について ただいま以下の一つのテーブルを正規化しようとしています。 テーブル:英単語 フィールド:単語、意味1、意味2、意味3、品詞、分類1、分類2、分類3、例文、難易度、ID(主キー・オートインクリメント) これを以下のように分けました。(分類とは単語の分類です。例えば year なら意味は 年 で分類は 時間 とか 単位 とか属性を入れたいのです。) ****** テーブル:英単語 フィールド:単語、意味1、意味2、意味3、分類ID、分類ID、分類ID、例文ID、難易度、ID(主キー・オートインクリメント) テーブル:分類 フィールド:分類名、ID(オートインクリメント 主キー) テーブル:品詞 フィールド:品詞名、ID(オートインクリメント 主キー) テーブル:例文 フィールド:例文、ID(オートインクリメント 主キー) ****** (1)これで正規化できているでしょうか? もしできていないなら、どうすればよいでしょうか? (2)また、仮にこのままデータベースを作るとすると、INSERTの時に英単語テーブルの分類IDに、分類テーブルのIDをひもづけるにはどうしたら良いのでしょうか? INSERT INTO 分類 (分類名) VALUES("時間") のあと、オートインクリメントされたIDを取り出して、英単語テーブルに入れるにはどうしたらいいでしょうか。 データモデル 図書館の予約システムの一部について、次のようなデータモデルを作成した。 [予約システムのデータモデル] (利用者)1対多(予約)多対1(図書タイトル)1対多(所属図書) 利用者(利用者ID←主キー、利用者名、住所) 予約(利用者ID←主キー、図書タイトルID、予約日) 図書タイトル(図書タイトルID←主キー、分類コード、署名、著者) 所蔵図書(所蔵図書ID←主キー、図書タイトルID、購入日、累計貸出回数) 図書タイトルと所蔵図書は、「1対多」の関係です。したがって、これを分けずに1つのエンティティで表した場合は、以下のようになります。 図書タイトルID|分類コード|署名|著者|所蔵図書ID|購入日|累計貸出回数 KB0100|K01|工事X|井橋太郎|K0001|2002.12.01|5 CH1000|C02|情報A|市川五郎|C0001|2003.10.01|10 CH1000|C02|情報A|市川五郎|C0002|2003.10.01|13 CH1000~市川五郎のように、これでは、同一タイトルの図書が複数存在し冗長なので、共通する属性を抜き出し、新たな図書タイトルエンティティを作成します。つまり、図書タイトルエンティティは、物理的な実体をもつ所蔵図書エンティティの属性を抜き出した、実体を伴わない抽象的なエンティティとなります。 以上のような解説があるのですが、「物理的な実体をもつ」「もたない」とは、どういう意味なのでしょうか?ここでいう実体とは、何のことなのでしょうか? excel vbaでマクロが作りたいのですが マクロ初心者です。 番号 貸出日 返却予定日 図書名 貸出先 返却日 1 2012/12/5 2013/1/5 マクロ ジョニーさん 上のような表を作成していて、予定日を過ぎても返却がない場合、自動的に番号欄に網掛けをして、実際に返却されて返却日が入力されたら、網掛けが消えるというマクロがつくりたいのですが。 素人なりに試行錯誤していますが、なかなか出来ずに困っています。 どなたか、わかりやすく教えていただけませんか。 第3正規化について 第3正規化について いつもお世話になっております。 第3正規化についての質問なのですが、理解できないので質問させて頂きます。 "t_携帯"というテーブルがあり、 [社員CD](一意) [氏名] [性別] [台数CD] [製造番号](一意) [メーカー名] [型名] [記憶媒体] [認証ID](一意?) [PASS] というフィールドがそれぞれ存在し、 [台数CD]フィールドの扱いがよく理解できなくて困っています。 例えばAさんが携帯を1台所持している場合、Aさんは[台数CD]フィールド'1'を持ち、 2台所持しているBさんは'1'と'2'を持ち、2台目以降の携帯情報が繰り返しとなるので 第1正規化するのは分かるのですが、それ以降の第3正規化までの手順と マスタ分けがよく分かりません。 ご教授の程、宜しくお願いします。 DBの正規化がわかりません・・・ こんにちは。 昔お世話になったペンションの顧客管理をファイルメーカーで作ろうかと思っています。ファイルメーカーも初心者ですが、DBも初心者です。そこでどうにか正規化をして 顧客マスター【顧客ID・氏名・ふりがな・郵便番号・住所・生年月日・電話番号・携帯番号・Fax番号・E-mail・宿泊回数】 部屋マスター【部屋ID・部屋名・分類(新館、ユニットバス付き等)】 飲み物マスター【飲み物ID・飲み物・料金】 温泉マスター【温泉ID・分類・料金】 宿泊テーブル【宿泊ID・日にち・夕食メニュー・朝食メニュー・日帰り温泉人数・宿泊人数】 明細テーブル(お客さんが何日にどの部屋に泊まり何を飲んだかを表示)【明細ID・顧客ID・部屋ID・宿泊ID・飲み物ID・消費税・総合計】 と正規化をしました。 わからないのは部屋の料金代をどこのマスターに入れたらいいかと言う事です。そこのペンションでは 大人の宿泊でも【新館・ユニットバス・朝食あり・なし・素泊まりなど】で料金が違いますので、部屋マスターに料金を入れるのは無理だと思います。どうしたらいいかご教授願えませんでしょうか?よろしくお願いします。 また参考になるサイトやソフト等があれば教えて頂けないでしょか?長々としてわかりにくいかもしれませんがよろしくお願いします。 主キーの選び方 主キーが良くわからなくなってきたので質問させてください。 このようなデータベースのとき、主キーは社員番号でいいですよね #同姓同名を考えると社員番号かと 社員番号|氏名|部署 0001|ほげ|デバッグ部隊 0002|ふー|リリース部隊 0003|ばー|クレーム対応部隊 0004|ばー子|接待ゴルフ部隊 0005|ほげ子|リリース部隊 ただ、部署を複数所属してよいとすると、社員番号だけが主キーだと行が一意に決まりません。 このときはどれを主キーとして選ぶべきなんでしょうか? また、○○部隊に所属するひとリストアップするにはどのように正規化(設計?)すればよいのでしょうか? 社員番号|氏名|部署 0001|ほげ|デバッグ部隊 0001|ほげ|接待ゴルフ部隊 0002|ふー|リリース部隊 0003|ばー|クレーム対応部隊 0004|ばー子|接待ゴルフ部隊 0005|ほげ子|リリース部隊 地元図書館の規則 地元図書館の去年からの新規則に疑問があります。 「継続貸し出しは1回まで」、ということ。 同じ本を3回連続で借りることはできません。 延滞してもそれは同じ。 しかし延滞してなくても3回目の貸し出しは不可ということ。 これはほかの図書館でも当たり前の規則なのでしょうか?? 正直、地元自治体があまり文化施設の運営に力をいれてないようで図書館も古いまま、利用者もあまりなく。規則のために返した本も予約が入っていることはあまりありません。 「延滞したら再貸し出し不可」というのならわかりますが、返却期限を守ってもそのような規則に縛られることに納得いきません。 この正規化アドバイス願います【初心者】 【アイテムテーブル】id | 名前 装備Lv 物理攻撃 魔法攻撃 特殊効果 【職業テーブル】job_id | 名前 【入手方法テーブル】map_id | マップ名 NPC名 【分類テーブル】 kind_id | 名前 【関連テーブル】id(外) job_id(外) map_id(外) kind_id(外) ※|の左が主キーです。 となってるんですが、1つのアイテムに特殊効果は複数付与される場合があります MP回復速度+2、MaxHP+20 MaxMP+10、魔法命中率+1%・・・ なので【アイテムテーブル】に特殊効果1 特殊効果2 特殊効果3としてしまうと正規化されません。。 この様な場合はどのように対処すればいいのでしょうか? というか、上のテーブルは正規化されてますよね? どなたかご教授願います。 注目のQ&A 「You」や「I」が入った曲といえば? Part2 結婚について考えていない大学生の彼氏について 関東の方に聞きたいです 大阪万博について 駅の清涼飲料水自販機 不倫の慰謝料の請求について 新型コロナウイルスがもたらした功績について教えて 旧姓を使う理由。 回復メディアの保存方法 好きな人を諦める方法 小諸市(長野県)在住でスキーやスノボをする方の用具 カテゴリ [技術者向] コンピューター データベース SQL ServerOraclePostgreSQLMySQLNoSQLその他(データベース) カテゴリ一覧を見る OKWAVE コラム 突然のトラブル?プリンター・メール・LINE編 携帯料金を賢く見直す!格安SIMと端末選びのポイントは? 友達って必要?友情って何だろう 大震災時の現実とは?私たちができる備え 「結婚相談所は恥ずかしい」は時代遅れ!負け組の誤解と出会いの掴み方 あなたにピッタリな商品が見つかる! OKWAVE セレクト コスメ化粧品 化粧水・クレンジングなど 健康食品・サプリ コンブチャなど バス用品 入浴剤・アミノ酸シャンプーなど スマホアプリ マッチングアプリなど ヘアケア 白髪染めヘアカラーなど インターネット回線 プロバイダ、光回線など