mysql 学习笔记（一） 数据库常识复习

数据库设计中出现的问题：

一、数据库概念和术语

（一） 实体和关系： 员工和部门的例子：实体就是我们现实中存在的个体（员工、部门），关系就是实体直接存在的联系， 员工work for 部门， works for 就是一种关系。 关系这里也有种类：多对一、一对一。

（二） 关系/表：

这里就是一个公司中的员工表，这里反映了就是一种关系（实体和实体）一般我们在数据库中把关系说成表（三） Columns or Attributes （列/属性）

你可以看到这个是员工表：ID 是它的ID，name 也是员工的name 所以所有的列都是能反映这个员工（实体） 的情况的-----属性。

（四） Rows, Records, Tuples （行、记录、元组）

这三个概念在数据库中是同一的，反映一个实体的情况，一行就是一个"个体".

（五） keys（键）

这个东西在数据库中非常重要！它存在的意义就是通过它可以区别一行与一行---一个个体和一个个体的有什么区别。  一般来说我们所谓的key 就是最小的标示-----ID，当然你可以说四个（id，name ，job，did）。

还有两个概念： 

A 主键：employeeID  ，而不选择name ，就是可能有两个人名字一样，而 eID永远唯一。

B 外键：就是其它表中的primary key ，从而实现两个实体之间 能搭建一个表（关系）。

函数依赖性： function dependency ,如上边表A——> B ，如果employeeID 没有了那么其他name等等也没有存在的价值了。

（六） Schemas （框架）：就是没有数据的的数据库，就是整个框架，所有的结构。

二、数据库设计原则

2 个最重要的东西： A 我们要存储哪些信息，需要哪些实体 B 我们要问哪些问题（查询哪些内容）

（一） 数据冗余 VS  丢失数据

怎么定义冗余： 就是不同的行中的相同数据项目 尽量的少！但前提是你不能丢掉信息的。

冗余：employeeDepartment(employeeID, name, job, departmentID, departmentName)

Research and Development 重复了很多次。

我们完全可以把这张表拆分为两张：

employee(employeeID, name, job, departmentID)

department(departmentID, name)

（二） Anomalies 反常

一个不好的设计（如上图）插入、删除、更新反常

尽量减少空值 ，如果有100 员工，1个员工有特殊属性，你增加了这个属性，而其他99 就要NULL ，这样不好。

三、标准化 （数据库中出名的几大范式）

（一）1NF

原则就是每个个体必须是原子，skills 就不是！ C,Perl ,Jave ：

但是问题你也看到了，有很多的冗余数据，所以你可以增加一张表employeeskills 

 

有人就会问了：你怎么知道这么做呢？  答案有两个 first 经验！  Second，就是你还用这张大表来继续我们的规范化过程！ 建议选择第二种。

（二） 2NF

all attributes that are not part of the primary key are fully functionally dependent on the primary key. 解释这个英文定义：所有不是主键一部分的属性必须完全依赖于主键。

看3.5 表进行阐述：

3.5 明显的是符合1NF，这时候你找到这个表中的主键：employeeID+skill  ====>

[ employeeID ,skill ] -->{ name ,job ,departmentID} ,我们分析这个功能依赖性（function dependency） employee -->{ name ,job ,departmentID},而skill 不能决定这三个属性。 综述：不符合2NF。 

怎么做才符合？ 把功能性得提到一张表里，剩余的放到另外一张表里。形成了3.6 两张表，不是猜得呀。

（三）3NF

2NF告诉我们属性必须依靠于key 中的每一部分，3NF说明属性除了键不能再依靠表中的其他属性。

这个符合2NF：employeeID-->{ name,job,departmentID,departmentName } ,而且就有一个主键！

仔细分析这个表中的关系，找出其他function dependency： departmentID ---> departmentName

其实我们现在明白 employeeID ——> departmentName 不是直接决定是传递性决定：

employeeID——> departmentID , departmentID ---> departmentName  。不符合3NF .把其他function dependency 提出来。

employee(employeeID, name, job, departmentID)

department(departmentID, departmentName)  形成两张表。

（四） BCNF： 一张表中的其他属性必须功能性依赖一个super key

附： 英文总结

Summary

Concepts

Entities are things, and relationships are the links between them.

Relations or tables hold a set of data in tabular form.

Columns belonging to tables describe the attributes that each data item possesses.

Rows in tables hold data items with values for each column in a table.

Keys are used to identify a single row.

Functional dependencies identify which attributes determine the values of other attributes.

Schemas are the blueprints for a database.

Design Principles

Minimize redundancy without losing data.

Insertion, deletion, and update anomalies are problems that occur when trying to insert, delete, or update data in a table with a flawed structure.

Avoid designs that will lead to large quantities of null values.

Normalization

Normalization is a formal process for improving database design.

First normal form (1NF) means atomic column or attribute values.

Second normal form (2NF) means that all attributes outside the key must depend on the whole key.

Third normal form (3NF) means no transitive dependencies.

Boyce-Codd normal form (BCNF) means that all attributes must be functionally determined by a superkey.