谁知道数据库的几大范式

分类: 电脑/网络 >> 软件

问题描述:

最好用通俗的语言

解析:

第一范式（1NF）：在关系模式R中的每一个具体关系r中，如果每个属性值 都是不可再分的最小数据单位，则称R是第一范式的关系。例：如职工号，姓名，电话号码组成一个表（一个人可能有一个办公室电话 和一个家里电话号码） 规范成为1NF有三种方法：

一是重复存储职工号和姓名。这样，关键字只能是电话号码。

二是职工号为关键字，电话号码分为单位电话和住宅电话两个属性

三是职工号为关键字，但强制每条记录只能有一个电话号码。

以上三个方法，第一种方法最不可取，按实际情况选取后两种情况。

第二范式（2NF）：如果关系模式R（U，F）中的所有非主属性都完全依赖于任意一个候选关键字，则称关系R 是属于第二范式的。

例：选课关系 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相联系，需要时再进行自然联接，恢复了原来的关系

第三范式（3NF）：如果关系模式R（U，F）中的所有非主属性对任何候选关键字都不存在传递信赖，则称关系R是属于第三范式的。

例：如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。否则两个关系之间失去联系。

BCNF：如果关系模式R（U，F）的所有属性（包括主属性和非主属性）都不传递依赖于R的任何候选关键字，那么称关系R是属于BCNF的。或是关系模式R，如果每个决定因素都包含关键字（而不是被关键字所包含），则RCNF的关系模式。

例：配件管理关系模式 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 丢失了, 因而对原来的语义有所破坏。没有体现出每个仓库里一种部件由专人负责。有可能出现 一部件由两个人或两个以上的人来同时管理。因此，分解之后的关系模式降低了部分完整性约束。

一个关系分解成多个关系，要使得分解有意义，起码的要求是分解后不丢失原来的信息。这些信息不仅包括数据本身，而且包括由函数依赖所表示的数据之间的相互制约。进行分解的目标是达到更高一级的规范化程度，但是分解的同时必须考虑两个问题：无损联接性和保持函数依赖。有时往往不可能做到既有无损联接性，又完全保持函数依赖。需要根据需要进行权衡。

1NF直到BCNF的四种范式之间有如下关系：

BCNF包含了3NF包含2NF包含1NF

MIDAS“设计用数值截面”无法进行RC设计是psc参数设置问题，解决方法如下：

1、从主菜单中选择 设计 >PSC设计> PSC设计参数，从树形菜单的菜单表单中选择 设计 > PSC设计参数 > PSC设计参数。

2、从主菜单中选择 设计>PSC设计>PSC设计截面位置，从树形菜单的菜单表单中选择 设计>PSC设计参数>PSC设计截面位置。

3、从主菜单中选择设计>PSC设计>PSC输出截面位置，从树形菜单的菜单表单中选择设计>PSC设计参数>PSC输出截面位置，添加最初输入的单元，修改已输入的单元。

4、从主菜单中选择 设计>PSC设计>PSC设计结果表格>施工阶段正截面法向应力验算，从树形菜单的表格表单中选择设计表格>PSC设计>施工阶段面法向应力验算。

5、在"分析 > 主控数据"中必须选择“计算截面刚度时考虑钢筋”，否则程序计算截面特性时将不考虑预应力钢筋的作用。退出页面，保存就可以了。

1、select from tb_reader tr where trlength>3; 这里面偷懒，用代替了字段，需要哪些字段，自己添加吧

2、select trreaderid,trreadername,sum(tbbookid) from tb_reader tr join tb_bookdet tb on tbbookcode = trbookcode group by trreaderid,trreadername ;

3、select trreadername from tb_reader tr where exists (select 1 from tb_bookdet tb where trtbbookcode = trbookcode and tbstatus ='借出');

4、create view view_bookinfo as select tbibookid, tbibookname, tbiauthor, tbipublisher from tb_reader tr

join tb_bookdet tb on tbbookcode = trbookcode

join tb_bookinfo tbi on tbbookid = tbibookid

where trbackdate > sysdate and trbackdate - sysdate <10;

5、create nonclustered index INDEX_DEPARTMENT tb_reader(department);---创建索引，department该字段非空、且不重复。

alter table tb_reader add primary key nonclustered(department); ----修改索引

在oracle数据库的开发环境和测试环境中 数据库的日志模式和自动归档模式一般都是不设置的 这样有利于系统应用的调整 也免的生成大量的归档日志文件将磁盘空间大量的消耗 但在系统上线 成为生产环境时 将其设置为日志模式并自动归档就相当重要了 因为 这是保证系统的安全性 有效预防灾难的重要措施 这样 通过定时备份数据库和在两次备份间隔之间的日志文件 可以有效的恢复这段时间的任何时间点的数据 可以在很多时候挽回或最大可能的减少数据丢失 虽然ORACLE数据库的日志模式和自动归档设置并不复杂 但其中的一些概念和 *** 作过程还是容易混淆的 现在根据本人的经验 分析介绍如下 所用环境为UNIX(HPUX SOLARIES AIX TRU UNIX)和ORACLE 一 要使OARCLE数据库进行日志的自动归档 需要做两方面的事情 一是数据库日志模式的设置(database log mode 可为Archive Mode和No Archive Mode) 另外就是自动归档模式设置(Automatic archival 可为Enabled和Disabled) 二 如何查看数据库的现行日志和自动归档模式的设置 可用archive log list命令来查看 例如 运行在日志自动归档模式下的数据库系统查看结果如下（一般是生产环境）SVRMGR> archive log listDatabase log mode　Archive ModeAutomatic archival EnabledArchive destination/backup/archivelogOldest online log sequence Next log sequence to archive　 Current log sequence　 没有启动数据库日志模式和自动归档的数据库系统查看结果如下（一般是测试环境）SVRMGR> archive log listDatabase log mode　No Archive ModeAutomatic archival DisabledArchive destination/u /app/oracle/product/ /dbs/archOldest online log sequence Current log sequence　 三 数据库日志模式的设置 在创建数据库时 可以在CREATE DATABASE 语句中指定数据库的日志模式 假如没有指明 则缺省为NOARCHIVELOG模式 由于如果在创建数据库时指明是Archive Mode的话 会增加约 %的创建时间 而在以后启动INSTANCE时再设置的话 一般只用去几秒的时间 所以一般在创建数据库时是不设置为ARCHIVE MODE的 如要确定一系统数据库的日志模式设置 除了(二)中的方法外也可以执行如下 *** 作查看 SVRMGR> Select from V$DATABASENAME　CREATEDLOG_MODE　CHECKPOINT　ARCHIVE_CH ORCL　 / / : :NOARCHIVELOG　 将数据库的日志模式设置切换（Archive Mode 和No Archive Mode之间的切换）的步骤和 *** 作如下 关闭运行的数据库实例SVRMGRL>　shutdown在进行日志模式切换之前 必须将运行的数据库正常关闭 备份数据库该备份跟以后产生的日志一起用于将来的灾难恢复（很重要 如要改为归档日志模式 没有这个数据库备份 仅有日志文件是无法从该时间点恢复的） 启动数据库实例到mount状态 但不要打开 SVRMGRL> startup mount注意 如果是使用OPS的话 请只打开一个数据库实例进行模式切换 *** 作 切换数据库日志模式 SVRMGRL> alter database archivelog;(设置数据库为归档日志模式)或SVRMGRL> alter database noarchivelog;(设置数据库为归档日志模式) 打开数据库SVRMGRL> alter database open; 确认数据库现在处于归档日志模式 SVRMGRL> archive log list;Database log mode　 Archive ModeAutomatic archival　EnabledArchive destination for example: $ORACLE_HOME/dbs/archOldest on line log sequence Next log sequence　 Current log sequence 将这个时间点的redo logs归档SVRMGRL> archive log all; 确认新产生的日志文件已在相应的归档目录下面 四 自动归档模式设置(Automatic archival 可为Enabled和Disabled) 在该模式下 数据库启动一个arch进程 专门负责将redo logs写到系统归档设备的相应目录下 在数据库的参数文件中设置参数（一般是在$ORACLE_HOME/dbs/init ora文件中） LOG_ARCHIVE_START=LOG_ARCHIVE_DEST=LOG_ARCHIVE_FORMAT=LOG_ARCHIVE_START:如要求自动归档的话 则设为TRUE 如要求为非自动归档的话 则设为FALSELOG_ARCHIVE_DEST:该参数设定了archive logs 归档存放的路径 LOG_ARCHIVE_FORMAT:该参数设定了archive logs的命名格式 例如 如将格式设为:　arch%s arclog 文件将为:　arch arc arch arc arch arc这几个参数设置只有在数据库实例启动前设置才能生效 如果在数据库运行中进行设置 要使其生效 必须重起数据库 如果数据库正在运行中 不能即刻重起 要设置其为自动归档模式 则做如下 *** 作 SVRMGRL> ALTER SYSTEM ARCHIVE LOG START;如要设置其为非自动归档模式(取消自动归档) 则 SVRMGRL> ALTER SYSTEM ARCHIVE LOG STOP;但如果数据库重起后 给语句修改的结果就失效了 自动归档的设置还是按照系统参数文件中的LOG_ARCHIVE_START的值来设置 五 几种设置情况 ( )　Database log mode　Archive ModeAutomatic archival Enabled这是在大部分生产环境中的ORACLE数据库日志及归档模式设置 这种情况下 做好数据库的定期备份（有热备和冷备）和归档日志备份 可有效的将数据库恢复到有归档日志的全部时间点 ( )　Database log mode　Archive ModeAutomatic archival Disabled这种情况下 数据库不能自动归档 需要进行手工归档 如果所有在线日志都写满了 又没有的及时进行手工归档的话 由于LGWR没有可用的在线日志可写 数据库将会挂在这儿 只有进行手工归档后 有可用的在线日志后才能继续 在生产环境中应该避免这种情况 手工归档 *** 作如下 SVRMGRL> ALTER SYSTEM ARCHIVE LOG ALL;数据库将会把在线日志进行归档处理( )　Database log mode　NO Archive ModeAutomatic archival Enabled有些相对欠缺经验的管理员在进行设置时 只在数据库参数文件中设置了LOG_ARCHIVE_START=TRUE 然后在数据库起来后查看到ARCH归档进程已经起来了 可是尽管ORACLE已经作了几次日志切换 但还是没有归档日志 这时的设置就是这种情况 如果数据库不是处在ARVHIVELOG模式 redolog 还是不会被归档 ( )　Database log mode　NO Archive ModeAutomatic archival Disabled这种设置是刚安装的oracle数据库的缺省设置 开发环境也大部分如此 即没有进行归档 lishixinzhi/Article/program/Oracle/201311/18755

回答的有点多请耐心看完。

希望能帮助你还请及时采纳谢谢

1事务的原理

事务就是将一组SQL语句放在同一批次内去执行，如果一个SQL语句出错,则该批次内的所有SQL都将被取消执行。MySQL事务处理只支持InnoDB和BDB数据表类型。

1事务的ACID原则

1（Atomicity）原子性： 事务是最小的执行单位，不允许分割。原子性确保动作要么全部完成，要么完全不起作用；

2（Consistency）一致性： 执行事务前后，数据保持一致；

3（Isolation）隔离性： 并发访问数据库时，一个事务不被其他事务所干扰。

4（Durability）持久性: 一个事务被提交之后。对数据库中数据的改变是持久的，即使数据库发生故障。

1缓冲池（Buffer Pool）

Buffer Pool中包含了磁盘中部分数据页的映射。当从数据库读取数据时，会先从Buffer Pool中读取数据，如果Buffer Pool中没有，则从磁盘读取后放入到Buffer Pool中。当向数据库写入数据时，会先写入到Buffer Pool中，Buffer Pool中更新的数据会定期刷新到磁盘中（此过程称为刷脏）。

2日志缓冲区（Log Buffer）

当在MySQL中对InnoDB表进行更改时，这些更改命令首先存储在InnoDB日志缓冲区（Log Buffer）的内存中，然后写入通常称为重做日志（redo logs）的InnoDB日志文件中。

3双写机制缓存（DoubleWrite Buffer）

Doublewrite Buffer是共享表空间的物理文件的 buffer,其大小是2MB是一个一分为二的2MB空间。

刷脏 *** 作开始之时,先进行脏页‘备份’ *** 作将脏页数据写入 Doublewrite Buffer

将Doublewrite Buffer(顺序IO)写入磁盘文件中(共享表空间) 进行刷脏 *** 作

4回滚日志(Undo Log)

Undo Log记录的是逻辑日志记录的是事务过程中每条数据的变化版本和情况

在Innodb 磁盘架构中Undo Log 默认是共享表空间的物理文件的Buffer

在事务异常中断,或者主动(Rollback)回滚的过程中 ,Innodb基于 Undo Log进行数据撤销回滚,保证数据回归至事务开始状态

5重做日志(Redo Log)

Redo Log通常指的是物理日志，记录的是数据页的物理修改并不记录行记录情况。（也就是只记录要做哪些修改，并不记录修改的完成情况） 当数据库宕机重启的时候，会将重做日志中的内容恢复到数据库中。

1原子性

Innodb事务的原子性保证,包含事务的提交机制和事务的回滚机制在Innodb引擎中事务的回滚机制是依托 回滚日志(Undo Log) 进行回滚数据，保证数据回归至事务开始状态

2那么不同的隔离级别，隔离性是如何实现的，为什么不同事物间能够互不干扰？ 答案是 锁 和 MVCC。

3持久性

基于事务的提交机制流程有可能出现三种场景

1 数据刷脏正常一切正常提交，Redo Log 循环记录数据成功落盘持久性得以保证

2数据刷脏的过程中出现的系统意外导致页断裂现象 (部分刷脏成功)，针对页断裂情况,采用Double write机制进行保证页断裂数据的恢复

3数据未出现页断裂现象,也没有刷脏成功，MySQL通过Redo Log 进行数据的持久化即可

4一致性

从数据库层面，数据库通过原子性、隔离性、持久性来保证一致性

2事务的隔离级别

Mysql 默认采用的 REPEATABLE_READ隔离级别 Oracle 默认采用的 READ_COMMITTED隔离级别

脏读： 指一个事务读取了另外一个事务未提交的数据。

不可重复读： 在一个事务内读取表中的某一行数据，多次读取结果不同

虚读(幻读)： 是指在一个事务内读取到了别的事务插入的数据，导致前后读取不一致。

2基本语法

-- 使用set语句来改变自动提交模式

SET autocommit = 0; /关闭/

SET autocommit = 1; /开启/

-- 注意:

--- 1MySQL中默认是自动提交

--- 2使用事务时应先关闭自动提交

-- 开始一个事务,标记事务的起始点

START TRANSACTION

-- 提交一个事务给数据库

COMMIT

-- 将事务回滚,数据回到本次事务的初始状态

ROLLBACK

-- 还原MySQL数据库的自动提交

SET autocommit =1;

-- 保存点

SAVEPOINT 保存点名称 -- 设置一个事务保存点

ROLLBACK TO SAVEPOINT 保存点名称 -- 回滚到保存点

RELEASE SAVEPOINT 保存点名称 -- 删除保存点

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

/

课堂测试题目

A在线买一款价格为500元商品,网上银行转账

A的yhk余额为2000,然后给商家B支付500

商家B一开始的yhk余额为10000

创建数据库shop和创建表account并插入2条数据

/

CREATE DATABASE `shop`CHARACTER SET utf8 COLLATE utf8_general_ci;

USE `shop`;

CREATE TABLE `account` (

`id` INT(11) NOT NULL AUTO_INCREMENT,

`name` VARCHAR(32) NOT NULL,

`cash` DECIMAL(9,2) NOT NULL,

PRIMARY KEY (`id`)

) ENGINE=INNODB DEFAULT CHARSET=utf8

INSERT INTO account (`name`,`cash`)

VALUES('A',200000),('B',1000000)

-- 转账实现

SET autocommit = 0; -- 关闭自动提交

START TRANSACTION; -- 开始一个事务,标记事务的起始点

UPDATE account SET cash=cash-500 WHERE `name`='A';

UPDATE account SET cash=cash+500 WHERE `name`='B';

COMMIT; -- 提交事务

# rollback;

SET autocommit = 1; -- 恢复自动提交

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

3事务实现方式-MVCC

1什么是MVCC

MVCC是mysql的的多版本并发控制即multi-Version Concurrency Controller，mysql的innodb引擎支持MVVC。MVCC是为了实现事务的隔离性，通过版本号，避免同一数据在不同事务间的竞争，你可以把它当成基于多版本号的一种乐观锁。当然，这种乐观锁只在事务级别为RR（可重复读）和RC（读提交）生效。MVCC最大的好处，相信也是耳熟能详：读不加锁，读写不冲突，极大的增加了系统的并发性能。

2MVCC的实现机制

InnoDB在每行数据都增加两个隐藏字段，一个记录创建的版本号，一个记录删除的版本号。

在多版本并发控制中，为了保证数据 *** 作在多线程过程中，保证事务隔离的机制，降低锁竞争的压力，保证较高的并发量。在每开启一个事务时，会生成一个事务的版本号，被 *** 作的数据会生成一条新的数据行（临时），但是在提交前对其他事务是不可见的；对于数据的更新（包括增删改） *** 作成功，会将这个版本号更新到数据的行中；事务提交成功，新的版本号也就更新到了此数据行中。这样保证了每个事务 *** 作的数据，都是互不影响的，也不存在锁的问题。

3MVCC下的CRUD

SELECT：

当隔离级别是REPEATABLE READ时select *** 作，InnoDB每行数据来保证它符合两个条件：

1 事务的版本号 大于等于 创建行版本号

　 2 行数据的删除版本 未定义 或者大于 事务版本号

　 行创建版本号 事务版本号 行删除版本号

INSERT：

InnoDB为这个新行 记录 当前的系统版本号。

DELETE：

InnoDB将当前的系统版本号 设置为 这一行的删除版本号。

UPDATE：

InnoDB会写一个这行数据的新拷贝，这个拷贝的版本为 当前的系统版本号。它同时也会将这个版本号 写到 旧行的删除版本里。

————————————————

版权声明：本文为CSDN博主「@Autowire」的原创文章，遵循CC 40 BY-SA版权协议，转载请附上原文出处链接及本声明。

原文链接：>

以上就是关于谁知道数据库的几大范式全部的内容，包括:谁知道数据库的几大范式、说MIDAS“设计用数值截面”无法进行RC设计、SQL 数据库的若干问题等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！