Entity-Component System
Data becomes powerful when it is granular, transparent, consistent, and accessible. With the set of tools below, you can begin to unlock more value in your data, complementing and moving beyond what you can do in the limited world of opaque file-based data.
Data Exchanges enable you to access and manipulate data with these notions in mind through extensive Data and Eventing APIs that leverage a common set of building blocks called Entities.
Overview
Our data platform architecture is based on the Entity-Component System (ECS) pattern. ECS is typically used in 3D imaging and video games. It follows the principle of composition over inheritance and hierarchy.
Core advantages of ECS include:
- A data-oriented design approach
- Decoupled data and logic, promoting better memory storage
- More efficient access to data for artificial intelligence
- Better modularity and parallelization
- Improved performance
ECS data-oriented approach echoes Autodesk’s own data-oriented shift: with data at the center, we can make data more transparent, modular, and accessible.
Entities
Our Data APIs let you access data that is built from a standard set of building blocks (entities) with a consistent set of behaviors so that you can manipulate your data no matter how it is organized. By combining entities into custom configurations, you can design efficient, accessible data solutions. Entities include the following:
- Components
- Assets
- Relationships
- Exchanges
- Collections
- Revisions
- Snapshots
To walk through a specific application of these concepts within the context of Data Exchanges, see REST API Tutorials 3.
Components
Components are logical groups of properties. Properties stored within components can include anything from a name (for example, a string of “Warm Roof – Timber” that corresponds to object’s name) to a specific value (for example, a float64 of “0.3” that corresponds to the roof thickness).
Assets
Assets are logical groups of components. Based on the type of components it contains, assets can be specialized in grouping other assets or storing design properties, instance properties or binary, geometry and render-style related.
Relationships
A relationship is a link between assets. There is often some sort of directionality implied (like a “from” and a “to”” or a “contains” and a “contained-by”).
Relationships use components to define the type of relationship. The components contain properties that provide critical metadata for understanding the relationship.
Exchanges
Assets are grouped into exchanges. Assets within an exchange might have various relationships to other assets in the same exchange.
Collections Project
A collection represents your projects. Collections are important organizational tools. You can manage access to your data by collection. You can also restrict the scope of your searches to a particular collection for greater efficiency.
Revisions
Every change made to an entity (asset, relationship) is tracked as a Revision. If an entity is modified, it will not be replaced. Instead, a copy of it will be created with modified data and new revision. The old entity and the new one will have the same id, but each one will have a distinct revision id.
Snapshot
Each exchange will have one corresponding snapshot, no matter how many versions of the exchange exist. Any changes made to an exchange will be captured as a new snapshot revision. The snapshot can be seen as the pointer to the graph, while snapshot revisions can be seen as the markers or pointers to different states of the graph.
Graph Data Models
Data Exchanges leverage a largely graph-based data model. Traditional hierarchical and relational data models were designed to optimize the performance of database queries through carefully constructed indexes and sophisticated JOIN table logic. The drawback of the structure is that it is inflexible by nature, and performance diminishes as the volume of data increases.
A graph data model is characterized by individual data assets associated with other data assets through defined relationships. This results in a flexible system that can readily adapt to changing requirements by adding new entities, new labels, and new relationships as needed without interfering with existing functionality. Your performance remains consistent or even improves because you tend to query only a specific subset of the graph at one time, rather than the entire database.
Nodes, Edges, Assets, and Relationships
When you think about the graph structure of Data Exchanges, you can imagine the assets and the relationships those assets might have to each other. When you query for assets through our APIs, the results use more general terminology – nodes and edges. Nodes represent the assets in your data model, and edges represent the connections between the assets – for instance, the relationships.
