ER 

最后总结以下E-R图的设计原则。
1）尽量减少实体集数量，能作为属性时不要作为实体集。
2）“属性”不能再具有需要描述的性质。必须时不可分割的数据项。不能时其他属性的聚集。
3）“属性”不能与其他实体具有联系
4)综合局部E-R图，产生出总体E-R图。在这个过程中，同名实体只能出现一次，并去掉不必要的联系，以便消除冗余。一般的，能够根据总体E-R图导出各个局部的E-R图。

1. 主键（Primary Key）：用于唯一标识实体的属性，通常在实体框内用下划线或加粗表示。主键属性的值在整个实体集合中必须是唯一的，用于区分不同的实体。\

弱实体
想象一下，在数据库中，实体就像是人或物体，而属性就像是这些人或物体的特征。通常情况下，一个实体具有自己的标识，例如一个人有独特的身份证号码，一个产品有独特的产品编号。

然而，有时候存在一种情况，某个实体的标识依赖于与其相关联的另一个实体。这时，我们称这个实体为弱实体。弱实体没有自己的唯一标识，它的标识需要依赖于与其相关联的另一个实体（强实体）。

在 E-R 图中，弱实体通常用双矩形框表示。

 订单项并不是一个单独存在的项，而是基于订单小票才会产生的一个实体，所以我们把它划分为弱实体。

在 E-R 图中，弱实体通常没有自己的唯一标识，因此需要使用弱实体的部分键来唯一标识不同的实例。弱实体的部分键是通过指定其中一个属性与父实体的键结合从而形成相应弱实体的键，弱实体的这个属性称为弱实体的部分键。部分键用虚线标识。

 UML

关系模型

SQL

第二个参数是从哪开始

select device_id AS user_infos_example from user_profile LIMIT 2;
//1.as 写不写都可
//2.别名加不加引号（单双）都可
    //加引号：别名就是引号内的内容。
    //不加引号：别名如果为小写，会解析为大写，别名实际为大写。
//以上两点在调用别名时要注意，易报错：找不到对应的列（大小写对应的是不同的列）
 

覆盖索引的原理：就是查询字段在 二级索引中全部找到，不需要回表查询

覆盖索引只是特定于具体select语录而言的联合索引。也就是说一个联合索引对于某个select语句，通过索引可以直接获取查询结果，而不再需要回表查询啦，就称该联合索引覆盖了这条select语句。

 device_id = user_profile.device_id 这一步是100%成立的，使用的目的就是索引覆盖

三大范式：

第一范式：无重复的列。当关系模式R的所有属性都不能在分解为更基本的数据单位时，称R是满足第一范式的，简记为1NF。满足第一范式是关系模式规范化的最低要求，否则，将有很多基本操作在这样的关系模式中实现不了。
第二范式：属性完全依赖于主键 [ 消除部分子函数依赖 ]。如果关系模式R满足第一范式，并且R得所有非主属性都完全依赖于R的每一个候选关键属性，称R满足第二范式，简记为2NF。第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。第二范式（2NF）要求数据库表中的每个实例或行必须可以被唯一地区分。为实现区分通常需要为表加上一个列，以存储各个实例的唯一标识。这个唯一属性列被称为主关键字或主键、主码。
第三范式：属性不依赖于其它非主属性 [ 消除传递依赖 ]。设R是一个满足第一范式条件的关系模式，X是R的任意属性集，如果X非传递依赖于R的任意一个候选关键字，称R满足第三范式，简记为3NF. 满足第三范式（3NF）必须先满足第二范式（2NF）。第三范式（3NF）要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。（eg：第一张表是学生表，主要信息为姓名，次要信息为成绩，那么其他的表中，就不能包含成绩。）
注：关系实质上是一张二维表，其中每一行是一个元组，每一列是一个属性
第二范式（2NF）和第三范式（3NF）的概念很容易混淆，区分它们的关键点在于，2NF：非主键列是否完全依赖于主键，还是依赖于主键的一部分；3NF：非主键列是直接依赖于主键，还是直接依赖于非主键列。

course

 

SELECT DISTINCT university from user_profile