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.
@@ -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
- - [Enter methodology name here, e.g., Star Schema]
6
- - Maintain structure according to table roles (e.g., Fact/Dim, Hub/Sat).
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. Naming Conventions
9
- <!-- Define your naming rules here -->
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
- ## 3. Standard Data Types
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: table_id # Unique identifier
25
- name: Table Display Name (Logical)
26
- appearance: # Optional: Visual style
27
- type: hub # Predefined: hub, link, satellite, fact, dimension
28
- icon: "🌐" # Optional: Emoji override
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: "Business definition"
32
- tags: ["WHO", "WHAT", "WHEN", etc.]
54
+ description: "Records of customer purchases"
55
+ tags: ["WHO", "WHEN", "HOW MUCH"]
33
56
  columns:
34
- - id: column_id
35
- logical:
36
- name: "Column Name"
37
- type: "Data Type"
38
- description: "Optional description"
39
- isPrimaryKey: true/false
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
- relationships:
57
- - from: { table: table_id, column: column_id }
58
- to: { table: other_id, column: column_id }
59
- type: "one-to-many" # or "one-to-one", "many-to-many"
60
-
61
- layout: # Automatically managed by the visualizer OR updated by AI Agent
62
- table_id: { x: 100, y: 100 }
63
- domain_id: { x: 50, y: 50, width: 600, height: 400 }
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
- ## 📁 File Management
67
-
68
- For larger projects, it is recommended to **split the model into multiple YAML files by domain** rather than keeping everything in a single file.
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
- - **Directory Management**: By specifying a directory with `modscape dev models/`, the visualizer will automatically scan and manage all YAML files within that folder.
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` (fact, dimension, hub, link, satellite) for new tables.
82
- - When defining relationships, ensure consistency between `from` and `to` tables.
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.
@@ -1,7 +1,7 @@
1
1
  {
2
2
  "name": "visualizer",
3
3
  "private": true,
4
- "version": "0.8.0",
4
+ "version": "0.9.0",
5
5
  "type": "module",
6
6
  "scripts": {
7
7
  "dev": "vite",