今天先完成前2个的知识点。
1.形参和实参
首先先说一下他们的定义:
形参:全称为“形式参数”,从字面意思上可以看出它是一个形式上的参数,相当于一个走过场的、不是实际存在的虚拟变量。函数中定义的变量就是形参。
实参:全称为“实际参数”,同样的,从字面意思可以看出来这是一个实际存在的参数,既然实际存在,那必须要有一个确定的值,不管表达式,还是常量、变量或函数,无论他是什么类型,在调用他的时候,都必须有一个具体的值,实参才能值传递给形参。
例子:
int add(int a, int b) {}这其中的a,b就是形参。当主调函数调用该函数传入的参数则是实参。
接下来说说他们的区别:
1、形参是出现在函数定义中,当出了这个函数体的范围时,即被调函数结束返回主调函数时,则不能再被使用了,因为当他被调用时才分配内存单元,调用结束时即刻释放资源。同样的,当实参将值传递给了形参,在被调函数中,实参也不能被操作。
2、函数调用中数据的传递只能是单向的。且由实参传递给形参,不能形参反向传递值给实参。因此在被调函数中无论形参怎么被“蹂躏”,实参都不会有任何影响(该项只限于实参和形参不是指针类型)。
3.当实参和形参为指针类型时,传递的是内存地址,即在被调函数中使用的是实参本色,此时形参发生改变会导致实参的值也发生改变。
2.范式
首先呢,范式分为:第一范式、第二范式和第三范式三种。层层递进,一层比一层严谨。
要区分一个关系模型为哪种范式,首先要判断该关系的每个字段是否是不可再分割的。如果这个条件都不满足,那么它将不是任何一个范式。
说明一下,在任何一个关系数据库中,第一范式是最低要求,数据库不是excel,不能对单元格进行多个拆分,如果连第一范式都无法满足,则这个表无法成型,就不是关系数据库。
其次,要分清一个关系模型属于哪个范式,要先理解3个函数依赖概念,分别是完全函数依赖,部分函数依赖和传递函数依赖。
函数依赖的定义是:当X值确定,则Y值必确定,称作Y函数依赖于X
完全函数依赖:如果X只是一个属性,则Y函数依赖X的同时也是完全函数依赖。当X是一个属性组(比如复合主键),无论X的哪一个真子集确定,都无法确定Y的值,则称作Y完全函数依赖于X。
部分函数依赖:X是一个属性组,并且当X的某一个真子集确定时,Y的值也随之确定,且Y依赖于X。再称作Y部分函数依赖于X。
传递函数依赖:Y函数依赖于X,Z函数依赖于Y,并且X、Y没有任何依赖关系,且Y不是X的真子集,则称作Z传递函数依赖于X。
(通俗一点……X确定了Y,而Z又由Y来确定,然而X、Y又一毛钱关系都没有,所以最后Z的值,还是需要通过X来确定的Y的值,随后再通过Y确定。)
第一范式
这个表格1最基本的,随处可见,这就不满足第一范式,因为销售字段是可再分割的,当其改为表格2,则满足了第一范式的要求。
第二范式
第二范式是在第一范式的基础上,再进行一次划分,消除了非主属性对码的部分函数依赖,使得所有属性完全依赖于主键。
还是用表格2来说,这个表格属于第一范式,但为什么不属于第二范式?
原因是因为它没有主键,没有一个属性确定之后,能精确到一笔记录。如表格3,确定学生姓名为“张三”之后就能精确到哪一条记录了吗?显而易见是并不能的,这就没有达成第二范式的要求,没有让所有的属性都完全依赖于主键。可以添加一个列属性“编号”,这样就可以满足第二范式。因为编号唯一,当编号确定,则可以精确定位到哪一条数据。
其次我们再来说说,如果精确的判定一个关系模型是否为第二范式。
第一步:找出关系中的所有的码(表中可以唯一确定一个元组的某个属性(或者属性组),如果有多个,则都成为候选码)。
第二步:除去那些码,判断剩下的所有非主属性,是否对码完全函数依赖,如果是,则符合第二范式,反之则不是。
第三范式
第三范式消除了非主属性对码的传递函数依赖。
例如表格5,学号能唯一确定一个元组,但是元组中的每个非主属性就没有依赖于其他非主属性了吗?
显然是没有的,学号是单个关键字,所以不存在传递函数依赖,即满足第二范式,但是他一定满足第三范式了吗?
第三范式解决的问题是第二范式带来的插入、删除异常、数据冗余度大河修改复制等问题。表格5有没有数据冗余呢?
从数据上来看,关系中的(所在系,系名字,系地址)是存在一定的冗余的,且所在系依赖于学号,而系名字和系地址是依赖于所在系的,由此可以得出,系名字和系地址,存在传递函数依赖。
改成表格6和表格7,则满足第三范式。
总结一下,第二范式消除了部分函数依赖,第三范式消除了传递函数依赖。
说个题外话,反范式。
数据库的范式设计是为了减少数据冗余,减少数据的插入、修改和删除异常,让数据各司其职,分工更加明确,数据组织更加和谐。
但是这样在开发过程中一定就更方便使用了吗?
当数据库设计严格按照第三范式来设计时,表会越来越多,而表多带来的问题则是查询时要不断的连接多个表,增加了查询语句的复杂度和数据库的查询性能。第三范式可以说是牺牲了性能(时间)来换取空间。
反范式就是不遵守范式,增加一些冗余,来提高查询速度。但也并不是不能完全不遵守范式,毕竟这个东西设计出来并流传下来,好处是毋庸置疑的,让关系数据库更加稳定。
所以个人觉得,开发过程中,如果一些数据频繁查询,且不在同一张表,可以考虑反范式设计,即在第三范式的基础上,适当的添加一些冗余,这样无论是数据结构还是可读性都取了一个折中点。
举个例子:有3个关系模型分别是客户、商品和销售记录
客户(客户编码,客户名,手机号,地址)
商品(商品编码,商品名,价格)
销售记录(流水号,客户编码,商品编码,销售数量,销售时间)
当我们要查询某个时间,各客户购买的商品记录,所编写的SQL语句如下:
SELECT C.客户名,B.商品名SUM(A.销售数量) AS 购买总数SUM(A.销售数量 * B.价格) AS 消费金额FROM 销售记录 ALEFT JOIN 商品 B ON A.商品编码=B.商品编码LEFT JOIN 客户 C ON A.客户编码=C.客户编码WHERE TO_CHAR(A.销售时间,'YYYY') = GROUP BY A.商品编码,A.客户编码,C.客户名,B.商品名
这样一看似乎并不是多复杂,但如果表更多了呢?多了一个进货信息表要查询利润呢?多了一个客户会员制度要查询该客户下个月的打折折扣呢?是不是感觉一瞬间就麻烦了起来。
所以这3个关系,如果能在销售记录关系中加以修改,增加适当的冗余不再遵循3范式。
销售记录(流水号,客户编码,客户名,商品编码,商品名,销售数量,销售时间)
这样我们从这一个表格,就能算出以上所需要的数据,不再需要连接商品和客户两个表。
当然了,具体的反范式设计还是需要根据实际情况来选择,不能一味的为了追求查询效率而乱添加冗余,毕竟提高数据库的性能,并不只是靠反范式,还有很多方法,比如索引,比如视图,比如Oracle的parallel模式等等。