数据库范式

本章内容 数据库管理系统 关系型数据库 简易数据规划流程 数据库的正规化分析 MySQL基本概念 数据模型 MariaDB初识 其实MySQL和MariaDB是同一个人开发的，所以在功能和用法和，几乎一致。自从MySQL被ORICAL收购后,开源的MySQL就成为了商业化的产品，以后的趋势是去IOE,这个概念是由阿里巴巴 2008 年提出,所谓的“IOE”,指的是以 IBM 、Oracle、EMC 为代表的小型机、 集中式数据库和高端存储所组成的 IT 技术架构。 所以下面所讲的MySQL其实就是MariaDB，实际使用的软件是MariaDB。 数据库的发展史 萌芽阶段：文件系统 使用磁盘文件来存储数据 初级阶段：第一代数据库 出现了网状模型、层次模型的数据库 中级阶段：第二代数据库 关系型数据库和结构化查询语言 高级阶段：新一代数据库 “关系-对象”型数据库 数据库管理系统 数据库是数据的汇集，它以一定的组织形式存于存储介质上。 DBMS 是管理数据库的系统软件，它实现数据库系统的各种功能。是数据库系统的核心。 DBA 负责数据库的规划、设计、协调、维护和管理等工作 数据库管理系统的优点 相互关联的数据的集合 较少的数据冗余 程序与数据相互独立 保证数据的安全、可靠 最中大限度地保证数据的正确性 数据可以并发使用并能同时保证一致性 文件管理系统的缺点 编写应用程序不方便

百度百科给的定义： 关系型数据库，是指采用了 关系模型 来组织数据的数据库，其以行和列的形式存储数据，以便于用户理解，关系型数据库这一系列的行和列被称为表，一组表组成了 数据库 。用户通过查询来检索数据库中的数据，而查询是一个用于限定数据库中某些区域的执行代码。关系模型可以简单理解为二维表格模型，而一个关系型数据库就是由二维表及其之间的关系组成的一个数据组织。 [1] 通俗易懂的定义： 关系型，当然就是关于这个表与表之间的关系，相互依赖关系，来减少冗余，比如：主外键关系 为了复合设计数据库所谓的三范式，而这样命名的。对于大数据量是很有必要的，一个字符串倒没有多大，但是 海量数据 的话，则很占用硬盘空间，不利于部署转移。 数据库三范式了解： 第一范式： http://baike.baidu.com/view/176725.htm 第二范式： http://baike.baidu.com/view/176736.htm 第三范式： http://baike.baidu.com/view/176738.htm 为了建立冗余较小、结构合理的数据库，设计数据库时必须遵循一定的规则。在关系型数据库中这种规则就称为范式。范式是符合某一种设计要求的总结。要想设计一个结构合理的关系型数据库，必须满足一定的范式。 来源： https://www.cnblogs.com/xibuhaohao/p

范式的定义 关系型数据库中的关系是需要满足一定条件的，满足这些不同程度的规范化就叫做范式。 范式按照规范化程度从低到高排序为第一范式，第二范式，第三范式，BC范式，第四范式，第五范式。 前导知识 函数依赖 R(U)是属性集U的关系模型，X，Y是U的一个子集，对于R(U)中的任一个关系r，不可能存在两个元组在X上属性值相同，而在Y上属性值不同。则称X函数确定Y，或Y函数依赖X。 说人话：U是表(可能不止一个表，可以是有关系的多个表)的所有列，X，Y分别是这些属性列的一个子集，也就是若干个属性， 对于所有在X这些属性上的值一样的行，在Y上的属性上也必须一样 ，满足这样条件的这若干个属性 X和Y叫称其函数依赖。 X相同则Y必须相同，但 X不同Y可以相同，也可以不同 。 如果Y是X的子集，就叫 平凡的函数依赖 ，一般不考虑这种，因为就是废话，X整个都相同，子集肯定相同。 如果Y不是X的子集，叫做 非平凡的函数依赖 。 如果Y函数依赖X，那么X称为决定因素。 如果Y函数依赖X，但不依赖X的任何一个真子集，也就是X是极小的，那就称 Y完全函数依赖X ，否则称 Y部分函数依赖X 。 如果X决定Y，Y决定Z，且 Y不决定X ，那么称 Z对X传递函数依赖 。 码(键) U是属性全集，K是U的子集，若U完全函数依赖K，则称K为 候选码 ，候选码若有多个，任意选择一个都可作为 主码 ，若U部分函数依赖K

MySql学习笔记（基础） 学习笔记 数据库基础 SQL的基本操作 基本操作：CRUD（增删改查） 更新数据库 删除数据库 表操作 修改数据表 查看数据 更新数据 删除数据 中文数据问题 校对集问题 数据类型（列类型） 字段属性 范式： 蠕虫复制 查询数据 连接查询 学习笔记 数据库基础 1.什么是数据库？ 数据库：database，存储数据的仓库 数据库：高效的存储和处理数据的介质（介质主要是两种：磁盘和内存） 2.数据库的分类？ 数据库基于存储介质的不同：进行了分类，分为两大类：关系型数据库（SQL）和非关系型数据库（NoSQL:Not Noly SQL,不是关系型的数据库都叫做非关系型数据库） 3.不同的数据库阵营中的产品有哪些？ 关系型数据库： 大型：Oracle，DB2 中型：SQL-SERVER，MySql等 小型：access等 非关系型数据库： memcached，mongodb，redis（同步到磁盘） 4.两种数据库阵营的区别？ 关系型数据库：安全（保存磁盘基本不可能丢失）容易理解，比较浪费空间（二维表） 非关系型数据库：效率高，不安全（断电会丢失） 关系型数据库 1.什么是关系型数据库？ 关系型数据库：是一种建立在关系模型（数学模型）上的数据库。 关系模型：一种所谓建立在关系上的模型，关系模型包含三个方面。 数据结构：数据存储的问题，二维表（有行和列）

1. 多表之间的关系 1. 分类： 1. 一对一： * 如：人和身份证 * 分析：一个人只有一个身份证，一个身份证只能对应一个人 2. 一对多(多对一)： * 如：部门和员工 * 分析：一个部门有多个员工，一个员工只能对应一个部门 3. 多对多： * 如：学生和课程 * 分析：一个学生可以选择很多门课程，一个课程也可以被很多学生选择 2. 实现关系： 1. 一对多(多对一)： * 如：部门和员工 * 实现方式：在多的一方建立外键，指向一的一方的主键。 2. 多对多： * 如：学生和课程 * 实现方式：多对多关系实现需要借助第三张中间表。中间表至少包含两个字段，这两个字段作为第三张表的外键，分别指向两张表的主键 3. 一对一： * 如：人和身份证 * 实现方式：一对一关系实现，可以在任意一方添加唯一外键指向另一方的主键。 3. 案例 -- 创建旅游线路分类表 tab_category -- cid 旅游线路分类主键，自动增长 -- cname 旅游线路分类名称非空，唯一，字符串 100 CREATE TABLE tab_category ( cid INT PRIMARY KEY AUTO_INCREMENT, cname VARCHAR(100) NOT NULL UNIQUE ); -- 创建旅游线路表 tab_route /* rid 旅游线路主键，自动增长 rname

第一范式：字段具有原子性，字段不可拆分。比如：海南省海口市。可以拆分成1、海南省，2、海口市。 第二范式：消除 非主键字段 对 主键字段 的部分函数依赖， 非主键字段 完全依赖于 主键字段 。 第三范式：消除 非主键字段 对 主键字段 的传递依赖， 非主键字段 唯一依赖于 主键字段 而不依赖于其他字段。 自创一句话记忆：原子完全唯一依赖。（原完唯依赖） 来源： https://www.cnblogs.com/oldpub-blog/p/11881364.html

版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。 本文链接： https://blog.csdn.net/devcloud/article/details/99317716 插曲 最近，一个远房亲戚的小表弟准备选修专业 找到我问： 1 "哥，现在学数据库有没有前途阿?" 2 3 "当然有啊，前途大大的呢" 4 "那我现在开始学数据库，需要先从什么开始呢?" 5 6 "学课程的话，先了解下数据库三范式，SQL这些吧" 7 8 "SQL我大概知道，数据库三范式是什么？" 9 "阿...三范式就是表的主键...唯一性那些东西吧，...嗯，应该就是那些" 10 11 "什么是主键？" 12 13 "额.....表弟你不要再问了啦，好好去百度一下行不。" 14 15 "噢...." 挂完电话，我舒了口气，由于差点暴露自己已经不记得三范式了这个不争的事实，我悄悄打开了谷歌.... 数据库的这个三范式的概念，相信大多数人都不会陌生，从懵懵懂懂的大学时代就已经普及到教材了（没记错的话应该在数据库系统概论这本教材里）。 还记得那会刚开始找实习的时候，由于自己本事太小，连简历都不知道怎么写好，尤其是擅长技术的部分更是一片空白。 于是乎会找来隔壁几个学霸的简历来做参考，那会儿大家的简历上都会赫赫写着： 熟练掌握数据库三范式，精通数据库系统开发语言。

1.第一范式（1NF）：字段具有原子性,不可再分。(所有关系型数据库系统都满足第一范式数据库表中的字段都是单一属性的，不可再分) 2.第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。要求数据库表中的每个实例或行必须可以被惟一地区分。通常需要为表加上一个列，以存储各个实例的惟一标识。这个惟一属性列被称为主关键字或主键。 3.满足第三范式（3NF）必须先满足第二范式（2NF）。简而言之，第三范式（3NF）要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。 >所以第三范式具有如下特征： >>1. 每一列只有一个值 >>2. 每一行都能区分。 >>3. 每一个表都不包含其他表已经包含的非主关键字信息。 来源： https://www.cnblogs.com/fightingcode/p/11833775.html

1NF: 　　属性的原子性（分到不可再分） 2NF: 　　实体属性完全依赖于主关键字（表必须有一个主键，二是没有包含在主键中的列必须完全依赖于主键，而不能只依赖于主键的一部分） 　　　　eg:考虑一个订单明细表：【OrderDetail】（OrderID，ProductID，UnitPrice，Discount，Quantity，ProductName）。 因为我们知道在一个订单中可以订购多种产品，所以单单一个 OrderID 是不足以成为主键的，主键应该是（OrderID，ProductID）。显而易见 Discount（折扣），Quantity（数量）完全依赖（取决）于主键（OderID，ProductID），而 UnitPrice，ProductName 只依赖于 ProductID。所以 OrderDetail 表不符合 2NF。不符合 2NF 的设计容易产生冗余数据。 　　　　可以把【OrderDetail】表拆分为【OrderDetail】（OrderID，ProductID，Discount，Quantity）和【Product】（ProductID，UnitPrice，ProductName）来消除原订单表中UnitPrice，ProductName多次重复的情况。 　　 3NF: 　　当2NF消除了非属性对码的传递函数依赖（传递依赖），则称为3NF。即不能存在

三大范式 第一范式：无重复的列 第二范式：属性完全依赖于主键 第三范式：属性不能传递依赖其他非主属性 范式的作用是避免数据冗余（数据重复）。 范式的问题： 按照范式设计出来的表在数据冗余的问题虽然得到解决，但是会生成许多表，导致了表数量的复杂性，其二，查询数据的时候，多表查询的时间远远高于单表查询的时间。 反范式 范式的目的是减小数据冗余，而反范式指的是在一定程度上允许数据冗余，目的是加快数据操作。 对比 范式与反范式是一场时间和空间的较量，满足范式节省空间，满足反范式加快操作速度。 在满足范式设计数据库的前提条件下，再根据具体的业务需求完成反范式的设计。 来源： https://www.cnblogs.com/noneplus/p/11769619.html