mysql 基础
mysql 基础
数据的时代
随着时代的发展与进步,互联网越来越进入我们的生活,而我们所要保存的数据也越来越多,在这样一个数据的时代,数据的存放面临着这些个问题。
- 涉及存放的数据量越来越大
- 数据不随程序的结束而消失
- 数据被多个应用程序共享
- 大数据时代,通过分析海量数据从中挖掘我们需要的有效信息。
数据库的发展史
萌芽阶段:文件系统
使用磁盘文件来存储数据。直接将数据通过一定的编码格式,存储在文本中。
初级阶段:第一代数据库
出现了网状模型、层次模型的数据库
中级阶段:第二代数据库
关系型数据库和结构化查询语言
高级阶段:新一代数据库
“关系-对象”型数据库
优缺点
文件管理系统的缺点:
- 编写应用程序不方便
- 数据冗余不可避免
- 应用程序依赖性
- 不支持对文件的并发访问
- 数据间联系弱
- 难以按用户视图表示数据
- 无安全控制功能
数据库管理系统的优点
- 相互关联的数据的集合
- 较少的数据冗余
- 程序与数据相互独立
- 保证数据的安全、可靠
- 最大限度地保证数据的正确性
- 数据可以并发使用并能同时保证一致性
所谓数据库,就等于数据的集合,只要能把数据存起来,都可以称为数据库。
数据库管理系统
数据库是数据的汇集,它以一定的组织形式存于存储介质上。
DBMS是管理数据库的系统软件,它实现数据库系统的各种功能,是数据库系统的核心。
DBA:负责数据库的规划、设计、协调、维护和管理等工作。
应用程序指以数据库为基础的应用程序。
DBMS 数据库管理系统,mysql sql server 都属于数据库管理系统
数据库系统的架构
单机架构
数据库放在本地客户端,只能存放该数据库的机器访问,类似于用友,金蝶等财务软件,access数据库等
大型主机/终端架构
1个主机,带多个终端,终端通过线缆连接到主机,操控主机上的数据库
主从式架构C/S
由于是一台主机,多台服务器,通常会带来瓶颈,比如同时连接主机的用户过多,造成服务器处理数据缓慢
NO SQL
not only sql 不仅仅只是关系型数据库,还可能是非关系型数据库
都属于非关系型数据库
memcached redis
mongodb
关系型数据库名词解释
实体:现实世界中客观存在并可以被区别的事物。比如“一个学生”、“一本书”、“一门课”等等。值得强调的是这里所说的“事物”不仅仅是看得见摸得着的“东西”,它也可以是虚拟的,比如说“老师与学校的关系”。
属性:教科书上解释为:“实体所具有的某一特性”,由此可见,属性一开始是个逻辑概念,比如说,“性别”是“人”的一个属性。在关系数据库中,属性又是个物理概念,属性可以看作是“表的一列”。
元组:表中的一行就是一个元组。
分量:元组的某个属性值。在一个关系数据库中,它是一个操作原子,即关系数据库在做任何操作的时候,属性是“不可分的”。否则就不是关系数据库了。
码:表中可以唯一确定一个元组的某个属性(或者属性组),如果这样的码有不止一个,那么大家都叫候选码,我们从候选码中挑一个出来做老大,它就叫主码。
全码:如果一个码包含了所有的属性,这个码就是全码。
主属性:一个属性只要在任何一个候选码中出现过,这个属性就是主属性。
非主属性:与上面相反,没有在任何候选码中出现过,这个属性就是非主属性。
外码:一个属性(或属性组),它不是码,但是它别的表的码,它就是外码。
关系: 表示横行纵列的二维表,表中的行,列次序并不重要
行row:表中的每一行,又称为一条记录
列column:表中的每一列,称为属性,字段
主键:用于唯一确认一个记录的字段 不可重复. 必须有值且不能为空
域domain:属性的取值范围,例如设置性别字段,只能为“男” 或者 “女”
事务:多个操作被当作一个整体来对待,要么都做,要么就都不做。(假设如果事务有,1-5 ,做到4的时候出错了,那么数据库会回滚所做的操作。并且不会继续执行。)
事务正确执行的四个基本要素:ACID
- A:原子性 :整个事务中的所有操作,要么全部完成,要么全部不完成,不可能停滞在中间某个环节。事务在执行过程中发生错误,会被回滚(Rollback)到事务开始前的状态,就像这个事务从来没有执行过一样。
- C:一致性:事务可以封装状态改变,但是事务必须始终保持处于一致的状态。比如ABCD四个账户,每个余额是100,总额是400,那么他们之间无论进行多少次互相转账的操作,总额也必须还是400。
- I:隔离性:同一时间仅有一个请求用于同一数据,多个表之间操作不相互影响,不应该看到脏数据
- D:持久性:在事务完成以后,该事务对数据库所作的更改便持久的保存在数据库之中,并不会被回滚。
数据规划流程及范式
构建一个数据库之前,需要先进行数据规划。
第一阶段:收集数据,得到字段
- 收集必要且完整的数据项
- 转换成数据表的字段
第二阶段:把字段分类,归入表,建立表的关联
- 关联:表和表间的关系
- 分割数据表并建立关联的优点
- 节省空间
- 减少输入错误
- 方便数据修改
第三阶段:
- 规范化数据库
范式
设计关系数据库时,遵从不同的规范要求,设计出合理的关系型数据库,这些不同的规范要求被称为不同范式,各种范式呈递次规范,越高的范式数据库冗余越小。
目前关系数据库有六种范式:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴德斯科范式(BCNF)、第四范式(4NF)和第五范式(5NF,又称完美范式)。满足最低要求的范式是第一范式(1NF)。在第一范式的基础上进一步满足更多规范要求的称为第二范式(2NF),其余范式以次类推。一般说来,数据库只需满足第三范式(3NF)即可。
第一范式
无重复的列,每一列都是不可分割的基本数据项,同一列中不能有多个值,即实体中的某个属性不能有多个值或者不能有重复的属性。除去同类型的字段,就是无重复的列。(通俗的说: 一张表中不能有任何重复的列,比如说学生与考试成绩,哪怕这一个学生,有多个成绩,也只能只写在一列中。属性不可分。)
错误
学号 | 成绩 | 考试日期 |
---|---|---|
1 | 80,88 | 2019.3.1 |
2 | 99,97 | 2019.3.2 |
正确
学号 | 成绩 | 考试日期 |
---|---|---|
1 | 80 | 2019.3.1 |
1 | 88 | 2019.3.2 |
2 | 99 | 2019.3.1 |
2 | 97 | 2019.3.2 |
第二范式
属性必须完全依赖于主键,而不是依赖其他的键,且必须符合第一范式设计原则。
第二范式(2NF):符合1NF,并且,非主属性完全依赖于码。(注意是完全依赖不能是部分依赖,设有函数依赖W→A,若存在XW,有X→A成立,那么称W→A是局部依赖,否则就称W→A是完全函数依赖)
错误设计。在这张表中,性别是依赖于主属性姓名,所在城市也是依赖于主属性姓名,然而城市ID是依赖于城市的,与一个人的姓名没有关系,所以不符合第二范式。需要拆分他们
姓名 | 男 | 所在城市 | 城市ID |
---|---|---|---|
1 | m | 1 | 101 |
1 | w | 2 | 202 |
正确设计 拆分成两张表
name | sex | city_id |
---|---|---|
1 | m | 1 |
1 | w | 2 |
city_id | city name | city num |
---|---|---|
1 | wx | 101 |
2 | s h | 202 |
第三范式
属性不依赖于其他非主属性
第三范式(3NF):符合2NF,并且,消除传递依赖(也就是每个非主属性都不传递依赖于候选键,判断传递函数依赖,指的是如果存在"A → B → C"的决定关系,则C传递函数依赖于A。)
SQL
结构化查询语言,一种数据库通用的编程语言,通常用于对数据库进行增删改查操作。
约束:constraint,表中的数据要遵守的限制
主键:一个或多个字段的组合,填入的数据必须能在本表中唯一标识本行;必须提供数据,即NOT NULL,一个表只能有一个
惟一键:一个或多个字段的组合,填入的数据必须能在本表中唯一标识本行;允许为NULL,一个表可以存在多个
外键:一个表中的某字段可填入的数据取决于另一个表的主键或唯一键已有的数据
检查:字段值在一定范围内
索引:将表中的一个或多个字段中的数据复制一份另存,并且此些需要按特定次序排序存储,相当于书的目录
索引有可能带来额外的负担,索引如果加的不好会对系统造成更坏的效果。
关系运算:
选择:挑选出符合条件的行
投影:挑选出需要的字段
连接:表间字段的关联
数据抽象
物理层,比如我们需要关注,文件应该如果按规则存放,还能加快访问效率,什么样的文件需要集中存放,什么样的文件需要分开存放
逻辑层 存储哪些类型的数据,以及数据互相之间的关联
视图层 抽取数据库中的部分内容,进行加载显示
作者: DreamDZhu
出处: https://www.cnblogs.com/ddz-linux/>
关于作者:专注Linux运维的萌新,目标:独立管理后宫三千服务器,请多多赐教!
本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出, 原文链接 如有问题, 可邮件(852749070@qq.com)咨询.
互相尊重版权,才能有更好的未来。