- 浏览: 984218 次
- 性别:
- 来自: 杭州
文章分类
- 全部博客 (826)
- 硬件 (8)
- 软件 (24)
- 软件工程 (34)
- JAVA (229)
- C/C++/C# (77)
- JavaScript (8)
- PHP (1)
- Ruby (3)
- MySQL (14)
- 数据库 (19)
- 心情记事 (12)
- 团队管理 (19)
- Hadoop (1)
- spring (22)
- mybatis(ibatis) (7)
- tomcat (16)
- velocity (0)
- 系统架构 (6)
- JMX (8)
- proxool (1)
- 开发工具 (16)
- python (10)
- JVM (27)
- servlet (5)
- JMS (26)
- ant (2)
- 设计模式 (5)
- 智力题 (2)
- 面试题收集 (1)
- 孙子兵法 (16)
- 测试 (1)
- 数据结构 (7)
- 算法 (22)
- Android (11)
- 汽车驾驶 (1)
- lucene (1)
- memcache (12)
- 技术架构 (7)
- OTP-Erlang (7)
- memcached (17)
- redis (20)
- 浏览器插件 (3)
- sqlite (3)
- Heritrix (9)
- Java线程 (1)
- scala (0)
- Mina (6)
- 汇编 (2)
- Netty (15)
- libevent (0)
- CentOS (12)
- mongod (5)
- mac os (0)
最新评论
-
kingasdfg:
你这里面存在一个错误添加多个任务 应该是这样的 /** * ...
Quartz的任务的临时启动和暂停和恢复【转】 -
kyzeng:
纠正一个错误,long型对应的符号是J,不是L。
Jni中C++和Java的参数传递 -
zhaohaolin:
抱歉,兄弟,只是留下作记录,方便学习,如果觉得资料不好,可以到 ...
netty的个人使用心得【转】 -
cccoooccooco:
谢谢!自己一直以为虚机得使用网线才可以与主机连接呢。。
主机网卡无网线连接与虚拟机通信 -
yuqilin001:
要转别人的东西,请转清楚点嘛,少了这么多类,误人子弟
netty的个人使用心得【转】
引用 G>第一范式(1NF):G>在关系模式R中的每一个具体关系r中,如果每个属性值都是不可再分的最小数据单位,则称R是第一范式的关系。例:如职工号,姓名,电话号码组成一个表(一个人可能有一个办公室电话和一个家里电话号码) 规范成为1NF有三种方法: G>第二范式(2NF):G>如果关系模式R(U,F)中的所有非主属性都完全依赖于任意一个候选关键字,则称关系R 是属于第二范式的。 G>第三范式(3NF):G>如果关系模式R(U,F)中的所有非主属性对任何候选关键字都不存在传递信赖,则称关系R是属于第三范式的。 BCNF:如果关系模式R(U,F)的所有属性(包括主属性和非主属性)都不传递依赖于R的任何候选关键字,那么称关系R是属于BCNF的。或是关系模式R,如果每个决定因素都包含关键字(而不是被关键字所包含),则RCNF的关系模式。 一个关系分解成多个关系,要使得分解有意义,起码的要求是分解后不丢失原来的信息。这些信息不仅包括数据本身,而且包括由函数依赖所表示的数据之间的相互制约。进行分解的目标是达到更高一级的规范化程度,但是分解的同时必须考虑两个问题:无损联接性和保持函数依赖。有时往往不可能做到既有无损联接性,又完全保持函数依赖。需要根据需要进行权衡。 1NF直到BCNF的四种范式之间有如下关系: 附另一篇文章: 本文将对范式进行通俗地说明,并以笔者曾经设计的一个简单论坛的数据库为例来讲解怎样将这些范式应用于实际工程。 范式说明 第一范式(1NF):数据库表中的字段都是单一属性的,不可再分。这个单一属性由基本类型构成,包括整型、实数、字符型、逻辑型、日期型等。 例如,如下的数据库表是符合第一范式的: 字段1 字段2 字段3 字段4 字段1 字段2 字段3 字段4 第二范式(2NF):数据库表中不存在非关键字段对任一候选关键字段的部分函数依赖(部分函数依赖指的是存在组合关键字中的某些字段决定非关键字段的情况),也即所有非关键字段都完全依赖于任意一组候选关键字。 假定选课关系表为 SelectCourse (学号, 姓名, 年龄, 课程名称, 成绩, 学分),关键字为组合关键字(学号, 课程名称),因为存在如下决定关系: (学号, 课程名称) → (姓名, 年龄, 成绩, 学分) 这个数据库表不满足第二范式,因为存在如下决定关系: (课程名称) → (学分) (学号) → (姓名, 年龄) 即存在组合关键字中的字段决定非关键字的情况。 由于不符合2NF,这个选课关系表会存在如下问题: (1) 数据冗余: 同一门课程由n个学生选修,"学分"就重复n-1次;同一个学生选修了m门课程,姓名和年龄就重复了m-1次。 (2) 更新异常: 若调整了某门课程的学分,数据表中所有行的"学分"值都要更新,否则会出现同一门课程学分不同的情况。 (3) 插入异常: 假设要开设一门新的课程,暂时还没有人选修。这样,由于还没有"学号"关键字,课程名称和学分也无法记录入数据库。 (4) 删除异常: 假设一批学生已经完成课程的选修,这些选修记录就应该从数据库表中删除。但是,与此同时,课程名称和学分信息也被删除了。很显然,这也会导致插入异常。 把选课关系表SelectCourse改为如下三个表: 学生:Student(学号, 姓名, 年龄); 课程:Course(课程名称, 学分); 选课关系:SelectCourse(学号, 课程名称, 成绩)。 这样的数据库表是符合第二范式的,消除了数据冗余、更新异常、插入异常和删除异常。 另外,所有单关键字的数据库表都符合第二范式,因为不可能存在组合关键字。 第三范式(3NF):在第二范式的基础上,数据表中如果不存在非关键字段对任一候选关键字段的传递函数依赖则符合第三范式。所谓传递函数依赖,指的是如果存在"A → B → C"的决定关系,则C传递函数依赖于A。因此,满足第三范式的数据库表应该不存在如下依赖关系: 关键字段 → 非关键字段x → 非关键字段y 假定学生关系表为Student(学号, 姓名, 年龄, 所在学院, 学院地点, 学院电话),关键字为单一关键字"学号",因为存在如下决定关系: (学号) → (姓名, 年龄, 所在学院, 学院地点, 学院电话) 这个数据库是符合 2NF 的,但是不符合 3NF,因为存在如下决定关系: (学号) → (所在学院) → (学院地点, 学院电话) 即存在非关键字段"学院地点"、"学院电话"对关键字段"学号"的传递函数依赖。 它也会存在数据冗余、更新异常、插入异常和删除异常的情况,读者可自行分析得知。 把学生关系表分为如下两个表: 学生:(学号, 姓名, 年龄, 所在学院); 学院:(学院, 地点, 电话)。 这样的数据库表是符合第三范式的,消除了数据冗余、更新异常、插入异常和删除异常。 鲍依斯-科得范式(BCNF):在第三范式的基础上,数据库表中如果不存在任何字段对任一候选关键字段的传递函数依赖则符合第三范式。 假设仓库管理关系表为StorehouseManage(仓库ID, 存储物品ID, 管理员ID, 数量),且有一个管理员只在一个仓库工作;一个仓库可以存储多种物品。这个数据库表中存在如下决定关系: (仓库ID, 存储物品ID) →(管理员ID, 数量) (管理员ID, 存储物品ID) → (仓库ID, 数量) 所以,(仓库ID, 存储物品ID)和(管理员ID, 存储物品ID)都是StorehouseManage的候选关键字,表中的唯一非关键字段为数量,它是符合第三范式的。但是,由于存在如下决定关系: (仓库ID) → (管理员ID) (管理员ID) → (仓库ID) 即存在关键字段决定关键字段的情况,所以其不符合BCNF范式。它会出现如下异常情况: (1) 删除异常: 当仓库被清空后,所有"存储物品ID"和"数量"信息被删除的同时,"仓库ID"和"管理员ID"信息也被删除了。 (2) 插入异常: 当仓库没有存储任何物品时,无法给仓库分配管理员。 (3) 更新异常: 如果仓库换了管理员,则表中所有行的管理员ID都要修改。 把仓库管理关系表分解为二个关系表: 仓库管理:StorehouseManage(仓库ID, 管理员ID); 仓库:Storehouse(仓库ID, 存储物品ID, 数量)。 这样的数据库表是符合BCNF范式的,消除了删除异常、插入异常和更新异常。 范式应用 我们来逐步搞定一个论坛的数据库,有如下信息: (1) 用户:用户名,email,主页,电话,联系地址 (2) 帖子:发帖标题,发帖内容,回复标题,回复内容 第一次我们将数据库设计为仅仅存在表: 用户名 email 主页 电话 联系地址 发帖标题 发帖内容 回复标题 回复内容 用户名 email 主页 电话 联系地址 发帖ID 发帖标题 发帖内容 回复ID 回复标题 回复内容 (用户名,发帖ID,回复ID) → (email,主页,电话,联系地址,发帖标题,发帖内容,回复标题,回复内容) 但是,这样的设计不符合第二范式,因为存在如下决定关系: (用户名) → (email,主页,电话,联系地址) (发帖ID) → (发帖标题,发帖内容) (回复ID) → (回复标题,回复内容) 即非关键字段部分函数依赖于候选关键字段,很明显,这个设计会导致大量的数据冗余和操作异常。 我们将数据库表分解为(带下划线的为关键字): (1) 用户信息:用户名,email,主页,电话,联系地址 (2) 帖子信息:发帖ID,标题,内容 (3) 回复信息:回复ID,标题,内容 (4) 发贴:用户名,发帖ID (5) 回复:发帖ID,回复ID 这样的设计是满足第1、2、3范式和BCNF范式要求的,但是这样的设计是不是最好的呢? 不一定。 观察可知,第4项"发帖"中的"用户名"和"发帖ID"之间是1:N的关系,因此我们可以把"发帖"合并到第2项的"帖子信息"中;第5项"回复"中的"发帖ID"和"回复ID"之间也是1:N的关系,因此我们可以把"回复"合并到第3项的"回复信息"中。这样可以一定量地减少数据冗余,新的设计为: (1) 用户信息:用户名,email,主页,电话,联系地址 (2) 帖子信息:用户名,发帖ID,标题,内容 (3) 回复信息:发帖ID,回复ID,标题,内容 数据库表1显然满足所有范式的要求; 数据库表2中存在非关键字段"标题"、"内容"对关键字段"发帖ID"的部分函数依赖,即不满足第二范式的要求,但是这一设计并不会导致数据冗余和操作异常; 数据库表3中也存在非关键字段"标题"、"内容"对关键字段"回复ID"的部分函数依赖,也不满足第二范式的要求,但是与数据库表2相似,这一设计也不会导致数据冗余和操作异常。 由此可以看出,并不一定要强行满足范式的要求,对于1:N关系,当1的一边合并到N的那边后,N的那边就不再满足第二范式了,但是这种设计反而比较好! 对于M:N的关系,不能将M一边或N一边合并到另一边去,这样会导致不符合范式要求,同时导致操作异常和数据冗余。 结论 满足范式要求的数据库设计是结构清晰的,同时可避免数据冗余和操作异常。这并意味着不符合范式要求的设计一定是错误的,在数据库表中存在1:1或1:N关系这种较特殊的情况下,合并导致的不符合范式要求反而是合理的。 在我们设计数据库的时候,一定要时刻考虑范式的要求。
大海 的 数据库范式详细解释
一是重复存储职工号和姓名。这样,关键字只能是电话号码。
二是职工号为关键字,电话号码分为单位电话和住宅电话两个属性
三是职工号为关键字,但强制每条记录只能有一个电话号码。
以上三个方法,第一种方法最不可取,按实际情况选取后两种情况。
例:选课关系 SCI(SNO,CNO,GRADE,CREDIT)其中SNO为学号, CNO为课程号,GRADEGE 为成绩,CREDIT 为学分。 由以上条件,关键字为组合关键字(SNO,CNO)
在应用中使用以上关系模式有以下问题:
a.数据冗余,假设同一门课由40个学生选修,学分就 重复40次。
b.更新异常,若调整了某课程的学分,相应的元组CREDIT值都要更新,有可能会出现同一门课学分不同。
c.插入异常,如计划开新课,由于没人选修,没有学号关键字,只能等有人选修才能把课程和学分存入。
d.删除异常,若学生已经结业,从当前数据库删除选修记录。某些门课程新生尚未选修,则此门课程及学分记录无法保存。
原因:非关键字属性CREDIT仅函数依赖于CNO,也就是CREDIT部分依赖组合关键字(SNO,CNO)而不是完全依赖。
解决方法:分成两个关系模式 SC1(SNO,CNO,GRADE),C2(CNO,CREDIT)。新关系包括两个关系模式,它们之间通过SC1中的外关键字CNO相联系,需要时再进行自然联接,恢复了原来的关系
例:如S1(SNO,SNAME,DNO,DNAME,LOCATION) 各属性分别代表学号,
姓名,所在系,系名称,系地址。
关键字SNO决定各个属性。由于是单个关键字,没有部分依赖的问题,肯定是2NF。但这关系肯定有大量的冗余,有关学生所在的几个属性DNO,DNAME,LOCATION将重复存储,插入,删除和修改时也将产生类似以上例的情况。
原因:关系中存在传递依赖造成的。即SNO -> DNO。 而DNO -> SNO却不存在,DNO -> LOCATION, 因此关键辽 SNO 对 LOCATION 函数决定是通过传递依赖 SNO -> LOCATION 实现的。也就是说,SNO不直接决定非主属性LOCATION。
解决目地:每个关系模式中不能留有传递依赖。
解决方法:分为两个关系 S(SNO,SNAME,DNO),D(DNO,DNAME,LOCATION)
注意:关系S中不能没有外关键字DNO。否则两个关系之间失去联系。
例:配件管理关系模式 WPE(WNO,PNO,ENO,QNT)分别表仓库号,配件号,职工号,数量。有以下条件
a.一个仓库有多个职工。
b.一个职工仅在一个仓库工作。
c.每个仓库里一种型号的配件由专人负责,但一个人可以管理几种配件。
d.同一种型号的配件可以分放在几个仓库中。
分析:由以上得 PNO 不能确定QNT,由组合属性(WNO,PNO)来决定,存在函数依赖(WNO,PNO) -> ENO。由于每个仓库里的一种配件由专人负责,而一个人可以管理几种配件,所以有组合属性(WNO,PNO)才能确定负责人,有(WNO,PNO)-> ENO。因为 一个职工仅在一个仓库工作,有ENO -> WNO。由于每个仓库里的一种配件由专人负责,而一个职工仅在一个仓库工作,有 (ENO,PNO)-> QNT。
找一下候选关键字,因为(WNO,PNO) -> QNT,(WNO,PNO)-> ENO ,因此(WNO,PNO)可以决定整个元组,是一个候选关键字。根据ENO->WNO,(ENO,PNO)->QNT,故(ENO,PNO)也能决定整个元组,为另一个候选关键字。属性ENO,WNO,PNO 均为主属性,只有一个非主属性QNT。它对任何一个候选关键字都是完全函数依赖的,并且是直接依赖,所以该关系模式是3NF。
分析一下主属性。因为ENO->WNO,主属性ENO是WNO的决定因素,但是它本身不是关键字,只是组合关键字的一部分。这就造成主属性WNO对另外一个候选关键字(ENO,PNO)的部分依赖,因为(ENO,PNO)-> ENO但反过来不成立,而P->WNO,故(ENO,PNO)-> WNO 也是传递依赖。
虽然没有非主属性对候选关键辽的传递依赖,但存在主属性对候选关键字的传递依赖,同样也会带来麻烦。如一个新职工分配到仓库工作,但暂时处于实习阶段,没有独立负责对某些配件的管理任务。由于缺少关键字的一部分PNO而无法插入到该关系中去。又如某个人改成不管配件了去负责安全,则在删除配件的同时该职工也会被删除。
解决办法:分成管理EP(ENO,PNO,QNT),关键字是(ENO,PNO)工作EW(ENO,WNO)其关键字是ENO
缺点:分解后函数依赖的保持性较差。如此例中,由于分解,函数依赖(WNO,PNO)-> ENO 丢失了, 因而对原来的语义有所破坏。没有体现出每个仓库里一种部件由专人负责。有可能出现一部件由两个人或两个以上的人来同时管理。因此,分解之后的关系模式降低了部分完整性约束。
BCNF包含了3NF包含2NF包含1NF
而这样的数据库表是不符合第一范式的:
字段3.1 字段3.2
很显然,在当前的任何关系数据库管理系统(DBMS)中,傻瓜也不可能做出不符合第一范式的数据库,因为这些DBMS不允许你把数据库表的一列再分成二列或多列。因此,你想在现有的DBMS中设计出不符合第一范式的数据库都是不可能的。
这个数据库表符合第一范式,但是没有任何一组候选关键字能决定数据库表的整行,唯一的关键字段用户名也不能完全决定整个元组。我们需要增加"发帖ID"、"回复ID"字段,即将表修改为:
这样数据表中的关键字(用户名,发帖ID,回复ID)能决定整行:
对于1:1的关系,我们可以将左边的1或者右边的1合并到另一边去,设计导致不符合范式要求,但是并不会导致操作异常和数据冗余。
发表评论
-
VS2010 C++下编译调试MongoDB源码[转]
2011-12-17 00:48 1314考虑到mongodb使用了boost库源码,参考mongodb ... -
mysql 批量update
2011-05-25 17:56 2898我们都知道在MySQL中批量insert的速度会比一条条ins ... -
MySQL查询及删除重复记录的方法
2011-05-06 18:43 1125查询及删除重复记录的方法(一)1、查找表中多余的重复记录, ... -
MYSQL删除重复记录(此处有正解)
2011-05-06 14:11 911有关mysql删除重复记录的方法,我在网上看到很多文章,很多是 ... -
Java嵌入式数据库LMini-0.1.2及其通讯录使用示例发布【转】
2011-05-06 01:14 815文章关键字:Java 嵌入 ... -
Java开源数据库、Java嵌入式数据库、Java内存数据库 第一部分
2011-05-05 20:33 2143Java免费开源数据库、Java 嵌入式数据库、Java ... -
Java开源数据库、Java嵌入式数据库、Java内存数据库 第二部分
2011-05-05 20:32 1578Apache Xindice Apache Xin ... -
Java嵌入式数据库LMini-0.1.2及其通讯录使用示例发布
2011-05-05 20:32 805[转]下载地址(这些小程序依例丢在code.google上 ... -
轻松掌握MySQL数据库锁机制的相关原理
2011-03-29 19:40 853《轻松掌握MySQL数据库 ... -
MySQL错误_中文参照列表
2011-02-15 20:26 704MySQL错误_中文参照列表 1005:创建表失败 ... -
mysql 的最大连接
2011-02-15 20:25 718mysql 的最大连接 系统不能连接数据库,关键要看两个数据 ... -
查询及删除重复记录的方法 (一) 1、查找表中多余的重复记录,重复记录是根据单个字段(peopleId)来判断 select * from people whe
2011-02-15 20:23 1357一个MYSQL多值查询的存储过程 DELIMITER $$ ... -
MySQL查询及删除重复记录的方法
2011-02-15 20:22 899MySQL查询及删除重复记录的方法 查询及删除重复记录的方法 ... -
引用 [原创]数据库事务
2011-02-12 23:05 865引用 [原创]数据库事务 数据库事务 200 ... -
引用 [转]转一个关于优化sql的文章
2011-02-12 23:04 717引用 [转]转一个关于优化sql的文章 数据 ... -
JDBC事务隔离级别
2011-02-12 23:04 1040JDBC事务隔离级别 数据库事务 2009- ... -
jdbc查看数据库事务隔离级别
2011-02-12 23:01 1524jdbc查看数据库事务隔离级别 数据库事务 ... -
数据库设计的三范式
2011-02-12 22:58 1014数据库设计的三范式 数据库及设计 2009- ...
相关推荐
详细设计阶段:将E-R图转换为多张表,进行逻辑设计,并应用数据库设计的三大范式进行审核; 代码编写阶段:选择具体数据库进行物理实现; 软件测试阶段:…… 安装部署:…… 数据库设计培训全文共37页,当前为第8页...
第8章介绍了商业智能(BI)系统和支持它们的数据仓库体系结构,还讨论了多维数据库,解释了如何为Heather Sweeney Designs建立多维数据库,并使用它生成PivotTable OLAP报表。 附录A提供了SQL Server 2008 R2 Express...
应用范式规范化设计应用第二范式规范化应用第三范式规范化规范化和性能的关系 总结 2-1 在需求分析阶段,设计数据库的一般步骤为:收集信息标识对象标识每个对象的属性标识对象之间的关系在概要设计阶段和详细设计...
1.5 规范引用文件 第二部分 编程规范 2 书写规范 2.1 大小写风格 2.2 缩进风格 2.3 空格及换行 2.4 其它 3、命名规范: 3.1 对象命名汇总表 3.2 对象命名 3.3 变量命名 3.4 表分区命名 4、注释规范 5、语法规范 ...
XXX数据库设计规范模板 目 次 1 范围 2 引用文件 3 术语、定义和缩略语 3.1 术语 3.2 缩略语 4 总体要求 4.1 数据库设计总体要求 4.2 数据库编程总体要求 5 数据库设计要求 5.1 数据库字符集选择 5.2 数据库表空间...
19.7哪些写法会导致索引用不了 43 二十、 数据库对象:序列号sequence 44 20.1什么是sequence 44 20.2创建sequence 44 20.3缺省是nocycle(不循环) 44 20.4缺省cache 20 44 二十一、 其他注意事项 46 21.1删除表,...
7.5.2 通用键引用 7.5.3 对非结构化数据的过度使用 7.6 总结 7.7 回顾与展望 第8章 数据访问安全 8.1 安全主体与安全对象 8.2 数据库安全概述 8.2.1 模拟 8.2.2 权限 8.2.3 控制对象...
1.1.6 范式化 1.2 高级语言 1.2.1 结构化查询语言 1.2.2 数据定义语言 1.2.3 数据处理语言 1.2.4 数据查询语言 1.3 事务管理和事务控制命令 1.3.1 ACID测试 1.3.2 SQL中的事务管理 1.4 数据库安全和数据...
本文将从系统的业务功能、性能需求方面结合3年来信贷管理系统实施 中数据库的改进经验,对信贷管理系统数据库的设计要点做了较详细的分析,并提供了相 应的解决方案。 [关键词] 银行信贷管理系统;信贷;数据库;设计;...
2、对表结构进行规范化处理(第三范式) 表名命名规范:表以T+项目缩写+表英文名, 首字母大写并以下划线连接;视图为V+项目缩写+表英文名,其余和表一样;存储过程为Pro+项目缩写+过程英文名。 字段命名规范:所有...
数据库设计三大范式 为了建立冗余较小、结构合理的数据库,设计数据库时必须遵循一定的规则。在关系型 数据库中这种规则就称为范式。范式是符合某一种设计要求的总结。要想设计一个结构 合理的关系型数据库,必须...
第2章 数据库建模 【考试目的】 考核考生对数据库建模的两种基本方法掌握的程度以及对键码和引用完整性这两个 基本概念理解的情况。 【考试的知识点】 1.对象定义语言:面向对象的设计;类的说明;ODL中的属性、...
1.1.6 范式化 1.2 高级语言 1.2.1 结构化查询语言 1.2.2 数据定义语言 1.2.3 数据处理语言 1.2.4 数据查询语言 1.3 事务管理和事务控制命令 1.3.1 ACID测试 1.3.2 SQL中的事务管理 1.4 数据库安全和数据...
1.1.6 范式化 1.2 高级语言 1.2.1 结构化查询语言 1.2.2 数据定义语言 1.2.3 数据处理语言 1.2.4 数据查询语言 1.3 事务管理和事务控制命令 1.3.1 ACID测试 1.3.2 SQL中的事务管理 1.4 数据库安全和数据...
1.1.6 范式化 1.2 高级语言 1.2.1 结构化查询语言 1.2.2 数据定义语言 1.2.3 数据处理语言 1.2.4 数据查询语言 1.3 事务管理和事务控制命令 1.3.1 ACID测试 1.3.2 SQL中的事务管理 1.4 数据库安全和数据...
三范式:列不可拆分、唯一标识、引用主键 关系及储存: 1对1 1对多 多对多 1个A对1个B 1个A对几个B 1个A对几个B 1个B对1个A 1个B对1个A 1个B对几个A 关系存A或B 关系存B 关系存新建表C 数据库文件:1....
在第二部分我将会覆盖更多高级内容,包括反范式化和双向引用。在最后一部分,我将会回顾各种选择,并给出做决定时需要考虑的因素。很多初学者认为在MongoDB中针对一对多建模唯一的方案就是在父文档中内嵌一个数组子...
4.3 关于引用的解释 67 4.3.1 对变量的引用 67 4.3.2 对函数的引用 68 4.3.3 引用的释放 68 4.4 小结 69 第5章 PHP中类的应用 70 5.1 PHP中OOP的应用 70 5.1.1 类简介 70 5.1.2 类的信息封装 71 5.1.3 静态类 71 5.2...