初めてのフレームワーク-Laravel5-3 DB周り用語整理

#Laravel & Markdown記法の勉強及びメモとして書いています。
間違えている点ございましたら、ご指摘いただけますと大変ありがたいです。よろしくお願いいたします。

##LaravelでDB使用する前に
まず、データベースについて復習
[そもそもリレーショナルデータベースって何？](http://www.atmarkit.co.jp/ait/articles/0807/16/news149.html)より

####データベースの種類
> - 階層型
> - ネットワーク型
> - リレーショナル型

とあるが、現在の主流はリレーショナルデータベース(RDB:Relational Database)
特徴として

> - データは2次元の表形式で表現される
> - **リレーション（複数の表を結合）**が可能

####**リレーショナルデータベースは基本的に複数の表からなる**

何故複数の表にするのか？
 → データの重複を避けるため
（重複するとデータ量が増えるし、修正時も2か所修正が必要になる）
そのために、**正規化**と呼ばれる1つの表を複数の表に細かく分ける作業が必要

####DOA(データ中心アプローチ)
ビジネスの変化に最も影響されにくいデータを中心として、システム基盤が全体的に最適な状態になるよう構築する考え方。

> - データの収集分析
> - データの整理統合
> - データを管理しやすくモデル化
が必要となる。

####SQLの代表的なアクセス方法
1.全表スキャン
SQLで指定された表のすべてのデータにアクセスして、WHERE句の条件を満たす行を1行ずつチェックする方法
全データにアクセスするため、少ないデータしかいらない場合は効率悪い
一方、一回でメモリ上に全てのデータを読み込むので、大半のデータが必要な場合は効率的

2.索引スキャン
自分でよく使う検索項目に索引(インデックス)つけておく方法。
全表スキャンに比べて、アクセス対象行が少ない(レコード全体の5～15%程度)ほど高速に処理できる。
一方、無駄な索引があると、INSERT処理時に索引へ自動的に新規データが追加されるので、INSERT処理の速度が低下する。
インデックスについては、下記を見る。
[DBパフォーマンスチューニングの基礎：インデックス入門](http://www.slideshare.net/simosako/rdb)

###データベースの設計
教えてもらったことメモ
・英語名に統一（日本語名でもOKだが、日本語、英語入り混じるのはNG)
・プレフィックス(wp_とか接頭語）は使わない。（賛否両論あり）
・エラーログのようにデータが少なくて、量が多いものはＤＢに入れずに、CSVとかTEXTで保存する。
・基本的に正規化して、正しくINDEXを付けるようにする。（1億レコードとかになるなら、非正規化も考える。）

####正規化
[正規化の手順](http://www.atmarkit.co.jp/ait/articles/1109/07/news124.html)
正規化自分用作業メモ
１．とりあえず上に沿って正規化してみる。
コツ：同じカラム名が繰り返されていたり（image1,image2,image3)、データベース内に配列が存在していたりする場合は、別テーブルに分ける。
２．テーブル間の関係を、1対1の関係、1対多の関係、多対多の場合に分類する。
（例：twitter)
・1対1の関係：ユーザアカウント情報とユーザプロフィール情報（1人のユーザの違う種類の情報）
・1対多の関係：ユーザとユーザがつぶやいたツイート（1人のユーザが多量のつぶやきをする。）
・多対多の関係：ユーザ間のフォロー（複数のユーザが複数のユーザをフォローする。）
３．1対1の関係があった場合：正規化ミス。多対多の関係があった場合：もう一つテーブル増やす。
４．全部テーブル間の関係が1対多になるようにする。

##Laravelでのデータベース操作について概論
### 1.クエリービルダー(DBファザード利用)
[日本語ドキュメント-クエリービルダー](http://readouble.com/laravel/5/1/ja/queries.html)
SQLが簡単に書けるようになっている。

### 2. Eloquent ORM

LaravelではDBとモデルオブジェクトを対応付ける機能。アクティブレコードと呼ばれるデザインパターンを採用。
####ORM(O/Rマッピング,Object/Relational Mapping)
[O/Rマッピングの役割とメリット](http://www.atmarkit.co.jp/ait/articles/0404/13/news075.html)
オブジェクト指向言語で扱う「オブジェクト」と「リレーショナルデータベース」を対応付け（Mapping)すること。

#####O/Rマッピング(ORM)が登場した背景にある問題
1.インピーダンスミスマッチ

 - リレーショナルデータベース設計：
 データベースの検索や登録更新処理に最適な設計
 - オブジェクト指向設計
 システムを相互左右するオブジェクトの集まりとしてモデル化する方法

これら二つは設計思想の違いから、データモデル上のミスマッチが生まれる。そのため、それぞれのデータを紐づける必要があるが、煩雑な作業なのでミスやバグが出やすい。

2.非オブジェクト指向の言語による阻害

SQLは非オブジェクト指向言語なので、オブジェクト指向プログラミング内に紛れ込むと、オブジェクト指向プログラミングが難しくなる。

#####O/Rマッピング(ORM)の意義
 - プログラマが書くはずのSQLを代わりに内部で生成してくれる。

O/Rマッピングフレームワークを使うとさらに、

 - データベース接続や例外処理のコード簡素化。
 - 自動でマッピングに必要なソースが生成される。

というメリットなどがある。

####Eloquent ORM を利用の注意
EloquentはActiveRecordパターンを使用。
[デザインパターンから見たActiveRecord](http://www.techscore.com/tech/Ruby/Rails/other/designpattern/1/)
#####ActiveRecordパターンの特徴
> - テーブルとモデルクラス、行とインスタンスは1対1で関連付られる。
> - モデルクラス、インスタンスメソッドで関連する処理を行う。= コントローラー肥大を防げる。
> - データベース操作をオブジェクト指向の表記で行う。
> - データベースに保存する前にValidationを行う。

#####ActiveRecordパターンの欠点
1つのモデルクラスは1つのテーブルを表す。
そのため、**非正規化**のままのものや、細部まで**正規化**されすぎたデータベース設計を行うとモデルクラスが使いにくい。
**データベース設計が非常に大切!!**

単体テストがしにくい？
→これはリポジトリパターンを使うことで対処可能
[Laravel4.2のリポジトリパターン](
http://tech.aainc.co.jp/archives/10227)

細かいデータベースの操作方法はマニュアルを参考
[Laravel5.1:データベース](http://readouble.com/laravel/5/1/ja/database.html)
[Laravel5.1:Eloquent](http://readouble.com/laravel/5/1/ja/eloquent.html)