This is an automated email from the ASF dual-hosted git repository. warren pushed a commit to branch main in repository https://gitbox.apache.org/repos/asf/incubator-devlake-website.git
commit 8e05a9ba490fc5c7270eb11d0375745ddccf8837 Author: Startrekzky <[email protected]> AuthorDate: Wed Dec 7 19:46:34 2022 +0800 docs: update schema docs --- docs/DataModels/RawLayerSchema.md | 2 +- docs/DataModels/SystemTables.md | 4 ++-- docs/DataModels/ToolLayerSchema.md | 4 ++-- docs/Overview/Architecture.md | 2 +- 4 files changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/DataModels/RawLayerSchema.md b/docs/DataModels/RawLayerSchema.md index 07b094dea..e2336e5ca 100644 --- a/docs/DataModels/RawLayerSchema.md +++ b/docs/DataModels/RawLayerSchema.md @@ -26,4 +26,4 @@ Raw layer tables start with a prefix `_raw_`. Each plugin contains multiple raw - _raw_jira_board_issues - ... -Normally, you do not need to use these tables, unless you have use cases above. +Normally, you do not need to use these tables, unless you have one of the above use cases. diff --git a/docs/DataModels/SystemTables.md b/docs/DataModels/SystemTables.md index 9b128e42f..6fea769ad 100644 --- a/docs/DataModels/SystemTables.md +++ b/docs/DataModels/SystemTables.md @@ -7,7 +7,7 @@ sidebar_position: 4 ## Summary -This document describes Apache DevLake's data models of its own entities. +This document describes Apache DevLake's data models of its own entities. These tables are used and managed by the Devlake framework. ## Use Cases @@ -25,4 +25,4 @@ These tables start with a prefix `_devlake`. Unlike raw or tool data tables, Dev - _devlake_subtasks - ... -Normally, you do not need to use these tables, unless you have use cases above. +Normally, you do not need to use these tables, unless you have one of the above use cases. diff --git a/docs/DataModels/ToolLayerSchema.md b/docs/DataModels/ToolLayerSchema.md index 17c442502..889e1a23c 100644 --- a/docs/DataModels/ToolLayerSchema.md +++ b/docs/DataModels/ToolLayerSchema.md @@ -9,7 +9,7 @@ sidebar_position: 2 This document describes Apache DevLake's tool layer schema. -Referring to DevLake's [architecture](../Overview/Architecture.md), the Tool layer extracts raw data from JSONs into a relational schema that's easier to consume by analytical tasks. Each DevOps tool would have a schema that's tailored to their data structure, hence the name, the Tool layer. +Referring to DevLake's [architecture](../Overview/Architecture.md), the Tool layer extracts raw data from JSONs into a relational schema that's easier to consume by analytical tasks. Each DevOps tool would have a schema that's tailored to its data structure, hence the name, the Tool layer. ## Use Cases @@ -25,4 +25,4 @@ Tool layer tables start with a prefix `_tool_`. Each plugin contains multiple to - _tool_jira_board_issues` - ... -Normally, you do not need to use tool layer tables, unless you have use cases above. +Normally, you do not need to use tool layer tables, unless you have one of the above use cases. diff --git a/docs/Overview/Architecture.md b/docs/Overview/Architecture.md index 47bd4b48e..66c9fc984 100755 --- a/docs/Overview/Architecture.md +++ b/docs/Overview/Architecture.md @@ -27,7 +27,7 @@ A DevLake installation typically consists of the following components: A typical plugin's dataflow is illustrated below: 1. The Raw layer stores the API responses from data sources (DevOps tools) in JSON. This saves developers' time if the raw data is to be transformed differently later on. Please note that communicating with data sources' APIs is usually the most time-consuming step. -2. The Tool layer extracts raw data from JSONs into a relational schema that's easier to consume by analytical tasks. Each DevOps tool would have a schema that's tailored to their data structure, hence the name, the Tool layer. +2. The Tool layer extracts raw data from JSONs into a relational schema that's easier to consume by analytical tasks. Each DevOps tool would have a schema that's tailored to its data structure, hence the name, the Tool layer. 3. The Domain layer attempts to build a layer of abstraction on top of the Tool layer so that analytics logics can be re-used across different tools. For example, GitHub's Pull Request (PR) and GitLab's Merge Request (MR) are similar entities. They each have their own table name and schema in the Tool layer, but they're consolidated into a single entity in the Domain layer, so that developers only need to implement metrics like Cycle Time and Code Review Rounds once against the domain la [...] ## Principles
