adjust tree or table model to mode (apache#993)

Author: leto-bbq

src/UserGuide/Master/Table/Background-knowledge/Cluster-Concept_apache.md

@@ -25,12 +25,12 @@
 
 ### 1.1 sql_dialect
 
-IoTDB supports two time-series data models (SQL dialects), both managing devices and measurement points:  
+IoTDB supports two time-series data mode (SQL dialects), both managing devices and measurement points:  
 
-- **Tree** **Model**: Organizes data in a hierarchical path structure, where each path represents a measurement point of a device.
-- **Table** **Model**: Organizes data in a relational table format, where each table corresponds to a type of device.
+- **Tree** **Mode**: Organizes data in a hierarchical path structure, where each path represents a measurement point of a device.
+- **Table** **Mode**: Organizes data in a relational table format, where each table corresponds to a type of device.
 
-Each dialect comes with its own SQL syntax and query patterns tailored to its data model.
+Each dialect comes with its own SQL syntax and query patterns tailored to its data mode.
 
 ### 1.2 Schema  
 
@@ -73,7 +73,7 @@ An IoTDB cluster consists of three types of nodes, each with distinct responsibi
 
 - **ConfigNode (Management Node)** Manages cluster metadata, configuration, user permissions, schema, and partitioning. It also handles distributed scheduling and load balancing. All ConfigNodes are replicated for high availability.
 - **DataNode (Storage and Computation Node)** Handles client requests, stores data, and executes computations.
-- **AINode (Analytics Node)** Provides machine learning capabilities, allowing users to register pre-trained models and perform inference via SQL. It includes built-in time-series models and common ML algorithms for tasks like prediction and anomaly detection.
+- **AINode (Analytics Node)** Provides machine learning capabilities, allowing users to register pre-trained models and perform inference via SQL. It includes built-in time-series mode and common ML algorithms for tasks like prediction and anomaly detection.
 
 ### 2.3 Data Partitioning  
 

src/UserGuide/Master/Table/Background-knowledge/Cluster-Concept_timecho.md

@@ -25,12 +25,12 @@
 
 ### 1.1 sql_dialect
 
-IoTDB supports two time-series data models (SQL dialects), both managing devices and measurement points:  
+IoTDB supports two time-series data mode (SQL dialects), both managing devices and measurement points:  
 
-- **Tree** **Model**: Organizes data in a hierarchical path structure, where each path represents a measurement point of a device.
-- **Table** **Model**: Organizes data in a relational table format, where each table corresponds to a type of device.
+- **Tree** **Mode**: Organizes data in a hierarchical path structure, where each path represents a measurement point of a device.
+- **Table** **Mode**: Organizes data in a relational table format, where each table corresponds to a type of device.
 
-Each dialect comes with its own SQL syntax and query patterns tailored to its data model.
+Each dialect comes with its own SQL syntax and query patterns tailored to its data mode.
 
 ### 1.2 Schema  
 
@@ -74,7 +74,7 @@ An IoTDB cluster consists of three types of nodes, each with distinct responsibi
 
 - **ConfigNode (Management Node)** Manages cluster metadata, configuration, user permissions, schema, and partitioning. It also handles distributed scheduling and load balancing. All ConfigNodes are replicated for high availability.
 - **DataNode (Storage and Computation Node)** Handles client requests, stores data, and executes computations.
-- **AINode (Analytics Node)** Provides machine learning capabilities, allowing users to register pre-trained models and perform inference via SQL. It includes built-in time-series models and common ML algorithms for tasks like prediction and anomaly detection.
+- **AINode (Analytics Node)** Provides machine learning capabilities, allowing users to register pre-trained models and perform inference via SQL. It includes built-in time-series modes and common ML algorithms for tasks like prediction and anomaly detection.
 
 ### 2.3 Data Partitioning  
 

src/UserGuide/Master/Table/Background-knowledge/Data-Model-and-Terminology_apache.md

@@ -21,31 +21,31 @@
 
 # Modeling Scheme Design
 
-This section introduces how to transform time series data application scenarios into IoTDB time series modeling.   
+This section introduces how to transform time series data application scenarios into IoTDB time series mode.   
 
-## 1. Time Series Data Model
+## 1. Time Series Data Mode
 
-Before designing an IoTDB data model, it's essential to understand time series data and its underlying structure. For more details, refer to: [Time Series Data Model](../Background-knowledge/Navigating_Time_Series_Data.md)
+Before designing an IoTDB data mode, it's essential to understand time series data and its underlying structure. For more details, refer to: [Time Series Data Mode](../Background-knowledge/Navigating_Time_Series_Data.md)
 
-## 2. Two Time Series Model in IoTDB
+## 2. Two Time Series Mode in IoTDB
 
-IoTDB offers two data modeling syntaxes—tree model and table model, each with its distinct characteristics as follows:
+IoTDB offers two data mode syntaxes—tree mode and table mode, each with its distinct characteristics as follows:
 
-**Tree Model**: It manages data points as objects, with each data point corresponding to a time series. The data point names, segmented by dots, form a tree-like directory structure that corresponds one-to-one with the physical world, making the read and write operations on data points straightforward and intuitive.
+**Tree Mode**: It manages data points as objects, with each data point corresponding to a time series. The data point names, segmented by dots, form a tree-like directory structure that corresponds one-to-one with the physical world, making the read and write operations on data points straightforward and intuitive.
 
-**Table Model**: It is recommended to create a table for each type of device. The collection of physical quantities from devices of the same type shares certain commonalities (such as the collection of temperature and humidity physical quantities), allowing for flexible and rich data analysis.
+**Table Mode**: It is recommended to create a table for each type of device. The collection of physical quantities from devices of the same type shares certain commonalities (such as the collection of temperature and humidity physical quantities), allowing for flexible and rich data analysis.
 
-### 2.1 Model Characteristics
+### 2.1 Mode Characteristics
 
-Both model syntaxes have their own applicable scenarios.
+Both mode syntaxes have their own applicable scenarios.
 
-The following table compares the tree model and the table model from various dimensions, including applicable scenarios and typical operations. Users can choose the appropriate model based on their specific usage requirements to achieve efficient data storage and management.
+The following table compares the tree mode and the table mode from various dimensions, including applicable scenarios and typical operations. Users can choose the appropriate mode based on their specific usage requirements to achieve efficient data storage and management.
 
 <table style="text-align: center;">
         <tr>
             <td>Dimension</td>
-            <td>Tree Model</td>
-            <td>Table Model</td>
+            <td>Tree Mode</td>
+            <td>Table Mode</td>
         </tr>
         <tr>
             <td>Applicable Scenarios</td>
@@ -75,20 +75,20 @@ The following table compares the tree model and the table model from various dim
 
 **Notes:**  
 
-- Both model spaces can coexist within the same cluster instance. Each model follows distinct syntax and database naming conventions, and they remain isolated by default.
+- Both mode spaces can coexist within the same cluster instance. Each mode follows distinct syntax and database naming conventions, and they remain isolated by default.
 
-- When establishing a database connection via client tools (Cli) or SDKs, specify the model syntax using the `sql_dialect` parameter (Tree syntax is used by default).
+- When establishing a database connection via client tools (Cli) or SDKs, specify the mode syntax using the `sql_dialect` parameter (Tree syntax is used by default).
 
 
 ## 3. Application Scenarios
 
 The application scenarios mainly include two categories:
 
-- Scenario 1: Using the tree model for data reading and writing.
+- Scenario 1: Using the tree mode for data reading and writing.
 
-- Scenario 2: Using the table model for data reading and writing.
+- Scenario 2: Using the table mode for data reading and writing.
 
-### 3.1 Scenario 1: Tree Model
+### 3.1 Scenario 1: Tree Mode
 
 #### 3.1.1 Characteristics
 
@@ -106,38 +106,38 @@ The application scenarios mainly include two categories:
 | **Time Series (Data Point)** | **Definition**:<br>A path prefixed with the database path, segmented by `.`, and can contain any number of levels, such as `root.db.turbine.device1.metric1`.<br>Each time series can have different data types.<br>**Naming Recommendation**:<br>Only include unique identifiers (similar to a composite primary key) in the path, generally not exceeding 10 levels.<br>Typically, place tags with low cardinality (fewer distinct values) at the front to facilitate system compression of common prefixes.<br>**Quantity Recommendation**:<br>The total number of time series manageable by the cluster is related to total memory; refer to the resource recommendation section.<br>There is no limit to the number of child nodes at any level.<br>**Creation Method**: Can be created manually or automatically during data writing. |
 | **Device**                   | **Definition**: The second-to-last level is the device, such as `device1` in `root.db.turbine.device1.metric1`.<br>**Creation Method**: Cannot create a device alone; it exists as time series are created. |
 
-#### 3.1.3 Modeling Examples
+#### 3.1.3 Mode Examples
 
-##### 3.1.3.1 How to model when managing multiple types of devices?
+##### 3.1.3.1 How to mode when managing multiple types of devices?
 
 - If different types of devices in the scenario have different hierarchical paths and data point sets, create branches under the database node by device type. Each device type can have a different data point structure.
 
 <div style="text-align: center;">
       <img src="/img/data-model-new-1-en.png" alt="" style="width: 70%;"/>
 </div>
 
-##### 3.1.3.2 How to model when there are no devices, only data points?
+##### 3.1.3.2 How to mode when there are no devices, only data points?
 
 - For example, in a monitoring system for a station, each data point has a unique number but does not correspond to any specific device.
 
 <div style="text-align: center;">
       <img src="/img/Data-model-en02.png" alt="" style="width: 70%;"/>
 </div>
 
-##### 3.1.3.3 How to model when a device has both sub-devices and data points?
+##### 3.1.3.3 How to mode when a device has both sub-devices and data points?
 
-- For example, in an energy storage scenario, each layer of the structure monitors its voltage and current. The following modeling approach can be used.
+- For example, in an energy storage scenario, each layer of the structure monitors its voltage and current. The following mode approach can be used.
 
 <div style="text-align: center;">
       <img src="/img/Data-model-en03.png" alt="" style="width: 70%;"/>
 </div>
 
 
-### 3.2 Scenario 2: Table Model
+### 3.2 Scenario 2: Table Mode
 
 #### 3.2.1 Characteristics
 
-- Models and manages device time series data using time series tables, facilitating analysis with standard SQL.
+- Modes and manages device time series data using time series tables, facilitating analysis with standard SQL.
 
 - Suitable for device data analysis or migrating data from other databases to IoTDB.
 
@@ -156,9 +156,9 @@ The application scenarios mainly include two categories:
 
 **Data Filtering Efficiency**: Time Column = Tag Column > Attribute Column > Data Point Column.
 
-#### 3.2.3 Modeling Examples
+#### 3.2.3 Mode Examples
 
-##### 3.2.3.1 How to model when managing multiple types of devices?
+##### 3.2.3.1 How to mode when managing multiple types of devices?
 
 - Recommended to create a table for each type of device, with each table having different tags and data point sets.
 
@@ -168,15 +168,15 @@ The application scenarios mainly include two categories:
       <img src="/img/data-model-new-2-en.png" alt="" style="width: 70%;"/>
 </div>
 
-##### 3.2.3.2 How to model when there are no device identifier columns or attribute columns?
+##### 3.2.3.2 How to mode when there are no device identifier columns or attribute columns?
 
 - There is no limit to the number of columns; it can reach hundreds of thousands.
 
 <div style="text-align: center;">
       <img src="/img/Data-model-en05.png" alt="" style="width: 70%;"/>
 </div>
 
-##### 3.2.3.3 How to model when a device has both sub-devices and data points?
+##### 3.2.3.3 How to mode when a device has both sub-devices and data points?
 
 - Each device has multiple sub-devices and data point information. It is recommended to create a table for each type of device for management.