跟前端一起来学数据库系列(1)

随着公司的业务发展,前端已经不满足于只是做切图仔的工作,前端天生的优势在于其业务无关性,但前端人的劣势也恰恰是业务无关性。所以,前端需要了解业务逻辑,了解的最好途径就是去写业务逻辑,要写业务逻辑就得首先过了数据库这一关,鉴于前端组员对于数据库缺乏经验,而我在做前端之前做过一阵子的后端,所以组织上研究决定,让我给组员们分享一下数据库方面的知识。

这次分享分为三个部分,第一部分讲怎样设计一个数据库表,第二部分讲一些基本SQL语句,第三部分讲数据库使用技巧(索引,事物务等)。

由于这个分享是面向前端组员的所以讲的会比较浅显,再加上我好久不写后端了并且水平有限,文中难免出现错误和不足, 如果发现了可以告诉我我将进行订正:)。

闲话不多说接下来进入第一部分,怎样设计一个数据库表。俗话说好的设计是成功的一半,好的设计可以避免后期频繁改动,可以最大限度的避免数据冗余,甚至某些情况下还可以提高性能。所以我们在建立数据库表之前一定要花时间把结构给设计好。

首先我们先要知道一些数据库方面的基本概念
  • 数据库: 逻辑上相关的可共享的数据(以及数据的描述)的集合
  • 数据库管理系统(DBMS): 能够让用户定义、创建和维护数据库以及控制对数据库的访问的软件系统
  • 应用程序: 一个通过向DBMS发送合适的请求(通常是SQL语句)与数据库交互的计算机应用程序
  • 视图: 一个”虚拟的表”,它不实际存在于数据库中,由DBMS从所涉及的基本表中产生

再来了解下关系数据结构术语
  • 关系:具有列和行的表
  • 属性:关系中被命名的列
  • 域:一个或多个属性的取值范围
  • 元组:关系中的一行记录
  • 关系数据库:规范化的表的集合

接着还需要知道关系表的一些属性
  • 数据库中每个表都有区别于其它表的名称
  • 表中的每个单元恰好只包含一个值
  • 每个列有不同的名字
  • 一个列的值来自相同的域
  • 列的顺序不重要
  • 每个记录都是不同的没有重复记录
  • 理论上来说,记录的顺序并不重要

稍微了解一下什么是关系键
  • 超键(Superkey):一个列或者列集,唯一的标识了表中的一条记录
  • 候选键(Candidate Key) :仅包含唯一标识实体所必须的最小数量的列的超键
  • 主键(Primary Key):唯一标识表中记录的候选键
  • 外键(Foreign Key):一个表中的一个列或多个列的集合,这些列匹配某些其它(也可能是同一个)表中的候选键

关系数据库由一个或多个表组成。描述关系数据库的惯例通常是给定每张表的名称,表名后面跟着列名,列名在圆括号中。通常,主键用下划线表示。如下图:

此处输入图片的描述


关于关系的一些须知
  • 关系:实体之间具有某种含义的关联
  • 关系的度:在关系中参与的实体的数目
  • 递归关系:在不同的角色中多次具有相同实体参与的关系
  • 属性:实体或关系的性质
  • 关系的种类:一对一、一对多、多对多等 关系的表示如下图: 此处输入图片的描述 此处输入图片的描述

关系完整性的保证
  • 空值:表示一个列的值目前还不知道或者对于当前记录来说还不能使用
  • 实体完整性:在一个基本表中,主键列的取值不能为空
  • 参照完整性:如果表中存在外键,则外键必须与主表中的某些记录的候选键值相同,或者外键的值必须为全部空
  • 业务规则:定义或约束组织的某些方面的规则

设计关系数据库时,遵从不同的规范要求,设计出合理的关系型数据库,这些不同的规范要求被称为不同的范式,各种范式呈递次规范,越高的范式数据库冗余越小。

目前关系数据库有六种范式:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)和第五范式(5NF,又称完美范式)。满足最低要求的范式是第一范式(1NF)。在第一范式的基础上进一步满足更多规范要求的称为第二范式(2NF),其余范式以次类推。一般说来,数据库只需满足第三范式(3NF)就行了

第一范式:每个列和记录包含一个而且只包含一个值的表(关系中的每个属性都不可再分) 1NF是所有关系型数据库的最基本要求, 也就是说,只要在关系数据库中已经存在的数据表,一定是符合1NF的。如图把一个不符合第一范式的表转换为符合第一范式的表:
此处输入图片的描述 此处输入图片的描述

第二范式:对于一个符合第一范式的表,消除了非主键对于主键的部分函数依赖。如图把一个不符合第二范式的表转换为符合第二范式的表: 此处输入图片的描述 此处输入图片的描述

第三范式:对于一个符合第一范式的表,消除了非主键对于主键的传递依赖。如图把一个不符合第三范式的表转换为符合第三范式的表: 此处输入图片的描述 此处输入图片的描述