有效性是字段值在指定的有效范围内，相对而言是静的。
参照完整性，相对是动的，并且参照完整性可实施级联删除和变更。
参照完整性一般多用于多个表之间的主键外键参照，从而保证数据的完整。
参照完整性规则要求：
1、不允许在“多端”的字段中输入1个“一端”主键不存在的值；
2、如果某一记录有相关的记录存在于关系表中，那么数据库引擎不允许从“一端”删除这个记录（除非选择了级联删除相关字段，这样会同时删除“一端”和“多端”的记录，从而保证数据的完整性），因为如果允许又回出现第一种情况。
3、如果某一记录有相关的记录存在于关系表中，那么数据库引擎不允许改变“一端”主键的值（除非选择了级联更新相关字段，这样会同时更新“一端”和“多端”的主键值，从而保证数据的完整性），因为如果允许又回出现第一种情况。
定义主键以对不允许空值的指定列中输入的值强制唯一性。 如果为数据库中的某个表定义了主键，则可将该表与其他表相关，从而减少对冗余数据的需要。 一个表只能有一个主键。
在每种蛋白质中，多肽链中氨基酸的排列顺序,包括二硫键的位置，我们称为蛋白质的一级结构
，也叫初级结构或基本结构。蛋白质一级结构是理解蛋白质结构
、作用机制以及与其同源蛋白质生理功能
的必要基础。
蛋白质的一级结构包括：
（1）组成蛋白质的多肽链
的数目；
（2）多肽链
的氨基酸
顺序；
（3）多肽链内或链间二硫键
的数目和位置。
主数据是描述企业核心数据、业务对象，当记录到数据库中时，需要对其进行维护，确保其时效性、准确性。数据模型管理是重要的环节，在实施主数据模型版本管理项目中用树节点挂载的方式，建立不同的数据类型树，在树节点下挂载数据类型、模型、版本，在每个版本下配置字段、展现方式等信息，并且可增加编码配置关系，在应用数据的时候可以灵活使用和展现数据。有效地解决了地产等行业的需求，提高数据处理效率和使用价值。目录：1. 数据模型版本管理使用方案介绍2. 模型版本管理数据关系结构3. 模型版本管理下的主数据1.数据模型管理使用方案介绍对于数据开发项目，我们常常会面临众多的数据对接,部分场景不仅数据量大，且数据种类多，数据解析开发工作量巨大。对于主数据模型版本管理，一般是使用是树节点挂载的方式，建立不同的数据类型树，在相应的树节点下挂载相应的数据类型、模型、版本和数据，在每个版本下需要配置相应的字段、展现方式等信息，并且可以增加一些编码配置关系，在应用数据的时候可 以灵活的使用和展现数据。
数据模型版本管理分为四部分：第一部分是数据分类管理，首先建立数据分类，比如职员、部门、出勤等数据分类，模型对应到每个数据分类下，在每个模型下有不同的模型版本，模型版本下有相应的数据属性；第二部分是模型配置，在每个模型版本下进行相关配置：每个模型版本下包含字段属性，字段配置就是对这些属性进行配置，这些配置包括中文、英文名称，默认值，是否是主键，是否是流程字段，是否是编码字段的信息；数据显示存在展现方式，展现方式包括数据模型的名称，展现方式是列表还是树或者是树和列表共同展示；数据查重包括查重规则名称和对应校验的字段信息；详细数据展示的时候会关联到数据模板，数据模板会配置与具体字段属性的关联关系，包括模板编码、名称，相关备注信息，字段是否显示、是否可编辑，是否必填信息。第三部分是编码管理，分为码段管理和编码规则，码段管理是维护一套编码，如：固定码、特征码、流水码、日期码等；编码规则是绑定模型板和对应编码的关系，可以增加、删除对应的关系。第四部分是数据应用部分，在配置好数据分类、模型配置、编码管理，数据应用的部分包括详细的数据，指数据维护、查看、权限和历史数据。面对大量数据和众多的数据类型，用数据分类、模型配置、编码管理和数据应用实现灵活管理和使用数据的目的。2.模型版本管理数据关系结构1、模型管理模块是指数据分类、数据字典、模型管理树形的单个数据分类下关联了多个模型，每个模型会有会有多个版本状态，每个模型下会涉及到多个模型版本，每个模型版本会有多个版本，但是只能有一个生效启用的版本，版本下增加了数据的字段属性。
如上是数据模型管理的树形图，也代表了数据结构关联关系，数据字段属性是数据详细内容。理论上，每个模型版本维护一套数据结构，意味着通过该版本控制当前的数据类型和形式。2、模型配置包含了多维度的配置，使得数据使用上更细化模型配置是对数据模型的补充，使得数据在使用上形式更多、更准确，其中包括了在字段配置、展现方式、数据查重、数据模板、数据权限上的配置。
如上图是模型配置信息，在不同模块下通过建立与字段属性的的关系，达到细化控制数据的目的，通过数据权限的配置，分用户使用数据。3、编码管理是对应到具体数据的字段上，包括值和类型以及相应的使用信息编码管理包括码段管理和编码管理，码段管理是根据实际项目中的需要设置多个码段类型，编码规则是将需要的码段类型绑定到具体的模型版本上，实现对模型版本具体字段的控制。
如上图是编码管理的配置信息，模型版本通过编码规则绑定适合版本的码段类型，形成一个带有码段的模型版本。4、数据应用模型版本管理下的数据使用部分在完成模型管理、模型配置和编码管理的基础上，实现数据查看、维护及历史数据查看。
如上图是数据应用的配置信息。3.模型版本管理下的主数据数据维护中的数据只提供查看，数据维护中的数据不仅可以查看功能，还可以进行增删改功能，历史数据中的数据是指当前版本下的之前版本的数据。数据列表如下所示：
在数据模型版本管理中，模型版本是平台管理数据一个重要的部分，不同的数据分类下的不同模型下也会存在多个版本，它维护了当前使用的数据模型版本的一套数据关系，包括所关联的模型配置和编码管理，每一个版本下的模型配置和编码管理都可以存在差异，再通过数据版本的状态是否生效判断当前数据是否可用，如此通过模型和编码配置进行更细化的管理和使用数据，达到数据模型版本管理的不同分类下、不同模型版本下灵活、充分的使用数据的目的。关于作者：茅十八，现任普元产品部大数据开发工程师。曾在电商（联通商城）领域公司工作。参与dsp 6.0版本、主数据开发及平台维护，擅长MyBatis、SpringMVC、Spring等领域技术，长期致力于IT技术研究、产品开发。专注服务治理、数据共享。对大数据、电商行业有着深入的研究。
关于EAWorld：微服务，DevOps，数据治理，移动架构原创技术分享。长按二维码关注！
他们俩是有区别的，主键就是能够唯一标识表中某一行的属性或属性组，一个表只能有一个主键，但可以有多个候选索引，当有多个候选码时，可以选定一个作为主码，选定的候选码称主键而主码可以有多个。
主键：当有多个候选码时，可以选定一个作为主码，选定的候选码称主键；
我们在建立数据库的时候，需要为每张表指定一个主码，主码也叫主键。
一个表只能有一个主键，如果非得实现两个主键的功能可以建一个唯一约束配合主键一起使用，就能起到相当于两个主键的作用。
约束就是对数据的一种控制，不是让所有的数据都能进入，满足条件的数据才能进入。
约束在excel，数据库中比较常见，例如在数据库中设置主键约束，空值约束，数值条件约束，这些都能有效的控制满足条件的数据进入数据库中，避免无效数据和脏数据进入。
3.1.水平分库
概念：以字段为依据，按照一定策略（hash、range等），将一个库中的数据拆分到多个库中。
结果：
每个库的结构都一样；
每个库的数据都不一样，没有交集；
所有库的并集是全量数据；
场景：系统绝对并发量上来了，分表难以根本上解决问题，并且还没有明显的业务归属来垂直分库。
分析：库多了，io和cpu的压力自然可以成倍缓解。
3.2.垂直分库
概念：以表为依据，按照业务归属不同，将不同的表拆分到不同的库中。
结果：
每个库的结构都不一样；
每个库的数据也不一样，没有交集；
所有库的并集是全量数据；
场景：系统绝对并发量上来了，并且可以抽象出单独的业务模块。
分析：到这一步，基本上就可以服务化了。例如，随着业务的发展一些公用的配置表、字典表等越来越多，这时可以将这些表拆到单独的库中，甚至可以服务化。再有，随着业务的发展孵化出了一套业务模式，这时可以将相关的表拆到单独的库中，甚至可以服务化。
3.3.水平分表
水平分表又分为 ：单库水平分表和多库水平分表。
概念：以字段为依据，按照一定策略（hash、range等），将一个表中的数据拆分到多个表中。
结果：
每个表的结构都一样；
每个表的数据都不一样，没有交集；
所有表的并集是全量数据；
场景：系统绝对并发量并没有上来，只是单表的数据量太多，影响了SQL效率，加重了CPU负担，以至于成为瓶颈。
分析：表的数据量少了，单次SQL执行效率高，自然减轻了CPU的负担。
3.4.垂直分表
概念：以字段为依据，按照字段的活跃性，将表中字段拆到不同的表（主表和扩展表）中。
结果：
每个表的结构都不一样；
每个表的数据也不一样，一般来说，每个表的字段至少有一列交集，一般是主键，用于关联数据；
所有表的并集是全量数据；
场景：系统绝对并发量并没有上来，表的记录并不多，但是字段多，并且热点数据和非热点数据在一起，单行数据所需的存储空间较大。以至于数据库缓存的数据行减少，查询时会去读磁盘数据产生大量的随机读IO，产生IO瓶颈。
分析：可以用列表页和详情页来帮助理解。垂直分表的拆分原则是将热点数据（可能会冗余经常一起查询的数据）放在一起作为主表，非热点数据放在一起作为扩展表。这样更多的热点数据就能被缓存下来，进而减少了随机读IO。拆了之后，要想获得全部数据就需要关联两个表来取数据。但记住，千万别用join，因为join不仅会增加CPU负担并且会讲两个表耦合在一起（必须在一个数据库实例上）。关联数据，应该在业务Service层做文章，分别获取主表和扩展表数据然后用关联字段关联得到全部数据。
3.5.分库分表方案选择
应该使用哪一种方式来实施数据库分库分表，这要看数据库中数据量的瓶颈所在，并综合项目的业务类型进行考虑。
3.5.1.垂直切分方案适用场景
数据库是因为表太多而造成海量数据，并且项目的各项业务逻辑划分清晰、低耦合，那么规则简单明了、容易实施的垂直切分必是首选。
