Appearance
Databases and data modelling
The data model describes the information an application manages. In NOOSAdmin, table definitions provide the structure around which data collection, exploration and processing are arranged. The platform can work with an existing database, allowing the application's existing information model to inform that structure.
Database connectivity
The platform's supplied capability overview identifies the following storage systems and services as available options. They are listed alphabetically for reference; inclusion does not imply identical configuration or capabilities across them.
| Storage systems and services |
|---|
| AWS RDS Data API |
| Azure Cosmos DB |
| BigQuery |
| ClickHouse |
| Cloudflare D1 |
| Cloudflare Durable Objects |
| Firebird |
| libSQL/sqld |
| MariaDB |
| Microsoft SQL Server |
| Neon |
| Oracle |
| PlanetScale |
| PostgreSQL |
| SQLite |
| SurrealDB |
| TiDB Cloud |
| Xata |
This list includes databases, hosted services and access interfaces. The relational table mapping described below applies to the relational data model; it should not be assumed to describe every listed storage option in the same way.
Operational and application data
NOOSAdmin can use a separate database for application data from the database holding its own operational data. This provides a deployment option for projects whose domain records need to reside separately from platform operation information.
When planning a deployment, identify where the project data resides and whether a separate application database is required. Database selection and connection configuration form part of that deployment's technical setup.
Tables, fields and relationships
For relational databases, NOOSAdmin tables have a one-to-one correspondence with underlying database tables. Fields describe the values a record contains, while relationships connect records across tables.
The model should reflect the information the application needs to collect, examine and produce. Relationships are particularly useful when users need to move from one kind of record to another, such as from equipment information to its measurements. NOOSAdmin's explorers support linked table views for following related information.
Schema configuration and the builder
Each table's schema is supplied through runtime configuration in JSON files. JSON is a structured text format used to express configuration. A builder is also provided for working with schema definitions.
Data administrators can create and edit table definitions, including names, fields and relationships. These definitions describe the structures available to the application. The guide covers their purpose; the exact configuration properties and the handling of database changes belong to implementation-specific instructions.
The model across the platform
A table can participate in several parts of an application. Ingress endpoints store submitted data in tables after validation. Explorers present records and their relationships. Processors read records, perform calculations and can store results in other tables. Runner outputs can also be written to tables for subsequent use in queried presentations.
NOOSAdmin also provides API generation based on a data model or existing database schema. Conceptually, this makes the model a basis for programmatic access as well as user-facing functionality. Particular routes, operations and request formats require the API details of the deployment.
The relationships between these features make data modelling an early application design decision. A useful model accounts for incoming information, the results the application will produce and the connections users need to explore.
Illustrative equipment model
An equipment-monitoring application could use the following tables. Their names and example fields are design choices for this scenario, not predefined NOOSAdmin tables or configuration syntax.
| Table | Purpose | Example information |
|---|---|---|
| Equipment | Describe monitored assets. | Equipment identifier, label and location. |
| Measurements | Store readings associated with equipment. | Equipment reference, observation time, measurement type, value and unit. |
| Analysis results | Store outputs from an analysis model. | Equipment reference, analysis time and result values. |
Each measurement would refer to the equipment it describes. For this example, each analysis result would also refer to a piece of equipment. This arrangement would let a user inspect an asset, follow its readings and consult the associated results.
An application could add a summary table if a processor needs to store calculated values for dashboards. Keeping those results in a table makes them available to the same exploration and presentation capabilities used for other records.
Before configuring the model, the team should agree what a record represents, how records refer to one another and which results need to be retained. These choices give ingress and processing a clear destination and help make the resulting information understandable to users.