day01【后台】搭建环境/14-尚硅谷-尚筹网-后台-环境搭建-物理建模-原则

好，建完了工程呢，我们下一步大的目标，我们就是要进行我们SM整合。那么SSM整合大家哈。那就是我们spring和MY贝蒂的一个整合啊，这是先做一个spring和MY贝蒂的一个整合，然后呢，接下来的话是一个我们spring和spring MC的一个整合。哎，那现在呢，那我们肯定是咱们要先说这个spring和整合这事，那spring和买整合我们是要操作数据库，哎，解决我们持久化层的这个问题，那么我们要操作数据库呢，咱们得先去把数据库和数据库表给它建出来。哎，建库建表，建库建表这事呢，其实有一个名词啊，叫做物理建模，哎呃，物理呢，指的就是说在数据库里边做什么事啊，这个对应的就是我们这个物理，有的时候有一个还有一个说法叫做比如说叫物理删除。

物理这两个字啊，物理删除，呃，跟物理删除对应的呢，有一个叫做逻辑删除。哎，这个大家你看这个名字你能不能够去推测出来啊，顾名思义，你能不能够去猜出来，物理删除和逻辑删除有什么区别。哎，物理删除是在数据库里边真正的去执行这个delete语句，是真的把这个数据给删掉了，而逻辑删除呢，只是update下。哎，去把它的一个状态，比如说我从一改成零，一表示数据有效，零表示数据无效，但是这个数据呢，把它变成无效的了，但数据并没有真正的delete啊，并没有真正的删掉，所以说这个delete是物理删除啊，Update去改它的一个某一个字段的状态呢，这个叫做逻辑删除。

表面上用户是看不到了，但其实这个数据在数据库里边还是有的啊，实际开发的时候我们考虑这个数据的安全性，呃，我们还是建议是使用是这个呃逻辑删除的方式啊，因为这个数据delete以后就真的没有了啊，这个你就再也找不回来了，那么我们这儿建模呃，创建我们项目要使用的模型在数据库里边，呃，去创建数据库，数据库表啊，就是在就是做的是一个物理建模的一个操作。那么物理建模的时候呢，哎，那不像说咱们平平常常的就在看在这个学学JDBC也好，学MY搜狗也好，咱们说为了测试搜狗语句是吧，哎，咱们根据我们学习的需要去建表，而我们现在呢，是需要根据我们的项目的需要去建表，那么我们这个建模呢，就得有点章法，哎，所以说呢，咱们得先说一下这个有有一点点这个相关的理论啊，咱们稍微给大家去提一下，这个倒也不用说，你看第一范式，第二范式，第三范式，这个啊，倒也不用说，大家把这个当成一个多么正式多么重要的知识点呢，去背，或者说去掌握的多么牢固哈，但这个东西呢，你得有一个印象。

啊嗯，咱们先来介绍一下这个第一反式啊呃，数据库表里边呢，每一列都不可以再分，要求每一列呢都是原子的，哎，原子这个词的这个意思就是不可再分嘛，所以说第一范式呢，就要求我们见表的时候呢，你不能够说有哪一个字段呀，它里边的值呢，其实还可以再拆开，比如说你看我们现在这个部门。岗位这个字段，它里边包含了部门，包含了岗位，那这个就。这个就是这个字段的值哈，就是属于说能够拆开的了，这个就违背了原子性，因为你可以再分呀，啊，原子性的要求是不可再分，所以说呢，这里边儿就要求我们把部门和岗位给拆开啊，有一个部门名称的字段，有一个岗位的字段啊，这个就是说你这样做了以后，就满足了第一反式的要求。

那然后再看第二范式。哎，当然我们这儿再说一句，就是说呃，我们拆开以后哈，你才能够针对部门或者岗位呢，进行这个SQL的查询啊，进行这个操作，不然的话，你两个字段在一起呢，它是没办法用SQL语句专门针对部门或者岗位进行这个查询的操作的，你这个SQL语句这个条件你没法写，哎，所以说这个为什么会有第一范式这个要求哈，就是根据我们实际的呃操作是有关系的，它不会说是凭空的说定这么一个，呃无缘无故的，他不会无缘无故的去定这么一个规则。包括我们第二范式来看一下。第二范式呢，其实它是针对一个比较。哎，第二范式是针对一个比较，呃，特定的一个情况，就是叫。

联合组建。如果你没有联合主键的话，如果主键呢，是一个字段，啥叫联合主键呢，就是这个主键呀，它是多个字段。啊，不是一个字段的两个三个四个字段，多个字段共同构成一个主键啊联合主键呢，说只要我这个组合不重复就行，组合里边的每一个字段呢，都可以重复，但是组合起来不能重复，这叫联合组建。呃，第二范式呢，就是针对我们联合主舰来说的。哎，你要不是联合主键，你要是这个表里边的主键就一个字段，那么第二范式和第三范式呢，你会看到其实没有啥区别啊，其实是没有啥实质性的这个区别，现在这儿说的是联合主件，联合主件你就涉及到多个字段，你这联合主件呢，包含多个字段以后，那么我们在这个表里边的其他的字段就会有一个要求了，就是这个其他字段呢，都必须和联合组建的所有的字段呢都关联。

啊，你不能只关联它的某一个字段，你比如说我们现在联合主件是订单编号，产品编号这两个字段。啊，因为我下一个订单呢，一个订单里边会包含很多个产品，那我就需要让他们。呃，这个怎么说哈，就是。我的。订单详情这个表里边儿啊，就会包含这个订单里边所有的这个产品，所以说这个产品价格，产品数量，哎，它是和订单也相关联，和产品也相关联啊呃，为啥他这个同一个订单里边哈，或者说不同订单里边的同一个产品。他有可能价格是不一样的啊，因为商家可能搞活动呀，人家昨天卖200块钱，今天可能卖150块钱啊，降价人想促销啊，所以说不同的订单里边，你不同时候下单，你赶上没赶上人家促销这个活动，这个价格不一样啊，不同的人呢，买的这个东西呢，这个数量也不一样啊，他赶上便宜了以后，他多买一点这个，所以说这个产品的信息呢，在不同的订单里边不一样啊，这个是很正常的。

所以说呢，我们产品价格，产品的数量是和我们订单编号，产品编号这两个字段呢，都关联这个。哎，是为呃，是满足我们第二三式的，可是呢，这个后边订单的金额，下单的时间，这两个字段和产品编号就没关系了，它只是和订单编号有关系，那么很明显这两个字段。这两个字段。它只是和我们联合组件里边的这一部分字段有关系，和其他的没有关系，它就不满足第二范式的，所以说其实其实其实第二范式呢，他所说的只是一个完整这么一个要求啊，归根到底呢，他在这儿提炼出来以后，就这两个字完整哎，他要求你和联合主键里边所有的字段都关联才行，这个时候呢，订单金额，下单的时间，这两个字段啊，就要求他拿到另外一张表里边儿去。哎。

所以说呢，你看啊，就是得按下边这样订单详情的表和订单表他们得分开啊，这是我们第二范式的要求，第三范式呢，就是要求非主见的字段和主见字段是直接相关的啊，不允许间接相关，啥叫直接相关，啥叫间接相关的，你比如说我们部门的名称和员工的编号啊，我想通过员工编号，如果想找到部门名称名称的话，这个逻辑应该是用员工编号找到部门编号，再拿部门编号去找这个，呃，部门的名称，所以说这个时候其实员工编号和部门的名称呀，并不是直接相关的这样的这个字段，这个就不满足第三方式的，第三方式会要求我们呢，你去把这个部门名称啊，也给它拿到另外一个表里边去啊，呃，用这个部门编号呢，作为一个外界的去给它关联上啊，这是我们这个第三范式的这个要求。啊呃，其实呢，我们归结起来哈，就是说这么多啊，这边举这么多例子，你懂了以后呢，你就可以去把它给提炼出来。

其实呢？第一范式呢，说的是一个字段啊，这个不能够再可以再拆开啊，就是说就是要每一个字段设计的时候，要设计成那种不能再拆分成更多字段的那种不可再分的，第一范是说的是一个原子性，第二范是呢说的是哎，你其他的字段和主键呢，要完整相关啊，如果涉及到联合主键的话，你得和联合主键里边的每个字段都相关，所以说第二范呢，提炼起来，提炼出来以后就是完整，第三肾呢说的就是一个直接。第三范式呢，它的关键词就是直接，哎，直接相关哎，所以说这个我们这三个范式呢，要求哈，第一个第一个范式呢，说的是我们单独的一个字段，第二范式，第三范式呢，其实说的都是哈，如果这个字段和这个表对应的数据要没关系的话，就把它拿出去啊，然后给它放到另外一个表里边，诶第二范式，从这来说，第二范式和第三范式其实意思是一样的，诶呃，那么说你违背了这个范式呢，其实会给我们带来什么样的麻烦？

哎，你违背第一范式呢，我们刚才说了，你没办法针对里边的这一个字段，里边的这个局部的数据进行查询。违背了第二范式呢？嗯。哎，这个时候你也是会产生这个冗余的数据等等啊，也不利于不方便我们进行这个自然改查这样的操作，第三份是呢，这个就我们可以说的很具体啊，你有这个数据的冗余，哎，你这个部门名称呢，会有多次重复的出现，哎会有可能会产生插入的异常，组建一个新的部门的时候，还没有员工的信息，也就没法单独的插入部门的信息，哎就算强强行的插入部门的信息呢，员工表里边儿也没有员工的记录，哎同样是这个非法的记录。啊，就是呃，你在其实是说你在员工里边强行的要保存这个部门的这个信息啊，那你这个部门还没有员工的时候，那么你这个部门的信息在这个员工表里边就很尴尬了啊，就没有你的这个位置。

删除异常，员工信息删除，那把部门信息也删除了，如果说我们呃，把这个某个部门的员工全删掉了，这个部门的信息也没有了啊，那我可能这个部门这些员工不在了，也可能还会补充新的员工，但是你部门信息没有了，他就没没没办法再补充了啊，所以这个时候他是呃，这叫删除异常，不该不该因为删除掉员工的信息，把部门信息也删了，这个是不对的。对吧。还有更新的一常啊，你哪怕只修改一个部门的名称，也得把这个部门所有的员工的记录呢，都把它给更新更新了啊这个时候呢，就是说这个是给我们带来一些的麻烦，影响我们，损失我们的性能，对吧？哎，所以说增删改查都会有问题，所以说人家设计这个范式呢，也是考虑我们实际的这个操作啊，是是对我们实际操作呢啊，对于我们搜狗语句的这个逻辑的严谨，对于我们这个性能都是说有好处的。

啊，所以这个这些个设计表的这个基本的原则啊，这些是一个用的是一个用的，则这个大家呢去了解。