2020/01/07 01-数据库原理

存放数据早期用文件，管理起来比较麻烦，不安全
后期出现的专业数据库软件，什么字段放什么数据，什么格式放在磁盘上，我们只需要和数据库交互即可
专门的数据管理系统是DBMS，比如mysql，db2，sql server
可以保证并发，而且保证一致性
DBMS数据库管理系统，mysql，oracle
mysql是一个程序，将来生成的数据通过mysl来进行组织和管理
存储引擎，存储方式（就是mysql存放数据的一种格式）不同的数据库，在硬盘存放的格式是不一样的
关系型数据库可以针对某一列，来指定用户是否能访问，能修改
数据库大部分都有日志功能，可以用日志恢复，如果意外停电等其他的情况下
保证数据正确性。可以加一些约束，来限定数据库用户写入数据的时候一些合理性，
比如年龄，数据库可以限定一个范围

用户只需要程序员开发友好界面去间接操作数据库，不需要直接使用专业的数据库软件

大部分数据都是存在磁盘上的，即时断电也保留数据
一小部分是把数据存放在内存中，断电就没有
有些数据库确实是依靠内存存放的比如，memacached，纯粹基于内存形式，性能超好
RAW文件系统，没有文件系统的磁盘空间（就是个裸磁盘）就是0101二进制
MBR的前面512字节就是010101
oracle是支持把数据放在非文件系统的磁盘上的，性能好，文件不存在，要拷贝文件也只能用DD命令，失去了可管理性
早期是网状数据库

层次的应对有重复的数据，可能会有问题
网状的拓补结构比较能表达关系能体现现实中的关系
，但是数据越来越多，管理起来比较错综复杂
主键是作用在某个字段上，字段上每一行的记录，在这个字段上是不重复的
避免了重复数据。
awk也提到行
record记录，行 row


这个属性是关联在表中的某个列上的，pk
作用在某个字段以后，表明这个字段的所有记录是不能重复的
通常数据库规范，都需要加主键

RDBMS是关系型数据库的意思
mysql只是大的类别，因为是开源的，所以里面进行二次开发还有分支
关系型数据库都符合国际标准，都是差不多的
postgresql被红帽收购了，取名enterprisesql，ansible也被红帽收购了（号称很强，但是没不普及，类似resizefs。betuefs）
最重要的一点是支持事务 transaction。在数据库执行操作的适合，允许多个动作
这个多个动作如果以事务方式执行，必须作为一个整体对待
10的80次方，宇宙的原子个数
事务都有 ACID特性
原子性，要么任务都做，要么都不做，不可分割（认为园子不可分割
ATM机吐钱银行不会损失，ATM的厂家有押金在银行里，损失的是ATM厂家

还有一些非关系数据库 no only sql

第一仍然是oracle，mongodb存放的是文档管理数据库，session一般放在redis
阿里去IOE
指 IBM p 系列小型机，操作系统是 AIX（IBM 专有的 Unix 系统）；非常贵
oracle
emc存储
实体模型图 ER图
entity实体，一条记录，一般用矩形方框
员工编号，和上司编号这里面是有联系的
表和表之间的关系，有可能
一对一
一对多（一个员工在一个部门里，一个部门有多个员工）
多对多（学员信息，学员报名多个课程，课程会有多个学员学习）
emp员工表，department 部门表
利用外键把一对多的关系表现出来了

学员信息，课程信息，如果两边都写课程，就有可能学生在填信息的录入错误*一对多，员工和部门，有多个部门，部门里有多个员工

主键是确保每个表里记录都是唯一的，主键和外键结合起来 就形成了一对多的关系，员工表的部门ID依赖部门表的ID，被依赖的表一般称为主键表，员工表称为外检表
外键表表示和其他表的依赖属性
利用主外键可以把两张表的一对多的关系表达出来
多对多的关系
保证这两个表是多对多的关系，学员信息表，不写课程名字
这样的结果就是不会重复存放，极大的节约存储空间
带来的缺点就是，逻辑性比较复杂
因为你要查a同学报的课程名字是什么，就涉及到多表关联

多对多，就是构建第三个表，第三个表分别跟前面两张表构建一对多的关系

mysql的性能始终是瓶颈，外键可以依赖程序能实现的就用程序实现，数据库最好就只存放数据

数据的结构，数据的操作，数据的约束，统称三要素

完整性，一部分也可以依靠主键，唯一键uk，unique
但是在一张表中，主键只有一个，主键是唯一的，而外键可以有好几个
唯一键和主键还有点区别，就是允许为空
主键不允许为空

域的完整性，就是限制字段的完整性，比如字段的值范围

就是外键，两个表两个字段之间的关联

规划一个数据库
规范数据库就是尽量让你的数据库在保存的时候，不要存重复的数据，比较节约我们的磁盘空间

规范的模式叫范式，数据库里要让你的数据更加规范通过一些范式来实现，所谓范式就是一些规则，只要符合范式，那你的数据库存放数据就更加规范，而且数据库的冗余数据就更加少，而且这些范式是递归规范的
（第二范式依赖第一范式，第三依赖第二）
范式越高越严格，数据库冗余度越小，目前主流的有很多范式
如果规范的多，那就使用起来也就不怎么灵活，逻辑性就比较复杂
主流的范式，只要遵守三大范式就可以了
1NF
2NF
3NF

如果这么设计，学生有可能报C1,C2,C3中的某一个字段，有些不使用，这样就违反了第一范式。，因为第一范式规定不要出现同一类型的列，C1,C2,C3都是课程或者这个字段存里好几个值也是违反了第一范式
可以这么写，放课程ID
一般第一范式必须要遵守，不然就不叫关系型数据库了
面试很少让你实际操作，面试只要自信，能说出来，会表达很重要

如果属性不完全依赖于主键，就违反了第二范式了，
假设有个字段存放员工姓名，性别，城市，城市区号，有的时候名字会重复，可以复合主键（在一张表里主键只有一个）
。
城市和城市区号并不完全依赖于姓名，就违反了第二范式，
区号ID只关注city，只依赖部分主键，就违反了第二范式解决办法，城市的区号是依赖于城市的，就需要单独设计一张表
但是你这样就增加了查询难度，所以有时候就需要违反第三范式，不跨表查询，在逻辑上简单，速度上也变快了，有时候追求高性能就是违反范式的
带来查询上的困难，甚至影响性能

设置成一个员工id，就违反了第三范式,区号是非主属性，依赖于另外一个非主属性，违反第三范式城市名称和城市编号，产生了依赖关系，就违反了第三范式，解决放啊就是把城市另外建一张表，这样用编号代替文字就节省了很多空间