ディレクトリ
エピソード
最近、少しいとこの遠い親戚はプロを取ることを計画して
くれと頼んを見つけること：
"哥，现在学数据库有没有前途阿?"
"当然有啊，前途大大的呢"
"那我现在开始学数据库，需要先从什么开始呢?"
"学课程的话，先了解下数据库三范式，SQL这些吧"
"SQL我大概知道，数据库三范式是什么？"
"阿...三范式就是表的主键...唯一性那些东西吧，...嗯，应该就是那些"
"什么是主键？"
"额.....表弟你不要再问了啦，好好去百度一下行不。"
"噢...."
電話をぶら下げた後、彼らはこの紛れもない事実の3つのパラダイムを覚えておくことはほとんどないエクスポージャーを持っているとして、私は、ため息をつく、私は静かにグーグルを開いた....
大学の教科書の混乱から、3つのデータベース・パラダイムの概念、私はほとんどの人が不慣れではないと考えているが、（データベース・システムでは、この物質の導入があるはず、正しく覚えている）に広がっています。
でも、技術的な部分で、特に優れた履歴書の書き方を知らない、ちょうど彼の能力が小さすぎるためで、インターンシップを探して開始することを忘れないでくださいことは空白になっています。
以来募集し、今後数専制君主は、参照を行うことを学ぶ再開され、すべての人の履歴書上で見たことがなかった笑氏は述べています：
データベースシステムの開発言語に堪能三のmasterデータベースのパラダイム、。
それともある：
3つのパラダイムを満たすために、データベースの設計を可能に馴染みのER図作成ツール
三つには、データベースのパラダイムは3つの公式パラダイムの技術的な詳細にインタビューの質問は、彼が驚い感じていることを確かに良いことだと損失で感じるようになりました。
緩やかな既知の仕事の経験では、私の心の中で、データベースのパラダイム論の強い印象が徐々に解消します。私が思うに、どちらかの不況のメモリ、またはいくつかの原則は本能的な経験を形成していること。
ですから、データベースのパラダイムは何ですか？
3つのパラダイムの定義
ここでは、情報は掃いて捨てるほどある、理論的な事柄を議論するためにあまりにも多くのスペースを費やす必要はありません。私たちは、味にいくつかの簡単な例を持っています。
1.第1正規形
アドレス情報も記録されている、上記ユーザIDに加えて、ユーザ情報テーブルを仮定する、名前：
| 番号 | フルネーム | 性別 | 場所 |
|---|---|---|---|
| 0001 | ジョー・スミス | 男性 | 広東省、深セン市 |
| 0002 | ジョン・ドウ | 女 | 海南、海口 |
：それは、最初のパラダイム（1NF）と一致しない列アドレス情報は
第1正規形（1NF）：データベーステーブルの各列は不可分原子エントリであります
したがって、それはに分割する必要があります。
| 番号 | フルネーム | 性別 | 所在省 | 都市 |
|---|---|---|---|---|
| 0001 | ジョー・スミス | 男性 | 広東省 | 深セン |
| 0002 | ジョン・ドウ | 女 | 海南 | 海口市 |
2.第2正規形
テーブルの注文は、例えば、通常次のように順番にダウン単一淘宝網内の複数の項目を含む作り出します。
| 注文番号 | 製品番号 | 製品名 | 価格 |
|---|---|---|---|
| O1 | G1 | 洗濯洗剤 | 23 |
| O1 | G2 | ヘアードライヤー | 125 |
| O1 | G3 | 空豆 | 5 |
| O2 | G9 | キルト | 302 |
| O2 | G8 | 枕 | 69 |
：ここで再び第二のパラダイム定義に違反
秒のパラダイム（2NFを）：各テーブルには主キー（主キー）の唯一の1つのデータ要素を持っている必要があり、他の属性は完全に主キーに依存する必要があります
第二のパラダイムは、最初のパラダイムを満たすことに基づくことが必要です
第二のパラダイム最初の要件は、上記の表の一意の主キーの存在であり、それがなければならない要件を満たすために共同主キーとして注文番号、商品番号です。
だから、第二の点のためにそれを求めますか？他のプロパティは、主キーに依存している場合？
注文のシナリオでは、商品価格も名前が変更される可能性があるため、これが正当化されるが、各注文の情報は、同じに見られるべきであると言うことができます
見たくない人自分の注文に製品情報がすでに急に価格を支払った。..何より重要なのは、商品価格の記録との整合性を維持するための合計金額です。
だからここにオーダーを作成する際に、レコードは、製品情報のスナップショットと考えることができます。
ただし、このシナリオを以下では適切でない可能性があります。
| 注文番号 | 製品番号 | 製品名 | 価格 | カテゴリ |
|---|---|---|---|---|
| O1 | G1 | 洗濯洗剤 | 23 | 世帯 |
| O1 | G2 | ヘアードライヤー | 125 | 電動 |
| O1 | G3 | 空豆 | 5 | 食べ物 |
| O2 | G9 | キルト | 302 | 世帯 |
| O2 | G8 | 枕 | 69 | 世帯 |
製品の種類は、一般的に固定されている、すなわち、プライマリキーの一部にのみ依存している製品番号、関連付けられた商品カテゴリ属性。
これにより、第2のパラダイム商品情報テーブルを分離する性質を必要とする、「他のプロパティは、主キーに完全に依存しなければならない」のルールの違反です。
3.第3正規形
私たちは、ユーザ情報テーブル場合、ユーザテーブルの先頭に戻る都市についてのいくつかの情報を追加してみましょう：
| 番号 | フルネーム | 性別 | 街 | 注目の都市 | 都市人口 |
|---|---|---|---|---|---|
| 0001 | ジョー・スミス | 男性 | 深セン | テクノロジーとイノベーション | 1300W |
| 0002 | ジョン・ドウ | 女 | 海口市 | 観光 | 230W |
これは、第三のパラダイムの定義に違反することになります。
第三のパラダイム（3NF）：表の各列および主キーのデータに直接関連するが、直接関係しません
同様に、第3のパラダイムは、第二のパラダイムに基づいてする必要があります
もちろん、ここでは都市人口、機能やその他の属性は、ユーザーだけの街ではなく、ユーザーに依存だし、それが唯一の間接的な関係とみなすことができます。
そこで、最善のアプローチは、都市情報テーブルに市関連のプロパティを分離することです。
なぜパラダイム
データベースのパラダイムは、教材の数ではなく、キーコースコンテンツとしてデータベースの設計、開発、のための参照モデルを提供します。
その後、パラダイムは、問題を解決するために提案されていますか？
最初のパラダイムは、要件が最も小さい部門として表示されます、我々はコラム行動の冗長ストアの複数の値排除したい
、そのようなユーザアドレス情報テーブルなどを省、市場など明確な、独立したプレスに分割フィールド検索、クエリ第二のパラダイムは、一意のプライマリ・キーを必要とし、そこに主キー列に部分的に依存する冗長（冗長）テーブルを除去することが望ましい
ような商品分類Ordersテーブルとして、情報の詳細は、唯一の商品情報を格納するテーブルが必要それはすることができます。第三のパラダイムは、まだテーブルの冗長列を排除するプライマリキー列に間接的に依存しては要求、ありません
、このようなユーザテーブルとして、それは都市の人口で、追加の情報、および市内の他の機能を保存する必要はありませんが。
明らかに、これらのパラダイムを排除するために、ストレージ・コストの削減は、主に冗長で可能提案されています。
PS：あなたは所有者がお金を節約することができ、3つのパラダイムを知って、不思議あなたの履歴書上の書き込み..
この資料に記載された3つのパラダイムに加えて、本質的にBCNFパラダイム、第四、第五のパラダイムがあります。
3つのパラダイムの概念を使用すると、データベースのテーブル構造は非常に洗練されて設計することができます。しかし、既存のプロジェクトのアプリケーションは完全ので、パラダイムの概念に準拠していません。
パフォーマンス上の理由から、冗長性テーブルのデザインはありません多くの時間データベースIO操作を意味し、より多くの問い合わせの動作を生成します。いくつかのリアルタイムのインタラクティブシステムでは、それは耐え難い遅くなることがあります。
もちろん、この問題を軽減するために提供されるデータベースに参加するには、データベース（参加）操作への接続を使用することができ、かつ事実です。しかし、一度フロントサブライブラリーサブテーブルのプログラムを使用し、この問題は非常に困難になります。成本结构的变化，数据库范式是在20世纪提出的，当时的磁盘存储成本还很高。随着科技发展，数据存储的成本已经大幅度缩减，对于采用范式设计(规避冗余)带来的成本缩减收益已经不那么明显。
反范式设计
既然范式是为了消除冗余，那么反范式就是通过增加冗余、聚合的手段来提升性能。比如，为了提升查询的性能，在CMS的文章表中同时冗余作者的信息。
当然，除了冗余(存储多份拷贝) 之外，还有另外的理念，即数据的聚合，或者叫嵌套。这种做法相当于是将多个字段(列)合并存储到数据库表的一个列中。
比如一条订单数据就可以同时包含许多信息：
{
"oid": "0001",
"price": {
"total": 380,
"benefit": 40
},
"goods": [{
"gid": "SN001",
"name": "蓝月亮洗衣液",
"price": 41,
"amount": 2
},
{
"gid": "SN003",
"name": "电动剃须刀",
"price": 99,
"amount": 1
}
],
"address": {
"contact": "张三",
"phone": "150899000"
...
}
...
}这种灵活的结构几乎是 NoSQL的专利，比如MongoDB文档数据库就可以直接以内嵌数组、对象的形式来实现聚合式存储，这无疑带来了极大的灵活性。
而 MySQL 在5.2.7版本开始支持JSON结构化列，也进入了聚合式存储的队伍，与其对标的PostGreSQL 则是9.4版本就已经支持。
反范式的设计在互联网项目、开源产品中也非常之常见，比如大名鼎鼎的Discuz 的数据表设计中就存在许多的冗余列、聚合字段。
一方面，除了能获得性能的提升之外，数据压缩、高度灵活扩展(非结构化) 也是反范式设计能获得青睐的理由。
当然，这里并非一律反对数据库范式，理解范式仍然是做好数据库设计的一门基础，比如选择合适的主键、清晰的划分每一列属性等等。
在项目中仍然需要根据自身的业务特点在范式和反范式中找到平衡点(通常是两者的结合)。类似于架构设计中空间换时间的一些做法，这其中涉及到的各种取舍都是需要经过权衡的。
也可以说这是一门艺术，因为没有标准答案...