達人に学ぶDB設計～徹底指南書 初級者で終わりたくないあなたへ 電子書籍（ミック）｜翔泳社の本
  1. ホーム >
  2. 電子書籍 >
  3. 達人に学ぶDB設計～徹底指南書 初級者で終わりたくないあなたへ

達人に学ぶDB設計～徹底指南書 初級者で終わりたくないあなたへ

著

形式：
電子書籍
発売日：
ISBN：
9784798128931
価格：
2,860円（本体2,600円＋税10%）
カテゴリ：
データベース
キーワード：
#データ・データベース,#ネットワーク・サーバ・セキュリティ,#システム運用,#開発環境
紙の書籍
電子書籍
本書籍には新版があります
達人に学ぶDB設計徹底指南書 第2版

購入はこちら

企業・教育機関での一括購入

DB設計の基礎と実践ノウハウが身につく一冊

本書は、好評を博した『達人に学ぶ SQL徹底指南書』の続編という位置づけで、プロのデータベース（DB）エンジニアである著者が、DB設計の基礎と実践ノウハウをやさしく手ほどきする指南書です。初級者が押さえておくべきDB設計の基礎知識やポイント、正規化／非正規化のケーススタディ、テーブル設計のやってはいけないバッドノウハウ、注意すべきグレーノウハウなどを丁寧に解説します。豊富なサンプルと練習問題で、現場で通用する実践的な力が身につきます。DBエンジニアを目指す人、DB設計の基礎と実践をしっかり学びたい人、脱初級を目指すアプリケーション開発者やDBエンジニアなど、DB設計・開発に携わるすべての方におすすめの一冊です。

※本電子書籍は同名出版物を底本とし作成しました。記載内容は印刷出版当時のものです。
※印刷出版再現のため電子書籍としては不要な情報を含んでいる場合があります。
※印刷出版とは異なる表記・表現の場合があります。予めご了承ください。
※プレビューにてお手持ちの電子端末での表示状態をご確認の上、商品をお買い求めください。

（翔泳社）

目次の登録はありません。

付属データはこちら

お問い合わせ

内容についてのお問い合わせは、正誤表、追加情報をご確認後に、お送りいただくようお願いいたします。

正誤表、追加情報に掲載されていない書籍内容へのお問い合わせや
その他書籍に関するお問い合わせは、書籍のお問い合わせフォームからお送りください。

利用許諾に関するお問い合わせ

本書の書影（表紙画像）をご利用になりたい場合は書影許諾申請フォームから申請をお願いいたします。
書影（表紙画像）以外のご利用については、こちらからお問い合わせください。

追加情報はありません。
この商品の「よくある質問」はありません。

ご購入いただいた書籍の種類を選択してください。

書籍の刷数を選択してください。

刷数は奥付（書籍の最終ページ）に記載されています。

現在表示されている正誤表の対象書籍

書籍の種類:

書籍の刷数:

本書に誤りまたは不十分な記述がありました。下記のとおり訂正し、お詫び申し上げます。

対象の書籍は正誤表がありません。

最終更新日:2023年12月25日
発生刷 ページ数 書籍改訂刷 電子書籍訂正 内容 登録日
1刷 033
6行目		 17刷 済
誤 本書ではスタンダードなER記法
正 本書ではスタンダードなIE記法
備
考		 ※リフローEPUBの場合、「2-1 概念スキーマと論理設計」の「ER図の作成」の3つ目の段落が該当箇所になります。
2023.12.25
1刷 044
本文2行目		 17刷 済
誤 「パリティ」と呼ばれる誤り符号訂正符号を
正 「パリティ」と呼ばれる誤り訂正符号を
備
考		 ※リフローEPUBの場合、「2-2 内部スキーマと物理設計」の「③ RAID5」の1つ目の段落が該当箇所になります。
2023.12.25
1刷 092
4行目		 2刷 済
誤 　一方、正規化した「社員」テーブルおよび「扶養者」テーブル（89ページ）を見れば、それぞれ、 　　　｛社員ID｝　→　｛社員名｝ 　　　｛社員ID｝　→　｛子｝ という関数従属性が成立していることが見て取れます。
正 　一方、正規化した「扶養者」テーブル（87ページ）では、以下のような関数従属が成立しています。 　　　{社員ID} → {社員名} 　　　{社員ID} → {子1} 　　　{社員ID} → {子2} 　　　{社員ID} → {子3} 　また同様に、正規化した「社員」テーブルおよび「扶養者」テーブル（89ページ）についても、関数従属が成立します。 　「扶養者」テーブルの場合、{社員ID, 子}という主キー列しか存在しませんが、主キーは当然、主キーに従属するのです。
備
考		 ※リフローEPUBの場合、「3-4 第1正規形」の「なぜ一つのセルに複数の値を入れてはダメなのか？～関数従属性」の8つ目の段落以降が該当箇所になります。
2012.04.02
1刷 094
「会社」テーブル		 4刷 済
誤 会社名
正 会社名
備
考		 主キーではないためアンダーラインを削除します。

※リフローEPUBの場合、「3-5 第2正規形～部分関数従属」の「第2正規形を行なう」の2つ目の表「会社」が該当箇所になります。
2013.07.22
1刷 099
「会社」テーブル 		4刷 済
誤 会社名
正 会社名
備
考		 主キーではないためアンダーラインを削除します。

※リフローEPUBの場合、「3-6 第3正規形～推移的関数従属」の2つ目の表「会社」が該当箇所になります。
2013.07.22
1刷 100
8～11行目		 5刷 済
誤 {社員ID} → {部署コード} という関数従属が存在しています。つまり、全体としては、 {社員ID} → {部署コード} → {部署名} という二段階の関数従属があるわけです。
正 {会社コード, 社員ID} → {部署コード} という関数従属が存在しています。つまり、全体としては、 {会社コード, 社員ID} → {部署コード} → {部署名} という二段階の関数従属があるわけです。
備
考		 「{社員ID}」ではなく、「{会社コード, 社員ID}」になります。

※リフローEPUBの場合、「3-6 第3正規形～推移的関数従属」の「推移的関数従属」の3つ目の段落が該当箇所になります。
2013.11.07
1刷 101
「会社」テーブル		 4刷 済
誤 会社名
正 会社名
備
考		 主キーではないためアンダーラインを削除します。

※リフローEPUBの場合、「3-6 第3正規形～推移的関数従属」の「第3正規化を行なう」の2つ目の表「会社」が該当箇所になります。
2013.07.22
1刷 103
注釈※12の内容		 5刷 済
誤 推移的関数従属は、｛非キー｝ → ｛非キー｝の間に成り立つ関係なので、｛非キー｝ → ｛キー｝の関係を推移的関数従属とは呼ばないのです。
正 100ページの「社員」テーブルにおける、推移的関数従属は「部署コード」→「部署名」の部分です（非キー→非キーへの関数従属のため）。{会社コード, 社員ID} → {部署コード} は、キー→非キーの関数従属であるため、推移的関数従属にはなっていません。
備
考		 ※リフローEPUBの場合、「3-7 ボイス‐コッド正規形」の図3-3のすぐ上の段落にある注（※12）が該当箇所になります。
2013.11.07
1刷 106
下から4～2行目		 4刷 済
誤 　先ほどの失敗は、元のテーブル（上記）に存在していた以下の「第3」の関数従属性を失ったために起きたことでした。 　{社員ID}　→　{チーム補佐}
正 　先ほどの失敗は、元のテーブル（上記）に存在していた以下の関数従属性を失ったために起きたことでした。 　{社員ID, チームコード}　→　{チーム補佐}
備
考		 ※リフローEPUBの場合、「3-7 ボイス‐コッド正規形」の「ボイス‐コッド正規化を行なう」の最初の表「社員‐チーム‐リーダー」の下、2つ目の段落が該当箇所になります。
2013.09.13
1刷 107
「「社員 - チーム補佐」テーブルと「チーム補佐 - チーム」テーブルを内部結合する」上から2行目		 13刷 済
誤 社員 - チーム補佐.チームコード,
正 チーム補佐 - チーム.チームコード
備
考		 ※リフローEPUBの場合、「3-7 ボイス‐コッド正規形」の「ボイス‐コッド正規化を行なう」の3つめの表の下にあるSELECT文「社員‐チーム補佐」テーブルと「チーム補佐‐チーム」テーブルを内部結合する」が該当箇所になります
2020.10.26
1刷 112
「第4正規形」の「社員-製品」		 13刷 済
誤
正
備
考		 ※リフローEPUBの場合、「3-8 第4正規形」の「第4正規化を行なう」の2つ目の表「社員‐製品」が該当箇所になります
2020.10.26
1刷 120
分解後の「社員」テーブル		 2刷 済
誤
正
備
考		 「社員」テーブルには以下2行が必要です。

009F　田島
010A　渋谷

※リフローEPUBの場合、第3章の末尾にある2つのCOLUMNのうち2つ目の「損失分解」に掲載されている図「損失分解」の中の分解後の「社員」テーブルが該当箇所になります。
2012.04.05
1刷 122
演習3-1の「支社支店商品」テーブル、7～12行目		 2刷 済
誤
正
備
考		 以下、修正箇所です。

「支社コード」9～12行目（大阪）：002
「商品コード」7行目（箸）：005
「商品コード」8行目（スプーン）：006
「商品コード」11行目（雑誌）：007
「商品コード」12行目（爪切り）：008
2012.04.02
1刷 142
図5-1 「会社」テーブル		 4刷 済
誤 会社名
正 会社名
備
考		 主キーではないためアンダーラインを削除します。
2013.07.22
1刷 156
「勘どころ38」の下　本文4行目		 2刷 済
誤 本章では、かなりくどいぐらい非正規形の性能面での難点
正 本章では、かなりくどいぐらい正規形の性能面での難点
備
考		 ※リフローEPUBの場合、第5章の「5-2 非正規化とパフォーマンス」の「勘どころ 38」の下、2つ目の段落が該当箇所になります。
2012.03.21
1刷 158
上から9行目		 5刷 済
誤 DAOの大原則
正 DOAの大原則
備
考		 ※リフローEPUBの場合、第5章の「5-3 冗長性とパフォーマンスのトレードオフ」の「改修コストの大きさ」の最初の段落が該当箇所になります。
2014.03.07
1刷 178
「⑦暗黙の型変換を行なっている」の2番目のコード囲み		 2刷 済
誤
正
備
考		 2番目のSQL文はインデックスが有効なため「○」が正しいです。

※リフローEPUBの場合、第6章の「6-3 B-treeインデックスの設計方針」の「B-treeインデックスとSQL」の小見出し「■⑦ 暗黙の型変換を行なっている」の2つ目のSELECT文が該当箇所になります。
2012.04.05
1刷 206
9行目		 2刷 済
誤 DAOの原則
正 DOAの原則
備
考		 ※リフローEPUBの場合、「7-5 テーブル分割」の「水平分割」の小見出し「欠点2 拡張性に乏しい」の最終行が該当箇所になります。
2012.04.02
1刷 206
「欠点3 他の代替手段がある」：下から5行目		 2刷 済
誤 カーディナリティが大きく、
正 カーディナリティが小さく、
備
考		 ※リフローEPUBの場合、「7-5 テーブル分割」の「水平分割」の小見出し「欠点3 他の代替手段がある」の2つ目の段落が該当箇所になります。
2012.04.05
1刷 243
ページ下部、「■行待ちテーブル」		 2刷 済
誤
正
備
考		 「扶養者（行持ち）」テーブルの3～6行目（「子」列がNULLの行）は
不要です。

※リフローEPUBの場合、第8章の「8-3 列持ちテーブル」の「行持ちテーブル」の最初の表「扶養者（行待ち）」が該当箇所になります。
2012.03.16
1刷 244
「■行持ち⇒列持ちへの変換」リスト（ページ下部）のFROM句		 2刷 済
誤 FROM 被扶養者（行待ち）
正 FROM 扶養者（行待ち）
備
考		 テーブル名の「被」は不要です。

※リフローEPUBの場合、第8章の「8-3 列持ちテーブル」の「行持ちテーブル」の2つ目のSELECT文「■行持ち⇒列持ちへの変換」が該当箇所になります。
2012.03.16
1刷 307
「演習3-2　関数従属性」4行目		 17刷 済
誤 {商品コード} → {商品名, 商品分類コード}
正 {商品コード} → {商品名, 商品分類コード, 分類名}
備
考		 ※リフローEPUBの場合、「付録 演習問題の解答」の「第3章 解答」の「演習3-2　関数従属性」が該当箇所になります。
2023.12.25
1刷 337
6行目		 16刷 済
誤 また、また、異動によって
正 また、異動によって
備
考		 ※リフローEPUBの場合、「付録　演習問題の解答」の「第9章　解答」の「演習9-1」の解説における図Hのすぐ下の段落が該当箇所になります。
2022.10.04

感想・レビュー

わたなべ さん

2020-10-01

DBの設計に関して体系的に学べる。かなり基本的なことが書かれている印象。以下、個人的に参考になった箇所。①非正規化はパフォーマンス対策の最終手段（あくまで著者の意見だが）。②インデックスはカーディナリティが高くて平均的に分散しているレコードほど有効。③配列型のデータは、列持ちより行持ち。列持ちと行持ちは双方に容易に変換可能。

youkari117 さん

2019-03-18

電子書籍で読了。 本書はデータベースについて、論理設計の基本から正規化(第1~第5)、ER図、パフォーマンスとアンチパターン、そしてSQLでの木構造の取り扱いまで幅広な内容になっています。その分、それぞれの内容は必要最低限で深いというわけではありませんが、何を学ぶべきかを網羅的にカバーしている地図本として有用だと思います。 比較的読みやすいため、それほど読了まで時間はかかりません。 様々な物事にトレードオフの関係があり、それらを加味しつつ可能な限り論理設計に従うべき、という筆者の主張はよく伝わりました。

かなすぎ@起業したエンジニア さん

2020-04-18

第７章のバッドノウハウと第８章のグレーノウハウが面白くて特に勉強になった。 バッドノウハウについては、絶対しないだろうって思ってしまったので、自分が関わってる案件は苦しいところはあるものの、比較的テーブル構成がきれいで、かつ、先輩たちが自分に適切な指導をしてくれたんだなと実感して感謝の念しかない。グレーノウハウの判断は本当に難しいし、正解はないだろうな。一番最初にDB設計をする時にすべてを想定しきることはできないし、思わぬ仕様変更にも柔軟に対応するためには、グレーゾーンを責めないといけないのは納得。

関連情報