SQL注入

学习目标

• 能够说出如何避免 SQL 注入问题

1. 什么是SQL注入

• SQL注入:

简单说sql注入是一种可以使得数据库中的数据泄露的方式. 如果有一些人有恶意的目的, 可以利用sql注入完成盗取数据.

• 产生原因:

后台将用户提交的带有恶意的数据和SQL进行字符串方式的拼接，从而影响了SQL语句的语义，最终产生数据泄露的现象.

简单的说, 就是利用各种方式提交数据给程序并让这些数据和SQL语句产生结合, 进而让新产生的SQL语句和之前的原始的SQL语句变成不同的意思, 至此就可以利用新产生的SQL语句获取想要的数据了.

• 防止SQL注入

SQL语句的参数化可以防止SQL注入的产生. 将SQL语句的所有数据参数存在一个列表中传递给execute函数的第二个参数进行执行, 就是SQL语句参数化.

python   # 把sql语句需要的参数放到一个列表中   my_list = [xxx,xxx,xxx]   # 把列表作为execute方法的第二个参数传递   cursor.execute(sql,my_list)

2. 非安全方式的SQL语句

注意:

在输入商品名称的时候输入

这样就完成了一个简单的SQL注入

这里 name= "" or 1=1 or "" 这个条件是一定成立的,因为or是或的意思多个条件只要有一个条件成立整体就成立,而1=1是一定成立的. 这就造成这个sql语句的意思发生里改变.

3. 安全方式的SQL语句

利用参数化列表就可以完成防止SQL注入.

总结

SQL注入问题

• 将SQL语句的所有数据参数存在一个列表中传递给execute函数的第二个参数

外键使用

学习目标：

• 知道数据库表外键约束的作用

• 能够为已经出存在的表添加外键约束

• 能够创建表时增加外键约束

1. 外键

下面咱们开始来验证外键的作用

• 分别在 goods_cates 和 goods_brands表中插入记录

• 在 goods 数据表中写入任意记录

问题: SQL语句中的12代表什么意义 ? 没错 是cate_id 请问: goods_cates表中有id=12的记录吗 显然没有

• 查询所有商品的详细信息 (通过左连接 将左表未显示数据添加到最终结果)

发现问题: cate_id = 12的SQL语句名称插入的数据是有问题的。

如何防止无效信息的插入,就是可以在插入前判断类型或者品牌名称是否存在呢? 可以使用之前讲过的外键来解决

• 外键约束:对外键字段的值 在更新和插入时进行和引用的表中字段数据进行对比

• 关键字: foreign key,只有 innodb数据库引擎 支持外键约束

2. 对于已经存在的字段添加外键约束

• 此时如果再次插入一个不存在的品牌（cate_id=12）的产品，会报错的

3. 在创建数据表的时候设置外键约束

• 注意: goods 中的 cate_id 的类型一定要和 goods_cates 表中的 id 类型一致

4.  删除外键约束

• 使用到外键约束会极大的降低表更新的效率, 所以在追求读写效率优先的场景下一般很少使用外键。

总结

• 将查询的数据直接插入表中  

• 连表更新

• 外键约束作用    

子表中的外键字段在插入和更新 新值的时候 新值必须 在主表中相应字段出现过。

E-R模型及表间关系

学习目标

• 了解E-R模型的组成部分

• 能够举例说出生活中 1对1 1对多 多对多关系的例子

1. E-R模型

• E-R模型简介

E-R模型即E-R图。

E-R图即实体-联系图(Entity Relationship Diagram)，是指提供了表示实体型、属性和联系的方法，用来描述现实世界的概念模型。由美籍华裔计算机科学家陈品山(Peter Chen)发明。

• E-R模型的使用场景

• 关系型数据库 关系模型的基础上，我们需要根据产品经理的设计策划，抽取出来模型与关系，制定出表结构，这是项目开始的第一步

• 在设计阶段一般使用E-R模型进行建模。有很多设计数据库的软件，常用的如power designer，db desinger等，这些软件可以直观的看到实体及实体间的关系

• 设计数据库，可能是由专门的数据库设计人员完成，也可能是由开发组成员完成，一般是项目经理带领组员来完成

• 待设计完成E-R模型会将其转化为关系模型

• E-R模型组成元素

E-R图用 实体、联系和属性这3个概念来描述现实问题, 有以下三种元素:

• 实体型(Entity)：具有相同属性的实体具有相同的特征和性质，用实体名及其属性名集合来抽象和刻画同类实体;在E-R图中用矩形表示，矩形框内写明实体名；比如 电商购物系统中用户、购物车、订单等都是实体。

• 属性(Attribute)：实体所具有的某一特性，一个实体可由若干个属性来刻画。在E-R图中用椭圆形表示，并用无向边将其与相应的实体连接起来；比如用户的ID、用户名、密码、昵称、身份证号码 都是属性。

• 联系(Relationship)： 实体彼此之间相互连接的方式称为联系，也称为关系。

联系可分为以下 3 种类型：一对一、一对多、多对多:

• 关系也是一种数据，需要通过一个字段存储在表中

• 实体A对实体B为1对1，则在表A或表B中创建一个字段，存储另一个表的主键值

• 实体A对实体B为1对多：在表B中创建一个字段，存储表A的主键值

• 实体A对实体B为多对多：新建一张表C，这个表只有两个字段，一个用于存储A的主键值，一个用于存储B的主键值

总结

• 范式就是设计数据库的通用规范。

• E-R图由 实体、属性、实体之间的联系构成，主要用来描述 数据库中表结构。

三范式

学习目标

• 了解三范式的要求

1. 什么是范式

设计关系数据库时，遵从不同的规范要求，设计出合理的关系型数据库，这些不同的规范要求被称为不同的范式，各种范式呈递次规范，越高的范式数据库冗余越小。

实际上家用电器都有节能标识,同时也会根据耗能不同进行等级的划分, 同样的数据库实际上也有这么个 ”节能标识 ” ,那就是范式.

2. 范式的划分

根据数据库冗余的大小,目前关系型数据库有六种范式,各种范式呈递次规范，越高的范式数据库冗余越小。

• 第一范式（1NF）

• 第二范式（2NF）

• 第三范式（3NF）

• 巴斯-科德范式（BCNF）

• 第四范式 ( 4NF）

• 第五范式（5NF，又称完美范式）

一般遵循前三种范式即可

3. 一范式

第一范式（1NF）: 强调的是字段的原子性，即一个字段不能够再分成其他几个字段。

上图这种表结构设计就没有达到 1NF，要符合 1NF 我们只需把字段拆分，即：把 contact 字段拆分成 name 、tel、addr 等字段。

4. 二范式

第二范式（2NF）: 满足 1NF的基础上，另外包含两部分内容

• 一是表必须有一个主键

• 二是非主键字段必须完全依赖于主键，而不能只依赖于主键的一部分

思考:

OrderDetail表的主键是什么？

主键的定义：能够确定唯一一行记录的特殊字段 主键可以是多个字段共同组成

在这里这里主键是由OrderID和ProductID共同组成, 只有通过OrderID和ProductID两个字段才可以确定唯一一行记录, 所以他们共同组成主键.

注意:

同时 UnitPrice 和 ProductName 这里两个字段 与ProductID的从属关系强于他们同OrderID的从属关系, 也就是说非主键字段 UnitPrice 和 ProductName 没有完全依赖于主键，而只依赖于主键的一部分, 这是不符合二范式要求的

上图的表才是符合二范式要求的表格

5. 三范式

第三范式（3NF）: 满足 2NF, 另外非主键字段必须直接依赖于主键，不能存在传递依赖, 即不能存在：非主键字段 A 依赖于非主键字段 B，非主键字段 B 依赖于主键的情况

观察上图, 因为 OrderDate，CustomerID，CustomerName，CustomerAddr，CustomerCity 等非主键字段都完全依赖于主键（OrderID），所以符合 2NF。

不过问题是 CustomerName，CustomerAddr，CustomerCity 直接依赖的是 CustomerID（非主键列），而不是直接依赖于主键，它是通过传递才依赖于主键，所以不符合 3NF。

把【Order】表拆分为【Order】（OrderID，OrderDate，CustomerID）和

【Customer】（CustomerID，CustomerName，CustomerAddr，CustomerCity）从而达到 3NF。

总结:

范式:

设计关系数据库时，遵从不同的规范要求，设计出合理的关系型数据库，这些不同的规范要求被称为不同的范式，

各种范式呈递次规范，越高的范式数据库冗余越小。

三范式:

• 第一范式（1NF）: 强调的是列的原子性，即列不能够再分成其他几列。

• 第二范式（2NF）: 满足 1NF，另外包含两部分内容，

• 一是表必须有一个主键；

• 二是非主键字段 必须完全依赖于主键，而不能只依赖于主键的一部分。

• 第三范式（3NF）: 满足 2NF，另外非主键列必须直接依赖于主键，不能存在传递依赖。即不能存在：非主键列 A 依赖于非主键列 B，非主键列 B 依赖于主键的情况。