关于一套简单的数据标签体系设计

1、资源标签体系

1.1、体系概述

我们需要开发一个高效、灵活且可扩展的标签系统，用于将标签与各种资源（例如人才库、专家库等）关联起来。通过该系统，我们可实现无代码拓展标注功能，系统将提供静态标签、规则自定义标签（动态标签）、复合标签（多种标签的交并集）三种类型的标签。
该标签系统旨在为上层系统提供一个强大的标记和分类机制，以帮助用户更轻松地搜索、过滤和组织资源；同时可以将标签归类等数据更为规范且高效地提供给任何需要其数据进行分析的模块。
标签其实是一种便捷灵活的数据索引方式，标签主要分两部分：一部分为标签本身结构体的定义：如该标签的各种参数（颜色、名称等——用于展示，标签指向资源类型），另一部分为被打上该标签的资源的存储方式的定义。和高级语言中的定义指针类型->定义指针->定义指针所指资源相似，一种标签可以理解为一类指针类型的所有指针的集合。
想特殊标识一部分人才，可以通过某些检索条件过滤得到人才列表，并将该条件存储，当人才的某些数据变动、使其可以通过/不能通过检索条件时，更新标签关系、添加/删除对应的标签数据。在打上标签后，系统可以通过标签高效快捷地查询所有符合条件的过滤集合。

1.1.1数据结构设计

1.1.1.1体系逻辑结构

1.1.1.2标签基本信息表（静态标签）

属性说明：
标签类型分为静态标签、动态标签、复合标签，这将决定该标签是否会由系统自动维护、标签赋予规则的存储位置；
标签标注资源存储该标签标注的资源类型，如：人才表，专家表。
颜色、图标、描述应用于前端页面相关数据的个性化展示。
标签其余属性暂未设计
标签基本信息表中的标签ID与标签标注资源类型需要形成一个反查表，即：可通过输入标注资源类型，获取该类型资源有可能被标记的所有标签列表。该功能将用于所有资源数据更新的前缀/后缀操作，通过过滤该资源是否满足标签标记条件，从而用于提高标签更新的效率。
标签的物理结构设计为：

命名 类型 名称
id varchar(32) 标签ID
tag_name varchar(64) 标签名称
tag_type tinyint 标签类型
tag_target varchar(64) 标签标注资源类型
background_color varchar(64) 颜色
background_img varchar(128) 图标
tag_synopsis varchar(256) 描述

1.1.1.3动态标签规则表

ER图（TODO）
属性说明：
标签赋予规则：标签赋予规则可理解为一个过滤方法，通过该方法过滤的资源将被打上该动态标签。该表中可以存储多种形式保存的过滤方法，如：SQL语句、JAVA字节码、自定义查询模板语句，具体。
规则类型：如果该表中可以保存多种格式定义的规则，则需要标注该过滤方法的类型（标签赋予规则将以何种形式被解析为可提供给前端渲染的数据以及可执行的查询语句）
标签的物理结构设计为：
命名 类型 名称
rule_id varchar(32) 标签赋予规则ID
id varchar(32) 该规则所属标签ID
rule_content varchar(256) 标签赋予规则
rule_type tinyint 规则类型

1.1.1.4复合标签规则表

ER图（TODO）
属性说明：
原子标签列表：构成该复合标签的各原子标签的ID集合，原子标签可为：静态标签、动态标签。
复合规则：各个原子标签之间的交并集规则，如：A∩B∪C。
复合标签规则表的物理结构设计为：
命名 类型 名称
rule_id varchar(32) 复合标签规则ID
id varchar(64) 标签ID
atom_tags varchar(256) 原子标签列表
composite_rule varchar(256) 复合规则

1.1.1.5标签更新触发条件表

该表用于记录自动触发更新的标签的更新条件。

1.1.1.6标记数据表（标签-实体-关系表）

标记数据表的每项数据，均记录了：一个标记数据，即打了某个标签的某个资源（某标签的某个标记资源）。通过标签ID的反查询，可以确定该标签的标签标注资源，标注资源表中ID与entry_id相同的资源即为该标记的目标。
标签的动态更新是标签关系表的刷新、应用过程。为此，考虑要有从标签到数据的倒排索引。[Tag_ID, [Data1_ID, Data2_ID, Data3_ID, …]]
RE:给定某tag_id，即可通过查询tag_id获得该标签的倒排索引。建议系统将该种倒排查询与标签的更新封装为一个基础方法，并缓存倒排索引。从而保证：数据库表中不会出现冗余标签数据（标签ID、标注资源ID均相同），查询打某个标签的数据时效率问题。
属性说明：
标签ID：标签的ID，用于标识该条记录的标签种类
标注资源ID：用于记录该标识资源的ID。
复合标签规则表的物理结构设计为：
命名 类型 名称
mark_id varchar(32) 标注ID
tag_id varchar(32) 标签ID
entry_id varchar(32) 标注资源ID

1.1.1.7标签关系

标签与标签之间设计为有向图关系，该关系通过图数据库（或一张关系型数据表）存储。通过关系类型type来定义向量方向。通过关系名称定义标签之间的关系名称，如：父亲、兄弟、儿子。（TODO:确定关系类型是否为固定几种，如果为固定几种，关系名称字段应为枚举类型）
type= 0：from_tag是end_tag的“关系名称”；
type= 1：end_tag是from_tag的“关系名称”。
type= 2：from_tag与end_tag互为“关系名称”；
父子关系等具有对称性质的关系，均使用两条向量存储，即A标签是B标签的父亲，B标签是A标签的儿子。
标签关系表的物理结构设计为：
命名 类型 名称
relationship_id varchar(32) 标签关系ID
from_id varchar(32) 关系开始标签ID
end_id varchar(32) 关系指向标签ID
type tinyint 关系类型
relationship_name varchar(32) 关系名称

1.1.2标签所属分类（未改动）

对于较多的标签，通过标签的分类实现对标签的细分管理。标签可以不具有分类。
序号 分类 描述
1 属性类 基于人才结构化属性的标签分类
2 荣誉类 标识人才荣誉类信息的标签分类
3 职位类 标识人才职位类信息的标签分类
4 评价类 标识人才被评价类信息的标签分类
5 统计类 基于人才相关统计数据的标签分类

1.1.3标记数据的维护

1.1.3.1人工维护

静态标签由人工对标注资源的标记数据进行维护（包括给资源添加标签、撤销标签）。

1.1.3.2系统自动维护

动态标签与复合标签均由系统对标注资源的标签自动进行维护（包括给资源添加标签、撤销标签）。当资源进行更新/修改时，自动将该资源有可能被打上的标签进行遍历并判断，若通过过滤，自动新建资源-标签对应的标记数据；若资源不符合某标签的条件，自动删除已存在的对应标记数据。

1.1.4静态标签的生命周期

1.1.4.1创建

静态标签的创建，通过选择标签标记资源类型、填写标签基础信息即可完成。标签名称为标签检索的主要标准，故标签名称不可重复。

1.1.4.2维护

标签标注资源的维护由业务人员手动维护，系统提供多种快捷标注功能。
（一）通过标签关系查询，可以选择任意标注资源类型相同的标签，获取其所有标注资源，对其所有标注资源赋予当前维护的静态标签。
（二）父子关系、兄弟关系标签。

1.1.5复合标签的生命周期TODO

1.1.5.1维护

复合标签的标签标注资源的维护只需要提供对复合标签和原子标签的增删功能，以及各个原子标签之间的交并运算的修改功能。对应的原子标签的维护跳转至对应的标签维护页面即可。

1.1.6动态标签的生命周期

1.1.6.1概览

动态标签的生命周期主要分为创建、检查、保存、执行、维护几步。下面将针对各步骤的需求及主要职责进行描述。

1.1.6.2创建

从数据源中选择打标签的资源类型，填写标签基本信息，并选择标签类型为动态标签后，即可进入动态标签的赋予规则设置页面。
动态标签的赋予规则有三种创建方法：
（一）简单规则：通过选择标签绑定的实体表数据源提供的多种键值查询功能，并可选择各过滤条件之间的且或关系。（对外提供简单规则标签创建接口，以便于在搜索完成后直接对搜索条件进行批量打标签，该种形式的赋予规则依附于专家库等组件提供的数据源检索功能）
如：标签标注资源为人才表，该设置页面即可选择人才表提供的各种键值的查询操作。下面是人才表中部分字段的部分支持查询功能示例，简单规则可从其中选择若干项，并填写具体要求，设置各条件之间的关系（且、或、非）。从而实现对单表的简单规则的设置，通过该规则的所有资源均会被打上该标签。

字段名称 数据类型 查询操作
姓名 文本类（50） 模糊/精确查询
证件类型 枚举类 多选框
证件号码 文本类（100） 模糊/精确查询
性别 代码类 模糊/精确查询
出生日期 时间日期类（yyyy-mm-dd） 时间范围查询、精准日期查询
民族 代码类 模糊/精确查询
国籍 代码类 模糊/精确查询

（二）复杂规则：通过选择附加表、主表与附加表JOIN键，提供两个数据源的多种键值查询功能的合并，并可选择各过滤条件之间的且或关系（该种设计目前只支持一对一关系，一对多的COUNT,GROUP等需求还未设计）。该部分规则需要与业务方准确沟通需求后准确建立。以下为简单举例：
如：标签标注资源为人才表，选择附加表为专家表，设置JOIN键为：人才表-人才ID，专家表-人才ID。系统自动提供JOIN后的两表的所有查询操作，如：
字段名称 数据类型 查询操作
姓名 文本类（50） 模糊/精确查询
证件类型 枚举类 多选框
证件号码 文本类（100） 模糊/精确查询
性别 代码类 模糊/精确查询
出生日期 时间日期类（yyyy-mm-dd） 时间范围查询、精准日期查询
民族 代码类 模糊/精确查询
国籍 代码类 模糊/精确查询
入库日期 时间日期类（yyyy-mm-dd） 时间范围查询、精准日期查询
入库原因 文本类（256） 模糊/精确查询
是否抽取 标记类 单选框
是否提名 标记类 单选框
是否临时 标记类 单选框
表1.2 人才表与专家表JOIN后部分字段的过滤功能示例

通过从其中选择若干项，并填写具体要求，设置各条件之间的关系（且、或、非），该条件将成为给予标签标注资源标签的规则。
（三）极复杂规则（前面两种形式的够不够用啊，够用的话这个就删除了，这个我本意是面向开发人员的，有一些多表查询特别复杂的，通过简单的JOIN之类的确实过滤不了，比如在某个团队中担任某个角色的人才之类的）：通过提供相关表结构文件，允许业务人员/开发人员手写SELECT语句进行查询，并保存为动态标签。或，通过提供相关的自定义查询语句教程，提供更为复杂的查询功能，如：COUNT、SUM、GROUP等功能。

1.1.6.3检查

在该部分，动态标签的各项关键信息将被检查，从而保证标签数据的完整性、正确性。同时避免错误的标签赋予条件被系统执行，破坏系统的数据完整性。

1.1.6.4保存

在该部分，标签赋予规则将被写入数据库，以持久化形式保存。同时，标签赋予规则可以被反向解析为规则设置页面显示所需数据（用于后续标签赋予规则的编辑功能）。
此外，标签赋予规则在任何时候均可以被系统以解析/直接执行的方式执行，得到一批通过过滤的资源。

1.1.6.5打标签动作的执行

初次建立标签时，系统将执行一遍标签过滤条件，并将所有通过过滤的资源建立对应的标记数据。当任何资源被插入/删除/更新时，系统都将通过1.1.1.2节中声明的反查表，获取资源可能的标记标签，并执行对应的过滤条件，判断该资源的标记数据是否需要新增/删除。其中，插入/更新操作中，打标签动作为后缀动作；删除操作中，打标签动作为前缀操作。

1.1.6.6编辑

除标签标记资源、标签种类（静态、动态、复合）、规则类型（简单、复杂）外，标签的其余属性均可以被修改，修改与创建流程相似。但是修改页面需要默认显示目前的标签属性，如：标签赋予规则。

1.1.6.7动态标签赋予规则的语法定义及解析。

标签编辑及标签信息浏览需要对标签的赋予规则进行反向解析，与1.1.6.2节中动态标签赋予规则的三种创建方法对应，需要为动态标签赋予规则设置至少三种语法解析模板，使得赋予规则可以被解析执行、解析为页面渲染所需数据。
（一）简单规则：
赋予规则需要保存：选择过滤的键及对应判断条件，各条件的与或非关系。
也可以直接存储查询SQL。
如定义JSON格式数据保存某规则（姓名中包含张、年龄小于等于40岁）：
{
“query”: "SELECT * FROM WHERE AND ", // 自动生成的SQL查询语句
“rule_column”: [“name”, “age”], // 判断列名
“rule_type”: { // 判断类型
“name”: “模糊查询”,
“age”: “<=”
},
“parameters”: { // 条件值
“name”: “张”,
“age”: “40”
},
“rule_relationship”: { // 各条件的与或非关系
“0”&&”1”
}
}
（二）极复杂规则：
该种规则可以删除，可以直接由开发人员在数据库中添加极为复杂的语句/提供接口。
{
“query”: “SELECT * FROM A …”, // 自定义的SQL查询语句
}

1.1.7标签关系的管理

标签关系的管理可以通过图谱/列表形式展示或管理，包含新建关系，检索标签相关数据，修改关系等。
https://modao.cc/app/WgzB4OErxjf3sk4qpthSA #标签体系原型设计-分享

1.1.8标签推荐功能（其它模块/对应业务模块需求）

根据用户的标签使用历史和当前资源内容，为用户推荐可能合适的标签。如：如果用户通过条件查询过滤得到一些资源内容，那么可以为用户推荐动态标签、以此方便快捷地标识过滤的参数即查询得到的资源。如果用户自行选择了某些资源，那么可以为用户推荐静态标签、以此直接标识该用户选定的资源项目。如果用户同时使用条件查询过滤及选择部分资源，那么可以为用户推荐复合标签、通过条件查询生成的动态标签与自行选择的静态标签的复合体，标识用户选择的数据。
动态标签
如下图1.3，该页面为人才表对应的简要数据展示页面草图，标记按钮在过滤框中。该页面设置了两条过滤条件，通过查询得到了若干符合条件的资源（人才数据）。

如果用户想将所有通过了查询的人才打上标签，那么用户只需要点击标记按钮，且保证没有在数据的左侧选择框中勾选任何数据，那么系统将为用户自动推荐动态标签，并将所用的过滤条件自动填入过滤条件中，如下图1.4：

在点击确定按钮后，系统将为所有符合条件的人才数据打上标签，用户后续可通过标签管理页面，点击标签的标记数据，直接浏览刚刚心仪的人才数据。
静态标签：
如图1.5，该页面为人才表对应的简要数据展示页面草图，标记按钮在过滤框中。该页面未设置查询条件，用户通过手动选择部分人才数据后点击标记按钮，系统将为用户推荐静态标签进行标记。

如图1.6，用户填写标签的属性信息后，系统将自动生成静态标签，并将上述所选资源打上该标签。用户后续可通过标签管理页面，点击标签的标记数据，直接浏览刚刚选择的人才数据。

复合标签
如下图1.7，该页面为人才表对应的简要数据展示页面草图，标记按钮在过滤框中。该页面设置了两条过滤条件，通过查询得到了若干符合条件的资源（人才数据），在查询的得到的数据中，用户选择了部分人才想将其打上标签。此时系统将为用户推荐复合标签。

对于通过该种方式新建的复合标签，系统将自动生成两个对应的原子标签——记录过滤条件的动态标签、记录特殊标记对象的静态标签。通过将上述两个标签复合并执行交运算，系统生成了对应的复合标签。用户后续可通过标签管理页面，点击标签的标记数据，浏览刚刚选择的人才数据。

1.2 性能要求

对于静态标签，要求使用缓存或反向列表的方式进行查询，禁止每次查询均需遍历标记数据表。
对于动态标签：在自动更新标记资源时。禁止通过：删除标记数据+触发动态标签的SQL过滤资源+重新写入标记数据的方式更新。必须通过：资源数据更新触发标签SQL过滤判断+删除/新增标记数据的方式。在查询标签标记数据时，要求使用缓存或反向列表的方式进行查询，禁止每次查询均需遍历标记数据表。
对于复合标签：同动态标签。

1.3 接口需求

标签系统作为其它系统的底层支持模块，需要对其它系统开发功能接口。对于现有的人才管理系统，标签系统需要开放对应系统所需的接口。