Ver.No: {{=response.verNo}}
General data model, which can store all information generated during the operation of a classic organization. This includes all manufacturer, retailer and service companies (or government units) which operation can be defined and described within a GOODS (we want to sell or we supply) – CLIENT (we work for) - RESOURCE (we possess for the task) triangle.
It is located between the applications, 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, perspicuous and usable logic. However it is capable to store the required data in structures. It ensures the possibility to attach defined type features 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. In the functions of implementation the concrete data storage can be realized by any optional method or device but as a main requirement the user of the data model must not sense this at all.
![]() |
Such pre-defined functional roles which can have any type of attributions, events can be attached to them as well as their elements can be attached to elements of other objects. |
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
TOOL, EMPLOYEE, 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)
All data that describes a given object, we want to attach to it as information. Some of them are pre-defined but further ones can freely be defined for any of the objects.
When using the Nervatura Data Interface (NDI) a feature of an object which has not existed before- is automatically generated when the first value is given. If we create a new feature in this way then its type is unidentifiable thus it will be automatically text. However by defining the exact type of certain features, we could easily ensure that the stored data is correct.
By using the DEFFIELD object we can define data storage features for other objects. Besides the classical data types (bool, integer, float, date, string, notes) these can contain list of values (valuelist), url links (urlink) or references to concrete components of other objects (customer, product, tool, employee, etc.).
When using NDI, values of features defined in this way can be set in the object component with the name of the feature and can be queried as well.
Through the FIELDVALUE object every defined feature of components of all objects can be queried.
Extended, generally time and interval bound object features. With the help of events we can make the static features of an object into dynamic so the feature of a given component is able to take various values at different times. An event can also be valid for a period of time, so having a start and an end date. Optional number of supplementary data of a given object can be attached to it as well as it can be grouped.
We can manage the events through the EVENT object. Beside the base object we can also assign events to projects.
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 granted but it's just an optional
additional data in this case.
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.
We can link additional data to transactions just as to events, but in contrary to events, here we don’t use the features of the linked base object but we can declare own, additional data. 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 device movements.
There are several options to link single objects. Usually the object
has the possibility of applying the one to one relation by default,
if it is required so by its type. In case of need the additional
data pointing to the proper type of object can also be generated at
any time.
For example we can set a customer type feature for
CUSTOMER object wherewith we can link a given customer to another
customer. With the same method one to many relations can also be
set, so in this case we can also link our customer to some other
customers. .
If any linked customer is also linked to an other customer it
results in a many to many relation.
LINK object can also be used to
set relations to objects. This way two objects can be linked without
giving further object features.
Several options are available for grouping the objects. Using supplementary data, further to data storage opportunities allows also grouping to a certain degree.
In the GROUPS object we can create groups by object types. If needed, further features can be defined for these groups. These can then be used for assignments of pre-defined values on a given object (for example type options), but through LINK object can also be used for creating classical one to many groups (for example customer of product groups).
Actually the PROJECT object can be applicable as the extension of GROUPS object. Surely it is possible to set additional data features here as well but at PROJECT object temporal extension is also possible, just like it is in case of events vs. features. Optionally it can have start or end date, we can also link it to customers or places. Projects can also have their own events as well as any transaction can be linked to them.
When adding features to objects in some cases complex data
feature setting is needed. Essentially these are such sub objects
which possess own features. For example if we want to add
address data to a customer then by setting the address we can give
the city, the zip code or the name of the street as well.
Some complex data types can be linked not only a single object but the
same element can also be attached to many others. In some of them it
is possible to define further additional data.
One to many linked sub objects:
ADDRESS,
BARCODE, CONTACT,
PRICE
One to one linked sub objects:
CURRENCY, PATTERN, RATE, TAX
The objects of rights management, logging and other options:
LOG,
NUMBERDEF
These objects are not parts of the object model, they are not
needed for recording the workflow data. However certain applications
to ensure their own operation might require data storage
possibilities.
These objects are not or not fully supported by
the functions of NDI, though they are available through the
Nervatura Programming Interface (NPI). Nervatura Web Client (NWC)
also uses some of them.
Storage of data of Reports:
UI_REPORT,
UI_REPORTSOURCES, UI_REPORTFIELDS
Settings of user interfaces:
UI_MENU, UI_MENUFIELDS
User rights, settings:
UI_AUDIT,
UI_USERCONFIG
Regional settings:
UI_LANGUAGE, UI_MESSAGE
Printing:
UI_PRINTQUEUE
For safe backup and restore go from top to the bottom.
Level | Additional data | Objects | |
---|---|---|---|
level 1a | no external link | no | GROUPS, NUMBERDEF |
level 1b | yes* | CURRENCY, TAX | |
level 2a | link to <= level 1 | no | DEFFIELD, PATTERN |
level 2b | yes* | CUSTOMER, EMPLOYEE, PLACE, PRODUCT | |
level 3 | link to <= level 2 | yes* | BARCODE, PRICE, PROJECT, RATE, TOOL |
level 4 | link to <= level 3 | yes* | TRANS |
level 5 | link to <= level 4 | yes* | EVENT, ITEM, MOVEMENT, PAYMENT |
level 6 | link to <= level 5 | yes* | ADDRESS, CONTACT |
level 7 | link to <= level 6 | yes* | LINK, LOG |
level 8 | link to <= level 7 | no | FIELDVALUE |
*Backup with the FIELDVALUE (cross-references fields) |
Level | Objects | |
---|---|---|
level 1 | no external link | UI_MENU, UI_LANGUAGE |
level 2a | link to <= level 1 | UI_MESSAGE |
level 2b | link to <= NOM level 1 | UI_REPORT, UI_AUDIT |
level 3 | link to <= level 2b | UI_MENUFIELDS, UI_REPORTFIELDS, UI_REPORTSOURCES |
level 4 | link to <= NOM level 2 | UI_USERCONFIG, UI_PRINTQUEUE |
1. picture: A possible relational database plan of NOM objects.
2. picture: A possible relational database plan of user interface objects.