diff --git a/src/.vuepress/sidebar/V2.0.x/zh-Table.ts b/src/.vuepress/sidebar/V2.0.x/zh-Table.ts
index caaf233fe..5b6e11f67 100644
--- a/src/.vuepress/sidebar/V2.0.x/zh-Table.ts
+++ b/src/.vuepress/sidebar/V2.0.x/zh-Table.ts
@@ -40,7 +40,7 @@ export const zhSidebar = {
children: [
{ text: '常见概念', link: 'Cluster-Concept_apache' },
{ text: '时序数据模型', link: 'Navigating_Time_Series_Data' },
- { text: '建模方案设计', link: 'Data-Model-and-Terminology' },
+ { text: '建模方案设计', link: 'Data-Model-and-Terminology_apache' },
{ text: '数据类型', link: 'Data-Type' },
],
},
diff --git a/src/.vuepress/sidebar_timecho/V2.0.x/zh-Table.ts b/src/.vuepress/sidebar_timecho/V2.0.x/zh-Table.ts
index 38a7ab996..be5720650 100644
--- a/src/.vuepress/sidebar_timecho/V2.0.x/zh-Table.ts
+++ b/src/.vuepress/sidebar_timecho/V2.0.x/zh-Table.ts
@@ -40,7 +40,7 @@ export const zhSidebar = {
children: [
{ text: '常见概念', link: 'Cluster-Concept_timecho' },
{ text: '时序数据模型', link: 'Navigating_Time_Series_Data' },
- { text: '建模方案设计', link: 'Data-Model-and-Terminology' },
+ { text: '建模方案设计', link: 'Data-Model-and-Terminology_timecho' },
{ text: '数据类型', link: 'Data-Type' },
],
},
diff --git a/src/zh/UserGuide/Master/Table/Background-knowledge/Data-Model-and-Terminology_apache.md b/src/zh/UserGuide/Master/Table/Background-knowledge/Data-Model-and-Terminology_apache.md
new file mode 100644
index 000000000..97e0bcf5f
--- /dev/null
+++ b/src/zh/UserGuide/Master/Table/Background-knowledge/Data-Model-and-Terminology_apache.md
@@ -0,0 +1,186 @@
+
+
+# 建模方案设计
+
+本章节主要介绍如何将时序数据应用场景转化为IoTDB时序建模。
+
+## 1 时序数据模型
+
+在构建IoTDB建模方案前，需要先了解时序数据和时序数据模型，详细内容见此页面：[时序数据模型](../Background-knowledge/Navigating_Time_Series_Data.md)
+
+## 2 IoTDB 的两种时序模型
+
+> IoTDB 提供了两种数据建模方式——树模型和表模型，其特点分别如下：
+
+**树模型**：以测点为对象进行管理，每个测点对应一条时间序列，测点名按`.`分割可形成一个树形目录结构，与物理世界一一对应，对测点的读写操作简单直观。
+
+**表模型**：推荐为每类设备创建一张表，同类设备的物理量采集都具备一定共性（如都采集温度和湿度物理量），数据分析灵活丰富。
+
+### 2.1 模型特点
+
+两种模型有各自的适用场景。
+
+以下表格从适用场景、典型操作等多个维度对树模型和表模型进行了对比。用户可以根据具体的使用需求，选择适合的模型，从而实现数据的高效存储和管理。
+
+
+
+
+ | 对比维度 |
+ 树模型 |
+ 表模型 |
+
+
+ | 适用场景 |
+ 测点管理，监控场景 |
+ 设备管理，分析场景 |
+
+
+ | 典型操作 |
+ 指定点位路径进行读写 |
+ 通过标签进行数据筛选分析 |
+
+
+ | 结构特点 |
+ 和文件系统一样灵活增删 |
+ 模板化管理，便于数据治理 |
+
+
+ | 语法特点 |
+ 简洁 |
+ 标准 |
+
+
+ | 性能对比 |
+ 相同 |
+
+
+
+**注意：**
+- 同一个集群实例中可以存在两种模型空间，不同模型的语法、数据库命名方式不同，默认不互相可见。
+
+- 在通过客户端工具 Cli 或 SDK 建立数据库连接时，需要通过 sql_dialect 参数指定使用的模型语法（默认使用树语法进行操作）。
+
+
+## 应用场景
+
+应用场景主要包括两类：
+
+- 场景一：使用树模型进行数据的读写
+
+- 场景二：使用表模型进行数据的读写
+
+
+### 3 场景一：树模型
+
+#### 3.1 特点
+
+- 简单直观，和物理世界的监测点位一一对应
+
+- 类似文件系统一样灵活，可以设计任意分支结构
+
+- 适用 DCS、SCADA 等工业监控场景
+
+#### 3.2 基础概念
+
+| **概念** | **定义** |
+| -------------------- | ------------------------------------------------------------ |
+| **数据库** | 定义：一个以 root. 为前缀的路径
命名推荐：仅包含 root 的下一级节点，如 root.db
数量推荐：上限和内存相关，一个数据库也可以充分利用机器资源，无需为性能原因创建多个数据库
创建方式：推荐手动创建，也可创建时间序列时自动创建（默认为 root 的下一级节点） |
+| **时间序列（测点）** | 定义：
1. 一个以数据库路径为前缀的、由 . 分割的路径，可包含任意多个层级，如 root.db.turbine.device1.metric1
2. 每个时间序列可以有不同的数据类型。
命名推荐:
1. 仅将唯一定位时间序列的标签（类似联合主键）放入路径中，一般不超过10层
2. 通常将基数（不同的取值数量）少的标签放在前面，便于系统将公共前缀进行压缩
数量推荐:
1. 集群可管理的时间序列总量和总内存相关，可参考资源推荐章节
2. 任一层级的子节点数量没有限制
创建方式：可手动创建或在数据写入时自动创建。 |
+| **设备** | 定义：倒数第二级为设备，如 root.db.turbine.**device1**.metric1中的“device1”这一层级即为设备
创建方式：无法仅创建设备，随时间序列创建而存在 |
+
+#### 3.3 建模示例
+
+##### 3.3.1 有多种类型的设备需要管理，如何建模？
+
+- 如场景中不同类型的设备具备不同的层级路径和测点集合，可以在数据库节点下按设备类型创建分支。每种设备下可以有不同的测点结构。
+
+
+
+
+
+
+
+
标签信息不可修改和删除，但允许增加
推荐按粒度由大到小进行排列 |
+| **测点列（FIELD）** | 一个设备采集的测点可以有1个至多个，值随时间变化
表的测点列没有数量限制，可以达到数十万以上 |
+| **属性列（ATTRIBUTE）** | 对设备的补充描述，**不随时间变化**
设备属性信息可以有0个或多个，可以更新或新增
少量希望修改的静态属性可以存至此列 |
+
+
+数据筛选效率：时间列=标签列>属性列>测点列
+
+#### 4.3 建模示例
+
+##### 4.3.1 有多种类型的设备需要管理，如何建模？
+
+- 推荐为每一类型的设备建立一张表，每个表可以具有不同的标签和测点集合。
+- 即使设备之间有联系，或有层级关系，也推荐为每一类设备建一张表。
+
+
+
+
+
+
+
+
+
+ | 对比维度 |
+ 树模型 |
+ 表模型 |
+
+
+ | 适用场景 |
+ 测点管理，监控场景 |
+ 设备管理，分析场景 |
+
+
+ | 典型操作 |
+ 指定点位路径进行读写 |
+ 通过标签进行数据筛选分析 |
+
+
+ | 结构特点 |
+ 和文件系统一样灵活增删 |
+ 模板化管理，便于数据治理 |
+
+
+ | 语法特点 |
+ 简洁 |
+ 标准 |
+
+
+ | 性能对比 |
+ 相同 |
+
+
+
+**注意：**
+- 同一个集群实例中可以存在两种模型空间，不同模型的语法、数据库命名方式不同，默认不互相可见。
+
+- 在通过客户端工具 Cli 或 SDK 建立数据库连接时，需要通过 sql_dialect 参数指定使用的模型语法（默认使用树语法进行操作）。
+
+
+## 应用场景
+
+应用场景主要包括两类：
+
+- 场景一：使用树模型进行数据的读写
+
+- 场景二：使用表模型进行数据的读写
+
+
+### 3 场景一：树模型
+
+#### 3.1 特点
+
+- 简单直观，和物理世界的监测点位一一对应
+
+- 类似文件系统一样灵活，可以设计任意分支结构
+
+- 适用 DCS、SCADA 等工业监控场景
+
+#### 3.2 基础概念
+
+| **概念** | **定义** |
+| -------------------- | ------------------------------------------------------------ |
+| **数据库** | 定义：一个以 root. 为前缀的路径
命名推荐：仅包含 root 的下一级节点，如 root.db
数量推荐：上限和内存相关，一个数据库也可以充分利用机器资源，无需为性能原因创建多个数据库
创建方式：推荐手动创建，也可创建时间序列时自动创建（默认为 root 的下一级节点） |
+| **时间序列（测点）** | 定义：
1. 一个以数据库路径为前缀的、由 . 分割的路径，可包含任意多个层级，如 root.db.turbine.device1.metric1
2. 每个时间序列可以有不同的数据类型。
命名推荐:
1. 仅将唯一定位时间序列的标签（类似联合主键）放入路径中，一般不超过10层
2. 通常将基数（不同的取值数量）少的标签放在前面，便于系统将公共前缀进行压缩
数量推荐:
1. 集群可管理的时间序列总量和总内存相关，可参考资源推荐章节
2. 任一层级的子节点数量没有限制
创建方式：可手动创建或在数据写入时自动创建。 |
+| **设备** | 定义：倒数第二级为设备，如 root.db.turbine.**device1**.metric1中的“device1”这一层级即为设备
创建方式：无法仅创建设备，随时间序列创建而存在 |
+
+#### 3.3 建模示例
+
+##### 3.3.1 有多种类型的设备需要管理，如何建模？
+
+- 如场景中不同类型的设备具备不同的层级路径和测点集合，可以在数据库节点下按设备类型创建分支。每种设备下可以有不同的测点结构。
+
+
+
+
+
+
+
+
标签信息不可修改和删除，但允许增加
推荐按粒度由大到小进行排列 |
+| **测点列（FIELD）** | 一个设备采集的测点可以有1个至多个，值随时间变化
表的测点列没有数量限制，可以达到数十万以上 |
+| **属性列（ATTRIBUTE）** | 对设备的补充描述，**不随时间变化**
设备属性信息可以有0个或多个，可以更新或新增
少量希望修改的静态属性可以存至此列 |
+
+
+数据筛选效率：时间列=标签列>属性列>测点列
+
+#### 4.3 建模示例
+
+##### 4.3.1 有多种类型的设备需要管理，如何建模？
+
+- 推荐为每一类型的设备建立一张表，每个表可以具有不同的标签和测点集合。
+- 即使设备之间有联系，或有层级关系，也推荐为每一类设备建一张表。
+
+
+
+
+
+
+
+