Model-Derived Views
Data Views are lightweight projections of the central model. They store only layout positions and style overrides. Entity data, properties, types, and relationships come from the model at render time, so views can never drift from the source of truth.
A common failure mode in architecture documentation is the diagram that was correct when it was drawn but has since drifted from reality. An entity was renamed in the database, but the ERD still shows the old name. A property was added, but the diagram was not updated. The diagram becomes worse than useless - it actively misleads anyone who reads it.
NeoArc eliminates this problem by making views projections of the model rather than independent artefacts. A view does not store entity data. It stores a reference to the model entity, plus layout coordinates and optional style overrides. When the view renders, it reads entity data - properties, types, key roles, relationships - directly from the model. If a property is renamed in the model, every view that includes that entity shows the new name immediately. There is no sync step. There is no manual update. The view cannot disagree with the model because it reads from the model.
The Data View
A Data View is a force-directed graph canvas where model entities appear as interactive nodes. Each view has a single purpose defined by its view mode and profile.
Entity Overlay
The Entity Overlay is the standard way to inspect any node's properties. Click a node (or press Alt+Enter) to open a floating panel showing the full property table with incoming and outgoing relationship pills on either side. The overlay works identically in both the editor and the published viewer.
What Views Store vs. What They Read
Understanding the separation between stored and derived data is key to understanding why views cannot drift.
| Data | Stored in View | Read from Model |
|---|---|---|
| Entity name and label | - | Read from model entity at render time |
| Properties (name, type, constraints) | - | Read from model entity properties, including shared property sets |
| Key roles (PK, FK, NK, SK, CK) | - | Read from model entity property key roles |
| Relationships and cardinality | - | Read from model edges |
| Governance metadata | - | Read from model entity property governance settings |
| Entity selection | List of included entity IDs | - |
| Node positions (x, y) and pin state | Stored per entity | - |
| Style overrides (fill, border, text colour) | Stored per entity | - |
| View mode (persistence or search) | Stored in view | - |
| Database or search profile assignment | Profile ID stored in view | - |
| Force simulation settings (node spacing) | Stored in view | - |
| Groups and group colours | Stored in view (filtered from model groups) | - |
Persistence Mode
Persistence mode Data Views are for database architects and developers. The Entity Overlay displays ERD-style columns with types resolved through the selected database profile.
| Column | Content | Resolved Via |
|---|---|---|
| Key | PK, FK, NK, SK, CK badge | Model property key role |
| Field | Property name | Database profile naming convention |
| Type | Concrete database type | Database profile type mapping (e.g. string to NVARCHAR) |
| Nullable | YES/NO | Model property nullable flag |
| Unique | YES/NO | Model property unique flag |
| Default | Default value expression | Model property default value |
| FK Ref | Target entity and property | Model FK relationship |
| Constraints | Constraint list | Model property constraints |
| Index | Index name | Model property index |
| Comments | Description text | Model property description |
Search Mode
Search mode Data Views are for search engineers configuring index mappings. The Entity Overlay shows search-specific columns resolved through the selected search profile.
| Column | Content | Resolved Via |
|---|---|---|
| Key | Whether this field is the document key (Y/-) | Search projection key flag |
| Field | Index field name | Search profile naming convention |
| Type | Concrete search field type | Search profile type mapping |
| Searchable | YES/NO | Search projection searchable behaviour |
| Filterable | YES/NO | Search projection filterable behaviour |
| Sortable | YES/NO | Search projection sortable behaviour |
| Facetable | YES/NO | Search projection facetable behaviour |
| Retrievable | YES/NO | Search projection retrievable behaviour |
| Analyser | Analyser name or - | Per-profile override or base value |
| Boost | Boost value or - | Search projection boost value |
Each search field can also be expanded within the overlay for deep configuration detail: text analysis settings, vector search parameters, storage and performance options, query capabilities, sub-fields, and governance metadata. All values are read from the model property's search projection and resolved through the active search profile.
Multiple Views, Same Entities
A single model entity can appear in multiple Data Views simultaneously. A Customer entity might appear in a high-level persistence view with a SQL Server profile for the DBA, another persistence view with a PostgreSQL profile for the migration team, and a search view with an Elasticsearch profile for the search team. All views show the same entity data because they all read from the model. Each view applies its own profile for type and naming resolution.
Graph Canvas Features
All Data Views share the same interactive graph canvas with these capabilities.
| Feature | Description |
|---|---|
| Force-directed layout | Entities positioned by physics simulation with configurable node spacing via a slider control |
| Node pinning | Pin entities to fixed positions while letting unpinned entities flow naturally |
| Node search | Ctrl+F opens fuzzy search with ranked results (exact matches first, then prefix, then fuzzy). Camera pans to the current result as you type |
| Node spacing slider | Adjust the spacing between nodes in real time using the slider in the bottom-right corner |
| Style overrides | Per-entity colour, border colour, and text colour for visual differentiation |
| Groups and hulls | Entities in the same model group cluster together with semi-transparent group hulls |
| Semantic zoom | Three detail levels based on zoom: minimal (group hulls only), medium (labels and edges), full (all detail) |
| Minimap | Togglable 150x100px overview panel showing all nodes with viewport rectangle |