数据的性能

1.数据的关系视图

数据库是现实状况的模型。

关系模型：不是因为不同表之间建立关系，额日式因为表内不同字段之间存在关系。表描述了关系。不同字段联系在一起的方式定义了关系。

关系模型对的一致性：只要遵守关系理论，基于数据库的任何查询结果与原始数据具有同样的有效性。

关系理论：关系不包含重复数据，且记录之间没有顺序。

2.规范化

规范化---满足第三范式。

（1）第一范式

原子性：表中的属性都是原子性，不可拆分。

（2）第二范式  表中的所有列，都必须依赖主键。（一个表只描述一个事件）

消除部分依赖

（3）第三范式  表中的每一列都要与主键直接相关，而不是间接相关（表中的每一列只能依赖于主键）

消除传递依赖

 第一范式（1NF）：强调的是列的原子性，即列不能够再分成其他几列。 
考虑这样一个表：【联系人】（姓名，性别，电话） 
如果在实际场景中，一个联系人有家庭电话和公司电话，那么这种表结构设计就没有达到 1NF。要符合 1NF 我们只需把列（电话）拆分，即：【联系人】（姓名，性别，家庭电话，公司电话）。
 第二范式（2NF）：首先是 1NF，另外包含两部分内容，一是表必须有一个主键；二是没有包含在主键中的列必须完全依赖于主键，而不能只依赖于主键的一部分。 
考虑一个订单明细表：【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，另外非主键列必须直接依赖于主键，不能存在传递依赖。即不能存在：非主键列 A 依赖于非主键列 B，非主键列 B 依赖于主键的情况。
考虑一个订单表【Order】（OrderID，OrderDate，CustomerID，CustomerName，CustomerAddr，CustomerCity）主键是（OrderID）。
其中 OrderDate，CustomerID，CustomerName，CustomerAddr，CustomerCity 等非主键列都完全依赖于主键（OrderID），所以符合 2NF。不过问题是 CustomerName，CustomerAddr，CustomerCity 直接依赖的是 CustomerID（非主键列），而不是直接依赖于主键，它是通过传递才依赖于主键，所以不符合 3NF。
通过拆分【Order】为【Order】（OrderID，OrderDate，CustomerID）和【Customer】（CustomerID，CustomerName，CustomerAddr，CustomerCity）从而达到 3NF。

3NF:可应对需求变更  是数据重复降至最少。

 

关系模型的完备性是以二值逻辑为基础的，记录要么存在、要么不存在。where子句中的条件必须明确，但任何中间状态或空值都是不确定的。

包含空值的模型数据三值逻辑（真，假，不确定），将他转换成结果集要求得二值逻辑非常危险。

color字段包含RED、GREEN、BLACK等值

where color not in ('blue','black',null)不会反悔任何结果，因为SQL引擎无法确定null代表什么--既可能代表red也可能代表green

where color in ('blue',black',null) 只返回颜色为balck的记录。

子类型

子类型：不同于主从关系。

表中有些字段出现了空值，表明需要引入子类型。

公司有不同类型的员工：固定工，合同工  相同特性：姓名，出生年份，部门，房间，电话

独有特性：固定工到职日期与薪水  合同工的费用与薪水

employee共有属性  permanent 固定工 contract 合同工  

固定工和合同工从employee表继承相应特性。