数据设计3范式

第一范式 

第一范式（1NF）：强调的是列的原子性，即列不能够再分成其他几列

列不可拆分

比如说 用户，电话

张三 ，186. 187.。

李四 ，186.。

张三里面存在 两个电话号码

 

这里电话 包含两种含义 既包含 手机 也包含座机

 

在业务上可以继续拆分成手机 座机

我可以设计 

用户  手机号 ，座机号

 

不过 在hive ,oracle db2也支持这种数组形式。

反过来说 有时候还是有必要的。在我工作总特殊业务场景

 

从来不是范式越高越好。

就一范式也有应用场景。

 

 

 

第二范式（2NF）：首先是 1NF，另外包含两部分内容，一是表必须有一个主键；二是没有包含在主键中的列必须完全依赖于主键，而不能只依赖于主键的一部分

 

表的字段名称包含相同的字段

二范式强调主键。通过主键定位数据。

1》“，而不能只依赖于主键的一部分” 这句是什么意思。 可能存在联合主键（A，B）有的数据依赖A，有的数据依赖B   是指这个意思。

这种情况可以吗？ 

在设计是可以 。

我们在设计数据仓库  一些字典表 可以通过 这种 依赖关系 统一管理。

还有一种情况。在数据仓库做主题的时候 人工 去添加这种依赖关系，保证模型的完整性，可以查找性。

 

2》

一是表必须有一个主键 先说中真的存在于 没有主机的数据。比如说日志表，流水表 可能设计这张表的人 从来想过主键。

 

第三范式（3NF）：首先是 2NF，另外非主键列必须直接依赖于主键，不能存在传递依赖。即不能存在：非主键列 A 依赖于非主键列 B，非主键列 B 依赖于主键的情况。

 

第三范式是大家常用的设计方式。或者可以思考 二范式的大表拆分成独立业务的小表。主键从另外一个角度 就是独立业务和数据的标识。

 

我只想说明设计场景，具体的细节看别的博客

第三范式  很多优势。

 当然从业务拆分，业务清楚，或者说更面向对象，理解简单。

 

从第三范式 优缺点 或者说从一个数据仓库 角度 或者从一个数据处理的角度看

牺牲性能 来减少冗余。

一张表查询 两个表进行关联 和明细有优势。

 

具体怎么实现要看具体的需求。

你更愿意牺牲什么

举例 两张大表

A 1000千万  B1000千万

把两张表合成一张表 可能 3000万

 

A在加索引的情况也很慢。你就考虑了。如果提供sql语句性能 当然做成一张宽表。

不必拘泥于几范式。

 

我个人感觉  二范式 更侧重 从行角度看能拆分吗，能就去拆分把

三范式 更侧重于 重 从列角度看能拆分吗，能就去拆分吧