2016/07/02 YAP(achimon)C:: Asia Hachioji 2016 mid in Shinagawa

1. MySQLと正規形のはなし
申し訳ない、あんまりMySQLのはなし出てこなかったDeath
2016/07/02
yoku0825
YAP(achimon)C::Asia Hachioji 2016 mid in Shinagawa

2. ＼こんにちは／
yoku0825＠とある企業のDBA
オラクれない-
ポスグれない-
マイエスキューエる-
家に帰ると
妻の夫-
せがれの⽗-
ムスメの⽗-
⽣息域
Twitter: @yoku0825-
Blog: ⽇々の覚書-
MyNA ML: ⽇本MySQLユーザ会-
MySQL Casualʼs Slack: MySQL Casual-
1/87

3. これまでの
（︖）
あらすじ
2/87

4. あらすじ
MySQLで正規化すると遅くなる
あるある-
節⼦、それ正規化が原因やない、内側のテーブルでソートし
てるやんか
YAPC::Asia Tokyo 2014 WHERE狙いのキー、ORDER BY狙いのキ
ー
-
「正規化したら遅くなった」テーブルを⾒せてもらったら正
規形じゃなかった
テーブル分割≠正規化-
イマココ-
3/87

5. 正規形 #
とは
4/87

6. 正規化 #とは
関係の正規化（かんけいのせいきか）は、関係データベ
ース (リレーショナル・データベース) において、正規
形と呼ばれる形式に関係（リレーション）を準拠させる
ことにより、データの⼀貫性の維持と効率的なデータア
クセスを可能にする関係設計を導くための⽅法である。
関係の正規化 - Wikipedia
5/87

7. ｳｯ
6/87

8. 正規化 #とは
更新箇所を減らす1.
参照効率を上げる2.
データの整合性を守りやすくする3.
ためのテーブル設計のプラクティス集
“Normal Form” だから “標準系” とか “平坦化” とかでもい
い気がする（正規っていうと正誤の問題ぽく聞こえるから）
7/87

9. 正規形
第1正規形(1NF)
第2正規形(2NF)
第3正規形(3NF)
ボイスコッド正規形(BCNF)
第4正規形(4NF)
第5正規形(5NF)
第6正規形(6NF)
8/87

10. MySQLerが絶対に押えておくべき正規形
第1正規形(1NF)
第2正規形(2NF)
第3正規形(3NF)
ボイスコッド正規形(BCNF)
第4正規形(4NF)
第5正規形(5NF)
第6正規形(6NF)
9/87

11. 第1正規形
関係がスカラ値のみを持ちうるとき、その関係を第1正
規形 (first normal form; 1NF) であるという
関係の正規化 - Wikipedia
10/87

12. 第1正規形
全ての⾏の
全てのカラムの値が
それ以上分割できない値であるとき
俺はアトミックな値って良く⾔う
アトミックな値についてはあとで-
11/87

13. NOT NULLと候補キー
第1正規形の定義に⼊ってることもある
候補キーが無いと第2正規化のステップで詰まる
3NFを除いてこれ以降の正規化は全て候補キーを軸にテーブル分割す
る
-
NULLABLE(NOT NULLしてない)と、第3正規化のステップ
で詰まる
⼈間的な理屈で無理⽮理それっぽく分割することはできるけれど-
個⼈的にはこれらは第1正規形の前だと思ってる
12/87

14. 第2正規形
ある関係が、第1正規形で、かつ、すべての非キー属性
が、すべての候補キーに対して完全従属するとき、第2
正規形 (second normal form; 2NF) であるという
関係の正規化 - Wikipedia
13/87

15. （ ﾟдﾟ）
14/87

16. （ﾟдﾟ）
15/87

17. （ﾟдﾟ ）
16/87

18. 雑に⾏き
ます
17/87

19. 第2正規形
候補キー（PRIMARY KEYとUNIQUE KEYだけど、何らかの
事情で制約をかけていないものも含む）が複数のカラムで構
成されているときに（複合候補キー）
複合候補キーの⼀部が決まれば値が決まるカラム がないと
き
18/87

20. 第2正規形
候補キーが複数のカラムで構成されてない場合は 第1正規形 ⇔
第2正規形
第1正規形であって第2正規形でない例
(prefecture, city)がPRIMARY KEY-
19/87

21. 第3正規形
ある関係が、第2正規形で、かつ、非キー属性があるな
らば、それら全てが候補キーに非推移的に関数従属する
とき、第3正規形 (third normal form; 3NF) であると
いう
関係の正規化 - Wikipedia
20/87

22. 第3正規形
非キー属性（候補キーでないカラム）があるとき
ある非キー属性の値が決まると、値が決まるカラム がない
とき
NULLABLEなカラムがあると、そもそも「値が決まらなくなる」ので
何とも⾔えなくなる
-
21/87

23. 第3正規形
第2正規形であって第3正規形でない例
(name)がPRIMARY KEY-
実はもう⼀つ罠がある-
22/87

24. ボイスコッド正規形
ある関係上に存在する⾃明でない全ての関数従属性の決
定項が候補キーであるとき、かつそのときに限り、その
関係はボイス・コッド正規形 (Boyce/Codd normal
form; BCNF) であるという
関係の正規化 - Wikipedia
23/87

25. ボイスコッド正規形
候補キーが複数のカラムで構成されているときに
ある非キー属性の値が決まると、候補キーの⼀部が決まって
しまうものがないとき
24/87

26. ボイスコッド正規形
第3正規形であってBCNFでない例（︖）
PRIMARY KEY (ipaddr, port, process) に対して、protocolがわかれば
processは⼀意に決まる場合
memcachedとInnoDB memcached Pluginが混在するとこの前提は崩れる
-
25/87

27. ボイスコッド正規形
複合候補キーが複数 (ipaddr, port, process), (ipaddr,
port, protocol) あって、それぞれの真部分集合 (ipddr,
port) が重なってる場合にしか発⽣しない
候補キーの⼀部 と 非キー属性 (の全部または⼀部) から候
補キーの別の⼀部が決まるケース が ない
このへんから「制約」の側⾯が強まってくる
26/87

28. 第4正規形
第4正規形 (fourth normal form; 4NF) では候補キーで
はない属性への多値従属性をもった属性があってはなら
ない。
関係の正規化 - Wikipedia
27/87

29. 第5正規形
第5正規形 (fifth normal form; 5NF) を満たす関係は、
その関係が第4正規形であり、さらにその関係に含まれ
る結合従属性の決定項が候補キーのみである場合、かつ
その場合だけである。
関係の正規化 - Wikipedia
28/87

30. 先に⾔っておくと
BCNFを満たすリレーションのうち 非キー属性を持つものは
⾃動的に第5正規形
テーブルが 3カラム以上の複合候補キーだけで構成されてい
る場合のみ 第4正規化と第5正規化を考える必要がある
そんなテーブル作ったことあるお客様はいらっしゃいますか
29/87

31. 第4正規形
3カラム以上の複合候補キーのみで構成されるテーブルが1
つのカラムで交差している場合に分割する
30/87

32. 第5正規形
3カラム以上の複合候補キーのみで構成されるテーブルが2
つ以上のカラムで交差している場合に分割する
31/87

33. もうやめて︕
yoku0825のラ
イフはゼロよ︕
32/87

34. 第6正規形
A relvar R [table] is in sixth normal form
(abbreviated 6NF) if and only if it satisfies no
nontrivial join dependencies at all ̶ where, as
before, a join dependency is trivial if and only if at
least one of the projections (possibly
U̲projections) involved is taken over the set of all
attributes of the relvar [table] concerned.
Sixth normal form
33/87

35. 第6正規形
複数の非キー属性を持つテーブルを
1テーブルあたり1候補キー:1非キー属性に分割する正規化
ドメインキー正規形と呼ばれる場合も（定義がブレてるらし
い）
普通やらない
34/87

36. 第6正規形
5NFのこんなテーブルを
+------------------------------------------+------+------+------+
| _hash_ | flg1 | flg2 | flg3 |
+------------------------------------------+------+------+------+
| a12483faa7f1c90c568017314a7ffdc84b544bb1 | 0 | 1 | 0 |
| da0e9d085e8f3ac208a7c80567914c097a9cc72a | 0 | 0 | 0 |
| 8458992edfd5e49f99bafacd33b9cac30abb967b | 0 | 0 | 0 |
+------------------------------------------+------+------+------+
35/87

37. 第6正規形
こうじゃ
+------------------------------------------+------+
| _hash_ | flg1 |
+------------------------------------------+------+
| a12483faa7f1c90c568017314a7ffdc84b544bb1 | 0 |
| da0e9d085e8f3ac208a7c80567914c097a9cc72a | 0 |
| 8458992edfd5e49f99bafacd33b9cac30abb967b | 0 |
+------------------------------------------+------+
+------------------------------------------+------+
| _hash_ | flg2 |
+------------------------------------------+------+
| a12483faa7f1c90c568017314a7ffdc84b544bb1 | 1 |
| da0e9d085e8f3ac208a7c80567914c097a9cc72a | 0 |
| 8458992edfd5e49f99bafacd33b9cac30abb967b | 0 |
+------------------------------------------+------+
+------------------------------------------+------+
| _hash_ | flg3 |
+------------------------------------------+------+
| a12483faa7f1c90c568017314a7ffdc84b544bb1 | 0 |
| da0e9d085e8f3ac208a7c80567914c097a9cc72a | 0 |
| 8458992edfd5e49f99bafacd33b9cac30abb967b | 0 |
+------------------------------------------+------+
36/87

38. ドメインと命名
ルールとか考え
る時に便利
37/87

39. 正規形
第1正規形(1NF)
第2正規形(2NF)
第3正規形(3NF)
ボイスコッド正規形(BCNF)
第4正規形(4NF)
第5正規形(5NF)
第6正規形(6NF)
38/87

40. 正規形
2NF, BCNFとそれ以降への正規化は複合候補キーがある場
合のみ
4NF以降（ただし6NFを除く）への正規化は3カラム以上の
複合候補キーのみで構成される場合
だからだいたい1NF〜3NFまで（本当はBCNFまで）きっち
り把握してればプラクティスの使い⼼地（学習コストと得ら
れるメリットの割合）としては上々
39/87

41. ここまでのまとめ
正規化は
更新箇所を減らす＆参照効率＆データの整合性を上げるためのテーブ
ル設計のプラクティス集
-
1NF〜3NFは割と簡単かつ効果が⾼い
4NF以降は3カラム以上の複合候補キーのみのテーブルに対してのみ
考える
-
40/87

42. 第1正規形(again)
関係がスカラ値のみを持ちうるとき、その関係を第1正
規形 (first normal form; 1NF) であるという
関係の正規化 - Wikipedia
41/87

43. 第1正規形(again)
全ての⾏の
全てのカラムの値が
それ以上分割できない値であるとき
42/87

44. アトミッ
ク #とは
43/87

45. アトミック #とは
それ以上分割できない
1⾏に複数の（候補キーで識別されるべき）主体の情報が⼊ってはい
けない
-
1カラムに複数の種類の情報が⼊ってはいけない-
分割しすぎてもとの意味が失われていない
「⽂字列型は配列だから1⽂字ずつがアトミック（キリ）」とかいう
ことは起こらない
-
44/87

46. 1⾏に複数の主体
mysql57> SELECT * FROM t1G
*************************** 1. row ***************************
v: yoku0825@gmail.com: せがれが扇風機に向かってですます調で「ﾜ
ﾚﾜﾚﾊ、ｳﾁｭｳｼﾞﾝﾃﾞｽ」って言っててちょっと面白い季節がやってきま
した。
yoku0825@gmail.com: "Noted in 8.0.0 changelog." nnMySQL Bugs: #
81827: no stack trace on crash in freebsdnhttps://bugs.mysql.co
m/bug.php?id=81827
yoku0825@gmail.com: Workbench使いにとっては大事なことかもしれ
ない。nnMySQL Bugs: #81971: Needs HiDPI supportnhttp://bugs.my
sql.com/bug.php?id=81971
1 row in set (0.00 sec)
45/87

47. ⾏を分割
mysql57> SELECT * FROM t1G
*************************** 1. row ***************************
v: yoku0825@gmail.com: せがれが扇風機に向かってですます調で
「ﾜﾚﾜﾚﾊ、ｳﾁｭｳｼﾞﾝﾃﾞｽ」って言っててちょっと面白い季節がやって
きました。
*************************** 2. row ***************************
v: yoku0825@gmail.com: "Noted in 8.0.0 changelog." nnMySQL Bug
s: #81827: no stack trace on crash in freebsdnhttps://bugs.mysq
l.com/bug.php?id=81827
*************************** 3. row ***************************
v: yoku0825@gmail.com: Workbench使いにとっては大事なことかもし
れない。nnMySQL Bugs: #81971: Needs HiDPI supportnhttp://bug
s.mysql.com/bug.php?id=81971
3 rows in set (0.00 sec)
46/87

48. それでもまだ1カラムに複数の情報
mysql57> SELECT * FROM t1G
*************************** 1. row ***************************
v: yoku0825@gmail.com: せがれが扇風機に向かってですます調で
「ﾜﾚﾜﾚﾊ、ｳﾁｭｳｼﾞﾝﾃﾞｽ」って言っててちょっと面白い季節がやって
きました。
*************************** 2. row ***************************
v: yoku0825@gmail.com: "Noted in 8.0.0 changelog." nnMySQL Bug
s: #81827: no stack trace on crash in freebsdnhttps://bugs.mysq
l.com/bug.php?id=81827
*************************** 3. row ***************************
v: yoku0825@gmail.com: Workbench使いにとっては大事なことかもし
れない。nnMySQL Bugs: #81971: Needs HiDPI supportnhttp://bug
s.mysql.com/bug.php?id=81971
3 rows in set (0.00 sec)
47/87

49. カラム分割
mysql57> SELECT * FROM t1G
*************************** 1. row ***************************
u: yoku0825@gmail.com
v: せがれが扇風機に向かってですます調で「ﾜﾚﾜﾚﾊ、ｳﾁｭｳｼﾞﾝﾃﾞｽ」
って言っててちょっと面白い季節がやってきました。
*************************** 2. row ***************************
u: yoku0825@gmail.com
v: "Noted in 8.0.0 changelog." nnMySQL Bugs: #81827: no stack t
race on crash in freebsdnhttps://bugs.mysql.com/bug.php?id=81827
*************************** 3. row ***************************
u: yoku0825@gmail.com
v: Workbench使いにとっては大事なことかもしれない。nnMySQL Bu
gs: #81971: Needs HiDPI supportnhttp://bugs.mysql.com/bug.php?id
=81971
3 rows in set (0.00 sec)
48/87

50. ところで
49/87

51. yoku0825@gmail.com
ってアトミック︖
50/87

52. yoku0825@gmail.com はアトミックか
ほとんどのサービスにとってはアトミック
Twitter, Slack, GitHub, Oracle Single Signin On, ..-
yoku0825@gmail.com をメールアドレスだとしか認識してない⼈たち
アカウント名が yoku0825 なのは俺がそう設定したからであって、関連はない（彼ら
にとっては）
-
51/87

53. yoku0825@gmail.com はアトミックか
たまに、アトミックじゃないサービスがいる
GMail, その他MTAさんたち-
yoku0825@gmail.com は gmail.com の yoku0825 ユーザー
DNSさんにとっては gmail.com もアトミックじゃない
-
52/87

54. つまりアトミック #とは
設計次第
なんだけど
LIKE 演算⼦や SUBSTR 関数を使ってるなら、それは多分アト
ミックじゃない
⇔ アトミックなら LIKE 演算⼦や SUBSTR 関数を使ってない
配列型（MySQLにはない）やJSON型もBLOB型も、SQLからはPKで
引いてアプリケーション側でゴニョゴニョするならリレーショナルモ
デル的には正規形
-
SET型（こんなデータ型MySQLくらい︖）さん…-
53/87

55. 第2正規形(again)
ある関係が、第1正規形で、かつ、すべての非キー属性
が、すべての候補キーに対して完全従属するとき、第2
正規形 (second normal form; 2NF) であるという
関係の正規化 - Wikipedia
54/87

56. 第2正規形(again)
候補キー（PRIMARY KEYとUNIQUE KEYだけど、何らかの
事情で制約をかけていないものも含む）が複数のカラムで構
成されているときに（複合候補キー）
複合候補キーの⼀部が決まれば値が決まるカラム がないと
き
55/87

57. 第2正規形
第1正規形であって第2正規形でない例
(prefecture, city)がPRIMARY KEY-
prefectureが決まるとprefecture̲kanaは⼀意に決まる-
56/87

58. 第2正規形
57/87

59. 第2正規形
+--------------+----------------------+
| _prefecture_ | _city_ |
+--------------+----------------------+
| 北海道 | 札幌市中央区 |
| 北海道 | 札幌市北区 |
| 北海道 | 札幌市東区 |
+--------------+----------------------+
+--------------+-----------------------+
| _prefecture_ | prefecture_kana |
+--------------+-----------------------+
| 北海道 | ﾎｯｶｲﾄﾞｳ |
+--------------+-----------------------+
+--------------------+--------------------------------------+
| _city_ | city_kana |
+--------------------+--------------------------------------+
| 札幌市中央区 | ｻｯﾎﾟﾛｼﾁｭｳｵｳｸ |
| 札幌市北区 | ｻｯﾎﾟﾛｼｷﾀｸ |
| 札幌市東区 | ｻｯﾎﾟﾛｼﾋｶﾞｼｸ |
+--------------------+--------------------------------------+
58/87

60. 正規化の醍醐味
北海道の読みが「でっかいどう」に変わった時にテーブルま
るごと更新しなくていい
更新箇所を減らす-
prefecture vs. prefecture̲kana を⾒れば容量がコンパク
トになっているのは⼀目瞭然
参照効率を上げる-
city̲kanaはこの⾯微妙。。
カーディナリティー依存
-
北海道の読みが「ほっかいどう」であることを保証できる
（整合性の保証）
元のテーブルで SELECT DISTINCT prefecture_kana FROM .. WHERE
prefecture = '北海道' が2⾏返ってきちゃったら、どっちが正しい
のかは機械は判断できなくなる
-
59/87

61. 第3正規形(again)
ある関係が、第2正規形で、かつ、非キー属性があるな
らば、それら全てが候補キーに非推移的に関数従属する
とき、第3正規形 (third normal form; 3NF) であると
いう
関係の正規化 - Wikipedia
60/87

62. 第3正規形(again)
非キー属性（候補キーでないカラム）があるとき
ある非キー属性の値が決まると、値が決まるカラム がない
とき
61/87

63. 第3正規形
第2正規形であって第3正規形でない例
62/87

64. 第3正規形︖
63/87

65. 第3正規形︖
+----------------------+------------+
| _name_ | birthday |
+----------------------+------------+
| yoku0825 | 1982-08-25 |
| yoku0825の妻 | 19xx-01-17 |
| yoku0825のせがれ | 20xx-05-27 |
| yoku0825のムスメ | 20xx-01-05 |
+----------------------+------------+
+------------+-----------------+
| _birthday_ | birthday_stone |
+------------+-----------------+
| 1982-08-25 | ペリドット |
| 19xx-01-17 | ガーネット |
| 20xx-05-27 | エメラルド |
| 20xx-01-05 | ガーネット |
+------------+-----------------+
64/87

66. 第1非正規形になってしまった
birthdayがアトミックじゃない
+----------------------+------------+
| _name_ | birthday |
+----------------------+------------+
| yoku0825 | 1982-08-25 |
| yoku0825の妻 | 19xx-01-17 |
| yoku0825のせがれ | 20xx-05-27 |
| yoku0825のムスメ | 20xx-01-05 |
+----------------------+------------+
+------------+-----------------+
| _birthday_ | birthday_stone |
+------------+-----------------+
| 1982-08-25 | ペリドット |
| 19xx-01-17 | ガーネット |
| 20xx-05-27 | エメラルド |
| 20xx-01-05 | ガーネット |
+------------+-----------------+
65/87

67. 改めて第1正規系のプロセスを通すと第3正規形に
66/87

68. 改めて第1正規系のプロセスを通すと第3正規形に
+----------------------+------------+
| _name_ | birthday |
+----------------------+------------+
| yoku0825 | 1982-08-25 |
| yoku0825の妻 | 19xx-01-17 |
| yoku0825のせがれ | 20xx-05-27 |
| yoku0825のムスメ | 20xx-01-05 |
+----------------------+------------+
+------------+------------+
| _birthday_ | birthmonth |
+------------+------------+
| 1982-08-25 | 8 |
| 19xx-01-17 | 1 |
| 20xx-05-27 | 5 |
| 20xx-01-05 | 1 |
+------------+------------+
+--------------+-----------------+
| _birthmonth_ | birthday_stone |
+--------------+-----------------+
| 1 | ガーネット |
| 5 | エメラルド |
| 8 | ペリドット |
+--------------+-----------------+
67/87

69. キモい…
68/87

70. 現実問題、中間テーブルはかっ⾶ばす
name_birthday JOIN birthmonth_stone ON MONTH
(birthday) = birthmonth で仕留める
リレーショナルモデルの世界には MONTH 関数なんてないの
で、中間テーブルを作らないと birthday と birthmonth の
対応が取れない
そういう世界線なのだと割り切る-
現実世界では birthday が判れば birthmonth を⼀意に識別
できる
意味的に MONTH 関数が中間テーブルを提供してくれる-
69/87

71. さてみなさん
お気付きだろ
うか
70/87

72. 3NFまでの正規化では、分割の軸になったカラムが必ず新
しいテーブルの候補キーになる
71/87

73. 候補キーで分かれるという意味
そのリレーション（テーブル）で表現されるもの（=⾏）が
分けられるということ
name̲birthday は「⼈間」が主体（名前で識別される “⾏”）だろう
し
-
birthmonth̲stoneは「誕⽣⽉」が主体（1〜12で識別される “⾏”）
だろう
-
何の「属性」だかわからなくなったものを、それぞれ正しい「クラ
ス」に割り振り直すのが正規化
-
72/87

74. 候補キーで分かれることが実際に起こすもの
というわけでJOINのインデックスはPK狙いになる
MySQLはPK狙いのJOINならそれなりに速い-
というか PKで結合できないなら分割の仕⽅間違ってる
あるいは、正規化とは関係ない別のテーブル分割の問題-
過剰分割とかね-
73/87

75. 候補キーで分かれることが実際に起こすもの
そして出てくる 内側テーブルの “ORDER BY狙いのキー” が
選べない問題
真⾯目に（︖）正規化すると、サブクエリーやGROUP BYと
のJOINをしたくなる
SELECT user_id, tweet_count FROM user JOIN (SELECT user_id,
COUNT(*) AS tweet_count FROM tweet GRUOP BY user_id) USING
(user_id) ORDER BY tweet_count DESC ..
-
こんなことするとしんでしまいます
「正規化すると遅い」が真になる瞬間
-
74/87

76. ⽇常的にこんなクエリーが流れてくる世の中
75/87

77. 驚きのinnodb̲rows̲read
76/87

78. COUNTで死んでしまうこんな第5正規形を
77/87

79. COUNTを避けるためにテーブルをこうしたとしたら
78/87

80. それは正
規形︖
79/87

81. 正規形は正規形
「ただし、明らかに冗
⻑」by C.J.Date
80/87

82. 正規化かどうかは別として、同じフレームで評価すると
参照効率を上げる
成功してる-
更新箇所を減らす
2テーブル更新しなきゃいけなくなったから失敗してる-
整合性の保証
トランザクションがあるとはいえ制約は失った（=整合性は保証され
ない）
正しくトランザクションが使われている限りは 整合性があるけれど、 正しくトランザ
クションが使われていることそのものは誰も保証してくれない
-
81/87

83. あんまり望まし
い⽅向じゃなか
った(´・ω・`)
82/87

84. とはいえこれイン
デックスを思い出
しませんか︖
83/87

85. インデックス（ただし禁書目録ではない）
ソート済みのデータの複製
予めソートした状態でデータのサブセットを作っておくことで、検索
時の探索効率を上げる
-
重複をなくした設計にしましょうって⾔ってるRDBMSが基
本的な機能として、「データを敢えて重複させている」とい
うのは業が深くて考えさせられる
重複させても不整合が出ないように、重複させるオーバーヘッドを取
り除くために、裏側の実装はすんごくがんばってる
-
それと同じだと割り切れば、上⼿い使い⽅として付き合うこ
とはできる
FriendFeed では MySQL を使いどのようにスキーマレスのデータを
保存しているのか （⽇本語訳）
-
FriendFeedがFacebookに買収されてサービスを終了したので、原⽂はリンク切れ
-
84/87

86. 後半のまとめ
正規化は “⾏” が表すものをクラス化する作業
候補キーはインスタンス、非キー属性はプロパティーみたいな感じ-
⼿順通りに3NFまで正規化するとJOINはPK結合になるはず
PK結合にならなかったら正しく分割できていないか、正規化とは別の
テーブル分割をしたのか
-
別のクラスのプロパティーとして再定義することで（せめ
て）正規形を保ちつつ冗⻑な⽅向に倒す
インデックスと同じ考え⽅-
正規化と同じ評価軸を使うと、どこまで論理的にアレな感じかの尺度
として⾒られる
-
85/87

87. 参考情報
あなたが知らない リレーショナルモデル
理論から学ぶデータベース実践⼊門
Amazon.co.jp︓ SQL and Relational Theory
FriendFeed では MySQL を使いどのようにスキーマレスの
データを保存しているのか
Where狙いのキー、order by狙いのキー
86/87

88. Questions
and/or
Suggestions?
87/87