update docs

Signed-off-by: NAnnie_wang <annie.wangli@huawei.com>

en/application-dev/database/database-mdds-overview.md

-# Distributed Data Service Overview<a name="EN-US_TOPIC_0000001183067628"></a>
+# Distributed Data Service Overview
 
-The distributed data service \(DDS\) implements distributed database collaboration across devices for applications. Applications save data to distributed databases by calling the DDS APIs. The DDS isolates data of different applications based on a triplet of account, application, and database to ensure secure data access. The DDS synchronizes application data between trusted devices to provide users with consistent data access experience on different devices.
+The distributed data service (DDS) implements distributed database collaboration across devices for applications. 
 
-## Basic Concepts<a name="section17506141102520"></a>
+Applications save data to distributed databases by calling the DDS APIs. The DDS isolates data of different applications based on a triplet of account, application, and database to ensure secure data access. The DDS synchronizes application data between trusted devices to provide users with consistent data access experience on different devices.
+
+You do not need to care about the implementation of the database locking mechanism.
+
+## Basic Concepts
 
 -   **KV data model**
 
@@ -54,7 +58,7 @@ The distributed data service \(DDS\) implements distributed database collaborati
     The DDS provides the database backup capability. You can set  **backup**  to  **true**  to enable daily backup. If a distributed database is damaged, the DDS deletes the database and restores the most recent data from the backup database. If no backup database is available, the DDS creates one. The DDS can also back up encrypted databases.
 
 
-## Working Principles<a name="section315111581616"></a>
+## Working Principles
 
 The DDS supports distributed management of application database data in the OpenHarmony system. Data can be synchronized between multiple devices with the same account, delivering a consistent user experience across devices. The DDS consists of the following:
 
@@ -86,7 +90,7 @@ Applications call the DDS APIs to create, access, and subscribe to distributed d
 
 ![](figures/en-us_image_0000001183386164.png)
 
-## Constraints<a name="section95382010203311"></a>
+## Constraints
 
 -   The DDS supports the KV data model only. It does not support foreign keys or triggers of the relational database.
 -   The KV data model specifications supported by the DDS are as follows:

en/application-dev/database/database-relational-overview.md

-# RDB Overview<a name="EN-US_TOPIC_0000001231030607"></a>
+# RDB Overview
 
-The relational database \(RDB\) manages data based on relational models. With the underlying SQLite database, the RDB provides a complete mechanism for managing local databases. To satisfy different needs in complicated scenarios, the RDB offers a series of methods for performing operations such as adding, deleting, modifying, and querying data, and supports direct execution of SQL statements.
+The relational database (RDB) manages data based on relational models. With the underlying SQLite database, the RDB provides a complete mechanism for managing local databases. To satisfy different needs in complicated scenarios, the RDB offers a series of methods for performing operations such as adding, deleting, modifying, and querying data, and supports direct execution of SQL statements.
 
-## Basic Concepts<a name="section1063573420813"></a>
+You do not need to care about the implementation of the database locking mechanism.
 
--   **RDB**
+## Basic concepts
 
-    A type of database based on the relational model of data. The RDB stores data in rows and columns. An RDB is also called RDB store.
+- **RDB**
 
--   **Predicate**
+  A type of database created on the basis of relational models. The RDB stores data in rows and columns. A RDB is also called RDB store.
 
-    A representation of the property or feature of a data entity, or the relationship between data entities. It is mainly used to define operation conditions.
+- **Predicate**
 
--   **Result set**
+  A representation of the property or feature of a data entity, or the relationship between data entities. It is mainly used to define operation conditions.
 
-    A set of query results used to access the data. You can access the required data in a result set in flexible modes.
+- **Result set**
 
--   **SQLite database**
+  A set of query results used to access data. You can access the required data in a result set in flexible modes.
 
-    A lightweight open-source relational database management system that complies with Atomicity, Consistency, Isolation, and Durability \(ACID\).
+- **SQLite database**
 
+  A lightweight open-source relational database management system that complies with Atomicity, Consistency, Isolation, and Durability (ACID).
 
-## Working Principles<a name="section4810552814"></a>
+## Working Principles
 
-The RDB provides a common operation interface for external systems. It uses the SQLite as the underlying persistent storage engine, which supports all SQLite database features.
+The RDB provides common operation APIs for external systems. It uses the SQLite as the underlying persistent storage engine, which supports all SQLite database features.
 
-**Figure  1**  How RDB works<a name="fig1826214361535"></a>  
-![](figures/how-rdb-works.png "how-rdb-works")
+**Figure 1** How RDB works
 
-## Default Settings<a name="section176091243121218"></a>
+![how-rdb-works](figures/how-rdb-works.png)
 
--   The default database logging mode is write-ahead logging \(WAL\).
--   The default database flush mode is Full mode.
--   The default shared memory used by the OpenHarmony database is 2 MB.
+## Default Settings
 
-## Constraints<a name="section929813398308"></a>
+- The default RDB logging mode is Write Ahead Log (WAL).
+- The default data flushing mode is **FULL** mode.
+- The default size of the shared memory used by an OpenHarmony database is 2 MB.
 
--   A maximum of four connection pools can be connected to an RDB to manage read and write operations.
+## Constraints
 
--   To ensure data accuracy, the RDB supports only one write operation at a time.
+- A maximum of four connection pools can be connected to an RDB to manage read and write operations.
 
+- To ensure data accuracy, the RDB supports only one write operation at a time.

en/application-dev/database/database-storage-overview.md

-# Lightweight Data Store Overview<a name="EN-US_TOPIC_0000001230752103"></a>
+# Lightweight Data Store Overview
 
-Lightweight data store is applicable to access and persistence operations on the data in key-value pairs. When an application accesses a lightweight  **Storage**  instance, data in the  **Storage**  instance will be cached in the memory for faster access. The cached data can also be written back to the text file for persistent storage. Since file read and write consume system resources, you are advised to minimize the frequency of reading and writing persistent files.
+The lightweight data store is applicable to access and persistence of data in the key-value structure.
 
-## Basic Concepts<a name="section1055404171115"></a>
+After an application obtains a lightweight store instance, the data in the instance will be cached in the memory for faster access. The cached data can also be written back to the text file for persistent storage. Since file read and write consume system resources, you are advised to minimize the frequency of reading and writing persistent files.
 
--   **Key-Value data structure**
+You do not need to care about the implementation of the database lock mechanism.
 
-    A type of data structure. The key is the unique identifier for a piece of data, and the value is the specific data being identified.
+## Basic Concepts
 
--   **Non-relational database**
+- **Key-value structure**
 
-    A database not in compliance with the atomicity, consistency, isolation, and durability \(ACID\) database management properties of relational data transactions. The data in a non-relational database is independent.
+  A type of data structure. The key is the unique identifier for a piece of data, and the value is the specific data being identified.
 
+- **Non-relational database**
 
-## Working Principles<a name="section682631371115"></a>
+  A database not in compliance with the atomicity, consistency, isolation, and durability (ACID) properties of relational data transactions. The data in a non-relational database is independent.
 
-1.  When an application loads data from a specified  **Storage**  file to a  **Storage**  instance, the system stores the instance in the memory through a static container. Each file of an application or process has only one  **Storage**  instance in the memory, till the application removes the instance from the memory or deletes the  **Storage**  file.
-2.  When obtaining a  **Storage**  instance, the application can read data from or write data to the instance. The data in the  **Storage**  instance can be flushed to its  **Storage**  file by calling the  **flush**  or  **flushSync**  method.
+## Working Principles
 
-**Figure  1**  How lightweight data store works<a name="fig1657785713509"></a>  
+1. An application can load data from a specified **Storage** file to a **Storage** instance. The system stores the instance in the memory through a static container. Each file of an application or process has only one **Storage** instance in the memory, till the application removes the instance from the memory or deletes the **Storage** file.
+2. When obtaining a **Storage** instance, the application can read data from or write data to the instance. The data in the **Storage** instance can be flushed to its **Storage** file by calling the **flush** or **flushSync** method.
 
+**Figure 1** Working mechanism
 
 ![](figures/en-us_image_0000001199139454.png)
 
-## Constraints<a name="section17243172883219"></a>
-
--   **Storage**  instances are loaded to the memory. To minimize non-memory overhead, the number of data records stored in a  **Storage**  instance cannot exceed 10,000. Delete the instances that are no longer used in a timely manner.
--   The key in the key-value pairs is of the string type. It cannot be empty or exceed 80 characters.
--   If the value in the key-value pairs is of the string type, it can be empty or contain a maximum of 8192 characters.
+## Constraints
 
+- **Storage** instances are loaded to the memory. To minimize non-memory overhead, the number of data records stored in a **Storage** instance cannot exceed 10,000. Delete the instances that are no longer used in a timely manner.
+- The key in the key-value pairs is of the string type. It cannot be empty or exceed 80 bytes.
+- The value of the string type can be empty, but cannot exceed 8192 bytes if not empty.

en/readme/security.md

-# Security<a name="EN-US_TOPIC_0000001087014383"></a>
-
-
-## Introduction<a name="section11660541593"></a>
-
-The security subsystem provides system, data, and application security capabilities to protect system and user data of OpenHarmony.
-
-It implemens application integrity verification, application permission management, device authentication, OpenHarmony Universal KeyStore (HUKS) key management, and data transfer management.
-
-## Architecture<a name="section342962219551"></a>
-
-**Figure 1** Security subsystem architecture<a name="fig4460722185514"></a> 
-
-![](figures/security_subsustem_architecture.png)
-
-The security subsystem consists of the following functional modules:
-
-- Interface layer: provides APIs to developers, some of which are only available for system applications
-
-- Application permission management: implements permission management for the application framework subsystem and provides APIs for applications to request permissions and query the permission granting status.
-
-- Application integrity verification: verifies application integrity during application signing and installation.
-- Device authentication: provides key agreement and trusted device management capabilities for interconnections between devices in a distributed network.
-
-- HUKS key management: provides the key management service for basic device authentication.
-
-- Data transfer management: provides API definitions related to data transfer management and control.
-
-## Directory Structure<a name="section92711824195113"></a>
-
-```
-/base/security
-├── appverify                       # Application integrity verification
-├── dataclassification              # Data transfer management
-├── device_auth                     # Device authentication
-├── huks                            # HUKS key management
-└── permission                      # Permission management
-```
-
-## Constraints<a name="section7715171045219"></a>
-
--   In the current version, application permission management is available only for local applications. (The stub mode is used for joint commissioning of upper-layer distributed services.)
--   Device authentication includes authentication for devices with the same account and peer-to-peer device authentication. Currently, only the latter is available. (The stub mode is used for joint commissioning of upper-layer distributed services.)
--   OpenHarmony-specific certificates are used for application integrity verification. The corresponding public key certificates and private keys are preset in the open-source code repositories of OpenHarmony to provide offline signing and verification capabilities for the open-source community. The public key certificates and the corresponding private keys need to be replaced in commercial versions that are based on OpenHarmony.
-
-## Usage<a name="section2057642312536"></a>
-
-#### Application Permission Management
-
-In OpenHarmony, applications and system services run in independent sandboxes. Both processes and data are isolated from each other to protect the security of application data. However, services or applications running in the sandboxes provide some APIs to implement specific functionalities. To access these APIs across processes, applications in other sandboxes need the required permissions, which are granted and managed based on a permission management mechanism.
-
-Application permission management provides a mechanism for defining permissions, allowing system services and applications to define new permissions for their sensitive APIs. To access these APIs, other applications need the required permissions.
-
-Application permission management also allows applications to request permissions that are defined by the system or other applications. Upon obtaining the permissions, applications can access the sensitive APIs provided by the system or other applications.
-
-In addition, application permission management allows users to view and manage the permission granting status.
-
-#### Application Integrity Verification
-
-OpenHarmony allows installation of applications. To ensure the integrity and trustworthiness of the applications to be installed in OpenHarmony, the applications must be signed and their signatures must be verified.
-
-After developing an application and generating the installation package during the application development process, you must sign the installation package to prevent it from being tampered with when released on devices. The OpenHarmony application integrity verification module provides the signing tool, specifications for generating the signing certificate, and required public key certificate for you to sign the application packages. A public key certificate and a corresponding private key are preset in OpenHarmony to ease your operation. You need to replace the public key certificate and private key in your commercial version of OpenHarmony.
-
-In the application installation process, the OpenHarmony application framework subsystem installs applications. Upon receiving an application installation package, the application framework subsystem parses the signature of the installation package, and verifies the signature using the application integrity verification APIs. The application can be installed only after the verification is successful. During the verification, the application integrity verification module uses the preset public key certificate to verify the signature.
-
-#### Device Authentication and HUKS
-
-A unified device binding and authentication solution that covers 1+8+N devices is available. Generally, device authentication provides support for cross-device communication implemented by DSoftBus, rather than directly interacting with applications. Device authentication provides the following functionalities:
-
-- Building and maintaining unified trust relationship for a group of devices using different accounts 
-
-  Devices with different accounts can set up a local trust group after a trust relationship is built by certain means such as scanning a QR code. Services can call APIs to query the group information.
-
-- Implementing unified device authentication 
-
-  A unified authentication solution is provided to discover devices and perform connection authentication and key agreement for encrypted, end-to-end sessions through DSoftBus for the devices in a trust group.
-
-HUKS provides credentials for device authentication and algorithms for key agreement protocols.
-
-#### Data Transfer Management
-
-In OpenHarmony, the data transfer management module provides cross-device data transfer management and control policies for distributed services. The data transfer management module defines a sef of APIs to provide management and control policies for cross-device data transfer and obtain the highest risk level of data to be sent to the peer device.
-
-## Repositories Involved<a name="section155556361910"></a>
-
-Security subsystem
-
-base/security