modscape 0.8.0 → 0.9.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.ja.md +81 -94
- package/README.md +84 -98
- package/package.json +1 -1
- package/src/dev.js +5 -3
- package/src/index.js +1 -1
- package/src/templates/rules.md +64 -68
- package/visualizer/package.json +1 -1
- package/visualizer-dist/assets/index-BQzAkOWB.js +40 -0
- package/visualizer-dist/assets/index-p_KeFJzm.css +1 -0
- package/visualizer-dist/index.html +2 -2
- package/visualizer-dist/assets/index-BEPV6FcC.js +0 -40
- package/visualizer-dist/assets/index-CS5ByLY6.css +0 -1
package/src/templates/rules.md
CHANGED
|
@@ -2,86 +2,82 @@
|
|
|
2
2
|
|
|
3
3
|
## 1. Modeling Strategy
|
|
4
4
|
<!-- Define your modeling methodology here. Example: Data Vault 2.0, Star Schema, 3NF -->
|
|
5
|
-
-
|
|
6
|
-
-
|
|
5
|
+
- **Dimensional Modeling (Star Schema)**: Recommended for most analytical use cases.
|
|
6
|
+
- Use `appearance.type: fact` for central measurement tables.
|
|
7
|
+
- Use `appearance.type: dimension` for descriptive attribute tables.
|
|
8
|
+
- **Data Vault 2.0**: For highly scalable enterprise data warehouses.
|
|
9
|
+
- Use `appearance.type: hub`, `link`, or `satellite`.
|
|
7
10
|
|
|
8
|
-
## 2.
|
|
9
|
-
|
|
11
|
+
## 2. Analytics Metadata
|
|
12
|
+
Modscape supports attributes to communicate the "Story" and "Grain" of your data to humans and AI agents.
|
|
13
|
+
|
|
14
|
+
### Fact Table Strategies (`appearance.strategy`)
|
|
15
|
+
- `transaction`: Standard fact table where one row = one event (e.g., an order).
|
|
16
|
+
- `periodic`: Snapshot fact table capturing state at set intervals (e.g., monthly inventory).
|
|
17
|
+
- `accumulating`: Fact table updated as a process moves through milestones (e.g., order → shipping → delivery).
|
|
18
|
+
- `factless`: Tables that record the occurrence of an event without numeric measures (e.g., event attendance).
|
|
19
|
+
|
|
20
|
+
### Dimension SCD Types (`appearance.scd`)
|
|
21
|
+
- `type0`: Fixed dimensions (no changes allowed).
|
|
22
|
+
- `type1`: Overwrite changes (no history maintained).
|
|
23
|
+
- `type2`: Add new row for changes (full history with timestamps).
|
|
24
|
+
- `type3`: Add new column for changes (partial history).
|
|
25
|
+
- `type6`: Hybrid approach (1+2+3).
|
|
26
|
+
|
|
27
|
+
### Column Additivity (`logical.additivity`)
|
|
28
|
+
- `fully`: Can be summed across all dimensions (e.g., sales amount). Displays as `Σ`.
|
|
29
|
+
- `semi`: Summing is valid only across some dimensions (e.g., bank balance - can't sum across time). Displays as `Σ~`.
|
|
30
|
+
- `non`: Summing is never valid (e.g., unit price, ratios). Displays as `⊘`.
|
|
31
|
+
|
|
32
|
+
### Metadata Columns (`logical.isMetadata`)
|
|
33
|
+
Mark technical or audit columns (like `created_at`, `dbt_updated_at`) with `isMetadata: true` to display a `🕒` icon.
|
|
34
|
+
|
|
35
|
+
## 3. Naming Conventions
|
|
10
36
|
- **Casing**: [Select one: snake_case / UPPER_SNAKE_CASE / camelCase]
|
|
11
37
|
- **Prefixes**: (e.g., `f_` for facts, `d_` for dimensions)
|
|
12
38
|
- **Suffixes**: (e.g., `_id` for primary keys, `_h` for history tables)
|
|
13
39
|
|
|
14
|
-
##
|
|
15
|
-
- String:
|
|
16
|
-
- Numeric:
|
|
17
|
-
- Date/Time:
|
|
18
|
-
|
|
19
|
-
## 4. YAML Schema Reference
|
|
20
|
-
Use this structure for `model.yaml`:
|
|
40
|
+
## 4. Standard Data Types
|
|
41
|
+
- String: Varchar, Text
|
|
42
|
+
- Numeric: Integer, Decimal, Float
|
|
43
|
+
- Date/Time: Timestamp, Date
|
|
21
44
|
|
|
45
|
+
## 5. YAML Schema Reference
|
|
22
46
|
```yaml
|
|
23
47
|
tables:
|
|
24
|
-
- id:
|
|
25
|
-
name:
|
|
26
|
-
appearance:
|
|
27
|
-
type:
|
|
28
|
-
|
|
29
|
-
color: "#fbbf24" # Optional: Hex color override
|
|
48
|
+
- id: fct_orders
|
|
49
|
+
name: Orders Fact
|
|
50
|
+
appearance:
|
|
51
|
+
type: fact
|
|
52
|
+
strategy: transaction # transaction | periodic | accumulating | factless
|
|
30
53
|
conceptual:
|
|
31
|
-
description: "
|
|
32
|
-
tags: ["WHO", "
|
|
54
|
+
description: "Records of customer purchases"
|
|
55
|
+
tags: ["WHO", "WHEN", "HOW MUCH"]
|
|
33
56
|
columns:
|
|
34
|
-
- id:
|
|
35
|
-
logical:
|
|
36
|
-
|
|
37
|
-
|
|
38
|
-
|
|
39
|
-
|
|
40
|
-
isForeignKey: true/false
|
|
41
|
-
physical: # Optional
|
|
42
|
-
name: "physical_name"
|
|
43
|
-
type: "DB_TYPE"
|
|
44
|
-
constraints: ["NOT NULL", "UNIQUE"]
|
|
45
|
-
sampleData: # Optional: 2D array mapped to columns by index
|
|
46
|
-
- ["value1", "value2"] # Corresponds to first and second column
|
|
47
|
-
- ["value3", "value4"]
|
|
48
|
-
|
|
49
|
-
domains: # Optional: Group tables into visual containers
|
|
50
|
-
- id: domain_id
|
|
51
|
-
name: Domain Name
|
|
52
|
-
description: "Domain purpose"
|
|
53
|
-
tables: ["table_id_1", "table_id_2"]
|
|
54
|
-
color: "rgba(59, 130, 246, 0.05)" # Optional background color
|
|
57
|
+
- id: order_id
|
|
58
|
+
logical: { name: ID, type: Int, isPrimaryKey: true }
|
|
59
|
+
- id: amount
|
|
60
|
+
logical: { name: Amount, type: Decimal, additivity: fully } # fully | semi | non
|
|
61
|
+
- id: updated_at
|
|
62
|
+
logical: { name: Updated At, type: Timestamp, isMetadata: true }
|
|
55
63
|
|
|
56
|
-
|
|
57
|
-
|
|
58
|
-
|
|
59
|
-
|
|
60
|
-
|
|
61
|
-
|
|
62
|
-
|
|
63
|
-
|
|
64
|
+
- id: dim_customers
|
|
65
|
+
name: Customers Dim
|
|
66
|
+
appearance:
|
|
67
|
+
type: dimension
|
|
68
|
+
scd: type2 # type0 | type1 | type2 | type3 | type6
|
|
69
|
+
columns:
|
|
70
|
+
- id: customer_id
|
|
71
|
+
logical: { name: ID, type: Int, isPrimaryKey: true }
|
|
72
|
+
- id: valid_from
|
|
73
|
+
logical: { name: Valid From, type: Timestamp, isMetadata: true }
|
|
64
74
|
```
|
|
65
75
|
|
|
66
|
-
##
|
|
67
|
-
|
|
68
|
-
|
|
76
|
+
## 6. Layout Management
|
|
77
|
+
- **Visualizer Priority**: The GUI handles layout through drag-and-drop.
|
|
78
|
+
- **AI Agent Responsibility**: When creating new entities, assign initial (x, y) coordinates to place them near related tables.
|
|
69
79
|
|
|
70
|
-
|
|
71
|
-
- **Naming Conventions**: The filename (without extension) is used as the "model slug" in the visualizer (e.g., `customer.yaml`, `billing.yaml`).
|
|
72
|
-
- **Common Structure**: Maintain a consistent `layout` format across all files. AI agents MUST respect the existing `layout` section when making updates.
|
|
73
|
-
|
|
74
|
-
## 5. Layout Management
|
|
75
|
-
- **Visualizer Priority**: The GUI handles layout through drag-and-drop, writing to the `layout` section.
|
|
76
|
-
- **AI Agent Responsibility**: When creating new entities or domains, you MUST assign initial coordinates (x, y) to place them logically near related tables. Do NOT leave new entities at (0, 0) or stacked on top of each other.
|
|
77
|
-
- **Preservation**: Do NOT modify existing coordinates unless a "Cleanup" or "Re-layout" is explicitly requested.
|
|
78
|
-
|
|
79
|
-
## 6. The Golden Rules
|
|
80
|
+
## 7. The Golden Rules
|
|
80
81
|
- When updating `model.yaml`, always self-audit against these rules.
|
|
81
|
-
- Set appropriate `appearance.type`
|
|
82
|
-
-
|
|
83
|
-
- If user instructions are ambiguous, propose the best design based on these rules.
|
|
84
|
-
|
|
85
|
-
## 7. Strictly Forbidden
|
|
86
|
-
- Do not create custom data types not defined in this document.
|
|
87
|
-
- Do not destroy or overwrite the `layout` section without assigning new, logical coordinates.
|
|
82
|
+
- Set appropriate `appearance.type` and `strategy`/`scd` for new tables.
|
|
83
|
+
- Use `additivity` for numeric measures to inform BI tools and analysts.
|