Nervatura

Object Model

Overview

It is a general open-data model, which can store all information generated in the operation of a usual corporation. This covers all manufacturer, retailer and service companies (or governmental units) where the business operation can be defined and described within a GOODS (items, services to be sold, provided) - CLIENT (the recipient of goods) - RESOURCE (assets used to produce the goods) triangle.

The open-data principle regulates the access to our business data. The point is the logic of the data storage. It means that the data are defined for storage so, that those are compliant with an open data-model which could be accessed and interpreted by anyone. It doesn’t concern the physical storage of the data, that can be implemented according to one’s needs. However it should ensure that data can be managed safely according to published description. Retrieving, new data creation, possibility to export the entire data structure should be provided.

What are the main advantages of open-data applications?

safety: provided one’s have proper usage rights and physical access to a database, then will be able to interpret and process the data correctly without any help or permission from a third party. Information in the data becomes independent of any management system, its treatment is not tied to specific programs or technologies.
efficiency and cost reduction: the business management system can be developed and diversified in accordance with one’s needs. There is no need and pressure to be tied to a solution of any vendor, the most appropriate tools and programs can be selected for all tasks. The only criteria is that selected applications should be able to communicate and exchange data with each other or with a central database according to the open-data description. The elements of the system can at any time be flexibly developed or new ones added by choosing the best offers available on the market.

It is located between the application surfaces that are using and creating the data and the real data storage layer. It defines logical objects; data is stored in these freely defined attributes and in relations between them. Its flexible structure allows defining new properties or assigning events to our objects.

The number of objects is minimal, their structure is simple. It has an easy to learn, clear and straightforward logic. However it is capable to store the required data in structures. It ensures the possibility to attach defined type metadata of any kind to each object and also makes the objects linkable to each other arbitrarily.

The data model is independent from data storage layer. The data storage can be implemented in any way or with any device but as a main requirement the user of the data model must not sense this at all.

Data structure

Nervatura's data structure follows a hybrid design model, which means it combines the advantages and technology of SQL and NoSQL databases for efficiency. SQL databases have the advantage of being vertically scalable, ACID-compliant and efficient for complex queries and transactions. Document-based, NoSQL databases have a flexible schema and they handle large amounts of data and high-velocity workloads better.

Nervatura is built on SQL database foundations. It contains a small number of tables, each of which has a uniform structure. The goal during the design was, in addition to easy transparency, the stability of the data structure. The content of the tables follows the business logic and covers all important elements of an average business record. They represent the logical groups that store information in business processes with their data content and their relationships to each other. It uses SQL capabilities to describe their relationships and ensure their integrity. The JSON data fields embedded in the tables are responsible for the flexible, easily modifiable or expandable description and storage of the properties of business objects.

id Database primary key. Database dependent serial number type. Its value is unique only at table level and may change during data migrations.
code Database independent, short but unique external key. If not specified, it is generated on creation. It cannot be modified after creation. The code structure contains information about the type of data, its creation time, and its order:
3 length prefix + UNIX Time stamp + N + current ID. Example: CUS1731101982N123
fk_code To simplify searches and make data portability easier, database tables also use code field as a foreign key instead of the id field. Example: customer_code.
idx_field To optimize searches for greater speed and performance, some data containing important or frequently used information has been defined directly as SQL fields instead of JSON metadata. Example: customer_name, valid_from, direction.
model_meta Schema validated data stored in JSON data type. The existence and type of the data defined here are always checked and guaranteed by the backend processing. The data stored here can be flexibly changed without modifying the SQL database, but their modification is always tied to the change of the program version and their backward data compatibility is ensured. Example: customer_meta.
address(es), contact(s) and event(s) are special, complex schema validated metadata objects.
model_map Flexible key-value map for additional user-defined metadata. The value is any json type. Client programs can use them freely to store any data, but the backend cannot verify the type and existence of their data. Regardless, their type, possible data content, description, and visibility can be defined in the config data, which the Nervatura Client can use when displaying them. Example: customer_map.

Objects

Such pre-defined functional roles which can have any type of attributes, events can be attached to them as well as their elements can be attached to elements of other objects.

Base object

CUSTOMER - all external partners of the company, including the buyer, consumer and supplier side

PRODUCT - all raw materials, semi-finished and end-products that are related to our activity (as customer or vendor), produced by us as a manufacturer or offered as service

EMPLOYEE, TOOL, PLACE resources which are available for executing the activity and they contribute to it. These can be human resources (EMPLOYEE), material devices, tools, machines (TOOL) or financial, potentially infrastructural conditions such as warehouses, bank account, petty cash (PLACE)

Transaction

Transaction is such a sort of event to which at least two base objects are joined.

An event is always attached to a given object. As a further event feature another base object can be specified but it’s just an optional additional data in this case. Events are stored as part of the given property group (object) in its table. Example: customer events.

In the transactions the relation between the base objects is an indispensable and essential component of the given event. The transaction doesn’t belong to any of the base objects but the base objects are joined to a transaction. From these some base objects might be optional components but at least two should be indispensable part of it.

The most common object pair is the customer and product relationship (e.g.: offer, order, invoice) but any other combination is also possible, for example product-place (stock management), customer-tool (rental), employee-customer (worksheet) etc. Transactions can also be linked to each other or can “originate” from each other, for instance offer -> order -> inventory move -> invoice.

The object of transactions is the TRANS which contains the main data of transactions as well as the single object relations. ITEM object contains PRODUCT lines linked to transactions, PAYMENT object contains financial settlements, MOVEMENT object contains warehouse and tool movements.

Database structure and relations

Previous: Overview
Next: Installation