前言

前面已經帶大家入門了MySQL，還沒看的可以先看一下那一篇：MySQL見聞錄-入門之旅由作者傾心打造，你值得擁有，

入門之后嘛，我帶隊正在做一個小專案，1.0版本需要涉及一個資料庫，但是我發現我居然設計不出來，我發現，快速入門始終是基礎不牢，還是得回爐重造，

本文略長，先收后看，不然劃著劃著就丟嘛了，

最后，再提一句：本系列屬于關系型資料庫-MySQL的文章，系列中所有“資料庫”字眼默認為MySQL資料庫，如果想看非關系型（nosql）的文，我也有幾篇redis，最近老師也在教，過段時間會陸陸續續出redis、HBase、MongoDB等方面的文，

關系資料庫

NoSQL出沒，學習MySQL還有錢途嗎？

首先，我們看一下大佬的介紹：

1、 MySQL資料庫最為流行的開源資料庫
2、 全球前20大互聯網網站有18家使用了MySQL，
3、 前10大獨立軟體開發商，有8家采用了MySQL資料庫
4、 在云的平臺架構下，市場占有率第一的云資料庫，
5、 大資料平臺下，80%與大資料平臺所集成，因為MySQL是互聯網應用，互聯網負責產生內容，Hadoop負責內容消費，形成開源的趨勢，OLTP在線事務使用MySQL資料庫，OLAP離線分析，使用Hadoop發展趨勢，

再來幾張招聘需求，一圖勝千言：

所以，我的建議是你先想清楚自己的崗位需不需要這個東西，或者自己以后需不需要這個東西，
當然，如果你是想博百家之長而自成一派，那MySQL會有很多不錯的思想給到你啟發，

資料模型

這一塊是我這一部分重點要寫的，不為什么，因為我不會，

做專案之前需要進行專案立項，需求分析，而資料庫的設計亦是如此，我苦惱于難以設計出一套適用于我們這個專案的資料庫模型，我知道我菜，后面我會把我的問題提出來，大家可以幫我一起想想，（雖然我已經有了想法，老師教我的）

資料模型是一種對現實世界資料特征的抽象，是資料庫系統的核心和基礎，

資料模型應滿足三方面的要求：

1.比較真實的模擬現實世界
2.容易為人所理解
3.便于在計算機上實作

概念模型：是從普通用戶的視角來描述資料的，使用簡單的符號來描述資訊，沒有嚴格的規定，只要能清晰反映現實世界的資訊就行，常用的就是E-R圖，

常用的資料模型

資料庫領域中主要的邏輯資料模型有：

層次模型
網狀模型
關系模型
面向物件資料模型
物件關系資料模型
半結構化資料模型

資料結構、資料操作和資料完整性約束這三個方面的內容完整的描述了一個資料模型，

層次模型

將資料組織成一對多關系的結構，用樹形結構表示物體及物體間的聯系，

來個例子啊：

那其中一條資料是長什么樣呢？

優點

層次模型的資料結構比較簡單清晰
查詢效率高，性能優于關系模型，不低于網狀模型
層次資料模型提供了良好的完整性支持

缺點

結點之間的多對多聯系表示不自然
對插入和洗掉操作的限制多，應用程式的撰寫比較復雜
查詢子女結點必須通過雙親結點
層次命令趨于程式化

可見，用層次模型對具有一對多的層序聯系的部門描述非常自然、直觀、容易理解，

網狀模型

然而事事盡如人意？顯然不會的，在現實世中事物之間的聯系更多的是非層次關系的，

定義：用有向圖表示物體和物體之間的聯系的資料結構模型稱為網狀資料模型，

差不多，我們的專案就是這么個一團亂麻，，，

優點：

網狀資料模型可以很方便的表示現實世界中的很多復雜的關系；

缺點

抽象啊，實在是抽象啊，你別看這圖話這容易，你改成表試試，會抓狂的！！

關系模型

關系模型是最重要的一種資料模型，

關系模型與前面的模型不同，它是建立在嚴格的數學概念基礎上的，嚴格的定義會在后面的部分給出，這里先講一些基本概念，

關系模型的資料結構是一個“二維表框架”組成的集合，每個二維表又可稱為關系，在關系模型中，操作的物件和結果都是二維表，關系模型是目前最流行的資料庫模型，支持關系模型的資料庫管理系統稱為關系資料庫管理系統，

一些概念

關系（Relation）：一個關系對應通常說的一張表
元組（Tuple）：表中的一行即為一個元組
屬性（Attribute）：表中的一列即為一個屬性，給每一個屬性起一個名稱即屬性名
主碼（Key）：也稱碼鍵，表中的某個屬性組，它可以唯一確定一個元組
域（Domain）：是一組具有相同資料型別的值的集合，屬性的取值范圍來自某個域，
分量：元組中的一個屬性值，
關系模式：對關系的描述，關系名（屬性1，屬性2，…，屬性n），如：學生（學號，姓名，年齡，性別，系名，年級）

資料模型建模

建模程序嘛，肯定是要由簡到難，再由難到簡，對我們來說，最簡單的莫過于層次模型和網狀模型了，關系模型沒那么簡單，
但是對計算機來說，恰恰就反過來了，而且它那個死腦子，怕是看不懂層次模型和網狀模型，

我的建模步驟是：先將抽象的現實問題轉化為網狀模型（如果能直接寫層次模型，那干嘛不直接寫關系模型），然后再從網狀模型分離出數個層次模型（屬性可重用），最后再根據層次模型和約束條件建造關系模型庫，

我們是準備做一個自動排課系統，目前分析出的沖突有三：

同一教師，同一時間，不同教室
同一教室，同一時間，不同教師
同一班級，同一時間，不同教室

各位可集思廣益啊

關系資料結構形式化定義

關系

什么是關系？在用戶看來，關系模型中資料的邏輯結構是一張扁平的二維表，
關系可以有三種型別：

基本關系（通常又稱基本表或基表）
查詢表
視圖表

基本表是實際存在的表，它是實際存盤資料的邏輯表示
查詢表是查詢結果對應的表
視圖表是由基本表或其他視圖表匯出的表，是虛表

關系的描述稱為關系模式

關系操作

關系的基本操作

想了想，此處應該用思維導圖

別急啊，后面會專門挑幾個重要的關系演算來示例

關系的完整性

關系模型的完整性規則是對關系的某種約束條件，

關系模型中有三種完整性約束：

物體完整性
參照完整性
用戶自定義完整性

物體完整性

關系資料庫中每個元組應該是可區分的，是唯一的，

物體完整性規則：若屬性A是基本關系B的主屬性，那么A不能取空值，
若主鍵由若干屬性組成，則所有這些主屬性都不能取空值，

參照完整性

如果說物體完整性約束了主鍵，那么自然而然可猜想參照完整性是約束了外鍵，沒錯啊，

用戶自定義完整性

怎么說呢，始侄訓是跳不出上一篇的畫地為牢啊，畢竟上一篇幾乎把我的基礎知識面鎖死了：MySQL見聞錄 – 入門之旅

關系代數

太好了，終于找到上面漏寫的了，

下圖分別是具有三個屬性列的關系 R、S ：

并

關系 R 與關系 S 的并由屬于 R 且屬于 S 的元組組成，其結果關系仍為 n 目關系，記作：

差

關系R與關系S的差由屬于R而不屬于S的所有元組組成，其結果關系仍為n目關系，記作：

交

關系R與關系S的交由既屬于R又屬于S的元組組成，其結果關系仍為n目關系，記作：

敲黑板：連接

我記得我寫過連接，不過我有刪博客的好習慣，所以就沒找著了，

交叉聯接（笛卡爾積）

假設你有一個存盤男孩姓名的表以及一個記錄男孩們都有哪些玩具的表，現在我們要試著找出每個男孩擁有的玩具，

SELECT t.toy,b.boy
From toys t
	CROSS JOIN
	boys AS b
;

CROSS JOIN回傳兩張表的每一行相乘的結果，

行內接

INNER JOIN利用條件判斷中的比較運算子結合兩張表的記錄，只有聯接記錄符合記錄條件時才會回傳列，

SELECT somecolumns
FROM table1
	INNER JOIN
	table2
ON somecondition;	--條件式里課采用任何一個比較運算子，也可以改用WHERE

示例：

SELECT mc.last_name,mc.first_name,p.profession
FROM my_contacts AS mc
	INNER JOIN
	profession AS p
ON mc.prof_id = p.prof_id;

自然聯接

屬于行內接的一種，
自然聯接只有在聯接的列在兩張表中的名稱相同時才會用，

SELECT boys.boy,toys.toy
FROM boys
	NATURAL JOIN
	toys;

左外聯接

LEFT OUTER JOIN 會匹配左表中的每一行及右表中符合條件的行，
當左表與右表具有一對多關系時，左外聯接特別有用，

理解外聯接的最大秘密在于知道表在左邊還是右邊，在LEFT OUTER JOIN中，出現在FROM后，聯接前的表稱為左表，而出現在聯接后的表稱為右表，

SELECT g.girl,t.toy
FROM girls g	--g是左表
LEFT OUTER JOIN toys t	--t是右表
ON g.toy_id = t.toy_id; 

內外聯接有什么差別？外聯接一定會提供資料行，無論該行能否在另一個表中找出相匹配的行，
左外聯接的結果為NULL表示右表沒有找到與左表相符的記錄，

具體流程概覽（圖有點小瑕疵）：

右外聯接

有外聯接與左外聯接一樣，除了它是用右表與左表比對，

自聯接

同一個表可以同時作為外聯接的左右表，雖然聽起來很奇怪，不過卻很好用，

來一題看看;

SELECT c1.name,c2.name AS boss
FROM clown_info1 c1
INNER JOIN clown_info2 c2
ON c1.bossid = c2.id
; 

自聯接能夠把一張表當成兩張完全相同的表來進行查詢，

UNION

還有一種取得多張表的查詢結果的方式：UNION聯合，

UNION根據我們在SELECT中指定的列，把兩張表或更多張表的查詢結果合并至一個表中，

SELECT title FROM job_current
UNION
SELECT title FROM job_desired
UNION
SELECT title FROM job_listings;

UNION的使用限制

示例

SELECT title FROM job_current
UNION
SELECT title FROM job_desired
UNION
SELECT title FROM job_listings
ORDER BY title;

結果集：

SELECT title FROM job_current
UNION ALL
SELECT title FROM job_desired
UNION ALL
SELECT title FROM job_listings
ORDER BY title;

結果集：

聯合規則說：選取的列必須可以互相轉換，

我就知道我有寫，只不過那篇的目錄過于嚇人，大家不喜歡罷了，

視圖

視圖是從一個或多個基表（或視圖）中匯出的表，是一個虛表，資料庫中只存放視圖的定義，而不存放視圖對應的資料，這些資料仍然放在原來的基本表中，所以一旦基本表中的資料發生變化，從視圖中查詢出的資料也就隨之改變了，

視圖一經定義，就可以和基本表一樣被增刪查改，不過對視圖的（增刪改）有一定的限制，

關于視圖我只想說一點：它沒有主鍵約束！！！

長尾流量優化

寫到這里有點累了，這篇戰線拉的過長，導致后面就比較快，
這里用幾篇來補上漏洞：
MySQL見聞錄 - 入門之旅
《深入淺出MySQL》問答錄
MySQL題集

最后，希望大家點個關注哦