数据库三范式在YANG模型中的应用解读

有人问：你一个搞北向接口 ”NETCONF/YANG"的，咋突然发啥数据库三范式了？你又不搞数据库。

话虽如此，但是研究YANG的同学，不理解北向网管是怎么适配的，就是相当于一个裁缝不了解你顾客的身材尺寸。而且设备侧的同学在设计YANG模型的时候是怎么设计的呢？你是根据命令行翻译成了YANG模型，还是根据你的特性业务，对你的特性进行了特性建模？模型驱动（model driven）这个词听说过吧。如果你是国内公司的YANG开发人员，还在跟做MIB一样设计YANG模型，建议去github上搜搜juniper、思科的YANG。看看NMDA，理解一下基于管理对象的建模。

言归正传：

第一范式（1NF）：

第一范式主要是保证数据表中的每一个字段的值必须具有原子性，也就是数据表中的每个字段的值是不可再拆分的最小数据单元。

点评：

我见过有个设备上单板风扇的建模。一个单板上有4个散热的小风扇。监控设备时要监控单板的风扇转速。模型是单板slot为键值（key），data只有一个leaf speed，数据类型为string，里面的字符串格式是“1:100;2:100;3:100;4:100;"。这串数据，明显是由4组风扇转速组成的，是可以分割的，不是原子数据字段。这就是一个典型的违反了第一范式的问题。

第二范式（2NF）

在1NF的基础上，还要满足数据表里的每一条数据记录，都是可唯一标识的，而且所有的非主键（key）字段，都必须完全依赖主键，不能只依赖主键（key）的一部分。

点评：

第二范式要求key唯一决定一条数据记录，且key中不应该有冗余的字段。比如：下面是一张实例表，每个实例有唯一的name做区分，软件内部会分配一个唯一的id。那么id是key吗？这里可以发现id做key是冗余了。

另外一种情况是多条数据有相同的key，这样会出现网管侧无法区分两条数据，就会出现数据覆盖。这种情况往往是key字段漏了。我在github上某设备厂商的yang模型中就见过这种模型，当然，后来他们厂家改掉了。

第三范式（3NF）

• 第三范式建立在已经满足第二范式的基础上
• 数据表中的每一个非主键字段都和主键字段直接相关
• 也就是说数据表中的所有非主键字段不能依赖于其他非主键字段
• 这个规则的意思是所有非主属性之间不能有依赖关系，它们是互相独立的
• 这里的主键可以拓展成为候选键

 点评：

这个范式难理解一些。我解释下上面的第二句话：一张表无论有几个key字段，主键是一个整体，标识一个对象，表中的每一个非key字段都和这个对象直接相关。举个例子：下表是一张接口带宽的表，其中有个slot字段，slot字段不应该出现在接口带宽表中，slot、port是另外一张设备管理的表项。