SQL注入，外鍵使用，E-R模型及表間關(guān)系，三范式
SQL注入
學(xué)習(xí)目標(biāo)
能夠說出如何避免 SQL 注入問題
1. 什么是SQL注入
SQL注入:
簡(jiǎn)單說sql注入是一種可以使得數(shù)據(jù)庫中的數(shù)據(jù)泄露的方式. 如果有一些人有惡意的目的, 可以利用sql注入完成盜取數(shù)據(jù).
產(chǎn)生原因:
后臺(tái)將用戶提交的帶有惡意的數(shù)據(jù)和SQL進(jìn)行字符串方式的拼接，從而影響了SQL語句的語義，最終產(chǎn)生數(shù)據(jù)泄露的現(xiàn)象.
簡(jiǎn)單的說, 就是利用各種方式提交數(shù)據(jù)給程序并讓這些數(shù)據(jù)和SQL語句產(chǎn)生結(jié)合, 進(jìn)而讓新產(chǎn)生的SQL語句和之前的原始的SQL語句變成不同的意思, 至此就可以利用新產(chǎn)生的SQL語句獲取想要的數(shù)據(jù)了.
防止SQL注入
SQL語句的參數(shù)化可以防止SQL注入的產(chǎn)生. 將SQL語句的所有數(shù)據(jù)參數(shù)存在一個(gè)列表中傳遞給execute函數(shù)的第二個(gè)參數(shù)進(jìn)行執(zhí)行, 就是SQL語句參數(shù)化.
python ? # 把sql語句需要的參數(shù)放到一個(gè)列表中 ? my_list = [xxx,xxx,xxx] ? # 把列表作為execute方法的第二個(gè)參數(shù)傳遞 ? cursor.execute(sql,my_list)
2. 非安全方式的SQL語句
注意:
在輸入商品名稱的時(shí)候輸入
這樣就完成了一個(gè)簡(jiǎn)單的SQL注入
這里 name= "" or 1=1 or "" 這個(gè)條件是一定成立的,因?yàn)閛r是或的意思多個(gè)條件只要有一個(gè)條件成立整體就成立,而1=1是一定成立的. 這就造成這個(gè)sql語句的意思發(fā)生里改變.
3. 安全方式的SQL語句
利用參數(shù)化列表就可以完成防止SQL注入.
總結(jié)
SQL注入問題
將SQL語句的所有數(shù)據(jù)參數(shù)存在一個(gè)列表中傳遞給execute函數(shù)的第二個(gè)參數(shù)
外鍵使用
學(xué)習(xí)目標(biāo)：
知道數(shù)據(jù)庫表外鍵約束的作用
能夠?yàn)橐呀?jīng)出存在的表添加外鍵約束
能夠創(chuàng)建表時(shí)增加外鍵約束
1. 外鍵
下面咱們開始來驗(yàn)證外鍵的作用
分別在 goods_cates 和 goods_brands表中插入記錄
在 goods 數(shù)據(jù)表中寫入任意記錄
問題: SQL語句中的12代表什么意義 ? 沒錯(cuò) 是cate_id 請(qǐng)問: goods_cates表中有id=12的記錄嗎 顯然沒有
查詢所有商品的詳細(xì)信息 (通過左連接 將左表未顯示數(shù)據(jù)添加到最終結(jié)果)
發(fā)現(xiàn)問題: cate_id = 12的SQL語句名稱插入的數(shù)據(jù)是有問題的。
如何防止無效信息的插入,就是可以在插入前判斷類型或者品牌名稱是否存在呢? 可以使用之前講過的外鍵來解決
外鍵約束:對(duì)外鍵字段的值 在更新和插入時(shí)進(jìn)行和引用的表中字段數(shù)據(jù)進(jìn)行對(duì)比
關(guān)鍵字: foreign key,只有 innodb數(shù)據(jù)庫引擎 支持外鍵約束
2. 對(duì)于已經(jīng)存在的字段添加外鍵約束
此時(shí)如果再次插入一個(gè)不存在的品牌（cate_id=12）的產(chǎn)品，會(huì)報(bào)錯(cuò)的
3. 在創(chuàng)建數(shù)據(jù)表的時(shí)候設(shè)置外鍵約束
注意: goods 中的 cate_id 的類型一定要和 goods_cates 表中的 id 類型一致
4. ?刪除外鍵約束
使用到外鍵約束會(huì)極大的降低表更新的效率, 所以在追求讀寫效率優(yōu)先的場(chǎng)景下一般很少使用外鍵。
總結(jié)
將查詢的數(shù)據(jù)直接插入表中??
連表更新
外鍵約束作用 ? ?
子表中的外鍵字段在插入和更新 新值的時(shí)候 新值必須 在主表中相應(yīng)字段出現(xiàn)過。
E-R模型及表間關(guān)系
學(xué)習(xí)目標(biāo)
了解E-R模型的組成部分
能夠舉例說出生活中 1對(duì)1 1對(duì)多 多對(duì)多關(guān)系的例子
1. E-R模型
E-R模型簡(jiǎn)介
E-R模型即E-R圖。
E-R圖即實(shí)體-聯(lián)系圖(Entity Relationship Diagram)，是指提供了表示實(shí)體型、屬性和聯(lián)系的方法，用來描述現(xiàn)實(shí)世界的概念模型。由美籍華裔計(jì)算機(jī)科學(xué)家陳品山(Peter Chen)發(fā)明。
E-R模型的使用場(chǎng)景
關(guān)系型數(shù)據(jù)庫 關(guān)系模型的基礎(chǔ)上，我們需要根據(jù)產(chǎn)品經(jīng)理的設(shè)計(jì)策劃，抽取出來模型與關(guān)系，制定出表結(jié)構(gòu)，這是項(xiàng)目開始的第一步
在設(shè)計(jì)階段一般使用E-R模型進(jìn)行建模。有很多設(shè)計(jì)數(shù)據(jù)庫的軟件，常用的如power designer，db desinger等，這些軟件可以直觀的看到實(shí)體及實(shí)體間的關(guān)系
設(shè)計(jì)數(shù)據(jù)庫，可能是由專門的數(shù)據(jù)庫設(shè)計(jì)人員完成，也可能是由開發(fā)組成員完成，一般是項(xiàng)目經(jīng)理帶領(lǐng)組員來完成
待設(shè)計(jì)完成E-R模型會(huì)將其轉(zhuǎn)化為關(guān)系模型
E-R模型組成元素
E-R圖用 實(shí)體、聯(lián)系和屬性這3個(gè)概念來描述現(xiàn)實(shí)問題, 有以下三種元素:
實(shí)體型(Entity)：具有相同屬性的實(shí)體具有相同的特征和性質(zhì)，用實(shí)體名及其屬性名集合來抽象和刻畫同類實(shí)體;在E-R圖中用矩形表示，矩形框內(nèi)寫明實(shí)體名；比如 電商購物系統(tǒng)中用戶、購物車、訂單等都是實(shí)體。
屬性(Attribute)：實(shí)體所具有的某一特性，一個(gè)實(shí)體可由若干個(gè)屬性來刻畫。在E-R圖中用橢圓形表示，并用無向邊將其與相應(yīng)的實(shí)體連接起來；比如用戶的ID、用戶名、密碼、昵稱、身份證號(hào)碼 都是屬性。
聯(lián)系(Relationship)： 實(shí)體彼此之間相互連接的方式稱為聯(lián)系，也稱為關(guān)系。
聯(lián)系可分為以下 3 種類型：一對(duì)一、一對(duì)多、多對(duì)多:
關(guān)系也是一種數(shù)據(jù)，需要通過一個(gè)字段存儲(chǔ)在表中
實(shí)體A對(duì)實(shí)體B為1對(duì)1，則在表A或表B中創(chuàng)建一個(gè)字段，存儲(chǔ)另一個(gè)表的主鍵值
實(shí)體A對(duì)實(shí)體B為1對(duì)多：在表B中創(chuàng)建一個(gè)字段，存儲(chǔ)表A的主鍵值
實(shí)體A對(duì)實(shí)體B為多對(duì)多：新建一張表C，這個(gè)表只有兩個(gè)字段，一個(gè)用于存儲(chǔ)A的主鍵值，一個(gè)用于存儲(chǔ)B的主鍵值
總結(jié)
范式就是設(shè)計(jì)數(shù)據(jù)庫的通用規(guī)范。
E-R圖由 實(shí)體、屬性、實(shí)體之間的聯(lián)系構(gòu)成，主要用來描述 數(shù)據(jù)庫中表結(jié)構(gòu)。
三范式
學(xué)習(xí)目標(biāo)
了解三范式的要求
1. 什么是范式
設(shè)計(jì)關(guān)系數(shù)據(jù)庫時(shí)，遵從不同的規(guī)范要求，設(shè)計(jì)出合理的關(guān)系型數(shù)據(jù)庫，這些不同的規(guī)范要求被稱為不同的范式，各種范式呈遞次規(guī)范，越高的范式數(shù)據(jù)庫冗余越小。
實(shí)際上家用電器都有節(jié)能標(biāo)識(shí),同時(shí)也會(huì)根據(jù)耗能不同進(jìn)行等級(jí)的劃分, 同樣的數(shù)據(jù)庫實(shí)際上也有這么個(gè) ”節(jié)能標(biāo)識(shí) ” ,那就是范式.
2. 范式的劃分
根據(jù)數(shù)據(jù)庫冗余的大小,目前關(guān)系型數(shù)據(jù)庫有六種范式,各種范式呈遞次規(guī)范，越高的范式數(shù)據(jù)庫冗余越小。
第一范式（1NF）
第二范式（2NF）
第三范式（3NF）
巴斯-科德范式（BCNF）
第四范式 ( 4NF）
第五范式（5NF，又稱完美范式）
一般遵循前三種范式即可
3. 一范式
第一范式（1NF）: 強(qiáng)調(diào)的是字段的原子性，即一個(gè)字段不能夠再分成其他幾個(gè)字段。
上圖這種表結(jié)構(gòu)設(shè)計(jì)就沒有達(dá)到 1NF，要符合 1NF 我們只需把字段拆分，即：把 contact 字段拆分成 name 、tel、addr 等字段。
4. 二范式
第二范式（2NF）: 滿足 1NF的基礎(chǔ)上，另外包含兩部分內(nèi)容
一是表必須有一個(gè)主鍵
二是非主鍵字段必須完全依賴于主鍵，而不能只依賴于主鍵的一部分
思考:
OrderDetail表的主鍵是什么？
主鍵的定義：能夠確定唯一一行記錄的特殊字段 主鍵可以是多個(gè)字段共同組成
在這里這里主鍵是由OrderID和ProductID共同組成, 只有通過OrderID和ProductID兩個(gè)字段才可以確定唯一一行記錄, 所以他們共同組成主鍵.
注意:
同時(shí) UnitPrice 和 ProductName 這里兩個(gè)字段 與ProductID的從屬關(guān)系強(qiáng)于他們同OrderID的從屬關(guān)系, 也就是說非主鍵字段 UnitPrice 和 ProductName 沒有完全依賴于主鍵，而只依賴于主鍵的一部分, 這是不符合二范式要求的
上圖的表才是符合二范式要求的表格
5. 三范式
第三范式（3NF）: 滿足 2NF, 另外非主鍵字段必須直接依賴于主鍵，不能存在傳遞依賴, 即不能存在：非主鍵字段 A 依賴于非主鍵字段 B，非主鍵字段 B 依賴于主鍵的情況
觀察上圖, 因?yàn)?OrderDate，CustomerID，CustomerName，CustomerAddr，CustomerCity 等非主鍵字段都完全依賴于主鍵（OrderID），所以符合 2NF。
不過問題是 CustomerName，CustomerAddr，CustomerCity 直接依賴的是 CustomerID（非主鍵列），而不是直接依賴于主鍵，它是通過傳遞才依賴于主鍵，所以不符合 3NF。
把【Order】表拆分為【Order】（OrderID，OrderDate，CustomerID）和
【Customer】（CustomerID，CustomerName，CustomerAddr，CustomerCity）從而達(dá)到 3NF。
總結(jié):
范式:
設(shè)計(jì)關(guān)系數(shù)據(jù)庫時(shí)，遵從不同的規(guī)范要求，設(shè)計(jì)出合理的關(guān)系型數(shù)據(jù)庫，這些不同的規(guī)范要求被稱為不同的范式，
各種范式呈遞次規(guī)范，越高的范式數(shù)據(jù)庫冗余越小。
三范式:
第一范式（1NF）: 強(qiáng)調(diào)的是列的原子性，即列不能夠再分成其他幾列。
第二范式（2NF）: 滿足 1NF，另外包含兩部分內(nèi)容，
一是表必須有一個(gè)主鍵；
二是非主鍵字段 必須完全依賴于主鍵，而不能只依賴于主鍵的一部分。
第三范式（3NF）: 滿足 2NF，另外非主鍵列必須直接依賴于主鍵，不能存在傳遞依賴。即不能存在：非主鍵列 A 依賴于非主鍵列 B，非主鍵列 B 依賴于主鍵的情況。
