Logo
NeoArc Studio

Data Model

The central model file is the single source of truth for every entity, relationship, and property in a NeoArc project. 12 abstract database-agnostic types, 6 key roles, per-property projections for persistence, search, and API, governance classifications (PII, confidential, retention policies), shared property sets with live inheritance, 18 validation rules, and import/export across 39 formats.

The data model (model.neoarc) is the foundation of everything in NeoArc Studio. Every entity, relationship, and property is defined here. API schemas, database DDL, search index mappings, ERD diagrams, graph views, governance documentation - all of these are projections of this single file. When you change the model, every downstream artefact reflects the change. When you break a contract, the validation engine tells you immediately. The model is the single source of truth that makes model-first architecture possible.

The model uses 12 database-agnostic abstract types that map to any vendor via profiles. Each property carries three independent projection configurations (persistence, search, API), governance metadata (data classification, encryption, retention), and validation constraints. Shared property sets provide live inheritance for common patterns. 18 validation rules check for errors at design time.

Key Capabilities

Model Structure

The model organises data around a small set of core concepts.

Property System

Abstract Types

Properties use 12 abstract types that are database-agnostic. Database profiles map each abstract type to a concrete type for a specific vendor (e.g. string maps to NVARCHAR in SQL Server, TEXT in PostgreSQL). Parameterised templates such as NVARCHAR({maxLength}) use property constraints to produce the final DDL type.

Key Roles

Every property has a key role that describes its function in the entity's identity and relationships.

Derivation Modes

Properties support three derivation modes that indicate how values are produced.

Projections

Each property carries per-channel projections that control how it appears in different output targets. The property table editor offers four lens modes: schema (the base definition), persistence, search, and API.

Governance

Validation

The model editor runs 18 validation rules across three categories. Rules are mode-aware: structural rules always apply, semantic rules apply in conceptual and graph-db modes, and domain rules apply only in graph-db mode.

Data Views

Data Views are interactive, model-derived visualisations that display entities as nodes on a force-directed graph canvas with edges inferred from relationships. Click any node to open the Entity Overlay with the full property table. Two view modes target different concerns.

Groups and Subdomains

Entities are organised into groups that represent logical subdomains. Each group has a name, a colour, and a list of member entities. The editor renders groups as convex hull boundaries around their members, with group-aware physics in the force simulation to keep related entities together. The entity picker supports group filtering to narrow selection when working with large models (the 50-entity cap per view makes this essential for navigation).

Entity Lifecycle Management

The model supports lifecycle tagging on every entity. Each entity carries a status of active, planned, or deprecated. When an entity is deprecated, it can be linked to its replacement via a replaced-by edge (the reverse evolved-from edge is created automatically). The repoint wizard migrates downstream references from deprecated entities to their replacements. Deprecation impact reports show remaining reference counts, and the safe-to-delete report confirms when deprecated entities can be removed.

Import and Export

The data model supports importing entities from 15 external file formats and exporting to 24 schema and DDL formats.

Getting Started

Begin by creating a project in NeoArc Studio, which generates the model.neoarc file automatically. Add entities manually, or import them from existing SQL DDL, diagram files, or other schema formats. Define properties with abstract types and key roles, then create views to visualise specific subsets of the model.