雑に読む「達人に学ぶDB設計徹底指南書」
達人に学ぶDB設計徹底指南書を雑に読む
2016年初版第7刷
目標
何日かに1回読む
雑で構わない。一通り目を通してどこに何の話題があったかをさらってみよう
実例は大切にしよう
第3章はじっくり読む
> 第1章 データベースを制する者はシステムを制す
1-1
今日のシステムでデータベースのないシステムはない(p.4)
1-2
データベースの代表的モデル
/excel-jp/データベースも参照する
この本で扱ってるのはRDBの設計技法
オブジェクト指向DB
XMLをつかう
XMLってなんだろう？
マークアップ言語というらしい
…
1-4
データの意味や形式を先に決める
オブジェクト指向アプローチ（OOA）とは相性が悪い
ユーザーから見たデータベース
UIが関係してくる
開発者から見たデータベース
データ同士の関係を記述する
設計の中心となる
概念スキーマで定義された論理データモデルをどうやってファイル内に格納するか定義する
物理スキーマともいう
> 第2章 論理設計と物理設計
2-1 概念スキーマと論理設計
エンティティはデータの集合体のこと
物理的実体に対応するものもあれば、対応しないものもある
たとえば？
いい感じの喫茶店つき本屋を頭に浮かべる
物理的実体に対応する
本
文房具
コーヒー
ケーキ
…
対応しない
出版社
購入履歴
利益
…
このエンティティを格納するのがテーブル
本テーブル、文房具テーブル、コーヒーテーブル、ケーキテーブル…
ケーキテーブル例
| 名前 | 値段 | … |
| チーズケーキ | 750 | |
| ミルクレープ | 800 | |
| モンブラン | 780 | |
| いちじくのタルト | 820 |
エンティティの定義 p.31
抽出したエンティティにどういうデータを持たせるかを決める
上のケーキテーブルだと、「名前」「値段」という属性でデータを保持しているわけだな
他にも属性があるかも
「季節商品」
「合うドリンク」
「在庫数」
これは在庫テーブルを作るほうがよさそう
…
例
シャトレーゼのクリスマスケーキ
| 名前 | 本体価格 | 商品番号 | サイズ | ... |
| Xmas2つの味が楽しめるデコレーション14cm（苺なし） | 2,400 | 993180 | 14cm | |
| Xmasパリパリチョコデコレーション17cm | 3,200 | 993183 | 17cm | |
| 乳と卵と小麦粉を使用していないXmasデコレーション15cm（苺なし） | 3,000 | 993188 | 15cm | |
| Xmasアイスアソートケーキ THE ICE CREAM SHOP 21cm | 3,500 | 993193 | 21cm |
このテーブルで今のデータが全部だとするとキー列は別にどれでも良いっちゃいい
どれも一意に定まる
でも商品番号にしておくのがいいんだろうな
本体価格は同じのが出るかもしれないしサイズも然り
そうですね
アソートケーキが品切れでした
更新が整合的に行えるように、エンティティのフォーマットを整理するのが目的(p.32)
第3章で詳しく解説
エンティティ同士の関係（relationship）を表現するための図のこと
第4章で詳しく解説
RDBで重要な概念
なんで？
第6章のパフォーマンスで関わってくるらしい
大量のデータの中から必要なデータを素早く引くための工夫なので重要
データ構造には木構造が使われる
🤔
この著者、基本的にわかりやすいのにインデックスの説明は下手な感じがある
インデックスの概念を知らない人に最初からアルゴリズムの話を持ってくるのは不親切(他の本でもそうだった)
↓この発表は説明の順序が非常に良い
ありがとうございます！
ストレージを冗長化してシステムの信頼性を高める
2-3 バックアップ設計
2-4 リカバリ設計
> 第3章 論理設計と正規化-なぜテーブルは分割する必要があるのか?
3-1 テーブルとは何か？
テーブルは「表」と似てるが違うもの
こういうのはRDBにおけるテーブルにはならない
テーブルじゃない表
| 9月 | 10月 | 11月 | |
| すりきず | 5 | 1 | 12 |
| きりきず | 4 | 8 | 5 |
| だぼく | 15 | 20 | 38 |
| ごうけい | 24 | 29 | 55 |
この表を正規化したい場合、どのようにすればいいだろうか？
傷マスタテーブルと負傷ログテーブルを作りそう
ログテーブルのレコードにタイムスタンプを付しておいて検索して集計したい
実際のSQLのやり方はなんもわからん
「本物のテーブル」が出てきた(p.70)
山岡さんみたいだ
同じレコードが存在してはならない
普通のRDBはやろうとしても挿入できないので安心
ちゃんと設計していればの話
一意性制約という
3-2 テーブルの構成要素
属性ということもある
キー：ある特定のデータを引き出すための鍵
テーブルに課す代表的制約
データベースにデータを登録するとき、空欄(
null )を許さないこともしnullを許すとどうなるんだろう？
おっ著者だ
>1. SQL の作成にあたり、人間の直観に反する3値論理を考慮せねばならない。
> 2. IS NULL、IS NOT NULL を指定する場合、インデックスが参照されないためパフォーマンスが悪い。
> 3. 四則演算または SQL 関数の引数に NULL が含まれると「NULL の伝播」が起こる
> 4. SQL の結果を受け取るホスト言語において、NULL の組み込み方が標準化されていない。
> 5. 通常の列の値と違って、NULL は行のどこかに余分なビットを持つことで実装されている。そのため記憶領域を圧迫したり、検索パフォーマンスを悪化させる。
まだわからん。先！
ある列のデータに対して一意性を求めること
主キーのような振る舞いを他の列に適用する、ようなものかな
指定した条件を満たしたデータだけしか記録できないようにすること
変数の範囲を設定する感じか
3-3 正規化とは何か？
データの冗長性を排除して、利用しやすい形に変形すること
正規化で作られるデータを正規形という
よく「冗長性を持たせて」って言われるけど、ここではむしろ「冗長性」は減らす対象なのか～
冗長性、知ってるつもり単語だった
冗長性を持たせたいものの例
ScrapboxのWebサーバー
冗長性を持たせたくないものの例
マスターデータ
2つのマスターデータが...どっちが本当なの？
正規化には何段階かのレベルがある
1つのセルに一つの値しか含まない状態
この値をスカラ値(scalar value)という
複数の値を含んでいるとダメ
「修正後」は第1正規形になってる、ってことだな
よくみる表はだいたいこれ
完全関数従属のみのテーブルになっている状態
完全関数従属って何？
主キーを構成するすべての列に従属性がある場合のこと
1. 主キーを決める
上だと
伝票番号 と 商品番号 2. 部分関数従属を排除する
主キーの一部の列に対して従属する列
上の例だと３つのテーブルに分解できる
1.
伝票番号 が決まると お得意先番号 と お得意先名 が決まる2.
商品番号 が決まると 商品名 が決まる3.
伝票番号 と 商品番号 の２つがあれば 数量 が決まる最初はここまで覚えれば十分、とのこと
未来に参照
>いまここ
> 第4章 ER図-複数のテーブルの関係を表現する
> 第5章 論理設計とパフォーマンス-正規化の欠点と非正規化
> 第6章 データベースとパフォーマンス
> 第7章 論理設計のバッドノウハウ
> 第8章 論理設計のグレーノウハウ
> 第9章 一歩進んだ論理設計-SQLで木構造を扱う
> 付録 演習問題の解答
https://algo-method.com/courses/33 でオンライン実行環境&説明があるので使えることもあるかも
時が来たら試してみます
理解が曖昧なので読みたい
買った。達人になるぞ
業務でRDBMSを触っててわからんことがおおい
理論的側面を求めている(やりがち)
歌人もRDBMSを触る時代！
和歌を読解するけど作らない
これは何人ですか？
何ていうんでしょうね…
プレイする人ではないので観客？
和歌の観客
業務でRDBMSを使うが、「テーブルとは」みたいになるシチュエーションのように見える
知ってた上で改めて精読してる可能性もある
まぁでも、うちの妻もデザイナーだけどSQL書かされてたな、、
自分もよくわかりません…