Logo
NeoArc Studio

Data Modelling with the Project Model

Define entities, properties, relationships, and key roles in the central data model (model.neoarc). Create ERD views and graph views to visualise the model for different audiences and database platforms.

Data modelling in NeoArc Studio centres on the project model (model.neoarc), a single file that defines all entities, properties, relationships, and constraints. The model uses the GraphDocument format with isProjectModel: true and authoringMode: "graph-db". All structural editing happens in the model editor; views are read-only representations that derive their data from this single source of truth.

The Central Model

The model file lives at the project workspace root, configured in project.neoarc via modelConfig.modelFilePath (defaults to model.neoarc). It stores entities as graph nodes and relationships as graph edges.

Entities
Graph nodes with labels, properties, key roles, constraints, and governance metadata.
Relationships
Graph edges with labels, cardinality (10 cardinality values), direction, and edge properties.
Groups
Logical subdomains that organise entities visually with convex hull rendering.
Abstract Types
12 database-agnostic types: string, integer, float, decimal, boolean, date, datetime, uuid, json, text, binary, enum.
Key Roles
6 key role types: primary (PK), foreign (FK), natural (NK), surrogate (SK), composite-part (CP), none.
Projections
Multi-domain projections: persistence, search, API, and custom projections per property.

Entity Properties

Each entity node contains an array of properties. Properties use abstract types that are database-agnostic; concrete types are resolved at view time via database profiles.

FieldDescription
nameProperty name (e.g. firstName, orderId)
typeAbstract type: string, integer, float, decimal, boolean, date, datetime, uuid, json, text, binary, enum
keyRoleKey semantics: primary, foreign, natural, surrogate, composite-part, none
requiredWhether the property is required
nullableWhether null values are permitted
uniqueUnique constraint
indexedWhether the property is indexed
defaultValueDefault value expression
maxLength / minLengthString length constraints
maxValue / minValueNumeric range constraints
patternRegular expression validation pattern
enumValuesAllowed values for enum types
descriptionDocumentation for the property
fkResolutionForeign key target: targetNodeId, targetPropertyName, showEdge
governanceClassification, retention policy, compliance notes, encryption, access restriction
projectionsPersistence, search, API, and custom projection configurations

Key Roles

Key roles express the identity semantics of a property. They are intrinsic to the field, not inferred from relationships.

RoleIndicatorDescription
primaryPKCanonical identifier for the entity
foreignFKReferences another entity's key (resolved via fkResolution)
naturalNKBusiness-meaningful identifier (e.g. email, tax number)
surrogateSKSystem-generated identifier (e.g. UUID, auto-increment)
composite-partCPParticipates in a composite key
none(none)No key role (default)

Abstract Types

The model uses 12 abstract types. These map to concrete database types via database profiles and to search index types via search profiles.

Abstract TypeDescription
stringVariable-length character data
integerWhole number
floatFloating-point number
decimalFixed-precision decimal number
booleanTrue/false value
dateDate without time
datetimeDate with time
uuidUniversally unique identifier
jsonStructured JSON data
textLarge/unbounded text
binaryBinary data
enumEnumerated set of allowed values

Creating Views from the Model

The model supports three types of read-only views. Each view references the model via modelFilePath and selects which entities to include via includedEntityIds.

View TypeFile ExtensionLayoutProfile TypeUse Case
ERD View.erd-view.jsonTabular (entity tables with columns)Database profilePhysical/logical data models for specific database vendors
Graph View.graph-view.jsonForce-directed (circles and edges)Database profileConceptual/domain models, graph database schemas
Search View.search-view.jsonTabular (search index fields)Search profileSearch index configurations for Azure AI Search, Elasticsearch, etc.

Conceptual, Logical, and Physical Distinction

The conceptual/logical/physical distinction is achieved through view configuration and database profile selection, not separate model files.

Validation

The model editor validates entities against 18 rules grouped into three categories.

CategoryRulesDescription
StructuralAlways enforcedInvalid references, corrupt identifiers
Semanticgraph-db modeUnnamed relationships, missing properties
Domaingraph-db modeMissing primary keys, orphan nodes, circular dependencies, naming conventions

Best Practices

Define Entities in the Model
All entity definitions belong in model.neoarc. Views are for visualisation, not data entry.
Use Groups for Subdomains
Organise entities into groups representing bounded contexts or functional areas.
One Model, Multiple Views
Create targeted views for different audiences: SQL Server ERD for DBAs, graph view for architects, logical ERD for design review.
Use Governance Metadata
Tag sensitive properties with classification levels, retention policies, and compliance notes.
Resolve Foreign Keys Explicitly
Populate fkResolution on FK properties to generate visible edges in views and enable cross-entity navigation.
Version with Git
The model and all views are JSON files that store cleanly in version control.